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
to create the PDB.SMFRECNT used for the report, and the
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=NO in //SYSIN.
-The new Audit Report goes to PRINT by default, but it can
be redirected to ODS, on ASCII with this //SYSIN syntax:
or on z/OS, you would use this syntax:
-You can also produce the SMF AUDIT REPORT directly from
an SMF file using:
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.
-Format $MGSMFID maps IBM SMF ID numbers and Subtype to
describe each record/subtype. User SMF records will be
tabulated with just the ID and possibly subtype (if the
subtype flag is enabled in the USER record), but you can
create your own VALUE statements to be added to $MGSMFID
in the new IMACSMFF member in your tailoring library.
-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
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 ID 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.
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.
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:
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 DB2 variable QWHDRQNM can now contain an ipv6 address,
VMACDB2 which is longer than the default kept $16 length, causing
VMACDB2H right-most characters to be truncated. Change 22.196 in
Feb 29, 2012 2004 internally INPUT all of these variables as $128:
Mar 4, 2012 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 what permits MXG to
increase stored length without DASD increases when most
of the $128 are still blanks. Change 22.196 did provide
syntax to increase any of those variable's stored length.
Sometime after 2004, DB2 header variables QWHSLOCN and
QWHDSVNM, and non-DB2-header variables QLACLOCN QLSTLOCN
QMDALOCN QPACCOLN QPACLOCN QPACPKID were increased. This
change increases QWHDRQNM and these header variables
QWHCAID QWHCOPID QWHCEUID QWHCTCXT QWHCROLE
QWHCOAUD QWHCCV QWHDRQNM
and these two non-header variables
to now be stored as $128.
Thanks to Fred Wondra, Balboa Insurance, USA.
Thanks to Mark Nakatani, WiPRO, 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, 20123 -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
Feb 23, 2012 '08'X='08X:SUSPENDED'
'42'X='42X:READY FOR SELECTION'
'4D'X='4DX:SELECTED FOR PROCESSING'
OTHER=?< $HEX2. ?>
Thanks to Joseph 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 '184.108.40.206', 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):
and then the GMT datetimes are converted to LOCAL using
-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 these values provided by Cathy:
Feb 17, 2012 VALUE MG073FE
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.
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.
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
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.
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.
ITRM ITRM SAS Note 45583 documents the error and ultimate fix,
Feb 9, 2012 but it is circumvented, simply, by inserting
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:
Feb 8, 2012 SMF21MCW='BYTES*WRITTEN*BY*CHANNEL'
-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
Many 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
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.
-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