COPYRIGHT (C) 1984-2023 MERRILL CONSULTANTS DALLAS TEXAS USA
MXG CHANGES 29.29
=========================member=CHANGE29================================
/* COPYRIGHT (C) 1984-2012 MERRILL CONSULTANTS DALLAS TEXAS USA */
MXG Version 29.29 is dated Jan 23, 2012, thru Change 29.307.
Second MXG Version 29.29 is dated Jan 18, 2012, thru Change 29.301.
First MXG Version 29.29 was dated Jan 17, 2012, thru Change 29.298.
MXG Version 29.09 was dated Jan 4, 2012, thru Change 29.291.
MXG Version 29.08 was dated Dec 20, 2011, thru Change 29.284.
MXG Version 29.07 was dated Nov 24, 2011, thru Change 29.262.
Second MXG Version 29.07 was dated Nov 21, 2011, thru Change 29.259.
First MXG Version 29.07 was dated Nov 14, 2011, thru Change 29.253.
MXG Version 29.06 was dated Sep 8, 2011, thru Change 29.204.
First MXG Version 29.06 was dated Sep 1, 2011, thru Change 29.198.
MXG Version 29.05 was dated Jul 11, 2011, thru Change 29.151.
MXG Version 29.04 was dated May 17, 2011, thru Change 29.116.
Final MXG Version 29.03 was dated Apr 19, 2011, thru Change 29.094.
First MXG Version 29.03 was dated Apr 11, 2011, thru Change 29.086.
Early MXG Version 29.03 was dated Apr 4, 2011, thru Change 29.077.
MXG Version 29.02 was dated Mar 1, 2011, thru Change 29.050.
MXG Version 29.01 was dated Feb 4, 2011, thru Change 29.022.
First MXG Version 29.01 was dated Feb 3, 2011, thru Change 29.020.
Annual MXG Version 28.28 was dated Jan 18, 2011, thru Change 28.331.
MXG Newsletter FIFTY-SEVEN is dated Jan 18, 2011.
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 29.29 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 29.29.
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 29.29 dated Jan 23, 2012, thru Change 29.307.
Major enhancements added in MXG 29.29, dated Jan 23, 2012
TYPEIMS 29.307 Support for IMS Version 12: Adds ZIIP/ZAAP CPU times.
RMFINTRV 29.305 INTERVAL=SHIFT generated warnings & incorrect output.
TYPETMS5 29.304 USER ABEND 1234 can be bypassed for TMSCLEAN input.
IMACICRD 29.302 Comment within comment block if default used.
Major enhancements added in MXG 29.29, dated Jan 18, 2012
TYPENDM 29.301 Old Version 4.7 "PS" record INPUT STATEMENT EXCEEDED.
TYPERMFV 29.300 Wrong ASMRMFV in first 29.29, VMACRMFV updated.
Major enhancements added in MXG 29.29, dated Jan 17, 2012
VMACSMF 29.290 USER ABEND 69 due to invalid SMFTIME now bypassed.
TYPENDM 29.295 NDM/Connect-Direct V5.0 added jobname/jctjobid.
TYPEXAM 29.294 Support for VNDNIC, LPARNW, USVCPU segments.
TYPE110 29.293 Support for CICS Statistics STID=143 and 144.
ASMDBLKU 29.289 ASMDBLKU, ASM version of UDEBLOCK, revised.
ASMRMFV 29.297 Continued RMF III enhancements.
TYPERMFV 29.297 Continued RMF III enhancements.
TYPEDCOL 29.296 DCOLLECT support updated to execute on ASCII.
BLDSMPDB 29.292 Support for execution under unix.
VMXGALOC 29.292 Support for execution under unix.
VMXGPPDS 29.298 Compare contents of multiple PDS/PDSE libraries.
Major enhancements added in MXG 29.08, dated Dec 22, 2011
ANALGRID 29.284 Color-intense grid of "hot spots" of any variable.
(Examples http://www.mxg.com/downloads, ANALGRID.)
ASUM4HRS 29.268 %MACRO calculates "Four Hour" running average values
(or running average for any number of hours).
VMAC30 29.281 CPUTASKALLTM and PCTTASKTIME added SMFINTRV/TYPE30_V.
("Task Time" is recommended by IBM for analysis).
ASMTAPEE 29.280 "YOU SPECIFIED ASCENV" Assembly error with z/OS 1.13.
(MXGTMNT does NOT need to be reassembled on 1.13)
TYPE16 29.264 Support for DFSORT z/OS 1.13 COMPAT new variables.
TYPESVIE 29.273 Support for SYSVIEW subtypes 34 and 35.
TYPETLMS 29.269 Support for CA TLMS tape library 2003 record changes.
TYPETMS5 29.274 CA-1 TMS Extended Format TMC records have no impact.
TYPE120 29.272 SM1209CI and SM1209CX can be negative.
MXGSASxx 29.265 MXGTEMP temporary DDNAME/FILENAME added to MXG JCL.
ASMRMFV 29.279 RMF III RCD INPUT STATEMENT EXCEEDED error.
Major enhancements added in MXG 29.07, dated Nov 24, 2011
TYPEIMST 29.230 Further updates to IMS56FA transaction processing.
SMFSRCH 29.236 SMFSRCH, search SMF records for text, print all obs.
TYPE7072 29.220 Support for z/OS 1.13 (WAS IN MXG 29.03 or later).
TYPETMO2 29.244 Support for TMON/CICS V3.3 (mostly COMPATIBLE) TCE.
TYPEQACS 29.208 Support for IBM i-series (AS400), more than 32 CPUs.
TYPEDB2 29.213 Support for DB2 V10 IFCID 225 Subtype4 INCOMPATIBLE.
TYPETPMX 29.211 Support for Throughput Manager APAR TMT6214, st=16.
TYPEBETA 29.233 Support for BETA93 Version 4.1.0 subtype 25 changes.
TYPEAXWY 29.231 Support for Axway CFT/ESA (Cross File Transfer) SMF.
TYPEPOC 29.219 Support for Tivoli Workload Schedulr Ver 8.3 INCOMPAT
TYPEFERT 29.247 Support for ZEN FERRET V2.3 (INCOMPATIBLE).
TYPEMPLX 29.247 Support for ZEN IMPLEX V5.1 (COMPATIBLE)
TYPEZOSA 29.247 Support for new ZEN OSA MONITOR V1.3 SMF records.
TYPEITRV 29.223 Support for APAR OA37114, ITRF (OMEGAMON IMS V420)
TYPE70x 29.239 Variable SHIFT (used as "ZONE") added to all RMF.
TYPEDB2 29.209 DB2 V10 ID=100 ST=1 INVALID HEADER.
TYPEVMXA 29.207 z/VM MONWRITE Broken Control Rec if 2.14 (SCALL) rec.
TYPE102 29.235 IFCID=22 in Change 28.234 wrong in DB2 V9.
TYPSXAM 29.249 TYPSXAM didn't sort all XMdddddd datasets to the PDB.
ASUM113 29.243 Calculation of ESTSCP1M incorrectly had small values.
ASMRMFV 29.217 Enhanced RMF III RCDSD section support, CHAR->NUM fix
TYPE120 29.240 Length of Character Variable SMF1209FH can't change.
TYPEaaaa 29.238 All USER SMF have MACRO _IDaaaa nnn as SMF record id.
TYPE16 29.232 DFSORT variables ICEMNVLX, ICEMNVLY, ICEMNVLZ wrong?
TYPETPMX 29.229 TPMCA7JN, TPMPI, and TPMDUEOT may be wrong.
TYPE1415 29.226 False ERROR.TYPE1415.DEFECTIVE.EXTENDED... log msg.
TYPEDB2 29.225 INVALID DB2 V10 QMDA segment for QMDAPTYP='JCC'.
TYPE80A 29.223 New TOKENIDs starting with NOxxxx (NOCPUTIMEMAX, etc)
TYPE110 29.221 CICS Statistics datasets CICDB2GL,CICSMDSA, corrected
TYPE119 29.215 Variables T119STCK/TISSTCK/TIESTCH were still GMT.
TYPE78PA 29.214 Values in TYPE78PA ending with TOTL could be wrong.
TYPE845 29.212 Invalid JES3 JMF SMF 84 Subtype 1 Segmented Records.
Major enhancements added in MXG 29.06, dated Sep 8, 2011
SAS V9.3 29.159 Support for SAS Version 9.3 - SAS Hot Fix E80004:
SAS V9.3 Hot Fix E80004 (for SAS Problem Note SN43828) is REQUIRED
to correct an error in the %MACRO compiler, which is SAS portable
code, so the Hot Fix is required for ALL platforms for SAS V9.3.
The %MACRO compiler error is in processing %LET statements.
While only two MXG members actually failed in MXG QA tests, ANY
use of %LETs can fail in MXG (or in your own %MACRO code).
MANY 29.169 MXG ODS HTML ASCII examples failed if no PATH=.
Seen first with SAS V9.3; complete revision of MXG ODS HTML examples
with new %macros with consistent arguments, etc, for all platforms.
TYPEVMXA 29.172 Support for APAR VM64961, SMF 113 in z/VM MONWRITE!!
TYPE113 29.176 Support for APAR OA36816, SMF 113 HIS DATALOSS parm.
IBM now recommends SMF 113 always be created.
TYPEIMST 29.162 Validation of TYPEIMST, many changes for IMS56FA.
Finally: IMS Transaction CPU/Response from ONE IBM IMS LOG RECORD.
TYPEADAB 29.189 Support for Software AG's ADABAS SMF user record.
TYPECFS 29.186 Support for InfoSphere Classic Federation Server SMF.
TYPE23 29.177 Support for APAR OA35175, logstream stats in SMF 23.
TYPE30 29.175 Support for APAR OA35617, SMF30CRM VELOCITY MNGED?
TYPE30 29.174 Support for APAR OA34895, EXCP/IOTM Missed, SMF Lock.
TYPE57 29.173 Support for APAR OA36966, JES3 expanded NJEJOBNO.
TYPEIDMS 29.156 Support for IDMS/R Performance Monitor Version 18.
TYPEVMXA 29.163 z/VM Crypto Record (5,10) with PRCAPMCT=6 error.
TYPE115 29.161 MXG 29.03-MXG 29.05 dataset MQMCFMGR was wrong.
TYPEDM 29.158 NDM-CDI Version 5 new fields supported.
TYPE110 29.155 CICS/TS 4.2 Statistics variables overlooked, added.
VMXGSUM 29.154 AUTOCALL %macro's %CMPRES/%QCMPRES removed.
TYPE111 29.153 UNDECODED CTGRECID message, possible CPU loop.
TYPE7072 29.152 VMSYSTEM='Y' RMF records validated, and revised.
RMFINTRV 29.194 Stats on Page Dataset Slot Usage added to RMFINTRV.
ASUM113 29.193 zVM MONWRITE VXPRCMFC (SMF 113 for z/VM) included.
ASUMUOW 29.188 Case 4 example prevents blank TRANNAME in ASUMUOW.
ASMRMFV 29.187 Do not use ASMRMFV in MXG29.05, fails with 0C4 ABEND.
GRAFWRKX 29.185 Workload RMFINTRV graph's update uses new workloads.
Major enhancements added in MXG 29.05, dated Jul 11, 2011
TYPE110 29.135 Support for CICS/TS 4.2. CICSTRAN supported in 29.03.
TYPE110 29.149 Support for CICS/TS 4.2. MNSEGCL=5 requires 29.05.
TYPE120 29.136 Support for WebSphere WAS 8.0 (COMPATIBLE).
TYPE70 29.127 Support for z/OS 1.12 VMGUEST option, CPU Time in 70.
TYPEIMST 29.144 IMS Transactions in IMS56FA, replaces JCLIMSL6!!!
TYPETIMS 29.123 Support for TMON/IMS Version 3.0 (INCOMPATIBLE).
TYPEPOEX 29.134 Support for Informatica's POWER EXCHANGE SMF record.
TYPEDB2 29.140 New LUUVTIME instead of QWACBSC for start time.
TYPE90A 29.142 Enclave variables decoded in TYPE9030 dataset.
TYPEVMXA 29.133 z/VM LPARNAME, LPNUMBER kept in PDB.VMXAINTV.
UTILARCH 29.137 New UTILARCH archives data (like Outlook archive).
TYPEDB2 29.131 DB2PARTY added to DB2ACCTP, Rollup impact documented.
TYPEDB2 29.128 DB2 INVALID DISTRIUTED HEADER message corrected.
TYPEDB2 29.121 QWHADSGN/QWHAHAMN were sometimes blank.
TYPE102 29.125 DB2 SMF 102 IFCID 22 INPUT STATEMENT EXCEEDED error.
TYPEVMXA 29.129 MXGERROR DM 5 RC 10 UNDECODED PRCAPMCT due to IBM.
TYPEXAM 29.126 XAM variables in VXSYTEP2 were not all input/kept.
TYPE111 29.124 Variables CTGIAREQ/CTGLALRQ revised keeps.
ANALDB2R 29.145 Performance and Reporting Enhancements
Major enhancements added in MXG 29.04, dated May 17, 2011
TYPE105 29.100 Support for GDPS Global Mirror V3R8 SMF 105 record.
DB2ACCT 29.111 DB2 CICS TRAN name could be wrong, now from QWHCCV.
TYPEIMSA 29.110 the exit _IMSTRN invocation was accidentally removed.
BUIL3005 29.106 JES3 PDB.JOBS variable JOBCLAS8 has after change.
VMXGSRCH 29.103 RESULTS=FINDVAR finds all datasets with a variable.
TYPE70PR 29.098 Counts ICFCPUS/IFLCPUS/IFACPUS/ZIPCPUS too high.
TYPE110 29.097 INPUT EXCEEDED 110-2 MNSEGLC=5 with DPL segment
Major enhancements added in MXG 29.03, dated Apr 19, 2011
TYPE110 29.094 1st MXG 29.03 ONLY. CICSTRAN CPUTM plus fields WRONG.
TYPE116 29.057 Support for Websphere for z/OS MQ Version 7.0.1.
TYPE115 29.057 Support for Websphere for z/OS MQ Version 7.0.1.
TYPEBBMQ 29.056 Support for MainView MQ (MVMQ) Version 4.4.
TYPEQACS 29.078 Support for OS/400, AS/400 Version 7.1 (INCOMPATIBLE)
TYPE110 29.076 CICS CPUTM exceeds ELAPSTM, zAAP/zIIP Equivalent time
TYPE120 29.081 Support for User Field in SMF 120 Subtype 9 record.
TYPETPMX 29.071 Support for Throughput Manager subtype 10 and 16.
TYPENTSM 29.075 Support for 62 new objects and 1425 new NT metrics.
UTILVREF 29.075 MXG now creates DATASET names up to 32 characters.
BUILDPDB 29.068 MXG 28.28-29.02. ABEND=JCL obs missing in PDB.JOBS.
TYPERACF 29.067 RACF UNLOAD dataset RACF0270 UID limit variables.
TYPEBETA 29.059 Support for Beta 93 Version 4.2 subtypes 25/50.
TYPE30 29.058 Variable CPUCEPTM always now set to a missing value.
MONTHxxx 29.052 SAS 9.1.3 Only. %QCMPRES needed versus %CMPRES.
TYPE85 29.093 INPUT STATEMENT EXCEEDED st 79, z/OS 1.12.
ASUM70PR 29.092 ZIPCPUS/IFACPUS included parked time.
TYPEVMXA 29.092 z/VM new PDB.VXINTUSR sums all engines for each VM.
Major enhancements added in MXG 29.02, dated Mar 1, 2011
VSETMNTH 29.041 POSSIBLE LOSS OF MONday DATA IN FEBRUARY MONTHLY PDB.
(Unfortunately, EVEN with the newest MXG 29.01).
The MXG2828 or MXG2901 ftp credentials are still valid;
you can download 29.02 and copy the two members you need
(VSETMNTH, and BUILDxxx or BLDSMPDB), or you can ftp
only those specific files to correct the error, for this
month and for future months, or you can install 29.02.
Without these updated members/29.02, future MONTHly's can
also be missing one or more day's PDBs in your MONTH PDB.
The complete details are in Change 28.041, below.
TYPENDM 29.042 Support for NDM-CDI Version 5 records (COMPATIBLE).
VMACDB2H 29.037 DB2 V9.1 false "INVALID DISTRIBUTED HEADER" message.
TYPE30 29.034 Invalid data for SMF30RGT is true, circumvented.
TYPECIMS 29.033 Support for IMF Version 4.5 is in place.
TYPE0 29.032 PDB.IPLS, now, DOES always report a SYSTEM IPL.
TYPEDB2 29.031 DB2 V9.2 only, most QBGxxx variables DB2GBPST wrong.
TYPEVMXA 29.026 Support for zVM APAR VM64794 (COMPATIBLE).
TYPE30 29.025 Small negative CPUUNITS now set to zero.
TYPE26J2 29.024 Cosmetic: INREASON NOT DECODED messages corrected.
Major enhancements added in MXG 29.01, dated Feb 4, 2011
These two impacted MONTHLY build:
MONTHBLD 29.017 SERIOUS ERROR CORRECTED: last day's PDB skipped.
BLDSMPDB 29.017 LIBNAME WEEK1 not found corrected.
These two eliminate possibility of NOTSORTED errors:
BLDSMPDB 29.008 SORTEDBY=NO default to eliminate NOTSORTED exposure.
WEEKBLD 29.008 MXGNOBY default to eliminate NOTSORTED exposure.
MONTHBLD 29.008 MXGNOBY default to eliminate NOTSORTED exposure.
TYPEENDV 29.012 Support for Endeavor Version 14 (INCOMPATIBLE).
TYPE111 29.001 Support for IPIC creates obs in TY111CXI.
TYPE115 29.015 Support for MQ Version 7 compression statistics.
TYPE89 29.002 Support for APAR OA31615, zIIP/zAAP times added,
and false error messages are eliminated.
Please read CHANGESS for the complete list of major enhancements.
See member NEWSLTRS or the Newsletters frame at http://www.mxg.com for
current MXG Technical Notes.
All of these enhancements are described in the Change Log, below.
II. SAS Version requirement information:
MXG 26.03 thru MXG 29.09 will execute under SAS Version 9.3, on
all supported platforms, but SAS V9.3 Hot Fix E80004 is REQUIRED
(for SAS Problem Note SN43828) to correct an error in the %MACRO
compiler, which is SAS portable code, so the Hot Fix is required
for ALL platforms for SAS V9.3.
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.
With Hot Fix E80004, the full MXG QA test stream executed with no
errors, and there were no new warnings on z/OS. Users of ODS will
want MXG 29.06, because SAS V9.3 did expose incompatibilities in
MXG code for ODS reporting, now corrected in MXG Version 29.06.
See Changes 29.159 and 29.169.
To find the Hot Fix for all platforms, open http://www.sas.com,
and then search SAS Notes for 43828 (NOT SN-43828, NOT E80004),
and then Pull Down the Hot Fix tab.
MXG 26.03 thru MXG 29.29 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.
And, only for z/OS 1.10 with SAS V9.1.3 with ANY version of MXG,
the SAS Hot Fix for SN-35332 is REQUIRED (to be completely safe).
Without this Hot Fix, "LIBREF XXXXXXXX IS NOT ASSIGNED" errors
can occur even though //XXXXXXXX DD is a valid SAS Data Library.
This error ONLY occurs with z/OS 1.10 and SAS V9.1.3; it does
NOT occur with SAS V9.2, nor with z/OS 1.9. It can be
circumvented by adding a LIBNAME statement that specifies the
ENGINE name. See the Technical Note in Newsletters for SN-35332.
Old MXG code may continue to execute with SAS V8.2, but V8 is now
"Level B" support from SAS Institute, and there are known errors
in V8.2 that are only fixed in SAS V9. I no longer QA with V8.2;
While many MXG programs (accidentally) will still execute under
V8.2, I can not guarantee that all of MXG executes error free.
PLEASE INSTALL V9.2/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 Hot Fix SN43828 is required; see text of Change 29.159.
With that hot Fix, MXG Versions 26.03 or later should execute
under SAS V9.3 on all platforms without error.
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. (On ASCII,
the 32-bit and 64-bit SAS versions are NOT the same "platform".)
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, 2010 29.03
z/OS 1.13 - MXGTMNT only Dec 15, 2010 29.08
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
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*
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 CICS/ESA 1.2 - 12.12
The Monitor for CICS/ESA 1.3 - 15.01
The Monitor for CICS/ESA 2.0 - 15.06
The Monitor for CICS TCE 2.1 - 20.04
The Monitor for CICS TCE 2.2 - 20.335, 21.134 21.04
The Monitor for CICS TCE 2.3 including CICS/TS 3.1 22.08
The Monitor for CICS TCE 3.2 (almost all) 25.11
The Monitor for CICS TCE 3.2 (almost all) 27.01
The Monitor for MVS/ESA 1.3 - 12.05
The Monitor for MVS/ESA 1.5 - 12.05
The Monitor for MVS/ESA 2.0 - 15.09
The Monitor for MVS/ESA 3.0 - 19.19
The Monitor for CICS/TS V2.3 for CICS/TS 3.1 22.08
Candle
Omegamon for CICS V200 User SMF 12.05
Omegamon for CICS V300 User SMF 13.06
Omegamon for CICS V400 User SMF 16.02
Omegamon for CICS V400 type 110 segments 16.02
Omegamon for CICS V500 User SMF 18.01
Omegamon for IMS V110 (ITRF) 12.12
Omegamon for IMS V300 (ITRF) 14.04
Omegamon for IMS V550/V560 (ITRF) 25.05
Omegamon for MVS V300 13.05
Omegamon for MVS V400 13.06
Omegamon for DB2 Version 2.1/2.2 13.05
Omegamon for VTAM V160 12.04A
Omegamon for VTAM V400 15.15
Omegamon for VTAM V500 18.08
Omegamon for SMS V100/V110 12.03
CA
ACF2 6.2 16.04
ASTEX 2.1 14.04
NETSPY 4.7 14.03
NETSPY 5.0 14.03
NETSPY 5.2 16.05
NETSPY 5.3 18.03
NETSPY 6.0 20.10 20.305
NETSPY 7.0 20.10 20.305
SAR/VIEW R11 23.07 23.196
BMC, was Boole & Babbage
IMF 3.1 (for IMS 5.1) 12.12
IMF 3.2 (for IMS 6.1 only) 15.09
IMF 3.2 (for IMS 5.1 and 6.1+) 16.04
IMF 3.3 (for IMS 7.1 and 8.1) 22.08*
IMF 4.1 (for IMS 9.1) 26.02*
IMF 4.4 (for IMS 9.1) 27.07*
IMF 4.5 (for IMS 11.1) (No change since 4.4) 27.07
Memorex/Telex
LMS 3.1 12.12A
Oracle V9, V10 24.06
Amdahl
APAF 4.1, 4.3 16.08
Velocity Software
XAMAP 3.4 22.10
XAMAP 3406 24.03
XAMAP 3.7 27.10
XAMAP 4.1 29.07
V. Incompatibilities and Installation of MXG 29.29.
1. Incompatibilities introduced in MXG 29.29:
a- Changes in MXG architecture made between 29.29 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 29.29 after MXG 28.28:
Dataset/
Member Change Description
Many 29.169 MXG ODS HTML ASCII examples failed if no PATH=.
ANALDB2R 29.145 Performance and Reporting Enhancements
ASMDBLKU 29.289 ASMDBLKU, ASM version of UDEBLOCK, revised.
ASMRMFV 29.187 Do not use ASMRMFV in MXG29.05, fails with 0C4 ABEND.
ASMRMFV 29.217 Enhanced RMF III RCDSD section support.
ASMRMFV 29.279 RMF III RCD INPUT STATEMENT EXCEEDED error.
ASMTAPEE 29.280 "YOU SPECIFIED ASCENV" Assembly error with z/OS 1.13.
ASUM113 29.193 zVM MONWRITE VXPRCMFC (SMF 113 for z/VM) included.
ASUM113 29.243 Calculation of ESTSCP1M incorrectly had small values.
ASUM4HRS 29.268 %MACRO calculates "Four Hour" running average values
ASUM70PR 29.092 ZIPCPUS/IFACPUS included parked time.
ASUMMIPS 29.237 Calculation of ZIPUSED and ZIEUSED incorrect.
ASUMUOW 29.007 Doc: variables required for ASUMUOW/ASUMCICX.
ASUMUOW 29.009 ASUMUOW fails is //CICSTRN,//DB2ACCT on tape.
ASUMUOW 29.188 Case 4 example prevents blank TRANNAME in ASUMUOW.
BLDSMPDB 29.008 SORTEDBY=NO default to eliminate NOTSORTED exposure.
BLDSMPDB 29.017 LIBNAME WEEK1 not found corrected.
BLDSMPDB 29.246 A dash in filename text tripped up %UPCASE().
BLDSMPDB 29.292 Support for execution under unix.
BUIL3005 29.106 JES3 PDB.JOBS variable JOBCLAS8 has after change.
BUILDPDB 29.068 MXG 28.28-29.02. ABEND=JCL obs missing in PDB.JOBS.
DB2ACCT 29.111 DB2 CICS TRAN name could be wrong, now from QWHCCV.
DB2ACCTP 29.053 Doc. QWACxxxx variables in DB2ACCTP always missing.
EXITCICS 29.064 Rare (one-site) error in INFILE exit corrected.
GRAFWRKX 29.185 Workload RMFINTRV graph's update uses new workloads.
IMACICRD 29.302 Comment within comment block if default used.
JCLSPLIT 29.241 Example to split SMF had 102 records copied twice.
MONTHBLD 29.008 MXGNOBY default to eliminate NOTSORTED exposure.
MONTHBLD 29.017 SERIOUS ERROR CORRECTED: last day's PDB skipped.
MONTHxxx 29.052 SAS 9.1.3 Only. %QCMPRES needed versus %CMPRES.
MXGSASxx 29.265 MXGTEMP temporary DDNAME/FILENAME added to MXG JCL.
RMFINTRV 29.005 Doc: INTERVAL=QTRHOUR became default in 28.01.
RMFINTRV 29.194 Stats on Page Dataset Slot Usage added to RMFINTRV.
RMFINTRV 29.305 INTERVAL=SHIFT generated warnings & incorrect output.
SAS V9.3 29.159 Support for SAS Version 9.3 - SAS Hot Fix SN43828.
SMFSRCH 29.236 SMFSRCH, search SMF records for text, print all obs.
TYPE0 29.032 PDB.IPLS, now, DOES always report a SYSTEM IPL.
TYPE102 29.125 DB2 SMF 102 IFCID 22 INPUT STATEMENT EXCEEDED error.
TYPE102 29.235 IFCID=22 in Change 28.234 wrong in DB2 V9.
TYPE105 29.100 Support for GDPS Global Mirror V3R8 SMF 105 record.
TYPE110 29.076 CICS CPUTM exceeds ELAPSTM, zAAP/zIIP Equivalent time
TYPE110 29.094 1st MXG 29.03 ONLY. CICSTRAN CPUTM plus fields WRONG.
TYPE110 29.097 INPUT EXCEEDED 110-2 MNSEGLC=5 with DPL segment
TYPE110 29.135 Support for CICS/TS 4.2 was in 29.03.
TYPE110 29.155 CICS/TS 4.2 Statistics variables overlooked, added.
TYPE110 29.221 CICS Statistics datasets CICDB2GL,CICSMDSA, corrected
TYPE110 29.293 Support for CICS Statistics STID=143 and 144.
TYPE111 29.001 Support for IPIC creates obs in TY111CXI.
TYPE111 29.124 Variables CTGIAREQ/CTGLALRQ revised keeps.
TYPE111 29.153 UNDECODED CTGRECID message, possible CPU loop.
TYPE113 29.060 z196 Est Finite CPI, Est SCPL1m calcs revised.
TYPE113 29.080 New variables and label revisions.
TYPE113 29.176 Support for APAR OA36816, SMF 113 HIS DATALOSS parm.
TYPE115 29.015 Support for MQ Version 7 compression statistics.
TYPE115 29.057 Support for Websphere for z/OS MQ Version 7.0.1.
TYPE115 29.161 MXG 29.03-MXG 29.05 dataset MQMCFMGR was wrong.
TYPE116 29.057 Support for Websphere for z/OS MQ Version 7.0.1.
TYPE119 29.215 Variables T119STCK/TISSTCK/TIESTCH were still GMT.
TYPE120 29.081 Support for User Field in SMF 120 Subtype 9 record.
TYPE120 29.136 Support for WebSphere WAS 8.0 (COMPATIBLE).
TYPE120 29.240 Length of Character Variable SMF1209FH can't change.
TYPE120 29.272 SM1209CI and SM1209CX can be negative.
TYPE1415 29.226 False ERROR.TYPE1415.DEFECTIVE.EXTENDED... log msg.
TYPE16 29.232 DFSORT variables ICEMNVLX, ICEMNVLY, ICEMNVLZ wrong?
TYPE16 29.264 Support for DFSORT z/OS 1.13 COMPAT new variables.
TYPE19 29.183 Variables SMF19TRK and SMF19TRM were wrong.
TYPE23 29.177 Support for APAR OA35175, logstream stats in SMF 23.
TYPE26J2 29.024 Cosmetic: INREASON NOT DECODED messages corrected.
TYPE30 29.025 Small negative CPUUNITS now set to zero.
TYPE30 29.034 Invalid data for SMF30RGT is true, circumvented.
TYPE30 29.058 Variable CPUCEPTM always now set to a missing value.
TYPE30 29.174 Support for APAR OA34895, EXCP/IOTM Missed, SMF Lock.
TYPE30 29.175 Support for APAR OA35617, SMF30CRM VELOCITY MNGED?
TYPE57 29.173 Support for APAR OA36966, JES3 expanded NJEJOBNO.
TYPE70 29.127 Support for z/OS 1.12 VMGUEST option, CPU Time in 70.
TYPE7072 29.077 z/OS under z/VM: MXG messages, nonexistent RMF data.
TYPE7072 29.152 VMSYSTEM='Y' RMF records validated, and revised.
TYPE7072 29.220 Support for z/OS 1.13 (REQUIRES MXG 29.03 or later).
TYPE70PR 29.098 Counts ICFCPUS/IFLCPUS/IFACPUS/ZIPCPUS too high.
TYPE70x 29.239 Variable SHIFT (used as "ZONE") added to all RMF.
TYPE78PA 29.214 Values in TYPE78PA ending with TOTL could be wrong.
TYPE80A 29.223 New TOKENIDs starting with NOxxxx (NOCPUTIMEMAX, etc)
TYPE845 29.212 Invalid JES3 JMF SMF 84 Subtype 1 Segmented Records.
TYPE85 29.093 INPUT STATEMENT EXCEEDED st 79, z/OS 1.12.
TYPE89 29.002 Support for APAR OA31615, zIIP/zAAP times added.
TYPE89 29.178 Variable CECSER in 89 now contains only 4 positions.
TYPE90A 29.142 Enclave variables decoded in TYPE9030 dataset.
TYPEADAB 29.189 Support for Software AG's ADABAS SMF user record.
TYPEAXWY 29.231 Support for Axway CFT/ESA (Cross File Transfer) SMF.
TYPEBBMQ 29.056 Support for MainView MQ (MVMQ) Version 4.4.
TYPEBETA 29.059 Support for Beta 93 Version 4.2 subtypes 25/50.
TYPEBETA 29.233 Support for BETA93 Version 4.1.0 subtype 25 changes.
TYPEBVIR 29.006 Variables DVRTBV01-32 incorrectly formatted.
TYPECFS 29.186 Support for InfoSphere Classic Federation Server SMF.
TYPECIMS 29.033 Support for IMF Version 4.5 is in place.
TYPEDB2 29.031 DB2 V9.2 only, most QBGxxx variables DB2GBPST wrong.
TYPEDB2 29.121 QWHADSGN/QWHAHAMN were sometimes blank.
TYPEDB2 29.128 DB2 INVALID DISTRIUTED HEADER message corrected.
TYPEDB2 29.131 DB2PARTY added to DB2ACCTP, Rollup impact documented.
TYPEDB2 29.140 New LUUVTIME instead of QWACBSC for start time.
TYPEDB2 29.209 DB2 V10 ID=100 ST=1 INVALID HEADER.
TYPEDB2 29.213 Support for DB2 V10 IFCID 225 Subtype4 INCOMPATIBLE.
TYPEDB2 29.225 INVALID DB2 V10 QMDA segment for QMDAPTYP='JCC'.
TYPEDCOL 29.296 DCOLLECT support updated to execute on ASCII.
TYPEDM 29.158 NDM-CDI Version 5 new fields supported.
TYPEENDV 29.012 Support for Endeavor Version 14 (INCOMPATIBLE).
TYPEFERT 29.247 Support for ZEN FERRET V2.3 (INCOMPATIBLE).
TYPEIDMS 29.156 Support for IDMS/R Performance Monitor Version 18.
TYPEIMS 29.307 Support for IMS Version 12: Adds ZIIP/ZAAP CPU times.
TYPEIMSA 29.110 the exit _IMSTRN invocation was accidentally removed.
TYPEIMST 29.144 IMS Transaction Detail in new IMS56FA dataset!!
TYPEIMST 29.162 Validation of TYPEIMST, many changes for IMS56FA.
TYPEIMST 29.230 Further updates to IMS56FA transaction processing.
TYPEITRV 29.223 Support for APAR OA37114, ITRF (OMEGAMON IMS V420)
TYPEMPLX 29.247 Support for ZEN IMPLEX V5.1 (COMPATIBLE)
TYPENDM 29.010 NDMPRCNM/NDMPRCNO/NDMSTEP now kept where they exist
TYPENDM 29.042 Support for NDM-CDI Version 5 records (COMPATIBLE).
TYPENDM 29.295 NDM/Connect-Direct V5.0 added jobname/jctjobid.
TYPENDM 29.301 Old Version 4.7 "PS" record INPUT STATEMENT EXCEEDED.
TYPENTSM 29.075 Support for 62 new objects and 1425 new NT metrics.
TYPEPOC 29.219 Support for Tivoli Workload Schedulr Ver 8.3 INCOMPAT
TYPEPOEX 29.134 Support for Informatica's POWER EXCHANGE SMF record.
TYPEQACS 29.078 Support for OS/400, AS/400 Version 7.1 (INCOMPATIBLE)
TYPEQACS 29.208 Support for IBM i-series (AS400), more than 32 CPUs.
TYPERACF 29.067 RACF UNLOAD dataset RACF0270 UID limit variables.
TYPERMFV 29.013 CPCGRPLM and LCPUPOLR variables were wrong.
TYPERMFV 29.297 Continued RMF III enhancements.
TYPERMFV 29.300 Wrong ASMRMFV in first 29.29, VMACRMFV updated.
TYPESVIE 29.273 Support for SYSVIEW subtypes 34 and 35.
TYPETIMS 29.123 Support for TMON/IMS Version 3.0 (INCOMPATIBLE).
TYPETLMS 29.269 Support for CA TLMS tape library 2003 record changes.
TYPETMNT 29.248 INVALID ARGUMENT TO SUBSTR IN SYSLOG IEC205I message
TYPETMO2 29.244 Support for TMON/CICS V3.3 (mostly COMPATIBLE) TCE.
TYPETMS5 29.274 CA-1 TMS Extended Format TMC records have no impact.
TYPETMS5 29.304 USER ABEND 1234 can be bypassed for TMSCLEAN input.
TYPETPMX 29.071 Support for Throughput Manager subtype 10 and 16.
TYPETPMX 29.211 Support for Throughput Manager APAR TMT6214, st=16.
TYPETPMX 29.229 TPMCA7JN, TPMPI, and TPMDUEOT may be wrong.
TYPEVMXA 29.014 z/VM MONWRITE "exit" at EOF to detect ftp failure.
TYPEVMXA 29.026 Support for zVM APAR VM64794 (COMPATIBLE).
TYPEVMXA 29.092 z/VM new PDB.VXINTUSR sums all engines for each VM.
TYPEVMXA 29.129 MXGERROR DM 5 RC 10 UNDECODED PRCAPMCT due to IBM.
TYPEVMXA 29.133 z/VM LPARNAME, LPNUMBER kept in PDB.VMXAINTV.
TYPEVMXA 29.163 z/VM Crypto Record (5,10) with PRCAPMCT=6 error.
TYPEVMXA 29.172 Support for APAR VM64961, SMF 113 in z/VM MONWRITE!!
TYPEVMXA 29.207 z/VM MONWRITE Broken Control Rec if 2.14 (SCALL) rec.
TYPEXAM 29.126 XAM variables in VXSYTEP2 were not all input/kept.
TYPEXAM 29.294 Support for VNDNIC, LPARNW, USVCPU segments.
TYPEZOSA 29.247 Support for new ZEN OSA MONITOR V1.3 SMF records.
TYPEaaaa 29.238 All USER SMF have MACRO _IDaaaa nnn as SMF record id.
TYPSXAM 29.249 TYPSXAM didn't sort all XMdddddd datasets to the PDB.
UTILARCH 29.137 New UTILARCH archives data (like Outlook archive).
UTILVREF 29.075 MXG now creates DATASET names up to 32 characters.
VMAC102 29.242 On ASCII COMPRESS turned off, QW0145TX maybe trashed.
VMAC30 29.281 CPUTASKALLTM and PCTTASKTIME added SMFINTRV/TYPE30_V.
VMACDB2H 29.037 DB2 V9.1 false "INVALID DISTRIBUTED HEADER" message.
VMACSMF 29.079 MXG will ABEND if SMFTIME is invalid.
VMACSMF 29.290 USER ABEND 69 due to invalid SMFTIME now bypassed.
VMXGGETM 29.224 Enhancements to select records with LOOKFOR=text.
VMXGMPDB 29.292 Support for execution under unix.
VMXGPPDS 29.298 Compare contents of multiple PDS/PDSE libraries.
VMXGPRNT 29.250 INSTREAM replaces TMPPRNT.SAS for ASCII restrictions.
VMXGSRCH 29.103 RESULTS=FINDVAR finds all datasets with a variable.
VMXGSUM 29.054 Macro variable DSETEXST redefined.
VMXGSUM 29.154 AUTOCALL %macro's %CMPRES/%QCMPRES removed.
VSETMNTH 29.041 POSSIBLE LOSS OF MONday DATA in FEBRUARY MONTHLY PDB.
WEEKBLD 29.008 MXGNOBY default to eliminate NOTSORTED exposure.
See member CHANGESS for all changes ever made to MXG Software.
Inverse chronological list of all Changes:
NEXTCHANGE: Version 29.
====== Changes thru 29.307 were in MXG 29.29 dated Jan 23, 2012=========
Change 29.307 Support for IMS 12: ADDS ZIIP/ZAAP TIME TO IMS LOG DATA!
VMACIMS IBM changes were COMPATIBLY made, used RESERVED fields,
Jan 21, 2012 and those CPU times were added by APAR PM36273.
These new variables are now created in IMS01/IMS01M:
MSGOD62I='APPC*DEST*TYPE'
MSGOD62A='APPC*DETT*ADDR'
MSGIHSQN='SUBPOOL*HSQN*NM'
MSGFMTNM='MFSMODNAME'
MSGEWTKN='WLM*TOKEN TO*C2*CORRELATOR'
These new variables are now created in IMS07 and IMS0708:
DLRXICAL='ICAL*CALLS'
DLRXDGUR='DATABASE*GUR*CALLS'
DLRFLAG4='DLRFLAG4'
DLRAZAAP='ZAAP*ZIIP*CPU*TIME'
This new variable is now created in IMS07 and IMS0708:
LINTSUB2='IMS08*SUBTYPE*ADDITIONAL'
These two variables are now created in IMS56FA:
DLRGUR ='DL/I*GUR*CALLS'
TPEZAAP ='ZAAP*ZIIP*CPU*TIME'
Thanks to Paul Volpi, UHC, USA.
Thanks to Jerome Bachmeier,, UHC, USA.
Change 29.306 DEBUG=1 was on in several XAM file processing sections,
VMACXAM causing log messages but no actual errors in processing.
Jan 20, 2012
Thanks to Clayton Buck, UniGroup, USA.
Change 29.305 Using INTERVAL=SHIFT for RMFINTRV generated MXG WARNINGS
VMXGDUR and produced incorrect output, because TYPE75 addition in
VMXGINIT Change 29.194 didn't test that INTERVAL value. But after
VMXGRMFI the VMXGRMFI fix for SHIFT, and because VMXG70PR uses the
VMXGSUM same macros, both summary programs were tested with all
Jan 22, 2012 -For RMFINTRV, all "Normally used" INTERVAL= values from
SECOND thru FOURHOUR were correct, but for long-duration
values of EIGHTHOUR thru ANNUAL, variable STARTIME was a
missing value, and an "invalid" string did not circumvent
by setting INTERVAL=DETAIL as documented. Changes had to
be made to VMXGRMFI where END versus START had been used.
-For ASUM70PR and ASUM70LP datasets, there were no errors,
but both ASUMCEC and ASUMCELP had populated-but-wrong
STARTIME values (close, but wrong) for long-durations.
-VMXGDUR was the culprit with inconsistent ENDTIME values
returned when FLORCEIL was CEIL for long duration values.
(No one reported errors, other than SHIFT, "NEVER USED?")
-VMXGINIT added new &MXGDURTM a global macro.
-Other members that invoked VMXGDUR were verified to only
expect START values, so they didn't need revision here.
-VMXGSUM cosmetic: INTERVAL=NONE is no longer printed when
no INTERVAL= was specified, as NONE could be confusing.
Thanks to Scott Wiig, US Bank, USA.
Change 29.304 Change 29.195 sets USER ABEND 1234 if TYPETMS5 reads data
VMACTMS5 that is not a TMC (because the results are wrong when the
Jan 20, 2012 file was created by TMSGRW.) But TYPETMS is also used to
read the output of the TMSCLEAN program, to list scratch
volumes, so this change allows you to disable that ABEND
when you know the file is not a TMC, with this syntax:
//SYSIN DD *
%LET MXGABND=1;
%INCLUDE SOURLIB(TYPETMS5);
You will still get the ERROR message on the log that the
file was not a TMC as an alert, without the ABEND.
Thanks to Robert Carballo, ACS, USA.
Change 29.303 Since MXG 27.06, DB2PM-like Statistics Short Report has
ANALDB2R had wrong Total GETS and Buffer Totals Hit Ratios values.
Jan 19, 2012 The SUM statement in line 18777 repeated QB1
GETS =SUM(QB1TGET,QB1TGET,QB1TGET,QB1TGET,0);
but should have summed all four buffer counts:
GETS =SUM(QB1TGET,QB2TGET,QB3TGET,QB4TGET,0);
Thanks to Paul Billick, QVC, Inc, USA.
Change 29.302 CICSTRAN: If your old IMACEXCL member included IMACICRD,
IMACICRD but you didn't have an IMACICRD in 'USERID.SOURCLIB',
Jan 19, 2012 (listed as required in the UTILEXCL job's report), then
the new default IMACICRD in MXG 29.29 was %INCLUDEd, but
it had a comment within the commment block (that I had
missed in my QA tests) that caused a 180 SYNTAX ERROR.
Thanks to Harald Seifert, Huk-Coburg, GERMANY.
====== Changes thru 29.301 were in MXG 29.29 dated Jan 18, 2012=========
Change 29.301 NDM-CDI Version 4.7 "PS" record INPUT STATEMENT EXCEEDED.
VMACNDM Change 29.295 input PSSGPE1D offset, added in V5.0, from
Jan 18, 2012 two reserved bytes, but (old) 4.7 PS records have '4040'x
in those two bytes, and the NEXT two bytes are zero.
Since NDM-CDI records don't contain a version number, the
the logic was revised to test the value of the offset vs.
the record length to circumvent the error.
Thanks to Raff Rushton, IBM Global Services, USA.
Change 29.300 First 29.29 ONLY: RMF III PROCESSING WAS BROKEN.
ASMRMFV Fixed in 29.29 dated Jan 18:
VMACRMFV so that version contains these two corrected members.
Jan 18, 2012 -The VMACRMFV member in MXG 29.29 failed when reading DVT
EXZRBDVT data with ERROR: INPUT STATEMENT EXCEEDED RECORD LENGTH,
Jan 22, 2012 because updates made to VMACRMFV for the new ASMRMFV did
not work with RMFBSAM files created with the old ASMRMFV.
This change to VMACRMFV revised the DVT logic so that
records created by the old or the new ASMRMFV program are
correctly processed.
-The ASMRMFV member in MXG 29.29 was NOT the updated code,
even though it had "Jan 14, 2012, Change 29.297" in the
comments and log messages; it was the ASMRMFV from 29.05
that had none of the last six month's enhancements, and
it had an R in column 1 of the fourth line which caused
the assembly to fail with errors, in the first iteration.
-This change MAY be INCOMPATIBLE - the new VMACRMFV might
ABEND with RCD data in RMFBSAM files created by earlier
ASMRMFV versions, so the ONLY safe implementation is to
assemble the Jan 18 ASMRMFV and use that new program to
read the VSAM RMF file to create the RMFBSAM output file,
and then use the new VMACRMFV to read that RMFBSAM file.
(If your existing ASMRMFV load module was created from
an MXG version earlier than MXG 29.05, the new VMACRMFV
should execute without an ABEND, but no guarantee.)
Added Jan 22:
-ZRBDVT now only outputs DEVICES WITH ACTIVITY, where the
activity is calculated/tested in EXZRBDVT exit member:
ACTIVITY=SUM(DEVACTTM,IORATE,DEVIOQTM,
DVBUSYTM,CUBUSYTM,SWPODLTM);
IF ACTIVITY GT 0 THEN DO;
OUTPUT _WZRBDVT;
END;
Tutorial: Your tailoring logic in EXdddddd dataset exits
to control output of an MXG dataset needs this structure:
IF something THEN DO;
OUTPUT _dddddd;
END;
and can't use a DELETE, nor "IF something;" statements,
because they stop the read-current-record, and cause SAS
to read the next record, so any remaining segments in a
record with more than one observation per record would be
skipped and the output observation count could be small.
-By only outputing active devices in ZRBDVT with detail
device-level-per-minute data, it's more practical to use
the RMF III detail DVT dataset for DETAIL I/O STATISTICS.
Thanks to Jack Schudel, University of Florida, USA.
Thanks to Rodger Foreman, TransUnion Corp, USA.
Change 29.299 Cosmetic installation issues with first MXG 29.29.
FTP -The file size of ter2929.ter was incorrect in the emailed
SENDDATA instructions sent on the 17th. 27,319,296 was correct for
Jan 18, 2012 that iteration.
-Appendix A in the download instructions failed on JES3:
IAT4401 LOCATE FOR STEP=STEP2OF2 DD=INFILE
DSN=MERRILL.V2929.TERSED
IAT4404 DATASET NOT FOUND ON MAIN PROCESSOR A
because that DSN was dynamically allocated in the PGM=FTP
step, but JES3 doesn't know that. The example is changed
to define the DSN in a DD statement, so the new example
now works on both JES2 and JES3. This is not a new issue,
but had not been previously reported, probably because
JES3 techies knew how to resolve this JES3 "feature"!
Thanks to Harald Haug, OBERFINANZDIREKTION KARLSRUHE, GERMANY.
Thanks to James E. Lund, Texas A&M University, USA.
====== Changes thru 29.298 were in MXG 29.29 dated Jan 17, 2012=========
Change 29.298 VMXGPPDS utility reads PDS and PDSE datasets, originally
VMXGPPDS to print text in two-column format. It is now enhanced
Jan 15, 2012 to output the Index entry for each PDS member, keeping
these variables in a dataset for each PDS/PDSE library:
MEMBER='MEMBER*NAME'
DSNAME='DATASET*NAME'
CDATE='CREATE*DATE'
MDATE='MODIFIED*DATE'
TIME='MODIFIED*TIME'
USERID='USER*ID'
INITLINE='INITIAL*LINES'
NOWLINE='CURRENT*LINES'
with an example showing how it can be used to compare the
members (i.e., which is most recent?) in different PDS or
PDSE libraries. Both text and load libraries can be read,
but index information is only usable for text PDS/PDSEs.
Change 29.297 Detail and Summary reports from ASMRMFV have been
ASMRMFV reformatted for improved legibility, content, and
VMACRMFV clarity. Message RMFV105I is updated by the changes.
Jan 12, 2012 -When the DVT is selected in ASMRMFV the entries are now
blocked up to use as much as possible of a 32K logical
record. The number of DVT records output was reduced by
99.5% during testing. The actual data volume is
unchanged. This was to reduce I/Os for performance.
-A new ASMRMFV report column DATA ACTION shows the data
destination for each table as: OUTPUT, FILTER, or SKIP.
-A new ASMRMFV report column ENTRIES COUNT shows the
number of logical table entries processed. The meaning
of an entry varies with the RMF III table type. See
source code documentation for more details.
-The minimum and maximum LRECL output are now shown for
filtered and skipped records if the optional RMFFILT
and/or RMFSKIP DD statements are provided.
-Input table counts are supported up to 999,999,999.
-Output record and entry counts are supported up to
99,999,999,999.
-A new message RMFV032E is added to show the error code
from the IBM decompression routine ERB3RDEC should a
failure occur. In this case the start and end time of
the problem RMF III sample set is also shown. This
should be a rare event.
-The discussion on final ASMRMFV return codes is expanded.
-A discussion is added on how RMF Monitor III options
affect the data contents in tables.
-Prologue documentation in source is updated to include
discussion on new ASMRMFV column headings.
-VMACRMFV is changed to support blocked DVT entries in
input records.
-In VMACRMFV the DEVTYPE variable length has been
corrected to 12 bytes.
-In VMACRMFV the calculation of the DEVACTTM variable has
been changed to avoid excessive Missing Value counts from
SAS.
These are available only with RMF z/OS 1.9 and up. They
will be missing values for older releases.
-Nine new data variables are added to the ZRBDVT file:
DVTFLAG3 - Flag Byte
DVTHPAVB - Device Is HyperPAV Base Device (Y/N/?)
DVTHPCON - Number Configured HyperPAV Aliases for LSS
DVTHPSM - Number of Successful PAV Samples
DVTHPNUM - Accumulated Number of HyperPAV Aliases
DEVALCH - Number of Alias Exposures Has Changed (Y/N)
DEVLCUOK - LCU Number Is Valid (Y/N)
DEVPAV - Multiple Exposure Device(Y/N)
DEVVDASD - Virtual DASD (Y/N)
The first 5 variables are available only with RMF z/OS
1.9 and up. They will be missing values for older
releases. The last 4 variables are available to all MXG
users with RMF Monitor III.
-A new option ZERODVT/NOZERODVT has been added to ASMRMFV.
The default is NOZERODVT and will filter out the initial
DVT entry for each MINTIME interval. This entry is all
binary zeros and has no value in a PDB.
-VMACRMFV will also check for a zero initial DVT entry and
skip processing for it if detected.
-These are companion programs and the same maintenance
level of each must be used for successful results, i.e.,
you MUST assemble the ASMRMFV program to use the VMACRMFV
in 29.29.
Change 29.296 -DCOLLECT support updated to execute on ASCII platforms,
VMACDCOL by conditionally specifying RECFM=S370VBS when MXG is
VMXGINIT executed under ASCII. (On z/OS that DCB parm is set by
Jan 14, 2012 the DSCB at OPEN; S370VBS reads V/VB/or VBS RECFMs.)
-Variable ZTIME added to all keep lists (zEE time when zEE
dataset was created) so that multiple executions of the
IDCAMS DCOLLECT process can be differentiated by time.
-The alternative to differentiate multiple executions of
DCOLLECT is to use the variable INFILENM, which contains
the "dsname/file-name" of the input data, but INFILENM
is only "input" and is not kept in any DCOL dataset. You
could add INFILENM to any DCOL dataset(s) with syntax
%LET MACKEEP= MACRO _KDCOLxx INFILENM % ;
(and repeat the MACRO _KDCOLxx for each dataset) in your
//SYSIN, but this new alternative is now created:
-New macro variable &MXGINFIL is created with null value
in VMXGINIT, and is added to the KEEP= list for all DCOL
datasets. So you could then insert this statement
%LET MXGINFIL=INFILENM;
in your SYSIN stream, and variable INFILENM will be kept
in all of the DCOLLECT datasets
Thanks to Nick Johns, Sainsbury's Supermarkets Ltd, ENGLAND.
Change 29.295 Version 5.0 of NDM/Connect-Direct added jobname and the
VMACNDM JES JCTJOBID to the PS and RJ records.
Jan 14, 2012
Thanks to Peter L., whose company won't allow him to be cited.
Change 29.294 -Support for Velocity Software segments VNDNIC, LPARNW,
EXXMLPAR and protection for USVCPU segment (no data of interest):
EXXMDNIC dddddd dataset
VMACXAM XMDNIC XMVNDNIC
VMXGINIT XMLPAR XMLPARNW
Jan 11, 2012 -Some values in XMLPARNW look wrong, and test data doesn't
contain fields PCTMGTM nor PCTLOGICAL.
Thanks to Robert Obee, IMSHealth, USA.
Change 29.293 -Support for CICS Statistics STID=144 adds new dataset
VMAC110 CICEPR.
Jan 10, 2012 -STID=143 message SKIP=4 with STILEN=156 was eliminated.
There was no new data in the record.
Thanks to Joachim Sarkoschitz, DATAEV, GERMANY.
Change 29.292 Execution under unix is now supported, having found and
BLDSMPDB protected for these variants between WIN and UNIX:
VMXGALOC -The XWAIT option is only supported on WIN, causing error
Jan 14, 2012 conditions on UNIX and zOS but is now protected.
-If NOT EXIST does not work on UNIX, so the logic now used
is %SYSFUNC(FILEEXIST(FILENAME)) which returns a zero if
the file does not exist, or a 1 when the file exists.
Using SYSFUNC also allows the MXGNOTES to only appear
when we actually create or delete a directory.
-md (or MD) is not recognized on UNIX as make directory so
the full mkdir command name (in lower case) is now used.
-rmdir (rd) is used to remove directories under Windows,
but the UNIX command is rm with different subparameters:
on Windows the command is rd /q /s
on UNIX the equivalent is rm -r
-These changes do not impact z/OS execution of BLDSMPDB.
They have been tested under AIX 5.3, RedHat LINUX, and
should work on all xNIX platforms.
Thanks to Ruth Larsen, CA Technologies, USA.
====== Changes thru 29.291 were in MXG 29.09 dated Jan 4, 2011=========
Change 29.291 Lines 541 & 542 were missing a second close-parenthesis,
ANALGRID some arguments were not UPCASE'd, and some selection
Jan 14, 2012 arguments were not printed on the log when used.
Examples added and footnotes formats match grid formats.
Thanks to David Bixler, FISERV, USA.
Change 29.290 -Invalid SMFTIME (Julian date 366 in 2011) in IBM BVIR SMF
VMACSMF record (HISTORY FILE FOR TS7700 VTS TAPE SYSTEM) caused
Jan 2, 2012 a USER ABEND 69, because MXG logic for a bad SMFTIME was
VMACBVIR intended to catch the reading of a non-SMF file. This is
VMACNAF the FIRST time an actual customer has ever ABENDed due to
my choice, which I now realize is too harsh, so now, only
the ERROR message is printed by default. You can enable
the ABEND with %LET MXGABND=1; in your SYSIN.
(BVIR records are supported in MXG's TYPEBVIR code.)
-A second SMF record type, from VTAM SuperSession product,
also caused the USER ABEND 69 because its Julian date had
an invalid Julian date of 637 in 2012! Two in two days!!
MXG's TYPENAF supports those SMF records, but the last
update was in 2005, and they have been incompatibly
changed, with new subtypes and inserted data fields;
MXG will be updated when doc is available.
Thanks to Jim S. Horne, Lowe's Companies, USA.
Thanks to Jorge Fong, NYC Information Technology, USA.
Change 29.289 The ASMDBLKU program is an ASM version of UDEBLOCK, that
ASMDBLKU constructs a valid VBS file on z/OS from a V/VB/VBS file
Dec 30, 2011 that was previously downloaded to an ASCII platform, as
that file is just a serial stream of bytes that cannot
be "back-loaded" and read on z/OS. You upload the file
from your ASCII platform back to z/OS, and then UDEBLOCK
or ASMDBLKU will read those chunks and reconstruct those
records into a valid VBS file on z/OS. This would likely
be needed only if IBM or another vendor needs for you to
send the VBS file for a problem, and you only have the
downloaded file. UDEBLOCK required SAS on z/OS while
ASMDBLKU doesn't. Additionally, UDEBLOCK was functional
but VERY expensive for DASD space, since it created a
single block for each record and wrote one record per
track. ASMDBLKU is smarter and wastes no DASD space.
Multiple enhancements were made to the original ASMDBLKU:
-The SMFOUT file is now generated as a true RECFM=VBS file
so no DCB overrides in JCL are required to process it
subsequently into a PDB build.
-QSAM blocking is now used so that SMFOUT disk space
requirements are significantly less than before when only
one record per 32K block was output.
-The PGSER macro system service SVC call to zero the
output buffer after each I/O was replaced with MVCL logic
thus providing up to a 64% CPU time reduction seen in
testing.
-The SMFOUT file now has DCB BLKSIZE=0 to use System
Determined BLKSIZE. Up to a 41% further reduction in
disk space usage was determined in testing.
-SMFIN and SMFOUT files now use DCB BUFNO=20 to reduce
elapsed time with up to a 33% time reduction seen in
testing. There was some corresponding increase in below
the line storage, but the program ran successfully with
REGION=2M.
-Most ASMDBLKU messages are reformatted for improved
clarity, legibility, and content.
-There are now separate and distinct messages for length
errors for the SMFIN physical block, BDW, and RDW values
respectively. Previously, these types of error were not
disclosed.
-Length error messages now show the invalid length value
and the related record number.
-The SMFIN file is now checked for RECFM=U and DSORG=PS
prior to any processing.
-SMFIN and SMFOUT byte counts are now accumulated and
reported. SMFOUT byte counts do NOT include the BDW
fields added by QSAM. Up to 19 decimal digit totals are
supported (9,999,999,999,999,999,999).
-Minimum and maximum LRECL values read from the SMFIN file
are now reported as message DBLKU25I.
-Minimum and maximum LRECL values written to the SMFOUT
file are now reported as message DBLKU26I.
-A missing DD statement for SMFIN or SMFOUT now generates
Return Code 16 as a severe error.
-Two character Return Codes are now displayed. Before
Return Codes higher than 8 were not supported.
-Record counts for SMFIN and SMFOUT files are now scaled
up to 9 decimal digits (999,999,999).
-Message DBLKU30I indicating final utility status is now
the last message displayed.
-Message DBLKU30I ended message is consistent in
appearance and format with DBLKU00I started message.
-PRINT OFF/PRINT ON added to suppress printing of the
change log during assembly.
-Prologue comments outside of the assembler source have
been updated.
Change 29.288 Reserved Change.
Dec 30, 2011
Change 29.287 Many VMWARE objects were revised to contain xxxxVMHO and
EXNTDTSC xxxxVMGU (Host and Guest names), changing NRNAMES, which
IMACNTSM caused MXG NRNAMES Messages. New DTS.ALERTCONFIG object
TYPENTSM is supported.
VMACNTSM
VMXGINIT
Dec 31, 2011
Change 29.286 Variable LPARCPUS was incorrectly typo'd as LPARCPU. Been
ANAL113 this way since 2010, so I assume either no use, or users
Dec 22, 2011 recognized and fixed the typo without report to support,
so Thomas gets this citation for finding the old error.
Thanks to Thomas Puddicombe, CSC, USA.
Change 29.285 Presumed error in back level SAS 9.2 TS0202M2 on z/OS, as
FORMATS NO error with 9.3 TS0202M3 nor 9.1.3/SP4 nor 9.3 on z/OS.
CREATEBC A split line in EBCDIC text for $MGZOSVT caused no error
PROCSRCE when PROC FORMATS created $MGZOSST/$MGZOSVT, but the two
Dec 22, 2011 formats could not be loaded when TYPEZOSA was executed by
TESTUSR1. The original ASCII text had a unexpected '0A'x
character (Line Feed) in that line, but that only caused
the EBCDIC text to be split there; no unprintable text
character was created in EBCDIC, and the longer right
hand value was still valid syntax, and was handled fine
on all other z/OS SAS versions.
-However, the unexpected '0A'x in ASCII text reminded me
to look for other unprintables in the EBCDIC text, and
three values ('01'x,'1C'x,'1D'x) are now detected in the
PROCSRCE/CREATEBC QA members, and corrected before EBCDIC
members are created for distribution. Fortunately, none
of these characters cause execution errors.
Thanks to Scott Wiig, US Bank, USA.
====== Changes thru 29.284 were in MXG 29.08 dated Dec 20, 2011=========
Change 29.284 ANALGRID creates a color-intense grid report of the value
ANALGRID of any variable, with time intervals as columns and date
Dec 20, 2011 as the row, to visually identify "hot spots". This is
based on the original design that was contributed by Bob.
See http://www.mxg.com/downloads, ANALGRID for examples.
Thanks to Robert A. Obee, IMS Health, USA.
Change 29.283 MXG 29.06-29.07. RMFINTRV with INTERVAL less than QTRHOUR
VMXGRMFI created an invalid PDB.RMFINTRV dataset with too many obs
Dec 20, 2011 but with ERROR: INCONSISTENT RMF DATA printed on the log.
Change 29.194 added TYPE75 summary data to RMFINTRV, but
had INTERVAL=QTRHOUR instead of INTERVAL=&INTERVAL.
Thanks to Yves Terweduwe, CIPAL, BELGIUM.
Change 29.282 The example summary of TYPE72GO to create ASUM72GO was
ASUM72GO updated to support "SYNC59" data written at :59 or :00
Dec 20, 2011 intervals.
Thanks to Brian Carter, HP Enterprise Services, ENGLAND.
Change 29.281 New CPUTASKTIMETM=ADDRESS*SPACE*DISPATCHED*TASK CPU TIME
VMAC30 and PCTTASKTIME=PCT WHEN*TASK WAS*DISPATCHED*ON PHYSICAL
BUILD005 variables are created in TYPE30_V and PDB.SMFINTRV data
BUIL3005 sets, to report the interval percentage of time when an
Dec 18, 2011 address space was dispatched on a physical processor.
PCTTASKTIME can exceed 100% when multiple tasks are
used for parallelism; values more than 25% are probably
of most interest. You can create the variables from your
PDB.SMFINTRV (or TYPE30_V) dataset, using:
CPUTASKGCPTM=CPUTCBTM-CPUASRTM-CPUENCTM-CPUDETTM;
CPUTASKZAPTM=(CPUIFATM-CPUEFATM-CPUDFATM)*256/SMF30ZNF;
CPUTASKZIPTM=(CPUZIPTM-CPUEZITM-CPUDZITM)*256/SMF30SNF;
CPUTASKTIMETM=CPUTASKGCPTM+CPUTASKZAPTM+CPUTASKZIPTM;
IF INTRVLTM GT 0 THEN
PCTTASKTIME=100*CPUTASKTIMETM/INTRVLTM;
Thanks to Bernie Pierce, IBM, USA.
Change 29.280 -z/OS 1.13 ASM ERROR when assembling ASMTAPEE/MXGTMNT:
ASMTAPEE "YOU SPECIFIED ASCENV=AR OR ANY ON THE SYSSTATE MACRO.
Dec 20, 2011 THE OPEN MACRO SUPPORTS ONLY ASCENV=P."
But there is NO NEED to ASM a new load module under 1.13;
your currently executing MXGTMNT module works just fine!
-This IBM note (migration guide) is the ONLY clue of the
incompatible change, which impacts OPEN/CLOSE macros, but
doesn't mention any by name:
DFSMSdfp: Accommodate 64-bit & AR mode rules enforcement
in DFSMS macros; required if you have code that invokes
DFSMS macros (but not all!). Before z/OS V1R13, many
DFSMS macros that did not support 64-bit or AR mode did
not react to being invoked in 64-bit or AR mode, and
generated code that might have been invalid in 64-bit or
AR mode. Starting with z/OS V1R13, these macros are
changed to issue an assembly-time message and suppress
expansion if they are invoked in 64-bit or AR mode."
-But as noted above, you didn't really need to ASM. Now,
from MXG's "asmguy", his comments on this change:
Nothing is going to happen to an existing site using
MXGTMNT and in fact the modification I have to make for
this does not result in any change to the executable
code.
The SYSSTATE macro is an assembler directive - it sets
a flag that tells any macros that support AR mode
(Access Register, used for cross memory access) to use
their AR mode compatible expansion. Macros that don't
have an AR mode expansion used to ignore this because
they had nothing to do, and it's always the coder's
responsibility to make sure that when those non-AR
compatible macros are executed, that the system is not
in AR mode. This is similar to switching back and forth
from 24-bit to 31-bit mode: some macros can't tolerate
31-bit mode. Nothing has really changed though; it is
still the coders responsibility to make sure the system
is not in AR mode and macros that can't tolerate AR mode
still can't, except now IBM is requiring the coder to
explicitly set SYSSTATE to indicate to the assembler
that the system is not in AR mode.
Of course this is all very silly because the assembler
can't know ahead of time that the system is or isn't in
AR mode. So regardless of whether or not SYSSTATE is
coded this way the system still could be in AR mode,
OPEN/CLOSE will still expand the same way, and if the
system really is in AR mode OPEN/CLOSE will abend when
executed.
So the bottom line is that nothing has changed except
our need to do something for no reason at all.
-This ASMTAPEE is now ML-48 in the MXGTMNT startup msg.
Thanks to Thomas Maguire, CitiGroup, USA.
Change 29.279 -ASMRMFV incorrectly calculated the RCDSDI offset, causing
ASMRMFV an INPUT STATEMENT EXCEEDED RECORD LENGTH error, when an
Dec 13, 2011 RCD Table Record had an RCDSD Subsystem Delay array, but
the record didn't have an RCDRD Response Time array.
-Also a formatting error in message RMFV102I was corrected
*** END OF DATA *** showing record input count.
Thanks to Scott Chapman, American Electric Power, USA.
Change 29.277 NPM VCS segment with an invalid fifth ECSA segment (with
VMAC28 buffer size of 180 Kbytes), and without the DATA segment
Dec 8, 2011 for buffer size 64Kbytes. The segment length is the 176
expected length, so this circumvention skips the invalid
segment if size is 180 and doesn't input the last data
segment; when IBM fixes the record, the circumvention
does not need to be removed.
APAR OA38371 will correct the error, ETA Feb, 2012.
Thanks to Karen Florup, Bank of America, USA.
Change 29.276 RMF III dataset ZRBASI variable ASIPER, PERIOD, is input
VMACRMFV where ASIDMN, DOMAIN, was previously located. ASIDMN is
Dec 8, 2011 set to zero, its value ever since domains departed z/OS.
Change 29.275 The CLRMFV Clist will now check for non-zero Return Codes
CLRMFV from the TSO LISTCAT LEVEL command.
Dec 8, 2011 -3 messages indicating the error, the data set name level,
and the Return Code are now issued.
-In addition, the first 4 lines of LISTCAT output for the
error condition are displayed.
-Prior to this change CLRMFV could issue a non-zero MAXCC
message at completion and the reason was difficult to
determine when LISTCAT was involved.
-A non-zero LISTCAT Return Code is most commonly caused by
a data set name level that does not exist.
Thanks to Rodger Foreman, Acxiom CDC, USA.
Change 29.274 CA-1 TMS "Extended Format TMC Catalog" records are COMPAT
VMACTMS5 with ALL versions of MXG, as there was NO change in the
Dec 7, 2011 TMC's 340 byte record's length. The text of Change 28.040
that thought there were new length(s) was wrong and gone.
Change 29.273 -Support for subtypes 34 and 35 of SYSVIEW for IMS creates
EXSV34DA dddddd dataset description
EXSV34TR SV34TR SV34TRAN Subtype 34 Transaction
EXSV35EV SV34DA SV34DAC Subtype 34 DAC Segment
EXSV35TR SV35TR SV35TRAN Subtype 35 Transaction
IMACSVIE SV35EV SV35EVNT Subtype 35 Event Segment
VMACSVIE -There are errors in the subtype 34 and 35 that I have
VMXGINIT circumvented in this iteration, and SYSVIEW support has
Dec 7, 2011 confirmed the errors in the 34 and are looking at similar
errors in the 35 record; both will likely be corrected in
a future PTF from CA. The value in IMRA_DBIOTIME is
appears to be defective, also.
Thanks to Anthony G. Hurlston, CSC, USA.
Change 29.272 -Variable SM1209CI and SM1209CX can be negative, but they
VMAC120 were INPUT as PIB, so a negative field becomes a large
Dec 7, 2011 positive value in MXG. They are now input as IB.
IBM Support reports than when work does not complete,
ENDTIME isn't populated, and since CI is calculated as
END-START, you get a negative value. But you can also get
a negative value of -1 if WebSphere was unable to reach
its internal service that supplies the END time: for
example, an in-flight transaction when the server was
configured to "Drain" work during termination, but that
transaction still could have completed normally, so all
of the other fields could be completely valid.
IBM chose to NOT suppress these records even when they
might contain incomplete values, because many other data
values could be useful in diagnosing problems, and there
should be relatively few of these records. You probably
should filter these records from your daily reporting
totals, but rather than testing for a negative value in
CI/CX, which have valid transaction data, IBM Support
suggests to exclude transactions that have any value in
the minor code, SM1209CJ, and perhaps to simply count the
number that were excluded.
-Variable SM1209BM now has value '7.0.0.15' instead of the
value '7.0.0.*' when the fourth byte was GT 9.
Thanks to Wayne Bell, UniGroup, Inc, USA.
Change 29.271 Variable R799CNF bit 3 now creates R799CPD='Y' if the
VMAC79 connect/pending/disconnected time is not valid. All
Dec 6, 2011 other bits were already decoded into unique variables.
Thanks to Heimir Hauksson, Barclays, ENGLAND
Change 29.270 Variable POUNAL was incorrectly multiplied by 4096 when
VMACQACS it should have been multiplied by 1024 to convert KB to
Dec 6, 2011 bytes.
Thanks to Thierry Wehrle, BNP Paribas, FRANCE
Change 29.269 CA TLMS tape library records were changed sometime since
VMACTLMS 2003 when the MXG TYPETLMS was last updated, causing the
Dec 5, 2011 TYPETLMS dataset to contain mostly trashed field as MXG
INPUT BAUNIQUE and BAVOL1ST as PIB4 but they appear to
be only 2-byte fields.
Thanks to Gene Palmer, CitiGroup, USA
Change 29.268 The new ASUM4HRS %macro calculates "Four Hour" running
ASUM4HRS Average Values of the variable(s) you chose, but any
VGETFMT integer number of hours can be used instead of "Four".
VGETLABL -New VGETFMT/VGETLABL/VGETLEN internal macros retrieve the
VGETLEN FORMAT, LABEL, and LENGTH of a variable so that the new
VMXGDUR Average Value variable will have the same attributes as
VMXGSUM the inputted variable.
VMXGPARS -VMXGDUR,VMXGSUM adds duration tokens for EIGHTHR and
Dec 13, 2011 TWELVEHR. These duration tokens now can be used:
ANNUAL, SEMIANN, QUARTER, MONTH, WEEK, DATE, SHIFT,
TWELVEHR, EIGHTHR, FOURHOUR, THREEHR, TWOHOUR, HOUR,
HALFHOUR, TWENTYMIN, QTRHOUR, TENMIN, FIVEMIN,
THREEMIN, TWOMIN, MINUTE OR SECOND, or DETAIL.
-VMXGPARS now parses at two blanks to create a new line.
Change 29.267 Variable MPL72, the average number of concurrent resident
VMXGRMFI ASIDs, is now created in PDB.RMFINTRV dataset. Variables
Nov 29, 2011 APPCAVG and APPCMAX to count those ASIDs are also added.
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 29.266 In TYPE70PR dataset, variables SMF70MSU and SMF70LAC are
VMAC7072 output in each TYPE70PR obs, but from the one TYPE70 obs
Nov 29, 2011 for "THIS" LPAR, so they are repeated for all LCPUADDRs
in this LPARNAME (being kept here only so they can be in
ASUM70PR). Since they are z/OS-only relevant, they are
now only populated in the SMF70CIN='CP' observations as
their non-missing value in obs for VM, ZIIPs, etc, was
unexpected and unwanted.
Thanks to Lars Fleischer, SMT Data, DENMARK.
Change 29.265A MXG 29.07 corrections found during ITRM validation.
VMAC42 -Macro token PSUVMXA added in Change 29.120 was misspelled
VMACCIMS as PSUMVXA in the GLOBAL statement in VMXGINIT.
VMACNTSM Also, the hardcoded PDB. in MACRO _LTYVMXA PDB.VMXAINTV
VMACTPMX in the (optional) ASUMVMXA member was corrected to the
VMXGINIT default &PVMAINT macro destination DD for VMXAINTV.
Nov 29, 2011 -TYPECIMS variables TRNSTRTA/TRNSTARTU/TRNSTOPA/TRNSTOPU
are no longer kept in CIMSTRAN as they are GMT offsets
that are already used to convert times to local zone.
-Variable VWGMACBY was accidentally removed from the NTSMF
dataset VMWGUMEM.
-TYPETPMX variables JBL54051,JBL55044-JBL55051 were always
missing values, DKROCOND=WARN printed warnings due to
typos in the variable name in the assignment statements.
All of the JBL54xxx and JBL55xxx are also now labeled.
-TYPE42 variables SMF42PTE and SMF42PTS are now labeled.
Thanks to Chris Weston, SAS ITRM Development, USA.
Change 29.265 Temporary DDNAME/FILENAME MXGTEMP is added to the MXG JCL
VMXGCNFG for z/OS for future cases when more than one temporary DD
MXGSAS is required. Currently, only SMFSRCH uses that DDNAME.
Nov 25, 2011
Change 29.264 Support for DFSORT for z/OS 1.13 adds COMPATIBLY two new
VMAC16 variables to TYPE16 dataset:
Nov 25, 2011 ICEMCPUZE='ZIIP*ELIGIBLE*CPU*TIME'
ICEMCPUZP='ZIIP*ACTUAL*CPU*TIME'
Change 29.263 Variables SMF30JQT/SMF30RQT/SMF30HQT/SMF30SQT are missing
BUILD005 values in PDB.SPUNJOBS for jobs that had TYPE30_5 job
BUIL3005 term obs with MULTIDD='Y' (which have only EXCP counts.)
Nov 25, 2011 And those TYPE30_5 with MULTIDD='Y' shouldn't ever have
been used in BUILDPDB logic; MXG uses the step records
for EXCP counts and only wanted the TYPE30_5 values from
the "real" TYPE30_5 that has MULTIDD=' '. So this change
deletes MULTIDD='Y' observations during processing of the
TYPE30_5 records in BUILDPDB and BUILDPD3.
Thanks to Esther Remiro, La Caixa, SPAIN.
====== Changes thru 29.262 were in MXG 29.07 dated Nov 24, 2011=========
Change 29.262 First MXG 29.07 Only, and only if IMACEXCL is tailored to
VMAC110 read exclude fields. WARNING: UNBALANCED QUOTES message
Nov 23, 2011 was printed, BUT ALL DATASETS WERE CREATED CORRECTLY.
There were no unbalanced quotes, but 29.07 had introduced
new " &CICXLTR " syntax into the existing PUT '***ERROR'
statement printed when MXG detects there are excluded
fields that are not supported in your IMACEXCL tailoring;
the enhancement prints your selection statements from the
current IMACEXCL member in use to help error resolution.
And for reasons I know not now, that macro reference was
the cause of the spurious warning. Now SYMGET('CICXLTR')
is used to retrieve the text for the PUT statement.
Thanks to Gerard Bosker, Rabobank Nederland, THE NETHERLANDS.
Change 29.261 -An incomplete comment in Change 29.147 caused the new and
VMAC0 "true" IPLs datasets WORK.TYPE0 and PDB.IPLS to have ZERO
Nov 23, 2011 observations since that change in MXG 29.06. That this
error was accidentally discovered when trying to diagnose
the unbalance quote warning in Change 29.262, by counting
the two comment tokens ( /* */ ) separately to see if the
counts are equal (because often unbalanced quote errors
result from unbalanced comments, or new comments wrapping
around commented text) suggests that few sites have IPLs
that needed to be reported!
-An incorrect pair of single quotes was changed to single
quote in optional IMACICBB code, discovered the same way
when counting quotes. The pair was inside the comment
block, and it's been there a long time; either tailoring
users caught it and fixed it when enabling that optional
CICS segment, or nobody uses this optional segment.
Thanks to Gerard Bosker, Rabobank Nederland, THE NETHERLANDS.
Change 29.260 At only one site, the EXITCICS decompression of DB2 V10
VMACDB2H records created records with INVALID HEADER values that
EXITCICS caused STOPOVER ABEND. This change thought the SMF data
Nov 23, 2011 was valid and added protection for the "truncated" data
Dec 18, 2011 segments, but that protection, while safe, was not needed
and the problem in the SAS INFILE exit code in EXITCICS
is being investigated by SAS Technical Support. The DB2
V10 compressed records can be uncompressed using the IBM
utility program xxxxxxx until the problem is resolved,
but this is most strange as MANY sites are successfully
reading compressed DB2 (and CICS!) records with EXITCICS.
This is the text of the original change:
DB2 V10 record with INVALID HEADER caused STOPOVER ABEND.
The ID=101 SUBTYPE=1 record had invalid offsets that are
now protected. The starting INPUT location was compared
with the LENGTH of the record, but in this case, while
the start offset happened to be less than the LENGTH,
the length of data to be input was beyond the LENGTH,
causing the STOPOVER ABEND. Now both the start and end
of each of these truncated name fields is validated and
an error message "INVALID DB2 RECORD QWHC=...." printed.
This text will be updated when an APAR/PTF is known.
Thanks to Gerard Bosker, Rabobank Nederland, THE NETHERLANDS.
====== Changes thru 29.259 were in MXG 29.07 dated Nov 21, 2011=========
Change 29.259 Cosmetic. Diagnostic PUTLOG statement in IFCID=140 code
VMAC102 was left and printed A_N_= nnn .... on the SAS log for
Nov 18, 2011 each IFCID=140 record, but no other impact.
Thanks to Stephen Hoar, Lloyds Banking, ENGLAND.
Change 29.258 Comparison of I/O Connect Times in RMF 74 and SMF 30 show
BUILD005 DEVCONTM SMF74CNN - DEVICE CONNECT TIME 2,058,143 sec
BUIL3005 SMF30AIC - DASD CONNECT 2,150,200 sec
IMAC30IO IOTMTOTL SMF30TCN - ASID IO all ASIDs 1,482,821 sec
VMAC30 IOTMTODD SMF30DCT - DD IO all ASIDS 1,253,434 sec
Nov 18, 2011 IOTMNODD MXGcalc - TOTL not in DDs 229,387 sec
RMF DEVCONTM and RMF SMF30AIC match quite closely, but
that "hardware" IOTM captured in RMF and in SMF30AIC is
much larger (2150200-1482821= 677,379 sec) than the IOTM
that is captured in SMF30TCN, Address Space IOTM Total.
To investigate, variable in TYPE30/JOBS/STEPS/SMFINTRV
IOTMNOCA='CONNECT*TIME*NOT CAPTURED*IN IOTMTOTL'
is created to see if the cause of this uncaptured IOTM
can be identified/correlated. This text will be updated
when more is known (including my asking IBM).
Some initial investigation with different data shows
-Of 9881 records with non-zero SMF30AIC, 1867 had a
negative IOTMNOCA, but only 40 were more than -10 sec
and the max negative was 2 jobs at -3 minutes.
MOST OF THESE WERE PROGRAM=DSNYASCP although our old
friend IFASMFDP had instances of -37, -17 and -12 sec.
-Of the other 7119 with positive IOTMNOCA, 592 were
greater than 3 seconds, AND ALL WERE PROGRAM=BPXPRFC.
which is the first step of an OMVS Spawned Address
Space Substep. This suggests that the use of I/O by
USS-OMVS is ONE source of NOT-Captured IOTM in 30s.
There are many OMVS I/O counters in the OMVS segment
in SMF 30s, but none have the I/O Connect Time.
-But, a third sites data looking at DB2 and ADABAS jobs
shows large positive uncaptured values for ADABAS but
for DB2 jobs, large negative uncaptured, i.e., time in
SMF30TCN is LARGER than the time in SMF30AIC.
-This issue is under discussion with IBM z/OS folks;
I think that IOTM for USS is captured in AIC but not
in IOTM, and there are errors in which address space
records IOTM when there are "partner" database ASIDs,
but the total IOTM are correct. We'll see!!
JOB INTBTIME IOTMTOTL SMF30AIC IOTMNOCA
DB2JOB01 13:14:00.15 0:10:23.25 0:00:42.06 -581.19
DB2JOB01 13:29:00.16 0:09:08.14 0:02:49.97 -378.16
DB2JOB01 13:44:00.16 0:07:51.57 0:01:34.28 -377.29
DB2JOB01 14:14:00.17 0:10:44.91 0:00:23.18 -621.73
DB2JOB01 14:29:00.21 0:10:22.25 0:00:55.89 -566.35
ADABAS72 13:14:00.05 0:02:46.90 0:12:50.75 603.85
ADABAS71 13:29:00.09 0:01:40.57 0:08:55.19 434.61
ADABAS72 13:29:00.09 0:03:54.11 0:16:02.57 728.45
ADABAS72 13:44:00.04 0:03:32.12 0:16:39.49 787.37
ADABAS72 13:59:00.02 0:03:05.23 0:16:01.69 776.46
ADABSD72 14:14:00.07 0:02:48.06 0:15:40.71 772.64
ADABSD72 14:29:00.05 0:02:05.13 0:11:20.71 555.58
Thanks to Meral Temel, Garanti Teknoloji, TURKEY.
Change 29.257 WMQGETTM was not divided by the 4096 factor needed for
VMAC110 CICS 8-byte time durations, so it was a little too large!
Nov 17, 2011
Thanks to Robert C. Crawford, USAA, USA.
Change 29.256 Change 29.120 revisions to ASUMVMXA were not included in
ASUMVMXA that change until today.
Nov 17, 2011
Change 29.255 z/VM datasets VXSUMIOD and VXDEVTOT created by _SIODDEV
VMACVMXA were left in //WORK, and dataset macros _LSUMIOD/_LDEVTOT
VMXGINIT were not defined nor were &PSUMIOD nor &PDEVTOT; all are
Nov 16, 2011 now defined and used so they now default to //PDB.
_RPT36 was revised to use _LDEVTOT as its input dataset.
Thanks to Scott Barry, SBBWorks Inc, USA.
Change 29.254 IMF variable ARRVTIME has resolution to only one decimal
VMACCIMS place, but "newer" variable TRNARVTH time has two decimal
Nov 19, 2011 places, so ARRVTIME is now revised to use the DATE part
of original ARRVTIME but with TRNARVTH's value for TIME.
Thanks to Ken Jones, Xwave, CANADA.
====== Changes thru 29.253 were in MXG 29.07 dated Nov 14, 2011=========
Change 29.253 Preliminary support for Velocity Software Version 4.1 has
VMACXAM eliminated warning messages about new segments, and most
Nov 14, 2011 new data fields are decoded, and this level set has been
validated with data records thru MXG's QA job stream.
Thanks to Douglas C. Walter, Citigroup, USA.
Change 29.252 The new SM120XP/SM120XZ times are in microseconds rather
VMAC120 than the (strange) duration units that MXG decoded. Also,
Nov 14, 2011 the MXG code caused INVALID ARGUMENT messages if executed
on ASCII; those fields had not been translated to EBCDIC
before they were used in the INPUT function.
-The undocumented SM120XZ field is the CPU time that has
been offloaded by WebSphere to zIIP engines, and it is so
labeled now.
Thanks to Millard Stephens, FMR, USA.
Thanks to Warren Cravey, FMR, USA.
Thanks to Raj Ramachandran, IBM, USA.
Change 29.251 Support for Demand Technology Performance Sentry NTSMF V4
EXNTDTSA adds three new objects that create three new datasets:
EXNTVMWA dddddd dataset description
EXNTVWVS NTDTSA DTSALRTR DTS.AlertRecipient
IMACNTSM NTVMWA VMWAREh VMWARE
VMACNTSM NTVWVS VMWHVSPH VMWARE.HOST.VSPHEREREPLICATION
VMXGINIT -Existing VMWARE objects were INCOMPATIBLY changed by the
Nov 12, 2011 insertion of a separate field for the 2nd instance field.
Previously a single field contained both instance values,
separated by a '::', that MXG parsed in the two instance
variables. MXG now detects NRNAMES=2 and uses separate
fields when they exist, but that new NRNAMES value causes
error messages (and no observations output), if you read
NTSMF V4 (new) records with MXG prior to 29.07.
These segments have two fields stored for xxxxINST/INS2
VWGC VWHC VWGD VWHD VWGN VWHN VWHS
These segments have one field that is still parsed to
populate the two xxxxINST and xxxxINS2 instances:
VWGA VWHA VWGM VWHM VWGS
-New variables xxxxVMHO (VM*HOST), xxxxCPU (CPU*NUMBER),
xxxxVMGU (VM*GUEST) are created from new fields added at
the end of many existing VMWARE records.
-Many new variables were added to existing VMWARE datasets
in Version 4, too many to list here, but you can find all
in VMACNTSM after the text "ADDED BY CHANGE 29.251" in
the KEEP= list for all datasets.
Change 29.250 Windows SEVEN restricts writes to the root, program file,
VMXGPRNT and other directories. VMXGPRNT writes text/code to file
Nov 10, 2011 TMPPRNT and then %INCLUDEd TMPPRNT, but the MXG default
file C:\MXGTEMP.SAS was in the root directory, so it was
restricted from access. The circumvention was to change
filename TMPPRNT to INSTREAM, which is the MXG ddname
specifically designed (and used internally by MXG) to
dynamically create SAS code and/or MXG macro definitions
"instream" and then %INCLUDE them. TMPPRNT was never
needed, but the original contribution was left asis.
FWIW: Even with the error, all datasets were printed;
The error prevented the printing of the variable name
along with its label, which is the ONLY reason you want
to use VMXGPRNT/VMXGPRAL, and why I saw the error, as
I use VMXGPRAL all the time, especially to understand
all of the variables in a new dataset I've just built.
Change 29.249 TYPSXAM example to create and sort all datasets to PDB
TYPSXAM did not sort all fifty-six datasets. The structure of
Nov 10, 2011 MXG support for XAM is different because XAM has five
INFILEs that create fifty-six datasets. Each infile has
a macro pair _TXAMfff and _SXAMfff where _TXAMfff reads
infile fff to create all fff datasets and _SXAMfff sorts
the fff datasets to the PDB. But, the _SXAMfff macros
have not been updated in a long time so the newer XAM
datasets were not in the XAM PDB data library.
The simple resolution is to replace the five _SXAMfff
macro invocations in TYPSXAM with the _SXAM product sort
macro that sorts ALL of the XAM product's datasets (and
all of the _Sxxxx product sort macros are validated to
sort all datasets as part of MXG's robust QA jobstream).
An additional problem is avoided: the _SXAMDEV token
name is used for both the data set sort token and for
the _SXAMfff "infile fff" token. Using _SXAM and not
using the _SXAMfff tokens avoids a major redesign and
new (INCOMPATIBLE) naming conventions.
Thanks to Debbie Mattos, Lockheed Martin, USA.
Change 29.248 INVALID ARGUMENT TO SUBSTR in SYSLOG IEC205I message text
VMACTMNT in ASMTAPEE/MXGTMNT tape mount/syslog monitor SMF record.
Nov 9, 2011 Parsing to INPUT the mmm after TOTALBLOCKS=mmm into the
SYSLBLKS variable in TYPESYMT dataset expected 16 bytes
and failed when there were fewer characters for mmm. Now
the parse stops at the first blank character.
This change in format of the IEC205I message occurred
after PTF UA90604, in APAR OA90604, which included
IFG0194J, which contains message IEC205I.
The prior PTF level was UA60149.
APAR OA38051 now documents:
Unnecessary information on the third line of IEC205I
Characters *HAS will appear after spaces
and it was these unexpected characters instead of
blanks that led to this MXG circumvention change.
Thanks to Clayton Buck, UniGroup, USA.
Change 29.247 Support for ZEN FERRET, ZEN IMPLEX and ZEN OSA user SMF
EXFERSAW records from William Data Systems GmbH products.
EXZOSAEV -VMACMPLX - ZEN IMPLEX V5.1 adds two new variables
FORMATS ESMFHCMN (CPC*NAME) and ESMFHLNM (LPAR*NAME) to its
IMACFERT header (COMPATIBLY) and those variables are kept in all
IMACZOSA ZEN IMPLEX datasets.
VMACFERT -VMACZOSA. Support for ZEN OSA MONITOR V1.3 SMF record,
VMACMPLX creates TYPEZOSA dataset with separate observations for
VMACZOSA each value segment in each SMF record. All four subtypes
VMXGINIT (CHAN,LPAR,I/O,QUEUE) have the same record structure with
Nov 10, 2011 a fixed suite of OSA descriptors and one or more value
Dec 16, 2011 segments; MXG creates a separate observation for each of
the value segments in each SMF record. Variable ZOSARESC,
the resource name is EBCDIC text in the I/O and QUEUE
record, but because it is a hex string in the CHAN record
it's value is instead kept in variable ZOSARESH.
-VMACFERT. Support for ZEN FERRET V2.3. INCOMPATIBLE.
-Datasets FERRETCP, FERETEE, FERETRT datetime field was
1 changed from mm/dd/yy to ddMONyy, so prior MXG versions
will fail due to this INCOMPATIBLE change.
-Two new fields have been added to the RTP and CP data
section, a flag byte which indicates the type of history
and a field showing the transmission priority.
-Support for new Session Awareness Section creates new
FERRTSAW dataset, although some minor issues have just
been opened.
-The key section for SAW has PLU and SLU, but those
fields are also in the data segment
-Offset value to SAW is 106, but segment starts in byte
109; the offset value should be 112, and three less to
get to the SAS byte location of that offset.
Thanks to Bruce Sloss, PNC Bank, USA.
Thanks to Ronald Delp, PNC Bank, USA.
Change 29.246 If a filename in macro variable &PDB had a DASH, this
BLDSMPDB compiler error was caused when %UPCASE(&PDB) was used:
Nov 8, 2011 "ERROR: A character operand was found in the %EVAL
function or %IF condition where a numeric operand is
required. The condition was: %upcase(&runday) eq
%upcase(&pdb) and %length(&rerun) ne 0 "
because that DASH was not "masked" and was thus seen as
a mathematical minus and not a part of the filename.
This is obscure, to say the least, but SAS documents that
neither %UPCASE() nor %STR() macro functions mask special
characters, and that %QUPCASE() should be used instead.
But in this specific test, the UPCASE() was never needed
as both arguments were previously LOWCASED() which DOES
mask special characters. But the &RUNDAY EQ &PDB test
cannot be used because that dash will still look like a
minus sign, so the circumvention/re-design now uses
IF %QUOTE(&RUNDAY) EQ %QUOTE(&PDB) to mask the DASH and
successfully compile.
Thanks to Mitchell Loren, Los Angeles County Education, USA.
Change 29.245 Change 29.195 added a test TMSCTL=:'TMSCTL#' to protect
VMACTMS5 when a non-TMC file is read, but that PoundSign was not
Nov 8, 2011 recognized with some character sets, so the test is now
shortened to TMSCTL='TMSCTL' to avoid a false positive.
Thanks to Akre Trond Maurita, EDB, NORWAY.
Change 29.244 Support for TMON/CICS V3.3 (mostly COMPATIBLE) TCE data.
VMACTMO2 -TMON/CICS V3.3 increased MRO's TAMRSYID field from 4 to 8
Nov 10, 2011 bytes, to hold the IPIC CONNID. Unfortunately, while MXG
does use segment length to keep aligned with each of the
repeated MRO segments, inserting 4 bytes (instead of new
8 bytes at the end) shifts/trashes the TAMRxxxx variables
in the MONIMRO dataset due to this INCOMPATIBLE change,
but there are no error messages nor condition code set,
so V3.3 is INCOMPATIBLE ONLY IF YOU USE MONIMRO dataset;
MXG Version 29.07 is required for V3.3 only for MONIMRO.
And, fortunately, MONIMRO is very rarely used in reports.
TMON records with earlier MXG versions will not cause
errors nor ABENDS, just bad data in one seldom used
-TAMRFLG1 and TAMRFLG2 fields are listed in V3.3 as new
but were previously input and kept in MONIMRO dataset.
-The DSECT for the header showed an optional, inserted
40-byte extended-common-header segment, that would have
made all V3.3 records incompatible, but, fortunately,
that segment will NOT exist in V3.3 records. And, more
fortunately, MXG is updated to support its existence, so
if/when it appears in a future record, it won't be an
incompatible change.
Change 29.243 Calculation of ESTSCP1M had (0.57*(0.1*RNI)) but that was
ASUM113 a typo, now corrected to (0.57+(0.1*RNI)). MXG's error
VMAC113 caused very small values in ESTSCP1M.
Nov 2, 2011
Thanks to Dave Cogar, Wells Fargo Bank, USA.
Change 29.242 ONLY if executing MXG on ASCII, and ONLY if MXG default
VMAC102 option COMPRESS=YES was changed to COMPRESS=NO (which
Nov 1, 2011 causes SQL text to be broken into 100 byte chunks that
Nov 3, 2011 are output in dataset T102T14x instead of T102S14x), the
DB2 Audit variables QW0140TX,QW0141TX,QW0142TX,QW0145TX
were only readable text in the last segment or if there
were less than 100 bytes of SQL text, because MXG's logic
for this "chunking" algorithm was written long ago and it
was only validated back then on z/OS. MXG INPUT those
fields with $EBCDIC100, but that INPUT should have been
with $CHAR100, and then the INPUT function with $EBCDIC
informat does that translation to readable text.
And variable QW0124T's INPUT was also corrected.
Thanks to Lars Fleischer, SMT Data, DENMARK.
Thanks to Jorgen Lund, SMT Data, DENMARK.
Change 29.241 The example to split SMF records into 5 groups output DB2
JCLSPLIT ID=102 records in "B" DB2 output file, and then failed to
Oct 28, 2011 add 102 to the NOTYPE list in the "E" group (ALL OTHER),
so all 102s were output in both "B" and "E" output files.
The 102 is now added to the NOTYPE list in "E".
Thanks to Jennifer D. Ayers, WVOT Data Center, USA.
Change 29.240 The length of new variable SM1209FH could not be changed
VMAC120 as described in Change 29.081. That text was rewritten.
Nov 8, 2011
Change 29.239 Variable SHIFT (also used as "ZONE") is now created in
VMAC7072 all of the RMF datasets, from STARTIME.
VMAC71
VMAC73
VMAC74
VMAC75
VMAC76
VMAC77
VMAC78
VMAC79
Oct 27, 2011
Thanks to Frank Lund, EDB ErgoGroup, NORWAY.
Change 29.238 Change 25.142 and Change 28.211 identified USER SMF
VMACARB VMAC's using "MACRO _xxxxID nnn%" instead of "MACRO
VMACDLMN _IDxxxx nnn%" but those changes did not revise those
VMACDMON members to use the more-recent-and-preferred _IDxxxx
VMACHURN syntax. All VMAC's are now updated to support both forms
VMACM204 of the _ID macro to tell MXG what SMF record number to
VMACNSPY process as product xxxx, but only to be consistent, just
VMACPDSM in case we needed to generate them internally in MXG.
VMACRMDS Note that using UTILBLDP is recommended to read multiple
VMACROSC SMF records, and by using it's USERADD=xxxx/nnn argument
VMACRTE set the SMF IDs, you do not need the _ID definitions in
VMACTSOM your IMACKEEP tailoring.
VMACVVDS -But some inconsistencies in _IDxxxx macron names exist:
VMACWYLA Arbiter can write each of its subtypes with a separate
VMACWYLB SMF record ID (_IDARB00-IDARB0C).
VMACX37 VMACM204 has _IDM204L and _IDM204S for Log/Since-Last.
Oct 26, 2011 VMACTSOM has _IDTSOMC and _IDTSOMS for Command/System.
VMACHSM has _IDHSMDS and _IDHSMD1 for Daily/FSR Stats.
VMACHBUF was in 25.142 but had been updated to _IDHBUF.
VMACWYLB was in 25.142 but had been updated to _IDWYLB.
Change 29.237 The calculation of ZIPUSED and ZIEUSED did not include
ASUMMIPS the divide by CAPZIPRT*100.
Oct 24, 2011
Thanks to Bernhard Bablok, Allianz Managed Operations, GERMANY.
Change 29.236 SMFSRCH is a VERY slick new tool to print all SMF records
COMPALL that contain a specific "LOOKFOR" character text string.
COMPALLN All SMF records are scanned for the "LOOKFOR" text
SMFSRCH - using IF INDEX(_INFILE_,"LOOKFOR") syntax -
TYPESMF and selected SMF records are written to the temporary
VMXGGETM DDNAME/filename of MXGTEMP, from where TYPESMF program
VMXGPRAL reads them to create every possible MXG dataset that can
VMXGSRCH be built from SMF records, including "USER" SMF records.
Nov 11, 2011 Then, ONLY the observations in those datasets that have
a variable containing the "LOOKFOR" text are printed.
(This extra filtering is needed because some datasets
created from the selected records won't contain that
"LOOKFOR" text. Consider if LOOKFOR=USERID, TYPE 30-4
records with that USERID will be selected and TYPE30_D
dataset will have many observations, one per DD name,
but the USERID field is not kept in dataset TYPE30_D,
so this final filtering prevents those unwanted "false
positive" observations from being printed.)
The selected SMF records can be kept by making //MXGTEMP
a permanent dataset, and the selected MXG-created SAS
datasets can also be kept.
-The //MXGTEMP DD may need to be added to your JCL.
-SMFSRCH creates all possible datasets that can be created
from IBM or USER SMF records. IBM fixed-numbered records
are automatically output, but only the USER SMF records
that have a "MACRO _IDxxxx nnn % definition in IMACKEEP
or in IMACxxxx will create observations (BUT: you can use
the USERADD=xxxx/nnn argument to tell MXG the nnn you use
for product xxxx and those datasets can be populated).
-SMFSRCH reports the counts/sizes of SMF records input and
selected, and maps USER SMF records to their product if
the_IDxxxx macro was found.
-New parameters added to VMXGGETM, used in new SMFSRCH:
BEGTIME= earliest datetime to be selected
ENDTIME= latest datetime to be selected
INCODE= A stub of code executed after the header
is read
LOOKFOR= text string to be searched in each SMF record
-TYPESMF executes all TYPExxxx member that read any SMF
records, reading SMF once for each TYPExxxx member, so
it is only used in SMFSRCH to read the selected records.
-VMXGPRAL's TITLE "PRINT OF FIRST MAX OBS.." corrected.
Thanks to Jeffrey Dyke, USDA, USA.
Change 29.235 Change 29.125 (MXG 29.05-29.06) corrected DB2 IFCID=22
VMAC102 error with DB2 V10, but did not work for DB2 V9. And, in
Oct 19, 2011 testing this update the T102I022 dataset was found to be
in serious need of realignment.
Thanks to Tom Buie, Southern California Edison, USA.
Change 29.234 Cosmetic. Messages that EXCLUDED FIELDS are revised to
VMAC110 print the value of the triplets (dictionary records) that
Oct 19, 2011 are defined in your IMACEXCL tailoring, to make it easier
to see that your UTILEXCL missed a dictionary record.
Change 29.233 Support for BETA93 Version 4.1.0: Subtype 25 was changed,
VMACBETA with fields removed, causing wrong or missing values in
Oct 18, 2011 dataset BETA25, plus INVALID DATA FOR BETASTRT messages.
These variables are now missing/blank with 4.1.0:
BETACPU BETAELAP BETAEND BETAETKN BETALTKN
BETAOWNR BETARTKN BETASTRT BETAVIOR BETAVIOW
Additionally, missing value messages for some datetimes
are circumvented by testing DATE GT 0 before calcs.
Thanks to Michael Brenning, Finanz Informatik, GERMANY.
Change 29.232 DFSORT variables ICEMNVLX,ICEMNVLY, and ICEMNVLZ are not
VMAC16 documented as to their units, but data shows they are in
Oct 15, 2011 KB and not Bytes, so they are now multiplied by 1024 to
Oct 25, 2011 convert to bytes, and then so MGBYTES format will print
16M rather than 16K previously printed. IBM has privately
verified that the units are 16M and plan to update their
DFSORT documentation to show the units attribute.
Thanks to Neil Ervin, Wells Fargo Bank, USA.
Change 29.231 Support for Axway CFT/ESA (Cross File Transfer) two SMF
EXAXWAY record formats ("2.3" and "2.4" but "2.3" format records
FORMATS (8-byte vs 32-byte fields) are created/creatable with the
IMACAXWY current CFTMON 2.6.4. As there is no version number and
TYPEAXWY the two records have same length, three one-byte fields
TYPSAXWY that must be blank in 2.4 are used to identify version of
VMACAXWY the record. The 2.4 code with 32-byte fields is INPUT
VMXGINIT first so the kept variables will be the longer length.
Oct 15, 2011
Nov 17, 2011
Thanks to Richard Wendland, US Bank, USA.
Thanks to Claude Breault, Centre de Services Partages Quebec, CANADA.
Change 29.230 Comparison of BMC IMF FA and IBM 56FA IMS Log records.
ASUM56FA -Variable IMSRECCH added to CIMSTRAN to capture that IMS
EXIMS56C log sequence number at the end of each IMS log record; it
FORMATS was already in IMF56FA. In TYPECIMS variable IMSRECNR is
IMACIMS the _N_ sequence number and is NOT input from the record.
TYPEIMST -IMS56FA records are written as pairs for a single IMF FAx
VMACCIMS log record. The pair have the same ARRV and STRT times,
VMACIMS and are written 5 milliseconds apart at transaction end.
VMXGINIT -See the new IMS Technical Note in NEWSLETTER FIFTY-NINE
Oct 11, 2011 for a detail explanation of what is captured in IMS56FA
Oct 21, 2011 transaction event records, and a comparison with IMF.
Oct 27, 2011 -ASUM56FA program (still in testing) is added to MXG.
Change 29.229 -Variable TPMCA7JN is now input &PIB.2. + 2 versus &PIB.4.
VMACTPMX -Variable TPMPI was decimal 243 for 'F3'x which is EBCDIC
Oct 11, 2011 numeric/character three. INPUTing TPMPI as $EBCDIC1 would
Oct 15, 2011 create a character variable with value '3', but TPMPI is
a numeric variable, so the field into TPMPICH $EBCDIC1.,
but then TPMPI=INPUT(TPMPICH,1.); will preserve TPMPI to
remain a numeric variable, but with value 3 versus 243.
-Datetime variable TPMDUEOT is now correctly populated but
that variable can have a missing value.
Thanks to Tren Csuy, Humana, USA.
Thanks to Scott Barry, SBBWorks Inc, USA.
Change 29.228 Variables SMF30SNF and SMF30ZNF, the zAAP and zIIP
BUILD005 factors that were used to normalize those Engine's CPU
BUIL3005 time are now kept in PDB.JOBS. This updates Change
Oct 11, 2011 28.139.
Nov 17, 2011 Nov 17: (DROP=_26NJE) was added to DATA TYPE26J2 to
ensure dropping of those NJE variables from PDB.JOBS,
if those variables were still somehow in SPIN26.
Thanks to Jim S. Horne, Lowe's Companies, USA
Change 29.227 -Revised code to read HP MeasureWare NT records with new
VMACMWNT fields added in GLOG record:
Oct 8, 2011 PKDSKPCT='PEAK*DISK*PERCENT'
PKDSKTIM='PEAK*DISK*TIME'
and with the MXG code restructured to match the changed
fields in the REPORT command used to extract the data.
-DDMMYY8 format revised to DDMMYY10 for those dates.
Thanks to Frank Tonneau, KBC Global Services NV, BELGIUM.
Thanks to Geert Debatselier, KBC Global Services NV, BELGIUM.
Change 29.226 False ERROR.TYPE1415.DEFECTIVE EXTENDED INFO SEGMENT
VMAC1415 could print for a record without an Extended Segment. MXG
Oct 7, 2011 code now tests SMF14XSG first to validate existence.
Thanks to Herbert Sweeney, Verizon Data Services, USA.
Change 29.225 INVALID THIRD ARGUMENT OF SUBSTR message and hex dump of
VMACDB2 the record was caused by DB2 V10 record with INVALID QMDA
Oct 7, 2011 segment for QMDAPTYP='JCC' - invalid because it does not
match the DSNDQMDA DSECT in the DB2 Macro Library. Now,
the first three records are detected and MXGWARN messages
are printed on the log, while a PMR will be opened.
Thanks to Kim Morrell, RCMP, CANADA.
Change 29.224 -Utility VMXGGETM selects SMF records for counts or to be
VMXGGETM written, and is enhanced with new arguments SYSTEM=,
Oct 3, 2011 BEGTIME=, and ENDTIME=, to select SMF records by SYSTEM
Oct 24, 2011 and/or ranges of SMFTIME values. This could alternately
be done with the powerful but obscure %LET MACFILE= logic
(the "instream" equivalent of IMACFILE EDIT tailoring).
-LOOKFOR=text, added: selects SMF records with that text.
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 29.223 Support for APAR OA37114, ITRF (OMEGAMON IMS V420 TRF)
VMACITRF TRFOUT record adds five new variables (COMPATIBLY) that
Oct 2, 2011 are output in MXG dataset ITRFMSG.
MI ='SPA*INDICATOR*PSTMI'
MSRC ='MESSAGE*SOURCE*FLAG*PSTFLAG1'
SCHF1 ='QUICK*SCHEDULED*PSTSCHF1'
SPAL ='CURRENT*SPA*SIZE'
VSFLG ='PRIMED*MSG*INDICATOR*PSTVSFLG'
Change 29.222 New tokenid values are now decoded in TYPE80A:
VMAC80A TOKMEMLI='MEMLIMIT'
Oct 2, 2011 TOKSHMEM='SHMEMMAX'
These "NO" value tokens have no data values so they are
output in TYPE80TK with their TOKDANAM to record that the
option was in effect, suppressing a NOT DECODED message:
NOCPUTIMEMAX NOFILEPROCMAX NOPROCUSERMAX NOTHREADSMAX
NOMMAPAREAMAX NOASSIZEMAX
Thanks to Angelito Lontoc, Northern Territory Government, AUSTRALIA.
Change 29.221 -CICS Statistics dataset CICDB2GL fields that were not
FORMATS identified as new were overlooked, but are now added:
VMAC110 D2GPSIGN='PARTIAL*SIGNONS'
Oct 3, 2011 D2GCTHCR='COMD*THREAD*CREATES'
Oct 16, 2011 D2GPTHCR='POOL*THREAD*CREATES'
D2GREHIT='REUSELIMIT*HIT*COUNT'
-Statistics Dataset CICSMDSA variable SMSDSAIN indexes the
type of DSA, but values of '00'x have been found for RDSA
EUDSA, and ERDSA, so the SMSDSANM (DSA Name) is used to
set their value in SMSDSAIN to '04'x, '86'x, and '08'x
when '00'x is found, and the FORMAT $MGCICDS (which maps
SMFDSAIN to the name of the DSA) is updated with values
'09'x (ECDSA), '8D'x (GCDSA) and '7F'x (ESDSA) that were
undocumented in the CICS Data Areas. Variable SMSDSAIN
existed before variable SMSDSANM, the actual DSA Name, so
with these undocumented and '00'x values in SMSDSAIN, the
variable SMSDSANM should be used instead of SMSDSAIN to
identify which DSA name is being reported in CICSMDSA.
-The CICSMDSA variables for "ABOVE THE BAR" storage were
wrong; they are in (undocumented, but now obvious) units
of 1 GB, so they are now converted to bytes and formatted
with MGBYTES to print the correct storage values:
NOTE: ABOVE WRONG, THEY ARE IN MB NOT GB. CHANGE 30.094.
These variables are DSA-specific and corrected:
SMSDSASZ SMSHWMDS SMSCSIZE SMSFSTG SMSHWMFS SMSLWMFS
SMSLFA
These variables are in the header of the CICSMDSA record
and thus repeated in each observation for the interval,
but are also corrected:
SMSGDCUL SMSGDHWL SMSGDCUR SMSGDHWM
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 29.220 Support for z/OS 1.13. REQUIRES MXG 29.03 or later.
VMAC7072 -VMAC7072. IBM now stores 'FF' character ('C6C6'x !) for
VMAC71 the CPUID (SMF70CID) for engines that don't exist in the
Mar 24, 2011 CPU Data Section, which MXG saw as 50886 decimal, which
VMAC23 caused ARRAY SUBSCRIPT OUT OF RANGE error. MXG logic
Apr 2, 2011 relocated the initialization of the two arrays that used
VMAC113 CPUID as the subscript, and created a DO group to only
VMAC6 process the CPU Data Sections with valid CPUID number.
VMAC42 -VMAC71. TEST for OFFSWAP GE 0 AND NRSWAP GE 0 caused
VMAC64 INPUT STATEMENT EXCEEDED. That test should have been GT
Sep 30, 2011 for a long time (since SWAP datasets went away!!).
Accidentally didn't fail with prior z/OS but was wrong.
Cosmetic: SWAPAUX calculation was moved back inside the
DO group for (now non-existent) SWAP counts so that it
doesn't cause a Missing Values message.
-VMAC23. Two new triplets are decoded, for the new Spin
Lock and Bind Breakdown Instrumentation sections, but
both are currently "For Internal Use Only".
-VMAC6. The Reserved 16-bytes in SMF6INDC=7 Extended Mode
segment contains SMF6IPV6, currently just input and not
kept nor decoded. SMF6URIL, added by OS25152 is not in
the Pre-GA SMF Manual.
-VMAC42. New variables added to several datasets:
SMF42GRU='READ REQS*RETRIED FOR*CASTOUT*LOCKS'
SMF42GRJ='READ REQS*RETRIED FOR*CASTOUT*LOCKS'
SMFA2GRJ='READ REQS*RETRIED FOR*CASTOUT*LOCKS'
SMFA2GRU='READ REQS*RETRIED FOR*CASTOUT*LOCKS'
SMF42JQ2='READ REQS*RETRIED FOR*CASTOUT*LOCK'
SMF42JRC='READ REQS*RETRIED FOR*CASTOUT*LOCKS'
SMFA2JQ2='READ REQS*RETRIED FOR*CASTOUT*LOCK'
SMFA2JRC='READ REQS*RETRIED FOR*CASTOUT*LOCKS'
These fields were added by APAR OA30300.
-VMAC64. New variable added to TYPE64:
SMF64RLM='CA-S*RECLAIMED*IN ESDS*SINCE CLOSE/EOV'
-VMAC7072. New ID=72 Subtype 5 adds 13 new datasets:
dddddd Dataset Description
TY725A TYPE725A RMF III SERIALIZATION DELAY
TY725B TYPE725B RMF III CMS LOCK DELAY
TY725C TYPE725C RMF III CMS ENQUEUE DEQUE LOCK DELAY
TY725D TYPE725D RMF III CMS LATCH LOCK DELAY
TY725E TYPE725E RMF III CMS SMF LOCK DELAY
TY725F TYPE725F RMF III LOCAL LOCK DELAY
TY725G TYPE725G RMF III CML LOCK OWNER DELAY
TY725H TYPE725H RMF III CML LOCK REQUESTOR DELAY
TY725I TYPE725I RMF III GRS LATCH SET CREATOR DELAY
TY725J TYPE725J RMF III GRS LATCH REQUESTOR DELAY
TY725K TYPE725K RMF III GRS ENQUEUE STEP DELAY
TY725L TYPE725L RMF III GRS ENQUEUE SYSTEM DELAY
TY725M TYPE725M RMF III GRS ENQUEUE SYSTEMS DELAY
-VMAC7072. New variables added to TYPE70XT dataset:
R7023CRT='EXEC TIME*ALL OPS*4096-BIT*CRT-FMT'
R7023CRC='NUMBER OF*ALL OPS*4096-BIT*CRT-FMT'
-VMAC71. New variable added to TYPE71:
SMF71LFA='LARGE*FRAME*AREA*SIZE'
All Logical Swap and ESTORE variables are now reserved.
-VMAC113. New variables added to TYPE113
SM1132MM='MACHINE*MODEL'
SM1132MT='MACHINE*TYPE'
Change 29.219 Support for Tivoli Workload Scheduler For z/OS Ver 8.3 is
FORMATS completely incompatible with numerous changes to many of
IMACOPC the tracklog file's records.
VMACOPC -The _OPCVER macro is no longer used, since this update
Sep 24, 2011 supports the current version. However, it may have to
Sep 27, 2011 be reinstated in the future since IBM still does not
Nov 14, 2011 provide the version number in each record.
-There are numerous instances in different MT0TYPE records
that end with a 4-byte field of hex zeros where the next
MTDTYPE/MTDOPER pair were expected. Probably APAR-able,
but it was more expeditious to detect and delete them in
MXG than to take the time to document them for a PMR.
-Invalid TRL 29 record caused INVALID ARGUMENT messages;
the internal %DT macro now tests the incoming arguments
and if the date or time is missing, RETURNs, preventing
those cosmetic messages. With or without those messages
the date values returned were and are missing values.
-Nov 14:
This is not a used record type so the error will not
be pursued until a customer who actually needs this
record type raises the issue.
-There are one new MTD segment, MTDTYPE=16 that is not
not documented in SC32-1261-03.
-MTD17 segment is decoded.
Thanks to Louis Deledalle, BNP Paribas, FRANCE
Change 29.218 Variable CNT30REC is added to PDB.STEPS dataset to count
BUILD005 the number of physical SMF 30 records created for this
BUIL3005 step (which were all consolidated into this observation).
Sep 22, 2011
Change 29.217 Corrected and improved support for the RCDSD section in
ASMRMFV RMF III RCD data is provided.
VMACRMFV -ASMRMFV now correctly calculates the length of the RCDSD
Sep 20, 2011 array that before could cause a SAS INPUT LENGTH ERROR in
Sep 27, 2011 VMACRMFV processing.
Nov 2, 2011 -ASMRMFV now correctly handles an RCDSD when a Class with
Nov 20, 2011 zero periods is detected. An RCDSD cannot exist in this
EXZRBRCP case because the RCDSD pointer is part of the period data
NOV 13, 2013 -VMACRMFV formats for the variables RCDRGCAP and RCDRCGD
were reversed.
-New variables RCDBPMI and RCDSDPH are added to the
ZRBRCDD file by VMACRMFV.
-VMACRMFV now reads both the Begin-To-End and Execution
Phase data for each RCDSD entry. Current documentation
for RMF III did not clarify that each RCDSD entry is
actually a pair of arrays for these two Phases.
-ASMRMFV when processing a CFI Table with the RMF III
CFDETAIL option in effect, did not correctly handle the
condition where no connections exist for a CF Structure.
This resulted in a corrupted CFI Table record and an SAS
INVALID DATA message during VMACRMFV processing.
-When the number of records output for a RMF III table
exceeded 16,277,215 the output record counter in ASMRMFV
would wrap to zero resulting in a very low incorrect
count for that table type. The total record count output
by ASMRMFV would then not match the input record count
from VMACRMFV.
-VMACRMFV did not count the 4 byte RDW (Record Descriptor
Word) in its report of bytes read but ASMRMFV did. Now,
the RDW length is added so that the VMACRMFV byte count
matches the ASMRMFV byte count. However, as neither
ASMRMFV nor VMACRMFV knows how many blocks were written,
both byte counts will not include the 4-byte BDWs (Block
Descriptor Word) for each block.
-The RMF Monitor III version id variable names are now
more consistent with the naming pattern of xxxVERG3.
RCDVERS is now RCDVERG3 (RCD version id). OPDVER is now
OPDVERG3 (OPD version id). SPGVER is now SPGVERG3 (SPG
version id).
-A new variable SVPRTC (Response Time Unit Code) is added
to files with Service Policy data. It is the decoded
value of SVPRTU. This indicates the response time units
for a goal. Values are I=Milliseconds, S=seconds
M for Minutes, H for Hours, and ? for Unknown.
-Added SPACE/NOSPACE parameter option:
-SPACE displays two new messages RMFV030I and RMFV031I
for each RMF Monitor III VSAM data set processed.
-Message RMFV030I shows HARBA (High Allocated Relative
Byte Address), HURBA (High Used Relative Byte Address),
and AVAIL (Available Free Space in Bytes).
-Message RMFV031I shows percent of Allocated Space Used
and percent of Allocated Space Available (Free).
-Both standard & extended format (EF) VSAM data sets are
supported, but RMFV030I message format varies slightly
to accommodate the much larger data sets possible in EF
mode.
-Assembler symbolic variable &SPACE can be changed by
users prior to assembly from the distributed default of
'Y' (SPACE in effect) to 'N' (NOSPACE in effect).
-In conjunction with the existing INDEXES parameter SPACE
is intended to assist MXG users in properly sizing their
RMF Monitor III data sets.
-Program prologue comments documentation was updated.
-Nov 20, 2011:
Change 29.204 (29.05) changed these version variables
PGPVERG3 CPDVERG3 CPUVERG3 CSRVERG3 CFIVERG3 ENCG3VER
OPDVERG3 SPGVERG3 CPUVERNU SVPDVN SVPRTU
from NUM to CHAR, which would create errors combining
PDBs built with different MXG Versions, so they are now
changed back to their original numeric nature. This code
change was NOT in MXG 29.07 dated Nov 14.
-Nov 13, 2013: Exit member EXZRBRCP is no longer called
as ZRBRCP dataset is no longer output, because ZRBRCS and
ZRBRCR now include ZRBRCP variables.
Thanks to Neil Ervin, Wells Fargo Bank, USA.
Thanks to Dan Case, Mayo Clinic, USA.
Change 29.216 Cosmetic. The comment in JCLIMSL6 that two %LETs are
JCLIMSL6 needed to set MACKEEP with _IMSVERS was wrong, as it is
TYPEIMSB only in the STEP04 step that the _IMSVERS must be set.
Sep 19, 2011 In TYPEIMSB, the %INCLUDE of VMACIMS and IMACKEEP and
the comment "to get _IMSVERS" was removed because that
program has no dependency on any of the IMS macros.
Thanks to Trevor Ede, HP, NEW ZEALAND.
Change 29.215 Variables T119STCK, TISSTCK and TIESTCK weren't converted
VMAC119 from GMT to LOCAL, but now are.
Sep 19, 2011
Thanks to Robert Stoffregen, Great Lakes Higher Education Corp., USA.
Change 29.214 Almost cosmetic. In subtype 2 (TYPE78PA dataset) eight
VMAC78 variables ending with TOTL were mislabeled as samples but
Sep 19, 2011 they are the total memory for all samples, so they are
now correctly labeled and added to MGBYTES format to show
they contain memory values. Variables LGMOMIN/TOFRMIN are
RB8 floating point fields, but they can contain hex value
7FFFFFFFFFFFFFFFx (presumably on systems that don't have
large memory frames), so they are now set missing (rather
than decimal values 7.237E75!). Some datetimestamps are
no populated (hex zeros for TODSTAMP8), so they are set
to a missing value (automatically, by SAS).
Thanks to Tony P. Steward, CSC, ENGLAND.
Change 29.213 Support for DB2 V10 IFCID 225 (Subtype=4) INCOMPATIBLE.
CLEARDB2 The IFCID 225 record contains important storage metrics,
EXDB2225 and is written each statistics interval. In DB2 V8, it
READDB2 was a trace record (ID=102,IFCID=225), creating T102S225
VMACDB2 dataset. In V9, it became a statistics interval record
VMXGINIT (ID=100,SUBTYPE=4) creating DB2STAT4 dataset, but with
Sep 20, 2011 the same suite of 8-byte field/MXG-variable names, and
Sep 23, 2011 because it was then recognized as useful, those QW0225xx
variables were added transparently into PDB.DB2STATS from
either DB2 V8 T102S225 or DB2 V9 DB2STAT4 datasets.
But now, DB2 V10 completely and incompatibly restructured
(but also significantly enhanced the storage metrics) in
the IFCID=225 record, still writing it as SUBTYPE=4, with
some fields preserved, but with many new fields with long
names, that I now use for MXG variable names, rather than
struggling to create unique two-character suffixes and
8-byte names (but two new prefixes are needed for the new
separate storage used by DBM1 & DIST address spaces, so
those sets of variable's names are QWA225xx/QAB225xx.
-For DB2 V10, IFCID=225 records are output in PDB.DB2ST225
dataset, and all variables in DB2ST225 are automagically
merged into PDB.DB2STATS dataset with all these programs:
TYPEDB2/TYPSDB2/BUILDPDB/READDB2(IFCIDS=STATISTICS).
-With DB2 V10, the PDB.DB2STAT4 dataset will have zero
observations from DB2 V10 data, since it is populated
only from DB2 V9 IFCID=225 records.
-Test data from the same DB2 Subsystem (QWHSSSID), when
the release changed from V8 to V10, had negative CPUTM in
that statistics interval, because there is no field in a
DB2 Header that clearly identifies when a DB2 subsystem
is started (i.e., unlike CICS records, that have the JOB
and READTIME). Normally, a restart resets QWHSISEQ to a
smaller value, but in this case, that sequence number was
larger in the V10 record than the prior V8 record! So,
MXG now tests both QWHSISEQ and SEQCHECK to circumvented
the IBM omission. That SEQCHECK test in the "bad" data
interval did identify the problem, so the previous test
of SEQCHECK GT 0 was enhanced to 0 LT SEQCHECK LE 5 to
confirm the inteval is valid with no restart.
Thanks to Betty Wong, Bank of America, UDS.
Change 29.212 Invalid JES3 JMF SMF 84 Subtype 1 Segmented Records.
VMAC84 After long discussions with JES3 SMF 84 Support Folks, I
Sep 16, 2011 understand how JMF creates multiple, segmented records
Oct 11, 2011 when there are more entries (FCTs) that will fit in one
SMF record. I can probably circumvent the absence of the
JMF PROD section (source of start/end times!) that is NOT
written in the 2nd and subsequent segments, but ONLY if I
add post-processing steps to sort and to populate those
missing values, and ONLY if there are no missing segments
in the SMF file.
-BUT, there is NO WAY that I can directly process each of
these segmented records, because sections (FCT ENTRY) are
truncated and split (a/k/a "spanned" in JES3 circles) and
written in two separate physical SMF records, but there
are no length fields to identify how many bytes were in
which record.
-Processing these JMF segmented records will require a new
MXG design, to first reconstruct legitimate VB records
without truncated sections, and then process those SMF
records in a separate process. I get to do this because
IBM regards this as "working as documented".
-But, fortunately, JMF records are not typically created
every day; they tend to be turned on and then off for a
study, so we can live with waiting a day to process all
of the JMF records from a study. And, this one very
small glitch in just one part of one subtype of the VERY
comprehensive JES 3 Monitoring Facility is now bypassed,
so all the rest of the JMF datasets are fully usable,
all of the other segments of this subtype 1 record, and
even those first 78 FCT entries are output; MXGWARN notes
on the SAS log alert you there were FCT segments missed.
-The specific case investigated: There were more FCT than
would fit in one SMF record. FCT entries are variable
length sections with many optional subsections. JMF
created 4 physical SMF records, segment numbers 1-4:
-The First segment has JMF PROD, JMF GENE, R84JES3O and
R84IRBSC offsets populated and has no FCT entries.
-The Second segment doesn't have JMF PROD nor JMF GENE
(needed for Interval Start and End times), and has only
R84FCTO, which points to a valid FCT "Header" section
(but R84FAWLN is the TOTAL length of all FCTs, and in
R84FCTN=250 is the total count of all FCTs in all segs;
what's needed here is how many FCTs are in THIS record!
This second segment then contains 78 complete FCT entry
sections, with R84FSEQN 1 thru 78, but then, only the
first part of FCT number 79 was written in this SEGNR=2
SMF record: the last 72 bytes were truncated.
-The Third segment also has no JMF PROD nor GENE sections
and does NOT contain an FCT Header section; it contains
only FCT entries, but it's data area STARTS with those
last 72 bytes of FCT entry number 79, and then FCT entry
number 80 thru 187 are contained in this SEGNR=3 record.
-Finally, the Fourth Segmented Record is like the third,
no PROD/GENE/FCT Header, only FCT entries, but its data
area (happens?) to start with FCT Entry R84FSEQN=188's
byte one, and then FCTs 189 thru 250 are complete in the
SEGNR=4 JMF record.
-Unrelated to the above issues, truncated subtype 2
records were discovered; IBM APAR OA37982 is now open to
correct that error.
Thanks to Lucy F. Trabulus, Bank of America, USA.
Change 29.211 Support for Throughput Manager APAR TMT6214, corrects the
VMACTPMX invalid subtype 16 triplets when there were more than 76
Sep 21, 2011 steps in a job. Those invalid triplets caused the ERROR:
INPUT STATEMENT EXCEEDED RECORD. The APAR corrects the
error by creating multiple "continuation" records when
when there are more than 76 steps, and installing their
APAR eliminates the INPUT STATEMENT EXCEEDED ERROR.
A new version of MXG is NOT required to support the APAR.
But, to create observations in TPM16J dataset, you need
Change 29.200, in MXG 29.06, to correct an unrelated MXG
coding error that caused zero observations to be created.
And, job-info variables were only added to the TPM16J
dataset by THIS change, which will be in MXG 29.07, or
can be requested now via email from support@mxg.com).
-Support for Subtype 5 PCS segment is added, with those
variables added to the existing TPMSLM dataset when the
PCS segment is present. The variable names are taken
verbatim from the DSECT, so most are longer than the old
8-byte ASM DSECT field names.
Change 29.210 The spelling of most variables available in this header
IHDRTMVS exit for selection were wrong. And, variable LMRKJOBC is
VMACTMVS NOT the JOB name of the Landmark Monitor for z/OS, but is
Sep 14, 2011 the SYSTEM ID of that system, so it's label is corrected,
and it can be used to select by SYSTEM.
Thanks to Sam Bass, McLane Co., USA.
Change 29.209 DB2 V10 ID=100 SUBTYPE=1 with INVALID HEADER caused INPUT
VMACDB2H EXCEEDED RECORD LENGTH error. The defective record had
Sep 14, 2011 0122x (290 decimal) for the offset to the un-truncated
QWHSOPID field, with that QWHSTYP=2 starting in byte 5375
but 5375+290=5665, while the LENGTH of the data portion
was only 5534 bytes. Protection for this invalid header
field has been added for all of the "untruncated" fields
in the QWHSTYP=2 Header segment. IBM might be contacted.
Thanks to Tom Pierce, LabCorp, USA.
Change 29.208 IBM i-Series (AS400) with more than 32 CPUs create two
VMACQACS records in QAPMSYSC dataset (IBM "QAPMSYSCPU") for each
Sep 14, 2011 interval, with the first 32 engines in the first record
and the second 32 engines in the second record. You must
now invoke the _SQAPSYC macro after your _TQAPSYC macro
when you read the QAPMSYSC infile:
%INCLUDE SOURCLIB(VMACQACS);
_TQAPCON
_TQAPSYC
_SQAPSYC
as the _SQAPSYC macro now sums those two records to
create a single observation per interval, with the
(corrected) PCTCPUBY percentage, and the new variable
SCPUSUM with the total CPU time for all online engines.
Thanks to Karen Florup, Bank of America, USA.
Change 29.207 MONWRITE Broken Control Record error due to incomplete
VMACVMXA decoding of the 2.14 (SCLALL) Schedule Domain record.
Sep 13, 2011 The error message gives no clue the cause is the 2.14.
This is the first MONWRITE file in a long time that had
SCL (Schedule) domain records enabled; they are rarely
turned on due to large volume, and provide low-level
trace-like event data that requires pretty deep knowledge
of z/VM internals to be useful, but now they too are
supported.
Thanks to David J. Schumann, Blue Cross of Minnesota, USA.
Change 29.206 Cosmetic. VMXGSUM now dies gracefully with an MXGERROR:
FORMATS message if there is no input dataset to process.
VMACEDGR
Sep 13, 2011
Thanks to
Change 29.205 Cosmetic. New format MGEDGCF decodes variable COMEFROM
FORMATS to identify which variable will be missing when invalid
VMACEDGR dates (e.g., 2000/000) are found in RMM records.
Sep 13, 2011
Thanks to
====== Changes thru 29.204 were in MXG 29.06 dated Sep 8, 2011========
Change 29.204 -Support for RMF III RCD data, promised in Change 29.187,
EXZRBRCX is now completed. The new ZRBRCDX dataset contains the
IMACRMFV Response Times for Reporting Classes and the existing
VMACRMFV ZRBRCDT datasets is updated with Response Times for the
VMXGINIT Service Classes.
Sep 7, 2011 -BY lists BZRTRCS/RCR/RCP/RCD were revised.
Sep 13, 2011 -Cosmetic changes, PCT, Version, etc.
Change 29.203 The labels for variables PC24RHWM and PC24SHWM for the
VMAC110 "Below 16MB" areas had ERDSA and ESDSA but those labels
Sep 7, 2011 should have been RDSA and SDSA.
Thanks to Steven Kimball, Aetna, USA.
Thanks to Victoria Lepak, Aetna, USA.
Change 29.202 The _IDEDGSA macro default value should be 512 but it was
VMACEDGS left with 8Ax (138) after a test with user's data, and if
Sep 7, 2011 you have an ID=138 record in your SMF file, JCLTEXTx will
fail (INPUT STATEMENT EXCEEDED).
Thanks to Walter Noniewicz, State of Connecticut, USA.
Change 29.201 -Support for DB2 V10 restructured IFCID=217 record, which
VMAC102 caused T102T217 and T102U217 to have zero observations,
Sep 7, 2011 but (fortunately) the incompatible record format did NOT
cause an execution error. Dataset T102S217 now has only
one unique variable, and new QW0217AL and QW0217AS ASIDs
were added to T102T217 & T102U217 datasets respectively.
Dataset T102V217 always has zero observations (after V8).
-Unrelated, many offseg+lenseg LE LENGTH segment tests are
corrected to offseg+lenseg-1; the incorrect test could
have prevented reading legitimate segments.
Thanks to Betty Wong, Bank of America, UDS.
Change 29.200 No observations were created in TPM16J dataset because
VMACTPMX the MXG test comparing segment offset+length with the
Sep 7, 2011 record length was off by one, preventing input/output.
Thanks to Scott Barry, SBBWorks Inc, USA.
Change 29.199 The %SYSPROD(GRAPH) function doesn't validate that the
GOPTIONS product is installed; it only confirms that the SETINIT
DOC licenses SAS/GRAPH. The MXG test in VMXGINIT to set
VMXGINIT GOPTIONS for SAS/GRAPH examples in MXG GRAFxxxx members
Sep 4, 2011 (that was added without a change number in MXG 28.05)
is true when the SETINIT said yes, but GOPTIONS/PATTERNn
statements fail when SAS/GRAPH isn't actually present,
with a 180 syntax error on the GOPTIONS statement, since
those procedure-specific statements can't compiled if the
product isn't installed. The new PROC PRODUCT_STATUS will
list all products that are installed, but its use would
require a PROC PRINTTO to trap its output to a file, a
DATA step to read that file, and new %macro variable and
logic, just to set these (optional!) SAS/GRAPH options.
So, to prevent a 180 error in VMXGINIT, these statements
GOPTIONS COLORS=(R B G CYAN MAGENTA ORANGE GREY BROWN BLACK);
PATTERN1 V=S; PATTERN2 V=L1; PATTERN3 V=R1; PATTERN4 V=X1;
PATTERN5 V=L2; PATTERN6 V=R2; PATTERN7 V=X2; PATTERN8 V=L3;
PATTERN9 V=R3; PATTERN10 V=X3;
are no longer set in VMXGINIT, but are moved into the new
GOPTIONS member, and all GRAFxxxx members were updated to
set them with %INCLUDE SOURCLIB(GOPTIONS);
-Also, MXG macro variables SASGRAF and SASSTAT are removed
from VMXGINIT; they were never referenced in any MXG code
and were set by %SYSPROD(), so they too could be wrong.
Thanks to Richard Haynes, Blue Cross Blue Shield of Kansas, USA.
====== Changes thru 29.198 were in MXG 29.06 dated Sep 1, 2011========
Change 29.198 iSERIES variable GDES21 was multiplied by 4096, but it
VMACQACS should have been multiplied by 1024; when GDES11 is all
Aug 31, 2011 nines, GDES21 contains the storage assigned to the LPAR.
Thanks to David Bixler, FISERV, USA.
Change 29.197 Two new segments in Velocity Software XAM Version 4.1 CPU
VMACXAM record are decoded (PRCINS,PRCDIA) but not output as they
Aug 31, 2011 are repeated and hence need new datasets created, and the
new STOASC (DEV) and new SYTLCK (SYS) weren't documented;
these four segments were protected for the NEW SEGMENT
messages but were not decoded. See Change 29.253.
Change 29.196 MXG calculation of GMTOFF30 in SMF 30 records could be
VMAC30 off by 0.01 second, only for positive GMT Offsets, but
Aug 31, 2011 that impacted the BUILDPDB logic that combines MULTIDD=Y
records for a step, when there were intervening SMF 30s
from a different job in between the MULTIDD=Y records.
The MULTIDD=Y records don't contain SMF30IST, so GMTOFF30
must be retained from the prior non-MULTIDD record, but
in this case, SMF30IST was 0.07 with SMF30ISS 0.073983 in
the non-MULTIDD, but an intervening step's non-record had
SMF30ISS of 0.075983 with SMF30IST of 0.08, causing MXG's
(failing) fuzzy logic use GMTOFF30 of .01 in MULTIDD=Ys
from the first step. This caused BUILDPDB to not include
the EXCP/IOTM counts in PDB.SMFINTRV for the MULTIDD's,
so while TYPE30_V had 26 million EXCPs, only 24 million
were in PDB.SMFINTRV for that day's DB2 intervals.
The real culprits, aside from MXG's failing fuzzy logic,
is the absence of GMTOFF in SMF 30 records, the absence
of SMF30IST in the MULTIDD=Y records, and SMF30ISS being
an 8-byte (LOCAL) TODSTAMP with microsecond resolution,
while SMF30IST (GMT) is an 8-byte SMFSTAMP with only 10
millisecond resolution. The correction for MXG's logic
error is to first use ROUND(SMF30ISS,.01) before its
comparison with SMF30IST so both have 10 millisecond,
rounded, values, so GMTOFF30 is correctly calculated for
both positive and negative GMT offsets.
A formal request to IBM SMF30 development to add the long
overdue GMT Offsset has again been made so that MXG logic
is not needed to compensate for its absence.
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.
Change 29.195 MXG now terminates reading TMS data with USER ABEND 1234
VMACTMS5 and an ERROR message if the input file is not the TMC.
Aug 30, 2011 The TMSGRW TMS utility program creates 340 byte records
that MXG read, but they produced incorrect results.
MXG support requires the TMC data as its input file.
Thanks to Srini Anne, State of California, USA.
Change 29.194 Statistics on Page Datasets are added to RMFINTRV (so if
VMXGRMFI your DB2 DBAs add massive buffers and eat up all of your
Aug 27, 2011 page datasets, you'll at least be able to prove why the
system died for lack of paging space!). New variables:
MAXCOMN ='MAXIMUM*COMMON*SLOTS USED'
MAXLOCL ='MAXIMUM*LOCAL*SLOTS USED'
MAXPLPA ='MAXIMUM*PLPA*SLOTS USED'
NRDSLOCL='ACTIVE*LOCAL*DATASETS'
PCTLOCL ='AVERAGE*PERCENT*SLOTS USED*ALL LOCALS'
PCTMAXLO='MAXIMUM*PERCENT*SLOTS USED*ANY LOCAL'
PCTCOMN ='PERCENT*COMMON*SLOTS USED'
PCTPLPA ='PERCENT*PLPA*SLOTS USED'
SIO75CNT='PAGING*SIO*COUNT'
SLOTCOMN='COMMON*SLOTS*DEFINED'
SLOTLOCL='LOCAL*SLOTS*DEFINED'
SLOTPLPA='PLPA*SLOTS*DEFINED'
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 29.193 -ANALZPCR with PDB=SMF reads 113s as well as the others
ANALZPCR and invokes ASUM113.
UTILBLDP -UTILBLDP adds SMF 113 processing, conditionally:
Aug 27, 2011 If BUILDPDB EQ YES and USERADD does not contain 113 it is
added to USERADD, and if INCLAFTR doesn't contain ASUM113
it is added there.
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 29.192 If the length of text in the list of DDNAMEs passed into
UTILCONT UTILCONT exceeded 256 bytes, the list was truncated and
Aug 26, 2011 remaining datasets were not read. Increased to 32000.
Thanks to David Bixler, FISERV, USA.
Change 29.191 Windows 7 may error when attempting to write files to the
DOC root directory (e.g., C:\ if that is your boot directory)
Aug 24, 2011 or to the c:\windows or the c:\program files directories,
with a message about "Insufficient authorization to use".
The error may be circumvented if the program is "run as
authorized", but some MXG examples of ASCII syntax had
"c:\filename.xxx" that could cause the error, so all
instances of that syntax were revised to explicitly
have a directory name (e.g. "c:\mxg\filename.xxx').
In addition, some ASCII LIBNAME examples (which always
point to a directory rather than a file) did not have
a final slash character (LIBNAME PDB 'C:\PDB';) and thus
were unclear that the syntax requires a directory name.
Those examples are now changed to include a final slash
(LIBNAME PDB 'c:\pdb\';) to reinforce that the object is
a directory and not a filename.
Change 29.190 In this "JCLSPLIT" example, CICSTRAN was incorrectly sent
BLDSPSMA to //WORK DD instead of the correct //CICSTRAN DDname.
JCLSPSMA
Aug 23, 2011
Thanks to Art Cuneo, Blue Cross Blue Shield of Illinois, USA.
Change 29.189 Support for Software AG's ADABAS SMF User record creates
EXADUSER sixteen new datasets:
EXADPARM
EXADSTG DDDDDD MXG MXG
EXADIODD DATASET DATASET DATASET
EXADTHRD SUFFIX NAME LABEL
EXADFILE
EXADCMD ADUSER ADABUSER ADABAS USER RECORD
EXADCSP ADPARM ADABPARM ADABAS PARM RECORD
EXADCSG ADSTG ADABSTG ADABAS STG RECORD
EXADCSB ADIODD ADABIODD ADABAS IODD RECORD
EXADCSF ADTHRD ADABTHRD ADABAS THRD RECORD
EXADLOK ADFILE ADABFILE ADABAS FILE RECORD
EXADMSGB ADCMD ADABCMD ADABAS CMD RECORD
EXADMSGC ADCSP ADABCSP ADABAS CSP RECORD
EXADMSGH ADCSG ADABCSG ADABAS CSG RECORD
EXADREV ADCSB ADABCSB ADABAS CSB RECORD
IMACADAB ADCSF ADABCSF ADABAS CSF RECORD
TYPEADAB ADLOK ADABLOK ADABAS LOK RECORD
TYPSADAB ADMSGB ADABMSGB ADABAS MSGB RECORD
VMACADAB ADMSGC ADABMSGC ADABAS MSGC RECORD
VMXGINIT ADMSGH ADABMSGH ADABAS MSGH RECORD
Aug 24, 2011 ADREV ADABREV ADABAS REV RECORD
-Datasets ADPARM, ADSTG, ADTHRD, ADFILE, and ADCMD are now
decoded and validated with SMF records; the others have
been coded but are untested with actual data records.
-Datasets ADABTHRD and ADABFILE do not have fields that
identify the Thread/File; counters ADTHRDNR and ADFILENR
are created as the sequence number in each record, but in
the test data, only the first instance in each record has
a non-zero count (but there are many instances in each
record with zero counts that perhaps should be deleted).
Thanks to Wayne Campos, Corelogic, USA.
Change 29.188 -Blank TRANNAME in ASUMUOW occurred with MXG 28.05 that
IMACUOW were not present with MXG 28.04, so new Case 4 example is
VMXGUOW created to handle this sequence of DB2/CICS/MQ records.
Aug 23, 2011 Precipitated possibly by our changes to VMXGUOW, as the
only site difference is that remote program definitions
with a remote tranid on them are used.
-New debugging TRACEUOW=TRAN option was added/needed to
diagnose this problem: at the endpoint, it tells you
everything there is to know about that particular UOW
when the TRANNAME comes up blank.
-All of the macros that are typically tailored are now
defined in the IMACUOW member, and you should EDIT that
member into your "USERID.SOURCLIB(IMACUOW) and make your
tailoring there, and should NOT now ever have VMXGUOW in
your "USERID.SOURCLIB" tailoring library.
Thanks to Dave Campbell, SunTrust, USA.
Change 29.187 -MXG 29.05 only. ASMRMFV could fail with 0C4 ABEND. Under
ASMRMFV some conditions, IBM did not create a Period Data
VMACRMFV Extension for a Report Class in the RCD record. The count
Aug 23, 2011 field was unexpectedly zero, causing a loop counter to
Sep 1, 2011 become negative, and the 0C4 during an MVCL command.
This condition was never observed during testing.
-This ASMRMFV properly outputs the RCD records, but the
MXG code in VMACRMFV has not yet been updated to read
those records, and prior VMACRMFV could fail trying to
read the new RCD output, so this VMACRMFV skips over any
RCDG3 records. If you want those data, contact support
since the VMACRMFV updates should be done by the time you
read this text.
Thanks to Neil Ervin, Wells Fargo Bank, USA.
Thanks to Jason, Bierman, Great Lakes Higher Education Corp., USA.
Change 29.186 Support for InfoSphere Classic Federation Server Account
EXCFSACC user SMF record creates two new datasets:
EXCFSACV
IMACCFS
FORMATS DDDDDD MXG MXG
TYPECFS DATASET DATASET DATASET
TYPSCFS SUFFIX NAME LABEL
VMACCFS
VMXGINIT CFSACC CFSACCT INFOSPHERE CLASSIC FEDSRVR CPU
Aug 15, 2011 CFSACV CFSVIOL INFOSPHERE CLASSIC FEDSRVR VIOLATE
These possible violations are formatted in MGCFSTY:
101:NOT AUTH TO ISSUE A DROP TABLE FOR TABLE
102:NOT AUTH TO ISSUE A DROP INDEX FOR TABLE
103:NOT AUTH TO ISSUE A DROP VIEW FOR VIEW
104:NOT AUTH TO ISSUE A DROP PROCEDURE FOR STORED PROC
200:NOT AUTH TO CREATE TABLE
201:NOT AUTH TO CREATE INDEX
202:NOT AUTH TO ISSUE THE CREATE VIEW STATEMENT
203:NOT AUTH TO ISSUE THE CREATE PROCEDURE STATEMENT
300:NOT AUTH TO ISSUE A SELECT STATEMENT FOR TABLE/VIEW
301:NOT AUTH TO ISSUE AN UPDATE STATEMENT FOR TABLE
302:NOT AUTH TO ISSUE AN INSERT STATEMENT FOR TABLE
303:NOT AUTH TO CALL STORED PROCEDURE
403:NOT AUTH TO ISSUE A DELETE STATEMENT AGAINST TABLE
500:NOT AUTH TO ISSUE GRANT STATEMENT
501:NOT AUTH TO ISSUE REVOKE STATEMENT
Thanks to Jeana M. Bechtel, Edward D. Jones, USA.
Thanks to Jim Poletti, Edward D. Jones, USA.
Change 29.185 GRAFWRKX used the old IMACWORK workloads to graph the
GRAFWRKX workload variables and had work1-work99 parameters
Aug 13, 2011 for the new. This change removes the need to specify
workload parameters unless you want to alter the order
in which the bars are stacked. Support for the old
IMACWORK workloads is removed but VGETWKLD is used to
capture all of the workloads unless you specify WORK1-
WORK99 values. If you do not specify WORKx values the
workloads are stacked alphabetically from bottom of the
bar to the top. Except that uncaptured will ALWAYS be
at the bottom. If you specify WORK1-x workloads then
the bars are stacked bottom to top starting with WORK1
and going up numerically. You can still use the old
IMACWORK definitions but the parameters are dead and
do not function.
Change 29.184 GRAFRMFI used the old IMACWORK workloads to graph the
GRAFRMFI workload variables and had no provision for the new
VGETWKLD VMXGRMFI sets of workload variables. It now uses
Aug 13, 2011 VGETWKLD to find the workloads that are defined in
your RMFINTRV dataset (whichever method is used) and
uses those workloads and labels to graph the workload
variables.
This is part of the ODS change 29.169, but the change in
the member are so extensive that it warranted a separate
change.
Numerous issues corrected in this change/circumvention:
-TIME VALUE NOT VALID FOR TIME FORMAT. SAS V9.3 only.
if all obs had a missing value for a TIME variable, that
WARNING was printed; circumvented with WHERE clause, but
that raised another WARNING about WHERE CLAUSE changing.
The more insidious problem was the structure:
PROC GPLOT;
PLOT A
PLOT B
PLOT C
PLOT D
PLOT E ....
Which worked fine unless all the obs had missing values
for one of the variables. For example, if A has all
missing values, then, instead of skipping over B, it
made a copy of A. Even worse, IF B C D E all had
missing values, then you got 5 copies of A instead of
the 1 you really wanted.
The solution was to change the structure to:
PROC GPLOT;
PLOT A
PROC GPLOT;
PLOT B
PROC GPLOT;
PLOT C
PROC GPLOT;
PLOT D
PROC GPLOT;
PLOT E ....
It runs a little slower but it eliminated that problem
as well as the warning about the where clause changing.
WARNING: This routine can produce hundreds of graphs;
the number is a function of the number of system, days,
and workloads.
-Code to execute from any populated RMFINTRV dataset:
%GRAFRMFI(PDB=WORK,
ODSTYPE=HTML,
ODSPATH=c:\HTMLTEST,
ODSFILE=GRAFRMFIBODY.HTML);
Change 29.183 Variable SMF19VLI never existed and is no longer created.
VMAC19 This is an overlay for SMF19TRK and SMF19TRM which were
Aug 13, 2011 invalid prior to this correction.
Thanks to Neal Musitano, Jr., Department of Veterans Affairs, USA.
Change 29.182 -Invalid ASP.NET Applications record caused ERROR: INPUT
EXNTNEDP STATEMENT EXCEEDED RECORD LENGTH (record had NRDATA=40
IMACNTSM but header said 75 should exist, which is what MXG
VMACNTSM expected). Circumvention detects number of words in the
VMXGINIT NT SMF record and deletes with an MXGERROR: message.
Aug 11, 2011 -New Object .NET DATA PROVIDER FOR SQLSERVER supported
-Segments ACSR,SQGS,SQDA,SQSS,QLSS and SQBS have IDPROCES
and SQLVERSN variables added.
-After circumvention code was implemented, user found out
the data file had been truncated during ftp transfer, but
I left the update in place since it was tested and safe.
Thanks to Xiaobo Zhang, FISERV, USA.
Change 29.181 %ANALDB2R argument PMIOS05 was not %UPCASED by MXG, so no
ANALDB2R IO SUMMARY REPORT was produced if PMIOS05=yes was used.
Aug 11, 2011
Thanks to Howard L. Curtis, Progress Energy, LLC, USA.
Change 29.180 Harmless MXGWARN: DURATM=INTERVAL WAS SPECIFIED message
ASUMMIPS is eliminated; DURATM was in the SUM= list when it should
Aug 10, 2011 not have been.
Thanks to Bernhard Bablok, Allianz, GERMANY.
Change 29.179 Undefined TOKEN= $ZEKE_Z with TOKENID=59674 now skipped,
VMACTPMX as are all of the defined-but-not-used ZEKE fields.
Aug 10, 2011
Thanks to Scott Wiig, U.S. Bank, USA.
Change 29.178 Variable CECSER, a 6-byte text variable with only the
VMAC89 left four positions populated, with two blanks at the
Aug 9, 2011 right end, is now created in TYPE89 and TYPE892 datasets
to match CECSER in the RMF TYPE70xx data. SMF89SER is a
three-byte character variable containing text in hex with
format $HEX6., so it printed '0178E0', including the 01x
CPUID value. But CECSER in RMF records is only the text
'78E0 ' value, and that is now the value in CECSER in
the TYPE89 and TYPE892 datasets.
Thanks to Warren Cravey, FMR, USA.
Change 29.177 Support for APAR OA35175, logstream statistics in SMF 23,
EXTY23LS creates new TYPE23LS dataset with these new data:
IMAC23 SMF23LFA='AMOUNT*OF EACH*BUFFER*ALLOCATION'
VMAC23 SMF23LFG='VARIOUS*FLAGS'
VMXGINIT SMF23LFH='HWM*BUFFER*ALLOCATION'
Aug 9, 2011 SMF23LFL='CURRENT*BUFUSEWARN*IN EFFECT'
SMF23LFM='CURRENT*DSPSIZMAX*IN EFFECT'
SMF23LFT='TOTAL*BUFFER*STORAGE*CURRENTLY*USED'
SMF23LSL='LENGTH*OF LOGSTREAM*NAME'
SMF23LSN='LOGSTREAM*NAME'
SMF23LF1='BUFUSEQARN*FROM THE*GLOBAL*OPTION?'
SMF23LF2='DSPSIZMAX*FROM THE*GLOBAL*OPTION?'
APAR OA37002 (see NEWSLTRS) adds new DSPSIZMAX argument
for SMFPRMxx to set logstream buffer size(s).
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 29.176 -APAR OA36816 adds bit to SM113CF1 in SMF 113 HIS record
FORMATS that is now decoded by $MG113FL format to display:
Aug 9, 2011 '08X:LOST COUNTER DATA' when SM113CF1 is printed.
-And it adds new option of interest to HIS SMF 113 users:
The DATALOSS parameter for the F HIS command has been
enhanced to control what action is taken by HIS when
any type of instrumentation data is lost. Prior to this
enhancement, the DATALOSS parameter only reacted to
sampling data lost due to a buffer overflow. The
DATALOSS parameter now reacts to instrumentation data
lost due to a Loss Of Sample Data Measurement Alert and
a Loss Of Counter Data Measurement Alert. By
specifying DATALOSS=IGNORE these types of
instrumentation data loss can now be ignored, and the
instrumentation run may continue.
Change 29.175 Support for APAR OA35617 documents two new SMF30PF2 bits
VMAC30 creating SMF30CRM (ASID IS VELOCITY GOAL MANAGED) and
Aug 9, 2011 SMF30PIN (INCOMPLETE WLM DATA?), one-byte flag variables.
SMF30PIN was just observed (overlooked) and now created.
The APAR documents SMF30CRM with this note:
the address space matched a classification rule which
specified "manage region using goals of both", which
means it is managed towards the velocity goal of the
region. But, transaction completions are reported
and used for management of the transaction service
classes with response time goals. This option should
only be used with CICS TORs, the associated AORs
should remain at the default "manage region using
goals of transaction".
Change 29.174 Support for APAR OA34895 adds new EXCP/IOTM SMF 30 fields
IMAC30IO (transparently) with step/interval total I/O Count and
VMAC30 I/O Connect times (new MXG variables EXCPMISS/IOTMMISS)
Aug 9, 2011 with counts that would have also been in a DD segment(s),
Aug 27, 2011 but weren't, because an SMF Lock (to update the TIOT for
VMAC434 serialization) could not be obtained. The xxxxMISS counts
VMAC40 ARE included in the asid/step totals, EXCPTOTL/IOTMTOTL,
read directly from the SMF record, but were not counted
in any of its DD segments, so they are ALSO already in
EXCPNODD/IOTMNODD, the "NOT COUNTED IN DD SEGMENT" vars
MXG creates with EXCPNODD=EXCPTOTl-EXCPTODD.
All of the above is true, WITH OR WITHOUT this change.
This change only creates the new variables and keeps them
in datasets in TYPE30_V, TYPE30_4, TYPE30_5, TYPE30_6 and
PDB.SMFINTRV, and in BUILDPDB's PDB.STEPS/PDB.JOBS (where
member IMAC30IO controls which SMF 30 I/O variables are
kept in the those BUILDPDB/BUILDPD3 datasets. These new
"missed" variables would be useful to at least partially
explain steps with large values in NODD and TOTL fields,
if the xxxxMISS values are non-zero. See NODD in ADOC30.
-Compiler faker added in VMAC434/VMAC40.
-Transparently added, but if you (incorrectly) have an old
VMAC30 in your tailoring library, that will cause
ERROR: EXCPMISS NOT FOUND in BUILDPDB at MXGSUM3.
Thanks to Christa Neven, KBC Global Services, BELGIUM.
Change 29.173 Support for APAR OA36966 for JES3 expands NJEJOBNO to
VMAC57 four bytes in SMF 57 record.
Aug 9, 2011
Change 29.172 APAR VM64961 adds SMF 113 Hardware Monitor counters to
EXPRCMFC the z/VM MONWRITE data on z/10 and later processors. PTFs
VMACVMXA will be available for z/VM 5.4 and z/VM 6.1 and 6.2.
Aug 8, 2011 Dataset VXPRCMFC contains the same variable names as
TYPE113, but there is no SYSTEM variable in z/VM so it
wasn't added into ASUM113. This support was in MXG
29.04, but undocumented.
Change 29.171 The example WEEKBLDT had four instances of _WKBLD that
WEEKBLDT should have been spelled _WEEKBLD; they caused a SAS
Aug 7, 2011 180 syntax error, after creating WEEK.TYPE72 dataset.
Thanks to Ron Wells, American General Finance, USA.
Change 29.170 The insertion of the _TODAY old style macro caused
BLDSMPDB the forceday option to fail.
Aug 7, 2011
Thanks to Cletus McGee, ALFA Insurance, USA.
Change 29.169 MXG examples that use ODS HTML on ASCII that did not have
ANAL72GO a PATH= statement failed with
ANALACTM ERROR: a COMPONENT C:\.... IS NOT A DIRECTORY."
ANALAVAI but only in QA Tests with SAS V9.3; no user had reported
ANALDB2B this error, which can occur with SAS V9.1,V9.2, or V9.3,
ANALHTML nor had we seen the error with earlier SAS Versions.
ANALIDMS SAS Note SN15046 says to eliminate the error you should
ANALINIT use this recommended syntax on ASCII platforms:
ANALPKGS ODS HTML PATH="C:\mxg\"(URL=NONE) body="temp.html";
ANALRAID Previously, MXG had inconsistent ODS examples; this
ANALRANK change formalizes MXG support to create HTML output.
ANALS225 -We use two new %macros VMXGODSO/VMXGODSC to OPEN/CLOSE
GRAFCEC ODS output in our examples, and they can be used in your
GRAFRAID report programs, to create HTML output. The macros can be
GRAFRMFI invoked on z/OS to send html output to either a PDSE or
GRAFTAPE to a ZFS filesystem, or on ASCII to .html files.
GRAFWLM -A consistent set of macro variables are used in arguments
GRAFWRKX so %LET's can be used to change ODS argument's values.
VMXGODSO change revised all of the MXG members with ODS examples.
VMXGODSC -SAS ODS inconsistencies we discovered and handle:
Aug 14, 2011 the URL= must be either a quoted string or unquoted NONE,
and the STYLE= and TRANTAB= arguments are unquoted.
-SAS HTMLBLUE default does not break PROC PRINT output
lines, requiring scrolling across to see all variables.
ODS LISTING; will change the default back to what you
were used to for all interactive output.
Change 29.168 Velocity Software XAM variable PERFCPU is now in seconds
VMACXAM and formatted TIME12.2 in datasets XMHSTAPP and XMHSTSFT.
Aug 1, 2011 Those datasets contain HSTAPP resource usage of a group
of processes that form an application (in snmpd.conf or
ESATCP 'guessing'). If you want to look at individual
processes, you would use dataset VXVSISFT instead.
Thanks to Joe Faska, Depository Trust, USA.
Change 29.167 MXG example reports using PDB.RMFINTRV only recognized
VGETWKLD workload names created with (now archaic) IMACWORK logic.
Aug 1, 2011 The VGETWKLD internal macro will parse the workload names
created by the (now-recommended) WORKnn= arguments that
should be used to define workload names in RMFINTRV.
Change 29.166 For DB2 Version 8.1, dataset DB2GBPST was mostly wrong as
VMACDB2 two 4-byte reserved fields (after QBGLXR and QBGLMR) were
Aug 1, 2011 not input, causing all subsequent variables to be wrong.
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.
Change 29.165 -Variable POSIT was incorrectly zero, as only the first 8
VMACRACF bytes of the 10-byte POSITCH field were INPUT as numeric.
Jul 31, 2011 -Vars OTHRSPEC/OTHRSPE1 are renamed to FRSTSPEC/OTHRSPEC
and re-labeled.
Thanks to Bill Arrowsmith, Euroclear, BELGIUM.
Thanks to Christopher Roberts, Euroclear, BELGIUM.
Change 29.164 Variables S17FBKNM S17SEXNM S17FMFNM are now kept in the
VMAC117 S117THRD dataset.
Jul 31, 2011
Thanks to Fabio Massimo Ottaviani, EPVTECH, ITALY.
Change 29.163 MXG 29.05, Change 29.129 for z/VM Crypto Record (5,10),
VMACVMXA from z/VM 5.4, if PRCAPMCT=6, because that subtype does
Jul 29, 2011 NOT have the undocumented 32 bytes found in 4 and 8, and
this was the first instance of that subtype. Since MXG
can so readily circumvent the IBM error (see 29.129), and
since this is an (ancient?) z/VM 5.4 record, fixing the
doc does not have (appropriately, IMO) high priority, as
this is a fairly obscure event - how many do use crypto
on z/VM systems, especially z/VM 5.4 systems.
Thanks to Tom Draeger, Aurora Health Care, USA.
Change 29.162 -Corrections/enhancements to TYPEIMST (IMS56FA TRANSACTs):
VMACIMS -STRTTIME and ARRVTIME were reversed in MXG logic.
Aug 2, 2011 -But, after fixing, ARRVTIME can be greater than STRTTIME:
- Case 1: WFI and PWFI, because the UOR Start Time begins
when the previous transaction completes, then the
program waits for the next message to appear, so the
STRTTIME=ARRVTIME is the wait time of the program.
- Case 2: Message Switch; the first transaction's
STRTTIME should be greater than the ARRVTIME unless
it is a WFI; see case 1, but the Message Switch
transaction afterward will have the UOR STRTTIME of
the first transaction, therefore the ARRVTIME of the
message will be greater than the STRTTIME.
In both cases, IF ARRVTIME GT STRTTIME then QUEUETM=0
and SERVICETM=RESPTM and STRTTIME=ARRVTIME to match IMF.
-Comparison of QUEUETM/INPQUETM between IMS56FA and IMS
has differences of up to 0.1 seconds, because ARRVTIME in
IMF has only to 0.1 second resolution while in IMS56FA it
has TODSTAMP resolution; this also caused similar small
differences between RESPTM/RESPNSTM variable's values.
-PROGTYPE in prior data was a one-byte text character, but
in IMS56FA it is a more robust bit map, so the data value
in the 56FA record is now input into PROGTYHX with $HEX2.
format, then PROGTYPE is constructed as a test character.
One-byte flag variables are created from PROGTYHX bits:
BMP='BMP?'
DBCTL='DBCTL?'
IFP='IFP?'
JAVA='JAVA?'
MODE='MODE*MULTI*OR*SINGLE?'
MPP='MPP?'
REMOTE='REMOTE?'
WFI='WFI?'
-These variables are now not kept in IMS56FA dataset:
TPCPTICH TPCPSOXN
and removed from the BY list for that dataset, as they
do not exist in that record.
-NMSGPROC=1 is set ONLY if CALLMSGU is GT 0 because 56FA
records are also written for a Message GU-CALL that did
not get a message from the IMS Message QUEUE; for MPPs
these show only a small CPU time, TPLTERM is blank, and
no calls are counted at all.
-TPLTERM was renamed LTERM in IMS56FA dataset.
-IMSVERSN is set to 10.1 instead of 10.10.
-Either SYSABEND or USRABEND, but not both, are populated;
COMPCODE='00000C4000'X correctly set SYSABEND='0C4';
but also incorrectly set USRABEND='U16E3' (i.e. 16,000+).
-If there are no GU calls to the message queue, then there
is no ARRVTIME, so neither QUEUETM nor RESPTM exist; they
are both set to missing values when CALLMSGU LE 0.
-IBM APAR PK773284 TPEXTIME IN X'56FA' TRANSACTION LEVEL
STATISTICS RECORD IS INVALID WHEN THE UNIT OF WORK ABENDS
exists to correct this intermittent problem:
TPEXTIME is IMSCPUTM in MXG IMS56FA dataset; values
'FFFFFFFBAFBA5708'x &'FFFFFFFCC4B4F0C8'x occurred in
two transactions with SYSABEND='0C4' (but the other
0C4's had zero values. MXG prints an error message
for the first five instances, and sets IMSCPUTM to a
missing value when an invalid CPU time value is found.
Thanks to Rudolf Sauer, T-Systems, GERMANY
Change 29.161 MXG 29.03-MXG 29.05, dataset MQMCFMGR was wrong, with 64
VMAC115 identical outputs of only the first segment for each SMF
Jul 29, 2011 ID=115 record, if QESTSTR was non-blank in that segment,
so there were MANY more obs created than should have been
and many valid segments were not output.
Thanks to Paul Volpi, UHC, USA.
Change 29.160 VMXGFIND failed when dataset names created by SAS were
VMXGFIND 32-characters, because VMXGFIND added a prefix of text
Jul 28, 2011 "LIBNAME_" to that SAS-created dataset name. Now, if
only a single input LIBNAME is found, that prefix is
omitted and when there is more than one libname, if the
result exceeds 32 characters, only the first 32 are used.
Change 29.159 -Support for SAS Version 9.3 requires SAS Hot Fix SN43828.
FORMATS This error in SAS Portable Code, in compiling the %macro
Jul 26, 2011 %LET statement, and the %SYSRPUT and %SYSLPUT statements,
could impact SAS V9.3 on ALL platforms, although it was
only detected in MXG QA tests on z/OS, in the members
ANALCNCR and VMXGRMFI, both of which invoke %VMXGSUM.
The compiler error caused misalignment between the left
half (variable name) and the right half (value) of the
%LET statement.
-On ASCII, 32-bit and 64-bit SAS versions are different
operating systems, even on the same platform; so separate
"bit-specific" FORMAT directories are required, but the
same FORMATs can be used for V9.2 or V9.3 for the same
"bit" version. Member FORMATS errored when I tried to run
it under 32-bit V9.3, writing to a V9.2 64-bit directory.
-On both ASCII and z/OS, SAS Data Libraries can be read or
written by either V9.2 or by V9.3, and on ASCII, under
either 32-bit or 64-bit environments.
Change 29.158 NDM-Connect Direct CT Version 5 record has 4 new fields.
VMACNDM There is no version value in the record, but there is a
Jul 26, 2011 new offset to 2 of the 4 new fields, so that offset is
used to conditionally assume all four are present.
NDMJOBID='JCTJOBID'
NDMJOBNM='JCTJBNAM'
NDMRIP6 ='IPV6*ADDRESS'
NDMTYPFK='TYPE*FILE*KEY'
Thanks to Eric R. Carlson, Kroger, USA.
Change 29.157 MXG 29.06 QA tests clean ups:
VMAC7072 -VMAC7072: These variables removed from DROP statement
Jul 24, 2011 LCPUDEXD-LCPUDEXZ LCPUDEVA-LCPUDEUI
LCPUWAXD-LCPUWAXZ LCPUWAVA-LCPUWAUI
because they never existed; QA test enabled DKROCOND=WARN
which caused spurious warning messages.
Change 29.156 IDMS/R Performance Monitor for Version 18 adds variables:
VMACIDMS -Dataset IDMSTAS:
Jul 24, 2011 TASCPTI ='SRB*TIME*ON*CP'
TASENTI ='ENCLAVE*SRB*CPU*TIME'
TASSYTI ='CPU*TIME*ON*CP'
TASTITI ='TCP*CPU*TIME'
TASUSTI ='USER*MODE*CPU*TIME'
TASZPTI ='SRB*TIME*ON*ZIP'
Initial observations were that
TASSYTI (.920) = TASTITI (.777) + TASENTI (.143)
CPU = TCB ENCL SRB
TASCPTI (.016)
TASZPTI (.127)
TASENTI (.0007)
-Added to all datasets, and inserted into the header, so
it caused INVALID DATA FOR PMHSDATE messages:
SMFHJOB ='PM*JOB*NAME'
Thanks to Scott Barry, SBBWorks Inc, USA.
Change 29.155 CICS/TS 4.2 Statistics variables now input:
VMAC110 Dataset CICISR:
Jul 24, 2011 ISRTDBYR='IPCONN*PS*TD*REQS*BYTES*RECEIVED'
ISRTDBYS='IPCONN*PS*TD*REQS*BYTES*SENT'
ISRTDREQ='IPCONN*PS*TRANSIENT*DATA*REQUESTS'
ISRTSBYR='IPCONN*PS*TS*REQS*BYTES*RECEIVED'
ISRTSBYS='IPCONN*PS*TS*REQS*BYTES*SENT'
ISRTSREQ='IPCONN*PS*TEMP*STORAGE*REQUESTS'
ISRUNSUP='ISR*UNSUPPORTED*REQUESTS'
Dataset CICWBR:
WBRATOMS='URIMAP*ATOMSERVICE*NAME'
WBRAUTHE='URIMAP*AUTHENTICATE*USE'
WBRREDIR='URIMAP*REDIRECTION*TYPE*USE'
WBRSOCPK='URIMAP*SOCPOOL*PEAK*IN*POOL'
WBRSOCRC='URIMAP*SOCKETS*RECLAIMED*FROM POOL'
WBRSOCTO='URIMAP*SOCKETS*TIMEDOUT*WHILE INPOOL'
WBRSOCTV='URIMAP*SOCLOSE*TIMEOUT*VALUE'
WBRSOCUR='URIMAP*SOCPOOL*CURRENT*IN*POOL'
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 29.154 Circumventions for a macro errors ONLY in archaic SAS V8,
VMXGSUM that were also perfectly cloned into WPS V8 architecture.
Jul 24, 2011 While SAS V8 is no longer supported by SAS Institute and
while MXG officially does not always work under V8, these
errors encountered in VMXGSUM from VMXGRMFI in BUILDPD3
with both SAS V8 and WPS were circumvented in MXG, and
could be useful in avoiding AUTOCALL issues in SAS V9s:
-%IF %LENGTH(&A &B) GT 0 THEN %DO incorrectly returned 1
when &A and &B were both null with V8/WPS but returned 0
with all SAS V9s. The error was circumvented by replacing
the test string of multiple macro variables with single
ORed tests of each macro variable, to avoid the exposure.
-The SAS provided-in-SASMACRO-library AUTOCALLed %macro
functions %CMPRES/%QCMPRES (which call %QLEFT, %VERIFY,
%QTRIM, %LEFT, %QLEFT, %VERIFY and %TRIM) were removed
from VMXGSUM, as they were never actually needed, and
their removal circumvented V8 and WPS macro errors.
I had thought they were needed to compress blanks from
the %macro arguments, which are limited to 65584 bytes,
and long ago longer argument errors had occurred, but
that error occurs when the %macro is invoked, prior
to these functions execution. Hindsight is beautiful.
Thanks to Scotie Mills, TI, USA.
Change 29.153 UNDECODED CTGRECID and CPU loop caused by Change 29.001,
VMAC111 which incorrectly calculated the SKIP value of bytes to
Jul 19, 2011 be skipped in the SMF ID=111, CTGRECID=7 record.
Thanks to Victoria Lepak, Aetna, USA.
Change 29.152 VMSYSTEM='Y' (Change 29.127) support was revised when RMF
VMAC7072 70 records were read. A divide by zero (creating TYPE70
Jul 19, 2011 from WORK.SORT70SP, because ONTM(LCPUADDR+1) was zero,
because the VMSYSTEM='Y' records do NOT populate the
"on time" in SMF70ONT (which populates ONTM array, and I
believe this is a defect that IBM needs to correct, and
a PMR has been opened to address this and other issues).
However, knowing SMF70ONT is NOT populated, MXG code was
revised and SMF70ONT=DURATM when VMSYSTEM='Y', which then
corrected calculations of PCTCPUBY for these new records,
and logic was revised to correctly capture the actual
LPARNAME of the z/OS system that was running under z/VM.
====== Changes thru 29.151 were in MXG 29.05 dated Jul 11, 2011========
Change 29.151 Support for RCD record in ASMRMFV is completed in time to
ASMRMFV be included in MXG 29.05, but I procrastinated and did
Jul 10, 2011 not complete the updates in VMACRMFV to actually process
and create the new variables. You can safely install the
new ASMRMFV program to create the RMFBSAM file with RCD
data, so that it could be examined when the VMACRMFV has
been updated. Contact support@mxg.com if you want the
updated VMACRMFV when it's ready. This change will be
revised when RCD support is completed.
Jan 18, 2012: MXG 29.29 DATED JAN 18, 2012 IS REQUIRED
TO PROCESS RCD RECORDS. YOU MUST USE THE NEW ASMRMFV
AND THE UPDATED VMACRMFV TO READ RCD DATA.
Change 29.150 New ONLYJOBS program creates 'only' the PDB.JOBS dataset
ONLYJOBS (but also creates PDB.STEPS, PDB.PRINT, which are needed
Jul 9, 2011 to create PDB.JOBS, and creates PDB.SMFINTRV, which may
be useful for long running jobs, from SMF 6/30/26, with
selection for only some JOB names in the example.
Thanks to Jerry Ellis, Liberty Mutual, USA.
Change 29.149 CICS/TS 4.2 (SMFPSRVN=67), INVALID VALUE FOR PHTRANNO,
VMAC110 in MNSEGCL=5 record; eight bytes were inserted by 4.2.
Jul 7, 2011 See Change 29.135, which added Support for CICSTRAN and
CICS Statistics records (which was in MXG 29.03 but was
not announced). This change is required for CICS/TS 4.2
if your site creates MNSEGCL=5 (dataset CICSRDS) records,
but luckily it only causes messages and hex record dumps;
it does NOT cause an ABEND.
Thanks to Tom Buie, Southern California Edison, USA.
Change 29.148 DATEFMT= parameter added to both BLDSMPDB and VMXGALOC to
BLDSMPDB control the format of the date in the directories created
VMXGALOC by VMXGLOC. The default of DATE7 does not allow you to
Jul 7, 2011 sort the directories into an order that puts the
directories in calendar order. The only formats that
would do that are JULIAN and YYMMDD but the code will
accept: DATE MMDDYY DDMMYY YYMMDD and JULIAN with
whatever length you specify. If you use one of the
MMDDYY etc formats and you specify MMDDYY8. you will get
07-05-11 but if you use MMDDYYN8. you will get 07052011.
Change 29.147 Change 29.032 revised dataset PDB.IPLS to only report a
VMAC0 true SYSTEM IPL, but the IPLTIME from SMF 90 is on GMT,
Jul 5, 2011 so this change uses the SMFTIME of the SMF 90 record for
IPLTIME so it is always on the Local time zone.
Thanks to Rudolf Sauer, T-Systems, GERMANY.
Change 29.146 Support for RCD record.
ASMRMFV
Jul 5, 2011
Change 29.145 Revisions (again!) to enhance DB2 processing, especially
ANALDB2R with large volumes of DB2 SMF data.
ASUMDB2A -Macro variable DB2RSELA added in VMXGINIT.
ASUMDB2B -New parameters in ANALDB2R:
ASUMDB2G BUFFDETL=NO - suppresses reading the DB2ACCTB/DB2ACCTG
ASUMDB2P JOB= - select only records with JOB=xxxxxxx
TRNDDB2A -Values for Class 3 Suspension in ANALDB2R reports were
TRNDDB2B corrected. Values for Global Contention are still being
TRNDDB2G reviewed.
TRNDDB2P -If selection criteria are specified in ANALDB2R:
VMXGINIT With PDB=SMF they are passed to READDB2
Jul 5, 2011 With PDB=PDB they are passed to ASUMDB2x members in the
READDB2 DB2RSELA macro variable so that only records that meet
the criteria are summarized.
Performance improvement in ANALDB2R:
IF PMACC01=YES and PMACC02 NE YES
Suppresses buffer data and ASUMs of buffer data
If DB2ACCTP has 0 OBS suppress ASUMDB2P
-New parameter in READDB2
JOB= - select only records with JOB=xxxxxxx
-Some changes in ASUMDB2x/TRNDDB2x members are cosmetic to
eliminate UNINIT messages; others are to pick up the time
ranges of the records for heading and sorting and adding
of a thread count for calculating averages. KEEPALL=YES
reinstated in ASUMDB2P,ASUMDB2G,ASUMDB2B, and ASUMDB2A so
that ANALDB2R can be used with user-tailored ASUMDB2x
datasets (i.e., with dropped variables) without messages
about UNINIT variables.
-In TRNDxxxx, variable THREADs added to SUM list so that
ANALDB2R could be executed against Trend datasets.
Thanks to Neil Ervin, Wells Fargo Bank, USA.
Change 29.144 -IBM IMS Log 56FAx records ARE INDIVIDUAL TRANSACTIONS!
IMACIMST Finally, you can track individual IMS transaction CPU and
TYPEIMST Response times, without using the MXG circumventions
VMACIMS (JCLIMSL6/ASMIMSL6/TYPEIMSA/TYPEIMSB, or IMS0708 data),
Jul 2, 2011 and without ANY sorting/merging/etc. And, the IMF56FA
dataset contains the ARRVTIME of the transaction, which
is NOT contained in IMS0708 dataset, although it is
contained in the IMSTRAN from JCLIMSL6.
-The TYPEIMST member builds only the IMS56FA.IMS56FA
dataset.
-MOST variable names are changed from the prior IMS56FA
dataset, so its variables are now identical to those in
the "circumvention" datasets IMS0708/IMSTRAN so that your
existing reports should work without error or with minor
revisions.
-Most of the DLRxxxxx variables in dataset IMS0708 do not
exist in the IMS56FA dataset, and variables DTOKEN
IMSACCQ6 IMSSQ6TM LINTPSB LINEPGM LINTSY2 LINTSUM are
also missing/blank in IMS56FA, but all of the really
important variables are present.
-References to IMS Version 11.0 were corrected to 11.1.
-References to IMS Version 10.0 were corrected to 10.1.
-Numerous duration variables in the LCODE=45x statistics
records are now correctly divided by 4096.
Thanks to Raymond J. Smith, UHC, USA.
Change 29.143 Extremely strange: INVALID ARGUMENT FOR MOD function and
VMACEXC1 ERROR.VMACEXC2.2 INVALID DEVCLASS/DEVTYPE IN 30 DD, but
Jul 1, 2011 the DEVCLASS and ARGUMENT were both valid, and this was
deep in the middle of a BUILDDB run. Fortunately, the
search for the INVALID ARGUMENT message found this note:
SAS Problem Note 13269: Various numeric functions may
return incorrect results.
The result returned by some numeric functions may be
incorrect. This problem can occur if the result of
the function is assigned to a variable that is also
used as an argument to the function. The functions
affected are:
BETA, COALESCE, COMB, CONVX, CONVXP, DATDIF, DUR,
DURP, GEOMEAN, GEOMEANZ, HARMEAN, HARMEANZ, IQR,
LARGEST, LOGBETA, MAD, MEDIAN, MOD, ORDINAL, PCTL1,
PCTL2, PCTL3, PCTL4, PCTL5, PERM, PROBDF, PVP,
RXMATCH, SMALLEST, YRDIF and YIELDP.
The function may also incorrectly return a missing
value and issue a NOTE to the SAS log reporting that
one of the arguments to the function is invalid.
The SAS Note states:
THIS PROBLEM IS FIXED IN SAS 9.1.3 SERVICE PACK 2
AND SAS 9.2.
BUT THE ERROR WAS UNDER SAS V9.1.3 WITH SP 4!!!
However, the text in the SAS Note and the MOD statement
identified in the error message agreed; the same named
variable was the input and the output
BLKSIZE=MOD(BLKSIZE,32768);
so the code now uses a different variable name, and the
error was eliminated!!!
Thanks to Jean-Denis Lacourse, CGI, CANADA.
Change 29.142 -Additional bits in SMF 90 Subtype 30 are now decoded:
VMAC90A SMF9030C='ENCLAVE*SERVICE*CLASS*RESET'
Jul 1, 2011 SMF9030D='ENCLAVE*QUIESCED'
SMF9030E='ENCLAVE*RESUMED'
SMF9030H='ORIGINAL*INDEPENDENT*ENCLAVE'
SMF9030K='ENCLAVE*OWNER'
-Variable PRODUCT is added to all TYPE90nn datasets.
Thanks to Siegfried Trantes, Gothaer-Systems, GERMANY.
Thanks to Willi Weinberger, Gothaer-Systems, GERMANY.
Thanks to Sabine Richard, Gothaer-Systems, GERMANY.
Change 29.141 Skipped Change Number.
Change 29.140 Some DB2 Trace Records IFCID 6/7 have QWHSSTCK events
VMACDB2 before the QWACBSC start time in their DB2ACCT and
VMACDB2H DB2ACCP observations. IBM DB2 support answer:
Jun 29, 2011 "The logic in DB2 does full thread allocation and then
clocks the begin time for the transaction. If an I/O
is required during allocation, you may see a 6/7 pair
outside the transaction bounds. So in the end, this
appears to be working without error."
But the time value in QWHSLUUV in these transaction DOES
precede the first IFCID 6, showing that the actual start
time WAS captured when the LUUV was created, and that
the LUUV creation event should be used for QWACBSC time.
That suggestion is under discussion with IBM.
While waiting, new variable LUUVTIME is created in both
DB2ACCT and DB2ACCTP to be used in place of QWACBSC when
analyzing DB2 trace records. For QWHCATYP=8 REMOTE UOW
transactions, LUUV is not a valid time value, but for
those records, LUUVTIME is set equal to QWACBSC so that
all observations have a usable LUUVTIME for match up
with other records.
Note that for DB2PARTY='R' or ='P' (Rollup, Parallel),
LUUVTIME can be MUCH earlier than QWACBSC, because in
those records QWACBSC NOT the transaction start time, as
is documented in Change 29.131.
Note also that variable ACE rather than QWHSACE should
be used to match up transactions; for DB2PARTY='P' obs,
ACE is set to QWACPACE, which is constant for all of
the records for that transaction (while QWHSACE in the
parallel records is not consistent).
Change 29.139 RACF variables RES25TEA-RES25TEF, RES25MEA-RES25MEF in
VMAC80A dataset TYPE8020 and CLASNAME-CLASNAM5 in TYPE8024 from
Jun 29, 2011 DTP=43 segments were wrong because the segment count
variables NR25SEGS and NR43SEGS were never reset to 0
for a new record.
Thanks to Lars Fleischer, SMT Data, DENMARK.
Change 29.138 If you use a LIBNAME statement to allocate a tape SAS
zOS Only data library and VGETENG is invoked before any datasets
Jun 25, 2011 are written to the tape, you may get a 413-18 error from
zOS indicating a failure to correctly open the dataset.
Your job will still get a CC=0 so it is not a serious
error, but it is an annoying warning message.
LIBNAME TEST V9SEQ;
%VGETENG(DDNAME=PDB);
Will cause:
ERROR: OPEN FAILED. ABEND CODE 413. RETURN CODE 18.
This can be suppressed by writing a 0 OBS 0 VARS dataset
to the tape immediately after the LIBNAME, using
LIBNAME TEST V9SEQ;
DATA TEST.A;RUN;
%VGETENG(DDNAME=PDB);
to suppress the message (although it will also put a
very small additional dataset on the tape).
Change 29.137 UTILARCH - Archival of SAS datasets from a data library,
UTILARCH similar to the way OUTLOOK archives its EMAIL store.
Jun 25, 2011 All observations for chosen datasets dated earlier than
the chosen archive date are written to the archive data
library (which could be new, or archived observations
can be appended to an existing archived dataset), and
the observations that were archived are then removed
from the original input dataset (which can be rewritten
or could be written to a new "unarchived" data library).
You can specify:
INDD= LIBNAME of the input data library.
OUTDD= LIBNAME of the output un-archived, reduced
dataset. If OUTDD is NOT specified, the
unarchived observations replace the dataset
in the INDD library. OUTDD is required if
INDD is on TAPE or DASD sequential format.
INARCHIVE= LIBNAME of the current archive data library.
If the dataset(s) selected exist in OUTDD,
newly archived observations are APPENDed.
ARCHIVE= The new archive data library. This could
be the same as INARCHIVE, as long as they
are not tape nor sequential format on DASD.
DATEVAR= The name of the date variable to be tested.
KEEPDAYS= The number of days of detail data to keep
unarchived. Obs more days old are archived.
KEEPDATE= The date literal (01JAN2011) to keep; obs
earlier than this date are archived.
Either KEEPDAYS or KEEPDATE but not both
must be specified.
ARCHDAYS= The number of days of data to keep in the
archive. If not specified, the archive
will continue to grow in size.
ARCHDATE= The date literal (01JAN2010) of the oldest
date to be kept in the archive.
Either ARCHDAYS or ARCHDATE or NEITHER, but
not both, must be specified.
DATASETS= one or more SAS datasets to be archived
If the datevar is gt TODAY()-KEEPDAYS, the OBS is
written back to the detail. If it is lt that value
but GT today()-sum(keepdays,archdays) it is written
to the archive (if archdays is specified - if it is
not specified the archive grows to infinity.)
Thanks to Brian A. Harvey, HCL America, USA.
Change 29.136 Support for WebSphere WAS 8.0 (COMPATIBLE). These new
VMAC120 variables are added to dataset TYP1209E:
Jun 25, 2011 SM1209FK='CLASSIFICATION*ONLY*TRACE?'
Jul 17, 2011 SM1209FM='SMF*REQUEST*ACTIVITY*ENABLED?'
SM1209FN='SMF*REQUEST*ACTIVITY*TIMESTAMP?'
SM1209FO='SMF*REQUEST*ACTIVITY*SECURITY?'
SM1209FP='SMF*REQUEST*ACTIVITY*CPU DETAIL?'
SM1209FQ='PROPAGATE*TRANSACTION*NAME?'
SM1209FR='STALLED*THREAD*DUMP*ACTION'
SM1209FS='CPUTIMEUSED*DUMP*ACTION'
SM1209FT='DPM*DUMP*ACTIO'
SM1209FU='TIMEOUT*RECOVERY'
SM1209FV='DISPATCH*TIMEOUT*VALUE'
SM1209FW='QUEUE*TIMEOUT*VALUE'
SM1209FX='REQUEST*TIMEOUT*VALUE'
SM1209FY='CPUTIMEUSED*LIMIT*VALUE'
SM1209FZ='DPM*INTERVAL*VALUE'
SM1209GA='MESSAGE*TAG*VALUE'
SM1209GF='CPU*USAGE*OVERFLOW?'
SM1209GG='CEEGMTO*UNAVAILABLE?'
SM1209GH='LENGTH*OBTAINED*AFFINITY*RNAME'
SM1209GI='OBTAINED*AFFINITY*RNAME'
SM1209GJ='LENGTH*ROUTING*AFFINITY*RNAME'
SM1209GK='ROUTING*AFFINITY*RNAME'
-Variable SM1209CE is expanded to 16 bytes.
-Variables SM1209DX and SM1209DZ are deprecated; they are
still set, but use SM1209GF and SM1209GG because DX/DZ
may not exist, since the z/OS Request Info Section
(and the Platform Neutral Request Info Section) might not
be present if this is Async Work.
-New values added to format MG1209T for SM1209CK and to
format MG1209C for SM1209EM.
-Jul 17: Updated VMAC120 was moved into SOURCLIB. This
Change was NOT included in MXG 29.05 dated Jul 11, 2011.
Thanks to David Follis, IBM, USA.
Change 29.135 Support for CICS/TS 4.2 was available in MXG 29.03 but
VMAC110 not announced until today when it became GA. See Change
Jun 24, 2011 29.063 for details.
Change 29.134 Support for Informatica's POWER EXCHANGE SMF record adds
EXPOEXCL five new datasets:
EXPOEXDB
EXPOEXEX DDDDDD MXG MXG
EXPOEXFI DATASET DATASET DATASET
EXPOEXLI SUFFIX NAME LABEL
FORMATS
IMACPOEX POEXLI POEXLIST POWER EXCHANGE LISTENER
TYPEPOEX POEXEX POEXEXPT POWER EXCHANGE EXCEPTION
TYPSPOEX POEXFI POEXFILE POWER EXCHANGE FILE ACCESS
VMACPOEX POEXDB POEXDB2 POWER EXCHANGE DB2
VMXGINIT POEXCL POEXCLIE POWER EXCHANGE CLIENT
Jun 24, 2011 Only POEXLIST and POEXCLIE datasets have been validated
with data records, and these problems have been reported
to the vendor's support team:
a. The STCK fields are in GMT but there is no GMT Offset;
it is possible to use Fuzzy Logic to compare END time
when it is populated (see below) to calculate a GMT
Offset, but well-written SMF records always contain
the GMT Offset that is in effect when the event
records are created, when they contain time/date-times
on the GMT clock.
b. The records contain Subtypes but BIT 1 in SMFxFLG is
not set; the SMF Manual Table 13-2 documents that bit
that should be set for records containing Subtype.
c. The Reserved Field at offset 290 in the General
section is only 28 bytes, but was documented as 32
bytes.
d. For the Client Records:
1. In the General section, the Character START/END are
LOCAL zone, but they are identical to each other
and are the same as SMF time (except that SMFTIME
has higher resolution). The STCK START/END are GMT
zone, and are also identical to each other.
2. In the Extended section, the STCK START/END times
are not populated.
3. The Reserved Field in the General Section contains
an IP address in character format.
4. The Client IP Address is not populated.
5. The Client User ID contains hex rather than EBCDIC
text; I don't know if that is correct or not, but
if it contains HEX it needs to be documented.
e. For the Listener Records:
1. The START fields are many days/hours prior to the
SMF TIME, and are constant for each JOB. The CHAR
field is Local Time Zone, the STCK field is GMT
Time Zone.
2. The SMF times are at 5 minute intervals, but are
not synchronized with TIME OF DAY, as all interval
records should be.
3. The END TIME fields (both CHAR and STCK) are not
populated, so it is NOT possible to use Fuzzy Logic
to reset the Start Time to the local clock.
Thanks to Bobbie Justice, Kohl's, USA.
Change 29.133 -Variables LPARNAME and LPNUMBER are added and are kept in
ASUMVMXA PDB.VMXAINTV and PDB.ASUMVMXA. But the LPNUMBER in z/VM
VMACVMXA data is NOT the "LPARNUM" variable in TYPE70PR from RMF.
Jul 5, 2011 In TYPE70PR, variable LPARNUM is a z/OS assigned sequence
number that has no connection with the actual Partition
number of each LPAR, which is precisely what is stored by
MONWRITE in its LPNUMBER variable. In TYPE70PR, there is
a variable PARTISHN, but that is the actual Partition
that wrote that SMF 70 record, and since the IFL LPARs do
not write SMF records, there is no possible way to match
the z/VM MONWRITE LPNUMBER to the IFL LPAR data.
However, merging the TYPE70PR IFL observations with the
MONWRITE data does not need the LPNUMBER/LPARNUM; the
data can be merged by matching the LPARNAME and ENDTIME.
Jul 26: See MXG Newsletter FIFTY-EIGHT VM Technical Notes
for comparison of synchronized MONWRITE and RMF data.
And, only SHARED IFLs have actual utilization; DEDICATED
IFLs always report 100% utilization in TYPE70PR/ASUM70PR.
Change 29.132 -When sending the output to HTML, PROC GCHART creates
GRAFCEC files with the name GCHART GCHART1 GCHART2 etc. If you
GRAFWRKX send the output of both routines to the same place, the
UTILWORK second one overwrites the output of the first. Added a
Jun 22, 2011 NAME= to all the GCHARTS so the charts created by
Jul 5, 2011 GRAFWRKX will be GRFWRK GRFWRK1 etc and the ones from
GRAFCEC will be GRFCEC GRFCEC1 etc.
-If COMPAT=YES was incorrectly specified (COMPAT went away
years ago), UTILWORK generated an RMFINTRV member with
USEREPRT and USECNTRL set to COMPAT=YES, causing VMXGRMFI
to look for performance groups. Now, COMPAT=GOAL is set.
-If run on ASCII in the background, your session will stop
to display every graph being produced - a real pain in
the butt. This can be suppressed using the GOPTIONS
NODISPLAY; option and a graphics catalog will still be
created. So you may want something like:
GOPTIONS NODISPLAY;
PROC GCHART GOUT=MYGRAPHS DATA=whatever;
VBAR whatever;
Run;
GOPTIONS DISPLAY;
FILENAME HTML 'C:\MXG\';
ODS HTML PATH=HTML BODY='BODY.HTML' FRAME='FRAME.HTML'
CONTENTS='CONTENTS.HTML';
PROC GREPLAY IGOUT=MYGRAPHS NOFS;REPLAY _ALL_;
RUN;
ODS HTML CLOSE:
RUN;
The graphs will be constructed and HTML put in C:\MXG\.
Clicking on FRAME.HTML will display the graphs after the
background task is complete.
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 29.131 When DB2 ROLLUP is specified, DB2ACCT and DB2ACCTP will
VMACDB2 have two observations, the Originating and the Rollup,
Jun 21, 2011 but only DB2ACCT created DB2PARTY to identify which.
This changes creates DB2PARTY in DB2ACCTP dataset.
In DB2ACCT, with Parallelized DB2 and ROLLUP specified:
-In the DB2PARTY='O' observation, QWACBSC/QWACESC are the
start and end times, but in DB2PARTY='R' record, both
BSC and ESC are set to the END time of the transaction.
In DB2ACCTP, with Parallelized DB2 and ROLLUP specified:
-In the DB2PARTY='O' observation, QPACSCB/QPACSCE both
are missing values, and in DB2PARTY='R' record, both
are set to the END time of the transaction.
-Parallelization is only recognizable because the value
in QPACSCT (and in QPACZITM if zIIPs exist) are much
larger than the ELAPSTM in the DB2ACCT 'O' observation.
In both DB2ACCT and DB2ACCTP, population of variables is
inconsistent between the 'O' and 'R' record; in ACCTP the
QPACPKID is blank in the 'O' but populated in the 'R',
while most other QPACxxxx variables have values in both.
In ACCT, the QBnxxxx and QXxxxxx variables are missing in
the 'R', but most other variables are populated in both.
Thanks to Glen Bowman, Wakefern, USA.
Change 29.130 -Cosmetic - if you were running with AUTOALOC=YES, a SAS
BLDSMPDB warning was generated when a PROC COPY was used to copy
Jun 21, 2011 the contents of PDB to the day of the week. That is now
suppressed unless AUTOALOC=NO.
-New parameter AUTOTRND= added to allow you to add or
subtract the TRNDxxxx members that are invoked when
trending is being done. Default TRNDxxxx members are:
TRNDCEC TRNDCELP TRNDCICX TRNDDB2A TRNDDB2P TRNDDBSS
TRNDRMFI TRND72GO TRNDTMNT TRNDTALO
Change 29.129 z/VM 5.4 Crypto Record (5.10) with PRCAPMCT=8 printed
VMACVMXA ***MXGERROR DM 5 RC 10 UNDECODED PRCAPMCT=8 WAS SKIPPED
Jun 15, 2011 *ERROR* PROBABLE DATA LOSS DUE TO MONWRITE FAILURE.
and subsequent misalignment, due to 32 undocumented bytes
for that crypto subtype. Investigating further.
IBM has confirmed the documentation of this record is in
error; the MXG code and this change will be updated when
the IBM correction is available.
Thanks to Victoria Lepak, Aetna, USA.
Change 29.128 NOTE: DB2 INVALID DISTRIBUTED HEADER DELETED message if
VMACDB2H QWHDSVNM length (QWHDLOSL) was greater than 16 bytes even
Jun 15, 2011 after Change 29.036 due to error calculating LENLEFT.
Thanks to Lorena Ortenzi, UniCredit Group, ITALY.
Thanks to Paolo Uguccioni, UniCredit Group, ITALY.
Change 29.127 Support for z/OS 1.12 VMGUEST option to add CPU time to
VMAC7072 the RMF 70 records for z/OS systems running under z/VM.
Jun 14, 2011 New variable VMGUEST='Y' is added to PDB.TYPE70PR dataset
if this z/OS is run under z/VM with the VMGUEST option
specified in Monitor I options (in your ERBRMFxx member).
Two observations in PDB.TYPE70PR exist with the option;
one with LPARNAME='PHYSICAL' that contains the Dispatch
CPU Time of z/VM itself for this z/OS system, and one
with the LPARNAME='VMSystem' for the z/OS CPU TIME.
In the RMF Reports:
The header of the Partition Data section provides data
about the z/VM partition running the z/OS guest, with
'VMSystem' reported as the MVS PARTITION NAME field.
The IMAGE CAPACITY field displays the CPU capacity
available to the z/VM partition; NUMBER OF VMSystem
PROCESSORS presents the number of processors that are
assigned to the z/VM partition. All other header fields
in the RMF report will be N/A. The partition data
reports data of the z/OS system running as z/VM guest.
The CPU time used by z/VM itself is reported as
partition name '*VMSystem*'. In the reported partition
data, the physical processor utilization represents the
logical processor utilization of the z/VM partition.
Change 29.126 Data set VXSYTEP2 variables kept that were not input:
VMACXAM SYTEP1FL ECMCPBT ECMCPBTB
Jun 13, 2011 and variables input that were not kept:
Jun 15, 2011 SYTEP2FL $CHAR1. /*SYTEP1*FLAGS*/
CSCCMCMB &RB.4. /*MAXIMUM*INTERNAL*BUS*CYCLES*PERSEC*/
CSCCMCMC &RB.4. /*MAXIMUM*CHANNEL*WORK*UNITS*PERSEC*/
CSCCMCMM &RB.4. /*MAXIMUM*WRITES*PERSEC*/
CSCCMCMR &RB.4. /*MAXIMUM*READS*PERSEC*/
CSCCMCMU &RB.4. /*BYTES*PER*DATA*UNIT*/
ECMBCBCC &RB.4. /*BUSY*CYCLES*USED FOR*I/O*/
ECMCCWUC &RB.4. /*CHPATH*DATA*UNITS*TOTAL*/
ECMCCWU &RB.4. /*CHPATH*DATA*UNITS*LPAR*/
ECMCDWUC &RB.4. /*CHPATH*WRITE*DATA*UNITS*TOTAL*/
ECMCDWU &RB.4. /*CHPATH*WRITE*DATA*UNITS*LPAR*/
ECMCDURC &RB.4. /*CHPATH*READ*DATA*UNITS*TOTAL*/
ECMCDUR &RB.4. /*CHPATH*READ*DATA*UNITS*LPAR*/
SYTEP2FL is now kept in place of SYTEP1FL, ECMCPBT/B are
no longer kept and the other twelve are now kept.
Jun 15: All references to WORKUNITS and WORK*UNITS in the
variable labels was changed to DATA*UNITS; while Barton
documented them as WORKUNITS in the PL/1 descriptors that
are the only XAM documentation, apparently later in the
Velocity reports/documentation they are now called DATA
UNITS so I've changed the labels as requested.
Thanks to Patricia Hansen, ADP, USA.
Change 29.125 DB2 SMF 102 IFCID 22 INPUT STATEMENT EXCEEDED if length
VMAC102 of QW0022AN,'ACCESS INDEX NAME' was greater than 18, due
Jun 10, 2011 to error in MXG logic in handling truncated name fields.
Also, for DB2 V10, QW0022PA was incorrectly read as PIB2
which caused the new CY/NP/F2/TT variables to be wrong.
Thanks to Joe Babcock, Bank of America, USA.
Change 29.124 Variables CTGIAREQ and CTGLALRQ were incorrectly kept in
VMAC111 dataset TY111CXI, but those fields do not exist in the
May 28, 2011 subtype 07 record, so they have been removed from that
dataset's KEEP list. They do exist in subtypes 01/02/03
so they were sometimes populated and sometimes missing in
TY111CXI dataset, depending on the order of subtypes in
the SMF record. These three different subtype sequences
have been observed in SMF 111 records, for no apparent
reason, but as each subtype is independent, with this
MXG correction, there is no impact on different orders:
00 01 05 04 06 07 03
07 00 01 05 04 06 03
00 07 01 05 04 06 03
Thanks to Gordon E. Griffith, Edward Jones, USA.
Thanks to Jeana M. Bechtel, Edward D. Jones, USA.
Change 29.123 Support for TMON/IMS Version 3.0 (INCOMPATIBLE). New
EXTIMCM1 variables added to TIMSCM, TIMSCP, and TIMSCT datasets.
EXTIMCM2 Six new datasets, one for each of the three segments in
EXTIMCM3 the CM and CP records are created. The datasets TIMSCM,
EXTIMCP1 TIMSCM1, TIMSCM2, TIMSCM3, TIMSCO, TIMSCP, TIMSCP1,
EXTIMCP2 TIMSCP2, TIMSCP3, and TIMSCT were validated with data;
EXTIMCP3 no other subtypes were examined for changes.
IMACTIMS
VMACTIMS
VMXGINIT
May 28, 2011
Thanks to Santosh Kandi, J.C. Penney, USA.
Change 29.122 Lengths of variables CUVENDOR $3 and CUSERIAL $12 are now
VMAC74 set in a length statement. Because they were created by
May 27, 2011 a SUBSTR function, their default length was set from the
length of the input variable, which was $28.
Change 25.155 noted that the SUBSTR function sets length
from the input variable, while SCAN and other functions
default to $200. The length for these SUBSTR could be
set at compile time, because the third argument is fixed,
but it isn't, so the LENGTH statement sets the length.
Thanks to Rudolf Sauer, T-Systems, GERMANY
Change 29.121 MXG 28.28-29.04. DB2 Data Sharing Variables QWHADSGN and
VMACDB2H QWHAMAMN were blank if there was a Distributed Header for
May 27, 2011 DB2ACCT or DB2ACCTP datasets. All DDF records have a
QWHSTYP=16 segment, but they can exist in other records.
Thanks to Paul Volpi, UHC, USA.
Change 29.120 Updates discovered during ITRM Dictionary Build:
ASUMVMXA -VMACTPMX. By list _BTMP10 variable TPMCMLNN (MSU) should
VMAC82 have been TPMCMLNM (LPAR NAME).
VMACTPMX -VMAC82. Labels 21th/22th/23th/31th/32th/33th corrected.
VMACVMXA -VMACVMXA
VMXGINIT Macro _SUSELOF had disappeared from the _DELTALL macro,
May 26, 2011 now reinstated.
Jun 22, 2011 Variable SCKRZWCT was a typo and does not exist.
Nov 17, 2011 Variables NBAD113 and RESETCTR are DROPped.
Variable CURALLOC does not exist and reference removed.
Variable PLXCPUCN was a typo and does not exist.
Variable VL3CAF label is now CAPABILITY vs CAPACILITY.
Nov 27, 2011: These updates were not made until today:
-ASUMVMXA. Macro variable PSUVMXA now defined in VMXGINIT
rather than in ASUMVMXA, and existing macro _LVMAINT is
for the location of VMXAINTV and the old _LTYVMXA token
is removed.
Thanks to Chris Weston, ITRM Development, USA.
Change 29.119 -The below segment of an INPUT statement was accidentally
QASAS left in the middle of a LABEL statement:
VMACQACS DSSRLN ='DISK*UNIT*SERIAL*NUMBER'
May 23, 2011 DSPTROP &PIB.8. /*TOTAL*PATH*READ*OPERATIONS*/
Jul 6, 2011 DSPTWOO &PIB.8. /*TOTAL*PATH*WRITE*OPERATIONS*/
DSWWWNN $CHAR8. /*WORLD*WIDE*NODE*NAME*/
DSSRVT ='DISK*SERVICE*TIME'
but it did NOT generate a compiler error, because the SAS
delimiter for label text is the equal sign. It did cause
variables DSPTROP DSPTWOO & DSWWWNN to have blank labels,
and it created a very long label for variable DSSRLN that
SHOULD have been detected in the QA LONG LABEL tests, but
wasn't, because the QASAS still had the archaic TYPEQAPM
executed AFTER the current TYPEQACS, so the old QAPMDISK
(with only 74 variables and none of the above new ones)
overwrote the new (103 variables) QAPMDISK dataset in QA.
-Removing the ancient TYPEQAPM member from the QA stream
caused these datasets to no longer be created/documented
in the DOCVER member (but this is only cosmetic); those
datasets have not been actually available in years).
QAPMASYN QAPMBSC QAPMDDI QAPMECL QAPMFRLY QAPMIDLC
QAPMJOBS QAPMLAPD QAPMPOOL QAPMRWS QAPMSTND
QAPMSTNL QAPMSTNY QAPMX25
Thanks to Richard Schwartz, State Street Bank, USA.
Change 29.118 Change 29.084 deleted temporary MXGENG dataset because
UTILCONT %VGETENG was thought to only create two macro variables,
VGETENG but UTILCONT/VMXGSIZE had undocumented invocations of
VMXGSIZE %VGETENG that required that dataset to exist. The new
May 18, 2011 CLEANUP=YES/NO is added to all three members to allow
the dataset to be kept and deleted later when needed.
Thanks to Paul Naddeo, FISERV, USA.
Change 29.117 -ASCII only, CICSTRAN variables RTYPE/RRTYPE should have
UTILEXCL been input with $EBCDIC informat in VMAC110/UTILEXCL.
VMAC110 -VMACSVIE, variable CNTL_TIME in SV03THRE dataset is now
VMACSVIE converted back from GMT to local time zone.
May 18, 2011 -VMACSVIE, variable DB2_PROGRAM in SV27DB2 is $ASCII.
-VMACSVIE, variable SCUCRSTG is no longer formatted.
-VMACSVIE stores CICS task number as PIB4 and not PD4 so
these variables inputs were changed:
CNTL_TASKNUMBER LASTTRANNUM TRANNUM OTRANNUM EXS_MNTNO
-VMACSVIE, variable THRS_GROUP and THRS_CLASS corrected.
Thanks to Matthew Chappell, Dept. of Transport Main Roads, AUSTRALIA
====== Changes thru 29.116 were in MXG 29.04 dated May 17, 2011========
Change 29.116 The SQL Statement Number in all of the original SQL Trace
FORMATS IFCIDS 53,58,59,60,61,64,65,66 plus 125,183, and 247 have
VMAC102 been wrong (fixed value of 16448 usually) ever since they
May 14, 2011 were relocated and increased from 2 to 4 bytes in DB2 V8.
In making this update, several overlooked variables are
also now output in these T102Snnn DB2 trace datasets, and
several new formats were created to decode them.
Thanks to Joachim Sarkoschitz, DATEV, GERMANY.
Change 29.115 Arguments PDB= and PDBOUT= were not UPCASED, causing the
GRAFWRKX PDB=trend to not be recognized. Now they are.
May 10, 2011
Change 29.114 -Testing JCLSIMPL default example exposed macro language
BLDSMPDB syntax errors corrected in this BLDSMPDB:
VMXGDBSS
May 10, 2011 NOTE: Line generated by the macro variable "RERUN".
May 15, 2011 20 "
-
77
ERRROR 77-185: Invalid number conversion on ""d.
-Tests also exposed errors in VMXGDBSS where SHIFT was not
being created in ASUMDBSx datasets, causing a later
failure when the ASUMs were executed.
-New PDB=NONSMF argument added to BLDSMPDB to support the
new JCLSMOTH non-SMF processing in Change 29.105.
Thanks to Vinnie Falzone, The Prudential, USA.
Change 29.113 Variables CTGLALRQ (Lifetime) and CTGIAREQ (Interval) in
VMAC111 TY111CXI dataset were reversed.
May 10, 2011
Thanks to Gordon E. Griffith, Edward Jones, USA.
Change 29.112 Documentation only. This paragraph was added:
IMACACCT If you have created a SPIN data library and then decide
May 5, 2011 to DROP ACCOUNTn and LENACCTn variables that were kept
originally, you will need to copy and DROP the unwanted
ACCOUNTn and LENACCTn variables from the three datasets
SPIN30_1, SPIN30_5, and SPIN26, and copy & DROP the
unwanted SACCTn variables from SPIN30_4, and then copy
the revised datasets back into your SPIN data library.
Otherwise, the unwanted will still be in both the SPIN
and the PDB JOBS/STEPS/PRINT datasets.
Thanks to Stan Dylnicki, Royal Bank of Canada, CANDADA
Change 29.111 For CICS Attach, the CICS TRAN name is extracted from the
VMACDB2 QMDACORR field, but that value is sometimes wrong and the
May 4, 2011 correct CICS TRAN name exists instead in QWHCCV field, so
MXG now uses QWHCCV as the source of CICS TRAN.
A PMR will be opened with IBM to determine if this is an
IBM error, since DSNWMSGS states that QWHCCV/QMDACORR are
supposed to be the same.
Thanks to Richard Schwartz, State Street Bank, USA.
Change 29.110 The invocation of the dataset exit token _EIMSTRN was
TYPEIMSA accidentally removed from TYPEIMSA in MXG 28.28, but is
May 4, 2011 in now reinstated.
Thanks to Craig Collins, State of Wisconsin DOA, DET, USA.
Change 29.109 PDB.DB2STATS vars QXRWSDEL/QXRWSFET/QXRWSINS/QXRWSUPD
VMACDB2 were incorrectly kept in both DB2STAT0 and DB2STAT1 and
May 4, 2011 were not deaccumulated in _SDB2ST0.
Thanks to Jane S. Stock, USPS, USA.
Change 29.108 -Invalid UARG record was not true; the MXG test for NWORDS
VMACNMON LE 5 should have been LE 4. Additionally, the UARGTYPE=2
May 4, 2011 UARG record now sets THCOUNT=1 so that observations will
be created in the PDB.NMONUARG dataset.
-INVALID ARGUMENT error messages are caused by invalid VM
record that has the second word T0001, an interval marker
which should contain data values, but the invalid record
instead contains the field descriptions. MXG now detects
and prints a clear error message referencing this change.
Thanks to Xiaobo Zhang, FISERV, USA.
Change 29.107 Format MG099TC is updated to decode 70+ new trace codes
FORMATS added by z/OS 1.12 for the SMF 99 variable S99TCOD.
May 4, 2011
Thanks to Michael Oujesky, Bank of America, USA.
Change 29.106 JES3 PDB.JOBS variable CLASS is the 8-byte JOBCLASS when
BUIL3005 the job was read-in, from the TYPE26J3 purge record, IBM
May 3, 2011 field SMF26CLN. CLASS is stored into JOBCLASS when CLASS
is non-blank (i.e., when a Purge Record exists). But the
job class can be changed in exits, in particular, in the
IATUX29 exit; that new JOBCLAS8 value is in the SMF 30
records, so this change now keeps JOBCLASS8 in the JES3
PDB.JOBS dataset, where it's label will be
JOBCLAS8='JES3*8-BYTE*JOBCLASS*AFTER*IATUX29'
If no purge record was found by BUIL3005, the value in
JOBCLAS8 from the 30 record is stored into JOBCLASS.
Thanks to Jeff Ramsay, ArcelorMittal, USA.
Change 29.105 JCLSIMPL and JCLSPxxx examples use UTILBLDP/BLDSMPDB and
BLDSIMPL are THE now-recommended z/OS jobs for a "SIMPLE" BUILDPDB
BLDSPMTH or the "SPLIT SMF" family of "BUILDPDB" jobs.
BLDSPOTH
BLDSPSMA JCLSIMPL creates a "simple", PDB library, with one job
BLDSPSMB that reads the SMF file, showing how to add an SMF record
BLDSPSMC and invoking all of the default ASUMxxxx members to build
BLDSPSMD a "single", default PDB data library from raw SMF data.
BLDSPSME You could do the same with BUILDPDB and the EXPDBxxx exit
BLDSPUOW members, but these more recent utility macros are now the
BLDSPWEK recommended way to build/tailor a simple BUILDPDB:
JCLSIMPL UTILBLDP - defines what data is to be created in a PDB.
JCLSPCPY You can add, subtract, or change what's kept
JCLSPGDG by each of these jobs use UTILBLDP to create
JCLSPLIT a specific suit of MXG datasets in a PDB
JCLSPMTH built from SMF data records.
JCLSPOTH BLDSMPDB - flexible job manager creates day/week/etc
JCLSPSMA PDBs using the UTILBLDP execution preceding
JCLSPSMB its invocation to define the PDB contents.
JCLSPSMC Processes SMF and non-SMF data records.
JCLSPSMD
JCLSPSME JCLSPxxx is a family of jobs to read "split" subsets of
JCLSPUOW SMF and other data records to parallelize the BUILDPDB,
JCLSPWEK using the above+ UTILBLDP and BLDSMPDB members:
VMXGALOC JCLSPGDG - run once to create GDGs, and then never again
VMXGPARS unless there is a need to alter a GDG base or
May 16, 2011 to change dataset names.
Nov 9, 2011 JCLSPLIT - first job in daily stream - standalone -
splits the daily SMF into pieces for
subsequent processing
SMF.ALL - All SMF for archive
SMF.CICS - SMF 110.1
SMF.DB2 - SMF 101/102
SMF.IO - SMF 14/15/42/61/65/66/74/240/241
SMF.MQ - SMF 115/116
SMF.SPLITPDB - All other SMF records
JCLSPSMA/JCLSPSMB/JCLSPSMC/JCLSPSMD/JCLSPSME can be run
concurrently to process the split SMF files:
JCLSPSMA - Read only CICS SMF 110, create:
CICSTRAN.CICSTRAN CICSBAD.CICSBAD.
JCLSPSMB - Read only DB2 SMF 101/102, create:
PDB: DB2ACCT DB2ACCTB DB2ACCTG DB2ACCTP DB2ACCTR
ASUMDB2A ASUMDB2B ASUMDB2G ASUMDB2P ASUMDB2R
JCLSPSMC - Read only I/O records, create:
PDB: TYPE1415 TYPE42AD TYPE42AU TYPE42CC TYPE42CU
TYPE42CV TYPE42DS TYPE42EX TYPE42NF TYPE42NU
TYPE42SC TYPE42SR TYPE42TO TYPE42VL TYPE42VS
TYPE42VT TYPE42XR TYPE42XV TYPE42S1 TYPE42S2
TYPE42S3 TYPE42S4 TYPE42D1 TYPE42D2 TYPE42D3
TYPE42D4 TYPE42L1 TYPE42L2 TYPE42P1 TYPE42P2
TYPE42P3 TYPE42X1 TYPE42X2 TYPE42X3 TYPE42X4
TYPE4220 TYPE4221 TYPE422A TYPE4222 TYPE4223
TYPE4224 TYPE424A TYPE4225 TYPE4226 TYPE4237
TYPE6156 TYPE64 TYPE64X TYPE74 TYPE74CA
TYPE74ID TYPE74CF TYPE74CO TYPE74LK TYPE74ME
TYPE74OM TYPE74PA TYPE74ST TYPE74DU TYPE74SY
TYPE74TD TYPE746B TYPE746F TYPE746G TYPE747P
TYPE747C TYPE748 TYPE748A TYPE748R TYPE748X
HSMDSRST HSMFSRBO HSMFSRST HSMFSRTP HSMDSRFU
HSMVSRFU HSMVSRST HSMWWFSR HSMWWVOL
JCLSPSMD - Read only MQ records, create:
PDB: MQCFSTAT MQMACCT MQMACCTQ MQMBUFER MQMCFMGR
MQMLOG MQMMSGDM MQMQUEUE
JCLSPSME - Read all remaining SMF, create:
ASUM70GC ASUM70GL ASUM70LP ASUM70PR ASUMCEC
ASUMCELP ASUMTALO ASUMTAPE CICEODRV CICINTRV
CICREQRV CICRRTRV CICSEXCE CICSYSTM CICUSSRV
DB2GBPAT DB2GBPST DB2STAT0 DB2STAT1 DB2STAT2
DB2STAT4 DB2STATB DB2STATR DB2STATS DDSTATS
IPLS IPLSMF JOBS NJEPURGE PRINT
RMFINTRV RMFWKLRV SMFINTRV SMFRECNT SPIN26
SPIN30TD SPIN30_1 SPIN30_4 SPIN30_5 SPIN6
SPINRMFI SPINTALO SPUNJOBS STEPS TAPEMNTS
TAPES TYPE0203 TYPE23 TYPE30MR TYPE30MU
TYPE30OM TYPE30_6 TYPE7 TYPE70 TYPE7002
TYPE70EN TYPE70PR TYPE70X2 TYPE70Y2 TYPE71
TYPE72 TYPE7204 TYPE725A TYPE725B TYPE725C
TYPE725D TYPE725E TYPE725F TYPE725G TYPE725H
TYPE725I TYPE725J TYPE725K TYPE725L TYPE725M
TYPE72DL TYPE72GO TYPE72MN TYPE72SC TYPE73
TYPE73L TYPE73P TYPE75 TYPE77 TYPE78
TYPE78CF TYPE78CU TYPE78IO TYPE78PA TYPE78SP
TYPE78VS TYPE89 TYPE892 TYPE89I TYPESTAT
TYPESYMT TYPESYSL TYPETALO TYPETARC TYPETMNT
TYPETSWP
JCLSPOTH - DCOLLECT, TMC.
JCLSPUOW - after JCLSPLTA and JCLSPLTB have run,
build PDB.ASUMUOW from CICSTRAN and DB2ACCT,
build PDB.CICS from PDB.ASUMUOW.
Nov 9: (+1) instead of (0) for PDB and SPIN
DDnames, and DISP/SPACE parameters added
JCLSPCPY - Copies these datasets into PDB library:
ASUMCACH CICS ASUMUOW ASUMDB:
JCLSPWEK - weekly job using BLDSMPDB to drive the bus
JCLSPMTH - monthly job using BLDSMPDB to drive the bus
BLDSPxxx members are for ASCII execution to create the
same suite of PDB datasets. except that there is no
GDG nor SPLIT members.
BLDSPSMA - Read only CICS SMF 110, create:
CICSTRAN.CICSTRAN CICSBAD.CICSBAD.
BLDSPSMB - Read only DB2 SMF 101/102, create:
PDB: DB2ACCT DB2ACCTB DB2ACCTG DB2ACCTP DB2ACCTR
ASUMDB2A ASUMDB2B ASUMDB2G ASUMDB2P ASUMDB2R
BLDSPSMC - Read only I/O records, create:
PDB: TYPE1415 TYPE42AD TYPE42AU TYPE42CC TYPE42CU
TYPE42CV TYPE42DS TYPE42EX TYPE42NF TYPE42NU
TYPE42SC TYPE42SR TYPE42TO TYPE42VL TYPE42VS
TYPE42VT TYPE42XR TYPE42XV TYPE42S1 TYPE42S2
TYPE42S3 TYPE42S4 TYPE42D1 TYPE42D2 TYPE42D3
TYPE42D4 TYPE42L1 TYPE42L2 TYPE42P1 TYPE42P2
TYPE42P3 TYPE42X1 TYPE42X2 TYPE42X3 TYPE42X4
TYPE4220 TYPE4221 TYPE422A TYPE4222 TYPE4223
TYPE4224 TYPE424A TYPE4225 TYPE4226 TYPE4237
TYPE6156 TYPE64 TYPE64X TYPE74 TYPE74CA
TYPE74ID TYPE74CF TYPE74CO TYPE74LK TYPE74ME
TYPE74OM TYPE74PA TYPE74ST TYPE74DU TYPE74SY
TYPE74TD TYPE746B TYPE746F TYPE746G TYPE747P
TYPE747C TYPE748 TYPE748A TYPE748R TYPE748X
HSMDSRST HSMFSRBO HSMFSRST HSMFSRTP HSMDSRFU
HSMVSRFU HSMVSRST HSMWWFSR HSMWWVOL
BLDSPSMD - Read only MQ records, create:
PDB: MQCFSTAT MQMACCT MQMACCTQ MQMBUFER MQMCFMGR
MQMLOG MQMMSGDM MQMQUEUE
BLDSPSME - Read all remaining SMF, create:
ASUM70GC ASUM70GL ASUM70LP ASUM70PR ASUMCEC
ASUMCELP ASUMTALO ASUMTAPE CICEODRV CICINTRV
CICREQRV CICRRTRV CICSEXCE CICSYSTM CICUSSRV
DB2GBPAT DB2GBPST DB2STAT0 DB2STAT1 DB2STAT2
DB2STAT4 DB2STATB DB2STATR DB2STATS DDSTATS
IPLS IPLSMF JOBS NJEPURGE PRINT
RMFINTRV RMFWKLRV SMFINTRV SMFRECNT SPIN26
SPIN30TD SPIN30_1 SPIN30_4 SPIN30_5 SPIN6
SPINRMFI SPINTALO SPUNJOBS STEPS TAPEMNTS
TAPES TYPE0203 TYPE23 TYPE30MR TYPE30MU
TYPE30OM TYPE30_6 TYPE7 TYPE70 TYPE7002
TYPE70EN TYPE70PR TYPE70X2 TYPE70Y2 TYPE71
TYPE72 TYPE7204 TYPE725A TYPE725B TYPE725C
TYPE725D TYPE725E TYPE725F TYPE725G TYPE725H
TYPE725I TYPE725J TYPE725K TYPE725L TYPE725M
TYPE72DL TYPE72GO TYPE72MN TYPE72SC TYPE73
TYPE73L TYPE73P TYPE75 TYPE77 TYPE78
TYPE78CF TYPE78CU TYPE78IO TYPE78PA TYPE78SP
TYPE78VS TYPE89 TYPE892 TYPE89I TYPESTAT
TYPESYMT TYPESYSL TYPETALO TYPETARC TYPETMNT
TYPETSWP
BLDSPOTH - DCOLLECT, TMC.
BLDSPUOW - after JCLSPLTA and JCLSPLTB have run,
build PDB.ASUMUOW from CICSTRAN and DB2ACCT,
build PDB.CICS from PDB.ASUMUOW.
BLDSPWEK - weekly job using BLDSMPDB to drive the bus
BLDSPMTH - monthly job using BLDSMPDB to drive the bus
Change 29.104 -Interval summarization of CICS Statistics CICLDR dataset
ASUMCLDR in PDB.ASUMCLDR and Trending in TREND.TRNDCLDR is useful
TRNDCLDR to track CICS Program Loader activity.
TRNDCELP -Trending for ASUMCELP and ASUM70LP per-LPAR datasets,
TRND70LP adds zIIP, zAAP, and IFL statistics.
May 1, 2011
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 29.103 New option RESULTS=FINDVAR will find every dataset in
VMXGSRCH every allocated LIBNAME, or in specific LIBNAMES, that
May 1, 2011 contains any of the variables listed in VARS= argument.
Jul 8, 2011 With FINDVAR option, the VALUE= argument is ignored.
Jul 2011: COUNT option was restored in code, was lost.
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 29.102 Change 29.052 documented this MONTHxxx error 180-322:
ANALDB2R
MONTHASC NOTE: Line generated by the macro function "SUBSTR".
MONTHBL3 18 ;SET MON.XXXXXX TUE.XXXXXX WED.XXXXXX THU.XXXXXX
MONTHBLD ---
MONTHDSK 180
READDB2 ERROR 180-322: Statement is not valid or it is used out
UTILBLDP of proper order.
VMXGSUM
May 2, 2011 was caused by the %CMPRES macro (in SASAUTOS) generating
a line of code when it should have stored that text in a
macro variable, and that this "SAS V9.1.3 ONLY" error was
circumvented by replacing %CMPRES with %QCMPRES. But this
error is also in SAS V9.2, both ASCII and z/OS platforms,
on May 1, but not on May 2. On May 1, a Sunday, with the
default STARTDAY of MON, the to-be-generated SET statement
has the (maximum) of six daily and five weekly elements,
which tripped up %CMPRES, while %QCMPRES worked fine.
But on May 2, with only five week tokens to be generated,
both %CMPRES and %QCMPRES worked fine.
-Detailed traces with all possible %MACRO debugging options
failed to reveal the actual cause of the error.
-But, the SAS documentation for %CMPRES and %QCMPRES states
"The %CMPRES and %QCMPRES macros compress multiple blanks
and remove leading and trailing blanks. If the argument
might contain a special character or mnemonic operator:
& % ' " ( ) + - * / < > = ¬ ^ ~ ; , # blank
AND OR NOT EQ NE LE LT GE GT IN
use %QCMPRES.
%CMPRES returns an unquoted result, even if the argument
is quoted.
%QCMPRES produces a result with the special characters
and mnemonic operators masked, so the macro processor
interprets them as text instead of as elements of the
macro language."
Since all MXG uses of %CMPRES are objects of a %LETs for a
text string, and since some of those text strings can have
those special characters, all %CMPRES are now %QCMPRES.
Thanks to Rodger Foreman, Acxiom, USA.
Change 29.101 Support for z/VM 6.2, COMPATIBLE RECORD CHANGES BY IBM.
EXIODMDE IBM's MONWRITE/MONDATA file changes WERE COMPATIBLE, but
EXISFILC MXG code might fail if you create SYTLCK (0.23) records;
EXISFISA See note at bottom to read 6.2 data with prior MXG code.
EXISFISC z/VM 6.2 MONWRITE is a MAJOR enhancement, with these 19
EXISFNOD new records (VXPRCMFC has the z/OS SMF 113 Counters!):
EXMTRILC DMN REC DDDDDD DATASET DESCRIPTION
EXMTRISC 1 23 MTRISC VXMTRISC ISFC End Point Configuration
EXMTRSSI 1 24 MTRILC VXMTRILC ISFC Logical Link Configuration
EXMTRTOP 1 25 MTRSSI VXMTRSSI SSI Configuration Information
EXPRCMFC 1 26 MTRTOP VXMTRTOP System Topology
EXPRCTOP 4 11 USERLS VXUSERLS Guest Relocation Started
EXSSISCH 4 12 USERLS VXUSERLS Guest Relocation Ended
EXSSISLT 5 13 PRCMFC VXPRCMFC CPU-Measurement Facility
EXSSISMI
EXSSISCS 5 14 PRCTOP VXPRCTOP System Topology
EXSSIXDI 6 31 IODMDE VXIODMDE Minidisk Activity
EXSSIXLK 9 1 ISFISC VXISFISC ISFC End Point Status Change
EXUSERLS 9 2 ISFISA VXISFISA ISFC End Point Activity
EXUSERLS 9 3 ISFILC VXISFILC ISFC Logical Link Def Change
FORMATS 9 4 ISFNOD VXISFNOD ISFC Logical Link Activity
IMACVMXA 11 1 SSISSC VXSSISSC State Change Synch Activity
VMACVMXA 11 2 SSISMI VXSSISMI State/Mode Information
VMXGINIT 11 3 SSISCH VXSSISCH State Change/Event
May 6, 2011 11 4 SSISLT VXSSISLT Slot Definition
Oct 22, 2011 11 6 SSIXLK VXSSIXLK XDISK Serialization Sample
Nov 2, 2011 11 7 SSIXDI VXSSIXDI XDISK Activity
and with changes to these 36 existing datasets:
0 VXSYTPRP (0.02) VXSYTRSG (0.03) VXSYTSHS (0.07)
VXSYTUSR (0.08) VXSYTUWT (0.12) VXSYTSCP (0.13)
VXSYTXSG (0.14) VXSYTCUM (0.17) VXSYTLCK (0.23)
1 VXMTREPR (1.01) VXMTRSYS (1.04) VXMTRPRP (1.05)
VXMTRDEV (1.06) VXMTRMEM (1.07) VXMTRSPR (1.09)
VXMTRDDR (1.14) VXMTRUSR (1.15) VXMTRCCC (1.18)
2 VXSCLSHR (2.09) VXSCLIOP (2.11)
3 VXSTORSG (3.01) VXSTORSP (3.02) VXSTOASP (3.04)
VXSTOADD (3.21)
4 VXUSELON (4.01) VXUSELOF (4.02) VXUSEACT (4.03)
VXUSEINT (4.04) VXUSEATE (4.09)
5 VXPRCCFN (5.06) VXPRCCFF (5.07) VXPRCAPC (5.09)
6 VXIODVON (6.01) VXIODVSW (6.21)
8 VXVNDSES (8.01)
10 VXAPLSDT (10.02)
-Dataset VXPRCMFC is created with TYPE113 variable names,
including all of the metrics from John Burg's papers, so
the existing ASUM113 dataset can be used to summarize the
new hardware counters from either z/VM or z/OS records.
-The sort order was changed on some existing datasets that
had not previously been validated for the NODUP option.
The _Bdddrrr "BY LIST" macro for each dataset has been
validated to ensure that PROC SORT NODUP; BY _Bdddrrr;
removes duplicates; some existing dataset's _Bdddrrr list
was insufficient and had to be extended to ensure the
physical adjacency of duplicate records.
The validation reads the same MONWRITE file twice and
the _SVMXA macro sorts all datasets. The SAS log
message for each sort is examined to ensure that
exactly one half of the input observations were
reported as duplicates.
-The validation of the BY LIST with NODUP is NOT because
MONWRITE has a duplicate record problem; it is required
for the DIF() validation of the MXG deaccumulation logic.
Because MONWRITE records contain accumulated values, the
deaccumulation logic (a DATA step in the _Sdddrrr macro)
uses the same "BY LIST" _Bdddrrr macro as the NODUP did.
The deaccumulated datasets are then examined with PROC
MEANS for MIN. If a non-accumulated field (cardinal,
min, max, end point) is deaccumulated, or if its sort
order is not correct, its minimum value will be negative.
-This change was a significant project; there were 3417
source lines inserted, and 730 lines deleted in the main
VMACVMXA code member, which now has 24,653 lines. The
update took from Monday thru Saturday, 40-50 hours.
I documented the original VM/XA MONWRITE development in
1988, 150 hours across 10 days for 75 datasets and 15,000
lines, I think, but I can't find that note right now!
-Not new in z/VM 6.2, but it has always been the case that
when the same MONWRITE data file was read twice, two MXG
created datasets had an odd number of observations, where
an even number should have been created. The two datasets
VXMTREPR (1.01) and VXMTRDDR (1.14) records are written
at MONITOR START, but prior to the MTRSYS (1.04), which
contains the GMT Offset (SYSZONE) value. MXG deletes
records with SYSZONE missing, because the MRHDRTOD can't
be converted to local time and thus is unknown.
But because SYSZONE is retained so it can be used for all
other records in this collect, if data from a different
system is concatenated, the new system's 1.01 record will
use the non-missing SYSZONE from the prior system and was
output with the wrong MRHDRTOD value. Fortunately, IBM
has added SYSZONE field to 1.01 MONITOR START record so
the MXG logic now exploit that addition and will use the
1.01 for MONITOR START when it contains SYSZONE.
-Also not new in z/VM 6.2, there is no SYNC option to make
MONWRITE interval records synchronized with TIME of DAY;
the intervals when the MONITOR SAMPLE INTERVAL or the
MONITOR START command is issued. A formal requirement
has just been submitted, and this text will be updated if
IBM accepts that request. In the interim, this example
from IBM can be used to STOP and reSTART the monitor with
TOD synchronization to second zero of the next minute:
/* Make the monitor intervals start on second zero */
'CP MONITOR STOP'
Parse value time('N') with hh ':' mm ':' ss .
mm=mm+1 /* Wait for the next minute*/
If ss=59 then mm=mm+1 /*May need a bit more time*/
If mm>60 then do /* Overflow to the hour*/
mm=mm-60
hh=hh+1
end
'WAKEUP' hh':'right(mm,2,0)':00' /*Wait*/
'CP MONITOR START' /*Start the monitor*/
Exit
Note: changing the mm=mm+1 to hh=hh+1
and changing to 'WAKEUP' hh':00:00'
will cause MONWRITE data to be on an hourly boundary.
-CIRCUMVENTION TO SKIP MONWRITE 0.23 SYTLCK RECORD:
To process z/VM 6.2 records with MXG 29.03 or earlier,
this code will skip all 0.23 records:
//SYSIN DD *
%LET MACVMXX=
%QUOTE(
IF MRHDRDM=0 AND MRHDRRC=23 THEN DO;
INPUT +SKIP @;
SKIP=0;
MRHDRDM=-99;
MRHDRRC=-99;
GOTO MWENDIT;
END;
);
%INCLUDE SOURCLIB(....);
Change 29.100 Support for GDPS Global Mirror V3R8 SMF ID=105 record,
EXTY1051 which creates these two new datasets:
EXTY1052 dddddd Dataset Description
IMAC105 TY1051 TYPE1051 GDPS SESSION DATA
VMAC105 TY1052 TYPE1052 GDPS LOGICAL SUBSYSTEM DATA
VMXGINIT
Apr 28, 2011
Thanks to Paul Volpi, UHC, USA.
Change 29.099 Omegamon User SMF "OMCI" record tested for versions before
VMACOMCI testing for SUBTYPE and RECSUBTY, and records from the old
Apr 27, 2011 version 420 printed error messages that that version was
unknown. But these were ID=112 records with SUBTYPE=203
and RECSUBTY=0, which are "112s" and not "OMCI", so the
code now accepts '420' for version but also deletes these
non-OMCI records ahead of the version test.
Thanks to Richard Schwartz, State Street Bank, USA.
Change 29.098 Variables ICFCPUS, IFLCPUS, IFACPUS, ZIPCPUS, only in the
VMXG70PR PDB.ASUMCEC dataset, were wrong (too high, they were the
Apr 27, 2011 SUM across all LPARs with those specialty engines).
Thanks to Otto Burgess, OPM, USA.
Change 29.097 INPUT STATEMENT EXCEEDED (on z/OS), INVALID FLOATING POINT
EXCICRDD (on ASCII) SMF 110 subtype 1 MNSEGCL=5 records, if any DPL
IMAC110 DPL Resource Segments exist (i.e., MNR5NUMX GT 0).
VMAC110 DPL segments, new in CICS/TS 4.1, were not input, causing
VMXGINIT mis-alignment, but they now create new CICSRDPL dataset.
Apr 26, 2011 Also, new variables added by CICS/TS 4.1 are now output
in the existing CICSRDS dataset that were overlooked.
Thanks to Paul Volpi, UHC, USA.
Change 29.096 Documentation only. APAR PK99058 corrects Tivoli Storage
VMAC42 Manager z/OS Server Accounting Record CPU usage field,
Apr 25, 2011 (variable CLICPUTM in TYPE42AD), in TSM Version 5.5 only,
which had failed to populate that field.
Thanks to Jacob Nudel, Thomson Reuters, USA.
Change 29.095 Parameter DALYKEEP= added to bldsmpdb to control which
BLDSMPDB dataset are selected by the PROC COPY from the PDB into
Apr 22, 2011 the Day-Of-Weed dataset, and can be a SELECT statement or
====== Changes thru 29.094 were in MXG 29.03 dated Apr 19, 2011========
Change 29.094 MXG 29.03 Dated APR 11: ALL CICSTRAN TIME VARIABLES WRONG
VMAC110 (if you did NOT use UTILEXCL to create IMACEXCL). A mass
Apr 19, 2011 change command went awry and inserted 16* in all of the
time duration variables in blocks of "fall thru" code for
CICS/TS 3.2 or later. This SHOULD have printed the MXG
***ERROR VMAC110: CPU 10X LARGER THAN ELAPSED.
See Change 29.076 for the CPU 10X LARGER enhancement.
Thanks to Matthew Chappell, Dept. of Transport Main Roads, AUSTRALIA
Change 29.093 INPUT STATEMENT EXCEEDED for subtype 79; value '1120' was
VMAC85 added to the two tests for variable R85PVRM in the block
Apr 18, 2011 that reads subtype=79, support z/OS 1.12 INCOMPAT change.
Thanks to Robert Chavez, Florida Power and Light, USA.
Change 29.092 Variables ZIPCPUS and IFACPUS in PDB.ASUMCEC/PDB.ASUM70PR
VMXG70PR were the average number online, but that included parked
Apr 13, 2011 time. They are now corrected to count the number of
AVERAGE*ONLINE*NOTPARKED specialty engines. Variables
NRZIPCPU and NRIFACPU are the number installed.
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 29.091 If MXG's default COMPRESS=YES is changed to COMPRESS=NO,
VMAC102 all SQL Text variables are broken into 100 byte chunks
Apr 13, 2011 and multiple observations are created in the T102Tnnn
datasets, but the last two characters of each chunk have
been missing since DB2 V8.1 changed the structure of
the length fields; MXG still subtracted 2 bytes which it
should not have. DB2 SQL text is created in these IFCIDS:
63 124 140 141 142 145 168 which are now all corrected.
Thanks to Mark Tomlinson, Lloyds Banking, ENGLAND.
Thanks to Stephen Hoar, Lloyds Banking, ENGLAND.
Change 29.090 Typo for the IMS08D and IMS0A08 datasets _Wdddddd entries
VMACIMS had _VIMS08 _KIMS08 which are now _VIMS08D _KIMS08D and
Apr 13, 2011 _VIMS0A8 and _KIMS0A8 respectively. Since the _VIMS08
and _VIMS08D keep the same variables, the IMS0708 dataset
was not impacted, and, fortunately, no one uses IMS0A78.
Thanks to Rudolf Sauer, T-Systems, GERMANY
Change 29.089 -The z/VM MONWRITE dataset PDB.VXBYUSR has one observation
VMACVMXA for every VMDCPUAD (CPU ADDRESS) configured for each VM,
VMXGINIT so it doesn't have the interval total for each machine.
Apr 13, 2011 The new PDB.VXINTUSR sums PDB.VXBYUSR to create one obs
for each interval for each machine, counting configured
(ENGCONFG) and online (ENGONLIN) engines.
-Variables VMDVTMP VMDTTMP VMDVTMS VMDTTMS are correctly
deaccumulated with this change.
Thanks to Ron Lewis, State Street Bank, USA.
Change 29.088 These "user id" variables are added to TMDBDB2 dataset
VMACTMDB DBHCEUID DBHCEUTX DBHCEUWN
Apr 12, 2011 (and should have been added a long time ago!).
Thanks to Patricia Abel, Regie des rentes du Quebec, CANADA.
Thanks to Liliane Paquet, Centre de services partages Quebec, CANADA.
Change 29.087 Comments in IMACIMS7 and IMACIMS7 for _IMSVERS values are
IMACIMS inconsistent; 10.1 or 11.1 were listed, but the values
Apr 12, 2011 needed are only 10.0 and 11.0 (so the misleading values
worked fine!).
And Change 28.311 did not change the datasets created;
that change only restructured the internal IMS processing
code to separate and then recombine the TM and DBCTLs.
Thanks to Daniel Strgarsek, SAS Institute, GERMANY.
====== Changes thru 29.086 were in MXG 29.03 dated Apr 11, 2011========
Change 29.086 The QA conflict report from DOCVER showed SYSTEM was $8
ANALID in PDB.SMFRECNT, but SYSTEM is always $4. After 2 hours
Apr 10, 2011 of tests with inserted PROC CONTENTS, I found it only
occurred when there were no observations in TYPEID, which
is normal for the QASAS job that creates DOCVER, and then
remembered that when the old PROC FREQ was replaced with
the enhanced ANALID (with PROC TABULATE to capture both
counts and bytes), an extra step was needed to create the
PDB.SMFRECNT (because PROC TABULATE didn't, with no obs),
and finally found the statement SYSTEM=' '; that
should have been SYSTEM=' '; to set its length to $4.
Change 29.085 -Revision to limit search to the LIBNAME requested and a
VMXGSRCH missing semicolon was inserted, although no syntax error
Apr 10, 2011 was reported.
-If VARS= is specified without VALUE=, the results are the
list of datasets that contain that variable.
Change 29.084 -Temporary dataset MXGENG is now deleted by VGETENG.
VGETENG -Variables QWHSACE QWHSMTN QWACACE ACE are now consistent
VMACDB2 LENGTH 5 and FORMAT HEX8 addresses, QWARACE is LENGTH 8
VMAC102 and FORMAT HEX16 in VMACDB2/VMACDB2H/VMAC102.
VMACDB2H -Variables TOKLEN and TOKVERS in VMAC80A are labeled.
VMAC80A -Variable CTGAPPLQ is labeled, comments for CTGAPLID now
VMAC111 match in VMAC111.
Apr 10, 2011
Thanks to Chris Weston, SAS/ITRM Development, USA.
Change 29.083 -Variable QWAXOTSE was added twice in three places; it was
ANALDB2R not detected because it was zero in the test SMF data.
Apr 9, 2011 -May 1: The formula for calculating the average time (per
May 1, 2011 thread) that was "not accounted for" was revised, thanks
to this equation provided by IBM DB2 Support in response
to a customer PMR, i.e., the Class 2 Elapsed times minus
the sum of Class 2 CPU and Class 3 Suspension durations:
AVG=(
/*** CLASS 2 ELAPSED ***/
SUM(QWACASC+QWACSPEB+QWACUDEB+QWACTRET+QWACTREE,0)
/**** CLASS 2 CPU ****/
-SUM(QWACAJST,QWACSPTT,QWACUDTT,QWACTRTT,QWACTRTE,0)
/**** CLASS 3 SUSPENSIONS ****/
-SUM(QWACAWTL,QWACAWTI,QWACAWTR,QWACAWTW,QWACAWTE,
QWACALOG,QWACAWAR,QWACAWDR,QWACAWCL,QWACAWTP,
QWACCAST,QWACAWTG,QWACAWTJ,0))/THREADS;
-The Accounting Trace Reports had many fields missing in
the headers because they had not been listed in the
SORTBY= arguments.
-For the ACCOUNTING reports, selection was not being done.
If you specified DB2=DB20 you still got all of the data
for all of the subsystems.
Thanks to Neil Ervin, Wells Fargo Bank, USA.
Change 29.082A Using PDB.ASUMCEC/PDB.ASUMCELP is STRONGLY RECOMMENDED
ASUM70PR because PDB.ASUM70PR/ASUM70LP CAN BE TERRIBLY WRONG for
Apr 9, 2011 many of the LPAR-Specific Variables, when IRD is active
and/or Hiperdispatch is enabled. In those environments,
only the "LPn" variables for the "THIS LPAR" observation
(i.e., "THIS SYSTEM") in "SYSTEM-LEVEL" ASUM70PR/ASUM70LP
datasets are always valid. These LPAR-Specific variables:
LPnNRPRC LPnDUR LPnLAC LPnONT LPnPAT LPnWST
LPCTnBY LPCTnOV
LPnZIUTM LPnZIKTM LPnIFUTM LPnIFKTM
will be WRONG in the ASUM70PR/ASUM70LP observations from
the "OTHER LPARs", because those LPAR-Specific variables
are based on SMF70ONT/SMF70PAT, which are ONLY valid in
the "THIS LPAR" observation.
This PROC PRINT shows the six ASUM70PR observations from
each of six SYSTEMs, with the set of LPAR-Specific fields
for LPAR 2 (SYSA). You can see that ONLY the observation
in ASUM70PR for SYSTEM=SYSA, the "THIS LPAR, THIS SYSTEM"
observation, are valid and match the ASUMCEC observation:
(Note that not ALL of the variables are WRONG!).
SYSTEM LP2NAME LP2DUR LP2UPDTM LP2UEDTM LP2MGTTM
******
SYSK SYSA 6:00:00.01 1:21:32.11 1:21:00.97 0:00:31.14
SYSA SYSA 2:33:48.28 1:21:31.41 1:21:00.27 0:00:31.14
SYSC SYSA 6:00:00.43 1:21:32.38 1:21:01.24 0:00:31.14
SYSD SYSA 6:00:00.30 1:21:32.50 1:21:01.36 0:00:31.14
SYSG SYSA 6:00:01.16 1:21:32.21 1:21:01.07 0:00:31.14
SYST SYSA 6:00:00.09 1:21:32.20 1:21:01.07 0:00:31.14
ASUMCEC: SYSA 2:33:48.28 1:21:31.41 1:21:00.27 0:00:31.14
SYSTEM LPCT2BY LPCT2OV PCTL2BY PCTL2OV LP2NRPRC LP2BDA
******* ******* ********
SYSK 22.64 0.14416 22.6486 0.14416 6.0 8
SYSA 53.00 0.33744 22.6521 0.14421 2.6 8
SYSC 22.64 0.14416 22.6495 0.14416 6.0 8
SYSD 22.65 0.14417 22.6502 0.14417 6.0 8
SYSG 22.64 0.14416 22.6479 0.14416 6.0 8
SYST 22.64 0.14416 22.6490 0.14416 6.0 8
ASUMCEC: 53.00 0.33744 22.6454 0.14416 2.6 8
SYSTEM LP2SHARC LP2SHARE LP2LAC LP2MSU LP2MSUHR
******
SYSK 16.2389 13 . 129.378 129.378
SYSA 16.2420 13 29.2360 129.360 129.398
SYSC 16.2389 13 . 129.385 129.383
SYSD 16.2389 13 . 129.388 129.387
SYSG 16.2389 13 . 129.381 129.374
SYST 16.2389 13 . 129.381 129.380
ASUMCEC: 16.2420 13 29.2360 129.360 129.360
SYSTEM LP2CSF LP2ONT LP2WST LP2ZIPTM
****** ******
SYSK 10G 6:00:00.01 3:59:14.35 0.00:18.94
SYSA 10G 2:33:47.23 0:33:06.46 0.00:18.94
SYSC 10G 6:00:00.43 3:59:15.35 0.00:18.94
SYSD 10G 6:00:00.30 3:59:15.46 0.00:18.94
SYSG 10G 6:00:01.16 3:59:15.21 0.00:18.94
SYST 10G 6:00:00.09 3:59:14.81 0.00:18.94
ASUMCEC: 10G 2:33:47.23 0:33:06.46 0.00:18.94
SYSTEM LP2ZIUTM LP2ZIKTM LP2ZIWTM
******** ******** ********
SYSK 2:00:00.00 . 1:59:41.11
SYSA 1:59:57.87 0:00:00.00 1:59:38.98
SYSC 2:00:00.14 . 1:59:41.25
SYSD 2:00:00.10 . 1:59:41.20
SYSG 2:00:00.39 . 1:59:41.49
SYST 2:00:00.03 . 1:59:41.13
ASUMCEC: 1:59:57.87 0:00:00.00 1:59:38.98
The non-LPAR-Specific variables ARE VALID; it's ONLY the
variables identified above that can be WRONG.
-And, for ASUMCEC to ALWAYS BE RIGHT, you MUST have READ
the PDB.TYPE70PR observations FOR ALL LPARS (ALL SYSTEMS)
as input to ASUM70PR when you create PDB.ASUMCEC/CELP.
-This change was ONLY documentation; no code was changed.
Thanks to Larry Stahl, IBM Global Services, USA.
Change 29.082 The default ASUM70GC/ASUM70GL interval was hard coded at
VMXG70PR HOUR, which matched the default for ASUMCEC/ASUMCELP, but
Apr 9, 2011 now INTERVAL=&CECINTRV is used so the group data interval
matches the CEC interval data, if you change CECINTRV.
With hindsight, these two datasets should have been named
ASUMCEGC and ASUMCEGL because both are summarized at the
CEC level (e.g., by CECSER, and NOT by SYSPLEX SYSTEM),
but it's too late to change dataset names now.
-New variable MAX70NSW, the maximum percent of time when
the LPAR was soft-capped, is now created in PDB.ASUM70GL,
as the hourly average in SMF70NSW could mask intervals
that were capped.
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 29.081 -Support for SMF 120 Subtype 9 User Field SM1209FH creates
VMAC120 that variable in dataset TYP1209E. While up to 5 user
VMXGINIT segments of 2048 bytes each per record can be created,
Apr 8, 2011 this change keeps only the first segment, and only the
Nov 8, 2011 first 12 bytes of the optional field are kept in SM1209FH
although temporary variable SM1209F input all 2048 and is
to be used as the source of SM1209FH, which can contain
HEX, EBCDIC or ASCII text. The MXG default is ASCII, to
match the original test data that was received, but that
can be tailored if you have EBCDIC or HEX data values.
-Variable SM1209FB is the data length in SM1209FH, and the
variable SM1209FF contains the user-chosen datatype, and
temporary variable SM1209F was input with $VARYING2048.,
so if your 12-bytes were EBCDIC instead of MXG's ASCII
default, then you would insert this statement
SM1209FH=INPUT(SM1209F,$EBCDIC12.);
in your EXT1209E to input the text as EBCDIC, and/or
you could use your installer's chosen SM1209FF datatype
value to conditionally input as ASCII/EBCDIC/SUBSTR/etc.
-The length of a character variable can NOT be changed in
a dataset exit member EXddddd. Only numeric variables
can have their length changed in a dataset exit member,
as SAS uses the first instance for character length and
the last LENGTH statement for numeric variables.
-The existing IMACFILE/MACFILE exit is taken before the
LENGTH statements in all VMACs are compiled, so it could
be used to change length of SM1209FH with this syntax:
//SYSIN DD *
%LET MACFILE= %QUOTE( LENGTH SM1209FH $40; );
%INCLUDE SOURCLIB(BUILDPDB);
in the job that reads the SMF 120 records. However that
is not the real purpose of the IMACFILE exit, and it may
already exist for record selection, and the insertion of
the LENGTH statement could cause non-fatal messages with
UNINITIALIZED VARIABLE SM1209FH if the program that is
%INCLUDEd doesn't process SMF 120 records. Using MACFILE
is totally slick but not righteous; there's a better way.
-Nov 8: This change creates macro variable &VARSM1209FHLN
in VMXGINIT and uses it LENGTH SM1209FH $&VARSM1209LN;
in VMAC120, so that the default of 8 can be more easily
changed (for example, to $40) and converted to EBCDIC:
//SYSIN DD *
%LET MACKEEP=
%QUOTE (
MACRO _ET1209E
SM1209FH=INPUT(SM1209F,$EBCDIC12.);
%%
);
%LET VARSM1209FHLN=12;
%INCLUDE SOURCLIB(BUILDPDB);
-Nov 8: Change text was completely rewritten.
Thanks to Larry Gray, Lowe's Companies, USA.
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 29.080 -New variables from Meral's excellent SHARE paper at
VMAC113 http://share.confex.com/share/116/webprogram/authort.html
Apr 7, 2011 are created in TYPE113 and ASUM113 datasets:
Apr 19, 2011 DWINSORM='DIR WRITES*L1 INST CACHE*FROM REMOTE'
DWDASORM='DIR WRITES*L1 DATA CACHE*FROM REMOTE'
with different equations for z10 vs z196 calculation.
-These original z10 counters were defined as:
EXTND128='DIRWRIT*TO L1-I*RETURNED*FROM L2'
EXTND129='DIRWRIT*TO L1-D*INSTLD*FROM L2'
but the z196 reversed contents so the labels are changed
EXTND128='DIRWRIT*TO L1-D*RETURNED*FROM L2'
EXTND129='DIRWRIT*TO L1-I*INSTLD*FROM L2'
with the Data count in 128 and the Instructions in 129.
Since there is no way to have two different labels for
the same SAS variable, I chose to use the z196 choice,
hoping z10 users will find this note. Fortunately, all
calculations use the sum of this pair of counters, so the
impact is minor unless you are looking in great detail
level for the old z10 processor.
Apr 19: SM113DOL corrected to SM113DON.
Thanks to Meral Temel, Garanti Teknoloji, TURKEY.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Thanks to Chris Weston, SAS ITRM Development, USA.
Change 29.079 MXG will now ABEND if SMFTIME is invalid. Occasionally,
VMACSMF using the SAS ftp access method, SAS would stop after
Apr 7, 2011 writing a horrendous SAS log (6 MILLION PAGES, not lines)
of MXG messages "FIRST RECORD IN GROUP SYSTEM= SMFTIME=".
The rerun was always successful, suggesting the error is
in the ftp Server, but this enhancement will stop the MXG
job by detecting that missing value in SMFTIME.
SAS was executing under Windows/XP with Service Pack 3.
Thanks to Bruce Orr, U.S. Customs and Border Protection, USA.
Change 29.078 Support for OS/400, AS/400, Version 7.1 INCOMPAT (due to
FORMATS IBM change in the LRECL for QAPMDISK file to 539).
VMACQACS Only the QAPMCONF/QAPMDISK/QAPMJOBL/QAPMPOLL/QAPMSYSL
Apr 7, 2011 files have been validated with 7.1 records, so it is
possible other files may also be INCOMPATIBLE. There
are also a number of new files that are not supported,
until a user needs those data and provides test files.
-Dataset QAPMCONF, new variables:
GDESF1T GDESF1S GDESFT GDESG1- GDESG9 GDESGA
GDESHT GDESMT GDESPF
and new formats are created in FORMATS member, so that
you must update your format library.
-Dataset QAPMCONF, new variables
DSPTROP DSPTWOO DSWWWNN
In addition, variable DSIOARN was documented and INPUT as
$EBCDIC15., but data in the records show only 10 bytes so
the INPUT was reduced and PMR was opened with IBM Support
to determine the true length of the field.
Thanks to Paul Naddeo, FISERV, USA.
Thanks to David Bixler, FISERV, USA.
Change 29.077 -Executing z/OS under z/VM caused MXG to print 3 messages:
VMAC7072 MXGNOTE:CPUID SECTION ERROR. INVALID RECORD ... DELETED.
Apr 2, 2011 but the TYPE70 observation had already been output in the
TYPE70SP dataset (thanks to the "Split 70s" redesign, so
nothing was lost). Under z/VM, the CPUID segment of the
RMF 70 record does not exist. The revised message reads:
MXGNOTE: RMF70 CPUID SECTION DOES NOT EXIST
THIS IS NORMAL IF z/OS IS EXECUTING UNDER Z/VM.
OTHERWISE THIS IS AN INVALID RMF 70 RECORD.
-Prior to z/OS 1.12, the PRCS/PRDS segments of the RMF
70 record did not exist when z/OS was run under z/VM.
But in z/OS 1.12, APAR OA35675 captures the CPU dispatch
time of both the z/OS partition and the z/VM "overhead".
See Change 29.127 which added support for that APAR.
-On the topic of z/OS under z/VM, past Newsletters noted:
- To construct the configuration and recording of TYPE78
data, RMF must read the IOCDS data set, but under z/VM,
the IOCDS is not available to z/OS, so some type RMF 78
records will not exist.
- Under z/VM, the RMF I/O Queueing Activity Report shows
only the static configuration data.
-And IBM's Running Guest Operating Systems documents that:
-When you analyze the z/OS environment, remember that
you have two operating systems running in a single
processor. Both z/VM and z/OS are vying for the basic
system resources, such as processor, I/O, storage, and
paging. Each is generating its own accounting
information, and each is supplying its own performance
information.
-Remember that z/OS is unaware that it is running as a
guest under z/VM. What the z/OS guest thinks is
real-time is actually the time-of-day clock and
processor timer facility. Elapsed time as measured by
the time-of-day clock is accurate. The guest's virtual
processor timer (VPT) runs whenever the guest is
dispatched or is in a voluntary wait state. It does not
run if the guest is in a CP wait state. Thus, when z/VM
dispatches another virtual machine and later dispatches
the z/OS guest, z/OS does not realize it had stopped
running.
-Information about guest system performance is
frequently published in Washington System Center
flashes. Contact your marketing team for obtaining
flashes that pertain to your particular installation.
-And IBM's RMF Programmer's Guide documents for z/VM:
-Partition Defined Capacity Used Percent is zero.
-And IBM's RMF Reports Manual documents for z/VM:
-When Channel Path Measurement Facility (CPMF) is not
available, for example, on z/OS systems running as z/VM
guests, RMF uses sampled data from SRM so that the
reported channel utilization is only an approximate
value. With increasing channel speed, the channel
utilization value becomes more and more inaccurate.
Therefore, in such cases, RMF does not provide accurate
values of FICON channel utilization. Beginning with
z990 processors, the channel data from SRM is no longer
available. As a result, the channel utilization data on
a z/OS system running as z/VM guest, is not reported.
-In the DEV and DEVV reports, LCU will be blank if this
is a non-dedicated device in a z/VM guest system
environment.
-Running in a z/VM guest environment, these RMF reports:
Partition Data Report
LPAR Cluster Report
Group Capacity Report
do not exist (because TYPE70PR has zero observations).
Dataset TYPE70 variable VMSYSTEM='Y' for z/OS under VM.
-For the CPU Activity Report:
If RMF is running as a guest under z/VM, it only reports
the z/OS busy time percentage. If you want to measure
partition utilization (as well as the individual CPU
utilization of the single guests, namely LPAR busy time
percentage), you need to use a z/VM monitor.
Thanks to MP Welch, Aprize, USA.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 29.076 CICS CPUTM can significantly exceed ELAPSTM if you have
VMAC110 "knee-capped, i.e. slow" CP engines with zIIP/zAAPS.
Apr 1, 2011 The specific case had CPUTM=25 and ELAPSTM=5 on a CP with
a zAAP that was 10 times faster (or that CP was 10 times
slower!). CICS Support responded to the PMR documenting
that CICS uses the TIMEUSED macro to capture CPU time:
"Note: TIMEUSED returns normalized CPU time. Some
servers are configured with System z(TM) Application
Assist Processors (zAAPs) or IBM System z9® Integrated
Information Processor and IBM System z10(TM) Integrated
Information Processors (zIIPs), which run at a faster
speed than the normal CP processors. In this case,
zAAP time and zIIP time is normalized to the equivalent
time it would take to run on a normal CP when
accumulated into total CPU time. "
The specific case had CPUTM=25 and ELAPSTM=5 on a machine
with a zAAP that was 10 times faster (or a CP that was 10
times slower!), which printed a recently added MXG ERROR
message "CPUTM MUCH LARGER THAN ELAPSED". This message
was added to enhance MXG's detection of mis-aligned SMF
records when CICS fields were excluded or optional fields
were added. Previously, the only way for MXG to catch
mis-alignment was to test that TASKNR was a valid packed
decimal or that STRTTIME was a missing value, but both of
those fields are at the beginning of the segment, and
some combinations of EXCLUDEd fields with optional data
segments passed those tests as the record was read, but
the CICSTRAN dataset contained invalid values for fields
later in the record, but that was only after the MXG job
had completed and the user analyzed the data. This test
was added for more robust detection, but the original was
only for CPUTM GT 2*ELAPSTM, which in this specific case
was a spurious ERROR message. I have changed the test to
CPUTM GT 10*ELAPSTM and added a note in the message that
this could be normal if you have knee-capped CP engines.
-These CPU time variables in CICSTRAN recorded those 25
Normalized CPU seconds: TASDSPTM (USRCPUT), KY8CPUTM,
L8CPUTTM, and the total CPUTM, for this transaction that
obviously spent some serious time on the zAAP engine.
Thanks to Hugo L. Michel, Prince Georges County, MD, USA.
Thanks to Dan Zachary, IBM CICS Support, USA.
Change 29.075 -Support for NTSMF's 62 new objects and 1425 new metrics.
EXNTD001 And, a MAJOR redesign in MXG architecture, isolated now
EXNTD062 to the NTSMF product support, but a possible harbinger
IMACNTSM of future MXG support: DATASET NAMES UP TO 32 CHARACTERS,
VMACNTSM with that dataset name being the OBJECT name (with blanks
VMXGINIT and periods changed to underscores). The "dddddd" dataset
Mar 31, 2011 tokens for the new datasets are "NTD001-NTD062", and the
VMXGINV variable/metric names use the D001 part of the dddddd
UTILVREF token as their prefix, and are sequentially numbered,
e.g. D0010001-D00010008 are the 8 variable names for the
dataset with NTD001:_NET_CLR_NETWORKING, and the labels
for the metrics are the metric name, shortened to forty
characters with asterisks inserted for the SPLIT='*' SAS
operand (to split labels when printing).
Previously, I created unique dataset names and variable
names that were arbitrarily limited to 8 characters, but
this design was implemented by the MAKENTSM code member
that programmatically generates all of the structural
code that is then cut/pasted to add the new datasets and
their exit members. The _UNTDISC utility provides the
cut and paste text for the metric names, that become the
labels for each variable; that is (and will always be) a
manual process, as that's how I discover what new metrics
are created, and get an understanding of each new object.
It is also where the conversion of values to be
consistent (like converting KB fields to bytes) and
assignment of MXG formats (like MGBYTES to those
converted fields, both for the "print pretty" aspect, but
more importantly, to document (in PROC CONTENTS) the
variables that contains storage units) that requires
human knowledge is done. The new objects are listed in
IMACNTSM rather than here!
-The increase of DATASET name required revisions to the
internal programs VMXGINV and UTILVREF that create the
DOCVER members; for datasets with names longer than 9,
DOCVER now has two lines, one for the DATASET name and
a second line for the DATASET label. Additional updates
were needed in a number of the internal QA programs to
support the longer dataset names.
Change 29.074 MXGWARM: MORE THAN 20 DUPLICATE LABELS, for TYPE8224 with
VMAC82 SMF82DCN, MORE THAN 20 UNAUTH DUPE for TYPE8225 are notes
Mar 30, 2011 that you had more than the 20 I thought was enough. With
a max of 36 now observed, I've increased to 40 the number
of these variables that are kept in the two datasets.
But, with MXG's default of COMPRESS=YES, why have any
limit at all: there really isn't any real cost of DASD
space, if the extra variables are all blanks.
If this is really a normal need, to know each of the
instances of the duplicate KEY, when there might be more
than 40, then MXG would create a new dataset with one
observation per instance, and free itself from any
array-size constraints!
Thanks to Bruce Hewson, Citibank N.A., SINGAPORE.
Thanks to Alan Yang, Citibank N.A., SINGPORE
Change 29.073 Documentation comments (ONLY) were updated to show how
READDB2 to create ONLY the PDB.DB2STATS dataset, with no other
Mar 28, 2011 datasets written to the PDB library. It should also be
noted that, to create observations in PDB.DB2STATS, both
DB2STAT0 and DB2STAT1 must have observations; DB2STAT4
can have zero observations.
Thanks to Jane S. Stock, USPS, USA.
Change 29.072 -Documentation comments (ONLY) were updated to show how
UTILBLDP the MACFILEX argument can be used to skip unwanted SMF
Mar 28, 2011 records and subtypes.
Apr 7, 2011 -Some MXGWARN were changed to MXGNOTE and text revised.
Thanks to Nicholas Ward, CentreLink, AUSTRALIA.
Change 29.071 Support for Throughput Manager subtypes 10 and 16 records
EXTPM10 creates new datasets:
EXTPM16S dddddd Dataset Description
EXTPM16J TPM10 TPM10 Description
IMACTPMX TPM16S TPM16S Step Termination
VMACTPMX TPM16J TMP16J Job Termination
VMXGINIT
Mar 28, 2011
Change 29.070 Replaced by Change 29.220.
Mar 24, 2011
Change 29.069 The DB2 Report of TOP users of resources was revised to
ANALDB2T report separately for each DB2 SubSystem.
Mar 24, 2011
Thanks to Ron Wells, American General, USA.
Thanks to Rick Brooks, American General, USA.
Change 29.068 MXG 28.28-29.02. Many ABEND='JCL' jobs had ABEND=' '
BUILD005 and all variables from TYPE26J2 were blank or missing in
Mar 24, 2011 the PDB.JOBS dataset. Change 28.304 unintentionally
output all TYPE26J2 obs with SYSEXEC LE ' ' to the
PDB.NJEPURGE dataset, so they were not used to build the
PDB.JOBS obs. Instead, only the Purge records that have
INREASON IN ('JR','JT','SR') AND SYSEXEC LE ' '
are (now, correctly) output in PDB.NJEPURGE. Fortunately
since purge records with SYSEXEC LE ' ' did NOT execute,
there was no actual loss of resources, except for the
counting JCL errors.
Thanks to Lars-Olof Thellenberg, Handelsbanken, SWEDEN.
Change 29.067 RACF UNLOAD utility dataset RACF0270 (OMVS) decodes these
VMACRACF ten variables for UID limits:
Mar 28, 2011 ASSIZEMAX ='MAXIMUM*ASID SIZE FOR UID'
CPUTIMEMAX ='MAXIMUM*CPU TIME*FOR UID'
FILEPROCMAX='MAXIMUM*CTIVE/OPEN FILES*FOR UID'
MEMLIMIT ='MAXIMUM*SIZE OF*NON-SHARED*MEMORY'
MMAPAREAMAX='MAXIMUM*MAPPABLE STORAGE*FOR UID'
PROCUSERMAX='MAXIMUM*PROCESSES*FOR UID'
SHMEMAX ='MAXIMUM*SIZE OF*SHARED*MEMORY'
THREADSMAX ='MAXIMUM*THREADS*FOR UID'
Thanks to Ed Webb, SAS Institute, USA.
Change 29.066 Duplicate formats $MG119SU were sourced in FORMATS; the
FORMATS last read was used correctly. The first is now $MG119ST
VMAC119 and is used to decode SSH_FSCMD, SSH FTP Subcommand.
Mar 16, 2011
Thanks to MP Welch, Aprize, USA.
Change 29.065 SMF 111 CTG variable CTGAPLID is conditionally INPUT for
VMAC111 dataset TY111CXI, but always INPUT for TY111GD dataset;
Mar 16, 2011 when it existed in GD but not in CXI, but only when the
GD segment preceded the CXI segment in a physical record,
the value from the GD segment was carried forward into
the CXI dataset. Now, the value is blanked after output
in the GD segment to prevent being carried forward.
Thanks to Gordon E. Griffith, Edward D. Jones, USA.
Thanks to Jim Poletti, Edward D. Jones, USA.
Thanks to Jeana M. Bechtel, Edward D. Jones, USA.
Change 29.064 The INFILE Exit for Compressed CICS and DB2 records did
EXITCICS not always work, sometimes causing an I/O Error message.
Mar 16, 2011 Code that had been moved in testing was restored.
Thanks to Harald Seifert, Huk-Coburg, GERMANY.
Change 29.063 Support for CICS/TS 4.2 was available in MXG 29.03, but
UTILEXCL was announced in Change 29.135. This change was Reserved
VMAC110 until the product became GA on June 24.
Mar 15, 2011 These new variables are added to the CICSTRAN dataset:
Apr 2, 2011 ECSEVCCT='SYNCHRONOUS*EMISSION*EVENTS'
Jun 24, 2011 OADID ='ORIGINATING*ADAPTER*ID'
OADATA1 ='ORIGINATING*ADAPTER*ID*DATA 1'
OADATA2 ='ORIGINATING*ADAPTER*ID*DATA 2'
OADATA3 ='ORIGINATING*ADAPTER*ID*DATA 3'
PHNTWKID='PREVIOUS*HOP*DATA*NETWORKID'
PHAPPLID='PREVIOUS*HOP*DATA*APPLID'
PHSTARTM='PREVIOUS*HOP*TASK*STARTIME'
PHSTARCN='PREVIOUS*HOP*TASK*STARTS'
PHTRANNO='PREVIOUS*HOP*DATA TRANS*SEQ NR'
PHTRAN ='PREVIOUS*HOP*DATA*TRANSACTION*ID'
PHCOUNT ='PREVIOUS*HOP*DATA*COUNT'
-UTILEXCL needed revisions because new fields inserted in
the middle of the record that were unknown to UTILEXCL
were not correctly handled in the prior UTILEXCL, which
created an IMACEXCL that had syntax errors that could be
visibly seen (the IBM field after the (last) new field
was NOT preceded by an INPUT statement.) This was NOT
an incompatibility with CICS/TS 4.2, but using the prior
UTILEXCL with CICS/TS 4.2 dictionary records did cause
the syntax error when that new IMACEXCL was used.
-New Statistics STID=19, Dataset CICSMD, exactly the same
fields as STID=6 in this iteration.
-New Statistics STID=20, Dataset CICSMT, exactly the same
fields as STID=5.
-New Statistics STID=29, existing Dataset CICSMDSA
SMSVABYT='ALLOCATED TO*PRIVATE*MEMORY*OBJECTS'
SMSVHBYT='HIDDEN IN*PRIVATE MEMORY*OBJECTS'
SMSVGBYT='HWM USABLE*IN*PRIVTE MEMORY*OBJECTS'
SMSPMOBJ='PRIVATE*MEMORY*OBJECTS'
SMSFGFAI='FROMGUARD*FAILURES'
SMSFGBYT='FROMGUARD*FAILURE*SIZE'
SMSSHBYT='SHARED*FROM*LARGE MEMORY*OBJECTS'
SMSHSBYT='HWM SHARED*IN*LARGE MEMORY*OBJECTS'
SMSSHOBJ='SHARED*MEMORY*OBJECTS'
SMSASPMO='AUX*SLOTS*BACK*64-BIT*PRIVATE*MEMORY'
SMSHSPMO='HWM AUX*SLOTS*BACK*PRIVATE*MEMORY'
SMSRFPMO='REAL FRAMES*BACK*64-BIT*PRIVATE*MEMORY'
SMSHRPMO='HWM REAL FRAMES*BACK*PRIVATE*MEMORY'
SMSLMOBJ='LARGE*MEMORY*OBJECTS'
SMSLPINR='LARGE PAGES*BACKED IN*REAL STORAGE'
-New fields in STID=48, Dataset CICTSQ:
A12TSQDL='QUEUES*AUTO*DELETED'
A12TSCTR='CLEANUP*TASK*RUNS'
-New fields in STID=142, Dataset CICEPG:
EPGEVLNO='EVENT*LOST*NO*ADAPTER'
Change 29.062 -UNKNOWN OPTION VNVERR should have been spelled VNFERR in
ASUMUOWT VMXGUOW. The error only occurs when ASUMUOWT is used for
VMXGUOW TMON CICS input. ASUMUOWT was not called in MXG QA job
Mar 15, 2011 or I would have caught this typo; that will be corrected.
Mar 18, 2011 -Debugging option TRACEUOW(YES) was left on in ASUMUOWT,
causing many thousands of lines FIRST.UOWICCHR= ...
to be printed on the log.
Thanks to Frank Lund, EDB ErgoGroup, NORWAY.
Change 29.061 Variables PCTZAPBY, PCTZALBY, PCTZIPBY, PCTZILBY are
VMACRMFV added to dataset ZRBCPU. These represent the Physical
Mar 13, 2011 and Logical Busy Percentage for ZAAP and ZIIP engines
respectively.
Thanks to Rodger Foreman, Acxiom, USA.
Change 29.060 Two calculations for z196 Est Finite CPI and Est SCPL1M
ASUM113 were revised by John Burg in his March SHARE session:
VMAC113 IF BASIC01 GT 0 THEN DO;
Mar 13, 2011 ESTFINCP=((BASIC03+BASIC05)/BASIC01)*(.57+(0.1*RNI));
END;
IF SUM(BASIC02,BASIC04,0) GT 0 THEN DO;
ESTSCP1M=((BASIC03+BASIC05)/(BASIC02+BASIC04))*
(0.57*(0.1*RNI));
END;
Change 29.059 Support for Beta 93 Version 4.2 new subtypes 25 and 50
EXTYBETF creates two new datasets:
EXTYBETG dddddd Dataset Description
IMACBETA TYBETF BETA25 93 SPOOL ACCESS
VMACBETA TYBETG BETA50 93 WEB BROWSER LOGON/LOGOFF
VMXGINIT
Mar 13, 2011
Thanks to Andreas Menne, Finanz Informatik, GERMANY.
Change 29.058 Variable CPUCEPTM is now set to a missing value in all of
VMAC30 the datasets that contain it (TYPE30_4,TYPE30_V,TYPE30_5,
Mar 11, 2011 PDB.STEPS,PDB.JOBS, where it was flat out WRONG, and in
PDB.SMFINTRV, where it was validly deaccumulated, but is
not needed). The error, starting in Change 22.326, was
that CPUCEPTM was an ACCUMULATED CPU time and was NOT the
CPU time of the interval, step, or job. In Change 22.326
MXG did deaccumulate it, but only in PDB.SMFINTRV, and in
that process, lost the value of the first interval. IBM
corrected their error, creating a new deaccumulated field
MXG variable CPUCIPTM, added in Change 23.329, which was
kept in all of the above datasets since that 2006 change.
But then in 2007, forgetting that it was completely wrong
I carelessly kept it in PDB.STEPS and PDB.JOBS. While it
might be better to just remove the variable, it is safer
to now set CPUCEPTM to a missing value, and hope/presume
that if/when you notice it is missing, that you will have
first searched CHANGESS and will have found this text to
tell you to use CPUCIPTM instead. Note that CPUCIPTM is
already contained in CPUTCBTM so you would only even want
to use it when examining the components of CPUTCBTM.
An obscure comment in VMAC30 notes that the variables
CPUASRTM CPUENCTM CPUDETTM CPUIFETM CPUEFETM CPUDFETM
and CPUCIPTM are all included in CPUTCBTM.
Thanks to Alfred Holtz, Medco, USA.
Thanks to Charles D'Angelo, Medco, USA.
Thanks to Alex Pasterick, Medco, USA.
Change 29.057 Support for Websphere for z/OS MQ Version 7.0.1 (COMPAT).
EXTY116C -SMF 115 record, dataset MQMMSGDM, new variables:
IMAC116 QMSTPUBS QMSTSTUS QMSTSUB QMSTSUBR QMSTTCB QMSTTCTL
VMAC115 QTSTETHW QTSTETTO QTSTPHIG QTSTPLOW QTSTPNOS QTSTPTO1
VMAC116 QTSTPTO2 QTSTPTO3 QTSTSDUR QTSTSEXP QTSTSHI1 QTSTSHI2
VMXGINIT QTSTSHI3 QTSTSLO1 QTSTSLO2 QTSTSLO3 QTSTSPHW QTSTSTOT
Mar 12, 2011 QTSTTMSG
Apr 19, 2011 -SMF 116 record, datasets MQMACCT1 and MQMQUEUE:
New variables added from both WQ and WTAS segments:
WTASCTCT WTASCTET WTASCTN WTASCTSR WTASSQCT WTASSQET
WTASSQN WTASSTCT WTASSTET WTASSTN WTASSUCT WTASSUET
WTASSUN WTASSUSC WTASSUSL
WQCBCT WQCBET WQCBN WQCLCFD WQCLSUET WQCLSUN
WQCLTOSR WQOPCFD WQOPSUET WQOPSUN WQOPTOSR WQP1TOSR
WQPUBCN WQPUTOSR WQSELCOU WQSELMXL
New MQCFSTAT dataset has one obs with these 5 variables
WQCFCOUN &PIB.4. /**TIMES*IN THE*ROUTINE*/
WQCFSYCN &PIB.4. /**SYNC*REQUESTS*/
WQCFSYET &PIB.4.6 /**SYNC*ELAPSED*TIME*/
WQCFASCN &PIB.4. /**ASYNC*REQUESTS*/
WQCFASET &PIB.4.6 /**ASYNC*ELAPSED*TIME*/
with those statistics for the Coupling Facility, if used,
for each of the five MQ Verbs (variable WQVERB);
OPEN CLOSE GET PUT PUT1
and for each of the thirteen MQ requests (WQREQSTY):
LOCK UNLOCK WRITELC SIGXCF SIGCF READ
WRITE STARTMON STOPMON NEW MOVE MOVEENT
DELETE
but observations are ONLY created in MQCFSTAT if there
are non-zero counts in one of the statistics variables.
Apr 19: VMAC110 QJSTDRE1/3 corrected to QJSTDRQ1/3
Thanks to Victoria Lepak, Aetna, USA.
Thanks to Chris Weston, SAS ITRM Development, USA.
Change 29.056 Support for MainView MQ (MVMQ) Version 4.4 (INCOMPAT);
VMACBBMQ MXG code had not been updated since 2007 and many new
Mar 13, 2011 fields were inserted in 'E6'x (dataset BBMQQUES) record,
the 'E5'x (dataset BBMQCHAN) record was completely
revised with several new fields, and the 'E1'x (dataset
BBMQQMGR) had new fields added at the end. The VERSREL
value in the 4.4 records contains 4.2, so the logic to
detect MVMQ Version was change to use the Length ENTL
field. This iteration suppresses checking for compress
bit while EXITMNVW is examined for possible error.
Thanks to James Swwinarski, Credit-Suisse, SWITZERLAND.
Change 29.055 JCLUOWV, an example to read DB2 & CICS data that creates
JCLUOWV PDB.ASUMUOW using SAS Views was altered by Change 28.220
Mar 9, 2011 but undocumented; the default ASUMDB2x members that were
%INCLUDed were changed, creating different PDB.ASUMDB2x
datasets. While any or all of the ASUMs are optional, it
was not my intent to create different datasets, so the
default original ASUMs are restored, with this note:
/*ANY OR ALL OF THE BELOW SUMMARIZING ASUMDB2X ARE OPTIONAL. */
/*THE PAIR INCLUDED BY DEFAULT ARE THE ORIGINAL PAIR, KEPT FOR */
/*CONSISTENCY, BUT AS ASUMDB2P CAN BE VERY EXPENSIVE, YOU MIGHT*/
/*NOT WANT TO EXPEND THOSE RESOURCES TO SUMMARIZE PACKAGES, AND*/
/*YOU MIGHT FIND SUMMARIZING DB2STATS WITH ASUMDBSS TO BE BOTH */
/*USEFUL AND CHEAP (SINCE THOSE ARE INTERVAL DATASETS). */
%INCLUDE SOURCLIB(ASUMDB2A); /*BUILD PDB.ASUMDB2A FROM DB2ACCT*/
%INCLUDE SOURCLIB(ASUMDB2P); /*BUILD PDB.ASUMDB2P FROM DB2ACCTP*/
/*%INCLUDE SOURCLIB(ASUMDB2B); BUILD PDB.ASUMDB2B FROM DB2ACCTB*/
/*%INCLUDE SOURCLIB(ASUMDB2G); BUILD PDB.ASUMDB2G FROM DB2ACCTG*/
/*%INCLUDE SOURCLIB(ASUMDBSS); BUILD PDB.ASUMDBSS FROM DB2STATS*/
Thanks to Carolyn Saul, West Virginia Office of Technology, USA.
Change 29.054 -STRING variable length was increased to 1000 to support
ASUMDB2A potentially longer arguments.
ASUMDB2B -Macro variable DSETEXST=NO, defined/set in VMXGINIT, was
ASUMDB2G incorrectly re-defined in VMXGSUM, ASUMDB2A, ASUMDB2B,
ASUMDB2P ASUMDB2G and ASUMDB2P, preventing it from being changed
VMXGSUM to YES by ANALDB2R, the only place it is currently used.
Mar 13, 2011 Re-definitions are now removed from those five members.
With DSETEXST=NO, VMXGSUM calls VGETOBS to determine if
the input dataset exists, gracefully failing was an MXG
message if it doesn't. With DSETEXST=YES, when the
existence is already known, VGETOBS is bypassed, saving
a read of the full input dataset if it happens to be
on tape or in sequential format on disk.
Because the redefinition text was DSETEXST=&DSETEXST,
SAS errors about RECURSIVE REFERENCE to DSETEXST could
have occurred, although (fortunately) none were reported.
Change 29.053 Documentation. Since DB2 Version 7.1, when DB2ACCTP data
TYPEDB2 was moved to SMF 101 Subtype 1, there has been no QWAC
Mar 4, 2011 segment for Packages. The KEEP list for DB2ACCTP still
had variables QWACBSC QWACESC and QWACWLME, which have
been missing values in DB2ACCTP since then. I could drop
them, but if I do, someone out there with an old report
program that referenced them, would then fail, so they
will still be kept (but if you are real picky, you can
easily drop them by putting this macro definition
MACRO _KDB2ACP DROP=QWACBSC QWACESC QWACWLME %
in your IMACKEEP member in your "USERID.SOURLIB").
Thanks to Wayne Bell, UniGroup, Inc, USA.
Change 29.052 The newest MONTHxxx fails, z/OS ONLY, SAS 9.1.3 only.
MONTHBLD %CMPRES must be changed to %QCMPRES. As often is the
Mar 3, 2011 case with %MACRO errors, the error message gives no clue:
NOTE: LINE GENERATED BY THE MACRO FUNCTION "SUBSTR".
;SET MON.XXXXXX WEEK1.XXXXXX WEEK2.XXXXXX WEEK3.XXXXXX
___
___
___
180
180
180
ERROR 180-322: STATEMENT IS NOT VALID OR IT IS USED OUT
OF ORDER.
The %CMPRES function was added to print the generated SET
statement, for diagnostics, to verify the results of the
7x7 tests (7 Startdays, 7 Rundays), but was added after
the z/OS MONTHxxx logic verification, and while it works
just fine on SAS 9.2, the 9.1.3 %CMPRES function fails,
inserting a semicolon that terminated the %LET statement.
The stronger %QCMPRES function works on SAS 9.1.3.
May 1: See CHANGE 29.102. Error occurred on SAS V9.2.
Thanks to Kim Tyson, Toyota, USA.
Change 29.051 Variable STORCLAS can be uninitialized, with hex zeroes
VMAC42 for some system datasets (SYS1.MANX,SYS1.PROCLIB); now,
Mar 2, 2011 hex zeros are translated to blanks.
Thanks to John R. Paul, Highmark, USA.
====== Changes thru 29.050 were in MXG 29.02 dated Mar 1, 2011=========
Change 29.050 DB2 IFCID 319, ACCESS CONTROL AUTH EXIT PARMS, specific
FORMATS to IFCID=319 fields, are now decoded and output; three
VMAC102 formats are created to decode three variables.
Change 29.049 The interval DELTATM was not summed when there was more
ASUM113 than one engine for a type of engine causing LPARBUSY
Feb 25, 2011 to exceed 100%. The sum of the DELTATM across engine type
Feb 28, 2011 is now stored in DELTASUM and used for LPARBUSY, while
DELTATM has the interval duration and is used for the
(now corrected) calculation of LPARCPUS.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 29.048 Macro variable MXGCIXT is created and inserted after all
VMXGCICI of the CICS Statistics WORK.INTxxxx datasets have been
VMXGINIT created (summarized), so they could be copied to a
Feb 25, 2011 permanent data library.
Change 29.047 DB2 variables QWACZIS1 QWACZIS2 QWACZIEL QWACZITR are now
VMXGUOW added to PDB.ASUMUOW when DB2ACCT data is found.
Feb 25, 2011
Change 29.046 On z/OS only (a LIBNAME is always needed on ASCII):
DOC if your program starts with an ASUM/TRND member, or it
Feb 25, 2011 invokes VMXGSUM, and the internal macro VGETOBS is used
(to detect the presence or absence of input datasets,
intended to conserve resources and avoid strange errors),
there are two potential exposures:
SAS - if the LIBNAME is on tape, we cannot detect that,
and the PROC SQL will read the entire tape volume(s) to
populate the DICTIONARY.TABLES internal table we use.
WPS - WPS does not populate dictionary.tables until the
LIBNAME(s) are opened, which causes these error messages:
NOTE: No rows were selected
NOTE: RUN has no effect in proc sql ... immediately.
MXGERROR: WEEK.JOBSKED DOES NOT EXIST. VMXGSUM WILL
MXGERROR: BE STOPPED.
NOTE: Procedure SQL step took :
In this case, you must have a LIBNAME statement for each
data library to cause that table to be populated.
Alternatively, you could also use PROC DATASETS
DDNAME=xxxxx; to populate the table.
In both cases, inserting %LET DATAEXST=YES; as the first
SYSIN statement eliminates VMXGSUM's call to VGETOBS to
verify the dataset exists. However, if they don't exist,
that will cause VMXGSUM to then fail for that reason.
Thanks to Kare Martin Torsvik, Ergogroup, NORWAY.
Thanks to Atle Mjelde, Ergogroup, NORWAY.
Change 29.045 TRNDRMFI example TRENDINT should have been INTERVAL.
TRNDRMFI UTILRMFI %IF J LT 5 should have been %IF &J LT 5.
UTILRMFI
Feb 27, 2011
Thanks to Matthew Chappell, Dept. of Transport Main Roads, AUSTRALIA
Change 29.044 ASM utility to convert a PC "RECFM=U" V/VB/VBS file that
ASMDBLKU was uploaded to z/OS into a readable "RECFM=V/VB/VBS"
Feb 25, 2011 dataset. This is the ASM equivalent of the SAS UDEBLOCK
for sites that don't have a z/OS SAS license.
Change 29.043 -If you needed to rerun a specific day, and you use the
BLDSMPDB AUTOALOC=YES option, the FORCEDAY parameter was not found
Feb 24, 2011 in the macro; it is now properly defined. To rerun with
AUTOALOC=YES, the syntax is forceday=ddmmmyy, where the
ddmmyy is the date to be rerun (e.g., 21feb11).
-If you need to rerun a day and AUTOALOC=YES is NOT used,
specify rerun= the day of the week to be rerun, MON, etc.
Thanks to Cletus McGee, ALFA Insurance, USA.
Change 29.042 NDM-CDI Version 5 records are read without actual errors,
VMACNDM but the test file contained 'XO' records, which printed
Feb 24, 2011 "NDM. HEADER ONLY" messages because no records had been
available for validation. These records are now decoded
and are output in NDMDT dataset.
Change 29.041 Your FEB MONTHly PDB could be missing MON data, if your
VSETMNTH MONTHBLD/MONTHBL3/MONTHASC/MONTHDSK has a %%VSETMNTH(),
MONTHBLD i.e., if the Last Change is 28.125 thru 29.017, i.e.,
MONTHBL3 if it was copied from MXG 28.04 thru 29.01 (yes, that
MONTHDSK new version that was supposed to have fixed the MONTHs).
MONTHASC YOUR MONTHXXX IS SAFE IF IT DOES NOT CONTAIN %%VSETMNTH.
MONTHWEK It depends on the MONTHxxx member, the version it came
Feb 27, 2011 from, and the STARTDAY of your week (MXG default is MON):
NOTE: THERE IS NO ERROR MESSAGE; THE JOB DOES NOT FAIL.
1. IF YOU USE MONTHBLD/MONTHBLD/MONTHASC/MONTHDSK:
The possible combinations that are good or bad:
Using MONTHBLD or MONTHBL3:
From version: MXG 29.01 MXG 28.04-MXG 28.28
(Last Change) Change 29.017 Change 28.125-28.324.
STARTDAY SUN MON SUN MON
VSETMNTH OLD NEW OLD NEW OLD NEW OLD NEW
X ok ok ok ok X X X
Using MONTHASC or MONTHDSK:
From version: MXG 28.04-MXG 29.01
(Last Change) Change 28.125-28.324.
STARTDAY SUN MON
VSETMNTH OLD NEW OLD NEW
ok X X X
X: MON's PDB data will be missing.
The safe correction, of course, is to "drop in" MXG 29.02
before Tuesday's MONTHxxx, but I realize that's unlikely!
To correct, you MUST download the new VSETMNTH file
- VSETMNTH.SAS (ASCII) or VSETMNTH.EBC (z/OS) - and copy
into your tailoring library.
With MONTHBLD/MONTHBL3 from MXG 29.01, the new VSETMNTH
is all that is required.
If your MONTHBLD/MONTHBL3 was from 28.04-28.28, then
you can download the new member and cut your list of
the datasets you create (i.e., from 1st MACRO _DSET to
the end of your MONTHBLx) and replace the default list
in the new MONTHBLx), or you can EDIT your MONTHxxx
(see below) to change the CALL SYMPUT.
With MONTHASC/MONTHDSK from 28.04 including 29.01,
you can download the new member and cut/paste your list
of datasets (see preceding note), or you can EDIT your
MONTHxxx (see below) to change the CALL SYMPUT.
To EDIT/fix MXG's error in MONTHBLD/MONTHBL3 pre 29.01
or the MXG error in MONTHASC/MONTHDSK from 28.04-2901:
Change the one line:
CALL SYMPUT('LASTDAY',PUT(TODAY,WEEKDATE3.));
to
CALL SYMPUT('WEEKDATR',PUT(TODAY,WEEKDATE3.));
The ftp credentials you already have for 28.28 or 29.01
are still valid, so you can either download MXG 29.02 and
copy those new members to your Tailoring Library from it,
or you can download only the specific files you need:
The files with .sas are ASCII for MXG ASCII execution.
The files with .ebc are EBCDIC (to avoid any code page
translation issues), but they must be moved as binary
to a PDS with DCB attributes of RECFM=FB and LRECL=80.
And, what do you do when it after March 1st when you find
this needed correction? Download/EDIT as described in
the preceding paragraphs for your BUILDxxx programs and:
-If the rerun is during the same processing week, then
simply EDIT your MONTHxxx and change the statement
TODAY=TODAY();
to
TODAY='01MAR2011'D;
(as is documented in the ADOCMNTH member).
-If the rerun is not until the NEXT week, then you would
use the MONTHWEK member (z/OS) or the MONTHASW (ASCII)
member (from your current MXG version - it doesn't use
the defective VGETMNTH that created all this flail),
cut/paste your list of datasets to be created, and then
read the last 5 WEEKly PDBs to rebuild your MONTHly.
2. IF YOU USE BLDMSPDB:
You must have the new BLDSMPDB and VSETMNTH, then:
To rebuild the past month's PDB on z/OS or on ASCII
with AUTOALOC=NO (default), but ONLY if you are in the
first week of the new month:
%BLDSMPDB(RUNDAY=NO,RUNWEEK=NO,RUNMNTH=FORCE,
FORCEDAY=01MAR11);
To rebuild the past month's PDB on ASCII with
AUTOALOC=YES (ASCII ONLY), but ONLY if you are in the
first week of the new month:
%BLDSMPDB(AUTOALOC=YES,RUNDAY=NO,RUNWEEK=NO,
RUNMNTH=FORCE,FORCEDAY=01MAR11);
To rebuild the past month when it is beyond the first
week of the month:
With AUTOALOC=NO:
LIBNAME WEEK6 'your sixth week';
%LET USEWEEKS=YES;
%BLDSMPDB(RUNDAY=NO,RUNWEEK=NO,RUNMNTH=FORCE,
FORCEDAY=01MAR11);
With AUTOALOC=YES:
%LET USEWEEKS=YES;
%BLDSMPDB(ALOCWEEK=YES,RUNDAY=NO,RUNWEEK=NO,
RUNMNTH=FORCE,FORCEDAY=01MAR11);
3. IF YOU USE BLDNTPDB:
To rerun the current month, whether during the week with
the first of the month, or a following week, use:
%BLDNTPDB(RUNDAY=NO,RUNNTINT=NO,RUNWEEK=NO,RUNMNTH=FORCE);
To rerun a prior month, you must ensure the correct week
pdbs are allocated to week1 thru week5, and then us:
%BLDNTPDB(RUNDAY=NO,RUNNTINT=NO,RUNWEEK=NO,RUNMNTH=FORCE,
FORCEDAY=01MAR11);
Additional changes were made by this enhancement.
-New macro variable (if you set it to) USEWEEKS=YES:
-drives logic in VSETMNTH to use only the WEEKly PDBs
when the rerun is in the week after the week with the
first of the month.
-allocates LIBNAME WEEK6 because some months need
to read six months of weeklies when a MONTH PDB is
created only from the past weekly pdbs.
-Documentation in BLDSMPDB for RUNMNTH=FORCE, RERUN=YES,
and FORCEDAY='date' are corrected and updated.
-The default WEEKs kept is now 12 in both BLDSMPDB and
VMXGALOC, but I recommend a MUCH LARGER number of WEEK
PDBs be kept for historic reasons, with all of the PDB
datasets (and only a few, if any, kept in MONTHly PDBs).
-I believe only SUN and MON are commonly used for the
Startday, but the below table shows all of the possible
datasets that could have been missing prior to this
change:
Table of which PDB's are missing with bad VSETMNTH:
Eg.: On Feb 1 and Mar 1, which are RUNDAY=TUE, the
table shows that "mon" PDB will be missing from your
MONTH PDB if your week starts on SUNDAY, or that the
"tue" PDB will be missing if MONDAY is STARTDAY, but
in the worst case, it shows six dailies could have
been skipped in building the monthly.
Your RUNDAY = DAY OF 1st of MONTH
Week MON TUE WED THU FRI SAT SUN
Start:
SUN mon tue wed thu fri su-fr ok
MON ok tue wed thu fri sat mo-sa
TUE tu-su ok wed thu fri sat sun
WED mon we-mo ok thu fri sat sun
THU mon tue th-tu ok fri sat sun
FRI mon tue wed fr-we ok sat sun
SAT mon tue wed thu sa-th ok sun
Thanks to Michael Creech, Lender Processing Services, USA.
Change 29.040 Variables MAXVMSIZ and VMDSSIZE in dataset XAMUSR were
VMACXAM incorrectly input as PIB.4. instead of RB.4. so the
Feb 23, 2011 formatted value printed as 1164M instead of 3071M.
While XAM apparently prints 3072M, the actual RB value
in the record, '48BFFFFF'x is only 3221225216 while the
actual bytes in 3072M (megabyte) is 3221225472.
Thanks to Craig Collins, State of Wisconsin DOA, DET, WISCONSIN.
Change 29.039 Format MGRMFCX, dataset TYPE7002 variable R7023CT and
FORMATS dataset TYPE70X2 variable R7024CT, Crypto Processor Type,
Feb 23, 2011 was incorrect, expecting 'F5'x EBCDIC numbers in hex, but
the actual values are hex (e.g.,'05'x); the hex value was
printed; now the decoded '05X:PCIXCC' will be printed.
Thanks to Giuseppe Giacomodonato, EPV Tech, ITALY.
Change 29.038 Variable ASISDCCP in dataset ZRBASI is now a percentage,
VMACRMFV as labeled; and divided by total samples. Previously, it
Feb 22, 2011 was the (numerator) sample count.
Thanks to Scott Wiig, USBank, USA.
Change 29.037 DB2 V9.1, MXG 28.28-29.01, may print false messages about
VMACDB2H INVALID DISTRIBUTED HEADER DELETED. The header is valid,
Feb 21, 2011 but the test added in Change 28.326 (to detect a truly
invalid header that ONLY exists in DB2 V10.1 and that is
to be corrected by APAR PM32425) was off by one byte for
DB2 V9.1 records. For either release, nothing is really
"deleted"; the only impact is that the INPUT of variable
QWHDRQNM, the Requestor Location Name, is skipped, so the
"DELETED" in the message is changed to "QWHDRQNM SKIPPED"
and the V10 APAR is printed in the message text.
Thanks to Lorena Ortenzi, UniCredit Group, ITALY.
Change 29.036 Julian dates of 1999/000 with COMEFROM=7 printed harmless
VMACEDGR messages that the date was invalid, but should have NOT
Feb 18, 2011 printed the message; instead the invalid date is stored
Mar 13, 2011 into RDEXPDCH as character, and RDEXPDTO is set missing,
Mar 20, 2011 and the test covers COMEFROM=7/48/53 now.
Mar 13: DATEDATE=1999/366 now also protected.
Thanks to Douglas C. Walter, Citigroup, USA.
Thanks to Brent Turner, Citigroup, USA.
Change 29.035 SAS compiler error when _NNTSM was invoked to substitute
COMPALLN _NULL_ replacement tokens, and a _NULL_ definition had
VMACNTSM only one space between the macro name and "_NULL_" text:
Feb 17, 2011 MACRO _WNTWFP _NULL_ %%
Inserting an extra blank so that the definition now reads
MACRO _WNTWFP _NULL_ %%
eliminated this error (with full diagnostic options on,
the generated code could be seen to be in error, with the
next line in the source being 'swallowed' into _WNTWFP.)
The error was replicated with other _NULL_'s in VMACNTSM.
All of the VMACxxxx that define _NULL_'s with similar
syntax were revised to eliminate the exposure, and some
members either did not define _Nxxxx or did not have
correct syntax (e.g., the MACRO keyword was missing).
to have two blanks. And, in the process, I discovered
several members did not have correct syntax for their
_NULL_ definitions( the MACRO keyword was missing).
these VMACxxxx members were corrected:
16 DECS 113 HURN SUIN OMVT
WPMO TMVS SVIE AIM3 19 NTSM ZTPM FITA VIOP UNIC ULTM
TPF SUNS SRMH SARR RSDF RSDA PMTR MVCI MRKV MPLX MOUN
MBO INMV IISL GUTS FDR AIXT 97 42 109 CISM
The error occurred with both PC SAS V9.2 and V9.1.3,
but only on Windows (both XP and Seven, 32 and 64 bit).
Thanks to Lars Fleischer, SMT Data, DENMARK.
Change 29.034 Invalid data for datetime variable SMF30RGT caused error
VMAC30 message and hex dump, and left SMF30RGT a missing value.
Feb 17, 2011 Datetime variable SMF30RGT (IXCARM REGISTER event) is
input from two IBM fields, SMF30RGT (the time part) and
SMF30RGD (the julian date part), but while SMF30RGT had
a valid time value, SMF30RGD was null (i.e., hex zeros).
The error is circumvented by inserting double question
marks for the INPUT of SMF30RGT, while IBM will be
contacted to correct their invalid data value in the
Automatic Restart Management (ARM) segment of SMF 30-5.
Change 29.033 Support for IMF Version 4.5 is in place; there were no
VMACCIMS changes in the IMS F9/FA records between 4.4 and 4.5.
Feb 14, 2011
Change 29.032 -Dataset PDB.IPLS now DOES always report a SYSTEM IPL, but
FORMATS previously that was not true. PDB.IPLS is created from
VMAC0 SMF type zero records, but ID=0 are written both when SMF
VMAC90A is started (at SYSTEM IPL), and when SMF is RESTARTED
VMACSMF (after an SMF address space ABEND, I/O error, etc). This
Feb 13, 2011 is NOT new; at least since 1992, member ADOC0 has noted
(albeit obscurely) that the ID=0 doesn't always report a
system was IPL'd.
-A true System IPL writes either an ID=90 subtype 8 (IPL
PROMPT) or ID=90 subtype 10 (IPL SRM). Now, VMAC0 reads
ID=0, ID=90.8 and ID=90.10 records, initially outputting
all in dataset TYPE0, but when TYPE0 is sorted by _S0
(the product sort macro, invoked by BUILDPDB/PD3/TYPS0),
now these two datasets are created:
PDB.IPLS - actual system IPLS - ID=90.8 or 90.10 obs
PDB.IPLSMF - all SMF ID=0 observations.
-But, note that when SMF has to be restarted, there were
SMF records that could not be written and were lost, and
no ID=7 record would have been written.
-VMACSMF required update because SMF ID=90 records do not
have their subtype in the standard SMF header.
-Cosmetic. TYPE90nn datasets now have variable CMDMVS to
identify which command created the record, and CMDMVS is
formatted with MG090CM to describe the command.
-Format MG090CM was updated for new commands.
-These "bogus IPL" events were overlooked because IBM has
done such a fine job in those 19 years to eliminate
unscheduled IPLs, that tracking them became unimportant!
It was only after SMF ABENDs due to a non-IBM product
required restarting the SMF address space that this need
to redesign MXG's PDB.IPLS dataset surfaced.
Thanks to Jerry Urbaniak, Acxiom, USA.
Change 29.031 DB2 V9.1 only; most QGBxxx variables in DB2GBPST were not
VMACDB2 correct; MXG had correct INPUT for V8.1 and V10.2 but did
Feb 9, 2011 not have a separate INPUT segment for 9.1, and MXG missed
the restructure in DB2 V9.1.
Thanks to Rachel Holt, Fidelity Systems, USA.
Thanks to Lori Masulis, Fidelity Systems, USA.
Change 29.030 -For DB2 connections (DBMDPTYP='DSN', variable DBMDACCT is
VMACTMDB input and kept in TMDBDB2 dataset; for Client connections
Feb 9, 2011 these variables are now kept in TMDBDB2 dataset:
Feb 18, 2011 DBMDPLAT $EBCDIC18. /*CLIENT*PLATFORM*/
DBMDAPPL $EBCDIC20. /*CLIENT*APPLICATION*NAME*/
DBMDATID $EBCDIC8. /*CLIENT*AUTH*ID*/
DBMDSFLN &PIB.1. /*DDCS*ACCOUNT*SUFFIX*LENGTH*/
DBMDSUFX $EBCDIC200. /*DDCS*ACCOUNT*SUFFIX*/
-TMDB Version 4.1 BF/BG/BH/BI/BJ/BK/BL/BM records were off
by 2 bytes, causing DATABASE NAME and other fields to be
misaligned.
-Feb 18. Revisions to BI record's restructure.
Thanks to Liliane Paquet, Centre de services partages Quebec, CANADA.
Thanks to Patricia Abel, Regie des rentes du Quebec, CANADA.
Thanks to Ernie Amador, UC Davis Health System, USA.
Change 29.029 Variable KW18SP03 was input but not kept nor labeled.
VMAC80A
Feb 9, 2011
Thanks to Kim Westcott, NYS Office of Technology, USA.
Change 29.028 Yet another NDM 'RT' subtype INPUT EXCEEDED error because
VMACNDM the records do not match the documentation, offsets are
Feb 8, 2011 inconsistent (PACCT/SACCT sometimes -3, sometimes +1),
ACCT values that are not EBCDIC, two segments after ACCT
that are undocumented, with wide variances in the data
from sites running the same CDI versions, so this change
stops reading at the end of the fixed portion of the data
record, and only looks for the CPUTIME= text string at
that point in the record. If you REALLY, REALLY, need
the NDMRT variable data, or the undocumented fields to be
decoded, be prepared to open a support issue with the CDI
vendor and have them contact me with their DSECT/data.
Change 29.027 Cosmetic. Several variables were incorrectly spelled in
ADOC110 the documentation of CICS variables.
Feb 7, 2011
Thanks to Clayton Buck, UniGroup, USA.
Change 29.026 Support for zVM APAR VM64794 adds variables to dataset
VMACVMXA VXMTRSYS, and new format $MGVXENS to decode new variable
Feb 11, 2011 SYSESTAT (Ensemble Status).
Thanks to Al Holtz, MEDCO, USA.
Thanks to Frank Bright, MEDCO, USA.
Change 29.025 Small negative values for CPUUNITS in type 30 subtype 4
VMAC30 records have been observed in steps with CPUTCBTM=0, when
Feb 7, 2011 the calculated ZIPUNITS (using normalized CPUZIPTM) is
Nov 3, 2011 greater than the SM30CSUL (original CPU+zIIP+zAAP units).
While not significant, MXG now forces CPUUNITS=0 when
CPUTCBTM=0. The maximum negative CPUUNITS value was -169,
but with LOSU_SEC=30018, that is only 0.009 CPU seconds.
Nov 3: Original text corrected; negative CPUUNITS weren't
set to zero, but CPUUNITS was set to zero if CPUTCBTM was
zero. So small negative values (-1.59 in one record in 8
million type 30s) could still occur if CPUTCBTM non-zero.
And, they printed a debugging message with _N_= CPUUNITS=
that should have been and is now disabled.
Change 29.024 MXG-created variables INREASON and SOURCE were blank when
VMAC26J2 INDEVICE=Nnnn.RDm and INTRDR=' ', printing messages that
Feb 5, 2011 INREASON NOT DECODED. INREASON='RD' and SOURCE=INDEVICE
Mar 24, 2011 is now set. INREASON and SOURCE are "my" variables that
were only used in understanding NJE Purge Records and are
not actually used for anything.
Mar 24: SOURCE=INDEVICE wasn't set for INTRDR='Y'.
Thanks to Jack Schudel, University of Florida, USA.
Thanks to Lars-Olof Thellenberg, Handelsbanken, SWEDEN.
Change 29.023 Using GTF input, IFCID 3 (DB2ACCT) observations were not
VMACDB2 output, and a (spurious) INVALID PROD section message was
Feb 5, 2011 printed. The OFFSMF value has to be changed when GTF is
input, but the logic for ID=101 SUBTYPE=0 was incorrect.
Thanks to Tony Curry, BMC, USA.
====== Changes thru 29.022 were in MXG 29.01 dated Feb 4, 2011=========
Change 29.022 After Change 28.146 (MXG 28.04+), Buffer Hit Ratio on the
VMXGDBSS %ANALDB2R(PDB=SMF,...) statistics reports were 100 times
Feb 4, 2011 too large. In MXG-built datasets BPHITRAT is a fraction
(e.g., .952), but in DB2PM reports IBM prints 95.2. But
Change 28.146 incorrectly multiplied by 100 when creating
the PDB.ASUMDBSS dataset, and then ANALDB2R multiplied.
This change restores the correct fractional value in the
ASUMDBSS dataset and lets ANALDB2R still do the multiply.
Thanks to Ron Wells, American General, USA.
Thanks to Rick Brooks, American General, USA.
Change 29.021 Variables SMF89DTO and SMF89HOF were accidentally removed
VMAC89 from dataset TYPE892, and should not have been. Since
Feb 4, 2011 they are needed by Al's LCS Product, MXG 29.01 refreshed.
Mar 12, 2011 Mar 12: Variables SMF89SIF,SMF89LPV,SMF89LCR are kept.
====== Changes thru 29.020 were in MXG 29.01 dated Feb 3, 2011=========
Change 29.020 The definition of MACRO _NEDA, to null all datasets, was
VMACEDA missing the MACRO preceding the _WEDAxxx token.
Feb 3, 2011
Thanks to Scott Barry, SBBWorks Inc, USA.
Change 29.019 Sample ACF2 reports looked for PDB.ACF2ARR when the real
ANALACF2 dataset created by TYPSACF2 is named PDB.ACF2AR.
Feb 3, 2011
Thanks to Vitullo Carmen, State of Delaware, USA.
Change 29.018 Calculation of MEMP for z196 now subtracts the two
ASUM113 counters EXTND152 and EXTND155, per John Burg's SHARE
VMAC113 paper, which I had overlooked since last August.
Feb 3, 2011 BUT: FEB 18: The revised calculation was ONLY in the
Feb 18, 2011 VMAC113 in 29.01; I forgot the calculation is repeated
for the z196 code in ASUM113 until today when it was
discovered, because, without the correction, the RNI
values for z196 were larger than for the same workload
on the z10 when they should be about the same.
Thanks to Meral Temel, Garanti Teknoloji, TURKEY.
Thanks to Adnam Can, Garanti Teknoloji, TURKEY.
Change 29.017 -SERIOUS: MONTHBLD/MONTHBL3/MONTHASC in 28.28 will skip
MONTHBLD reading the last day's PDB library (the JAN 2011 MONTH
MONTHBL3 will be MISSING the MON PDB's observations).
MONTHASC This new statement added by Change 28.324
ADOCMNTH CALL SYMPUT('WEEKDATR',(PUT(LASTDAY,WEEKDATE3.)));
BLDSMPDB MUST be corrected to:
Feb 3, 2011 CALL SYMPUT('WEEKDATR',(PUT(TODAY,WEEKDATE3.)));
That is the permanent correction.
-BUT, to RERUN JAN 2011 NOW, since it is already Feb 2,
you must ALSO replace the existing statement
TODAY=TODAY(); with
TODAY='01FEB2011'D.
just for the JAN REBUILD (and then restore that statement
before you run the next month's build).
MONTHBLx normally must execute on the 1st day of the
next month; but comments in MONTHBLx point to ADOCMNTH,
for instructions on how to rerun on a different day of
the month; as long as you rebuild during this week,
there is no change needed to the JCL for the JOB.
If you don't see this until NEXT week, then you need
to read the instructions for the required JCL change
when you need to rebuild a MONTHly in a later week
than the normal week with the 1st day of the month.
-BLDSMPDB: LIBNAME WEEK1 NOT FOUND when runmnth=yes. Can
be circumvented by adding LIBNAME WEEK1 statement with
this syntax to rebuild JAN 2001:
libname week1 'c:\mxg\week1\';
%bldsmpdb(runday=no,runweek=no,runmnth=force);
An undocumented requirement of VSETMNTH needs WEEK1,
which is now LIBNAME'd to the same directory as WEEK.
-I personally apologize for my failure to validate these
changes made by MXG Change 28.324.
-Cosmetic, but possibly confusing. The %PUT statement
that prints the date selections printed "LT", but the
actual and correct test is for "LE".
Thanks to Robb Hermes, Sentry Insurance, USA.
Thanks to Wanda Prather, FRTIB, USA.
Change 29.016 When the _SMF macro was redesigned to store DB2 IFCID in
VMACSMF SUBTYPE, and READDB2 was revised to generate tests using
Feb 2, 2011 the SUBTYPE instead of IFCID, the _DB2GTF macro was not
updated, so %READDB2(INFILE=GTF,IFCIDS=xxx) failed to
output any observations. Macro _DB2GTF is now revised.
Thanks to Tony Curry, BMC, USA.
Change 29.015 Support for Version 7, which (COMPATIBLY) added three
VMAC115 sets of eight variables providing compression statistics,
Feb 1, 2011 one set for each of the three algorithms, although only
the first algorithm's variables are currently populated.
Thanks to Martyn Jones, Euroclear, BELGIUM.
Change 29.014 A new "exit", macro variable &EOFVMXA, for MWINPUT file,
VMACVMXA it inserted at the EOF of reading that MONWRITE data so
VMXGINIT users can take action if the input file is empty or has
Jan 29, 2011 invalid (no Control Record) contents. MONWRITE data is
ftp'd to the MXG platform, but an ftp failure causes an
empty file, which MXG processes without error, but that
has not observations created; that is reported in MXG's
"SUCCESSFULLY READ" message as having zero records.
This exit allows you to insert your own code to detect
there was a failure and you create your own log message
and then ABORTing the MXG job to externalize the error.
For example, the exit could be used with this syntax:
%LET EOFVMXA=
%QUOTE(
IF NRDRRECS LE 0 OR NRCRTOTL LE 0 OR
NRBYTOTL LE 0 THEN DO;
PUT ' ';
PUT '#####################################';
PUT 'ERROR: Z/VM MONWRITE FILE IS INVALID.';
PUT '#####################################';
PUT '>>>> CONTACT z/VM Support ON-CALL <<<< ';
PUT '#######################################';
PUT '# DETAILS:';
PUT '#######################################';
PUT //" MXG &MXGVERS FOUND THESE COUNTS:"
//+5 'THERE WERE ' NRDRRECS ' MONITOR RECORDS '
//+5 'FROM ' NRCRTOTL ' CONTROL RECORDS WHICH '
//+5 'CONTAINED ' NRBYTOTL COMMA15. ' BYTES, ( '
NRBYTOTL MGBYTES. 'B)';
PUT '#######################################';
PUT '#######################################';
ABORT ABEND 16;
END;
ELSE
);
%INCLUDE SOURCLIB(TYPEVMXA);
-Note that after your DO/END group, the "ELSE" is required
because the exit is inserted ahead of an existing PUT.
-Also note that the first line of the sample PUT statement
has double quotes around the text; this is required so
that the &MXGVERS macro variable's value is printed. With
single quotes only the text MXGVERS would be printed.
Thanks to Frank Bright, MEDCO, USA.
Thanks to Frank Bright, MEDCO, USA.
Change 29.013 -Variable CPCGRPLM in ZRBCPU is only four bytes but MXG
VMACRMFV input as 8 bytes; the commented +4 is moved ahead of the
Jan 30, 2011 input and the informat changed to PIB4.
-Variable LCPUPOLR was incorrectly input from two bits in
the first byte of LCPUCHIN; it is the last bit of first
byte and first byte of second byte (which is now input
and kept as LCPUCHI2).
Thanks to Matthew Chappell, Dept. of Transport Main Roads, AUSTRALIA
Change 29.012 Support for Endeavor Version 14 (INCOMPATIBLE because MXG
VMACENDV did not test the segment length and 20 bytes were added),
Jan 31, 2011 causing many missing variables in ENDVERAC dataset. The
fields added are now decoded and seven variables created.
Thanks to Rob D'Andrea, CIS, ENGLAND.
Change 29.011 Cosmetic. Variables with DATETIME value were stored as
VMACIMS length 5 instead of length 8, which can truncate times
ASUMSYTA up to 4 seconds.
VMACBE91 DATASET MEMBER VARIABLE
VMACCYFU ASUMTAPE ASUMSYTA REALMSMF
VMAC28 BETA91C VMACBE91 BE91CSST
VMACPMTR PERFMETR VMACPMTR STARTIME
VMACPW PWPDPD VMACPW ENDTIME
VMACSHDW PWPDPDI VMACPW ENDTIME
VMACTMVS SHADOW05 VMACSHDW SM05LGTM
VMAC90A TMVSCO VMACTMVS IPLTIME
VMACVMXA TYPE9033 VMAC90A SMF9033T
VMACXAM TYPE9034 VMAC90A SMF9034T
Jan 28, 2011 VXSYTSPT VMACVMXA SRXATOD
XAMSYVSW VMACXAM VQSCTTOD
Change 29.010 Variables NDMPRCNM, NDMPRCNO, and NDMSTEP were not kept
VMACNDM in all datasets where they exist in the "NDMPRC" header
Jan 25, 2011 or in the "Record" data segment; the table in comments at
the top of VMACNDM has been updated with a new column to
identify the datasets that have those variables, and all
datasets that are decoded now contain these variables.
Thanks to Michael Oujesky, Bank of America, USA.
Change 29.009 VMXGUOW fails if //CICSTRAN or //DB2ACCT is on tape, with
VMXGUOW MXG 28.06 thru MXG 28.28, but the error is circumvented
Jan 24, 2011 if you add LIBNAME statements to tell MXG it's on tape:
Jan 31, 2011 //SYSIN DD *
LIBNAME CICSTRAN V9SEQ;
LIBNAME DB2ACCT V9SEQ;
%LET PCICTRN=CICSTRAN;
%LET PDB2ACC=DB2ACCT;
%LET MACKEEP= MACRO _NOOBS % MACRO _YESOBS %
%INCLUDE SOURCLIB(ASUMUOW,ASUMCICX);
-Prior to Change 28.204, VMXGUOW only tested existence of
the _Ldddddd dataset token, but in 28.204, a test for the
existence of that LIBNAME was added (so we could tell you
what you did wrong when you didn't have one). But under
z/OS, if the LIBNAME had not been referenced in this SAS
session, it is not in DICTIONARY, and MXG fell thru to
use WORK for the LIBNAME, but as WORK.CICSTRAN did not
exist (your data was in CICSTRAN.CICSTRAN on tape), MXG
failed with NOT FOUND BY VARIABLES and MXGWARNS.
-In this revision, the EXTFILES table is scanned and if
the &PCICTRN "ddname" is found, _LCICTRN is set to
CICSTRAN. Likewise, _LDB2ACC and _LMONTSK are set to the
normal defaults if not found.
-In all cases, if the LIBNAME pointed to does not exist,
VMXGUOW will still fail.
Thanks to Hugo L. Michel, Prince Georges County, MD, USA.
Change 29.008 -WEEKBLD/MONTHBLD: to eliminate NOTSORTED errors, MXGNOBY
VMXGINIT is now specified in VMXGINIT so there will be no testing
BLDSMPDB of the sort order of the input, and no NOTSORTED error.
Feb 3, 2011 -BLDSMPDB: SORTEDBY=NO is now specified as the default.
(Also, LIBNAME=WEEK1 was in error and changed to WEEK.)
-Previously, you had to define MXGNOBY with this statement
%LET MXGNOBY= MACRO _BY % MACRO _SORTBY % ;
in your //SYSIN DD, to disable the sort testing and the
interleave of input observation in sort order. That will
still work fine, but no longer needed with this change.
Although I can't see a reason why you would want to go
back to the NOTSORTED exposure, you can redefine macro
MXGNOBY as null with this syntax to reinstate sorting:
%LET MXGNOBY= ;
-The exposure occurs when MXG has to change the sort order
of a dataset when it is built, and that dataset with new
sort order is combined in WEEKBLD/MONTHBLD with datasets
that were created with the previous sort order.
-The only reason MXG ever changes the sort order is when
the initial order was insufficient to remove duplicates
with the NODUP option of PROC SORT. Errors can occur if
your old WEEKBLD has the old sort order (TYPE72DL in MXG
28.28), or if MXG failed to update the new order in its
WEEKBLD/MONTHBLD member (DB2STATS in MXG 28.28)
-MXG does not require the WEEKLY and MONTHLY datasets to
be sorted; no report programs should ever expect ordered
data as there is no way to guarantee someone else didn't
sort the dataset after it was first created.
-Building sorted output is only a possible performance
benefit: if subsequent programs happen to use the same
order in their PROC SORT, SAS is smart enough to bypass
the unneeded sort, and that was the original purpose for
creating WEEKBLD/MONTHBLD in sort order. And, because
the "daily" datasets were already sorted, the WEEKBLD and
MONTHBLD programs preserved that sort order with a BY
statement, without re-sorting.
-However, it turns out that disabling the sort order test
and building the output as the concatenation of the input
datasets instead of interleaving observations to preserve
the sort order is a REAL performance benefit: benchmarks
show a reduction of about 12% of the CPU time with the
MXGNOBY enabled.
Change 29.007 Documentation if CICSTRAN variables are EXCLUDEd/DROPPED.
ASUMUOW This isn't new behavior, and has been in place long time.
ASUMCICX For ASUMUOW to execute, these BY-VARIABLES are REQUIRED:
Jan 21, 2011 TRANNAME STRTTIME ENDTIME NETSNAME
UOWID UOWIDCHR UOWTIME
There is no circumvention; ASUMUOW fails without them.
These KEPT variables from CICSTRAN aren't required for
execution, but MXGWARN messages will be printed if
these variables do not exist in your CICSTRAN:
APPLID USER LUNAME SYSTEM TERMINAL USERCHAR
This list is defined in MACRO _KUOWIDC, which you can
redefine to keep only your variables to eliminate the
MXGWARN messages.
For ASUMCICX to execute, these BY-VARIABLES are REQUIRED:
APPLID OPERATOR USER TERMINAL STRTTIME TRANNAME
SYSTEM SHIFT
If any do not exist, ASUMCICX fails.
This list is defined in MACRO _BSUCICS and some can be
removed, but you could end up with useless output if,
for example, you didn't keep STRTTIME.
If some of these variables are not kept, you can redefine
_KUOWIDC and _BSUCICS to list only those that exist.
For example, these variables are removed from CICSTRAN:
USER OPERATOR TERMINAL USERCHAR
Then you would add the MACRO _KUOWIDC and _BSUCICS into
the %LET MACKEEP= in your current JOB:
//UOWCICX EXEC MXGSAS92
//CICSTRAN DD DSN=YOUR.CICSTRAN,DISP=SHR
//DB2ACCT DD DSN=YOUR.DB2ACCT,DISP=SHR
//PDB DD DSN=NEW.ASUMUOW,DISP=(,CATLG),...
//SYSIN DD *
%LET PCICTRN=CICSTRAN;
%LET PDB2ACC=DB2ACCT;
%LET MACKEEP=
MACRO _KUOWIDC APPLID LUNAME SYSTEM %
MACRO _BSUCICS APPLID STRTTIME TRANNAME SHIFT %
MACRO _NOOBS % MACRO _YESOBS %
;
%INCLUDE SOURCLIB(ASUMUOW);
%INCLUDE SOURCLIB(ASUMCICX);
Thanks to Hugo L. Michel, Prince Georges County, MD, USA.
Change 29.006 Variables DVRTBV01-DVRTBV32, Returned Borrowed Volumes,
VMACBVIR were incorrectly formatted $MGBVIPT but $MGBVIPO is the
Jan 21, 2011 correct format to decode when printed.
Thanks to Doug Boettcher, Atco I-Tek, CANADA.
Change 29.005 Documentation of INTERVAL= change in default RMFINTRV.
RMFINTRV INTERVAL=DETAIL in MXG 27.27 became INTERVAL=QTRHOUR in
Jan 19, 2011 MXG 28.01, Change 28.046, in MXG default RMFINTRV member,
but that was not documented, carelessly, but also because
I didn't think anyone used MXG's default RMFINTRV member.
I expected each site to have their own tailored RMFINTRV
with both INTERVAL= and WORKnn= (maps Service Classes to
WORKLOADs) definitions, and thus my default would only be
used by new sites, and only before they read the INSTALL
instructions to tailor those RMFINTRV definitions, so I
could change the interval with impunity. Well, almost!
I replaced DETAIL with QTRHOUR because DETAIL creates an
observation for every RMF start, including those short
interval at each IPL that have VERY high CPU Busy and are
outliers on normal interval graphs and reports, whereas
INTERVAL=QTRHOUR creates equal intervals and smooth data.
But, with DETAIL, you get an observation with the exact
STARTIME of each interval, and if SYNC59 is in use, those
startimes were of 59:00 14:00 29:00 44:00. But SYNC59=YES
is the default for Real Intervals, so changing from the
INTERVAL=DETAIL to INTERVAL=QTRHOUR, for SYNC59 sites,
changed their STARTIMEs to 00: 15: 30: & 45: when they
"dropped-in" MXG 28.28 after MXG 27.27. Tailoring their
RMFINTRV with INTERVAL=DETAIL restored original values.
Change 29.004 ISO format dates with 19990000 for "never expire" are now
VMACEDGR detected and the DATE variable is set missing.
Jan 20, 2011
Thanks to Harald Seifert, Huk-Coburg, GERMANY.
Change 29.003 If you have ancient JCL with //SASAUTOS DD DSN=&&NULLPDS,
VMXGGETM MXG 28.28 UTILGETM ran much longer (10x) because it did
Jan 19, 2011 not read the (new in 28.28) %DATATYP macro function from
the SAS-provided AUTOCALL PDS. The ERROR message didn't
stop the read of the large SMF file, but the message
wasn't the expected APPARENT MACRO %DATATYPE NOT FOUND.
Because of the way %DATATYP was used, the error was:
ERROR: Character operand was found in the %EVAL function
... where %DATATYP(&NRECORD) NE NUMERIC ....
The JCL &&NULLPDS token was removed many MXG versions ago
for unrelated problems and lack of need, but I was not
aware that the &NULLPDS stopped the AUTOCALL search, but
only recent MXG versions actually use macros (%TRIM) from
that library. But the %DATATYP was added ONLY to detect
that you had mistyped an alphabetic text for NRECORD=,
and only in your own %VMXGGETM invocation (UTILGETM has
NRECORD=50), so we shot ourselves in the foot adding it.
And ONLY to prevent a less-than-clear warning message.
DATATYP is no longer used; the logic is in a data step.
Change 29.002 -APAR OA31615 was NOT supported by MXG 28.28 as claimed.
VMAC89 That APAR will cause many INVALID SMF89CTZ log messages,
Jan 20, 2011 but the job does NOT ABEND (unless the log fills!).
Jan 21, 2011 -MXG detection of records with Invalid Intersect Segments
Feb 3, 2011 had no limit on the number of Invalid Record messages,
but also falsely detected some valid records as invalid.
The MXG test was corrected so only true Invalid segments
are detected, and only the first 3 are printed on log.
-But, feedback from IBM has clarified the new intersect
data in new TYPE89I dataset, and MXG was wrong to carry
the PRODxxxx variables from the Usage Data Section; those
variables were removed from the KEEP= list, and from the
Sort Order in MACRO _BTY89I, which now uses the CPO-CPI
and IPO-IPI variables to order and remove duplicates, and
is sequenced SMF89UST SMF89IST within those variables.
-Unrelated to the APAR, these variables in subtype 2 have
never been populated and are no longer kept in TYPE892:
MACHTIME SMF89UET SMF89UST
Thanks to Jim Poletti, Edward D. Jones, USA.
Thanks to Jeana M. Bechtel, Edward D. Jones, USA.
Thanks to Al Sherkow, I/S Management Strategies, Ltd.
Thanks to Scott Barry, SBBWorks Inc, USA.
Thanks to Harald Seifert, Huk-Coburg, GERMANY.
Change 29.001 Support for SMF 111 IPIC now creates obs in TY111CXI.
VMAC111 No observations were created because MXG incorrectly had
Jan 19, 2011 them to be in CTGRECID=2 when they are CTGRECID=7, so the
Jan 24, 2011 code for IPIC was relocated to that correct subtype, and
obs are now created.
-Warning added when a new subtype is detected.
-Change 28.329 for SMF 111 was NOT included in 28.28 as
originally claimed.
Thanks to Jim Poletti, Edward D. Jones, USA.
Thanks to Jeana M. Bechtel, Edward D. Jones, USA.
Thanks to Gordon E. Griffith, Edward D. Jones, USA.
LASTCHANGE: Version 29.