COPYRIGHT (C) 1984-2007 MERRILL CONSULTANTS DALLAS TEXAS USA
CHANGE 08.08
=========================member=CHANGE08================================
/* COPYRIGHT (C) 1984,1991 MERRILL CONSULTANTS DALLAS TEXAS USA */
I. This is the Production Version MXG 8.9, dated May 1, 1991.
All Changes listed in this member have been installed in MXG 8.9.
MXG 8.9 is a replacement for MXG 8.8 (which had been shipped April 8).
The few minor errors that had been found in 8.8 were corrected, and the
support for Fujitsu's FACOM PDL data was enhanced.
This MXG 8.9 library contains 1370 members, 309,959 lines of code,
and builds 903 datasets with 31,868 variables documented in DOCVER!
Member NEWSLTRS contains all newsletters, including NINETEEN which
contains the Installation and Compatibility notes for MXG Version 8.
Changes thru 8.078 were printed in NEWSLETTER SEVENTEEN, Jul 10, 1990.
Changes thru 8.087 were contained in MXG PreRelease 8.2, Jul 20, 1990.
Changes thru 8.119 were contained in MXG PreRelease 8.3, Aug 26, 1990.
Changes thru 8.157 were contained in MXG PreRelease 8.4, Oct 9, 1990.
Changes thru 8.168 were contained in MXG PreRelease 8.5, Oct 27, 1990.
Changes thru 8.169 were contained in MXG PreRelease 8.6, Oct 27, 1990.
Changes thru 8.186 were printed in NEWSLETTER EIGHTEEN, Dec 3, 1990.
Changes thru 8.203 were contained in MXG PreRelease 8.7, Dec 18, 1990.
Changes thru 8.283 were printed in NEWSLETTER NINETEEN, Apr 8, 1991.
Changes thru 8.285 were contained in MXG Production 8.8, Apr 8, 1991.
Changes thru 8.305 were contained in MXG Production 8.9, May 1, 1991.
Critical Notes:
MXG Compatibility Exposures in MXG Version 8 for Existing Users:
a. The SAS options required by MXG for execution have changed.
b. Execution under SAS 6.06 is different than under SAS 5.18.
c. To create your PDB directly on tape, IMACCICS must be changed.
d. If you have added additional SMF record processing to BUILDPDB,
and you still execute MXG under SAS 5.18, you may encounter a
SAS Version 5.18 Compiler Limit "344" error. BUILDPDB is larger.
See Change 7.038 in member CHANGE07 for 344 error circumvention.
Please note the new MANDATORY options for SAS 5.18 and 6.06 in the
SAS Notes in Newsletter NINETEEN. Member SASOPTV5 or CONFIG in this
library can be used to specify these options, but if you do not pay
attention to ALWAYS include the appropriate member, you will be
very frustrated by unresolved macro reference or 180 syntax errors!
MXG Newsletter NINETEEN contains Installation Instructions that MUST be
complied with. (Contained in member NEWSLTRS).
SAS 6.06 is repaired, and with the March 1991 or later SAS Usage Notes
tape, it is now MXG's recommendation that you begin your migration
to SAS 6.06. The March tape contains 100% pre-applied SAS ZAPs for
all SAS products, in IEBCOPY format, making SAS maintainance a snap!
Z6062141 is a critical ZAP that MUST be installed if you do not
have the March SAS tape installed.
IV. Documentation MXG Software.
Member CHANGES always contains the version number of MXG Software, and
it lists changes that were installed in that version. Several members
named CHANGEnn are the contents of changes when that "nn" MXG version
was created. Details on 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 also 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 altered or added by that change, and documentation (especially for
new product support) is often found in comments at the beginning of
those named members.
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 31,868 variables from the 903 MXG data sets
that can be 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 VMAC...'s
that actually create the data set, or ANAL....'s that analyze the MXG
datasets. In many instance, the MXG Variable is the IBM or Vendor's
documented field name. In other cases, the IBM field name is carried as
a comment beside the MXG variable that contains that information. In
all cases, you should also have the Vendor's documentation of the
particular data record you are using for analysis.
I. MXG SOFTWARE Version status.
1. Production MXG Version is now MXG 8.8, dated April 8, 1991.
MXG Version 8.8 is shipped with NEWSLETTER NINETEEN to all sites, and
should be installed as soon as possible. MXG 8.8 is mandatory for MXG
execution under SAS 6.06 or later, has MANY major enhancements, and has
been testing at over 500 MXG sites. MXG 8.8 WILL SAVE YOU TIME LATER,
SO PLEASE INSTALL IT AS SOON AS POSSIBLE. Major MXG 8.8 enhancements:
Support for Amdahl MDF Performance Tool "MPT" SMF record.
Support for Amdahl MDFTRACK record.
Support for Amdahl SPMS Cache DASD Controller SMF record.
Support for Boole IMF 2.6 (for IMS 3.1).
Support for Cray COS 1.16 Operating System Data.
Support for DASD Space management with fast VTOC read program.
Support for DASD VTOCs and VVDSs for SMS variables.
Support for Hitachi processors MLPF.
Support for IBM CICS/ESA 3.1.1 Monitor and Statistics Data.
Support for IBM DCOLLECT data records.
Support for IBM DCOLLECT data records.
Support for IBM HSM user SMF records, including deaccumulation.
Support for IBM Hiperbatch statistics in SMF type 14, 15, & 64.
Support for IBM IMS/ESA 3.1.
Support for IBM MVS/ESA 4.1.
Support for IBM MVS/ESA 4.2.
Support for IBM NETVIEW/NPM 1.4
Support for IBM RMF 4.1.2 (APAR OY29112, PTF UY90666).
Support for IBM RMF 4.2.0
Support for IBM RMF 4.2.1
Support for IBM SMS records (HSM, VVR, VVDS, SMS/DFP) enhanced.
Support for IBM VLF subtype 3 in SMF type 41.
Support for IBM VM/ESA Version 1 Release 1.0 (ESA Feature).
Support for Landmark's Monitor for CICS Version 8.
Support for Landmark's TMON/MVS Version 1.1 and spanned records.
Support for Oracle SMF record.
Support for RSD WSF2 version 3.3.4.
Support for Tangram Arbiter Version 2.1.1.
SPIN library fills due to JES2 maintenance circumvented.
CICS Shutdown Statistics no longer printed, only in SMF or MXG.
Documentation of Trend Data Base processing.
Documentation of DB2 analysis.
Documentation of IMAC.... installation tailoring members.
Corrections in IMS Log measurement of INPQUETM/RESPNSTM.
NPM records from VM can be processed.
Testing of MXG Version 8.8 under SAS 6.06 Version 6.06.
DB2 trace SQL reporting.
DB2 trace Transit Time reporting.
BUILDPDB/3 Enhancements.
- SPIN library copied into PDB for backup and recovery
- ACCOUNTn and SACCTn added to SMFINTRV.
- TYPE25 processing added for JES3.
- PDB.SPUNJOBS allows reporting on jobs still in SPIN library.
MXG Software next-release agenda (subject to change):
Validation of EXPLORE/VM, EPILOG/CICS, and restructure of the
AS400 support was not complete as this was written.
DB2 2.3 will be supported when available, late this year.
CICS 3.2 will be supported when available, later this year.
Landmark CICS Version 9 will be developed later this year.
Cray UNICOS is a future consideraton.
VAX/VMS Account/SPM is a future consideration.
JES3 Tape Mount Merge with TYPETMNT is a future consideration.
2. Recent IBM Announcements and their MXG support.
IBM has made many major announcements relating to the System/390, the
ES/9000 family, and ESCON capabilities. The following table identifies
announced availability dates for the IBM product, and the corresponding
Version/PreRelease of MXG required to support that IBM product.
Product Name Availability MXG Version
Date Required
VM/ESA 1.1.0 (370 Feature) Oct 26, 1990. 7.7
RMF 4.1.2 (for MVS/ESA 3.1.3) Sep 7, 1990. 8.8
RMF 4.2 (for MVS/ESA 4.1) Oct 26, 1990. 8.8
MVS/ESA 4.1 Oct 26, 1990. 8.8
MVS/ESA 4.2 Mar 29, 1991. 8.8
RMF 4.2.1 (for MVS/ESA 4.2) Mar 29, 1991. 8.8
VM/ESA 1.1.0 (ESA Feature) Mar 29, 1991. 8.8
VM/ESA 1.1.1 Dec 27, 1991. ???
IV. SAS Notes.
1. SAS 6.06 has been repaired, and can be safely used.
SAS 6.06 has finished its shakedown cruise, and shipyard repairs have
been made, and the SAS Usage Note tape for March (or later) can now
be safely and easily installed. (Starting in February, SAS now ships
a load library on that tape which contains 100% pre-applied SAS ZAPs
for all SAS products. A SAS 6.07 will likely exist by year end, but
THERE IS NO LONGER ANY REASON TO WAIT. ALL MXG-critical problems are
fixed by the March tape. Furthermore, SAS 5.18 sites that have made
extensions to BUILDPDB may find that their program is now too large
for the SAS 5.18 compiler (Error 344) which can only be eliminated
by execution under SAS 6.06 or later.
See Change 7.038 in member CHANGE07 for 344 error circumvention.
MXG NOW RECOMMENDS MIGRATION TO SAS 6.06 WITH SAS's MARCH 6.06 TAPE.
2. SAS 6.06 and 5.18 options now REQUIRED by MXG 8.8.
Please read this section carefully. MXG execution will fail if you
do not pay attention to these (potentially incompatible) changes:
MANDATORY OPTIONS with either SAS Version 5.18 or 6.06:
NOIMPLMAC MAUTOSOURCE SASAUTOS=SOURCLIB ERRORABEND MACRO DQUOTE
MANDATORY OPTIONS with SAS Version 5.18 that do not exist in 6.06:
MWORK=28000 GEN=0
MANDATORY OPTION with SAS Version 6.06 that does not exist in 5.18:
MEMSIZE=12M
RECOMMENDED Options with either SAS Version 5.18 or 6.06:
FIRSTOBS=1 OBS=MAX
NOSOURCE NOSOURCE2 NOMACROGEN NOMPRINT NOMLOGIC
SAS Version 5.18 requires the MACRO and MWORK=28000 options to be on
the EXEC statement, but all other mandatory/recommended options can be
specified in a SAS OPTIONS statement before your %INCLUDE statements:
a.) //stepname EXEC SAS,OPTIONS='MACRO MWORK=28000'
//SYSIN DD *
OPTIONS
NOIMPLMAC MAUTOSOURCE SASAUTOS=SOURCLIB
DQUOTE ERRORABEND
GEN=0
FIRSTOBS=1 OBS=MAX
NOSOURCE NOSOURCE2 NOMACROGEN NOMPRINT NOMLOGIC;
However, so you (and I) don't have to type all those options each time
we run an MXG 8.8 program under SAS 5.18, member SASOPTV5 was built and
it MUST be %INCLUDEd each time you execute under SAS 5.18:
b.) //stepname EXEC SAS,OPTIONS='MACRO MWORK=28000'
//SYSIN DD *
%INCLUDE SOURCLIB(SASOPTV5);
... the rest of your program ...
IF YOU DON'T HAVE THE RIGHT OPTIONS IN EFFECT, YOU WILL RECEIVE
RUDE AND INSULTING SAS ERROR MESSAGES, INCLUDING 180 ERRORssss!
For SAS Version 6.06+, options are supplied via an OPTIONS statement,
via the CONFIG DDname, or (as is now MXG's recommendation), via the
CONFIG= JCL parameter on the EXEC statement. MXG 8.8 member CONFIG
contains the MXG-required options (CONFIG is a changed copy of BATCHXA
config member on the SAS distribution tape). In previous Newsletters
and sample JCL, MXG had used the CONFIG DDname, but because different
sites have their JCL procedure DD statements in different sequences,
and since overrides have to be EXACTLY in the right order, it is now
clear that specifying CONFIG='MXG.SOURCLIB(CONFIG)' on your EXEC
statement is far safer to ensure the correct options are in effect:
// EXEC SAS606,TIME=10,
// CONFIG='MXG.SOURCLIB(CONFIG)'
These are the required options added to BATCHXA to create CONFIG:
NOIMPLMAC MAUTOSOURCE SASAUTOS=SOURCLIB MEMSIZE=12M
FULLSTATS STIMER
The MEMSIZE=12M parameter only works with MVS/XA and MVS/ESA. In almost
all of my tests, 12M was sufficient. The exceptions were when BUILDPDB
was "tailored" and many additional SMF records were added to BUILDPDB
using the EXPDB... exit facility. One large site with heavy user SMF
record additions to BUILDPDB reported they needed 24MB. Since this is
all virtual storage, and above the line, and only during the "build"
phase in MXG processing, it should not cause a problem. If you really
are limited in virtual storage (or are trying to execute MXG 8.8 with
SAS 6.06 under MVS/370) you can significantly reduce the virtual memory
requirement by specifying BLKSIZE=4096 or even 1024. Small blocks will
reduce the virtual memory size, but can significantly increase the real
CPU time, run time, I/O interrupts, and the amount of real memory used.
See the paper on blocksize in Chapter 42 of the MXG Guide.
3. Format library differences between MVS SAS 6.06-5.18.
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.06, formats are members of a SAS data library,
which must be allocated as SPACE=(CYL,(1,1)). Note there is NOT
a third parameter in SPACE (for PDS directory blocks) because data
libraries in SAS 6.06 are physical sequential files.
SAS 6.06 formats 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.
4. CMS-MXG Installation and Execution Considerations.
a. CMS Format libraries are different.
MXG Formats are created under SAS 6.06 by executing member FORMATS,
which creates a SAS Catalog that is named 0FORMATS LIBRARY (yes, the
first character is a numeric zero and the third an alphabetic "oh").
Since this catalog contains all of the MXG Formats, the installation
instructions on page 120 of the MXG Supplement ("iv. Optionally copy
TEXT into TXTLIB") no longer apply. Also the SASLIB SASLIB option in
the example is not used to access SAS 6.06 Formats (although SASLIB
SASLIB is still valid in SAS 6.06 to access SAS 5.18-built formats).
As long as the 0FORMATS LIBRARY file built by member FORMATS is on
your first disk, SAS 6.06 will automatically find MXG formats there.
b. Virtual Storage requirement for MXG and SAS 6.06 with VM/370.
Executing under VM/370, MXG 8.8 needed a 10MB machine for BUILDPDB.
It is necessary to use the NOSSEG option to disable the "SAS Saved
Segment" to use addresses above 7MB, because the SAS Saved segment
begins at address 7MB! The NOSSEG only applies to this machine,
and is needed only for the big virtual memory programs that build
lots of MXG datasets simultaneously (like VMACVMXA, VMACVMON, etc.).
The rest of MXG needs only a 4MB machine under VM/360.
The BLKSIZE is set small in the REXXTES6 exec, so that the virtual
storage required for the biggest MXG programs (BUILDPDB) would fit in
the 10 meg I could get under VM/370, but you should experiment to use
the largest BLKSIZE you can (and still compile the data step!). Small
block size reduces only the virtual storage size; a large block size
will reduce CPU time, elapsed time, I/O interrupts, and will actually
reduce the real memory required (always true for sequential access,
and building SAS datasets with MXG is a sequential process)!
Executing under VM/XA, MXG 8.8 was tested in a 16MB machine.
c. CMS SAS 6.06 ZAPs required.
SAS ZAPS Z6062068 (add) and Z6060508 (remove) appear to solve the
only serious CMS SAS 6.06 problem. Without the zap, CMS MACLIB
CONCAT concatenation fails, and you cannot read members from the
second concatenation.
d. CMS Testing Notes.
The REXX exec that was used for MXG testing with CMS SAS was printed
in MXG Newsleter EIGHTEEN and is contained in member REXXTST6.
Before the exec is invoked, you must first issue the DEFINE STOR 10M
command, followed by the IPL CMS command. All datasets are sent to
your "T" disk, a temporary disk (199 cylinders in the exec) that will
go away at logoff, unless you use the USER= SAS option, or PROC COPY.
One Irritating problem in my testing of MXG with CMS is IBM's fault:
There is no CMS equivalent for "DD DUMMY" or NULLFILE. Under MVS,
NULLFILE lets me syntax check all MXG code by dummying input files.
Under CMS I had to create pseudo records (but with RECFM=VB, instead
of RECFM=VBS) because of Another Irritating IBM feature:
CMS only partially supports the VBS record format:
CMS only reads, and can not create/write/copy VBS files, and
CMS ABENDs if it gets an SMF record with LRECL=32760.
All this, to verify that ALL of MXG executes under SAS/CMS, for those
sites who have only a SAS/CMS license and use MXG to process both the
VM and SMF data under CMS.
V. Documentation of MXG Software.
Member CHANGES always contains the version number of MXG Software, and
it lists changes that were installed in that version. Several members
named CHANGEnn are the contents of changes when that "nn" MXG version
was created. Details on 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 also 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 altered or added by that change, and documentation (especially for
new product support) is often found in comments at the beginning of
those named members.
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 26,355 variables from the 791 MXG data sets
that can be 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 VMAC...'s
that actually create the data set, or ANAL....'s that analyze the MXG
datasets. In many instance, the MXG Variable is the IBM or Vendor's
documented field name. In other cases, the IBM field name is carried as
a comment beside the MXG variable that contains that information. In
all cases, you should also have the Vendor's documentation of the
particular data record you are using for analysis.
VI. MXG Version 8.8 Installation, Space, Compatibility, etc.
MXG Compatibility Exposures in MXG Version 8 for Existing Users:
a. The SAS options required by MXG for execution have changed.
b. Execution under SAS 6.06 is different than under SAS 5.18.
c. To create your PDB directly on tape, IMACCICS must be changed.
d. If you have added additional SMF record processing to BUILDPDB,
and you still execute MXG under SAS 5.18, you may encounter a
SAS Version 5.18 Compiler Limit "344" error. BUILDPDB is larger.
See Change 7.038 in member CHANGE07 for 344 error circumvention.
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 were found in Chapter 32 of the MXG
Supplement for both new installation and for version replacement, and
those instructions, plus this discussion, is still usable. MXG SOURCLIB
member INSTALL will be a complete rewrite of Installation Instructions
for MXG, consolidating both Chapter 32s and these notes. After you have
unloaded MXG 8.8 SOURCLIB and read these notes, read member INSTALL.
This MXG tape is distributed as a Non-Labelled (NL) tape with a single
file, DCB=RECFM=FB,LRECL=80,BLKSIZE=6160, that is actually an unloaded
Partitioned Data Set containing 1370 members (and about 309,959 source
lines) in IEBUPDTE format.
Under MVS use the IEBUPDTE utility to build MXG.SOURCLIB PDS library.
Under CMS use the TAPPDS command to build SOURCLIB MACLIB library.
Under MVS, MXG Version 8.8 MXG.SOURCLIB requires SPACE=(CYL,(40,1,299))
and DCB=(RECFM=FB,LRECL=80,BLKSIZE=23440) on DASD.
Under CMS, approximately the same space (40 cylinders) will eventually
required by the MXG SOURCLIB MACLIB, but during the CMS installation
process you should have at least 100 free cylinders on your minidisk.
MXG is tailored and extended by "Installation Macro" members (begin with
IMAC) and the "MXG Exit Facility" members (begin with EX) that are put
in the installation's "USERID.SOURCLIB", the "MXG Tailoring" library,
that is concatenated ahead of MXG.SOURCLIB in your 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)); for CMS create an equivalent MACLIB.
Changes are made by copying the member from my library to your library.
IMAC.... members are self-documenting. IMACAAAA indexes all IMACs.
You should create a member CHANGES in your USERID.SOURCLIB and record
therein chronologically the MXG tailoring and installation history,
just like the member CHANGES in MXG.SOURCLIB tracks MXG itself.
You must now browse the members in USERID.SOURCLIB. If there are VMACs
members, they will override the new MXG code, and should be removed now.
However, the real purpose of USERID.SOURCLIB is for normal tailoring of
MXG for your site. It is completely normal to have some members there:
If you have installed printed changes from an MXG Newsletter, you
would have copied member(s) from MXG.SOURCLIB into your site's
USERID.SOURCLIB and then made the changes therein, or alternatively,
you would have made a new PDS (we suggested the name MXG.CHANGLIB)
into which you put those in-between-version changes, concatenating
it between USERID.SOURCLIB and MXG.SOURCLIB until you receive this
new MXG Release. In either case, if you made temporary changes,
now is the time to remove them. Delete the changed VMACs members
from your USERID.SOURCLIB, or remove the MXG.CHANGLIB from your
SOURCLIB concatenation.
If you have tailored IMAC.... members in your USERID.SOURCLIB, and
that member was changed by the new MXG Version, you must compare your
member with the new MXG member, and retrofit your tailoring on the
new member. These IMACs are of particular importance, if they exist:
IMACPDB (options for BUILDPDB) has changed and must be retrofit.
IMACKEEP can cause syntax errors when MXG creates a new dataset from
an existing record. MXG 8.8 support for CICS/ESA adds new
CIC.... datasets in TYPE110/VMAC110 processing. If IMACKEEP
had been used to tailor the variables kept in CICSTRAN by
redefining the _VAR110 macro (an appropriate use of this
tailoring exit), the new dataset will cause "Dataset not in
DATA statement" SAS error condition), unless you retrofit
your _VAR110 changes starting with MXG 8.8.
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 data set, 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 new IMAC.... members, and if there is a difference,
you MUST start with this version's IMAC and retrofit your
installation's tailoring.
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 the MXG utility UTILPRAL.
VII. Change Log
==========================Changes Log=================================
You MUST read each Change description below to determine if a Change
will impact your installation. All of these changes have been made
to this MXG Source 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 printed NEWSLETTER (which might have
printed only the easily installed, critical part of the correction).
Always read the comments at the beginning of each source member named
under the Change Number for impacting changes.
Documentation of new datasets and variables, validation status, notes,
etc., are usually in comments in the source members.
Alphabetic INDEX of the most significant changes in MXG 8.8.
Member Change Description
ANALDB2R 8.030 DB2 Reporting from GTF data failed.
ANALDB2R 8.031 DB2 Report PMLOK03 fails with 170 format error.
ANALDB2R 8.067 Report selection by time frame incorrect, minor.
ANALDB2R 8.084 DB2 Trace reporting with PDB=SMF avoids IMAC102.
ANALDB2R 8.121 PMAUD02/PMAUD03 request caused SAS 145/170 error.
ANALDB2R 8.280 Transit time and SQL reports added.
ANALDBTR 8.249 DB2 Trace record pairing (SnnnSnnn) datasets built.
ANALDSET 8.077 ACCESS variable was not created, report failed.
ANALDSET 8.223 EXCP count deaccumulation from SMF 14/15 corrected.
ANALPRTR 8.146 New printer capacity analysis system.
AS400PDS 8.278 AS400 Records processing.
ASMTMNT 8.070 MXG Tape Mount Monitor on 7.7 does support MVS/ESA.
ASMVTOC 8.117 Assembly program for Fast reading of DASD VTOCs.
ASUMCICS 8.023 Variable LENGTHs caused trunction.
ASUMJOBS 8.230 Duplicate-Job-Name-Hold delay time estimated.
BUILDPDB 8.069 ACCOUNT/SACCT in SMFINTRV, SPIN in PDB, TYPE25 added.
CICINTRV 8.182 New CICINTRV (CICS/ESA Interval Statistics) dataset.
CICINTRV 8.251 New CICEODRV (CICS/ESA Shutdown Statistics) dataset.
CONFIG 8.068 SAS 6.06 options member added to MXG library.
DIFFHSM 8.260 HSM User SMF Record de-accumulation.
DOCDB2PM 8.112 Documentation of DB2PM-like reports in ANALDB2R.
DOCGRAF 8.274 SAS/GRAPH device support and MXG standards.
DOCTREND 8.113 Incompatible changes in MXG Trending implemented.
EXACFJR 8.047 ACF2 dataset ACF2JR may have deleted observations.
EXIDMTAS 8.105 IDMS Batch ACCOUNT1-3 fields decoded.
FMXGUCBL 8.009 Returns wrong value under SAS 5.18.
GRAFDB2 8.275 SAS/GRAPH analysis of DB2 data.
GRAFWORK 8.140 New graphic report of RMFINTRV workloads by hour.
IMACAAAA 8.281 Install aid describing which tailoring IMACs do what.
IMACACCT 8.133 Safer/Easier user tailoring of kept Account fields.
IMACICDB 8.177 CICS/ESA 3.1 Transaction DBCTL counters/clocks.
IMACPDB 8.048 Variables ABNDRSNC DIVRREAD DSSIZHWM TERMNAME added.
JCLDASD 8.264 MXG DASD (VTOC,VVDS) Space Management example.
JCLTEST 8.001 Options MACRO DQUOTE MWORK=28K required by MXG 7.7.
JCLTEST 8.025 WORK.DIRMACR REQUIRES MORE SPACE error condition.
JCLTREND 8.058 PROC SORT added to avoid not-sorted condition.
MONTHBLD 8.095 Syntax error under SAS 6.06 circumvented.
MVS 4.1 8.167 Support for MVS/ESA SP Version 4.1 and RMF 4.2.
MVS 4.2 8.224 Support for MVS/ESA SP Version 4.2 and RMF 4.2.1
NPM 8.038 NPM records from VM can be processed.
PRODUCTS 8.282 Documents MXG support by "product name/acronym"
RMFINTRV 8.216 SIO counts in RMFINTRV missing.
SAS 6.06 8.283 "Dataset is not sorted" SAS Error fixed by Z6062141.
SPIN 8.158 SPIN library fills when MVS/ESA replaces MVS/XA.
SPIN 8.172 SPIN library fills when MVS/ESA replaces MVS/XA.
SPUNJOBS 8.258 New PDB.SPUNJOBS dataset for SPIN reporting.
TRND72 8.143 Critical error, but only in PreRelease 8.3
TRNDDB2A 8.276 TRENDing for DB2ACCT into MXG Trend database.
TRNDDB2S 8.279 TRENDing for DB2STAT0 and DB2STAT1.
TRNDRMFI 8.143 Critical error, but only in PreRelease 8.3.
UTILGETM 8.206 %MACRO on FILE statement CPU loop in SAS 6.06.
VMAC110 8.065 Support for new CICS 3.1.1 major changes.
VMAC1415 8.017 New hiperbatch counts added to SMF type 1415.
VMAC1415 8.137 Hiperbatch values non-zero when they should be zero.
VMAC23 8.208 SMF writer memory usage added (OY27449).
VMAC28 8.111 INPUT function error in NPM subtype 82.
VMAC28 8.148 Support for NPM Release 4 (NPM 1.4), SMF Type 28.
VMAC30 8.081 Support for APAR adding DDCONS() option.
VMAC30 8.082 Support for APAR adding PROCSTEP to type 30s.
VMAC30 8.208 NOT CATLG 2 or 7 now added (APAR OY24857) to 30s.
VMAC37 8.022 Variable KEEP, FORMATs.
VMAC39 8.022 TYPE39EL conditionally created. ZDATE kept.
VMAC39 8.245 Support for NETMASTER V2.1.0 subtype 255.
VMAC41 8.015 New VLF counts in new subtype 3 SMF type 41.
VMAC42 8.136 STOPOVER on subtype 3 due to IBM error.
VMAC57 8.184 STOPOVER on type 57 (MVS 4.1 and MXG 8.5 only).
VMAC6 8.057 STOPOVER due to invalid external writer record.
VMAC60 8.128 STOPOVER on SMS NVR segment in type 60.
VMAC6156 8.027 STOPOVER error with ICF catalog record section.
VMAC6156 8.039 TYPE6156 VOLSER may be wrong for GDGs.
VMAC6156 8.214 "Invalid Third Argument to Function SUBSTR."
VMAC64 8.134 ACBMACRF fields individually decoded into variables.
VMAC64 8.219 TYPE64 hiperbatch variables missing.
VMAC64 8.234 VSAM Hiperbatch counters corrected.
VMAC7072 8.066 Support for new "SRCL" field in RMF Product section.
VMAC7072 8.187 Support for new Hitachi processors with MLPF.
VMAC7072 8.233 "Invalid data for MSOCOEFF..." correction.
VMAC7072 8.250 Support for PR/SM "overhead" measure APAR OY36668.
VMAC76 8.254 Support for OPPSI in SYSPLEX is traceable.
VMAC78 8.049 TYPE78CF only output if CHPID is online.
VMAC78 8.132 STOPOVER on type 78 subtype 3 with ES/9000 CPUs.
VMAC79 8.012 STOPOVER correction, support validation.
VMAC79 8.055 Formats and units corrections.
VMACACF2 8.002 ACF2 SMF record caused STOPOVER.
VMACACF2 8.090 Further validation of ACF2 SMF record.
VMACARB 8.190 Support for Arbiter Version 2.1.1 SMF records.
VMACCIMS 8.064 Support for IMF 2.6 (for IMS 3.1).
VMACCMF 8.247 Support for Boole & Babbage CMF SMF record 240.
VMACCRAY 8.044 Support for CRAY COS operating system
VMACDB2 8.102 Distributed DB2 header added to DB2ACCT.
VMACDB2 8.225 Support for Landmark's The Monitor for DB2.
VMACDCOL 8.130 DCOLLECT enhancement for all seven records.
VMACDCOL 8.210 DCOLLECT migration/backup tape dates correction.
VMACDCOL 8.252 Support for DCOLLECT APAR OY37378.
VMACDCOL 8.074 Support for SMS DCOLLECT data records.
VMACDMON 8.003 Uninitialized variable in ANALDMON caused.
VMACDMON 8.236 Support for LEGENT ASTEX replacement for DASDMON.
VMACEPMV 8.217 Support for Candle's EPILOG for MVS SMF Type 180.
VMACHSM 8.138 Preliminary support for HSM User SMF records.
VMACIDMS 8.005 IDMS/R SMF record variables format incorrect.
VMACIMS 8.006 IMS crashes required duplicate DTOKEN protection.
VMACIMS 8.098 Support for IMS/ESA 3.1 log records.
VMACIMS 8.118 IMS Cold start support and logic changes.
VMACIMS 8.119 Correction of IMS Input Queue time.
VMACIMS 8.176 IMS 3.1 DBCTL Thread Transactions Deleted.
VMACIMS 8.256 Support for IMS Wait-for-Input from IMS log.
VMACMDF 8.091 Amdahl's MDFTRACH SMF records corrected.
VMACMEMO 8.227 Support for MEMO European Electronic Mail SMF record.
VMACMON8 8.161 Support for Landmark's Monitor for CICS Version 8.0
VMACMONI 8.036 CREATIME in MONITASK may have wrong date.
VMACMPT 8.173 Support for Amdahl's MDF Performance Tool
VMACNSPY 8.010 NETSPY 3.2 support was incomplete.
VMACNSPY 8.043 Netspy 3.1 STOPOVER.
VMACNSPY 8.265 Support for NETSPY Release 4.0.
VMACORAC 8.080 Support for Oracle SMF record.
VMACROSC 8.028 ROSCOAUD contained zero observations always.
VMACSASU 8.157 SAS User Record changed under SAS 6.06.
VMACSESA 8.228 Support for Volvo's SESAME VTAM Monitor.
VMACSMF 8.013 DB2 read from GTF. Minor.
VMACSPMS 8.149 Support for Amdahl's SPMS SMF (Cache DASD CU).
VMACSTC 8.092 STC 4400 Silo SMF record new subtype.
VMACSTC 8.194 STC 4400 Silo SMF record new subtype STOPOVER!
VMACSYNC 8.020 Invalid CPUTCBTM value detected.
VMACSYNC 8.056 SIRECFM,SORECFM contain invalid data value.
VMACSYNC 8.123 Error (only in PreRelease 8.2) in TYPESYNC data.
VMACSYNC 8.211 SYNCSORT EW2903 detects SAS invoked Sort.
VMACSYNC 8.253 Support for SYNCSORT SCZ 33038 (Hiperspace stats).
VMACTMNT 8.033 Minor. Formats for DEVFROM/DEVTO.
VMACTMVS 8.173 Protection for TMON/MVS Spanned Records
VMACTPNS 8.269 Support for TPNS log.
VMACTPX 8.016 No observations in TPXINTRV.
VMACTSOM 8.007 Missing STRTTIME in TSOMCMND.
VMACTSOM 8.104 Invalid READTIME due to CA7 in TSO/MON record.
VMACTSOM 8.262 Support for LEGENT TSO/MON Release 5.3.0.
VMACVMON 8.037 Divide by zero.
VMACVMON 8.045 24APR90 became 02OCT89 when 202 day clock wrapped.
VMACVMON 8.106 VM Start Time off by 43 minutes on Aug 4, 1990.
VMACVMXA 8.004 OMEGAMON/VM creates invalid VM/XA VB records.
VMACVMXA 8.099 Many VM/XA PTFs altered Monitor records.
VMACVMXP 8.041 Minor EXPLORE/VM processing changes.
VMACVPD 8.234 Support for NETVIEW's VPD aka NAM type 37 SMF data.
VMACVVDS 8.073 Validation of VVDS record created by ASMVVDS.
VMACWSF 8.100 Support for WSF archive product SMF.
VMACX37 8.024 STOPX37, minor.
VMACZRB 8.054 RMF 4.1.1 caused STOPOVER.
VMACZRB 8.079 Further validation of RMF III VSAM data.
VMACZRB 8.156 Further validation and reports.
VMXGDOWN 8.273 Download to PC all datasets in a SAS library.
VMXGSUM 8.021 Missing variable initialization protection.
VMXGVTOC 8.018 OFFSET4E and SMS variables added.
VMXGVTOC 8.032 Minor. RECFM should be $4.
VMXGVTOC 8.075 Did not capture free space at beginning of volume.
VMXGVTOF 8.193 Build VMXGVTOC datasets from ASMVTOC records.
VMXGVTOR 8.009 Incorrect on 7.7, changes not propagated.
XMAC7072 8.014 ZDATE not kept in TYPE70PR and TYPE72MN
ZZZZZZZZ 8.011 Final member of MXG Library is named.
Inverse chronological list of all Changes:
NEXTCHANGE: Version 8 72
--- Changes 8.305 thru 8.286 were added after MXG 8.8 was shipped ---
Change 8.305 About 90 of the 32,000+ MXG variables had no labels, some
many obsecure datetime variables were not formatted, and some
Apr 30, 1991 variables were length 8 when they should have been only
4 bytes long, as discovered in the MXG QA jobstreams. All
of these that could be corrected easily were!
Change 8.304 Type 79 support (RMF Monitor II) has now been extended
VMAC79 backwards to include RMF 3.5.1, and code was cleaned up
Apr 29, 1991 with this significant user contribution.
Thanks to Gordon Keehn, Fidelity Mutual Life Insurance Company, USA.
Change 8.303 IMS Log processing temporary variable OENQTO should have
TYPEIMS been spelled OENQO in line 107900.
Apr 28, 1991
Change 8.302 VM/ESA variable CHANBYTM was stored 8 bytes, but can be
VMACVMXA stored in only 4 bytes. Add CHANBYTM before DURATM in
Apr 28, 1991 the LENGTH statement at the end of line 060650.
Change 8.301 The New DB2 Trending members run fine the first week, but
TRNDDB2S in subsequent runs, the three shifts in prior weeks data
Apr 28, 1991 are summarized into a single observation for the entire
week (and SHIFT appears as Weekend). The recalculation
of SHIFT in trending should have only been applied to the
new PDB data, but bad logic caused the corruption.
This correction is for the DB2 Statistics trending member
TRNDDB2S. See Change 8.300 for DB2 Account trending.
1. The INCODE= argument at 005200:
INCODE = 005200
IF INWEEK THEN NUMINTVL = 1; 005300
LABEL NUMINTVL='NUMBER OF*STATISTICS*INTERVALS'; 005400
OUTPUT MXGSUM1; 005500
DATA MXGSUM1 005600
TIMES 005700
(KEEP=SYSTEM SHIFT QWHSSSID QWHSSTCK MINTIME MAXTIME); 005800
SET MXGSUM1; 005900
IF DURATM GT 0 THEN MINTIME=QWHSSTCK-DURATM; 006000
ELSE MINTIME=.; 006100
MAXTIME=QWHSSTCK; 006200
%VMXGDUR(DATETIME=QWHSSTCK,INTERVAL=WEEK,NEWSHIFT=Y); 006300
QWHSSTCK=DATETIME; 006400
OUTPUT MXGSUM1; 006500
OUTPUT TIMES;, 006600
Must be changed to read
INCODE = 005200
IF INWEEK THEN DO; 005300
NUMINTVL = 1; 005310
IF DURATM GT 0 THEN MINTIME=QWHSSTCK-DURATM; 005320
ELSE MINTIME=.; 005330
MAXTIME=QWHSSTCK; 005340
%VMXGDUR(DATETIME=QWHSSTCK,INTERVAL=WEEK,NEWSHIFT=Y); 005350
QWHSSTCK=DATETIME; 005360
END; 005370
LABEL NUMINTVL='NUMBER OF*STATISTICS*INTERVALS'; 005400
OUTPUT MXGSUM1; 005500
DATA MXGSUM1 005600
TIMES 005700
(KEEP=SYSTEM SHIFT QWHSSSID QWHSSTCK MINTIME MAXTIME); 005800
SET MXGSUM1; 005900
QWHSSTCK=DATETIME; 006000
OUTPUT MXGSUM1; 006500
OUTPUT TIMES;, 006600
2. The INCODE= argument at 012300:
INCODE = 012300
IF INWEEK THEN DO; 012400
IF QXMSMIAP=. THEN QXMSMIAP=.; 012500
IF QXNSMIAP=. THEN QXNSMIAP=.; 012600
IF QXNSMIAP=. AND QXMSMIAP GT 0 THEN QXNSMIAP=QXMSMIAP; 012700
END; 012800
OUTPUT MXGSUM1; 012900
DATA MXGSUM1 013000
TIMES 013100
(KEEP=SYSTEM SHIFT QWHSSSID QWHSSTCK MINTIME MAXTIME); 013200
SET MXGSUM1; 013300
IF DURATM GT 0 THEN MINTIME=QWHSSTCK-DURATM; 013400
ELSE MINTIME=.; 013500
MAXTIME=QWHSSTCK; 013600
%VMXGDUR(DATETIME=QWHSSTCK,INTERVAL=WEEK,NEWSHIFT=Y); 013700
QWHSSTCK=DATETIME; 013800
OUTPUT MXGSUM1; 013900
OUTPUT TIMES;, 014000
Must be changed to read
INCODE = 012300
IF INWEEK THEN DO; 012400
IF QXMSMIAP=. THEN QXMSMIAP=.; 012500
IF QXNSMIAP=. THEN QXNSMIAP=.; 012600
IF QXNSMIAP=. AND QXMSMIAP GT 0 THEN QXNSMIAP=QXMSMIAP; 012700
IF DURATM GT 0 THEN MINTIME=QWHSSTCK-DURATM; 012710
ELSE MINTIME=.; 012720
MAXTIME=QWHSSTCK; 012730
%VMXGDUR(DATETIME=QWHSSTCK,INTERVAL=WEEK,NEWSHIFT=Y); 012740
QWHSSTCK=DATETIME; 012750
END; 012800
OUTPUT MXGSUM1; 012900
DATA MXGSUM1 013000
TIMES 013100
(KEEP=SYSTEM SHIFT QWHSSSID QWHSSTCK MINTIME MAXTIME); 013200
SET MXGSUM1; 013300
DATETIME=QWHSSTCK; 013800
OUTPUT MXGSUM1; 013900
OUTPUT TIMES;, 014000
Change 8.300 The New DB2 Account Trending has the same problem cited
TRNDDB2A for the DB2 Statistics Trending discussed above in the
Apr 28, 1991 Change 8.301.
This correction involves also requires two parts:
1. The two lines, 012900-013000, now reading:
MINTIME=QWACBSC; 012900
MAXTIME=QWACESC; 013000
Must be MOVEd to after 004900 (MOVE, not COPY!).
2. Then, the two lines, 019800-019000, now reading:
%VMXGDUR(DATETIME=QWACESC,INTERVAL=WEEK,NEWSHIFT=Y); 019800
QWACESC=DATETIME; 019900
Must be MOVEd to after the lines just moved above.
The end result of these two moves will be:
IF INWEEK THEN DO; 004900
MINTIME=QWACBSC; 004910
MAXTIME=QWACESC; 004920
%VMXGDUR(DATETIME=QWACESC,INTERVAL=WEEK,NEWSHIFT=Y); 004930
QWACESC=DATETIME; 004940
IF QXMSMIAP = . THEN QXMSMIAP = .; 005000
Change 8.299 A "Variable Not Found" condition occurs with ANALDB2R if
ANALDB2R the Accounting Trace Long report was requested by itself.
Apr 28, 1991 (If any other report was also requested, this error does
not occur). Line 021820, which now reads:
TIMES (KEEP=&SORT1 &SORT2 &SORT3 MINTIME MAXTIME);
was replaced by these 6 lines:
%IF &PMACC02 EQ YES %THEN %DO;
TIMES (KEEP=&SORT1 &SORT2 &SORT3 MINTIME MAXTIME);
%END;
%ELSE %DO;
TIMES (KEEP=DB2 MINTIME MAXTIME);
%END;
Thanks to Ron Roberts, The Equitable Life Assurance Society, USA.
Change 8.298 Fujitsu's AIM database manager (CICS-like) SMF records
VMACAIM2 were in error. The FILLER $CHAR2. in VMACAIM2 line 117
VMACAIM3 was deleted. In VMACAIM3, NUMSCHMA is PIB2, not PIB4,
Apr 28, 1991 and the DO loop in line 65 should be 1 to NUMSCHMA. These
changes were received long ago and should have been in
earlier versions. Thanks for the contributor; Bill has
provided them locally to Fujitsu sites down under!
Thanks to Bill Gibson, SAS Institute, AUSTRALIA.
Change 8.297 Support for Fujitsu's FACOM operating system now includes
TYPEPDL both MSP and FSP data from PDL reports from PDA records.
TESTFACO Former "X-rated" member XPDLPDA is now renamed TYPEPDL,
JCLTEST and first-time-logic added for history datasets. The MXG
JCLTEST6 test and cross reference jobstreams now separately test
JCLUXREF all FACOM support in step TESTFACO, so that all 25 of the
JCLUXRE6 RTYPExx datasets and histor datasets created by TYPEPDL
are documented in DOCVER. The coding changes that added
FSP support were a significant user contribution, and
also added decoding of several additional PDL reports.
Thanks to Ian Heaney, M.L.C., AUSTRALIA.
Change 8.296 VM/XA processing requires more work space that it should
VMACVMXA because the PROC DATASETS to delete VXUSEINT and VXACTINT
Apr 19, 1991 was commented out during testing. Remove the comments in
line 798400. Also, variable RDEVOFFL was not kept because
it was misspelled as RDEFOFFL in the KEEP= list.
Thanks to Jay Cicardo, Southwestern Bell, USA.
Change 8.295 SAS datasets will be destroyed/corrupted by CASORT 6.6
CASORT 6.6 if its ATTRLS Option (system wide, set when CASORT was
Apr 18, 1991 installed) was specified ATTRLS=YES. Instead, you MUST
have ATTRLS=NO. With ATTRLS=YES, CASORT will RLSE sort
work space after each invoked SORT, which somehow causes
SAS to think all records were deleted by NODUP, and the
output dataset built by the PROC SORT contains either
zero or one observation! If there is one observation,
all of its numeric variables are zero or missing, which
happened with RMFINTRV, and the garbaged dates/times
put messages on the SAS log, but then caused the TREND
database to be overwritten with only one observation!
CA says the problem is known to affect ANY invoked sort,
not just SAS invoked sorts. SAS tracking 180027 is open,
to determine why SAS built the corrupted 1-observation
data set, and I will investigate how I can make the trend
logic more robust, but you MUST specify ATTRLS=NO to fix
the real problem with CASORT 6.6.
Thanks to Arnold Ruterbories, Standard Insurance Company, USA.
Change 8.294 Additional SAS 6.06 error conditions have been reported.
SAS 6.06 a.VMXGVTOC will fail "VARIABLE VOLSER NOT FOUND", if you
Apr 18, 1991 installed SAS ZAPs Z6061834 or Z6062315, due to an error
introduced by those zaps (the "autovariable" VOLSER was
lost when those zaps were installed). SAS ZAP Z6062674
now exists to correct their error and is required. It is
not on the April SAS Notes tape, but can be downloaded.
b.SAS will ABEND with an 0C4 in SMS sites, if the datasets
in the CONFIG DD concatenation are SMS-managed datasets,
if the CONFIG= JCL parameter is used. (If you used the
prior MXG technique of actually overriding the CONFIG DD,
this abend does not occur, but then you must be careful
to order the JCL override, thus the CONFIG= parameter was
recommended instead of overriding the CONFIG DD!) The SAS
error is fixed by ZAP Z6062264, which is required if your
site has SMS-managed datasets for SAS and or MXG.
Change 8.293 a.IBM's Cache DASD RMF Reporter "CRR" Product's SMF records
ANALCACH status bits were changed (don't know when!) and count of
FORMATS sequential-detected sequential read requests was added.
VMACACHE Variables have been dropped from CACHE90. Flag variables
Apr 18, 1991 (CSCS1-CSCS8,CSNVSS1-CSNVSS8, CSDP,CSCD,CSFF,CSFD,CSPD,
CSSD,CSFC,CSPP) are replaced by format-decoded variables,
and the caching/fastwrite/pinning/etc. status variables
from the CSVOL segment (which apply only to that CSVOL,
and not to the VOLUME being reported) are not kept. IBM's
3990 Storage Control Reference, GA32-0099-3, pp 171-177,
Chapter 4, Command Descriptions, describes the statistics
captured much better than the CRR manual (SH20-6295-4).
CACHE90 variable FWDC, the count of DASD fast write ops
that were forced to access DASD directly (because the
nonvolatile storage was insufficient), may be important
in recognizing this performance degredation.
b.The Cache analysis program ANALCACH was revised to now
CACHE90 (instead of the CACHETY data from 3880's) along
with RMF TYPE74 data for sample reports.
Thanks to Victor Heiner, Northwest Airlines, USA.
Thanks to Alfred Holtz, Dun and Bradstreet, USA.
Change 8.292 Boole & Babbage CICS Manager product causes MXG messages
VMAC110 "Unexpected Statistics Subtype" with STID=200 to 210, due
Apr 16, 1991 to that product's pseudo type 110 statistics records. The
additional records will be supported in the future.
Thanks to Paul Dean, IBM Hursley, ENGLAND.
Change 8.291 Variables EXCPTOTL and IOTMTOTL should have been in the
ASUMJOBS KEEP= list for dataset BATCHJOB (added by Change 8.230
Apr 16, 1991 for detect duplicate job hold enhancement).
Thanks to Elliot Weitzman, Oryx Energy Company, USA.
Change 8.290 MVS Account Fields with length=0 create MXG error message
IMACACCT "***ERROR.IMACACCT.ACCOUNT FIELD n LENGTH WRONG", and any
Apr 16, 1991 account fields after the zero length field are skipped.
If the "n" in the message is greater than the number of
Account Fields you are KEEPing, there is no impact on the
datasets built by MXG. The enhancement in Change 8.267
(to prevent STOPOVER if account length were wrong) failed
to allow for a zero length field. The nine lines that
now read "ELSE DO;" must be change to read:
(line number)
ELSE IF LENACCT1 GT 0 THEN DO; 012300
ELSE IF LENACCT2 GT 0 THEN DO; 014000
ELSE IF LENACCT3 GT 0 THEN DO; 015700
ELSE IF LENACCT4 GT 0 THEN DO; 017400
ELSE IF LENACCT5 GT 0 THEN DO; 019100
ELSE IF LENACCT6 GT 0 THEN DO; 020800
ELSE IF LENACCT7 GT 0 THEN DO; 022500
ELSE IF LENACCT8 GT 0 THEN DO; 024200
ELSE IF LENACCT9 GT 0 THEN DO; 025900
This error occurs ONLY if your IMACACCT was tailored from
MXG version 8.8.
Thanks to Mike Hoevenaars, Toyota Canada, CANADA.
Change 8.289 ACF2 Release 5.2 added four variables (ACPMFCPM,ACPMFCJN,
VMACACF2 ACPMFCJI, and ACPMFCLI to the ACF2PR dataset & variables
Apr 16, 1991 ACVMFLRT, ACFMFTRT, and ACVMFTRS to ACF2VR dataset.
Thanks to Dave Greene, Kwasha Lipton, USA.
Change 8.288 Format MGSYNDB for SYNCSORT value 2 should have formatted
FORMATS to 2:3390 instead of the (now nonexistent) 2:3330 device,
Apr 16, 1991 and values 16 and 24 were added to ACF2 formats MGACFDA
and MGACFDB respectively.
Thanks to Dave Greene, Kwasha Lipton, USA.
Change 8.287 Member VMACEPIL on the original MXG 8.8 tape was wrong.
TESTOTHR Instead of the complete revision of support for Candle's
VMACEPIL EPILOG/CICS, VMACEPIL contained a copy of member CHANGES!
Apr 16, 1991 This error also caused JCLTEST step TESTOTHR to fail.
This change simply puts back VMACEPIL in VMACEPIL!
Thanks to Rex Pommier, St. Lukes Hospital Fargo, USA.
Change 8.286 IEBUPDTE unload of MXG 8.8 ends with condition code four,
V88-tape prints "IEB823I SYSIN HAS NO RECORDS for AS400PDS", and
Apr 11, 1991 MXG.SOURCLIB contains 1394 members instead of the stated
1367 members, but this warning has no real impact on the
MXG.SOURCLIB data set. The warning occurs because member
AS400PDS itself was an IEBUPDTE input for a 28-member PDS
with preliminary support for AS400 data. Your unload saw
those "./" statements and created the 28 members starting
with @@@....., AS400..., ICEGENER, and QAPM.... directly
in your MXG.SOURCLIB, and then there were no lines in the
member AS400PDS, causing the warning! I had intended to
change the "./" to "xy" in AS400PDS to avoid this warning
but failed to do so. Sorry for all those phone calls and
faxes that would have been avoided by better testing.
Thanks to Ken Thomas, Maryland Casualty Company, USA.
--Changes thru 8.285 are included in MXG Version 8.8 dated Apr 8, 1991-
Change 8.285 A surprising discovery by looking at DCOLLECT data. DASD
VMACDCOL capacity stated by IBM (eg, 630MB for a 3380 volume) is
Apr 4, 1991 NOT 630 Megabytes, but instead is 630 "Million bytes"!
A 3380 (47476*15*885 = 630,243,900 bytes) actually stores
only 601MB (megabytes)! So much for IBM consistency in
use of "MB". Because VMACDCOL assumed MB was megabytes,
it multiplied by 1024 to convert to bytes for MGBYTES, so
this change replaced all occurrences of 1024 with 1000.
The unknown UK user also noted that the test that set the
values of DCVEVLCP, DCVEBYTK, and DCVELSPC should have
tested DCVERROR instead of DCVFLAG1.
Thanks to Derek Cespedes, Florida Power and Light, USA.
Thanks to ???, ???, ENGLAND.
Change 8.284 Major revision of support for EPILOG/CICS was finished
EXEPCIJC after Newsletter NINETEEN went to the printer. The change
EXEPCISF is INCOMPATIBLE with previous MXG EPILOG/CICS support, as
EXEPCISI the TYPEEPIL dataset no longer is created. Instead, these
five new MXG datasets are created by TYPEEPIL execution:
EXEPCISU EPILCITR - Transaction data - most important.
EXEPCITR EPILCISU - Startup.
TESTOTHR EPILCISF - Suffix.
VMACEPIL EPILCIJC - JCL Parameters
Apr 4, 1991 EPILCISI - SIT Parameters
Each dataset keeps only the appropriate variables.
VMACEPIL code was restructured, with a separate section
for Releases 450-451, which is different from 440 format.
Only EPILCITR records were available for testing from 450
but there is no change in the format when you install 451
so I anticipate no problems. While the (archaic) 440 code
might need work, Candle solves 440 problems by sending a
copy of 451!
Thanks to Richard Evans, Mervyn's, USA.
==Changes thru 8.283 were printed in MXG Newsletter NINETEEN==========
Change 8.283 SAS 6.06 errors like "Data set is not sorted" that were
SAS 6.06 discussed under Usage Note 1000 were finally resolved on
Mar 29, 1991 the March SAS Usage Notes Tape by the inclusion of SAS's
ZAP Z6062141. If you do not have the March SAS 6.06 tape
installed (it's now a 100% pre-applied ZAPed loadlib in
IEBCOPY format), you MUST at least download and install
Z6062141.
Change 8.282 This new member documents all of the "Products" that MXG
PRODUCTS supports. PRODUCTS identifies which product versions are
Mar 29, 1991 supported by which version of MXG and the member name of
the MXG member(s) that processes that product's records.
Use your online editor to search for the product name to
find the entry for a specific product, which will contain
the names of MXG datasets created, their exit names, etc.
Suggestions for enhancement are most welcome.
Change 8.281 This new member documents the IMAC.... exit members which
IMACAAAA tailor MXG for your site. Some IMACs (IMACSHFT,IMACWORK)
Mar 29, 1991 should always be tailored, but most IMACs are not needed
to be changed by most sites. This new member groups the
different purpose IMACs together to make it easier for an
installer to know which IMACs affect their site. The IMAC
itself contains self-documenting comments for its use.
Change 8.280 Transit time reports from DB2 trace are now in ANALDB2R.
ANALDB2R Selection criteria is more robust and is uniform across
Mar 29, 1991 all reports, and can include SHIFT or DB2 Trace Number.
ANALDB2R reports can be produced from either the PDB or
the new TRNDDB2x data (See Changes 8.276 and 8.279) for
Accounting and Statistics reports. Data from the TREND
databases can be input along with data from your daily
PDB to compare history with current with PDB=PDB TREND
syntax to cause ANALDB2R to combine both data sources.
Transit time and SQL trace activity analysis were added
by ANALDBTR (Change 2.249) which creates the trace-pair
data sets needed. ANALDB2R now will use those data for
these new reports, and for the I/O Activity Summary, and
eventually all DB2 trace reports will be restructured to
use the ANALDBTR trace-pairs.
Change 8.279 Summarization of DB2STAT0 and DB2STAT1 statistics data
TRNDDB2S into the TREND database uses PDB.DB2STAT0 and DB2STAT1
Mar 29, 1991 as input to create TREND.TRNDDB20 and TREND.TRNDDB21.
Summarization is by WEEK by SHIFT within SYSTEM, and DB2
Sub-System ID, QWHSSSID. Note that Version 8.8 ANALDB2R
can use these new TREND datasets as input for reports.
See DOCTREND for the structure of MXG trending.
Change 8.278 This significant user contribution for AS400 Records will
AS400PDS eventually be a fully supported part of MXG, but time ran
Mar 28, 1991 out for development and testing. This member is actually
a 27-member unloaded PDS, and is provided so that leading
edge sites who would otherwise have had to start from the
beginning, may find this a starting point for AS400 data.
It should be regarded as preliminary, unverified, and is
certain to change in structure. Your input is welcome.
Thanks to Carolyn Barnett, Sentara Health System, USA.
Change 8.277 Variables INAVG and READYAVG were added to the RMFINTRV
RMFINTRV dataset. I had actually planned to do further revisions
Mar 28, 1991 to RMFINTRV for MVS/ESA, but ran out of time!
Thanks to ???, ???, EUROPE.
Change 8.276 Summarization of DB2ACCT dataset into the Trend Database.
TRNDDB2A Input is weekly PDB.DB2ACCT into TREND.TRNDDB2A. The time
Mar 28, 1991 summarization is for each shift for each week within the
SYSTEM SHIFT QWHSSSID QWHCPLAN QWHCCN values.
Both ANALDB2R and/or GRAFDB2 will produce Accounting
Detail and Summary reports and graphs from TRNDDB2A.
See documentation in the member itself.
Change 8.275 Graphical analysis of DB2 data from MXG PDB or TREND
GRAFDB2 data libraries (three sets of graphs) can be produced
Mar 28, 1991 and a graphic catalog (default DDname of PDB) is built.
See comments in member for documentation.
Change 8.274 Documentation of the techniques implemented in MXG use
DOCGRAF of SAS/GRAPH, and briefly describes the MXG GRAF....
Mar 28, 1991 members and the graphic catalog they produce.
Change 8.273 New style macro generates the code needed to download
VMXGDOWN all of the datasets contained in a single SAS data
Mar 28, 1991 library. This utility is the logical equivalent of:
PROC DOWNLOAD DATA=PDB._ALL_ OUT=PCPDB;
which does not exist.
Thanks to Chuck Hopf, Hopf Consulting, USA.
Change 8.272 The MXG utility UTILPRAL will print all datasets in a
UTILPRAL SAS data library. This change simplifies that process
VMXGPRAL by executing as a single step with no external DD.
Mar 28, 1991
Thanks to Chuck Hopf, Hopf Consulting, USA.
Change 8.271 Graphics table added samples for IBM3825 and IBM3827
VMXGGOPT devices (but only in portrait mode; rotating requires the
Mar 28, 1991 use of templates, and is non-trivial). See SAS Technical
A SAS note xxxx that discusses rotation. Also, standard
PATTERN/SYMBOL statements were added for consistency so
they can (eventually) be used in all GRAF.... members.
Change 8.270 Printer analysis logic for NPRO was corrected and support
ANALPRTR for XEROX XPAF CPU calculation (based on testing of early
ASUMPRTR releases of XPAF) was added. The default value for NPRO
IMACPRTR is now zero, since only the (dead?) 3800-3 used NPRO.
Mar 28, 1991 For sheet printers, PAGECNT is equal to the number of
physical sheets that went through the printer; SHEETPRN
is the number of sides printed. For the printer THRUPUT
calculations, SHEETPRN is now used instead of PAGECNT if
SHEETPRN is non-zero (using PAGECNT, duplexing made the
printer's thruput half-speed)!
Thanks to Chuck Hopf, Hopf Consulting, USA.
Change 8.269 Preliminary support for log produced by IBM's TPNS. Its
TYPETPNS pretty simple, but there is not a whole lot of data.
Mar 27, 1991
Change 8.268 Because it was not always clear on the log when %VMXGSUMs
VMXGSUM invocation actually began, a RUN; statement was inserted
Mar 27, 1991 after line 019500.
Change 8.267 Protection for invalid accounting field lengths has been
IMACACCT enhanced. The total length of accounting data was always
Mar 27, 1991 compared with record length, but individual account field
lengths were not verified, until now. A site with a badly
corrupted type 30 record (due to an error in their SMF
exit code) ABEMDED with a STOPOVER. With this change, the
unnecessary STOPOVER is avoided, the bad record detected,
and an MXG message is now printed on the log. The site
chooses to remain unknown!
Change 8.266 Thanks for IBM's excellent vendor support in the CICS/ESA
Mar 27, 1991 Early Test Program, we can confirm that not only will
MXG Version 8.8 correctly process CICS/ESA 3.1 SMF data,
but also that it will not fail with CICS/ESA 3.2 records!
Change 8.265 Support for NETSPY Release 4.0 was added by this change.
EXNSPYAC Four new variables were added to the NSPYAPPL dataset,
VMACNSPY eight new variables were added to the NSPYVIRT dataset,
Mar 26, 1991 and the new NSPYACCT data set with 68 variables for the
Network Accounting type 'C' NETSPY record is created.
Thanks to Richard Warren, Solomon, Inc., USA.
Change 8.264 This change summarizes and documents the MXG DASD space
ANALVVDS management facilities that have been enhanced in 8.8.
ASMVVDS Member JCLDASD/JCLDASD6 contains the sample JCL that is
FMXGUCBL suggested to allow you to process your VTOCs and VVDS.
IMACVVDS Comments in the MXG members elaborate on each of the
JCLDASD programs discussed. Note that "ASM" members are written
TYPEVVDS in IBM Assembler and must be assembled and link edited
VMXGVTOC before they can be used. Sites which have installed
VMXGVTOF DFP 3.2 or later should first look at IBM's DCOLLECT
VMXGVTOR utility (supported by MXG's TYPEDCOL member) to measure
Mar 26, 1991 their DASD farm, as it may be adequate for most sites.
The VTOC/VVDS processing described below gives more data
that is presently provided by IBM's DCOLLECT.
1. VTOC Processing
Original VTOC processing in MXG consisted of these three
members, which in concert would dynamically allocate all
DASD volumes that were online, read each VTOC, and build
three data sets describing VTOCs, Datasets, and extents
in your DASD farm:
FMXGUCBL - a function for dynamic allocation, used by
VMXGVTOR - a %macro that interated the execution of
VMXGVTOC - a SAS program that read a single VTOC
Execution of this sequence created the three MXG datasets
to be used for DASD space management, chargeback, etc:
VTOCINFO - One obs per VTOC, describes the volume
VTOCLIST - One obs per dataset, describes each dataset
VTOCMAP - One obs per extent, for pack analysis.
Large sites (over 500 volumes) found that VTOC reading
with SAS itself, while functional, took scores of seconds
per VTOC. Philip Morris wrote their own ASM program and
graciously contributed it to MXG, and cut the VTOC read
time to seconds per VTOC! You need only to assemble and
link edit the ASM program:
ASMVTOC - "Fast" VTOC reading assembly program
and then execute PGM=ASMVTOC to read all VTOCs and write
a single flat file to the VTOCDUMP DDname, which is then
read by the MXG SAS %macro program %VMXGVTOF in member
VMXGVTOF - Reads VTOCDUMP file created by ASMVTOC and
create three VTOC.... data sets.
(The example JCL in JCLDASD/JCLDASD6 then copies the
three VTOC.... datasets to the SAS data library that
is pointed to by the MXGDASD DDname.)
This is the recommended method for reading all VTOCs.
2. VVDS Processing.
Originally VVDS described only VSAM dataspace on a volume
but with SMS, the VVDS contains an entry for both VSAM
(in a VVR in the VVDS), and for non-VSAM (in a NVR in the
VVDS). Keeping track of VSAM data spaces on a volume was
the primary reason that the MXG Assembly program
ASMVVDS - read all VVDS and create a user SMF record
which was then processed by MXG members
IMACVVDS - identifies the SMF record number you chose
TYPEVVDS - to read the SMF VVDS records and create
the MXG dataset of of the same name with
an obs for each entry in the VVDS.
Additional idiosyncracies in VVDS entries were found and
corrected in analysis which is now inclued in member
ANALVVDS - executes IMACVVDS/TYPEVVDS, and adds logic
to "clean-up" the VVDSf data.
Member ANALVVDS creates these two MXG datasets for VVDS:
TYPEVVDS - One obs per VVR, cleaned up
VSAM - One obs per VSAM data set.
The two datasets are written to the DDname of MXGVVDS.
Change 8.263 Three variables added by DB2 2.2 were not deaccumulated.
DIFFDB2 Variable Q3STRDON in DB2STAT0 and variables QTAUCCH and
Mar 26, 1991 QXMIAP in DB2STAT1 are now DIF()'d in DIFFDB2.
Thanks to Siegfried Trantes, Gothaer Versicherungsbank VVAG, GERMANY.
Change 8.262 Support for TSO/MON Release 5.3.0 has been added and has
EXTSODRU been tested, due to excellent support from LEGENT; not
VMACTSOM only did this vendor provide documentation in advance of
Mar 25, 1991 the general availability of the product, but also sample
SMF records were provided for testing! The major change
is the new TSOMDRU Dynamic Resource Utilization dataset,
which allows you to identify the most resource intensive
commands so that you can then enable detail recording for
those commands. Minor changes included new fields in the
TSOMSYST and TSOMCALL datasets containing Hiperspace page
in and page out counts.
Change 8.261 TSO/MON system records are restricted to 4089 bytes. When
VMACTSOM more users are logged on than fit in 4089 bytes, TSO/MON
Mar 25, 1991 writes multiple records, which MXG recognized, but the
INTRVTM value was incorrect in these "split" records.
Additionally, the test for INTRVTM=0 as criteria for the
first of a split record was changed to TSMSSEGN=1.
Thanks to Richard Morris, Progressive Companies, USA.
Change 8.260 Many variables in the HSM user SMF record accumulate from
DIFFHSM record to record. The new DIFFHSM provides the logic to
TYPEHSM de-accumulate these ascending values with the SAS DIF()
VMACHSM function. For the first occurrence of a "BY Group" value
Mar 25, 1991 or if values between adjacent observations decrease, MXG
sets the DIF()'ed variable to a missing value. This new
algorithm has been tested, but only with a few sets of
HSM SMF data records. If you have added HSM SMF record
processing to BUILDPDB, you must also %INCLUDE the new
member DIFFHSM in the EXPDBOUT member. If instead you
use member TYPEHSM to process HSM, the DIFFHSM member is
now already included for you. VMACHSM was also changed.
Variables DSRFUNCT,FSRFUNCT,VSRFUNCT were redundant with
DSRTYPE,FSRTYPE,VSRTYPE (which also take less space and
are decoded by an MXG format) so the ...FUNCT variables
were removed from VMACHSM datasets. Several PD4. variable
input statements were protected for hex nulls, and indent
of code was standardized. Some inconsistent data values
were found in IBM records - for example, several of the
fields which contain "number of tracks" contain hex
FFFFFFnn values, which is 4,294,000,000+ in decimal!
Use with caution, and let me know if you find IBM APARs
are needed to correct their data errors!
Change 8.259 TYPE6156 variables VOLSER1-VOLSER5 can be wrong if there
VMAC6156 are more than five volumes, because these variables were
Mar 24, 1991 not initialized. Line 020700 was change to a DO group:
IF NR6XVOLS=1 THEN DO; VOLSER1=VOLSER; VOLSER2=' ';
VOLSER3=' ';VOLSER4=' ';VOLSER5=' ';END;
Thanks to Kenneth D. Jones, Maritime Telegraph and Telephone, CANADA.
Change 8.258 New dataset PDB.SPUNJOBS is created automatically in your
SPUNJOBS MVS PDB by the new SPUNJOBS program, which reads today's
Mar 15, 1991 SPIN datasets and combines those SPINning job's records,
giving you PDB.JOBS variable names and a single dataset,
PDB.SPUNJOBS, describing jobs still spinning. Of course,
many variables in PDB.SPUNJOBS will have missing values,
because only fields from records that were found will be
non-missing for a particular job. Variable INBITS shows
which records were found, and in section "PDB" of Chapter
40 of the MXG Supplement is described which variables in
PDB.JOBS and PDB.SPUNJOBS come from which record.
Change 8.257 Goal Systems Explore/VM records for VM/370 were supported
VMACVMXP by MXG's VMACVMXP, but the VM/XA extensions were not in
XMACVMXP that data. This change stores the original member in the
Mar 15, 1991 XMACVMXP member (for backup, but will eventually go away)
and replaces the contents of VMACVMXP with new code that
was contributed, but only syntax checked. Use with the
appropriate caution.
Change 8.256 IMS Log Processing has been once again been significantly
TYPEIMS re-engineered, and now supports WFI (Wait-for-Input) and
VMACIMS multi-transactions per program schedule correctly, and it
Mar 14, 1991 also eliminates those occasional negative values in the
input and output queue times. The new design uses MXG's
BUILDPDB logic to merge the PRG and INOUT3 (message) data
and puts non-matches in UNMATCHD, but also creates a new
dataset MSGMISSD if the log does not contain all messages
for a program sked, (if WFI runs from 8am to 8pm, but if
the IMS log starts at noon, messages executed before noon
will be counted in the 07 record when the WFI terminates,
but would not have their 01-03-31-35-36 records in this
IMS log dataset). The CPU and DL/I calls for those missed
messages will be lumped into one observation in MSGMISSD
(variable NMSGMISS counts the missed message executions)
and all IMS resources are captured in IMSTRAN + MSGMISSD,
but only IMSTRAN captures transaction response times too.
The re-design eliminated the need to 'explode" IMS07 obs.
This redesign answers all reported problems with IMS log
processing for non-fastpath transactions, but at best the
IMS log is a poor source of IMS measurement data. The IMS
log was designed ONLY for backup/recovery, and IBM does
not care enough for IMS users to enhance the log to put
a transaction identifier in each record, making heuristic
algorithms based on found-data-patterns of MSGDRRN and
DEST necessary to reconstruct a transaction response from
its log records). Even when reconstructed, the IMS log
contains only a single measure of CPU time used which not
only includes the Control Region and Message Region times
but also includes the CPU time used when IMS transactions
access DB2! Large IMS sites deserve better quality from
IBM. Nevertheless, we will continue to do our best to
extract whatever can be captured from IMS log records.
Change 8.255 IMACJBCK allows SMF record selection by jobname, and this
IMACJBCK is a documentation note rather than a change. Only jobs
Mar 13, 1991 with blank or higher jobname are kept by MXG's default.
Type 30 records with nulls are created by IBM errors (see
MXG Technical Notes in Newsletter NINETEEN), and these
"bad" records were deleted by MXG because of the IMACJBCK
default. The default was needed to protect the PDB from
a runaway software monitor that created scores of records
with invalid job names, and the default could probably be
changed (to pass any or all values of jobname) without
any significant impact, but since that can't be proven in
advance, it seemed better to leave the default alone, but
remind you of this MXG default here and in comments in
the IMACJBCK member.
Thanks to Mike Revelette, Defense CEETA, USA.
Change 8.254 Support for OPPSI Operator Single System Image in SYSPLEX
VMAC76 environment added six new traceable variables to TYPE76:
Mar 6, 1991
OMDGWTOI - Lines of messages, WTOs, issued per millisec
OMDGCMDI - Commands issued per millisecond.
OMDGWTLI - WTLs (write to logs) per millisecond.
OMDGWQEB - Max WQEs (WTO Queue Elements) on queue.
OMDGOREB - Max OREs (Operator Reply Entries on queue.
OMDGAMRE - MAX messages on AMRF (Action Msg. Retention)
You must first enable RMF trace for these fields, and use
a PRINT of TYPE76 dataset to examine their values.
Change 8.253 SYNCSORT SCZ 33038 for SYNCSORT 3.3 or 3.4 adds two new
VMACSYNC counters with the number of frames of Hiperspace/Data
Mar 5, 1991 Space allocated (HPALLOC) and used (HPUSED). The two new
fields occupy formerly reserved fields, so prior versions
of MXG will not fail when this SCZ is installed.
Thanks to Sam Sheinfeld, Kraft General Foods, USA.
Change 8.252 Talk about great response from IBM for this vendor!!!
VMACDCOL At SHARE 76 last week, IBM mentioned that a future APAR,
Mar 5, 1991 OY37378, would add many new fields to the HSM DCOLLECT
record. Starting with the HSM Hotline telephone number
(listed in Pat Kearney's GC38-7014), it took only three
short telephone calls and less than three elapsed hours
before my fax machine coughed out the DSECT of the new
HSM record produced by DCOLLECT! Due to this great
response from IBM, APAR OY37378 is supported in this MXG
version (transparently), and you won't need to install a
new version later this spring! The new variables are:
ORGEXPDT='EXPIRATION*DATE'
UMALLSP ='ORIGINAL*ALLOCATE*SPACE'
UMBKLNG ='BLOCK*LENGTH'
UMCREDT ='CREATION*DATE'
UMEXPDT ='EXPIRATION*DATE'
UMFLAG2 ='INFORMATION*FLAG*#2'
UMGDS ='GDG?'
UMLBKDT ='LAST*BACKUP*DATE'
UMLRFDT ='LAST*REFERENCED*DATE'
UMNMIG ='NUMBER OF*TIMES*MIGRATED'
UMPDSE ='PDSE?'
UMRACFD ='RACF*INDICATED?'
UMRECOR ='VSAM*RECORD*ORGANIZATION'
UMRECOR ='VSAM*RECORD*ORGANIZATION'
UMRECRD ='RECORD*FORMAT*BYTE'
UMRECSP ='RECALL*SPACE*ESTIMATE'
UMRELBK ='RELBLK?'
UMSMSM ='SMS*MANAGED?'
UMUSESP ='ORIGINAL*SPACE*USED'
UMCHIND ='CHANGED*SINCE LAST*BACKUP?'
UMDSORG ='DATASET*DSORG*ORGANIZATION'
These variables will exist, but will have missing values
or blanks until the PTF for the APAR is installed. See
also the discussion in Change 8.130 for DCOLLECT info.
The PTF for OY37378 requires additional prerequisites.
APARs OY41039 and OY41256 must be installed before 37378.
Change 8.251 This is a revision of and enhancement to Change 8.182.
BUILDPDB The CICS 3.1+ Statistics records are combined to create
BUILDPD3 four interval data sets CICINTRV, CICEODRV, CICINTRV, &
CICINTRV CICUSSRV. CICS Stats records are created at an INTerval,
Mar 5, 1991 (CICINTRV), at EOD (End of Day, or Shutdown), at REQuest
(CICREQRV), or at USS (CICUSSRV). The CICINTRV dataset
replaces and enhances the old CICSYSTM dataset that has
zero observations under CICS 3.1+. The CICEODRV dataset
is brand new and provides Shutdown & EOD statistics. In
fact, CICS 3.1 no longer prints ANY of the shutdown stats
on the Job's listing. IBM provides the DFHSTUP utility to
extract Shutdown stats from SMF data. MXG has CICEODRV!
Printing the CICEODRV data set wil give your CICS folks a
report for each shutdown/end of day evolution. There are
the nineteen CICS datasets that are currently used to
create the four (INT/EOD/REQ/USS) interval datasets:
CICAUTO CICDMG CICDQG CICDQT CICDS CICDTB
CICFCT CICLDG CICM CICSDG CICSMDSA CICST
CICTC CICTCT CICTDG CICTM CICTSQ CICTST
CICVT
Note that there are a few other CICS Statistics datasets
that are not currently included in these four interval
MXG data sets. As we learn more about CICS/ESA, these
four datasets built by CICINTRV member may be enhanced.
These four CIC...RV interval datasets are automatically
created in the PDB library by BUILDPDB/BUILDPD3 if you
do nothing; member IMACCICS defaults the destination DD
name to "PDB". The sort order of these four datasets is:
BY SYSTEM APPLID SMFPSSPN COLLTIME DURATM SMFSTINO;
Change 8.250 PR/SM "overhead" is explicitly captured when APAR OY36668
VMAC7072 (and associated microcode) is installed in ES/9000 or S/J
Mar 4, 1991 models of the 3090 (this APAR is not available on earlier
hardware platforms). The APAR captures the "Effective
Dispatch" duration, LCPUEDTM, for each partition. The
difference between LCPUPDTM, the existing LPAR Dispatch
time, and this new LCPUEDTM "Effective" LPAR Dispatch, is
the time that this LPAR was dispatched for management of
this partition. In addition to capturing the partition
LPAR management time, there will be a new observation in
TYPE70PR with a partition name of PHYSICAL that will have
only a value for LCPUPDTM. This "pseudo" partition does
not actually exist, but is the capture mechanism for the
total additional time that LPAR was dispatched but could
not be charged to a specific partition. See the technical
discussion and schematic in Newsletter NINETEEN.
Note that with this APAR installed, all of the IBM RMF
reports will now use the "Effective" dispatch time as
their 100% CPU busy denominator.
Although unrelated to the primary purpose of this APAR,
two new fields (LCPUCAP and LCPUCAPC) identify if each
partition had Capping in effect, or if Capping status
changed during the interval.
Change 8.249 DB2 trace records are now "paired" (event start and end
ANALDBTR are merged) in this new analysis routine for serious DB2
Feb 28, 1991 questions. (Note that most sites with DB2 do not need the
detail of SMF 102 tracing; member ANALDB2R seems to meet
the reporting needs of the vast majority of MXG sites).
But if you need to trace SQL calls, I/Os, etc., this
routine will sort and match the pairs and builds the many
data sets from your DB2 trace. The instructions for its
use and the datasets created are documented in the member
itself.
Change 8.248 DB2ACCT variable QWHDUNIQ is now formatted $HEX12. Three
VMACDB2 variables, QLACCPUL, QLACCPUR, QLACDBAT, added for DB2
Feb 28, 1991 distributed data durations, are not in 8-byte Timer Units
used every where else in DB2, but are microseconds stored
in an 8-byte floating point number! Change lines 189800
thru 190000 to use RB8.6 instead of MSEC8.!
Thanks to Bob Otis, Rockwell International, USA.
Change 8.247 Support for Boole and Babbage's CMF Monitor's "Type 240"
ANALCM27 SMF record is added by this MAJOR user contribution! The
ANALCM29 subtypes 0, 1, 19, and 23 are processed by the standard
EXCMFASM architecture MXG members TYPECMF/VMACCMF into 16 datasets
EXCMFCPQ CMFASMQ CMFDEVIC CMFEXTRT CMFPG0V
EXCMFCPS CMFCACHE CMFDOM CMFIPS CMFPRIOS
EXCMFDEV CMFCPUQ CMFEXTCC CMFOBJ CMFSRMC
EXCMFDOM CMFCPUS CMFEXTPG CMFPG CMFTRACE
EXCMFID
EXCMFIPS In addition, two specific processing/reporting members
EXCMFOBJ for the subtype 27 (cache sampler) and subtype 29 (the
EXCMFPG CS monitor) are provided in ANALCM27 and ANALCM29.
EXCMFPG0 The actual SMF record ID is set in member IMACCMF.
EXCMFPRI
EXCMFSRM The implementation includes a CALLed function, that is
EXCMFTCC yet to be added in MXG. Also, actual testing with the
EXCMFTPG BUILDPDB has not been performed yet.
EXCMFTRA
EXCMFTRT
IMACCMF
TYPECMF
VMACCMF
Thanks to Richard L. Gimarc, Boole and Babbage Austin, USA.
Change 8.246 SAS 6.06 Compatibility. LENGTH DEFAULT=4 is positional.
VMACSMF Variables ID and SUBTYPE in TYPE30_V and TYPE1718 were
Feb 21, 1991 stored in 8-bytes instead of 4-bytes because they precede
the LENGTH DEFAULT=4 statement. The LENGTH statement in
VMACSMF now includes LENGTH DEFAULT=4 preceding INPUT.
Thanks to Siegfried Trantes, Gothaer Versicherungsbank VVAG, GERMANY.
Change 8.245 Support for NETMASTER V2.1.0 has been added. The type 39
EXTY39 records written by NETMASTER are generally identical to
FORMATS IBM type 39 records. Two TOD variables exist at the end
VMAC39 of the SCS secion, SMFNCSTM/SMFNCETM, but their values
Feb 20, 1991 are identical to ACTSTIME/ACTETIME in the ACCT section,
and are not kept. The subtype 255 creates a new dataset,
TYPE39FF that is unique to NETMASETR and contains:
SMFNRCFA='RESOURCE*AVAILABLE*?'
SMFNRCLN='RESOURCE*LINK NAME'
SMFNRCNI='RESOURCE*NETWORK*ID'
SMFNRCNM='RESOURCE*NAME'
SMFNRCPU='RESOURCE*PU NAME'
SMFNRCR ='CONFIG DATA REVISION LEVEL'
SMFNRCSP='RESOURCE*SUBAREA PU NAME'
SMFNRCSS='RESOURCE*OWNING/ADJACENT SSCP'
SMFNRCST='END OF*NETMASTER*INTERVAL'
SMFNRCTP='RESOURCE*TYPE'
This change has been bench validated with printed dumps
of several NETMASTER records.
Thanks to Gerry Binas, DCSD, Manila Electric Company, PHILIPPINES.
Change 8.244 VM/XA and VM/ESA MONWRITE records can cause an erroneous
VMACVMXA MXG message "Probable Data Loss Due to MONWRITE Failure".
Feb 20, 1991 MXG detection of internally spanned MONWRITE records was
imperfect. Line 005970 was IF (COL-4+MRHDRLEN) GT LENGTH
but should have been (COL-3+MRHDRLEN) and line 006000 was
SKIPTHIS=LENGTH-COL-1 but should have been LENGTH-COL+1.
Thanks to Bob Small, Grumman Data Systems, USA.
Thanks to Mike Masella, G.T.E. Services Corp, USA.
Change 8.243 The test IF X NE 0 may not produce the expected result.
SAS coding If variable X can be missing, the test wil be TRUE. This
Feb 15, 1991 suggests that a (generally) safer algorithm, which does
ensure that X is both non-zero AND non-missing, is to use
the test IF X GT 0 for this purpose. The example below
tested X (an offset to a data field) to ensure that the
FIELD was present in the record:
wrong: IF X NE 0 THEN INPUT @X FIELD $CHAR1.;
right: IF X GT 0 THEN INPUT @X FIELD $CHAR1.;
Because X was in a conditional INPUT statement that had
not been executed, the value of X was missing, but the
NE 0 test (instead of GT 0) executed the INPUT statement
with @X where X was missing! What did SAS do with missing
pointer? For either a zero or missing pointer value in
an INPUT statement, SAS moves the pointer to byte 1 of
the record and beings normal INPUT. There is no problem
with using X GE 0 if you can guarantee that X will be non
missing, and in all instances of its use in MXG it does
have adequate protection. Fields unconditionally input as
PIBn (full binary) can never be missing, but variables
input as PDn and other packed formats can be missing.
Now that I realize GT 0 is safer than NE 0, I will cease
using NE 0. I'll bet this already written up somewhere.
Change 8.242 An MRO CICS transaction in an AOR that is waiting for a
VMAC110 TOR user to type enter will find the AOR transaction's
Feb 14, 1991 IRESPTM=(ELAPSED-WTTCIOTM) will include all of the time
that the AOR was waiting on the (user) TOR, and the time
waiting is captured in the WTIRIOTM, the time that the
AOR was waiting on inter-region communications. As long
as this AOR has no FOR, then all of the WTIRIOTM can be
recognized as "user think time" and should be subtracted
from IRESPTM to capture the "real" internal response time
for this type of AOR transaction. However, if the AOR
waits for any other inter-region communications, such as
and FOR, then the WTIRIOTM would contain ambiguous delay
time. The IRESPTM=IRESPTM-WTIRIOTM; statement could be
added in your EXCICTRN exit; it cannot be added to MXG
code because it might not apply to all CICS installations
and it might not even apply to all CICS regions at an
installation.
Thanks to John Nursey, Commercial Union Assurance.
Change 8.241 Unused.
Change 8.240 Variable R79GTOD was added to all TYPE79xx datasets, as
VMAC79 that timestamp may be needed in analysis.
Feb 14, 1991
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 8.239 If CICS variables are EXCLUDEd (i.e, the CICS MCT has the
VMAC110 EXCLUDE=(DFHaaaa,DFHbbbb) or INCLUDE=(DFHaaaa,DFHbbbb),
Feb 12, 1991 MXG member VMAC110 can be edited and the excluded fields
can be commented out as described in instructions in this
member (FIND occurrence of EXCLUDE and read comments).
The comments suggested using the UTILCICS program in the
MXG library, but you can just as easily look directly at
the EXCLUDE/INCLUDE statements in your MCT to know which
fields to comment out in VMAC110. This change takes note
of that user suggestion, and protected BMSTOTCN & TDTOTCN
variables against "Un-Initialized Variable" messages.
Thanks to Joe Naussbaum, Morgan Stanley, USA.
Change 8.238 Validation of CICS 3.1 statistics records uncovered some
VMAC110 incorrect input formats. In CICFCR, variables A17OPENT
Feb 12, 1991 and A17CLOST were incorrect. Instead of PD4. format, the
four bytes must be read HH PK1. MM PK1. SS PK1. TH PD1.1
and then SS=SS+TH; and A17OPENT=HMS(HH,MM,SS); and this
is repeated for A17CLOST. In CICSLDG, variables LDRFT,
LDGLLT, and LDGTTW were incorrectly input as TU4., when
they are actually CICS internal clock values and must
be INPUT as PIB4.6 and then multiplied by 16 to convert
to seconds. See Technical Discussion in Newsletter 19
for a table of time formats and how to read them.
Change 8.237 A short SMF record can be created by STC's 4400 Silo when
VMACSTC a silo is varied on/off line. STC ZAP L1H00o8 (yes, that
Feb 12, 1991 is two zeros and an alphabetic o) corrects the bad record
that caused MXG to ABEND (INPUT STATEMENT EXCEEDED ...).
The following circumvention fix has been added to MXG so
that it will not fail even with the short record. Lines
022700 thru 023000 now read:
INPUT @21+OFFSMF SMLSFLAG $CHAR1. @;
IF LENGTH GT 26 THEN
INPUT +3 SMLSATID PIB2. @;
Thanks to Raymond Zieverink, Belk Stores Services, USA.
Change 8.236 Support for Legent's ASTEX ("Automated Storage Expert"
VMACDMON replacement for DASDMON SMF records. A number of new data
Feb 6, 1991 variables have been added to all three datasets. Some of
the variables that were common in all records now exist
only in the DMONDSN and DMONJOB datasets under ASX, but
since MXG now supports either old DASDMON or new ASX SMF
records, these variables are still kept in both places
for compatibility; the ones moved will exist but have
missing values with ASTEX. The following are changed:
New in all three (DMONVOL,DMONDSN,DMONJOB) datasets:
ASXFLAG ='SPANNING FLAG'
ASXFLAG2='SYSTEM*TYPE*FLAG'
ASXFLAG3='AUTHORIZED*FLAG*DASD'
RALBSY -'TOTAL*CON/DISC*OUTBOARD TIME'
RBYCNT ='TOTAL IO-S FOR BYPASSES'
RCCCNT ='TOTAL IO-S FOR CACHE CANDIDATES'
RCFCNT ='TOTAL IO-S FOR CFW'
RDFCNT ='TOTAL IO-S FOR DFW'
RDLCNT ='TOTAL*DFW*LOAD COUNT'
RHTDFW ='TOTAL DASD FAST WRITE HITS'
RHTRD ='TOTAL*READ*HITS'
RHTRDS ='TOTAL READ SEQUENTIAL HITS'
RLDCNT ='TOTAL*LOAD*COUNT'
RNRCYLS ='NR OF CYLINDERS ON THE DEVICE'
RNWCNT ='IO-S THAT WERE NORM WRITES'
ROICNT ='OPTIMIZER INHIBIT IO-S'
RSTCFW ='TOTAL CACHE FAST WRITE HITS'
RTICNT ='TOTAL IOS INHIBIT IO-S'
RXSCNT ='CROSS*SYSTEM*SEEK COUNT'
New in DMONVOL dataset:
RVCACHFL='CACHE*FLAG*HVLFLAG4'
RVCFLAG2='CACHE*FLAG2 '
RVDMTOBJ='DEMOTION*TIME (SECS)*OBJECTIVE '
RVDSNRBA='RBA OF DSN RECORDS'
RVDSNBKS='NUMBER PHYS. BLOCKS FOR DSN RECS'
RVDSNOFF='OFFSET INTO RBA TO 1ST DSN REC'
RVJOBBKS='NUMBER OF PHYS. BLOCKS FOR JOB RECS'
RVJOBOFF='OFFSET INTO BLOCK TO 1ST JOB REC'
RVJOBRBA='RBA OF JOB RECORDS'
RVMXNBR ='DSNRBA'
RVSIIX ='VSAM IMBEDDED*INDEX I-O*COUNT'
New in DMONDSN and DMONJOB dataset:
RPRGMNM ='PROGRAM NAME*ASSOCIATED*WITH DSN'
RTRATME ='TOTAL*INTRA-DSN*SEEK TIME '
Variables removed from all three DMON.... datasets.
RCHCNT ='TOTAL*CACHE*HITS'
RSQRSP ='SUM*RESP*SQUARED'
Variables removed from DMONVOL dataset
RVMXNBR ='LONGEST*NON-BUSY*RESERVE'
Now missing values (ASX only) in DMONVOL dataset:
RFTCNT ='TOTAL*FETCH*IO-S'
RLRCNT ='TOTAL*LONG*RESERVES'
RSEEKTM ='TOTAL*SEEK*TIME'
RSRCNT ='TOTAL*BLDL-FIND*IO-S'
Thanks to Joseph Faska, Depository Trust Corporation, USA.
Change 8.235 The support to read HSM data sets needed correction for
VMACHSM HSM 2.4 and 2.5. Two occurrences of 177 for offset P2
Feb 6, 1991 changed to 185, and the two occurances of 297 for P3 are
changes to 405.
Thanks to Milt Weinberger, Information Services International, USA.
Change 8.234 The Hiperbatch counters for VSAM added to the type 64 SMF
VMAC64 record were wrong, because MXG failed to skip over the 3
Feb 5, 1991 undocumented bytes in the record. Change the test for 193
to 196, and insert +3 between INPUT and SMF64SIO.
Thanks to Bob Brosnan, Goldman Sachs, USA.
Change 8.234 Preliminary support for VPD, "Vital Products Data" aka
DOCVPD NAM, "Network Asset Management" NETVIEW "hardware monitor
EXTYVPDE records" written to SMF (usually) as type 37 containing
EXTYVPDF "VPD" as SUBSYS and SUBTYPE=22. Member IMACVPD sets the
EXTYVPDM record ID MXG expects, and defaults to 37. (If VP writes
EXTYVPDP the record, I would not be surprised to see the value 0!)
EXTYVPDS Seven internal record subtypes, E,F,M,P,S,T and W create
EXTYVPDT seven VPD..... datasets documented in DOCVPD. An extra
EXTYVPDW part of this user contribution is the INFOLOAD member,
IMACVPD which shows how an MXG SAS data set (in this example, the
LOADINFO PDB.VPDPUHAR) can be "loaded" into an INFO/SYS database!
TYPEVPD All seven subtypes have been coded and syntax checked,
VMACVPD but only "P", VPDPUHAR PU Hardware subrecords have been
VMAC37 tested with data records. Member VMAC37 was updated to
Feb 4, 1991 NOT process type 37 records with SUBSYS='VPD'.
Thanks to Bill Border, Apollo Computer Inc, USA.
Change 8.233 "Invalid data for MSOCOEFF in line ..." error and a hex
VMAC7072 dump is printed with MVS/ESA 4.1 type 72 records, but the
XMAC7072 data sets built by MXG are NOT in error. IBM increased
Feb 1, 1991 the width of the MSOCOEFF field from 4 to 8 bytes in
MVS/ESA 4.1 (because sites wanted to set a small value
and the 4-byte EBCDIC value was limited to .001 for the
memory service coefficient) by adding a new 8-byte field
to the end of the record, and putting a zero in the old
4-byte field. Unfortunately, I expected an EBCDIC zero,
but IBM changed the format to binary zeros, causing the
invalid data message. Since MXG went on to then input a
value from the new 8-byte field, MSOCOEFF was correct in
the TYPE72 data set, in spite of the note on the log!
The correction is simple. Change the line now reading:
@OFFWRKC+34 MSOCOEFF 4.
to read:
@OFFWRKC+34 MSOCOEFF ?? 4.
(the ?? added suppresses the error message and the dump
and sets the variable to missing value on invalid data).
Thanks to Ann Slaughter, Airline Tariff, USA.
Change 8.232 The CICS Dictionary utility had misleading titles and was
UTILCICS accidentally altered when CICS 3.1 support was added. The
Feb 1, 1991 report was valid, however.
Thanks to Phil Shelley, Jewish Hospital HealthCare Services, USA.
Change 8.231 VM/ESA testing found an unprotected divide by zero that
VMACVMXA is now corrected in de-accumulation of the user records.
Feb 1, 1991 (It had no impact on the MXG-build data sets, because the
observation causing zero-divide was the first for a user,
and the first record is always deleted). Additionally,
variable VMDELIST is now formatted $HEX2.
Change 8.230 Duplicate Job Name Hold delay time for batch scheduling
ASUMJOBS is now detected and eliminated in this summarization part
Jan 31, 1991 of the MXG Trend Data base that builds the PDB.JOBSKED
data set and calculates IWT (Initiation Wait Time) by
job class. See the MVS Technical Note in Newsletter 19.
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
Change 8.229 SAS 6.06 Compatibility? SAS 5.18 handled "PIB2 ." in
VMXGHSM line 370300, but SAS 6.06 requires the "PIB2." syntax
Jan 31, 1991 (i.e., no blank between PIB2 and its period)!
Thanks to Andrew Davies, TAB of W.A., AUSTRALIA.
Change 8.228 Support for SESAME, a Volvo (Europe) VTAM Monitor, which
EXTYSESA creates an SMF record. This is preliminary support, that
IMACSESA has only been syntax checked after editing this user
TYPESESA contribution to MXG Software. Formats are defined in
VMACSESA FORMATS but are not yet associated with their variables.
Jan 30, 1991
Thanks to Olli Rautajuuri, SAS Institute Oy, FINLAND.
Change 8.227 Support for MEMO, a European Electronic Mailsystem which
EXTYMEMO creates an SMF "accounting" record. This is preliminary
IMACMEMO support, that has only been syntax checked after editing
TYPEMEMO this user contribution to MXG Software. Formats are
VMACMEMO defined in FORMATS but are not yet associated with their
Jan 30, 1991 variables.
Thanks to Pertti Russcanen, Carelcomp Oy, FINLAND.
Change 8.226 Variable PMHTSKID should not have been KEEPed in these
VMACIDMS non-task-related MXG datasets: IDMSARA,BUF,CPM,INS,INT,
Jan 29, 1991 JRL,LNE,PGM,RUS,STG,YPE. Only caused confusion.
Thanks to Bob Rutledge, Sherwin Williams Paint, USA.
Change 8.225 Support for Landmark's The Monitor for DB2 type 100 & 101
TYPEDB2 records requires a fix from Landmark. ZAP U900266 exists
Jan 29, 1991 now, and that fix will be included in Landmark's planned
maintenance release level ML911, due out this Spring. The
DB2ACCT data is good without that fix, but DB2STAT0/1 are
wrong until the fix is installed. (The statistics record
sequence number was not updated by Landmark, and MXG uses
it to validate the de-accumulation of interval records,
and to detect skipped intervals and multiple startups).
Landmark does not yet write type 102 SMF records.
Change 8.224 Support for MVS/ESA 4.2 (RMF 4.2.1).
EXTY22IO 1.New dataset TYPE22IO reports I/O configuration changes as
EXTY33U1 a result of the ACTIVATE funcation (add, delete, modify)
IMACPDB with these 33 new variables from the new subtype of the
TYPE33 type 22 SMF record:
VMAC6 FORCEOPT='ACTIVATE*FORCE*OPTION?'
VMAC22 SMF22CCH='CHANNEL*PATH*ID'
VMAC26J2 SMF22CFI='OPSYS*CONFIGURATION*ID'
VMAC26J3 SMF22DCH='ARRAY OF*CHPIDS*ADDED OR DELETED'
VMAC30 SMF22DCM='MASK OF*CHPIDS*ADDED OR DELETED'
VMAC32 SMF22DPC='ARRAY OF*PHYS CU-S*ADDED OR DELETED'
VMAC33 SMF22DPM='MASK OF*PHYSICAL CU-S'ADDED-DELETED'
VMAC4345 SMF22DVN='DEVICE*NUMBER'
VMAC7072 SMF22EDT='ID OF*NEW*EDT'
VMAC71 SMF22EFL='ENTRY*FLAGS'
VMAC73 SMF22EHD='ENTRY*HEADER'
VMAC74 SMF22ELN='LENGTH OF EACH ENTRY'
VMAC78 SMF22ER ='ENTRY*TYPE*(MXG FORMATTED)'
Dec 6, 1990 SMF22ERQ='ENTRY*REQUEST'
Jan 28, 1991 SMF22ETY='ENTRY*TYPE'
SMF22FLS='FLAGS'
SMF22FNC='ACTIVATE*FUNCTION*REQUESTED'
SMF22HCT='HARDWARE*CONFIGURATION*TOKEN'
SMF22IDN='DSNAME OF IODF*WITH NEW*I/O CONFIGURA'
SMF22NE ='NUMBER OF ENTRIES IN THIS RECORD'
SMF22NUA='NUMBER OF*UCBS ADDED*FOR THIS CHANGE'
SMF22NUD='NUMBER OF*UCBS DELETED*FOR THIS CHANGE'
SMF22OFF='OFFSET TO FIRST ENTRY'
SMF22PCH='ARRAY OF*CHPIDS*ADDED OR DELETED'
SMF22PCM='MASK OF*CHANNEL PATH IDS*ADD-DELETED'
SMF22PCN='PHYSICAL*CONTROL UNIT*NUMBER'
SMF22PSU='STARTING*UNIT*ADDRESS'
SMF22PUA='RANGE OF UNIT ADDRESSES*ADD-DELETED'
SMF22PUC='COUNT*OF UNIT*ADDRESSES'
SMF22RNR='RECORD NUMBER OF THIS RECORD'
SMF22TNE='TOTAL NUMBER OF ENTRIES FOR THIS CHANGE'
SMF22TR ='TOTAL RECORD NUMBERS FOR THIS CHANGE'
SOFTOPT ='ACTIVATE*SOFT*OPTION?'
2.New variables have been added to the TYPE30_V, TYPE30_4,
TYPE30_5, and TYPE30_6 datasets built from type 30 SMF
records, and to datasets PDB.SMFINTRV, PDB.STEPS and
PDB.JOBS built by BUILDPDB/BUILDPD3. The BUILDPDB change
required modification to member IMACPDB, so that MXG
users with a modified IMACPDB will need to retrofit its
changes onto the new IMACPDB member.
a. Ten new variables describe pages and blocks moved to
and from Auxiliary and Expanded storage for this job
due to the new Blocked Paging enhancements. Variables
in upper case are actual data fields, while lower case
variables are calculated from actual data fields:
Blocks Blocked Unblocked Total
Pages Pages Pages
In from AUX BLKSAUIN PGBKAUIN
In from ESTORE BLKSESIN PGBKESIN PGUNESIN PGTOESIN
In total BLKSTOIN PGBKTOIN
Out to AUX BLKSAUOU PGBKAUOU
Out to ESTORE BLKSESOU PGBKESOU PGUNESOU
Out total BLKSTOOU PGBKTOOU
Type 71 variables: Blocks Blocked Unblocked Total
Pages Pages Pages
In total BLKSTOIN PGBKTOIN
Type 72 variables: Blocks Blocked Unblocked Total
Pages Pages Pages
In from AUX BLKSAUIN pgbkauin
In from ESTORE BLKSESIN PGBKESIN pgunesin PGTOESIN
In total blkstoin PGBKTOIN
c. Eight new variables describing APPC activity by this
address space were added (but the APPC resources are
not currently contained in the subtype 2 & 3 interval
records, so these variables are not kept in TYPE30_V
nor the PDB.SMFINTRV data set):
APPCATR ='TRANSACTIONS*SCHEDULED*BY ASCH'
APPCCN ='TOTAL*CONVERSATIONS*(ACTIVE+DEALLOC)'
APPCCNA ='NUMBER OF ALL*CONVERSATIONS*ALLOCATED'
APPCDAR ='BYTES OF DATA*RECEIVED*BY THE TP'
APPCDAT ='BYTES OF DATA*SENT*BY THE TP'
APPCREC ='RECEIVE CALLS*ISSUED*BY TP'
APPCSEN ='SEND CALLS*ISSUED*BY TP'
APPCTAC ='NUMBER OF*ACTIVE*CONVERSATIONS'
d. The JCTJOBID field from which TYPETASK and JESNR are
extracted has changed with APPC. Instead of three
characters JOB/STC/TSU follwed by the five digit JESNR
the JCTJOBID will contain an "A" and a seven digit
number, which MXG stores in TYPETASK and JESNR. You
should check if any reporting programs use TYPETASK
for selection, and to ensure they are coded robustly
so they will not fail if TYPETASK='A' is encountered.
The JCTJOBID change was not compatibly implemented and
changed VMAC6,VMAC30,VMAC32,VMAC26J2, and VMAC26J3.
SMF records use the fieldname SMFnnJNM for the eight
byte JCTJOBID field. This IBM change in that field
could also affect "banner page" printing code in your
SMF exits.
3.New dataset TYPE33_1 records APPC Transaction Program,
"TP" resources, for each TP work scheduled by ASCH. Each
type 33 is an APPC event, with the same APPC counts that
are totaled in the type 30, above. In addition, times of
receipt, scheduling, and execution of the TP are recorded
as is the CPU times, I/O connect time and EXCP counts for
APPC TPs. This new data is the resource record for APPC,
and will be used instead of the type30s for APPC resource
accounting, performance measurement, etc. The variables
in this data set from the type 33 subtype 1 record are:
ACCOUNTn='ACCOUNT*FIELD* n'
APPCCNAS='CONVERSATIONS*ALLOCATED*BY THIS TP'
APPCCONS='NUMBER OF*CONVERSATIONS*FOR THIS TP'
APPCDARS='BYTES*RECEIVED*BY THIS TP '
APPCDATS='BYTES*SENT BY*THIS TP '
APPCRECV='RECEIVES*ISSUED*BY THIS TP'
APPCSEND='SENDS*ISSUED*BY THIS TP '
CPUSRBTM='CPU*SRB*DURATION'
CPUTCBTM='CPU*TCB*DURATION'
ELAPSTM ='ELAPSED*DURATION'
EXCPTOTL='EXCPS*FOR*THIS TP'
INPREQTM='INPUT*REQUEST*DURATION'
IOTMTOTL='DEVICE*CONNECT*DURATION '
LENACCTn='LENGTH OF*ACCOUNT FIELD* n '
LOCLLUNM='LOCAL*LU NAME*FOR THE TP'
NRACCTFL='NUMBER*ACCOUNT*FIELDS'
PARTLUNM='NODENAME*LUNAME*OF PARTNER'
QUEUETM ='SCHEDULER*QUEUE*DURATION'
RACFGRUP='RACF*GROUP*IDENTIFICATION'
RACFUSER='RACF*USER*IDENTIFICATION'
REQDTIME='REQUEST*RECOGNIZED*BY FMH-5'
SKEDTIME='REQUEST*PLACED ON*SCHEDULER QUEUE'
SMFTIME ='TIMESTAMP*WHEN RECORD*WAS WRITTEN'
SYSTEM ='SMF*SYSTEM*ID'
TPCLASS ='TP*CLASS'
TPNAME ='TP*NAME'
TPNDTIME='TP*EXECUTION*ENDED'
TPROFILE='TP*PROFILE*NAME'
TPSKEDTY='TP*SCHEDULER*TYPE'
TPSTTIME='TP*EXECUTION*STARTED'
TPUSECNT='USES OF*THIS TP*BY THIS USER'
TPUSRTYP='TP*USER*TYPE'
ZDATE ='ZEE DATE*ZEE OBS*WAS CREATED'
The following time sequence is unvalidated but is thought
to describe the events for a standard TP scheduled event:
INPREQTM QUEUETM ELAPSTM
Waiting on Waiting on Executing
Scheduler TP queue
|_____________|_______________|____________|
| | | |
REQDTIME SKEDTIME TPSTTIME TPENTIME
Request Placed on Execution Execution
Received TP's queue Started Ended
4.New variables were added to TYPE4345 for JES2 start
options:
CONSOPT ='CONSOLE*OPTION*SPECIFIED?'
LOGOPTN ='LOG*OPTIONS*SPECIFIED?'
QUIKSTRT='JES2 DID*QUICK*START??
RECNFGOP='RECONFIG*OPTION*SPECIFIED?'
5.New TYPE70 variables APPCMIN,APPCMAX,APPCAVG for the min,
max,avg number of APPC address spaces active, and twelve
distribution buckets APPC00 thru APPC11 count the percent
of time when 0, 1-3, ... over 36 APPC address spaces were
active, paralleling the similar set of fifteen variables
for the existing other three types of address spaces for
BATCH, TSO, and STC addresses.
6.New TYPE71 variables count blocked pages in or out, the
PWSS (Primary working set) pages migrated, and the number
of ESTORE frames that were freed without migration:
ESPGFRNO='ESTORE FRAMES FREED W/O MIGRATION'
PGBKtoin='BLOCKED*PAGES*PAGED IN'
PGBKtoou='BLOCKED*PAGES*PAGED OUT'
PWSSMIIN='PWSS PAGES*MIGRATED*FROM ESTORE'
7.Old TYPE72 variable WKLOAD no longer exists.
Eleven new variables, including the long needed new
ESA CPU times, and the ESTORE residency time (which
can be compared with the existing variable ACTFRMTM,
previously discussed in NEWSLTRS member) to estimate
usage of ESTORE frames.
ACTESFTM='EXPANDED*STORAGE*RESIDENCY'
ACTFRMTM='ACTIVE*FRAME*TIME'
BLKSAUIN='BLOCKS*PAGED IN*FROM AUX'
BLKSESIN='BLOCKS*PAGED IN*FROM ESTORE'
CPUHPTTM='HIPERSPACE*CPU TIME'
CPUIIPTM='I/O*PROCESSING*CPU TIME'
CPURCTTM='REGION*CONTROL*CPU TIME'
PGBKESIN='BLOCKED PAGES*PAGED IN*FROM ES'
PGBKTOIN='BLOCKED PAGES*PAGED IN'
PGTOESIN='PAGES*PAGED IN*FROM ESTORE'
SYSTRNTM='SYSTEM*TRANSACTION*TIME'
8.New TYPE73 variables describe IODF name and creation:
CFGCHGFL='SMF73CFL CONFIGURATION CHANGE FLAGS'
CHPADDED='CHANNEL*PATH*ADDED?'
CHPDELET='CHANNEL*PATH*DELETED?'
CHPMODIF='CHANNEL*PATH*MODIFIED?'
IODFNAME='IODF*NAME'
IODFSUFX='IODF*NAME*SUFFIX'
IODFTIME='IODF*CREATION*DATETIME'
9.Type 74 record contains the same fields added to the type
73 listed above, but the variables are NOT kept in TYPE74
because I don't think the 44 bytes of IODF name needs to
be kept in each device segment of MXG's TYPE74 dataset.
If they really turn out to be needed, I will create a new
data set, one per type 74 record, instead of one for each
device. The code is in place, so the variables do exist
and are available in EXTY74, if needed.
_______ _______ ________
|Offset |Offset |Offset | SMF Type 33 APPC/MVS TP Accounting
|to POF |to IOF |to UOF |
|_______|_______|________|
Product Section:
____________________________
| |
POF: | "ASCH", MVSLEVEL |
|____________________________|
TP Identification Section:
_________________________________________________________
|Offset | |
IOF: |to TPO |TP Class, Standard/Multi-Trans, TP Profile Name |
|_______|_________________________________________________|
\
\
\
\ TP Program Name Section:
\ _______ _______________________________
| | |
TPO: | Len |TP Name (up to 64 characters) |
|_______|_______________________________|
______________________
/ \
TP Usage Section: / \
_______________ _______ _________ _______ \
| |Offset | |Offset | /
UOF: |RACFUSER,GROUP |to AOF |Usecount |to TDO | /
|_______________|_______|_________|_______| /
/ /
/ /
/ /
/ /
_________________/ /
/ /
/ TP Usage Accounting Section:
/ ______ __________________
/ | |Accounting fields |
/ AOF: | Len |(up to 175 char) |
/ |______|__________________|
/
/
/
TP Usage Detail Section
_______ ___________________________________________
|Offset | |
TDO: |to TSO | Sends,received,data,conversations,TCB,SRB |
|_______|___________________________________________|
\
\
\
\ TP Usage Scheduler Section
\ _____________________________
| |
TDO: | LLU, PLU, Four Time Stamps |
|_____________________________|
10.Type 78 record contains the same fields added to the type
73 listed above, but the variables are NOT kept in TYPE78
because I don't think the 44 bytes of IODF name needs to
be kept in each subtype 3 segment. See above note.
Change 8.223 Deaccumulation of EXCP count from type 14/15 records by
ANALDSET this MXG analysis routine did not handle concatenated PDS
Jan 25, 1991 libraries, noticibly causing JES2 job's PROCnn DDNAMES to
have incorrectly high EXCP counts in this analysis. The
BY list in lines 017300 and 017600 should have had the
variable DSNAME inserted between DDNAME and UNITADR:
BY SYSTEM READTIME JOB STEP DDNAME DSNAME UNITADR SMFTIME;
Thanks to Lee Hollis, Lowe's Companies, Inc, USA.
Thanks to Dee Ramon, Mutual of America, USA.
Change 8.222 Default SMF record IDs in IMAC.... members for User SMF
IMACWSF records are intended to all be 512 (an impossible value)
Jan 25, 1991 but some IMACs slipped into the library with a different
value; if your site had a record of that value, the test
of JCLTEST could cause an "INPUT STATEMENT EXCEEDED "
STOPOVER condition. All IMACs for User SMF records now
have the value of 512, as they should have all along!
Thanks to Glenn Hanna, Textron Defense Systems, USA.
Change 8.221 SAS 6.06 Compatibility. Mixed case from PUT function.
MONTHBLD The DAY=PUT(TODAY,WEEKDATE3.); may create mixed case in
Jan 25, 1991 the character variable DAY under SAS 6.06, depending on
several SAS 6.06 options; the first letter is upper case,
while the second and third letters of the name of the day
are lower case. Since the subsequent test is for caps,
the test fails. Line 005200 is now replaced with
DAY=UPCASE(PUT(TODAY,WEEKDATE3.));
to force DAY to be uppercase, independent of the sites
options for case.
Thanks to Barry Lampkin, Blue Cross Blue Shield of Mass., USA.
Thanks to Debora Reinert, Nordstrom, Inc, USA.
Change 8.220 DCOLLECT variable DCDBKLNG should have been multiplied
VMACDCOL by 1024 (like the other adjacent values) to convert to
Jan 25, 1991 bytes for printing by the MGBYTES format.
Thanks to David Stern, CSX Technology, USA.
Change 8.219 Hiperbatch statistics added to the TYPE64 data set were
VMAC64 not kept in the correct dataset. The line containing
Jan 24, 1991 the six new variables was mis-located in the keep list
for TYPE64X (which is output before the variable are
input) instead of the correct keep list for TYPE64.
Variable JFCBDSNM was spelled incorrectly as JCFBDSNM.
Thanks to Michael Enad, Dun and Bradstreet, USA.
Change 8.218 Validation of PreRelease uncovered minor corrections.
IMACPDB 1.Line 029800 in IMACPDB should be _FREQ_ vice _FREQ
IMACACCT (but no error was set as _FREQ_ only exists in 6.06
VMAC110 and the missing underscore only caused _FREQ_ to be kept.
Jan 21, 1991 2.Comments in IMACACCT were enhanced to suggest that the
unwanted LENACCTn variables should also be dropped, and
that meaningless SAS "393" warnings print on the log.
3.CICS 3.1 processing was not protected for an unexpected
Statistics subtype. It did not fail, but the messages
produced were unclear. Now it is protected.
Thanks to Norbert Korsche, OMV-AG, AUSTRIA.
Change 8.217 Support for Candle's EPILOG for MVS Version 300 SMF "type
EXEPMEP 180" data record is added by this user contribution.
EXEPMIO Three EPMV.. data sets are created:
EXEPMEQ EPMVEP - The fixed workload information and the wait
IMACEPMV statistics for the two kinds of workloads,
TYPEEPMV PG (perf groups, periods, total sys), and
VMACEPMV AS (TSO, JOB, STC). Variable SM180SUB shows
Jan 16, 1991 which of the 10 subtypes created the record:
TOTS - all perf groups combined
PGN - all periods of a perf group
PGP - a single period of a perf group
BAT - end of step for batch address space
TSO - end of step for TSO address space
STC - end of step for STC address space
bat - end of interval for batch ASID
tso - end of interval for TSO ASID
stc - end of interval for STC ASID
RSRC - EPILOG captured data (not from RMF)
EPMVEPIO - I/O counts for each device with counts.
EPMVEPEQ - ENQ counts for each major name with counts.
Thanks to Billy Westland, Candle Corporation, USA.
Thanks to John Ebner, Litton Computer Services, USA.
Change 8.216 Both SIO73CNT and SIO78CNT are missing in RMFINTRV for a
RMFINTRV 4381/3090/ES9000 processor, because I/O counts moved into
Jan 16, 1991 different records for different processors and software.
Mar 13, 1991 Insert after line 070200
DATA TYPE78; SET PDB.TYPE78;
(so a PDB can be on tape), and expand the SET statement
in line 070400 to read:
SET TYPE73P TYPE78 (IN=IN78) PDB.TYPE78IO (IN=IN78IO);
and insert new line after 070700:
IF IN78IO THEN SIO73CNT=IOPACTRT*DURATM;
to now populate variable SIO73CNT to contain total SSCH
count to all channels from the appropriate data set.
Thanks to John McDonald, Arizona State University, USA.
Change 8.215 If only DB2 Report PMLOK03 was requested, a 309 error is
ANALDB2R received. Line 076980, variable QW0054AI should have
Jan 16, 1991 numeric 0's instead of alphabetic o's. Line 077020,
variables MINTIME and MAXTIME need to be added to that
RETAIN statement.
Thanks to Elliot Weitzman, Oryx Energy Company, USA.
Change 8.214 "INVALID THIRD ARGUMENT TO FUNCTION SUBSTR" error message
VMAC6156 from syntax WANT6156=INPUT(SUBSTR(SYSPARM(),10,7),7.);
Jan 15, 1991 when the SYSPARM value is less than 17 characters. This
soft error can be eliminated by storing the value of the
SYSPARM() function into a variable, because SAS sets that
variable's length to 200 bytes. The variable is then used
in place of the subsequent SYSPARM() references. Lines
012200 thru 012600 now read:
IF WANT6156=. THEN DO;
SYSPARM=SYSPARM();
IF SYSPARM EQ: 'TYPE6156-' THEN
WANT6156=INPUT(SUBSTR(SYSPARM,10,7),7.);
ELSE WANT6156=-1;
RETAIN WANT6156;
END;
Apr 1 update. Now I find out from SAS that this message
only occurs in SAS 6.06 if ZAP Z6060627 was installed,
and that zap is now marked REMOVED by the Institute).
But I'll leave my robust circumvention in place!
Thanks to Debbie Matic, Commercial Union Assurance of Canada, CANADA.
Change 8.213 This example shows how new-style macros can be used in
Book place of the old style _DAY macro and INSTREAM DD.
Jan 15, 1991 The example in the Chapter 35 to copy the DAY PDB into
the correct "Day-of-Week" PDB uses a temporary dataset
(pointed to by the INSTREAM DDname), and writes out an
old-style MACRO named _DAY that contains the character
name of the day of the week, which is then used as the
DDNAME into which the daily PDB will be copied. That
example has been updated and commented below:
//INSTREAM DD UNIT=SYSDA,SPACE=(TRK,(1,1))
OPTIONS NOTITLES;
DATA _NULL_ ;
FILE INSTREAM NOPRINT RECFM=FB LRECL=80 BLKSIZE=8000;
TODAY=TODAY()-1; /* get yesterday's date */
WEEKDAY=' ';
WEEKDAY=PUT(TODAY,WEEKDATE3.);
PUT 'MACRO _DAY ' WEEKDAY $CHAR3. '%' ;
RUN;
%INCLUDE INSTREAM; /*read macro just created*/
PROC COPY IN=DAY OUT= _DAY;
Some users have been directed by SAS technical support to
replace the old-style substitution macro with the %MACRO
facility. One recommended implementation is:
DATA _NULL_;
TODAY=TODAY()-1;
DAY=UPCASE(PUT(TODAY,WEEKDATE3.));
CALL SYMPUT('_DAY',DAY);
PROC COPY IN=DAY OUT=&_DAY;
More later.
Change 8.212 This change deletes MXG member XMACEPIL and puts support
VMACEPIL for EPILOG CL1000 back in member VMACEPIL. Change 8.019
XMACEPIL was applied to member XMACEPIL, which was then copied in
Jan 14, 1991 to VMACEPIL. It is believed to support 4.4.0, 4.5.0, and
4.5.1 versions, but test data is not at hand.
Change 8.211 New variable INVOKSAS in TYPESYNC dataset from user SMF
VMACSYNC record produced by SYNCSORT now identifies if this SORT
Jan 14, 1991 was invoked by the SAS System. Note that SYNCSORT's
enhancement PTF number EW2903 must have been installed by
your SYNCSORT installer before this field will be "Y".
Change 8.210 DCOLLECT migration/backup tape data sets datetime values
VMACDCOL UMTIME or UBTIME were wrong. Both occurrences of JULDATE
Jan 14, 1991 must be changed to DATEJUL (lines 037800 and 040000).
In addition, the value written in the record by IBM is
apparently wrong itself, until you install APAR OY37378.
Thanks to Derek Cespedes, Florida Power and Light, USA.
Change 8.209 TSO/MON variable READTIME is missing in PreReleases 8.3
VMACTSOM thru 8.7. Change 8.104 to correct CA7 corruption of the
Jan 14, 1991 first byte of Reader Date worked ONLY if for corrupted
records; normal, non-CA7 records produced missing values.
In line 040110, remove the DO; and delete line 040130
(containing END;) so that READTIME is always created by
the INPUT function.
Thanks to David B. Adams, National Life of Vermont, USA.
Change 8.208 IBM SMF APARs have added new data fields.
VMAC23 1.SMF now flags when the CPU timer goes bad in a new field
VMAC30 in the type 30 timer section. APAR OY24857 applies.
Jan 12, 1991 New variable CPUERROR (which was formerly a reserved
field) will have hex 0000 (APAR not installed), hex 8000
(APAR installed, no error). The subsequent bits are on if
the corresponding CPU measurement value (there are now
seven CPU measures) was defective and set to zero in this
record. The APAR also eliminates an OC9 ABEND of SMF.
2.SMF now flags a step cancellation due to NOT CATLG 2 or
NOT CATLG 7 condition (one bit for both reasons), but
only if the installation specified JOBFAIL(YES) in ALOCXX
SYS1.PARMLIB member (which ABENDs the NOT CTLG JOB). APAR
OY38977 applies. IBM's bit 11 of SMF30STI is used, and
MXG ABEND will contain NOTCTLG if the step was cancelled
due to NON CATLG condition. In addition, new variable
TERMIND contains all 16 bits of the step/job indicator
for detail examination in your programs, if needed.
3.SMF type 23 record (buffer statistics) is expanded to
better describe the SMF writer's use of its memory. APAR
OY27449 applies. New variables created in TYPE23 dataset:
CURALLOC='SMF BUFFER*CURRENT*ALOCATION'
HWMALLOC='SMF BUFFER*HIWATERMK*ALLOCATION'
MAXBUFSZ='BUFFER*MAXIMUM*LEVEL'
MVSLEVEL='MVS*SOFTWARE*LEVEL'
PERALLOC='INCREMENT*PER EACH*ALLOCATION'
WRNBUFSZ='BUFFER*WARNING*LEVEL'
Change 8.207 MXG 8.7 only. Several test sites noted that //SOURCLIB DD
JCLTEST6 JCL statement was missing from the FORMATS step, and the
Jan 12, 1991 SMFSMALL step's //SYSIN DD DSN=MXG(UTILGETM) was replaced
with a //SYSIN DD * statement and a %INCLUDE.
Change 8.206 SAS 6.06 Compatibility, only in MXG PreReleases thru 8.7.
UTILGETM The UTILGETM program, used only during installation of
Jan 12, 1991 MXG (to build a small SMF file for testing), will put SAS
6.06 (even at the October maintenance level) in a 100%
CPU Busy loop, causing a System 322 ABEND. The error is
in the processing of the %VMXGVBS macro which was added
by MXG Change 8.174. This macro generates different DCB
attributes for the FILE statement (CMS can't create VBS)
so new MXG users under CMS did not die during testing.
The %VMXGVBS macro added to UTILGETM was almost exactly
the same as the %VMXGLRC macro for the INFILE statement
in the _SMF macro. The differences were that %VMXGVBS
sets only the LRECL parameter of the INFILE SMF, while
%VMXGVBS sets LRECL, DCB, and BLKSIZE options, and that
their references were located in different positions in
their respective INFILE and FILE statements. Over 50 runs
322 ABENDed before the %MACRO compiler error was found to
be circumvented when there is a "parameter=value"syntax
preceding the %VMXGVBS invocation. Adding COL=COLOUT to
line 01900 in UTILGETM circumvents the loop. This works:
FILE SMFOUT COL=COLOUT %VMXGVBS;
This didn't:
FILE SMFOUT %VMXGVBS;
SAS Institute now knows the loop occurs only a %MACRO on
a FILE or INFILE statement (and also only if the %MACRO
itself starts with %IF), and are working on the problem.
SAS Zap Z606xxxx, available Month dd,yyyy corrects this
error in the SAS 6.06 %MACRO compiler. Tracking 163046.
Thanks to Barry Lampkin, Blue Cross Blue Shield of Mass., USA.
Thanks to Grady Tart, McM Information Services, Inc, USA.
Change 8.205 PreRelease 8.2 thru 8.7 only. The label for CPUTCBTM may
VMAC110 say "SUM OF THREE CPU TCB TIMES", but it is still the
Jan 11, 1991 CPU TCB TIME. (The CICS 3.1 support label overrode the
original label).
Thanks to Raymond Zieverink, Belk Stores Services, USA.
Change 8.204 DB2ACCT variable QXNSMIAP was misspelled as QXMSMIAP. The
ANALDB2R correct variable QXNSMIAP was added by this change, but
VMACDB2 the original variable is also kept so that any reports
Dec 20, 1990 that you've written won't fail. Please correct in your
report programs and eventually QXMSMIAP will be dropped.
Thanks to Ron Root, Oryx Energy Company, USA.
---Changes thru 8.203 were included in MXG PreRelease 8.7 Dec 18, 1990--
Change 8.203 WSF2 record from RSD newest version 3.3.4 has a section
VMACWSF mis-located two bytes to the right and truncated at the
Dec 17, 1990 end. However, MXG code had not been validated with a real
record from that version, and a nine-bit bit test only
failed when actually executed, and the overlay of two
fields in the WSF2 DSECT was missed in MXG coding. The
two MXG oversights were corrected, and the logic was
expanded to support both the correct and incorrect record
format. Until maintenance exists from its vendor, the
value of ACCNPELT will be incorrect, and usually zero.
Thanks to Dennis Mahlubam, Aetna Life & Casualty, USA.
Change 8.202 MXG didn't calculate converted RMF data (3.5.1 to 4.1.1).
VMAC79 The equation for R791FMCT in line 027800 should be
Dec 16, 1990 ELSE R791FMCT=R791RSV1 + R791RSV2;
Note R791WSS is missing here, since SMF79ASL is only 60.
Thanks to Miller Dixon, Continuum, USA.
Change 8.201 1.VM/XA Monitor records appear to have an IBM error. In the
VMACVMXA VXUSEINT record the HFQUCT (Hi Freq Sample Count) resets
Dec 16, 1990 itself erratically. MXG tries to capture the CPU time a
VM machine used between a logon and the end of the first
interval, and used HFQUCT in that heuristic algorithm.
However, that logic is now invalidated by this IBM reset
and the user interval record is no longer output when a
logon event is detected. The actual change was to
comment out the two lines "IF NOT (FIRST.BEGINMTR OR
FIRST.VMDUSER OR FIRST.VMDCPUAD) THEN OUTPUT;"
until HFQUCT can be corrected by IBM.
Perhaps someday, IBM will provide the long-requested
flag in the user sample record so the time from logon
to end of interval can be captured safely.
2.An unrelated change was made to better format the notes
MXG writes to the log when operator commands are found.
Additionally, the command variable CALCMD is now length
200 in all kept data sets.
Thanks to Procter & Gamble, BELGIUM.
Change 8.200 IMS Log type 35x with ENQFLAG=0Cx and FLAG2=40x is now
VMACIMS output in the IMS35P record. This is the last reported
Dec 16, 1990 record subtype that was not output in TYPEIMS processing.
Thanks to Magnus Jansson, DAFA Stockholm, SWEDEN.
Change 8.199 SAS 6.06 Circumvention discussed in Changes 8.078 and
ANALDB2R 8.059 were not propagated into all reports in ANALDB2R.
TESTANAL The default set of ANALDB2R reports were changed, but in
Dec 16, 1990 lines 028780 and 45960 the commas after AUTHCHG UTILITY
and OUTCODE=DROP DATETIME; must be removed. The fourteen
occurrences of " .T102" must be changed to " . T102", and
two " .DB2" must be changed to " . DB2". MXG testing of
%ANALDB2R by member TESTANAL was corrected to now invoke
and test all 27 of the DB2 reports.
Thanks to Susan Marshall, SAS Institute Europe, GERMANY.
Change 8.198 ACF2 variable ACLFLDVB could raise "Invalid Data" note.
VMACACF2 Line 052900 (the only occurrence of PK4.) should end with
Dec 7, 1990 "ACLFLDVB ?? PD4. @;" instead of "ACLFLDVB PK4. @;"
Thanks to Rachel Bromage, L.O.L.A., ENGLAND.
Change 8.197 Unused.
Change 8.196 Unused.
Change 8.195 Change 8.056 had not been installed in PreReleases. Lines
VMACSYNC 023800 and 024800 should now read SIRFM ?? 1. and
Dec 4, 1990 SORFM ?? 1. respectively.
Thanks to Bob Rutledge, Sherwin Williams Paint, USA.
Change 8.194 Validation of the STC Silo HSC 1.1.0 SMF Record uncovered
VMACSTC an MXG coding error that caused STOPOVER. Line 034600
Dec 3, 1990 should input STC07TNM PIB1. (instead of PIB4.).
Thanks to Leslie Dixon, Santa Fe Energy Resources, USA.
Change 8.193 VMXGVTOF is a modification of VMXGVTOC that will read the
VMXGVTOF output of ASMVTOC (the "Fast VTOC Reading program") and
Dec 3, 1990 will create the same datasets (VTOCLIST,VTOCMAP,VTOCINFO)
that were created by the slower VMXGVTOR/VMXGVTOC pair.
Note that VMXGVTOF replaced the (temorary) MPXGVTOC that
was introduced in Change 8.117.
Thanks to Jeff Fox, SKF, USA.
Change 8.192 Reserved Change Number.
Dec 2, 1990
Change 8.191 This contributed member estimates processor storage
ANALSTOR requirements based on techniques taught by IBM's
"MVS/ESA Subsystem Analysis: Processor Storage
Estimation" seminar taught by the South Western
Area Systems Center. The two step process suggested
first measures current usage based on RMF type 71 and
type 79 ASD records and second estimates the real and
expanded storage needed for zero paging (or very close
paging) taking under consideration future workload
growths. This analysis program accomplishes only the
first step, and provides a program to report the
current usage based on this IBM methodology.
Thanks to Miller Dixon, Continuum, USA.
Change 8.190 The original author of the support for Arbiter SMF
EXARB404 records (from Tangram product) has updated the code
EXARBC01 to support changes in Version 2.1.1 of that product.
EXARBC02 Three new data sets are created.
IMACARB
VMACARB
Nov 29, 1990
Thanks to J-P Tonnieau, GMF System Team SARAN, FRANCE.
Change 8.190 VMXGVTOC produces a single "error" message,
VMXGVTOC POINT=1 NOBS=0 POINTER=. VOLSER= DSNAME= ...
Nov 28, 1990 that has no real effect, that will disappear if you move
the SET statement (line 063700) to after the STOP
statement (line 063800).
Thanks to Magnus Jansson, DAFA Stockholm, SWEDEN.
Change 8.189 The POINT= operand of the SET statement cannot be used
ASUMCICS for a dataset on tape under SAS 6.06. We used it under
Nov 27, 1990 5.18, but it turns out that 5.18 documentation said that
it couldn't be used for tape! POINT= and NOBS= were used
to determine transparently which CICS dataset (CICSTRAN
or MONITASK or both) was to be summarized. The logic has
been redesigned to make the same determination without
the POINT= operand, so tape datasets can be used.
Thanks to Bob Grant, Gold Bond, USA.
Change 8.188 The final RETURN; statement was after the END; statement,
VMACHSM which caused no problem as long as HSM SMF record was
Nov 27, 1990 processed by itself; adding VMACHSM to BUILDPDB caused
subsequent data sets to be not output! The RETURN; is
now moved inside the END; statement.
Thanks to Chuck Hopf, Hopf Consulting, USA.
Change 8.187 Hitachi processors using MLPF (their PR/SM or MDF) can
VMAC7072 mix dedicated and shared processors in the same LPAR,
Nov 27, 1990 but MXG did not protect for that possibility and the
CPUWAITM in the TYPE70 was incorrect (but the individual
CPUWAITn variables were correct). This change expanded
the logic for Dedicated processors to re-calculate the
CPUWAIT variable across both dedicated and shared CPUs.
Thanks to Matthew Bakulich, Crowley Maritime, USA.
=========Changes thru 8.186 were printed in Newsleter EIGHTEEN==========
Change 8.186 PreReleases 8.2 thru 8.5, JES 3 BUILDPDB, line 044500
BUILDPD3 added variables JINLTIME and JSRTTIME to the LENGTH
Nov 16, 1990 statement but left out the "8" before the semicolon.
Thanks to Phil Waters, Arthur Andersen, Bristol, ENGLAND.
Change 8.185 PreRelease 8.3 thru 8.5 had an extra debugging statement
VMACDB2 "IF QWHSTYP GT 2 THEN PUT QWHSTYP= Z=;" after the @; in
Nov 16, 1990 line 165000 which should have been removed. Other than
possibly filling your log, there was no real problem.
Thanks to Ron Allison, UDSI, USA.
Change 8.184 PreRelease 8.5 could fail with a STOPOVER due to SMF
VMAC57 type 57 (only with MVS 4.1) because of typographical
Nov 15, 1990 errors in Change 8.167. Line 009700 should be
IF LEN GE 116 THEN instead of GE 16 and line 009800
should be INPUT @101+OFFSMF instead of @100.
Thanks to Bob Malitz, United Parcel Service, USA.
Change 8.183 PreRelease 8.5 needed minor tuning of Landmark TMON/CICS
TYPEMON8 Version 8 support. The division by TCINPRCN for long
Nov 15, 1990 running mirrors needed zero-divide protection.
Change 8.182 The CICS 3.1+ Statistics records are now combined into
BUILDPDB _CICNTRV.CICINTRV by new member CICINTRV which is now
BUILDPD3 automatically included in BUILDPDB/3 and TYPE110. The
CICINTRV CICINTRV data set merges the interval "INT" records from
IMACCICS statistic data sets, and the original CIC..... datasets
TYPE110 remain in the work file. CICINTRV is a major enhancement
Nov 14, 1990 for CICS 3.1 analysis, and logically is a replacement for
the non-existent CICSYSTM. Note that if no "INT" records
exist (which would happen if only "EOD" was requested),
there will be no observations in CICINTRV. These nineteen
CICS Statistics datasets are merged together to create
the CICINTRV interval statistics dataset:
CICAUTO CICDMG CICDQG CICDQT CICDS CICDTB
CICFCT CICLDG CICM CICSDG CICSMDSA CICST
CICTC CICTCT CICTDG CICTM CICTSQ CICTST
CICVT
Change 8.181 Boole & Babbage IMF product record for IMS chained
TYPECIMS transactions contain the ARRVTIME of the original
Nov 14, 1990 transaction in the subsequent records, causing the input
queue time to be too long. This contributed fix adds the
logic to sort and reprocess the IMS.TRANSACT datasetand
resets ARRVTIME to the ending time of the preceding
transaction in each chain.
Thanks to David Daner, Sun Refining and Marketing, USA.
Change 8.180 IMS Response Mode Transactions are now identifiable
VMAC110 with new variable RSPMODTR added to IMSTRAN dataset.
Nov 14, 1990
Thanks to ???, CED BORSA, ITALY.
Change 8.179 CICS Type 110 variables DSAHWMK, PROGCOMP, PROGSTOR,
VMAC110 STORHWMK, and STORHWMH all measure bytes, but their
Nov 14, 1990 units ranged from bytes, to doublewords to pages. Now,
all are converted to bytes and formatted with MGBYTES
format for consistency and clarity. (MGBYTES prints
100K, 200M, etc, scaling bytes to the appropriate range.)
Thanks to Elisabeth Jensen, Aetna Life and Casualty, USA.
Change 8.178 IMS Log processing algorithms enhanced in MXG 8.3 arenow
VMACIMS corrected for two conditions that had occasionally caused
Nov 11, 1990 INPQUETM and RESPNSTM to be appreciably wrong. The first
change affected 21 transactions, the second affected 134
transactions, out of a total of 368,000 transactions!
1.IMS Log 35x records with ENQFLAG=0Cx and FLAG2=0Cx did
not decode correctly, which caused RESPNSTM to be very
large in a very small number of transactions.
Near line 070600, after line
IF FLAG2='...1.....'B THEN LOC=LOC+2;
insert the following new line:
ELSE IF FLAG2='00001100'B THEN LOC=LOC+4;
This has been validated only for IMS 2.2, but it should
apply also for both 2.1 and 3.1. One of the big logic
problems in MXG support of the IMS log is the decoding of
the 35x records. IBM does not describe all of the bit
values for ENQFLAG, and each combination of ENQFLAG/FLAG2
must be experimentally determined to be an input, output,
message, or program-to-program enqueue event. MXG notes
on the log "LCODE 35X NOT OUTPUT ENQFLAG= FLAG2=" when
unknown values are found, and deletes the record. Values
of 0C/40, 2F/80, 2F/88 have been reported and are thought
to be output enqueue (and hence non-critical to delete).
It appears that FLAG2 must contain the '04'x bit on for
the enqueue to be for input.
2.The logic added in PreRelease 8.3 to reset ARRVTIME when
it was missing was correct and did correct problems by
sorting correctly. Out-of-time-sequence 01/03x records
were also reset by the 8.3 change, and seemed to work for
many transactions, but when the transaction's 35x record
was also out of time sequence, the change overcorrected,
and the INPQUETM and ENQTIME were wrong.
Near line 025600, change the test which read
IF ARRVTIME=. or ARRVTIME LT LASTTIME THEN ARRVTIME=....
to now read
IF ARRVTIME=. THEN ARRVTIME=LASTTIME-.001;
Thanks to J. Cary Jones, Philip Morris, USA.
Thanks to T. H. Witt, Oscar Mayer Food Corp, USA.
Thanks to Magnus Jansson, DAFA Data AB, SWEDEN.
Change 8.177 1.CICS/ESA 3.1 transactions accessing DL/I databases with
IMACICDB DBCTL can contain (optionally) a 256-byte segment with
IMACICDL clocks and counters for the CICS-caused DL/I activity.
IMACICUS (DL/I counters from the IMACICDL member can also exist,
UTILCICS but contain DL/I counts only for Local DL/I). Enabling
VMAC110 the DBCTL data is described in the Customization Guide.
Nov 11, 1990 Previously, the transaction record consisted of a static
segment, the optional local DL/I segment, the optional
user counters/clocks, and then ended with the optional
user character field. Since the character field (often
used for application data, account number, etc.) was at
the end of the transaction record, MXG simply read the
rest of the record into USRSTRNG, and then truncated the
data into the kept variable USERCHAR, whose length you
specified with the LENGTH statement in member IMACCICS.
With the restructured CICS 3.1 record, however, you must
now also set the variable USRCHRLN in IMACICUS to tell
MXG how many bytes of character data is to be read into
USRSTRNG so that the DBCTL data can be read; the order in
CICS 3.1 is static, Local DLI, User clocks/counters, user
character string, and DBCTL segment, when the new EMP is
added after your existing MCT calls.
The new IMACICDB member decodes the DBCTL fields when
you remove the comment block (just like IMACICDL did for
local DL/I). The actual DBCTL segment is 256 bytes, but
only 158 bytes are currently used by IBM, and they create
these 34 new variables (only if IMACICDB is changed);
STATBFWT='WAITS FOR*DEDB*BUFFERS'
STATDATN='SCHEDULE*COMPLETED*TIMESTAMP'
STATDATS='SCHEDULE*STARTED*TIMESTAMP'
STATDBIO='DATABASE*I/O-S'
STATDECL='DEDB*CALLS'
STATDERD='DEDB*READ*OPERATIONS'
STATDLET='DATA BASE*DELETES*ISSUED'
STATEXDQ='EXCLUSIVE*DEQUEUES'
STATEXEQ='EXCLUSIVE*ENQUEUES'
STATGHN ='DATA BASE*GHN CALLS*ISSUED'
STATGHNP='DATA BASE*GHNP CALLS*ISSUED'
STATGHU ='DATA BASE*GHU CALLS*ISSUED'
STATGN ='DATA BASE*GNP CALLS*ISSUED'
STATGNP ='DATA BASE*GNP CALLS*ISSUED'
STATGU ='DATA BASE*GU CALLS*ISSUED'
STATINTC='WAIT TIME*INTENT*CONFLICT'
STATISRT='DATA BASE*INSERTS*ISSUED'
STATMSCL='RESERVED*FOR*FAST PATH'
STATNPSB='PSB*NAME'
STATOVFN='OVERFLOW*BUFFERS*USED'
STATPOOL='WAIT TIME*FOR POOL*SPACE'
STATREPL='DATA BASE*REPLACES*ISSUED'
STATSCHT='SCHEDULE*PROCESSING*DURATION'
STATTENQ='TEST*ENQUEUES'
STATTLOC='PI*LOCKING*DURATION'
STATTMIO='DATABASE*I/O*DURATION'
STATTOTC='TOTAL*DL/I*CALLS'
STATTSDQ='TEST*DEQUEUES'
STATUENQ='UPDATE*ENQUES'
STATUOWC='UNIT-OF-WORK*CONTENTIONS'
STATUPDQ='UPDATE*DEQUES'
STATWEXQ='WAITS ON*EXCLUSIVE*ENQUEUES'
STATWTEQ='WAITS ON*TEST*ENQUEUES'
STATWUEQ='WAITS ON*UPDATES AND*ENQUEUES'
2.Unrelated, but discovered in this phase of testing, the
%VMXGFOR macro references inside old style macros, in the
UTILCICS dictionary-reading utility were corrected to now
contain double percent signs and titles were clarified.
Thanks to Hamid Tavakolian, Continuum, USA.
Change 8.176 IMS 3.1 DBCTL Thread Type transactions have zero for the
TYPEIMS value for NMSGPROC, causing them to be lost. There were
VMACIMS two errors in MXG logic. First, the setting of PROGTYPE
Nov 9, 1990 from PTYPE values 3, 4, and 5 (for D, Q, and R), near
line 038500 in VMACIMS should have been 4, 8, and 128.
Second, the tests in TYPEIMS for PROGTYPE='B' near line
024400 and 038700 are expanded to protect for DBCTL:
IF PROGTYPE='B' OR PROGTYPE='D' NMSGPROC EQ 0 THEN DO;
Thanks to Hamid Tavakolian, Continuum, USA.
Change 8.175 Landmark's TMON/MVS release 1.11 was supposed to become
EXTMVTR release 1.12, but it is now in managed availability as
EXTMVTRS release 1.1, with two new data records and some changes.
EXTMVWK 1.In LMRKREC="SY" section, insert a line with +4 after
EXTMVWKP SYSMDL $CHAR2., change SYSTSO1P PIB4.2 to PIB4.4, and
IMACTMVS delete the line with +4 after SYSPDT is read in.
TYPETMVS 2.Logical data records can span physical blocks, and the
VMACTMVS spanning can split fields! Thus far, only the I/O data
Nov 9, 1990 records have been found to be spanned. For example, with
Nov 28, 1990 552 I/O devices, an interval's logical record contains
41,400 bytes of data (plus headers), but is written in
three blocks of 13844 bytes each. Part of a field is at
the end of the first block, with the rest of that field
continued in the 33rd byte of the second block! There is
only one way to handle these non-standard records that
can exceed 32760 bytes, and that requires the use of an
Infile Exit to the SAS System. Fortunately, the Infile
Exit named TMON that is supplied by MXG for compressed
Landmark CICS records has been modified to support either
compressed and/or spanned record processing! The member
EXITMONI, however, only works under SAS 5.18.
In Newsletter EIGHTEEN, I thought we would also change
the 6.06 exit, and added member EXITMON6 in preparation
for its modification, but it turns out that SAS 6.06
itself will need modifications before the infile exit
can be redesigned. Thus EXITMON6 only supports the
decompression of Landmark records under SAS 6.06; the
EXITMONI member does both decompression and unspanning
but only under SAS 5.18.
Follow the instructions in the EXITMONI member, build
the TMON exit, and then edit new member IMACTMVS to tell
MXG that you have installed the Infile exit. Note that
this modified TMON exit will process either TMON/MVS or
TMON/CICS records. If you have not installed the TMON
exit and MXG finds spanned TMON/MVS records, the bad data
record will now be deleted and so noted on the log; prior
to this change, TMON/MVS spanned records cause STOPOVER.
3.Four new datasets are built, two each from the TR and WK
records. TMVSTR contains the Tape Record statistics, and
TMVSTRS contains one observation for each tape drive in
a TR record. TMVSWK contains the "static" variables in
the WK record, and TMVSWKP contains one observation for
each period of each performance group in the WK record.
4.Further validation added JIJNAME to TMVSJIST, corrected
labels for IOELDNRP,PSMAXSU,PSMINSU, and changed the
INPUT for SYSWTIME from PIB8.6 to MSEC8.
Thanks to Bob Rutledge, Sherwin Williams Paint, USA.
Change 8.174 This change should be transparent. It permits MXG to be
VMACSMF used for SMF record processing either under CMS or OS
UTILGETM versions of SAS, by using a new %MACRO to set the values
Nov 9, 1990 of RECFM and LRECL differently when MXG is exeuted under
CMS SAS than when MXG is executed under MVS SAS.
(Previously, CMS users had to EDIT these changes.)
UTILGETM was also expanded for both environments to look
for additional subtypes in creating the SMFOUT file.
Under CMS, VBS records can only be read, not written, and
they cannot have LRECL greater than 32756. Furthermore,
RECFM=VB is not supported for output; only RECFM=V
records can be created (CMS SAS accepts RECFM=VB syntax
but actually creates RECFM=V records). With this change,
execution under CMS causes the _SMF macro used for SMF
input to specify RECFM=VBS,LRECL=32756, and the UTILGETM
output spec will be RECFM=V,LRECL=32756,BLKSIZE=32760.
Additionally, since the SAS JFCB= option of the INFILE
statement does not function under CMS, variable SMFJFCB
is now protected to eliminate the uninitialized variable
message when MXG is executed under CMS SAS for SMF data.
Under MVS, VBS records can have LRECL=32760 (and actual
records with 32760 LRECL are written by SMF!). Since the
MXG specification has been LRECL=32760, this change had
no logic change to _SMF or UTILGETM when MXG is executed
under MVS SAS.
Change 8.173 Preliminary support for Amdahl's MPT (MDF Performance
EXMPTDOM Tool) SMF record. This new tool replaces the existing
EXMPTEND TYPEMDF record with enhanced information. Existing names
EXMPTGLO of TYPEMDF variables were preserved when recognized, but
EXMPTSEL until the actual DSECT is provided by Amdahl, all names
IMACMPT are subject to change and should be used with caution.
TYPEMPT The four new datasets created from the MPT SMF records
VMACMPT (whose ID is set in IMACMPT) are MPTDOMAN, MPTGLOBL,
Nov 9, 1990 MPTSELCT, and MPTENDSL. This support has not been tested
with actual data records yet.
Change 8.172 SPIN library suddenly fills after installation of JES2
BUILDPDB maintenance (either migration to MVS/ESA or PUT 8908).
BUILDPD3 This change replaces the discussion (without a change)
Nov 9, 1990 on the MXG 8.5 PreRelease as Change 8.158.
1.The logic decision in BUILDPDB ("to SPIN or not to SPIN")
controls the contents of PDB.JOBS, PDB.STEPS, PDB.PRINT,
and the SPIN data library. BUILDPDB will output to the
PDB library or SPIN library based on these criteria:
a) Job has "spun" more times than your chosen value of
_SPINCNT (defined in IMACSPIN). Each time a job is not
output, its SPINCNT is incremented. If you set the
value of _SPINCNT in IMACSPIN to 0, BUILDPDB will then
always output to the PDB and will never output to the
SPIN library.
b) The job is complete. There are two possibilities:
i.) The job failed before execution (i.e., JCL error
or canceled before initiation). The JES2 JSTRTIME
(start of execution) will be missing, and only
type 26 (and possibly type 6) records exist for
the job.
ii.) The job is really complete, and all SMF records
have been read. This requires that both a type 26
and a type 30 subtype 5 record were found, AND the
timestamp in the subtype 5 (MVS execution ended)
is between JSRTIME to JENDTIME (the JES execution
start to end times). That timestamp test is needed
to ensure that the real execution type 30 record
was found. If the SMF type 30 timestamp doesn't
match the JES type 26 timestamp, all records on
the job are "SPUN" until the correct type 30
subtype 5 is found. (Restarted jobs create
multiple type 30 subtype 5s. With multiple MVS
systems, today's SMF file could contain the type
26 and a type 30 from the first execution, but the
real (final) type 30 record could be in an
un-dumped SMF file that will not be read until
tomorrow's BUILDPDB run.)
This logic is implemented in BUILDPDB by setting OKFLAG;
if OKFLAG is set to 1, the job is created in the PDB,
if OKFLAG is not set, the records are sent to the SPIN.
SPINCNT= MAX(SPIN26,SPIN6,SPIN30_5,SPIN30_4,SPIN30_1,0);
IF IN26 AND IN30_5 AND
JSTRTIME LE JTRMTIME LE JENDTIME THEN OKFLAG=1;
ELSE IF IN26 AND (JSTRTIME=. OR JENDTIME=.) THEN OKFLAG=1;
ELSE IF SPINCNT GE _SPINCNT THEN OKFLAG=1;
2.Several sites suddenly found their SPIN libraries filled
after migration from MVS/XA to MVS/ESA, or after applying
JES2 maintenance (somewhere between PUT 8902 and 8908).
There were PTFs which altered JES2 time stamps, and one
of the PTFs went PE (PTF in Error), and perhaps the site
did not correctly install all of the PTFs, but the actual
result of the maintenance was that the site's JES2 type
26 SMF record's JENDTIME variable (SMF26XPT, JCTEQOF, the
job ended time, also in the $HASP395 job ended message)
was now earlier than the MVS type 30 subtype 5 (the job
termination JTRMTIME variable (SMF 30TME) timestamp!!!
This has NEVER been true before, and the sites with the
problem saw the change occur precisely when they put on
the IBM maintenance. Not only did IBM JES2 Level 2 say
there was no problem, they also tried to say that there
is no correlation between the JES SMF26XPT execution end
and the MVS SMF30TME job termination time (which is the
timestamp when SVC83 moves the record into the SMF buffer
in the SMF address space)! But SMF30TME occurs while the
job is still in MVS initiation and JES2 can't end the
execution until after SVC83 has completed and until after
MVS terminates its initiator. At these sites, the actual
JENDTIME to JTRMTIME delta is hundreds of milliseconds,
and it plots uniformly across the entire day. Note also
that SVC83 does not write data to disk, but only moves an
SMF record into the SMF buffer; the actual VSAM write of
the CI containing that SMF record will occur much later,
under an asyncronous SRB in the SMF address space.
But even if I'm right and IBM's wrong, it doesn't matter.
IBM can't find their problem or fix their code nearly
as fast as you and I can change the MXG logic to protect
for the error. Since the purpose of the time test is to
match the type 30 with its type 26, we will use the MVS
type 30 job initiation time, JINITIME, which has not been
touched by JES2 maintanance, instead of JTRMTIME, which
was altered, in the MXG BUILDPDB logic. Thus if the SPIN
library suddenly fills, compare JTRMTIME in SPIN30_5 with
JENDTIME in SPIN26J2, and if JENDTIME is earlier than the
JTRMTIME, you know you have this problem. To correct,
simply change JTRMTIME in the BUILDPDB "To Spin or Not To
Spin" logic shown above to instead use JINITIME. This
Change has been made in MXG PreRelease 8.7 and later.
Thanks to Georg Simon, Federal Reserve of Philadelphia, USA.
Change 8.171 PreRelease 8.5 support for Landmark CICS Version 8 had a
TYPEMON8 little error, but it caused a big dump and a STOPOVER!
Nov 5, 1990 Add +1 at the end of line 066800 (ends with TH PK1.)
to skip over the eighth byte of that datetimestamp.
Thanks to Marcia Ketchersid, Price Waterhouse, USA.
Change 8.170 The FORMATS step (only on MXG 8.5 PreRelease) was missing
JCLTEST the //SOURCLIB DD DSN=MXG.SOURCLIB,DISP=SHR
Nov 5, 1990 JCL statement.
---Changes thru 8.169 were included in MXG PreRelease 8.6 Oct 27, 1990--
Change 8.169 Support for VM/ESA Version 1 Release 1.0 ESA Feature.
EXAPLEDT The contents of the MONWRITE output data records has been
EXAPLSDT changed with new fields and new records, but the changes
EXAPLSRV were implemented by IBM in a completely compatible manner
EXIODATS and thus previous versions of MXG Software will not fail
EXSTOASS when they process the ESA Feature data records.
VMACVMXA The four new records create five new MXG datasets (and
Oct 16, 1990 thus there are five new EX...... exit members), and 15 of
Nov 5, 1990 the existing MXG datasets have new variables.
Dec 4, 1990
1.These fifteen existing MXG data sets content's have been
changed as indicated:
VXSYTXSP - New variables PLSPGMRD,PLSPGMRX,PLSPGXRD, and
PLSPGXWT (page reads/writes to/from ESTORE/AUX
due to page translations/migrations). Sample.
VXSYTASG - SALPRFAV,SALPRFIU are now reserved (were for
Preferred Paging), and new variables added for
page/spool average/total MLOAD (CALTOTM1,M2,
CALAVGM1,M2). Sample.
VXSYTCOM - New variables for counts of IUCVs good to/from
and bad to services SYSTEM,ACCOUNT,LOGREC,CRM,
IDENT,CONFIG, and SPL, twenty-one variables
PLSIS+{E,T,U}+{SY,AC,LO,CR,ID,CF,SP}.
VXMTREPR - Added new flag if Application Domain Event is
active, and CONFIG time limit variable.
VXMTRPAG - DDIPREF now reserved (was Pref. Paging Flag),
DDIPPCYL renamed RDCPCYL, and RDEVSID, Host
Subchannel ID now added.
VXMTRSPR - Added new flag if Application Domain Sample is
active, and CONFIG time limit variable.
VXMTRSCH - New SRMWSSMP for SET SRM MAXWSS value.
VXSCHDDL - New VMDLRGST if user prempted for storage.
VXSCLSRM - New SRMWSSMP for SET SRM MAXWSS value, and
VMDSCDF1 was replaced with VMCQDSPU.
VXSTORSG - New CALASCRT,CALASCFT,CALASCUT for paging
virtual segment control (reorgs, unused and
used pages).
VXSTORSP - New PLSPGDRD,PLSPGDWT for page tables paged
to/from auxiliary storage.
VXSTOASP - New EXPDEVST,EXPMLOAD,CPVLOKAT,CPVALOCD with
paging device service time, MLOAD, scans for
allocations, actual allocations, and twenty
EXPCON01-EXPCON20 tabulating how many times
that many contiguous slots were available.
VXSTOATC - DDIPREF now reserved, CALPAGCY renamed to
RDCPCYL, and RDEVSID added.
VXUSEACT - VMDCTPPS (Pref Page Slots) deleted.
VXIODCAD - New CALPSF data for 3990-3 status bytes.
2.There are five new datasets which can exist. However, two
of the new datasets (VXAPLEDT,VXAPLSDT) will have nonzero
observations is your site has an application that uses
the new interface to create Application data records.
Note that IBM uses that interface, and MXG creates the
VXAPLSRV dataset for file pool servers.
VXSTOASS - Auxiliary Shared Storage Sample Data record
describing resources from the CP-owining a
shared volume (PAGE/SPOOL READs/WRITES, queue
length, and SSCH+RSCH counts).
VXIODATS - Attach Shared Device Event Data record, which
contains exactly the same data as the existing
VXIODATD Attach (non-shared) Device dataset.
VXAPLEDT - Application Event Data record, with a variable
length string of installation/application
created event data, domain 10 record 1.
No IBM application currently uses this new
event data interface.
VXAPLSDT - Application Sample Data record with a variable
length string of installation/application
created interval data, domain 10 record 2.
IBM applications do now use this new interface
but they are recognized by MXG and create the
new VXAPLSRV dataset described below.
VXAPLSRV - IBM's use of Application Sample Data to record
"Server Monitor Records". Both SFS file pool
servers and CRR recovery servers use the
APPLDATA class call to provide 123 counters or
clocks that are listed below. MXG converts all
counters to rates per second (which are, by an
MXG convention, formatted 7.1 to so indicate
that they are rates), but the clocks are kept
in units of seconds during the sample interval
(and formated TIME12.2 to so indicate). The
VMDUSER (VM User ID) must be used to identify
which server created the application data:
Server-ID Observation contains
VMSERVR CRR (Counters 103-116 are only
for CRR, and 114 will be
always non-zero if CRR).
VMSERVS SFS (System owned file pool)
VMSERVU User (User owned file pool)
The following list of variables created from
these servers using the new application data
interface clearly is a major enhancment in
the measurement and management of the shared
file system and other future file servers:
ADATASDT='APPLICATION*DATA'
CALDATLN='LENGTH OF*APPLICATION*DATA'
CALDATOF='BYTE OFFSET*TO APPLICATION*DATA'
DEDMTFLG='DEDICATED*MAINTENANCE*MODE FLAG'
FIRSTR ='FIRST RECORD*SINCE DIAGNOSE*DC ISSUED?'
MDGPROD ='APPLICATION*PRODUCT AND*RELEASE'
SRVCN001='ACTIVE*AGENTS*HIGHEST VALUE'
SRVCN002='VIRTUAL*STORAGE*HIGHEST VALUE'
SRVCN003='VIRTUAL*STORAGE*REQUESTS DENIED'
SRVCN004='CHECKPOINTS*TAKEN'
SRVCN005='CHECKPOINT*TIME'
SRVCN006='SECURITY*MANAGER*EXIT CALLS'
SRVCN007='SECURITY*MANAGER*EXIT TIME'
SRVCN008='EXTERNAL*SECURITY*MGR EXIT CALLS'
SRVCN009='EXTERNAL*SECURITY*MGR EXIT TIME'
SRVCN010='ADD*STORAGE*REQUESTS'
SRVCN011='CACHE*RELEASE*REQUESTS'
SRVCN012='CHANGE*THRESHOLD*REQUESTS'
SRVCN013='CLOSE*DIRECTORY*REQUESTS'
SRVCN014='CLOSE*FILE*REQUESTS'
SRVCN015='COMMIT*REQUESTS'
SRVCN016='CONNECT*REQUESTS'
SRVCN017='CREATE*ALIAS*REQUESTS'
SRVCN018='CREATE*DIRECTORY*REQUESTS'
SRVCN019='DELETE*DIRECTORY*REQUESTS'
SRVCN020='DELETE*FILE*REQUESTS'
SRVCN021='DELETE*STORAGE*REQUESTS'
SRVCN022='FILE*COPY*REQUESTS'
SRVCN023='GET*DIRECTORY*REQUESTS'
SRVCN024='GET*DIRECTORY*ENTRY REQUESTS'
SRVCN025='GRANT*ADMINISTRATOR*AUTHORIZATION'
SRVCN026='GRANT*AUTHORIZATION*REQUESTS'
SRVCN027='GRANT*USER*CONNECT REQUESTS'
SRVCN028='LOCK*REQUESTS'
SRVCN029='OPEN*DIRECTORY*REQUESTS'
SRVCN030='OPEN FILE*NEW REQUESTS'
SRVCN031='OPEN FILE*READ*REQUESTS'
SRVCN032='OPEN FILE*REPLACE*REQUESTS'
SRVCN033='OPEN FILE*WRITE*REQUESTS'
SRVCN034='QUERY*ADMINISTRATOR*REQUESTS'
SRVCN035='QUERY*CONNECTED USERS*REQUESTS'
SRVCN036='QUERY*ENROLLED USERS*REQUESTS'
SRVCN037='QUERY*LOCK CONFLICT*REQUESTS'
SRVCN038='QUERY*FILE POOL*REQUESTS'
SRVCN039='QUERY*USER SPACE*REQUESTS'
SRVCN040='READ*FILE*REQUESTS'
SRVCN041='RECOVERY*CLOSE CATALOG*REQUESTS'
SRVCN042='RECOVERY*GET CATALOG*REQUESTS'
SRVCN043='RECOVERY*OPEN CATALOG*REQUESTS'
SRVCN044='RECOVERY*PUT CATALOG*REQUESTS'
SRVCN045='REFRESH*DIRECTORY*REQUESTS'
SRVCN046='RELOCATE*REQUESTS'
SRVCN047='RENAME*REQUESTS'
SRVCN048='REVOKE*ADMINISTRATOR*AUTHORIZATIONS'
SRVCN049='REVOKE*AUTHORIZATION*REQUESTS'
SRVCN050='REVOKE*USER*REQUESTS'
SRVCN051='ROLLBACK*REQUESTS'
SRVCN052='UNLOCK*REQUESTS'
SRVCN053='WRITE*ACCOUNTING*REQUESTS'
SRVCN054='WRITE*FILE*REQUESTS'
SRVCN055='FILE POOL*REQUEST*SERVICE TIME'
SRVCN056='REMOTE*FILE POOL*REQUESTS'
SRVCN057='ALIAS*DEFINITIONS*EXAMINED'
SRVCN058='ALIAS*DEFINITIONS*UPDATED'
SRVCN059='BEGIN*LOGICAL*UNITS OF WORK'
SRVCN060='AGENT*HOLDING*TIME'
SRVCN061='LOGICAL*UNIT OF WORK*ROLLBACKS'
SRVCN062='SAC*CALLS'
SRVCN063='STORAGE GROUP*EXPLICIT LOCK*CONFLICTS'
SRVCN064='FILE SPACE*EXPLICIT LOCK*CONFLICTS'
SRVCN065='DIRECTORY*EXPLICIT LOCK*CONFLICTS'
SRVCN066='FILE*EXPLICIT LOCK*CONFLICTS'
SRVCN067='STORAGE GROUP*LOGICAL LOCK*CONFLICTS'
SRVCN068='FILE SPACE*LOGICAL LOCK*CONFLICTS'
SRVCN069='DIRECTORY*LOGICAL LOCK*CONFLICTS'
SRVCN070='FILE*LOGICAL LOCK*CONFLICTS'
SRVCN071='CATALOG*LOCK*CONFLICTS'
SRVCN072='LOCK*WAIT*TIME'
SRVCN073='DEADLOCKS'
SRVCN074='QSAM*REQUESTS'
SRVCN075='QSAM*TIME'
SRVCN076='FILE*BLOCKS*READ'
SRVCN077='FILE*BLOCKS*WRITTEN'
SRVCN078='CATALOG*BLOCKS*READ'
SRVCN079='CATALOG*BLOCKS*WRITTEN'
SRVCN080='CONTROL*MINIDISK*BLOCKS READ'
SRVCN081='CONTROL*MINIDISK*BLOCKS WRITTEN'
SRVCN082='LOG*BLOCKS*READ'
SRVCN083='LOG*BLOCKS*WRITTEN'
SRVCN084='BIO REQ TO*READ FILE*BLOCKS'
SRVCN085='BIO REQ TO*WRITE FILE*BLOCKS'
SRVCN086='BIO REQ TO*READ CATALOG*BLOCKS'
SRVCN087='BIO REQ TO*WRITE CATALOG*BLOCKS'
SRVCN088='BIO REQ TO*READ CONTROL*MINIDISK BLOCKS'
SRVCN089='BIO REQ TO*WRITE CONTROL*MINIDISK BLKS'
SRVCN090='TOTAL*BIO REQUEST*TIME'
SRVCN091='I/O REQ TO*READ FILE*BLOCKS'
SRVCN092='I/O REQ TO*WRITE FILE*BLOCKS'
SRVCN093='I/O REQ TO*READ CATALOG*BLOCKS'
SRVCN094='I/O REQ TO*WRITE CATALOG*BLOCKS'
SRVCN095='I/O REQ TO*READ CONTROL*MINIDISK BLOCKS'
SRVCN096='I/O REQ TO*WRITE CONTROL*MINIDISK BLKS'
SRVCN097='RELEASE*BLOCKS*REQUESTS'
SRVCN098='TEMPORARY*CLOSE*REQUESTS'
SRVCN099='SFS*SEND USER*DATA REQUESTS'
SRVCN100='PREPARE*REQUESTS'
SRVCN101='CHANGE*FILE*ATTRIBUTE'
SRVCN102='HIGHEST*MAXCONN*USER'
SRVCN103='GET*CAPABILITY*REQUESTS'
SRVCN104='GET*LOG NAME*REQUESTS'
SRVCN105='CRR GET LUWID REQUESTS'
SRVCN106='RESYNC*INITIAL*REQUESTS'
SRVCN107='RESYNC*PROTOCOL*VIOLATION REQS'
SRVCN108='RESYNC*QUERY DIRECTION*REQUESTS'
SRVCN109='CRR*WRITE LOG*REQUESTS'
SRVCN110='CRR REQUEST*SERVICE*TIME'
SRVCN111='NUMBER OF*SYNC*POINTS'
SRVCN112='SYNC*POINT*TIME'
SRVCN113='PARTICIP RESC*CRR WRITE*LOG REQS'
SRVCN114='CRR LOG*CHECKPOINTS*TAKEN'
SRVCN115='CRR LOG*I/O*REQUESTS'
SRVCN116='CRR BIO*REQUEST*TIME'
SRVCN117='RESERVED'
SRVCN118='DIRATTR*REQUESTS'
SRVCN119='QUERY*ACCESSORS*REQUESTS'
SRVCN120='RESERVED*COUNTER 120'
SRVCN121='RESERVED*COUNTER 121'
SRVCN122='DIRCONTROL*RESOURCE*LOCK CONFLICT'
SRVCN123='DEADLOCKS*THAT CAUSE*ROLLBACK'
SVMSTAT ='OPTION*SVMSTAT*IN DIRECTORY?'
VMDUSER ='USER*IDENTIFICATION'
3.The documentation of the VM/ESA Monitor records will now
be only in "softcopy", and will be unloaded at install
into a file named MONITOR LIST1403 on your base CP object
disk (194). The new documentation contains an excellent
table that details changes made to the content and format
of the monitor records, including the many APARs that are
a part of VM/XA (and were already supported in MXG).
A thanks for IBM for making documentation available so
early; it's nice to not have to play "catch-up". Of even
greater significance: you can install this version of MXG
now, and whenever you install VM/ESA, you won't need to
install yet another version of MXG!
---Changes thru 8.168 were included in MXG PreRelease 8.5 Oct 27, 1990--
Change 8.168 The SAS 6.06 circumvention was misspelled; three lines
GRAFRMFI that now read
Oct 26, 1990 IGOUT=GRARMF5S GOUT=PDB.GRARMF5S
should be
IGOUT=GRARMF5S GOUT=PDB.GRARMF5S
IGOUT=GRARMF5M GOUT=PDB.GRARMF5M
IGOUT=GRARMF5D GOUT=PDB.GRARMF5D
Thanks to Jan Simark, SAS Institute Europe, GERMANY.
Change 8.167 Support for MVS/ESA SP Version 4.1 and RMF 4.2, which
VMACSMF became avaliable October 26, 1990.
VMACSMF 1.New flag variable MVSESAV4 (flag that this is MVS Version
VMAC434 4) is set but not used in MXG logic.
VMAC535 2.TYPE434, new variables CPUWRONG and EXCPLOST are now set
VMAC6 to "Y" if TCB time has overflowed, or EXCPs lost because
VMAC24 over 1635 DD statements existed. Both conditions exist
VMAC57 ONLY in the type 4 and 34 records, and IBM's now states
VMAC71 "Only the type 30 record should be considered valid."
VMAC74 3.TYPE535, new variable CPUWRONG (see above) added.
VMAC78 4.TYPE6 (JES2 only, not PSF nor JES3 nor EXT WRTR) has
VMAC79 a new "Enhanced SYSOUT Support (ESS) section containing
VMAC90 the output descriptor (if any) for the first offloaded
XMAC7072 data set, with five new variables:
XMAC71 SMF6IND ='ESS*SEGMENT*INDICATOR'
XMAC73 SMF6JDVT='JCL*DEFINITION TABLE*NAME IN JDTV'
XMAC74 SMF6SGID='SEGMENT*IDENTIFIER'
XMAC75 SMF6TU ='TEXT UNIT*(SWBTU)*DATA AREA'
Oct 27, 1990 SMF6TUL ='TEXT UNIT*(SWBTU)*DATA AREA LENGTH'
Mar 5, 1991 This paragraph was changed after Newsletter 18.
The SMF6TU character variable contains the SWB text unit,
which contains the JES2 ITEXT (length, key, value) for
the new OUTPUT JCL statement parameters ADDRESS, BUILDING
DEPT, NAME, ROOM, and TITLE. Their key values (IEFDOKEY
in SYS1.MACLIB) are x'27',28,29,2D,26, & 2A respectively.
Once I find out what sets the maximum length of these new
parameters, the fields will be decoded from the SWB. Stay
tuned to this paragraph in this change.
5.The MSS (Mass Storage System) device is no longer and IBM
supported device, and TYPE22_4 and its MSS variables will
now always be missing.
6.TYPE24 contains the same new five Enhanced SYSOUT (ESS)
fields added to the type 6, with these different names:
SMF24IND,SMF24JDT,SMF24SGT,SMF24TU, and SMF24TUL.
These variables are kept in TYPE24.
7.TYPE57J2 contains the same new five Enhanced SYSOUT (ESS)
fields added to the type 24, with these different names:
SMF57IND,SMF57JDT,SMF57SGT,SMF57TU, and SMF57TUL.
These variables are kept in TYPE57.
8.TYPE71 contains three new swap reason codes, because MVS
now has three additional reasons to swap an ASID:
IC - Improve Central Storage usage swap, by recognizing
page thrashing.
IP - Improve System Paging Rate swap, identifies that
your PTR controls are causing swaps.
MR - Make Room to swap in a user who has been swapped
out too long. When an Exchange Swap should have
occurred, SRM starts a clock, defaults to 30 sec
for TSO, 10 min for non-TSO, and will bring that
task back in if it stays out that long.
For each swap reason, there are five new variables for
the swap rate of each possible transition (EXTAUX..,
LOGAUX.., LOGEXT.., PHYAUX.., and PHYEXT..). The sum of
all transitions for each swap reason, (i.e., the total
swap rate for that reason code) is in the new variables
SWAPIC, SWAPIP, and SWAPMR.
9.TYPE74 data set has been enhanced with new variables
CUNAME ='CONTROL*UNIT*NAME'
DEVMODEL='DEVICE*MODEL*NAME'
and three variables describing pending delay due to the
director port busy, AVGPNDIR, DLYDIRTM, and PCPNDIR.
10.New subtype 2 of the Type 74 record from the Monitor III
Cross-System Coupling Facility (XCF) reports on message
traffic between the local system (where RMF executes)
and remote systems.
Four new TYPE74xx data sets are created:
/*TYPE74CO - control data */
R742MNXT='MEMBER DATA*SECTIONS IN*NEXT RECORDS'
R742MTOT='MEMBER DATA*SECTIONS IN*ALL RECORDS'
R742PNXT='PATH DATA*SECTIONS IN*NEXT RECORDS'
R742PTOT='PATH DATA*SECTIONS IN*ALL RECORDS'
R742SNXT='SYSTEM DATA*SECTIONS IN*NEXT RECORDS'
R742STOT='SYSTEM DATA*SECTIONS IN*ALL RECORDS'
R742TSR ='SUBTYPE 2 RECORDS IN INTERVAL'
/*TYPE74ME - member data */
R742MGRP='GROUP*NAME'
R742MMEM='MEMBER*NAME'
R742MRCV='SIGNALS*RECEIVED BY*MEMBER'
R742MSNT='SIGNALS*SENT BY*MEMBER'
R742MSTF='STATUS*FLAGS'
R742MSYS='SYSTEM NAME*WHERE MEMBER*RESIDES'
/*TYPE74PA - path data */
R742PAPP='PATH WAS BUSY*WHEN SELECTED*TO TRANSFER'
R742PDEV='DEVICE*NUMBER'
R742PDIR='DIRECTION*PATH'
R742PIBR='INBOUND SIGNALS*REFUSED*MAX MSG LIMIT'
R742PMXM='MAXIMUM*MESSAGE BUFFER*SPACE'
R742PNME='SYSTEM*NAME'
R742PODV='DEVICE*NUMBER ON*OTHER END'
R742PONA='NAME OF*SYSTEM ON*OTHER END'
R742PQLN='OUTBND SIGNALS*PENDING TRANSFER*ON PATH'
R742PRET='PATH*RETRY*LIMIT'
R742PRST='NUMBER*OF*RESTARTS'
R742PSIG='OUT/IN BOUND*SIGNALS SENT/RCVD*OVER PATH'
R742PSTA='PATH*STATUS'
R742PSTF='STATUS*FLAGS'
R742PSUS='PATH NOT BUSY*WHEN SELECTED*TO TRANSFER'
R742PTCN='TRANSPORT*CLASS*NAME'
/*TYPE74SY - system data */
R742SBIG='NUMBER OF*BIG MESSAGE*CONDITIONS'
R742SBSY='NUMBER OF*NO BUFFER*CONDITIONS'
R742SDIR='DIRECTION*OF THE MESSAGE*TRAFFIC'
R742SFIT='NUMBER OF*MESSAGE FIT*CONDITIONS'
R742SMXB='MAXIMUM*MESSAGE BUFFER*SPACE'
R742SNME='SYSTEM*NAME'
R742SNOP='NUMBER OF*NO PATH*CONDITIONS'
R742SOVR='BIG MESSAGES*THAT EXCEEDED*OPT MSG LEN'
R742SPTH='SIGNALING PATHS*CURRENTLY*IN SERVICE'
R742SSML='NUMBER OF*SMALL MESSAGE*CONDITIONS'
R742SSTF='STATUS*FLAGS'
R742STCL='MESSAGE LENGTH*FOR*TRANSPORT CLASS'
R742STCN='TRANSPORT*CLASS*NAME'
11.TYPE75 data set has also been enhanced with the same new
variables CUNAME and DEVMODEL that were added to TYPE74.
12.TYPE78 now detects and deletes invalid subtype 3 records
to avoid the STOPOVER condition if you have not installed
PTF UY55476 for APAR OY36517 described in MVS notes.
13.TYPE79 subtype 1 changed R791ES to reserved and previous
reserved R791ESSL now contains what was in R791ES and is
renamed R791ESCT! Both R791ES and R791ESCT are kept.
14.TYPE79 subtype 11, new variables R79BCU and R79BDEVN for
control unit name and device name.
15.TYPE90 new subtype 18 added variables SYSISUED,SMF90SGC
and SMF90GRN for the SET GRSRNL command.
16.All five of the XMAC70xx members (needed only for SAS
Version 5 for circumvention of the "344 Compiler Limit"
error condition) now include these and all previous MXG
changes to their corresponding VMAC members. See Change
8.129 for further information on the "344" error. Due to
additional new subtypes added by MVS 4.1, there were 3
new iterative DOs added by this support which may cause
modified BUILDPDBs to need "344" circumvention. Sorry!
Note that IBM has announced additional RMF enhancements in
MVS/ESA 4.2 (RMF 4.2.1) to be available on March 29, 1991,
that will add additional data to type 72, 74, and 79s.
Change 8.166 Variable INNODE was added to _PDB26J2 macro. INNODE and
IMACPDB (previously kept) INROUTE are both required to know the
Oct 23, 1990 source of a job, using PDB.JOBS.
Thanks to Elliot Weitzman, Oryx Energy Company, USA.
Change 8.165 IMS Log processing variable PGMLODTM is now non-zero only
TYPEIMS for the first transaction, for multiple transactions per
Oct 23, 1990 program schedule (since the program is loaded only once!)
and OENQTIME is calculated differently for MULTRANS.
Thanks to Harry Olschewski, DVG Kiel, GERMANY.
Change 8.164 Page 219 references the _DBUG110 macro which no longer
MXG Guide exists. It was replaced by a new (undocumented) value of
Oct 23, 1990 SYSPARM=TYPE110-5, since specifying a SYSPARM value does
not require the source change mentioned on page 219.
Thanks to Hr. Moser, RBG Munich, GERMANY.
Change 8.163 NETSPY target response variables for session manager
VMACNSPY have no meaning, but contained non-zero values (they are
Oct 23, 1990 addresses) in the SMF record. MXG recognized thesession
manager record and set the percentages T1RSPPC-T4RSPPC to
missing, but left the counts T1RSPNO-T4RSPNO as they were
found, which confused some users. Now, the countsare
also set missing for session manager records.
Thanks to Randy Hallman, LEGENT, ENGLAND.
Change 8.162 NPM variables OPER.... are now correctly labeled to show
VMAC28 these fields represent HOST plus NETWORK durations, and
Oct 23, 1990 the NETW.... variables are now corrected to label these
fields as NETWORK only (i.e., eliminating the previously
incorrect NEWT label of Network Plus Host). The values
were correct, only the MXG label was incorrect.
Thanks to Tom Kiddy, American President Lines, USA.
Change 8.161 Support for Landmark's Monitor for CICS Version 8.0
ANALMONI Member TYPEMON8 is used instead of TYPEMONI for this
EXMONHIS new version. The support added two new datasets, the
EXMONMRO MONIMRO (MRO detail from transaction record), and the
IMACMONI MONIHIST history detail, which contains the total-to-
TYPEMON8 current-minute of the resources in the MONISYST interval
Oct 18, 1990 data set. MONISYST is now written every minute. Many new
fields describe counts and durations of both requested
and waiting states. The variable names are patterned:
WTxxyyzz
where xx=activity (see list below).
yy=IO for request active, or
WT for waiting, a subset of request active.
zz=TM for duration, or
CN for count of times activity performed.
eg:
WTFCIOTM=duration File Control IO was requested,
including processing and waiting time,
WTFCIOCN=count of File Control IO requests,
WTFCWTTM=duration that FC IO actually waited, and
this duration is included in WTFTIOTM,
WTFCWTCN=number of times File Control actually waited.
The xx activities captured in Landmark Version 8 are:
xx Requests Waits
DB ='DB2*WAITS' YES
DL ='DLI*CALL*IO' YES YES
DS ='DISPATCH*QUEUE-WAIT' YES
EN ='ENQUE*SUSPEND*WAITS' YES
FC ='FILE*CONTROL*IO' YES YES
IC ='ICP*SUSPEND*WAITS' YES
IS ='ISC (MRO)*SUSPEND*WAITS' YES
JC ='JOURNAL*CONTROL*IO' YES YES
MD ='MRO/DTP*WAITS' YES
MI ='MIRROR*SUSPEND*WAITS' YES
MR ='MRO/IRC*WAITS' YES
MS ='MRO/DTP*SUSPEND*WAITS' YES
NS ='DB2 NON-SQL*CALLS' YES
OP ='OPER*THINK TIME*FOR CONV' YES
PF ='PROGRAM*FETCH' YES YES
PM ='PREEMPT*WAITS' YES
SC ='MRO/ISC' YES YES
SQ ='DB2 SQL*CALLS' YES
ST ='STORAGE*SUSPEND*WAITS' YES
TB ='TEMPSTG*(AUX+MAIN)' YES YES
TC ='TERMINAL*SUSPEND WAITS' YES
TD ='TD (EXTRA)*IO' YES YES
TI ='TD (INTRA)*IO' YES YES
TS ='TEMPSTG (AUX)*OUTPUT' YES YES
UD ='USER*DATABASE' YES YES
1S ='FIRST*DISPATCH' YES
Wherever possible, previous MXG variable names are used
but Landmark names are in comments adjacent to MXG's
chosen variable name in MXG member TYPEMON8. Complete
description of variables is contained in Landmark's
Appendix C of "Report Writer and Extended Facilities",
and in MXG member DOCVER under each MONI.... dataset.
Change 8.160 DCOLLECT record date fields cause "NOTE: INVALID DATA"
VMACDCOL or "NOTE: ILLEGAL ARGUMENT TO FUNCTION" when the julian
Oct 10, 1990 date is a zero, nulls or 99000 or 99366. The three input
statements for DCDDATE1-DCDDATE3 need ?? before the PD4
format item, and the calculation of DCDCREDT and DCDLSTRF
must be protected for 0. The DCDEXPDT expiration date is
more complicated, because EXPDT values of 99000 and 99366
appear in DCOLLECT records, but these cannot be converted
to real date values. DCDCREDT, DCDEXPDT, DCDLSTRF should
be SAS date values, so that subtraction, formatting, etc.
can be done. However, these "flaky" EXPDT values used for
flags should not be lost. Since only EXPDT contain these
"flaky" values, MXG chooses the following technique. New
variable ORGEXPDT will contain the original (raw, in the
record) value (the raw value for Jan 1, 1991 is 1991001).
DCDEXPDT will contain the real SAS date of ORGEXPDT, or
will be missing if ORGEXPDT was zero or missing, but if
ORGEXPDT contains a "flaky" value (day=000, 99000, 99365
or 99366), MXG sets DCDEXPDT of 1JAN 2099 as a special
flag date to tell you to look at ORGEXPDT if you really
need to know the original expiration date. MXG uses a
SAS date in the year 2099 so that if you should ever use
DCDEXPDT in a calculation, you'll see the expiration
date is well into the future!
Thanks to Jim Gilbert, Texas Utilities, USA.
Change 8.159 Variable PAGRT in TYPE71 now includes PGMIEXAU, HIPAGINS,
VMAC71 and HIPAGOUT, in addition to the original DPR, SPR, & VIO
Oct 10, 1990 variables so that PAGRT counts all pages moved between
auxiliary storage (DASD) and central/expanded storage.
The three new fields are MVS/ESA only.
Thanks to Peter Durant, National Australia Bank, AUSTRALIA.
Change 8.158 This was originally a two part technical discussion with
no actual MXG change. The first half of that discussion
is now Change 8.172 and has been reworded and enhanced.
This is the rest of the original technical discussion.
One site wanted to reset their SPINCNT value to 0 at the
end of each month. (I don't recommend this technique,
and its not clear to me this is wise, but by exploiting
MXG's use of the old style substitution macro _SPINCNT,
it was possible to show them how to do what they wanted
to do, with no change to the BUILDPDB code itself):
In IMACSPIN, define _SPINCNT as follows. The value of 10
in the example assumes your original SPINCNT was 10.
MACRO _SPINCNT
. THEN DO;
IF SYSPARM()='MONTH' THEN SPINTST=0;
ELSE SPINTST=10;
IF SPINCNT GE SPINTST THEN OKFLAG=1;
END;
ELSE IF -1 = +1
%
This logic is not obvious, until you look at BUILDPDB
to see exactly how _SPINCNT is referenced, but it shows
how flexible the old style substitution macros can be!
With this new definition for _SPINCNT, and by using the
OPTIONS='SYSPARM=''''MONTH''''' on the EXEC SAS statement
on the desired day, the SPIN library will be emptied.
---Changes thru 8.157 were included in MXG PreRelease 8.4 Oct 9, 1990---
Change 8.157 SAS 6.06 Compatibility Change. SAS User-SMF record.
IMACSASU The format of the SAS-created user SMF record (describing
VMACSASU resources for each PROC execution) was changed in 6.06.
Oct 8, 1990 Now, IMACSASU defines two macros, _IDSAS5 and _IDSAS6 to
identify the SMF record number of each version's record.
If you are currently building TYPESASU from Version 5.18
records, you will have to replace the modified IMACSASU
in your USERID.SOURCLIB with this new IMACSASU member.
Thanks to Tim Haiar, South Dakota Higher Ed. Computer Services, USA.
Change 8.156 Additional enhancements for RMF III VSAM dataset record
EXZRBUWM processing was provided by National Westminster Bank to
EXZRBUWT these members. Two new members, ZRBBATCH and ZRBPRINT
VMACZRB were added and they produce a detailed analysis of batch
ZRBBATCH job delays. Member ZRBDLYBT was rewritten to be more
ZRBBUILD efficient. Member VMACZRB has been amended to include a
ZRBCHECK division-by-zero test for SQA overflow frames.
ZRBDLYBT The function of the associated code members is explained
ZRBDVDLY in member VMACZRB. New member ZRBIPSJ is an interesting
ZRBMKIDX job which is self-explanatory and reads selected members
ZRBPRINT of SYS1.PARMLIB. Two new data set exits were added. The
Oct 8, 1990 remaining members changes were only in the comments. All
"ZRB" members now cite both NatWest's enhancements and
acknowledge the original "ZRB" author, Dick Whiting.
Thanks to Roland Rashleigh-Berry, NatWest, ENGLAND.
Thanks to Dick Whiting, Precision Castparts, USA.
Change 8.155 Variable FWRATIO (Fast Write Hit Ratio) was added to the
VMACACHE CACHE90 data set. Because four Fast Write specific fields
XMACACHE (SRCD,SRCDH,WCD,WCDH) were zero, it appeared there was no
Oct 8, 1990 Fast Write, but FWRATIO was actually non-zero. This value
now matches the same-named heading on the IBM report.
Thanks to Dale Mattison, Shared Medical Services, USA.
Change 8.154 This ROSCOE report did not %INCLUDE IMACROSC and did not
ANALRRTM threfore use the _ROSCDDN as the expected location of the
Oct 6, 1990 RRTMPSE data set used for reporting; now it does.
Thanks to Bob Yeager, Whirlpool Corporation, USA.
Change 8.153 Comments were corrected. The correct sort order for the
ASUMJOBS WEEKBLD after using ASUMJOBS is given by the SUMBY= list
Oct 6, 1990 on the invocation of %VMXGSUM, but anytime that the
temporary variable "DATETIME" is used in the SUMBY list
(as it usually is), the actual variable you must use in
any subsequent processing is not "DATETIME" (which will
always be DROPped by VMXGSUM), but instead the actual
variable set equal to DATETIME= in the macro invocation.
For ASUMJOBS the actual resultant sort order will be
JOBCLASS SHIFT INITTIME
because SUMBY=JOBCLASS SHIFT DATETIME, but also
DATETIME=INITTIME, in the VMXGSUM invocation.
Thanks to Linda Carroll, Crawford Long Hospital of Emory Univ, USA.
Change 8.152 VM/370 Monitor data set VMONCHAN now has the sample count
ANALVMDY variables MN602SAM and MN602SA2 added to the KEEP= list,
VMACVMON and they were added to the RETAIN list so that the are
Oct 6, 1990 carried into the CHAN record from the DEV record. This
avoids the need to merge DEV and CHAN to calculate CHAN
busy. The three tests for (LENGTH-COL) GE 64 should all
be GE 63 so that channels 32 and higher actually INPUTed.
ANALVMDY now uses the MN602SAM/SA2 instead of INTERVAL to
correct its CHAN busy calculations. Variable MN003CDD
should not be DIF()d, and variable DRUMUTIL needed to be
added to the big RETAIN list.
Thanks to Bob Small, Grumman Data Systems, USA.
Thanks to Frank Putnam, Ryerson Polytechnical Institute, USA.
Change 8.151 VM/XA support macro _DBYUSR did not DIF() some of the HF
VMACVMXA counters, causing some percentages to be since the start
Oct 5, 1990 of monitoring. These HF counters are now DIF()d. MACRO
_CSYTUWT should have decremented SKIP by 52 vice 72.
If the Interval or HF Sampling rate were changed, MXG
made the change when the record was found, rather that
as it should have at the end of the interval. That has
been corrected, and notes on the log alert you if either
was altered.
Thanks to Peter Strange, BP International London, ENGLAND.
Change 8.150 This JCL member is an example of the MVS job that submits
JCLCRAYC a job to execute on the Cray to extract the accounting
Oct 5, 1990 and performance data records and send them back (asis)
to the MVS system (into dataset MXG.CRAY.MODFILE) that is
then processed by MXG member TYPECRAY under MVS to build
the Cray PDB. (This specific example is for COS 1.17).
With 1000 Cray jobs per business day, and with the SPM
interval set at 10 minutes, the extract will need about
125 cyl, or about 90MB for an entire WEEKs Cray rawdata.
Thanks to Arlin B. Collins, Oryx Energy, USA.
Change 8.149 Support for Amdahl's SPMS product's SMF record for the
EXTYSPMS 6100 and 6880 Cache DASD controllers. The code was tested
IMACSPMS with the help of the folks at Amdahl, and one real user,
VMACSPMS as the documentation of the SMF record is less than good.
TYPESPMS Data set TYPESPMS is created from the SMF record, but
Oct 5, 1990 only 6100 data records have been validated. Amdahl has
said there will be enhancements in the near future to the
SMF record that will answer many user requirements.
MXG variable names for fields described in the DSECT are
the DSECT suffix prefixed with SPMS. For variables that
are calculated or decoded, the variable name suffix is
SPMS or SPM. Do you like this technique (which was my
choice after looking at the two user contributions from
which this support derived)?
Thanks to Richard R. (Dick) Sziede, PRC Inc, USA.
Thanks to Neville Windeyer, Amdahl, USA.
Thanks to Ray Williams, Amdahl, USA.
Thanks to Neil Avery, Amdahl, USA.
Thanks to Randy Graves, Amdahl, USA.
Change 8.148 NPM Release 4 (NPM 1.4) Support has been added, but not
EX028ER1 yet tested with 1.4 data. This text will change when
EX028ER2 validation has been completed with 1.4 data records.
EX028IN9 Support is in MXG PreRelease 8.4, but because IBM used
FORMATS (correctly!) the relocatable record architecture, their
VMAC28 changes ARE compatible with MXG 7.7. (MXG 7.7 will detect
Oct 5, 1990 the new 1.4 data and will note that unexpected data was
found, but MXG 7.7 will not fail with NPM 1.4 data!). The
change processes mixed 1.3 or 1.4 records, transparently!
1.Support added three New MXG datasets:
NPMERNCP,NPMERNET, for NCP or Network respectively,
are created when a prior Event Exception has been
resolved (either the value is now in range, the
resource was detached, or monitoring was stopped).
NPMINTRI, an interval record reporting resources from
the Network Token Ring Interface.
2.Support added new variables in existing MXG datasets:
NPMINPMT, variables NPMALRCT,NPMARCNT count Alerts
sent or lost.
NPMINSES, variables LSCDANUM,BADI,CNTL,EXTN,GRUP,SMID,
SPLU,SSLU, and LSCDUSER contain (optional) session
manager names (Userid, SLU, etc.) and status.
NPMINNCP, variables NCPNEWNM,NCPGENLV contain NCP load
module name and the GENLEVEL parameter.
NPMINPMT, variables NPMTDROF,DRAD,DRDE,DL18) track the
DDR entries lost, added, or deleted.
3. FORMAT member was updated with new format MG028FL and
existing formats MG028DA and MG028NT contain new
values.
4. The IBM NPM 1.4 Installation and Customization Guide,
Part 1, pages 1-106 provide much better documentation
than its predecessor. A big thanks also to IBM to make
the manual available early so support can be in place!
Change 8.147 TYPE41 variable SMF41LRG is already in bytes and the line
VMAC41 SMF41LRG=SMF41LRG*4096; must be deleted. Some labels did
Oct 1, 1990 not contain * for split characters, but now they do!
Thanks to Ken Williams, Australian and New Zealand Banking, AUSTRALIA
Change 8.146 New members. This set of members provides a capacity
ANALPRTR measurement and planning system for printers, and it
ASUMPRTR defines measures of printer throughput. It is preliminary
IMACPRTR and further additions to BUILDPDB may be made. Definition
TRNDPRTR of printers, costs, etc., are made in IMACPRTR, and then
Oct 1, 1990 member ASUMPRTR can be added to BUILDPDB to create the
dataset PDB.TYPE6ENH ("Enhanced", with throughput stats),
which is the basis for ANALPRTR, and TRNDPRTR. See the
comments in each member for documentation.
Thanks to Chuck Hopf, Hopf Consulting, USA.
Change 8.145 RACF variable RACFDESC contains undecoded values which
FORMATS were printed as a colon because the MXG format did not
Oct 1, 1990 recognize the additional bits added by RACF 1.9. The data
itself was not wrong; bit 0 is a violation and bit 3 is
a warning. Because IBM uses multiple bits in this field,
the $MG080DE. format now includes values A0 and 88 for
violation and values 30 and 18 for warning.
Thanks to Joseph Rannazzisi, Brooklyn Union Gas, USA.
Change 8.144 New members. JCL example and code used to print the MXG
JCLUPPDS source library (or any source PDS) in two column format
VMXGPPDS with an Index of members. The JCL uses standard IBM PSF
Oct 1, 1990 control statements in the SYSIN for all steps.
Thanks to Chuck Hopf, Hopf Consulting, USA.
Change 8.143 Critical error, but only in MXG 8.3. The order of INDATA
TRNDRMFI datasets was changed for consistency, but the (IN=INWEEK)
TRND72 option was not re-located, which caused the Trend dataset
Oct 1, 1990 TYPE72 and RMFINTRV to be badly corrupted.
Change INDATA to correctly read:
INDATA=WEEK.TYPE72 (IN=INWEEK) TREND.TRND72,
INDATA=WEEK.RMFINTRV (IN=INWEEK) TREND.RMFINTRV,
Thanks to Raymond Zieverink, Belk Stores Services, USA.
Change 8.142 This member was intended to produce trend charts from the
GRAFREGR VM/370 trend data set TREND.VMONINTV, but somewhere in an
Oct 1, 1990 EDIT session, VMONINTV inadvertently became RMFINTRV!
Thanks to Bob Yeager, Whirlpool Corporation, USA.
Change 8.141 a.Enhancement. The existing code used default pattern and
GRAFTRND color selection when building bar charts. This is fine
Oct 1, 1990 when the graphs are viewed in color, but if reproduced in
black and white they can be very difficult to read. This
change solves this problem by alternating cross-hatching,
left diagonals, and right diagonals in varying densities.
Colors are also selected but only eight are used. If the
default PCBATCH device driver is used, there should be no
difficulty on any device with eight or more colors. You
could use a color catalog (described in the SAS/GRAPH
manual) to modify the colors in use. All MXG GRAFxxxx
routines that use the PCBATCH device driver default to
WHITE for the titles and axes and any text. If you are
using a pen plotter, you may wish to force the conversion
from WHITE to BLACK.
b.Bar charts for workloads create segments in the legend
for workloads that have zero CPU time. This is not really
an error but it's annoying to have to explain nonexistent
workloads to your management. This change only outputs
those workloads with non-zero CPU time.
c.If SASGRAPH=NO and SASSTAT=YES were specified, the first
plot received a "variable not found" message. The PROC
PLOT was pointed at the wrong dataset.
Change 8.140 New member that produces bar charts of workloads by hour
GRAFWORK from RMFINTRV. Will use SAS/GRAPH if available, otherwise
Oct 1, 1990 produces printer charts and tabular reports.
Change 8.139 Cosmetic change added new optional argument INVOKEBY to
VMXGSUM %VMXGSUM macro that will be printed on the SAS log to
Oct 1, 1990 identify which member invoked %VMXGSUM. As time permits,
each MXG invocation of %VMXGSUM will be changed to pass
the member name into this argument for documentation on
your log. This is mostly helpful when one is debugging!
Change 8.138 Significant validation and enhancement of MXG's supprot
EXHSMDSR for the HSM User SMF records (default is 240 and 241) is
EXHSMFSR added by this user contribution. Code has been unloaded
EXHSMFST and syntax tested, but not actually used. One of the HSM
EXHSMFUN SMF records contains accumulated counts that are reset
EXHSMVSF each midnight, and de-accumulation may be desirable but
EXHSMVSR has not yet been investigated. The other record seems to
FORMATS be directly usable.
IMACHSM
VMACHSM
Thanks to Wanda Prather, Johns Hopkins APL, USA.
Change 8.137 TYPE1415 Hiperbatch variables (added by Change 8.017) are
VMAC1415 non-zero (garbaged) for type 14/15 records with more than
Sep 19, 1990 one UCB, which occurs only for BPAM accessed concatenated
PDSs, which aren't even eligible for Hiperbatch! The test
IF LENGTH-COL+1 GE 20 THEN .... should be changed to
IF LENGTH-COL+1 GE 20 AND NUCB=1 THEN .... so that only
non-BPAM data sets with a single UCB are tested to see if
the hiperbatch fields exist. (MXG must use the length of
the record to determine if data exists that could be the
hiperbatch fields, because IBM does not set a flag to say
that the fields are present, and IBM also failed in the
original implementation to set the length of the segment
to include the new fields!)
Thanks to Linda Carroll, Crawford Long Hospital of Emory Univ, USA.
Change 8.136 The DFP 3.2 type 42 SMF record to audit an ACTIVATE event
VMAC42 is created in error. IBM APAR OY36035 describes the error
Sep 18, 1990 and PTF UY55307 is the correction for their error. The
subtype 3 (audit) record is mis-located and incorrectly
documented in the SMF manual, and will cause MXG to abend
with a STOPOVER, than can be circumvented only by adding
this test to member IMACFILE (which deletes all subtype 3
audit records) until the PTF exists from IBM:
IF ID=42 THEN DO;
INPUT @85+OFFSMF TESTDFP $CHAR8. @;
IF TESTDFP='ACTIVATE' THEN DELETE;
END;
or alternatively by using the MISSOVER circumvention for
STOPOVER option as described in Change 8.012.
Member VMAC42 was re-written based on the corrected SMF
record description received from IBM Level 2, and tests
for both the right and wrong format record. Fortunately,
the subtype 3 record is not very important and deleting
it won't really hurt the good data in the other subtypes!
Thanks to Dan Barbatti, Southwestern Bell, USA.
Change 8.135 PR/SM changes in status were not decoded in TYPE70PR. Now
VMAC7072 variables LCPUCHST, LCPUCHWT, LPARCHAC and LPARCHNR flag
Sep 17, 1990 that changes occurred in LCPUWAIT status, LCPUSHAR value,
Activation/Deactivation, or Number of LPARS in Partition,
respectively.
Thanks to Richard Evans, Mervyns, USA.
Change 8.134 The ACBMACR1-3 variables added in MXG Version 7 (decoded
VMAC64 after PTF UY40839, APAR OY23661 has been installed) are
Sep 15, 1990 now explicitly decoded into useful new flag variables:
ACBADR ='ACCESS*WITHOUT*INDEX?'
ACBAIX ='AIX OF THE PATH IN THE GIVEN DDNAME?'
ACBCNV ='CONTROL*INTERVAL*PROCESSING?'
ACBDFR ='DEFER*WRITES'
ACBDIR ='DIRECT*PROCESSING?'
ACBDSN ='SHARING*CONNECTION*USING DSNAME?'
ACBGSR ='GLOBAL*SHARED*RESOURCE?'
ACBICI ='IMPROVED*CI*PROCESSING?'
ACBIN ='INPUT*(GET,*READ)?'
ACBKEY ='ACCESS DATA*VIA*INDEX?'
ACBLOGON='LOGON*INCICATOR*(VTAM X03004)?'
ACBLSR ='LOCAL*SHARED*RESOURCE?'
ACBMODE ='VSAM*31 BIT*ADDRESSING?'
ACBNCFX ='CFX IF Y,*NFX IF BLANK?'
ACBOUT ='OUTPUT*(PUT,*WRITE)?'
ACBRST ='SET*DATA SET TO*EMPTY STATE?'
ACBSEQ ='SEQUENTIAL*PROCESSING?'
ACBSIS ='SEQUENTIAL*INSERT*STRATEGY?'
ACBSKP ='SKIP*SEQUENTIAL*PROCESSING?'
ACBUBF ='USER*BUFFERS?'
Thanks to Derek Cespedes, Florida Power and Light, USA.
Change 8.133 The technique for setting the number and length of the
IMACACCT Accounting variables kept in MXG from SMF records has
Sep 13, 1990 always been an exposure to user error, because the user
was required to actually alter the SAS code in member
IMACACCT, which occasionally caused a STOPOVER condition
to new users unfamiliar with SAS syntax. A much safer
and easier technique has now been implemented. Instead of
commenting out code for unwanted account variables, the
simple addition of a DROP statement naming the unwanted
variables will keep only the wanted with no code changes.
Existing sites need not change their IMACACCT member, but
may wish to do so anyhow.
The only price for this technique is that programs that
%INCLUDE member IMACACCT more than once will cause a new
warning message (but only under SAS 5.18) that reads:
WARNING 393:VARIABLE ALREADY SPECIFIED IN DROP/KEEP LIST.
The warning itself has no effect.
Thanks to Rich Hawthorne, Group Health Coop. of Puget Sound, USA.
Change 8.132 One major and several minor changes to RMF to support the
VMAC7072 ES/9000 series under MVS/ESA 3.1.3 from (GC28-1819-3).
VMAC71 1.ES/9000 Processors will cause STOPOVER abend on type 78
VMAC73 SMF records, because IBM added data to the IOP and IOQ
VMAC74 sections which MXG was not prepared to handle! The new
VMAC75 fields (see below) are now supported, and the MXG "SKIP"
VMAC76 logic now protects future segment length changes. Even if
VMAC77 you have this MXG change installed, MXG will STOPOVER if
VMAC78 IBM's PTF for APAR OY36517 is not installed, as the IBM
VMAC79 PTF which added RMF support for ES/9000 (UY90666) itself
Sep 13, 1990 is in error until PTF OY36517 is installed.
2.New flag variables ESCAENAB,ESCACONF identify if this
processor is enabled for ES Connection Architecture, or
there is an ES connection director in the configuration.
3.The MSOCOEFF field in the type 72 and type 79 records was
increased from 4 to 8 EBCDIC characters (I cannot imagine
why) and relocated to the end of the section. MXG picks
up the longer field if it exists, but since an 8 digit
number can still be stored in a 4-byte MXG variable, the
IBM increase has no effect on the MXG MSOCOEFF length.
4.PCTDIRPT, percentage of samples when I/O was delayed due
to Director Port (ESCA, or Fiber Optic Channels) busy is
added to TYPE78CF, TYPE79EF, and as variable R799DPB in
TYPE799.
The only circumvention for the STOPOVER condition until
you receive this change is to delete the type 78 subtype
3 record in member IMACFILE:
IF ID=78 AND SUBTYPE=3 THEN DELETE;
or alternatively use the MISSOVER replacement for the
STOPOVER option as described in Change 8.012.
Change 8.131 Minor enhancement to TYPE41AC and TYPE41UN data sets for
FORMATS Data-in-Virtual added format for object type (DA) and
VMAC41 object mode (Read or Update).
Sep 12, 1990
Change 8.131 The CMS example on page 24 of the MXG Supplement to copy
VM example VM/Monitor data to a CMS file named MONITOR DATA A does
Sep 12, 1990 not specify DCB attributes on the FILE MONOUT statement,
and the CMS default of FB, 80, 960 causes the output data
records to be truncated. The correct FILE statement is:
FILE MONOUT RECFM=VB LRECL=4092 BLKSIZE=4096;
There is additional discussion of possible problems with
the subsequent GLOBAL statement in Change 6.212 in member
CHANGE06.
Change 8.130 Validation and enhancement of the DCOLLECT processing was
VMACDCOL added by this change. All 7 record types are supported to
Sep 12, 1990 create DCOLDSNS, DCOLVOLS, DCOLCLUS, DCOLMIGS, DCOLBKUP,
DCOLCAPD, and DCOLCAPT data sets. The documentation for
the output of this IDCAMS utility named DCOLLECT is found
in several manuals. GG24-3540-00 "DFSMS Planning and
Reporting" provides an overview of DCOLLECT. The first 3
MXG data sets above are built from VTOC/VVDS information
and their contents are described in Appendix E of DFP 3.2
"Access Method Services for Integrated Catalog Facility",
SC26-4562-1. The final 4 MXG data sets are HSM related,
and their contents is described (poorly, DCOLLECT is not
even cited in the table of contents nor the index) in
Chapter 17 (User Application Interfaces) of SH35-0084-4,
"DFHSM 2.5.0 Installation and Customization Guide".
A future MXG newsletter will contrast the data available
from the DCOLLECT facility with the data created from the
VMXGVTOC and VMACVVDS, and will (hopefully) also compare
the HSM DCOLLECT data captured with the data available
from MXG's JCLHSM (BCDS,MCDS, etc), and the HSM SMF data
record (VMACHSM, still work in progress). The initial
review does make DCOLLECT attractive, especially since it
is a supported interface from IBM, but there appears to
be some data simply not available from DCOLLECT that may
be important (such as physical data set location).
Thanks to Jim Gilbert, Texas Utilities, USA.
Thanks to Sal Fazzino, General Electric Capital, USA.
Change 8.129 SAS 5.18 Compiler Error 344 circumvention. An iterative
XMACACHE DO was added by MXG 8.3 for DB2 Distributed Header in the
Sep 12, 1990 VMACDB2 processing. That broke the compiler limit in 5.18
at a site which had added DB2, Cache DASD, and several of
their own SMF records to BUILDPDB processing. In looking
for additional opportunities to eliminate iterative DOs,
this change creates replacement member XMACACHE from the
existing VMACACHE member. XMACACHE will ONLY process the
3990 Cache Controller records (although the 3880 datasets
will still be built with zero observations) and thereby
eliminated 4 iterative DO statements. If you have added
VMACACHE processing to BUILDPDB and get the 344 Error,
copy XMACACHE into your USERID.SOURCLIB and rename it
therein to VMACACHE. The original discussion of Error
344 Circumvention is in Change 7.038 in member CHANGE07.
Note that 344 is only a problem with SAS 5.18. There is
no limitation on iterative DOs in SAS 6.06.
Thanks to Dan Barbatti, Southwestern Bell Telephone, USA.
Change 8.128 SMS (System Managed Storage) adds a new record to the
VMAC60 VVDS for non-VSAM files on SMS-managed volumes, a pseudo
VMACVVDS VVR record called the NVR. Unlike real VVR records that
Sep 5, 1990 describe space, etc., the NVR record has no such data.
However, the NVR and the VVR records both now contain the
SMS attributes (Data, Storage, & Management Class Names).
The new MXG variables VVRDATCL,VVRSTGCL,VVRMGTCL are the
class names, new variable VVRSBKUP is the last backup
date, and flag variables VVRNATTR,VVRSMSFG were added.
The NVR record was processed without error by TYPEVVDS,
but the TYPE60 member failed with a STOPOVER condition
if it encountered the new NVR data record without this
change.
Thanks to Jim Gilbert, Texas Utilities, USA.
Thanks to Sal Fazzino, General Electric Capital, USA.
Change 8.127 Preliminary support for MVS/ESA Version 4 SMF changes.
IMACPDB 1.New variable VARIEDBY was added to TYPE8911 (but applies
VMAC8911 only for SMF type 9 or 11 vary record) to identify who
VMAC30 issued the vary command. (In Version 4, a terminal user
Sep 5, 1990 can actually signal to MVS to vary the device offline).
2.New variable MVSLEVEL was added to the type 30 datasets
(and will contain SP4.1.0 for MVS/ESA Version 4) so that
you can finally know which software operating system was
in use at the step/job accounting level. MVSLEVEL was
also added (in IMACPDB) to the variables to be kept in
PDB.STEPS and PDB.JOBS.
3.Additional changes in MVS/ESA Version 4 that did not need
MXG changes but which should be noted:
a. A new bit in the header identifies MVS as Version 4.
b. Long standing problem with the internal 3-byte counter
for step/job CPUTCBTM (which wrapped at 17 hours) is
now corrected, and a 4-byte field is used internally.
This will correct CPU times for these long-running job
records in the type 30 (used by BUILDPDB), but for any
site still clinging to the archaic 4, 34, 5,or 35 SMF
record, the CPU times are still only 3-bytes, and will
not be correct. (In fact, MVS Version 4 now sets a bit
if the 3-byte field overflows to tell you to use the
CPU times in the type 30 instead!).
c. APPC support was added, but accounting fields for APPC
are added only to the type 30s, and not 4,34,5,35s.
d. SMF Exits IEFUJP and IEFUJV must be AMODE 31.
Change 8.126 SAS 6.06 Compatibility. JCL Examples.
CONFIG The JCLTEST example creates the MXG Format Library and
JCLTEST exercises the MXG system under SAS. Member JCLTEST was
JCLTEST6 revised for SAS Version 5, and now %INCLUDES new member
JCLPDB SASOPTV5 which specifies the SAS System Options that are
JCLPDB6 now required by MXG Version 8.3 and later. SAS Version 5
SASOPTV5 format library still uses the DDname "SASLIB" and uses a
Sep 5, 1990 DSNAME of "MXG.SASLIB" in this example for Version 5.
New member JCLTEST6 provides an example of the JCL needed
for SAS Version 6.06, and references the CONFIG member to
specify the Version 6 recommended options. SAS Version 6
format library now uses the DDname "LIBRARY" and uses a
DSNAME of "MXG.FMTS606" in this example for Version 6.
Change 8.125 SAS 6.06 Compatibility. SYS prefix reserved in %MACROs.
ANALDMON Syntax of %LET SYSTEM causes "ERROR: Attempt to %GLOBAL
ANALNPMR a name (SYSTEM) which exists in a local environment."
Sep 4, 1990 This is actually a bug in SAS 6.06, but there is a good
possibility that the SYS.... prefix may be reserved in
%MACRO variables/arguments in SAS 6.07, and thus the two
occurrences in MXG in which SYSTEM= was used as a macro
variable (to select the SMF System ID for the report)
have been changed to SMFSYSTM= instead of SYSTEM.
Change 8.124 Variable SMGS_MIN in this NSPY reporting program should
ANALNSPY have been spelled SMSG_MIN in the FORMAT statement in
Sep 4, 1990 line 006000.
Change 8.123 The MXG 8.2 circumvention (Change 8.020) for invalid CPU
VMACSYNC time in SYNCSORT SMF records was mis-typed and caused
Sep 4, 1990 TYPESYNC to contain garbage. Line 042910 was added as
@M4 CPUERTST but it was supposed to be
+M4 CPUERTST $CHAR4.
to redefine CPUERTST as a character value of CPUTCBTM for
the subsequent test (M4 is set equal to minus four).
Change 8.122 Member FORMATS produced warning message because there are
FORMATS no quotes for $MG037FU format definition.
Sep 4, 1990
Change 8.121 DB2 PMAUD02 and PMAUD03 report request produced 145 and
ANALDB2R 170 SAS errors. The format for variable QW0145TS in both
Sep 1, 1990 PUT statements should be HEX16. instead of $HEX16.
Thanks to Tim Kearney, Allied Automotive, USA.
Change 8.120 The allocation for SAS 6.06 format library needed SPACE
FORMATS of CYL,(10,1) during 6.06 beta testing; unbeknownst to
LIBRARY me, the problem had been fixed in 6.06.01, and in fact,
SASLIB MXG's format library under SAS 6.06 requires only space
Sep 1, 1990 of (CYL,(1,1)). References have been corrected.
Thanks to Dan Squillace, SAS Institute Cary, USA.
--Changes thru 8.119 comprised MXG PreRelease 8.3 Dated August 26, 1990-
Change 8.119 IMS Log Input Queue times were incorrect whenever an
TYPEIMS IMS transaction had no ARRVTIME in its 01/03 record.
TYPEIMSX Why IBM can't put the DATE and TIME in every IMS log
VMACIMS record is beyond me, but they don't. Because of the
Aug 26, 1990 missing value, these records sorted early and caused
sometimes significant errors in IMSQUETM & RESPNSTM.
Comparison with IBM's DFSILTA0 output shows that IBM
uses the ENQTIME as the ARRVTIME in these cases, and
now MXG also uses ENQTIME. The implementation was to
use the timestamp of the just-previous-log-record minus
.001 for ARRVTIME when ARRVTIME was missing. That causes
the sort order to be correct, and the .001 allows MXG
to recognize that ARRVTIME was missing (IMS time stamps
are only accurate to .1 seconds), and thus MXG can use
ENQTIME for ARRVTIME in these cases.
In further examination of the test data and the output
of DFSILTA0, it became apparent that even IBM's IMS
guru's can't figure out how to put IMS transactions
together with that program, even though DFSILTA0 is
essentially simulating IMS processing and can keep
everything it needs in virtual storage. About one
third of these IMS 2.2 transactions have missing
time stamps on the DFSILTA0 report, especially when
multiple transactions are executed with a single
program schedule. Further review suggested that if
using the adjacent record's time stamp was good for
a missing ARRVTIME in an 01/03 record, it was also good
in those many cases where the 03 log contained a non-
missing, but much-earlier-than-now timestamp, and now
those cases are also detected and protected this way.
Additional logic enhancments were offered by Ashland
Oil, whose contribution in recalculation of output queue
times were implemented in this change as well.
And for those of you still using IMS 1.3, remember that
member TYPEIMS1 (See Change 7.075 in member CHANGE07)
is only for that archaic IMS version.
Thanks to Richard S. Ralston, Rochester Telephone, USA.
Thanks to Ervin Claxon, Ashland Oil, USA.
Change 8.118 IMS Log processing did not handle a cold start. This
IMACIMS contributed discovery added processing in VMACIMS to
TYPEIMS detect a cold start of IMS (a subtype of type 40 record)
VMACIMS and added IMSQBLDN to count each new queue build event.
Aug 25, 1990 In TYPEIMS, the SORT order which formerly was
IMSTAPNO DTOKEN PSTNUMBR TRANSACT IMSRECNO is now
IMSQBLDN DTOKEN PSTNUMBR TRANSACT IMSTAPNO IMSRECNO
which not only handles cold starts, but solves several
site's problems with incorrect input queue time, by
re-associating IMSTAPNO with IMSRECNO. The same SORT
logic (with different variables) was applied throughout
TYPEIMS, and the conditional tests were restructured.
Thanks to J. Cary Jones, Philip Morris, USA.
Change 8.117 Philip Morris has made this major contribution to MXG
ASMVTOC for DASD management and measurement. They replaced the
JCLDASD functional but slow %VMXGVTOR and %VMXGVTOC programs
VMXGVTOF (which used SAS and CVAF) to read the DASD VTOCs, with
ANALVVDS ASMVTOC, a very fast assembly program that extracts the
Aug 25, 1990 VTOC data into a flat file. JCLDASD is a jobstream to
execute ASMVTOC (and MXG's pre-existing ASMVVDS program)
and it uses VMXGVTOF and ANALVVDS (which were originally
named MPXGVTOC and MPXGVVDS in PreReleases) to
manage, measure, and recover DASD space. This has only
been repackaged before addition to MXG 8.3, but it
has been running at Philip Morris for some time. Note,
however, that it is now Merrill Consutants, and not
Philip Morris who is now responsible for problems!
Thanks to Tuanhung Doanvo, Philip Morris, USA.
Change 8.116 MXG's Quality Assurance job stream is contained in the
JCLUXREF two JCL members, one for 5.18, the second for 6.06, and
JCLUXRE6 the reporting ANAL.... members have finally been added
TESTANAL into the test stream!
Aug 25, 1990
Change 8.115 SAS 6.06 Compatibility. Macro compiler logic error.
ASUMVMON This circumvention was made before it was known that SAS
TRNDCICS ZAP Z6060916 corrected the problem. The %VMXGSUM macro
TRNDJOBS is invoked by these members, and should generate a line
TRNDRMFI SAS code for each variable in the NORMn= list, but this
TRNDTMNT error caused %VMXGSUM to terminate the scan early and the
TRNDVMON code generated was wrong, yet there was no error message!
Aug 24, 1990 The error was discovered because the scan truncated the
name of a variable, causing that variable to surface on
the list of variables without labels in the QA jobstream!
By moving the NORMn= variables in the 2nd and subsequent
lines, the problem seemed to go away, but now that there
is a zap for the problem, put it on and don't trust this
repositioning circumvention.
Thanks to Chuck Hopf, Hopf Consulting, USA.
Change 8.114 SAS 6.06 Compatibility. %VMXGFOR macro for FORCE option.
VMXGFOR See ZAP Z6060571 (which was superceeded by Z6060969)
Aug 24, 1990 circumvented the need for FORCE on PROC SORTs, but since
that ZAP disables this new FORCE "feature", not all sites
may choose to disable FORCE. So, for those MXG sorts in
which the input and output data sets are the same, this
changes adds %VMXGFOR (which has value FORCE under 6.06,
and a null value under 5.18)in these 65 members. With
this source circumvention installed, the above zap is
now optional, instead of required, for MXG.
However, this change now makes two SAS options mandatory
for execution of MXG. SAS Options MAUTOSOURCE and
SASAUTOS=SOURCLIB is now required to locate the %VMXGFOR
macro which implemented this change. (These options have
always been required for MXG programs which used %MACROs,
such as ANALDB2R, but now ALL executions of MXG must use
these two options to resolve the location of %VMXG...
macros.)
ANALALL ANALAUDT ANALBNCH ANALBNC1 ANALCACH ANALCICS
ANALDB2R ANALDMON ANALDOS ANALESV ANALMNTS ANALMONI
ANALMPL ANALNAF ANALNPA ANALNPM ANALNPMR ANALNSPY
ANALPATH ANALPDSM ANALPROG ANALRRTM ANALSMF ANALSUPR
ANALTAPE ANALTURN ANALVARY ANALVM ANALVMDY ANALVMOS
BUILDPDB BUILDPD3 DIFFDB2 DIFFROSC DIFFTPX GRAFREGR
GRAFRMFI GRAFTMNT GRAFTRND IDMSAPND IDMSJANL JCLHSM
JCLTREND PDBTREND RMFINTRV SYSLOGJ3 TYPEDOS TYPEIMS
TYPEIMS1 TYPEIMS3 TYPEMONI TYPETMS UTILCICS UTILDUMP
UTILPRAL UTILSPAC UTILXRF2 VMACCRAY VMACVMON VMACVMXA
VMXGHSM VMXGSUM VMXGVTOC ZRBRPT1 ZRBRPT2
Change 8.113 Incompatible changes in MXG Trending were implemented by
DOCTREND this change, for prior users of MXG Trending data sets.
GRAFTRND The TREND.RMFINTRV and TREND.TYPE72 data sets have been
JCLTREND renamed to TREND.TRNDRMFI and TREND.TRND72 with MXG 8.3.
TRNDRMFI All that you need to do is to rename these two datasets
TRNDVDEV in your TREND library BEFORE you run the MXG 8.3+ TRND...
TRNDVMON programs, using:
TRND72
Aug 22, 1990 PROC DATASETS LIBRARY=TREND;
CHANGE RMFINTRV=TRNDRMFI
TYPE72 =TRND72 ;
Ok, so now you didn't see this note, you have run your
new TRNDRMFI, and discover only last week's data is in
your trend plots. Have we destroyed your old data? No!
It's still sitting in your TREND library, as datasets
RMFINTRV and TYPE72, but now you can't rename them, as
there's already a TRNDRMFI and TRND72 in your TREND!
In this case, you need only combine the old data sets
with the new data sets:
DATA TREND.TRNDRMFI;SET TREND.TRNDRMFI TREND.RMFINTRV;
DATA TREND.TRND72 ;SET TREND.TRND72 TREND.TYPE72;
and you will have lost nothing and will be compatible!
I apologize for the inconvenience of this change, but the
TREND data sets need to be named differently, because the
contents (especially TRND72) is quite different than the
TYPE72 data set.
The consolation may be the new member, DOCTREND, which is
a preliminary documentation of which members of the Trend
Data Base are built by which members of MXG Software!
Change 8.112 Chuck Hopf's excellent paper on generation of DB2PM-like
DOCDB2PM reports using ANALDB2R (which Chuck wrote) is now added
Aug 22, 1990 to the MXG documentation in DOCDB2PM.
Thanks to Chuck Hopf, Hopf Consulting, USA.
Change 8.111 NPM 1.3 Subtype 82 (x'52'), and perhaps other subtypes,
VMAC28 have BASNCPDT and BASNCPTM values of 0, which cause INPUT
Aug 22, 1990 function error when creating BASTIME from those fields.
In line 163610, replace THEN with AND, and insert a new
line containing BASNCPDT GT 0 AND BASNCPTM GT 0 THEN
to eliminate the error message.
Thanks to Ross Pover, Immigration & Ethnic Affairs, AUSTRALIA.
Change 8.110 MXG QA runs uncovered that variable STRTTIME was not kept
TYPEMONI in MONIDBDS and MONIUSER data sets built from Landmark
Aug 22, 1990 CICS data.
Change 8.109 MXG QA now includes testing of the TREND data base, and
JCLTRND as a result, the data sets built by the default TREND
TESTTRND options are documented (finally) in DOCVER and DOVER08
Aug 21, 1990 in MXG 8.3 and later.
Change 8.108 SAS 6.06 Compatibility. Eliminate multiple macro compile.
ASUMCICS These members defined %MACROs VMXGSUM and VMXGDUR using
ASUMDBDS %INCLUDE logic, but this causes a re-compile each time
ASUMDOS that the include is executed. Instead of using %INCLUDE
ASUMTMNT statements, these macros will automatically be defined
ASUMVDEV only one time by the combination of SAS system options
ASUMVMON MAUTOSOURCE SASAUTOS=SOURCLIB (which have always been
TRNDCICS recommended in MXG executions using %MACROs). In an
TRNDDOS unrelated change, DROP DATETIME was also added to each
TRNDJOBS invocation of VMXGSUM to save 8 bytes per observation.
TRNDRMFI
TRNDTMNT
TRNDVDEV
TRNDVMON
TRND72
Aug 21, 1990
Change 8.107 Addition of TREND testing to the MXG QA stream uncovered
TRNDDOS a syntax error, and the delete of DATETIME mention above
Aug 21, 1990 was also added.
Line 001600, delete (DROP=DATETIME) from line
Line 002800, change ;'); to ';
Insert new line after 002800
DROP DATETIME;);
Change 8.106 VM/370 Monitor processing could calculate incorrect value
VMACVMON for date timestamps, but only in the Western Hemisphere,
Aug 20, 1990 and only if the Monitor Start Record (0.97) timestamp in
GMT was after the 202-day interval midpoint and the local
timestamp was before the 202-day interval midpoint, which
at most could occur every 202 days. The error only occurs
in that one day's execution of MXG. The midpoint datetime
of the current 202-day interval was at 04AUG90:03:43:52.
If the VM/Monitor was started on that date at 00:00 local
time, all Western Hemisphere sites had a GMT of 05:00 or
later, and MXG calculated STARTIME 43 minutes too early!
Whew! The error is in the heuristic algorithm to decode
the 5-byte datetimestamp (only 202 days fit in 5 bytes).
and determine the timezone value, which did not protect
for the preceding situation. Replace lines 209200 thru
029600 (now and IF (16*MNHTOD ... to END; ) with:
IF (COLLTIME-BASETIME) GT 0.75*FFFFF AND 16*MNHTOD LT 0.25*FFFFF
THEN BASETIME=BASETIME+FFFFF;
ELSE IF (COLLTIME-BASETIME) LT 0.25*FFFFF AND 16*MNHTOD GT
0.75*FFFFF THEN BASETIME=BASETIME-FFFFF;
IF 16*MNHTOD GT FFFFFOV2 THEN LASTHALF=1;ELSE LASTHALF=0;
Thanks to Frank Putnam, Ryerson Polytechnical Institute, USA.
Change 8.105 IDMS 10.2 Batch Jobs ACCOUNT1-ACCOUNT3 fields were not
EXIDMTAS decoded, because no sample data had been seen. Now it has
Aug 20, 1990 been, and you can decode batch job's account fields into
those variables in Exit member EXIDMTAS, which should be
copied into your USERID.SOURCLIB and modified therein to
contain the appropriate substring operations. For example
if your three account fields are 17, 8, and 4 bytes long,
you would insert the below example. (Note that the first
byte of ACCOUNT1 begins in byte 2 of TASBFLDS):
IF TASTTYPE='.1......'B THEN DO; /* BATCH ONLY */
ACCOUNT1=SUBSTR(TASBFLDS,2,17);
ACCOUNT2=SUBSTR(TASBFLDS,19,8);
ACCOUNT3=SUBSTR(TASBFLDS,27,4);
END;
Thanks to Harold L. Correll, Harris Corporate, USA.
Change 8.104 CA7 (formerly UCC7) job scheduling package still corrupts
VMACTSOM SMF records, as first described in Newsletter TEN, 1986.
Aug 20, 1990 CA says 4 sites have reported the problem and they are
"looking into it", but have no immediate plan for a fix.
CA7 modifies the READTIME of a controlled job by writing
a non-zero value in the first byte of its julian date, to
flag that this job is under CA7's control. When that job
terminates, CA7 is supposed to remove its corruption and
restore the valid julian date, before the SMF records are
written. CA7 corrects the SMF record in IEFU83, after the
record has been built, and only corrects the SMF records
that it knows about. CA7 does not know about TSO/MON!!
TSO/MON creates SMF records for batch jobs that execute
TSO commands, and if that job is under CA7 control, that
SMF record contains corrupted READTIME values, causing an
"INVALID DATA FOR READTIME ...", a hex dump of the record
and several pages of variable=value error messages.
Since CA appears incapable of rapid response, and since
the error is likely to show up again, this specific fix
to CA7s corruption of TSO/MON records can generically be
used for any other (future) SMF record corrupted by CA7.
a.Locate all occurrences of inputting READTIME SMFSTAMP8.
in member (in VMACTSOM, lines 034700 and 068800). Change
all occurrences to now read READCA7S $CHAR8. instead.
b.Find the @; which terminates the INPUT statement you just
fixed (in VMACTSOM, lines 040100 and 072500). Insert four
lines after each @; which read:
IF SUBSTR(READCA7S,5,1) GT '01'X THEN DO;
SUBSTR(READCA7S,5,1)='00'X;
READTIME=INPUT(READCA7S,SMFSTAMP8.);
END;
Note that this fix is only waranteed thru Dec 31, 2099.
If CA7 is still corrupting SMF data in the year 2100,
(since they are overwriting the century byte of date)
the 01 in the algorithm will need to be changed to 02!
Thanks to Keith Mo, Empire Blue Cross Blue Shield, USA.
Change 8.103 SAS 6.06 Compatibility. VMXGSUM DROP= conflict.
ASUMVMON Change 8.089 in MXG 8.2 added DROP=MXGMISS MXGNMISS to
TRNDVMON the %VMXGSUM macro, but two members that invoke %VMXGSUM
Aug 12, 1990 already contained DROP= arguments, causing syntax errors
Aug 21, 1990 (that should have been caught in MXG 8.2 testing), and
thus this change only affects recipients of MXG 8.2. But
while we were at it, we also removed the unnecessary
includes discussed above in Change 8.108.
1.ASUMVMON, delete line 001200 to eliminate %INCLUDE.
Line 001600, remove (DROP=WFRENUM DATETIME)
Line 003700, change ;); to ;
Insert new line after 003700 containing
OUTCODE=DROP WFRENUM DATETIME;);
2.TRNDVMON, delete line 001100 to eliminate %INCLUDE
Line 001500 remove (DROP=WFRENUM DATETIME)
Line 003700 remove )
Insert new line after 003700
DROP WFRENUM DATETIME;);
Change 8.102 For the DB2ACCT Accounting data set in a Distributed DB2
VMACDB2 environment, the Distributed Header fields QWSHCCNT,
VMAC102 QWHDLUNM, QWHDNETI, QWHDRQNM, and QWHDUNIQ are now added.
Aug 12, 1990 In the type 102 trace correlation header, QWHCOPID is now
decoded. In both the 101 and 102 SMF records, MXG now
looks for all five possible header types.
Thanks to Mike Atterberry, Rockwell International, USA.
Change 8.101 ANALDB2R Accounting Trace Long worked if the Trace Short
ANALDB2R was requested, but if the Trace Long alone was requested,
Aug 9, 1990 a SORT VARIABLE error occurred. Adding SORTBY=DBT, to the
ANALDB2R invocation will make the problem go away, or
adding these four lines after line 018980 will fix it:
%IF &PMACC02 NE YES %THEN %DO;
%LET SORTN = 1;
%LET SORT1 = %QUOTE(DB2);
%END:
Thanks to Cindy Schinker, AgriData Resources, USA.
Change 8.100 Support for WSF 3.3.0 and WSF 3.3.4 SMF records from the
EXWSFACC WSF sysout archive product from RSD. Five data sets are
EXWSFAUD created, WSFACCT, WSFDSN, WSFERD, WSFEVTS, and WSFEVTP,
EXWSFDSN from the account record, and data set WSFAUDIT is built
EXWSFERD from the audit SMF record. The WSFACCT and WSFERD data
EXWSFEVP sets contain the total READ, WRIT, etc counts from all
EXWSFEVS of the DSNB sections, and the WSFDSN data set contains an
IMACWSF observation for each DDNAME/DSNAME accessed. The WSFERD,
TYPEWSF WSFEVTS (Screen) and WSFEVTP (Printer) datasets contain
VMACWSF CPU time for WSF processing, unique for sysout archivers!
Aug 6, 1990 Member IMACWSF identifies which SMF record is which.
Thanks to Victoria A. Lepak, Aetna Casualty and Surety Company, USA.
Change 8.099 A plethora of VM/XA changes were discovered in a search
VMACVMXA of INFO/SYS using KWS A MONITOR RECORD NEW UPDATE; some
Aug 6, 1990 of the documention for these VM/XA changes required the
actual script of the PTF, and the documentation leaves
a lot to be desired. This is especially sad, because the
VM/XA monitor itself was one of the best documented IBM
products in a long time. I guess that's the difference
between development and maintenance in IBM.
1.VM39921 added variable CALBASE to seven VM/XA datasets
(VXSCLADL,VXSCLDDL,VXSCLAEL,VXUSEACT,VXUSEATE,VXUSEITE)
to identify if this is the base VMDBK or adjunct VMDBK.
2.VM39196 added variable CALMODE to four VM/XA datasets
(VXMTRUSR,VXUSELON,VXUSEACT,VXUSEATE) to indicate the
architectural mode (ESA, XA, or 370) of the guest.
3.VM36026 added variable CALIOACT to VXSYTUWT and variable
HFIOACT to datasets VXUSEINT and VXUSEITE to count the
number of times the user has an asynchronous I/O that
was outstanding.
4.VM36104 adds two new VM/XA monitor records, 0.15 (SYTCUG)
and 0.16 (SYTCUP), measuring LPAR (Logical Partition) CPU
allocation (dispatched) duration. MXG builds two new data
sets, VXSYTCUG (per time interval) and VXSYTCUP (per LPAR
per time interval). The new data is identical to that
in the MVS TYPE70PR SMF data record, and reports on the
utilization of ALL of your LPARs on the hardware platform
whether they are executing VM, MVS, or DOS.
Thanks to Tom Healy, ChemNet Processing, USA.
Change 8.098 Support for IMS/ESA 3.1 IMS log processing is now added.
FORMATS While several additional fields were added to the IMS log
TYPEIMS records 07 and 08, because they were added at the end of
VMACIMS the log record, MXG 7.7 will not fail with IMS 3.1 data!
Aug 6, 1990 Several of the new fields are 8-byte time durations that
are not documented as to format in the IMS log DSECTS,
and the test data received to data was only from BMPs
that had zero values for these durations, so there is
still some validation/verification required. The new
data fields that have been added are:
DBCTL DB I/O measures:
DLRIOCNT - DBCTL DB I/O Count.
DLRTMEPL - DBCTL DB Locking Elapsed Time.
DLRTMEIO - DBCTL DB I/O Elapsed Time.
Delays during program scheduling:
DLRMINT - Wait time for Intent Conflict with another
PSB for scheduling.
DLRMPOL - Wait time for Pool Space for scheduling.
DLRMSCH - Elapsed time for Schedule Processing
(which includes both DLRMINT and DLRMPOL).
There is only one 07 record per program schedule, but it
describes NMSGPROC transactions, if multiple transacts
are executed by a single program schedule. As MXG has had
to do before, these new 07/08 fields are divided by the
NMSGPROC value and thus each ultimate transaction record
in TYPEIMS contains the average count/duration of these
new resource measures.
What has not been tested for IMS/ESA 3.1 is the data
compaction introduced (I think by an SPE to IMS) in
MVS 3.1.3. APARs OY19751, OY19854, OY19860, OY19863 are
involved, and IBM manual GC28-1057, MVS/ESA Data
Compression and Expansion Services describe the new
callable macro CSRCESRV which is automatically used by
IMS/ESA 3.1 to compress the OLDS and SLDS (System Log
Data Set, the input to TYPEIMS). I am still researching
if, when, and how the data compression occurs, and would
welcome an IMS/ESA log tape with compression in effect
so that I can figure out how to decompress it in MXG!
Thanks to Hamid Tavakolian, Continuum, USA.
Change 8.097 This circumvention member for the 344 Compiler error had
XMAC73 initialized variable LCI as numeric instead of character.
Aug 6, 1990 Line 014500 should be IF LCI=' ' then LCI=' ';
Only when data from before and after the circumvention is
installed, did this cause a conflict.
Thanks to Richard Evans, Mervyns, USA.
Change 8.096 SAS 6.06 Compatibility. PROC PRINT PAGE option.
ANALESV The PROC PRINT option PAGE no longer exists, and it has
Aug 3, 1990 been removed from this example report.
Thanks to Tom Simons, Matson Navigation, USA.
Change 8.095 SAS 6.06 Compatibility. LIBREF reuse as FILEREF.
MONTHBLD SAS Version 6.06 still does not properly recognize the
Aug 3, 1990 TAPECLOSE=LEAVE or FILECLOSE=LEAVE options when reading
or writing tape format SAS data libraries. Just like 5.18
did, a rewind of each tape library is issued after each
SAS data set is read/written, whereas the LEAVE options
should cause the tape to remain positioned at the end
of the SAS data set just read/written on that tape. The
problem is only that this causes many tape mounts if the
input or output data libraries are multi volumes, and it
causes lots of rewinds (and hence longer elapsed times)
even if only single volume tape libraries are involved.
The problem has been most pronounced in building the
monthly PDB (since that has the highest probability to
be multi-volume). MXG has provided a circumvention in
MONTHBLD for the output tape (ddname MONTH), but changes
in the SAS 6.06 language specifications were made. To
protect users from accidentally overwriting a SAS data
library with a FILE/INFILE statement, SAS 6.06 no longer
allows the same ddname for both a LIBREF and FILEREF at
the same time. The following circumvention is required
in MONTHBLD to free the LIBREF name so it can be reused
as a FILEREF (and, of course, the syntax only works under
SAS 6.06 so that version-dependent macros are required so
that the modified MONTHBLD executes under either 5.18 or
6.06!).
1.Before the second "MACRO _MNTHBLD" definition, insert
these two new compatibility macros:
%MACRO V6COMPEN;
%IF %SUBSTR(&SYSVER,1,1) GE 6 %THEN %DO;
LIBNAME TAPETEMP TAPE ; /*6.06+ TAPE ENGINE*/
%END;
%MEND;
%MACRO V6COMPCL;
%IF %SUBSTR(&SYSVER,1,1) GE 6 %THEN %DO;
LIBNAME TAPETEMP CLEAR; /*6.06+ CLEAR*/
%END;
%MEND;
2.Inside the second "MACRO _MNTHBLD" definition, after the
OPTIONS OBS=MAX; and before the DATA TAPETEMP._DSET;
insert (note double percent sign):
%%V6COMPEN;
3.Inside the second "MACRO _MNTHBLD" definition, after the
IF _BEGIN LE ZDATE LE _END; and before the DATA _NULL_;
insert (note double percent sign):
RUN; %%V6COMPCL; RUN;
Thanks to Bud Porter, City of Birmingham, USA.
Change 8.094 Truncated RMF type 79 SMF records resulted when SMF data
VMAC79 records that were actually LRECL=32760 bytes were dumped
VMAC79 with an incorrect LRECL=32756 specified in the SMF dump
Aug 3, 1990 or copy program. The correct LRECL=32760 must be used.
MXG detected and deleted the defective SMF records, but
did not note on the log this had been done. The type 79
subtype 1 record with 32760 bytes occurs only when there
are 331 or more address spaces active. This change now
reports when bad records have been found and reports that
they were deleted. Insert after line number 017100
(the end of MONITOR II Control SECTION):
L79EXPD=OFFSMF+SMF79ASS-3+SMF79ASL*SMF79ASN-1;
IF SMF79ASS GT 0 AND SMF79ASL GT 0 AND SMF79ASN GT 0
AND L79EXPD GT LENGTH THEN DO;
N79BADAS=1;
IF N79BADAS LT 10 THEN PUT
' EXPECTED ' L79EXPD
' BYTES, BUT LOGICAL DATA IS ONLY ' LENGTH
' BYTES IN RECORD. RECORD DELETED.';
END;
Thanks to Ken Trayes, General Electric Capital, USA.
Change 8.093 The 8.2 PreRelease copy of VMACZRB has now been validated
VMACZRB by the original author of the RMF III processing support,
Aug 3, 1990 who discovered that all X'04' must be changed to $ and
all X'52' must be changed to "not" signs. Guess what MXG
source code went from EBCDIC to ASCII and back to EBCDIC!
To avoid future character set conversion problems, I have
further changed all "not-symbol equal signs" to " NE ".
(In printing this change, which was down loaded from MVS
to PCDOS, the "not-symbols" were converted and printed as
"caret" symbols! Please do not use not-symbols!)
Thanks to Dick Whiting, Precision Castparts, USA.
Change 8.092 STC's 4400 Silo SMF record will contain a new subtype 7
EXSTCHSC for HSC 1.1.0. This change adds support for that new
FORMATS subtype, and creates a new STCHSC data set, with some
VMACSTC 60 new variables. New $MGSTCxx. formats were also
Aug 2, 1990 created to decode several variables.
Change 8.091 Amdahl's MDFTRACK SMF records were not quite right. Six
VMACMDF variables, DOMMIN,DOMTGT,DOMMAX,DOMNORM,DOMATGT,DOMUTIL
Aug 1, 1990 were missing.
1.In lines 011700 thru 012300, where these variables were
INPUTed as ?? PD4.2, they should instead be PIB4.
2.Insert six new lines, after 014200, to convert these six
fields to their screen values:
DOMATGT=FLOOR((((DOMATGT)/GBLELTM)+5)/10); 014210
DOMMAX =FLOOR((((DOMMAX )/GBLELTM)+5)/10); 014220
DOMMIN =FLOOR((((DOMMIN )/GBLELTM)+5)/10); 014230
DOMNORM=FLOOR((((DOMNORM)/GBLELTM)+5)/10); 014240
DOMTGT =FLOOR((((DOMTGT )/GBLELTM)+5)/10); 014250
DOMUTIL=FLOOR((((DOMUTIL)/GBLELTM)+5)/10); 014260
Thanks to Vince Loeffler, Searle, USA.
Thanks to Martin Tavener, Reed Travel Group, ENGLAND.
Thanks to Myron King, The Equitable, USA.
Change 8.090 These extensive validation corrections to ACF2 support
VMACACF2 correct the ARE processing, and clean up several other
Aug 1, 1990 minor bugs. This replaces the temporary fix for the
ARE that was made by Change 8.002, and this fix should
have been in PreRelease 8.2, but got lost temporarily!
1.Lines 010400-010500, remove ACEEMLTH ACEELDNM ACEVLOFF &
ACEFLDVL, as they do not exist.
2.Line 011700, ACLMAMFS should be ACLMAFMS.
3.Lines 032600,032700 change ACTMFTOD to ACSMFTOD.
4.Line 035900, change PIB8. to TODSTAMP8.
5.Lines 037300-037400 can be deleted.
6.Line 046200 can be deleted.
7.Line 016010 inserted after 016000 naming all five of
the ACJ..... variables in ACF2TR.
8.Line 062000 (ACVMFRT PIB1.), insert new line after
containing +1
9.Lines 049100-055900 were completely re-written to
properly decode the ARE segments.
Thanks to J. R. Dravnieks, Ladbroke Computer Services, NETHERLANDS.
Change 8.089 Obscure. Using the FREQ= options of VMXGSUM can result in
VMXGSUM erroneous counts if all variables in the MIN=,MAX=,MEAN=,
Jul 31, 1990 or SUM= macro arguments contain missing values.
Replace three lines 034900-035100 (now reading):
%IF %LENGTH(&FREQ) NE 0 %THEN %DO;
N=&FREQ
%END;
with these two lines:
NMISS = MXGNMISS
N = MXGMISS
Change line 035300 to read:
DATA &OUTDATA (DROP=MXGMISS MXGNMISS);
Insert the following after line 035600:
%IF %LENGTH(&FREQ) NE 0 %THEN %DO;
&FREQ = SUM(MXGMISS,MXGNMISS);
%END
Change 8.088 Early alpha tests of a new DB2 monitor created an SMF 100
VMACDB2 subtype 1 data record with a subtype field of zero, which
Jul 30, 1990 caused MXG to STOPOVER abend. Although the real cause of
the error was a bad record (that was immediately fixed),
this change was added to enhance MXG to be more robust
and to avoid the STOPOVER even in the face of bad data!
It's unlikely you will need to install this insurance:
1.Line 086200 should be LENQLST PIB2. vice OFFQLST PIB2.
2.After line 088700 ( IF QWHSLEN GE 52 THEN ...), insert:
IF QWHSNSDA LT 13 THEN OFFRSV3=.; 088710
IF QWHSNSDA LT 12 THEN OFFQJST=.; 088720
IF QWHSNSDA LT 11 THEN OFFQLST=.; 088730
IF QWHSNSDA LT 10 THEN OFFQSST=.; 088740
IF QWHSNSDA LT 9 THEN OFFQVAS=.; 088750
IF QWHSNSDA LT 8 THEN OFFQVLS=.; 088760
IF QWHSNSDA LT 7 THEN OFFQWSD=.; 088770
IF QWHSNSDA LT 6 THEN OFFQ9ST=.; 088780
IF QWHSNSDA LT 5 THEN OFFQ3ST=.; 088790
IF QWHSNSDA LT 4 THEN OFFQWSC=.; 088791
IF QWHSNSDA LT 3 THEN OFFQWSB=.; 088792
IF QWHSNSDA LT 2 THEN OFFQWSA=.; 088793
3.After line 125400 ( IF QWHSLEN GE 52 THEN ...), insert:
IF QWHSNSDA LT 7 THEN OFFEDM =.; 124510
IF QWHSNSDA LT 6 THEN OFFQTXA=.; 124520
IF QWHSNSDA LT 5 THEN OFFQIST=.; 124530
IF QWHSNSDA LT 4 THEN OFFQBST=.; 124540
IF QWHSNSDA LT 3 THEN OFFQTST=.; 124550
IF QWHSNSDA LT 2 THEN OFFQXST=.; 124560
4.After line 165700 ( IF QWHSLEN GE 52 THEN ...), insert:
IF QWHSNSDA LT 6 THEN OFFR5 =.; 165710
IF QWHSNSDA LT 5 THEN OFFQTXA=.; 165720
IF QWHSNSDA LT 4 THEN OFFQBAC=.; 165730
IF QWHSNSDA LT 3 THEN OFFQXST=.; 165740
IF QWHSNSDA LT 2 THEN OFFQWAC=.; 165750
Thanks to Benny Maynard, BiLo, Inc, USA.
==============Changes thru 8.087 comprised MXG PreRelease 8.2===========
Change 8.087 Lines 046800 thru 047100 should have denominator TRANSNO
VMACNSPY instead of TOTRSPNO for calculation of T1RSPPC-T4RSPPC.
Jul 20, 1990 If this DO group was entered (not likely), missing values
were calculated because TOTRSPNO was missing. This only
affected the NSPYLU data set values.
Thanks to Marty Quinlan, Virginia Power, USA.
Change 8.086 PreRelease validation identified many datasets which did
Many not have ZDATE, some $MG.. formatted variables that were
Jul 20, 1990 length 8, some DATETIME variables that were not length 8,
and many variables with no label. Uninitialized variable
messages were also detected and corrected, and the TREND
data base code was added to the MXG Validation/Cross
reference testing.
Change 8.085 This JCL member contains IDCAMS control statements and
JCLVSAM JCL to build a VSAM ESDS data set that is needed only for
Jul 20, 1990 MXG testing of RMF III (VMACZRB) code.
Thanks to Jeannie Hopf, Hopf Consulting, USA.
Change 8.084 This is a significant internal revision to DB2 reporting
ANALDB2R from SMF trace data. Previously, you had to update/edit
Jul 20, 1990 member IMAC102 to tell MXG what trace classes had been
enabled. If you did not update IMAC102 correctly, MXG
would create zero observations in T102Snnn datasets, even
though there were SMF records for IFCIC nnn in your SMF
file. Now, when you specify PDB=SMF in ANALDB2R, the
program is smart enough to know which datasets are needed
and ANALDB2R no longer uses IMAC102 to control T102S...
datasets. (Note: IMAC102 is still needed if you use the
TYPE102/VMAC102/BUILDPDB method of processing DB2 trace
type 102 records; this change applies only to ANALDB2R,
and only when PDB=SMF is specified to read SMF data.)
Additionally, macro variables corresponding to macro
names constructed by IMAC102 were added to ANALDB2R to
allow you to select specific trace class(s), using the
syntax of DB2TC1=YES as the argument when you invoke the
%ANALDB2R report macro. Documentation (comments in the
member itself) was added to describe the new parameters,
and also to list which trace classes must be enabled for
each report group. The member was renumberd.
Change 8.083 Dataset VXIODDEV variables AVGPNDMS,AVGDISMS,AVGCONMS are
VMACVMXA incorrect (but this should not affect most users, as this
Jul 20, 1990 detail dataset is not typically used; instead VXDEVTOT
and VXSUMIOD are used and their values were correct). But
now, even these variables are always correct.
Dataset VXPRCPRP variable HFUSERZ is now formatted 5.1
and multiplied by 100, as it is a percentage, not a rate.
Thanks to Dick Whiting, Precision Castparts, USA.
Change 8.082 Support for APAR OY32638 which (finally!!) adds PROCSTEP
IMAC30 to the type 30 record datasets, and to the PDB.STEPS data
VMAC30 set in your PDB. This procedure stepname has been wanted
Jul 20, 1990 since OS/360. However, what is still wanted and still not
provided in any SMF record is the actual name of the JCL
procedure that was executed by the user on the EXEC card!
Change 8.081 Support for APAR OY25606/OY33312, which (incompatibly)
VMAC30 added a new 4-byte field (SMF30EOS) to replace the 2-byte
Jul 14, 1990 existing SMF30EOR. Without this change, MXG variable
EXTRADD will contain a value of 61682, but as that is
not actually used by MXG, the incompatibility is one of
principle rather than one of fact. The EXTRADD field had
to be expanded from half-word to full-word to keep count
of the number of extra DD segments in additional SMF
type 30 records that can be written if the new DDCONS(NO)
option is specified. See extensive discussion in IBM's
Washington Systems Center Flash Number 9027, and further
notes in the next MXG newsletter. Inserted to correct:
IF OFFPROD-3-COL GE 6 THEN INPUT @105 EXTRADD PIB4. @;
Thanks to George Scott, Rockwell International Corporation, USA.
Change 8.080 Support for ORACLE SMF Record. The data set ORACLE is
ANALORAC built from the SMF record ID specified in IMACORAC
EXORACLE (which should be copied into your USERID.SOURCLIB and
IMACORAC changed therein). A set of sample reports are also in
TYPEORAC ANALORAC. This user contribution was reformatted and
VMACORAC has been tested with a small sample of ORACLE data.
Jul 7, 1990
Thanks to David Henley, Signet Bank/BISYS, USA.
Change 8.079 Significant validation of RMF III VSAM records is in this
VMACZRB user enhancement. In addition to corrections in VMACZRB,
VMACZRB0 new members ZRBCHECK will check the integrity of these
ZRBCHECK datasets produced by VMACZRB, and member ZRBMXIDX now
ZRBDLYBT summarizes and builds an index for the datasets that are
ZRBMKIDX built from VMACZRB, and member ZRBDLYBT reads the index
Jul 7, 1990 and summarized datasets to produce delay reasons for
batch jobs. VMACZRB0 is a backup of previous VMACZRB.
Thanks to Roland Rashleigh-Berry, National Westminster Bank, ENGLAND.
=========Changes thru 8.078 were printed in Newsleter SEVENTEEN=========
Change 8.078 SAS 6.06 Compatibility. Comma after last argument.
TRNDJOBS An extraneous comma after line 002900 works under 5.18
Jul 4, 1990 but is flagged as an error under 6.06. This comma is
after the last macro argument, immediately preceding the
close parenthesis, and was not required, so its gone.
Thanks to M. Cambier, Credit Lyonnais, FRANCE.
Change 8.077 The variable ACCESS should have been created in the exit
ANALDSET for TYPE64, but was not. Insert new line after 007300
Jul 4, 1990 setting ACCESS='VSAM';
Thanks to John R. Grout, Midlantic National Bank, USA.
Change 8.076 Further validation of Trending uncovered incorrect code
ASUMCICS in these ASUM.... members (that take detail data like
ASUMJOBS CICS transactions, JOBs, etc. and summarize in groups).
ASUMTMNT 1.Response buckets in ASUMCICS were off by one bucket. In
Jul 4, 1990 lines 009900 thru 010500 change LE to LT, and in line
010700 change RESPMAX=RESP to RESPMAX=IRESPTM.
2.Similarly, in ASUMJOBS change lines 003600 thru 004200
from LE to LT.
3.Similarly, in ASUMTMNT change lines 002400 thru 003000
from LE to LT.
Thanks to Jim Hinkel, Weyerhaeuser Company, USA.
Change 8.075 The VTOC processing code did not capture free space that
VMXGVTOC is located at the very beginning of the volume. This
Jul 4, 1990 change added about 30 lines to recognize that situation.
Thanks to Uriel Carrasquilla, Vancouver Stock Exchange, CANADA.
Change 8.074 Preliminary support for IBM System Managed Storage (SMS)
EXDCOCLU utility program DCOLLECT, that creates a flat file of
EXDCODSN Data Set, Cluster, and Volume information from SMS. This
EXDCOVOL significant user contribution creates three MXG datasets,
IMACDCOL DCOLCLUS, DCOLDSET, and DCOLVOLS from DCOLLECT output.
TYPEDCOL Not all of the variables have been decoded, and the code
VMACDCOL may be enhanced in the future with decoding formats.
Jul 4, 1990
Thanks to Tom Skasa, General Electric Medical Systems, USA.
Change 8.073 Considerable validation of the VVDS record created by MXG
VMACVVDS member ASMVVDS and processed by VMACVVDS has uncovered
Jun 28, 1990 several errors and additional variables are created.
1.Variables VVRCATSD VVRCOMTP VVRKRQ VVRSELFD VVRSPCFG
VVRSPCOP and VVRSSDAT should be added to the KEEP list.
2.These seven new variable's labels should be added:
VVRCATSD = 'SELF-DESCRIBING*VVR FOR*CATALOG'
VVRCOMTP = 'COMPONENT*TYPE'
VVRKRQ = 'KEY*RANGE*QUALIFIER'
VVRSELFD = 'SELF-DESCRIBING*VVR FOR*VVDS'
VVRSPCFG = 'SPACE*FLAGS'
VVRSPCOP = 'SPACE*OPTIONS'
VVRSSDAT = 'SEQUENCE*SET*WITH DATA'
3.Add variables VVRALTSP VVRAMSTS and VVRTMSTP length 8 to
the LENGTH statement at line 012900.
4.Add variables VVRALSTP VVRAMSTS and VVRTMSTP to the
FORMAT statement at line 014300 with DATETIME21.2;
5.After line 016500 (before the END; before 'D8'X), insert
IF VVRFLAG='.1......'B THEN VVRSELFD='Y';
IF VVRFLAG='..1.....'B THEN VVRCATSD='Y';
IF VVRFLAG='....0...'B THEN VVRCOMTP='D'; /* DATA */
ELSE VVRCOMTP='I'; /* INDEX */
6.Change SMFSTAMP8. in 024100, 024200 and 029100 to
TODSTAMP8.
7.Change test '....1...'B for VVRA1IUP in line 024900 to
instead test '.....1..'B.
8.After line 026000 (after IF VVRAIXFG ...), insert
IF VVRSPCFG='11......'B THEN VVRSPCOP='CYL';
ELSE VVRSPCOP='TRK';
9.In lines 030600 thru 031200 the test for VVRDSATR should
instead test VVRAMATR.
10.Change all " IB" to " PIB" (binary numbers should be
PIBn. rather than IBn. to prevent unexpected negatives.)
Thanks to Tuanhung Doanvo, Philip Morris, USA.
Change 8.072 SAS 6.06 Compatibility. ID statement different.
TRNDRMFI To avoid a very obscure exposure if SU_SEC was missing,
Jul 3, 1990 the order is now ID = NRCPUS PARTNCPU SU_SEC STARTIME,
Change 8.071 SAS 6.06 Compatibility. AUTOCALL fails.
ANALDB2R The first line of an AUTOCALLd macro cannot be non-blank
VXMGGOPT in column 72 of the first line of the member, until SAS
VMXGHSM ZAP Z6060946 exists.
VMXGINIT
VMXGVTOR
Jun 29, 1990
Change 8.070 The MXG 7.7 Tape Mount Monitor (in ASMTMNT) does work on
ASMTMNT MVS/ESA as well as MVS/XA (and, also for MVS/370!). The
Jun 29, 1990 comment in that member is wrong; the code had been tested
under MVS/ESA last year. The argument yy of SYPARM(xx,yy)
value of SP builds the MVS/370 monitor, using XA for yy
creates a monitor that works on either MVS/XA or MVS/ESA.
This change only changed the comments, not any real code.
Change 8.069 BUILDPDB/3 has been enhanced in several ways.
BUILDPDB 1.The contents of the SPIN library are now copied into the
BUILDPD3 PDB library at the end of BUILDPDB/3 processing. This is
Jul 3, 1990 both for Backup/Recovery and for possible analysis.
Should you ever need to back up and recover your PDB jobs
you would simply go back to the last successful PDB, and
copy (PROC COPY IN=PDB OUT=SPIN; SELECT SPIN:;) the SPIN
data sets from that PDB into your SPIN library, and then
re-process the input SMF data.
In addition, by inclusion of the SPIN data sets in your
PDB, jobs which executed yesterday but have not yet
purged will be available in the SPIN30_5 (and their steps
in the SPIN30_4) data set for timely reporting.
2.Job accounting variables ACCOUNTn and SHIFT were added to
the PDB.SMFINTRV data set. SHIFT is defined by your shift
definition in IMACSHFT, applied to the interval INTBTIME
begin time stamp. This would allow shift by shift charging
for your long running jobs, but if you do so, you must be
careful to not double charge between the PDB.SMFINTRV and
the duplicate data in PDB.JOBS and/or PDB.STEPS.
The BUILDPDB logic was slightly altered by this change.
Previously, the PDB.SMFINTRV data set was built by sort
of the TYPE30_V before the EXPDBSPN exit. Now, the logic
is relocated to after all EXPDB... exits, just before
the SPIN library is updated. Completed jobs (PDB.JOBS)
and incomplete jobs (SPIN30_1) are now merged with the
type 30 interval records and output in PDB.SMFINTRV.
Unless you used exit EXPDBSPN and expected PDB.SMFINTRV
to exist in that exit, there is no compatibility issue.
you have used EXPDBSPN
3.TYPE25 data set (JES3 Main Device Scheduled) is now added
automatically to the JES 3 PDB built by BUILDPD3.
Change 8.068 SAS 6.06 Options are controlled by the DDNAME of CONFIG
CONFIG in the SAS606 procedure. The MXG library now contains
Jun 28, 1990 the CONFIG member, which has been used in all of MXG's
testing discussed in Newsletter SEVENTEEN. It may change
as more is discovered in testing SAS 6.06, but it is here
so that you will know what options we had changed from
SAS's defaults. You may find a separate CONFIGTSO member
useful to specify NODMS, NOCENTER, etc., because SAS 6.06
does not automatically recognize the TSO environment. In
the production version 8 there will likely be multiple
CONFIG... members.
* INITIAL RECOMMENDATION FOR CONFIG OPTIONS FOR SAS 6.06.01 IN BATCH
* THESE ARE SUBJECT TO CHANGE AS WE LEARN MORE ABOUT 6.06.
* YOU CANNOT USE /* */ DELIMITER FOR COMMENTS IN CONFIG MEMBER
NOIMPLMAC
MAUTOSOURCE
SASAUTOS=SOURCLIB
FULLSTATS
STIMER
SORTDEV=3380
BUFNO=3
MEMSIZE=12M
PROCLEAVE=100K
SYSLEAVE=100K
VMCTLISA=40K
VMPAISA=256K
VMPAOSA=128K
VMPBISA=512K
VMPBOSA=128K
PSUP=SASXKERN
SORT31PL
SYSIN=SYSIN
Change 8.067 ANALDB2R reporting was slightly different than IBM DB2PM.
ANALDB2R 1.The Accounting Detail showed average instead of total for
Jul 3, 1990 Class 3 System Events. Moved variables QWACARNA,QWACARNE
from MEAN= at line 015240 to the SUM= at line 015330.
2.The ELAPSED time on the MXG report was the ending minus
starting time, instead of the sum of the plan execution
durations. Deleted lines 109400-109430 and 117940-117970
DURATM
%IF .......
%ELSE ....
;
in both places.
3.Selection criteria in MXG reports incorrectly used ending
time stamp instead of start time, causing MXG to report a
different set of intervals than DB2PM. Change to read:
line 006590 and 015850 IF "&BEGTIME"DT LT QWACESC;
line 006620 and 015880 IF "&ENDTIME"DT GT QWACBSC;
line 084930 and 110050 IF "&BEGTIME"DT LT QWHSSTCK;
line 084950 and 110080 IF "&ENDTIME"DT GT STRTTIME;
Thanks to Piara Singh, Ministry of Health, SINGAPORE.
Change 8.066 This change supports the new "SRCL" field added to RMF
VMAC7072 product section by APAR OY28449 and PTF UY49092. The
VMAC71 text of the PTF claims that
VMAC73 "the APAR will not impact the customer unless they
VMAC74 have private programs that process RMF - SMF records.
VMAC75 The customer will have to modify their programs/execs
VMAC76 to include the new SRCL field..."
VMAC77 but there is NO impact on MXG 7.7. The new field was
VMAC78 already a reserved field in the RMF product section, and
VMAC79 its value is currently always zero. This change uniformly
XMAC7072 renames the reserved field @OFFRMFP+51 as RMFSRCL, but
XMAC71 only for possible future use when IBM actually puts a
XMAC73 non-zero value in the field (which is suposed to be an
XMAC74 indicator of the RMF source level that created the RMF
XMAC75 record).
Jul 2, 1990
Change 8.065 This announces support for CICS/ESA Releases thru 3.1.1
EXCIC... Monitor and Performance data. Forty seven MXG datasets
FORMATS are created from the new Statistics class data, and new
IBCICTRN variables were added to CICSTRAN and CICSEXCE. Two data
PRCICALL sets no longer exist in CICS/ESA: CICSACCT was always
UTILCICS redundant with CICSTRAN, and CICSYSTM's interval data is
VMAC110 now contained in (and significantly enhanced) in the 47
VMAC110B new CIC..... CICS statistics datasets. See the technical
VMAC110M note in MXG Newsletter SEVENTEEN documenting changes.
Jun 30, 1990 a.The new member VMAC110 contains support for all CICS data
(1.5,1.6,1.6.1,1.7,2.1,3.1.0, and 3.1.1) concurrently.
b.Member VMAC110B is the backup copy of VMAC110 before the
3.1.1 changes. It will not exist in the next prerelease.
c.VMAC110M processes only subtype 1 records for CICS/ESA
and previous CICS's; it does not process new Statistics
structure, but does know about new fields in the CICS
dictionary in 3.1.1. It may be needed to avoid a SAS 344
Compiler Limit exceeded error under SAS 5.18 for sites
that do not have SAS 6.06 available.
d.FORMATS member on MXG 8.2 contains new CICS formats.
e.IBCICTRN labels all CICSTRAN variables with the CMODHEAD
name from the dictionary. Then, you can
PROC PRINT DATA=CICSTRAN SPLIT='*';
%INCLUDE SOURCLIB(IBCICTRN);
to print the CICSTRAN monitor data with IBM headings.
Useful when you need to talk to IBM about their data!
f.PRCICALL will print (with or without SPLIT='*') all 47
new CIC.... data sets and the pre-existing four as well.
The OBS= parameter limits print to first 300 obs, but
even that can be lots of paper.
g.UTILCICS knows about the CICS/ESA dictionary, but has not
yet been updated for connectors, as there has been no
need thus far for that enhancement.
h.See NEWSLETTER SEVENTEEN for initial documentation.
Change 8.064 Boole and Babbage's IMS Measurement Facility (IMF/CIMS)
VMACCIMS product Release 2.6 supports IMS 3.1 with no changes in
Jun 24, 1990 the IMF data records written to the IMS log, so therefore
MXG now (and before) supports IMS 3.1 IMF records!
Change 8.063 SAS 6.06 Compatibility. SAS/STAT existence and ID.
GRAFTRND Added SASSTAT option to indicate you have SAS/STAT.
Jul 3, 1990 Added error message if SU_SEC (used to normalize CPU in
plots) is missing. Default device changed to PCBATCH.
Code was consolidated, enhanced and renumbered.
Thanks to Bruce L. Green, Medical Information Bureau, USA.
Change 8.062 SAS 6.06 Compatibility. PROC MEANS vs SUMMARY.
ANALBNCH Each PROC MEANS NOPRINT execution with an OUT= option
ANALBNC1 was located and (DROP=_FREQ_ _TYPE_) was added after the
ANALCACH output data set name in the OUT= option, so that these
ANALCICS variables (created because 6.06 PROC MEANS now actually
ANALDB2R is PROC SUMMARY) are not kept. At the same time, all
ANALDMON PROC MEANS statements were re-ordered so that the NOPRINT
ANALDOS option immediately follows the MEANS, for consistency.
ANALESV
ANALMNTS
ANALMONI
ANALMPL
ANALNPMR
ANALPROG
ANALSMF
ANALTAPE
ANALTURN
BUILDPDB
BUILDPD3
IDMSREPT
IMACPDB
RMFINTRV
VMACCRAY
VMACVMON
VMACVMXA
VMXGHSM
VMXGSUM
VMXGVTOC
XPAII
Jul 3, 1990
Change 8.061 SAS 6.06 Compatibility. PROC COPY GCAT change.
GRAFRMFI Replaced use of PROC COPY with the COPY command of PROC
Jul 3, 1990 GREPLAY. Deleted GROUPing logic if executed under SAS
6.06. Changed default device to PCBATCH.
Change 8.060 SAS 6.06 Compatibility. DROP= validation.
VMACVMON Remove MN002RS1,MN002RS2,MN003RSV from DROP= option in
Jun 14, 1990 line 361600. Remove INTERVAL from DROP=option in lines
361800, 362000, 362200, 362400, and 362600.
Change 8.059 SAS 6.06 Compatibility. Parser error. PROC SORT
ANALCICS DATA=_CICTRAN. CICSTRAN fails with a 201 error, but it
Jun 14, 1990 accepts _CICTRAN.CICSTRAN or _CICTRAN . CICSTRAN syntax.
SAS 5.18 didn't care about blanks before or after the
delimiter period in a full data set name.
Will not be repaired until SAS 6.07.
Thanks to Dennis Longnecker, Admin. for the Courts, WA. State, USA.
Change 8.058 This TREND example needed a PROC SORT; BY SYSTEM PERFGRP;
JCLTREND to be inserted before line 005900 (PROC PLOT) to avoid a
Jun 14, 1990 non-sorted condition.
Thanks to Tom Elbert, John Alden Life Insurance, USA.
Change 8.057 Invalid type 6 SMF records can cause an MXG STOPOVER. In
VMAC6 most cases, the record is created by an external writer
May 9, 1990 that lies (by storing subsys of 2 instead of 0, making me
believe this is a JES-written record), but it can also be
caused by an IBM-written record with incorrect data.
This change adds an additional test to detect the invalid
record and avoids the STOPOVER. Replace the three lines
that test SECTIND (lines 022500, 025400 and 028800) with:
IF SECTIND='1.......'B AND OFTONXT+35 LE LENGTH THEN DO;
IF SECTIND='.1......'B AND OFTONXT+ 5 LE LENGTH THEN DO;
IF SECTIND='..1.....'B AND OFTONXT+46 LE LENGTH THEN DO;
Even these tests are not sufficient when a SMF6LN3 value
says 162 bytes exist, but the record is truncated, as is
found in MVS 3.1.3. For this case, an additonal test was
added to line 027100 which now reads
IF SMF6LN3 GE 162 AND LENGTH-COL+1 GE 124 THEN
Finally, all other conditional input statement are now
protected similar to line 027100 to test both the LENGTH
minus COL plus one, against the data to be inputted.
These MXG circumventions for the defective IBM type 6
record are not necessary if you instead install the APAR
OY29986 PTF UY49159 for JES 2 3.1.3 causing the error.
Thanks to Mark Stafford, PHH Fleet America, USA.
Thanks to Diane McCabe, N.J. Dept. of Treasury/OTIS, USA.
Thanks to Leatha Harlow, Sperry Marine, Inc, USA.
Change 8.056 SYNCSORT SMF record for sorts using E15/E35 exits ahve a
VMACSYNC value of hex 00 for SIRECFM, SORECFM, causing an "INVALID
May 8, 1990 DATA" message and a dump of the input record. Inserting a
double questionmark (SIRECFM ?? 1. and SORECFM ?? 1.) the
invalid data message goes away.
Thanks to Dave Greene, Kwasha Lipton, USA.
Change 8.055 RMF Type 79 data validation continues. Formats have been
VMAC79 assigned: R791DP HEX4., R791TRTM and R796TOD TIME12.2,
May 8, 1990 and R794AFC MGBYTES. INPUT statements were corrected:
May 9, 1990 R791TRTM PIB4.3 and R792TDEV PIB4.6. Line 051300 (4096*
R793LOUT) was deleted and removed from MGBYTES format,
new lines added 040610 R792TDEV=128*R792TDEV; and added
060110 R794AFC=4096*R794AFC;to correct units. A number
of other fields which contain memory(pages/frames,etc)
measures were inconsistent. They were either not mult.
by 4096, not Formatted MGBYTES, or did not have (MB) in
their label to indicate they are in units of K,M, etc.
They are all now consistent, and they include:
792: FXBL, PNV, PSWP, PVIO CMNI PIN
794: CMNI CMNO CSAI ERTE HSP LPAI MRTE PRVI PRVO PSPI
PSPO and VIO
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 8.054 RMF Monitor III VSAM dataset records cause STOPOVER with
VMACZRB RMF 4.1.1. Since MXG 7.7 supporte RMF 3.4.1, it is not
May 7, 1990 surprising that the lengths in the RELINFO: table needed
to be changed. However, actual data record lengths do not
agree with IBM documentation, and occasional STOPOVERs
still occur (possibly because these records can span a
physical record). Further research and validation will
be done at a later date, but it appears the code can be
used if STOPOVER in line 000200 is changed to MISSOVER,
and try these values following the label RELINFO:
ASISIZE = 120 (IBM document said 114, MXG 7.7 was 88)
GEISIZE = 132 (IBM document agrees, MXG 7.7 was 96)
SSHSIZ = 264 (IBM document said 260, MXG 7.7 was 240)
Thanks to Jim Stebel, Royal Insurance, USA.
Thanks to Richard Evans, Mervyn's, USA.
Change 8.053 SAS 6.06 Compatibility. A RUN; statement was added
GRAFRMFI before each PROC GREPLAY to isolate potential problems,
May 7, 1990 the test for Version EQ 5 was changed to GE 5.
Change 8.052 Type 37 processing directly from VSAM SMF records was
VMAC37 not complete. In lines 017400, 019100, 021300, 022700,
May 7, 1990 024800, 025700, 028100 and 032000 add +OFFSMF after -3.
Thanks to Herr Lehmann, GRZ Norddeutschland, GERMANY.
Thanks to Herr Kumellis, GRZ Norddeutschland, GERMANY.
Change 8.051 Line 008200 should be spelled CPUOVHTM vice CPUOHVTM,
GRAFTRND and GOUT=TREND.GRAPHS should be GOUT=&TREND..GRAPHS in
May 7, 1990 all five places to be consistent with other references.
Thanks to Norbert Korsche, OMV-AG, AUSTRIA.
Change 8.050 TSO/MON now supports TSO measurement of Batch execution,
VMACTSOM and thus JOB $CHAR7. in line 068700 should be changed to
May 7, 1990 JOB $CHAR8. TSO Userid's were restricted to seven chars,
but batch jobs can be all eight positions. Minor.
Change 8.049 Documentation note. Data set TYPE78CF will contain an
VMAC73 observation only if a CHPID is online (because NRCUS must
VMAC78 be non-zero), but the TYPE73 dataset will contain an obs
May 7, 1990 for each CHPID in the record, whether online or not. Why
the difference? They were written at different times!
To be consistent, I should externalize both tests to the
exit members and consistenly keep only those CHPIDS that
are online (to minimize the unnecessary data in your PDB)
but for now I will leave it the way it is.
Thanks to Laurie Maser, Central Illinois Light Company, USA.
Change 8.048 Variables ABNDRSNC DIVRREAD DSSIZHWM and TERMNAME were
IMACPDB not kept in PDB.STEPS from TYPE30_4, but now were added
VMAC30 in macro _PDB30_4 in member IMACPDB, so they are. Also,
May 7, 1990 variable DSSIZHWM was added to the KEEP list for dataset
TYPE30_V (and thus also will be in PDB.SMFINTRV)
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 8.047 ACF2 dataset ACF2JR will have fewer observations with
EXACFJR MXG 7.7 than it contained with MXG 6.6, because a test
May 4, 1990 in EXACFJR inadvertently deleted SMF records. Remove
the temporary fix "IF ACLEMLTH LT 256;" statement and
its associated comment.
Thanks to Ilana Towery, Houston General Insurance Company, USA.
Change 8.046 Pre-release 8.1 shipped to support ESP product.
May 4, 1990
Change 8.045 MXG's algorithm to detect the wrap of the 202-day clock
VMACVMON in VM/SP failed at 24APR90:08:22:10. MXG's next timestamp
May 4, 1990 was 02OCT89:17:40:04, and the rest of the records in that
VM Monitor file had the Oct 2, 1989 date, because 16* was
left out of line 029400 when Change 6.023 was installed.
The test for new interval in line 029400 should read:
IF LASTHALF AND 16*MNHTOD LT FFFFFOV2 THEN DO;
The incorrect STARTIMEs only occurred on the day of the
clock wrap; the next MXG run (or a monitor start event)
corrected the MXG error.
Thanks to Nancy Ayers, General Electric Lighting, USA.
Change 8.044 Preliminary support for the Cray supercomputer COS 1.16
EXCRA... operating system accounting and performance records. This
VMACCRAY support requires SAS Version 6.06+ (because of ASCII
May 3, 1990 character variables). Future revisions will support the
COS 1.17 changes, and eventually, UNICOS as well. There
are 6 CRAYA... datasets built from account records,
16 CRAYP... datasets built from SPM performance records,
and the MXG-built CRAYPINT "Interval Performance" dataset
built by sum/merging those 16 SPF datasets.
These datasets are currently built:
CRAYAEJ Label='Accounting Job Termination'
CRAYAET Label='Accounting Task Termination'
CRAYAFU Label='Accounting BMR Device Utilization'
CRAYAGU Label='Accounting Generic Resource'
CRAYAPD Label='Accounting Permanent Data'
CRAYATA Label='Accounting Tape Data'
CRAYPCP Label='SPM CPU Times and Task Times'
CRAYPTK Label='SPM Task Requests'
CRAYPER Label='SPM Executive Requests'
CRAYPMU Label='SPM Memory Utilization'
CRAYPDU Label='SPM Disk Utilization'
CRAYPDC Label='SPM Disk Channel'
CRAYPLU Label='SPM Link Utilization'
CRAYPEC Label='SPM Executive Calls'
CRAYPUC Label='SPM User Calls'
CRAYPPU Label='SPM Preemptable Generic Resources'
CRAYP11 Label='SPM JSH Statistics'
CRAYP12 Label='SPM Job Class Information'
CRAYP13 Label='SPM JSH Request Count'
CRAYPIC Label='SPM Channel Interrupts'
CRAYPSB Label='SPM System Buffer Utilization'
CRAYPINT Label='SPM Interval Performance'
Change 8.043 NETSPY Version 3.1 (3.2 is current) can cause a STOPOVER
VMACNSPY because the test in line 032300 should be NSPYENTL GE 177
Apr 30, 1990 (the current test was NSPYENTL GE 167).
Thanks to David B. Adams, National Life of Vermont, USA.
Change 8.042 IMS log processing variable VTAMNODE should be added to
VMACIMS the IMS03 and IMS36 dataset KEEP list and removed from
Apr 30, 1990 the IMS01M dataset KEEP list. The two occurrences of
IF VTAMNODE GE ' ' ... should be changed to now test for
IF VTAMNODE NE ' ' ....
Thanks to Pete Shepard, Ashland Oil, USA.
Change 8.041 EXPLORE/VM second occurrence of CHANBUSY in the LABEL and
VMACVMXP INPUT statements (lines 054000 and 056600) should be
Apr 30, 1990 changed to CHANBUS2 and variable CHANBUS2 should be added
to the KEEP list (line 005700). CHANBUSY is the IPL-proc
Channel Busy and CHANBUS2 is the non-IPL-proc chan busy.
Thanks to Pete Shepard, Ashland Oil, USA.
Change 8.040 MXG 7.7 can have 0 observations in CICS datasets built
VMAC110 from CICS 1.7 records. An anticipatory change was added
Apr 30, 1990 that used a reserved field, but the field is not always
Jun 30, 1990 zero in 1.7 (but it seems okay in CICS 2.1). Either
delete line 025320 (IF SUBTYPE NE 0 THEN DELETE;) for the
present, or if you have both CICS 1.7/2.1 records and
are also testing CICS/ESA 3.1.1, change the logic to:
INPUT @31+OFFSMF OLDVERCI $CHAR2. @19+OFFSMF SUBTYPE PIB2. @;
IF '02' LE OLDVERCI LE '03' THEN SUBTYPE=0;
IF SUBTYPE NE 0 THEN DELETE;
This is a safe test, since the OLDVERCI field in CICS 3.1.1
is the SMFPSNPS (number of product sections, always '0001'X),
and OLDVERCI in CICS 2.1 and earlier will be 'F0F2'X or
'F0F3'X.
Thanks to David Ayresman, University of Louisville, USA.
Thanks to Hunter Chang, Sydney County Council, AUSTRALIA.
Change 8.039 TYPE6156 variable VOLSERs are wrong when additional
VMAC6156 "GOOVOO" entries follow the GOOVOO for this Entry. The
Apr 30, 1990 logic to update VOLSER in MXG was incomplete in this
instance.
a.Add DO; after the THEN which ends statement 019600.
b.MOVE lines 019600-019700 to after 020600 (the @;).
c.Insert new line 021610 (after 021600, END;) containing
END; (to complete the new DO; added above).
Thanks to Tim Kearney, Allied-Signal, Inc, USA.
Change 8.038 NPM records can be created under VM and processed by MXG
NPM with these changes (mostly to VM:)
Apr 23, 1990 a.In FNMINIT FNMPARM A in the NPM MACRO the session
parameter was modified to read session=(session,NPMLOG),
i.e., to write session data to the NPMLOG as well as the
session log.
b.In NPMSTRT GCS A the FILEDEF for FMNLOG1 and FMNLOG2 was
modified to read FILEDEF FNMLOG1 DISK FNMLOG1 LOG A4
FILEDEF FNMLOG2 DISK FNMLOG2 LOG A4
c.To process the log the FNMLOG1 or FNMLOG2 was copied to
a file with a FILEMODE of A1 which was then used as the
input for MXG. The FILEDEF for the input file was also
specified with FILEMODE A1.
d.VMACSMF was copied and modified to create a new macro
named _SMF, which is a copy of the _SMF macro, but which
deleted the VBS and LRECL options on the INFILE statement
in the modified copy.
Thanks to W. C. Cronje, Anglo American Corporation, SOUTH AFRICA.
Change 8.037 VM/370 variable MN000PPC can be zero if preferred paging
VMACVMON is to expanded storage, causing a divide by zero error
Apr 23, 1990 in calculation of DRUMUTIL variable in line 116600. That
calculation is now precedeed by IF MN000PPC GT 0 THEN.
Format MGVM6TY has new value 2420X='2420:3380' added.
Thanks to Gary Zolweg, National Semiconductor, USA.
Change 8.036 Variable CREATIME in dataset MONITASK has date of END if
TYPEMONI a transaction spans midnight. Logic to correct date was
Apr 23, 1990 perturbed by Change 7.171. To correct, change line 00503
to read IF CREATIME LE TIMEPART(ENDTIME) THEN instead of
IF CREATIME LE ENDTIME THEN.
Thanks to Steve Cavill, SAS Institute, AUSTRALIA.
Change 8.035 This one is obscure. CICS type 110 records with a error
VMAC110 are usually detected by MXG and STOPOVER prevented, but
Apr 18, 1990 if the invalid segment happens to be the last segment in
a type 110 record, a STOPOVER can still result, because
line 032200 (CONNBYTE+DRLENNUM GT BYTELEFT AND ...)
should be CONNBYTE+DRLENNUM GT BYTELEFT-38 AND ...).
Thanks to Earl Ryan, Life Insurance Company of Georgia, USA.
Change 8.034 IBM documented SMF6XFNC values of S and U for type 65
VMAC6156 and R for type 66, but S and U have been found in SMF
Apr 17, 1990 type 66. Now, MXG tests for R, S, or U for either type
in creating MXG variable FUNCTION.
Thanks to John Mattson, National Medical Enterprises, USA.
Change 8.033 MXG Tape mount monitor variables DEVFROM and DEVTO were
VMACTMNT not formatted to HEX4. (add them in line 004600), and
Apr 12, 1990 DEVNR should be removed from line 020000.
Thanks to Glenn Thompson, Comalco, AUSTRALIA.
Change 8.032 VTOC processing variable RECFM should have been $4. in
VMXGVTOC line 032000 (instead of $3.), although it is unlikely
Apr 12, 1990 to ever see a non-blank in the fourth position.
Thanks to Wyman Young, BHP, AUSTRALIA.
Change 8.031 DB2 Lock Detail report PMLOK03 fails with a 170 format
ANALDB2R conflict error, because variable ELAPSED was previously
Apr 12, 1990 defined as a numeric variable. In three lines within the
PMLOK03 macro, lines 073560, 073570 and 073780, change
the variable name ELAPSED to LOCKTMCH.
Thanks to Dennis Longnecker, Wash. Office Admin for Courts, USA
Change 8.030 DB2 reporting from GTF (instead of SMF or PDB) failed,
ANALDB2R with "GTF is not a SAS library" error. We had failed to
Apr 11, 1990 test the GTF option in MXG 7.7. The correction is to
change line 002670 from
%IF &&PDB&I = SMF %THEN ....
to read
%IF &&PDB&I = SMF OR &&PDB&I = GTF %THEN ....
Thanks to Cindy Schinker, AgriData, USA.
Change 8.029 TSO SPF EDIT subcommand COPY should NOT be used to copy
TSO-SPF an MXG member into your USERID.SOURCLIB library from the
Apr 10, 1990 MXG.SOURCLIB, because the COPY subcommand of EDIT will
renumber the lines! Always use SPF COPY Command (3.3)
to copy members without renumbering, so that numbering
will be preserved. (It's not clear when this began to
happen, nor whether its an IBM design change or an error;
if you know more on the subject, let me know!)
Change 8.028 ROSCOE Audit records were not being output in ROSCOAUD.
VMACROSC Because there is no ROSCOE version identifier in their
Apr 10, 1990 record, an ad hoc test (TIME = . ) used to detect earlier
versions now prevents testing for audit records. In line
073500, replace the (TIME = . OR ROSREC = '30'X) with
(ROSREC='F0'X OR ROSREC='30'X OR 'A0'X LE ROSREC LE 'AB'X)
to process those record subtypes. In addition, variables
ACCTCODE FORMKEY and USERID were added to ROSCOAUD keep.
Thanks to Tom Braswell, Dow Jones & Company Corporate DP, USA.
Change 8.027 TYPE6156 processing can cause STOPOVER because cell '02'X
VMAC6156 record was incorrectly decoded. Correction:
Apr 10, 1990 Delete line 015700 (was ICFPSWRD $CHAR32.)
Change line 016800 from LENTHIS-87 to LENTHIS-55
Remove ICFPSWRD= from line 017200.
Thanks to Brian Kaczkowski, AgriData, USA.
Change 8.026 PDB.JOBS variables JINLTIME and JRSTTIME were up to four
BUILDPDB minutes (about 255 seconds!) earlier than JSTRTIME! This
BUILDPD3 truncation occurs when a DATETIME variable is stored in a
TYPEDOS length 4 variable. Because MXG's default numeric length
UTILXRF2 is 4, all DATETIME variables must be explicitly named in
VMACARB a LENGTH 8 statement, and MXG's QA test member UTILXRF2
VMACROSC is supposed to detect occurrences of DATETIME variables
VMACTMVS with length other than 8. Why did this slip thru QA? Due
VMACVMON to a logic error in UTILXRF2, only DATETIME variables in
VMACX37 more than one MXG-built dataset were tested for length 8!
VMAC102 1.Fixing that error uncovered additional DATETIME variables
VMAC24 that have now been explicitly set to length eight:
VMAC60
VMAC6156 Member Line Number Dataset Variable(s)
VMXGVTOC VMACTMVS 073000 TMVSJIST JISTSTOP,JISTSTRT
Apr 17, 1990 VMAC24 006500 TYPE24 OFLDTIME
BUILDPDB 044100 PDB.JOBS JINLTIME,JRSTTIME
BUILDPD3 044500 PDB.JOBS JINLTIME,JRSTTIME
VMAC102 411100 T102S100 QW0100SA,QW0100SB
VMACROSC 070100 ROSCOHU ROSTERM
VMACVMON 213910 VMONSUSP TODSTIME
2.An unrelated additional QA test was added by this change,
to detect character variables with a $MG.... format that
are also length 8. This causes no error but wastes seven
bytes, and results when the formatted variable was not in
a LENGTH $1 statement. This new test identified these
variables which needed a LENGTH statement:
Member Line Number Dataset Variable(s)
VMAC60 009700 TYPE60 ENTTYPID
VMAC6156 004300 TYPE6156 ENTTYPID
3.The QA CROSSREF output also showed that several members
did not contain LENGTH DEFAULT=4 statements, causing
numberic variables to be 8 bytes instead of only four.
DEFAULT=4 was added in VMACARB, TYPEDOS, and VMACX37,
and SMFTIME READTIME JINTTIME 8 was added in VMACX37.
In VMXGVTOC, VOLUME $6 was added to the LENGTH statement
(VOLUME is returned by SAS's VTOC option as a 30-byte
variable, which caused VOLSER to also be thirty bytes!)
Thanks to Elliot Weitzman, Oryx Energy Company, USA.
Change 8.025 MXG testing step TESTIBM has abended at two sites that
JCLTEST have used IMACKEEP to modify the default KEEP list. There
Apr 10, 1990 is no problem with their normal BUILDPDB, etc., but it
appears there is another SAS 5.18 internal limit that is
encountered. One set of symptoms are ERROR: WORK.DIRMACR
REQUIRES MORE SPACE ... with either THE LIBRARY IS IN 16
EXTENTS or THE LIBRARY IS IN nn EXTENTS, AND NO MORE
SPACE IS AVAILABLE ON VOLUME. Other failures show up as
a DATA SET NOT FOUND when the PROC MEANS or PROC PRINT is
invoked, and the SAS LOG shows the program simply stopped
building datasets, with no error. Increasing WORK space
does not correct the problem. (While not documented in
the JCLTEST member, the default JCLTEST requires a max
of 12 cylinders work space for any step with MXG 8.2).
Nor did REGION size have any effect. When the abend is
DASD space related, the SAS message usually indicates
DATA SET WORK.DIRMACR WAS AT OBSERVATION 16744450!
I think this problem is due to re-definition of old style
macros due to the repetitive include of IMACKEEP in this
test jobstep, which exhausts some internal limit for old
style SAS macro re-definitions. But since the error is
circumventable (run JCLTEST without the sites' modified
IMACKEEP), since the error hopefully does not exist in
SAS 6.06, and since I haven't taken the time to create
a repeatable test for SAS Institute to use to detect and
fix their problem, it is left with this documentation
note, until time or more errors cause further study!
Thanks to Marvin Rockhill, Community Hospitals of Indiana, Inc, USA.
Thanks to Georg Simon, Federal Reserve Bank of Philadelphia, USA.
Change 8.024 STOPX37 product SMF record had minor corrections to the
VMACX37 SELECTBK and ACTIONBK variables (changed from $CHAR10.
Mar 27, 1990 $CHAR8.) and MESSAGE variable (changed from @509 $CHAR144
to @513 $CHAR140.), but no loss of data had occurred.
Change 8.023 Lengths of five character variables were truncated due to
ASUMCICS incorrect initialization in this summary member for Trend
Mar 27, 1990 Data Base. Variables OPERATOR,TERMINAL,TRANNAME,TRANSACT
must be four instead of three bytes, and variables SYSID
and APPLID must be eight instead of three bytes in their
initial statements (where now set equal to 'MXG').
Thanks to Mike Hoevenaars, Toyota, CANADA.
Change 8.022 Fixes that should have been in MXG 7.7, but were not.
EXTY39EL 1.VMAC37 needed new formats $MG037FE, $MG037FI, $MG037FU
FORMATS for variables BRL/BRRFEAER, BRL/BRRFEAIN, BRL/BRRCTRC,
VMAC37 which also were added to the LENGTH statement with $1.
VMAC39 LABEL for BRLTYPE should be LOCAL instead of REMOTE, and
Mar 27, 1990 variables were added to the KEEP list: BRRTYPE, BRLTYPE,
BRLMODEL, and BRRMODEL.
2.VMAC39 needed ZDATE added to all KEEP lists, and the
existing-but-never-referenced EXTY39EL member for the
TYPE39EL (route elements) data set is now referenced.
Because TYPE39EL can get large, and because no one has
said they actually use the TYPE39EL dataset, the EXTY39EL
exit now DEFAULTS to create NO observations TYPE39EL.
Thanks to Bruce Widlund, Texas Utilities, USA.
Thanks to Doug Drain, National City Bank, USA.
Change 8.021 ANALDB2R DB2 report in MXG 7.7 was not tested with PDBs
ANALDB2R created by MXG 6.6, causing uninitialized variable error
VMXGSUM messages. MXG uses SAS's NOVNFERR (No Error when Variable
Mar 27, 1990 Not Found) but when the variable is in a BY statement or
Apr 10, 1990 a PROC MEANS control statement, NOVNFERR does not prevent
Apr 15, 1990 the error condition. The usual fix would add a statement
(IF x=. THEN x=.;) for each variable which might not be
in the input dataset (which fakes out the SAS compiler
by creating a variable if it does not exist). ANALDB2R
was changed (but when it was realized that these "fakes"
already existed in the OUTCODE macro argument, and that
MOVEing the lines from OUTCODE to INCODE would avoid any
retyping (with its high exposure to typing error), and
was more robust. The first three reports worked fine. But
the DB2 Accounting Detail report added 150 OUTCODE lines
to the existing 380 INCODE lines, and SAS died with the
"Excessive Parameter Length" Error, because 380 lines do
fit in MWORK=28K, but 380+150 lines break the maximum!
Part of the solution was to re-design the %VMXGSUM macro
so that it protects for possible missing variables in the
MIN, MAX, SUM, etc. operations done by %VMXGSUM, because
that should have been the original implementation. That
enhancement to %VMXGSUM is implemented herein in the 1st
part of this change.
Additionally, however, MXG 7.7 reports expected several
character variables that did not exist in MXG 6.6-built
PDBs. The second part of this change added statements to
supress the UNINITIALIZED VARIABLE messages if a cross-
version report (7.7 report from 6.6 data) is requested!
1.These sixteen new lines are inserted in member VMXGSUM:
After 025910 (IF DATETIME=. THEN DATETIME=.;) and before
026000 (&INCODE) insert:
%DO I = 1 %TO &NUMMAX %BY 1; 02592000
%LET VAR = %SCAN(&MAX,&I); 02593000
IF &VAR = . THEN &VAR = .; 02594000
%END; 02595000
%DO I = 1 %TO &NUMMIN %BY 1; 02596000
%LET VAR = %SCAN(&MIN,&I); 02597000
IF &VAR = . THEN &VAR = .; 02598000
%END; 02599000
%DO I = 1 %TO &NUMMEAN%BY 1; 02599100
%LET VAR = %SCAN(&MEAN,&I); 02599200
IF &VAR = . THEN &VAR = .; 02599300
%END; 02599400
%DO I = 1 %TO &NUMSUM %BY 1; 02599500
%LET VAR = %SCAN(&SUM,&I); 02599600
IF &VAR = . THEN &VAR = .; 02599700
%END; 02599800
2.If you MUST create new ANALDB2R MXG 7.7 reports from old
MXG 6.6-built PDB libraries, you must make these changes.
a.In two places in ANALDB2R, after lines 084860 and 110130
(each is: IF QWHSLOCN = ' ' THEN QWHSLOCN = ' ';),
replicate each line twice, then change the QWHSLOCN to
QLSTLOCN in the first replicate, then change the QWHSLOCN
to QLACLOCN in the second replicate.
b.Replicate line 006330 and change QWHSLOCN to QLACLOCN.
c.Change lines 015610 and 015620 (which initialize variable
QWHSDBAT and QWHSLOCN to four blanks) to now read:
IF QWHSDBAT=' ' THEN QWHSDBAT=' ';
IF QWHSLOCN=' ' THEN QWHSLOCN=' ':
d.Now, replicate this changed line 015620 thirteen times,
and change the replicated lines to now read:
IF QWHSLOCN=' ' THEN QWHSLOCN=' '; 015620
IF QLACLOCN=' ' THEN QLACLOCN=' '; 015621
IF QTXASELM=' ' THEN QTXASELM=' '; 015622
IF QTXASALM=' ' THEN QTXASALM=' '; 015623
IF QTXASPLM=' ' THEN QTXASPLM=' '; 015624
IF QTXABLLM=' ' THEN QTXABLLM=' '; 015625
IF QTXAINLM=' ' THEN QTXAINLM=' '; 015626
IF QTXAIOLM=' ' THEN QTXAIOLM=' '; 015627
IF QLACTRNS=. THEN QLACTRNS=.; 015628
IF QLACCNVQ=. THEN QLACCNVQ=.; 015629
IF QLACMSGS=. THEN QLACMSGS=.; 015630
IF QLACMSGR=. THEN QLACMSGR=.; 015631
IF QLACBYTS=. THEN QLACBYTS=.; 015632
IF QLACBYTR=. THEN QLACBYTR=.; 015633
Thanks to Dale St. Amant, Tenneco, USA.
Change 8.020 As discussed in Change 7.139 in MXG 7.7 CHANGES, SYNCSORT
VMACSYNC creates an invalid CPUTCBTM value (hex'555555'=15:32HHMM)
Mar 23, 1990 but it was not known why. SYNCSORT Early Warning Nr. 2803
now identifies the culprit; the use of FREE=CLOSE on the
SORTIN DDNAME causes SYNCSORT and MVS to both have issued
active STIMERS, which causes the corruption in their CPU
TCB time measurement. Eventually, SYNCSORT will fix the
conflict by zeroing out the field when a second STIMER is
set. MXG now recognizes '00555555'X and sets CPUTCBTM to
be missing in VMACSYNC. When the SYNCSORT fix is applied
in the future, a zero value instead of missing value will
result. This is a price you pay for FREE=CLOSE. Note that
even DFSORT specifically states to not specify FREE=CLOSE
on SORTIN DD statement
Note that this STIMER conflict ONLY affects the CPU time
that is measured by the 2nd STIMER issuer. The true CPU
TCB time in the SMF type 30 and the RMF type 72 records
are NOT affected, and remains correct.
Note also that FREE=CLOSE similarly affects SAS reported
CPU times on the SAS log, and can actually cause SAS to
ABEND with an internal apparent CPU TIME EXCEEDED error,
that also does not affect type 30/72 data, as was first
discussed on page 6 of MXG Newsletter TEN. With SAS, you
can still use FREE=CLOSE by specifying the NOSTIMER
option, which supresses CPU capture by not even issuing
the STIMER macro. (While SYNCSORT also has a NOSTIMER
option, it does not work in the same way, and will not
zero the CPU field when FREE=CLOSE is used.)
Thanks to Sam Sheinfeld, Kraft General Foods, USA.
Thanks to Nanette, SYNCSORT, USA.
Change 8.019 As documented in Newsletter SIXTEEN, MXG support for
VMACEPIL Candle's EPILOG/CICS was incomplete. It was also wrong!
XMACEPIL 1.The correct member to include (in member TYPEEPIL) is
XXACEPIL XMACEPIL in place of VMACEPIL, and DO NOT use XXACEPIL).
Mar 23, 1990 2.In member XMACEPIL, a + sign is missing in line 039300,
which should read: @121+OFFEPIL BISTIME ....
3.Variable WID should be 8 bytes (it is UOWID), but the
DEFAULT=4 causes it to be kept as only 4 bytes. It needs
to be added with explicit length 8, but eventually will
be converted and decoded into UOWID and UOWTIME.
Thanks to ???, ???.
Updated Jan 14, 1991. Member XMACEPIL was corrected and
copied into (replacing) member VMACEPIL, and then the
member XMACEPIL was deleted. All future EPILOG CL1000
support will be in member VMACEPIL, as it should have
been all along. See Change 8.212.
Change 8.018 System Managed Storage (SMS) now uses formerly reserved
VMXGVTOC bits located at offset '4E'x in the DSCB1 in your VTOCs.
Mar 22, 1990 DASD products like DMS/OS and ASM2 have used these bits,
and local modifications (to CSECTS IFG0196W and IFG0194E)
have also caused this "DSCB Contamination".IBM published
"Clean up VTOCs Before Implementing DFP V3"(as WSC Flash
9009, Hone Entry G022345) to advise you of the exposure.
If DSCB contamination is found, you must not only clean
the VTOCs of your online data sets, but you will need to
also clean all migrated datasets, since their DSCBs were
also migrated and your migration software will need to
correct the contamination when datasets are recalled.
The change in 8.2 creates these new SMS variables in the
VTOCLIST (for VMXGVTOR) or LIST (for VMXGVTOC) dataset:
DS1CRSDB='DADSM CREATE ORIGINATED BLOCKSIZE?'
DS1PDSE ='PDSE MANAGED DATASET?'
DS1REBLK='DATA SET MAY BE REBLOCKED?'
DS1SCAVB='SECONDARY IS ORIG AVG BLOCK LENGTH?'
DS1SCCP1='SECONDARY IS COMPACTED BY FACTOR OF 256?'
DS1SCCP2='SECONDARY IS COMPACTED BY FACTOR OF 65536?'
DS1SCKB ='SECONDARY IS IN KILOBYTES?'
DS1SCMB ='SECONDARY IS IN MEGABYTES?'
DS1SCUB ='SECONDARY IS IN BYTES?'
DS1SCXTV='SECONDARY SPACE EXTENSION VALUE'
DS1SMSDS='SYSTEM*MANAGED*DATASET?'
DS1SMSUC='NO BCS ENTRY EXIST FOR DATA SET?'
OFFSET4E='OFFSET 4E*INTO DSCB1*(USED BY SMS)'
2.The PROC SORT DATA = EXTENT; BY VOLSER POINTER; was
inside the %DO group was relocated outside, just before
the %DO, since no values in EXTENT were changed; this
will speed up execution slightly.
3.Adding variable OFFSET4E to VMXGVTOC is simple: replace
line 045100 (now containing only +4 ), with this:
@84 OFFSET4E $CHAR4.
and add OFFSET4E to the KEEP list for the LIST dataset.
Then, you can execute the following MXG program under TSO
to read the VTOC of your favorite VOLSER to see if it
suffers from DSCB contamination at offset '4E'x:
ALLOC F(DISK) DA('any data set on chosen volume') SHR
SAS OPTIONS('NODMS MAUTOSOURCE SASAUTOS=SOURCLIB VTOC')
%VMXGVTOC(DISK=DISK); RUN;
DATA CONTAMIN; SET LIST;
IF OFFSET4E NE '00000000'X THEN OUTPUT;
(Dataset LIST is built directly by VMXGVTOC. If you
have implemented VMXGVTOR to graze your entire DASD
farm, the SET LIST; statement would be replaced with
SET &LIB..MXGVTOC which contains all LIST datasets.)
If dataset CONTAMIN has non-zero observation count, then
you either have DSCB contamination, or SMF has already
been installed at your site!
Thanks to Tuanhung Doanvo, Philip Morris, USA.
Thanks to Jim Gilbert, Texas Utilities, USA.
Change 8.017 Hiperbatch hit/miss stats were added by IBM to type 14/15
VMAC1415 and type 64 by TNL (GN28-1284) dated Jan 3, 1990 that was
Mar 22, 1990 delivered today. (Had it been received even by Feb 20, it
would have been implemented in MXG 7.7, avoiding this
change!). The change adds five new fields to both the
TYPE1415 and TYPE64 data sets. While the fields are the
same, IBM used two different field names/acronyms:
TYPE1415 TYPE64 Description
name name
SMFIOREQ SMF64SIO Hiperbatch total searches/requests
SMFCHITS SMF64HIT Successful searches
SMFPHIOS SMF64MIS Misses; caused physical DASD I/O
SMFCIOS SMF64IOS Misses that were copied into buffers
SMFNMWTS SMF64WTS Suspends due to conflict other users
Change 8.016 TPX dataset TPXINTRV will have zero observations because
VMACTPX of mis-alignment in the subtype 2 or 4 records. After
Mar 22, 1990 line 040900 insert:
IF TPXVER GE 200 THEN INPUT TPX24LEN PIB2.
TPX24ID $CHAR2.
@;
Note: TPX24ID was printed in error as $CHAR4. in Newsletter
SEVENTEEN, but was correct in MXG PreRelease 8.2 and
later software. It should be $CHAR2. as shown above.
Thanks to Kari Strand, Televerkets EDB-tjeneste, NORWAY.
Thanks to Doug Mayward, Pharmaceutical Data Services, Inc, USA.
Change 8.015 New subtype 3 of the existing SMF type 41 record provides
EXTY41AC usage statistics of the Virtual Lookaside Facility (VLF).
EXTY41UN Interval records (15 min) are written for each class in
EXTY41VF your COFVLFnn member of PARMLIB that is currently in use.
VMAC41 MXG creates dataset TYPE41VF from this subtype, reporting
Mar 22, 1990 (for each VLF class used) the MAXVIRT size, the storage
used, counts when objects were found in, added to,
deleted from or trimmed from VLF during the interval,
the largest object attempted to be added to VLF since VLF
was started, and the VLF "pct found/hit ratio". Multiple
VLF classes (CSVLLA, IGGCAS, IKJEXEC) can exist in one
type 41 subtype 3 record; multiple observations with the
same SMFTIME will be created by MXG. This change deletes
the existing TYPE41 dataset built from subtypes 1 and 2
and in its place creates two: TYPE41AC (DIV Accesses)
and TYPE41UN (DIV Unaccesses), which now keep only the
variables specific to those DIV events.
Thanks to Dan Barbatti, Southwestern Bell, USA.
Thanks to Jim Gilbert, Texas Utilities, USA.
Change 8.014 These circumvention members (for SAS 344 compiler limit)
XMAC7072 did not keep ZDATE in all datasets and had a typographic
XMAC71 error.
Mar 22, 1990 1.In XMAC7072, add ZDATE to the KEEP list for TYPE70PR and
TYPE72MN datasets.
2.In XMAC71, remove the extraneous period before the final
semicolon in line 031800.
Thanks to Bruce Widlund, Texas Utilities, USA.
Change 8.013 DB2 data read from GTF did not have DATETIME21.2 format
VMACSMF nor LENGTH=8 for SMFTIME variable, but now _GTFDB2 macro
Mar 22, 1990 contains SMFTIME in both FORMAT and LENGTH statements.
Thanks to Susan Marshall, SAS Institute Europe, GERMANY.
Change 8.012 As noted in comments, type 79 support had not been tested
VMAC79 with real records. Now it has, and these changes will be
Mar 21, 1990 required to avoid STOPOVER or invalid data conditions.
1.These seven actions are SPF commands to be entered on the
command line while SPF EDITing member VMAC79 to make the
global changes (note that blanks ARE important):
a.EXCLUDE ALL
b.FIND ' = ' ALL (16 occurrences found)
c.CHANGE ' = ' '=' ALL
d.CHANGE ' BY ' '-1 BY ' ALL NX
e.EXCLUDE ALL
f.FIND ' LE LENGTH' ALL (21 occurrences found)
g.CHANGE ' LE LENGTH' '-1 LE LENGTH' ALL
2.Change line 013800 to read CYCLE ?? PD4.
3.Insert new line 015910 (after 105900) R79LF2 $CHAR1.
4.Change line 016200 to read R79RSV $CHAR2.
5.Change line 016900 to read R79IST ?? PDTIME4.
6.Change three occurrences in two lines of R792SLQR to read
R792LSQR.
7.These first six items bring the code up for MVS/ESA, but
for MVS/XA, other STOPOVER conditions are guaranteed, as
the code was only written for ESA. Guess what, though.
A real slick trick for MVS/XA execution (pointed out to
me by a user who got the trick from LEGENT's MICS) is to
execute with this code:
MACRO STOPOVER MISSOVER %
%INCLUDE SOURCLIB(TYPE79);
which will simply set the non-MVS/XA variables missing!
(I seldom use MISSOVER, because it does not tell you
that there were short records; I need STOPOVER so that
I GET the dump of the record, but is perfect here.)
Eventually, I may retrograde the code to support the XA
records, by breaking up the INPUT statement and inputting
conditionally the MVS/ESA variables, and thereby support
both MVS/XA and MVS/ESA type 79 data records, if that is
really necesary!
Thanks to Ron Thein, Mortgage Guaranty Insurance Corp., USA.
Thanks to Dan Barbatti, Southwestern Bell, USA.
Thanks to Randy Catlin, CENTEL.
Change 8.011 New member ZZZZZZZZ now exists as the last member of the
ZZZZZZZZ MXG library (AAAAAAAA is the first) so that it will be
Mar 15, 1990 easy to verify that all of the MXG Source Library ("from
AAAAAAAA to ZZZZZZZZ") has been successfully unloaded.
(Twenty new customers received incomplete MXG 7.7 tapes
from SAS before a customer discovered that only 1057 of
the 1100 members had been copied from our master tape!)
Thanks to Don Ehrig, Pearl Vision, USA.
Change 8.010 Support for NETSPY 3.2 was incomplete. NSPYVIRT (Virtual
VMACNSPY Route) variables APACING HOSTSUB OSTAGEP VRBLOCKD VRHELD
Mar 15, 1990 VRBHELDT VRBNSESS VROPEN VRBOPACT VRBPRTME were not input
and APPLID was replaced by SUBHOST. NSPYLINE variables
NSPDLY NSPDIALU NSPNMAXD NAPNMAXO NSPNANC NSPNCA NSPNNELS
NSPNPACE NSPNPLIM NSPNRTO NSPNSLIM were not input. These
un-input variables did not cause MXG to fail, they just
were not read in. Three other variables were actually
wrong and must be changes.
1.Line 052500 should read: BUF_UTIL=100 - FBLPCT;
so that minimum free buffers are used to calculate buffer
utilization (instead of average free buffers).
2.Line 059400 should read: COTPUTSZ PIB8.
(as PIB4., COTPUTSZ, Output Length, was always zero).
3.Move NETWADDR in line 009400 (in data set NSPYLU keep) to
line 008000 (in data set NSPYLINE keep list).
Thanks to Marty Quinlan, Virginia Power, USA."
for extensive validation.
Change 8.009 The %VMXGVTOR macro which invokes the FMXGUCBL function
FMXGUCBL was not correct. Changes made in VMXGVTOC (which is the
VMXGVTOR piece that actually reads the VTOC) were not propagated.
Mar 15, 1990 1.In member VMXGVTOR:
Jun 13, 1990 a. In lines 002200 and 002300 replace &I with &IVTOR.
b. Replace two lines 002500 and 002600 with these three:
PROC APPEND BASE=&LIB..VTOCLIST NEW=LIST FORCE;
PROC APPEND BASE=&LIB..VTOCMAP NEW=MAP FORCE;
PROC APPEND BASE=&LIB..VTOCINFO NEW=INFO FORCE;
2.The FMXGUCBL function was modified in MXG 7.7 (see page
17 of MXG Newsletter SIXTEEN), so the function would work
compatibly under either SAS 5.18 or SAS 6.06+, but it was
only tested under SAS 6.06! Under SAS 5.18, the MXG 7.7
FMXGUCBL returns a value too large by one. The following
change DOES work under either version of SAS and does let
a single assembly of this function to work witheither
SAS 5.18 or 6.06+. Change member FMXGUCBL lines 017400
thru 017500 so they now read:
MVC WORKAREA(4),=XL4'4E000000' 01740000 no change
LD FR0,WORKAREA 01741000 was SD FR0,FR0
XC WORKAREA+4(4),WORKAREA+4 01742000 new line
AD FR0,WORKAREA 01750000 no change
Thanks to Jeff Fox, SKF Inc, USA.
Thanks to David Fahey, SAS Institute Cary, USA.
Change 8.008 This is a complete revision of the text of this change
IMACVMON that was published in MXG Newsletter SEVENTEEN.
VMACVMON 1.The Q1SEC equation was wrong. The actual calculation
Jul 19, 1990 is Q1SEC=SUM(Q1TIME,E1TIME)/SUM(Q1DROPS,Q1); .
The lines affected by this change are:
a. After 035700, insert Q1SEC (to the KEEP= list)
b. After 082100, insert Q1SEC='AVERAGE*Q1SEC*DURATION'
c. After 146800, insert two lines:
DENOM=SUM(Q1DROPS,Q1);
IF DENOM GT 0 THEN Q1SEC=SUM(Q1TIME,E1TIME)/DENOM;
ELSE Q1SEC=.;
d. After 170000, insert Q1SEC (to the RETAIN list).
2.Comments in IMACVMON were added to stress the importance
of setting _INTRV macro value to equal your VM/Monitor
interval. If you leave the MXG default _INTRV value of
1 minute, but actually write records at 15 minutes, MXG
will throw away all USER and DASTAP data.
3.Variables PCTQUEDV/PCTQUECU were wrong, and instead of
containing the percentage of monitor intervals during
which there was a queue (as VM MAP calculates), these
MXG variables actually contained 100 times the average
number of entries in the queue. Now, they are correct and
should agree with VM MAP. The label for PCTQUEDV was
corrected and a label provided now for PCTQUECU.
4.The VM/370 SEEK (Class 7) reports in ANALVMDY do not work
and have not been fixed in MXG 8.7. It was re-packaged
incorrectly and causes syntax errors. Also, the logic to
match Seek address with the Mini-Disk directory may cause
ambiguous results, because it turns out that directory
entries can overlap. Pended for test data and test site.
Thanks to Bob Small, Grumman Data Systems, USA.
Thanks to George Ellard, Federal Express, USA.
Change 8.007 TSO/MON data set TSOMDSNS did not contain SYSTEM, and
TYPETSOM TSOMCMND had missing STRTTIME if there were enough users
Mar 19, 1990 logged on to create multiple System records for one
interval. (The TSOMSYST data set was protected by retain,
but the restore logic was after TSOMCMND was output.)
1.Add SYSTEM to keep list at line 005200.
2.Move three lines 084200 thru 084400 (which restore
STRTTIME,ENDTIME,and MAXUSERS from TSOMSTAR,TSOMENDT,and
TSOMAXUS) to immediately after line 072700 (before the
COMNDTYP='00'X; statement.
Thanks to Pete Shepard, Ashland Oil, USA.
Change 8.006 TYPEIMS IMS Log processing had missing values if IMS
TYPEIMS crashed repeatedly, due to duplicate DTOKEN values.
Mar 19, 1990 1.Move IMSTAPNO in lines 035400 and 035800 to make the line
read: BY IMSTAPNO DTOKEN PSTNUMBR TRANSACT IMSRECNO;
2.Insert IMSTAPNO in line 036900 to make the line read
BY IMSTAPNO DTOKEN;
3.Move IMSTAPNO in lines 094900 and 095300 to make the line
read: BY IMSTAPNO DTOKEN ARRVTIME GUTIME IMSRECNO;
4.Insert IMSTAPNO in line 108300 to make the line read
BY IMSTAPNO DTOKEN;
Thanks to Pete Shepard, Ashland Oil, USA.
Change 8.005 IDMS/R Performance Monitor SMF record variables PGMTYPE,
VMACIDMS TASPTYPE, and TASTTYPE were kept as 8-byte variables and
Mar 15, 1990 with $HEX2. format. They should have been 1-byte length
with the $MGIDMPP, $MGIDMTT, and $MGRTEPT formats. Also,
the IDMSDBK data set was never output.
1.Delete the semicolon at the end of the LENGTH statement
in line 072000, and insert this new line
PGMTYPE $1. TASPTYPE $1. TASTTYPE $1.;
to force their length to only one byte, and then also
2.Remove these same three variable names from line 072400
(where the $HEX2. format overrode line 072000).
3.Change line 154800 from EXIDMCDM to EXIDMDBK.
Thanks to Mike Eisenhart, York International, USA.
Thanks to Mark Robbins, Jaguar Cars, ENGLAND.
Change 8.004 Candle's OMEGAMON/VM for VM/XA has an option to reformat
VMACVMXA IBM's MONWRITE data records into a Variable Blocked (VB)
Mar 15, 1990 file. Unfortunately, their program did not create valid
VB format records. They incorrectly added an extra RDW
(Record Descriptor Word of 4 bytes) in front of the real
RDW (does this make the record a VVB format!).
Because VB records are easier to work with during testing
and because it was hoped that IBM would eventually change
MONWRITE to create legitimate VB data files, MXG's VM/XA
support defined the _OUTFILE macro, that does create true
VB data records from IBM's MONWRITE records, and MXG's
_VMINPUT macro was defined to process those (future!) VB
records. With only a minor change, MXG's _VMINPUT macro
can be modified by Candle sites to process those invalid
"VVB" format data. Candle has acknowledged their error,
and announced that a permanent solution (i.e., correct
VB record format) would be provided in their next release
of VCOLLECT in their Version 4.10, in second quarter 90.
Before 4.10, Candle sites can read the "VVB" data by the
followin new line inserted after 769000 (ends a PUT that
precedes the INPUT MRHDRDM ... ), skipping over the RDW:
INPUT +4 @;
BUT THIS CHANGE IS ONLY FOR CANDLE "VVB" PRIOR TO 4.10.
IT MUST BE BACKED OUT WHEN YOU INSTALL THEIR 4.10.
Candle's VCOLLECT Incident Number is 81696.
2.To read real VB data (either from Candle 4.10 or using
MXG's _OUTFILE), if you have installed the IBM PTFs that
are described in Change 7.219, you will need to add this
correction (unrelated to the Candle problem, but observed
while debugging the Candle-created problem):
The following line must be inserted after line 769600:
LENGTH=LENGTH+4;
(immediately before the MRHDRLEN=LENGTH; statement), to
set LENGTH to the physical instead of logical record
length, as expected by MXG's MONWRITE logic.
Thanks to Mark Flugrath, WVNET, USA.
Change 8.003 DASDMON data sets did not have SMFTIME and ZDATE in their
VMACDMON KEEP= list, causing uninitialized variable error in the
Feb 26, 1990 ANALDMON report program. Now they do.
Thanks to Danny High, Blue Cross Blue Shield Texas, USA.
Change 8.002 ACF2 ARE data segment had two bytes not read, causing a
VMACACF2 STOPOVER condition. If the ARE did not exist, a program
Feb 23, 1990 loop could occur.
Mar 22, 1990 1.Insert two new lines, after line 052000 and 054200 (both
of which are ACLFLDNM $CHAR8.). The new lines contain
+2
(thereby skipping over two bytes after ACLFLDNM).
2.Change line 051500 to now read:
IF ACLAFARE GT 0 AND ACLMFLGS NE '...1....'B THEN DO;
3.Change line 053700 to now read:
IF ACLBFARE GT 0 AND ACLMFLGS NE '..1.....'B THEN DO;
Thanks to Roman Gudz, Leaseway Transportation, USA.
Thanks to Steve Cavill, SAS Institute, AUSTRALIA.
Change 8.001 The first step of JCLTEST builds the MXG Format (SASLIB)
JCLTEST library. MXG 7.7 (unlike previous versions) requires the
VMACIMS SAS option MACRO in building formats (added to support
Feb 23, 1990 both SAS 5.18 and SAS 6.06+). Either specify MACRO on
May 5, 1990 the EXEC statement or use PROC SETINIT to set the default
to MACRO. Other MXG uses of the "new" %MACRO facility
also require DQUOTE to be similarly enabled. For the DB2
reporting and some of the Trend Data Base programs, the
option MWORK=28K (which sets the size of the macro work
area) prevents an "Excessive Parameter Length" error.
MXG now requires these SAS System options:
MACRO DQUOTE MWORK=28K GEN=0
For DB2 reporting (ANALDB2R) additional options are also
suggested (see comments in that member).
The two PUT statements that contained double quotes in
VMACIMS (requiring DQUOTE in step TESTOTHR) were changed
to single quotes.
LASTCHANGE: Version 8
End of Changes Log.