COPYRIGHT (C) 1984-2007 MERRILL CONSULTANTS DALLAS TEXAS USA
CHANGE 09.09
=========================member=CHANGE09================================
/* COPYRIGHT (C) 1984,1992 MERRILL CONSULTANTS DALLAS TEXAS USA */
This is the Production Version MXG 9.9, dated March 1, 1992.
All Changes listed in this member have been installed in MXG 9.9.
HOT NOTES:
Several new changes were added after NEWSLETTER TWENTY-ONE went to
press; see the Change Log, below, for Changes 9.236 thru 9.245.
The library now has more members, lines, datasets and variables than
was stated in the newsletter. This final MXG 9.9 library contains
1,605 members, 388,651 lines of code, builds 1,093 datasets with
41,332 variables documented in DOCVER with delta-doc in DOCVER09.
Over 800 sites have installed a PreRelease of MXG Version 9!
The installation instructions for MXG 9.9 were contained in NEWSLETTER
TWENTY-ONE, which is contained in member NEWSLTRS, repeated also
below in this member.
I. MXG Version Status.
1. Production Version is now MXG 9.9, dated March 1, 1992.
MXG Version 9.9 was accompanied by Newsletter TWENTY-ONE.
All Changes in this newsletter have been installed in MXG 9.9.
The MXG 9.9 library contains 1,605 members, 388,651 lines of code,
and builds 1,093 datasets with 41,332 variables that are documented
in member DOCVER. Datasets changed between MXG 8.8 and MXG 9.9
are documented in member DOCVER09.
2. Major enhancements and new products supported in MXG 9.9.
Support for SAS 6.07 (new options).
Support for Amdahl's SPMS Release 1.2 SMF record.
Support for Boole & Babbage CONTROL-D SMF record.
Support for CA-1 (TMS) Release 5 complete rewrite.
Support for CADAM's Statistics Data File.
Support for CICS/ESA 3.2.1 product.
Support for Codework Software's SNAPAD-MVS user SMF record.
Support for Database 2 Release 2.3.
Support for DCOLLECT APAR OY36364 change in track capacity.
Support for Fischer's Totally Automated Office TAO.
Support for HSM 2.6 SMF record.
Support for Interlink's SNS/SNA Gateway SMF record.
Support for Interlink's SNS/TCPaccess SMF record.
Support for Interlink's SNS/TCPvt SMF record.
Support for LEGENT's MIM Multi-Image Manager
Support for LEGENT's LANSPY component of NETSPY (4.1).
Support for LEGENT's BUNDL product modified type 6 SMF record.
Support for MVS/ESA 4.2.2 (RMF 4.2.2) changes.
Support for NetView NPM 1.5 release.
Support for NetView FTP SMF record.
Support for Omegamon for CICS/ESA Version 550 ESRA user SMF.
Support for Omegamon V550 SMF 110 EMPs (Basic, DB2, DL/I).
Support for SCA's CMA-SPOOL user SMF record.
Support for Shared Medical Systems CICS exclude logic.
Support for Softtool Corporations's CCC (Change and Control).
Support for Software AG's NET-PASS user SMF record.
Support for Type 30 APARs OY33312 and OY25606 (no changes).
Support for 3490E (Serpentine) tape device.
Support for 9345E DASD device.
Addition of DB2ACCT,STAT0,STAT1 datasets to your PDB.
Error in VMXGVTOF/VMXGVTOF (only 3 extents kept) corrected.
Revision of BUILDPDB to eliminate SAS 5.18 Compiler Error 344.
Cache RMF Reporter support enhanced, decoded, and documented.
DB2 Reports corrections and enhancements in ANALDB2R.
Fujitsu FACOM MSP and FSP supported in XPDLPDA.
IMS Input Queue time, resources, CONDCODE corrections.
PR/SM Trend Data Base implemented.
VM/XA Trend Data Base implemented.
Each of these enhancements are described in the Change Log, below.
alphabetical list of the most important changes precedes the
changes.
V. Installation Instructions for MXG Version 9.9.
Over 800 sites have installed a PreRelease of Version 9, with almost
no reported problems. Sites migrating from MXG Version 8.8 or later
have found installation of MXG 9.9 was smooth and easy. The only
known incompatibilities are listed below, before the instructions.
Under ALL SAS Versions:
BUILDPDB/3 sites who have added DB2 processing to their PDB must now
"back-out" their exit code as described in Change 9.175; MXG now has
added DB2ACCT/DB2STAT0-1 datasets automatically to your PDB, and
a syntax error in BUILDPDB will occur if you fail to heed this note.
Only under SAS Version 6.07:
Use new member CONFIG07 instead of CONFIG. No error will occur, but
several unnecessary WARNING messages will be eliminated by use of
the new CONFIG07 member for 6.07.
Only under SAS Version 5.18:
BUILDPDB/3 under SAS 5.18 ONLY (not required with SAS 6.06/SAS 6.07)
sites must add a new temporary DD card in their JCL for BUILDPDB:
//SMFTEMP DD UNIT=SYSDA,SPACE=(CYL,(20,20))
This inconvenience may help eliminate SAS 5.18 compiler 344 errors.
If you encounter SAS 5.18 errors 344 or 160 see Change 9.175.
A syntax error in BUILDPDB will occur if you fail to heed this note.
However, if you have NOT installed MXG 8.8, you MUST note:
a. See SAS Notes section of this newsletter. The SAS options that
are required by MXG were changed between MXG 7.7 and MXG 8.8.
b. Execution under SAS 6.06 is different than under SAS 5.18. See
SAS Notes section of newsletters 17-21.
e. To write your PDB directly to tape, IMACCICS must be changed as
described in comments in the member. Although MXG does support
creation of the PDB directly to tape, most sites find it better
(especially elapsed time) to create the PDB on temporary disk and
then use PROC COPY to copy from disk to tape. (BUILDPDB re-reads
PDB datasets to build RMFINTRV, and this can cause lots of tape
spinning when the PDB DDname points directly to tape.)
Always read comments in the CHANGES member for compatibility issues, as
well as for any last minute changes added after Newsletter composition.
1. Installation, re-installation, and Space Requirements.
The MXG Installation instructions are found in Chapter 32 of the MXG
Supplement for both new installation and for version replacement, and
those instructions, as modified herein, are still valid.
The MXG tape is distributed as a Non-Labelled (NL) tape containing a
single file with DCB=RECFM=FB,LRECL=80,BLKSIZE=32720. The MXG tape is
an unloaded Partitioned Dataset in IEBUPDTE format. Note that the tape
blocksize was changed to 32720 (it had been 6160 in prior versions). You
will receive I/O errors if you specify the incorrect blocksize.
Under MVS use IEBUPDTE utility to build the MXG.SOURCLIB PDS library.
Under CMS use TAPPDS command to build the SOURCLIB MACLIB library.
Allocate the MXG.SOURCLIB for MXG 9.9 with SPACE=(CYL,(50,1,299)), using
DCB=(RECFM=FB,LRECL=80,BLKSIZE=23440) on 3380 devices, or
DCB=(RECFM=FB,LRECL=80,BLKSIZE=27600) on 3390 devices.
Under CMS, approximately the same space (50 cylinders) will ultimately
be required by the MXG SOURCLIB MACLIB, but during the CMS installation
process you will need at least 100 free cylinders on your minidisk.
MXG is tailored and extended by "Installation Macro" members (members
beginning with IMAC....), and by "MXG Exit Facility" members (members
beginning with EX....) that are copied and edited into the installation
"USERID.SOURCLIB", the name of the "MXG Tailoring" library, that you
create and concatenate ahead of MXG.SOURCLIB to the SOURCLIB DDNAME:
//SOURCLIB DD DSN=USERID.SOURCLIB,DISP=SHR --> site tailoring (yours)
// DD DSN=MXG.SOURCLIB,DISP=SHR --> never changed (mine)
If this is an MXG re-install, there should already be a USERID.SOURCLIB.
If not, then allocate one using the same attributes as the MXG.SOURCLIB,
with SPACE=(CYL,(1,1,99)). Under CMS create an equivalent MACLIB.
Tailor by editing members that you copy from my library to your library.
IMAC.... members are self-documenting, and member IMACAAAA indexes all
IMAC members. Most MXG sites have only a few tailoring members in their
USERID.SOURCLIB (typically, IMACACCT, IMACSHFT, IMACWORK).
VMAC.... members contain the actual processing code, and normally should
not exist in your USERID.SOURCLIB, and should always be removed when you
install a new version of MXG. However, if you have installed printed
Changes from an MXG Newsletter, you might have copied VMAC member(s)
from MXG.SOURCLIB into your site's USERID.SOURCLIB and then modified the
VMAC member. (Alternatively, you could have created an MXG.CHANGLIB in
which you put those in-between-version changes.) In either case, if
you made temporary changes, they must be removed now. Delete all of the
VMACs members from your USERID.SOURCLIB (or delete the MXG.CHANGLIB).
Otherwise, your modified VMAC member would be used instead of MXG's.
You should record all tailoring changes in your USERID.SOURCLIB so the
next MXG technician will know what you have done. You should create a
member named CHANGES in your USERID.SOURCLIB, similar to member CHANGES
in the MXG.SOURCLIB which documents all MXG changes.
If there are IMAC.... members in your USERID.SOURCLIB, you must look at
the alphabetic list of changed IMACs in the Change Log, below, and must
retrofit your tailoring on the new member in this library. In MXG 9.9,
only IMACACCT was changed (Change 8.290, in member 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 Chapter FORTY.
Summary of critical actions to be taken in installing new version:
a. All VMAC.... members in your USERID.SOURCLIB must be examined
and, in general, must be deleted.
b. All IMAC.... members in your USERID.SOURCLIB must be compared
with the IMAC.... members that have been changed in this MXG
version (see alphabetic list at beginning of Change Log). You
you MUST start with the IMAC in this version and retrofit your
installation's tailoring. Member IMACAAAA indexes all IMAC's.
c. It is always wisest to PROC PRINT the first 50 observations of
important datasets, especially PDB.JOBS, which can be affected
by user tailoring in IMACPDB. A visual scan of that PROC PRINT
serves as an excellent validation of correct installation, and
will almost always detect any serious problems BEFORE you begin
your production MXG runs! See also the MXG utility UTILPRAL.
VI. SAS Technical Notes.
1. The following important notes are repeated from prior Newsletters:
a. SAS OPTIONS REQUIRED under version 5.18, 6.06, or 6.07.
Please read this section carefully. MXG execution will fail if you
do not pay attention to these (potentially incompatible) changes:
SAS options that are MANDATORY with all SAS Versions:
NOIMPLMAC MAUTOSOURCE SASAUTOS=SOURCLIB ERRORABEND MACRO DQUOTE
NOIMPLMAC should ALWAYS be used in ANY program.
MAUTOSOURCE and SASAUTOS=SOURCLIB are required by MXG to
resolve %MACRO references without extra I/O by using autocall.
ERRORABEND ensures SAS stops on any error condition.
MACRO enables SAS to recognize %MACROs.
DQUOTE is needed to extract values of certain string %MACROs.
SAS options MANDATORY under SAS Version 5.18 (do not exist in V6):
MWORK=28000 GEN=0
MWORK was needed in large %MACROs (like %ANALDB2R).
GEN=0 was needed to eliminate unnecessary I/O and CPU time, and
is discussed in the 1984 Guide (see Index).
SAS options MANDATORY under SAS Version 6 (did not exist in 5.18):
MEMSIZE=24M
Previously, MXG recommended MEMSIZE=12M, but programs that build
many datasets concurrently (like BUILDPDB, VMACVMXA, etc.) will
need more of this virtual storage above the line, because of the
new MXG recommended value for BLKSIZE='half-track'. The MEMSIZE
option only works under MVS/XA and MVS/ESA, and since it is not
a real resource, and only used when needed during the "building"
phase in MXG processing, the new default of MEMSIZE=24M should
not cause any problem, and will avoid unnecessary ABENDs.
If you are using MXG and SAS 6.06 under MVS/370 or CMS/370, you
will have to reduce this MEMSIZE= parameter to no more than 6M,
and must reduce the BLKSIZE (try 4096, or the minimum 1024).
Small BLKSIZE will allow your program to compile, but the DASD
work space you will need will significantly increase, as will
the run-time, IOs, and CPU requirements for the same job.
SAS options STRONGLY RECOMMENDED for SAS 6.06 performance:
BLKSIZE=23040 BUFNO=2 -- for 3380's
BLKSIZE=27648 BUFNO=2 -- for 3390's
Both are now automatically set by MXG's use of BLKSIZE(DASD)=HALF
in MXG's CONFIG/CONFIG07 members for permanent datasets, but
note that the WORK DD in the default SAS JCL procedure contains
a BLKSIZE=6144 parameter which MUST be overridden or changed for
optimum execution performance:
// EXEC SAS
//WORK DD DCB=BLKSIZE=23040
The BLKSIZE option in the CONFIG member will have no effect if a
DCB=BLKSIZE value is specified on the JCL DD statement.
See "SAS Benchmarks" in Newsletter TWENTY for resource savings.
SAS options recommended with either SAS Version 5.18, 6.06 or 6.07:
FIRSTOBS=1 OBS=MAX
ERRORS=2
NOSOURCE NOSOURCE2 NOMACROGEN NOMPRINT NOMLOGIC
So how do you specify these recommended/required MXG options?
In Version 5.18, MACRO and MWORK=28000 must be specified on the EXEC
statement, but all other options could be specified on an OPTIONS
statement right after your SYSIN DD * statement. However, so you do
not have to remember them nor type them, MXG member SASOPTV5 has all
of the recommended options in an OPTIONS statement, so you need only
%INCLUDE SOURCLIB(SASOPTV5); as your first SAS statement:
//stepname EXEC SAS518,OPTIONS='MACRO MWORK=28000'
//SYSIN DD *
%INCLUDE SOURCLIB(SASOPTV5);
... the rest of your program ...
For SAS Version 6, options can be set with an OPTIONS statement, or
with the OPTIONS= JCL parameter, or (as is MXG's recommendation) via
the CONFIG= JCL parameter on the EXEC statement. MXG member CONFIG
contains the MXG required and recommended options for SAS 6.06, and
member CONFIG07 contains the SAS 6.07 recommendations. The BLKSIZE
and MEMSIZE options were increased in MXG 9.9, and the new CONFIG07
member was added with new SAS 6.07 options. (You could also supply
options by overriding the CONFIG DD in the SAS JCL procedure, but
using the CONFIG= parameter is safer and simpler.).
// EXEC SAS606,TIME=10,
// CONFIG='MXG.SOURCLIB(CONFIG)'
// EXEC SAS607,TIME=10,
// CONFIG='MXG.SOURCLIB(CONFIG07)'
IF YOU DON'T HAVE THE RIGHT OPTIONS IN EFFECT, YOU WILL RECEIVE
RUDE AND INSULTING SAS ERROR MESSAGES, INCLUDING 180 ERRORssss!
b. Format libraries are different in MVS SAS Version 6 and Version 5.
The MXG-built "SASLIB" formats are built by the first step of either
JCLTEST (for SAS 5.18) or JCLTEST6 (for SAS 6.06).
Under SAS Version 5.18, formats are members of a PDS load library
which must be allocated as SPACE=(CYL,(3,1,99)). SAS 5.18 formats
are always referenced using the DDNAME of SASLIB.
Under SAS Version 6 formats are members of a SAS data library, which
must be allocated as SPACE=(CYL,(1,1)). Note there is NO third SPACE
parameter (for PDS directory blocks), because data libraries in SAS
Version 6 are physical sequential files. SAS Version 6 format
libraries are always referenced using the DDNAME of LIBRARY.
In either version of SAS, the blocksize is set by the PROC FORMAT.
MXG always requires the appropriate DDNAME (SASLIB or LIBRARY).
You will fail with SAS 170 FORMAT NOT FOUND errors if you do not
have the correct format library pointed to by the correct DDNAME.
VII. Documentation of MXG Software.
Member CHANGES always contains the version number of MXG Software, and
it lists changes that were installed in that version. The members named
Changenn have the contents of CHANGES when that "nn" MXG version was
created. Description of enhancements will be found in the text of the
Change description that made the enhancement (in those CHANGES and
CHANGEnn members). The CHANGE members can be scanned online (with SPF
BROWSE) to search for specific product name references (CICS, MVS/ESA,
etc.). The text of each Change identifies the member(s) that were added
or altered by that change. Documentation (especially for new product's
support) is usually also found in comments at the beginning of those
members listed in the change entry.
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 of each Newsletter is not
replicated in member NEWSLTRS, since that text will be in CHANGES).
Member DOCVERnn is the "delta-documentation" (in abbreviated Chapter
FORTY style) of only those variables and datasets that were changed
between successive MXG Versions. There is a DOCVERnn "delta" member in
the MXG library for each version.
Penultimately, member DOCVER contains abbreviated Chapter FORTY format
that documents all of the variables names in all of the MXG datasets
that are created by that MXG Software Version (alphabetically by data
set name and variable name).
Finally, MXG is a source distributed system, so you can often find your
answer by BROWSE/EDIT of the source member, especially the VMACs that
actually create the dataset, or ANALs that analyze the MXG datasets.
In many instance, 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 expects you to also have access to the vendor's
documentation of particular data records you are using for analysis.
VIII. 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 easily installed, critical part of the correction).
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.
Changes thru 9.241 are contained in MXG Version 9.9 Mar 1, 1992
Changes thru 9.235 were printed in NEWSLETTER TWENTY-ONE Mar 1, 1992.
Changes thru 9.218 were contained in MXG PreRelease 9.8 Feb 3, 1992.
Changes thru 9.212 were contained in MXG PreRelease 9.7 Jan 27, 1992.
Changes thru 9.205 were contained in MXG PreRelease 9.6 Jan 14, 1992.
Changes thru 9.184 were contained in MXG PreRelease 9.5 Dec 1, 1991.
Changes thru 9.175 were contained in MXG PreRelease 9.4 Nov 15, 1991.
Changes thru 9.107 were contained in MXG PreRelease 9.3, Aug 1, 1991.
Changes thru 9.104 were printed in NEWSLETTER TWENTY Aug 1, 1991.
Changes thru 9.069 were contained in MXG PreRelease 9.2, July 1, 1991.
Changes thru 9.038 were contained in MXG PreRelease 9.1, June 3, 1991.
Changes thru 8.305 were contained in MXG Production 8.9, May 1, 1991.
Changes thru 8.285 were contained in MXG Production 8.8, Apr 8, 1991.
Changes thru 8.283 were printed in NEWSLETTER NINETEEN, Apr 8, 1991.
Alphabetic INDEX of significant changes in MXG 9.9 (after MXG 8.8):
Member Change Description
many 9.151 DASD Device 3345 ("Serpentine") data recognized.
many 9.152 Tape Device 3490E ("Serpentine") data recognized.
ANALACHE 8.293 Cache RMF Reporter analysis uses 3990 records now.
ANALDBTR 9.135 DATASET S064058 NOT SORTED error corrected.
ANALDB2R 8.299 Variable Not Found if only Acct Trace Long requested.
ANALDB2R 9.030 DB2 Reports have incorrect values for some fields.
ANALDB2R 9.032 DB2 Audit Reports not created if PDB=SMF specified.
ANALDB2R 9.104 DB2 Trace TRANSIT report causes DATA IS NOT SORTED.
ANALDB2R 9.210 DB2PM-like SQL trace reports added.
ANALRACF 9.064 RACF Analysis of OPERATOR,SPECIAL activity.
ANALTMS 9.059 PROC SUMMARY out of memory condition.
ANALVVDS 9.031 PERM should be changed to MXGVVDS.
ANALVVDS 9.053 MXG 9.1 only, VMXGVVDS should have been MXGVVDS.
APAR/PTF 9.141 OY33312/UY52529 has no impact on MXG processing
ASUMDBDS 9.012 TMON/CICS trending fails with Release 7 data.
ASUMJOBS 8.291 EXCPTOTL, IOTMTOTL were not kept in BATCHJOB.
ASUM70PR 9.091 TYPE70PR data summarized into PDB.ASUM70PR
ASUM70PR 9.179 ASUM70PR data wrong if NRPRCS not equal to PARTNCPU.
AS400PDS 8.286 AS400PDS contains no records.
BLKSIZE 9.109 MXG distribution tape block size changed to 32720.
BUILDPDB 9.049 SAS 6.06 and MXG 8.8 under MVS/370 options.
BUILDPDB 9.095 Dataset TYPE0203 added to default datasets built
BUILDPDB 9.175 DB2ACCT,STAT0/1 automatically created by BUILDPDB.
CASORT66 8.295 SAS datasets destroyed by CASORT release 6.6.
CHANGE08 9.073 Example to create _DAY in 8.213 was wrong
CONFIG 9.022 Option VERSIONLONG specified to display SAS version.
CONFIG 9.131 Default CONFIG for 6.06 updated.
CONFIG07 9.131 Default CONFIG for 6.07 updated.
DIFFDB2 9.080 Not all DB2STAT0/1 variables were deaccumulated
DIFFDB2 9.128 DB2STAT0/1 variables improperly deaccumulated.
EXPDB304 9.034 BUILDPDB/3 steps data creation exit.
EXPDB6 9.034 BUILDPDB/3 steps data creation exit.
EXTY72 9.184 CPURCTTM invalid in TYPE72, not included in CPUTM.
IEBUPDTE 8.286 Unload of MXG 8.8 set condition code 4.
IMACACCT 8.290 ACCOUNT FIELD n LENGTH WRONG corrected.
IMACCICS 9.005 PDB cannot be built on tape unless IMACCICS changed.
IMACDB2 9.121 DB2 Correlation ID decoding corrected.
IMACEXCL 9.051 Support for CICS type 110 EXCLUDE statement.
IMACEXCL 9.145 CICS EXCLUDE/INCLUDE logic externalized
IMACFMTS 9.066 New IMAC for user formats for SAS 6.06.
IMACICDA 9.146 CICS EMP data control externalized
IMACICDB 9.181 Support for APAR PL83370 in DBCTL data with CICS/ESA
IMACICOx 9.146 Omegamon V550 User EMPs added to type 110
IMACKEEP 9.017 A better way to drop MXG variables not using IMACKEEP
JCLDASD 9.031 MXGDASD,PERM DDNAMEs should be DISK,MXGDASD
JCLMNTH 9.225 MONTHBLD require only one tape drive, runs faster!
JCLTEST6 9.108 FORMAT not found error in step SMFSMALL.
READDB2 9.164 List processing %MACRO for DB2 IFCIDs added.
RMFINTRV 9.184 Enhanced, MVS/ESA CPU times and PR/SM data added.
RMFINTRV 9.204 RMF72D NOT SORTED condition corrected.
SPUNJOBS 9.005 PDB.SPUNJOBS on tape caused 207 error.
SPUNJOBS 9.013 SPUNJOBS timestamps not 8 bytes, truncating values.
TLMS 9.041 TLMS causes 713-04 ABEND if DBLTIME=0.
TRNDDB2A 8.301 DB2 Acct trending failed in 2nd week of execution.
TRNDDB2A 9.209 DB2 Trending errors corrected.
TRNDDB2S 8.301 DB2 Stats trending failed in 2nd week of execution.
TRNDVMXA 9.028 VM/XA Trend Data Base implemented.
TRNDVMXA 9.089 VM/XA Trended PFXUTIME and PCTCPUBY incorrectly
TRND70PR 9.091 TYPE70PR data creates new TREND.TRND70PR
TRND70PR 9.179 TRND70PR data wrong if NRPRCS not equal to PARTNCPU.
TRND71 9.092 TYPE71 data creates new TREND.TRND71
TRND72 9.093 MVS/ESA 4.2 variables added to TREND.TRND72
TYPEAPAF 9.218 Support for Amdahl's APAF.
TYPECIMS 9.122 IMF Chained Transactions response time corrected.
TYPECIMS 9.235 Support for IMF 2.7 log records.
TYPEIMS 9.106 IMS Multi-trans resources wrong.
TYPEIMS 9.182 Multi-trans corrections, CONDCODE no longer blank.
TYPEIMS 9.216 IMS 3.1 resources wrong for Quick Reschedule trans.
TYPEMON8 9.011 TMON/CICS Release 9.0 supported via conversion only.
TYPEMON8 9.015 TMON/CICS Version 8 History file cause MXG failure.
TYPEMON8 9.168 STOPOVER with bad record in Landmarks Monitor
TYPEPDL 8.297 Fujitsu FACOM MSP and FSP support replaced XPDLPDA.
TYPE84 9.202 JES3 JMF type 84 SMF record partial support.
UTILCICS 9.019 Not Sorted error corrected for CICS/ESA dictionary.
VDOCACHE 9.027 Documentation re-write has begun.
VMACACF2 8.289 ACF 5.2 new variables not kept.
VMACACF2 9.086 ACF2 REC=L CN=3 records were not output
VMACACHE 8.293 Cache RMF Reporter support enhanced and decoded.
VMACAIM2 8.298 Fujitsu AIM database manager records corrected.
VMACCADM 9.021 Support for CADAM's Statistics Data File.
VMACCCC 9.172 Softtool Corporation's CCC (Change Control) user SMF
VMACCMA 9.143 Support for CMA-SPOOL user SMF record
VMACCMF 9.126 CMF User SMF record STOPOVER corrected.
VMACCTLD 9.038 Support for Boole & Babbage CONTROL-D SMF record.
VMACDB2 9.138 Support for DB2 2.3.0
VMACDCOL 8.285 IBM DASD measures use MB for million, not megabytes.
VMACDCOL 9.144 DCOLLECT values incorrect after IBM APAR OY36364
VMACDCOL 9.157 DCOLLECT variables changed from character to numeric
VMACDCOL 9.180 Capacity values off by 120 bytes.
VMACDMON 9.196 Support for ASTEC 1.5.
VMACEPIL 8.284 Support for EPILOG/CICS 451 added, and enhanced.
VMACEPIL 8.287 Invalid member on MXG 8.8 replaced.
VMACFOCU 9.223 Support for Information Builder's FOCUS MSO SMF.
VMACFTP 9.056 Support for NetView FTP User SMF record.
VMACFTP 9.170 FTP records produce no observations
VMACHSM 9.097 Support for HSM 2.6 SMF record
VMACILKA 9.020 Support for Interlink's SNS/TCPaccess SMF record.
VMACILKG 9.020 Support for Interlink's SNS/SNA Gateway SMF record.
VMACILKV 9.020 Support for Interlink's SNS/TCPvt SMF record.
VMACIMS 9.063 TYPEIMS Input Queue time correction.
VMACLMS 9.229 Support for Memorex Telex LMS/PM SMF record.
VMACMIM 9.173 LEGENT's Multi-Image Manager (MIM) user SMF record
VMACMIM 9.173 Support for LEGENT's Multi-Image Manager MIM record.
VMAC28 9.116 NPM 1.4.1 support was not complete in MXG 9.3.
VMACNETP 9.118 Support for NET-PASS user SMF record.
VMACNSM 9.194 Support for NOMAD's Session Manager record.
VMACNSPY 9.033 STOPOVER protection for invalid records.
VMACNSPY 9.044 STOPOVER with NETSPY Accounting record.
VMACNSPY 9.045 NETSPY Accounting subtype caused STOPOVER.
VMACNSPY 9.165 LEGENT's LANSPY component of NETSPY additions.
VMACOMCI 9.147 Omegamon V550 User SMF record
VMACOPCA 9.224 IBM's OPC/A Job Tracking and Audit Trail Log.
VMACRMDS 9.139 RMDS records RMDSORG='D' STOPOVER corrected.
VMACSMF 9.094 New message at end of SMF processing on log
VMACSNAP 9.167 Codework Software's SNAPAD-MVS user SMF record
VMACSPMS 9.088 Support for Amdahl's SPMS Release 1.2 SMF record
VMACTAO 9.018 Support for Fischer's Totally Automated Office TAO.
VMACTAO 9.200 Support for Emc2/TAO Release 3.3.0.
VMACTMS5 9.016 Support for CA-1 (TMS) Release 5 complete rewrite.
VMACTMS5 9.057 Missing semicolons.
VMACTMVS 9.142 TMON/MVS spanned record STOPOVER circumvented
VMACUCB 9.002 3490E cartridge tape now recognized.
VMACVMXA 8.296 VM/XA used more work space than really required.
VMACVMXA 9.096 LOGICAL RECORD SPANS message corrected
VMAC102 9.178 IBM incompatible change to IFCID 140, 141 in 2.3
VMAC110 8.292 Unexpected Statistics Subtype due to Boole CICSMGR.
VMAC110 9.051 Support for Shared Medical Systems CICS modifications
VMAC110 9.062 Support for CICS/ESA 3.2.1.
VMAC110 9.084 CICS PCLOADCN has different meaning.
VMAC23 9.134 New fields were not input.
VMAC28 9.061 Support for NetView Performance Monitor NPM 1.4.1.
VMAC28 9.214 Support for NPM Release 1.5.
VMAC30 9.001 INVALID DATA FOR SMF30ASO with MVS/ESA 4.2 eliminated
VMAC30 9.085 STCs starting with A confused APPC logic.
VMAC30 9.134 Support for MVS/ESA 4.2.2.
VMAC42 9.048 Circumvention of IBM DFP 3990 Cache type 42 errors.
VMAC57 9.010 Invalid ESS Section message due to IBM error.
VMAC6 9.083 OUTDEVCE changes affect PRINTLNE, EXTWTRLN
VMAC6 9.154 LEGENT's Bundle product caused type 6 stopover
VMAC6156 9.046 TYPE6156 variables ACTION, FUNCTION not valid.
VMAC7072 9.001 INVALID DATA FOR IOCRFC with MVS/ESA 4.2 eliminated.
VMAC7072 9.054 MXG 9.1 only, Change 9.001 incompletely installed.
VMAC7072 9.070 TYPE72 CPUHPTTM,CPUIIPTM,CPURCTTM wrong in MVS 4.2
VMAC7072 9.072 TYPE70PR LCPUADDRs 2 and 3 wrong if DEDICATED CPU
VMAC7072 9.119 ACF2 STOPOVER due to bad record length corrected.
VMAC7072 9.120 ESA CPU times HPT/IIP/RCT wrong by 2%.
VMAC73 9.001 INVALID DATA FOR IODFDATE in MVS/ESA 4.2 eliminated.
VMAC74 9.001 First STOPOVER with MVS/ESA 4.2 data corrected.
VMAC74 9.039 Second STOPOVER with MVS/ESA 4.2 data corrected.
VMAC78 9.055 STOPOVER with MVS/ESA 4.2 data corrected.
VMAC78CU 9.047 Missing fields due to IBM microcode errors.
VMAC79 9.007 Support for (archaic?) RMF 3.5.1 type 79 records.
VMAC90 9.134 Support for MVS/ESA 4.2.2 added new subtypes.
VMXGHSM 9.009 HSM MCD data can cause STOPOVER.
VMXGVPD 9.158 STOPOVER with VPD record type "E".
VMXGVTOC 9.159 VTOC data beyond 3rd extent lost since MXG 7.2.
VMXGVTOF 9.035 SAS 5.18 only, did not read all extents.
VMXGVTOF 9.040 First Extent on each volume lost. .
VMXGVTOF 9.159 VTOC data beyond 3rd extent lost since MXG 7.2.
WEEKBLD 9.050 Submitting job may need DCB on INTRDR DDNAME.
XMAC74 9.054 MXG 9.1 only, Change 9.001 incompletely installed
Inverse chronological list of all Changes:
NEXTCHANGE: Version 9 72
Change 9.245 Yet another IMS idiosyncracy was discovered after MXG 9.8
TYPEIMS and corrected by this contributor. For Message Switching,
Feb 20, 1992 each transaction in a single logical business task has the
same ARRVTIME (i.e., the arrival time of the first of the
group). Since RESPONSE time is calculated from ARRVTIME
to ENDTIME, this caused the calculated response time for
Message Switched transactions to be overstated. Russell
tried to use SEQNO and NMSGSW to identify each group of
transactions, but that algorithm did not always uniquely
identify a group, and IBM was unwilling/unable to provide
technical validity of those fields. Thus the solution was
to sequence the IMSTRAN dataset and then, after the fact,
recognize (using the LAG function) and correct the
ARRVTIME of subsequent Message Switched transactions.
Thanks to Russell Dewar, NM Computer Services Pty., AUSTRALIA.
Change 9.244 The "Prudential Writer" program is a "freebie" for Xerox
VMAC6 9700 forms management, which writes a type 6 SMF external
Feb 19, 1992 writer record. Unfortunately, the READTIME value put in
the SMF record is not READTIME but JCNVTIME, and thus this
type 6 record cannot be matched with the other SMF records
written by the same job! There is presently no fix, but
their error was only discovered today! If you use this
program, call/fax us for a status update.
Thanks to David Ehresman, Univerity of Louisville, USA.
Change 9.243 JES2 SPOOL Transfer Program can cause "real" purge records
BUILDPDB to be mis-recognized by BUILDPDB and sent to PDB.NJEPURGE.
Feb 19, 1992 Change 7.008 discussed the MXG logic added to process the
multiple purge records that are created when a job is
offloaded before execution and then later reloaded for its
execution. The SPOOL transfer purge record was recognized
because DEVNAME begins with 'OFF', and was sent to the
PDB.NJEPURGE, since it is not the true job purge record.
However, it is possible to offload a copy of a job using
SPOOL transfer, but not delete that job from spool. (Sites
specify DISP=KEEP on the JESPARMS OFFLOAD statement to
make a backup copy of the spool before system maintenance,
but only reload if a failure occurred during testing).
The offload does not create a purge record, but the actual
job purge record now contains DEVNAME=OFF1.JT1 (I guess,
so you know the job had been previously copied to spool?).
This caused MXG to send this "real" purge record to the
PDB.NJEPURGE, and the job's other records sat in the SPIN
file waiting on the nonexistent purge record until SPINCNT
was exceeded, when the job was finally output to PDB.JOBS.
This change modifies the test for DEVNAME=:'OFF' and is
(DEVNAME=:'OFF' AND JPURTIME LT JSTRTIME) so that only
the unwanted SPOOL transfer purge record is excluded from
BUILDPDB processing, by comparing the purge record time
with the job start time.
Thanks to David Ehresman, Univerity of Louisville, USA.
Change 9.242 PR/SM variable NRPRCS is the number of partitions, butthe
VMAC7072 pseudo-partition named PHYSICAL added by APAR was also
Feb 18, 1992 being counted. Now it is subtracted out from NRPRCS.
Thanks to Tim Follen, Blue Cross Blue Shield of Ohio, USA.
Change 9.241 A DB2ACCT dataset with 250,000 obs requires 5,000 tracks.
ANALDB2R A DB2 Accounting Summary report needed 10,000 tracks of
Feb 17, 1992 work space (twice the 5,000 tracks because at the end of
the sort phase both the input and output datasets exist),
because ANALDB2R unwisely kept all 221 DB2ACCT variables!
Now, only the 43 variables needed for the Summary report
are kept, and only 1800 tracks are now required! A change
in 9.7 that required yet another copy of DB2ACCT in the
work file was also eliminated in this re-design.
Thanks to Neil Ervin, Huntington Bank Service Company, USA.
Change 9.240 The IRG (inter-record gap) calculation used to estimate
VMACTMS feet of tape should have been IF IRG LT 38000 THEN ....
VMACTMS5 instead of NE (VMACTMS) or LE (VMACTMS5). The 3480 tape
Feb 17, 1992 length was correct, but 3490s calculated too long!
Thanks to Sam Sheinfeld, Kraft General Foods, USA.
Change 9.239 Under MVS/370, SAS 6.06 can execute BUILDPDB, but it has
BUILDPDB required these changes.
Feb 17, 1992 1. CICS processing must be moved from BUILDPDB to a second
step. In member BUILDPDB, you will have to comment out
the _VAR110 and _CDE110 lines, the lines which PROC SORT
datasets starting with CIC....., and %INCLUDEs for members
starting with CIC.....
2. Set MEMSIZE=6M, a Region size of 6M, and insert an
OPTIONS BLKSIZE=2048; preceding the %INCLUDE of BUILDPDB.
3. If you need to process the type 110 CICS SMF records,
you should use IMACEXIT to select ID=110 and write them
to SMFTEMP the BUILDPDB step, then use a second step to
execute %INCLUDE SOURCLIB(TYPE110), with the SMF DDname in
this second step pointing to the temporary dataset name
you used on the SMFTEMP DDname in the BUILDPDB step.
4. Again, all of this flailing around is necessary ONLY if
you are trying to execute SAS 6.06/6.07 under MVS/370. If
you have MVS/XA or MVS/ESA, you need none of the above!
Thanks to Darrell Allen, Special Metals, USA.
Change 9.238 SMS fields (Data Class, Storage Class, Management Class)
VMXGHSM plus SMS-related flag, VSAM organization and last update
Feb 18, 1992 datetimestamp were added to the three MCD datasets created
from the Migration Control Data Set.
Thanks to John E. Schultz, First National Bank of Maryland, USA.
Change 9.237 Reserved Change Number.
Change 9.236 Support for BEI Systems PDQ/PAGE SMF record creates four
EXPDQAMJ datasets:
EXPDQAMO PDQAMON - Auxilliary Storage by performance group
EXPDQEMJ PDQAMONJ - Auxilliary Storage by job (ASID)
EXPDQEMO PDQEMON - Expanded Storage by performance group
IMACPDQ PDQEMONJ - Expanded Storage by job (ASID).
TYPEPDQ This vendor contribution has only been syntax checked.
VMACPDQ
Feb 14, 1992
Thanks to Bill Ek, BEI Systems, USA.
---Changes thru 9.235 were printed in MXG Newsletter TWENTY-ONE-----
Change 9.235 Support for Boole and Babbage IMF 2.7 is provided in MXG
TYPECIMS (it was easy - there was no change in the IMF log record
Feb 12, 1992 format since IMF 2.6!)
Change 9.234 RMFINTRV memory variables ending in MEMR were incorrect.
RMFINTRV Instead of the total memory (bytes) for the workload,
Feb 12, 1992 they contained the per-user bytes for the workload, and
variable TOTMEMR contained frames instead of bytes! The
MEMR variables should have been divided by DURATM and
not the RESD variables, and TOTMEMR should have been
multiplied by 4096 to convert frames to bytes.
Thanks to Shirley Rementer, Atlantic Electric, USA.
Change 9.233 NETSPY variable LRSPNET normally contains the response
VMACNSPY time of the last transaction, but a new variable exists,
Feb 12, 1992 LRSPNETV='Y', to flag that the LRSPNET value contains
the calculated average response for the interval. This
is particularly important for LU 6.2 and APPC sessions,
where only the calculated LRSPNET is available. Labels
for LRSPNET and LRSPHOST should have indicated "LAST".
Thanks to Marty Quinlan, Virginia Power, USA.
Change 9.232 Sample tape error report enhanced with a report by device
ANALESV type added, allowing comparisons of errors by different
Feb 10, 1992 types of tapes and drives in your tape pool.
Change 9.231 Revised documentation of DB2 reporting using ANALDB2R,
DOCDB2PM ANALDBTR, and READDB2 members adds new reports and DB2
Feb 10, 1992 2.3 considerations.
Change 9.230 Major enhancements were made to correct a known bug and
GRAFTRND add an additional set of graphs. If you had more than
Feb 10, 1992 18 months of data in your TRNDRMFI dataset, some of the
graphs (Avg vs Max CPU Busy and All Workload Bar charts)
could not be produced because the x axis could not be
fit on most graphics devices. The best circumvention
would have been to use PROC GPLOT and AREA fill but this
proved impractical because if AREAS=16 is specified and
only 5 workloads are present, the entire area of the
graph is filled with the pattern for workload 5. This is
clearly not what you (or we) wanted. Until this is fixed
(if ever) the workload bar charts will be limited to the
past 65 weeks. Why 65? It appears to be the least common
denominator for most graphic devices. 65 bars fit on all
of the devices we have tried. The data to be retained
is constructed based on the data in your TRNDRMFI data.
An MXGNOTE is produced detailing the range of dates in
your TRNDRMFI dataset and, if too much data is present,
MXGWARNINGs are produced outlining the error condition
and what will be done to circumvent the problem. There
will be notes on the SAS LOG that some observations were
missing or out of range. This is normal. When data is
being projected, the actual CPU is missing. The use
of PROC GLM to project using linear regression has been
extended to the workload level (only if you have the
SAS/STAT product.) These graphs are identical to the
current workload graphs except that they carry workloads
forward into the future the number of weeks specified by
WEEKSOUT parameter. As with the other workload charts,
only 65 weeks are charted. If a workload is shrinking,
at the point in time at which it reaches zero or goes
negative, it will be set to missing.
Change 9.229 Support for Memorex Telex Library Management Software
EXLMSADO Performance Monitor (LMS/PM), a significant contribution
EXLMSAIN written by Dan Kaberon of Hewitt Associates, was provided
EXLMSALD to MXG users by Memorex Telex. Not only did Dan write
EXLMSATL this code in MXG style, he also provided Chapter 40 style
EXLMSCHG MXG documentation, which you will find in ADOCLMS.
EXLMSCIN Seventeen datasets are created from the twenty subtypes
EXLMSEJE of the LMS SMF record. See ADOCLMS for more information.
EXLMSENT LMSXX LMS SUBTYPE INVENTORY
EXLMSEVE LMSINIT LMS SUBTYPE 0: LMS INITIALIZATION
EXLMSINI LMSSDOWN LMS SUBTYPE 1: LMS SHUTDOWN
EXLMSISC LMSCHG LMS SUBTYPE 2/12: SETTING CHANGE
EXLMSLIN LMSALDOM LMS SUBTYPE 4: ALLOCATE/DOMAIN STMTS
EXLMSMOU LMSEVENT LMS SUBTYPES 5,13-15: ATL EVENT
EXLMSSDO LMSATLI LMS SUBTYPES 10: ATL INIT
EXLMSUNL LMSADOWN LMS SUBTYPE 11: ATL SHUTDOWN/INACTIVE
EXLMSVER LMSISCR LMS SUBTYPE 19: ATL INTVL SCRATCH STATS
EXLMSXX LMSENTRY LMS SUBTYPE 20: CARTRIDGE ENTERED
IMACLMS LMSVER LMS SUBTYPE 22: CARTRIDGE VERIFY
TYPELMS LMSMOUNT LMS SUBTYPE 21: ATL MOUNT
VMACLMS LMSEJECT LMS SUBTYPE 23: CARTRIDGE EJECTED
Feb 10, 1992 LMSUNLD LMS SUBTYPE 24: UNLOAD
LMSCINIT LMS SUBTYPE 25: CART INITIALIZED
LMSLINT LMS SUBTYPE 30: INTERVAL
LMSAINT LMS SUBTYPE 31: ATL INTERVAL
Change 9.228 DCOLLECT's space calculation for dataset size (DCDALLSP
VMACDCOL in dataset DCOLDSET) is wrong; the total allocated space
Feb 10, 1992 in the dataset records can exceed the allocated space in
the volume record, because IBM uses the wrong track size
in computing the size of the dataset. The unformatted
track capacity is used, instead of the formatted track
size. Changes 9.180 and 9.144 discuss APAR OY36364 which
corrected the track size used in DCOLLECT volume records,
but the correction was not applied to the dataset record.
APAR OY48920 discusses DCDALLSP for 3390s, but it is not
clear if that APAR recognizes the other fields that are
wrong, nor if the fix (when a PTF exists) will apply to
both 3380s and 3390s. Check the status of that APAR.
Thanks to Terry Duchow, Minnesota Mutual Life, USA.
Change 9.227 CICS Exception variables MSWAITCN and TSWAITCN should be
VMAC110 missing, as these values existed only under CICS 1.6. The
Feb 10, 1992 label for MSREQWT now correctly indicates it is the bytes
of main storage acquired only after waiting.
Thanks to Paul Masters, Blue Cross and Blue Shield of Texas, USA.
Change 9.226 WSF timestamp ACCLOGON was incorrectly input as PD4.2; it
FORMATS needed to be input as HH PK1. MM PK1. SS PD2.1. Variable
VMACWSF AUDACT was incorrectly input as $CHAR1. when it should be
Feb 10, 1992 input PIB2. It is removed from the LENGTH statement, and
it is now formatted with MGWSFAC (a new numeric format).
Thanks to Douglas Clarke, General Accident, ENGLAND.
Change 9.225 Revised JCL for MONTHBLD requires only ONE tape drive,
JCLMNTH eliminates many tape mounts (especially if your weekly
Feb 6, 1992 PDBs are multi-volume), and significantly reduces the run
time of the monthly PDB build job. The revision copies
each of the weekly PDBs from tape to temporary DASD (and
selects only the datasets you intend to build monthly),
and then uses those temporary DASD files as input instead
of spinning input tapes back to the beginning of the tape
for each input dataset to be read. The output monthly
PDB is written to tape, on the same drive used to copy
the weekly datasets. As long as you have enough temp
DASD space for the job, this is a much better and faster
method of building your monthly PDB. The revised JCL is
in member JCLMNTH, but the existing member JCLMONTH was
left in the library as well.
Change 9.224 Support for IBM's Production Control System OPC/A Job
EXOPC20 Tracking and Audit Trail Log Records. Twelve datasets
EXOPC23 are created from the standard IBM log records:
EXOPC24 OPCA20 JT STARTED EVENT
EXOPC25 OPCA23 OPERATION EVENT
EXOPC26 OPCA24 MCP EVENT
EXOPC27 OPCA25 SUBMIT EVENT
EXOPC28 OPCA26 AUTO RECOVERY
EXOPC29 OPCA27 MISSED FEEDBACK RECORD
EXOPC30 OPCA28 FEEDBACK RECORD
EXOPC31 OPCA29 AUTO-TRACKED EVENT
EXOPC32 OPCA30 SPECIAL RESOURCE EVENT
EXOPC33 OPCA31 ETT TAB FILE MAINTENANCE EVENT
EXOPC00 OPCA32 AUDIT TRAIL LOG RECORD
EXOPC01 OPCA33 MESSAGE LOG RECORD
EXOPC02 In addition, four user datasets for user log records are
EXOPC03 defined, OPCA00-OPCA03, for sites which write additional
VMACOPCA data records to the log.
TYPEOPCA
Feb 5, 1992
Thanks to Wolfgang Vierling, Vereinte Versicherungen, GERMANY.
Change 9.223 Support for Infomation Builder's FOCUS Multi-Session
EXFOCMSO Option accounting SMF record. One dataset is created:
IMACFOCU FOCUSMSO FOCUS MSO Accounting
TYPEFOCU This record provides CPU and EXCP resources and duration
VMACFOCU of session for accounting, in Release 6.5 Level 6 at PUT
9109. Technical Memo 7857.1 describes the contents.
Thanks to Mike Boyce, Anderson Consulting, USA.
Change 9.222 A vendor's type 39 record was truncated after 46 bytes,
VMAC39 causing INPUT STATEMENT EXCEEDED RECORD LENGTH error. MXG
Feb 5, 1992 now checks for complete header before INPUTing record,
and prints message and dumps record on SAS log instead of
failing with a STOPOVER abend.
Thanks to Connie Wilson, AMR Travel, USA.
Change 9.221 An archaic and confusing comment at the end of this
IMACFILE member was removed.
Feb 5, 1992
Thanks to Connie Wilson, AMR Travel, USA.
Change 9.220 DCOLLECT Migration and Backup datasets have new variables
VMACDCOL UMFLAG1/UBFLAG1 and UMDSORG/UBDSORG. Variables added by
Feb 4, 1992 APAR OY37378 to the Migration dataset were also added to
the Backup record, but were overlooked by MXG until this
change. (Since on one noticed their absence, they must
not be very important, but they are now decoded!)
Thanks to Joseph Faska, Depository Trust Corporation, USA.
Change 9.219 Minor typo (which caused no execution error). At line 164
VMACSPMS change the three @113's to @113, @115, and @116.
Feb 4, 1992
Thanks to John Chapman, British Gas, ENGLAND.
=======Changes thru 9.218 were included in MXG PreRelease 9.8 ==========
Change 9.218 Preliminary sample code for processing Amdahl's APAF data
IMACAPAF from MVS or VM data was provided by Amdahl. This code is
TYPEAPAF not in the style of MXG, and may be revised to conform to
Feb 2, 1992 MXG architecture, but it arrived in time to save you the
effort of writing it yourself when you install APAF.
Change 9.217 IMS Multi-Trans with only 03/35/31 sequence didn't always
TYPEIMS have accurate SERVICTM and RESPNSTM, whenever the same
Feb 2, 1992 MSGDRRN was reused at a later time for the same ODEST.
First, the INPUT and OUTPUT datasets contained blank
values for DTOKEN (because, from IBM, not all log
records contain a token), and second, the 31I record was
not used to create pseudo 31O and 35O records containing
DTOKEN to correct the INPUT/OUTPUT datasets. Now, 31I
records create both 31O and 35O records so DTOKEN exists,
and just to be sure, INPUT/OUTPUT observations without a
DTOKEN are now deleted before the final merge. Like all
scotch tape and chewing gum fixes to IMS log processing,
I hope this is the last one, and pray that IBM will soon
replace IMS with DB2, since IBM refuses to enhance the
IMS log with discrete transaction resource data.
Thanks to Lynn Delacourt, Volvo Heavy Truck Corporation, USA.
Change 9.216 IMS 3.1 records contain duplicate values of DLRTOKEN, the
TYPEIMS key that is used to match log records together. The new
Feb 2, 1992 "Quick Reschedule" event creates multiple type 07/08 log
records to be created with the same value of DTOKEN, one
pair for each Reschedule. Because MXG expected only one
pair for each DTOKEN value, MXG's IMSTRAN dataset will be
incorrect (generally overreporting IMSCPUTM, DL/I calls,
etc.) without this change. Now, MXG OUTPUTs the first 08
record (the initial program schedule event), totals the
resources in the subsequent multiple 07 records, and then
OUTPUTs the final 07 record of the set with same DTOKEN.
A "Quick Reschedule" occurs when a message region has run
its maximum number of transactions per program schedule,
finds there are more transactions to execute, AND finds
there is no other program waiting on this message region.
Each 08/07 pair contains the resources consumed by all of
the transactions executed by that schedule, and it has
never been possible to measure the resources used by an
individual "multi-sked" transaction; the best we could
ever do was to divide the total resources by the number
of transactions executed during each program schedule.
Now, that "average" resource per transaction is even more
meaningless, since these multiple schedule records now
have to be summed and divided by a larger total number of
transactions. It would have made much more sense, and we
would not have lost ground in resource measurement, if
IBM had been wise enough to create a new DTOKEN value for
each Quick Reschedule.
Added 1999: Variable SCHEDULE in dataset IMSTRAN flags if
the obs was the scheduled or the rescheduled event.
Thanks to J. Cary Jones, Philip Morris, USA.
Change 9.215 BUILDPD3 (JES3 only) enhancement added in MXG 9.5 had two
BUIL3518 occurrences of 26J2 which should have been 26J3 in both
BUIL3606 of these JES3 members.
Jan 31, 1992
Thanks to Paul Oliver, BHP Information Technology, AUSTRALIA
Thanks to Steve Cavill, SAS Institute, AUSTRALIA
Change 9.214 Support for NPM Release 1.5 added seven new datasets:
EX028CM6 NPMCMEXE - Execute commands
EX028LA1 NPMLANAT - LAN Bridge Attach/Detach
EX028LA2 NPMLANCO - LAN Manager Connect/Disconnect
EX028LA3 NPMLANEX - LAN Bridge Monitor Exception/Resolution
EX028LA4 NPMLANIN - LAN Bridge Interval Resources
EX028LA5 NPMLANST - LAN Start/Stop/Alter Collection
EX028NCP NPMNCPCH - NCP Add/Replace/Delete
FORMATS and some new fields and bit values were added to existing
VMAC28 datasets. IBM publication, "Netview Performance Monitor
Jan 31, 1992 Reports and Record Formats Release 5", SC31-6147-0 is the
new documentation for all of the data records created by
this new release. Thanks again to IBM's excellent vendor
support, documentation was made available in sufficient
time to include support for this significant release in
MXG's production version. Unfortunately, no data records
from the new release were provided for testing, so caveat
user!
Change 9.213 Minor cosmetic change to recognize upper or lower case
READDB2 value for "ALL", and to relocate the %INCLUDE until after
Jan 29, 1992 requests have been parsed for efficiency.
==Changes thru 9.212 were included in MXG PreRelease 9.7==============
Change 9.212 Additional pairing logic for SQL trace report IFCID pairs
ANALDBTR were added for DB2 2.3 IFCIDs 170-171,173-176,178-179,and
VMAC102 183, and these IFCIDs are now decoded in VMAC102.
Jan 27, 1992
Change 9.211 Sites that execute BUILDPDB only six days per week will
MONTHBLD need to locally modify MONTHBLD, as it expects seven day
Jan 27, 1992 per week possible execution. One line in MONTHBLD,
(line 003400, DAY=UPCASE(PUT(TODAY,WEEKDATE3.)); ) was
moved to immediately after line 002100, as this creates
the variable DAY containing the name of the day of week.
With that permanent MXG change in place, the changes you
need to tailor in you own sites copy of MONTHBLD are more
compact and logically clearer. There are two changes to
be made by you:
a. Change IF DAY(TODAY) NE 1 THEN DO; to read
IF DAY(TODAY) NE 1 AND
(DAY(TODAY) NE 2 AND DAY NE 'MON') THEN DO;
This permits MONTHBLD to execute either on the first
day of the month, or on the second day of the month
if the first day fell on Sunday (the day you do not
execute BUILDPDB).
b. Insert after LASTDAY=TODAY-1; the statement
IF DAY(TODAY) EQ 2 THEN LASTDAY=LASTDAY-1;
This causes LASTDAY to contain the date of the last
day of the last month, which is then used to set the
_BEGIN macro value for date selection. Note that as
the _END macro value is TODAY, the selection values
will now be correct whether you execute on the first
of the month or on Monday the second day.
Thanks to Phyllis Reedyk, Witco Corporation, USA.
Change 9.210 Continued enhancement of DB2 reporting added SQL trace
ANALDB2R reports, and many additional internal enhancements:
Jan 26, 1992 1.All WARNING or NOTE messages printed on the log by MXG
now print as MXGWARN or MXGNOTE to clarify their source.
2.Internal macros are now documented with update date.
3.All uses of VMXGSUM use the INVOKEBY parameter to message
which report is being generated ("PMACC01 - ANALDB2R").
4.Selection was consolidated into DB2RSELA macro.
5.DB2DBID macro uses T102S105 and T102S107 (IFCID 105,107)
to build a temporary format which maps hex DATABASE and
PAGESET values to their actual names. Under SAS 5.18,
the INSTREAM DD pointing to temporary sequential space
is required, but under SAS 6.06+, the CNTLIN option of
PROC FORMATS is used to create formats directly from SAS
datasets.
6.Reports now check for the existence of required datasets
(as opposed to just zero observations) and messages now
indicate why reports were not produced.
7.PDB=SMF option (produce DB2 reports directly from SMF)
cannot be used under SAS 5.18 (compiler limit) in a 7MB
region. Messages now tell you how to use READDB2 plus
ANALDB2R instead of PDB=SMF to produce almost all reports
directly from SMF if you are still using SAS 5.18.
Change 9.209 DB2 Trending was not adequately tested. In the second
TRNDDB2A and subsequent week's processing, old data was not even
TRNDDB2S carried forward, and timestamps were not set correctly.
Jan 26, 1992
Thanks to Dave Leeker, Southwestern Bell, USA.
Change 9.208 New ESA 4.2 variables R79AIMPL and R79AOMPL have been now
VMAC79 added to the TYPE79A (subtype 10) dataset for the target
Jan 24, 1992 IN and OUT MPLs respectively.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 9.207 Variable RDRTM in TYPE30 was always missing after Change
VMAC30 9.102 because the test in line 075198 should also have
Jan 24, 1992 tested for SUBTYPE NE 1 to detect the MULTIDD condition.
Thanks to Don Friesen, B.C. Systems, CANADA.
Change 9.206 Variable EXCMNTYP in dataset CICSEXCE (CICS Exceptions)
FORMATS did not describe the exception type because it was kept
VMAC110 in one byte instead of two. In the LENGTH statement, it
Jan 24, 1992 must be $2. instead of $1. Additionally, the $MG110EX
format in member FORMATS should have been '01X:' instead
of the obvious typographical error '02X:'
Thanks to Bill Hess, Belk Stores, USA.
Change 9.205 This code referenced formats $TABSYS and $FORHEX that are
ANALRACF not in the member. $TABSYS has been replaced by $4., and
Jan 14, 1992 $FORHEX (which converted hex strings to numerics) was
replaced an equivalent algorithm.
Thanks to ???, Alm. Brand, DENMARK.
Change 9.204 Dataset RMF72D NOT SORTED message can result if IMACRMFI
RMFINTRV has been used to re-define the startime of your RMF data,
Jan 14, 1992 since STARTIME is both being changed and in the BY list.
Insert:
PROC SORT DATA=RMF72D %VMXGFOR;BY SYSTEM STARTIME;
immediately before the PROC MEANS NOPRINT DATA=RMF72D;
to ensure that RMF72D is always sorted.
Thanks to Bill Stoneberg, National-Oilwell, USA.
Change 9.203 CA7 corruption of TSO/MON READTIME was only partially
VMACTSOM corrected in MXG 8.8 by Change 8.209. That change should
Jan 14, 1992 have also been applied to the second correction of the
CA7 corruption, lines 076500 and 076800.
Thanks to Paul Hill, Midland Bank, ENGLAND.
Change 9.202 Preliminary support for JES3 Monitoring Facility (JMF)
FORMATS type 84 SMF record. There are nine subtypes, and only
TYPE84 subtype 5 has been addressed thus far, and not even all
VMAC84 of the sub-subtypes are yet coded. This change will
Jan 13, 1992 extend over time.
Thanks to Jonathan E. Paley, Massachussets Mutual, USA.
Change 9.201 A cosmetic change. Variable RECNR should have been
VMAC6156 RECNR156 in line 013400.
Jan 13, 1992
Thanks to James F. Cook, CocaCola Company, USA.
Change 9.200 Support for Emc2/TAO (Fischers Totally Automated Office)
FORMATS Release 3.3.0 SMF record. The new release switched the
VMACTAO database reads and writes, but was otherwise implemented
Jan 12, 1992 compatibly. This support also added format MGTAOTC and
decoded three bitstrings into new variables.
Thanks to Joe Aldrich, Army and Air Force Exchange Service, USA.
Change 9.199 This member creates reports for use at IBM's SNAP/SHOT.
ANALSNAP The SNAP/SHOT report is created from MXG's TYPE30_5 data.
Jan 11, 1992 A DASD farm report was created from DMS DSINDEX report.
A report from CA-11 (JEHF Version 2) was developed.
Mantissa run tracking file formats for RMS/BASIC are
provided, and the TMC file was used for tapes (MXG's
TYPETMS separately processes that data). These reports
could save you lots of time if you plan to model your
workload with SNAP/SHOT (and look at TYPETPNS which will
analyze the TPNS log produced by SNAP/SHOT!)
Thanks to John Leath, Fleet Real Estate Funding, USA.
Change 9.198 IMS Fastpath transactions are now supported, thanks for
TYPEIMS the diligent research of the three authors of this very
VMACIMS significant contribution. VMACIMS now creates temporary
VMACIMS datasets IMS5901,03,36,37, and 38 from those subtypes of
Jan 11, 1992 the 59x log record, and TYPEIMS has additional logic at
the end to sort and combine these to create the IMSFASTP
fastpath dataset (and IMS5838 with syncpoint failures.
Not only has this code been in production (IMS 2.2 & 3.2)
for over a year, its output has been validated with IBM's
DBFULTA0, and these author's comments in member TYPEIMS
are an excellent mini-tutorial on IMS Fastpath.
(Usually ANY activity in IMS makes my stomach hurt, as
there just isn't any documentation or help from IBM.
This contribution was done so well that my stomach
feels like it just received a piece of cake! Thanks!)
Thanks to Lars-Olof Thellenberg, Forsta Sparbanken, SWEDEN
Thanks to Goran Zebuhr, Forsta Sparbanken, SWEDEN
Thanks to Sven Agrell, Forsta Sparbanken, SWEDEN
Change 9.197 A sample report using TYPE30_4, TYPE30_5, and TYPE30_D
ANAL30DD datasets to report on all your active ddnames by job.
Jan 10, 1992 The comments in the member describe how to use ANAL30DD.
Thanks to Phil Mason, ANZ Bank, AUSTRALIA
Change 9.196 Support for LLA exits CSVLLIX1 and CSVLLIX2 are added in
ANALLLA this significant user contribution. Member ASMLLA is the
ASMLLA ASM source for the two exits that will capture LLA module
IMACLLA accesses and create a user SMF record. Members IMACLLA,
EXLLAEX1 EXLLAEX1,TYPELLA, and VMACLLA are the MXG members to read
TYPELLA those SMF records and create dataset LLAEXIT. The final
VMACLLA member, ANALLLA, provides some sample reports on LLA. Be
Jan 10, 1992 very careful as these exits can create many SMF records!
Thanks to Ken Williams, ANZ Bank, AUSTRALIA
Thanks to Peter Beer, Amdahl AUSTRALIA
Change 9.195 SAS can write zero-length VB or VBS records to a FILE
IMACFILE statement, and files containing zero-length records may
VMACSMF cause other programs (specifically, DFSORT) to fail. The
Jan 10, 1992 problem was precipitated by MXG's change in VMACSMF to
Feb 9, 1992 PUT a new message to the SAS LOG telling you how many
megabytes of SMF data had been read. In that message
there is // (two skip to the next line on the log).
The site had used IMACFILE to write selected SMF records
to an external file using FILE SMFOUT; PUT _INFILE_;
The SAS log showed "minimum record length 0" to SMFOUT!
The FILE SMFOUT had changed the destination for all PUTs
from the LOG to SMFOUT, causing the MXG message and its
// to be written as a length zero record to SMFOUT!
The real error was in not recognizing that any FILE
statement changed the destination for all subsequent PUT
statements, and the moral therefore is to ALWAYS follow
any FILE/PUT statement that you add to MXG with a FILE
LOG statement to reset the destination for PUTs. The real
error was MXG's failure to reset the log in VMACSMF; that
has been done. Change 9.087 originally discussed the need
for the FILE LOG; statement, and the new "megabytes" note
was added by Change 9.094.
Thanks to Keith Stout, City of Anchorage, USA.
Change 9.194 Support for NOMAD Session Manager SMF record is added by
EXNSMCON this significant user contribution. Three datasets are
EXNSMPRC created: NSMCON, NSMPRC, and NSMTRM, and you specify the
EXNSMTRM SMF record ID in MXG member IMACNSM.
IMACNSM
TYPENSM
VMACNSM
Thanks to David B. Adams, National Life of Vermont, USA.
Change 9.193 Three occurrences of $CHARZB43. should be $CHARZB44. so
VMXGHSM all 44 bytes of the dataset name are captured in the
Jan 9, 1992 MCDDSN variable.
Thanks to Ray Dickensheets, Yellow Freight System, USA.
Change 9.192 User of Amdahl Cache Controllers will thank Dick Sziede
ADOCSPMS for his excellent paper "A Look at Cache Performance Data
Jan 9, 1992 for the Amdahl 6100" which is contained in this ADOC.
The member is not complete, but his discussion of what's
good and what's bad is must reading for SPMS users.
Thanks to Richard R. (Dick) Sziede, PRC Inc, USA.
Change 9.191 Members ADOCDB2 and ADOC102 completely describe each of
ADOCDB2 the variables created by VMACDB2 and VMAC102 in DB2ACCT,
ADOC102 DB2STAT0, DB2STAT1, and all 200 of the T102.... datasets.
ANALDBTR The variable-level documentation is complete, but there
FORMATS is still substantial writing to finish before theses two
VMACDB2 ADOCs are completed. It is the process of documentation,
VMACDB2H however, that uncovers inconsistency in formats, names,
VMAC102 labels, etc., and that has been completed. Additionally,
Jan 12, 1992 some datasets that formerly created multiple observations
per SMF record were revised to create a single obs with
multiple variables, so that the SQL trace logic to match
begin and end would be more straightforward. These notes
identify the highlights of this significant enhancement:
1.Variable QWHSIID was added to DB2ACCT/STAT0/1 datasets to
eventually replace incorrectly spelled QWHSSIID. MXG will
now use QWHSIID for IFCID variable in 100,101 and 102.
Both variables continue to exist in DB2ACCT/DB2STATn for
backwards compatibility.
2.Format MGDB2ID replaced with MGDB2II.
3.DB2 database "Object IDs" (PSID,OBID,DBID,ISOBID) are all
now consistently $CHAR2 with format $HEX4, and the labels
are now consistent and accurate. Seven variables had to
be changed from numeric to character: QW0023PD,24PD,25PD,
44KD,44KP,143PS, and 144PS.
4.SQL statement type exists in two different formats. A one
byte character value is found in IFCIDS 59-62 and 64-66
that is decoded by an expanded MGD062S format. A four
hex digit numeric value is found in 124, 145, and 145
IFCIDs that is decoded by an expanded MG145S format.
5.Variable QW0032AR should not have existed; QW0032FT is
the name of the field (QW0032AR is an EQU value!).
6.Variable QW0145TS was changed from numeric to $CHAR8 and
formatted $HEX16 so all 'PRECOMPILER*TIME*STAMP' fields
(in IFCIDs 53,58,59,60,61,64,65,66)are now character.
If I can find out how to decode this timestamp (a hex
value of '148CDFEF19AC29AC'X, for example), all these
variables will be decoded into numeric datetime values!
7.Variable QW0063HL was not kept but should have been, and
is formatted by new $MGD063H.
8.Variable QW0063OT is now formatted $HEX2. The MGD060O
format formerly used did not correctly decode the multi
valued bit fields, and is no longer used.
9.MXG 9.5 created observations for new IFCIDs 126-139 and
170-194 even without any 102 records because the OUTPUT
statement for these IFCIDs was missing in VMAC102.
10.Datasets T102S018,T102S053,and T102S058 formerly had one
or two observations per SMF record, one for index and one
for data. This change eliminates the second record by
putting the data portion counts in QW00.... variables,
and by putting the index portion counts in QW0I.... names
so that pairing these three records with their partners
in ANALDBTR can be more easily/accurately accomplished.
Variable SDSNUM, a sequence counter, is thus no longer
required in these datasets and has been dropped.
11.ANALDBTR was revised to pair 044/045 data, to create
additional datasets (S018S018 and S058S058) for unpaired
ends, and to keep only the first segment of 063 data,
all in support of SQL trace reporting.
12.VMAC102 was revised to create single observations for
IFCIDs 13,15,and 17. Previously, one observation for each
predicate was created. Now, the up-to-ten predicates are
stored is sets of variables. The first set is prefixed
QW0013, the second set QW0A13, the third QW0B13, etc.
13.VMAC102 was revised to create single observations for
IFCIDs 58-62 and 64-66; previously they could have one
or two observations describing DATA and/or INDEX activity
due to SQL statements, but now the QW00nn variables have
the data activity, while new variables QW0Inn contain the
index activity. This made matching begin and end of SQL
events much simpler in ANALDBTR.
14.The only IFCIDs that create multiple observations now are
22 (one miniplan per table per subselect block), 63 (one
per each 200 bytes of SQL statement text), 126 (one per
each index used to obtain candidate RIDs, up to 16), 145
(one per Audit Log Table), 148 (only for distributed
allied agents, R8O one per conversation, R9O, one per
location), and 191 (one per parse, up to 5).
14.VMAC102 and VMACDB2 labels and formats were revised to
be consistently spelled, etc.
15.ANALDBTR, the routine which matches pairs of trace data,
is now a %MACRO which invokes the old-style _nnnPAIR
macros. This change added flexibility to its use and its
invocation inside %ANALDB2R reporting.
16.VMACDB2H now creates variable QWHDYES, indicating that
there was a distributed header, and which is now used in
VMACDB2 to create new variable THREADTY (formatted with
$MGDB2TT) to describe the type of thread (Allied, Allied-
Distributed, DBAT (Database Access) or DBAT-Distributed).
Thanks to Debby Meister, Loews Corporation, USA.
Change 9.190 1.CICS 3.2.1 statistics records were not fully supported.
VMAC110 STID=63 (CICTM) record contains sixteen tables, but only
Dec 27, 1991 the first twelve were kept by MXG prior to this change.
Seven records (that contained only totals) are no longer
created by IBM (because they are redundant with their
corresponding detail record) and thus these MXG datasets
always contain zero observations: CICTST(STID=5),CICTCT
(35),CICLSRT(38),CICLSRFT(41),CICCONST(53),CICTCLT(59),
CICFCT(68),CICCONMT(77). (Their detail dataset names
are minus the ending "T".)
2.IBM added two undocumented bytes in the STID=57 (CICSDS)
record, which corrupted the CPU times in CICSDS dataset,
and in the CICINTRV, etc., datasets created from it. The
two bytes added for alignment (immediately before the
repeating DSECT) are not documented in DFHGSGDS. And in
an unrelated change, CICS APAR PN02625 removes two filler
bytes following DSGNTCB, but did not update the STIVERS
version indicator, so there is no direct way to know what
length record to expect! As a result, MXG protects for
none, two, or four filler/alignment bytes in this record.
3.IBM documentation for statistic record STID=49 is wrong.
DSECT DFHA13DS describes STID=49 as containing 39 bytes,
but actual data records have STILEN=40; a one-byte field
(reserved) following A0013BFC is not described in that
DSECT (the only IBM documentation of the record!). IBM
will correct their error (eventually) with a doc APAR.
How can the record disagree with the DSECT you might ask?
Because IBM records are built by PL/S DSECTS, but IBM
documents with ASM DSECTS that are never actually used!
4.Two occurrences of broken CICS 3.2.1 records were found
with only 80 bytes of data. MXG new detects the short
record, messages to the log, and avoids STOPOVER ABEND.
Thanks to Lee F. Johnson, Talbots Systems Center, USA.
Thanks to Bruce W. Galle, Talbots Systems Center, USA.
Change 9.189 Processing VVDSs previously failed with a USER ABEND 666
ASMVVDS when ASMVVDS tried to read a VM system volume that was
Dec 20, 1991 online to MVS (because the volume does not have a normal
VTOC/VVDS). Now, instead of the ABEND, the program puts
out a message that the OBTAIN macro failed for that UCB
(DEVNR), and then continues to process additional UCBs.
Thanks to Chris Taylor, First Wachovia Bank, USA.
Change 9.188 VVDS support skipped over VVRTYPE='D5'X because the test
VMACVVDS in line 017100 was mistyped as ='D5' instead of ='D5'X.
Dec 20, 1991
Thanks to Chris Taylor, First Wachovia Bank, USA.
Change 9.187 Support for ASTEC Version 1.5. Several new fields were
VMACDMON added (incompatibly) to the SMf record. This support was
Dec 16, 1991 actually shipped in MXG 9.5, but this change was not in
member CHANGES of that library.
Thanks to Joseph Faska, Depository Trust Corporation, USA
Change 9.186 VPD type E records caused STOPOVER ABEND because variable
VMACVPD VPDRSVR2 should have been input as $CHAR11. instead of
Dec 16, 1991 $CHAR12. (line 014200).
Thanks to Jim Nicholas, Mead Data Central, USA.
Changes thru 9.185 were contained in MXG PreRelease 9.5, Dec 1, 1991
Change 9.185 Change 9.164 was a major restructuring of ANALDB2R, and
ANALDB2R had not been sufficiently tested for all DB2 reports.
ANALDBTR Using SAS 6.07 (and reading all of the SAS messages on
Dec 1, 1991 the log!) not only corrected UNINITIALIZED variables, but
the 6.07 feature which warns of unreferenced variables in
the KEEP= list caught a number of mispellings in some of
the type 102 trace reports. SAS 6.07 furthermore found
a syntax error that SAS 5.18 had accepted! This was an
another superb contribution from Koln.
Thanks to Siegfried Trantes, Gothaer Versicherungsbank VVAG, GERMANY.
Change 9.184 Several important variables have now been added to the
EXRMFINT TYPE70 and RMFINTRV datasets for MVS/ESA and PR/SM data.
EXTY72 1.If PR/SM data section is found in type 70 (PR/SM, MLPF,
RMFINTRV or MDF) records, both the Partition Dispatch (PDTM) and
VMAC7072 Effective Dispatch (EDTM) are carried into the TYPE70
Nov 28, 1991 dataset. MXG continues to calculate PCTCPUBY based on
Sep 21, 1994 Partition Dispatch Time for consistency, but now provides
PCTCPUEF, based on Effective Time, which matches the RMF
reported "CPU Busy" under PR/SM. The individual LCPUs
times are in new variables CPUPDTM0-8, CPUEDTM0-8, and
totals across all LCPUs are in CPUACTTM and CPUEFFTM.
2.RMFINTRV was enhanced to provide the three new CPU times
(HPT,IIP,RCT) in each set of workload variables and their
total for each workload. New variable BATCPU is the sum
of existing BATTCB,BATSRB plus BATHPT,BATIIP, and BATRCT.
Total CPU times are also kept in CPUTM, CPUHPTTM,CPUIIPTM
and CPURCTTM variables.
Next paragraph revised in 1994:
Additionally, in each workload, the memory is now
calculated (Central+Estore) from ACTFRMTM in bytes in
BATMEMR, CICSMEMR, etc. (but recall that ACTFRMTM does
not include logically swapped pages nor the nucleus, LPA,
nor CSA). This is a much better indicator of memory
utilization than AVGMEMSZ, which is based on MSOUNITS as
discussed in prior newsletters. And the total memory of
all workload's memory is variable TOTMEMR.
3.See the MVS Technical Note on CPURCTTM in Newsletter 21.
It is unmodified in the TYPE72 dataset, so you can see
how wrong it is, but it is now subtracted from CPUTM in
EXTY72 (temporarily, until a PTF exists). This will
prevent negative overhead calculations in RMFINTRV due
to the wrong value of CPURCTTM until fixed by IBM.
Change 9.183 DB2 variable QWHSSTCK is now formatted DATETIME22.3 so as
VMACDB2 to show the milliseconds. Sites using DB2 trace found
VMAC102 the increase in printed resolution useful for tracking
Nov 28, 1991 detail event sequences.
Thanks to Siegfried Trantes, Gothaer Versicherungsbank VVAG, GERMANY.
Change 9.182 Heavy validation of TYPEIMS from MXG 9.2 uncovered still
VMACIMS additional idiosyncracies and undocumented Enqueue record
TYPEIMS flags in this significant contribution. In VMACIMS,
Nov 28, 1991 35x records with ENQFLAG=04C or 08C and FLAG2=08 are now
added to IMS35P. This site uses Terminal-Databases with
SPA-information and a Code-Information in the INPUT msg
to jump from one transaction to another, which are now
supported by additional logic, even when outputs do not
match inputs. Compare criteria using LOGONID and ODEST
do not work if there is no external LOGON-processing,
(DEQTIME was always equal to OGUTIME), but by using
CLINENR instead, and revising the MERGE logic, this
case appears to be now protected as well. However, as
past history indicates with IMS, what works at several
sites may not always work at all sites, so please verify
your output if you must process IMS log data.
Additional cosmetic changes were a new message that tells
you how many megabytes of IMS log data MXG read in, and
if invalid 035x records are found, a hex dump of the
record is printed on the log for Merrill debugging!
Thanks to Siegfried Trantes, Gothaer Versicherungsbank VVAG, GERMANY.
Change 9.181 1.IBM APAR PL83370 adds new field STATCTM1 to CICS/ESA type
IMACICDB 110 DBCTL segment. However, since the APAR does not say
VMAC110 where the field was added, I had to assume it's at the
Nov 27, 1991 end of the known fields (in the 96 skipped bytes).
This new field captures the IMS CPU time in DRA thread
TCBs (but not time spent in the control region, as DBCTL
cannot capture that CPU time). Originally, IMS 3.1.0 did
not provide CPU time for threads because the original
design provided for an alternate method called "commit-
continue"; late in the release, a decision was made not
to support the commit-continue, and nothing was provided
in its place. Now, STATCTM1 has been provided to capture
the CPU time spent in the DRA thread TCB from the begin
of schedule request to the release of the PSB (any SYNC
POINT that also says 'TERMINATE TCB'), using existing
STIMER and TTIMER cancel code in DRA.
STATCTM1='ELAPSED UOR*CPUTIME FOR*THREAD TCB'
2.This APAR also corrects the value in STATDBIO: IBM code
existed to catch the SLOG22/SLOG23 pair (OSAM buffer
handler) and count it as one Database I/O, but there was
no code to catch the SLOG24/SLOG25 pair (VSAM buffer
handler). The DBIO field is also copied into the IMS 07
log record, so now that field will also be valid.
3.The APAR text also states that the new CPU time, STATCTM1
is added to the IMS log Type 07 record as field DLRTIME,
but I need DSECTS to find out where, before I can update
TYPEIMS (and there'll be a change for TYPECIMS too!).
Thanks to Philip Schwartz, United Parcel Service, USA.
Change 9.180 A volume with 1,260,487,800 bytes capacity (tracks times
VMACDCOL formatted track capacity) was reported by DCOLLECT as
Nov 26, 1991 having a capacity of only 1,260,487,680, a loss of 120
Feb 10, 1992 bytes. The error was thought to be truncation because
the variable was stored in 4 bytes, and in Nov, these
variables were changed to be stored in 8 bytes:
DCDALLSP DCDSCALL DCDUSESP DCVALLOC DCVFRESP DCVLGEXT
DCVVLCAP UBDSIZE UMALLSP UMDSIZE UMRECSP UMUSESP
Now, the truth is known, and there was no MXG error. The
DCOLLECT data field is in kilobytes and not bytes, and
thus the values reported by DCOLLECT will be the nearest
multiple of 1024 bytes that is smaller than the true
value. The extra 120 bytes exist on the volume, but will
never be reported by DCOLLECT!
Thanks to Terry Duchow, Minnesota Mutual Life, USA.
Change 9.179 PR/SM TYPE70PR summary PDB.ASUM70PR and trending TRND70PR
ASUM70PR datasets were correct if NRPRCS (number of partitions
TRND70PR running or defined) was equal to PARTNCPU (number of
Nov 25, 1991 physical processors), but PCTLnBY calculations were wrong
otherwise, and produced logical busy percentages instead
of percent of physical busy that was intended. Now, the
calculations use PARTNCPU so the PCTLnBY measures real
hardware CPU utilization of your PR/SM or MLPF box.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 9.178 DB2 2.3 SMF type 102 records were changed incompatibly on
VMAC102 Nov 12. (DB2 2.3 just became available Oct 28!). Fields
Nov 25, 1991 were added to IFCIDs 28, 96, 140-142, and 145 (and are
now supported by MXG). IBM provided documentation that
was good and timely for this change.
Change 9.177 MXG PreRelease 9.4 produced zero observations in DB2data
VMACDB2H sets, with no error message. A last-minute "cosmetic"
Nov 25, 1991 change to label the new 2.3 variables corrupted the code.
(The last 32 lines, starting at line number 01860000 must
be moved to after line 005500).
Thanks to Ted Garner, First Union, USA.
Change 9.176 IMS Abend condition codes were always blank, and because
TYPEIMS Change 9.106 was incorrectly located in MXG 9.3, the
Nov 28, 1991 resources for multi-trans were incorrect.
Thanks to Pete Shepard, Ashland Oil, USA.
--Changes thru Change 9.175 were in MXG PreRelease 9.4 dtd Nov 15, 1991
Change 9.175 BUILDPDB has been significantly enhanced. DB2ACCT/STAT
BUILD518 datasets are now added to your PDB from type 100/101 SMF
BUILD606 records. SAS 5.18 users should be able to add many more
BUIL3518 SMF records to their PDB before a SAS 344 Compiler error
BUIL3606 is encountered. However, this change is INCOMPATIBLE for
BUILDPDB SAS 5.18 sites; a new DD statement is required in the JCL
VMACDB2 for the BUILDPDB/3 step (only for SAS 5.18):
VMACSMF
Nov 15, 1991 //SMFTEMP DD UNIT=SYSDA,SPACE=(CYL,(20,20))
An additional INCOMPATIBILITY exists for all BUILDPDB/3
sites that have added DB2 processing to their PDB (this
would have been done by editing members EXPDBINC,EXPDBVAR
EXPDBCDE and EXPDBOUT members as described on pp 134ff of
the MXG Supplement). If you have added DB2 processing,
it must be removed or BUILDPDB will syntax error.
This redesign was caused because the "vanilla" BUILDPDB
in MXG 9.4 could not be compiled under SAS 5.18. The
additions for MVS/ESA, CICS/ESA, etc., added iterative DO
statements, causing a SAS 5.18 "344 Compiler Error". To
circumvent this error, now, (for SAS 5.18 only), MXG
writes RMF 71 and 73-78 records to the (new) SMFTEMP file
while reading your SMF input, and then executes a second
data step to process that small SMFTEMP file. (Type 70,72
records are not split out, because type 30 processing
needs IOCCOEFF to calculate EXCPRMF!). Splitting the
data step reduced the number of iterative DO statements,
avoiding the "344 Error" for sites which have added other
SMF record processing (using the MXG Exit Facility, pages
134-140 of the MXG Supplement). The circumvention that
was previously described in Change 7.038 (in CHANGE07) is
no longer applicable (except for the possible use of the
XMAC7072 member), since MXG has split the RMF processing
out. Since RMF data is not large volume (perhaps 9MB
per day per system at 15 minute intervals), there is very
little increase in processing time.
Unfortunately, this elimination of the 344 SAS error may
only serve to uncover yet another SAS 5.18 limitation. A
160 SAS error occurs if the total length of all variables
in a SAS data step exceeds a SAS 5.18 internal limit, and
there's NO circumvention for the 160 error. If received,
you must remove some of your additional SMF records from
the EXPDB.. members, and instead use IMACFILE member to
write your SMF records the SMFTEMP DD, which can then
be processed in a subsequent step of your job. (Or, you
can use SAS 6.06/6.07 for just the BUILDPDB step and use
a LIBNAME statement to build your PDB datasets in SAS
version 5.18 format).
Note there is no change for SAS Version 6; the compiler
limit does not exist in SAS Version 6, and BUILDPDB logic
uses %MACROs to detect you are executing under Version 6,
and MXG processes all SMF data in one pass; there is no
need for the SMFTEMP DD name under SAS 6.07/6.07.
Adding DB2 processing had been desired for some time, but
because of the 5.18 problems, it could not be easily done
until now.
Change 9.174 Divide by zero error occurred for the type 79 record for
VMAC79 the interval in which the clocks were set back this Fall!
Nov 14, 1991 The record had a duration of 0 seconds after the operator
changed the clock. Now, divides by DURATM are checked to
be non-zero before the divide. Also, RMF 3.5.1 caused a
STOPOVER on type 79 subtype 3 that is now protected.
Thanks to Fred Fettinger, Rockwell Graphic Systems, USA.
Change 9.173 Support for LEGENT's MIM (Multi-Image Manager) user SMF
EXTYMIM records was added by this user contribution. A single
IMAMIMC dataset, MIMTAPE, is created from this record.
TYPEMIM
VMACMIM
Nov 14, 1991
Thanks to Doug Drain, National City Bank, USA.
Change 9.172 Support for Softtool Corporations's CCC (Change and
ANALCCC Configuration Control software is added by this user
EXTYCCC contribution. Example reports are also provided, but
IMACCCC will require an installation format for processor power.
TYPECCC
VMACCCC
Nov 14, 1991
Thanks to Sue Swayne, Inland Revenue (UK), Worthing, ENGLAND.
Change 9.171 The collection of RACF reports added by change 9.064 had
ANALRACF invalid concatenation symbols (because the code went
Nov 12, 1991 from MVS to a PC and back!). The reports were also
slightly revised and enhanced.
Thanks to Duncan McKellar, Inland Revenue (UK)
Thanks to Neil Campbell, Inland Revenue (UK)
Thanks to Dave McLaughlin, Inland Revenue (UK)
Change 9.170 FTP SMF records produced no observations because test to
VMACFTP ensure there was data was incorrect. Eleven occurrences
Nov 12, 1991 OFFDATA+(NRDATA*LENDATA) LE LENGTH THEN ...
must each be changed to
OFFDATA+(NRDATA*LENDATA) LE LENGTH+1 THEN ...
Thanks to Kueller, Spardat Wien, AUSTRIA.
Change 9.169 TYPE59 variable QUEUTIME was not formatted DATETIME21.2,
VMAC59 nor was it set to stored length of 8 bytes, but now it
Nov 12, 1991 is!
Thanks to Siegfried Trantes, Gothaer Versicherungsbank VVAG, GERMANY.
Change 9.168 A CICS region ABEND caused Landmark to write a "trashed"
TYPEMON8 record that contained invalid values for the offset to
Nov 11, 1991 variable segments. Because MXG did not validate that
the offset value was actually in the record, MXG failed
(with "INPUT STATEMENT EXCEEDED RECORD LENGTH"). There
are three DO statements that need to be protected. Find
the following 3 DO statements in TYPEMON8, and insert
the four lines of protection preceding the existing DO
statement:
IF FILECOL+FATNUM*TAFATLEN GT LENGTH+1 THEN D0;
PUT 'BAD RECORD FOUND AND DELETED '; LIST;
DELETE;
END;
DO FILESEG=1 TO FATNUM;
IF UATCOL+UTNUM*TAUATLEN GT LENGTH+1 THEN DO;
PUT 'BAD RECORD FOUND AND DELETED '; LIST;
DELETE;
END;
DO USERSEG=1 TO UTNUM;
IF MROCOL+MRONUM*TAMROLEN GT LENGTH+1 THEN DO;
PUT 'BAD RECORD FOUND AND DELETED '; LIST;
DELETE;
END;
DO MROSEG=1 to MRONUM;
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
Change 9.167 Support for Codework Software's SNAPAD-MVS product user
EXSNAPAD SMF record. SNAPAD lets mainframes talk to X.25 packet
IMACSNAP switching networks. Feb 20, 1992: This code has now
TYPESNAP been tested and verified, superceeding the note in this
VMACSNAP change printed in Newsletter TWENTY-ONE.
Nov 10, 1991
Thanks to Dennis Uy, Asian Development Bank, PHILIPPINES.
Change 9.166 MXG incorrectly calculated Full Duplex line utilization
VMAC28 PCTBUSY. For half duplex, the calculation was correct.
Nov 10, 1991 Since a Half Duplex line has only one set of buffer for
both send and receive, MXG summed the send and receive
bytes and divided by the send (primary) line speed:
PCTBUSY=800*(BYTSPRSC+BYTSSCPR)/(NCPTM*NPMPLS);.
(The 800 is used because line speed is in baud).
But for a Full Duplex line, there are 2 sets of buffers,
one for send and the other for receive. Thus there are
two separate utilizations that can be calculated. Since
the purpose of PCTBUSY is to identify utilization, and
since the line is out of speed when either its send or
its receive utilization is 100%, MXG now calculates the
PCTBUSY for full duplex as the Maximum of the send or
receive (primary or secondary) utilization:
PCTBUSY=MAX(800*BYTSPRSC/(NCPTM,NPMPLS),
800*BYTSSCPR/(NCPTM,NPMSLS));
MXG's previous calculation for Full Duplex turned out to
be the average of the send and receive utilizations, and
thus underreported the typical utilization in which one
direction predominates.
Thanks to Lee Lik Cheung, DBS Bank, SINGAPORE.
Change 9.165 Support for LEGENT's LANSPY component of NETSPY 4.1 that
EXNSPYLF captures LAN resources and responses in five new MXG
EXNSPYLG datasets. LANSPY creates record segments even when
EXNSPYLL there was no activity on the LAN, but MXG only outputs
EXNSPYLR observations if the activity counts are non-zero (the
EXNSPYLS decision logic is located in the Exit member EXNSPY..).
VMACNSPY This support has been tested with actual LANSPY data,
Nov 10, 1991 thanks for excellent vendor support from Legent.
Change 9.164 This change is primarily internal in that most user will
ANALDB2R not explicitly see these changes, but they are under the
READDB2 cover significant enhancements to DB2 processing. In
VMAC102 VMAC102, new macros of the form _LTRccnn now are defined
Nov 8, 1991 that are the list of the IFCIDs in each trace class.
These list macros are then used by the new READDB2 macro
(invoked by ANALDB2R when PDB=SMF is specified) so that
MXG only processes the IFCIDs that are needed, based on
the reports you have requested. You no longer have to
manipulate member IMAC102 to process trace records, and
this re-design should execute significantly faster.
Note that READDB2 can be invoked independently if you
wish to create datasets from subsets of DB2 data; it
is self documenting. The old keyword parameter names
for trace class selection (DB2TC1-DB2TC16, etc.) do not
exist (they were replaced by the new TRACECLS parameter),
and you will get "KEYWORD PARAMETER NOT DEFINED" errors
if your ANALDB2R invocation uses the old names.
Change 9.163 Trend Data Base updates. DB2ACCT, DB2STAT0, DB2STAT1
TRNDDB2A have been updated to add some new DB2 2.3 variables for
TRNDDB2S identification, if they exist (i.e., when you have DB2
TRND70 2.3 data. New member TRND70 trends RMF TYPE70 dataset.
Nov 8, 1991
Change 9.162 Cosmetic (but then looks do count!). TYPE22_A bit maps
VMAC22 of 3390-3 status should have been formatted $HEX2./$HEX4.
Nov 8, 1991 Now they are correctly formatted to describe status bits.
Thanks to Harry Price, Florida Power and Light, USA.
Change 9.161 CICS/ESA only, DBCTL EMP data only. In IMACICDB, the +98
IMACICDB after STATBFWT should have been +100 (but this would have
VMAC110 only caused a problem if you had additional user data
Nov 8, 1991 after the DBCTL EMP - if you did and decoded that user
data you will have been off by two bytes in your code).
However, IBM has added a new field in those former +100
bytes, so this change in IMACICDB replaces the old +98
with STATUSSN PIB4.
+96
and adds a label STATUSSN='USSN*NUMBER'. In VMAC110, the
new variable is added to the KEEP= list for CICSTRAN.
Thanks to Barry Pieper, First Bank Minneapolis, USA.
Change 9.160 MXG 9.3 only, VMXGVTOF processing of ASMVTOC output will
VMXGVTOF cause "Invalid data for STARTIME" because the variables
Nov 6, 1991 UNITADDR, UCBTYPE and STARTIME (added by Change 9.099)
were off by one byte. The input @151, @154, and @158
for those three variables must be @152, @155, and @159.
Thanks to Normand Poitras, Teleglobe Canada, CANADA.
Change 9.159 A potentially serious error in VTOC/VTOF processing (only
VMXGVTOC under SAS 5.18, not under SAS 6.06+) has been found. The
VMXGVTOF error appears to have been introduced in MXG 7.2 (October
Nov 6, 1991 1989!). If you have this error, dataset VTOCLIST will
describe only the space used by the first three extents!
You have the error if VTOCLIST variable NREXTNTS (extent
count in the DSCB1) is greater than variable NUMEXT (MXGs
count of extents). The logic error is the location of
the CALL SYMPUT; it is now known that under SAS 5.18 the
CALL and STOP must be located after the SET statement for
the below logic to have ever worked:
DATA _NULL_;
POINT=1;
CALL SYMPUT('MXGOBS',PUT(NOBS,7.0));
STOP;
SET DSNAMES POINT=POINT NOBS=NOBS;
RUN;
%IF &MXGOBS EQ 0 %THEN %LET I=11;
Because the CALL was mislocated, &MXGOBS was always zero,
causing MXG to prematurely terminate extent processing.
(Under SAS 6.06, it turns out, the logic worked!). But
the following logic is more straightforward and has now
replaced the above logic in VMXGVTOC and VMXGVTOF:
DATA _NULL_;
IF EOF THEN CALL SYMPUT('MXGOBS','0');
ELSE CALL SYMPUT('MXGOBS','1');
STOP;
SET DSNAMES END=EOF;
RUN;
%IF &MXGOBS EQ 0 %THEN %LET I=16;
Additionally, the %DO statement twenty lines before this
code was changed to 15 instead of 10 (which corresponds
to changing the %LET I= value from 11 to 16), because it
is theoretically possible to require up to fifteen passes
of the extent merge (I've not seen more than two needed).
The actual change in MXG is more extensive; in addition
to the above logic changes, NREXTNTS is now compared to
NUMEXT and an error message produced on the log if data
has been lost (and some of the work dataset names used
in the matching process were renamed to make diagnosis
of any future problems more tractable).
Thanks to Joseph Rannazzisi, Brooklyn Union Gas, USA.
Thanks to Al Acosta, Brooklyn Union Gas, USA.
Change 9.158 The NETVIEW VPD record type "E", end subrecord STOPOVER.
VMACVPD Variables VPDRSRV1 and VPDDCCAL must be $CHAR8. instead
Nov 5, 1991 of $CHAR12. Offset for VPDDCCAL and VPDRSRV2 must be 86
and 94 instead of 90 and 102. Additionally, informat for
VPDRECNT, VPDPUCAL, and VPDDCCAL were changed from $CHAR8
to ?? 8. so they are changed from character to numeric.
Thanks to Jim Nicholas, Mead Data Central, USA.
Change 9.157 Two DCOLLECT variables, DCDLBKDT in DCOLDSET, and UMLBKDT
VMACDCOL in DCOLMIGS, were previously $CHAR8. (because IBM did not
Nov 5, 1991 choose to document the internal contents, and test data
used for MXG validation had only zeros in those fields.)
Both variables are now changed from character to numeric;
this change may cause a problem if you combine the DCOL..
datasets from before and after the change, but the long
term benefit of having the correct field name and format
out weight the short term impact. Furthermore, BEFORE
and AFTER datasets can be combined while deleting the
previous character variable with simple logic:
DATA DCOLDSET; SET OLD.DCOLDSET (DROP=DCDLBKDT)
NEW.DCOLDSET ;
Thanks to O. V. Hanger, A. C. Nielsen Co., USA.
Change 9.156 DB2 2.3 final validation and documentation found several
VMACDB2 changes, mostly cosmetic, were needed.
Nov 5, 1991 1.DB2ACCT/DB2STAT1 variables QTXABLLM,INLM,IOLM,SALM,SELM,
and SPLM were deleted, as they were completely redundant
with decoded values of QTXAPREC. They had been used in
tests in ANALDB2R, but those tests were replaced with the
explicit tests for values of QTXAPREC. Also, variables
QTXAILMT and QTXANRUN are now set based on bit tests (the
previous tests for '80'X and '40'X were incorrect). Also
variables QTXACHUS and QTXACLMT are now format TIME12.2.
2.DB2STAT0 variable QLSTBRBF needed asterisks in its label.
Variables QWS4ASCB and QWS4ASID are now kept, variables
QWS4EJST and QWS4SRBT are formatted TIME12.2. The twenty
address space variables (prefix QWS1,QWS2,QWS3,QWS4 and
suffix ASCB,ASID,EJST,PROC,SRBT) labels now name each of
the address spaces, and MXG now stores the data for each
address space consistently in these prefixes (in spite of
IBM's inconsistent use of the 3rd and/or 4th buckets!):
QWS1 - Master, or system services address space
QWS2 - DBM1, or data base services address space
QWS3 - IRLM, or inter-region lock manager address space
QWS4 - DDF, or distributed data facility (values will
be missing if no DDF).
Change 9.155 TYPE22_7 variables CHOWNED and CHONLINE are set in lines
VMAC22 lines 079600 and 079700, but were not reset if bit test
Oct 17, 1991 was not satisfied, causing values to be propagated. Now
ELSE CHOWNED=' '; and ELSE CHONLINE=' '; were inserted
respectively.
Thanks to Bruce Read, Attorney General's Department, AUSTRALIA.
Change 9.154 NETSPY variables STARTIME and STOPTIME are reversed in
VMACNSPY lines 089100 and 089200. STOPTIME is based on DTEE/TMEE
Oct 17, 1991 and STARTIME is based on DTES/TMES.
Thanks to Lois Robinson, M & I Data Services, Inc, USA.
Change 9.153 Type 6 "INPUT STATEMENT EXCEEDED RECORD LENGTH" results
VMAC6 from LEGENT's Bundle product record which is logically a
Oct 16, 1991 normal External Writer record, but because the record now
contains the characters "BU" instead of the normal zero
in the SUBS field, the shorter EXTW record format was not
recognized by MXG. Now, SUBS=49892 ("BU" as PIB2.) sets
SUBSYS='BUND', and the two tests for 'EXTW' are extended
to treat 'BUND' as 'EXTW', thereby adding support for
the Bundle product in MXG.
Thanks to David Kyle, Dominion Bankshares, USA.
Change 9.152 Support for new Tape Device 3490E added. In MXG datasets
VMACEXC2 TYPE434, TYPE30_V, TYPE30_4, TYPE30_5, TYPE30_6, TYPE40,
VMACUCB variable EXCP3490 is created, in the TYPE30_n datasets
VMAC30 variable IOTM3490 is created, and in datasets TYPE434
VMAC40 and TYPE30_N variable TAPE3490 is created. Change 9.002
VMAC434 created a new value for the variable DEVICE, but did not
Oct 9, 1991 create these new variables. Because the 3490E format is
Aug 19, 1995 completely different than 3480s or the earlier 3490s, it
was consistent with MXG treatment of devices to create
these three new variables in the appropriate datasets.
MXG Internals Architecture Note for the record:
Addition of new device type in MXG requires knowledge of the values
of device class DEVCLASS and device type DEVTYPE returned by the IBM
macro DEVTYPE so that the new variables EXCPnnnn, IOTMnnnn, (and for
tape devices, TAPEnnnn) can be created. The changes that are then
made in MXG (not by you - these are the changes that MXG made when
an MXG Change states "Support for new DASD/Tape Device nnnn added"):
For new DASD device:
a) VMACUCB - create new value for DEVICE within device class.
b) VMACEXC2 - create new DO group within device class.
IF DEVTYPE=0hhX THEN DO;
EXCPnnnn=SUM(EXCPnnnn,EXCPCNT);
IOTMnnnn=SUM(IOTMnnnn,IOTM);
END;
c) VMAC434 - Label EXCPnnnn
d) VMAC40 - Label EXCPnnnn
e) VMAC30 - Label EXCPnnnn, IOTMnnnn
- Add IOTMnnnn to TIME12.2 format list.
f) IMAC30IO - Add EXCPnnnn, IOTMnnnn to respective macros.
For new Tape device:
a) VMACUCB - create new value for DEVICE
b) VMACEXC2 - create new DO group:
IF DEVTYPE=0hhX THEN DO;
EXCPnnnn=SUM(EXCPnnnn,EXCPCNT);
IOTMnnnn=SUM(IOTMnnnn,IOTM);
END;
- create new counter within device class tests:
IF DEVTYPE=0hhX THEN TAPEnnnn=SUM(TAPEnnnn,1);
c) VMAC434 - Label EXCPnnnn,TAPEnnnn
- Keep TAPEnnnn
d) VMAC40 - Label EXCPnnnn
e) VMAC30 - Label EXCPnnnn,IOTMnnnn,TAPEnnnn
- Keep TAPEnnnn
- Add IOTMnnnn to TIME12.2 format list.
f) IMAC30IO - Add EXCPnnnn, IOTMnnnn to respective macros.
g) IMACPDB - Add TAPEnnnn to the _PDB30_4 and _MAXSTP macros.
- Then, in the PROC MEANS logic that follows, the
X10 in the DROP= list must be changed to X11, and
X11 must be added after the X10 in the SUM= list.
In addition, member FORMATS must be scanned for all occurrences
of the previously-newest-device-of-this-class. (Eg, when adding
support for 3590 tape drive, locate all occurrences of 3490 in
all formats). Only one or two formats use the IBM DEVCLASS and
DEVTYPE values (eg., '8083' for 3590s); those you can directly
update. The rest (currently, EREP and ZARA) have their own, non-
standard table of values, and their vendor must be contacted to
determine what value they chose.
This note was revised August 19 and again September 22, 1995.
Change 9.151 Support for new DASD Device 9345 added. In MXG datasets
VMACEXC2 TYPE434, TYPE30_V, TYPE30_4, TYPE30_5, TYPE30_6, TYPE40,
VMACUCB variable EXCP9345 is created, and variable IOTM9345 is
VMAC30 created in the TYPE30_n datasets. The new device has a
VMAC40 tracksize of 46456 (after R0 is on the track), with 15
VMAC434 tracks per cylinder, and 1440 cyl per vol on Model 1 or
Oct 9, 1991 2156 cyl per vol on Model 2.
Change 9.150 Cosmetic changes. Comments describing the expected sort
ANALCICS order were clarified, and the second occurrence of
Oct 8, 1991 TASCPUTM=0; was deleted.
Thanks to John Chapman, British Gas, ENGLAND.
Change 9.149 DB2 report PMACC01 could produce zeros in two places due
ANALDB2R to MXG typing errors. The two lines now reading
Oct 8, 1991 GSWS=QBACSWS; and L2SWS=QBACSWS; should read
GSWS+QBACSWS; and L2SWS+QBACSWS; respectively.
Though not causing an error, lines 012560-012970 (IF _N_
.... END;) were deleted, as those variables were already
initialized by the RETAIN statement.
Thanks to Susan Marshall, SAS Institute Europe, GERMANY.
Thanks to ???, ORDA-B, BELGIUM.
Change 9.148 Cosmetic enhancement to MXG messages when reading SMF.
VMACSMF MXG now prints additional information on the SAS log
Oct 4, 1991 when reading SMF data. The start and end times and the
system id for each dump event are now printed (from the
type 02/03 records) preceding the "SUCCESSFULLY READ"
message, and the minimum and maximum timestamp of any
SMF record are also printed. The 02/03 pairs are very
useful to detect problems in SMF dump processing (if you
don't have matched pairs for each system, you had a real
problem, and if you have duplicate data you can see the
record numbers so you can copy the SMF file, deleting
the duplicate records based on these log messages).
Thanks to John Chapman, British Gas London, ENGLAND.
Change 9.147 Support for Omegamon for CICS/ESA Version 550 user SMF
EXOMCADA record created by ESRA, INTR, SYSINIT, and OMDV. There
EXOMCBOT are three different subtypes (100,101,102) of the user
EXOMCDCT SMF record, and each subtype has sub-subtypes, and the
EXOMCDLI subtype 100 sub-subtype 4 has still additional subtypes.
EXOMCENQ This code has been compared with hex dumps of subtype 100
EXOMCFCT records, but only syntax checked in execution as no data
EXOMCFIX records have yet been received for testing.
EXOMCIDM
EXOMCJCT
EXOMCPCP
EXOMCRTA
EXOMCSYS
EXOMCTIT
EXOMCTRA
EXOMCTRL
EXOMCVIO
EXOMCVSA
EXOMCVVS
IMACOMCI
TYPEOMCI
VMACOMCI
Nov 8, 1991
Change 9.146 This change significantly enhances MXG's processing of
IMACICDA optional CICS data gathered with EMPs. Previously, MXG
IMACICDB member IMACICDL decoded IBM local DL/I counters, member
IMACICDL IMACICDB decoded IBM DBCTL counters, and member IMACICUS
IMACICDU was used to set the length of any remaining user data.
IMACICOB The MXG order of processing those segments was not under
IMACICOC user control. This change externalizes the processing
IMACICOL into new member IMACICDA, which can be used to match the
VMAC110 MXG order with the order your CICS programmer set in her
Oct 3, 1991 CICS MCT table. IMACICDA can also be used to identify
which APPLIDs have which data segments, if not all are
the same. Comments in IMACICDA describe how to use the
enhancement, but this change did NOT change the previous
MXG order (DL/I, UserChar, DBCTL). The change should be
transparent to users already using the existing IMACIC..
members to decode those data.
The real reason for this enhancement now was that it is
now used to add support for additional CICS data that is
created by Omegamon for CICS Version 550. The additional
data are now supported by the new IMACIC.. "Omegamon"
members listed below.
IMACICDL IBM Local DL/I counters.
IMACICDU User counters/clocks/character data.
(Note that the length of the user data is still
defined, and can be decoded, in IMACICUS).
IMACICDB IBM DBCTL counters, CICS/ESA only.
IMACICOC Omegamon OMEGBSC (Basic) segment, CICS/ESA only.
IMACICOL Omegamon OMEGDLI (DL/I) segment, CICS/ESA only.
IMACICOB Omegamon OMEGDB2 (DB2) segment, CICS/ESA only.
Note that while the order of segment processing is now
set in IMACICDA, it is still required that you remove the
comment block in each member you want to enable. See the
comments in each member itself.
Thanks to Barry Pieper, First Bank Services Minneapolis, USA.
Change 9.145 Support for Omegamon for CICS Version 550 type 110 SMF
IMACEXCL record EXCLUDE logic (used ONLY by Omegamon for non-ESA
VMAC110 CICS, e.g., CICS 2.2 and earlier) has been added to MXG
Oct 3, 1991 IMACEXCL (itself new in MXG 9.2). Candle keeps only 31
of the standard 60 IBM fields, and Candle reorders them!
Reading a Candle excluded record without IMACEXCL gets
you an "Invalid TASKNR" error with MCTSSDCN=34.
(The exclude/reorder is optional in Omegamon, but your
CICS person must be extremely careful with Omegamon with
CICS Version 2, as the type 110 record that is created by
Omegamon is independent of the type 110 IBM CMF record -
both can be simultaneously created if both are turned on,
which can happen and has caused duplicate accounting of
CICS transaction counts and resources under CICS Version
2 regions. The problem does not occur in CICS/ESA, as
Omegamon does not create a type 110 record under CICS
Version 3 - it simply adds data (EMPs) to the end of the
IBM CMF record as described in Change 9.146).
The IMACEXCL member was originally added in MXG 9.2 to
support Shared Medical Systems exclude logic, and it now
has been revised to provide support not only for these
Omegamon exclude logic, but now can be used for any CICS
system with excluded/included fields.
Note that the three EMPs that Omegamon can also create
in CICS/ESA are separately supported by Change 9.146.
Note also that there is also an Omegamon CICS user SMF
record (that Candle unwisely defaults to ID=255, which
is the same default as their unrelated Omegamon for MVS
audit record!). That new CICS SMF record is supported in
Change 9.147. (The unrelated audit record support is in
member TYPEOMAU/VMACOMAU/IMACOMAU.)
Thanks to Jim Shumaker, American Express Phoenix, USA.
Change 9.144 DCOLLECT values for sizes of volumes and datasets were
VMACDCOL changed by APAR OY36364/UY55804, but MXG Change 8.285
Oct 1, 1991 was also in error. Before APAR, IBM used a track size
of 47968 (3380) or 58786 (3390) bytes, which is the
unformatted track capacity. But every track really has
a record R0, and users complained about DCOLLECT values.
IBM's APAR now uses the formatted track size available
after R0, the familiar 47476 (3380) or 56664 (3390)!
But when I validated the earlier number and found the
numbers were larger than expected, I assumed that the
values documented as "KB" were "thousand-bytes", and not
"kilo-bytes", and thus Change 8.285 incorrectly used a
factor of 1000 to convert raw values into "bytes". Now
the truth is know; DCOLLECT does store Kil0-bytes and
the correct conversion factor should have been 1024.
1.These values must be multiplied by 1024 instead of 1000
(they are listed in the order in which they appear):
DCDALLSP DCDUSESP DCDSCALL DCVALLOC DCVFRESP DCVLGEXT
DCVVLCAP UMDSIZE UMALLSP UMUSESP UMRECSP UBDSIZE
2.Two other variables were also in error, but unrelated
to the above error. Variables DCDBKLNG and UMBKLNG are
block length of datasets, and should not have been
multiplied at all. Delete the respective lines which
erroneously multiplied them by 1000.
The following table shows the values stored and reported
by MXG (after this change has been made to VMACDCOL),
before and after the above IBM APAR is installed. (Note
that after the APAR but without this change, MXG showed
the 3380D capacity as 587MB!).
Before APAR After APAR
Device Tracks Kbytes MB Kbytes MB
3380D 13275 621850 607 615472 601
3380E 26550 1243701 1214 1230945 1202
3380K 39825 1865552 1821 1846417 1803
3390-2 33390 1916859 1871 1847666 1804
3390-3 50085 2875289 2807 2771500 2706
Thanks to Susan Marshall, SAS Institute Europe, GERMANY.
Thanks to Mr. Plaacht, RWG, GERMANY.
Thanks to Stuart Buck, Procter and Gamble Brussels, BELGIUM.
Change 9.143 Support for CMA-SPOOL user SMF record creates twelve new
EXCMA00X datasets, one for each subtype. The support is written
EXCMA01X in the "Subtype-Level Processing" architecture, which
EXCMA02X allows individual datasets to be created from selected
EXCMA03X subtypes, or all twelve datasets can be simultaneously
EXCMA04X created. See examples in the comments at the beginning
EXCMA05X of member VMACCMA. CMA-SPOOL is a product of SCA.
EXCMA06X
EXCMA07X
EXCMA08X
EXCMA09X
EXCMA0AX
EXCMA0BX
IMACCMA
TYPECMA
VMACCMA
Sep 30, 1991
Thanks to Charlan Ledbetter, Anderson Consulting Dallas, USA.
Change 9.142 TMON/MVS creates invalid records (if the data record is
VMACTMVS larger than the CI size of the VSAM dataset TMON/MVS
Sep 30, 1991 uses, the logic record is arbitrarily broken down into
"spanned" physical records that do not conform to normal
spanning, that have incorrect counts of how may real
segments are in a "spanned" record, and that can be
spanned right in the middle of a field!). MXG can only
recognize and delete these defective records, but the
DELETE; statement after the MXG error message was lost.
The spanned record was recognized, the error message was
printed on the log, but MXG still failed with INPUT
STATEMENT EXCEEDED RECORD LENGTH message. This change
put the DELETE; statement after the error message.
Additional failures occurred when "trashed" records were
created by TMON/MVS; these records had julian dates of
1989 and their "triplets" (offset, length, number)had
zeroes for offset and/or length. MXG previously only
tested the triplet-number, which was insufficient
protection for these defective records. Now, MXG uses
all three triplet fields, and the record length to
(hopefully) more robustly detect and delete defective
data records. Finally, MXG now can recognize if you
have tried to process compressed records without having
installed the MXG-provided de-compression exit (in MXG
member EXITMON6 for Version 6, EXITMONI for Version 5),
and the messages in this case are much cleared. Note
that until Landmark chooses to create valid records,
the data in their "spanned" records will be deleted.
Thanks to William Padilla, Farmers Group Insurance, USA.
Change 9.141 IBM APAR OY33312 (PTF UY52529,30,31), says "APAR OY25606
APAR/PTFs Contains an Incompatible Change to Type 30 Records" and
Sep 29, 1991 OY33312 proceeds to state that it will reverse OY25606,
and will change the length of SMF30EOR back to 2-bytes,
etc. Don't worry about it; OY33312 has no effect on MXG
processing of the type 30 record. The APAR affects only
assembly programs using IBM macros which reference the
DSECT fieldname SMF30EOR, but the APAR does not change
the location of any fields that MXG reads; MXG did have
to add code to support OY25606 (Change 8.081), but that
code works fine with or without OY33312.
Thanks to Susan Marshall, SAS Institute Europe, GERMANY.
Change 9.140 The author of this I/O report found these corrections:
ANALPATH Line 014900 should be XDUR = MAX(XDUR,SDUR); instead of
Sep 29, 1991 containing a + sign.
Lines 016700 and 016800 should use XDUR instead of SDUR
in the denominator (calculating GTSIOPS and GTATTPS).
Thanks to Cindy Batson, Hewitt Associates, USA.
Change 9.139 RMDS records with RMDSORG='D' were incorrectly decoded,
IMACRMDS causing "INPUT STATEMENT EXCEEDED RECORD LENGTH" error.
VMACRMDS in VMACRMDS, change line 043700 to read
Sep 29, 1991 ELSE IF RMDSORG='B' OR RMDSORG='D' THEN DO;
change line 044500 to read
RMDSDEST $CHAR19. (instead of 17),
insert after line 044700 a new line with
IF RMDSORG='D' THEN INPUT RMDSOWNR $CHAR8. @;
and change line 045900 to read:
ELSE IF RMDSORG='V' THEN DO;
Before the change, RMDSORG='D' was processed with 'V'.)
In verifying this error, the code in VMACRMDS was
restructured and renumbered, and comments made clearer
that RMDS Version 3 and Version 4 are identical.
Thanks to Steve Lottich, The University of Iowa, USA.
Change 9.138 Support for DB2 2.3.0.
DIFFDB2 IBM made incompatible changes in type 100 (Statistics,
FORMATS DB2STAT0/1 datasets) and in type 102 (Trace, T102Snnn),
VMACDB2 but existing MXG programs should have no problems, as
VMACDB2H long as you install MXG 9.4+ and update the MXG Format
VMAC102 library. You may want to exploit some of the new data,
Sep 29, 1991 as described in the following notes:
Change 9.137 Minor enhancements to type 30 MULTIDD='Y' observations.
VMAC30 Variable CPUERROR is now retained from the base record.
Sep 29, 1991 (It is a bit map character variable, but since it was
not input in the multi-dd record, it assumed a value of
'4040'X, potentially causing confusion). EXECTM is now
missing in the interval multi-dd records; recalculation
of EXECTM is performed only if not multi-dd record. The
JELAPSTM is now set missing in the multi-dd record.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 9.136 Variable DUPLXUSE in TYPE6 should not be used. It was
FORMATS originally used to identify Standard/Tumble Duplex, and
VMAC6 MXG format $MG006DU decoded '80'X or '40'X values. But
Sep 28, 1991 now, additional bits are used, invalidating the single
Nov 14, 1991 value hex decoding. SAS 6.07 supports bit testing for
formats, but SAS 5.18 syntax errors. MXG has replaced
format $MG006DU for variable DUPLXUSE with $HEX2., and
you should use the variables (STDUPLEX/TMBUPLEX) instead.
(All of the bits of old variable DUPLXUSE are now used
to set individual variables).
Thanks to Vickie Wong, Manufacturers Life, CANADA.
Change 9.135 ANALDBTR can fail with "DATASET S064058 NOT SORTED" even
ANALDBTR after Change 9.104 was installed, because one more typo
Sep 28, 1991 was missed. Line 161000 must be E064TM instead of the
E063TM variable name.
Thanks to Barry Bluestein, Union Carbide, USA.
Change 9.134 Support for MVS/ESA 4.2.2 (RMF 4.2.2) added several new
VMAC22 fields to several records, but most are not significant.
VMAC23 IBM changes are compatible.SMF manual now GG28-1628-2.
VMAC30 a.TYPE22 added new bit value in TYPE22_1.
VMAC40 b.TYPE23 support in MXG was incorrect. Fields added by
VMAC71 earlier APAR were not INPUTed because the test was for
VMAC90 the wrong length (also, order of new variables was not
Sep 28, 1991 correct). Code has now been corrected, so the new data
on SMF buffer statistics is now useful!
c.TYPE30 contains new 8-byte jobclass JOBCLAS8 (left
justified). Until it's clear that it's needed, MXG has
decoded but not kept the field. However, if the 1-byte
existing variable JOBCLASS is blank and the new JOBCLAS8
is non-blank, the first byte of JOBCLAS8 will be stored
in variable JOBCLASS. Do you see a need for 8-bytes?
This field was added by APAR OY42532.
d.TYPE40 contains two new fields, TDDRCIND/TDDRCTOT which
count the index and number of records in a sequence of
records, but I can't figure why they are needed, and
especially IBM states at the beginning of section that
"IBM recommends you use record type 30 rather than
record types 4, 5, 20, 34, 35, and 40"
its unclear why any change to type 40 was made!
e.TYPE71 record was not changed, but since RECLAIMS no
longer exist in 4.2.2, the four fields which formerly
counted reclaims (PVTNPREC,PVTVAMR,PVTCAREC,LPARECLM)
will now always be zero. Member VMAC71 was enhanced by
adding SMF71xx field names in comments adjacent to the
MXG variable name to map MXG names to IBM names.
f.TYPE90 now supports subtypes 19, 20, and 21 (which were
in 4.2.1 but not decoded by MXG - SET APPC, SET ASCH, &
SET SCH respectively), and supports the new subtype 22
(SET CNGRP) added by 4.2.2.
Change 9.133 Variable ID was added to the KEEP= list, since multiple
VMAC6156 SMF records (61,65, or 66) create observations in the
Sep 28, 1991 TYPE6156 dataset.
Thanks to Tony Curry, Manufacturer's Hanover, USA.
Change 9.132 Typographical errors printed