This is the Production Version MXG 9.9, dated March 1, 1992.           
 All Changes listed in this member have been installed in MXG 9.9.      
 HOT NOTES:                                                             
 Several new changes were added after NEWSLETTER TWENTY-ONE went to     
 press; see the Change Log, below, for Changes 9.236 thru 9.245.        
 The library now has more members, lines, datasets and variables than   
 was stated in the newsletter. This final MXG 9.9 library contains      
 1,605 members, 388,651 lines of code, builds 1,093 datasets with       
 41,332 variables documented in DOCVER with delta-doc in DOCVER09.      
 Over 800 sites have installed a PreRelease of MXG Version 9!           
 The installation instructions for MXG 9.9 were contained in NEWSLETTER 
  TWENTY-ONE, which is contained in member NEWSLTRS, repeated also      
  below in this member.                                                 
I.    MXG Version Status.                                               
 1. Production Version is now MXG 9.9, dated March 1, 1992.             
    MXG Version 9.9 was accompanied by Newsletter TWENTY-ONE.           
    All Changes in this newsletter have been installed in MXG 9.9.      
    The MXG 9.9 library contains 1,605 members, 388,651 lines of code,  
    and builds 1,093 datasets with 41,332 variables that are documented 
    in member DOCVER.  Datasets changed between MXG 8.8 and MXG 9.9     
    are documented in member DOCVER09.                                  
 2. Major enhancements and new products supported in MXG 9.9.           
        Support for SAS 6.07 (new options).                             
        Support for Amdahl's SPMS Release 1.2 SMF record.               
        Support for Boole & Babbage CONTROL-D SMF record.               
        Support for CA-1 (TMS) Release 5 complete rewrite.              
        Support for CADAM's Statistics Data File.                       
        Support for CICS/ESA 3.2.1 product.                             
        Support for Codework Software's SNAPAD-MVS user SMF record.     
        Support for Database 2 Release 2.3.                             
        Support for DCOLLECT APAR OY36364 change in track capacity.     
        Support for Fischer's Totally Automated Office TAO.             
        Support for HSM 2.6 SMF record.                                 
        Support for Interlink's SNS/SNA Gateway SMF record.             
        Support for Interlink's SNS/TCPaccess SMF record.               
        Support for Interlink's SNS/TCPvt  SMF record.                  
        Support for LEGENT's MIM Multi-Image Manager                    
        Support for LEGENT's LANSPY component of NETSPY (4.1).          
        Support for LEGENT's BUNDL product modified type 6 SMF record.  
        Support for MVS/ESA 4.2.2 (RMF 4.2.2) changes.                  
        Support for NetView NPM 1.5 release.                            
        Support for NetView FTP SMF record.                             
        Support for Omegamon for CICS/ESA Version 550 ESRA user SMF.    
        Support for Omegamon V550 SMF 110 EMPs (Basic, DB2, DL/I).      
        Support for SCA's CMA-SPOOL user SMF record.                    
        Support for Shared Medical Systems CICS exclude logic.          
        Support for Softtool Corporations's CCC (Change and Control).   
        Support for Software AG's NET-PASS user SMF record.             
        Support for Type 30 APARs OY33312 and OY25606 (no changes).     
        Support for 3490E (Serpentine) tape device.                     
        Support for 9345E DASD device.                                  
        Addition of DB2ACCT,STAT0,STAT1 datasets to your PDB.           
        Error in VMXGVTOF/VMXGVTOF (only 3 extents kept) corrected.     
        Revision of BUILDPDB to eliminate SAS 5.18 Compiler Error 344.  
        Cache RMF Reporter support enhanced, decoded, and documented.   
        DB2 Reports corrections and enhancements in ANALDB2R.           
        Fujitsu FACOM MSP and FSP supported in XPDLPDA.                 
        IMS Input Queue time, resources, CONDCODE  corrections.         
        PR/SM Trend Data Base implemented.                              
        VM/XA Trend Data Base implemented.                              
    Each of these enhancements are described in the Change Log, below.  
    alphabetical list of the most important changes precedes the        
V.    Installation Instructions for MXG Version 9.9.                    
    Over 800 sites have installed a PreRelease of Version 9, with almost
    no reported problems.  Sites migrating from MXG Version 8.8 or later
    have found installation of MXG 9.9 was smooth and easy.  The only   
    known incompatibilities are listed below, before the instructions.  
    Under ALL SAS Versions:                                             
    BUILDPDB/3 sites who have added DB2 processing to their PDB must now
    "back-out" their exit code as described in Change 9.175; MXG now has
    added DB2ACCT/DB2STAT0-1 datasets automatically to your PDB, and    
    a syntax error in BUILDPDB will occur if you fail to heed this note.
    Only under SAS Version 6.07:                                        
    Use new member CONFIG07 instead of CONFIG.  No error will occur, but
    several unnecessary WARNING messages will be eliminated by use of   
    the new CONFIG07 member for 6.07.                                   
    Only under SAS Version 5.18:                                        
    BUILDPDB/3 under SAS 5.18 ONLY (not required with SAS 6.06/SAS 6.07)
    sites must add a new temporary DD card in their JCL for BUILDPDB:   
       //SMFTEMP  DD UNIT=SYSDA,SPACE=(CYL,(20,20))                     
    This inconvenience may help eliminate SAS 5.18 compiler 344 errors. 
    If you encounter SAS 5.18 errors 344 or 160 see Change 9.175.       
    A syntax error in BUILDPDB will occur if you fail to heed this note.
    However, if you have NOT installed MXG 8.8, you MUST note:          
    a. See SAS Notes section of this newsletter.  The SAS options that  
       are required by MXG were changed between MXG 7.7 and MXG 8.8.    
    b. Execution under SAS 6.06 is different than under SAS 5.18. See   
       SAS Notes section of newsletters 17-21.                          
    e. To write your PDB directly to tape, IMACCICS must be changed as  
       described in comments in the member.  Although MXG does support  
       creation of the PDB directly to tape, most sites find it better  
       (especially elapsed time) to create the PDB on temporary disk and
       then use PROC COPY to copy from disk to tape.  (BUILDPDB re-reads
       PDB datasets to build RMFINTRV, and this can cause lots of tape  
       spinning when the PDB DDname points directly to tape.)           
Always read comments in the CHANGES member for compatibility issues, as 
well as for any last minute changes added after Newsletter composition. 
 1. Installation, re-installation, and Space Requirements.              
The MXG Installation instructions are found in Chapter 32 of the MXG    
Supplement for both new installation and for version replacement, and   
those instructions, as modified herein, are still valid.                
The MXG tape is distributed as a Non-Labelled (NL) tape containing a    
single file with DCB=RECFM=FB,LRECL=80,BLKSIZE=32720.  The MXG tape is  
an unloaded Partitioned Dataset in IEBUPDTE format.  Note that the tape 
blocksize was changed to 32720 (it had been 6160 in prior versions). You
will receive I/O errors if you specify the incorrect blocksize.         
Under MVS use IEBUPDTE utility to build the MXG.SOURCLIB PDS library.   
Under CMS use TAPPDS   command to build the SOURCLIB MACLIB library.    
Allocate the MXG.SOURCLIB for MXG 9.9 with SPACE=(CYL,(50,1,299)), using
  DCB=(RECFM=FB,LRECL=80,BLKSIZE=23440) on 3380 devices, or             
  DCB=(RECFM=FB,LRECL=80,BLKSIZE=27600) on 3390 devices.                
Under CMS, approximately the same space (50 cylinders) will ultimately  
be required by the MXG SOURCLIB MACLIB, but during the CMS installation 
process you will need at least 100 free cylinders on your minidisk.     
MXG is tailored and extended by "Installation Macro" members (members   
beginning with IMAC....), and by "MXG Exit Facility" members (members   
beginning with EX....) that are copied and edited into the installation 
"USERID.SOURCLIB", the name of the "MXG Tailoring" library, that you    
create and concatenate ahead of MXG.SOURCLIB to the SOURCLIB DDNAME:    
  //SOURCLIB DD DSN=USERID.SOURCLIB,DISP=SHR --> site tailoring (yours) 
  //         DD DSN=MXG.SOURCLIB,DISP=SHR    --> never changed  (mine)  
If this is an MXG re-install, there should already be a USERID.SOURCLIB.
If not, then allocate one using the same attributes as the MXG.SOURCLIB,
with SPACE=(CYL,(1,1,99)).  Under CMS create an equivalent MACLIB.      
Tailor by editing members that you copy from my library to your library.
IMACXXXX members are self-documenting, and member IMACAAAA indexes all  
IMAC members.  Most MXG sites have only a few tailoring members in their
VMACXXXX members contain the actual processing code, and normally should
not exist in your USERID.SOURCLIB, and should always be removed when you
install a new version of MXG.  However, if you have installed printed   
Changes from an MXG Newsletter, you might have copied VMAC member(s)    
from MXG.SOURCLIB into your site's USERID.SOURCLIB and then modified the
VMAC member.  (Alternatively, you could have created an MXG.CHANGLIB in 
which you put those in-between-version changes.)  In either case, if    
you made temporary changes, they must be removed now.  Delete all of the
VMACs members from your USERID.SOURCLIB (or delete the MXG.CHANGLIB).   
Otherwise, your modified VMAC member would be used instead of MXG's.    
You should record all tailoring changes in your USERID.SOURCLIB so the  
next MXG technician will know what you have done.  You should create a  
member named CHANGES in your USERID.SOURCLIB, similar to member CHANGES 
in the MXG.SOURCLIB which documents all MXG changes.                    
If there are IMAC.... members in your USERID.SOURCLIB, you must look at 
the alphabetic list of changed IMACs in the Change Log, below, and must 
retrofit your tailoring on the new member in this library.  In MXG 9.9, 
only IMACACCT was changed (Change 8.290, in member CHANGES).            
Whenever you install changes or test a new version of MXG (or even your 
own reports), be extra careful to look on the SAS log for any real error
conditions. Search for all occurrences of "ERROR:" and  "ERROR :"  and  
"UNINITIALIZED" and "NOT CATLGD", as they may indicate a serious error. 
A PROC PRINT and a PROC MEANS of each new MXG-built SAS dataset can help
you to understand their contents, and should be used to examine any     
unusually large, negative, or suspicious values.  Print all variables in
the dataset, and read the variable's descriptions in Chapter FORTY.     
 Summary of critical actions to be taken in installing new version:     
     a. All VMAC.... members in your USERID.SOURCLIB must be examined   
        and, in general, must be deleted.                               
     b. All IMAC.... members in your USERID.SOURCLIB must be compared   
        with the IMAC.... members that have been changed in this MXG    
        version (see alphabetic list at beginning of Change Log).  You  
        you MUST start with the IMAC in this version and retrofit your  
        installation's tailoring. Member IMACAAAA indexes all IMAC's.   
     c. It is always wisest to PROC PRINT the first 50 observations of  
        important datasets, especially PDB.JOBS, which can be affected  
        by user tailoring in IMACPDB. A visual scan of that PROC PRINT  
        serves as an excellent validation of correct installation, and  
        will almost always detect any serious problems BEFORE you begin 
        your production MXG runs!  See also the MXG utility UTILPRAL.   
VI.   SAS Technical Notes.                                              
 1. The following important notes are repeated from prior Newsletters:  
 a. SAS OPTIONS REQUIRED under version 5.18, 6.06, or 6.07.             
    Please read this section carefully.  MXG execution will fail if you 
    do not pay attention to these (potentially incompatible) changes:   
    SAS options that are MANDATORY with all SAS Versions:               
        NOIMPLMAC should ALWAYS be used in ANY program.                 
        MAUTOSOURCE and SASAUTOS=SOURCLIB are required by MXG to        
         resolve %MACRO references without extra I/O by using autocall. 
        ERRORABEND ensures SAS stops on any error condition.            
        MACRO enables SAS to recognize %MACROs.                         
        DQUOTE is needed to extract values of certain string %MACROs.   
    SAS options MANDATORY under SAS Version 5.18 (do not exist in V6):  
      MWORK=28000 GEN=0                                                 
        MWORK was needed in large %MACROs (like %ANALDB2R).             
        GEN=0 was needed to eliminate unnecessary I/O and CPU time, and 
        is discussed in the 1984 Guide (see Index).                     
    SAS options MANDATORY under SAS Version 6 (did not exist in 5.18):  
        Previously, MXG recommended MEMSIZE=12M, but programs that build
        many datasets concurrently (like BUILDPDB, VMACVMXA, etc.) will 
        need more of this virtual storage above the line, because of the
        new MXG recommended value for BLKSIZE='half-track'. The MEMSIZE 
        option only works under MVS/XA and MVS/ESA, and since it is not 
        a real resource, and only used when needed during the "building"
        phase in MXG processing, the new default of MEMSIZE=24M should  
        not cause any problem, and will avoid unnecessary ABENDs.       
        If you are using MXG and SAS 6.06 under MVS/370 or CMS/370, you 
        will have to reduce this MEMSIZE= parameter to no more than 6M, 
        and must reduce the BLKSIZE (try 4096, or the minimum 1024).    
        Small BLKSIZE will allow your program to compile, but the DASD  
        work space you will need will significantly increase, as will   
        the run-time, IOs, and CPU requirements for the same job.       
    SAS options STRONGLY RECOMMENDED for SAS 6.06 performance:          
      BLKSIZE=23040 BUFNO=2   -- for 3380's                             
      BLKSIZE=27648 BUFNO=2   -- for 3390's                             
      Both are now automatically set by MXG's use of BLKSIZE(DASD)=HALF 
      in MXG's CONFIG/CONFIG07 members for permanent datasets, but      
      note that the WORK DD in the default SAS JCL procedure contains   
      a BLKSIZE=6144 parameter which MUST be overridden or changed for  
      optimum execution performance:                                    
           //    EXEC MXGSASV9                                          
           //WORK DD DCB=BLKSIZE=23040                                  
      The BLKSIZE option in the CONFIG member will have no effect if a  
      DCB=BLKSIZE value is specified on the JCL DD statement.           
      See "SAS Benchmarks" in Newsletter TWENTY for resource savings.   
    SAS options recommended with either SAS Version 5.18, 6.06 or 6.07: 
        FIRSTOBS=1 OBS=MAX                                              
    So how do you specify these recommended/required MXG options?       
    In Version 5.18, MACRO and MWORK=28000 must be specified on the EXEC
    statement, but all other options could be specified on an OPTIONS   
    statement right after your SYSIN DD * statement.  However, so you do
    not have to remember them nor type them, MXG member SASOPTV5 has all
    of the recommended options in an OPTIONS statement, so you need only
    %INCLUDE SOURCLIB(SASOPTV5);  as your first SAS statement:          
         //stepname EXEC SAS518,OPTIONS='MACRO MWORK=28000'             
         //SYSIN     DD *                                               
            %INCLUDE SOURCLIB(SASOPTV5);                                
             ... the rest of your program ...                           
    For SAS Version 6, options can be set with an OPTIONS statement, or 
    with the OPTIONS= JCL parameter, or (as is MXG's recommendation) via
    the CONFIG= JCL parameter on the EXEC statement.  MXG member CONFIG 
    contains the MXG required and recommended options for SAS 6.06, and 
    member CONFIG07 contains the SAS 6.07 recommendations.  The BLKSIZE 
    and MEMSIZE options were increased in MXG 9.9, and the new CONFIG07 
    member was added with new SAS 6.07 options.  (You could also supply 
    options by overriding the CONFIG DD in the SAS JCL procedure, but   
    using the CONFIG= parameter is safer and simpler.).                 
         // EXEC SAS606,TIME=10,                                        
         //            CONFIG='MXG.SOURCLIB(CONFIG)'                    
         // EXEC SAS607,TIME=10,                                        
         //            CONFIG='MXG.SOURCLIB(CONFIG07)'                  
 b. Format libraries are different in MVS SAS Version 6 and Version 5.  
    The MXG-built "SASLIB" formats are built by the first step of either
    JCLTEST (for SAS 5.18) or JCLTEST6 (for SAS 6.06).                  
    Under SAS Version 5.18, formats are members of a PDS load library   
    which must be allocated as SPACE=(CYL,(3,1,99)).  SAS 5.18 formats  
    are always referenced using the DDNAME of SASLIB.                   
    Under SAS Version 6 formats are members of a SAS data library, which
    must be allocated as SPACE=(CYL,(1,1)). Note there is NO third SPACE
    parameter (for PDS directory blocks), because data libraries in SAS 
    Version 6 are physical sequential files.  SAS Version 6 format      
    libraries are always referenced using the DDNAME of LIBRARY.        
    In either version of SAS, the blocksize is set by the PROC FORMAT.  
    MXG always requires the appropriate DDNAME (SASLIB or LIBRARY).     
    You will fail with SAS 170 FORMAT NOT FOUND errors if you do not    
    have the correct format library pointed to by the correct DDNAME.   
VII.  Documentation of MXG Software.                                    
Member CHANGES always contains the version number of MXG Software, and  
it lists changes that were installed in that version.  The members named
Changenn have the contents of CHANGES when that "nn" MXG version was    
created.  Description of enhancements will be found in the text of the  
Change description that made the enhancement (in those CHANGES and      
CHANGEnn members).  The CHANGE  members can be scanned online (with SPF 
BROWSE) to search for specific product name references (CICS, MVS/ESA,  
etc.).  The text of each Change identifies the member(s) that were added
or altered by that change. Documentation (especially for new product's  
support) is usually also found in comments at the beginning of those    
members listed in the change entry.                                     
Member NEWSLTRS contains the text of all newsletters (up through the    
newsletter that accompanied that MXG release). You can search NEWSLTRS  
for product name or acronym to find the technical notes, APARs, etc.    
from all MXG newsletters.  (The Change Log of each Newsletter is not    
replicated in member NEWSLTRS, since that text will be in CHANGES).     
Member DOCVERnn is the "delta-documentation" (in abbreviated Chapter    
FORTY style) of only those variables and datasets that were changed     
between successive MXG Versions. There is a DOCVERnn "delta" member in  
the MXG library for each version.                                       
Penultimately, member DOCVER contains abbreviated Chapter FORTY format  
that documents all of the variables names in all of the MXG datasets    
that are created by that MXG Software Version (alphabetically by data   
set name and variable name).                                            
Finally, MXG is a source distributed system, so you can often find your 
answer by BROWSE/EDIT of the source member, especially the VMACs that   
actually create the dataset, or ANALs that analyze the MXG datasets.    
In many instance, the MXG Variable name is the IBM or Vendor's field or 
DSECT field name. In other cases, the DSECT field name is carried as a  
comment beside in the MXG INPUT statement to map field name to MXG's    
variable name.  MXG expects you to also have access to the vendor's     
documentation of particular data records you are using for analysis.    
VIII. Change Log                                                        
==========================Changes Log=================================  
 You MUST read each Change description to determine if a Change will    
 impact your site. All changes have been made in this MXG Library.      
 Member CHANGES of the MXG SOURCLIB will always be more accurate than   
 the printed changes in a Newsletter, because the software is created   
 after the newsletter is sent to the printer!                           
 Member CHANGES always identifies the actual version and release of     
 MXG Software that is contained in that library.                        
 The actual code implementation of some changes in MXG SOURCLIB may be  
 different that described in the change text (which might have printed  
 only the easily installed, critical part of the correction).           
 Scan each source member named in any impacting change for any comments 
 at the beginning of the member for additional documentation, since the 
 documentation of new datasets, variables, validation status, and notes,
 are often found in comments in the source members.                     
 Changes thru 9.241  are contained in MXG Version    9.9  Mar  1, 1992  
 Changes thru 9.235 were printed in NEWSLETTER TWENTY-ONE Mar  1, 1992. 
 Changes thru 9.218 were contained in MXG PreRelease 9.8  Feb  3, 1992. 
 Changes thru 9.212 were contained in MXG PreRelease 9.7  Jan 27, 1992. 
 Changes thru 9.205 were contained in MXG PreRelease 9.6  Jan 14, 1992. 
 Changes thru 9.184 were contained in MXG PreRelease 9.5  Dec  1, 1991. 
 Changes thru 9.175 were contained in MXG PreRelease 9.4  Nov 15, 1991. 
 Changes thru 9.107 were contained in MXG PreRelease 9.3, Aug  1, 1991. 
 Changes thru 9.104 were printed in NEWSLETTER TWENTY     Aug  1, 1991. 
 Changes thru 9.069 were contained in MXG PreRelease 9.2, July 1, 1991. 
 Changes thru 9.038 were contained in MXG PreRelease 9.1, June 3, 1991. 
 Changes thru 8.305 were contained in MXG Production 8.9, May  1, 1991. 
 Changes thru 8.285 were contained in MXG Production 8.8, Apr  8, 1991. 
 Changes thru 8.283 were printed in NEWSLETTER NINETEEN,  Apr  8, 1991. 
Alphabetic INDEX of significant changes in MXG 9.9 (after MXG 8.8):     
  Member    Change   Description                                        
  many      9.151  DASD Device 3345 ("Serpentine") data recognized.     
  many      9.152  Tape Device 3490E ("Serpentine") data recognized.    
  ANALACHE  8.293  Cache RMF Reporter analysis uses 3990 records now.   
  ANALDBTR  9.135  DATASET S064058 NOT SORTED error corrected.          
  ANALDB2R  8.299  Variable Not Found if only Acct Trace Long requested.
  ANALDB2R  9.030  DB2 Reports have incorrect values for some fields.   
  ANALDB2R  9.032  DB2 Audit Reports not created if PDB=SMF specified.  
  ANALDB2R  9.104  DB2 Trace TRANSIT report causes DATA IS NOT SORTED.  
  ANALDB2R  9.210  DB2PM-like SQL trace reports added.                  
  ANALRACF  9.064  RACF Analysis of OPERATOR,SPECIAL activity.          
  ANALTMS   9.059  PROC SUMMARY out of memory condition.                
  ANALVVDS  9.031  PERM should be changed to MXGVVDS.                   
  ANALVVDS  9.053  MXG 9.1 only, VMXGVVDS should have been MXGVVDS.     
  APAR/PTF  9.141  OY33312/UY52529 has no impact on MXG processing      
  ASUMDBDS  9.012  TMON/CICS trending fails with Release 7 data.        
  ASUMJOBS  8.291  EXCPTOTL, IOTMTOTL were not kept in BATCHJOB.        
  ASUM70PR  9.091  TYPE70PR data summarized into PDB.ASUM70PR           
  ASUM70PR  9.179  ASUM70PR data wrong if NRPRCS not equal to PARTNCPU. 
  AS400PDS  8.286  AS400PDS contains no records.                        
  BLKSIZE   9.109  MXG distribution tape block size changed to 32720.   
  BUILDPDB  9.049  SAS 6.06 and MXG 8.8 under MVS/370 options.          
  BUILDPDB  9.095  Dataset TYPE0203 added to default datasets built     
  BUILDPDB  9.175  DB2ACCT,STAT0/1 automatically created by BUILDPDB.   
  CASORT66  8.295  SAS datasets destroyed by CASORT release 6.6.        
  CHANGE08  9.073  Example to create _DAY in 8.213 was wrong            
  CONFIG    9.022  Option VERSIONLONG specified to display SAS version. 
  CONFIG    9.131  Default CONFIG for 6.06 updated.                     
  CONFIG07  9.131  Default CONFIG for 6.07 updated.                     
  DIFFDB2   9.080  Not all DB2STAT0/1 variables were deaccumulated      
  DIFFDB2   9.128  DB2STAT0/1 variables improperly deaccumulated.       
  EXPDB304  9.034  BUILDPDB/3 steps data creation exit.                 
  EXPDB6    9.034  BUILDPDB/3 steps data creation exit.                 
  EXTY72    9.184  CPURCTTM invalid in TYPE72, not included in CPUTM.   
  IEBUPDTE  8.286  Unload of MXG 8.8 set condition code 4.              
  IMACACCT  8.290  ACCOUNT FIELD n LENGTH WRONG corrected.              
  IMACCICS  9.005  PDB cannot be built on tape unless IMACCICS changed. 
  IMACDB2   9.121  DB2 Correlation ID decoding corrected.               
  IMACEXCL  9.051  Support for CICS type 110 EXCLUDE statement.         
  IMACEXCL  9.145  CICS EXCLUDE/INCLUDE logic externalized              
  IMACFMTS  9.066  New IMAC for user formats for SAS 6.06.              
  IMACICDA  9.146  CICS EMP data control externalized                   
  IMACICDB  9.181  Support for APAR PL83370 in DBCTL data with CICS/ESA 
  IMACICOx  9.146  Omegamon V550 User EMPs added to type 110            
  IMACKEEP  9.017  A better way to drop MXG variables not using IMACKEEP
  JCLDASD   9.031  MXGDASD,PERM DDNAMEs should be DISK,MXGDASD          
  JCLMNTH   9.225  MONTHBLD require only one tape drive, runs faster!   
  JCLTEST6  9.108  FORMAT not found error in step SMFSMALL.             
  READDB2   9.164  List processing %MACRO for DB2 IFCIDs added.         
  RMFINTRV  9.184  Enhanced, MVS/ESA CPU times and PR/SM data added.    
  RMFINTRV  9.204  RMF72D NOT SORTED condition corrected.               
  SPUNJOBS  9.005  PDB.SPUNJOBS on tape caused 207 error.               
  SPUNJOBS  9.013  SPUNJOBS timestamps not 8 bytes, truncating values.  
  TLMS      9.041  TLMS causes 713-04 ABEND if DBLTIME=0.               
  TRNDDB2A  8.301  DB2 Acct trending failed in 2nd week of execution.   
  TRNDDB2A  9.209  DB2 Trending errors corrected.                       
  TRNDDB2S  8.301  DB2 Stats trending failed in 2nd week of execution.  
  TRNDVMXA  9.028  VM/XA Trend Data Base implemented.                   
  TRNDVMXA  9.089  VM/XA Trended PFXUTIME and PCTCPUBY incorrectly      
  TRND70PR  9.091  TYPE70PR data creates new TREND.TRND70PR             
  TRND70PR  9.179  TRND70PR data wrong if NRPRCS not equal to PARTNCPU. 
  TRND71    9.092  TYPE71 data creates new TREND.TRND71                 
  TRND72    9.093  MVS/ESA 4.2 variables added to TREND.TRND72          
  TYPEAPAF  9.218  Support for Amdahl's APAF.                           
  TYPECIMS  9.122  IMF Chained Transactions response time corrected.    
  TYPECIMS  9.235  Support for IMF 2.7 log records.                     
  TYPEIMS   9.106  IMS Multi-trans resources wrong.                     
  TYPEIMS   9.182  Multi-trans corrections, CONDCODE no longer blank.   
  TYPEIMS   9.216  IMS 3.1 resources wrong for Quick Reschedule trans.  
  TYPEMON8  9.011  TMON/CICS Release 9.0 supported via conversion only. 
  TYPEMON8  9.015  TMON/CICS Version 8 History file cause MXG failure.  
  TYPEMON8  9.168  STOPOVER with bad record in Landmarks Monitor        
  TYPEPDL   8.297  Fujitsu FACOM MSP and FSP support replaced XPDLPDA.  
  TYPE84    9.202  JES3 JMF type 84 SMF record partial support.         
  UTILCICS  9.019  Not Sorted error corrected for CICS/ESA dictionary.  
  VDOCACHE  9.027  Documentation re-write has begun.                    
  VMACACF2  8.289  ACF 5.2 new variables not kept.                      
  VMACACF2  9.086  ACF2 REC=L CN=3 records were not output              
  VMACACHE  8.293  Cache RMF Reporter support enhanced and decoded.     
  VMACAIM2  8.298  Fujitsu AIM database manager records corrected.      
  VMACCADM  9.021  Support for CADAM's Statistics Data File.            
  VMACCCC   9.172  Softtool Corporation's CCC (Change Control) user SMF 
  VMACCMA   9.143  Support for CMA-SPOOL user SMF record                
  VMACCMF   9.126  CMF User SMF record STOPOVER corrected.              
  VMACCTLD  9.038  Support for Boole & Babbage CONTROL-D SMF record.    
  VMACDB2   9.138  Support for DB2 2.3.0                                
  VMACDCOL  8.285  IBM DASD measures use MB for million, not megabytes. 
  VMACDCOL  9.144  DCOLLECT values incorrect after IBM APAR OY36364     
  VMACDCOL  9.157  DCOLLECT variables changed from character to numeric 
  VMACDCOL  9.180  Capacity values off by 120 bytes.                    
  VMACDMON  9.196  Support for ASTEC 1.5.                               
  VMACEPIL  8.284  Support for EPILOG/CICS 451 added, and enhanced.     
  VMACEPIL  8.287  Invalid member on MXG 8.8 replaced.                  
  VMACFOCU  9.223  Support for Information Builder's FOCUS MSO SMF.     
  VMACFTP   9.056  Support for NetView FTP User SMF record.             
  VMACFTP   9.170  FTP records produce no observations                  
  VMACHSM   9.097  Support for HSM 2.6 SMF record                       
  VMACILKA  9.020  Support for Interlink's SNS/TCPaccess SMF record.    
  VMACILKG  9.020  Support for Interlink's SNS/SNA Gateway SMF record.  
  VMACILKV  9.020  Support for Interlink's SNS/TCPvt  SMF record.       
  VMACIMS   9.063  TYPEIMS Input Queue time correction.                 
  VMACLMS   9.229  Support for Memorex Telex LMS/PM SMF record.         
  VMACMIM   9.173  LEGENT's Multi-Image Manager (MIM) user SMF record   
  VMACMIM   9.173  Support for LEGENT's Multi-Image Manager MIM record. 
  VMAC28    9.116  NPM 1.4.1 support was not complete in MXG 9.3.       
  VMACNETP  9.118  Support for NET-PASS user SMF record.                
  VMACNSM   9.194  Support for NOMAD's Session Manager record.          
  VMACNSPY  9.033  STOPOVER protection for invalid records.             
  VMACNSPY  9.044  STOPOVER with NETSPY Accounting record.              
  VMACNSPY  9.045  NETSPY Accounting subtype caused STOPOVER.           
  VMACNSPY  9.165  LEGENT's LANSPY component of NETSPY additions.       
  VMACOMCI  9.147  Omegamon V550 User SMF record                        
  VMACOPCA  9.224  IBM's OPC/A Job Tracking and Audit Trail Log.        
  VMACRMDS  9.139  RMDS records RMDSORG='D' STOPOVER corrected.         
  VMACSMF   9.094  New message at end of SMF processing on log          
  VMACSNAP  9.167  Codework Software's SNAPAD-MVS user SMF record       
  VMACSPMS  9.088  Support for Amdahl's SPMS Release 1.2 SMF record     
  VMACTAO   9.018  Support for Fischer's Totally Automated Office TAO.  
  VMACTAO   9.200  Support for Emc2/TAO Release 3.3.0.                  
  VMACTMS5  9.016  Support for CA-1 (TMS) Release 5 complete rewrite.   
  VMACTMS5  9.057  Missing semicolons.                                  
  VMACTMVS  9.142  TMON/MVS spanned record STOPOVER circumvented        
  VMACUCB   9.002  3490E cartridge tape now recognized.                 
  VMACVMXA  8.296  VM/XA used more work space than really required.     
  VMACVMXA  9.096  LOGICAL RECORD SPANS message corrected               
  VMAC102   9.178  IBM incompatible change to IFCID 140, 141 in 2.3     
  VMAC110   8.292  Unexpected Statistics Subtype due to Boole CICSMGR.  
  VMAC110   9.051  Support for Shared Medical Systems CICS modifications
  VMAC110   9.062  Support for CICS/ESA 3.2.1.                          
  VMAC110   9.084  CICS PCLOADCN has different meaning.                 
  VMAC23    9.134  New fields were not input.                           
  VMAC28    9.061  Support for NetView Performance Monitor NPM 1.4.1.   
  VMAC28    9.214  Support for NPM Release 1.5.                         
  VMAC30    9.001  INVALID DATA FOR SMF30ASO with MVS/ESA 4.2 eliminated
  VMAC30    9.085  STCs starting with A confused APPC logic.            
  VMAC30    9.134  Support for MVS/ESA 4.2.2.                           
  VMAC42    9.048  Circumvention of IBM DFP 3990 Cache type 42 errors.  
  VMAC57    9.010  Invalid ESS Section message due to IBM error.        
  VMAC6     9.083  OUTDEVCE changes affect PRINTLNE, EXTWTRLN           
  VMAC6     9.154  LEGENT's Bundle product caused type 6 stopover       
  VMAC6156  9.046  TYPE6156 variables ACTION, FUNCTION not valid.       
  VMAC7072  9.001  INVALID DATA FOR IOCRFC with MVS/ESA 4.2 eliminated. 
  VMAC7072  9.054  MXG 9.1 only, Change 9.001 incompletely installed.   
  VMAC7072  9.070  TYPE72 CPUHPTTM,CPUIIPTM,CPURCTTM wrong in MVS 4.2   
  VMAC7072  9.072  TYPE70PR LCPUADDRs 2 and 3 wrong if DEDICATED CPU    
  VMAC7072  9.119  ACF2 STOPOVER due to bad record length corrected.    
  VMAC7072  9.120  ESA CPU times HPT/IIP/RCT wrong by 2%.               
  VMAC73    9.001  INVALID DATA FOR IODFDATE in MVS/ESA 4.2 eliminated. 
  VMAC74    9.001  First STOPOVER with MVS/ESA 4.2 data corrected.      
  VMAC74    9.039  Second STOPOVER with MVS/ESA 4.2 data corrected.     
  VMAC78    9.055  STOPOVER with MVS/ESA 4.2 data corrected.            
  VMAC78CU  9.047  Missing fields due to IBM microcode errors.          
  VMAC79    9.007  Support for (archaic?) RMF 3.5.1 type 79 records.    
  VMAC90    9.134  Support for MVS/ESA 4.2.2 added new subtypes.        
  VMXGHSM   9.009  HSM MCD data can cause STOPOVER.                     
  VMXGVPD   9.158  STOPOVER with VPD record type "E".                   
  VMXGVTOC  9.159  VTOC data beyond 3rd extent lost since MXG 7.2.      
  VMXGVTOF  9.035  SAS 5.18 only, did not read all extents.             
  VMXGVTOF  9.040  First Extent on each volume lost.      .             
  VMXGVTOF  9.159  VTOC data beyond 3rd extent lost since MXG 7.2.      
  WEEKBLD   9.050  Submitting job may need DCB on INTRDR DDNAME.        
  XMAC74    9.054  MXG 9.1 only, Change 9.001 incompletely installed    
Inverse chronological list of all Changes:                              
NEXTCHANGE: Version  9                                                72
Change 09.245  Yet another IMS idiosyncracy was discovered after MXG 9.8
TYPEIMS       and corrected by this contributor.  For Message Switching,
Feb 20, 1992  each transaction in a single logical business task has the
              same ARRVTIME (i.e., the arrival time of the first of the 
              group).  Since RESPONSE time is calculated from ARRVTIME  
              to ENDTIME, this caused the calculated response time for  
              Message Switched transactions to be overstated. Russell   
              tried to use SEQNO and NMSGSW to identify each group of   
              transactions, but that algorithm did not always uniquely  
              identify a group, and IBM was unwilling/unable to provide 
              technical validity of those fields.  Thus the solution was
              to sequence the IMSTRAN dataset and then, after the fact, 
              recognize (using the LAG function) and correct the        
              ARRVTIME of subsequent Message Switched transactions.     
   Thanks to Russell Dewar, NM Computer Services Pty., AUSTRALIA.       
Change 09.244  The "Prudential Writer" program is a "freebie" for Xerox 
VMAC6         9700 forms management, which writes a type 6 SMF external 
Feb 19, 1992  writer record.  Unfortunately, the READTIME value put in  
              the SMF record is not READTIME but JCNVTIME, and thus this
              type 6 record cannot be matched with the other SMF records
              written by the same job!  There is presently no fix, but  
              their error was only discovered today!  If you use this   
              program, call/fax us for a status update.                 
   Thanks to David Ehresman, Univerity of Louisville, USA.              
Change 09.243  JES2 SPOOL Transfer Program can cause real purge records 
BUILDPDB      to be mis-recognized by BUILDPDB and sent to PDB.NJEPURGE.
Feb 19, 1992  Change 7.008 discussed the MXG logic added to process the 
              multiple purge records that are created when a job is     
              offloaded before execution and then later reloaded for its
              execution. The SPOOL transfer purge record was recognized 
              because DEVNAME begins with 'OFF', and was sent to the    
              PDB.NJEPURGE, since it is not the true job purge record.  
              However, it is possible to offload a copy of a job using  
              SPOOL transfer, but not delete that job from spool. (Sites
              specify DISP=KEEP on the JESPARMS OFFLOAD statement to    
              make a backup copy of the spool before system maintenance,
              but only reload if a failure occurred during testing).    
              The offload does not create a purge record, but the actual
              job purge record now contains DEVNAME=OFF1.JT1 (I guess,  
              so you know the job had been previously copied to spool?).
              This caused MXG to send this "real" purge record to the   
              PDB.NJEPURGE, and the job's other records sat in the SPIN 
              file waiting on the nonexistent purge record until SPINCNT
              was exceeded, when the job was finally output to PDB.JOBS.
              This change modifies the test for DEVNAME=:'OFF' and is   
               (DEVNAME=:'OFF' AND JPURTIME LT JSTRTIME) so that only   
              the unwanted SPOOL transfer purge record is excluded from 
              BUILDPDB processing, by comparing the purge record time   
              with the job start time.                                  
   Thanks to David Ehresman, Univerity of Louisville, USA.              
Change 09.242  PR/SM variable NRPRCS is the number of partitions, butthe
VMAC7072      pseudo-partition named PHYSICAL added by APAR was also    
Feb 18, 1992  being counted. Now it is subtracted out from NRPRCS.      
   Thanks to Tim Follen, Blue Cross Blue Shield of Ohio, USA.           
Change 09.241  A DB2ACCT dataset with 250,000 obs requires 5,000 tracks.
ANALDB2R      A DB2 Accounting Summary report needed 10,000 tracks of   
Feb 17, 1992  work space (twice the 5,000 tracks because at the end of  
              the sort phase both the input and output datasets exist), 
              because ANALDB2R unwisely kept all 221 DB2ACCT variables! 
              Now, only the 43 variables needed for the Summary report  
              are kept, and only 1800 tracks are now required!  A change
              in 9.7 that required yet another copy of DB2ACCT in the   
              work file was also eliminated in this re-design.          
   Thanks to Neil Ervin, Huntington Bank Service Company, USA.          
Change 09.240  The IRG (inter-record gap) calculation used to estimate  
              feet of tape should have been IF IRG LT 38000 THEN ....   
VMACTMS5      instead of NE (VMACTMS) or LE (VMACTMS5).  The 3480 tape  
Feb 17, 1992  length was correct, but 3490s calculated too long!        
   Thanks to Sam Sheinfeld, Kraft General Foods, USA.                   
Change 09.239  Under MVS/370, SAS 6.06 can execute BUILDPDB, but it has 
BUILDPDB      required these changes.                                   
Feb 17, 1992  1. CICS processing must be moved from BUILDPDB to a second
              step.  In member BUILDPDB, you will have to comment out   
              the _VAR110 and _CDE110 lines, the lines which PROC SORT  
              datasets starting with CIC....., and %INCLUDEs for members
              starting with CIC.....                                    
              2. Set MEMSIZE=6M, a Region size of 6M, and insert an     
              OPTIONS BLKSIZE=2048; preceding the %INCLUDE of  BUILDPDB.
              3. If you need to process the type 110 CICS SMF records,  
              you should use IMACEXIT to select ID=110 and write them   
              to SMFTEMP the BUILDPDB step, then use a second step to   
              execute %INCLUDE SOURCLIB(TYPE110), with the SMF DDname in
              this second step pointing to the temporary dataset name   
              you used on the SMFTEMP DDname in the BUILDPDB step.      
              4. Again, all of this flailing around is necessary ONLY if
              you are trying to execute SAS 6.06/6.07 under MVS/370.  If
              you have MVS/XA or MVS/ESA, you need none of the above!   
   Thanks to Darrell Allen, Special Metals, USA.                        
Change 09.238  SMS fields (Data Class, Storage Class, Management Class) 
VMXGHSM       plus SMS-related flag, VSAM organization and last update  
Feb 18, 1992  datetimestamp were added to the three MCD datasets created
              from the Migration Control Data Set.                      
   Thanks to John E. Schultz, First National Bank of Maryland, USA.     
Change 09.237  Reserved Change Number.                                  
Change 09.236  Support for BEI Systems PDQ/PAGE SMF record creates four 
EXPDQAMJ      datasets:                                                 
EXPDQAMO        PDQAMON  - Auxilliary Storage by performance group      
EXPDQEMJ        PDQAMONJ - Auxilliary Storage by job (ASID)             
EXPDQEMO        PDQEMON  - Expanded Storage by performance group        
IMACPDQ         PDQEMONJ - Expanded Storage by job (ASID).              
TYPEPDQ         This vendor contribution has only been syntax checked.  
Feb 14, 1992                                                            
   Thanks to Bill Ek, BEI Systems, USA.                                 
---Changes thru 9.235 were printed in MXG Newsletter TWENTY-ONE-----    
Change 09.235   Support for Boole and Babbage IMF 2.7 is provided in MXG
TYPECIMS        (it was easy - there was no change in the IMF log record
Feb 12, 1992    format since IMF 2.6!)                                  
Change 09.234   RMFINTRV memory variables ending in MEMR were incorrect.
RMFINTRV        Instead of the total memory (bytes) for the workload,   
Feb 12, 1992    they contained the per-user bytes for the workload, and 
                variable TOTMEMR contained frames instead of bytes! The 
                MEMR variables should have been divided by DURATM and   
                not the RESD variables, and TOTMEMR should have been    
                multiplied by 4096 to convert frames to bytes.          
   Thanks to Shirley Rementer, Atlantic Electric, USA.                  
Change 09.233   NETSPY variable LRSPNET normally contains the response  
VMACNSPY        time of the last transaction, but a new variable exists,
Feb 12, 1992    LRSPNETV='Y', to flag that the LRSPNET value contains   
                the calculated average response for the interval.  This 
                is particularly important for LU 6.2 and APPC sessions, 
                where only the calculated LRSPNET is available.  Labels 
                for LRSPNET and LRSPHOST should have indicated "LAST".  
   Thanks to Marty Quinlan, Virginia Power, USA.                        
Change 09.232  Sample tape error report enhanced with a report by device
ANALESV        type added, allowing comparisons of errors by different  
Feb 10, 1992   types of tapes and drives in your tape pool.             
Change 09.231  Revised documentation of DB2 reporting using ANALDB2R,   
DOCDB2PM       ANALDBTR, and READDB2 members adds new reports and DB2   
Feb 10, 1992   2.3 considerations.                                      
Change 09.230   Major enhancements were made to correct a known bug and 
GRAFTRND        add an additional set of graphs. If you had more than   
Feb 10, 1992    18 months of data in your TRNDRMFI dataset, some of the 
                graphs (Avg vs Max CPU Busy and All Workload Bar charts)
                could not be produced because the x axis could not be   
                fit on most graphics devices. The best circumvention    
                would have been to use PROC GPLOT and AREA fill but this
                proved impractical because if AREAS=16 is specified and 
                only 5 workloads are present, the entire area of the    
                graph is filled with the pattern for workload 5. This is
                clearly not what you (or we) wanted. Until this is fixed
                (if ever) the workload bar charts will be limited to the
                past 65 weeks. Why 65? It appears to be the least common
                denominator for most graphic devices. 65 bars fit on all
                of the devices we have tried. The data to be retained   
                is constructed based on the data in your TRNDRMFI data. 
                An MXGNOTE is produced detailing the range of dates in  
                your TRNDRMFI dataset and, if too much data is present, 
                MXGWARNINGs are produced outlining the error condition  
                and what will be done to circumvent the problem. There  
                will be notes on the SAS LOG that some observations were
                missing or out of range. This is normal. When data is   
                being projected, the actual CPU is missing. The use     
                of PROC GLM to project using linear regression has been 
                extended to the workload level (only if you have the    
                SAS/STAT product.) These graphs are identical to the    
                current workload graphs except that they carry workloads
                forward into the future the number of weeks specified by
                WEEKSOUT parameter. As with the other workload charts,  
                only 65 weeks are charted. If a workload is shrinking,  
                at the point in time at which it reaches zero or goes   
                negative, it will be set to missing.                    
Change 09.229  Support for Memorex Telex Library Management Software    
EXLMSADO       Performance Monitor (LMS/PM), a significant contribution 
EXLMSAIN       written by Dan Kaberon of Hewitt Associates, was provided
EXLMSALD       to MXG users by Memorex Telex.  Not only did Dan write   
EXLMSATL       this code in MXG style, he also provided Chapter 40 style
EXLMSCHG       MXG documentation, which you will find in ADOCLMS.       
EXLMSCIN       Seventeen datasets are created from the twenty subtypes  
EXLMSEJE       of the LMS SMF record.  See ADOCLMS for more information.
EXLMSENT         LMSXX     LMS SUBTYPE INVENTORY                        
EXLMSMOU         LMSEVENT  LMS SUBTYPES 5,13-15: ATL EVENT              
EXLMSSDO         LMSATLI   LMS SUBTYPES 10: ATL INIT                    
TYPELMS          LMSMOUNT  LMS SUBTYPE 21: ATL MOUNT                    
Feb 10, 1992     LMSUNLD   LMS SUBTYPE 24: UNLOAD                       
                 LMSCINIT  LMS SUBTYPE 25: CART INITIALIZED             
                 LMSLINT   LMS SUBTYPE 30: INTERVAL                     
                 LMSAINT   LMS SUBTYPE 31: ATL INTERVAL                 
Change 09.228  DCOLLECT's space calculation for dataset size (DCDALLSP  
VMACDCOL       in dataset DCOLDSET) is wrong; the total allocated space 
Feb 10, 1992   in the dataset records can exceed the allocated space in 
               the volume record, because IBM uses the wrong track size 
               in computing the size of the dataset.  The unformatted   
               track capacity is used, instead of the formatted track   
               size.  Changes 9.180 and 9.144 discuss APAR OY36364 which
               corrected the track size used in DCOLLECT volume records,
               but the correction was not applied to the dataset record.
               APAR OY48920 discusses DCDALLSP for 3390s, but it is not 
               clear if that APAR recognizes the other fields that are  
               wrong, nor if the fix (when a PTF exists) will apply to  
               both 3380s and 3390s.  Check the status of that APAR.    
   Thanks to Terry Duchow, Minnesota Mutual Life, USA.                  
Change 09.227  CICS Exception variables MSWAITCN and TSWAITCN should be 
VMAC110        missing, as these values existed only under CICS 1.6. The
Feb 10, 1992   label for MSREQWT now correctly indicates it is the bytes
               of main storage acquired only after waiting.             
   Thanks to Paul Masters, Blue Cross and Blue Shield of Texas, USA.    
Change 09.226  WSF timestamp ACCLOGON was incorrectly input as PD4.2; it
FORMATS        needed to be input as HH PK1. MM PK1. SS PD2.1.  Variable
VMACWSF        AUDACT was incorrectly input as $CHAR1. when it should be
Feb 10, 1992   input PIB2.  It is removed from the LENGTH statement, and
               it is now formatted with MGWSFAC (a new numeric format). 
   Thanks to Douglas Clarke, General Accident, ENGLAND.                 
Change 09.225  Revised JCL for MONTHBLD requires only ONE tape drive,   
JCLMNTH        eliminates many tape mounts (especially if your weekly   
Feb  6, 1992   PDBs are multi-volume), and significantly reduces the run
               time of the monthly PDB build job.  The revision copies  
               each of the weekly PDBs from tape to temporary DASD (and 
               selects only the datasets you intend to build monthly),  
               and then uses those temporary DASD files as input instead
               of spinning input tapes back to the beginning of the tape
               for each input dataset to be read.  The output monthly   
               PDB is written to tape, on the same drive used to copy   
               the weekly datasets.  As long as you have enough temp    
               DASD space for the job, this is a much better and faster 
               method of building your monthly PDB.  The revised JCL is 
               in member JCLMNTH, but the existing member JCLMONTH was  
               left in the library as well.                             
Change 09.224  Support for IBM's Production Control System OPC/A Job    
EXOPC03        Tracking and Audit Trail Log Records.  Twelve datasets   
EXOPC20        are created from the standard IBM log records:           
EXOPC23           OPCA20   JT STARTED EVENT                             
EXOPC24a          OPCA23   OPERATION EVENT                              
EXOPC24n          OPCA24   MCP EVENT                                    
EXOPC25           OPCA25   SUBMIT EVENT                                 
EXOPC26           OPCA26   AUTO RECOVERY                                
EXOPC27           OPCA27   MISSED FEEDBACK RECORD                       
EXOPC28           OPCA28   FEEDBACK RECORD                              
EXOPC29           OPCA29   AUTO-TRACKED EVENT                           
EXOPC30           OPCA30   SPECIAL RESOURCE EVENT                       
EXOPC31           OPCA31   ETT TAB FILE MAINTENANCE EVENT               
EXOPC32           OPCA32   AUDIT TRAIL LOG RECORD                       
EXOPC33           OPCA33   MESSAGE LOG RECORD                           
EXOPC34        In addition, four user datasets for user log records are 
EXOPC35        defined, OPCA00-OPCA03, for sites which write additional 
VMACOPC        data records to the log.                                 
Feb  5, 1992                                                            
   Thanks to Wolfgang Vierling, Vereinte Versicherungen, GERMANY.       
Change 09.223  Support for Infomation Builder's FOCUS Multi-Session     
EXFOCMSO       Option accounting SMF record.  One dataset is created:   
IMACFOCU          FOCUSMSO FOCUS MSO Accounting                         
TYPEFOCU       This record provides CPU and EXCP resources and duration 
VMACFOCU       of session for accounting, in Release 6.5 Level 6 at PUT 
Feb  5, 1992   9109.  Technical Memo 7857.1 describes the contents.     
   Thanks to Mike Boyce, Anderson Consulting, USA.                      
Change 09.222  A vendor's type 39 record was truncated after 46 bytes,  
Feb  5, 1992   now checks for complete header before INPUTing record,   
               and prints message and dumps record on SAS log instead of
               failing with a STOPOVER abend.                           
   Thanks to Connie Wilson, AMR Travel, USA.                            
Change 09.221  An archaic and confusing comment at the end of this      
IMACFILE       member was removed.                                      
Feb  5, 1992                                                            
   Thanks to Connie Wilson, AMR Travel, USA.                            
Change 09.220  DCOLLECT Migration and Backup datasets have new variables
VMACDCOL       UMFLAG1/UBFLAG1 and UMDSORG/UBDSORG.  Variables added by 
Feb  4, 1992   APAR OY37378 to the Migration dataset were also added to 
               the Backup record, but were overlooked by MXG until this 
               change.  (Since on one noticed their absence, they must  
               not be very important, but they are now decoded!)        
   Thanks to Joseph J. Faska, Depository Trust, USA.                    
Change 09.219  Minor typo (which caused no execution error). At line 164
VMACSPMS       change the three @113's to @113, @115, and @116.         
Feb  4, 1992                                                            
   Thanks to John Chapman, British Gas, ENGLAND.                        
=======Changes thru 9.218 were included in MXG PreRelease 9.8 ==========
Change 09.218  Preliminary sample code for processing Amdahl's APAF data
IMACAPAF       from MVS or VM data was provided by Amdahl.  This code is
TYPEAPAF       not in the style of MXG, and may be revised to conform to
Feb  2, 1992   MXG architecture, but it arrived in time to save you the 
               effort of writing it yourself when you install APAF.     
Change 09.217  IMS Multi-Trans with only 03/35/31 sequence didn't always
TYPEIMS        have accurate SERVICTM and RESPNSTM, whenever the same   
Feb  2, 1992   MSGDRRN was reused at a later time for the same ODEST.   
               First, the INPUT and OUTPUT datasets contained blank     
               values for DTOKEN (because, from IBM, not all log        
               records contain a token), and second, the 31I record was 
               not used to create pseudo 31O and 35O records containing 
               DTOKEN to correct the INPUT/OUTPUT datasets.  Now, 31I   
               records create both 31O and 35O records so DTOKEN exists,
               and just to be sure, INPUT/OUTPUT observations without a 
               DTOKEN are now deleted before the final merge.  Like all 
               scotch tape and chewing gum fixes to IMS log processing, 
               I hope this is the last one, and pray that IBM will soon 
               replace IMS with DB2, since IBM refuses to enhance the   
               IMS log with discrete transaction resource data.         
   Thanks to Lynn Delacourt, Volvo Heavy Truck Corporation, USA.        
Change 09.216  IMS 3.1 records contain duplicate values of DLRTOKEN, the
TYPEIMS        key that is used to match log records together.  The new 
Feb  2, 1992   "Quick Reschedule" event creates multiple type 07/08 log 
               records to be created with the same value of DTOKEN, one 
               pair for each Reschedule.  Because MXG expected only one 
               pair for each DTOKEN value, MXG's IMSTRAN dataset will be
               incorrect (generally overreporting IMSCPUTM, DL/I calls, 
               etc.) without this change.  Now, MXG OUTPUTs the first 08
               record (the initial program schedule event), totals the  
               resources in the subsequent multiple 07 records, and then
               OUTPUTs the final 07 record of the set with same DTOKEN. 
               A "Quick Reschedule" occurs when a message region has run
               its maximum number of transactions per program schedule, 
               finds there are more transactions to execute, AND finds  
               there is no other program waiting on this message region.
               Each 08/07 pair contains the resources consumed by all of
               the transactions executed by that schedule, and it has   
               never been possible to measure the resources used by an  
               individual "multi-sked" transaction; the best we could   
               ever do was to divide the total resources by the number  
               of transactions executed during each program schedule.   
               Now, that "average" resource per transaction is even more
               meaningless, since these multiple schedule records now   
               have to be summed and divided by a larger total number of
               transactions.  It would have made much more sense, and we
               would not have lost ground in resource measurement, if   
               IBM had been wise enough to create a new DTOKEN value for
               each Quick Reschedule.                                   
               Added 1999: Variable SCHEDULE in dataset IMSTRAN flags if
               the obs was the scheduled or the rescheduled event.      
   Thanks to J. Cary Jones, Philip Morris, USA.                         
Change 09.215  BUILDPD3 (JES3 only) enhancement added in MXG 9.5 had two
BUIL3518       occurrences of 26J2 which should have been 26J3 in both  
BUIL3606       of these JES3 members.                                   
Jan 31, 1992                                                            
   Thanks to Paul Oliver, BHP Information Technology, AUSTRALIA         
   Thanks to Steve Cavill, SAS Institute, AUSTRALIA                     
Change 09.214  Support for NPM Release 1.5 added seven new datasets:    
EX028CM6        NPMCMEXE - Execute commands                             
EX028LA1        NPMLANAT - LAN Bridge Attach/Detach                     
EX028LA2        NPMLANCO - LAN Manager Connect/Disconnect               
EX028LA3        NPMLANEX - LAN Bridge Monitor Exception/Resolution      
EX028LA4        NPMLANIN - LAN Bridge Interval Resources                
EX028LA5        NPMLANST - LAN Start/Stop/Alter Collection              
EX028NCP        NPMNCPCH - NCP Add/Replace/Delete                       
FORMATS        and some new fields and bit values were added to existing
VMAC28         datasets.  IBM publication, "Netview Performance Monitor 
Jan 31, 1992   Reports and Record Formats Release 5", SC31-6147-0 is the
               new documentation for all of the data records created by 
               this new release.  Thanks again to IBM's excellent vendor
               support, documentation was made available in sufficient  
               time to include support for this significant release in  
               MXG's production version.  Unfortunately, no data records
               from the new release were provided for testing, so caveat
Change 09.213  Minor cosmetic change to recognize upper or lower case   
READDB2        value for "ALL", and to relocate the %INCLUDE until after
Jan 29, 1992   requests have been parsed for efficiency.                
==Changes thru 9.212 were included in MXG PreRelease 9.7==============  
Change 09.212  Additional pairing logic for SQL trace report IFCID pairs
ANALDBTR       were added for DB2 2.3 IFCIDs 170-171,173-176,178-179,and
VMAC102        183, and these IFCIDs are now decoded in VMAC102.        
Jan 27, 1992                                                            
Change 09.211  Sites that execute BUILDPDB only six days per week will  
MONTHBLD       need to locally modify MONTHBLD, as it expects seven day 
Jan 27, 1992   per week possible execution.  One line in MONTHBLD,      
               (line 003400, DAY=UPCASE(PUT(TODAY,WEEKDATE3.)); ) was   
               moved to immediately after line 002100, as this creates  
               the variable DAY containing the name of the day of week. 
               With that permanent MXG change in place, the changes you 
               need to tailor in you own sites copy of MONTHBLD are more
               compact and logically clearer.  There are two changes to 
               be made by you:                                          
               a.  Change  IF DAY(TODAY) NE 1 THEN DO; to read          
                  IF DAY(TODAY) NE 1 AND                                
                    (DAY(TODAY) NE 2 AND DAY NE 'MON') THEN DO;         
                   This permits MONTHBLD to execute either on the first 
                   day of the month, or on the second day of the month  
                   if the first day fell on Sunday (the day you do not  
                   execute BUILDPDB).                                   
               b.  Insert after LASTDAY=TODAY-1;  the statement         
                   IF DAY(TODAY) EQ 2 THEN LASTDAY=LASTDAY-1;           
                   This causes LASTDAY to contain the date of the last  
                   day of the last month, which is then used to set the 
                   _BEGIN macro value for date selection.  Note that as 
                   the _END macro value is TODAY, the selection values  
                   will now be correct whether you execute on the first 
                   of the month or on Monday the second day.            
   Thanks to Phyllis Reedyk, Witco Corporation, USA.                    
Change 09.210  Continued enhancement of DB2 reporting added SQL trace   
ANALDB2R       reports, and many additional internal enhancements:      
Jan 26, 1992 1.All WARNING or NOTE messages printed on the log by MXG   
               now print as MXGWARN or MXGNOTE to clarify their source. 
             2.Internal macros are now documented with update date.     
             3.All uses of VMXGSUM use the INVOKEBY parameter to message
               which report is being generated ("PMACC01 - ANALDB2R").  
             4.Selection was consolidated into DB2RSELA macro.          
             5.DB2DBID macro uses T102S105 and T102S107 (IFCID 105,107) 
               to build a temporary format which maps hex DATABASE and  
               PAGESET values to their actual names.  Under SAS 5.18,   
               the INSTREAM DD pointing to temporary sequential space   
               is required, but under SAS 6.06+, the CNTLIN option of   
               PROC FORMATS is used to create formats directly from SAS 
             6.Reports now check for the existence of required datasets 
               (as opposed to just zero observations) and messages now  
               indicate why reports were not produced.                  
             7.PDB=SMF option (produce DB2 reports directly from SMF)   
               cannot be used under SAS 5.18 (compiler limit) in a 7MB  
               region.  Messages now tell you how to use READDB2 plus   
               ANALDB2R instead of PDB=SMF to produce almost all reports
               directly from SMF if you are still using SAS 5.18.       
Change 09.209  DB2 Trending was not adequately tested.  In the second   
TRNDDB2A       and subsequent week's processing, old data was not even  
TRNDDB2S       carried forward, and timestamps were not set correctly.  
Jan 26, 1992                                                            
   Thanks to Dave Leeker, Southwestern Bell, USA.                       
Change 09.208  New ESA 4.2 variables R79AIMPL and R79AOMPL have been now
VMAC79         added to the TYPE79A (subtype 10) dataset for the target 
Jan 24, 1992   IN and OUT MPLs respectively.                            
   Thanks to Diane Eppestine, Southwestern Bell, USA.                   
Change 09.207  Variable RDRTM in TYPE30 was always missing after Change 
VMAC30         9.102 because the test in line 075198 should also have   
Jan 24, 1992   tested for SUBTYPE NE 1 to detect the MULTIDD condition. 
   Thanks to Don Friesen, B.C. Systems, CANADA.                         
Change 09.206  Variable EXCMNTYP in dataset CICSEXCE (CICS Exceptions)  
FORMATS        did not describe the exception type because it was kept  
VMAC110        in one byte instead of two.  In the LENGTH statement, it 
Jan 24, 1992   must be $2. instead of $1.  Additionally, the $MG110EX   
               format in member FORMATS should have been '01X:' instead 
               of the obvious typographical error '02X:'                
   Thanks to Bill Hess, Belk Stores, USA.                               
Change 09.205  This code referenced formats $TABSYS and $FORHEX that are
ANALRACF       not in the member. $TABSYS has been replaced by $4., and 
Jan 14, 1992   $FORHEX (which converted hex strings to numerics) was    
               replaced an equivalent algorithm.                        
   Thanks to ???, Alm. Brand, DENMARK.                                  
Change 09.204  Dataset RMF72D NOT SORTED message can result if IMACRMFI 
RMFINTRV       has been used to re-define the startime of your RMF data,
Jan 14, 1992   since STARTIME is both being changed and in the BY list. 
               immediately before the PROC MEANS NOPRINT DATA=RMF72D;   
               to ensure that RMF72D is always sorted.                  
   Thanks to Bill Stoneberg, National-Oilwell, USA.                     
Change 09.203  CA7 corruption of TSO/MON READTIME was only partially    
VMACTSOM       corrected in MXG 8.8 by Change 8.209.  That change should
Jan 14, 1992   have also been applied to the second correction of the   
               CA7 corruption, lines 076500 and 076800.                 
   Thanks to Paul Hill, Midland Bank, ENGLAND.                          
Change 09.202  Preliminary support for JES3 Monitoring Facility (JMF)   
FORMATS        type 84 SMF record.  There are nine subtypes, and only   
TYPE84         subtype 5 has been addressed thus far, and not even all  
VMAC84         of the sub-subtypes are yet coded.  This change will     
Jan 13, 1992   extend over time.                                        
   Thanks to Jonathan E. Paley, Massachussets Mutual, USA.              
Change 09.201  A cosmetic change.  Variable RECNR should have been      
VMAC6156       RECNR156 in line 013400.                                 
Jan 13, 1992                                                            
   Thanks to James F. Cook, CocaCola Company, USA.                      
Change 09.200  Support for Emc2/TAO (Fischers Totally Automated Office) 
FORMATS        Release 3.3.0 SMF record.  The new release switched the  
VMACTAO        database reads and writes, but was otherwise implemented 
Jan 12, 1992   compatibly.  This support also added format MGTAOTC and  
               decoded three bitstrings into new variables.             
   Thanks to Joe Aldrich, Army and Air Force Exchange Service, USA.     
Change 09.199  This member creates reports for use at IBM's SNAP/SHOT.  
ANALSNAP       The SNAP/SHOT report is created from MXG's TYPE30_5 data.
Jan 11, 1992   A DASD farm report was created from DMS DSINDEX report.  
               A report from CA-11 (JEHF Version 2) was developed.      
               Mantissa run tracking file formats for RMS/BASIC are     
               provided, and the TMC file was used for tapes (MXG's     
               TYPETMS separately processes that data).  These reports  
               could save you lots of time if you plan to model your    
               workload with SNAP/SHOT (and look at TYPETPNS which will 
               analyze the TPNS log produced by SNAP/SHOT!)             
   Thanks to John Leath, Fleet Real Estate Funding, USA.                
Change 09.198  IMS Fastpath transactions are now supported, thanks for  
TYPEIMS        the diligent research of the three authors of this very  
VMACIMS        significant contribution.  VMACIMS now creates temporary 
VMACIMS        datasets IMS5901,03,36,37, and 38 from those subtypes of 
Jan 11, 1992   the 59x log record, and TYPEIMS has additional logic at  
               the end to sort and combine these to create the IMSFASTP 
               fastpath dataset (and IMS5838 with syncpoint failures.   
               Not only has this code been in production (IMS 2.2 & 3.2)
               for over a year, its output has been validated with IBM's
               DBFULTA0, and these author's comments in member TYPEIMS  
               are an excellent mini-tutorial on IMS Fastpath.          
                 (Usually ANY activity in IMS makes my stomach hurt, as 
                  there just isn't any documentation or help from IBM.  
                  This contribution was done so well that my stomach    
                  feels like it just received a piece of cake!  Thanks!)
   Thanks to Lars-Olof Thellenberg, Forsta Sparbanken, SWEDEN           
   Thanks to Goran Zebuhr, Forsta Sparbanken, SWEDEN                    
   Thanks to Sven Agrell, Forsta Sparbanken, SWEDEN                     
Change 09.197  A sample report using TYPE30_4, TYPE30_5, and TYPE30_D   
ANAL30DD       datasets to report on all your active ddnames by job.    
Jan 10, 1992   The comments in the member describe how to use ANAL30DD. 
   Thanks to Phil Mason, ANZ Bank, AUSTRALIA                            
Change 09.196  Support for LLA exits CSVLLIX1 and CSVLLIX2 are added in 
ANALLLA        this significant user contribution.  Member ASMLLA is the
ASMLLA         ASM source for the two exits that will capture LLA module
IMACLLA        accesses and create a user SMF record.  Members IMACLLA, 
EXLLAEX1       EXLLAEX1,TYPELLA, and VMACLLA are the MXG members to read
TYPELLA        those SMF records and create dataset LLAEXIT.  The final 
VMACLLA        member, ANALLLA, provides some sample reports on LLA.  Be
Jan 10, 1992   very careful as these exits can create many SMF records! 
   Thanks to Ken Williams, ANZ Bank, AUSTRALIA                          
   Thanks to Peter Beer, Amdahl AUSTRALIA                               
Change 09.195  SAS can write zero-length VB or VBS records to a FILE    
IMACFILE       statement, and files containing zero-length records may  
VMACSMF        cause other programs (specifically, DFSORT) to fail. The 
Jan 10, 1992   problem was precipitated by MXG's change in VMACSMF to   
Feb  9, 1992   PUT a new message to the SAS LOG telling you how many    
               megabytes of SMF data had been read.  In that message    
               there is  //  (two skip to the next line on the log).    
               The site had used IMACFILE to write selected SMF records 
               to an external file using    FILE SMFOUT; PUT _INFILE_;  
               The SAS log showed "minimum record length 0" to SMFOUT!  
               The FILE SMFOUT had changed the destination for all PUTs 
               from the LOG to SMFOUT, causing the MXG message and its  
               // to be written as a length zero record to SMFOUT!      
               The real error was in not recognizing that any FILE      
               statement changed the destination for all subsequent PUT 
               statements, and the moral therefore is to ALWAYS follow  
               any FILE/PUT statement that you add to MXG with a FILE   
               LOG statement to reset the destination for PUTs. The real
               error was MXG's failure to reset the log in VMACSMF; that
               has been done. Change 9.087 originally discussed the need
               for the FILE LOG; statement, and the new "megabytes" note
               was added by Change 9.094.                               
   Thanks to Keith Stout, City of Anchorage, USA.                       
Change 09.194  Support for NOMAD Session Manager SMF record is added by 
EXNSMCON       this significant user contribution.  Three datasets are  
EXNSMPRC       created: NSMCON, NSMPRC, and NSMTRM, and you specify the 
EXNSMTRM       SMF record ID in MXG member IMACNSM.                     
Jan  9, 1992                                                            
   Thanks to David B. Adams, National Life of Vermont, USA.             
Change 09.193  Three occurrences of $CHARZB43. should be $CHARZB44. so  
VMXGHSM        all 44 bytes of the dataset name are captured in the     
Jan  9, 1992   MCDDSN variable.                                         
   Thanks to Ray Dickensheets, Yellow Freight System, USA.              
Change 09.192  User of Amdahl Cache Controllers will thank Dick Sziede  
ADOCSPMS       for his excellent paper "A Look at Cache Performance Data
Jan  9, 1992   for the Amdahl 6100" which is contained in this ADOC.    
               The member is not complete, but his discussion of what's 
               good and what's bad is must reading for SPMS users.      
   Thanks to Richard R. (Dick) Sziede, PRC Inc, USA.                    
Change 09.191  Members ADOCDB2 and ADOC102 completely describe each of  
ADOCDB2        the variables created by VMACDB2 and VMAC102 in DB2ACCT, 
ADOC102        DB2STAT0, DB2STAT1, and all 200 of the T102.... datasets.
ANALDBTR       The variable-level documentation is complete, but there  
FORMATS        is still substantial writing to finish before theses two 
VMACDB2        ADOCs are completed.  It is the process of documentation,
VMACDB2H       however, that uncovers inconsistency in formats, names,  
VMAC102        labels, etc., and that has been completed.  Additionally,
Jan 12, 1992   some datasets that formerly created multiple observations
               per SMF record were revised to create a single obs with  
               multiple variables, so that the SQL trace logic to match 
               begin and end would be more straightforward.  These notes
               identify the highlights of this significant enhancement: 
             1.Variable QWHSIID was added to DB2ACCT/STAT0/1 datasets to
               eventually replace incorrectly spelled QWHSSIID. MXG will
               now use QWHSIID for IFCID variable in 100,101 and 102.   
               Both variables continue to exist in DB2ACCT/DB2STATn for 
               backwards compatibility.                                 
             2.Format MGDB2ID replaced with MGDB2II.                    
             3.DB2 database "Object IDs" (PSID,OBID,DBID,ISOBID) are all
               now consistently $CHAR2 with format $HEX4, and the labels
               are now consistent and accurate.  Seven variables had to 
               be changed from numeric to character: QW0023PD,24PD,25PD,
               44KD,44KP,143PS, and 144PS.                              
             4.SQL statement type exists in two different formats. A one
               byte character value is found in IFCIDS 59-62 and 64-66  
               that is decoded by an expanded MGD062S format.  A four   
               hex digit numeric value is found in 124, 145, and 145    
               IFCIDs that is decoded by an expanded MG145S format.     
             5.Variable QW0032AR should not have existed; QW0032FT is   
               the name of the field (QW0032AR is an EQU value!).       
             6.Variable QW0145TS was changed from numeric to $CHAR8 and 
               formatted $HEX16 so all 'PRECOMPILER*TIME*STAMP' fields  
               (in IFCIDs 53,58,59,60,61,64,65,66)are now character.    
               If I can find out how to decode this timestamp (a hex    
               value of '148CDFEF19AC29AC'X, for example), all these    
               variables will be decoded into numeric datetime values!  
             7.Variable QW0063HL was not kept but should have been, and 
               is formatted by new $MGD063H.                            
             8.Variable QW0063OT is now formatted $HEX2.  The MGD060O   
               format formerly used did not correctly decode the multi  
               valued bit fields, and is no longer used.                
             9.MXG 9.5 created observations for new IFCIDs 126-139 and  
               170-194 even without any 102 records because the OUTPUT  
               statement for these IFCIDs was missing in VMAC102.       
            10.Datasets T102S018,T102S053,and T102S058 formerly had one 
               or two observations per SMF record, one for index and one
               for data.  This change eliminates the second record by   
               putting the data portion counts in QW00.... variables,   
               and by putting the index portion counts in QW0I.... names
               so that pairing these three records with their partners  
               in ANALDBTR can be more easily/accurately accomplished.  
               Variable SDSNUM, a sequence counter, is thus no longer   
               required in these datasets and has been dropped.         
            11.ANALDBTR was revised to pair 044/045 data, to create     
               additional datasets (S018S018 and S058S058) for unpaired 
               ends, and to keep only the first segment of 063 data,    
               all in support of SQL trace reporting.                   
            12.VMAC102 was revised to create single observations for    
               IFCIDs 13,15,and 17. Previously, one observation for each
               predicate was created.  Now, the up-to-ten predicates are
               stored is sets of variables.  The first set is prefixed  
               QW0013, the second set QW0A13, the third QW0B13, etc.    
            13.VMAC102 was revised to create single observations for    
               IFCIDs 58-62 and 64-66; previously they could have one   
               or two observations describing DATA and/or INDEX activity
               due to SQL statements, but now the QW00nn variables have 
               the data activity, while new variables QW0Inn contain the
               index activity.  This made matching begin and end of SQL 
               events much simpler in ANALDBTR.                         
            14.The only IFCIDs that create multiple observations now are
               22 (one miniplan per table per subselect block), 63 (one 
               per each 200 bytes of SQL statement text), 126 (one per  
               each index used to obtain candidate RIDs, up to 16), 145 
               (one per Audit Log Table), 148 (only for distributed     
               allied agents, R8O one per conversation, R9O, one per    
               location), and 191 (one per parse, up to 5).             
            14.VMAC102 and VMACDB2 labels and formats were revised to   
               be consistently spelled, etc.                            
            15.ANALDBTR, the routine which matches pairs of trace data, 
               is now a %MACRO which invokes the old-style _nnnPAIR     
               macros.  This change added flexibility to its use and its
               invocation inside %ANALDB2R reporting.                   
            16.VMACDB2H now creates variable QWHDYES, indicating that   
               there was a distributed header, and which is now used in 
               VMACDB2 to create new variable THREADTY (formatted with  
               $MGDB2TT) to describe the type of thread (Allied, Allied-
               Distributed, DBAT (Database Access) or DBAT-Distributed).
   Thanks to Debby Meister, Loews Corporation, USA.                     
Change 09.190 -CICS 3.2.1 statistics records were not fully supported.  
VMAC110        STID=63 (CICTM) record contains sixteen tables, but only 
Dec 27, 1991   the first twelve were kept by MXG prior to this change.  
               Seven records (that contained only totals) are no longer 
               created by IBM (because they are redundant with their    
               corresponding detail record) and thus these MXG datasets 
               always contain zero observations: CICTST(STID=5),CICTCT  
               CICFCT(68),CICCONMT(77).  (Their detail dataset names    
               are minus the ending "T".)                               
              -IBM added two undocumented bytes in the STID=57 (CICSDS) 
               record, which corrupted the CPU times in CICSDS dataset, 
               and in the CICINTRV, etc., datasets created from it.  The
               two bytes added for alignment (immediately before the    
               repeating DSECT) are not documented in DFHGSGDS.  And in 
               an unrelated change, CICS APAR PN02625 removes two filler
               bytes following DSGNTCB, but did not update the STIVERS  
               version indicator, so there is no direct way to know what
               length record to expect!  As a result, MXG protects for  
               none, two, or four filler/alignment bytes in this record.
              -IBM documentation for statistic record STID=49 is wrong. 
               DSECT DFHA13DS describes STID=49 as containing 39 bytes, 
               but actual data records have STILEN=40; a one-byte field 
               (reserved) following A0013BFC is not described in that   
               DSECT (the only IBM documentation of the record!). IBM   
               will correct their error (eventually) with a doc APAR.   
               How can the record disagree with the DSECT you might ask?
               Because IBM records are built by PL/S DSECTS, but IBM    
               documents with ASM DSECTS that are never actually used!  
              -Two occurrences of broken CICS 3.2.1 records were found  
               with only 80 bytes of data.  MXG new detects the short   
               record, messages to the log, and avoids STOPOVER ABEND.  
   Thanks to Lee F. Johnson, Talbots Systems Center, USA.               
   Thanks to Bruce W. Galle, Talbots Systems Center, USA.               
Change 09.189  Processing VVDSs previously failed with a USER ABEND 666 
ASMVVDS        when ASMVVDS tried to read a VM system volume that was   
Dec 20, 1991   online to MVS (because the volume does not have a normal 
               VTOC/VVDS).  Now, instead of the ABEND, the program puts 
               out a message that the OBTAIN macro failed for that UCB  
               (DEVNR), and then continues to process additional UCBs.  
   Thanks to Chris Taylor, First Wachovia Bank, USA.                    
Change 09.188  VVDS support skipped over VVRTYPE='D5'X because the test 
VMACVVDS       in line 017100 was mistyped as ='D5' instead of ='D5'X.  
Dec 20, 1991                                                            
   Thanks to Chris Taylor, First Wachovia Bank, USA.                    
Change 09.187  Support for ASTEC Version 1.5.  Several new fields were  
VMACDMON       added (incompatibly) to the SMf record.  This support was
Dec 16, 1991   actually shipped in MXG 9.5, but this change was not in  
               member CHANGES of that library.                          
   Thanks to Joseph J. Faska, Depository Trust, USA                     
Change 09.186  VPD type E records caused STOPOVER ABEND because variable
VMACVPD        VPDRSVR2 should have been input as $CHAR11. instead of   
Dec 16, 1991   $CHAR12. (line 014200).                                  
   Thanks to Jim Nicholas, Mead Data Central, USA.                      
Changes thru 9.185 were contained in MXG PreRelease 9.5, Dec 1, 1991    
Change 09.185  Change 9.164 was a major restructuring of ANALDB2R, and  
ANALDB2R       had not been sufficiently tested for all DB2 reports.    
ANALDBTR       Using SAS 6.07 (and reading all of the SAS messages on   
Dec  1, 1991   the log!) not only corrected UNINITIALIZED variables, but
               the 6.07 feature which warns of unreferenced variables in
               the KEEP= list caught a number of mispellings in some of 
               the type 102 trace reports.  SAS 6.07 furthermore found  
               a syntax error that SAS 5.18 had accepted!  This was an  
               another superb contribution from Koln.                   
   Thanks to Siegfried Trantes, Gothaer Versicherungsbank VVAG, GERMANY.
Change 09.184  Several important variables have now been added to the   
EXRMFINT       TYPE70 and RMFINTRV datasets for MVS/ESA and PR/SM data. 
EXTY72       1.If PR/SM data section is found in type 70 (PR/SM, MLPF,  
RMFINTRV       or MDF) records, both the Partition Dispatch (PDTM) and  
VMAC7072       Effective Dispatch (EDTM) are carried into the TYPE70    
Nov 28, 1991   dataset.  MXG continues to calculate PCTCPUBY based on   
Sep 21, 1994   Partition Dispatch Time for consistency, but now provides
               PCTCPUEF, based on Effective Time, which matches the RMF 
               reported "CPU Busy" under PR/SM.  The individual LCPUs   
               times are in new variables CPUPDTM0-8, CPUEDTM0-8, and   
               totals across all LCPUs are in CPUACTTM and CPUEFFTM.    
             2.RMFINTRV was enhanced to provide the three new CPU times 
               (HPT,IIP,RCT) in each set of workload variables and their
               total for each workload.  New variable BATCPU is the sum 
               of existing BATTCB,BATSRB plus BATHPT,BATIIP, and BATRCT.
               Total CPU times are also kept in CPUTM, CPUHPTTM,CPUIIPTM
               and CPURCTTM variables.                                  
               Next paragraph revised in 1994:                          
               ACTFRMTM replaced MSOUNITS as a metric in 1994:          
               Additionally, in each workload, the memory is now        
               calculated (Central+Estore) from ACTFRMTM in bytes in    
               BATMEMR, CICSMEMR, etc. (but recall that ACTFRMTM does   
               not include logically swapped pages nor the nucleus, LPA,
               nor CSA).  This is a much better indicator of memory     
               utilization than AVGMEMSZ, which is based on MSOUNITS as 
               discussed in prior newsletters.  And the total memory of 
               all workload's memory is variable TOTMEMR.               
             3.See the MVS Technical Note on CPURCTTM in Newsletter 21. 
               It is unmodified in the TYPE72 dataset, so you can see   
               how wrong it is, but it is now subtracted from CPUTM in  
               EXTY72 (temporarily, until a PTF exists).  This will     
               prevent negative overhead calculations in RMFINTRV due   
               to the wrong value of CPURCTTM until fixed by IBM.       
Change 09.183  DB2 variable QWHSSTCK is now formatted DATETIME22.3 so as
VMACDB2        to show the milliseconds.  Sites using DB2 trace found   
VMAC102        the increase in printed resolution useful for tracking   
Nov 28, 1991   detail event sequences.                                  
   Thanks to Siegfried Trantes, Gothaer Versicherungsbank VVAG, GERMANY.
Change 09.182  Heavy validation of TYPEIMS from MXG 9.2 uncovered still 
VMACIMS        additional idiosyncrasies and undocumented Enqueue record
TYPEIMS        flags in this significant contribution.  In VMACIMS,     
Nov 28, 1991   35x records with ENQFLAG=04C or 08C and FLAG2=08 are now 
               added to IMS35P.  This site uses Terminal-Databases with 
               SPA-information and a Code-Information in the INPUT msg  
               to jump from one transaction to another, which are now   
               supported by additional logic, even when outputs do not  
               match inputs.  Compare criteria using LOGONID and ODEST  
               do not work if there is no external LOGON-processing,    
               (DEQTIME was always equal to OGUTIME), but by using      
               CLINENR instead, and revising the MERGE logic, this      
               case appears to be now protected as well.  However, as   
               past history indicates with IMS, what works at several   
               sites may not always work at all sites, so please verify 
               your output if you must process IMS log data.            
               Additional cosmetic changes were a new message that tells
               you how many megabytes of IMS log data MXG read in, and  
               if invalid 035x records are found, a hex dump of the     
               record is printed on the log for Merrill debugging!      
   Thanks to Siegfried Trantes, Gothaer Versicherungsbank VVAG, GERMANY.
Change 09.181 -IBM APAR PL83370 adds new field STATCTM1 to CICS/ESA type
IMACICDB       110 DBCTL segment. However, since the APAR does not say  
VMAC110        where the field was added, I had to assume it's at the   
Nov 27, 1991   end of the known fields (in the 96 skipped bytes).       
               This new field captures the IMS CPU time in DRA thread   
               TCBs (but not time spent in the control region, as DBCTL 
               cannot capture that CPU time).  Originally, IMS 3.1.0 did
               not provide CPU time for threads because the original    
               design provided for an alternate method called "commit-  
               continue";  late in the release, a decision was made not 
               to support the commit-continue, and nothing was provided 
               in its place.  Now, STATCTM1 has been provided to capture
               the CPU time spent in the DRA thread TCB from the begin  
               of schedule request to the release of the PSB (any SYNC  
               POINT that also says 'TERMINATE TCB'), using existing    
               STIMER and TTIMER cancel code in DRA.                    
                    STATCTM1='ELAPSED UOR*CPUTIME FOR*THREAD TCB'       
              -This APAR also corrects the value in STATDBIO: IBM code  
               existed to catch the SLOG22/SLOG23 pair (OSAM buffer     
               handler) and count it as one Database I/O, but there was 
               no code to catch the SLOG24/SLOG25 pair (VSAM buffer     
               handler).  The DBIO field is also copied into the IMS 07 
               log record, so now that field will also be valid.        
              -The APAR text also states that the new CPU time, STATCTM1
               is added to the IMS log Type 07 record as field DLRTIME, 
               but I need DSECTS to find out where, before I can update 
               TYPEIMS (and there'll be a change for TYPECIMS too!).    
   Thanks to Philip Schwartz, United Parcel Service, USA.               
Change 09.180  A volume with 1,260,487,800 bytes capacity (tracks times 
VMACDCOL       formatted track capacity) was reported by DCOLLECT as    
Nov 26, 1991   having a capacity of only 1,260,487,680, a loss of 120   
Feb 10, 1992   bytes.  The error was thought to be truncation because   
               the variable was stored in 4 bytes, and in Nov, these    
               variables were changed to be stored in 8 bytes:          
               Now, the truth is known, and there was no MXG error.  The
               DCOLLECT data field is in kilobytes and not bytes, and   
               thus the values reported by DCOLLECT will be the nearest 
               multiple of 1024 bytes that is smaller than the true     
               value.  The extra 120 bytes exist on the volume, but will
               never be reported by DCOLLECT!                           
   Thanks to Terry Duchow, Minnesota Mutual Life, USA.                  
Change 09.179  PR/SM TYPE70PR summary PDB.ASUM70PR and trending TRND70PR
ASUM70PR       datasets were correct if NRPRCS (number of partitions    
TRND70PR       running or defined) was equal to PARTNCPU (number of     
Nov 25, 1991   physical processors), but PCTLnBY calculations were wrong
               otherwise, and produced logical busy percentages instead 
               of percent of physical busy that was intended.  Now, the 
               calculations use PARTNCPU so the PCTLnBY measures real   
               hardware CPU utilization of your PR/SM or MLPF box.      
   Thanks to Diane Eppestine, Southwestern Bell, USA.                   
Change 09.178  DB2 2.3 SMF type 102 records were changed incompatibly on
VMAC102        Nov 12.  (DB2 2.3 just became available Oct 28!).  Fields
Nov 25, 1991   were added to IFCIDs 28, 96, 140-142, and 145 (and are   
               now supported by MXG). IBM provided documentation that   
               was good and timely for this change.                     
Change 09.177  MXG PreRelease 9.4 produced zero observations in DB2data 
VMACDB2H       sets, with no error message.  A last-minute "cosmetic"   
Nov 25, 1991   change to label the new 2.3 variables corrupted the code.
               (The last 32 lines, starting at line number 01860000 must
               be moved to after line 005500).                          
   Thanks to Ted Garner, First Union, USA.                              
Change 09.176  IMS Abend condition codes were always blank, and because 
TYPEIMS        Change 9.106 was incorrectly located in MXG 9.3, the     
Nov 28, 1991   resources for multi-trans were incorrect.                
   Thanks to Pete Shepard, Ashland Oil, USA.                            
--Changes thru Change 9.175 were in MXG PreRelease 9.4 dtd Nov 15, 1991 
Change 09.175  BUILDPDB has been significantly enhanced.  DB2ACCT/STAT  
BUILD518       datasets are now added to your PDB from type 100/101 SMF 
BUILD606       records.  SAS 5.18 users should be able to add many more 
BUIL3518       SMF records to their PDB before a SAS 344 Compiler error 
BUIL3606       is encountered.  However, this change is INCOMPATIBLE for
BUILDPDB       SAS 5.18 sites; a new DD statement is required in the JCL
VMACDB2        for the BUILDPDB/3 step (only for SAS 5.18):             
Nov 15, 1991       //SMFTEMP  DD UNIT=SYSDA,SPACE=(CYL,(20,20))         
               An additional INCOMPATIBILITY exists for all BUILDPDB/3  
               sites that have added DB2 processing to their PDB (this  
               would have been done by editing members EXPDBINC,EXPDBVAR
               EXPDBCDE and EXPDBOUT members as described on pp 134ff of
               the MXG Supplement).  If you have added DB2 processing,  
               it must be removed or BUILDPDB will syntax error.        
               This redesign was caused because the "vanilla" BUILDPDB  
               in MXG 9.4 could not be compiled under SAS 5.18.  The    
               additions for MVS/ESA, CICS/ESA, etc., added iterative DO
               statements, causing a SAS 5.18 "344 Compiler Error".  To 
               circumvent this error, now, (for SAS 5.18 only), MXG     
               writes RMF 71 and 73-78 records to the (new) SMFTEMP file
               while reading your SMF input, and then executes a second 
               data step to process that small SMFTEMP file. (Type 70,72
               records are not split out, because type 30 processing    
               needs IOCCOEFF to calculate EXCPRMF!).  Splitting the    
               data step reduced the number of iterative DO statements, 
               avoiding the "344 Error" for sites which have added other
               SMF record processing (using the MXG Exit Facility, pages
               134-140 of the MXG Supplement).  The circumvention that  
               was previously described in Change 7.038 (in CHANGE07) is
               no longer applicable (except for the possible use of the 
               XMAC7072 member), since MXG has split the RMF processing 
               out.  Since RMF data is not large volume (perhaps 9MB    
               per day per system at 15 minute intervals), there is very
               little increase in processing time.                      
               Unfortunately, this elimination of the 344 SAS error may 
               only serve to uncover yet another SAS 5.18 limitation. A 
               160 SAS error occurs if the total length of all variables
               in a SAS data step exceeds a SAS 5.18 internal limit, and
               there's NO circumvention for the 160 error. If received, 
               you must remove some of your additional SMF records from 
               the EXPDB.. members, and instead use IMACFILE member to  
               write your SMF records the SMFTEMP DD, which can then    
               be processed in a subsequent step of your job.  (Or, you 
               can use SAS 6.06/6.07 for just the BUILDPDB step and use 
               a LIBNAME statement to build your PDB datasets in SAS    
               version 5.18 format).                                    
               Note there is no change for SAS Version 6; the compiler  
               limit does not exist in SAS Version 6, and BUILDPDB logic
               uses %MACROs to detect you are executing under Version 6,
               and MXG processes all SMF data in one pass; there is no  
               need for the SMFTEMP DD name under SAS 6.07/6.07.        
               Adding DB2 processing had been desired for some time, but
               because of the 5.18 problems, it could not be easily done
               until now.                                               
Change 09.174  Divide by zero error occurred for the type 79 record for 
VMAC79         the interval in which the clocks were set back this Fall!
Nov 14, 1991   The record had a duration of 0 seconds after the operator
               changed the clock.  Now, divides by DURATM are checked to
               be non-zero before the divide.  Also, RMF 3.5.1 caused a 
               STOPOVER on type 79 subtype 3 that is now protected.     
   Thanks to Fred Fettinger, Rockwell Graphic Systems, USA.             
Change 09.173  Support for LEGENT's MIM (Multi-Image Manager) user SMF  
EXTYMIM        records was added by this user contribution.  A single   
IMACMIM        dataset, MIMTAPE, is created from this record.           
Nov 14, 1991                                                            
   Thanks to Doug Drain, National City Bank, USA.                       
Change 09.172  Support for Softtool Corporations's CCC (Change and      
ANALCCC        Configuration Control software is added by this user     
EXTYCCC        contribution.  Example reports are also provided, but    
IMACCCC        will require an installation format for processor power. 
Nov 14, 1991                                                            
   Thanks to Sue Swayne, Inland Revenue (UK), Worthing, ENGLAND.        
Change 09.171  The collection of RACF reports added by change 9.064 had 
ANALRACF       invalid concatenation symbols (because the code went     
Nov 12, 1991   from MVS to a PC and back!).  The reports were also      
               slightly revised and enhanced.                           
   Thanks to Duncan McKellar, Inland Revenue (UK)                       
   Thanks to Neil Campbell, Inland Revenue (UK)                         
   Thanks to Dave McLaughlin, Inland Revenue (UK)                       
Change 09.170  FTP SMF records produced no observations because test to 
VMACFTP        ensure there was data was incorrect.  Eleven occurrences 
Nov 12, 1991      OFFDATA+(NRDATA*LENDATA) LE LENGTH THEN ...           
               must each be changed to                                  
                  OFFDATA+(NRDATA*LENDATA) LE LENGTH+1 THEN ...         
   Thanks to Kueller, Spardat Wien, AUSTRIA.                            
Change 09.169  TYPE59 variable QUEUTIME was not formatted DATETIME21.2, 
VMAC59         nor was it set to stored length of 8 bytes, but now it   
Nov 12, 1991   is!                                                      
   Thanks to Siegfried Trantes, Gothaer Versicherungsbank VVAG, GERMANY.
Change 09.168  A CICS region ABEND caused Landmark to write a "trashed" 
TYPEMON8       record that contained invalid values for the offset to   
Nov 11, 1991   variable segments.  Because MXG did not validate that    
               the offset value was actually in the record, MXG failed  
               (with "INPUT STATEMENT EXCEEDED RECORD LENGTH").  There  
               are three DO statements that need to be protected.  Find 
               the following 3 DO statements in TYPEMON8, and insert    
               the four lines of protection preceding the existing DO   
                 IF FILECOL+FATNUM*TAFATLEN GT LENGTH+1 THEN D0;        
                   PUT 'BAD RECORD FOUND AND DELETED '; LIST;           
                 DO FILESEG=1 TO FATNUM;                                
                 IF UATCOL+UTNUM*TAUATLEN GT LENGTH+1 THEN DO;          
                   PUT 'BAD RECORD FOUND AND DELETED '; LIST;           
                 DO USERSEG=1 TO UTNUM;                                 
                 IF MROCOL+MRONUM*TAMROLEN GT LENGTH+1 THEN DO;         
                   PUT 'BAD RECORD FOUND AND DELETED '; LIST;           
                 DO MROSEG=1 to MRONUM;                                 
   Thanks to Freddie Arie, Lone Star Gas, TEXAS.                        
Change 09.167  Support for Codework Software's SNAPAD-MVS product user  
EXSNAPAD       SMF record.  SNAPAD lets mainframes talk to X.25 packet  
IMACSNAP       switching networks.  Feb 20, 1992: This code has now     
TYPESNAP       been tested and verified, superceeding the note in this  
VMACSNAP       change printed in Newsletter TWENTY-ONE.                 
Nov 10, 1991                                                            
   Thanks to Dennis Uy, Asian Development Bank, PHILIPPINES.            
Change 09.166  MXG incorrectly calculated Full Duplex line utilization  
VMAC28         PCTBUSY.  For half duplex, the calculation was correct.  
Nov 10, 1991   Since a Half Duplex line has only one set of buffer for  
               both send and receive,  MXG summed the send and receive  
               bytes and divided by the send (primary) line speed:      
               (The 800 is used because line speed is in baud).         
               But for a Full Duplex line, there are 2 sets of buffers, 
               one for send and the other for receive.  Thus there are  
               two separate utilizations that can be calculated.  Since 
               the purpose of PCTBUSY is to identify utilization, and   
               since the line is out of speed when either its send or   
               its receive utilization is 100%, MXG now calculates the  
               PCTBUSY for full duplex as the Maximum of the send or    
               receive (primary or secondary) utilization:              
               MXG's previous calculation for Full Duplex turned out to 
               be the average of the send and receive utilizations, and 
               thus underreported the typical utilization in which one  
               direction predominates.                                  
   Thanks to Lee Lik Cheung, DBS Bank, SINGAPORE.                       
Change 09.165  Support for LEGENT's LANSPY component of NETSPY 4.1 that 
EXNSPYLF       captures LAN resources and responses in five new MXG     
EXNSPYLG       datasets.  LANSPY creates record segments even when      
EXNSPYLL       there was no activity on the LAN, but MXG only outputs   
EXNSPYLR       observations if the activity counts are non-zero (the    
EXNSPYLS       decision logic is located in the Exit member EXNSPY..).  
VMACNSPY       This support has been tested with actual LANSPY data,    
Nov 10, 1991   thanks for excellent vendor support from Legent.         
Change 09.164  This change is primarily internal in that most user will 
ANALDB2R       not explicitly see these changes, but they are under the 
READDB2        cover significant enhancements to DB2 processing.  In    
VMAC102        VMAC102, new macros of the form _LTRccnn now are defined 
Nov  8, 1991   that are the list of the IFCIDs in each trace class.     
               These list macros are then used by the new READDB2 macro 
               (invoked by ANALDB2R when PDB=SMF is specified) so that  
               MXG only processes the IFCIDs that are needed, based on  
               the reports you have requested.  You no longer have to   
               manipulate member IMAC102 to process trace records, and  
               this re-design should execute significantly faster.      
               Note that READDB2 can be invoked independently if you    
               wish to create datasets from subsets of DB2 data; it     
               is self documenting.  The old keyword parameter names    
               for trace class selection (DB2TC1-DB2TC16, etc.) do not  
               exist (they were replaced by the new TRACECLS parameter),
               and you will get "KEYWORD PARAMETER NOT DEFINED" errors  
               if your ANALDB2R invocation uses the old names.          
Change 09.163  Trend Data Base updates.   DB2ACCT, DB2STAT0, DB2STAT1   
TRNDDB2A       have been updated to add some new DB2 2.3 variables for  
TRNDDB2S       identification, if they exist (i.e., when you have DB2   
TRND70         2.3 data.  New member TRND70 trends RMF TYPE70 dataset.  
Nov  8, 1991                                                            
Change 09.162  Cosmetic (but then looks do count!).  TYPE22_A bit maps  
VMAC22         of 3390-3 status should have been formatted $HEX2./$HEX4.
Nov  8, 1991   Now they are correctly formatted to describe status bits.
   Thanks to Harry Price, Florida Power and Light, USA.                 
Change 09.161  CICS/ESA only, DBCTL EMP data only.  In IMACICDB, the +98
IMACICDB       after STATBFWT should have been +100 (but this would have
VMAC110        only caused a problem if you had additional user data    
Nov  8, 1991   after the DBCTL EMP - if you did and decoded that user   
               data you will have been off by two bytes in your code).  
               However, IBM has added a new field in those former +100  
               bytes, so this change in IMACICDB replaces the old +98   
               with    STATUSSN   PIB4.                                 
               and adds a label STATUSSN='USSN*NUMBER'. In VMAC110, the 
               new variable is added to the KEEP= list for CICSTRAN.    
   Thanks to Barry Pieper, First Bank Minneapolis, USA.                 
Change 09.160  MXG 9.3 only, VMXGVTOF processing of ASMVTOC output will 
VMXGVTOF       cause "Invalid data for STARTIME" because the variables  
Nov  6, 1991   UNITADDR, UCBTYPE and STARTIME (added by Change 9.099)   
               were off by one byte.  The input @151, @154, and @158    
               for those three variables must be @152, @155, and @159.  
   Thanks to Normand Poitras, Teleglobe Canada, CANADA.                 
Change 09.159  A potentially serious error in VTOC/VTOF processing (only
VMXGVTOC       under SAS 5.18, not under SAS 6.06+) has been found.  The
VMXGVTOF       error appears to have been introduced in MXG 7.2 (October
Nov  6, 1991   1989!).  If you have this error, dataset VTOCLIST will   
               describe only the space used by the first three extents! 
               You have the error if VTOCLIST variable NREXTNTS (extent 
               count in the DSCB1) is greater than variable NUMEXT (MXGs
               count of extents).  The logic error is the location of   
               the CALL SYMPUT; it is now known that under SAS 5.18 the 
               CALL and STOP must be located after the SET statement for
               the below logic to have ever worked:                     
                   DATA _NULL_;                                         
                   CALL SYMPUT('MXGOBS',PUT(NOBS,7.0));                 
                   SET DSNAMES POINT=POINT NOBS=NOBS;                   
                   %IF &MXGOBS EQ 0 %THEN %LET I=11;                    
               Because the CALL was mislocated, &MXGOBS was always zero,
               causing MXG to prematurely terminate extent processing.  
               (Under SAS 6.06, it turns out, the logic worked!). But   
               the following logic is more straightforward and has now  
               replaced the above logic in VMXGVTOC and VMXGVTOF:       
                   DATA _NULL_;                                         
                   IF EOF THEN CALL SYMPUT('MXGOBS','0');               
                   ELSE        CALL SYMPUT('MXGOBS','1');               
                   SET DSNAMES END=EOF;                                 
                   %IF &MXGOBS EQ 0 %THEN %LET I=16;                    
               Additionally, the %DO statement twenty lines before this 
               code was changed to 15 instead of 10 (which corresponds  
               to changing the %LET I= value from 11 to 16), because it 
               is theoretically possible to require up to fifteen passes
               of the extent merge (I've not seen more than two needed).
               The actual change in MXG is more extensive; in addition  
               to the above logic changes, NREXTNTS is now compared to  
               NUMEXT and an error message produced on the log if data  
               has been lost (and some of the work dataset names used   
               in the matching process were renamed to make diagnosis   
               of any future problems more tractable).                  
   Thanks to Joseph Rannazzisi, Brooklyn Union Gas, USA.                
   Thanks to Al Acosta, Brooklyn Union Gas, USA.                        
Change 09.158  The NETVIEW VPD record type "E", end subrecord STOPOVER. 
VMACVPD        Variables VPDRSRV1 and VPDDCCAL must be $CHAR8. instead  
Nov  5, 1991   of $CHAR12. Offset for VPDDCCAL and VPDRSRV2 must be 86  
               and 94 instead of 90 and 102.  Additionally, informat for
               VPDRECNT, VPDPUCAL, and VPDDCCAL were changed from $CHAR8
               to ?? 8. so they are changed from character to numeric.  
   Thanks to Jim Nicholas, Mead Data Central, USA.                      
Change 09.157  Two DCOLLECT variables, DCDLBKDT in DCOLDSET, and UMLBKDT
VMACDCOL       in DCOLMIGS, were previously $CHAR8. (because IBM did not
Nov  5, 1991   choose to document the internal contents, and test data  
               used for MXG validation had only zeros in those fields.) 
               Both variables are now changed from character to numeric;
               this change may cause a problem if you combine the DCOL..
               datasets from before and after the change, but the long  
               term benefit of having the correct field name and format 
               out weight the short term impact.  Furthermore, BEFORE   
               and AFTER datasets can be combined while deleting the    
               previous character variable with simple logic:           
                                    NEW.DCOLDSET ;                      
   Thanks to O. V. Hanger, A. C. Nielsen Co., USA.                      
Change 09.156  DB2 2.3 final validation and documentation found several 
VMACDB2        changes, mostly cosmetic, were needed.                   
               and SPLM were deleted, as they were completely redundant 
               with decoded values of QTXAPREC.  They had been used in  
               tests in ANALDB2R, but those tests were replaced with the
               explicit tests for values of QTXAPREC.  Also, variables  
               QTXAILMT and QTXANRUN are now set based on bit tests (the
               previous tests for '80'X and '40'X were incorrect).  Also
               variables QTXACHUS and QTXACLMT are now format TIME12.2. 
             2.DB2STAT0 variable QLSTBRBF needed asterisks in its label.
               Variables QWS4ASCB and QWS4ASID are now kept, variables  
               QWS4EJST and QWS4SRBT are formatted TIME12.2. The twenty 
               address space variables (prefix QWS1,QWS2,QWS3,QWS4 and  
               suffix ASCB,ASID,EJST,PROC,SRBT) labels now name each of 
               the address spaces, and MXG now stores the data for each 
               address space consistently in these prefixes (in spite of
               IBM's inconsistent use of the 3rd and/or 4th buckets!):  
                 QWS1 - Master, or system services address space        
                 QWS2 - DBM1, or data base services address space       
                 QWS3 - IRLM, or inter-region lock manager address space
                 QWS4 - DDF, or distributed data facility (values will  
                                be missing if no DDF).                  
Change 09.155  TYPE22_7 variables CHOWNED and CHONLINE are set in lines 
VMAC22         lines 079600 and 079700, but were not reset if bit test  
Oct 17, 1991   was not satisfied, causing values to be propagated. Now  
               ELSE CHOWNED=' '; and ELSE CHONLINE=' '; were inserted   
   Thanks to Bruce Read, Attorney General's Department, AUSTRALIA.      
Change 09.154  NETSPY variables STARTIME and STOPTIME are reversed in   
VMACNSPY       lines 089100 and 089200.  STOPTIME is based on DTEE/TMEE 
Oct 17, 1991   and STARTIME is based on DTES/TMES.                      
   Thanks to Lois Robinson, M & I Data Services, Inc, USA.              
Change 09.153  Type 6 "INPUT STATEMENT EXCEEDED RECORD LENGTH" results  
VMAC6          from LEGENT's Bundle product record which is logically a 
Oct 16, 1991   normal External Writer record, but because the record now
               contains the characters "BU" instead of the normal zero  
               in the SUBS field, the shorter EXTW record format was not
               recognized by MXG.  Now, SUBS=49892 ("BU" as PIB2.) sets 
               SUBSYS='BUND', and the two tests for 'EXTW' are extended 
               to treat 'BUND' as 'EXTW', thereby adding support for    
               the Bundle product in MXG.                               
   Thanks to David Kyle, Dominion Bankshares, USA.                      
Change 09.152  Support for new Tape Device 3490E added. In MXG datasets 
VMACEXC2       TYPE434, TYPE30_V, TYPE30_4, TYPE30_5, TYPE30_6, TYPE40, 
VMACUCB        variable EXCP3490 is created, in the TYPE30_n datasets   
VMAC30         variable IOTM3490 is created, and in datasets TYPE434    
VMAC40         and TYPE30_N variable TAPE3490 is created.  Change 9.002 
VMAC434        created a new value for the variable DEVICE, but did not 
Oct  9, 1991   create these new variables.  Because the 3490E format is 
Aug 19, 1995   completely different than 3480s or the earlier 3490s, it 
               was consistent with MXG treatment of devices to create   
               these three new variables in the appropriate datasets.   
    MXG Internals Architecture Note for the record:                     
    Addition of new device type in MXG requires knowledge of the values 
    of device class DEVCLASS and device type DEVTYPE returned by the IBM
    macro DEVTYPE so that the new variables EXCPnnnn, IOTMnnnn, (and for
    tape devices, TAPEnnnn) can be created.  The changes that are then  
    made in MXG (not by you - these are the changes that MXG made when  
    an MXG Change states "Support for new DASD/Tape Device nnnn added"):
       For new DASD device:                                             
         a) VMACUCB  - create new value for DEVICE within device class. 
         b) VMACEXC2 - create new DO group within device class.         
                        IF DEVTYPE=0hhX THEN DO;                        
         c) VMAC434  - Label EXCPnnnn                                   
         d) VMAC40   - Label EXCPnnnn                                   
         e) VMAC30   - Label EXCPnnnn, IOTMnnnn                         
                     - Add   IOTMnnnn to TIME12.2 format list.          
         f) IMAC30IO - Add EXCPnnnn, IOTMnnnn to respective macros.     
       For new Tape device:                                             
         a) VMACUCB  - create new value for DEVICE                      
         b) VMACEXC2 - create new DO group:                             
                        IF DEVTYPE=0hhX THEN DO;                        
                     - create new counter within device class tests:    
                        IF DEVTYPE=0hhX THEN TAPEnnnn=SUM(TAPEnnnn,1);  
         c) VMAC434  - Label EXCPnnnn,TAPEnnnn                          
                     - Keep  TAPEnnnn                                   
         d) VMAC40   - Label EXCPnnnn                                   
         e) VMAC30   - Label EXCPnnnn,IOTMnnnn,TAPEnnnn                 
                     - Keep  TAPEnnnn                                   
                     - Add   IOTMnnnn to TIME12.2 format list.          
         f) IMAC30IO - Add EXCPnnnn, IOTMnnnn to respective macros.     
         g) IMACPDB  - Add TAPEnnnn to the _PDB30_4 and _MAXSTP macros. 
                     - Then, in the PROC MEANS logic that follows, the  
                       X10 in the DROP= list must be changed to X11, and
                       X11 must be added after the X10 in the SUM= list.
       In addition, member FORMATS must be scanned for all occurrences  
       of the previously-newest-device-of-this-class. (Eg, when adding  
       support for 3590 tape drive, locate all occurrences of 3490 in   
       all formats).  Only one or two formats use the IBM DEVCLASS and  
       DEVTYPE values (eg., '8083' for 3590s); those you can directly   
       update.  The rest (currently, EREP and ZARA) have their own, non-
       standard table of values, and their vendor must be contacted to  
       determine what value they chose.                                 
       This note was revised August 19 and again September 22, 1995.    
Change 09.151  Support for new DASD Device 9345 added.  In MXG datasets 
VMACEXC2       TYPE434, TYPE30_V, TYPE30_4, TYPE30_5, TYPE30_6, TYPE40, 
VMACUCB        variable EXCP9345 is created, and variable IOTM9345 is   
VMAC30         created in the TYPE30_n datasets. The new device has a   
VMAC40         tracksize of 46456 (after R0 is on the track), with 15   
VMAC434        tracks per cylinder, and 1440 cyl per vol on Model 1 or  
Oct  9, 1991   2156 cyl per vol on Model 2.                             
Change 09.150  Cosmetic changes.  Comments describing the expected sort 
ANALCICS       order were clarified, and the second occurrence of       
Oct  8, 1991   TASCPUTM=0; was deleted.                                 
   Thanks to John Chapman, British Gas, ENGLAND.                        
Change 09.149  DB2 report PMACC01 could produce zeros in two places due 
ANALDB2R       to MXG typing errors.  The two lines now reading         
Oct  8, 1991      GSWS=QBACSWS;   and  L2SWS=QBACSWS;  should read      
                  GSWS+QBACSWS;   and  L2SWS+QBACSWS;  respectively.    
               Though not causing an error, lines 012560-012970 (IF _N_ 
               .... END;) were deleted, as those variables were already 
               initialized by the RETAIN statement.                     
   Thanks to Susan Marshall, SAS Institute Europe, GERMANY.             
   Thanks to ???, ORDA-B, BELGIUM.                                      
Change 09.148  Cosmetic enhancement to MXG messages when reading SMF.   
VMACSMF        MXG now prints additional information on the SAS log     
Oct  4, 1991   when reading SMF data.  The start and end times and the  
               system id for each dump event are now printed (from the  
               type 02/03 records) preceding the "SUCCESSFULLY READ"    
               message, and the minimum and maximum timestamp of any    
               SMF record are also printed.  The 02/03 pairs are very   
               useful to detect problems in SMF dump processing (if you 
               don't have matched pairs for each system, you had a real 
               problem, and if you have duplicate data you can see the  
               record numbers so you can copy the SMF file, deleting    
               the duplicate records based on these log messages).      
   Thanks to John Chapman, British Gas London, ENGLAND.                 
Change 09.147  Support for Omegamon for CICS/ESA Version 550 user SMF   
EXOMCADA       record created by ESRA, INTR, SYSINIT, and OMDV.  There  
EXOMCBOT       are three different subtypes (100,101,102) of the user   
EXOMCDCT       SMF record, and each subtype has sub-subtypes, and the   
EXOMCDLI       subtype 100 sub-subtype 4 has still additional subtypes. 
EXOMCENQ       This code has been compared with hex dumps of subtype 100
EXOMCFCT       records, but only syntax checked in execution as no data 
EXOMCFIX       records have yet been received for testing.              
Nov  8, 1991                                                            
Change 09.146  This change significantly enhances MXG's processing of   
IMACICDA       optional CICS data gathered with EMPs.  Previously, MXG  
IMACICDB       member IMACICDL decoded IBM local DL/I counters, member  
IMACICDL       IMACICDB decoded IBM DBCTL counters, and member IMACICUS 
IMACICDU       was used to set the length of any remaining user data.   
IMACICOB       The MXG order of processing those segments was not under 
IMACICOC       user control.  This change externalizes the processing   
IMACICOL       into new member IMACICDA, which can be used to match the 
VMAC110        MXG order with the order your CICS programmer set in her 
Oct  3, 1991   CICS MCT table.  IMACICDA can also be used to identify   
               which APPLIDs have which data segments, if not all are   
               the same.  Comments in IMACICDA describe how to use the  
               enhancement, but this change did NOT change the previous 
               MXG order (DL/I, UserChar, DBCTL).  The change should be 
               transparent to users already using the existing IMACIC.. 
               members to decode those data.                            
               The real reason for this enhancement now was that it is  
               now used to add support for additional CICS data that is 
               created by Omegamon for CICS Version 550.  The additional
               data are now supported by the new IMACIC.. "Omegamon"    
               members listed below.                                    
            IMACICDL    IBM Local DL/I counters.                        
            IMACICDU    User counters/clocks/character data.            
                        (Note that the length of the user data is still 
                         defined, and can be decoded, in IMACICUS).     
            IMACICDB    IBM DBCTL counters, CICS/ESA only.              
            IMACICOC    Omegamon OMEGBSC (Basic) segment, CICS/ESA only.
            IMACICOL    Omegamon OMEGDLI (DL/I) segment, CICS/ESA only. 
            IMACICOB    Omegamon OMEGDB2 (DB2) segment, CICS/ESA only.  
               Note that while the order of segment processing is now   
               set in IMACICDA, it is still required that you remove the
               comment block in each member you want to enable.  See the
               comments in each member itself.                          
   Thanks to Barry Pieper, First Bank Services Minneapolis, USA.        
Change 09.145  Support for Omegamon for CICS Version 550 type 110 SMF   
IMACEXCL       record EXCLUDE logic (used ONLY by Omegamon for non-ESA  
VMAC110        CICS, e.g., CICS 2.2 and earlier) has been added to MXG  
Oct  3, 1991   IMACEXCL (itself new in MXG 9.2).  Candle keeps only 31  
               of the standard 60 IBM fields, and Candle reorders them! 
                 Reading a Candle excluded record without IMACEXCL gets 
                 you an "Invalid TASKNR" error with MCTSSDCN=34.        
               (The exclude/reorder is optional in Omegamon, but your   
               CICS person must be extremely careful with Omegamon with 
               CICS Version 2, as the type 110 record that is created by
               Omegamon is independent of the type 110 IBM CMF record - 
               both can be simultaneously created if both are turned on,
               which can happen and has caused duplicate accounting of  
               CICS transaction counts and resources under CICS Version 
               2 regions.  The problem does not occur in CICS/ESA, as   
               Omegamon does not create a type 110 record under CICS    
               Version 3 - it simply adds data (EMPs) to the end of the 
               IBM CMF record as described in Change 9.146).            
               The IMACEXCL member was originally added in MXG 9.2 to   
               support Shared Medical Systems exclude logic, and it now 
               has been revised to provide support not only for these   
               Omegamon exclude logic, but now can be used for any CICS 
               system with excluded/included fields.                    
               Note that the three EMPs that Omegamon can also create   
               in CICS/ESA are separately supported by Change 9.146.    
               Note also that there is also an Omegamon CICS user SMF   
               record (that Candle unwisely defaults to ID=255, which   
               is the same default as their unrelated Omegamon for MVS  
               audit record!). That new CICS SMF record is supported in 
               Change 9.147. (The unrelated audit record support is in  
               member TYPEOMAU/VMACOMAU/IMACOMAU.)                      
   Thanks to Jim Shumaker, American Express Phoenix, USA.               
Change 09.144  DCOLLECT values for sizes of volumes and datasets were   
VMACDCOL       changed by APAR OY36364/UY55804, but MXG Change 8.285    
Oct  1, 1991   was also in error.  Before APAR, IBM used a track size   
               of 47968 (3380) or 58786 (3390) bytes, which is the      
               unformatted track capacity.  But every track really has  
               a record R0, and users complained about DCOLLECT values. 
               IBM's APAR now uses the formatted track size available   
               after R0, the familiar 47476 (3380) or 56664 (3390)!     
               But when I validated the earlier number and found the    
               numbers were larger than expected, I assumed that the    
               values documented as "KB" were "thousand-bytes", and not 
               "kilo-bytes", and thus Change 8.285 incorrectly used a   
               factor of 1000 to convert raw values into "bytes".  Now  
               the truth is know; DCOLLECT does store Kil0-bytes and    
               the correct conversion factor should have been 1024.     
             1.These values must be multiplied by 1024 instead of 1000  
               (they are listed in the order in which they appear):     
             2.Two other variables were also in error, but unrelated    
               to the above error.  Variables DCDBKLNG and UMBKLNG are  
               block length of datasets, and should not have been       
               multiplied at all.  Delete the respective lines which    
               erroneously multiplied them by 1000.                     
               The following table shows the values stored and reported 
               by MXG (after this change has been made to VMACDCOL),    
               before and after the above IBM APAR is installed.  (Note 
               that after the APAR but without this change, MXG showed  
               the 3380D capacity as 587MB!).                           
                                      Before APAR         After APAR    
                  Device  Tracks      Kbytes   MB         Kbytes   MB   
                  3380D    13275      621850   607        615472   601  
                  3380E    26550     1243701  1214       1230945  1202  
                  3380K    39825     1865552  1821       1846417  1803  
                  3390-2   33390     1916859  1871       1847666  1804  
                  3390-3   50085     2875289  2807       2771500  2706  
   Thanks to Susan Marshall, SAS Institute Europe, GERMANY.             
   Thanks to Mr. Plaacht, RWG, GERMANY.                                 
   Thanks to Stuart Buck, Procter and Gamble Brussels, BELGIUM.         
Change 09.143  Support for CMA-SPOOL user SMF record creates twelve new 
EXCMA00X       datasets, one for each subtype.  The support is written  
EXCMA01X       in the "Subtype-Level Processing" architecture, which    
EXCMA02X       allows individual datasets to be created from selected   
EXCMA03X       subtypes, or all twelve datasets can be simultaneously   
EXCMA04X       created.  See examples in the comments at the beginning  
EXCMA05X       of member VMACCMA.  CMA-SPOOL is a product of SCA.       
Sep 30, 1991                                                            
   Thanks to Charlan Ledbetter, Anderson Consulting Dallas, USA.        
Change 09.142  TMON/MVS creates invalid records (if the data record is  
VMACTMVS       larger than the CI size of the VSAM dataset TMON/MVS     
Sep 30, 1991   uses, the logic record is arbitrarily broken down into   
               "spanned" physical records that do not conform to normal 
               spanning, that have incorrect counts of how may real     
               segments are in a "spanned" record, and that can be      
               spanned right in the middle of a field!).  MXG can only  
               recognize and delete these defective records, but the    
               DELETE; statement after the MXG error message was lost.  
               The spanned record was recognized, the error message was 
               printed on the log, but MXG still failed with INPUT      
               STATEMENT EXCEEDED RECORD LENGTH message.  This change   
               put the DELETE; statement after the error message.       
               Additional failures occurred when "trashed" records were 
               created by TMON/MVS; these records had julian dates of   
               1989 and their "triplets" (offset, length, number)had    
               zeroes for offset and/or length.  MXG previously only    
               tested the triplet-number, which was insufficient        
               protection for these defective records.  Now, MXG uses   
               all three triplet fields, and the record length to       
               (hopefully) more robustly detect and delete defective    
               data records.   Finally, MXG now can recognize if you    
               have tried to process compressed records without having  
               installed the MXG-provided de-compression exit (in MXG   
               member EXITMON6 for Version 6, EXITMONI for Version 5),  
               and the messages in this case are much cleared.  Note    
               that until Landmark chooses to create valid records,     
               the data in their "spanned" records will be deleted.     
   Thanks to William Padilla, Farmers Group Insurance, USA.             
Change 09.141  IBM APAR OY33312 (PTF UY52529,30,31), says "APAR OY25606 
APAR/PTFs      Contains an Incompatible Change to Type 30 Records" and  
Sep 29, 1991   OY33312 proceeds to state that it will reverse OY25606,  
               and will change the length of SMF30EOR back to 2-bytes,  
               etc.  Don't worry about it; OY33312 has no effect on MXG 
               processing of the type 30 record.  The APAR affects only 
               assembly programs using IBM macros which reference the   
               DSECT fieldname SMF30EOR, but the APAR does not change   
               the location of any fields that MXG reads; MXG did have  
               to add code to support OY25606 (Change 8.081), but that  
               code works fine with or without OY33312.                 
   Thanks to Susan Marshall, SAS Institute Europe, GERMANY.             
Change 09.140  The author of this I/O report found these corrections:   
ANALPATH       Line 014900 should be XDUR = MAX(XDUR,SDUR);  instead of 
Sep 29, 1991    containing a + sign.                                    
               Lines 016700 and 016800 should use XDUR instead of SDUR  
                in the denominator (calculating GTSIOPS and GTATTPS).   
   Thanks to Cindy Batson, Hewitt Associates, USA.                      
Change 09.139  RMDS records with RMDSORG='D' were incorrectly decoded,  
VMACRMDS       in VMACRMDS, change line 043700 to read                  
Sep 29, 1991      ELSE IF RMDSORG='B' OR RMDSORG='D' THEN DO;           
               change line 044500 to read                               
                          RMDSDEST $CHAR19.        (instead of 17),     
               insert after line 044700 a new line with                 
                    IF RMDSORG='D' THEN INPUT RMDSOWNR $CHAR8. @;       
               and change line 045900 to read:                          
                  ELSE IF RMDSORG='V' THEN DO;                          
               Before the change, RMDSORG='D' was processed with 'V'.)  
               In verifying this error, the code in VMACRMDS was        
               restructured and renumbered, and comments made clearer   
               that RMDS Version 3 and Version 4 are identical.         
   Thanks to Steve Lottich, The University of Iowa, USA.                
Change 09.138  Support for DB2 2.3.0.                                   
DIFFDB2        IBM made incompatible changes in type 100 (Statistics,   
FORMATS        DB2STAT0/1 datasets) and in type 102 (Trace, T102Snnn),  
VMACDB2        but existing MXG programs should have no problems, as    
VMACDB2H       long as you install MXG 9.4+ and update the MXG Format   
VMAC102        library.  You may want to exploit some of the new data,  
Sep 29, 1991   as described in the following notes:                     
Change 09.137  Minor enhancements to type 30 MULTIDD='Y' observations.  
VMAC30         Variable CPUERROR is now retained from the base record.  
Sep 29, 1991   (It is a bit map character variable, but since it was    
               not input in the multi-dd record, it assumed a value of  
               '4040'X, potentially causing confusion).  EXECTM is now  
               missing in the interval multi-dd records; recalculation  
               of EXECTM is performed only if not multi-dd record. The  
               JELAPSTM is now set missing in the multi-dd record.      
   Thanks to Diane Eppestine, Southwestern Bell, USA.                   
Change 09.136  Variable DUPLXUSE in TYPE6 should not be used.  It was   
FORMATS        originally used to identify Standard/Tumble Duplex, and  
VMAC6          MXG format $MG006DU decoded '80'X or '40'X values. But   
Sep 28, 1991   now, additional bits are used, invalidating the single   
Nov 14, 1991   value hex decoding.  SAS 6.07 supports bit testing for   
               formats, but SAS 5.18 syntax errors.  MXG has replaced   
               format $MG006DU for variable DUPLXUSE with $HEX2., and   
               you should use the variables (STDUPLEX/TMBUPLEX) instead.
               (All of the bits of old variable DUPLXUSE are now used   
               to set individual variables).                            
   Thanks to Vickie Wong, Manufacturers Life, CANADA.                   
Change 09.135  ANALDBTR can fail with "DATASET S064058 NOT SORTED" even 
ANALDBTR       after Change 9.104 was installed, because one more typo  
Sep 28, 1991   was missed.  Line 161000 must be E064TM instead of the   
               E063TM variable name.                                    
   Thanks to Barry Bluestein, Union Carbide, USA.                       
Change 09.134  Support for MVS/ESA 4.2.2 (RMF 4.2.2) added several new  
VMAC22         fields to several records, but most are not significant. 
VMAC23         IBM changes are compatible.SMF manual now GG28-1628-2.   
VMAC30       a.TYPE22 added new bit value in TYPE22_1.                  
VMAC40       b.TYPE23 support in MXG was incorrect.  Fields added by    
VMAC71         earlier APAR were not INPUTed because the test was for   
VMAC90         the wrong length (also, order of new variables was not   
Sep 28, 1991   correct).  Code has now been corrected, so the new data  
               on SMF buffer statistics is now useful!                  
             c.TYPE30 contains new 8-byte jobclass JOBCLAS8 (left       
               justified).  Until it's clear that it's needed, MXG has  
               decoded but not kept the field.  However, if the 1-byte  
               existing variable JOBCLASS is blank and the new JOBCLAS8 
               is non-blank, the first byte of JOBCLAS8 will be stored  
               in variable JOBCLASS.  Do you see a need for 8-bytes?    
               This field was added by APAR OY42532.                    
             d.TYPE40 contains two new fields, TDDRCIND/TDDRCTOT which  
               count the index and number of records in a sequence of   
               records, but I can't figure why they are needed, and     
               especially IBM states at the beginning of section that   
                "IBM recommends you use record type 30 rather than      
                 record types 4, 5, 20, 34, 35, and 40"                 
               its unclear why any change to type 40 was made!          
             e.TYPE71 record was not changed, but since RECLAIMS no     
               longer exist in 4.2.2, the four fields which formerly    
               counted reclaims (PVTNPREC,PVTVAMR,PVTCAREC,LPARECLM)    
               will now always be zero.  Member VMAC71 was enhanced by  
               adding SMF71xx field names in comments adjacent to the   
               MXG variable name to map MXG names to IBM names.         
             f.TYPE90 now supports subtypes 19, 20, and 21 (which were  
               in 4.2.1 but not decoded by MXG - SET APPC, SET ASCH, &  
               SET SCH respectively), and supports the new subtype 22   
               (SET CNGRP) added by 4.2.2.                              
Change 09.133  Variable ID was added to the KEEP= list, since multiple  
VMAC6156       SMF records (61,65, or 66) create observations in the    
Sep 28, 1991   TYPE6156 dataset.                                        
   Thanks to Tony Curry, Manufacturer's Hanover, USA.                   
Change 09.132  Typographical errors printed in NEWSLETTER TWENTY have   
CHANGES        been corrected in the MXG SOURCLIB members. Errors were: 
NEWSLTRS     a.Newsletter TWENTY correctly stated that NOIMPLMAC must   
Sep 28, 1991   be specified in CONFIG, but then should have said that   
                "IMPLMAC should never be used in ANY program."          
               instead of "NOIMPLMAC should never be used...."          
             b.In Change 9.066 text USERFMTS should have been IMACFMTS. 
             c.Several references to NPM 4.1.1 should have been 1.4.1.  
   Thanks to Pat Russell, Group Health Cooperative, USA.                
Change 09.131  Members CONFIG and CONFIG07 have been updated to contain 
CONFIG         all of the MXG recommended options (added: ERRORABEND    
Sep 28, 1991   NOMACROGEN NOMPRINT NOMLOGIC). The new SAS 6.07 option   
               CODEPCT=120 was added only to CONFIG07; this option will 
               avoid a second pass of SAS compiler for very large MXG   
               programs (like a heavily enhanced BUILDPDB) and will     
               eliminate an unnecessary and confusing SAS message.  Note
               that options in the CONFIG file can be overridden by the 
               the JCL OPTIONS= parameter. For example, to print source 
               statements, you can print the entire source program with:
                 //  EXEC SAS607,OPTIONS='SOURCE SOURCE2 MACROGEN',     
                 //              CONFIG='MXG.SOURCLIB(CONFIG)           
   Thanks to Pat Russell, Group Health Cooperative, USA.                
Change 09.130  SAS Version 6 Compatibility.  Options TLS= and TPS= do   
ANALTMS5       not exist in Version 6.  (They were used to set the line 
Sep 28, 1991   size and page size of your terminal, and were set to 132 
               and 60 respectively in an OPTIONS statement in this ANAL 
               member.  That OPTIONS statement was deleted.)            
   Thanks to Chuck Hopf, Primerica, USA.                                
Change 09.129  Variable SPMSEXTL in the KEEP= list for dataset SPMSCED  
VMACSPMS       should have been spelled SPMSEXTE.  Variable SPMSDSN     
Sep 28, 1991   should be added to the KEEP= list for dataset SPMSEXT so 
               you can match Extent data (SPMSEXT observations) to      
               their Definition data (SPMSCED observation). New Amdahl  
               PTFs for SPMS 1.2 are supposed to fix some data problems 
               but STARTIME is completely wrong in records that span    
               midnight; problem is being discussed with Amdahl now.    
               It has also been noticed that the SPMSATDC, allocated    
               track count delta, can be negative when less tracks are  
               allocated at the end than at the start of interval.      
   Thanks to Richard R. (Dick) Sziede, PRC Inc, USA.                    
Change 09.128 -MXG 9.3 only. Change 9.080 incorrectly deaccumulated the 
DIFFDB2        DB2STAT0/1 variables QBnTCBA and QBnTPID; eight lines    
Sep 26, 1991   with those names must be deleted.  QXCRRALS is spelled   
Oct  3, 1991   QXCRALS. QISE.... variables RCUR,RHIG,RLLM,RMAX,         
               RDLM, and RSTG must be changed to QIST.... prefix.       
              -MXG 8.8 and later.  Several sequence counter variables   
               have been incorrectly deaccumulated.  For DB2STAT0,      
               delete lines DIF'ing QWHSWSEQ, QWSBWSEQ, QWSnISEQ,       
               QWnBWSEQ. For DB2STAT1, delete DIF'ing of QWHSWSEQ.      
               (Do not delete DIF'ing of variables ending in TSEQ, nor  
               the two statements SEQCHECK=DIF(...).)                   
   Thanks to Barry Bluestein, Union Carbide, USA.                       
   Thanks to Pete Shepard, Ashland Oil, USA.                            
Change 09.127  Variable FSRTIME should have been in the KEEP= list for  
VMACHSM        dataset HSMFSRST; now it is.                             
Sep  9, 1991                                                            
   Thanks to Peter Giles, DSS, AUSTRALIA.                               
   Thanks to Colin Norton, DSS, AUSTRALIA.                              
Change 09.126  Boole's CMF records caused STOPOVER when record with a   
VMACCMF        non-zero offset and non-zero length but with a zero for  
Sep  8, 1991   number of segments was found.  The CHECKSUM logic did    
               not check for existence of segment before trying to read 
               the record.  Only the Device Type Segment has thus far   
               had zero number, and changing line 00089700 to now read  
                    IF C00DTYPN GT 0 THEN LINK CMFCKSM;                 
               will circumvent this specific error.  However, the MXG   
               change will protect each triplet by creating a variable  
               CMFWNUM set equal to the number of segments (immediately 
               following CMFWPTR which is set equal to the offset), and 
               then executing the subsequent LINK only if CMFWNUM is    
               greater than zero. There are 12 triplets to protect.     
   Thanks to Peter Giles, DSS, AUSTRALIA.                               
Change 09.125  This Cache DASD analysis report uses both TYPECACH and   
ANALCACH       TYPE74 data, but did not delete type 74 data from tapes! 
Aug 20, 1991   Insert after PDB.TYPE74;  IF DEVICE=:'34' THEN DELETE;   
               to exclude tape devices from Cache DASD reports.         
   Thanks to Jim Cummings, First Interstate Bank of Oregon, USA.        
Change 09.124  Candle's OMEGAMON Audit User SMF Record has existed for  
VMACOMAU       some time, and defaults to SMF ID=255.  However, their   
Aug 20, 1991   new CICS V550 product now creates a different user SMF   
               record, which also defaults to ID=255, causing sites     
               using VMACOMAU to fail, since the new CICS user records  
               don't look anything like the Audit Record.  You must     
               change the V550 SMF record ID (in Candle's OC$GLOB       
               SMFID= parameter in their OCDATA install dataset) to     
               a different SMF record ID.  MXG support for the new      
               V550 User SMF record is discussed in Change 9.147.       
   Thanks to Dean Bolick, Belk Stores Services, USA.                    
Change 09.123  Protection for Shared Medical Systems CICS segments,     
UTILCICS       which have MNSEGCL values greater than 4, was not added  
Aug 20, 1991   to UTILCICS when VMAC110 was updated in MXG 9.2.  Now,   
               this member will skip over these segments instead of     
               printing ERROR.VMAC110.1 messages with MNSEGCL=209!      
   Thanks to Phil Shelley, Jewish Hospital HealthCare Services, USA.    
Change 09.122  For IMS measurement with Boole & Babbage's IMF product,  
TYPECIMS       the processing of Chained Transactions (at the end of    
Aug 20, 1991   member TYPECIMS) should have also recalculated the       
               response time variable, RESPNSTM, using the ACTLARRV     
               time of the chained transaction. Insert after 008600:    
   Thanks to Wolfgang Vierling, Vereinte Versicherungen, GERMANY.       
Change 09.121  MXG decoding of DB2 Correlation ID into CORRNAME/CORRNUM 
IMACDB2        was incorrect for CICS connection.  The CORRNAME should  
Aug 20, 1991   have been SUBSTR(QWHCCV,5,4) instead of (QWHCCV,9,4).    
               The comments describing the decoding of QWHCCV into the  
               CORRNAME/CORRNUM were also incorrect for CICS, and have  
               been revised and clarified.                              
   Thanks to ???, UNI Storebrand, NORWAY.                               
Change 09.120  IBM now says the three new CPU time values added by ESA  
XMAC7072       to the TYPE72 (CPUHPTTM,CPUIIPTM,CPURCTTM) are actually  
VMAC7072       in micro-second units, and not 1024-microsecond units,   
Aug 16, 1991   as documented in the microfiche for IRAWAMT!  MXG Change 
               9.070 is thus off by 2%; the 1.024 factor added by that  
               change must be removed (fortunately, by comparing these  
               CPU times with their counterparts in type 30, I knew the 
               1000 factor was wrong, but believed IBM when they said   
               1.024 instead of 1.000!).  Therefore, delete the three   
               lines multiplying these times by 1.024.                  
   Thanks to Peter Doane, Com/Energy Services Company, USA.             
Change 09.119  Invalid MODIFY ACF2 user SMF records are created, which  
Aug 14, 1991   The record has a parm length of 1 byte, but there is no  
               ACFAPARM field in the record.  C A could not see an      
               obvious code error, and required the Australian site to  
               open a problem, but not fix yet exists.  For now, change 
               updated when CA responds.  The circumvention for now is  
               lines 038900 and 039100 to read:                         
                ... 200 AND (COL-1+ACFAMPLN LE LENGTH) THEN ...         
   Thanks to Francis Han, Office of State Revenue, NSW, AUSTRALIA.      
Change 09.118  Support for Software AG's NET-PASS user SMF record is    
EXTYNETP       added by this change, which captures response time       
IMACNETP       (average, and three distribution buckets) as well as     
TYPENETP       session logon, logoff, and disconnect/reconnect times.   
Aug 13, 1991                                                            
   Thanks to Nancy Ayers, General Electric Lighting, USA.               
Change 09.117  Minor. Variables DLYCHATM and DLYDIRTM in TYPE74 were    
VMAC74         not formatted as TIME12.2, but now they are.             
Aug  9, 1991                                                            
   Thanks to Chuck Hopf, Primerica, USA.                                
Change 09.116  NPM 1.4.1 support was not complete in MXG 9.3. The code  
VMAC28         does not fail, but messages (NON-ZERO COF, UNEXPECTED    
Aug  9, 1991   SUBTYPE, CALL HOME) are printed, and not all of the new  
Aug 12, 1991   subtypes were output.  Several changes were required.    
   Thanks to Jim Shumaker, American Express, USA.                       
Change 09.115  SAS 5.18 compatibility. Step TESTIBM2 of JCLTEST needs   
TESTIBM2       a 6000K region under 5.18 because TYPE102, instead of    
Aug  8, 1991   TYPE102A,TYPE102B are included in MXG 9.3's TESTIBM2.    
               This change uses a %MACRO to detect which SAS version    
               is used and includes TYPE102 if under 6.06+, or includes 
               the pair TYPE102A, TYPE102B if under 5.18.               
   Thanks to Diane Eppestine, Southwestern Bell, USA.                   
Change 09.114  The VM/XA utility UTILGEVX to create VB records for test 
UTILGEVX       referenced the non-existent member (MACROS) and had the  
Aug  8, 1991   wrong macro names.  The INCLUDE for (MACROS) should have 
               been for (VMACVMXA), the _INFILE should be _MWINPUT, and 
               the _ENFILE should be _MWENDIT.  The comments should say 
               the input comes from fileref MWINPUT and VB records are  
               written to fileref OUTFILE.                              
   Thanks to Jay Cicardo, Southwestern Bell St. Louis, USA.             
Change 09.113  The VSAM Sharing Options in the VVDS were not fully      
VMACVVDS       decoded in the two flag variables VVRA2REG/VVRA2SYS.     
Aug  8, 1991   Two new variables with values 1, 2, 3, or 4 for both     
               the cross-system and cross-region share options now are  
               created with:                                            
   Thanks to Jeff Fox, SKF USA, Inc, USA.                               
Change 09.112  In analysis of ESA benchmark data, I discovered PERFGRP  
VMAC30         and MULTIDD was not kept in TYPE30_D and PDB.DDSTATS.    
Aug  8, 1991   Now they have both been added to the KEEP= list.         
   Thanks to Chuck Hopf, Primerica, USA.                                
Change 09.111  MXG recommended half-track BLKSIZEs of 23040/27647 for   
CONFIG         3380/3390s but did not realize SAS 6.06+ has an option   
CONFIG07       specifically for DASD, and there is also a TAPE option.  
Aug  7, 1991   Now, MXG CONFIG/CONFIG07 contain                         
   Thanks to Chuck Hopf, Primerica, USA.                                
Change 09.110  Landmark CICS added the 8-byte APPLID in their 8.1. MXGs 
ASUMCICS       7.1 summarization code had stored SYSID into APPLID to   
Aug  7, 1991   create APPLID, but that line now causes APPLID to be     
               truncated to 4 bytes with 8.1.  Change line 008700 from  
               to read                                                  
                  IF APPLID='        ' THEN APPLID=SYSID;               
               and add APPLID to the KEEP= in line 006200.              
               This change will only work with Landmark 8.1 data; the   
               datasets built from 7.1 data records does not contain    
               the variable APPLID, so the change must coincide with    
               your implementation of TYPEMON8 processing of 8.1 data.  
   Thanks to Freddie Arie, Lone Star Gas, TEXAS.                        
Change 09.109  The BLKSIZE of the MXG 9.3 tape was increased to 32720.  
CHANGES        The 9.3 label printed on the tape was correct, but the   
INSTALL        change from 6160 was not stated.  Worse, a note in the   
Aug  7, 1991   Installation section of Newsletter TWENTY said the tape  
               BLKSIZE was 23440, which it never has been!  The tape    
               blocksize had to be increased so that MXG 9.3 would fit  
               on a 600-foot 3420 reel, but it also reduced the time to 
               create 3420 or 3480s. The BLKSIZE=32720 will now be used 
               for all future MXG Versions. Sorry for my carelessness!  
JCLPDB6        pointing to your format library because Change 9.094 now 
JCLTEST        uses the MXG MGBYTES format.  In JCLPDB6, a // is needed 
JCLTEST6       before the OPTIONS= parameter on the EXEC statement.     
Aug  7, 1991                                                            
   Thanks to Mark Delorme, Minnesota Power, USA.                        
--Changes thru 9.107 were contained in MXG PreRelease 9.3, Aug 1, 1991--
Change 09.107  MONITASK variable TATASKNR contains transaction counts   
TYPEMON8       for history records, but Landmark's Release 8 relocated  
Jul 30, 1991   the field to what MXG read as TASINTL1 $CHAR4. Now, that 
               input is TATASKNR PIB4., the original TATASKNR is now    
               unkept variable TATASKNN, and TASINTL1 was never kept.   
   Thanks to Annette Miller, Dale Electronics, USA.                     
Change 09.106  IMS multiple-message transactions resources were wrong.  
TYPEIMS        Lines 145300-148400, which calculate the average DL/I,   
Jul 30, 1991   CPU, etc., must be moved to after line 144200, so that   
               the average is calculated only once, instead of being a  
               moving average.                                          
   Thanks to Russell Dewar, NM Computer Services, AUSTRALIA.            
Change 09.105  Change 9.100 discussed the new DROP,KEEP,RENAME warning. 
DOC            While initially I did not like the default of warning,   
Jul 30, 1991   it appears to be worthwhile; it uncovered many cases of  
               misspelled variables in KEEP lists that were not being   
               output, and some cases of variables that should have not 
               been in the KEEP list, when I ran the MXG 9.3 QA runs.   
               All members that could be corrected were, but some MXG   
               members intentionally contain unreferenced variables,    
               and these members may produce warnings (which have no    
               real impact, except for the condition code four!):       
                 VMAC6     VMAC40    VMAC110                            
               The protection in BUILDPDB/BUILDPD3 was extended to      
               suppress warnings for the entire member.                 
--Changes thru 9.104 were printed in MXG Newsletter TWENTY Aug 1, 1991--
Change 09.104  DB2 102 Trace Data causes ANALDB2R to fail with DATA SET 
ANALDBTR        NOT SORTED error in S008S009, S0015S018, or S059S058 due
Jul 28, 1991    to a misspelling in ANALDBTR.  The error occurs only if 
                a one of these trace events was incomplete, i.e., when a
                start event or end event record was not in the input.   
                These three sets of variables were reversed:            
                   Line       Now             Should be                 
                   049000     IF E008TM=.     IF S008TM=.               
                   049400     IF S008TM=.     IF E008TM=.               
                   068100     IF E015TM=.     IF S015TM=.               
                   068500     IF S015TM=.     IF E015TM=.               
                   164500     IF E059TM=.     IF S059TM=.               
                   164900     IF S059TM=.     IF E059TM=.               
   Thanks to Bob Farrell, Sun Alliance, ENGLAND.                        
Change 09.103  -A minor revision to ANALPATH was provided by its authors
ANALPATH        to deal with a divide by zero if no prime shift data was
IMACPDBX        used for the analysis.                                  
Jul 28, 1991   -The new member IMACPDBX will undoubtedly replace the MXG
                IMACPDB, but is placed in a separate member for sites to
                validate its architecture.  Dan Kaberon has implemented 
                a slick technique that lets you trivially change the    
                variables that are sum/min/maxed from the steps data to 
                PDB.JOBS, and you no longer have to count and set up the
                "dummy" X variables in the original IMACPDB.  The new   
                member also added three variables, PGSUSED PGSGLOAD and 
                SHEETPRN to the PDB.PRINT data set.                     
   Thanks to Dan Kaberon, Hewitt Associates, USA.                       
Change 09.102  -Multiple type 30 records will be written for each step, 
BUILDPDB        interval, or job, if more than 1476 DDs are in the task.
BUILDPD3        MXG has always created separate observations for each of
IMACPDB         these "Multi-DD" records, which contain only EXCP/IOTM  
VMAC30          resource fields.  However, several elapsed time measures
Jul 28, 1991    calculated by MXG from timestamps (ALOCTM,DSENQTM,EXECTM
                RDRTM,SELAPSTM) should not have been calculated, and are
                now set missing.  A new variable, MULTIDD='Y' is created
                to flag these records in TYPE30_4, TYPE30_5, TYPE30_6,  
                and TYPE30_V datasets.  If the need is demonstrated in  
                the future, MXG may add logic to sum the MULTIDD type 30
                into a single record, but the cost of double processing 
                does not seem necessary at this time. For now, flagging 
                these "pseudo-step" records and ensuring there is no    
                duplication of these elapsed time measures is enough.   
                MULTIDD was also added in IMACPDB to the _PDB30_4 list. 
               -The MULTIDD records for TYPE30_V intervals have another 
                problem; the begin of interval INTBTIME does not exist  
                (has missing value) in the second and subsequent MULTIDD
                record (because IBM puts it in the processor accounting 
                section, which is not created in MULTIDD records!). The 
                INTBTIME cannot be retained from the first record to the
                subsequent records while processing SMF data, because   
                other SMF records from other tasks can be sent to SMF in
                between the first and subsequent intervals of our job.  
                It was necessary to modify the logic of BUILDPDB/3 to   
                add an extra PROC SORT and logic to fill in the missing 
                INTBTIME, so that sites who wish to account using their 
                interval records can cluster the MULTIDD records.  If   
                your site creates interval records, you probably want to
                have this corrected, and if there is no interval data,  
                there is no cost to this enhancement of PDB.SMFINTRV.   
                Note this change does not correct the TYPE30_V data set 
                built by member TYPE30, but only the PDB.SMFINTRV data  
                set built by BUILDPDB/BUILDPD3.                         
               -Two other problems with MULTIDD records were corrected  
                in BUILDPDB/3. The variable STEP was a counter of step  
                records found, but it was also being incremented for    
                each of the MULTIDD records.  STEP is now incremented   
                only for the actual step record, not for the MULTIDDs.  
                The variable RESTART was a counter of job restarts, but 
                it too was being incremented for each MULTIDD record.   
                Now it only counts real job terminations as RESTARTS.   
   Thanks to Diane Eppestine, Southwestern Bell, USA.                   
Change 09.101  DOS/VSE Landmark CICS records are non-standard formats.  
TYPEMOND        Each block begins with 2-byte block length, followed by 
Jul 27, 1991    two 4-byte length fields, the second of which contains  
                the data-length of the following data record. The 4-byte
                pairs and data records are then repeated.  This format  
                can be read with the following changes to TYPEMONI for  
                Landmark 7.1 records.  The new member TYPEMOND contains 
                this change, but the logic has not been data-tested yet.
                 Replace                 With                           
                 INPUT                   INPUT BLKLEN PIB2. @;          
                   LENGTH   PIB2.        LOC=COL;                       
                   MFSREC $CHAR1.        DO WHILE (COL+8 LT BLKLEN);    
                 @;                        INPUT @LOC FIRSTLEN   PIB4.  
                                                      LENGTH     PIB4.  
                                                      MFSREC   $CHAR1.  
                 Immediately before the                                 
                 percent sign before                                    
                 MACRO _ANALMON insert                                  
   Thanks to ???, ???, EUROPE.                                          
Change 09.100  SAS 6.07 compatibility.  SAS validation of variables in  
BUILDPDB        KEEP, DROP, or RENAME statements or options was never   
BUILDPD3        consistent; an unreferenced variable in a "D,K,R" could 
CONFIG07        print an error, a warning, or no warning, depending on  
Jul 27, 1991    whether the "D,K,R" was an option or a statement and/or 
                whether the "D,K,R" was for input or output.  SAS 6.07  
                now consolidates the action by input or output and has  
                two new options, DKRICOND and DKROCOND which can set the
                action to be taken to ERROR, WARN, or NOWARN. By design,
                MXG has unreferenced variables in KEEP= lists for output
                and since the SAS 6.07 default is WARN, many unnecessary
                WARNING message will be printed on the log, and the step
                will end with condition code 0004.  These warnings can  
                be eliminated by adding  DKROCOND=NOWARN  to the CONFIG 
                member of MXG, but then SAS 6.06 will fail because this 
                option is unknown to SAS 6.06!  As a result, there is a 
                now a new member, named CONFIG07, for SAS 6.07 which has
                DKROCOND=NOWARN specified.  Just in case you miss this  
                note, however, BUILDPDB/3 are specifically protected by 
                the addition of %MACRO VMXGDKRN to set NOWARN during the
                SMF processing phase under 6.07 or later:               
                  %MACRO VMXGDKRN;                                      
                   %IF %SUBSTR(&SYSVER,1,4) GE 6.07 %THEN %DO;          
                     OPTIONS DKROCOND=NOWARN;                           
                and after the DATA step there is a %MACRO VMXGDKRW to   
                reset the option to DKROCOND=WARN.  This may change as  
                more experience with these new options accumulates.     
   Thanks to Rick Langston, SAS Institute Cary, USA.                    
Change 09.099  Dataset VTOCINFO's variable TRKSALOC contained only the  
VMXGVTOC        number of tracks allocated for the VTOC; not the total  
VMXGVTOF        tracks on the volume.  This change summarizes the detail
Jul 27, 1991    information into VTOCINFO, correcting TRKSALOC, and adds
                variables TRKSUSED, NUMDSN, PCTALOC to make the VTOCINFO
                dataset more meaningful for DASD capacity analysis.     
                Additionally, in the VMXGVTOF member only, each volume's
                UNITADDR, UCBTYPE, and STARTIME (of the ASMVTOC run) are
                now added to the VTOCINFO dataset.  These fields were at
                the end of the record created by ASMVTOC, but were not  
                kept in MXG's processing.                               
   Thanks to John Mattson, National Medical Enterprises, USA.           
Change 09.098  The original members WEEKBLD and MONTHBLD contained both 
JCLWEEK         JCL and SAS code, which required unnecessary JCL changes
JCLMONTH        due to SAS or SAS changes due to JCL.  This change puts 
WEEKBLD         the sample JCL in members JCLWEEK and JCLMONTH and has  
MONTHBLD        only SAS code in WEEKBLD and MONTHBLD.  The JCL examples
Jul 27, 1991    in these members (an in all future JCL examples) will be
                only for the SAS Version 6 environment.                 
Change 09.097A -The optimal BLKSIZE for MXG's SAS Data Libraries is half
CONFIG          track (See SAS Notes in Newsletter TWENTY).  Since these
Jul 26, 1991    libraries are RECFM=FB,LRECL=512, the correct half track
                data library block sizes are                            
                 Data libraries:                                        
                   3380  BLKSIZE=23040                                  
                   3390  BLKSIZE=27648                                  
                Member CONFIG now specifies BLKSIZE=23040 as default.   
               -The MXG Default BUFNO=2 is now specified in CONFIG. With
                a half-track BLKSIZE, transferring one track of data per
                SSCH results when BUFNO=2 is specified.  The incremental
                gain of additional buffers above 2 does not seem needed 
                and I have always felt righteous if I transferred data  
                for 1  revolution and then freed the device to other    
                users.  Since the virtual storage required for each SAS 
                data set is BUFNO*BLKSIZE, reducing BUFNO from 3 to 2   
                concomitant with the above BLKSIZE increase will        
                mitigate MEMSIZE.  I plan further benchmarking to see if
                there really is a value in increased BUFNO (only even   
                values make sense), but early results show half track   
                and BUFNO=2 gives very good performance and minimized   
                resources reasonably.                                   
               -The increased BLKSIZE value has increased the virtual   
                storage required for the INFILE processing parts of MXG,
                so MEMSIZE=24M is now specified (increased from 12M) to 
                ensure unnecessary "out-of-virtual-memory" ABENDs. Since
                MEMSIZE is above the line virtual storage, I don't think
                this increase will affect any real resources, and SAS   
                only gets what it needs anyhow.                         
               -The option ERRORS=2 was added, so that if you get any   
                invalid data hex dumps, only the first two will be on   
                your log, instead of the SAS default of the first 20.   
Change 09.097  HSM 2.6 SMF records were changed INCOMPATIBLY. The DSR   
VMACHSM         and VSR have new fields, VSR fields (VSRTBAK,VSRTALC,   
Jul 24, 1991    VSRNDSV, and VSRTCPU), are now reserved, and bit fields 
                are now decoded into new variables.  MXG supports not   
                only HSM 2.6, but also HSM 2.4 and 2.5 SMF records.     
   Thanks to Joseph J. Faska, Depository Trust, USA                     
Change 09.096  VM/XA messages "LOGICAL RECORD SPANS PHYSICAL BLOCK" are 
VMACVMXA        incorrectly printed on the log. The error was introduced
Jul 22, 1991    by Change 8.244; line 005970 must be (COL-5+MRHDRLEN).  
                Fortunately, the datasets built were valid, but the MXG 
                messages sure filled pages of your log!                 
   Thanks to Rob Owens, SAS Institute Europe, GERMANY.                  
   Thanks to ???, ???.                                                  
Change 09.095  BUILDPDB is enhanced by the automatic addition of the    
BUILDPDB        dataset TYPE0203 in your PDB, so you can keep track of  
BUILDPD3        when SMF data was dumped; a type 2 record is written at 
VMAC0203        the start of each SMF dump (IEASMFDP) and a type 3 is   
Jul 21, 1991    written at the end of each dump.  Back to back type 2s  
                indicates probable duplicate data, because a dump was   
                started but failed to complete.  Member VMAC0203 was    
                also changed, to create variable RECNUM, the record     
                number of each 2 or 3 record, in case you need to strip 
                out duplicated records.                                 
Change 09.094  The _SMF macro, used by all SMF processing programs, now 
VMACSMF         prints a message on the log "MXG SUCCESSFULLY READ SMF" 
Jul 21, 1991    with the number of records AND the number of megabytes  
                of data that was found in your SMF file.                
Change 09.093  This revision of existing TRND72 member adds several new 
TRND72          MVS/ESA 4.2 variables to the TREND.TRND72 dataset.      
Jul 20, 1991                                                            
   Thanks to Chuck Hopf, Primerica, USA.                                
Change 09.092  Trending of TYPE71 data is added by this change, using   
TRND71          the WEEK.TYPE71 dataset as input.  (Since the TYPE71    
Jul 20, 1991    data already exists as one observation per interval,    
                there is no need for an "ASUM71" member.)               
   Thanks to Chuck Hopf, Primerica, USA.                                
Change 09.091  Trending of PR/SM, MLPF or MDF data in TYPE70PR is added 
ASUM70PR        by this change.  Member ASUM70PR creates PDB.ASUM70PR by
TRND70PR        summarizing TYPE70PR into one observation per interval  
Jul 20, 1991    for each system.  (If you have more than one MVS system 
                running, remember that each one creates observations in 
                TYPE70PR for each SYSTEM.  Either SYSTEM or LPARNAME has
                to be used to avoid duplication in your reporting. MXG  
                keeps all SYSTEMs found in TYPE70PR).  Member TRND70PR  
                takes the WEEK.ASUM70PR, and adds its new data to the   
                TREND.TRND70PR data, which can be used for tracking the 
                utilization of all your LPARs.                          
   Thanks to Chuck Hopf, Primerica, USA.                                
Change 09.090  ASUMCICS used more temporary work space than needed, as  
ASUMCICS        some variables were not dropped, and no LENGTH statement
Jul 20, 1991    was used.  After line 003400 (DATA NULLCICS;) insert    
                  LENGTH DEFAULT=4 ENDTIME STRTTIME 8;                  
                After line 009199 (END;) insert                         
                       SYSID TRANSACT;                                  
Change 09.089  VM/XA Trending variables PFXUTIME and PCTCPUBY were not  
TRNDVMXA        correct.  PFXUTIME was wrong because it should be in the
Jul 18, 1991    NORM13 list instead of NORM1. PCTCPUBY was wrong because
                it is recalculated and uses PFXUTIME!                   
   Thanks to ???, 3M Europe, GERMANY.                                   
Change 09.088  Amdahl's Cache DASD SPMS Release 1.2 completely rewrote  
EXTYSPMC        their user SMF record. The original VMACSPMS supported  
EXTYSPME        SPMS Release 1.0, but that code was temp VMACSPM0, and  
VMACSPMS        VMACSPMS now contains support only for SPMS 1.2.  There 
                are two data sets created now, SPMSCED "Cache Extent    
Jul 18, 1991    Definition" statistics, for each CED (which might be an 
                entire volume, or just a data set), and SPMSEXT "Cache  
                Extent" statistics, for each EXTent (which will normally
                contain one observation for each CED, unless the dataset
                in the CED is itself in extents).  Although statistics  
                can be captured in the CED part of the record, there is 
                an option to disable statistics in the CED, so MXG will 
                create the sum of the EXT data and store into the CED   
                dataset, which seems to be the most likely dataset of   
                general interest, and by summing the EXT data into the  
                CED, either data set will be valid.  Note that some of  
                the fields may not be valid; SPMSATBC contains negative 
                values.  Amdahl is investigating.                       
   Thanks to Elliot Weitzman, Oryx Energy Company, USA.                 
Change 09.087  Only comments were changed in IMACFILE, but the example  
IMACFILE        showing how to write SMF records out to an OS file now  
Jul 18, 1991    has a FILE LOG; statement after the PUT _INFILE_ so that
                and error messages PUT by MXG will be sent to the log.  
                Without the FILE LOG; statement, error messages were    
                written to the output SMF file!                         
   Thanks to Brenda Rabinowitz, Prudential-Bache Securities, USA.       
Change 09.086  ACF2 records with ACSMFREC='L' and ACSMFCN GE 3 were not 
VMACACF2        processed.  They are now output in the ACF2JR dataset.  
Jul 18, 1991    The LID at the end of these records is not currently    
                decoded; since the records themselves were not output,  
                it is not clear the contents of the LID are needed, but 
                that will change if users request it!  The change was to
                change ELSE IF ACSMFREC='L' AND ACSMFFCN LE 2 THEN DO;  
                to     ELSE IF ACSMFREC='L' THEN DO; in line 049400, and
                change IF ACSMFFCN=2 THEN DO;                           
                to     IF ACSMFFCN GE 2 THEN DO;  in line 050200.       
   Thanks to Rachel Bromage, L.O.L.A., ENGLAND.                         
Change 09.085  Early Address Spaces (Started Task ASIDs that come up    
VMAC6          before SMF is fully up) have no JES number and their     
VMAC26J2       JCTJOBID variable contains job name.  The logic added in 
VMAC26J3       MXG 8.8 to support the APPC TYPETASK tested JCTJOBID to  
VMAC30         see if it started with an "A", but this caused "Invalid  
VMAC32         Data Error" for JESNR if the STC happened to start with  
Jul 18, 1991   an "A" (like ACF2!).  This change reorders the logic to  
               first recognize an early address space (JCTJOBID=JOB)    
               to set TYPETASK='STC ' and JESNR=., or otherwise use the 
               original logic to determine TYPETASK and JESNR. The only 
               impact were messy record dumps on the log when MXG tried 
               to read characters as numbers!                           
   Thanks to Stephen Tull, State Energy Commission of W.A., AUSTRALIA.  
Change 09.084  For consistency in CICS, variable PCLOADCN was changed.  
VMAC110        Its old contents, the count of load requests, was moved  
Jul 18, 1991   to new variable PCLOADCT, which will be non-missing in   
               all CICSs, and the old variable PCLOADCN contains the    
               count of actual loads.  The change occurred in MXG 8.8   
               but was not documented.                                  
   Thanks to Ms. Ericson, EDV Gmbh, Vienna, AUSTRIA.                    
Change 09.083  In Newsletter SIXTEEN, I made mention of APAR OY16896,   
BUILDPDB       but did not elaborate on its significant effect on lines 
VMAC6          printed counting in MXG.  The APAR changes the variable  
Jul 17, 1991   OUTDEVCE (SMF type 6 field SMF6OUT).  Formerly, OUTDEVCE 
               was the name of the output device to which the print was 
               sent, e.g., PRINTER1, PUNCH2, or R196.PR1 for a remote   
               printer, R196.PU1 for a remote punch (remember, external 
               writers for microfiche and other devices often "punch"). 
               The APAR changed OUTDEVCE to contain the VTAM LUNAME of  
               the printer, which no longer contains indication of the  
               type of device to which print was sent.  MXG still uses  
               OUTDEVCE to create variable DEVICE in TYPE6, setting     
               DEVICE='PRINT' (if OUTDEVCE starts with 'PRINT' or 'PRT' 
               or contains '.PR', or UCS starts with 'VPS, or setting   
               DEVICE='PUNCH' (if OUTDEVCE starts with 'PUN' or         
               contains '.PU'). If no match is found in OUTDEVCE, then  
               MXG sets DEVICE='EXT WTR'.  The APAR not only changes    
               the contents of variable DEVICE in TYPE6, but BUILDPDB   
               uses the value of DEVICE to decide if NRLINES are put    
               in variables PRINTLNE, PUNCHCRD, OR EXTWTRLN in both the 
               PDB.JOBS and PDB.PRINT data sets. The total of those     
               three variables will still be correct, but you cannot    
               trust PRINTLNE to contain print lines; all of the lines  
               printed could end up in variable EXTWTRLN.               
               If the breakout is important to your site, you will have 
               to first create a table look up mapping VTAM LUNAME to   
               the type of device, and use that table in member EXTY6   
               to set DEVICE= to the correct device type for your site. 
               As long as you use the SUM(PRINTLNE,PUNCHCRD,EXTWTRLN)   
               for TYPE6 or PDB.PRINT analysis/billing, there is no     
   Thanks to Susan Marshall, SAS Institute Europe, GERMANY.             
Change 09.082  Interlink's product SNS/vt is actually the ANET product  
VMACILKV       from Teubener Associates, and is also marketed by Mitek  
Jul 17, 1991   (now Open Connect Systems) as Telenet Client Fullscreen! 
               By whatever name, however, the disconnect record has a   
               bug (CONECTIM does not contain a date) that is now fixed 
               in their release 322.                                    
   Thanks to Dan Barbatti, Southwestern Bell St. Louis, USA.            
Change 09.081  EPILOG CICS CL1000 records, by default, are dumped by    
IMACEPIL       Candle's utility as RECFM=U, even though the records are 
Jul 16, 1991   actually internally VB, with BDW=600 and RDW=LRECL=596.  
               The only problem with RECFM=U is that when written to a  
               tape data set, lots of space is wasted between these     
               600 byte records.  Sites have, therefore, chosen to      
               change the output RECFM of the Candle dumping program to 
               specify VB, reducing storage on tape from 5 volumes to a 
               single volume, but this creates an additional BDW/RDW on 
               the tape, a "VVBB" RECFM!  MXG has always handled these  
               two formats; if the output is dumped with RECFM=U then   
               OFFEPIL=0 is specified in IMACEPIL, and if the output is 
               dumped with RECFM=VB, then OFFEPIL=4 handles the extra   
               four bytes on each record, but only now do I realize in  
               which case which offset is specified in IMACEPIL!        
   Thanks to Myron Highfield, Square D, USA.                            
Change 09.080  Some new DB2 variables in DB2STAT0/DB2STAT1 were not     
DIFFDB2        deaccumulated.  QLSTx, QWTRx, QW2x-QW5x, Q9STCTRI,J,K,L  
               QXMRMIAP,QXMSMIAP,QXNSMIAP in DB2STAT1 are now correct.  
   Thanks to Elliot Weitzman, Orxy Energy Company, USA.                 
Change 09.079  Data set TYPE30_D can contain duplicate observations, if 
BUILDPDB       the same DDNAME appears multiple times in a step record. 
BUILDPD3       The NODUP option was removed from the PROC SORT of the   
Jul 11, 1991   TYPE30_D into the PDB.DDSTATS to prevent unintentional   
Change 09.078  SAS 6.06 circumvention.  In SAS Version 5, a DO variable 
VMACCMF        could be missing, and SAS treated the value as zero. In  
VMXGHSM        SAS Version 6, however, a missing value for one of the   
Jul 10, 1991   DO loop variables raises a syntax error and terminates   
               execution.  This problem was simultaneously encountered  
               in two unrelated members on the same day!                
             a.In VMXGHSM, before the DO C= 1 TO MPCDGNCT; insert       
                 IF MCPDGNCT=. THEN MCTDGNCT=0;                         
               Unrelated VMXGHSM corrections were also made.            
                 MCDCLU should have been spelled MCDDLU. INPUT          
                 MCTFRAG PIB2 should have been PIB2. (with a period).   
                 DCRDATEX should have been DCRDATE.                     
                 MCVLSPCT should have been INPUT as PIB4.2, and the     
                 subsequent DMS function deleted, as it was not PK4.    
                 DSRTIME  should have been INPUT as PIB4.2, and the     
                 subsequent DMS function deleted, as it was not PK4.    
             b.In VMACCMF,  before the DO on _I_, insert                
                 IF CMFWPTR=. THEN CMFWPTR=0;                           
                 IF CMFCHKTG=. THEM CMFCHKTG=0;                         
               and four lines later, change IF CMFCHKRM NE 0 ....       
               to read                      IF CMFCHKRM GT 0 ....       
   Thanks to Ray Dickensheets, Yellow Freight System, USA.              
   Thanks to Bill Dempster, UOP, USA.                                   
Change 09.077  The macro _CICEXCL referenced at the end of IMACCICS was 
IMACCICS       only used in MXG testing and should have been removed.   
Jul  9, 1991   All of the installation controls for EXCLUDE processing  
               are contained in member IMACEXCL.                        
   Thanks to Tim Cartwright, University of Wisconsin Madison, USA.      
Change 09.076  Option NOTEXT82 was never in SAS 6.06, and is removed    
CONFIG         from MXG's CONFIG member.  It caused no execution error, 
Jul  4, 1991   but confused users who tried to figure out what it was.  
               It should not have been in CONFIG in the first place!    
Change 09.075  This is a document change, pending IBM answers. The two  
VMAC42         fields SMF42LFW and SMF42CFW are now acknowledged by IBM 
Jul  4, 1991   to be accumulators and not counts for the interval. They 
               have not yet acknowledged this as a bug or a feature!    
   Thanks to Joseph J. Faska, Depository Trust, USA                     
Change 09.074  Boole's unique CMF record processing member needs a      
VMACCMF         RETURN; statement inserted immediately before the label 
Jul  4, 1991    CMFCKSM: statement.                                     
   Thanks to Bill Dempster, UOP, USA.                                   
Change 09.073  Change 8.213 gave an example for using INSTREAM DDNAME   
CHANGE08       to create the _DAY macro for copying yesterday's PDB to  
Jul  4, 1991   the correct day-of-week PDB, but the example failed to   
               execute.  First, the OPTIONS NOTITLE; statement should   
               be deleted (that options no longer exists). Second, the  
               PRINT option in the FILE INSTREAM statement should be    
               NOPRINT.  Third, a blank is required after _DAY in the   
               quoted string:  'MACRO _DAY ' to be written to INSTREAM. 
               The example has been corrected in member CHANGE08 so you 
               could copy it for execution. Finally, under SAS 6.06+.   
               is required because the PUT function returns mixed case. 
   Thanks to Mark Steeley, Anthem Insurance.                            
Change 09.072  TYPE70PR data for DEDICATED='Y' LPAR's LCPUADDR 2 and 3  
VMAC7072       incorrectly subtracted CPUWAIT0 in lines 134620,134660.  
XMAC7072       The obvious typing error should have subtracted CPUWAIT2 
Jul  4, 1991   and CPUWAIT3 respectively, and came in MXG 8.8.          
   Thanks to Helmut Kirrmaier, Comparex Mannheim, GERMANY.              
Change 09.071  VLFHITPC hit percentage was conditionally calculated if  
VMAC41         SMF41SRC was non-zero, but should also have been set to  
Jul  2, 1991   missing with an ELSE clause. Without the ELSE clause, if 
               the record had classes with no activity, the prior class 
               value for VLFHITPC was carried forward.                  
   Thanks to Dan Squillace, SAS Institute Cary, USA.                    
Change 09.070  TYPE72 new CPU variables CPUHPTTM,CPUIIPTM CPURCTTM,     
VMAC7072       added by MVS/ESA 4.2, are wrong.  Lines 157900-158200    
XMAC7072       must INPUT these three variables as PIB4.6 instead of    
Jul  2, 1991   PIB4., and then each variable must be multiplied by      
               1.024 after the input statement.  This error also made   
               the variable CPUTM, as it includes these three. Note:    
               see revision in Change 9.120.                            
======Changes thru 9.069 were on MXG 9.2 built July 1, 1991=============
Change 09.069  Candle's External Security Audit SMF record needs a ZAP  
VMACOMAU       from Candle, OB270S10 to capture the DB2 Subsystem ID if 
Jun 30, 1991   an Omegamon DB2 command is being audited; otherwise you  
               will not know which DB2 subsystem was the object of the  
               Candle command that was issued.  Even with the ZAP, the  
               subsystem ID is not put in the right place; instead of   
               in being in MXG variable OMSUBSID where it belongs, the  
               ID value is stored in MXG's variable OMSTEP.  No change  
               was made to MXG to move it to the right field, Candle    
               has not called, and the zap and this note may be enough. 
   Thanks to Wayne Cope, Belks Stores, USA.                             
Change 09.068  CA's IDMS Performance Monitor SMF records appear to be   
VMACIDMS       in error. TASPAGRD contains 'FFFFFFFB'x, which MXG sees  
Jun 30, 1991   (inputing at PIB4.) as 4,294,967,040, and the Cullinet   
               report (no, they have not changed the report header yet) 
               shows a negative 4.  Separately, the TASIMWT wait time   
               duration is sometimes greater than the delta between the 
               STARTIME and ENDTIME.  No MXG change was made to deal    
               with what appear to be IDMS errors. Stay tuned.          
   Thanks to Elizabeth Stronge, Michelin Tier Corp, USA.                
Change 09.067  Trending TYPE72 data did not contain PERFRPGN, so you    
TRND72         could not know which performance groups were control and 
Jun 30, 1991   which were report (unless you resorted to an external    
               table or format).  This change added PERFRPGN to the ID  
               statement so it will now exist in trended TYPE72 data.   
   Thanks to Seymour J. Metz, EDS, USA.                                 
Change 09.066  SAS 6.06 does not support concatenated Format libraries  
FORMATS        (since they are now SAS datasets, which still cannot be  
IMACFMTS       concatenated).  New tailoring member IMACFMTS is created 
Jun 30, 1991   to allow you to put your installation's VALUE statements 
               in this separate member of your USERID.SOURCLIB.  The    
               member IMACFMTS is %INCLUDEd at the end of MXG's member  
               FORMATS so that your formats will be placed in the same  
               data library as the MXG formats.  One suggested use was  
               to define performance group mapping in this member.      
   Thanks to Seymour J. Metz, EDS, USA.                                 
Change 09.065  DASDMON/ASTEC load counts RLDCNT and RDLCNT in VMACDMON  
VMACDMON       should have been input PIB4.2 instead of PIB4., though   
Jun 30, 1991   there was no clue in the DSECT documentation. Only the   
               observed very large values and comparison with Legent's  
               reports uncovered their documentation error.             
   Thanks to Greg Scriba, First National Bank of Chicago, USA.          
Change 09.064  This significant user contribution is a 15-member PDS in 
ANALRACF       member ANALRACF that will analyze the use of MXG TYPE80  
VMAC80         observations for the use of RACF commands with SPECIAL   
Jun 30, 1991   or OPERATIONS authority.  Documentation and flow of the  
               programs are contained in member ANALRACF.  Three new    
               variables were added to the TYPE80 KEEP= list, NRSET,    
               RACFDAT1, and RACFVRMN, to support these reports.        
   Thanks to Duncan McKellar, Inland Revenue (UK), ENGLAND.             
   Thanks to Neil Campbell, Inland Revenue (UK), ENGLAND.               
   Thanks to Dave McLaughlin, Inland Revenue (UK), ENGLAND.             
Change 09.063  Yet another problem with IMS Input Queue time was found. 
TYPEIMS        Out of 22,000 transactions, type 35x log records for 18  
VMACIMS        transactions contained the LTERM value in the NODENAME   
Jun 29, 1991   field, causing the 35x (ENQTIME) to not be matched with  
               the 01x (ARRVTIME) record.  These 18 records all have an 
               ENQFLAG=0Cx and FLAG2=ACx, and had CLBNAME=LTERM and 16  
               bytes later, the NODENAME needed was found in the "Input 
               subpool name" part of IBM's QLNQLNID (and, as usual for  
               IMS, there is no indication in the IBM IMS DSECT of this 
               condition). MXG has again been patched to support this   
               IMS variation.  Another change, unrelated, had been left 
               out of the MXG 8.8 changes; for Multi-Transactions per   
               schedule, the CONDCODE was propagated into all IMSTRAN   
               observations; now it is blank until the final one. And   
               occasional negative service times for Multi-Trans and    
               WFI transactions were corrected by not re-setting the    
               ENDTIME to an incorrect earlier value.  I always want    
               to think each IMS fix is the last one, but I have little 
               doubt that there will be future discoveries.  But then   
               even IBM's IMSPARS is frequently unable to correctly     
               count transactions, and frequently can't figure out the  
               time stamps that MXG can locate in the log records, so   
               it is clearly not straightforward to decode the IMS log, 
               in which the records are written out of order by time!   
               I do believe there have never been errors in MXG's IMS   
               resource capture (CPU, DLI, counts, etc.), and only in   
               the Input and Output Queue times have there been wrong   
               calculations, and statistically few in number. This does 
               suggest STRONGLY to avoid using average values for the   
               analysis of IMS response, service, and queue times. One  
               large value can completely distort the average value,    
               but counting the percentage that completed in a specific 
               duration will not be so affected, and is much safer to   
               report.  Even at its very best, though, the IMS log is   
               NOT the recommended source for IMS analysis; at best it  
               provides only one single measure of CPU time for each    
               program schedule (which might represent hundreds of real 
               transaction), and that CPU time cannot be subdivided     
               into Message Region, DB2 services, DL/I services, etc.,  
               which can and are captured currently by third-party IMS  
               monitors which write discrete transaction records for    
               analysis.  Sites to whom IMS is a significant workload,  
               and especially sites with WFI, Fast Path, or lots of     
               multi-trans per sked activity should invest in an IMS    
               monitor until IBM decides to provide transaction-level   
               resource and response time recording in the IMS log.     
   Thanks to Lindsay Dawe, Mobil Oil, AUSTRALIA.                        
Change 09.062  CICS/ESA 3.2.1 became available today. MXG now supports  
VMAC110        all releases of CICS from 1.5 thru CICS/ESA 3.2.1.       
Jun 28, 1991   In fact, due to IBM's ETP program, MXG 8.8 contained     
               support for CICS/ESA 3.2.1, and thus you do NOT need to  
               install a new release of MXG just for CICS/ESA if you    
               have already installed MXG 8.8.  Versions of MXG before  
               MXG 8.8 will fail with CICS/ESA 3.2.1 records, because   
               3.2.1 records were changed incompatibly (CICS version    
               SMFPSRVN was changed from an EBCDIC field containing 31  
               to a PK2. field containing 321). That incompatibility    
               is actually beneficial; finally we can recognize the     
               version, release, and modification-level of CICS. The    
               other changes between last fall's CICS 3.1 and 3.2.1     
               are minor, but a new timestamp, taken at CICS startup,   
               was added to the type 110 record, used to collect all    
               records from a specific execution of a CICS region. It   
               would really been useful if IBM had stored, not the STCK 
               value when CICS started, but instead had copied the      
               READTIME of the CICS job (which already exists) because  
               then CICS SMF could be directly MERGED/JOINED with the   
               other SMF records (like 14,15, and 64 I/O records) that  
               have contained READTIME for the "Job Log" since day 1    
               of SMF data!  Oh, well, something's better than nothing! 
Change 09.061  Support for NetView Performance Monitor NPM 1.4.1 is     
EX028INA       added by this last-minute change (the product became     
EX028INB       available today, and I received the IBM documentation    
EX028INC       two days ago!) which has been syntax tested, but has     
EX028IND       not actually read any SMF records with the new data      
EX028EV3       segments.  Prior versions of MXG should not fail with    
EX028EV4       the new records, but the SAS log will contain many       
EX028EV5       MXG notes that unexpected subtypes 0B, 72-77x, 90-96x,   
EX028NTN       and FAx were found.  Eight new NPM datasets are created, 
VMAC28         but none of the existing data sets appeared to have been 
Jun 27, 1991   changed after a brief review of the new documentation.   
               MXG documentation of the new datasets is in comments at  
               the beginning of member VMAC28. IBM's documentation is   
               on pages 285-411 of NPM Installation and Customization,  
Change 09.060  This graphic analysis program failed if you specified    
GRAFTRND        SASGRAPH=NO and SASSTAT=YES.  Line 038700 should be     
Jun 27, 1991   DATA=PERCENTS instead of DATA=PRED1, and line 044800     
               should be DATA=TIMES instead of DATA=PRED1.              
   Thanks to Jim Ray, National Council on Compensation Insurance, USA.  
Change 09.059  The two PROC SUMMARYs in this analysis of TMS catalog    
ANALTMS5       records worked fine in small shops, but with a large     
Jun 26, 1991   number of devices and volsers, they ran out of virtual   
               addressability (i.e., virtual memory), because a CLASS   
               statement was used.  The CLASS statement needs storage   
               in virtual memory for every possible combination of the  
               class variables data values; it creates all possible     
               answers in virtual memory, and then decides how many of  
               the answers you really wanted.  With three variables in  
               a CLASS statement, if each variable has 100,000 unique   
               values (e.g., a TMC catalog of 100,000 tapes VOLSERs),   
               there are 10**15 cells needed per statistic calculated!  
               One of the historic virtues of the SAS System, in my     
               opinion, was that by being what I called "data driven",  
               SAS could solve problems that broke the back of these    
               "memory driven" algorithms.  As long as you could first  
               afford to PROC SORT your data, you could summarize and   
               analyze any number of groups with a PROC MEANS with a    
               BY statement. Being "data driven" is the solution to     
               this ANALTMS problem.  By changing the "CLASS" to "BY"   
               following the two PROC SUMMARY statements you change the 
               architecture from "memory driven" to "data driven", and  
               the virtual memory is now independent of the number of   
               by groups in your data.  Although the TMS.TMS dataset    
               was already built SORTed, so in general you do not need  
               an extra sort to summarize, I chose to ensure the sort   
               order by inserting PROC SORT before the PROC SUMMARY.    
               However, a PROC SORT was required for the second PROC    
               SUMMARY, but its input dataset was already a summarized  
               temporary data subset of the original TMS.TMS dataset.   
               Since PROC MEANS now actually invokes PROC SUMMARY, this 
               reminder is not about PROC SUMMARY itself, but rather it 
               contrasts the "in memory" CLASS statement algorithm to   
               the "data driven" BY statement implementation.  For MXG  
               data, the BY statement implementation is recommended, as 
               we DO have many possible unique values, and being "data  
               driven" not only uses fewer CPU and I/O resources, but   
               of perhaps even greater importance, being "data driven"  
               means that your daily production reports use exactly     
               the same amount of virtual memory every day, and they    
               will not awake you at 3am because today's data happened  
               to have more unique values then your test job (you know, 
               the one you tested in a 4MB region yesterday afternoon!) 
Change 09.058  The sample code in comments that could be used to build  
RMFINTRV       RMFINTRV directly from SMF records did not have the BY   
Jun 26, 1991   list correct for TYPE70PR dataset, causing SAS to think  
               there were duplicate records. The BY list now matches    
               its BUILDPDB counterpart.                                
   Thanks to Chuck Hopf, Primerica, USA.                                
Change 09.057  Semicolons were missing at the end of lines 032300 thru  
VMACTMS5       032500 in VMACTMS5 and lines 019700 thru 019900 in       
               VMACTMS, after support for CA/1 Release 5 was added.     
Jun 26, 1991                                                            
   Thanks to Chuck Hopf, Primerica, USA.                                
Change 09.056  Support for the eleven subtypes of the NETVIEW FTP (file 
EXFTP01X       transfer program) User SMF record creates eleven FTP...  
EXFTP02X       MXG data sets, one per subtype, from FTP R1.0.           
EXFTP03X       The FTP support uses the new "subtype-level-processing"  
EXFTP04X       MXG architecture, which will be used for all future      
EXFTP11X       development, and eventually will be retrofitted into all 
EXFTP12X       of the existing products which create record subtypes.   
EXFTP21X       The specification and naming conventions of this new MXG 
EXFTP22X       architecture is presently contained in member VMACFTP,   
EXFTP23X       but these initial descriptions will be elaborated into   
EXFTP24X       a formal MXG architecture specification member later.    
EXFTP25X       "Subtype-level-processing" is completely compatible with 
FORMATS        the existing MXG "record-level-processing" architecture, 
IMACFTP        and most sites won't even notice the difference, but for 
TESTUSER       records with lots of subtypes, the change is required to 
TYPEFTP        maximize the flexibility and optimize the construction   
VMACFTP        of MXG programs in the future.                           
Jun 24, 1991   FTP just happened along at the right time!               
   Thanks to Stephen Bell, Bunchungszentrale der westfalisch, GERMANY.  
Change 09.055  Another MXG error caused STOPOVER with MVS/ESA 4.2 type  
VMAC78         78 subtype 3 records because line 171600 should have     
Jun 23, 1991   been @; instead of just a semicolon.  At the same time,  
               the ?? format modifier were added to the input for the   
               IODFDATE/IODFTIME variables to eliminate the INVALID     
               DATA messages.  Mini-tutorial on SAS hex dumps:          
                The hex dump produced by this error was not for a type  
                78 record, but instead contained a type 74 record.      
                The PUT _ALL_ list of variable=value after the dump     
                showed the _N_ value of 4, but the number on the hex    
                dump CHAR line was 5!  The _N_= value is the accurate   
                indicator, and shows when the error occurred, and only  
                if the _N_= value equals the hex dump's record number,  
                do you know the dumped record is the problem record.    
                Why did SAS dump the next record? I don't know why,     
                but for some logic errors, SAS reads into the next data 
                record before realizing it has switched records, and so 
                when it goes to dump the record currently in its buffer 
                it has already gone past the problem record.            
   Thanks to Tom Parker, Hogan Systems, USA.                            
Change 09.054  MXG 9.1 corrections for MVS/ESA 4.2 in Change 9.001 were 
VMAC7072       inconsistent.  Part b was in XMAC7072 but not VMAC7072,  
XMAC74         and parts d and e were in VMAC74 but were incorrect in   
Jun 23, 1991   XMAC74.  Only MVS/ESA 4.2 records were affected.         
   Thanks to Diane Eppestine, Southwestern Bell, USA.                   
   Thanks to Dan Barbatti, Southwestern Bell, USA.                      
Change 09.053  The PROC DATASETS DDNAME=VMXGVVDS ... should have been   
ANALVVDS            PROC DATASETS DDNAME=MXGVVDS                        
Jun 21, 1991                                                            
   Thanks to Ray Dickensheets, Yellow Freight System, USA.              
Change 09.052  SAS 6.06 Usage Note 2066 discusses an unfixed error that 
VMAC37         causes the SAS CHARCODE option (see SAS 6.06 Language    
ANALDBTR       guide page 741) to unexpectedly replace characters that  
ANALPDSM       are inside a comment block.  In VMAC37, a  ?-  inside a  
BUILDPDB       comment block was replaced by an underscore, reducing    
BUILDPD3       the source line by one byte, which moved the line number 
TESTUSER       from column 73 to column 72, causing a syntax error!     
VMACACF2       MXG did not know of this vulnerability and just happened 
VMACTEST       to have the ?- in a comment.  Nine other MXG members had 
VMAC110        either ?- or ?) pairs in comments, and all have been now 
VMXGHSM        changed to avoid the exposure until 2066 is fixed,       
Jun 19, 1991   although SAS option NOCHARCODE could probably been used. 
   Thanks to Willie Antman, Federal Deposit Insurance Corporation, USA. 
Change 09.051  Shared Medical System's CICS application creates its own 
IMACEXCL       header segment with an unexpected MNSEGCL value, which   
VMAC110        caused MXG to fail.  These segments were detected and    
Jun 19, 1991   skipped over with the first part of this change, but MXG 
Jun 27, 1991   still failed with SMS CICS records, because they use the 
               CICS EXCLUDE option to exclude some fields from their    
               transaction record.                                      
                 You can tell a region has EXCLUDEd fields if the value 
                 of MCTSSDRN in the MXG error message is 60 or less;    
                 a minimum of 61 fields are in non-EXCLUDEd CICS data.  
               The previous "support" in MXG for EXCLUDE/INCLUDE was    
               marginal at best, was not externalized, and actually     
               required you to create a modified copy of VMAC110!       
               Because MXG promised to fix every Error condition, the   
               second part of this change completely redesigned the MXG 
               support for CICS EXCLUDEd fields, and now provides an    
               externalized tailoring member, IMACEXCL, that permits    
               processing a multiplicity of different CICS regions that 
               can even have different EXCLUDEs.  IMACEXCL not only is  
               the documentation for this MXG support, it also contains 
               the code to read the SMS transaction records and shows   
               how changing only one line in your IMACEXCL will enable  
               SMS record processing for two specific APPLIDs.          
   Thanks to Phil Shelley, Jewish Hospital HealthCare Services, USA.    
   Thanks to Tim Cartwright, University of Wisconsin - Madison, USA.    
Change 09.050  WEEKBLD job failed when automatically submitted by a job 
Submitting     but ran without error when submitted from TSO.  Adding   
Jun 19, 1991   DCB=(RECFM=FB,LRECL=80,BLKSIZE=8000) to the DDNAME in    
               the submitting job that points to the INTRDR solved the  
               problem. Without that DCB, the SYSIN dataset that SAS    
               tried to read had VBA or VS attributes, and SAS failed   
               with "Undetermined I/O Failure".  By the way, that I/O   
               error from SAS always means the error is in a "flat"     
               file (SYSIN, or INCLUDEd, or FILE/INFILE), and is not    
               related to I/O to/from a SAS data library.               
Change 09.049  Execution of MXG 8.8 under SAS 6.06 under MVS/370 (i.e., 
SAS 6.06        pre-MVS/XA) is possible for BUILDPDB, but testing and   
Jun 19, 1991    validation is still on-going.  This note identifies the 
                current recommendations for SAS 6.06 under MVS/370.     
               -Use maximum REGION size you can possibly get.           
               -Specify OPTIONS BLKSIZE=1024 BUFNO=1;  to minimize the  
                virtual storage (but at the cost of additional I/O and  
                CPU time).                                              
               -Change CONFIG member to specify MEMSIZE=6M (because SAS 
                will try to get more, even when it doesn't exist on your
                370 system).                                            
               -Add SAS option MINSTG to the CONFIG member (to free up  
                storage after each PROC/DATA step).                     
               -Let me know if it works.  Last site testing got through 
                to building the SPUNJOBS before memory failure, and has 
                not yet reported if MINSTG solved their problem.        
   Thanks to Moji Varian, Congressional Information Services, USA.      
Change 09.048  The MXG circumvention for IBM's DFP type 42 records in   
VMAC42         Change 9.024 protected the STOPOVER condition, but the   
Jun 19, 1991   MXG test for wrong record length was invoked first, and  
               the bad records were thrown away instead of processed    
               (after a message was printed on your log, however).      
               This enhancement protects the STOPOVER and prevents the  
               MXG message on the log.  In addition, the PIB8. fields   
               in the subtype 1 (written only if you have PDSE enabled) 
               are now input as ?? 8. instead of PIB8.  There is still  
               a long series of questions at IBM DFP, because some of   
               the statistics (but not all) appear to be accumulated    
               across records, and the "Current" time stamp is several  
               minutes earlier than the SMF timestamp.  Two APARs now   
               exist for the type 42, OY39393 and OY44995, and when     
               PTFs exist, they should be installed.                    
   Thanks to Joseph J. Faska, Depository Trust, USA                     
Change 09.047  TYPE78CU IO Queuing data will be missing if microcode    
VMAC78         level CP HH0124 has been installed.  The fix to IBM's    
Jun 19, 1991   firmware is microcode level CP HH0130.                   
   Thanks to Miller Dixon, Continuum, USA.                              
Change 09.046  TYPE6156 variable ACTION is not consistent with the type 
VMAC6156       of function creating the respective record, according to 
Jun 19, 1991   IBM APAR OZ82412 (1985!). MXG variable ACTION decodes    
               SMF6xSUB into INsert, DElete, or UPdate, but the APAR    
               says the field is valid only in the type 60 VVDS record  
               and is invalid in type 61, 65, or 66 records.  Sister    
               APAR OZ82414 also claims that SMF6xFNC and SMF6xTYP are  
               equally invalid (which MXG decodes into FUNCTION and     
               ENTTYPID respectively).  In MVS/ESA 4.2 SMF manual, the  
               SMF6xFNC is now a reserved field, but both SMF6xSUB and  
               SMF6xTYP are still documented.  Your guess is as good as 
               mine, but beware!                                        
   Thanks to Dan Kaberon, Hewitt Associates, USA.                       
Change 09.045  NETSPY accounting record offset cause INPUT STATEMENT    
Jun 10, 1991   @OFFNSPY+OFFSMF+169 to read  @OFFNSPY+OFFSMF+168         
   Thanks to Doug Drain, National City Bank, USA.                       
Change 09.044  An interesting change in Connect Time ("IOTM") measures  
IOTM           was observed in GTF traces. The instance was 4K I/O, and 
Jun  8, 1991   the normal connect of 2ms per I/O was observed most of   
               the time, but occasionally the connect time was 18ms!    
               The device was a 3390 DASD behind a Model 2 3990 (i.e.,  
               non-cached CU).  The additional connect time was traced  
               to a change in IBM's handling of missed RPS reconnects.  
               Previously, IBM would simply try, and try, and try again 
               to reconnect, recording 16ms (one revolution) disconnect 
               time for each miss.  IBM has apparently implemented the  
               same scheme that other vendors use to limit reconnects:  
               after some number of misses (perhaps 2?), IBM now tries  
               continually to reconnect, and when it is finally able to 
               connect to the channel, it now SEARCHes to find the      
               desired sector and record.  SEARCH, of course, records   
               not disconnect time, but now records connect time, for   
               the device in type 74 and for the job in type 30. In     
               principle this is probably good, since it limits how     
               long your I/O can sit waiting for reconnect, but it      
               could lead to problems in repeatability of connect time  
               for I/O measurement and accounting, because now the      
               connect time is a function of channel and path conflicts 
               rather than just the amount of I/O transferred.  Since   
               multiple paths are typically available to devices, there 
               is much less probability of RPS misses now than in the   
               past, and the variability in connect time will not be a  
               significant factor in the absence of RPS misses.         
   Thanks to Bill Fairchild, Landmark, USA.                             
Change 09.043  The link edit step in ASMVTOC specifies AC=1, but later  
ASMVTOC        comments in the program state that authorization is NOT  
Jun  8, 1991   required.  The comments are correct, and the AC=1 has    
               been removed from the LKED step.                         
   Thanks to David Ehresman, University of Louisville, USA.             
Change 09.042  SAS 6.06 and MXG JCLTEST6 will fail in REGION=2048K with 
JCLTEST6       The REGION=4096K is required, but MXG JCL comments were  
Jun  8, 1991   incorrect and implied 2048K was enough. It isn't.        
   Thanks to David Ehresman, University of Louisville, USA.             
Change 09.041  Sites with TLMS may encounter 713-04 ABENDS when putting 
TLMS           SAS datasets on tape, if the TLMS installation Option    
Jun  8, 1991   named DBLTIME is set to 0!  If DBLTIME=0, TLMS does not  
Feb 25, 2006   permit "double opens", but when you build your PDB on    
               tape, SAS opens and closes each SAS dataset, which OS    
               sees as multiple opens, and TLMS inhibits.  You can set  
               DBLTIME=1 and TLMS will let the same jobname open the    
               same tape data set multiple times, as long as the time   
               between is less than one hour (DBLTIME=2 give 2 hours!). 
               Unfortunately, DBLTIME is an installation-wide option.   
               Feb 25, 2006:  Using DISP=(MOD,CATLG) instead of using   
               DISP=(NEW,CATLG) eliminated the ABEND!!!                 
   Thanks to Nancy Vance, ???.                                          
   Thanks to Terry Poole, SAS Institute Cary, USA.                      
   Thanks to Carol Arnold, BBH, USA.                                    
Change 09.040  Reading VTOC records created by ASMVTOC with VMXGVTOF,   
VMXGVTOF       even after Change 9.035 (MXG 9.1), was still incorrect.  
Jun  7, 1991   The logic of VMXGVTOC was not properly migrated into     
               VMXGVTOF, and the first extent on each volume was lost.  
               You might not have noticed the loss, if the first extent 
               was free space, but if the first extent was a real       
               dataset, the entire dataset record could have been lost. 
               The simple fix is to change VMXGVTOF as follows:         
                  was:                         must be:                 
   Thanks to Roger Edwards, South Carolina Electric & Gas, USA.         
Change 09.039  MVS/ESA 4.2 was still not fully validated, even in 9.1.  
VMAC74         Yet another error slipped thru, causing STOPOVER on type 
XMAC74         74 subtype 2 RMF records:                                
Jun  7, 1991   -Find the following statement and changes as shown:      
                   was                     must be                      
                 R742STCN $CHAR4.        R742STCN $CHAR8.               
               -There are three lines containing SKIP=OFFDDSS that must 
                be changed as follows:                                  
                   was                     must be                      
                 SKIP=OFFDDSS-52;        SKIP=LENDDSS-56;               
                 SKIP=OFFDDSS-72;        SKIP=LEN742PO-72;              
                 SKIP=OFFDDSS-44;        SKIP=LEN742MO-44;              
   Thanks to Tom Elbert, John Alden Life Ins, USA.                      
   Thanks to Dan Barbatti, Southwestern Bell, USA.                      
----Changes thru 9.038 were included in MXG 9.1 dated June 3, 1991------
Change 09.038  Support for Boole and Babbage's CONTROL-D SMF record     
ANALCTLD       is added by this user contribution.  Release 1.6.4 has   
EXTYCTLD       been processed with this data, which creates the         
IMACCTLD       CONTROLD data set.  Member ANALCTLD provides examples    
TYPECTLD       of potential reports.                                    
Jun  3, 1991                                                            
   Thanks to Brian Cobb, Credit General Industriel, FRANCE.             
Change 09.037  Variable FCOTHCN was not kept in CICSTRAN dataset, for   
VMAC110        no good reason, but now it is!                           
Jun  3, 1991                                                            
   Thanks to Herr Weismann, Zurich Versicherung Frankfurt, GERMANY.     
Change 09.036  Variable APPLID in NSPYVIRT was not kept, causing later  
VMACNSPY       report programs to fail.  Add APPLID to KEEP= list.      
Jun  3, 1991                                                            
   Thanks to Chris Morgan, Post Office (UK), ENGLAND.                   
Change 09.035  A SAS 5.18-only problem caused when SYMPUT references an 
VMXGVTOF       unreferenced variable caused VMXGVTOF to not process all 
Jun  3, 1991   extents.  The MXG circumvention is to insert the line    
                  LENGTH NOBS 4;       ahead of the   CALL SYMPUT line, 
               which satisfies the 5.18 compiler and makes the %DO loop 
               iterate.  In addition, there was a redundant PROC SORT   
               of the EXTENDS data set preceding the %DO which did no   
               harm, but did no good, and which has been removed. This  
               was a combined discovery of several SAS folks:           
   Thanks to Susan Marshall, SAS Institute Europe, GERMANY.             
   Thanks to Jan van Lent, SAS Institute, NETHERLANDS.                  
   Thanks to Waldemar Schneider, SAS Institute Europe, GERMANY.         
Change 09.034  Two exits enhance BUILDPDB tailoring so that changes to  
BUILDPDB       are externalized for sophisticated users. Exit           
BUILDPD3       EXPDB304 is taken so TYPE30_4 step variables can be      
EXPDB304       changed/added into PDB.STEPS or summed into PDB.JOBS.    
EXPDB6         is taken so TYPE6 print variables can be changed         
May 31, 1991   into PDB.PRINT or summed into PDB.JOBS.  Comments in the 
               exit member describe how it can be used. Complete tests  
               have not been completed; use with caution until this     
               note is replaced with validation results. At worst, you  
               may have to modify SPUNJOBS if you use these exits!      
   Thanks to Jane Graffum, Blue Cross Blue Shield of Massachussets, USA.
Change 09.033  Invalid NETSPY records are now protected from STOPOVER   
VMACNSPY       by comparing the expected length ENDREC to LENGTH and    
May 31, 1991   deleting bad records.  LEGENT is investigating the data  
               (NSPYREC='C' with ENTL=288 and ENTN=216-->62208 bytes    
               in a record only 21,000 bytes long)!                     
   Thanks to Wilson Wong, Salomon Technology Services, USA.             
Change 09.032  DB2 Audit Reports (PMAUD01, PMAUD02, or PMAUD03 were not 
ANALDB2R       produced if PDB=SMF was specified on %ANALDB2R.  These   
May 31, 1991   reports ARE produced if instead you use TYPEDB2/TYPE102  
               to build the datasets first, and then invoke ANALDB2R    
               with the PDB=PDB option to generate the Audit reports.   
               The PDB=SMF problem can be corrected by inserting:       
                          AND &PMAUD01 EQ NO                            
                          AND &PMAUD02 EQ NO                            
                          AND &PMAUD03 EQ NO                            
               two lines prior to each of the following lines:          
                       MACRO _DB2AC1            MACRO _DB2AC2           
                       MACRO _DB2AC3            MACRO _DB2AC4           
                       MACRO _DB2AC5            MACRO _DB2AC6           
                       MACRO _DB2AC7            MACRO _DB2AC9           
                       MACRO _DB2TC2            MACRO _DB2TC10          
               (The omission of these three lines testing if you had    
               requested an Audit report caused the PDB=SMF option to   
               generate the above Macro line, thereby causing MXG to    
               create 0 observations in the datasets needed by the      
               audit report.                                            
Change 09.031  The example JCLDASD had incorrect DDNAMEs, and ANALVVDS  
ANALVVDS       had conflicting DDNAMEs.                                 
JCLDASD        -In ANALVVDS both occurrences of PERM should be MXGVVDS, 
May 31, 1991   and the OPTIONS statement was deleted (it did not cause  
               a real problem, but it did not belong there, since it    
               would prevent you from controlling options externally).  
               -In JCLDASD step VTOC:                                   
               Comment preceding step VTOC should state                 
                  DDNAMES DISK AND MXGDASD ARE REQUIRED                 
               MXGDASD should replace PERM as the DDNAME for the SAS    
                 data set to be built,                                  
               DISK    should replace MXGDASD as the DDNAME for the     
                *.ASMVTOC.VTOCDUMP dataset, and                         
               -In JCLDASD step VVDS:                                   
               Comment preceding step VVDS should state                 
                 DDNAMES SMF AND MXGVVDS ARE REQUIRED                   
Change 09.030  DB2 Reports have several values that are incorrect by a  
ANALDB2R       factor of two. The error only affects these variables:   
                  QISEFREE QISEDBD  QISESKCT                            
               The correction (fortunately) is simple.  Delete all      
               15 occurrences of 2* in member ANALDB2R!  I am really    
               embarrassed by this error due to incorrect testing.      
   Thanks to Siegfried Trantes, Gothaer Versicherungsbank VVAG, GERMANY.
Change 09.029  The MXG PDS Printing utility ALWAYS printed the SOURCLIB 
VMXGPPDS       PDS because "PROC SOURCE INDD=&PDSIN ..." should have    
May 31, 1991   been used instead of INDD=SOURCLIB!                      
Change 09.028  Preliminary trend data base support for VMXAINTV dataset 
TRNDVMXA       has been added.  Note that the trending supports only a  
May 31, 1991   single VM/XA system.  If you have multiple VM/XA systems 
               they must be separately processed and trended; I am open 
               to suggestions for the creation of a "SYSTEM" variable   
               that would allow separate VMXAINTV datasets to be added  
               to a common VM/XA trend data base.  The TRNDVMXA member  
               existed in MXG 8.9, but had warnings not to use, because 
               of Variable Not Found messages.  If you remove variables 
               PFXIDSER and PFXIDMDL from the SUMBY= statement in 8.9,  
               you will then have the MXG 9.1 version of TRNDVMXA!      
Change 09.027  Complete online documentation of MXG datasets has begun! 
ADOCACHE       I plan to provide "Chapter FORTY" style documentation of 
May 31, 1991   each data source that MXG supports and each dataset that 
               MXG builds, as members of the MXG library, so that they  
               can be viewed and searched online with your text editor. 
               Since most data sources have a VMACxxxx member that is   
               the actual processing code, I have decided on the naming 
               convention that VMACxxxx member's data will be described 
               in member named VDOCxxxx.  A completed VDOCxxxx member   
               will contain these sections:                             
                 a. Data source description.  Who, what, when, writes   
                    the raw data records, vendor, releases supported    
                    by which version of MXG, etc.  How to process this  
                    data source with MXG (members, IMACs, etc.).        
                 b. MXG Data Set Documentation.  For each MXG data set  
                    built, there will be these sections:                
                    1. Description of data set itself, usage, etc.      
                    2. Alphabetic description in detail of every MXG    
                       variable, including usage notes, caveats, etc.   
                    3. Clustering of similar variables.                 
                    4. PROC PRINT with variable name of sample data.    
                    5. PROC PRINT SPLIT='*' with label of sample data.  
                    6. PROC MEANS of sample data.                       
               The member VDOCACHE is incomplete, but contains CACHE90  
               sections b.2, b.4, b.5, and b.6 for starters.            
               This work will extend over time.  Initial estimates of   
               the number of pages for MXG's 900 datasets and 36,000    
               variables are from 8 to 13 800-page volumes!  How much   
               will actually be printed, in what form, when will it be  
               completed, etc., are still under consideration. However, 
               as individual VDOC.... information is completed, it will 
               be added to the MXG SOURCLIB (even if not finished) so   
               the information will always be available online.         
Change 09.026  Changes in 8.293 to CACHE90 dataset in VMACACHE have now 
XMACACHE       been implemented in XMACACHE, the SAS 5.18 member used   
May 31, 1991   to circumvent the 344 compiler error.                    
Change 09.025  TPX variable TPXELAP should have been INPUT as PIB4.2    
VMACTPX        instead of PIB4.                                         
May 31, 1991                                                            
   Thanks to Seymour J. Metz, EDS, USA.                                 
Change 09.024  Type 42 subtype 2 SMF records (DFP 3990 SMS cache stats) 
VMAC42         are invalid until module IGDDCFSR is at OY39393.  The    
May 30, 1991   APAR OY39393 which fixed the subtype 3 record last year  
               didn't get on subtype 2! Without OY39393, the CU and VOL 
               segments are both mis-located by their offset triplets,  
               and the final VOL segment is actually truncated by two   
               bytes). This change enhances MXG to detect and process   
               both corrected and incorrect format records; since the   
               truncated bytes happen to be reserved it could be done!  
               You should still install OY39393 in case IBM makes any   
               other change to the DFP record.  But there's more. In    
               every other relocatable SMF record, the length triplet   
               value is the length of a single segment, but the DFP     
               developers decided to be different and store the total   
               length of all VOL segments in SMF42VLL (and not only do  
               they claim there is no standard and that the format of   
               the length field is up to the creator, they haven't even 
               said they will issue a document APAR telling you!). MXG  
               corrects the length value in processing.  And then there 
               are the LTM and CTM time stamps that don't contain the   
               HHMMSSTH that is documented, but instead contain the     
               seconds since midnight!  And finally, the LYY and CYY    
               year values contain x'005B' = decimal 91 now, but do not 
               document what will happen in 2000 - is the format really 
               0cyy where c is the century bit and the 2000 will be the 
               x'0100', or is the format the number of years since 1900 
               so that the 2000 year value will be x'0064'?  I have put 
               code in place that assumes the century bit format, but   
               am checking with IBM for the actual format.              
   Thanks to Joseph J. Faska, Depository Trust, USA.                    
Change 09.023  EXD Release 3.0 added EXDRTECD (EXD/SAR Route COde) to   
IMACEXD        the additional EXD variables in the type 6 record, and   
May 30, 1991   now MXG creates that variable if optional EXD support    
               is enabled in member IMACEXD.  I failed to note which    
               bright MXG user notified me of this omission.            
Change 09.022  SAS 6.06 option VERSIONLONG was added to MXG's list of   
CONFIG         default options, so that SAS will print the date of the  
May 30, 1991   maintenance library on your log (      
Change 09.021  Support for CADAM, Inc.'s Statistics Data File, written  
TYPECADM       to their DDNAME STATSEQ, provides response averages and  
VMACCADM       counts of function key activity for CADAM end users. The 
May 30, 1991   vendor's documentation warns that the data structures    
               are not supported by CADAM as user-accessible data and   
               are subject to change without notice (but the document   
               is dated 1988 and MXG has decoded data from the current  
               CADAM version 20.12). Function key use is recorded in 32 
               function key slots (but note that many CADAM products    
               (AEC, 3D) use multiple function key tables, redefining   
               the slots each time, and these re-uses are NOT reflected 
               in the function key slots.) For each function key slot,  
               CADAM records the number of uses, the total service time 
               and the sum-of-squares service times; MXG converts the   
               total service time to the average service time for each  
               function key slot.  Additionally, CADAM captures the     
               arrival, service, and response time statistics (average, 
               minimum, maximum, and distributions of these three "wall 
               clock" durations in 44 buckets from .01 to 120 seconds.  
               Service is the duration from when CADAM selects an       
                attention to process to the point that the operating    
                system has reported that the display has been updated.  
               Response time adds to the service time the additional    
                duration that an attention waits to be selected for     
                processing (i.e., response is from arrival of an        
                attention to when the display is updated after          
                processing the attention).                              
               Arrival time is the interval between the arrival of      
                attentions at the scope.  Since attentions may be       
                "stacked" this value forms a measure of the "human      
                factor" in scope usage.  Arrival times significantly    
                lower than response times imply that scope operators    
                are "getting ahead of the system," and that system      
                performance is poor.                                    
   Thanks to Emery Johnson, Allied Automotive Data Center, USA.         
Change 09.020  Support for Interlink's products (used to interchange    
EXILKA20       data between IBM, DEC, Internet, etc. platforms) has     
EXILKA21       been added.  The products each create user SMF records   
EXILKGAB       which are processed into multiple MXG datasets:          
EXILKGCO           Product           MXG Acronym    Datasets Created    
EXILKGRE           SNS/TCPaccess     ILKA             ILKAST20          
EXILKVCO                                              ILKAST21          
EXILKVOF           SNS/SNA Gateway   ILKG             ILKGABRT          
EXILKVON                                              ILKGACPT          
EXILKVSR                                              ILKGCONN          
EXILKVST                                              ILKGDISC          
IMACAAAA                                              ILKGREJC          
IMACILKG           SNS/TCPvt         ILKV             ILKVCONN          
IMACILKV                                              ILKVDISC          
TESTUSER                                              ILKVLOGF          
TYPEILKA                                              ILKVLOGN          
TYPEILKG                                              ILKVSTOP          
TYPEILKV                                              ILKVSTRT          
May 29, 1991                                                            
   Thanks to Diane Eppestine, Southwestern Bell, USA.                   
Change 09.019  The CICS Dictionary Printing Utility added support for   
UTILCICS       CICS 3.1 dictonary, but failed to sort the data before   
May 27, 1991   the PROC PRINT DATA=CICSDI31, causing "INPUT DATASET NOT 
               IN PROPER SORT SEQUENCE."  Insert before the PROC PRINT, 
                   PROC SORT DATA=CICSDI31  ;                           
                   BY SMFPSRVR APPLID NREC MNSEGCL MCTSSDID;            
   Thanks to Norbert Korsche, OMV-AG, AUSTRIA.                          
Change 09.018  This significant user contribution supports SMF user     
EXTYTAO        records created by Fischer International's TAO (Totally  
IMACTAO        Automated Office) Electronic Mail System Release 3.2.1   
TYPETAO        at product maintenance level #82 and up.  Earlier        
VMACTAO        releases are not supported as the vendor had previously  
May 15, 1991   used a non-SMF type of recording for statistics from the 
               EMC2 Electronic Mail System which predates TAO.          
               Although not as widely used as some EMAIL systems, TAO   
               is a stand-alone MVS/VTAM application.  AMDAHL uses the  
               TAO system extensively for electronic mail worldwide.    
               Some problems were encountered processing release 3.2.1  
               records due to errors in the vendors distribution        
               packaging.  It seems that the documentation which        
               describes the dsects had been updated along with the     
               source dsects, however, the load modules were assembled  
               using earlier versions of the dsects.  Assembly was a    
               problem due to user defined macros which the vendor had  
               not distributed in source form.  These problems were     
               easily cleared up with a phone call to the vendor, but   
               some shops may encounter similar difficulties in         
               attempting to read the TAO generated SMF records using   
               this code.  Several fields have been included in the MXG 
               code which are not yet supported (or populated) by the   
               vendor, although they are contained in the dsect areas   
               and the vendors comments supply documentation of the     
               future contents of these fields (at least in part).      
               This is NOT a complete subsystem for processing TAO SMF  
               records, retaining and summarizing detail data, and      
               producing reports.  It IS a start for people (like me)   
               who hate using ALC dsects in SAS code.                   
   Thanks to Joe Aldrich, Army and Air Force Exchange Service, USA.     
Change 09.017  The use of IMACKEEP to drop variables in MXG datasets is 
IMACKEEP       vulnerable to error.  If a new dataset is created by the 
May 15, 1991   new version of MXG (for example, new TYPE74.. datasets to
Jul 23, 1991   support MVS/ESA 4.1), and if you don't retrofit your     
               changes in IMACKEEP, you will fail with a SAS Error 311, 
               because your redefinition in IMACKEEP won't contain the  
               name of the new datasets.   It appears there is a better 
               way to drop unwanted variables from MXG datasets without 
               using IMACKEEP.  You can simply use a DROP statement in  
               the EXTY.... member to drop unwanted variables.  Even    
               those variable names are still in the KEEP= option of the
               DATA statement in the _VAR macro definition, the DROP    
               statement overrides the KEEP= option and the unwanted    
               variables will be dropped.  Using the EXit member to drop
               variables should be less vulnerable to change, and will  
               eliminate the use of IMACKEEP except in cases where you  
               want to ADD a new variable to an MXG dataset.  A caution;
               you cannot drop a variable which is later used in a BY   
               statement.the DATA step, as one user found when he tried 
               to drop MVS/370 variable LCHAN using EXTY74.  The drop   
               statement removed LCHAN from not only TYPE74 but also the
               TYPE73P dataset, which is later sorted from work to the  
               PDB with LCHAN in its BY statement. This cause an error! 
                 However, ain't nothin' straightforward.  If you should 
                 use a DROP statement in the EXIT member, and if that   
                 variable should ever disappear from MXG, you will THEN 
                 fail with a "Variable in drop list never referenced"   
                 error!  Normally this won't happen in MXG code, but    
                 (for example), if you had used the XMAC7... members to 
                 circumvent of the SAS (Version 5 only) 344 compiler    
                 error, MVS/370-only variables do not exist in the XMACx
                 and your DROP statement in EXTY74 would fail.          
                   But you can be even smarter than SAS.  If you add a  
                   "MXG Compiler Faker" statement for each variable to  
                   be dropped ahead of your DROP statement, the compiler
                   will be faked out whether the variable exists or not,
                   the variable will be dropped, and you code will be   
                   invulnerable to future MXG changes!  What is this MXG
                   "Faker" statement? Simply for numeric variables it's:
                       IF N=. THEN N=.;                                 
                   and for a character variable C, you must have as many
                   blanks between the quotes as is the length of the    
                   character variable:                                  
                       IF C='        ' THEN C='        ';               
Change 09.016  Support for Computer Associates CA-1 (TMS) Release 5 has 
TYPETMS        completely changed the format of the TMC records, but as 
TYPETMS5       there is no product release number in the TMC, MXG had to
               create completely separate, but parallel members to read 
VMACTMS5       the new TMC to create MXG data set TMS.TMS.  A few new   
May 15, 1991   variables do exist (see DOCVER09), but all of the prior  
               variables still exist (except for the obscure variables  
               READERR, WRITERR, which were replaced by 8 separate error
               values).  The value of variable DEVTYPE was changed so it
               doesn't waste so much space; the "EIGHTEEN-TRACK" and the
               "NINE-TRACK" values were replaced by "9TRK", "18TRK", and
               new value "36TRK" (for the 3490-E Serpentine technology) 
               was added for DEVTYPE.  For 3480s ("18TRK"), the IDRC    
               compaction status is decoded into MXG variable DEN, which
               will have the value 38000 for non-IDRC 3480 tapes, and   
               which is set to 76000 by MXG to indicate IDRC compacted  
               3480 tapes. Members TYPETMS/VMACTMS must be used for     
               CA-1 Releases earlier than Release 5, and MXG members    
               TYPETMS5/VMACTMS5 must be used for Release 5.            
   Thanks to Debora Reinert, Nordstrom, USA.                            
Change 09.015  Landmark TMON/CICS Version 8 history file contains a data
TYPEMON8       dictionary record with TMMDREC='DD' which causes MXG to  
May 14, 1991   fail because this record was not expected, and should be 
               deleted.  Change lines 065900 to 0660 to now read:       
                         TMMDREC     $CHAR2.                  065900    
                  @;                                          065910    
                  IF TMMDREC='DD' THEN DELETE;                065920    
                  INPUT  TMMDFLG1    $CHAR1.                  066000    
   Thanks to David A. Faught, FCC National Bank, USA.                   
Change 09.014  The  DROP=_FREQ statement in IMACPDB was supposed to have
IMACPDB        been DROP=_FREQ_ (with underscore on both sides), so that
May 13, 1991   the _FREQ_ variable created (only in SAS 6.06+, when PROC
               MEANS was replaced by PROC SUMMARY) would be dropped. The
               "misspelling" caused _FREQ_ to exist in both PDB.JOBS and
   Thanks to Raymond Zieverink, Belk Stores Services, USA.              
   Thanks to Freddie Arie, Lone Star Gas, TEXAS.                        
Change 09.013  New PDB.SPUNJOBS dataset variables INITTIME/JINITIME were
SPUNJOBS       not kept as 8-bytes (which caused their value to be      
May 13, 1991   truncated by up to 255 seconds) and were not formatted.  
               Both are now explicitly in the LENGTH statement and a new
               FORMAT statement was added.                              
   Thanks to Freddie Arie, Lone Star Gas, TEXAS.                        
Change 09.012  Trending of TMON/CICS dataset MONIDBDS built from TMON   
ASUMDBDS       Release 7 data (i.e., using MXG member TYPEMONI) will    
TESTOTHR       cause ASUMDBDS to fail with variable APPLID not found, as
May 13, 1991   APPLID did not exist in TMON Release 7.  Adding after the
               INCODE= operand:                                         
                       IF APPLID='         THEN APPLID='        ';      
               will protect ASUMDBDS for either TMON Release 7 or 8.    
               (This error was not detected because MXG's TESTOTHR step 
                of JCLTEST had member TYPEMON8 included after TYPEMONI  
                and then ASUMDBDS was included, masking the error. Now, 
                ASUMDBDS (and ASUMCICS) are invoked after TYPEMONI, and 
                then again invoked after TYPEMON8.  Note that there is  
                no way to actually test TMON/CICS with step TESTOTHR and
                actual data records; the single MONICICS DDNAME is used 
                for both TYPEMONI and TYPEMON8, and thus with real data,
                one or the other will fail in step TESTOTHR.  To really 
                test TMON/CICS data with MXG, use a separate job with   
                only the appropriate TYPEMONx member.)                  
   Thanks to William Padilla, Farmers Insurance Group, USA.             
Change 09.011  Landmark's TMON/CICS Release 9.0 records will have to be 
TYPEMON8       converted to Release 8.1 format for processing by MXG's  
May 13, 1991   TYPEMON8 member; Landmark does not intend to make the 9.0
               formats available.  But TMON/CICS 9.1 will be available  
               late 1991 or early 1992, and will have significant change
               in its records that will be made available and thus 9.1  
               records will be supported by MXG natively late this year.
Change 09.010  TYPE57 data produced MXG message "INVALID ESS SECTION'   
VMAC57         and the record was skipped because IBM documented the LEN
May 13, 1991   and NR of ESS sections as 4 bytes when in fact they are  
               only two bytes.  Lines 010100 and 010200 (where LENESS & 
               NRESS are INPUTed) should be PIB2. instead of PIB4.      
   Thanks to David A. Faught, FCC National Bank, USA.                   
Change 09.009  Processing HSM MCD, etc. data sets may cause STOPOVER,   
VMXGHSM        may print INVALID DATA messages if HSM dates are nulls,  
May 13, 1991   may print INVALID ARGUMENT messages because DATEJUL()    
               were not protected, misspelled TTOCTYP with an E, and    
               did not input TTOCALT, the Alternate VOLSER. The STOPOVER
               was corrected by moving the two tests for 'junk" records 
               (SUBSTR(MCDDSN) containing '99999') to immediately after 
               the variable MCDDSN was input (by breaking the input     
               statement at that point with @;).  The INVALID DATA was  
               eliminated by preceding all PDB4. formats with the ??    
               format modifier, and the INVALID ARGUMENT was eliminated 
               by replacing all DATEJUL(x) functions with:              
                       IF x GT 0 THEN x=DATEJUL(x);                     
                       ELSE           x=.;                              
               The occurrence of TTOCTYPE was respelled TTOCTYP, and was
               formatted $HEX2. instead of HEX2., and the preceding     
               TTOCKEY variable was now formatted HEX2.  Finally, at the
               end of the TTOC section, new variable TTOCALT $CHAR6. is 
               now input, labeled 'VOLSER OF ALTERNATE VOLUME' and kept.
   Thanks to Tim Noone, American United Life Insurance Company, USA.    
   Thanks to Joe Ellis, Shelby Insurance, USA.                          
Change 09.008  SAS 5.18 344 Compiler Limit circumvention member VMAC110M
CICINTRV       (that was added by Change 8.065 to reduce Iterative DOs) 
VMAC110M       fails with BUILDPDB because after VMAC110M was tested,   
May  9, 1991   member CICINTRV was added to BUILDPDB, but VMAC110M does 
               not create the datasets required by CICINTRV.  Since the 
               purpose of VMAC110M was to suppress CICS/ESA Statistics  
               processing, and since CICINTRV processes only CICS/ESA   
               Statistics data sets, the easiest circumvention that lets
               you use VMAC110M (by copying and renaming it to VMAC110  
               in your USERID.SOURCLIB) is to also create a member named
               CICINTRV in your USERID.SOURCLIB that contains a blank   
               line.  This will possibly circumvent the 344 error and   
               will definitely eliminate the "Data Set Not Found" caused
               by VMAC110M.  However, just to be really robust, the     
               member VMAC110M was corrected by this change, and now it 
               does create the CICS/ESA statistics datasets (with zero  
               observations, and with only the seven variables needed by
               CICINTRV) so if a future user does not see this change,  
               and uses only VMAC110M, he/she won't be burned!          
   Thanks to John Hassman, Texas Education Agency, USA.                 
Change 09.007  Applies only to MXG 8.9.  Change 8.304 added retrograde  
VMAC79         support for RMF 3.5.1 type 79 records, but I miss-typed  
May  9, 1991   two lines.  In line 037900, R792ARS should be PIB2. vice 
               PIB4., and in line 039630, R792TWSS should be PIB2. vice 
               PIB4.  Without this change, RMF 3.5.1 records STOPOVERed.
   Thanks to Gordon Keehn, Fidelity Mutual Life Insurance Company, USA. 
Change 09.006  Minor documentation.  Member IMACAAAA failed to list the 
IMACAAAA       IMACCMF member (Boole's CMF SMF Record ID) in its index, 
IMACCMF        and member IMAC370 was deleted, as it was not referenced 
IMAC370        and should have been deleted during testing; it was going
May  8, 1991   to contain MVS/370-only-RMF processing but was discarded 
               as a bad idea.  It serves no purpose.                    
   Thanks to Freddie Arie, Lone Star Gas, TEXAS.                        
Change 09.005  Minor, unless you tried to build your PDB on tape! The   
IMACCICS       new SPUNJOBS logic added in MXG 8.8 tried to read the    
SPUNJOBS       PDB.SPIN26 at the same time it was writing PDB.SPUNJOBS  
May  8, 1991   which can't be done if your PDB DD points to tape! Note  
               that if you really want your PDB on tape you must not    
               only correct this design error in SPUNJOBS, but you must 
               also change the default PDB values in member IMACCICS to 
               WORK, and (if you actually have CICS data) use EXPDBOUT  
               to then PROC COPY IN=WORK OUT=PDB; SELECT CIC:;  as is   
               now described in comments in IMACCICS.  To fix SPUNJOBS, 
               insert:   DATA SPJB26; SET PDB.SPIN26; immediately before
               the line containing  DATA  PDB.SPUNJOBS; and in the      
               following MERGE statement change PDB.SPIN26 to SPJB26 so 
               that only one PDB dataset is open at a time.  Also,      
                    PROC DATASETS NOLIST;                               
                   DELETE SPJB30_1 SPJB30_4 SPJB30_5 SPJB26;            
               was added at the end of the member.  It was also realized
               that SPIN6 processing is not currently in SPUNJOBS, and  
               that will be corrected in another change.                
   Thanks to Tim Hill, Pacific Bell, USA.                               
Change 09.004  Minor. Lines 011900 and 012000 both contained */ after   
DIFFHSM        the semicolon, which should have raised a syntax error,  
May  8, 1991   but didn't. Instead, variable DSRNTRKW was never DIF()d! 
   Thanks to Joanne Turpie, New Zealand Dept. of Labour, NEW ZEALAND.   
Change 09.003  Minor. The last occurrence of variable OTHRACTV (in the  
TRNDRMFI       NORM1= list) should have been OTH0ACTV.                  
May  6, 1991                                                            
Change 09.002  This change is cosmetic, but should be noted. The 3490E  
VMACUCB        cartridge tape (serpentine, bi-directional) device has a 
May  6, 1991   DEVTYPE of 81x, which was formerly assigned to the 9348. 
               MXG will now report 3490E instead of 9348.  Note that the
               3490 (non-E variety) cannot be differentiated from 3480s.
               And of course 3480s with and without IDRC (compression)  
               are not identified at the device level.  And what's going
               to be real fun is trying to figure out what kind of tape 
               you hold in your hand; all three used identical media    
               cartridges, but are incompatible; 3490E cannot be read   
               by 3490/3480/3480-IDRC, and 3490/3480IDRC cannot be read 
               on 3480.  Note MXG shipments are 3480-non-IDRC!          
   Thanks to Jay Arbabha, Principal Mutual Life Insurance Company, USA. 
Change 09.001  MVS/ESA 4.2 data records finally arrived and demonstrate 
VMAC30         that it is risky to distribute software that has not been
VMAC7072       tested with actual data records.  On the other hand, if  
VMAC73         I had waited for the data, you would still be waiting for
VMAC74         the software! These errors ONLY happen with MVS/ESA 4.2  
XMAC30         data records, and only one causes an actual error.       
XMAC7072     a.In VMAC30, find the line containing                      
XMAC73          @109+OFFSMF SMF30ASO         +8  /*RESERVED*/           
XMAC74         and change it to read:                                   
May  6, 1991    @109+OFFSMF                  +8  /*RESERVED-SMF30ASO*/  
               This was a soft error, only causing your log to be filled
               with "INVALID DATA FOR SMF30ASO" messages and a hex dump.
               (If it's not clear, SAS was trying to input SMF30ASO as  
               an EBCDIC numeric field because there was no format item 
               following the variable name in the input statement. What 
               was desired was to skip over 8 bytes, and note that this 
               reserved field was called SMF30ASO by IBM.)              
             b.VMAC7072 causes "INVALID DATA FOR IOCRFC/CPURFC" messages
               because these two fields no longer exist in 4.2, and the 
               fields now contain hex zeros instead of EBCDIC zeros!    
               Find the lines containing                                
                 @OFFWRKC+14 IOCRFC           3.                        
                 @OFFWRKC+17 CPURFC           3.                        
               and add ?? format modifier between the variable and its  
                 @OFFWRKC+14 IOCRFC     ??    3.                        
                 @OFFWRKC+17 CPURFC     ??    3.                        
               The ?? format modifier suppresses the hex dump and the   
               message, and sets the variable's value to missing.       
               This is a soft error.                                    
             c.VMAC73 causes "INVALID DATA FOR IODFDATE" messages.      
               Find the lines containing                                
                  IODFDATE     YYMMDD8.                                 
                  IODFTIME       TIME8.                                 
               and add ?? format modifier between the variable and its  
                  IODFDATE  ?? YYMMDD8.                                 
                  IODFTIME  ??   TIME8.                                 
               because not all records contain this new date/time data. 
               This is a soft error.                                    
             d.VMAC74 also causes "INVALID DATA FOR IOFDATE" messages   
               for the same reason as the VMAC73.  Apply the fix above  
               for IOFDATE (paragraph c) to the VMAC74 member.          
             e.VMAC74 causes a STOPOVER condition. This is not soft!!!  
               Find the three lines reading:                            
                         DLYDIRTM    PIB4.6                             
               and change them to read:                                 
                         DLYDIRTM    PIB4.6                             
                         DEVDYNCH  $CHAR1.                              
               These extra four bytes were added by IBM, and were added 
               in the SMF manual, and were even vertically barred, but  
               I simply missed them.  Sorry for the inconvenience.      
               The actual change in MXG VMAC74/XMAC74 9.2 and later is  
               more extensive that this "quick fix" printed changed.    
   Thanks to Diane Eppestine, Southwestern Bell, USA.                   
LASTCHANGE: Version  9