COPYRIGHT (C) 1984-2023 MERRILL CONSULTANTS DALLAS TEXAS USA
MXG CHANGES 10.10
=========================member=CHANGE10================================
/* COPYRIGHT (C) 1984-1993 MERRILL CONSULTANTS DALLAS TEXAS USA */
This is the Production MXG Version 10.10, dated March 15, 1993.
Changes through:
Change 10.336 are included in MXG Version 10.10, Mar 15, 1993
Change 10.323 were printed in Newsletter TWENTY-THREE, Mar 15, 1993
Change 10.304 are included in MXG PreRelease 10.6, Feb 23, 1993
Change 10.265 are included in MXG PreRelease 10.5, Jan 28, 1993
Change 10.251 are included in MXG PreRelease 10.4, Jan 8, 1993
Change 10.241 are included in MXG PreRelease 10.3A, Dec 17, 1992
Change 10.235 are included in MXG PreRelease 10.3, Dec 13, 1992
Change 10.208 are included in MXG PreRelease 10.2, Oct 18, 1992
Change 10.199 were included in Early PreRelease 10.2, Oct 12, 1992
Change 10.113 were included in MXG PreRelease 10.1, Jul 10, 1992
Change 10.104 were printed in Newsletter TWENTY-TWO, Jul 10, 1992
Table of Contents:
I. MXG Software Status and Enhancements:
II. Incompatibilities, Installation, and Space Requirements.
III. Documentation of MXG Software.
IV. MXG Technical Notes - see NEWSLETTER TWENTY-THREE
V. MVS Technical Notes - see NEWSLETTER TWENTY-THREE
VI. VM Technical Notes - see NEWSLETTER TWENTY-THREE
VII. CICS Technical Notes - see NEWSLETTER TWENTY-THREE
VIII. SAS Technical Notes - see NEWSLETTER TWENTY-THREE
IX. Change Log
I. MXG Software Status and Enhancements:
MXG 10.10 is the Production Version of MXG 10 (i.e., the version that
we "Produce" for all sites), dated March 15, 1993.
MXG 10.10 is a major revision, with many latent enhancements, and near
transparent installation. Sites with normal MXG tailoring should need
less than 2 hours to unload, tailor, and submit the test jobstreams.
Make sure you read the COMPATIBILITY warning in Installation notes.
These enhancements are in MXG 10.10, but were not printed in the MXG
Technical Newsletter number TWENTY-THREE:
Note: There are 1965 members in MXG 10.10, not the 2000+ I thought
there would be. MXG now creates 47,292 variables in 1195 data
sets with its 533,759 lines of source code.
Support for type 30 OpenEdition/MVS measurements
NETSPY Average Host Response calculation corrected
Major enhancements added in MXG 10.10, that were not in MXG 10.6:
Support for OpenEdition MVS, OMVS, RMF record enhancements.
Preliminary RS6000 AIX VMSTAT,IOSTAT,PS command processing
GMT offset, GMTOFFTM, available in MVS/ESA 4.3 RMF records.
DCOLLECT options SMSDATA creates nine new SMS construct datasets.
RMF reports can be produced from MXG TYPE70xx datasets.
Additional online MXG documentation members (ADOC and ACHAP).
Major enhancements added in MXG 10.6, that were not in MXG 10.5:
Support for Empact's Hipercache SMF record.
Support for IMF Release 2.8.
Support for Oracle 6.0.33.1.51.
Support for IBM 3495 Tape Library Dataserver's type 94 SMF record.
Support for (incompatible) Omegamon/CICS DATACOM SPE PTF QOC0109.
Support for STOPX37 Release 3.5.
Support for Empact's POOL-DASD user SMF record.
Support for Candle's IMS Transaction Reporting Facility, ITRF.
Support for Landmark for CICS's Release 9 and Release 1.0.
IBM-like RMF reports can be created with new ANALRMFR.
Additional HOGAN application fields added in CICSTRAN
HP's MPE data or HP/UX Unix data are both supported by TYPEHPCS
SLR-like IMS processing for sites with heavy fast-path in TYPESLRI
Additional CMF "type 240" subtypes supported in TYPECMF
Major enhancements added in MXG 10.5, that were not in MXG 10.4:
Support for MVS/ESA 4.3 and RMF 4.3.
Support for NPM Release 1.6.
Support for NETSPY Release 4.3 and LANSPY 1.1.
Support for IDMS Release 12 PM records confirmed.
Major enhancements added in MXG 10.4, that were not in MXG 10.3:
Support for ESCOM Multi-Image Facility (EMIF)
Support for VM/ESA 2.0
Validation of support for Velocity Software's XAMAP History files.
Major enhancements added in MXG 10.3, that were not in MXG 10.2:
Support for NPM 1.5.1 incompatible changes.
Correction of MXG-10.2-only error in ASUM70PR
Support for DFSORT Release 12 new fields.
Cleanup of all reported errors in prior prereleases.
Toleration support for VM/ESA 2.0 MONWRITE data.
Major enhancements added in MXG 10.2:
Powerful new "_L" and "_K" macro architecture allows full tailoring
of MXG datasets (variables kept/dropped, compression, blocksize,
the DDNAME to which the dataset is written, etc.).
Support for DB2 Trace IFCID 172/ 177 added, Audit/SQL reports fixed.
Support for FACOM AIM Version 12 type 116 SMF record changes.
Support for FACOM PDLF Type 127 for MSP/EX.
Support for HP Unix (HP/UX) PCS Performance Collection System data
Support for IBM TCP/IP Version 2 Release 2 SMF record.
Support for IBM TIRS type 96 SMF record coded.
Support for Network Alert APAR OY49717 in SMF Type 37.
Support for OMEGAMON II for VTAM V150 user SMF record coded.
Support for OPC changes.
Support for SAP Accounting data in CICS type 110 or journal file.
Support for SIMWARE SIM/XFER VTAM user SMF record.
Support for TMS Billing-by-dataset using enhanced DSNBRECD dataset.
Support for VSE DOS POWER Version 4.2
Support for Xerox Printer's SFS Status File System records.
Support for XCOM 6.2 Version 2.2.2G SMF record.
Alert that Legent's MIM can corrupt MXG Tape Mount counting.
"Appended" IMS Log enhancements; has now been tested with IMS 2.2.
Continued enhancement of ANALDB2R for DB2 reports.
Major enhancements added in MXG 10.1 but not listed in Newsletter 22:
OPC/A log processing major revision, additional datasets created.
Verstand's product, TTX, is now included in MXG Software.
Support for AS400 V2R1M0 added, and AS400 support was revised.
NPM 1.5.1 subtypes 144-150 (NPMEVX25 dataset) errors were corrected.
Sample IEFU83 exit to filter type 40 records for tape-only added.
Major enhancements added in MXG 10.1 that were listed in NL 22:
Required for CICS/ESA 3.3,
Required for VM/ESA 1.1.1,
Required for TYPEIMS users; major revision in IMS log processing.
Strongly recommended for DB2 sites, because it:
- has significant corrections in ANALDB2R reporting,
- has speeded up MXG DB2 processing and reduced WORK space needed,
- allows DB2ACCT direct to tape for sites with large DB2 activity,
- has new ASUMDB2A to summarize and reduce size of DB2ACCT.
- has MVS Account fields added to DB2ACCT (DB2 2.3).
Offers support for these new products or releases:
Support for AICorp's KBMS user SMF record.
Support for Amdahl's APAF replacement for MDFTRACK.
Support for Blue Line's Vital Signs for VTAM type 28.
Support for Fujitsu's FACOM MSP/EX (incompatible) SMF records.
Support for MVS/ESA 4.2 Dynamic I/O Reconfig in MXG Tape Monitor.
Support for NETSPY Release 4.2 added.
Support for NETSPY Token-Ring records added.
Support for ROSCOE Release 5.7 changes to SMF data.
Support for RSD's WSF/WSF2 Release 3.4.1.
Support for SPMS 1.2.13 incompatible changes.
Support for STOPX37 Release 3.4.
Support for Software Ag "Natural Process" SMF record.
Support for System Center's NETMASTER type 37 SMF records.
Support for The Network Director North Ridge Software
Support for UNIX iostat and vmstat commands from ULTRIX.
ASMVTOC avoids 213/314 abends reading VTOC of TPF or VM volumes.
LPAR CPU utilization reports added.
MINTIME=,MAXTIME= parameters added to VMXGSUM.
MVS/ESA 4.2.0 changed format of DEVNR/UNITADR in TYPE75.
MXG Tape Mount Monitor supports MVS/ESA dynamic reconfiguration.
New dataset TYPE40_D can be created for tape analysis
TAPE3490 (3490s allocated) added to PDB.STEPS/JOBS.
Trending with INTERVAL=MONTH members added.
Each of these enhancements are described in the Change Log, below.
The following table lists announced availability dates for the IBM
product, and the corresponding Version of MXG required to support
that IBM product.
Availability MXG Version
Product Name Date Required
MVS/370, MVS/XA (all) long ago 8.8
RMF 4.1.2 (for MVS/ESA 3.1.3) Sep 7, 1990. 8.8
RMF 4.2 (for MVS/ESA 4.1) Oct 26, 1990. 8.8
MVS/ESA 4.1 Oct 26, 1990. 8.8
MVS/ESA 4.2 Mar 29, 1991. 9.9
RMF 4.2.1 (for MVS/ESA 4.2) Mar 29, 1991. 9.9
MVS/ESA 4.2.2 Aug 1991. 9.9
RMF 4.2.2 (for MVS/ESA 4.2.2 Aug 1991. 9.9
MVS/ESA 4.3 Mar 23 1993. 10.5
RMF 4.3.0 (for MVS/ESA 4.3 Mar 23 1993. 10.5
CICS/ESA 3.1 1990 8.8
CICS/ESA 3.2 Jun 28, 1991. 9.9
CICS/ESA 3.3 Mar 28, 1992. 10.1
DB2 2.2.0 1990 8.8
DB2 2.3.0 Oct 28, 1991. 10.1
VM/ESA 1.1.0 (370 Feature) Oct 26, 1990. 8.8
VM/ESA 1.1.0 (ESA Feature) Mar 29, 1991. 8.8
VM/ESA 1.1.1 Dec 27, 1991. 10.1
VM/ESA 2.0 Dec 23, 1992. 10.4
II. Incompatibilities, Installation, and Space Requirements.
1. Incompatibilities in MXG 10.10 which will cause syntax errors:
a. If these members exist in your USERID.SOURCLIB, then you must
replace them, by re-tailoring your changes starting with the
new MXG 10.10 member:
IMACCICS IMACCIMS IMACCMF IMACDB2 IMACDCOL IMACIMS
IMACINTV IMACMONI IMACNSPY IMACOPC IMACPDSM IMACROSC
IMACSTX IMACTPX IMACZRB IMAC30DD IMAC40DD IMAC434D
These members defined the DDNAME to which MXG sent certain
datasets (eg., MACRO _CICTRAN CICSTRAN % set the DDname for
DATA _CICTRAN.CICSTRAN). The new "_L" architecture provides
the same function with different syntax (eg., now the macro
_LCICTRN defines both the DDNAME (LIBREF) and dataset name).
Change 10.175 provides specific details of what old-names have
to be changed to what new-names for these incompatibly changed
members.
b. If you had tailored BUILDPDB/3 to create TYPETMNT (the MXG
Tape Mount Monitor records), you will need to remove your
tailoring in members EXPDBINC,EXPDBVAR,EXPDBCDE,EXPDBOUT.
In MXG 10.10 TYPETMNT is automatically created by BUILDPDB/3.
Sites migrating to MXG 10.10 from MXG 9.9 thru MXG 10.x should find
no other compatibility issues.
Sites migrating to 10.10 from an MXG version earlier than 9.9 must
read the compatibility section of the installation instructions in
MXG Newsletter TWENTY-ONE (also in member NEWSLTRS).
MXG 10.10 will still execute under SAS 5.18, but this is likely to
be the last version that will fully work under that archaic version
of SAS; MXG intends to begin to exploit Version 6 features in MXG
future versions, and we strongly recommend use of SAS 6.07 or later!
2. Installation and re-installation procedures are described in detail
in member INSTALL, but they are summarized here:
a. Install member MXGSAS as JCL Procedure MXGSAS in your PROCLIB.
b. Allocate a 70-cyl PDS: MXG.V1010.MXG.SOURCLIB, & use IEBUPDTE
to read the MXG tape to create the 1800+ member Source Library.
c. Allocate a 1-cyl PDS: MXG.V1010.USERID.SOURCLIB for your site
"Installation Tailoring" Source Library. Installation specific
tailoring (like telling MXG your shift hours, which performance
groups are TSO, CICS, etc.) is done by copying and modifying MXG
source members into V1010.USERID.SOURCLIB.
d. Allocate a 1-cyl SAS Data Library: MXG.V1010.MXG.FORMATS and
execute SAS to create the library of Formats required by MXG.
Sample JCL for the above three steps is in member JCLINSTL.
e. If re-installing MXG, copy your existing USERID.SOURCLIB library
members into the MXG.V1010.USERID.SOURCLIB. Then examine the set
of IMACs that were changed incompatibly (see member CHANGES).
If any members in MXG.V1010.USERID.SOURCLIB are in that list,
you must reinstall your site's tailoring for that IMAC, starting
with the IMAC member from the MXG 10.10 Source Library.
e. If this is the initial install of MXG, tailor these members into
your MXG.V1010.USERID.SOURCLIB tailoring library:
IMACACCT (Account Length),
IMACSHFT (Shift Definitions),
IMACWORK (Performance Group to Workload mapping), and
IMACSPIN (for BUILDPDB).
Each IMAC member is self-documenting, and IMACAAAA is the index
of all of the IMACs. You should at least scan IMACAAAA to see
the acronyms MXG uses for the many products MXG supports.
f. EDIT and submit member JCLTEST6 (JCLTEST if still on SAS 5.18)
to verify that your tailoring did not create any errors.
g. EDIT and submit JCLPDB to create a Daily PDB for testing. Or
use the TYPE.... members to process specific data sources, use
the ANAL.... members for report examples, the GRAF.... members
for SAS/GRAPH reports.
You have now installed MXG 10.10 in its own set of libraries. When
parallel testing is complete and are ready to implement MXG 10.10
in production, rename your three current MXG Production Libraries
(MXG.MXG.SOURCLIB, MXG.USERID.SOURCLIB, and MXG.MXG.FORMATS) to
(MXG.BACK.MXG.SOURCLIB, MXG.BACK.USERID.SOURCLIB, MXG.BACK.MXG....)
and rename the MXG.V1010.x.y libraries to their Production names!
Again, detailed installation instructions are in member INSTALL
Always read comments in the CHANGES member for compatibility issues, as
well as for any last minute changes.
Whenever you install changes or test a new version of MXG (or even your
own reports), be extra careful to look on the SAS log for any real error
conditions. Search for all occurrences of "ERROR:" and "ERROR :" and
"UNINITIALIZED" and "NOT CATLGD", as they may indicate a serious error.
A PROC PRINT and a PROC MEANS of each new MXG-built SAS dataset can help
you to understand their contents, and should be used to examine any
unusually large, negative, or suspicious values. Print all variables in
the dataset, and read the variable's descriptions in its ADOC member.
III. Documentation of MXG Software.
Member CHANGES always contains the version number of MXG Software, and
it lists changes that were installed in that version. Members named
Changenn are the CHANGES member from MXG Version "nn". Each change in
MXG software is documented by a Change number and text. The text of
each Change identifies the member(s) that were added or altered.
Documentation (especially for new product's support) is often
also found in comments at the beginning of those members listed in the
Change entry. The CHANGE member is designed to be read online (with SPF
BROWSE); you can search for specific product name references (CICS,
MVS/ESA, etc.), or the MXG member name.
Member NEWSLTRS contains the text of all newsletters (up through the
newsletter that accompanied that MXG release). You can search NEWSLTRS
for product name or acronym to find the technical notes, APARs, etc.
from all MXG newsletters. The Change Log pages of each Newsletter are
in member CHANGES or CHANGEnn and are not repeated in member NEWSLTRS.
Member DOCVER lists alphabetically ALL datasets and variables that can
be build by this MXG Software Version. "Delta-documentation" between
MXG versions, which lists only those datasets and variables that were
Changed by version "nn" is found in DOCVERnn members for each version.
Chapter FORTY in the MXG Guide and MXG Supplement books are still the
primary documentation of MXG datasets and their variables (at least for
those data sources that existed in 1987!). This should be the first
place you look for information about MXG variables and/or datasets.
As each section of chapter FORTY is rewritten, it becomes an ADOCxxxx
member of MXG.SOURCLIB, providing online documentation for product xxxx.
ADOCs contain alphabetic descriptions of datasets and variables, the
instructions on how to enable that product, bibliography to the vendor
documentation, sample PROC PRINT and PROC MEANS of real data, and the
MXG member names that you use to process that product, etc. Sounds
great? It will be when finished - this is work in progress!
Beginning with MXG 10.3, there has been an IMACxxxx member for every
product supported by MXG. Once you know the xxxx suffix for a product,
you then know the names of all of the MXG members for that product:
IMACxxxx - Defines record IDs, and "_K,_L" macros for product xxxx.
ADOCxxxx - "Chapter FORTY" style dataset and variable documentation.
VMACxxxx - The "real" code member, often documentation in comments.
TYPExxxx - Standalone member to test or process product xxxx records.
ASUMxxxx - Summarization example (only for some products)
TRNDxxxx - Trending example (only for some products)
ANALxxxx - Reporting/analysis example (only for some products)
GRAFxxxx - SAS/GRAPH report example (only for some products)
EXyyyzzz - OUTPUT exit for each dataset. There can be more than one
dataset per product. The EX member name suffix yyyzzz is
the same as the suffix of "_L" and "_K" macros defined in
IMACxxxx for the product. See further discussion under
"Using the MXG Exit Facilities".
Member IMACAAAA is an index of all IMACs, and is the best place to
begin to find what xxxx suffix Merrill chose for which product!
You can often find additional documentation by searching members
NEWSLTRS, CHANGES, and the CHANGEnn members for the xxxx suffix.
Finally, remember that MXG is source code, so you can often find your
answer by BROWSE/EDIT of the source member, especially the VMACs that
actually create the data set, or ANALs that analyze the MXG data sets.
In most cases, the MXG Variable name is the IBM or Vendor's field or
DSECT field name. In other cases, the DSECT field name is carried as a
comment beside in the MXG INPUT statement to map field name to MXG's
variable name. MXG does expect that you will also have access to the
vendor's documentation of the data records you are processing.
The MXG Technical Newsletter is published aperiodically, one copy per
licensed site, and describes changes and enhancements to the software,
provides APARs and PTFs affecting MXG users, and provides tutorial
information of interest to MXG users.
IX. Change 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 of the MXG SOURCLIB will always be more accurate than
the printed changes in a Newsletter, because the software is created
after the newsletter is sent to the printer!
Member CHANGES always identifies the actual version and release of
MXG Software that is contained in that library.
The actual code implementation of some changes in MXG SOURCLIB may be
different that described in the change text (which might have printed
only the critical part of the correction that can be made by paper).
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.
Alphabetic INDEX of significant changes in MXG 10.10 (since MXG 9.9):
Member Change Description
All 10.175 Powerful new "_L" and "_K" macros tailor MXG datasets
All 10.261 Support for MVS/ESA 4.3.
ADOCAAAA 10.332 Seventy-Three ADOCs documentation members now exist.
ANALDB2R 10.001 DB2 Report truncated character values.
ANALDB2R 10.034 SORTBY= operand parsed only the first SORT variable.
ANALDB2R 10.046 LIBRARY SMF IS NOT VALID message with PMSQL04 report.
ANALDB2R 10.047 DBID/OBID hex values printed instead of name.
ANALDB2R 10.055 Date/time selection in PMSACC01/02 produced no report
ANALDB2R 10.094 ANALDB2R Accounting report uses ASUMDB2A if exists.
ANALDB2R 10.135 DB2 Audit report may not be produced.
ANALDB2R 10.158 DB2 SQL Trace report FORMAT NOT FOUND error.
ANALDB2R 10.272 Buffer Pool statistics average values wrong.
ANALDSET 10.097 VSAM data sets may have wrong PROGRAM name.
ANALMONI 10.066 TMON/CICS sample report filled WORK file.
ANALRMFR 10.301 IBM-formatted RMF reports are now produced by MXG.
ANALRMFR 10.301 IBM's RMF reports produced from MXG datasets.
ASMIMSLG 10.084 Major revision in IMS log processing algorithms.
ASMIMSLG 10.142 Revision to "Appended" IMS log processing.
ASMIMSLG 10.191 "Appended" IMS process might miss RACF segment
ASMISMLG 10.146 New "Appended" IMS log processing works with IMS 2.2.
ASMTMNT 10.012 MXG Tape Mount Monitor supports Dynamic I/O Reconfig.
ASMTMNT 10.136 (MXG 10.1 only). ABEND S55F at startup.
ASMTMNT 10.226 MXG Tape Monitor sets TMNTRTRN=3 for MIM event.
ASMTMNTO 10.177 MXG Tape Mount Monitor for sites still on MVS/XA.
ASMVTOC 10.073 Avoid 213/314 abends reading VTOC of VM/TPF volumes
ASMVTOC 10.157 (MXG 10.1 only). Assembler error MSGAREA.
ASMVTOC 10.202 Use ASMVTOCO for ASMVTOC under MVS/ESA 3.1.3.
ASMVVDS 10.156 ASMVVDS fails with User 666 Abend.
ASUMDB2A 10.090 DB2 Account "transactions" summarized into ASUMDB2A.
ASUM70PR 10.131 PR/SM,MDF,MLPF summarization now supports 16 LPARs.
ASUM70PR 10.218 MXG 10.2 only, corrupted Effective/Management times.
ASUM70PR 10.284 Amdahl MDF LPARNUM=0 now supported, for 17 LPARs.
ASUM70PR 10.335 PCTOFHDW busy in this partition added to RMFINTRV.
BUILDPDB 10.117 BUILDPDB under SAS 6.07 needs changes.
BUILDPDB 10.129 Execution under CMS requires changes.
BUILDPDB 10.153 Step account variable SACCT1 now added to PDB.
BUILDPDB 10.190 JES APAR OY56235 filling SPIN library circumvention.
BUILDPDB 10.298 TOTLINES added to PDB.PRINT dataset.
CMS 10.129 SAS 6.07 under CMS has problems for MXG.
CONFIG07 10.109 Option S=72, s2=72 added to MXG Config members.
EXCICJRN 10.132 New exit for CICS journal data sent to SMF.
EXTY72 10.064 CPURCTTM PTF now exists, circumvention removed.
GRAFxxxx 10.227 SAS 6.07 replaced XSWISS font name with SWISS.
GRAFDB2 10.151 Not all DB2 graphs were produced.
GRAFLPAR 10.052 LPAR CPU utilization reports added.
GRAFTRND 10.049 Graphic trending reports were not always correct.
IMACACCT 10.119 Invalid type 30 subtype 1 SMF caused INPUT STATEMENT.
IMACDB2 10.149 CORRNAME/CORRNUM set from QWHCATYP now.
IMACDOS 10.168 Support for VSE DOS POWER Version 4.2 account records
IMACFACO 10.100 Fujitsu's FACOM MSP/EX SMF records now supported.
IMACFMTS 10.173 Member made archaic by SAS 6.07 FMTSEARCH option.
IMACICSA 10.164 Support for SAP Accounting data in CICS type 110.
IMACICUS 10.297 Optional HOGAN application variables in CICSTRAN.
IMACPDB 10.053 New macro _DB2ACCT added. Compatibility exposure.
IMACPDB 10.068 TAPE3490 (3490s allocated) added to PDB.STEPS/JOBS.
IMACPDB 10.133 PDB.JOBS can have JELPSTM missing when it should not.
JCLPDB6 10.127 (MXG 10.1 only) JCLPDB6 fails, TYPETMNT not found.
JCLTEST6 10.030 INVALID DATA FOR SMFTIME, SAS zap MV313550 required.
MNTH.... 10.091 Trending with INTERVAL=MONTH members added.
MONTHBLD 10.206 All JCLPDB6 PDB & ASUM.... datasets are in MONTHBLD.
MXGSAS 10.336 Example JCL Procedure MXGSAS now provided
READDB2 10.045 TRACECLS= parameter does not select all IFCIDs.
RMFINTRV 10.299 Additional statistics added to RMFINTRV dataset.
TRNDDB2A 10.093 TRNDDB2A Account Trending uses ASUMDB2A if exists.
TTXPDS 10.111 Verstand's TTX product is now included in MXG.
TYPEAICO 10.048 Support for AICorp's KBMS user SMF record.
TYPEAIM6 10.161 Support for FACOM's AIM Version 12 type 116 SMF.
TYPEAPAF 10.078 Support for Amdahl's APAF replacement for MDFTRACK.
TYPEAPAF 10.143 Variable Balance not kept in APAFDOMA
TYPEASTX 10.245 Support for Legent's ASTEX Trace Record
TYPECIMS 10.063 IMF flag variables wrong if multiple bits are on.
TYPECMF 10.230 Boole's CMF variable R783PT in error.
TYPECMF 10.292 Support for IMF Release 2.8.
TYPECTLD 10.327 CONTROL-D Release 2.0.0 is also supported.
TYPECTLD 10.327 CONTROL-D Release 2.0.0 is supported.
TYPEDB2 10.024 MVS Account fields added to DB2ACCT!
TYPEDB2 10.333 DB2ACCT fields ACCOUNTn were not input.
TYPEDB2 10.333 MVS Account fields now are actually input to DB2ACCT!
TYPEDCOL 10.071 INVALID VALUE FOR FUNCTION DATEJUL message.
TYPEDCOL 10.148 DCOLBKUP variables UBALLSP,UBUSESP,UBRECSP wrong.
TYPEDCOL 10.221 DCOLLECT variable UCTOTAL was incorrectly documented.
TYPEDCOL 10.307 DCOLLECT SMSDATA writes SMF constructs records.
TYPEFOCU 10.334 FOCUS record caused INPUT STATEMENT EXCEEDED error
TYPEFTP 10.176 NETVIEW FTP SMF record timestamps reversed.
TYPEF127 10.162 Support for FACOM PDLF Type 127 for MSP/EX Version.
TYPEHIPR 10.300 Support for Empact's HiperCache SMF records.
TYPEHPCS 10.178 Support for HP Unix (HP/UX) PCS Performance Data.
TYPEHPCS 10.294 HP's MPE operating system records now supported.
TYPEHSM 10.080 FSTTRKR/W large values are actually negative values.
TYPEIDMS 10.219 IDMS variable DBKDBKEY was incorrectly documented.
TYPEIDMS 10.265 Support for IDMS Release 12 PM records confirmed.
TYPEILKA 10.121 Invalid data because incorrect offset/documentation.
TYPEIMSA 10.142 STRTTIME/ENDTIME/INPQUETM/SERVICETM/RESPNSTM wrong.
TYPEIMSA 10.205 NMSGPROC value wrong. Must use ASMIMSLG for IMS log.
TYPEIMSA 10.288 Zero service time corrected.
TYPEITRF 10.273 Support for Candle's IMS Trans Report Facility,ITRF.
TYPEMON8 10.020 Landmark CICS "INVALID OFFSETS" message.
TYPEMON8 10.067 MONITASK variables STRTTIME/CREATIME now equal.
TYPEMON8 10.145 Landmark CICS variable TAMRCNT input incorrectly.
TYPEMON8 10.271 Support for Landmark's/CICS Release 9 and Release 1.
TYPEM204 10.120 MODEL204 variable M24IODEV input, EXM24ACT eliminated
TYPENATP 10.033 Support for Software Ag "Natural Process" SMF record.
TYPENETP 10.039 NETPACTM was total response, should be average.
TYPENRS 10.075 Support for The Network Director North Ridge Software
TYPENSPY 10.015 Support for NETSPY Token-Ring records added.
TYPENSPY 10.057 Support for NETSPY Release 4.2 added.
TYPENSPY 10.144 NETSPY type 'N' records cause INPUT STATEMENT EXCEED.
TYPENSPY 10.262 Support for NETSPY Release 4.3 and LANSPY 1.1
TYPENSPY 10.326 NETSPY AHOSTRSP calculation corrected.
TYPEOMCI 10.182 Omegamon V550 ESRA (user) SMF "INPUT EXCEEDED".
TYPEOMVT 10.194 Support for OMEGAMON II for VTAM V150 user SMF.
TYPEOPC 10.112 Major revision for OPC/A log processing.
TYPEOPC 10.204 Support for Changes to OPC records.
TYPEOPC 10.302 RECFM= parameter removed so RECFM=U data can be read.
TYPEORAC 10.291 Support for Oracle 6.0.33.1.51.
TYPEPOOL 10.274 Support for Empact's POOL-DASD user SMF record.
TYPEQAPM 10.110 Support for AS400 V2R1M0 and restructured members.
TYPERMDS 10.102 RMDS messages INVALID DATA FOR RMDSMXVR eliminated.
TYPEROSC 10.022 Support for ROSCOE Release 5.7 changes to SMF data.
TYPEROSC 10.101 ROSCOE ADSFUN.. variables values corrected.
TYPEROSC 10.138 ROSCOE JCK and Documentview added to ROSCOVPE.
TYPERSxx 10.319 Support for RS6000 AIX VMSTAT,IOSTAT,PS commands.
TYPESFS 10.186 Support for XEROX Printer's SFS Status File System.
TYPESIM 10.180 Support for SIMWARE SIM/XFER VTAM user SMF record.
TYPESIM 10.222 SIMWARE initial support revised.
TYPESLRI 10.290 SLR-like IMS log processing for Fast Path.
TYPESMF 10.019 Header/Trailer messages on log were not always right.
TYPESPMS 10.011 SPMS R2.1.4 invalid record circumvented.
TYPESPMS 10.069 SPMS 1.2.13 inserted four byte field, causing errors
TYPESTC 10.105 STC 4400 decode used wrong bits of STC07TYP.
TYPESTC 10.116 STC4400 HSC SMF record for Release 1.2 incompatible.
TYPESTC 10.193 STC 4400 Silo HSC variables formatted.
TYPESTC 10.229 STC 4400 variables LSBECON1/2 incorrectly documented.
TYPESYNC 10.115 SYNCSORT variable COREREQ can be negative.
TYPETCP 10.184 Support for IBM's TCP/IP Version 2 Release 2 SMF.
TYPETIRS 10.181 Support for IBM type 96 SMF record from TIRS.
TYPETMNT 10.200 Legent's MIM corrupts MXGTMNT Tape Mount count.
TYPETMS5 10.060 TMS inactive DSNBs now deleted, caused wrong VOLSER.
TYPETMS5 10.082 TMS.TMS had DSNB fields, TAPEFEET calculation changed
TYPETMS5 10.185 DSNBs could have been skipped.
TYPETMS5 10.196 TMS Billing-by-dataset enhanced in DSNBRECD dataset.
TYPETMS5 10.289 "Dead" tapes no longer create DSNBRECD observation.
TYPETMVS 10.058 TMON/MVS "INVALID DATA for WKLCPURF" message.
TYPETPX 10.007 TPX variable TPXELAP has wrong value.
TYPEVM 10.233 VMSQLxxx datasets enhanced for SQL/DS under VM.
TYPEVMXA 10.036 VM/ESA 1.1.1 additions now supported.
TYPEVMXA 10.071 VM/ESA VXSYTCUP dataset has only 49 observations.
TYPEVMXA 10.163 Candle's VCOLLECT 5.1.0 still writes invalid "VVBs".
TYPEVMXA 10.244 Support for VM/ESA Release 2.0.
TYPEWSF 10.081 Support for RSD's WSF/WSF2 Release 3.4.1.
TYPEWSF 10.150 WSF 3.3.6 caused error (no problem with 3.4.1).
TYPEXAM 10.231 Support for Velocity Software's XAMAP History files.
TYPEXCOM 10.165 Support for XCOM 6.2 Version 2.2.2G SMF record.
TYPEX37 10.013 STOPX37 Release 3.4 is supported.
TYPEX37 10.276 Support for Empact's STOPX37 Release 3.5.
TYPE102 10.072 DB2 SQLCODE can be negative, MXG read as positive.
TYPE102 10.170 DB2 Trace IFCID 172 and 177 now tested and supported.
TYPE102 10.174 DB2 optimizer's cost estimate was incorrect.
TYPE102 10.183 DB2 Trace statement Numbers now print as decimals.
TYPE102 10.281 DB2 T102S044 lock fields were incorrect.
TYPE110 10.017 Invalid type 110 subtype 2 could cause MXG to loop.
TYPE110 10.038 Omegamon error causes INVALID DATA FOR SMFPSRSN.
TYPE110 10.059 Type 110 STOPOVER due to bad record eliminated.
TYPE110 10.061 Support for CICS/ESA 3.3.0 monitor (CICSTRAN) data.
TYPE110 10.062 Support for CICS/ESA 3.3.0 statistics datasets.
TYPE110 10.234 Enhanced CICS error messages for EXCLUDE/INCLUDE.
TYPE110 10.278 OMEGAMON/CICS V550 DATACOM SPE is incompatible.
TYPE110 10.280 Fourth TCBs CPU time was not included in CICINTRV.
TYPE24 10.037 Spool off-load type 24 can cause STOPOVER abend.
TYPE28 10.095 Blue Line's Vital Signs for VTAM type 28 supported.
TYPE28 10.106 NPM 1.5.1 NPMEVX25 (subtypes 144-150) error fixed.
TYPE28 10.134 Line PCTBUSY in each direction measured separately.
TYPE28 10.141 (MXG 10.1 only). INVALID DATA FOR NPMPDUTH.
TYPE28 10.155 NPM variables LLBSSTIM/LLBSPTIM incorrect.
TYPE28 10.264 Support for NPM Release 1.6
TYPE30 10.031 Variables ACTDLYTM, RESDLYTM, DSPDLYTM created.
TYPE30 10.108 Some APPC variables in TYPE30 have wrong value.
TYPE30 10.325 Support for OpenEdition/MVS type 30 enhancements.
TYPE30OM 10.325 Type 30 support for OpenEdition/MVS
TYPE33 10.232 Error in processing SMF type 33 (APPC) records.
TYPE37 10.098 System Center's NETMASTER type 37 SMF record support.
TYPE37 10.167 Support for Type 37 Network Alert APAR OY49717.
TYPE39 10.040 INPUT STATEMENT EXCEEDED for subtype 5.
TYPE40 10.065 New dataset TYPE40_D can be created for tape analysis
TYPE41 10.015 DIV type 41 SMF record timestamps misdocumented.
TYPE42 10.005 Type 42 SMF record causes STOPOVER ABEND.
TYPE6 10.003 PSF type 6 record had FORM truncated.
TYPE6 10.124 Incompatible change to type 6 SMF record by PSF.
TYPE6 10.139 PRUWTR type 6 SMF record has incorrect READTIME.
TYPE6156 10.255 VSAM Data and Index component names & SMS data added.
TYPE70 10.256 TCP/IP SMF record defaults to type 70!
TYPE70 10.260 Negative CPUACTTM/PCTCPUBY in TYPE70 with PR/SM/
TYPE70x 10.320 Support for OpenEdition MVS, OMVS, RMF records.
TYPE7072 10.010 TYPE70PR variable NRPRCS corrected.
TYPE7072 10.042 PCTRDYWT variable now created.
TYPE7072 10.317 GMT Offset, GMTOFFTM, available in MVS/ESA 4.3.
TYPE71 10.014 SWAP counts corrected.
TYPE73 10.179 ESCON converter flag variable ESCACVC not set.
TYPE73 10.247 MVS/ESA 4.2.2 EMIF Feature corrupts TYPE73 data set.
TYPE73 10.259 Only real channels create TYPE73 observations now.
TYPE74 10.137 MVS/ESA XCF Type 74 causes INPUT STATEMENT EXCEEDED.
TYPE75 10.099 MVS/ESA 4.2.0 changed format of DEVNR/UNITADR.
TYPE78 10.201 CMF Type 78 incorrect R783CPDN value causes 0 obs.
TYPE79 10.123 Type 79 subtype 1 corrections.
TYPE79 10.283 RMF 79 records appear to be un-deaccumulatable.
TYPE80 10.114 CA TOP SECRET caused INPUT STATEMENT EXCEEDED error.
TYPE80A 10.251 RACF events consolidated in new TYPE80A dataset.
TYPE84 10.224 JES3 type 84 INPUT STATEMENT EXCEEDED error.
TYPE94 10.285 Support for IBM 3495 Tape Library Dataserver SMF.
VMXGHSM 10.254 HSM dates TTOCDLR and TTOCXPDT were wrong.
VMXGSUM 10.089 MINTIME=,MAXTIME= parameters added to VMXGSUM.
VMXGVTOC 10.018 CRITICAL ERROR IN VTOC if DSORG=PS-SUL data found.
VMXGVTOC 10.054 ISAM index space not recognized in VTOC.
VMXGVTOC 10.243 SAS 6.07 ZAP V6-SYS-FILE-4673 required.
VMXGVTOF 10.125 Variable DS4VTOCE input but not kept.
VMXGVTOF 10.171 VTOCs with freespace starting in track 1 missed it.
WEEKBLD 10.008 NOT SORTED when implementing MXG 9.9
WEEKBLD 10.009 TYPE70PR,DB2ACCT/STAT0/STAT1 added to weekly/monthly.
WEEKBLD 10.206 All JCLPDB6 PDB & ASUM.... datasets are in WEEKBLD.
WEEKBLD 10.225 BY list for WEEK.ASUM70PR wrong.
XMAC7072 10.023 344 Compiler circumvention causes UNINITIALIZED msg.
XUNIX 10.076 Support for ULTRIX UNIX iostat and vmstat commands.
Inverse chronological list of all Changes:
NEXTCHANGE: Version 10
Change 10.336 The sample JCL Procedure MXGSAS is now provided in member
MXGSAS MXGSAS, and is now used in MXG JCL examples. The PROC is
Mar 11, 1993 simply an extension to the SAS607 JCL Proc, with the MXG
data sets and options provided to minimize your JCL.
Using MXGSAS, it is no longer necessary to override the
BLKSIZE on the //WORK DD, because there is no BLKSIZE
specified on that DD in the PROC, which permits the MXG
CONFIG07 default of BLKSIZE(DASD)=HALF to control the
blocksize. (Previous JCL examples showed the override
because the SAS607 JCL Proc had hardcoded BLKSIZE). These
symbolic parameters are provided in MXGSAS:
MXGHLQ= The highlevel qualifier of your MXG data sets,
defaults to MXGHLQ='MXG'
SASHLQ= The highlevel qualifier of your SAS data sets,
defaults to SASHLQ='SAS.SAS607'.
CONFIG= Can be used to override, but the PROC itself
concatenates &MXGHLQ..MXG.SOURCLIB(CONFIG07),
so there is no requirement to specify CONFIG=
WORK = Cylinders of work space. Default is (30,10)
SORT = Cylinders of sort work space in each of three
//SORTWKnn DDs. Explicit DDs are included to
prevent dynamic allocation; historically, SAS
and SORT packages have ABENDed when dynaloc was
used and there are multiple sorts of datasets of
different sizes (large, then small, then large
dataset sorting is common in BUILDPDB).
However, this is an example JCL PROC, and you are free to
modify it to meet your installation's JCL requirements.
Change 10.335 Program ASUM70PR enhanced to merge PR/SM data into the
ASUM70PR RMFINTRV and added these three new variables:
Mar 11, 1993 PLATCPUS - Number of CPUs in the hardware platform
PLATBUSY - Total "platform" CPU busy of the PLATCPUS
PCTOFHDW - Percentage of platform busy in this MVS system
RMFINTRV describes each MVS system in a PR/SM partition,
while ASUM70PR describes the whole box. The RMFINTRV
variable PCTCPUBY is the percentage of the interval during
which the NRCPUS in this MVS system were dispatched.
Assume a 100 second interval, and assume that you have a
3090-600 with two partitions, a "test" partition as a
3090-300 that can use three CPU engines, and a "prod"
partition as a 3090-600 that can use all six engines, and
assume you have Capped the test partition at 33%. At full
utilization, then, PLATBUSY would be 100% (of PLATCPUS=6
engines), the test partition RMFINTRV PCTCPUBY would be
66% (of NRCPUS=3 engines) and the prod partition RMFINTRV
PCTCPUBY would be 66% (of NRCPUS=6 engines). There were
600 seconds of total hardware platform CPU busy
(PLATCPUS=6)*(PLATBUSY=100%)*(DURATM=100) = 600, and
there would have been 200 seconds in test partition busy
(NRCPUS=3)*(PCTCPUBY=66%)*(DURATM=100) = 200, and there
would have been 400 seconds in prod partition busy
(NRCPUS=6)*(PCTCPUBY=66%)*(DURATM=100) = 400 seconds,
and PCTOFHDW can be calculated for the test partition:
PCTOFHDW = 100*(NRCPUS*PCTCPUBY)/(PLATCPUS*PLATBUSY);
= 100*(3*66)/(6*100) = 100*(1/3)= 33%
which shows that while PCTCPUBY=66% in RMFINTRV, in fact,
the test partition was using the full 33% of the hardware
platform that capping allowed it to use; arguably the test
partition is at 100% of the capacity you gave it!
Unfortunately, the Capping Target value is not stored in
the type 70 record, but PCTOFHDW may be a better measure
of processor utilization in a PR/SM environment with
shared processor engines.
Thanks to Gene Fernando, American Honda Motor Co, USA.
Change 10.334 FOCUS SMF record processing code caused INPUT STATEMENT
VMACFOCU EXCEEDED RECORD length (because MXG did not protect for an
Mar 20, 1993 82-byte short record); the change was made in MXG 10.3,
but not entered in CHANGES, and thus I do not know to whom
to give thanks. (If it's you, let me know!).
Change 10.333 DB2ACCT fields ACCOUNTn were not input. The test for the
VMACDB2 existence of account fields (IF QWHSNSDA GE 6) should have
Mar 20, 1993 been GE 7, and needed to be relocated until after IMACDB2H
had been included (since that's where QWHSNSDA is input!).
Finally, the offsets for the QMDA triplet should have been
73, 77, and 79 instead of 75, 81, and 83!
Thanks to Linda Thomas, Alberta Government, CANADA.
Change 10.332 Many new ADOCs members were added to MXG 10.10. Some are
ADOCx completed, but many are still work in progress, with new
Mar 9, 1993 text and discussion to be added. Nevertheless, since all
of the "variable descriptions" have been reviewed, the
usefulness of the information justified baring my soul, as
there's clearly still a lot of writing to be done. Most
now have PROC PRINT and PROC MEANS examples, which I still
find to be the best tool in SAS to learn about new data.
I intend to concentrate more on writing now that 10.10 is
done and looks so robust. Our next newsletter will keep
you informed of my progress toward the consolidation and
rewrite of both MXG books and all Newsletters, but I still
will provide all text in the MXG Source Library first, and
then will concern how much of it is put on paper!
Change 10.331 NETSPY Type "U" record sometimes produced negative value
VMACNSPY for TRANSNO when LUFDRSEQ='.1......'B because I did not
Mar 9, 1993 verify that TRANSNO was non-zero before subtraction. Now,
TRANSNO=TRANSNO-1 is executed only if both the bit is on
and TRANSNO GT 0.
Thanks to Jan-Ake Christoffersson, GotaData, SWEDEN.
Change 10.330 Variables UBRELBK and UMRELBK should have been spelled as
VMACDCOL UBREBLK and UMREBLK, and now they are.
Mar 9, 1993
Change 10.329 MXG 10.10 has been tested under both SAS 6.07 & SAS 6.08,
CONFIG08 and there are no external changes to your MXG jobs when
Mar 9, 1993 you migrate to SAS 6.08. Member CONFIG07 works with 6.08.
However, there is a new CONFIG08 member in MXG 10.10, just
for consistency in naming conventions, and just in case it
turns out that it is needed when 6.08 becomes production.
Because SAS 6.08 is currently a Beta release, benchmarks
of MXG under SAS 6.08 will await the production 6.08.
Change 10.328 MXG 10.10 has been tested under SAS 5.18, but this is the
DOC last MXG version that will completely support that archaic
Mar 9, 1993 version! Future MXG enhancements will now exploit new SAS
Version 6 features, which may cause incompatibility.
Change 10.327 CONTROL-D Release 2.0.0 is also supported by MXG as there
VMACCTLD were no changes to their SMF record in that release.
Mar 9, 1993
Thanks to Brian Cobb, Credit General Industriel, FRANCE.
Change 10.326 NETSPY dataset NSPYLU average host response time AHOSTRSP
VMACNSPY was slightly off if the number of transactions terminated
Mar 9, 1993 at the host (LUNRSPSS) was different than the number of
transactions input (TRANSNO), because MXG incorrectly used
TRANSNO in the denominator; now LUNRSPSS is used.
Thanks to Bob Hursch, Lockheed Information Technology, USA.
Change 10.325 Support for OpenEdition/MVS OMVS, section in type 30 adds
EXTY30OM new dataset TYPE30OM, which will contain one observation
VMAC30 for each process segment in each type 30 record. There
Mar 9, 1993 can be many process segments in a type 30 interval or step
termination record, and TYPE30OM will contain observations
from both step term and interval records. In addition,
type 30 pseduo step termination records are created when
an OMVS address space is "dubbed", indicating a change of
in state of that address space. The pseudo termination
record is identified by ABEND='OMVSEX' (because an OMVS
EX() was issued). Each "dub" creates a separate type 30
step record, which are identified within each STEPNR by a
new sub-step number, SUBSTEP. This support has only been
coded and syntax checked.
Change 10.324 Variable RMLFLAG2 was not kept in ASTEX dataset DMONVOL,
VMACDMON but now it is and it is formatted $HEX2.
Mar 8, 1993
Thanks to John Rosza, Depository Trust Company, USA.
====Changes thru 10.323 were printed in MXG Newsletter TWENTY-THREE====
Change 10.323 The PDB data sets listed in the Weekly and Monthly jobs
JCLMNTH were not in synchronization; some were in the weekly but
MONTHBLD not in the monthly, and TYPETMNT was copied twice in the
WEEKBLD weekly and monthly examples. Now, all data sets created
Mar 7, 1993 by the JCLPDB6 example will be copied to WEEK & MONTH.
Thanks to Barry Lampkin, Polaroid, USA.
Change 10.322 Significant progress has been made in MXG documentation,
ACHAP31 as there are now many new ADOCxxxx members, but it's still
ADOCxxxx a long way from completion. Most ADOCs now contain sample
Mar 6, 1993 PROC PRINTs and PROC MEANS, and variable definitions have
been revised, but some of the text has not been updated.
Change 10.321 This is the "all-your-data-sets-tracking-system" to keep
ADOCDSNS track of storage of all data sets, combining DCOLLECT data
DAILYDSN (all of your online volumes as well as information on
JCLDAYDS HSM migrated datasets, HSM backups, DASD volume capacity,
TRNDDSNS HSM tape capacity, and VSAM clusters) with data from the
WKLYDSNS TMS (CA-1) product's TMC tape data set catalog. It is
Mar 6, 1993 described in member ADOCDSNS and in comments.
Thanks to Chuck Hopf, Primerica, USA.
Change 10.320 Support for OpenEdition MVS, OMVS, in RMF records. TYPE70
FORMATS contains counts for OMVS address spaces (OMVS00-OMVS11 and
VMAC7072 OMVSAVG,OMVSMAX,OMVSMIN). TYPE71 contains six destination
VMAC71 counts for two new OMVS Swap Reasons, SWAPOI=OMVS Input
VMAC74 Wait, SWAPOO=OMVS Output Wait. New TYPE74OM dataset from
Mar 6, 1993 Monitor III captures OMVS Kernel Activity: TOT/MIN/MAX for
System Calls, CPU time, Fork/Dub Fails because of either
max users, max processes, or max processes per user, count
of users, count of processes, and the defined maximum
number of users, processes, and processes per user.
Change 10.319 Very preliminary support for RS6000 AIX commands VMSTAT,
VMACRSIO IOSTAT, and PS, with this user contribution. VMACRSCR
VMACRSPS is the script used that adds the data/time that is not in
VMACRSCR the command output! Not all fields are decoded, variables
VMACRSVM are not labeled, etc., but this is a start if you have the
Mar 6, 1993 need to look at AIX on your RS6000. The next release will
enhance and document, probably rename datasets and members
and add support for the AIX accounting file as well.
Thanks to Rachel Quiroz Holt, Neiman Marcus, USA.
Thanks to Andy Rockwell, Neiman Marcus, USA.
Change 10.318 TYPE42VL variables SMF42DB1 & SMF42DB2 are now formatted
VMAC42 as $HEX2. so they legibly print their bit values.
Mar 6, 1993
Thanks to Stephen W. Sweely, NM, AUSTRALIA.
Change 10.317 The GMT Offset, GMTOFFTM, is now available in RMF records
VMAC7072 under MVS/ESA 4.3, if Global Synchronization is enabled.
VMAC70s By comparing SYNCTIME with ENDTIME and using fuzzy logic,
Mar 3, 1993 MXG now creates the RETAINed variable GMTOFFTM from the
type 70 record, that may be useful in converting other SMF
records that contain GMT instead of local. This work is
not complete, since it only protects records written after
the first type 70 is found in your SMF file. I intend to
enhance the SPIN logic in BUILDPDB to keep the GMTOFFTM
from each SYSTEM to protect those early records!
Change 10.316 MXG formats contain the data value, a colon, and the data
UTILFMTX description, but for some report users (notably auditors)
Mar 5, 1993 the data value and colon confused them. This utility will
create an alternative format library for reports that has
removed the data value and colon. You can then point the
//LIBRARY DD in your report programs to the alternative
format library, or use SAS's FMTSEARCH option in reports.
Thanks to Joe Faska, Depository Trust, USA
Change 10.315 TCP/IP allows for two different SMF record IDs for TELNET
VMACTCP and FTP, but some sites assigned only one record ID. This
Mar 5, 1993 is now supported, as MXG reads inside the record to decide
which dataset is to be output. See also Change 10.256.
Thanks to Kurt Karlsen, NIT.
Change 10.314 MXG 10.1+ only, for JES3 BUILDPD3, "WORK.TAPEMNTS.DATA"
BUIL3606 error message results because the _VARTMNT and _CDETMNT
Mar 5, 1993 macro invocations were not in BUIL3606. Now they are!
Thanks to Hanno Bresch, SAS Institute, GERMANY.
Change 10.313 Variable ZDATE was not in the KEEP= list for TYPETAO data
VMACTAO set, but it is now!
Mar 5, 1993
Thanks to Sharon O'Daniel, Blue Cross Blue Shield of Kentucky, USA.
Change 10.312 The paper "An RMF Bigots View of Measuring UNIX Systems,
ADOCHPCS or how i learned to type in lower case", presented at
Mar 3, 1993 CMG and SHARE by Chuck Hopf, is now contained in ADOCHPCS.
Change 10.311 This is a preliminary change created for initial testing.
BUILD001 BUILDPDB was split into six members:
BUILD002 BUILD001 - Reads SMF and creates all WORK data sets,
BUILD003 CICSTRAN.CICSTRAN, DB2ACCT.DB2ACCT and the
BUILD004 PDB.DB2STATn data sets.
BUILD005 BUILD002 - SORT some WORK datasets into PDB library.
BUILD006 BUILD003 - SORT RMF datasets into PDB and then build
Mar 3, 1993 PDB.RMFINTRV dataset.
BUILD004 - Combine CICS Statistics datasets and create
four PDB.CICxxxRV datasets.
BUILD005 - (For JES2).
Sort TYPE30xx, TYPE6, TYPE26J2, interleave
with SPIN library, create PDB.JOBS,PDB.STEPS
PDB.JOBS, update SPIN library, copy SPIN
datasets into PDB (for backup), and create
PDB.SPUNJOBS.
BUILD006 - (For JES3).
Sort TYPE30xx, TYPE6, TYPE26J3, interleave
with SPIN library, create PDB.JOBS,PDB.STEPS
PDB.JOBS, update SPIN library, copy SPIN
datasets into PDB (for backup), and create
PDB.SPUNJOBS.
This may permit improved run time of the BUILDPDB process,
because once BUILD001 has run, the remaining four phases
may be executable in parallel. However, there will be JCL
constraints, and SAS/SHARE may be required for concurrent
update from parallel steps, and there may be additional
design changes before this becomes a recommended process.
Thanks to Dan Squillace, SAS Institute Cary, USA.
Change 10.310 For interval observations most MXG datasets have STARTIME
VMACNSPY and DURATM variables for the interval start and duration,
VMAC38 but in some datasets STARTIME does not exist or it has a
VMAC39 different name, and similarly for DURATM. It is now my
VMAC110 intention that STARTIME and DURATM variables will exist
VMACTSOM consistently in all MXG interval data sets, by creating
Mar 1, 1993 them where necessary (and without changing existing names
of their counterparts, so your reports won't break). The
members listed in this Change have all had either STARTIME
or DURATM or both added to their interval data sets,
except for TYPE39FF (NETMASTER), which does not contain
the DURATM and hence STARTIME cannot be determined. Let
me know if you find others that should be updated.
Thanks to Dan Squillace, SAS Institute Cary, USA.
Change 10.309 Very archaic EPILOG 451 code missed three undocumented
VMACEPIL bytes. Insert +3 after BIODISP PIB1. to correct the
Feb 28, 1993 BIO..... variables after BIODISP.
Thanks to Chris Spikings, Deutsche Bank AG, ENGLAND.
=Changes thru 10.304 were included in MXG PreRelease 10.6, Feb 23, 1993=
Change 10.308 OPC data apparently can be dumped in different formats.
VMACOPC If "OPC" starts in the 1st byte of the logical record, MXG
Feb 25, 1993 default is valid, but if "OPC" starts in the 4th byte of
the record, you must change to OFFSMF=-3 to OFFSMF=0 in
VMACOPC. Use DATA;INFILE OPCLOG;INPUT;LIST;STOP: to
print the first record to find the location of "OPC".
Thanks to Fulvio Robbiani, Banca Commerciale Italiana, ITALY.
Change 10.307 MXG no longer sets ABEND=NOTP in PDB.JOBS & PDB.SPUNJOBS
BUILDPDB because it was overlaying the ABEND value from the job
BUILDPD3 termination record. This will help in counting job-level
SPUNJOBS events, but for analysis of CONDCODE within ABEND, you
Feb 24, 1993 must use the PDB.STEPS data (CONDCODE in PDB.JOBS is wrong
if a flushed step followed the abending step).
Thanks to Steve Talley, Department of the Army, USA.
Change 10.306 Type 0 SMF record processing now checks record length and
VMAC0 deletes invalid records, after putting a message on the
Feb 24, 1993 SAS log. Occasionally, SMF records are created with the
record ID of 0, due to coding errors, but they looked like
IPL events. If you detect bad records, and know what the
true ID is, you can convert the bad record ID in member
IMACFILE, using IF ID=0 AND LENGTH GT 31 THEN ID=42;
if the bad record to be converted was actually a type 42.
Change 10.305 DCOLLECT has been enhanced in DFP 3.3 by APARS OY59795 &
EXDCODAG OY60048 with nine new datasets describing SMS constructs
EXDCODBC and control information. Even more significant, DFSMS 1.1
EXDCODDC adds long-needed VSAM statistics (including space used!).
EXDCODDR Two existing datasets are enhanced with new variables:
EXDCODLB DCOLCLUS (VSAM Data Set Information)
EXDCODMC DCAASP ='BYTES OF*FREESPACE*IN DATA SET'
EXDCODSC DCACAS ='CONTROL*AREA*SPLITS'
EXDCODSG DCACIS ='CONTROL*INTERVAL*SPLITS'
EXDCODVL DCADLR ='DELETED*RECORDS'
IMACDCOL DCAEXC ='EXCPS'
VMACDCOL DCAHARBA='HIGH ALLOCATED*RELATIVE BYTE*ADDRESS'
Feb 24, 1993 DCAHURBA='HIGH USED*RELATIVE BYTE*ADDRESS'
DCAINR ='INSERTED*RECORDS'
DCAKLN ='KEY*LENGTH*
DCANLR ='LOGICAL*RECORDS'
DCARKP ='RELATIVE*KEY*POSITION'
DCARTR ='RETRIEVED*RECORDS'
DCAUPR ='UPDATED*RECORDS'
DCAVRRDS='VARIABLE LENGTH*REL RECORD*DATA SET?'
DCOLDSET (Active Data Set Information) new variables:
DCDALLFG='ALLOCATED*SPACE*RETURNED?'/
DCDNMBFG='UNUSABLESPACE*RETURNED?'
DCDPDSEX='POSIX*FILE SYSTEM*FILE'
DCDSECFG='SECONDARY*SPACE*RETURNED?'
DCDSTRP ='STRIPED*DATA*SET'
DCDUSEFG='USED*SPACE*RETURNED?'
Additionally, if the DCOLLECT option SMSDATA is specified,
these nine new MXG datasets will have observations that
describe your SMS environment:
DCOLAG - Aggregate Group Information
DCOLBC - Base Configuration Information
DCOLDC - Data Class Construct Information
DCOLDR - OAM Optical Drive Record Information
DCOLLB - OAM Optical Library Record Information
DCOLMC - Management Class Construct Information
DCOLSC - Storage Class Construct Information
DCOLSG - Storage Group Construct Information
DCOLVL - Storage Group Volume Information
These nine new MXG datasets have been syntax checked, but
no test data has yet been made available; with 277 new
variables, I'll be surprised if it's perfect!
Change 10.304 Unexpected non-packed decimal field caused IMS log reads
ASMIMSLG program to ABEND with 0C7. After the BZ READIN02 that is
Feb 23, 1993 after the label READINPQ, insert this instruction:
OI ARRVDATE+3,X'0F'
to ensure the field is in packed decimal format.
Thanks to Jeffrey S. Crum, Ashland Oil, USA.
Change 10.303 TYPE1415 variable DSORG can be "PS" when really is "PO"
VMAC1415 and MEMBER can be blank because the IBM record is wrong.
Feb 23, 1993 If PDSs with member name specified are concatenated, the
first type 14 has DSORG='PO' and correct MEMBER name, but
the 2nd and subsequent type 14 records had DSORG="PS", and
MEMBER was blank. The DSORG was wrong because both the
JFCBORG and DCBDSORG are '40'X (PS) in the concatenation
records, instead of '02'X (PO) as is in the first record.
MEMBER is blank because MXG INPUTed it only for DSORG=PO
(the location of MEMBER contains RELGDG if it is not a PDS
and is a GDG!). Why are JFCBORG and DCBDSORG both "PS"
for a PDS? Because when the member name exists in the
JCL, OPEN treats the data set as sequential, even though
the true DSORG (in the VTOC) is still "PO"! Since IBM
will take some time to address this situation, MXG has
circumvented the problem (hopefully): If MEMBER starts
with + or -, it must be a RELGDG and MEMBER is blanked.
Otherwise, if MEMBER is non-blank, it must be a PDS, and
so MEMBER is valid and DSORG if forced to "PO".
Thanks to Herbert G. Strozinsky, Burlington Northern Railroad, USA.
Change 10.302 OPC/A data records are created as RECFM=U but test data I
VMACOPC received had been copied to RECFM=VBS, misleading me to
Feb 23, 1993 assume that RECFM=VBS had to be specified in macro _SMFOPC
defined in VMACOPC. The RECFM=VBS parameter is now removed
from VMACOPC, so MXG will read either VBS or U data, using
the RECFM in the data set label.
Change 10.301 This new report macro replicates IBM's RMF reports from
ANALRMFR MXG's TYPE70xx thru TYPE78xx datasets. In addition to
Feb 22, 1993 producing reports, the source code can be read to find out
which MXG variables are used for RMF report values. This
support includes all RMF reports except Channel and Trace,
(which will be added when there is a groundswell of user
requests, or when we feel like it, whichever comes first!)
The report syntax is self-defined in this member.
Change 10.300 Support for Empact's HiperCache product's SMF record adds
EXHIPRSA two new dataset:
EXHIPRVS HIPRSAM - Hipercache SAM data set activity
IMACHIPR HIPRVSAM- Hipercache VSAM data set activity
TYPEHIPR thanks for this significant user contribution.
VMACHIPR
Feb 22, 1993
Thanks to David Childress, Lowe's Companies, Inc, USA.
Change 10.299 RMFINTRV enhancements have added SIO75CNT (Paging SSCHs),
RMFINTRV SIO74TAP (SIOs to tape devices), and TSO2-TSO4 variables
Feb 22, 1993 SWAP,TRAN,RESP for 2nd thru 4th period TSO counts and
response time. In addition, these swap counts:
EXTAUX LOGAUX LOGEXT PHYAUX PHYEXT
and page movement rates:
HIPMIGRS HIPREADS HIPWRITS PGMIEXAU PGMVTOEX PWSSMIIN
were added to RMFINTRV from the TYPE71 dataset.
Thanks to Tom Parker, Hogan Systems, USA.
Thanks to Chuck Hopf, Primerica, USA.
Change 10.298 PDB.PRINT dataset now contains new variable TOTLINES, the
BUILDPDB sum of PRINTLNE, PUNCHCRD, EXTWTRLN, for sites that still
BUILDPD3 have impact printers. Note that TOTLINES is the number of
Feb 22, 1993 print line images if JES2 or PSF prints line-mode data,
but if PSF prints PSF-mode data, it counts print records,
and a print record can be a single print line or it could
be a multi-page graph. Because of this, variable SHEETPRN
the actual number of sheets of paper printed, should be
used, with TOTLINES only used for impact printers under
JES. See member ACHAP31 for discussion of print charging.
Change 10.297 Support for optional HOGAN application variables was
IMACICUS updated to add new variables FPSSCRN, TCTPLD, TCBFUNC,
VMAC110 PLDVERS, and correct variables FPSOPTN and FPSTYPCD, and
Feb 22, 1993 the new variables were added to CICSTRAN KEEP= list (but,
like all the optional variables in CICSTRAN, they will not
exist unless the optional code is enabled in IMACICUS).
Thanks to Tom Parker, Hogan Systems, USA.
Change 10.296 DB2 Reports. If PMIOS05=YES was requested with PDB=SMF,
ANALDB2R and PDBOUT= was not specified, ERROR "LIBREF SMF IS NOT IN
Feb 21, 1993 A VALID FORMAT" resulted. ANALDBTR should have replaced
the earlier "paring" macros, which were the source of the
real error. Replacing the "paring" with %ANALDBTR invoked
for those pairs eliminated the error. Specifying PDBOUT=
circumvented the error. The PMACC02=YES accounting detail
in the accounting detail report and the values reported as
averages in the Buffer Pool Summary were reported
incorrectly. In addition, a 'Total Average' column was
added to be consistent with DB2PM.
Change 10.295 The variables created to identify why a plan had ended
ASUMDB2A were created but not kept because they were not in the
Feb 21, 1993 SUM= list.
Change 10.294 Support for HP's PCS data from HP/UX is extended to now
ADOCHPCS read MPE data (HP's older, proprietary operating system).
EXHPCSSP Some minor logic bugs were also corrected. Macro HPCSDLM
IMACCSSP was added to member IMACHPCS to identify the character(s)
TYPEHPCS that are to be used as field delimiters when the PCS data
VMACHPCS was created, since the delimiter is a part of the data
Feb 21, 1993 collection command. Member ADOCHPCS now contains the
specific SCOPE commands that was used to create the data
that MXG TYPEHPCS support expects. In addition, that same
ADOCHPCS member contains Chuck Hopf's fine paper on UNIX
resource measurement, "An RMF Bigots View of Measuring
UNIX Systems, or how i learned to type in lower case".
Thanks to Doug McBride, Hewlett-Packard, USA.
for patience with the untutored in this particular world of DP, and
for the data and manuals that made this enhancement to MXG possible.
Change 10.293 Support for Boole & Babbage CMF User SMF record subtypes
EXCMFCAR expanded to support essentially all subtypes; the complete
EXCMFCCS status for each subtype is listed in comments at the start
EXCMFCDS of member VMACCMF. Most of this enhancement is based on
EXCMFCJS the sample SAS code distributed with CMF, so that names of
EXCMFCOS variables and datasets are the same, but their sample code
EXCMFCPQ was architecturally revised and edited into the MXG style.
EXCMFCSC With this enhancement, these datasets are now created,
EXCMFCSS and all have been tested with real data records, too!
EXCMFC93
EXCMFDDS Subtype Dataset Description (Dataset Label)
EXCMFGDA 00 CMFDEVIC CMF 00 DEV
EXCMFJDS 00 CMFDOM CMF 00 DOM
EXCMFPDS 00 CMFIPS CMF 00 IPS
EXCMFPGS 00 CMFOBJ CMF 00 OBJ
EXCMFPDS 00 CMFPG CMF 00 PG
EXCMFUSS 00 CMFSRMC CMF 00 SRM
EXCMFWOR 00 CMFEXTCC CMF 00 TCC
VMACCMF 00 CMFEXTPG CMF 00 TPG
Feb 21, 1993 00 CMFEXTRT CMF 00 TRT
01 CMFCPUQ CPU QUEUE COUNTS
01 CMFCPUS CPU AND CHANNEL SAMPLE DATA
02 CMF02PSD ASM DATA (PAGE/SWAP DATASETS)
03 CMF03PGS PAGING DATA (SRM SAMPING)
04 CMF04WOR WORKLOAD DATA (DOMAIN SAMPLING)
05 CMF05DDS DASD DEVICE DATA
05 CMF05TDS TAPE DEVICE DATA
06 CMF06GDA JES SPOOL ACTIVITY
06 CMF06JDS JES CLASS ACTIVITY
09 CMFASMQ ASM DATA
19 CMFTRACE I/O WORKLOAD TRACE
20 CMF20CCS TSO COMMAND SUMMARY
20 CMF20CSS TSO COMMAND DETAILS
21 CMF21USS TSO USER RESOURCES
23 CMFPG0V CMF 23 PG0V
23 CMFPRIOS CMF 23 PRIOS
27 CMF27C93 CACHE SAMPLING MODEL 3990-3
27 CMF27CAR CACHE SAMPLING MODEL 3880
27 CMF27CSD CACHE SAMPLING CSD
29 CMF29COS COMMON STORAGE COS
29 CMF29CJS COMMON STORAGE CJS
29 CMF29CDS COMMON STORAGE CDS
Change 10.292 Support for IMF Release 2.8 uncovered MXG corrections:
VMACCIMS Dataset CIMSTRAN variable INPQUETM was wrong for fastpath,
Feb 20, 1993 and COREALOC is actually "Storage Available", so its label
was changed.
The IMF Release itself added these changes:
Dataset CIMSTRAN:
New variable UOWTIME is now created from existing
variable ALPCBTRN. For DBCTL, ALPCBTRN is the IMS
Transaction's Unit of Recovery, the same as the CICS
Unit of Work ID, UOWID. MXG converts the first six
bytes of ALPCBTRN into UOWTIME, the 6-byte part of
UOWID that is the constant token across all records for
the same transaction, and the token that is used to
match IMS events to their CICS and/or DB2 counterparts.
UOWTIME is always created, but is only valid when
ALPCBTRS contains a UOR. The second field CICS/DB2
field used to match transaction, NETSNAME, the name of
the originating network on which UOWTIME was created,
is not yet in the IMF transaction record.
Variable FLGSPECL now contains Q for Quick Reschedule.
New variables TRNSKW and TRNSNKW count the SYNC buffer
flush writes (Key-Writes and NonKey-Writes).
New variable APPCIMS flags APPC/IMS transactions.
Dataset CIMSDBDS: Two new counts:
DBTDDNNO='DDN*DBTNO'
DBTSECNO='SEC*DBTNO*(OVERFLOW)'
and seven new flag (status) variables:
DBTMSCNT='DBT CNTRS*OVERFLOWED?'
DBTOSSB ='OSAM*SB IN*EFFECT?'
DBTOVFLW='DBT*OVERFLOW*OCCURRED?'
DBTTYDDN='I AM A*DDNAME*DBT?'
DBTTYOTH='I AM A*CATCH-ALL*DBT?'
DBTTYSEC='I AM A*SECONDARY*DBT?'
DBTVSAM ='VSAM*ACCESS*METHOD?'
Fortunately for everyone, the new fields used existing
reserved fields, so the changes were compatible.
Change 10.291 Support for Oracle 6.0.33.1.51 added two READTIME and JOB
VMACORAC and ACCOUNTn fields, and two additional CPU time measures.
Feb 20, 1993 CPUCICTM is the CICS subtask CPU time (now added to CPUTM
as it was not previously captured). CPUXMETM is the CPU
time spent in cross memory mode in the ORACLE address
space, but as this is already captured in CPUTCBTM or
CPUSRBTM, it is not added to CPUTM; CPUXMETM lets you see
how much of CPUTM was spent in the ORACLE ASID. There is
a new section for SQLNET data, but the contributor site
did not have documentation nor data for that option. The
USER field section is added; see comments in VMACORAC on
how to keep the USER field if it exists in your data.
Thanks to Martyn A. Jones, Data Sciences UK
Change 10.290 This significant user contribution matches SLR-IMS log
TYPESLRI processing - it keeps only a subset of the statistics that
Feb 19, 1993 MXG's new ASMIMSLG produces and it uses the output of IBMs
DBFULTA0 as input for Fast Past processing, which greatly
reduced the elapsed processing time. This contribution is
documented in the author's letter at the beginning of the
member, which is actually the JCL to build a PDS with the
several members of this IMS log processing alternative.
Thanks to George Denissof, Savings Bank Services Ltd, Espoo, FINLAND.
Change 10.289 To bill tape datasets using TMS dataset DSNBRECD is built
TYPETMS5 for the first dataset on the volume by OUTPUTing the info
VMACTMS5 from the volume record, but if the first dataset on the
Feb 19, 1993 volume was SCRatched or DELeted in the catalog, MXG still
output to DSNBRECD, causing a billing charge for a "dead"
tape. Now, the observation is OUTPUT only if the dataset
is neither scratch nor deleted.
Thanks to Chuck Hopf, Primerica, USA.
Change 10.288 Service time could still be zero, because the reset logic
TYPEIMSA had not been moved into TYPEIMSA from TYPEIMS. Lines in
Feb 19, 1993 TYPEIMSA from STRTTIME=GUTIME; thru OUTQUETM=OGUTIME...
were deleted and replaced by TYPEIMS lines from
/* TEST FOR MISSING thru RESPNSTM=ENDTIME-ARRVTIME;.
Thanks to Lonnie T. Rimmer, Philip Morris, USA.
Change 10.287 Format $MGAMDDT is no longer used (it was for an earlier
FORMATS version of Amdahl's SPMS), and has been removed.
Feb 19, 1993
Thanks to Adrian Reynolds, SAS Institute, ENGLAND.
Change 10.286 MXG 10.5 only. Variable AVGMTPTM, the average mount time
VMAC74 per TAPEMNTS (new in ESA 4.3) was incorrect. DEVMNTTM,
Feb 19, 1993 the duration when a mount was pending is added to TYPE74.
Change 10.285 Support for IBM 3495 Tape Library Dataserver Statistics
EXTY94 SMF type 94 record is added, providing hourly statistics
IMAC94 (min/max/avg counts/durations) of drives mounted, mount
TYPE94 requests pending, demounts, ejects, audit requests, and
VMAC94 the number of insert stores.
Feb 18, 1993
Change 10.284 Amdahl MDF creates TYPE70PR observations with LPARNUM=0,
ASUM70PR while the first LPAR in IBM's PRSM or Hitachi MLPF is=1.
Feb 18, 1993 ASUM70PR will produce an error message "MORE THAN 16 LPAR"
when it encountered the unexpected LPARNUM=0. Now, this
summary member supports 17 LPARs, numbered 0 thru 16!
Thanks to Jeff McFadyen, Ministry of Correctional Services, CANADA.
Change 10.283 Some fields (notably R791TCPU) are accumulated in type 79
VMAC79 records created by RMF Monitor II. However, it appears it
Feb 17, 1993 is not possible to deaccumulate the data. Using the sort
order BY SYSTEM R79SES R791ASID R791JBN STARTIME does
correctly sequence the TYPE791 dataset, but MVS/ESA 4.2.2
data contains adjacent intervals in which R791TCPU drops
rather than increases. I assume these are either step
transitions or reuse of the same ASID by the same Job in
which the CPU clock is reset, but there is no indicator of
STEPNR or JESNR in the record by which the reset can be
recognized. Furthermore, even when two intervals happen
to show an increase, it is possible that the CPU clock was
reset, but the CPU time in the second interval just
happened to be larger; in this case, if the values were
deaccumulated, the wrong CPU time would have been created.
In addition, the TYPE791 data contains accumulated counts
for page activity when the task is swapped in, but those
counts are zeros in the next record if the task is swapped
out, requiring additional investigations in the absence of
logic description from IBM as to when this occurs. Thus a
safe algorithm for deaccumulation is not possible until
IBM enhances the record and describes when fields are
zeroed and when they are not!
Thanks to Khalid Al-Harthi, Saudi Arabian Airlines, SAUDI ARABIA.
Change 10.282 This suite of RACF reports was made more user friendly by
ANALRACF removing references to &DAYNUM, and providing specific
Feb 17, 1993 example of how to set &START and &END in JCLRACFR. All
occurrences of RACFTERM $6. were changed to $8. MXG Format
MG080TY was updated with new types. PROC DATASETS were
added to delete unused work data sets, freeing DASD. Two
new members now exist: JCLRACFR executes ANALRACF
programs, and JCLPRINT prints reports created by ANALRACF.
The internal members in ANALRACF that were altered are:
JCLRACFR JCLPRINT MXGDAY1 REPRACF REPRACFB REPRACF2
REPRACF3 REPRACF4 WPDBRACF
While ANALRACF provides a lot of reports, the new TYPE80A
dataset may prove to be a better source of reporting. Much
of the logic in ANALRACF was required because MXG split
the type 80 record into multiple observations. The TYPE80A
member creates one observation per type 80 into several
datasets for improved access and reporting. Try it first!
Thanks to George Waselus, State of Arizona, Department of Admin, USA.
Change 10.281 DB2 Trace IFCID 0044 Lock fields were input incorrectly.
VMAC102 Change INPUT QW0044KL PIB1. to read
Feb 17, 1993 to read INPUT @I+8 QW0044KL PIB1.
Thanks to Jason Lau, AMP Society, AUSTRALIA.
Change 10.280 The 4th TCB (Secondary LU) CPU time was not summed into
VMAC110 CPUTCBTM in dataset CICDS, and thus it was also not in the
Feb 15, 1993 CICEODRV, CICINTRV, CICREQRV or CICUSSRV datasets.
Change 10.279 Believe it or not, there is still SMF data from VS1 being
VMAC535 created, and its type 5 record caused MXG to fail because
Feb 4, 1993 I assumed the MVS/370 service unit fields were present in
the record. Now their input is conditional!
Thanks to Don Mosley, Farmland Industries, USA.
Change 10.278 OMEGAMON/CICS V550 PTF QOC0109-DATACOM SPE- adds 16 bytes
IMACICOC to their BSC segment in the type 110 record for both CICS
IMACPTF Version 2 and CICS/ESA. This will corrupt the data in the
Feb 4, 1993 other OMEGAMON segments, as well as any user data segments
your installation might have added. And, of course, there
is no way to detect whether or not you have installed this
PTF by examining the type 110 record! As a result, you
will need to update member IMACPTF to enable _QOC0109 to
tell MXG when you have installed this OMEGAMON PTF. (Page
9 of Newsletter TWENTY-TWO discussed how to enable the
MXG Support for OMEGAMON V550.)
Thanks to Carol Harper, EG&G Idaho, USA.
Change 10.277 DCOLLECT does not capture VSAM space used. IBM Appendix E
VMACDCOL of the MVS/DFP Access Method Services For ICF documents
Feb 4, 1993 that DCDUSESP is not 'valid' for VSAM datasets. MXG's
ASMVVDS/TYPEVVDS processing, which reads the VVDSs, does
capture space allocate and space used. However, under
user pressure, IBM has announced, in ETR Item E3058,379
that DFSMS Release 1.1 (March, 1993) will add a field to
the "A" record with space used value.
Note: Change 10.305 added the new fields to "A" record,
which is output to DCOLCLUS dataset; see ADOCDCOL.
Thanks to Frank Vessell, ITT Consumer Financial Corporation, USA.
Change 10.276 Support for STOPX37 Release 3.5 added a number of new
VMACX37 variables to the STOPX37 dataset. This support has not
Feb 4, 1993 yet been tested with actual 3.4 data records.
Change 10.275 MXG 10.4-10.5. STOPOVER resulted because line 031500
VMAC73 should be SKIP=SKIP-8; instead of SKIP=LENCHDS-8;. (Note
Feb 4, 1993 that line 030800 still must be SKIP=LENCHDS-8;).
Thanks to Jim Nissen, Principal Financial Group, USA.
Change 10.274 Support for Empact's POOL-DASD user SMF record, written
EXTYPOOL whenever POOL-DASD manages an allocation. The text of the
IMACPOOL WTO messages associated with the allocation override by
TYPEPOOL POOL-DASD describes what action was taken.
VMACPOOL
Feb 3, 1993
Change 10.273 Support for Candle's IMS Transaction Reporting Facility,
EXITRDAT ITRF, is added. MXG reads the output file created by the
EXITRDB2 ITRF Batch Summary program to create these MXG datasets:
EXITRMSG ITRFMSG - Message records
EXITRMSO ITRFMSGO - Message Out records
EXITRSUM ITRFDATA - Database Records (DL1 and Fastpath)
IMACITRF ITRFSUM - Summary Records (DL1 and Fastpath)
TYPEITRF ITRFDB2 - Summary Records (DB2)
VMACITRF ITRF is a new part of Omegamon II for IMS. Its online
Feb 3, 1993 component creates an IMS log record (default ID=160) that
captures response time, CPU time, virtual storage used,
and elapsed time of DL1 and DB2 calls. That log record,
along with IBM log records 01,03,07,08,31,32,33,35,5607,
5901,5903,5936,and 5937 are the input to the ITRF Summary
program, which constructs transaction events and creates
the output file that is the input for MXG's TYPEITRF
program. Although Candle provides an option to send all
of those required IMS log records to SMF for processing
by the Summary program, this is one instance in which I
think it ill advised to use SMF because of the significant
volume of data. (If Candle ever builds a transaction
data in the online component and write a single record for
an IMS transaction, I would strongly endorsed SMF as the
correct destination for such a record!).
Change 10.272 DB2 Accounting report 2nd occurrence "GET PAGE REQUEST"
ANALDB2R is actually "BUFFERPOOL EXPANSIONS". The Average values
Feb 3, 1993 of Buffer Pool statistics are incorrect; they were divided
by the number of occurrences, then divided a second time.
(We missed this careless error because in our test data
we happened to have only one occurrence for each group!)
Finally, the "Total" column will be relabeled to indicate
it is the "Total of Averages", and a new column with the
true total has been added to the report.
Thanks to Tuomo Rahko, KOP / Kansallistieto, FINLAND.
Change 10.271 Processing Landmark's Monitor For CICS data Release 9 may
TYPEMON8 produce "INVALID DATA FOR TIESDATE" and "ERROR"INVALID DO
Feb 3, 1993 LOOP CONTROL INFORMATION", if the Landmark Dump program
does not specify CONVERT on the DUMP statement. (See their
JCL samples TMON9DBU and TMON9FSU). Without the CONVERT
operand, the dumped data is not converted to Release 8
format, which is the only data format that Landmark has
documented externally. As long as DUMP CONVERT is used,
MXG has no problem processing Release 9 data. MXG now
detects this condition and writes an error message to the
SAS log alerting you to the incorrect dumping. Landmark
has also begun shipping of Release 1.0, which has the same
data records as Release 9 (and which also requires the use
of the CONVERT option).
Thanks to Terry Baker, Royal Insurance, USA.
Change 10.270 MXG 10.2 thru 10.5 only. Invoking the READDB2 program:
READDB2 %READDB2(INFILE=SMF,PDBOUT=XXX,IFCIDS=ACCOUNT STATISICS);
Feb 3, 1993 did not write DB2ACCT,DB2STAT0,DB2STAT1 to the XXX ddname,
because the defaults defined in IMACDB2 were not changed
by READDB2. The macro definitions _DB2ACCT and _DB2STAT
were replaced by new definitions of _LDB2ACC, _LDB2ST0,
and _LDB2ST1 to correct this error.
Change 10.269 READDB2 fails with "ERROR: THE FILE WORK.T102S: WAS NOT
READDB2 FOUND" if the USER=xx option is specified, because READDB2
Feb 3, 1993 expected the selected datasets to be in the WORK file.
Thanks to Mike Marek, Kraft General Foods, USA.
Change 10.268 10.4-10.5 only. INPUT STATEMENT EXCEEDED RECORD LENGTH
VMAC28 resulted because variable LSAMINID was input twice! The
Feb 3, 1993 second occurrence in the INPUT statement must be deleted.
Thanks to Adrienne Wijlaars, Belastingdienst Automatiser, NETHERLANDS
Change 10.267 Title statements in these graphic members still contained
GRAFBNCH the options .F and .H of an ancient SAS version (82.4).
GRAFCICS The period should have been removed from both options long
GRAFVM ago!
Feb 2, 1993
Thanks to Norbert Korsche, OMV-AG, AUSTRIA.
Change 10.266 DB2 Trace subtype 191 (data set T102S191) is now decoded,
VMAC102 although some of the internal diagnostic sections are not,
Jan 28, 1993 nor is this strange subtype protected if the data length
exceeds 5000 bytes. (DB2 self-limits a DB2 data block to
5000 bytes, even though the SMF record can be 32760 bytes.
When an IFCIC=191 data block exceeds 5000 bytes, DB2
inserts two-byte length fields between the blocks to
build the SMF record, but DB2 does not update the internal
offsets inside the data blocks! This will require lots of
nasty logic to either strip the length fields or to figure
out how many length fields there are and then to correct
the internal offsets to the external record locations! If
someone really needs the diagnostic sections decoded and
provides sample data, only then will I have to spend the
time to figure out how to do it!)
Thanks to Tom Parker, Hogan Systems, USA.
=Changes thru 10.265 were included in MXG PreRelease 10.5, Jan 28, 1993=
Change 10.265 Support for CA's IDMS Release 12 Performance Monitor SMF
VMACIDMS records is confirmed. It was easy, as there were no
Jan 28, 1993 changes in their SMF records!
Thanks to Roger Clayton, Cryovac Division of W.R. Grace & Co, USA.
Change 10.264 Support for NPM Release 1.6 added new values for several
EX028CM7 formats and changed the FRP, NAM, NCD, and TRI segments.
EX028LA6 New subtypes 84x,85x are output in the existing NPMINFRP
EX028LA7 dataset. Six new data sets are created:
EX028LA8 Subtype Dataset
EX028LA9 80x NPMLANET Ethernet Lan
EX028LAA A0x-A1x NPMLANOD ODLC Lan
FORMATS C3x NPMLANSG Lan Segment Utilization
VMAC028 C0x-C2x NPMCMLAN Start/Stop/Alter Lan
Jan 28, 1993 C4x-C5x NPMLANES Lan Monitor Exception
C6x-C7x NPMLANSA Lan Attach/Detach
Change 10.263 Some new TYPE71 page movement variables are rates per
VMAC71 second didn't so indicate in their label but now they do!
Jan 27, 1993 (You can always determine if a variable is a rate simply
by looking at all occurrences of the variable name in the
MXG source VMAC.... member to see if it is divided by the
interval duration.
Thanks to Bill Fife, Computer Associates, USA.
Change 10.262 Support for NETSPY Release 4.3 and LANSPY Release 1.1.
EXNSPYLD NETSPY added STOPTIME to NSPYLU, NSPVTSWD to NSPYTR,
EXNSPYLF NSPYLINE and NSPYNPSI datasets. Many new variables were
IMACNSPY added to LANSPY dataset NSPYLANL, including frame and byte
VMACNSPY counts for LLC, NetBios, IP, IPX, XNS, DEC, LAT, LAVC, ARP
Jan 27, 1993 X.25, AppleTalk, NCP, SMB, VINES, NFS, FTP, ICMP, Telnet,
Feb 20, 1993 Broadcast, Multicast, and SNA over Ethernet! Counts of
frames and bytes were also added to NSPYLANS. New dataset
NSPYLAND captures internetwork delays. Member EXNSPYLF
controlled outputting of dataset NSPYLANF by testing
IF SUM(a,b,c) THEN OUTPUT ..., which created observations
only if the sum was non-zero, but two users were puzzled
why it did not read IF SUM(a,b,c) GT 0 THEN OUTPUT...,
so to avoid unnecessary puzzlement, it now uses GT 0!
(Without the GT 0, the OUTPUT is executed if the sum is
non-zero; since the a,b,c values were input as PIB4, they
could never be negative, and there was no logic exposure,
but it is more accurate and user friendly to use GT 0!)
Feb 20. New Path Entry Layout for Extended Subtype D LAN
SPY records was coded, and several incorrect lengths were
revised. No data for testing yet available.
Change 10.261 Support for MVS/ESA 4.3. These variables were added:
BUILDPDB Dataset Variable Description
IMACPDB TYPE23 SYNCTIME - Datetime value when the SMF Global
RMFINTRV TYPE30_V Recording Interval ended (the STATUS
VMAC23 TYPE70xx function). This value is put into
VMAC26J2 thru other SMF and RMF records so the data
VMAC30 TYPE79xx can be matched exactly! However, the
VMAC32 new SYNCTIME includes the GMT offset,
VMAC33 so if you have a non-zero value for
VMAC42 TIMEZONE= in SYS1.PARMLIB(CLOCKxx),
VMAC60 SYNCTIME will be in GMT while all the
VMAC6156 other timestamps will be in the LOCAL
VMAC71 time zone! And, the GMT offset value
VMAC73 is not provided in these records!
VMAC76 You Synchronize SMF and RMF records
VMAC77 with the SYNCVAL and INTVAL values
Jan 28, 1993 in the SMFPRMxx member of parmlib.
Feb 9, 1993 TYPE26J2 SUBMUSER - Submitting USERID
NOTIFYND - Job end execution notify NODE
NOTIFYUS - Job end execution notify USERID
ACCOUNTn - Job card accounting fields finally!!!
NRACCTFL - Number of accounting fields.
LENACCTn - Length of nth accounting field
DUPJBDLY - Flag that job was delayed due to
Duplicate Job Name Hold event
OFFLPURG - Flag that this purge record was due
to Spool Offload event, and is not
the actual purge event. (This flag
requested only last year, is now used
in BUILDPDB to solve the problem
described in Change 9.243.
TYPE30_V New INTBTIME and INTETIME values are added to
the ID section, and INTETIME is now the end of
the Interval (previously, INTETIME was taken from
SMFTIME, which could be later than the actual end
of the interval). If a task is swapped out at
the end of the interval, a record is not written
until the task is swapped back in, and SMFTIME is
much later than INTETIME. The INTBTIME/INTETIME
values are actually on the GMT clock, but because
the old interval begin time (SMF30IST) remains on
the local clock, the GMTOFFTM can be determined
so that INTBTIME and INTETIME are converted to
local time (like all the other type 30 times).
Variable SYNCTIME is the GMT value of INTETIME
that will match SYNCTIME in type 23 and type 70s,
for matching synchronized SMF and RMF intervals.
SMFTIME was also added to TYPE30_V data set. Data
set TYPE30_V becomes the PDB.SMFINTRV data set.
Also, DSSIZHWM was converted to bytes and format
with MGBYTES format.
TYPE33_1 Now contains JOB READTIME and STEPNAME.
TYPE33_2 New APPC/MVS dataset contains resources at the
conversation level, particularly needed if you
uses an APPC/MVS Server address space to process
multiple conversations concurrently, since now
you can collect information for each conversation
in the server address space.
TYPE42SR New DFSMS data set provides response statistics
for each Storage Class for each interval:
AVGCONMS- Average connect time per SSCH
AVGCUQMS- Average CU queue time per SSCH
AVGDISMS- Average disconnect time per SSCH
AVGPNDMS- Average pending time per SSCH
CACHCAND- Count of cache candidates
CACHHITS- Count of cache hits
IOCOUNTS- Total i/o count
RESPTIME- Average response time per SSCH
STORCLAS- Average connect time per SSCH
WRITCAND- Count of write candidates
WRITHITS- Count of write hits
TYPE42DS New DFSMS data set provides response statistics
for each Data Set, with same statistics as in the
TYPE42SR (above), with additional details.
TYPE60 Existing field SMF60SUB/SMF61SUB which explained
TYPE6156 if the VVR or ICF Catalog record was UPDATED or
INSERTED or DELETED is now "Erroneous Field. Do
Not Use", with no alternative field!
TYPE70s Variable SYNCTIME was added to all RMF datasets
for synchronization with SMF records. See above.
Additionally, all RMF datasets have new variable
INTRVSYN=Y if synchronization is in effect.
TYPE71 CPUPAGTM, the CPU time spent in page movement in
central store. When a particular type of frame
(eg. below 16MB or nonreconfigurable) is mandated
by a request but is not found in the available
frames, the real storage manager uses a process
called prefsteal to attempt to find a correct
type of frame and move the contents of that frame
elsewhere in central or expanded storage. The
TCB/SRB timer is stopped during this process in
consideration of the general desire that these
times be as repeatable as possible. This new
variable, CPUPAGTM, is the CPU time that was not
previously captured during this process.
TYPE72MN A significant MVS/ESA 4.3 RMF enhancement is the
addition of many new RMF III variables to the
TYPE72MN dataset, written for each performance
group for each interval. New sampled measures
for the percentage of time when each performance
group was USING devices or CPU, or was DELAYed
for devices, CPU, storage, ENQ, HSM, JES, MOUNT,
message, XCF, will make TYPE72MN a very useful
source of delay analysis. Additional measures
of CSTORE and ESTORE usage and "long" logical
swaps are included in these new variables:
AVGELPTM=AVG ELAPSED*TIME PER*ENDED TRANS
AVGQUETM=AVG JES/APPC*QUEUE TIME*PER ENDED
CPUVECTM=VECTOR*CPU USED*DURATION
LOGCSTOR=CSTORE FOR*LOGICALLY*SWAPPED USERS
LOGESTOR=ESTORE FOR*LOGICALLY*SWAPPED USERS
LONGESTO=LONG SWAPS*TO EXPANDED*STORAGE
LONGLGSW=LONG*LOGICAL*SWAPS
LONGPHYS=LONG SWAPS*TO PHYSICAL*AUXSTORE
LSWSAMPS=TOTAL*LOGICAL SWAP*SAMPLES*/
PCTDLDEV=PCT WHEN*DEVICE*DELAY
PCTDLENQ=PCT WHEN*ENQ*DELAY
PCTDLHSM=PCT WHEN*HSM*DELAY
PCTDLJES=PCT WHEN*JES*DELAY
PCTDLMNT=PCT WHEN*MOUNT*DELAY
PCTDLMSG=PCT WHEN*MESSAGE*DELAY
PCTDLPRO=PCT WHEN*PROCESSOR*DELAY
PCTDLSTO=PCT WHEN*STORAGE*DELAY
PCTDLXCF=PCT WHEN*XCF*DELAY
PCTUNKN =PCT WHEN*UNKNOWN*STATE
PCTUSDEV=PCT WHEN*DEVICE*USING
PCTUSPRO=PCT WHEN*PROCESSOR*USING
PHYESTOR=ESTORE FOR*NON-LOGICAL*SWAPPED USERS
PSWSAMPS=TOTAT*NON-LOGICAL*SWAP SAMPLES
TRANS =ENDED*TRANSACTION*COUNT
VALDSAMP=TOTAL*VALID*SAMPLES
TYPE73 In MVS/ESA 4.2, APAR OY45991 PTF UY77343 now
writes a CHPID segment for all 256 possible paths
whether they exist or not; now MXG only OUTPUTs
TYPE73 observations if the CHPID is ONLINE.
TYPE74TD New "Tape Device" dataset contains the maximum
number of tape devices allocated each interval,
recorded if device class TAPE is being recorded.
This dataset was also added to BUILDPDB/BUILDPD3
and WEEKBLD/MONTHBLD logic.
TYPE74 New variable, TAPEMNTS, counts the number of tape
mounts detected during the interval for each tape
device. Since TAPEMNTS now exists, the duration
of Mount Pending, DEVMTPTM is also now created.
If a Mount is Pending (MTP) at the beginning or
the ending of the interval, variables MTPATBET
and MTPATEND are "Y". Only if MTP does not exist
at either the begin or end will MXG calculate the
average mount pending per tape mount per device,
new variable AVGMTPTM.
(Only when both flags are blank do we know for
sure that the mount pending time duration and
the number of mounts are exactly matched.)
TYPE76 SAMPSKPD variable if samples were skipped
TYPE77 SAMPSKPD variable if samples were skipped, and
WAITS was PIB2., is now moved to a PIB4. field at
the end of the record.
TYPE792 R792EXCP was expanded to four bytes and moved to
the end of the record.
TYPE79C New variables R79FLAG, R79CPBY, R79CCPTS added.
TYPE90 Variables MINBUFF and MAXBUFF are now reserved in
IPL SMF, SET SMF, or SETSMF Operator Command
event records. No real loss here, since the
maximum number of buffers each interval is always
in TYPE23 dataset.
TYPE96 The new type 96 record was already supported in
MXG 10.3, as TYPETIRS, for this record is created
to account for "The Integrated Reasoning System"
users resource usage. However, the name in the
SMF manual for type 96 is "Cross Memory Service
Provider Charge Back", is inaccurate; it's TIRS!
BUILDPDB Logic was changed to use the type 26 OFFLPURG
field to detect purge records created by the
SPOOL Transfer/Offload program. New variables
SUBMUSER DUPJBDLY OFFLPURG ACCOUNT1-ACCOUNT3
LENACCT1-LENACCT3 and NRACCTFL were added to the
list of variables kept from TYPE26J2 (in member
IMACPDB). The order of datasets in the MERGE for
PDB.JOBS was changed, moving GOOD26J2 to be first
so that the TYPE26 ACCOUNTn fields will be used
in PDB.JOBS when they exist. (Leaving it where
it was could have blanked out valid ACCOUNTn data
since the SAS MERGE uses the values from the last
dataset, for sites not yet on MVS/ESA 4.3!)
RMFINTRV The new TYPE71 CPUPAGTM is added to RMFINTRV as a
separate variable, and is also included in CPUTM,
the sum of all captured CPU time; this will cause
and increase in the capture ration of RMF.
Change 10.260 Negative CPUACTTM and PCTCPUBY in TYPE70 under PR/SM can
VMAC7072 occur if the LPARNUM for the PHYSICAL partition segment is
Jan 24, 1993 non-zero and equal to a real LPARNUM value. The LPARNUM
for the PHYSICAL partition should always be zero, but at a
few sites it was erratically non-zero (which also caused
RMF reports to fail!). IBM APAR OY55704 and PTF UY87723
acknowledge and fix the problem, but MXG now protects the
data by inserting:
IF LPARNAME='PHYSICAL' THEN LPARNUM=0;
following the @; which follows the INPUT of LPARNUM.
Thanks to Tom Hatcher, US Sprint Dallas, USA.
Thanks to MP Welch, US Sprint Dallas, USA.
Change 10.259 There are now always 255 CHPID segments in type 73 record
VMAC73 even though there might not be 'FF'X CHPIDs defined in the
Jan 24, 1993 system. Now, MXG only outputs TYPE73 observations if the
CHPID is defined. APAR II06736 discusses this problem and
suggested two possible algorithms; the above is the second
algorithm in that APAR (beware - there are typo's in the
1st algorithm - Reference to SMF73FGS should be SMF73FG3,
and the bit field names SMF73REP and SMF73VLD do not exist
in the SMF manual - due to OCO!).
Thanks to John Mattson, National Medical Enterprises, USA.
Change 10.258 Variable QW0023DN was not kept in dataset T102S023, which
VMAC102 caused a warning when using ANALDB2R report PMTRN01. It
Jan 23, 1993 is reserved, and should not have been referenced in the
report, but the better fix was to now keep it!
Thanks to Andre Henry, AG 1824, BELGIUM.
Change 10.257 MXG RMF/CMF processing has been enhanced to validate that
VMAC7072 each section actually exists in the physical record. The
VMAC71 previous validation only checked that the section offset
VMAC73 and number of sections was non-zero, but did not protect
VMAC74 for truncated records nor for unexpected invalid records.
VMAC75 Now, if a bad record is encountered, a message will be
VMAC76 printed on the SAS log, the bad record deleted, but the
VMAC77 processing will continue, avoiding the STOPOVER abend!
VMAC78
VMAC79
Jan 23, 1993
Thanks to Phil Hathaway, Spartan Stores, USA.
Change 10.256 SMF type 70 INPUT STATEMENT EXCEEDED RECORD LENGTH occurs
IMACTCP with IBM's TCP/IP SMF record because the IBM sample member
Jan 22, 1993 used record ID of 70! IBM APAR PN34837 addresses this bad
choice, and IBM has now assigned SMF record numbers 118
and 119 to the TCP/IP product SMF records. MXG has thus
changed its default values in IMACTCP to agree with this
IBM correction. To delete the unwanted TCP/IP records,
you can add this code to member IMACFILE:
IF ID=70 AND LENGTH LE 194 THEN DELETE;
until you get the ID of TCP/IP records corrected.
Change 10.255 ICF Catalog cells C4x and C9x were not printed because
VMAC6156 the test prior to their PUT statements tested for 'C4' or
Jan 14, 1993 'C9' (without the X indicator to test for hex value!). New
Feb 17, 1993 variables DATANAME/DATAVOL1 and INDXNAME/INDXVOL1 for VSAM
entries contain the VSAM Data Component name, First Data
VOLSER, Index Component name, and First Index VOLSER. New
variables DATACLAS, MGMTCLAS,and STORCLAS are non-blank
if the Optional SMS Subcell for a Cluster record is found.
Thanks to Steve Dzielak, First Interstate Bank of Arizona, USA.
Change 10.254 Dates last referenced and expiration in TTOC section of
VMXGHSM HSM BCD/MCDS records were wrong. Replace these lines:
Jan 14, 1993 TTOCDLR PD3.
+1 TTOCEFLG PIB2.
TTOCXPDT PD3.
@;
and the subsequent lines that reference TTOCDLR/TTOCXPDT
with these lines:
TTOCDLR1 PIB1.
TTOCDLR2 PIB2.
+1
TTOCEFLG PIB1.
TTOCXPD1 PIB1.
TTOCXPD2 PIB2.
@;
TTOCDLR =TTOCDLR1*1000+TTOCDLR2;
TTOCXPDT=TTOCXPD1*1000+TTOCXPD2;
Unrelated, the line formatting TTOCTYP $HEX2. should be
deleted, as this is an EBCDIC field.
Thanks to Chris Fenn, Andersen Consulting, ENGLAND.
Thanks to Chris Weston, SAS Institute Europe, GERMANY.
Thanks to John Dalton, SAS Institute, ENGLAND.
Change 10.253 QW0022OS, the DB2 optimizer's cost estimate, was supposed
VMAC102 to have been changed by Change 10.174, but the code was
Jan 14, 1993 not changed until now. Sorry for this carelessness!
Thanks to Matthew Bildstone, Sun Life, ENGLAND.
Thanks to Chris Weston, SAS Institute Europe, GERMANY.
Change 10.252 A spelling error; the "by incrd" in the AXIS2 statement
GRAFLPAR should have been "by &incrd", as incrd is a macro variable
Jan 14, 1993 and was missing the ampersand.
Thanks to Chris Weston, SAS Institute Europe, GERMANY.
=Changes thru 10.251 were included in MXG PreRelease 10.4, Jan 8, 1993==
Change 10.251 Preliminary revised support for RACF & TOPSECRET type 80
EXTY8001 SMF record. The original TYPE80 data set built by MXG is
EXTY8002 valid, but it is unwieldy for analysis, as it creates one
EXTY8003 observation for each data segment in each type 80 record,
EXTY8004 and left the decoding of the RACFDATA string to you! This
EXTY8005 revision recognizes that each type 80 record represents an
EXTY8006 event, and the data segments for each event should be kept
EXTY8007 in a single observation. Instead of one TYPE80 dataset,
EXTY80A the new logic creates nine datasets; seven for each RACF
EXTY80CM event category, (TYPE8001-TYPE8007), TYPE80CM for RACF
IMAC80A Commands, and TYPE80A in case records with no segments are
TYPE80A encountered. The data segments in the TYPE80CM Command
VMAC80A dataset are not decoded in this implementation, but the
Jan 7, 1993 command and its issuer, etc., are decoded. Some variables
may be formatted, and some revisions are likely, but the
initial testing suggests that reporting and selection of
RACF data will be much easier with this revision. The 7
event categories and their new dataset names are:
TYPE8001 Job Initiation or TSO Logon
TYPE8002 Resource Access
TYPE8003 End of Volume
TYPE8004 Rename Data Set
TYPE8005 Scratch Dataset or Tape Volume
TYPE8006 Delete Volume one of Multi-Volume
TYPE8007 Define Data Set or Tape Volume
TYPE80CM RACF Commands Issued
TYPE80A Catchall for records with no data segments
Thanks to Joe Faska, Depository Trust, USA
Change 10.250 Twenty-five more ADOC members (Documentation members, one
ADOCx for each "Product" which described all data sets that MXG
Jan 7, 1993 creates from that product data records) have been added.
Most contain sample PROC PRINTs, but not all are fully
completed. However, when an ADOC member exists, it is the
first place to look for notes and contents of MXG datasets
Each ADOC member corresponds to a Section of Chapter 40.
Change 10.249 Existing formats MG080EV, MG080IA, MG080QU, and MG080TY
FORMATS were updated for new values for RACF 1.9.
Jan 7, 1993
Change 10.248 VMXGSUM is enhanced with the SUMLONG function, which is
VMXGSUM the same as the SUM function, but stores the results in an
Jan 7, 1993 8-byte field instead of a 4-byte field. This is rarely a
problem with performance/capacity data, but in chargeback
applications with large dollar amounts, pennies could be
lost with only 4-byte stored variable lengths.
Thanks to Chuck Hopf, Primerica, USA.
Change 10.247 The ESCON Multi-Image Facility (EMIF) Feature for MVS/ESA
VMAC73 4.2.2 added 8 bytes to each CHPID section in type 73 SMF
Jan 6, 1993 record, but MXG failed to skip over the new fields, which
caused alternating good and invalid observations, and MXG
had good records only for the first 128 CHPIDs! As best
as I can discover, there was no TNL to the SMF Manual for
this IBM change! The correction is to insert xx lines as
shown in the following corrected code (note this is the
last PCHANBY input, at the bottom of VMAC73);
exists PCHANBY PIB4. /*SMF73BSY .... */
exists @;
insert SKIP=LENCHDS-8;
" IF SKIP GT 0 THEN DO;
" INPUT SMF73PBY PIB4.6 /*CHANPATH*BUSY TIME*SINCE LAST*/
" SMF73PTI PIB4.6 /*CHANPATH*MEASUREMENT*INTERVAL*/
" @;
" SMF73PBY=1024*SMF73PBY; /* CVT FROM 1024 USEC UNITS */
" SMF73PTI=1024*SMF73PTI; /* CVT FROM 1024 USEC UNITS */
" SKIP=SKIP-8; /*this line is now correct in this change */
/*and in VMAC73, but in 10.4 and 10.5 it */
/*was wrong (SKIP=LENCHDS-8;) in both! */
" IF SKIP GT 0 THEN INPUT +SKIP @;
insert END;
exists IF CHANIND ='..1.....'B THEN CHANTYPE='BLOCK MUX';
Thanks to Linda Lokkesmoe, West Publishing Company, USA.
Change 10.246 IBM's type 36 record has the subtype bit on, indicating
UTILGETM the record contains a subtype in bytes 19-20, but the
VMACSMF subtype is an EBCDIC 00 (hex F0F0) instead of hex 0000,
Jan 9, 1993 and UTILGETM threw the record away. Now, when an invalid
subtype value is found, a message is printed on the log,
and INDEXST=1 is set so that the record will be written.
VMACSMF was also changed to input type 36's subtype as an
EBCDIC number. This change was revised after MXG 10.4.
An "ARRAY SUBSCRIPT OUT OF RANGE" can occur with MXG 10.4;
the statement SUBTYPE=1; should have been INDEXST=1.
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
Change 10.245 Support for Legent's ASTEX Trace Record. This data is not
EXTYASXT an SMF record, but is sent to a flat file that must be
IMACASXT first uncompressed by a Legent-provided program and then
TYPEASXT decoded by these MXG members. See the comments in member
VMACASXT VMACASXT, which includes the JCL example for the two-step
Jan 5, 1993 process. (Note that the SMF record created by ASTEX has
been supported for years by MXG members VMACDMON, named
DMON in MXG because it used to be DASDMON).
Thanks to John Rosza, Depository Trust Company, USA.
Change 10.244 Support for VM/ESA 2.0 creates five new data sets:
EXSYTCUM VXSYTCUM - LPAR Management time by Physical CPU
EXSYTCPM VXSYTCPM - Channel Path Busy by CHPID
EXPRCCFN VXPRCCFN - ADD access to CRYPTO facility
EXPRCCFF VXPRCCFF - REMOVE access to CRYPTO facility
EXIODALS VXIODALS - 3495 Automated Tape Library Statistics
VMACVMXA (only partially decoded, awaiting 3495 manual
Jan 4, 1993 because that's where the record is documented)
Perhaps of more importance, VM/ESA 2.0 added a number of
new variables to several datasets:
VXAPLSRV - 25 new counters now exist
VXIODDEV - new measure SCDATIM "Device Active-Only time"
VXMTRDDR - IBM no longer spans across physical blocks!
VXMTRDEV - RDEVSHAR if device is shared
VXMTRPAG - FBA if device is FBA
VXMTRPRP - PFXIDVER identifies CPU model version number
in this and other CPU-related datasets.
VXSYTUSR - SYSDIALD/SYSLUCNT for dialed/SNA connected
users, and flag in VXUSEATE/VXUSELOF/VXUSEACT
and VXUSELOF data sets.
VXUSELOF - Major enhancement adds resources consumed to
the existing (but previously useless) LOGOFF
event record so that it now describes the
resources used by each CMS machine session.
Not only resources (CPU, SSCH, Reserved Pages)
but now a session logon time CALTODON, RACF
group VMCGRPN, and user accounting number
(only 8-bytes!) VMDACTNO make this a much more
attractive source of session-level resources
for accounting and capacity planning.
This description only hits the highlights. The complete
list of new variables is given in member DOCVER10 for the
data sets beginning with VX - twenty five MXG data sets
have new variables!
This code has been tested with real VM/ESA 2.0 data that
was provided by IBM (with my sincere thanks!), but it did
not contain any of the new record types, so not all of the
code has been tested!
An existing error in MXG 10.1 was also corrected; the
second occurrence of "MACRO _MSTOASS ..." should have
been ASI instead of ASS in three places in that line.
This error caused a 180 syntax error.
Change 10.243 As noted on page 10 of MXG NEWSLETTER TWENTY-TWO, SAS ZAP
VMXGVTOC V6-SYS-FILE-4673 (on June 1992 Usage Notes Tape) is needed
Dec 29, 1992 for SAS 6.07 to avoid "CRITICAL ERROR IN VTOC" messages.
Change 10.242 Archaic SAS 5.18 produces syntax error with TPX data due
DIFFTPX to incorrect parsing, but the error can be circumvented by
Dec 29, 1992 re-ordering the PROC SORT to read:
PROC SORT NODUP %VMXGFOR DATA= _LTPXINT ;
Thanks to Mike Marek, Kraft General Foods, USA.
==Changes thru 10.241 are included in Dec 13, 1992 MXG PreRelease 10.3A=
Change 10.241 The JCLMNTH example did not contain the //SOURCLIB DD
JCLMNTH concatenation, and the %INCLUDE SOURCLIB(MONTHBLD); which
Dec 17, 1992 should have been the last line of SAS code was missing.
Thanks to Barry Lampkin, Polaroid, USA.
Change 10.240 SMFSMALL step JCLTEST6 may produce "ARRAY OUT OF RANGE"
UTILGETM error with SMF record types of 127, 128 or 255, depending
Dec 16, 1992 on subtype value, because the index calculation was wrong.
INDEX=(ID+1)*256+SUBTYPE; must be INDEX=ID*256+SUBTYPE+1;
and ELSE IF ID LE 128 ... must be ELSE IF ID LE 127 ....
Thanks to Tom Gillis, Southern National Bank, USA.
Change 10.239 ASTEC variable RDMT must be input as PIB4. vice PIB4.6,
VMACDMON and the statement RDMT=RDMT*128; must be deleted, as the
Dec 16, 1992 units are seconds, not 128 microseconds. Variables
RDTBK1 thru RDTBK4 must be input as PIB4.2 vice PIB4.
Thanks to Chris Nielsen, Wells Fargo Bank, USA.
Change 10.238 VM/ESA 2.0 MONWRITE data causes SFM-OR-CRR SAMPLE message
VMACVMXA and then PROBABLE DATA LOSS message if you have enabled
Dec 15, 1992 the Application Server data. (The MXG protection for new
APL data was incorrectly coded.) Change the line reading
SKIP=SKIP-CALDATLN-8;
to these two lines:
INPUT +SKIP @;
SKIP=0;
With this change, MXG tolerates VM/ESA 2.0 MONWRITE data
records without error, skipping over the new fields and
records. MXG will exploit VM/ESA (i.e., decode new data)
shortly; work is in progress.
Change 10.237 The message when you had more than 9 account fields is
IMACACCT now only printed five times, and the text was made more
Dec 15, 1992 clear.
Thanks to Ann Wheeler, American President Lines, USA.
Change 10.236 All occurrences of PIBR. should have been PIB4. I thought
VMACM204 this one had been fixed, but it slipped through into 10.3!
Dec 15, 1992 This causes FORMAT PIBR unknown during JCLTEST6 execution.
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
==Changes thru 10.235 are included in Dec 13, 1992 MXG PreRelease 10.3==
Change 10.235 Existing graphic reports were enhanced in GRAFLPAR when
GRAFLPAR is executed under SAS 6.07 or later using PROC GPLOT with
Dec 13, 1992 filling colors in place of PROC GCHART with bar charts, as
we exploit SAS 6.07 features.
Thanks to Chuck Hopf, Primerica, USA.
Change 10.234 MXG processing message when MXG detects use of EXCLUDE in
VMAC110 CICS records is enhanced by printing a table of expected
Dec 13, 1992 values of Data Length and Number of Fields (MCTSSDRL and
MCTSSDCN) in the MXG error message to help you compare the
actual and expected values. This has been the number one
technical problem in MXG CICS record processing this year
sites CICS person installed a CICS monitor which excludes
fields, but the MXG person doesn't find out until MXG runs
against the modified data! The new error text should help
resolve the error without additional phone calls!
Change 10.233 Variables USER, SQLUSER & SQLDBMAC were added to VMSQLxx
TYPEVM datasets. SQLDBMAC is the full name of the SQL database
Dec 13, 1992 machine (and is stored in from USER after line 028200).
SQLUSER is TERM in VMSQLTRM, is SYSTEM in VMSQLSYS, and is
INIT in VMSQLINI, but it has meaning in VMSQLUSR where it
is taken from the connect process and is sometimes a
different user. USER is always SQL/DS in the -INI, -SYS,
and VMSQLTRM datasets, and at present useless, but it is
kept for consistency and possible future changes by IBM!
Thanks to Norbert Korsche, OMV-AG, AUSTRIA.
Change 10.232 APPC type 33 account record header offsets were off by 6
VMAC33 bytes (the subtype and length of header were omitted). The
Dec 13, 1992 offsets for OFFPROD thru NRTPUS in lines 68-76 must have 6
added to each value. Additionally, the TP name field is
variable length, with a maximum of 64 bytes, so it is now
input conditionally:
SMF33TPL PIB2. @;
IF SMF33TPL GT 0 THEN
INPUT TPNAME $VARYING64. SMF33TPL @;
Thanks to Robin Luff, Dun & Bradstreet Europe, ENGLAND.
Change 10.231 Support for Velocity Software's XAMAP history data files.
EXXAMCPB MXG creates several datasets from the four history files.
EXXAMCPT This code has been tested with actual XAMAP data records
EXXAMDEV and reviewed for reasonableness, but there are many fields
EXXAMSYS and lots of code!
EXXAMUSR See comments at the beginning of VMACXAM for instructions
IMACXAM for processing the four XAMAP files.
TYPEXAM Jul, 2003: EXXAMSYS, EXXAMTCP, EXXAMUSR members were
VMACXAM removed in MXG 21.03 as multiple datasets
Jan 4, 1993 are now created from those XAM data.
Change 10.230 Boole & Babbage CMF type 78 record variable R783PT-number
VMACCMF of times channel path was taken- is in error in CMF 4.3.3
Dec 11, 1992 until you install Boole's fix BAB1081.
Thanks to Bill Stoneberg, National-Oilwell, USA.
Change 10.229 STC 4400 SMF record variable LSBECON1/2 documentation was
VMACSTC incorrect; these are not connect durations but rather are
Dec 11, 1992 the LSM number and Panel number, and they are six bytes
instead of four bytes! They are now input $CHAR6., format
$HEX12., and were removed from the IF test for OUTPUT of
STCLMU dataset. Also, variable LSMNUMBR is created.
Thanks to Dean Ruhle, J.C. Penny, USA.
Change 10.228 MXG summarization of TYPE70PR assumed Effective Dispatch
ASUM70PR time was in TYPE70PR, but sites without the APAR or sites
Dec 1, 1992 with MDF (which does not yet record Effective Dispatch)
ended up with LPAR management time equal to LPAR dispatch
time. Delete the sixteen lines which set LPnUEDTM=0, and
the overhead time will be zero/missing instead of wrong!
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 10.227 SAS 6.07 no longer supports the XSWISS font name, so all
ANALVARY occurrences of XSWISS were changed to SWISS. This change
DOCGRAF works with SAS 6.06, 6.07, 6.08 and later. However the
GRAFBNCH SWISS font name is not supported in SAS 5.18, so if you
GRAFCICS are still on 5.18, you must change SWISS back to XSWISS
GRAFRMFI in these SAS/GRAPH examples.
GRAFVM
Dec 1, 1992
Thanks to Jim Border, Packaging Corporation of America, USA.
Change 10.226 The MXG Tape Mount Monitor has been modified to recognize
ASMTMNT the MIM Pseudo Mount event (see Change 10.200), to create
a TMNTRTRN value of 3 when the Pseudo event is recognized.
Dec 1, 1992 This change has been tested in a non-MIM shop, but the MIM
site tests have not been completed to verify that in fact
a record with TMNTRTRN=3 is created. Please verify!
Change 10.225 The BY list for the WEEK.ASUM70PR dataset should not have
WEEKBLD variables LPARNAME LPARNUM, as these variables don't exist
Dec 1, 1992 in the summarized ASUM70PR dataset.
Thanks to Wayne Bell, National General Insurance, USA.
Change 10.224 JES3 TYPE84 INPUT STATEMENT EXCEEDED RECORD LENGTH error.
VMAC84 a. Remove the line containing +4 immediately following
Dec 1, 1992 JMFJSMXJ $CHAR8. ....
b. Three lines later, change LOCJSOF=LOCJSOF+76; to read
LOCJSOF=LOCJSOF+72;
This MXG error uncovered two other IBM errors. JMFGSNUM
is zero, but there is a GMS/MDS summary entry present,
but the zero causes MXG to not input the entry. Also
noted, R84JSNAM has two leading blanks for DSP names.
These are being reported to IBM for repair.
Thanks to Ellen Ulrich, Texas Instruments, USA.
Change 10.223 Change 10.138 changed ELSE IF MONITOR='JCL' THEN DO; to
VMACROSC ELSE IF MONITOR='JCL' OR MONITOR='JCK' THEN DO; but only
Nov 17, 1992 in one line. The 2nd occurrence needed to be changed also!
Thanks to Norbert Korsche, OMV-AG, AUSTRIA.
Change 10.222 SIMWARE support missed two undocumented bytes, apparently
VMACSIM added for alignment. After the INPUT of VUXBPGRM $CHAR20.
Nov 17, 1992 insert a line with +2 to skip the extra bytes.
Thanks to Mike Roybal, First National Bank in Albuquerque, USA.
Change 10.221 DCOLLECT disk capacity dataset DCOLCAPD variable UCTOTAL
VMACDCOL contains the volume capacity in Kilo-bytes in the DCOLLECT
Nov 16, 1992 record, but was documented as tracks! MXG now multiplies
UCTOTAL by 1024 (to convert Kilo-bytes to bytes) and then
added UCTOTAL to the list of variables formatted MGBYTES
so that the capacity will print 601M for a 3380 (that has
615,472 Kilo-bytes, or 630,243,328 bytes capacity.
Thanks to Frank Vessell, ITT Consumer Financial Corporation, USA.
Change 10.220 VMPRF for VM/ESA now counts a user as "ACTIVE" if either
VMACVMXA the user consumed some virtual CPU time (VMDVTIME GT 0),
Nov 13, 1992 or the user was not in the Dormant List at the end of the
monitor interval (VMDSLIST NE '0B'X). MXG formerly used
only the CPU test to count ACTIVE users, but now the test
for ACTIVE has been expanded to include the VMDSLIST test.
Note, however, that the whole issue of counting VM users
is questionable, since the interval over which the count
is taken completely controls the number of "ACTIVE" users.
This site examined VXBYUSR with different intervals:
5-min interval active count in the 150 range
15-min interval active count in 240-440 range
30-min interval active count in 700-800 range
Thanks to Anne Schroeder, Amway Corporation, USA.
Change 10.219 IDMS DBKDBKEY was incorrectly documented by CA. Instead
VMACIDMS of the DB Key in four bytes, the key is only the first 3
Nov 12, 1992 bytes, and the fourth byte is the DBKEY Line Index. MXG
now inputs DBKDBKEY as PIB3, and creates the new variable
DBKDBINX as the fourth byte.
Thanks to Sal Fazzino, General Electric Capital Corporation, USA.
Change 10.218 MXG 10.2 only. In adding new variables to support LPARS
ASUM70PR 9 thru 16 (for Amdahl MDF), several variables were not
Nov 11, 1992 properly RETAINed due to spelling errors, causing the
ASUM70PR dataset to be corrupted - the effective dispatch
times LPxUEDTM and its associated LPAR management time
LPxMGTTM will be missing except in the last LPAR, and this
caused CPUOVHTM and PCTOVHD to also be incorrect. The
total Partition Dispatch Time, LPxUPDTM, fortunately, was
not affected, so it is possible you may have not noticed
this error. Once you make this change, you should rebuild
ASUM70PR in each PDB that was created by MXG 10.2, by
allocating the //PDB DD DSN=dsname,DISP=OLD, and then
%INCLUDE SOURCLIB(ASUM70PR) to rebuild ASUM70PR. The
correction is to look at the end of the RETAIN statement,
and correct the spelling so that there are four sets of
sixteen variables, each with names LPxUPDTM LPxUEDTM
LPxNRPRC and LPxMGTTM, where x=1,2,...,8,9,A,B,C,D,E,F,G.
Another minor correction, the 2nd occurrence of LPDMGTTM
in the TIME12.2 statement should be LPGMGTTM, and four
lines earlier, LPDUEDTM should have been LPGUEDTM.
Thanks to Ron Kopfer, First Interstate Bank of Arizona, USA.
Thanks to Norbert Korsche, OMV-AG, AUSTRIA.
Change 10.217 MXG 10.2 only. MXG Tape Mount Monitor was changed in 10.2
ASMTMNT to default to MVS/ESA, but the SYSPARM parsing was not
Nov 2, 1992 updated, which caused an ASM error if you specify TEST in
SYSPARM (to write the records to a flat file). The parse
logic values are now changed to read:
AIF (K'&SYSPARM LT 7).NOSYS
&ESA SETB ('&SYSPARM'(5,3) EQ 'ESA')
AIF (K'&SYSPARM LT 12).NOTEST
&TEST SETB ('&SYSPARM'(9,4) EQ 'TEST')
AIF (K'&SYSPARM LT 16).NONUM
&C SETC '&SYSPARM'(14,3)
Change 10.216 CICS Version 2 Global Performance Record wasn't protected
VMAC110 for EXCLUDE logic, and a record with excluded fields could
VMAC110M cause MXG to ABEND with INPUT STATEMENT EXCEEDED RECORD
Nov 2, 1992 message. Additional testing logic should now prevent this
ABEND and alert you that EXCLUDE was used in the CICS MCT.
Thanks to Ron Kirk, Union Carbide, USA.
Change 10.215 NPM Release 1.5.1 added six new subtypes, causing "INPUT
EX028EV6 STATEMENT EXCEEDED RECORD LENGTH" error. That error can
EX028EV7 be circumvented by replacing both occurrences in VMAC28 of
EX028INE ELSE IF 21X LE NPMSUBTY LE 35X THEN ....
VMAC28 with
Oct 30, 1992 ELSE IF 21X LE NPMSUBTY LE 25X OR
31X LE NPMSUBTY LE 35X THEN ....
Subtypes 26x,27x,28x,29x are session monitor exception and
exception resolution events for applications, nodes, LUs&
LU groups, and create new datasets NPMEVSAA and NPMEVSAL.
(It was the unexpected fall-thru by a NPMSUBTY=26x record
that caused the MXG ABEND.) Subtypes 82x and 83x report
interval frame relay resources in new dataset NPMINFRP.
IBM really blew this change. While the June, 1992 "TNL"
SH19-6835 supplement to SC31-6835 (the NPM "SMF" manual)
described the new records, the supplement was not SLSS'd
to anyone, so it took an MXG user to ABEND to alert me to
call one of the two remaining NPM IBM'ers in the USA (NPM
is now developed in Rome), who was able to fax me the six
critical pages to add the support the next day, but IBM
Publications is still researching why I didn't
automatically get the change so that it could have been in
Newsletter 22 last summer!
Thanks to Adrienne Wijlaars, Belastingdienst Automatiser, NETHERLANDS
Change 10.214 DFSORT Release 12 added new fields describing Hiperspace
VMAC16 and Data Space usage, PROC Step name, input and output
Oct 28, 1992 DSNs and their first VOLSER, performance group number, the
average record length, and flags if HIPERSORT, DATASPACES,
and/or Work Datasets were used. Additionally, counts of
records and bytes in and out that were previously 4-bytes
were relocated and expanded to 8 bytes.
Change 10.213 ABEND A78-RU FREEMAIN-can create type 30 SMF record with
VMAC30 incorrect INITTIME and REND (Reader End) timestamps. IBM
Oct 28, 1992 is aware but has no fix at present. The INITTIME contains
the initiator start time (not the step start time), and
REND contains the initiator start completion time (not the
end of Read-in), and hence in this defective record the
INITTIME is less than REND! (Note that INITTIME can be
less than READTIME, because READTIME is taken where the
job originally read-in, and with NJE that could be in a
different time zone!). These incorrect time stamps can be
detected and corrected with this circumvention to set an
INITTIME closer to the truth!
IF . LT INITTIME LT REND THEN DO;
INITTIME=DHMS(DATEPART(SMFTIME),0,0,LOADTIME);
IF INITTIME GT SMFTIME THEN INITTIME=INITTIME-86400;
END;
Part of this problem has been reported to IBM under APAR
OY27665 (1989!), which has no PTF and was "CLOSED - SUG",
meaning its only a suggestion to the developers!
Thanks to J. G. Vlietstra, Ultramar Canada, CANADA.
Change 10.212 New variables SPMSCTST and SPMSXSQN are created, and old
FORMATS variables SPMSEL1,EL2,SL1,SL2,SL3 were deleted, and format
VMACSPMS MGAMDCS and MGAMDDT were added to decode SPMSCTST,SPMSDTYP
Oct 27, 1992 respectively. This completes Change 10.069.
Thanks to Joseph G. Ogurchak, Westfield Companies, USA.
Change 10.211 DB2 Trace variable QW0145OB in dataset T102S145 has value
VMAC102 of QW0145DB; statement QW0145OB=QWX145DB should have been
Oct 26, 1992 QW0145OB=QWX145DB. Variables QW0141TX,QW0142TX,QW0145TX
are now input as $VARYING200 (were only 100) to be same as
the SQL text field in the other audit trace records.
Thanks to Jorn Fledelius, Kommunedata I/S, DENMARK
Change 10.210 Several DB2STAT0 & DB2STAT2 variables were deaccumulated
DIFFDB2 that should not have been. (Because IBM often fails to
Oct 26, 1992 identify whether fields are accumulated or not, only real
data values can prove to DIF() or not to DIF(). Most of
these fields are from Distributed DB2, and only now do we
have test data with non-zero values with which to validate
accumulation.)
DB2STAT0 variables which must be removed from DIFFDB2:
QWSBSACT QW2BSACT QW3BSACT QW4BSACT QW5BSACT
DB2STAT1 variables which must be removed from DIFFDB2:
QB1TWFM QB2TWFM QB3TWFM QB4TWFM
QDSTQDBT QISEKT QISESKPT QISTRCUR QTCURPB QTPUBDD
QTSLWDD and all QLST fields: QLSTABRR QLSTABRS
QLSTBRBF QLSTBROW QLSTBTBF QLSTBRBF
QLSTBROW QLSTBTBF QLSTBYTR QLSTBYTS QLSTCBLB QLSTCNVQ
QLSTCNVR QLSTCNVS QLSTCOMR QLSTCOMS QLSTMSGR QLSTMSGS
QLSTROWR QLSTRBND QLSTROWS QLSTSQLR QLSTSQLS QLSTTRNR
QLSTTRNS
Thanks to Warren E. Waid, JC Penny, USA.
Change 10.209 Variables A17FLOC and A17FNAM were not in the KEEP= list
VMAC110 for the CICFCR statistics dataset.
Oct 19, 1992
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 10.209A New variable PCTRDYWT was not in the KEEP= list for the
VMAC7072 TYPE70 dataset.
Oct 19, 1992
Thanks to Tom Elbert, John Alden Life Ins, USA.
==Changes thru 10.208 are included in Oct 18, 1992 MXG PreRelease 10.2==
Change 10.208 Something is wrong with this archaic member, for it now
VMXGVTOC has "UNINITIALIZED VARIABLE" messages that I could not
Oct 18, 1992 resolve in time for building this tape, but since MXG
strongly recommends the use of ASMVTOC/VMXGVTOF instead
of this old technology, I hoped this warning is enough!
Change 10.207 All of the MACRO _Txxxyyy definitions should have started
VMAC102 with DATA _Vxxxyyy but the "DATA" was missing. The JCL
Oct 18, 1992 example showing how to use the _Txxxyyy macros will now
execute correctly!
Thanks to Merlin Beeching, Nuclear Electric, ENGLAND.
Change 10.206 WEEKBLD and MONTHBLD were updated so that all of the PDB
WEEKBLD datasets created by the JCLPDB6 example are copied into
MONTHBLD your WEEKly and/or MONTHly PDB libraries. Note that it
Oct 18, 1992 is definitely NOT my recommendation that you build all of
these datasets monthly:
I do recommend that you create all of the WEEKBLD
datasets in your WEEKly PDB, but only build MONTHly the
PDB datasets that you need for monthly reports; often
only the PDB.JOBS, PDB.STEPS, PDB.PRINT and
PDB.RMFINTRV datasets are needed to feed monthly
billing validation. This is especially true if you
have implemented the TREND database and have weaned
your management from monthly to WEEKLY trending (as
exemplified by the MXG report examples in Chapter 42 of
the 1984 MXG Guide!).
However, so you don't have to rummage around in BUILDPDB
or ASUM members to find the MXG Sort Order, they've all
been added so you can comment out the datasets you don't
want created. That's safer and easier for both of us!
The BUILDPDB-created PDB datasets that were added were
PDB.TYPE72MN, PDB.NJEPURGE, PDB.TYPETMNT, & PDB.TYPE0203,
and the ASUM.... PDB Summary datasets PDB.CICS,
PDB.ASUMDB2A, PDB.JOBSKED, PDB.ASUM70PR, and PDB.TAPEMNTS,
which are built by their corresponding ASUM.... member
ASUMCICS, ASUMDB2A, ASUMJOBS, ASUM70PR, ASUMTMNT, have
also been added. Do check your USERID.SOURCLIB for an
EXPDBWEK member you might have added to do some of this
yourself, and avoid duplication!
If you do use MONTHBLD, make sure you use the JCL example
in JCLMNTH instead of the earlier JCL still in JCLMONTH.
JCLMNTH needs only one tape drive to create your monthly
PDB from your dailies and weeklies, and runs much faster.
It does require more temporary DASD space than the old
example, but the saving in tape drives AND tape mounts
is substantial with JCLMNTH. Everyone who has tried it
has kept on using it in production.
Change 10.205 IMS log variable NMSGPROC, IMSTRAN is wrong, but only in
TYPEIMSA MULTRANS='Y' observations, where it should have been set
Oct 17, 1992 back to 1, since a total of NMSGPROC observations will be
created by the MERGE logic. Insert NMSGPROC=1; after the
MULTRANS='Y'; statement to correct the value. Users report
correct response times and faster run times with the IMS
"Appended" Log processing, and it is so much better that
MXG sites MUST use ASMIMSLG/JCLIMSLG/TYPEIMSA instead of
the old TYPEIMS member for IMS log processing.
Thanks to Lonnie T. Rimmer, Philip Morris, USA.
Change 10.204 IBM Changes to OPC records cause INVALID RECORD messages.
IMACOPC There appear to be two different versions of records from
VMACOPC OPC, but IBM did not update the Record Version Number in
Oct 17, 1992 the record, so there is a new _OPCVER macro in IMACOPC to
tell which version to expect. I don't know right now what
OPC version is which, but there are only two choices, a 0
for the old and a 1 for the new format. Try one, and if
it doesn't work, try the other. This text will be revised
when I know more, but the software has been tested with
data from both versions. The changes were the addition of
MT0JVT $16 after MT0OCC, MTDOPTS2 $1 after MTDOPTS, and
+2 after MTDDIATM (but only for MTDTYPE=9), and SPLITLEN
was changed from 71 to 36. One MXG error was found. The
test IF 8 LE MT0TYPE LE 9 should have tested MTDTYPE!
This site also discovered that the records in the EQQTROUT
file with record type of 01, 02, or 03 appear to be copies
of the Current Plan, but have not yet found description
of the format, nor an acknowledgement of the discovery!
Thanks to Brenda Rabinowitz, Prudential Securities, USA.
Change 10.203 Early 10.2 support for Candle's Omegamon II for VTAM V150
VMACOMVT failed with real data records; I gambled and lost when I
Oct 13, 1992 sent a few sites an Early 10.2 before the test data from
Candle finally arrived. The support has now been tested
and the real 10.2 (this one) does support that product.
However, as with all new product support, use with caution
and validate your own data values.
Change 10.202 A blank line in the Early 10.2 choked the ASSEMBLER that
ASMVTOC is fixed in this 10.2. However, ASMVTOC may not work with
ASMVTOCO MVS/ESA 3.1.3; Matt found it executed instantaneously and
Oct 13, 1992 wrote no records on his 3.1.3 system while it worked find
Oct 17, 1992 on his 4.2 system. Apparently the ESA 4.2 enhancement in
10.1 is the culprit, but since the MXG 9.9 version has no
problem with MVS/370 thru MVS/ESA 4.1, I have put the old
MXG 9.9 version of ASMVTOC in member ASMVTOCO for you old
timers!
Thanks to Matt Gallion, Tenneco, USA.
Change 10.201 Boole & Babbage CMF under MVS/ESA 4.2 contains incorrect
VMAC78 triplet R783CPDN in type 78 subtype 3 record, causing MXG
Oct 16, 1992 to create zero observations in the TYPE78CF dataset.
Field R783CPDN (MXG variable NRCPDS), the number of I/O
queueing data sections, is 4 but there are 8 sections in
the record! The length of SMF78DCS (MXG variable LENDCS)
does include those extra 4 sections, so while I believe
CMF should be fixed, it turns out that by a simple change
in MXG "SKIP" logic (the logic to protect for any future
data which might be added, and which had been "faked out"
by the incorrect value), MXG can support this CMF record
and simultaneously protect both CMF and RMF for this new
way of adding unused data segments to type 78 records!
(To Boole's credit, they looked at MXG logic, as they are
also an MXG customer, diagnosed the source of the zero
observations, and gave the MXG site an MXG circumvention
that is part of this change, even before they called me!)
Find the following lines in VMAC78 (note EXCLUDEed lines):
OFFCPDS PIB4.
LENCPDS PIB2.
NRCPDS PIB2.
@;
SKIP=LENDCS-(12+NRCPDS*LENCPDS);
IF SKIP GT 0 THEN INPUT +SKIP @;
DO _II_ =1 TO NRCPDS;
- - - - 39 line(s) not displayed -
END; /* END DO TO NRCPDS */
END; /* END DO TO NRDCSLCU */
and make it look like the following by move and insert:
OFFCPDS PIB4.
LENCPDS PIB2.
NRCPDS PIB2.
2nd: @;
these new lines ==> SKIP=OFFCPDS-12;
were changed ==> IF SKIP GT 0 THEN INPUT +SKIP @;
after copy DO _II_ =1 TO NRCPDS;
- - 39 line(s) not displayed - -
1st: END; /* END DO TO NRCPDS */
these old lines ==> SKIP=LENDCS-(12+NRCPDS*LENCPDS);
were copied ==> IF SKIP GT 0 THEN INPUT +SKIP @;
from above END; /* END DO TO NRDCSLCU */
Boole & Babbage now have PTFs BPM4428/BPM4428 to correct
the original error.
Thanks to Norvell Reeves, Boole & Babbage, USA.
Change 10.200 Legent's MIM product causes the MXG Tape Mount Monitor to
ADOCTMNT write a record with non-zero return code when MIM replies
TYPETMNT "WAIT" or "NOHOLD" to some allocation recovery events.
VMACTMNT
Oct 17, 1992 YOU MUST USE ONLY THE OBSERVATIONS WITH TMNTRTRN=0
TO COUNT AS TAPE MOUNTS IN A MIM ENVIRONMENT, OR AT
LEAST DISCARD MOUNTS WITH TAPMNTTM LESS THAN 5 SECONDS.
MIM manages tape drives across systems by "Plugging"
values into the UCB, and by propagating UCB status bit
values to all systems. MIM "allocates" all drives and
then doles them out to your jobs as needed. One of the
bits plugged by MIM is the Mount Pending, or MTP, bit. For
every allocation recovery scan event (each time a drive is
deallocated while jobs are in allocation recovery), MIM
intercepts messages and replies WAIT,NOHOLD for each job
that didn't get that device, and sends new UCB status bits
for that device to all sharing systems. MXGTMNT sees the
MTP bit change on these other systems, thinks a mount
event was seen and missed, and writes an SMF record,
setting a non-zero Return Code value in TMNTRTRN
(accidentally, a 1 for NOHOLD, a 2 for WAIT) for these
non-mount mount events.
Change 10.226 attempts to recognize these MIM non-mount
events (the UCBASID to zero and the UCB Allocated Bit is
On), and sets TMNTRTRN=3 for them, but that change has NOT
been validated, and one non-MIM site saw valid mounts with
TMNTRTRN=3, so you must verify. Since the minimum mount
time for a real tape mount is 5 seconds, I suggest that
you discard any TYPETMNT mount record with TAPMNTTM LT 5.
Further investigation is planned, and hopefully these MIM
pseudo-mount events can be explicitly identified.
As a result of this investigation, I have finally written
the long overdue documentation of the MXGTMNT monitor and
the datasets created from its SMF records, in the member
ADOCTMNT. Please review it for complete information.
Thanks to Ted Anderson, Kaiser Permanente, USA.
=Changes thru 10.199 were included in MXG PreRelease 10.2, Oct 12, 1992=
Change 10.199 MXG Installation instructions have been revised and are
INSTALL now contained in member INSTALL. JCL to allocate the MXG
JCLINSTL libraries (two source PDS, a SAS data library of FORMATS)
Oct 11, 1992 is contained in JCLINSTL. The references to SAS 5.18 have
been removed, and the philosophy of installation slightly
changed, as described in INSTALL and above in this member.
This is work still in progress, as the rewriting of the
MXG documentation begins in ernest!
Change 10.198 Execution under SAS 5.18 required several changes.
DIFFDB2 Although MXG Strongly recommends execution under SAS 6.07,
VMACOPC for those of you still struggling with Version 5 (you are
VMACAIM6 either still running MVS/370 or are you think you are too
VMACQAPM swamped to take a half-day to install SAS 6.07), MXG still
Oct 11, 1992 executes under SAS 5.18! Only TYPEQAPM (AS400 support)
is known to fail under 5.18 (it uses 6.07-only formats).
a.VMACOPC and VMACAIM6 were written using IN (1,2) logic,
but that syntax was not a part of 5.18, so the IN (,)
logic was replaced with OR logic.
b.DIFFDB2 initially failed under SAS 5.18 because its parser
failed on PROC SORT NODUP DATA=_LDB2ST0 %VMXGFOR; syntax!
Moving the %VMXGFOR to after the NODUP allowed 5.18 to
successfully execute. (This is really strange, because
there are numerous other PROC SORT statements with very
similar structure that did not fail!)
Change 10.197 Variable DEVCLASS has been added to TYPE74 so reports
VMAC74 for DASD (DEVCLASS=20X) or for TAPE (DEVCLASS=80X) can be
Oct 7, 1992 generated without a list of all devices in a class.
Change 10.196 TMS datasets have been enhanced to provide both capacity
TYPETMS5 measures and billing measures for tapes & tape data sets.
VMACTMS5 Dataset TMS contains one observation for each tape volume
Oct 7, 1992 with the count of files on that tape and the TAPEFEET for
that volume, and contains the DSNAME of only the first
data set on that tape volume. TMS is thus useful for the
capacity measurement of your tape library. The major part
of this change was to enhance dataset DSNBRECD so that it
now contains one observation for each tape data set with
the attributes and correct TAPEFEET for that dataset.
(Previously, DSNBRECD contained observations for only the
second and subsequent data sets on tape - the first data
set information was in TMS. Now, the data set information
from the first (and maybe only) data set in TMS has been
added to DSNBRECD so ALL of your tape data sets can be
billed directly from DSNBRECD.
Thanks to Chuck Hopf, Primerica, USA.
Change 10.195 Accounting summary report now has DDF headings suppressed
ANALDB2R if there is no Distributed data, and null values for one
Oct 7, 1992 of the SORTBY variables now prints "BLANK" vice a blank.
The owning and wanting plan were reversed in the Lock
Suspension Trace, and that report is now named the Lock
Contention Trace.
Change 10.194 Support for OMEGAMON II FOR VTAM V150 user SMF record.
EXOMVEXC Seven datasets are created from the record's subtypes:
EXOMVTBU OMVTEXCE - Exception Events
EXOMVTCT OMVTTBUF - Trend Interval Buffers
EXOMVTET OMVTTCTC - Trend Interval CTCs
EXOMVTLC OMVTTETE - Trend Interval End-to-End Response
EXOMVTNC OMVTTLCL - Trend Interval Local Controllers
EXOMVTVR OMVTTNCP - Trend Interval NCP
IMACOMVT OMVTTVRF - Trend Interval VRs
TYPEOMVT Code has been syntax checked, but no test records were
VMACOMVT provided by Candle as yet for validation.
Oct 7, 1992
Change 10.193 STC 4400 SILO HSC (subtype 7) SMF record variables have
VMACSTC been FORMATed, and some $CHAR1. variables were changed to
Oct 6, 1992 PIB1. numeric variables. New variables STC07FPS/STC07TPX
are created and contain the volume in the same format as
the MVS System (LSM ID, Panel, Row, Column display as
000:00:00:00.) Specifics:
- Variables changed from $CHAR1. to PIB1. in their INPUT
statement, and given format Z2. are these:
STC07SAC STC07SPN STC07SRO STC07SCO
STC07TAC STC07TPN STC07TRO STC07TCO
- Variables changed from $CHAR1. to PIB1. in their INPUT
statement, and given format Z3. are these:
STC07SLS STC07TLS
- Variables added to format statement as shown:
STC07FPS STC07TPS $12.
STC07TYP STC07RQS STC07FLG $HEX2.
STC07DRS STC07DRT HEX4.
- New variables created:
STC07FPS=PUT(STC07SLS,Z3.)!!':'!!PUT(STC07SPN,Z2.)!!
':'!!PUT(STC07SRO,Z2.)!!':'!!PUT(STC07SCO,Z2.);
STC07TPS=PUT(STC07TLS,Z3.)!!':'!!PUT(STC07TPN,Z2.)!!
':'!!PUT(STC07TRO,Z2.)!!':'!!PUT(STC07TCO,Z2.);
Thanks to Lou Sassani, National Australia Bank, AUSTRALIA.
Change 10.192 Variables SYSTEM SMFTIME weren't kept in dataset ROSCOSOR
VMACROSC ROSCOPUR,ROSCOHEX,ROSCOCON,ROSCOATT,ROSCOALL,ROSCOSHU,
Oct 6, 1992 ROSCOVPE, and ROSCODSR, but now they are.
Thanks to Willie Antman, Federal Deposit Insurance Corp., USA.
Change 10.191 "Appended" IMS Log processing was enhanced with new logic
ASMIMSLG to test for and locate the RACF segment in the IMS 01/03
Oct 6, 1992 record. Before this change, it was possible that the RACF
variables would have had wrong values.
Thanks to Engelbert Smets, Provinzia Versicherungsanstalten, GERMANY.
Rheinprovinz.
Thanks to Jeffrey S. Crum, Ashland Oil, USA.
Change 10.190 JES2 errors (APAR OY56235) create truncated timestamp
BUILDPDB values for TYPE26 variables JSTRTIME and JENDTIME. These
BUILDPD3 values are compared with TYPE30_5 variable JINITIME in the
IMACTIME BUILDPDB/BUILDPD3 logic to decide whether to SPIN or not.
Oct 6, 1992 Since IBM has not yet fixed their truncation problem, the
macro _TIMEDIF defined in IMACTIME previously used only in
JES3 BUILDPD3 has been added to JES2 BUILDPDB so that the
decision can be externalized without modification to the
BUILDPDB member. The default value for _TIMEDIF is zero,
but if you experience problems (i.e., your SPIN library
fills because of the JES2 error, and few jobs are put in
PDB.JOBS), you should change the default to 10 seconds,
as described in the comments in IMACTIME. The new logic
to decide to SPIN or not to SPIN using _TIMEDIF is now:
IF IN26 AND IN30_5 AND
(JSTRTIME-_TIMEDIF) LE JINITIME LE (JENDTIME+_TIMEDIF)
THEN OKFLAG=1;
Thanks to Don Friesen, B.C. Systems, CANADA.
Change 10.189 Variables TOTMEMR and OTH0MEMR were accidentally left out
RMFINTRV of the FORMAT statement for the other ....MEMR variables
TRNDRMFI in RMFINTRV. In the INCODE= logic in TRNDRMFI, compiler
Oct 6, 1992 "faker" statements (IF OTH0xxxx=. THEN OTH0xxxx=.;) for
OTH6-OTH0 variables were deleted. They were added to avoid
the UNINITIALIZED VARIABLE message between MXG 6.6 and MXG
7.7 (when these new variables were added), but now only
caused confusion as to why they were there!
Thanks to Tom Elbert, John Alden Life, USA.
Change 10.188 Change 10.020 correctly circumvented LENGTH problem in
EXITMONI Landmark records, but the actual cause of the zero value
Sep 28, 1992 is corrected by changing the line reading
MVC 0(2,R1),=H'0' RECORD LENGTH IS MEANINGLESS
to read
MVC 0(2,R1),F$NXTLNG+2
Thanks to Trevor Holland, Bank of Melbourne, AUSTRALIA.
Change 10.187 Change 10.110 mislocated an INFILE & FORMAT statement in
VMACQAPM the new X.25 section, which surfaced as "SYSTEM ABEND 0C4
Sep 28, 1992 OCCURRED OUTSIDE OF THE SAS ENVIRONMENT" on the SAS log.
Change 10.186 Support for XEROX printer SFS "Status File System" data.
ADOCSMS XEROX Printers have always created data records on print
EXTYSFS workstations, but now that data is somewhat more usable,
IMACSFS because you can now capture the MVS JOB and JESNR fields.
VMACSFS This will require your XEROX person to make some changes
TYPESFS to the XEROX software driving the printer, as described
Sep 28, 1992 in member ADOCSFS.
Then, getting the SFS data records from the XEROX printer
to the mainframe may require floppy disk or non-labeled
tapes or communications packages, depending on the
configuration of a particular printer.
You typically cannot use PDB.PRINT for XEROX printer
cost recovery, because JES counts in the TYPE6 record
only what JES sent to the printer, not what was
actually printed; JES may send only one copy, but the
printer can print 100 copies, and only the SFS
Accounting record will tell you what was really
printed. Now it can tell by whom, too!
The ability to process the TYPESFS dataset and merge it
with your PDB.JOBS dataset to pick up accounting data now
makes the XEROX SFS data worth generating and transporting
over to MVS for XEROX printer workstation accounting.
Unfortunately, XEROX does not yet include the data
needed for accurate printer throughput analysis (see
ANALPRTR) and there is still no way to get the MVS
accounting fields put in the SFS data records.
Thanks to Chuck Hopf, Primerica, USA.
Change 10.185 Change 10.060 was not completely correct. If the first of
VMACTMS5 two DSNBs was inactive, the statement IF DSNBACTV='Y';
Sep 24, 1992 that was added by 10.060 caused the next DSNB to be lost!
That statement must be deleted. The statement
IF VOLSER GE 'A' THEN OUTPUT DSNBREC;
must be changed to read
IF VOLSER GE 'A' AND DSNBACTV='Y' THEN OUTPUT DSNBREC;
so only the active DSNBs are output.
Thanks to Norbert Korsche, OMV-AG, AUSTRIA.
Change 10.184 Support for IBM's TCP/IP Version 2 Release 2 SMF records.
ADOCTCP The Telnet Server writes a record for each Logon or Logoff
EXTYTCP event; a different SMF record number can be assigned for
IMACTCP each event, but only one record number for both events is
TYPETCP needed/recommended, as MXG will create one observation in
VMACTCP dataset TYPETCPT for each event record which identifies
Sep 24, 1992 which event. The FTP Server writes a record for each
APPEND/DELETE-MDELETE/LOGIN fail/RENAME/GET-MGET/PUT-MPUT
event; like the Telnet Server, a different record number
can be assigned for each event, but only one record number
for all FTP events is needed/recommended, as MXG will
create one observation in dataset TYPETCPF for each event
record which identifies which FTP event. These records
and their installation is described in TCP/IP V2 R2
Planning and Customization, SC31-6085-01.
Thanks to Fred Toro, Lever Bros. Co, USA.
Thanks to Kurt Karlsen, NIT, NORWAY.
Thanks to Oystein J. Blix, Etrinell.
Change 10.183 DB2 Statement Number type 102 trace records are decimal
ANALDB2R values, but some MXG datasets stored them as $CHAR2. with
VMAC102 a $HEX4. format. Now, all statement numbers are decimal
Sep 24, 1992 values, to agree with DB2PM and the catalog information.
Thanks to Dave Leeker, Southwestern Bell, USA.
Change 10.182 Omegamon V550 ESRA (user) SMF record subtype 101 caused
VMACOMCI INPUT STATEMENT EXCEEDED RECORD LENGTH. Immediately before
Sep 24, 1992 "INPUT ESRES1..." insert "IF SUBTYPE NE 101 THEN" (that
header segment does not exist in the subtype 101). After
input of SYSEGS PIB4., insert @; SMSEGO=SMSEGO=3;INPUT
(this subtype had not occurred in earlier test data).
Thanks to David Ehresman, University of Louisville, USA.
Change 10.181 Support for IBM type 96 SMF record from The Integrated
ADOCTIRS Reasoning Shell, TIRS. An observation is created in the
EXTYTIRS TYPETIRS dataset, containing session times, CPU time used
IMACTIRS (both vector and CPU), interactions and ABEND codes for
TYPETIRS each time the TIRS subsystem replies or queries the user.
VMACTIRS This has been coded but not tested with data.
Sep 24, 1992
Thanks to Bill Stoneberg, National-Oilwell, USA.
Change 10.180 Support for SIMWARE SIM/XFER VTAM user SMF record added.
ADOCSIM For each user transfer session, an observation is created
EXTYSIM in TYPESIM dataset, reporting session times and the amount
IMACSIM (bytes and blocks) of data sent and received.
TYPESIM
VMACSIM
Sep 24, 1992
Thanks to Mike Roybal, First National Bank in Albuquerque, USA.
Change 10.179 TYPE73 variable ESCACVC (flag that an ESCON converter is
VMAC73 attached to this CHPID) was never set to "Y" because it
Sep 24, 1992 was misspelled as ESONCVC in one line. Corrected spelling.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 10.178 Support for Hewlett-Packard Performance Collection System
ADOCHPCS Now available from HP, the PCS product for HP/UX operating
ANALHPRS system creates 4 records from which MXG builds 6 datasets:
ASUMHPCS HPCSAPPL - Application resources by interval
EXHPCSAP HPCSCONF - Configuration at startup of PCS
EXHPCSCO HPCSDISK - Disk activity by device by interval from GLOB
EXHPCSDI HPCSGLOB - Global activity by interval
EXHPCSGL HPCSLANS - LAN activity by LAN by interval from GLOB
EXHPCSLA HPCSPROC - Process activity by process by interval
EXHPCSPR It is quite encouraging that Hewlett Packard recognizes
IMACHPCS the need to instrument its UNIX platform and now offers
JCLHPCS the PCS product to manage HP UNIX systems.
TRNDHPCS
TYPEHPCS
VMACHPCS
VMACHPCS
Sep 23, 1992
Thanks to Chuck Hopf, Hopf Consulting, USA.
Change 10.177 Sites still on MVS/XA will need to use ASMTMNTO to create
ASMTMNT the MXG tape mount monitor, as it will assemble under XA.
Sep 23, 1992 (The "real" monitor in ASMTMNT uses MVS/ESA-only macros to
support dynamic device additions).
Change 10.176 NETVIEW FTP SMF record timestamps aren't SMFSTAMP8 format
VMACFTP but have DATE preceding TIME. (Its not standard format,
Sep 23, 1992 but it ain't illegal!) Replace all eleven lines with:
xxxxxxxx SMFSTAMP8.
with these five lines:
DATE PD4.
TIME PIB4.2
@;
IF DATE GT 0 THEN xxxxxxxx=DHMS(DATEJUL(DATE),0,0,TIME);
INPUT
Thanks to Herr Timmermanne, Preussen Elektra, GERMANY.
Change 10.175 Powerful new "_L" 7 "_K" macros are now defined for each
all of MXG MXG dataset, allowing you to completely tailor individual
Sep 22, 1992 datasets. You can now ADD or DROP variables, write the
dataset to a specific DD (libref), add dataset compression
for specific datasets, change BUFSIZE, or even change the
name of the MXG dataset! This MAJOR revision to the MXG
architecture greatly enhances the flexibility and control
for the future. The usage of this new design is described
in the second part of this change. The first part of this
change discusses the incompatibility of the design.
1. INCOMPATIBILITY of the new "_L" macros. These nineteen
IMACs have been changed INCOMPATIBLY:
IMACCICS IMACCIMS IMACCMF IMACDB2 IMACDCOL IMACHSM
IMACIMS IMACINTV IMACMONI IMACNSPY IMACOPC IMACPDSM
IMACROSC IMACSTX IMACTPX IMACZRB IMAC30DD IMAC40DD
IMAC434D
If these IMACs are in your USERID.SOURCLIB, you MUST
make the changes described below, or your job will ABEND!
Prior to MXG 10.2, those IMACs defined old-style macros
which set the DDNAME to which certain MXG datasets were
written. In the new "_L" architecture, these IMACs define
both the DDNAME and DATASET names in one "_L......" macro.
For example, IMACICS defined MACRO _CICTRAN CICSTRAN %
(which was used with DATA _CICTRAN.CICSTRAN syntax) so
that the CICSTRAN dataset was written to the CICSTRAN DD.
Now, IMACCICS defines MACRO _LCICTRN CICSTRAN.CICSTRAN %
(which is now used with DATA _LCICTRN syntax) so that
the CISTRAN dataset is still written to the CICSTRAN DD.
For each IMAC listed above that is in your USERID.SOURCLIB
library, you MUST copy the new 10.x IMAC member into your
MXG.V1010.USERID.SOURCLIB, and set the DDNAME part of the
new "_L" macro definition to the DDNAME value from your
old IMAC member.
The following table lists the old and new macro definition
(with the MXG default value) for each of the IMACs that
were incompatibly changed:
IMAC: Old DDNAME macro: New "_L" ("Library") macro:
IMACCICS MACRO _CICACCT PDB % MACRO _LCICACC PDB.CICSACCT %
MACRO _CICEXCE PDB % MACRO _LCICEXC PDB.CICSEXCE %
MACRO _CICTRAN CICSTRAN% MACRO _LCICTRN CICSTRAN.CICSTRAN%
MACRO _CICYSTM PDB % MACRO _LCICSYS PDB.CICSYSTM %
MACRO _CICEOD PDB % MACRO _LCICEOD PDB.CICEODRV %
MACRO _CICINT PDB % MACRO _LCICINT PDB.CICINTRV %
MACRO _CICREQ PDB % MACRO _LCICREQ PDB.CICREQRV %
MACRO _CICUSS PDB % MACRO _LCICUSS PDB.CICUSSRV %
IMACCIMS MACRO _IMFTRAN WORK % MACRO _LIMFTRN WORK.CIMSTRAN %
MACRO _IMFDBDS WORK % MACRO _LIMFDBD WORK.CIMSDBDS %
MACRO _IMFDB2 WORK % MACRO _LIMFDB2 WORK.CIMSDB2 %
MACRO _IMFPROG WORK % MACRO _LIMFPGM WORK.CIMSPROG %
IMACCMF MACRO _CMF19DD PDB % MACRO _LCMFTRA PDB.CMFTRACE %
IMACDB2 MACRO _DB2ACCT PDB % MACRO _LDB2ACC PDB.DB2ACCT %
MACRO _DB2STAT PDB % MACRO _LDB2ST0 PDB.DB2STAT0 %
MACRO _DB2STAT PDB % MACRO _LDB2ST1 PDB.DB2STAT1 %
IMACDCOL MACRO _DCOLDSN WORK % MACRO _LDCODSN PDB.DCOLDSET %
MACRO _DCOLCLU WORK % MACRO _LDCOCLU PDB.DCOLCLUS %
MACRO _DCOLVOL WORK % MACRO _LDCOVOL PDB.DCOLVOLS %
MACRO _DCOLMIG WORK % MACRO _LDCOMIG PDB.DCOLMIGS %
MACRO _DCOLBKP WORK % MACRO _LDCOBKP PDB.DCOLBKUP %
MACRO _DCOLCPD WORK % MACRO _LDCOCPD PDB.DCOLCAPD %
MACRO _DCOLCPT WORK % MACRO _LDCOCPT PDB.DCOLCAPT %
IMACINTV No macro is defined in this member, and it is unlikely that
this member would cause a problem, but where it used to be
OUTPUT TYPE30_V; it now needs to be OUTPUT _LTY30UV; just
to be consistent with the new architecture.
IMAC30DD No macro is defined in this member, and it is unlikely that
this member would cause a problem, but where it used to be
OUTPUT TYPE30_D; it now needs to be OUTPUT _LTY30UD; just
to be consistent with the new architecture.
IMAC40DD No macro is defined in this member, and it is unlikely that
this member would cause a problem, but where it used to be
OUTPUT TYPE40_D; it now needs to be OUTPUT _LTY40UD; just
to be consistent with the new architecture.
IMACMONI MACRO _MONDBDS WORK % MACRO _LMONDBD WORK.MONIDBDS %
MACRO _MONHIST WORK % MACRO _LMONHIS WORK.MONIHIST %
MACRO _MONMRO WORK % MACRO _LMONMRO WORK.MONIMRO %
MACRO _MONSYST WORK % MACRO _LMONSYS WORK.MONISYST %
MACRO _MONTASK WORK % MACRO _LMONTSK WORK.MONITASK %
MACRO _MONUSER WORK % MACRO _LMONUSR WORK.MONIUSER %
IMACOPC MACRO _OPC20 WORK % MACRO _LOPC20 WORK.OPC20 %
MACRO _OPC23 WORK % MACRO _LOPC23 WORK.OPC23 %
MACRO _OPC24A WORK % MACRO _LOPC24A WORK.OPC24D_A %
MACRO _OPC24B WORK % MACRO _LOPC24B WORK.OPC24D_B %
MACRO _OPC24C WORK % MACRO _LOPC24C WORK.OPC24D_C %
MACRO _OPC24D WORK % MACRO _LOPC24D WORK.OPC24D_D %
MACRO _OPC24E WORK % MACRO _LOPC24E WORK.OPC24D_E %
MACRO _OPC24F WORK % MACRO _LOPC24F WORK.OPC24D_F %
MACRO _OPC24G WORK % MACRO _LOPC24G WORK.OPC24D_G %
MACRO _OPC241 WORK % MACRO _LOPC241 WORK.OPC24_1 %
MACRO _OPC242 WORK % MACRO _LOPC242 WORK.OPC24_25 %
MACRO _OPC246 WORK % MACRO _LOPC246 WORK.OPC24_6 %
MACRO _OPC247 WORK % MACRO _LOPC247 WORK.OPC24_78 %
MACRO _OPC25 WORK % MACRO _LOPC25 WORK.OPC25 %
MACRO _OPC26 WORK % MACRO _LOPC26 WORK.OPC26 %
MACRO _OPC27 WORK % MACRO _LOPC27 WORK.OPC27 %
MACRO _OPC28 WORK % MACRO _LOPC28 WORK.OPC28 %
MACRO _OPC29 WORK % MACRO _LOPC29 WORK.OPC29 %
MACRO _OPC30 WORK % MACRO _LOPC30 WORK.OPC30 %
MACRO _OPC31 WORK % MACRO _LOPC31 WORK.OPC31 %
MACRO _OPC32 WORK % MACRO _LOPC32 WORK.OPC32 %
MACRO _OPC33 WORK % MACRO _LOPC33 WORK.OPC33 %
IMACPDSM MACRO _PDSMDD WORK % MACRO _LTYPDSM WORK.TYPEPDSM %
IMACROSC MACRO _ROSCDDN WORK % - unchanged at present.
IMACSTX MACRO _STXINT WORK % - was defined, but never
referenced in MXG.
IMACTPX MACRO _TPXINT WORK% MACRO _LTPXINT WORK.TPXINTRV %
It is remotely possible that you may have used the old
syntax in your report/analysis program, and if so, you
may encounter syntax errors. The following table lists
the old and new syntax for each possible macro that might
cause syntax errors.
Previous syntax Must be replaced by syntax
_CICACCT.CICSACCT _LCICACC
_CICEXCE.CICSEXCE _LCICEXC
_CICTRAN.CICSTRAN _LCICTRN
_CICYSTM.CICSYSTM _LCICSYS
_CICEOD .CICEODRV _LCICEOD
_CICINT .CICINTRV _LCICINT
_CICREQ .CICREQRV _LCICREQ
_CICUSS .CICUSSRV _LCICUSS
_IMFTRAN.CIMSTRAN _LIMFTRN
_IMFDBDS.CIMSDBDS _LIMFDBD
_IMFDB2 .CIMSDB2 _LIMFDB2
_IMFPROG.CIMSPROG _LIMFPGM
_CMF19DD.CMFTRACE _LCMFTRA
_DB2ACCT.DB2ACCT _LDB2ACC
_DB2STAT.DB2STAT0 _LDB2ST0
_DB2STAT.DB2STAT1 _LDB2ST1
_DCOLDSN.DCOLDSET _LDCODSN
_DCOLCLU.DCOLCLUS _LDCOCLU
_DCOLVOL.DCOLVOLS _LDCOVOL
_DCOLMIG.DCOLMIGS _LDCOMIG
_DCOLBKP.DCOLBKUP _LDCOBKP
_DCOLCPD.DCOLCAPD _LDCOCPD
_DCOLCPT.DCOLCAPT _LDCOCPT
_MONDBDS.MONIDBDS _LMONDBD
_MONHIST.MONIHIST _LMONHIS
_MONMRO .MONIMRO _LMONMRO
_MONSYST.MONISYST _LMONSYS
_MONTASK.MONITASK _LMONTSK
_MONUSER.MONIUSER _LMONUSR
_OPC20 .OPC20 _LOPC20
_OPC23 .OPC23 _LOPC23
_OPC24A .OPC24D_A _LOPC24A
_OPC24B .OPC24D_B _LOPC24B
_OPC24C .OPC24D_C _LOPC24C
_OPC24D .OPC24D_D _LOPC24D
_OPC24E .OPC24D_E _LOPC24E
_OPC24F .OPC24D_F _LOPC24F
_OPC24G .OPC24D_G _LOPC24G
_OPC241 .OPC24_1 _LOPC241
_OPC242 .OPC24_25 _LOPC242
_OPC246 .OPC24_6 _LOPC246
_OPC247 .OPC24_78 _LOPC247
_OPC25 .OPC25 _LOPC25
_OPC26 .OPC26 _LOPC26
_OPC27 .OPC27 _LOPC27
_OPC28 .OPC28 _LOPC28
_OPC29 .OPC29 _LOPC29
_OPC30 .OPC30 _LOPC30
_OPC31 .OPC31 _LOPC31
_OPC32 .OPC32 _LOPC32
_OPC33 .OPC33 _LOPC33
_PDSMDD .TYPEPDSM _LTYPDSM
_TPXINT .TPXINTRV _LTPXINT
2. Usage of the new "_L" and "_K" macros to tailor datasets.
For each MXG dataset, an "_L" ("Library") macro and an
"_K" (Keep) macro is now defined in the product's IMAC.
For example, these IBM Type 0 SMF record product's macros
are now defined in member IMAC0:
MACRO _LTY0 TYPE0 %
MACRO _KTY0 %
The naming convention for the "_L" and "_K" macros use
the same suffix as the dataset's "EX" (Exit macro). The
"EX" members names have one of these forms:EXTYnnnn,
EXTYaaaa, EXTYxxyy, EXxxxyyy or EXxxyyyy, where xx/xxx
is the product acronym and yyy/yyyy is the suffix for
the specific dataset. For example, EXCICTRN is the
exit member name for the CICS product CICSTRAN dataset,
and thus "_LCICTRN" and "_KCICTRN" are the new macros.
The "_L" macro lets you change the DDNAME to which each
dataset is written (for example, you can send a dataset
to a tape, or to a different DASD volume, which can help
with large volume datasets). This is the primary function
of the "_L" (Library) macro architecture. Note that in
the "_LTY0" default definition, only the dataset name is
defined, so the default DDNAME of WORK is used. Changing
the definition to MACRO _LTY0 XYZ.TYPE0 % would cause
that dataset to be written to the XYZ DDname.
It is the "_K" macro that is the real powerhouse in this
implementation. It is located after the KEEP= list of MXG
variables to be kept, and is inside the parenthesis that
can contain dataset options, and so it can be used to
specify dataset options like DROP= BLKSIZE= and COMPRESS=!
Lets look at the before and after structure of MXG code,
using the macros defined in VMAC0 (for the TYPE0 dataset).
The original implementation for dataset TYPE0 was this:
MACRO _VAR0
TYPE0 (KEEP=VAR1 VAR2 ... VARn)
%
MACRO _CDE0
IF ID=0 THEN DO;
INPUT .... @;
%INCLUDE SOURCLIB(EXTY0); ===> OUTPUT TYPE0;
END;
%
The new "_L" and "_K" implementation now looks like this:
%INCLUDE SOURCLIB(IMAC0);
MACRO _VAR0
_LTY0 (KEEP=VAR1 VAR2 ... VARn _KTY0)
%
MACRO _CDE0
IF ID=0 THEN DO;
INPUT .... @;
%INCLUDE SOURCLIB(EXTY0); ===> OUTPUT _LTY0;
END;
%
Examples:
a. The _KTY0 macro can be used to DROP unwanted variables.
Simply define it as
MACRO _KTY0 DROP= VAR2 %
and the unwanted variables will be dropped. (It turns
out that if a KEEP= and a DROP= option are used for the
same dataset, that the DROP= list overrides the KEEP=
list!)
b. The _KTY0 macro can be used to COMPRESS the dataset:
MACRO _KTY0 COMPRESS=YES %
will compress the TYPE0 dataset.
c. You can create new variables (in the Exit member, or in
the case of CICS user data, in IMACICUS) and add them
to the dataset, and drop other variables at the same
time:
MACRO _KTY0 MYVAR1 MYVAR2 DROP= VAR2 %
will cause the TYPE0 dataset to contain your new
variables and drop old variable VAR2.
The earlier implementation of IMACKEEP did permit override
of dataset name and the keep list, but it required copying
the entire _VAR macro definition into IMACKEEP, and this
exposed your site to errors any time a new dataset was
added to that product. The new implementation isolates
your tailoring to the specific dataset, and addition of
new datasets will be transparent to your tailoring.
Change 10.174 The DB2 optimizer's cost estimate, QW0022OS, is input as
ADOC102 RB4. (floating point), not the $CHAR4 input format (that
VMAC102 was printed as $HEX8.). Now, QW0022OS is a numeric field
Sep 22, 1992 instead of character, and contains the cost estimate.
Thanks to Frank Ingrassia, IMS Software, USA.
Change 10.173 SAS 6.07 option FMTSEARCH=(DD1 DD2 DD3), which supports
IMACFMTS concatenation of format libraries, has eliminated the need
Sep 22, 1992 for this SAS 6.06 circumvention. The member was kept for
compatibility, but is unlikely to be needed now.
Change 10.172 Warning "Variable FVOLSER uninitialized" eliminated by
TYPETMS5 removing the incorrect reference to FVOLSER in DSNBREC
Sep 21, 1992 processing. This was only a cosmetic warning.
Change 10.171 VTOC with freespace starting in track 1 did not have that
VMXGVTOC freespace extent reported (except for the first VOLSER).
VMXGVTOF MXG logic was only checking the first volume. This change
Sep 21, 1992 restructured several lines of logic, thanks, Chris. The
Oct 18, 1992 VMXGVTOC changes were incomplete in the Early MXG 10.2 and
were corrected in the PreRelease MXG 10.2
Thanks to Hank Boonstra, GASUNIE NV, THE NETHERLANDS.
Thanks to Chris Weston, SAS Institute Europe, GERMANY.
Change 10.170 DB2 Trace record IFCID=172 (Deadlock, identifies all of
VMAC102 the units-of-work involved in the deadlock, resources they
Sep 17, 1992 were contending for, and attributes of their requests) and
IFCID=177 (Package Allocation) have now been coded/tested.
The only remaining IFCIDs that are not coded are 126-129,
180-182, 186, and 190-195, because none of these subtypes
have yet been created in numerous traces. If you observe
one of these subtypes, please fax a hex dump of the record
so these final DB2 trace IFCIDs can be supported.
Thanks to Gary Smith, Southern California Edison, USA.
Thanks to Frank Ingrassia, IMS Software, USA.
Change 10.169 The JCL example showing how to invoke %GRAFDB2 would not
GRAFDB2 execute; GRAFTRND should have been GRAFDB2, and the ending
Sep 17, 1992 parenthesis and final semi-colon were missing. This error
was only in the example in comments; there was no error in
GRAFDB2 itself.
Thanks to Raymond Zieverink, Belk Stores Services, USA.
Change 10.168 Support for VSE DOS POWER Version 4.2 accounting records
IMACDOS has been found to require only setting OFFSET=24 and INPUT
Sep 17, 1992 @67 RECID in the Installation tailoring MACro, IMACDOS.
Thanks to Alan Smith, Health and Welfare Data Center, Calif., USA.
Change 10.167 IBM APAR OY49717 adds text to SMF type 37 records for the
VMAC37 Network Alert Report and the Self Defining Text Message
Sep 8, 1992 Report. While there may be multiple Network Alert Report
text segments, in this implementation, only the first is
kept; these are 200 byte variables, and I don't want to
greatly enlarge the size of TYPE37 until a real user tells
me this new data is actually useful! If you use the
TYPE37 and if it uses enough DASD space to be a problem
justifying a re-design (i.e., creating multiple datasets
with restricted sets of variables instead of just the one
TYPE37 with all possible variables) please let me know and
give me your thoughts.
Change 10.166 The _LTRccmm macros names were changed to _XTRccmm names
READDB2 so as to not conflict with the new _L and _K dataset macro
VMAC102 names. (This should have no impact; _XTRccmm macros are
Sep 7, 1992 internal lists and are not normally modified by users.)
Change 10.165 Support for XCOM 6.2 Version 2.2.2G SMF record.
ADOCXCOM Dataset XCOMDATA describes (extensively!) file transfer
EXTYXCOM activity, timestamps, and file attributes and sizes for
IMACXCOM files transferred by XCOM. Additionally, Neil Colombage
TYPEXCOM provided extensive notes about meanings of many variables
VMACXCOM that are now found in member ADOCXCOM.
Sep 6, 1992
Thanks to Sam Sheinfeld, Kraft General Foods, USA.
Thanks to Neil Colombage, British Airways, ENGLAND.
Change 10.164 Support for SAP Application Accounting data under CICS.
EXCICSAP The SAP product provides the "STCDUMMY SAP Statistics" in
IMACCICS either a journal format file (which can be read with MXG's
IMACICSA TYPE110J member), or an SMF format type 110 record (as a
VMAC110 journal subtype, which can now be read by TYPE110/BUILDPDB
VMAC110M members). The CICSSAP dataset will contain observations
Sep 6, 1992 automatically if the "user journal type-id" JCRUTRID='SA',
so you need only to find out whether the SAP STCDUMMY data
was sent to a Journal or to SMF. A SAP "event" can have
several CICS transactions, and may last beyond the end of
the last CICS event, so SAP's creation of this additional
transaction information appears to be a very intelligent
architecture to help us measure both CICS and SAP!
Member IMACICSA contains the logic to decode their journal
segment, but you should not have to do anything to that
member; it was externalized only for ease of maintenance.
The internal logic of VMAC110 was restructured to process
journal segments and to specifically recognize the SAP
journal-id. (The logic of VMAC110 is now documented
schematically in ADOC110 for those interested.)
Thanks to Danilo Gipponi, SAS Institute, ITALY.
Thanks to Mr. Eude, Didier Werke AG, GERMANY
Thanks to Mr. G. Guarnaschelli, Hoechet Italia, ITALY.
Change 10.163 Candle's VCOLLECT 5.1.0 still writes the invalid "VVB"
VMACVMXA monitor records first discussed in Change 8.004. The fix
Sep 5, 1992 then was to modify VMACVMXA to add " INPUT +4 @; " before
the actual input statement, but line numbers have changed,
and now the change has been externalized. A new macro in
VMACVMXA is now defined, _VCANFIX, with null value (blank)
but which is located so that you can process Candle data
by the following override in your program:
%INCLUDE SOURCLIB(VMACVMXA);
MACRO _VCANFIX INPUT +4 @; %
_VMTEST
since the resultant program will skip over the unwanted,
additional record length field. (Note that _VCANFIX was
located immediately prior to the INPUT MRHDRDM statement
following MACRO _VMINPUT, as suggested in 8.004).
Thanks to Phil Henninge, Timken Company, USA.
Change 10.162 Support for FACOM PDLF Type 127 SMF record for MSP/EX is
VMACF127 provided by this significant user contribution. Many new
Sep 5, 1992 variables were added to the TYPEF27D (device statistics,
including VOLSER, and pending, connect and disconnect
times), the TYPE27S (CPU statistics, including virtual
pages in the CSA,PLPA, and NUC above and below the line),
and the TYPE27S and TYPE27P (performance Group statistics)
both now support eight-CPU-engine statistics. These data
bring FACOM up to rough equivalence to MVS/XA in terms of
the "RMF-like" PDLF data capture.
Thanks to Joan Dobbie, Attorney-General's Office, S.A., AUSTRALIA.
Change 10.161 Support for FACOM's AIM Version 12 type 116 SMF record is
EXAIM6R added. Version 12 incompatibly changed the record, and
FORMATS there is no record version indicator, so a new Flag AIMVER
IMACFACO was added to IMACFACO to identify which version of AIM MXG
VMACAIM6 is to process. Two formats were added and new AIM dataset
Sep 5, 1992 AIM116_R is created. The changes were extensive, but the
documentation was unclear as to the relationship between
the task information sections and the deadlock resource
information sections; these MXG assumptions were made:
- item 16 (table A.5) should be described as "Offset to
deadlock-related *resource* information section".
- use the pointers to the deadlock resource info sections
that were in each task info section rather than the
triplet in the header which points to all the deadlock
resource info sections
- each deadlock task has only one deadlock resource
section associated with it.
This support has been tested, but only with a small number
of test records.
Thanks to Malcolm Sare, Australian National, AUSTRALIA.
Change 10.160 UTILGETM (used in step SMFSMALL of JCLTEST6 to create the
UTILGETM SMFSMALL sample file now will select ten of each subtype
Sep 5, 1992 of all SMF records, including user records. Previously,
only types 22,30,39,70-79 subtypes were selected. This
implementation makes use of _TEMPORARY_ arrays to avoid
a limitation in SAS 6.07 of 32768 variables in a data step
(that limitation is to be fixed in the November, 1992,
SAS maintenance tape), but you may wish to note that the
variables in _TEMPORARY_ arrays are not similarly limited.
Since this type of array did not exist in SAS Version 5,
UTILGETM tests its operating environment and uses the new
(more robust) logic only under Version 6; the old logic is
unchanged under Version 5.
Thanks to Chuck Hopf, Primerica, USA.
Change 10.159 Although we don't recommend using these archaic read VTOC
FMXGUCBL programs (instead, see member ASMVTOC/VMXGVTOF), they will
VMXGVTOC now work under SAS 6.07. The EXEC ASMHCL statement must
VMXGVTOR be changed so the PARM.C parameter precedes the PARM.L
Sep 3, 1992 parameter, and the //SYSIN following that EXEC must be
changed to //C.SYSIN. Additionally, the function calls in
VMXGVTOC and VMXGVTOR using =FMXGUCBL() was changed to
=UCBL() because functions can only have 4-character names
in SAS Version 6.
Thanks to Bob Smith, Nissan Motor Corporation in the USA.
Change 10.158 FORMAT NOT FOUND error with DB2 SQL Trace reports if no
ANALDB2R T102S105 or T102S107 records (the records that map DBID &
Sep 3, 1992 OBID to their names) were found. While these records are
always written at Trace start-up, the condition can occur
when you process records in the middle of a trace session.
Also, even when the format could be constructed, if there
was no match with your OBID/DBID value, an 8-byte string
(SYSTEM ID + QWHSSSID) was printed. Now, the format is
always created, and for a no-match, the string of SYSTEM,
QWHSSSID, DBID, and OBID is printed. This required some
reformating of some of the SQL reports.
Selection by PLAN, CORRNAME, etc., has now been added to
the Record Trace report.
Regardless of the order in which reports are specified,
ANALDB2R executes and prints the reports alphabetically.
The SORTBY= parameter was ignored in subsequent reports,
if a report such as PMACC03 was requested that had a non-
changeable sort sequence, because of incorrect parsing
that has now been corrected by DB2RSORT macro changes and
invoking this macro for the reports whose sort sequence
can be changed.
Additional changes that will reduce WORK space requirement
are still in development.
Thanks to Chuck Hopf, Primerica, USA.
Change 10.157 (MXG 10.1 only). Assembler error MSGAREA not found cause
ASMVTOC LSPACE UCB=(4),EXPMSG=MSGAREA,MF=I should have been
Sep 2, 1992 LSPACE UCB=(4),MF=I
The EXPMSG=MSGAREA was left over from debugging. Sorry!
Thanks to Sean Chaffee, Amadeus Dataprocessing Gmbh & Co, GERMANY.
Change 10.156 ASMVVDS may fail with User 666 ABEND processing a VVDS on
ASMVVDS a volume which is SMS managed multivolume with guaranteed
Sep 2, 1992 space. The Diagnose VVDS command does not work until you
install IBM APAR OY48199 (PTFs UY74336-339).
Thanks to Chris Taylor, Wachovia Operations Services Corp., USA.
Change 10.155 NPM 1.5 incorrectly documented format of new variables
VMAC28 LLBSSTIM and LLBSPTIM as packed decimal (PDTIME4.) fields,
Sep 2, 1992 but actual data now shows they are PIB4. fields. Change
the PDTIME4. to PIB4. after both variables.
Thanks to Jerry Kleinheinz, Mortgage Guarantee Corp, USA.
Change 10.154 TYPEMONI (archaic Landmark Version 7) does not contain
TYPEMONI APPLID, but ASUMCICS expects that variable, so sites still
Sep 2, 1992 using TYPEMONI (remember, TYPEMON8 is for Versions 8/9)
must add APPLID to the KEEP= list for MONITASK, and must
insert APPLID=SYSID; after the @; and before FILTEM=0; .
Thanks to Russ Weid, CUNA Mutual Insurance Group, USA.
Change 10.153 Step accounting variable SACCT1 is now added to the PDB
IMACPDB datasets JOBS, STEPS, and PRINT, so that Started Tasks
Sep 1, 1992 (which can have only step accounting fields) can be
tracked to account group. This involved adding SACCT1 to
the ID statement in macro _PDBSUMS, and adding SACCT1 to
the _PDBADD2 and _PDBADD3 macros.
Thanks to Mike Skopec, Platinum Technology, USA.
Change 10.152 The //LIBRARY DD in the first step should have specified
JCLTEST6 DISP=(NEW,CATLG) instead of NEW,PASS so that this MXG
Sep 1, 1992 format library is both built AND cataloged!
Thanks to Basil Hines, Rogers Data, CANADA.
Change 10.151 Some DB2 graphs may not have been produced because the
GRAFDB2 statement IF EOF THEN CALL SYMPUT... should have been only
Sep 1, 1992 CALL SYMPUT.... (It worked in testing, because in each of
the cases, the last observation was selected, but if the
last observation was not selected, &MXGOBS was not set.)
Thanks to Andre Henry, AG 1824, GERMANY.
Change 10.150 WSF 3.3.6 causes INPUT STATEMENT EXCEEDED error because
VMACWSF the accounting extension in 3.3.6 contains only three of
Sep 1, 1992 the seven fields added in 3.4.1. To process 3.3.6 data,
you will need to find BOTH occurrences of ACCXPFMR $CHAR8.
and insert the following line after each occurrence:
@; IF LENGTH-COL+1 GE 148 THEN INPUT
so that those following fields are only input if the data
is in the record. There is no error with 3.4.1 data.
Thanks to Frank Sullivan, Woolworth plc, ENGLAND.
Change 10.149 DB2 variables CORRNAME and CORRNUM are determined by the
IMACDB2 connection type (TSO, IMS, CICS, etc.), but prior to DB2
Sep 1, 1992 2.3, the only way to identify connection was by testing
the value of QWHCCN for you site's IMS jobname in macro
_DB2CORR defined in IMACDB2. This macro has now been
redesigned to take advantage of new (in DB2 2.3) variable
QWHCATYP which explicitly identifies the connection type.
(See member ADOCDB2 for all possible values of QWHCATYP.)
The macro definition now reads:
MACRO _DB2CORR
IF (QWHSRELN GE 2.3 AND (QWHCATYP=5 OR QWHCATYP=6 OR QWHCATYP=9))
OR
(QWHSRELN LE 2.2 AND (QWHCCN =: 'IMS1' OR QWHCCN =: 'IMS2'))
THEN DO; /* IDENTIFY IMS CONNECTIONS */
CORRNAME = SUBSTR(QWHCCV,5,8);
CORRNUM = SUBSTR(QWHCCV,1,4);
END;
ELSE
IF (QWHSRELN GE 2.3 AND QWHCATYP=4)
OR
(QWHSRELN LE 2.2 AND (QWHCCN =: 'CICS' OR QWHCCN =: 'PROD'))
THEN DO; /* IDENTIFY CICS CONNECTIONS */
CORRNAME = SUBSTR(QWHCCV,5,4);
CORRNUM = SUBSTR(QWHCCV,1,4);
END;
ELSE DO; /* FOR ALL OTHER CONNECTIONS */
CORRNAME = SUBSTR(QWHCCV,1,8);
CORRNUM = ' ';
END;
%
Thanks to Mr. M. Praet, AG, GERMANY.
Change 10.148 Three DCOLLECT variables in the DCOLBKUP (backup) dataset
VMACDCOL have incorrect values. UBALLSP, UBUSESP, and UBRECSP were
Sep 1, 1992 1024th of what they should have been. Find the line
UBALLSP=1024*UMALLSP;
and the two lines following. Change the "UM" in all three
lines to "UB" to correctly convert the variables.
Thanks to John Ellis, Commercial Union, U.K.
Change 10.147 The MXTDELAY dataset built by these sample CICS reporting
ANALCICS programs is not used by any report (it was a holdover from
ANALMONI CICS 1.6), and the dataset is no longer created.
Aug 31, 1992
Thanks to Kevin Batten, Roses Stores, Inc, USA.
Change 10.146 The new Appended IMS log processing program ASMIMSLG now
ASMIMSLG works with IMS 2.2 as well as IMS 3.1. Sites still using
Aug 31, 1992 IMS 2.2 need only to comment out a single statement:
MVC ORGENT(8),MSGRACGP
(because MSGRACGP is a field name that does not exist in
the IMS 2.2 DSECT as it was added in IMS 3.1), and then
use the IMS 2.2 macro libraries for the assembly. Note
that you will need to have two load libraries, one for
the IMS 2.2 version of MXGIMSLG, and one for the IMS 3.3
version if MXGIMSLG, to keep them separate. The comments
in ASMIMSLG were revised to include IMS 2.2 installation.
Thanks to Warren Hayward, TJX, USA.
Change 10.145 Landmark Monitor for CICS variable TAMRCNT is now INPUT
TYPEMON8 as PIB4. instead of PIB4.6.
Aug 18, 1992
Thanks to David Taylor, Owens & Minor, USA.
Change 10.144 NETSPY NSPYREC=N records with NCPELTYP=41 (29X) cause an
VMACNSPY INPUT STATEMENT EXCEEDED RECORD LENGTH error. Find the
Aug 18, 1992 line with NSPNEWVC PIB4. (note this is the line with
PIB4., not the earlier line with PIB2.), and delete it.
Thanks to Aubrey Tang, Government Insurance Office, AUSTRALIA.
Change 10.143 Amdahl APAF support did not keep variable BALANCE in the
VMACAPAF APAFDOMA data set, but now it does. Note that you specify
Aug 18, 1992 values 0 to 9 or A on the hardware screen, but the value
in the SMF record is 0 thru 10!
Thanks to George Scott, Rockwell International Corporation, USA.
Change 10.142 The "Appended" IMS log processing introduced in MXG 10.1
ASMIMSLG is almost perfect, but even perfection can be improved.
TYPEIMSA There were actually two errors in that release: LOGONID
Aug 12, 1992 was sometimes blank, and STRTTIME/ENDTIME were not reset
to GUTIME/OENQTIME, causing INPQUETM/SERVICTM/RESPNSTM
to be missing/incorrect. LOGONID was an omission in the
ASMIMSLG programs that create MXGIMSLG, and the time value
error was a correction in the back end of TYPEIMSA.
In addition, the Fast Path processing (IMS log 059x) that
was in TYPEIMS (the "old" way) has now been added to both
ASMIMSLG and TYPEIMSA. Moreover, Ashland's six-months use
of their contribution caused them to add enhancements to
the dynamic table allocation algorithms that are described
in comments in ASMIMSLG (and new, cleaner messages are now
printed on the SYSOUT for MXGIMSLG execution).
Thanks to J. Cary Jones, Philip Morris, USA.
Thanks to Pete Shepard, Ashland Oil, USA.
Thanks to Jeffrey S. Crum, Ashland Oil, USA.
Change 10.141 NPM changes in MXG 10.1-Change 10.106- cause INVALID DATA
VMAC28 FOR NTMPDUTH because PIB4 was mistyped instead of PIB4.
Aug 12, 1992 Change both occurrences of 'PIB4 ' to 'PIB4.'. Once this
was corrected, the values for NTNPDUTH/NTNOCCTH were noted
to be '7FFFFFFE'X, because NPM folks use that hex value as
their "infinity" (the real maximum is '7FFFFFFF'X since
the first bit is the sign bit). However, since MXG stored
these variables in LENGTH DEFAULT=4 variables, and since
the maximum hex value storable in four bytes is '7FFFFF00'
MXG was truncating the "infinity" from 2,147,483,646 to
2,147,483,392. To correct this truncation of infinity,
LENGTH NTNPDUTH NTNOCCTH 5; was added. These NTN fields
are PIUs (PDUs) or bytes (Octets) threshold values at
which NPM is to cut interval records. By specifying the
infinity value, the site is telling NPM to never write an
interval record based on these counters, and instead to
write timed interval records.
Thanks to Scott Ashby, U.S. Customs Data Center, USA.
Change 10.140 An interesting discovery was made by comparing the pagein
RMFINTRV counts in TYPE71 with the sum of the page in counts in the
Aug 7, 1992 TYPE72 observations (SET TYPE72; IF PERFRPGN=.; , to keep
only control performance group data). The TYPE71 PVTNPIN
was 46,912 page ins, while the sum of the TYPE72 PAGEINS
was 45,838, which means that the delta, 1074, page ins
were not counted in the address space data. This may be
a coding error in RMF code, or could be an indicator of a
special category of paging. IBM can't explain it, yet.
Thanks to Sandi Whitmyer, USA Funds, USA.
Change 10.139 The PRUWTR package, from Prudential Insurance, is used to
TYPE6 manage spool printing, and writes an SMF Type 6 record.
Aug 7, 1992 The READTIME value put in that record is incorrect; it is
taken from JCTCNVON, the converter on event, instead of
being taken from JCTRDRON, the correct value of when the
job's JOB card was recognized. Because the wrong time was
in READTIME, these type 6 records did not match up to any
of the other job records (BY READTIME JOB JESNR), and the
PDB.PRINT observations from PRUWTR did not have ACCOUNTn
values, and the PDB.JOBS observations did not include the
PRUWTR lines. Since PRUWTR is also source code, your JES
person can change the value from JCTCNVON to JCTRDRON, and
then the PRUWTR type 6 records will match other records.
Thanks to Norm Lacoe, Confederation Life, CANADA.
Thanks to Beth Wells, Confederation Life, CANADA.
Change 10.138 ROSCOE creates records for two new "ROSCOE monitors". The
VMACROSC JCL-CHECKER (MONITOR JCK) is identical with the JCL RECORD
Aug 6, 1992 and JCK records are added to the ROSCOJCL dataset. The
Documentview creates observations in ROSCOVPE that can be
recognized as documentview because VPEMONNM='DOC'.
Thanks to Norbert Korsche, OMV-AG, AUSTRIA.
Change 10.137 MVS/ESA XCF Type 74 record INPUT STATEMENT EXCEEDED
VMAC74 RECORD LENGTH and STOPOVER ABEND, because of an MXG error.
XMAC74 Find INPUT @OFF742MO, and change the immediately following
Aug 4, 1992 statement from DO _I_=1 TO NRDDSS; to DO _I_=1 TO NR742MO;
(make sure you change only this DO statement; there are
two other occurrences of DOs to NRDDSS that are correct!)
Thanks to John Nicholls, Health Insurance Commission, AUSTRALIA.
Change 10.136 MXG 10.1 Tape Mount Monitor ABENDs with S 55F at startup.
ASMTMNT Code added in 10.1 to support MVS/ESA 4.2 dynamic devices
Aug 4, 1992 perturbed the contents of Register 1. When the SYSEVENT
TRANSWAP was issued, the non-zero value in R1 is taken as
the address of an ECB to wait upon, but as it was now not
in the address space of the MXGTMNT, the ABEND occurred.
The fix is simple. Insert SR R1,R1 immediately
prior to the SYSEVENT TRANSWAP statement to zero Register
One, which tells TRANSWAP not to post any ECB address, and
thereby avoids the abend. This error was not in MXG 9.9.
Thanks to Andrew Jeppeal, Marshalls, USA.
Thanks to Matt Gallion, Tenneco, USA.
Change 10.135 DB2 Audit Detail Report isn't produced when more than one
ANALDB2R report was requested, or when the SORTBY operand was used,
Aug 4, 1992 because of a mislocated %END statement. Find the first
DATA _NULL_ after the %MACRO PMAUD02 statement, and insert
a %END; statement immediately before that DATA _NULL_
statement. Then find %MEND PMAUD02; and delete the %END;
statement immediately preceding that %MEND statement.
Thanks to Tom Hubbard, Westone Bancorp, USA.
Change 10.134 NPM variable PCTBUSY, for full duplex lines, contains the
VMAC28 maximum of Primary (outbound from NCP) or Secondary
Aug 3, 1992 (inbound to NCP) utilization, but PCTBUSY won't identify
when one direction dominates. MXG added two new variables
PCTPRBSY/PCTSCBSY which contain the utilization in each
direction. An additional network variable, PCTNEGPL, the
percentage of polls that were negative polls, was added as
it is useful in identifying network response problems.
Thanks to Scott Taylor, Primerica, USA.
Change 10.133 Some observations in PDB.JOBS can have JELAPSTM missing,
IMACPDB even though variable INBITS contains a 'J', indicating a
Aug 1, 1992 type 30_5 record was found. (If there is no 'J' in the
third position of INBITS, then JELAPSTM is expected to be
missing, since it is calculated from the 30_5 record.)
This error affected only jobs with more than 1476 unique
DD segments in their type 30_5 record, and resulted from
the absence of variable MULTIDD in the _PDB30_5 macro that
is defined in member IMACPDB. MULTIDD='Y' identifies the
"extra" type 30 record created where there are more than
1476 DD segments in the record, and is used in BUILDPDB/3
logic to recognize these pseudo job (and step) records.
Because it was not in TYPE30_5 in BUILDPDB, JELAPSTM was
inadvertently missing, and also variable RESTARTS was not
accurate for these jobs. To correct the error, variable
MULTIDD was added to the _PDB30_5 definition in IMACPDB.
You could workaround the error by adding the following
statement in your reporting program that uses JELAPSTM:
IF JELAPSTM=. AND JINITIME NE . AND JTRMTIME NE . THEN
JELAPSTM=JTRMTIME-JINITIME;
Thanks to Jim Cummings, First Interstate Bank of Oregon, USA.
Change 10.132 CICS Journal data can be sent to the type 110 SMF record.
EXCICJRN Some sites modify CICS to send data (such as logon/logoff)
Jul 30, 1992 to a journal and direct that journal to SMF. This change
creates a new exit which allows you to gain control (for
example, to process a user journal record). If you think
you need to use this exit, call for further assistance.
Note that Change 10.164 adds support for the SAP journal
record from SAP accounting, and does not use EXCICJRN.
Thanks to John Ebner, SystemHouse, USA.
Change 10.131 Amdahl's MDF architecture supports 16 LPARs, but MXG only
ASUM70PR supported 8 in its summarization and trending. (A message
TRND70PR alerts you that more than 8 were found.) This change
Jul 27, 1992 adds variables for the additional 8 possible LPARS.
Thanks to Jeff McFadyen, Ministry of Correctional Services, CANADA.
Change 10.130 Calculation of tape length for 3420 (reels) in VMACTMS is
VMACTMS5 slightly incorrect. The IRG (inter record gap) of 0.6" is
Jul 27, 1992 for 1600BPI tapes, and IRG is only 0.3 inches for 6250s.
For a full tape of 5200 blocks at 32760 blksize, the 0.6"
value caused a 2400 foot tape to be reported as 2530 feet!
Thanks to Malcolm Sare, Australian National, AUSTRALIA.
Change 10.129 SAS 6.07 under CMS has serious problems for MXG users.
Jul 27, 1992 The concat of sourclibs (USERID.SOURCLIB, MXG.SOURCLIB)
did not work, although it is now reportedly corrected.
The workaround is to make a complete copy of SOURCLIB
and make your tailoring changes in that copy until SAS
fixes the problem so you can reinstall with your changes
isolated in the USERID.SOURCLIB.
Standard label tapes cannot be read under CMS SAS 6.07,
but SAS is working on the problem with Systems Center.
Change 10.128 BUILDPDB under CMS SAS needs correction. The new macros
BUILDPDB VMXGDKRN/VMXGDKRW must be renamed VMXGDKN/VMXGDKW because
BUILDPD3 CMS SAS is limited to only seven character macro names.
Jul 27, 1992 Additionally, execution under CMS SAS 5.18 will require
the addition of a FILE DEF for SMFTEMP, and the DCB=SMF in
the FILE SMFTEMP statement in BUILDPDB must be changed to
DCB=VB LRECL=32756 BLKSIZE=32760 since CMS cannot create
VBS files.
Change 10.127 JCLPDB6 in MXG 10.1 will fail with DATASET PDB.TYPETMNT
BUILDPDB NOT FOUND error, because ASUMTMNT is included in JCLPDB6
BUILDPD3 sample program, but the intended automatic creation of the
Jul 24, 1992 TYPETMNT (Tape Mount Monitor records, created by ASMTMNT),
did not get into MXG 10.1. Now, BUILDPDB/BUILDPD3 will
create TYPETMNT dataset, so that if you install MXGTMNT to
create SMF records, you will now only have to update the
IMACTMNT member in your USERID.SOURCLIB to tell MXG what
SMF record number you assigned, and your tape mount times
will automatically be in your PDB library.
Thanks to Jeff McFadyen, Ministry of Correctional Services, CANADA.
Change 10.126 Variable QWHSLUUC should have been spelled QWHSLUCC in
ANALDBTR the _VTRCMN macro definition for DB2 Trace processing.
Jul 24, 1992
Thanks to Christophe Faure, SAS Institute, FRANCE.
Change 10.125 Variable DS4VTOCE was input but not kept, and was not
VMXGVTOC labeled. Add it adjacent to DS4VTOCI in the keep list,
VMXGVTOF and add DS4VTOCE='VTOC*EXTENT*DESCRIPTION' adjacent to
Jul 24, 1992 DS4VTOCI in the LABEL statement.
Thanks to Christophe Faure, SAS Institute, FRANCE.
Change 10.124 IBM incompatibly changed the PSF type 6 SMF record, but
VMAC6 the change was not documented! Bin counts were added to
Jul 22, 1992 the APA subsection (and the added length was NOT added to
SMF6LN4!), and the ESS subsection, formerly only in the
JES2 type 6 SMF record, now exists in the PSF record; this
unexpected segment caused incorrect values for the APA
subsection variables DOCLENFT/FONT,OVLY,PGSG USED-LOAD.
The simple fix is to relocate the ESS section DO group
(22 lines) which starts with
IF SECTIND='...1....'B AND OFTONXT ... /* ESS SEG */
to just after the end of the PSF section DO group, which
starts with
IF SECTIND='..1.....'B AND OFTONXT ... /* PSF-APA */
This change also added BINnBNCT variables for 8 bins.
The APAR which apparently made this change is OY30945.
Thanks to Kevin James, Cornhill Insurance, ENGLAND.
Thanks to Tim Sparrow, Cornhill Insurance, ENGLAND.
Change 10.123 Variables R791BPIN,PINE,BPNE,CTAR, and R791VAL were added
VMAC79 to TYPE791 dataset. The test IF SMF79ASL GE 96 before the
Jul 21, 1992 input of R791HIN was changed to IF SMF79ASL GE 98. The
MVS/ESA 4.2 value for R791FMCT is occasionally too large
(129MB for INIT with WM/LW); IBM is investigating.
Variables R794PPIA/LPIA were added to TYPE794 dataset,
and redundant LCUID code was removed from TYPE79E logic.
Thanks to Steve Saunders, Talbots, USA.
Change 10.122 Total page movement between central and expanded storage
VMAC71 is EXTREADS (from ESTORE to CSTORE) plus PGMVTOEX (from
Jul 21, 1992 CSTORE to EXTORE). The sum of EXTREADS+PGMVTOEX is useful
in comparing before and after effects on memory changes.
Thanks to Sigfrido Perdomo, Metropolitan Life, USA.
Change 10.121 Datasets ILKAST20 and ILKAST21 had invalid data because
VMACILKA the offset was incorrect, and the documentation was wrong.
Jul 21, 1992 Change the line reading:
Aug 18, 1992 FPTDCSOF=FTPDCSOF-3+OFFSMF;
to read:
FPTDCSOF=FTPDCSOF+SMFACDOF;
Change the line reading:
FPTDCTOF=FTPDCTOF-3+OFFSMF:
to read:
FPTDCTOF=FTPDCTOF+SMFACDOF;
Change the +3 following F20DTTY PIB1. to +1
Change F21FVOL from $CHAR8. to $CHAR6.
Change F21DAIR from $CHAR8. to $CHAR4.
Change F21DARC from $CHAR8. to $CHAR1.
Insert two lines after F21SBMSG PIB2.
@;
IF FTPDCTLN GE 129 THEN INPUT
to conditionally input F21DAIR/F21DARC (a feature that was
not documented by the record's vendor!).
Thanks to Paul Mei, Imperial Oil Limited, CANADA.
Change 10.120 New variable M24IODEV is input in M24LOGOF and M24SINCE
EXM24ACT datasets, and the account input code formerly in EXM24ACT
VMACM204 (for compatibility with archaic versions of MODEL204) was
Jul 19, 1992 moved into VMACM204. EXM24ACT is no longer referenced.
Change 10.119 A strange type 30 subtype 1 record caused INPUT STATEMENT
IMACACCT EXCEEDED RECORD LENGTH error because of an MXG logic error
Jul 17, 1992 if a type 30 ends with an account section. This record is
questionable, as it contains only a PROD, ID, and ACCT
section, and the "INITTIME" is nulls, so this may in fact
be an invalid record, but MXG still should not fail too!
Change the last line of IMACACCT to read
IF LENGTH GT TEMPLOC THEN INPUT @TEMPLOC @;
so the existing INPUT @TEMPLOC @; is only executed if the
record has additional data sections.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 10.118 The Cache DASD analysis was incorrect. LCU and DEVADDR
ANALCACH could be missing, and only the first LCU was reported.
Jul 17, 1992 The logic was revised to merge BY LCU VOLSER and output
Oct 8, 1992 only when both TYPE74 and CACHE90 had data (MXG does not
output TYPE74 if there was no I/O activity during the
interval, while CACHE90 always had an observation.)
Thanks to Scott Ashby, U.S. Customs Service, USA.
Change 10.117 Execution of MXG's BUILDPDB under the CMS version of 6.07
BUILDPDB causes APPARENT MACRO INVOCATION ERROR message, because I
BUILDPD3 forgot that CMS is limited to seven-character %macro names
BUILD518 when I added %VMXGDKRO and %VMXGDKRW macro definitions and
Jul 17, 1992 invocations in MXG 9.9! Change both VMXGDKRO to VMXGDKO
and both VMXGDKRW to VMXGDKW to comply with the CMS limit.
If you are still executing under CMS 5.18, there are other
problems! The FILE SMFTEMP DCB=SMF; statement will fail
under CMS if the input SMF file is a VBS file, because you
can only read VBS under CMS, you cannot create VBS. You
would need to change BUILD518 to use
FILE SMFTEMP RECFM=VB LRECL=32756 BLKSIZE=32760;
and pray you never see an SMF record that is 32760 bytes
long!
Thanks to J. D. Hill, CyCare Systems, USA.
Change 10.116 STC Release 1.2 of the STC4400 HSC SMF record was changed
VMACSTC incompatibly. The one-byte STC07CON field in the middle
Jul 15, 1992 of the record is now a four-byte field. MXG does not fail
but the data values are trashed, and of course there is no
record version indicator in this subtype 7 record!. The
correction is to replace STC07CON PIB1. with
@;
IF LENGTH-OFFSMF EQ 105 OR LENGTH-OFFSMF EQ 137 THEN
INPUT STC07CON PIB1. @;
ELSE INPUT STC07CON PIB4.
Thanks to Glen Farmer, Hallmark Cards, USA.
Change 10.115 SYNCSORT variable COREREQ can be negative! If you specify
VMACSYNC "MAX-100K", indicating SYNCSORT can use the REGION size
Jul 13, 1992 minus 100K, COREREQ will be -100K, after you change the
INPUT statement for COREREQ from PIB4. to IB4.
Thanks to Brian LeBlanc, Chrysler Corporation, USA.
Change 10.114 CA TOP SECRET causes INPUT STATEMENT EXCEEDED RECORD due
VMAC80 to a change in the value CA stores in RACFVRSN. The type
Jul 12, 1992 80 SMF record created by TOP SECRET is identical in format
to the IBM record, but CA's OFFSET is from the beginning
of the physical record, while IBM's OFFSET is from the
start of the logical record. MXG tests RACFVRSN to know
if the record is an IBM or a CA record. A new value of
43X (previous values were F3X or F4X) must be added to the
test in line 007700 to recognize this as a CA record. I
assume this new value is associated with a new release of
TOP SECRET, but nobody at CA bothers to keep me informed!
As an aside, the CA OFFSET value is actually consistent
with offset values in other SMF records; the RACF type
80 is the only IBM record which calculates offset from
the logical record!
Thanks to Mark Paulson, Maurices, USA.
==Changes thru 10.113 were included in MXG PreRelease 10.1 Jul 10, 1992=
Change 10.113 Sample IEFU83 SMF exit that filters type 40 SMF records,
ASMIEFU8 only write SMF records for tape devices. This exit is in
Jul 10, 1992 use to measure tape drive allocation time by merging SMF
type 30, type 40, type 21, and MXGTMNT SMF records with an
algorithm still in development, but the exit by itself may
be useful so that you can create type 40 (deallocation of
dynamically allocated devices) for tapes only, and thereby
determine the JOB name of those jobs which allocate tape
devices dynamically (so that they can be excluded by JOB
name in MXG's ANALTAPE analysis).
Thanks to Gary Strohminger, AT&T Transtech, USA.
Change 10.112 Major revision in support for OPC/A log processing. This
EXOPC... significant user contribution adds several new datasets
FORMATS and expands logic to handle records spanned across blocks.
IMACOPC The "OPCA" prefix for dataset names was changed to "OPC",
TYPEOPC the variables prefixed "OPC" are now prefixed "TRL" to
TYPEOPC agree with IBM field names, and the input file is now
VMACOPC OPCLOG instead of OPCALOG. (To eliminate confusion with
VMACOPC the earlier MXG support, members TYPEOPCA/VMACOPCA are
Jul 9, 1992 deleted and replaced by TYPEOPC/VMACOPC.). See comments
in member VMACOPC for an appreciation of the extensive
work that the contributor accomplished.
Thanks to Rodney Marwick, Vereinte Versicherungen, GERMANY.
Thanks to Wolfgang Vierling, Vereinte Versicherungen, GERMANY.
Change 10.111 Verstand's product, TTX, is now a part of MXG Software!
TTXPDS The TTX product is a set of tools for capturing MVS data
Jul 7, 1992 (control blocks, data records, etc.) from within a SAS
program; many of its tools are implemented as ASM source
code routines that (once assembled and link-edited) can
be CALLed from within SAS. Most MXG sites probably will
not need to create monitors, but TTX is now available in
MXG if you need it. (TTX customers found TTX useful for
its DASD space measurement and Tape Device analysis, but
both these facilities were already provided to MXG sites
in ASMVTOC, ASMVVDS, and MXGTMNT. In fairness, however,
it must be noted that TTX tape monitoring also provides
device allocation time statistics not (yet!) captured in
MXGTMNT.) The single MXG member, TTXPDS, is actually a
164-member PDS that contains installation instructions,
excellent documentation, and commented source code for the
ASM and SAS TTX programs. Please let us know which parts
of TTX you have found useful.
Thanks to Guy Garon, Verstand, CANADA.
author and creator of TTX.
Change 10.110 Support for AS400 now supports V2R1M0 (and V1R3) and was
ADOCQAPM restructured. New members TYPEQAPM/VMACQAPM now follow
AS400PDS MXG naming conventions and builds all 13 QAPM.... datasets
JCLQAPM from AS400 data. Member ADOCQAPM documents how to extract
TYPEQAPM AS400 data and sending it to MVS, and JCLQAPM shows how to
VMACQAPM split an AS400 tape into 13 files, and invokes TYPEQAPM to
VMXGDSNL create all 13 QAPM.... datasets from those files.
Jul 6, 1992 AS400 data does not contain a "system" identifier, but you
can use the DSNAME of the MVS dataset with the AS400 data
to identify which AS400 system's data is being read. The
macro _MXGDSNL opens the INFILE and extracts the low-level
qualifier of the GDG into the %macro variable &LOWLEVEL
that is then stored in variable AS400SYS in each QAPM....
dataset. AS400 support in VMACQAPM is fully functional,
but variables are not yet labeled and the datasets need to
be better documented.
The _MXGDSNL was originally a %MACRO, but an 0C4 ABEND
in the %MACRO compiler caused me to change it and use
the old-style substitution macro, even though it is in
a "VMXG...." member normally used only for %MACRO. SAS
Zap Z6074721 corrects the problem; when pervasively
installed, I may revert back for consistency.
Thanks to John Astle, National Australia Bank, AUSTRALIA.
Thanks to Greg Scriba, Budget Rent-a-Car, USA.
Change 10.109 MXG source members have always been numbered lines, but
CONFIG if you submit a job with the SYSIN statements unnumbered,
CONFIG07 you will receive a very un-obvious 180 syntax error.
SASOPTV5 With option S=0, SAS reads columns 73-80 of the first SAS
Jun 30, 1992 statement, and if no line numbers are found, SAS concludes
your source statements are unnumbered, and sets S=80 to
read all 80 columns. However, when you %INCLUDE an MXG
member, those line numbers in columns 73-80 cause the SAS
180 syntax error, or even an "UNEXPECTED END OF FILE".
To prevent the occurrence of this error, MXG members
CONFIG, CONFIG07 (for SAS Version 6) and the (now archaic)
SASOPTV5 (for SAS Version 5) contain options S=72 and
S2=72 so that SAS will always only read columns one thru
seventy-two as MXG SAS statements.
Thanks to MP Welch, US Sprint Dallas, USA.
Change 10.108 APPC variables in TYPE30 have incorrect values. Variables
VMAC30 APPCDAT and APPCDAR must be input as RB8. instead of the
Jun 30, 1992 present PIB4. format.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 10.107 Messages "INFO: THE VARIABLE xxx ON DATA SET yyy WILL BE
DOC OVERWRITTEN BY DATASET zzz" are printed on the SAS log if
Jun 30, 1992 SAS options MSGLEVEL=I is specified (the default is N).
These messages result when MERGE datasets have multiple
occurrences of the variable xxx, and are not informing you
of any problem. (These info messages may be useful during
testing, but they serve no purpose in normal execution.)
Thanks to Doug Drain, National City Bank, USA
Change 10.106 NPM 1.5.1 subtypes 90x-96x (144-150) caused "NONZERO TOF"
VMAC28 or "RECORD NOT OUTPUT" message; these X.25 records had not
Jun 30, 1992 been validated. Only the new NPMEVX25 dataset is affected.
Lines 168100,168200,257100 values 92, 95, 96 must be 92x,
95x, and 96x. Line 329100 must be changed to read:
ELSE IF 90X LE NPMSUBTY LE 92X OR NPMSUBTY=96X THEN DO;
Line 329400 must be changed to read:
ELSE IF 93X LE NPMSUBTY LE 95X THEN DO;
Line 242900 (+1 following DDD input) must be deleted.
Variables LXETDDTA/LXETGDTA (lines 242000-242100) must be
$CHAR9. vice $CHAR8. Most LXET.... variables are now
formatted as $HEX, as they contain unprintables.
Thanks to Scott Ashby, U.S. Customs Data Center, USA.
Change 10.105 STC 4400 SMF record decode used the same bit of STC07TYP
VMACSTC to decode its eight variables, instead of successive bits
Jun 29, 1992 for each variable, starting in line 034800.
Thanks to Daryl Skufca, DITSO Cleveland, USA.
-----Changes thru 10.104 were printed in MXG NEWSLETTER TWENTY-TWO-----
Change 10.104 EPILOG/MVS support was still wrong, after Change 10.079!
VMACEPMV The *SM180NIO and *SM180NEQ should have been
Jun 24, 1992 *(SM180NIO-1) and *(SM180NEQ-1) respectively. Also, the
input SM180RID RMFSTAMP8. is now SM180RID ?? RMFSTAMP8.
because the field is incorrect in the SM180SUB='TOTS' data
record. Because MXG the EPMVEP dataset contains events
TOTS/PGN/PGP/TSO,BAT,STC/tso,bat,stc/ some fields may not
be valid for some values of SM180SUB. It is possible that
separate datasets may be created for each event type in
future MXG versions, but that is still under study.
Thanks to Wayne Parrino, Avery-Dennison, USA.
Change 10.103 A "MONWRITE" equivalent from some vendor creates VM/ESA
VMACVMXA monitor files with an extra, and invalid, control record
Jun 23, 1992 between the valid "end" and "start" control records. The
problem is being investigated with the vendor, but this
circumvention has been added to MXG to strengthen its test
for a valid control record. After the @; after variable
IPARMLF1 has been input, insert the following statement:
IF IPARMLF1 NE 00008709X THEN DELETE;
The actual MXG change also puts a message on the log that
the unexpected/invalid record has been deleted. This
site's "MONWRITE" file also contained incorrect bytecount
values which are also being researched.
Thanks to Yam Tan, British Airways, ENGLAND.
--Changes thru 10.102 were in Beta MXG PreRelease 10.1 of Jun 22, 1992--
Change 10.102 RMDS Delete Directory record, ORG=M,ACT=D,Key=x0101'x is
VMACRMDS written erratically with inconsistent contents when it
Jun 21, 1992 is compared to the IBM DSECT, and causes INVALID DATA
message for variables RMDSMXVR,LLTH,VWDP,HHLD. This is
not an important RMDS record, and only served to print
a hex dump on the log. Now, all Packed Decimals are ??
protected to eliminate the message and hex dump.
Thanks to Norbert Korsche, OMV-AG, AUSTRIA.
Change 10.101 ROSCOE variables starting with ADSFUN2 thru ADSFNDSN are
VMACROSC input incorrectly. Starting in line 074800, the offsets
Jun 20, 1992 should be 211,219,227,235,243,251,259, and 259 (it was
obvious once pointed out). Also, ADFSMEM and ADFSNDSN
logic was enhanced and cleaned up in this change.
Thanks to John Ellis, Commercial Union, USA.
Change 10.100 Fujitsu's FACOM MSP/EX SMF records are now supported.
IMACFACO Type 6,22,26 and 57 records were changed incompatibly,
VMAC6 but only TYPE6 (PDB.PRINT) variables NODE,RMOTID and
VMAC26J2 TYPE26J2 (PDB.JOBS) INROUTE,PRROUTE,PUROUTE,INDEVICE
Jun 19, 1992 variables will be incorrect without this change. The
type 6 one-byte NODE/RMOTID pair was expanded in place
to two bytes each. The type 26 record was also changed
to support two-byte node/rmotid for the IN,PR, and PU
route codes, but instead of putting these data in IBM's
pre-defined Routing Section, FACOM decided to tack those
fields on to the end of the descriptor section! Facom
MSP/EX users must update member IMACFACO to tell MXG
your operating system level to cause MXG to read in
their relocated data. See comments therein.
Unfinished in 10.1 Beta:
Type 26 may have also relocated DEVNAME (SMF26NDV), but
that relocation is not coded yet. This should have no
impact except for that variable.
Type 22 record change was only to make existing fields
reserved, and had no impact on MXG code or execution.
Type 57 record has also relocated DEVNAME, but type 57
is not used in any standard MXG BUILDPDB nor reports.
Thanks to Joan Dobbie, Justice Information System, S.A., AUSTRALIA
Change 10.099 I sure missed this one! IBM changed the format of DEVNR
VMAC75 with MVS/ESA 4.2.0 records. DEVNR (or UNITADDR, its old
XMAC75 MVS/370 name) used to be written as hhhF (device BF7 was
Jun 17, 1992 'BF7F'x. Document APAR OY48957 now indicates that DEVNR
is now written as hhhh (to support 4-hex-digit addresses).
Since this was not documented in the 4.2.0 SMF manual, MXG
continued to divide by 16 to shift the "F" out. Now, the
correction is to replace line 020400:
DEVNR=FLOOR(DEVNR/16); with
IF MVSLEVEL LT 'SP4.2.0' THEN DEVNR=FLOOR(DEVNR/16);
I'm surprised it took this long for this error to show
up, but a) the VOLSER was correct, which I guess most
people use in tracking paging activity, b) it did not
create a note or message, just a wrong value, and/or
c) MVS/ESA 4.2.0 is so good, and sites using it are so
smart as to get enough memory, so that paging and swap
are no longer the bottlenecks which caused us to look at
TYPE75 data regularly in earlier operating systems!
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 10.098 System Center's NETMASTER type 37 SMF record supported.
VMAC37 Their record is basically compatible with NETVIEW type
Jun 19, 1992 37 records, but they set PRODUCT='NETM' instead of the
'NETV' value expected, and their subtype 2 record also
contains the GEND triplet, while IBM's subtype 2 did
not. Change IF PRODUCT='NETV' THEN to
IF PRODUCT='NETV' OR PRODUCT='NETM' THEN and
replace IF PRODUCT='NETV' AND SUBTYPE GE 3 THEN with
IF (PRODUCT='NETV' AND SUBTYPE GE 3) OR
(PRODUCT='NETM' AND SUBTYPE GE 2) THEN
for MXG to support either NETVIEW or NETMASTER records!
Thanks to Normand Poitras, TELEGLOBE Canada, CANADA.
Change 10.097 Analysis of VSAM data sets may have the incorrect value
ANALDSET for PROGRAM name. Variable SORTTIME, created in the
Jun 17, 1992 ADD statements for NAME=EXTY64 in this member, defaulted
to LENGTH 4, causing truncation of the value (up to 255
seconds could be lost), causing incorrect sequence with
the INITTIME value from the file's step record. Insert
LENGTH SORTTIME 8; after SORTTIME=SMFTIME to fix this
error. Also, TYPE64 does not contain variable OPEN that
is used in ANALDSET, causing VSAM Input and Output I/Os
to be summarized together in DSNSUMS. In the IEBUPDTE
step, add OPEN to the KEEP= list for TYPE64, and just
before the OUTPUT TYPE64; statement insert:
IF ACBOUT='Y' THEN OPEN='OUTPUT ';
ELSE OPEN='INPUT';
IBM Info/Sys Item Q494663 (all 39 pages) confuses issues,
but ultimately points out that the count of INSERTS,SPLITS
UPDATES, etc., in a type 64 record "Change" counter is not
due to this job's open, but is the catalog change since
open, and that is why you can see UPDATE counts non-zero
for INPUT! Only the EXCPS count in TYPE64 is for this
open (as it alone was fixed by ancient APAR OY15663).
Thanks to Gary Matney, Twentieth Century Investors, USA.
Change 10.096 PDBTREND JCL example builds PDBs and updates TRENDs from
PDBTREND SMF input for new sites to "initialize" their past trend
Jun 16, 1992 from before they begin regular building of the PDB. The
sample report herein used RMFINTRV/TYPE72 instead of the
TRNDRMFI and TRND72 dataset names (which were change way
back in MXG 8.3, but this example was overlooked).
Thanks to Mike Skopec, Platinum Technology, USA.
Change 10.095 Support for Blue Line's Vital Signs for VTAM product,
VMAC28 which creates type 28 SMF records, has been tested.
Jun 13, 1992 Six subtypes (10x,11x,12x,13x,20x, and 30x) populate the
five MXG interval NPM datasets NPMINLU,NPMINNCP,NPMINPU,
NPMINRTM, and NPMINSES. The Version 2 Release 0 level of
Blue Line is required, as the type 28 records written by
earlier releases were not correct.
Change 10.094 DB2 Accounting Detail and Summary reports now will use
ANALDB2R the (new in 10.1) summarized (and thus smaller) ASUMDB2A
Jun 13, 1992 dataset if it is found in the PDB= input library list.
This will significantly reduce the run time of ANALDB2R.
(Only the Accounting Trace needs the detail transaction
records in DB2ACCT; the Accounting Detail is really a
summary, and ASUMDB2A is summarized at that same level!)
You can force MXG to use the DB2ACCT dataset with the
new USEACCT option: %ANALDB2R(PDB=PDB,USEACCT=YES);
If you have taken advantage of sending your DB2ACCT
data to the DB2ACCT ddname (Change 10.053), and you
have added ASUMDB2A to your BUILDPDB and WEEKBLD jobs
(Change 10.yyy), then your existing %ANALDB2R reports
with PDB=PDB specified will work just fine.
If you have put your DB2ACCT data in the DB2ACCT dd,
but did not build ASUMDB2A, to get your DB2 Account
reports, you will need only to add the DB2ACCT ddname
to the PDB= list of ddnames to be searched:
%ANALDB2R(PDB=PDB DB2ACCT);
The ANALDB2R reports now include the new DB2 2.3 fields
printed by DB2PM, except for the DDF data fields,
because we have no test data (hint, hint)!
Change 10.093 Trending of DB2ACCT data will now use the new ASUMDB2A
TRNDDB2A dataset if it exists in the WEEKly PDB library, but if
Jun 12, 1992 ASUMDB2A has not been created in your WEEKly PDB, then
TRNDDB2A will use the DB2ACCT dataset (which is more
expensive because it has many more observations than
does the ASUMDB2A dataset built by member ASUMDB2A).
Change 10.092 Minor cleanup of several of the TREND members. Variable
TRNDRMFI ZDATE was added where missing and INTERVAL (the number
TRND70 of RMF intervals) is created in RMF based datasets for
TRND70PR enhanced reporting capabilities.
TRND71
TRND72
Jun 12, 1992
Change 10.091 One user asked for it, here it is. Enhancement of the
MNTHCICS MXG TREND architecture to trend monthly in addition to
MNTHDBDS the strongly preferred weekly trending. MXG strongly
MNTHDB2A feels weekly trending must be used for capacity trends,
MNTHDB2S but some sites still think they need monthly trends too!
MNTHJOBS The MNTH.... are corresponding TRND.... members modified
MNTHRMFI to create MNTH.... instead of TRND.... output datasets,
MNTH70 with the interval set to MONTH. The MONTH PDB should be
MNTH70PR used as input, although WEEKly PDBs can be used (but the
MNTH71 current month's data will be incomplete until monthend.)
MNTH72
Jun 12, 1992
Change 10.090 The DB2ACCT dataset was externalized by Change 10.053,
ASUMDB2A but it may be too large for typical analysis. Just like
Jun 12, 1992 ASUMCICS summarizes CICSTRAN transactions records into a
much smaller, yet very usable PDB.CICS dataset in the PDB,
member ASUMDB2A summarizes DB2ACCT detail accounting (DB2
"transaction") records into the much smaller, yet also
very usable PDB.ASUMDB2A. ANALDB2R will use the smaller
PDB.ASUMDB2A (if it exists) in DB2 reports reduce the
amount of data that must be read. The input dataset is
the DB2ACCT dataset and the summarization is BY QWACLOCN
QWHCCN "date-hour" SHIFT (where "date-hour" is the value
of QWACBSC at the hour level).
IT IS STRONGLY RECOMMENDED that all DB2 sites add ASUMDB2A
to your daily PDB by adding
%INCLUDE SOURCLIB(ASUMDB2A);
following the include of (BUILDPDB); this has already been
added to the BUILDPDB step in the JCLPDB6 example.
Sites with extremely large DB2ACCT datasets may choose to
execute the ASUMDB2A include in a separate JCL step, since
the WORK space required for sorting and summarizing
DB2ACCT into ASUMDB2A can be greater than the WORK space
you normally allocate in your BUILDPDB.
If you follow the MXG recommendation and create ASUMDB2A
daily, you will also need to add code to EXPDBWEK (or
modifying WEEKBLD) to create the WEEK.ASUMDB2A dataset
in your weekly PDB from dailies. ASUMDB2 would have
been automatically included in MXG's BUILDPDB except for
the possible problem with work space cited above. The
dataset should prove to significantly reduce the cost of
ANALDB2R reporting.
Change 10.089 %VMXGSUM is enhanced to provide two new macro parameters
VMXGSUM MINTIME= and MAXTIME= that name the datetime variable
Jun 12, 1992 that will be used in building the minimum and maximum
datetimestamp values in each summary record. (Because
timestamps require LENGTH 8, and all SUM= MIN= MAX= or
MEAN= have a length of 4), new parameter names were
necessary. Variables MINTIME and MAXTIME are created in
the output dataset created by %VMXGSUM.
Change 10.088 BUILDPDB/3 redundant SORTs of DB2STAT0 and DB2STAT1 were
BUILDPDB removed because SORTs were relocated into DIFFDB2. Some
BUILDPD3 superfluous OPTIONS were removed from DIFFDB2. READDB2
DIFFDB2 standalone execution that unintentionally always sent the
READDB2 output to the PDB DDname was also corrected.
Jun 12, 1992
Change 10.087 Product Documentation "ADOC...." members have been added.
ADOCAAAA Twenty-five "Products" are now documented in the style of
Jun 12, 1992 future MXG online documentation, although none of the ADOC
members are completely finished, and the text is still in
draft (no spell check, no grammar check, author's "zzzzz"
mark where there's more to be written). Nevertheless, the
detail description of the MXG variables and datasets built
from each "Product" are now consolidated into an ADOC per
VMAC and the technical descriptions are now current. As
additional ADOCs are completed, they are added to the next
MXG PreRelease. Comments, criticism, and suggestions for
this ongoing project are welcome.
Change 10.086 Trending of Printer Throughput could cause divide by zero
TRNDPRTR message (but no impact on the Trend Database). Zerodivide
Jun 12, 1992 protect lines 002200 and 002300 (by adding the IF test):
IF denominator GT 0 THEN XXX = YYY / denominator ;
Thanks to Dan Barbatti, Southwestern Bell Telephone, St. Louis, USA.
Change 10.085 ANALDSET step IEBUPDTE did not create a null member name
ANALDSET of IMAC30DD in &SOURCLIB, and if the MXG.SOURCLIB member
Jun 12, 1992 IMAC30DD had been modified, a 311 error occurred. A new
line XY ADD NAME=IMAC30DD was added to the IEBUPDTE.
Thanks to Mike Crane, Annheiser Busch, USA.
Change 10.084 Pete Shepard and Jeffrey Crum, Ashland Oil, have provided
ASMIMSLG a significant contribution to MXG processing of IMS log
JCLIMSLG records. MXG's algorithms have tried to recognize an IMS
TYPEIMSA transaction after the fact from log records that do not
TYPEIMSB have a consistent token. Pete and Jeffrey's work solved
VMACIMSA that major weakness of the IBM IMS log records by creating
Jun 11, 1992 a pre-processor Assembly program that reads the IMS log
records, acts like the IMS queue manager, adds transaction
identifier to some of the log records, and even stores the
status of the IMS queues to initialize the next run. The
modified records are then SORTed and manipulated with a
new SAS program, TYPEIMSB (that does not create SAS data
sets, but instead manipulates IMS log records).
The fourth and final step of the algorithm uses a modified
version of MXG's TYPEIMS, (named TYPEIMSA for "Appended"
IMS record processing) to combine the two sets of IMS log
records into the _IMSTRAN.IMSTRAN MXG dataset.
The algorithm requires two additional IMS log records, the
10x and the 33x, that must be selected in your IMS archive
log job. These are the IMS log records now required:
01x 03x 07x 08x 10x 31x 33x 35x 36x
The ASM program, MXGIMSLG, is created by MXG member
ASMIMSLG, the ASM source code and the JCL to assemble and
link edit MXGIMSLG. Member ASMIMSLG also contains the
documentation of the algorithms, and a schematic of the
four steps of this "Appended IMS log" processing.
Member JCLIMSLG contains the JCL and documentation of the
four-step job to build the _IMSTRAN.IMSTRAN dataset:
STEP01 - Execute MXGIMSLG to read IMS log, split into
two OS files, IMSSUM and IMSMPRS. In addition,
reads INQUEUE (last run queue status) and then
writes OUTQUE (for input to next run).
STEP02 - SORT the IMSSUM file into IMSSUMSO.
STEP03 - Execute TYPEIMSB SAS step to read IMSSUMSO and
write out IMSMERGE OS file.
STEP04 - Execute TYPEIMSA SAS step to read IMSMERGE and
the IMSMPRS IMS log records to create IMSTRAN.
This enhancement fixes transaction response time measures,
but the IMS log records can never be used for accurate IMS
resource measurement by transaction, because IBM does not
create a resource record per transaction. The IMS 07x
record contains total CPU Time and DL/I calls per program
schedule event, which can include many transactions. Thus
IMSTRAN contains only the average CPU time and DL/I calls
for each group of transactions reported in each 07x.
Only a major change in IBM's functional design of the IMS
log can provide accurate IMS measurement of both resources
and responses of IMS transactions.
Nevertheless, this should be a major improvement in the
response measurement from IMS log records for sites that
do not have an IMS transaction monitor product.
The new algorithm has only been tested with IMS 3.1. It
is not my intention to test or revise the algorithm for
any earlier IMS versions. If any user lets me know that
the algorithm has been validated with earlier IMS log
records (by assembling MXGIMSLG using that version's macro
libraries), we will so report here in this Change text.
Thanks to Pete Shepard, Ashland Oil, USA, USA.
Thanks to Jeffrey S. Crum, Ashland Oil, USA, USA.
Change 10.083 Change 9.017 discussed how vars can be DROPped with a
DOC DROP statement in an EXTY member, but did not stress that
Jun 10, 1992 the DROP statement is global to ALL datasets being built;
if a variable name is DROPped in an EXTY member, it is
dropped from all other datasets with that variable name in
that SAS DATA step, even if the variable name is in the
KEEP= option of the DATA statement!
The only way to drop a variable name from a specific MXG
dataset is to copy the _VAR.... macro into member IMACKEEP
and erase the variable name from the KEEP= list for the
specific dataset. (Perhaps someday, I'll find a simpler
way.)
Thanks to John Astle, National Australia Bank, AUSTRALIA.
Change 10.082 For TMS tapes with multiple datasets per volume, or for
TYPETMS5 datasets that span multiple volumes, the MERGE of their
Jun 10, 1992 TMSREC (volume record, with 1st dataset information) with
DSNBREC (dataset record for 2nd+ datasets on a volume) MXG
overlaid some dataset-related TMSREC variables with their
DSNBREC values requiring revision of the MERGE logic.
More important: the calculation of TAPEFEET was changed.
TAPEFEET of a dataset was calculated only if the RECFM was
F/FB/VBS/VS, which have absolutely known record length.
For V/VB/U files, MXG did not calculate a TAPEFEET,
because record length was not guaranteed. I now think it
better to always calculate the estimated TAPEFEET for all
datasets, even though it may overestimate the feet used
occasionally. Since the primary use of TAPEFEET is to
identify tapes using "lots" or "few" feet (i.e., "good" vs
"bad" tape usage), always calculating TAPEFEET will ensure
that tapes with lots of data (i.e., large BLKCNTS) aren't
misidentified as "few" because they have variable lengths.
Jun 30, 1992 Note: After Newsletter TWENTY-TWO was sent to printer:
Variable TAPEFEET now exists in both TMS.TMS and DSNBREC,
and is calculated for all datasets. Not only was the code
in TYPETMS5 redesigned, VMACTMS5 had to be changed. Now,
VOLSER in DSNBREC is equated to FVOLSER for multi-volume
files, because FVOLSER is the actual volume with this DSN,
and VOLSER was the first volume of the multi-volume tape!
(the original VOLSER in DSNBREC is now in OVOLSER).
Thanks to Tom White, US.Sprint, USA.
Change 10.081 Support for RSD's WSF (or WSF2) Release 3.4.1 added new
VMACWSF accounting fields ACCX.... to the WSFACCT (for AREP, ERD,
Jun 10, 1992 PROFILE, and WSF2 events) and to the WSFERD (for ERD Batch
and WSF2 Batch). It appears the job accounting fields and
jobname are those of the WSF2 Bundling job, and not the
(desired!) users accounting information.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 10.080 Variables FSTTRKR and FSRTRKW (tracks read and written)
VMACHSM can be negative (for Small Data Set Packaging, SDSP, or
Jun 9, 1992 for VSAM, but MXG input them as PIB2. instead of IB2.
We are still asking IBM what it means to read negative
tracks (or write them!)? IBM APAR OY58311/OY61585 fixed.
Thanks to John Mattson, National Medical Enterprises, USA.
Change 10.079 EPILOG/MVS support was wrong. MXG failed to subtract 3
VMACEPMV bytes from two offsets, and did not protect for zero value
Jun 9, 1992 in triplets used in the two iterative DO groups. Before
each of the statements "DO SM180Oxx=SM180Oxx TO ..."
(where xx=IO or xx=EQ), insert the following two lines:
SM180Oxx=SM180Oxx-3+OFFSMF;
IF SM180Oxx GT 0 AND SM180Nxx GT 0 AND SM180Lxx GT 0 THEN
to correctly calculate the offset, and to conditionally
execute the (now following) iterative DO group only if all
triplet fields (offset, length, and number) are non-zero.
In addition, the RSRC subtype (SM180SUB='RSRC') record is
now deleted; it caused INVALID DATA FOR SM180RID message,
and "represents activity recorded by EPILOG that is not
obtained from RMF's SMF records. The RSCS subtype is not
documented further" according to Candle.
Thanks to Wayne Parrino, Avery Dennison, USA.
Change 10.078 Amdahl APAF product (Amdahl Processor Analysis Facility)
VMACAPAF creates a user SMF record describing MDF resource usage by
Jun 8, 1992 domain and LP within each domain that is now documented in
Appendix B, APAF Record Layouts of Amdahl's manual). The
preliminary variable names in MXG 9.9 were changed and now
the MXG variable names are based on the Amdahl documented
field names. Some previous fields are now reserved, and
storage variables are now in bytes, formatted by MGBYTES.
The number of LPs data kept is set in member IMACAPAF with
MXG %macro variable __NRLPS (yes, that's two underscores)
to only keep variables describing your environment, and
MXG defaults to keep four partitions (LP0-LP3) by setting
%LET __NRLPS=3;
Change 10.077 NPM reports caused DIVISION BY 0 because calculation of
ANALNPMR AVGOBYTE and AVGIBYTE were not protected for zero divide.
Jun 8, 1992 Now they are.
Thanks to Mike Jacques, Best Products, USA.
Change 10.076 Preliminary support for UNIX iostat and vmstat command's
XUNIX output data has been tested against ULTRIX data. The code
Jun 8, 1992 is temporarily located in the "X-rated" member XUNIX until
formal naming conventions for UNIX support have been
decided.
Thanks to Chuck Hopf, Primerica, USA.
Change 10.075 Support for North Ridge Software's "The Network Director"
EXNRS... SMF record creates thirteen NRS..... datasets that are
IMACNRS described in the vendor's Network Administrators Guide,
TYPENRS under the topic of "Event Recording", thanks for this
VMACNRS significant user contribution, which included test data
Jun 8, 1992 for validation!
Thanks to Tom Jones, Banks of Iowa Computer Services, USA.
Change 10.074 INVALID VALUE FOR DATEJUL FUNCTION occurs with TMS record
VMACTMS5 with create date of 91000 (found in volume that was shared
Jun 5, 1992 between MVS and TPF). Now, MXG validates the julian date
is valid before creating CREATIME.
Thanks to Chuck Hopf, Primerica, USA.
Change 10.073 Additional code added to avoid 213 or 314 ABENDS, caused
ASMVTOC primarily by VM DASD volumes shared with MVS, which do not
Jun 5, 1992 have a legitimate MVS VTOC. Now, these "bad" volumes are
bypassed and no longer cause ASMVTOC to ABEND.
Thanks to Wayne Beardsley, Citibank National Technology Div, USA.
Change 10.072 DB2 SQLCODE (SQL error code) can be negative, but MXG did
VMAC102 not know that, and thus SQLCODE was input as PIB4, causing
May 21, 1992 a return code of -204 to show up as 4,194,967,091! Change
both occurrences of SQLCODE PIB4. to SQLCODE IB4.
Thanks to Andrew Jeppeal, Marshalls, USA.
Change 10.071 VM/ESA dataset VXSYTCUP may contain only 49 observations
VMACVMXA if member TYPEVMXA is used to process MONWRITE output data
May 19, 1992 because of a misspelling. Change _DSYTCUP in line 010060
(inside the _PRNTALL macro definition) to _PSYTCUP. The
unintended invocation of _DSYTCPU (which deaccumulates the
VXSYTCUP dataset) inside _PRNTALL after OBS=50 was set in
TYPEVMXA caused the correctly built VXSYTCUP data set to
be re-built incorrectly with only 49 observations.
Thanks to Mark Kraut, Walgreens, USA.
Change 10.070 DCOLLECT value of 31Dec2155 expiration caused MXG to fail
VMACDCOL with an INVALID VALUE FOR FUNCTION DATEJUL message.
May 19, 1992 Change DATEJUL(CALEXPDT) to DATEJUL(ORGEXPDT) in 2 places.
In tests and calculation for DCDDATE1, DCDDATE3, UMCREDT,
UMLRFDT and UCCOLDT, remove -1900000 from both the IF test
and from inside the DATEJUL function. MXG converted dates
to yyddd format, which only supported years thru the next
millennium, but the SAS DATEJUL function supports date
yyyyddd formats beyond the year 2155 (the maximum year in
the present IBM calendar). In several labels, asterisks
were omitted and MACINE should have been MACHINE, and two
REBLK? variables are now spelled correctly.
Thanks to Chuck Hopf, Primerica, USA.
Change 10.069 SPMS Version 1.2.1.3 added a 4-byte field after SPMSRSV3
VMACSPMS causing errors. Pending documentation of the new field,
May 17, 1992 insert the following line after the @; after SPMSRVR3:
IF SPMSLEN3 GE 32 THEN INPUT +4 @;
(Note: In NL 22, SPMSRVR3 was misspelled as SMFPSRVR3).
Thanks to Pino Todesco, Western Australia Police, AUSTRALIA.
Change 10.068 Variable TAPE3490 (number of 3490 tape drives allocated)
IMACPDB is now added to PDB.STEPS (drives per step) and PDB.JOBS
May 17, 1992 (max drives in any step).
Thanks to Frank Vessell, ITT Consumer Financial Corporation, USA.
Change 10.067 TMON/CICS dataset MONITASK variable CREATIME was used in
ASUMCICS reports and summarization where STRTTIME should have been.
TYPEMONI Both variables were correctly described in the MXG
TYPEMON8 Supplement, but reports (See Change 10.066) and ASUMCICS
May 17, 1992 now use STRTTIME variable instead of CREATIME. Both are
still kept with equal values in MONITASK.
Change 10.066 TMON/CICS reporting with ANALMONI can loop, filling WORK
ANALMONI file, because STRTTIME from the interval dataset was used
May 17, 1992 where instead of STRTTIME from the MONITASK dataset. The
correction of CHANGE 10.067 corrects the problem. This
change provided a circumvention to ANALMONI that is now
no longer required after Change 10.067.
Thanks to Peter Paproota, BMI N.Y. Operations, USA.
Change 10.065 New dataset TYPE40_D can be created for each DD segment
IMAC40DD in type 40 SMF record. The old TYPE40 dataset creates 1
VMAC40 observation per SMF record, but there can be many devices
May 17, 1992 represented in a single dynamic deallocation event. MXG's
analysis of tape drive utilization (work in progress) will
need this new TYPE40_D dataset. New member IMAC40DD will
control whether observations are created in TYPE40_D; by
default, no observations are created, although comments in
IMAC40DD shows how to create only tape drive events.
Change 10.064 Variable CPURCTTM was invalid due to IBM APAR OY51878;
EXTY72 MXG 9.9 subtracted CPURCTTM from CPUTM in member EXTY72 to
May 15, 1992 prevent negative overhead values until IBM fixed their
error. Now, PTF UY77275 exists and does correct the CPU
value, so MXG has now eliminated the subtraction in this
Exit Member. If you install that PTF before MXG 10.1+, you
need to tailor member EXTY72 from MXG 9.9 into your USERID
and remove the subtraction, remembering to remove EXTY72
from your USERID.SOURCLIB when you install MXG 10.1+.
Change 10.063 Boole & Babbage IMF vars set from OPFLG1N2 & OPFLG3N4
VMACCIMS were not correct if multiple bits were on in these flags,
May 15, 1992 because MXG tested for the Hex value instead of the Bit
value. Variables RGNIOPT,BHTOON,DEPRECN,CPUNONE,CPUDEP,
BILLOVHD,TRNSYNC,BMPNO,DBIOWAIT, and DBIONONE could have
been affected. Change the hex test to bit test to fix.
Thanks to Mr. Steinkopf, Volksvagen Ag, GERMANY.
Change 10.062 Support for IBM CICS/ESA 3.3 type 110 subtype 2 Stats
CICINTRV records is added. IBM changes were incompatible and MXG
MECICALL 10.1 or later is required for CICS 3.3 statistics records.
PRCICALL MXG now no longer creates eleven statistic datasets whose
VMAC110 STIDs were eliminated by IBM in CICS 3.2.1 (they were all
May 14, 1992 summary records that were redundant with detail STIDs).
These datasets no longer exist and their Exit Members have
been deleted from the MXG Source Library:
STID Exit Member Dataset STID Exit Member Dataset
05 EXCICTST CICTST 53 EXCICCO2 CICCONST
26 EXCICLDT CICLDT 59 EXCICTC2 CICTCLT
35 EXCICTCT CICTCT 68 EXCICFCT CICFCT
38 EXCICLS2 CICLSRT 77 EXCICCO4 CICCONMT
41 EXCICLS4 CICLSRFT 82 EXCICBTA CICBTAM
44 EXCICDQT CICDQT
Because four of the above datasets had previously been
used in building the CICEODRV (shutdown statistics) and
CICINTRV (interval) datasets, member CICINTRV was changed
to summarize the detail data previously in CICDQT, CICFCT,
CICTCT, and CICTST. Additionally, exit members now exist
for the four datasets created by CICINTRV. The CICUSSRV
dataset can be large, since it represents every dynamic
resource, and you may wish to disable it in its exit.
Dataset Description Exit Member
CICEODRV - End-of-day "Shutdown" EXCICEOD
CICINTRV - Interval Statistics EXCICINT
CICREQRV - Requested Statistics EXCICREQ
CICUSSRV - Unsolicited (Dynamic) EXCICUSS
The order of the CICS statistics datasets was alphabetized
as were the labels for their variables, and member VMAC110
was renumbered. Fields added by IBM to several statistics
records are now supported.
Thanks to Joseph Rannazzisi, Brooklyn Union Gas, USA.
Change 10.061 Support for IBM CICS/ESA 3.3.0 type 110 subtype 1 monitor
VMAC110 record is added. Twelve new fields added to CICSTRAN are
VMAC110M very useful, describing program and user storage, but the
IMACEXCL fields were added incompatibly (they were inserted in the
May 14, 1992 middle, rather than added at the end of the record) and
thus MXG 10.1 or later IS REQUIRED for CICS 3.3 CICSTRAN.
Member VMAC110M processes ONLY the monitor (and not the
statistic) subtype, but it should be needed only by sites
still using SAS Version 5 under MVS/370 where virtual
storage constraints exist.
The following table lists the MXG variables in CICSTRAN
which capture transaction-level virtual storage usage:
Virtual Program User User User
Storage Storage Storage Storage Storage
Area HiWaterMk HiWaterMk Getmain Occupancy
Amount Amount Count Page-seconds
Above 16MB:
ECDSA PC31CHWM SC31CHWM SCGETCH SC31COCC
EUDSA PC31UHWM STORHWMH SCGETCNH PAGESECH
ERDSA PC31RHWM
Total Above PC31AHWM
Below 16MB:
CDSA PC24CHWM SC24CHWM SCCGETCT SC24COCC
UDSA PC24UHWM STORHWMK SCGETCN PAGESECS
Total Below PC24BHWM
Above and Below
Total PROGSTOR
Change 10.060 TMS inactive DSNBs are now deleted before merge with TMS
VMACTMS5 records, because their existence created invalid results.
May 13, 1992 A DSNB exists in TMS when multiple datasets are created on
a VOLSER, but when that VOLSER becomes scratch and it is
reused, its old DSNB is not removed from the TMC, and this
old DSNB was incorrectly matched with the VOLSER, creating
an observation in TMS.TMS with incorrect dataset name.
Statement IF DSNBACTV='Y'; was inserted after 012100.
Thanks to Gary Matney, Twentieth Century Investors, USA.
Change 10.059 Invalid CICS/ESA type 110 records caused STOPOVER ABEND.
VMAC110 one site; MCTSSDRN was 16 but there were only 15 segments
May 12, 1992 and MXG did not protect for this IBM error. Now, the test
IF SEGSTRT+MCTSSDRL GT LENGTH+1 THEN DO;
NBAD110+1;
IF NBAD110 LT 10 THEN PUT " INVALID RECORD DELETED "
// _N_= APPLID= MCTSSDCA= MCTSSDCL= MCTSSDRL= COL=
ICICS= ;
DELETE;
END;
was inserted after each statement SEGSTRT=COL; to detect
and delete these bad records, while IBM investigates.
Thanks to Tom Elbert, John Alden Life Insurance, USA.
Change 10.058 "Invalid Data for WKLCPURF" messages result with TMON/MVS
VMACTMVS because when IBM eliminated these EBCDIC fields, TMON/MVS
May 12, 1992 wrote hex nulls instead of EBCDIC values, causing the SAS
error condition. The MXG data set is not affected and
variables (WKLCPURF,WKLIOCRF,WKLMSORF) are set to missing
values. Inserting a ?? format modifier for each variable
eliminates the invalid data message and hex dump.
Thanks to Marcia Ketchersid, Price Waterhouse, USA.
Change 10.057 Support for NETSPY Release 4.2 added new dataset NSPYNPSI
EXNSPYNP describing X.25 multi-channel lines, X.25 MCH PUs and X.25
VMACNSPY virtual circuits with 50 variables; variable DLYVALUE was
May 5, 1992 added to NSPYNCP, variables NTRISUBT,NTRISBTE to NSPYTR,
and dataset NSPYLINE now captures resources for six new
elements (X.25 line, PU, LU, and SNA switched line, PU,
and LU). The NTRI entry was internally reformatted.
Change 10.056 Using EXPDB... members to add SMF record processing to
EXPDBCDE your PDB is documented in the MXG supplement (pp 137-140).
May 4, 1992 However, in many instances, you may only want certain of
the SMF record's subtype's datasets to be created. If the
MXG architecture supports "subtype-level-processing" for
this record (see comments in its VMAC.... member), it is
easy to add only specific subtypes to your BUILDPDB.
(It is MXG's intention to extend "s-l-p" architecture to
all SMF records with subtypes.)
The following example shows how you would add DB2 type 102
subtypes 63 and 106 to your BUILDPDB.
Member Would contain
EXPDBIND %INCLUDE SOURCLIB(VMAC102);
EXPDBVAR MACRO _VARUSER _V102063 _V102106 %
EXPDBCDE MACRO _CDEUSER _HDR102 _C102063 _C102106 _END102 %
EXPDBOUT PROC COPY MT=DATA INDD=WORK OUTDD=PDB;
SELECT T102S063 T102S106;
Thanks to Nancy Ayers, General Electric Lighting Business Group, USA.
Change 10.055 Date selection in DB2 reports PMSACC01/PMSACC02 produced
ANALDB2R no report because code was relocated incorrectly. In the
May 3, 1992 %MACRO PMACC01 and the %MACRO PMACC02 definitions, find
the invocation of %DB2RSELA (once in each of the above
macro definitions), and after each of these %DB2RSELA,
insert the following four lines:
IF NOT INTREND THEN DO;
MINTIME=QWACBSC;
MAXTIME=QWACESC;
END;
Thanks to Nancy Ayers, General Electric Lighting Business Group, USA.
Change 10.054 VTOC processing did not capture archaic ISAM index space,
VMXGVTOF warning "CRITICAL ERROR IN VTOF PROCESSING". The FMT2
VMXGVTOC DSCB, which describes the space occupied by ISAM indices
May 3, 1992 is now properly processed.
Thanks to Hr. Leineweber, HUELS AG, GERMANY.
Change 10.053 DB2ACCT dataset can now be written to a DDNAME of your
ANALDB2R choosing, and unnecessary SORTs which wasted WORK space
ASUMDB2A were eliminated. High volume transaction datasets should
BUILDPDB be written to tape (or a separate DASD file) and thereby
BUILDPD3 avoid B37 ABENDs and pollution of the daily PDB. MXG has
DIFFDB2 done this for CICSTRAN, and now that same philosphy has
EXDB2ACC been implemented for DB2ACCT as well. However, if you
IMACDB2 do nothing, the DB2ACCT data will still be written to your
READDB2 PDB, and the only incompatibility of this change is that
May 5, 1992 the DB2ACCT dataset is no longer sorted, which could cause
an error if you build a weekly DB2ACCT expecting it to be
sorted. (If so, simply remove the BY statement following
WEEK.DB2ACCT in your WEEKBLD/MONTHBLD member.)
Of greater impact, however, is the philosophy that now the
DB2ACCT dataset is a transaction file that may not be in
the daily PDB; what about daily/weekly reporting? Just as
CICS transactions are written to a transaction file and
are then summarized into the PDB.ASUMCICS by ASUMCICS, the
DB2ACCT dataset can now be summarized into PDB.ASUMDB2A by
new member ASUMDB2A, and the summarized PDB.ASUMDB2A can
be used for DB2 reports PMACC01 or PMACC02 in ANALDB2R.
a.IMACDB2 now defines MACRO _DB2ACCT PDB % (i.e., default is
PDB). Change that default value to DB2ACCT if you want to
write the DB2ACCT data to the DDname of DB2ACCT (and then
add a //DB2ACCT DD to your job).
b.VMACDB2 and EXDB2ACC now output to _DB2ACCT.DB2ACCT, and
IMACDB2 is included by VMACDB2.
c.DIFFDB2's unnecessary PROC SORT DATA=DB2ACCT was removed.
(This was the primary abuser of WORK space in BUILDPDB.)
d.The PROC SORT DATA=DB2ACCT OUT=PDB.DB2ACCT in BUILDPDB/3
was eliminated, since the DB2ACCT data set has already
been written to _DB2ACCT as the SMF data was processed.
And DB2ACCT was removed from the PROC DATASETS;DELETE list
e.If ANALDB2R or READDB2 is used to read SMF data, and if
PDBOUT= is specified to save the created datasets, the
DB2ACCT dataset will be sent to the DDname in IMACDB2,
while all other selected datasets are sent to PDBOUT=.
Thus if you do not change IMACDB2's default of PDB, and
you specify PDBOUT=PDB, then all datasets created by these
two members will be written to the PDB DDname. If instead
you change the IMACDB2 DDname, the DB2ACCT dataset will be
sent to the IMACDB2 destination.
Thanks to Nora Spencer, Toyota, USA.
Thanks to Bill Stoneberg, National-Oilwell, USA.
Thanks to Neil Ervin, Huntington Bank Service Company, USA.
Change 10.052 LPAR CPU utilization reports created by this rewritten
GRAFLPAR member can use PDB or TREND library PR/SM datasets
Apr 30, 1992 ASUM70PR or TRND70PR. Comments within the member show how
to select and generate desired reports.
Change 10.051 Invalid data for SMFPSRVR reading CICS/ESA dictionary
UTILCICS records, because UTILCICS was not updated at the same time
Apr 30, 1992 that VMAC110 was updated to support IBM's changed format
of SMFPSRVR. 2. The correction is to replace two lines
039200-039300 which now read:
INPUT @OFFPROD SMFPSRVR 2.
APPLID $CHAR8. /*SMFMNPRN*/
with these three lines:
INPUT @OFFPROD SMFPSRVR ?? 2. @;
IF SMFPSRVR=. THEN INPUT @OFFPROD SMFPSRVR PK2.1 @;
INPUT APPLID $CHAR8. /*SMFMNPRN*/
Thanks to Dave Gosse, Univesity of Iowa Hospitals, USA.
Change 10.050 Specifying a DDname other than PDB in IMACMONI caused the
ASUMDBDS ASUMDBDS member to fail with dataset not found error. This
TRNDDBDS change also renames the dataset created by ASUMDBDS to be
Apr 30, 1992 named ASUMDBDS and thereby be consistent with MXG ASUMs.
Finally, TRNDDBDS was added for trending ASUMDBDS output.
Change 10.049 Graphic reports were not perfect. Charts were not printed
GRAFTRND if there were fewer than 40 intervals, the interval was
Apr 28, 1992 not always calculated correctly, and forecast line could
be skewed because the last-actual-value rather than the
last-predicted-value was used. If STAT=NO was specified
or specified in the wrong case, Axes statements were lost.
Workload bar chart axes values for projections were wrong.
All these glitches have been repaired.
Thanks to Van Xydis, VM System Center, USA.
Thanks to Norbert Korsche, OMV-AG, AUSTRIA.
Change 10.048 Support for AICorp's KBMS (Knowledge Based Management
EXAICOST System) user SMF record is added by this change, which
IMACAICO creates the AICOSTAT dataset with CPU time, EXCP count and
TYPEAICO elapsed time for each "transaction".
VMACAICO
Apr 30, 1992
Thanks to Kelly Raven, CSX Technology, USA.
Change 10.047 DB2 reporting for DBID and OBID did not print the actual
ANALDB2R name of the object. MXG built formats dynamically to map
Apr 30, 1992 these objects, but failed to use the format in the report
PUT statements. Many lines were altered in this change.
This change also added processing of the T102S183 dataset
to the SQL reports.
Thanks to Carl Koch, AT&T Westminster, USA.
Change 10.046 DB2 reporting LIBRARY SMF IS NOT VALID message occurs if
ANALDB2R PMSQL04 or TRANSIT reports are requested with PDB=SMF.
Apr 29, 1992 Insert after 009060 OR &PMSQL04=YES
and replace line 186700 (currently _ALLPAIR;)
with %ANALDBTR(PDB=&PDB1,PAIRS=ALL);
Thanks to Carl Koch, AT&T Westminster. USA.
Change 10.045 Using READDB2 with TRACECLS= parameter to select desired
READDB2 IFCIDs by trace class does not select all IFCIDs in all of
Apr 29, 1992 the classes you ask for (however, the IFCID= parameter can
be used to list the desired values, and it has no error).
READDB2 itself does not fail, but creates zero observation
datasets for some trace classes, which can cause ANALDB2R
to fail if it is invoked after the READDB2 invocation.
Correct this error by moving the %INCLUDE statement in
line 026400 to immediately after 007400.
Thanks to Carl Koch, AT&T Westminster. USA.
Change 10.044 The calculation of TAPEFEET from TMS data should include
TYPETMS5 test for RECFM='VS ' in line 005200 of TYPETMS5 and in
VMACTMS5 line 037300 of VMACTMS5.
Apr 28, 1992
Thanks to Norbert Korsche, OMV-AG, AUSTRIA.
Change 10.043 Two RECFM codes, FS and VS, were not decoded by VMACRCFM.
VMACRCFM After line 002100 insert:
Apr 28, 1992 ELSE IF RECFMT='1000100.'B THEN RECFM='FS ':
and after line 003200 insert:
ELSE IF RECFMT='0199100.'B THEN RECFM='VS ':
Thanks to Norbert Korsche, OMV-AG, AUSTRIA.
Change 10.042 The percentage of time when there are more Ready tasks in
VMAC7072 memory than there are Processor Engines is a much better
XMAC7072 indicator of CPU "stress", especially in LPARs, because it
Apr 27, 1992 directly measures when tasks are waiting for CPU dispatch.
MXG now creates variable PCTRDYWT in dataset TYPE70:
IF NRCPUS=1 THEN PCTRDYWT=SUM(OF READY02-READY15);
ELSE IF NRCPUS=2 THEN PCTRDYWT=SUM(OF READY03-READY15);
ELSE IF NRCPUS=3 THEN PCTRDYWT=SUM(OF READY04-READY15);
(repeated for NRCPUS up to 8), and is labeled
PCTRDYWT='PERCENT WHEN*READY TASKS*ARE WAITING'.
The only weakness of PCTRDYWT is that it does not identify
WHICH ready tasks are waiting, and with a well-designed
SRM you would typically have your lesser important tasks
Ready and waiting for CPU dispatch while your online tasks
are getting what they need.
Change 10.041 Line 398700 should be STID=77 instead of STID-77, and MXG
VMAC110 did not create observations in CICCONMT statistic dataset.
Apr 27, 1992 Fortunately for me, the STID=77 is the "total" record for
the "interval" STID=76 which was output in CICCONMR, and
thus no data was lost. IBM no longer creates any "total"
records starting with CICS/ESA 3.3, so all of the CICS
statistics datasets which end with "T" will have zero
observations in the future. Total records were redundant
with the interval data.
Thanks to Caron Knox, Willis Corroon Group, ENGLAND.
Change 10.040 Type 39 SMF record caused INPUT STATEMENT EXCEEDED with
VMAC39 subtype=5. Change all occurrences of NE 0 to GT 0
Apr 22, 1992 (a missing value unintendedly satisfied the NE 0 test).
Thanks to Miller Dixon, Continuum, USA.
Change 10.039 The NET-PASS variable NETPACTM was the total response
VMACNETP for NETPTRNS transactions, but it should have been the
Apr 22, 1992 average response time. Insert after 010200 this line:
IF NETPTRNS GT 0 THEN NETPACTM=NETPACTM/NETPTRNS;
Thanks to Nancy Ayers, General Electric Lighting, USA.
Change 10.038 Candle Omegamon for CICS V550 erroneously stored nulls in
VMAC110 the packed decimal field SMFPSRSN, causing MXG to print a
Apr 22, 1992 hex dump of the SMF record. Candle incident 201387 fixes
their error, but MXG circumvents the unwanted hex dump
by adding ?? to the input statement so it now reads:
SMFPSRSN ?? PD4.
Change 10.037 JES2 Spool Offload type 24 SMF record can cause STOPOVER
VMAC24 ABEND because tests for OFFESS and NRESS in line 016100
Apr 21, 1992 must be GT 0 instead of NE 0. (Missing values satisfy the
NE 0 test but not the GT 0 test.)
Thanks to David Ehresman, University of Louisville, USA.
Change 10.036 VM/ESA 1.1.1 is now supported, creating 3 new datasets
FORMATS and adding new variables to existing datasets:
VMACVMXA a.Variables added to existing MXG datasets:
Apr 20, 1992 VXSYTSHS - variables CALNUMSA and RSACTSHR.
VXMTRSYS - flag variable SYSMASFI.
VXMTRPRT - PCCCSU and PFXCFO.
VXSTOSHR - ASCCSPGR,SPGW,SPXR,SXWT,ASCSMIGC,VMDCTLKP and
VMDCTNPS. IBM renamed VMDCTPST to ASCCSPST,
but MXG continues to call it by its original
name, and did not create a redundant variable.
VXBYUSR - VMDASMCT,BLKCT,MDCIA,OPCTN (from VXUSEACT).
VXIODDEV - VIUTIM/CNT for IN,LV, and OT, and RDEVMCIA.
VXIODCAD - CALDATA ($CHAR160) replaced CALPSF ($CHAR96).
b.New data sets VXSTOASI (Interval Shared Address Space
paging activity), VXSTOASC (Address Space Create Event),
and VXSTOASD (Address Space Delete Event) were added.
c.New format MGBYTRT expresses byte rate in B/SEC, KB/SEC,
MB/SEC printed units, similar to MGBYTES for byte values,
and is used for several new storage movement variables.
d.These changes have been tested with HCPCPEID=1101 release.
Change 10.035 TMS variables EDMTAP and DYNAM were incorrect. The bit
VMACTMS5 test should be the '20'X bit for EDMTAP (instead of '40'X)
Apr 20, 1992 and the '10'X bit for DYNAM (instead of '20'X).
Thanks to Ruth Whitney Parker, Citibank South Dakota, USA.
Change 10.034 If you added a SORTBY= operand for DB2 Reports the report
ANALDB2R did not break where you expected; only the first variable
Apr 16, 1992 in your SORTBY= list was used. Lines 006250 and 006260
both now start with %ELSE %IF LENGTH( .... Both must be
changed to start with only %IF LENGTH( ....
Reports requested without SORTBY= had no error.
Thanks to Georg Simon, Federal Reserve Bank of Philadelphia, USA.
Change 10.033 Support for the Software Ag "Natural Process" SMF record
EXNATPAC is added by this change. Dataset NATPACCT contains one
IMACNATP observation for every SMF record, written at user logoff
TYPENATP (including a termination of Natural Process before the
VMACNATP user can logoff), with the Natural Process 8-byte user id,
Apr 15, 1992 the CPU time and I/O count of that session.
Thanks to Joanne Turpie, Department of Labour, Wellinton, NZ
Thanks to Terry Proops, Department of Labour, Wellington, NZ
Change 10.032 Two references to DATA=SMF should have been DATA=LLAEXIT
ANALLLA in this analysis example.
Apr 15, 1992
Thanks to Hanno Bresch, SAS Institute, GERMANY.
Change 10.031 New variables ACTDLYTM/RESDLYTM/DSPDLYTM are now created
VMAC30 in TYPE30_4, TYPE30_V, PDB.STEPS and PDB.JOBS datasets.
IMACPDB These delta times are described on pages 44-45 of the MXG
Apr 15, 1992 Guide, but were not kept as unique MXG variables until a
CPE class student went home and observed confusing values,
because pages 44-45 were not completely accurate. After
further research (and clarification from Bernie Pierce of
IBM) they now clearly deserve their own variables.
ACTDLYTM='Delay duration*executing*not active'
(EXECTM-ACTIVETM)
This delta includes time the address space was
Detected Wait or Long Wait swapped out by SRM,
(which includes TSO user's think time).
RESDLYTM='Delay duration*active*not resident'
(ACTIVETM-RESIDTM)
This delta is the time SRM wanted the ASID to
be in the Multi-Programming Set, but was unable
to get the ASID resident. This includes all
swapped out time (except DW/LW, which is caught
in ACTDLYTM) plus the time to actually do the
swap in. Another name might be MPL Delay time,
because all of the swap out and non-resident
time while active is the time when the Target
MPL was not high enough to include this task.
This delta divided by SWAPS is an estimate of
the time-to-swap-in a task, but since SWAPS
counts both RESDLYTM and ACTDLYTM swap events,
and since RESDLYTM includes the time to swap in
and the time waiting to swapin and the time
swapped out, the estimate is usually poor!
DSPDLYTM='Delay duration*resident*not dispatched'
(RESIDTM-CPUTCB+SRB+HPT+RCT+IPT)
This delta is the time the task was resident
in memory but was not executing instructions.
It includes delay for CPU dispatch (when you
enter the MPL set you don't immediately get
CPU - a hot CICS transaction may still have the
processor), delay for I/O (you execute a few
CPU instructions and then issue an I/O and you
wait for IOS to get the data for you), delay
due to page faults (the next page is not
in memory and you wait for that page to be
brought in), and delay due to tape mounts.
NOTE: PRIOR TO AUG, 1994, THIS CHANGE TEXT SAID THAT TAPE MOUNT
DELAY WAS INCLUDED IN ACTDLYTM, BUT THAT WAS IN ERROR. DELAY FOR
TAPE MOUNTING HAS ALWAYS BEEN INCLUDED IN DSPDLYTM. SEE THE NEW
SCHEMATICS IN MEMBER ADOC30 AND SEE CHANGE 12.142.
Schematic step duration example (numbers from a day's TSO session):
ELAPSTM
|-----------------------------------------------------------------|
| |
INITTIME ALOCTIME LOADTIME ENDTIME
|---------|---------|---------------------------------------------|
DSENQTM ALOCTM / EXECTM |
/ |
/ |
/ |
/ |
/ |
/ EXECTM |
/ 14:29:37.42 |
|------------------------------------------------------|
| |
| ACTDLYTM ACTIVETM |
| 14:16:57.90 759.52 |
|--------------|---------------------------------------|
| |
| RESDLYTM RESIDTM |
| 04.22 755.30 |
|------------|--------------------------|
Session TGETS=1275 | |
TSO/MON TRANS=1276 |DSPDLYTM CPUTM|
| 654.13 101.17|
|--------------|-----------|
Thanks to Steve Donahue, Blue Cross and Blue Shield of Texas, USA.
Change 10.030 JCLTEST6 gets INVALID DATA FOR SMFTIME when a VSAM SMF
JCLTEST6 file is used for step SMFSMALL, because of SAS 6.07 Error
Apr 15, 1992 V6-SYS.DATA-3550, which affects only the creation of BSAM
files from VSAM input. There is no error in creation of
SAS datasets from VSAM input.
The error only occurs if the INFILE SMF START=BEGINCPY
parameter has BEGINCPY not equal to one. To create a
BSAM file of SMF records from a VSAM file, MXG has to
set BEGINCPY=5 (to start the copy in byte 5 of the
VSAM record, and thereby skip over the unwanted first
four bytes containing RDW/SDW of the VSAM record).
This is done in MACRO _SMF defined in member VMACSMF.
This error has been fixed by SAS ZAP MV313550. Only the
members JCLTEST6/JCLTEST use START=BEGINCPY logic, and
only in step SMFSMALL; either install the SAS ZAP or use
a non-VSAM file for the SMF ddname in step SMFSMALL.
Thanks to Dan Squillace, SAS Institute Cary, USA.
Change 10.029 Cosmetic. Variable QWACARNW in VMAC102 had no asterisks
VMACNSPY in its label. Added asterisks as in variable QWACARNR.
Apr 15, 1992
Change 10.028 Variable SESSMGR was misspelled once as SESSGMR, causing
VMACNSPY it to never have value "Y".
Apr 10, 1992
Thanks to Lindsay Oxenham, State Electricity Commission of Victoria.
Change 10.027 Comments only were changed. The reference to _CICEXCL in
IMACCICS comments do not apply to IMACICS; the Exclude Logic macro
Apr 10, 1992 _CICEXCL is defined/described in member IMACEXCL.
Thanks to Don Sively, E-Systems, USA.
Change 10.026 Dataset TYPE0203 was not deleted from the WORK file after
BUILDPDB PDB.TYPE0203 had been built. MXG "housecleans" the WORK
BUILDPD3 library in BUILDPDB to minimize the amount of workspace
Apr 9, 1992 required. TYPE0203 had been overlooked when added.
Thanks to Tracy Blackstone, Kaiser Foundation Health Plan, Inc, USA.
Change 10.025 SMF type 41 DIV (Data In Virtual) Access/Unaccess records
VMAC41 variables ACCSTIME and UACCTIME are timestamps and not the
Apr 9, 1992 durations implied by the SMF manual. Hex value 'A57F3640'
expanded to 8 bytes was 05APR92:08:50:33 in a record with
SMFTIME=05APR92:09:09:00 in a TYPE41AC observation after
this change. (That large delta of 19 minutes confuses me;
if you use this record, what's your data show?). Change
ACCSTIME PIB4.2 to ACCSCHAR $CHAR4.
UACCTIME PIB4.2 to UACCCHAR $CHAR4.
and insert after the appropriate @; one of the following:
ACCSTIME=INPUT((ACCSCHAR||'00000000'X),TODSTAMP8.);
UACCTIME=INPUT((UACCCHAR||'00000000'X),TODSTAMP8.);
and give both variables format DATETIME21.2 and LENGTH 8.
IBM APAR OY19780 is the Documentation Error acknowledging
these fields to contain the first 4 bytes of TODSTAMP.
Thanks to Terry Poole, SAS Institute Cary, USA.
Thanks to Richard Bear, Gulf States Toyota, USA.
Change 10.024 MVS Accounting fields (+ additional DB2 accounting data)
FORMATS were added to DB2ACCT and some trace records by IBM in a
VMACDB2 revision included in DB2 2.3 release, but documentation
VMAC102 did not arrive in time for MXG 9.9. Additionally, format
Apr 9, 1992 values for PACKADM were added to the IFCID 140/141 data.
This enhancement uses your site's tailoring in IMACACCT
to set the length of the ACCOUNTn variables that are kept.
These new accounting variables are added to DB2ACCT:
Variable Type Length Format Label
ACCOUNT1 CHAR ?? FIRST JOB*ACCOUNT*FIELD
ACCOUNT2 CHAR ?? SECOND JOB*ACCOUNT*FIELD
ACCOUNT3 CHAR ?? THIRD JOB*ACCOUNT*FIELD
QMDAASLN NUM 4 BYTES USED IN QMDAAINF
QMDAAUTH CHAR 8 DB2 AUTHID
QMDACNAM CHAR 8 DB2 CONNECTION*NAME
QMDACORR CHAR 12 DB2 CORRELATION*ID
QMDACTYP CHAR 8 DB2 CONNECTION*TYPE
QMDALOCN CHAR 16 DB2 LOCATION NAME
QMDALUNM CHAR 8 SNA*LU*NAME
QMDANETN CHAR 8 SNA*NETID
QMDAPLAN CHAR 8 DB2 PLAN
QMDAPMOD CHAR 1 PRODUCT*MODIFICATION*LEVEL
QMDAPREL CHAR 2 PRODUCT*RELEASE
QMDAPTYP CHAR 10 $MGDB2PN. PRODUCT*NAME
QMDAPVER CHAR 2 PRODUCT*VERSION
IBM's DB2 group reformatted the standard MVS account data!
Instead of sensibly copying the existing, well-known, and
already-decoded MVS accounting string (which contains a
length-field preceding each account-field), the DB2 group
decided to eliminate the length fields and instead insert
an 'FF'x byte as a delimiter between account fields! This
unnecessary inconsistency by DB2 required a new algorithm
(and of course any new algorithm is an exposure to error)
that required 120 lines of SAS code plus time to test!
Consistency would have been cheaper and lots safer!
Change 10.023 The SAS 5.18 Circumvention for the 344 Compiler Error in
XMAC7072 member XMAC7072 will cause UNINITIALIZED VARIABLE messages
Apr 8, 1992 because the final version of VMAC7072 was not edited into
XMAC7072. Copy in VMAC7072 into XMAC7072, replace all 410
lines in the DO group following 'NOT MVSXA' with this
single line : IF SUPATRN=' ' THEN SUPATRN=' ';
to create the corrected XMAC7072 member.
Thanks to Ken Thomas, Maryland Casualty Company, USA.
Change 10.022 Support for ROSCOE Release 5.7 changes to SMF Records.
EXROSPRN SMF record creates two new subtypes and MXG creates a new
EXROSSTA dataset for each: ROSCOPRN - ROSCOE Printing Services,
FORMATS subtype '80'x, and ROSCOSTA - Roscoe Statistics, subtype
VMACROSC '34'x. Both new ROSCOE datasets appear to have useful
Apr 8, 1992 new information about your ROSCOE subsystem, and its PRINT
activity. This change added about 250 lines.
Thanks to Dave Thorn, Dow Jones & Company, USA.
Change 10.021 New NPMHP, NPMMP, and NPMLP variables for Hi/Lo/Med Prty
TYPE28 bytes sent/received were not all kept, and some had "Sent"
Apr 7, 1992 in their label instead of "Received".
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 10.020 Landmark CICS records may produce ERROR. INVALID OFFSETS
TYPEMON8 message with LENGTH=0 in the message. The first two bytes
TYPEMONI of the Landmark record contain zero, instead of the actual
Apr 6, 1992 record length. (When/Why Landmark made the change is not
known). Change member TYPEMON8: Change "LENGTH" in lines
064700 and 064900 to "LENMONI" so that the field in these
two bytes no longer overrides the LENGTH=LENGTH value that
is captured in the INFILE statement. Archaic TYPEMONI for
Landmark Version 7 was similarly changed for consistency.
Thanks to David Bane, Jefferson County (Colo) Public Schools, USA.
Thanks to Chun-Heng Liu, Bellcore, USA.
Change 10.019 Cosmetic cleanups. Hex dumps produced when MXG finds data
VMAC110 invalid in type 110 records are now only printed for the
VMACSMF first two records. MXG notes of bad records are still put
Mar 27, 1992 on the log for the first 20 occurrences of a bad record.
Apr 20, 1992 Back-to-back type 02 or 03 (dump header/trailer) records
were not expected by VMACSMF's new messages, and the time
of the FIRST RECORD IN GROUP message was not correct.
(I wondered why SMFDUMP output would begin with a pair
of type 02 records, and with the first record's timestamp
several hours later than the second record, but realized
the output was first dumped by SMFDUMP and was then later
copied by SMFDUMP which added the 02 at the beginning and
the 03 at the end of the copy too!).
Change 10.018 Very obscure problem. DASD VTOCs with datasets defined to
VMXGVTOC have a "Standard User Label" (DSORG=PS-SUL) cause an MXG
VMXGVTOF note CRITICAL ERROR IN VTOC PROCESSING, EXTENTS NOT FOUND.
Mar 27, 1992 PS-SUL datasets have NREXTNTS=1 in their DSCB1, but two
extents are contained in DSCB1: extent #0 with EXTYPE=40x
for the one track Standard User Label, and extent #1 with
the real file. MXG now captures this extra track/extent
and includes it in TRKSALOC and TRKSUSED (note, however,
ISPF and LISTVTOC do not properly count this SUL track).
The change is in the FMTID='1' logic in members VMXGVTOF
and VMXGVTOC. The changes to VMXGVTOF are:
a) Move lines 042900 and 043000 (OUTPUT VTOC1/DSNAMES)
to after 044400.
b) Delete line 044000 (IF FIRST EQ 0 THEN DELETE).
c) Change line 044300 (OUTPUT EXTENT;) to now read
IF FIRST GT 0 THEN OUTPUT EXTENT;
d) Insert four lines after 044300 reading:
IF EXTYPE EQ 40X THEN DO; /*STANDARD USER LABEL*/
NREXTNTS=NREXTNTS+1;
TRKSUSED=TRKSUSED+1;
END;
The same changes need to be made to VMXGVTOC. Line numbers
are: a) 055700 and 055800 to after 057200, b) 056800,
c) 057100, and d) after 057100.
The only PS-SUL datasets found thus far are the log files
created by Omegamon/CICS Version 500!
Thanks to Mike Jacques, Best Products, USA.
Change 10.017 Invalid CICS/ESA Type 110 Subtype 2 Stats records can
VMAC110 cause MXG to loop. MXG detects the bad record and PUTs a
Mar 25, 1992 note on the log "UNEXPECTED STATISTICS SUBTYPE", but MXG's
attempt to skip over an unexpected segment fails when the
segment is corrupted (i.e., it has STILEN=0). Line numbers
408200 and 408300 currently read:
IF (COL+SKIP LE LENGTH+1) THEN INPUT +SKIP @;
ELSE INPUT;
but they must be changed to read:
IF (COL+SKIP LE LENGTH+1) AND SKIP GT 0 THEN INPUT +SKIP @;
ELSE DELETE;
The cause of the single occurrence of this type of
corrupted record is still under investigation.
Thanks to Jim Gilbert, Texas Utilities, USA.
Change 10.016 Documentation note for TYPE6 (and PDB.PRINT) datasets.
ADOC6 The fields SMF6DDNM, SMF6DSNM, SMF6PRNM and SMF6STNM that
Mar 25, 1992 were added by PSF to type 6 SMF records do NOT exist in a
type 6 record created by JES. Those fields exist only in
the PDDB built by PSF and are not in the JOE built by JES.
The variables exist, but their values are blank for DDname
DSname, Procname and Stepname if JES did the printing.
IBM APAR OY48265 documents their omission by JES.
Thanks to Marcia Ketchersid, Price Waterhouse, USA.
Change 10.015 Support for NETSPY Token-Ring records create the new MXG
EXNSPYTR MXG dataset NSPYTR, thanks for this significant user
VMACNSPY contribution.
Mar 25, 1992
Thanks to Lois Robinson, M & I Data Services, Inc, USA.
Change 10.014 The four new swap events (SWAPIC, SWAPIP, SWAPMR, SWAPAW)
VMAC71 always had missing values because the test in line 084500
Mar 25, 1992 IF LENSWAP GE 360 THEN DO; must be changed to read
IF NRSWAPSG GE 15 THEN DO;
Additionally, variables SWAPSHRT (logical swap candidates)
SWAPLGPY (logical swaps actually swapped) and PCTLSWAP
(pct logical swaps that swapped) used to be MVS/370 only,
but are now calculated for XA and ESA environments by the
addition of these three lines after line 091400:
SWAPSHRT=SWAP-SUM(PHYEXT,PHYAUX);
SWAPLGPY=SUM(LOGEXT,LOGAUX);
IF SWAPSHRT GT 0 THEN PCTLSWAP=100*SWAPLGPY/SWAPSHRT;
Thanks to Lois Robinson, M & I Data Services, Inc, USA.
Change 10.013 STOPX37 Product's SMF Record for Release 3.4 is supported
VMACX37 by changing EQ 'X37 33' THEN to GE 'X37 33' THEN
Mar 24, 1992 because the record format was (apparently) unchanged. The
variable STEPCPU must be changed to STPCPUTM in two places
so the CPU time will be kept by MXG.
Thanks to Mike Jacques, Best Products Co., Inc, USA.
Change 10.012 MVS/ESA V4.2 Dynamic I/O Reconfiguration is now supported
ASMTMNT in these "monitor" programs provided by MXG. The MXG Tape
ASMVTOC Mount Monitor, ASMTMNT, the MXG Fast VTOC Reader, ASMVTOC,
ASMVVDS the MXG VVDS Reader, ASMVVDS, and the MXG SAS Function to
FMXGUCBL Dynamically Allocate All Disks, FMXGUCBL (now redundant in
Mar 13, 1992 purpose with the ASMVTOC program), all use the new UCBSCAN
service so these programs will recognize new devices that
were added by MVS/ESA after IPL.
Thanks to Bill Fairchild, Royal Software Associates, USA.
for enhancement.
Thanks to Guy Garon, Verstand, CANADA.
for review of Bills' work
Change 10.011 SPMS 1.2.1.3 writes invalid record if a volume is deleted
VMACSPMS or renamed, without first changing SPMS parameters. The
Mar 13, 1992 resultant SMF record contains a value of 1 for SPMSREXT,
but sections 3/4 do not exist in the record, causing MXG
to STOPOVER abend. This is really an Amdahl problem, but
this circumvention protects their error. Change
DO _I_=1 TO SPMSREXT; to read
IF LENGTH GT 188 THEN DO _I_=1 TO SPMSREXT;
(Note: NL 22 misspelled 1.2.1.3 as R2.1.4).
Thanks to Peter Evans, Inland Revenue, Worthing, ENGLAND.
Change 10.010 TYPE70PR variable NRPRCS, number of logical partitions
VMAC7072 is still incorrect after the PR/SM Effective Dispatch Time
Mar 12, 1992 APAR is installed. Change 9.179 subtracted one for the
pseudo partition "PHYSICAL", but since that partition
segment is last in the actual record (even though it has
the Logical Partition Number LPARNUM of 0), only the
observations in TYPE70PR for LPARNAME of PHYSICAL have the
correct number of logical partitions! Line 131110,
IF LPARNAME='PHYSICAL' THEN NRPRCS=NRPRCS-1;
must be deleted, and a new line must be inserted after
line 133220 (SKIP=SKIP-16;, inside the DO group to read
LCPUEDTM) containing:
NRPRCS=NRPRCSS-1;
(yes, the variable on the right does have an extra 'S').
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 10.009 Datasets TYPE70PR, DB2STAT0 and DB2STAT1 were added to
WEEKBLD BUILDPDB/3 in MXG 9.9, but were not added to WEEKBLD or
MONTHBLD MONTHBLD. Now they have been added, with these BYs:
Mar 10, 1992 WEEK.TYPE70PR:
BY SYSTEM STARTIME LPARNUM LCPUADDR;
WEEK.DB2STAT0:
BY SYSTEM QWHSSSID QWHSSTCK;
WEEK.DB2STAT1:
BY SYSTEM QWHSSSID QWHSSTCK;
But what about DB2ACCT; wasn't it added to BUILDPDB? Yes,
but, since Change 10.053 now gives you the choice of the
destination of the DB2ACCT dataset, and since I don't know
if you really want to put your detail DB2ACCT data in the
weekly PDB, I can't automatically add it to your weekly
PDB for you; you'll have to do that yourself, (with no BY
statement, since it is no longer sorted), if you really
want detail DB2ACCT data weekly!
Change 10.008 Sites that had added DB2ACCT to their PDB under MXG 8.8
WEEKBLD may get a NOT SORTED condition in WEEKBLD under MXG 9.9,
Mar 10, 1992 because your previous sort order might be different than
Apr 20, 1992 the sort order used by MXG 9.9. Simply remove the BY
May 5, 1992 statement from your WEEKBLD and the daily datasets will be
concatenated instead of interleaved in sort order.
This is not only a circumvention to this specific problem,
but in fact is the way of the future, as DB2ACCT is no
longer built in sort order; see Change 10.053!
Change 10.007 Variable TPXELAP has wrong value. Line 052200, which is:
VMACTPX TPXELAP=TPXELAP*900/40812;
Feb 27, 1992 must be deleted. The value is correct without conversion.
Thanks to Sam Sheinfeld, Kraft General Foods, USA.
Change 10.006 Cosmetic change. Variable SMFT0BST should have format of
VMACCMA DATETIME21.2 and should have LENGTH of 8.
Feb 27, 1992
Thanks to Ken French, Wisconsin Gas, USA.
Change 10.005 Type 42 SMF record causes STOPOVER ABEND. One ABEND is
VMAC42 because APARs OY48288 and OY39393 incompatibly re-format
Mar 9, 1992 the record, and require a new VMAC42 member to process the
Mar 14, 1992 completely restructured record. However, MXG could also
fail on records created before the above APAR, because the
NRSTOR in line 020300 should have been (NRSTOR-1). Since
the original records were not correct, the only thing that
makes sense, if you want to process the type 42 record,
(it contains 3990 cache statistics if you have SMS volumes
behind the cache) is to install the above APARs and to ask
for MXG PreRelease 10.1, because these two APARs correct
the errors previously reported (but not fixed) in APAR
OY36035 and OY39393. MXG circumvention for those two
earlier APARs was removed in this almost complete rewrite
of VMAC42. However, users with IBM's Cache RMF Reporter
or Legent's DASDMON/ASTEX products have said they found
TYPE42 added nothing useful to those two products.
Revision 1MAR94: New subtypes of the type 42 record added
great value to the type 42 record! See later changes!
Thanks to Greg Scriba, Budget Rent-A-Car Corp, USA.
Thanks to Glenn Hanna, Textron Defense Systems, USA.
Change 10.004 The value of offset P3 had previously been hardcoded to a
VMXGHSM value of 297 or 405 depending on the release of HSM, but
Mar 9, 1992 it now can be calculated independent of release. In lines
152300 and 153000, replace "405" with "MCDNVSNO+65".
Additionally, MCDMCNAM in lines 140500 (label=SMS...) and
141600 (... $HEX2.) should have been MCDSMSFG. Without
this change, MCDMCNAM printed funny because it was given
the $HEX2. format.
Thanks to Roger Edwards, South Carolina Electric & Gas Company, USA.
Change 10.003 PSF type 6 records had FORM truncated to four bytes. The
VMAC6 original PSF record did not contain the 8-byte FORM name,
Mar 9, 1992 and old MXG code that bypassed inputting the 8-byte field
should have been removed when PSF added the longer field.
Lines 026000 thru 026300 need to be replaced with:
IF SMF6LN3 GE 14 AND LENGTH-COL+1 GE 8 THEN
INPUT FORM $CHAR8. @;
since the 8-byte form name is now in all type 6 records.
Thanks to Lars Hylin, TryggHansa-SPP, SWEDEN.
Change 10.002 Line 184600 changed to _IMSTRAN.IMSTRAN instead of
TYPEIMS IMSTRAN._IMSTRAN, but using MXG's suggested DDNAME of
Mar 9, 1992 IMSTRAN for the _IMSTRAN value caused no error condition!
Only if you used a different DDNAME did an error occur.
Thanks to Richard S. Ralston, Rochester Telephone, USA.
Change 10.001 DB2 Reports truncated values for eight character values,
ANALDB2R and the System Parameter Report ABENDs with "Variable Not
Mar 9, 1992 Found" due to inadequate testing of the final 9.9 code.
a.Insert the following line in two places, after line 016050
and after line 025220:
LENGTH DB2 AUTHID PLAN CONNID CORRNAME CORRNUM
DB2LOCAL DB2REMOT $ 8 ;
b.Replace all occurrences of SM102SSI with QWHSSSID. These
are the lines: 088580, 088620, 093840, 095140, 096260.
LASTCHANGE: Version 10