COPYRIGHT (C) 1984-2023 MERRILL CONSULTANTS DALLAS TEXAS USA
MXG CHANGES 17.17
=========================member=CHANGE17================================
/* COPYRIGHT (C) 1984-2000 MERRILL CONSULTANTS DALLAS TEXAS USA */
MXG Version 17.17 is dated Feb 7, 2000, thru Change 17.398.
MXG Version 17.11 was dated Feb 2, 2000, thru Change 17.395.
First MXG Version 17.11 was dated Jan 31, 2000, thru Change 17.394.
First MXG Version 17.10 was dated Jan 20, 2000, thru Change 17.375.
MXG Version 17.09 was dated Dec 22, 1999, thru Change 17.339.
MXG Version 17.08 was dated Nov 12, 1999, thru Change 17.308.
First MXG Version 17.08 was dated Nov 10, 1999, thru Change 17.301.
MXG Version 17.07 was dated Oct 8, 1999, thru Change 17.264.
First MXG Version 17.07 was dated Oct 7, 1999, thru Change 17.261.
MXG Version 17.06 was dated Aug 12, 1999, thru Change 17.216.
MXG Version 17.05 and dated Aug 5, 1999, thru Change 17.207.
First MXG Version 17.05 and dated Aug 4, 1999, thru Change 17.203.
MXG Version 17.04 was dated Jul 16, 1999, thru Change 17.175.
First MXG Version 17.04 was dated Jul 14, 1999, thru Change 17.172.
MXG Version 17.03 was dated Jun 8, 1999, thru Change 17.126.
MXG Version 17.02 was dated May 19, 1999, thru Change 17.104.
MXG Version 17.01 was dated May 3, 1999, thru Change 17.079.
First MXG Version 17.01 was dated Apr 29, 1999, thru Change 17.073.
MXG Version 16.16 was dated Feb 20, 1999, thru Change 16.394.
Newsletter THIRTY-FIVE was dated Feb 20, 1999, thru Change 16.367.
Contents of member CHANGES:
(Please see member NEWSLTRS for Technical Notes
that were previously in member CHANGES).
I. MXG Software Version 17.17 is now available.
IX. Incompatibilities and Installation of MXG 17.17.
X. Online Documentation of MXG Software.
XI. Changes Log
I. MXG Software Version 17.17 is now available, upon request.
1. Major enhancements added in MXG 17.17:
Support for OS/390 Release 2.9.
Support for Lotus Domino Server Release 5.02.
CICINTRV dataset creation logic was wrong.
Revised utility to print NEWSLTRS/CHANGESS members.
Revisions and updates with new variables in all ADOCs.
Major enhancements added in MXG 17.10:
Year 2000 errors fixed for TYPEZARA and VMXGVTOF.
Y2K Cosmetic conversion of Julian dates from 00cyyddd to yyyyddd.
TELNET LOGF Time field is Duration, not datetime, not Y2K prob!
RMFINTRV/VMXGRMFI enhancements fixed and documented.
Support for Beta91 Balancing Manager SMF record.
Support for Software Innovation's LDMS product.
Added a replica of MICS SNTNSS report from NETSPY (and fixed it).
EXPDBOUT Example to add CICS Statistics datasets to your PDB.
Several ANALRMFR enhancements, this was just most recent.
Test version of VMXGSUM in XMXGSUM, uses SAS View to save DASD+.
Major enhancements added in MXG 17.09:
ABEND 2415, some sites due to no RECFM in //NULLPDS in SAS proc.
Starting with MXG 17.07, VMXGINIT now opens //SOURCLIB, and
some SMS sites get ABEND2415. Adding RECFM=U to the //NULLPDS.
DD statement corrects the ABEND. See Change 17.317.
Support for IIS Log.
Support for Windows 2000 Build 2195 NTSMF data.
Support for remaining CA-VIEW Metrics validated.
Support for additional Landmark TMVS subtypes.
More IMS Log revisions for negative values, more in testing.
RMFINTRV now invokes VMXGRMFI, supports 115 workload, SYNC59.
ASUMTALO Last-complete-interval now corrected.
Major enhancements added in MXG 17.08:
TYPEIMSA IMS Log revisions correct negative RESPNSTM/SERVICTM.
TYPECIMS IMF SQLCALLS are lost due to INCOMPAT change in MVIMF.
TYPE73 FICON PCHANBY/PNCHANBY wrong in initial FICON support.
TYPE74 PCTPNCHA/PCTPNOTH/PCTDVPND/PCTPNDEV revisions.
Support for APAR OW41147 ORGEXPDT=99999 - Read it: Y2K Critical.
Support for CA View Metrics SARSMFUX SMF record.
Support for RACF Unload IRRDBU00 Started Task subtype.
Support for TRMS Version 51A08 (COMPATIBLE).
Support for Landmark DB2 Monitor V 3.2 (INCOMPAT).
Support for APAR OW40579/41407 SMF 42 subtype 4.
Support for APAR PQ28258 for SMF 103 record.
Support for unix PerfMeter Freeware Monitor records.
Support for DFSMS/MVS V1R5 - in place, no changes.
Support for CA VIEW Metrics SARSMFUX SMF record.
Support for SQL*NET NIV adds IPADDR/PORTNR to ORACLE.
Enhanced TYPE1032 Web Server eliminates negatives.
Negative QXSELECT because DB2 overflowed counter!
CECSER wrong if CPUs added or deleted during interval.
Utility to show IMACWORK definitions CPU sources.
TYPE90A replaces TYPE90 member for SMF type 90 data.
CICS Statistics EOD record has missing DURATM.
Major enhancements added in MXG 17.07:
Major IMS Enhancements for MXG IMS log processing.
Support for Domino Server R5.0/R5.01 SMF type 108 record.
Support for Top Secret 5.1 (INCOMPATIBLE).
Support for TMON/MVS V2 PTF TD01655 (COMPAT).
Support for MQ Series Version 2.1 (COMPATIBLE).
Support for TeleView 4.3B subtype 3 record.
Support for OS/400 Release 4.4.0 (LRECLs INCOMPAT)
Support for Mobius View Direct 6.1.2 (INFOPAC).
Support for APAR OW39508 7060 Multiprise EIO and DSD.
Support for OS/390 R2.8 (COMPAT, changes were APARs).
ASUM70PR now creates PDB.ASUMCEC BY CECSER vice BY SYSPLEX.
Major enhancements added in MXG 17.06:
Support for OS/390 R2.8 (Compatible, 16.09 or later supports).
Support for Lotus Notes, SMTPDS, SMTPRS objects in NTSMF data.
Y2K Ready: ASMTAPES must have been Assembled with ES6 parameter.
Major enhancements added in MXG 17.05:
Support for IBM's TPF (Transaction Processing Facility) OS.
Support for APAR OW31701 for ESS Parallel Access Volumes.
Support for OW39128 for RACF, adds DSNAME of PDS used for PROGRAM
Support for STK's VTCS 2.2.0 (INCOMPATIBLE) VSM SMF records.
IBM's sample IXGRPT1 for SMF type 88 records is replicated.
New PDB.ASUMCEC corrects errors in PDB.ASUM70PR, more useful.
TYPETASK='OMVS' instead of TYPETASK='STC ' for OMVS/USS jobs.
OMVS/USS jobs filled SPIN, never purged, now output to PDB.
Major enhancements added in MXG 17.04 dated Jul 16, 1999:
Correction for preliminary IMS Log Enhancements.
Major enhancements added in MXG 17.04 dated Jul 14, 1999:
Support for CICS TS 1.3 new field inserted in CICSTRAN, INCOMPAT!
If you have CICS TS 1.3, you must install MXG 17.04 (or the one
line Change 17.156) or many variables in CICSTRAN will be bad.
Support for APAR OW37565 identifies CP or ICF CPUs in TYPE70PR.
ICF CPUs are now detected and deleted automatically in ASUM70PR.
Significant IMS Log processing enhancements available for test.
Utility to examine dates in SAS data library for Y2K.
Support for APAR OW37816, new 2105 cache data in TYPE74CA.
Support for Connect Direct R 3.2 'CT' record.
Support for MIM user record enhanced, new dataset.
Support for RMM European or American Date formats.
Support (preliminary) for NTSMF Windows 2000 Beta Three records.
Enhanced RMFINTRV/VMXGRMFI permits over 100 workloads now works.
Major enhancements added in MXG 17.03:
Support for Type 42 subtype 7/8 NFS Usage/Users.
Support for APAR OW37091 Measured Usage SMF 89 changes.
Support for SoftAudit Version 7.1 (COMPATIBLE).
Support for STK's NearOAM V2.2 (COMPATIBLE).
Support for 32 (up from 16) sortworks for SYNCSORT.
Support for OS/400 V4.3.0, no change, is in MXG 16.16.
BUILDPDB vars TAPEDRVS/TAPE3480/etc corrected for MULTIDD='Y'.
BUILDPDB vars EXCPNODD/IOTMNODD now corrected for MULTIDD='Y'.
Enhancement for PDB.ASUMTAPE obs with STATUS=MISSEDMNT.
Major enhancements added in MXG 17.02:
Support for DB2 type 102 subtype 199, Dataset I/O.
Support for Lexmark MarkVision Job Statistics
Support for CICS TS 1.2 Journal segment GLRHTYPE=2, used by SAP.
Support for SOFTAUDIT 6.1.2 (COMPATIBLE).
Support for TELEVIEW 4.3 (INCOMPATIBLE).
Support for RACAL IT Security's SRM product for HSM.
Support for i-data afp-software's SMF record.
Support for NTSMF 2.3 (COMPAT), 21 new NT objects added.
Enhanced RMFINTRV/VMXGRMFI permits over 100 workloads. See 17.04.
RACF command keywords specified/ignored now decoded in TYPE80A.
Major enhancements added in MXG 17.01:
Support for DB2 type 102 subtype 199, Dataset I/O.
Support for Index Statistics in T102S022.
Support for deaccumulation of TYPE30_6 data.
Support for APAR OW37708/APAR OW38073 new fields.
Support for APAR OW15406 (IODF Creation now YYYY).
Support for "FICON" channels adds fields compatibly.
Support for Candle V400 Omegamon for CICS Epilog.
Support for IXFP/ICEBERG Subtype 8 and fix forsubtype6.
Support for NTSMF new Quota Server object.
Support for TANDEM F40, G04 and G05 INCOMPATIBLE.
Changing Interval with DURSET didn't change ASUM70PR.
Don't use PDB.TYPETMNT. USE PDB.ASUMTAPE for mounts.
ML-19 of ASMTAPES supresses TMNT005E messages.
TYPEIMSA processing is wrong in 16.16. Use 17.08.
STC SILO SMF record sometimes short.
Unexpected TCP/IP command of STOU protected.
TMS Julian dates printed as 2E6, format now 7.
Revised and documented utility to modify BUILDPDB.
Text in col 72 cause unexpected failure.
All of these enhancements are described in the Change Log, below.
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.8.0 Aug 24, 1999 16.09
OS/390 2.8.0 FICON/PAV/SHARK Aug 24, 1999 17.08
OS/390 2.9.0 Mar 31, 2000 17.17
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
CRR 1.6 Jun 24, 1994 12.02
CRR 1.7 Apr 25, 1996 14.02
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 Mar 15, 1999 16.09
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
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
RMDS 2.1, 2.2 Dec 12, 1995 12.12
TCP/IP 3.1 Jun 12, 1995 12.12
TCP/IP 3.4 Sep 22, 1998 16.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 ??? ??, ???? 16.08
IMS 4.1 Jul 4, 1994 12.02
IMS 5.1 Jun 9, 1996 14.05
IMS 6.1 ??? ?, 199? 16.04
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
Availability dates for non-IBM products and MXG version required:
MXG Version
Product Name Required
Microsoft
Windows NT 4.0 and NT 3.51 14.14
Windows NT 4.0 Service Pack 2 15.03
Windows NT 4.0 Service Pack 5 16.04
Windows 2000 Build 2195 17.10
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
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 16.02
The Monitor for CICS/ESA 1.2 - 12.12
The Monitor for CICS/ESA 1.3 - 15.01
The Monitor for CICS/ESA 2.0 - 15.06
The Monitor for MVS/ESA 1.3 - 12.05
The Monitor for MVS/ESA 1.5 - 12.05
The Monitor for MVS/ESA 2.0 - 15.09
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 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 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
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
MXG IMS-Log Not-Officially-Supported
IMS 6.1 - ASMIMSL6/TYPEIMSA 17.08
IMS 5.1 - ASMIMSL5/TYPEIMSA 17.08
Amdahl
APAF 4.1, 4.3 16.08
IX. Incompatibilities and Installation of MXG 17.17.
1. Incompatibilities introduced in MXG 17.17 (since MXG 16.16):
a- No changes in MXG architecture were made between 16.16 and 17.17
that introduced incompatiblities.
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.
X. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
XI. Changes Log
--------------------------Changes Log---------------------------------
You MUST read each Change description to determine if a Change will
impact your site. All changes have been made in this MXG Library.
Member CHANGES always identifies the actual version and release of
MXG Software that is contained in that library.
The CHANGES selection on our homepage at http://www.MXG.com
is always the most current information on MXG Software status,
and is frequently updated.
Important changes are also posted to the MXG-L ListServer, which is
also described by a selection on the homepage. Please subscribe.
The actual code implementation of some changes in MXG SOURCLIB may be
different than described in the change text (which might have printed
only the critical part of the correction that need be made by users).
Scan each source member named in any impacting change for any comments
at the beginning of the member for additional documentation, since the
documentation of new datasets, variables, validation status, and notes,
are often found in comments in the source members.
Alphabetical list of important changes after MXG 16.16 now in MXG 17.17:
Dataset/
Member Change Description
All 17.060 MXG Enhancement %LET &Wdddddd=ddname for //WORK copy.
many 17.171 PRINTWAY JCTJOBID='PSnnnnnn' support in TYPETASK.
many 17.214 Support for OS/390 R2.8 (COMPAT, changes were APARs.
ADOCall 17.379 Revisions and updates with new variables in all ADOCs
ANAL42 17.223 Report failed with more than one SYSTEM.
ANAL88 17.185 IBM's sample IXGRPT1 for SMF type 88 replicated.
ANAL91 17.243 Batch Pipes Analysis for APAR PQ25641.
ANALCNCR 17.070 Concurrency analysis now tolerates missing values.
ANALDATE 17.168 Utility to examine dates in SAS data library for Y2K.
ANALDB2R 17.300 Field-width enhancement to DB2PM-like reports
ANALDSET 17.240 MXG 17.03-17.06. DATA SET NOT FOUND corrected.
ANALDSET 17.343 Revised to use MACKEEP instead of IEBUPDTE, NEXTENT.
ANALDSOP 17.198 ANALDSET enhancements (42s, 30 interval, 62s, 6156).
ANALNSPY 17.358 Added and corrected a replica of MICS SNTNSS report.
ANALRMFR 17.160 All BY variables must be in first 4092 bytes.
ANALRMFR 17.369 Several enhancements, this was just most recent.
ASMDALO 17.061 The MXG DASD Allocation Monitor may 0C4.
ASMIMSL5 17.064 0C4 if &DFSMS left at 0 (for DFP) in IMS 5.1.
ASMIMSLx 17.172 Significant IMS Log processing enhancements for test.
ASMIMSLx 17.228 Major IMS Enhancements for MXG IMS log processing.
ASMIMSLx 17.315 Final IMS Revisions for all know negative values.
ASMTAPES 17.046 ML-19 of ASMTAPES supresses TMNT005E messages.
ASUM70PR 17.045 Changing Interval with DURSET didn't change ASUM70PR.
ASUM70PR 17.163 ICF CPUs are now detected and deleted automatically
ASUM70PR 17.203 Dedicated CPU error fixed, use new PDB.ASUMCEC.
ASUM70PR 17.232 PDB.ASUMCEC now created BY CECSER vice BY SYSPLEX.
ASUM78CF 17.178 New ASUM78CF member summarizes PDB.TYPE78CF data.
ASUMDB2A 17.170 DB2 5.1/6.1 new variables added to DB2ACCT summary.
ASUMTALO 17.242 Lost output when multiple days are input is fixed.
ASUMTALO 17.320 Last-complete-interval now corrected.
ASUMTAPE 17.010 PDB.ASUMTAPE replacement for PDB.TYPETMNT.
ASUMTAPE 17.041 Don't use PDB.TYPETMNT. USE PDB.ASUMTAPE for mounts.
ASUMTAPE 17.106 PDB.ASUMTAPE with STATUS=MISSEDMNT handling revised.
ASUMUOW 17.324 WTIRIOTM no longer sum of all IR waits in ASUMUOW.
AUTOEXEC 17.392 Options S=72,S2=72 removed from AUTOEXEC and CONFIG.
BUILDPDB 17.025 Adding/Dropping variables from PDB.JOBS/STEPS/PRINT.
BUILDPDB 17.110 Vars EXCPNODD/IOTMNODD now corrected for MULTIDD='Y'.
BUILDPDB 17.111 Vars TAPEDRVS/TAPE3480/etc corrected for MULTIDD='Y'.
BUILDPDB 17.113 PDB.PRINT new variables SMF6PRMD and SMF6USID added.
BUILDPDB 17.176 OMVS/USS jobs fill SPIN, never purge, now forced out.
CICINTRV 17.391 CICINTRV dataset creation logic was wrong.
CONFIGV7 17.073 Revised CONFIG for SAS V7 eliminates warning msgs.
DOCMXG 17.051 Typos in MACKEEP= examples in documentation corrected
EX80ASEG 17.247 New TYPE80A exit for Top Secret unique segments.
EXPDBOUT 17.357 Example to add CICS Statistics datasets to your PDB.
FORMATS 17.222 Support for APAR OW39508 7060 Multiprise EIO and DSD.
IMACACCT 17.327 Order of code revised so &MACACCT now works.
IMACEXCL 17.229 Omegamon Exclude logic needed SMFPSRVR test.
IMACEXCL 17.356 CICS TS 1.3 Excluded Field example did not work.
MXGSAS 17.317 ABEND 2415 due to no RECFM=U in //NULLPDS in SAS proc
PRINTNL 17.381 Revised utility to print NEWSLTRS/CHANGESS members.
RMFINTRV 17.238 Non-contiguous shift definitions now supported
RMFINTRV 17.322 RMFINTRV now invokes VMXGRMFI, supports 115 workload
RMFINTRV 17.360 RMFINTRV/VMXGRMFI enhancements fixed and documented.
SPUNJOBS 17.311 DATASET CONDCODE NOT FOUND with old IMACPDB.
TYPE102 17.006 Support for DB2 type 102 subtype 199, Dataset I/O.
TYPE102 17.020 Typos. _C012297 should have been _C102297.
TYPE102 17.044 Typos. _C102206 should have been _C102106.
TYPE102 17.056 Support for Index Statistics in T102S022.
TYPE103 17.270 Support for APAR PQ28258 for SMF 103 record.
TYPE103 17.304 Enhanced TYPE1032 Web Server eliminates negatives.
TYPE103 17.314 Deaccum of TYPE1032 for duplicate IPADDRESS.
TYPE108 17.384 Support for Lotus Domino Server Release 5.02.
TYPE110 17.096 Support for GLRHTYPE=2 CICS TS 1.2 Journal segment
TYPE110 17.156 Support for CICS TS 1.3 new field (INCOMPATIBLE)!
TYPE110 17.279 CICS Statistics EOD record has missing DURATM.
TYPE115 17.248 Support for MQ Series Version 2.1 (COMPATIBLE).
TYPE21 17.013 TYPE21/PDB.TAPES variable OPEN is always blank.
TYPE28 17.018 NPM 2.4. Datasets NPMINSES/NPMEVSAL trashed.
TYPE28 17.049 Zero obs in dataset NPMSEEND corrected.
TYPE30 17.009 Support for deaccumulation of TYPE30_6 data.
TYPE30 17.176 TYPETASK='OMVS' instead of TYPETASK='STC ' for USS.
TYPE30 17.385 New foreign enclave times and TYPE30MR in OS/390 R29.
TYPE42 17.042 Type 42 subtype 16 (SMF42Gxx) was out of alignment.
TYPE42 17.059 Support for APAR OW37708/APAR OW38073 new fields.
TYPE42 17.124 Support for Type 42 subtype 7/8 NFS Usage/Users.
TYPE42 17.278 Support for APAR OW40579/41407 SMF 42 subtype 4.
TYPE42 17.355 Type 42 st 7/8 NFS caused INVALID NF-CL TRIPLET.
TYPE50 17.007 Variables BSIZE and MXTRSIZE corrected in TYPE50.
TYPE64 17.032 Extended Format datasets, HIGHRBA now calculated.
TYPE7072 17.162 Support for APAR OW37565 identifies CP or ICF CPUs.
TYPE7072 17.299 CECSER wrong if CPUs added or deleted during interval
TYPE73 17.026 Support for APAR OW15406 (IODF Creation now YYYY).
TYPE73 17.027 Support for "FICON" channels adds fields compatibly.
TYPE73 17.286 PCHANBY/PNCHANBY wrong in initial FICON support.
TYPE74 17.161 Support for APAR OW37816, new 2105 cache TYPE74CA.
TYPE74 17.180 Support for APAR OW31701 ESS Parallel Access Volumes
TYPE74 17.182 TYPE74OM (OMVS/USS) had several variables wrong.
TYPE74 17.269 PCTPNCHA/PCTPNOTH/PCTDVPND/PCTPNDEV revisions.
TYPE74 17.378 Broken Type 74.4 RMF caused INPUT STATEMENT EXCEEDED.
TYPE74CF 17.211 Doc. XSYSn variable blank is most observations.
TYPE79 17.023 CPU time for Pre-emptible SRBs added in TYPE79s.
TYPE80A 17.012 RACF type 80 with optional RACFTYPE=7 had STOPOVER.
TYPE80A 17.094 RACF keywords specified/ignored are now decoded.
TYPE80A 17.158 Top Secret causes many SEGMENT SKIPPED messages.
TYPE80A 17.199 Support for OW39128, PDS DSNAME for PROGRAM access.
TYPE80A 17.218 Support for Top Secret Release 5.1 (INCOMPAT)
TYPE89 17.116 Support for APAR OW37091 Measured Usage SMF 89 change
TYPE90A 17.287 Replacement for TYPE90 member for SMF type 90 data.
TYPE91 17.298 Batch Pipes IC/OC counts propagated into 12/13/15.
TYPE94 17.213 Support for type 94 import/export statistics.
TYPE94 17.245 ERROR.VMAC94.AUDITLEN INVALID error corrected.
TYPE97 17.385 New in OS/390 Release 2.9
TYPEBETA 17.368 Support for Beta91 Balancing Manager SMF record.
TYPECIMS 17.303 IMF, MVIMF, CIMS: SQLCALLS not counted, INCOMPAT.
TYPEDB2 17.090 DB2STATS dataset some QXxxxxxx variables were wrong.
TYPEDB2 17.338 BPHITRAT, Buffer Pool Hit Ratio, revised.
TYPEDB2 17.382 DB2 TCB times QWACSPCP/QWACSPTT included in DB2TCBTM.
TYPEDCOL 17.244 DCOLLECT variables DCACSIZ/DCACACIC were missing.
TYPEDCOL 17.281 Support for DFSMS/MVS V1R5 - in place, no changes.
TYPEDCOL 17.307 Support for APAR OW41147 ORGEXPDT=99999 Y2K Critical
TYPEDCOL 17.347 Year 2000. IBM APAR OW42559, UCCOLDT in DCOLCAPD.
TYPEEDGR 17.016 Dataset EDGRDEXT has zero observations.
TYPEEPIL 17.003 Support for Candle V400 Omegamon for CICS Epilog.
TYPEEREP 17.339 INPUT STATEMENT EXCEEDED for EREP records.
TYPEHSM 17.019 HSM _DIFFHSM macro relocated into VMACHSM.
TYPEHSM 17.021 HSM Julian dates printed as 2E6, format now 7.
TYPEICE 17.048 Support for IXFP/ICEBERG Subtype 8 and fix for st 6.
TYPEICE 17.346 INVALID DATA FOR IOSSTIME, Icebert IXFP subtype 8.
TYPEIDAP 17.100 Support for i-data afp-software SMF record.
TYPEIISL 17.321 Support for IIS Log.
TYPEIMSA 17.011 TYPEIMSA processing is wrong in 16.16. Use 17.08.
TYPEIMSA 17.290 More IMS Log revisions correct negative RESPNSTM.
TYPEIPAC 17.234 Support for Mobius View Direct 6.1.2 (INFOPAC).
TYPEITRF 17.336 Variables IMSVERS,IMSRELEASE,SMBCLASS numeric now.
TYPELDMS 17.371 Support for Software Innovation's LDMS product.
TYPEMIM 17.152 Support for MIM user record enhanced, new dataset.
TYPEMRKV 17.099 Support for Lexmark MarkVision Job Statistics
TYPENDM 17.155 Support for Connect Direct R 3.2 'CT' record.
TYPENOAM 17.122 Support for STK's NearOAM V2.2 (COMPATIBLE).
TYPENSPY 17.154 Zero obs in NSPYTIC3 (again, due to Change 16.147).
TYPENSPY 17.367 NETSPY NSPYAPPL dataset had missing response times.
TYPENTSM 17.055 Support for NTSMF new Quota Server object.
TYPENTSM 17.101 Support NTSMF Version 2.3 (COMPAT), 21 new objects.
TYPENTSM 17.165 Protection for Win 2000 Beta 3. IIS, Web changes.
TYPENTSM 17.209 Support for Lotus Notes, SMPTDS/SMTPRS objects.
TYPENTSM 17.335 Support for Windows 2000 Build 2195 NTSMF data.
TYPEORAC 17.308 Support for SQL*NET NIV adds IPADDR/PORTNR to ORACLE.
TYPEPMTR 17.297 Support for unix PerfMeter Freeware Monitor records.
TYPEQAPM 17.107 Support for OS/400 V4.3.0, no change, is in 16.16.
TYPEQAPM 17.235 Support for OS/400 Release 4.4.0 (LRECLs INCOMPAT)
TYPERACF 17.305 Support for RACF Unload IRRDBU00 Started Task subtype
TYPESARR 17.306 Support for CA View Metrics SARSMFUX SMF record.
TYPESARR 17.309 Support for remaining CA-VIEW Metrics validated.
TYPESFTA 17.092 Support for SOFTAUDIT 6.1.2 (COMPATIBLE).
TYPESFTA 17.123 Support for SoftAudit Version 7.1 (COMPATIBLE).
TYPESRMH 17.085 Support for RACAL IT Security's SRM product for HSM.
TYPESTC 17.040 STC SILO SMF record sometimes short.
TYPESTC 17.195 Support for STK's VTCS 2.2.0 INCOMPATIBLE VSM SMF.
TYPESTC 17.230 Variables STC07FPS/TPS now match STK utility report.
TYPESTC 17.313 Variables STC11CI/CE/TOL were blank.
TYPESYNC 17.145 SYNCSORT variables COREREQ/COREUSED now 8-byte store.
TYPESYNC 17.199 Support for 32 (up from 16) sorworks for SYNCSORT.
TYPESYNC 17.350 Flags CONTIGn,CACHFWn fixed, DYNALOn,UNOPENn added.
TYPETAND 17.037 Support for TANDEM F40, G04 and G05 INCOMPATIBLE.
TYPETAND 17.115 TANDEM G05 and later TANDDISK corrected.
TYPETCP 17.034 Unexpected TCP/IP command of STOU protected.
TYPETCP 17.349 TELNET LOGF Time field is Duration, not datetime!
TYPETELE 17.091 Support for TELEVIEW 4.3 (INCOMPATIBLE).
TYPETELE 17.246 Support for TeleView 4.3B subtype 3 record.
TYPETMDB 17.280 Support for Landmark DB2 Monitor V 3.2 (INCOMPAT).
TYPETMNT 17.216 ASMTAPES needed 'ES6' at ASM for Y2K, this protects.
TYPETMO2 17.169 Landmark TARSPTM contains sum of all conversations.
TYPETMS5 17.021 TMS Julian dates printed as 2E6, format now 7.
TYPETMS5 17.151 Undocumented DENX='DE'x TMS records now supported.
TYPETMS5 17.352 Year 2000. Variable OUTDATE was still 0cyyddd.
TYPETMV2 17.259 Support for TMON/MVS V2 PTF TD01655 (COMPAT).
TYPETMV2 17.333 Support for additional Landmark TMVS subtypes.
TYPETPF 17.200 Support for IBM's TPF Operating System records.
TYPETPX 17.036 TPX Start Up record subtype 1 not properly decoded.
TYPETRMS 17.284 Support for TRMS Version 51A08 (COMPATIBLE).
TYPEUNIC 17.002 TYPEUNIC support for CA UniCenter is for Open VMS.
TYPEZARA 17.344 Year 2000. Support for ZARA Release 1.3 (INCOMPAT).
UTANDSTR 17.241 Tandem Utility to read "Unstructured" with new LRECLs
UTILBLDP 17.054 Revised and documented utility to modify BUILDPDB.
UTILRMFI 17.271 UTILRMFI to show IMACWORK definitions CPU sources.
VMAC102 17.253 DB2 trace SQL text variables use &SASCHRLN length.
VMAC110 17.220 SMF type 110 subtype 0 JCRLL=0 error.
VMAC28 17.018 NPM 2.4, NPMINSES/NPMEVSAL datasets trashed.
VMAC80A 17.316 WARNING: BIT MASK TOO LONG corrected.
VMACDB2 17.300 Negative QXSELECT because DB2 overflowed counter!
VMACIMSA 17.011 MXG ASMIMSLG/L5/L6, STRTTIME is missing due to typo
VMACIMSA 17.228 SAP IMS 'AE'x log record was NOT Y2K Ready.
VMACTMDB 17.319 Landmark DB2 Version 3.0 INPUT STATEMENT EXCEEDED.
VMXGINIT 17.250 MXGVERS specification removed from VMXGINIT.
VMXGINIT 17.251 USER= option protected, &SASCHRLN= created
VMXGRMFI 17.142 Enhanced RMFINTRV permits over 100 workloads.
VMXGRMFI 17.388 Added DROPPGN=,DROPSRV= for easier RMFINTRV tailoring
VMXGSUM 17.193 Dashed-variable-list now correctly supported.
VMXGSUM 17.255 New stats, INHERIT exploitation under SAS V8.
VMXGSUM 17.265 VMXGSUM revisions now implemented in MXG 17.08.
VMXGVTOF 17.341 Year 2000. CREATED,EXPIRES,LASTUSE wrong.
WEEKBLDT 17.029 Text in col 72 cause unexpected failure.
XMXGSUM 17.370 Test version of VMXGSUM using SAS View to save DASD+.
YEAR2000 17.363 Year 2000. Julian 0cyyddd values convert to yyyyddd.
Inverse chronological list of all Changes:
NEXTCHANGE: Version 17.
======Changes thru 17.398 were in MXG 17.17 dated Feb 7, 2000======
Change 17.398 DEVICE Activity Report can now utilize the INTERVAL and
ANALRMFR MYTIME parameters for summarization tailoring. All of
Feb 6, 2000 the ANALRMFR reports will eventually hav these options.
Change 17.397 The revised CICINTRV dataset did not contain variable
VMXGCICI DATETIME, which is archaic and STARTIME should be used
Feb 6, 2000 in your reports, but now they will still work.
Change 17.396 Support for EMC's InfoMovers Product's SMF record.
EXINMVCL creates two datasets:
EXINMVSR INMVCLNT - Infomover Client Record Subtype 1
IMACINMV INMVSRVR - Infomover Server Record Subtype 2
TYPEINMV These records look much like FTP records, but do not
TYPSINMV contain IP addresses, but do have additional statistics.
VMACINMV However, the start and end time variables INFSTART/END
VMXGINIT are bad, containing INFEND= '38970868'x which should be
Feb 6, 2000 close to the record's SMFTIME of '005F7F11'x.
Feb 7, 2000 EMC has opened tracking number 2951232 to resolve, but
was unaware of the error.
Thanks to Charles Piggott, SAS Europe, GERMANY.
Thanks to Mr. Ragaglia, ITS - FIAT, ITALY.
======Changes thru 17.395 were in MXG 17.11 dated Feb 2, 2000======
Change 17.395 Change 15.268 was supposed to have added DURATM=INTERVAL,
ASUMHSM to the VMXGSUM invocation in ASUMHSM, but was overlooked
Feb 2, 2000 until now. And work datasets HSMINTVL/HSMSTAT are now
deleted at the end of execution of ASMHSM.
Thanks to Chris Weston, SAS Institute ITSV, USA.
======Changes thru 17.394 were in MXG 17.11 dated Jan 31, 2000======
Change 17.394 Example had three sets of pairs of strange characters in
ANALBATW lines 77, 78, and 170; those characters should each be
Jan 31, 2000 an exclamation point, since a pair of exclamation points
are used for character string concatenation (instead of
long vertical bars, precisely because exclamation points
are correctly translated by Rhumba, but long vertical
bars are not, and I missed that error when I edited this
contribution that had gone thru Rhumba enroute to MXG).
Thanks to Raff Rushton, Kaiser Permanente, USA.
Change 17.393 IBM RMF-like CACHE Subsystem Activity Report can now be
ANALRMFR created by ANALRMFR. New REPORT=CACHE argument will
Jan 31, 2000 create the report from TYPE74CA Cache DASD records.
Thanks to Jiann-Shiun Huang, CIGNA, USA.
Change 17.392 MXG 17.01-17.11, on ASCII (PC or Workstations) only. To
AUTOEXEC make AUTOEXEC and CONFIGxx members consistent, I added
CONFIG OPTIONS S=72 S2=72 into the AUTOEXEC member in MXG 17.01,
CONFIGV7 but only today did Chuck discover that those options have
CONFIGV8 entirely different meanings to SAS under MVS than under
Jan 31, 2000 ASCII! Originally they were needed to prevent SAS from
reading source statement columns 73-80, because that's
where MVS fixed length files are numbered, and under MVS
with fixed length input, options S=72/S2=72 do set the
MAXIMUM column to be read. However, under PC/unix, with
variable length -SYSIN input, SAS documents that they
instead set the MINIMUM column to be read, causing SAS to
skip input columns 1-71! When PC SAS read that OPTIONS
statement in AUTOEXEC.SAS, it began ignoring columns 1-71
in remaining lines, and never read nor ran the %VMXGINIT
statement that followed that OPTIONS statement!
Fortunately, those options are now deleted from AUTOEXEC
(and for consistency, also from the CONFIGxx members),
because MXG Software has been unnumbered since 1992.
P.S. I keep several AUTOEXEC.xxx members in the SAS root
directory and copy the one I want (kinda like JCL) into
the AUTOEXEC.SAS member and then start SAS. However, you
can also change the autoexec using
c:\sas\sas.exe -config 'c:\mxg\sourclib\config.sas'
-autoexec 'c:\mxg\sourclib\autoexec.sas'
either in batch execution or in separate shortcuts for
your differing file allocations, etc.
Making MXG.SOURCLIB VB on MVS reduced it from 150 cyl
to 95 cylinders, reduced BUILDPDB EXCPs for compile
from 13,326 to 12,886, and CPU time from 45 to 43 sec.
It doesn't hardly seem worthwhile!
Change 18.147 reinstated S=72,S2=72 in CONFIGV8. 29JUN00.
But S=72,S2=72 should NOT be in your AUTOEXEC.SAS file.
Thanks to Chuck Hopf, MBNA, USA.
Change 17.391 -CICINTRV dataset creation logic was wrong, causing the
CICINTRV non-INT event records (REQ/USS/EOD) to be put in the
VMXGCICI wrong interval. But IBM caused STARTIME to be wrong in
VMXGDUR INT interval records, because DURATM was found wrong:
VMXGSUM CICDS Interval records with DURATM=03:00:00 and the
Jan 30, 2000 COLLTIME=06:00:00 (so then STARTIME=03:00:00), but
CICSSTCK=03:48:00 when this region started. The
interval record has SMFSTINO=1, but that interval
number is reset at midnight! Since the CICDS record
has the dispatcher durations, adding DSGTWT=DSGTDT
showed the true duration of this interval was 02:12:00
and the IBM DURATION of 3 hours was wrong!
MXG uses COLLTIME to group records. The COLLTIME in the
INT records is the end-of-interval value and is the same
in all INT records for that interval (e.g. 03:00:00),
which VMXGCICI floored correctly to 03:00:00 for summary.
However, because the COLLTIME in the EOD, REQ and USS
records is a distinct event time (e.g. 03:05:01.99 for a
file close), it is not the end of interval, so VMXGCICI
incorrectly floored that COLLTIME back to the 03:00:00
end time of the prior interval. This logic error was
corrected by adding the INTERVAL value to the COLLTIME
for the non-INT records and then flooring that sum back
to the end of this interval.
This works for timed intervals, but INTERVAL=SHIFT is
not supported at this time, as there is no obvious
way to determine the end of shift. Call if wanted.
-STARTIME is now calculated based on the DSGTDT+DSGTWT or
DURATDS from the dispatcher record, if one is found, and
the STARTIME will be exact if the COLLTIME is exact and
the DURATDS is within 30 seconds of exact. If there were
no CICDS records for an interval both the STARTIME and
DURATM will be set missing and COLLTIME will be the end
of interval.
-Variable SMFSTRQT is now kept in PDB.CICINTRV to identify
the source (EOD/INT/REQ/USS).
-New INTERVAL=EOD option will combine all of the records
for a region's execution together and give you total
resources for each execution.
-New INTERVAL=THREEHR option is an attempt to match IBM's
default interval, and works fine as long as all regions
create interval records.
-But you can still get strange results if you request
CICINTRV to be summarized at an INTERVAL that is smaller
that your CICS interval, or if a region writes EOD,REQ
and USS but doesn't write interval records: a region
started at 01:00, wrote three USS CICFCR close records at
05:05:, and then wrote an EOD record at shutdown at
12:00. CICINTRV with hourly default created one obs for
the 05:00-06:00 event, with only the FCR counts, and then
the EOD record created an overlaping 01:00-12:00
observation with all other measurements.
Thanks to Normand Poitras, ISM, CANADA.
Change 17.390 The default value for &SASCHRLN was changed back to 100
VMXGINIT from 200 so those SQL text variables under SAS V6 are the
Jan 28, 2000 original length and agree with labels. See Change 17.253.
Thanks to Jarl L. Bruvoll, VPS, NORWAY.
Change 17.389 Support for HP's Measureware V11.0 for HPUX adds several
VMACMWUX fields (incompatibly, since they were inserted in the
Jan 28, 2000 middle of the records).
Thanks to Tony P. Steward, Post Office, ENGLAND.
Change 17.388 Additional arguments were added for better tailoring, and
VMXGRMFI additional new variables are now kept in both RMFINTRV
Jan 27, 2000 and TRNDRMFI datasets.
-New OPERANDS:
If you specified IMACWORK=NO and USEREPRT=YES, you could
not drop unwanted Control Performance Groups or Service
Classes; now you have these new operands:
DROPPGN= A list of performance groups numbers, which
could be either Control or Report Performance
groups, that are to be deleted.
DROPSRV= A list of service class names, which could be
either Service or Reporting Class names, that
that are to be deleted.
In case you really need to add special logic as each of
the individual TYPE7xxx datasets are brought in, these
new macro variables permit insertion of any SAS code:
INCODE70= INCODE71= INCODE72= INCODE73= INCODE74=
INCODE75= INCODE78=
-Migration age was not being tracked by RMFINTRV so the
MIGAGEMX, MIGAGEMN, and MIGAGEAV variables were added,
and if it makes sense to track migration age, it should
make sense to also add the HIUIC values.
RMFINTRV new variables:
HIUICMN HIUICMX MIGAGEMN MIGAGEMX MIGAGEAV IORATE70
TRNDRMFI new variables:
HIUICMN HIUICMX MIGAGEMN MIGAGEMX MIGAGEAV IORATE70
PMGIEXAU
-Note that the actual values many variables in RMFINTRV &
TRNDRMFI datasets that came from TYPE71 with labels that
indicate they are average values are actually the maximum
value of the average value of each of the individual RMF
interval values. These variables are:
FIXEDAV CSLPFXAV LPAFXAV LSQAFXAV PRVFXAV SQAFXAV
FIXLOAV PCTLSWAP PVTAFCAV CSTORE ESTORE
Thanks to Normand Poitras, ISM, CANADA.
Thanks to Raymond Schwartz, First Data, USA.
Change 17.387 The _STY94 macro contained PROC DELETE instead of invoke
VMAC94 of %VMXGDEL(DDDDDD=TY94), so you could not change the PDB
Jan 26, 2000 ddname and sort into work. With this correction, the MXG
syntax: %INCLUDE SOURCLIB(TYPE94);
%LET PTY94=WORK;
_STY94;
will sort WORK.TYPE94 into WORK.TYPE94. Note that this
syntax is general, and works with all TYPExxxx members.
Thanks to Joseph M. Marchesani, Equitable, USA.
Change 17.386 MXG 17.10 only. Labels for BYTEREAD and BYTERPCR contain
VMACNTSM extraneous trash and hex characters that should have been
Jan 26, 2000 errored by the SAS compiler, but weren't detected until
execution of their data records, causing unrelated error
message INVALID HEXADECIMAL CONSTANT STRING CONNXAFA=....
Thanks to Bob Gauthier, Albertsons, Inc, USA
Change 17.385 Support for OS/390 Release 2.9.
BUIL3005 TYPE30:
BUILD005 - New SMF30WMI variable 'Y' identifies jobs executing in
EXTY30MR a WLM managed batch initiator.
EXTY9207 - New SMF30MSI variable 'Y' if remote system data is
EXTY94 incomplete. I don't know what this really means, but
FORMATS suspect it means a permanent data loss.
IMAC97 - New triplet for the Multisystem Enclave Remote Data,
TYPE97 with a separate section for each system on which remote
TYPS97 enclaves of this job were executed, contains:
VMAC30 RMSU_SEC - CPU SU_SEC OF THIS REMOTE SYSTEM
VMAC7072 MRENSYST - SYSTEM ID OF THIS REMOTE SYSTEM
VMAC97 CPUMRDTM - CPU TIME FOR DEPENDENT REMOTE ENCLAVES
VMXGINIT CPUMRITM - CPU TIME FOR INDEPENDENT REMOTE ENCLAVES.
Jan 26, 2000 These variables are output in the new TYPE30MR dataset
with an observation for each segment in this job, but
the CPUMRDTM and CPUMRITM are summed across all of the
remote segments and the sum is kept in TYPE30_V, _4,
and TYPE30_5 datasets, as well as being kept in the
PDB.STEPS and PDB.JOBS built by BUILDPDB.
If your remote systems are of different speeds, you
may want to normalize these remote CPU times before
they are output; the exit member EXTY30MR allows you
to normalize the new CPUMRDTM and CPUMRITM if needed.
TYPE72/TYPE72GO
- Three new Active durations for enclaves were added:
to the TYPE72 and TYPE72GO datasets:
TYPE72 TYPE72GO Description
SMF72IEA R723CIEA INDEP*ENCLAVES*ORIGINATED*ACTIVETM
SMF72XEA R723CXEA EXPORTED*ENCLAVES*TOTAL*ACTIVETM
SMF72FEA R723CFEA FOREIGN*ENCLAVES*TOTAL*ACTIVETM
TYPE92
- New subtype 7 for NFS FILE SYSTEM MOVE creates new
TYPE9207 dataset with 33 variables.
TYPE97
- New SMF type 97 for FOREIGN ENCLAVE CPU TIME creates
dataset TYPE97 with an observation for every system
that exported Enclaves to this system containing the
Dependent and Independent Enclave CPU time consumed
by Foreign Enclaves on this system.
Change 17.384 Support for Lotus Domino Server Release 5.02 SMF 108,
EXTY1083 added GMT interval start/end times, system, sysplex and
IMAC108 level to the product section, which are now added to the
VMAC108 existing subtype 1 datasets (with a heuristic algorithm
VMXGINIT to convert GMT to local until IBM adds the GMT Offset).
Jan 26, 2000 The new subtype 3 Monitoring and Tuning data record now
creates new dataset TYPE1083 with interval activity and
buffer pool statistics. Problems with subtype 3 data:
- Five counters in Release 5.02 are accumulated:
DOMTDBCI (DBCACHE Initial DB Opens) and
DOMTDBCO (DBCACHE OVERCROWDING REJECTIONS)
DOMTDBHI (DBCACHE Hits)
DOMTDBPR (DATABASE BUFFERPOOL READS)
DOMTDBPW (DATABASE BUFFERPOOL WRITES)
which was not IBM's intention, and those counters will
be fixed in Release 5.03 later this year. The MXG
_STY1083 SORT macro deaccumulates those variables only
if the record is from Release 5.02, but you will need
to add _STY1083 in your EXPDBOUT member if you add
SMF 108 record processing to you BUILDPDB.
- These MXG subtype 3 variables are set by environmental
server variables, rather than being measurements:
DOMMXUS /*MAXIMUM*NUMBER*OF USERS*/
DOMTLMCS /*LIMIT FOR*CONCURRENT*TRANSACTIONS*/
DOMTMXCS /*MAXIMUM*CONCURRENT*SESSIONS*/
DOMTTMOT /*DURATION*IN*TIMEOUT*/
DOMTMXCU /*MAXIMUM*CONCURRENT*UPDATE*TASKS*/
DOMTMXRE /*MAXIMUM*CONCURRENT*REPLICATORS*/
DOMTSATH /*SERVER*AVAILABILITY*THRESHOLD*/
If you don't change the corresponding environmental
variable at your installation, a default value is put
in the SMF record. For the 2nd-4th fields, default
values are meaningless: FFFFFFFF FFFF000 F900, (so
variables DOMTLMCS, DOMTMXCS and DOMTTMOT are set
missing if they contain those values).
Thanks to Tom Wieland, Phoenix Home Life, USA.
Change 17.383 Member IMACJBCK ("Job Check" exit) is now included in
VMAC83 these members that input JOB and READTIME. The IMACJBCK
VMAC92 exit lets you select SMF records for specific JOBs. Four
VMACHIPR other members, VMACSTC, VMACSUIN, VMACTCP, and VMACWSF
Jan 24, 2000 do contain job name, but they do not have the READTIME so
without both JOB and READTIME (the "job log"), they are
not really written on behalf of a job execution, and so
they don't include IMACJBCK.
Thanks to Chuck Hopf, MBNA, USA.
Change 17.382 DB2 TCB time for stored procedures (QWACSPCP & QWACSPTT)
VMACDB2 are now added into DB2TCBTM variable in DB2ACCT, as they
Jan 24, 2000 are not already captured in DB2TCBTM.
Thanks to Brandon Persinger, The Gap, USA.
Change 17.381 Revised utility program to print MXG Newsletters from the
PRINTNL member NEWSLTRS or CHANGESS, under either MVS or ASCII.
Jan 24, 2000 To print Newsletters using MS Word:
Open NEWSLTRS.SAS as a new document.
Adjust the page setup:
Select portrait
Set top.bottom margins to .6 inches.
EDIT/REPLACE ALL _PAGE_ with a "manual page break",
by select "more" on the replace panel then
"special" to get to this option.
EDIT/SELECT ALL change font to COURIER NEW 9 point
PRINT
Change 17.380 First MXG 17.10. The first few tapes had version date of
AAAAAAAA Jan 20, 1999, which was not Y2K Ready. MXG 17.10 dated
Jan 24, 2000 Jan 24, 2000 corrected that cosmetic error, since that
is only a display string and is not a SAS date value.
Thanks to Freddie Arie, Lone Star Gas, USA.
Change 17.379 Documentation. All ADOCxxxx members were examined and
ADOCall revised to be consistent (i.e., force ZDATE to always be
Jan 24, 2000 the last listed variable for each dataset) so that we can
programatically compare the variables in member DOCVER
with each ADOC and update the ADOC with new or changed
variables while still keeping the original ADOC text.
Thanks to Freddie Arie, Lone Star Gas, USA.
Change 17.378 Type 74 subtype 4 (Coupling Facility) records caused MXG
VMAC74 to "INPUT STATEMENT EXCEEDED" because only 12 of the 18
Jan 24, 2000 structures had complete data in the RMF record. Whenever
the total size of the structure Request Data and Cache
Data sections is greater than 32760, IBM creates multiple
"broken" records from the "large" record, but the 74.4
"broken" records, unlike the 74.1 and 74.2, are invalid.
Instead of RMF writing one SMF record with 12 structure
Request Data sections and the associated 134 Cache Data
sections, and then writing a second record with the other
6 structure's Request Data sections and the associated 2
Cache Data sections, RMF wrote a first record containing
all 18 structure Request Data sections and the 134 Cache
Data sections for structures 1-12, and then RMF wrote a
second SMF record containing only the two remaining Cache
Data sections (one each for structure 13 and 14), but as
neither the Structure nor Request Data sections are in
that second record, it is IMPOSSIBLE for MXG to decode
the second broken record.
The record has SMF74RAN=1, indicating the "Reassembly
Area" exists, but that design (to reassemble multiple
"broken" records into a large record in the virtual
memory of the reading program) requires offsets from one
SMF record to be used to input fields in another SMF
record, and that algorithm fails unless all of the SMF
broken records are adjacent and found in the input SMF
file, which cannot be guaranteed (as, for example, when
the first broken record is the last record in today's SMF
file, or if the SMF data was presorted).
"Broken" records and reassembly areas are not new, but
IBM has previously never spanned logical data fields
between two physical records. Both the 74 subtype 1 and
subtype 2 records are "broken" when there are many
devices, but each "broken" record is self-contained and
can be decoded with no dependency on other records. The
required solution for the type 74 subtype 4 record is for
IBM to write self contained data records. The first
record should contain only as many Request Data sections
as will fit with their associated Cache Data sections.
Second and subsequent records must contain the Product,
Local Coupling Facility, and Structure data sections, and
then as many Request Data and their Cache Data sections
that will fit together.
To circumvent the error, an additional condition:
AND CDSILOC+SMF744CL LT LENGTH
was inserted in the existing IF statement
IF R744CDSI GT 0 AND R744CDNE GE 1 THEN DO;
before the THEN, so that the missing cache data sections
are skipped (causing missing values in TYPE74ST). Thus
far, only a few bad 74.4 records have been found per
day on this OS/390 R2.8 system.
While IBM's RMF Reporter does handle these broken records
if they are found in the same SMF input file (which RMF
has to first sort for the reassembly algorithm), if the
second record is not in today's data, the RMF Report just
skips that interval in its reports!
In conversation with RMF developers, they have now agreed
to revise their design so that when "broken records" must
be written, they will be self-contained and not dependent
on the contents of other records for decoding.
This investigation also uncovered an MXG oversight; only
the first cache data section was read for each structure,
but there are a few structures that have as many as 63
cache data sections, (but only two of those sections had
any non-zero counter values!). Now MXG sums all of the
cache data section counters for each structure.
Thanks to Steve Lottich, University of Iowa Hospitals, USA.
Change 17.377 Change 17.290 changed SORT fields, but this JCL example
JCLIMSL6 was overlooked (LG and L5 were correct). It should be:
Jan 21, 2000 SORT FIELDS=(1,12,A,43,8,A,29,1,A),FORMAT=BI
as described in the text of that change.
Thanks to John Pierce, Liberty Mutual, USA.
Change 17.376 Variables POOLNPBY and POOLPGBY in NTINTRV dataset were
NTINTRV from the SERVER dataset instead of from the MEMORY data,
Jan 21, 2000 so their values were not correct in NTINTRV. Inserting
(DROP=POOLNPBY POOLPBY) after _LNTSERV in the MERGE
statement will correct this error.
Thanks to Greg Jackson, National Life of Vermont, USA.
======Changes thru 17.375 were in MXG 17.10 dated Jan 20, 2000======
Change 17.375 Report was showing equal utilization of the channel for
ANALPATH both the LPAR and the CEC.
Jan 20, 2000
Thanks to Tony P. Steward, Post Office, ENGLAND.
Change 17.374 Windows 2000 NTSMF enhancements, etc.
EXNTSMTN -Objects 'Job Object' and 'Job Object Details' are still
EXNTTRMS flakey, sometimes containing NRNAMES and instance names
EXNTTRMV (1 in Job Object, 2 in Details), sometimes NRNAMES=0.
FORMATS While this is being resolved, MXG now protects both,
IMACNTSM (but if NRNAMES=0, then the names will be blank and the
VMACNTSM records of questionable utility!).
VMXGINIT -New variable FTPUPTME added to FTPSERV dataset from the
Jan 20, 2000 'FTP Service' object.
-Three new objects supported:
dddddd Dataset Object
NTSMTN SMTPNFS SMTP NFS Store Driver
NTTRMV TERMSERV Terminal Services
NTTRMS TERMSESS Terminal Services Sesion
-Sixty new variables added to SMTPSERV dataset from the
'SMTP Server' object are protected, but not input; I
ran out of time in building MXG 17.10, but call for
the update.
Jan 21, 2000: No update needed; MXG 17.10 did contain
all of the new variables, but I forgot to go back and
change this text.
Thanks to Jim Quigley, Con Edison, USA.
Change 17.373 TRNDRMFI has been updated to keep xxxxMEMR memory vars
TRNDRMFI as 8 bytes, like all other measures of memory, so that
Jan 20, 2000 there is no loss of resolution.
Change 17.372 Replaced by Change 17.378.
VMAC74
Jan 20, 2000
Change 17.371 Support for LDMS product creates three new datasets:
EXLDMSDB dddddd dataset label
EXLDMSDI LDMSDB LDMSBASE SI-LDMS-BASE
EXLDMSPC LDMSDI LDMSDIST SI-LDMS-DIST
FORMATS LDMSPC LDMSPC SI-LDMS-PC
IMACLDMS in this user-contributed enhancement.
TYPELDMS LDMS is from Software Innovation in Germany, and it is
TYPSLDMS used for archiving and viewing JCLLOG, SYSLOG, reports
VMACLDMS and lists that were previously printed and delivered.
VMXGINIT
Jan 20, 2000
Thanks to Thomas Heitlinger, FIDUCIA IT AG AG, GERMANY.
Change 17.370 This test version of VMXGSUM enables a SAS VIEW in the
XMXGSUM first datastep to reduce time and resources (CPU, I/O,
Jan 19, 2000 and especially DASD space, since a VIEW is essentially a
pipe that avoids hardening a dataset. This version also
allows you to create the output dataset as a view with
OUTDATA=X/VIEW=X, syntax (but of course you must use that
dataset before you invoke VMXGSUM again). This member
will become VMXGSUM in the next version, but is placed
here for wider testing; copy this XMXGSUM into VMXGSUM
in your USERID.SOURCLIB to test it yourself.
Thanks to Chuck Hopf, MBNA, USA.
Change 17.369 CPU Activity Report can now utilize the INTERVAL and
ANALRMFR MYTIME parameters for summarization tailoring.
Jan 18, 2000
Change 17.368 Support for Beta91 Balancing Manager SMF Record creates
EXTYBE9A four new datasets from the many subtypes:
EXTYBE9B "dddddd" Dataset Label
EXTYBE9C TYBE9A BETA91A BETA91 HEX ST 10,14,28,48
EXTYBE9C TYBE9B BETA91B BETA91 HEX ST 22,24,36,42,44
FORMATS TYBE9C BETA91C BETA91 HEX ST 50
IMACBE91 TYBE9D BETA91C BETA91 HEX ST 60
TESTUSR1 The second variable data portion of the subtype 22-44
TYPEBE91 record is not documented, so those fields are not yet
TYPSBE91 decoded into dataset BETA91B.
VMACBE91 -Minor, but SMFCSTIM was shifted one byte to the left in
VMXGINIT the record ('45400000'x instead of '00454000'x for noon),
Jan 17, 2000 so there is an extra divide by 256 required.
Thanks to W. Waldeyer, BHF-Bank AG, GERMANY.
Change 17.367 NETSPY NSPYAPPL dataset had missing values for response
EXNSPYAP time and percentages when NETRSPN6 (computed number of
VMACNSPY LU6.2 responses) was zero. Logic was added to use the
Jan 15, 2000 TOTRSPN6 (total number of LU 6.2 responses) if NETRSPN6
is zero. Additionally, exit EXNSPYAP tested only TRANSNO
or OUTPUTNO, which suppressed output of any interval that
had LU6.2 traffic but no 3270 traffic. The test now also
tests TOTRSPN6 so that LU6.2-only intervals are output.
Thanks to Julian Smailes, Experian Limited (UK), ENGLAND.
Change 17.366 Deleted TMS volumes still in the TMC that had DENX=00x
VMACTMS5 printed DENSITY IS MISSING and a hex dump of the record
Jan 14, 2000 on the log, with no other impact. The existing test
ELSE IF DENX=0DEX THEN DEN=0; was expanded to read
ELSE IF (DENX=0DEX OR DEL='Y') THEN DEN=0; and that
block of code was relocated to after DEL='Y' is set.
Thanks to Warren Hayward, TJX, USA.
Change 17.365 The _Sdddddd and _Bdddddd macros (SORT and BY list) have
VMACTCP been updated so they can now be used. The _SUBTCP5 macro
Jan 13, 2000 was deleted, as it was never referenced; the statistics
record is recognized by length, not by subtype (which was
user-settable and thus not reliable!).
Thanks to Dr. Alexander Raeder, Karstadt AG, GERMANY.
Change 17.364 XCF Path Statistics report, updated to report all
ANALRMFR paths.
Jan 13, 2000
Thanks to Neil Ervin, Schwab and Company, USA.
Change 17.363 Year 2000. Julian Date Values for these products have
VMACACF2 been protected to convert 01yyddd values to 20yyddd:
VMACCTLT TYPEACF2 - LIDADATE, LIDCDATE, LIDDXPDT, LIDIPDAT, prot.
VMACLMS TYPECTLT - CTLTDSN/CTLTVOL variables protected.
VMACPROS but there are EXPDT fields that are not
Jan 14, 2000 protected for invalid dates (like 99366).
TYPELMS - This code had not been updated in a long time.
EXPDT is now correct, but several datasets
were also corrected, and the code now runs
under ASCII as well as EBCDIC versions of SAS.
These changes support Sutmyn/VTS/LMS 3.4.
TYPEOMAU - OMJULDAT is protected, and OMDATIME corrected.
TYPEPROS - GWADATE protected. GWAEXPDT is character.
TYPEWSF2 - No julian date variable, listed in error.
Unfixed, awaiting raw data:
TYPEIAM: IAMCDATE=0852 decimal, 0354 hex, doc dddy!!!
Unvalidated, these products have unvalidated fields and
no test data has been made available. See the
member YEAR2000 for variables and datasets:
TYPEBETA TYPECMF TYPEDECS TYPEEDGR TYPEEDGS
TYPEEPIL VMXGHSM TYPESARS TYPETMDB TYPETMVS
TYPETLMS
Thanks to Warren Hayward, TJX, USA.
Thanks to David Ehresman, University of Louisville, USA.
Thanks to Kevin Marsh, AT&T Solutions EMEA, ENGLAND.
Thanks to Caron Know, Willis, ENGLAND.
Thanks to Steve Clark, California Federal, USA.
Thanks to Coen Wessels, UNICIBLE, SWITZERLAND.
Thanks to Caron Knox, Willis Corroon Group Services Limited, ENGLAND.
Change 17.362 Documentation only; no code was changed. Highwatermark
VMACTMO2 and lowatermark values in TMON for CICS/ESA 2.0 (TCE)
Jan 13, 2000 statistics interval records will be always zeroes after
applying SYSMOD TH01288 to TMON, but the HWM values in
the TI record will still be valid, as they are obtained
differently than the TCE records. The SYSMOD text has an
extensive discussion of why the TCE HWM/LWM values cannot
be calculated when the TCE interval is different than the
CICS statistics interval. These fields in these records
will be zero:
Record Fields
TP TPGWLRHW TPGHWMT
TS TSGSTA6F TSGQNUMH TSGNCIAH TSGBUWTH TSGNVCAH
TSGVUWTH TSGQINH
TD TDGAMXIU TDGAMXAL TDGAMXWT TDGAMXCI TDGSMXAL
TDGSMXWT
TX TXGPAT TXGPQT
TR TRVRPLX TRVRPLXT TRXMCPAT TRXMCCPQ TRVLUHWM
T2 T2TCBQHW T2TCBHWM T2ETHDHW T2EPTHDP T2EHTASK
T2EH
TM TMCE1HWM TMCE2HWM TMCEBHWM TMCESTAM
TT TTRMCNT
TF TFFDSHSW TFFDTSHI
Change 17.361 Extension to Change 17.339 for EREP records. Now, all
VMACEREP EREP record types are tested and will be bypassed (and
Jan 12, 2000 and MXG WARNING message printed on the log) if any of the
invalid record bits are enabled; previously only the
record types that had experienced bad bits were
protected. IBM's EREP writes out truncated records when
it runs out of buffer space, and sometimes EREP doesn't
edit the record and only writes out what's in the buffer,
and sometimes EREP writes out incomplete records. Also,
MCH '13'x record conditionally inputs ERRORID by testing
length in LRBMLNH to avoid STOPOVER.
Thanks to Jerry Urbaniak, Peoples Energy Corporation, USA.
Thanks to Les Geraghty, DMR (an Amdahl Corporation), IRELAND.
Change 17.360 The RMFINTRV/VMXGRMFI enhancements added in MXG 17.09
VMXGRMFI have been revised and corrected, so the errors and fixes
RMFINTRV apply only to the 17.09 code, but all of the new stuff
TRNDRMFN now works! Your existing IMACWORK member will continue
Jan 12, 2000 to work to define your workloads, if you do nothing, but
Jan 20, 2000 now you can EDIT member RMFINTRV (instead of IMACWORK) in
your USERID.SOURCLIB to create new workloads either in
addition to your IMACWORK workloads, or instead of, by
ignoring in IMACWORK completely. Member RMFINTRV invokes
%VMXGRMFI, so you EDIT RMFINTRV to change the arguments.
Remember, you NEVER change member VMXGRMFI; you only read
it for its documentation of the arguments in comments.
Then, in your RMFINTRV member, you invoke %VMXGRMFI with
your chosen workload definitions, parameters, etc.
Member RMFINTRV has documentation and examples in its
comments.
To match output to input sums exactly, all of the length
4 variables in RMFINTRV are now stored in 8 bytes. The
truncation when stored in four bytes is only in the 7th
significant digit, so using length 4 is not wrong, but
with a daily totaly of 1,000,000 seconds, that caused a
visually-obvious-even-if-not-significant difference of
0.1 of those million seconds lost between RMF & RMFINTRV.
Since I wasted a full day chasing down that difference, I
decided the small increase in DASD space would be worth
you never having to ask why there was any difference!
RMFINTRV now uses SAS VIEWS to pass data from one step to
another without using DASD space, but now, an ignorable
note "A stored DATA STEP view cannot run under a
different operating system" is printed on the SAS log.
Some additional documentation comments.
Specifying IMACWORK=NO may cause UNINITIALIZED VARIABLE
messages on the SAS log for the old variables that you
no longer want. Putting a comment block aroung the
label statement in your EXRMFINT member will eliminate
those messages, but they have no impact.
Any workload can be broken into periods, with a set of
variables for each period, including response time,
transaction count, and swap count as has always been
done for the TSO workload. You need to tell VMXGRMFI
how many periods to be mapped with the syntax:
WORKn=NNNN/LLLLLLLL/PGN/SRVCLASS/PERIODS
See PERIODS= in member VMXGRMFI.
If you specify to use Report Classes/Perfgrps, but you
also say to use your IMACWORK member, and that IMACWORK
member still contains the default to delete Report stuff
the IMACWORK will have deleted the Report stuff before
the new definitions are used. You will need to revise
your IMACWORK member to permit use of Report stuff.
Trending on the new RMFINTRV variables can now also be
done, with this new VMXGRMFI's TRENDIN=, TRENDOUT=,
TRENDBY=, and TRNDINTV= arguments, and by setting PDB=.
Member TRNDRMFN is an example of the new syntax that
will invoke VMXGRMFI to create TREND.TRNDRMFI with all
of the new workload variables.
These 17.09-only errors were corrected:
-The default IMACWORK=YES caused MXG error message that
RMFINTRV CPU TIMES DO NOT MATCH because OTHRCPU was
included twice in the creation of variable CPU72TM.
17.09 sites can remove the OTHRCPU from the end of:
,BATCPU,TSOCPU,CICSCPU,IMSCPU,OTHRCPU,
OTHRCPU is the fallthru workload for undefined PERFGRP or
SRVCLASS that were not mapped in your IMACWORK, so if all
work was mapped, then OTHRCPU will be zero and this error
does not occur.
-That error message does NOT set a return code nor stop
your BUILDPDB job (because once you see the error and
fix your workload definitions in your IMACWORK member
or in your RMFINTRV invocation of %VMXGRMFI, you can
simply re-run the RMFINTRV program to re-create the
PDB.RMFINTRV dataset, without re-reading SMF data.
-Detailed validation of 17.09 corrected values in a few
variables from TYPE71 and TYPE74 datasets.
-Using IMACWORK=NO and RPGNs did not use the RPGN data.
Thanks to Bruce Lietz, Cessna Aircraft, USA.
Thanks to Normand Poitras, ISM, CANADA.
Change 17.359 VMXGSUM fails if variable names are created in lower case
VMXGSUM and KEEPALL=NO default is used with SAS V7/V8, as that
Jan 12, 2000 space-saving option invokes logic to figure out what
variables need to be kept, and because the output dataset
created by PROC CONTENTS that contains the list of
variable names that exist has lower case values in
variable NAME, but the dataset created by parsing of the
arguments (like SUMBY=) that contains the list of
variables that are needed has upper case values in its
variable NAME, which then causes the MERGE matchup:
MERGE A (IN=INA) B (B=INB); BY NAME; IF INA AND INB;
to fail, as it sees those NAMEs as different values.
And since there is no SAS facility for case-insensitive
character tests nor case-insensitive MERGEing, three
UPCASE() functions were inserted in the three places
where variable NAME is read from the PROC CONTENTS output
dataset.
I discovered this one while creating CHANGE 17.358, and
accidentally used lower case in my test program, but it
was very nasty in impact and not obviously caused. There
was no error condition, but the output dataset had only
17 observations instead of 212; there were a few MISSING
VALUES messages on the log during MXGSUM1 creation. Only
when the SUMBY variables were printed was it found that
one of them did not exist in the output dataset, which
led to the discovery and fix.
Using argument KEEPALL=YES will circumvent this error,
because that bypasses the NAMEs matchup, but it can waste
//WORK space if there are many unused variables.
Ain't mixed case fun?????
Change 17.358 An additional sample NETSPY report that replicates the
ANALNSPY MICS SNTNSS report from MXG's NSPYLU dataset was added to
Jan 12, 2000 the examples in ANALNSPY. (However, the MICS report does
not correctly count input transactions; the MXG report
prints both the MICS number and the true number).
Thanks to Gene Rahe, Experian, USA.
Change 17.357 To modify BUILDPDB to copy CICS Statistics datasets to
EXPDBOUT your PDB, you should insert this code in EXPDBOUT:
Jan 12, 2000 _S110
Jan 20, 2000 MACRO _SCICEXC %
The BUILDPDB writes all CICS Statistics datasets to the
work file (to later create PDB.CICINTRV), but those 50+
individual CICxxxx datasets are not copied into the PDB
by default (they can be large; if you don't ask for them,
they won't waste any space in your PDB). That macro
invocation of _S110 sorts each TYPE110 dataset to the
PDB, and the two MACRO redefinitions to null out the
sorts of datasets CICSEXEC and CICSYSTM are needed
because BUILDPDB will try to sort them later in its own
logic, after the EXPDBOUT exit has been executed.
Note: if you don't want to create any observations from
the type 110 subtype 2 CICS statistics records, add this
statement: IF ID=110 AND SUBTYPE=2 THEN DELETE; in
your IMACFILE exit member.
Thanks to David Ehresman, University of Louisville, USA.
Change 17.356 Using Excluded CICS fields with CICS TS 1.3 failed,
IMACEXCL because the DO group IF MCTSSDCN LT 202 ... should have
Jan 11, 2000 been deleted when the TS 1.3 INPUT logic was copied into
member IMACEXCL. Delete that DO group.
Thanks to Tony P. Steward, Post Office, ENGLAND.
Change 17.355 Type 42 Subtype 7/8 NFS records caused INVALID NF-CL
VMAC42 SECTION TRIPLET error, but the message itself was in
Jan 11, 2000 error. The test OFFCL+LENGTH GT LENGTH should have been
OFFCL+LENGTH-1 GT LENGTH. The INPUT of SMF42CHL (twice)
was changed from &PIB.4. to &PIB.2. and SUBTYPE= was
added to those INVALID messages. Datasets TYPE42NF and
TYPE42NU were affected.
Thanks to Alan Deepe, Perot Systems Europe, ENGLAND.
Change 17.354 Summarized variable RESPSTD was always zero; the code
ASUMCICS SQRTARG=(SSQELAP/NUMTRANS)-(IRESPTM**2);
ASUMCICX must be changed to read:
Jan 11, 2000 SQRTARG=(SSQELAP/NUMTRANS)-((IRESPTM/NUMTRANS)**2);
Thanks to Normand Poitras, ISM, CANADA.
Change 17.353 Protection for the unwise. If you use the same name for
VMAC7072 a Service Class and for a Report Class, the MXG NODUP
WEEKBLD removal would not remove all duplicates. Adding variable
MONTHBLD RPRTCLAS at the end of MACRO _BTY72GO will not impact the
Jan 11, 2000 existing sorted datasets but will delete any duplicate
records in TYPE72GO.
Thanks to Chuck Hopf, MBNA, USA.
Change 17.352 Year 2000. Variable OUTDATE was still a 0cyyddd value,
VMACTMS5 having been overlooked by Change 16.330, but now it is
Jan 11, 2000 converted into a yyyyddd value.
Thanks to Freddie Arie, Texas Utilities, USA.
Change 17.351 Format MGSTCRS was corrected to 00/01 UN-/CONFIGURED.
FORMATS Labels for STC26MST/MET were changed to TAPECOPY vice
VMACSTC MIGRATE, for STC26VPO was changed to Position on the new
Jan 8, 2000 MVC, and for STC26MID was changed to VTV VOLSER.
Thanks to Herb Strazinski, US Bank, USA.
Change 17.350 SYNCSORT flag variables CONTIGn was wrong if SMFWKCID
VMACSYNC contained multiple bits, variable CACHFWn was created but
Jan 8, 2000 not kept, and two new flag variables were not decoded.
Now, CONTIGn and CACHFWn are kept and right, and two new
variables are decoded and kept:
DYNALOn = 'WORK n*DYNAMICALLY*ALLOCATED?'
UNOPENn = 'WORK n*UNOPENED*DISP=OLD?'
for n=1 to 32, for each possible Sort Work Area. Also,
the UCB address in variables UNIT1-UNIT32 is now the four
digit character address, so their stored length was
increased from $3 to $4.
Thanks to Steve Colio, CIGNA, USA.
Change 17.349 IBM Documentation of TELNET LOGF Date and Time Fields was
VMACTCP wrong, causing MXG variable TELLOGFT to be wrong.
Jan 7, 2000 Instead of being the time of logoff, the time field at
offset 82-85 is the elapsed duration of the session! And
the date field at 86-89 is redundant with the SMF date
field (and this is the date field that IBM's APAR PQ34359
plans to change from the non-standard yyyydddF format to
0cyydddF in spite of its uselessness!). Adding the
session duration and that date field created a value on
Jan 3, 2000, for a session that ended Jan 1, which made
this look like a Year 2000 problem, but it was just bad
documentation! Now, TELLOGFT is the LOGF datetime value,
new variable TELLOGON is the calculated LOGN datetime
value, and new variable TELLOGTM is the elapsed session
duration.
Thanks to Freddie Arie, Texas Utilities, USA.
Thanks to Jerome Vitner, Experian, USA.
Change 17.348 This GRAF example failed if you did not have SAS/GRAPH;
GRAFLPAR while the actual PROC GPLOTS were protected, the graph
Jan 6, 2000 control statements AXIS1, SYMBOL1, etc, were not and
caused AXIS1; to create a 180 syntax error.
Thanks to Michael E. Rounceville, Shaw Industries, USA.
Change 17.347 APAR OW42559. Variable UCCOLDT contains 1900001F for
VMACDCOL data on Jan 1, 2000, and records will be lost until the
Jan 5, 2000 end of January, 2000, according to that APAR text.
Change 17.346 INVALID DATA FOR IOSSTIME error because an additional 4
VMACICE bytes were added to the subtype 8 ICEBERG SMF record, but
Jan 5, 2000 MXG failed to protect for a change in segment size. The
correction is to insert these two lines:
SKIP=LENSEG-128;
IF SKIP GT 0 THEN INPUT +SKIP @;
immediately before this line:
_EICE8NP /*INC SOURCLIB(EXICE8NP); _WICE8NP .... */
Thanks to Jerry Urbaniak, Peoples Energy Corporation, USA.
Change 17.345 MXG 17.06-17.09 only. INVALID NUMERIC DATA CECSER=...
ASUM70PR error because MXG 17.06 added statements that used CECSER
Jan 5, 2000 as a numeric variable, but it is created as a 6-byte
character variable. The actual CPU Serial number
contained xxC4, which surfaced this error.
The test IF CECSER=. THEN CECSER=.; must be changed
to IF CECSER=' ' THEN CECSER=' '; and the
test IF CECSER=. THEN DELETE; must be changed to
IF CECSER=' ' THEN DELETE;
Thanks to Darlene Wnukowski, Schreiber Foods, Inc, USA.
Change 17.344 Year 2000. Support for ZARA Release 1.3 (INCOMPATIBLE).
VMACZARA Release 1.3 is the only Y2K Ready version of ZARA, and
Jan 5, 2000 the record format was changed to the API records, so you
will need this change to support ZARA records. In
addition to 1.3 record changes, MXG's logic for the
FILDATEX was wrong; the test FILDATEX GE 1999365 was
corrected to read:
FILDATEX EQ 1999365 OR FILDATEX EQ 1999366 OR
FILDATEX EQ 1999999)
Thanks to Norbert Ravarani, European Commission, LUXEMBURG.
Change 17.343 Variable NEXTENT, the number of extents on this volume,
ANALDSET was added to dataset DSETOPEN created by ANALDSET. The
Jan 3, 2000 DCOLLECT/TYPEDCOL is probably better for analysis of
Feb 2, 2000 dataset extents, because DCOLLECT sees all datasets on a
volume at the time DCOLLECT is run, while ANALDSET only
sees datasets that were closed in input SMF file time
interval (SMF type 14,15,64). Nevertheless, if you need
to track which job and which open is causing datasets to
extend, using this revised ANALDSET will now provide
NEXTENT for both VSAM and non-VSAM files. The structure
of ANALDSET was also revised; no longer do you need to
IEBUPDTE step to create the temporary tailoring PDS
library; the revised program now tailors instream using
%LET MACKEEP= architecture.
Feb 2: _N30, _N1415, _N64 added to null all datasets and
then define the wanted; creation of new TYPE30MR caused
the earlier revision to fail, but now its futurized.
Thanks to Tien Truong, CITICORP, SINGAPORE.
Change 17.342 Year 2000. TYPE1415 variables EXPDT and CRDATE were not
VMAC1415 converted to yyyyddd format (they were overlooked in
VMXGINIT Change 16.330) and are still in cyyddd format, so they
Dec 31, 1999 print as 100001 for 1Jan2000. This change adds in the
Jan 12, 2000 algorithm from member YEAR2000 to convert both EXPDT and
CRDATE to value 2000001 instead of 100001, and changes
their label to show YYYYDDD as their value. Member
VMXGINIT is also needed if you are still at MXG Version
16.16, or you can insert this statement:
%LET WTY1415=WORK;
as your first //SYSIN DD statement.
Thanks to Rebecca Cates, PKS Information Systems, USA.
Thanks to Frank Cortell, CSFB, USA.
Change 17.341 Year 2000. MXG created SAS date variables CREATED,
VMXGVTOF EXPIRES, and LASTUSED are wrong in Y2K in this archaic
Dec 31, 1999 VTOC reading program (which was replaced by DCOLLECT),
although the julian date variables CRDATE, EXPDT, and
LASTUSE are correct. The correct equations are:
CREATED=DATEJUL((CRCENT+19)*100000+CRDATE);
EXPIRES=DATEJUL((EXCENT+19)*100000+EXPDT);
LASTUSED=DATEJUL((LACENT+19)*100000+LASTUSE);
The incorrect equation produced dates that were either
off by one day if YEARCUTOFF=1900, or off by 36525 days
if YEARCUTOFF was 1960.
Thanks to Geoff Morley, Origin Netherlands, THE NETHERLANDS.
Change 17.340 Three cases of "$EBCDIC8 " were changed to "$EBCDIC8."
VMACOMVT
Dec 24, 1999
Thanks to Freddie Arie, Texas Utilities, USA.
======Changes thru 17.339 were in MXG 17.09 dated Dec 22, 1999======
Change 17.339 INPUT STATEMENT EXCEEDED RECORD LENGTH for EREP records
VMACEREP because the HDRIS flag bits were not being tested for all
Dec 21, 1999 record subtypes. IBM's EREP writes out truncated records
when it runs out of buffer space, it sometimes doesn't
edit the record but writes out what's in the buffer, and
writes out incomplete records, all of which are flagged
by HDRIS and BYTE0 flag bytes. MXG covered most but not
all cases, writing out an MXG WARNING that EREP had
created bad records, but now all cases are protected.
Thanks to Jerry Urbaniak, Peoples Energy Corporation, USA.
Change 17.338 -The calculation of BPHITRAT, Buffer Pool Hit Ratio, in
VMACDB2 DB2STATB dataset was revised based on Don's research: The
Dec 20, 1999 new algorithm substitutes QBSTRIO for QBSTSIO, and
restores QBSTSPP, which was removed due to negatives:
BPHITRAT=
QBSTGET-(QBSTRIO+QBSTSPP+QBSTDPP+QBSTLPP)/QBSTGET;
-QBSTSPP had been removed when MXG had negative ratios,
but it is better to use it (as it includes all prefetch
pages, regardless of whether these pages were discarded
before actually being used by the application), so that
negative values indicates a potentially serious problem
that could be overlooked without QBSTSPP: pages that are
read via prefetch, discarded before use, and then read
via synchronous sequential read. Large values in QBSTSIO
would also be true for this case, but negative BPHITRAT
would be less likely to be overlooked. Without QBSTSPP,
the equation calculated terrific buffer hit ratios that
were meaningless, since they did not consider the number
of pages that were read via normal sequential prefetch.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 17.337 -Remove TYPE79 processing, not used in IBM reports.
ANALRMFR -Remove TYPE76 processing, not used in IBM reports.
Dec 20, 1999 -New optional parameter ALLTYPE= to build TYPE70-75,
TYPE77 & TYPE78 datasets, or build only those record
types needed for the reports that are requested.
-New optional parameter DEVICEC=, allows selection of
only certain device classes for device reports.
-Update Channel Avtivity report column TYPE of channel.
Change line
IF LPARCPUS GT 0 AND LPARNAME NE 'PHYSICAL' THEN DO;
To
IF LPARCPUS GT 0 THEN DO;
Thanks to Neil Ervin, Charles Schwab & Co.
Thanks to Al Sherkow, Management Strategies, Ltd.
Thanks to Susan Walters, Michelin Tires, USA.
Change 17.336 Variables IMSVERS, IMSRELEASE, and SMBCLASS were changed
VMACITRF from character to numeric (input now with &PIB.1.) to be
Dec 20, 1999 directly readable and to now make sense!
Thanks to Warren E. Waid, JC Penny, USA.
Change 17.335 -Support for Windows 2000 Build 2195 changed field counts
EXNTACRS from the Beta 3 release, so the code was revised to read
EXNTDIST only the Build 2195 records:
EXNTIACC Memory - AVAILMEK and AVAILMEM variables added.
EXNTIACS Logical Disk - Instance Name restored (was missing).
EXNTIATC Print Queue - Instance Name restored (was missing).
EXNTIATS Web Service - SRVUPTME (service up time) added.
IMACNTSM Job Object - Instance Field added, sometimes, but
VMACNTSM data fields are accumulated.
VMXGINIT Job Object Details - Instance Fields added, sometimes.
Dec 19, 1999 Note: we're still researching why some of the Job and
Job Detail records contain no instance fields,
and NTSMF will need to be revised to deaccumulate
the Job Object counters.
-New Objects found in Build 2195:
Dataset dddddd Description
ACSRSVPS NTACRS ACS/RSVP Service
DISTRNCO NTDIST Distributed Transaction Coordinator
IASACCTC NTIACC IAS Accounting Clients
IASACCTS NTIACS IAS Accounting Server
IASAUTHC NTIATC IAS Authentication Clients
IASAUTHS NTIATS IAS Authentication Server
Thanks to Jim Quigley, Con Edison, USA.
Change 17.334 Variables PGBKSYSA PGBKLPA SHPGINAU SHPGOUAU SHPGINES
VMAC71 SHPGOUES in TYPE71 are now converted to rates per second
Dec 19, 1999 and their labels corrected, since they paging rates.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 17.333 Support for additional Landmark TMVS subtypes, including
EXTMVXC WG (Workload Manager) and XC (Coupling Facility), and
EXTMVXC1 additional fields in other records are now decoded and
EXTMVXC2 created. Test data was available, and most number have
EXTMVXC3 been verified, but there was lots of coding here!
EXTMVXC4
IMACTMV2
VMACTMV2
VMXGINIT
Dec 15, 1999
Thanks to John Jackson, Redcats, UK.
Change 17.332 INPUT STATEMENT EXCEEDED error for VSM subtype 24; the
VMACSTC input of STC24MID should have been $EBCDIC6 instead of
Dec 15, 1999 $EBCDIC8.
Dec 21, 1999 In addition, variable STC13TIM is now corrected by the
addition of DEL6070 (the delta seconds between unix's
1970 epoch and SAS's 1960 epoch - see Change 17.195),
and further protected in case STC changes that to the
TODSTAMP format in the future!
And more: All of the VSM timestamps (except SMFTIME) are
on GMT, and there is no offset provided!
And finally, just in time for the 17.09 build, the bit
test for STC11TOL had an extra 9th postition to delete.
Thanks to Herb Strazinski, US Bank, USA.
Change 17.331 Variable SMF77RF2, a second status indicator, is input to
VMAC77 match RMF report replication in member ANALRMFR.
Dec 14, 1999
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 17.330 17.05-17.08 only. STOPOVER and/or BAD RECORD messages
VMAC80A if you have installed APAR OW39128, which added RPDSNAME
Dec 13, 1999 to the WHEN (66) decoding, but I believed IBM and read in
with INPUT RPDSNAME $EBCDIC44. But actual data records
show the segment is variable length. Change the above
line to read: RPDSNAME $VARYING44. RACFDLN
Thanks to Joe Faska, Depository Trust, USA.
Change 17.329 Partition Data Report, *PHYSICAL* values zero. Change
ANALRMFR IF LPARCPUS GT 0 AND LPARNAME NE 'PHYSICAL' THEN DO;
Dec 10, 1999 to
IF LPARCPUS GT 0 THEN DO;
References to TYPE79 were removed, as it is not used in
any reports, and caused space problems if PDB=SMF was
specified.
Thanks to Neil Ervin, Charles Schwab & CO.
Thanks to Al Sherlow, Management Strategies, Ltd., USA.
Thanks to Susan Walters, Michelin Tires, USA.
Change 17.328 This utility to show the size (MegaBytes) of each data
UTILCONT set in a SAS Data Library did not have the DETAILS
Dec 10, 1999 parameter specified, and thus returned zero when run
under SAS Verson 6, 7, or 8. Now it always works.
Thanks to Jerry Urbaniak, Peoples Energy Corporation, USA.
Change 17.327 The order of the code in IMACACCT was revised, so that
IMACACCT the &MACACCT invocation now is located after the LABEL
Dec 7, 1999 statement and before the LENGTH statement, so that the
length and label of the account variables can both be
changed instream. For example, this syntax in //SYSIN:
%LET MACACCT=
%QUOTE(
DROP ACCOUNT4-ACCOUNT9 SACCT4-SACCT9
LENACCT4-LENACCT9;
LENGTH ACCOUNT3 SACCT3 $12; ) ;
will drop and change the length as indicated.
Thanks to Paul Oliver, BHP Petroleum, AUSTRALIA.
Change 17.326 Documentation only. The old //PROCLIB DD DSN=xxxxxxx
INSTALL statement was replaced some time ago by the JCLLIB
Dec 7, 1999 statement. An example of that syntax is:
//PROCLIB JCLLIB ORDER=MXG.USERID.SOURCLIB
Thanks to MP Welch, SPRINT, USA.
Change 17.325 This CICS utility to detect what PTFs are installed so
IMACPTF that you can then update member IMACPTF to tell MXG what
UTILCICS is installed has been cleaned up. The double output for
Dec 6, 1999 OMEGADLI, CANMQ, and CANWLMSC were removed, the test for
PTF UN98309 should have been for SMFPSRVR=51.0 instead of
SMFPSRVR=41.0 (and the associated comments in member
IMACPTF were corrected to 51.0), and the test for DBCTL
now tests for CMODNAME=DBCTL.
Thanks to Harry Olschewski, DeTecCSM GmbH, GERMANY.
Change 17.324 The WTIRIOTM (inter region wait time) in ASUMUOW was the
ASUMUOW sum of all of WTIRIOTM values from all transactions in
Dec 6, 1999 the unit of work, but this value is meaningless, as the
multiple waits in the TOR, AOR, etc., were summed. Now,
the WTIRIOTM in ASUMUOW is the WTIRIOTM from the first
transaction, which is also the source of IRESPTM, as this
will provide a more meaningful indication of IR wait for
the unit of work.
Thanks to Alan Meyer, Prudential-Bache Securities, USA.
Change 17.323 -This utility to understand the sequencing of CICS TOR/AOR
UTILUOW transactions now avoids all duplicates in the reports by
Dec 5, 1999 adding variables APPL5, TRAN5, ... TRAN10 to the BY list
for the PROC SORTs of datasets FIRST/MIDDLE/LAST/MOREONE,
and variable INDEX was added at the end for a better sort
sequence.
-Comments for Report 5 were enhanced, because when DBCTL
is used, there are lots of non-mirror transactions with
RTYPE=D that belong to one unit-of-work, that show up in
Report 5 and that are correct and should use case 1.
-Eliminated the first step (and IEBUPDTE to create a temp
PDS for tailoring) by using the 16.04 design to override
instream.
Thanks to Harry Olschewski, DeTecCSM GmbH, GERMANY.
Change 17.322 -Parameter SYNC59 will correct the RMFINTRV interval for
EXRMFINT sites still stuck with SYNC(59) in SMFPRMxx in PARMLIB.
RMFINTRV Because MICS originally used the end-of-interval SMFTIME
VMXGRMFI to summarize data, they required the RMF interval to be
Nov 30, 1999 at 59 minutes rather than on the exact hour. This new
Dec 21, 1999 parameter will "correct" the STARTIME in PDB.RMFINTRV
by adding one minute to STARTIME and ENDTIME so your old
13:59 to 14:59 report shows 14:00 to 15:00.
-Member IMACKEEP was only included if PDB=SMF.
-Parameter IMACWORK=NO did not function in VMXGRMFI, and
it has been corrected, redefined, and redocumented in
member VMXGRMFI. The default IMACWORK=YES causes MXG to
use definitions in member IMACWORK to create workloads in
dataset PDB.RMFINTRV in addition to any workloads that
are created in the WORKnn= parameters in your %VMXGRMFI
invocation. Now, if IMACWORK=NO is specified, not only
is the INCLUDE of IMACWORK suppressed, but also the old
MXG workload variables (BATxxxx,TSOxxxx,..,OTHnxxxx) will
NOT be created in PDB.RMFINTRV; only the workloads that
you define in your %VMXGRMFI invocation will create
workload variables (but you can still create workloads
with those old prefixes in your invocation and they will
be kept).
-Member RMFINTRV now invokes %VMXGRMFI to create the data
set PDB.RMFINTRV, using the IMACWORK definitions, to
exploit the VMXGRMFI performance enhancements (by using
VMXGSUM, especially in SAS V8, when entire data steps can
be skipped due to the new PROC MEANS INHERIT feature).
-An example of how you can invoke VMXGRMFI multiple times
to create additional "RMFINTRV" datasets that are at the
Hour (RMFINTHR), or at the Shift (RMFINTSH), etc., are in
sample VMXGRMFI invocations in member RMFINTRV.
-If you have tailored EXRMFINT to provide labels for OTHxx
variables, your definitions will be used for RMFINTRV,
but if you use VMXGRMFI to create a different dataset
name (like RMFINTHR), you will first need to change the
OUTPUT in your EXRMFINT to read OUTPUT _LRMFINT ; cause
if you don't, you'll get a 455-185 error due to your old
OUTPUT statement in your old EXRMFINT member.
Thanks to Normand Poitras, Banque Nationale du Canada, CANADA.
Change 17.321 Support for IIS Log provides event records with identity
EXIISLOG of user, IP Address, byte counts, etc. in new dataset
IMACIISL IISLOG. This support reads the #FIELDS list of fields and
TYPEIISL populates only those variables in your log records. All
VMACIISL possible IIS Log variables are kept in IISLOG dataset, so
Nov 27, 1999 compression is strongly recommended to eliminate wasted
Dec 19, 1999 space, especially since many character variables are
defined as $64, but usually contain far fewer characters.
Of course you can always use MACRO _KIISLOG to drop any
unwanted variables as well.
Thanks to Xiaobo Zhang, Insurance Services Office, USA.
Change 17.320 The logic to detect the last-complete-interval-time to
ASUMTALO control SPINTALO was imperfect, and could cause part of
Nov 24, 1999 the data for an hour to be split into two separate obs
Dec 5, 1999 in two day's separate PDB.ASUMTALO datasets. The logic
Dec 20, 1999 was revised, which required a change in the sort order of
dataset PDB.ASUMTALO to now be BY DEVICE DEVNR ALOCSTRT.
In addition, we are now using SAS Views to "pipe" data
and avoid physical writing and then reading records.
This works fine, but prints notes on the log reading:
"A stored DATA STEP view cannot run under a different
operating system.", which has no impact.
Thanks to Greg Jackson, National Life of Vermont, USA.
Change 17.319 Landmark DB2 Version 3.0 caused INPUT STATEMENT EXCEEDED
VMACTMDB error, because MXG tried to input the CF fields (starting
Nov 24, 1999 with variable DABRH) that don't exist in that version.
The INPUT statement was revised.
Thanks to Paul P. van den Brink, MeesPierson, THE NETHERLANDS.
Change 17.318 Documentation. MXGTMNT TMNT010E WRITE FAIL RC=0024 will
ASMTAPES result if you try to create SMF records with MXG's Tape
Nov 24, 1999 Mount monitor, but have excluded that SMF record number
in your SMFPRMxx member. Depending on how your SYSPROG
chose to code the TYPE/NOTYPE, etc parameters, you may
have to update SMFPRMxx before you can write the SMF
record, and you'll get one of these messages for each
tape dismount and deallocation.
Thanks to Steve Smith, BMC, USA.
Change 17.317 ABEND 2415 due to no RECFM=U in //NULLPDS DD in SAS proc,
MXGSAS and message "INVALID RECFM is DCB NOT (U|F|V)" is printed
on your SYSMSG, if your SMS ACS allocation rules for new,
Nov 23, 1999 temporary PDS libraries leaves RECFM blank, and you are
Nov 29, 1999 using MXG 17.04 or later. The permanent fix from SAS is
Jan 31, 2000 in Usage Note G645 for V6, Usage Note 1651 for V8, is to
add RECFM=U to the //NULLPDS DD statement in SAS proc.
The ABEND was precipitated by MXG 17.04, which added an
INFILE read of //SOURCLIB during initialization, but as
SOURCLIB is also in SASAUTOS, SAS opened that DD, which
concatenates the //NULLPDS DD, and SAS cannot tolerate
a blank value for RECFM when an INFILE is opened.
The MXGSAS JCL Procedure was changed, but if you use
// EXEC SAS instead of // EXEC MXGSAS, you will need to
add RECFM=U to the //NULLPDS DD in the SAS procedure.
The //NULLPDS DD statement exists in the SAS JCL proc,
but it is there only for maintenance and testing, and it
and was included in MXGSAS only for consistency. That
default was changed from only DCB=BLKSIZE=6160, to now
DCB=(RECFM=U,BLKSIZE=6160).
Adding RECFM=FB to //NULLPDS fixed the ABEND and it was
my initial circumvention, because MXG 17.04+ reads from
the //SASAUTOS DD, which points to RECFM=FB datasets.
Now, SAS Technical Support and I now agree that RECFM=U
is slightly the better choice: Both work fine now, but
NULLPDS is also used in //STEPLIB, which is read by IBM
programs, so using RECFM=U protects if a future OS/390
release decides not to tolerate RECFM=FB in STEPLIB.
Thanks to Mike Kepler, Wright State University, USA.
Thanks to Phil Wise, Wright State University, USA.
Thanks to Eladio Aviles, Arizona Public Services, USA
Change 17.316 WARNING: BIT MASK TOO LONG, TRUNCATED ON THE LEFT occurs
VMAC80A if two bytes of bits are compared with a one byte field,
Nov 23, 1999 but the warning is not detected by the compiler, and it
give no clue as to which statement is in error, which was
introduced in Change 17.094 decoding of keyword bits.
Three tests for KW08AUDT, 8 tests for KW25SPEC, and two
tests for KW25ADSP were stripped of the right eight dots.
eg, the line IF KW25ADSP='........1........'B THEN ...
now reads IF KW25ADSP='........1'B THEN ...
Thanks to Joe Faska, Depository Trust, USA.
Change 17.315 MXG 17.08 only. I introduced typos into IMS Log members
ASMIMSL6 when I updated the MXG library from the tested members,
ASMIMSL5 and one more houskeeping statement was added to TYPEIMSA:
ASMIMSLG - TYPEIMSA:
TYPEIMSA Semicolon was missing in this statement:
Nov 22, 1999 IF MTYPE EQ: 'T' THEN STRTTIME=GUTIME; /*RESET....*/
Nov 23, 1999 New statement ENDTIME=STRTTIME; was inserted after
the WSRVTS=ENDTIME-NEWSQ6; statement (line 864).
- ASMIMSL6/L5/LG: Three statements must be changed:
BNZ P301000I should be BNZ P031000I.
CLI MTYPE+3,=C'P' should be CLI MTYPE+3,C'P'
MVI MTYPE+3,=C'T' should be MVI MTYPE+3,C'T'
- ASMIMSL6:
Blank line before label P031000C must be removed.
I thought that my revisions had been re-tested before
MXG 17.08 was sent, but it is now painfully obvious that
they were not!
Thanks to Alan Green, Zurich, ENGLAND.
Change 17.314 The de-accumulation of the Web Server TYPE1032 data was
VMAC103 expanded to BY SYSTEM HOSTNAME IPADDRES PORTNUMB SMFTIME;
Nov 19, 1999 because you can have two copies of the server running in
the same host with same IP Address, differing only in the
Port Number.
Thanks to Joe Faska, Depository Trust, USA.
Change 17.313 Tests for STC11CI, STC11CE, and STC11TOL should have been
VMACSTC IF STC11xx='.......1.B THEN DO .... instead of ='01'.
Nov 17, 1999 Variables were blank without this change.
Thanks to Herb Strazinski,
Change 17.312 The _KSU70PR "Keep/Drop" macro was not referenced in the
ASUM70PR building of ASUM70PR dataset, so variables could not be
Nov 17, 1999 dropped. The token _KSU70PR was added inside the parens.
Thanks to Gary Morris, Centre Link, AUSTRALIA.
Change 17.311 If you had an old IMACPDB from before MXG 16.04, you can
SPUNJOBS get and error DATASET CONDCODE NOT FOUND. Removing your
Nov 12, 1999 old IMACPDB and instead using the new %LET ADDnn= macro
variables will correct the error, but this change also
protects by using the same logic in BUILD005 to create a
zero obs CONDCODE dataset.
Thanks to Rudolf Werner, Audi Ag, GERMANY.
Change 17.310 Input statement #25 (STIVSR36-STIVSR44) should have been
VMACCADM #25 (STIVSR37-STIVSR44).
Nov 12, 1999
Thanks to Freddie Arie, Lone Star Gas, USA.
Change 17.309 The remaining subtypes of CA-VIEW Metrics have now been
VMACSARR validated and corrected. Segment tests were change to
Nov 12, 1999 IF SV31xOF+SV31xLN-1 LE LENGTH AND SV30xLN GE 1 THEN DO;
and the input of SV30IVAL now uses SV30IVLN vice SV30INLN
to eliminate INPUT STATEMENT EXCEEDED on some subtypes.
Thanks to Bruce Sloss, PNC Bank, USA.
======Changes thru 17.308 were in MXG 17.08 dated Nov 12, 1999======
Change 17.308 Support for the SQL*NET Network Information Vector, added
VMACORAC to the Oracle user SMF record. New variables IPADDR and
Nov 12, 1999 PORTNR for TCP/IP connnections or NIVNETNM and NIVLUNAME
for SNA connnections are created and kept.
Thanks to Sudie Wulfert-Schickedanz, Anheuser-Busch, USA.
Change 17.307 Support for APAR OW41147 to recognize ORGEXPDT=0099999 as
VMACDCOL a "valid" migration date when creating variables DCDEXPDT
Nov 12, 1999 and UMEXPDT. This change (insert before ORGEXPDT=9999999
in two places the line ORGEXPDT=99999 OR ) corrects
SAS dates to be "MXG infinite" date in 2099 instead of to
be missing in DCDEXPDT or UMEXPDT. However, the variable
ORGEXPDT is unchanged, so you can use your current MXG to
examine your DCOLLECT datasets DCOLDSET and DCOLMIGS, and
if you have any datasets with ORGEXPDT=99999, then you
MUST either install that APAR or follow its instructions
to prevent unexpected loss of any SMS dataset with its
ORGEXPDT=99000 on Jan 1, 2000. What is critical is that
you read the APAR and see if it has impact on our site.
This MXG change is not required for year 2000 support in
MXG Software.
Change 17.306 Support for CA VIEW Metrics report program SARSMFUX SMF
EXSARR20 records create seven datasets:
EXSARR21 Dataset Label
EXSARR30 SARRU20 User Logon
EXSARR31 SARRU21 User Logoff
EXSARR32 SARRU30 Report was viewed
EXSARR33 SARRU31 Report was reprinted
EXSARR34 SARRU32 Report was loaded to database
TYPESARR SARRU33 Report was deleted
TYPSSARR SARR&34 Report was deleted from disk
VMACSARR
Nov 11, 1999
Thanks to Bruce Sloos, PNC Bank, USA.
Change 17.305 Support for RACF General Resources Started Task subtype
EXRAC540 540 in RACF Database Unload Utility IRRDBU00 file.
IMACRACF
VMACRACF
Nov 11, 1999
Thanks to Randy Shumate, LEXIS-NEXIS, USA.
Change 17.304 Counts could be negative in TYPE1032 Web Server dataset,
TYPE103 because the accumulated counters are reset each time the
TYPS103 server is "bounced". Now, MXG interleaves the subtype 1
VMAC103 (start) and 2 (interval) records to eliminate negative
Nov 11, 1999 values. Additional protection prevents negative values
if a subtype 2 is read before a subtype 1, or if data
records were lost, for the first subsequent record.
Member TYPE103 or TYPS103 both now invoke the DIFF103
member to sort both TYPE1031 and TYPE1032 datasets.
(So the //PDB ddname is required for TYPE or TYPS103).
Thanks to Joe Faska, Depository Trust, USA.
Change 17.303 IMF DB2 counts are lost in datasets CIMSTRAN and CIMSDB2
VMACCIMS in MVIMF 3.2, because BMC enabled IOWAITS by default,
Nov 11, 1999 which puts some SQLCALLS in a new, undocumented DBORG=00x
Nov 19, 1999 DBD segment, instead of the documented DBORG='80'X DBD.
Sep 15, 2000 IOWAITS is the MVIMF Event Collector DBIO initialization
parameter, and the new 00x segment accounts for sync
point write activity and is also flagged by the
PLANNAME='ALLDBS'. MXG previously only knew about the
80x DBD, so the new 00x segments were decoded incorrectly
and output to the CIMSDBDS instead of CIMSDB2. And while
MVIMF documentation said there would be only one '80'x
segment, logic was added to sum SQLCALLS for these
multiple segments into CIMSTRAN. The drop in SQLCALLS
coincided with installing IMF 3.2.61.
This change was not correct. See Change 18.225.
Thanks to Winfried Waldeyer, BHF Bank, GERMANY.
Change 17.302 Format $MG074PT expected 'F1'X or 'F3'X, but actual data
FORMATS values are '01'X or '03'X, so the format now supports
Nov 11, 1999 both formats, just in case.
Thanks to Alan M. Sherkow, I/S Management Strategies, Ltd., USA.
======Changes thru 17.301 were in MXG 17.08 dated Nov 10, 1999======
Change 17.301 Variable DURATM was not created in PDB.CICS built with
ASUMCICX member ASUMCICX. Insert DURATM=INTERVAL, before the
Nov 10, 1999 INTERVAL=HOUR, macro argument.
Thanks to Alan Deepe, Perot Systems Europe, ENGLAND.
Change 17.300 If DB2 stays up long enough, and does enough SELECTs, the
ANALDB2R four-byte accumulated counter in the type 100 SMF records
VMACDB2 can wrap, causing MXG to create a negative value when it
Nov 10, 1999 DIF()'d the adjacent observations. Now, each DIF() is
followed by a test for four-byte wrapping of the form:
IF . LT Qxxxxxxx LT 0 THEN Qxxxxxxx=Qxxxxxxx+4294967296;
in member VMACDB2 (the "DIFFDB2" logic was relocated into
the _SDB2xxx sort macros in MXG 16.04 redesign). Also,
several fields in MXG's ANALDB2R reports were not wide
enough for large values, causing SAS to print exponential
notation (valid, but confusing to neophytes), so they are
now expanded along with other minor report revisions.
Thanks to Victor Chacon, Bell Atlantic Mobile, USA.
Change 17.299 MXG Variable CECSER is created by substringing the last
VMAC7072 four nybbles of the three byte CPUSER to get the hardware
Nov 9, 1999 serial number of the "CEC" or "CPC", (i.e., the box), but
Nov 10, 1999 CPU segments have been found with 'E03333'X instead of a
valid CPU Serial Number. These segments are all flagged
for an engine "not online at the end of the interval", or
"came online during the interval", and the CPUSER is not
valid in those instances. So now, MXG sets CECSER only
IF CECSER GT '000000'X AND CAI EQ '......01'B THEN ...
so that only CPUs that were online at the end of the
interval and had not come online during the interval
will be used to set the CECSER. Note, however, that
CPUSERnn (CPUSER stored into a serial number for each
CPU) will still contain whatever CPUSER value was in
its CPU segment if CAI had any bits turned on.
Thanks to Linda S. Berkley, Amdahl, USA.
Change 17.298 Batch Pipes datasets TYPE9112, TYPE9113, and TYPE9115 now
FORMATS contain the Input and Output counts summed from all of
VMAC91 the IEC and OEC connection segments for the End, Close,
Nov 9, 1999 or Delete events, and the Highest Error Code from those
Nov 27, 1999 connection segments. Format $MG091EC was also updated.
Nov 27: additional formats added to $MG091EC.
Thanks to Michael Oujesky, MBNA Hallmark Information Services, USA.
Change 17.297 Support for unix PerfMeter Freeware Monitor that creates
EXTYPMTR interval resource data on CPU, PKTS, PAGE, SWAP, INTR,
IMACPMTR DISK, CNTXT, LOAD, COLLS, and ERRS rates in new dataset
TYPEPMTR PERFMETR. This monitor is free from Sun MicroSystems,
TYPEPMTR for their unix.
VMACPMTR
VMXGINIT
Nov 8, 1999
Thanks to Michael Lefkofsky, Wayne State University, USA.
Change 17.296 The de-accumulation logic in DIFFTPX caused NOT FOUND as
DIFFTPX was not updated; now it has only _STPXINT invocation, as
Nov 8, 1999 deaccum is now done in the data set sort macro.
Thanks to Mike Shapland, PKS Information Services, Inc.
Change 17.295 The creation of ZDATE in this VMAC member was replaced by
VMACCTLT %%INCLUDE SOURCLIB(IMACZDAT); to be consistent with the
Nov 8, 1999 rest of MXG VMACs. The ommission was an oversight.
Thanks to Steve Clark, California Federal Bank, USA.
Change 17.294 MXG 17.06 added macro _CICXC13 to support excluded fields
IMACEXCL for CICS/TS 1.3, but the "END; /* END CICS TS 1.3 ..."
Nov 8, 1999 line number 547, must be deleted to use the 1.3 Excludes.
Thanks to Alan Deepe, Perot Systems Europe, ENGLAND.
Change 17.293 TYPEIMSA did not include member IMACKEEP; now it does.
TYPEIMSA This should have been included in Change 17.228 but was
Nov 8, 1999 overlooked.
Thanks to Gilles Fontanini, SAS Institute, FRANCE.
Change 17.292 Variable SMF6DDNM contains hex zeros for DDNAME in some
IMAC6ESS type 6 SMF records (perhaps spin data sets?), but the ESS
VMAC6 segment appears to have the DDNAME in the SWBTU text, so
Nov 5, 1999 this change inputs new variable SMF6TUDD from ESS segment
and stores SMF6TUDD into SMF6DDNM if SMF6DDNM is blank or
nulls. I'm still seeking the DSECTS for the SWBTU, and
the ESS segment itself is incorrectly documented in the
SMF manual and the DSECT, to make sure this is permanent.
Thanks to Hartmut Richter, BASF Computer Services GmbH, GERMANY.
Change 17.291 -Variable PERFINDX in dataset TYPE72GO was non-zero when
EXTY72DL it should have been missing for Service Classes with a
EXTY72GO Percentage goal. MXG calculated PERFINDX even when there
VMAC7072 were no transactions completed in the interval. Now, the
Nov 5, 1999 statement ELSE IF R723CRGF='P' THEN DO; was changed to
read ELSE IF R723CRGF='P' AND TRANS GT 0 THEN DO; so that
PERFINDX will be missing when TRANS=0. Additionally,
PERFINDX was not reinitialized for each Period, and thus
it could have been carried forward as non-zero when it
should have been missing. However, PERFINDX will always
be missing in Reporting Class (RPRTCLAS='Y') observations
and in observations for Service Classes that have System
or Discretionary Goals (R723CRGF='S' or 'D'). PERFINDX
will also be missing if the percent of transactions that
meet the goal falls into the 14th (last) bucket, which
make it impossible to calculate the PERFINDX. On RMF
reports, IBM prints four asterisk for the index; you
can recognize these cases in MXG because R732CRGF='P',
PERFINDX=., but TRANS or TRANSEXC will be non-zero.
-Observations were output in TYPE72GO for Service Classes
that had no resources nor transaction completions. The
variable NOACTVTY was non-zero (indicating activity) when
it should have been zero. Logic in VMAC7072 was revised
so R723RESS (trans states sampled) is no longer included
in NOACTVTY, and VELOCITY and PERFINDX are initialized
for each period (they were propagated into subsequent
periods in the same record that had no activity), and the
logic in EXTY72GO now tests only
IF NOACTVTY GT 0 THEN OUTPUT _WTY72GO;
-Observations were also output in TYPE72DL where there
were no delay samples. Now, EXTY72GO was revised so that
observations are only output in TYPE72DL when R723RESS is
non zero (i.e., there were transaction states sampled).
Thanks to Tan York Sin, Stock Exchange of Singapore, SINGAPORE.
Change 17.290 MXG 17.07 IMS code still had negative RESPNSTM/SERVICETM
ASMIMSLG in 5704 (out of 130000) IMS transactions. Data records
ASMIMSL5 for this (yet another!) unique sequence of IMS log events
ASMIMSL6 plus lots of detailed digging thru mounds of data allowed
JCLIMSLG Carl to enhance MXG for these new IMS idiosyncrasies:
JCLIMSL5 1. TYPEIMSA corrected 5411 of the negative cases, which
JCLIMSL6 included all of the negative RESPNSTM values. Logic
TYPEIMSA added protects when ENDTIME is less than GUTIME. This
Nov 10, 1999 left 293 transactions with negative SERVICTM.
2. ASMIMSLx assembly program revision protects cases when
IMS rerouting exits change destinations causing the
IMS communications manager to do the get unique of a
message that was originally destined to an SMB. The
change sets MTYPE='PTOT' for messages GU'd by comm.
So you must re-assemble the ASMIMSLG/L5/L6 program for
your version of IMS to correct this problem, which
corrected 291 cases of negative SERVICETM.
3. TYPEIMSA corrected the remaining two cases of negative
SERVICETM was to change the reset of STRTTIME=GUTIME
for all transactions, to use that reset only for MTYPE
starts with T, and otherwise reset STRTTIME=ENQTIME
for cases such as MTYPE='PTOT' in which the GU happens
ascynchronous to the end of the transaction.
4. The SORT statement in STEP02 of the JCL examples needs
to be changed. The "35,8" entry, for the message
arrival time, is changed to "43,8" so that the enq
timestamp is used to force the records in absolute
order (because the arrival timestamp can be zero, as
for 03 output record messages for PTOT transactions).
In summary, you need to reassemble ASMIMSLx, use the new
TYPEIMSA, and change the SORT parameter in your JCL.
The cause of the 291 negatives is documented in IBM APAR
PQ01976; they result when the site uses the IMS Input
Message Routing Exit, DFSNPRT0, to reroute a message that
was originally destined to an SMB instead to a CNT. In
this case, a multisegment IMS log 03 record has MSGDFLG2
indicating a program-to-program message switch ('81'X),
but the Exit changed the destination from another SMB to
the CNT of an IBM 3614 cash dispensing ATM terminal, so
the message is picked up by the IMS communications
manager instead of by DLI, so the get unique from the
message queue for that message is represented by a type
31 record that has a QLGUFLGS ('A0'X), indicating it's
pretty much just a normal output message, but the
resultant mismatch in log coding created a transaction
record with negative value for SERVICTM variables in
IMSTRAN. The PTF associated with IBM APAR PQ01976 does
NOT correct the log records; it only prevented IBM's
merge utility DFSLTMG0 from ABENDing (as it did when it
first saw this sequence of IMS log records!).
Thanks to Carl Meredith, SAS Institute ITSV Development, USA.
Change 17.289 Labels for several sets of TYPE71 variables AV/MN/MX
VMAC71 suffixed, now contain "*USED", to clarify which are the
Nov 3, 1999 usage measures and which are capacity measures.
Thanks to Forrest Nielson, State of Utah, USA.
Change 17.288 Variable TOTSHARE was removed from the DROP statement so
ASUM70PR it will be kept, as it may be useful to recalculate the
Nov 3, 1999 original system weights.
Thanks to Chuck Hopf, MBNA, USA.
Change 17.287 Revised Support for SMF Type 90, TYPE90A/VMAC90A should
EXTY9001 be used instead of the old TYPE90/VMAC90 members, which
EXTY9003 will no longer be updated. That old architecture kept
EXTY9004 all variables from subtypes 1-26 in the TYPE90 dataset,
EXTY9005 which not only wastes DASD space, but always requires a
EXTY9006 subset operation to select the observations you want.
EXTY9008 The TYPE90 code was the first written when subtypes were
EXTY9010 added to SMF records, and when there were only a few and
EXTY9011 they were similar in content, it made sense to create one
EXTY9012 TYPE90 dataset, and when new subtypes were added it was
EXTY9014 easier to add variables to an existing data set than to
EXTY9016 create a new data set, but now with 31 often-dissimilar
EXTY9017 subtypes, this "redesign with hindsight" is the righteous
EXTY9018 way it should have been done in the first place, as it
EXTY9019 creates 26 separate datasets, TYPE9001-TYPE9031, one for
EXTY90.. each of the operator commmand events, with only variables
EXTY90.. from that event kept in that TYPE90nn dataset. There was
EXTY9030 no complaint with the old design, since everything that
EXTY9031 was supported was in the old TYPE90 dataset, but the need
IMAC90A to support the new subtypes (27 and above, plus some that
TYPE90A per previously missed) motivated the redesing. Now all
TYPS90A subtypes are decoded, except for data segments of subtype
VMAC90A 24 and 31 (no request, no test data, complicated, shelve
Nov 3, 1999 until someone want's to us them).
Thanks to Philip Foster, Desjardins, CANADA.
Change 17.286 MXG Support for FICON Channels was wrong. Variables
VMAC73 PCHANBY/PNCHANBY were incorrectly calculated for FICON,
Nov 2, 1999 and Percent Bus Busy, PBUSBY was not even created, and
variables SMF73PRU/PWU/TRU/TWU are recalculated to now
contain read/write lpar/total rates in bytes per second,
formatted with MGBYTRT to print KB/Sec, MB/Sec, etc, to
match IBM RMF reports, now that I have test data and RMF
reports for validation!
Thanks to Joseph Rannazzisi, Salomon Smith Barney, USA.
Change 17.285 New NPM 2.4 field LSCDIPNM (IP Name) was input for all
VMAC28 records but is valid only if resource type is 'IP', so
Nov 1, 1999 that field will now be blank if not an 'IP' record.
Variable LSCDUSER is blank if LENCOF is 112, which is the
documented length for VM Session Configuration (SMF28SCD)
records, and other LSCDxxxx fields are only input if the
record is for Session Managers.
Thanks to Robert A. Brown, Arthur Andersen, USA.
Change 17.284 Support for TRMS Version 51A08 changes (COMPATIBLE) to
EXTRMS05 their user SMF record. New fields were added to subtype
VMACTRMS 3 and 4 datasets TMRS03 and TMRS04, and new subtype 5
VMXGINIT record creates new dataset TMRS05, 'Browse Tracking'.
Oct 28, 1999 The S0nACCT character variables are now formatted as
$HEX64, because the contain non-printable characters.
The length of new fields S05KEY is not defined in the
dsect, but was found to be 14 bytes in this site's data
record. It's length, T00KLEN is set somewhere else and
could be different; we're investigating.
Thanks to Carol King-Baer, Vanderbuilt University, USA.
Change 17.283 Format $MG091EC now decodes Batch Pipes error codes in
FORMATS variables SMF91IEC and SMF91OEC.
VMAC91
Oct 28, 1999
Thanks to Michael Oujesky, MBNA Hallmark Information Services, USA.
Change 17.282 Protection for bad type 80 record was not robust if MXG
VMAC80A got out of alignment and thought it had a bad record; it
Oct 27, 1999 could STOPOVER abend instead of gracefully deleting that
bad record, but protection logic from WHEN (00) was also
added in OTHERWISE DO; logic to eliminate the abend.
Thanks to Jens Schlatter, Independent Consultant, GERMANY.
Change 17.281 Support for DFSMS/MVS V1R5 is already in place, as there
VMACDCOL were no changes in the DCOLLECT records in 1.5.
Oct 26, 1999
Change 17.280 Support for Landmark DB2 Monitor Version 3.2 (INCOMPAT).
EXTMDD7 Many new variables were added to existing MXG datasets
EXTMDD7B TMDBDB, TMDBDA2, TMDBDAB, TMDBDBB, TMDBDBF, TMDBDBK and
EXTMDD7P TMDBDE2, and TMDBD6, and the new 'D7' record creates new
VMACTMDB TMDBD7, TMDBD7B, and TMDBD7P datasets. This version has
VMXGINIT lots of new stuff, including pairs of duration/counts of
Oct 26, 1999 many waiting-for-something's. Since Landmark inserted
new fields instead of adding at the end, you must install
the change to process Version 3.2 or higher data. Using
an earlier MXG version for TMDB Version 3.2 records will
cause the job to fail with many errors!
Thanks to John Enevoldson, Ellos AB, SWEDEN.
Change 17.279 CICS Statistics "EOD" records do not contain a duration,
UCICSCNT even though the "EOD" records is just the Interval Record
VMAC110 since the last "INT" record. (The "EOD" is written at EOD
Oct 24, 1999 but DOES NOT contain the entire day's data!). With no
Oct 27, 1999 DURATM, MXG sets STARTIME=COLLTIME (SMFTIME), so while
all of the obs are really there in the MXG data set, it
looks like the 9pm interval was missed with STARTIME:
STARTIME COLLTIME SMFSTRQT
31OCT:15:00 31OCT:18:00 INT
31OCT:18:00 31OCT:21:00 INT
1NOV:00:00 1NOV:00:00 EOD
1NOV:00:00 1NOV:03:00 INT
While STARTIME is wrongly equal to COLLTIME in the "EOD"
interval record in CICxxxxx Statistics datasets built by
the TYPE110/BUILDPDB programs, STARTIME is set correctly
in the PDB.CICINTRV dataset that is created from nineteen
of the "raw" CICS Stat datasets by the member CICINTRV:
-It constructs true intervals from INT/EOD/USS/REQ/RRQ
records, some of which are intervals and some of which
are accumulated, and by sorting and merging, it creates
the correct STARTIME of each interval.
-Fifteen CICS statistics datasets that are used in the
creation of PDB.CICINTRV are created one-per-interval,
so they are merged into PDB.CICINTRV with no loss of
detail; thus there should be no need to use these "raw"
CICxxx datasets with wrong STARTIME in their EOD record
because they are redundant with PDB.CICINTRV:
CICAUTO CICDMG CICDQG CICDS CICDTB CICLDG
CICM CICSDG CICST CICTC CICTDG CICTM
CICTSQ CICVT CICXMR
-Four CICS statistics datasets used in the creation of
PDB.CICINTRV have multiple observations per interval
CICDQR CICFCR CICTCR CICTSR
(i.e., CICFCR has an observation for each File). Some
useful counters are summed per interval and merged in
PDB.CICINTRV, but detail observations are likely needed
to be kept in your PDB, and you will have to live with
the incorrect STARTIME in the EOD obs.
So why not fix IBM's ommission (which was designed this
way and not likely to change)? Because the only way to
correct it would be to add a PROC SORT and DATA step for
each stat dataset to re-construct the correct STARTIME,
and that seems an unnecessary expense at this time.
However, the architecture of each _Sdddddd macro would
make this possible, so if this remains a problem for you,
let's discuss this as a future enhancement.
The initial "Missing 9pm Interval" report was thought to
be a real data loss, but that possibility was eliminated
when there were no messages that CICS had suspended write
to SMF. But to re-document what might happen:
When CICS cannot send data to the SMF address space, you
get "DFHMN0101 CICS COPYNAME SMF RC '0028'X" or
"DFHST0103 CICS COPYNAME SMF RC '0028'X" messages
on both SYSLOG and the JOBLOG of that CICS region. The
MN message says CICSTRAN (subtype 1) records were lost,
the ST message is for Statistics (subtype 2) records.
This happens briefly when SMF Buffers are being expanded
or when SMF SWITCH occurs (because both are serialized
functions under the single SMF TCB). By scheduling the
SMF dump/SWITCH away from the interval pop, its impact
may be eliminated. By increasing the size of your SMF
buffers with APAR OW12836 (increases minimum from 1MB
to 8MB, which might eliminate the need for expansion;
increases the maximum from 32MB to 128MB; and increases
each increment from 1MB to 8MB so there are fewer buffer
expansions and fewer exposures to data loss) you may be
lucky and avoid the problem, until IBM responds to the
SHARE requirement to fix this design!
The only code change was an enhancement to the UCICSCNT
program that counts CICS records by APPLID and type; a
new reports details Statistics counts by STID and record
so I could tell if stat data really was lost!
Thanks to David Lyle, Total System Services, USA.
Change 17.278 Support for APAR OW40570/OW41407 for SMF 42 Subtype 4
VMAC42 adds S42CVLUX to contain the 4-digit UCB address in MXG
Oct 22, 1999 dataset TYPE42CV. The existing 3-digit S42CVLUA variable
contains 'UCB' for any 4-digit UCB address!
Change 17.277 Documentation only, no code was changed. TYPE94 data
VMAC94 fields VMV/VPS/VPM/VPR/VMP/VBW/VBR/VTW/VTR will be zero,
Oct 22, 1999 and fields VBA/VEC/VLA/VNM/VCA/VCZ will stop accumulate,
if the screen on the PC that is attached to the VTS/ATL
and that is collecting those physical back end activity
counters is minimized! Discussions with IBM in progress.
Change 17.276 New Format $MGTCPFM decodes the FTPDATFM data format
FORMATS variable (ASCII/EBCDIC/IMAGE/DOUBLE-BYTE/UCS-2) values.
VMACTCP Variable FTPDSNA2 is no longer kept in TYPETCPC dataset
Oct 22, 1999 (FTP Client), as that field exists only in TYPETCPF
(FTP Server), and was filled with hex trash.
Thanks to Jason Cooley, CITICORP, USA.
Change 17.275 Reading type 39 SMF records directly from VSAM SMF file
VMAC39 failed because the calculation of offset for two optional
Oct 21, 1999 triplets did not include (+OFFSMF).
Thanks to Bruce Hudson, Payless Cashways, USA.
Change 17.274 The symbolic &TAILOR and its //TAILOR DD were removed
JCLTEST6 from the MXGSAS example JCL procedure, because in a few
MXGSAS sites either SAS 180 errors or USER ABEND 2415 occurred
Oct 20, 1999 due to (strange?) problems, and so I've decided that the
optional tailoring library is more pain than value, as
no one really used it anyhow!
Thanks to Richard Phelps, Arizona State University, USA.
Change 17.273 The estimated length of tape, DSNBFEET and TAPEFEET, was
TYPETMS5 non-zero when BLKSIZE=0 because the two calculations in
Oct 20, 1999 TYPETMS5 did not match the logic in VMACTMS5, so tests
for BLKCNT GT 0 and BLKSIZE GT 0 AND RECFM conditions
in VMACTMS5 were added to calculations in TYPETMS5.
Thanks to Pat Moffett, CMX Group, USA.
Thanks to Patsy Hildreth, CMX Group, USA.
Change 17.272 Calculation of variable OVRSPPC6 incorrectly used the
VMACNSPY 3270 buckets instead of the LU6.2 buckets. It should be:
Oct 20, 1999 OVRSPPC6=100-T1RSPPC6-T2RSPPC6-T3RSPPC6-T4RSPP6;
Thanks to Julian Smailes, Experian Limited (UK), ENGLAND.
Change 17.271 This utility was developed to show you how your IMACWORK
UTILRMFI definitions cluster PERFGRP or SRVCLASS into the workload
Oct 18, 1999 variables in RMFINTRV dataset. It shows where the type72
CPU times came from, using your IMACWORK, and it also
reads type 30s to show SRVCLASS/RPTCLASS/JOB CPU times.
The utility is needed when your RMFINTRV execution prints
error messages that your workload definition CPU time
does not match the true CPU time in SRVCLASS/PERFGRPS.
Thanks to Chuck Hopf, MBNA, USA.
Change 17.270 Support for APAR PQ28258 for the SMF type 103 record that
VMAC103 was created by Internet Connection Secure Server (R3,R2)
Oct 18, 1999 and then by Lotus Domino Go Webserver for OS/390 (R4-R6),
May 31, 2000 now named WebSphere Application Server OS/390 (R7-R8),
(and now May, 2000 sub-titled HTTP Server Version 5.2),
adds many new statistics, including five sets of avg/min
max response times for DNS, Plugins, CGI, SSL, & Proxy,
to subtype=2 record in dataset TYPE1032.
Change 17.269 Long ago, when I observed that the total device pending
VMAC74 time (PCTDVPND) was more than the sum of its two parts,
Oct 18, 1999 Pend for Device (PCTPNDEV) plus Pend for CU (PCTPNCUB),
Dec 16, 1999 I stored the difference as the Pend for Chan (PCTPNCHA).
But when IBM added Pend for Director Port (PCTPNDIR), I
did not treat that as a component of PCTPNCHA, and now I
measure there still is a difference between the Total and
its components, so I now:
- Store Pend Dir Port into PCTPNCHA/DLYCHATM variables
and changed their labels to be Chan Dir Port delay
- Calculate the Other Pending PCTPNOTH/DLYOTHTM as
PCTPNOTH = PCTDVPND - (PCTPNDEV+PCTPNCUB+ PCTPNDIR)
Other Pend = Total - (Device + CU + Dir Port)
Independent of this change, type 74 data records with
Total Pend Time (SMF70PND) of 28 seconds but Pending for
Device component (SMF70DVB) was 37 seconds are written
occasionally for devices simulated in an EMC box. The
error causes PCTPNOTH to be negative (and, before this
change, PCTPNCHA was also negative because it used to
be the same as PCTPNOTH). We have also seen similar, but
much smaller differences, for tape devices.
Thanks to Robert Girard, EMC, USA.
Change 17.268 Variables UBCOMPR UBUSRSIZ UBCMPSIZ were INPUT but were
VMACDCOL not in the KEEP= list for dataset DCOLBKUP. Now they are.
Oct 18, 1999
Thanks to Alastair Gray, Philip Morris EDC, SWITZERLAND.
Change 17.267 The VTS report program was corrected; while its example
ANAL94 in comments worked fine, invoking %ANAL94(PDB=SMF); to
Oct 13, 1999 read SMF to produce reports did not produce! Parameter
REPORT=HOURLY is now the default, so that a report will
now always be produced, plus other cleanup.
Change 17.266 The "GT" was changed to "GE" so all lines now read
VMACHARB IF HH GE 0 AND MM GE 0 AND SS GE 0 THEN ....
Oct 11, 1999 because the "GT" caused some missing timestamps.
Nine flags, AXR0nFL1, are now formatted $HEX2.
Thanks to Patsy Hildreth, CMX Group, USA.
Change 17.265 The VMXGSUM error in Change 17.264 is corrected, by
VMXGSUM relocating the ALLVARS initialization higher up in the
Oct 11, 1999 logic; it was bypassed when INCODE= was not used, and
was blank when it should have had a list of variables.
When &ALLVARS was blank, VMXGSUM generated code was
PROC MEANS; VAR ; OUTPUT OUT=X SUM(A B C);
(i.e., a VARIABLES statement with no variables).
This PROC MEANS failed "NO ANALYSIS VARIABLES" with
SAS V6, but under SAS Version 8, it ran just fine!
Exactly why is under investigation; but I think it is
enhancements SAS made under SAS V8: in this specific
PROC MEANS invocation, a VAR statement is not needed
because the SUM(A,B,C) syntax provides the names, so
SAS V8 ignored the unneeded VAR statement?
In any event, VMXGSUM now always populates ALLVAR with
the list of variables so it won't be blank.
======Changes thru 17.264 were in MXG 17.07 dated Oct 8, 1999======
Change 17.264 The VMXGSUM of Change 17.255 was never put in MXG 17.07,
VMXGSUM because it was not correct. MXG QA under SAS V8 had no
XMXGSUM errors, so 17.07 was built, but final QA with SAS V6
Oct 8, 1999 found errors in VMXGSUM that were not caught by V8, so I
removed VMXGSUM for the MXG 17.07. Note that 17.255 was
reinstated by Change 17.265 in MXG 17.08.
Change 17.263 Support for Domino Server SMF type 108 record creates
EXTY1081 three new datasets from subtype 1 interval records:
EXTY108P Dataset Description
EXTY108T TYPE1081 Server Statistics
IMAC108 TYPE108P Port Statistics
TYPE108 TYPE108T Transaction Statistics
TYPS108 Additional development work is ongoing by IBM so you can
VMAC108 anticipate additional measurements for Domino soon.
Oct 8, 1999 Domino Release R5.0 & R5.01 are supported by this change.
The type 108 record originated with Lotus Notes Domino
Server, and was primarily a mail server for Lotus Notes,
but now the Lotus Domino Server provides services for
Notes, and contains its own HTTP server & JAVA function.
Note that the Websphere Application Server HTTP Server
is the product that creates the SMF 103 record.
Thanks to John Milne, Suncorp Metway, AUSTRALIA.
Change 17.262 Revisions in DAILYDSN to use TYPSDCOL instead of TYPEDCOL
DAILYDSN (so the PROC SORT and NODUP logic would be taken from the
Oct 8, 1999 VMACDCOL instead of being coded in DAILYDSN) wrote the
output to the //PDB instead of the expected //DATASETS.
By inserting %VMXGINIT(DEFAULT=DATASETS); before the
include of TYPSDCOL, the default PDB becomes DATASETS and
DAILYDSN now works as it did previously.
Thanks to Craig Gifford, City of Lincoln, USA.
======Changes thru 17.261 were in MXG 17.07 dated Oct 7, 1999======
Change 17.261 Unexpected Expiration date of 2099366 (also invalid, as
VMACDCOL 2099 is not a leap year) was found, and caused missing
Oct 7, 1999 value for DCDEXPDT/UMEXPDT. The logic was revised to add
test (YREXPDT=199 AND DAYEXPDT GE 365) OR in two places
so that the '31DEC2099' infinite MXG date is stored in
DCDEXPDT or UMEXPDT.
Thanks to Jens Mohring, HUK Coburg, GERMANY.
Thanks to Harald Seifert, HUK Coburg, GERMANY.
Change 17.260 NTSMF SQLServer Objects Cache Manager, Databases, Locks,
VMACNTSM and User Settable were corrected (NRNAMES and/or NRDATA,
Oct 5, 1999 and NRNAMES=NRNAMES-1 was added) and validated with data.
Thanks to Leigh Ann Payne, Wachovia Operational Services, USA.
Change 17.259 Landmark PTF TD01655 for TMON Version 2 added fields
VMACTMV2 COMPATIBLY to the CI and JD records:
Oct 5, 1999 -Variables CICSALUB,CIECSLUB added to TMVSCI dataset.
-Variables (enclave CPU times)
JDDECPU JDENCSU JDENCTR1 JDENCTR2 JDIECPU JDJDECPU
JDJENCSU JDJIECPU JDSDECPU JDSENCSU JDSIECPU JDSWPRSN
were added to TMVSJD dataset.
-Variables
JDOPRID JDOSTCK
were added to TMVSJDOM dataset.
Thanks to ???, IDUNA NOVA, ITALY.
Change 17.258 The trending of ASUMUOW into TRNDUOW failed with error
TRNDUOW TREND.TRNDUOW.DATA DOES NOT EXIST because the statement
Oct 4, 1999 OPTIONS NODSNFERR; should have been at the start of the
TRNDUOW member. "No DSN Not Found" option protects the
first-time execution of TRND members, but was left out of
the TRNDUOW member.
Thanks to Tom Marchant, Wayne State University, USA.
Change 17.257 Variable SMF26WIN, a bit map, is now formatted $HEX2.
VMAC26J2
Oct 4, 1999
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 17.256 This revision, used by UTILGETM, allows you to read an
VMXGGETM SMF file and report on the contents by type, subtype, and
Oct 4, 1999 system, using PROC TABULATE. If you specify SMFOUT= a
null string, and specify FREQ=YES, the report is created.
Thanks to Chuck Hopf, MBNA, USA.
Change 17.255 This revision adds new statistics (notably percentiles)
VMXGSUM in VMXGSUM output, and detects execution under SAS V7/V8
Oct 6, 1999 so that the new INHERIT parameter in PROC MEANS can be
used, which may eliminate the need for the final datastep
(previously required to reset variable lengths).
Thanks to Chuck Hopf, MBNA, USA.
Change 17.254 A number of new timestamp fields from DB2 and CICS were
IMACNORM added to the PDB.ASUMOW dataset. In addition, new member
ASUMUOW IMACNORM is added to permit you to normalize the CPU time
Oct 3, 1999 created in the PDB.ASUMUOW dataset, in case you have CICS
Regions and/or DB2 Subsystems executing in machines of
different speeds. IMACNORM is preliminary, and may be
changed in the future, but it has no impact unless you
change it, as IMACNORM now only contains commments.
Thanks to Chuck Hopf, MBNA, USA.
Change 17.253 -MXG options SASCHRLN is implemented to save space in some
VMAC102 DB2 trace records that contain variable length text. See
Oct 3, 1999 Change 17.251 text. Both COMPRESS=YES and execution with
SAS V7, V8, or later is required.
-For trace subtypes 206, 208, and 236, if the message text
was greater than 200 bytes, the first 200 bytes were not
input, but now are. The first INPUT of QW0207HR was
removed, as the second one, inside the test for length,
was the correct one.
See minor revision in Change 17.390.
Thanks to Chuck Hopf, MBNA, USA.
Change 17.252 This analysis of all SAS dates in all SAS datasets that
ANALDATE was added by Change 17.168 now works; the debugging lines
Oct 3, 1999 302 and 303 are now removed, and line 10 now has an
ending */.
Thanks to Steve Donahue, Blue Cross and Blue Shield of Texas, USA.
Change 17.251 If SAS options USER= or WORK= were specified, the output
VMXGINIT of an MXG %INCLUDE SOURCLIB(TYPExxxx); program always
Oct 2, 1999 went to //WORK, but with this change, the WORK= or USER=
destination will be honored.
Apr 5, 2000: The USER= or WORK= options must be specified
on // EXEC SAS or on the SAS command; they are resolved
when VMXGINIT executes at MXG startup, and cannot be
changed later with an OPTIONS statement.
-A new macro variable, SASCHRLN, is set to 32000 if SAS V7
or V8 is executed AND if COMPRESS=YES is turned on, but
SASCHRLN=200 for V6 (and for V7, V8 with COMPRESS=NO).
This macro may be used to set the length of character
variables in some specific cases:
With the SAS character variable limit of 200 bytes, MXG
datasets with long text strings (SQL text in DB2 trace
averages 2000 bytes per statement) are output into many
observations for each 200 bytes of text (and the fixed
fields are many hundred repeated bytes!). Instead, now
that variables can be 32000 bytes long, only one output
observation is needed, and by using compression, only
the actual data has to be stored, so the unused length
won't actually take up any space, and you can get the
effect if variable length text storage in SAS!
Thanks to Michael Oujesky, MBNA Hallmark Information Services, USA.
Change 17.250 Member VMXGINIT creates macro variable MXGVERS, the MXG
VMXGINIT Version Number that is printed in MXG messages and kept
Oct 4, 1999 in dataset TYPE70. The MXGVERS value was kept in member
VMXGINIT, but its value is now read from member AAAAAAAA
used because it has always had the version and because
it is never modified by user tailoring), so that now I
can email you a change that includes an altered VMXGINIT
member (two new macro variables are defined there for a
new MXG dataset), but the MXG Version will be unchanged.
Only when you install the full new MXG Version will the
new number be seen. This had not caused any error nor
had anyone noticed, but this seems more righteous.
Change 17.249 New FORMAT MGKILO is created to print five-position
FORMATS values with K/M/G/T/P suffix for Kilo/Mega/Giga factors
Oct 2, 1999 (not 1024 byte-factors, but 1000 kilo-factors) for pretty
printing of data with wide range of values compactly. It
is not used in MXG Software, and will not replace MGBYTES
format for true "mega-bytes" values, but if your manager
demands that you use "million-byte" values to match the
lies from your DASD vendor, you can use MGKILO in your
reports to satisfy him/her, but I suggest you create a
second variable and format it MGKILO and print both the
MGBYTES and MGKILO values side-by-side, and use a LABEL
to clearly identify which is which!
Thanks to Alan Phelan, PKS Systems, USA.
Change 17.248 Support for MQ Series Version 2.1 (COMPATIBLE) type 115
VMAC115 SMF records adds new variables QISTMGET/QISTMPUT to the
Oct 2, 1999 MQMMSGDM MQ Message Data Manager dataset. Previously
reserved fields were used for the new data.
Thanks to MP Welch, SPRINT, USA.
Change 17.247 A new exit member, EX80ASEG, for type 80 SMF records
EX80ASEG (RACF or TOP SECRET) is added so that installation-unique
VMAC80A RACFTYPE segments can be decoded external to the VMAC80A.
Oct 2, 1999 Old-style macro _E80ASEG is defined so MACKEEP= logic can
be used as an alternative to EDITing EX80ASEG.
Thanks to Marc Matthys, Hudson Williams Europe, BELGIUM.
Change 17.246 The subtype 3 TELEVIEW SMF record has four extra bytes
VMACTELE inserted before the startup/shutdown times in the 4.3B
Oct 2, 1999 release that is now supported. An additional internal
TeleView error in the USERID field is corrected by their
fix T19C017.
Thanks to Tom Parquette, MONY Life Insurance Company, USA.
Change 17.245 MXG 17.06 only. Change 17.213 typo caused VTS variables
VMAC94 to have zero values, and ERROR.VMAC94.AUDITLEN INVALID
Oct 1, 1999 messages printed. The line added by that change:
IF SMF94XOF+SMF94VLN*SMF94XON-1 GT LENGTH THEN DO;
should have been
IF SMF94XOF+SMF94XLN*SMF94XON-1 GT LENGTH THEN DO;
(and the SMF94VLN= in the following PUT statement should
also have been SMF94XLN=).
Thanks to Robert Carballo, WORLDSPAN, L.P. USA.
Change 17.244 DCOLLECT variables DCACISZ and DCACACIC were missing,
VMACDCOL because the test before the INPUT of DCAHURBC should have
Oct 1, 1999 been GE 16 instead of GE 32, and the +16 after the INPUT
of DCAHARBC should have been deleted.
Thanks to Paul Naddeo, FISERV, USA.
Thanks to Stewart Spyker, FISERV, USA.
Change 17.243 The _BTY91xx By List macros and _STY91xx Sort macros are
ANAL91 populated and will eliminate duplicate Batch Pipes SMF
FORMATS records. The label for SMF91OW as changed from EMPTY to
VMAC91 FULL, format $MG091XW was updated, and the new ANAL91
Oct 3, 1999 was intended to summarize TYPE91IC/TYPE91OC data to look
for lost data as described in APAR PQ25641. However, as
SMF91IEC/SMF91OEC are almost always zero (7 nonzero in
33,609 TYPE91IC obs, 3 nonzero in 23,570 TYPE91OC obs),
ANAL91 is not much use (yet) in detecting that data loss.
Also, type 91 is incomplete. These pipe criteria values
(ALLOCSYNC,ALLOCNOW,FIT/FITDD,OPENSYNC,NOEOF,EOFREQUIRED,
ERC,CLOSESYNC,TERMSYNC) are not reported in type 91s, nor
are replacement values for WAITALLOC,WAITOPEN,IDLE,WAIT,
WAITEOF,WAITCLOSE or WAITTERM reported when one of those
values is overriden for a specific pipe connection. And
the STEPNAME in TYPE91IC/TYPE91OC still does not match
the SMF 30 record's STEPNAME for same job/step number!
A new APAR PW31018 will correct some documentation for
type 91 records, but a new ETR is still open on counts.
Thanks to Michael Oujesky, MBNA Hallmark Information Services, USA.
Thanks to Chuck Hopf, MBNA, USA.
Change 17.242 If you ran ASUMTALO against a months input, and you had
ASUMTALO one system whose last TYPETALO timestamp was on Aug 5th,
Oct 1, 1999 (either that system went away, or the MXGTMNT monitor
program that writes the SMF records was STOPped, or
MXGTMNT was no longer automatically started at IPL, or
MXGTMNT had shut itself down with an MXGTMNT message on
SYSLOG, etc.) then PDB.ASUMTALO output had data only thru
Aug 5, because the MXG SPIN logic in ASUMTALO put all of
the TALO records for Aug 6-31 into the spin library!
The SPIN logic in ASUMTALO uses the TMNTTYPE=5 Hourly
Interval records (created just for this logic so that
active allocations can be included) in TYPETALO input
to get the timestamp of the last-complete-interval on
each SYSTEM, and uses the minimum last-interval time
across all SYSTEMs as the spin criteria: TYPETALO obs
with timestamps greater than that criteria (both the
TMNTTYPE=5 hourly and the TMNTTYPE=4 end-of-allocation
event) go to SPIN.SPINTALO for tomorrow's ASUMTALO,
because only records up thru the last complete interval
from ALL systems can be used to count tape allocations
when tape drives can be shared across systems.
This SPIN logic works fine when you run ASUMTALO daily,
(ASUMTALO is invoked by BUILDPDB), although if the last
TYPETALO timestamp for one system is at 9:00am THU, the
PDB.ASUMTALO built early Friday will contain data only
up to 9:00am THU, but then the next day's PDB.ASUMTALO
will have picked up the spun records, so PDB.ASUMTALO
built early Saturday will contain 9:00am THU thru FRI
end of day, so no data is really lost, but at most is
delayed one day.
But to support processing of multiple day's TYPETALO data,
the ASUMTALO spin logic now calculates the delta between
the minimums of each system last-complete-interval, and if
there is more than 24 hours difference between systems,
that execution of ASUMTALO will suspend the SPIN logic and
will output all TYPETALO events in the input data.
If you have missing data in PDB.ASUMTALO datasets that
were created from multiple day's TYPETALO, you can delete
the subtype 5 interval records and recreate ASUMTALO with:
//PDB DD DSN=PDB.TO.BE.REPAIRED,DISP=OLD
DATA PDB.TYPETALO;
SET PDB.TYPETALO;
IF TYPETMNT=5 THEN DELETE;
%INCLUDE SOURCLIB(ASUMTALO);
Deleting the subtype 5 interval records eliminates SPIN
logic in ASUMTALO, so all dates will be output into the
replacement PDB. The tail-end intervals will be missing
in-flight tape allocations, but the real data will be
correct. Note that if your PDB.ASUMTALO dataset is on
tape, you cannot directly replace it, and would have to:
//REALPDB DD DSN=REAL.PDB.ON.TAPE,DISP=OLD
//TAPECOPY DD DSN=TEMPTAPE,DISP=(,DELETE,CATLG),UNIT=TAPE
//PDB DD DSN=&&TEMPPDB,DISP=(,DELETE),UNIT=SYSDA,
// SPACE=(CYL,(100,100))
DATA PDB.TYPETALO;
SET REALPDB.TYPETALO;
IF TYPETMNT=5 THEN DELETE;
%INCLUDE SOURCLIB(ASUMTALO);
PROC COPY INDD=REALPDB OUTDD=TAPECOPY;
EXCLUDE ASUMTALO;
PROC DELETE DATA=REALPDB._ALL_;
PROC COPY INDD=TAPECOPY OUTDD=REALPDB;
PROC COPY INDD=PDB OUTDD=REALPDB;
SELECT ASUMTALO;
Thanks to Jonathan A. McVey, Lowe's Companie, Inc, USA.
Thanks to David Zeems, Bank of America, USA.
Change 17.241 The Tandem Utility to read "Unstructured" records was
UTANDSTR re-commented and set up to convert the five Measure files
VMACTAND that MXG supports, and the table of LRECLs for both the
Sep 30, 1999 "Normal" and "Unstructured" tandem records in VMACTAND
was updated.
Change 17.240 The addition of dataset TYPE30TD by Change 17.111 was not
ANALDSET nulled out in ANALDSET, causing ERROR 455-185. New lines
Sep 29, 1999 XY ADD NAME=EXTY30TD
/* override and output no type30td records */
were added to STEPONE.
Thanks to Freddie Arie, Lone Star Gas, USA.
Change 17.239 Variable ENDDTE was not converted back into a SAS date,
VMACXCOM because ENDTIME was created so ENDDTE was redundant, but
Sep 28, 1999 since ENDDTE was also kept, it is now a valid SAS date.
Thanks to Andrew Nyiri, EDS Australia, AUSTRALIA.
Change 17.238 RMFINTRV didn't support non-contiguous shift definitions,
RMFINTRV like a three hour peak-shift that includes 10:00-11:59
Sep 28, 1999 and 14:00-14:59, because some TYPE7xD datasets were not
resorted after the value of STARTIME was changed by the
DURSET macro in member IMACRMFI. Now, all of the TYPE7xD
data sets are sorted BY SYSPLEX SYSTEM STARTIME, so as
long as your shift definition for this peak shift resets
STARTIME to 10:00 as the start of this three hour shift,
all three hours will be summarized as expected.
Thanks to Jim Quigley, Con Edison, USA.
Change 17.237 NETSPY X.25 line stats are in NSPYNPSI dataset instead of
VMACNSPY dataset NSPYLINE (only non-X.25 lines are there), and now
Sep 28, 1999 the line utilization variables SLNU/PLNU are calculated
and kept in NSPYNSPI, for NSPNRECI='04'x (X.25 lines).
Variable NSPX25R is no longer kept in NSPYLINE dataset,
because NSPYLINE contains no X.25 resources and the
existence of that variable was misleading.
Thanks to Sharon Hindle, EDS Australia, AUSTRALIA.
Change 17.236 Invalid user SMF records written with '40'x for record ID
VMAC64 caused TYPE64 code to fail, so protection was added to
Sep 27, 1999 prevent the INPUT EXCEEDED RECORD error. The INPUT is
now conditionally executed:
IF 137+LENEXT+OFFSMF+114 LE LENGTH THEN
INPUT @137+LENEXT+OFFSMF
Thanks to Fred Kaelber, Pacific Bell, USA.
Change 17.235 Support for OS/400 Release 4.4.0 (INCOMPATIBLE due to the
VMACQAPM changes in LRECL of the new records), but if you change
Sep 27, 1999 the LRECLs in your JCL, then MXG 16.02-17.06 "tolerate"
the new records: MXG does not fail, reads all of the
existing fields, but the new fields will not be input
until you install this change, in MXG 17.07 or later).
4.2 4.4
File LRECL LRECL
QAPMBUS 57 111
QAPMDISK 346 352
QAPMECL 276 277
QAPMJOBS 812 819
QAPMLIOP 144 150
QAPMMIOP 232 270
QAPMRESP 58 68
QAPMSYS 3250 3268
-Dataset QAPMCONF now has only one observation, with all
of the Configuration options in that one observation,
instead of a separate observation for each GKEY value.
-Dataset QAPMSYS has three new variables, SYSHEAO, SYHFTH
and SYHFTS.
-Dataset QAPMJOBS has two new variables: JBSVIF JBTFLT.
-Dataset QAPMDISK has one new variable: DSCERC
Change 17.234 Mobius View Direct 6.1.2 (a/k/a INFOPAC) added new field
VMACIPAC for the Caller Type, new variable IPCALLER in dataset
Sep 26, 1999 IPAC03, compatibly.
Thanks to Steve Clark, California Federal Bank, USA.
Change 17.233 TRND70 was enhanced to contain OMVSAVG, OMVSMIN and
TRND70 OMVSMAX to track number of Open Edition users.
Sep 26, 1999
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 17.232 The new PDB.ASUMCEC dataset was created BY SYSPLEX CECSER
ASUM70PR but SYSPLEX should not have been used in the summary (a
Sep 26, 1999 CEC can have LPARs in different SYSPLEXes) and has been
removed. Also, the "PDB" was hardcoded, but it should
have been the "&PDBMXG" macro reference (which defaults
to "PDB" but permits global destination changes by ITSV).
Thanks to Randy Shumate, LEXIS-NEXIS, USA.
Thanks to Toby Olberding, Hudson Williams, USA.
Change 17.231 The date variables XPMLKDT and XPMXPDT were formatted as
VMACSFTA DATE9, but they contained Julian dates and had not been
Sep 26, 1999 converted to SAS dates. These lines were inserted after
their input so they will now contain valid SAS dates:
XPMLKDT=DATEJUL(XPMLKDT);
XPMZPDT=DATEJUL(XPMZPDT);
The actual code change was more extensive, as it includes
the Y2K JULDATE algorithm from member YEAR2000.
Thanks to Ove Dall-Hansen, CODAN Insurance A/S, DENMARK.
Change 17.230 MXG constructed variables STC07FPS and STC07TPS did not
VMACSTC match the format printed on the STK Silo LSM Info report
Sep 26, 1999 but once STK Technical Support told me how they drop the
Oct 5, 1999 first nybble and print three character positions with the
last nybble of ACS in one hex and both nybbles of LSM in
two hex positions, both fields now match the STK utility
report format from the STK user SMF record.
However, truncated subtype 1, 4, and 7 records that cause
INPUT RECORD EXCEEDED RECORD LENGTH, STOPOVER abends were
found and are under now protected in VMACSTC.
One circumvention for these short records (prior to
this change) that eliminates the ABEND and lets MXG
read thru all of the SMF data is to use MACRO STOPOVER
MISSOVER % after //SYSIN to change MXG's default of
STOPOVER to MISSOVER.
However, MISSOVER will still OUTPUT each of the bad
records, so the MXG datasets will contain unexpected
missing values, possibly causing your report programs
to die with divide by zero exceptions!
A safer workaround was to delete the short records
in the IMACFILE exit member, using:
IF ID=222 AND SUBTYPE=7 AND LENGTH LT 140 THEN DELETE;
IF ID=222 AND SUBTYPE=4 AND LENGTH LT 552 THEN DELETE;
IF ID=222 AND SUBTYPE=1 AND LENGTH LT 198 THEN DELETE;
Thanks to Jorge Fong, Depository Trust, USA
Thanks to Joe Faska, Depository Trust, USA.
Change 17.229 The EXCLUDE logic for Omegamon for archaic CICS Version 2
IMACEXCL in macro _CICXCOM did not test for SMFPSRVR, so if you
Sep 26, 1999 had both _CICXCOM and _CICXCU4 enabled, the _CICXCOM code
was executed for the 4.1 region, causing INVALID RECORD
DELETED error message and STOPOVER abend. Inserting
IF SMFPSRVR LE 3 THEN DO; ... END;
inside the MACRO _CICXCOM definition in IMACEXCL allows
the old and new version's excludes to coexist.
Thanks to Charles McAfee, Cover-all, CANADA.
Change 17.228 MXG Change 17.172 enhancements to MXG IMS log processing
ASMIMSLG are now implemented as the standard MXG support members.
ASMIMSL5 (Those changes were added in new "X" members for testing
ASMIMSL6 and with no reported errors, they have now become the MXG
EXIMSBMP support for IMS log processing.) In addition, the exit
EXIMSTRN members for the IMSTRAN, IMSBMPS, and IMSFASTP datasets
JCLIMSLG are now used (i.e., the _EIMSxxx macro did not call the
JCLIMSL5 %INCLUDE SOURCLIB(EXIMSxxx); ) so that the MXG exit
JCLIMSL6 facility can be exploited by ITSV.
TYPEIMSA
TYPEIMSB I strongly recommend that you install the new IMS support
VMACIMSA and use it to reassemble the ASMIMSLx member to re-create
Sep 25, 1999 the MXGIMSLn program, which is then used in the JCLIMSLx
JCL example. Using these new members will correct the
SubQ 6 times as well as provide the many enhancements
to IMS log processing described in member ADOCIMXA.
Change 17.227 The SAP IMS log record 'AE'x was NOT Y2K Ready until SAP
VMACIMSA Release 5.0i, which (INCOMPATIBLY) changed the date from
VMACIMS 0DDMMYYF to YYYYMMDD format. This change supports the
YEAR2000 new format, adds Y2K protection for their old YY format,
Sep 25, 1999 and also corrects an MXG error in the HH/MM/SS fields
that could cause the SAPTIME date to be a day later than
the actual date (those fields are actually PK format, but
they were input with PIB format, so an HH of '18'x or
larger became 25 hours, and bumped the date when HH was
added to create SAPTIME.
Thanks to Alain Kerninon, Generali AG, AUSTRIA.
Thanks to Ottfried Dorok, ICG Informationssys, GERMANY.
Change 17.226 An expiration date of 2099366 caused INVALID VALUE FOR
VMACDCOL DATEJUL FUNCTION and UMEXPDT or DCDEXPDT were missing,
Sep 18, 1999 although ORGEXPDT still contained the 2099366 value.
Since 2099366 itself is an invalid value (2099 is not a
leap year), MXG's algorithm for invalid dates (which is
to set the calculated expiration date to 31Dec2099 so
that any calculation on days-to-expire will be large) is
now extended to protect the invalid date of 2099366,
by inserting
(YREXPDT=199 AND DAYEXPDT GE 365) OR
after the (YREXPDT=99 AND DAYEXPDT GE 365) OR statement
in two places.
Thanks to Harald Seifert, HUK-Coburg, GERMANY.
Thanks to J. Hohring, HUK-Coburg, GERMANY.
Change 17.225 SAS/GRAPH examples are now updated to report
GRAFWORK BY SYSPLEX SYSTEM; instead of just
Sep 18, 1999 BY SYSTEM;
Thanks to Tom Kelman, Sun Trust, USA.
Change 17.224 Member IMACKEEP was not included in TYPETAND, but it now
TYPETAND has been added after the include of member VMACTAND.
Sep 17, 1999
Thanks to Steve Hurley, National Westminster Bank, ENGLAND.
Change 17.223 Report example fails if there were more than one SYSTEMs
ANAL42 data, because the PROC SORT DATA=JIM2 OUT=JIM; and DSD
Sep 15, 1999 BY DESCENDING IOCOUNT;
should have been BY SYSTE DESCENDING IOCOUNT;
Thanks to Freddie Arie, Lone Star Gas, USA.
Change 17.222 Support for APAR OW39508 adds support for 7060 Multiprise
FORMATS 3000 Enterprise Server's new EIO (Emulated I/O) and DSD
Sep 15, 1999 (Direct System Device) type of CHPIDs. MXG Format named
$MG073CD decodes the CHPID type and was updated for these
two new entries, plus additional entries that were in the
complete list (which should have been in the APAR text,
but was not printed there).
Change 17.221 Deaccumulation of WEBSERVR dataset had DURATM and
VMACNTSM STARTIME missing because PREVWEBS=SYSTEM should have been
Aug 27, 1999 PREVWEBS=WEBSERV. Additional variables are deaccumulated
and minor other corrections were made.
Thanks to Jim Quigley, CONED, USA.
Change 17.220 SMF type 110 subtype 0 records written by CICS 5.1 caused
VMAC110 JCRLL=0 MXG error message, because MXG expected the new
Aug 27, 1999 Journal Format SMF records in CICS 5.2 instead of 5.1!
To correct, find the two IF statement with comments that
contain "Journal Format" and change them to now read:
IF SMFPSRVR LT 51 THEN DO /* PRE 5.1 JOURNAL FORMAT */
ELSE IF SMFPSRVR GE 51 THEN DO; /*POST 5.1 JOURNAL FORMAT*/
Thanks to Andre van de Riet, Hudson Williams Europe, THE NETHERLANDS.
Change 17.219 SAS ITSV CPDUPUPD fails with APPARENT MACRO error because
DIFFTPX an old statement: OPTIONS MAUTOSOURCE SASAUTOS=SOURCLIB;
DIFFROSC was still in these members. The SASAUTOS was changed to
TYPEDOS OPTIONS MAUTOSOURCE SASAUTOS=(SOURCLIB SASAUTOS); back in
TYPEIMS Change 16.066, and since they are set in member CONFIG,
TYPEIMS1 those old statements in these members were deleted so as
Aug 23, 1999 to eliminate the error.
Thanks to Jens Mohring, HUK Coburg, GERMANY.
Thanks to Harald Seifert, HUK Coburg, GERMANY.
Change 17.218 Support for Top Secret Release 5.1 (INCOMPATIBLE, due to
VMAC80 the need for a specific test to recognize Top Secret type
VMAC80A 80 records from the standard IBM type 80 record). To fix
Aug 23, 1999 MXG to support this release, you need only to add
OR RACFVRSN=051X
to the existing test for Top Secret Versions.
Thanks to Peter Vines, THE University of Virginia, USA.
Change 17.217 The member still contained a %INCLUDE for EXTY94 instead
VMAC94 of invoking the _ETY94 substitution macro, so overriding
Aug 16, 1999 the _ETY94 did not work. Now it does.
Thanks to Tom Parker, CSC/Hogan, USA.
======Changes thru 17.216 were in MXG 17.06 dated Aug 12, 1999======
Change 17.216 To be Y2K Ready, ASMTAPES must be assembled with "ES6"
VMACTMNT when the MXGTMNT Tape Mount Monitor program is assembled
Aug 12, 1999 for under OS/390 R1.3 or later. Your old MXGTMNT program
that had been assembled with "ES5" or "ESA" still ran on
OS/390 R1.3, so there was no error to alert you that the
"ES6" was now required, but if you are still running the
old MXGTMNT after January, 2000, the date in the INITTIME
field will still be 1900! IBM moved that date from a 3
to a 4 byte field that is only seen by "ES6".
ASMTAPES documents that "ES6" is for OS/390 R1.3, but
I had not previously highlighted that requirement.
This change protects VMACTMNT; if 1900 records are still
being written at your site in Jan, 2000, the variable
INITTIME in TYPETMNT and TYPETALO will be correct.
Thanks to Steve Donahue, Blue Cross and Blue Shield of Texas, USA.
Change 17.215 The variable R791ES in this old report example became the
ANALSTOR variable R791ESCT in Change 8.167, but the report was not
Aug 10, 1999 updated until now.
Thanks to Tony P. Steward, Post Office, ENGLAND.
Change 17.214 OS/390 R2.8 is already supported in MXG, as there were
several only minor, compatible changes, most of which have been
Aug 10, 1999 released as APARS to the type 89, 92, and 94 SMF records.
MXG Versions 16.09 or later can process the R2.8 records.
Change 17.213 Support for the Import/Export Statistics section in SMF
VMAC94 type 94 adds new variables to dataset TYPE94.
Aug 10, 1999
Change 17.212 TYPE110 SUBTYPE 2 ERROR STID=67 SKIP=80 because the value
VMAC110 of A17DT was hex '00' in the record, but MXG's statement
Aug 8, 1999 A17DT=TRANSLATE(A17DT,' ','00'x) was incorrectly changing
the '00'x to a blank, causing the two 40-byte sections
to be skipped. Delete that line and these records will
be properly decoded in to the CICFCR statistics dataset.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 17.211 TYPE74CF observations have the XSYSn variables non-blank
VMAC74 in only one record per SYSPLEX, and you can't pick which
Aug 8, 1999 SYSTEM's record has the info, accoring to this IBM reply:
To avoid collection of redundant data within a sysplex,
RMF selects one system as a 'master system'. This
selection is RMF internal, there is no option to select
the master system. For this 'master system' all CF
data, SMF 74-4 data, are collected. For the other
systems within a sysplex, the redundant but expensive
CF-data are omitted (expensive in terms of CPU
utilization). That explains why we see the
'Connectivity Data Section' and 'Structure Data
Section' only for one system within a sysplex. For
more details, please see apar OW31699, as this was
introduced with this APAR.
Thanks to Dennis Wong, New York Life Insurance, USA.
Change 17.210 -PDB.ASUMTAPE can have the wrong JOB/READTIME/INITTIME for
ASUMTAPE some jobs from TYPETMNT, but these events are detected
Aug 8, 1999 and the TYPETALO information is used to identify the job
that caused the mount. These mismatched events occur
only for jobs that went thru allocation recovery and are
usually few in number (5 of 2500).
-PDB.ASUMTAPE can have small negative values for TAPMTDTM
because the TENDTIME is the sampled MXGTMNT end of mount,
but TY21TIME is the exact dismount timestamp. The value
will be less than two seconds (the default MXGTMNT sample
rate) so to avoid negative numbers for the duration a
a tape is mounted, these negatives are now set to zero.
Thanks to Gene Rahe, First American, USA.
Thanks to Judy Arroyo, Summit Bank, USA.
Change 17.209 Support for NTSMF: Lotus Notes, SMTPDS & SMTPRS objects:
EXNTLNAG Object Dataset Variables
EXNTLNCA Lotus.Notes.Agent LONOAGNT 8
EXNTLNDB Lotus.Notes.Calendar LONOCALN 6
EXNTLNDI Lotus.Notes.Database LONODB 21
EXNTLNDV Lotus.Notes.Disk LONODISK 2
EXNTLNDO Lotus.Notes.Disk.Inventory LONODINV 1
EXNTLNMA Lotus.Notes.Domino LONODOMI 66
EXNTLNME Lotus.Notes.Mail LONOMAIL 16
EXNTLNNE Lotus.Notes.Memory LONoMEM 5
EXNTLNNL Lotus.Notes.Network LONONETW 11
EXNTLNRE Lotus.Notes.Network.Log LONONETL 2
EXNTLNSE Lotus.Notes.Replica LONOREPL 5
EXNTLNWE Lotus.Notes.Server LONOSERV 16
VMACNTSM Lotus.Notes.Web LONOWEB 39
VMXGINIT SMTPDS SMTPDS 4
Aug 7, 1999 SMTPRS SMTPRS 4
-NTSMF 2.1.1 could write an interval begin (0,0) with the
DURATM=0, which caused STARTIME to be missing. While now
fixed, this change also protects that case and uses the
previous interval to construct STARTIME.
Change 17.208 The RECFM=F and LRECL=256/512 were removed from the
VMACSPMG INFILE statements so that the DCB attributes are read
Aug 6, 1999 from the dataset. SpaceManager files can be F or FB.
Thanks to Anke Mineur, dvg Hannover, GERMANY.
======Changes thru 17.207 were in MXG 17.05 dated Aug 5, 1999======
Change 17.207 Microsoft SP4 and HotFixes have changed the version text
VMACNTSM from "Service Pack 3" to "Service Pack 4, RC 1.2", which
Aug 5, 1999 was passed by NTSMF into its output comma delimited file,
so an extra new field was inadvertently inserted in this
configuration record. MXG now looks for that syntax and
appends the "RC 1.2" to the NTVERSN. NTSMF will protect
the field in a future version to blank the comma.
Thanks to Norbert Ravarani, European Commission, LUXEMBURG.
Change 17.206 Member IMACJBCK (the "job check" exit to select SMF
IMACJBCK job-related records by JOB/READTIME/etc) was not changed
VMXGINIT to support dynamic changes, but by defining MACJBCK in
Aug 5, 1999 VMXGINIT and locating &MACJBCK; at the end of IMACJBCK
you can now use %LET MACJBCK= ... ; syntax instream
instead of editing your tailoring into IMACJBCK member.
Thanks to Dr. Alexander Raeder, Karstadt AG, GERMANY.
Change 17.205 Variables MCTDLWTV and MCTDPWTV, bytes logically written
VMXGHSM and bytes physically written, are now created in dataset
Aug 5, 1999 MCT from the HSM catalogs. Many sites now use DCOLLECT
rather than reading the catalogs directly with MXG.
Thanks to Dave Jackson, Capital One Financial Services, USA.
Change 17.204 Negative PGMLODTM was caused by the DEFAULT=4 which was
VMACCIMS truncating timestamps and record number. Change the
Aug 5, 1999 both DEFAULT=4 to DEFAULT=8.
Thanks to Alan Green, Zurich Co., ENGLAND.
Thanks to Brian Sznger, Zurich Co, ENGLAND.
======Changes thru 17.203 were in MXG 17.05 dated Aug 4, 1999======
Change 17.203 If you have Dedicated CPUs in LPARs, PR/SM forces Wait
ASUM70PR Complete=Yes (which makes sense: to reduce overhead when
Aug 4, 1999 there's nothing to share), but MXG's PDB.ASUM70PR reports
100% CPU busy in that LPAR (LCPUPDTM, partition dispatch
time is 100% in a Wait Complete=YES LPAR) because MXG did
not see this before! The immediate fix to your ASUM70PR
member is to insert this DO group in the INCODE= section,
immediately after the "LPARDUR=DURATM;" statement:
IF LCPUDED='Y' AND LCPUWAIT='Y' THEN DO;
IF PCTCPUBY GT . THEN DO;
LCPUPDTM=LPARCPUS*PCTCPUBY*DURATM/100;
LCPUEDTM=LCPUPDTM;
END;
ELSE DO;
LCPUPDTM=.;
LCPUEDTM=.;
END;
END;
The PCTCPUBY that is tested is MVS CPU busy for Dedicated
CPUs, but it exists only in the SMF record from the MVS
System running in that LPAR. In the ASUM70PR observation
from other LPARs in this CEC (Central Electronic Complex)
the dedicated LPAR CPU busy measures will be missing, as
they simply are unknown to the other LPARs. If you have
only one LPAR in a CEC, then there is only one SYSTEM and
the ASUM70PR data will be valid with the above fix.
However, this error is an opportunity to design a better
solution to measuring CEC/LPAR CPU busy. The ASUM70PR
dataset is created per SYSTEM, but what you need is now
the new PDB.ASUMCEC dataset that summarizes TYPE70PR data
by the CECSER (CPU Serial Number of the CEC/CPC), so the
hardware platform is measured by PDB.ASUMCEC, with true
CPU busy for each of the LPARs running on that CEC.
The structure of PDB.ASUMCEC has the same variable names
(except for SYSTEM, which doesn't have any meaning here),
so your existing reporting should require minimal change.
But MXG has to read all of the type 70 records from every
MVS system that executes in an LPAR with Dedicated CPU to
create true CPU measurements; you cannot measure CPU busy
in a Dedicated-CPU-LPAR from any other LPAR's SMF record;
if MXG does not see the true CPU busy record, the CPU for
those dedicated engines will be missing values and the
total CPU busy will be wrong.
Check your EXTY70PR exit to see if there was user code
added to output records from only one system; delete
that logic if you find it, so you output all records.
The bottom line is that PDB.ASUMCEC should have been the
dataset created long ago, but now it should correct the
existing error and give you a single record per box to
measure total and per-LPAR CPU utilizations.
Thanks to Brandan Hock Kwan Wong, DBS, Singapore.
Thanks to Chee Hwee Chua, DBS, Singapore.
Change 17.202 This example report program processes VTS SMF type 94
ADOC94 records and replicates IBM PGM=VTSSTATS reports. The
ANAL94 report is documented in member ADOC94. Remember to use
Aug 2, 1999 only one system's data to report on a library box.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 17.201 APAR OW40390 identifies SMF92CPN, pathname, that may be
VMAC92 in your type 92 OMVS/USS file records; that field is now
Aug 2, 1999 input if present. The APAR also adds two subtypes to SMF
Aug 10, 1999 type 94 that create two new MXG datasets for OMVS/USS:
Subtype Dataset Description
12 TYPE9212 MMAP
13 TYPE9213 MUNMAP
Change 17.200 Support for IBM's TPF Operating System.
EXTPFxx Forty datasets are created from the fifty or so records.
FORMATS Some datasets are written at monitor initialization to
IMACTPF map things, but the interval records are deaccumulated
TPFINTRV and written as individual PDB datasets, and then TPFINTRV
TYPETPF is invoked to summarize into PDB.TPFINTRV. This support
VMACTPF has been tested with data from one system, and TPFINTRV
VMXGINIT intervals the SA/NX/SX/SU/SP/MD/MG/FV/FS/SC records.
VMXGTPFI This is preliminary support, but TPFINTRV and its input
Aug 2, 1999 datasets have been tested extensively; there are still a
number of questions and some variable names may change.
For over two years I have requested the DSECTS for the
TPF records; it took a vote of the TPF Users Group to
"convince" IBM it would be worthwhile to allow MXG to
support this high-speed transaction processing system.
Formerly know at the Airline Control Program, it can
drive 30,000 I/Os per second on an 8-engines CPC!
The initial development of the VMACTPF code took 40 hours
across four days to write about 4,000 lines of SAS code.
Another 40 hours were required to add the roughly 400
lines to deaccumulate and validate the PDB.TPFINTRV data.
Thanks to Jack Opgenorth, Sabre, USA.
Thanks to Linda Tallent, Sabre, USA.
Change 17.199 Support for APAR OW39128 adds DSNAME to SMF type 80-2
VMAC80A Resource Access event, so that you can tell what library
Aug 2, 1999 an audited controlled program was loaded from! So if
you need to know which program library is being used by
which users for which programs, you can use RACF to
control access and write a record for each successful
or failed attempt to run that program and finally know
which STEPLIB dataset was actually used by that job!
Variable RPDSNAME is added to dataset TYPE8002. The APAR
also populates variable VOLSER in the DTP=15 section for
this case, but that variable is already in TYPE8002.
Change 17.198 Variables that contain '00'x, when printed across VTAM or
VMAC110 downloaded as a text file from MVS to your PC, can cause
Aug 2, 1999 the download to stop. Other unprintable characters in
a PROC PRINT output can make your PC see an end-of-file
long before the real end of the file. When these values
are seen for a character variable, it is either formatted
with a HEX/$HEX format, or if the variable is normally a
printed variable that maybe has nulls at the end, then
the TRANSLATE function is used to convert nulls to blank
values. Variable SMFSTRTK was formatted $HEX16. and the
variables A13LVW, A17FLOC, A17DTTYP, A17DT, and DS5TCBNM
have any nulls translated to blanks.
Change 17.197 Starting from ANALDSET, this new ANALJOBE, "Job Events"
ANALJOBE adds to the 14, 15, 64, and 30s, the information from the
Aug 2, 1999 the VSAM type 62 OPEN time, the statistics from the type
Aug 12, 1999 42 subtype 6 TYPE42DS close, and the type 30 interval
records are used to capture PROGRAM name for Started
Tasks and long running steps whose step termination type
30 has not yet been seen. Additionally, if new datasets
were cataloged, the 61/65/66 SMF records in TYPE6156
identify that activity. The result will be a tool to
examine every timestamp in the life of a job, for delay
analysis, etc. This phase is complete, but HSM is soon
to be added.
And ANALJOBE is a single step, cleaner implementation:
When ANALDSET was first written in 1976, tape had to
be used because of data volume, and frequent system
crashes were circumvented by using multiple steps, so
a recovery might not have to re-read the SMF data
again!. Reliability, cheaper DASD, and better code
makes that unnecessary: two days SMF data opens used
than 1000 Cylinders (a/k/a 750 MB) of //WORK space.
The output dataset of this algorithm, ANALJOBE, may be,
in a future program, merged into the ASUMTAPE dataset to
identify the first-open-time and last-close-time of each
tape dataset, to identify where FREE=CLOSE can be used to
save tape drives.
Thanks to Chuck Hopf, MBNA, USA.
Change 17.196A If the CPMF segment exists in the record, but SMF73CMG,
VMAC73 the CPMF Measurement Group is 0, MXG did not skip over
Aug 2, 1999 the CPMF segment, and stopped reading Channels at CHPID
'55'x (one third of 'FF'x, because the old segment was
24 bytes long, the new is 72). Also, variables CHANIND
CHANINDX CHANINDY SMF73CPD SMF73FG5 are now hex format.
Thanks to Dr. H. Pat Artis, Performance Associates, USA.
Change 17.196 Dataset CONTROLD variable ACCOUNT2 is renamed CTLDACCT,
VMACCTLD so that its label does not override the real ACCOUNTn
Aug 2, 1999 field if CTLD records are processed with BUILDPDB. The
label as changed from second to first, as CTLDACCT has
(in ten fixed bytes) the first account field.
Thanks to Mike Penlington, Westpac Truse, NEW ZEALAND.
Change 17.195 Support for STK's VTCS 2.2.0 INCOMPATIBLE change to VSM
VMACSTC SMF subtype 13-26 records. Version 1 timestamps used the
Aug 2, 1999 unix epoch of 1/1/1970, which MXG handled, but now their
developers decided to waste my time and your time by
changing what was working just fine, back to what it
should have been in the first place, a TODSTAMP8 format.
And it doesn't appear that they put a version indicator
in their record, so I have to test each subtype to see
which version you have installed. And because at least
one field (VTV time) was not changed to TODSTAMP, I have
to test each of those timestamps in case they change the
format again! The test uses the first four bytes of the
timestamp, an algorithm that won't fail until Sep, 2042,
when the TOD clock wraps. Hopefully, STK will have added
a version indicator in their record before then.
Thanks to Sue Yarker, Midland Bank a/k/a HSBC, ENGLAND.
Change 17.194 The MXG 16.04+ revisions to HP Measureware did not define
VMACMWUX macros _HPUXCPU and _HPUXDLM in member VMACMWUX, and the
Aug 2, 1999 examples in IMACMWUX were commented out. The correction
was to define the macros in VMACMWUX, so that they are
defined by default in the VMAC, so they can be tailored
in the IMACMWUX, IMACKEEP or with %LET MACKEEP=. logic.
Thanks to Glenn Delvecchio, Stelco Inc, CANADA.
Change 17.193 -Using INTERVAL=NONE caused a warning message that the
VMXGSUM VARIABLE DATETIME IS UNINITIALIZED with no other impact.
Aug 2, 1999 The warning message is eliminated by this change.
-Using a dashed-list of variables in the NORM= argument
could cause errors messages about &EVAL function or
extra variables to be created, but only if there was
more than one dash per line and/or blanks around the
dash. Now the parser handles dashed-lists and blanks.
Change 17.192 The BY list for TYPE42DS needed DEVNR added to the end of
VMAC42 the list to fully protect for duplicate records.
Jul 30, 1999
Thanks to Chuck Hopf, MNBA, USA.
Change 17.191 Comments. The Subtype 5 Interval record is automatically
ASMTAPEE synchronized with SMF ENF Event 37, so there is no longer
Jul 28, 1999 a need to issue the console command to synchronize.
Thanks to Dr. Alexander Raeder, Karstadt AG, GERMANY.
Change 17.190 The SPIN.SPINMOUN and SPIN.SPINALOC datasets were not
ASUMTAPE copied into the PBD library (for backup and recovery),
Jul 28, 1999 but now they are.
Thanks to Freddie Arie, Lone Star Gas, USA.
Change 17.189 Member DIFFDB2 is automatically invoked by TYPEDB2, and
DIFFDB2 it separately listed the _Sdddddd macro for each dataset
VMACDB2 to be sorted/deaccumulated, which works fine, until you
Jul 27, 1999 try to create only dataset DB2ACCT. You can null all DB2
datasets with the _NDB2 macro, and can reinstate DB2ACCT
with the MACRO _WDB2ACC redefinition, but then DIFFDB2
fails ("NO DATASET OPEN TO LOOK UP VARIABLES") when it
tries to sort the non-existent datasets. You can fix the
design flaw by nulling out each of the individual sort
sort macros that are listed in DIFFDB2:
%LET MACKEEP= _NDB2
MACRO _WDB2ACC DB2ACCT.DB2ACCT %
MACRO _SDB2ACP %
MACRO _SDB2ACB %
MACRO _SDB2ACG %
MACRO _SDB2PAT %
MACRO _SDB2ST2 %
MACRO _SDB2STB %
MACRO _SDB2STR %
MACRO _SDB2STS %
MACRO _SDB2PST %
;
%INCLUDE SOURCLIB(TYPEDB2);
to build only the DB2ACCT.DB2ACCT dataset. However, to
correct the design flaw, the definition of MACRO _SDB2
in VMACDB2 was changed so that it does not sort the
DB2ACCT dataset (just like _S110 doesn't sort CICSTRAN)
and DIFFDB2 now invokes _SDB2 instead of all of the
individual _SDB2ddd macros, so now (17.05+) you can use:
%LET MACKEEP= _NDB2
MACRO _WDB2ACC DB2ACCT.DB2ACCT %
MACRO _SDB2 %
;
%INCLUDE SOURCLIB(TYPEDB2);
to create only DB2ACCT.DB2ACCT. And this protects you
for future datasets, and they will be listed in both the
_NDB2 and _SDB2 macro definitions.
Thanks to Alastair Gray, Phillip Morris International, SWITZERLAND.
Change 17.188 This user contribution was posted on MXG-L; it reads the
USTKVOL output of the StorageTek Volume Report utility to find
Jul 26, 1999 the date when each volume was mounted in the ATL, and the
the date when each volume was mounted in the ATL, and the
example invokes MXG member TYPETMS5 and appends the ATL
data with the TMS information on each volume.
Thanks to Clark Jennings, Reynolds Metals Company, USA.
Change 17.187 The MXG Test JCL stream step TESTOTHR fails in VMXGTAPE
JCLTEST6 because SAS option USER=PDB had been added to their JCL.
Jul 26, 1999 Don't do that to this JCL example that didn't expect it!
A comment has been added to the member.
Thanks to Dr. Alexander Raeder, Karstadt AG, GERMANY.
Change 17.186 IBM RMF Report replicator example used TYPE74OM dataset
ANALRMFR to now produce their OMVS KERNEL ACTIVITY REPORT.
Jul 22, 1999
Change 17.185 IBM's sample IXGRPT1 for SMF type 88 Logger records is
ANAL88 now replicated in this example report program that uses
Jul 21, 1999 both TYPE88 and TYPE8811 datasets.
Change 17.184 Revision to correct ZEROOBS= argument, which did not work
UTILBLDP in the prior version. Further updated August 3.
Jul 21, 1999
Thanks to Mike Utting, Hitachi Data Systems, AUSTRALIA.
Change 17.183 Continued IMS Log enhancements for Fast Path transactions
TYPEIMS is revised and made available for testing.
VMACIMS
Jul 21, 1999
Change 17.182 Numerous errors in OMVS/USS dataset TYPE74OM. MXG failed
VMAC74 to divide seven variables by NRSAMPLE, so they had large
Jul 21, 1999 values: OMVSSYSC OMVSCPU OMVSOPRP OMVSOUS OMVSOPRU
OMVSCURP OMVSCURU
And NRSAMPLE was not kept in TYPE74OM, but now is there.
Then IBM documented twelve fields as binary, but they in
fact contain s_float (RB4.) data, also causing largeness:
OMVSCMSG OMVSCSEM OMVSCSHM OMVSCSPG OMVSCMAP OMVSCPAG
OMVSOMSG OMVSOSEM OMVSOSHM OMVSOSPG OMVSOMAP OMVSOPAG
-A few labels had TOT or TOTAL for Average variables.
-Note that the IBM OMVS Kernel Activity Report prints
CPU time in units Hundredths of a Second, so a MAX CPU
of 8 on their report is actually .08 CPU seconds, which
is what MXG variable OMVSCTMX contains.
-RMF fields for Shared Memory, Memory Map Storage, and
Shared Storage are in bytes in the raw data, so MXG now
formats those variables with MGBYTES to show the true
MegaBytes, etc, but IBM still prints K or M after the
value for a factor of 1000 instead of 1024. For Shared
Storage actual value 32,768,000, IBM prints 32.8M, but
MXG prints that true size in megabytes as 31M.
Thanks to Ed Woodward, ADP/BSG, USA.
Change 17.181 Cosmetic. DCOLLECT variables DCDCUDSZ and DCDUDSIZ were
VMACDCOL correct, but their labels were reversed. DCDCUDSZ is the
Jul 21, 1999 Data Size AFTER compression, DCDUDZIZ the size BEFORE.
Thanks to Alan Winston, MBNA, USA.
Change 17.180 Support for APAR OW31701, "ESS Parallel Access Volumes"
VMAC74 adds new variables to TYPE74 and TYPE799 datasets:
VMAC79 PAVBASE ='PAV*DEVICE?'
Jul 20, 1999 NRALEXCH='NUMBER OF*ALIAS*EXPOSURES*HAS CHANGED'
Sep 12, 2000 SMF74PCT='SUCCESSFUL*PAV*SAMPLE*COUNTS'
SMF74TMS='TIME SKIPPED*IF NR*ALIAS EXP*WAS CHANGED'
NREXPOSR='NUMBER OF*UCBS FOR*PAV VOLUME'
Text of this change revised after change 18.096 added the
variable PAVBASE instead of old variable BASE.
Change 17.179 Using the 17.04 ANALRMFR against a 14.14-built PDB failed
ANALRMFR with VARIABLE SMF72QDT NOT FOUND; five variables added to
Jul 20, 1999 TYPE72GO (SMF72QDT/IQT/ADT/IOT/CVT) by later versions of
MXG were not protected for non-existence in ANALRMFR, but
now they are and it can be used against back-level PDBs.
Thanks to Normand Poitras, Banque Nationale du Canada, CANADA.
Change 17.178 New summarization member creates PDB.ASUM78CF dataset by
ASUM78CF summarizing dataset PDB.TYPE78CF for analysis of I/O
Jul 20, 1999 Configuration activity.
Thanks to John Meli, Queensland Rail, AUSTRALIA.
Thanks to Paul Dirkis, Queensland Rail, AUSTRALIA.
Change 17.177 Support for Control D release 5.1.4 has been confirmed,
VMACCTLD as there were no changes in the record format.
Jul 20, 1999
Thanks to Trevor Ede, EDS, NEW ZEALAND.
Change 17.176 OMVS (Open Edition/MVS), now USS (Unix System Services)
BUILD005 tasks create no purge records, so BUILDPB held their data
BUIL3005 in the SPIN library for SPINCNT days (in member IMACSPIN)
VMAC30 before they were OUTPUT into the PDB.STEPS and PDB.JOBS.
Jul 20, 1999 These OMVS tasks have SUBSYS='OMVS' but TYPETASK='STC '.
To output the OMVS tasks without purge records, BUILD005
and BUIL3005 were revised to detect and to not spin OMVS
tasks. To be consistent with its purpose, MXG variable
TYPETASK='OMVS' will now contain 'OMVS' for OMVS tasks.
You can fix the SPIN problem by using member IMACSPCK
by inserting: IF SUBSYS='OMVS' THEN OKFLAG=1;
until you install the version with this change.
Note that these JOBS/STEPS observations for OMVS tasks
are the TSO resources; the count of OMVS functions are in
the TYPE30OM dataset, which was not affected.
Thanks to Larry Ludwig, Northern Illinois University, USA.
======Changes thru 17.175 were in MXG 17.04 dated Jul 16, 1999======
Change 17.175 The preliminary IMS Log Enhancements in Change 17.172
ADOCIMS required one more tweak. The SubQ 6 time from the type
TYPEIMSA 7 record was being applied to the following transaction
VMACIMSA instead of the preceding transactio for pseudo/WFI or
Jul 16, 1999 Quick Reschedules, causing timestamps used to calculate
service times to be bad in occasional transactions.
Also, the member ADOCIMSX now exists in the MXG 17.04
dated Jul 16 that is now being shipped.
Change 17.174 IBM has confirmed Don's discovery that the R723CCHS
VMAC7072 (MXG variable PCTDLCHS) was trashed (like 600,000%!),
Jul 16, 1999 and will eventually fix their in counting those delays.
This correction recalculates by subtracting all of the
other wait fields so that PCTDLCHS will be valid with
or without the IBM correction.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 17.173 -Reading AS/400 data on ASCII platforms caused variable
VMACQAPM AS400SYN to be trash, because it wasn't converted from
VMXGINIT ASCII to EBCDIC when it was input as variable GDESS, but
Jul 15, 1999 inserting these two lines after the input of GDESS:
Jul 20, 1999 GDESS=INPUT(GDESS,$EBCDIC8.);
GDESS=TRANSLATE(GDESS,' ','80'X);
will create readable values for GDESS and AS400SYN.
-Also, WARNING: APPARENT SYMBOLIC REFERENCE LOLEVEL NOT
RESOLVED note is eliminated by the addition of LOLEVEL
in VMXGINIT as a GLOBAL macro variable with null value.
Macro variable LOLEVEL was used under MVS to pass the
lowest level of the DSNAME of the input file into an
MXG variable (AS400SYS in this case), because there
used to be no "System" name in the AS400 records.
Now, the MXG variable AS400SYN contains the system
name, so AS400SYS can be left blank.
-The include of member IMACKEEP was missing from TYPEQAPM
member, so tailoring in IMACKEEP was not recognized for
the AS/400 processing. It has now been added.
Thanks to Don Goulden, SAS Institute, USA.
======Changes thru 17.172 were in MXG 17.04 dated Jul 14, 1999======
Change 17.172 Significant enhancements to IMS log processing are now
ASMIMSLG available for testing. These added members will replace
ASMIMSL5 their counterparts in the next version of MXG, so I
ASMIMSL6 chose to use temporary names with an X in the penultimate
JCLIMSXG position to keep the new members apart. For the ASM and
JCLIMSX5 JCL members, change the X to an L, and for the TYPE and
JCLIMSX6 VMAC members, change the X to an S, as you copy them into
TYPEIMSA your USERID.SOURCLIB for testing.
TYPEIMSB Member ADOCIMSA contains the discussion of the changes in
VMACIMSA these revisions.
Jul 14, 1999
Thanks to Carl Meredith, SAS Institute ITSV, USA.
Thanks to Ken Whitehead, Bank of New York, USA.
Change 17.171 PRINTWAY records contain JCTJOBID='PSnnnnnn', so the MXG
DOC logic to create TYPETASK='PS' and JESNR=nnnnnn in all of
Jul 13, 1999 these MXG members that create TYPETASK from JCTJOBID:
VMAC6,VMAC26J2,VMAC26J3,VMAC30,VMAC32,VMAC42,VMAC91,
VMACBETA,VMACDALO,VMACIPAC,VMACNNAV,VMACTMNT,VMACXPM
and BUILD005 was revised to test for the 'PS' value.
Thanks to Bob Falla, The Mutual Group, CANADA.
Change 17.170 DB2ACCT variables added by versions 5.1 and 6.1 are now
ASUMDB2A added to the summarization by member ASUMDB2a in creating
Jul 13, 1999 dataset PDB.ASUMDB2A. Comments in member ASUMDB2A list
the 75 variables added to the SUM and one to the MAX.
Thanks to Glenn Bowman, Wakefern, USA.
Change 17.169 Landmark TMON V2 response time TARSPTM will contain the
VMACTMO2 sum of all conversations if SEGMENT CONVERSTATION is NOT
Jul 13, 1999 set to Y in Landmark Record Collection Options, and the
total count of conversations is counted in TARSPCT. So
if TARSPCT is greater than one, TARSPTM is recalculated
as the average response time of those conversations:
IF TARSPCT GT 1 THEN TARSPTM=TARSPTM/TARSPCT;
Thanks to Dan Ternosky, IBM, USA.
Change 17.168 This utility will analyze a SAS data library for date or
ANALDATE datetime formatted variables, and will print a summary of
Jul 12, 1999 minimum and maximum dates found in your data, as well as
dates outside the expected range (user definable, default
earlier than 1/1/1999 or later than 1/1/2001). This may
be useful in your final Y2K testing of SAS libraries.
Thanks to Freddie Arie, LONE STAR GAS, USA.
Change 17.167 Corrections to Boole's MainView for CICS VSAM file. The
VMACMVCI division of T6EP24HW by 62500 was incorrect and was thus
Jul 12, 1999 removed. The input of T6EUSTGO was moved back two bytes,
by creating M6=-6; and using +M6 instead of +M4, and by
inserting +2 after the input to re-align with the rest of
the data fields.
Thanks to Mrs. Peridon, Ministere du Budget, FRANCE.
Thanks to Mr. Deledalle, SAS Institute, FRANCE.
Change 17.166 An IBM-provided PSF ZAP (change APSPPSMF to set SMF6IMPS
VMAC6 with Logical Page Count in DIAPAGE instead of Side Count
Jul 12, 1999 from DIAIMPS) overlays the record with zero for SMF6LN2,
that cause INPUT STATEMENT EXCEEDED error condition.
While IBM investigates, this circumvention resets a zero
SMF6LN2 to 36 so that the rest of the record is output.
If these invalid records are found, MXG will now print a
note for the first three instances.
Thanks to Rick Knapp, AON, USA.
Change 17.165 Preliminary NTSMF support for Win 2000 Beta 3 and support
VMACNTSM for new data and record formats for four existing objects
Jul 11, 1999 as well as protection for the new 0.8 and 0.9 records.
The Beta changes are incomplete, as the discover records
had fields with missing names that are input with place
holders, but the important existing fields should be ok.
Win 2000 Beta 3 Changes:
Object Status
Memory: Reordered, 3 Name Missing field
Process: 6 Name Missing fields
PhysDisk: 5 new fields inserted somewhere
LoglDisk: No Instance name, 3 new
Other Object Changes:
Object Status
IIS Global: Complete Revision, all new vars
Web Service: Twenty-Seven new variables
Indexing Service: Instance variable removed
Indexing Service Filter: Instance variable removed
Thanks to Jim Quigley, Con Edison, USA.
Change 17.164 The _SVMxxxx sort macros had PROC COPY syntax instead of
TYPEVM the DATA _LVMxxxx; SET _WVMxxxx; logic that is needed
Jul 11, 1999 until the _BVMxxxx BY macros are populated.
Thanks to Anthony P. Lobley, EDS, ENGLAND.
Change 17.163 ASUM70PR discards SMF70CIN='ICF' observations so they are
ASUM70PR not counted in NRCPUS, LPARCPUS, or PARTNCPU variables in
Jul 11, 1999 PDB.ASUM70PR (as long as you have APAR OW37565 on your
system - see Change 17.162). If you have more than one
ICF CPU, the circumvention in member XSUM70PR from Change
16.381 is not valid, and this revision does not depend on
a table of SYSTEM/LCPUADDR. It first counts the number
of ICF engines, and then subtracts that count from the
above variables in the real CPU records while deleting
the ICF CPU records. It also creates new variable
NRICFCPU with the count of the number of ICF engines
found in the CPC (and whose detail can still be found in
the TYPE70PR 'ICF' observations), but whose data are not
included in PDB.ASUM70PR (nor in TRND70PR either).
If you use this new ASUM70PR to summarize old TYPE70PR
data, you will get 'SMF70CIN UNINITIALIZED' messages, but
that has no impact unless you actually have ICF, in which
case you will need to recreate TYPE70PR with the new
TYPE7072 with Change 17.162 installed.
Change 17.162 Support for APAR OW37565 creates SMF70CIN='CP ' or 'ICF'
VMAC7072 in TYPE70PR dataset to identify if the CPU is a General
Jul 11, 1999 Purpose CPU (SMF70CIN='CP '), or an Internal Coupling
Facility CPU (SMF70CIN='ICF'). While most sites use the
PDB.ASUM70PR dataset, revised by Change 17.163, for PRSM
measurements, if you use the PDB.TYPE70PR detail dataset
you will want to revise your reporting to exclude the
ICF CPUs from your capacity counts and measurements.
Change 17.161 Support for APAR OW37816 adds data for new 2105 cache
VMAC74 subsystem to dataset TYPE74CA, and the data looks very
Jul 11, 1999 interesting with these new variables:
R7451AID='DEVICE*ADAPTER*ID'
R7451DVN='DEVICE*NUMBER'
R7451FLG='0=NO INFO*1=RAID RANK DATA'
R7451HDD='NUMBER OF*HDDS IN*RAID RANK'
R7451HSS='HDD*SECTOR*SIZE'
R7451NVS='NVS*SPACE*ALLOCATION'
R7451RID='RAID*RANK*ID'
R7451RMR='RECORD*MODE*READ*REQUESTS'
R7451RRQ='RAID*RANK*READ*REQUESTS'
R7451RRT='RAID*RANK*READ*RESPONSE*(MILLISEC)'
R7451RSV='R7451RSV*LOWER*IO*MILLISEC'
R7451SR ='RAID*RANK*FB SECTORS*READ'
R7451SW ='RAID*RANK*FB SECTORS*WRITTEN'
R7451TSP='TRACKS XFERED*TO SECONDARY*PPRC VOL'
R7451WRQ='RAID*RANK*WRITE*REQUESTS'
R7451WRT='RAID*RANK*WRITE*RESPONSE*(MILLISEC)'
R7451XCW='XRC OR CC*CONTAMINATED*WRITES'
R7451XSF='XRC OR CC*SIDEFILE*READ*REQUEST'
The change also populates field R745XRSV, which has been
in dataset TYPE74CA as MXG variable RSV for some time:
RSV ='LOWER*INTERFACE*IO*(MILLISEC)'
And the Real Control Unit ID, R745CUID/R745DCID was added
to both the Cache Control Section and the Cache Device
Data Sections.
This change has been syntax checked, but not yet tested
with records with the PTF installed. This note will be
deleted when the change has been validated with data.
Change 17.160 SAS requires all BY list variables to be in the 1st 4092
ANALRMFR bytes of the physical record, a SAS restriction that I
Jul 11, 1999 had not hit before, but this RMF report program failed
when many reports were requested, as it creates a single
dataset with many variables. By creating a copy of the
data with an added RETAIN statement (as suggested by the
text of the SAS Error message!!):
DATA newcopy; RETAIN list-of-BY-variables; SET oldcopy;
the zY variables are located at the front of the newcopy.
Thanks to Jon Whitcomb, Great Lakes Higher Education Corporation, USA
Change 17.159 RMF Type 99 Subtype 2 variable PCDCLOCK was input as PIB
VMAC99 but it can be negative, so it should have been input IB,
Jul 11, 1999 and it was input from the wrong location, and new fields
added by OS/390 R2.6 are now decoded in dataset TYPE99_2.
Thanks to Ralph Acorn, Safeway, USA.
Change 17.158 Top Secret writes TYPE80 SMF records with RACFTYPE values
VMAC80A of 0,103-105,109, and 255 that caused "SEGMENT SKIPPED"
Jul 11, 1999 messages on the MXG log. This change revised the MXG
logic so only five messages will be printed on the log:
INPUT +RACFDLN @; old
NSKPRACF+1; new
IF NSKPRACF LE 5 THEN new
PUT /' SKIPPED SEGMENT ' RACFEVNT= .... old
Fortunately, the TYPE80xx datasets created are valid.
I'm awaiting test data to decode these TSS-only events,
and this text will be updated when MXG is enhanced to
deal with the TSS-only data records and fields.
Thanks to Marc Matthys, Hudson Williams Europe, BELGIUM.
Change 17.157 The new _STY30TD sort macro for TYPE30TD had SMFTIME in
VMAC30 the BY statement, but it is not kept in the dataset, and
Jul 9, 1999 the BY list is now READTIME JOB JESNR DEVNR INITTIME.
Thanks to Chuck Hopf, MBNA, USA.
Change 17.156 Support for CICS TS 1.3 new field TRNGRPID which was
IMACEXCL inserted in the CICSTRAN record (INCOMPATIBLY), causing
VMAC110 many fields to have incorrect values. IBM did not
Jul 7, 1999 automatically refresh my documentation when they added
the field (which happens to reuse a previously used field
number, 082 decimal). To just skip over the new field,
insert a line with +28 after CLIPADDR $EBCDIC16.
Thanks to Dirk Frijlink, Shell Services International, NETHERLANDS.
Change 17.155 Support for Connect Direct Release 3.2 record 'CT'.
VMACNDM The documentation is wrong in their Appendix pages,
Jul 6, 1999 but MXG tolerates the 3.2 record. There are three
fields added in existing location, one of which,
MXG variable NDMCTDOF, is an offset to a new table,
but I have no example record with that offset present,
so the CTDTOTAL table cannot be decoded until a data
record with that event (process was restarted) is
available.
Thanks to Fiona Crane, IBM United Kingdom, ENGLAND.
Change 17.154 Zero observations in dataset NSPYTIC3 and non-zero in
VMACNSPY NSPYETHR is the result of Change 16.147 overriding
Jul 6, 1999 Change 15.268. The tests for NSPYRECI have been again
corrected, so that for NSPYREL 4.5 and higher, only the
NSPYRECI is used to select ETHERNET versus TIC3, but
4.4 and earlier are protected by using the other flags,
but only for R 4.4.
Thanks to Simon D. Briggs, Allied Irish Bank, IRELAND.
Change 17.153 Variable MCBSCRD, Uncatalog Date, is now created in HSM
VMXGHSM dataset set in dataset MCB from the HSM control file.
Jul 6, 1999
Thanks to Stephen Hahne, Capital One Financial Services, USA.
Change 17.152 Support for MIM's user SMF record is enhanced, and a new
EXTYMIMD dataset is now created, with GDIF benefit counts at the
VMACMIM MIIPLEX LPAR level. The new dataset keeps the old name
Jul 6, 1999 of MIMGDBE, but is at a higher level of detail now, and
the lower level of detail at the enqueue QNAME level that
was MIMGDBE is now created as dataset MIMGDBC.
Thanks to Martyn A. Jones, Chase, ENGLAND.
Change 17.151 TMS records containing DENX='DE'x are undocumented, but
VMACTMS5 appear to be stored in records for Deleted VOLSERs, as
Jul 6, 1999 none of the dates are populated, and Create Job Name is
Jul 11, 1999 DELETE, and Stepname is EBCDIC zeroes. This unexpected
DENX value caused MXG to print a note and a hex dump on
the SAS log, because Density is used to estimate the feet
of tape used, but this note has no real impact on the TMS
datasets created by MXG. To suppress the notes, I added
ELSE IF DENX=0DEX THEN DEN=0; after ELSE IF DENX=0E8X...
-The %%INCLUDE SOURCLIB(EXdddddd); statements should have
been replaced with their _Edddddd macro invocations in
the 16.04 re-architecture; they are now revised so that
those MXG dataset exits can be overridden with MACKEEP=.
Thanks to Andre van de Riet, Hudson Williams Europe, THE NETHERLANDS.
Thanks to Chuck Hopf, MBNA, USA.
Change 17.150 While support for CICS TS 1.3 was in member VMAC110, the
IMACEXCL support for excluded fields was not added to IMACEXCL
Jul 5, 1999 until this change.
Thanks to Harald Seifert, Huk-Coburg, GERMANY.
Change 17.149 The VVDS Key Cluster Name was not converted to blanks
VMACVVDS if the fieldname contained '80'x or '00'x, but now, like
Jul 5, 1999 the other names, the TRANSLATE function converts.
Thanks to Tom Benson, Amdahl U.K., ENGLAND.
Change 17.148 Cosmetic. Label for variables DSG32NAM and DVL32NAM
VMACDCOL are now 'DSG FLAG*SMS 8-WAY OR*32 WAY?' and 'DVL ....'
Jul 5, 1999
Thanks to Grahm West, NPI, ENGLAND.
Change 17.147 MXG 17.03, "BY VARIABLES NOT SORTED IN WORK.SPIN30TD"
BUILD005 error is corrected by moving these two existing lines:
BUIL3005 PROC SORT %VMXGFOR DATA=CVRT30TD OUT=CVRT30TD ;
Jun 30, 1999 BY READTIME JOB JESNR INITTIME DEVTYPE DEVNR;
from before the DATA SPIN30TD; statement, to after the
PROC DELETE DATA=CVRT30TD; statement, and then change
the CVRT30TD in both places in the PROC SORT to SPIN30TD.
Thanks to Dirk Frijlink, Shell Services International, NETHERLANDS.
Change 17.146 Inconsistencies and typos were corrected.
MONTHBLD -The BY list in WEEKBLD-MONTHBLD for TYPE89 caused NOT
WEEKBLD SORTED error because SYSPLEX should have been added as
WEEKBLDT the first var in the BY list after Change 16.xxx was made
VMAC25 to its VMAC.
VMAC80A -The BY list for TYPE70PR caused no error, but was changed
VMACRMFV in WEEKBLD-MONTHBLD by adding LPARNUM LCPUADDR, so as to
VMACTMO2 be consistent with its VMAC.
VMACTMV2 -The BY list for TYPE30_6 could error, so it was changed
Jun 28, 1999 in WEEKBLD-MONTHBLD by inserting SYSTEM after JESNR so as
to be consistent with its VMAC.
-Typo WTY24 was changed to WTY25 in member VMAC25.
-Typo WTY8025 and WTY8X25 were changed to WTY8X24 in
member VMAC80A.
-Typo ZRBSDSIH was changed to ZRBBDSIH in VMACRMFV.
-Typo MONIDBD was changed to MONIDBDS in VMACTMO2.
-Type TMVSSSW was changed to TMVSYSSW in VMACTMV2.
Thanks to Fredie Arie, Lone Star Gas, USA.
Change 17.145 SYNCSORT variables COREREQ and COREUSED are now format as
VMACSYNC MGBYTES (to print KB/MB/GB etc), and their stored length
Jun 28, 1999 is increased from 4 to 8 bytes (because memory values of
16MB or larger cannot be stored exactly in 4 bytes).
If you use PROC APPEND to combine datasets with variables
of different length, you will get an error if you do not
specify FORCE, and even when you specify FORCE (which I
recommend: I think FORCE should be PROC APPEND's default)
you will still end up with the variables as 4-bytes. You
must recreate your "BASE" dataset with corrected lengths:
DATA BASE; LENGTH list-of-variables 8; SET BASE; and then
PROC APPEND won't fail and will have correct length 8.
The TYPESYNC variables that are now length 8 are:
SYNCAVLA SYNCAVLT SYNCREQT SYNCUSEA SYNCUSET SYNDSMVL
SYNVSCOR SYNVSCRT COREREQ COREUSED
Change 17.144 Cosmetic. The deaccumulation logic that was still in the
DIFFNTCP DIFFNTCP member was moved into the _SNTCPSY macro in the
Jun 28, 1999 VMACNTCP member; now, DIFFNTCP member invokes _SNTCPSY.
Change 17.143 The BY list was insufficiently specified and might not
VMAC42 remove duplicates for dataset TYPE42VL (variable SMF42VOL
Jun 24, 1999 was added to _BTY42VL), and for dataset TYPE74PA (macro
_BTY74PA has variables R742PTCN R742PDEV R742PODV added).
Thanks to Chuck Hopf, MBNA, USA.
Change 17.142 VMXGRMFI creates PDB.RMFINTRV with up to 115 workloads,
VMXGRMFI but had uninitialized and missing values if you used the
Jun 24, 1999 new WORKn= variables; those ommissions are now corrected.
-New option PDB=PDB or SMF lets you create RMFINTRV from
either an existing PDB library, or directly from SMF.
-Comments have examples of how to create new workloads:
%VMXGRMFI(WORK1=OMVS/OMVS/66 67/OMVS);
xxxx yyyy nn aaaa
where xxxx = prefix of the variable names to be created,
yyyy = prefix of the label of the created variables
nn = for Compatibility Mode: list of PERFGRPs
that make up this workload.
aaaa = for Goal Mode: list of Service Class Names
that make up this workload.
will create 17 variables named OMVSCPU,OMVSIOTM,... from
PERGRPS=66 or 67 or from SRVCLASS='OMVS' records.
Comments in the member show how you can invoke %VMXGRMFI
multiple times with different INTERVAL= values to create
multiple "RMFINTRV,RMFINTHR,RMFINTDY..." hourly, daily,
summary datasets in the same PDB library, and more.
Change 17.141 -The utility to create the SYSIN for a tailored BUILDPDB
UTILBLDP did not null the _Sdddddd sort macro when you suppressed
Jun 24, 1999 an SMF record. Also, while most product's ID macro name
Jul 9, 1999 is of the form _IDxxxx, a few members had the _xxxxID,
and these exceptions are now known by UTILBLDP logic,
so the correct macro name will be generated.
-We recommend that the ID macros for your user SMF records
be defined in member IMACKEEP, so that anyone running an
MXG TYPExxxx program will get the right records selected.
If you use UTILBLDP and specify USERADD=XXXX/NNN, it will
create the _ID macro, but if you use only USERADD=xxxx,
UTILBLDP will not generate an _ID macro for product xxxx,
and instead expects to find your _ID macro in IMACKEEP.
-A new parameter, IMACKEEP=, has been added, so you can
write all _IDxxxx and _xxxxID macro definitions to a
file, and then use that file as your IMACKEEP member, if
you have not already created the IMACKEEP definitions.
-New parameter RMFINTRV will suppress creation of RMFINTRV
dataset, and is used: if TYPE7072 is suppressed, RMFINTRV
won't be built and warning message will be printed; if
other datasets needed by RMFINTRV are suppressed, the
PDB.RMFINTRV will be built, but warning messages will be
printed on the SAS log.
-If TYPE70PR dataset is detected, ASUM70PR will be added.
-Only the _DIFFxxx's that exist will be created.
-USERADD=6, 30, or 26 caused BUILD005 to fail because the
datasets were deleted; now they are kept for BUILD005.
-IMACKEEP= option will create an IMACKEEP member with your
optional records added, etc.
Thanks to Simon Briggs, Allied Irish Bank, IRELAND.
Change 17.140 The PROC SORT of TYPE30_D had SMFTIME specified twice; in
VMAC30 the _BTY30UD macro and at the end of the BY statement.
Jun 24, 1999 This is not really an error, but now SAS Version 7 will
not permit repeats in the BY list, so the SMFTIME in the
BY statement was removed to satisfy SAS syntax.
Thanks to Andre van de Riet, Hudson Williams Europe, THE NETHERLANDS.
Thanks to Ed Powers, Pearson, USA.
Change 17.139 Documentation. One of the examples had a LIST; statement
SENDDATA that should have been after the FILE LOG; statement, but
Jun 23, 1999 it was after the FILE SMFOUT; statement.
Thanks to Solomon Baker, The Prudential, USA.
Change 17.138 Support for APAR OW37254 "Capacity Upgrade on Demand" for
VMAC7072 type 70 record (COMPATIBLE) adds flag variable STSICPC=Y
Jun 23, 1999 if the STSI facility is available for the CPC, and adds
CPCMODEL (CPC Model Identifier) to TYPE70PR dataset.
A "CPC" is a Central Processing Complex (previous IBM
name: "CEC" for Central Electronic Complex), for example,
a parallel enterprise server 9672 is a CPC, and variable
CPUTYPE='9672'X. An RX6 is a model of 9672, so the new
variable would contain CPCMODEL='RX6' in TYPE70PR.
Note: Change 18.258 added CPCMODEL to TYPE70 dataset.
Thanks to Bob Falla, The Mutual Group, CANADA.
Change 17.137 Format $MG039SN for type 39 Netview record has new value
FORMATS '5'='5:CP-CP' now created; the value is not new but had
Jun 23, 1999 been overlooked.
Thanks to Chris Taylor, Wachovia, USA.
Drove 990 miles to Telluride BlueGrass Festival, Telluride, Colorado.
Four days, forty groups, four hundred tunes - a great show!
Change 17.136 TCP TELNET Server variable TELLOGFT in dataset TYPETCPT
VMACTCP is created by IBM with date format of yyyydddF, which is
Jun 15, 1999 not supported by the SMFSTAMP8. format (which expects
Jul 29, 1999 the IBM SMF "century bit" format of 0cyydddF). With a
raw value 1999099F, SMFSTAMP8 creates year 3899 for date!
The SMFSTAMP8. input was replaced with the algorithm from
member YEAR2000 to support the unexpected date value.
Jul 29: Removed PUT TELLOGTM= ; debugging statement.
Thanks to Colin Bowen, Old Mutual, SOUTH AFRICA.
Thanks to Freddie Arie, Lone Star Gas, USA.
Change 17.135 Support for NETSPY type I Telnet Session record creates
EXNSPYTE new NSPYTELN dataset with written at interval and session
FORMATS end, with bytes in/out, smooth time, IP addresses and the
IMACNSPY LUNAME of the session.
VMACNSPY
VMXGINIT
Jun 10, 1999
Thanks to Stuart Robertson, GIO, AUSTRALIA.
Change 17.134 MXG message ERROR - STID=123 FOUND WITH SKIPPED FIELDS
VMAC110 is an MXG error. The statement SKIP=STILEN-100; in the
Jun 10, 1999 ELSE IF STID=123 THEN DO; must be SKIP=STILEN-104;
Thanks to Jean-Pierre Ravera, Michelin, FRANCE.
Change 17.133 Using TYPSCIMS caused errors (but TYPECIMS was okay).
VMACCIMS The _BIMFDB2 by-list macro must have PLANNAME instead
Jun 10, 1999 of DBDNAME, and variable DBDSEQNR must be added to the
KEEP= list for the CIMSDB2 dataset
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 17.132 Cosmetic. Temporary variables MNSMFTME and MXSMFTME are
VMACSMF now formatted DATETIME21.2, so they will be readable if
Jun 10, 1999 printed on the SAS log due to an error condition.
Change 17.131 If you used VMXGSUM with the NORM= argument to normalize
VMXGSUM values, and if the denominator was zero, you got DIVIDE
Jun 10, 1999 BY ZERO. Now, the divide is protected. No error was
reported; the exposure was observed and protected.
Thanks to Chuck Hopf, MBNA, USA.
Change 17.130 RMM Extract EDGHSKP, support for its four date formats:
IMACEDGR Julian 1999/365 YYYY/DDD JULIAN7.
VMACEDGR ISO 1999/12/31 YYYY/MM/DD YYMMDD10.
Jun 9, 1999 European 31/12/1999 DD/MM/YYYY DDMMYY10.
Jun 24, 1999 American 12/31/1999 MM/DD/YYYY MMDDYY10.
Jun 29, 1999 is implemented in this revision. Originally, dates were
Jul 9, 1999 stored as character fields, and MXG 16.16 converted them
into date variables (so you can count number-of-days),
but MXG 16.16 only supported the ISO format. All four
date formats are now supported, but only JULIAN and ISO
are supported automatically, by default. So if your RMM
extract dates are European or American format, you must
update member IMACEDGR and change the default definition
of MACRO _EDGRDTE YYMMDD10. % to the desired format (or
you could put that redefinition in member IMACKEEP).
-RMM Extract Type='V' records (EDGHSKP utility) caused
INVALID DATA FOR RVLCDATE. MXG was off by 6 bytes. The
line with RVCFTIME $EBCDIC6. /*DSN*CREATE*TIME*/
must be deleted (it's decoded by the following HH/MM/SS).
-Variables RDRETDAT/RVRETDAT may contain a date, but can
be CYCL/nnnnn or WHILECATLG, so new variables RDRETCHR/
RVRETCHR now contain the character string of their date.
If the RDRETDAT/RVRETDAT are not valid dates, they will
be missing values, but RDRETCHR and RVRETCHR will
contain the original string value.
-Times are now calculated IF SS GE 0 THEN ... instead of
IF SS GT 0 THEN ... as zero is a valid value for SS; the
test is to protect if SS/HH/MM are missing, not zero.
-Variables RVSTBIN and RVOBIN are changed from character
to numberic, as they are bin numbers.
Thanks to Darlene E. Wnukowski, Schreiber Foods, Inc, USA.
Thanks to Jan van Lent, Hudson Williams Europe, GERMANY.
Change 17.129 SAP R/2 5.0i under CICS 4.1 at one site created type 110
VMAC110 subtype 0 journal records with JCRLL=30, which was not
Jun 9, 1999 not expected nor protected in VMAC110 for 4.1, so the
three statements IF JCRUTRID='SA' THEN DO; are changed
to IF JCRUTRID='SA' AND JCRLL GE 250 THEN DO;
Thanks to W. Weber, V.I.S. Informationssysteme Gmbh, GERMANY.
Change 17.128 Utility to produce EBCDIC hex dumps under ASCII SAS was
UDUMPEBC enhanced with OUTPAGES= operand to limit the number of
Jun 9, 1999 pages printed. I needed this so I don't have to print
all 32760 bytes of a type 110 record if I don't need it!
Change 17.127 Support for APAR OW29849, which adds variables counting
VMAC88 writes and suspends by the system logger; this APAR also
Jun 9, 1999 improves the write performance of IXGWRITE by offloading
asynchronously to overlap I/O.
======Changes thru 17.126 were in MXG 17.03 dated Jun 8, 1999======
Change 17.126 Boole and Babbage has provided an enhancement to their
ASMMNVW MainView history file decompression SAS Infile Exit that
Jun 7, 1999 decompresses on the data on the fly. The new algorithm
supports both the original implementation as well as the
current compression implementation.
Change 17.125 Sample ANALPATH report expected no more than 16 LCUIDs on
ANALPATH on CHPID, and was revised in MXG 17.03 to handle up to 32
Jun 7, 1999 but the report was revised after 17.03 was built to only
Jun 9, 1999 print a line for LCU17-LCU32 if there were 17 LCUIDs.
Thanks to Bruce Koelker, Gates Rubber Company, USA.
Change 17.124 Support for TYPE 42 Subtypes 7 NFS File Usage and subtype
EXTY42NF 8 NFS User Session Statistics, creates new TYPE42NF and
EXTY42NU TYPE42NU. TYPE42NF File has only the end time; there is
FORMATS no OPEN/Start time, but includes counts in bytes and I/O
IMAC42 blocks. TYPE42NU User Session interval record has start
VMAC42 and session end times, elapsed/active durations, bytes
VMXGINIT read/written for network/files during the session. Both
Jun 5, 1999 TYPE42NF and TYPE42NU contain RACFUSER,RACFGRUP, the unix
Process and Group Ids, IP Address of the client host and
the client host name. Some field names in subtype 7 are
the same as existing subtype 15 field names, so some new
variables are named S42xxx instead of SMF42xxx. Two new
formats were added to decode NFS variables. These two
subtypes have existed since 1994, but no one noticed, as
they are only documented in "NFS Customization and Ops"
manual; they are not listed in the SMF manual!
Thanks to Mat J.H. Elbersen, Rabobank, THE NETHERLANDS.
Change 17.123 Support for SoftAudit Version 7.1 COMPATIBLY added the
VMACSFTA CPU Product Group and CPU Product Version variables to
Jun 4, 1999 the SOFTPROD Installed Products dataset.
Change 17.122 Support for STK's NearOAM V2.2 COMPATIBLY added variables
VMACNOAM like intercept and scheduling datetimestamps, the name of
Jun 4, 1999 the requesting job, name of the object, ... to TYPENOAM.
Thanks to Fiona Crane, Sun Alliance Insurance Group, ENGLAND.
Change 17.121 Variable SMF88AWB was mis-documented by IBM as RB8., but
VMAC88 it is a PIB8. Variable SMF88AIT was a character string,
Jun 4, 1999 but is actually a TODSTAMP value, so it is now decoded as
numeric and formatted as DATETIME21.2. The subtype 11
record has an observation written at the end of each
interval with blank SMF88STN (structure name), with only
SMF88ALS (log streams connnected at end of interval).
The TYPE8811 dataset now has variable SMF88LTD (interval
end datetimestamp) kept from the preceding subtype one,
since there is no interval end value in TYPE8811. Also,
there is no interval start nor interval duration in the
subtype 1, so the rates cannot be calculated without an
extra de-accumulation step to construct the duration of
the interval. Pending IBM's reply as to whether they
will correct the problem, and due to overwhelming nonuse
thus far, I have not added deacculumulation yet.
Since SMF88LTD is on the GMT clock and since there is no
GMT offset in the record, the times cannot be converted
to local time of day.
Thanks to Chuck Hopf, MBNA, USA.
Change 17.120 For Goal Mode (a/k/a Workload Manager Mode), the PERFGRP
VMAC30 variable had value of zero in type 30s but missing in 72
Jun 2, 1999 so it is now set missing in type 30s, so it won't be
confused with Compat Mode PERFGRP=0, and so that BY lists
can contain PERFGRP SRVCLASS to merge step interval data
with either TYPE72 or TYPE72GO data. To know from the
job's TYPE30s/PDB.JOBS datasets if a job ran under Goal
Mode or under Compat Mode, you can now test IF PERFGRP=.
(or alternatively, IF SRVCLASS GT ' ') and both are true
for Goal Mode) and both are false if Compat mode.
Change 17.119 SyncSort supports up to 32 sort work areas, but MXG had
VMACSYNC only decoded the first twelve. Now all thirty-two sets
Jun 2, 1999 of the eight variables are created for all possible.
Thanks to Chairat Tiajanpan, KTB, THAILAND.
Change 17.118 Minor cleanup. The default DDNAME for the CIMSTEMP
TYPSCIMS temporary dataset is now //WORK instead of //PDB, and
VMXGINIT member TYPSCIMS now invokes _S macros to sort the
Jun 1, 1999 CIMSDBDS, CIMSDB2, and CIMSPROG datasets into the default
ddname of PDB.
Thanks to Carl Meredith, SAS Institute, USA.
Change 17.117 Sample RACF Violation reports, originally posted on MXG-L
ANAL80A use the TYPE80A and TYPE8002 datasets for reports.
May 31, 1999
Thanks to Brian Cavanaugh, Key Services Corporation, USA.
Thanks to Sean Sullivan, Key Services Corporation, USA.
Change 17.116 Support for APAR OW37091 for Measured Usage (MULC) adds
VMAC89 support for Concurrent CP Upgrades ("the capability to
May 31, 1999 increase the number of usable CPs without requiring a
hardware IML or operating system IPL"). New fields are
added to the ID section, so they are kept in both usage
and state datasets: Type/Model/Manufacturer/Plant/etc,
counts of the configured and standby CPUs, and the value
of SMF89CPC, the "CPU Capability" value, an integer that
specifies the CPU capability of one engine. While there
is no formal description of the algorithm used to create
the value, CPU Capability Value is used as an indication
of the capability of this CPU relative to the capability
of other CPU models. Then to adjust that single engine
Capability value to get the actual value for your number
of CPs in use, you use the Multiprocessing CPU Capability
Adjustment Factor for that number of CPs. There are up
to fifteen factors, each containing the percentage of the
single engine CPU capability for that number of CPs: MXG
variable SMF89MA1 contains the percentage for 2CPs, and
SMF80MAF contains the percentage if there are 16CPs. The
new information comes from the Store System Information
Instruction (STSI).
Change 17.115 IMF/CIMSTRAN variable FLGSPCHR decoded 'W' for WFI, but
FORMATS did not know that value 'Q', documented as "Pseudo WFI",
VMACCIMS but also called Quick Restart, exists also. Now the MXG
May 31, 1999 format MGIMFCS decodes both Q and W in FLGSPCHR.
Thanks to Ulrich Dillenberger, BMC Software, GERMANY.
Change 17.114 Change 17.037 was wrong for TANDDISK for TANDEM G05 plus.
VMACTAND Two IF OPSYSVER GE ... should end with "@;", not "END;".
May 28, 1999 The ERROR message is INVALID DATA FOR END ....
If you pull the data files from the Tandem System using
UserAccess - Stream Mode, you get the "unstructured" file
format discussed in Change 15.119, and you will have to
EDIT and use the UTANDSTR utility to double process the
records to create the "structured" records to be read.
Change 17.113 Variables SMF6PRMD (Print Mode) and SMF6USID (User) are
BUILD005 now carried into the PDB.PRINT dataset in BUILDPDB/PD3
BUIL3005 logic, by adding them to the _PDB6 list of variables to
May 28, 1999 be kept from TYPE6 into PDB.PRINT.
Thanks to Bob Falla, The Mutual Group, CANADA.
Change 17.112 MXG 17.02 only, cosmetic. WARNING: NOT ALL VARIABLES
VMAC80A KW24MO00-KW24MO50 WERE FOUND is eliminated by changing
May 27, 1999 KW24MO50 to KW24MO18 in the KEEP= list, but there was no
impact of this warning, as there were only 18 to keep.
Thanks to Jos Schwab, Newell Company, USA.
Change 17.111 Variables TAPEDRVS/TAPE3420/TAPE3480/TAPE3490/TAPE3590 in
BUIL3005 observations in TYPE30_V, TYPE30_4 and TYPE30_5 datasets
BUILD005 count only the number of tape devices allocated in each
EXTY30TD physical step record, and that is still true after this
FORMATS change. But this redesign in BUILD005/BUIL3005 will now
IMAC30 count the number of unique tape drive addresses that were
SPUNJOBS allocated by the step (across all multiple records) in
VMAC30 those TAPExxxx variables in the PDB.STEPS dataset.
VMXGINIT Note, however, that even the corrected TAPExxxx count for
May 27, 1999 the step is not necessarily the number of concurrent tape
Jun 7, 1999 drives that were used by the step, but is just the total
number of drives allocated by the step: you cannot tell
from the step data whether those allocations were
sequential or concurrent. In addition to changes in the
BUILD005/BUIL3005 members, a new "temporary" dataset
WORK.TYPE30TD is created by VMAC30, with one observation
for each tape DD segment, that is used to correctly count
tape drives. This also required a new SPIN.SPIN30TD
dataset to hold these new data for incomplete jobs, and
revisions to member SPUNJOBS, as well as logic to convert
spun Step records tape drive counts to the new design.
And macros _S30 and _N30 were corrected in member VMAC30
so they include TY30UD and TY30UV datasets that had been
overlooked.
Note 10/19/2000: The TAPEDRVS/TAPExxx variables were
removed from the SPINxxxx datasets (because they were the
old, probably wrong values), and were relocated into the
SPIN30TD dataset (tape allocation count by DEVNR) that
will be used tomorrow to put TAPEDRVS/TAPExxxx variables
back in the output PDB.STEPS and PDB.JOBS.
Change 17.110 Variables EXCPNODD/IOTMNODD are now corrected, and the
BUILD005 observations with MULTIDD='Y' in PDB.STEPS dataset will
BUIL3005 no longer exist (although they still will exist in the
SPUNJOBS TYPE30_4 and TYPE30_5 datasets). Instead of there being
May 25, 1999 multiple observations for those steps, there now is only
one observation for each step in PDB.STEPS, so the number
of observations in PDB.STEPS will be reduced by this fix.
This redesign sums the STEP I/O counts from the multiple
step records to create only one observation per step, and
it re-calculates the NODD "Not Recorded in a DD" values.
Previously, the NODD numbers were TOTL - TODD, but when
the step had MULTIDD='Y' records, the TODD counts in the
"real" step record (the one with MULTIDD=' ') did not
include the TODD counts from the MULTIDD='Y' records, so
the NODD values in the MULTIDD=' ' observation were too
high, and the NODD values in the MULTIDD='Y' observation
were missing (because the TOTL values exist only in the
MULTIDD=' ' record). The values of the NODD variables in
the PDB.JOBS dataset were also incorrect, because they
were sums of the incorrect NODD values from PDB.STEPS.
This internal redesign splits the STEPS dataset into
STEPS and STEPSIO, with all EXCP/IOTM counts in STEPSIO,
which is VMXGSUM'd and merged to re-created STEPS with
NODD calculations now based on the TODD sum from all
records, and so there is no longer any need to create the
MULTIDD='Y' observations in the PDB.STEPS dataset.
This change was precipitated by the analysis of a step
record from TSO-in-batch that executed DB2 that had very
large values for EXCPNODD and IOTMNODD. The large NODD
counts were completely valid, had nothing to do with any
MULTIDD='Y' steps, and in fact were caused a design flaw
in the site's DB2 QMF exit that caused repeated loads of
the same module from a linklist library, and all linklist
accesses are captured by the NODD counts.
But before I knew that, I had asked Chuck Hopf to scan
his PDB for executions under TSO that called DB2 to see
if DB2 might be involved in high NODD counts. While his
data proved high NODD counts were not DB2 related, he did
serendipitously find MULTIDD='Y' steps with the incorrect
NODD counts that led to this redesign.
Thanks to Kirk Hampton, Texas Utilities, USA.
Change 17.109 Typo and a logic error that have been in VMXGHSM for some
VMXGHSM time were detected and corrected. The corrections:
May 25, 1999 IF MCPDGNCT=. THEN MCPDGNCT=0 instead of MCTDGNCT, and
P2=P2+14; instead of P2=P2+(14C);
Thanks to Neville Wright, TELSTRA, AUSTRALIA.
Change 17.108 Type 39 records may cause SHORT RECORD messages and zero
VMAC39 observations output, depending on APARs you have applied,
May 21, 1999 because Change 16.258 was incorrect.
The ELSE DO; group must be relocated to be before the
first "IF OFFPROD-3-COL+1 GE 8 THEN INPUT" statement.
And APPN fields may be incorrect, because the INPUT after
the second "IF OFFPROD-3..." statement should have offset
values of @61, @65, and @67 vice @53/@57/@59.
Thanks to Jim Tintle, Mack Trucks, USA.
Change 17.107 Support for OS/400 V4.3.0 (compatible) was in MXG 16.16,
VMACQAPM as a comparison of the 4.3 and 4.2 record formats found
May 21, 1999 no changes.
Change 17.106 PDB.ASUMTAPE observations with STATUS='MISSEDMNT' due to
ASUMTAPE to the fuzzyness of sampled mount times in MXGTMNT are
May 20, 1999 now STATUS='MATCHED', by changing the TYPETMNT timestamp
used in sorting the Allocate, Mount, and Dismount events.
The problem is that the timestamp of the TYPE21 record
is exact, whereas the TMNTTIME/TENDTIME (mount start and
mount end times) are up to 2 seconds later (with MXGTMNT
sampling default value) than their real event time.
Using TENDTIME gave good results, but when TENDTIME was
later than TY21TIME, the sequence was A/D/M and the mount
was missed. By using SMFTIME=MAX(TMNTTIME,TENDTIME-2),
in the step that creates MOUNT dataset, those now match.
-Status of known causes of STATUS='MISSEDMNT':
-tape ape "knocking-down" the outstanding mount for a
specific volser by mounting the wrong VOLSER, perhaps
by accident, perhaps intentionally so that the message
"Mount Pending For 10 Minutes" won't be created, which
stops the MVS console operator from harrasing tape ape.
Tape apes know they can put in any VOLSER and that MVS
Volume Verification will reject and dismount the wrong
tape (so the job doesn't fail) and that the new mount
event for the original VOLSER resets mount pending!
In this case, MXGTMNT still was in mount pending state,
so the second mount does not reset the TMNTTIME start of
mount pending, but the TENDTIME end of mount does not
occur until after the bad mount was dismounted and the
correct VOLSER was verified, so the TY21TIME is in the
middle of the mount start and end times:
Wrong Vol Right Vol
TMNTTIME TY21TIME TENDTIME TY21TIME
10:50:51.26 10:52:15.96 10:52:39.00 10:58:29.11
ASUMTAPE creates an observation for the dismount of the
wrong volume with STATUS=MISSEDMNT, but I can't yet see
how to status that mount as a "wrong volume mount", or
even if that is needed! ASUMTAPE also creates the real
observation for the mount of the right volume, and its
TAPMNTTM=TENDTIME-TMNTTIME does include all of the delay
caused by mounting-the-wrong-volume, because the real
mount (and this job) is still pending until the correct
VOLSER is mounted).
-one mount of a tape by one job that was not used but the
tape was then picked up (without a new mount event, as
the tape was in the drive) by a second job. The first
mount is output to EXTRAMNT dataset rather than ASUMTAPE
and the second job has ASUMTAPE obs with MISSEDMNT.
-tape swap (an I/O error caused your VOLSER to be moved
to a different physical tape drive) creates an extra
mount event for each swap, and MXG properly creates an
obs in ASUMTAPE, so these mounts are true, counted mount
events, but they were not caused by the job.
-I may investigate if a further post-processing step is
needed to merge TYPETSWP to identify mounts caused by
tape swaps, to detect passing of an unused tape from one
job to another, or to identify "kicked-down" mounts.
-Note that observations in PDB.ASUMTAPE with MISSEDMNT for
STATUS are still completely valid tape mount events, with
true dismount time, bytes, etc,; it just that the start
and end of tape mount time are not known because there
was no MXGTMNT mount event found.
Change 17.105 TYPE39 variable LSESFQLN should have been &PIB.1. instead
VMAC39 of &PIB.2., which caused LSESFQNM to be missing its first
May 20, 1999 byte.
Thanks to Anthony Pagliano, Summit Bank, USA.
======Changes thru 17.104 were in MXG 17.02 dated May 19, 1999======
Change 17.104 DF/SMS 1.4 additional variables UMUSRSIZ, UMCMPSIZ, and
VMACDCOL UMFRVOL may be missing because the tests for existence
May 19, 1999 should have been GE 8 for the first two, and GE 20 for
the DO group for UMFRVOL.
Thanks to Dave Cogar, U.S. Department of Transportion, USA.
Change 17.103 TCP records for APICALLS have invalid APISTART values
VMACTCP in the IBM record. While contacting IBM, the INPUT was
May 19, 1999 changed to APISTART ?? SMFSTAMP8., inserting the double
question marks to suppress the error message and dump.
Nov 3, 1999 update: APAR PW29974 and PQ32322 document
negative values for APICALLS bytes in and bytes out.
Thanks to Sudie Wulfert-Schickedanz, Anheuser-Busch Companies, USA.
Change 17.102 TMS variable DEVTYPE was blank for 3490-E tape volumes;
VMACTMS5 a new test IF TRTCH=0E1X THEN DEVTYPE='36TRK-E'; was
May 18, 1999 added to decode them.
Thanks to Sal Fazzino, Excelis, Inc, USA.
Change 17.101 Support for NTSMF Version 2.3 (COMPATIBLE), and support
EXNTSQAM for new Seagate, Site Server, and SQLSERVER 7 objects:
EXNTSQBD
EXNTSQBM Dataset Object Name Vars
EXNTSQCM
EXNTSQDA QUOTAS QUOTAS 5
EXNTSQGS SEAGATE SEAGATE INFO 13
EXNTSQLA SITESVAU SITE SERVER AUTHENTICATION SERVICE 32
EXNTSQLO SITESVCO SITE SERVER CONTENT DEPLOYMENT 34
EXNTSQMM SITESVLD SITE SERVER LDAP SERVICE 86
EXNTSQRA SITESVMB SITE SERVER MESSAGE BUILDER SERVICE 7
EXNTSQRD SQLACCES NT SQLSERVER7 ACCESS METHODS 20
EXNTSQRL SQLBKPDV NT SQLSERVER7 BACKUP DEVICE 1
EXNTSQRM SQLBUFMG NT SQLSERVER7 BUFFER MANAGER 18
EXNTSQRS SQLCACMG NT SQLSERVER7 CACHE MANAGER 5
EXNTSQSE SQLDATAB NT SQLSERVER7 DATABASES 22
EXNTSQSS SQLGENST NT SQLSERVER7 GENERAL STATISTICS 3
FORMATS SQLLATCH NT SQLSERVER7 LATCHES 4
IMACNTSM SQLLOCK NT SQLSERVER7 LOCKS 6
VMACNTSM SQLMEMMG NT SQLSERVER7 MEMORY MANAGER 14
VMXGINIT SQLREPAG NT SQLSERVER7 REPLICATION AGENTS 1
May 17, 1999 SQLREPDI NT SQLSERVER7 REPLICATION DIST. 3
SQLREPLR NT SQLSERVER7 REPLICATION LOGREADER 3
SQLREPME NT SQLSERVER7 REPLICATION MERGE 3
SQLREPSN NT SQLSERVER7 REPLICATION SNAPSHOT 2
SQLSTATS NT SQLSERVER7 SQL STATISTICS 7
SQLUSRSE NT SQLSERVER7 USER SETTABLE 1
Only dataset QUOTAS has been data-tested, but there is a
lot of new NT measurements in this change!
-Additionally, the WEBSERVR dataset is now deaccumulated,
as suggested by Jim Quigley's posting to MXG-L LISTSERV.
These IIS counters are accumulated in NT 4.0, but are
supposedly corrected in NT 2000, so the deaccumulation
(done in the _SNTWEBS sort macro, where all DIF() code
is now located) may need to be suppressed in NT 2000.
Change 17.100 Support of i-data afp-software SMF record. The dataset
EXTYIDAP TYPEIDAP has counters of pages and bytes printed by
FORMATS i-data, for distributing AFP print thru the enterprise
IMACIDAP network, using commodity laser printers.
TYPEIDAP See their homepage at www.i-data.com.
TYPSIDAP
VMACIDAP
VMXGINIT
May 15, 1999
Thanks to Engelbert Smets, Provinzial Versicherungen Duessl,GERMANY.
Change 17.099 Support of Lexmark MarkVision "job statistics file" for
EXTYMRKV printing on Windows, OS/2 and Windows-NT platforms. The
FORMATS dataset MARKVISN created counts sheets and impressions,
IMACMRKV by treys and feeders and by auto and manual and by color
TYPEMRKV of toner. Each observation is either a successful print
TYPSMRKV or an error condition (in which case varible ERROR will
VMACMRKV be blank and most fields will be missing. This code has
VMXGINIT only been tested executing under ASCII reading ASCII data
May 14, 1999 but the program should work under EBCDIC reading the raw
datafile that were sent to MVS (and converted to EBCDIC).
Thanks to Martin Laursen, Danske Data, DENMARK.
Change 17.098 Enhanced creation of RMFINTRV now permits over 100 unique
VMXGRMFI workloads to be defined.
May 14, 1999
Change 17.097 MXG 17.01 only. Some dataset names for AICS and APAF
VMACAICS were misspelled in their _Wdddddd macro definition (but
VMACAPAF if you used the _Sdddddd or TYPSxxxx member to sort from
May 14, 1999 //WORK to the //PDB, there was no error).
Thanks to Freddie Arie, TXU, USA.
Change 17.096 Support for CICS TS 1.2 Journal segment for SAP. CICS TS
VMAC110 1.2 has two different formats of Journal data in SMF 110,
VMXGINIT and only GLRHTYPE=1 was previously validated, but now the
May 14, 1999 GLRHTYPE=2 segment (which happens to be used by SAP) are
May 17, 1999 recognized and decoded, eliminating "SOR TYPE NOT ONE"
MXG error message and hex dump of the record.
This change also corrected a 17.01-only error: the macro
&WCICACC was repeated inside other _WCICxxx definitions,
and &WCICJRN is now defined in VMXGINIT.
Thanks to Roy Pennington, Vertex, ENGLAND.
Change 17.095 In an undocumented, verbal change to SYNCSORT records,
VMACSYNC new variable MAXSORT='Y' or blank if the MAXSORT option
May 13, 1999 was specified for a sort.
Thanks to John Parla, Cigna, USA.
Change 17.094 Extensive additional decoding of RACF bit flags create
FORMATS new one-byte character variables to identify the keywords
VMAC80A specified, keywords ignored, keywords in error, and many
May 13, 1999 other options of RACF events. Since each RACF command
has a unique set of keywords, and there can be many in
each single record, the naming convention and variable
labels convey the keyword specified/ignored etc. The
naming convention is KWnnSPmm for Specified Keywords,
KWnnIGmm for Ignored Keywords, and similar names for
other options, class names, and other flags. For example
the TYPE8019 (PERMIT) command has fourteen keyword
specification variables, named KW19SP00-KW19SP13,
and the corresponding keyword ignored variables are
named KW19IG00-KW19IG13:
KW19SP00='KEYWORD*SPECIFIED*CLASS?'
KW19SP01='KEYWORD*SPECIFIED*ID?'
KW19SP02='KEYWORD*SPECIFIED*ACCESS?'
KW19SP03='KEYWORD*SPECIFIED*FROM?'
KW19SP04='KEYWORD*SPECIFIED*DELETE?'
KW19SP05='KEYWORD*SPECIFIED*FCLASS?'
KW19SP06='KEYWORD*SPECIFIED*VOLUME?'
KW19SP07='KEYWORD*SPECIFIED*FVOLUME?'
KW19SP08='KEYWORD*SPECIFIED*GENERIC?'
KW19SP09='KEYWORD*SPECIFIED*FGENERIC?'
KW19SP10='KEYWORD*SPECIFIED*RESET?'
KW19SP11='KEYWORD*SPECIFIED*WHEN?'
KW19SP12='KEYWORD*SPECIFIED*RESET(WHEN)?'
KW19SP13='KEYWORD*SPECIFIED*RESET(STANDARD)?'
KW19IG00='KEYWORD*IGNORED*CLASS?'
KW19IG01='KEYWORD*IGNORED*ID?'
...
KW19IG13='KEYWORD*IGNORED*RESET(STANDARD)?'
About 800 new variables are created, with a max of 205 in
one dataset (TYPE8024), but at one byte per variable, the
impact is minimal. If you use PROC PRINT SPLIT='*', the
variable label prints as column heading and you can see
which keywords were specified/ignored/errored/etc. You
can look at member DOCVER to see what variable name is
created for each keyword, or you can use PROC CONTENTS to
see the label, but the variable label names the contents.
This code has NOT been validated, and there was lot's of
opportunity for typos, so please verify with known RACF
events that all of the bits are mapped correctly.
-One new format was added and old one enhanced.
Thanks to Michael Brench, National Bank of Australia, AUSTRALIA.
Change 17.093 The LRECL=xxx value for each Tandem file was specified on
VMACTAND each INFILE statement, but that was removed so that you
May 11, 1999 don't have to modify the VMAC for new Tandem versions;
instead you can use the LRECL of the dataset on MVS or
a FILENAME statement with LRECL=xxx to specify the LRECL.
Thanks to Kim S. Johnson, NationsBank, USA.
Change 17.092 Support for SOFTAUDIT 6.1.2 (COMPATIBLE) added three new
VMACSFTA fields at the end of the Installed Products File.
May 11, 1999
Thanks to Thomas Heitlinger, FIDUCIA IT AG, GERMANY
Change 17.091 Support for TELEVIEW 4.3 (INCOMPATIBLE). Field TELUSER
VMACTELE was expanded to 9 bytes and 3 bytes were inserted in the
May 10, 1999 subtype 1 and subtype 2 record. In addition, while the
May 18, 1999 variable SMFTIME has been accurate, none of the internal
datetimestamps were validated and all were wrong, but now
are corrected and Y2K compliant!
Thanks to Yvonne McDonough, USDA NITC, USA.
Change 17.090 Some QXxxxxxx variables in DB2STATS were misaligned and
VMACDB2 wrong, starting with QXRLFDPA. The stat code was revised
May 10, 1999 and the line with +4 after QXDEGENC was replaced with the
input of QXRLFDPA and its associated +3, and the tests
for length were corrected: the 256 to 252, 284 to 280,
and 316 to 312. Only DB2STATS was affected; the QXxxxxxx
variables in DB2ACCT were not misaligned.
Thanks to Ken Michalik, Kraft Foods, Inc, USA.
Change 17.089 Unused.
Change 17.088 Variable BANDTIME in NPM dataset NPMINNSA is missing.
VMAC28 The equation should be BANDTIME=DHMS( ... BANDTTME);
May 10, 1999 instead of the typo BANDTIME=DHMS( ... BANDTIME);.
Thanks to Mr. Holscher, BWS Munster, GERMANY
Change 17.087 Documentation. If your DB2 datasets are on tape, you
ANALDB2R must specify DATASET=DDNAME, arguments and PDB=PDB to
May 6, 1999 prevent TWO OPEN SEQUENTIAL DATASETS ON ONE TAPE error.
If your DB2ACCT, DB2ACCTP, and DB2ACCTB datasets are on
tapes with DDNAMES of DB2ACCT, DB2ACCTP, and DB2ACCTB,
then you would specify
%ANALDB2R(
PDB=PDB,
DB2ACCT=DB2ACCT,
DB2ACCTB=DB2ACCTB,
DB2ACCTP=DB2ACCTP,
... );
The documentation in the comments has been revised;
the code has been in place since version 14.14!
Thanks to Alan Fendler, Pershing, USA.
Thanks to Harold Wentz, Pershing, USA.
Change 17.086 The DCOLLECT example had LRECL=644 in comments, but you
JCLDAYDS must specify LRECL=32756. With LRECL=644, DCOLLECT sets
May 6, 1999 a Return Code of 4 and a message that it encountered a
record that was too long to process, but does not ABEND,
and some of the records are not created. (Fortunately,
the long records are the SMS structure definitions for
Storage Class, Storage Group, etc., rather than the real
Dataset and Cluster records used for accounting/sizing.
Thanks to Chuck Hopf, MBNA, USA.
Change 17.085 Support for RACAL IT Security's SRM product for HSM SMF
EXSRMHAP record creates three new datasets:
EXSRMHDV SRMHSMAP SRM HOST SECURITY MODULE APPL
EXSRMHNU SRMHSMDV SRM HOST SECURITY MODULE DEVICE
FORMATS SRMHSMNU SRM HOST SECURITY NULL RECORD
TYPESRMH The Null Record dataset is created from records that have
TYPSSRMH no Device nor Application segment, just a 36-byte record;
VMACSRMH it is not clear of what use they may be.
VMXGINIT
May 6, 1999
Thanks to Choo Hui Chuin, Maybank, MALAYSIA.
Change 17.084 -The %INCLUDE of IMACIMSA should have been just before the
TYPEIMSA MACRO _VARxxxx definition, and has been moved, but there
VMACIMSA was no error since IMACIMSA is re-included by TYPEIMSA.
May 15, 1999 -The _KIMSBMP macro was added to the step that builds the
BMPS dataset so that full tailoring is supported.
Thanks to Chris Weston, SAS Institute, USA.
Change 17.083 The label for variable STRTTIME was changed to INTERVAL
VMAC25 START TIMESTAMP because in BUILDPD3, the type 25 label
May 4, 1999 was overriding the CICS and other Interval datasets.
I should have chosen a different name for the JES3 TYPE25
dataset, but its too late for that now, but changing its
label will eliminate the JES3 confusion.
Thanks to Neal Musitano, Jr., Department of Veterans Affairs, USA.
Change 17.082 DATASET PDB.TYPE200 NOT FOUND results when TYPSIDMS is
VMACIDMS used; the four lines _STY200, _STY201, _STY202, _STY203
May 4, 1999 are deleted as the TYPE200 members were IDMS 10.2 only.
Thanks to Alan Deepe, Perot Systems Europe, ENGLAND.
Change 17.081 The invocation of the sort macro, _STMVS, should have
TYPSTMV2 been spelled _STMV2 in member TYPSTMV2.
May 4, 1999
Thanks to Kathy Gordon, General Nutrition, Inc, USA.
Change 17.080 Comments only were changed, on how to handle CADI record
IMACCADI with ID=239 instead of ID=6. Those comments are now the
May 4, 1999 MXG Note Example of using IMACFILE to change ID number.
Thanks to Bob Cooney,
======Changes thru 17.079 were in MXG 17.01 dated May 3, 1999======
Change 17.079 Yet another enhancement to the UTILBLDP utility that will
UTILBLDP create the //SYSIN file BUILDMXG to build your tailored
May 1, 1999 PDB. This iteration detects if CICS, DB2, TMNT, or TY74
May 14, 1999 data was requested, and if the ASUM member appropriate to
that data are not included, they will be added with a new
comment "/*RECOMMENDED*/". New options to run BUILDMXG
instead of creating the file, INCLAFTR= to name members
to be included after BUILDMXG runs, and SPINUOW to pass
the SPIN count for ASUMUOW build, if requested.
Change 17.078 Change 17.029 was also needed in MONTHBLD; two lines with
MONTHBLD non-blank character in column 72 caused failure, even tho
May 1, 1999 the syntax should be valid.
Thanks to David Gibney, Washington State University, USA.
Change 17.077 Chuck discovered that some PDB.ASUMTAPE observations with
ASUMTAPE STATUS=MISSEDMNT had TMNTTIME incorrect and traced some
May 3, 1999 to be caused by "multi-unit,never-used" tape mounts:
May 20, 1999 Using UNIT=(TAPE,2) allocates two tape drives, and
See 17.106 two scratch tapes will be initially mounted. When a
volume fills, writes switch to the second drive while
a new tape is mounted on the first drive, so at CLOSE
of the DDNAME, there will always be a hanging mount
that was never used and never opened. But MXGTMNT
saw that mount, and at deallocation time it writes the
SMF record with the actual (earlier) mount start and
end times; MXG sets VOLSER='UNKNWN' because without an
OPEN, the VOLSER is unknown. And IBM's type 21 SMF
record contains blanks for VOLSER for the dismount!
This and other discoveries led to revisions in internal
algorithms in ASUMTAPE, described below, but there was
no error in the number of observations in PDB.ASUMTAPE.
Some obs that previously had STATUS='MISSEDMNT' will now
be MATCHED, and a few will now be STATUS='WRONGVOL'.
-The VOLSER=UNKNWN mount records are no longer discarded.
They are for those "multi-unit,never-used" mounts in
which the MXGTMNT monitor is still waiting for a VOLSER,
and their type 21 record has blanks for volser.
-The "sorttime" used for MOUNT records is now based on the
end of mount timestamp, TENDTIME, moved two seconds back
to account for the MXGTMNT timer pop, but not moved back
before the start of the mount timestamp, TMNTTIME:
sorttime = MAX(TMNTTIME,TENDTIME-2);
These choices for sort order were tested:
TMNTTIME - start of mount (sampled) timestamp. Used
early, but found to cause many MISSEDMNT
events, correcting moved it before ALOCSTRT
so TENDTIME was used in 17.01/17.02.
TENDTIME - end of mount (sampled) timestamp. Used
in 17.01 and 17.02, revised above in 17.03.
Without subtraction, a few were found with
TENDTIME after the TY21TIME, which created
MISSEDMNT events, but the 2 second pop now
sorts the mount record before the dismount,
and the MAX(TMNTTIME) ensures the it will
not be shifted to earlier than TMNTTIME (as
that could put the mount before allocate).
SMFTIME - when record written, can be after TENDTIME,
eg., for "multi-unit,never-used" mounts
whose SMF records are written at (sampled)
deallocate time, so SMFTIME can even be
after TY21TIME.
-Some MISSEDMNTs had mount records, but their mounts had
been discarded due to missing JESNR, which was used to
recognizing a new JOB. I have revised that logic to not
require JESNR, and thus can keep those mount records.
-Some MISSEDMNTs are for "start-up effect missed-mounts"
whose mount had occurred before the begin time of the SMF
file (ALOCSTRT earlier than the first dismount), but they
occur on the first day's run of ASUMTAPE and are
eliminated when the SPIN library takes effect on the
second run.
-Some MISSEDMNTs are now STATUS=TY21ONLY, because the test
is now IF ALOCSTRT LE TY21TIME LE ALOCEND THEN (added
test for ALOCEND) so that 21s with times after the end of
the held alloc record are recognized.
-Some MISSEDMNTs are now STATUS=WRONGVOL, because I found
I can recognize many instances of the operator putting in
(intentionally) an incorrect volume (when he/she cannot
find the correct volser, the stick in any tape to knock
down the outstanding mount message).
-Some remaining MISSEDMNTs in non-VTS environment are the
result of allocation recoveries when allocation switching
occurs; sometimes the mount was seen but the wrong job
name was put in the mount record so the mount did not
match up. A new version of MXGTMNT is in testing that
may be able to detect this state and correct or eliminate
those bad mount records.
-This revision now matched 13,822 tape mounts, found 5
WRONGVOL, 26 TY21ONLY, and only 24 are now MISSEDMNTs!
Thanks to Chuck Hopf, MBNA, USA.
Change 17.076 Type 73 with APAR OW15406 (IODF date expanded to YYYY)
VMAC73 and first 17.01 printed debugging lines on the SAS log:
May 1, 1999 YYYY IODFTIME=25MAR1999:08:24:18.00 _N_= ....
because the PUT statement had not been deleted.
Thanks to MP Welch, SPRINT, USA.
Change 17.075 The SORT order in these examples did not include SYSPLEX
ANALMTP variable in the PLOTs of TYPE70 and RMFINTRV, causing
ANALMPL a NOT SORTED error. SYSPLEX was added to RMF sort order
Apr 30, 1999 in MXG Change 16.288 but these examples were overlooked.
Thanks to MP Welch, SPRINT, USA.
Change 17.074 EXCP/IOTM variables did not exist in TYPE434 because the
VMAC434 "%INCLUDE SOURCLIB(IMAC434);" statement should have been
Apr 30, 1999 "%INCLUDE SOURCLIB(IMAC30IO,IMAC434);". This error was
introduced in the MXG 16.04 redesign.
Thanks to Mike Hoey, Ameren Services Corporation, USA.
======Changes thru 17.073 were in MXG 17.01 dated Apr 29, 1999======
Change 17.073 -SAS Version 7 causes error message on SYSMSG that options
AUTOEXEC CODEPCT and BLKSIZE(TAPE) are not supported in V7, but
CONFIGV7 there a return code of zero is set, so there is no real
Apr 28, 1999 error condition. To eliminate those messages, however,
new CONFIGV7 member exists and it can be used instead of
CONFIG in your MXG SAS JCL procedure. (Note that members
CONFIG, CONFIG07 and CONFIG08 are identical, and they are
for SAS Version 6.07 thru 6.09.).
Note: Feb 17, 2000: Members CONFIGV8 and CONFIGV7 are
the same and eliminate warning messages on the SAS log
with SAS Version 8.
-For ASCII execution, member AUTOEXEC is the equivalent of
CONFIG and it has been updated to pass the same options
for ASCII MXG execution as are set by CONFIGV7 for MVS.
Change 17.072 ANALDALY's sort order had not been updated to include the
ANALDALY SYSPLEX variable (BY SYSPLEX SYSTEM STARTIME), causing a
Apr 28, 1999 NOT SORTED error message.
Thanks to MP Welch, SPRINT, USA.
Change 17.071 Duplicate obs were detected and deleted from MQMACCT data
VMAC116 set (type 116 MQ-series accounting) because identical 116
Apr 28, 1999 records are created, in pairs and triplets (284 removed
of 24,000). The sort macro _BTY116 was expanded to hold
the full set of unique variables, but each observation is
from a different SMF record, so variable SMFRECNR was
added to the KEEP list, so that no records are duplicates
and so none are deleted by the SORT. (TYPE116 does not
sort, so it deleted no observations; only if you used the
TYPS116 member or the _S116 or _Sty116 macros were dupes
removed.) Further investigation with IBM is planned.
Note added Feb 18, 2000: While SMFRECNR was added to the
KEEP= list for dataset MQMACCT, it was not added to the
BY-list macro, because it would prevent removal of dupes
that came in two different SMF-reading jobs. See the
sort revisions in Change 18.001 and discussion there.
Thanks to Freddie Arie, Texas Utilities, USA.
Change 17.070 Using ANALCNCR to count concurrency failed if the values
ANALCNCR for start or end were missing. ANALCNCR now deletes any
Apr 28, 1999 input observations with missing timestamps (and reports
how many if any were found).
Thanks to Greg Jackson, National Life of Vermont, USA.
Change 17.069 Thirty-nine instances of "&NUM.2 "
VMACEDGR were changed to "&NUM.2. "
Apr 28, 1999 Retention Date field RDRETDAT can contain "WHILECATLG"
as date value; that string is now reported and new MXG
variable RDWILCAT='Y' and RDRETDAT will be missing.
Thanks to Jan van Lent, Hudson Williams Europe, GERMANY.
Change 17.068 Change 16.078 increased variables CSTORE and ESTORE in
RMFINTRV dataset TYPE71 to eight bytes stored length, but RMFINTRV
Apr 28, 1999 had the variables in the new LENGTH 8 and in the old
LENGTH 4 statement; remove them from LENGTH 4 statement.
Thanks to Jan van Lent, Hudson Williams Europe, GERMANY.
Change 17.067 Inconsistent documentation and code, but thankfully with
VMXGSUM no impact. The invocation of &INCODE1 is now located
Apr 28, 1999 after the invocation of &INCODE instead of before, but we
have never used &INCODE1= nor do I really think anyone
else would have; it was really there just for insurance
if we ever needed it.
Thanks to Jan van Lent, Hudson Williams Europe, GERMANY.
Change 17.066 Several IMACs still had active macro definitions for the
IMACxxxx "_L and _K" macros that should have been removed in the
Apr 21, 1999 16.04+ design (they are now defined in the VMAC, and the
IMAC should be only comments). Only if you tried to use
the %LET MACKEEP= architecture to tailor these IMACs was
there a problem - your tailoring may have been ignored!
These IMACs were revised: IMACNTCP, IMACSTX, IMACSUIN,
IMACSUPR, IMACSVCC, IMACSTC, IMACICE.
Change 17.065 Eight DB2 variables in DB2ACCT and DB2STATS were only
VMACDB2 input if LENQXST was GE 428, for DB2 Version 6, but the
Apr 21, 1999 fields exist in DB2 Version 5.1. These variables
QXALOCL QXALOCC QXSTFND QXSTNFND QXSTIPRP
QXSTNPRP QXSTDEXP QXSTDINV
are now INPUT if LENQXST is GE 16, and the remainder of
the 6.1 fields are then input if LENQXST is GE 428.
Thanks to Ken Michalik, Kraft, USA.
Change 17.064 The ASMIMSLG/ASMIMSL5 programs still had symbolic value
ASMIMSLG &DFSMS set to 0 (for DFP) that must be changed to one if
ASMIMSL5 you have DF/SMS instead. If you overlooked this value,
Apr 20, 1999 you might read 107 out of 110 log tapes without error and
then fail with 0C4 abends on the other three log files!
I have made the default now to be DF/SMS installed with:
&DFSMS SETB 1
in both programs (ASMIMSL6 already had 1 as its default).
Thanks to David Pearce, Westpac Banking, AUSTRALIA
Thanks to Andrew Barrett, Westpac Banking, AUSTALIA
Change 17.063 Reserved Change.
Apr 20, 1999
Change 17.062 Comments only. TMON data can be dumped in two modes, and
EXITMON6 MXG supports only the "Data-Image" format. If the TMON
Apr 20, 1999 data instead is dumped with their "Export-Import" format,
an extra 104 bytes prefix each record. Comments remind
you to create "Data-Image" format, but also provide an
example of how to use the INFILE's START=105 value to
strip off those extra bytes so MXG can process the badly
dumped data anyhow!
Thanks to Coen Wessels, UNICIBLE, SWITZERLAND.
Change 17.061 The DASD Allocation Monitor program had return code 4 in
ASMDALO its assembly, but runs fine on an OS/390 2.4 system with
Apr 19, 1999 all of its UCBs below the 16MB line, while it 0C4's at
one site which has dynamic UCBs - we are investigating
and will update this text when more is known.
Thanks to Paul Parragio, U.S. Geological Survey, USA.
Change 17.060 "Final?" enhancement to MXG 16.04 architecture defines a
VMXGINIT new &Wdddddd macro variable for the //WORK destination of
VMACXXXX each MXG dataset, just like the &Pdddddd macro variables
Apr 17, 1999 for the output "PDB" destination. The macro _L and _W
are now defined with this syntax in their VMACs:
MACRO _Ldddddd &Pdddddd.DATASET %
MACRO _Wdddddd &Wdddddd.DATASET %
so any existing overrides of the _L or _W macros continue
to work, but instead you can use the simpler syntax:
%LET &Wdddddd = DDNAME ;
to redirect that dataset to DDNAME. That %LET can be
stored in your IMACKEEP member, or can be put ahead of
of the %INCLUDE program statement. I'm only sorry I did
not think of this in time to include in MXG 16.16!
This enhancement is transparent, unless you use USER=XYZ:
There were 272 members EDITed for this change.
Before, if you use // EXEC MXGSAS,OPTIONS='USER=XYZ'
all datasets that SAS wrote by default to //WORK would
be sent to the XYZ DDname, but now, SAS sees a real
DDNAME (yep, it happens to be "WORK", but SAS doesn't
see that, so the datasets are not output to XYZ).
Now, to send all //WORK datasets to the //XYZ DDname,
you can re-initalize MXG and change the work default:
%VMXGINIT(MXGWORK=XYZ);
%INCLUDE SOURCLIB(TYPExxxx);
and get the same effect as the USER=XYZ option.
Jan 2009: The preceeding example to send //WORK to //XYZ
has not worked since 2000. See Change 18.148.
The MXGWORK argument of %VMXGINIT was removed
in Change 26.310.
It took 240 minutes to locate and change the 2450 lines
in 272 members. It then took 120 minutes to locate and
correct the 19 characters in 17 lines in 14 members that
had been incorrectly typed. I had an error in 5.1% of
the members I edited, but that is only 0.7% of the lines
Change 17.059 Support for APAR OW37708 and/or APAR OW38073 add four new
VMAC42 variables, SMF42BUF/BMX/LRU/UIC to the TYPE42TO dataset,
Apr 16, 1999 with total and highwater mark of BMF buffers and BMF LRU.
interval and cycles until castout.
Change 17.058 For RMM/EDGS records EDGATYPE R or S, there are two
VMACEDGS different sets of variables depending on MSRMSTID. Now
Apr 16, 1999 both sets are decoded, and new variables MSUSTNAM,
MSMEDIA and EDGATYPE are added to dataset EDGSSREC.
Thanks to Richard Fortenberry, Mitsubishi Motor Sales of America, USA
Change 17.057 -Change 16.225 was incomplete; the INPUT of the variables
VMACHSM WFSCPUTM and WFSACCT was added in the ID+1 record but was
FORMATS not added in the ID record, but since the FSR segment is
Apr 16, 1999 now in the ID+1 record, there should be little impact,
unless you are missing the APAR that moved the segment.
-Format MGHSMFU was updated to include values 15 and 16,
for ABARS ABACKUP and ABARS ARECOVERY records.
Thanks to Richard Fortenberry, Mitsubishi Motor Sales of America, USA
Change 17.056 Support for the index information in DB2 Type 102 subtype
VMAC102 22 for DB2 5 and later is now decoded and creates ten new
Apr 16, 1999 variables in dataset T102S022.
Thanks to Scott Mcdonall, Southern California Electric, USA.
Change 17.055 Support for NTSMF new Quota Server object creates new MXG
EXNTQTAS dataset QUOTASRV.
FORMATS
IMACNTSM
VMACNTSM
Apr 15, 1999
Change 17.054 Using UTILBLDP to create your tailored sysin for BUILDPDB
UTILBLDP had errors and not clearly documented. If your tailoring
Apr 15, 1999 generated a MACRO _Edddddd .... statement, it was missing
an end comment on that line that cause a recursion error.
If you added the TMNT (MXG Tape Mount) product records,
you got an OPEN failure because UTILBLDP forgot that TMNT
records are in BUILDPDB by default. The missing "*/" is
now created, and your request to add TMNT records will be
used to set the _IDTMNT value without the OPEN failure,
so that observations are created in TYPETMNT dataset.
Comments were revised to document that you run %UTILBLDP
once to build an output text file, (BUILDMXG is now the
recommended name, and the recommended destination is in
your USERID.SOURCLIB). Then that "BUILDMXG" file with
your tailoring changes is used instead of the BUILDPDB
member in your daily job, either by pointing the SYSIN
of the daily job at BUILDMXG file:
//SYSIN DD DSN=USERID.SOURCLIB(BUILDMXG),DISP=SHR
or by replacing the %INCLUDE SOURCLIB(BUILDPDB); in your
daily PDB job with %INCLUDE SOURCLIB(BUILDMXG);
If you name the output file "BUILDPDB", it cannot be
put in the //SOURCLIB concatenation, because it will
recursively include itself. It could be put in a PDS
that is not in the SOURCLIB concatenation and pointed
to in that source library, but using BUILDMXG as the
member/file name for the output of UTILBLDP is much
safer and clearer.
Thanks to Keith McWhorter, State of Georgia DOAS, USA.
Thanks to Freddie Arie, Texas Utilities, USA.
Change 17.053 Typo in VMXGINIT caused _S110 (sort all type 110s) to
TYPS110 fail with APPARENT SYMBOLIC REFERENCE PCICCF9 error. The
VMXGINIT two occurrences of PCICCF0 in VMXGINIT were changed to
Apr 15, 1999 PCICCF9. The ultimate cause of the error, however, was
Jul 20, 1999 that the _S110 macro was not used in the TYPS110 member,
so it was not fully tested; now, _S110 will execute when
member TYPS110 (to sort all datasets) is tested.
Jul 20: Typos in text: PCICFCn changed to PCICCFn.
Thanks to Alex Torben Nielsen, TeleDanmark EDB, DENMARK.
Thanks to Tom Elbert, FORTIS, USA.
Change 17.052 Variable A08DURAT was missing in CICS/ESA 4.1 and later,
VMAC110 because the timestamps used to create it moved from the
Apr 14, 1999 STID=37 to the STID=39, and I overlooked creating the
duration variable from them. In addition, A08DURAT is
now truly the duration, since now the start and stop
variables are datetimestamps; previously they were only
a 24-hour time of day, so its calculation is direct:
A08DURAT=A08LBKDD-A08LBKCD;
Thanks to Harald Seifert, Huk-Coburg, GERMANY.
Change 17.051 A MACKEEP= example in Change 16.134 and DOCMXG does not
ChangeSS work safely, and was removed. The bad example showed
DOCMXG that you could sometimes tailor an _Edddddd exit macro
Apr 14, 1999 without using a semicolon and avoid the %QUOTE( ), but
that does not always work, depending on the contents of
the EXdddddd member used by the _Edddddd macro. Instead,
the second (and good) example showed that you should add
IF ... THEN DO; %include (member); END; logic around
the include of the EXdddddd member, and how to put the
MACKEEP= argument inside the %QUOTE ( ) function. This
is always safe, and only that second example was kept.
Thanks to C. Fred Kuhstoss, Norfolk Southern Corporation, USA.
Change 17.050 Using the new PDB.ASUMTAPE as input to member ASUMTMNT
ASUMTAPE can cause INVALID DO CONTROL error for "MISSEDMNT" mounts
Apr 14, 1999 because their TMNTTIME and TENDTIME variables were left
missing. But these MISSEDMNT events are all very fast
mounts, which had physical mount time in less than one
sample interval (max 2 seconds by default, may be 0.5),
so I have chosen to set the TMNTTIME and TENDTIME equal
to the ALOCSTRT datetimestamp for MISSEDMNT events in the
PDB.ASUMTAPE dataset to protect member ASUMTMNT.
Thanks to Greg Jackson, National Life of Vermont, USA.
Change 17.049 Typo caused no observations for dataset NPMSEEND. The
VMAC28 statement _E028SE1; after IF NPMSUBTY=49X THEN DO;
Apr 14, 1999 should be _E028SE2; (as in the comment).
Thanks to Bill Shanks, SEMA, ENGLAND.
Change 17.048 Support for IXFP/ICEBERG Subtype 8 and Subtype 6 fix.
EXICE8CL -IBM/STK mis-documented the IXFP SNAPSHOT DDSR segment,
EXICE8DD causing INVALID DATA FOR DSSRTIME error. DDSRTYPE is
EXICE8DS a four-byte binary and not a one-byte character.
EXICE8NP -New subtype 8 is an extended subtype 6 record that now
FORMATS creates four new MXG datasets, replacing two:
IMACICE ICEBR8CL - Cluster Definition
VMACICE ICEBR8DS - Dataset Name Segment
VMXGINIT ICEBR8SN - Snapped Extents List Segment
Apr 15, 1999 ICEBR8DD - DDSR Extents List Segment
Thanks to Judy Arroyo, Summit Bank, USA.
Change 17.047 Some 24 variables with MGBYTES format also had labels
VMACDCOL with "(MGBYTES)", which misled some to think the field
VMACTSOM contained "mega-bytes". MXG variables formatted with
VMACNETP the MGBYTES format contain bytes, but are converted when
Apr 13, 1999 printed to display their value in K/M/G/T-suffix for
Kilo/Mega/Giga/Tera-byte (i.e., 1024*) units. Because of
this confusion, the "(MGBYTES)" in the LABEL of all
variables was removed. The LABEL of a variable describes
the contents of that variable; the FORMAT of a variable
describes its display format, and implicitly its internal
units (MGBYTES in bytes, TIME/DATETIME in seconds, etc.).
I just read that the International Standards body has
defined new prefixes of KIBI/MEBI/GIBI/TEBI to
explicitly describe "binary thousands", or units of
1024-per-"thousand", so the MGBYTES format formally
supports those units with its "K/M/G/T/P" suffixes!
Change 17.046 ML-19 of ASMTAPES supresses the TMNT005E messages that
ASMTAPES should not have been printed. Originally a message for
Apr 12, 1999 an unexpected event, these messages occur with very fast
mounts. We detected that an ASID has a tape allocation,
but when we (slightly later) scan to that UCB, it no
longer is owned by the ASID number we got at the start
of the sample. Fast scratch VTS mounts now cause this
message to print in flurries, but the message has no
impact on the SMF records created by ASMTAPES, which are
just fine even when there are TMNT0005E log messages.
This correction returns to the caller with an RC-8, which
will cause the main logic to simply continue processing
with the next tape drive. At the next sample interval
we'll detect the ASID change and cut the allocation for
the job that used to have the drive allocated.
Thanks to David Gayle, Alltel, USA.
Change 17.045 Changing the Interval of PDB.ASUM70PR with _DURSET macro
ASUM70PR no longer worked, because of internal changes to VMXGSUM
Apr 12, 1999 to the &DATETIME parameter. To synchronize ASUM70PR with
RMFINTRV, IMACRMFI's _DURSET macro was used in a MYTIME=
argument, instead of using the VMXGSUM interval settings.
Additionally a SHIFT variable was needed to be created,
complicating the old logic. This redesign removed the
MYTIME= and INTERVAL=, and instead substitues the _DURSET
and IMACSHFT statements directly in the INCODE= argument.
This is both simpler and forces synchronization with the
PDB.RMFINTRV that is demanded in the later merge.
Thanks to Mike Hill, Abbey Life Assurance Company Limited, ENGLAND.
Change 17.044 Another typo in the _CDE102 macro causes error if TYPE102
VMAC102 is used to create all 300+ possible IFICIDs. The line
Apr 9, 1999 _C102206 _C102107 _C102108 ... should have been
_C102106 _C102107 _C102108 .... See Change 17.020.
Thanks to Hans Coolen, Zwolsche Algemeene, THE NETHERLANDS.
Change 17.043 Variable FSRDLM was not converted to yyyyddd julian date.
VMACHSM Eleven lines after CC=FLOOR(FSRDLM/100000) statement, the
Apr 9, 1999 IF YYYYDDD GT . THEN FSRBDATE=YYYYDDD; should have been
IF YYYYDDD GT . THEN FSRDLM=YYYYDDD; (Date Last Moved).
Thanks to Solomon Baker, Prudential, USA.
Change 17.042 Type 42 subtype 16 was out of alignment; after the input
VMAC42 of SMF42GAI and SMF42GBI, lines with +3 were inserted
Apr 9, 1999 to skip over the remaining three bytes of those four byte
fields. Type 42 subtype 19 timestamps SMF42JNE/SMF42JNF
are now input as &PIB.8.3 instead of 8.6. Many times that
were documented as microsec in OS/390 R2.6 SMF manual are
now documented as milliseconds in OS/390 R2.7 manual, and
most were caught in MXG 16.16, but these two were missed.
Thanks to Ben Cheung, Bank of Montreal, CANADA.
Change 17.041 The original PDB.ASUMTAPE dataset had SYSTEM='ALL ' for
ASUMTAPE all observations, but that is now corrected and the obs
Apr 9, 1999 will contain the SYSTEM of the Allocate (or Mount, if
there was no Matching Allocate, or Dismount if neither
an Allocate or a Mount was found. MXG sets SYSTEM='ALL'
internally so that grouping is done by DEVNR, but now the
true system is reset into variable SYSTEM.
See Change 17.010 for more complete details on why you
must use the new PDB.ASUMTAPE in place of PDB.TYPETMNT.
Thanks to David Ziems, NationsBank, USA.
Change 17.040 STC SMF record subtype 14 apparently does not always
VMACSTC contain step name and dataset name, STC14SNM/DSN (and
Apr 9, 1999 the label for STC14DSN was typoed too!). Now the MXG
logic tests for those fields existence before input.
Thanks to Jorn Ernebjerg, Kommunedata A/S, DENMARK
Change 17.039 Cosmetic. Typos in example for DATASET=DB2STATB were
DOCMXG corrected. The actual _SDB2STB code in member VMACDB2
Apr 6, 1999 was correct and can be viewed as an example.
Thanks to Engelbert Smets, Provinzial Versicher. Dusseldorf, GERMANY
Change 17.038 Cosmetic. Typos in the list of DDDDDD and DATASET names.
IMACACF2 ACFJEL/ACF2JEL should be ACFJRL/ACF2JRL and ACFAR/ACF2VR
Apr 6, 1999 should be ACFVR/ACF2VR. Only comments were changed.
Thanks to Mike Penlington, WestPac Trust, NEW ZEALAND.
Change 17.037 Support for TANDEM F40, G04, and G05 Operating System
VMACTAND changes to CPU, DISK, and PROCESS (INCOMPATIBLE, because
Apr 6, 1999 you must specify the exact LRECL when you upload TANDEM
records, and the LRECL is different for these records for
these operating systems. A number of new variables,
including Bytes In/Out have been added in this change.
Although these changes have been coded, no test data for
any of these operating systems has been available yet.
Thanks to Kim S. Johnson, NationsBank, USA.
Change 17.036 TPX Start Up record, subtype 1, was not properly decoded.
VMACTPX Now TPX subpool entry count is corrected, and the total
Apr 6, 1999 pool size (instead of entry size) is calculated for each
Apr 8, 1999 of the twelve pools, above and below the 16M line.
Thanks to Tom Parker, CSC Logic, USA.
Change 17.035 DENSITY IS MISSING message will now produce a hex dump of
VMACTMS5 the bad record for the first two errors, for diagnosis of
Apr 6, 1999 the raw record, but the message is no longer printed if
STPNAME='PRE-TMS', which are the only records that that
have had their density field zero.
Thanks to Joe Bruns, Cargill, USA.
Change 17.034 UNEXPECTED TCP/IP DATA VALUE message with TSTTCPCM=STOU
VMACTCP is fixed by adding 'STOU', to the list of commands for
Apr 6, 1999 FTPCLIENT/FTPSERVER events. Also, the message will now
also print a hex dump of the full record for the first
three instances on the SAS log.
Thanks to Pat Hearne, Experian, USA.
Change 17.033 New ratio variables are created in TYPE74CA dataset to
VMAC74 match RMF cache reports and eliminate an extra pass of
Apr 5, 1999 the data in your reports. Variables PCTREAD, TOTDEVHR
and WRITEHR (Percent Read, Device Hit Ratio and Write Hit
Ratio) were added.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Taught my 3-day Class in Dallas, March 31 - April 2, 1999.
Flew to Steve Cullen's retirement at State Farm Mutual Automobile
Insurance Co, Bloomington, Il, on April 2, 1999, in a Lear 25.
Change 17.032 For extended format datasets, HIGHRBA contains not the
VMAC64 highest byte address, but the highest CI number, and
Mar 29, 1999 so MXG stored HIGHRBA into HIGHCIEX, and tried to set the
HIGHRBA to missing (but misspelled it as HICHRBA). But
now, the spelling was corrected and the block of code
for extended format datasets was moved to after the INPUT
of CISIZE, and for extended format datasets, now the
HIGHRBA=HIGHCIEX*CISIZE calculates the highest relative
byte address of these datasets too.
Thanks to Alan Winston, MBNA, USA.
Change 17.031 Documentation. Boole's CMF product can create type 74
VMAC74 subtype 5 Cache records by specifying CMFREC=74 on the
Mar 29, 1999 CACHE control Statement. See CMF Monitor Batch User
Guide and Reference, Version 5 Release 2.3 pp 134-135.
Thanks to Bernd Klawa, Stadt Bielefeld, GERMANY.
Change 17.030 The calculation of RATCNT was revised, based on an email
VMACDMON from a CA technician. They now report that their code
Mar 29, 1999 calculates RATCNT=(RTCNT-RRSCNT)+SSAMPRT; but the old MXG
equation was RATCNT=(RTCNT-RRSCNT)*SSAMPRT+RRSCNT;.
Thanks to Ian Jones, Standard Life Assurance Company, ENGLAND.
Change 17.029 One site encountered syntax errors because two lines had
WEEKBLDT extended into column 72 (which is not wrong, and we can't
Mar 29, 1999 figure out why the one site had a failure), but the blank
before the percent sign was removed in the BYLIST macros
for TYPE72GO and TYPE7204, so that the line had a blank
in column 72, and the syntax error went away. The site
is at SAS 6.09 TS460!
Thanks to Bob LeMaster, Compass Bank, USA.
Change 17.028 TLMS expiration dates of 9990000 caused INVALID ARGUMENT
VMACTLMS TO FUNCTION DATEJUL, and variables BAVEXPDT or BADEXPDT
Mar 28, 1999 had missing values. These fields are now protected just
like TMS: two new variables, ORVEXPDT and ORDEXPDT will
contain the original EXPDT values, and for these non-date
dates (see Change 16.382 for the set of non-date values),
variables BAVEXPDT/BADEXPDT will contain '31DEC2099'D so
than any calculations will return a large value for these
non-date expiration values.
Two statements were changed for each variable in each
TLMS-version-block. The changes for BADEXPDT are:
IF 0 LT BADEXPDT LT 9999999 THEN .... was changed to
IF 0 LT BADEXPDT LT 9900000 THEN .... and
ELSE IF BADEXPDT=9999999 THEN .... was changed to
ELSE IF BADEXPDT GE 9900000 THEN ....
Thanks to Jim VanArsdale, IBM Global Services, USA.
Change 17.027 Support for APAR OW35586 "FICON" channels adds fields to
VMAC73 type 73 record from RMF Monitor I, and the type 79-12 RMF
Mar 28, 1999 Monitor II (optional) record. The TYPE73 and TYPE79C
Jul 11, 1999 datasets have new fields (variables prefixed SMF73 in the
TYPE73 dataset are prefixed R79C in dataset TYPE79C).
Depending on the CPMF Channel Measurement Group for the
Channel, SMF73CMG, one of these two sets of measurements
will be populated in dataset TYPE73:
For SMF73CMG=1, the Group 1 measurements are:
SMF73FG5='CPMF*VALIDATION*FLAGS'
SMF73TUT='TOTAL*CHANNEL*PATH*BUSY*TIME'
SMF73PUT='LPAR*CHANNEL*PATH*BUSY*TIME'
or for SMF73CMG=2, the Group 2 measurements are:
SMF73MBC ='MAXIMUM*BUS*CYCLES*PER SEC'
SMF73MCU ='MAXIMUM*CHANNEL*WORK UNITS*PER SEC'
SMF73MWU ='MAXIMUM*WRITE*DATA UNITS*PER SEC'
SMF73MRU ='MAXIMUM*READ*DATA UNITS*PER SEC'
SMF73US ='DATA*UNIT*SIZE'
SMF73TBC ='TOTAL*BUS*CYCLES*COUNT'
SMF73TUC ='TOTAL*CHANNEL*WORK UNITS*COUNT'
SMF73PUC ='LPAR*CHANNEL*WORK UNITS*COUNT'
SMF73TWU ='TOTAL*WRITE*DATA UNITS*COUNT'
SMF73PWU ='LPAR*WRITE*DATA UNITS*COUNT'
SMF73TRU ='TOTAL*READ*DATA UNITS*COUNT'
SMF73PRU ='LPAR*READ*DATA UNITS*COUNT'
-And these were added to TYPE79C by Change 17.023.
-They provide Channel Path Activity data transfer rates
and bus utilization for FICON bridges (FCV), with new
IBM descriptions:
Bus Utilization: Percentage of bus cycles when
bus has been found busy for
this channel in relation to the
theoretical limit.
Read (MB/SEC) PART: Data transfer rates from the
or control unit for this individual
LPAR partition.
Write(MB/SEC) TOTAL: Data transfer rates from the
control unit for the entire
CPC/CEC.
Change 17.026 APAR OW15406 added YYYY value for IODF Creation Date/Time
VMAC73 IODFTIME. Fortunately, this date is not likely to be
VMAC74 used for anything other than display, if at all! The MXG
Mar 28, 1999 logic to protect the 2-digit YY field in systems without
that APAR was added, and now the MXG code for IODFTIME is
the same for type 73 and type 74 records.
Change 17.025 Adding new variables to the PDB.JOBS/STEPS/PRINT datasets
BUILD005 with the new %LET ADD30U4= NEWVAR1 ... ; syntax is easy,
BUIL3005 but I hadn't thought about an easy way to drop variables
Mar 25, 1999 from those PDB datasets. Of course, you could always do
as before, by copying the appropriate _PDBnnnn macro from
BUILD005/BUIL3005 into your IMACPDB or IMACKEEP member
and blanking out the unwanted variables. But I realized
that by locating all _PDBnnnn macro references to the end
of the KEEP= list (some were, some weren't!), you can now
use the new ADDnnnn macro variable either to add new or
to drop old variables from those three PDB datasets:
%LET ADD30U4= NEWVAR1 NEWVAR2 DROP= UNWANT1 UNWANT2 ;
%INCLUDE SOURCLIB(BUILDPDB);
Since the &ADDnnnn token is at the end of each _PDBnnnn
definition, adding variables worked no matter where the
_PDBnnnn macro occurred after the KEEP=, but the _PDBnnnn
reference must be at the end of the KEEP= list to safely
use the above syntax to both drop and add variables.
In truth, you could have used the ADDnnnn macro to
add and drop, even without my relocating, but you
would have had to protect any variables that followed
the _PDBnnnn reference in the BUILxxxx member by the
use of this syntax for following variables:
%LET ADDnnnn= V1 V2 DROP= X1 X2 KEEP= ;
because SAS accepts this syntax:
DATASET (KEEP=list DROP=list KEEP=list )
Thanks to Larry Melamed, SHL Systemhouse, CANADA.
Change 17.024 I can't seem to ever get VMACIMSA right. Line 1374 has a
VMACIMSA missing semicolon. Actually, the semicolon was in column
Mar 25, 1999 73, which MXG truncates under MVS because S=72 is set in
CONFIG, but my testing under ASCII accepted the longer
record. Shift the line left and put the semicolon in 72.
Thanks to Pete Young, University of Toronto, CANADA.
Change 17.023 -CPU time for Pre-emptible SRBS running in this ASID, and
TYPE79 the CPU time for Pre-emptible SRBs running on behalf of
TYPS79 this ASID, and the Total CPU time consumed in this ASID
VMAC79 are now variables R791ASST/R791PHTM/R791TCPC in TYPE791
Mar 25, 1999 dataset, and R792ASST/R792PHTM/R792TCPC in TYPE792. The
Mar 28, 1999 fields were added by OS/390 Version 2 Release 5.
-In validating the TYPE791 dataset, I note that it has
mostly-accumulated fields, so the _STY791 Sort macro now
includes additional data steps to deaccumulate the data,
and the deaccumulation is automatic if you use member
TYPS79. Or you can use TYPE79 and then invoke _STY791,
so that dataset TYPE791 contains valid interval values.
-Support for FIBERCON/FICON new measures were added. See
text of Change 17.027 for details of new measurements, as
the same variables were added to TYPE73 as to TYPE79C.
-In TYPE79 and TYPS79, the line with _CDE79S was deleted
because it did not belong there; fortunately it had no
external impact, except to confuse my debugging!
Thanks to Tim Crocker, National Council on Compensation Insurance,USA
Change 17.022 IMS 6.1 only, MXG 16.16 still was wrong. Six lines with
VMACIMSA "DHMS(DATEYYYY," must be "DHMS(DATEJUL(YYYYDDD),"
Mar 24, 1999 so that timestamp values are not missing. While IMS 6.1
records had been validated with MXG 16.09, VMACIMSA was
later "cleaned up" to create unique julian date fields to
examine for debug that were not kept, and that revision
introduced this error in MXG 16.16.
Thanks to Chris Weston, SAS Institute Cary, USA.
Change 17.021 HSM and TMS Julian Date variables are internally Y2K ok,
VMACHSM but their default print format was still "6.", causing a
VMACTMS5 julian date of 2000001 to print as 2E6. The default
Mar 19, 1999 print format is now changed from "6." to "7." in both
members, but the MXG 16.16-built datasets are still
completely valid internally, and you can add a statement
FORMAT DSRDATE 7.; in your reports to print the seven
digit julian dates.
Thanks to John McCray, Huntington Services Company, USA.
Change 17.020 Typo in the _CDE102 macro causes error if TYPE102 is used
VMAC102 to create all 300+ possible IFICIDs. The text _C012297
Mar 19, 1999 should have been _C102297.
Thanks to Jules Troxler, Swiss National Bank, SWITZERLAND.
Change 17.019 The definition of HSM macro _DIFFHSM was relocated from
DIFFHSM the DIFFHSM member to the VMACHSM member so that you can
VMACHSM redefine the _DIFFHSM macro if you only want one HSM
DOCMXG dataset. For example, after this change, to create only
Mar 19, 1999 the HSMDSRST dataset, you could use:
%LET MACKEEP=
_NHSM
MACRO _WHSMDSR HSMDSRST %
MACRO _DIFFHSM _SHSMDSR %
;
Bob also found a type in DOCMXG examples; the second use
of _N110 example needed a second percent sign to end the
MACRO _ECICTRN definition as it is inside the %QUOTE.
Thanks to Bob Barton, DaimlerChrysler, GERMANY.
Change 17.018 NPM 2.4 only. Datasets NPMINSES and NPMEVSAL have trash
VMAC28 in LSCDxxxx variables. IBM added fields for IP address
Mar 16, 1999 and IP Port Number, but I misread the DSECT and thought
they were inserted; in fact they overlaid existing fields
causing the INPUT statement to be miis-aligned with data.
There are two places that needed correction.
The original code in the first location was:
SLNKNAME $EBCDIC8.
@;
IF COFTYPE='SCD' AND LSCDREVL GE 3 THEN INPUT
LSCDIPNM $EBCDIC15.
@;
INPUT SLUSUBPU $EBCDIC8.
and the correct code in that location now is:
SLNKNAME $EBCDIC8.
@;
M16=-16;
IF COFTYPE='SCD' AND LSCDREVL GE 3 THEN INPUT
+M16 LSCDIPNM $EBCDIC15.
+1
@;
INPUT SLUSUBPU $EBCDIC8.
to back up 16 bytes and input LSCDIPNM correctly.
The original code in the second location was:
VRNUM &PIB.2.
@;
IF LSCDREVL GE 3 THEN INPUT
LSCDIPPN $EBCDIC5.
@;
INPUT
TRANPRTY &PIB.2.
and the correct code in that location now is:
VRNUM &PIB.2.
@;
M5=-5;
IF LSCDREVL GE 3 THEN INPUT
+M5 LSCDIPPN $EBCDIC5.
@;
INPUT
TRANPRTY &PIB.2.
to back up 5 bytes and input LSCDIPPN.
Thanks to Steve Donahue, Blue Cross Blue Shield of Texas, USA.
Change 17.017 Cosmetic. The BY list for the TYPETMNT dataset in the
ASUMTMNT ASUMTMNT and TRNDTMNT members had "DATETIME", but that
Mar 15, 1999 can now be changed to the real variable name of TMNTTIME
Apr 5, 1999 (changes to VMXGSUM several versions ago made that change
possible), and the sort order in TRNDTMNT was changed
changed from ... SHIFT DEVICE ... to ...DEVICE SHIFT ...
to be consistent with the prior sorts. In addition, the
ID=TMNTTIME, statement has to be deleted for this change.
Thanks to John Sheridan, Aer Lingus, IRELAND.
Change 17.016 RMM EDGR dataset EDGRDEXT has zero observations because
VMACEDGR _EEDGRV /*INC SOURCLIB(EXEDGRD); _WEDGRD OUTPUTS EDGRDEXT*/
Mar 15, 1999 should have been:
_EEDGRD /*INC SOURCLIB(EXEDGRD); _WEDGRD OUTPUTS EDGRDEXT*/
Thanks to John Paul, Capital Blue Cross, USA.
Change 17.015 The input dataset was WEEK.PRINTER but member ASUMPRTR
TRNDPRTR now creates WEEK.ASUMPRTR, so the input was changed to
Mar 11, 1999 WEEK.ASUMPRTR. The output remains TREND.PRINTER.
Thanks to John McCray, Huntington Service Company, USA.
Change 17.014 Documentation and revision. The original 16.16 example
UTILBLDP did not properly handle SMF records that had fixed ID,
Mar 24, 1999 such as IBM type 39 records, and there was a missing
end comment sign.
Change 17.013 Dataset TYPE21/PDB.TAPES variable OPEN is always blank
VMAC21 now (MXG 16.04+), but it used to always be "INPUT". In
Mar 9, 1999 fact, the DCBOFLGS field that is tested to set OPEN is
not valid, since it always contains nulls in our data.
(IBM documentation says that if no bit is on in that
field, it was not available to the SMF record). Since
the type 21 record now contains BYTEREAD and BYTEWRIT,
which are clearer indicators of activity, I will leave
the code as it is, with OPEN=blank. If IBM every fixes
the record to retain the DCBOFLGS, then the MXG code
will populate OPEN. In addition, if the new ASUMTAPE
is enhanced to merge in TYPE1415 records, the actual
OPEN value will be available with that analysis.
Thanks to Khoan Dang, MBNA, USA.
Change 17.012 RACF type 80 record with optional RACFTYPE=7 user segment
VMAC80A had INPUT STATEMENT EXCEEDED RECORD LENGTH error. Delete
Mar 8, 1999 the statement INPUT +RACFDLN @; that is immediately after
the statement WHEN (7) DO;
Thanks to Joe Faska, Depository Trust, USA.
Change 17.011 MXG 16.09-MXG 16.16. TYPEIMSA processing is wrong, with
VMACIMSA missing values for STRTTIME. There is one instance of
Mar 8, 1999 DATEJUL(YYYDDD) that has only three YYYs, and that must
be changed to four YYYYs: DATEJUL(YYYYDDD).
Thanks to Werner Bundschuh, SAS Institute, EUROPE.
Thanks to Dr. Harald Lindenmuller, Bayerische Beamtenversich, GERMANY
Change 17.010 MXGTMNT can miss some mounts or can create false ones!!
ASMFTAPE
ASUMTAPE The MXG Tape Mount and Tape Allocation Monitor program
ASUMTMNT MXGTMNT (in member ASMTAPES), has two newly discovered
Mar 11, 1999 serious errors in dataset PDB.TYPETMNT:
Apr 5, 1999
- extra tape mount event records may be created during
allocation recovery with a NOHOLD reply, and
- some very fast VTS scratch mounts are missed.
Fortunately, those errors can be corrected with the new
ASUMTAPE program, which will read these PDB datasets:
PDB.TYPETMNT - Sampled Tape Mount Events
PDB.TYPETALO - Non-sampled Tape Allocation Events
PDB.TAPES - Rename of TYPE21, IBM Dismount Tape
to create the new PDB.ASUMTAPE dataset, that not only
discards any extra mounts, but recognizes missed-mounts
by merging the Allocate with Dismount events, so that the
ownership, durations, plus bytes read/written is known!
This major enhancement should have been written long ago.
A "tape event" is created in PDB.ASUMTAPE for every tape
volume dismounted. An event starts with the allocation
for a volume and ends with the dismount of that volume.
An event could be an allocate/mount/dismount with one
open/close of one dataset on that volume, or a tape event
could have opened many datasets on a volume during one
mount of the volume, or an event could allocate a volume
and mount it in one step and then retain the volume and
use it many times in many subsequent steps until dismount
of the volume. All these are recognized and handled.
These are important variables in the new PDB.ASUMTAPE:
STATUS - MATCHED/MISSEDMNT/TY21ONLY status
VOLSER - Volume Serial Number
DEVNR - Device Number (a/k/a UCB Address)
DDNAME - DDNAME of first use of this volume
INITTIME - Step Initiate time of first step to use
PROGRAM - PROGRAM from first step to use volume
STEPNAME - STEPNAME from first step to use volume
ALOCSTRT - Start Time of allocation for this volume
ALOCVLTM - Duration this volume was allocated
TMNTTIME - Timestamp when Mount was issued
TAPMNTTM - Duration that it took to mount the tape
TMTDTIME - Timestamp when Mount was satisfied
TAPMTDTM - Duration when the tape was mounted
TY21TIME - Timestamp when Volume was Dismounted
BYTEREAD - Bytes Read
BYTEWRIT - Bytes Written
SIOCOUNT - SSCH/SIO Count, number of I/O operations
ERRORxxx - Tape Permanent/Temporary/Erase error counts
JOB - JOB/READTIME/JESNR, and all of the other
information from the first allocate record
and from the mount record.
To correct the errors, all you need do is to insert this
statement after your %INCLUDE SOURCLIB(BUILDPDB):
%INCLUDE SOURCLIB(ASUMTAPE);
and then use PDB.ASUMTAPE instead of PDB.TYPETMNT in your
reports and analysis programs.
If you already %INCLUDE SOURCLIB(ASUMTMNT), to create the
PDB.TAPEMNTS from PDB.TYPETMNT, you will need to add the
include of ASUMTAPE before ASUMTMNT:
%INCLUDE SOURCLIB(ASUMTAPE,ASUMTMNT);
so that the new PDB.ASUMTAPE dataset will be built and
then the revised ASUMTMNT member will create PDB.TAPEMNTS
from the new PDB.ASUMTAPE instead of from PDB.TYPETMNT.
You can correct past PDBs by running this job for each
PDB, starting with the oldest PDB first, because those
"inflight" allocations and mounts are written to the new
SPIN.SPINALOC and SPIN.SPINMOUN datasets at the end of
ASUMTAPE's execution, and are then used as input for its
next run:
// EXEC MXGSAS
//SPIN DD DSN=YOUR.SPIN.LIBRARY,DISP=OLD
//PDB DD DSN=YOUR.PDB,DISP=OLD
%INCLUDE SOURCLIB(ASUMTAPE,ASUMTMNT);
Here are the details of the errors, their cause, etc:
See additional enhancements in Change 17.077.
-MXG SMF Mount records are created for some mounts that
never happened. Jobs that are in allocation recovery
that receive WAIT and NOHOLD replies have mount records
written when message IEF433D "NOHOLD" is printed (but
there are more IEF433D messages than extra records).
Many of these extra mount records have missing JESNR or
READTIME, which are required for validation of matchup,
so those are output to READMSNG dataset and not used.
Some of these extra mount records had VOLSER='UNKNWN',
(MXGTMNT could not get the VOLSER), and originally they
were discarded until Change 17.077. UNKNWN are now used
to build PDB.ASUMTAPE, and also output in dataset UNKNWN.
just in case they are needed. The EXTRAMNT dataset
counts the additional extra mounts that were detected and
discarded in ASUMTAPE. One site had 110
UNKNWN+READMSNG+EXTRAMNT with 745 true tape mounts, while
a second had 406+507+179=1092 false mounts with 8166 true
mounts, so the impact is severe.
While just discovered, this error in MXGTMNT has probably
been there all along. We are presently unable to locate
any flags in OS/390 that can differentiate these IEF433D
mounts as false mounts; all of the bits available to us
when we sample the UCB status during the IEF433D state
look just like the bits during a real mount event, but we
are still investigating corrections to the monitor.
-MXG SMF Mount records are missed for some very fast VTS
scratch mounts, even with 1/2 second sampling. MXGTMNT
missed 219 VTS scratch mounts with 2 second sampling, but
missed only 19 with 1/2 second sampling.
Fast VTS mounts that were too fast and were missed by
MXGTMNT sampling are now captured and identified with
JOB/JESNR/etc by merging their Dismount and Allocate,
although the durations TAPMNTTM will be set to zero
and TAPMTDTM will be set to ALOCVLTM for those mounts
with STATUS='MISSEDMNT'.
-Two new code members were added and one was revised:
ASUMTAPE reads a PDB library to create the PDB.ASUMTAPE
dataset from the PDB.TYPETMNT/TYPETALO/TAPES datasets
that are build by BUILDPDB. ASUMTAPE is in JCLPDB6 so
that it will be build automatically with that JCL.
ASMFTAPE will read SMF data to create the PDB.ASUMTAPE
dataset, for sites that don't run BUILDPDB:
// EXEC MXGSAS
//SMF DD DSN=your.smf,DISP=SHR
//PDB DD DSN=the.output.library,DISP=(,CATLG)...
//SPIN DD DSN=the.inflight.spin,DISP=(,CATLG)
%INCLUDE SOURCLIB(ASMFTAPE);
ASUMTMNT creates the PDB.TAPEMNTS summary dataset that is
used in your tape mount reporting. It is now revised to
use PDB.ASUMTAPE as its input, instead of PDB.TYPETMNT,
if there are observations in PDB.ASUMTAPE. Thus you can
create the corrected PDB.ASUMTAPE dataset and use it in
place of the incorrect PDB.TYPETMNT dataset.
A print of the PDB.ASUMTAPE dataset can be produced by
the macro _TAPERPT, using this syntax:
%INCLUDE SOURCLIB(ASxxTAPE); _TAPERPT;
These WORK datasets are available for examination:
- From the TYPETMNT dataset these defective observations
were not used in the combine logic, but instead were
output to these work datasets:
READMSNG Mount missing READTIME or JESNR.
UNKNWN Mounts with VOLSER=UNKNWN, usually false
mounts, but mounts that were not opened,
like the last volume of multi-unit alloc
for scratch tape that was pre-mounted but
was not used.
- From the TYPETALO dataset these defective observations
were not used in the combine logic, but instead were
output to these work datasets:
ALLOCBAD Allocation with JESNR or JOB missing.
- From the combine of Allocate, Mount, and Dismount:
EXTRAMNT - Extra Mount or Mount with no Dismount, they
were discarded and not counted nor used.
BK2BKDIS - Back to Back Dismounts without alloc/mount.
Has not occurred in testing, but coded for.
ALLOCNOT - Allocation event that was not used; no mount
nor dismount found. Could identify jobs
that are wasting a tape drive, but most of
these are partial allocation events during
allocation recovery. A job needs two drives;
it gets the first but can't get its second.
We see the allocate event record for that
first allocate, but there was no mount nor
dismount because the job never allocated.
The job goes to the bottom of allocation
recovery, and another job is now allocated
to the drive. Typically there is a series
of back-to-back allocates for alternating
job names on the same device as jobs bounce
around.
ALLOCRET - Allocation event that was retained. Very
common to see A,M,A,A,A,A,D sequence for
a tape that was mounted once and then passed
and retained across multiple steps.
DEBUG - Zero obs unless you enable, typically for a
single device, to examine what records come
in what sequence.
SPUNMOUN - Inflight Mounts, held for tomorrow, they get
written out to SPIN.SPINMOUN.
SPUNALOC - Inflight Mounts, held for tomorrow, they get
written out to SPIN.SPINALOC.
The logic expects that a DEVNR is a unique tape drive,
i.e. no two tape devices have the same DEVNR/UCBADDRESS.
By default the variable SYSTEM is set to 'ALL ', so that
the logical merge is by DEVNR, because the IBM dismount
record can be written on a different system than the
system where the allocate and mount were written.
If you do have two tape devices with the same DEVNR
on two different systems, you can group your SMF data
for systems that share and for systems that don't and
run the ASxxTAPE program separately against each set
of SMF records, or better, you will be able to update
a new format table that MXG will use to reset the
variable SYSTEM to separate the shared and non-shared
devices. Contact Merrill to be the test site!
The implementation requires the //SPIN DD exist in your
JCL, and writes out to the //SPIN DD the SPINMOUN and
SPINALOC datasets, holding the inflight mount/allocate
records to be reintroduced in tomorrows processing.
The SPINCNT value in IMACSPIN is not used for ASUMTAPE,
because new allocations will eventually either match up
or confirm that the inflight allocate can be discarded.
I have done a lot of testing, with data from several
systems with different hardware, but this is a brand new
algorithm with lots of opportunities for validation.
I am highly confident that the PDB.ASUMTAPE matchup is
okay, and almost as confident that all other possible
non-matchups are decoded correctly into //WORK.
This program is validated for JES2 only, at present.
It does not fail with JES3, and does match the MXGTMNT
records from JES3 with the TYPE 21 records, but initial
JES3 tests suggest that because JES3 MDS allocations are
never seen by MXGTMNT, this program may not be as useful
for JES3. More JES3 testing is planned and this note
will be revised when more is known about JES3.
These sequences of Alloc/Mount/Dismount events are seen:
Normal: A M D
Multi-Volume A M D M D M D
Retained Allocation A M A A A A D
Dynamic Allocate A M D A M D
Missed Mount A D
Missed Mount Multi-Volume A D D D
Thanks to Chuck Olsen, ALLTEL, USA, whose analysis found the error.
Change 17.009 Support for deaccumulation of TYPE30_6 data. These funny
VMAC30 subtype 6 records are written for address spaces that are
Mar 4, 1999 started before SMF is up, and contain accumulated values
for most fields (but not all, and IBM doesn't document
which are accumulated and which are not) that require the
SORT and DIF() operation to produce valid interval data.
The JOB names that typically write subtype 6 records are:
ALLOCAS CONSOLE EYUX130 GRS IEFSCHAS JES2AUX JES3AUX
PCAUTH RACFDS RASP SMXC SYSBMAS TNF TRACE
VMCF
The dataset sort macro _STY30U6 for TYPE30_6 was revised
to deaccumulate the TYPE30_6 data into PDB.TYPE30_6, and
comments in VMAC30 list which variables are kept, dif()d,
which are not, and which are always missing values. Only
the PROD, ID, UREC, CPU, STOR, and PERF segments exist.
The change also corrects variables INTBTIME/INTETIME in
TYPE30_6. Because subtype 6 records contain nulls for
the SMF30IST timestamp from which GMTOFF30 is calculated,
INTB/INTE were never converted from GMT in TYPE30_6. By
revising the logic so that INTBTIME=SMF30IST only when
SMF30IST is non-missing, and by only calculating GMTOFF30
only when SMF30IST is non-missing, the GMTOFF30 from the
prior type 30 (non-subtype-6) can be used to convert GMT.
Thanks to Ron Hackett, US West, USA.
Change 17.008 Cosmetic. The &MACSHFT statement was moved to the end of
IMACSHFT the member.
Mar 4, 1999
Thanks to Chuck Hopf, MBNA, USA.
Change 17.007 TYPE50 dataset. Input should be BSIZE &PIB.4. instead of
VMAC50 BSIZE ?? 4. and the input of MXTRSIZE should be @75+
Mar 2, 1999 rather than @74+.
Thanks to Peter Durrant, National Australia Bank, AUSTRALIA.
Change 17.006 Support for DB2 type 102 subtype 199 adds QW0199xx fields
VMAC102 that report DB2 Dataset I/O statistics (avg/min/max delay
Mar 2, 1999 time in millisecs for sync/async/cached I/O plus counts).
There is an observation for every Piece or Partition of
every DB2 dataset (DBID/OBID), but only if the piece/part
averaged more than one I/O per second in the interval.
Looks interesting, and I too have used a one-I/O-per-sec
threshold to separate the wheat from the chaff.
One test record out of ten has QW0199xx fields missing
because it has only two segments (QWHSNSDA=2) when
there should be three. To be investigated with IBM.
Thanks to Dennis Pugh, BMC, USA.
Change 17.005 In the "Print first 50 obs of every NTSMF dataset" macro
VMACNTSM _RNTPRNV, the PROC PRINT DATA=_LNTDDB2 should be _LNTDB2.
Mar 1, 1999
Thanks to Mike Kynch, International Paper, USA.
Change 17.004 SYNCSORT variable INVOKSAS was not always set; the test
VMACSYNC should be IF INVOKFLG='...1....'B THEN INVOKSAS='Y'; as
Mar 1, 1999 the value of CMFSAS are x'10' or x'11'.
Thanks to Bruce Christopher, Household International, USA.
Change 17.003 Support for Candle V400 Omegamon for CICS Epilog records.
VMACEPIL Change IF OMPRDVER=451 OR OMPRDVER=450 THEN DO; to read
Feb 24, 1999 IF OMPRDVER=451 OR OMPRDVER=450 OR OMPRDVER=400 THEN DO;
and add MACRO _EPILOFF OFFEPIL=4; % in member IMACKEEP,
as there is an extra four byte length field at the start
of the V400 record.
Thanks to Malcolm Campbell, Marks and Spencer, ENGLAND
Change 17.002 The TYPEUNIC support for CA UniCenter is not for Unix,
TYPEUNIC but is for the Open VMS or VMS operating system, and test
Feb 22, 1999 data validated was from VMS 7.0. Also, the suffix is
UNIC (UNCI was typoed in change 16.391 and Newsletter).
The code is fine, I just failed to realize the data was
from VMS (but I
Change 17.001 The optional IMAC6ESS for the type 6 ESS segment was fine
IMAC6ESS under MVS, but the $VARYING fields were not converted to
Feb 22, 1999 EBCDIC when run under ASCII SAS. The INPUT and TRANSLATE
functions were added to correct.
LASTCHANGE: Version 17.