COPYRIGHT (C) 1984-2023 MERRILL CONSULTANTS DALLAS TEXAS USA
MXG CHANGES 22.22
=========================Member=CHANGE22================================
/* COPYRIGHT (C) 1984-2005 MERRILL CONSULTANTS DALLAS TEXAS USA */
MXG Version 22.22 is dated Feb 1, 2005, thru Change 22.378
Early MXG Version 22.22 was dated Jan 22, 2005, thru Change 22.366
MXG Version 22.13 was dated Jan 13, 2005, thru Change 22.350
First MXG Version 22.13 was dated Jan 12, 2005, thru Change 22.345
Final MXG Version 22.12 was dated Dec 11, 2004, thru Change 22.316
Second MXG Version 22.12 was dated Dec 10, 2004, thru Change 22.313
First MXG Version 22.12 was dated Dec 2, 2004, thru Change 22.308
MXG Version 22.11 was dated Oct 26, 2004, thru Change 22.277
MXG Version 22.10 was dated Oct 13, 2004, thru Change 22.264
MXG Version 22.09 was dated Aug 25, 2004, thru Change 22.227
Final MXG Version 22.08 was dated Aug 20, 2004, thru Change 22.219
Second MXG Version 22.08 was dated Aug 13, 2004, thru Change 22.207
First MXG Version 22.08 was dated Aug 12, 2004, thru Change 22.205
Final MXG Version 22.07 was dated Jul 25, 2004, thru Change 22.180
MXG Version 22.07 was dated Jul 23, 2004, thru Change 22.177
MXG Version 22.06 was dated Jun 15, 2004, thru Change 22.129
MXG Version 22.05 was dated May 22, 2004, thru Change 22.108
MXG Version 22.04 was dated May 2, 2004, thru Change 22.099
MXG Version 22.03 was dated Apr 5, 2004, thru Change 22.066
First MXG Version 22.03 was dated Apr 2, 2004, thru Change 22.063
MXG Version 22.02 was dated Mar 24, 2004, thru Change 22.055
MXG Version 22.01 was dated Mar 11, 2004, thru Change 22.036
First MXG Version 22.01 was dated Mar 10, 2004, thru Change 22.034
Final MXG Version 21.21 was dated Feb 11, 2004, thru Change 21.320
MXG Newsletter FORTY-FOUR was dated Feb 11, 2004.
Contents of member CHANGES:
Member NEWSLTRS (and the Newsletters frame at http://www.mxg.com) now
contain the current MXG Technical Notes that used to be put in member
CHANGES between Newsletters. New Technical Notes are now added (and
now dated!) in NEWSLTRS/Newsletters with each new MXG Version.
I. MXG Software Version 22.22 is now available upon request.
II. Incompatibilities and Installation of MXG 22.13.
III. Online Documentation of MXG Software.
IV. Changes Log
=======================================================================
I. MXG Software Version 22.22 is available upon request.
Major enhancements added in MXG 22.22
BUILDPDB 22.365 BUILDPDB now sets Condition/Return code of zero.
ASUMMIPS 22.354 Interval Capacity by Workload, MIPS and MSU used.
ASMTAPEE 22.366 MXGTMNT ML-32, has MEXIT=ON,XMEMF=ON,ARCV=ON
TYPE110 22.359 Support for CICS/TS 3.1 with no EXCLUDEd fields.
UTILEXCL 22.347 New CICS/TS 3.1 WBREPRDL/WBREPWDL/PGCRECCT supported.
TYPE7072 22.349 Negative PCTMVSBY/CPUMVSTM/SHORTCPs, SMF70CNF bit 6.
TYPE30 22.375 IBM error in CPUIFATM, MXG error in SRVTCBTM.
TYPETPF 22.374 Support for MQ Series in TPF operating system.
TYPEQACS 22.371 Support for OS/400 5.3.0, new QAPMSYS dataset.
TYPEVMXA 22.369 Support for z/VM 4.4 and 5.1 new data (INCOMPATIBLE).
Major enhancements added in MXG 22.13
BUILDPDB 22.342 TYPE115/TYPE116 are now in BUILDPDB, will cause error
if you have already tailored MXG to add 115/116s.
You must remove your 115/116 tailoring from EXPDBxxx
or you will get this error message if you miss this:
ERROR: DATA SET WORK.MQMLOG IS ALREADY OPEN ....
BUILDPDB 22.320 MULTIDD='Y' obs now combined in PDB.SMFINTRV.
BUILDPDB 22.326 Variable CPUCEPTM now deaccum in PDB.SMFINTRV.
TYPE110 22.312 Support for CICS/TS 3.1 (INCOMPATIBLE).
UTILEXCL 22.350 Support for CICS/TS 3.1 new fields, errors fixed.
ASUMUOW 22.336 MQMACCT/MQMACCTQ data can be added to PDB.ASUMUOW
TYPE70 22.325 "Short CPs" variable SHORTCPS created in TYPE70.
TYPE70PR 22.325 "Short CPs" variable SHORTCPS created in TYPE70PR.
TYPETNG 22.339 Major TNG enhancement - array sizes dynamically set.
TYPE74 22.334 Support for APAR OA06476 type 74 subtype 5 and 8.
ONLYINTV 22.326 Example to build only PDB.SMFINTRV/PDB.TYPE30_6.
TYPE6 22.321 Support for second format type 6 PrintWay record.
TYPE7072 22.340 Revision to support for varying IFAs online/offline.
IMAC6ESS 22.332 Support for GEPARMKY 0036, 0041, 0043, fix 0034x.
TYPEHIOM 22.331 Support for hIOmon File I/O Performance Monitor.
This is a Windows environment monitor that tracks
I/O activity to the filename and user.
MONTHDSK 22.343 "MONTHBLD" program to build MONTHLY PDB on disk.
Major enhancements added in MXG 22.12
MXG 22.12 corrects IRD errors introduced in MXG 22.10/22.11.
MXG 22.12 corrects TYPE6 errors introduced in MXG 22.10/22.10.
TYPE6 22.309 Final correction for type 6 INPUT EXCEEDED errors.
TYPE6 22.298 SMF 6 STOPOVER on PrintWay section - missing @;
TYPE7072 22.307 Negative CPU values for IRD - Required CHANGE.
TYPEHURN 22.304 Support for ObjectStar subtype 45 Page Sweep.
TYPE6 22.302 Support for VPS V1 R8.0 VPS-FAX data
TYPE102 22.294 Support for APAR PQ73385,PQ91101 for IFCIDs 217, 225
TYPE102 22.294 Support for APAR PQ87848 for IFCID 173
TYPECIMS 22.314 Support for Mainview IMS IMF 4.1.00 (NO CHANGES!).
UTILEXCL 22.313 Support for APPLNAME,CANDEXNM,CANDEXTY CICS segments.
TYPENSPY 22.312 Support for NetSpy Version 7.0 (COMPATIBLE).
TYPEQACS 22.311 Support for OS/400 5.3.0 CONF/DISK/POLL/JOBL data.
ASMRMFV 22.316 Enhanced support for RMF III VSAM files.
TYPETNG 22.291 Support TNG NT Platforms NTW400I, WNS502I, ZPP501I.
VMACSMF 22.300 Use of FTP access to read SMF MVS-to-MVS supported.
ASUM70PR 22.293 LP0xxxxx variables now populated with PHYSICAL's data
CICINTRV 22.288 Comments show how to create PDB.CICINTRV from SMF.
VMXGPRAL 22.287 Enhancement to use PROC FREQ, example for 102 "who".
TYPE80A 22.286 Numerous enhancements, multiple RACF segments, etc.
ANALSIZE 22.276 Utility to analyze size of SAS data libraries.
ASUM70PR 22.274 Vars TOTSHARE/TOTSHARC kept for orig/current weights.
Major enhancements added in MXG 22.11
MXG 22.11 is NOW required for z/OS 1.6 with IFA/zAAPs, and it HAS
been tested with SMF 30, 70, and 72s from a system with real IFAs!
MXG 22.09 and MXG 22.10 do correctly support z/OS 1.6 without any
zAAP engines, but actual test data uncovered MXG errors and IBM
undocumented fields (Changes 22.272, 22.262, 22.265) that caused
most of the IFA/IFE fields to contain invalid values.
Additional enhancements in 22.11:
TYPE30 22.272 Support for zAAP IFA engines.
TYPE7072 22.272 Support for zAAP IFA engines.
TYPE30 22.265 Support for APAR OA09118, adds CPUCOEFF to SMF 30s.
TYPE94 22.268 Support for VTS R7.3 additional statistics.
TYPECMF 22.266 Support for CMF Version 5504 User SMF (INCOMPAT).
VMACDB2H 22.270 22.08-22.10 only. DB2 V8.1 INPUT STATEMENT EXCEEDED.
TYPE71 22.269 22.07-22.10 only. LPAxxxx variables missing values.
Major enhancements added in MXG 22.10
MXG 22.10 supports z/OS 1.6, but only if there are no IFA engines.
Additional enhancements in 22.10:
TYPE7072 22.260 Support for z/OS 1.6 WITH IFA engines.
TYPEVMXA 22.240 Support for z/VM 4.4, INCOMPAT.
TYPENTSM 22.246 Support for NTSMF Release 2.4.7 COMPATIBLE.
TYPEXAM 22.245 Support for XAMAP Release 3.4 INCOMPAT.
TYPETDSL 22.249 Support for TDSLink product's user SMF record.
TYPEBETA 22.250 Support for BETA93 Release 3.5 subtypes 0-5.
TYPETMDB 22.235 Support for ASG/Landmark TMON for DB2 V4.0 (COMPAT)
SYSLOG 22.238 Preliminary support for SYSLOG file.
ANALGART 22.242 Example analysis for Gartner Group requests.
ASUMCIMS 22.241 Example summarization of the four IMF datasets.
ERRORASC 22.239 ASCII platform errors when incorrect SMF download.
ANALFLSH 22.236 New member tracks concurrent flash copies executing.
TRND.... 22.258 Symbolics &TRENDINP,&TRENDNEW,&TRENDOLD added.
Major enhancements added in MXG 22.09
MXG 22.09 supports z/OS 1.6, but only if there are no IFA engines.
See Change 22.221 and especially MVS Technical Notes in NEWSLTRS.
Major enhancements added in MXG 22.08
MXG 22.08 is required for safe execution with SAS V9.1.2 or V9.1.3.
While MXG 22.07 had critical revisions for SAS 9.1.2, more design
changes were discovered in V9.1.2 that required more MXG changes.
In addition, Syncsort's add-on product PROC SYNCSORT was found to
corrupt INFORMATs, causing fatal errors in BUILDPDB, but because
I could remove all MXG INFORMAT statements faster than they could
even examine their error, I believe you can safely use that add-on
with MXG code (but you'll need to check your own code for INFORMAT
and watch for their eventual revised version that will work with
SAS V9.1.2). Note, the errors are in the PROC SYNCSORT add-on
product (which prints "PROC SYNCSORT" on your SAS log if used).
We have not seen these errors with the Syncsort Sort product.
The Syncsort ticket number # SR387805 is open for PROC SYNCSORT.
The details of the MXG changes that support V 9.1.2 and V 9.1.3 are
in the change text of the below MXG changes, but for execution of
MXG under "MVS", the only critical changes required are to:
- Install MXG 22.08 and use MXGSASV9 and CONFIGV9 from 22.08, and
- Run the UTILS2ER utility against all of your source libraries to
see if any lines of your SAS programs conflict with S2=72 option
that was required to replace the previous S2=0 option in MXG.
Changes related to SAS V9.1.2 and MXG execution:
CONFIGV9 22.207 NOTHREADS specified for 9.1.2 error, fixed in 9.1.3.
(the NOTHREADS change caused the Aug 13 re-date of MXG 22.08!),
CONFIGV9 22.108 CRITICAL Hot Fix SN-012437 Required for SAS V9.1.2
CONFIGV9 22.123 SAS V9 on MVS VB INCOMPAT: S2=72 must be S2=0.
MXGSASV9 22.130 Revised MXG JCL example for SAS V9, NLS names, etc.
MXGSASV9 22.126 SAS dsnames must be "W0", w-zero, not w-oh.
CONFIGV9 22.108 Support for V6SEQ under SAS V9.1
UTILS2ER 22.123 Utility to detect errors with S2=0 in your programs.
FLASH 22.108 CRITICAL SAS Hot Fix SN-012437 is REQUIRED for V9.1.2
Many 22.184 SAS V9.1.2 $VARYING design change protected.
AUTOEXEU 22.102 autoexec.sas file for unix, protects SASAUTOS error.
Some 22.108 Support for SAS V9.1 and V6SEQ without Hot Fix.
Many 22.192 Protection for PROC SYNCSORT error with SAS V9.1.2
Additional important enhancements in MXG 22.08:
TYPETMO2 22.191 Support for ASG/TMON TCE for CICS/ESA 2.3, COMPATIBLE
Many 22.180 Support for IFA CPU variables for zAAP processors.
Many 22.177 Update to define MACRO _Vdddddd for numeric SMF plus.
Many 22.192 All INFORMAT $NOTRAN statements were removed.
TYPEIMS7 22.199 Major revision to IMS0708 dataset, all events output.
VMACDB2H 22.196 Support for extended length DB2 id variables.
TYPENTSM 22.193 Support for NTSMF Exchange/Outlook/DTS CPU objects.
TYPENTSM 22.190 Support for NTSMF MicroStrategy Server objects.
TYPEOMVT 22.186 Omegamon/VTAM V520 IRNUM 29 Divide by zero corrected.
TYPE80A 22.185 Invalid SMF 80 Extended Relocate Section protected.
ANALRMFR 22.181 Enhancements to RMF reporting.
ADOC110 22.189 Major updated added 1300 lines of CICS documentation.
Note: The Aug 20 re-date of MXG 22.08 was made only because it was
easy to do; I discovered that members were missing from the
3480 tapes (not from ftp nor CD-rom shipments) and so I chose
to create replacement tapes with the added changes that were
made during the week.
Major enhancements added in MXG 22.07
TYPE7072 22.152 Support for IFA Processors, APAR OA05731.
TYPE7072 22.137 Support for z890 CPUTYPE 2086, OS/390-INCOMPAT.
TYPE74 22.141 Support for RMF 74 subtype 8 ESS Link Stats record.
TYPETNG 22.170 Support for TNG Windows Server 2003 new objects+fix.
IMACICHO 22.169 Hogan optional CICS data member now exists
TYPEHMF 22.168 Support for HMF V2.7 new subtypes, compatible.
TYPEHPDM 22.166 Support for STK ExHPDM user SMF record.
BUILDPDB 22.165 BUILDPDB detects overlapped SMF data previously read.
IMAC6ESS 22.161 Support for ESS GEPARMKY 003Bx and 0045x fields.
TYPETNG 22.160 REGION reduced for JCLTEST8 TESTOTHR due to TYPETNG.
UTILBLDP 22.149 Enhancement supports subtype selection in ZEROOBS.
VGETENG 22.148 Enhancement to get Engine and Device Type of LIBNAME
ASUM42DS 22.147 Performance enhancement reduce I/O, CPU using view.
TYPE119 22.146 TYP119nn datasets had GMT time zone, now have local.
JCLRMF 22.143 Example to create "RMF-only" PDB from SMF data.
ASUMUOW 22.139 Variables APPLID/USER/LUNAME/TERMINAL incorrect.
ANAL4GB 22.138 Revised to use DCOLLECT to detect large VSAM files.
IEFU84 22.136 SMF exit to get Initiator Name and Number for jobs.
ASUM70PR 22.135 MVS System Name of each LPAR, SMF70STN, added.
TYPE70 22.134 Percent when each engine online PCTONLN0-PCTONLNX.
TYPENDM 22.133 Support for several additional NDM-CDI subtypes.
TYPENSPY 22.131 TYPENSPY and TYPENETM combined, only one SMF record.
TYPENETM 22.131 TYPENSPY and TYPENETM combined, only one SMF record.
MXGSASV9 22.130 Revised MXG JCL example for SAS V9, NLS names, etc.
UTILCONT 22.175 Utility to Inventory the Megabyte Sizes of PDBs.
Major enhancements added in MXG 22.06
Really major:
Change 22.123 - SAS V9 on "MVS" INCOMPAT due to RECFM=VB on the
SAS-supplied SASMACRO library requires the MXG
default S2=72 be changed to S2=0, which itself
raises another potential incompatibility in SAS
programs, so new UTILS2ER must be run against
your SAS programs before migration to SAS V9,
or your programs may have strange ABENDs. See
extensive discussion in text of Change.
Change 22.121 - CPU time for DB2 Parallel Trans was not output
(i.e., lost, could be very large) in DB2ACCT.
See the Change text, and also the DB2 Technical
Note in Newsletter FORTY-FIVE.
CONFIGV9 22.123 SAS V9 on MVS VB INCOMPAT: S2=72 must be S2=0.
UTILS2ER 22.123 Utility to detect errors with S2=0 in your programs.
TYPEDB2 22.121 DB2 Parallel CPU time lost, not output in DB2ACCT.
TYPEDB2 22.124 MXG 22.04-05, QWHSSTCK missing in SMF 102 trace data.
EXDB2ACC 22.121 DB2 Parallel CPU time lost, not output in DB2ACCT.
TYPEIPAC 22.125 Support for IPAC subtype 5 IPAC05 corrections.
IMAC6ESS 22.117 Support for optional ESS segment GEPARMKY=003Bx.
BUILDPDB 22.115 JES3 PDB only; wrong TYPE26J3 used in BUILDPD3.
TYPE102G 22.109 TYPE102G to read DB2 Trace written to GTF didn't.
BLDIMPDB 22.128 ASCII equivalent of JCL for JCLIMSLx execution.
TYPEIMSA 22.113 ASCII execution only, APPLID not readable.
TYPEEDGS 22.112 INPUT STATEMENT EXCEEDED with MVRECLEV '02'x.
ANALFIOE 22.127 Run time improvement if SMF, instead of PDB, input.
BLDSMPDB 22.111 unix case sensitivity corrections
BLDNTPDB 22.111 unix case sensitivity corrections
MXGSASV9 22.126 SAS dsnames must be "W0", w-zero, not w-oh.
Major enhancements added in MXG 22.05
CONFIGV9 22.108 Support for V6SEQ under SAS V9.1
FLASH 22.108 CRITICAL SAS Hot Fix SN-012437 is REQUIRED for V9.1.2
TYPE102C 22.104 Support for Candle Omegamon II for DB2 IFCID Trace.
AUTOEXEU 22.102 autoexec.sas file for unix, protects SASAUTOS error.
Major enhancements added in MXG 22.04
TYPE110 22.094 Support for CICS/TS 2.3 with no EXCLUDEd fields.
(If you use UTILEXCL with your CICS/TS 2.3 data,
there was no error, but CICSTRAN without IMACEXCL
was wrong if all fields were present in 110-1.)
TYPEQACS 22.095 Support for OS/400 5.2 QAPMMIOP record new fields.
TYPETNG 22.085 Support for NT objects SESSION and USER in TNG cubes.
TYPEAIX 22.083 Support for AIX PTX new objects.
TYPEIBSM 22.079 Support for IBM Session Manager user SMF record.
TYPETPMX 22.077 Support for alternative multiple-ACCT field TPM data.
TYPE74 22.075 Support for 1024 structures in Coupling Facility.
UTILEXCL 22.068 Support for optional RMI data in CICSTRAN.
VMXGINIT 22.096 Macro variables &MACINTV and &MAC30DD created.
TYPEDB2 22.090 MXG 22.02-22.03 only. QWHSSTCK 1960 date in DB2ACCT.
TYPEDB2 22.084 Large QBSTGET in DB2STATB due to DB2 restart fixed.
TYPE70 22.087 Non-PR/SM, IORATE/PCTTPI variables too low.
TYPE7072 22.072 TYPE72GO with R723CWMN GT 0, Periods not output.
MONTHASC 22.064 Example "MONTHBLD" for ASCII systems.
AUTOEXEC 22.064 LIBNAME DUMMY added to support MONTHASC.
Major enhancements added in MXG 22.03
Revision of ThruPut Manager TYPETPMX to not use ARRAYS to save CPU.
(34 new datasets); Change 22.060.
Major enhancements added in MXG 22.02
If you are using IRD, you must install MXG 22.12 or later:
(This note originally said MXG 22.02, but now, Change 22.307 in
MXG 22.12 is required for IRD values to be correct!)
--Full Support for IRD (Intelligent Resource Director) is now in all
CPU-related datasets. IRD support was incremental in MXG:
Datasets When MXG Version Change
ASUM70PR/ASUMCEC Sep 22, 2003 21.05 21.170
TYPE70PR Mar 11, 2004 22.01 22.011
TYPE70,RMFINTRV Dec 2, 2005 22.12 22.307
PCTCPUBY in TYPE70 and RMFINTRV were wrong in any interval when IRD
varied CPUs offline. I'm embarrassed, since PCTCPUBY is the second
most important variable in all of MXG (CPUTM for billing is the most
important); this is the first PCTCPUBY error in MXG's history! When
all engines remained online, however, there was no error.
BUILDPDB 22.052 PDB.STEPS can have wrong EXCP,IOTM,TAPExxxx values,
but only in rare circumstance of identical INITTIMEs.
RMFINTRV 22.050 Variable PCTCPUBY wrong in RMFINTRV when IRD active.
TYPE70 22.050 Variable PCTCPUBY wrong in TYPE70 when IRD is active.
DB2STATB 22.045 Negative QBSTGET, other QBSTxxx, when 4-byte wrapped.
TYPEDB2 22.042 DB2 Stats records not written in subtype order.
ANALALL 22.040 Example now can write all SMF for selected job(s).
ASMTAPEE 22.038 ML-31 of MXGTMNT corrects GMT, MSC APAR support.
Major enhancements added in MXG 22.01
VMXGRMFI 22.017 BUILDPDB run time elongation, if output is to tape.
Circumvention: USE FREE=CLOSE on tape DDs. See text.
TYPE117 22.029 Support for SMF 117 WBIMB WebSphere Business Integrat
TYPE82 22.005 Support for SMF 82 Crypto subtypes 14 thru 19.
TYPEENDV 22.032 Support for Endeavor Release 4.0, INCOMPATIBLE.
TYPEHURN 22.006 Support for Huron/Object Star additional subtypes.
TYPESMSX 22.030 Support for DF/SMS Storage Class Exit User SMF record
Many 22.018 Hardcoded "SPIN" DDname now &SPININ,&SPINOUT macros.
TYPE120 22.014 WebSphere SMF 120s had GMT for many timestamps.
TYPE30 22.022 Variable SRVTCBTM,SRVSRBTM,CPUTOTTM created in TYPE30
TYPETMNT 22.012 RACFUSER/RACFTERM reversed, GMT times, INPUT EXCEEDED
TYPETPMX 22.008 (Final?) revisions to internal Thruput array names.
TYPE30 22.021 Job delays SMF30HQT/JQT/RQT/SQT revisions.
See member NEWSLTRS or the Newsletters frame at www.mxg.com for
current MXG Technical Notes that used to be in CHANGES.
All of these enhancements are described in the Change Log, below.
SAS Version requirement information:
MXG 22.08 or later is REQUIRED for SAS V9.1.2 or V9.1.3; see
"Major Enhancements in MXG 22.08" in CHANGES for details.
MXG executes best under the most recent SAS Version, with all
Critical HotFixes installed by your SAS Installer:
For 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 V7SEQ,V8SEQ, or V9SEQ.
Both fixes ARE included in SAS V9.1.3; earlier MXG notes that
they were required for 9.1.3 are wrong.
For SAS Version 8.2, HotFix Bundle 82BX08 is REQUIRED to be safe.
Sequential Engine Status:
V9SEQ is fixed in V9.1.3; it would be my default in CONFIGV9,
but I can't tell that you are at V9.1.3, and because V9SEQ
was badly broken prior to 9.1.3, I still have to use V6SEQ
and MXG's default in CONFIGV9. You should change to V9SEQ
in CONFIGV9 if you have installed SAS V9.1.3.
V6SEQ, if used under V9.1.2, requires SN-013514.
V8SEQ was always safe under SAS V8.2, but it wasted CPU time
by always compressing when writing in tape format.
MXG New Version QA tests are executed on z/OS with SAS V9.1.3 and
V8.2, and on (archaic) V6.09, and on Windows XP with SAS V9.1.3.
Previous tests of MXG Software have been run with SAS V9.1.2, SAS
V8.2 and V9.1 with Linux RH8 on Intel, with V9.1 on Solaris v2.8
model v880, and V9.1 on HP-UX v11.11 model rp5470, confirming full
compatibility. So MXG executes with SAS V9.1+ or SAS V8.2 on
every possible SAS platform! Each new MXG version is also tested
with SAS/ITSV/ITRM by ITRM developers.
Availability dates for the IBM products and MXG version required:
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 21.05
z/OS IRD TYPE70PR Mar 11, 2004 22.01
z/OS IRD TYPE70,RMFINTRV Mar 22, 2002 22.12
z/OS 1.6 - No IFAs Sep 30, 2004 *22.09
z/OS 1.6 - With IFAs Sep 30, 2004 *22.11
z990 CPUs - CPUTYPE '2084'x Aug 25, 2003 21.04
z890 CPUs - CPUTYPE '2086'x Jun 24, 2004 22.07
CICS/ESA 3.2 Jun 28, 1991 9.9
CICS/ESA 3.3 Mar 28, 1992 10.01
CICS/ESA 4.1 Oct 27, 1994 13.09
CICS/ESA 5.1 aka CICS/TS V1R1 Sep 10, 1996 14.07
CICS-Transaction Server V1R1 Sep 10, 1996 14.07
CICS-TS V1R1 with APAR UN98309 Sep 15, 1997 15.06
CICS-TS V1R2 CICS/TS 1.2 Oct 27, 1997 15.06
CICS-TS V1R3 CICS/TS 1.3 Mar 15, 1999 17.04
CICS-TS for Z/OS Version 2.1 Mar 15, 2001 18.11
CICS-TS for Z/OS Version 2.2 Jan 25, 2002 19.19
CICSTRAN subtype 1 support only *19.19
CICSTRAN subtype 2 completed *19.08
CICS-TS for Z/OS Version 2.3 Dec 19, 2003
Using UTILEXCL to create IMACEXCL: 21.04
Reading un-Excluded CICS with TYPE110, no IMACEXCL:*22.04
CICS-TS for Z/OS Version 3.1 Mar 15, 2005
Using UTILEXCL to create IMACEXCL: 22.13
Reading un-Excluded CICS with TYPE110, no IMACEXCL: 22.22
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 Mar 31, 2004 20.20
DB2 8.1 New Data Supported Mar 31, 2004 21.08
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
MQM 1.1.2, 1.1.3, 1.1.4 Apr 25, 1996 14.02
MQ Series 1.2.0 May 26, 1998 16.02
MQ Series 2.1.0 Oct 2, 1999 17.07
MQ Series 5.2 Dec 16, 2000 18.10
MQ Series 5.3 Dec 16, 2002 21.05
NETVIEW 3.1 type 37 ??? ??, 1996 14.03
NPM 2.0 Dec 17, 1993 12.03
NPM 2.2 Aug 29, 1994 12.05
NPM 2.3 ??? ??, 1996 15.08
NPM 2.4 Nov 18, 1998 17.01
NPM 2.5 Feb ??, 2000 18.02
NPM 2.6 Nov ??, 2001 19.06
RMDS 2.1, 2.2 Dec 12, 1995 12.12
RMDS 2.3 Jan 31, 2002 19.11
TCP/IP 3.1 Jun 12, 1995 12.12
TCP/IP 3.4 Sep 22, 1998 16.04
WebSphere 5.0 APAR PQ7463 Aug 19, 2003 21.04
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
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
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
Note: Asterisk before the version number means the Version number
was changed (to the MXG version required), after an earlier
MXG version was listed as supporting this product release,
usually because an APAR modified the product's data records.
Or a coding error in MXG could be the reason for the change!
Availability dates for non-IBM products and MXG version required:
MXG Version
Product Name Required
Demand Technology
NTSMF Version 1 Beta 14.11
NTSMF Version 2.0 15.05
NTSMF Version 2.1 15.06
NTSMF Version 2.2 16.04
NTSMF Version 2.3 17.10
NTSMF 2.4.4 Aug 9, 2002 20.04
NTSMF 2.4.5 INCOMPAT Apr 1, 2003 21.02
NTSMF 2.4.7 Sep 30, 2004 22.08
Landmark
The Monitor for DB2 Version 2 13.06
The Monitor for DB2 Version 3.0 16.02
The Monitor for DB2 Version 3.1 20.04
The Monitor for 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/ESA 2.1 - 20.04
The Monitor for CICS/ESA 2.2 - 20.335, 21.134 21.04
The Monitor for MVS/ESA 1.3 - 12.05
The Monitor for MVS/ESA 1.5 - 12.05
The Monitor for MVS/ESA 2.0 - 15.09
The Monitor for MVS/ESA 3.0 - 19.19
Candle
Omegamon for CICS V200 User SMF 12.05
Omegamon for CICS V300 User SMF 13.06
Omegamon for CICS V400 User SMF 16.02
Omegamon for CICS V400 type 110 segments 16.02
Omegamon for CICS V500 User SMF 18.01
Omegamon for IMS V110 (ITRF) 12.12
Omegamon for IMS V300 (ITRF) 14.04
Omegamon for 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
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
Memorex/Telex
LMS 3.1 12.12A
Amdahl
APAF 4.1, 4.3 16.08
Velocity Software
XAMAP 3.4 22.10
II. Incompatibilities and Installation of MXG 22.10.
1. Incompatibilities introduced in MXG 22.22 (since MXG 21.21):
a- Changes in MXG architecture made between 22.22 and 21.21 that might
introduce incompatibilities.
NONE.
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 JCLINSTL.
MXG Definitions with regard to MXG Software Changes:
COMPATIBLE A change in a data record which did not alter either
the location or the format of all of the previously-
kept MXG variables is COMPATIBLE, and you can continue
to run the old version of MXG software, which will read
the new records without error, but none of any new data
fields or any new record subtypes will be created/kept
until you install the MXG Version with this change.
A change that alters any previously kept variable is
INCOMPATIBLE, and requires the new version to be used.
TOLERATE In other words, the old MXG Version TOLERATES the new
data records, if they are COMPATIBLY changed.
EXPLOIT Once you use the new MXG Version to read the changed
records, all of the new fields, subtypes, etc, that are
described in this change will be created in the MXG
datasets, so the new MXG Version EXPLOITS the new data,
and you have full support of the new data records.
INCOMPAT A change in a data record that causes the current MXG
version to fail, visibly or invisibly, with or without
error conditions or messages, and the output datasets
may contain wrong values and incomplete observations,
and/or observations may have been lost.
You MUST install the new MXG Version with this change
to process data records that have been INCOMPATIBLY
changed by their vendor.
III. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
See also member INDEX, but it may be overwhelming.
IV. Changes Log
--------------------------Changes Log---------------------------------
You MUST read each Change description to determine if a Change will
impact your site. All changes have been made in this MXG Library.
Member CHANGES always identifies the actual version and release of
MXG Software that is contained in that library.
The CHANGES selection on our homepage at http://www.MXG.com
is always the most current information on MXG Software status,
and is frequently updated.
Important changes are also posted to the MXG-L ListServer, which is
also described by a selection on the homepage. Please subscribe.
The actual code implementation of some changes in MXG SOURCLIB may be
different than described in the change text (which might have printed
only the critical part of the correction that need be made by users).
Scan each source member named in any impacting change for any comments
at the beginning of the member for additional documentation, since the
documentation of new datasets, variables, validation status, and notes,
are often found in comments in the source members.
_PAGE_ 8
Alphabetical list of important changes in MXG 22.22 after MXG 21.21:
Dataset/
Member Change Description
Many 22.018 Hardcoded "SPIN" DDname now &SPININ,&SPINOUT macros.
Many 22.177 Update to define MACRO _Vdddddd for numeric SMF plus.
Many 22.180 Support for IFA CPU variables for zAAP processors.
Many 22.184 SAS V9.1.2 $VARYING design change protected.
Many 22.192 All INFORMAT $NOTRAN statements were removed.
Many 22.192 Protection for PROC SYNCSORT error with SAS V9.1.2
Some 22.108 Support for SAS V9.1 and V6SEQ without Hot Fix.
ADOC110 22.189 Major updated added 1300 lines of CICS documentation.
ANAL4GB 22.138 Revised to use DCOLLECT to detect large VSAM files.
ANAL94 22.114 IBM VTS Stat Report used SMFTIME, not STARTIME.
ANALALL 22.040 Example now can write all SMF for selected job(s).
ANALFIOE 22.127 Run time improvement if SMF, instead of PDB, input.
ANALFLSH 22.236 New member tracks concurrent flash copies executing.
ANALGART 22.242 Example analysis for Gartner Group requests.
ANALIDMS 22.372 Sample contributed report for IDMS response times.
ANALPATH 22.275 Support for 256 LCUs in the example report.
ANALRMFR 22.062 REPORT=ALL request failed due to HTTP report, fixed.
ANALRMFR 22.181 Enhancements to RMF reporting.
ANALSIZE 22.276 Utility to analyze size of SAS data libraries.
ASMRMFV 22.316 Enhanced support for RMF III VSAM files.
ASMTAPEE 22.038 ML-31 of MXGTMNT corrects GMT, MSC APAR support.
ASMTAPEE 22.366 MXGTMNT ML-32, has MEXIT=ON,XMEMF=ON,ARCV=ON
ASMTAPST 22.366 Prototype test MXGTMNT for STK HSC = please test.
ASUM42DS 22.147 Performance enhancement reduce I/O, CPU using view.
ASUM70PR 22.135 MVS System Name of each LPAR, SMF70STN, added.
ASUM70PR 22.274 Vars TOTSHARE/TOTSHARC kept for orig/current weights.
ASUM70PR 22.293 LP0xxxxx variables now populated with PHYSICAL's data
ASUMCACH 22.248 Protection for zero obs in PDB.TYPE74CA.
ASUMCIMS 22.241 Example summarization of the four IMF datasets.
ASUMHSM 22.282 Variable DATETIME was missing.
ASUMJOBS 22.031 Incorrect stats for jobs that did not purge.
ASUMMIPS 22.354 Interval Capacity by Workload, used MIPS and MSU.
ASUMUOW 22.139 Variables APPLID/USER/LUNAME/TERMINAL incorrect.
ASUMUOW 22.336 MQMACCT/MQMACCTQ data can be added to PDB.ASUMUOW
AUTOEXEC 22.064 LIBNAME DUMMY added to support MONTHASC.
AUTOEXEU 22.102 autoexec.sas file for unix, protects SASAUTOS error.
BLDIMPDB 22.128 ASCII equivalent of JCL for JCLIMSLx execution.
BLDNTPDB 22.111 unix case sensitivity corrections
BLDSMPDB 22.111 unix case sensitivity corrections
BLDSMPDB 22.329 Major enhancement to "PC Job Stream" for SMF on PC.
BUILDPDB 22.022 Variable LOSU_SEC,SRVTCBTM,SRVSRBTM,CPUTOTTM in PDB.
BUILDPDB 22.052 PDB.STEPS can have wrong EXCP,IOTM,TAPExxxx values.
BUILDPDB 22.115 JES3 PDB only; wrong TYPE26J3 used in BUILDPD3.
BUILDPDB 22.140 BY VARIABLES NOT SORTED FOR DATASET WORK.SPIN30TD.
BUILDPDB 22.165 BUILDPDB detects overlapped SMF data previously read.
BUILDPDB 22.320 MULTIDD='Y' obs now combined in PDB.SMFINTRV.
BUILDPDB 22.326 Variable CPUCEPTM now deaccum in PDB.SMFINTRV.
BUILDPDB 22.342 TYPE115/TYPE116 added to BUILDPDB, may cause errors.
BUILDPDB 22.365 BUILDPDB now sets Condition/Return code of zero.
CICINTRV 22.288 Comments show how to create PDB.CICINTRV from SMF.
CONFIGV9 22.108 CRITICAL Hot Fix SN-012437 Required for SAS V9.
CONFIGV9 22.123 SAS V9 on MVS VB INCOMPAT: S2=72 must be S2=0.
DB2STATB 22.045 Negative QBSTGET and other QBSTxxx, 4-bytes wrapped.
ERRORASC 22.239 ASCII platform errors when incorrect SMF download.
EXDB2ACC 22.121 DB2 Parallel CPU time lost, not output in DB2ACCT.
IEFU84 22.136 SMF exit to get Initiator Name and Number for jobs.
IHDRMQM 22.290 New "header" exit for MQ record selection.
IMAC6ESS 22.117 Support for optional ESS segment GEPARMKY=003Bx.
IMAC6ESS 22.161 Support for ESS GEPARMKY 003Bx and 0045x fields.
IMAC6ESS 22.332 Support for GEPARMKY 0036, 0041, 0043, fix 0034x.
IMACICHO 22.169 Hogan optional CICS data member now exists
IMACSHFT 22.058 Temporary variable SHFTTIME now dropped and not kept.
IMACZDAT 22.004 New ZTIME variable available.
JCLMNTHD 22.343 JCL example to build MONTHLY PDB on disk.
JCLRMF 22.143 Example to create "RMF-only" PDB from SMF data.
MONTHASC 22.064 Example "MONTHBLD" for ASCII systems.
MONTHDSK 22.343 "MONTHBLD" program to build MONTHLY PDB on disk.
MXGSASV9 22.126 SAS dsnames must be "W0", w-zero, not w-oh.
MXGSASV9 22.130 Revised MXG JCL example for SAS V9, NLS names, etc.
ONLYINTV 22.326 Example to build only PDB.SMFINTRV/PDB.TYPE30_6.
RMFINTRV 22.050 Variable PCTCPUBY wrong in RMFINTRV when IRD active.
RMFINTRV 22.088 Second VMXGRMFI invocation requires SPINRMIN= arg.
RMFINTRV 22.289 Duplicate observations for first hour.
SYSLOG 22.238 Preliminary support for SYSLOG file.
TESTOTHR 22.279 TYPEVTOC no longer executed in MXG test stream.
TRND.... 22.258 Symbolics &TRENDINP,&TRENDNEW,&TRENDOLD added.
TYPE102 22.074 T102S125 variables QW0125SN/PC/PL/PN/TS missing.
TYPE102 22.234 Support for IFCIDs 140-145 SQL text that was blank.
TYPE102 22.294 Support for APAR PQ73385,PQ91101 for IFCIDs 217, 225
TYPE102 22.294 Support for APAR PQ87848 for IFCID 173
TYPE102C 22.104 Support for Candle Omegamon II for DB2 IFCID Trace
TYPE102G 22.109 TYPE102G to read DB2 Trace written to GTF didn't.
TYPE110 22.059 CICS/TS 2.3 Pool Variables corrected in CICDSPOO.
TYPE110 22.094 Support for CICS/TS 2.3 with no EXCLUDEd fields.
TYPE110 22.359 Support for CICS/TS 3.1 with no EXCLUDEd fields.
TYPE117 22.029 Support for SMF 117 WBIMB WebSphere Business Integrat
TYPE119 22.073 TYP11910 variables UCINxxxx,UCOUxxxx corrected.
TYPE119 22.146 TYP119nn datasets had GMT time zone, now have local.
TYPE120 22.014 WebSphere SMF 120s had GMT for many timestamps.
TYPE30 22.021 Job delays SMF30HQT/JQT/RQT/SQT revisions.
TYPE30 22.022 Variable SRVTCBTM,SRVSRBTM,CPUTOTTM created in TYPE30
TYPE30 22.221 Support for z/OS 1.6 and zAAP/IFA Processors.
TYPE30 22.265 Support for APAR OA09118, adds CPUCOEFF to SMF 30s.
TYPE30 22.272 Support for zAAP IFA engines.
TYPE30 22.375 IBM Error in CPUIFATM, MXG Error in SRVTCBTM.
TYPE30MR 22.345 TYPE30MR dataset restructured and corrected.
TYPE42 22.254 False ERROR:INVALID TYPE 42 SUBTYPE 5 corrected.
TYPE42DS 22.055 TYPE42DS variable AVGIOQMX small negative value.
TYPE57 22.057 Support for optional ESS fields.
TYPE6 22.153 SUBSYS='TCP' or 'TCPE' for Printway SMF 6 records.
TYPE6 22.298 SMF 6 STOPOVER on PrintWay section - missing @;
TYPE6 22.302 Support for VPS V1 R8.0 VPS-FAX data
TYPE6 22.309 Final correction for type 6 INPUT EXCEEDED errors.
TYPE6 22.321 Support for second format type 6 PrintWay record.
TYPE70 22.050 Variable PCTCPUBY wrong in TYPE70 when IRD is active.
TYPE70 22.087 Non-PR/SM, IORATE/PCTTPI variables too low.
TYPE70 22.116 Variables SMF70NSI/NSA/NSW incorrectly divided.
TYPE70 22.134 Percent when each engine online PCTONLN0-PCTONLNX.
TYPE70 22.325 "Short CP" variable SHORTCPS created in TYPE70.
TYPE7072 22.063 Calculation of variable PCTDLTDQ in TYPE72GO revised.
TYPE7072 22.072 TYPE72GO with R723CWMN GT 0, Periods not output.
TYPE7072 22.137 Support for z890 CPUTYPE 2086, OS/390-INCOMPAT.
TYPE7072 22.152 Support for IFA Processors, APAR OA05731.
TYPE7072 22.221 Support for z/OS 1.6 and zAAP/IFA Processors.
TYPE7072 22.260 Support for z/OS 1.6 WITH IFA engines.
TYPE7072 22.272 Support for zAAP IFA engines.
TYPE7072 22.307 Negative CPU values for IRD - Required CHANGE.
TYPE7072 22.340 Revision to support for varying IFAs online/offline.
TYPE7072 22.349 Negative PCTMVSBY/CPUMVSTM/SHORTCPs, SMF70CNF bit 6.
TYPE70PR 22.011 PCTCPUBY for IRD was incorrect.
TYPE70PR 22.150 LPAR names for LPARs 16-32 now 8 bytes, were only 1.
TYPE71 22.269 22.07-22.10 only. LPAxxxx variables missing values.
TYPE74 22.075 Support for 1024 structures in Coupling Facility.
TYPE74 22.141 Support for RMF 74 subtype 8 ESS Link Stats record.
TYPE74 22.334 Support for APAR OA06476 type 74 subtype 5 and 8.
TYPE78 22.091 Variable PCTALLBY, TYPE78CU always missing, correct.
TYPE80A 22.185 Invalid SMF 80 Extended Relocate Section protected.
TYPE80A 22.286 Numerous enhancements, multiple RACF segments, etc.
TYPE82 22.005 Support for Crypto subtypes 14 thru 19.
TYPE94 22.268 Support for VTS R7.3 additional statistics.
TYPEAIX 22.083 Support for AIX PTX new objects.
TYPEBETA 22.250 Support for BETA93 Release 3.5 subtypes 0-5.
TYPECIMS 22.314 Support for Mainview IMS IMF 4.1.00 (NO CHANGES!).
TYPECMF 22.266 Support for CMF Version 5504 User SMF (INCOMPAT).
TYPEDB2 22.042 DB2 Stats records not written in subtype order.
TYPEDB2 22.084 Large QBSTGET in DB2STATB due to DB2 restart fixed.
TYPEDB2 22.090 MXG 22.02-22.03 only. QWHSSTCK 1960 date in DB2ACCT.
TYPEDB2 22.121 DB2 Parallel CPU time lost, not output in DB2ACCT.
TYPEDB2 22.124 MXG 22.04-05, QWHSSTCK missing in SMF 102 trace data.
TYPEEDGS 22.112 INPUT STATEMENT EXCEEDED with MVRECLEV '02'x.
TYPEENDV 22.032 Support for Endeavor Release 4.0, INCOMPATIBLE.
TYPEHIOM 22.331 Support for hIOmon File I/O Performance Monitor.
TYPEHMF 22.168 Support for HMF V2.7 new subtypes, compatible.
TYPEHPDM 22.166 Support for STK ExHPDM user SMF record.
TYPEHURN 22.006 Support for Huron/Object Star additional subtypes.
TYPEHURN 22.304 Support for ObjectStar subtype 45 Page Sweep.
TYPEIBSM 22.079 Support for IBM Session Manager user SMF record.
TYPEIMS7 22.199 Major revision to IMS0708 dataset, all events output.
TYPEIMSA 22.113 ASCII execution only, APPLID not readable.
TYPEIPAC 22.125 Support for IPAC subtype 5 IPAC05 corrections.
TYPEMVCI 22.296 Reading CMRDETL on ASCII platform - BLKSIZE error
TYPENDM 22.133 Support for several additional NDM-CDI subtypes.
TYPENETM 22.037 Support for NetMaster 5000x subtype.
TYPENETM 22.131 TYPENSPY and TYPENETM combined, only one SMF record.
TYPENSPY 22.131 TYPENSPY and TYPENETM combined, only one SMF record.
TYPENSPY 22.312 Support for NetSpy Version 7.0 (COMPATIBLE).
TYPENTSM 22.082 Variable MEMINBOX in NTCONFIG was wrong.
TYPENTSM 22.190 Support for NTSMF MicroStrategy Server objects.
TYPENTSM 22.193 Support for NTSMF Exchange/Outlook/DTS CPU objects.
TYPENTSM 22.246 Support for NTSMF Release 2.4.7 (COMPATIBLE).
TYPEOMVT 22.186 Omegamon/VTAM V520 IRNUM 29 Divide by zero corrected.
TYPEQACS 22.095 Support for OS/400 5.2 QAPMMIOP record new fields.
TYPEQACS 22.311 Support for OS/400 5.3.0 CONF/DISK/POLL/JOBL data.
TYPEQACS 22.371 Support for OS/400 5.3.0.
TYPESASU 22.163 Cannot use NODUP option with TYPESASU SAS user SMF.
TYPESMSX 22.030 Support for DF/SMS Storage Class Exit User SMF record
TYPETDSL 22.249 Support for TDSLink product's user SMF record.
TYPETMDB 22.235 Support for ASG/Landmark TMON for DB2 V4.0 (COMPAT)
TYPETMNT 22.012 RACFUSER/RACFTERM reversed, GMT times, INPUT EXCEEDED
TYPETMNT 22.237 DDNAME/STEPNR missing in PDB.ASUMTMNT corrected.
TYPETMO2 22.191 Support for ASG/TMON TCE for CICS/ESA 2.3, COMPATIBLE
TYPETNG 22.081 Protection for '9E'x for Left Square Bracket.
TYPETNG 22.085 Support for NT objects SESSION and USER in TNG cubes.
TYPETNG 22.160 REGION reduced for JCLTEST8 TESTOTHR due to TYPETNG.
TYPETNG 22.170 Support for TNG Windows Server 2003 new objects+fix.
TYPETNG 22.291 Support TNG NT Platforms NTW400I, WNS502I, ZPP501I.
TYPETNG 22.339 Major TNG enhancement - array sizes dynamically set.
TYPETPF 22.374 Support for MQ Series data from TPF Operating System.
TYPETPMX 22.008 (Final?) revisions to internal Thruput array names.
TYPETPMX 22.060 Restructure TPM support, multiple datasets created.
TYPETPMX 22.077 Support for alternative multiple-ACCT field TPM data.
TYPETPMX 22.142 INNODE, JBSBIND, JVLVOL, REQCLA varnames supported.
TYPEVIOP 22.101 Support new VIO/PLUS (Performance Enhancer) subtypes.
TYPEVMXA 22.240 Support for z/VM 4.4, INCOMPAT.
TYPEVMXA 22.369 Support for z/VM 4.4 and z/VM 5.1 additions.
TYPEXAM 22.245 Support for XAMAP Release 3.4 (INCOMPATIBLE).
UTILBLDP 22.149 Enhancement supports subtype selection in ZEROOBS.
UTILBLDP 22.277 New MACFILEX argument to insert SAS code.
UTILBLDP 22.301 Use of ZEROOBS= parameter could fail.
UTILCONT 22.356 ABEND with SAS V9 when PDB=WORK requested fixed.
UTILEXCL 22.068 Support for optional RMI data in CICSTRAN.
UTILEXCL 22.313 Support for APPLNAME,CANDEXNM,CANDEXTY CICS segments.
UTILEXCL 22.317 The final @; was not created in IMACEXCL.
UTILEXCL 22.347 New CICS/TS 3.1 WBREPRDL/WBREPWDL/PGCRECCT supported.
UTILS2ER 22.123 Utility to detect errors with S2=0 in your programs.
VGETENG 22.148 Enhancement to get Engine and Device Type of LIBNAME
VMACDB2H 22.196 Support for extended length DB2 id variables.
VMACDB2H 22.270 22.08-22.10 only. DB2 V8.1 INPUT STATEMENT EXCEEDED.
VMACSMF 22.271 _LOGSMF revised for TYPENDML.
VMACSMF 22.300 Use of FTP access to read SMF MVS-to-MVS failed.
VMXGINIT 22.096 Macro variables &MACINTV and &MAC30DD created.
VMXGPRAL 22.287 Enhancement to use PROC FREQ, example for 102 "who".
VMXGRMFI 22.017 BUILDPDB run time elongation, if output to tape.
Inverse chronological list of all Changes:
NEXTCHANGE: Version 22.
====== Changes thru 22.378 were in MXG 22.22 dated Feb 1, 2005=========
Change 22.378 Type 74 subtype 8 (ESS 2105 PPRC RMD data) with nulls for
VMAC74 R748CFDT (DATE WHEN FIRST RECORD WRITTEN) caused R748CFTM
Jan 30, 2005 to be midnight on 1JAN1960. Now, R748CFTM is set missing
when R748CFDT is not populated.
Thanks to Shirley Fung, Hong Kong & Shanghai Bank, HONG KONG.
Change 22.377 This elegant tweak discovered by this user to my enhanced
TYPETNG dynamic array sizing uses even less virtual storage when
VMACTNG you have multiple TNG cubes from different systems. My
Jan 29, 2005 enhancement in Change 22.339 kept all instances from all
systems to set the array sizes, but by changing counting
from BY PLATFORM OBJECT to BY PLATFORM SYSTEM OBJECT, the
true count of unique instances needed for the array size
is much smaller; for example, NT042I dropped from 1008 to
489, and REGION dropped from 266MB to only 149MB.
-TYPETNG now prints the INSTREAM file on the log after it
was created, useful for debugging.
Thanks to Peter Krijger, ANZ National Bank Limited, NEW ZEALAND.
Change 22.376 -MXG 22.22 is the last to be tested under SAS V6 on MVS,
UTILXRF1 because my MVS QA site is removing Version 6, but the
UTILXRF2 final tests discovered two variables whose names were
Jan 29, 2005 longer than 8 bytes. While SAS V8+ permits longer names,
Jan 30, 2005 it is my intention to NEVER use them in MXG, not only as
I find them user-unfriendly, but also because all of my
ADOC/DOC members are designed for 8-byte variable names.
But this last test was a great wakeup, so I have enhanced
my Cross Reference utility, run during my Alpha QA tests,
to detect long variable names, and also, for similar
reasons, detect if I have created labels longer than 40.
-Dataset Labels were missing from many datasets in DOCVER,
even though the MXG code had a LABEL= dataset option in
the VMACxxxx members. Dataset labels are propagated from
the input to the output dataset if PROC COPY or PROC SORT
is used (even if the dataset name is changed in SORT),
but creating a new dataset from an old dataset does not
propagate the dataset label. Most MXG _Sdddddd dataset
macros use PROC SORT, and test data is used to determine
the correct BY list to remove duplicates, but when there
is no test data, DATA _Ldddddd; _Wdddddd; is used to
copy the "Work" dataset to the "PDB" output library, and
it was those instances that had missing labels in DOCVER.
While getting test data and revising the _Sdddddd to SORT
and remove duplicates is the eventual solution, to get
the dataset labels for MXG 22.22, I revised CROSSREF to
copy the _Wdddddd datasets to one library, and to copy
the _Ldddddd datasets to a second library, and to use the
label from the _Wdddddd dataset if the _Ldddddd copy had
a blank label. I could not just use the _Wdddddd data,
because some of the _Sdddddd macros add new variables;
in particular, when adjacent interval records have to be
deaccumulated, the _Sdddddd logic creates the DELTATM.
-There are still a few datasets that don't have labels.
Thanks to Jake M. Drew, MBNA, USA.
Change 22.375 MXG variable SRVTCBTM, a CPU TCB time that is calculated
VMAC30 from CPU TCB Service Units was wrong if the task executed
Jan 29, 2005 on a zAAP (IFA) engine, because the MXG calculation used
CPUUNITS before IFAUNITS had been removed from CPUUNITS.
-Now, the order of calculation is correct.
- SRVTCBTM was added by Change 22.022 to the TYPE30xx
datasets so that it could be compared with CPUTCBTM.
Cheryl thought that using Service Units might provide
higher resolution and less truncation for small jobs
due to the .01 second precision of CPUTCBTM, but my
analysis had not shown a significant difference.
- Change 22.221 documented that the "raw" CPUUNITS in
SMF 30 records include the IFA Service Units, but as
IBM provides the CPUIFATM and the coefficients, that
MXG created a separate variable, IFAUNITS, and those
IFA Service Units are removed from CPUUNITS.
-However, new analysis of SRVTCBTM in type 30 records for
2086 (z/890s) for tasks that use IFAs shows an error in
IBM's creation of CPUIFATM: the calculated SRVTCBTM is
significantly larger than CPUTCBTM when IFAs are used:
IFA? SRVCLASS CPUTCBTM SRVTCBTM Diff CPUIFATM
Yes STCHI 31.14 90.58 +59 80
Yes STCMED 129.29 333.35 +204 211
Yes STCHI 4057.62 4517.82 +460 689
Yes STCMED 23.37 118.91 +95 13
No STCHI 1253.96 1248.32 -5
No STCHI 242.15 241.79 0
No STCMED 266.03 265.80 0
IBM is fully aware of this problem and will undoubtedly
correct it in the near future.
Change 22.374 Support for MQ Series data from TPF creates two datasets
EXTPFMQC dddddd dataset description
EXTPFMQQ TPFMQC TPFMQC MQ SERIES CHANNEL INFORMATION
IMACTPF TPFMQQ TPFMQQ MQ SERIES QUEUE INFORMATION
VMACTPF
VMXGINIT
Jan 28, 2005
Change 22.373 Change 22.055 set AVGIOQMS to zero if a negative value
VMAC42 was calculated, due to clock differences, but that change
Jan 28, 2005 only applied to AVGIOQMS for TYPE42SR dataset. Now, the
other two datasets, TYPE42VT and TYPE42DS are protected.
Thanks to Karl Lasecki, Chemical Abstracts Service, USA.
Change 22.372 Sample contributed report for IDMS response times, using
ANALIDMS the PDB.IDMSTAS dataset built by TYPEIDMS from the IDMS-R
Jan 28, 2005 SMF record. The report also shows how you can send any
SAS report to your company's web site.
Thanks to Pat Curren, SuperValu Inc, USA.
Change 22.371 Support for OS/400 5.3.0. New data in QAPMJOBM, QAPMSYSC
EXQAPDPS QAPMSYST and QAPMIODn, and new QAPMSYS replaces QAPMSYSL.
EXQAPJSU Change 22.311 supported new data in QAPMCONF, QAPMDISK,
IMACQACS QAPMPOLL and QAPMJOBL. As always with AS/400 support, if
JCLTEST8 you are running MXG on z/OS, you must make the LRECL of
JCLTEST9 the MVS dataset into which the QAPM file is sent to be
QASAS the same as the LRECL in the table in VMACQACS for that
VMACQACS dataset; on ASCII, it's the LRECL in your FILENAME that
VMXGINIT must match.
Jan 28, 2005 -The new QAPMSYS with 567 variables replaces QAPMSYSL, but
none of the old JSxxxx variables from QAPMSYSL exist in
QAPMSYS. QAPMSYS is the "long" (LRECL=3344) system file,
and you will need to add _TQAPSYS and //QAPMSYS DD to
create the new dataset.
-The new QAPMJSUM dataset is created with Job Statistics
Performance Data.
-The new QAPMDPS dataset is created with Data Port Service
Performance Data.
-Variables added to QAPMSYSC:
SCTACT - The number of CPUs, so variable PCTCPUBY is now
calculated as 100*SUM(OF SCPU01-SCPU32)/(SCTACT*INTSEC).
-Variables added to QAPMJOBM:
JBASH JBASHA JBBFA JBBFW JBBTA JBBTW
JBCOP JBCOS JBDOP JBDOS JBFSH JBFSHA
JBNSJE JBPGA JBPGD JBPJE JBSJD JBTNW
JBTWT JBUJD JBXRBR JBXRBW JBXRFS JBXRRR
JBXRRW JCUSR
-Variables added to QAPMSYST:
SYBTAC SYBTAP SYBTAPC SYBTAPD SYBTAPP SYCTA
SYIFTA SYIFTE SYIFUS SYJOC1 SYJOC2 SYJOC3
SYJOER SYJOES SYJOIB SYJOS1 SYJOS2 SYJOS3
SYLPTB SYNPLA SYNPLU SYNUAL SYNUTC SYSDFAL
SYSDFRL SYSDNFE SYSDNFO SYSDNST SYSDPFD
SYSDPFF SYSDTET SYSPTU SYUTA
Thanks to Clayton Buck, Unigroup, USA.
Change 22.370 The dataset name in the comments in the code that invokes
TYPEHO15 the _Edddddd macro was incorrect in a number of members,
VMAC84 but in some cases, it wasn't the name in comments, but it
VMACARB was the _Edddddd that was wrong, which caused those data
VMACCMFV to be output to the wrong dataset. Fortunately, none of
VMACTMDB these are "mainstream" datasets, so that error was never
VMACVITA noticed. The MXG QA stream now validates the comment and
Jan 27, 2005 the _Edddddd macro are consistent.
invoke it. This change corrects the dataset name typos
and makes the macro use more consistent within MXG code.
TYPEHO15 VMAC84 VMACARB VMACCMFV VMACTMDB VMACVITA
Thanks to Jake M. Drew, MBNA, USA.
Change 22.369 Support for new fields added to z/VM 4.4 and z/VM 5.1;
EXIODQDS INCOMPATIBLE only because MXG did not properly use the
EXMTRQDC offsets and lengths for the SYTCUG and SYTCUP datasets.
FORMATS -Added prior to z/VM 4.4, but not in MXG until now:
IMACVMXA SYTSYG - CPUCAPAB CPUCFGCT CPUCOUNT CPURESVD
VMACVMXA CPUSTNBY CTNABORT CTNDONE CTNNOTEL VL3CAF
VMXGINIT VL3CFGCT VL3COUNT VL3CPNAM VL3DBCT VL3MNAME
Jan 26, 2005 VL3RESVD VL3STNBY
Jan 27, 2005 USELOF - ASCDEFSZ VMDCTPVG VMDMVB2G VMDMXSHR VMDTHRCT
USEACT - ASCDEFSZ IPQFO IPQRQLO IPQRQHI IPQEFLO
IPQEFHI IPQDSKIP VMDCTPVG VMDMVB2G
-Added in z/VM 4.4:
IODDEV - SCGCOUNT SCGSSCH SCMDBTIM SCMIRTIM
IODMOF - SCGCOUNT SCGSSCH SCMDBTIM SCMIRTIM
MTRMEM - CALSCMAX HCPMMO HCPSYS RSAGSTOR SYSGTORS
SYSSCMEX SYSTRCPC
MTRSYS - CPUCFGCT CPUCHAR CPUCOUNT CPUDEDCT CPURESVD
CPUSHARD CPUSTNBY LPARCAF LPARNAME LPNUMBER
SYSMMODL SYSMPOM SYSMSEQC SYSMTYPE
STOASP - SCGSSCH
STOASS - SCMSSCH (expanded to 4 bytes)
SYTCUG - CPUCFGCT CPUCHAR CPUCOUNT CPUDEDCT CPURESVD
CPUSHARD CPUSTNBY LPARCAF LPARNAME LPNUMBER
SYTEPM - CSCCMCDP CSCCMCDU CSCCMCMP CSCCMCMS ECMMDUS
ECMMDUSC ECMMSNT ECMMSNTC ECMMUATS ECMMURB
ECMMURBC
SYTRSG - TCMMNBLW TCMMNABV RSA2GDCT SYSSCGCT
SYTSCG - CALTLKCT CALTLKTM
-Added in z/VM 5.1:
IODDEV - EDEVTYPE RDEVDEV
IODDTD - RDEVDEV
IODVOF - RDEVDEV
IODVON - EDEVFCP1-EDEVFCP8 EDEVLUN1-EDEVLUN8
EDEVTYPE EDEVWPN1-EDEVWPN8 RDCOBRCO RDCRCUC
RDEVDEVP RDEVPVFG RDEVSER RDEVSID RDEVSIDP
RDEVTYPE
MTRDEV - EDEVFCP1-EDEVFCP8 EDEVLUN1-EDEVLUN8
EDEVWPN1-EDEVWPN8 EDEVTYPE RDEVDEVP RDEVPVFG
RDEVSIDP
MTRPAG - RDEVDEV
MTRSYS - CPUCAPAB SCPCAPAB
STOASS - RDEVDEV
STOATC - RDEVDEV
SYTCUP - LCXPUPID
SYTXSG - TCMFSHVM TCMRDCT TCMPIN4K
USELOF - VEBALERT VEBHDWAI VEBSVSCT VEBTPIAI
VEBTVSCT VEBVIRAI
USEACT - VEBALERT VEBHDWAI VEBSVSCT VEBTPIAI
VEBTVSCT VEBVIRAI
USEATE - VEBALERT VEBHDWAI VEBSVSCT VEBTPIAI
VEBTVSCT VEBVIRAI
SYTSYG - SCPCAPAB
-New Datasets created in z/VM 5.1:
MTRQDC - QDIO DEVICE CONFIGURATION
IODQDS - QDIO ACTIVITY
Other new records will be supported only if you
have a need and can send test data for them:
MTRCCC, IODVSM, IODVSR, IODSZI, IODQDA, IODQDD.
Thanks to Kris Ferrier, State of Washington Dept Info Services, USA.
Thanks to Alexandre Dorsimont, SCNH, FRANCE.
Change 22.368 The "TOTALS" record was still output in XAMSYT, because
EXXAMSYT the test in EXXAMSYT was spelled 'TOTAL' but the actual
Jan 26, 2005 LPAR name test needed to be 'TOTALS:'.
Thanks to Joachim Mayr, Amadeus, GERMANY.
Change 22.367 MXG 22.13-22.22 only. Change 22.320 combined MULTIDD obs
BUILD005 from TYPE30_V into one PDB.SMFINTRV obs, but if you used
BUIL3005 IMACINTV to only output some of the TYPE30_V obs, then
Jan 25, 2005 PDB.SMFINTRV had more obs than were in TYPE30_V. All DDs
for all tape devices from all interval records are output
in TYPE30TD, independent of the TYPE30_V selections. The
TYPE30TD then becomes TYPE30VT, which is merged with the
INTVS (which is a stripped down TYPE30_V) and INT30VSIO
(the sum of all I/Os for the interval records), but now,
the merge is only OUTPUT if the obs is in INTVS.
Thanks to Ron Lundy, AHOLD, USA.
====== Changes thru 22.366 were in MXG 22.22 dated Jan 22, 2005=========
Change 22.366 The MXGTMNT Tape Mount Event and Sampling Monitor ML-32
ASMTAPEE is in member ASMTAPEE, with these enhancements:
ASMTAPST -The ML-32 revisions are primarily for IBM Tape Devices,
ASMTAPSK because it defaults to use the IBM Volume Mount Exit, and
Jan 22, 2005 STK doesn't support that exit. Thus these defaults in
Jan 27, 2005 the ASMTAPEE member will ONLY work with IBM devices:
MXIT=ON, use the IBM Volume Mount Exit to capture all
Mount Events (exit-driven, not sampling for mounts),
which also gets job-level fields for the Mount Event
so Cross Memory Service calls are not needed for the
mount record.
XMEMF=ON, use Cross Memory Services to get job-level
fields for the Allocation Event, which are detected
by sampling.
ARCV=ON, enable detection of Allocation Recovery thru
exit, to write a separate subtype for each delay
because a tape device could not be allocated. This
subtype creates the (new) PDB.TMNTTARC dataset.
-However, you can use ML-32 with STK devices: you have to
set MXIT OFF, so that the old sampling monitor is used to
detect mount events, even though that means that many of
your fast VTS mounts will not be captured. You also need
to leave XMEMF ON, so that Cross Memory Services is used
to get the job-level information for both mount events
and allocate events, even though that may increase the
CPU time used by the MXGTMNT monitor (because there is no
way to know that an address space is no longer present,
except to issue the XMEM call, and then go thru the very
CPU-expensive recovery mechanism when XMEM fails to find
the job, because it had already ended).
-And if you have both IBM and STK devices, you will need
to assemble two different MXGTMNT programs and run them
in two Started Tasks, and use the EXCLUDE LIST DD to tell
the IBM instance to exclude the STK devices by DEVNR, and
to tell the STK instance to exclude the IBM devices.
You can create the same SMF record for both monitors, or
you could set different SMF IDs, and then you would use
MACRO _IDTMNT nnn OR ID= mmm % in the IMACKEEP member
to tell MXG to process both IDs as MXGTMNT records.
-STK devices are allocated by STK's HSC product, which
does not call the IBM volume mount exit; we have written
a test program for the HSC SLSUX01 exit, but have not had
an STK site run the program, which will determine if we
can use that exit for STK devices (and thus eliminate the
sampling and missed mounts). Here's what we need:
ASMTAPST is a test exit for potential STK support. The
program is a wrapper for the site's current SLSUX01 HSC
exit. There is a DD in the linkedit step, HSCLOAD, that
points to the location of the site's current SLSUX01
exit. The output of the linkedit is a combined SLSUX01
exit that the site will use, instead of their current
SLSUX01 exit code. The HSCLOAD and SYSLMOD DDs must not
point to the same library, or the site's SLSUX01 will be
replaced. Once the ASM/LKED are done, the site will
have to define the new MXG version of that exit to HSC.
The logic is as follows:
-HSC calls the MXG SLSUX01.
-MXG SLSUX01 executes the site's local SLSUX01 as-is,
taking whatever actions, were coded by the site.
-Control is returned to MXG SLSUX01 where the code
will do some data gathering and issue WTOs to the job
log, reporting what was discovered, from which we can
tell if the HSC exit can be used for STK devices.
-MXG SLSUX01 returns to HSC.
Once you've installed our exit, run some jobs that
cause both VTS and non-VTS tape mounts, and send us the
MXGTMNT job log, which will show us if all mounts do
actually go through the exit, and what environment
exists at the time the exit is taken. From that info,
we may be able to figure out how to handle the STK
devices. Unfortunately, we have to depend on you to
run these tests, as STK has been unwilling to run these
tests for us on their systems.
- Just discovered: STK no longer provides a dummy exit
SLSUX01 in HSC 6.0! Member ASMTAPSK is the variant
of ASMTAPST that doesn't call that user exit.
-ML-32 corrects ML-31, in which setting MEXIT bypassed the
XMEMF call in the Allocation Monitor (causing job-level
fields to be missing in the allocation records). Now,
XMEMF on/off is independent of the MEXIT on/of setting.
-The TMNT004I message is updated before it is issued at
MXGTMNT initialization, to show any user modifications.
-STEPNAME is now correctly populated, and PROCSTEP name
has been added to TYPETMNT record for mounts.
-Using MXIT on IBM systems is only supported on z/OS. We
have seen, on OS/390 systems, that second and subsequent
mounts for a job-step are not captured by MXIT, and also
mounts from STCs (like DFHSM and JES2) are also missed.
This is just not worth fixing for those archaic systems.
-There is one know error in ML-31/ML-32; the Mount Start
time is taken as the entry time into the Volume Mount
Exit, which now appears to be the same as the Allocation
Allocation Start time, and for most mounts that is very
close to the IEF233I Mount Message timestamp, and hence
not a problem. But one site experienced very significant
delays (30 minutes!, due to hardware errors) between the
TMNTTIME time and the IEF233I time, so "asmguy@mxg.com"
is now working on a revision, ML-33, but it won't be done
and tested in time for MXG 22.22; please email a request
to support@mxg.com when you read this text, asking for
ML-33, and we'll email the revised ASMTAPEE when ready.
Change 22.365 BUILDPDB now sets Condition/Return Code of zero under V9!
BUILD005 SAS V9 tightened when Condition Codes were returned, and
VMAC26J2 the WARNING: LENGTH OF CHARACTER VARIABLE HAS BEEN SET
Jan 21, 2005 returned a CC=0 with SAS Version 8.2, but CC=4 with V9,
because JES3 JOBCLASS is $8, VMAC30 reads JES2 and JES3
30s, but VMAC26J2 for JES2 26s had JOBCLASS of $1, and
VMAC26J2 was located first in BUILDPDB to set $1 length.
This design increased JOBCLASS length in VMAC26J2 to $8,
eliminating the WARNING in the SMF-reading step where
VMAC30 and VMAC26J2 coexist, and new LENGTH JOBCLASS $1
statements were inserted in BUILD005 to keep only $1 for
JES2 JOBCLASS in the PDB and SPIN datasets, so that old
and new datasets built before and after this redesign
will still have a one byte JES2 JOBCLASS variable.
-TYPE30 used by itself always had JOBCLASS $8, so that did
not change; only if you use TYPE26J2 by itself would you
notice that JOBCLASS's length is now $8 instead of $1.
But with MXG's COMPRESS=YES default, you shouldn't see
any increase in the size 'cause those 7 blank bytes will
get compressed real good!
-The SAS change was noted in MXG Newsletter FORTY-FOUR,
but that note was revised, citing this MXG change.
-This should make migration from V8 to V9 even easier.
Change 22.364 Variables BLKPAGE, BLKSAUIN, and NRBLKPAGE in TYPE71 are
VMAC71 rates (per second, like all paging activity rates), but
Jan 21, 2005 their labels did not so indicate; now, they do.
Thanks to David Kaplan, DTC, USA.
Change 22.363 -The JES3 Workload Management Section variables (added to
BUILD005 SMF 26 in OS/390 R2.4; already in TYPE26J2 and PDB.JOBS
BUIL3005 for JES2, are now kept in JE3's TYPE26J3 and PDB.JOBS.
VMAC26J3 JOBMODE0='RAN*IN*MODE=WLM'
Jan 21, 2005 JOBMODE1='RAN*F*J=JOB,RUN'
SMF26WCL='SERVICE*CLASS AT*EXECUTION'
SMF26WIN='JOB*INDICATORS'
SMF26WJC='JOB*CLASS'
SMF26WOC='ORIGINAL*SERVICE*CLASS'
SMF26WSE='SCHEDULING*ENVIRONMENT'
-Variable SMF26WSE, the Scheduling Environment name, was
only previously kept in JES2's PDB.JOBS, but this change
adds SMF26WSE to PDB.STEPS for both JES2 and JES3, as it
is often useful examine STEPS-level data (i.e., PROGRAM)
and the Scheduling Environment name that caused that PGM
to execute on this SYSTEM.
Thanks to Julian Smailes, Experian, ENGLAND.
Change 22.362 Cosmetic. The include of VMACSMF in these products was
Several not needed, as they read different INFILES. No error,
Jan 21, 2005 but it could have been confusing. Members changed:
TYPEASXT, TYPECMFV, TYPEEAGL, TYPEIDML, TYPEMVCI,
TYPEOMDB, TYPEUNIA, TYPEUNIK, and TYPEVITA and TYPS's.
Thanks to Freddie Arie, TXU, USA.
Change 22.361 Variable SYSTEM was blank in PDB.ASUMUOW if there was no
VMXGUOW DB2ACCT observation for that unit of work. The value of
Jan 20, 2005 SYSTEM comes from the last of the two input datasets
(CICS,DB2) that contributed to the PDB.ASUMUOW obs, so
if there are DB2 obs, the SYSTEM of the last DB2ACCT
observation will be the source of the value of SYSTEM.
Thanks to Ron Root, Texas Comptroller of Public Accounts, USA.
Change 22.360 On z/890s with z/OS 1.4 but with SMF70LAC=0, values in
FORMATS the variables CECSUSEC, CPCNRCPU, CPUMSU were missing
VMXGRMFI because the $MG070CP format's table for CPUTYPE='2086'x
Jan 19, 2005 was wrong. When SMF70LAC GT 0, those variables are in
the SMF 70, but the $MG070CP table has to be used when
SMF70LAC=0. MXG ERROR: CPUTYPE WAS NOT FOUND IN TABLE,
CECSUSEC IS MISSING was printed (obscurely) on the SAS
log by RMFINTRV code; this change enhanced that message
in case it again occurs. Changes 21.299 and 20.168 noted
that SMF70LAC was zero on basic (non-LPAR) machines, or
on LPAR'd machines if APAR OW55509 was not installed and
the LPAR had no defined capacity limit. This system was
not running in 64-bit mode, which may also be required
for SMF70LAC to be non-zero.
Thanks to Diane Parker, AmerisourceBergen Corp, USA.
Change 22.359 Full support for CICS/TS 3.1 was only in UTILEXCL in
VMAC110 22.13 as the three new fields (328,341,342) during the
Jan 18, 2005 ESP were not added to VMAC110 INPUT for SMFPSRVR=64.0
until today. MXG 22.13 tested MCTSSDCN=283, but now
MCTSSDCN=286 and MCTSSDRL=1848 is tested for
non-excluded-field records. Using UTILEXCL to create
IMACEXCL has always been the recommended way to minimize
the size of your CICS 110s, and even if there are added
fields, since UTILEXCL read your CICS dictionary records,
it will generate code to skip over any unrecognized
fields (and will tell you on the log it found unknown
fields, so they can be added to the MXG UTILEXCL and
VMAC110 members.
Thanks to Roland Schiradin, Alte-Leipziger, GERMANY.
Thanks to Lambros Theodorides, Alte-Leipziger, GERMANY.
Change 22.358 CALTODON, the datetime stamp when user Logged on, was not
VMACVMXA converted from GMT to local time, but now it is.
Jan 18, 2005
Thanks to Xiaobo Zhang, ISO, USA.
Change 22.357 UTILBLDP failed with USERADD=118 because VMACTCP defines
UTILBLDP the macros for SMF 118; originally, the TCP record was a
Jan 18, 2005 User SMF record, and only later was given ID=118. Now,
UTILBLDP is coded for this inconsistency and will work if
use USERADD=118 or USERADD=TCP.
Thanks to Keith McWhorter, Georgia Technology Authority, USA.
Change 22.356 UTILCONT reports SAS Data Set sized in MegaBytes; as is
UTILCONT documented in its comments, it can cause log messages of:
Jan 18, 2005 WARNING: LIBRARY xxx WAS ALREADY ALLOCATED
ERROR: LIBRARY xxx MAY NOT BE REASSIGNED
ERROR: DISP=SHR CONFLICTS ASSIGNED
ERROR: LIBNAME XXX IS NOT ASSIGNED
but with MXG default options, these messages to NOT cause
a condition code, nor does the job fail, and the reports
are produced. However, if you have set the SAS Option to
ERRORCHECK=STRICT (default is NORMAL), then errors like
the above in LIBNAME statements do cause ERRORABEND to be
invoked, and the step fails with USER ABEND 999.
An ABEND did occur with %UTILCONT(PDB=WORK); due to the
changes made in Change 22.175, when MXG 22.12 was tested.
This change to UTILCONT detects that the LIBNAME of WORK
was requested and does not reassign it, avoiding those
messages for the WORK library, and the ABEND.
Thanks to Hugh Lapham, Royal Canadian Mounted Police, CANADA.
Change 22.355 EDGRKEXT was wrong; the first +1 did not exist. New
VMACEDGR variables RKRELIXD RKRELSI RKRETAND RKRETNCD RKRETNXD
Jan 17, 2005 are now output.
Thanks to Reinhard Nitsch, Provinzial Vershicherungen, GERMANY.
Change 22.354 Capacity used for each interval for each workload, for
ASUMMIPS each service and reporting class from PDB.TYPE72GO, and
Jan 16, 2005 for each job from PDB.SMFINTRV, with MIPSUSED, MSUUSED,
Jan 22, 2005 and PCTUSED variables, is created in two output datasets
named PDB.RMFMSUSE and PDB.SMFMSUSE by the ASUMMIPS code.
I think MSU is a much better capacity measure than MIPS,
but I used "MIPS" to name the member, so that, when your
boss asks for an MXG report on MIPS used, you will find
this program, which uses MSUUSED and MSU Capacity for the
PCTUSED, but also calculates MIPSUSED from MSUUSED.
-Note that the conversion from MSU to MIPS uses a factor
that you will likely have to change to meet your boss's
MIPS rating of your hardware. IBM giveth the MSU rating.
Comments show how to determine the factor for your boss,
and you can set different factors for different systems.
-The MIPSUSED are the MSUUSED, multiplied by the factor
you set; the default factor is 5.8 MIPS for each MSU, but
IBM now has a factor of 6.7 MIPS for each MSU for T-REX.
-See MXG Newsletter FORTY-ONE, MVS Technical Note 24, for
my documentation of MSU metrics and the MSU capacity
variables that are reported in the ASUMMIPS examples.
-PDB.RMFMSUSE is created from RMFINTRV and TYPE72GO data,
for capacity used by each Service and Reporting Class in
each interval. Be careful: PDB.RMFMSUSE has duplicate
data, because it keeps both the Reporting and Service
Class obs. You will need to select which obs are of
interest for your reporting, before you do any summary of
the data in PDB.RMFMSUSE.
-PDB.SMFMSUSE is created from RMFINTRV and SMFINTRV data,
for capacity used by each JOB in each interval. If your
SMFINTRV data is NOT globally synchronized, the results
in PDB.SMFMSUSE may be inaccurate:
If your RMF Interval is on 0 minutes, but your SMF data
is on 3 minutes, the 00:00 to 00:10 interval created in
PDB.SMFMSUSE includes CPU time from jobs's intervals
that executed from 00:03 to 00:13.
-In both datasets, the MSU capacity is calculated from the
CECSUSEC of the hardware platform, not from the SU_SEC of
the MVS System, because that's what IBM uses in its MSU
calculations. I use the NRCPUS (average number of CPUs
that IRD gave to this MVS system ) to get the capacity
of the specific interval (DURATM). To compare with IBM
hourly MSU rates, you need to multiply by the ratio of
3600 divided by DURATM of your interval data.
-The PCTUSED is the percentage of MSUUSED by the job or
service/reporting class during this interval, divided
by the interval MSU capacity (using average NRCPUS),
which MXG calculates in variable INTMSUCP.
-Be careful to not confuse MIPS/MSU counts with MSU rates.
Read the Newsletter Article (again).
-Macros define the input "RMFINTRV" dataset that is used,
which sets the output interval, and macros define the
output dataset names. The MXG default interval for
"RMFINTRV" is your RMF Interval, but you can execute the
RMFINTRV program many times to create multiple "RMFINTRV"
datasets, each with different interval (see comments in
member RMFINTRV). For example, Hourly in RMFINTHR,
Shiftly in RMFINTSH, Daily in RMFINTDY. Comments in
ASUMMIPS member show how to execute it and how to tailor
it for your needs.
Thanks to George Canning, Abbey Plc, ENGLAND.
Change 22.353 The ERROR*RMFINTRV. WORKLOAD CPU TIMES DO NOT MATCH ...
VMXGRMFI is printed when the sum (CPU72TM) of the workloads that
Jan 16, 2005 you defined, either in your tailored RMFINTRV member
(the recommended way to define which Service/Reporting
Classes you want combined into PDB.RMFINTRV workloads),
or in your tailored IMACWORK member (the old way), do not
match the sum (CPUTM) of all Service-only Classes.
The text of the message was enhanced to show both times
in both TIME12.2 and 8.2 formats and they are collimated
for easier reading.
-If you do receive that error message, you need to review
your RMFINTRV/IMACWORK definitions, and review your data,
which is the purpose of the UTILRMFI program, which will
examine both your TYPE72GO and STEPS/SMFINTRV data to
provide explicit answers, but UTILRMFI requires manual
EDITing, and could require re-reading of your SMF data.
This PROC FREQ might be sufficient to show the error:
PROC FREQ DATA=PDB.TYPE72GO
(WHERE=(STARTIME='02JAN2005:08:00:00'DT));
BY SYSPLEX SYSTEM;
TABLES RPRTCLAS*SRVCLASS*STARTIME/MISSING;
WEIGHT CPUTM;
FORMAT STARTIME DATETIME13.;RUN;
My error message was the result of using an old RMFINTRV
that had USEREPRT=GOAL (use ONLY Reporting Classes), but
the test data I was looking at (for other purposes!) did
not have 100% of its Service Classes mapped to Reporting
Classes. The preceding PROC FREQ showed that the CPUTM
was exactly equal to the RPRTCLAS=' ' observations, and
that CPU72TM was exactly equal to the RPRTCLAS='Y' obs,
and that CPU72TM was less than CPUTM. The PROC FREQ is
also useful since it shows the CPU time and the names of
all Service and Reporting Classes in the interval.
Change 22.352 Test for short record expanded to test both LENMONI and
VMACTMO2 LENGTH, because an archive file contained two 80-byte
Jan 14, 2005 records that contained '4040'x for LENMONI.
Thanks to Tom Parker, CSC, USA.
Change 22.351 HSM format MGHSMFU for 13 is 13:FULL VOLUME DUMP instead
FORMATS of 13:DELETE BACKUP VERSIONS, and descriptions were made
Jan 14, 2005 clearer for migration formats.
Thanks to Michael Yuan, University of California, USA.
====== Changes thru 22.350 were in MXG 22.13 dated Jan 13, 2005=========
Change 22.350 New CICS/TS 3.1 variables WBREPRDL, WBREPWDL, PGCRECCT
UTILEXCL were found in PDB.CICSDICT and are now supported in the
VMAC110 UTILEXCL member, and WBSNDOU1 test was corrected.
Jan 13, 2005 -Duplicate variables were not removed from SORTTEST so
and additional DATA step was added to remove them all.
Without this change, 180 errors when TYPE110 was executed
with IMACEXCL built by the earlier UTILEXCL.
Thanks to Tory Lepak, Aetna, USA.
Change 22.349 Change 22.325 created SHORTCPS/PLCPRDYQ variables, but
VMAC7072 negative values were found in a few TYPE70 observations.
VMXGINIT Those obs also had PCTMVSBY and CPUMVSTM negative, values
Jan 13, 2005 of MVSWAITx greater than DURATM, and unreasonably large
Jan 29, 2005 IORATE values, at two sites, both using IRD (Intelligent
Resource Director, the WLM component that varies engines
on/offline as needed. The occasionally bad data records
occurred with both z/OS 1.4 and 1.5, and all of the RMF
70 records with bad data had SMF70CNF bit 6 on ('02'x or
'03'x in MXG variables CAIx), and no observations with
bit 6 off had bad data values, and only some CPU Data
segments in each bad record had bad data.
-None of the LPAR bits indicated a change in CPUs, but in
one z/OS 1.5 case examined closely, in the LPAR segment
for the CPUID that had CAI='02'x, SMF70ONT was only 230
milliseconds less than SMF70INT/DURATM; the next interval
shows that engine remained offline (CAI='00'x), so it
appears the bad data may only occur when IRD has varied
an engine off right at the end of an interval.
-When engines had been IRD'd on/off with good data, they
had SMF70ONT values that were a multiple of 10 minutes,
the normal WLM decision interval for varying engines.
-SMF70CNF bit 6 was documented in the SMF manual as
"CPU reconfigured during the measurement interval (data
for this CPU is incorrect)"
However, RMF Development now says that the "incorrect"
part of the doc is out of data, is no longer true, and
will be revised.
-Both sites had SLIH counts of 20-30 million in 900 second
(15 minute) interval data, which was much above the value
in normal observations from both sites.
-Many obs had SMF70WAT (CPUWAITM) much larger than DURATM
in the observations with bit 6 on (as much as 26 Hours of
Wait in a 15 minute interval) at one site, while the
second size always had SMF70WAT of zero when bit 6 was on
(which is likely also wrong, as that would be 100% busy
for that engine, which was inconsistent with the other
engines in the LPAR for that interval).
-One of the sites will opening a PMR with IBM, after I had
extensive discussions with RMF Development, but that will
require IBM Support to design a SLIP trap to diagnose the
problem, which will take some time and effort by both IBM
and the customer.
-I had revised MXG code to detect that CNF bit 6 is on, in
this original change, so that you could choose to cause
those bad values to be instead be set to a missing value,
simply by inserting this optional statement:
%LET CNFBIT6=1;
after your //SYSIN. And this change originally made the
MXG default to calculate the bad values, so that you'd
know they existed. Fortunately, that bad data only
affects variables that are "MVS-specific" and are not the
"mainstream" variables you use for CPU calculations; they
have been there some time and were not observed until I
added the Short CPs variables.
HOWEVER: UPDATE JAN, 2006: SPLIT 70 Rewrite eliminated
the CNFBIT6 macro variable option, and these data are
always presented. See change 23.321.
-Several MXG sites without IRD have run the program and
none have seen the symptoms, but that's not conclusive.
-In conclusion, these MXG variables in PDB.TYPE70 and in
PDB.RMFINTRV (where not all are kept) may be negative or
incorrect with MXG's default
PCTMVSBY MVSWAITn SHORTCPS PLCPRDYQ CPUMVSTM
when corresponding CAIx variables have 02x or 03x values.
-Additional notes from RMF Development elaborate meanings:
MXG Variable LPARCHNR='Y' if Bit 1 of SMF70PFG is on:
Bit 1 of PFG (Number of Logical Processors has
Changed) does not indicate any online/offline
activity; it it indicates whether the number of
logical processors changed and does not care whether
those processors are online or offline or whether
their on/of status changed.
MXG Variable LCPUVARY='Y' if Bit 5 of SMF70VPF is on:
Bit 5 of VPF (log proc varied online during interval)
is only set when the processor turned ONLINE compared
to the status at the end of the previous interval
(this is more or less a bit from the old days, prior
to WLM CPU mgmt).
-You can use the below program, to analyze your existing
TYPE70 data to see if the problem exists in at your site:
/* CNFBIT6 PROGRAM, EXAMINE SMF70CNF BIT 6 ERRORS */
/* DISREGARD THE MESSAGES ON THE LOG THAT STATE: */
/* THERE ARE NO VALID OBSERVATIONS... */
PROC CHART DATA=PDB.TYPE70;
BY SYSPLEX SYSTEM MVSLEVEL DURATM NOTSORTED;
HBAR CPUWAIT1-CPUWAIT9 IORATE CAI1-CAI9;
TITLE MXG INVESTIGATION OF SMF70CNF BIT 6 ERROR;
TITLE2 CPUWAIT GT DURATM IS AN ERROR CONDITION;
TITLE3 IORATE GT 10000 IS LIKELY AN ERROR CONDITION;
TITLE3 ONLINE STATUS OF 02-03 ARE SMF70CNF BIT 6 ON;
LABEL SYSPLEX='SYSPLEX' SYSTEM='SYSTEM'
MVSLEVEL='MVSLEVEL' DURATM='DURATM';
Thanks to MP Welch, SPRINT, USA.
Thanks to Chuck Hopf, MBNA, USA.
Thanks to Michael Oujesky, MBNA, USA
Change 22.348 The actual variable names are CPUIFATM and CPUIFETM, but
Several there still were references in several members to the
Jan 12, 2005 original-last-August names of IFACPUTM and IFECPUTM.
Thanks to Raimo Korhonen, CompMeas Consulting Oy, FINLAND.
Change 22.347 The IMACEXCL member generated for CICS/TS 3.1 data could
UTILEXCL fail with 180 abend starting with variable PGTOTCCT.
Jan 12, 2005
Thanks to Victoria Lepak, Aetna, USA.
Change 22.346 PCTCPUBY for non PR/SM system was wrong; it was either
VMAC7072 the busy of the last engine, or missing, if the last CPU
Jan 12, 2005 was offline. And the IORATE was way wrong, as it was the
IORATE of the last engine, not the total of all engines.
Thanks to Mary Kay Pettengill, (i)Structure, USA.
====== Changes thru 22.345 were in MXG 22.13 dated Jan 12, 2005=========
Change 22.345 The support for Multi-System Remote Enclave CPU segment
VMAC30 in Change 22.051 was flat out wrong; I was misled by my
Jan 12, 2005 own error: my code INPUT the MOF/MLN/MNO triplet at the
same location as the ARM triplet offset. The data DOES
agree with IBM documentation, and, with this change, the
IBM field names are the MXG variable names in TYPE30MR.
Note: the SMF30MRD/SMF30MRI CPU times are normalized by
MXG back to the system on which this type 30 was created,
but both SMF30MRA and LOSU_SEC variables are kept in the
TYPE30MR dataset, in case you want to do it differently.
The sum of SMF30MRD/SMF30MRI in all MR segments in this
SMF 30 record are summed into variables CPUMRDTM/CPUMRITM
which already existed in TYPE30_4(PDB.STEPS) and TYPE30_5
and are now also kept in TYPE30_V (PDB.SMFINTRV).
However, CPUMRDTM/CPUMRITM are NOT added into CPUTM, at
least not yet by this change; since they have never been
right, they could not have been used, and it is not
clear exactly what use will be made of those CPU times
that occurred on other systems. Your feedback is wanted!
Especially, since I do not have any type 30 records with
the Multi-System segment with which to validate!!
-The original MXG variable names RMSU_SEC and MRENSYST are
now replaced by SMF30MRA and SMF30MRS respectively.
Thanks to Robert Vaupel, IBM RMF Development, GERMANY.
Change 22.344 If you have too many LPARs and LCPUADDRs, it is possible
VMAC7072 for IBM to split your RMF 70 data into multiple physical
Jan 11, 2005 records for each interval, and this is not YET supported
in MXG (because no one yet has actually made it happen).
At least now, MXG will detect the split records and will
alert you with error messages and hex dumps of the first
10 records with SMF70RAN non-zero, and will tell you that
your TYPE70, TYPE70PR, ASUM70PR, ASUM70LP, and ASUMCEC
data are wrong, and that TYPE70 will have multiple obs
for a single RMF interval. Eventually, MXG will support
the split records, and this change text will be revised.
====== Changes thru 22.343 were in MXG 22.13 dated Jan 10, 2005=========
Change 22.343 Discussion and examples for building MONTHLY PDBs.
JCLMNTH -The existing JCLMONTH and JCLMNTH both assume you want to
JCLMNTHD build your MONTH PDB on tape. The original JCLMONTH read
JCLMONTH five weekly PDBs and created MONTH as a sequential format
MONTHBLD ("tape format") SAS data library, but there are multiple
MONTHDSK mounts and rewinds when multiple data steps are used to
Jan 9, 2005 write multiple datasets to a seq-format library on tape.
So the JCLMONTH was revised (in 1987!) to write each
dataset first in sequential format to //TAPETEMP DD on
DASD, and MVS's MOD was used to add each dataset to the
end of the tape, to eliminate backspace/rewind delays.
-But even then, if your weekly PDBs were each on tape, the
JCLMONTH required six tape drives, one for each weekly
PDB and one for the MONTH output data library. So 1992s
JCLMNTH example enhanced the process by requiring only
one tape drive, by first PROC COPYing each weekly tape
PDB with SELECT of the needed datasets to temporary DASD,
(with UNIT=AFF so only one tape drive was needed to read
all weekly PDBs), and then the MONTH PDB was created
using //TAPETEMP, MOD, and UNIT=AFF on the same drive.
-While both JCLMONTH or JCLMNTH were designed to write the
//MONTH to tape, you could write MONTH to a DASD DD.
However, a data library in sequential (tape) format has
no directory, so you must read all N-1 preceding SAS
data sets to read the Nth dataset you wanted, wasting CPU
and I/O.
-In addition, you may have been wasting a lot of DASD
space if you wrote your //MONTH to DASD in sequential
format. This entire discussion was precipitated when the
reporting site's monthly job failed when it ran out of
disk space; they had moved from SAS V8.2 to SAS V9.1.3,
but were unaware they were creating their Monthly PDB in
sequential format:
-Using SAS V8, V8SEQ, and COMPRESS=YES (MXG Default),
and writing //MONTH to DASD in sequential format, they
needed only 55,830 tracks, because V8SEQ, SAS 8.2 and
COMPRESS=YES did compress sequential format libraries,
but V9SEQ and SAS V9.1.3 does NOT compress seq format,
so its data library was 106,710 (uncompressed) tracks!
-So I had Chuck then run these benchmarks to reveal the
source of their ABEND:
Tracks Engine SAS Version CPU sec Compress
34305 DASD V8 8.2 --- Yes
106710 V6SEQ 8.2 65 Yes
106725 V9SEQ 9.1.3 26 No
106725 V9SEQ 9.1.3 26 Yes
34380 DASD V9 9.1.3 138 Yes
63705 DASD V9 9.1.3 22 No
106723 V8SEQ 8.2 22 No
55830 V8SEQ 8.2 126 Yes
34305 V8SEQ 8.2 133 Yes
50145 V8SEQ 8.2 20 No
106725 V8SEQ 9.1.3 26 No
106725 V8SEQ 9.1.3 26 Yes
34380 DASD V8 9.1.3 137 Yes
63705 DASD V8 9.1.3 20 No
-Even though COMPRESS was specified, not all engines
and versions actually compress sequential format, but
that is what I want: if you are writing to tape, the
IDRC hardware compress the tape, so you don't want
SAS to burn CPU time to also compress the data.
Furthermore, you can write a single SAS dataset to
an extended-sequential, striped, hardware-compressed
DASD device, which also shouldn't be SAS-compressed.
-MXG CONFIGV9 still specifies V6SEQ today, because I
cannot tell from within SAS if you are at V9.1.3, or
if you have the critical Hot Fix for earlier V9s.
Originally I recommended V6SEQ, even under SAS V8.2,
because it did NOT waste CPU time by compressing.
While V9SEQ eliminated that compression, prior to
SAS V9.1.3, you MUST use V6SEQ, because there were
data corruption errors using V8SEQ or V9SEQ under
SAS V9s prior to 9.1.3. If you have installed 9.1.3,
it is NOW safe for you to change CONFIGV9 to V9SEQ.
-So back to the new JCL examples, and documentation of all
of your choices. This change adds example JCLMNTHD and
member MONTHDSK, which should be used when yow want your
monthly on DASD, and your weekly PDBs are also on DASD.
Additionally, once you've built "Last Month's" PDB on
DASD, you can archive it to a tape GDG by using:
PROC COPY IN=MONTH OUT=MNTHTAPE MT=DATA;
to write all of those datasets in a single write to tape
when you're finished with this month's reporting and then
free up the DASD space.
JCL Code Weekly Monthly Select Tape
Member include On On Copy Drives
JCLMONTH MONTHBLD Tape Tapes No Six
JCLMNTH MONTHBLD Tape Tapes Yes One
JCLMNTHD MONTHDSK Disk Disk No None
JCLMNTHT MONTHDSK Tape Disk Yes One
-To be complete, JCL example JCLMNTHT is created, but it
is likely to be unneeded - if you can't find space on
DASD for your weekly PDBs, then why try to write a month
to DASD? (Perhaps, if you only build a small number of
datasets monthly, which is really what I personally think
best - I only created the JOBS/STEPS/PRINT/RMFINTRV in my
monthly, and did all of my other reporting week-to-week.
Thanks to Bruce Green, MIB, USA.
Change 22.342 INCOMPATIBLE MXG CHANGE TO BUILDPDB, if you have tailored
BUILD001 your build to add SMF 115 or SMF 116 records. If so, you
BUIL3001 MUST remove the references to 115 and/or 116 in the PDB
BUILD004 exit members, EXPDBINC/EXPDBVAR/EXPDBCDE/EXPDBOUT. If
BUILDPDB you overlook this revision to your tailoring, your first
BUILDPD3 test of the new MXG BUILD will fail, because of duplicate
BUILD606 dataset names being built in the first Data Step.
Jan 10, 2005
Change 22.341 -If you have IFAs but don't have APAR OA09118 installed
VMAC30 (adds CPUCOEFF to SMF 30), MXG-created IFAUNITS/IFEUNITS
Jan 7, 2005 variables are missing, causing CPUUNITS to still include
the IFAUNITS. Now, if there are RMF 72s from the same
SYSTEM in the SMF file that precede the type 30 record,
the old MXG logic to calculate EXCPRMF using CPUCOEFF
from RMF is used to also populate IFAUNITS and IFEUNITS
and to subtracts IFAUNITS from CPUUNITS. If both the
IFAUNITS and EXCPRMF are still missing values, then both
the APAR is not installed and there was no RMF 72 record
from this system before that type 30 record.
-The IFA CPU time variables are now formatted TIME12.2.
Thanks to Bernie Pierce, IBM, USA.
Change 22.340 -If zAAP engines are offline, MXGs PCTIFABY in TYPE70 was
VMAC7072 100%, and IFAACTTM was equal to the DURATM, because MXG
Jan 6, 2005 did not consider offline IFAs. This change restructures
MXG code for IFAs, summing IFAs SMF70ONT into IFAUPTM and
summing IFAs LCPUPDTM into IFAACTTM to calculate PCTIFABY
and also new variable NRIFAONL, the number of IFAs that
were online (which, like NRCPUS, the number of CPs that
were online) can be a fraction if some are offline.
-The MXGCIN variable is also now correctly set to IFA even
for offline IFAs. The original NRIFAS variable is now a
count of installed IFAs, but is not used in calculations.
-The IFAWAITn and PCTIFBYn variables (32 of each!) are no
longer created; they are not needed in TYPE70 and they
can be determined from TYPE70PR.
-If CP engines were varied on/off, PCTMVSBY was wrong, as
it was calculated based on DURATM instead of SMF70ONT;
this also led to incorrect values of the new SHORTCPS
variable, that was added in Change 22.325.
-Mar 7, 2005: The MXGCIN 'guess' depends on IRD, because
variable SMF70SPN, the LPAR Cluster Name, is only found
in systems that are in an LPAR Cluster.
Thanks to Dave Cogar, CA, USA.
Change 22.339 -Major enhancement to TNG support:
EXTNT100- The instance macro variables values and the MAXROW value
EXTNT127 are now set dynamically from the input performance cubes,
EXTNT127 so you won't get any ARRAY SUBSCRIPT OUT OF RANGE errors!
FORMATS The cube's headers are read in a quick pass of the input,
IMACTNG and then used to write the %LET PPoooI=nnn; statements
TYPETNG (to //INSTREAM) for each object that was found in your
TYPSTNG input; the input is then re-read to create the output.
VMACTNG This will also minimize the amount of virtual storage
VMXGINIT required for the MXG job; a REGION of only 200MB was
Jan 6, 2005 used for test data with many objects and many instances
Jan 21, 2005 that previously required over 400MB. And since the array
size is now based on data, the default instance macro
variables in VMXGINIT are now all set to one, and metric
macro variables are back in the VMACTNG member, since
they are only changed when new metrics are added by CA,
and that requires other changes in the VMACTNG code.
-Support for 28 new NT objects with over 600 metrics:
Dataset dddddd Object Name
TNT100 NT100 ASP.NET APPS V1.1.43
TNT101 NT101 ASP.NET V1.1.4322
TNT102 NT102 DOUBLE-TAKE CONNECTI
TNT103 NT103 DOUBLE-TAKE KERNEL
TNT104 NT104 DOUBLE-TAKE SECURITY
TNT105 NT105 DOUBLE-TAKE SOURCE
TNT106 NT106 DOUBLE-TAKE TARGET
TNT107 NT107 FTP SERVER
TNT108 NT108 GOPHER SERVICE
TNT109 NT109 GROUPSHIELD FOR MICR
TNT110 NT110 HTTP SERVICE
TNT111 NT111 INDEXING SERVICE
TNT112 NT112 INDEXING SERVICE FIL
TNT113 NT113 MSEXCHANGE INTERNET
TNT114 NT114 MSEXCHANGECCMC
TNT115 NT115 MSEXCHANGEDS
TNT116 NT116 MSEXCHANGEES
TNT117 NT117 MSEXCHANGEIMC
TNT118 NT118 MSEXCHANGEIS
TNT119 NT119 MSEXCHANGEIS PRIVATE
TNT120 NT120 MSEXCHANGEIS PUBLIC
TNT121 NT121 MSEXCHANGEMSMI
TNT122 NT122 MSEXCHANGEMTA
TNT123 NT123 MSEXCHANGEMTA CONNEC
TNT124 NT124 MSEXCHANGEPCMTA
TNT125 NT125 SQLSERVER:BACKUP DEV
TNT126 NT126 DATABASE
TNT127 NT127 RSVP SERVICE
-When processing TNG data on ASCII platforms, which have
a default LRECL=255, you will need to add LRECL=32000 to
your FILENAME statement.
-Jan 20: temporary datasets used in _UTNGCNT now deleted.
Thanks to Peter Krijger, ANZ National Bank Limited, NEW ZEALAND.
Change 22.338 The AUTOEXEx and CONFIGVx members now specify the option
AUTOEXEC DLDMGACTION=REPAIR for all platforms; the option causes
AUTOEXEU SAS to automatically repair and rebuild indexes and the
CONFIGV8 integrity constraints, when a damaged SAS dataset is
CONFIGV9 detected; the most common reason for a damaged data set
Jan 4, 2005 is when it was left open because of a prior abnormal
termination (i.e., on z/OS, an x22 timeout ABEND). SAS
defaults are inconsistent, with z/OS having REPAIR for
batch and PROMPT for interactive, but FAIL for batch and
REPAIR for interactive for Windows systems.
Thanks to Dan Squillace, SAS Institute Cary, USA.
Change 22.337 -WARNING: BIT MASK .. TOO LONG because the RACF variables
VMAC80A KW23SPEC and KW23IGNR are only one byte each, but the bit
Jan 4, 2005 tests were wrong, and were testing for two bytes.
-Variable RACF07DT was increased to 200 bytes.
Thanks to Erling Andersen, SMT, DENMARK.
Change 22.336 Major enhancement: MQMACCT/MQMACCTQ data (SMF 116) can be
ASUMUOW added to the PDB.ASUMUOW dataset for CICS transactions
IMACUOW created by MQ-Series (but you must enable their addition
JCLMQMCI in your IMACUOW member or in your input per comments.
VMXGUOW IBM does NOT provide the variables NETSNAME/UOWTIME in
VMXGINIT MQMACCT/MQMACCTQ datasets that are used to directly match
Jan 10, 2005 up to CICSTRAN data. (IBM MQ-series support claimed that
the STCK value in QWHCNID in MQMACCT could be used, but
its value is NOT the same as the UOWTIME STCK value.)
So this heuristic algorithm first matches CICSTRAN with
MQMACCT by APPLID TASKNR TRANNAME to get NETSNAME/UOWTIME
from CICSTRAN, which is then used to merge MQMACCT and
MQMACCTQ (which can have more than one obs per uow if
multiple MQ queues are used) with the CICSTRAN (and any
DB2ACCT data, although DB2ACCT data is not required).
-There is a clear exposure in using the TASKNR within an
APPLID to get the NETSNAME/UOWTIME from CICSTRAN, as the
IBM maximum for TASKNR is currently 99999, even though
the field is a PD4 that could contain 9999999, but there
is no other way at the present time.
-You MUST have tailored either IMACUOW or ASUMUOW to even
create observations in PDB.ASUMUOW in the first place,
since the MXG default is to create zero observations.
You must re-tailor using the new IMACUOQ or ASUMUOW
member from this MXG to add the MQ Series variables.
-ASUMUOW will not fail, even if there are no MQ data.
-Variable MQTRAN counts the number of MQMACCT/MQMACCTQ
records that were included in the Unit of Work.
-MXG's BUILDPDB was revised by Change 22.342 to add the
processing of SMF 115 and 116 data in the default PDB.
-Member JCLMQMCI is a JCL example that uses VMXGUOW for
standalone processing of SMF for CICSTRAN, DB2ACCT and
SMF 116 data to create PDB.ASUMUOW with all three.
-MXG 22.12. Error due to IMACUOW missing an end comment
symbol. At the same time, CICSUOW dataset was
externalized by MACRO _UOWICIC so that it's destination
can be overridden.
-VMXGINIT defines macro variable MXGMQADD, default blank.
-Cosmetic. Using %INCLUDE SOURCLIB(ASUMUOW); with no DB2
observations caused UNINITIALIZED variable messages that
are now eliminated by adding compiler fakers for DB2PARTY
QWACFLGS and QWHSSSID variables, and missing value notes
have also been almost completely suppressed.
Thanks to Ove Dall-Hansen, Codan Insurance, DENMARK.
Thanks to Diane Eppestine, SBC, USA.
Change 22.335 Unused Change Number.
Change 22.334 Support for APAR OA06476 changes to RMF 74 records.
EXTY748A -Subtype 5 adds these new metrics to TYPE74CA dataset:
EXTY748R R7451CT1='BYTES*READ'
EXTY748X R7451CT2='BYTES*WRITTEN'
FORMATS R7451CT3='READ*RESPONSE*TIME'
IMAC74 R7451CT4='WRITE*RESPONSE*TIME'
VMAC74 R7451PBR='PHYSICAL*STORAGE*BYTES*READ'
VMXGINIT R7451PBW='PHYSICAL*STORAGE*BYTES*WRITTEN'
Jan 1, 2005 R7451PRO='PHYSICAL*STORAGE*READ*OPERATIONS'
R7451PRT='PHYSICAL*STORAGE*READ*TIME'
R7451PWO='PHYSICAL*STORAGE*WRITE*OPERATIONS'
R7451PWT='PHYSICAL*STORAGE*WRITE*TIME'
R7451XID='EXTENT*POOL*ID'
R7451XTY='EXTENT*TYPE'
R7452XFL='EXTENT*POOL*FLAGS'
"Millisec" values are formatted TIME13.3 (so a value of
99 milliseconds will print as 0:00:00.099).
-Subtype 8 creates three new datasets:
TYPE78A - ESS RANK ARRAY DATA
R748AACP='ARRAY*CAPACITY'
R748AAID='RANK*ARRAY*IDENTIFIER'
R748AASP='ARRAY*SPEED*IN 1000*RPM'
R748AAWD='ARRAY*WIDTH'
R748AEBC='ARRAY*TYPE*EBCDIC'
R748ARID='RANK*IDENTIFIER'
R748ATYP='ARRAY*TYPE*CODED'
TYPE78R - ESS RANK STATISTICS DATA
R748RAIX='INDEX TO*FIRST ARRAY*SECTION OF*RANK'
R748RBYR='BYTES*READ'
R748RBYW='BYTES*WRITTEN'
R748RCNT='COUNT OF*ARRAYS*IN RANK'
R748RKRT='READ*TIME'
R748RKWT='WRITE*TIME'
R748RPNM='EXTENT*POOL*NUMBER'
R748RRID='RANK*IDENTIFIER'
R748RROP='RANK*READ*OPERATIONS'
R748RWOP='RANK*WRITE*OPERATIONS'
TYPE78X - ESS EXTENT POOL STATISTICS
R748XPID='EXTENT*POOL*IDENTIFIER'
R748XPLT='EXTENT*TYPE'
R748XRCP='REAL*EXTENT*POOL*CAPACITY*
R748XRNA='ALLOCATED*REAL*EXTENTS*IN POOL'
R748XRNS='REAL*EXTENTS*IN EXTENT*POOL'
R748XRSC='REAL*EXTENT*CONVERSIONS'
R748XSDY='SOURCES OF*DYNAMIC*RELOCATIONS'
R748XTDY='TARGETS OF*DYNAMIC*RELOCATIONS'
R748XVCP='VIRTUAL*EXTENT*POOL*CAPACITY'
R748XVNS='VIRTUAL*EXTENTS*IN EXTENT*POOL'
R748XVSC='VIRTUAL*EXTENT*CONVERSIONS'
Change 22.333 Cosmetic. If you used "views" for MXG datasets that still
DOC "housecleaned" with PROC DELETE DATA=_Wdddddd syntax, you
Jan 1, 2005 got a non-fatal SAS warning message; replacing the syntax
with the preferred %%VMXGDEL(DDDDDD=dddddd); eliminates
the messages. (All were oversights where VMXGDEL should
have been used.) These members were revised:
ANALVVDS ASUMTAPE TYPEDOS TYPETMS5 VMAC103 VMAC108
VMAC29 VMAC30 VMAC50 VMAC79 VMACAIX VMACCIMS
VMACCTLL VMACHMF VMACHSM VMACMPLX VMACTCP VMACTIMS
VMACTMDB VMACTPF VMACTPX VMACVITA VMACVMON VMACVMXA
VMACXXXX
Thanks to Joe Babcock, Bank One, USA.
Change 22.332 Support for (Optional) ESS segment GEPARMKY field values
IMAC6ESS 0036x=ESSRETAS, 0041x=ESSOFSTF, and 0043x=ESSOFSTB, plus
VMAC6 correction for '034'x field, which can have time-in-text
Dec 30, 2004 formats of 10:00 or 0150:00:00.
Jan 2, 2005
Thanks to Dr. Alexander Raeder, Itellium, GERMANY.
Thanks to Harmuth Beckmann, Itellium, GERMANY.
Change 22.331 Support for hIOmon File I/O Performance Monitor.
VMACHIOM This Windows family I/O monitor records activity at the
Dec 30, 2004 individual file for each process for each user, with both
I/O activity counts, Bytes read/written, and duration of
the I/O. A special export option MXGall creates a csv
file of all 117 I/O metrics, with nulls for those fields
that are not being monitored, and that file is the file
supported in the TYPEHIOM code. Only a single dataset is
presently created, for both files and devices, but that
may change, based on user feedback. The inexpensive I/O
monitor can be downloaded at http://www.hyperio.com, and
a free trial is offered.
Thanks to Tom West, hyperI/O LLC, USA.
Change 22.330 Documentation. The CPUxxxTM variables created from SMF
ADOC30 30 records were not fully documented; they are updated
Dec 30, 2004 and identify what's included in which variables.
Thanks to Michael Bouros, Morgan Stanley, USA.
Change 22.329 Major enhancement to "PC Job Streams" for running MXG on
BLDNTPDB ASCII systems to create "SMF" or "NTSMF" PDB Libraries.
BLDSMPDB Uses the new VMXGALOC utility macro to allocate daily,
VMXGALOC weekly, and monthly PDB Directories, creating directory
VMXGSUM names that contain the DATE of the data, and logic to
Dec 30, 2004 read the correct directories for the MONTH PDB.
Jan 16, 2005 -UPCASE(KEEPALL) was added in VMXGSUM for pc execution.
UTILBLDP -Note: Only VMXGSUM was updated in MXG 22.13; the other
TRND70 three members were not revised until Jan 16, 2005.
ANALSHCP -UTILBLDP now supports OUTFILE=INSTREAM, needed for the
BLDSMPDB enhancement that lets you specify BUILDPDB= to
use the tailored UTILBLDP output for your BUILDPDB code.
-UTILBLDP now has an internal table of SMF records that
are automatically created by MXG's default BUILDPDB, so
that your USERADD= list can be compared and errors
prevented if you list a record that's already in PDB.
-UTILBLDP/BLDSMPDB logic for OUTFILE argument is robusted.
If the name is a PC dataset name it has to be inside
quotes, but if it is not (something like INSTREAM or like
SOURCLIB(MYPDB) then it must NOT be inside quotes in your
invocation. If a colon or backslash is found in your text
it will be put in quotes and treated as a PC filename.
-TRND70 now adds PCTMVSBY SHORTCPS PLCPRDQY MAXSHCPS and
MAXRDYQ to TRND70 dataset.
-ANALSHCP provides sample reports of SHORTCPs and PLCPRDYQ
for your systems.
Thanks to Chuck Hopf, MBNA, USA.
Change 22.328 Cosmetic, unless you used the _NTNG macro to null all of
VMACTNG the TNG datasets (the _NULL should have been _NULL_ in
Dec 29, 2004 each of the lines in MACRO _NTNG), or tried to use the
_KTNT015 macro to tailor NT015 (it was spelled _KTNT016).
Thanks to Freddie Arie, TXU, USA.
Change 22.327 Cleanup of BUILDPDB/BUILDPD3.
BUILDPDB -In BUILDPDB/BUILDPD3, TYPE30MR was not sorted into //PDB
BUILD002 (unless you used BUILD002, which did contain _STY30MR).
BUILDPD3 -Work datasets STEPS, STEPSIO, SPJB30T4 were created in
SPUNJOBS SPUNJOBS but were not deleted, now they are.
Dec 24, 2004
Change 22.326 Variable CPUCEPTM (CPU TIME WHEN TASK WAS ENQUE PROMOTED)
BUILD005 in what I regard as an IBM Design Error, is accumulated
BUIL3005 in the SMF 30 subtype 2 and 3 interval records; no other
ONLYINTV CPU metrics are accumulated in those records. This means
Dec 24, 2004 that the TYPE30_V dataset built from SMF is no longer
valid. But since MXG can correct IBM errors faster than
they can even acknowledge their errors (Level 2 says it's
not their problem to fix), this redesign in BUILDPDB code
deaccumulates the CPUCEPTM in the PDB.SMFINTRV dataset.
(Of course, the CPUCEPTM will be missing in the first
interval for each task that has more than one interval
record, since there is no prior interval record in
"today's" SMF file.)
Dataset PDB.SMFINTRV is automatically built by BUILDPDB.
-If you want to create PDBINTRV.SMFINTRV (and the other
interval dataset, PDBINTRV.TYPE30_6) directly from your
raw SMF file, you can use this example that uses the
BUILDPDB logic, but builds only the PDBINTRV.SMFINTRV
and the PDBINTRV.TYPE30_6 interval datasets:
//PDBINTRV DD DSN=YOUR.PDB.OUTPUT,DISP=(,CATLG),....
//SMF DD DSN=YOUR.SMF.DATA,DISP=SHR
//PDB DD UNIT=SYSDA,SPACE=(CYL,(5,5))
//SPIN DD UNIT=SYSDA,SPACE=(CYL,(5,5))
//SYSIN DD *
%INCLUDE SOURCLIB(ONLYINTV);
Thanks to Tony Hirst, Wells Fargo, USA.
Change 22.325 Variable SHORTCPS=PCTMVSBY/PCTCPUBY is created in TYPE70
VMAC7072 and TYPE70PR datasets, based on Kathy Walsh's Paper that
Dec 23, 2004 was presented at SHARE in August, 2004, available at
Jan 10, 2004 http://www-03.ibm.com/support/techdocs/atsmastr.nsf/
Oct 12, 2004 WebIndex/PRS1077, titled
"Performance Impacts of Running CICS in a Shared LPAR".
The term 'Short CPs' was created by IBM WSC Performance
Staff, and is a performance effect created by the LPAR
hipervisor enforcing LPAR weights on busy processors or
capped LPARs, that can reduce the MIPS delivered by the
logical CPs to the partition. She suggested that when
the SHORTCPS ratio exceeded 2, it could be a sign of
trouble. But Don Deese pointed out that another way of
looking at the phenomenon is as a measure of the queueing
delay when the LPAR is waiting for a CP engine to be
assigned, and that a ratio of 2:1 means that for 50% of
the elapsed time, the LPAR was waiting for a CP engine.
He suggests that even a lower ratio may be the threshold
of pain; a ratio of 1.5:1 means the LPAR was 33% waiting.
Don is working on an extensive discussion of this topic
in the next release of his CPExpert product, and I have
created variable PLCPRDYQ=100*(PCTMVS-PCTCPUBY)/PCTMVSBY;
so that you can use either the ratio or the percent of
time when there was a delay in your analysis to see if
this construct is useful in measuring your LPARs.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Thanks to Dr. Robert Cross, JP Morgan, USA.
Change 22.324 Cosmetic. Missing value messages eliminated by testing
VMACTNG three NT006 fields before they are multiplied by 1024 or
Dec 23, 2004 1024*1024.
Change 22.323 Line 3624 should have named TOTSHARE TOTSHARC in KEEP=
VMXG70PR list for &OUT70LP dataset, instead of SYSSHARE CURSHARE,
Dec 23, 2004 to keep those variables in the PDB.TYPE70LP dataset.
Thanks to MaryBeth Delphia, Texas Comptroller of Public Accounts, USA
Change 22.322 Hasty creation of JCL examples for MXG under SAS V9.1.3
MXGSASV9 did not have sufficient testing; W-OH should have been
JCLTEST9 W-zero, WORKVOL was not referenced in JCLTEST9, WORK
JCLPDB9 sizes are all now 500,500, the WORK=200 in JCLPDB9 was
Dec 23, 2004 removed (with only a primary allocation, you cannot use
multiple volumes), and comments with "V8" were revised to
"V9". The instream JCL PROC in the JCLTEST9 example now
matches the symbolics in MXGSASV9.
Feb 23, 2005: This change originally changed the INSTREAM
LRECL to 72, but Change 23.012 corrected that back to 80.
Thanks to Bruce Green, MIB, Inc, USA.
Thanks to Michael Gebbia, Eddie Bauer, USA.
Change 22.321 Type 6 PrintWay records apparently come in two flavors,
VMAC6 and Change 22.302 did not protect both; in some records
Dec 21, 2004 the SMF6PQNM is always 24 bytes, and SMF6PQLN is the
number of non-blank bytes, and in other records, SMF6PQNM
is only the length of SMF6PQLN. (And, to make it more
fun, in VPS-FAX records, SMF6PQLN is always zero, but
PQNM is 24 bytes!). Additional test for blanks when
SMF6PQLN is less than 24 bytes now protects INPUT
STATEMENT EXCEEDED error that occurred even with Change
22.302/MXG 22.12 installed. And, variable SMF6PQLN is
now output in TYPE6 dataset.
Thanks to Robert Vance, Zurich Insurance Co., USA
Thanks to Reiner Luken, Zurich Insurance Co., USA
Change 22.320 This long-overdue enhancement for PDB.SMFINTRV combines
BUILD005 the MULTIDD='Y' observations from TYPE30_V into a single
BUIL3005 observation in PDB.SMFINTRV, with the correct totals for
Dec 15, 2004 EXCPxxxx, IOTMxxxx, and TAPEDRVS variables for each SMF
interval. There will be fewer observations created in
PDB.SMFINTRV, and variables EXCPNODD, IOTMNODD, and
TAPEDRVS are now correct for each interval. Variable
EXTRADD is set to zero, since those extra DDs have been
consolidated in the single observation per interval.
Note: Long ago, the MULTIDD='Y' observations were summed
into the PDB.STEPS dataset in the BUILDPDB logic. It
was only PDB.SMFINTRV that still contained MULTIDD='Y'
observations:
MULTIDD='Y' - steps with more DDs than can fit in one
SMF 30 record write multiple type 30 records; those
additional records contain only IOTMxxxx,EXCPxxxx and
TAPEDRVS values, and are flagged with MULTIDD='Y'.
See Change 23.015 if ERROR: PDB.SMFINTRV NOT SORTED is
encountered in your WEEKLY or MONTHLY PDB jobs.
Thanks to Mary Kay Pettengill, (i)Structure, USA.
Change 22.319 The R747AVFR/R747AVFT average frame size received/sent
VMAC74 in dataset TYPE747P needed to be multiplied by four; the
Dec 15, 2004 source fields are in words, and have 4 bytes per word.
Thanks to Pat Jones, DST, Inc, USA.
Change 22.318 The JCLINSTL example used the SAS V8 JCL procedure; new
JCLINST9 JCLINST9 had the minor changes to execute under SAS V9.
Dec 15, 2004 The correct CONFIGV9 member and ENTRY=SAS are now in the
example that uses the site's installed SAS JCL procedure
to create the MXG Format library during install. Once
this JCL example has been executed, the MXGSASV9 JCL proc
should be use for all subsequent MXG testing/execution.
Thanks to Burchell Williams, HIPUSA, USA.
Change 22.317 The final @; was not correctly created in the second and
UTILEXCL subsequent GRNR's, when there were optional segments; at
Dec 15, 2004 first, I blamed the conversion of CMODLENG from numeric
Dec 21, 2004 to character was the culprit, and revised that logic in
the COMDNAME='USER' code segment to
!!PUT(CMODLENG,4.)!!, but in fact the real error was a
hanging end-comment-*/ in line 745 that I had
accidentally removed during the testing of the CMODLENG
code change!
Thanks to Sally Jordan, Bear Sterns, USA.
Thanks to MaryBeth Delphia, Texas Comptroller of Public Accounts, USA
====== Changes thru 22.316 were in MXG 22.12 dated Dec 11, 2004=========
Change 22.316 Enhanced Support for RMF III VSAM files have many added
ASMRMFV features and options, all of which are discussed in the
ADOCRMFV documentation note at the beginning of ADOCRMFV member.
Dec 11, 2004 No changes are required to the CLRMFV nor TYPERMFV code.
Thanks to Jerry Urbaniak, Acxiom CDC Inc, USA.
Change 22.315 Example ASUM and TRND members for IBM SMF 94 VTS data.
ASUM94
TRND94
Dec 11, 2004
Change 22.314 Support for MainView for IMS IMF 4.1.00. DSECTS show no
TYPECIMS changes in the IMF records for IMS Version 9.1
Dec 11, 2004
Thanks to Tony Curry, BMC, USA.
====== Changes thru 22.313 were in MXG 22.12 dated Dec 10, 2004=========
Change 22.313 Optional field CMODNAME='DFHAPPL', CMODHEAD='APPLNAME'
IMACICAP had CMODIDNT='001', which tripped up MXG logic because
IMACICD6 only CMODNAME=:'DFH' (starting with) was tested; '001'
IMACICD7 generated an extra input of TRANNAME in the wrong place
UTILEXCL in IMACEXCL, which failed when it was executed.
VMAC110 -All of the CMODNAME tests were revised to test for the
Dec 10, 2004 full name (DFHTASK/DFHCICS/etc).
-New exits for optional fields and variables created:
CMODNAME CMODHEAD EXIT Variable
DFHAPPL APPLNAME IMACICAP APPLNAME
CANDEXNM CANDEXNM IMACICD6 CANDEXNM
CANDEXTY CANDEXTY IMACICD7 CANDEXTY
Thanks to Sally Jordan, Bear Stearns, USA.
Change 22.312 Support for NetSpy Version 7.0 (COMPATIBLE).
VMACNSPY -New variables in NSPYTCP.
Dec 10, 2004 NSPYAVRT NSPYINBU NSPYLOGM NSPYNROT NSPYNRTT NSPYOUBU
NSPYRCBS NSPYSGNL NSPYSOOP NSPYSSTZ NSPYTIMR NSPYTNID
NSPYTUID
-New variables in NSPYTCPS.
NSPYASID NSPYIFNR NSPYIPAE NSPYIPFC NSPYIPFD NSPYIPFF
NSPYIPFO NSPYIPFO NSPYIPHE NSPYIPID NSPYIPIR NSPYIPOD
NSPYIPON NSPYIPOR NSPYIPRF NSPYIPRO NSPYIPRR NSPYIPRT
NSPYIPSD NSPYIPUP NSPYIPVE NSPYTSSW NSPYUDDC NSPYUINE
NSPYUNOP NSPYUOUD NSPYURBS NSPYUSBS
Thanks to Leon Schiebel, IBM Global Services, CANADA.
Thanks to Nick Varvarigos, IBM Global Services, CANADA.
Thanks to Norman Hollander, CA, USA.
Change 22.311 Support for OS/400 5.3.0 for QAPMCONF, QAPMDISK, QAPMPOLL
VMACQACS and QAPMJOBL data files/data sets.
Dec 10, 2004
Thanks to Paul Gillis, Pacific Systems Management Pty, AUSTRALIA.
Thanks to Clayton Buck, UniGroup, Inc, USA.
Change 22.310 An OPTIONS SOURCE; statement inserted to circumvent a SAS
ANALRMFR V8 compiler error under Win98 caused a compiler error on
Dec 10, 2004 z/OS with SAS 9.1.3. Using a conditional test resolved.
Thanks to Steve Gear, Schneider National, INC.
Change 22.309 Change 22.302 revised the IBM File Transfer segment code
VMAC6 to support VPS, but I failed to test with IBM data after
Dec 8, 2004 the revision, causing INPUT STATEMENT EXCEEDED, on IBM
data. I was misled by IBM doc that said the SMF6PQLN was
the "length of the significant portion" of SMF6PRTQ but
it's DSECT length was 24 bytes, so I assumed 24 bytes.
It turns out that SMF6PQLN is the length of the field,
so the INPUT was restored to variable length, and code
knows that the VPS record does always have 24 bytes, and
the SMF6PQLN field is 0 in the VPS record. Both IBM and
VPS records have been tested with this change.
Thanks to George Waselus, State of Arizona, USA.
====== Changes thru 22.308 were in MXG 22.12 dated Dec 2, 2004=========
Change 22.308 Duplicate variable names in KEEP= list are detected by
VMACTDSL one of Freddie's many QA tests that read MXG source; most
Dec 1, 2004 were just duplicates, but the second instance of TDSL09PR
should have been TDSL09PN.
Thanks to Freddie Arie, TXU, USA.
Thanks to Jacky Hofbauer, Atlantica, FRANCE.
Change 22.307 MXG 22.10 & 22.11 only. Support for IRD was STILL wrong,
VMAC7072 causing PCTCPUBY, PCTMVSBY, CPUACTTM and other PCTxxxxx
Dec 1, 2004 to be wrong in ANY interval in which CPUs were varied by
Dec 2, 2004 IRD. If more than 33% of the engines were varied off,
some of those values could actually be negative values!
The revised NRCPUS calculation for IRD in Change 22.233
tested the LPARWLMG flag for the last LPAR (PHYSICAL)
instead of that flag for this MVS system's LPAR. Now,
the correct LPAR's flag is used, and variable LPARWLMG
is kept in TYPE70 dataset so you can tell when IRD is
managing this system's CPUs. This change also protects
for manual vary of engines when IRD is not in control.
The magnitude of the numeric error depended on what pct
of the engines were offline; my IRD test data had 12
CPUs, and only 1-2 were offline, masking the problem;
it took negative values to cause me to see my errors.
Thanks to Dan Case, Mayo Foundation, USA.
Change 22.306 Support for CICS/TS 3.1: INCOMPATIBLE, as ALWAYS, since
EXCICPIR IBM CICS Development continues to insert fields in the
EXCICPIW middle of the existing SMF 110 subtype 1 CICSTRAN record.
EXCICWBG -New variables added to CICSTRAN dataset:
EXCICWBR DSCHMDCN='DSCHMDLY*COUNT'
FORMATS DSCHMDTM='DSCHMDLY*DURATION'
IMACCICS ICSTACCT='LOCAL*IC*START*REQUESTS'
VMAC110 ICSTACDL='BYTES IN*START CHANNEL*REQUESTS'
VMXGCICI ICSTRCCT='INTERVAL*CONTROL*START*CHANNEL*REQUESTS'
VMXGINIT ICSTRCDL='BYTES IN*CONTAINERS*START*CHANNEL REQS'
Nov 30, 2004 L9CPUTCN='L9CPUT*COUNT'
Dec 10, 2004 L9CPUTTM='L9CPUT*DURATION'
Jan 2, 2005 MAXSTDCN='MAXSTDLY*COUNT'
MAXSTDTM='MAXSTDLY*DURATION'
MAXXTDCN='MAXXTDLY*COUNT'
MAXXTDTM='MAXXTDLY*DURATION'
PCDLCRDL='BYTES IN*DPL RETURN*CHANNEL'
PCDLCSDL='BYTES IN*DPL REQUESTS*ISSUED'
PCDPLCCT='DPL*REQUESTS*ISSUED'
PCLNKCCT='LOCAL*PROGRAM*LINK*REQUESTS'
PCRTNCCT='REMOTE*PSEUDOCONV*RETURN*REQUESTS'
PCRTNCDL='BYTES IN*PSEUDOCONV*CONTAINERS'
PCXCLCCT='PROGRAM*XCTL*REQUESTS*ISSUED'
PGBRWCCT='BROWSE*CHANNEL*CONTAINER*REQUESTS'
PGGETCCT='GET*CONTAINER*REQUESTS'
PGGETCDL='BYTES IN*GET CONTAINER*CHANNEL*COMMANDS'
PGMOVCCT='MOVE*CONTAINER*REQUESTS'
PGPUTCCT='PUT*CONTAINER*REQUESTS'
PGPUTCDL='BYTES IN*PUT CONTAINER*CHANNEL*COMMANDS'
PGTOTCCT='CHANNEL*CONTAINER*REQUESTS'
WBBRWOCT='BROWSE*HTTPHEADER*REQUESTS'
WBCHRIN1='BYTES*RCVD FOR*RECEIVE OR*CONVERSE'
WBCHROU1='BYTES*SENT FOR*SEND OR*CONVERSE'
WBIWBSCT='WBIWBSCT'
WBPARSCT='PARSE*URL*REQUESTS'
WBRCVIN1='RECEIVE OR*CONVERSE*REQUESTS'
WBREDOCT='READ*HTTPHEADER*REQUESTS'
WBSNDOU1='SEND OR*CONVERSE*REQUESTS'
WBWRTOCT='WRITE*HTTPHEADER*REQUESTS'
X8CPUTCN='X8CPUT*COUNT'
X8CPUTTM='X8CPUT*DURATION'
X9CPUTCN='X9CPUT*COUNT'
X9CPUTTM='X9CPUT*DURATION'
-New SP, L9, X8, and X9 TCBs exist in CICS/TS 3.1 and CPU
time for each TCB is in CICSDS and CICINTRV datasets. The
full list of CICS TCBs are:
TCB VAR PREFIX DESCRIPTION
QR DSG QUASI REENTRANT MODE
RO DS2 RESOURCE OWNING MODE
CO DS3 CONCURRENT MODE
SZ DS4 SECONDARY LU MODE
RP DS5 ONC/RPC MODE
FO DS6 FILE OWNING MODE
SL DS7 SOCKETS OWNING MODE (SL)
SO DS8 SOCKETS OWNING MODE (SO)
J8 DS9 J8 - OPEN MODE
L8 DSA L8 - OPEN MODE
S8 DSB S8 - SOCKETS (SSL) MODE
H8 DSC H8 - NOT IN CICS/TS 3.1+
D2 DSD D2 - DB2 MODE
JM DSE JM - JVM CLASS CACHE MODE
J9 DSF J9 - OPEN MODE
SP DSH SOCKETS PTHREAD OWNING MODE (SP)
L9 DSI L9 - OPEN MODE
X8 DSJ X8 - OPEN MODE
X9 DSK X9 - OPEN MODE
-New variables in CICCONSR Statistics Dataset (STID=52):
A14ESPCN A14ESPCS A14ESPCR A14ESTCN A14ESTCS A14ESTCR
A14ESICN A14ESICS A14ESICR
-New DS4 variables for H8 POOL statistics are added to
dataset CICDSPOO (STID=60).
-Four new Statistics Datasets are created; the full list
of all STIDs and their datasets is in ADOCCICS member:
MXG Symbolic
Dataset IBM
Name STID Description of Data Set Name
CICWBG 101 URIMAPS (Global) STIWBG
CICWBR 104 URIMAPS (Resource) STIWBR
CICPIR 105 PIPELINE (Resource) STIPIR
CICPIW 106 WEBSERVICE (Resource) STIPIW
Change 22.305 INVALID NUMERIC DATA, 'TOTALS:' AT LINE ... COL ... and
EXXAMSYT INVALID NUMERIC DATA, 'TOTAL:' AT LINE ... COL ... and
Nov 30, 2004 NOTE: CHARACTER VARIABLES HAVE BEEN CHANGED TO NUMERIC...
due to IF NOT UPCASE(NAME)='TOTAL:' THEN DO; syntax.
Using IF NOT (UPCASE(NAME)='TOTAL:') THEN DO; or
using IF UPCASE(NAME) NE 'TOTAL:' THEN DO; corrects.
Thanks to Rodger Foreman, Acxiom, USA.
Change 22.304 Support for subtype 45 (PAGE SWEEP LIMIT EXCEEDED) record
EXHRN45 in ObjectStar SMF user records.
IMACHURN The pdf documentation of this subtype is incorrect.
VMACHURN The first 64 bytes of the HU45MSG field are decoded into
VMXGINIT un-labeled variables HU45H1-HU45H5 (hex), HU45C1-HU45C3
Nov 30, 2004 (EBCDIC text) and HU45N1-HU45N5 (numeric values).
Thanks to Mark King, S.A. Dept of Human Services, AUSTRALIA.
Thanks to Robyn Mcgeachie, S.A. Dept of Human Services, AUSTRALIA.
Change 22.303 -MXG Change 21.251 added support for the optional new data
VMACSASU in the SAS user SMF record, but MXG code was off by one
Nov 29, 2004 byte, causing the last digit of JESNR to be lost.
-SAS Version 9.1.3 has SASVEREL ' 9.10', which SAS sets
for all 9.1 images (9.1.0 1MO, 9.1.0 1M2, and 9.1.0 IM3),
and that will also be the value when SAS releases the new
Service Pack levels starting with SP1.
-The ENTRY had to be changed to SMFEXIT3 in BASMF job to
create the optional 64 bytes in the SMF User Record.
//SYSLIN DD *
INCLUDE SYSLIB(SMFEXIT)
ENTRY SMFEXIT3
NAME SMFEXIT(R)
Thanks to MP Welch, SPRINT, USA.
Thanks to Wilson Chen, SPRINT, USA.
Thanks to Tom White, SPRINT, USA.
Change 22.302 Support for VPS V1 R8.0 VPS-FAX, which uses the PrintWay
VMAC6 file transfer segment to add information for TCP/IP print
Nov 29, 2004 devices. Minor revision to MXG coding for that existing
segment will populate existing variable SMF6URI with:
mailto:email address (primary recipient)
lpr://hostname/queue
lrsq://hostname:port
direct_sockets://hostname:port
Thanks to Peter Harmut, R + V Versicherung, GERMANY.
Change 22.301 Use of ZEROOBS= parameter could fail due to incorrect
UTILBLDP tests for length of operands; using MACFILEX= option did
Nov 29, 2004 circumvent the MXG coding error.
Thanks to Willy Iven, Fortis Bank Belgium, BELGIUM.
Change 22.300 Using the FTP access method to read SMF data from one MVS
VMACSMF system when MXG executes on a different MVS system fails
VMXGINIT with "ERROR 23-2: INVALID OPTIONS NAME JFCB" because MXG
Nov 26, 2004 needs JFCB=SMFJFCB on the INFILE SMF statement so that
either BSAM or VSAM SMF file can be read transparently,
but the FTP access method does not support that option.
Since that option is needed only to read VSAM SMF data,
and since the ftp access method itself does not support
reading any VSAM file, and because there is no way to
know that you have allocated your SMF filename using the
ftp access method, the solution is to create a macro
variable &MXGJFCB in VMXGINIT that is initialized to the
string JFCB=SMFJFCB by default, and use that macro
variable in VMACSMF instead of the hard-coded option.
Then, if you want to use the FTP access method to read
SMF data from a different MVS system, you can eliminate
the SAS error by using
%LET MXGJFCB= ;
to remove the JFCB option from MXG's INFILE statement.
Thanks to MP Welch, SPRINT, USA.
Thanks to Maurice Pascal, ???, ???
Change 22.299 -STORHWMH and STORHWMK were defined in both _KUOWCIC and
VMXGUOW _KUOWCICX, but they are high water marks (maxima) and so
Nov 26, 2004 should only have been maximized.
-Macro _SUOWTMO did not correctly handle max and mins;
macros _KUOWCIX and _KUOWCIN were inserted after _KUOWIDC
and _KUOWCIC as was done in _SUOWCIC.
-Macro _SUOWTMO was reading the CICSTRAN dataset and not
MONITASK; SET _LCICTRN was changed to SET _LMONTSK.
Thanks to Erling Andersen, SMT Data A/S, DENMARK.
Change 22.298 MXG 22.11 only. A missing @; caused SMF type 6 records
VMAC6 with the "PrintWay" File Transfer Section to fail with
Nov 22, 2004 INPUT STATEMENT EXCEEDED error
Thanks to Randy Shumate, LEXIS-NEXIS, USA.
Change 22.297 Short 'IF' NDM/CDI record caused INPUT STATEMENT EXCEEDED
VMACNDM error; instead of the expected 64 byte NDMRUID, there
Nov 17, 2004 were only 45 bytes at the end of the record. INPUT of
NDMRUID is now conditional if it exists.
Thanks to Bernie Mazur, Bank of Montreal, CANADA.
Change 22.296 Processing CMRDETL data on ASCII platform failed because
VMACMVCI the INFILE statement and VMXGRFV attributes contained the
Nov 17, 2004 BLKSIZE= parameter, which is not supported on ASCII:
Perhaps ASCII SAS should be smart enough to disregard,
instead of fail, but since ASCII files are nothing but
a single string of bytes, BLKSIZE has no meaning there.
Thanks to Steven Olmstead, Thompson, USA.
Change 22.295 Variable ACCIPAD, IP Address, is now output in WSFEVTPR
VMACWSF as well as WSCEVTSC.
Nov 16, 2004
Thanks to Stephane Attouz, Infosud, FRANCE
Change 22.294 -Support for APAR PQ73385 which adds data to IFCID 217 and
VMAC102 to IFCID 225.
VMACDB2 -Support for APAR PQ87848 which adds data to IFCID 173 to
Nov 12, 2004 monitor Dynamic SQL Statements that exceed RLF ASUTIME
Limit (and issued SQLCODE905).
-Support for APAR PQ91101 which adds more data to IFCID
225, and which added QISESTMT to DB2ACCT dataset.
Change 22.293 In PDB.ASUM70PR and PDB.ASUMCEC, all LP0xxxxx variables
VMXG70PR for LPARNAME='PHYSICAL' are always missing values; at one
Nov 9, 2004 time, Amdahl used zero for a real LPAR, so MXG test for
LPARNAME didn't populate LP0xxxx variables unless it was
a real Amdahl LPARNUM=0). But since Amdahl is now long
gone, it makes sense to populate the PHYSICAL LPAR data
in the LP0xxxx variables for consistency and so that the
newer PDB.ASUM70LP dataset can contain the data for the
LPARNAME='PHYSICAL'. In PDB.ASUM70PR and PDB.ASUMCEC,
the existing LPPUPDTM and PCTPOV variables are unchanged,
and the calculations that included LPPUPDTM and LP0UPDTM
are revised to not double account the PHYSICAL time.
Thanks to Anthony Lobley, EDS, ENGLAND.
Change 22.292 Debugging PUT statement is no commented out.
VMACSFS The Xerox SFS architecture is being replaced by an export
Nov 8, 2004 file produced by the Xerox Docutech 6135 network printer.
Thanks to Robert McElhaney, Texas Workforce Commission, USA.
Change 22.291 -Concatentating TNG files from multiple systems caused
VMACTNG incorrect results when the sets of fields were different;
Nov 8, 2004 values from the first system could be propagated into the
subsequent system's output, because the initialization DO
loop limit had the instance macro (&NT018I for example)
but the upper value should be %EVAL(&NT018I*&MAXROWS).
In addition, the init of the NTxxxINM variables had to be
relocated into their own DO loop.
-New NT Platform Names of NTW400I, WNS502I, and XPP501I
are all supported.
-Also, NT Platform Names are now defined in a new _NTPLAT
macro, so that new TNG names can be added in only one
place, or can be added in your IMACKEEP member.
Thanks to Peter Krijger, ANZ National Bank Limited, NEW ZEALAND.
Change 22.290 Enhancement for MQM processing creates new IHDRMQM exit
IHDRMQMH that can be used to select MQ records using variables
VMAC115 MQMSSSID SUBTYPE SYSTEM STARTIME
VMAC116 SM115REL (blank if ID=116)
VMXGINIT SM116REL (blank if ID=115)
Nov 5, 2004 Either member IHDRMQMH can be edited with your selection
logic, or %LET MQCMQMH= %QUOTE(your code;); can be used.
The existing TYPENQM member will process both SMF 115 and
SMF 116 records in one pass.
Thanks to Helmut Roese, COM Software, USA.
Change 22.289 The PDB.RMFINTRV dataset could have duplicate obs for the
VMXGRMFI first hour, if your RMFINTRV logic summarized your detail
Nov 5, 2004 RMF data (e.g., written at 15 minutes, but you tailored
IMACRMFI or your RMFINTRV memer to create HOURLY data),
but only if some SMF records for that interval were in
yesterday's SMF and the rest of that interval's records
were in today's SMF data. The MXG logic to calculate the
MSU4HRAV was at fault, incorrectly combining the data in
SPINRMFI with today's data.
Thanks to Normand Poitras, IBM Global Services, CANADA.
Change 22.288 Comments in CICINTRV show how to create PDB.CICINTRV from
CICINTRV SMF data; CICINTRV is automatically included by TYPS110
VMAC110 and by BUILDPDB/BUILDPD3.
Nov 5, 2004 Default in VMAC110 now creates WORK.CICSACCT instead of
PDB.CICSACCT, so that a //PDB DD is not required if you
run %INCLUDE SOURCLIB(TYPE110). CICSACCT has had zero
observations for years, but historically was written to
the //PDB library.
Thanks to Neil Ervin, Charles Schwab, Inc, USA.
Change 22.287 Enhanced %VMXGPRAL utility. New option to run PROC FREQ
VMXGPRAL can be used to find out who's writing DB2 SMF 102 Trace
Nov 4, 2004 Records with this example:
%LET MACDB2H %QUOTE(KEEP QWHSSSID QWHSLUNM QWHSLOCN;);
%READDB2(IFCIDS=ALL);
%VMXGPRAL(DDNAME=WORK,NOBS=MAX,NOFREQ=FREQ,
NOPRNT=NOPRNT,NOMEANS=NOMEANS);RUN
- Note: the KEEP statement should almost never be used,
but it turns out that by using MACDB2H to insert
that statement inside the READDB2 processing,
only those variables listed will be output, so
the Trace Datasets won't take much disk space.
I first kept QWHCCV and QWHCCN, but the SMF 102 trace
records do not contain the Correlation Header.
Thanks to Hoang Ho, Experian, USA.
Change 22.286 -Two variables were not converted to EBCDIC when MXG was
VMAC80A executed on ASCII platforms:
Nov 4, 2004 RACF07DT ENTITYNM
Nov 5, 2004 -Support for RACFTYPE=29 DTP adds variable RACF29AD to the
Nov 8, 2004 TYPE8020 and TYPE8021 datasets.
Nov 9, 2004 -RACFTYPE=42 DTP segment variable CLASNAME was not kept.
Nov 10, 2004 In almost all datasets with variable CLASNAME, it comes
Dec 10, 2004 from DTP=17 segments. But datasets TYPE8024 and TYPE8X24
Dec 7, 2006 can have CLASNAME from DTP=21 and/or DTP=42 segments:
- TYPE8024 dataset can have both 21 and 42 segments, and
can have more than one DTP=42 segment, so that dataset
contains variables CLASNAME,CLASNAM1-CLASNAM4 from any
DTP=42 segments, and variable CLASNA21 from DTP=21s.
- TYPE8X24 dataset contains only DTP=21 segments, so the
variable name kept is CLASNA21, so as to matches the
name in the related TYPE8024 dataset.
This text was revised 2006, no code was changed.
-Multiple RACFTYPE=24 DTP segments, up to fifteen, are now
supported in RALTER (TYPE8020) and RDEFINE (TYPE8021) in
variables RESBYTE1-RESBYTEF and RESNAME1-RESNAMEF, like
the handling of multiple RACFTYPE=44 DTP segments in the
ADDUSER (TYPE8010) and ALTUSER (TYPE8013) datasets. The
choice of 15 is arbitrary, and could be increased if it
is needed, or a secondary dataset could be created in the
future if there are many more repeated segments in one
SMF 80 record.
-Multiple RACFTYPE=25 DTP segments in RALTER/DELMEM are
also supported, as above.
-Note that some cases of multiple segments currently will
be created as separate observations in additional data
sets, rather than separate variables. Specifically:
Dataset Command Multiple Segments
TYPE8X13 ALTUSER 40s
TYPE8Y13 ALTUSER 41s
TYPE8X24 SETROPTS 21s
-Dataset Label for TYPE8X13 and TYPE8Y13 were corrected to
ALTUSER (incorrectly had SETROPTS).
-Variable RACF07DT is now correctly input and it length is
set at $80 to hold installation data.
-Variable RESBYTE uninitialized was corrected.
Thanks to Erling Andersen, SMT Data A/S, DENMARK.
Thanks to Larry Krause, Rite-Aid, USA.
Change 22.285 Label values for two variables were incorrect/incomplete
VMAC7072 and are revised to this description:
Nov 3, 2004 PCTDLCDE='CPU DELAY*PERCENT*NOT INCLUDING*WLM CAP'
PCTDLPDE='PCT WHEN*RESOURCE GROUP*MAXIMUM*ENFORCED'
And PCTDLPDE is not a delay; only PCTDLCDE will show
if there actually was a delay.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 22.284 Allocation Recovery subtype 7 (TYPETARC) support was not
FORMATS correct for variables after TARCDSN, now revised to match
VMACTMNT the DSECT. But the SMF records are not always correct;
Nov 2, 2004 many have 0 for DEVNR and following fields, all have ACTN
value 0, and ASID is only two bytes. Those errors in the
SMF record will be corrected in the next ASMTAPEE.
Thanks to Doug Medland, IBM Global Services, CANADA.
Change 22.283 Cosmetic. Error BIT MASK ... TOO LONG caused examination
VMAC1415 of all bit tests and three members were found to have
VMAC63678 bit literals that were not 8 or 16 symbols; fortunately,
VMACF127 none of those tests are currently executed, but the code
Nov 2, 2004 was revised nonetheless:
-TYPE1415 - bad test was inside ISAM code, not used now!
-TYPE6367 - VSAM catalog records no longer exist.
-TYPEF127 - FACOM operating system, probably defunct.
Change 22.282 Variable DATETIME was missing, because MXG code to create
ASUMHSM it from REQUEST was located before REQUEST was created;
Nov 2, 2004 this caused WHERE clause errors in a tailored IMACSHFT
Nov 5, 2004 member that used WHERE clauses and did not expect missing
values in DATETIME (nor should it have, since the error
was in MXG, not in the tailored IMACSHFT!).
-SUMBY FSRTYPE SHIFT logic in the internal invocations of
ANALCNCR had to be revised to remove SHIFT from SUMBY, as
it conflicted with SYNCINTV=YES default in ANALCNCR, and
the recalculation of SHIFT was relocated. This change
also corrected deeper errors, and the number of output
observations in PDB.ASUMHSM is now correct.
Thanks to Karl Lasecki, Chemical Abstracts, USA.
Thanks to Bruce Zink, Honda of America Manufacturing, USA.
Change 22.281 RACF SMF80DTP 44 segment with only SEGNAME and no text
VMAC80A caused *** RACF EV(44) ERROR. INVALID RACFDLNN=0 and
Nov 1, 2004 NOTE: INVALID THIRD ARGUMENT TO FUNCTION SUBSTR... and a
hex dump of each record. Code revised to protect zeroes.
Thanks to Ike Hunley, Blue Cross Blue Shield of Florida, USA.
Change 22.280 NRCPUS calculated in PDB.RMFINTRV using SMF70ONT could
VMXGRMFI have fractional values (0.999) instead of an integer when
Oct 29, 2004 IRD was not involved; the calculation was revised to add
0.005 and FLOOR/1000 to produce the expected integer.
Note that with IRD, fractional NRCPUS is very legitimate.
Thanks to Thomas Heitlinger, FIDUCIA IT AG, GERMANY.
Change 22.279 Member TYPEVTOC is no longer executed in the test stream;
TESTOTHR it caused 0C4s under SAS V9 because of CCHHR= operang,
Oct 28, 2004 but it has been archaic ever since DCOLLECT/TYPEDCOL was
released. Because it is no longer in the test stream,
the three datasets it created VTOCLIST,VTOCMAP,VTOCINFO
will no longer be documented in DOCVER.
Thanks to Randy Shumate, LEXIS-NEXIS, USA.
Change 22.278 In (archaic) VMAC90, variable SMF9029N was changed from
VMAC90 character to numeric in Change 21.320, but if you combine
Oct 28, 2004 TYPE90 built before and after that change, you got the
ERROR: VARIABLE SMF9029N HAS BEEN DEFINED AS BOTH CHAR...
This change replaces SMF9029N with SMF9029X to avoid that
error, but use of VMAC90A is the preferred solution.
Thanks to Andreas von Imhof, Rabobank, THE NETHERLANDS.
====== Changes thru 22.277 were in MXG 22.11 dated Oct 26, 2004=========
Change 22.277 New argument MACFILEX allows you to insert SAS code after
UTILBLDP the SMF header has been read (like MACFILE), for user
Oct 26, 2004 tailoring of what records to read or not to read.
Change 22.276 A utility to analyze the size of SAS data libraries, with
ANALSIZE the number of datasets, number of variables, data bytes,
VMXGSIZE compressed bytes, and average compression percentages.
Oct 26, 2004
Thanks to Chuck Hopf, MBNA, USA.
Change 22.275 The array LCUZ in data step C4 was changed to LCU1-LCU256
ANALPATH and the final report will show up to 256 LCUs if present.
Oct 26, 2004
Thanks to Harald Seifert, HUK Coburg, GERMANY.
Change 22.274 Variables TOTSHARE and TOTSHARC are now kept in both the
VMXG70PR PDB.ASUM70PR and PDB.ASUMCEC so the original and current
Oct 26, 2004 total Weights are available; for summary intervals that
Oct 27, 2004 had more than one RMF record, the weights from the first
record are kept.
Thanks to Chuck Hopf, MBNA, USA.
Change 22.273 The variable PCTCPUBY in QAPMSYST is now set to a missing
VMACQACS value, because there is no "total" CPU busy in QAPMSYST;
Oct 26, 2004 it is still kept so your report programs won't fail with
VARIABLE NOT FOUND errors, but set missing because it was
calculated from SHCPUTM, which is only the SystemTask CPU
time. New PCTCPTBY='PERCENT WHEN*SYSTASK*CPU BUSY' is
now calculated from SHCPUTM.
Thanks to Chris Selley, Zurich, ENGLAND.
Change 22.272 Support for zAAP IFA engines now requires MXG 22.11 due
VMAC30 to this change and change 22.265.
VMAC7072 =TYPE72GO Corrections:
Oct 25, 2004 -New zAAP CPU time CPUIFETM was incorrectly adjusted with
R723NFFI from R723IFCT, but IFCT is the time when zAAP-
eligible work executed on a CP, and that work executes at
the CPU speed, so the NFFI adjustment in MXG was wrong.
-Label CPUIAFTM='IFA*EQUIVALENT*CPU TIME' more accurately
describes the contents of that MXG variable.
-Variables R723IFCT (now, always equal to CPUIFETM), and
R723IFAT (unadjusted, equal to CPUIFATM ONLY if R723NFFI
is 256, and hence probably more confusing that useful),
are both now kept in TYPE72GO dataset.
-Calculation of IFAUNITS, IFEUNITS was corrected, and the
code to subtract IFAUNITS from CPUUNITS was relocated.
=TYPE30 Corrections:
-All TYPE30 IFA/IFE CPU times were wrong: I could blame
IBM, because there are two undocumented bytes after the
SMF30TF2 field that caused misalignment (but my +2 after
the SMF30TF2 was also wrong, it is now +1 for the second
byte of TF2, but now there's a new +2 needed to skip over
those undocumented two bytes). However, my guess that the
new times were like the immediately preceding SMF30CEP
field (input PIB4.6, multiply by 1024) was also wrong;
the new CPU times are PIB4.2 without the multiply).
And the offsets in the SMF manual are wrong starting at
SMF30TF2. (In my defense, Change 22.221 did note that the
changes had NOT been tested with data!).
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Thanks to Adam Warkow, Citigroup Technology Infrastructure, USA.
Change 22.271 The Macro _LOGSMF, used to read log files (like NDM/CDI)
VMACSMF that have "SMF Records" without the SMF Header, did work
Oct 23, 2004 when last tested, but DATA STEP STOPPED DUE TO LOOPING
error occurred using the TYPENDML example! Inserting
INPUT @; after the ELSE DO; appears to now be required
by SAS, and eliminated that error.
Thanks to Albert Jacobs, KBC, BELGIUM
Change 22.270 22.08-22.10 only. INPUT STATEMENT EXCEEDED RECORD LENGTH
VMACDB2H error with DB2 V8.1 SMF 100/101 records. INPUT of new
Oct 23, 2004 variable QWHSLOCO was PIB4, but the field is only PIB2.
Thanks to Roman Jost, ERGO Integration, NORWAY.
Change 22.269 MXG 22.07-22.10. Six variables in TYPE71 dataset:
VMAC71 LPAPGMN LPAPGMX LPAPGAV LPAFXMN LPAFXMX LPAFXAV
Oct 23, 2004 had missing values, because an extraneous "V" was added
to each variable name in its INPUT statement, when I had
added the IBM SMF field name in comments on each line.
Thanks to Matthew Chappell, Queensland Transport, AUSTRALIA.
Change 22.268 Support for VTS R7.3 adds many statistics to TYPE94 and a
FORMATS few to TYPE94P; some 2-byte fields were expanded to four
VMAC94 bytes, but existing, reserved bytes were used for the
Oct 23, 2004 expansion, so the changes are compatible. You can tell
Oct 27, 2004 that R7.3 has been installed because S94LVVCF=730.
Oct 27: MXG 22.11 input these fields as $HEX2 per IBM doc
but IBM reports show them as decimal values, so
they were changed to PIB2 numeric variables:
S94LVVCM='VTS*CODE*MODIFICATION*VALUE'
S94LVVCF='VTS*CODE*FIX*VALUE'
S94LVLMV='LIBRARY*CODE*VERSION*VALUE'
S94LVLMR='LIBRARY*CODE*RELEASE*VALUE'
Change 22.267 The debugging PUT statement at line 745 should have been
VMACMVCI removed; it could flood sysout with millions of lines of
Oct 22, 2004 text: COL=390 T6ECPRID=F5 AFTER F4X
Thanks to Udo Froehline, Signal Iduna, GERMANY.
Change 22.266 Support for CMF Version 55.04 user SMF record (INCOMPAT).
VMACCMF INPUT STATEMENT EXCEEDED for CMF Version 5504 because the
Oct 22, 2004 BMC user SMF record removed four fields from subtype 1;
CMFREC01 was changed by BPM8956/BPM9152. MXG now INPUTS
those fields only for the old length of CMF01CSL=232.
Thanks to Peter Giles, Centrelink, AUSTRALIA.
Change 22.265 Support for APAR OA09118 adds the Service Definition
VMAC30 Coefficients (CPUCOEFF,SRBCOEFF,IOCOEFF,MSOCOEFF) into
Oct 22, 2004 the SMF type 30 records; these fields are needed now for
Oct 25, 2004 zAAP calculations, but have always been wanted in SMF 30.
-If the SDCs are in the SMF 30 record, variable IFAUNITS
will be non-missing, and variable CPUUNITS will contain
ONLY the CP TCB Service Units (i.e., IFAUNITS will be
subtracted from CPUUNITS if this APAR is installed).
-And if SDC values are present, the MXG-created variables
SRVTCBTM and SRVSRBTM will use the CPUCOEFF/SRBCOEFF from
the SMF record, rather than the &CPUCOEFF/&SRBCOEFF macro
default values of one, and CPUTOTTM will use the correct
SRVTCBTM/SRVSRBTM values. See text of Change 22.022.
-This change replaced Change 22.256.
====== Changes thru 22.264 were in MXG 22.10 dated Oct 13, 2004=========
Change 22.264 Variable QTGSUSLM in DB2STATS was not deaccumulated, so
VMACDB2 it have very large and meaningless values. DIF() logic
Oct 13, 2004 was added.
Thanks to John Shuck, Suntrust, USA.
Change 22.263 Revision of the original ANALDSET (DataSet Analysis) that
ANAL42DS uses the TYPE42DS interval records instead of TYPE1415
Oct 13, 2004 and TYPE64 close records. However, only SMS managed DISK
datasets are captured in TYPE42DS (but then ANALDSET only
reports on CLOSED datasets, so both may be necessary!).
Thanks to Chuck Hopf, MBNA, USA.
Change 22.262 Hardcoded DDNAME of PDB for PDB.DTSLOGPR and PDB.DTSCPU
VMACNTSM were replaced by their symbolic &PNTDTLP and &PNTDTCP.
Oct 13, 2004
Thanks to Matthew Chappell, Queensland Transport, AUSTRALIA.
Change 22.261 The token for dataset TYPE4237 was missing from the _N42
VMAC42 and _S42 macro definitions, so that dataset was not NULLd
Oct 13, 2004 if _N42 was used, or wasn't sorted if _S42 was used.
Thanks to Ambat Ravi Nair, ATOSORIGIN, SINGAPORE.
Change 22.260 -MXG Change 22.221 for z/OS 1.6 IFAs has now been tested
VMAC7072 with real IFAs and found wanting, causing negative values
Oct 12, 2004 in PCTCPUBY and incorrect CPUWAITTM (but only for systems
that actually have an IFA; there are NO errors using MXG
22.08+ with z/OS 1.6 if you do NOT have any zAAPs).
The code has been updated for all three configurations of
Shared/Dedicated and Wait Completion Yes/No, but only the
Shared, Wait Complete=NO data has been validated.
-New variable MXGCIN in TYPE70PR is an attempt to identify
IFAs (which have SMF70CIN='ICF') from ICFs, with values:
'PHY' - Physical
'CP ' - CP Engine
'VM ' - VM Engine
'IFA' - IFA Engine
'ICF' - ICF (Coupling Facilit) or IFL (Linux) Engine
' ' - SPARE Engine
but this is a heuristic algorithm based on my test data,
but could use validation with your system's data.
-New variables IFACROSS and IFAHONOR are now kept in the
TYPE72GO dataset, where they are created, instead of the
TYPE70 dataset, where I originally kept them.
However: it really makes no sense for IBM to have put
the global parameters in the service-class TYPE72GO
records, but since that's where IBM put them, I have
to do the same.
-I originally spelled IBM field R723IFCU as R723IFEU in
TYPE72GO dataset, trying to use "IFE" for IFA-Eligible
and "IFA" for IFA-Actual, but the variable name is now
changed back R723IFCU to be consistent with the IBM name.
-The test data was from an early system, and these notes
may not be relevant to current IFAs, but are documented
in case these data are observed:
- During Startup Interval, the IFAWAITM is slightly
larger (tenths of a second) than the Interval Duration
which causes PCTIFABY to be slightly negative. While
I could detect and set PCTIFABY to zero, I will wait
to see if this is actually necessary with your data.
- The PHYSICAL LPAR data has LCPUADDR values that are
totally unexpected: 0,2,5,7,8,10,12,14,16,18,21,23,24,
26,28,30,32,34,37,39,40,42,44,46,48,50,53,55,56,60,62
for the 32 engines! While this has no impact, it does
look strange; IBM says its working as designed.
- Update from Martin Packer, Oct 17, 2005:
It turns out there is an explanation: when LCPUADDR
is displayed as a hex value, the first nybble is the
book number minus one, the second is the CPU number.
So the values above are for book 1 thru book 4, with
hex CPU numbers of 00,02,05,07,08,0A,0C,0E
-See Change 22.272, which corrected further errors and is
required for zAAP IFA processors.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 22.259 Variable NDMCPUTM had missing value in NDMPT dataset; a
VMACNDM circumvention now detects that "CPUTIME=" text is present
Oct 12, 2004 and inputs NDMCPUTM.
Thanks to Andreas von Imhof, RaboBank, THE NETHERLANDS.
Change 22.258 All TRND.... members were enhanced with macro variables
TRND.... &TRENDINP, &TRENDNEW, and &TRENDOLD (all of which are set
Oct 12, 2004 to "TREND" by default) so that you can override the MXG
default, and create a new TREND library, instead of reuse
(so that your TREND libraries can be GDGs, which is
required for CA's 11 job recovery product).
-Summarization of DB2ACCTB (Buffer used by Plans) should
have had WEEK.DB2ACCTB instead of WEEK.DB2ACCT.
Thanks to Chuck Hopf, MBNA, USA.
Change 22.257 Summarization of MXGTMNT Tape Mount Monitor data can now
ASUMTMNT alternatively use the STK VSM STCVSM13 and STCVSM16 data
Oct 11, 2004 sets as input. Comment blocks must be removed, and you
must provide a way to identify the VSM devices.
Change 22.256 This change was replaced by Change 22.265.
VMAC30
Oct 11, 2004
Change 22.255 MXG format $MGSASPR, which maps the SAS procedure name to
FORMATS SAS Product Name, was updated for alternative spellings
Oct 11, 2004 (eg., SUMMERY for SUMMARY). The SMF record contains what
name was typed in, but when incorrectly spelled, SAS can
often "guess" the correct procedure name, leaving the
wrong spelling in the SMF record.
Thanks to Dr. Alexander Raeder, Itellium, GERMANY.
Change 22.254 False ***ERROR.INVALID TYPE42 SUBTYPE 5 RECORD DELETED
VMAC42 message caused only the last entry for that VOLSER to be
Oct 11, 2004 not output in TYPE42VT dataset; all other entries were
correctly output. Three tests for invalid length were
revised: each needed "-4" to be added to each test:
IF 0 LT S42VTVDO LT COL OR S42VTVDO+S42VTVDL-4 GT LENGTH
0 LT S42VTVXO LT COL OR S42VTVXO+S42VTVXL-4 GT LENGTH
0 LT S42VTVVO LT COL OR S42VTVVO+S42VTVVL-4 GT LENGTH
Thanks to John Parkes, Experian, USA.
Change 22.253 Change 22.211 required BLDNTPDB/BLDSMPDB invocation text
BLDNTPDB in your source code to be all lower case, but internal
Oct 11, 2004 code in BLDNTPDB was incorrect; using upper case text
in your invocation caused errors in the Week and Month
selection.
Thanks to Terry Heim, ECOLAB, USA.
Change 22.252 Variable QW0258TS is revised; it is input TODSTAMP8. and
VMAC102 formatted as DATETIME21.2, and the divide by 4096 was
Oct 12, 2004 removed.
-All raw DB2 datetimestamps are on GMT clock, so each must
be converted to local by the addition of GMTOFFDB, and
then each must then be in a %VMXGTIME call (in case your
site uses %TIMEBILD to convert all times to a different
time zone). These variables were missing the GMTOFFDB
addition: QW0022TS,QW0022BT,QW0125TS,QW0316TS.
Also, extraneous refs for QW0260TS,QW0261TS,QW0262TS
were removed.
Thanks to Christa Neven, KBC, BELGIUM.
Change 22.251 Format $MGSTCMR, for the type of mount, had additional
FORMATS values '03'x thru '07'x that are now decoded.
Oct 10, 2004
Thanks to Gilles Fontanini, ABS Decision, FRANCE.
Change 22.250 Support for Release 3.5 of BETA93 product for subtypes
FORMATS 0, 1, 2, 3, and 5 has been revised and 0-3 validated:
VMACBETA -Dataset BETA1 new variables:
Oct 11, 2004 BETAPCR BETADCR BETAFRM BETAEXT BETAPDEF BETAFDEF
BETABTKN BETARBTK BETAREPR BETARMOD BETARUSR
- However, the new REPRINT variables BETARPUS, BETAREPR,
BETABTKN, BETARMOD, and BETARBTK appear to be trashed
in the SMF record, producing missing/strange values.
-Dataset BETA3 is now valid; most variables were missing.
-Dataset BETA5 new variables:
BETAFRM BETAEXT BETARPTN BETAWRPT BETALTKN BETARTKN
-Some inconsistent variable names (FRM2,FRMX,EXT2,EXTX)
were eliminated.
-Other subtypes will be validated when sample records are
received; some timestamps are now SMFSTAMP8 format, but
only real records will reveal their internal formats.
-The subtype 50 record still has not been validly created
so it is not yet supported.
Thanks to Graham Cornwell, Donovan Data Systems, ENGLAND.
Thanks to Klaus Messer, COMLAB GmbH, GERMANY.
Change 22.249 Support for TDSLink user SMF record creates 26 datasets:
EXTDS01F dddddd dataset description
EXTDS01I TDS01T TDSL01TC TCP REJECTED PORTS
EXTDS01M TDS01I TDSL01IC ICMP EVENTS
EXTDS01T TDS01F TDSL01FT FTP EVENTS
EXTDS01V TDS01X TDSL01XO XOT EVENTS
EXTDS01X TDS01V TDSL01VT VTAM EVENTS
EXTDS04 TDS01M TDSL01MV MVS EVENTS
EXTDS06 TDS04 TDSL04 XOT CONNECTIONS
EXTDS07 TDS06 TDSL06 TCP CONNECTIONS
EXTDS08 TDS07 TDSL07 IP INTERFACES
EXTDS09 TDS08 TDSL08 LOCAL APPLICATIONS
EXTDS0A TDS09 TDSL09 REMOTE APPLICATIONS
EXTDS0B TDS0C TDSL0C TCP/IP STACK
EXTDS0C TDS0A TDSL0A IP NETWORKS
EXTDS0D TDS0B TDSL0B ENTERPRISE EXTENDER/IP NODES
EXTDS0E TDS0D TDSL0D CSM BUFFERS
EXTDS0F TDS0E TDSL0E PING OBJECTS
EXTDS10G TDS0F TDSL0F MQ SERIES QUEUES
EXTDS10L TDS10X TDSL10XC XCA HEADER
EXTDS10M TDS10G TDSL10GR GROUP
EXTDS10P TDS10M TDSL10MX CROSS DOMAIN RESOURCE MGR
EXTDS10R TDS10P TDSL10PU PHYSICAL UNIT
EXTDS10S TDS10S TDSL10SK SKLETAL PHYSICALUNIT
EXTDS10X TDS10L TDSL10LU LOGICAL UNIT
EXTDS11 TDS10R TDSL10RX CROSS DOMAIN RESOURCE
EXTDS12 TDS11 TDSL11 CPU AND MEMORY
TYPETDSL TDS12 TDSL12 DISK
TYPSTDSL
VMACTDSL
VMXGINIT
Oct 7, 2004
Thanks to Khalid Meskinia, SAS France, FRANCE.
Thanks to Alain Delaroache, Atlantica (Credit Agricole), FRANCE
Thanks to Jacky Hofbauer, Atlantica (Credit Agricole), FRANCE.
Change 22.248 ASUMCACH revised to tolerate zero obs in PDB.TYPE74CA.
ASUMCACH Previously, zero obs caused $CACHID format to not be
Oct 6, 2004 created.
Thanks to Jeff Harder, Indiana Farm Bureau, USA.
Change 22.247 Default test for Oracle SUBSYSID EQ 'OSDI' replaced the
VMACORAC SUBSYSID EQ 'TGW9' value, left after debugging. If you
Sep 30, 2004 re-define the _IDORACO macro in your IMACKEEP, it will
use your subsystem IDs, rather than the default in the
VMACORAC member, but 'OSDI' should have been the default
in the MXG code. See also change 20.111 text.
Thanks to John Rivest, TDS Corporate, USA.
Change 22.246 Support for Demand Technology's NTSMF Release 2.4.7.
VMACNTSM -MSEXCHANGEDSACCESS PROCESSES object, dataset MSEXPROC
Sep 30, 2004 has only seven variables, down from thirty nine.
-EPOXY object, dataset EPOXY, has two new variables.
-MSEXCHANGEIS MAILBOX object, dataset MSEXCHPU has six
new variables.
Change 22.245 -Support for Velocity Software's XAMAP Release 3.4, which
EXXAMSYT is INCOMPATIBLE, because new SYTCUP segment with LPARNAME
VMACXAM of "Totals:" had an invalid value for the number of LCPUs
Sep 30, 2004 causing INPUT STATEMENT EXCEEDED RECORD Length error if
Release 3.4 records are read without this change.
-The "Totals:" record is not output, as it duplicates the
CPU time in XAMSYT dataset, and caused 200% CPU busy's!
That tailoring code is externalized into the EXXAMSYT
exit member, if you ever decide you need it, unlikely.
-New variables are added to the XAMSYS dataset:
CPUCAPAB CPUCFGCT CPUCFGCT CPUCHAR CPUCOUNT CPUCOUNT
CPUDEDCT CPURESVD CPURESVD CPUSHARD CPUSTNBY CPUSTNBY
DEDCNT IOPCNT LPARCAF LPARNAME LPNUMBER MONECONH
MONECONL MONEVNTH MONEVNTL MONSAMPH MONSAMPL MONSCONH
MONSCONL SCPCAPAB SYSMMODL SYSMPOM SYSMSEQC SYSMTYPE
VL3CAF VL3CFGCT VL3COUNT VL3CPNAM VL3DBCT VL3MNAME
VL3RESVD VL3STNBY
-New variables added to the XAMSYT dataset:
CALPTIS LCUCWCPL LCUCCAPP LCPTYCP LCPTYICF LCPTYIOT
-Additional data from SUBSUM, PRCIOP, and IODVSW will be
added later, when someone asks to use the new data, or
I get bored/caught up. The preceding changes are all
that are needed to keep your current reports valid, and
add those new variables.
This note will be revised when that happens.
Thanks to Tony Curry, BMC, USA.
Change 22.244 RACF REMOVE event, dataset TYPE8023, did not decode the
VMAC80A Data Type 6 segment; the OWNER/GROUP and bit variables
Sep 30, 2004 are now created.
Thanks to Robert D. Mitchell, UBS, USA.
Change 22.243 INPUT STATEMENT EXCEEDED if old VMACNSPY member (prior to
VMACNSPY Change 22.131) read a NETSPY record that is a NETMASTER
Sep 30, 2004 subtype. NETSPY and NETMASTER are now combined and write
Referenced: a single SMF record with both NSPY and NETM subtypes, and
EXNETM50 Change 22.131 added support to create both NETM and NSPY
VMXGINIT datasets from the single SMF record. However, messages
INVALID NETSPY SUBTYPE were printed with Change 22.131,
and NETMASTER datasets all had zero observations, because
the more robust test for NETMASTER subtype must be first,
and the test for a NETSPY subtype can be executed when it
is clear the record is not a NETMASTER subtype.
Note that TYPENETM will still process NetMaster subtypes
in the NETSPY record, but if you have added both NSPY and
NETM logic to your BUILDPDB, either VMACNSPY will ABEND,
because both want to create the five NETMxxxx datasets.
You should remove NETM tailoring and use only NSPY to
create both NSPYxxxx and NETMxxxx datasets.
-This VMACNSPY requires MXG 22.02 or later, because 22.02
contained Change 22.037, which created the new EXNETM50
member and updated VMXGINIT to support the new NETM5000
NetMaster dataset.
Thanks to Andy Creet, Department of Defence, AUSTRALIA.
Change 22.242 Example analysis provides Gartner Group with information:
ANALGART Batch Workload (e.g., MVS Batch Percentage CPU)
Sep 28, 2004 Interactive Workload (e.g., MVS/TSO Percentage CPU)
Online Workload (e.g., CICS,DB2,IDMS Percentage CPU)
across all partitions data.
The example assumes your Batch Work is in WORKLOAD=JES2,
TSO in WORKLOAD=TSO, Enclaves in DDF, CICS in CICS, so
you may need to tailor those definitions, and then it
reads your PDB library and build a tailored "RMFINTRV"
dataset named GARTNER, and print a summary report.
Thanks to Atle Mjelde, Ergo, NORWAY.
Change 22.241 Example summarization of the four IMF datasets:
ASUMCIMS PDB.ASUMIMTR : /*SUMMARY OF CIMSTRAN */
VMXGINIT PDB.ASUMIMDD : /*SUMMARY OF CIMSDBDS */
Sep 28, 2004 PDB.ASUMIMDB : /*SUMMARY OF CIMSDB2 */
PDB.ASUMIMPR : /*SUMMARY OF CIMSPROG */
Thanks to Ray Dorsing, Affiliated Computer Services, USA.
Change 22.240 Support for z/VM 4.4 INCOMPAT changes in SYTCUP record.
VMACVMXA New LCPTYPE='HARDWARE*CPU*TYPE' variable inserted in the
Sep 28, 2004 record is now supported. As no other errors with data
from z/VM 4.4 have been reported, I can claim "support"
with this change, but there could be new data variables
that are not yet decoded.
Thanks to Reinhard Lidzba, AGIS Allianz Dresdner, GERMANY.
Change 22.239 Member ERRORASC shows ASCII platform errors that occur if
ERRORASC you incorrectly download SMF data, and the member shows
Sep 28, 2004 how to use the %UDUMPEBC utility to determine what is in
the downloaded file, and how to resolve the cause of the
ERROR: Undetermined I/O failure.
ERROR: Unrecoverable I/O error detected...
This was originally in the undocumented "ERRORS" member,
but it contained unprintable characters that caused other
problems when that member was downloaded, so the revision
updated the contents and removed the unprintables.
Thanks to Dan Squillace, SAS Institute, USA.
Change 22.238 First pass at support for z/OS 1.4 SYSLOG file.
SYSLOG -Appends the type 'S' continuation record to create a
Sep 30, 2004 single event record
-Creates LOGGROUP sequence number for multi-record SYSLOG
events. See preliminary comments.
Please contribute suggestions for enhancements, as this
present implementation is still in first tests; some
important LOG events may be create new datasets, etc.
-Original example completely replaced.
Thanks to Freddie Arie, TXU Energy, USA.
Change 22.237 -To monitor STK tape devices with ML-31, you must use the
VMACTMNT XMEM=YES,MXIT=NO options when you assemble ASMTAPEE, to
Sep 27, 2004 capture the job-level information via Cross Memory calls.
Instead, for IBM tape devices, MXIT=YES,XMEM=NO is used
to eliminate Cross Memory calls and capture all mounts
in the IBM Volume Mount Exit - STK's HSC does not use
that exit, so you still have to use XMEM, until we can
find a usable HSC exit, research long underway.
Using the above options for STK caused DDNAME and STEPNR
to be blank/zero, because of a logic error in VMACTMNT:
The MXIT architecture captures these new variables:
ASID INITTIME JOBCLASS LOCLINFO PGMRNAME
RACFGRUP RACFTERM RACFUSER STEPNAME STEPNRX
TMNTACTN TMNTDEVC TMNTEDUR TMNTFLAG TMNTRCN
and these old variables:
DDNAME STEPNR
ML-31 SMF records have a new segment with those fields,
but they are not populated unless MXIT=YES was used;
MXG incorrectly INPUT those variables if the segment
was detected, causing the DDNAME/STEPNR fields in the
new segment overwrote the valid old . That logic was
corrected in this change.
-PDB.ASUMTAPE had missing values in RACFxxxx and ASID
variables because of the TYPETMNT error; that blank
DDNAME in TYPETMNT caused ASUMTAPE's merge of TYPETMNT,
TYPETALO, and IBM TYPE21 datasets to fail to correctly
propagate old ASID variables from TYPETALO into the
output PDB.ASUMTAPE dataset. Fixing TYPETMNT fixed.
Thanks to Normand Poitras, IBM Global Services, USA.
Change 22.236 New ANALFLSH member tracks how many flash copies are run
ANALFLSH in each 15 minute interval, as lots of parallel flashes
FORMATS can degrade performance. New format $MG022ST decodes the
VMAC22 copy status, and tests for LENGTH-COL were corrected to
Sep 26, 2004 use LENGTH-COL+1 for the bytes remaining in the record.
Since multiple records are written from multiple systems,
the ANALFLSH report must be tailored to select data from
only one system, since TYPE22_A dataset can have pseudo
duplicates. The sort order for TYPE22_A was changed to
SYSTEM SMFTIME SMF22CUA SMF22VOL to remove acutal dupes
when TYPS22 is used to sort TYPE22_A dataset.
Change 22.235 Support for ASG/Landmark TMON for DB2 Version 4.0.
VMACTMDB Only one dataset, TMDB7P appears to have been changed.
Sep 26, 2004
Thanks to Martin Legendre, Regie des Rentes du Quebec, CANADA.
=Drove to East Coast(NYC, NJ, DEL) then drove thru Hurricane Ivan in GA
=enroute to FLA (Wakulla County), then drove thru Hurricane Ivan again
=one week later in Shreveport, LA. Rain was 6 inches per hour, for
=about an hour both times, but traffic only slowed to 60 mph.
Change 22.234 Support for DB2 V8.1 IFCIDs 140,141,142,145 SQL text that
VMAC102 was relocated; without this change the QW014nTX variable
Sep 9, 2004 was blank even when there was SQL text in the record.
Thanks to Ep van der Es, Dow, BELGIUM.
Change 22.233 MXG's calculation of NRCPUS when IRD was NOT active could
VMAC7072 be very slightly wrong, calculating 2.0020 for 2 engines.
Sep 1, 2004 The use of NRCPUS=ROUND(SMF70ONT/DURATM,.001) was the
cause, but by replacing that calculation with
IF SMF70ONT GT 0 AND NRCPUS GT 0 AND LPARWLMG='Y' THEN
NRCPUS=SMF70BDA;
the correct IRD calculation (LPARWLMG='Y') is done, and
for non-IRD, MXG had correctly counted the integer number
of engines, which is unperturbed when LPARWLMG NE 'Y'.
Thanks to Al Sherkow, I/S Management Strategies, Ltd., USA.
Change 22.232 CMR time is added to the calculation of MPL74 time:
VMAC74 MPL74=SUM(DEVCONTM,DEVDISTM,DLYCMRTM)/DURATM;
Sep 1, 2004 Originally, errors in the CMR field in the record caused
it to be left out, but APARs have corrected the value.
This agrees with Cathy Cronin's "FICON and FICON Express
Channel Performance Version 2.0" IBM White Paper.
Thanks to Ray Waugh, Merrill Lynch, USA.
Change 22.231 If an NTSMF data set was unlabeled, using %BLDNTPDB with
EXNTDB2A RUNWEEK=WTD caused VARIABLE NOT IN DATASET errors. The
EXNTDB2D new PDB.DTSCPULP was build from two datasets by did not
FORMATS have a label.
IMACNTSM -FORMATS was updated with the $MGDDDDD and $MGDDDSN for
VMACNTSM all of the new NTSMF datasets.
VMXGINIT -DATABASE object with 170 fields support added.
Aug 31, 2004 -MSEXCHANGEIS object with 126 fields support added.
Sep 8, 2004 -DB2 DATABASE MANAGER (originally DB2 NT DATABASE MANAGER)
object with 28 fields is support added.
-New objects DB2 DATABASE and DB2 APPLICATIONS with 94 and
90 fields respectively create NTDB2DAT,NTDB2APL datasets.
Thanks to Terry Heim, ECOLAB, USA.
Change 22.230 Variable A17DTCFP, CFDT Pool Name was hex zeros rather
VMAC110 than blanks when there was no pool name. MXG now tests
Aug 30, 2004 and sets the variable to blanks instead of hex zeroes.
Thanks to Harald Seifert, HUK=COBURG, GERMANY.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 22.229 Cosmetic. ABNDRSNC TERMIND UNINITIALIZED messages were
BUILD005 printed the first time BUILDPDB/BUILDPD3 were executed,
BUIL3005 with nothing in the //SPIN library, but those messages
Aug 26, 2004 had no impact. Compiler fakers suppress the messages.
Change 22.228 Second instance of INCLASS in the KEEP list should have
VMACTPMX been INCLASSJ.
Aug 26, 2004
Thanks to Bruce W. Christopher, Housholde International, USA.
====== Changes thru 22.227 were in MXG 22.09 dated Aug 25, 2004=========
Change 22.227 Typo left a start-comment /* as the last line of member
VMAC99 VMAC99, which caused problems. Stray text was deleted.
Aug 25, 2004
Thanks to Chris Weston, SAS ITSV Development Cary, USA.
Change 22.226 Back-level ASG/TMON Version 2.0 records caused INVALID DO
VMACTMO2 LOOP CONTROL because I forgot that SAS won't tolerate a
Aug 25, 2004 missing value and had added DO _I_=1 TO TAAMQCNT; without
testing that TAAMQCNT had been input; it was a new field
in ASG/TMON Version 2.3 that was missing when 2.0 records
were read. All the DO _I_ statements are now protected.
Thanks to Nori Abakah, Progress Energy, USA.
Change 22.225 ANALDB2R(PDB=PDB,PMAUD02=YES) caused FORMAT MGD140O NOT
ANALDB2R FOUND (but a $MGD140O did exist in the format library),
Aug 25, 2004 because the variable that was PUT with $MGD140O format
did not exist, and thus was created as numeric, causing
SAS to look for a numeric rather than a character format.
The variable did not exist because not all datasets that
ANALDB2R expected were in the PDB library. If you use
%ANALDB2R(PDB=SMF...), it creates all needed datasets for
the requested reprots; if %READDB2(INFILE=SMF,IFCIDS=...)
is used to create a PDB, and all IFCIDs are not requested
then using %ANALDB2R(PDB=PDB ..) may fail. You can use
%READDB2(INFILE=SMF,CLASS=AUDIT...) to create a PDB with
all needed datasets for AUDIT reports (and that PDB will
have zero obs datasets for the IFCIDs with no records,
with all datasets created, all variables exist. Seeing
this exposure, a "compiler faker" was added for each of
the character variables that are PUT with FORMAT, forcing
those variables to be character variables, to circumvent
the error when all expected datasets are not present.
Thanks to Sharon Nagy, Comerica Bank, USA.
Change 22.224 SMF 6 or 57 record with ESS segment, but with SMF57TUL=0,
VMAC57 was not expected, caused INPUT STATEMENT EXCEEDED error.
VMAC6 Since there was an ESS segment, text was assumed present!
Aug 24, 2004 Now, the text length is tested. This text was revised
Oct 26, 2004 Oct 26, when same error did occur with SMF 6 record.
Thanks to Scott Wiig, US Bank, USA.
Thanks to Jurgen Strauch, Zweckverband Kommunale Stuttgart, GERMANY.
Change 22.222 NDM subtype QE record caused INPUT STATEMENT EXCEEDED.
VMACNDM The CDI DSECT does not agree with the record; the QTYPE
Aug 24, 2004 field is only 1 byte in the record but the DSECT shows a
Aug 26, 2004 halfword. The Queue Status contains a valid 'SS', and
the SEQ field contains '0000'x, but the error was because
MXG always expected that was followed by an 8-byte field
with SYSPLEX SERVER NAME, but that field does not exist
in all releases of NDM. Code was added to conditionally
input SERVER NAME only when it exists for the QE, TP, PI
and FA subtypes, and all with SERVER NAME field.
-Invalid value for OFFSET to JOB DATA SET NAME protected.
Thanks to Gerrit Van Meerbeek, HP/Procter and Gamble Cie, BELGIUM.
Change 22.221 Support for z/OS 1.6, but now, Change 22.272 is required.
VMAC30 Change 22.180 and prior APARs supportd most z/OS 1.6 new
VMAC7072 data and changes in MXG 22.07 and 22.08, but TYPE72GO
BUILD005 code (ONLY FOR z/OS 1.6 RECORDS) was wrong, causing many
BUIL3005 INVALID DATA messages and incorrect output in TYPE72GO
Aug 25, 2004 when z/OS 1.6 records were read (NO errors with 1.5 RMF).
The SKIP=SKIP-16 needed to be SKIP=SKIP-28 in SUBTYPE=3
code block for LENSCS GE 532.
-The extensive MXG Technical Note on IFAs/zAAPs in MXG
Newsletter FORTY-FIVE discussed MXG revisions to some of
the existing MXG variables; this change implements those
new calculations and new variables for TYPE72GO/TYPE70:
-In TYPE72GO:
CPUIFATM - IFA CPU Time spent on IFA
CPUIFETM - CP CPU Time that was Eligible to run on IFA
IFAUNITS - IFA Service Units spent on IFA
IFEUNITS - CP Service Units that were Eligible for IFA
CPUTCBTM - CP CPU Time (does NOT contain IFA CPU time)
CPUUNITS = CP Service Units (NOT contain IFA Units)
-It is likely the VELOCITY calculations in TYPE72GO will
be changed, but this is just a note that they have NOT
been revised to include IFA samples.
-TYPE70 dataset was revised to include only CP engines in
existing PCTCPUBY, CPUACTTM, etc, and labels now include
"CP" to identify. New IFA Capacity Variables added.
PCTCPUBY,CPUACTTM,CPUUPTM,CPUWAITM are all "CP-only".
PCTIFABY,IFAACTTM,IFAUPTM,IFAWAITM are all "IFA-only".
Individual PCTIFBYn and IFAWAITn variables exist for
each of the possible 32 IFA engines.
IFAACTTM='IFA ENGINE*EXECUTING*(ACTIVE) CPU TIME'
IFAUPTM ='IFA ENGINE*AVAILABLE*(UP) TIME'
NRIFAS ='NUMBER OF*IFA*ENGINES*AVAILABLE'
PCTIFABY='ALL IFAS*PERCENT*BUSY (DISPATCHED)'
IFAWAIT0-IFAWAITX - IFA wait for each of 32 engines
PCTIFBY0-PCTIFBYX - IFA PCT BUSY for each engine.
-This data has been tested with z/OS R 1.6 RMF 72 records,
but not with IFAs installed, so please validate the
old and new percentages when you install an IFA.
Change 22.272 updates have been tested with 30s and 72s.
-TYPE30 variable's names were changed to be consistent:
CPUIFATM='TOTAL*CPU TIME*ON*IFA'
CPUDFATM='DEPENDENT*ENCLAVE*CPU TIME*ON IFA'
CPUEFATM='INDEPENT*ENCLAVE*CPU TIME*ON IFA'
CPUIFETM='IFA-ELIGIBLE*CPU TIME*ON*CP'
CPUDFETM='IFA-ELIGIBLE*DEP ENCLAVE*CPU TIME*ON CP'
CPUEFETM='IFA-ELIGIBLE*IND ENCLAVE*CPU TIME*ON CP'
and these variables are added to the PDB.JOBS & PDB.STEPS
in the BUILDPDB/BUILDPD3 logic.
Thanks to Pat Curren, SuperValu Inc, USA.
Change 22.220 All 275 ADOC members were updated with new variables and
ADOC.... the variable lengths were corrected back to their MVS
Aug 22, 2004 lengths. The text in these documentation members was not
touched by the elegant utility that Freddie implemented,
which uses the text in DOCVER to update the variables.
Thanks to Freddie Arie, TXU, USA.
====== Changes thru 22.219 were in MXG 22.08 dated Aug 20, 2004=========
MXG 22.08 was re-dated Aug 20, 2004, when I discovered seven members
were missing from the 3480 tapes,including VMAC0 which caused JCLTESTx
to fail. The re-dated version included these additional changes:
Change 22.219 -Variable DISKRATE was misspelled in two KEEP= lists ad
VMACMWUX DISKRT.
Aug 20, 2004 -Variable DISKNAME was increased to $64 as $20 was too
short; only $35 were seen thus far, but this will avoid
yet another change later, hopefully!
-Comments revised to caution that a dollar sign should not
be used as a delimiter, as dollar signs appear in the tty
field in the MeasureWare PROC records.
Thanks to Roman Gudz, Penske Logistics, USA.
Thanks to Albert Jacobs, KBC, BELGIUM.
Change 22.218 The PDB exit _EDBJOBS was relocated so it precedes the
BUILD005 OUTPUT ACCOUNT; statement; if you used the _EDBJOBS exit
BUIL3005 to populate ACCOUNTn variables for Started Tasks that do
Aug 20, 2004 not have accounting parameters on their "JOB" card, your
code worked just fine for the PDB.JOBS dataset, but the
observations in PDB.STEPS and especially in PDB.SMFINTRV
contained blanks for the ACCOUNTn variables, because the
ACCOUNT (temporary) dataset is used to "back fill" those
other PDB datasets. With this code relocation, any exit
changes to ACCOUNTn variables will be propagated into the
PDB.STEPS, PDB.PRINT, and PDB.SMFINTRV datasets.
Note: It used to be that you HAD to use a table lookup
based on JOB name to assign ACCOUNTn variables
for STCs, but for all current OS/390 and z/OS,
you can put account fields on the "JOB" card for
the STC, and they will automatically be carried
into the PDB.JOBS/STEPS/PRINT/SMFINTRV datasets.
Thanks to Ken Jones, Xwave, CANADA.
Change 22.217 The extraneous IF in IF BYTEAVAIL=MAX(...) was removed,
VMACNTSM but it had no impact since the prior test for AVAILMEK
Aug 20, 2004 was never satisfied.
Thanks to Xiaobo Zhang, ISO, USA.
Change 22.216 The utility to convert character-variables-containing-hex
UTILCVRT after you move SAS datasets from MVS to ASCII worked fine
Aug 20, 2004 but added temp variables LENGTH and _I_ to the output.
Now it doesn't, and LENGTH was respelled as _L_.
Thanks to Al Sherkow, I/S Management Strategies, Ltd., USA.
Change 22.215 Creating CPU graphs of NT SMF data caused errors VARIABLE
BLDNTPDB STARTIME NOT FOUND and INVALID VALUE FOR SORTEDBY; the
Aug 20, 2004 sumby= statement was corrected and the DROP was removed.
Thanks to Matthew Chappell, Queensland Transport, AUSTRALIA.
Change 22.214 Commas were missing after XX='EN' and YY='WO' in lines
MXGSASV9 15 and 16 in the JCL procedure for SAS V9.
Aug 20, 2004
Thanks to Wade Peterson, McMaster-Carr Supply Company, USA.
Change 22.213 Variable R723CRTF was not kept in the TRND72GO dataset
TRND72GO because it was misspelled as R723CRFT in the ID=
Aug 19, 2004 statement.
-The default example TRND72GO summarizes at the SRVCLASS
level of detail, but you may prefer to summarize at the
PERIOD level, since Goals and Importance can be set at
the lower level. You can add PERIOD at the end of the
SUMBY= statement in your tailored TRND72GO if you want
the PERIOD level included in the trending summary.
Thanks to Rick Mansfeldt, IBM Global Services, USA.
Change 22.212 The FTPREPLY field changed from a binary value to EBCDIC
VMACTCP numeric; APARs PQ92769 and PQ83055 documents this change
Aug 18, 2004 in the format of the field; MXG code supports both the
old and the new format transparently.
Thanks to Tom White, SPRINT, USA.
Change 22.211 The JCL example for testing with SAS Version 9 needed the
JCLTEST9 //MONITASK and //SPIN DDs in step TESTOTHR.
Aug 17, 2004
Thanks to Paul Gillis, Pacific Systems Management Pty. Ltd
Change 22.210 JES3 JMF SMF 84 caused INPUT STATEMENT EXCEEDED RECORD;
VMAC84 the statement LOCJSTOF+LOCJSTOF+48; in VMAC84 should
Aug 17, 2004 have been: LOCJSTOF=LOCJSTOF+48;
Thanks to Paul Gillis, Pacific Systems Management Pty. Ltd
Change 22.209 While all INFORMAT xxx $NOTRAN statements were removed in
BUILD005 Change 22.192, using PROC SYNCSORT still caused BUILDPDB
BUIL3005 to fail, because the SPIN.SPIN30_4 dataset had variables
Aug 17, 2004 with that INFORMAT. This change removes the informat for
the two variables ABNDRSNC TERMIND as that dataset is
read, eliminating that (hopefully!) final exposure.
Alternatively, you could just use
DATA SPIN.SPIN30_4;
SET SPIN.SPIN30_4;
INFORMAT ABNDRSNC TERMIND ;
to replace the SPIN30_4 data set and remove the INFORMAT.
-I discovered the INFORMAT statement must be AFTER the SET
statement to remove the informat from the variables!
Thanks to Michael L. Kynch, International Paper, USA.
Thanks to Peter Giles, Centrelink, AUSTRALIA.
Change 22.208 -Support for TOKDANAM=GID creates new variable TOKGID in
IMAC6ESS TYPE80xx datasets that can contain the 53 segment.
VMAC80A -Removed unneeded PUT statement in IMAC6ESS member that
Aug 13, 2004 was observed in the log.
Thanks to Engelbert Smets, Provinzial Rheinland Versicher., GERMANY.
====== Changes thru 22.207 were in MXG 22.08 dated Aug 13, 2004=========
Change 22.207 FLASH. For MVS SAS V9.1 and V9.1.2. SAS Note SN-12943
CONFIGV9 reports incorrect results with PROC MEANS,SUMMARY,REPORT
Aug 13, 2004 and TABULATE only on "MVS", if threading is used, and the
SAS default option is THREADS. Specifying NOTHREADS does
corrects the error, which is fixed in SAS V9.1.3, and SAS
will have a Hot Fix very soon for V9.1 and V9.1.2, but I
still decided this was sufficiently critical to re-date
the MXG 22.08 release and include NOTHREADS in CONFIGV9
member, since you could easily change that option in your
CONFIGV9 later, or use OPTIONS= on your // EXEC statement
when you have the fix and find threading is of value.
Thanks to MP Welch, SPRINT, USA.
Change 22.206 Cosmetic. Some fields caused 'Note 49' and blanks were
VMACEREP inserted, to support that future version possible change.
IMACICBB
Aug 13, 2004
Thanks to Thomas Heitlinger, FIDUCIA IT AG, GERMANY.
====== Changes thru 22.205 were in MXG 22.08 dated Aug 12, 2004=========
Change 22.205 New CICS Statistics datasets were not listed in IMACCICS,
IMACCICS and worse, were not invoked in the _CICSTAT nor _S110ST
VMAC110 macros, and the example to use both in Change 18.152 did
Aug 12, 2004 not work. The new datasets are now added/listed.
-The _S110ST macro sorts all CICS Statistics datasets from
the "Wdddddd" work default (WORK) to their "Pdddddd" PDB
library.
-The _CICSTAT changes both the _W and _Pdddddd names, to
the value (ddname) you stored in macro variable CICSTAT,
but could not be used with the _S110ST macro because the
same DD would be used for both _W and _P datasets.
-The new _CICSTAS (S=sort!) changes only the Pdddddd for
the output of the SORTs, so it can be used in EXPDBOUT
ahead of _S110ST to sort all CICS statistics datasets to
the DDname specified in macro variable CICSTAT.
To COPY all cics stats datsets to DDname "CICSSTAT", use
%LET CICSTAT = CICSSTAT;
_CICSTAS;
_S110ST
in your EXPDBOUT member, and all of the CICS statistics
datasets will be CICSSTAT.CICxxxxx.
Thanks to Nori Abakah, Progress Energy, USA.
Change 22.204 Support for new fields added by DB2 V7 and V8 in T102S172
VMAC102 for IFCID=172 (all units of work involved in a deadlock).
Aug 12, 2004 The test for QWHSRELN EQ 7.1 was changed to GE 6, as the
Aug 13, 2004 "V7" data existed starting with DB2 Version 6.
Thanks to Andy Creet, Department of Defence, AUSTRALIA.
Thanks to Brad Kiemann, Department of Defence, AUSTRALIA.
Change 22.203 Cosmetic. VGETJESN decodes JCTJOBID to create JESNR and
VGETJESN TYPETASK, but if JCTJOBID was hex zeros or blank, as for
Aug 12, 2004 some records for JOB='INIT', unnecessary messages that
WARNING - TYPETASK NOT DECODED were printed on the log.
Now, VGETJESN tests to see that JCTJOBID is non-blank,
so the unnecessary warning messages won't be printed.
Thanks to Ng Kin, Acxiom, USA.
Change 22.202 Cosmetic. Invalid SMF 42 subtype 21 record cause MXG to
VMAC42 print an MXG error message that APAR OA02184 corrects the
Aug 11, 2004 bad records, but that APAR only corrects errors when the
delete used ISPF STOW command; if the delete was done by
DESERV FUNC=DELETE, the record is wrong and IBM has just
created APAR OA08693 to correct that error. The text of
MXG's error message said the record was DELETED, but at
the point of the error, MXG had already output TYPE4221.
The bad segment prevents an output to TYPE422A dataset,
so the text of the error message was clarified that it is
the rest of the record that is being deleted.
Thanks to Scott Wiig, U.S. Bank, USA.
Change 22.201 Aren't you glad SAS developers use MXG for testing new
VMXGSUM releases of SAS? Their early tests of SAS V9.2 found an
Aug 11, 2004 MXG syntax error that had previously been absorbed with
no compiler error. The text %ELSE %THEN %DO; was
corrected to %ELSE %DO;
Thanks to Rick Langston, SAS Institute Cary, USA.
Change 22.200 Variables SASVEREL SASUSER and SASJOBID are created by a
VMACSASU SUBSTR() of a $64 variable, so they defaulted to length
Aug 11, 2004 of 64. They are now defined in a LENGTH $8 statement.
These fields were added by Change 22.251, but, now, see
Change 22.303 for the (final?) correction.
Thanks to Dr. Alexander Raeder, Itellium, GERMANY.
Change 22.199 Major revision to IMS0708 dataset, created by TYPEIMS7,
EXIMS78 from the IMS 07/08 log records. Previously, transactions
EXIMSMRY with the same DTOKEN were summed into only one output
TYPEIMS7 observation, but that destroyed the detail "servictm" of
VMACIMS each program schedule event, and there can be thousands
VMXGINIT of Quick Restart program schedules with the same DTOKEN.
Aug 12, 2004 And each program schedule event could have serviced many
(NMSGPROC) transactions for each detail event. This
redesign eliminates the summarization by DTOKEN, creating
one observation for each program schedule event, with the
detail NMSGPROC, IMSCPUTM, etc., for each schedule event.
-If both 08 and 07 are found, STRTTIME and ENDTIME will
be non-missing; if only an 07 end event with no matching
08 start is found, STRTTIME will be missing, and for an
08 only with no 07 start (or back-to-back 08s) ENDTIME
will be missing.
-For events with the same DTOKEN, new variable INSTANCE
counts individual event instances.
-New variables SYSABEND and USRABEND decode the COMPCODE
into more meaningful variables in IMS0708 detail dataset.
-VMACIMS had to be revised to increase the stored length
of IMSRECNO to 8 bytes; it is now used to sequence events
within each DTOKEN. Originally it was a PIB4. field that
was stored in 5 bytes, but it was changed to a PIB8 field
in IMS Version 6, and should have been increased then.
-VMXGINIT was updated to support the new tokens PIMS78 and
PIMSMRY which can be used to set the DDNAME of IMS0708
and IMSSUMRY datasets. The default value for the output
DD is the _IMSTRAN old-style macro, so if you have set it
in your IMACIMS7 member to "IMSTRAN", the new TYPEIMS7
will still create IMSTRAN.IMS0708, or the example in the
TYPEIMS7 member shows you can use %LET PIMS78=IMSTRAN; in
your //SYSIN stream to set the destination DDname.
-But in case you really want the summary by DTOKEN, new
IMSSUMRY data set can be created by the _IMSUMRY macro,
as documented in comments in TYPEIMS7 member.
-And the original TYPEIMS7 program is preserved in the MXG
member ZTYPIMS7, just in case you feel a need to revert.
-The requestor of this change also wanted to create a new
dataset, IMSABEND, with only ABENDing transactions, but I
decided against making that an "MXG dataset", because the
IMACKEEP member and the _KIMS78 and _EIMS78 macros can
easily be used to create the new dataset, as shown below
in the example that also creates a new ORIGUSID variable
at the same time:
MACRO _KIMS78
ORIGUSID )
IMSABEND (KEEP=COMPCODE ORIGUSID USRABEND SYSABEND
%
MACRO _EIMS78
ORIGUSID=IMSUSID;
IF '0' LE IMSUSID LE '9' THEN IMSUSID='INTERNAL';
OUTPUT _LIMS78;
IF COMPCODE NOT
IN('00000000'X,'40404040'X,'20202020'X)
THEN OUTPUT IMSABEND;
%
The use of the _Kdddddd and _Edddddd macros to create new
datasets is documented in the DOCMXG member.
Thanks to Glenn Lundgren, SEB IT Service, SWEDEN.
Change 22.198 The PCTWFLOW calculation was revised to match the WFL %
ZRBRPT3 value shown on the RMF III panels, using the revised
Aug 6, 2004 equation from the RMF Programmers Guide that had been
overlooked since 1996.
Thanks to Randy Shumate, LexisNexis, USA.
Thanks to Steven L. Hankins, LexisNexis, USA.
Change 22.197 The Ficon Open Exchange analysis program was revised to
ANALFIOE keep only Online channels, and to delete Ficon Bridge
Aug 5, 2004 channels, to which the analysis does not apply.
The example in comments to create the datasets from SMF
was revised again, now using the three _Sdddddd dataset
sort macros instead of the _Sxxxx product sort macros.
Thanks to Dr. H. Pat Artis, Performance Associates, USA.
Thanks to Betty Wong, Bank of America, USA.
Change 22.196 Support for longer length DB2 identification variables:
VMACDB2H QWHSLOCN QWHSAID QWHCOPID QWHCEUID QWHDRQNM QWHDSVNM
Aug 5, 2004 is prepared to read in the up-to-128-byte character text,
but the length of those variables is not changed, yet.
Only when you actually increased-length data would you
want to increase their stored length in each observation
in your DB2ACCT dataset, and that can be done in your
//SYSIN in the job that creates your DB2ACCT data, using:
%LET MACFILE= %QUOTE( LENGTH QWHSLOCN $128;);
The longer fields can also now be in UNICODE, but until I
have test data, and until there is a need, I chose not to
to add that alternative code (UNICODE requires SAS V8,
and because the DB2 code is used in BUILDPDB, the longer
I hold off adding the UNICODE support, the longer those
few sites still running SAS V6 can limp along).
Thanks to Charles Harbour, John Deere, USA.
Change 22.195 INVALID DATA FOR YYYY warning for SMF 102 IFCID=22 when
VMAC102 the QW0022TS field contained nulls; the inputs with NUM
Aug 4, 2004 informat were protected with ?? syntax.
Thanks to Jim Poletti, Edward Jones, USA.
Change 22.194 Typo. SUN.ASUM79PR should have been SUN.ASUM70PR.
WEEK70PR
Aug 4, 2004
Thanks to Ingegerd Jansson, Volvo Information Technology AB, SWEDEN.
Change 22.193 Support for many new NTSMF objects, including DTS CPU
EXNTDTCP configuration records, Exchange 2003, Exchange 2000
EXNTDTLP instant messaging, Outlook 2003, and RSVP objects create
EXNTIACP these new datasets:
EXNTIAUP dddddd dataset description
EXNTMEII NTDTCP DTSCPU NT DTS.CPU
EXNTMETF NTDTLP DTSLOGPR NT DTS.LOGICALPROCESSOR
EXNTMSAS NTIAUP IASAUTPR NT IAS AUTHENTICATION PROXY
EXNTMSDC NTIACP IASACCPR NT IAS ACCOUNTING PROXY
EXNTMSGC NTMEII MSEXIM NT MSEXCHANGEIM
EXNTOUTL NTMETF MSEXTRFS NT MSEXCHANGE TRANSPORT FILTER SINK
EXNTRSVI NTOUTL OUTLOOK NT OUTLOOK
EXNTRSVP NTRSVI RSVPINTR NT RSVP INTERFACES
EXNTSMSM NTRSVP RSVPSERV NT RSVP SERVICE
IMACNTSM NTMSAS MSEXCHAS NT MS EXCHG ACTIVESYNCNOTIFY OMAPUSH
VMACNTSM NTMSDC MSEXCHDC NT MS EXCHG DSACCESS DOMAIN CONTROLLER
VMXGINIT NTMSGC MSEXCHGC NT MS EXCHG DSACCESS GLOBAL COUNTERS
Aug 3, 2004 NTSMSM SMSMSE NT SMS SMSMSE 4.5
Aug 5, 2004 -Most of the sample data records from the test system have
zero values, so it is impossible to know which, if any,
will need to be de-accumulated; if you have real data for
any of these objects, please contact support@mxg.com for
instructions on sending us your file for validation.
-The new DTSCPU and DTSLOGPR objects indicate HyperThread
Support and Status. MXG merges the two objects into an
enhanced PDB.DTSLOGPR dataset (in the _SNTDTLP sort macro
when you use TYPSNTSM) with the CPU information from the
DTSCPU object and the logical processor information from
the DTSLOGPR object. HyperThreading is determine by:
DTCPNLPS - Number of Logical Processors Supported
DTCPNLPA - Number of Logical Processors Active.
DTCPNLPS DTCPNLPA
Hyperthreading Unsupported: missing one
Supported/Disabled: not missing one
Supported/Enabled: not missing more than 1
-The new HyperThread objects were added structurally by
NTSMF 3.4.7, so this change supports that release.
Change 22.192 All INFORMAT xxxx $NOTRAN.; statements are removed from
DOC all source code. That informat has never actually done
Aug 2, 2004 anything; it was planned to "mark" the hex-containing
character variables, so SAS could detect NOTRAN and not
translate them, but that was never implemented in SAS,
and the circumvention (to use UTILCVRT instead) has been
provided in MXG since Change 19.271.
Note that the $NOTRAN. format will always be created in
the MXG FORMATS member, to protect old MXG datasets.
The motivation for this change was the error in Syncsort
PROC SYNCSORT product under SAS Version 9.1.2, which does
not correctly handle INFORMATs, and since the $NOTRAN was
no longer needed, removing all will eliminate one more
possible error, if you have the PROC SYNCSORT product and
they have not fixed their error when you install 9.1.2.
Search NEWSLTRS for PROC SYNCSORT for details.
IMACICBB IMACICOC IMACICSA TYPEMOND TYPETMON TYPEVM
VMAC1415 VMAC21 VMAC22 VMAC28 VMAC33 VMAC36
VMAC37 VMAC38 VMAC39 VMAC41 VMAC42 VMAC60
VMAC6156 VMAC64 VMAC78 VMAC79 VMAC80 VMAC84
VMAC88 VMAC89 VMAC8911 VMAC90 VMAC90A VMAC91
VMAC92 VMACACF2 VMACACHE VMACAICO VMACAICS VMACAIM6
VMACBETA VMACBGSI VMACCIAO VMACCIMS VMACCMF VMACCMFV
VMACCOMP VMACCRAY VMACCTLG VMACDALO VMACDLMN VMACDMON
VMACEPIL VMACEPMV VMACFILA VMACFOCU VMACFTEK VMACFTP
VMACHBUF VMACHIPR VMACIAM VMACIDMJ VMACIDMS VMACILKA
VMACILKV VMACIMS1 VMACITRF VMACLMS VMACMDF VMACMIM
VMACMON8 VMACMPT VMACNAF VMACNNAV VMACNOAM VMACODS
VMACOMAU VMACOMCI VMACOMVT VMACOPC VMACPKMN VMACPRFS
VMACPROS VMACQAPM VMACRDS VMACROSC VMACRTE VMACSAMO
VMACSAR VMACSARS VMACSARX VMACSFTA VMACSMF VMACSNAP
VMACSOLV VMACSPMS VMACSTX VMACTCP VMACTIE VMACTIRS
VMACTMNT VMACTMS5 VMACTMV2 VMACTPX VMACTSOM VMACVMON
VMACVMXP VMACVSME VMACWSF VMACX37 VMACXCOM VMACXPSM
VMACXSTR VMACXXXX VMXGHSM VMXGVTOC VMXGVTOF
Subnote: in my class, discussing "sub-second" response
response time, I compare measures of EDITing under TSO
with three (okay, old!) connections: 2400 and 9600 baud
and local channel attached, and measured a max of 900
"TGET"s (inputs) per hour. This PC updated 120 members
took 20 minutes; there were at least one sequence of
SELECT, FIND, MARK, DELETE, FIND, SAVE for each member,
so, without the delay due to TSO swapping, this EDIT
session exceeded 2100 transactions per hour.
Change 22.191 Support for ASG/TMON TCE for CICS/ESA 2.3: COMPATIBLE, as
EXMONAMQ all new fields were added at the end of records, so MXG
IMACTMO2 21.21 or later will read the new records without error.
VMACTMO2 The new version added many fields now supported in MXG in
VMXGINIT the many TMON datasets, and one new dataset is created:
Aug 2, 2004 Dataset MONITASK dataset new variables:
TAWRDCT ='WAIT FOR*REDISPATCH*COUNT'
TAWRDTM ='WAIT FOR*REDISPATCH*TIME'
TAUSRWCT ='USERWAIT*TIME'
TAUSRWTM ='USERWAIT*COUNT'
Dataset MONISYST new variables:
TIMIDNSC='MIDNIGHT*NON-SEGMENTED*TASKS*COUNT'
TIUSRWCT='WAIT FOR*REDISPATCH*COUNT'
TIUSRWTM='WAIT FOR*REDISPATCH*TIME'
TIWRDCT ='WAIT FOR*REDISPATCH*COUNT'
TIWRDTM ='WAIT FOR*REDISPATCH*TIME'
Dataset MONIAWT new variables:
TAAWTWRC='WAIT FOR*REDISPATCH*COUNT'
TAAWTWRT='WAIT FOR*REDISPATCH*TIME'
Dataset MONICMX new variables:
TICMXHWM='CLASS*HIGH*WATER*MARK'
TICMX ='TICMX*SEGMENT*COUNT'
Dataset MONIIWT new variables:
TIIWTWRC='WAIT FOR*REDISPATCH*COUNT'
TIIWTWRT='WAIT FOR*REDISPATCH*TIME'
Dataset MONITJ new variables:
TJSREQCT='JVM*REQUESTS*WITH*RESET'
TJCREQCT='JVM*REQUESTS*WITH*CLASSCACHE'
Dataset MONIPA new variables:
PACBRNM ='CORBASERVER NAME'
PADSCWC ='STG CONSTRAINT WAIT COUNT'
PADSCWT ='STG CONSTRAINT WAIT TIME'
PADSMWC ='TCB MISMATCH WAIT COUNT'
PADSMWT ='TCB MISMATCH TIME'
PADSTHW ='PEAK OPEN TCBS'
PAEJBACT='BEAN ACTIVATION REQUESTS'
PAEJBCCT='BEAN CREATION REQUESTS'
PAEJBMCT='EJB METHOD CALLS'
PAEJBPCT='BEAN PASSIVATION REQUESTS'
PAEJBRCT='BEAN REMOVAL REQUESTS'
PAEJBTCT='TOTAL EJB REQUESTS'
PAHTDLYC='HOT POOL DELAYS'
PAHTDLYT='HOT POOL DELAYS TIME'
PAJ9CPUC='J9 CPU COUNT'
PAJ9CPUT='MODE J9 CPU TIME'
PAJTDLYC='JVM TCB DELAYS TIME'
PAJTDLYT='JVM TCB DELAYS'
PAKY9CPC='KEY 9 CPU COUNT'
PAKY9CPT='KEY 9 CPU TIME'
PAKY9DSC='KEY 9 DISPATCH COUNT'
PAKY9DST='KEY 9 DISPATCH TIME'
PAPTPWTC='PARTNER WAIT COUNT'
PAPTPWTT='PARTNER WAIT TIME'
PAROCPUC='RO CPU COUNT'
PAROCPUT='RO CPU TIME'
PARODSPC='RO DISPATCH COUNT'
PARODSPT='RO DISPATCH TIME'
PASOI1C ='SOCKET CHARS RECEIVED'
PASOIMC ='SOCKET RECEIVE REQUESTS'
PASOO1C ='SOCKET CHARS SENT'
PASOOMC ='SOCKET SEND REQUESTS'
Dataset MONIPA new variables:
PIRECICT='PI*RECORD*COUNT'
PIKY9DST='KEY 9*DISPATCH*TIME'
PIKY9DSC='KEY 9*DISPATCH*COUNT'
PIKY9CPT='KEY 9*CPU*TIME'
PIKY9CPC='KEY 9*CPU*COUNT'
PIJ9CPUT='MODE*J9*CPU*TIME'
PIJ9CPUC='J9*CPU*COUNT'
PIDSMWT ='TCB*MISMATCH*TIME'
PIDSMWC ='TCB*MISMATCH*WAIT*COUNT'
PIDSCWT ='STG*CONSTRAINT*WAIT*TIME'
PIDSCWC ='STG*CONSTRAINT*WAIT*COUNT'
PIEJBACT='BEAN*ACTIVATION*REQUESTS'
PIEJBPCT='BEAN*PASSIVATION*REQUESTS'
PIEJBCCT='BEAN*CREATION*REQUESTS'
PIEJBRCT='BEAN*REMOVAL*REQUESTS'
PIEJBMCT='EJB*METHOD*CALLS'
PIEJBTCT='TOTAL*EJB*REQUESTS'
PIRODSPT='RO*DISPATCH*TIME'
PIRODSPC='RO*DISPATCH*COUNT'
PIROCPUT='RO*CPU*TIME'
PIROCPUC='RO*CPU*COUNT'
PIPTPWTT='PARTNER*WAIT*TIME'
PIPTPWTC='PARTNER*WAIT*COUNT'
PISOOMC ='SOCKET*SEND*REQUESTS'
PISOO1C ='SOCKET*CHARS*SENT'
PISOIMC ='SOCKET*RECEIVE*REQUESTS'
PISOI1C ='SOCKET*CHARS*RECEIVED'
PIJVIRST='JVM*RESET*TIME'
PIJVIRSC='JVM*RESET*COUNT'
PIJTDLYT='JVM*TCB*DELAYS*TIME'
PIJTDLYC='JVM*TCB*DELAYS'
PIHTDLYT='HOT*POOL*DELAYS*TIME'
PIHTDLYC='HOT*POOL*DELAYS'
Dataset MONITKP new variables:
TKPTOTMT='MVS*STORAGE*CONSTRAINT*WAIT*TIME'
TKPTOTMW='MVS*STORAGE*CONSTRAINT*WAITS'
Dataset MONITR new variables:
TRSTGWWT='STORAGE*REQUEST*WAIT*TIME'
TRSTGWCT='STORAGE*REQUEST*WAITS'
New Dataset MONIAMQ for MQ variables:
TAAMQCLC='MQCLOSE*CALLS'
TAAMQCLT='MQCLOSE*CALL*TIME'
TAAMQFLG='QUEUE*MQ*API*FLAG'
TAAMQGTC='MQGET*CALLS'
TAAMQGTT='MQGET*CALL*TIME'
TAAMQICT='TAAMQ*SEGMENT*COUNT'
TAAMQIQC='MQINQ*CALLS'
TAAMQIQT='MQINQ*CALL*TIME'
TAAMQMGO='ORIG*QUEUE*MANAGER*NAME'
TAAMQMGR='MQ*QUEUE*MANAGER*NAME'
TAAMQOPC='MQOPEN*CALLS '
TAAMQOPT='MQOPEN*CALL*TIME '
TAAMQP1C='MQPUT1*CALLS '
TAAMQP1T='MQPUT1*CALL*TIME '
TAAMQPTC='MQPUT*CALLS'
TAAMQPTT='MQPUT*CALL*TIME'
TAAMQQUE='MQ*QUEUE*NAME'
TAAMQQUO='ORIG*QUEUE*NAME'
TAAMQSTC='MQSET*CALLS'
TAAMQSTT='MQSET*CALL*TIME'
Change 22.190 Support for NTSMF Objects MicroStrategy Server Jobs and
EXNTMSSJ MicroStrategy Server Users create new datasets MSTRSRJB
EXNTMSSU and MSTRSRUS (MSTRSRJB is complete, but only structure
IMACNTSM code exists MSTRSRUS, with no fields, as the dictionary
VMACNTSM record for the User's object has not yet been created).
VMXGINIT Because some of the fields are presented as totals, and
Jul 29, 2004 are not deaccumulated interval values, the _SNTMSSJ sort
macro must be used to de-accumulate the datasaet, so the
first observation for each instance has missing values.
Additional heuristics to detect when these total values
went to zero (perhaps a shutdown of the process?) were
necessary.
Thanks to Bob Gauthier, Albertsons, USA.
Change 22.189 Major update added 1300 lines of text to document most of
ADOC110 the undescribed CICSTRAN variables, using IBM's CICS
Jul 29, 2004 Performance Analyzer Report Reference 1.3 manual.
Change 22.188 Variables S94VCA41-S94VCA48, S94CA481-S94CA488, and
VMAC94 S94CA351-S94CA358 are all multiplied by 60 (so their
Jul 29, 2004 internal value is seconds) and then formatted TIME8.
so they will print as hh:mm:ss units of time, since they
are all rolling average cache ages.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 22.187 The format to map SAS Procs to their Product for the SAS
FORMATS user SMF record was updated for PROC SORTT, which is an
Jul 29, 2004 undocumented way of forcing the internal SAS Sort utility
to be used instead of a "host" sort product.
Thanks to Dave Thorn, SunGard Availability Service, USA.
Change 22.186 Omegamon/VTAM V520 IRNUM 29 caused DIVISION BY ZERO and
VMACOMVT LOOPING; the test for IRNUM IN (29,30) was incorrect for
Jul 28, 2004 IRIND NE 'L'.
Thanks to Phil Baxter, Capgemini Group, ENGLAND.
Change 22.185 Invalid SMF 80 Extended Relocate Section contained token
VMAC80A PROGRAM but there was no length of program name nor the
Jul 28, 2004 program name field following the token) caused and INPUT
STATEMENT EXCEEDED RECORD error. Circumvention tests for
expected length field, while IBM support is contacted.
Thanks to Engelbert Smets, Provinzial Rheinland Versicher., GERMANY.
Change 22.184 ASCII Execution only, SAS V9 only: EBCDIC character
DOC variables can contain hex zeros instead of blanks due to
Jul 28, 2004 a V9 SAS design change, which can cause character tests
to fail and/or cause spurious MXG error messages when an
expected character was not found. Under ASCII execution,
the $VARYINGn informat reads a variable length string,
but the value is "raw" and must be converted to EBCDIC if
that's what's really in the text. Previous to Version 9:
INPUT VARIABLE $VARYINGnn. LENTEXT @;
VARIABLE=INPUT(VARIABLE,$EBCDICnn.);
VARIABLE=TRANSLATE(VARIABLE,' ','80'X);
was sufficient: when LENTEXT was less than nn, $VARYINGnn
returned ASCII blank '20'x for the extra characters, the
INPUT function converted them to '80'x, and thus the
TRANSLATE of '80'x back to blank was necessary. Now, SAS
V9 $VARYING informat returns hex zeros, rather than ASCII
blanks for the extra characters, and the INPUT function
passes the hex zeros into it's output, so it is necessary
now to use these statements for each $VARYING variable:
INPUT VARIABLE $VARYINGnn. LENTEXT @;
VARIABLE=INPUT(VARIABLE,$EBCDICnn.);
VARIABLE=TRANSLATE(VARIABLE,' ','80'X);
VARIABLE=TRANSLATE(VARIABLE,' ','00'X);
to convert those unexpected hex zeros to character blank.
All 511 TRANSLATE statements with '80'x were replicated
and the '80'x changed to '00'x in the second instance in
these 55 MXG members:
ANALSNAP IMAC6ESS IMACACCT INSTALL SYSLOGJ3 UTILTPMX
UTILXREF VMAC102 VMAC103 VMAC119 VMAC120 VMAC24
VMAC33 VMAC37 VMAC42 VMAC4789 VMAC59 VMAC6
VMAC60 VMAC6156 VMAC80A VMACACC VMACACF2 VMACASXT
VMACCMA VMACCTLG VMACDB2 VMACEDGS VMACENDV VMACHMF
VMACHPDM VMACIMS VMACNDM VMACNETM VMACNSPY VMACOPFT
VMACPOOL VMACQACS VMACQAPM VMACRSDA VMACSARR VMACSASU
VMACSHDW VMACSOLN VMACTCP VMACTMDB VMACTPMX VMACTSOM
VMACVMON VMACVMXA VMACVVDS VMACXPSM VMXGHSM
- An alternative was to replace the INPUT and TRANSLATE
functions with INPUTC(variable,'$EBCDIC.'); but its
syntax needs additional quotes (the second argument
is not an INFORMAT, but a literal/variable containing
an informat), the length has to be removed, (it fails
if the informat has an "n" value), and in some cases
just didn't seem to work correctly (returned only one
character when there were three), all of which made
it very unattractive to EDIT/CHANGE those many times!
- The TRANSLATE statement supports multiple pairs, so
it could have been written as
VARIABLE=TRANSLATE(variable,' ','80'x,' ',00'x);
but that too was mechanically risky, and was too long
for some existing lines of code, so a second function
statement was inserted.
Change 22.183 The Working Set Size variables ACTVWSS and VMDWSSPR are
VMACXAM in 4096 byte blocks, so they are now converted to bytes
Jul 27, 2004 and FORMATed MGBYTES to "print pretty" storage units.
Aug 8, 2004 Aug 8: Semi-colon added to FORMAT statement to correct
error detected in Freddie's QA tests.
Thanks to Rodger Foreman, Acxiom, USA.
Thanks to Freddie Arie, TXU, USA.
Change 22.182 The field FCFILENM was truncated at 32 bytes; the INPUT
VMAC119 was 64 bytes, but the statement MINLEN=MIN(32,LEN11903);
Jul 26, 2004 is now corrected to MINLEN=MIN(64,LEN11903);.
Thanks to Ken Jordan, Pacific Gas & Electric, USA.
Change 22.181 Enhancements to RMF Reporting.
ANALRMFR -Online Time Percentage field added to CPU Activity Report
Jul 26, 2004 -Updates to Partition Data Report
-LPAR Cluster Report added, use REPORT=LCLUS to request.
Thanks to Jim S. Horne, Lowe's Companies, Inc, USA.
====== Changes thru 22.180 were in MXG 22.07 dated Jul 25, 2004=========
Change 22.180 IFA CPU variables added by APAR OA05731, Change 22.152
VMAC22 variable names are clarified and more consistent:
VMAC30 R723IFAT - IFA*CPU TIME*ON IFA
VMAC7072 R723IFCT - IFA-ELIGIBLE*CPU TIME*ON CP "C-for Coulda?"
VMAC71 Some additional revisions were made for IFA processors.
VMAC74 This change includes new fields added to RMF 74-5 by
VMAC75 APAR OA04877.
VMAC79
BUILD005
BUIL3005
Jul 24, 2004
Change 22.179 The UCICSCNT utility to examine and count CICS records in
FORMATS your SMF file was enhanced with additional reports on the
UCICSCNT Statistics STIDs found in your data, and corrected so the
Jul 23, 2004 PROC FREQs always work without error. New formats for
a description of STID and MNSEGCL are added in FORMATS.
Thanks to Tren Burner, City of San Antonio (TEXAS, of course), USA.
Change 22.178 The INSTANCE=, argument allows selection by "UOWIDCHR",
ANALDB2R the first six bytes of UOWID (which is also QWHSLUUV),
Jul 23, 2004 but the internal logic was wrong in ANALDB2R. The test
and comments for how to use INSTANCE= were revised; the
value passed must be hex characters, with no quotes and
without the "X" that is used for hex literals in data
step logic.
Thanks to Jim Mourgelas, TD Bank Financial Group, USA.
====== Changes thru 22.177 were in MXG 22.07 dated Jul 23, 2004=========
Change 22.177 Update to define MACRO _Vdddddd in selected members.
VMACIDMS -VMACIDMS: The _Sdddddd macros now invoke PROC SORT with
VMACTMS5 NODUP and the _Bdddddd macros are defined.
Jul 22, 2004 -VMACTMS5: _Vdddddd defined.
Aug 8, 2004 -Aug 8: These members were EDITed and support _V macros:
VMAC20 VMAC25 VMAC26J2 VMAC26J3 VMAC28 VMAC31
VMAC32 VMAC33 VMAC36 VMAC37 VMAC38 VMAC39
VMAC40 VMAC41 VMAC434 VMAC4345 VMAC44 VMAC4789
VMAC50 VMAC5234 VMAC535 VMAC5568 VMAC57 VMAC59
VMAC60 VMAC6156 VMAC6367 VMAC68 VMAC69 VMAC7
VMAC75 VMAC81 VMAC83 VMAC85 VMAC88 VMAC89
VMAC8911 VMAC90 VMAC90A VMAC91 VMAC92 VMAC94
VMAC97 VMAC99 VMACNSPY VMACSTC VMACSYNC VMACTCP
VMACTMNT VMACTPF VMACTSOM
Thanks to Dale Houg, Abbott Labratories, USA.
Thanks to Dr. Alexander Raeder, Itellium, GERMANY.
Change 22.176 Invalid SMF 42 subtype 5 caused INPUT STATEMENT EXCEEDED
VMAC42 error; this record contained only volume segments, with
Jul 21, 2004 422 valid segments, but the 423rd segment was overlaid.
It has valid S42VTNXT (00004FE4x) VOLSER (IMS210), DEVNR
(6BC5x) and S42VTFL1 (80x, indicating online), and 2 in
S42VTUNC, but the 2nd and 3rd offsets are overlaid:
S42VTVDO/S42VTVDL are '000000000000'x
S42VTVXO/S42VTVXL are '000000006C87'x and
S42VTVVO/S42VTVVL are '0001C4C2F2C2'x,
and the hex dump shows that last data is a VOLSER DB2B91
overlaying the third offset/length, and the rest of the
record is control unit information that doesn'b belong
there. MXG added tests to detect these invalid offsets,
and prints error messages for the first five bad records,
and prints a hex dump of the first bad record; variable
OFFVOL in the error message is the start of the defective
volume segment.
This text will be updated when an IBM fix is identified.
Thanks to Richard Haynes, Blue Cross Blue Shield of Kansas, USA.
Change 22.175 Major revision to this Utility to inventory the Contents
UTILCONT of SAS data libraries, reporting on size of each dataset
Jul 21, 2004 in MegaBytes, and the percentage of the library occupied
by each SAS dataset. The inventory can be output to the
ASUMSIZE dataset, which could be added to your PDB and
then TRENDed over time to monitor growth of your PDBs.
But only datasets are reported; DICTIONARY.TABLES doesn't
provide the size of CATALOGS (GRAPHS, SASMACR) in the
LIBNAMEs.
You can specify the list of LIBNAMEs to be inventoried
PDB=PDB WEEK MONTH (default is PDB=PDB), so to size the
datasets in yesterday's PDB in a standalone job on MVS
you would need to use this syntax:
// EXEC MXGSASV9
//PDB DD DSN=YOUR.PDB,DISP=SHR
//SYSIN DD *
%UTILCONT(PDB=PDB);
Under MVS, when you supply a list of LIBNAMEs, UTILCONT
issues a LIBNAME DDNAME SHR; statement for each LIBNAME;
the DICTIONARY.TABLES requires that each LIBNAME has
been 'referenced' (OPENed, or in a LIBNAME statement).
If any LIBNAME is sequential-format (e.g., tape), that
ENTIRE physical library must be read to find its size,
taking time and resources; you can skip reading of all
sequential format libraries using EXCLUDE=SEQUENTIAL,
or just don't put that LIBNAME in your list!
Instead, you can use PDB=_ALL_ to inventory all LIBNAMEs
that have been referenced; the _ALL_ choice enables the
EXCLUDE=SEQUENTIAL DUMMY GISMAPS LIBRARY MAPS SAS SASHELP
default list to skip sequential and 'SAS-owned' LIBNAMEs
that we think you don't want reported, but you can use
EXCLUDE=DUMMY GISMAPS LIBRARY MAPS SAS SASHELP in your
%UTILCONT invocation if you do want sequentials reported.
On MVS, the reported size closely matches the MVS dataset
allocated size, but on ASCII platforms the actual files
are slightly larger than the reported size; the directory
of variables is not included in pagesize*number-of-pages.
Change 22.174 Using the IDCAMS EXPORT Catalog function, the output file
VMACCTLG always has a few defective records, but those records do
Jul 20, 2004 not appear to actually contain any catalog segments. This
change revises the old "NOT UNDERSTOOD" MXG messages with
specific description of the two possible defects found.
IBM's "trench-holder" technican who "owns" the catalog
records refused to provide any documentation, claiming
the catalog records are "object code only", and their
contents could not be released, and his manager was also
unable to listen to reason (like, do they really think
think Microsoft is going to create a competing catalog
dataset, as kludgy as IBM's???), so I can only continue
to delete the defective records in the export file.
-The comments now contain the JCL for the IDCAMS program.
Thanks to Greg Burt, Fifth Third Bank, USA.
Change 22.173 Support for RMF 99 subtypes 3, 4, and 8 create four new
EXTY99U3 datasets:
EXTY994I dddddd dataset description
EXTY998L TY99U3 TYPE99_3 99-3 Service Class Period
EXTY998P TY994I TYPE994I 99-4 Device Cluster
IMAC99 TY998L TYPE998L 99-8 LPAR
VMAC99 TY998P TYPE998P 99-8 Priority Table
VMXGINIT -None of the "Plot" tables are created for these subtypes;
Jul 17, 2004 only tables that had test data are supported.
-I made blind guesses as to the format of two variables,
S998CPUT and S998PTMA.
Thanks to Richard S. Ralston, Humana, USA.
Change 22.172 ASCII only. Zero observations in TYPEVVDS because the
VMACVVDS INPUT of VVRTYPE was $EBCDIC1. instead of $CHAR1. Other
Jul 17, 2004 HEX-containing variables were also corrected and INPUT
with $CHAR and formatted with $HEX. On "MVS", $EBCDIC
and $CHAR are the same, but not so on ASCII platforms
This member was overlooked, because most sites use the
TYPEDCOL/DCOLLECT data to examine VVDS data, but the
TYPEVVDS has more detail information and is now correct.
Thanks to Glenn Bowman, Wakefern, USA.
Change 22.171 Enhancement for RMF III VSAM file reading program.
ASMRMFV -The very last CSR table entry was not being output.
Jul 16, 2004 -RMFV104I message for RED record type always showed Y for
SELECT, even when that table was not selected. Only the
message was incorrect; data exclusion did occur if RED
table was not selected.
Thanks to Jerome Urbaniak, Acxiom CDC Inc, USA.
Thanks to Len Romano, Hewitt Associates, USA.
Change 22.170 Support for TNG NT Windows Server 2003 Enterprise Ed 5.2,
EXTNT067 PLATFORM='WNE502I', added 35 new objects, some of which
thru are also created on PLATFORM='NTS500I. New NT datasets
EXTNT099 NT065 thru NT099 are documented in updated IMACTNG.
FORMATS -LENTEXT GT 99 tests caused errors with INSTANCE names
IMACTNG greater than 36 characters; all were revised to test for
VMACTNG GT 35 (TNG's base-35 encoding has '10'=36) to bump LOC
VMXGINIT by 2 positions; this should have been fixed earlier, but
Jul 16, 2004 -New MIB-2 Object data had over 12,000 instances for three
metrics, which makes little or no sense, and until that
data is better understood, only the first instance will
be output in new NT089 dataset.
-If you use the distributed TYPETNG/TYPSTNG members, you
must remove the %LET MAXROWS=1; statement that was added
by Change 22.160 to override the MAXROWS=288 MXG default
(288 supports 24 hours of 5-minute-interval data cubes).
-With MAXROWS=288 and the MXG default array sizes, the
TYPETNG program now needs about 300MB of virtual memory.
Thanks to Peter Krijger, National Bank of New Zealand, NEW ZEALAND.
Change 22.169 Support for Hogan System's optional CICS segment was not
IMACICHO complete; UTILEXCL recognized Hogan data was present, but
VMAC110 the IMACICHO member did not exist. It does now, and will
UTILEXCL create these four Hogan variables:
Jul 15, 2004 FPSAPPL - Application Code
FPSFUNC - Function Code
FPSCSCR - Current Screen
FPSSIPR - Previous Screen
Old code in IMACICUS had additional Hogan variables:
FPSACTN ='HOGAN*ACTION*CODE'
FPSOPTN ='HOGAN*OPTION*CODE'
FPSSCRN ='HOGAN*SCREEN*NAME'
PLDVERS ='HOGAN*PAS*VERSION'
TCTPLD ='HOGAN*ODS TCTNAME/*PAS PLDNAME'
TCBFUNC ='HOGAN*ODS TCT*TRANCODE'
and those variables will be in the _VCICTRN macro if the
Hogan data is detected by UTILEXCL, but only the fields
actually created in your IMACICHO will exist in CICSTRAN.
Thanks to Scott Wiig, USBank, USA.
Change 22.168 Support for HMF V2.7 adds subtypes 26, 27, 28 creating
EXTYHMFP St dddddd Dataset Description
EXTYHMFQ 26 TYHMFP TYPEHMFP ULTRANET SNMP TRANSPORT STATS
EXTYHMFS 27 TYHMFQ TYPEHMFQ ULTRANET SNMP TRANSPORT STATS
VMACHMF 28 TYHMFS TYPEHMFS ULTRANET SNMP DECOMPRESSION
VMXGINIT Variables in TYPEHMFT TYPEHMFU stored in the original
Jul 7, 2004 named/labeled variables; both 29 and 30 subtypes have
fewer variables, but Change 21.143 did not handle that
revision correctly.
Thanks to Perry Lim, Union Bank of California, USA.
Change 22.167 Variable STATIND in TYPE77 is a one byte numberic flag
ADOC77 byte, but it should have been formatted as HEX2. The bit
VMAC77 descriptions in ADOC77 were incomplete and incorrect, and
Jul 8, 2004 bit 6 ON was not even documented by IBM, but the bits are
now correct. A value of 03 is normal, as it indicates
that bit 6 and bit 7 are on, i.e., you have a GRS=STAR
configuration.
Thanks to Rodger Foreman, Acxiom, USA.
Change 22.166 Support for STK ExHPDM user SMF record.
EXHPDM00 DDDDDD DATASET DESCRIPTION
EXHPDM01
EXHPDM02 HPDM00 HPDMAU00 AUDIT STARTUP/SHUTDOWN
EXHPDM03 HPDM01 HPDMAU01 AUDIT CLIENT REQUEST
EXHPDM04 HPDM02 HPDMAC02 AUDIT CONNECTION ACCOUNTING
TYPEHPDM HPDM03 HPDMPE03 AUDIT STREAM TASK PERFORMANCE
TYPSHPDM HPDM04 HPDMAU04 AUDIT DATABASE TRANSACTION
VMACHPDM -Problems in data:
VMXGINIT Variable SOV2DEVN, 'Device Definition Name' has '0E'x in
Jul 19, 2004 in first byte, then 7 blanks in subtype 2, but is text
'DEVICE3' in subtype 3 records.
Thanks to Al Holtz, MEDCO, USA.
Change 22.165 BUILDPDB now detects "overlapped" SMF data was read in.
BUILD005 If you read the same SMF file in two separate PDB runs,
BUIL3005 or if you rerun BUILDPDB to re-create a PDB library and
Jul 8, 2004 did not restore the SPIN library, there will be duplicate
Aug 25, 2004 observations in the SPIN30_1 dataset; MXG now detects the
Oct 28, 2004 duplicates, and prints ERROR. DUPLICATE TYPE 30 SUBTYPE 1
messages on the SAS log. I had considered ABENDing for
this condition, but in this implementation, only error
messages are printed.
-The symptom that detected this problem was a change in
the number of observations in PDB.SMFINTRV, and messages
NOTE: MERGE STATEMENT HAS MORE THAN ONE DATASET... for
the TYPE30_V interval dataset, because the SPIN30_1 data
is used to populate the ACCOUNTn variables in PDB.SMINTRV
dataset, even though no interval records are "spun".
-For any rerun of BUILDPDB, you must restore the //SPIN
library to contain what it did before that failed run;
BUILDPDB automatically backs up your SPIN datasets into
the PDB library, so all you need do is to go back to the
last successfully build PDB library and restore the SPIN:
// EXEC MXGSASV9
//PDB DD DSN=LAST.GOOD.PDB,DISP=SHR
//SPIN DD DSN=YOUR.SPIN,DISP=OLD
//SYSIN DD *
PROC COPY IN=PDB OUT=SPIN;
SELECT SPIN: ;
and then you can rerun BUILDPDB with the SMF data that
failed; you may need to edit IMACZDAT to set the ZDATE
of the re-built PDB library, if you have skipped a day.
-Aug 25: Added restriction to only examine BAT/TSO/STC job
records with a JES Number. OMVS/USS creates multiple job
initiate records with the same READTIME/JOB/JINITIME and
a missing JESNR that erroneously caused the "duplicate"
MXG message.
-Oct 28: Corrected tests for BAT to JOB and TSO to TSU, as
those are the correct spelling of TYPETASK values. With
original spelling, only STC tasks were being examined.
And the CRITICAL ERROR. DUPLICATE TYPE 30 message now
shows where the overlapped records were found.
Thanks to Tim Gilchrist, Department of Defence, AUSTRALIA.
Thanks to Pat Curren, SuperValu Inc, USA.
Thanks to Udo Froehling, Signal-Iduna, GERMANY.
Change 22.164 The %VGETJESN invocation was moved after variable SYSTEM
VMACSFTA has been set. Initially, I saw no error in my tests, but
Jul 8, 2004 the PUT in VGETJESN for error conditions had a blank for
Aug 11, 2004 SYSTEM that was corrected by the relocation. However, I
now have test data that failed with error messages that
NOTE: INVALID NUMERIC DATA, STEPNAME='XXXX' that were
corrected by this change, so it all depends on which of
the SoftAudit files have data as to whether this change
is cosmetic, or required!
Thanks to Jim Kovarik, Aegon, USA.
Thanks to Ng Kin, Acxiom, USA.
Change 22.163 The SAS User SMF record does not contain enough data to
VMACSASU permit the use of the NODUP option in PROC SORT to safely
Jul 7, 2004 remove duplicates; NODUP removed 51,596 non-duplicates
from 2,687,811 SMF records. Using READTIME JOB SMFTIME
has only 10 milliseconds resolution, which is much larger
than the elapsed time of many SAS steps, especially the
repetitive SORTing of small datasets. A sequence number
of the proc/data step within the session is needed to be
able to safely remove duplicates, but for now, the NODUP
option was removed from the PROC SORT for TYPESASU, to
prevent the unwanted deletion of records that appear to
be duplicates, but aren't.
Thanks to MP Welch, SPRINT, USA.
Change 22.162 In TYPEBET0 dataset, new variable BETARETP, Retention
VMACBETA Period is now input as &PIB.4. where BETAEXPD was &PD4.,
VMACBE97 in VMACBETA, and in BETA974 dataset, variable B974XPDT is
Jul 7, 2004 input as &PD.4., as it is an expiration date.
Thanks to Ruben de Leeuwe, Independent Consultant, THE NETHERLANDS.
Change 22.161 Support for optional ESS segment GEPARMKY=003B creates
IMAC6ESS variable ESSITRAY (INTRAY) and GEPARMKY=0045 creates the
VMAC6 variable ESSPORNO (PORTNO) in TYPE6 when comment block
Jul 7, 2004 in member IMAC6ESS is opened.
Thanks to Engelbert Smets, Provinzial Rheinland Versich., GERMANY
Change 22.160 TYPETNG/TYPSTNG default array sizes, based on actual TNG
TYPETNG data from a large site, requires REGION=280M, but this
TYPSTNG caused INSUFFICIENT MEMORY errors in TESTOTHR step of the
JCLTEST8 JCLTESTn test job for sites that didn't even have TNG.
Jul 7, 2004 This change inserted %LET MAXROWS=1; so that only 20M
is required, but a site with real TNG data will need to
remove that statement, and may need 280M. However,
sites with TNG should read Change 21.269 which discusses
other MXG facilities for actual processing of TNG data.
Thanks to Pius Nwaobasi, IBM Global Services, USA.
Change 22.159 Variable SMF89LPI now always contains the correct LPAR ID
VMAC89 whether less than or greater than 15, and SMF89LP3 is no
Jul 5, 2004 longer kept, now that doc indicates what both contained.
Change 22.158 "Support" for JMF SMF 84 subtype 10, but only the header
EXTY84A variables are input; no one has actually ever requested
VMAC84 MXG to support this JES3-only SMF record, and I'd be very
VMXGINIT pleased if no one ever does.
Jul 5, 2004
Change 22.157 TYPE78IO new variable:
VMAC78 R783GFLG='IOQ*GLOBAL*FLAGS'
Jul 5, 2004
Change 22.156 TYPE73 new variables added by z/OS 1.5:
VMAC73 CHANDCMG='CHANNEL*PATH IS*DCM*MANAGED'
Jul 5, 2004 CHANCHCH='CHANNEL*PATH*CHARACTERISTICS*CHANGED'
Change 22.155 TYPE71 new variables added by z/OS 1.5:
VMAC71 SMF71PTH='AVG*TOTAL*SHARED*FRAMES*ABOVE 2GB BAR'
Jul 5, 2004 SMF71PCH='AVG*TOTAL*CSTORE*FRAMES*ABOVE 2GB BAR'
SMF71PAH='AVG*TOTAL*AUXSTORE*FRAMES*ABOVE 2GB BAR'
SMF71BLG='PEAK*SHARED*BYTES*LARGE*VIRTUAL'
SMF71PIH='PAGEINS*FROM AUXSTOR*FOR ABOVE*2GB BAR'
SMF71POH='PAGEOUTS*TO AUXSTOR*FOR ABOVE*2GB*BAR'
Change 22.154 TYPE1415 new variable created:
VMAC1415 SMF14EDI='EXTENDED*DATA*INTEGRITY*EDI*FLAG'
Jul 5, 2004 and FORMATed $HEX2.:
Bit Meaning
'1.......'B DSN found in EDI exclusion table
'.1......'B DSN being opened for out, already open in
'..1.....'B DSN being opened for in, already open out
'...1....'B application requested EDI be bypassed
Change 22.153 -TYPE6/PDB.PRINT variable SUBSYS='TCP ' is for PrintWay
VMAC6 basic mode records; SUBSYS='TCPE' is now set if the SMF 6
Jul 5, 2004 record is from PrintWay Extended mode records.
-New variables for PrintWay file transfer:
SMF6URI ='TARGET*UNIVERSAL*RESOUIRCE*INDICATOR*URI'
SMF6URIL='LENGTH*OF*URI'
SMF6FTL ='*FILE*TRANSFER*LEVEL*INDICATOR'
and SMF6BYTE is now input from PIB8 field.
Change 22.152 Support for IFA Processors, APAR OA05731.
FORMATS -TYPE70 dataset, new variables:
VMAC7072 IFAAVAIL='IFA Processor AVAILABLE?'
VMAC79 SMF70IFA='NUMBER OF*IFA PROCESSORS*ONLINE'
Jul 5, 2004 IFACROSS='IFA*CROSSOVER?'
Dec 12, 2005 IFAHONPR='IFA*HONOR*PRIORITY?'
-TYPE72GO dataset, new variables:
R723NFFI='*NORMALIZATION*FACTOR*FOR IFA*TIMES'
R723RCOD='CONTENTION*DELAY*SAMPLE*COUNT'
R723RCOU='CONTENTION*USING*SAMPLE*COUNT'
R723ECTC='CPU TIME*WHILE DP*RAISED'
R723IFAU='IFA*USING*SAMPLES'
R723IFEU='IFA-ELIGIBLE*ON CP*USING*SAMPLES'
R723IFAD='IFA*DELAY*SAMPLES'
R723IFAC='IFA*CPU TIME*ON IFA'
R723IFEC='IFA-ELIGIBLE*ON CP*CPU TIME'
-TYPE791 dataset, new variables:
R791TIFA='IFA*CPU TIME*ON IFA' (normalized to CP secs)
R791TCP ='CPU TIME*SPENT ON*STANDARD CPS'
R791TIFC='IFA-ELIGIBLE*CPU TIME*ON CP'
R791NFFI='NFFI*NORMALIZATION*FACTOR'
-TYPE792 dataset, new variables:
R792TIFA='IFA*CPU TIME*ON IFA' (normalized to CP secs)
R792TCP ='CPU TIME*SPENT ON*STANDARD CPS'
R792TIFC='IFA-ELIGIBLE*CPU TIME*ON CP'
R792NFFI='NFFI*NORMALIZATION*FACTOR'
Dec 12, 2005: TYPE791/TYPE792 variable names/labels now
match the actual variable names.
Change 22.151 Cosmetic, only labels were changed.
ADOC71 -CSLPFXAV/CSLPFXMN/CSLPFXMX contain only CSA FRAMES; back
VMAC71 in MVS/370 those variables contained the sum of CSA+LPA,
Jul 4, 2004 but ever since MVS/XA, they contain only the CSA Fixed
Frame counts, so LPA was removed from their Labels.
-Variables that had just "FRAMES" in their label now have
CSTORE*FRAMES if the area was CSTORE.
-Unfortunately, some variables in TYPE71 are in units of
byte-storage (and formatted MGBYTES to "print pretty"),
while these old variables still have counts of frames,
but there is no way to be consistent without destroying
your existing reports. Hindsight is wonderful, but can't
be applied now!
Thanks to Mayflor Dageforde, Blue Cross Blue Shield of Kansas, USA.
Change 22.150 The LPAR name variables for LPARs 16-32 were only one
VMXG70PR byte long; their initialization was corrected to eight
Jul 2, 2004 bytes to hold the full name.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 22.149 Enhancement to the UTILBLDP utility that "builds" a "PDB"
UTILBLDP (actually, builds the SYSIN code) for arbitrary combos of
Jul 1, 2004 SMF records:
- ZEROOBS= parameter supports subtypes, so datasets
built from specific SMF subtype can be created with
zero observations.
USERADD= 74,
ZEROOBS= 74.1 74.5,
creates TYPE74 and TYPE74CA with zero observations,
but all other TYPE74XX datasets will be populated.
- New MACFILEX= parameter allows insertion of code that
would normally be inserted with %LET MACFILE= ....;
UTILBLDP internally uses MACFILE=, so your MACFILE=
insert is ignored. Probably not needed, as the main
need for MACFILE= here was to suppress subtypes!
-See member JCLRMF
Thanks to Sue Castona, Rockwell, USA.
Change 22.148 With assistance from SAS developers, %VGETENG(DDNAME=XXX)
VGETENG returns the SAS Engine name (in macro variable &VGETENG)
VMXGENG and the Device Type (in macro variable &VGETDEV), if xxx
VMXGTAPE points to an existing SAS data library that was OPENed,
VMXGINIT and sometimes even if the library has not been opened.
Jul 6, 2004 The redesign also corrects these previous glitches:
Jul 20, 2004 - If the XXX pointed to a sequential format library,
on disk or on tape, the entire data library was read,
wasting CPU, I/O, and elapsed time.
- VMXGTAPE failed when the LIBNAME had not been opened.
-When a LIBNAME statement exists for XXX, VGETENG/VGETDEV
are always correct, whether XXX has been opened or not,
unless there is a LIBNAME (XXX or some other ddname) that
points to a non-existent data library on tape, i.e., a
DISP=NEW file that has not yet been written to.
The logic searches LIBNAMEs, and if an uncreated tape
DD is found (perhaps before your wanted XXX ddname) an
IEC145I 413-18 message is printed on SYSMSG and SASLOG
has an I/O ERROR HAS OCCCURRED message, and the search
is terminated (with a zero return code). If the XXX
ddname is the uncreated file, VGETENG will have the
Engine from LIBNAME XXX statement, but VGETDEV will
always be blank for an un-created file.
-If there is NO LIBNAME statement, the engine and device
are correct only if the DDNAME has been OPENED, but the
function does not fail; engine is UNKNOWN and device is
blanks for unopened or even uncreated ddnames, on tape or
on disk. Test %VMXGENG before using in production!
-If XXX accesses a REMOTE SAS/CONNECT file, the MVS device
type will be correct; on ASCII VGETDEV will be blank.
-The other %macros, VMXGENG and VMXGTAPE were revised with
the new logic, and return their original variables, but
they exist only for backwards compatibility, as MXG's
convention for %macros that "get" something is %VGETxxxx.
-VMXGINIT was updated to %GLOBAL macro variable VGETDEV.
LIBNAME Statement in SYSIN: YES NONE
VGETENG VGETDEV VGETENG VGETDEV
DISK
DISP=SHR/OLD REFERENCED CORRECT CORRECT CORRECT CORRECT
DISP=SHR/OLD NOT REFERENCED CORRECT CORRECT UNKNOWN BLANK
DISP=NEW CORRECT CORRECT UNKNOWN BLANK
TAPE
DISP=SHR/OLD REFERENCED CORRECT CORRECT CORRECT CORRECT
DISP=SHR/OLD NOT REFERENCED CORRECT CORRECT UNKNOWN BLANK
DISP=NEW CORRECT BLANK UNKNOWN BLANK
The 413-18 ONLY occurs when there is a LIBNAME, the
device is TAPE, and the DDNAME has not been referenced.
Thanks to Lewis King, SAS Institute Cary, USA.
Thanks to Rick Langston, SAS Institute Cary, USA.
Thanks to Chuck Hopf, MBNA, USA.
Thanks to Diane Eppestine, SBC, USA.
Change 22.147 Performance enhancements to reduce I/O and CPU time, by
ASUM42DS eliminating second pass of TYPE42DS, which was input to
Jun 30, 2004 VMXGSUM and then input again to ANALCNCR. The redesign
builds a View to create input to ANALCNCR at the same
time the data is being read into VMXGSUM. New SAS NOTES:
DATA STEP VIEW SAVED ON FILE WORK.SUM142DS
DATA STEP VIEW SAVED ON FILE WORK.MXGSUM1
THERE WERE x OBS READ FROM DATASET WORK.TYPE42DS
THE DATASET WORK.CNCR42DS HAS Y OBS AND 4 VARIABLES
COMPRESSING ....
MISSING VALUES ....
THE VIEW WORK.MXGSUM1.VIEW USED THE FOLLOWING RESOURCES
are printed on the log. The savings?
Resource Before After Redesign
EXCPs 1.8 Million 760K
CPU time 78 minutes 46 minutes
Elapsed 236 minutes 135 minutes
Thanks to Chuck Hopf, MBNA, USA.
Change 22.146 Most variables in the TYP119nn datasets, except for the
VMAC119 STARTIME and SMFTIME, were on the GMT clock, but all of
Jun 29, 2004 the internal variables are corrected to local time zone.
Thanks to Robert Sample, Atlanta Journal Constitution, USA.
Change 22.145 -TYPETCPC and TYPETCPF FTP Client/Server in SMF 118 record
VMACTCP has GMT time in TOD variables FTPSTART and FTPEND; they
Jun 29, 2004 are now corrected to local time zone.
-Variable ELAPSTM is added to TYPETCPC/TYPETCPF datasets.
-Without this change, ANALTCP reports sometimes had wrong
TOD and zero duration because of the GMT time issue. No
change was needed in the ANALTCP code.
Thanks to Robert Sample, Atlanta Journal Constitution, USA.
Change 22.144 DB2 Trace IFCID 140 variable QW0140RC, Return Code from
FORMATS Access Control Exit has legitimate negative value of -1
VMAC102 if the Exit was not called, so the input was changed to
Jun 29, 2004 IB instead of PIB; additionally, new format MGD140R is
created to decode all of the return codes. Also, the
QW0140RS, a four-byte reason code is HEX8. formatted.
-Additional new values for format MGD140P for V7 and V8
are added.
Thanks to Larry Stahl, IBM Global Services, USA.
Change 22.143 An example that reads only RMF SMF records to create an
JCLRMF "RMF-only" PDB library, including PDB.RMFINTRV, and the
Jun 29, 2004 PDB.ASUM70PR, PDB.ASUM70LP, and PDB.ASUMCEC summary data.
The default example skips the RMF 74 subtypes 1 and 5,
so that PDB.TYPE74 and PDB.TYPE74CA datasets will have
zero obs (i.e., they take no disk space).
This example uses the enhancement in Change 22.149.
Thanks to Sue Castona, Rockwell, USA.
Change 22.142 Support for Thruput Manager SMF record VARNAME/TOKENID of
VMACTPMX INNODE/16448, JBSBIND/50240, JVLVOL/57920, REQCLA/58082
Jun 28, 2004 was added to the CARDS; section; these VARNAMEs had only
blank values for TOKENID, but had existing variables.
Thanks to Kasandra Natzke, Information Resources, Inc, USA.
Change 22.141 Support for RMF 74 subtype 8 ESS LINK STATISTICS record,
FORMATS added by APAR OA04877, creates new dataset TYPE748 with
EXTY748 counts of I/O operations, Bytes Read/Written, and Active
VMAC74 Time for ECKD, PPRC, and SCSI devices. Also, TYPE74CA
Jun 28, 2004 dataset has Bytes Read/Written, and Time to Read/Write.
The APAR adds the fields to the 74-5 and 74-8 records,
but the new data is only populated if the ESS D/T 2105
device has micro code version 2.3.0.455 (Sand) or higher.
Thanks to Willy Iven, Fortis Bank, BELGIUM.
Change 22.140 ERROR: BY VARIABLES NOT SORTED FOR DATASET WORK.SPIN30TD
BUILD005 because Change 22.052 did not add STEPNR in all places
BUIL3005 where it was needed (CVRT30TD and SPIN30TD); fortunately,
Jun 25, 2004 the exposure only occurs if two adjacent steps have the
same INITTIME, and all sorts are now protectd.
Thanks to Rich Lopez, Johnson and Johnson, USA.
Change 22.139 The CICS ID variables in PDB.ASUMUOW: APPLID,USER,LUNAME,
UTILUOWC SYSTEM,TERMINAL, and USERCHAR were incorrectly kept from
VMXGUOW the LAST transaction segment, but should have been kept
VMXGUOWT from the FIRST transaction segment. The sort order was
Jun 29, 2004 was changed in Change 21.220, from descending ENDTIME to
ascending STRTTIME to recognize the TOR transaction as
the first transaction within the UOW, but the logic to
store those ID variables was not changed.
-LISTALL= argument, primarily for debugging, can now be
used to add any of the FRSTxxxx, LASTxxxx, and HOLDxxxx
variables to the PDB.ASUMUOW dataset.
-New UTILUOWC member can be used to examine the CICSTRAN
observations that made up a Unit-of-Work, for debugging.
-Oct 2, 2020: Revised UTILUOW replaces UTILUOWC.
Thanks to Carla Fleming, King County, USA.
Thanks to Sydney Cheung, King County, USA.
Change 22.138 The original ANAL4GBO member uses the SMF TYPE64 records
ANAL4GB to identify VSAM files that are approaching the 4GB size
ANAL4GBO limit, but that only saw VSAM files that were opened in
Jun 25, 2004 the SMF file that was read. This revision uses the
DCOLCLUS dataset, created from IBM's DCOLLECT option of
IDCAMS (JCL example in JCLDAYDS) so that all VSAM files
can be examined for their size.
- Using TYPE64, the HIGHALLOC was 3354M from TYPE64, but
LISTCAT showed only 1234M, because it was run at a
later time, and that VSAM file was defined as reusable
and an RST was specified on the ACB at OPEN, so it was
reset to empty before the LISTCAT was run.
Thus both members may be useful in tracking VSAM size.
Thanks to Dennis Cole, Commerce Bank NJ, USA.
Change 22.137 Support for z890 new CPUTYPE='2086'x, REQUIRED ONLY for
FORMATS OS/390 R2.10; MXG does not error with data from z890s,
VMAC7072 but without this change, MSU-containing variables will be
VMXGRMFI missing if you are still running your z890 under OS/390.
Jun 28, 2004 -The '2084x CPUTYPE tests added to support the z990 CPU
in Changes 21.141, 21.149, and 21.216 are expanded to now
also test for the '2086'x CPUTYPE of the z890.
-The table of "MSU" values in MG070CP format are updated
with IBM announced Software Pricing MSU for the z890,
which will eliminate the "CPUTYPE NOT IN TABLE" messages.
Thanks to Ed May, Western Power, AUSTRALIA.
Thanks to Al Sherkow, I/S Management Strategies, Ltd, USA.
Change 22.136 The SMF Exit code to put Initiator Name and Init Number
IEFU84 if the PROGRAM field in the SMF 30 subtype 1 record that
Jun 24, 2004 was announced in Change 19.269 now exists in the member
IEFU84, which is the JOB to assemble that SMF exit. Your
System Programmer will need to install the exit for you,
as it must be placed in an authorized load library, and
he/she will want to examine this SMF exit code.
MXG member VMAC30 already has the code in place and will
now populate the variables INITNAME and INITNUM after you
have installed the IEFU84 exit to add the data to SMF 30.
But note that only "real" initiators have names/numbers;
WLM-managed initiators will have blank initname and no
value for initiator number.
Thanks to Stan Dylnicki, Royal Bank of Canada, CANADA.
Change 22.135 The "MVS" SYSTEM NAME of each LPAR, SMF70STN, is added to
VMXG70PR datasets ASUM70PR and ASUMCEC as variables LP0STN-LPXSTN,
Jun 24, 2004 and in dataset ASUM70LP as SMF70STN.
Thanks to Jim S. Horne, Lowe's Companies, Inc, USA.
Change 22.134 The percentage of DURATM when each of the 32 CPU engines
VMAC7072 was online is added in variables PCTONLN0-PCTONLNX in the
Jun 24, 2004 TYPE70 dataset.
Thanks to Jim S. Horne, Lowe's Companies, Inc, USA.
Change 22.133 -Support for additional NDM-CDI Connect Direct subtypes:
VMACNDM FA,FI,GO,IF,NL,PI,SY,TP,TR,UU,WS,ZI
Jun 23, 2004 -Exit members EXNDMEV,EXNDMSB,EXNDMWS were deleted, as
those subtypes are now output into existing datasets.
-Comments in VMACNDM identify all known subtypes, those
that have known DSECTS, and those for which I have had
test data; if you have observations created in any of the
datasets identified as "NO DSECT", contact support@mxg.
Thanks to Jim Petersen, Washington Mutual, USA.
Thanks to Stuart Hubbard, Washington Mutual, USA.
Thanks to Thomas Heitlinger, FIDUCIA IT AG, GERMANY.
Change 22.132 This example for detail trace of the events in the life
ANALJOBE of a JOB did not keep CPUTM, had MULTIDD mispelled, did
VMACSYNC not use MACJBCK to select specific jobs whose events are
Jun 25, 2004 to be tracked, and deleted some 14/15 records for some
long-running jobs.
Change 22.131 NETSPY now writes both TYPENSPY and TYPENETM subtypes in
VMACNSPY one SMF ID, which caused messages ERROR.VMACNSPY.1 with
Jun 22, 2004 NSPYENTL=54754 and NSPYOFF=1539954642 in the text. This
change merges the VMACNETM code into the VMACNSPY code so
that NETSPY records (all of which have alpha subtypes)
and NETMASTER (which have two-byte hex subtype) are now
processed with the single TYPENSPY/VMACNSPY member to
creates all NSPY and NETM datasets. This change requires
MXG 22.01+, because of the new EXNETM50 and the revised
VMXGINIT members added by Change 22.037.
-While TYPENETM will still decode NETMASTER records, it is
now archaic, since TYPENSPY creates both NETMASTER and
NETSPY datasets.
-Change 22.243 is required; it corrected this change.
Thanks to Susan Fassette, Erie Insurance Group, USA.
Change 22.130 The "W0" in DSNAMEs in SAS V9 is only part of new naming
MXGSASV9 conventions, many of which are documented in the section
Jun 15, 2004 "Languages, Encodings, and Installation Codes" in the SAS
Aug 24, 2004 "Installation Instructions for SAS 9.1.2 Foundation for
z/OS" manual. The DSNAME and MEMBER names created depend
on the two NLS/LOCALE options for your country, the "XX"
Language Value and the "YY" Encode Value. Some DSNAMES
use XXYY, some member names end in YY, and both SASHELP
and SASMSG have ENYY in their DSNAME for the help and the
messages that have not been translated into local. For
example, "ENW0" for English in US, "DEW3" for most GERMAN
languages, but "DEWB" for GERMAN in Switzerland.
-To support this SAS change, the MXGSASV9 JCL procedure
example has two new symbolic parameters, &XX and &YY with
&XX=EN and &YY=WO as their default values, and you can
see in that JCL where the XX and where the YY is used to
form part of the DSNAME or MEMBER names.
-New DD statements added in V9 are also added in the JCL
example: TRNSHLP, ENCDHLP, and TMKVSENV.
Thanks to Bernd Klawa, Stat Bielefeld, GERMANY.
====== Changes thru 22.129 were in MXG 22.06 dated Jun 14, 2004=========
Change 22.129 "MVS" SAS only, I think! In SAS V9, the NLSCOMPATMODE
CONFIGV9 option was changed to default to NONLSCOMPATMODE, which
Jun 15, 2004 doesn't fail if your LOCALE option is ENGLISH or blank,
but with a LOCALE=GERMAN_GERMANY or other non-blank and
non-ENGLISH value, with the new NONLSCOMPATMODE option,
every "@" causes this error at compile time:
ERROR: The name 'A7'x49 is not a valid SAS name.
where that 'A7'x is a funny looking printed symbol.
(in the VMXGINIT code at statement INPUT @49 ....).
Changing the NONLSCOMPATMODE option back to the V8.2
default of NLSCOMPATMODE eliminated the error, so I have
added option NLSCOMPATMODE to the CONFIGV9 member, as it
appears to be safer, and I've listed the SAS help note
about the option for you to read, below. This note is
was added so MXG 22.06 could be completed, but it may be
revised when I know more about these options.
Specifying LOCALE=GERMAN_GERMANY and NONLSCOMPATMODE did
not cause a failure using SAS 9.1.2 under Windows/XP.
The SAS help documentation for NLSCOMPATMODE:
"NLSCOMPATMODE provides compatibility with previous
releases of SAS in order to process data in languages
other than English, which is the default language.
Programs that ran in previous releases of SAS will
continue to work when NLSCOMPATMODE is set.
When NONLSCOMPATMODE is in effect, SAS does not support
substitution characters in SAS syntax. If you run SAS
with NONLSCOMPATMODE, you must update existing programs
to use national characters instead of substitution
characters. For example, Danish customers who have
substituted the 'Å' for the '$' character in existing SAS
programs will have to update the SAS syntax to use the
'$' ("national character") in their environments.
Note: NLSCOMPATMODE might affect the format of outputs
that are produced using ODS. If you are using ODS, set
the option value to NONLSCOMPATMODE."
There is additional, extensive, documentation of LOCALE
and NLS in SAS Technical Note TS-653 at www.sas.com.
Jan 2012: See Change 27.356, which shows how to use the
CONFIMXG and // EXEC SAS and //MXGNAMES to use the site's
default SAS JCL and removes the NLSCOMPATMODE option.
Thanks to Bernd Klawa, Stat Bielefeld, GERMANY.
Change 22.128 New BLDIMPDB is "JCL" for ASCII platforms, for STEP03/04
BLDIMPDB of the JCLIMSLx/ASMIMSLx IMS log processing on ASCII SAS
TYPEIMSB platforms; BLDIMPDB provides the filename statements with
Jun 14, 2004 correct DCB attributes that are used after STEP01/STEP02
(which do not require SAS) were executed on "MVS".
-Member TYPEIMSB had to be changed to process character
fields containing hex data as $CHAR rather than $EBCDIC,
logic was added to convert text fields back to EBCDIC.
Thanks to Steven Hudson, Avnet Inc, USA.
Change 22.127 The example in comments to read SMF data (instead of PDB)
ANALFIOE was enhanced to create only the datasets, and keep only
Jun 14, 2004 the variables that are required, reducing run time and
DASD space. This is not needed if you run ANALFIOE with
BUILDPDB, since the PDB has all of the needed datasets
to analyze concurrent FICON Open Exchanges.
Thanks to Neil Ervin, Charles Schwab, Inc, USA.
Change 22.126 The "WO" must be "W0", i.e., w-zero not w-oh in the DSNs
MXGSASV9 and member names in the JCL example.
Jun 11, 2004
Thanks to Robert Chavez, Office Depot, USA.
Change 22.125 Support for Mobius/IPAC subtype 5 IPAC05 dataset duration
VMACIPAC variables were incorrectly input, but nobody had noticed,
Jun 9, 2004 until now. Version 6.2 data has been validated.
Thanks to Marty Wertheim, Bank of America, USA.
Change 22.124 MXG 22.04-MXG 22.05, QWHSSTCK was missing in SMF 102 DB2
VMACDB2H trace records after Change 22.090; the reset for ID=101
Jun 9, 2004 statement should have also have reset ID=102.
Thanks to David M. Forbes, McLeodUSA, USA.
Change 22.123 SAS Version 9 INCOMPATIBILITY, on "MVS" only, CRITICAL:
CONFIGV9 The MXG default value for the SAS system option S2=
UTILS2ER (it sets the line size of source statements that will
MXGSASV9 be read from %INCLUDE and AUTOCALL members),
Jun 8, 2004 which is set in the MXG CONFIGV9 member,
Jun 12, 2004 MUST now be changed for MVS from the MXG default of S2=72
(which was chosen so that SAS only read columns 1-72,
and prevented errors when user-written code had mixed
blank and non-blank lines, or had invalid line numbers
in columns 73-80. Only user-written code members had
the exposure, since all of MXG fits in 72 positions),
to be S2=0, because:
- MVS SASMACRO library was changed from RECFM=FB to VB.
There are no standards for line size of SAS-provided
%macros; previous MVS-used %macros fit in RECFM=FB, but
new V9 macros now have line sizes up to 255 positions.
These new macros were created on ASCII platforms,
where all text files are variable length, with 255
default length (which SAS handled because it treats
variable length input and fixed length differently),
so the coders (with no legacy background) had no
reason to restrict their code to the 72 bytes that
we had found necessary on MVS systems, and they did
all of their testing on ASCII platforms.
If they had known of the restriction, their macros
could easily have been written to fit, this change
wouldn't have been necessary, so you could have
read their source code, to understand and learn,
without line wrapping on green screen terminals!
- So the MVS folks had to change RECFM from FB to VB to
deliver these long-length %macros, and since the real
SAS System default is S2=0, the MVS QA tests did not
see any of the errors that their change causes when the
S2 option is set to S2=72.
- And, unfortunately, while MXG programs do use some of
the SAS-provided %macros (%LOWCASE,%LEFT,%CMPRES,%TRIM)
the utilities that use them (UTILBLDP,BLDSMPDB) weren't
executed with the arguments that happen to invoke them
in our QA, so we missed this V9 problem in our testing.
- The SAS Change to RECFM=VB with the MXG S2=72 default
has caused real errors, and has the potential for more:
- With VB and S2=72, real errors occurred:
A site that had always put their own local %macros
in the SASMACRO FB library in previous SAS versions
got "macro not found" errors when they copied their
%macros into the VB file, and executed with S2=72,
because SAS started reading in column 73, and never
saw their %macro definition. SAS Technical Support
recommended they change S2=0, SAS Note SN-011929,
which did correct this error.
An alternative to putting user %macros in the
SAS-supplied library is to put them in the MXG
"USERID" tailoring source library, because MXG
uses MAUTOSOURCE SASAUTOS=(SOURCLIB SASAUTOS)
precisely so that %macros will be found.
- But with VB and S2=0, potential errors may be worse:
Since MXG has always set S2=72, any text in your own
source code in columns 73-80 was ignored, but now,
if you have a member with invalid line numbers in
columns 73-80 (mixed numbers and characters; some
vendors use 73-76 for a line number and put version
characters in 77-80), or if you have a member with
unnumbered first line and numbers in later lines,
your perfectly running job now will fail under V9
(with a 180 syntax error, at the non-blank line),
and the defective numbering will not be identified.
That member must be either all unnumbered or all
lines must be numbered to eliminate this error.
MXG set S2=72 to protect users from the very common
human error we found in MVS systems, when a user
EDITed a new line with blank number into a member
that was already numbered, but now, you must detect
and correct those members so that S2=0 can be used.
- But since CONFIGV9 must now specify S2=0 to prevent the
real errors encountered, those potential errors due to
"bad" line numbers MUST be detected and corrected prior
to migration to V9. The new UTILS2ER program MUST be
run against each of your Source PDS libraries that have
SAS code; it will identify all members with "bad" line
numbers, so that you can EDIT those members and avoid
the potential errors caused by changing S2=72 to S2=0,
prior to migrating to SAS Version 9 on "MVS".
- Tutorial on S2 option values:
- The S2=72 option has completely different meanings for
RECFM=VB than for RECFM=FB:
-For FB, S2=72 says to only read the first 72 positions
-For VB, S2=72 says to skip the first 72 positions and
start reading in column 73!
- The S2=0 option is also different, for the two RECFMs:
-For FB, the last 8 columns of the first line of each
member is read; if that first line does not have a
valid sequence number, SAS reads the full LRECL of the
source line. If that first line has a valid sequence
number, SAS reads all but the last 8 columns of that
member's lines.
-For VB, columns 1-8 of the first line of each member
is read, and if a valid line number is found, SAS then
internally uses S2=8 to start reading in column 9.
If there is no line number in columns 1-8, SAS then
internally uses S2=0 to read the entire line length.
- Fortunately, SAS separately opens each member, so with
S2=0 and either FB or VB, SAS examines each member for
line numbers, so you can have one member without line
numbers, and another member with line numbers, even in
the same PDS, without any error; it is only when you
have invalid line numbers, or have a blank line before
a numbered line, that the 180 syntax error will happen.
Note that MXG did NOT change the S=72 default value:
- S controls SAS action on code read in from //SYSIN
- S2 controls SAS action on code read by %INCLUDE or
by SASAUTOS)
because you want that protection: it is very common to
have mixed numbered and unnumberd lines in your members
that have both the JCL and the SAS code, that you EDIT
and SUBMIT, and using S=72 allows that inconsistency,
so your job will continue to run without errors.
Summary of changes:
-CONFIGV9 now specifies S2=0 instead of S2=72.
-UTILS2ER is a new program to find S2=0 bad lines.
-MXGSASV8/V9 has //INSTREAM with SPACE=(CYL,(1,20))
instead of CYL,(1,1), which could only hold 168,000
lines of source for UTILS2ER. With (1,20) that temp
file has room for 3 million lines from each PDS.
Thanks to Michael L. Kynch, International Paper, USA.
Change 22.122 Cosmetic. Error messages were made consistent, with both
VMAC28 SYSTEM and SMFTIME printed with all errors.
Jun 8, 2004
Thanks to Pascal Maurice-Prestataire, La Poste, FRANCE.
Change 22.121 See the extensive discussion of DB2 Parallel Transactions
VMACDB2 (and the significant loss of DB2TCBTM if you have any)
EXDB2ACC in the "DB2 Technical Notes, Newsletter FORTY-FIVE).
EXDB2ACB -This old code in the MXG exit members EXDB2ACC/ACP/ACB:
EXDB2ACP IF DB2PARTY='P' AND QWACPARR='Y' THEN DELETE;
Jun 6, 2004 was removed by this change, and should be removed from
your exits. It was added by Change 20.266 to resolve a
problem with duplicate records, but the new DB2PARTY='R'
value is set when QWACPARR='Y', so the DELETE could never
have been executed.
-New value 'R' for the RollUp record, and value 'P' is now
for the Parallel Task (or Utility Subtask):
DB2PARTY Description Set by
'R' Rollup QWACPARR EQ 'Y'
'P' Parallel QWACPACE GT 00000000X
'O' Parent/Orig QWACPCNT GT 0, QXMAXDEG GT 0
'S' Sequential None of the above
-The code to set DBPARTY was relocated, and the test for
'O' is now set IF QWACPCNT GT 0 OR QXMAXDEG GT 0, which
is a stronger test for the Parent/Originating record.
Without this change, DB2PARTY was "S" for the Parent.
-In DB2PARTY='R' Rollup records QWACESC is not a datetime
value, but as noted in IBM APAR PQ41012, it contains the
total elapsed time for all child tasks, a duration. MXG
now detects when QWACESC is smaller than QWACBSC, (or if
QWACESC or QWACBSC are zero) and for those observations:
MXG stores the "QWACESC" time in variable CHIELPTM.
MXG creates QWACESC as datetime, equal to QWHSSTCK.
QWACBSC may be zero
ELAPSTM is set to missing
For all other observations, CHIELPTM will be missing,
and ELAPSTM=QWACESC-QWACBSC.
Thanks to Andy Creet, Department of Defence, AUSTRALIA.
Thanks to Andy Schuermann, Department of Defence, AUSTRALIA.
Change 22.120 MXG 22.05, MVS only, using UTILBLDP, you will get error:
CONFIGV8 APPARENT INVOCATION OF MACRO CMPRES NOT RESOLVED and
CONFIGV9 APPARENT INVOCATION OF MACRO LEFT NOT RESOLVED because
Jun 4, 2004 during tests for Change 22.102, I had mis-understood SAS
techs to say that the %LOWCASE and other %MACROS had been
implemented in base SAS, and that SASAUTOS was no longer
required, so I had changed SASAUTOS=SOURCLIB in testing,
but found it was only the function LOWCASE and not the
%macro %lowcase that had been implemented; unfortunately
I failed to go back and correct the SASAUTOS= statements
in those CONFIGVn members. The correct statement is
SASAUTOS=(SOURCLIB SASAUTOS)
which has always been required in CONFIGxx and AUTOEXEx
to retrieve the SAS-provided %macros that are not defined
in base SAS: %LOWCASE, %CMPRES, %LEFT, and %TRIM.
Thanks to Jim S. Horne, Lowe's Companies, Inc, USA.
Change 22.119 Cosmetic: Four of the BY statements in the _CHAIN macro
VMACCIMS were replaced by _BIMFTRN, since that "BY" macro had the
Jun 3, 2004 same variables as the replaced BY statements.
Thanks to Joe Babcock, Bank One, USA.
Change 22.118 Cosmetic: Semi-colons at the end of some MACRO _BTY91xx
VMAC91 were removed, to be consistent with other definitions.
Jun 3, 2004
Thanks to Joe Babcock, Bank One, USA.
Change 22.117 Support for optional ESS segment GEPARMKY=003B creates
IMAC6ESS variable ESSFRMLN (FORMLEN) in dataset TYPE6, when the
VMAC6 comment block in member IMAC6ESS is opened.
Jun 3, 2004
Thanks to Engelbert Smets, Provinzial Rheinland Versich., GERMANY
Change 22.116 Variables SMF70NSI SMF70NSA SMF70NSW were incorrectly
VMAC7072 divided by NRSAMPLE, which is ten times greater than the
Jun 3, 2004 SMF70DSA that should have been used.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 22.115 JES3 only. The BUILDPD3 program could use the wrong type
BUIL3005 26 purge record, which caused ABEND='JCL' for jobs that
Jun 2, 2004 had actually executed, especially for jobs that were read
in on one system and sent to a second system via NJE for
execution, because the first TYPE26J3 observation was the
one used. This revision uses the SYSEXEC field, which is
non-blank only in the "execution" purge record; all other
purge records are output in dataset PDB.DJEPURGE prior to
the logic that matches the purge record with the other
job records.
-The READTIME value can be different in the purge record
that was written for the job's output processing which
occurred on the original node. The first two 26 records
(one on the read-in system, one on the execution-system)
but the third 26 record had a READTIME that was after the
purge time of the execution purge record. As this was a
non-execution purge record, it is output in PDB.DJEPURGE,
but searching for it by READTIME would not find the obs.
Thanks to Ray C. Lau, Nav-International, USA.
Thanks to Roger Rush, Nav-International, USA.
Change 22.114 This VTS Library Statistics report replicated the IBM
ANAL94 report, but IBM uses the SMFTIME (end) rather than the
Jun 1, 2004 STARTIME (begin) of the interval, so, to match their
report, SMFTIME is now used, and the REPORT TITLE has
been modified to indicate it the end of the interval.
Thanks to Cheri Sample, Ford Motor Car Company, USA.
Change 22.113 ASCII execution only, using ASMIMSLx/JCLIMSLx steps 3 & 4
TYPEIMSA on PC, variable APPLID was unreadable because it was not
May 27, 2004 converted back to EBCDIC. APPLID=SUBSTR(DTOKEN,1,4); was
replaced by APPLID=INPUT(SUBSTR(DTOKEN,1,4),$EBCDIC4.);
Thanks to Mark Van Der Eynden, Hewlett-Packard Australia, AUSTRALIA.
Change 22.112 INPUT STATEMENT EXCEEDED if MVRECLEV EQ '02'X but you did
VMACEDGS see the circumvention in the comments to change the 58 in
May 26, 2004 _SKPEDGS to 122, because the INPUTs for MVAUTID1-8 were
not compared with their length. However, this error is
now eliminated, as logic now tests MVRECLEV and sets the
value to either +58 or +122 automagically.
Thanks to Chuck Hopf, MBNA, USA.
Change 22.111 Durn unix, and it's case sensitivity: these two members
BLDSMPDB must be all lower case, and all of the %UPCASE functions
BLDNTPDB must be changed to %LOWCASE, and when you type in the
May 26, 2004 %bldsmpdb(....) or %bldntpdb(....) those text lines
must also be typed in lower case.
-References to &SYSSCP were changed to &OPSYS, because
&SYSSCP is a SAS-owned macro variable that cannot be
%LOWCASEd, but &OPSYS is set in VMXGINIT and can be.
Thanks to Steven Hudson, Avnet Inc, USA.
Change 22.110 The label for R744STSA was reversed; it is now
VMAC74 R744SSTA='REQUESTS*CHANGED FROM*SYNC TO ASYNC'
May 25, 2004
Thanks to Thom Kight, Fidelity Systems, USA.
Change 22.109 -DB2 data written to GTF and read with TYPE102G caused
ANALDB2R INVALID DO LOOP CONTROL INFORMATION error.
ANALDBTR because some IFCID 070 and 071 Trace Records contain only
VMAC102 a product section; MXG expected a second section with the
VMACDB2H QW0070 and QW0071 DSECTs, as described in DSNDQW01. The
VMACSMF two IFCIDs now only INPUT the second if QWHSNSDA GE 2.
May 30, 2004 When QWHSNSDA=1, T102S070/T102S071 dataset will have
missing values for the variables from those DSECTS, i.e.,
QW0070FR/CK or QW0071RT/RS/NI/FR will have missing value.
-Additionally, these two IFCIDs have only the Standard DB2
Header and the CPU Header in their Product Section. the
Correlation Header does not exist, so the QWHCCN QWHCCV
and all QWHC variables are missing in T102S070/T102S071.
-The _GTFDB2 macro in VMACSMF was corrected to run under
ASCII SAS; $EBCDIC was changed to $CHAR and $HEX format
was added.
-The _GTFDB2 macro did not store TODSTAMP into QWHSSTCK,
so the use of GTF data for ANALDBTR to create "PAIRS"
datasets, and/or the use oF PMSQLnn reports in ANALDB2R
did not work, causing blanks for Interval Start, etc.
-ANALDBTR did not include _114PAIR in ALLPAIRS macro,
causing S114S115/S114S116 DATA SET NOT FOUND errors in
ANALDB2R.
-ANALDB2R had misspelling of QW006PG vice QW0006PG, and an
incorrect &TRACEIN..S183S183 that is now just S183183; it
had caused a DATASET PDB.S183S183 not found error.
Thanks to Wayne Montefiore, CSC GIS Engineering Services, AUSTRALIA.
====== Changes thru 22.108 were in MXG 22.05 dated May 22, 2004=========
Change 22.108 CRITICAL for SAS V9.1, if you did NOT install CRITICAL
CONFIGV9 SAS Hot Fix in SN-012437 for V9.1 and for V9.1.2:
VMAC110 Summary: -SAS V9.1, using V7SEQ,V8SEQ,or V9SEQ, creates
VMAC120 corrupted and un-readable datasets, with no
VMAC80A error messages until you try to read the data,
VMACOMDB and the data is NOT recoverable; it's lost!
VMACSMSX See the FLASH posted May 21 to MXG-L/ITSV-L,
VMACTMTC or see FLASH in Newsletters at www.mxg.com.
May 22, 2004 -SAS V9.1, using V6SEQ, creates valid datasets
that have no errors, but if a dataset has any
long-length variables (greater than 200 bytes),
the copy/write caused error messages, and you
could not copy/write that dataset.
-SAS 9.1.3 has corrected all known errors and
V9SEQ can be safely used; however, CONFIGV9
still has V6SEQ, because I cannot tell that you
are running under SAS V9.1.3.
-Under SAS V8.2, V8SEQ creates valid datasets,
and supports "long length" variables; the error
only occurs under SAS V9.1, without hot fix.
This revision shortens all "long-length" variables in
datasets from MVS data, so that SEQENGINE=V6SEQ can be
safely used without errors; and the change reinstates
the SEQENGINE=V6SEQ in the CONFIGV9 member.
There is now another CRITICAL change to CONFIGV9 that is
also required for SAS V9, in Change 22.123.
These SMF variables were reduced to $200 bytes length,
(and it is extremely unlikely that your MVS data has
and text longer than 200 bytes in these fields):
SMF TYPE Dataset Variable Orig length
80 TYPE80EK EKC80FRD 1024
80 TYPE8XEK EKC80FRD 1024
110 CICSJR SJRPRPTH 255
110 CICPGR PGRJVCLS 255
120 TYP120JI SM120JI7 400
120 TYP120WA SM120WAL 400
120 TYP120WA SM120WAQ 400
120 TYP120WI SM120WIQ 400
120 TYP120WI SM120WIW 400
USER SMSX IGDACSSC ACEROJFL 256
USER SMSX IGDACSSC ACEROMFL 256
USER SMSX IGDACSSC ACEROSFL 256
USER TMTC TMTCIS ISCONTCT 256
USER TMTC TMTCIS ISDESCR 256
USER TMTC TMTCIS ISLOC 256
USER TMTC TMTCIS ISNAME 256
USER TMTC TMTCIS ISOBJID 256
These MVS-but-not-SMF variables were reduced to $200,
(and data loss here is also unlikely):
Product Dataset Variable
Candle OMDB DB0035 QMDAASTR 247
Candle OMDB DB0630 QW0063ST 5000
Candle OMDB DB1920 QW0192DT 250
Candle OMDB DB2060 QW0206MR 256
Candle OMDB DB2060 QW0206MS 256
Candle OMDB DB2080 QW0208MR 256
Candle OMDB DB2080 QW0208MS 256
Candle OMDB DB2360 QW0236MR 256
Candle OMDB DB2360 QW0236MS 256
Candle OMDB DB2571 QW0257MS 256
Candle OMDB DB3120 QW0312PR 250
Candle OMDB DB3140 QW0314PL 256
Candle OMDB DB3190 QW0319D1 256
Candle OMDB DB3240 QW0324CP 254
Candle OMDB DB3270 QW0327MS 256
And what's at least "slick" about this change:
If you need the extra characters in these variables,
once you have installed the Hot Fix, you can increase
them back to their maximum length just by inserting a
LENGTH var1 var2 ... varn $256 ;
statement in one EXdddddd member for each product!
MXG code still INPUTs the original long length, but
this change inserted a LENGTH varx $200; statement
in the VMACxxxx member, but SAS uses the LAST
LENGTH statement, and the EXdddddd member's code
will then change the stored length of the variable.
But not all variables over 200 bytes were changed:
- These variables created by TYPEWWW from Web Logs were
unchanged; that code is normally run on ASCII SAS,
which does not use the SEQENGINE option, and
Dataset Variable LENGTH
WWWIIS BROWSER URISTEM 256
" COMPNAME CSBYTES CSHOST 4096
" CSVERSN PORT SCBYTES 4096
" SITENAME STATUS32 URIQUERY 4096
WWWLOG BROWSER URISTEM 256
WWWLOG URIQUERY 4096
WWWREFER REFERER 4096
WWWURQRY URIQVALU 4096
WWWCOOKE COOKVALU 4096
- These variables are ONLY longer that 100 bytes if the
COMPRESS=YES option is enabled, none of the datasets
are likely to be created in BUILDPDB nor archived,
especially the T102Snnn DB2 trace datasets that are
usually created only for ad hoc analysis. And all of
these variables can be changed by inserting
%LET SASCHRLN=100;
or
OPTIONS COMPRESS=NO;
as your first //SYSIN statement:
Dataset Variable LENGTH
T102S004 QW0004MS 32000
T102S005 QW0005MS 32000
T102S059 QW0059CN 32000
T102S061 QW0061CN 32000
T102S062 QW0062ON 32000
T102S063 QW0063ST 32000
T102S064 QW0064CN 32000
T102S065 QW0065CN 32000
T102S066 QW0066CN 32000
T102S090 QW0090CT 32000
T102S092 QW0092P1 32000
T102S097 QW0097P1 32000
T102S124 QW01242T 32000
T102S140 QW0140TX 32000
T102S141 QW0141TX 32000
T102S145 QW0145TX 32000
T102S168 QW0168ST 32000
T102S180 QW0180DS 32000
T102S194 QW0194DS 32000
T102S203 QW0203PA 32000
T102S204 QW0204TH 32000
T102S206 QW0206MR QW0206MS 32000
T102S207 QW0207HR 32000
T102S208 QW0208MR QW0208MS 32000
T102S236 QW0236MR QW0236MS 32000
T102T124 QW01242T 32000
T102T140 QW0140TX 32000
T102T141 QW0141TX 32000
T102T145 QW0145TX 32000
TMDBBD QW0140TX 32000
TMDBBD0 QW0140TX 32000
SHADOW06 SM06SQSR 32000
Note: Jan 11, 2011. Change 28.325 updated this list.
Thanks to Diane Parker, AmerisourceBergen Corp, USA
Change 22.107 Formats MGTMDRC for ASG/TMON DB2 and MGDB2RC for IBM DB2
FORMATS slightly out of sync, but now match.
May 22, 2004
Thanks to Chuck Hopf, MBNA, USA.
Change 22.106 Variables EDSDSMEM, EDSESMEM, EDTDSMEM, EDTESMEM were not
VMACENDV correctly input.
May 22, 2004
Thanks to Lindsay Oxenham, IBM Global Services, AUSTRALIA.
Change 22.105 MXG 22.04 ONLY. If there were no optional CICS segments,
UTILEXCL the IMACEXCL created by UTILEXCL failed with ERROR 22-322
May 22, 2004 on this statement: STRTTIME=STRTTIME+MCTMNTAD-MCTMNLSO;
The error was due to a mislocated comment symbol after
the LASTCHEK: label around a debugging PUT statement.
-ZDATE protected if _RPTEXCL run against PDB.CICSDICT that
had been created by an old UTILEXCL prior to ZDATE keep.
Thanks to George Waselus, Arizona State Department of Admin, USA.
Thanks to Noel D'Sousa, CSC, AUSTRALIA.
Thanks to Helmut Roese, Com-Software, GERMANY.
Change 22.104 Support for Candle Omegamon II for DB2 IFCID Trace data
TYPE102C that is written to a sequential file. Use the file name
VMAC102 //CANDB2 to point to their file, and %INC the TYPE102C
VMACSMF program to create obs for all IFCIDs in the file.
May 20, 2004
Thanks to Joseph Pugh, Fujitsu, ENGLAND.
Change 22.103 Cosmetic. Example had lines 648 and 652 the same; the
DOCPDB second MACRO _LDBJOBS &PDBJOBS..JOBS % statement in
May 20, 2004 line 652 was deleted.
Thanks to Christa Neven, KBC BankVerzekeringsHolding, BELGIUM.
Change 22.102 SAS under unix does not fileref SASAUTOS (SN=000444), and
AUTOEXEC this caused NO LOGICAL ASSIGN FOR SASAUTOS followed by
AUTOEXEU WARNING: Apparent invocation macro LOWCASE not resolved.
May 20, 2004 ERROR 23-2: Invalid option name ) messages, plus the MXG
Version number and date are missing from this message:
MXG DATED HAS BEEN SUCCESSFULLY INITIALIZED.
The real cause of this error is that the %LOWCASE macro
function is not implemented in base SAS, but instead is
provide as a %MACRO in the "SASAUTOS" library; if that
function (and %LEFT) were in base SAS, there
would be no need to concatenate the "SASAUTOS" fileref
with the MXG SOURCLIB. For both z/OS and Windows and
Linux, SAS does "fileref" the SASAUTOS (with a -SET in
the SASVn.CFG file, so this syntax in the MXG-provided
AUTOEXEC.SAS works just fine.
OPTIONS MAUTOSOURCE SASAUTOS=(SOURCLIB,SASAUTOS);
However, under unix, you must provide the "pointer" to
the SASAUTOS directory; you could use a FILENAME to do
that, but it is simpler to use the new AUTOEXEU member
for your autoexec.sas under unix, as it contains
OPTIONS SASAUTOS=(SOURCLIB !SASROOT/SASAUTOS);
which should be the correct location of unix sasautos.
For Windows, of course, the location is different, and
OPTIONS SASAUTOS=(SOURCLIB !SASROOT\CORE\SASMACROS);
is the correct syntax.
If any of the above fail in the future, all you need do
is to search your disk for the file "lowcase.sas", which
will be found in some directory under the sas root, and
use that directory name in your AUTOEXEC/AUTOEXEU file.
Thanks to Steven Hudson, Avnet Inc, USA.
Change 22.101 Support for VIO/PLUS subtypes 1 and 2 create new datasets
EXTYVIOL subtyp dddddd dataset description
EXTYVION 1 TYVION TYPEVION VIO PLUS NON-VSAM STATISTICS
IMACVIOP 2 TYVIOL TYPEVIOL VIO PLUS LOAD STATISTICS
VMACVIOP and eliminates INPUT STATEMENT EXCEEDED RECORD LENGTH
VMXGINIT error. Both new subtypes have been validated with data.
May 5, 2004
Thanks to Billy Westland, Kaiser Permanente, USA.
Thanks to Raff Rushton, Kaiser Permanente, USA.
Change 22.100 Invalid SMF 80 created by EKC's ETF/R FIRECALL product
VMAC80A caused INPUT STATEMENT EXCEEDED RECORD LENGTH ERROR. The
May 4, 2004 second segment length was 197, but only 7 bytes remained
in the record. This vendor's "ETFR" modified SMF 80 was
supported by Change 21.215, after a similar error in that
record was circumvented by Change 21.201. This new EKC
record contains "EKCS" rather than "ETFR", and eventually
I'll support that unique record, also, but for now, this
additional test will prevent your daily job from ABENDing
no matter what EKC comes up with next.
May 22: EKC Inc fix for this error is their PTF LK12029.
Thanks to John Grasing, Metropolitan Life, USA.
====== Changes thru 22.099 were in MXG 22.04 dated May 2, 2004=========
Change 22.099 Documentation only. If a "dddddd" macro variable WTNT063
VMXGINIT %GLOBALed but was not %LET a value, then SAS syntax
May 2, 2004 errors 22, 202, and 455 and their messages were created:
+ &WTNT063..NT063
22
202
455
ERROR 22-322: Syntax error, expecting one of the following:
a name, a quoted string, RC, _DATA_, _LAST_,;, _NULL_.
ERROR 202-322: The option or parameter is not recognized
and will be ignored.
ERROR 455-185: Data set was not specified on the DATA
statement.
Change 22.098 Variables LCPUSHAR,LPnSHARE in ASUM70PR/ASUM70LP/ASUMCEC
VMXG70PR are the Initial Weight of the LPAR (SMF70BPS). Now, new
May 2, 2004 variables LCPUSHAC,LPnSHARC in those datasets contain the
Current Weight of the LPAR (SMF70ACS).
Thanks to Karl Lasecki, Chemical Abstracts Service, USA.
Change 22.097 Assembly error for ASMRMFV if an old OS/390 MACLIB was
ASMRMFV used: "ASMA017W Undefined keyword parameter - GETDS/LOC"
May 2, 2004 because the old GETDSAB macro did not support LOC=ANY.
Reassemble with a current z/OS MACLIB, or you can remove
",LOC=ANY" from the GETDSAB macro call in ASMRMFV source,
if you're still stuck with an old system and MACLIB.
No change was made in MXG code; documentation only.
Thanks to Dr. Alexander Raeder, Itellium, GERMANY.
Change 22.096 Global macro variables &MACINTV and &MAC30DD are defined
IMAC30DD in VMXGINIT and located in IMACINTV and IMAC30DD so that
IMACINTV TYPE30_V(PDB.SMFINTRV) and TYPE30_D(PDB.DDSTATS) datasets
VMXGINIT can be optionally created using %LET MACINTV= syntax as
May 2, 2004 an alternative to EDITing the IMAC members.
Thanks to Dr. Alexander Raeder, Itellium, GERMANY.
Change 22.095 Support for OS/400 5.2 QAPMMIOP with three new fields
VMACQACS that were added compatibly at the end of the record;
May 2, 2004 the length for QAPMMIOP is now 290 instead of 272.
Thanks to Clayton Buck, UniGroup, USA.
Change 22.094 CICS/TS 2.3 records with no excluded fields had wrong
VMAC110 values for all variables after CBSRVRNM in the CICSTRAN
May 1, 2004 dataset. If, instead, you had excluded fields from SMF,
Aug 13, 2004 like all my test CICS/TS 2.3 data, and used the UTILEXCL
program to create your IMACEXCL tailoring member, that
code did input CBSRVRNM correctly as $EBCDIC4., but the
code for un-excluded records input CBSRVRNM as $EBCDIC8,
throwing every thing else in the record off by 4 bytes.
Note: Not to defend my error, but I do STRONGLY recommend
that even if you do not have any EXCLUDEd fields in
CICS data, you should still use UTILEXCL to create
a tailored IMACEXCL for your installation; it will
minimize the size of CICSTRAN by keeping only the
CICS variables in your current release(s), and some
some optional CICS fields are only decoded if you
use UTILEXCL to create an IMACEXCL to create your
CICSTRAN data.
Aug 13: More Important Note: Variable TASCPUTM is one of
the VERY MANY CICSTRAN variables that are wrong if you
read CICS/TS 2.3 records without this change. As listed
in CHANGES since last May, MXG 22.04 or later is the
REQUIRED version to support CICS/TS 2.3 records fully.
Thanks to Helmut Roese, COM Software, GERMANY.
Change 22.093 Cosmetic. Blank lines between FIRST/LAST record messages
VMACSMF were removed, _N_= value is consistently located, and new
May 1, 2004 Start of Read SMF and End of Read Time of Day messages.
Change 22.092 For SMF 116 Subtype 1 and 2, the CICS and IMS id fields,
VMAC116 variables QWHCTNO,QWHCTRN,QWHCTASK for CICS and
May 1, 2004 variables QWHCPST, QWHCPSB for IMS
were not in the same location as the subtype 0 record.
New input statements correct those variables in the
MQMACCTQ and MQMQUEUE datasets.
Thanks to Helmut Roese, COM Software, GERMANY.
Change 22.091 Variable PCTALLBY in dataset TYPE78CU should have always
VMAC78 been a missing value, with z/OS 1.2+, per the June, 2002,
May 1, 2004 note added to the text of Change 19.203, but it has been
alway 100% instead of missing. The test was revised so
that it now is as documented, always missing value.
Thanks to Phil Baxter, Cap Gemini Ernst & Young, ENGLAND.
Thanks to Simon Bolland, Cap Gemini Ernst & Young, ENGLAND.
Change 22.090 MXG 22.02-22.03 only. Change 22.045 corrected QWHSSTCK in
VMACDB2 DB2STATx datasets (so statistics intervals would MERGE),
VMACDB2H but that change caused QWHSSTCK in the DB2ACCTx datasets
May 1, 2004 to be zero (printed as year 1960).
-MXG Logic in VMACDB2H was revised to RETAIN the STCK of
the first ID=100 record in variable STATSTCK, and use
QWHSSTCK=STATSTCK for statistics data, but directly use
QWHSSTCK=THISSTCK for ID=101 DB2ACCTx datasets.
-The RETAIN QWHSSTCK in VMACDB2 was removed as not needed.
Thanks to Dean Ruhle, J. C. Penney, USA.
Change 22.089 Variable QWHCCV was INPUT $EBCDIC12. in MXG 20.20, but as
VMAC116 the field contains both EBCDIC text characters and binary
May 1, 2004 hex values, the INPUT was changed to $CHAR12 in MXG 21.21
so that the hex values were preserved when MXG executed
under ASCII. On EBCDIC platforms, there is no difference
between $EBCDIC and $CHAR, but $CHAR informat variables
must be formatted $HEX: a binary '00'x value, PROC PRINTd
can stop VTAM output, so QWHCCV is now $HEX24 formatted.
16Jan04: Note that my choice to format QWHCCV as $HEX24
will cause printed reports to be expanded from 12 to 24
positions.
Thanks to Dean Ruhle, J. C. Penney, USA.
Change 22.088 If VMXGRMFI is invoked a second time with PDB= non-null,
RMFINTRV to re-read the PDB.TYPE7xx datasets to create different
VMXGRMFI output "PDB.RMFINTRVs", perhaps with different workload
Apr 30, 2004 definitions, the SPINRMFI dataset was reused and became
May 19, 2004 corrupted, causing spurious observations to be created.
Note:
This does NOT happen with the example in RMFINTRV using
PDB=, TRENDIN=PDB.RMFINTRV, to resummarize the first
output to create separate hourly and daily summary
datasets PDB.RMFINTHR and PDB.RMFINTDY. When the PDB=
argument is null, the SPINRMFI dataset is not used.
The SPINRMFI is only needed to keep the prior day's
last four hours, for calculation of MXG's MSU4HRAV.
If your PDB= argument is non-null in subsequent VMXGRMFI
invocations, you must use the SPINRMIN= argument to name
your spin dataset (e.g. SPINRMIN=SPINRMXX,), so that that
summarization's SPIN will be in SPIN.SPINRMXX dataset.
The default value for SPINRMIN is SPINRMFI, and I suggest
you use SPINRMxx naming convention for your dataset.
-This change also created new argument SPINRMOU, for the
output dataset name, for consistency, but it is unlikely
to be used. SPINRMOU defaults to the value in SPINRMIN.
-Each VMXGRFI with PDB=non-null must use a different SPIN
dataset; the SPINRMIN= argument changes the dataset name,
but the default "SPIN" library is used for all of them.
There is an alternative: you can have multiple "SPIN"
libraries, instead of multiple "SPIN" datasets, using the
&SPININ/&SPINOUT macro variables created in Change 22.018
(so that you could have different input and output SPIN
libraries so you could use a GDG for your SPIN library).
So you could %LET SPININ=SPIN01, to change the DDNAME for
each %VMXGRMFI invocation.
-May 19: Example in comments in RMFINTRV was missing the
comma after SPINRMIN=SPINRMDY, now corrected.
Thanks to Karl Lasecki, Chemical Abstracts Service, USA.
Thanks to Jim S. Horne, Lowe's Companies, Inc, USA.
Change 22.087 Non-PR/SM systems. Datasets PDB.TYPE70 and PDB.RMFINTRV
VMAC7072 had variables IORATE and PCTTPI too low; they contained
Apr 30, 2004 values from only the last CPU, instead of the totals.
This error was introduced in MXG 21.05 when Change 21.170
moved the three lines inside the PR/SM Control Section,
which does not exist on non-PR/SM systems. The lines are
relocated after the PR/SM Control Section (NRPRCSS) loop.
Thanks to Dean Ruhle, J. C. Penney, USA.
Change 22.086 The second IF ID=xx AND MVSXA THEN DO; statement should
VMAC74 have been ELSE IF ID=xx ...., for performance reasons,
VMAC75 and to be consistent with SMF TYPE logic in MXG, but it
VMAC76 had no other impact on execution.
VMAC77
Apr 30, 2004
Thanks to Dr. Alexander Raeder, Intellium, GERMANY
Change 22.085 Support for TNG NT platform SESSION and USER objects:
EXTNT063
EXTNT064 dddddd Dataset Description Vars Instances
FORMATS TNT063 NT063 SESSION 77 181
IMACTNG TNT064 NT064 USER 17 75
VMACTNG You must update your MXG Format Library with this FORMATS
VMXGINIT member (see FORMAT step of JCLINSTL).
Apr 29, 2004
Thanks to Peter Krijger, National Bank of New Zealand, NEW ZEALAND.
Change 22.084 Large QBSTGET in PDB.DB2STATB after Change 22.045 occurs
VMACDB2 if the DB2 Subsystem was restarted, and the buffer pool
Apr 29, 2004 was not used in every interval. MXG Logic was revised
to use QWHSACE to detect a restart had occurred.
Thanks to Steve Dyck, Canadian Depository for Securities, CANADA.
Change 22.083 Support for additional unix AIX PTX objects create new
EXAIXIP datasets:
EXAIXNFS dddddd dataset description
EXAIXRPC AIXIP AIXIP AIX IP DATA
EXAIXTCP AIXNFS AIXNFS AIX NFS DATA
EXAIXUDP AIXRPC AIXRPC AIX RPC DATA
IMACAIX AIXTCP AIXTCP AIX TCP DATA
VMACAIX AIXUDP AIXUDP AIX UDP DATA
VMXGINIT
Apr 29, 2004
Thanks to Glenn Bowman, Wakefern, USA.
Change 22.082 Variable MEMINBOX in NTCONFIG dataset was 1/100th of the
VMACNTSM actual memory in the box; the INFORMAT MEMINBOX 16.2 was
Apr 28, 2004 changed to INFORMAT MEMINBOX 16. because the value is an
integer, and does not have two implied decimal places.
Thanks to Diane Parker, AmeriSource Bergen, USA.
Change 22.081 -If the translate table used to send TNG ASCII data to MVS
VMACTNG created '9E'x/'9F'x for Left/Right Square Bracket & '4F'x
Apr 28, 2004 for Exclamation Point, those unexpected values caused MXG
Apr 29, 2004 ERROR: UNEXPECTED CAPMPCM HEADER RECORD. The Left Square
Bracket test now has '9E'x for that EBCDIC value, and has
'92'x, because the ftp of the '9E'x value back to ASCII
created that unexpected value. The full test now is:
IF TYFLG IN : ('[','5B'X,'AD'X,'BA'X,'92'X,'9E'X)
-Change 21.269 blanked variable DOMAIN, but did not note
that there is no "domain" value in TNG, and that variable
should not have been created. SYSTEM is the one to use.
-The "DATA FROM PLATFORM" message now has the SYSTEM from
each new Header record; it was blank in the first message
and had the prior record's SYSTEM value in the rest.
Thanks to Gunner Jacobsen, Nordea, NORWAY.
Change 22.080 Variable CPUTM was removed from PDB.CICS built from ASG-
ASUMCICT The Monitor's MONITASK dataset, since TASCPUTM is the TCB
Apr 28, 2004 CPU time variable. CPUTM had been removed from PDB.CICSs
built by ASUMCICS and ASUMCICX by was accidentally left
in the ASUMCICT member.
Thanks to Frank Lund, EDB IT Drift, NORWAY.
Change 22.079 Support for IBM Session Manager User SMF record creates
EXIBSMSM IBMSESMG dataset. Unfortunately, there is no field that
IMACIBSM indicates what Application was connected to, so for a
TYPEIBSM specific USERID/LTERM (variables SSTUSER/SSTTNAM), that
TYPSIBSM connected to multiple applications, records with overlap
VMACIBSM between Session Start (SSTSTRTT) and SMFTIME (Signoff).
VMXGINIT Use SMFTIME instead of the lower resolution SSTSTIME for
Apr 28, 2004 the signoff time. Query to IBM as to why there is no
field for the application to which session connected.
Thanks to Dave Crandall, Farmers Insurance, USA.
Change 22.078 Cosmetic. Variable PCTDLCCA Label was corrected to be
VMAC7072 PCTDLCCA='CPU*CAPPING*DELAY*PERCENT'
Apr 27, 2004 instead of RESOURCE*GROUP... (which is in PCTDLPDE).
Thanks to Ronald Kveton, Experian, USA.
Change 22.077 Support for "second flavor" of ACCT fields; original data
VMACTPMX had the "standard type 30 job accounting string", but new
Apr 27, 2004 data has multiple ACCT fields; new logic detects which is
present and still populates ACCOUNT1-ACCOUNT9, LENACCT1-
LENACCT9 from the individual fields.
-TSSUSR2 and TSSUSR3 fields now supported.
Thanks to Lawrence Jermyn, Fidelity Systems, USA.
Change 22.076 Cosmetic. Variable _N_ was added to PUT statements for
IMACACCT error conditions and messages were single spaced.
Apr 27, 2004
Change 22.075 ARRAY SUBSCRIPT OUT OF RANGE error occurs if you have
VMAC74 more than 255 structures in your CF; the temporary arrays
Apr 27, 2004 allocated only 255 elements, but they have been raised to
1024 elements, which I believe is the maximum number of
structures supported in a CF.
Thanks to Bob Miller, CONSECO, USA.
Change 22.074 DB2 Trace SMF 102 Subtype 125 dataset T102S125 variables
VMAC102 QW0125PC QW0125PL QW0125PN QW0125TS QW0125SN were missing
Apr 27, 2004 values because the test for QWT02R1L GE 64 should have
been GE 62. The original DSECT showed two reserved bytes
but those bytes do not exist in the current record, so
the +2 at the end of segment was also removed.
Thanks to Ron Alterman, PG&E, USA.
Change 22.073 SMF 119 Subtype 10 dataset TYP11910 had invalid values in
VMAC119 variables UCINDTGR UCOUDTGR UCINBYTE UCOUBYTE because +2
Apr 27, 2004 was needed to skip two reserved bytes before UCINDTGR.
Thanks to Thomas Heitlinger, FIDUCIA IT AG, GERMANY.
Change 22.072 For Service or Reporting Classes with R723CWMN GT 0, not
VMAC7072 all periods were output. With three periods, only the
Apr 27, 2004 first period was output; with four periods, only the 1st
Aug 5, 2004 and 2nd periods were output. This is NOT a new error;
MXG has always been this way:
Inner loop IF R723CWMN GT 0 THEN DO _I_=1 TO R723CWMN;
(for the two state/delay sections), and the outer loop
(for each period), DO _I_=1 TO NRSCS; used the same _I_
variable! Transaction Service Classes have R723CWMN=2
(begin and end entries), causing _I_=3 when R723CWMN=2,
so if NRSCS (number of periods) was 2 or 3, only the
first period's data was created. (With 4 periods in
the service class, only the first and second period
data was output, but not the 3rd nor 4rd, etc.).
The DO variable in the inner loop was changed to _II_ to
correct this error.
-The April text cited R723TYPE=3 as the only exposure, but
the error actually occurred with any service or reporting
class with R723CWMN non-zero. This text was revised in
August, but the April code change was not affected.
Thanks to Tom Koelle, CitiGroup, USA.
Thanks to Dave Crandall, Farmers Insurance, USA.
Change 22.071 Test string for "SAS Product SMF Record" change to SASU
UTILBLDP (it was SAS) to correctly include VMACSASU, etc., when
Apr 26, 2004 SAS USER records are to be processed.
Thanks to Dr. Alexander Raeder, Itellium, GERMANY.
Change 22.070 Modification to VMXGSUM to prevent a bizzare abend that
VMXGSUM should not happen but did happen in one isolated case,
VMXGSUME where a slash was used. Addition of %STR resolved.
Apr 26, 2004
Change 22.069 The BLDSMPDB utility for daily/weekly/monthly/trend PDB
BLDSMPDB had used SMF= for its input argument, but Change 22.060
Apr 26, 2004 replaced hardcoded SMF DDname in VMACSMF with &SMF, which
caused BLDSMPDB code to fail; the name in BLDSMPDB was
changed to SMFIN= to eliminate the conflict and error.
Thanks to ???, ???, USA.
Change 22.068 -Support for optional RMI data for both CMODNAME='RMI' in
VMAC110 IMACICRM and CMODNAME='DFHRMI' in IMACICRD adds similar
UTILEXCL but different sets of RMIxxxxx variables.
IMACICRD -UTILEXCL was revised to support DFHRMI and RMI segments;
IMACICRM without this change, if CMODNAME='DFHRMI' was in the CICS
Apr 17, 2004 dictionary, the IMACEXCL created by UTILEXCL failed with
a SAS 180 error, underscoring variable TRANTYPE.
Thanks to Neil Ervin, Charles Schwab, USA.
Change 22.067 Ending */ comment was missing, but the only impact was
SPUNJOBS that work datasets were not be deleted.
Apr 16, 2004
Thanks to Dov Brosch, Bank Hapoalim, USA.
====== Changes thru 22.066 were in MXG 22.03 dated Apr 5, 2004=========
Change 22.066 Cosmetic. Labels for SOMSGIN1 and SOMSGOU1 were reversed.
VMAC110
Apr 5, 2004
Thanks to Allan J. Winston, MBNA, USA.
Change 22.065 The six undocumented ESS fields in SMF 57 (Change 22.057)
VMAC6 are also in SMF 6 records, and are decoded in variables
Apr 5, 2004 SMF6C1, SMF6C2, SMF6C3, SMF6N1, SMF6N2,and SMF6N3
Thanks to Rainer Hertwig, Lufthansa Systems Infratec GmbH, GERMANY.
Change 22.064 -Executing "MONTHBLD" on ASCII platforms caused errors, as
AUTOEXEC it was designed to run on "MVS", with RECFM=FB, which SAS
MONTHASC does not honor on ASCII; it presumed MVS JCL provided the
INSTALL required //DUMMY DD'; it created the MONTHPDB in "tape"
Apr 2, 2004 (sequential) format, to eliminate MVS tape mounts, etc.
This new MONTHASC member executes under ASCII and creates
a "disk" format SAS Data Library, but it also executes on
"MVS", and it may be preferred there, now that Virtual
Tape drives have eliminated most of the concerns about
tape mounts, and the "disk" format library with directory
is much faster to access a single dataset; furthermore,
the "disk" format PDB can be migrated to tape by HSM!
-AUTOEXEC member was revised to add LIBNAME DUMMY, which
is used for "dummy" datasets in MONTHASC.
-INSTALL for MXG install under ASCII was revised to note
that you need to create c:\mxg\dummy directory and the
c:\mxg\userid\instream.sas file, if you did not copy the
MXG product from CD-ROM (that directory and file are now
created on the CD-ROM).
Thanks to Joe Keey, BOC, ENGLAND.
====== Changes thru 22.063 were in MXG 22.03 dated Apr 2, 2004=========
Change 22.063 The delay percentages in TYPE72GO are calculated by using
VMAC7072 R723CTSA, execution samples, if it is non-zero as the
Apr 1, 2004 denominator, replacing VALDSAMP. But PCTDLTDQ, pct total
delay including batch, when there was batch queueing is
incorrect, because in that case, VALDSAMP and R723CTSA
can be major-different (R723CTSA=7, VALDSAMP=202,206!),
so the calculation of PCTDLTDQ is now based on VALDSAMP
instead of R723CTSA, to get a sensible percentage!
Thanks to Phil Baxter, CGEY, ENGLAND
Thanks to Simon Bolland, CGEY, ENGLAND.
Change 22.062 When REPORT=ALL is specified, the HTTP report abends with
ANALRMFR ERROR: FILE WORK._LTY1031 DOES NOT EXIST. The HTTP report
Apr 1, 2004 logic was not included in the "ALL" logic, but now it is.
Thanks to David Klein, DOITT - City of New York, NY.
Change 22.061 Cosmetic. VARIABLE QWGTDSC1 IS UNINITIALIZED had no
UDB2GTF impact; it was in a Debugging PUT that was not executed.
Apr 1, 2004 This UDB2GTF utility is required as a pre-step to convert
GTF 256-byte "chunks" into readable VB records, which can
then be read by MXG. The output DDNAME of UDB2GTF is
GTFOUT, so to process that converted file, you would use
%READDB2(GTF=GTFOUT,IFCIDS=ALL) to create all possible
DB2 datasets and populate those found in your data.
Thanks to George French, Liberty Mutual, USA.
Thanks to John Pierce, Liberty Mutual, USA.
Change 22.060 -The ARRAYs added in TYPETPMX in MXG 21.21 cause horrific
EXTPMACT CPU time increases, from 3 Minutes to 71 Minutes for
EXTPMAFF TYPETPMX to read 4 million SMF records (4GB), of which
EXTPMAFT only 16,000 (70MB) were TPM records. (Processing the SMF
EXTPMBFR file of only those 16K TPM records took 3 CPU minutes.)
EXTPMBND The ARRAYs were used to store the variables that can have
EXTPMBVL multiple instances (like the list of VOLSERs used), and
EXTPMDEA you had to update IMACTPMX to tell MXG the maximum number
EXTPML10 of instances of each of the arrays. The problem is that
EXTPML11 real variables were defined in each array, and that was
EXTPML12 the cause of the CPU increase; for real variables, SAS
EXTPML13 initializes each array variable before each SMF record
EXTPML14 is read. Using _TEMPORARY_ instead of real variables
EXTPML15 eliminated the CPU hit, as did removing the ARRAYs and
EXTPML16 their references.
EXTPML17 -With real variables in an ARRAY, SAS initializes every
EXTPML18 one of the variables for each new SMF record, even for
EXTPML19 the non-TPM SMF records that are skipped after their ID
EXTPML20 in INPUT and tested, before any arrays were referenced.
EXTPML21 -The only solution was to completely rewrite TYPETPMX and
EXTPML22 eliminate the use of real variable ARRAYs, and instead,
EXTPML23 create 34 new TPMxxxxx datasets, one for each variable
EXTPML24 that can have multiple instances, keeping the instanced
EXTPMLL1 variable and JOB JESNR SMFTIME SYSTEM variables so you
EXTPMLL2 can select and report, or use those key variables to
EXTPMLL3 JOIN the instanced dataset with TYPETPMX if needed.
EXTPMLL4 There is a counter variable in TYPETPMX for each of the
EXTPMLL5 instanced variables to tell you if there are instances.
EXTPMLL6 -The %LETs that you were required to update in IMACTPMX,
EXTPMLL7 which told MXG the maximum number of instances are no
EXTPMLL8 longer required and were removed ("a Good Thing"), as
EXTPMLL9 were the now-unnecessary DROP statements in the EXTYTPMX
EXTPMLLM exit member for those instanced variables. And TYPETPMX
EXTPMLMT dataset now has only 480 variables, but you may have to
EXTPMVVL revise your TPMX reports as a result of this redesign.
EXTYTPMX -Before TYPETPMX was redesigned, a circumvention was seen
IMACTPMX possible: my changing the hardcoded INFILE SMF ... in the
VMACSMF MACRO _SMF definition in VMACSMF to INFILE &SMF ..., and
VMACTPMX transparently adding %LET SMF=SMF in VMXGINIT, you could
VMXGINIT then change the INFILE name "on the fly", and could use
Apr 1, 2004 the MACFILE exit to send the TPM records to a temp file,
and then use "TYPETPMX" only against the TPM records:
// EXEC MXGSASV9
//SMF DD YOUR.SMF,DISP=SHR
//SMFOUT DD UNIT=SYSDA,SPACE=(CYL,(200,200))
//SYSIN DD *
%INCLUDE SOURCLIB(VMACTPMX); /*defines _IDTPMX*/
%LET MACFILE=
%QUOTE(
IF ID=_IDTPMX THEN DO;
FILE SMFOUT DCB=SMF;
PUT _INFILE_;
FILE LOG;
END;
);
%INCLUDE SOURCLIB(BUILD001);
RUN;
%LET MACFILE= ;
%LET SMF=SMFOUT;
%LET PTYTPMX=PDB;
DATA _VARTPMX; _SMF; _CDETPMX; RUN;
%INCLUDE SOURCLIB(BUILD002,BUILD003,BUILD004,BUILD005)
Although this specific need to change the SMF infile to
use the temporary SMFOUT file is no longer needed with
the revised TYPETPMX support, it was left in place for
possible future use.
Thanks to Richard S. Ralston, Humana, USA.
Change 22.059 New CICS/TS 2.3 Pool variables were added using reserved
VMAC110 fields in STID=60 subtype 2 SMF 110 stat record, but were
Mar 30, 2004 not input (no vertical bars in CICS Data Areas!):
Mar 31, 2004 DSGMMWTS DSGMMWTM DSGCMMWS DSGPMWWS DSGCMMWT
DSGTOTMT DSGTOTMW
DS2MMWTS DS2MMWTM DS2CMMWS DS2PMWWS DS2CMMWT
DS2TOTMT DS2TOTMW
DS3MMWTS DS3MMWTM DS3CMMWS DS3PMWWS DS3CMMWT
DS3TOTMT DS3TOTMW
These new variables measure TCB Mismatch Waits/durations
and MVS Storage Waits/durations, and are output in the
CICDSPOO datas for the three pools.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 22.058 -Temporary variable SHFTTIME should have been DROPed in
IMACSHFT IMACSHFT when it was added by Change 21.204; now it is
VMACTMDB DROPped so it will not be kept in any MXG dataset.
Mar 29, 2004 -Variables added to ASG Monitor for DB2 in Change 21.237
were not labeled.
Thanks to Chris Weston, SAS Institute ITRM, USA.
Change 22.057 -Support for the optional ESS fields in TYPE57J2, for JES2
VMAC57 sysout transmission between NJE nodes; the ESS variables
Mar 29, 2004 are now (optionally) created if your IMAC6ESS member has
been tailored (comment block removed) to keep them.
-Six undocumented variables SMF57C1-C3 and SMF57N1-N3 are
decoded from the 28 bytes following SMF57TUL; they will
be re-labeled if their documentation can be located.
-SMF 57 is created when sysout was sent thru this JES2 NJE
node, but it counts only the number of logical TP records
(which may or may not count actual lines or images!).
-The SMF 57 record is also created by unisys's DEPCON
(output management tool), which routes print from unisys
to the z/OS print queue. While actual lines printed may
not be available, at least the destination printer is
available, but as there is no MVS "job" that created the
output, merging with BUILDPDB for unisys print accounting
is not really possible.
Thanks to Rainer Hertwig, Lufthansa Systems Infratec GmbH, GERMANY.
Change 22.056 Q3STHWIB variable should still be good; UNINIT Q3STHIWB
VMACDB2 note caused by a typo, but code is executed only if field
Mar 26, 2004 wrapped, and the next interval's Q3STHIWB value is valid.
Thanks to Lori A. Masulis, FMR, USA.
====== Changes thru 22.055 were in MXG 22.02 dated Mar 24, 2004=========
Change 22.055 TYPE42DS variable AVGIOQMS=RESP-PND+DIS+CON+CUQ is often
VMAC42 a negative 0.128 milliseconds, which is one clock tick in
Mar 24, 2004 the type 42 "clock", and AVGIOQMS is at best an estimate
of an average value. Since this is a calculated value,
rather than a value in an SMF record, I think it wise to
just set these negative values to zero, and document what
I've done here, so you don't get sidetracked by the small
negatives; the max AVGIOQMS was 902 Millisec/SIO.
Thanks to Ron Alterman, PGE, USA.
Change 22.053 Cosmetic. The MXG-created character variable CPCFNAME
VMXGRMFI was inconsistently built, sometimes with a dash 2064-2C8,
VMXG70PR sometimes without, 20642C8. It now always has the dash.
Mar 24, 2004
Thanks to Kenneth D. Jones, xwave, CANADA.
Change 22.052 PDB.STEPS can have some EXCP, IOTM, TAPEDRVS, TAPNMNTS
BUILD005 and TAPSMNTS counts from one step of a job output in the
BUIL3005 previous step of that job, if both steps have exactly the
VMAC30 same INITTIME: the first step was FLUSHED (condition code
Mar 23, 2004 bypass), so it was never initiated, nor allocated, nor
executed), AND, the next step initiated instantaneously,
without any delay, in the same 10 millisecond clock tick.
MXG's BUILDPDB logic was revised to use INITTIME STEPNR
instead of INITTIME to separate the two steps, so these
I/O counts are now output in the correct PDB.STEPS obs.
While I/O counts were in the wrong PDB.STEPS observation,
the values were correct, so the PDB.JOBS observation did
have the correct total I/O counts for the job (although
the TAPEDRVS count could have been incorrect). Also, in
PDB.STEPS the STEPNR was not equal to variable STEP (but
that is normal for restarted jobs, as STEP is a counter
of steps executed, and restarted jobs will have multiple
instances of the same STEPNR with different STEP values).
-Member VMAC30 had to be changed to add STEPNR to KEEP=
list for the TYPE30TD dataset.
Thanks to John R. Parla, CIGNA, USA.
Thanks to Ray Dunn, CIGNA, USA.
Thanks to Paul E. Cohen, CIGNA, USA.
Change 22.051 The Multi-System Remote Enclave CPU segment is 80 bytes
BUILD002 instead of the 20 bytes documented in SMF; I have guessed
VMAC30 what some of the fields contain, but the MRENxxxx names
Mar 22, 2004 will likely be changed when I understand what's what.
Mar 24, 2004 But assuming the data is eventually valid, I have added
Jan 12, 2005 _STY30MR to the BUILD002 so that PDB.TYPE30MR will now be
automatically created in the PDB library in BUILDPDB/PD3.
-Jan 12, 2005: This Change was COMPLETELY wrong; the code
was completely revised by Change 22.345, with correct
SMF30MRx variable names.
Thanks to Chuck Hopf, MBNA, USA.
Change 22.050 IRD caused wrong PCTCPUBY in TYPE70 and RMFINTRV datasets
VMAC7072 for intervals in which engines were varied offline. The
VMXGRMFI MXG support for IRD should now be complete; it was added
Mar 22, 2004 in these increments for these "CPU-measuring" datasets:
Datasets When MXG Version Change
ASUM70PR/ASUMCEC Sep 22, 2003 21.05 21.170
TYPE70PR Mar 11, 2004 22.01 22.011
TYPE70,RMFINTRV Mar 22, 2002 22.02 22.050
MXG accumulated CPUWAITM for each engine only when it was
online at the end of interval (CAIx='01'B), but when IRD
varies an engine CAIx='11'B, so CPUWAITM for that engine
was not added, causing CPUACTTM and PCTCPUBY both to be
too large. Now, CPUWAITM is accumulated if SMF70ONT is
non-zero (i.e., the engine was used, a stronger test).
-An unrelated error in the first RMF interval after an IPL
was also detected and corrected. The first records have
their interval DURATM greater than SMF70ONT, but CAI0=01
so engines were not varied off. For one IPL, the 25 sec
difference caused PCTCPUBY and CPUACTTM to be NEGATIVE!
These first interval records have short DURATM because
RMF is synchronizing with time of day:
IPL TIMESTAMP STARTIME DURATM SMF70ONT
22FEB04:02:15:05.95 02:19:12.00 0:09:47.39 0:09:24.26
22FEB04:02:22:46.45 02:26:59.00 0:02:00.63 0:01:35.19
22FEB04:01:28:39.42 01:31:52.00 0:12:07.05 0:11:39.81
I conclude that RMF starts to count DURATM before engines
are available for use, so MXG now uses SMF70ONT (if it is
non-zero) instead of DURATM to correct IBM's error.
-Variable CPUPDTTM is added to PDB.RMFINTRV. (It was the
validation of this user request that exposed the prior
MXG error!).
Thanks to Kenneth D. Jones, Xwave, CANADA.
Change 22.049 Variable TMNTUSER added to the Mount record is actually
VMACTMNT the existing LOCLINFO variable (in all JOB-related SMF
Mar 21, 2004 records), so TMNTUSER variable no longer exists.
Change 22.048 If SPF Statistics are enabled, the MXG.SOURCLIB PDS will
JCLINSTL now require 1199 directory blocks; JCL examples with 999
JCLTEST9 blocks were increased to 1199. Without SPF statictics,
COVERLTR only 399 blocks are required.
Mar 21, 2004
Thanks to Peter Giles, Centrelink, AUSTRALIA.
Change 22.047 -Datasets QAPMTCP and QAPMIFC were not automatically built
TYPEQACS by TYPEQACS/TYPSQACS, so they were not listed in DOCVER.
TYPSQACS -Variables PCTCPUBY NRCPUS were not labelled in QAPMSYSL.
VMACQACS -Variable INTSEC was not kept in QAPMTCP nor QAPMIFC.
Mar 21, 2004
Thanks to Chris Weston, SAS ITRM, USA.
Change 22.046 %VMXGTIME was invoked before SYSTEM had been input in two
VMACRMFV places; the %VMXGTIME and IMACSHFT invocations were moved
Mar 20, 2004 to below the INPUT of variable SYSTEM.
Thanks to Michael Oujesky, MBNA, USA.
Change 22.045 Dataset PDB.DB2STATB was not protected for wrap of 4-byte
VMACDB2 counters, which caused negative values in variables like
Mar 20, 2004 QBSTDPP,QBSTGET,QBSTRIO,QBSTSGT,QBSTSPP,QBSTSWS, all of
which can have very large raw values before their DIF().
All other DB2 variables that are DIF()'d were protected.
This error was introduced in Change 21.140 when DB2STATB
was restructured and I forgot to protect for wrapping.
Thanks to Ron Alterman, PGE, USA.
Change 22.044 The %%INCLUDE SOURCLIB(VGETJESN) should have been only
ANALEPMV one %INCLUDE SOURCLIB(VGETJESN) because it is inside a
Mar 18, 2004 %MACRO statement; two are needed inside MACRO statements.
Thanks to David Klein, DOITT - City of New York, NY.
Change 22.043 APPL records with or without the nine APPRM variables are
VMACMWUX supported in a heuristic test for LENGTH LE/GT 565, based
Mar 18, 2004 on 535/536 length without, 594/595 with, in test data.
Thanks to Miguel Fernandez, Information Services International, USA.
Change 22.042 DB2 Statistics SMF 100 Subtypes 0, 1, and 2 have always
VMACDB2H been written to SMF in order, but because their QWHSSTCK
Mar 18, 2004 datetime values could be fractions apart, I retained STCK
from each 0 into its 1 so DB2STAT0 and DB2STAT1 had the
same value in QWHSSTCK, so they could be MERGEd to create
DB2STATS directly. But now, one site's DB2 6.1 SMF 100
records are completely out of order, with subtype 0 with
an earlier STCK written after that interval's subtype 1
with a later STCK value, and MXG's algorithm to create a
common QWHSSTCK value created this ERROR message:
DB2 TYPE 100 SUBTYPE 1 FOUND AT START OF INPUT FILE.
The error corrupts the DB2STATS0,DB2STATS1 and DB2STATS
datasets; QWHSSTCK will have wrong values, and subtype 1s
from one interval may be merged with subtype 0 from next
interval in the DB2STATS dataset, and negative values in
DB2STATB dataset may result when this message is printed.
-The QWHSSTCK logic now recognizes the start of interval
as a delta of 10 seconds, and the first record's STCK is
now stored in QWHSSTCK for all three STAT subtypes.
-It's only a guess as to why this has not been seen before
but it may be the "tactical" interval of one minute that
exposed the error; for whatever reason, it is now clear
that each of these subtypes are created by independent
subtasks, so their physical writes are not in any order,
and my ASSUMEption of order was wrong.
Thanks to Ron Alterman, Pacific Gas and Electric, USA.
Change 22.041 If you EXCLUDEd variable OPERATOR or TERMINAL in CICS SMF
ASUMCICS and if you used ASUMCICS (which we no longer recommend)
Mar 17, 2004 to create PDB.CICS, the length of OPERATOR and TERMINAL
are now $1, but they were $4 in previous versions. This
can cause a warning if you combine PDB.CICS datasets in
your MONTHBLD that were built with two different versions
of MXG. This change restores the length to $4 for both.
See Change 21.xxx on why ASUMCICS may not be the
right program to use.
Thanks to Gary Keers, AES, USA.
Change 22.040 The ANALALL example, which selects all SMF records from a
ANALALL JOB(s), creates all MXG datasets from those SMF records,
Mar 17, 2004 and then prints all observations and all variables, can
also be used to create an SMF output VBS file with all of
the selected SMF records. Comments in the member show
how to add
FILE SMFOUT DCB=SMF;
PUT _INFILE_;
FILE LOG;
after the IF JOB=: selection in %LET MACJBCK=, and how
to add an //SMFOUT DD statement for those records.
Thanks to Alex Puno, LACO, USA.
Change 22.039 If you use the _N42 macro to null data set creation, the
VMAC42 _WTY4237 null definition was missing; it has been added.
Mar 16, 2004
Thanks to Jon Whitcomb, Great Lakes Educational Loan Services, USA.
Change 22.038 ML-31 of the Exit-Based MXG Tape Mount, Allocation, and
ASMTAPEE Allocation Recovery monitor corrects GMT timestamps that
Mar 15, 2004 should have been on the local clock, and supports an IBM
Mar 25, 2004 MSC APAR that changed bit meanings. The MXGTMNT DIAG
command provides additional diagnostics in its WTO text,
but will also write a "dump" to a file (for sites where
taking a "system dump" is political issue), if there is
an MXGDUMP DD included in the monitor program's JCL:
//MXGDUMP DD RECFM=FB,LRECL=4160,BLKSIZE=4160,
// UNIT=SYSDA,SPACE=(CYL,(100,100)),
// DISP=(,CATLG),DSN=YOUR.CHOICE
The DIAG command is issued from a console:
F jobname,DIAG
where jobname is the "job" name of the MXGTMNT monitor.
-The IBM IEF-VOLUME-MNT exit in our Exit-Based logic is
not called by StorageTek's HSC software, so you will NOT
see any mount records with HSC with MXIT=YES in ML-31.
Now that we've examined the dump and saw that STK did not
call the IBM exit, and knew who/what to ask, STK has been
very cooperative in providing documentation of HSC, so I
believe it is only a matter of time (weeks?) before our
"asmguy@mxg.com" will develop the needed enhancement to
support both HSC and IBM tape mounts with MXIT=YES.
April 1, 2004.
Change 22.037 Support for NetMaster subtype 5000x record, Performance
EXNETM50 Monitoring record.
IMACNETM
VMACNETM
VMXGINIT
Mar 24, 2004
Thanks to Andy Creet, Department of Defence, AUSTRALIA.
====== Changes thru 22.036 were in MXG 22.01 dated Mar 11, 2004=========
Change 22.036 The MG070CP format, used only if you are still on OS/390,
FORMATS or running z/OS on a non-zSeries machine, was updated for
Mar 11, 2004 the 2066-E1 and 2066-X2 processors.
Thanks to Al Sherkow, I/S Management Strategies, Ltd., USA.
Thanks to Edward Ogonosky, Blue Cross Northeast PA, USA.
Change 22.035 The z/VM MONWRITE "User" dataset, VXBYUSR, was left in
VMACVMXA the //WORK file and was not written to the //PDB, but now
VMXGINIT is; this is the dataset with interval data for each CMS
Mar 11, 2004 "user", i.e., each VM Machine, and is THE dataset to use
to track individual Linux-under-VM machine activity. Only
the default output "DDname" was changed.
Thanks to Reinhard Kelm, GAD, GERMANY.
Change 22.034 -Support for Candle optional CANADABN and CANADABT fields
IMACICD4 (for Adabas Count/Duration variables of same NAME) is
IMACICD5 added. UTILEXCL will detect and tell you to open the
UTILEXCL comments in the appropriate IMAC, if fields exist in your
VMAC110 CICS SMF 110 records, with Candle's additions.
Mar 10, 2004
Thanks to James Hein, Erie Insurance, USA.
Change 22.033 -Support for XIDTYP='A' ADAPATER record in new QAPMIOP5
EXQAPIO5 dataset.
IMACQACS -Correction for LRECL=359 QAPMIOPD record which has an
VMACQACS extra byte betwen XIDTYP and XIDTA1.
VMXGINIT
Mar 10, 2004
Thanks to Stan Dylnicki, Royal Bank of Canada, CANADA.
Change 22.032 Support for Endeavor Release 4.0 user SMF (INCOMPATIBLE,
VMACENDV because ELEMT, DSNAME, and DSMEM fields were relocated.
Mar 10, 2004 The Action Record (subtype 2) has been validated with
new data; the Block Header's record version had to be
used to identify the new format record because C1VER was
not changed (only has before/after 2.5), and SM2RECVN is
'01' in the new records. The Security Record (subtype 2)
also had incompatible changes, and has been coded, but no
subtype 1 records have been validated. The DSECT shows
a subtype 3 (ESI Exception) and a subtype 4 (MCF CHANGES)
but there is no sub-DSECT for those records; if a 3 or 4
is found, MXG will print one record on the log.
Thanks to John Paul, Highmark, USA.
Change 22.031 The ASUMJOBS logic calculated the Initiation Wait Time as
ASUMJOBS IWT=INITTIME-JRDRTIME, but JRDRTIME is only in the Purge
Mar 9, 2004 record, so a PDB.JOBS observation that did not have a
Purge record (probably because member IMACSPIN had not
been tailored to change MXG's SPINCNT=0 default) had a
missing value for JRDRTIME, causing IWT to be missing.
This caused the summarized observations in PDB.JOBSKED to
have incorrect bucket percentages because IWT missing was
counted as a zero-wait job. It also caused IWT (summed)
to be equal to IWTMAX in some obs that had NUMJOBS more
than one (but closer examination showed that these case
actually had had only one job with non-missing IWT!).
The IWT calculation was revised; if JRDRTIME is missing,
IWT=INITTIME-SUM(READTIME,RDRTM) is used, as those data
are in the JOB Termination record. And if the IWT is
still a missing value, that job will be deleted.
Thanks to Miguel F. Montferrer Carvajal, RSI EDS, ESPAGNE.
Change 22.030 Support for DF/SMS Storage Class Exit User SMF record,
EXSMSXSC written at Storage Class assignment, so you can examine
FORMATS how your ACS rules actually perform. New dataset:
IMACSMSX dddddd Dataset Description
TYPESMSX SMSXSC IGDACSSC DF/SMS STORAGE CLASS EXIT
TYPSSMSX I arbitrarily only output the first six VOLSERS of the
VMACSMSX possible 1464 volumes that a dataset can have, until
VMXGINIT someone needs all of them!. I was unaware of that limit.
Mar 9, 2004
Thanks to Tobias Cafiero, Depository Trust and Clearing Company, USA.
Change 22.029 Support for new SMF 117 record from WBIMB, WebSphere
EX117FLO Business Integration Message Broker creates four new
EX117THR datasets:
EX117NOD dddddd Dataset Description
EX117TRM 117FLO S117FLOW MESSAGE FLOW
FORMATS 117THR S117THRD THREAD
IMAC117 117NOD S117NODE NODE
TYPE117 117TRM S117TERM TERMINAL
TYPS117 Data for FLOW, THREAD, and NODE have been validated.
VMAC117
VMXGINIT
Mar 8, 2004
Thanks to Victoria LePak, AETNA, USA.
Thanks to Jeff Martens, AETNA, USA.
Change 22.028 The BY-list-macro _BCICRDQ for new CICSRDQU had TSQNAME,
VMAC110 but that should have been TSQUEUE. This misspelling was
Mar 5, 2004 missed because CICSRDQU is not sorted by default.
Thanks to Chris Weston, SAS ITRM, USA.
Change 22.027 -Variable SM120WIP is a count, not a duration; it is input
VMAC120 now as &PIB.4. instead of &PIB.4.3, and is no longer in
Mar 5, 2004 the TIME13.3 format list.
Mar 10, 2004 -For subtype=7, MXG output only the first server segment
from web application section, causing the counts in the
web activity TYP120WA dataset to be wrong, and much lower
than corresponding web interval counts in TYP120WI. All
server segments are now output.
Thanks to Andre Baltimore, Unigroup Inc, USA.
Change 22.026 Cosmetic. The time-of-day when the read of the SMF file
VMACSMF ended is now printed in the "SUCCESSFULLY READ SMF FILE"
Mar 4, 2004 message on the SAS log.
Change 22.025 The JCL Procedure for MXG and SAS execution for SAS V 9.1
MXGSASV9 is slightly different than the original SAS V9.0 JCL. The
Mar 4, 2004 entry point is SAS, the "BATCH" config member is BATWO,
and the DSNAMES are now .WO.AUTOLIB, .ENW0.SASHELP, and
.ENW0.SASMSG.
Thanks to Ed Finnell, University of Alabama, USA.
Change 22.024 This text just documents all of the names of %MACROs that
doc are currently defined anywhere in MXG source code.
Mar 4, 2004 ACTIVITY ANAL115 ANAL94 ANALAVAI ANALBLSR ANALCISH
ANALCNCR ANALDB2C ANALDB2R ANALDBTR ANALDMON ANALEPMV
ANALHSM ANALMNTS ANALNPMR ANALRMFR ANALTCP ANALUOW
ARGS BITCHECK BLDNTPDB BLDSMPDB CALCPOLC CDE_BCR
CDE_BVR CDE_DCL CDE_DCR CDE_DGN CDE_DSR CDE_DVL
CDE_L2CR CDE_MC1 CDE_MCA CDE_MCB CDE_MCC CDE_MCD
CDE_MCM CDE_MCO CDE_MCP CDE_MCR CDE_MCT CDE_MCU
CDE_MCV CDE_MHCR CDE_TTOC CDE_VAC CDE_VSR CECLEVEL
CHART CHKWORK CICCONSM CICDLIR CICDUMP CICFILE
CICSTOR CONVERT COPYIT CPUGRAF DASDGRPH DB2DBID
DB2RSELA DB2RSORT DBUGDB2C DEVTYPE DISKREPT DMIDET
DMISUM DMONREP1 DMONREP2 DMONREP3 DMONREP4 DOMAIN
DSNUPDT DSNUPDT DSNUPDT DT EMAIL EPIVARS
EXTRACT FACILITY FINALRPT FTPDATA FTPRPTD FTPRPTS
GENFTP GETHEX GETOBS GETSUM GRAFDB2 GRAFHSM
GRAFLPAR GRAFREGR GRAFRMFI GRAFTALO GRAFTAPE GRAFTMNT
GRAFTRND GRAFWORK GRAFWRKX GROUP HEADALL HSMBALL
HSMDELT HSMDELU HSMMALL HSMMMIG HSMMTYP HSMPALL
HSM_SUMT HTTPDTL HTTPSRY IMFDLCHA IMFDLSRT IMFDLTRX
INTVREPT IOSTAT IPHOST IPHOSTF LBLCLS LDSKREPT
LOOP LPARSUM MIGSGRPH MMRYREPT MNMXTIME MONTH
MONTHMTD MQMBUF MQMCFS MQMDB2 MQMLOG MRPDBCMD
MXGCAH MXGCF MXGCHAN MXGCOMM MXGCPU MXGDAY1
MXGDEVC MXGDOMI MXGENQU MXGHTTP MXGIOQU MXGPAGE
MXGPGDS MXGSDV MXGSMRY MXGVDAIL MXGVHOUR MXGVSTOR
MXGVUSAG MXGWKLD MXGWLMG MXGXCF NETWREPT NODATA
NPMSMR01 NPMSMR02 NPMSMR03 NUMTYPE OBSCHEK OBSCHEK1
OPTIONS OUT_BCR OUT_BVR OUT_DCL OUT_DCR OUT_DGN
OUT_DSR OUT_DVL OUT_L2CR OUT_MC1 OUT_MCA OUT_MCB
OUT_MCC OUT_MCD OUT_MCM OUT_MCO OUT_MCP OUT_MCR
OUT_MCT OUT_MCU OUT_MCV OUT_MHCR OUT_TTOC OUT_VAC
OUT_VSR PCSRREPT PERIOD PMACC01 PMACC02 PMAUD01
PMAUD02 PMAUD03 PMIOS01 PMIOS02 PMIOS03 PMIOS04
PMIOS05 PMLOK01 PMLOK02 PMLOK03 PMLOK04 PMSPR01
PMSQL01 PMSQL02 PMSQL03 PMSQL04 PMSTA01 PMSTA02
PMTRC01 PMTRC02 PMTRN01 POLICY PRINTIT PRINTNL
PROCESS PROFILE PRT_BCR PRT_BVR PRT_DCL PRT_DCR
PRT_DGN PRT_DSR PRT_DVL PRT_L2CR PRT_MC1 PRT_MCA
PRT_MCB PRT_MCC PRT_MCD PRT_MCM PRT_MCO PRT_MCP
PRT_MCR PRT_MCT PRT_MCU PRT_MCV PRT_MHCR PRT_TTOC
PRT_VAC PRT_VSR PSSTAT RCLASS RDCAT READDB2
READMAP READMXG READREC READSAR REAL REG
REPDATE REPLAY REPORT REPORTS RESP RPTAUSS
RPTCONSM RPTDLIR RPTDUMP RPTFILE RPTJCR RPTLDG
RPTLDR RPTLGR RPTLGS RPTLSRFR RPTLSRR RPTNQG
RPTRMG RPTTCR RPTTSR RPTXMR SCLASS SCPER
SELECT SELTM SMBVTOC SMBVVDS SORTPDB SORTPDB
SPLITCHK SPMAP SRIF SRVPOLCY STM SUMRIZE
SUMTAB TEMP TEMPDB2 TESTLONG TESTN TESTSITE
TIMEBILD TMP70PR TNDATA TNRPTD TNRPTS TRENDIT
TRNDDB2A TRNDDB2B TYP30DD TYP_HDR TYP_HDR2 UDUMPEBC
UNIXTOP USERID USERS UTILBLDP UTILCONT UTILCVRT
UTILPRIN UTILRMFI UTILXRF1 V6COMPCL V6COMPEN VAR_BCR
VAR_BVR VAR_DCL VAR_DCR VAR_DGN VAR_DSR VAR_DVL
VAR_L2CR VAR_MC1 VAR_MCA VAR_MCB VAR_MCC VAR_MCD
VAR_MCM VAR_MCO VAR_MCP VAR_MCR VAR_MCT VAR_MCU
VAR_MCV VAR_MHCR VAR_TTOC VAR_VAC VAR_VSR VAXLOOP
VAXNUM VGETDDS VGETDSN VGETENG VGETOBS VGETSORT
VMACFRYE VMSTAT VMXG2DTE VMXG344 VMXG70PR VMXGCC
VMXGCHR VMXGCICI VMXGCOMP VMXGCON VMXGDEL VMXGDKRN
VMXGDOWN VMXGDSNL VMXGDUR VMXGENG VMXGETM VMXGEXP
VMXGFOR VMXGGETM VMXGGMT VMXGGOPT VMXGINIT VMXGINV
VMXGJFCB VMXGLBIN VMXGLRC VMXGLRF VMXGLRI VMXGLRO
VMXGLRV VMXGMLST VMXGOPTR VMXGPPDS VMXGPRAL VMXGPRO
VMXGRFM VMXGRFV VMXGRMFI VMXGSET VMXGSUM VMXGTAPE
VMXGTIME VMXGTPFI VMXGUOTT VMXGUOW VMXGUOWC VMXGUOWL
VMXGUOWT VMXGUSE VMXGVBS VMXGVTOC VMXGVTOF VMXGVTOR
VMXGWORL WEEKBLD WEEKWTD WGPER WGROUP WKLDUPDT
XMINX _MTG01 _MTG02 _NDMMAKE _VRD30
Change 22.023 No Change, doc only. PCHANBY over 100% for SMF73ACR='OSD'
VMAC73 channels occurs but variable VARIED='Y' (bit 6 SMF73FG2)
Mar 4, 2004 is true in those obs. The SMF manual says for bit 6:
"Data Recorded is incorrect because channel path was
reconfigured during the interval". While I could chose
to not calculate fields, it has always been my policy to
give you whatever IBM puts in the record, so you can then
chose to keep or not to keep that observation in reports.
And, hopefully, the larger-than-100% value will cause you
to find this note, understand why, and then take actions
for your installation to delete those observations from
your reports.
Thanks to Frank DeBree, DEXIA, BELGIUM.
Change 22.022 -Variable LOSU_SEC (unweighted service units per second of
BUILD005 the hardware platform where this step executed) is kept
BUIL3005 in PDB.STEPS and PDB.JOBS.
VMAC30 -Two new service-unit-based CPU variables are created in
Mar 4, 2004 TYPE30_x, PDB.SMFINTRV, PDB.STEPS, and PDB.JOBS datasets;
so they can be compared with the SMF-recorded TCB and SRB
fields:
SRVTCBTM='SERVICE*UNIT*BASED*TCB TIME'
SRVSRBTM='SERVICE*UNIT*BASED*SRB TIME'
The CPUUNITS, SRBUNITS & LOSU_SEC are in SMF 30 records,
but the CPUCOEFF/SRBCOEFF coeffs are not. They are only
in RMF 72s, but since they almost never are changed, the
new variables use macro variables which default to ONE,
a very common weighting value. You MUST override default
coefficients, using these %LETs in IMACKEEP or //SYSIN:
%LET CPUCOEFF=10;
%LET SRBCOEFF=10;
if CPUCOEFF and SRBCOEFF in TYPE72/TYPE72GO are not one.
Note: IBM added those coefficients into the SMF 30 record
with APAR OA09118, and they will be used if that
APAR has been installed. See Change 22.341.
Cheryl Watson suggested using SU-based CPU time instead
of SMF CPU time, because SUs have more precision than the
.01-second SMF resolution, and truncation of those extra
decimal places added up to a few hours of CPU per month.
I examined 879 step records (z/OS 1.5), and did find 216
steps with SRV TCB/SRB CPU times greater than their SMF
TCB/SRB CPU times, but the max delta was only 0.0069 secs
and the "extra" SRV time, due only to truncation, was a
total of only 0.62 seconds for those 216 steps.
However, I also found there were 377 other steps that had
SMF TCB/SRB CPU time greater than SRV CPU; 38 steps had
deltas of over 1 second, and the total SMF CPU captured
was 168 seconds more than the SRV captured CPU time, so
replacing the SMF CPU with the SRV CPU seems unwise.
But what does make sense, now that I have the variables,
is to use the maximum TCB/SRB time, so any decimals that
would have been truncated won't be, creating new variable
CPUTOTTM='TOTAL CPU*MAX TCB,SRB*FROM SMF OR SU'
with this equation in SMF 30 processing:
SUM(MAX(SRVTCBTM,CPUTCBTM),MAX(SRVSRBTM,CPUSRBTM),
CPITCBTM,CPISRBTM,CPURCTTM,CPUHPTTM,CPUIIPTM);
However, remember that CPUTOTTM is COMPLETELY DEPENDENT
on you having %LET correct CPUCOEFF and SRBCOEFF values,
if your coefficients are not the MXG default of one.
-Now, see also the text of Change 22.265.
Thanks to Cheryl Watson Walker, Watson & Walker, USA.
Change 22.021 -Job delay variables SMF30HQT/JQT/RQT/SQT should not have
VMAC30 been created in TYPE30_V,PDB.SMFINTRV,TYPE30_6 interval
Mar 3, 2004 datasets from subtype 2,3,6 type 30 records, because they
Mar 8, 2004 are job-level, and not interval-level. Their value is
Mar 12, 2004 now always set to a missing value for those records.
-TYPE30_4 dataset, those job-related variables will now be
missing except in the STEPNR=1 observation.
-TYPE30_5 dataset, those job-related variables will now be
missing if TYPETASK IN ('STC','OMVS'), as they are not
"jobs that are initiated".
-No changes were made to BUILDPDB code; those variables
are summed from their TYPE30_5 observation(s) into the
PDB.JOBS dataset, so they will be non-zero if variable
INBITS contains a "J" in the third character, indicating
that a 30-5 job termination was found for this job.
-Variable SMF30PF2, flag byte 2 is now kept.
-Jobs run under CA's JobTrack control have zeros for these
variables in their type 30-5 record, even though they are
non-zero in step records, but it is not JobTrack's error.
We now find that ANY job that has a flushed last step has
zero values for SMF30HQT/JQT/RQT/SQT in the job's SMF 30
subtype 5, even when the step records have non-zero
values; JobTrack showed up because it adds a non-executed
step at the end of every job under its control for
tracking information! The zero values, I believe, are an
IBM error in failing to propagate the values when the
last step is flushed, and a problem report will be opened
with IBM; this note will be updated when IBM replies.
Thanks to Bret Hoesly, TDS, USA.
Change 22.020 The example to create only DB2ACCT.DB2ACCT & PDB.DB2STATS
ADOCDB2 fails with ERROR: FILE WORK.SUMSTATB DOES NOT EXIST. The
Mar 2, 2004 redesign in Change 21.140 moved the interval statistics
for buffers into DB2STATB, which is now required as input
to create the desired PDB.DB2STATS summary dataset. The
example now creates DB2STATB, DB2STAT0, and DB2STAT1 so
PDB.DB2STATS can be created, but they are written to the
//WORK file, so only the two desired datasets are kept.
//SYSIN DD *
%LET PDB2ACC=DB2ACCT;
%LET PDB2ST0=WORK;
%LET PDB2ST1=WORK;
%LET PDB2STB=WORK;
%LET MACKEEP=
%QUOTE(
_NDB2
MACRO _WDB2ACC _LDB2ACC %
MACRO _WDB2ST0 DB2STAT0 %
MACRO _WDB2ST1 DB2STAT1 %
MACRO _WDB2STB DB2STATB %
MACRO _SDB2 _SDB2STB _SDB2STS %
MACRO _SDB2ACP %
MACRO _SDB2ACB %
MACRO _SDB2ACG %
MACRO _SDB2PAT %
MACRO _SDB2ST2 %
MACRO _SDB2STR %
MACRO _SDB2PST % );
%INCLUDE SOURCLIB(TYPSDB2);
RUN;
Thanks to John Croasdale, Abbey National, ENGLAND.
Change 22.019 -Variables STARTIME and DURATM are now created in each of
VMAC119 the 119 interval statistic datasets, TYP11905, TYP11906,
Mar 3, 2004 TYP119A7, and TYP119B7. There are four duration variables
in TYP11905, but all have identical values in test data,
so DURATM is set to the MAX of the four variables. Some
labels were revised and misspellings corrected. All other
TYP119xx datasets are events, rather than intervals, so
they don't contain the STARTIME/DURATM pair.
-Variable TCDURTM and UDDURTM are now divided by 4096 vice
by 496.
-Protective double question mark modifiers were inserted
before the two &NUM.3. inputs for FCLREPLY and FSLREPLY.
Thanks to Chris Weston, SAS ITRM, USA.
Change 22.018 All references to the "SPIN" DDNAME/LIBNAME have been
ASUMTALO replaced with macro variables &SPININ or &SPINOUT, so
ASUMTAPE that input and output can be separate MVS datasets. As
BUIL3005 both macro variables default to "SPIN", this should be a
BUILD005 transparent change. This enhancement is needed by sites
JCLUOWP that run their MXG jobstream under CA's Job Scheduler,
JCLUOWV which requires separate datasets for its recoverability.
SPINSORT To use this enhancement, you would change your JCL to
VMACFRYE // EXEC MXGSASV9
VMXGINIT //SPININ DD DSN=OLDSPIN,DISP=SHR
VMXGRMFI //SPINOUT DD DSN=NEWSPIN,DISP=(,CATLG),...
VMXGUOTT and put your %LETs either in //SYSIN or in IMACKEEP:
VMXGUOW %LET SPININ=SPININ;
VMXGUOWT %LET SPINOUT=SPINOUT;
Mar 2, 2004 -These VMXGRMFI temporary datasets that should have been
deleted, now are:
MERGERMF SORINTRV MSU4HRAV SPUNRMFI MSU4HRMR
MERGEMSU MERGESOR SPUNRMFI
-Typo'd member named VMAGUOTT was discovered and deleted.
Change 22.017 FLASH: BUILDPDB (only-under"MVS") runtime elongation can
VGETENG be significant IF any output libraries (like CICSTRAN or
VMXGRMFI DB2ACCT) are on tape or in sequential format on DASD.
VMXGSUM This problem does NOT affect ITRM's normal job, because
VMXGSUME %CPPROCES/CMPROCES puts everything in //WORK, and ITRM
Mar 2, 2004 doesn't use tape libraries during its "BUILD".
Mar 12, 2004 This problem was introduced in MXG 19.19, when %VGETENG
was added in VMXGRMFI, to test if a //SPIN DD existed.
VMXGRMFI is called by RMFINTRV, which is automatically
included in MXG's BUILDPDB. If you do NOT use tapes for
output in your BUILDPDB job, you don't have this problem.
The PROC SQL with FROM DICTIONARY.MEMBERS in VGETENG gets
the ENGINE of //SPIN, but no WHERE LIBNAME=SPIN clause
was used, so the PROC SQL had to read all LIBNAMEs to
populate the DICTIONARY.MEMBERS table. If your CICSTRAN
and DB2ACCT are both multi-vol on tape, you would have
these mount messages on the BUILDPDB's job log:
hh:mm-hh:mm
SMF Opened, read started 14:25
CICSTRAN Mount-Dismount 5 vols 14:24-16:06
DB2ACCT Mount-Dismount 2 vols 14:24-15:25
SMF Closed, read completed 16:12
VGETENG-remount/read 2 DB2ACCT vols 16:17-16:30
VGETENG-remount/read 5 CICSTRAN vols 16:40-17:09
Total Elapsed time: 164 minutes with re-read.
VGETENG wasted 52 minutes, mounting and reading the seven
tapes! For DASD data libraries, PROC SQL only has to
read the directory of SAS datasets in that library, but
for sequential format libraries, PROC SQL has to read the
entire sequential file, because tape format libraries do
not have a directory of datasets.
And PROC SQL doesn't print any message on the SAS log to
tell you it was the cause of the extra CICSTRAN & DB2ACCT
mounts. The only clue to the elongation are those extra,
and unexpected, tape mount messages on the job's SYSOUT!
Elapsed and CPU time, and EXCPs of your daily job can be
reduced significantly, if you use tape output on MVS in
your BUILDPDB job, with either circumvention:
Immediate circumvention, any of the three fixes:
1. Replace MXG 21.21 with MXG 22.01, now available.
See text of Change 22.017 for lots of details.
2. Change the JCL:
Add ,FREE=CLOSE to the //CICSTRAN and //DB2ACCT and
to any other output DDs that are on tape/seq format.
3. Or, change the MXG source code:
a. EDIT/CREATE member EXPDBOUT in USERID.SOURCLIB
tailoring library, and add a statement:
LIBNAME CICSTRAN CLEAR;
LIBNAME DB2ACCT CLEAR;
for each tape (or sequential format) DDNAME.
b. Or do the same in your //SYSIN stream, using:
//SYSIN DD *
%LET MACKEEP=
%QUOTE( MACRO _EPDBOUT
LIBNAME CICSTRAN CLEAR;
LIBNAME DB2ACCT CLEAR;
%
);
%INCLUDE SOURCLIB(BUILDPDB);
....rest of job....
Discussion of the circumventions:
- Using FREE=CLOSE. This appears to always be safe.
The FREE=CLOSE occurs when CICSTRAN/DB2ACCT/etc are
closed, at the end of reading the SMF file, so PROC SQL
in VMXGRMFI won't see those sequential LIBREFs so they
won't be read. But even if your job does then %INCLUDE
any of the ASUMCICx, ASUMDB2A, or ASUMUOW members that
read those data libraries, SAS is still able to re-open
the LIBREF that was FREE=CLOSEd, without any error.
Like magic!
And using FREE=CLOSE on //SMF DD seems always wise and
courteous, so the device can be available to another.
- Using LIBNAME xxxxxxxx CLEAR; in EXPDBOUT also appears
to be completely safe. EXPDBOUT is a little later than
the close of the SMF file, after a few PROC SORTs, but
the CLEAR closes the LIBNAME so PROC SQL in VMXGRMFI
never sees those LIBNAMES to read, but the allocation
can be re-opened, if, for example, you %INCLUDE any of
the ASUMxxxx's that read DB2ACCT or CICSTRAN.
- With either circumvention, harmless messages are on the
SASLOG for each DDNAME, at deallocation time:
NOTE: DATASET XYZ HAS NOT BEEN DEALLOCATED BECAUSE
IT WAS ALLOCATED EXTERNALLY
NOTE: LIBREF XYZ HAS BEEN DEASSIGNED
- The circumventions do not have to be removed when you
install an MXG Version with this change.
- The choice of changing JCL or MXG source depends only
on whichever is easier to do within your production
change control system for your MXG daily jobs!
Permanent Changes made in this change:
a. VMXGRMFI. The permanent correction in this change:
- %VGETENG(DDNAME=SPIN) and ENGINE logic was removed.
- If you execute VMXGRMFI/RMFINTRV by itself, a //SPIN
DD is now required; you'll get an obvious SAS error
if you don't have one.
The test that caused this problem was added only to
prevent an abend that might happen, only if you used
RMFINTRV in a standalone job. RMFINTRV is normally
created by BUILDPDB, and a //SPIN DD has always been
provided in JCLPDBxx examples, but when the MSU4HRAV
variable was created in PDB.RMFINTRV, the history of
the last four hours was to be "spun" in SPIN.SPINRMFI
if a //SPIN DD was found. But if you ran RMFINTRV in
a standalone job that didn't have a //SPIN DD, the
MSU change would cause your "running just fine" daily
job to fail. So the VGETENG and associated logic was
added in VMXGRMFI in MXG 19.19 to protect no //SPIN.
Unfortunately, even that was also wrong. The PROC SQL
with DICTIONARY.MEMBERS sees only LIBNAMEs that are
OPEN, and BUILDPDB has not OPENed the SPIN library
when RMFINTRV is called, VGETENG set ENGINE=UNKNOWN
and so SPIN.SPINRMFI has never been created; only the
WORK.SPINRMFI has been output, and then deleted!
Fortunately, the only impact is that MSU4HRAV in
PDB.RMFINTRV has missing values for the first four
hours of each day. But since you have been wisely
using the PDB.ASUM70PR/ASUMCEC/ASUM70LP LPAR data
to measure and report "MSU" capacities, you have
never noticed nor used MSU4HRAV in PDB.RMFINTRV.
It was added for convenience when looking at a
single SYSTEM in RMFINTRV data.
Now, SPIN.SPINRMFI will always be created.
b. VGETENG: Permanent change, but VGETENG is NOT used in
VMXGRMFI with this change. Read carefully.
You can heal VGETENG's missing WHERE clause problem
by copying the member VMXGENG into member VGETENG,
and then CHANGE "VMXGENG" "VGETENG" ALL. The old
VMXGENG member does have the needed WHERE clause.
However, even with a WHERE clause, if the DDNAME is a
sequential format library, PROC SQL still must read
all of that (one) data library. And if it happens to
be a multi-volume, extended format, striped, and DASD
hardware compressed dataset; it will take time and
there won't even be mount messages to account for the
wasted time.
The VMXGENG member worked fine with its WHERE clause,
but when I standardize macro/member names that "GET"
a value to start with VGET instead of VMXG prefix, I
got a VGETENG without the WHERE clause. We would not
be having this pleasant conversation if I had used
%VMXGENG in VMXGRMFI in place of the new %VGETENG.
But since the %VGETENG is not removed from VMXGRMFI,
it really doesn't matter, now.
c. VMXGSUM, VMXGSUME: A very minor exposure to delay.
If you created your own %VMXGSUM execution that uses
TEMP01=, TEMP02=, TEMP03= arguments (DDNAMEs for temp
workspace), a PROC SQL; FROM DIRECTORY.MEMBERS is
used to find the engine, which was then set to VnSEQ,
if the fall-thru case of UNKNOWN engine is found, so
that an extended-format, hardware compressed, striped
file can be used, if that's in the DATACLAS/STORCLAS.
Since this PROC SQL does have the WHERE clause, only
the one TEMPnn DD would be read, but it would be read
once for every %VMXGSUM invocation.
But because the primary reason for TEMPnn= arguments:
to circumvent limitations back in SAS Version 6
for multi-volume temporary disk data libraries
was eliminated by SAS V8 multi-volume support, I have
removed this exposure by removing the PROC SQL and
logic for ENGINE in the VMXGSUM members. If you are
bright enough to use those specialized files that
require a sequential engine, that I believe you are
also bright enough to know that you need to add a
LIBNAME TEMPnn VnSEQ;
in your program before your %VMXGSUM invocation.
Especially since SAS will tell you if is needed!
d. Two other MXG "utility"s use FROM DICTIONARY.MEMBERS:
- VGETDDS, which you would use ahead of VMXGSET to
read multiple SAS libraries for the same dataset.
- VGETDSN, which returns the MVS DSNAME of a SAS data
library.
As both members have WHERE clauses for the LIBNAME,
so only one library would be read in any case, and as
both are optional and unlikely to be used during the
BUILDPDB process, they remain unchanged.
Thanks to Jim Poletti, Edward D. Jones, USA.
Change 22.016 The ANALSRVC report still had BY SYSTEM STARTIME for the
ANALSRVC RMF sort order, and failed with RECORDS OUT OF ORDER;
ANALPGNS BY SYSPLEX SYSTEM STARTIME has been the RMF sort order
ANALSTOR for years, but these examples had not been updated until
ADOCPDB now.
ACHAP35
XPRSMSUM
Mar 1, 2004
Thanks to Dave Crowley, Blue Cross Blue Shield of Florida, USA.
Change 22.015 Cosmetic. White space was inserted after single quotes
ANALDB2R to eliminate the SAS Version 9.1 " 49 " Warning message.
VMAC94
Feb 29, 2004
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 22.014 WebSphere SMF 120 records don't have GMT offset, and the
VMAC120 MXG algorithm was wrong, so all of the SM120xxx datetime
Feb 27, 2004 variables were wrong, if your GMT offset is non-zero.
Some were off by one-GMT-offset, some were off by two!
And SM120WAU could still be wrong, if it spans the
Spring/Fall time changes, since it can be several days
earlier than the SMFTIME of the record.
Thanks to Tom Draeger, Aurora Health, USA.
Change 22.013 -Members EXNDMIP and EXNDMSP were removed; all references
EXNDMIP to NDMIP and NDMSP were removed; the IP and SP subtypes
EXNDMQT are output in the NDMDT dataset.
EXNDMSP -Member EXNDMQT and all references to NDMQT were removed;
EXNDMTI subtype "QT" is output in NDMQE.
EXNDMUM -Member EXNDMTI and all references to NDMTI were removed;
VMACNDM subtype "TI" is output in NDMCI.
VMXGINIT -Member EXNDMUM and all references to NDMUM were removed;
Feb 26, 2004 subtype "UM" is output in NDMAE.
-Data set Label "NDM AUTHORIZATION" was revised to show
the subtypes, for severaly NDM datasets.
Thanks to Chris Weston, SAS ITRM, USA.
Change 22.012 -Variables RACFUSER & RACFTERM were reversed in MXG code.
VMACTMNT -The new subtype 6 stats record from ML-28/ML-29 caused an
Feb 26, 2004 INPUT STATEMENT EXCEEDED error; MXG expected ML-30, which
which added two new fields.
-Pending March 3: some timestamps created in ASMTAPEE are
on GMT clock, and support for a bit-changing APAR are in
development/testing.
Thanks to Tom L. White, SPRINT, USA.
Thanks to Jon Whitcomb, Great Lakes Educational Loan Services, USA.
Thanks to Normand Poitras, IBM Global Services, USA
Change 22.011 Calculation of PCTCPUBY in PDB.TYPE70PR for IRD was not
VMAC7072 correct for any engine with SMF70ONT less than DURATM.
Feb 24, 2004 The calculation of PCTCPUBY was revised to use SMF70ONT
as the denominator instead of DURATM when IRD has varied
the engine off during the interval. This only affected
the PDB.TYPE70PR dataset; both PDB.ASUM70PR and ASUMCEC
with MXG 21.05 (Change 21.170), but see Change 22.050.
Thanks to Scott Barry, SBBWorks, USA.
Change 22.010 Two typographic errors were corrected; /* before SMCASID
RMFMON instead of just /, and in the PUT statement variable name
Feb 24, 2004 IRARMCNS instead of IRAMCNS.
Thanks to Daniel T. Cannon, The Hartford, USA.
Change 22.009 Hyperspace buffers, reads, and writes variables are now
VMACMBO input and kept.
Feb 24, 2004
Thanks to Job Babcock, Bank One, USA.
Change 22.008 -The TPMX arrays were redesigned so that it is no longer
EXTYTPMX fatal to have more instances in your data than you %LET
IMACTPMX in your IMACTPMX member. A new message will be printed:
VMACTPMX ***ERROR.TPMX JBL19NN ARRAY SIZE EXCEEDED.
Feb 22, 2004 with the name "JBL19nn" of the %LET statement to change,
Feb 24, 2004 but extra instances are skipped and all records are now
Feb 25, 2004 output. New variables with the same name as the macro
Mar 11, 2004 variable are created in TYPETPMX dataset, so you can use
PROC MEANS DATA=TYPETPMX MAX; to see how many instances
were found in your data. The %LET statements in IMACTPMX
set the number of variables created in each array, and
all variables are normally kept, but you can increase the
%LET to eliminate the message, and then use the example
DROP statements in your EXTYTPMX member, if you don't
want to output that many instance variables.
-Array names were changed (since they are internal to the
VMACTPMX code) and all now match the base of the variable
name that are output; the "WHEN" values in the format are
also changed for the arrays and also match the base name.
-Format "VARNAME" values were also changed to match their
array base name.
-Bind variables were not output, but are now.
-The original count variables are still kept, to prevent a
VARIABLE NOT FOUND condition, but those variables can be
removed by uncommenting this DROP statement in EXTYTPMX:
DROP JBACTC JBAFFC JBBNDC JRBNDC JBDEAC JCAFTC JCBFRC
JLLIMC JLIMTC JBVOLC JVVOLC JBLL1C JBLL2C JBLL3C
JBLL4C JBLL5C JBLL6C JBLL7C JBLL8C JBLL9C JBL10C
JBL11C JBL12C JBL13C JBL14C JBL15C JBL16C JBL17C
JBL18C JBL19C JBL20C JBL21C JBL22C JBL23C JBL24C;
-Documentation of the syntax of the PROC FORMAT in the
IMACTPMX member was (hopefully!) improved.
Thanks to Richard S. Ralston, Humana, USA.
Change 22.007 Variable RVOLTYPE, VOLUME*TYPE*PHYSICAL*OR LOGICAL is now
VMACEDGR kept in EDGRVEXT dataset; previously it was only INPUT
Feb 18, 2004 and kept in EDGRXEXT dataset.
Thanks to Ray Bole, IBM Global Services, USA.
Change 22.006 Support for Huron/Object Star subtype 23, and corrections
EXHRN23 for subtypes 08, 11, 22, 24, 26, which could cause an
IMACHURN INPUT STATEMENT EXCEEDED error. New HURN23 dataset is
VMACHURN created. The symbol # was removed from labels; they
VMXGINIT are not needed and don't always print correctly. Huron
Feb 18, 2004 Versions R3 and R4 have been tested with this change.
Thanks to Greg Meyer, Isuzu, USA.
Change 22.005 Support for subtypes 14 thru 19 for SMF 82 CRYPTO records
EXTY8214 creates new TYPE8214 thru TYPE8219 datasets.
EXTY8215
EXTY8216
EXTY8217
EXTY8218
EXTY8219
IMAC82
VMAC82
VMXGINIT
Feb 17, 2004
Thanks to Willy Iven, Fortis Bank, BELGIUM.
Change 22.004 New variable ZTIME='ZEE DATETIME*ZEE OBS*WAS CREATED' is
IMACZDAT created and retained in member IMACZDAT, which currently
VMACEDGS creates the existing ZDATE variable. ZTIME is needed for
VMACTMS5 raw data that doesn't have a "datetime" event variable,
Feb 17, 2004 like TMS/CA-1 and DFSMS/rmm tape data that are created by
taking a "snapshot" of the tape catalog by running a job.
The new ZTIME variable can be used to detect or separate
multiple runs, and can be used for duplicate observation
detection, and can eliminate the need for ITSV sites to
tailor MXG exits.
Variable ZTIME is kept in TYPETMS5 and TYPEEDGS datasets.
Thanks to Christa Neven, KBC BankVVerzekeringsHolding, BELGIUM.
Change 22.003 Several new APPLICATION PRM METRICS are now supported and
VMACMWUX these variables created in HPUXAPPL dataset.
Feb 16, 2004 APPPRMMD='APPPRM*LOGGING*MODE*APP=0*PRM=1?'
PRMMEMUT='APPPRM*MEM*UTILIZED'
PRMSTATE='APPPRM*STATE'
PRMCPUCA='APPPRM*CPUCAP*MODE'
PRMCPUEN='APPPRM*CPU*ENTITLEMENT'
PRMMEMAV='APPPRM*MEM*AVAILABLE'
PRMMEMUP='APPPRM*MEM*UPPERBOUND'
PRMMEMEN='APPPRM*MEM*ENTITLEMENT'
Thanks to Miguel Fernandez, Information Services International, USA.
Change 22.002 -MQ Series variable WTINDXTY, index type, is now decoded
FORMATS with format MG116IN:
Feb 16, 2004 VALUE MG116IN
Feb 17, 2004 0='0:NO INDEX'
1='1:MSG_ID INDEX'
2='2:CORREL_ID INDEX'
4='4:MSG_TOKEN INDEX'
5='5:GROUP_ID INDEX'
Index type can be a critical factor in WebSphere MQ
message retrieval. With No Index, message retrieval for a
browse is sequential, and can take a long time for large
queues, since each page must be retrieved to see whether
the page contains the message of interest. With indexing
it can take only one page retrieval, and the difference
can be seconds or even minutes. If the browse is of many
messages, the difference can be "many" times the scan of
a single queue, since the queue must be scanned for each
message retrieved. And this really gets *ugly* if the
queue has spilled over to the page set on DASD.
-Labels for WQPUTPMS,WQPUT1PM are 'PERSISTENT*CREATED...'
instead of 'PERSISTENT*GOT'. MQPUT calls create messages,
MQGET calls retrieve messages (either GET-and-delete or
BROWSE). And the distinction between NON-PERSISTENT and
PERSISTENT is important because the two types should not
normally be intermingled in a queue, for performance.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA
Change 22.001 Support for MQ Series counts and times in ASG-TMON/CICS
VMACTMO2 adds four variables to MONITASK and
Feb 12, 2004 See MXG Tech Note 4.A in Newsletter FORTY-FOUR, 11Feb04.
Thanks to Alex Nielsen,
The below Change may be required for your MXG 21.21, depending on its
internal date. Tape were copied starting Feb 6, and that edition of the
MXG 21.21 annual version need this change. But if your CHANGES in your
MXG 21.21 indicates Feb 11, 2004, then this change is already installed.
Change 21.320 MXG 21.21 final post-QA corrections/incompatibilities:
CLRMFV -SEQENGINE=V6SEQ changed to V8SEQ/V9SEQ in CONFIGV8/V9.
NOTE: SEQENGINE HAD TO BE RESET TO V6SEQ IN CONFIGV9.
in May, 2004, in Change 22.108.
CONFIGV8 See MXG Tech Note 4.A in Newsletter FORTY-FOUR, 10Feb04.
CONFIGV9 -VMACDB2. Remove line 8259: PUT _N_= 'HAVE 239 ';
EXTMNSTS -UTILEXCL. Add a second percent-sign to change line 218 to
IMACTMNT %%INCLUDE SOURCLIB(IMACZDAT);
UTILEXCL -CLRMFV. Cosmetic. A "NOT" and EQUAL symbols slipped thru
VMAC90 and were changed to "NE"; NOTs don't translate well among
VMACDB2 platforms, and were removed back in Change 8.093
VMACTMNT -Only if you received MXG on CD: Change line 57 in member
VMXGINIT VMACTMNT, removing "DEVNR", changing the line to be:
Feb 10, 2004 MACRO _BTYSTS SYSTEM SHIFT INTBTIME %
-The CD-only VMACTMNT error was caused by my accidental
copying of support for the new TYPESTAT statistics data
from the subtype 6 ASMTAPEE ML-30 SMF record, after the
ftp and tape files were built. TYPESTAT was validated,
but I didn't use TYPSTMNT to test its sort macro. Member
EXTMNSTS was added and VMXGINIT updated for TYPESTAT and
the sort has been tested in this final iteration.
-Variables SMF9029N,SMF9029A,SMF9030I in archaic VMAC90
were renamed A, N, and Y, only in case someone foolishly
uses both VMAC90 and VMAC90A in same step. Use VMAC90A.
Thanks to George Canning, Abbey National Plc, ENGLAND.
Thanks to Vernon Kelley, IBM, USA.
LASTCHANGE: Version 22.