COPYRIGHT (C) 1984-2023 MERRILL CONSULTANTS DALLAS TEXAS USA
MXG CHANGES 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.
IMACXXXX 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).
VMACXXXX 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 MXGSASV9
//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 09.245 Yet another IMS idiosyncrasy 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 09.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 09.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 09.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 09.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 09.240 The IRG (inter-record gap) calculation used to estimate
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 09.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 09.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 09.237 Reserved Change Number.
Change 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.224 Support for IBM's Production Control System OPC/A Job
EXOPC03 Tracking and Audit Trail Log Records. Twelve datasets
EXOPC20 are created from the standard IBM log records:
EXOPC23 OPCA20 JT STARTED EVENT
EXOPC24a OPCA23 OPERATION EVENT
EXOPC24n OPCA24 MCP EVENT
EXOPC25 OPCA25 SUBMIT EVENT
EXOPC26 OPCA26 AUTO RECOVERY
EXOPC27 OPCA27 MISSED FEEDBACK RECORD
EXOPC28 OPCA28 FEEDBACK RECORD
EXOPC29 OPCA29 AUTO-TRACKED EVENT
EXOPC30 OPCA30 SPECIAL RESOURCE EVENT
EXOPC31 OPCA31 ETT TAB FILE MAINTENANCE EVENT
EXOPC32 OPCA32 AUDIT TRAIL LOG RECORD
EXOPC33 OPCA33 MESSAGE LOG RECORD
EXOPC34 In addition, four user datasets for user log records are
EXOPC35 defined, OPCA00-OPCA03, for sites which write additional
EXOPC36
VMACOPC data records to the log.
TYPEOPC
Feb 5, 1992
Thanks to Wolfgang Vierling, Vereinte Versicherungen, GERMANY.
Change 09.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
Feb 5, 1992 9109. Technical Memo 7857.1 describes the contents.
Thanks to Mike Boyce, Anderson Consulting, USA.
Change 09.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 09.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 09.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 Joe Faska, Depository Trust, USA.
Change 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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
Jan 9, 1992
Thanks to David B. Adams, National Life of Vermont, USA.
Change 09.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 09.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 09.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 09.190 -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".)
-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.
-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!
-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 09.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 09.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 09.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 Joe Faska, Depository Trust, USA
Change 09.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 09.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 09.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:
ACTFRMTM replaced MSOUNITS as a metric 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 09.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 09.182 Heavy validation of TYPEIMS from MXG 9.2 uncovered still
VMACIMS additional idiosyncrasies 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 09.181 -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'
-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.
-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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.173 Support for LEGENT's MIM (Multi-Image Manager) user SMF
EXTYMIM records was added by this user contribution. A single
IMACMIM dataset, MIMTAPE, is created from this record.
TYPEMIM
VMACMIM
Nov 14, 1991
Thanks to Doug Drain, National City Bank, USA.
Change 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.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 09.132 Typographical errors printed in NEWSLETTER TWENTY have
ChangeS been corrected in the MXG SOURCLIB members. Errors were:
NEWSLTRS a.Newsletter TWENTY correctly stated that NOIMPLMAC must
Sep 28, 1991 be specified in CONFIG, but then should have said that
"IMPLMAC should never be used in ANY program."
instead of "NOIMPLMAC should never be used...."
b.In Change 9.066 text USERFMTS should have been IMACFMTS.
c.Several references to NPM 4.1.1 should have been 1.4.1.
Thanks to Pat Russell, Group Health Cooperative, USA.
Change 09.131 Members CONFIG and CONFIG07 have been updated to contain
CONFIG all of the MXG recommended options (added: ERRORABEND
CONFIG07 MACRO DQUOTE FIRSTOBS=1 OBS=MAX NOSOURCE NOSOURCE2
Sep 28, 1991 NOMACROGEN NOMPRINT NOMLOGIC). The new SAS 6.07 option
CODEPCT=120 was added only to CONFIG07; this option will
avoid a second pass of SAS compiler for very large MXG
programs (like a heavily enhanced BUILDPDB) and will
eliminate an unnecessary and confusing SAS message. Note
that options in the CONFIG file can be overridden by the
the JCL OPTIONS= parameter. For example, to print source
statements, you can print the entire source program with:
// EXEC SAS607,OPTIONS='SOURCE SOURCE2 MACROGEN',
// CONFIG='MXG.SOURCLIB(CONFIG)
Thanks to Pat Russell, Group Health Cooperative, USA.
Change 09.130 SAS Version 6 Compatibility. Options TLS= and TPS= do
ANALTMS5 not exist in Version 6. (They were used to set the line
Sep 28, 1991 size and page size of your terminal, and were set to 132
and 60 respectively in an OPTIONS statement in this ANAL
member. That OPTIONS statement was deleted.)
Thanks to Chuck Hopf, Primerica, USA.
Change 09.129 Variable SPMSEXTL in the KEEP= list for dataset SPMSCED
VMACSPMS should have been spelled SPMSEXTE. Variable SPMSDSN
Sep 28, 1991 should be added to the KEEP= list for dataset SPMSEXT so
you can match Extent data (SPMSEXT observations) to
their Definition data (SPMSCED observation). New Amdahl
PTFs for SPMS 1.2 are supposed to fix some data problems
but STARTIME is completely wrong in records that span
midnight; problem is being discussed with Amdahl now.
It has also been noticed that the SPMSATDC, allocated
track count delta, can be negative when less tracks are
allocated at the end than at the start of interval.
Thanks to Richard R. (Dick) Sziede, PRC Inc, USA.
Change 09.128 -MXG 9.3 only. Change 9.080 incorrectly deaccumulated the
DIFFDB2 DB2STAT0/1 variables QBnTCBA and QBnTPID; eight lines
Sep 26, 1991 with those names must be deleted. QXCRRALS is spelled
Oct 3, 1991 QXCRALS. QISE.... variables RCUR,RHIG,RLLM,RMAX,
RDLM, and RSTG must be changed to QIST.... prefix.
-MXG 8.8 and later. Several sequence counter variables
have been incorrectly deaccumulated. For DB2STAT0,
delete lines DIF'ing QWHSWSEQ, QWSBWSEQ, QWSnISEQ,
QWnBWSEQ. For DB2STAT1, delete DIF'ing of QWHSWSEQ.
(Do not delete DIF'ing of variables ending in TSEQ, nor
the two statements SEQCHECK=DIF(...).)
Thanks to Barry Bluestein, Union Carbide, USA.
Thanks to Pete Shepard, Ashland Oil, USA.
Change 09.127 Variable FSRTIME should have been in the KEEP= list for
VMACHSM dataset HSMFSRST; now it is.
Sep 9, 1991
Thanks to Peter Giles, DSS, AUSTRALIA.
Thanks to Colin Norton, DSS, AUSTRALIA.
Change 09.126 Boole's CMF records caused STOPOVER when record with a
VMACCMF non-zero offset and non-zero length but with a zero for
Sep 8, 1991 number of segments was found. The CHECKSUM logic did
not check for existence of segment before trying to read
the record. Only the Device Type Segment has thus far
had zero number, and changing line 00089700 to now read
IF C00DTYPN GT 0 THEN LINK CMFCKSM;
will circumvent this specific error. However, the MXG
change will protect each triplet by creating a variable
CMFWNUM set equal to the number of segments (immediately
following CMFWPTR which is set equal to the offset), and
then executing the subsequent LINK only if CMFWNUM is
greater than zero. There are 12 triplets to protect.
Thanks to Peter Giles, DSS, AUSTRALIA.
Change 09.125 This Cache DASD analysis report uses both TYPECACH and
ANALCACH TYPE74 data, but did not delete type 74 data from tapes!
Aug 20, 1991 Insert after PDB.TYPE74; IF DEVICE=:'34' THEN DELETE;
to exclude tape devices from Cache DASD reports.
Thanks to Jim Cummings, First Interstate Bank of Oregon, USA.
Change 09.124 Candle's OMEGAMON Audit User SMF Record has existed for
VMACOMAU some time, and defaults to SMF ID=255. However, their
Aug 20, 1991 new CICS V550 product now creates a different user SMF
record, which also defaults to ID=255, causing sites
using VMACOMAU to fail, since the new CICS user records
don't look anything like the Audit Record. You must
change the V550 SMF record ID (in Candle's OC$GLOB
SMFID= parameter in their OCDATA install dataset) to
a different SMF record ID. MXG support for the new
V550 User SMF record is discussed in Change 9.147.
Thanks to Dean Bolick, Belk Stores Services, USA.
Change 09.123 Protection for Shared Medical Systems CICS segments,
UTILCICS which have MNSEGCL values greater than 4, was not added
Aug 20, 1991 to UTILCICS when VMAC110 was updated in MXG 9.2. Now,
this member will skip over these segments instead of
printing ERROR.VMAC110.1 messages with MNSEGCL=209!
Thanks to Phil Shelley, Jewish Hospital HealthCare Services, USA.
Change 09.122 For IMS measurement with Boole & Babbage's IMF product,
TYPECIMS the processing of Chained Transactions (at the end of
Aug 20, 1991 member TYPECIMS) should have also recalculated the
response time variable, RESPNSTM, using the ACTLARRV
time of the chained transaction. Insert after 008600:
RESPNSTM=ENDTIME-ACTLARRV;
Thanks to Wolfgang Vierling, Vereinte Versicherungen, GERMANY.
Change 09.121 MXG decoding of DB2 Correlation ID into CORRNAME/CORRNUM
IMACDB2 was incorrect for CICS connection. The CORRNAME should
Aug 20, 1991 have been SUBSTR(QWHCCV,5,4) instead of (QWHCCV,9,4).
The comments describing the decoding of QWHCCV into the
CORRNAME/CORRNUM were also incorrect for CICS, and have
been revised and clarified.
Thanks to ???, UNI Storebrand, NORWAY.
Change 09.120 IBM now says the three new CPU time values added by ESA
XMAC7072 to the TYPE72 (CPUHPTTM,CPUIIPTM,CPURCTTM) are actually
VMAC7072 in micro-second units, and not 1024-microsecond units,
Aug 16, 1991 as documented in the microfiche for IRAWAMT! MXG Change
9.070 is thus off by 2%; the 1.024 factor added by that
change must be removed (fortunately, by comparing these
CPU times with their counterparts in type 30, I knew the
1000 factor was wrong, but believed IBM when they said
1.024 instead of 1.000!). Therefore, delete the three
lines multiplying these times by 1.024.
Thanks to Peter Doane, Com/Energy Services Company, USA.
Change 09.119 Invalid MODIFY ACF2 user SMF records are created, which
VMACACF2 caused INPUT STATEMENT EXCEEDED RECORD LENGTH error.
Aug 14, 1991 The record has a parm length of 1 byte, but there is no
ACFAPARM field in the record. C A could not see an
obvious code error, and required the Australian site to
open a problem, but not fix yet exists. For now, change
updated when CA responds. The circumvention for now is
lines 038900 and 039100 to read:
... 200 AND (COL-1+ACFAMPLN LE LENGTH) THEN ...
Thanks to Francis Han, Office of State Revenue, NSW, AUSTRALIA.
Change 09.118 Support for Software AG's NET-PASS user SMF record is
EXTYNETP added by this change, which captures response time
IMACNETP (average, and three distribution buckets) as well as
TYPENETP session logon, logoff, and disconnect/reconnect times.
VMACNETP
Aug 13, 1991
Thanks to Nancy Ayers, General Electric Lighting, USA.
Change 09.117 Minor. Variables DLYCHATM and DLYDIRTM in TYPE74 were
VMAC74 not formatted as TIME12.2, but now they are.
Aug 9, 1991
Thanks to Chuck Hopf, Primerica, USA.
Change 09.116 NPM 1.4.1 support was not complete in MXG 9.3. The code
VMAC28 does not fail, but messages (NON-ZERO COF, UNEXPECTED
Aug 9, 1991 SUBTYPE, CALL HOME) are printed, and not all of the new
Aug 12, 1991 subtypes were output. Several changes were required.
Thanks to Jim Shumaker, American Express, USA.
Change 09.115 SAS 5.18 compatibility. Step TESTIBM2 of JCLTEST needs
TESTIBM2 a 6000K region under 5.18 because TYPE102, instead of
Aug 8, 1991 TYPE102A,TYPE102B are included in MXG 9.3's TESTIBM2.
This change uses a %MACRO to detect which SAS version
is used and includes TYPE102 if under 6.06+, or includes
the pair TYPE102A, TYPE102B if under 5.18.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 09.114 The VM/XA utility UTILGEVX to create VB records for test
UTILGEVX referenced the non-existent member (MACROS) and had the
Aug 8, 1991 wrong macro names. The INCLUDE for (MACROS) should have
been for (VMACVMXA), the _INFILE should be _MWINPUT, and
the _ENFILE should be _MWENDIT. The comments should say
the input comes from fileref MWINPUT and VB records are
written to fileref OUTFILE.
Thanks to Jay Cicardo, Southwestern Bell St. Louis, USA.
Change 09.113 The VSAM Sharing Options in the VVDS were not fully
VMACVVDS decoded in the two flag variables VVRA2REG/VVRA2SYS.
Aug 8, 1991 Two new variables with values 1, 2, 3, or 4 for both
the cross-system and cross-region share options now are
created with:
VVRSHREG=FLOOR(INPUT(VVRATTR2,PIB1.)/64)+1;
VVRSHSYS=MOD(FLOOR(INPUT(VVRATTR2,PIB1.)/16),4)+1;
Thanks to Jeff Fox, SKF USA, Inc, USA.
Change 09.112 In analysis of ESA benchmark data, I discovered PERFGRP
VMAC30 and MULTIDD was not kept in TYPE30_D and PDB.DDSTATS.
Aug 8, 1991 Now they have both been added to the KEEP= list.
Thanks to Chuck Hopf, Primerica, USA.
Change 09.111 MXG recommended half-track BLKSIZEs of 23040/27647 for
CONFIG 3380/3390s but did not realize SAS 6.06+ has an option
CONFIG07 specifically for DASD, and there is also a TAPE option.
Aug 7, 1991 Now, MXG CONFIG/CONFIG07 contain
BLKSIZE(DASD)=HALF
BLKSIZE(TAPE)=MAX
Thanks to Chuck Hopf, Primerica, USA.
Change 09.110 Landmark CICS added the 8-byte APPLID in their 8.1. MXGs
ASUMCICS 7.1 summarization code had stored SYSID into APPLID to
Aug 7, 1991 create APPLID, but that line now causes APPLID to be
truncated to 4 bytes with 8.1. Change line 008700 from
APPLID=SYSID;
to read
IF APPLID=' ' THEN APPLID=SYSID;
and add APPLID to the KEEP= in line 006200.
This change will only work with Landmark 8.1 data; the
datasets built from 7.1 data records does not contain
the variable APPLID, so the change must coincide with
your implementation of TYPEMON8 processing of 8.1 data.
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
Change 09.109 The BLKSIZE of the MXG 9.3 tape was increased to 32720.
ChangeS The 9.3 label printed on the tape was correct, but the
INSTALL change from 6160 was not stated. Worse, a note in the
Aug 7, 1991 Installation section of Newsletter TWENTY said the tape
BLKSIZE was 23440, which it never has been! The tape
blocksize had to be increased so that MXG 9.3 would fit
on a 600-foot 3420 reel, but it also reduced the time to
create 3420 or 3480s. The BLKSIZE=32720 will now be used
for all future MXG Versions. Sorry for my carelessness!
Change 09.108 JCLTEST/JCLTEST6 step SMFSMALL needs SASLIB/LIBRARY DD
JCLPDB6 pointing to your format library because Change 9.094 now
JCLTEST uses the MXG MGBYTES format. In JCLPDB6, a // is needed
JCLTEST6 before the OPTIONS= parameter on the EXEC statement.
Aug 7, 1991
Thanks to Mark Delorme, Minnesota Power, USA.
--Changes thru 9.107 were contained in MXG PreRelease 9.3, Aug 1, 1991--
Change 09.107 MONITASK variable TATASKNR contains transaction counts
TYPEMON8 for history records, but Landmark's Release 8 relocated
Jul 30, 1991 the field to what MXG read as TASINTL1 $CHAR4. Now, that
input is TATASKNR PIB4., the original TATASKNR is now
unkept variable TATASKNN, and TASINTL1 was never kept.
Thanks to Annette Miller, Dale Electronics, USA.
Change 09.106 IMS multiple-message transactions resources were wrong.
TYPEIMS Lines 145300-148400, which calculate the average DL/I,
Jul 30, 1991 CPU, etc., must be moved to after line 144200, so that
the average is calculated only once, instead of being a
moving average.
Thanks to Russell Dewar, NM Computer Services, AUSTRALIA.
Change 09.105 Change 9.100 discussed the new DROP,KEEP,RENAME warning.
DOC While initially I did not like the default of warning,
Jul 30, 1991 it appears to be worthwhile; it uncovered many cases of
misspelled variables in KEEP lists that were not being
output, and some cases of variables that should have not
been in the KEEP list, when I ran the MXG 9.3 QA runs.
All members that could be corrected were, but some MXG
members intentionally contain unreferenced variables,
and these members may produce warnings (which have no
real impact, except for the condition code four!):
VMAC6 VMAC40 VMAC110
The protection in BUILDPDB/BUILDPD3 was extended to
suppress warnings for the entire member.
--Changes thru 9.104 were printed in MXG Newsletter TWENTY Aug 1, 1991--
Change 09.104 DB2 102 Trace Data causes ANALDB2R to fail with DATA SET
ANALDBTR NOT SORTED error in S008S009, S0015S018, or S059S058 due
Jul 28, 1991 to a misspelling in ANALDBTR. The error occurs only if
a one of these trace events was incomplete, i.e., when a
start event or end event record was not in the input.
These three sets of variables were reversed:
Line Now Should be
049000 IF E008TM=. IF S008TM=.
049400 IF S008TM=. IF E008TM=.
068100 IF E015TM=. IF S015TM=.
068500 IF S015TM=. IF E015TM=.
164500 IF E059TM=. IF S059TM=.
164900 IF S059TM=. IF E059TM=.
Thanks to Bob Farrell, Sun Alliance, ENGLAND.
Change 09.103 -A minor revision to ANALPATH was provided by its authors
ANALPATH to deal with a divide by zero if no prime shift data was
IMACPDBX used for the analysis.
Jul 28, 1991 -The new member IMACPDBX will undoubtedly replace the MXG
IMACPDB, but is placed in a separate member for sites to
validate its architecture. Dan Kaberon has implemented
a slick technique that lets you trivially change the
variables that are sum/min/maxed from the steps data to
PDB.JOBS, and you no longer have to count and set up the
"dummy" X variables in the original IMACPDB. The new
member also added three variables, PGSUSED PGSGLOAD and
SHEETPRN to the PDB.PRINT data set.
Thanks to Dan Kaberon, Hewitt Associates, USA.
Change 09.102 -Multiple type 30 records will be written for each step,
BUILDPDB interval, or job, if more than 1476 DDs are in the task.
BUILDPD3 MXG has always created separate observations for each of
IMACPDB these "Multi-DD" records, which contain only EXCP/IOTM
VMAC30 resource fields. However, several elapsed time measures
Jul 28, 1991 calculated by MXG from timestamps (ALOCTM,DSENQTM,EXECTM
RDRTM,SELAPSTM) should not have been calculated, and are
now set missing. A new variable, MULTIDD='Y' is created
to flag these records in TYPE30_4, TYPE30_5, TYPE30_6,
and TYPE30_V datasets. If the need is demonstrated in
the future, MXG may add logic to sum the MULTIDD type 30
into a single record, but the cost of double processing
does not seem necessary at this time. For now, flagging
these "pseudo-step" records and ensuring there is no
duplication of these elapsed time measures is enough.
MULTIDD was also added in IMACPDB to the _PDB30_4 list.
-The MULTIDD records for TYPE30_V intervals have another
problem; the begin of interval INTBTIME does not exist
(has missing value) in the second and subsequent MULTIDD
record (because IBM puts it in the processor accounting
section, which is not created in MULTIDD records!). The
INTBTIME cannot be retained from the first record to the
subsequent records while processing SMF data, because
other SMF records from other tasks can be sent to SMF in
between the first and subsequent intervals of our job.
It was necessary to modify the logic of BUILDPDB/3 to
add an extra PROC SORT and logic to fill in the missing
INTBTIME, so that sites who wish to account using their
interval records can cluster the MULTIDD records. If
your site creates interval records, you probably want to
have this corrected, and if there is no interval data,
there is no cost to this enhancement of PDB.SMFINTRV.
Note this change does not correct the TYPE30_V data set
built by member TYPE30, but only the PDB.SMFINTRV data
set built by BUILDPDB/BUILDPD3.
-Two other problems with MULTIDD records were corrected
in BUILDPDB/3. The variable STEP was a counter of step
records found, but it was also being incremented for
each of the MULTIDD records. STEP is now incremented
only for the actual step record, not for the MULTIDDs.
The variable RESTART was a counter of job restarts, but
it too was being incremented for each MULTIDD record.
Now it only counts real job terminations as RESTARTS.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 09.101 DOS/VSE Landmark CICS records are non-standard formats.
TYPEMOND Each block begins with 2-byte block length, followed by
Jul 27, 1991 two 4-byte length fields, the second of which contains
the data-length of the following data record. The 4-byte
pairs and data records are then repeated. This format
can be read with the following changes to TYPEMONI for
Landmark 7.1 records. The new member TYPEMOND contains
this change, but the logic has not been data-tested yet.
Replace With
INPUT INPUT BLKLEN PIB2. @;
LENGTH PIB2. LOC=COL;
MFSREC $CHAR1. DO WHILE (COL+8 LT BLKLEN);
@; INPUT @LOC FIRSTLEN PIB4.
LENGTH PIB4.
MFSREC $CHAR1.
@;
LENGTH=LENGTH-2;
Immediately before the
percent sign before
MACRO _ANALMON insert
LOC=LOC+FIRSTLEN;
END;
Thanks to ???, ???, EUROPE.
Change 09.100 SAS 6.07 compatibility. SAS validation of variables in
BUILDPDB KEEP, DROP, or RENAME statements or options was never
BUILDPD3 consistent; an unreferenced variable in a "D,K,R" could
CONFIG07 print an error, a warning, or no warning, depending on
Jul 27, 1991 whether the "D,K,R" was an option or a statement and/or
whether the "D,K,R" was for input or output. SAS 6.07
now consolidates the action by input or output and has
two new options, DKRICOND and DKROCOND which can set the
action to be taken to ERROR, WARN, or NOWARN. By design,
MXG has unreferenced variables in KEEP= lists for output
and since the SAS 6.07 default is WARN, many unnecessary
WARNING message will be printed on the log, and the step
will end with condition code 0004. These warnings can
be eliminated by adding DKROCOND=NOWARN to the CONFIG
member of MXG, but then SAS 6.06 will fail because this
option is unknown to SAS 6.06! As a result, there is a
now a new member, named CONFIG07, for SAS 6.07 which has
DKROCOND=NOWARN specified. Just in case you miss this
note, however, BUILDPDB/3 are specifically protected by
the addition of %MACRO VMXGDKRN to set NOWARN during the
SMF processing phase under 6.07 or later:
%MACRO VMXGDKRN;
%IF %SUBSTR(&SYSVER,1,4) GE 6.07 %THEN %DO;
OPTIONS DKROCOND=NOWARN;
%END;
%MEND
%VMXGDKRN;
and after the DATA step there is a %MACRO VMXGDKRW to
reset the option to DKROCOND=WARN. This may change as
more experience with these new options accumulates.
Thanks to Rick Langston, SAS Institute Cary, USA.
Change 09.099 Dataset VTOCINFO's variable TRKSALOC contained only the
VMXGVTOC number of tracks allocated for the VTOC; not the total
VMXGVTOF tracks on the volume. This change summarizes the detail
Jul 27, 1991 information into VTOCINFO, correcting TRKSALOC, and adds
variables TRKSUSED, NUMDSN, PCTALOC to make the VTOCINFO
dataset more meaningful for DASD capacity analysis.
Additionally, in the VMXGVTOF member only, each volume's
UNITADDR, UCBTYPE, and STARTIME (of the ASMVTOC run) are
now added to the VTOCINFO dataset. These fields were at
the end of the record created by ASMVTOC, but were not
kept in MXG's processing.
Thanks to John Mattson, National Medical Enterprises, USA.
Change 09.098 The original members WEEKBLD and MONTHBLD contained both
JCLWEEK JCL and SAS code, which required unnecessary JCL changes
JCLMONTH due to SAS or SAS changes due to JCL. This change puts
WEEKBLD the sample JCL in members JCLWEEK and JCLMONTH and has
MONTHBLD only SAS code in WEEKBLD and MONTHBLD. The JCL examples
Jul 27, 1991 in these members (an in all future JCL examples) will be
only for the SAS Version 6 environment.
Change 09.097A -The optimal BLKSIZE for MXG's SAS Data Libraries is half
CONFIG track (See SAS Notes in Newsletter TWENTY). Since these
Jul 26, 1991 libraries are RECFM=FB,LRECL=512, the correct half track
data library block sizes are
Data libraries:
3380 BLKSIZE=23040
3390 BLKSIZE=27648
Member CONFIG now specifies BLKSIZE=23040 as default.
-The MXG Default BUFNO=2 is now specified in CONFIG. With
a half-track BLKSIZE, transferring one track of data per
SSCH results when BUFNO=2 is specified. The incremental
gain of additional buffers above 2 does not seem needed
and I have always felt righteous if I transferred data
for 1 revolution and then freed the device to other
users. Since the virtual storage required for each SAS
data set is BUFNO*BLKSIZE, reducing BUFNO from 3 to 2
concomitant with the above BLKSIZE increase will
mitigate MEMSIZE. I plan further benchmarking to see if
there really is a value in increased BUFNO (only even
values make sense), but early results show half track
and BUFNO=2 gives very good performance and minimized
resources reasonably.
-The increased BLKSIZE value has increased the virtual
storage required for the INFILE processing parts of MXG,
so MEMSIZE=24M is now specified (increased from 12M) to
ensure unnecessary "out-of-virtual-memory" ABENDs. Since
MEMSIZE is above the line virtual storage, I don't think
this increase will affect any real resources, and SAS
only gets what it needs anyhow.
-The option ERRORS=2 was added, so that if you get any
invalid data hex dumps, only the first two will be on
your log, instead of the SAS default of the first 20.
Change 09.097 HSM 2.6 SMF records were changed INCOMPATIBLY. The DSR
VMACHSM and VSR have new fields, VSR fields (VSRTBAK,VSRTALC,
Jul 24, 1991 VSRNDSV, and VSRTCPU), are now reserved, and bit fields
are now decoded into new variables. MXG supports not
only HSM 2.6, but also HSM 2.4 and 2.5 SMF records.
Thanks to Joe Faska, Depository Trust, USA
Change 09.096 VM/XA messages "LOGICAL RECORD SPANS PHYSICAL BLOCK" are
VMACVMXA incorrectly printed on the log. The error was introduced
Jul 22, 1991 by Change 8.244; line 005970 must be (COL-5+MRHDRLEN).
Fortunately, the datasets built were valid, but the MXG
messages sure filled pages of your log!
Thanks to Rob Owens, SAS Institute Europe, GERMANY.
Thanks to ???, ???.
Change 09.095 BUILDPDB is enhanced by the automatic addition of the
BUILDPDB dataset TYPE0203 in your PDB, so you can keep track of
BUILDPD3 when SMF data was dumped; a type 2 record is written at
VMAC0203 the start of each SMF dump (IEASMFDP) and a type 3 is
Jul 21, 1991 written at the end of each dump. Back to back type 2s
indicates probable duplicate data, because a dump was
started but failed to complete. Member VMAC0203 was
also changed, to create variable RECNUM, the record
number of each 2 or 3 record, in case you need to strip
out duplicated records.
Change 09.094 The _SMF macro, used by all SMF processing programs, now
VMACSMF prints a message on the log "MXG SUCCESSFULLY READ SMF"
Jul 21, 1991 with the number of records AND the number of megabytes
of data that was found in your SMF file.
Change 09.093 This revision of existing TRND72 member adds several new
TRND72 MVS/ESA 4.2 variables to the TREND.TRND72 dataset.
Jul 20, 1991
Thanks to Chuck Hopf, Primerica, USA.
Change 09.092 Trending of TYPE71 data is added by this change, using
TRND71 the WEEK.TYPE71 dataset as input. (Since the TYPE71
Jul 20, 1991 data already exists as one observation per interval,
there is no need for an "ASUM71" member.)
Thanks to Chuck Hopf, Primerica, USA.
Change 09.091 Trending of PR/SM, MLPF or MDF data in TYPE70PR is added
ASUM70PR by this change. Member ASUM70PR creates PDB.ASUM70PR by
TRND70PR summarizing TYPE70PR into one observation per interval
Jul 20, 1991 for each system. (If you have more than one MVS system
running, remember that each one creates observations in
TYPE70PR for each SYSTEM. Either SYSTEM or LPARNAME has
to be used to avoid duplication in your reporting. MXG
keeps all SYSTEMs found in TYPE70PR). Member TRND70PR
takes the WEEK.ASUM70PR, and adds its new data to the
TREND.TRND70PR data, which can be used for tracking the
utilization of all your LPARs.
Thanks to Chuck Hopf, Primerica, USA.
Change 09.090 ASUMCICS used more temporary work space than needed, as
ASUMCICS some variables were not dropped, and no LENGTH statement
Jul 20, 1991 was used. After line 003400 (DATA NULLCICS;) insert
LENGTH DEFAULT=4 ENDTIME STRTTIME 8;
After line 009199 (END;) insert
DROP ENDTIME FILECN PRIINCHR PRIOUCHR RESPONSE
SYSID TRANSACT;
Change 09.089 VM/XA Trending variables PFXUTIME and PCTCPUBY were not
TRNDVMXA correct. PFXUTIME was wrong because it should be in the
Jul 18, 1991 NORM13 list instead of NORM1. PCTCPUBY was wrong because
it is recalculated and uses PFXUTIME!
Thanks to ???, 3M Europe, GERMANY.
Change 09.088 Amdahl's Cache DASD SPMS Release 1.2 completely rewrote
EXTYSPMC their user SMF record. The original VMACSPMS supported
EXTYSPME SPMS Release 1.0, but that code was temp VMACSPM0, and
VMACSPMS VMACSPMS now contains support only for SPMS 1.2. There
are two data sets created now, SPMSCED "Cache Extent
Jul 18, 1991 Definition" statistics, for each CED (which might be an
entire volume, or just a data set), and SPMSEXT "Cache
Extent" statistics, for each EXTent (which will normally
contain one observation for each CED, unless the dataset
in the CED is itself in extents). Although statistics
can be captured in the CED part of the record, there is
an option to disable statistics in the CED, so MXG will
create the sum of the EXT data and store into the CED
dataset, which seems to be the most likely dataset of
general interest, and by summing the EXT data into the
CED, either data set will be valid. Note that some of
the fields may not be valid; SPMSATBC contains negative
values. Amdahl is investigating.
Thanks to Elliot Weitzman, Oryx Energy Company, USA.
Change 09.087 Only comments were changed in IMACFILE, but the example
IMACFILE showing how to write SMF records out to an OS file now
Jul 18, 1991 has a FILE LOG; statement after the PUT _INFILE_ so that
and error messages PUT by MXG will be sent to the log.
Without the FILE LOG; statement, error messages were
written to the output SMF file!
Thanks to Brenda Rabinowitz, Prudential-Bache Securities, USA.
Change 09.086 ACF2 records with ACSMFREC='L' and ACSMFCN GE 3 were not
VMACACF2 processed. They are now output in the ACF2JR dataset.
Jul 18, 1991 The LID at the end of these records is not currently
decoded; since the records themselves were not output,
it is not clear the contents of the LID are needed, but
that will change if users request it! The change was to
change ELSE IF ACSMFREC='L' AND ACSMFFCN LE 2 THEN DO;
to ELSE IF ACSMFREC='L' THEN DO; in line 049400, and
change IF ACSMFFCN=2 THEN DO;
to IF ACSMFFCN GE 2 THEN DO; in line 050200.
Thanks to Rachel Bromage, L.O.L.A., ENGLAND.
Change 09.085 Early Address Spaces (Started Task ASIDs that come up
VMAC6 before SMF is fully up) have no JES number and their
VMAC26J2 JCTJOBID variable contains job name. The logic added in
VMAC26J3 MXG 8.8 to support the APPC TYPETASK tested JCTJOBID to
VMAC30 see if it started with an "A", but this caused "Invalid
VMAC32 Data Error" for JESNR if the STC happened to start with
Jul 18, 1991 an "A" (like ACF2!). This change reorders the logic to
first recognize an early address space (JCTJOBID=JOB)
to set TYPETASK='STC ' and JESNR=., or otherwise use the
original logic to determine TYPETASK and JESNR. The only
impact were messy record dumps on the log when MXG tried
to read characters as numbers!
Thanks to Stephen Tull, State Energy Commission of W.A., AUSTRALIA.
Change 09.084 For consistency in CICS, variable PCLOADCN was changed.
VMAC110 Its old contents, the count of load requests, was moved
Jul 18, 1991 to new variable PCLOADCT, which will be non-missing in
all CICSs, and the old variable PCLOADCN contains the
count of actual loads. The change occurred in MXG 8.8
but was not documented.
Thanks to Ms. Ericson, EDV Gmbh, Vienna, AUSTRIA.
Change 09.083 In Newsletter SIXTEEN, I made mention of APAR OY16896,
BUILDPDB but did not elaborate on its significant effect on lines
VMAC6 printed counting in MXG. The APAR changes the variable
Jul 17, 1991 OUTDEVCE (SMF type 6 field SMF6OUT). Formerly, OUTDEVCE
was the name of the output device to which the print was
sent, e.g., PRINTER1, PUNCH2, or R196.PR1 for a remote
printer, R196.PU1 for a remote punch (remember, external
writers for microfiche and other devices often "punch").
The APAR changed OUTDEVCE to contain the VTAM LUNAME of
the printer, which no longer contains indication of the
type of device to which print was sent. MXG still uses
OUTDEVCE to create variable DEVICE in TYPE6, setting
DEVICE='PRINT' (if OUTDEVCE starts with 'PRINT' or 'PRT'
or contains '.PR', or UCS starts with 'VPS, or setting
DEVICE='PUNCH' (if OUTDEVCE starts with 'PUN' or
contains '.PU'). If no match is found in OUTDEVCE, then
MXG sets DEVICE='EXT WTR'. The APAR not only changes
the contents of variable DEVICE in TYPE6, but BUILDPDB
uses the value of DEVICE to decide if NRLINES are put
in variables PRINTLNE, PUNCHCRD, OR EXTWTRLN in both the
PDB.JOBS and PDB.PRINT data sets. The total of those
three variables will still be correct, but you cannot
trust PRINTLNE to contain print lines; all of the lines
printed could end up in variable EXTWTRLN.
If the breakout is important to your site, you will have
to first create a table look up mapping VTAM LUNAME to
the type of device, and use that table in member EXTY6
to set DEVICE= to the correct device type for your site.
As long as you use the SUM(PRINTLNE,PUNCHCRD,EXTWTRLN)
for TYPE6 or PDB.PRINT analysis/billing, there is no
error.
Thanks to Susan Marshall, SAS Institute Europe, GERMANY.
Change 09.082 Interlink's product SNS/vt is actually the ANET product
VMACILKV from Teubener Associates, and is also marketed by Mitek
Jul 17, 1991 (now Open Connect Systems) as Telenet Client Fullscreen!
By whatever name, however, the disconnect record has a
bug (CONECTIM does not contain a date) that is now fixed
in their release 322.
Thanks to Dan Barbatti, Southwestern Bell St. Louis, USA.
Change 09.081 EPILOG CICS CL1000 records, by default, are dumped by
IMACEPIL Candle's utility as RECFM=U, even though the records are
Jul 16, 1991 actually internally VB, with BDW=600 and RDW=LRECL=596.
The only problem with RECFM=U is that when written to a
tape data set, lots of space is wasted between these
600 byte records. Sites have, therefore, chosen to
change the output RECFM of the Candle dumping program to
specify VB, reducing storage on tape from 5 volumes to a
single volume, but this creates an additional BDW/RDW on
the tape, a "VVBB" RECFM! MXG has always handled these
two formats; if the output is dumped with RECFM=U then
OFFEPIL=0 is specified in IMACEPIL, and if the output is
dumped with RECFM=VB, then OFFEPIL=4 handles the extra
four bytes on each record, but only now do I realize in
which case which offset is specified in IMACEPIL!
Thanks to Myron Highfield, Square D, USA.
Change 09.080 Some new DB2 variables in DB2STAT0/DB2STAT1 were not
DIFFDB2 deaccumulated. QLSTx, QWTRx, QW2x-QW5x, Q9STCTRI,J,K,L
Jul 16, 1991 in DB2STAT0, and QBnTCBA,QBnTPID,QISERx,QXCRRALS,QXDRPAL
QXMRMIAP,QXMSMIAP,QXNSMIAP in DB2STAT1 are now correct.
Thanks to Elliot Weitzman, Orxy Energy Company, USA.
Change 09.079 Data set TYPE30_D can contain duplicate observations, if
BUILDPDB the same DDNAME appears multiple times in a step record.
BUILDPD3 The NODUP option was removed from the PROC SORT of the
Jul 11, 1991 TYPE30_D into the PDB.DDSTATS to prevent unintentional
deletion.
Change 09.078 SAS 6.06 circumvention. In SAS Version 5, a DO variable
VMACCMF could be missing, and SAS treated the value as zero. In
VMXGHSM SAS Version 6, however, a missing value for one of the
Jul 10, 1991 DO loop variables raises a syntax error and terminates
execution. This problem was simultaneously encountered
in two unrelated members on the same day!
a.In VMXGHSM, before the DO C= 1 TO MPCDGNCT; insert
IF MCPDGNCT=. THEN MCTDGNCT=0;
Unrelated VMXGHSM corrections were also made.
MCDCLU should have been spelled MCDDLU. INPUT
MCTFRAG PIB2 should have been PIB2. (with a period).
DCRDATEX should have been DCRDATE.
MCVLSPCT should have been INPUT as PIB4.2, and the
subsequent DMS function deleted, as it was not PK4.
DSRTIME should have been INPUT as PIB4.2, and the
subsequent DMS function deleted, as it was not PK4.
b.In VMACCMF, before the DO on _I_, insert
IF CMFWPTR=. THEN CMFWPTR=0;
IF CMFCHKTG=. THEM CMFCHKTG=0;
and four lines later, change IF CMFCHKRM NE 0 ....
to read IF CMFCHKRM GT 0 ....
Thanks to Ray Dickensheets, Yellow Freight System, USA.
Thanks to Bill Dempster, UOP, USA.
Change 09.077 The macro _CICEXCL referenced at the end of IMACCICS was
IMACCICS only used in MXG testing and should have been removed.
Jul 9, 1991 All of the installation controls for EXCLUDE processing
are contained in member IMACEXCL.
Thanks to Tim Cartwright, University of Wisconsin Madison, USA.
Change 09.076 Option NOTEXT82 was never in SAS 6.06, and is removed
CONFIG from MXG's CONFIG member. It caused no execution error,
Jul 4, 1991 but confused users who tried to figure out what it was.
It should not have been in CONFIG in the first place!
Change 09.075 This is a document change, pending IBM answers. The two
VMAC42 fields SMF42LFW and SMF42CFW are now acknowledged by IBM
Jul 4, 1991 to be accumulators and not counts for the interval. They
have not yet acknowledged this as a bug or a feature!
Thanks to Joe Faska, Depository Trust, USA
Change 09.074 Boole's unique CMF record processing member needs a
VMACCMF RETURN; statement inserted immediately before the label
Jul 4, 1991 CMFCKSM: statement.
Thanks to Bill Dempster, UOP, USA.
Change 09.073 Change 8.213 gave an example for using INSTREAM DDNAME
Change08 to create the _DAY macro for copying yesterday's PDB to
Jul 4, 1991 the correct day-of-week PDB, but the example failed to
execute. First, the OPTIONS NOTITLE; statement should
be deleted (that options no longer exists). Second, the
PRINT option in the FILE INSTREAM statement should be
NOPRINT. Third, a blank is required after _DAY in the
quoted string: 'MACRO _DAY ' to be written to INSTREAM.
The example has been corrected in member CHANGE08 so you
could copy it for execution. Finally, under SAS 6.06+.
WEEKDAY=UPCASE(PUT(TODAY,WEEKDATE3.));
is required because the PUT function returns mixed case.
Thanks to Mark Steeley, Anthem Insurance.
Change 09.072 TYPE70PR data for DEDICATED='Y' LPAR's LCPUADDR 2 and 3
VMAC7072 incorrectly subtracted CPUWAIT0 in lines 134620,134660.
XMAC7072 The obvious typing error should have subtracted CPUWAIT2
Jul 4, 1991 and CPUWAIT3 respectively, and came in MXG 8.8.
Thanks to Helmut Kirrmaier, Comparex Mannheim, GERMANY.
Change 09.071 VLFHITPC hit percentage was conditionally calculated if
VMAC41 SMF41SRC was non-zero, but should also have been set to
Jul 2, 1991 missing with an ELSE clause. Without the ELSE clause, if
the record had classes with no activity, the prior class
value for VLFHITPC was carried forward.
Thanks to Dan Squillace, SAS Institute Cary, USA.
Change 09.070 TYPE72 new CPU variables CPUHPTTM,CPUIIPTM CPURCTTM,
VMAC7072 added by MVS/ESA 4.2, are wrong. Lines 157900-158200
XMAC7072 must INPUT these three variables as PIB4.6 instead of
Jul 2, 1991 PIB4., and then each variable must be multiplied by
1.024 after the input statement. This error also made
the variable CPUTM, as it includes these three. Note:
see revision in Change 9.120.
======Changes thru 9.069 were on MXG 9.2 built July 1, 1991=============
Change 09.069 Candle's External Security Audit SMF record needs a ZAP
VMACOMAU from Candle, OB270S10 to capture the DB2 Subsystem ID if
Jun 30, 1991 an Omegamon DB2 command is being audited; otherwise you
will not know which DB2 subsystem was the object of the
Candle command that was issued. Even with the ZAP, the
subsystem ID is not put in the right place; instead of
in being in MXG variable OMSUBSID where it belongs, the
ID value is stored in MXG's variable OMSTEP. No change
was made to MXG to move it to the right field, Candle
has not called, and the zap and this note may be enough.
Thanks to Wayne Cope, Belks Stores, USA.
Change 09.068 CA's IDMS Performance Monitor SMF records appear to be
VMACIDMS in error. TASPAGRD contains 'FFFFFFFB'x, which MXG sees
Jun 30, 1991 (inputing at PIB4.) as 4,294,967,040, and the Cullinet
report (no, they have not changed the report header yet)
shows a negative 4. Separately, the TASIMWT wait time
duration is sometimes greater than the delta between the
STARTIME and ENDTIME. No MXG change was made to deal
with what appear to be IDMS errors. Stay tuned.
Thanks to Elizabeth Stronge, Michelin Tier Corp, USA.
Change 09.067 Trending TYPE72 data did not contain PERFRPGN, so you
TRND72 could not know which performance groups were control and
Jun 30, 1991 which were report (unless you resorted to an external
table or format). This change added PERFRPGN to the ID
statement so it will now exist in trended TYPE72 data.
Thanks to Seymour J. Metz, EDS, USA.
Change 09.066 SAS 6.06 does not support concatenated Format libraries
FORMATS (since they are now SAS datasets, which still cannot be
IMACFMTS concatenated). New tailoring member IMACFMTS is created
Jun 30, 1991 to allow you to put your installation's VALUE statements
in this separate member of your USERID.SOURCLIB. The
member IMACFMTS is %INCLUDEd at the end of MXG's member
FORMATS so that your formats will be placed in the same
data library as the MXG formats. One suggested use was
to define performance group mapping in this member.
Thanks to Seymour J. Metz, EDS, USA.
Change 09.065 DASDMON/ASTEC load counts RLDCNT and RDLCNT in VMACDMON
VMACDMON should have been input PIB4.2 instead of PIB4., though
Jun 30, 1991 there was no clue in the DSECT documentation. Only the
observed very large values and comparison with Legent's
reports uncovered their documentation error.
Thanks to Greg Scriba, First National Bank of Chicago, USA.
Change 09.064 This significant user contribution is a 15-member PDS in
ANALRACF member ANALRACF that will analyze the use of MXG TYPE80
VMAC80 observations for the use of RACF commands with SPECIAL
Jun 30, 1991 or OPERATIONS authority. Documentation and flow of the
programs are contained in member ANALRACF. Three new
variables were added to the TYPE80 KEEP= list, NRSET,
RACFDAT1, and RACFVRMN, to support these reports.
Thanks to Duncan McKellar, Inland Revenue (UK), ENGLAND.
Thanks to Neil Campbell, Inland Revenue (UK), ENGLAND.
Thanks to Dave McLaughlin, Inland Revenue (UK), ENGLAND.
Change 09.063 Yet another problem with IMS Input Queue time was found.
TYPEIMS Out of 22,000 transactions, type 35x log records for 18
VMACIMS transactions contained the LTERM value in the NODENAME
Jun 29, 1991 field, causing the 35x (ENQTIME) to not be matched with
the 01x (ARRVTIME) record. These 18 records all have an
ENQFLAG=0Cx and FLAG2=ACx, and had CLBNAME=LTERM and 16
bytes later, the NODENAME needed was found in the "Input
subpool name" part of IBM's QLNQLNID (and, as usual for
IMS, there is no indication in the IBM IMS DSECT of this
condition). MXG has again been patched to support this
IMS variation. Another change, unrelated, had been left
out of the MXG 8.8 changes; for Multi-Transactions per
schedule, the CONDCODE was propagated into all IMSTRAN
observations; now it is blank until the final one. And
occasional negative service times for Multi-Trans and
WFI transactions were corrected by not re-setting the
ENDTIME to an incorrect earlier value. I always want
to think each IMS fix is the last one, but I have little
doubt that there will be future discoveries. But then
even IBM's IMSPARS is frequently unable to correctly
count transactions, and frequently can't figure out the
time stamps that MXG can locate in the log records, so
it is clearly not straightforward to decode the IMS log,
in which the records are written out of order by time!
I do believe there have never been errors in MXG's IMS
resource capture (CPU, DLI, counts, etc.), and only in
the Input and Output Queue times have there been wrong
calculations, and statistically few in number. This does
suggest STRONGLY to avoid using average values for the
analysis of IMS response, service, and queue times. One
large value can completely distort the average value,
but counting the percentage that completed in a specific
duration will not be so affected, and is much safer to
report. Even at its very best, though, the IMS log is
NOT the recommended source for IMS analysis; at best it
provides only one single measure of CPU time for each
program schedule (which might represent hundreds of real
transaction), and that CPU time cannot be subdivided
into Message Region, DB2 services, DL/I services, etc.,
which can and are captured currently by third-party IMS
monitors which write discrete transaction records for
analysis. Sites to whom IMS is a significant workload,
and especially sites with WFI, Fast Path, or lots of
multi-trans per sked activity should invest in an IMS
monitor until IBM decides to provide transaction-level
resource and response time recording in the IMS log.
Thanks to Lindsay Dawe, Mobil Oil, AUSTRALIA.
Change 09.062 CICS/ESA 3.2.1 became available today. MXG now supports
VMAC110 all releases of CICS from 1.5 thru CICS/ESA 3.2.1.
Jun 28, 1991 In fact, due to IBM's ETP program, MXG 8.8 contained
support for CICS/ESA 3.2.1, and thus you do NOT need to
install a new release of MXG just for CICS/ESA if you
have already installed MXG 8.8. Versions of MXG before
MXG 8.8 will fail with CICS/ESA 3.2.1 records, because
3.2.1 records were changed incompatibly (CICS version
SMFPSRVN was changed from an EBCDIC field containing 31
to a PK2. field containing 321). That incompatibility
is actually beneficial; finally we can recognize the
version, release, and modification-level of CICS. The
other changes between last fall's CICS 3.1 and 3.2.1
are minor, but a new timestamp, taken at CICS startup,
was added to the type 110 record, used to collect all
records from a specific execution of a CICS region. It
would really been useful if IBM had stored, not the STCK
value when CICS started, but instead had copied the
READTIME of the CICS job (which already exists) because
then CICS SMF could be directly MERGED/JOINED with the
other SMF records (like 14,15, and 64 I/O records) that
have contained READTIME for the "Job Log" since day 1
of SMF data! Oh, well, something's better than nothing!
Change 09.061 Support for NetView Performance Monitor NPM 1.4.1 is
EX028INA added by this last-minute change (the product became
EX028INB available today, and I received the IBM documentation
EX028INC two days ago!) which has been syntax tested, but has
EX028IND not actually read any SMF records with the new data
EX028EV3 segments. Prior versions of MXG should not fail with
EX028EV4 the new records, but the SAS log will contain many
EX028EV5 MXG notes that unexpected subtypes 0B, 72-77x, 90-96x,
EX028NTN and FAx were found. Eight new NPM datasets are created,
VMAC28 but none of the existing data sets appeared to have been
Jun 27, 1991 changed after a brief review of the new documentation.
MXG documentation of the new datasets is in comments at
the beginning of member VMAC28. IBM's documentation is
on pages 285-411 of NPM Installation and Customization,
SH20-6361-5.
Change 09.060 This graphic analysis program failed if you specified
GRAFTRND SASGRAPH=NO and SASSTAT=YES. Line 038700 should be
Jun 27, 1991 DATA=PERCENTS instead of DATA=PRED1, and line 044800
should be DATA=TIMES instead of DATA=PRED1.
Thanks to Jim Ray, National Council on Compensation Insurance, USA.
Change 09.059 The two PROC SUMMARYs in this analysis of TMS catalog
ANALTMS5 records worked fine in small shops, but with a large
Jun 26, 1991 number of devices and volsers, they ran out of virtual
addressability (i.e., virtual memory), because a CLASS
statement was used. The CLASS statement needs storage
in virtual memory for every possible combination of the
class variables data values; it creates all possible
answers in virtual memory, and then decides how many of
the answers you really wanted. With three variables in
a CLASS statement, if each variable has 100,000 unique
values (e.g., a TMC catalog of 100,000 tapes VOLSERs),
there are 10**15 cells needed per statistic calculated!
One of the historic virtues of the SAS System, in my
opinion, was that by being what I called "data driven",
SAS could solve problems that broke the back of these
"memory driven" algorithms. As long as you could first
afford to PROC SORT your data, you could summarize and
analyze any number of groups with a PROC MEANS with a
BY statement. Being "data driven" is the solution to
this ANALTMS problem. By changing the "CLASS" to "BY"
following the two PROC SUMMARY statements you change the
architecture from "memory driven" to "data driven", and
the virtual memory is now independent of the number of
by groups in your data. Although the TMS.TMS dataset
was already built SORTed, so in general you do not need
an extra sort to summarize, I chose to ensure the sort
order by inserting PROC SORT before the PROC SUMMARY.
However, a PROC SORT was required for the second PROC
SUMMARY, but its input dataset was already a summarized
temporary data subset of the original TMS.TMS dataset.
Since PROC MEANS now actually invokes PROC SUMMARY, this
reminder is not about PROC SUMMARY itself, but rather it
contrasts the "in memory" CLASS statement algorithm to
the "data driven" BY statement implementation. For MXG
data, the BY statement implementation is recommended, as
we DO have many possible unique values, and being "data
driven" not only uses fewer CPU and I/O resources, but
of perhaps even greater importance, being "data driven"
means that your daily production reports use exactly
the same amount of virtual memory every day, and they
will not awake you at 3am because today's data happened
to have more unique values then your test job (you know,
the one you tested in a 4MB region yesterday afternoon!)
Change 09.058 The sample code in comments that could be used to build
RMFINTRV RMFINTRV directly from SMF records did not have the BY
Jun 26, 1991 list correct for TYPE70PR dataset, causing SAS to think
there were duplicate records. The BY list now matches
its BUILDPDB counterpart.
Thanks to Chuck Hopf, Primerica, USA.
Change 09.057 Semicolons were missing at the end of lines 032300 thru
VMACTMS5 032500 in VMACTMS5 and lines 019700 thru 019900 in
VMACTMS, after support for CA/1 Release 5 was added.
Jun 26, 1991
Thanks to Chuck Hopf, Primerica, USA.
Change 09.056 Support for the eleven subtypes of the NETVIEW FTP (file
EXFTP01X transfer program) User SMF record creates eleven FTP...
EXFTP02X MXG data sets, one per subtype, from FTP R1.0.
EXFTP03X The FTP support uses the new "subtype-level-processing"
EXFTP04X MXG architecture, which will be used for all future
EXFTP11X development, and eventually will be retrofitted into all
EXFTP12X of the existing products which create record subtypes.
EXFTP21X The specification and naming conventions of this new MXG
EXFTP22X architecture is presently contained in member VMACFTP,
EXFTP23X but these initial descriptions will be elaborated into
EXFTP24X a formal MXG architecture specification member later.
EXFTP25X "Subtype-level-processing" is completely compatible with
FORMATS the existing MXG "record-level-processing" architecture,
IMACFTP and most sites won't even notice the difference, but for
TESTUSER records with lots of subtypes, the change is required to
TYPEFTP maximize the flexibility and optimize the construction
VMACFTP of MXG programs in the future.
Jun 24, 1991 FTP just happened along at the right time!
Thanks to Stephen Bell, Bunchungszentrale der westfalisch, GERMANY.
Change 09.055 Another MXG error caused STOPOVER with MVS/ESA 4.2 type
VMAC78 78 subtype 3 records because line 171600 should have
Jun 23, 1991 been @; instead of just a semicolon. At the same time,
the ?? format modifier were added to the input for the
IODFDATE/IODFTIME variables to eliminate the INVALID
DATA messages. Mini-tutorial on SAS hex dumps:
The hex dump produced by this error was not for a type
78 record, but instead contained a type 74 record.
The PUT _ALL_ list of variable=value after the dump
showed the _N_ value of 4, but the number on the hex
dump CHAR line was 5! The _N_= value is the accurate
indicator, and shows when the error occurred, and only
if the _N_= value equals the hex dump's record number,
do you know the dumped record is the problem record.
Why did SAS dump the next record? I don't know why,
but for some logic errors, SAS reads into the next data
record before realizing it has switched records, and so
when it goes to dump the record currently in its buffer
it has already gone past the problem record.
Thanks to Tom Parker, Hogan Systems, USA.
Change 09.054 MXG 9.1 corrections for MVS/ESA 4.2 in Change 9.001 were
VMAC7072 inconsistent. Part b was in XMAC7072 but not VMAC7072,
XMAC74 and parts d and e were in VMAC74 but were incorrect in
Jun 23, 1991 XMAC74. Only MVS/ESA 4.2 records were affected.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Thanks to Dan Barbatti, Southwestern Bell, USA.
Change 09.053 The PROC DATASETS DDNAME=VMXGVVDS ... should have been
ANALVVDS PROC DATASETS DDNAME=MXGVVDS
Jun 21, 1991
Thanks to Ray Dickensheets, Yellow Freight System, USA.
Change 09.052 SAS 6.06 Usage Note 2066 discusses an unfixed error that
VMAC37 causes the SAS CHARCODE option (see SAS 6.06 Language
ANALDBTR guide page 741) to unexpectedly replace characters that
ANALPDSM are inside a comment block. In VMAC37, a ?- inside a
BUILDPDB comment block was replaced by an underscore, reducing
BUILDPD3 the source line by one byte, which moved the line number
TESTUSER from column 73 to column 72, causing a syntax error!
VMACACF2 MXG did not know of this vulnerability and just happened
VMACTEST to have the ?- in a comment. Nine other MXG members had
VMAC110 either ?- or ?) pairs in comments, and all have been now
VMXGHSM changed to avoid the exposure until 2066 is fixed,
Jun 19, 1991 although SAS option NOCHARCODE could probably been used.
Thanks to Willie Antman, Federal Deposit Insurance Corporation, USA.
Change 09.051 Shared Medical System's CICS application creates its own
IMACEXCL header segment with an unexpected MNSEGCL value, which
VMAC110 caused MXG to fail. These segments were detected and
Jun 19, 1991 skipped over with the first part of this change, but MXG
Jun 27, 1991 still failed with SMS CICS records, because they use the
CICS EXCLUDE option to exclude some fields from their
transaction record.
You can tell a region has EXCLUDEd fields if the value
of MCTSSDRN in the MXG error message is 60 or less;
a minimum of 61 fields are in non-EXCLUDEd CICS data.
The previous "support" in MXG for EXCLUDE/INCLUDE was
marginal at best, was not externalized, and actually
required you to create a modified copy of VMAC110!
Because MXG promised to fix every Error condition, the
second part of this change completely redesigned the MXG
support for CICS EXCLUDEd fields, and now provides an
externalized tailoring member, IMACEXCL, that permits
processing a multiplicity of different CICS regions that
can even have different EXCLUDEs. IMACEXCL not only is
the documentation for this MXG support, it also contains
the code to read the SMS transaction records and shows
how changing only one line in your IMACEXCL will enable
SMS record processing for two specific APPLIDs.
Thanks to Phil Shelley, Jewish Hospital HealthCare Services, USA.
Thanks to Tim Cartwright, University of Wisconsin - Madison, USA.
Change 09.050 WEEKBLD job failed when automatically submitted by a job
Submitting but ran without error when submitted from TSO. Adding
Jun 19, 1991 DCB=(RECFM=FB,LRECL=80,BLKSIZE=8000) to the DDNAME in
the submitting job that points to the INTRDR solved the
problem. Without that DCB, the SYSIN dataset that SAS
tried to read had VBA or VS attributes, and SAS failed
with "Undetermined I/O Failure". By the way, that I/O
error from SAS always means the error is in a "flat"
file (SYSIN, or INCLUDEd, or FILE/INFILE), and is not
related to I/O to/from a SAS data library.
Change 09.049 Execution of MXG 8.8 under SAS 6.06 under MVS/370 (i.e.,
SAS 6.06 pre-MVS/XA) is possible for BUILDPDB, but testing and
Jun 19, 1991 validation is still on-going. This note identifies the
current recommendations for SAS 6.06 under MVS/370.
-Use maximum REGION size you can possibly get.
-Specify OPTIONS BLKSIZE=1024 BUFNO=1; to minimize the
virtual storage (but at the cost of additional I/O and
CPU time).
-Change CONFIG member to specify MEMSIZE=6M (because SAS
will try to get more, even when it doesn't exist on your
370 system).
-Add SAS option MINSTG to the CONFIG member (to free up
storage after each PROC/DATA step).
-Let me know if it works. Last site testing got through
to building the SPUNJOBS before memory failure, and has
not yet reported if MINSTG solved their problem.
Thanks to Moji Varian, Congressional Information Services, USA.
Change 09.048 The MXG circumvention for IBM's DFP type 42 records in
VMAC42 Change 9.024 protected the STOPOVER condition, but the
Jun 19, 1991 MXG test for wrong record length was invoked first, and
the bad records were thrown away instead of processed
(after a message was printed on your log, however).
This enhancement protects the STOPOVER and prevents the
MXG message on the log. In addition, the PIB8. fields
in the subtype 1 (written only if you have PDSE enabled)
are now input as ?? 8. instead of PIB8. There is still
a long series of questions at IBM DFP, because some of
the statistics (but not all) appear to be accumulated
across records, and the "Current" time stamp is several
minutes earlier than the SMF timestamp. Two APARs now
exist for the type 42, OY39393 and OY44995, and when
PTFs exist, they should be installed.
Thanks to Joe Faska, Depository Trust, USA
Change 09.047 TYPE78CU IO Queuing data will be missing if microcode
VMAC78 level CP HH0124 has been installed. The fix to IBM's
Jun 19, 1991 firmware is microcode level CP HH0130.
Thanks to Miller Dixon, Continuum, USA.
Change 09.046 TYPE6156 variable ACTION is not consistent with the type
VMAC6156 of function creating the respective record, according to
Jun 19, 1991 IBM APAR OZ82412 (1985!). MXG variable ACTION decodes
SMF6xSUB into INsert, DElete, or UPdate, but the APAR
says the field is valid only in the type 60 VVDS record
and is invalid in type 61, 65, or 66 records. Sister
APAR OZ82414 also claims that SMF6xFNC and SMF6xTYP are
equally invalid (which MXG decodes into FUNCTION and
ENTTYPID respectively). In MVS/ESA 4.2 SMF manual, the
SMF6xFNC is now a reserved field, but both SMF6xSUB and
SMF6xTYP are still documented. Your guess is as good as
mine, but beware!
Thanks to Dan Kaberon, Hewitt Associates, USA.
Change 09.045 NETSPY accounting record offset cause INPUT STATEMENT
VMACNSPY EXCEEDED RECORD LENGTH STOPOVER error. Change the line:
Jun 10, 1991 @OFFNSPY+OFFSMF+169 to read @OFFNSPY+OFFSMF+168
Thanks to Doug Drain, National City Bank, USA.
Change 09.044 An interesting change in Connect Time ("IOTM") measures
IOTM was observed in GTF traces. The instance was 4K I/O, and
Jun 8, 1991 the normal connect of 2ms per I/O was observed most of
the time, but occasionally the connect time was 18ms!
The device was a 3390 DASD behind a Model 2 3990 (i.e.,
non-cached CU). The additional connect time was traced
to a change in IBM's handling of missed RPS reconnects.
Previously, IBM would simply try, and try, and try again
to reconnect, recording 16ms (one revolution) disconnect
time for each miss. IBM has apparently implemented the
same scheme that other vendors use to limit reconnects:
after some number of misses (perhaps 2?), IBM now tries
continually to reconnect, and when it is finally able to
connect to the channel, it now SEARCHes to find the
desired sector and record. SEARCH, of course, records
not disconnect time, but now records connect time, for
the device in type 74 and for the job in type 30. In
principle this is probably good, since it limits how
long your I/O can sit waiting for reconnect, but it
could lead to problems in repeatability of connect time
for I/O measurement and accounting, because now the
connect time is a function of channel and path conflicts
rather than just the amount of I/O transferred. Since
multiple paths are typically available to devices, there
is much less probability of RPS misses now than in the
past, and the variability in connect time will not be a
significant factor in the absence of RPS misses.
Thanks to Bill Fairchild, Landmark, USA.
Change 09.043 The link edit step in ASMVTOC specifies AC=1, but later
ASMVTOC comments in the program state that authorization is NOT
Jun 8, 1991 required. The comments are correct, and the AC=1 has
been removed from the LKED step.
Thanks to David Ehresman, University of Louisville, USA.
Change 09.042 SAS 6.06 and MXG JCLTEST6 will fail in REGION=2048K with
JCLTEST "OPEN ABORTED FOR SOURCLIB, NO MEMORY FOR DATA BUFFERS".
JCLTEST6 The REGION=4096K is required, but MXG JCL comments were
Jun 8, 1991 incorrect and implied 2048K was enough. It isn't.
Thanks to David Ehresman, University of Louisville, USA.
Change 09.041 Sites with TLMS may encounter 713-04 ABENDS when putting
TLMS SAS datasets on tape, if the TLMS installation Option
Jun 8, 1991 named DBLTIME is set to 0! If DBLTIME=0, TLMS does not
Feb 25, 2006 permit "double opens", but when you build your PDB on
tape, SAS opens and closes each SAS dataset, which OS
sees as multiple opens, and TLMS inhibits. You can set
DBLTIME=1 and TLMS will let the same jobname open the
same tape data set multiple times, as long as the time
between is less than one hour (DBLTIME=2 give 2 hours!).
Unfortunately, DBLTIME is an installation-wide option.
Feb 25, 2006: Using DISP=(MOD,CATLG) instead of using
DISP=(NEW,CATLG) eliminated the ABEND!!!
Thanks to Nancy Vance, ???.
Thanks to Terry Poole, SAS Institute Cary, USA.
Thanks to Carol Arnold, BBH, USA.
Change 09.040 Reading VTOC records created by ASMVTOC with VMXGVTOF,
VMXGVTOF even after Change 9.035 (MXG 9.1), was still incorrect.
Jun 7, 1991 The logic of VMXGVTOC was not properly migrated into
VMXGVTOF, and the first extent on each volume was lost.
You might not have noticed the loss, if the first extent
was free space, but if the first extent was a real
dataset, the entire dataset record could have been lost.
The simple fix is to change VMXGVTOF as follows:
was: must be:
SET EXTENTS END=EOF; SET TOTRACKS EXTENTS END=EOF;
Thanks to Roger Edwards, South Carolina Electric & Gas, USA.
Change 09.039 MVS/ESA 4.2 was still not fully validated, even in 9.1.
VMAC74 Yet another error slipped thru, causing STOPOVER on type
XMAC74 74 subtype 2 RMF records:
Jun 7, 1991 -Find the following statement and changes as shown:
was must be
R742STCN $CHAR4. R742STCN $CHAR8.
-There are three lines containing SKIP=OFFDDSS that must
be changed as follows:
was must be
SKIP=OFFDDSS-52; SKIP=LENDDSS-56;
SKIP=OFFDDSS-72; SKIP=LEN742PO-72;
SKIP=OFFDDSS-44; SKIP=LEN742MO-44;
Thanks to Tom Elbert, John Alden Life Ins, USA.
Thanks to Dan Barbatti, Southwestern Bell, USA.
----Changes thru 9.038 were included in MXG 9.1 dated June 3, 1991------
Change 09.038 Support for Boole and Babbage's CONTROL-D SMF record
ANALCTLD is added by this user contribution. Release 1.6.4 has
EXTYCTLD been processed with this data, which creates the
IMACCTLD CONTROLD data set. Member ANALCTLD provides examples
TYPECTLD of potential reports.
VMACCTLD
Jun 3, 1991
Thanks to Brian Cobb, Credit General Industriel, FRANCE.
Change 09.037 Variable FCOTHCN was not kept in CICSTRAN dataset, for
VMAC110 no good reason, but now it is!
Jun 3, 1991
Thanks to Herr Weismann, Zurich Versicherung Frankfurt, GERMANY.
Change 09.036 Variable APPLID in NSPYVIRT was not kept, causing later
VMACNSPY report programs to fail. Add APPLID to KEEP= list.
Jun 3, 1991
Thanks to Chris Morgan, Post Office (UK), ENGLAND.
Change 09.035 A SAS 5.18-only problem caused when SYMPUT references an
VMXGVTOF unreferenced variable caused VMXGVTOF to not process all
Jun 3, 1991 extents. The MXG circumvention is to insert the line
LENGTH NOBS 4; ahead of the CALL SYMPUT line,
which satisfies the 5.18 compiler and makes the %DO loop
iterate. In addition, there was a redundant PROC SORT
of the EXTENDS data set preceding the %DO which did no
harm, but did no good, and which has been removed. This
was a combined discovery of several SAS folks:
Thanks to Susan Marshall, SAS Institute Europe, GERMANY.
Thanks to Jan van Lent, SAS Institute, NETHERLANDS.
Thanks to Waldemar Schneider, SAS Institute Europe, GERMANY.
Change 09.034 Two exits enhance BUILDPDB tailoring so that changes to
BUILDPDB are externalized for sophisticated users. Exit
BUILDPD3 EXPDB304 is taken so TYPE30_4 step variables can be
EXPDB304 changed/added into PDB.STEPS or summed into PDB.JOBS.
EXPDB6 is taken so TYPE6 print variables can be changed
May 31, 1991 into PDB.PRINT or summed into PDB.JOBS. Comments in the
exit member describe how it can be used. Complete tests
have not been completed; use with caution until this
note is replaced with validation results. At worst, you
may have to modify SPUNJOBS if you use these exits!
Thanks to Jane Graffum, Blue Cross Blue Shield of Massachussets, USA.
Change 09.033 Invalid NETSPY records are now protected from STOPOVER
VMACNSPY by comparing the expected length ENDREC to LENGTH and
May 31, 1991 deleting bad records. LEGENT is investigating the data
(NSPYREC='C' with ENTL=288 and ENTN=216-->62208 bytes
in a record only 21,000 bytes long)!
Thanks to Wilson Wong, Salomon Technology Services, USA.
Change 09.032 DB2 Audit Reports (PMAUD01, PMAUD02, or PMAUD03 were not
ANALDB2R produced if PDB=SMF was specified on %ANALDB2R. These
May 31, 1991 reports ARE produced if instead you use TYPEDB2/TYPE102
to build the datasets first, and then invoke ANALDB2R
with the PDB=PDB option to generate the Audit reports.
The PDB=SMF problem can be corrected by inserting:
AND &PMAUD01 EQ NO
AND &PMAUD02 EQ NO
AND &PMAUD03 EQ NO
two lines prior to each of the following lines:
MACRO _DB2AC1 MACRO _DB2AC2
MACRO _DB2AC3 MACRO _DB2AC4
MACRO _DB2AC5 MACRO _DB2AC6
MACRO _DB2AC7 MACRO _DB2AC9
MACRO _DB2TC2 MACRO _DB2TC10
(The omission of these three lines testing if you had
requested an Audit report caused the PDB=SMF option to
generate the above Macro line, thereby causing MXG to
create 0 observations in the datasets needed by the
audit report.
Change 09.031 The example JCLDASD had incorrect DDNAMEs, and ANALVVDS
ANALVVDS had conflicting DDNAMEs.
JCLDASD -In ANALVVDS both occurrences of PERM should be MXGVVDS,
May 31, 1991 and the OPTIONS statement was deleted (it did not cause
a real problem, but it did not belong there, since it
would prevent you from controlling options externally).
-In JCLDASD step VTOC:
Comment preceding step VTOC should state
DDNAMES DISK AND MXGDASD ARE REQUIRED
MXGDASD should replace PERM as the DDNAME for the SAS
data set to be built,
DISK should replace MXGDASD as the DDNAME for the
*.ASMVTOC.VTOCDUMP dataset, and
-In JCLDASD step VVDS:
Comment preceding step VVDS should state
DDNAMES SMF AND MXGVVDS ARE REQUIRED
Change 09.030 DB2 Reports have several values that are incorrect by a
ANALDB2R factor of two. The error only affects these variables:
May 31, 1991 QB1TCBA QB2TCBA QB3TCBA QB4TCBA QISEPAGE QISECT
QISEFREE QISEDBD QISESKCT
The correction (fortunately) is simple. Delete all
15 occurrences of 2* in member ANALDB2R! I am really
embarrassed by this error due to incorrect testing.
Thanks to Siegfried Trantes, Gothaer Versicherungsbank VVAG, GERMANY.
Change 09.029 The MXG PDS Printing utility ALWAYS printed the SOURCLIB
VMXGPPDS PDS because "PROC SOURCE INDD=&PDSIN ..." should have
May 31, 1991 been used instead of INDD=SOURCLIB!
Change 09.028 Preliminary trend data base support for VMXAINTV dataset
TRNDVMXA has been added. Note that the trending supports only a
May 31, 1991 single VM/XA system. If you have multiple VM/XA systems
they must be separately processed and trended; I am open
to suggestions for the creation of a "SYSTEM" variable
that would allow separate VMXAINTV datasets to be added
to a common VM/XA trend data base. The TRNDVMXA member
existed in MXG 8.9, but had warnings not to use, because
of Variable Not Found messages. If you remove variables
PFXIDSER and PFXIDMDL from the SUMBY= statement in 8.9,
you will then have the MXG 9.1 version of TRNDVMXA!
Change 09.027 Complete online documentation of MXG datasets has begun!
ADOCACHE I plan to provide "Chapter FORTY" style documentation of
May 31, 1991 each data source that MXG supports and each dataset that
MXG builds, as members of the MXG library, so that they
can be viewed and searched online with your text editor.
Since most data sources have a VMACxxxx member that is
the actual processing code, I have decided on the naming
convention that VMACxxxx member's data will be described
in member named VDOCxxxx. A completed VDOCxxxx member
will contain these sections:
a. Data source description. Who, what, when, writes
the raw data records, vendor, releases supported
by which version of MXG, etc. How to process this
data source with MXG (members, IMACs, etc.).
b. MXG Data Set Documentation. For each MXG data set
built, there will be these sections:
1. Description of data set itself, usage, etc.
2. Alphabetic description in detail of every MXG
variable, including usage notes, caveats, etc.
3. Clustering of similar variables.
4. PROC PRINT with variable name of sample data.
5. PROC PRINT SPLIT='*' with label of sample data.
6. PROC MEANS of sample data.
The member VDOCACHE is incomplete, but contains CACHE90
sections b.2, b.4, b.5, and b.6 for starters.
This work will extend over time. Initial estimates of
the number of pages for MXG's 900 datasets and 36,000
variables are from 8 to 13 800-page volumes! How much
will actually be printed, in what form, when will it be
completed, etc., are still under consideration. However,
as individual VDOC.... information is completed, it will
be added to the MXG SOURCLIB (even if not finished) so
the information will always be available online.
Change 09.026 Changes in 8.293 to CACHE90 dataset in VMACACHE have now
XMACACHE been implemented in XMACACHE, the SAS 5.18 member used
May 31, 1991 to circumvent the 344 compiler error.
Change 09.025 TPX variable TPXELAP should have been INPUT as PIB4.2
VMACTPX instead of PIB4.
May 31, 1991
Thanks to Seymour J. Metz, EDS, USA.
Change 09.024 Type 42 subtype 2 SMF records (DFP 3990 SMS cache stats)
VMAC42 are invalid until module IGDDCFSR is at OY39393. The
May 30, 1991 APAR OY39393 which fixed the subtype 3 record last year
didn't get on subtype 2! Without OY39393, the CU and VOL
segments are both mis-located by their offset triplets,
and the final VOL segment is actually truncated by two
bytes). This change enhances MXG to detect and process
both corrected and incorrect format records; since the
truncated bytes happen to be reserved it could be done!
You should still install OY39393 in case IBM makes any
other change to the DFP record. But there's more. In
every other relocatable SMF record, the length triplet
value is the length of a single segment, but the DFP
developers decided to be different and store the total
length of all VOL segments in SMF42VLL (and not only do
they claim there is no standard and that the format of
the length field is up to the creator, they haven't even
said they will issue a document APAR telling you!). MXG
corrects the length value in processing. And then there
are the LTM and CTM time stamps that don't contain the
HHMMSSTH that is documented, but instead contain the
seconds since midnight! And finally, the LYY and CYY
year values contain x'005B' = decimal 91 now, but do not
document what will happen in 2000 - is the format really
0cyy where c is the century bit and the 2000 will be the
x'0100', or is the format the number of years since 1900
so that the 2000 year value will be x'0064'? I have put
code in place that assumes the century bit format, but
am checking with IBM for the actual format.
Thanks to Joe Faska, Depository Trust, USA.
Change 09.023 EXD Release 3.0 added EXDRTECD (EXD/SAR Route COde) to
IMACEXD the additional EXD variables in the type 6 record, and
May 30, 1991 now MXG creates that variable if optional EXD support
is enabled in member IMACEXD. I failed to note which
bright MXG user notified me of this omission.
Change 09.022 SAS 6.06 option VERSIONLONG was added to MXG's list of
CONFIG default options, so that SAS will print the date of the
May 30, 1991 maintenance library on your log (6.06.01.01Feb91P).
Change 09.021 Support for CADAM, Inc.'s Statistics Data File, written
TYPECADM to their DDNAME STATSEQ, provides response averages and
VMACCADM counts of function key activity for CADAM end users. The
May 30, 1991 vendor's documentation warns that the data structures
are not supported by CADAM as user-accessible data and
are subject to change without notice (but the document
is dated 1988 and MXG has decoded data from the current
CADAM version 20.12). Function key use is recorded in 32
function key slots (but note that many CADAM products
(AEC, 3D) use multiple function key tables, redefining
the slots each time, and these re-uses are NOT reflected
in the function key slots.) For each function key slot,
CADAM records the number of uses, the total service time
and the sum-of-squares service times; MXG converts the
total service time to the average service time for each
function key slot. Additionally, CADAM captures the
arrival, service, and response time statistics (average,
minimum, maximum, and distributions of these three "wall
clock" durations in 44 buckets from .01 to 120 seconds.
Service is the duration from when CADAM selects an
attention to process to the point that the operating
system has reported that the display has been updated.
Response time adds to the service time the additional
duration that an attention waits to be selected for
processing (i.e., response is from arrival of an
attention to when the display is updated after
processing the attention).
Arrival time is the interval between the arrival of
attentions at the scope. Since attentions may be
"stacked" this value forms a measure of the "human
factor" in scope usage. Arrival times significantly
lower than response times imply that scope operators
are "getting ahead of the system," and that system
performance is poor.
Thanks to Emery Johnson, Allied Automotive Data Center, USA.
Change 09.020 Support for Interlink's products (used to interchange
EXILKA20 data between IBM, DEC, Internet, etc. platforms) has
EXILKA21 been added. The products each create user SMF records
EXILKGAB which are processed into multiple MXG datasets:
EXILKGAC
EXILKGCO Product MXG Acronym Datasets Created
EXILKGDI
EXILKGRE SNS/TCPaccess ILKA ILKAST20
EXILKVCO ILKAST21
EXILKVDI
EXILKVOF SNS/SNA Gateway ILKG ILKGABRT
EXILKVON ILKGACPT
EXILKVSR ILKGCONN
EXILKVST ILKGDISC
IMACAAAA ILKGREJC
IMACILKA
IMACILKG SNS/TCPvt ILKV ILKVCONN
IMACILKV ILKVDISC
TESTUSER ILKVLOGF
TYPEILKA ILKVLOGN
TYPEILKG ILKVSTOP
TYPEILKV ILKVSTRT
VMACILKA
VMACILKG
VMACILKV
May 29, 1991
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 09.019 The CICS Dictionary Printing Utility added support for
UTILCICS CICS 3.1 dictonary, but failed to sort the data before
May 27, 1991 the PROC PRINT DATA=CICSDI31, causing "INPUT DATASET NOT
IN PROPER SORT SEQUENCE." Insert before the PROC PRINT,
PROC SORT DATA=CICSDI31 ;
BY SMFPSRVR APPLID NREC MNSEGCL MCTSSDID;
Thanks to Norbert Korsche, OMV-AG, AUSTRIA.
Change 09.018 This significant user contribution supports SMF user
EXTYTAO records created by Fischer International's TAO (Totally
IMACTAO Automated Office) Electronic Mail System Release 3.2.1
TYPETAO at product maintenance level #82 and up. Earlier
VMACTAO releases are not supported as the vendor had previously
May 15, 1991 used a non-SMF type of recording for statistics from the
EMC2 Electronic Mail System which predates TAO.
Although not as widely used as some EMAIL systems, TAO
is a stand-alone MVS/VTAM application. AMDAHL uses the
TAO system extensively for electronic mail worldwide.
Some problems were encountered processing release 3.2.1
records due to errors in the vendors distribution
packaging. It seems that the documentation which
describes the dsects had been updated along with the
source dsects, however, the load modules were assembled
using earlier versions of the dsects. Assembly was a
problem due to user defined macros which the vendor had
not distributed in source form. These problems were
easily cleared up with a phone call to the vendor, but
some shops may encounter similar difficulties in
attempting to read the TAO generated SMF records using
this code. Several fields have been included in the MXG
code which are not yet supported (or populated) by the
vendor, although they are contained in the dsect areas
and the vendors comments supply documentation of the
future contents of these fields (at least in part).
This is NOT a complete subsystem for processing TAO SMF
records, retaining and summarizing detail data, and
producing reports. It IS a start for people (like me)
who hate using ALC dsects in SAS code.
Thanks to Joe Aldrich, Army and Air Force Exchange Service, USA.
Change 09.017 The use of IMACKEEP to drop variables in MXG datasets is
IMACKEEP vulnerable to error. If a new dataset is created by the
May 15, 1991 new version of MXG (for example, new TYPE74.. datasets to
Jul 23, 1991 support MVS/ESA 4.1), and if you don't retrofit your
changes in IMACKEEP, you will fail with a SAS Error 311,
because your redefinition in IMACKEEP won't contain the
name of the new datasets. It appears there is a better
way to drop unwanted variables from MXG datasets without
using IMACKEEP. You can simply use a DROP statement in
the EXTY.... member to drop unwanted variables. Even
those variable names are still in the KEEP= option of the
DATA statement in the _VAR macro definition, the DROP
statement overrides the KEEP= option and the unwanted
variables will be dropped. Using the EXit member to drop
variables should be less vulnerable to change, and will
eliminate the use of IMACKEEP except in cases where you
want to ADD a new variable to an MXG dataset. A caution;
you cannot drop a variable which is later used in a BY
statement.the DATA step, as one user found when he tried
to drop MVS/370 variable LCHAN using EXTY74. The drop
statement removed LCHAN from not only TYPE74 but also the
TYPE73P dataset, which is later sorted from work to the
PDB with LCHAN in its BY statement. This cause an error!
However, ain't nothin' straightforward. If you should
use a DROP statement in the EXIT member, and if that
variable should ever disappear from MXG, you will THEN
fail with a "Variable in drop list never referenced"
error! Normally this won't happen in MXG code, but
(for example), if you had used the XMAC7... members to
circumvent of the SAS (Version 5 only) 344 compiler
error, MVS/370-only variables do not exist in the XMACx
and your DROP statement in EXTY74 would fail.
But you can be even smarter than SAS. If you add a
"MXG Compiler Faker" statement for each variable to
be dropped ahead of your DROP statement, the compiler
will be faked out whether the variable exists or not,
the variable will be dropped, and you code will be
invulnerable to future MXG changes! What is this MXG
"Faker" statement? Simply for numeric variables it's:
IF N=. THEN N=.;
and for a character variable C, you must have as many
blanks between the quotes as is the length of the
character variable:
IF C=' ' THEN C=' ';
Change 09.016 Support for Computer Associates CA-1 (TMS) Release 5 has
TYPETMS completely changed the format of the TMC records, but as
TYPETMS5 there is no product release number in the TMC, MXG had to
create completely separate, but parallel members to read
VMACTMS5 the new TMC to create MXG data set TMS.TMS. A few new
May 15, 1991 variables do exist (see DOCVER09), but all of the prior
variables still exist (except for the obscure variables
READERR, WRITERR, which were replaced by 8 separate error
values). The value of variable DEVTYPE was changed so it
doesn't waste so much space; the "EIGHTEEN-TRACK" and the
"NINE-TRACK" values were replaced by "9TRK", "18TRK", and
new value "36TRK" (for the 3490-E Serpentine technology)
was added for DEVTYPE. For 3480s ("18TRK"), the IDRC
compaction status is decoded into MXG variable DEN, which
will have the value 38000 for non-IDRC 3480 tapes, and
which is set to 76000 by MXG to indicate IDRC compacted
3480 tapes. Members TYPETMS/VMACTMS must be used for
CA-1 Releases earlier than Release 5, and MXG members
TYPETMS5/VMACTMS5 must be used for Release 5.
Thanks to Debora Reinert, Nordstrom, USA.
Change 09.015 Landmark TMON/CICS Version 8 history file contains a data
TYPEMON8 dictionary record with TMMDREC='DD' which causes MXG to
May 14, 1991 fail because this record was not expected, and should be
deleted. Change lines 065900 to 0660 to now read:
TMMDREC $CHAR2. 065900
@; 065910
IF TMMDREC='DD' THEN DELETE; 065920
INPUT TMMDFLG1 $CHAR1. 066000
Thanks to David A. Faught, FCC National Bank, USA.
Change 09.014 The DROP=_FREQ statement in IMACPDB was supposed to have
IMACPDB been DROP=_FREQ_ (with underscore on both sides), so that
May 13, 1991 the _FREQ_ variable created (only in SAS 6.06+, when PROC
MEANS was replaced by PROC SUMMARY) would be dropped. The
"misspelling" caused _FREQ_ to exist in both PDB.JOBS and
PDB.SPUNJOBS.
Thanks to Raymond Zieverink, Belk Stores Services, USA.
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
Change 09.013 New PDB.SPUNJOBS dataset variables INITTIME/JINITIME were
SPUNJOBS not kept as 8-bytes (which caused their value to be
May 13, 1991 truncated by up to 255 seconds) and were not formatted.
Both are now explicitly in the LENGTH statement and a new
FORMAT statement was added.
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
Change 09.012 Trending of TMON/CICS dataset MONIDBDS built from TMON
ASUMDBDS Release 7 data (i.e., using MXG member TYPEMONI) will
TESTOTHR cause ASUMDBDS to fail with variable APPLID not found, as
May 13, 1991 APPLID did not exist in TMON Release 7. Adding after the
INCODE= operand:
IF APPLID=' THEN APPLID=' ';
will protect ASUMDBDS for either TMON Release 7 or 8.
(This error was not detected because MXG's TESTOTHR step
of JCLTEST had member TYPEMON8 included after TYPEMONI
and then ASUMDBDS was included, masking the error. Now,
ASUMDBDS (and ASUMCICS) are invoked after TYPEMONI, and
then again invoked after TYPEMON8. Note that there is
no way to actually test TMON/CICS with step TESTOTHR and
actual data records; the single MONICICS DDNAME is used
for both TYPEMONI and TYPEMON8, and thus with real data,
one or the other will fail in step TESTOTHR. To really
test TMON/CICS data with MXG, use a separate job with
only the appropriate TYPEMONx member.)
Thanks to William Padilla, Farmers Insurance Group, USA.
Change 09.011 Landmark's TMON/CICS Release 9.0 records will have to be
TYPEMON8 converted to Release 8.1 format for processing by MXG's
May 13, 1991 TYPEMON8 member; Landmark does not intend to make the 9.0
formats available. But TMON/CICS 9.1 will be available
late 1991 or early 1992, and will have significant change
in its records that will be made available and thus 9.1
records will be supported by MXG natively late this year.
Change 09.010 TYPE57 data produced MXG message "INVALID ESS SECTION'
VMAC57 and the record was skipped because IBM documented the LEN
May 13, 1991 and NR of ESS sections as 4 bytes when in fact they are
only two bytes. Lines 010100 and 010200 (where LENESS &
NRESS are INPUTed) should be PIB2. instead of PIB4.
Thanks to David A. Faught, FCC National Bank, USA.
Change 09.009 Processing HSM MCD, etc. data sets may cause STOPOVER,
VMXGHSM may print INVALID DATA messages if HSM dates are nulls,
May 13, 1991 may print INVALID ARGUMENT messages because DATEJUL()
were not protected, misspelled TTOCTYP with an E, and
did not input TTOCALT, the Alternate VOLSER. The STOPOVER
was corrected by moving the two tests for 'junk" records
(SUBSTR(MCDDSN) containing '99999') to immediately after
the variable MCDDSN was input (by breaking the input
statement at that point with @;). The INVALID DATA was
eliminated by preceding all PDB4. formats with the ??
format modifier, and the INVALID ARGUMENT was eliminated
by replacing all DATEJUL(x) functions with:
IF x GT 0 THEN x=DATEJUL(x);
ELSE x=.;
The occurrence of TTOCTYPE was respelled TTOCTYP, and was
formatted $HEX2. instead of HEX2., and the preceding
TTOCKEY variable was now formatted HEX2. Finally, at the
end of the TTOC section, new variable TTOCALT $CHAR6. is
now input, labeled 'VOLSER OF ALTERNATE VOLUME' and kept.
Thanks to Tim Noone, American United Life Insurance Company, USA.
Thanks to Joe Ellis, Shelby Insurance, USA.
Change 09.008 SAS 5.18 344 Compiler Limit circumvention member VMAC110M
CICINTRV (that was added by Change 8.065 to reduce Iterative DOs)
VMAC110M fails with BUILDPDB because after VMAC110M was tested,
May 9, 1991 member CICINTRV was added to BUILDPDB, but VMAC110M does
not create the datasets required by CICINTRV. Since the
purpose of VMAC110M was to suppress CICS/ESA Statistics
processing, and since CICINTRV processes only CICS/ESA
Statistics data sets, the easiest circumvention that lets
you use VMAC110M (by copying and renaming it to VMAC110
in your USERID.SOURCLIB) is to also create a member named
CICINTRV in your USERID.SOURCLIB that contains a blank
line. This will possibly circumvent the 344 error and
will definitely eliminate the "Data Set Not Found" caused
by VMAC110M. However, just to be really robust, the
member VMAC110M was corrected by this change, and now it
does create the CICS/ESA statistics datasets (with zero
observations, and with only the seven variables needed by
CICINTRV) so if a future user does not see this change,
and uses only VMAC110M, he/she won't be burned!
Thanks to John Hassman, Texas Education Agency, USA.
Change 09.007 Applies only to MXG 8.9. Change 8.304 added retrograde
VMAC79 support for RMF 3.5.1 type 79 records, but I miss-typed
May 9, 1991 two lines. In line 037900, R792ARS should be PIB2. vice
PIB4., and in line 039630, R792TWSS should be PIB2. vice
PIB4. Without this change, RMF 3.5.1 records STOPOVERed.
Thanks to Gordon Keehn, Fidelity Mutual Life Insurance Company, USA.
Change 09.006 Minor documentation. Member IMACAAAA failed to list the
IMACAAAA IMACCMF member (Boole's CMF SMF Record ID) in its index,
IMACCMF and member IMAC370 was deleted, as it was not referenced
IMAC370 and should have been deleted during testing; it was going
May 8, 1991 to contain MVS/370-only-RMF processing but was discarded
as a bad idea. It serves no purpose.
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
Change 09.005 Minor, unless you tried to build your PDB on tape! The
IMACCICS new SPUNJOBS logic added in MXG 8.8 tried to read the
SPUNJOBS PDB.SPIN26 at the same time it was writing PDB.SPUNJOBS
May 8, 1991 which can't be done if your PDB DD points to tape! Note
that if you really want your PDB on tape you must not
only correct this design error in SPUNJOBS, but you must
also change the default PDB values in member IMACCICS to
WORK, and (if you actually have CICS data) use EXPDBOUT
to then PROC COPY IN=WORK OUT=PDB; SELECT CIC:; as is
now described in comments in IMACCICS. To fix SPUNJOBS,
insert: DATA SPJB26; SET PDB.SPIN26; immediately before
the line containing DATA PDB.SPUNJOBS; and in the
following MERGE statement change PDB.SPIN26 to SPJB26 so
that only one PDB dataset is open at a time. Also,
PROC DATASETS NOLIST;
DELETE SPJB30_1 SPJB30_4 SPJB30_5 SPJB26;
was added at the end of the member. It was also realized
that SPIN6 processing is not currently in SPUNJOBS, and
that will be corrected in another change.
Thanks to Tim Hill, Pacific Bell, USA.
Change 09.004 Minor. Lines 011900 and 012000 both contained */ after
DIFFHSM the semicolon, which should have raised a syntax error,
May 8, 1991 but didn't. Instead, variable DSRNTRKW was never DIF()d!
Thanks to Joanne Turpie, New Zealand Dept. of Labour, NEW ZEALAND.
Change 09.003 Minor. The last occurrence of variable OTHRACTV (in the
TRNDRMFI NORM1= list) should have been OTH0ACTV.
May 6, 1991
Change 09.002 This change is cosmetic, but should be noted. The 3490E
VMACUCB cartridge tape (serpentine, bi-directional) device has a
May 6, 1991 DEVTYPE of 81x, which was formerly assigned to the 9348.
MXG will now report 3490E instead of 9348. Note that the
3490 (non-E variety) cannot be differentiated from 3480s.
And of course 3480s with and without IDRC (compression)
are not identified at the device level. And what's going
to be real fun is trying to figure out what kind of tape
you hold in your hand; all three used identical media
cartridges, but are incompatible; 3490E cannot be read
by 3490/3480/3480-IDRC, and 3490/3480IDRC cannot be read
on 3480. Note MXG shipments are 3480-non-IDRC!
Thanks to Jay Arbabha, Principal Mutual Life Insurance Company, USA.
Change 09.001 MVS/ESA 4.2 data records finally arrived and demonstrate
VMAC30 that it is risky to distribute software that has not been
VMAC7072 tested with actual data records. On the other hand, if
VMAC73 I had waited for the data, you would still be waiting for
VMAC74 the software! These errors ONLY happen with MVS/ESA 4.2
XMAC30 data records, and only one causes an actual error.
XMAC7072 a.In VMAC30, find the line containing
XMAC73 @109+OFFSMF SMF30ASO +8 /*RESERVED*/
XMAC74 and change it to read:
May 6, 1991 @109+OFFSMF +8 /*RESERVED-SMF30ASO*/
This was a soft error, only causing your log to be filled
with "INVALID DATA FOR SMF30ASO" messages and a hex dump.
(If it's not clear, SAS was trying to input SMF30ASO as
an EBCDIC numeric field because there was no format item
following the variable name in the input statement. What
was desired was to skip over 8 bytes, and note that this
reserved field was called SMF30ASO by IBM.)
b.VMAC7072 causes "INVALID DATA FOR IOCRFC/CPURFC" messages
because these two fields no longer exist in 4.2, and the
fields now contain hex zeros instead of EBCDIC zeros!
Find the lines containing
@OFFWRKC+14 IOCRFC 3.
@OFFWRKC+17 CPURFC 3.
and add ?? format modifier between the variable and its
format:
@OFFWRKC+14 IOCRFC ?? 3.
@OFFWRKC+17 CPURFC ?? 3.
The ?? format modifier suppresses the hex dump and the
message, and sets the variable's value to missing.
This is a soft error.
c.VMAC73 causes "INVALID DATA FOR IODFDATE" messages.
Find the lines containing
IODFDATE YYMMDD8.
IODFTIME TIME8.
and add ?? format modifier between the variable and its
format:
IODFDATE ?? YYMMDD8.
IODFTIME ?? TIME8.
because not all records contain this new date/time data.
This is a soft error.
d.VMAC74 also causes "INVALID DATA FOR IOFDATE" messages
for the same reason as the VMAC73. Apply the fix above
for IOFDATE (paragraph c) to the VMAC74 member.
e.VMAC74 causes a STOPOVER condition. This is not soft!!!
Find the three lines reading:
DLYDIRTM PIB4.6
@;
SKIP=SKIP-20;
and change them to read:
DLYDIRTM PIB4.6
DEVDYNCH $CHAR1.
+3
@;
SKIP=SKIP-24;
These extra four bytes were added by IBM, and were added
in the SMF manual, and were even vertically barred, but
I simply missed them. Sorry for the inconvenience.
The actual change in MXG VMAC74/XMAC74 9.2 and later is
more extensive that this "quick fix" printed changed.
Thanks to Diane Eppestine, Southwestern Bell, USA.
LASTCHANGE: Version 9