COPYRIGHT (C) 1984-2023 MERRILL CONSULTANTS DALLAS TEXAS USA
MXG CHANGES 18.18
=========================member=CHANGE18================================
/* COPYRIGHT (C) 1984-2001 MERRILL CONSULTANTS DALLAS TEXAS USA */
MXG Version 18.18 is dated Feb 12, 2001, thru Change 18.360.
MXG Newsletter THIRTY-EIGHT is dated Feb 12, 2001.
MXG Version 18.12 was dated Jan 30, 2001, thru Change 18.341.
MXG Version 18.11 was dated Jan 4, 2001, thru Change 18.315.
First MXG Version 18.10 was dated Dec 20, 2000, thru Change 18.303.
MXG Version 18.09 was dated Oct 24, 2000, thru Change 18.264.
MXG Newsletter THIRTY-SEVEN was dated Oct 24, 2000.
MXG Version 18.08 was dated Sep 25, 2000, thru Change 18.238.
MXG Version 18.07 was dated Aug 31, 2000, thru Change 18.217.
First MXG Version 18.07 was dated Aug 30, 2000, thru Change 18.216.
Test MXG Version 18.07 was dated Aug 27, 2000, thru Change 18.204.
MXG Version 18.06 was dated Jul 28, 2000, thru Change 18.177.
MXG Version 18.05 was dated Jul 1, 2000, thru Change 18.154.
MXG Version 18.04 was dated May 15, 2000, thru Change 18.109.
Final MXG Version 18.03 was dated Apr 17, 2000, thru Change 18.086.
MXG Version 18.03 was dated Apr 12, 2000, thru Change 18.083.
First MXG Version 18.03 was dated Apr 11, 2000, thru Change 18.081.
Final MXG Version 18.02 was dated Mar 29, 2000, thru Change 18.052.
Second MXG Version 18.02 was dated Mar 16, 2000, thru Change 18.046.
First MXG Version 18.02 was dated Mar 15, 2000, thru Change 18.043.
MXG Version 18.01 was dated Mar 3, 2000, thru Change 18.021.
MXG Version 17.17 was dated Feb 7, 2000, thru Change 17.398.
Newsletter THIRTY-SIX was dated Feb 7, 2000, thru Change 17.398.
Contents of member CHANGES:
Member NEWSLTRS (and the Newsletters frame at http://www.mxg.com) now
contain the current MXG Technical Notes that used to be put in member
CHANGES between Newsletters. New Technical Notes are now added (and
now dated!) in NEWSLTRS/Newsletters with each new MXG Version.
I. MXG Software Version 18.18 was shipped to all MXG licensees.
II. Incompatibilities and Installation of MXG 18.18.
III. Online Documentation of MXG Software.
IV. Changes Log
=======================================================================
I. MXG Software Version 18.18 is the annual version, Feb 12, 2001, and
it was sent to all MXG sites, and contains NEWSLETTER THIRTY-EIGHT.
Major enhancements added in MXG 18.18:
Support for z/OS Version 1.1 (COMPATIBLE).
Support for CICS/TS for z/OS Version 2.1 (INCOMPATIBLE).
Support for DB2 Version 7.1 (COMPATIBLE).
Support for Vital Signs VisionNet VSV TCPIP stats.
Support for Innovation Data Processing's FDR SMF.
Support for SYNCSORT Release 3.7 (COMPAT).
Support for IBM TapeTools MOUNTMON user SMF record.
ASUMTALO MAXDRVS greater than installed tape drives corrected.
New MACRO _Vdddddd KEEP=x y z %; finally makes KEEP= easy.
Major enhancements added in MXG 18.12:
Support for CA UNICENTER TNG AIX, CISCO, NT, and SOLARIS objects.
Support for SOLVE SMF Subtypes 1 and 2.
Support for SHADOW SMF Subtype 6.
Support for IBM Domino WebServer Logs enhanced.
Support for DFSMSRMM 1.5 changes (COMPATIBLE).
Major enhancements added in MXG 18.11:
Support for DB2 Space Manager 2.1 (INCOMPAT).
Support for NPM APAR OW45788 corrects LXETxxxx.
Scheduling Environment variables added to PDB.JOBS
MXG execution under SAS V8.1 notes consolidated in NEWSLTRS member.
Documentation of the Internal Logic of BUILDPDB in DOCPDB member.
Erroneous EXCLUDED FIELDS message, MXG 18.10 only, TS 1.3 only.
Major enhancements added in MXG 18.10:
RMFINTRV now calculates MSU4HRAV 4-hour running MSU avg for z/OS.
DB2ACCT variable DB2TCBTM included Stored Proc AS CPU time twice.
Support for MQ Series V5.2 (INCOMPATIBLE) SMF 115 and SMF 116.
Support for Websphere Appl Server (EE) Component Broker SMF 120.
Support for TMON for MVS 2.0 NQ records corrected.
Support for ANALRMFR to create HTTP Server Report from SMF 103.
Using IMACJBCK for DB2ACCT selection saves CPU time
NPM Type 28 Subtype 'DC'x caused INPUT EXCEEDED.
CICINTRV request for "EOD" did not sum correctly.
CICS 1.3 SAP Journal records in CICSJOUR vice CICSSAP
Support for Vital Signs VisionNet VSAM file.
Short JES3 type 6 record protected.
Support for APAR OW37743 corrected.
CICINTRV DSA size variables corrected.
Support for NETVIEW SMF 38 APAR OW45728.
Major enhancements added in MXG 18.09:
Support for NPM APAR OW37743 (INCOMPATIBLE if TIC3 and 3746).
Support for Neon System's Shadow Server V4.5 SMF record.
Support for NTSMF ADSM, ColdFusion, MQSeries, WorldSecure objects.
Support for Candle's Omegamon for VTAM TCP record.
TYPE74 PCTDVUSE,PCTDVCON, etc for PAV Volumes now less than 100%.
GRAFWORK/GRAFRMFI/GRAFTAPE SAS/GRAPH examples now output as HTML
TYPE70 variable CPCMODEL ('RX6') added, was already in TYPE70PR.
Format $MGSASPR maps SAS PROC name to Product name, for SAS SMF.
Major enhancements added in MXG 18.08:
Support for Landmark TMON for VTAM.
Support for Landmark TMON for DBCTL.
Support for Omegamon for VTAM V500 (COMPAT).
Support for Enterprise Data Access, EDA, SMF record.
Support for AS/400 Collection Services records.
Summarization/Trending for STC datasets.
ANALUAFF finds wasted tape drives for SORT without UNIT=AFF.
Major enhancements added in MXG 18.07:
Support for OS/390 R2.10 (INCOMPAT!). See Change 18.134.
R2.10 support was included in MXG 18.06, although there was no
statement of support in that Version, and the Change text was
"Reserved". MXG 18.06 or later is required for OS/390 R2.10.
Support for BMC MainView for MQ Series History File V2.1.
Support for APAR II11493 (INCOMPAT) type 50 SMF.
Support for APAR PN61399 TCP type 118 SMF.
Support for NTSMF object "SESSION", from Term Svcs.
Support for APAR OW45168 SMF type 94 confirmed.
Support for APAR OW43854, adds OPENTIME to SMF 62 and 64.
VMXGSUM revisions, VIEW used, can avoid I/O, can be big savings.
ASUMUOW revised, MQ Series added to DB2+CICS, VIEW used for speed.
TYPE71 Memory (Hi,Med,Low Impact Frames) now correct and useful.
Datasets TYPE7 and TYPE23 now automatically built by BUILDPDB/3.
Example ANALCNCR and PROC TABULATE create HTML format reports.
New %MACRO VMXGENG returns the ENGINE of a SAS dataset.
MXG Y2K error, BMC CICS Manager type 110 segment corrected.
Major enhancements added in MXG 18.06:
Support for OS/390 R2.10 (INCOMPAT!). See Change 18.134.
Support for OS/400 Release 4.5.0 (INCOMPATIBLE).
Support for IHS WEBSERVER SMF 103 APAR PQ32435, adds JOB/ASID.
Support for BETA93 Release 321 INCOMPATIBLE subtype 1 record.
Revised support for TYPEEDGS/TYPEEDGB for DFSMS/rmm.
TCP SMF 118 Bad Record INPUT STATEMENT EXCEEDED corrected (again).
SAS Version 8.1 causes Condition Code 4 and prints log message:
WARNING: ARGUMENT 3 TO MACRO FUNCTION %SUBSTR IS MISSING
because the length of their &SYSVER Version macro was shortened
from four to three. There is no execution impact, fortunately,
except that the warning causes MVS Condition Code/Return Code of
four instead of zero, and wastes your time in reading this!
See further discussion in Change 18.159 which revises MXG.
Major enhancements added in MXG 18.05:
Support for Domino Server R5.0.3 subtypes 2 and 6.
Support for Type 42 RLS Subtype 19 enhanced, fixed.
Support for COM Tran Integrator, TN3270 Server, etc.
Support for new NTSMF Objects in Windows 2000 Server.
Support for IBM Websphere SMF type 103 subtype 2 undoc field.
Support for 3494 Peer-to-Peer (Gemini).
Support for APAR OW41317 support, INCOMPAT R2.7, R2.8, R2.9.
IMS Log Version 5.1 caused zero obs in IMSTRAN in TYPEIMSA.
ANALSMJB Who is filling your active VSAM SMF file utility.
MEMSIZE removed, S=72,S2=72 restored to CONFIGV8.
Trending of NTSMF LOGLDISK for NT disk space in TRNDNTLD.
Additional ESS variables now decoded from type 6.
Summarize TYPETCPT to track concurrent users in ASUMTCPT.
Major enhancements added in MXG 18.04:
SAS V8.0/V8.1 errors can corrupt variable labels in tape datasets
built by the V8SEQ "tape" engine. Until the errors are fixed, I
strongly recommend that you change the default "tape" engine to
V6SEQ instead of V8SEQ (by adding SEQENGINE=V6SEQ to the CONFIGV8
member in your CONFIG concatenation, and by changing any LIBNAMEs
with "TAPE" engine specified to "V6SEQ", as discussed in the SAS
Technical Note 5 in Newsletter-to-be THIRTY-SEVEN (in NEWSLTRS &
in Newsletters on homepage), and in the text of Change 18.104.
Update July 26: SAS ZAP Z8002651 exists and corrects the error,
so that with that ZAP installed, the V8SEQ engine can be used.
TYPEIMSB correction for IMS 6.1 log processing.
Support for Roger Software Development RSD FOLDERS.
Support for MainView for CICS 5.3.01 (INCOMPATIBLE).
Major enhancements added in MXG 18.03:
Support for OS/390 Release 2.9 (17.17 support was not correct).
Support for NETSPY Release 5.3 (COMPATIBLE).
Support for CMA Release 1.11 (COMPATIBLE).
Support for OAM Release 1.5.0 (INCOMPATIBLE) SMF 85.
Support for Systemware SYSOUT X/PTR, JHS, MPS, and C/QUE.
IMS Log OTMA/APPC transactions supported, dates fixed in ASMIMSLx.
ASUM70PR/ASUMCEC with ICFs had PCTLnBY and LPnDUR wrong
ASUMTALO corrected for SPINning (in-flight) allocations.
KEEPALL= argument for VMXGSUM was externalized to a Global macro.
Major enhancements added in MXG 18.02:
Support for Tivoli Netview Performance Monitor NPM 2.5 (SMF 28).
Support for GUTS Gutenberg Time Sharing user SMF records.
Support for optional CICS RMI counters.
Support for Oracle Version 7.3.3 (INCOMPATIBLE)
Support for retrofit APAR OW41317 was in MXG 17.17
Support for type 21 APAR OW40414, added four byte fields.
Recognition and non-counting of ICF processors is now corrected.
Major enhancements added in MXG 18.01:
MXG 18.01 replaced MXG 17.17 for ITSV sites. Changes made in MXG
17.17 to BUILDPDB/BUILDPD3, RMFINTRV, and ASUMTALO members had not
been tested with ITSV when MXG 17.17 was shipped. Change 18.009.
Using Report Performance Groups or Reporting Classes in IMACWORK
to define the workloads in our RMFINTRV dataset did not work in
MXG 17.17; enhancements to VMXGRMFI (invoked in RMFINTRV) support
using any mixture of report/control/service class to define your
RMFINTRV workloads. Revised UTILRMFI can be used to discover any
overlap if you get the "CPU TIMES DO NOT MATCH" error message.
Support for DB2 6.1 Buffer Pools 100+ in DB2ACCT/DB2STATS.
Support for Type 79 Subtype 15 IRLM Long Lock now validated.
ASUMUOW adds DB2ELAP to output, corrects wait for SPUN UOWs.
You can now use (COMPRESS=YES) with MACRO _Ldddddd definitions.
Blank value in JOBCLASS corrected.
ANALDSET needed _NULL to be added to its DATA statement.
Invalid Y2K date in BETA93 product now protected.
Type 39 record INPUT EXCEEDED RECORD error corrected.
See member NEWSLTRS or the Newsletters frame at www.mxg.com for
current MXG Technical Notes that used to be in CHANGES.
MXG 18.18 has been tested with SAS 6.09, SAS V8.0 TS M0/M1 and V8.1.
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.7.0 APAR OW41317 Mar 31, 2000 18.03
OS/390 2.8.0 Aug 24, 1999 16.09
OS/390 2.8.0 APAR OW41317 Mar 31, 2000 18.03
OS/390 2.8.0 FICON/SHARK Aug 24, 1999 17.08
OS/390 2.8.0 APAR OW41317 Mar 31, 2000 18.03
OS/390 2.9.0 Mar 31, 2000 18.03
OS/390 2.10.0 Sep 15, 2000 18.06
OS/390 PAV Oct 24, 2000 18.09
z/OS 1.1 Mar 30, 2001 18.11
CICS/ESA 3.2 Jun 28, 1991 9.9
CICS/ESA 3.3 Mar 28, 1992 10.01
CICS/ESA 4.1 Oct 27, 1994 13.09
CICS/ESA 5.1 aka CICS/TS V1R1 Sep 10, 1996 14.07
CICS-Transaction Server V1R1 Sep 10, 1996 14.07
CICS-TS V1R1 with APAR UN98309 Sep 15, 1997 15.06
CICS-TS V1R2 CICS/TS 1.2 Oct 27, 1997 15.06
CICS-TS V1R3 CICS/TS 1.3 Mar 15, 1999 17.04
CICS-TS for Z/OS Version 2.1 Mar 15, 2001 18.11
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 initial support Mar 15, 1999 16.09
DB2 6.1.0 all buffer pools Mar 15, 1999 18.01
DB2 7.1.0 Mar 30, 2001 18.11
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
NPM 2.5 Feb ??, 2000 18.02
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
SAS Institute
SAS V8 (TS M0), (TS M1):
(Read member NEWSLTRS (search 'V8') for other V8 notes.
MXG 16.16 runs, prints "options CODEPCT/BLKSIZE don't exist".
MXG 17.01 removed options in CONFIGv8 member, Change 17.073.
MXG 17.07 exploits 32K character var length, Change 17.253
MXG 17.08 exploits INHERIT option VMXGSUM, Change 17.265.
MXG 18.04 changes V8 default to SEQENGINE=V6SEQ. Change 18.104.
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 CICS V500 User SMF 18.01
Omegamon for IMS V110 (ITRF) 12.12
Omegamon for IMS V300 (ITRF) 14.04
Omegamon for MVS V300 13.05
Omegamon for MVS V400 13.06
Omegamon for DB2 Version 2.1/2.2 13.05
Omegamon for VTAM V160 12.04A
Omegamon for VTAM V400 15.15
Omegamon for VTAM V500 18.08
Omegamon for SMS V100/V110 12.03
CA
ACF2 6.2 16.04
ASTEX 2.1 14.04
NETSPY 4.7 14.03
NETSPY 5.0 14.03
NETSPY 5.2 16.05
NETSPY 5.3 18.03
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 18.03
IMS 5.1 - ASMIMSL5/TYPEIMSA 18.03
Amdahl
APAF 4.1, 4.3 16.08
II. Incompatibilities and Installation of MXG 18.10.
MXG Definitions with regard to MXG Software Changes:
COMPATIBLE A change in a data record which did not alter either
the location or the format of all of the previously-
kept MXG variables is COMPATIBLE, and you can continue
to run the old version of MXG software, which will read
the new records without error, but none of any new data
fields or any new record subtypes will be created/kept
until you install the MXG Version with this change.
A change that alters any previously kept variable is
INCOMPATIBLE, and requires the new version to be used.
TOLERATE In other words, the old MXG Version TOLERATES the new
data records, if they are COMPATIBLY changed.
EXPLOIT Once you use the new MXG Version to read the changed
records, all of the new fields, subtypes, etc, that are
described in this change will be created in the MXG
datasets, so the new MXG Version EXPLOITS the new data,
and you have full support of the new data records.
INCOMPAT A change in a data record that causes the current MXG
version to fail, visibly or invisibly, with or without
error conditions or messages, and the output datasets
may contain wrong values and incomplete observations,
and/or observations may have been lost.
You MUST install the new MXG Version with this change
to process data records that have been INCOMPATIBLY
changed by their vendor.
1. Incompatibilities introduced in MXG 18.10 (since MXG 17.17):
a- No changes in MXG architecture were made between 17.17 and 18.10
that introduced incompatibilities.
2. Installation and re-installation procedures are described in detail
in member INSTALL (which also lists common Error/Warning messages a
new user might encounter), and sample JCL is in member JCLINSTL.
III. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
See also member INDEX, but it may be overwhelming.
IV. Changes Log
--------------------------Changes Log---------------------------------
You MUST read each Change description to determine if a Change will
impact your site. All changes have been made in this MXG Library.
Member CHANGES always identifies the actual version and release of
MXG Software that is contained in that library.
The CHANGES selection on our homepage at http://www.MXG.com
is always the most current information on MXG Software status,
and is frequently updated.
Important changes are also posted to the MXG-L ListServer, which is
also described by a selection on the homepage. Please subscribe.
The actual code implementation of some changes in MXG SOURCLIB may be
different than described in the change text (which might have printed
only the critical part of the correction that need be made by users).
Scan each source member named in any impacting change for any comments
at the beginning of the member for additional documentation, since the
documentation of new datasets, variables, validation status, and notes,
are often found in comments in the source members.
Alphabetical list of important changes after MXG 17.17 now in MXG 18.10:
Dataset/
Member Change Description
SAS V8 18.xxx SAS Version 8.1 notes are updated in member NEWSLTRS.
many 18.001 Duplicate removal by MXG _Sdddddd macro enhanced.
many 18.338 Description of soon-to-be-pervasive MACRO _Vdddddd.
many 18.317 Support for z/OS R1.1 (COMPATIBLE).
many 18.338 New MACRO _Vdddddd KEEP=x y z % ; syntax defined.
ANAL94 18.218 Report failed with PDB=SMF/PDBOUT=PDB.
ANALCNCR 18.326 Support for interval specification of MINUTE.
ANALCNR 18.089 Last period for synchronized intervals corrected.
ANALDB2R 18.067 Negative DD counts for OPEN/USED DDs in reports.
ANALDB2R 18.246 DB2 Report PMAUD03 failed, semicolon missing.
ANALDB2R 18.329 DB2 Accounting Summary enhanced for DB2 Version 6.
ANALDSET 18.010 _NULL_ needs to be added to DATA statement.
ANALHTML 18.177 ANALCNCR/PROC TABULATE HTML format reports w/ODS.
ANALRMFR 18.028 Partition Data Report supports CP/ICF.
ANALRMFR 18.302 Support for RMF HTTP Server Report from SMF 103.
ANALSMJB 18.149 Who is filling your active VSAM SMF file utility.
ANALTCP 18.091 Sample TCP/IP basic analysis reports.
ANALUAFF 18.234 Detect wasted tape drives for SORT without UNIT=AFF.
ASMIMSL5 18.030 APPC transactions caused negative SERVICETM
ASMIMSL5 18.060 IMS transactions thru OTMA and APPC revised.
ASMIMSL6 18.287 Assembly error: CLOSE (R3) s/b CLOSE ((R3)).
ASUM42DS 18.140 Variables CIOPCT, HITPCT, RDHITPCT were incorrect.
ASUM70PR 18.131 Amdahl SMF 70 LPARNUM=0, LPARNAME=Inactive error.
ASUMSTC 18.235 Summarization/Trending for STC datasets.
ASUMTALO 18.013 Failed under ITSV or with USER=WORK: Member Lock....
ASUMTALO 18.346 MAXDRVS greater than installed tape drives corrected.
ASUMTCPT 18.122 Summarize TYPETCPT to track concurrent users.
ASUMUOW 18.007 Wait times for spun UOWs corrected, DB2ELAP added.
ASUMUOW 18.204 Major rewrite, adds MQ Series data, easy tailoring.
BLDNTPDB 18.145 Revisions to use symbolics instead of hardcode dsn.
BUILDPD3 18.124 BUILDPD3 fails, VARS NOT SORTED WORK.TYPE25.
BUILDPDB 18.018 Blank value for JOBCLASS corrected.
BUILDPDB 18.094 If you want to write the PDB output to tape.
BUILDPDB 18.184 Datasets TYPE7 and TYPE23 now automatically built.
BUILDPDB 18.217 BUILDPDB Missing _S21 to build PDB.TAPES.
BUILDPDB 18.259 Do not redefine MACRO _BLD005 under SAS V8.
BUILDPDB 18.306 Scheduling Environment variables added to PDB.JOBS
BUILDPDB 18.312 Variable DATETIME now contains correct value.
BUILDxxx 18.014 Warning CODEPASS=2 eliminated, can be disregarded.
CONFIGV8 18.104 SAS V8 requires SEQENGINE=V6SEQ for tape datasets.
CONFIGV8 18.147A MEMSIZE removed, S=72,S2=72 restored to CONFIGV8.
DOCITSV 18.310 Example of ITSV macros needed to add new variable.
DOCMXG 18.168 Example of how to use USER=XYZ with MXG.
DOCPDB 18.315 Documentation of the Internal Logic of BUILDPDB.
EXCECTIM 18.066 Exit for PDB.ASUMCEC with different system clocks.
FORMATS 18.240 SAS user SMF record, $MGSASPR maps Proc to Product.
FORMATS 18.256 MG073CD decodes OSA EXPRESS and OSA EXPRESS DIRECT.
GRAFRMFI 18.263 GRAFRMFI Graphs from RMFINTRV now output as HTML.
GRAFSAMP 18.264 GRAFWORK sample using mainframe PDB, output to LAN.
GRAFTAPE 18.262 GRAFTAPE MXGTMNT and STK TRENDing, output as HTML.
GRAFWORK 18.264 GRAFWORK Graphs from RMFINTRV now output as HTML.
GRAFxxxx 18.220 SAS V8.0 (not 8.1) ERRORABEND with missing values.
IMAC6ESS 18.138 Additional ESS variables now decoded from type 6.
IMACICBB 18.190 MXG Y2K error, BMC CICS Manager now data-validated.
IMACICUS 18.036 Support for optional CICS RMI counters added.
IMACJBCK 18.289 Using IMACJBCK for DB2ACCT selection saves CPU time
JCLIMSL5 18.318 SORT FIELDS value should have been 35,8.
JCLMNTH 18.113 Monthly failed trying to build MONTH.ASUMCEC.
JCLUWOV 18.204 JCL Example for CICS+DB2+MQ Series merge.
MONTHBLD 18.135 WEEKBLD and MONTHBLD had wrong BY for TYPE30MU.
PRINTNL 18.058 No output if you did not use MXGSAS or CONFIG=.
RMFINTRV 18.000 Failed under ITSV, because of hardcode PDB.RMFINTRV.
RMFINTRV 18.111 Variable MVSLEVEL now kept in RMFINTRV.
RMFINTRV 18.298 Calculation of z/OS License Manager MSU4HRAV added.
RMFINTRV 18.345 High/Med/Low Impact Frame variables added to RMFINTRV
TRNDNTLD 18.145 Trending of NTSMF LOGLDISK for NT disk space util.
TYPE102 18.178 DB2 6.1 only, IFCID 106, end comment missing.
TYPE102 18.330 SQL Text truncated to 100 characters with V8/NoCOMP.
TYPE103 18.092 TYPE1032 dataset had missing values for variables.
TYPE103 18.129 IBM Websphere SMF type 103 subtype 2 undoc field.
TYPE103 18.172 Support for IHS WEBSERVER SMF 103 APAR PQ32435.
TYPE103 18.198 Variable BYREADCA negative, now BYREADCA=KBREADCA.
TYPE108 18.119 Support for Domino Server R5.0.3 subtypes 2 and 6.
TYPE110 18.188 INPUT STATEMENT EXCEEDED 110 Journal GLRHTYPE=2.
TYPE110 18.250 CICS STAT STID=126 zero obs in CICCFS6D dataset.
TYPE110 18.276 CICS 1.3 SAP Journal records in CICSJOUR vice CICSSAP
TYPE110 18.313 EXCLUDED FIELDS error message for TS 1.3 in error.
TYPE110 18.314 Support for CICS/TS for z/OS Version 2.1 (INCOMPAT).
TYPE110 18.333 New "Header" exit IHDR110S to skip unwanted STID's.
TYPE115 18.292A Support for MQ Series V5.2 (INCOMPATIBLE)
TYPE116 18.292A Support for MQ Series V5.2 (INCOMPATIBLE)
TYPE120 18.299 Support for Websphere Appl Server Comp Brok SMF 120.
TYPE21 18.026 Support for APAR OW40414, adds four byte fields.
TYPE28 18.032 Support for Tivoli Netview NPM V2R5 new subtypes.
TYPE28 18.254 Support for NPM APAR OW37743 (INCOMPAT if TIC3,3746).
TYPE28 18.257 NPM 28 NPMSUBTY=14x NRT non-fatal MXG messages.
TYPE28 18.273 Support for APAR OW37743 corrected.
TYPE28 18.279 NPM Type 28 Subtype 'DC'x caused INPUT EXCEEDED.
TYPE28 18.308 Support for NPM APAR OW45788 corrects LXETxxxx.
TYPE30 18.001 _Bdddddd list macros were updated for NODUP.
TYPE30 18.286 Init delays SMF30JQT/RQT/HQT/SQT incorrect.
TYPE30 18.344 Some duplicate steps were not removed by NODUP.
TYPE37 18.266 Support for NETVIEW SMF 38 APAR OW45728.
TYPE38 18.015 INPUT EXCEEDED RECORD SMF type 38 record.
TYPE39 18.185 Protection for NETVIEW SMF 39 overlaid ROUTE seg.
TYPE42 18.118 Support for Type 42 RLS Subtype 19 enhanced, fixed.
TYPE42 18.334 TYPE42XR dataset (XRC) was trashed; misaligned INPUT.
TYPE50 18.197 Support for APAR II11493 (INCOMPAT) type 50 SMF.
TYPE6 18.137 Variable CUTSHEET in TYPE6/PDB.PRINT was wrong.
TYPE6 18.274 Short JES3 type 6 record protected.
TYPE64 18.187 Support for APAR OW43854, adds OPENTIME to SMF 64.
TYPE70 18.258 Variable CPCMODEL ('RX6') added to TYPE70.
TYPE7072 18.023 SMF70CIN was reread, didn't remove ICFs.
TYPE7072 18.027 Support for retrofit APAR OW41317 was in MXG 17.17.
TYPE7072 18.120 APAR OW41317 support, INCOMPAT R2.7 or R2.8.
TYPE71 18.199 TYPE71 Memory (Hi,Med,Low Impact Frames) now useful.
TYPE74 18.049 "Broken RMF Record" over-protective, revised.
TYPE74 18.125 Extra observations in TYPE746B (HFG Global Buffs).
TYPE74 18.166 Variables R744Cxxx in TYPE74ST wrong in 2nd segment.
TYPE74 18.261 TYPE74 for PAV had over 100% for PCTDVUSE/ACT/CON/PND
TYPE79 18.004 Type 79 subtype 15 IRLM Long Lock now validated.
TYPE80A 18.024 INPUT STATEMENT EXCEEDED in RACFTYPE=39 segment.
TYPE85 18.055 Support for OAM Release 1.5.0 (INCOMPATIBLE) SMF 85.
TYPE94 18.123 Support for 3494 Peer-to-Peer (Gemini).
TYPE94 18.176 Support for APAR OW45168 confirmed.
TYPEAPAF 18.021 Support for APAF Release 4.6.
TYPEBETA 18.019 Invalid Y2K date now protected in BETA93 records.
TYPEBETA 18.164 Support for BETA93 Release 321 INCOMPATIBLE.
TYPECIMS 18.051 IMF Fast Path INPQUEUE, ARRIVTIME corrected.
TYPECIMS 18.191 New variable PSBNAME was still blank.
TYPECIMS 18.225 Counts in CIMSDB2 and CIMSDBDS wrong after Ch 17.303.
TYPECMA 18.056 Support for CMA Release 1.11 (COMPATIBLE).
TYPECMA 18.142 Subtype 6 variable SMFT06PC incorrect.
TYPEDB1 18.226 Variable JOB in DB2ACCT can be blank.
TYPEDB2 18.003 Support for DB2 6.1 Buffer Pools 100+ in DB2ACCT.
TYPEDB2 18.202 DB2GBPST,DB2STATS some QGBxxxx and QXxxxx vars wrong.
TYPEDB2 18.305 Support for DB2 Version 7.1 (COMPATIBLE).
TYPEDB2 18.348 QWAXxxxx variables now put back in QWACxxxx.
TYPEDCOL 18.224 DCOLLECT sort macros now remove duplicates.
TYPEEDA 18.227 Support for Enterprise Data Access, EDA, SMF record.
TYPEEDGR 18.322 Support for DFSMSRMM 1.5 changes (COMPATIBLE).
TYPEEDGS 18.128 DFSMS/rmm dataset EDGSVREC had blank dataset names.
TYPEEDGS 18.162 Support for DFSMS/rmm TYPEEDGS/TYPEEDGB still wrong.
TYPEEREP 18.183 EREP Symptom Record was incorrectly output.
TYPEFDR 18.351 Support for Innovation Data Processing's FDR SMF.
TYPEFTP 18.141 Variable DVGSBCNT has always been wrong.
TYPEGUTS 18.040 Support for GUTS, Gutenberg Time Sharing, SMF.
TYPEICE 18.136 RECTYPE=5 records were incorrectly output.
TYPEIMSB 18.103 IMS log processing, 18.03 only, IMS 6.1 only, error.
TYPEIMSB 18.139 IMS Log Version 5.1 caused zero obs in IMSTRAN.
TYPEIMSB 18.283 IMS 6.1, MSGSZOUT a constant, wrong value.
TYPEMIM 18.029 Variables labeled and reformatted
TYPEMVCI 18.087 Support for MainView for CICS 5.3.01 (INCOMPATIBLE).
TYPENSPY 18.069 Support for CA's NETSPY 5.3 (COMPATIBLE).
TYPENSPY 18.232 STOPOVER ABEND NETREC='I' with NSPYENTL=124.
TYPENSPY 18.323 Variable TIC_UTIL now created in NSPYTIC3 dataset.
TYPENTSM 18.110 Support for COM Tran Integrator, TN3270 Server, etc.
TYPENTSM 18.143 Support for new NTSMF Objects in Windows 2000 Server.
TYPENTSM 18.193 Support for NTSMF object "SESSION", from Term Svcs.
TYPENTSM 18.245 Support for NTSMF ADSM/ColdFusn/MQSeries/WorldSecure
TYPEOMVT 18.229 Support for Omegamon for VTAM V500 (COMPAT).
TYPEOMVT 18.244 Support for Candle's Omegamon for VTAM TCP record.
TYPEORAC 18.034 Support for Oracle Version 7.3.3 (INCOMPATIBLE).
TYPEORAC 18.133 Oracle CPUTM is revised based on Oracle feedback.
TYPEQACS 18.222 Support for AS/400 Collection Services records.
TYPEQAPM 18.173 Support for OS/400 Release 4.5.0 (INCOMPAT LRECLs).
TYPERMFV 18.326 CSA, ECSA, SQA, ESQA variables calculated.
TYPERMFV 18.349 Support for RMF III for z/OS (COMPAT).
TYPERSDF 18.093 Support for Roger Software Development RSD FOLDERS.
TYPESARR 18.270 SARRU33 records from CA-VIEW subtype 33 corrected.
TYPESHDW 18.247 Support for Neon System's Shadow Server V4.5 SMF.
TYPESHDW 18.311 Support for SHADOW SMF Subtype 6.
TYPESOLV 18.332 Support for SOLVE SMF Subtypes 1 and 2.
TYPESPMG 18.311 Support for DB2 Space Manager 2.1 (INCOMPAT).
TYPESTC 18.035 VTCS 2.2 VTV Timestamps invalid, corrected.
TYPESYNC 18.347 Support for SYNCSORT Release 3.7 (COMPAT).
TYPETCP 18.171 TCP SMF 118 Bad Record INPUT STATEMENT EXCEEDED.
TYPETCP 18.196 Support for APAR PN61399 TCP type 118 SMF.
TYPETLMS 18.355 Support for TLMS 5.5 records; there was no change.
TYPETMDC 18.231 Support for Landmark TMON for DBCTL.
TYPETMS5 18.054 PROC SORTs now have _WTMSTMS/_WTMSDSN for Work copy.
TYPETMV2 18.290 Support for TMON for MVS 2.0 NQ records corrected.
TYPETMVT 18.236 Support for Landmark TMON for VTAM.
TYPETNG 18.337 Support for CA's UNICENTER TNG performance cubes.
TYPEVITA 18.275 Support for Vital Signs VisionNet VSAM file.
TYPEVITA 18.353 Support for Vital Signs VisionNet VSV TCPIP stats.
TYPEWWW 18.327 Support for IBM Domino WebServer Logs enhanced.
TYPEXPTR 18.073 Support Systemware SYSOUT X/PTR, JHS, MPS, and C/QUE
UTILRMFI 18.017 Utility to detect overlap in RMFINTRV workloads.
VMACDB2 18.300 DB2ACCT variable DB2TCBTM included SPAS CPU twice.
VMXGCICI 18.268 CICINTRV DSA size variables corrected.
VMXGCICI 18.278 CICINTRV request for "EOD" did not sum correctly.
VMXGDEL 18.020 You can use (COMPRESS=YES) with MACRO _Ldddddd.
VMXGDUR 18.326 Support for interval specification of MINUTE.
VMXGENG 18.182 New %MACRO to determine the ENGINE of a SAS dataset.
VMXGRMFI 18.009 Using Report PGNs or Reporting Classes didn't work.
VMXGRMFI 18.038 Added COMPAT GOAL SYSx to USECNTRL/USEREPRT
VMXGRMFI 18.062 New RMFINTRV parms KEEPPGN/KEEPRPGN/KEEPSRV/KEEPRSRV
VMXGRMFI 18.088 Using VMXGRMFI with TREND= and PDB=blank corrected.
VMXGSUM 18.182 VIEW used to avoid physical I/O, can be big savings.
VMXGSUM 18.326 Support for interval specification of MINUTE.
VMXGUOW 18.204 New %MACRO to support ASUMUOW revisions.
VMXGUOW 18.281 Logic errors corrected.
WEEKBLD 18.135 WEEKBLD and MONTHBLD had wrong BY for TYPE30MU.
Inverse chronological list of all Changes:
NEXTCHANGE: Version 18.
======Changes thru 18.360 were in MXG 18.18 dated Feb 12, 2001======
Change 18.360 Support for IBM's free MOUNTMON tape mount and allocation
EXMOUNTM monitor creates the new MOUNTMON dataset from either the
TYPEMOUN flat file or the SMF record. Support for this monitor
TYPSMOUN was prompted by concerns that the MXG Tape Mount Monitor
VMACMOUN was missing fast, scratch Virtual Tape mounts, and if the
VMXGINIT IBM freebie did better, I was prepared to restructure the
Feb 11, 2001 ASUMTAPE logic to use their record instead of ASMTAPE's
TYPFMOUN SMF record, but the initial comparison with three day's
data with both monitors running showed MOUNTMON saw 462
mounts with 1 second sampling and MXGTMNT saw 452 with 2
second default sampling, so I'm greatly encourages that
no errors are seen in MXGTMNT capture of mounts. However
as the IBM monitor captures Device Pend/Dis/and Connect
times, I will evaluate an enhancement to combine both
monitor's data and improve the quality of MXG measurement
of tape mounts and tape drive usage. The IBM MOUNTMON
monitor is written and supported by Dennis Haight, and is
available at ftp://ftp.software.ibm.com/storage/tapetool/
-Member TYPFMOUN processes the flat file when MOUNTMON is
not writing to SMF.
Thanks to Mike Shapland, (i)Structure, USA.
Change 18.359 This analysis of the new z/OS MSU capacity was provided
ANALMSU by Alan Sherkow. See the text of Change 18.298 for the
Feb 11, 2001 discussion of PDB.RMFINTRV's new MSU4HRAV variable that
measures your current capacity in Millions of Service
Units (per hour) for License Manager pricing.
Thanks to Al Sherkow, I/S Management Strategies Ltd, USA.
Change 18.358 My QA stream reports variables with blank labels, but now
DOC I've actually used it to clean up labels in these members
Feb 11, 2001 ASUMCACH ASUMTAPE ASUMVMON CHANGES TYPEIMS TYPETMS5
VMAC30 VMAC42 VMAC50 VMAC90A VMAC91 VMACBGSI
VMACGUTS VMACHURN VMACIMS VMACNTSM VMACRSDF VMACSTC
VMACTMDB VMACTMS5 VMACTMV2 VMACTNG VMACVITA VMACXPTR
VMXGRMFI. These member's update date was updated but
the last change referenced is the prior change.
Change 18.357 Eight TMS flag variables from the TMSREC record are now
TYPETMS5 propagated into the pseudo TMSDSNB observation created
VMACTMS5 from the TMSREC. The DSNBssss suffixes updated are
Feb 11, 2001 DSNBUSRU/TMSI/ECAT/ABND/ISCA/DFXU/WSCA/DFLT (into DSNB)
UPD/ETM/CAT/ABN/FILEISCA/DEFEXPOO/E99/DEF (from TMS).
New DEVTYPE values for Redwood, STK 9842 and 3590E are
created from TRTCH values of E4-E7 and EA-EB.
Thanks to David Ehresman, University of Louisville, USA.
Change 18.356 SAS SMF record pads SASPROC with '00'x instead of blank,
VMACSASU causing SASPROD to be UNKNOWN because the $MGSASPR table
Feb 9, 2001 expected blanks. SASPROC= TRANSLATE(SASPROC,' ','00'x);
was added to convert the '00'x to blank (and note that
a blank, rather than '40'x is used so the code will work
under either ASCII or EBCDIC) before the create of:
SASPROD=PUT(SASPROC,$MGSASPR.);
Thanks to Jim Peddycord, The Northern Trust Company, USA.
Change 18.355 Support for TLMS 5.5 records; there were no changes to
TYPETLMS the record or to MXG; this is just for documentation.
Feb 9, 2001
Change 18.354 Collected updates and new features added.
ASUMCACH -ASUMCACH added KEEPALL=YES, ID=DEVICE and the logic to
ASUMSMFI keep only DASD devices; tape devices were reported.
FORMATS -New ASUMSMFI summarizes PDB.SMFINTRV, keeping only the
VMXG2DTE variables needed for problem solving and accounting.
ASUM23 -New format MGPCTGR is used to print horizontal graphs in
TRND23 DB2 reporting.
ASUMVMNT -New VMXG2DTE macro is self-documenting and provides the
TRNDVMNT creation of week-to-date and month-to-date summarization.
ASUMVTVM The algorithms can interleave or APPEND the output.
ADOCUOW -Summarization and trending of TYPE23 (SMF activity) is
Feb 12, 2001 provided in the new ASUM23/TRND23 members
-Summary of VSM recall and migrate activity by hour from
STCVSM19 records is provided in new ASUMVTVM member.
-Summary of VSM mount activity is summarized in ASUMVMNT
and TRNDVMNT from STCVSM13 records.
-Revision of documentation for large volume CICS/DB2 shows
how best to set up VMXGUOW processing, in member ADOCUOW.
Thanks to Chuck Hopf, MBNA, USA.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 18.353 Support for Vital Signs VisionNet Record created new MXG
EXVITATC dataset VSVTCPIP with VSV TCPIP Interface Stats, but
IMACVITA there will be additional datasets created from their VSAM
TYPEVITA file.
TYPSVITA
VMACVITA
Feb 8, 2001
Thanks to Craig Collins, State of Wisconsin IT Services, USA.
Change 18.352 Running MXG under ASCII SAS to create DB2ACCT dataset did
VMACDB2H not convert the NETSNAME to ASCII, so you could not match
Feb 8, 2001 the DB2 plan back to its CICS transaction.
Thanks to Mark Cohen, DTS, ITALY.
Change 18.351 Support for Innovation Data Processing's FDR user SMF
EXFDRDSF record creates new FDRDSF dataset with an observation for
FORMATS each FDR event.
IMACFDR
TYPEFDR
TYPSFDR
VMACFDR
VMXGINIT
Feb 8, 2001
Thanks to Shawn Beardsley, NDC Health Information Services (AZ), USA.
Change 18.350 Cosmetic. Labels were missing for variables in VMACDB2
VMACDB2 (PLAN,TRAN), in VMAC28(NRTDTYPE), in VMXGRMFI(CECSUSEC),
VMAC28 VMAC42(SMF42NRS), and VMAC74(SMF74CNF,SMF74CNX). Labels
VMXGRMFI for CSFRxxAV and ESFRxxAV that didn't have AVE, now do.
VMAC42
Feb 7, 2001
Thanks to Chris Weston, SAS Institute ITSV, USA.
Change 18.349 Support for RMF III changes for z/OS COMPATIBLY added a
EXZRBCPU few fields, and three previously undecoded segments are
EXZRBCSR now decoded to create these three new datasets:
EXZRBPGP ZRBCPU - Processor
IMACRMFV ZRBCSR - Common Storage Remaining
VMACRMFV ZRBPGP - Performance Group Period
VMXGINIT This change also added the CSA/ECSA/SQA/ESQA variables in
Feb 5, 2001 Change 18.325. Many variables are still the accumulated
value, and have not been divided by their sample count.
Please validate that the variables of interest to you do
match their RMF III screen values, and let me know if you
find any needed corrections for MXG variables.
Thanks to Thom Kight, Fidelity Systems, USA.
Change 18.348 MXG created QWAXvvvv variables in DB2ACCT from the new
VMACDB2 QWAX segment, but I failed to realize that most of those
Feb 5, 2001 QWAX fields were existing QWACvvvv variables, with some
new QWAX fields. Instead of extending QWAC, IBM created
the new QWAX segment; if it exists, your QWAC fields are
all zero. I should never have created the QWAXvvvv names.
So this change now stores the QWAXvvvv values in QWACvvvv
variables that exist, and creates new QWACvvvv variables
for the new QWAX fields.
I should DROP the QWAXvvvv variables now, but I can't do
that without warning, as those few of you who found the
QWAX variable names would have reports failed, so this is
your warning: Do Not use QWAXvvvv variable names.
Use their QWACvvvv counterpart instead.
Variable names starting with QWAXvvvv will go away soon!
And if you want to drop them now, with this change, you
can use the _KDB2ACC macro to drop them, with:
MACRO _KDB2ACC DROP=
QWAXALCT QWAXALOG QWAXANAR QWAXARNC QWAXARND QWAXAWAR
QWAXAWCL QWAXAWDR QWAXOCSE QWAXSLSE QWAXDSSE QWAXOTSE
QWAXOCNS QWAXSLNS QWAXDSNS QWAXOTNS
QWAXAWFC QWAXFCCT QWAXIXLE QWAXIXLT
QWAX fields so your existing and future programs work
with the same QWACvvvv names in your future reports, and
this change accomplishes that: use QWACvvvv instead of
QWAXvvvv in any reports you write.
QWAXxxxx variables should not have been created at all,
but since I can't safely DROP them without warning, here
is your warning:
Don't USE DB2ACCT variables named QWAXxxxx;
Instead, use QWACxxxx with the same suffix
Thanks to Alan Winston, MBNA,USA.
Change 18.347 Support for SYNCSORT Release 3.7 (COMPAT) adds variables.
VMACSYNC SYNCSORT now permits up to 100 SORTWORK DDs, so VMACSYNC
Feb 8, 2001 can creates up to 100 sets of variables for each sort
work area, but the MXG default is 32, previously the max
that SYNCSORT allowed. You can increase the number of
sets of variables if you have more than that:
-You can change it permanently by adding this statement in
your IMACKEEP member to re-definite the default value:
MACRO _NSYNCWK 100 %
-Or, to increase it just for this execution of TYPSSYNC,
you can change it "Instream" with this in your //SYSIN:
%LET MACSYNC= MACRO _NSYNCWK 99 % ;
(you can track variable NRWRKUSE in TYPESYNC to see if
more than 32 sort works are being used).
Note: Dec 2001: The DDnames are SORTWK00-SORTWK99, but
SAS will start with SORTWK01 and not use SORTWK00.
Thanks to Chuck Hopf, MBNA,USA.
Change 18.346 ASUMTALO could have MAXDRVS greater than installed drives
ASUMTALO when tape drives are switched between systems, because of
Feb 3, 2001 slightly different timer pops on different systems. One
event with ALOCEND=11:22:05.79 on SYSA was followed by an
event with ALOCSTRT=11:22:05.60 on SYSB. The overlap is
always less than the monitor interval (2 second default);
code inserted into an existing step now detects any such
overlap and resets the ALOCSTRT to the previous ALOCEND.
Thanks to Bruno Peeters, Dexia, BELGIUM.
Change 18.345 The High/Med/Low Impact Average Frame variables are now
VMXGRMFI MAX'ed for each interval and added to PDB.RMFINTRV. The
Feb 2, 2001 variables that are added are these:
CSFRSRAV CSFRWLAV CSFRFXAV CSFRLSAV CSFRTOAV CSFRAVAV
CSFRHIAV CSFRLOAV CSFRMEAV ESFRSRAV ESFRWLAV ESFRHSAV
ESFRLSAV ESFRTOAV ESFRAVAV ESFRHIAV ESFRLOAV ESFRMEAV
Thanks to Peter Smith, SEMA, ENGLAND.
Change 18.344 Some duplicate steps were not removed by PROC SORT NODUP
VMAC30 because the BY list did not force adjacency if there was
Feb 1, 2001 a real step and a flushed step with the same TERMTIME.
Variable INITTIME was needed at the end of the BY list
defined in MACRO _BTY30U4.
Thanks to Michael Oujesky, MBNA, USA.
Change 18.343 MXG 18.12 only. Typo in label had *' instead of * in
VMACIAM one label in this (fortunately) seldom-used code; typo
Jan 31, 2001 was made incorrectly after final QA.
Change 18.342 Variables CSFRLSAV and ESFRLSAV were incorrect; parens
VMAC71 were missing. The correct equations are:
Jan 31, 2001 CSFRLSAV=CSTORE-(CSFRTOAV-CSFRFXAV);
ESFRLSAV=ESTORE-(ESFRTOAV-ESFRHSAV);
Thanks to Peter Smith, Sema plc, ENGLAND.
======Changes thru 18.341 were in MXG 18.12 dated Jan 30, 2001======
Change 18.341 A short first record in the Catalog Export's output file
VMACCTLG caused notes on the log, but no error. The record is now
Jan 30, 2001 decoded and the time stamp text string is printed on log.
Thanks to Len Rugen, State of Missouri Department of Education, USA.
Change 18.340 BETA93 variable JESNR was missing for JOB/TSU/STC. Add
VMACBETA ELSE DO;
Jan 29, 2001 JESNR=INPUT(SUBSTR,JCTJOBID,4,5), ?? 5.);
END;
in two places so JESNR will be populated.
Thanks to Klaus Messer, COMLAB GmbH, GERMANY.
Change 18.339 Divide by zero protected in two places in this analysis
ANALCACH example.
Jan 29, 2001
Thanks to Greg Jackson, National Life of Vermont, USA.
Change 18.338 New MXG enhancement defines new MACRO _Vdddddd that
DOC lets you use this simple and straightforward syntax:
Jan 28, 2001 %LET MACKEEP= MACRO _Vdddddd KEEP= A B C % ;
(or you can put that MACRO _Vdddddd in member IMACKEEP)
to KEEP only those variables want kept in an MXG dataset!
The original design of the _Kdddddd macro will still
be supported (documented in DOCMXG), but that syntax
still requires you to list those variables that you do
not want to keep, using a DROP= statement; kludgy!
This change moves the text of the KEEP= and its list from
inside the _VARxxxx macro into a new _Vdddddd for each
MXG dataset, and the syntax of the _VARxxxx definition
was changed to use that new _Vdddddd token:
_Wddddddt (LABEL='THE*LABEL*FOR*THE*DATASET'
_Vdddddd _Kdddddd )
While being easy to use, the new _Vdddddd will also truly
keep only what you want; using _Kdddddd to DROP variables
only drops variables you listed; all new MXG variables
(a new release of CICS?) will be kept in your output data
set until you edited your DROP= list.
You can put the MACRO _Vdddddd definitions in IMACKEEP
if you ALWAYS want only those variables kept in that data
set, or you can tailor a job in its //SYSIN "instream",
so the macro changes only what's created by that job.
Using the CICSTRAN dataset as an example, you look up the
"dddddd" dataset-suffix name in the IMACxxxx member for
the TYPExxxx product, so IMAC110 tabulates the dddddd for
each MXG dataset built from the type 110 SMF record. The
IMAC110 member show you that "CICTRN" is the dddddd name
for the "CICSTRAN" dataset, so this instream tailoring
creates CICSTRAN.CICSTRAN with only three variables kept:
//SYSIN DD *
%LET MACKEEP=
MACRO _VCICTRN KEEP= APPLID TRANNAME TASCPUTM% ;
;
%INCLUDE SOURCLIB(TYPE110);
This is an internal text change inside VMAC members, and
it should be transparent to your existing tailoring.
Since datasets with lots of variables are the ones most
likely to need KEEP= tailoring, datasets with the most
variables were revised first; most have been enhanced but
not all MXG members were finished when 18.18 was ready.
These members that already defined an _Vxxxxxx macro were
set aside to be examined later:
TYPEAXC,TYPECMA,TYPEFTP,TYPEICE,TYPEIMS1,TYPEOMCI,
TYPEPW,TYPEQACS,TYPEQAPM,TYPEQTRT,TYPETUX,TYPEVMXA,
TYPEXAM,TYPE102,TYPE28,TYPE79,TYPE84
Change 18.337 Support for CA's UNICENTER TNG performance cubes data for
EXTAI001- AIX, CISCO, WIN-NT, and SOLARIS platforms creating these:
EXTAI005 MXG
EXTC2001- Platform Object Max Max Max DATASET
EXTC2002 Instance Vars Rows NAME
EXTC7001 AIX411: BUFFER 1 8 95 AI001
EXTNT001- CPU 1 5 95 AI002
EXTNT020 PAGING 1 4 95 AI003
EXTSO001- QUEUES 1 4 95 AI004
EXTSO015 SWAPPING 1 1 95 AI005
FORMATS CIS2500: CISCO 7 130 76 C2001
IMACTNG MIB-2 34 89 76 C2002
VMACTNG CIS7500: CISCO 24 166 76 C7001
TYPETNG NTS400I: BROWSER 1 20 95 NT001
TYPSTNG CACHE 1 27 95 NT002
UTILTNGO ICMP 1 27 95 NT003
VMXGINIT IP 1 17 95 NT004
Jan 28, 2001 LOGICALDISK 5 21 95 NT005
MEMORY 1 27 140 NT006
NBT CONNECTION 8 3 95 NT007
NETBEUI 2 39 71 NT008
NETBEUI RESOURCE 13 3 71 NT009
NETWORK INTERFACE 3 17 140 NT010
OBJECTS 1 6 95 NT011
PAGING FILE 2 2 140 NT012
PHYSICALDISK 3 19 140 NT013
PROCESSOR 2 10 95 NT014
REDIRECTOR 1 37 95 NT015
SERVER 1 26 140 NT016
SERVER WORK QUEUES3 17 140 NT017
SYSTEM 1 25 140 NT018
TCP 1 9 95 NT019
UDP 1 5 95 NT020
SOL240S: BUFFER 1 8 12 SO001
CPU 1 5 12 SO002
DISK 3 6 12 SO003
FILE-ACCESS 1 3 12 SO004
FILESYSTEM 2 3 12 SO005
IPC 1 2 12 SO006
KERNEL MEMORY ALLOC1 8 12 SO007
MEMORY 1 2 12 SO008
NETWORK 5 5 12 SO009
PAGING 1 11 12 SO010
QUEUES 1 4 12 SO011
SWAPPING 1 5 12 SO012
SYSTEM-CALLS 1 7 12 SO013
TABLES 1 7 12 SO014
TERMINAL 1 6 12 SO015
The dataset names in this implementation are structured:
Dataset Name: PPOOO
WHERE PP= Platform Type 2-Character Abbreviation:
AI=AIX411 C2=CIS2500 C7=CIS7500
NT=NTS400I SO=SOL240S
OOO= Object Number within Platform (see above)
Variable Name: PPOOOVVV
VVV= Variable (metric) number within object.
The Label for each MXG dataset is the Object Name; the
Label for each MXG variable is the Metric Name. Use the
PROC CONTENTS DATA=PDB._ALL_ DETAILS; to display what is
what in the AInnn,C2nnn,C7nnn,NTnnn and SOnnn datasets.
This is a departure from MXG variable naming. Most MXG
names are abbreviations for what it is, but these names
are all cryptic, except for the common BY variables of
PLATFORM SYSTEM INSTANCE and STARTIME. If it turns out
that having "real MXG variable names" is needed, perhaps
to match existing variables from other data sources, an
optional rename with PROC DATASETS will be developed.
New metrics/platforms/objects are easy to add; MXG notes
new objects and metrics on the log, telling you to run
UTILTNGO program, and email me the report and the OBJECTS
dataset. I can create the needed code from those files.
The next major enhancement to TNG support (2nd Quarter?)
will make the processing of TNG data completely dynamic:
I will only create datasets for those objects that had
data in the input file, and will only keep variables for
metrics that were found in the input file. That will
minimize the space required and remove the clutter of the
un-measured variables, and the completely new algorithms
in this support were designed with that intention.
Standard MXG PDB:
You will continue to have the option of building the
standard all-variable all-datasets PDB library from TNG
data, so your PDB libraries are consistent, with missing
values in variables that were not measured, and with
zero observations in datasets for objects that were not
found in today's data.
Dynamic MXG PDB:
You can tell MXG to construct the datasets and variables
that were found in today's input data stream, using only
the amount of storage and processing to be determined by
the data stream.
This architecture is extendable to other data sources
that have one row of raw data describing the object and
the metric followed by that one column of data values.
-Over a year ago, Roman Jost tried to convince me that
TNG was a find source of data, and sent me code that
read the TNG data, but it took me a year to finally
realize how I could write supportable code. This
development was actually triggered by a phone call
after CMG from the mid-west insurance company that had
written a C-program to "decode the performance cube
data". I had all along assumed that some API-issuing C
program or a vendor-provided utility was needed to read
the data, but when I realized this C program read a
flat file and wrote a flat file, and then actually
looked at a faxed dump of three records, I saw that the
raw data could be processed with SAS.
-My first pass took two days, and I read each record to
create one dataset for each variable, outputting an obs
for each data value, and then merged those datasets
together to create a dataset per object. I tested the
prototype with an NT cube with four objects and twenty
metrics, and the logic performed as designed.
-Then I wrote a SAS utility to generate all of the SAS
statements I would need to create a dataset for all of
the other objects and variables in all cubes for five
platforms, executed the generated code, and it worked.
However, with a small performance cube (64KB in size),
the program used 330 MegaBytes of disk storage and 10
minutes to create those 800+ datasets!
-Examining the structure of these data, I realized that
with fairly limited numbers of observations and limited
numbers of objects in one single input cube, arrays to
store a single performance cube was all that was needed
and that generated names for variables and datasets was
the best solution for this type of data structure; at
the end of each input cube, one dataset per object is
created, containing all of that object's metrics, so
there are 44 datasets created, one per object.
-The final run with multiple input of 24 daily cubes, at
15 minute intervals, 10,000 records, 6.6MB of raw data,
now took 25 seconds (12 to read and create datasets,
and 13 seconds to sort them into the PDB), used 17MB of
disk work space, with less than 6MB virtual storage for
all arrays, so the algorithm should scale well as new
objects and metrics are added in the future. The MXG
output PDB library was 6MB of disk for 24 days data,
using COMPRESS=YES under Win98 on a 500MHz Pentium III.
COMPRESS=NO took 2 seconds longer, needed 37MB for
work space and created a 12MB PDB on disk; I've
previously reported that COMPRESS=YES saves time and
disk space on Pentium architecture.
Change 18.336 -Device Number variables STC13DID/STC14DID are character
VMACSTC variables formatted with $HEX4., which do not translate
Jan 24, 2001 correctly between EBCDIC and ASCII platforms. New DEVNR
variable is created as numeric and formatted HEX4., so it
matches DEVNR in other MXG datasets like TYPE74.
See Newsletter "Executing SAS on PCs and Workstations"
-STC does not store anything into the channel interface
name field, variable STC11INM, so we will now store the
channel interface number as a character in STC11INM with:
IF STC11INM LE ' ' THEN STC11INM=PUT(_I_,8.);
so that if they change their mind and store a value in
the future, you'll get it, but for now, we need to sort
by STC11INM. (The LE ' ' catches both blanks and hex
zeros).
Thanks to Chuck Hopf, MBNA, USA.
Change 18.335 Testing statement PUT RTYPE= $HEX2.; should have been
VMACNAF deleted, and now it is. Only impact was a large SASLOG.
Jan 24, 2001
Thanks to Robert A. Brown, Arthur Anderson, USA.
Change 18.334 XRC dataset TYPE42XR had trash; the INPUT was misaligned.
VMAC42 The following INPUT statement was inserted before the
Jan 23, 2001 existing DO statement in member VMAC42:
INPUT @S42XRSSO @;
DO _I_=1 TO S42XRSSN;
Thanks to John Nalesnik, The Prudential, USA.
Thanks to Brenda Rabinowitz, The Prudential, USA.
Change 18.333 New "Header" exit IHDR110S for the CICS 110 Statistics
IHDR110S STID segments allows you to skip unwanted subsubtypes
VMAC110 and thereby save CPU time for the INPUT statements, if
Jan 22, 2001 you only want to output one or a few STID's (like STID=25
a year's CICLDR observations). See IHDR110S comments;
you simply set variable STIDWANT to 1 or zero, using:
IF STID =25 THEN STIDWANT=1;
ELSE STIDWANT=0;
or
IF STID IN (1,5,9, ..) THEN STIDWANT=1;
ELSE STIDWANT=0;
to skip unwanted STID segments, you should also throw
away the unwanted subtype 1 transaction record and other
unwanted statistics subtypes using the MACFILE tailoring:
%LET MACFILE= %QUOTE (
IF ID=110 ;
IF SUBTYPE=2;
);
so only (in this case) subtype 2 records, which contain
subsubtype 25 records, are input past the SMF header.
Note these mappings of subtypes to STID's:
0 - Journal
1 - Transaction, Exception, Dictionary
2 - Statistics - all other STIDs
3 - Statistics - STIDs 121,122,123
4 - Statistics - STIDs 126, 127, 128, 129
5 - Statistics - STIDs 124, 125
Change 18.332 Support for Solve SMF subtypes 1 and 2 create new dataset
EXTYSOL1 TYPESOL1 for FTS File Send/Receive.
FORMATS
IMACSOLV
VMACSOLV
VMXGINIT
Jan 20, 2001
Thanks to Aubrey Tang, Westpac Banking Corporation, AUSTRALIA.
Change 18.331 Validation of Shadow SMF subtype 6 changed variable
VMACSHDW SM06SQSR from numeric to variable length 32000 if under
Jan 19, 2001 V8 with COMPRESS=YES, or will be broken down into 100
byte pieces and output in multiple records (with resource
counts set to missing values in the SM06SEGN=2nd and
subsequent observations). All test records had SQL text
truncated at byte 255, with the rest of the SM06SQLN
bytes filled with hex zeroes. That may be an error or
an installation choice; it is under investigation, but
MXG prints one instance if found.
Thanks to Chris Morgan, IBM Integrated Technology Services, ENGLAND.
Change 18.330 Character strings (SQL text) greater than 100 bytes long
VMAC102 were truncated to 100 bytes if run under SAS V8 without
Jan 19, 2001 COMPRESS=YES. The tests to decide to break the long text
into 100 byte chunks was IF &SASVER GE 7 THEN DO; but
that was changed to IF &SASCHRLN LE 100 THEN DO; because
the &SASCHRLN length is set greater than 100 only if both
SAS V8 is being used AND COMPRESS=YES is used.
Change 18.329 The DB2 Accounting Summary report is enhanced to match
ANALDB2R the DB2 Version 6 DB2PM reports.
Jan 18, 2001
Jan 30, 2001
Change 18.328 The MQIN view/dataset was not deleted at the end of the
VMXGUOW program, causing no error, but inconsistent with MXG's
Jan 17, 2001 deleting of temporary datasets from the work file.
Thanks to Chris Weston, SAS Institute ITSV, USA.
Change 18.327 IBM Domino WebServer logs are readable with TYPEWWW code,
TYPEWWW but the statement FULLURL=SUBSTR(FULLURL,1,LOC-1); was
Jan 16, 2001 changed to FULLURL=SUBSTR(FULLURL,1,LOC-10). Without the
change, variable FULLURL contained the URL plus the
variable HTTPCLVS.
Thanks to Greg Meyer, Isuzu Motors, USA.
Change 18.326 Interval specification of MINUTE are now supported in the
ANALCNCR VMXGSUM, VMXGDUR, and ANALCNCR functions, if you need the
ASUMTALO minute details. Hardcode INTERVAL=HOUR and divides by
VMXGDUR 3600 were replaced with _TALOINT and _TALOSECS macros
VMXGSUM that can be changed to MINUTE and 60 to get minutes.
Jan 15, 2001
Thanks to Luc Mattheus, DEXIA Bank, BELGIUM.
Change 18.325 Variables CSA, ECSA, SQA, and ESQA are now calculated in
VMACRMFV the RMF Monitor III dataset ZRBASI to track the sizes of
Jan 15, 2001 those memory areas allocated to each ASID/JOB, and the
variables GEICSAAS and GEISQAAS are divided by samples.
Thanks to Stephen Hoar, Lloyds TSB, ENGLAND.
Change 18.324 Invalid data for RMGTSHTR (CICS Statistics) is because
VMAC110 the MSEC8. format still does not support values greater
VMACTMDB than 24 hours. I thought I had replaced all uses of the
Jan 12, 2001 MSEC8. informat with &PIB.8.6 and a divide by 4096, back
in Change 12.030, a few MSEC8 crept back in the IBM CICS
and the Landmark DB2 code. All have been replaced.
Thanks to Roman Jost, Gjensidige, NORWAY.
Change 18.323 Variable TIC_UTIL is now created in the NSPYTIC3 dataset.
VMACNSPY
Jan 11, 2001
Thanks to Tom Neurauter, Fidelity Investments, USA.
Change 18.322 Support for DFSMSRMM 1.5 changes (COMPATIBLE, new fields
EXEDGRK were added at end, new subtype added):
IMACEDGR -Dataset EDGRDEXT (DSN Record) new variables:
VMACEDGR RDVRSSCH='PRIMARY*VRS*SUBCHAIN'
VMXGINIT RD2VJBN ='SECONDARY*VRS*JOBNAME*MASK'
Jan 9, 2001 RD2VNME ='SECONDARY*VRS*NAME*MASK'
RD2VSCH ='SECONDARY*VRS*SUBCHAIN*NAME'
RD2VXDS ='SECONDARY VRS*SUBCHAIN*START DATE'
RDVRSXDS='PRIMARY*VRS*SUBCHAIN*START DATE'
-Dataset EDGRVEXT (VOL Record) new variables:
RVCONTNR='IN*CONTAINER*NAME'
(appears to be updated only for exported tapes).
RVRQPRTY='MOVEMENT*PRIORITY'
-New dataset EDGRKEXT created from new type K record.
RKCOUNT ='VITAL RECORD COUNT'
RKCRDATE='VITAL*RECORD*CREATE*DATE'
RKCRSID ='CREATE*SYSTEM*ID'
RKCRTIME='VITAL*RECORD*CREATE*TIME'
RKCRTJBN='JOBNAME'
RKDELAY ='DAYS*DELAY*BEFORE*SELECTION'
RKDELDAT='DATE VRS*IS TO BE*DELETED*BY RMM'
RKDESC ='DESCRIPTION'
RKDSNAME='DATA*SET*NAME'
RKDSNG ='DATASET*NAME*MASK IS*GDG?Y/P/N?'
RKGENKEY='DSET/VOL*GENERIC*CHARACTERS?'
RKLCDATE''LAST*CHANGE*DATE'
RKLCSID ='LAST*CHANGE*SYSTEM ID'
RKLCTIME''LAST*CHANGE*TIME'
RKLCUID ='LAST*CHANGE*USER ID'
RKLOC ='NAMEAOF LOCATION TO BE STORED'
RKLOCTYP='LOCATION*TYPE?*A/M/S/ '
RKNAME ='VRS*NAME'
RKNEXT ='NAMEAOF NEXT VRS IN THE CHAIN'
RKOWNER ='VITAL*RECORD*OWNER'
RKRETNC ='RETAIN*BASED ON*CYCLES?'
RKRETND ='RETAIN*BASED ON*ELAPSED DAYS?'
RKRETNR ='RETAIN*BASED ON*UNREFERENCED DAYS?'
RKRETNW ='RETAIN*ONLY WHILE*CATALOGED?'
RKRETNX ='RETAIN*UNTIL*EXPIRED?'
RKSTNUM ='STORE KEEP NUMBER'
RKTYPE2 ='VRS*TYPE*V=VOL*D=DSET*N=NAME'
RKVOLSER='VOLUME*SERIAL'
Thanks to Carl Kyonka, Enbridge, CANADA.
Change 18.321 Warning that variable RPRTCLAS was duplicated in an ID
TRND72GO argument was valid, but of no impact. RPRTCLAS was added
Jan 9, 2001 to the SUMBY= by Change 18.189 but should have also been
removed from the ID= argument. Now it is.
Change 18.320 MXG 18.06-MXG 18.10, and only if VMXGSUM was called twice
BLDNTPDB with &DDNAME as an input argument (we found it only in
VMXGSUM BLDNTPDB and only in the LDSK report). Change 18.182
Jan 9, 2001 added a call to new %VMXGENG (to determine the SAS engine
that created the input dataset), but used DDNAME for a
temporary macro, and then changed its value. This change
eliminates the use of DDNAME inside VMXGSUM. There was no
change made to member BLDNTPDB.
Thanks to Terry Heim, ECOLAB, USA.
Change 18.319 The calculation of Standard Deviation was incorrect;
TRNDCICS the logic from TRNDCICX was imported into TRNDCICS.
Jan 9, 2001
Change 18.318 The SORT FIELDS= value in JCLIMSL5 should have been
JCLIMSL5 SORT FIELDS=(1,12,A,35,8,A,29,1,A),FORMAT=BI
Jan 9, 2001 The change was made in JCLIMSL6 but not in L5.
Thanks to Roman Jost, Gjensidige Gruppen, NORWAY.
Change 18.317 Support for z/OS R1.1 (COMPATIBLE).
VMAC7072 TYPE70: New z/OS metrics for this CPU/SYSTEM:
VMXGRMFI CPUADJCH='PHYSICAL*CPU*ADJ FACTOR*CHANGED?'
Jan 5, 2001 Changed only by Capacity Upgrade on Demand.
Jan 20, 2001 SUAVAICH='SU*AVAILABLE*CHANGED?'
SMF70CPA='SU_SEC*OF THE*PHYSICAL*CEC'
SMF70LAC='IBM*4-HR*AVERAGE*HOURLY MSU'
SMF70WLA='Defined*Capacity*SU*Available'
TYPE70PR: New z/OS metrics for each LPAR segment:
LPARCLND='CAPACITY*LIMIT*NOT*DEFINED?'
LPARDCLC='DEFINED*CAPACITY*LIMIT*CHANGED?'
LPARWLMG='WLM*MANAGEMENT*OF THIS*LPAR?'
LPARWTFD='WAIT*TIME*FIELD*DEFINED?'
SMF70MSU='DEFINED*CAPACITY*LIMIT*IN MSU'
SMF70NSA='PCT WHEN*AT MAXIMUM*PARTITION*WEIGHT'
SMF70NSI='PCT WHEN*AT MINIMUM*PARTITION*WEIGHT'
SMF70NSW='PCT WHEN*LPAR WAS CAPPED*BY WLM'
SMF70ONT='LPAR*ONLINE*TIME'
SMF70PMA='AVERAGE*IRD*ADJUSTED*PARTITION*WEIGHT'
SMF70WST='LPAR*WAIT*TIME'
RMFINTRV: Variables from TYPE70 now maxed into RMFINTRV:
SMF70LAC='IBM*4-HR*AVERAGE*HOURLY MSU'
SMF70WLA='MAX SU*AVAILABLE*TO MVS*IMAGE'
Additional z/OS changes:
New TYPE74 Subtype 7 FICON Director - await test data,
will be supported ASAP, new MXG dataset(s) to be.
New TYPE99 Subtype 8 LPAR CPU Management - no data.
Similar to subtype 2, will decode upon request.
New TYPE99 Subtype 9 Dynamic Channel Path Management.
Have data, will decode upon request.
Type 78.1 documentation was removed.
Type 79.13 documentation was removed.
MXG support is based on pre-GA documentation, and there
may be differences in the GA level of the product.
Change 18.316 The null macro _NSHDW was incorrect and if you tried to
VMACSHDW use it, you got a strange "180" error about "WORK".
Jan 4, 2001
Thanks to Wayne A. Schumack, Blue Cross Blue Shield of Minnesota,USA.
======Changes thru 18.315 were in MXG 18.11 dated Jan 3, 2001======
Change 18.315 Documentation of the Internal Logic of the MXG PDB. This
DOCPDB was presented as a 3-hour Workshop prior to CMG 2000.
Jan 3, 2001
Change 18.314 Support for CICS TS for z/OS Version 2.1 (INCOMPAT):
EXCICEJR As usual, while there's some interesting new metrics that
EXCICIIR IBM added to the CICSTRAN record, they inserted those new
EXCICSJG fields (instead of adding them at the end of the segment)
EXCICSOG so you MUST install this change to process 2.1 records.
EXCICSOR -Dataset CICSTRAN - New variables inserted:
IMACCICS JVMITICN='CICS JVM*INITIALIZE*ELAPSED*COUNT'
VMAC110 JVMITITM='CICS JVM*INITIALIZE*ELAPSED*TIME'
VMXGINIT JVMRTICN='CICS JVM*RESET*ELAPSED*COUNT'
Jan 3, 2001 JVMRTITM='CICS JVM*RESET*ELAPSED*TIME'
Jan 28, 2001 KY8CPUCN='USER-TASK*KEY 8*TCB CPU*COUNT'
KY8CPUTM='USER-TASK*KEY 8*TCB CPU*TIME'
KY8DISCN='USER-TASK*KEY 8*TCB DISPATCH*COUNT'
NETID ='NETWORK*QUALIFIED*NAME*NETWORK ID'
OTSINDCN='OTS*INDOUBT*WAIT*COUNT'
OTSINDTM='OTS*INDOUBT*WAIT*TIME'
OTSTID ='OTS*TRANSACTION*ID*(TID)'
PORTNUM ='TCP/IP*SERVICE*PORT*NUMBER'
RLUNAME ='NETWORK*QUALIFIED*NAME*NETWORK*NAME'
RQPWAICN='REQUEST*PROCESSOR*WAIT*COUNT'
RQPWAITM='REQUEST*PROCESSOR*WAIT*TIME'
RQRWAICN='REQUEST*RECEIVER*WAIT*COUNT'
RQRWAITM='REQUEST*RECEIVER*WAIT*TIME'
SOCHRIN ='SOCKET*CHARACTERS*RECEIVED'
SOCHROUT='SOCKET*CHARACTERS*SENT'
SOCNPSCT='CREATE*NON-PERSISTENT*SOCKET*REQUEST'
SOCPSCT ='CREATE*PERSISTENT*SOCKET*REQUEST*COUNT'
SOEXTRCT='SOCKET*EXTRACT*REQUEST*COUNT'
SONPSHWM='NON-PERSISTENT*SOCKET*HIGH-WATER-MARK'
SOOIOWCN='OUTBOUND*SOCKET*I/O*WAIT*COUNT'
SOOIOWTM='OUTBOUND*SOCKET*I/O*WAIT*TIME'
SOPSHWM ='PERSISTENT*SOCKET*HIGH-WATER-MARK'
SORCVCT ='SOCKET*RECEIVE*REQUEST*COUNT'
SOSENDCT='SOCKET*SEND*REQUEST*COUNT'
SOTOTCT ='SOCKET*TOTAL*REQUEST*COUNT'
TCPSRVCE='TCP/IP*SERVICE*NAME'
WBBRWCT ='WEB BROWSE*REQUEST*COUNT'
WBEXTRCT='WEB EXTRACT*REQUEST*COUNT'
WBREADCT='WEB READ*REQUEST*COUNT'
WBWRITCT='WEB WRITE*REQUEST*COUNT'
-New CICS Statistics STIDs create new MXG datasets:
STID Name MXG DSN Description
107 STISOG CICTCPSO TCP/IP Sockets Global
108 STISOR CICTCPIP TCP/IP Services (Sockets)
111 STIIIR CICTCPII TCP/IP II Domain RequestModel
114 STIEJR CICTCPEJ TCP/IP Entrprse Java ObjContainer
117 STISJG CICTCSJG TCP/IP JVMPOOL Statistics
MXG support is based on pre-GA documentation, and there
may be differences in the GA level of the product.
Change 18.313 MXG 18.10 only. Change 18.280 caused CICS/TS 1.3 records
VMAC110 to print error messages about EXCLUDED fields when there
Jan 2, 2001 were no excluded fields, and records were deleted:
***ERROR.TYPE110.CICS TS 1.3. EXCLUDED FIELDS HAVE BEEN DETECTED.
MXG EXPECTED MCTSSDCN=202 AND MCTSSDRL=1260.
RECORD WAS DELETED, CICSTRAN DATA WAS LOST.
SYSTEM=XXXX APPLID=YYYYYYYY SMFPSRVR=53 MCTSSDCN=203 MCTSSDRL=1288
(Disregard the "MXG EXPECTED" text, which was also wrong,
and note that the final line of the error message showing
MCTSSDCN=203 is the correct minimum number of fields.)
The test in line 6977 in VMAC110 was changed from 203 to
204 when it should have remained 203. The correction is
to change that line back to test for LT 203:
6976 ELSE IF SMFPSRVR GE 53.0 THEN DO;
6977 IF MCTSSDCN LT 203 OR MCTSSDRL LT 1288 THEN DO;
If optional fields exist in your type 110 record, this
error does not occur, which is why I missed it in 18.10!
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 18.312 Variable DATETIME is kept in 169 MXG datasets, but it has
BUILD005 different meanings depending on which dataset it was in,
BUIL3005 and in the PDB.JOBS/STEPS/PRINT/SPUNJOBS datasets, it was
SPUNJOBS not correct. In those four datasets, while labeled as
Jan 2, 2001 "DATETIME OF SHIFT CALCULATION", its value was the time
of the beginning of the shift, rather than the actual
DATETIME value of the job.
Originally, "DATETIME" was a temporary variable that
was used as the input datetime value for your IMACSHFT
definition, to set the value of the character variable
SHIFT. So that summarization with VMXGSUM could
exploit your shift definitions, IMACSHFT changes the
value returned in variable DATETIME, setting its value
back to the time of the start of this shift.
But along the way, DATETIME was accidentally kept in
some datasets, so now it must be corrected where it is
wrong, and documented where it is different.
Now, in the PDB.JOBS/STEPS/PRINT/SPUNJOBS dataset, the
value that is returned in variable DATETIME will be the
original value that was used to calculate the shift:
PDB.JOBS and PDB.SPUNJOBS:
MAX(READTIME,INITTIME,JINITIME,JINLTIME,JSTRTIME);
PDB.STEPS:
MAX(READTIME,INITTIME);
PDB.PRINT:
MAX(READTIME,PRINTIME);
The MAX() is used since some timestamps may be missing,
and the Max/Last datetime value is the logical time of
the job start, step initiate, or print file print time.
In these summary datasets that contain variable DATETIME:
ASUMxxxx CICINTRV CICS JOBSKED MNTHxxxx TRNDxxxx
it is properly labeled 'START OF INTERVAL' and contains
that correct value. In some of those datasets. variable
STARTIME exists and is equal to DATETIME, and where it
exists, STARTIME is better as it is self-describing!
In dataset EREPTIM, DATETIME='DATETIME FOR IPL RECORDS'
and is correct, as IMACSHFT is not invoked in VMACEREP.
In the many OPCxxxxx datasets, DATETIME='EVENT DATETIME',
and is correct, as IMACSHFT is not used here, either.
Thanks to Cendrine Pezier, ABS Technologies, FRANCE.
Change 18.311 Support for DB2 Space Manager 2.1 (INCOMPATIBLE) from SE
FORMATS (Software Engineering). The "current" date/time fields at
VMACSPMG the start of the record were removed, shifting the real
Jan 2, 2001 date/time fields to the left. No error message occurs,
but variable SPMGTIME is missing. FORMATs were updated
to print "Blank:TYPE1" instead of " :TYPE1" (cosmetic).
And variables FARINDRF,NEARINDR,PCTACTIV and PCTDROP are
set missing if they contain all FFx.
Thanks to Anke Mineur, DVG, GERMANY.
Change 18.310 Documentation. Example invocation of the ITSV macros
DOCITSV that are needed to add a new MXG variable into the ITSV
Jan 2, 2001 PDB (in case you need something not yet in ITSV).
Thanks to Chris Weston, SAS ITSV, USA.
Change 18.309 The WorldSecure SMTP Relay object printed UNEXPECTED OBJ
VMACNTSM message; the NRNAMES=NRNAMES-1; statement for that object
Jan 2, 2001 should have been deleted.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 18.308 Support for APAR OW45788 for NPM corrects the lengths of
VMAC28 several LXETxxxx variables in the X.25 Session dataset
Dec 26, 2000 NPMEVX25 that were originally mis-documented by IBM.
Change 18.307 Variable MSU4HRAV was correct for a uni-processor, but
VMXGRMFI was wrong in magnitude for multi-processors; NRCPUS(II)
Dec 26, 2000 was needed in the numerator of MSU4HRAV calculation.
Variable CECSUSEC is now kept, and the absence of //SPIN
DD statement no longer causes a failure.
Thanks to Al Sherkow, I/S Management Strategies Ltd, USA.
Change 18.306 The Scheduling Environment name, SMF30PFL, and durations
BUILD005 SMF30HQT/JQT/RQT/SQT, are added to the PDB.JOBS dataset
BUIL3005 (JES2 or JES3, BUILDPDB/BUILDPD3. Those five variables
VMAC30 will be of long term importance in job scheduling, and so
Dec 23, 2000 are now automatically in PDB.JOBS. The change in VMAC30
was cosmetic; SMF30PFL was hex zeros when not populated;
now those '00'x will be translated to blanks.
Thanks to Stephen Marksamer, The Hartford, USA.
Change 18.305 The text of Change 18.300, re DB2TCBTM, was revised and
VMACDB2 the MXG equation, changed by this change, is now:
Dec 21, 2000 DB2TCBTM=
Jan 29, 2001 SUM((QWACEJST-QWACBJST),QWACSPCP,QWACTRTE);
This change added support for DB2 Version 7.1 (COMPAT):
DB2ACCT new variables:
QBGA2H ='ASYNC*IXLCACHE*FOR SECC GBP'
QBGA2S ='COMPLETION*CHECKS*SUSPENDED'
QBGA2W ='CHANGED PAGE*WRITES TO*SEC GBP '
QBGAEX ='*EXPLICIT*XI-S'
QBGAHS ='ASYNCH*IXLCACHE*FOR PRI GBP'
QBGAGG ='GET PAGES*FOR GBP*DEP PAGES'
QWACARLG='TRACE EVENT*FOR WAITS*FOR LOG WRITE*I/O'
QWACARNK='CHILD L-LOCKS*GLBL CONTENTION*EVENTS'
QWACARNM='OTHER L-LOCKS*GLBL CONTENTION*EVENTS'
QWACARNN='PAGESET P-LOCKS*GLBL CONTENTION*EVENTS'
QWACARNO='PAGE P-LOCKS*GLBL CONTENTION*EVENTS'
QWACARNQ='OTHER P-LOCKS*GLBL CONTENTION*EVENTS'
QWACAWLG='WAIT TIME*FOR LOG WRITE*I/O'
QWACAWTK='WAIT TIME*GLBL CONTENT*CHILD L-LOCKS'
QWACAWTM='WAIT TIME*GLBL CONTENT*OTHER L-LOCKS'
QWACAWTN='WAIT TIME*GLBL CONTENT*PAGESET P-LOCKS'
QWACAWTO='WAIT TIME*GLBL CONTENT*PAGE P-LOCKS'
QWACAWTQ='WAIT TIME*GLBL CONTENT*OTHER P-LOCKS'
QWACRBSV='ROLLBACK TO*SAVEPOINT*REQUESTS'
QWACRLSV='RELEASE*SAVEPOINT*REQUESTS'
QWACSVPT='SAVEPOINT*REQUESTS'
QWAXAWFC='WAIT TIME*FOR FORCE*AT COMMIT'
QWAXFCCT='WAITS FOR*FORCE*AT COMMIT'
QWAXIXLE='EVENTS FOR*ASYNC*IXLCACHE*IXLFCOMP'
QWAXIXLT='WAIT TIME*FOR IXLCACHE*IXLFCOMP'
QXDCLGTT='DECLARE*GLOBAL*TEMP TABLE*STMTS'
QXDEGDTT='PARALLEL*GROUPS*DECLARED*TEMP TABLE'
QXSETCPR='SET*CURRENT*PRECISION*STATEMENTS'
DB2ACCTP new variables:
QPACARNK='CHILD L-LOCKS*GLBL CONTENTION*EVENTS'
QPACARNM='OTHER L-LOCKS*GLBL CONTENTION*EVENTS'
QPACARNN='PAGESET P-LOCKS*GLBL CONTENTION*EVENTS'
QPACARNO='PAGE P-LOCKS*GLBL CONTENTION*EVENTS'
QPACARNQ='OTHER P-LOCKS*GLBL CONTENTION*EVENTS'
QPACAWTK='WAIT TIME*GLBL CONTENT*CHILD L-LOCKS'
QPACAWTM='WAIT TIME*GLBL CONTENT*OTHER L-LOCKS'
QPACAWTN='WAIT TIME*GLBL CONTENT*PAGESET P-LOCKS'
QPACAWTO='WAIT TIME*GLBL CONTENT*PAGE P-LOCKS'
QPACAWTQ='WAIT TIME*GLBL CONTENT*OTHER P-LOCKS'
DB2ACCTG new variables:
QBGA2H ='ASYNC*IXLCACHE*FOR SECC GBP'
QBGA2S ='COMPLETION*CHECKS*SUSPENDED'
QBGA2W ='CHANGED PAGE*WRITES TO*SEC GBP '
QBGAEX ='*EXPLICIT*XI-S'
QBGAGG ='GET PAGES*FOR GBP*DEP PAGES'
QBGAHS ='ASYNCH*IXLCACHE*FOR PRI GBP'
DB2STATS new variables:
(DB2STAT0)
Q9STCTRZ='DISPLAY*FUNCGION*COMMANDS'
Q9STCTX0='START*FUNCTION*COMMANDS'
Q9STCTX1='STOP*FUNCTION*COMMANDS'
Q9STCTX2='SET*LOG*COMMANDS'
Q9STCTX3='DISPLAY*LOG*COMMANDS'
Q9STCTX4='SET*SYSPARM*COMMANDS'
QDSTCIN2='CURRENT*TYPE 2*INACTIVE*THREADS'
QDSTMADS='MAXIMUM*ACTIVE DBAT SLOTS NOT INUSE'
QDSTMIN2='MAXIMUM*TYPE 2*INACTIVE*THREADS'
QDSTMQR2='MAXIMUM*TYPE 2*QUEUED*REQUESTS'
QDSTNADS='CURRENT*ACTIVE DBAT SLOTS NOT INUSE'
QDSTNDBA='REQUESTS*REQUIRING*DBAT'
QDSTNITC='CONNECTIONS*TERMINATED*MAX TYPE 1'
QDSTNQR2='CURRENT*TYPE 2*QUEUED*REQUESTS'
QDSTPOOL='REQUESTS*SATISFIED*BY POOL THREAD'
QDSTQIN2='QUEUED*RECEIVE*REQUESTS*FOR TYPE 2'
QJSTBPAG='LOG-WRITE*BUFFER*PAGE INS'
QJSTCIWR='LOG*CI-S*WRITTEN'
QJSTLOGW='LOG WRITE*I/O*REQUESTS'
QJSTLSUS='SUSPENDS*FOR LOG WRITE'
QJSTSERW='SERIAL*LOG WRITE*REQUESTS* FOR REWRITE'
QJSTTHRW='TIMES*LOG WRITE*THRESHOLD*WAS REACHED'
(DB2STAT1)
QISEDFAL='FAIL*DUE TO*DATASPACE FULL'
QISEDFRE='FREE PAGES*IN DATASPACE*FREE CH'
QISEDPGE='PAGES*IN EDM*DATASPACE'
QTRACAUT='SUCCESS*AUTH CHECKS*FOR ROUTINES'
QTRACNAC='DB2 UNABLE*TO ADD ENTRY*TO AUTH CACHE'
QTRACNOT='ROUTINE*AUTH CHECKS*NON USE*AUTH CACHE'
QTRACOW1='DB2 OVERWROTE*AUTHID IN*AUTH CACHE'
QTRACOW2='DB2 OVERWROTE*ENTRY IN*AUTH CACHE'
QTRACPUB='SUCCESS*AUTH CHECKS*HELD BY*PUBLIC'
QXDCLGTT='DECLARE*GLOBAL*TEMP TABLE*STMTS'
QXDEGDTT='PARALLEL*GROUPS*DECLARED*TEMP TABLE'
QXSETCPR='SET*CURRENT*PRECISION*STATEMENTS'
DB2STAT2 new variables:
QDBPPGST='PGSTEAL*ATTRIBUTE'
QDBPSLA ='QDBPSLA*SERVICEABILITY'
QDBPVDQB='POOL*VERTICAL*WRITE*THRESHOLD'
QDBPVPTY='VPTYPE*ATTRIBUTE'
T102S006 new variables:
QW0006PG QW0006FG
T102S016 new variables:
QW0016WT
T102S017 new variables:
QW0017TY
T102S022 new variables:
QW0022AS QW0022CC QW0022CE QW0022FG QW0022QO QW0022RS
QW0022CY QW0022F2 QW0022NP QW0022PA QW0022TT
T102S022 new variables:
QW0023R1
-Additional T102Snnn subtypes will be decoded upon request
MXG support is based on pre-GA documentation, and there
may be differences in the GA level of the product.
======Changes thru 18.304 were in MXG 18.10 dated Dec 20, 2000======
Change 18.304 First MXG 18.10 only. Cosmetic. Label was truncated for
ASUMCICS variable SYSTEM and CPUTM had no label, because the equal
Dec 20, 2000 sign after CPUTM was missing.
======Changes thru 18.303 were in MXG 18.10 dated Dec 20, 2000======
Change 18.303 Cosmetic, in that the statement was never executed, but
VMXGCICI %ELSE INTRVSEC=0; should have been %ELSE %LET INTRVSEC=0;
Dec 19, 2000
Thanks to Russell Dewar, National Australian Bank, AUSTRALIA
Change 18.302 Support for APARs OW44845 and OW47050 adds a new report,
ANAL103 the HTTP Server Report, from SMF 103 records!
ANALRMFR MXG parameter overrides:
Dec 19, 2000 MXG HTTP Server Summary Report
%ANALRMFR(REPORT=HTTP);
DEFAULT is to create:
Interval of DATE and Report is HTTPSUM.
To create another Interval other than Date.
%ANALRMFR(REPORT=HTTP,RPTOPT=HTTPSUM,
INTERVAL=HOUR);
Create MXG HTTP Server Detail Report
%ANALRMFR(REPORT=HTTP,RPTOPT=HTTPDTA);
Values have not been verified, see comments within
ANALRMFR for more detail of overrides.
A DDNAME of PDB is now required anytime ANALRMFR is
invoked, whether it is a TEMPORARY SAS library
//PDB DD UNIT=SYSDA,SPACE=(CYL,(5,5))
or a CATALOGED SAS library:
//PDB DD DSN=MXG.PDB,DISP=(,CATLG),
// DCB=RECFM=FS,
// UNIT=SYSDA,SPACE=(CYL,(5,3))
New member ANAL103(HTTP), documentation only, how to
create the associated Post-processor RMF reports.
Change 18.301 Validated reports with FICON data records. REPORT=CHAN,
ANALRMFR columns READ(MB/SEC) and WRITE(MB/SEC) values were output
Dec 19, 2000 even if they were missing. Values were corrected to
match IBM RMF report. APAR OW42945 updated the Partition
Data Report to now include two TOTAL lines, one for all
CP partitions and one for all ICF partitions.
Thanks to Trevor Holland IBM/GSA Australia
Change 18.300 MXG 17.17 thru MXG 18.09 only. Variable DB2TCBTM in data
VMACDB2 set DB2ACCT included CPU time in Stored Procedure Address
Dec 07, 2000 Spaces twice. Both variables QWACSPCP and QWACSPTT were
Dec 18, 2000 added by MXG Change 17.382 to the DB2TCBTM formula,
Dec 21, 2000 DB2TCBTM=SUM((QWACEJST-QWACBJST),QWACSPCP,QWACSPTT);
because I read "not recorded" in IBM DB2 V6.1 DSNWMSGS:
QWACSPCP ACCUMULATED TCB TIME SPENT PROCESSING SQL CALL STATEMENTS
QWACSPCP IN THE DB2 STORED PROCEDURES ADDRESS SPACE OR A WLM
QWACSPCP ADDRESS SPACE. THIS TIME IS CALCULATED ONLY IF
QWACSPCP ACCOUNTING CLASS 1 IS ACTIVE.
QWACSPCP FOR A THREAD THAT USES RRSAF TO CONNECT TO DB2 AND
QWACSPCP IS SWITCHED AMONG TASKS, THIS VALUE IS 0.
QWACSPTT ACCUMULATED TCB TIME SPENT IN DB2 PROCESSING SQL
QWACSPTT STATEMENTS ISSUED BY STORED PROCEDURES. THIS IS <===
QWACSPTT THE TIME NOT RECORDED IN QWACSPCP. THIS TIME IS
QWACSPTT CALCULATED ONLY IF ACCOUNTING CLASS 2 IS ACTIVE.
and so I concluded that both SPCP and SPTT must be added,
and made Change 17.282 in January, 2000. But when data
had large and nearly equal values in both SPCP and SPTT,
we queried IBM DB2 support, who investigated and replied
that internal documentation showed that SPTT was included
in SPCP, and DSNWMSGS was wrong and would be corrected.
IBM DB2 support also confirmed that the additional CPU
time field for the execution of triggers under enclaves,
variable QWACTRTE, is also not included in EJST-BJST and
it must also be added to get the Total DB2 TCB CPU time
in DB2ACCT. So the final (Dec 21) equation is:
DB2TCBTM=
SUM((QWACEJST-QWACBJST),QWACSPCP,QWACTRTE);
The SPAS accounting error surfaced when one user saw the
daily DB2 CPU time for his AUTHID jump from 20.17 seconds
when only EJST-BJST was charged, to 137.57 seconds when
SPCP=58.76 and SPTT = 58.60 were both added by MXG; the
user's bill increased by a factor of six!
His real cost without the double accounting was 78.93,
so his bill should increase by a factor of only four.
For this one AUTHID, SPAS CPU time was significant, and
because the SPTT time recorded was also large, the MXG
double accounting was significant. But that may not be
the general case; overall, SPTT seems to be quite small,
even when SPCP is large. Looking at the daily totals
from two sites shows that including SPCP can be
significant, but the CPU time in SPTT was insignificant:
One site Other site
EJST-BJST 166,612 1,095,220.92
QWACSPCP 205,839 389.34
QWACTRTE 0 0
DB2TCBTM 372,451 1,095,610.26
QWACSPTT 2,902 388.00
You should run a PROC MEANS SUM DATA=PDB.DB2ACCT;
to determine the impact of including SPTT at your site.
Dec 21 update: Today I looked at the DSNDQWAC DSECT, and
it was right all along, as it documents that:
QWACSPTT THE ACCUMULATED TCB TIME CONSUMED IN DB2 PROCESSING SQL
STATEMENTS ISSUED BY STORED PROCEDURE(S)
AND INCLUDED IN QWACSPCP <<===== !!!!!
It's all about knowing which documentation to believe!
To summarize what has been true in DB2ACCT and ASUMUOW:
- DB2TCBTM is calculated as
SUM((QWACEJST-QWACBJST),QWACSPCP,QWACTRTE);
QWACSPCP and QWACTRTE are added by MXG into DB2TCBTM
QWACSPTT is NOT added, because it is in QWACSPCP.
Thank to Steve Colio, CIGNA, USA.
Thanks to Jiann-Shiun Huang, CIGNA, USA
Thanks to Curt Cotner, IBM, USA.
Change 18.299 Support for SMF 120 record for Websphere Application
EXT120CC Server Enterprise Edition OS/390 Component Broker
EXT120CM Version 3.02, added by APAR OW44456.
EXT120SA There are four subtypes, described by IBM as:
EXT120SC
EXT120SI Subtype=1: Server Activity Record:
FORMATS Created for each activity that is running inside a
IMAC120 Websphere Application Server. This record can be used to
TYPE120 perform basic charge back accounting as well as profiling
VMAC120 of customer written applications to determine in detail
VMXGINIT what is happening inside the Websphere Application
Dec 16, 2000 Server.
MXG dataset TY120SA
Subtype=2: Container Activity Record
Created for each activity that runs inside a container
located in a Websphere Application Server. This record
can be used to perform basic charge back accounting,
application profiling, problem determination, and
capacity planning. MXG Datasets TYP120CA/TYP120CC and
TYPE102CM.
Subtype=3: Server Interval Record
Created for each server instance that has interval
recording active during the interval. The purpose of this
record subtype is to record activity that is running
inside a Websphere Application Server. This record is
produced at regular intervals and is an aggregation of
the work that has run inside the server instance during
the interval. MXG Dataset TYP120SI.
Subtype=4: Container Interval Record
Created for each active container located in a Websphere
Application Server. This interval record provides a
snapshot view of the activity running inside the
container. This record can be used to perform application
profiling, problem determination, and capacity planning.
MXG Dataset TYP120CI.
And IBM APAR OW44456 requires the following doc changes:
Periodically, IBM refreshes documentation on our Web
site, so the changes might have been made before you
read this text. To access the latest on-line
documentation, go to the product library page at:
www.ibm.com/software/webservers/appserv/library_390.html
And support provides a new edition:
Document Name: WebSphere Application Server Enterprise
Edition for OS/390 Operations and Administration
Document Number: GA22-7328-01
The new edition contains a chapter (Chapter 9) that
explains how to set up and use the new SMF recording
support and an appendix (Appendix A) that describes
the new SMF record type 120.
To get the new edition, go to our Web site at:
www.ibm.com/software/webservers/appserv/library_390.html
IBM support also requires changes to existing doc:
Document Name: WebSphere Application Server Enterprise
Edition for OS/390 Component Broker Planning and
Installation Guide
Document Number: GA22-7325-00
See revisions in the APAR OW44456 text.
This support has not been tested with 120 SMF records.
Change 18.298 Support for the z/OS License Manager's new LPAR capacity
VMXGRMFI measurement: "Four-Hour Running Average MSU", with MSU in
TRNDRMFI "Million Service Units per Hour", based on the raw SU_SEC
Dec 12, 2000 of the physical platform. New MXG variable MSU4HRAV is
Dec 18, 2000 now created in the PDB.RMFINTRV dataset, and it is that
Feb 10, 2001 value that z/OS will pass to the License Manager, which
is compared with the licensed MSU for that LPAR (which
you chose in your software License Certificate for that
LPAR). WLM measures the MSU consumed by the LPAR every
five (may be changed) minutes, and if the licensed MSU is
exceeded, WLM will cap the LPAR to that licensed MSU for
the next interval.
So this new License Manager can save you lots on software
license costs, if you don't need an entire machine for an
LPAR; you can even license only part of an engine.
BUT to save that money, you will need to know your peak
MSU4HRAV for the month, in advance, so you can purchase a
correct size license, and you will need to track when
that peak MSU4HRAV consumption occurs, perhaps so you can
time-shift work to reduce that peak MSU consumed. Since
each month's charge is likely to be based on the maximum
peak running average during each calendar month, tracking
closely at near-month-end may be needed!
When WLM capping is invoked (because the LPAR exceeded
its licensed MSU4HRAV), response times may be elongated,
and it remains to be seen what feedback will be available
to alert you that dynamic capping was applied, but with
this new variable now, you can at least estimate the size
of each of your Systems to see how you will be able to
take advantage of License Manager product pricing.
The MSU4HRAV variable is created in PDB.RMFINTRV when
you run BUILDPDB/BUILDPD3, or if you run RMFINTRV or
invoke %VMXGRMFI in your own program. The algorithm
also creates the new SPIN.SPINRMFI dataset, which holds
the last four hours of the previous day, and is read by
the next day's BUILDPDB so that continuous four-hour
means are calculated. Variable CECSUSEC, the SU_SEC of
the physical CEC, is also created in PDB.RMFINTRV.
New variable MSU4HRMX in TRNDRMFI is the maximum value
of the MSU4HRAV during each trended interval.
You can add the new variables MSU4HRAV and CECSUSEC to
existing PDB.RMFINTRV datasets (without re-reading the
SMF data), by using the PDB=ADDMSU option in %VMXGRMFI to
read each existing PDB.RMFINTRV dataset and write back a
replacement, enhanced PDB.RMFINTRV dataset, as shown:
//PDB DD DSN=YOUR.EXISTING.PDB,DISP=OLD
//SYSIN DD *
%VMXGRMFI(PDB=ADDMSU);
If you add a //SPIN DD to that example, and start your
re-creation from the oldest to the newest, MSU4HRAV
will exist in all observations (except for the first
four hours of the oldest PDB):
//WEEKOLD EXEC MXGSAS
//PDB DD DSN=YOUR.WEEKOLD.PDB,DISP=OLD
//SPIN DD DSN=YOUR.SPIN,DISP=OLD
//SYSIN DD *
%VMXGRMFI(PDB=ADDMSU);
... one step per week ...
//WEEKNEW EXEC MXGSAS
//PDB DD DSN=YOUR.WEEKNEW.PDB,DISP=OLD
//SPIN DD DSN=YOUR.SPIN,DISP=OLD
//SYSIN DD *
%VMXGRMFI(PDB=ADDMSU);
If you use the first example, without SPIN, the first
four hour's observations in each output PDB.RMFINTRV
dataset will have missing value for the new variables.
Definitions and description of the algorithm:
"MSU" is Millions of Service Units per Hour, and it is
calculated from the raw (un-weighted) Service Unit Per
Second value (MXG's SU_SEC variable from TYPE72). The
equation to calculate the hourly MSU capacity is:
MSU= 3600*SU_SEC*NRCPUS/1000000 = 336 MSU (per hr)
(e.g.: 10 engine, SU_SEC=9334.8828, a z900 2064-110)
- But SU_SEC value in PDB.RMFINTRV and TYPE72 data is an
LPAR value, and is based on the number of CPU engines
that you gave to that LPAR for this system; increasing
the number of engines decreases the SU_SEC value, due
to the Multi-Processor effect that causes the recorded
CPU time to increase with the number of engines:
Spin loops for access to serialized storage is seen
as CPU time, and the recorded CPU time increases as
the number of engines increases, so to get constant
Service Units, we must multiply by a smaller factor.
An example of the 9021-711 family's MP Factors
CPUs 1 2 3 4 5 6 7 8 9 10
Pct: 100 95 92 88 85 81 79 77 75 72
So instead of using the SU_SEC value for each LPAR,
which varies with the number of engines in each LPAR,
the MSU capacity measurement in z/OS is based on the
new CECSUSEC variable, which is the SU_SEC for all
engines, the "SU_SEC" of the physical "box" or "CEC"
CEC, was Central Electronics Complex,
CPC, now Central Processing Complex,
and CECSUSEC is constant from LPAR to LPAR in a box.
CECSUSEC did not exist in the RMF records, and it has now
been added in z/OS as SMF70CPA, but MXG creates it now so
we can calculate MSU capacity even before you're at z/OS.
a. The original (18.11) algorithm to calculate CECSUSEC
and MSU from pre-z/OS records (replaced, below):
In OS/390 RMF TYPE72 records, we only have the SU_SEC
of this LPAR, but we could calculate the CECSUSEC from
the LPAR SU_SEC and the "table of MP factors",
above, given the engines in the LPAR and in the box:
CECSUSEC=SU_SEC*MP(PARTNCPU)/MP(NRCPUS);
where
MP(n) is the MP factor for n engines, above, and
PARTNCPU=engines in the physical CEC, and
NRCPUS =engines in this LPAR.
A numerical example:
An LPAR with an SU_SEC = 1000
with NRCPU = 2 (2 engines for this LPAR), and
on a 6-way CEC (PARTNCPU=6) would have a
CECSUSEC = 1000 *(81)/(95) = CECSUSEC = 852
At 100% busy that 2-CPU LPAR has MSU capacity of:
MSU = 3600sec*852SU_sec*2engines/1000000=6.1 MSU
b. The present (18.18) algorithm to get IBM MSU capacity
(pre-z/OS) using table lookup of IBM published values:
The original code worked fine for that one set of MP
factors, but the factors vary with CPU families, and
IBM does not publish a table of MP factors; instead
IBM publishs the MSU capacity of each CPU, and with
the help of Alan Sherkow, the new $MG070CP format is
created as a look-up table that returns the capacity
in MSU and the CECSUSEC, given the CPUTYPE, CPUVERSN,
and (for 2064's) the CPCMODEL.
Alan also noted that the MSU capacity calculated from
CECSUSEC does not exactly match IBM's MSU table value,
even though we thought it should; differences of up to
10% were observed on some particular machines.
c. When you're running under z/OS with License Manager,
the needed fields are added by IBM to the type 70 RMF
record and are kept in PDB.RMFINTRV dataset:
MXG Variable z/OS Variable Description
CECSUSEC SMF70CPA SU_SEC of n-way CPC
MSU4HRAV SMF70LAC 4-hour Average MSU
MSUINTRV n/a Interval MSU count
temp SMF70WLA Defined MSU Capacity
While IBM will provide the SMF70LAC field in z/OS, MXG
now calculates MSU4HRAV from RMF Interval records, going
back four hours, and uses the actual interval durations
so it supports different interval sizes. The last four
hours of each system is written out to SPIN.SPINRMFI so
they can be re-introduced tomorrow so that the four-hour
is continuous in RMFINTRV. (If you're using ADDMSU with
a large PDB.RMFINTRV, default array sizes of 9999 permit
three month's worth of 15 minute intervals.)
This is new territory, and we'll know a lot more about
MSU4HRAV when the License Manager product is released,
but at least now you can begin to measure your LPARs in
these IBM units that will certainly be important in the
future of capacity measurement.
Please do not confuse the License Manager measurements
with Usage Based Pricing, because they are not related.
Under the License Manager, it will be the size of the
LPAR that you define that sets the price you pay for
Software that runs in that LPAR, and it is the total
work in that LPAR (and not the usage of any software
product) that is measured and compared with the LPARs
defined capacity in MSU. There is no measurement of
product's software usage under License Manager, and it
is all work in the LPAR that will be capped if the
MSU4HRAV/SMF70LAC exceeds the SMF70WLA capacity.
Change 18.297 Cosmetic. The test IF NUMTRANS GT 0 for the calculation
ASUMCICX of SQRTARG is redundant so it was removed.
Dec 8, 2000
Thanks to Ian Mackay, Royal Bank of Scotland, SCOTLAND.
Change 18.296 Variable SYSTEM and CPUTM are kept/summed respectively
ASUMCICS from input CICSTRAN/MONITASK data into the PDB.CICS
Dec 8, 2000 summary dataset. CPUTM=TASCPUTM+CPURLSTM in CICSTRAN.
Thanks to Aubrey Tang, Westpac Banking Corporation, AUSTRALIA.
Change 18.295 Support for APAR OWxxxxx which adds a flag bit to type 79
VMAC79 subtype 2.
Dec 8, 2000
Change 18.294 QBGLGG now decoded and kept, although the counters in the
VMACDB2 QBGL section are suspect and under investigation.
Dec 7, 2000
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 18.293 SPINCNT=SPINCNT+1; changed to SPINCNT=SUM(SPINCNT,1); so
IMACUOW that SPINCNT would actually be retained and incremented
Dec 7, 2000 and the SPIN library actually used.
Change 18.292A Support for MQ Series V5.2 SMF 115/116.
EXTY1152 -INCOMPATIBLE because subtype is now a two-byte binary at
EXTY1161 @19, having been corrected by IBM from the non-standard
EXTY116Q one-byte @19 (and that VMACSMF had catered for, and now
FORMATS had to be revised to cover both old and new 115/116 SMF).
VMAC115 -Reading new records with old MXG versions will create
VMAC116 zero observations from the new records.
VMACSMF -Type 115 Subtype 1, dataset MQMLOG has 7 new variables:
VMXGINIT QJSTBPAG QJSTCIWR QJSTLLCP QJSTLOGW QJSTLSUS QJSTSERW
Dec 8, 2000 QJSTTHRW
Dec 18, 2000 -Type 115 Subtype 2, new Q5ST DB2 manager statistics adds
70 new variables to existing dataset MQMMSGDM:
ABNDCNT ACTTASK CONNCNT DEADCNT DELECNT DELESCUW
DELESMXW DELETCUW DELETMXW DHIGMAX DISCCNT LISTCNT
LISTSCUW LISTSMXW LISTTCUW LISTTMXW NUMTASK READCNT
READSCUW READSMXW READTCUW READTMXW REQUCNT SCSBFTS
SCSDEL SCSDSCUW SCSDSMXW SCSDTCUW SCSDTMXW SCSINS
SCSISCUW SCSISMXW SCSITCUW SCSITMXW SCSMAXR SCSSEL
SCSSSCUW SCSSSMXW SCSSTCUW SCSSTMXW SCSUPD SCSUSCUW
SCSUSMXW SCSUTCUW SCSUTMXW SSKDEL SSKDSCUW SSKDSMXW
SSKDTCUW SSKDTMXW SSKINS SSKISCUW SSKISMXW SSKITCUW
SSKITMXW SSKSEL SSKSSCUW SSKSSMXW SSKSTCUW SSKSTMXW
UPDTCNT UPDTSCUW UPDTSMXW UPDTTCUW UPDTTMXW WRITCNT
WRITSCUW WRITSMXW WRITTCUW WRITTMXW
-Type 115 Subtype 2, new QEST Coupling Facility statistics
segment, MXG creates new MQMCFMGR dataset, one obs for
each structure (if QESTSTR structure name is non-blank:
IBM writes an array of 64 possible structures but MXG
outputs only the entries with data). MXG also calculates
the average duration of IXLLSTE and IXLLSTM calls in new
new variables QESTAVGE and QESTAVBM.
Updates to elements in the CF can be made one at a
time with IXLLSTE, or requests to update multiple
elements, a group of changes that have to be made
together, are done with IXLLSTM.
The other IBM variables created in MQMCFMGR dataset:
QESTCMEC QESTCSEC QESTMLUS QESTMNUS QESTMSTC QESTRMEC
QESTRSEC QESTSFUL QESTSSTC QESTSTR QESTSTRN
-Type 116: FORMAT MG116TY updated for '7:RRS BATCH' type
of attachment type.
-Type 116 subtype 0 creates old MQMACCT Message Manager
accounting; this was the only data set created from SMF
116 record prior to Version 5.2.
-Type 116 subtype 1 creates new MQMACCTQ Queue Level
Accounting dataset with WTIDxxxx and WTASxxxx variables.
This is the important, task-level, dataset, with elapsed
and CPU times per verb for commit and back out requests,
and has task identification, including Job, User ID,
Transaction Name if applicable, and Channel Name (TCP/IP
address or APPC LU).
-Type 116 subtype 1 or subtype 2 creates new MQMQUEUE
Queue Detail with WTIDxxxx and WQxxxx variables. This
data set has an observation for each QUEUE used by the
task, including number/elapsed/CPU times for MQOPEN,
MQCLOSE,MQPUT,MQPUT1,MQGET,MQINP and MQSET calls, and
the WTIDxxxx task identifiers.
Change 18.292 Cosmetic. Comment corrected and labels for Mount Wait
ASUMTMNT bucket variables MNTBKTn changed from 'PCT JOBS' to
Dec 6, 2000 the more accurate 'PCT MOUNTS*MOUNT WAIT*LESS THAN....'.
Thanks to Chuck Hopf, MBNA, USA.
Change 18.291 Cosmetic. Labels added for DOMTRESP/DOMTWAIT/DOMTRTYP/
VMAC103 DOMTRNUM variables in VMAC108, and dataset labels in the
VMAC108 VMAC103 are now "HTTP Web Sphere Server" instead of the
Dec 6, 2000 Lotus Domino no-longer-used name.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 18.290 TMON for MVS 2.0 NQ records were not correct; Landmark
VMACTMV2 inserted data between 1.3 and 2.0, but no one noticed!
Dec 5, 2000 Both record formats are now supported, and new variables
are now created in dataset TMONNQ.
Thanks to Lindsay Robertson, GMAC Insurance, USA.
Change 18.289 Using IMACJBCK exit for DB2ACCT selection saves CPU time!
IMACJBCK The IMACJBCK exit (or MACJBCK= macro) is invoked in every
VMACDB2H SMF record that contains JOB name. For the DB2 SMF 101
Dec 5, 2000 Account records, using it instead of the EXDB2ACC/ACB/ACP
exit member to delete unwanted records can save lots of
CPU time, because it is invoked earlier in the processing
code, after the QWHS (Standard) and QWHC (Correlation)
Headers have been input, and before INPUTing all of the
other variables in all of the segments in the rest of the
accounting record, and then invoking the EXDB2ACx exit.
These QWHSxxxx and QWHCxxxx variables exist when IMACJBCK
exit is taken, and can be used to delete SMF 101 records
early, fully decoding only the selected records and then
taking EXDB2ACx exit before output into DB2ACCT/ACCTB/P:
SMFTIME ='TIME WHEN*SMF RECORD*WAS WRITTEN'
QWHSSTCK='STORE CLOCK*VALUE FOR*HEADER'
QWHSSSID='SUBSYSTEM NAME'
QWHCAID ='AUTHORIZATION ID '
QWHCCV ='CORRELATION ID '
QWHCCN ='CONNECTION NAME '
QWHCPLAN='PLAN NAME '
QWHCOPID='ORIGINAL OPERATOR ID'
QWHSRELN='RELEASE INDICATOR'
JOB ='JOB NAME*OR*TSO USER'
QWHSLUNM='LUNAME'
NETSNAME='ORIGINATING*SYSTEM*NET-NAME'
QWHCEUTX='END USERS*TRANSACTION*NAME'
QWHCEUID='END USERS*USERID*AT WORKSTATION'
QWHCEUWN='END USERS*WORKSTATION*NAME'
QWHCATYP='CONNECTING*SYSTEM TYPE*CODE'
Numeric values and their meaning:
0='0:UTILITY'
1='1:TSO'
2='2:DB2 CALL ATTACH'
3='3:DL/I BATCH'
4='4:CICS ATTACH'
5='5:IMS ATTACH BMP'
6='6:IMS ATTACH MPP'
7='7:DISTRIBUTED UOW'
8='8:REMOTE UOW'
9='9:IMS CONTROL REGION'
0AX='AX:IMS TRANSACTION BMP'
0BX='BX:UTILITY JOBS'
In your logic in IMACJBCK, you must DELETE unwanted SMF
records, so you must use NOT logic to select wanted:
//SYSIN DD *
%LET MACJBCK= %QUOTE(
IF ID=101 THEN DO;
IF QWHSSIID NE 'DB2SYS1' THEN DELETE;
IF NOT (JOB='MINE' AND QWHCPLAN='PLAN1') THEN DELETE;
END;
);
%ANALDB2R(PDB=SMF);
This change is minor: it moved the %INCLUDE of IMACJBCK
in member VMACDB2H to the end of the Correlation Header,
so all QWHCxxxx variables exist when at IMACJBCK. Added
are QWHCATYP/NETSNAME and new-in-6.1 QWHCEUID/EUTX/EUWN.
(There was no change to IMACJBCK; it just listed here so
you'll find this change when searching for that string!).
Savings: Reading 4.3GB of SMF 101 records to create all
these obs on an SU_SEC=2700 engine took 1426 CPU seconds.
Data Set Observations MegaBytes
DB2ACCT 1,842,166 1500
DB2ACCTG 1,289,146 800
DB2ACCTB 3,915,350 1430
DB2ACCTP 2,700,571 920
Total Output 4650
Deleting all obs in the _EDB2ACx exit took 1257 secs. The
delta of 1426-1257 = 169 seconds is the CPU cost for SAS
write out the 4.5 GB of output, about 27 MB/CPU second.
Using MACJBCK to delete all obs took 318 CPU seconds, so
the delta of 1257-318 = 939 seconds (deleting in _E exit)
is the CPU cost for SAS to execute the INPUT statements
for the 4.3 GB of SMF or about 4.6MB/CPU second.
The 318 seconds is the CPU cost just to read in all 4.3GB
of SMF, because the Headers are actually at the physical
end of each SMF record, so SAS reads SMF records at about
13.8 MB/CPU second.
Case Study:
Read 4.3GB Execute Write 4.5GB
SMF Data Input SAS Output Total
Output all: 318 secs 939 secs 169 secs 1426 secs
Output half:
_EDB1ACx 318 939 85 1342
IMACJBCK 318 470 85 873
Using IMACJBCK to select half of the obs saves 470 secs.
With this much possible saving, we will enhance ANALDB2R
in the near future so that any selection we can do in the
IMACJBCK exit will be done there if you use PDB=SMF for
your DB2PM-like reports, but you can exploit this exit
right now using the above example.
Thanks to Ron Alterman, Charles Schwab & Co., Inc, USA.
Change 18.288 The JCL in the TESTOTHR step of JCLTEST8 did not have the
JCLTEST8 //TMDCIN DD DUMMY and //TMDVTIN // DD DUMMY statements.
Dec 4, 2000 Member TESTOTHR had been updated to test the new support
and JCLTEST6 was updated, but JCLTEST8 was overlooked.
Thanks to Peter Herden, TUI (Touristik Union) Hannover, GERMANY
Change 18.287 Assembly error IEC293I FIRST DCB IN CLOSE NOT ACCESSIBLE
ASMIMSL6 because CLOSE (R3) must be CLOSE ((R3)) in line 1333.
Dec 1, 2000 Many MXG users have seen this error when they assembled
that program, but being ASM experts, they fixed it and
never told me about it! Since R3 is an address in reg 3
the parens tell the ASM that R3 is not a ddname!
Thanks to Alan Green, Zurich Financial Services, ENGLAND.
Thanks to Trevor Ede, EDS, NEW ZEALAND.
Change 18.286 The four new duration variables for initiator delays:
VMAC30 SMF30JQT /*JOB*PREPARATION*TIME*/
Nov 30, 2000 SMF30RQT /*INELIGIBLE*FOR*EXECUTION*TIME*/
SMF30HQT /*JOB*HOLD*TIME*/
SMF30SQT /*ELIGIBLE*FOR*EXECUTION*TIME*/
were multiplied by 1.024, but should have been multiplied
by 1024, as they are in 1024-microsecond units.
May 22, 2004: APAR OA07041 corrected SMF30SQT.
Thanks to Steve Simon, ALLTEL, USA.
Change 18.285 Cosmetic. Label for QWACARNG was corrected to be
VMACDB2 QWACARNG='WAITS FOR*SEND MSGS*DATA SHARING'.
Nov 30, 2000
Thanks to Allan J. Winston, MBNA, USA.
Change 18.284 JES 3 only. The WEEKBLD/WEEKBLDT/MONTHBLD members all
WEEKBL3 referenced dataset NJEPURGE which is JES2 only. These
WEEKBL3T three members can be used for JES3 sites; the only change
MONTHBL3 is that DJEPURGE instead of NJEPURGE is processed, and
Nov 29, 2000 the TYPE25 (also JES3-only) processing is added.
Thanks to Robert Sample, Atlanta Journal-Constitution, USA.
Change 18.283 IMS 6.1 only; variable MSGSZOUT is a constant and wrong
TYPEIMSB value in IMSTRAN dataset; the PUT "SUBQ6 $EBCDIC12." was
Nov 29, 2000 corrected to "SUBQ6 $EBCDIC4." to prevent the overlay.
My apologies to Pete Gain who's correct fix I typoed!
Thanks to Alan Green, Zurich Financial Services, ENGLAND.
Change 18.282 Invalid length ILKA record subtype 20 is protected now,
VMACILKA but the record is still invalid. The length of data in
Nov 29, 2000 SMFACDLN is 11,640, but the record is only 4092 bytes,
and the number of subpools expected is 256, but there is
room only for the first 98 subpool segments. This change
detects the bad record, prints a message on the log, and
outputs only the found subpool segments, while awaiting
a correction from the vendor. Only ILKAST20 dataset is
affected by this error.
Thanks to Frank d'Hoine, Nationale Bank van Belgie, BELGIUM
Change 18.281 Three logic errors in VMXGUOW were corrected:
VMXGUOW -IRESPTM was being summed from all MRO transactions, due
Nov 24, 2000 to the mis-location of the code that sets IRESPTM to the
single internal response time of the "TOR" transaction
(i.e.: now, IRESPTM is the response of the transaction
used for TRANNAME and TERMID).
-Counters were being summed as: HOLDX=HOLDX+X; but that
results in a missing value in the PDB.ASUMUOW output data
set if any counter was missing for any observation in the
input. Instead, the more robust HOLDX=SUM(HOLDX,X);
statement is used in VMXGUOW, so that only if all values
of a variable is missing in all input observations will
that variable have missing value in PDB.ASUMUOW output.
-The INCODE= segments (intended to allow tailoring things
like normalize CPU times across different processors, or
to add new variables) was mis-located after the code that
added the new variables, so new variables were missing.
Thanks to Chuck Hopf, MBNA, USA.
Change 18.280 Cosmetic, only affected MXG processing under ASCII SAS.
VMAC110 The variables RTYPE and RRTYPE should have been INPUT as
Nov 24, 2000 $EBCDIC1. instead of $CHAR1., so that they were converted
into ASCII characters for printing and MG110RT format.
See Change 18.313.
Change 18.279 NPM Type 28 Subtype 'DC'x (VTAM CSM Buffer Pool data) had
VMAC28 INPUT STATEMENT EXCEEDED INPUT RECORD error because I
Nov 24, 2000 mis-read the documentation. The four fields input at the
Nov 27, 2000 end of the sub-subtype VCSVDTYP=1 record (VCSMAXFS thru
VCSCUREC) exist in the VCSDTYPE=2 record, where they are
properly input. The four lines in the VCSVDTYP=1 INPUT
statement were replaced by +4 (to skip over the four
undocumented bytes at the end of the 176 byte segment).
Nov 27: Variable NRTDTYPE now kept with other NRT vars.
Thanks to Bruno Peeters, Dexia Bank Belgium, BELGIUM.
Change 18.278 -Summarization of CICS Statistics into CICINTRV for "EOD"
ADOCCICI (sum all "INT" and "End-of-Day" shutdown records into one
VMXGCICI total observation for each execution of a CICS region)
Nov 23, 2000 did not work properly: INTERVAL=EOD was never defined in
VMXGSUM/VMXGDUR, causing missing COLLTIME and STARTIME,
and multiple executions were lumped together. Since EOD
is defined only for CICS "EOD" in CICINTRV (set by adding
MACRO _CICINTV EOD % in your IMACKEEP or IMACCICS),
VMXGCICI was revised if EOD was requested and now passes
INTERVAL=MYTIME, and MYTIME= DATETIME=COLLTIME;, values.
The end result is that you get one observation for each
APPLID COLLTIME, where COLLTIME=CICSSTCK, logically the
the READTIME of each CICS region execution.
Note that if you dump your SMF data at midnight, and
stop/start the CICS regions daily at, say 4am,
requesting EOD will create two observations in todays
PDB.CICINTRV, one with yesterday's CICSSTCK time,
for the interval from midnight until 4am, and one with
today's CICSSTCK, summarizing the interval from 4am
until midnight, and neither observation would have the
total resources for each execution.
-Additional enhancements were also made. The PDB.CICINTRV
dataset is now created with the variables in alphabetic
order (with SYSPLEX SYSTEM SMFPSSPN COLLTIME etc. first)
by inserting a LABEL statement in the ORDER= argument of
the final VMXGSUM invocation.
-Two variables that had been summed are now maxed from the
SMD data: MAX=SMDHWMPS SMDIFREE
-Two variables that had been summed are now maxed from the
SMT data: MAX=SMTHWMPS SMTNTASK
-One variables that had been overlooked is now summed in
the XMC data: SUM=XMCPWQ
-These variables that had been overlooked are now summed
in the XMR data:
SUM= XMRAMISM XMRFAIT XMRFANW XMRFAOPN XMRFAOT
XMRFATX XMRITOV XMRIWAIT XMRRC
-Member ADOCCICI now documents which variables from which
Statistics datasets are SUM, MIN, MAX, and MEANed, and
how interval datasets are sorted. All except the MEANed
variables are defendable: for some datasets with multiple
records per interval (LSRPOOL, FCR), I calculate average
values that are of dubious value, so disregard them if
they are useless. Sometimes, averages are useful for
trending, and in all these cases, you still can go back
to the original detail to examine specifics.
Thanks to Normand Poitras, ISM, Canada.
Thanks to Chuck Hopf, MBNA, USA.
Change 18.277 Cosmetic. Labels for R744SSTA, R744STAC, and R744STRC
VMAC74 were corrected from the original documentation and now
Nov 20, 2000 match the SMF manual's description.
Thanks to Raimo Korhonen, CompMeas Consulting Oy, FINLAND
Change 18.276 CICS TS 1.3 SAP Journal Format SMF records were output in
VMAC110 dataset CICSJOUR instead of CICSSAP. The MXG test
Nov 16, 2000 IF JCRUTRID='SA' AND JCRLL GE 250 THEN DO;
was false because JCRLL is not created for the GLRHTYPE=2
sub-subtype journal format record. Instead of testing
JCRLL, the variable LENUDAT is used to verify that there
are at least 250 bytes of journal data left to read:
IF JCRUTRID='SA' AND LENUDAT GE 250 THEN DO;
and also the test for 00D1 was similarly changed to:
ELSE IF JCRUTRID='00D1'X AND LENUDAT EQ 50 THEN DO;
Thanks to L. Theodorides, Alte-Leipziger, GERMANY.
Change 18.275 Support for Vital Signs VisionNet VSAM file.
TYPEVITA Work in progress; only the subtype '38'x has been decoded
Nov 16, 2000 and code is not yet fully structured. But it works.
Thanks to Craig Collins, State of Wisconsin IT Services, USA.
Change 18.274 JES3 only. A short SMF type 6 record (90 bytes) had a
VMAC6 short "I/O Data Section", with SMF6LN1=30, which MXG had
Nov 16, 2000 not ever seen before. Normally, SMF6LN1=52 because all
thirteen fields existed, and MXG read them all. This
record ended with field SMF6DFE='01C9'x, which itself is
also not expected. Now, MXG tests for SMF6LN1=52 before
inputting SMF6DFE and the four subsequent fields.
Thanks to Robert Sample, Atlanta Journal-Constitution, USA.
Change 18.273 MXG 18.09 only. NPM APAR OW37743 inserted a four byte
VMAC28 field in the CSL segment in the NPMSUBTY='A0'x ODLC SMF
Nov 16, 2000 type 28 record, and MXG attempted to support that APAR in
Change 18.254, using IBM documentation only and no test
data, but now I find out IBM fibbed. MXG coded to test
the bit that IBM said would be on when the new field was
present, but data now shows the bit is on in records that
don't have the field (and without the APAR!), causing an
INPUT STATEMENT EXCEEDED RECORD LENGTH error. MXG now
uses the LENAOF segment length to determine if the field
is or is not inserted in your record. The original code:
IF LCSLCON6='1.......'B THEN INPUT LCSLT3S &PIB.4. @;
IF LENAOF GE 192 THEN DO;
INPUT
was replaced by these statements:
IF LENAOF GE 192 THEN DO;
IF LENAOF GE 196 THEN INPUT LCSLT3S &PIB.4. @;
INPUT
Thanks to Richard Rich, California Stephen P. Teal Data Center, USA.
Change 18.272 This example that analyzes allocation time components
ANALALOC (including HSM recall) had "IOPDB.xxx", but that was
Nov 13, 2000 changed to "PDB.xxx" to be consisted with other ANALs.
Thanks to Forrest Nielson, State of Utah, USA.
Change 18.271 Variable STC14VSZ now is formatted MGBYTES. (so that
VMACSTC it prints pretty!).
Nov 8, 2000
Thanks to Chuck Hopf, MBNA, USA.
Change 18.270 The SARRU33 records from CA-VIEW for subtype 33 (DELETE
VMACSARR REPORT) reserved field before SV33LNES should be +2 and
Nov 8, 2000 not +1. This caused subsequent fields in the dataset
to be incorrect.
Thanks to Craig Raridon, RadioShack, USA.
Change 18.269 ASTEX records were not read under ASCII SAS; the test for
VMACDMON DMONREC='F1'x, 'F2'x, and 'F3'x must be changed to '1',
Nov 8, 2000 '2', and '3' respectively, as DMONREC was INPUT with
$EBCDIC1, it became an ASCII character value under ASCII
SAS.
Thanks to Neil Ervin, Charles Schwab, USA.
Change 18.268 DSA size variables (SMSDSALI,SMDSATO,SMSHWMDS,SMSHWMDT,
VMXGCICI others) were incorrectly summarized into CICINTRV.
Nov 5, 2000 Some size variables were summed when they should not be.
Nov 12, 2000 These SMSDSANM count variables are summed in CICINTRV:
SUM=SMSASR SMSCREL SMSCRISS SMSCSS SMSCSSCM
SMSCSUBP SMSDSR SMSEXTS SMSEXTSA SMSEXTSR
SMSFMREQ SMSGMREQ SMSHWMSS SMSPWWS SMSSOS
SMSSV SMSTSOS SMSUCSS ,
and these SMSDSANM size variables are maxed in CICINTRV:
MAX=SMSUSSCU SMSUSSHW SMSCSSHW SMSDSALI SMSEDSAL SMSDSAT
SMSEDSAT SMSHWMDT SMSHWMED SMSNPAGP
Sizes (current, hwm, total, cushion) of each specific
DSA (CDSA,RDSA,SDSA,UDSA,ECDSA,ERDSA,ESDSA,EUDSA)
were correct in the CICSMDSA detail dataset, and it
must be used for analysis by SMSDSANM (DSA name).
Also, ANALCISH produced correct values.
Thanks to William Sherriff, IBM Global Services, USA.
Change 18.267 Variables SMF14CDL, SMF14CDS, SMF14UDL, and SMF14UDS are
VMAC1415 now formatted with MGBYTES, and they contain byte counts.
Nov 4, 2000
Thanks to Chuck Hopf, MBNA, USA.
Change 18.266 Support for NETVIEW "Hardware Monitor" type 37 SMF record
VMAC37 APAR OW45728 added new variable BRFRIBID, the
Nov 3, 2000 Ring Number (for token-ring LAN) or the bus number (for a
CSMA or token-bus LAN) to dataset TYPE37.
Change 18.265 Corrections based on source code scanning.
VMAC90A -Variable NEWFWKLD was not in keep in VMAC90A.
VMACTMDC -Variable CNSRRBA was not created nor kept in VMACTMDC.
VMACOMVT -Variables ON29UNK1-OM29UNK5 were removed from KEEP list
VMACPMTR as they are now known, input, with correct names.
Nov 3, 2000 -Dataset OMVTTCPC was incorrect, because "NEW" string had
been left in columns 1-3, but now have been removed.
-There was no %%INCLUDE SOURCLIB(IMACZDAT) in VMACPMTR,
so variable ZDATE was never created in dataset PERFMETR.
Thanks to Freddie Arie, TXU Gas, USA.
We took real vacation in Chena Hot Springs, near Fairbanks, Alaska. No
email for six days, saw the aurora three nights, made 9,000 ham radio
contacts (at KL7RA, with six other hams, during the annual 48-hour CQ
World Wide DX contest: made 8,600 contacts during the first 24 hours,
and then aurora hit Saturday night, and we made only 400 more QSO's in
the last 24 hours of the contest!).
======Changes thru 18.264 were in MXG 18.09 dated Oct 24, 2000======
Change 18.264 Changes to this SAS/Graph report example for RMFINTRV and
GRAFWORK TRNDRMFI Workload reporting now exploits HTML and SAS V8.
GRAFSAMP -PDBOUT added, allows you to write the output graphics
Oct 23, 2000 catalog to a different location than the input PDB.
This is important if you are using SAS/CONNECT to read
the input data from a mainframe PDB but want to store
the output on your PC or LAN. The default is "PDB".
-New parameter HTMLPATH= (default is null) should point
to a directory where all of the JPG files and HTML code
created by GRAFWORK will be stored.
-Member GRAFSAMP is a sample execution of GRAFWORK based
on a mainframe PDB as input using SAS/CONNECT with an
output PDB on a LAN and HTML being generated.
Thanks to Chuck Hopf, MBNA, USA.
Change 18.263 Changes to this SAS/Graph report example for RMFINTRV and
GRAFRMFI TRNDRMFI reporting has been enhanced to exploit HTML and
Oct 23, 2000 SAS V8, and to remove the now-obsolete VMXGGOPT macro.
-DEVICE= operand now directly used the GOPTIONS statement
rather than using VMXGGOPT.
-New parameter HTMLPATH= (default is null) should point
to a directory where all of the JPG files and HTML code
created by GRAFRMFI will be stored. At the conclusion
of GRAFRMFI, point your browser at the RMFIFRAM.HTML
dataset in the HTMLPATH= directory to view the generated
WEB pages.
Thanks to Chuck Hopf, MBNA, USA.
Change 18.262 Changes to this SAS/Graph report example for tape usage
GRAFTAPE has been enhanced for usability, and new options that
Oct 23, 2000 exploit ODS and SAS Version 8 for HTML output. This
example uses data from MXG's Tape Mount Monitor and from
STK's HSC and LSM records, expecting these datasets in
your TREND library: TAPEMNTS TRNDTALO TRNDHSC TRNDLMS.
-New parameter HTMLPATH= (default is null) should point
to a directory where all of the JPG files and HTML code
created by GRAFTAPE will be stored.
-DEVICE=JPEG provides a good choice of devices to make
your output more accessible and useable.
-DISPLAY=NODISPLAY now has no effect, since with SAS V8,
no output is produced if this option is in effect.
-GOUTTYPE=INDEPENDENT was removed to eliminate a warning
that had no meaning, and NOLIST added to all executions
of PROC DATASETS.
Thanks to Chuck Hopf, MBNA, USA.
Change 18.261 TYPE74 data for PAV Volumes had percentages over 100% for
VMAC74 PCTDVACT, PCTDVCON, PCTDVPND, and PCTDVUSE, because MXG
Oct 21, 2000 did not average those values across the number of UCBs
that were used during that interval. But now, to match
the IBM RMF report philosophy, all of the duration-based
device percentages are now divided by NREXPOSR to give
the average percentage. Note that only the percentage
values are divided by NREXPOSR; the duration variables
are unchanged, so in a 15 minute you could record true
DEVACTTM=39:58, DEVCONTM=21:33, DEVPNDTM=15:45 (with
DLYDEVTM=04:53 and DLYOTHTM=10:52).
This table maps the MXG variable names for the TYPE74
measures of duration, milliseconds per SIO, and percent
of the interval duration to their IBM DASD Report tag:
IBM MXG Duration Per-SSCH Percentage
---- ACT DEVACTTM dne PCTDVACT
CONN CON DEVCONTM AVGCONMS PCTDVCON
DISC DIS DEVDISTM AVGDISMS PCTDVDIS
IOSQ IOQ DEVIOQTM AVGIOQMS dne
PEND PND DEVPNDTM AVGPNDMS PCTDVPND
CUB CUB DLYCUBTM AVGPNCUB PCTPNCUB
DB DEV DLYDEVTM AVGPNDEV PCTPNDEV
DPB DIR DLYDIRTM AVGPNDIR PCTPNDIR
--- OTH DLYOTHTM dne PCTPNOTH
RESP RSP dne AVGRSPMS dne
USE USE dne dne PCTDVUSE
where dne = "does not exist" = is not created.
Schematically, these fields are related:
|----------------------ACT--------------------|
|----------PND----------|--DIS--|-----CON-----|
|-CUB-|-DEV-|-DIR-|-OTH-|
MXG creates the "Other" Pending time because the sum of
individual pends (CUB + DEV + DIR) is less than the total
device PND time. IBM does not directly report that other
component of pending time (although RMF shows it if you
compare DPB+CUB+DB DLYs with PEND). This PCTPNOTH has
usually zero, but now with PAV volumes, it has been seen
to be quite significant in this DURATM=900 sec interval:
One PAV Volume. NREXPOSR=4. DURATM=900 seconds.
|---------------------2398--------------------|
|----------------------ACT--------------------|
|----------945----------|--159--|----1293-----|
|----------PND----------|--DIS--|-----CON-----|
|-0.0-|-293-|-0.0-|-652-|
CUB DEV DIR OTH
The "Other" Pend time of 652 seconds is significant, and
according to none other than Dr H.P. Artis, for PAV, that
Other Pend, PCTPNOTH, includes the response time of the
subsystem to receive, verify, and acknowledge the first
CCW of the channel program. PEND time ends when the
subsystem (i.e., the logical volume) acknowledges the
first CCW. (Included in Other Pend is the percent of
time when I/O was pended due to conflicting Data Extents
for a track range, that is, overlapping writes and reads
waiting for a Data Extent area that is already being
written.
This Other Pend is the I/O delay to shared users of the
same dataset due to PAV parallelism, but without PAV,
that contending job could have had a much larger delay:
in the old days with MIM, the job would have run into
a DSENQ event, been put in hold and still be waiting in
the JES2 Held Job Queue until the enqued dataset was
freed by the first job, or now, with no limit on number
of batch initiators, the job is waiting in the DSENQTM
duration, initiated and holding an initiator, awaiting
allocation, held due to DSNAME ENQ due to DISP=OLD.
Note also that the Connect duration of 1293 seconds is
greater than the interval duration; PAV drops the point
of exclusive control to the track range in the data
extent for writes, and any number of simultaneous reads
can be concurrent even for one track as long as there is
not a write active for that track. I had trouble with
this until I realized that PAV must be behind cache so
parallel I/O to the channel occurs, and even for a cache
miss, the back end can have a 6:1 raid scheme which would
also permit six parallel I/Os between cache and raid.
Note that EMC's PAV's do not have any miss-parallelism,
due to their choice of a raid-1 back end.
A recent MXG-L posting reported an ADABAS volume with
an average of 37 UCB's assigned, showing PAV might be
a real salvation for that old database system!
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 18.260 REPORT=DEVC, columns %DEV RESV, %ANY ALLOC and %MT PEND
ANALRMFR have no values. AVG NUMBER ALLOC value is incorrect.
Oct 21, 2000 Line 4036
Change IF DEVCLASS NE 20X OR DEVCLASS NE 80X
To IF DEVCLASS NE 20X AND DEVCLASS NE 80X
Line 4056
Change IF DEVCLASS EQ 20X THEN PUT @1 STORGRUP @128" " @;
To IF DEVCLASS EQ 20X THEN PUT @1 STORGRUP @;
Change 18.259 Under SAS V8, you cannot re-define MACRO _BLD005 using
BUILDPDB %LET MACKEEP= to add PROC SORT and DATA steps before the
Oct 21, 2000 include of BUILD005, although it worked under V6. Instead
you can redefine MACRO _EPDBOUT (or use member EXPDBOUT)
to insert you code, and that is actually the exit that
should be used. In this case, the user wanted to sort
and create a PDB.TYPE30_5 dataset of today's records.
I will pursue the V8 problem with SAS when time permits.
Thanks to Simon Briggs, Allied Irish Bank, IRELAND.
Change 18.258 Variable CPCMODEL was added to dataset TYPE70PR by Change
VMAC7072 17.138, and is now also added to dataset TYPE70.
Oct 18, 2000
Thanks to Dr. Alexander Raeder, Karstat AG, GERMANY.
Thanks to Harmuth Beckmann, Karstat AG, GERMANY
Change 18.257 Tivoli NPM Type 28 Subtype 14X NRT record caused either a
VMAC28 NONZERO AOF NPMSUBTY=14 or UNEXPECTED NRPDTYPE=1 error.
Oct 14, 2000 Only NRPDTYPE=2 records (IBM Router) had been received,
so MXG forced this error to validate the Cisco NRPDTYPE=1
record, which turn out to be validly supported by MXG if
the DO group writing this message is deleted and the test
IF NRTDTYPE=2 THEN DO; is replaced with
IF NRTDTYPE IN (1,2) THEN DO; /*IBM/CISCO */
Thanks to Sandra Mischianti, Nicus Software, USA.
Thanks to Ken Patterson, Chemical Abstracts Service, USA.
Change 18.256 The MG073CD format for SMF73CPD (Channel Path Type) now
FORMATS decodes bits: 10X:OSA EXPRESS and 11X:OSA EXPRESS DIRECT
Oct 14, 2000 for those types of channels.
Thanks to Bob Falla, Clarica, CANADA.
Change 18.255 A semi-colon was missing after _ETY30TD invocation, so if
VMAC30 you tailored _ETY30TD and did not end your tailoring with
Oct 14, 2000 a semi-colon, ERROR 79-322 EXPECTING SEMICOLON occurred.
Thanks to Lawrence Jermyn, Fidelity Investments, USA.
Change 18.254 Support for NPM APAR OW37743 (INCOMPAT) SMF 28 for 3746
VMAC28 devices if NPM is collecting TIC3 (ODLC) link resources.
Oct 12, 2000 A four byte field, LCSLT3S='ACTIVE PU*COUNT*PER TIC3',
was inserted into the CSL segment, trashing some fields
in MXG dataset NPMLANOD dataset. The APAR text notes
that TIC3 data can be created by an NPM NETCOLL command
naming a generic resource, such as ODLCLNLK or ALLLINES,
which will match any ODLC (TIC3) link resource cause the
TIC3 data to be captured and sent to NPM.
Thanks to John Wilmot, Midland Bank, ENGLAND.
Change 18.253 The IBM sample report had two columns labeled STG THLD
ANAL88 which we replicated, but the second column is STG FULL,
Oct 11, 2000 and we've corrected our Logger replica report.
Thanks to Tom Elbert, Fortis, USA.
Change 18.252 Support for APAR OW44456 which creates the new SMF 120
record from the Component Broker element of WebSphere
IMAC120 Application Server Enterprise (EE) Edition. WebSphere
VMAC120 Application Server Standard Edition (SE), Advanced
TYPE120 Edition (AE), and Enterprise Edition (EE) is an IBM
TYPS120 product suite that runs on NT, AIX, Solaris, OS/390 and
VMXGINIT more. The SE version includes JAVA and the WebSphere
Oct 10, 2000 Application Server, but the EE version adds the Component
Broker element, and APAR OW44456 provides SMF type 120
records to record measurement of the Component Broker
that runs on OS/390.
Note: none of these members exist; no doc yet.
Change 18.251 Even after Change 17.348, this SAS/GRAPH example failed
GRAFLPAR if you didn't have SAS/GRAPH. The Graph-only SYMBOL1,
Oct 10, 2000 etc., statements were protected by the %IF .. %DO group,
but the following four lines were not deleted.
Thanks to John Allgire, Group Health, USA.
Change 18.250 ERROR.TYPE110.SUBTYPE 2. CICS STATISTICS RECORD STID=126
VMAC110 is an MXG error. The STILEN is 280, but MXG had miscoded
Oct 18, 2000 STILEN-STILEN-272; where it now has STILEN=STILEN-280;.
The error caused zero observations in CICCFS6D dataset.
STID=126 is new CFDT Coupling Facility statistics.
-Two new data fields were added to STID=127 record for
the CICFS7D CFDT Server Table Access dataset.
Thanks to Bernard Cadet, Michelin, FRANCE.
Change 18.249 Variables IMSGTEXT and OMSGTEXT, the first forty bytes of
IHDRIMS the message text, are decoded from the IMS 01 and 03 log
VMACIMS records. They have been useful in fraud investigation!
Oct 5, 2000 In addition, new exit IHDRIMS has been added, after the
IMS record has been read, but before decoding, so that
unwanted IMS records can be deleted.
Thanks to Frank Baird, Oklahoma Department of Human Services, USA.
Change 18.248 Unused Change number.
Change 18.247 Support for Neon System's Shadow Server V4.5 SMF record
EXSHDW01 creates three datasets:
EXSHDW02 dddddd dataset description
EXSHDW06 SHDW01 SHADOW01 SHADOW END CONNECTION
IMACSHDW SHDW02 SHADOW02 SHADOW INTERVAL
TYPESHDW SHDW06 SHADOW06 CLIENT REQUEST
TYPSSHDW The SHADOW01 observations may be end of Session, SM01RCTY
VMACSHDW ='S', or if the Logging feature is enabled, you will also
VMXGINIT get Interim Interval (='I') and Final Interval (='F').
Oct 4, 2000 Only subtype=1 data has been validated.
Thanks to Jim Gilbert, Sabre, USA.
Change 18.246 DB2 Report PMAUD03 failed (Uninit error for IF, NE, THEN)
ANALDB2R because the semicolon was missing from this line:
Oct 3, 2000 @90 'ORIGINAL AUTHID: ' QW0087OP;
Thanks to Bill Hamilton, Scottish Widows, SCOTLAND.
Change 18.245 Support for new NTSMF Objects:
EXNTADSM dddddd dataset Object
EXNTCFSE NTADSM ADSMCLNT ADSM Client Performance
EXNTMQQU NTCFSE COLDFUSE ColdFusion Server
EXNTWSCT NTMQQU MQQUEUES MQSeries Queues
EXNTWSQU NTWSCT WRLDMSCT WorldSecure/Mail Message Count
EXNTWSSM NTWSQU WRLDMSQU WorldSecure/Mail Message Queue
IMACNTSM NTWSSM WRLDSMTP WorldSecure SMTP Relay.
VMACNTSM The ColdFusion object still has errors in their data that
VMXGINIT Demand Technology is working to resolve. All except the
Oct 1, 2000 ADSM object's records have been tested.
-In addition, the "Full Image" object is now supported, as
it's counters are the same as the "Image" object with the
only difference being the instance name. In the Full
Image object the name includes the full file path name of
the loaded modules, while Image has only the filename.
Oct 24: The new ADSM object had no test records, so its
INPUT statement had not been executed. Compiling
under SAS V8 did not detect an MXG coding error
(there were no comments around the label text in
the ADSM INPUT statement), but SAS V6 did detect
an error at compile, but only accidentally: both
versions of SAS saw each word in the comment as a
variable to be input, but under V6, "variable"
TRANSFERRED was MORE THAN 8 CHARACTERS long.
CHARACTERS! This MXG coding error would have
been eventually detected, when test records were
read, but by using both V6 and V8 in the MXG QA,
yet another, later, change has been avoided!
Change 18.244 Candle's Omegamon for VTAM TCP record documentation was
VMACOMVT incorrect; revised DSECT was received and the code for
Oct 1, 2000 TCPA and TCPB datasets now matches the data records.
Change 18.243 While writing my CMG Workshop Paper on BUILDPDB, I was
MXGSAS stunned to find REGION=4096K on the EXEC PGM= statement
Sep 28, 2000 in the MXGSAS JCL Procedure that I distribute! That
should have been removed long ago. You should specify
either REGION=0 or REGION=64M on your JOB card.
Change 18.242 MXG 18.05-18.08 only. CICSTRAN variable PROGRAMB was not
VMACCIMS kept because it was spelled as ROGRAMB in the KEEP= list
VMACEDGS fortunately PROGRAM is the same as PROGRAMB, so the name
VMACSRMH is still there, and this was not reported, but instead
VMACLDMS was detected by Freddie continued source analysis. Other:
VMACRSDF -VMACIISL - Include of IMACZDAT added to create ZDATE.
VMACIISL -VMACEDGS - MDNDS removed from KEEP= list
Sep 28, 2000 -VMACSRMH - _KSRMNNU changed to _KSRMHNU
Oct 23, 2000 -VMACLDMS - corrected to PCDJJNAM,PCDJPSTN,PCDJCOND,
PCDDRLNG,DIRSVERS,DIRSCTL1 which were missing
the last character in KEEP= list, and LPCABR
changed to LPCAGR.
-VMACRSDF - RSDUNKN1-RSDUNKN4 instead of 2-5.
Oct 23: %%INCLUDE for IMACZDAT.
Thanks to Freddie Arie, TXU Utilities, USA.
Change 18.241 Macro _LNTTN32 was not defined, creating dataset _LNTTN32
VMACNTSM instead of TN3270SV. Insert, before MACRO _WNTTN32:
Sep 28, 2000 MACRO _LNTTN32 &PNTTN32..TN3270SV %
Thanks to Greg Jackson, National Life of Vermont, USA.
Change 18.240 For SAS user SMF record, new format $MGSASPR maps the
FORMATS variable SASPROC (Procedure Name) to the new variable
VMACSASU SASPROD (SAS Product Name that owns that Procedure).
Sep 27, 2000
Thanks to Raff Rushton, Kaiser Permanente, USA.
Change 18.239 Cosmetic. Freddie's post-QA analysis of every line of
VMAC90A MXG source code continues to get better! This iteration
VMAC28 identified variables in the KEEP= list in MXG source
UTILXREF members that were never referenced:
UTILXRF2 -In VMAC90A, variables NEWWKLD and MCPNAME in the KEEP=
Sep 26, 2000 list should be spelled NEWFWKLD and MPCNAME. This does
not cause an error, but those variables did not exist in
the output dataset because of the spelling error; only if
you went looking for those fields would you have noticed
the did not exist.
-And when he ran under SAS Version 6, he got VMAC28 NOTE:
LABEL VALUE FOR VARIABLE NITIFODP HAS BEEN TRUNCATED TO
A LENGTH OF 40, but that note did not appear under my SAS
Version 8 QA run, because V8 permits 256 byte Labels!
I have always limited my LABELS to 40 positions, only so
that you didn't get that TRUNCATED message on your log.
In fact, it is only by searching the SAS Log as part of
my own Post-QA analysis for the string TRUNCATED that I
find and correct these long labels in MXG source.
But now that the message goes away in SAS V8, should I
still keep LABELS to only 40 characters? I say YES:
- For sites still running under SAS V6, eliminating any
unneeded or non-impacting message might save me a tech
support call/email, and will save new users confusion
and wasted time.
- Since PROC PRINT SPLIT='*' is the MXG way to print the
label as column heading, if I were to increase label
length, it could mess up our nicely arranged reports.
Besides, you can always use your own LABEL statement
with your PROC PRINT if you want a wordier heading.
- MXG ADOCxxxx and DOCVER members only have room for 40.
- Forty has been enough to describe the first 112,498
variables I've created in MXG.
So I have modified my UTILXREF/UTILXRF2 programs to
detect any labels longer than 40 bytes as part of the
MXG QA stream, and shorten them before you see them.
Thanks to Freddie Arie, TXU Utilities, USA.
======Changes thru 18.238 were in MXG 18.08 dated Sep 25, 2000======
Change 18.238 The new logic fails when the SPIN.SPINUOW dataset exists,
ASUMUOW because a VIEW cannot be used when the input and output
VMXGUOW datasets are the same. Remove /VIEW=_TMPSPIN from the
Sep 25, 2000 DATA _TMPSPIN; statement.
Sep 26, 2000 Members IMACKEEP and IMACUOW were removed from %INCLUDE
Nov 17, 2000 in member ASUMUOW, and IMACUOW was added to the existing
INCLUDE of IMACKEEP in member VMXGUOW, so that MACKEEP is
only invoked once.
Sep 26: If ASUMUOW were executed in a separate step, and
not in the step that built CICSTRAN, the program fails
with CHAR/NUM conflicts, because macro _LCICTRN did not
exist. Now, new logic validates the existence of that
macro, and defines it with the MXG default if not found.
Nov 17: Under SAS V8, the error message was:
YOU CANNOT OPEN SPIN.SPINUOW.DATA FOR OUTPUT ACCESS
WITH MEMBER-LEVEL CONTROL BECAUSE SPIN.SPINUOW.DATA
IS IN USE BY YOU IN RESOURCE ENVIRONMENT SASDSVX.
Bottom line: Scratch and Reallocate the SPIN Library.
Thanks to Hank Oerlemans, Western Australia Police Service, AUSTRALIA
Change 18.237 The TYPS102A member was expected by the test job TESSIBM3
TYPS102A but that member did not exist.
Sep 22, 2000
Thanks to Dr. Alexander Raeder, Karstat AG, GERMANY.
Thanks to Harmuth Beckmann, Karstat AG, GERMANY
Change 18.236 Support for Landmark TMON for VTAM creates datasets:
EXTMVTAA dddddd dataset
EXTMVTAE TMVTAA TMVTAA
EXTMVTAS TMVTAE TMVTAE
EXTMVTIB TMVTAS TMVTAS
EXTMVTIN TMVTIB TMVTINB
EXTMVTSE TMVTIN TMVTIN
EXTMVTSI TMVTSE TMVTSE
EXTMVTSS TMVTSI TMVTSI
EXTMVTTN TMVTSS TMVTSS
EXTMVTVR TMVTTN TMVTTN
IMACTMVT TMVTVR TMVTVR
TYPETMVT Records AA, IN, SI, TN, and VR have been tested; the
TYPSTMVT TN records were discovered to have some fields that are
VMACTMVT accumulated, the _STMVTTN macro will deaccumulate TMVTTN
VMXGINIT dataset, and _STMVTTN is added to the TYPETMVT member so
Sep 21, 2000 that dataset TMVTTN is always deaccumulated; using the
TYPSTMVT member is recommended, since the TYPSxxxx member
invokes the _Sdddddd sort macros, which is where the MXG
DIF() logic for deaccumulation is invoked.
Thanks to Siobhan Hansen, Merrill Lynch, USA.
Change 18.235 Summarization and trending of STC datasets.
ASUMSTC Input dataset(s) Summarized dataset
TRNDSTC PDB.STCLMU PDB.ASUMLSM
Sep 21, 2000 PDB.STCENTER, PDB.STCEJECT PDB.ASUMENEJ
PDB.STCHSC PDB.ASUMHSC
Thanks to Chuck Hopf, MBNA, USA.
Change 18.234 This analysis uses SYNCSORT SMF records to identify jobs
ANALUAFF that used tape-to-tape sort steps, but that did not use
Sep 21, 2000 UNIT=AFF=SORTIN on the //SORTOUT dd statement, causing
the job to use an extra tape drive.
Thanks to Al Holz, Merck, USA.
Change 18.233 Both VMXGDUR and VMXGSUM now have new argument SYNC59 to
VMXGDUR add one minute to DATETIME for Interval calculations, so
VMXGSUM that sites which write at :59 minutes can have the start
Sep 21, 2000 of the interval be one minute later.
Thanks to Ian Davies, Canadian Utilities Ltd, CANADA.
Change 18.232 NETSPY 'I' record with NSPYENTL=124 caused STOPOVER ABEND
VMACNSPY because MXG expected NSPYENTL=170. The INPUT statement
Sep 20, 2000 is interrupted after variable OPTSEGSZ and the remaining
fields are only INPUT if NSPYENTL GE 170.
Thanks to Mark Bailey, HM Land Registry, ENGLAND.
Change 18.231 Support for Landmarks The Monitor for DBCTL creates four
ADOCTMDC new datasets from the 'CN', 'CT', and 'CX' records.
EXTMDCCN These new datasets are created:
EXTMDCCV dddddd DATASET Description
EXTMDCCT TMDCCN TMDCCN Interval Statistics from CN record.
EXTMDCCX TMDCCV TMDCCV VSAM Intervals from CN record
IHDRTMDC TMDCCT TMDCCT PSB/Thread Detail from CT record.
IMACTMDC TMDCCX TMDCCX Exception record
TYPETMDC See member ADOCTMDC for notes on some data values.
TYPSTMDC These TMON records can be dumped in compressed format,
VMACTMDC and MXG member EXITMON6 is the code and instructions to
VMXGINIT install the TMON INFILE exit so MXG will read compressed
EXITMON6 TMON records directly; comments and examples in EXITMON6
Sep 19, 2000 were revised and updated for all TMON products.
Thanks to ???, ???, EUROPE
Thanks to Daniel Strgarsek, SAS EMEA, GERMANY.
Change 18.230 Cosmetic. The LABEL for variables PGPEXCP and PGPIOTM
VMAC7072 are now *BY THIS*PERFGRP/SRVCLASS instead of the old
Sep 19, 2000 PERF GROUP PERIOD. These variables exist in both TYPE72
and TYPE72GO datasets, so their contents were clarified.
Thanks to Joe Martin, Amdahl, USA.
Change 18.229 Support for Omegamon for VTAM V500 (COMPAT) adds new
EXOMVTCA TCP/IP measurements in four new MXG datasets:
EXOMVTCB dddddd Dataset Description
EXOMVTCC OMVTCP OMVTTCP TCP/IP Address Space
EXOMVTCP OMVTCA OMVTTCPA TCP/IP Application
IMACOMVT OMVTCB OMVTTCPB TCP/IP Buffer Pool
VMACOMVT OMVTCC OMVTTCPC TCP/IP Connection
VMXGINIT Only the first three datasets have been tested with data.
Sep 19, 2000
Thanks to Eric Barnes, Prudential, ENGLAND.
Thanks to Norman Hollander, Candle, USA.
Thanks to Dave Crandall, Farmers Insurance, USA.
Change 18.228 Add logic to MXGCPU report for number ICF's and CP's
ANALRMFR within the Partition data report.
Sep 18, 2000 Error PDB not assigned, when parameters are PDB=SMF,
REPORT=IOQU, and PDBOUT=PDBO was corrected.
Change _STY78 to _STY78CF;
Add _STY78CU; _STY78IO;
Error Physical file does not exist. When parameters are
PDB=SMF,REPORT=WKLD,PDBOUT=PDBO,RPTOPT=PERIOD corrected.
Change all _N72 to _N7072.
Change all VMAC72 to VMAC7072.
Change all _CDE72 to _CDE7072.
Change all _VAR72 to _VAR7072.
Change 18.227 Support for EDA, Enterprise Data Access, SMF user record.
EXEDALOF Two datasets are created from the four subtypes:
EXEDALON dddddd Dataset Subtype Description
FORMATS EDALON EDALOGON 1,4 EDA LOGON OR BEGIN QUERY
IMACEDA EDALOF EDALOGOF 2,5 EDA LOGOFF OR END QUERY
TYPEEDA The EDALOGON dataset seems useless, since it has only the
TYPSEDA SMFTIME of the start, which becomes MXG variable EDASTIME
VMACEDA in the EDALOGOF dataset. Sorted by EDASTIME, EDALOGOF
VMXGINIT has the 2:LOGOFF event record first, which has the total
Sep 18, 2000 CPU Time and EXCP count, and then each of the individual
5:END QUERY event records follow that LOGOFF record. The
CPU time in the 5:END QUERY records is already contained
in the 2:LOGOFF even record.
Thanks to Glen Yee, California Health & Human Services, USA.
Change 18.226 Variable JOB was blank if QMDACORR was blank, for DB2
VMACDB2 attachment QWHCATYP IN (1,2,0Bx) (TSO, CALL ATTACH, and
Sep 15, 2000 UTILITY JOBS). For those QWHCATYP values, MXG now tests
IF QMDACORR GT ' ' THEN JOB=QMDACORR;
so JOB won't be overwritten if QMDACORR is blank.
Thanks to Diane Parker, Bergen Brunswig, USA.
Thanks to Warren E. Waid, JC Penny, USA.
Change 18.225 Change 17.303 was wrong. The DBORG='00'x segment does
VMACCIMS not contain SQL information, and should not have been
Sep 15, 2000 output to CIMSDB2. That segment (with DBDNAME='ALLDBS')
is the I/O activity for DLI buffers during Syncpoint
processing and is now output back into CIMSDBDS (as it
was before Change 17.303), and its I/O counts are summed
into the CIMSTRAN observation for that transaction. It
is called IOWAITS because only IOWAITS code generates
statistics during this processing.
Thanks to Thomas Heitlinger, FIDUCIA IT AG, GERMANY.
Change 18.224 The DCOLLECT _Sdddddd and _Sxxxx SORT macros are updated
VMACDCOL as PROC SORT NODUP and the _Bdddddd BY list will remove
Sep 12, 2000 duplicate observations in the input DCOLLECT data.
Change 18.223 MXG 18.02-18.07 GOAL MODE only. Report 2 printed too
UTILRMFI much because test for RPRTCLAS=Y should have been='Y',
Sep 12, 2000 and reports were revised to use PDB.SMFINTRV/PDB.STEPS
or TYPE30_V/TYPE30_V instead of interval and Job Term,
and the comments were clarified.
Thanks to Bob Falla, The Mutual Group, CANADA.
Change 18.222 Support for AS/400 Collection Services records, which is
EXQAPCON a separate product, different from the AS/400 Performance
EXQAPDIS Monitor that is still available (free) and supported by
EXQAPJOB MXG's TYPEQAPM code. This new product captures only a
EXQAPPOO small subset of the data in the Performance Monitor.
IMACQACS This new TYPEQACS support creates these datasets:
TYPEQACS DDDDDD INFILE/DATASET Description LRECL
TYPSQACS QAPCON QACSCONF CS Configuration data 16
VMACQACS QAPDIS QACSDISK CS Disk Storage data 352
VMXGINIT QAPJOB QACSJOBS CS Job data 544
Sep 14, 2000 QAPPOO QACSPOOL CS Main Storage data 78
Aug 21, 2008 (QACSYS/QACSYSM/EXQCSSYS reference/member removed 2008.)
The AS/400 CS data is completely dependent on the correct
LRECL having been specified when the data was uploaded
to MVS, or in the FILENAME statement on ASCII systems.
Member VMACQACS documents the correct LRECL sizes.
Thanks to Joe Faska, Depository Trust, USA.
Thanks to Colin Bowen, CSC, SOUTH AFRICA.
Thanks to Stuard R. Burnett, Reynolds Metal Company, USA.
Change 18.221 Cosmetic. A single byte value, 10995116167810048 was
FORMATS skipped in the MGBYTES format and would not have been
Sep 12, 2000 formatted; the range for TB was increased to include.
Thanks to Danny Ball, CNF, USA.
Change 18.220 SAS V8.0 (TSM0 and TSM1), but not SAS V8.1. SAS/GRAPH
DOC "missing values" warning message in SAS V6 became a real
Sep 9, 2000 _ERROR_ condition in SAS V8.0, causing either CC=12, or a
USER 999 ABEND (because MXG sets option ERRORABEND so
that any true error causes an ABEND instead of just a
condition code), if any graph has missing values for one
variable! This has been corrected in SAS V8.1; only a
WARNING message is printed on the log, as it should have
been. If you are still at SAS V8.0, you can specify
OPTIONS NOERRORABEND; for the steps that use SAS/GRAPH,
and the USER 999 will be avoided, although the condition
code will still be non-zero.
Thanks to Caron Knox, Willis Group Services, ENGLAND.
Change 18.219 ERROR: CHARACTER VARIABLE QW0140TX HAS TOO LONG A VALUE
VMAC102 THE SASEB ENGINE when you execute BUILDPDB or TYPE102
Sep 8, 2000 under SAS V8, but point your output to a pre-existing
V6-built SAS data library (i.e., your "PDB"). You should
build V8-format data libraries when executing under V8;
you must allocate new physical OS data sets and write to
them: you CANNOT use PROC DELETE to clear a V6 library
and then write to it with V8 to create a V8-built data
library, since the SAS Directory is still V6-built.
See SAS Technical Note 11 in Newsletter THIRTY-SEVEN.
However, if you intentionally must keep your PDB in the
V6-format, executing under SAS V8, you can circumvent
the above error by using %LET SASCHRLN=100; as your
first //SYSIN statement.
Thanks to Caron Knox, Willis Group Services, ENGLAND.
Change 18.218 Report macro failed if PDB=SMF and PDBOUT=PDB was used.
ANAL94 The internal logic was revised so that macro &PDB was not
Sep 7, 2000 reset.
Thanks to Steve Gossage, Cummins Engines, USA.
======Changes thru 18.217 were in MXG 18.07 dated Aug 31, 2000======
Change 18.217 First MXG 18.07 only. First day's tape (dated Aug 30).
BUILDPDB Member BUILDPDB was missing the _S21 invocation, causing
Aug 31, 2000 dataset PDB.TAPES to have not been built.
Thanks to Bruce Widlund, Merrill Consultants, USA.
======Changes thru 18.216 were in MXG 18.07 dated Aug 30, 2000======
Change 18.216 Erroneous "BAD HFS" segment messages were produced from
VMACTCP SMF 118 errors with legitimate data; COL-LENGTH should
Aug 30, 2000 have been LENGTH-COL, and LT LENGTH-1 should have been
LE LENGTH-1.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 18.215 Each INFILE statement was enhanced with END=ENDOFTAN
VMACTAND so that the end of input file is flagged, as this can
Aug 30, 2000 be used to simplify duplicate data checking in ITSV.
Thanks to Peter Christie, IT Performance Consulting, USA.
Change 18.214 INPUT STATEMENT EXCEED RECORD LENGTH for SMF ID=65 record
VMAC6156 because the '04'x Catalog Segment in the Catalog Record
Aug 30, 2000 that is appended to the SMF record without documentation,
now has Low and High Key field lengths of 112 bytes when
previously that field was only 64 bytes long. The IBM
development programmer who "owns" these catalog records
that are output in the type 61, 65, and 66 records has
refused to make their documentation available ("its OCO")
even for this Vendor, so I have to stumble into changes
in field lengths in the data in the field. The logic to
read those varying length fields was revised to protect
for whatever length is now found.
Thanks to John Doan, TotalSystem, USA.
Change 18.213 Support for BMC MainView for MQ Series History File V2.1.
EXBBMQCH Two new subtypes, 'E4' and 'E5' are now supported and new
EXBBMQLM data was added to the existing 'E1' Queue Manager record.
IMACBBMQ DDDDDD Dataset Description
VMACBBMQ BBMQCH BBMQCHAN 'E5' CHANNELS RECORD
VMXGINIT BBMQLM BBMQLMGR 'E4' LOG MANAGER RECORD
Aug 29, 2000 These data sets have been created and sorted, but only
Sep 5, 2000 just examined; the interval DURATION does not exist in
these records, and I can't tell if the values are exact
or whether they are accumulated until I look at more
data, but the datasets and variables look good.
Sep 5: CHLLRTRY and CHLSEQHI are now stored in length 8,
because their default hex value of '3B9AC9FF'x=999999999
became '3B9AC900'x internally when stored in length 4.
Thanks to Martyn Jones, ABN AMRO, THE NETHERLANDS.
Change 18.212 Cosmetic. Spelling in comments of asterisk are now all
DOC the same; variants asteric, asterics, and asterisk were
Aug 29, 2000 corrected in many places. And occurrences of occurance
Sep 5, 2000 and occurence were corrected, too!
Thanks to Bruce Green, MIB, USA.
Change 18.211 This "BUILDPDB" utility now knows about the inconsistent
UTILBLDP spelling of the SMF "MACRO _IDxxxx" in 17 MXG members.
Aug 29, 2000 While most of the SMF ID macro names are _IDxxxx, these
products have non-standard macro names, typically _xxxxID
and they are now properly generated if you request these
products be added to the BUILDPDB code built by UTILBLDP:
ARB, DLM, DMON, HBUF, HURN, IPAC, M204, NSPY, PDSM, RMDS
ROSC, RTE, SYNC, TSOM, VVDS, WYLA, WYLB, X37.
Thanks to Ian Davies, ATCO I-Tek, CANADA.
Change 18.210 Documentation. Support for Netview 1.3 SMF records
VMAC37 type 37, 38, and 39 has been in MXG since before 16.16,
VMAC38 but there was no MXG note to that effect. No changes
VMAC39 were made by this change.
Aug 29, 2000
Thanks to Harald Seifert, HUK-COBURG, GERMANY
Change 18.209 Cosmetic. The "LAST RECORD IN GROUP" message was not
VMACSMF written if the last record was not a subtype 3 record,
Aug 29, 2000 as when reading only part of an SMF file.
Change 18.208 Y2K Error. MainView for CICS Statistics SMF type 110
IMACICBB special subtype 0B02x records cause year 2020 in 2000:
VMAC110 -in the IBM Statistic Header COLLTIME/STARTIME variables,
Aug 28, 2000 because the BMC type 110 subtype 2 record for CICS 4.1
did not update the SMFMNMFL Maintenance Level field.
That field was updated for IBM type 110 subtype 2 by
PN69653, which changed the date format from YY to YYYY.
With the MFL still zero, MXG assumed the old YY format
and generated the wrong dates. As it's too late for
BMC to fix their error, MXG now tests the ORIGSUBT to
recognize 4.1 BMC records with the YYYY date format.
Logic in VMAC110 was enhanced to protect BMC.
-in the unique datetime variable in all CICSBBxx datasets,
the BMC documentation showed binary (PIB) for their new
YYYY,MO,DD dates, but now with data records, those fields
turn out to be unsigned-packed (PK) format, so member
IMACICBB was corrected.
Thanks to Hartmut Peter, R+V Allgemeine Versicherung AG, GERMANY.
Change 18.207 Documentation for MXG Support for BMC MainView products.
DOC Member Infile Product/Description
Aug 28, 2000 ASMMNVW n/a INFILE Exit for Compressed BMC data
TYPEBBMQ BBMQVSAM MainView for MQ
TYPECMFV CMFVSAM MainView for OS/390, MMR, CMF-VSAM.
TYPECMF SMF MV for OS/390, CMF User SMF record.
TYPECIMS IMSLOG MainView for IMS
TYPEMVCI CMRDETL MainView for CICS CMRDETL/CMRFILE.
IMACICBB SMF MV for CICS Type 110-2 Stat records.
TYPEDB2 SMF MainView for DB2 (no unique records).
Change 18.206 Three TMON V2 Segments did not have the offset variable
VMACTMO2 in their INPUT statement, causing misalignment. The
Aug 27, 2000 offset variables that were added to their INPUT:
TRDSAOFF,TREXPOFF, and TRXMCOFF, for datasets MONIDSA,
MONIEXP, and MONIXMC.
Thanks to Alex Benny Nielsen, TeleDanmark IT, DENMARK.
Change 18.205A The xxxxCMFV members were named for "CMF-VSAM", because
VMACCMFV member xxxxCMF already existed (for the CMF user SMF
Aug 27, 2000 record), and the records came with the BMC CMF product.
Change 18.205 However, the records that xxxxCMFV processes are actually
created by the MMR component of the "New CMF" product,
but as the records are common to both the "CMF" and the
"MMR" products, they exist even if you have only "MMR"
(for example, if you use RMF instead of the "old CMF"
part of the "New CMF" product).
Five datetime variables in ZNTS format are now decoded
(PIB6.2 seconds since 1JAN1980, IB2. minutes GMT offset,
and add 63115200 seconds for the 1960-1980 delta).
The corrected variables are
SYREXTDI SYREXPTI GLSTDAY1 GLSTDAY2 RWREDATE
Thanks to Bill Blair, BMC, USA.
Change 18.204 Major rewrite of ASUMUOW to add variables, make it
ADOCUOW simpler for you to add or delete variables, add the
ASUMUOW possibility of MQ series data, and allow you to break
JCLUOWV the processing of DB2 and CICS data into separate jobs
VMXGUOW to increase parallelism and decrease run times.
Aug 26, 2000
Sep 25, 2000 In larger installations, the processing of CICS and DB2
data can be extremely time and resource consuming. In a
large shop, over 120 million CICS transactions/day are
processed and over 3 million DB2 accounting records in
3 separate runs per day. Each of these creates 5-6
3490 volumes of CICS transaction data and 1-2 of DB2
data. The total processing time often exceeds 18 hours
per day. In the event of an ABEND, recovery time is
very painful.
Consider the flow of the processing. TYPE110 reads the
SMF data and creates the CICSTRAN dataset. This must
be sorted and then read by ASUMUOW. That means that 5-6
cartridges of data are read and written by TYPE110, read
and written by SORT, and read by ASUMUOW. If we assume
6 cartridges for each, then there are 5 full passes of
the data (a total of 30 cartridges!)
Now revise the flow so that a VIEW is used to pass the
data directly from TYPE110 into the SORT. Two full
passes of the data (writing it from TYPE110 and reading
it in the SORT) are eliminated. At 10 minutes per tape
this adds up to about 2 hours of processing time in each
of the three cycles of CICS data per day!
Member JCLSUOW is a set of JCL containing three jobs.
Job TYPE110V executes TYPE110 to read only the CICS
transaction data and sort it into the correct sequence
for ASUMUOW keeping only those variables needed by
ASUMUOW. TYPEDB2V process all of the DB2 data and uses
a VIEW to pass the DB2ACCT data into the SORT for
ASUMUOW. All other DB2 data uses the normal sorts and
processing for DB2. ASUMUOWV uses the output of the
first two jobs as input to ASUMUOW.
ASUMUOW now contains some substitution style macros
for keeping lists of variables and datasets and uses a
new macro VMXGUOW to dynamically build the code to
perform the summarization so that adding and deleting
variables is much simpler (you don't have to invent new
variables names for all of the counters!)
Substitution MACROS in ASUMUOW:
_LASSPIN - SPIN.SPINUOW - OUTPUT SPIN DATASET
_PRESPIN - SPIN.SPINUOW - INPUT SPIN DATASET
_TMPSPIN - TEMPSPIN - INTERMEDIATE SPIN DATASET
_SUUOW - &PSUUOW..ASUMUOW - FINAL OUTPUT
_WSUUOW - NOT USED
_KSUUOW - NOT USED
_BSUUOW - NETSNAME UOWTIME UOWIDCHR - SORT ORDER
_SSUUOW NOT USED
_NOBS - %%VMXGOPTR(OPTNAME=OBS,NEWVALUE=0);RUN;
Controls number of observations
Must be overridden in member IMACUOW
(by completing comment statements)
to create observations in PDB.ASUMUOW.
_YESOBS - %%VMXGOPTR(OPTNAME=OBS,NEWVALUE=MAX);RUN;
Resets number of observations
Must be overridden in member IMACUOW
(by completing comment statements)
to create observations in PDB.ASUMUOW.
_TRANUOW logic to determine which transaction name
is the real transaction name
_SPINUOW - 7 How many spins
_LASCICS &TEMP01..TEMPCICS - intermediate CICSTRAN
_LASDB2A &TEMO02..TEMPDB2A - intermediate DB2ACCT
_LASMQ WORK.TEMPMQM - intermediate MQMACCT
_INMQ _NULL_ - input MQMACCT dataset
_KUOWCIC list of variables to be kept and accumulated
from CICSTRAN
_KUOWDB2 list of variables to be kept and accumulated
from DB2ACCT
_KUOWMQ list of variables to be kept and accumulated
from MQMACCT
_SUOWCIC the sort of the CICSTRAN dataset
_SUOWDB2 the sort of the DB2ACCT dataset
_SUOWMQ the sort of the MQMACCT dataset
_SUOSPN building of the intermediate SPIN dataset
VMXGUOW parameters:
INCODE= A stub of code executed
during INPUT processing
INCICS= A stub of code executed
when a CICS record is found
INDB2 = A stub of code executed
when a DB2 record is found
INMQ = A stub of code executed
when an MQ record is found
INSPIN= A stub of code executed
when a SPIN record is found
OUTCODE= A stub of code executed
during OUTPUT processing
Currently calculates
CLASS3 DB2 times and counts
and SQL counts
CICSVARS=_KUOWCIC variables kept and counted
for CICS
DB2VARS=_KUOWDB2 variables kept and counted
for DB2
MQVARS=_KUOWMQ variables kept and counted
for MQ Series
If all you do with ASUMUOW is a %INCLUDE, you will
not need to make any changes.
Thanks to Chuck Hopf, MBNA, USA.
Change 18.203 RMF Paging Activity Report: corrected values for LPA and
ANALRMFR CSA columns named NON SWAP BLOCK and NON SWAP NON BLOCK.
Aug 25, 2000
Change 18.202 Some DB2 statistics variables, new in DB2 6.1, were input
VMACDB2 but were not deaccumulated, so their values were wrong.
Aug 25, 2000 This change does not affect the DB2ACCT dataset, which
Sep 5, 2000 contains interval values (i.e., valid); it is only the
statistics records that have accumulated values that must
be deaccumulated in MXG logic.
-Group Buffer Pool variables in DB2GBPST/DB2STATS/DB2STAT1
datasets were not deaccumulated:
QBGLAX QBGLAY QBGLAZ QBGLCC QBGLCK QBGLCS
QBGLDG QBGLDN QBGLRB QBGLRD QBGLRG QBGLUN
Don found this error because he knew that QBGLUN must
be lots less than QBGLRC. I had INPUT and KEEPt them but
failed to update the _SDB2PST and _SDB2ST1 macros that do
the deaccumulation. This cause me to examine the other
variables added to the statistics records, and I found:
-QXxxxxx variables in dataset DB2STATS/DB2STAT1 dataset
were only INPUT, and were neither kept nor deaccumulated:
QXALPRO QXALUDF QXCASCDP QXCAUD QXCAUDAB QXCAUDRJ
QXCAUDTO QXCRATB QXROIIDX QXROIMAT QXROITS QXROWTRG
QXSTLOBV QXSTTRG QXTRGERR
-Sep 5: Variables QBGBGR1 and QBGBGR2 were moved from the
$HEX8. to $HEX12. format list; they are 6 bytes long but
with the shorter $HEX8. format, they appeared to be blank
when the first four characters were blank or nulls.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 18.201 The four variables that measure bytes are now formatted
VMACTCP with MGBYTES so the values will be more readable in the
Aug 24, 2000 units of /KB /MB /GBytes. The four variables are:
APIBYTIN APIBYTOU FTPBYTEC TELINBYT TELOUBYT
Thanks to Chuck Hopf, MBNA, USA.
Change 18.200 The Workload name printed only the first two characters.
UTILRMFI A LENGTH WORK $8; statement had to be inserted after
Aug 25, 2000 each of the INCODE= arguments.
Thanks to David Ehresman, University of Louisville, USA.
Change 18.199 The High Impact (Low UIC), Medium Impact (Medium UIC),
VMAC71 Low Impact (High UIC), and Available Impact frame count
Aug 25, 2000 fields for CStore and for EStore were added to TYPE71 by
Sep 5, 2000 OS/390 R2.4, but only now, as a result of Peter's looking
Sep 12, 2000 at real numbers after seeing a presentation by Martin
(who had them added to type 71), and with free advice
from Don Deese (who first documented their cousins in RMF
type 99), MXG now correctly decodes those twenty-four
memory measurements into these variables:
HI mn/mx/av HI mn/mx/av
CSFR ME mn/mx/av ESFR ME mn/mx/av
LO mn/mx/av LO mn/mx/av
AV mn/mx/av AV mn/mx/av
The field values are accumulated between adjacent values;
it is necessary to subtract MED from HI to get HI values,
LOW from MED to get MED, and AVAIL from LOW to get the
LOW values. Because the MED memory is quite small with
the current IBM-set UIC buckets, its average value was
often a small negative value; in those cases, the MED are
set to missing, and HI-LO is used for HI values. Fields
are in frames, but as the variables were never correct, I
converted all CSFR/ESFR variables to bytes, formatted
them with MGBYTES, and re-labeled them as IMPACT MEMORY.
Martin's paper precipitated creation of additional memory
measures, based on average values that are now created in
MXG's TYPE71 dataset:
CSFRSRAV "SRM-BUFFER" in CSTORE
ESFRSRAV "SRM-BUFFER" in ESTORE
The frames needed to support the Available
Frame Queue, calculated by subtracting the
new free size from the old free size.
CSFRWLAV "Free as Seen by WLM" in CSTORE
ESFRWLAV "Free as Seen by WLM" in ESTORE
The free memory as seen by WLM, calculated
by removing the SRM-Buffer value from the
CSFRAVAV/ESFRAVAV values.
But the "Impact" memory includes only the UIC-updated
pages. WLM updates UICs in Expanded, but not DREF nor
hiperspaces, (but hiperspace size is in TYPE71). Also,
fixed frames and nucleus frames are not UIC-updated (but
they also are in TYPE71). Since the installed CSTORE and
ESTORE memory is known, the missing piece of memory is
all of the memory owned by all of your logically swapped
ASIDs plus any storage isolated pages!
With this change and these new variables, the CSTORE and
ESTORE memory is mapped by these MXG variables:
Online memory CSTORE ESTORE
Logically Swapped CSFRLSAV ESFRLSAV
Fixed CS, Hiper ES CSFRFXAV ESFRHSAV
WLM-viewed Free Memory CSFRWLAV ESFRWLAV
SRM-Buffer Memory CSFRSRAV ESFRSRAV
Low-Impact High-UIC Memory CSFRLOAV ESFRLOAV
Med-Impact Med-UIC Memory CSFRMEAV ESFRMEAV
Hi-Impact Low-UIC Memory CSFRHIAV ESFRHIAV
Because we are adding averages to averages, the measures
are not perfect, and small negative values can still show
up for the MN and MX values, but this provides a complete
picture of how your CSTORE and ESTORE are being used.
Sep 5: The calculation of CSFRFXAV was corrected to use
FIXEDAV instead of PRVFXAV for the fixed memory.
These new CSFRxxxx measures above were compared with the
existing CSTORE72 and ESTORE72 variables in RMFINTRV and
TYPE72/TYPE72GO datasets; those type 72 measurements are
based on resident frame time, and are more accurate than
the averages of averages, in my opinion, and they also
provide memory usage by SRVCLASS/PERFGRP so you can tell
which tasks are occupying how much of your memory.
Sep 12: CSTORE and ESTORE creation was moved up in the
code so that CSFRLSAV and ESFRLSAV are not missing.
Thanks to Martin Packer, IBM, EUROPE
Thanks to Peter Webber, CIS, UK.
Thanks to Tony P. Steward, Post Office, UK.
Change 18.198 TYPE103 variable BYREADCA could have negative values and
VMAC103 contained only the bytes portion of Bytes Read From Cache
Aug 23, 2000 while variable KBREADCA contained only the bytes from the
KiloByte part of the total. Now that IBM revised their
field descriptions, I can correctly sum the KB*1024 plus
the Bytes, and that value is stored in both variables;
both contain bytes and are formatted with MGBYTES format,
and now both describe total bytes read from cache.
An eight byte binary field would have been better!
Thanks to Rex Elbert, SPRINT, USA.
Change 18.197 Support for APAR II11493 changes to SMF type 50 VTAM
FORMATS Statistics record (INCOMPAT) adds new subtype 03 and
VMAC50 restructures that record different from other subtypes.
Aug 22, 2000 The new record provides statistics for TCP connections.
Thanks to Mark Rosen, Office Depot, USA.
Change 18.196 Support for APAR PN61399 (corrects TELNET SMF LOGF record
VMACTCP 'SAVF' in error instead of 'LOGF') adds 'SAVF' to the
Aug 21, 2000 commands that MXG recognizes as TELNET SERVER record, so
even if you don't have the APAR installed, MXG protects.
Change 18.195 Cosmetic. Comments in EXPDBSTP containing the old macro
EXPDBSTP names (prior to MXG 16.04 changes) were revised to show
Aug 16, 2000 the current macro name, _LDBSTEP, in the example.
Thanks to Patrick Julien, France Telecom, FRANCE.
Change 18.194 Error: INVALID DATA FOR GDESIS because the input should
VMACQAPM have &PD.3. instead of &PD.4., but this field indicates
Aug 16, 2000 the data is from Collection Services and not QAPM.
Thanks to Joe Faska, Depository Trust, USA.
Change 18.193 Support for new NTSMF object "SESSION", previously named
VMACNTSM "TERMINAL SERVICES SESSION and with seven new fields:
Aug 16, 2000 ELAPSTM PID PRTYBASE TOTPROHI TOTPROHR TOTPRORE
UNKNCTR1
and removes two:
TOTRANER TOTAL*TRANSPORT*ERRORS
OUTRANER OUTPUT*TRANSPORT*ERRORS
INTRANER INPUT*TRANSPORT*ERRORS
and one unnamed counter is thought to be HANDLES, so the
new record has a total of 80 data fields. It is still
output to the TERMSESS dataset.
Thanks to Luc Gariepy, Regie des Rentes du Quebec, CANADA.
Change 18.192 MXG 18.05-18.06 only INPUT STATEMENT EXCEEDED RECORD. The
VMAC16 +6 before ICEOTBKF should have been +2.
Aug 16, 2000
Thanks to Shabida Khan, Royal Bank, CANADA.
Change 18.191 PSBNAME, added by Change 18.083A was blank because it was
VMACCIMS inserted in the wrong KEEP= list. It should have been
Aug 16, 2000 immediately before _KIMFTRX instead of _KIMFPGM so it
is kept in CIMSTEMP instead of CIMSPROG.
Thanks to Tammy Wellstood, Clarica, USA.
Change 18.190 Year 2000 support for BMC CICS Manager data segments in
IMACICBB type 110 records was incorrect, causing year to be 2020
Aug 15, 2000 instead of 2000. Change 15.179 had never been
tested with Y2K data, and its change was incorrect for
each of its six datetime variables.
Thanks to ???, ???, EUROPE.
Change 18.189 If you had the same name for both a Service Class and a
TRND72GO Reporting Class, TRND72GO lumped them together. Adding
Aug 12, 2000 variable RPRTCLAS at the end of the SUMBY= now separates.
Thanks to Mike Schwencer, Banner Health, USA.
Change 18.188 CICS type 110 Journal (Subtype 0) with GLRHTYPE=2 caused
VMAC110 an INPUT STATEMENT EXCEEDED RECORD error. The statement
Aug 11, 2000 IF CLUPRLE GT 0 THEN INPUT +CLUPRLE @; should not have
been there, and has been deleted (those bytes are read by
the included exit member and the double read were wrong).
Thanks to Shoab Kamran, U.S. Postal Service, USA.
Change 18.187 Support for APAR OW43854 adds new fields to SMF type 62
VMAC62 VSAM OPEN and especially to the SMF type 64 VSAM CLOSE
VMAC64 record, finally adding the OPENTIME of the VSAM file, so
Aug 9, 2000 it is no longer necessary to merge 62 and 64 just to get
the OPENTM duration of a VSAM file! New ACB bits are
also decoded; these variables are added to TYPE64:
ACBMACR4='ACBMACRF*BYTE*FOUR'
OPENTIME='DATETIMESTAMP*WHEN THIS*FILE WAS*OPENED'
OPENTM ='DURATION*THIS FILE*WAS OPEN'
SMF64FG1='MISCELLANEOUS*FLAG*ONE'
SMF64RSC='SMB*INFORMATION'
SMF64SMB='SMB*ACCESS*BIAS*INFORMATION'
ACBBWO ='ELIGIBLE*FOR BACKUP*WHILE*OPEN?'
ACBCCT ='CONTROL*CHARACTER*TYPE?'
ACBJES ='OUTPUT*AND*JES*?'
ACBNLEX ='NO LSR*EXCLUSIVE*CONTROL?'
ACBRLS ='RLS*PROCESSING?'
ACBSNP ='SNP*OPTION?'
-TYPE62 was also enhanced: the OPENTIME variable was added
and all four ACBMACRx bytes were added, so all of the MXG
ACBxxxxx variables in TYPE64 now also exist in TYPE62.
-The new data fields were added compatibly, using either
previously reserved fields or added at the end.
Dec 2005 note: APARs OW45393 and OA03866 reference the
"new" OPENTIME field, but they were already supported and
no additional code changes were needed for those APARs.
Change 18.186 An extra observation in PDB.STEPS can result if a step
BUILD005 with multiple TYPE30_4 records (MULTIDD='Y') has some of
BUIL3005 the records in today's SMF file and the rest are at the
Aug 9, 2000 start of tomorrow's SMF file, i.e., when MULTIDD='Y' step
records are "spun" today and re-introduced tomorrow.
Fortunately, that extra observation has zeroes in all of
the resource variables, so there is no real impact, but
it should not have been created, and is confusing, with
STEP=0, MULTIDD=' ' instead of MULTIDD='Y', and SYSTEM is
blank. The spun MULTIDD records (SPIN30_4) are combined
with today's new MULTIDD records (TYPE30_4) into GOOD30_4
which is then sorted for its SET with GOOD30_5 to create
STEP number, but that sort of GOOD30_4, did not ensure
that the real MULTIDD=' ' step record was always first.
If any spun records with MULTIDD='Y' were physically
before the real MULTIDD=' ' step record, they created the
extra STEP=0 observation!
The original BY list of READTIME JOB JESNR SORTTIME (with
SORTTIME=INITTIME of the step) was expanded to now be by
READTIME JOB JESNR SORTTIME MULTIDD DESCENDING EXTRADD
as this forces the real step record to be first, and also
sequences the MULTIDD='Y' in the order they were written,
by that addition of DESCENDING EXTRADD to the BY list.
Variable RDRTM was removed for the TYPE30_4 keep list, as
it exists only in the TYPE30_1 and TYPE30_5 datasets.
Thanks to Mat Elbersen, Rabobank, THE NETHERLANDS.
Change 18.185 NETVIEW SMF 39 record with invalid ROUTE segment caused
VMAC39 INPUT STATEMENT EXCEEDED RECORD LENGTH. The record looks
Aug 9, 2000 like it was overlaid starting in the SCS section with the
LSESCOSA filed, thru the APPN and ROUTE segments. MXG
added test to INPUT only if there is enough data left in
the record, while investigating the cause of the record.
Thanks to Bruno Peeters, Dexia Bank, BELGIUM.
Change 18.184 Datasets TYPE7 and TYPE23 are now automatically created
BUIL3001 in your PDB library by BUILDPDB/BUILDPD3 programs. The
BUIL3606 PDB.TYPE7 dataset will have observations only if there
BUILD001 was a loss of SMF records. The PDB.TYPE23 dataset has
BUILD002 one observation per SMF interval with the activity to the
BUILD606 SMF datasets, and is useful in tracking down the cause of
BUILDPDB any TYPE7 SMF Data Lost events. Both are very small.
BUILDPD3 Note: if you tailored BUILDPDB to add either of these two
Aug 9, 2000 datasets, you must back out your tailoring in the members
EXPDBINC, EXPDBVAR, EXPDBCDE, and EXPDBOUT.
Change 18.183 The EREP Symptom Record was output to EREPSIM instead of
VMACEREP to EREPSYM; the _EERPSIM in line 2680 should have been
Aug 9, 2000 _EERPSYM.
Thanks to Peter Webber, CIS, ENGLAND.
Change 18.182 VMXGSUM enhancements - 4 major changes:
VMXGSUM -Small differences in results could be seen if INHERIT is
VMXGENG used with V8 to set the lengths of variables and bypass
VMXGINIT the second data step. VMXGSUM was modified to only use
Aug 9, 2000 the inherit option when the data step can be bypassed
Aug 26, 2000 (when no OUTCODE= or NORMx= operands are specified.)
-If TEMP01 or TEMP02 was used and they were sequential
format datasets, the MXGSUM1 and MXGSUM2 datasets were
left in place. Since this can cause subsequent uses
of VMXGSUM to run longer and a PROC DATASETS will fail
on a sequential format dataset, macro %VMXGENG now exists
to detect the ENGINE for a LIBNAME and to set the global
macro variable &MXGENG to contain the ENGINE name, so
that either a PROC DATASETS or LIBNAME DDNAME CLEAR;
LIBNAME DDNAME ENGINE; will be done to appropriately
reset the work files.
-If KEEPALL=YES is used, more WORK space may be required
because there was no KEEP= list on the MXGSUM1 dataset.
So now a KEEP= list (the UNION of all parameters sorted
with duplicates removed) is created, and this is a better
than KEEPALL=NO or KEEPIN=xxxx since it avoids all of the
resources needed to determine what variables exist.
-Significant savings can be had by avoiding the physical
I/O involved in the first data step. This is now done by
using a VIEW on MXGSUM1, but since a VIEW will not work
on a sequential format SAS dataset, the new logic detects
that a sequential engine is being used and instead uses
a data step within the INCODE instead of a VIEW.
In a test of ASUMDB2A with 1743212 OBS in input DB2ACCT
dataset the following results were attained:
CPU EXCP WORK TRACKS
Current 16.75 minutes 124805 117630
New 11.82 100178 59442
-The new %VMXGENG macro can be used to detect the engine
for a LIBNAME/DDNAME, using this syntax:
%VMXGENG(DDNAME=xxxxxxxx);
The name of the SAS engine is returned in the global
macro variable &MXGENG.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Thanks to Chuck Hopf, MBNA, USA.
Change 18.181 Variable CLASS3WT was incorrect in ASUMUOW if there was
ASUMUOW any WAIT FOR IO UNDER DIFF THREAD, variable QWACARNW.
Aug 9, 2000 The count rather than duration variable was in the SUM.
Thanks to Chuck Hopf, MBNA, USA.
Change 18.180 Variable DEVTYPE now supports TRTCH values of E8x,E9x for
VMACTMS5 3590 and 3590E devices, although you must manually update
Aug 8, 2000 the TRTCH value in TMS.
Thanks to Renzo Serena, ENEL, ITALY.
Change 18.179 Variable QLACMDWT, elapsed time waiting because the max
VMACDB2 number of DBATS has been exceeded, is now input and kept
Aug 8, 2000 in DB2ACCT dataset.
Thanks to Phil Downes, ABN AMRO Bank, THE NETHERLANDS.
Change 18.178 DB2 Version 6.1 only, IFCID 106. The end of comment was
VMAC102 missing in line 11081.
Aug 4, 2000
Thanks to Harald Seifert, HUK Coburg, GERMANY.
======Changes thru 18.177 were in MXG 18.06 dated Jul 28, 2000======
Change 18.177 Report example that uses ANALCNCR and PROC TABULATE and
ANALHTML produces reports in HTML format using ODS.
Jul 28, 2000
Thanks to Chuck Hopf, MBNA, USA.
Change 18.176 Doc only. Support for APAR OW45168's minor changes to
VMAC94 SMF Type 94 were already in place in MXG.
Jul 28, 2000
Change 18.175 MXG 18.05 only. INVALID DATA FOR PHMSDATE because three
VMACIDMS debugging lines were incorrectly left. Delete the three
Jul 28, 2000 lines (1223-1226) starting IF PHMRTYPE=18 THEN ....
Thanks to Wim Desmecht, DOLMEN, BELGIUM.
Change 18.174 Documentation only. Comments in both members still had
ASMIMSL5 LRECL=132 for the IMSSUM,INQUEUE, and OUTQUEUE DD names,
ASMIMSL6 but the correct LRECLs (which are ok in the JCLIMSLx's)
Jul 28, 2000 are 136 for V5 and 144 for V6. If you used our old JCL
with incorrect LRECL value, you got IEC141I 013-20 ABEND.
Thanks to Brian Sanger, Zurich Financial Services, ENGLAND.
Change 18.173 Support for OS/400 Release 4.5.0 (INCOMPAT LRECLs and
VMACQAPM data was inserted in the QAPMETH record). If you don't
Jul 27, 2000 use the QAPMETH record, you can change the LRECLs as
Sep 19, 2000 indicated for QAPMBUS, QAPMJOBS, and QAPMSYS, and the
previous MXG Version will work with 4.5 records.
-QAPMBUS has an undocumented single byte character field
added, changing it's LRECL from 111 to 112. New variable
BUCHAR created, was always 'S' in my sample records.
-QAPMETH had six fields with undocumented length changes.
The suffixes MEXR, MM14, MTR, and MDCN increased from 3
to 6 bytes, and MBRV and MBTR increased from 6 to 8.
The LRECL is now 257 for QAPMETH.
-QAPMJOBS has two undocumented 8-byte fields added at the
end of the record, variables JBUNDOC1/JBUNDOC2. The
LRECL for QAPMJOBS is now 835.
-QAPMSYS has five undocumented 4-byte fields added at the
end of the record, variables; the QAPMSYS LRECL is 3288.
Sep 19, 2000: The undocumented variables are now named,
but I still have no description of their contents:
JOBS: JBEDBC, JBTDBC SYS: SYIFUS, SYIFTE, SYDBC, SYSWC
SYSTEM: SCIFUS SCIFTE SYHFTH SYSDBC SYSSWC
BUS: BUTYPE
Thanks to Stuart R. Burnett, Reynolds Metal Corporation, USA.
Change 18.172 Support for APAR PQ32435 OS/390 IHS WEBSERVER SMF 103
VMAC103 adds variables JOB and ASID to the TYPE1032 dataset.
Jul 27, 2000 The APAR also describes changes in values put into the
"EntityName" and "EntityAddress" fields, and documents
when the interval value is not the expected interval:
- The initial write on startup has an interval of zero.
- The termination write on shutdown or restart has an
interval of the time since last write.
- The initial write on restart has an interval of the
time since the restart termination write.
Change 18.171 MXG's protection logic for TCP SMF 118 records with bad
VMACTCP HFS Filename offsets or lengths was still incomplete and
Jul 27, 2000 permitted INPUT STATEMENT EXCEEDED errors. Logic was
revised and the first two bad records are printed on the
SAS log. This supercedes Change 18.144.
Thanks to Francis Berckman, Astra Zeneca, USA.
Change 18.170 MXG 18.04-18.05 only. Variables ONLINE,CMBINVLD,PARTIAL,
VMAC74 BASE, and VARY were always blank. The five lines setting
TYPE74 those variables blank were not removed after the logic to
Jul 26, 2000 set those variables was moved up thirty lines.
Jul 28, 2000
Thanks to Diane Parker, Bergen Brunswig, USA.
Thanks to Peter Webber, CIS, ENGLAND.
Change 18.169 Variable PERFINDX was incorrect in TRND72GO because the
TRND72GO variables R723CVAL and R723CPCT should have been in the
Jul 26, 2000 ID= list, and not in the SUM= list.
Thanks to Pat Perreca, Bear Stearns & Co., USA.
Change 18.168 Documentation. The SAS option USER=XYZ can be used to
DOCMXG send "//WORK" datasets instead to the "//XYZ" DDname.
Jul 25, 2000 However, for MXG to recognize the USER=option, it needs
Oct 11, 2002 to be set before MXG initialization has executed:
OS/390: put USER=XYZ on the EXEC statement:
//STEPNAME EXEC MXGSAS,OPTIONS='USER=XYZ'
ASCII: put USER=XYZ in the AUTOEXEC.SAS file:
LIBNAME XYZ 'C:\XYZ';
OPTIONS USER=XYZ;
If you must put the USER= option in your //SYSIN stream,
then you must insert a %VMXGINIT; statement after it:
//SYSIN DD *
OPTIONS USER=XYZ;
%VMXGINIT;
which will re-invoke the MXG initialization using your
USER= value (printing a second "WELCOME TO MXG" message).
If the USER= value is put in //SYSIN without the VMXGINIT
MXG will not see your USER= option. If you have USER= on
the // EXEC, and you also have USER= and VMXGINIT in your
//SYSIN, the USER= in SYSIN will be used because of the
second MXG initialization.
Putting USER= on the //EXEC statement is preferred, as it
does not require the extra cost of the second VMXGINIT.
An alternative for re-directing datasets in the //SYSIN
is to use the %LET Wdddddd=XYZ; syntax for the "work"
copy of the unsorted dataset (or use %LET Pdddddd=XYZ;
for the sorted, "PDB" copy). The "dddddd" value for each
MXG dataset is documented in the IMACxxxx member for the
product that creates the dataset.
Oct 11: text was revised for clarity.
Thanks to Mike Delaney, Pershing, USA.
Change 18.167 New variables QBGBGR1N and QBGBGR2N are input as numeric
VMACDB2 variables. The original variables QBGBGR1 and QBGBGR2
Jul 25, 2000 were input as characters (because I didn't realize what
they were), and worse, while input as $EBCDIC6, they were
truncated to a kept length of only $4 because they were
in the $HEX8 format item list! Now the character vars
are kept as full length (by moving to $HEX12 format), and
numeric counterparts now exist in DB2GBPAT dataset for
Global Buffer Pools counts of current or pending
directory entries.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 18.166 The new R744Cxxx variables in the TYPE74ST Structure data
VMAC74 set were wrong if there were more than one segment, due
Jul 25, 2000 to a typo: the 26 lines with SUM(R744Caaa,R744Caaa) were
changed to SUM(R744Caaa,R744Xaaa). The
RLS and OSAM structures have 20+ and 60+ segments each,
but DB2 group buffer pools have only one segment so their
counts were always correct.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 18.165 New format MGBYTEN converts bytes to KB/MB/GB/TB/PB like
FORMATS existing format MGBYTES, but MGBYTEN handles negative
Jul 25, 2000 and positive byte values (to track increase/decrease in
DASD memory) so it must be 6 characters wide to have room
for the minus sign, so it had to be a different name than
the 5-character-wide MGBYTES format.
Thanks to Tan York Sin, Singapore Exchange Limited, SINGAPORE.
Change 18.164 Support for Release 321 INCOMPATIBLY changed time stamp
VMACBETA formats for BETABT and BETASTRT. More testing may be
Jul 25, 2000 required if other fields were changed, as only the one
subtype=1 record was received for validation.
Thanks to ???, ???, EUROPE.
Change 18.163 Statement IORATE=0; was removed. The devices with no
ANALCACH cache records needed to have cache-related fields zero,
Jul 25, 2000 but not the IORATE.
Change 18.162 Support for DFSMS/rmm TYPEEDGS/TYPEEDGB was still wrong.
VMACEDGS Zero obs or INPUT STATEMENT EXCEEDED RECORD LENGTH error.
Jul 25, 2000 The "D" and "V" dataset/volume records did change in 1.5
Sep 5, 2000 but the old-format 1.4 records still exist in the catalog
dataset. And the handling of variable length name fields
that worked in 16.16 was somehow lost. In any event, the
change has been tested with TYPEEDGB reading a catalog
with both formats of both records, and works correctly,
using the MD/MVRECLEV variable to identify record format.
There are some 1.4 records that have '40'X in their name
length fields, and have enough record length to contain
a DSN, but they do not contain real DS names; however,
they also do not cause any error.
Sep 5: Variable MVRETDAT was not kept.
Thanks to Richard Fortenberry, Mitsubishi Motor Sales, USA.
Taught classes in Amsterdam and London.
Change 18.161 Y2K support was incorrect, but nobody noticed! Inserted
VMACAXC IF IDTE LT 1900000 THEN IDTE=IDTE+1900000; and changed
Jul 7, 2000 each IDTE,5.),JULIAN5. to IDTE,7.),JULIAN7.
Thanks to Stephen Bell, Informatik Kooperation, GERMANY.
Change 18.160 The %INCLUDE of member IMACKEEP was missing from a number
DOC of MXG TYPExxxx and TYPSxxxx members, which prevented use
Jul 7, 2000 of the new-in-16.04 architecture for instream tailoring.
Most are archaic or not mainstream. Members updated were:
TYPxCRAY TYPxFRYE TYPxHO15 TYPxHPAI TYPxHPCS TYPxHPSU
TYPxHPUX TYPxIMFL TYPxIMS TYPxIMS1 TYPxMWAI TYPxMWSU
TYPxMWTE TYPxMWUX TYPxPW TYPxQTRT TYPxRMF TYPxSAM
TYPxSFS TYPxSNIF TYPxSUPR TYPxTRSN TYPxTUX TYPxVMON
TYPxVMXA TYPxXAM TYPxZARA TYPxZRB TYPEIMSD
Thanks to Bart Decat, KBC Belgium, BELGIUM.
Change 18.159 WARNING: ARGUMENT 3 TO MACRO FUNCTION %SUBSTR IS MISSING
ANALDB2R occurs with SAS Version 8.1, because the length of their
BUIL3001 &SYSVER Version macro was shortened from four to three.
BUIL3005 There is no execution impact, fortunately, except that
BUILD001 the warning now sets a step Condition Code/Return Code of
BUILD005 four instead of zero, and wastes your time in diagnosis!
BUILDPD3
BUILDPDB In Version 8.1, SAS changed the length of their &SYSVER
READDB2 macro from four digits (6.06,6.07,6.08,6.09,8.00) to only
VMXGFOR three digits (8.1), but MXG used %SUBSTR(&SYSVER,1,4):
VMXGINIT to differentiate 6.07 from 6.08, so that options that
VMXGSUM were new in 6.08 would be bypassed under 6.07. While
Jul 6, 2000 the %SUBSTR fails, because the option now exists in
SAS releases, there is no execution error. And the
only purpose was to suppress unneeded SAS messages!
To eliminate this exposure in future SAS Version names,
all MXG references to &SYSVER were revised. Now, all
tests for SAS Version use the MXG-created macro variable
&SASVER, which is set by VMXGINIT from &SYSVER to the SAS
Version number (6, 7, 8, etc.). All of the old 4th-digit
of &SYSVER tests are no longer required:
The tests that set OPTIONS CODEPASS=2 were removed
completely, as that option no longer exists and is no
longer set, and tests around OPTIONS DKROCOND= were
also removed, as that option is now present in all
executable SAS versions.
Thanks to Pat Curren, SuperValu Inc, USA.
Change 18.158 The NTSMF Trending macro variables PTRNTIN and PTRNTLD
VMXGINIT were not defined in VMXGINIT. Three labels in VMACNTSM
VMACNTSM longer than 40 characters, that were not caught by the
Jul 6, 2000 SAS compiler when VMACNTSM ran, but were caught when the
data set was copied.
Thanks to Howard Glasetter, Weyerhaeuser, USA.
Change 18.157 The example REPORT command in the ADOCMWUX member did not
ADOCMWUX create the file that was expected by VMACMWUX, so that
VMACMWUX command was revised to include the new variables that are
Jul 6, 2000 expected. Four variables, TFRSTSEC,TPRMPSEC,TTHNKUSE,
and TPRMPUSE are set missing because I cannot find them
in the current list of MeasureWare fields for HPUX.
Thanks to Roman Gudz, Penske, USA.
Thanks to Bart Decat, KBC Belgium, BELGIUM.
Change 18.156 Variable SMF74CNF was not kept, but not initialized, as
VMAC74 it was INPUT into DEVIND, which was not kept. Now it is.
Jun 30, 2000
Thanks to Freddie Arie, Lone Star Gas, USA.
Change 18.155 MXG 18.05 only. Variables S42DSMXR,S42DSMXS were never
VMAC42 input, having been misspelled as DXMXR and DSMXS in the
Jun 30, 2000 INPUT statement.
Thanks to Bruce Widlund, Merrill Consultants, USA.
======Changes thru 18.154 were in MXG 18.05 dated Jul 1, 2000======
Change 18.154 ANAL4GB member reports on VSAM files approaching 4GB in
ANAL4GB size, but included Extended VSAM files, which show over
Jun 30, 2000 100% utilized space, so IF SMF64EF='Y' THEN DELETE; was
added so those datasets will not be reported.
Thanks to Alfred Holz, Merck & Co., USA.
Change 18.153 Corrections found during QA runs.
VMAC108 -VMAC108. The KEEP list for TYPE108T and TYPE108P did not
VMAC74 keep the variables DOMSPN and DOMSYN, and DOMDBNAM should
WEEKBLD not have been in _BTY108T.
WEEKBLDT -VMAC74. Two variables R745DCID; the "Real CU ID" variable
MONTHBLD was changed to R745DCIR.
VMACEDGS -WEEKBLD/WEEKBLDT/MONTHBLD. The Sort Order for TYPE72SC
VMACMIM was revised to match the VMAC7072 definition, and is now
VMACTMV2 SYSPLEX SYSTEM STARTIME SRVCLASS
VMACSOLV R723SCSN R723SCSR SMFTIME
VMXGCICI -VMACEDGS. Variable MDPDSN repeated in KEEP and LABEL.
Jun 30, 2000 -VMACMIM. Variable DURATM repeated in KEEP list.
-VMACTMV2. Variable WGMSOSCE repeated in KEEP list.
-VMACSOLV. Variable SOLVFLAG had two formats.
-VMXGCICI. Variable STARTIME repeated in FORMAT.
Thanks to Freddie Arie, Lone Star Gas, USA
Thanks to Bruce Widlund, Merrill Consultants, USA
Change 18.152 New _S110ST and _CICSTAT macros are defined in VMAC110 so
VMAC110 that you can control where the CICS Statistics datasets
Jun 29, 2000 are written. With TYPE110 or BUILDPDB, CICS statistics
Aug 29, 2000 datasets are created in the "WORK" DD; BUILDPDB reads 'em
to create the PDB.CICINTRV summary dataset, but those
individual CICS Statistics datasets are not copied or
sorted; they just die at end of step in the //WORK file.
This enhancement lets you control where they written, if
you want to keep any or all of them.
1. You can write them to the 'CICSSTAT' library, sending
all of the CICS statistics datasets (unsorted) to that
DD as the SMF records are read. You would use this:
after your //SYSIN DD statement:
%LET CICSTAT=CICSSTAT;
_CICSTAT;
The _CICSTAT macro invocation uses the value of the
&CICSTAT macro variable as the destination library for
the &WCICddd and &PCICddd CICS statistics data sets.
If you %LET CICSTAT=PDB; before the _CICSTAT invoke,
CICS stats would be written unsorted to the PDB DD.
2. Alternatively, by default, BUILDPDB builds all CICS
Statistics datasets in the //WORK file, and then reads
them to create the PDB.CICINTRV dataset, but then the
CICS Statistics datasets are left in the //WORK DD,
which is temporary and goes away at step end. You can
thus use the member EXPDBOUT to select/sort any of the
CICS Statistics datasets into your PDB. You can use
individual dataset "_Sdddddd" macros for each dataset
that you want to output, or you can use this new
"_S110ST" macro, which will sort only the Statistics
CICS datasets. (The old _S110 macro can't be
used in EXPDBOUT, because it invokes two _Sdddddd sort
macros, _SCICEXC and _SCICSYS, which were already
invoked by BUILDPDB logic.) Just adding _S110ST in
your EXPDBOUT member will sort all CICS statistics
data to the PDB library. You can also invoke the
_CICSTAT macro in member EXPDBOUT after resetting the
default DD name, can could then sort all of the CICS
statistics datasets into the "MYDD" library, using:
%LET CICSTAT=MYDD;
_CICSTAT;
_S110ST
Note: _S110ST did not exist until MXG 18.07, when the
change was revised.
Thanks to Glenn Bowman, Wakefern, USA.
Change 18.151 INPUT STATEMENT EXCEEDED with NETSPY 5.2 subtype "I" and
VMACNSPY MXG 18.03-18.04. In 5.2, the "I" subtype was for TELNET
Jun 29, 2000 sessions, but NETSPY 5.3 deleted the TELNET data, and
reused subtype "I" record for TCP/IP data. MXG 18.03 now
supports the TCP/IP data, but Change 18.069 did not test
for and delete that now-defunct 5.2 "I" record. The code
test after IF NSPYREC='I' THEN DO; was revised to insert
IF NSPYENTL LE 70 THEN DELETE; since the 5.2 "I" record
segment length was 70.
Thanks to Rita Bertolo, Canadian Pacific Railroad, CANADA.
Change 18.150 Negative values for RANDOM PAGES fields in reports. The
ANALDB2R calculation of variable RANDOMP was incorrectly located,
Jun 29, 2000 and was moved to after MEAN=QB&B.TCBA/NUMINTVL;
Thanks to Gary L. Keers, Indianapolis Power & Light, USA.
Change 18.149 New analysis: Who is filling your active SMF VSAM file?
ANALSMJB This program reads the active VSAM SMF file (or any SMF
Jun 29, 2000 file) and counts how many type 14, 15, 30, 42, and 64 SMF
records in that SMF file were created by each JOB, so
that your operators can use this report to cancel a
runaway job. (The program stops reading SMF records when
it sees a timestamp after the start of this program, so
that SAS does not have to read over all the unused CIs
in your VSAM SMF file).
Change 18.148 Documentation only. Change 17.060 showed example syntax
VMXGINIT of %VMXGINIT(MXGWORK=XYZ); to redirect datasets from the
Jun 29, 2000 //WORK default to the "XYZ" libref, but VMXGINIT changes
(VOPTIONS table, resetting MXGWORK based on SASSWORK and
USERWORK) cause that old syntax to no longer work. If you
should ever need to redirect work, now the correct syntax
is to use OPTIONS USER=XYZ; See also Change 18.168
Thanks to MP Welch, SPRINT, USA.
Change 18.147A-SAS V8 no longer requires the MEMSIZE parameter in the
CONFIGV8 CONFIG member, and in some cases it has caused memory
Jun 29, 2000 ABENDs that were eliminated by removing MEMSIZE, so I
have removed it from CONFIGV8 member. Using REGION=0M
on your JOB card is recommended, but you should be aware
that installation exits IEALIMIT and/or IEFUSI can limit
the virtual storage that be allocated.
-I had to reinstate the S=72 and S2=72 options in CONFIGV8
member. It was removed (Change 17.392) to protect from
potential problems if your SOURCLIB was RECFM=VB, but its
absence caused errors if you had numbered lines in your
MXG Tailoring Library (USERID.SOURCLIB), including 180
syntax ABENDs, and APPARENT MACRO &WORDI UNRESOLVED.
Unnumbering your lines eliminated the error, but so does
putting back the S=72 and S2=72 in the CONFIGV8 member,
and you don't have to touch your numbered lines.
Thanks to John Mattson, Espon, USA.
Change 18.147 The data step previously in the _STYMEMx sort macros were
VMACMEMO replaced with PROC SORT and the _BTYMEMx macros now have
Jun 29, 2000 the correct BY list variables.
Thanks to Fred Kuhstoss, Norfolk Southern Corp, USA.
Change 18.146 Variables S42DSMXR and S42DSMXS were added to TYPE42DS
VMAC42 when they were discovered in the SMF manual.
Jun 29, 2000
Change 18.145 -New TRNDNTLD trends NT DISK Space Utilization using the
BLDNTPDB NTSMF dataset LOGLDISK.
NTINTRV -Hardcode dataset names in BLDNTPDB text were replaced
TRNDNTLD with their _Ldddddd symbolic macro name, and NTINTRV was
VMXGINV changed to use the symbolic, and to %INCLUDE the member
Jun 28, 2000 IMACKEEP so the BLDNTPDB builds a fully compatible code
member that accepts IMACKEEP/MACKEEP= tailoring.
If TRENDing is invoked by BLDNTPDB, both TRNDNTSM and the
new TRNDNTLD are invoked.
Thanks to Greg Jackson, National Life of Vermont, USA.
Thanks to Howard Glasetter, Weyerhaeuser Company, USA.
Change 18.144 Protection for bad length/offset for TCP HFS filename
VMACTCP segments was over slightly in error; some records with
Jun 26, 2000 valid HFS lengths of zero were flagged as in error. The
test for IF 0 LT FTPHFS01 LT LENGTH-1 THEN DO; line 440
and IF 0 LT FTPHFS02 LT LENGTH-1 THEN DO; line 472
were changed IF 0 LT FTPHFS01 LE LENGTH-1 THEN DO; 440
and IF 0 LT FTPHFS02 LE LENGTH-1 THEN DO; 472
so only bad segments with non-zero length are detected.
Thanks to Sal Fazzino, First American, USA.
Change 18.143 -Support for new NTSMF Objects in Windows 2000 Server:
EXNTBENG "dddddd" "dataset" vars description
EXNTDHCP NTBENG BEENGINE 131 BE Engine
EXNTDNS NTDHCP DHCP 14 DHCP Server
EXNTFIRC NTDNS DNS 62 DNS
EXNTFIRS NTFIRC FILREPCO 24 FileReplicaConn
EXNTNTPC NTFIRS FILREPSE 91 FileReplicaSet
EXNTNTPS NTNTPC NNTPCMND 44 NNTP Commands
EXNTNTDS NTNTPS NNTPSERV 40 NNTP Server
EXNTNTSH NTNTDS NTDS 140 NTDS
EXNTWMSS NTNTSH NETSHIEL 40 NetShield
EXNTWMUS NTWMSS WINMEDSS 3 Windows Media Station Service
IMACNTSM NTWMUS WINMEDUS 24 Windows Media Unicast Service
VMACNTSM -And the NTSMF 2.2.2 change that puts back into the SYSTEM
VMXGINIT object the variables PCTCPUTM PCTUSRTM PCTPRVTM that
Jun 27, 2000 Microsoft had previously removed from SYSTEM.
-And the NTCONFIG file was corrected; the CPUSPEDn/FAMILYn
MANUFACn/CPUNUMn fields were RETAINed from each 0,0, but
were not initialized, and so could contain data in the
N+1 fields when the value of NRCPUS was only N.
Thanks to Hansueli Vogt, Credit-Suisse, SWITZERLAND.
Change 18.142 CMA SPOOL record, subtype 6, variable SMFT06PC, added by
VMACCMA Change 18.056, was incorrectly decoded, as a two-byte
Jun 26, 2000 reserved field precedes that field. The DSECT shows a
two byte reserved field after SMFT06PC, but it is not
input (to preserve compatibility).
Thanks to Dr. Alexander Raeder, Karstat AG, GERMANY.
Thanks to Harmuth Beckmann, Karstat AG, GERMANY
Change 18.141 Variable DVGSBCNT, the Transfer Byte Count, has always
VMACFTP been wrong; it should have been input as &PD.8., but it
Jun 26, 2000 was documented as binary instead of packed decimal.
Jul 25, 2000 In addition, variable DVGSCFAC should have been &PIB.1.1
but was previously only &PIB.1.
Thanks to John Sheridan, Aer Lingus, IRELAND.
Thanks to Theo Peelen, RABOBANK, THE NETHERLANDS.
Change 18.140 Variables CIOPCT, HITPCT, and RDHITPCT were not being
ASUM42DS recalculated after the summation; the were revised into
Jun 26, 2000 NORM= operands to be properly recalculated as percents.
Thanks to Raff Rushton, Kaiser Permanente, USA.
Change 18.139 IMS Log Version 5.1 cause zero observations in IMSTRAN
TYPEIMSB in STEP4 of JCLIMSL5, because IF _IMSVERS LE 5 THEN DO;
Jun 22, 2000 should have been IF _IMSVERS LE 5.1 THEN DO; in three
places in member TYPEIMSB.
Thanks to Pete Gain, SAS UK, ENGLAND.
Change 18.138 Additional, optional variables are now decoded from the
IMAC6ESS ESS segment in the type 6 record. Comments in IMAC6ESS
VMAC6 describe how to enable the creation of these variables,
Jun 21, 2000 and how to add them to TYPE6, or to PDB.PRINT. The full
list of TYPE6/PDB.PRINT variables that are decoded from
the ESS/IEFDOKEY optional fields are these:
ADDRESS1='FIRST LINE*OF ADDRESS'
ADDRESS2='SECOND LINE*OF ADDRESS'
ADDRESS3='THIRD LINE*OF ADDRESS'
ADDRESS4='FOURTH LINE*OF ADDRESS'
BUILDING='BUILDING'
DEPT ='DEPARTMENT'
DESTNATN='DESTINATION'
ESSBURST='BURST*IN*ESS'
ESSCHARS='CHARS*IN*ESS'
ESSCLASS='CLASS*IN*ESS'
ESSCOPIE='COPIES*IN*ESS'
ESSFCB ='FCB*IN*ESS'
ESSFMDEF='FORMDEF*IN*ESS'
ESSFORMS='FORMS*IN*ESS'
ESSLINCT='LINECT*IN*ESS'
ESSMODFT='MODIFY TRC*IN*ESS'
ESSMODFY='MODIFY*IN*ESS'
ESSPGDEF='PAGEDEF*IN*ESS'
ESSPRMOD='PRMODE*IN*ESS'
ESSPRTY ='PRTY*IN*ESS'
ESSWRITR='WRITER*NAME*IN ESS'
GROUPID ='GROUP ID'
NAME ='NAME'
ROOM6 ='ROOM6'
TITLE ='TITLE'
Thanks to Todd Wright, CSC, AUSTRALIA.
Change 18.137 Variable CUTSHEET='Y' in dataset TYPE6 and PDB.PRINT was
VMAC6 incorrectly decoded; the wrong bit was tested. It should
Jun 21, 2000 have been IF OPTBIT='..1.....'B THEN vice '.1......'B.
Thanks to Peter Robinson, IGM-GSA, AUSTRALIA.
Change 18.136 The RECTYPE=5 Deleted Data Space Release records were put
VMACICE in ICEBRGDR instead of ICEBRGDE, because the statement in
Jun 21, 2000 the RECTYPE=5 DO group should have been _EICEDEL instead
of _EICEDRV (i.e., the comments were correct).
Thanks to Nick Johns, J. Sainsbury, ENGLAND.
Change 18.135 WEEKBLD and MONTHBLD still had the wrong BY list for the
MONTHBLD TYPE30MU dataset (but WEEKBLDT was correct!). All were
WEEKBLD changed to match variables in the _STY30MU sort macro
Jun 12, 2000 that is used in BUILDPDB:
READTIME JOB JESNR INITTIME SUBTYPE PRODOWNR PRODNAME
PRODQUAL PRODID SMFTIME
Thanks to Michael Creech, ALLTEL, USA.
Thanks to Ed Billowitz, Medical College of Virginia Hospital, USA.
Change 18.134 Support for OS/390 R2.10 (INCOMPATIBLE).
VMACEXC1 -TYPE30 DD segment has new 8-byte SMF30XBS field for large
VMAC1415 tape block size that requires revised VMACEXC1 to read.
VMAC16 Processing V2.10 data with old MXG will cause INVALID
VMAC30 DEVICE DATA error messages, with trashed DDname, because
VMAC7072 of this INCOMPATIBLE change to SMF type 30.
VMAC71 Note: A common symptom of using an MXG version without
VMAC73 this change to read OS/390 R2.10 or later SMF is
VMAC74 ***ERROR.VMACEXC2.2 INVALID DEVICE DATA message
VMAC78 that has TEMPLSEG=30 in that message text.
VMAC79 This note was added Jun 20, 2001.
Jun 10, 2000 -TYPE1415 has new 8-byte BLKSIZE field for large tape
blocksize, and the CCSID Information added in 2.7 is
now decoded into new variables SMF14CFG/USR/TPE/LBL.
-TYPE16 had only cosmetic changes.
-TYPE30 new variables added to 30_4, 30_5, 30_V, 30_6
datasets: SMF30ASP SMF30CCP SMF30CPR SMF30CSP SMF30JPN
SMF30SME SMF30SPR
-TYPE70 new variable SMF70DSA
-TYPE70PR new variables SMF70ACS SMF70BDA SMF70CSF
SMF70ESF SMF70MAS SMF70MIS SMF70NSA SMF70NSI SMF70ONT
SMF70SPN SMF70STN
-TYPE71 new variables ESAMEMOD SMF71AFB SMF71AHI SMF71AVI
SMF71HRS SMF71HWS SMF71MFB SMF71MHI SMF71MVI SMF71VRS
SMF71VWS SMF71XFB SMF71XHI SMF71XVI
-TYPE72GO new variables R723PRCP R723PRST
-TYPE73 new variable SMF73SFL
-TYPE74 new variable TIMFACNO
-TYPE74PA new variable R742PIOT
-TYPE74CA new variables R745DCID R745LFRE R745LKBF
R745LKBR R745RBYF R745RBYS R745RRID R745VBYW R745VFLG
R745VNTR R745VNUM R745VSER
-TYPE74?? new subtype 7, two or three datasets, but need
test data to decide on structure of datasets created.
Code is in place for Global/Switch/Port sections.
-TYPE78IO new variables R783CUBM R783DPBM R783MCDF
R783MCMN R783MCMX R783PTM
-TYPE791 new variables R791RLG2 R791RCL
-TYPE792 new variables R792FXAB
-TYPE79E R79EEPTM R79EDPBM R79ECUBM R79EMCDF R79EMCMN
R79EMCMX
Change 18.133 Variable CPUTM, the total CPU Time for billing Oracle use
ADOCORAC is modified based on Oracle technical feedback. For the
VMACORAC Batch/TSO connections (CONNID='BATCH' OR CONNID='TSO'):
Jun 9, 2000 CPUTM=SUM(CPUTIMER,CPUCICTM,CPUTCBTM,CPUSRBTM);
and for all other connections,
CPUTM=SUM(CPUTIMER,CPUCICTM,CPUXMETM);
Further discussion of Oracle data is in member ADOCORAC.
Thanks to Yvonne McDonough, USDA, USA.
Thanks to Leslie Arndt, USDA, USA.
Change 18.132 VMXGSUM failed if you used both AUTONAME=YES and NORMx
VMXGSUM operands. AUTONAME is a new feature in SAS Version 8,
Jun 8, 2000 and when specified with PROC MEANS/SUMMARY, new variable
names are longer than 8-bytes and are suffixed with the
statistics (VARIABLE_SUM instead of VARIABLE). With this
change, AUTONAME can be used with VMXGSUM. Why use the
AUTONAME option? If you wanted to sum PDB.JOBS to get
the min/max/mean/sum/std of CPUTM/SELAPSTM/IOTMTOTL, the
VMXGSUM invocation without AUTONAME would be:
%VMXGSUM(INDATA=PDB.JOBS,
OUTDATA=JOBSSUM,
SUMBY=JOBCLASS,
SUM=CPUTM SELAPSTM IOTMTOTL,
MIN=MINCPU MINELAP MINIOTM,
MAX=MAXCPU MAXELAP MAXIOTM,
MEAN=MEANCPU MEANELAP MEANIOTM,
STD=STDCPU STDELAP STDIOTM,
INCODE=
MINCPU=CPUTM;
MINELAP=SELAPSTM;
MINIOTM=IOTMTOTL;
MAXCPU=CPUTM;
MAXELAP=SELAPSTM;
MAXIOTM=IOTMTOTL;
MEANCPU=CPUTM;
MEANELAP=SELAPSTM;
MEANIOTM=IOTMTOTL;
STDCPU=CPUTM;
STDELAP=SELAPSTM;
STDIOTM=IOTMTOTL;
);
But with AUTONAME specified, only this is required:
%VMXGSUM(INDATA=PDB.JOBS,
OUTDATA=JOBSSUM,
SUMBY=JOBCLASS,
AUTONAME=YES,
SUM=CPUTM SELAPSTM IOTMTOTL,
MIN=CPUTM SELAPSTM IOTMTOTL,
MAX=CPUTM SELAPSTM IOTMTOTL,
MEAN=CPUTM SELAPSTM IOTMTOTL,
STD=CPUTM SELAPSTM IOTMTOTL
);
The major difference using AUTONAME=YES is that you no
longer need to equate the new variables in the INCODE=
operand as they are built automatically using the
variable name suffixed by the statistic. This can also
result in the bypassing of a data step or two depending
on the invocation; in this example, two data steps are
bypassed and all that is left is a PROC SORT and a PROC
MEANS, but you are then left with long variable names!
Change 18.131 Amdahl processors can create type 70 RMF records with
ASUM70PR PR/SM segment with LPARNAME='Inactive',LPARNUM=0, and
Jun 7, 2000 LPARCPUS=0, but LPARNUM=0 was previously used to identify
the LPARNAME='PHYSICAL' obs. These records have missing
values for durations, so there was no error in
PDB.ASUM70PR numeric values, but variable LP0NAME had
'Inactive' (yes, in mixed case) instead of PHYSICAL. The
change is to delete these observations as ASUM70PR reads
them, but they will still exist in the TYPE70PR dataset,
as they are really there in the type 70 SMF record.
Change 18.130 Tailoring in EXDB2STS to create variables in DB2STATS did
EXDB2STS not work, because the exit was not included properly.
VMACDB2 -In VMACDB2, the OUTPUT _LDB2STS ; statement was replaced
Jun 2, 2000 with _EDB2STS to invoke the EXDB2STS exit, and
-In EXDB2STS, the _WDB2STS must be OUTPUT _LDB2STS.
The DB2STATS data set is different because it is created
not during the SMF processing, but in subsequent data
steps (after de-accumulation of DB2STAT0 and DB2STAT1,
which are then merged to create DB2STATS). As a result,
the EXdddddd member outputs to the final destination
"_Ldddddd" macro instead of the "_Wdddddd" work file.
Additionally, any variable that is created in EXDB2STS
exit member will be kept in DB2STATS, and thus there is
no need to update the _KDB2STS macro, as it is never
referenced (but now a comment in VMACDB2 explains!).
Thanks to Mr. Chiarle, Gruppo Miroglio Tessile, ITALY.
Change 18.129 IBM Websphere SMF type 103 subtype 2 record contained
VMAC103 an undocumented 4-byte reserved field between CONNSNLA
Jun 2, 2000 and RTDNSMAX caused the subsequent min/max/avg response
Jun 7, 2000 fields to be incorrect. The field was not in the -03
manual but was added in SC31-8690-04. In addition, the
-03 had the 7 ERRORnnn fields ahead of the 4 ERRLVnnn,
but the -04 manual has the ERRLVnnn first, so MXG was
revised to match the revised documentation. Some thread
wait variables are now "IBM internal", but MXG still
inputs that field into the original variable names.
Thanks to Rex Elbert, SPRINT, USA.
Change 18.128 DFSMS/rmm dataset EDGSVREC had blank data set names in
VMACEDGS the volume record, because the data was located +62 from
Jun 1, 2000 where MXG expected, but since the record level value in
the record is still 01, I don't know if this record was
always this way, or was changed between versions.
New variables were added by SMS 1.5 to both the EDGSVREC
and EDGSDREC datasets that are supported by this change.
Thanks to Pat Osborne, DND/DGISDS/DIOM, CANADA.
Change 18.127 Comments only, but message TMNT010E RC=0028 is written by
ASMTAPES MXGTMNT when there is an SMF buffer shortage (or all SMF
May 31, 2000 datasets are full). The RC in MXGTMNT's TMNT010E is the
return code from the SMFWTM macro (documented in the SMF
Manual, GC28-1783-09) and thus this message appears on
your SYSLOG when MXGTMNT tried to write a mount or an
allocation record, but found it couldn't. The list of
all SMFWTM return codes was added in comments.
Thanks to Herb Strazinski, US Bank, USA.
Change 18.126 The string LABEL='NTACSR: was misspelled once as NTACRS,
VMACNTSM and was repeated incorrectly five times that are changed
May 31, 2000 to NTDIST, NTIACC, NTIACS, NTIATC, and NTIATS. These
typos caused BLDNTPDB to see duplicates in &MXGDSNS.
Also _KNTACSR was misspelled once as _KNTACRS.
Thanks to Greg Jackson, National Life of Vermont, USA.
Change 18.125 Extra observations were created in TYPE746B (HFS Global
VMAC74 buffers) and R746GBF/R746GBNF were negative, because the
May 30, 2000 DO R746GSBN=1 TO SMF746FN should have been TO SMF746BN.
Also, variable R746GSB, R746GSBF, and R746GSBP are now
formatted MGBYTES.
Thanks to Alan Deepe, Perot Systems, ENGLAND.
Change 18.124 BUILDPD3 fails "BY VARIABLES NOT SORTED WORK.TYPE25" when
BUIL3005 two jobs with the same READTIME and JOB are executed with
May 29, 2000 the second JESNR first. MXG's heuristic algorithm merges
Jun 1, 2000 TYPE30_1 with TYPE25 to add JESNR into the TYPE25 dataset
(because IBM still has not added JESNR to the TYPE25),
but previously, the output dataset was in order by JESNR.
This unexpected out-of-sequence execution is corrected
by adding PROC SORT DATA=TYPE25; BY READTIME JOB JESNR;
to ensure the TYPE25 is now in the expected order. This
is the first instance I have seen that confirms that the
two jobs can be read-in in the same .01 second READTIME,
but MXG addition of JESNR in BUILDPDB/BUILDPD3 was done
knowing that someday the reader would be fast enough to
create two jobs of same job name with same READTIME.
Thanks to Ron Lundy, Navistar, USA.
Change 18.123 Support for 3494 Peer-to-Peer (Gemini) adds an Enhanced
FORMATS Statistic segment with dozens of new variables, added by
VMAC94 APARs OW42071 and OW42073. Code has not yet been tested
May 25, 2000 as records are not yet available.
Thanks to Greg Kent, IBM Global Services, USA.
Change 18.122 Summarization of TYPETCPT to track the number of users
ASUMTCPT concurrently logged on, using TYPETCP/TYPSTCP to first
May 24, 2000 create the TYPETCPT dataset.
Thanks to Charlie Sticher, University of Georgia, USA.
Change 18.121 Bad offset for second HFS filename caused INPUT EXCEEDED
VMACTCP error; the record is wrong and being investigated, but
May 24, 2000 logic was now added to prevent reading off the record,
while we open a problem with IBM.
Thanks to Michael Creech, Alltel, USA.
Change 18.120 MXG 17.17-18.02 only. Revision to text of Change 18.071.
RMFINTRV That change (in MXG 18.03 and later) is now required for
VMAC7072 OS/390 R2.7 or R2.8 if APAR OW41317 is installed (and 2.9
May 24, 2000 which includes the APAR). That APAR added multi-system
May 30, 2000 enclave fields that were incorrectly read by MXG. While
R2.9 generates error messages, R2.7 and R2.8 do not; both
create bad values (negative, asterisk, etc) in TYPE72GO
observations for periods two and higher.
RMFINTRV sums the TYPE72GO data, so data in RMFINTRV
will also be bad without this change; this is just an
alert, as nothing in RMFINTRV was changed.
This change is really just to update the text of 18.071,
as that change only mentioned Release 2.9. A cosmetic
change (LENSCS test from GE 448 to GE 460) that has no
execution impact was made in VMAC7072.
Thanks to Jane Huong, Cigna, USA.
Thanks to Steve Colio, Cigna, USA.
Change 18.119 Support for Domino Server R5.0.3 new subtype 2 & 6
EXTY1082 type 108 records now create two new datasets:
EXTY1086 Dataset Description
IMAC108 TYPE1082 Domino Server User Activity
VMAC108 (IP address of user, Notes User Name, Type
VMXGINIT of connection, CPU time, Bytes Read/Written
May 23, 2000 an interval record).
May 31, 2000 TYPE1086 Domino Server Database Activity
(Database name, index ops, replicates, docs
added, docs deleted)
In addition, the _Sdddddd sort macros for all TYPE108x
datasets were revised for duplicate SMF record removal.
These new data are a good start to tracking Domino Server
activity to users and causers, but it is still incomplete
and provides only resource measurements, with no counts
of user activity other than bytes, and no intersect of
which databases were used by which users when! The good
news is that IBM is listening and we will continue to see
enhancements in the SMF 108 records as Domino Server is
finally a mainstream product for mainframes!
The type 108 SMF record's product has had these names:
Domino Server R5.0.3
Lotus Domino Server R5.0.2
Domino Server R5.0/R5.0.1
Lotus Domino R5
Lotus Notes Domino Server
The MXG-L Archives contain several discussions of Domino
Server: IBM Redbooks SG24-2083 (Install, Customization,
Admin) and SG24-5149 (Performance Tuning and Capacity
Planning) have both been recommended, especially the USS
customization and installation in SG24-2083.
See Change 18.092 for the type 103 SMF record.
Thanks to Stella Lim, United Air Lines, USA.
Change 18.118 Support for Type 42 RLS Subtype 19 has been revised and
EXTY42X2 validated; two datasets are now created:
IMAC42 Dataset Description
VMAC42 TYPE42X1 VSAMRLS Local Buff Mgr SYSPLEX Totals
VMXGINIT TYPR42X2 VSAMRLS Local Buff Mgr SYSTEM Details
May 18, 2000 However, these two datasets have lots of data, and in
keeping the IBM field name as part of the prefix of each
variable name for the 16 buffer pool with six measures
per buffer pool got messy, but here is the table of the
variable name prefixes for the Buffer Pool measurements:
IBM Buffer Pool Megabytes Buffer Pool Extents
Array LOW HIGH CURR LOW HIGH CURR
"JOE" SMFJOF SMFJOG SMFJOH SMFJOJ SMFJOK SMFJOL
"JRL" SMFJRJ SMFJRK SMFJRL SMFJRN SMFJRO SMFJRP
"JPY" SMFJPZ SMFJQA SMFJQB SMFJQC SMFJQD SMFJQF
There are sixteen variables for each of these prefixes
and their suffixes are 01-09,0A-0G, so SMFJOF01 is the
Low Size (in Megabytes - note that MXG Labels & Formats
for the Megabyte variables have been converted from the
min/max/current count of buffers to the size of that
buffer pool in bytes, and is formatted to print KB/MB/GB
with the MGBYTES format) of the 2K buffer pool, and
SMFJOL0G is the current number of extents in the 32K
buffer pool. Labels identify the pool size.
This is valid data, but may be enhanced as the data is
viewed and used.
APAR OW44739 (May 30, 2000) acknowledges that the SMF
manual for V2R5 and V2R6 subtype 19 documentation was
wrong and that the V2R7 and later are correct.
Thanks to Edward McCarthy, IBM GSA, AUSTRALIA.
Change 18.117 Tailoring failed because IMACKEEP was not included in the
TYPEMWUX TYPEMWUX member.
May 18, 2000
Thanks to Bart Decat, KBC Belgium, BELGIUM.
Change 18.116 Two occurrences of AND SV30ALN GE 1 THEN must be changed
VMACSARR to AND SV31ALN GE 1 THEN and to AND SV32ALN GE THEN as is
May 18, 2000 obvious from the other variables in those statements.
Thanks to Ian Mackay, RBS, UK.
Change 18.115 Assembly of ASMTAPES under OS/390 R2.8 or 2.9 with ASM H:
ASMTAPES IEV122 ERROR ILLEGAL OP-CODE FORMAT MACRO STCKCONV, due
May 17, 2000 to IBM error (APAR OW39924, macro STCKCONV has blank line
at sequence number 10075000 - remove or commend out blank
line. Or use the High Level Assembler instead of ASM H,
which tolerates the blank and is IBM's recommended ASM
Thanks to Scott Wigg, USBank, USA.
Change 18.114 Variable UOWTIME was kept LENGTH 4 in dataset MONITASK,
VMACTMO2 which would cause a problem only if you were to merge the
May 17, 2000 MONITASK and DB2ACCT datasets; UOWTIME is INPUT from the
first six bytes of UOWID; it is only a token for matching
DB2ACCT to MONITASK/CICSTRAN, but it needs to be kept as
LENGTH 8, as it is everywhere else in MXG except this one
member. (It was also not formatted as DATETIME21.2, but
rarely is the time value of UOWTIME useful; the truncated
value wraps every few weeks and from some originations is
completely off from current time, but that's ok for a
token.
Thanks to Freddie Arie, Texas Utilities, USA.
Change 18.113 The SELDSN macro did not list ASUMCEC after ASUM70PR,
JCLMNTH but MONTHBLD expected to create MONTH.ASUMCEC. Added
May 17, 2000 ASUMCEC to the list of datasets.
Thanks to Freddie Arie, Texas Utilities, USA.
Change 18.112 Variable NSPYTIPL is now formatted DATETIME21.2 and kept
VMACNSPY as LENGTH 8 instead of the default 4 (which can truncate
May 17, 2000 a datetime variable by as much as 255 seconds).
Thanks to Freddie Arie, Texas Utilities, USA.
Change 18.111 RMF variable MVSLEVEL from RMF 70 is now kept in the
VMXGRMFI RMFINTRV dataset.
May 16, 2000
Thanks to Marc Matthys, Hudson Williams, BELGIUM.
Change 18.110 -NTSMF object SNA ADAPTER SNADLC* has an Instance Field
EXNTCOTI that is now decoded when it is present.
EXNTTN32 -Support for COM Transaction Integrator object in the new
IMACNTSM COMTRNIG dataset.
VMACNTSM -Support for TN3270 Server object in the new TN3270SV
VMXGINIT dataset.
May 15, 2000
Thanks to Tom Aaslet, SMT, DENMARK.
Thanks to Richard P. Clarke, Freemans PLC, ENGLAND.
======Changes thru 18.109 were in MXG 18.04 dated May 15, 2000======
Change 18.109 Comments only were changed in MONTHBLD (that it expects
MONTHBLD that your Weekly PDB is built on Monday morning), and new
MONTHBLS member MONTHBLS expects that your Weekly PDB is built on
May 15, 2000 Saturday instead. The actual weekly job doesn't care
when it is run; it simply combines the last seven dailies
to create a Weekly PDB thru that morning's daily PDB, but
the MONTHBLx has to know what is your first day of week.
Thanks to Larry Heath, Shaw, Inc, USA.
Change 18.108 Variable SVCCIO inserted between SVCCKERN and SVCCSEM4.
VMACSVCC However, 75% of Peregrine's elapsed times are zeroes, and
May 13, 2000 many records that should be there aren't! Open problem.
Change 18.107 Variable NOAMIDBK is now INPUT as &PIB.2 (instead of 4),
VMACNOAM variable NOAMCOLN=INPUT(NOAMCOLL,&PIB.4.) is the numeric
May 15, 2000 value of NOAMCOLL, which is now input as $CHAR4. with
$HEX8. format, and the non-Y2-compliant 0yymmddF NOAMMIGD
"Object Migration Date" is now protected with a 1960
window.
Thanks to Peter Skov Sorensen, Jyske Bank, DENMARK
Change 18.106 Inconsistent macro names were used in BLDNTPDB and in the
BLDNTPDB TRNDNTIN trending for NTSMF. The Macro _LASUMNT in the
May 13, 2000 BLDNTPDB member was changed to _LSUNTIN to be consistent
with the TRNDNTIN naming conventions.
Thanks to Greg Jackson, National Life of Vermont, USA.
Change 18.105 -Workload Activity Report was updated for APAR OW41317:
ANALRMFR three enclave fields (AVG ENC/REM ENC/MS ENC) added in
May 13, 2000 the TRANSACTIONS column.
-Workload Activity Report was updated for APAR OW41317:
goal mode, REPORT=WLMGL,RPTOPT=WGPER, the PERIOD
summarization and calculations were revised to remove
SYSTEM from all BY statements.
-Device Activity Report was updated for APAR OW31701:
Add column MX to DASD ACTIVITY REPORT to show the
number of UCBs that were active for PAV devices.
-Channel Activity Report was updated for APAR OW35586:
columns for Ficon data transfer rates and Bus Utilization
were added.
Change 18.104 SAS data libraries built in tape format with OS/390 SAS
CONFIGV8 V8.0 TS MO, TS M1, and V8.1 cannot be safely used. You
JCLQAJOB may get errors when you write or read; or worse, datasets
JCLUXRE6 created from tape datasets can have trashed labels.
MONTHBLD See "SAS Technical Notes" in Newsletter THIRTY-SEVEN for
MXGSASV8 a technical discussion of the errors (also on homepage).
VMXGINIT Instead of using the V8SEQ engine, until these errors are
WEEKBLD corrected by SAS Institute, you must change the default
WEEKBLDT tape engine so that the V6SEQ engine is used, by either:
May 13, 2000 - adding SEQENGINE=V6SEQ to your CONFIG member, or
- using MXGs revised CONFIGV8 member with that option, or
- adding OPTIONS SEQENGINE=V6SEQ; in every job's SYSIN
input stream, or
- adding ,OPTIONS='SEQENGINE=V6SEQ' to each // EXEC SAS
or // EXEC MXGSAS JCL statement for each job.
Also, MXG members WEEKBLDT and MONTHBLD, which create
tape format datasets on temp DASD, will fail, as they
contain LIBNAME TAPETEMP TAPE ; statements that force
the V8SEQ engine even when SEQENGINE=V6SEQ is set, so
"TAPE" in those LIBNAME statements was replaced with a
new macro variable &TAPENGN, set to V6SEQ by VMXGINIT.
And there now exists member MXGSASV8, a JCL Procedure
example to use for SAS Version 8, as I discovered that
SAS member BATCHXA in the SAS CNTL library is now named
BATCH, and the MXGSASV8 example now uses member CONFIGV8
(instead of CONFIG) for execution under SAS V8.
(Confused? CONFIG08 was for SAS 6.08, not SAS V8)
SAS Institute opened SAS Note 002651 and found that the
LABEL error applies to all platforms where TAPE engine is
supported, so they are aggressively attacking the error.
July 26 update: SAS ZAP Z8002651 now exists for SAS V8.0
and V8.1, and the error is corrected in SAS V8.2.
With that zap, you can change the CONFIGV8 to V8SEQ, but
since I can't detect if that ZAP is installed.
Thanks to Dan Riggs, Wachovia, USA.
Thanks to Ron Adkins, Wachovia, USA.
Thanks to Alan Lankin, Towers Perrin, USA.
Thanks to Chuck Hopf, MBNA, USA.
Thanks to MP Welch, SPRINT, USA
Change 18.103 IMS log processing, MXG 18.03 only, IMS 6.1 only (whew!):
TYPEIMSB WARNING: UNINITIALIZED VARIABLE _IMSVERS message because
May 12, 2000 %INCLUDE SOURCLIB(VMACIMSA,IMACKEEP);
should have been added by change 18.086. Our testing was
with IMS Version 5, so we missed this error, as even with
that note, the 18.03 IMS Support processes V5 just fine.
Thanks to Pete Young, University of Toronto, CANADA.
Change 18.102 SMF 108 records from the early release 5.0 cause error
VMAC108 INVALID DO LOOP CONTROL because the DO loop on SM108PTN
May 12, 2000 did not test first that SM108PTN was non-missing.
Thanks to Coen Wessels, UNICBLE, SWITZERLAND.
Change 18.101 INVALID DATA FOR REQSTART resulted when the date field
VMACIPAC contains packed decimal value of zero for both the time
May 11, 2000 and date parts ('0000000C0000000C'x). Inserting the
"double question-mark modifier" in the INPUT statement
suppresses the note and hex dump of the SMF record. This
subtype (for KSDS VSAM) should not have been created by
IPAC, since that feature is not enabled at this site.
So MXG now protects the zero date in this useless record.
Thanks to Jim Petersen, Homeside Lending, Inc, USA.
Change 18.100 Variable FILDATEX was not protected for invalid Julian
VMACZARA date values of 1998000, but now those expiration dates
May 11, 2000 will be set to MXG's "infinite" date of '31DEC2099'D.
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 18.099 Dataset ASUMCEC is now automatically built in the Monthly
MONTHBLD and Weekly PDB libraries. Since it is built by %INCLUDE
WEEKBLD of ASUM70PR member, and MXG already expected the ASUM70PR
WEEKBLDT dataset to exist, adding ASUMCEC to the WEEK/MONTH PDBs
May 11, 2000 should be transparent.
Thanks to Normand Poitras, ISM, Canada.
Change 18.098 Variable FTPDATFM added to LENGTH $1 statement, as it
VMACTCP is decoded by $MGTCPFM and its length must be forced in
May 10, 2000 the LENGTH statement.
Thanks to Lindsay Oxenham, IBM Global Services, AUSTRALIA.
Change 18.097 Summarization example for DB2STATB, the DB2 Statistics
ASUMDBSB Buffer Pool data, which is not yet provided by ANALDB2R
May 2, 2000 Statistics Detail report. This is a first pass effort.
Thanks to Chad Heck, BEPC, USA.
Change 18.096 Execution under ASCII only. Some hex variables were read
VMAC74 with $EBCDIC instead of $CHAR, causing possible incorrect
Apr 30, 2000 values in internal variables TEMPIOML/SMF74PRF/DASDRCFG/
SMF74CNX/RF8FLAG/DSG2 and kept variables TYPEIOML,
EXTNDSTO,ESCAENAB,ESCACONF,MTPATBEG,MTPATEND,DEVDYNCH,
DEVDISNV,BASE,NRALEXCH,SNAV,DVID,RCOL,DIFN,DBDP, &PDAT,
but only if the raw SMF data was read with MXG under SAS
on an ASCII platform. Fortunately, most of these are new
variables, and the old ones were rarely used.
-I misread APAR OW31701 and used the wrong hex field to
set variable NRALEXCH (number of aliases changed?).
and overlooked bit 2 of SMF74CNX, now variable PAVBASE.
Change 18.095 The HFS Dataset Names for FTP Client and Server are now
VMACTCP created as variables FTPHFSD1/FTPHFSD2 in the TYPETCPF
Apr 30, 2000 and TYPETCPC datasets. While the theoretical length of
an HFS dsname could be 1024 bytes, only the first 200
bytes (the maximum length of a character variable under
SAS V6) are kept. However, if you actually have dsnames
longer than 200, this could easily be changed, and when
the entire world is on V8 with compression, variable
lengths can be 32000 with no wasted space!
Thanks to Steve Clark, California Federal Bank, USA.
Change 18.094 Building the daily MVS PDB on tape is not recommended, as
VMXGCICI there will be lots of rewinds (and possible dismounts and
VMXGRMFI remounts). If you want to put your daily PDB on tape, it
Apr 30, 2000 is far better to create it on temporary DASD and then use
Feb 27, 2003 PROC COPY IN=PDB OUT=PDBTAPE MEMTYPE=DATA; to copy all of
the PDB datasets to the tape in one write after creation.
MXG has always intended that the BUILPDB could write to
//PDB when it points to tape, so code was revised so that
you could make the below changes and put //PDB to tape:
To write all the PDB datasets directly to //PDB on tape:
//SYSIN DD *
%LET PCICTRN=WORK;
%LET PDB2ACC=WORK;
%LET PCICACC=WORK;
%INCLUDE SOURCLIB(BUILDPDB);
PROC COPY IN=WORK OUT=PDB;
SELECT DB2ACCT CICSTRAN CICSACCT;
DB2ACCT and CICSACCT are normally written to //PDB during
the SMF-processing step, but you cannot have two datasets
open simultaneously in a sequential data library, so they
will be written initially to //WORK and copied to //PDB.
The CICSTRAN dataset is normally written to //CICSTRAN as
a separate sequential data library, but in this example,
CICSTRAN will be written to //WORK and then copied to the
//PDB. Of course, if you don't want to keep CICSTRAN and
DB2ACCT you can eliminate the PROC COPY. (CICSACCT always
has zero observations, and is not likely used anymore.)
If you have large CICSTRAN and DB2ACCT datasets, you may
prefer to write them to separate tape datasets and have
the rest of the PDB datasets written to //PDB, taking
much less //WORK space and eliminating double handling:
// EXEC MXGSASV9
//CICSTRAN DD DSN=CICSTRAN,DISP=(,CATLG),UNIT=TAPE
//DB2ACCT DD DSN=DB2ACCT,DISP=(,CATLG),UNIT=TAPE
//SYSIN DD *
%LET PCICTRN=CICSTRAN;
%LET PDB2ACC=DB2ACCT;
%LET PCICACC=WORK;
%INCLUDE SOURCLIB(BUILDPDB);
And if you want to include ASUMCACH, you must use this
code; ASUMCACH normally reads PDB.TYPE74 and PDB.TYPE74CA
and outputs to PDB.ASUMCACH:
DATA TYPE74; SET PDB.TYPE74;
DATA TYPE74CA; SET PDB.TYPE74CA;
The actual MXG changes made in CHANGE 19.084 were these:
-In VMXGCICI, protection for archaic CICEOD/REQ/RRT/USSRV
datasets had input and output from the PDB ddname; now a
temporary file is created and used for the four inputs.
-In VMXGRMFI, the TYPE72 and TYPE72GO datasets were read
concurrently from the PDB ddname; a temporary copy is
made of the TYPE72 dataset (which eventually will have
zero observations always when the world is goal mode!).
Read Change 18.104 before using SAS V8 tape datasets.
The text of this change was revised in Feb 2003.
Change 18.093 Support for Roger Software Development, RSD FOLDERS 4.0.
EXRSDFBA Two datasets are created
EXRSDFOL dddddd dataset description
IMACRSDF RSDFBA RSDFOBAT RSD FOLDERS ASTRES BATCH
TYPERSDF RSDFOL RSDFOONL RSD FOLDERS ASTRES ONLINE
TYPSRSDF Most fields documented in DSECTS ACCIO and ACCIOAP are
VMACRSDF now decoded, but there still are a few unknown fields
VMXGINIT in the record, but they seem to contain zeroes.
Apr 29, 2000
May 13, 2000 Note that member TYPEWSF supports RSD's EOS/WSF product.
Thanks to Chairat Tiajanpan, KrungThai Bank, Thailand.
Change 18.092 The _ETY1032 statement, which OUTPUTs SMF 103 subtype 2,
VMAC103 was in the wrong place (too early in the INPUT logic),
Apr 27, 2000 causing many TYPE1032 variables to have missing values.
The type 103 SMF record's product has had these names:
Websphere Application Server for OS/390
HTTP Server Version 5.2
Lotus Domino GO Webserver
ICSS (Lotus Domino GO)
IICS V2 R2
See Change 18.119 for the type 108 SMF record.
Thanks to Steve Clark, California Federal Bank, USA.
Change 18.091 A set of sample reports for some basic TCP/IP analysis
ANALTCP from IBM type 118 records (MXG Member TYPETCP) for the
Apr 27, 2000 analysis of FTP and Telnet usage.
Thanks to Steve Clark, California Federal Bank, USA.
Change 18.090 Cosmetic, to avoid confusion. VMXGSUM's WARNING message
VMXGSUM that a dataset did not exist had a confusing reference to
Apr 27, 2000 KEEPALL=NO that was removed. The message now states that
it is normal for the first TRENDing run; but otherwise
the warning that an input dataset did not exist is valid.
Thanks to Normand Poitras, ISM, CANADA.
Change 18.089 The last period for any BY group when intervals are
ANALCNCR synchronized may not have been synchronized, because the
Apr 26, 2000 RUNTIME variable was not forced to be a discrete interval
time value. Adding RUNTIME=CEIL(RUNTIME/&TIMER)*&TIMER;
and DO up to LASTINTV in &TIMER chunks fixed the error.
Thanks to Anthony P. Lobley, EDS, ENGLAND.
Change 18.088 Using VMXGRMFI with TREND= specified and PDB= blank to
VMXGRMFI invoke only for TRENDing failed with messages:
Apr 26, 2000 WARNING: APPARENT SYMBOLIC V70NRM NOT RESOLVED....
Local macro definitions mis-located inside the PDB loop
were relocated, and KEEPALL=YES was added to the VMXGSUM
invocation in its TRENDing section.
Thanks to Normand Poitras, ISM, CANADA.
Change 18.087 Support for MainView for CICS 5.3.01 (INCOMPATIBLE). The
VMACMVCI CMRDATE format was changed to YYYYMMDD, and a PTF added
Apr 26, 2000 variables STRTTIME, ENDTIME, and SYSTEM to the CMRDETL
transaction dataset. Nine new file count variables were
added in the CMRFILE dataset.
Thanks to Steve Smith, BMC, USA.
======Changes thru 18.086 were in MXG 18.03 dated Apr 17, 2000======
Change 18.086 Revised TYPEIMSB member for IMS log processing completes
TYPEIMSB MXG 18.03 revisions, correcting earlier TYPEIMSB members
Apr 17, 2000 (post 17.17) that created dates of Jan 1, 2000 instead of
the correct date. MXG 18.03 dated Apr 17, 2000 has now
corrected all reported IMS 5.1 log errors, and thus the
IMS Log processing now requires that release of MXG.
Change 18.085 Revisions to Sterling's Solve Management Services V3.7
VMACSOLV support. New subcategory '50'x is undocumented, and MXG
Apr 15, 2000 code will be revised to create separate datasets for each
subcategory. The original MXG code was only for the '06'
USERCPU segment, which is now the only subcategory that
is output in TYPESOLV, pending receipt of documentation
and additional test data.
Apr 29: SOLVLAST changed from TODSTAMP8. to SMFSTAMP8.
Thanks to Silas J. White, FDIC, USA.
Thanks to Ian Davies, Workers' Compensation Board of Alberta, CANADA.
Change 18.084 Variable VERSION is now XPTRVERS, because it conflicted
VMACXPTR with pre-existing character variable VERSION, and it is
Apr 14, 2000 now labeled 'XPTR*REPORT*VERSION'. The KEEP= list for
May 12, 2000 XPTR50 and XPTR52 were missing SYSTEM/SUBSYSTEM/SMFTIME
May 15, 2000 causing _SXPTR50/_SXPTR52 to fail. I protected the Y2K
non-Ready records for 2000, expecting only new dates, but
the RPRTTIME date in XPTR52 have 98 and 99, which MXG
interpreted as 2098/2099. Apparently, the RPRTTIME date
is when the report (format?) was put out to this X/PTR
Report repository, and so now both 19xx and 20xx dates
are protected. LOC_7ATA is respelled as LOC_DATA.
May 12: SRC_FLG logic revised.
May 15: SRC_FLG '... .100'B now '.....100'B.
Thanks to Mike Shapland, PKS Information Services, Inc, USA.
Change 18.083A IMF variable PROGRAMB (@149) was originally documented
VMACCIMS "BMP Program name", when it was added to the IMF record
Apr 14, 2000 by IMF Release 1.3 years ago, because variable PROGRAM
May 22, 2000 was already input (@53), and so MXG used the logic
"IF PROGRAMB GT ' ' THEN BMP='Y';"
to identify BMPs. However, BMC Technical Support has
informed me to instead use variable PROGTYPE (@78), so
IF PROGTYPE='B' THEN BMP='Y';
is now the revised change in VMACCIMS to identify BMPs.
BMC Technical Support also told me that the field I named
PROGRAM has always actually contained the PSBNAME, and
the field I named PROGRAMB contains the actual program
name. This has not been noticed; first, MPPs must have
PSBNAME and PROGRAM name the same, second, for BMPs and
other transaction types that can have different names,
most sites use the same name, and third, IMS analysis is
usually more interested in transaction name than program.
But now that I know the truth, VMACCIMS was changed:
- variable PROGRAMB is still input @149 but re-labeled
to make no reference to "BMP".
- variable PROGRAM is now input @149 instead of @53.
- new variable PSBNAME is now input @53 and kept in the
CIMSTRAN dataset from the 'FA'x IMF records.
The entire text of this change was revised May 22, 2000,
but the change to VMACCIMS that corrected BMP='Y' was
made by the original change contained in MXG 18.03 of
April 17, 2000. Only the changes to PROGRAM/PSBNAME
were not available until MXG 18.05.
Thanks to Betty Paterson, BMC, USA.
Thanks to Dan Sills, The Mutual Group, CANADA.
Thanks to Bob Falla, The Mutual Group, CANADA.
======Changes thru 18.083 were in MXG 18.03 dated Apr 12, 2000======
Change 18.083 ICF CPUs support was still imperfect. The PCTLnBY in
ASUM70PR both PDB.ASUM70PR and PDB.ASUMCEC was wrong (too low)
Apr 11, 2000 if there was an ICF in the box, and the LPnDUR in
PDB.ASUMCEC was DURATM instead of LPnNRPRC*DURATM.
Note that for ICF removal from capacity calculations,
you need APAR OW37565 or the current OS/390 release that
stores 'ICF' into SMF70CIN. If you have systems that are
back level, you can use EXTY70PR to force SMF70CIN='ICF'
for the TYPE70PR observations for the ICF LPARNAME, but
you also must set SMF70CIN='ICF' for the PHYSICAL entry
for that LPAR by its LCPUADDR:
IF SYSTEM='CMC1' AND (LPARNAME='CFP2' OR
(LPARNAME='PHYSICAL' AND LCPUADDR=2))
THEN SMF70CIN='ICF';
Thanks to Richard S. Ralston, Whirlpool, USA.
Change 18.082 First MXG 18.03 only. Sort macro for TYPE64X had a
VMAC64 missing underscore before the _WTY64X in the PROC SORT.
Apr 11, 2000
Thanks to Bruce Widlund, Merrill Consultants, USA.
======Changes thru 18.081 were in MXG 18.03 dated Apr 11, 2000======
Change 18.081 Very minor. Protection for a 16th IFCID destination
VMACDB2 eliminates the VMACDB2 NOTE: YOUR DATA HAD NRQWSC=16.
Apr 11, 2000
Change 18.080 Revisions to correct tape drive counts for SPINing tape
ASUMTALO allocations, and additional exits have been added so that
Apr 11, 2000 selection by SYSTEM and changes to bucket definitions can
Apr 12, 2000 be made without EDITing the ASUMTALO member (by using
%LET MACKEEP= to redefine the exit macros:
_ESUTAL1 allows for the insertion of code to select
which SYSTEMs data is summarized.
_ESUTAL2 allows for overriding the buckets built by
ASUMTALO's invocation of ANALCNCR.
_ESUTAL3 allows for adding to the renames of buckets
if more than 8 bucket are present (supports
new buckets added in _ESUMTAL2)
Thanks to Anthony Lobeley, EDS, ENGLAND.
Change 18.079 These two summary members require KEEPALL=NO to override
ASUMCICS the VMXGSUM new default of KEEPALL=YES, Change 18.065.
ASUMCICX These members will read either IBM or Landmark CICS data,
Apr 10, 2000 but only one set of variables was kept; with KEEPALL=NO,
VMXGSUM constructs a KEEP= with only needed variables,
but KEEEPALL=YES passes the hardcode SUM= list, which
caused variable not found condition. I will revise the
members in a cleaner fashion in a later release, but by
restoring KEEPALL=NO for these two VMXGSUM invocations,
it constructs the correct KEEP= list, and all is well!
Change 18.078 The change in order of sort variables by Change 18.001
MONTHBLD was not propagated into WEEKBLD, WEEKBLDT or MONTHBLD,
WEEKBLD causing NOT SORTED errors TYPE30MU, TYPE30OM, and TYPE89
Apr 10, 2000 datasets. The BY lists were corrected and now match the
Apr 24, 2000 BUILDPDB sort order, but NOT SORTED errors will still
Apr 27, 2001 occur if you build weekly/monthly from daily/weeklys that
Aug 7, 2001 were created with different sort orders.
To get that failing weekly/monthly job to finish, you
only need to add the NOTSORTED option to the end of the
BY list in your WEEKBLD/WEEKBLDT/MONTHBLD:
in WEEKBLD: add NOTSORTED to the BY statement after
each SET statement BY .... NOTSORTED ;
in WEEKBLDT: add NOTSORTED to the MACRO _BYLIST ... %
& MONTHBLD after each MACRO _DSET TYPExxxx %
Explanation: The BY statement with multiple datasets
in a SET statement creates an output
dataset that is sorted, so that a SORT in
a report programs can be bypassed by SAS
to save time and resources, but nothing
else in MXG requires datasets to be in a
sort order, so adding option NOTSORTED
will create the output dataset (which is
partially sorted!) without the error.
Install a new MXG version on the first logical day of
your week (e.g.: my week is MON to SUN PDBs, or Tue-Mon
daily runs, so I move my new version into production on
Monday afternoon, before the Tuesday morning's BUILDPDB,
so that all of the new week's dailies will be created by
the same MXG version) to minimize sort change issues.
Thanks to David Ehresman, University of Louisville, USA.
Thanks to Alan Lankin, Towers Perrin, USA.
Thanks to Scott Snyder, First Data, USA.
Change 18.077 A final PROC SORT was added to put PDB.CICINTRV back in
VMXGCICI the correct order for the WEEKLY merge. The final step
Apr 9, 2000 logic can recalculate STARTIME, so the added sort was:
PROC SORT DATA=CICINTRW OUT=&OUTDATA;
BY SYSTEM APPLID SMFPSSPN STARTIME;
Thanks to Michael L. Knych, International Paper, USA.
Change 18.076 NETSPY report NSPYPRT exposed that MXG NETSPY datasets
VMACNSPY needed revisions in some of its response calculations.
Apr 9, 2000 -Julian discovered and tested with TARGETS=HOST:
NETRSPNO and NETRSPN6 appear to be the number of
instances where a 'definite response' has occurred, as a
result of either (1) FORCEDR in the NetSpy INITPRM, or
(2) the application running in DR-mode anyway. Therefore
they represent the number of times network response time
has been measured, and can correctly be used to calculate
average network response time (by division by CRSPNET and
CRSPNET6). They can only be used to calculate %responses
on target if TARGETS=USER is in force. With TARGETS=HOST
the value of NETRSPNO and NETRSPN6 should be irrelevant.
-The revision of TRANSNO +1 or -1 relates to the number of
inputs to the number of transactions terminated at the
host, which is redundant with LUNRSPSS, and was removed.
-TARGETS=HOST/USER based on NETRSPNO LT Sum(T1-T4RSPNO)
is an approximation that fails with small numbers.
Instead, using SMFTFLG1 for NSPYLU and XDOMAIN for the
NSPYAPPL is a better determination.
Thanks to Julian Smailes, Experian Limited (UK), ENGLAND.
Change 18.075 Dataset TMVSWG's _STMVWG and _NTMVWG macros were not in
VMACTMV2 the _STMV2 and _NTMV2 macro lists, and comments with the
Apr 9, 2000 TMVSWKP instead of TMVSWG were corrected.
Thanks to John Jackson, Redcats (UK), ENGLAND.
Change 18.074 CICS Statistics dataset CICTCPIP variables SOROPENG/OPENL
VMAC110 which should be open timestamp on GMT and Local are bad;
Apr 9, 2000 OPENG is zero, and OPENL is 'FFFFFFFFD1' which produces
a datetime of 17SEP2042:18:53:47.18 in every record. And
the GMT and Local clock values for OPEN/CLOSE are not the
same; they are off by about .2 seconds.
This change is only for documentation; when an IBM APAR
exists that corrects those fields, this will be updated.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 18.073 Support for Systemware SYSOUT X/PTR, JHS, MPS, and C/QUE
EXXPTR02 product's user SMF record. There are 30 XPTRnn datasets
... created, but only these subtypes have been data tested:
EXXPTR52 04,06,09,10,11,12,18,20,50,51,52. This vendor provides
IMACXPTR sample SAS code that was used as a starting point, and
TYPEXPTR some of its variable names were used in MXG datasets, but
TYPSXPTR that program failed when executed, had fields input from
VMACXPTR wrong locations, was incomplete, and not Y2K compliant,
VMXGINIT so the DSECTS were used to create this MXG support with
Apr 9, 2000 its structure, formatting, exits, etc.
Thanks to Mike Shapland, PKS Information Services, Inc, USA.
Change 18.072 ObjectStart/Huron have new HU62KEYn/HU72KEYn variables so
VMACHURN that the multiple observations from a single type 62/72
Apr 7, 2000 (multiple Process, Accounting, Locking, etc) can be
Apr 10, 2000 combined into a logical transaction. HU47INTV/APL/SSNO,
HU49INTV/HU49APL/HU49SSNO and HUxxHPSN/PUIN/ACTN/SCN/SAN/
PERN/LKN/RPN/ for 62 and 72 subtypes are all now kept.
Variables HUnnSSNO were changed from &PIB.4. to $CHAR4.
with $HEX8 so that the type 49 and 62 records can be
merged together by HU49SSNO and HU62UNQI to show Huron
resource usage by JOB/STEP. The LABEL for HU49TCPU is
TCB+SRB (was TCB).
Thanks to Lindsay Oxenham, TELSTRA, AUSTRALIA
Thanks to John Toohey, TELSTRA, AUSTRALIA.
Thanks to Greg Meyer, Isuzu Motors, USA.
Change 18.071 MXG 17.17-MXG 18.02 only INPUT STATEMENT EXCEEDED or
VMAC7072 INVALID DATA FOR R723CIEA in Goal Mode Type 72 Subtype 3.
Apr 7, 2000 The OS/390 R2.9 added code was wrong. The INPUT of CXEA
Apr 10, 2000 and CFEA should have been &RB.8. vice &RB.4., and there
was a missing SKIP=SKIP-24; after that input statement.
See Change 18.120: R2.8 with APAR OW41317 also requires
this change, but has no error message. 24May2000.
Thanks to Dr. Alexander Raeder, Karstat AG, GERMANY.
Thanks to Harmuth Beckmann, Karstat AG, GERMANY
Change 18.070 DB2ACCT variable JOB has been revised based on the source
ASUMDB2A of the connection, and new variables TRAN and PLAN are
VMACDB2 also created for possible use in matching to CICSTRAN:
Apr 7, 2000 TRAN=' ';
Apr 10, 2000 PLAN=QWHCPLAN;
IF QWHCATYP IN (1,2,0BX) THEN DO;/*TSO,CALL ATTACH*/
JOB=QMDACORR; /*UTILITY JOBS*/
END;
ELSE IF QWHCATYP IN(3,5,6,9,0AX) THEN DO;/*DLI,IMS*/
JOB=QWHCCN;
END;
ELSE IF QWHCATYP =4 THEN DO;/*CICS*/
JOB=QWHCCN;
TRAN=SUBSTR(QMDACORR,5,4);
END;
ELSE IF QWHCATYP IN (7,8) THEN DO;/*DISTRIBUTED,REMOTE*/
JOB=QWHCOPID;
PLAN=SCAN(QWHCCV,1,' .');
END;
-Testing with the new VMXGSUM change (KEEPALL=YES) found
that some DB2 6.1 variables had been added to ASUMDB2A
but were not in the KEEP= list for dataset DB2ACCT. The
old default of KEEPALL=NO had masked the omission, and
ASUMDB2A's spelling of two QZZ variables as QXX.
Thanks to Paul Weissman, Perot Systems, USA.
Change 18.069 Support for CA's NETSPY 5.3 (COMPATIBLE) adds nine new
EXNSPYAD datasets and removes one. The NSPYTELE TELNET dataset
EXNSPYAT introduced in 5.2 has been completely replaced in 5.3,
EXNSPYHP so references to NSPYTELE and EXNSPYTE were deleted.
EXNSPYMA The nine new dataset created are:
EXNSPYMC dddddd Dataset Record Description
EXNSPYMR NSPYAD NSPYAPPD D APPN Directory Services
EXNSPYRT NSPYAT NSPYAPPT E MNPS Application Recovery
EXNSPYTC NSPYHP NSPYHPR N High Performance Routing
EXNSPYTS NSPYMA NSPYMNPA M MNPS Application
IMACNSPY NSPYMC NSPYMNPF F MNPS Coupling Facility Struct
VMACNSPY NSPYMR NSPYMNPR E MNPS Application Recovery
Apr 7, 2000 NSPYRT NSPYVRTP R VTAM RTP
NSPYTC NSPYTCP I TCP/IP Connections
NSPYTS NSPYTCPS J TCP/IP Stack
These datasets have been added but only syntax tested, as
no test records are yet available for validation.
Thanks to Roger Zimmerman, Scudder Kemper Investments, USA.
Change 18.068 DB2ACCT variables ACCOUNT1-ACCOUNT9 were not populated
VMACDB2 for DBAAS nor for non-Local-DB2-ACCOUNTING records. The
Apr 6, 2000 logic for Local-DB2 was replicated for the other two DB2
record types. Note if you put your own accounting values
in your DB2 records, you must use a 'FF'x delimiter if
you want those accounting fields separated into separate
account variables; only DB2 takes MVS accounting fields
and inserts a 'FF'x delimiter in its 101 records, so that
is what MXG's VMACDB2 logic expects. If there is only
on field with no 'FF' delimiter, then it will be stored
into variable ACCOUNT1 (and member IMACACCT sets the
stored length of each of the ACCOUNTn variables).
Thanks to Ian McKay, Royal Bank of Scotland, SCOTLAND.
Change 18.067 Negative DD counts for OPEN/USED DB2 Dataset calculation:
ANALDB2R -IBM APAR PQ21969 (see NEWSLTRS for APAR details) corrupts
Apr 5, 2000 QTSLWDD, "Slow DDs", which is subtracted from QTDSOPN.
-MXG logic error if there were more than one interval in
the summary. The statement QTDSOPN=QTDSOPN/INTRVLS;
was moved to follow DSUNUSED=(QTDSOPN-QTSLWDD)/INTRVLS;
so total-total instead of average-total is subtracted!
Thanks to John McCray, Huntington National Bank, USA.
Change 18.066 The PDB.ASUMCEC dataset requires that all SYSTEM's clocks
ASUM70PR are on the same timezone, since the merge is by STARTIME.
EXCECTIM This change adds new exit member EXCECTIM to allow you to
Apr 5, 2000 insert your own logic to change the time zone of STARTIME
to a common time zone. You could use logic like this:
IF SYSTEM='CST ' THEN STARTIME=STARTIME+HMS(-5,0,0);
ELSE IF SYSTEM='EUR ' THEN STARTIME=STARTIME+HMS(1,0,0);
to change STARTIME from local to GMT.
Thanks to Richard S. Ralston, Whirlpool, USA.
Change 18.065 The KEEPALL=NO default of VMXGSUM can cost CPU time with
ANALCISH minimal benefit, especially when VMXGSUM is used multiple
ASUMCICS times, as in ANALCISH which invokes 45 executions of the
ASUMCICX VMXGSUM macro if all CICS shutdown reports are requested!
ASUMDBDS MXG enhancements to support all possible syntax in that
ASUMHPAI KEEPALL=NO logic (constructs KEEP= statements with only
ASUMHPSU needed variables, but parsing must be in macro language
MNTHDB2S that is more expensive that data step logic) cost too:
TESTOTHR 16.16 17.17 17.17
TYPEMON8 KEEPALL= NO NO YES
TYPEMONI CPUTM 62 sec 93 sec 43 sec
VMACMON8 ELAPSTM 15 min 19 min 10 min
VMACMONI Hi Block Used 1905 1905 1921
VMXGSUM for ANALCISH, with no savings in the work space needed!
Apr 4, 2000
Apr 11, 2000 I had planned to change the default to KEEPALL=YES, but
found that some VMXGSUM invocations require KEEPALL=NO
to prevent VARIABLE NOT FOUND errors:
With KEEPALL=NO, variables can be listed that don't
exist in the input dataset; both IBM and TMON vars are
listed in the dual-input ASUMCICS program, but only
one set will actually exist. With KEEPALL=YES, all
variables must exist. And with KEEPALL=NO, you can
still use ASUMDB2A to summarize DB2ACCT, even if you
have removed variables that you don't need, since the
KEEPALL=NO option tolerates non-existent variables.
By adding an explicit KEEPALL=YES in each VMXGSUM use in
member ANALCISH, and by adding an EXPLICIT KEEPALL=NO in
ASUMCICS/ASUMCICX, and by cleaning up variables in SUM=
lists that didn't belong there, all of MXG members in the
18.03 library have been tested with KEEPALL=YES as the
default, but I decided that it was not worth the exposure
of creating an error perfectly running programs to save a
few seconds of CPU time, so the MXG default remains
KEEPALL=NO.
But because KEEPALL=YES can be very useful in specific
cases, I have instead externalized KEEPALL to a Global
macro variable, so it can be changed from KEEPALL=NO with
%LET KEEPALL=YES;
in your //SYSIN before the program that invokes VMXGSUM,
so you can test the possible savings and any impact.
Note that if your program uses %VMXGSUM(KEEPALL=xxx,...),
i.e., explicitly specifies the KEEPALL= argument in its
invocation, that local xxx value will always override and
replace the Global value set with a %LET statement.
Thanks to Steve Colio, CIGNA, USA.
Change 18.064 MXG 18.01-18.02 only. Changes in the _Bdddddd "BY list"
VMAC6156 macros caused VARIABLE xxxxxxxx NOT FOUND errors:
VMAC64 -VMAC6156: VARIABLE SMF6XFNC NOT FOUND. Macro should be:
VMAC79 MACRO _BTY6156 SYSTEM READTIME JOB FUNCTION CATNAME
VMACGUTS ENTRNAME VOLSER1-VOLSER5 ACTION SMFTIME %
Apr 4, 2000 -VMAC64: VARIABLE SITUATN NOT FOUND. Macro should be:
MACRO _BTY64X SYSTEM READTIME JOB CATNAME ENTRNAME
COMPONT BEGCCHH VOLSER EXTENTNR SMFTIME %
-VMAC79: VARIABLE SYSPLEX NOT FOUND. Here the KEEP= for
dataset TYPE79F was incomplete; variables SYSPLEX
SYSNAME and STARTIME were added to its KEEP list.
-VMACGUTS: VARIABLE JOB NOT FOUND. Here the KEEP= for
datasets GUTSSESS and GUTSINTR was incomplete;
variable JOB was added to their KEEP lists.
Thanks to Richard S. Ralston, Whirlpool Corporation, USA.
Change 18.063 The count of CLASS3WT events typographically included the
ANALDB2R variable QWACAWTW, the wait duration, when it should have
Apr 4, 2000 been QWACARNW, the number of wait events, (three places).
Thanks to Tom Benson, Amdahl U.K., ENGLAND.
Change 18.062 New RMFINTRV parameters KEEPPGN/KEEPRPGN/KEEPSRV/KEEPRSRV
VMXGRMFI can be used to minimize the list of entries when you only
Apr 3, 2000 want to keep/drop a few PERFGRPs/SRVCLASSes.
Thanks to Normand Poitras, ISM, CANADA.
Change 18.061 The statement segment AND %LENGTH(&USERADD) NE 0
UTILBLDP was removed, because it could have caused no USERADD=
Apr 3, 2000 to be created when there should have been one.
Thanks to Dave Gibney, Washington State University, USA.
Change 18.060 Continued IMS quirk removal; Open Transaction Manager
ASMIMSL5 Access, OTMA, and APPC differences in LCODE=31x records
ASMIMSL6 were revised. While OTMA may have been only an IMS 5.1
Apr 3, 2000 facility, I put the code in both members while we await
an answer from IBM. We think OTMA is very rare in any
event, so this change should have no negative impacts!
Thanks to Pete Gain, SAS Institute, ENGLAND.
Thanks to Carl Meredith, SAS Institute ITSV, USA.
Change 18.059 -TPF support did not work with SAS USER= or WORK= options,
IMACTPF causing ERROR DATASET WORK.TPFTD NOT FOUND because the
TYPSTPF PROC COPY at the end of member TYPSTPF should have been
VMXGINIT removed when the _STPFxx PROC SORT macros were added.
VMXGTPFI -Hardcode "PDB." references were replaced with _Ldddddd
TESTUSER macro references in VMXGTPFI.
Apr 3, 2000 -VMXGINIT now defines WTPFINT and PTPFINT macro variable
for dataset TPFINTRV for consistency in naming.
-IMACTPF now documents the many TPF datasets/dddddd.
-VMACTPF had data set labels that were repeated/unclear.
-These were found by running TESTOTHR with their options.
-TESTUSER was also revised, with its one PROC COPY with
INDD=WORK being replaced with three separate PROC COPYs
each with INDD=&Wdddddd for the specific dataset to copy.
Thanks to Dr. Alexander Raeder, Karstat AG, GERMANY.
Thanks to Harmuth Beckmann, Karstat AG, GERMANY
Change 18.058 Zero observations were processed if you did not use the
PRINTNL MXGSAS procedure (or used the SAS procedure without the
Apr 1, 2000 CONFIG=MXG.SOURCLIB(CONFIG) parameter specified) because
the MXG macro variable OPSYS was tested instead of the
original SAS macro variable SYSSCP. Since nothing else
in CONFIG is required for PRINTNL, changing to use the
SAS macro variable SYSSCP eliminates the exposure so that
PRINTNL will work with the plane vanilla SAS JCL proc.
Thanks to Glenn Harper, Memorial Hermann Hospital System, USA.
Change 18.057 Variable PROCSTEP should not have been kept in TYPE30_1
VMAC30 or TYPE30_5, as it is a step-level variable, and it was
Apr 1, 2000 added to the KEEP= list for all TYPE30 datasets that
contained STEPNAME (except for TYPE30_D, because that is
a DD-level dataset, and adding PROCSTEP doesn't see to
be needed there and would only waste space (and you can
always use the MACRO _KTY30UD to add PROCSTEP if you
really decided you needed it at the DD-level dataset.
Thanks to Michael Oujesky, MBNA, USA.
Change 18.056 Support for CMA Release 1.11 (COMPATIBLE) added two new
VMACCMA variables, SMFT05PL and SMFT06PC to the subtype 5 and 6
Apr 1, 2000 SMF records.
Thanks to Dr. Alexander Raeder, Karstat AG, GERMANY.
Thanks to Harmuth Beckmann, Karstat AG, GERMANY
Change 18.055 OAM Release 1.5.0 changed the type 85 subtypes 74-77 and
VMAC85 subtypes 78-79 and 88 INCOMPATIBLY by inserting 32 bytes
Mar 31, 2000 (R85ORMN,R85OTMN) at the front of the segment, and by
Apr 10, 2000 inserting R85LXQT in the middle of the segment. Jobname,
stepname/procname were added to the OAM product segment
and those are now kept in all OAM data sets.
Apr 10: corrected tests for 1.4.0 to 150.
Subtypes 80-86 are not supported yet because I have no
test data, but MXG now prints a note if one of those
unsupported records are found, and I'll add support if
you'll send me your type 85s with those subtypes!
Thanks to Jeff Schuster, American Century, USA.
Change 18.054 The two PROC SORTs should have had _WTMSTMS and _WTMSDSN
TYPETMS5 instead of TMSRECS and DSNBREC, so that you could change
Mar 31, 2000 the location of the WORK copy. If you changed the ddname
you will get "TMS MERGE ERROR" message because MXG did
not use your changed destination.
Thanks to Dr. Alexander Raeder, Karstat AG, GERMANY.
Thanks to Harmuth Beckmann, Karstat AG, GERMANY
Change 18.053 The macro token _K102TX5 did not follow the _W102TX5
VMAC102 segment in the DATA statement; an oversight, but no
Mar 30, 2000 impact unless you wanted to change the variables kept.
Thanks to Jim Kovarik, AEGON USA, USA.
======Changes thru 18.052 were in MXG 18.02 dated Mar 29, 2000======
Change 18.052 IMS log record 01s are now deleted if MSGFLAGS '10'x bit
ASMIMSL5 is set (MSGFNRQU, the non-recoverable bit). Pete found
ASMIMSL6 duplicate IMSTRAN observations for some transactions that
Mar 29, 2000 were being submitted to the IMS input queue via the IMS
OTMA facility from an MQ series box. The non-recoverable
transaction exists merely to enter the message onto the
queue so that it can be requeued for execution. That
original (non-recoverable) 01 lacks critical identifiers
anyway, cannot be analyzed, and its processing is not
recorded in a type 7 record as a processed message, so
there is no loss by discarding that record.
The non-OTMA log records sequence all had the same DRRN:
01/35/08/56/31/03/35/37/7/33/56/07; the OTMA sequence was
01/35/08/56/31/03/31/33/56/37/33/56/07 records, but the
03/35/31/33 had one DRRN value, while the 01/31/33 had a
second DRRN generated by OTMA's processing, and it was
the second DRRN that created the "duplicate" transaction.
This change removed nine redundant XC USERKEY,USERKEY
statements in ASMIMSL5/ASMIMSL6 to make room for the four
new statements added to drop the unwanted records.
Thanks to Pete Gain, SAS Institute, ENGLAND.
Thanks to Carl Meredith, SAS Institute ITSV, USA.
Thanks to Pete Sadler, IBM, ENGLAND.
Change 18.051 IMF Fast Past records contain INPQUETM as a PD instead of
VMACCIMS the documented PIB format, affecting both INPQUETM and
Mar 28, 2000 ARRVTIME. CICS transactions with ARRVTEST='0000000C'x
are now included in the fast path calculation for the
ARRVTIME, although they are not strictly queueing.
Thanks to Stephen Hoar, Lloyds TSB ENGLAND.
Change 18.050 -IMS transactions with non-zero value for SUBQ6 time had
ASMIMSL6 the divide by NMSGPROC incorrectly located, causing the
JCLIMSL6 averaged resources (CPUTM, DLI, etc) to be incorrect.
IMACIMSA Fortunately, only one site has observed the problem. The
TYPEIMSA moved code had been added by Change 17.315 to cover the
TYPEIMSB rare case when FIRST.DTOKEN also has INIO and MTYPE='7 '
VMACIMSA because then, the averaging needed for Quick reschedule
Mar 28, 2000 transactions must be bypassed. (That change also added
Jun 5, 2001 IMSACCQ6, IMSSQ6TM and DLRUSSN to the list of variables
to be averaged.)
-Alan's changes that accommodate the 10-byte timestamps in
IMS 6.1 were incorporated in this change, and cosmetic
changes (colons to long vertical bars) were cleaned up.
-Note: error WORK.IMSMERGE.DATA DOES NOT EXIST occurs if
you try to copy an archaic IMACIMS member into your new
IMACIMSA member in your USERID.SOURCLIB. In general,
no tailoring of the IMACIMSA member is required for most
sites, and it is delivered with only comments.
-1Jun01: This change also changed the default in IMACIMSA
to IMSVERS 6.1 instead of 5.1, but that was not noted
in the original change text.
Thanks to Alan Green, Zurich, ENGLAND.
Thanks to Daniel Cannon, The Hartford, USA.
Thanks to John Pierce, Liberty Mutual, USA.
Thanks to Carl Meredith, SAS ITSV Cary, USA.
Thanks to Yves Terweduwe, CIPAL, BELGIUM.
Change 18.049 TYPE 74 subtype 4 "Broken RMF Record" Change 18.045 was
VMAC74 over-protective, falsely throwing away each last segment
Mar 26, 2000 with that error message. The test CDSILOC+SMF744CL GT
should have been CDSILOC+SMF744CL-1 GT LENGTH THEN DO;
Change 18.048 Cosmetic cleanup of MXG members. Sample PROC Prints in
CREATEBC ADOCxxxx members had non-text hex-values (like '00'x)
IMACEAGL that are now blanks, and the hex values in IMACEAGL and
VMACEAGL are replaced by hex literals. Some members had
DOC a small circle or a tiny "3" instead of the long vertical
Mar 25, 2000 bar for flow chart documentation inside comments (members
had been emailed from ASCII to EBCDIC with non-standard
conversion tables, particularly RHUMBA and/or European
ASCII to EBCDIC tables). The creation of MXG EBCDIC text
from ASCII text has not been documented previously, but
it uses the SAS ASCII to EBCDIC conversion, except that
two changes are required to the SAS ASCII to EBCDIC table
to match OS/390 TSO ISPF EDIT's characters:
Left Bracket - ASCII '5B'x EBCDIC 'BA'x
Right Bracket - ASCII '5D'x EBCDIC 'BB'x
Split Vertical - ASCII none EBCDIC '6A'x
New member CREATEBC is a ASCII SAS program that reads the
ASCII IEBUPDTE file to creates the MXG EBCDIC IEBUPDTE
file. The Variable length ASCII IEBUPDTE file is about
half the size of the fixed length EBCDIC 80-byte file.
The output of CREATEBC is a binary file that can be
written directly to a 3480 tape drive under ASCII, or the
EBCDIC file can be ftp'd into an RECFM=FB,LRECL=80 MVS
file which can then be directly read by PGM=IEBUPDTE to
create the MXG PDS Source Library under OS/390.
Change 18.047 Change 18.044 was still incomplete; variable STARTIME was
VMXGRMFI not reset after %VMXGDUR, so changes to _DURSET were
Mar 19, 2000 still not being applied until this (final!) revision.
======Changes thru 18.046 were in MXG 18.02 dated Mar 16, 2000======
Change 18.046 Variable RESPSTD was not created in this member, so it
TRNDCICX was inconsistent with TRNDCICS.
Mar 16, 2000
Thanks to Alan Deepe, Perot Systems Europe, ENGLAND.
Change 18.045 TYPE 74 subtype 4 "Broken Record" protection added in MXG
VMAC74 Change 17.378 did not protect when the number of segments
Mar 16, 2000 exceeded the count in the record, but now it does.
Thanks to Steve Lottich, University of Iowa Hospitals, USA.
Change 18.044 MXG 18.01-First 18.02. If you changed _DURSET, either
VMXGRMFI in IMACKEEP or with %LET MACKEEP= , it caused CPU TIMES
Mar 16, 2000 DO NOT MATCH ERROR. Relocate the IF &INTERVAL EQ DURSET
and following eight lines so they are after &INCODE72.
======Changes thru 18.043 were in MXG 18.02 dated Mar 15, 2000======
Change 18.043 Lotus Domino Server SMF type 108 variable DOMTMXSZ, the
VMAC108 Maximum Size of NSF Bufferpool, needs to be multiplied by
Mar 15, 2000 4096, as it is the number of 4096 byte frames.
Thanks to B. Brewer, Humana, USA.
Change 18.042 -This report fails under SAS V8 under OS/390 (but not with
ANAL30DD Windows) with APPARENT SYMBOLIC MAXRUN error because the
Mar 15, 2000 statement %LET MAXRUN=%EVAL(&MAXRUN); is invalid in open
SAS code, and should have caused a syntax error under V6
and under V8 under Windows, but didn't. If there was no
syntax error, the report ran fine, because MAXRUN is set
in the following statement, but the line is now deleted.
-The report example had 'B3'x instead of '7C'x in seven
places, causing a little 3 instead of a vertical bar to
be printed on these example reports.
Thanks to Edward J. Finnell, III, University of Alabama, USA
Change 18.041 ITSV 2.1 and 2.2 failed with CA1-TMS records, due to
VMACTMS5 hardcode TMS.TMS and TMS.DSNBRECD references, that are
TYPETMS5 now replaced with _LTMSTMS and _LTMSDSN tokens, which are
Mar 15, 2000 themselves redefined in VMACTMS5 now (they were not used
Apr 13, 2000 until now, so there is no compatibility issue) to be:
MACRO _LTMSTMS &PTMSTMS..TMS %
MACRO _LTMSDSN &PTMSTMS..DSNBRECD %
and in member VMXGINIT, the default value of PTMSTMS and
PTMSDSN was changed to "TMS" for both macro variables.
This change makes TMS processing consistent with the MXG
16.04 architecture. TMS records are initially written to
their two _Wdddddd tokens, and then sorted and combined
and output to the _Ldddddd tokens.
There was an additional ITSV fix required on top of this
MXG change for ITSV Release 2.2 and earlier (see ITSV
defect number S0079863), but the problem is corrected
in ITSV Release 2.3.
Thanks to Harald Seifert, HUK=COBURG, GERMANY.
Change 18.040 Support for GUTS, Gutenberg Time Sharing, user SMF
EXTYGUTI records. Two records are created, so two _ID macros are
EXTYGUTS defined, and either or both datasets will be populated.
IMACGUTS dddddd dataset description
TYPEGUTS TYGUTI GUTSINTR GUTS Interactive Execution Session
TYPSGUTS TYGUTS GUTSSESS GUTS Session
VMACGUTS
VMXGINIT
Mar 14, 2000
Thanks to Jeffrey Ball, Information Resources Inc, USA.
Change 18.039 Variable LOSU_SEC is now decoded from SMF30SUS, which
VMAC30 was added in OS/390 R2.6, and provides the Service Units
Mar 13, 2000 per second of CPU value for the SYSTEM on which his step
Mar 28, 2000 locally executed. Variable LOSU_SEC was added to dataset
TYPE30_V, TYPE30_4, TYPE30_5, and TYPE30_6.
Additionally, variables SMF30MSI and SMF30WMI were added;
those variables, new in OS/390 2.9, were documented in
MXG Change 17.385, but were not created until now.
March 28, 2000:
Variable SMF30SUS replaced SMF30TET, but SMF30TET has not
had any value so nothing is lost by its removal.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 18.038 Further enhancements now permit USECNTRL/USEREPRT to use
VMXGRMFI YES NO COMPAT GOAL SYS1 SYS1... to select control
UTILRMFI or report groups or classes for your workload definition.
Mar 15, 2000 All RPRTCLAS='N' were replaced with RPRTCLAS NE 'Y'
because RPRTCLAS is either Y or blank, and defaults work.
Thanks to Michael L. Kynch, International Paper, USA.
Change 18.037 %INCLUDE SOURCLIB(IMACJBCK) was added to VMACTMNT
VMACTMNT in case that job selection member is used for TYPETMNT
Mar 13, 2000 or TYPETALO selection.
Thanks to Chuck Hopf, MBNA, USA.
Change 18.036 Support for optional CICS RMI counters is added as an
IMACICUS example in using IMACICUS to decode user segments, and
Mar 13, 2000 the comments on how to use IMACICUS were updated.
Thanks to Bernie McGinnis, Charles Schwab, USA.
Thanks to Neil Ervin, Charles Schwab, USA.
Change 18.035 Invalid datetime values in VTCS 2.2 VTV Timestamp in VSM
VMACSTC subtypes 13,14,18,19 STCxxTIM variables. New 2.2 version
Mar 14, 2000 records have start/end variables in TODSTAMP8 format
Mar 16, 2000 ('B3B5488A226EE1C1'x) but have '38A8D15E000580C0'x for
VTV timestamp. Old 2.1 version records have all three as
valid seconds-since-1970 values '0000000038CD028F'x, so
the VTV timestamp was shifted left by four bytes, with
new flag variables in the low four bytes.
Because there is no version number in the STK records,
MXG's heuristic to detect VTCS Version 2.2 versus 2.1
did not expect this shifted value, causing STCxxTIM to
have a date in 1931 (or 1970 if value was zero). MXG's
algorithm to decode VTV STK timestamps is expanded to
Value greater than corresponds to input with
4294967295 FFFFFFFFF missing value
'B000------00'x 11Feb1998 TODSTAMP8.
'3800------00'x 10Oct1999 Left 4 PIB+DEL6070
'0000000038--'x All 8 PIB+DEL6070
I first tried IF X GT 0B000000000000000X syntax, but
doesn't work, and SAS Institute has accepted a bug in
both V6 and V8: you cannot use a 16-digit hexadecimal
constant literal value that starts with A or higher,
because the leading zero that is required (so that SAS
doesn't think it is a variable name) makes the string a
rejected 17 positions. SAS promises a fix in a future
release, but here I just used the decimal value for the
test:
X GT 4E18 for TODSTAMP, or
X GT 1.2E19 for shifted, or
otherwise input as unshifted PIB8.
If STK ever puts a version number in their record, this
heuristic will be removed.
The media size variables are now formatted MGBYTES and
the VPOs to HEX. See also Changes 17.195 and 17.332.
Mar 16: The low four bytes of VTV timestamp now create
STCxxSEQ, STCxxHID, STCxxVTI, and STCxxFLG for subtypes
13, 14, 18, and 19 thanks to STK documentation.
Change 18.034 Support for Oracle Version 7.3.3. INCOMPATIBLE. The SMF
VMACORAC record with CONNID=CICS have KERNNUM=0, but it should be
Mar 10, 2000 KERNNUM=1 because there is a valid Kernel segment in the
record. When KERNNUM=0, MXG does not read the kernel
segment, causing missing values for all kernel variables.
Now, MXG detects and corrects the Oracle error and will
read a Kernel segment even if the count field is wrong.
This error has been reported to Oracle.
An additional problem is being investigated: CPUTCBTM and
CPUSRBTM fields are zero with the 7.3.3 release, and so
far, Oracle has no knowledge of any change, but this text
will be updated when more is known.
Thanks to Yvonne McDonough, USDA NITC, USA.
Thanks to Leslie Arndt, USDA NITC, USA.
Change 18.033 Member ASUMTAPE was finally tested under ITSV and it too
ASUMTAPE contained hardcode references to PDB.xxxxxxxx that are
Mar 10, 2000 now changed to their &PDBMXG..xxxxxxxx symbolic names.
Change 18.032 Support for Netview NPM V2R5 changes and two MXG errors.
EX028INK -MXG error: VCD segment was not input for 'DC' or 'DE'.
EX028INL It would have helped if IBM and documented those subtypes
EX028INM in NPM 2.4 tables 73/74 or NPM 2.5 tables 80/81! Change
FORMATS to ELSE IF 0D0X LE NPMSUBTY LE 0DEX THEN COFTYPE='VCD';
IMAC28 -MXG error: VCS segment has two flavors, and the last 4
VMAC28 variables, VCSMAXFX/CURFX/MAXEC/CUREC are now input only
VMXGINIT if VCSVDTYP=2; MXG code was restructured for VCS segment.
Mar 10, 2000 -IBM error: APAR OW37758 for NPM 2.4 corrected error in
subtype DDx record, but that APAR is not included in the
NPM 2.5 release: new APAR AW43578 documents the error.
Change 16.336's circumvention still works to protect 2.5.
-New datasets from new subtypes:
Subtype Exit Dataset Description
14x 028INK NPMINNRT Router Interval
15x 028INL NPMINNRP Cisco Pool Interval
16x 028INM NPMINNIT Router Interface Interval
-The NCD and SCD segments' logic was revised to only input
the IP address for IP resource, and not input SLUNAME,
SLUPU, SLNKNAME and NPMNAME for IP resource type.
Thanks to Jerome Vitner, Experian Information Solutions, USA.
Thanks to Cendrine Pezier, ABS Technologies, FRANCE.
Change 18.031 Uninitialized variable messages for MROTRAN and DB2TRAN
ASUMUOW caused no actual problem, but they are now initialized in
Mar 9, 2000 the first DO; loop in the last DATA step.
Thanks to Freddie Arie, Texas Utilities, USA.
Change 18.030 IMS Log processing with APPC transactions caused negative
ASMIMSL5 SERVICTM and N+1 rather than N transactions per schedule.
ASMIMSL6 After label P031, after USING statement, insert:
Mar 9, 2000 TM QLGUFLGX,QLGUAPPC APPC?
BO DROPMAP SKIP APPC REDUNDANT 31
This has only been tested with IMS 5.1 data. If you have
APPC under IMS 6.1 and have validated this change, or if
you find any problems under IMS 6.1, please contact MXG.
Thanks to Kenneth D. Jones, ISM, CANADA.
Thanks to Carl Meredith, SAS Institute ITSV, USA.
Change 18.029 Variables were labeled, times were re-formatted and the
VMACMIM label (MS) was removed and fields divided by 1000 to put
Mar 3, 2000 durations in units of TIME13.3.
Mar 6, 2000 Mar 6: Uninit variable messages MIMCELL-MIMVCF were in
first 18.01, but had no impact. Variable MIMMPOS is now
labeled and variables MIMADTCR/MIMHDTCR/MIMATMCR/MIMHTMCR
are no longer kept
Thanks to Chris Weston, SAS Institute Cary, USA.
Change 18.028 Partition Data Report was updated for APAR OW37565, in
ANALRMFR the body of the Partition Report, where 'CP ' or 'ICF'
Mar 3, 2000 will be shown for Processor TYPE.
Mar 7, 2000 Mar 7: VMAC75 replaced VMAC71,VMAC77 in line 938.
Change 18.027 APAR OW41317 retrofits the OS/390 R2.9 multi-system
VMAC7072 enclave support (which added data fields in type 72)
Mar 3, 2000 back to OS/390 R2.7. Change 17.385, in MXG 17.17 and
later already supports those fields; this change is
only for documentation; no change was made.
Change 18.026 Support for APAR OW40414, which adds two four-byte fields
VMAC21 at the end of the record (i.e., compatibly) that replace
Mar 3, 2000 the existing two-byte fields for SIOCOUNT and BLKSIZE.
Mar 7, 2000
Change 18.025 If you did not put all SuperSession maintenance on, its
VMACNAF SMF record still contains CENT=39 instead of CENT=01
Mar 3, 2000 caused MXG's circumvention algorithm to be off by one
day. Remove the term (CENT-38)*86400 from each of the
datetime adjustments when CENT=39 and Y2K dates after
March 1, 2000 will be correct.
Thanks to Joe Faska, Depository Trust, USA.
Change 18.024 RACF SMF 80 INPUT STATEMENT EXCEEDED RECORD LENGTH error
VMAC80A in RACFTYPE=39 segment (PROGRAM NAMES, PERMIT). The line
Mar 3, 2000 SKIP=RACFDLNN=64-3 must be SKIP=RACFDLN-RACFDLNN-3;
Mar 9, 2000 Mar 9: The debugging PUT statement was deleted.
Mar 14, 2000 Mar14: Variables KW21AU04/05 and KW21GL04/05 formatted.
Change 18.023 SMF70CIN was reread from the same offset, and it should
VMAC7072 have been LENGTH $3 instead of $2, since it contains CP
Mar 3, 2000 or ICF. This error prevented ASUM70PR from recognizing
and removing ICF processors from the CEC capacity.
Change 18.022 Variable DURATM was added to those MIM datasets that
VMACMIM contained start and end time; it previously had been
Mar 3, 2000 kept only in the MIMTAPE dataset, but MXG intends to
keep DURATM in all interval datasets. Only the TYMIM2,
TYMIM4, and TYMIM6 are event datasets. Mar 6 note:
Uninitialized variables messages MIMCELL-MIMVCF are
created but have no impact; labels were removed.
======Changes thru 18.021 were in MXG 18.01 dated Mar 3, 2000======
Change 18.021 APAF Release 4.6 added a new field Series Name to the
VMACAPAF Pool segment, causing the second and subsequent pools'
Mar 1, 2000 data to be trashed. Insert
IF LENPOOL GE 36 THEN INPUT APAFSENM $EBCDIC16. @;
add APAFSENM='SERIES*NAME' to the LABEL, and to the KEEP=
list for dataset APAFPOOL, and then notice and correct
the _KAPAFLC to be _KAPAFPO for the APAFPOOL dataset.
The other APAF data sets appear to have been unchanged
by this release
Thanks to Art Cuneo, Health Care Service Corporation, USA.
Change 18.020 Using MACRO _Ldddddd to add (COMPRESS=YES) did not work,
VMXGDEL but revisions to this %VMXGDEL macro now supports that
Feb 29, 2000 syntax. I had not provided an option for compressing of
a sorted dataset, but redefining the dataset's _L macro:
MACRO _Ldddddd ddname.dataset (compress=yes) %
is now valid for compressing individual datasets.
VMXGDEL now uses PROC DATASETS MT=ALL so that if you
made a SAS dataset to be a SAS view, both will be deleted
Thanks to Alex Torben Nielsen, TeleDanmark EDB, DENMARK.
Thanks to Michael L. Kynch, International Paper, USA.
Change 18.019 The vendor of BETA93 writes non-Y2K-Ready date values in
VMACBETA the BETAJOBT SMFSTAMP8 value, with 00dddF format for Y2K
Mar 1, 2000 with no century bit turned on. The SMFSTAMP8 input was
broken into Time and Date pieces, the Date is now
protected with MXG's DATEJUL algorithm, and BETAJOBT is
then reconstructed from its (protected) pieces.
Thanks to Frank d'Hoine Nationale Bank van Belgie, BELGIUM.
Change 18.018 Variable JOBCLASS in datasets TYPE30xx, PDB.JOBS/STEPS
VMAC30 may be eight blanks, or may have only the first of JES3's
Feb 29, 2000 8-character job class, because IBM changed SMF30CLS, the
old one-byte job class field. Before IBM added SMF30CL8
in 1993, SMF30CLS was INPUT into the 1-byte MXG variable
JOBCLASS. In support for IBM's 8-byte SMF30CL8 field for
JES3, MXG increased JOBCLASS to 8-bytes, read SMF30CLS
into the first byte of JOBCLASS, then input SMF30CL8 into
variable JOBCLAS8, and used this logic to prevent a blank
JOBCLAS8 value from overriding a non-blank JOBCLASS:
IF JOBCLASS LE ' ' AND JOBCLAS8 GT ' '
THEN JOBCLASS=JOBCLAS8;
But now in JES2 R2.8 OS/390 records, SMF30CLS is blank
and SMF30CL8's first byte contains the JES2 jobclass, and
now in JES3 R1.3 OS/390 records, that 1-byte SMF30CLS
field that used to be blank is not blank, so the MXG
logic had to be changed to match the IBM Incompatibility:
IF JOBCLAS8 GT ' ' THEN JOBCLASS=JOBCLAS8;
Variable JOBCLASS is length 8 in TYPE30xx datasets built
by VMAC30 code (because I can't tell if a type 30 record
is from JES2 or JES3), and kept as length 8 in JES3's
BUILDPD3's datasets, but with JES2's BUILDPDB, I can
keep the variable JOBCLASS in only one byte.
Thanks to Allan Koch, Ford Motor Company, USA.
Thanks to Rich Anderson, SAS Institute Cary, USA.
Thanks to Ken Hansen, Exxon, USA.
Change 18.017 The UTILRMFI utility is used to examine any overlap of
UTILRMFI CPU time in your RMFINTRV workload definitions. It has
Feb 29, 2000 been updated to match the VMXGRMFI workloads, and uses
type 30 and type 72 records. See its comments for usage.
Change 18.016 Variable TYPEIOML was blank in dataset TYPE70 because of
VMAC7072 an extraneous line IF SMF70RAN THEN that should have
Feb 26, 2000 been deleted. Fortunately, TYPEIOML is always '3090' and
is unlikely to have been used in any reports!
Thanks to Bill Shanks, SEMA, UK.
Change 18.015 -INPUT EXCEEDED RECORD LENGTH error because the INPUT of
VMAC38 S38CUSER should have been $EBCDIC4. instead of $EBCDIC8.
Feb 25, 2000 -Additionally, TYPE38 failed if you tried to read the VSAM
SMF file because OFFSMF was not added to each offset
calculation.
Thanks to Kenneth D. Jones, ISM, CANADA.
Thanks to Harald Seifert, Huk-Coburg, GERMANY.
Change 18.014 SAS Version 7/8 only. Option CODEPASS=2 no longer exists
BUILD001 in SAS Version 7 or 8; it caused a warning message that
BUIL3001 had no other impact, and CODEPASS=2 itself had no impact
BUILDPDB on MXG, and was only specified to suppress a V6 message
BUILDPD3 that suggested you should try CODEPASS=2! Now it will be
Mar 1, 2000 specified only under SAS V6 execution.
Thanks to Mike Hoey, Ameren Services, USA.
Change 18.013 MXG 17.17 only. Running ASUMTALO under ITSV (or using the
ASUMTALO USER= option to send all of the datasets created during
Feb 25, 2000 ASUMTALO's execution to the same DDname) fails with error
V6: You cannot open WORK.TYPETALO.DATA for output access
with member level control because WORK.TYPETALO.DATA
is in use by resource environment SASEDSNX
V8: MEMBER lock is not available for WORK.TYPETALO.DATA
lock held by another user
because views and datasets of the same name cannot exist
in the same data library. The logic was revised and
temporary dataset/view names that do not conflict are now
used, and SPINTALO is no longer a view to avoid conflict.
Thanks to Sharon L. Nagy, Comerica, USA
Thanks to Robert K. Hare, Comerica, USA
Change 18.012 The calculation of RESPSTD (Std Deviation of Response)
TRND72GO did not protect for TRANS=0 before the divide by TRANS,
Feb 24, 2000 causing DIVIDE BY ZERO note on the log (but the dataset
created was still valid). Now divide is protected.
Thanks to Mike Hoey, Ameren Services, USA.
Change 18.011 The object SNA ADAPTER SnaDlc* caused Unknown Object
VMACNTSM message because MXG was expecting SnaDlc1 as the string.
Feb 24, 2000 The test was changed to SNADLC*, and the label of the
SNAADAPT dataset was also corrected.
-Variables DATABASE and APPLETLK appear in both LENGTH $32
and in INFORMAT 16.2 statements, but the SAS compiler did
not flag the inconsistency. Both were removed from the
numeric INFORMAT statement as they are indeed characters.
Thanks to Richard C. Clarke, Freemans PLC, ENGLAND
Change 18.010 Change 17.343 to ANALDSET causes error message "dataset
ANALDSET _NULL_ is not in the data statement". Change the DATA
Feb 19, 2000 statement and insert the needed _NULL_ so it reads:
DATA _VAR1415 _VAR30 _VAR64 _NULL_ _SMF _CDE1415 _CDE30 _CDE64;
Thanks to Ed Long, Fidelity Investments, USA.
Change 18.009 MXG 17.17 only. Using RMFINTRV under ITSV failed, or use
RMFINTRV of Report PGNs or Reporting Classes to define workloads
VMXGRMFI (either in your IMACWORK definitions, or in your
Feb 18, 2000 tailored %VMXGRMFI invocation your RMFINTRV member)
Feb 25, 2000 caused the error message "CPU TIMES DO NOT MATCH" on the
SAS log during creation of dataset PDB.RMFINTRV.
That error message occurs because either:
- you used the new DROPPGN= or DROPSRV= operands, which
didn't work correctly until this change to VMXGRMFI, or
- you didn't use those new operands, in which case there
was double accounting.
This change corrects VMXGRMFI logic for the new operands.
and now has six operands to make tailoring easier if you
want to use RPGNs/Reporting Classes to define workloads:
USEREPRT= Default NO, set to YES to permit Report PGN
or Reporting Classes to be used.
USECNTRL= Default YES, set to NO to delete all Control
PGNs or Service Classes. This is only used
if you want to use only Report PGN/Classes,
and you don't want to list all of them in the
DROPSRV= or DROPPGN= arguments.
DROPSRV = List of Service Classes to drop.
DROPPGN = List of Control Performance Groups to drop.
DROPRSRV= List of Reporting Classes to drop.
DROPRPGN= List of Report Performance Groups to drop.
To be able to use either Reporting Classes or Report PGNs
to define your workloads in dataset RMFINTRV, you MUST
use these new arguments in your member RMFINTRV's invoke
of VMXGRMFI to drop the Control PGN or Service Class
observations that correspond to the RPGN/Reporting Class
observations you want kept in your workloads, to avoid
double accounting and that error! You must also ensure
that every SUBSYS has a default Report PGN or Reporting
Class so that all work in the corresponding Control
Performance Group or Service Class is recorded in type 72
records.
-RMFINTRV failed when it was finally tested under ITSV
because it contained a hardcode OUTDATA=PDB.RMFINTRV,
in the actual %VMXGRMFI invocation in member RMFINTRV,
but ITSV expected the symbolic &PDBRMFI..RMFINTRV so
that ITSV could redirect to the WORK library. The real
bummer is that that OUTDATA= operand is not needed in the
actual invocation, and was added only as a documentation
example and reminder of the default output dataset name!
Remove that operand from the %VMXGRMFI invocation, and
the expected symbolic value will be used.
-This change also corrects an unrelated problem: when no
PERFGRP number was needed to be specified, a blank value
caused VMXGRMFI to fail. While using a bogus number like
9999 circumvented the problem, now a blank can be used,
but using a null value ( // ) fails. Use / / instead.
Thanks to Normand Poitras, ISM, CANADA.
Thanks to Jon G. Whitcomb, Great Lakes Higher Education Corp, USA.
Change 18.008 Variable NRSAMPLES is now kept in dataset TYPE7204; it is
VMAC7072 used to create several variables and should have been
Feb 17, 2000 kept.
Thanks to Frank Cortell, Credit Suisse Group, USA.
Change 18.007 SPIN logic was revised to correctly pick up class three
ASUMUOW wait times, and DB2ELAP (elapsed time in DB2) was added
Feb 29, 2000 to the final dataset. Previously, if a UOW was SPUN,
the DB2 Wait buckets and transaction counts were not put
in the record in the SPIN dataset.
Thanks to Brandon Persinger, The Gap, USA.
Thanks to Allan Winston, MBNA, USA.
Change 18.006 If the QAPMCONF configuration file has a start date of
VMACQAPM 02Sep99, records from this century will have dates in
Feb 16, 2000 year 1900 instead of year 2000. The QAPMCONF file must
match the century of the data you want to process, since
MXG gets AS400CC "Century" value from QAPMCONF.
However, you can circumvent the missing CC=1 value
in your QAPMCONF file by resetting the value of
the macro variable after you have invoked _TQAPCON:
%INCLUDE SOURCLIB(VMACQAPM);
_TQAPCON
%LET AS400CC=1; /*<<= insert to set cc=1 */
RUN; /*<<= insert to set cc=1 */
_TQAPSYS
etc...
Thanks to Kim Johnson, Bank of America, USA.
Change 18.005 There is an end-of-comment */ missing from the second
TRNDSMFI line of this trending example.
Feb 15, 2000
Thanks to Carl Kyonka, Enbridge Consumers Gas Company Ltd, CANADA.
Change 18.004 Type 79 subtype 15 IRLM Long Lock record has SMF79TRN=2
VMAC79 but there is no product section, so STARTIME, SYSPLEX,
Feb 17, 2000 DURATM and other product fields do not exist in TYPE79F.
Feb 22, 2000 In addition, the second triplet is SMF79ASS rather than
SMF79MCS, so the input logic for triplets was revised.
Finally, variables are now formatted to HEX when they do
not contain printable characters, and R79FTRNM is now
kept and labeled.
Note that this type 79 subtype 15 record replaces the
type 74 subtype 100 dataset that MXG creates in VMAC74.
That subtype 100 was a test version that doesn't exist.
Thanks to Johannes-Matthias Laveuve, DVG, GERMANY.
Thanks to Jurgen Scherwa, DVG, GERMANY.
Change 18.003 DB2 6.1 added Buffer Pools 100-109 (8K) and 120-129 (16K)
VMACDB2 and they cause "UNEXPECTED BUFFER POOL ID" messages to be
Feb 11, 2000 printed, because MXG did not know about .
Those new buffer pools are output in the detail by-pool
datasets DB2STATB and DB2ACCTB (although you have to have
removed the comment block in member EXDB2ACB to cause MXG
to create observations in DB2ACCTB), but the new pools
counts were not included in DB2ACCT or DB2STAT datasets.
In DB2ACCT/DB2STAT, MXG creates four sets of buffer pool
variables: QB1xxxx for BP zero, QB2xxxx for BP one,
QB3xxxx for all other 4K buffers, and QB4xxxx for all 32K
buffers. Rather than create yet another set of summary
counters for the 8K and 16K buffer pools, I have added
the 8K and 16K buffer counts to the QB4xxxx variables
in DB2ACCT and DB2STAT, since you can always retrieve the
individual buffer pool counts from DB2ACCTB/DB2STATB.
This change replaces the statement:
ELSE IF 80 LE QBACPID LE 80 THEN DO;
with
ELSE IF 80 LE QBACPID LE 89 OR 100 LE QBACPID LE 109
OR 120 LE QBACPID LE 129 THEN DO;
for DB2ACCT, and replaces this statement:
ELSE IF 80 LE QBSTPID LE 80 THEN DO;
with
ELSE IF 80 LE QBSTPID LE 89 OR 100 LE QBSTPID LE 109
OR 120 LE QBSTPID LE 129 THEN DO;
for dataset DB2STATS.
Thanks to Joachim Mayer, Amadeus Data Processing GmbH, GERMANY.
Change 18.002 Omegamon V500 records were deleted simply because the
VMACOMCI test for version number did not include V500. Add
Feb 7, 2000 AND FOCVER NE 'V500' and the records will be read.
Thanks to Peter Webber, CIS, UK.
Change 18.001 The _Bdddddd BY List macro was not sufficiently robust to
VMAC1415 remove all duplicates for some datasets, so the BY list
VMAC30 of variables has been revised so that you can PROC APPEND
VMAC42 to combine possibly duplicated data and then use the MXG
VMAC6156 _Sdddddd sort macro (which uses the revised _Bdddddd BY
VMAC64 list macro) to eliminate duplicates. However. there are
VMAC7072 four datasets that contain intrinsic duplicates; there
VMAC74 are repeated observations for the same set of BY vars
VMAC89 for the first four datasets listed (with asterisk) that
VMAC115 will require further research and discussion with IBM.
VMAC116 *MQMACCT _BTY116 now SYSTEM MQMSSSID QWHCAID
VMACACC QWHCCV QWHCCN SMFTIME
VMACTCP *TYPETCPA _BTYTCPA now SYSTEM APIJOBNM APISTART
Feb 18, 2000 APILCLPO APILCLPN APILOCAL
APIREMOT SMFTIME
*TYPE42DS _BTY42DS now SYSTEM STARTIME JOB READTIME
DSNAME DEVNR
*TYPE30MU _BTY30MU now READTIME JOB JESNR INITTIME
SUBTYPE PRODOWNR PRODNAME
PRODQUAL PRODID SMFTIME
TYPEACC _BTYACC now SYSTEM READTIME JOB SRHSTEPN
SRHDDN MESSAGE SMFTIME
MQMBUFER _BTY115B now SYSTEM MQMSSSID QPSTPOOL
SMFTIME
TYPE30OM _BTY30OM now READTIME JOB JESNR SUBTYPE
STEPNR SUBSTEP OMVSOPI
OMVSOUI OMVSOSI SMFTIME
TYPE892 _BTY892 now SYSPLEX SYSTEM PRODOWNR
PRODNAME PRODFEAT PRODID
PRODSTFL PRODREGS SMF89IST
SMFTIME
TYPE89 _BTY89 now SYSPLEX SYSTEM PRODOWNR
PRODNAME PRODQUAL PRODID
MULCUFG SMF89IST SMF89UST
SMFTIME
TYPE74SY _BTY74SY now SYSPLEX SYSTEM STARTIME
R742SNME R742SDIR R742STCN
SMFTIME
TYPE74ME _BTY74ME now SYSPLEX SYSTEM STARTIME
R742MSYS R742MGRP R742MMEM
SMFTIME
TYPE72SC _BTY72SC now SYSPLEX SYSTEM STARTIME
SRVCLASS R723SCSN R723SCSR
SMFTIME
TYPE64 _BTY64 now SYSTEM READTIME JOB CATNAME
ENTRNAME SITUATN COMPONT
DDNAME VOLSER1-VOLSER3
SMFTIME
TYPE6156 _BTY6156 now SYSTEM READTIME JOB SMF6XFNC
CATNAME ENTRNAME GENNO VERNO
VOLSER1-VOLSER5 SMFTIME
PDB.SMFINTRV _BTY30UV add SMFTIME DESCENDING INTBTIME
MULTIDD EXTRADD
TYPE1415 _BTY1415 now SYSTEM READTIME JOB OPENTIME
DDNAME DSNAME UCBSEGNR
SMFTIME
TYPE1718 _BTY1718 now SYSTEM READTIME JOB DSNAME
VOLSER NEWNAME SMFTIME
This is work still in progress; I need to formally open
a problem with IBM to discuss the duplicate records that
we've identified. This note updated 1Mar00.
Thanks to Abakah Nori, United Parcel Service, USA.
LASTCHANGE: Version 18.