This is  MXG Version 19.19,    dated Feb 14, 2002, thru Change 19.300.  
         MXG Version 19.11 was dated Feb  4, 2002, thru Change 19.288.  
         MXG Version 19.10 was dated Jan 28, 2002, thru Change 19.282.  
         MXG Version 19.09 was dated Jan 21, 2002, thru Change 19.267.  
         MXG Version 19.08 was dated Dec 20, 2001, thru Change 19.247.  
         MXG Version 19.07 was dated Nov  3, 2001, thru Change 19.218.  
First    MXG Version 19.06 was dated Oct 31, 2001, thru Change 19.214.  
         MXG Version 19.05 was dated Oct 24, 2001, thru Change 19.207.  
         MXG Version 19.04 was dated Oct  5, 2001, thru Change 19.189.  
First    MXG Version 19.04 was dated Oct  1, 2001, thru Change 19.183.  
         MXG Version 19.03 was dated Jul 30, 2001, thru Change 19.151.  
First    MXG Version 19.03 was dated Jul 26, 2001, thru Change 19.148.  
         MXG Version 19.02 was dated Jun  1, 2001, thru Change 19.098.  
First    MXG Version 19.02 was dated May 27, 2001, thru Change 19.097.  
         MXG Version 19.01 was dated Apr  4, 2001, thru Change 19.060.  
First    MXG Version 19.01 was dated Apr  3, 2001, thru Change 19.057.  
         MXG Version 18.18 was dated Feb 12, 2001, thru Change 18.360.  
         MXG Newsletter THIRTY-EIGHT is dated Feb 12, 2001.             
Contents of member CHANGES:                                             
  Member NEWSLTRS (and the Newsletters frame at now 
  contain the current MXG Technical Notes that used to be put in member 
  CHANGES between Newsletters.  New Technical Notes are now added (and  
  now dated!) in NEWSLTRS/Newsletters with each new MXG Version.        
I.    MXG Software Version 19.19 is the 2002 Annual Version.            
II.   Incompatibilities and Installation of MXG 19.19.                  
III.  Online Documentation of MXG Software.                             
IV.   Changes Log                                                       
I.   MXG Software Version 19.19 dated Feb 14, 2001, is available.       
    Major enhancements added in MXG 19.19:                              
     Support  CICS/TS 2.2 CICSTRAN (INCOMPATIBLE).                      
     Support for TYPE94 APAR OW52989, adds 8-way AX0 controlers.        
     Support for OS/400 Release 5.1.0 Collection Services, in TYPEQACS. 
     New UTILEXCL program for CICS EXCLUDEd fields automatically creates
       an IMACEXCL member to read your records, without any EDITing, but
       this major enhancement should be used by ALL sites that read SMF 
       110 records, even if you do not EXCLUDE fields.  UTILEXCL creates
       an IMACEXCL member with these performance enhancements:          
        - a single INPUT statement (more efficient than conditionals)   
        - eliminates unnecessary arithmetic (avoids missing values)     
        - KEEPs only the variables that exist in your records; all the  
          EXCLUDED fields are dropped, and all of the extra variables   
          that are in the CICSTRAN KEEP= list for new/old versions that 
          do not (yet) exist in your data are also not kept.            
       See text of Change 19.293 and examples in member UTILEXCL.       
     User contributed code to read the output of the unix  sar command. 
     ASMVTOC enhanced to select/exclude VOLSER and UCBs above the line. 
    Versions 19.12 thru 19.18 were never created.                       
    Major enhancements added in MXG 19.11:                              
       Datetime values are now automatically converted from GMT fo LOCAL
       Landmark CICS values are NOT changed, but now could be.          
       See Change 19.288.                                               
     TIMEBILD/TIMETABL/VMXGTIME supports LOCAL and GMT Time Zone deltas 
       and has identified all MXG datetime variables that contain GMT   
       (few) in the text of Change 19.286.  If you have SYSTEMs on      
       different time zones that needs to be shifted to a common zone,  
       of if you have GMT values to change to Local, this massive change
       will let you do all of the above.  And if you do nothing, it does
       nothing; the VMXGTIME() statements do nothing until TIMEBILD has 
       been invoked for a specific job to change datetimes.             
    UGMTCHEK Utility will check for datetime variables still on GMT     
    Major enhancements added in MXG 19.10:                              
      MXG sets OPTIONS COMPRESS=YES as the default.  Change 19.279.     
      MXG changes LENGTH DEFAULT=4 to =5 on EBCDIC, to =6 on ASCII, to  
       eliminate any truncation of PIB4-input numeric variables, and the
       stored length of MGBYTES-Format'd PIB4 variables was reduced from
       8 to 5/6 to eliminate wasted space.  &MXGLEN/&MXGBYLN macro vars 
       can be %LET if you need to restore original defaults; only known 
       exposure is if you use PROC APEND, but did not specify FORCE.    
       No size increase with compress; benchmarks/text in Change 19.272.
      Initiator Number and Name variables added to PDB.JOBS and TYPE30_1
        but missing until you install the IEFU84 SMF Exit Assembly code 
        that moves those fields into type 30 subtype 1.  Change 22.136. 
    Major enhancements added in MXG 19.09:                              
      Support for SMF 119 from IBM z/OS V1R2.0 Communications Server.   
      Support for IBM AIX Performance Toolbox, PTX V2.                  
      You can change the time zone of all SMF datetime variables, by    
        SYSTEM and TimeRange, to put all of your systems on their own   
        time zones (EST/PST/GMT) to the common time zone of the floor   
        of the data center, so you can compare RMF, response, etc.,     
        when your SYSTEMS are on different time zones. This is in the   
        VMXGTIME, TIMEBILD, and TIMETABL members.                       
      ML-20 ASMTAPES, wrong DDNAME in MXGTMNT SMF if tape on 4-digit.   
      Select step records, then corresponding 14 15 & 64s - see ANAL30. 
      Select SORTs with concat SYSIN, then matching 14 15 - see ANAL16. 
      Support for WebLogs: IIS, WebSphere, CLF, Cookies+.               
    Major enhancements added in MXG 19.08:                              
      MXG 19.04-19.07: TYPE73 PCHANBY/PNCHANBY zero, ONLINE wrong.      
      Support for Crypto (for SSL) RMF 70 Subtype 2 APAR OW49808.       
      Support for IBM CICS/TS 2.2 Statistics Record TCBs                
      Support for IDMS Log Statistics Records.                          
      Support for Landmark's TMON for TCP/IP v1.1.                      
      Support for RSD Folders ASTRE Auditing User SMF record.           
      MXG Software (all versions) supports euro symbol.                 
      New HSM variables, start/end timestamps for HSMFSRST events.      
      Sample MQ Series reports were enhanced.                           
      Enhanced support for NPM subtypes 18x/19x.                        
      ANALDB2R PMACCnn reports caused ERRORS and ABENDS.                
      ASUMUOW Doc updated: which _K macro to use for what data.         
      %GLOBAL macro variables no longer %LET to null value.             
    Major enhancements added in MXG 19.07:                              
      Errors in datasets PDB.ASUM70PR, PDB.ASUMCEC, and PDB.TYPE70PR    
      were introduced by MXG 19.05 and not completely fixed by MXG 19.06
      changes. IBM's unexpected insertion of segments for spare CPUs in 
      type 70 records (APAR OW49536) precipitated Change 19.189 to fix, 
      and that worked fine with 2064 CPUs, but failed with 9672 data.   
      The next fix took care of 9672s, but that fix created too large   
      values for LPnDUR, causing bad percentages, but now only on 2064s.
      And then a user pointed out that Dedicated CPUs were not quite    
      correctly summed in ASUM70PR logic.  Another user had mis-matched 
      values for LPAR busy of the same LPAR from three different systems
      with MXG 18.18, because he had Dedicated/Wait Complete CPUs, and  
      (after hours of looking at his data, I re-found my) Change 17.203 
      that created PDB.ASUMCEC to solve the problem with missing values 
      and Dedicated/Wait Complete processors.  (That the values were not
      missing in his 18.18 data was itself an error also now corrected).
      And Change 19.201 was needed to correct variable SHIFT in ASUM70PR
      and ASUMCEC.                                                      
      But, in summary, we did not handle that APAR well!                
    Major enhancements added in MXG 19.06:                              
      Support for Tivoli/Netview NPM 2.6 COMPATIBLE.                    
      Support for NTSMF SMS Objects.                                    
      "Support" for DB2 QLES section added to DB2STATS.                 
    Major enhancements added in MXG 19.05:                              
      Support for APAR OW49806, z/OS 1.1 and 1.2 required correction.   
      Support Windows 2000, SP2 for Exchange 2000, SQLSERVER, objects.  
      Support for Serena's Ultimizer user SMF record                    
      Support for SMF type 82 crypto facility record.                   
      Revised to invoke VMXG70PR to match RMFINTRV interval             
    Major enhancements added in MXG 19.04:                              
      Support for z/OS Version 1 Release 2, most new stuff (COMPATIBLE):
         Existing important SMF and RMF records have been updated, but  
         some new data records, SMF 109, SMF 119 are not yet written.   
         See Change 19.176.  (SMF 119 support was added in MXG 19.09).  
      Support for CICS/TS 2.2 Subtype 1 CICSTRAN (COMPATIBLE, unless you
         have tailored MXG process any optional "user" segments in your 
         SMF 110 Subtype 1 Performance record (how to tell?: if you have
         any tailored IMACICxx members in your USERID.SOURCLIB).        
         This support does NOT yet support the Subtype 2 Statistics 110.
         See Change 19.181.                                             
      Support for IMS 6.1 Fast Path records (INCOMPAT)                  
      Support for CISCO Works Blue ISM user SMF record st 01/05/06/66.  
      Support for WAS/390 4.0 EE Websphere SMF 120; won't fail, but this
        support requires SAS V8.2+ for some character variables to be   
        valid; IBM introduced "Unicode" UCS/DBCS data in SMF 120's.     
      New SPINSORT member to sort SPIN if MXG moves from MVS to ASCII.  
      Documentation of the IHDRxxxx "INFILE" header exits.              
      Support for NTSMF V & Windows 2000 changes.              
    Major enhancements added in MXG 19.03:                              
      Support for TPF releases PUT08, PUT10, PUT12 (INCOMPATIBLE).      
      Support for z/VM 3.1 and VM/ESA 2.4 on z900 CPUs.                 
      Revisions to ASMIMSL5 (5.1) and ASMIMSL6 (6.1 and 7.1) IMS log.   
      Enhanced ASUMCACH, from 74s: DASD Cache and DASD I/O.             
      New TYPE42XV dataset for XRC Volume segments.                     
      Correction for TNG STARTIME, two-digit base-36, etc.              
      Read same MXG dataset from many DDnames/libraries with VGETDDS    
    Major enhancements added in MXG 19.02:                              
     New MSU calculations were wrong with new z/OS 70 records.          
     PDB.ASUMUOW now contains USERCHAR from CICSTRAN.                   
     Support for BMC Mainview Batch Optimizer, BMO SMF.                 
     Support for DCOLLECT APAR OW48529, new value.                      
     Support for HMF Subtypes 29, 30, and 31.                           
     Support for IBM changes to Websphere SMF 120 record.               
     Support for SMF 102 IFCID 096 was corrected.                       
     Support for objects NETWORKINTERFACE and PAGINGFILE.               
     ANALUSS example sums CPU time from USS/OMVS task's type 30s.       
     ASMIMSLn deletes IMS 01 records with recovery bit.                 
     CICSTRAN STRTTIME/ENDTIME did not include Leap seconds.            
     JCL example to use BatchPipes with SAS - big savings!              
     KEEPALL=YES is now specified in ASUMs to save CPU.                 
     SAS V8.2 WARNING: OPTION BLKSIZE(2311) NOT SUPPORTED.              
     Spurious SAS NOTE: "might be uninitialized".                       
     TYPE73 records different for SMF73CMG=1 and SMF73CMG=2.            
    Major enhancements added in MXG 19.01:                              
     z900 2064s and ICFs without OW48190 have wrong CPU count.          
      - causes CPU busy values to be wrong, too.  Change 19.015         
     DB2ACCT Parallel Transactions are double accounted.                
      - See 19.027.  IBM now "rolls up" child records into duplicate.   
     Duplicate observations created in MQMMSGDM dataset.                
      - See Change 19.054.  MXG 18.18 error had two outputs.            
     Support for APAR OW46268 TYPE74 USS Kernel in place.               
     Support for APAR OW46622 for Temporal Affinity.                    
     Support for CICS TCP/IP EZA01 optional variables.                  
     Support for IMS Version 7.1 Log Records - no changes.              
     Support for Omegamon/IMS V500 - no changes.                        
     Support for Tandem G06/G07/G08 CPU & DISK records.                 
     Support for Landmark's The Monitor for IMS records.                
     Support for TLMS Release 5.5 (COMPATIBLE).                         
     Support for CA/TNG new, post-9907 V6, format (INCOMPAT).           
     CICS CPU time captured is now documented in ADOC110.               
     Protection for invalid ALOCTIME (before INITTIME).                 
     CHAIN logic in IMF IMS trans corrects negatives.                   
  See member NEWSLTRS or the Newsletters frame at for       
  current MXG Technical Notes that used to be in CHANGES.               
  MXG 19.19 has been tested with SAS V8.2 and SAS V6.09 on OS/390, and  
  with SAS V8.2 on Windows 98 and 2000 and Linux RH 7.2, but should run 
  without error under V8.2 on every possible SAS platform!              
  All of these enhancements are described in the Change Log, below.     
    Availability dates for the IBM products and MXG version required:   
                                       Availability     MXG Version     
      Product Name                     Date              Required       
      MVS/ESA 4.1                      Oct 26, 1990         8.8         
      MVS/ESA 4.2                      Mar 29, 1991         9.9         
      MVS/ESA 4.2.2                    Aug 15, 1991         9.9         
      MVS/ESA 4.3                      Mar 23, 1993        10.10        
      MVS/ESA 5.1.0 - compatibility    Jun 24, 1994        12.02        
      MVS/ESA 5.1.0 - Goal Mode        May  3, 1995        13.01        
      MVS/ESA 5.2.0                    Jun 15, 1995        13.05        
      MVS/ESA 5.2.2                    Oct 19, 1995        13.09        
      OS/390  1.1.0                    Feb 22, 1996        14.01        
      OS/390  1.2.0                    Sep 30, 1996        14.05        
      OS/390  1.3.0 Compatibility Mode Mar 28, 1997        14.14        
      OS/390  1.3.0 WLM Goal Mode      Mar 28, 1997        15.02        
      OS/390  2.4.0                    Sep 28, 1997        15.06        
      OS/390  2.5.0                    Feb 24, 1998        15.06        
      OS/390  2.6.0                    Sep 24, 1998        16.04        
      OS/390  2.7.0                    Mar 26, 1999        16.09        
      OS/390  2.7.0 APAR OW41317       Mar 31, 2000        18.03        
      OS/390  2.8.0                    Aug 24, 1999        16.09        
      OS/390  2.8.0 APAR OW41317       Mar 31, 2000        18.03        
      OS/390  2.8.0 FICON/SHARK        Aug 24, 1999        17.08        
      OS/390  2.8.0 APAR OW41317       Mar 31, 2000        18.03        
      OS/390  2.9.0                    Mar 31, 2000        18.03        
      OS/390 2.10.0                    Sep 15, 2000        18.06        
      OS/390  PAV                      Oct 24, 2000        18.09        
      z/OS    1.1                      Mar 30, 2001        18.11        
      z/OS    1.1 on 2064s             Mar 30, 2001        19.01        
      z/OS    1.1 with correct MSU     Mar 30, 2001        19.02        
      z/OS    1.2                      Oct 31, 2001        19.04        
      z/OS    1.1,1.2 APARs to 78      Oct 31, 2001        19.05        
      CICS/ESA 3.2                     Jun 28, 1991         9.9         
      CICS/ESA 3.3                     Mar 28, 1992        10.01        
      CICS/ESA 4.1                     Oct 27, 1994        13.09        
      CICS/ESA 5.1 aka CICS/TS V1R1    Sep 10, 1996        14.07        
      CICS-Transaction Server V1R1     Sep 10, 1996        14.07        
      CICS-TS V1R1 with APAR UN98309   Sep 15, 1997        15.06        
      CICS-TS V1R2  CICS/TS 1.2        Oct 27, 1997        15.06        
      CICS-TS V1R3  CICS/TS 1.3        Mar 15, 1999        17.04        
      CICS-TS for Z/OS Version 2.1     Mar 15, 2001        18.11        
      CICS-TS for Z/OS Version 2.2     Oct 31, 2001        19.04        
         CICSTRAN subtype 1 support only                   19.04        
         CICSTRAN subtype 2 completed                      19.05        
      CRR 1.6                          Jun 24, 1994        12.02        
      CRR 1.7                          Apr 25, 1996        14.02        
      DB2 2.3.0                        Oct 28, 1991        10.01        
      DB2 3.1.0                        Dec 17, 1993        13.02A       
      DB2 4.1.0 Tolerate               Nov  7, 1995        13.07        
      DB2 4.1.0 Full support           Sep 11, 1996        14.07        
      DB2 5.1.0 Tolerate               Jun 27, 1997        14.14        
      DB2 5.1.0 Full support           Jun 27, 1997        15.02        
      DB2 6.1.0 initial support        Mar 15, 1999        16.09        
      DB2 6.1.0 all buffer pools       Mar 15, 1999        18.01        
      DB2 7.1.0                        Mar 30, 2001        18.11        
      DFSMS/MVS 1.1                    Mar 13, 1993        11.11        
      DFSMS/MVS 1.2                    Jun 24, 1994        12.02        
      DFSMS/MVS 1.3                    Dec 29, 1995        13.09        
      DFSMS/MVS 1.4                    Sep 28, 1997        15.04        
      DFSMS/MVS 1.4 HSM                Sep 23, 1998        16.04        
      DFSMS/MVS 1.5                    ??? ??, 1999        16.04        
      MQM 1.1.2, 1.1.3, 1.1.4          Apr 25, 1996        14.02        
      MQ Series 1.2.0                  May 26, 1998        16.02        
      MQ Series 2.1.0                  Oct  2, 1999        17.07        
      MQ Series 5.2                    Dec 16, 2000        18.10        
      NETVIEW 3.1 type 37              ??? ??, 1996        14.03        
      NPM 2.0                          Dec 17, 1993        12.03        
      NPM 2.2                          Aug 29, 1994        12.05        
      NPM 2.3                          ??? ??, 1996        15.08        
      NPM 2.4                          Nov 18, 1998        17.01        
      NPM 2.5                          Feb ??, 2000        18.02        
      NPM 2.6                          Nov ??, 2001        19.06        
      RMDS 2.1, 2.2                    Dec 12, 1995        12.12        
      RMDS 2.3                         Jan 31, 2002        19.11        
      TCP/IP 3.1                       Jun 12, 1995        12.12        
      TCP/IP 3.4                       Sep 22, 1998        16.04        
      DOS/VSE POWER V6.3.0             Dec 19, 1998        16.08        
      VM/ESA  2.0                      Dec 23, 1992        10.04        
      VM/ESA  2.1                      Jun 27, 1993        12.02        
      VM/ESA  2.2                      Nov 22, 1994        12.06        
      VM/ESA  2.3                      Jun  1, 1998        16.08        
      VM/ESA  2.4                      Mar  1, 2001        19.03        
      z/VM    3.1                      Mar  1, 2001        19.03        
      IMS     4.1                      Jul  4, 1994        12.02        
      IMS     5.1                      Jun  9, 1996        14.05        
      IMS     6.1                      ???  ?, 199?        16.04        
      AS400 3.7.0                      Nov  1, 1996        15.01        
      AS400 4.1.0                      Dec 30, 1996        15.08        
      AS400 4.2.0                      Apr 27, 1998        16.02        
      AS400 4.4.0                      Sep 27, 1999        17.07        
      AS400 4.5.0                      Jul 27, 2000        18.07        
    Availability dates for non-IBM products and MXG version required:   
                                                        MXG Version     
      Product Name                                       Required       
      SAS Institute                                                     
       MXG executes best under SAS Version 8.2, with 82BX01 HOTFIX for  
         MVS-OS/390-z/OS which includes Critical 81BA57 fix).           
       See Newsletter FORTY for expanded discussion of other versions.  
       Read member NEWSLTRS (search 'V8') for SAS Version 8 notes.      
       Windows NT 4.0 and NT 3.51                          14.14        
       Windows NT 4.0 Service Pack 2                       15.03        
       Windows NT 4.0 Service Pack 5                       16.04        
       Windows 2000 Build 2195                             17.10        
      Demand Technology                                                 
       NTSMF Version 1 Beta                                14.11        
       NTSMF Version 2.0                                   15.05        
       NTSMF Version 2.1                                   15.06        
       NTSMF Version 2.2                                   16.04        
       NTSMF Version 2.3                                   17.10        
       The Monitor for DB2 Version 2                       13.06        
       The Monitor for DB2 Version 3.0                     16.02        
       The Monitor for DB2 Version 3.1                     16.02        
       The Monitor for CICS/ESA 1.2 -                      12.12        
       The Monitor for CICS/ESA 1.3 -                      15.01        
       The Monitor for CICS/ESA 2.0 -                      15.06        
       The Monitor for MVS/ESA 1.3  -                      12.05        
       The Monitor for MVS/ESA 1.5  -                      12.05        
       The Monitor for MVS/ESA 2.0  -                      15.09        
       Omegamon for CICS V200 User SMF                     12.05        
       Omegamon for CICS V300 User SMF                     13.06        
       Omegamon for CICS V400 User SMF                     16.02        
       Omegamon for CICS V400 type 110 segments            16.02        
       Omegamon for CICS V500 User SMF                     18.01        
       Omegamon for IMS V110 (ITRF)                        12.12        
       Omegamon for IMS V300 (ITRF)                        14.04        
       Omegamon for MVS V300                               13.05        
       Omegamon for MVS V400                               13.06        
       Omegamon for DB2 Version 2.1/2.2                    13.05        
       Omegamon for VTAM V160                              12.04A       
       Omegamon for VTAM V400                              15.15        
       Omegamon for VTAM V500                              18.08        
       Omegamon for SMS V100/V110                          12.03        
       ACF2 6.2                                            16.04        
       ASTEX 2.1                                           14.04        
       NETSPY 4.7                                          14.03        
       NETSPY 5.0                                          14.03        
       NETSPY 5.2                                          16.05        
       NETSPY 5.3                                          18.03        
      Boole & Babbage                                                   
       IMF 3.1 (for IMS 5.1)                               12.12        
       IMF 3.2 (for IMS 6.1 only)                          15.09        
       IMF 3.2 (for IMS 5.1 and 6.1)                       16.04        
       LMS 3.1                                             12.12A       
      MXG IMS-Log Not-Officially-Supported                              
       IMS 6.1  -   ASMIMSL6/TYPEIMSA                      19.03        
       IMS 5.1  -   ASMIMSL5/TYPEIMSA                      19.03        
       APAF 4.1, 4.3                                       16.08        
II.   Incompatibilities and Installation of MXG 19.19.                  
 1. Incompatibilities introduced in MXG 19.19 (since MXG 18.18):        
  a- Changes in MXG architecture made between 18.18 and 19.19 that might
     introduce incompatibilities.                                       
          - A small increase, perhaps 5-6MB, of virtual storage may be  
            required for BUILDPDB due to MXG code changes (new variables
            and datasets require more REGION=, and Change 19.272) has   
            has been observed.  If you have a fixed REGION=nnM in your  
            JCL, even a small increase could cause an ABEND, so you must
            compare the region used in your current job (Total Memory on
            on the SAS log, for that big DATA step) with your REGION,   
            and may need to increase your fixed REGION size.  At present
            REGION=128M is larger than any BUILDPDB, and thus should be 
            safe, if you can't use REGION=0 and must specify a value.   
          - COMPRESS=YES is now the MXG default for new datasets. ITSV  
            sites have always had COMPRESS=YES specified, but if you did
            not have that option set, you could see an increase in the  
            CPU time of BUILDPDB jobs.  On some early CMOS systems cost 
            of compression was significant; you can turn it off with:   
                OPTIONS COMPRESS=NO;                                    
            Our benchmarks on 2064s with 307MB SMF showed:              
                 Data Step sec        BUILDPDB total CPU sec            
                    NO    YES             NO     YES        CPU increase
            18.18   71 -> 110   54%      172  -> 243   41%   71 seconds 
            19.19  106 -> 123   16%      205  -> 255   24%   50 seconds 
            The cost of compression with 18.18 was substantially higher 
            as a percentage than is the cost of compression with 19.19, 
            which mostly shows how poor percentages can be for real     
            comparisons.  The real cost of total job compression is one 
            minute of CPU time per day for 300 MegaBytes of SMF data.   
            And you not only save lots of DASD space, but also avoid the
            3am phone call that BUILDPDB had a B37 ABEND!               
          - Changes between 18.18 and 19.19 (new data, new subtypes     
            of existing BUILDPDB records) may cause a small increase in 
            the MXG CPU time for the "Big DATA" step; perhaps 2-3% for  
            an untailored BUILDPDB.  But even when the new VMXGTIME time
            zone convert option was enabled, the monster BUILDPDB that  
            reads almost every IBM and user SMF records, saw only a 12% 
            increase in the Big Data Step.  However, other MXG changes  
            (KEEPALL=YES in VMXGSUM invocations) actually significantly 
            reduced the CPU time for the rest of the BUILDPDB job, and  
            the net increase (again, with VMXGTIME enabled) was only 5%:
                Extended BUILDPDB Timings 307MB SMF;                    
                       Big DATA step      BUILDPDB Job Total            
                18.18  110 sec  102MB     243 sec  104MB                
                19.19  123 sec  105MB     255 sec  107MB                
            Other cross-hardware benchmarks without VMXGTIME enabled    
            showed 2064 CPU time increased by 3% but by 5% on 9672      
          - MXG changed Landmark Support code for IMS, DB2, MVS:        
            Datetime values are now automatically converted from        
            GMT to LOCAL, as there is an offset in those records.       
            Landmark CICS values are NOT changed, because I could       
            not confirm if they should be.  See Change 19.288.          
 2. Installation and re-installation procedures are described in detail 
    in member INSTALL (which also lists common Error/Warning messages a 
    new user might encounter), and sample JCL is in member JCLINSTL.    
    MXG Definitions with regard to MXG Software Changes:                
    COMPATIBLE   A change in a data record which did not alter either   
                 the location or the format of all of the previously-   
                 kept MXG variables is COMPATIBLE, and you can continue 
                 to run the old version of MXG software, which will read
                 the new records without error, but none of any new data
                 fields or any new record subtypes will be created/kept 
                 until you install the MXG Version with this change.    
                 A change that alters any previously kept variable is   
                 INCOMPATIBLE, and requires the new version to be used. 
    TOLERATE     In other words, the old MXG Version TOLERATES the new  
                 data records, if they are COMPATIBLY changed.          
    EXPLOIT      Once you use the new MXG Version to read the changed   
                 records, all of the new fields, subtypes, etc, that are
                 described in this change will be created in the MXG    
                 datasets, so the new MXG Version EXPLOITS the new data,
                 and you have full support of the new data records.     
    INCOMPAT     A change in a data record that causes the current MXG  
                 version to fail, visibly or invisibly, with or without 
                 error conditions or messages, and the output datasets  
                 may contain wrong values and incomplete observations,  
                 and/or observations may have been lost.                
                 You MUST install the new MXG Version with this change  
                 to process data records that have been INCOMPATIBLY    
                 changed by their vendor.                               
III.  Online Documentation of MXG Software.                             
    MXG Documentation is now described in member DOCUMENT.              
    See also member INDEX, but it may be overwhelming.                  
IV.   Changes 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 always identifies the actual version and release of     
 MXG Software that is contained in that library.                        
 The CHANGES selection on our homepage at            
 is always the most current information on MXG Software status,         
 and is frequently updated.                                             
 Important changes are also posted to the MXG-L ListServer, which is    
 also described by a selection on the homepage.  Please subscribe.      
 The actual code implementation of some changes in MXG SOURCLIB may be  
 different than described in the change text (which might have printed  
 only the critical part of the correction that need be made by users).  
 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.                     
Alphabetical list of important changes after MXG 18.18 now in MXG 19.11:
  Member   Change    Description                                        
  none     19.234  MXG Software (all versions) supports the euro symbol.
  Many     19.176  Support for z/OS Version 1 Release 2 (COMPAT)        
  ADOC110  19.025  CICS CPU time captured is now documented in ADOC110. 
  ANAL115  19.231  Sample MQ Series reports were enhanced.              
  ANAL16   19.257  Select SORTs with concat SYSIN, then matching 14 15. 
  ANAL30   19.257  Select step records, then corresponding 14 15 & 64s. 
  ANALDB2R 19.222  ANALDB2R PMACCnn reports caused ERRORS and ABENDS.   
  ANALQAPM 19.262  Sample AS/400 report from QAPM Perf Monitor data     
  ANALUSS  19.087  Example to sum CPU time from USS aka OMVS 30 records.
  ASMIMSL5 19.135  MXG 19.01-19.02 only. Change 19.061 removed.         
  ASMIMSL6 19.135  MXG 19.01-19.02 only. Change 19.061 removed.         
  ASMIMSLn 19.061  IMS 01 records with recovery bit are deleted.        
  ASMTAPES 19.259  MXGTMNT DDNAME in SMF wrong if tape on 4-digit UCB.  
  ASUM70PR 19.015  z900 and ICFs without OW48190 have wrong CPU count.  
  ASUM70PR 19.201  Revised to invoke VMXG70PR to match RMFINTRV interval
  ASUMCACH 19.123  Enhanced ASUMCACH, from 74s: DASD Cache and DASD I/O.
  ASUMUOW  19.219  Doc only. Which _K macro to use for what.            
  ASUMxxxx 19.074  KEEPALL=YES is now specified in ASUMs to save CPU.   
  AUTOEXEC 19.279  MXG now sets OPTIONS COMPRESS=YES as default.        
  BLDNTPDB 19.199  Incorrect copying in the weekly phase corrected.     
  BUIL3005 19.162  JES3-only, variable NETNAME (DJC) now kept in JOBS.  
  BUILDPDB 19.036  Variable ABENDS in PDB.JOBS counted pseudo steps.    
  BUILDPDB 19.237  Variable LOCLINFO in PDB.STEPS was not from step.    
  BUILDPDB 19.269  Initiator Number and Name added to PDB.JOBS.         
  FORMATS  19.073  Support for DCOLLECT APAR OW48529, new value.        
  IEFU84   19.269  SMF Exit to add Initiator Number and Name to SMF 30. 
  IHDRxxxx 19.232  Documentation of the IHDRxxxx "INFILE" header exits. 
  IMACICEZ 19.047  Support for CICS TCP/IP EZA01 optional variables.    
  JCLUOWP  19.079  JCL example to use BatchPipes with SAS - big savings!
  MXGBYLE  19.272  Default of MXG numeric variables changed, externalizd
  MXGLEN   19.272  Default of MXG numeric variables changed, externalizd
  RMFINTRV 19.011  CPCNRCPU,CPFCNAME wrong for CPUTYPE='2064' in 18.18. 
  RMFINTRV 19.020  %VMXGRMFI(PDB=SMF) error, MERGERMF not found.        
  RMFINTRV 19.156  Using fewer than the default workloads caused Notes. 
  SPINSORT 19.172  PROC SORT of SPIN if MXG moves from MVS to ASCII.    
  TIMEBILD 19.260  Change time zone of all datetime variables by SYSTEM.
  TIMEBILD 19.286  LOCAL and GMT Time Zone Deltas for VMXGTIME.         
  TIMETABL 19.260  Change time zone of all datetime variables by SYSTEM.
  TIMETABL 19.286  LOCAL and GMT Time Zone Deltas for VMXGTIME.         
  TRNDCEC  19.150  Example of TRENDing the ASUMCEC dataset.             
  TYPE102  19.019  Type 102 subtype 140 INPUTE EXCEEDED error.          
  TYPE102  19.081  Support for SMF 102 IFCID 096 was corrected.         
  TYPE110  19.028  Variables DSxPERCT in CICDS are endpoint values.     
  TYPE110  19.076  CICSTRAN STRTTIME/ENDTIME did not include Leap secs. 
  TYPE110  19.181  Support for CICS/TS 2.2 Subtype 1 CICSTRAN           
  TYPE110  19.224  Support for IBM CICS/TS 2.2 Statistics Record TCBs   
  TYPE110  19.293  Support for CICS/TS 2.2 CICSTRAN (INCOMPATIBLE).     
  TYPE115  19.054  Duplicate observations created in MQMMSGDM dataset.  
  TYPE116  19.139  Invalid SMF 116 with QWHS length=108 protected.      
  TYPE119  19.267  Support for SMF 119 IBM z/OS V1R2 CS TCP/IP Product  
  TYPE120  19.077  Support for IBM changes to Websphere SMF 120 record. 
  TYPE120  19.180  Support for WAS/390 4.0 EE Websphere SMF 120         
  TYPE28   19.211  Support for Tivoli/Netview NPM 2.6 COMPATIBLE.       
  TYPE28   19.221  Enhanced support for NPM subtypes 18x/19x.           
  TYPE28   19.264  NRPxxxxx variables in NPMINNRP were all missing      
  TYPE30   19.056  Protection for invalid ALOCTIME (before INITTIME).   
  TYPE30   19.163  Variable JOBCLASS was unprintable under ASCII SAS.   
  TYPE30   19.169  Initiator Number and Name added to TYPE30_1 job init.
  TYPE30   19.283  Actual Midnight ALOCTIME=0 caused ELAPSTM=24 hours.  
  TYPE30_D 19.060  Variable BLKSIZE in TYPE30_D, PDB.DDSTATS, wrong.    
  TYPE42   19.043  TYPE 42 subtype 5 INPUT EXCEEDED reading VSAM SMF.   
  TYPE42   19.145  New TYPE42XV dataset for XRC Volume segments.        
  TYPE42   19.147  Invalid SMF 42-5 protected.                          
  TYPE42   19.160  Type 42 subtypes 7 and 8 were revised.               
  TYPE42   19.173  INPUT STATEMENT EXCEEDED, SMF 42 ST 6, invalid.      
  TYPE7072 19.018  Zero-divide by SMF70CPA corrected (no impact).       
  TYPE7072 19.245  Support for CRYPTO RMF 70 Subtype 2 APAR OW49808.    
  TYPE70PR 19.030  LPARCPUS=0 if back level OS/390 and no OW37565.      
  TYPE70PR 19.189  APAR OW49536 "spare" LPARCPUS/LPnNRPRC counted.      
  TYPE71   19.270  CSFRLSAV/ESFRLSAV can be small negative, reset to 0. 
  TYPE73   19.084  Offline channels in TYPE73, document CMG=1 and CMG=2.
  TYPE73   19.240  MXG 19.04-19.07: PCHANBY/PNCHANBY/ONLINE were WRONG. 
  TYPE74   19.017  Support for APAR OW46268 TYPE74 USS Kernel in place. 
  TYPE74   19.186  "Broken" 74 subtype 4 incorrectly output in TYPE74CF.
  TYPE74   19.239  TYPE74CF/TYPE74ST some R744S/R744F variables wrong.  
  TYPE78   19.070  TYPE78SP's _BTY73SP BY list didn't remove all dupes. 
  TYPE78   19.203  Support for APAR OW49806, z/OS 1.1 and 1.2 correction
  TYPE79   19.051  Support for APAR OW46622 for Temporal Affinity.      
  TYPE82   19.200  Support for SMF type 82 crypto facility record.      
  TYPE91   19.241  Batch Pipes datasets have added variables for merge. 
  TYPE94   19.290  Support for APAR OW52989, adds 8-way AX0 controlers. 
  TYPEAIX  19.261  Support for IBM AIX Performance Toolbox, PTX V2.     
  TYPECIMS 19.031  CHAIN logic in IMF IMS trans corrects negatives.     
  TYPECISM 19.158  Support for CISCO Works Blue ISM user SMF record.    
  TYPEDB2  19.027  DB2ACCT Parallel Transactions are double accounted.  
  TYPEDB2  19.213  DB2 V7 QLES section variables added to DB2STATS.     
  TYPEEDGR 19.252  Variables added by OW40710 in 1999 now added in MXG. 
  TYPEEDGS 19.284  DFSMS/rmm "V" records had blank MVDSNx variables.    
  TYPEHMF  19.082  Support for HMF Subtypes 29, 30, and 31.             
  TYPEHSM  19.227  New vars, start/end timestamps for HSMFSRST events.  
  TYPEIDML 19.244  Support for IDMS Log Statistics Records.             
  TYPEIMS  19.046  Support for IMS Version 7.1 Log Records.             
  TYPEIMS  19.242  IMSGTEXT/OMSGTEXT were incorrect.                    
  TYPEIMS7 19.117  NMSGPROC in IMS0708 no longer counts unmatched 08's. 
  TYPEIMSA 19.177  Support for IMS 6.1 Fast Path records (INCOMPAT)     
  TYPEIMSA 19.188  Times were GMT vice local: IMS SRV/RES/ TM/TS.       
  TYPEITRF 19.003  Support for Omegamon/IMS V500 - no changes.          
  TYPEMBO  19.067  Support for BMC Mainview Batch Optimizer, BMO SMF.   
  TYPEMPLX 19.185  Support for the Implex User SMF record.              
  TYPENDM  19.275  NDMCPUTM added in NDM/Connect Direct records.        
  TYPENTSM 19.065  Support for objects NETWORKINTERFACE and PAGINGFILE. 
  TYPENTSM 19.148  Support for NTSMF V & Windows 2000 changes. 
  TYPENTSM 19.153  Corrections for Process with NRDATA=27, old NTSMFs.  
  TYPENTSM 19.197  New Windows 2000, Exchange 2000, etc, objects.       
  TYPENTSM 19.214  Support for NTSMF SMS Objects.                       
  TYPENTSM 19.276  MSEXCHANGE DS object has new variables.              
  TYPEQACS 19.289  Support for OS/400 Release 5.1.0 Collection Services 
  TYPERSDA 19.229  Support for RSD Folders ASTRE Auditing User SMF rec. 
  TYPESFTA 19.166  Soft Audit variable STEPNAME contained SYSTEM.       
  TYPESHDW 19.032  Shadow Direct INPUT STATEMENT EXCEEDED error.        
  TYPESTC  19.264  Zero observations in HSC dataset STCHSC from STK SMF.
  TYPESYNC 19.004  Array name DD conflicts with existing DD variable.   
  TYPETAND 19.029  Support for Tandem G06/G07/G08 CPU & DISK records.   
  TYPETCP  19.053  SMF 118 ERROR.4. HFS FILE error created in error.    
  TYPETIMS 19.050  Support for Landmark's The Monitor for IMS records.  
  TYPETIMS 19.288  Landmark for IMS datetime variable now on Local zone.
  TYPETLMS 19.013  Support for TLMS Release 5.5 (COMPATIBLE).           
  TYPETMDB 19.288  Landmark for DB2 datetime variable now on Local zone.
  TYPETMNT 19.088  INITTIME could be off by one day.                    
  TYPETMS5 19.164  TMS Audit variables TMAUxxxx/TMVAxxxx correct now.   
  TYPETMTC 19.225  Support for Landmark's TMON for TCP/IP v1.1.         
  TYPETMV2 19.288  Landmark for MVS datetime variable now on Local zone.
  TYPETMV2 19.297  Support for Landmark Monitor for MVS Version 3.      
  TYPETNG  19.009  Support for CA/TNG new, post-9907, format (INCOMPAT).
  TYPETNG  19.146  Correction for TNG STARTIME, two-digit base-36, etc. 
  TYPETPF  19.125  Support for TPF releases PUT08,PUT10,PUT12 INCOMPAT. 
  TYPETPF  19.136  TPF datetimes now corrected from GMT to local zone.  
  TYPETPF  19.170  TPF enhancements for wrapped counters.               
  TYPETSOM 19.075  New TSMPxxxx variables now kept in TSOMCALL dataset. 
  TYPEULTM 19.202  Support for Serena's Ultimizer user SMF record       
  TYPEVMXA 19.132  Support for z/VM 3.1 and VM/ESA 2.4 on z900 CPUs.    
  TYPEWWW  19.249  Support for WebLogs: IIS, WebSphere, CLF, Cookies+.  
  UGMTCHEK 19.287  Utility to check for datetime variables still on GMT 
  UGMTCHEK 19.287  Utility to examine if GMT values are in your data.   
  UNIXSAR  19.294  User contribution reads unix sar -A -f reports.      
  UTILCVRT 19.271  Utility converts historic MVS PDB's $HEX on ASCII.   
  UTILEXCL 19.293  UTILEXCL creates IMACEXCL without EDIT for CICS.     
  VGETDDS  19.116  Read same MXG dataset from many DDnames/libraries.   
  VGETOBS  19.247  New MXGDSN macro variable exist/zero obs detection.  
  VGETxxx  19.002  Documentation of VGETxxx macro naming convention.    
  VMXGDEL  19.268  Replaced use of PROC SQL/VTABLE in internal macro.   
  VMXGDEL  19.295  Lower case work. did not match upper case WORK.      
  VMXGDUR  19.282  SYNC59=NO specification did not work.                
  VMXGINIT 19.230  %GLOBAL macro variables no longer %LET to null value.
  VMXGINIT 19.279  MXG now sets OPTIONS COMPRESS=YES as default.        
  VMXGOPTR 19.268  Replaced use of PROC SQL/VTABLE in internal macro.   
  VMXGRMFI 19.083  New MSU calculations wrong with new z/OS 70 records. 
  VMXGSUM  19.151  Use of TEMP01/TEMP02/TEMP03 revised.                 
  VMXGSUM  19.246  New HOUSKEEP= option to leave temporary datasets.    
  VMXGSUM  19.251  &MXGLEN added, TEMPnn logic corrected, PROC SQL fix. 
  VMXGTIME 19.260  Change time zone of all datetime variables by SYSTEM.
  VMXGTIME 19.286  LOCAL and GMT Time Zone Deltas for VMXGTIME.         
  VMXGUOW  19.092  PDB.ASUMUOW now contains USERCHAR from CICSTRAN.     
  VMXGWORL 19.063  Spurious SAS NOTE: "might be uninitialized".         
Inverse chronological list of all Changes:                              
NEXTCHANGE: Version 19.                                                 
=======Changes thru 19.300 were in MXG 19.19 dated Feb 14, 2002=========
Change 19.300  One site using MXGTMNT MXG Tape Mount Monitor found their
ASMTAPES       LOGREC filled with MXGTMNT generated X'E0' ABEND messages
Feb 13, 2002   to the extent that they had to stop MXGTMNT.  This site  
               is a massive user of virtual tapes, and the E0 results   
               when the monitor saw the job at one pop, but the job is  
               no longer in the system a 2-second pop later, because its
               done its virtual mount and ended in milliseconds.        
               The original design used a previously saved ALET during  
               cross-memory access to an address space for which a tape 
               mount occurred, but, no check was made to see if the ALET
               has been invalidated because the job had ended.          
               Instead, this redesign will                              
               - Save the ASID and JOBNAME for the job associated with  
                 the device when it sees a mount pending, and now save  
                 the STOKEN for the address space.  Each STOKEN value is
                 unique across the life of the IPL, whereas the ASID and
                 the ALET are not.                                      
               - When the CROSSMEM routine executes, it checks to see if
                 the STOKEN for the address space it is in (ASSBSTKN in 
                 the ASSB) matches what was saved previously when the   
                 mount was detected; if it matches, it's safe to do the 
                 SAC instruction.  If the STOKEN does not match, then   
                 the original address space that caused the mount is    
                 indeed gone, and we will stop CROSSMEM processing for  
                 that address space.                                    
                -The SMF record will be written the same way a job      
                 change is currently handled: MXGTMNT writes out the    
                 SMF record as it is up to that point, without the      
                 allocation information in it.  The data currently      
                 captured from the ACEE, JCT, OUCB, ACT, JMR, DSAB, and 
                 the SCT will be missing from these records.            
                 This enhancement to MXGTMNT will be "ML-21" and the    
                 ASMTAPES member will have that noted at its beginning. 
                 As of the February 14 start of tape build for MXG 19.19
                 this change has only been designed; if you encounter   
                 significant counts of LOGREC 0E ABEND messages from the
                 MXGTMNT program, please request the "ML-21" level of   
                 the ASMTAPES member, and it will be sent when tested.  
                 Feb 27, 2002: ML-21 is now available, Change 20.011.   
Change 19.299  MXG Messages "New NTSMF OBJECT Found" did not contain the
VMACNTSM       name of the SYSTEM with the new object, making it hard to
Feb 13, 2002   know on which system to enable NTSMF's DISCOVERY option. 
               Sending the discover file to is all that 
               is needed to add support for the new object into MXG.    
               But if that message has OBJECT=, then you  
               will need to contact NTSMF support, because that message 
               results when the MicroSoft code-writer failed to comply  
               with standards, so the NTSMF programmers have to develop 
               a fix to Cover Their Actions and get the correct name.   
   Thanks to Denny C. Wong, New York Life Insurance, USA.               
Change 19.298  Variables for Storage Class name are now input in subtype
VMACSTC        16, 17, and 18 STK records, as is STC17MVC, the VOLSER in
Feb 13, 2002   subtype 17.                                              
   Thanks to John Ellis, Powergen Retail, ENGLAND.                      
Change 19.297  Support for Landmark TMON for MVS Version 3.0 (INCOMPAT).
VMACTMV2       The documentation does not agree with their actual data, 
Feb 13, 2002   but by considerable sleuthing I believe I have found what
Oct 17, 2002   was changed, but you must validate this support with your
               data, and report any discrepancies to   
               The DV record is bypassed because it has inserted data   
               that I can't figure out, but these 3.0 datasets have been
               created and printed and look okay except as noted:       
                XIS, XIM, XI, WG , TR (DURATM is in error in the record)
                SYS, YSSW, YSUI, PS (CHANGED) NQ, MLV, MLL, MLG, LC,    
                JDSW, JDDL, JDIN (suspect) EL CS,CP,CH,CF (suspect)     
                Oct 17, 2002: Support for TMON/MVS V3.0 and 3.1 is      
                now in member TYPETMVS/TYPSTMVS/VMACTMVS and not in     
                the TMV2 suffixes.  See Change 20.201.                  
   Thanks to John Jackson, REDCATS (UK), ENGLAND.                       
   Thanks to Jim Horne, Lowes, USA.                                     
Change 19.296  While DCOLLECT is generally used to graze your DASD farm 
ASMVTOC        for dataset space, etc., there are cases when ASMVTOC is 
Feb 13, 2002   needed, and this  revision will make it easier and better
               when you need to look at all the VTOCs.                  
              -The program now allows Volume select/exclude processing, 
               so you can avoid multiple scans of volumes shared between
               images.  To invoke select/exclude, set PARM='VOLLIST' and
               add a //VOLLIST DD.                                      
              -The program revised the CVAFSEQ access to handle UCBs    
               that are above the line.                                 
   Thanks to Brian Crow, British Telecom, ENGLAND.                      
Change 19.295  An ITSV-only problem appears to have been introduced by  
VMXGDEL        SAS Version 8.2; apparenly the ITSV %CMSTART macro now   
VMXGINIT       sets the option USER='work', and VMXGDEL tried to compare
Feb 13, 2002   work.DB2STAT2 with WORK.DB2STAT2, which was not equal, so
               VMXGDEL deleted the WORK.DB2STAT2 dataset it had built.  
               This change protects the VMXGDEL test with UPCASE, but   
               also VMXGINIT was enhanced to force the USER and SASWORK 
               options to upper case if they had been lower case, for   
   Thanks to Roderic Gass, British Energy Group, ENGLAND.               
Change 19.294  This user contribution processes unix sar reports files  
UNIXSAR        created with the command   sar -A -f sardata.mmmyy       
Feb 12, 2002   This preliminary code will eventually be revised into the
               normal MXG member naming, macros, etc, but this code will
               give you access to the sar information now.              
   Thanks to Carmen Vitullo, Acxiom, USA                                
   Thanks to Uriel Carrasquilla, NCCI, USA.                             
Change 19.293 -Support for CICS/TS 2.2 CICSTRAN (INCOMPATIBLE, IBM again
VMAC110        inserted new fields in their SMF 110 subtype 1 records.  
UTILEXCL      -New UTILEXCL program for EXCLUDEd fields in CICS records 
Feb  9, 2002   automatically creates the tailored IMACEXCL member from  
Feb 11, 2002   your CICS dictionary SMF records, eliminating any manual 
               EDITing of the IMACEXCL member.  In addition, using the  
               UTILEXCL to create an IMACEXCL member, even if you don't 
               exclude fields, will provide performance benefits:       
                - a single INPUT statement for each APPLID is created;  
                  the default TYPE110 code has many conditional tests   
                  that break up the INPUT statement, and that is more   
                  CPU-expensive that a single INPUT execution.          
                - conversion statements (times are multiplied by 16) are
                  only generated for the fields that are input.  The    
                  old IMACEXCL you created skipped over Exclude fields, 
                  but then all variables were converted, causing many   
                  unnecessary calculations on missing values, which is  
                  itself a performance negative in SAS V8.              
                - all EXCLUDEd fields are DROPped automatically, so you 
                  do not have to tailor the KEEP or DROP macros for the 
                  CICSTRAN dataset.                                     
               This is new and very powerful; see its comments.         
               And this design will be enhanced: I would like to detect 
               changes in your CICS dictionary and create a new IMACEXCL
               that can use SMFTIME to differentiate the old from the   
               new records from the same APPLID, in a future revision.  
Change 19.292  Overdue cleanup of TRENDing for DB2 datasets has correct 
TRNDDB2A       spelling of all variables and KEEPALL=YES is specified on
TRNDDB2B       each VMXGSUM invocation so they work. The TRNDDB2X member
TRNDDB2S       summarizes the DB2STATB, Interval Buffer Statistics, by  
TRNDDB2X       Buffer Pool, named TRNDDB2X because TRNDDB2B is used for 
Feb  8, 2002   the DB2ACCTB (Plan Buffer Details, by Buffer Pool).      
Change 19.291  The NOAMSGID field in the Version 2.3 record is now an   
VMACNOAM       8-byte character variable, instead of a 2-byte numeric,  
Feb  6, 2002   so it is now input into new variable NOAMSGCH.           
   Thanks to Mike Fry, HSBC, ENGLAND.                                   
Change 19.290  Support for IBM SMF 94 record, APAR OW52989 that added   
VMAC94         support for 8-way AX0 controllers (AX0 to AX7).  MXG will
Feb  6, 2002   input the additional 4 AXO's data fields when they are   
   Thanks to Alex MacFarlane, Bank of New York, USA.                    
Change 19.289  MXG Support for OS/400 Release 5.1.0 Collections Services
EXQAPJOL       was added in the TYPEQACS member (introduced in 4.5 for  
EXQAPJOM       IBM's first Collection Services), instead of the TYPEQAPM
EXQAPJOM       member, because the records were completely incompatibly 
EXQAPJOL       restrucured, and in three instances, split apart.  While 
EXQAPPOB       the Member name you execute is changed from QAPM to QACS,
EXQAPPOL       all datasets created still start with QAPMxxxx and all of
EXQAPPOT       the former variable names are preserved. Three old files 
EXQAPSYC       are split: JOBS, POOL, and SYS.  For example, from IBM's 
EXQAPSYL       Collection Services documentation:                       
EXQAPSYT          Performance data files: QAPMJOBS and QAPMJOBL.        
IMACQACS          The QAPMJOBL file is provided for compatibilty with   
TYPEQACS          the PM and combines data from QAPMJOBMI and QAPMJOBOS 
TYPSQACS          files.  The QAPMJOBS file is created when the PM      
VMXGINIT          database files are migrated with the Convert          
Feb  6, 2002      Performance Data commmand (CVTPFRDTA) to the new      
Feb  9, 2002      release, but Collection Services does not create the  
                  QAPMJOBS file.                                        
               MXG will create QAPMJOBL, or QAPMJOBM, or QAPMJOBO, from 
               whichever those three files you create, but it appears   
               the new "Logical" dataset, QAPMJOBL, contains all that   
               was in the old QAPMJOBS dataset, so the JOBMI/JOBOS files
               probably are not needed.  And similarly, the POOL records
               are split and create QAPMPOLB, QAPMPOLL (old QAPMPOOL),  
               and QAPMPOLT datasets from those three Pool files, and   
               the SYS records now create QAPMSYSC, QAPMSYSL (old       
               QAPMSYS), and QAPMSYST datasets from those files.  Your  
               choice of macros you invoke in your copy of TYPEQACS     
               determines what MXG will create.  This changes has been  
               validated with all of the above records, plus QACSCONF   
               and QACSDISK, but there are three new records (JSUM, TCP,
               and TCPIFC) that have not been requested (i.e., test     
               data).  The list of specific LRECLs that must be used to 
               upload to MVS (or to use in your FILENAME statement on   
               ASCII) are listed in the comments in VMACQACS.           
   Thanks to Paul Gillis, Pacific Management Systems, AUSTRALIA.        
   Thanks to Gary Katerelos, Coles Meyer, AUSTRALIA.                    
   Thanks to Martyn Jones, ABN-AMRO, THE NETHERLANDS.                   
======Changes thru 19.288 were in MXG 19.11  dated Feb  4, 2002======   
Change 19.288  MXG Support for Landmark's IMS, DB2, and MVS products is 
VMACTIMS       changed INCOMPATIBLY, possibly, because all datetimes are
VMACTMDB       now converted from GMT to LOCAL, using the record's GMT  
VMACTMO2       offset, which is the way is should have been done.       
               FROM RIGHT TO WRONG, and you will need to remove your    
               tailoring code.  (Of course, if your site's GMT offset is
               zero, no change in before or after values will occur.)   
                  Alternatively, you could use the new TIMEBILD/TIMETABL
                  in Change 19.286 to change those local times back to  
                  GMT, using a TIMETABL just for these MXG jobs with the
                  negative of the GMT offset in the LOCAL delta entry,  
                  and with SYSTEM blank.  help.                         
               Note that ONLY Landmark IMS, DB2, and MVS were changed;  
               the CICS support in TYPETMO2 is still unchanged, because 
               there IS no GMT offset in those records.  In fact, you   
               can now use the new TIMEBILD architecture for your       
               TYPETMO2 jobs to convert those GMT datetimes into local. 
Change 19.287  Utility UGMTCHEK selects all datetime variables in all   
UGMTCHEK       datasets in a SAS data library, PROC PRINTs only those   
VMXGPRAL       variables from the first observation, and PROC MEANS to  
Feb  2, 2002   get the min and max value of each datetime variable, so  
               that you can see whether a datetimestamp is on the local 
               or GMT time zone.  Change 19.286 required knowledge of   
               the zone of each datetime variable, rarely found in the  
               record's documentation; only actual data can confirm the 
               time zone of a datetime variable, hence this new utility.
               MXG always intends to convert datetime variables to the  
               local timezone, if a GMT offset is present in the record,
               and for the vast majority of data, times are local zone. 
               UGMTCHEK requires SAS V8 because it uses the AUTONAME    
               option (so variable names in MEANS output are appended   
               with their statistic: SMFTIME_MIN and SMFTIME_MAX for    
               these reports; it is still my intention NOT to create any
               real MXG variables in MXG datasets with names longer than
               8-characters, but AUTONAME was perfect for this report.  
               UGMTCHEK uses %VMXGPRAL to "PRint ALL datasets in a SAS  
               Data Library"; VMXGPRAL was revised to choose any or all 
               of the three procs (CONTENTS, MEANS, PRINT) to execute;  
               in this instance, I only wanted a PRINT of each dataset. 
Change 19.286  LOCAL and GMT Time Zones Delta conversion in VMXGTIME.   
IMACINIT      -This enhancement to Change 19.260 supports two time zones
TIMEBILD       in TIMETABL: a LOCAL delta for datetime variables on the 
TIMETABL       local time zone, and a GMT delta for those few variables 
VMACmanymany   still on GMT time zone (because there is no GMT-offset   
VMXGTIME       in their record). All GMT-time-zone datetime variables   
VMXGINIT       were put in separate %VMXGTIME source statements:        
Feb  2, 2002      %VMXGTIME(.list-of-GMT-vars.,SYSTEM,GMT=YES)          
Feb  5, 2002   so that VMXGTIME uses the GMT delta column in TIMETABL   
Feb  8, 2002   member to convert those variables.                       
Feb 11, 2002     Almost all important variables are in local time zone, 
                 but actual data is the only way to know for sure, so   
                 all possible data records were run thru the UGMTCHEK   
                 utility that display the actual values of each variable
                 that has a datetime format in all datasets in a PDB.   
                 But since vendors can add GMT offsets, and they will be
                 used when found, you should use UGMTCHEK against your  
                 own datasets to confirm and validate your datetimes.   
                 The full list of GMT variables is at the end of this   
                 change, and it will be revised if vendors add GMT      
                 offsets to their records, or if your validation shows  
                 that I've overlooked something.                        
                 If there is a difference in your datetime values, check
                 your "USERID.SOURCLIB" Exit members (EXdddddd) to see  
                 if the previous MXG-person changed those values in your
                 installation tailoring exit member.                    
               The specific case that created VMXGTIME was a site with  
               multiple LPARs, each on different time zones, and this   
               change is running in production to bring all of those    
               data to the common, local time zone of the data center.  
               But for records that do not contain a GMT Offset, you can
               now enable TIMEBLD with a zero LOCAL Delta and your site 
               GMT offset for the GMT delta, and convert GMT datetimes  
               based on your instructions in TIMETABL.                  
               Most MXG datetimestamp variables contain local time; the 
               SMFSTAMP/RMFSTAMP informats are local; most TODSTAMPs are
               GMT, but are converted if there is a GMT offset.  Records
               that contain only the first 4-bytes of GMT offset were   
               originally decoded with this calculation:                
                  INPUT OFFSET &IB.4. @;   OFFSET=1.048576*OFFSET;      
               but the result can be off by a second, it has no obvious 
               reason for that constant, and must be "rounded" to give  
               picture-pretty values.  And now, real logic can be used  
               to replace that engineering estimate:                    
                  INPUT GMTCHAR $CHAR4. @;                              
                  OFFSET=INPUT( (GMTCHAR!!'00000000'X),&IB.8.6)/4096;   
                  IF . LT OFFSET LT 0 THEN OFFSET=CEIL(OFFSET);         
                  ELSE                     OFFSET=FLOOR(OFFSET);        
               Only a few members had the old code.                     
               Two very important "token" variables that are necessary  
               to match records together, READTIME and UOWTIME, are     
               NOT converted by VMXGTIME:                               
                READTIME - its time zone is that of the SYSTEM that saw 
                           the job card, but the records on this SYSTEM 
                           do not tell where the job was input (except  
                           for the type 26 purge record), so it is not  
                           possible to correctly re-zone READTIME.  And 
                           even if it were, you would have the READTIME 
                           in your PDB datasets different that READTIME 
                           in the other (unprocessed) SMF data.         
                UOWTIME  - similarly, it's time zone is unknown, and it 
                           must be unchanged to allow CICS and DB2 to   
                           be merged in ASUMUOW.                        
               The variables below are still in GMT time zone (because  
               there is no GMT offset value in their data records) so   
               they are in VMXGTIME (GMT=YES) statements, and will be   
               converted only if you have a non-zero GMT-offset value   
               in your TIMETABL member:                                 
                 A06GOFTM A06GONTM A08GBKCD A08GBKDD A14GACT  A14GADT   
                 STGCSTRT STGLRTVL                                      
                 TTETIME  TTSTIME  UCCTIME  UCOTIME                     
                 STARTIME ENDTIME                                       
                 S42EXSTM S42EXETM                                      
                 S42CCSST S42CCEIT S42CCSET                             
                 CMF29SCK CMF29TIM SMF29ECK SMF29PCK                    
                 ACSMFTOD LIDLUPT  LIDPSTOD                             
                 APAFTOD  IMLTOD   LITOD    UPDATE                      
                 RSIOMT   RSIO     RCENDT                               
                 HU01RST  HU02END  HU05RST  HU06RST  HU08RST  HU09RST   
                 HU10RST  HU11RST  HU12RST  HU12TIM1 HU12TIM2 HU12TIM3  
                 HU12TIM4 HU12TIM5 HU13ETIM HU13RST  HU13STIM HU16SSTM  
                 HU22RST  HU24RST  HU25RST  HU26RST  HU40DRST HU42CRTM  
                 HU47ONDT HU47RST  HU49ONDT HU49RST  HU50CRTM HU51CRTM  
                 HU51DRST HU51RST  HU52DRST HU52RST  HU60CRTM HU60DRST  
                 HU60SSTM HU61CRTM HU61DRST HU61RST  HU62CRTM HU62DRST  
                 HU62RST  HU62SSTM HU72CRTM HU72DRST HU72RST  HU72SSTM  
                  OMFS2STM OMFS2ETM OMFS2JTM                            
                  STC09TIM STC13MET STC13MST STC13TIM STC14TIM STC16MET 
                  STC16MST STC18MET STC18MST STC18TIM STC19RET STC19RST 
                  TRSTCK   TRSTK1   TRSTK2   TRSTK3                     
              -Performance Impact:                                      
               - Changes between 18.18 and 19.19 (new data, new subtypes
                 of existing BUILDPDB records) may cause an increase in 
                 the MXG CPU time for the "big DATA" step: perhaps 3%   
                 for an untailored BUILDPDB, and as much as 12% at one  
                 test site with a heavily tailored and extended PDB that
                 contains almost all possible IBM and user SMF records. 
                 However, the CPU time for the post-big-DATA processing 
                 was significantly with 19.19 than with 18.18, so the   
                 net increase in the entire BUILDPDB job was only 5%:   
                   Extended BUILDPDB Timings 307MB SMF;                 
                          Big DATA step      BUILDPDB Job Total         
                   18.18  110 sec  102MB     243 sec  104MB             
                   19.19  123 sec  105MB     255 sec  107MB             
               - Many %VMXGTIME() invocation statements were added in   
                 source code, but MXG initialization invokes %TIMEBILD  
                 with TIMEBILD=NO to create a dummy %VMXGTIME macro that
                 has minimal impact on CPU and virtual storage costs.   
               - Enabling %TIMEBILD in your //SYSIN will create the real
                 %VMXGTIME macro, with a small, measurable compile cost,
                 but the actual execution CPU costs depend on how many  
                 variables in how many records are actually changed.    
               - BUILDPDB with only default SMF records with no DB2/CICS
                 (375K records, 1.1GB) showed no increase between 18.18 
                 and 19.19.  Enabling VMXGTIME, CPU increased from 9 to 
                 10 minutes.                                            
               - BUILDPDB with only default RMF records (4.8GM) also had
                 no increase between 18.18 and 19.19; enabling VMXGTIME 
                 increased 79 seconds CPU time to 98 seconds.           
                  MXG 19.07 base     - 1637 CPU secs      Virtual 69411K
                  MXG 19.19 disabled - 1638 CPU secs + 0% Virtual 69574K
                  MXG 19.19 enabled  - 1839 CPU secs +12% Virtual 70951K
                  -  The delta between 19.07 and 19.19 VMXGTIME-disabled
                     run shows there was no cost in adding that code.   
                  -  The VMXGTIME-enabled increase of 201 seconds is the
                     (small, fixed) compile-time cost of each %VMXGTIME 
                     statement, and the actual execution costs to change
                     377 variable's values across those 10 million SMF  
                     records to shift all records to the local zone.    
               There were 210 VMACxxxx members that were EDITed for this
               change, with 1054 %VMXGTIME statements added that list in
               excess of 1,500 datetime variables.                      
              -Feb 8 revision.  TIMEBILD with TIMEBILD=NO is now invoked
               at MXG Initialization to create a null %VMXGTIME macro,  
               so there is NO cost for those %VMXGTIME() statements     
               added in MXG source code to provide this enhancement.    
              -Unrelated, but done as part of this change, there is a   
               new IMACINIT, for user tailoring at MXG Initialization,  
               which is included as the last statement each time that   
               %VMXGINIT is initialized or re-initialized.  Likely very 
               few sites will ever need it, but now it's there.         
              -If you enable TIMEBILD, you can get a count of how many  
               variables were changed by adding this statement:         
               at the end of your sysin.                                
Change 19.285  Incorrect macro references caused syntax errors if you   
Feb  1, 2002   arguments of %VMXGRMFI to send those two datasets to WORK
               (VMXG70PR was wanted to only update the PLATxxxx vars in 
               the PDB.RMFINTRV dataset).  The correct macro references 
               now work as documented.                                  
   Thanks to Helgund Linck, BASF IT Services GmbH, GERMANY.             
Change 19.284  DFSMS/RMM "V" records have changed at some point in the  
VMACEDGS       past, but unless you wanted the MVDSNx fields, you would 
Jan 31, 2002   not have notices.  The  +58 in the INPUT for the V record
               is now +122 to skip over the new blank data inserted in  
               the record.                                              
               See Change 21.122, which changed the +122 back to +58,   
               and externalized the value in MACRO _LNEDGS.             
   Thanks to Bruce J. Danderline, Memorial Sloan Kettering, USA.        
Change 19.283  My very earliest (1972) heuristic, to identify steps that
VMAC30         did not Allocate or Load by setting ALOCTIME or LOADTIME 
Jan 31, 2002   to a missing value, was based on exact zero values in the
Feb  1, 2002   raw data, but has finally been exposed by a step that did
               allocate exactly at midnight (0.00), causing ALOCTIME to 
               be wrong, ELAPSTM to be 24 hours, and ALOCTM negative in 
               step and interval datasets.  A heuristic is required here
               because IBM only provides times, without dates, for these
               events timestamps.  This revision eliminates any exposure
               to incorrectly setting LOADTIME, now setting it missing  
               only when virtual storage was not acquired; if PVTTOP=0  
               PVTTOP=0, the "PROGRAM FETCH" event never occurred. And  
               with this external criteria to guarantee LOADTIME valid, 
               ALOCTIME can be always valid when LOADTIME is nonmissing.
               One remaining exposure cannot be corrected: a step that  
               did not load, so it has LOADTIME=., but had an allocation
               start time exactly at midnight, will still have ALOCTIME 
               missing, rather than a midnight time on potentially the  
               wrong date, because there is no separate criteria to tell
               whether that was a midnight or a no-allocate event, but  
               since LOADTIME is missing in this case, ALOCTIME is far  
               more likely to have also been missing, and not midnight. 
               SMF 30 records for STCs for O/MVS a/k/a USS can be valid 
               but appear inconsistent.  Step records for JOB=BPXAS with
               both ALOCTIME and LOADTIME missing, but a SELAPSTM of 45 
               minutes, and with PVTBOT and PVTTOP both zero but with a 
               small non-zero CPUTCBTM recorded have been observed; the 
               examples all had PGM=IEFIIC, the initator program name.  
               Because Change 19.056 reported that the ALOCTIME can be  
               slightly earlier than INITTIME, and won't be fixed by IBM
               a 5-second fuzziness is included in the revision.        
   Thanks to Randy Shumate, LEXIS-NEXIS, USA.                           
Change 19.282  Explicitly specifying SYNC59=NO in $%VMXGRMFI invocations
VMXGDUR        did not work, printed "uninitialized variable NO " notes,
Jan 30, 2002   and could create incorrect datetime value; even though   
               SYNC59=NO is the default in VMXGRMFI and works.  The user
               found that SYNC59=N circumvented this error, that occurs 
               only if you add SYNC59 to your invocation of             
               The actual error was in the VMXGDUR macro that is called 
                by %VMXGRMFI, and its handling of SYNC59 is now correct.
   Thanks to Helgund Linck, BASF IT Services GmbH, GERMANY.             
======Changes thru 19.281 were in MXG 19.10  dated Jan 29, 2002======   
Change 19.281  Internal utility macro %VGETOBS is now modified to test  
VGETOBS        that DDNAME is not blank; instead of failing, it will pop
Jan 29, 2002   a warning message and will set the DDNAME to WORK.       
   Thanks to Michael Oujesky, MBNA, USA.                                
Change 19.280  WebLog read fails if the ASCII-to-EBCDIC conversion table
VMACWWW        in the ftp/upload program that moved the web log to MVS  
Jan 29, 2002   changed left/right ASCII square brackets into 'AD'x/'BD'x
               instead of the expected 'BA'x/'BB'x hex values.  IBM's   
               "Yellow Card" does show 'AD'x/'BD'x for EBCDIC square    
               brackets, and some editors and (we now know!) some ftp   
               packages also output AD/BD values, but IBM's own ISPF/PDF
               editor has always created the BA/BB value that is in MXG 
               source code on MVS!  Now, when MXG code that reads data  
               records with brackets as delimiters is executed on MVS,  
               MXG will use the TRANSLATE function to change 'AD'x/'BD'x
               into 'BA'x/'BB'x so either delimiter will be recognized. 
   Thanks to MP Welch, SPRINT, USA.                                     
Change 19.279  MXG now sets option COMPRESS=YES by default, to enable   
AUTOEXEC       compression of new SAS datasets, to significantly reduce 
CONFIGV8       the disk space required for work and PDB libraries:      
CONFIGV6        - primarily to eliminate unnecessary out-of-space ABENDs
CONFIGxx          that wake up a human at 3 am when BUILDPDB fails,     
Jan 28, 2002    - Avoid B37 ABENDS                                      
                - Job that now needs two or more work volumes will still
                  run without changing its JCL to UNIT=(SYSDA,3)        
                - Big reduction in I/O time and I/O conflicts           
                - Faster run time: lots on Intel, somewhat on IBM       
                - Automatic; no human intervention or action on your    
                  part is required; many sites already made this choice 
                - For MXG under ITSV: no impact; ITSV has always used   
                  COMPRESS=YES default option.                          
                - Reversible; just specify OPTIONS COMPRESS=NO; as your 
                  first statement in the //SYSIN stream.                
               Those benefits far outweigh the only possible negative:  
               a moderate increase in CPU time on old CMOS pre-G6 CPUs. 
               The savings in human intervention alone is worth the very
               small increase in CPU time of your MXG jobs.             
               Benchmarks in Newsletter FORTY justify this change.      
              -All CONFIGs now have OPTION SOURCE, so that the SAS code 
               statements in your //SYSIN stream will be printed on the 
               SAS log (so I can figure out what program you are running
               if you have a problem).                                  
Change 19.278  Support for RMDS 2.3 added new RMDSORG=5 RMDSACT=A Report
FORMATS        with several new variables in TYPERMDS, and new Sign On  
VMACRMDS       and Sign Off RMDSORG=4 RMDSACT=U/X events with no new    
Jan 28, 2002   data fields.  FORMATS was updated for RMDSORG values.    
   Thanks to Bruno Peeters, Dexia Bank, BELGIUM.                        
Change 19.277  New examples of Availability Reporting based on TYPE30_V 
ANALAVAI       a/k/a PDB.SMFINTRV data from type 30 interval records.   
Jan 27, 2002                                                            
   Thanks to Chuck Hopf, MBNA, USA,                                     
Change 19.276  NTSMF object MSEXCHANGE DS has two added fields:         
VMACNTSM          MSEXCMTA='MSEXCHANGE*MTA'                             
Jan 27, 2002      ABANRRRT='AB*ANR*PER SEC'                             
   Thanks to Terry Heim, ECOLAB, USA.                                   
Change 19.275  Support for NDM Connect Direct for OS/390 CPU time that  
VMACNDM        was added to the end of PT, CT and RT statistics record. 
Jan 27, 2002   MXG variable NDMCPUTM now exists in those datasets, and  
               will be non-missing if the extra field is found.         
   Thanks to John Rivera, (i)Structure, Inc, USA.                       
Change 19.274  Variables B1HITRAT/B2/B3/B4 in DB2STAT1 dataset were not 
VMACDB2        changed when BPHITRAT in DB2STATB was, by Change 17.338. 
Jan 26, 2002   Now all Buffer Hit Ratios use that same equation.        
   Thanks to Helmut Roese, COM Software GmbH, GERMANY.                  
Change 19.273  IMACEXCL now defines MACRO _CICXC22 for CICS/TS 2.2, if  
IMACEXCL       your CICS guru has excluded CICSTRAN fields from the SMF 
VMAC110        type 110 subtype 1 record.                               
Jan 24, 2002                                                            
Change 19.272  The default stored length of numeric variables is changed
VMACmanymany   from 4 bytes for most and 8 bytes for MGBYTES-formatted  
Jan 24, 2002   memory variables, to 5 bytes for most, and 5 bytes for   
Jan 28, 2002   memory, on EBCDIC, and to 6 bytes for both under ASCII.  
               Two macro variables were created so you can change either
               default back; %LET MXGLEN=4; for most numerics, and with 
               %LET MXGBYLEN=8;  the variables will be their original   
               stored lengths.  MXGLEN=5 ON EBCDIC MXGLEN=6 ON ASCII.   
               MXG Newsletter FORTY, SAS Techical Note 2 documented the 
               truncation of up to 255 counts when a large-value 4-byte 
               binary input field is stored in 4 bytes (floating point).
                 It was SAS's original choice of using floating point   
                 that made SAS shine in 1972; other programs used       
                 integer values in fixed length fields, and truncated   
                 the high-order digits with large values!  Using FP     
                 keeps track of the decimal point, avoiding errors!     
               All LENGTH DEFAULT=4 are now LENGTH DEFAULT=&MXGLEN,     
               and all variables with MGBYTES format lengths are now    
               set with &MXGBYLN instead of ' 8 ' bytes.                
               Both MXGLEN and MXGBYLN are set by VMXGINIT when MXG     
               initialized, but can be changed in your //SYSIN code     
               or in IMACKEEP with  %LET MXGLEN=4; %LET MXBYLN=8; to    
               restore the pre-MXG 19.10 default values.                
               There is only one exposure when I change variable length:
               If you use your own PROC APPEND, you must make certain   
               that it uses the FORCE operand, which has always been an 
               MXG reconnendation, so that datasets with dissimilar     
               attributes can be concatenated.                          
               The only use of PROC APPEND in MXG is optional in the    
               VMXG2DTE member, which has always specified FORCE.       
               This change has been under discussion for some time, but 
               it was DB2 Statistics records, which contain accumulated 
               counters, that precipitated the change, which was not    
               needed until now (because DB2 and OS/390 used to crash   
               before the counters got this large: QB2TGET=301,219,072).
               Two adjacent intervals with truncated large values with  
               a delta less than 255 resulted in a zero delta value.    
               I considered just identifing the MXG variables that are  
               accumulated and could get "big" enough now, but that is  
               both human-intensive and high-exposure-to-missing-one;   
               the real exposure should never have existed, and the     
               default length of 5 for a PIB4 has absolutely integrity. 
                 Historical choice of 4 versus 5.  In early 70s, sorts  
                 with SYNCSORT failed when lengths other than 4 or 8    
                 were used; SYNCSORT thought only FORTRAN *4 and *8 FP  
                 could exist.  Old memories of 3am ABENDS remain strong!
                 But MXG has had length 3, 5, and 6 for sometime, so I  
                 now deem it completely safe to use!                    
               Datetimestamp variables are still kept in 8 bytes stored 
               length, as are a few other variables that need the full  
               resolution possible (like SERVUNIT, which may be used    
               directly for billing, and there, pennies ARE important!).
               With the increased lengths, PROC COMPARE between 19.10   
               and 19.09 showed many variables are slightly larger now  
               than before, but the magnitude of the difference is very 
               small; a 60 minute time value was 0.006 seconds larger.  
               But PROC COMPARE will not show exact values before and   
               after MXG 19.10.                                         
               The net impact of changing the default stored lengths on 
               the size of the //WORK space and the //PDB libraries, as 
               usual, depends!  It depends on how many numeric variables
               were increased from 4 to 5, and how many were reduced    
               from 8 to 5, in the datasets that interest you.          
               But, if you use compression, almost always a wise choice 
               now, there is NO increase in the disk space required.    
               Without compression, the storage increase depends on how 
               many records of what type you keep, but here are a two   
               examples of what we have measured with MVS defaults:     
               a. An 842 MB 6/26/30 SMF file created JOBS/STEP/PRINT    
                  datasets; PDB increased from 350MB to 390MB, 11%.     
               b. A 456 MB all-record SMF file, 30 RMF intervals, full  
                  PDB increased from 316MB to 356MB, 12% increase.      
               c. Chuck's big 1160 Cyl PDB increased by 30 Cyl, 3%.     
               There is also a small increase in Virtual Storage needed 
               for a big job like BUILDPDB.  Chuck's Total Memory went  
               from 69MB to 71MB, but that 2MB increase did cause one   
               one site to fail with an out-of-memory error:            
                 viloada: autoload failed for module SASXKRN2           
               because they were limited to 64M by their defaults:      
                 In V6: set by the MEMSIZE=64M default in CONFIGV6.     
                 In V8: Do not have MEMSIZE in CONFIG, use REGION=80M   
               You should compare the Total Memory used reported on the 
               SAS log, or in the IEF374I message on the job's SYSLOG,  
               with your REGION= parm to make sure you have VS left!    
              -z/OS 1.12 message IEF032I/33I replaced IEF374I/276I.     
   Thanks to M.J.H. Elbersen, Rabobank, THE NETHERLANDS.                
   Thanks to F. Nijdam, Rabobank, THE NETHERLANDS.                      
Change 19.271  This conversion utility, used to convert $HEX FORMATed   
UTILCVRT       character variables in PDB libraries moved from EBCDIC   
Jan 23, 2002   to ASCII platforms (if you move your MXG processing from 
               MVS to PCs/unix, you'll copy your historical PDBs),      
               never did work right, but it now works as designed.      
                  CPORT/EXPORT changes all characters variables values, 
                  like '40'x EBCDIC to '20'x ASCII,  during download,   
                  but we need the original '40'x value so bit tests work
                  and so that the CPU Model is '9672'x and not '96B7'x. 
               The 1994 iteration used $EBCDIC, but Change 19.163 shows 
               that won't work.  Instead, UTILCVRT now uses the $MGAS2EB
               mapping ASCII-2-EBCDIC, defined in member FORMATS, and   
               selects variables with  FORMAT=:'$HEX', no longer using  
               the original and 'not happening' INFORMAT=:'NOTRAN' test.
               Of course, this conversion works only if the table that  
               SAS uses in your country matches that format; some sites 
               may find it necessary to edit the $MGAS2EB format into   
               the IMACFMTS tailoring member to match your tran table.  
               But any MXG datasets that you create under ASCII, reading
               SMF,etc, data, are correct and do not need UTILCVRT.     
   Thanks to Mark Darvodelsky, Royal Sun, Australia                     
Change 19.270  Two variables that estimate the Average Logically Swapped
VMAC71         frames, CSFRLSAV and ESFRLSAV were found to be negative  
Jan 22, 2002    CSTORE=1040MB,CSFRTOAV=920,CSFRFXAV=142==>CSFRLSAV=-4MB 
               which printed as -42E5.  The problem is subtracting two  
               average values on a system with essentially no logical   
               swapping, the "zero" is slightly negative.  I now test   
               the calculation, and when negative, the variable is set  
               to a missing value, so that a real zero value would still
               be preserved as a zero value, but these negative values  
               will just be missing.                                    
   Thanks to Kenneth D. Jones, xwave, CANADA.                           
Change 19.269  The Initiator Number, INITNUMB and Name, INITNAME are now
BUILD005       added to the type 30 subtype 1 (job initiate) record when
BUIL3005       you install the Assembly code in SMF exit IEFU84 that    
IEFU84         will move those values into the subtype 1 record.        
VMAC30        -This change creates and keeps those two new variables in 
Jan 23, 2002   dataset TYPE30_1, and updated BUILDPDB logic to add them 
Jun 24, 2004   to the PDB.JOBS dataset as well.  The variables will be  
               missing/blank if the SMF exit has not been installed.    
               Jun 24, 2004: The IEFU84 exit code member was added by   
               MXG Change 22.136; the original IEFU83 references were   
               wrong, as it is IEFU84, not IEFU83, that writes the SMF  
               30 subtype 1 SMF record.  Text was changed from 83 to 84.
              -The SMF exit IEFU84 source code is in member IEFU84,     
               along with notes, so your SYSPROG can see what it does.  
                  The exit moves the initiator number (in binary) into  
                  the first four bytes of PROGRAM (SMF30PGM) name field,
                  and the initiator name (character) into the second    
                  four bytes of PROGRAM name. SMF30PGM is not populated 
                  at job initiate since PROGRAM doesn't exist until     
                  after the step initiates.                             
              -However, it is your System Programmer's responsibility to
               install and test any SMF exit, and thus your company, and
               not Merrill Consultants, must take all risk in choosing  
               to adapt this enhancement SMF exit into your systems:    
                 recognize that the risk with an SMF exit-in-error could
                 be as bad as a system outage.                          
               I would not provide this example if I did not think it is
               safe, and almost every MVS site uses an SMF exit, but you
               should read up on SMF exits in the SMF manual before you 
               convince your friendly SysProg to install the exit.      
               Remind them that the exit will let you to help them track
               which job us which initiator, to help in chasing ABENDS  
               with overlaid initiators, or in measuring which init is  
               used how often, etc.                                     
               This exit is provided because IBM does not currently     
               provide this information in their SMF type 30 record.  I 
               have provided them with the tested exit code in the hope 
               that they will eventually add the fields so that you     
               don't have to install an SMF exit to get them.           
               Several MXG-L postings on the subject of initiator number
               precipitated this change, but the guys who suggested and 
               coded the solution, respectively, get the CodeShark cite!
   Thanks to Mike Shaw, MVS QuickRef/Chicago Soft, USA.                 
Change 19.268  Under very strange circumstances: when %LET MACKEEP= was 
VMXGDEL        used to redefine an old style macro that contained an    
VMXGOPTR       %VMXGDEL(DDDDDD=dddddd) invocation, the internal call to 
VMXGSUM        %VMXGOPTR by VMXGDEL generated this error message:       
Jan 23, 2002     ERROR 14-12: Invalid option OBS=;; for SAS option OBS. 
Jan 26, 2002   VMXGOPTR was needed by VMXGDEL solely because PROC SQL   
               doesn't execute if OBS=0, but PROC SQL/VTABLE had to run 
               in VMXGDEL (even when OBS=0 was specified) to populate   
               macro variables, and OBS=0 is commonly set for testing.  
               We had used VMXGOPTR to store the old OBS=value, set it  
               to OBS=MAX (so PROC SQL would execute), and then restore 
               the original OBS= value, all inside VMXGDEL.  But when   
               we could not diagnose this particular macro error, Rick  
               Langston at SAS showed us the GETOPTION() function, which
               allowed us to remove the PROC SQL/VTABLE in both VMXGDEL 
               and in VMXGOPTR, with a cleaner, safer approach.         
               The GETOPTION() function can be used in two ways:        
                - DATA step solution:                                   
                   %GLOBAL OBSVALUE;                                    
                - pure macro solution:                                  
                   %MACRO GETOBS;                                       
                     %GLOBAL OBSVALUE;                                  
                     %LET OBSVALUE=%SYSFUNC(GETOPTIONS(OBS));           
                   %MEND  GETOBS;                                       
               We chose the pure macro solution in VMXGDEL and VMXGOPTR.
               We also changed the design of VMXGOPTR so that it resets 
               the option value to what it was in the prior VMXGOPTR    
               execution; the original design kept the value of the     
               option only from the very first invocation of VMXGOPTR,  
               and did not recognize if you changed the option between  
               paired invocations of VMXGOPTR. See comments in VMXGOPTR.
              -In QA tests of these VMXGOPTR and VMXGDEL changes, Bruce 
               set OPTION OBS=10, and found two places inside VMXGSUM   
               where we had failed to use %VMXGOPTR to protect for user 
               change of OBS=; VMXGSUM was corrected to now protect.    
               With OBS=11, this error would not have been corrected!   
   Thanks to Bruce Widlund, Merrill Consultants, USA.                   
   Thanks to Rick Langston, SAS Institute, USA.                         
   Thanks to Rosalind Howe, IBM Global Services, USA.                   
======Changes thru 19.267 were in MXG 19.09 dated Jan 21, 2002======    
Change 19.267  Support for IBM SMF 119 (TCP/IP) record from z/OS V1R2.0 
EXT11901       Communications Server, which replaces the SMF 118 record 
EXT11902       from the current IBM TCP/IP product.  The data content is
EXT11903       significantly enhanced beyond what is in the current 111,
EXT11905       with many new subtypes and these datasets created:       
EXT119A7       SUBTYPE  DATASET  description                            
EXT119B7         1     TYP11901  TCP CONNECTION INITIATION              
EXT11908         2     TYP11902  TCP CONNECTION TERMINATON              
EXT11910         3     TYP11903  FTP CLIENT TRANSFER COMPLETION         
EXT11920         5     TYP11905  TCP/IP STATISTICS                      
EXT11921         6     TYP11906  INTERFACE STATISTICS                   
EXT11922         7     TYP119A7  SERVER PORT STATISTICS - TCP           
EXT11923         7     TYP119B7  SERVER PORT STATISTICS - UDP           
EXT11970         8     TYP11908  TCP/IP STACK START/STOP                
EXT11972        10     TYP11910  UDP SOCKET CLOSE                       
FORMATS         20     TYP11920  TN3270 SERVER SNA SESSION INIT         
IMAC119         21     TYP11921  TN3270 SERVER SNA SESSION TERM         
TYPE119         22     TYP11922  TSO TELNET CLIENT CONNECTION INIT      
TYPS119         23     TYP11923  TSO TELNET CLIENT CONNECTION TERM      
VMAC119         70     TYP11970  FTP SERVER TRANSFER COMPLETION         
VMXGINIT        72     TYP11972  FTP SERVER LOGIN FAILURE               
Jan 18, 2002                                                            
Change 19.266  Variable RVSTBIN, Bin Number, can be characters, but MXG 
VMACEDGR       did not know that, and character data caused a non-fatal 
Jan 16, 2002   INVALID DATA FOR RVSTBIN message.  New variable RVSTBINC 
               is now Character; RVSTBIN is still numeric, but missing  
               value now if RVSTBINC has non-numeric characters.        
   Thanks to Joe Ellis, American Century, USA.                          
Change 19.265  Dataset STCHSC has zero observations, because STK changed
VMACSTC        the length of the record; long ago MXG had to protect for
Jan 16, 2002   records shorter than the then-written 140 bytes, but now 
               their subtype=7 record is only 120 bytes.  Logic revised.
   Thanks to Fraser Wong, CitiCorp, USA.                                
Change 19.264  Cisco Memory Pool variables NRPxxxxx in NPMINNRP were all
FORMATS        missing; MXG tested NRPDTYP=1 for Cisco, but the records 
VMAC28         contained NRPDTYP=0, so nothing was input.  Now, the test
Jan 14, 2002   is for NRPRTYP=2 (Record Type, not Data Type) for the    
Jan 16, 2002   Memory Pool data.  IBM lists two other NRPRTYP values of 
                NRPRTYP=1 - CPU and Memory   NRPRTYP=3 - Interface      
               but does not document the contents of the NRP segment for
               those (as yet) unsupported values.  Variables NRPRTYP and
               NRPDTYP are now kept in NPMINNRP so you can see if any of
               the new Record Types are in your SMF data; contact MXG   
               support when you find any, so we can decode them!        
               New format MG028PT decodes Cisco pool type variables     
               NRPCPTYP and LNCDCPTY:                                   
                 1='1 PROCESSOR MEMORY   4='1:FAST MEMORY'              
                 2='1:I/O MEMORY'        5='1:MULTIBUS MEMORY'          
                 3='1:PCI MEMORY'                                       
               Jan 24: IBM APAR OW53087 documents that the DTYP=0 in the
               NRP and NRT segments is now a reserved field, but that   
               APAR does not document the RTYP=1 and RTYP=3 data.       
               Feb 15: IBM will correct OW53087. The xxxRTYP field has  
               only one value in each record: NRPRTYP==2 NRT=1 NIT=3,   
               so there are no undocumented segments, and the misleading
               documentation will be revised by IBM.  See Change 20.003.
   Thanks to Howard Swift, HSBC Bank, UK.                               
   Thanks to John Wilmot, HSBC Bank, UK.                                
Change 19.263  The _SDB2ACC sort macro for DB2ACCT and _BDB2ACC BY list 
VMACDB2        were defined as blank, to prevent an accidental sort of  
Jan 14, 2002   that potentially large dataset, but since the _SDB2ACC   
               reference in _SDB2 is commented out, both macros are now 
               defined, in case you do need to sort and remove dupes    
               from your DB2ACCT dataset.                               
   Thanks to Rosalind E. Howe, IBM Global Services - South, USA.        
Change 19.262  A sample AS/400 report from TYPEQAPM Performance         
ANALQAPM       Monitor data.                                            
Jan 11, 2002                                                            
   Thanks to Stephen Hoar, TSB, ENGLAND                                 
Change 19.261  Support for IBM AIX Performance Toolbox and Performance  
ADOCAIX        AIDE for POWER, PTX Version 2, refs: SG24-2011-00.       
EXAIXPTX       This internal design is extremely robust, and is similar 
IMACAIX        to the new WebLog support; the list of fields in your    
TYPEAIX        data is read and used to input the record, so you can    
TYPSAIX        have different sets of fields defined for different AIX  
VMACAIX        servers, and the one MXG program will work on all their  
VMXGINIT       data, transparently.                                     
Jan 15, 2002   This implementation supports the default set of 55 fields
Jan 17, 2002   and the heavy work is done; expansion to keep any of the 
               other 2000 possible fields is easy, when anyone actually 
               has actually created those additional fields!            
   Thanks to Glenn Bowman, Wakefern, USA.                               
   Thanks to Al Sias, Wakefern, USA.                                    
Change 19.260  New optional design will change timezones of all datetime
TIMEBILD       variables read from SMF records, based on a table lookup 
TIMETABL       of SYSTEM/SYSPLEX/datetime-range in which you set the    
VMACmanymany   offset to be added to all datetime variables.            
VMXGTIME       This is needed when you have SYSTEMs with different time 
Jan 11, 2002   zones, so you can have a common timezone for analysis of 
Jan 15, 2002   shared dasd, time of day, etc.                           
Jan 26, 2002                                                            
               The table is defined in member TIMETABL (copied into your
               USERID.SOURCLIB tailoring library) with a syntax of:     
                 SYSA     01/01/2002 00:00:00 01/31/2999 23:59:59 -21600
               to change SYSA datetimes back 6 hours, for a datetime    
               range from now until infinity.                           
               Even if you have defined your table in member TIMETABL,  
               nothing happens until you enable time change with this   
               statement in your //SYSIN stream:                        
               Invoking %TIMEBILD enables the time changing logic, and  
               reads the TIMETABL member with the TIMEBILD program that 
               creates the (temporary) format $MGTMPTM that is the look 
               up table that is used by %VMXGTIME.                      
               The default table is the TIMETABL member in your SOURCLIB
               concatenation, but you can use %TIMEBLD(TIMETABL=XYZ);   
               to use a different time change table; see its comments.  
               While the table supports SYSPLEX for selection, SYSPLEX  
               only exists in some records, so it is really there only  
               for future selection.  Only in the case where you know   
               that all records you want to change (RMF is the only one 
               at present) contain SYSPLEX, then and only then could you
               have a value for SYSPLEX in the TIMETABL, and you could  
               not then use that same TIMETABL to select TYPE1415 data  
               that does not contain a SYSPLEX variable.                
               To make the actual time change itself, this statement    
                 %VMXGTIME(var1 var2 var3,system,sysplex);              
               was inserted in the correct place in every VMACxxxx      
               member that creates datetime variables from SMF records. 
               All MXG members that process IBM or User SMF records have
               been updated, as were most other products that contain a 
               SYSTEM variable.  Some non-SMF products that do not have 
               a "SYSTEM" field were set aside until a need arises.     
               VMXGTIME statements were inserted 874 places in 380 MXG  
               members, listing 1,300 variables that can be changed in  
               'one felt swoop':   update TIMETABL, invoke %TIMEBILD.   
               See VMXGTIME revisions, GMT support, and corrected CPU   
               and memory cost measurements in Change 19.286/MXG 19.11. 
Change 19.259  The MXGTMNT Tape Mount and Tape Allocation Monitor SMF   
ASMTAPES       record had the wrong DDNAME if the tape UCB was a 4-digit
VMACTMNT       address (the incorrect DDNAME was the last DDNAME in the 
JAN 20, 2002   TIOT). The previous logic compared UCB address to get the
               the correct DDNAME; this revision compares device numbers
               for the UCBs, so this logic will work regardless of      
               whether the tape UCB address is above or below the 16MB  
               line, or 3 or 4-digit device address.  The revision also 
               gets the correct DSAB allocation flags for tape mounts.  
               This revision is "ML-20" of the monitor program.  Your   
               SysProg must re-assemble ASMTAPES and link edit the new  
               MXGTMNT program that is executed by your MXGTMNT started 
               task that writes the SMF records, to get the corrected   
               DDNAME into those SMF records, but you don't need to do  
               anything to your daily MXG SMF processing jobs; they will
               get the correct DDNAME without any change.  Only if you  
               want the new DSABFLAG variable (which is not currently   
               used by MXG) in your TYPETMNT dataset, will you need to  
               use the revised VMACTMNT member.                         
   Thanks to Chuck Hopf, MBNA, USA.                                     
   Thanks to Jim Sherman, FDC, USA.                                     
Change 19.258  Variable XCPUFLAG is now formatted with new $MGXCMCP     
FORMATS        format to decode the CPU type of the ftp transfer, and   
VMACXCOM       the list of old and new values for XCPUFLAG in ADOCXCOM  
Jan  9, 2002   was updated with the new values.                         
   Thanks to Tony P. Steward, Post Office, ENGLAND.                     
Change 19.257  Two examples that select related pairs of SMF records.   
ANAL30         Program ANAL16 reads SMF to create TYPE16 (sort) obs for 
Jan  8, 2002   selected sorts (in this example, those with concatenated 
Jan 15, 2002   SORTIN datasets, because only the first DSNAME is in the 
               TYPE16 record), and uses those selected TYPE16 obs to    
               create a table lookup that is then used to re-read SMF   
               and select only the matching SMF TYPE1415 records; the   
               site could thus find the dsnames of all SORTIN datasets. 
               Program ANAL30 reads SMF to create only TYPE30_4 obs for 
               steps you selected (this example, programs IEBCOPY and   
               IEBGENER), creates the lookup table, which is then used  
               to select all of the non-VSAM TYPE1415 and VSAM TYPE64   
               datasets that were opened by that step.                  
               These examples are easily extended to select other       
               pairs of data where one event defines a timerange, and   
               the matching events must occur within that timerange.    
               I've been meaning to write this example technique for    
               some time; this specific request precipiated the program!
   Thanks to David Goldstein, EDS, AUSTRALIA.                           
Change 19.256  Variable UMRECRD in dataset DCOLMIGS is now formatted by 
FORMATS        the new $MGDCORF format to decode the Record Format when 
VMACDCOL       UMRECRD is printed or displayed.  And variable DCERECRD  
Jan  4, 2002   in dataset DCOLDSET is now kept, and formatted with the  
               new $MGDCORF format, also displays the Record Format (and
               eliminates the need to combine the same information from 
               the variables DCDRECFA/B/C/F/J/S/U/V to get it!          
   Thanks to Wanda Prather, The John Hopkins Applied Physics Lab, USA   
Change 19.255  Comments only.  If you add NPM TYPE28 processing to your 
DIFF28         BUILDPDB, you must either add  %INCLUDE SOURCLIB(DIFF28);
Jan  2, 2002   in member EXPDBOUT (to deaccumulate the NPMINPMT data) or
               if you want all NPM datasets written to your PDB library,
               then you would instead add  _S28  in member EXPDBOUT, as 
               that "product" sort macro sorts (and deaccumulates where 
               necessary) all datasets created by TYPE28 code.          
               The DIFF28 member contains only  _S028IN7, the "dataset" 
               sort macro for NPMINPMT, which is included in _S28 macro.
               DIFFxxx members exist only for products with accumulated 
               data fields, and MXG always invokes the DIFFxxx member in
               both the TYPExxx and TYPSxxx members, to hopefully assure
               that you always have legitimate (i.e., deaccumulated)    
               values.  But now, the DIFF logic is contained in the     
               "dataset" sort macro, so the DIFFxxx members contain only
               the specific datasets that must be deaccumulated.        
   Thanks to Bruce Hewson, CitiCorp, N.A., SINGAPORE.                   
Change 19.254  Support for the configuration record (NTCONFIG dataset)  
VMACNTSM       adds variables DCSDURATM (DCS Interval) and DSCVRYRT     
Jan  2, 2002   (Discovery Record Types) - existing fields not decoded,  
               and variable SUMRYVER (Summary Version Number), to be    
               added to the record when this data file was created by   
               NTSMF's summarization program, which is also the flag    
               that this input file contains summarized data.           
Change 19.253  Variable LABEL in TYPETMNT was wrong; the INPUT location 
VMACTMNT       of TMNTLAB should have been the first byte, with the     
Dec 30, 2001   second byte unused.                                      
   Thanks to Mike Jacques, Branch Banking & Trust, USA.                 
Change 19.252  "New" DFSMS/rmm variables include Creating Program Name, 
VMACEDGR       Total Block Count across all volumes, and "Last Used"    
Dec 30, 2001   Program/Job/Step/DD/DEVNR are now INPUT and kept in      
               TYPEEDGR.  They were added by IBM by OW40710 in 1999.    
   Thanks to Joe Lodyga, Whirlpool Corporation, USA.                    
Change 19.251  Use of long-variable-names was not fully supported in    
VMXGSUM        VMXGSUM; names could be truncated to eight bytes.  Since 
VMXGINIT       MXG does not use long variable names, this only impacted 
Dec 27, 2001   use of VMXGSUM with long variable names in SAS V8.       
Dec 30, 2001   To accomplish this change, TEMPnn libnames will be built 
Jan  4, 2002   with ENGINE=V8SEQ under V8, and ENGINE=V6SEQ under V6,   
Jan 20, 2002   and TEMPnENG is set blank if TEMPnn is not used.         
               Corrected logic if KEEPALL=NO was used.                  
              -In member VMXGINIT, new global macro variable MXGLEN     
               defaults to 4, and it is used by VMXGSUM (instead of the 
               hardcoded 4) to set the length of variables on the output
               side of VMXGSUM, for those rare cases where you need to  
               increase kept length, by using  %LET MXGLEN=8; before    
               your %VMXGSUM invocation.  NO LONGER TRUE.               
               PARAGRAPH WAS CHANGED BY CHANGE 19.272 in JANUARY.       
              -PROC SQL's scope was limited to look only at LIBNAMEs;   
               under very unlikely circumstances, it could read all SAS 
               datasets on a multi-volume tape data library; nothing    
               failed, but the job took longer than expected.           
  Thanks to Paul Gillis, Pacific Systems Management Pty, AUSTRALIA.     
Change 19.250  The Logically Swapped ESTORE in variable ESFRLSAV was    
VMAC71         wrong; ESFRHSAV was being added instead of subtracted.   
Dec 27, 2001     ESFRLSAV=ESTORE-(ESFRTOAV+ESFRHSAV); is now used.      
   Thanks to Peter Webber, CIS, US.                                     
Change 19.249  Major revision in support for Web Logs.                  
EXWWWCOO       The original TYPEWWW was completely restructured and now 
EXWWWIIS       creates multiple datasets, and more are likely over time.
EXWWWLOG      -Multiple web log data formats are automatically detected,
EXWWWREF       and multiple "Log Event" datasets will be created where  
EXWWWURQ       the contents of the logs are sufficiently different.  An 
IMACWWW        observation in the "Log Event" dataset is created for    
VMACWWW        each web log record that is not filtered.  At present:   
TYPEWWW         Dataset   Description of Web Log                        
TYPSWWW         WWWLOG    Netscape/I-planet,Common Log Format,Websphere 
Jan  7, 2002    WWWIIS    Microsoft IIS (old and new versions)          
              -"Multiple segment" datasets are created for content items
               when there can be more than one item in a log event.  The
               individual segments can be mapped back to their parent   
               log event observation using the ZTIME/WEBSEQNR variables.
               At present, these multiple segments are decoded:         
                Dataset   Description of contents                       
                WWWCOOKE  Cookies, COOKNAME and COOKVALUE pairs         
                WWWREFER  Referer text, may be revised.                 
                WWWURQRY  URI Query, URIQNAME, URIQVALU pairs.          
              -By default, MXG Sorts invoke the NODUP option to remove  
               all duplicates, but duplicate log events occur (refresh  
               same page in same second), and to allow you to override  
               and keep duplicates, macro variable &SASNODUP is defined 
               in VMXGINIT (Default is NODUP) and it is used in VMACWWW 
               so you can supress duplicate removal in web logs by      
               using %LET SASNODUP=;  in your //SYSIN                   
              -There is a lot of logic in VMACWWW that will eventually  
               be documented in ADOCWWW, and there will be new exits to 
               allow filtering of what records are kept during INPUT, as
               web log data can be voluminous.  Current notes:          
                 Variable HOST is LOWERCASED, so that all of the casing 
                 spelling variants (WWW.MXG.COM, will be   
                 Variable VISITOR is created from cookies if either the 
                 SITESERVER=ID= or ASPSESSIONID cookie name (COOKNAME)  
                 is found, to track the same user thru your servers. If 
                 neither cookie is found, a VISITOR variable is created 
                 as TRIM(HOST)!!TRIM(CLIENTIP)!!TRIM(USERNAME). Note the
                 USERNAME exists only for URLs in the authenticated     
               For web logs with self-contained documentation of their  
               contents (currently, the IIS "#FIELDS" record and the    
               Netscape "format=" record), this new architecture reads  
               those header records to determine what data fields are in
               your data records, and in what order, to automatically   
               process logs with excluded, skipped, optional fields,    
               and with those fields in any order, transparently!       
               These powerful algorithms will be easy to use to support 
               other new data that contain self-documenting headers.    
               While this support is fully usable now, I anticipate the 
               expansion of analysis and reporting of this clickstream  
               data.  Unfortunately, at present, there is no way to     
               correlate the computer resources that are associated with
               these web activities.  But this is ongoing research, and 
               additional enhancements can be expected.                 
   Thanks to Tom Gray, SPRINT, USA.                                     
Change 19.248  Change 19.187 was incomplete; an ID statement referenced 
ASUMNTIN       non existent variables and was removed.                  
Dec 21, 2001                                                            
   Thanks to Jim Quigley, ConEd, USA.                                   
======Changes thru 19.247 were in MXG 19.08 dated Dec 20, 2001======    
Change 19.247  Some ANALDB2R reports failed if all DB2 datasets had zero
ANALDB2R       observations.  The original design of %VGETOBS macro did 
VGETOBS        did not differentiate a non-existent dataset from one    
VMXGINIT       with zero observations.  This enhancement to %VGETOBS    
Dec 19, 2001   creates new GLOBALed macro variable VGETDSN that will be 
               blank if the dataset does not exist in the DDNAME, or    
               will contain the data set name if it exists.  If the     
               dataset is found, an MXGNOTE with name and number of     
               observations is printed on the log; if not, an MXGWARN is
               printed that the requested dataset was not found.        
               The invocations of %VGETOBS in ANALDB2R were then revised
               to exploit the enhancement.                              
Change 19.246  Sophisticated option for VMXGSUM when two output summary 
ADOCSUM        datasets at different summary levels are to be created.  
VMXGSUM        MXG's normal HouseKeeping deletes the MXGSUMx temporary  
Dec 18, 2001   datasets, to make disk space available, but with the new 
               HOUSKEEP=NO specified in your first %VMXGSUM invocation, 
               no housekeeping is done, so a second %VMXGSUM can then   
               specify NOSORT=YES to bypass the PROC SORT, and since the
               first step (when needed) will be a VIEW, there is no I/O 
               associated with the output side of the first data step,  
               which is then read directly by the PROC MEANS.           
               You have to be very sure of what you are doing; if the   
               sort order is not correct, the second %VMXGSUM invocation
               will fail.  Examples of using these options are given in 
               member ADOCSUM.                                          
   Thanks to Chuck Hopf, MBNA, USA.                                     
Change 19.245  Support for APAR OW49808 to RMF Type 70 Subtype 2 CRYPTO 
EXTY70X2       record (new in z/OS 1.2, Change 19.176) enhances the data
EXTY70Y2       measures and there are now three datasets created from   
IMAC7072       the 70-2 record:                                         
VMAC7072        DDDDDD  Dataset  Description                            
               These data will become important as they will be used by 
               the Secure Sockets Layer associated with Websphere and   
               similar secured systems.                                 
               These data have not yet been validated with test records.
Change 19.244  Support for IDMS Log Statistics Records decodes LGRTYPE  
EXIDML01-      'F6'x and '76'x record's into eleven datasets, one for   
EXIDML11       each STLTYPE (01x-11x), but only the STLTYPE=02 TASK     
FORMATS        records are fully decoded (in dataset IDMLOG02).  Records
TYPEIDML       with STLTYPE=01 (SYSTEM) have three non-zero fields, but 
VMACIDML       do not match their DSECT descriptions, and all other STL 
VMXGINIT       TYPEs in the test file have no data fields.              
   Thanks to Hugh O'Neill, Dow Jones, USA.                              
Change 19.244  This Windows Disk Space Used utility read the output of  
UDSKCONT       DIR commands to report disk space by direcory and file.  
Dec 13, 2001   It now supports Windows NT/2000/XP, which has a different
               output format for the DIR command, but you have to tell  
               it which format you want to read.  I use this to find out
               why I've run out of space on a PC disk.                  
Change 19.243  IBM declared field QBACSWU to be 'Reserved' in DB2 6.1,  
VMACDB2        but the field appears to continue to contain QBACSWU, so 
Dec 13, 2001   the QBACRSVD field is now input into QBACSWU variable,   
               but please validate and use it with caution.             
   Thanks to Charles Harbour, John Deere, USA.                          
Change 19.242  For users of TYPEIMS7 and VMACIMS, variables IMSGTEXT and
VMACIMS        OMSGTEXT in IMS01/IMS03 datasets were blank with IMS 6.1 
Dec 12, 2001   and wrong with 5.1 that are now correctly input in this  
               almost-archaic member.  Some unnecessary/confusing tests 
               IF _IMSVERS were removed for readability.  Several new   
               variables were INPUT but not kept; MSGRACUS (RACF User   
               ID, also "LogonID"), MSGSAFNM, MSGUSIDI, and MSGWLMSC are
               now kept in the 01/03 datasets.                          
               The recommended MXG IMS Log processing is in the members 
               JCLIMSLn, ASMIMSLn, and TYPEIMSA/TYPEIMSB, and they are  
               not impacted by this change.   This site had reports that
               were based on the raw IMSnn datasets created by VMACIMS, 
               so it was updated to preserve their reports.             
   Thanks to James Seitz, Oklahoma Department of Human Services, USA.   
   Thanks to Ken Sharpe, Oklahoma Department of Human Services, USA.    
Change 19.241  MXG enhancement for Batch Pipes adds these variables     
Dec 11, 2001   TYPE91nn datasets for subtypes 11,12,13, and 15, and     
               increases the number of system names/flags variables     
               SMF91XYn and SMF91XFn from eight to sixteen to support   
               sixteen systems in a sysplex.                            
   Thanks to Michael Oujesky, MBNA, USA.                                
Change 19.240  MXG 19.04-19.07 only.  Variables PCHANBY and PNCHANBY can
VMAC73         be always zero in error.  Change 19.176 mis-located the  
Dec 10, 2001   initialization of those variables for SMF73CMG=0 records.
   Thanks to John Gebert, Office Depot, USA.                            
Change 19.239  Several Coupling Facility variables in TYPE74CF/TYPE74ST:
VMAC74         R744SASQ/R744SSSQ/R744SQSQ/R744SDSQ/R744FCSQ/R744FSQU    
Dec  6, 2001   were all sums of squares that are now divided by 1000000.
               Variables R744FTIM/R744FCTM were incorrectly divided by  
               4096. Our test data had all zeros, so these incorrect    
               conversions were not previously caught.                  
   Thanks to Bill Cool, EDS Federal Government, USA.                    
Change 19.238  Variable DEVNR is now created in dataset TYPE42VL as a   
VMAC42         numeric field with format HEX4; variable SMF42DEV in that
Dec  6, 2001   dataset is a 4-byte character device number in hex, but  
Dec 18, 2001   DEVNR is numeric in all other datasets, and is needed to 
               merge TYPE42VL with other data.                          
               Dec 18: SMF42DEV input changed to $CHAR and logic to     
                       INPUT the DEVNR variable was revised to work.    
   Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA   
Change 19.237  Variable LOCLINFO in PDB.STEPS was incorrect.  Its value 
BUILD005       in a step record was being overlaid with LOCLINFO from   
BUIL3005       the other job-level records, so if you put different data
Dec  4, 2001   in the STEP records, it was lost.  Now, the step value   
               is preserved for each step.                              
   Thanks to Diane Eppestine, Southwestern Bell, USA                    
Change 19.236  Values for SMF73CPD (Channel Path Description), decoded  
FORMATS        by MXG Format MG073CD, were updated for new '14'x,'15'x, 
Nov 26, 2001   values for HSSI and Ethernet Open System Adapter Channel.
Change 19.235  Observations were created in new dataset MQMCFMGR only by
VMAC115        accident; the test IF SM1152O2 GT 0 THEN DO; should have 
Nov 26, 2001   been coded as      IF SM1152OC GT 0 THEN DO;             
   Thanks to Martin Lee, Safeway Stores PLC, ENGLAND.                   
Change 19.234  MXG Software (all versions) supports the euro symbol, as 
none           there are no MXG variables that contain financial values 
Nov 23, 2001   in euros, dollars, or any other units of currency.       
                  Of course, you can always create financial variables  
                  in your reporting and billing programs, and there, you
                  can use the SAS FORMAT EUROw.d, which complies with   
                  the European Monitary Union rules and displays an "E" 
                  as the euro symbol, without any special characters.   
                  But be careful with EUROw.d (and DOLLARw.d) formats;  
                  you must not underspecify the field width w, or SAS   
                  will truncate from the left and your euro/dollar sign 
                  will not be printed (as shown in SAS documentation!): 
                  With a value of   x= E1254.71 euros                   
                    using format       will print as                    
                    EURO6.0             E1,255                          
                    EURO5.0             1,255                           
                    EURO5.1              1255                           
                    EURO6.1             1254.7                          
   Thanks to K. Strange Bruun, IBM Denmark A/S, DENMARK.                
Change 19.233  For NT Trending, default DDNAMES could not be changed, as
BLDNTPDB       the user tailoring could be overwritten by TRND defaults.
TRNDNTIN       Now, user tailoring of DDnames works as expected.        
Nov 23, 2001                                                            
   Thanks to Greg Jackson, National Life Insurance of Vermont, USA.     
Change 19.232  The new IHDRTMO2 exit that was supposedly added by Change
IHDRTMO2       Change 19.154 was created but not included in VMACTMO2.  
VMACTIMS       This change adds the %INCLUDE of IHDRTMO2 in VMACTMO2; it
VMACTMO2       is called after the Transaction Header or Interval Header
VMACTMV2       has been INPUT.  Comments in IHDRTMO2 were updated and   
Nov 20, 2001   now include an examples of tailoring, either by EDIT of  
Nov 23, 2001   the IHDRTMO2 member, or by using the %LET MACTMOH= in    
               your //SYSIN input.                                      
              -Similarly, the INCLUDE of IHDRTIMS and IHDRTMV2 have been
               added to their appropriate VMAC member.                  
   Thanks to Jerry Urbaniak, Acxiom CDC, USA.                           
Change 19.231  Sample MQ Series reports were updated.  Originally, the  
ANAL115        ANAL115 member contained an MXG "program" that was read  
Nov 20, 2001   with a %INCLUDE, and then executed with the syntax:      
                    %INCLUDE SOURCLIB(ANAL115);                         
               Now, the ANAL115 member defines %MACRO ANAL115;, so your 
               %INCLUDE statement is now replaced with:                 
               to execute with all defaults, or with                    
               if you want to change the input to use SMF data, select  
               reports, etc.  See the complete list of arguments in the 
               comments in the ANAL115 member.  The member was changed  
               into a %MACRO so that we could provide you with arguments
               to tailor the execution and provide report selection:    
               - The %INCLUDE(ANAL115); statement now would not fail,   
                 but it would only read the member and compile the      
                 %ANAL115 macro, but it would not "do" anything, since  
                 it does not invoke the actual %MACRO name.             
               - You don't need the %INCLUDE(ANAL115); statement now,   
                 because when SAS sees that %ANAL115; statement in your 
                 //SYSIN (because MXG set options SASAUTOS=SOURCLIB and 
                 MAUTOSOURCE in its CONFIGV8/AUTOEXEC), SAS will read,  
                 compile, and execute the %MACRO defined in ANAL115.    
               There are extensive IBM notes about measuring/monitoring 
               MQ series in the comments of this report member.         
   Thanks to Bruce Widlund, Merrill Consultants, USA.                   
Change 19.230 -Using %LET MACKEEP= to tailor the DCOLLECT part of the   
DAILYDSN       DAILYDSN program (used in the JCLDAYDS example to read   
VMXGINIT       DCOLLECT and TMS data for "Daily Dataset Accounting")    
Nov 19, 2001   did not work.  The second execution of %VMXGINIT inside  
               DAILYDSN was re-executing the %LET MACKEEP=; statement to
               set the MACKEEP macro variable back to blank.  Further   
               examination of the %GLOBAL statement documentation showed
                  A macro variable created with a %GLOBAL statement has 
                  null value until you assign it some other value. If a 
                  global macro variable already exists and you specify  
                  that variable in a %GLOBAL statement, the existing    
                  value remains unchanged.                              
               so there is no need to initialize macro variables to null
               value if the variables is in a %GLOBAL statement, and the
               removal of those %LET xxxxxx=.; (null value) statements  
               permits multiple execution of %VMXGINIT.                 
              -However, the purpose of the user's MACKEEP= tailoring was
               to make DAILYDSN only create the four DCOLLECT datasets  
               that are used in DAILYDSN, so that member now has an     
               example of a %LET MACKEEP= statement that only keeps the 
               four DCOLxxxx dataset that are used by DAILYDSN:         
                 DCOLDSET DCOLVOLS DCOLMIGS DCOLBKUP                    
   Thanks to Joseph Stoll, University of Wisconsin Hospital, USA.       
Change 19.229  Support for RSD Folders ASTRE Auditing User SMF Record   
EXRSDAUD       creates new RSDAUDIT dataset with member TYPERSDA, and   
FORMATS        new formats MGRSDAU and $MGRSDFO.  One set of fields,    
IMACRSDA       Folder Type is not documented, but will eventually be    
TYPERSDA       decoded with another format.                             
TYPSRSDA       Note that the other RSD Folder SMF records are supported 
VMACRSDA       in TYPERSDF.                                             
VMXGINIT       The tested version is RSD/Folders V 4.1.                 
Nov 17, 2001                                                            
   Thanks to Christa Neven, KBC Bank, BELGIUM.                          
Change 19.228  MXG 19.01-19.07 only, execution under ITSV, received this
Nov 16, 2001   AND NUMERIC, because MXG 19.01 unintentionally changed   
               those variables from CHAR to NUM, but ITSV's dictionary  
               (righteously!) expected them to still be character.      
               This change creates variables UNIT0-UNIT99 as CHAR $4    
               variables, as they were in MXG 18.18, but it also creates
               new numeric variables DEVNR0-DEVNR99, that should be used
               instead of UNITn variables, so that your devices are in  
               numeric order: 181x..18Ax..A18x..B41x...  If you use the 
               character unit address, you get A81x..B41x..18Ax..181x.. 
               Variables DEVNR0-DEVNR99 are FORMATed HEX4, so they      
               print the same value as the UNITn variables.             
   Thanks to Bob Funk, Progressive Insurance, USA                       
Change 19.227  Fields added to HSM User SMF (usually 240/241) last year,
VMACHSM        compatibly, in what were reserved bytes.  These new MXG  
Nov 15, 2001   variables now exist in HSMFSRST dataset:                 
                  FSRFLG3 ='FSRFLG3*REQUEST*FLAGS'                      
                  FSRTIMM1='TIME WHEN*DATA MOVEMENT*STARTED'            
                  FSRTIMM2='TIME WHEN*DATA MOVEMENT*COMPLETED'          
                  FSRTIME1='TIME WHEN*HOST PROCESSNG*STARTED'           
                  FSRHOST ='HOST*IDENTIFIER'                            
               Those new timestamps for phases of HSM may be useful.    
               I chose to keep only the one-byte flag variable FSRFLG3, 
               to save DASD space, but these tests can be used for the  
               bit-level-field-names, some of which may be important:   
                 FSRFLG3='1.......'B  FSRFVINI  RECOVERY REQUEST        
                 FSRFLG3='.1......'B  FSRVXPL1  DS EXPIRED FROM ML1     
                 FSRFLG3='..1.....'B  FSRFXPL2  DS EXPIRED FROM ML2     
                 FSRFLG3='...1....'B  FSRFEXBV  BACKUP VER BEING EXPIRED
                 FSRFLG3='....1...'B  FSRFBKTP  BACKUP VER DELTD IS TAPE
                 FSRFLG3='.....1..'B  FSRFEXDT  DELETED BY EXPDT/MGTCL  
                 FSRFLG3='......1.'B  FSRRECON  MIGRATE DUE TO RECONNECT
   Thanks to Judith Bruner, Wal-Mart, USA.                              
Change 19.226  There was a missing end-of-comment */ in this member.    
Nov 15, 2001                                                            
   Thanks to Dan Riggs, Wachovia, USA.                                  
Change 19.225  Support for Landmark's The Monitor for TCP/IP v1.1 has   
EXTMTCIA       been tested with actual data for all subtypes!  These new
EXTMTCIC       datasets are created from the dumped TMON records:       
EXTMTCIE        dddddd     dataset   description                        
EXTMTCPA        TMTCIO     TMTCIO    TMON TCP/IP IO CISCO               
TYPSTMTC       Invalid packed dates in IASDAT, IZSDAT, and ILSDAT have  
VMACTMTC       '101271F0'x instead of '0101271F', causing missing values
VMXGINIT       values, and IZFTPTY is sometimes shifted right, but there
Nov 16, 2001   is lots of new data here, especially from SNMP v1/v2 MIB.
   Thanks to Julie Haines, Direct Line, ENGLAND.                        
   Thanks to Pete Gain, SAS Software PTY, ENGLAND.                      
Change 19.224  Support for CICS/TS 2.2 Statistics Record was enhanced   
EXCICDSP       with new datasets CICDSPOO, CICS Dispatcher TCB Pools to 
IMACCICS       record the number of TCBs attached, allocated, etc., for 
VMAC110        the Open, JVM and HP TCB pools.  Now understanding that  
VMXGCICI       CICS TCB number is no longer valid to identify what is in
VMXGINIT       which TCB, the text of Change 19.204 and ADOC110 were    
Nov 13, 2001   revised to show that the TCB "Name", rather than number  
Nov 19, 2001   determines what is stored in the dsNxxxxx set of CICS TCB
               variables: trust the variable's Label, not its number!   
              -The VMXGCICI member was updated to bring in the twelfth  
               and thirteenth TCBS                                      
              -New (and undocumented) "D2" TCB is now recognized.       
               The STID=114 EJR and STID=66 STG segments have new fields
               added to their existing datasets.                        
Change 19.223  Invoking _N108 to null out all TYPE108x datasets failed  
VMAC108        because the MACRO _N108 statements were wrong - each was 
Nov 12, 2001   of the subsequent lines were missing the word "MACRO".   
   Thanks to Martin Lee, Safeway Stores PLC, ENGLAND.                   
Nov 14, 2001   are no observations in DB2ACCTP, but observations were in
Nov 22, 2001   both DB2ACCT and ASUMDB2A, causing USEACCT to be blank,  
Nov 26, 2001   causing SKIPPAK to be wrong, which caused the incorrect  
               open.  The logic to set USEACCT and SKIPPAK and the code 
               that uses then was corrected and made consistent for both
               PMACCT01 and PMACCT03 reports.                           
              -%ANALDB2R failed when PMACC01 and PMACC03 were requested,
               with ERROR: FILE WORK.ASUMDB2A.DATA DOES NOT EXIST,      
               because the OPTIONS NODSNFERR NOVNFERR statement was not 
               executed the second time (after the PMACC01 report was   
               created, it reset those options to DSNFERR and VNFERR).  
               Adding the OPTIONS statement inside %MACRO PMACC01 fixed 
               that error, but uncovered an extra END; statement in the 
               PMACC03 report, that had to be conditionally generated.  
              -With PDB=SMF and both PMACC01 and PMACC03 requested, no  
               package detail was printed, but UNINITIALIZED VARIABLE   
               log messages were, because the VMXGSUM output of PMACC01 
               was written to OUTDATA=DB2ACCTP, but that overwrote the  
               original DB2ACCTP data, and then that summary was used as
               the input to PMACC03.  Using a different dataset name in 
               the OUTDATA= statement (and in subsequent references) was
               required for both DB2ACCTP and DB2ACCTB, and now they are
               OUTDATA=OUTACCTP and OUTDATA=OUTACCTB.                   
              -A conditional execution of a PUT statement was inserted  
               in the Package Detail.                                   
              -Statements were indented to make the logic more obvious. 
              -Nov 26: Eliminated UNINITIALIZED DATETIME varialbe notes,
               two CPUTIME headings became one ELAPSED and one CPUTIME, 
               and when there's more than a page of package detail, the 
               headings on package section now propagate to the first   
               heading lines on the second and following pages.         
   Thanks to Simone Niemczura, Harleysville Insurance Companies, USA.   
   Thanks to Andrew Taylor, AXA Shared Servicess Limited, ENGLAND.      
Change 19.221  Enhanced support for NPM subtype 18/19x (Exception and   
EX028EX1       Resolution events) are now output in eight new datasets  
EX028EX2       based on NPMTYPE (LSCDRTYP) value, with detail sets of   
EX028EX3       variables from each Volume/AOFTYPE segment.  This will   
EX028EX4       cause zero observations in datasets NPMEVNET & NPMERNET, 
EX028EX5       which are replaced by the new datasets:                  
EX028EX6        NPMTYPE  Exit  Dataset   Event Description              
EX028EX7        24x      EX1   NPMEXXPU  X.25 (NPSI/XI/3746) PU         
EX028EX8        26x      EX2   NPMEXXVC  X.25 (NPSI/3746) VC            
VMAC28          27x,47x  EX3   NPMEXNEO  Generic NEO link/PU            
VMXGINIT        28x,4Cx  EX4   NPMEXCSL  ODLC LAN                       
Nov 12, 2001    2Ax,2Bx  EX5   NPMEXFRP  Frame Relay                    
                49x,4Ax   "       "                                     
                44x,45x  EX6   NPMEXTRI  NTRI logical/physical link     
                46x      EX7   NPMEXXLK  X.25 (NPSI/XI/3746) link       
                4Bxc     EX8   NPMEXETH  Ethernet LAN physical link     
               These Event/Resolution records were not reported as being
               a problem, but in validating NPM 2.6 records, INVALID    
               DATA FOR MDY FUNCTION with NPMTYPE=28x exposed the need  
               to create a separate dataset for each of these events.   
              -Variable BASTIME now existsin NPMSUBTY 51x & 62x records,
               so the test for NPMSUBTY added by Change 7.237 (!) is now
               removed; only BASNCPDT and BASNCPTM GT 0 are now tested. 
              -Labels for CONTENT*FLAG variables were made consistent   
               and all are now formatted $HEX2.                         
              -All Byte-Measurement variables are now formatted MGBYTES 
               so that their values will be printted with K/M/G suffix. 
              -Four variables previously in Kilo-Bytes are now converted
               to contain bytes, and formatted with MGBYTES:            
                  LLBVP1BB LLBVP1NB LLBVP2BB LLBVP2NB                   
              -FORMAT statements were sorted and reorganized.           
   Thanks to William Sherriff, IBM Global Services, USA.                
Change 19.220  SMF type 42 subtype 6 INVALID DATA FOR READTIME message  
VMAC42         and hex dump were caused by blanks for both JOB name and 
Nov  9, 2001   for READTIME, in a record from (old) DFSMS/MVS 3.1 for a 
               started task that may have been cancelled/forced.  This  
               change supresses the message and hex dump by inserting   
               double-question-mark-modifier, but with or without this  
               change, READTIME is missing in the TYPE42DS dataset for  
               a record with blanks instead of a time and date.         
               The blanks could also have been caused by user SMF exits.
   Thanks to Jesse Gonzales, The Gap, USA.                              
Change 19.219  Documentation only.  Comments added to identify which of 
VMXGUOW        the "_K" macros are to be used for what.  There is a pair
Nov  9, 2001   of "_Kxxxxxx" macros that can be tailored to control what
               additional variables are kept from CICSTRAN, DB2ACCT, and
               MQACCT.  One is for numeric variables that are summed and
               kept in PDB.ASUMUOW from each input dataset:             
                  _KUOWCIC    CICSTRAN                                  
                  _KUOWDB2    DB2ACCT                                   
                  _KUOWMQC    MQACCT                                    
               and one is for character variables that are added to the 
               ID statement and are kept in PDB.ASUMUOW:                
                  _KUOWIDC    CICSTRAN                                  
                  _KUOWIDD    DB2ACCT                                   
                  _KUOWIDM    MQACCT                                    
   Thanks to Kenneth Johnsonk, Vanguard, USA.                           
======Changes thru 19.218 were in MXG 19.07 dated Nov  3, 2001======    
Change 19.218  Revision to RMF III ASMRMFV program, additional revisions
ADOCRMFV       to VMACRMFV will follow.  Extensive documentation of the 
ASMRMFV        changes in ADOCRMFV.                                     
Nov  3, 2001                                                            
   Thanks to Jerry Urbaniak, Acxiom CDC, USA.                           
Change 19.217  CPUTYPE='2064'x with Spare CPUs still made PDB.ASUM70PR  
VMAC7072       have bad values for LPnDUR and LPnPERCENTAGES.  The real 
Nov  3, 2001    source of the problem was that the TYPE70PR dataset had 
               an observation for each spare CPU, with non-zero DURATM, 
               and the LPARDUR included the DURATION of all the spares. 
               I considered deleting the spares in the ASUM70PR logic,  
               but believe many MXG users do their own sums of TYPE70PR,
               so it makes more sense to only output observations in the
               TYPE70PR dataset for 2064 CPUS for LPARNAME=PHYSICAL (as 
               it has SMF70ONT=0), or if SMF70CIN NE 'CP' (so ICFs and  
               anything else will be output) or if SMF70ONT NE 0 (so the
               2064s with the APAR will have non-zero ONT for non-spares
               and 2064s without the ONT APAR will have missing ONT and 
               will also be output.                                     
               If you have LPnDED='Y' or LPnWAIT='Y' (Dedicated CPUs or 
               Wait-Complete), then the only PDB.ASUM70PR observations  
               that have non-missing values for those LPARs will be the 
               ASUM70PR observation written on the Dedicated LPAR, i.e.,
               those with SYSTEM=LPnNAME.  For Dedicated/Wait Complete  
               CPUs, the PDB.ASUMCEC dataset was invented to solve this 
               problem; read the extensive discussion in the text of the
               Change 17.203 that added the creation of PDB.ASUMCEC into
               the ASUM70PR logic, and see member ACHAP10 for general   
               PR/SM CPU measurement discussion.                        
                 OBSERVATION COUNT CHANGE: TYPE70PR fewer obs.          
   Thanks to Bruce Widlund, Merrill Consultants, USA.                   
   Thanks to Joseph Rannazzisi, Salomon Smith Barney, USA.              
   Thanks to Jim Gilbert, EDS-Sabre, USA.                               
Change 19.216  MXG ASCII Execution only: R723MSCF in TYPE72GO is wrong, 
VMAC7072       but not when MXG runs under MVS.  It was INPUT with the  
VMAC71         $EBCDIC format, but it is a character-variable-containing
VMAC73         hex-values, formatted with $HEX, and all such variables  
VMAC74         MUST be INPUT with $CHAR informat to preserve the bits   
VMAC75         and for MXG to be portable across platforms.             
VMAC76         Under MVS, $EBCDIC and $CHAR are identical, but on ASCII 
VMAC77         platforms, the INPUT must be with $CHAR to preserve the  
VMAC78         original bits; if you input with $EBCDIC under ASCII, as 
VMAC79         designed, SAS converts '40'x to '20'x for blanks, etc.,  
VMAC102        for each byte in the field.  Under ASCII, $CHAR stores   
TYPEDOS        the unmodified hex value in the character variable (and  
VMAC102        so does $VARYING).                                       
VMAC110        Don's discovery precipitated an audit of old MXG source  
VMAC116        for other cases of incorrect informat: all variables     
VMAC22         listed below are now correctly INPUT with $CHAR and      
VMAC42         formatted with $HEX; none are important flags, some are  
VMAC6          not even kept, many are reserved fields, but a few are   
VMAC6156       used to create other (apparently-not-very-important) flag
               variables, and since no one else had caught this failure 
               in MXG transparency across platforms, I feel very lucky! 
VMAC80A        I should have done this long ago.                        
VMAC90A         VMAC7072: R723MSCF TEMPIOML SMF70PRF SMF70PRF           
VMACACF2                  SMF72RV5 SMF70V                               
VMACACHE        VMAC71:   TEMPIOML SMF71PRF                             
VMACAPAF        VMAC73:   TEMPIOML SMF73PRF                             
VMACAPAF        VMAC74:   R747PNUM R747PADR R747CNUM R747CADR           
VMACCTLG        VMAC76:   TEMPIOML SMF76PRF                             
VMACDB2         VMAC77:   TEMPIOML SMF77PRF                             
VMACEREP        VMAC78:   TEMPIOML SMF78PRF                             
VMACIDMJ                  R79RSV   R79USER  R796FLG  R797FLG  R797RES   
VMACIDMS                  R798FL1  R799RVO  R799CNF  R799RV0  R799CNF   
VMACIMS                   R79BFL2  R79BRESV                             
VMACIMSA        TYPEDOS:  SUFFIX                                        
VMACMVCI        VMAC102:  QW0011PS QW0015C2 QW0021KD QW0021KP QW0021K1  
VMACOPC                   QW0021K2 QW0087AD QWP1SMRC QWP3WLST QWP4DATE  
VMACSNAP                  QWP4DATE QW0170FC QW0177CT                    
VMACSYNC                  TRANPRI TRANPRI TRANPRI TCLASS                
VMACTMV2        VMAC116:  WTIDUOWI WQCORREL                             
VMACTMVS        VMAC22:   CPUTYPE                                       
ZMACxxxx        VMAC42:   SMF42DEV                                      
Nov  1, 2001    VMAC6:    SMF6OTOK                                      
                VMAC6156: RELFLAG                                       
                VMAC7072: R723MSCF                                      
                VMAC79:   R79FRCVT                                      
                VMAC80A:  CLASOPT1                                      
                VMAC84:   SMF84FL1                                      
                VMAC90A:  SMF9031U                                      
                VMACACF2: ACVMFMF                                       
                VMACACHE: DEVMAP1 DEVMAP2 CSDEV DVID                    
                VMACAPAF: CPUMAP                                        
                VMACAPAF: IOPMAP                                        
                VMACBETA: BETAALVL                                      
                VMACCTLG: RELFLAG                                       
                VMACDB2:  QBGBGR1 QBGBGR2                               
                VMACERE:  SYRELLVL                                      
                VMACFTP:  DVGDRETC DVGDREAC                             
                VMACIDMJ: DBKOWNER DBKOWNER                             
                VMACIDMS: DBKOWNER DBKOWNER                             
                VMACIMS:  SYNCDMAP                                      
                VMACIMSA: SYNCDMAP                                      
                VMACMVCI: T6EUDATA                                      
                VMACOPC:  EXRPURGE                                      
                VMACSPMS: SPMSEXTB SPMSEXTE                             
                VMACSYNC: SYNSOIO SYNSOIO                               
                VMACTMV2: JDCLASS                                       
                          IVDEVNR JDCLASS                               
               Fortunately, except for R723MSCF in TYPE72GO cited above,
               none of these variables have been reported in error by   
               Note: most of these CHAR variables were assigned MXG's   
               $NOTRAN informat: that was to be used by SAS as a flag to
               "Not Translate" that variable between platforms, but that
               scheme will not be implemented, so whether hex-containing
               character variables have informat $NOTRAN or not has no  
               impact. Sep 2009: Find MXGNOTRA in CHANGESS for solution.
               I also eliminated many ZMACxxxx members that were old and
               no longer needed as penultimate backup for major changes.
   Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.  
Change 19.215  MXG 19.05 only. PDB.ASUM70PR and PDB.ASUMCEC variable    
VMXG70PR       SHIFT was usually wrong.  The _DURSET logic changes made 
Nov  2, 2001   by Change 19.201 were incorrect and were revised with the
               insertion of  DATETIME=STARTIME; before the first include
               statement for IMACSHFT, and that code block was copied to
               the second include statement for IMACSHFT.               
   Thanks to Bruce Widlund, Merrill Consultants, USA.                   
======Changes thru 19.214 were in MXG 19.06 dated Oct 30, 2001======    
Change 19.214  Support for NTSMF SMS Objects create five datasets:      
EXNTSMDI          dddddd   dataset   description                        
Oct 31, 2001                                                            
   Thanks to Jim Quigley, ConEd, USA.                                   
Change 19.213  "Support" for DB2 V7 QLES section was added to DB2STATS  
VMACDB2        dataset (from 100 subtype 1) record, even though none of 
Oct 31, 2001   the QLES fields are described in the DSNDQLES DSECT; they
               are all flagged with (S) - Serviceability.  Additionally,
               the 8-byte QLETIMEx "time" fields, are actually two four 
               byte fields, which I have assumed to be like CICS "time" 
               values, with a 4-byte time value and a 4-byte count when 
               the time value was updated.  While all of the other four 
               byte counters are accumulated, five of the "time" fields 
               are not accumulated: QLETIMEW,QLECNTM,QLETIMEI,QLECNTDY, 
               and QLECNTW.  (The pair of time and count variables are  
               named QLETIMEx and QLECNTx, labelled "QLETIMEx*TIME" and 
               "QLEXTIMEx*COUNT".  The QLExxxxx variables are discussed 
               in IBM documentation concerning the use of DSNTIP7 and   
               Section 2 of the DB2 Installation Guide, specifically to 
               measure and set the MAXIMUM LE TOKENS (LEMAX) on that DB2
               panel to ensure that there are enough, and not too many, 
               LE tokens.  Whether I've guessed correctly on the order  
               of time-count, and whether my assumed time units of secs 
               are valid, will hopefully confirmed or corrected, when   
               either IBM provides additional documentation, or when you
               users can prove or disprove the numbers!  Why only five  
               counters are not accumulated, especially since they are  
               really in pairs, suggests possible alignment errors, but 
               even then, I would expect four or six, not five.         
   Thanks to Harry Price, Florida Light and Power, USA.                 
   Thanks to Ed Gambon, Florida Light and Power, USA.                   
Change 19.212  MXG 19.05 ONLY, CPUTYPE not 2064, LPARCPUS count is wrong
VMAC7072       in TYPE70PR and in ASUM70PR, because the test added by   
Oct 30, 2001   Change 19.189 to support APAR OW49536 only was valid if  
               the CPUTYPE='2064'x.  The revised change now counts CPUS:
                  IF SMF70CIN NE 'ICF'  AND  ( (SMF70ONT NE 0) OR       
                     (SMF70ONT EQ 0 AND CPUTYPE NE '2064'X) )           
                     THEN LPARCPUS=LPARCPUS+1;                          
               and thus is CPU-Type dependent until IBM externalizes the
               DDBOnlin flag into the RMF type 70 record as a safer test
               field in the future.                                     
   Thanks to Peter Krijger, National Bank of New Zealand, NEW ZEALAND.  
   Thanks to Alan Sherkow, I/S Management Strategies, USA.              
Change 19.211  Support for Tivoli/Netview NPM 2.6 COMPATIBLY added one  
EX028INN       new subtype, 17x, for new NPMINNRC dataset containing    
VMAC28         Router CISCO CIP Interval Volume Data (i.e., records are 
VMXGINIT       written only for the routers that have installed CISCO   
Oct 30, 2001   CIP card).                                               
Oct 31, 2001                                                            
Change 19.210  NOT SORTED TYPE72GO error in WEEKBLDT caused by Change   
WEEKBLDT       17.353 that added variable RPRTCLAS to the BY list in    
Oct 30, 2001   This worked fine for two years, but a SET CLOCK event at 
               two sites exposed the MXG inconsistency that caused the  
               error.  Correcting the BY list eliminated the error.     
   Thanks to Art Hunter, Penn Mutual, USA.                              
   Thanks to Richard Lopez, Johnson and Johnson, USA.                   
Change 19.209  RMF III job monitor total storage is created in new      
Oct 28, 2001   in ZRBASI dataset.                                       
   Thanks to Mark Wittie, FMR, USA.                                     
Change 19.208  First 19.05 only.  SYSTEM object has missing counters if 
VMACNTSM       NRDATA=24; first IF test was revised.                    
Oct 24, 2001                                                            
   Thanks to Jim Quigley, ConED, USA.                                   
======Changes thru 19.207 were in MXG 19.05 dated Oct 24, 2001======    
Change 19.207  Some sample MQ Series Exception reports based on SMF 115 
ANAL115        records (TYPS115).                                       
Oct 24, 2001                                                            
   Thanks to Bruce Widlund, Merrill Consultants, USA.                   
   Thanks to Yakov Nudel, Beta Systems, USA.                            
   Thanks to Jan Hess, America West, USA.                               
Change 19.206  Unexpected blank 80-byte record at start of compressed   
VMACTMO2       Landmark file caused INPUT STATEMENT EXCEEDED error. This
Oct 24, 2001   change detects short records, lists them on the SAS log, 
               and deletes them.  These records are probably being added
               as part of the site's tape initialization process, rather
               than being created by Landmark.                          
   Thanks to Tim Sisk, CSC Corp, USA                                    
Change 19.205  Using ASUMCICS with Landmark TYPSTMO2 member failed, due 
ASUMCICS       to the incorrect include of member IMACMONI instead of   
Oct 23, 2001   VMACTMO2 (so _LMONTSK was not defined).                  
   Thanks to Robin Murray, Maritime Life, CANADA                        
Change 19.204  Support for CICS/TS 2.2 Statistics changes to CICDS data.
VMAC110        IBM has changed the 9th and 11th TCB buckets contents and
Oct 23, 2001   added a twelfth bucket:                                  
Nov 12, 2001      MXG Prefix    TCB Number  TCB Name  2.1 TCB   2.2 TCB 
                    DSG            1         QR        1         1      
                    DS2            2         RO        2         2      
                    DS3            3         CO        3         3      
                    DS4            4         SZ        4         4      
                    DS5            5         RP        5         5      
                    DS6            6         FO        6         6      
                    DS7            7         SL        7         7      
                    DS8            8         SO        8         8      
                    DS9            9         J8        9     H8 12      
                    DSA           10         L8       10        11      
                    DSB           11         S8       11         9      
                    DSC           12         D2       --     D2 10      
               MXG variable DSnTCBNM, where n is the TCB number, will   
               contain the actual name of the TCB so you can verify     
               which set of TCB values applies to which TCB; because of 
               the IBM change, the LABEL values for DS9,DSA,DSB, and DSC
               variables may be incorrect, but DSnTCBNM will be valid.  
               There are additional DSG Pool segments that are not yet  
               decoded, as I need actual data to validate their location
               in the SMF record to write that code.                    
Change 19.203  Support for z/OS Version 1.1 and 1.2 APAR and MXG error. 
VMAC78         APAR OW49806, for z900 with z/OS 1.2, adds new IOP       
Oct 23, 2001   (I/O Processor) utilization measurements have been added 
               TYPE78IO dataset:                                        
                  R783IIPB='TIMES WHEN*IOP*WAS BUSY'                    
                  R783IIPI='TIMES WHEN*IOP*WAS IDLE'                    
                  R783IIFS='IO FUNCTIONS*INITIALLY*STARTED'             
                  R783ICPB='RETRIES*DUE TO*CHANNEL*PATH*BUSY'           
                  R783IDPB='RETRIES*DUE TO*DIRECTOR*PORT*BUSY'          
                  R783ICUB='RETRIES*DUE TO*CONTROL*UNIT*BUSY'           
                  R783IDVB='RETRIES*DUE TO*DEVICE*BUSY'                 
               But in installing this support, I found the new variables
               for DCM managed channels, added by Change 18.134 for 1.1 
               (R783MCMN/MX/DF/PTM/DBPM/CUBM added to dataset TYPE78IO),
               should have instead been added to dataset TYPE78CU, so   
               this change is required for z/OS 1.1 and 1.2 on all      
               platforms, not just z900s.                               
               14May02: Documented in comments in VMAC78, but not here, 
               z/OS 1.2 R783GSAM/NRCMPTSM  and R783PB/PCTPTHBY are now  
               reserved, causing PCTPTHBY to be missing in TYPE78CF.    
               16Jun02: This also causes PCTALLBY to be missing in      
               TYPE78CU,  beginning with Z/OS 1.2.                      
Change 19.202  Support for Serena's Ultimizer user SMF record.          
EXULTM01       Four datasets are created:                               
TYPEULTM       This vendor puts the RDRDATE where the SYSTEM should be  
TYPSULTM       in the SMF header.  The subtypes 4 thru 10 are all output
VMACULTM       in the ULTMIZnn dataset, which appears to also have      
VMXGINIT       duplicate records created for some subtypes.             
Oct 20, 2001                                                            
Change 19.201  Several enhancements to PDB.RMFINTRV and PDB.ASUM70PR:   
VMXG70PR       PDB.RMFINTRV by your include of ASUM70PR after BUILDPDB  
VMXGRMFI       that updates PDB.RMFINTRV after PDB.ASUM70PR is built.   
Oct 22, 2001  -The SYNC59 logic in VMXGRMFI was revised; it could be    
               off by one minute in creating PDB.RMFINTRV.              
              -The 70ID list was cleaned up and now is in one place.    
              -If you used the (recently added) INTERVAL= and SYNC59=   
               arguments in your RMFINTRV member to control %VMXGRMFI's 
               summary interval, variables PLATBUSY and PLATCPUS could  
               be missing, because the ASUM70PR program that adds them  
               into PDB.RMFINTRV uses the _DURSET macro in IMACRMFI to  
               set the ASUM70PR interval, causing the mis-match.  This  
               exposure is fixed by new member VMXG70PR, a new %MACRO   
               definition, that is now invoked by member ASUM70PR, with 
               the same arguments as VMXGRMFI, so that if you do tailor 
               RMFINTRV with INTERVAL= and/or SYNC9=, you now can (and  
               now MUST!) use the same arguments and values in both your
               RMFINTRV and ASUM70PR members, so that the intervals in  
               RMFINTRV, ASUM70PR, and ASUMCEC are identical.           
               -The default value in both RMFINTRV and ASUM70PR are set 
                to INTERVAL=DURSET and SYNC59=NO, so that the default   
                interval in PDB.RMFINTRV and PDB.ASUM70PR is set by the 
                member IMACRMFI (in it's _DURSET macro definition).     
                 By default, IMACRMFI member does no summarization, and 
                 instead creates one observation in PDB.RMFINTRV and    
                 PDB.ASUM70PR for each original RMF interval.           
               -If you have tailored member IMACRMFI to set the summary 
                interval (eg, HOUR, SHIFT, etc) you want, then it will  
                be used for both RMFINTRV and ASUM70PR.                 
               -If instead you tailored member RMFINTRV to use INTERVAL=
                or SYNC59= arguments, then you MUST also tailor member  
                ASUM70PR to use those same arguments and values.        
              -With the added variables, the maximum percent CPU busy   
               that a system can reach based on LPAR weights can be     
                E.g.: CEC with 11 physical engines and with 3 LPARS:    
                      6 engines and weights of 47 in two LPARS          
                      2 engines and weight  of  6 in one LPAR           
                      LPARMAX = 100 * (47/100) * (11/6) = 86.6 %        
                      is the busyiest those six engine LPARs can be,    
                      even though PLATBUSY is 100%                      
              -Correction in ASUM70PR for Dedicated processors to change
                IF LCPUDED='Y' AND LCPUWAIT='Y' THEN DO;  to now read   
                IF LCPUDED='Y' OR  LCPUWAIT='Y' THEN DO;                
               because the logic only worked for Dedicated and LCPUWAIT,
               which could cause the non-dedicated CPU busy to be wrong.
   Thanks to Chuck Hopf, MBNA, USA.                                     
   Thanks to Steve Emson, TESCO, ENGLAND.                               
   Thanks to Richard Rich, State of California Teale Data Center, USA.  
Change 19.200  Support for SMF type 82 crypto facility record           
EXTY8201       creates thirteen new datasets:                           
EXTY8203         TY8201    TYPE8201  INITIALIZATION                     
EXTY8204         TY8203    TYPE8203  STATUS CHANGE                      
EXTY8205         TY8204    TYPE8204  CONDITION CODE 3                   
EXTY8206         TY8205    TYPE8205  SPECIAL SECURITY MODE              
EXTY8207         TY8206    TYPE8206  MASTER KEY PART                    
EXTY8208         TY8207    TYPE8207  KEUK PART                          
EXTY8209         TY8208    TYPE8208  CKDS REFRESH                       
EXTY8210         TY8209    TYPE8209  CKDS UPDATE                        
EXTY8211         TY8210    TYPE8210  PKA KEY PART                       
EXTY8212         TY8211    TYPE8211  CLEAR NEW MASTER KEY PART          
EXTY8213         TY8212    TYPE8212  PUBLIC KEY SECURE CABLE            
VMAC82           TY8213    TYPE8213  PUBLIC KDS UPDATE                  
Oct 19, 2001                                                            
Change 19.199  Incorrect copying in the weekly phase was corrected by   
BLDNTPDB       inserting a RUN; statement between the PROC COPY and the 
Oct 19, 2001   %VMXGOPTR invocation (to force macro resolution).        
   Thanks to Greg Jackson, National Life of Vermont, USA                
Change 19.198  Invalid values for sample counts of 'FFFFFFFF'x for the  
VMAC7072       PCTDLTOT (R723TOT) and PCTDLQ (R723CQ) and 'FFFFFFFA'x   
Oct 19, 2001   for PCTDLTDQ (R723CTDQ) caused very small VELOCITY and   
               very large PERFINDX values.  MXG now tests those three   
               fields and forces a missing value when large values are  
               found in the IBM record.                                 
               Updated: Oct 30, 2001: IBM APAR OW50380 fixes the error, 
               at least for basic mode.                                 
   Thanks to Jiann-Shiun Huang, CIGNA, USA                              
   Thanks to Perry Metzel, Hewitt, USA.                                 
Change 19.197 -Support for revised SYSTEM object with NRDATA=24, which  
EXNTEPXY       reinstated Total Interrupts/Sec counter to match all of  
EXNTEXEX       the SYSTEM fields that used to exist in NT 4.0.          
EXNTMEAL      -Support for the restructured SQL 2000 objects creates    
EXNTMECA       these seventeen new SQLServer datasets:                  
EXNTMESA         NTQLLA    MSQLATCH  NT MSSQL:LATCHES                   
EXNTMESR         NTQLLO    MSQLOCKS  NT MSSQL:LOCKS                     
EXNTQLAM      -Support for 14 new MS Exchange objects create datasets:  
EXNTQLBD         NTMEAL    MSEXMEAL  NT MSEXCHANGEAL                    
EXNTQLDA         NTMEM     MEMORY    NT MEMORY                          
EXNTQLLO         NTMEPO    MSEXPOP3  NT MSEXCHANGEPOP3                  
EXNTQLRD         NTMESR    MSEXSRS   NT MSEXCHANGESRS                   
EXNTQLSE       The duplicate removal logic was validated and BY lists   
EXNTQLSS       were enhanced where needed to ensure removal.  There are 
IMACNTSM       actual duplicates in MSEXCONT that are being investiaged.
NTINTRV       -In NTINTRV, the NTCONFIG dataset is no longer combined in
VMACNTSM       to PDB.NTINTRV because is is not an interval dataset.    
VMXGINIT      -SP2 for Exchange 2000 added object MSExchangeIS Mailbox  
Oct 19, 2001   that appears to have the same fields as MS..eIS Public,  
               so the Mailbox records are output in MSEXISPU dataset.   
               Object for MSExchangeIS was restructured with some new   
               and some removed fields. The "Database ==> Instances"    
               object is questionable, and missing fields in Database   
               object have yet to be resolved, but both objects with    
               "Database" in their name are now output into DATABASE.   
              -New Epoxy object creates new EPOXY dataset.              
              -New MicroSoft Gatherer object creates new MIGATHER       
              -New  " Gatherer Projects object creates new MIGATHPR     
              -New Microsoft Search object creates new MISEARCH         
              -New  " Search Catalogs object creates new MISEARSC       
              -New  " Search Indexer Catalogs creates new MISEARSI      
              -New Exchange Server HTTP Extensions new EXCHHTEX         
Change 19.196  Variable QBGBGCS, the current status of GBPCACHE (NO/YES)
VMACDB2        was added by DB2 Release 6, but was skipped by MXG; now  
Oct 17, 2001   that variable is INPUT and kept in dataset DB2GBPAT.     
   Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.  
Change 19.195  Cosmetic.  Some of the error messages for bad segments   
VMAC108        had incorrect segment name in the text, possibly causing 
Oct 17, 2001   confusion, if any of those conditions ever occurred.     
   Thanks to Bob Furlong, Chase, USA.                                   
Change 19.194  Change 19.101 removed PGMRNAME from the TYPE30_4 step    
BUILD005       dataset in BUILDPDB processing to protect against blank  
BUIL3005       values, but that change caused PGMRNAME to not be kept   
Oct 17, 2001   in PDB.STEPS; by adding PGMRNAME to the PDBADD2/PDBADD3  
Apr  5, 2002   macros, the PGRMNAME from the PDB.JOBS dataset will now  
               be copied into the PDB.STEPS dataset.  However, PGMRNAME 
               will still be blank if no PGMRNAME was used on the JOB   
               card: PDB.JOBS and PDB.STEPS contains observations for   
               all "jobs": STCs, TSO, OMVS, USS, APPC, etc, all will    
               create "job" records that can have no PGMRNAME value,    
               so variable TYPETASK may explain blank PGMRNAME values.  
               Since BUILDPDB keeps PGMRNAME from only the 30.1 Job Init
               and 26 Job Purge, if "Spinning" was not enabled in your  
               IMACSPIN, and if only step/job/print without init/purge  
               are found for a job, then variable INBITS won't contain  
               an I or a P, and PGMRNAME will be blank in JOBS/STEPS.   
               5Apr02: Text revised: why it can still be blank.         
   Thanks to Bob Greer, Nissan North America, USA.                      
Change 19.193  Support for IFCID=225, DB2 Storage Manager Pool Summary  
VMAC102        Statistics to create dataset T102S225, with lots of stats
Oct 17, 2001   on pool sizes and concurrent activity.                   
   Thanks to Sim Williams, Fidelity, USA.                               
Change 19.192  New formatted variable S42DSBUF for VSAM Buffer type:    
FORMATS           S42DSBUF='VSAM*BUFFER*TYPE'                           
VMAC42              with values 0:NSR 1:RLS 2:LSR 3:GSR                 
Oct 16, 2001   and new character flag variables ('Y' or blank) are added
                  S42DSEXC='OPEN FOR*EXCP*PROCESSING?'                  
                  S42DSPL ='PROGRAM*LIBRARY?'                           
                  S42DSEF ='EXTENDED*FORMAT?'                           
               to TYPE42DS by decoding the existing S42DSFL1 variable.  
               These new variables were used to examine why the S42AMxxx
               Access Method Statistics variables are sometimes missing 
               in TYPE42DS.  Thus far, all observations with            
                  S42DSEXC='Y'  - EXCP Access Method                    
               do not contain an Access Method Statistics section, but  
               no other pattern has been found to explain why that A.M. 
               segment is not present (S42DSAMO=0) for other datasets.  
   Thanks to Rob D'Andrea, NatWest, ENGLAND.                            
Change 19.191  Variable CPUTYPE was added to the KEEP= list for TYPE70PR
VMAC7072       dataset.                                                 
Oct 15, 2001                                                            
   Thanks to Helmut Roese, COM Software GmbH, GERMANY.                  
Change 19.190  This example report to calculate per-service-class CPU   
ANALSRVC       busy percentages had a FORMAT PGPCTCAP PGPCTUSE 5.1; that
Oct  7, 2001   should have been       FORMAT SVPCTCAP SVPCTUSE 5.1;  .  
   Thanks to Sudie Wulfert-Schickedanz, Anheuser-Busch, USA.            
======Changes thru 19.189 were in MXG 19.04 dated Oct  5, 2001======    
Change 19.189  Support for APAR OW49536 (INCOMPAT if you have SPARE CPU 
VMAC7072       engines on your 2064 CPU).  Reserve/Spare CPUs on 2064s  
Oct  5, 2001   have segments in type 70 records that were being counted 
               as a real CP engine (both in RMF reports and in MXG!).   
               This change tests SMF70ONT, the new LPAR "online time";  
               only if that value is non-zero will that CP be counted.  
               A missing value in SMF70ONT will be counted; that is a   
               record without the new field that can't have the problem.
               A non-zero non-missing value in SMF70ONT will be counted,
               because it was online during the interval.               
               Variable LPARCPUS in dataset TYPE70PR, and the LPnNRPRC  
               variables for each LPAR in dataset ASUM70PR will be wrong
               and LPAR percentages based on these variables will also  
               be incorrect without this change.                        
   Thanks to Al Sherkow, I/S Management Strategies Ltd, USA.            
Change 19.188  TYPEIMSA corrected ENDTIME and STRTTIME for GMTOFFTM, but
TYPEIMSA       variable END7TIME was not corrected, so these variables  
Oct  5, 2001   IMSSRVTM IMSRESTM IMSSRVTS and IMSRESTS were off from TOD
               by the value of GMTOFFTM.  All are now corrected.        
   Thanks to Daniel Cannon, The Hartford, USA.                          
Change 19.187  Enhancements for MXG NTSMF support:                      
ASUMNTIN      -NTCONFG file has been added in NTINTRV so KEEPALL=YES can
BLDNTPDB       be used in ASUMNTIN.                                     
NTINTRV       -ASUMNTIN now uses KEEPALL=YES for performance reasons.   
              -RUNMNTH processing in BLDNTPDB corrects problem passing  
Oct  5, 2001   a variable that should not have been.                    
               Stay tuned: more enhancements, like RERUN, in progress.  
Change 19.186  Support for RMF type 74 subtype 4 "Broken Records" output
VMAC74         observations from the subsequent, incomplete record when 
Oct  2, 2001   that record should have been deleted, as it was precedeed
               by the MXG "Broken Record" message from the previous SMF 
               record.  This change only outputs to TYPE74CF when the   
               is greater than zero.                                    
               For First 19.04:  This change relocate the RO section,   
               inserted the missing END; and corrected the comment that 
               has masked the missing END;                              
   Thanks to Wally Danielson, Airborne, USA.                            
Change 19.185  Support for Implex USER SMF record creates five datasets 
EXMPLXGA       one per subtype, from Williams Data Systems:             
EXMPLXIN         Subtype   DDDDDD    Dataset                            
EXMPLXPE           1       MPLXIN    IMPLEXIN   Interface Statistics    
EXMPLXPM           2       MPLXSE    IMPLEXSE   Service Statistics      
EXMPLXPO           3       MPLXGA    IMPLEXGA   Gateway Statistics      
EXMPLXRT           4       MPLXRT    IMPLEXRT   RTT Statistics          
EXMPLXSE           5       MPLXPR    IMPLEXPR   Protocol Monitoring     
FORMATS        These records contains accumulated fields, so the member 
IMACMPLX       both TYPEMPLX and TYPSMPLX invoke the _SMPLX "sort MPLX" 
TYPEMPLX       macro, which sorts and deaccumulates these datasets into 
TYPSMPLX       the default DDname of PDB. Implex is an IP monitor with  
VMACMPLX       3270 response time monitoring.                           
Oct  5, 2001                                                            
   Thanks to Rolf Meinert, Volkswagen, GERMANY.                         
Change 19.184  MXG Data Sets contain labels with unique syntax DDDDDD:, 
BLDNTPDB       that is used via PROC CONTENTS to control copying of the 
Oct  2, 2001   daily/weekly/monthly in the BLDNTPDB logic.  However, the
               DATA WEEK.NTxxxxx; SET MON.NTxxxxx ...  SUN.NTxxxxx; does
               not propagate a dataset LABEL, causing RUNMNTH=YES to    
               fail with ERROR: BY VARIABLE _B IS NOT ON INPUT DATASET  
               (because the DDDDDD value is used to create &SUFX, but if
               there is no DDDDDD value in the label, &SUFX is blank).  
               The circumvention is to use the PDB, instead of the WEEK.
               as the library to read to get the DDDDDD values.  Change 
               %VMXGINV(LIBNAME=WEEK);  to %VMXGINV(LIBNAME=PDB) after  
               the comment "BUILD THE MONTHLY" to circumvent.           
   Thanks to Liz Slack, Premera Blue Cross, USA.                        
======Changes thru 19.183 were in MXG 19.04 dated Oct  1, 2001======    
Change 19.183  Variable R742PIOT in dataset TYPE74PA was always missing.
VMAC74         The test  IF SKIP GT 4 THEN DO; prior to its INPUT should
Oct  1, 2001   have been IF SKIP GE 4 THEN DO;                          
   Thanks to Philip Foster, CGI Inc, CANADA.                            
Change 19.182  A new alternative report member for GRAFWORK, enhanced to
GRAFWRKM       support all workload that are now createable in RMFINTRV,
GRAFWRKX       with an additional neat twist.  With GRAFWORK, workloads 
Oct  1, 2001   are stacked from bottom to top and the order was fixed:  
               Overhead, CICS, IMS, TSO, BATCH, OTHER OTH1-OTH9.        
               But now with GRAFWRKS, if IMACWORK=NO is used, there is  
               total control of the order of stacking (except that the  
               "overhead", or uncaptured, is always at the bottom, so   
               you can order the stacking to map the priorities of your 
               workloads.  GRAFWRKM is an example using GRAFWRKX.       
   Thanks to Chuck Hopf, MBNA, USA.                                     
Change 19.181  Support for CICS/TS 2.2 SMF 110 Subtype 1 CICSTRAN record
VMAC110        is almost compatible!  IBM added two new variables at the
Sep 29, 2001   end of the standard transaction segment:                 
                 PTPWAITM='3270 BRIDGE*PARTNER*WAIT*ELAPSED*TIME'       
                 PTPWAICN='3270 BRIDGE*PARTNER*WAIT*COUNT'              
               so that all of the standard IBM fields are still correct 
               with earlier versions of MXG that supported TS 2.1 data. 
               However, if you are processing any of the optional CICS  
               segments, this change is required so that the optional   
               variables are valid:  (you ARE processing optional CICS  
               segments if there are IMACICxx members in your tailoring 
               MXG library).                                            
               This change supports only the subtype 1 record.  A later 
               change will support the CICS TS 2.2 Statistics subtype 2 
               record changes (INCOMPAT: CICDS data moved to STID=60).  
Change 19.180  Support for SMF 120 WAS/390 4.0 EE (Websphere Application
EXT120JI       Server, Enterprise Edition) which adds new Server Type:  
EXT120JC      -MOFW server supports both C++ and Java BOs (in 3.02)     
FORMATS       -J2EE server supports EJBs only (new in 4.0)              
VMAC120        The existing subtype 1 and 3 records for MOFW servers are
VMXGINIT       reused for the new J2EE server, so existing MXG datasets 
Sep 28, 2001   TYP102SA and TYP102SC from subtype 1 Server Activity and 
Oct 17, 2001   TYP102SI from subtype 3 Server Interval are changed only 
               by the addition of new variable SM120ST, Server Type, to 
               identify MOFW or J2EE server type.  Existing MOFW subtype
               2 and 4 could not be reused; new subtypes 5 and 6 create 
               MXG dataset TYP120JC (subtype 5 J2EE Container Activity) 
               and dataset TYP120JI (subtype 6 J2EE Container Interval).
              -These new records are the first SMF records to contain   
               UCS, or Unicode DBCS (Double Byte) character data in new 
               variables SM120JA8/SM120JB1/SM120JM1/SM120JA, with the   
               names of containers, ejbRoles, methods, and AMCNames of  
               the bean, etc.  However, SAS support for UCS (Informat   
               $UCS2Bnnn.) became available in SAS V8, so those new     
               UCS variables will have valid printable names only if    
               SAS Version 8 or later is used to build the datasets.    
               Although those names can be as large as either 256 or 512
               characters (512 or 1024 bytes of DBCS data in the record)
               until there is a need for more text, and for simplicity  
               and compatibility, only the first 200 characters are     
               kept, creating a unique new MXG macro variable named     
               UCS2B4, with value:                                      
                  IF &SYSVER GE 8.2 THEN %LET UCS2B4= $UCS2B4 ;         
                  ELSE                   %LET UCS2B4= $EBCDIC2;         
               so that using  "&UCS2B4.00" syntax, SAS V8.2+ will INPUT 
               with $UCS2B400. while earlier INPUT is with $EBCDIC200.  
               Code was revised and validated with J2EE data, Oct 17.   
Change 19.179  RMF III LENGTH=0 cause INPUT STATEMENT EXCEEDED error,   
VMACRMFV       but a rerun does not fail, (but a rerun against the VSAM 
Sep 28, 2001   file to create the BSAM file will have different records 
               because RMF III VSAM continuously runs and wraps).  This 
               change tests and deletes LENGTH=0 records with a message 
               on the log to show how many records were found.          
   Thanks to John F. Gebert, Office Depo Inc, USA.                      
Change 19.178  DB2 variable QWHSLUCC is the character variable with the 
VMACDB2        Commit Count, but that should have been a numberic value.
VMACDB2H       Since I can't change the type from CHAR to NUM without a 
Sep 27, 2001   serious compatability issue, I have created QWHSLUCN as  
               a numeric variable with the Commmit Count.               
   Thanks to Chuck Hopf, MBNA, USA.                                     
Change 19.177  Support for IMS 6.1 Fast Path records (INCOMPAT).        
VMACIMS        Fast Path subcodes 01, 03, 36, 37, and 38 were all       
VMACIMSA       changed by IBM; fields were inserted in all records, and 
Sep 27, 2001   new variables are now created and kept.  Support was then
Oct 15, 2001   revised Oct 15 to correct VARIABLE STRTTIME NOT FOUND    
               errors introduced by the first change.                   
   Thanks to Pete Gain, SAS, ENGLAND.                                   
Change 19.176  Support for z/OS Version 1 Release 2 changes in SMF data:
EXTY7002      -TYPE30xx - bit 2 in field SMF30SFL (Storage/Paging) new  
EXTY74DU                  variable IEFUSIME='IEFUSI*CHANGED*MEMLIMIT?'  
FORMATS                   in TYPE30_4, TYPE30_V, TYPE30_5, TYPE30_6.    
IMAC7072                - new vars   MEMLIMIT='MEMLIMIT*VALUE'          
IMAC74                    and        SMF30MLS='SOURCE OF MEMLIMIT' which
VMAC30                               is decoded by new MG030ML format:  
VMAC7072                                1:MEMLIMIT SET BY SMF           
VMAC71                                  2:MEMLIMIT SET IN JCL           
VMAC73                                  3:MEMLIMIT BASED ON REGION=0    
VMAC74                                  4:MEMLIMIT SET BY IEFUSI        
VMAC78                    but SMF30MLS and MEMLIMIT are set missing (and
VMAC79                    not zero) if SMF30MLS has no bit set (i.e., if
VMAC90                    MEMLIMIT is not specified).                   
VMXGINIT      -TYPE70PR - Existing SMF70BDA is now divided by SMF70DSA  
Sep 25, 2001              to calculate Average number of LCPUs Active,  
                          as the variable was labelled, and existing    
                          SMF70ACS is now documented as 4 bytes (z/OS   
                          R1.1 doc had ACS 2 bytes with +2 after MAS; I 
                          assume this is an IBM doc correction).        
                          SMF70ACS is now divided by SMF70DSA.          
              -TYPE7002 - New Dataset for Cryptographic Coprocessor data
                          contains PCCI Cryptographic Hardware execution
                          times and counts for all operations and all   
                          RSA-key-generation operations.                
              -TYPE71   - New Swap Reason "In-Real Swap" is added in new
                          variables SWAPIR/EXTAUXIR/LOGAUXIR/LOGEXTIR/  
              -TYPE72GO - New variable R723CLSC, only in Reporting Class
                          observations, contains the name of the Service
                          Class that last contributed to this Reporting 
                          Class; blank if this obs is for Service Class.
                            Note: Previously Reporting Classes did not  
                                  have Periods, (only Service Classes   
                                  had periods), but now both can have   
                                  up to 8 periods.                      
                        - New variable R723HETR='Y' if this report class
                          period is "Heterogeneous":                    
                            If the report class contains transactions   
                            from a single service class, R723HETR='N'   
                            for a "Homogeneous" reporting class.        
                            Report classes now can combine transactions 
                            running in different service classes, and   
                            those "Heterogeneous" have R723HETR='Y'.    
                        - New variables R723CAMU/R723CAMD (CAM CRYPTO)  
                          and R723APU/R723APD (AP CRYPTO) contain TCB   
                          USING and TCB DELAY samples for Cryptographic 
                          Asynchronous Message Processor (CAM) and for  
                          Cryptographic Assist Processor (AP).          
                        - New R723FQD Feature Queue Delay Samples: a TCB
                          was found waiting on a processor feature queue
                          associated with a CPU, are also included in   
                          the delay samples in R723CCDE (MXG PCTDLCDE). 
                            Note: Feature Queue Using Samples are in    
                                  MXG variable PCTUSCUS (R723CCUS).     
              -TYPE7204 - Type 72 subtype 4 delay samples have new var  
                          R724OR18 for new "In-Real" Swap Reason delays.
              -TYPE73   - New CPMF Channel Measurement Groups 3 adds new
                          channel traffic variables for HiperSockets, or
                          the IQDIO, a/k/a IQD (Internal Queued Direct  
                          Communication) channel type, a high-speed LAN 
                          for communications between LPARs in a CEC/CPC.
                          Eleven variables with byte rates per second,  
                          for both LPAR and Totals, for both data unit  
                          and message unit traffic, plus unsuccessful   
                          sends and receive counts, but there is no     
                          capacity measure for the IQD.  These new      
                          variables exist only for SMF73CMG=3:          
                            SMF73PDS SMF73PDU SMF73PMS SMF73PUB SMF73PUM
                            SMF73TDS SMF73TDU SMF73TMS SMF73TUB SMF73TUM
              -TYPE74CF - New variables added to TYPE74CF with bit masks
                          of paths available and installed and channel  
                          path type acronym for each of 8 possible paths
                          in variables                                  
                            R744FPAS R744FPIS R744FPCM R744FTA1-R744FTA8
              -TYPE74ST - New variables for waits, wait duration, and   
                          square of wait duration for waiting for peer  
                          subchannel, for waiting for peer with reserve 
                          held, and for waiting for peer completion in  
                          these new variables:                          
                           R744SCSS R744SCST R744SCTC R744SLSV R744SPES 
                           R744SPLN R744SPSS R744SPST R744SPTC R744SRSS 
                           R744SRST R744SRTC                            
              -TYPE74DU - New remote facility data section in subtype 4 
                          Coupling Facility data for your Duplexed CFs  
                          creates new dataset TYPE74DU.                 
              -TYPE746x - SKIP calculation corrected for 746BL/746DL.   
              -TYPE747x - While decoding of the subtype 7 FICON Director
                          is in place in VMAC74, no datasets are created
                          until I have test data to understand.         
              -TYPE78CF - IBM removed PCTPTHBY and NRCMPTSM fields, so  
                          they will now have missing values.            
              -TYPE791  - Variable R791TTOD now is non-zero and contains
                          "Real Time into Transaction".                 
                        - Added swap 'SR'='IN REAL' to FORMAT $MG079SR  
                        - New R791MLIM variable ASID Memory Limit added.
                        - Bits in R791FLG and R792FLG added for temporal
              -TYPE79C  - New CMG=3 data added                          
              -TYPE79E  - Variables CHPIDTKN and NRCMPTSM now reserved. 
              -TYPE90   - Support for subtypes 26,27,28,29,30,31,32.    
Change 19.175  Statistics reports for multiple intervals used the number
ANALDB2R       of intervals as a divisor, incorrectly, but only on one  
Sep 25, 2001   summary page, and only for the Long Statistics summary   
               and trace, PMSTA01/PMSTA03, which are not invoked by     
               default.  It's been this way for some time, suggesting   
               that a) that page of that report is not very useful, or  
               b) no user has looked at it that closely until now!      
   Thanks to Liesbeth Post, KLM, THE NETHERLANDS.                       
Change 19.174  Two separate sites report errors in SMF type 60 records, 
VMAC60         causing INPUT STATEMENT EXCEEDED RECORD error when read. 
Sep 21, 2001   Both had VVRTYPE=Z:PRIMARY, but the two SMF records are  
Oct  1, 2001   wrong in different ways:                                 
              -ENTTYPID=C:CLUSTER record, VVR has impossible value for  
               offset-to-next-field of 1792 in a 588 byte SMF record:   
                  VVRLOKYL=1792 (0700x located at byte 563) can't be    
                  valid, but the expected fields VVRXSC1 that I tried to
                  INPUT look like they are there after VVRLOKYL in the  
                  record.  Maybe first byte of VVRLOKYL is now a flag   
                  (note '.....11100000000'B value in this record)?      
                  CIRCUMVENTION: This change now compares VVRLOKYL with 
                  LENGTH to prevent INPUT, but when prevented, those    
                  additional fields will have missing or blank values.  
              -ENTTYPID='A:NON-VSAM', NVR has invalid values in length  
               and name fields for the Storage Class, Data Class, and   
               the Management Class names:                              
                 VVRSTGLN Length field = 6 , but 8 EBCDIC bytes follow  
                                             before the next length:    
                 VVRDATLN Length field = 4 , and 4 bytes do follow, but 
                                             only 3 are EBCDIC, final is
                                             '00'x instead of '40'x, and
                 VVRMGTLN Length field = 6 , but four unprintable hex   
                                             bytes are followed by four 
                                             EBCDIC bytes.              
               so the name field variables VVRSTGCL, VVRDATCL, VVRMGTCL 
               are trashed, as is the VVRSBKUP datetimestamp, whose byte
               location is now indeterminate with those invalid length  
               length fields.  My old DSECT ends with VVRSBKUP, but this
               record has nearly 200 bytes more data, with several new  
               TODSTAMP fields that should be new event variables, since
               type 60s are frequently used to investigate security     
               issues about who has access, and who accessed, and when  
               did they access sensitive data on DASD volumes.          
               Oct 1, 2001 update to this change text:                  
               I held this as the last change for 19.04, expecting IBM  
               would supply me with the VVR and NVR "DSECTS" so I could 
               see if something had been changed, and if so, how to     
               continue decoding the SMF type 60 records without error. 
               IBM's official reply to Merrill Consultant's request for 
               the DSECTS for the SMF type 60 record came from the IBM  
               DFSMS Vendor Activity manager:                           
                "I've discussed this matter with the developer and since
                 the VVR and NVR contains proprietary information, we   
                 cannot honour you request to acquire the DSECT for the 
                 VVR and NVR records in the VVDS.  Instead, please      
                 contact IBM Service and be prepared to FTP the dump and
                 the SMF records for analysis.  No promises are made as 
                 to how we'll choose to resolve this issue."            
                 Stay tuned for future updates to this bigger problem!  
                 Feb 14: IBM DFSMS refuses to provide documentation of  
                 either the Catalog or the VVDS records.  One of the    
                 above IBM errors was fixed by OW51353/OW50528 that     
                 reports creation of defective VVR; it's a shame that   
                 IBM would not let me have the documentation so I could 
                 have detected the bad record and told you the APAR that
                 you need to correct IBM's error, but I've given up.    
   Thanks to Lawrence Jermyn, Fidelity, USA.                            
   Thanks to Peter Krijer, National Bank of New Zealand, NEW ZEALAND.   
Change 19.173  Invalid SMF type 42 subtype 6 (TYPE42DS) record caused   
VMAC42         INPUT STATEMENT EXCEEDED error.  OFFDSAM segment started 
Sep 19, 2001   data byte 32697 but the record length of 32722 data bytes
               left only 26 bytes for the 48-byte Access Method segment.
               This change now protects for the short record, printing a
               message that bad records were found and missing values   
               were set for the S42AMxxx variables.                     
   Thanks to Linda Berkley, USPS, USA.                                  
Change 19.172  Moving your EBDCIC SPIN library from an existing BUILDPDB
SPINSORT       to run under ASCII versions of SAS will require a re-SORT
Sep 19, 2001   of the SPIN library after it has been XPORT/IMPORTed to  
               ASCII, or you will get SPINxxxx NOT SORTED errors.       
               This member has the PROC SORT and BY statements to resort
               all of the SPIN datasets.                                
   Thanks to Robert Battilana, Franklin Mint, USA.                      
Change 19.171  Misspelled variable CSRENTLE was corrected to CSRENTIN,  
VMACRMFV       and the dataset labels for ZRBCPU and ZRBENC were revised
Sep 14, 2001   in this almost-cosmetic change.                          
   Thanks to ???, ???, ???                                              
Change 19.170 -Dataset TPFFM variable FMIOTIM, unlike the SXxxxxxx wait 
VMACTPF        variables, should not have been divided by 4096.         
Sep 14, 2001  -All accumulated counters in all TPF datasets are now     
               protected for wrapping (when they exceed their four byte 
               field max value) using this logic to correct the wrap:   
                 IF . LT FVDATAn LT 0 THEN FVDATAn=FVDATAn+4294967296;  
               This change was not originally needed, because the TPF   
               monitor was only permitted to run for a few hours, so the
               counters didn't wrap, but now that TPF SYSPROGs/Managers 
               are seeing how useful it to measure TPF, they permit the 
               monitor to run all day, and the counters now do wrap!    
              -In the TPFFV dataset (VFA Database Activity), variable   
               SLOTNR was replaced with new variable FVDATBAS that has  
               the Database Number, 1 if there is only one database,    
               sequentially more when there are more than one.          
   Thanks to Robert Wilcox, Sabre, USA.                                 
   Thanks to Jim Gilbert, Sabre, USA.                                   
Change 19.169  The IBM field name DCVFRAGI should have been used as the 
VMACDCOL       variable name, but DCVFRAG1 is what I thought it was, but
Sep 10, 2001   now its too late to change the name without impact, so I 
               added a comment with the DCVFRAGI name for documentation.
   Thanks to Moira Hunter, SchlumbergerSema, ENGLAND.                   
Change 19.168  Change 19.104 missed some SU_SEC variables that should   
VMACTMV2       have been stored in 8 bytes now; variables SU_SEC in the 
VMAC97         TMON/MVS data, variable THSU_SEC in TYPE97, and variables
VMAC30         RMSU_SEC and LOSU_SEC in some TYPE30xx are now changed.  
Sep 10, 2001                                                            
Change 19.167  INVALID ARGUMENT TO FUNCTION INPUT caused messages and a 
ASUMCACH       hex dump on the log, and missing value in R7451RID that  
Sep  9, 2001   are now corrected.                                       
   Thanks to Chuck Hopf, MBNA, USA.                                     
Change 19.166  The Soft Audit product's records now contain SYSTEM in   
VMACSFTA       the field location that previously contained STEPNAME.   
Sep  9, 2001   New variable SYSTEM and old variable STEPNAME will now   
               contain the value of that field.                         
   Thanks to Jiann-Shiun Huang, CIGNA, USA.                             
Change 19.165  Revision; if APPEND=YES was specified and DDIN and DDOUT 
VMXG2DTE       are not the same, the output will reflect only the most  
Sep  9, 2001   current day, and an error was generated.                 
   Thanks to Chuck Hopf, MBNA, USA.                                     
Change 19.164  TMS Audit variables TMAUxxxx have been always missing,   
TYPETMS5       the TMVAxxxx variables should never have been created,   
VMACTMS5       and labels for some TMAUxxxx/TMVAxxxx variables had      
Sep  9, 2001   LAST UPDATE when they should have been LAST AUDIT.       
               This change revises the creation of TMAUxxxx variables,  
               (which should be used in place of TMVAxxxx variables)    
               in your report programs (although the TMVAxxxx variables 
               are correct and still kept in TMS.TMS so reports work).  
                  Note: The TMVAxxxx variables in your old TMS.TMS data 
                  did have correct values with wrong label.  TMVATIME,  
                  for example, contains the Last Audit Date, but now you
                  should use the TMAUTIME variable instead of TMVATIME. 
   Thanks to Terry Duchow, United States Postal Service, USA.           
Change 19.163  Variable JOBCLASS has always been unique, because it had 
ADOC30         valid EBCDIC characters (A-Z,0-9) for real TYPETASK='JOB'
VMAC30         records, but non-printable hex characters ('00'x) for SMF
Sep  9, 2001   type 30 records from non-JOBs (TYPETASK=STC/TSU/OMVS...).
               Before variable TYPETASK existed, I thought that keeping 
               those non-printable values might be useful, so JOBCLASS  
               used the $CHAR informat to preserve the hex value.  But, 
               under ASCII execution, this causes all values of JOBCLASS
               to be unprintable; MXG stores a hex 'C1'x in JOBCLASS for
               class 'A', but ASCII requires hex '41'x to print an 'A'! 
               Then, when IBM added the 8-byte class name field SMF30CL8
               years ago, MXG input it in JOBCLAS8 with $CHAR8, adding  
               logic to use it as JOBCLASS only when it was present:    
                 IF JOBCLAS8 GT ' ' THEN JOBCLASS=JOBCLAS8;             
               But under ASCII, that test was always true when JOBCLAS8 
               was blank (EBCDIC '40'x), because that  GT ' ' test is   
               IF  '40'x  GT  '20'x , so JOBCLAS8 was always used, even 
               when the one-byte JOBCLASS had a non-printable hex value!
               The fix:  SMF30CL8 is now always present, and it does not
               contain unprintable characters, so it is now INPUT into  
               the JOBCLASS variable (not JOBCLAS8), using $EBCDIC as   
               the Informat, and "IF JOBCLAS8 GT ' ' test was deleted.  
               What do you do with existing MXG datasets under ASCII?   
               I thought you could just use the $EBCDIC format in your  
               PROC PRINT to display the job class value, but that does 
               not work under either V6 or V8 under Windows:            
                  DATA; X='C1'x; PUT X $EBCDIC1.;                       
                  prints a lower case "e" instead of an "A"             
               However, you can convert the actual data value in the    
               JOBCLASS variable in your TYPE30_5 or PDB.JOBS dataset   
               on your ASCII system, using this data step:              
                 DATA JOBS;                                             
                 SET PDB.JOBS;                                          
               The description of JOBCLASS in ADOC30 was updated.       
   Thanks to Paul Gillis, Pacific Systems Management Pty Ltd, AUSTRALIA.
   Thanks to Robert Battilana, Franklin Mint, USA.                      
Change 19.162  JES3-only.  Variable NETNAME, The JES3 DJC (Dependent JOB
BUIL3005       Control) Network ID, is now propagated into PDB.JOBS when
Sep  5, 2001   BUILDPD3 is used to create your JES3-PDB.                
   Thanks to Graham Cornwell, Donovan Data Systems, ENGLAND.            
=Cruised from Nome, Alaska, south to St. Lawrence, St. Matthew, St.     
=George in the Pribilofs to Chugulak, and thence west across all of the 
=Aleutian Islands to Russia's Bering Island, Kamchatka Peninsula's      
=Valley of the Geysers (pronounced "geezers" in Russian), and           
=Petropavlovsk on the 340-foot Clipper Odyssey, with "birders" from the 
=American Birding Association.  Landings each morning via Zodiacs to see
=birds at sunrise, often second island landing in afternoon, phenomenal 
=weather (while the Alaskan State wine is "When is this fog going to    
=lift?", we had sun on every single day!).  And evening lectures on the 
=geology, flora and flauna! Saw over 100 bird species, including Steller
=Sea Eagles on their nest, 10 mammals (five whale species!), and bones  
=of the extinct Steller Sea Cow. Fantastic naturalist experience,       
=especially for this EE!                                                
Change 19.161  MXG 19.03 only.  Change DEBUG=1; to DEBUG=.; and those   
VMACTNG        "AFTER HEADERS _N_=" (harmless) notes won't be printed on
Aug 16, 2001   the SAS log.                                             
Change 19.160  Support for type 42 subtypes 7 and 8 was revised; a six  
VMAC42         byte filler is now skipped, the OFFCL calculation was    
Aug 16, 2001   corrected, and S42FFN and SMF42CHN are now input variable
               length, and converted and translated to be printable     
               under MVS or ASCII platforms.                            
   Thanks to Richard Fortenberry, Mitsubshi Motor Sales of America, USA.
Change 19.159  While TYPEMBO tested just fine, the TYPSMBO member had   
TYPEMBO        a type _SDEMBO should be _SMBO, and the VMACMBO member's 
VMACMBO        definitions of _NMBO and _SMBO were obviously incorrect. 
Aug 10, 2001                                                            
   Thanks to David Bixler, FISERV, USA.                                 
Change 19.158  Support for CISCO Works Blue ISM User SMF record creates 
EXCISM01       twelve new datasets, one for each subtype:               
EXCISM02          Dataset   Description                                 
EXCISM03          CISM01    CISCO ISM ROUTER/SWITCH CPU/MEM'            
EXCISM04          CISM02    CISCO ISM CMCC(CIP) CPU/MEM'                
EXCISM05          CISM03    CISCO ISM OSA CPU/MEM'                      
EXCISM06          CISM04    CISCO ISM TN3270 STATISTICS'                
EXCISM07          CISM05    CISCO ISM INTERFACE PERF STATS'             
EXCISM31          CISM07    CISCO ISM PATH STATISTICS'                  
EXCISM41          CISM21    CISCO ISM REAL SERVER STATS'                
EXCISM42          CISM31    CISCO ISM VIRTUAL SERVER STATS'             
TYPECISM          CISM66    CISCO ISM ISM EVENT LOG'                    
TYPSCISM       This support is preliminary; only subtypes 01,05,06,66   
VMACCISM       are decoded and tested, and these issues have just been  
VMXGINIT       observed from the small data sample:                     
Aug  6, 2001     -  The SYSTEM field in the CISCO SMF record is blank.  
                 -  There is an extra undocumented file at the end of   
                    the '01' record, that looks like a percentage?      
                 -  Additional '06' fields are documented for FDDI, etc 
                    that won't be decoded until they appear in data.    
                 -  The documentation shows 8 fields in the '06' record 
                    after the "OE(" marker (UN,OE,CO,IR,RS,OBF,OBS,TR), 
                    but there are only 7 data fields in the '06' record.
   Thanks to Harvey Aviles, SSA, USA.                                   
Change 19.157  The PDB.CICS dataset can be created by either ASUMCICS,  
JCLPDB8        which always counts from CICSTRAN, or by ASUMCICX, which 
JCLPDB6        will use PDB.ASUMUOW if it exists (i.e, if ASUMUOW was   
Aug  6, 2001   both included and member IMACUOW updated to create obs in
               PDB.ASUMUOW), but what is counted is quite different:    
               when PDB.CICS is built from CICSTRAN, it counts all CICS 
               transaction names separately, since each observation in  
               CICSTRAN is a separate "CICS" transaction, but if ASUMUOW
               is built, it has summarized all of the CICS transactions 
               in one "Unit-of-Work" into one observation, with only the
               "Real" transaction name of that UOW, and thus the counts 
               in PDB.CICS using ASUMCICX are counts of units-of-work,  
               not CICS transactions, and only the "Real" TRANNAME will 
               be in the PDB.CICS dataset built from ASUMCICX.          
   Thanks to Art Hunter, Penn Mutual Life Insurance Company, USA.       
Change 19.156 -Using %VMXGRMFI(IMACWORK=NO) in your RMFINTRV member and 
EXRMFINT       defining fewer than the default workloads can cause many 
Aug  6, 2001   each workload you didn't use, and all of those UNINIT    
               variables listed are actually created in PDB.RMFINTRV.   
               The problem was caused by the default LABEL statement in 
               EXRMFINT, which was there to support the earlier design  
               in which you defined the workloads in IMACWORK and their 
               labels in EXRMFINT.  With the revised VMXGINIT design,   
               the labels in EXRMFINT are not needed in my default code,
               and are now commented out, as an example if you are still
               using IMACWORK=YES and want to change labels.            
              -MXG 19.03 only. Change 19.105 causes errors if %VMXGRMFI 
               arguments end with slash before the comma (mis-matched   
               DO;-END; pair).  This change makes the final slash       
   Thanks to Nancy R. Brizuela, University of Wyoming, USA.             
Change 19.155  Dataset CTLGVSAM, created by reading an exported Catalog,
VMACCTLG       had unique variables missing because macros were spelled 
Aug  6, 2001   wrong.  Folowing _WCTLGVS  /* CTLGVSAM */, the statement 
               after the label should have been  _VCTLGVS _KCTLGVS to   
               match the CTLGVS (was mistyped as _VCTLGDS _KCTLGDS).    
   Thanks to Barry McQueen, Department of Defense, AUSTRALIA.           
Change 19.154  IHDRxxxx exit members exist for each "INFILE" that MXG   
IMACFILE       reads from, and are taken after the record header or     
IHDR110        sub-header, has been INPUT.  They exist so that you can  
IHDR110S       use ID, SUBTYPE, SYSTEM, APPLID, SMFTIME, etc., in these 
IHDRCIMS       exits to control whether or not MXG creates observations,
IHDRDCOL       primarily for ad hoc runs when you want to output just a 
IHDREAGL       little bit of the input.  For example, IHDR110S for CICS 
IHDRNTSM       Statistics Segments lets you select by STID value to only
IHDRTMDB       output to specific a CICxxxxx statistics dataset, and not
IHDRTMO2       waste temporary disk space with unwanted statistics.     
IHDRTMV2       These IHDRxxxx members are not new, but this change adds 
IHDRTPF        a macro variable to each, so that you can alternatively  
IHDRVMXA       tailor these headers "instream", using this syntax:      
IHDRTMDC         %LET MACxxxx=  %QUOTE(    your code    );              
IHDRIMS        instead of having to EDIT/SAVE of the IHDRxxxx member.   
IHDRTIMS       The IHDR members and their new MACxxxx macro variables:  
Aug  2, 2001                                                            
                 IHDRxxxx  Macro                                        
                 Member    Name     Data Source                         
                 IMACFILE  MACFILE  SMF Record Header, ID, SUBTYPE, etc.
                 IHDR110   MAC110H  CICS 110 Sub-Header, APPLID, etc.   
                 IHDR110S  MAC110S  CICS 110 Statistics Sub-Sub, STID.  
                 IHDRCIMS  MACCIMH  IMF/CIMS Record Header              
                 IHDRDCOL  MACDCOH  DCOLLECT Record Header              
                 IHDREAGL  MACEAGH  Eagle Header                        
                 IHDRNTSM  MACNTSH  NTSMF Record Header                 
                 IHDRTMDB  MACTMDH  TMON/DB2 Record Header              
                 IHDRTMO2  MACTMOH  TMON/CICS Record Header             
                 IHDRTMV2  MACTMVH  TMON/MVS Record Header              
                 IHDRTPF   MACTPFH  TPF Record Header                   
                 IHDRVMXA  MACVMXH  VM/ESA, z/VM Record Header          
                 IHDRTMDC  MACTMCH  TMON/DBCTL Record Header            
                 IHDRIMS   MACIMSH  IMS Log Record Header               
                 IHDRTIMS  MACTIMH  TMON/IMS Record Header              
               The MACFILE macro has existed for some time; IMACFILE was
               the original name for the SMF File Header, but now all   
               new INFILE exit member names start with IHDR.            
   Thanks to MP Welch, SPRINT, USA.                                     
Change 19.153 -NTSMF Process object record with NRDATA=27 is supported. 
VMACNTSM      -Records from Win2000 Servers with older NTSMF versions   
Aug  1, 2001   for Indexing Service, Indexing Service Filters, and Site 
Aug  3, 2001   Server Authentication Srevice had an unexpected instance 
               field, which is now expected, but not kept, as there is  
               no instance field with the current NTSMF version.        
   Thanks to Jim Quigley, ConEd, USA.                                   
Change 19.152  Variable NCL, Net Capacity Load, the back-end space used 
VMACICE        is now created in ICEBRGSY and ICEBRGUT dataset (but the 
Jul 31, 2001   ICEBRGUT records are generated only if you run a REPORT  
               SPACEUTILIZATION, daily, and have turned on subtype 7 in 
               SVAA or IXFP in SYS1.PARMLIB(SMFPARM), so using ICEBRGSY 
               which is always present is recommended).                 
   Thanks to Rob Gibson, Centrelink, AUSTRALIA.                         
======Changes thru 19.151 were in MXG 19.03 dated Jul 30, 2001======    
Change 19.151  If you use TEMP01/TEMP02/TEMP03 in a VMXGSUM invocation, 
VGETENG        a non-impacting Warning 413 may result, if those DDs were
VMXGSUM        on tape devices that had not been opened.  Our open to   
Jul 27, 2001   determine the device type of your (optional) TEMPnn DD   
Jul 30, 2001   caused the warning when the tape had not been opened.    
               Those TEMPxx parms were primarily needed before SAS V8   
               provided good multi-volume support, and are less needed  
               now, but as sequential format datasets on disk, they can 
               be striped and hardware compressed, and for VMXGSUM runs 
               with large volumes of data, they are still very useful.  
               This change eliminates the 413 warning by first looking  
               to see if the TEMPnn libname is already open, in which   
               case we will use its current engine, and if the TEMPnn DD
               is not open, we will force the Sequential Engine for you,
               and avoid the open that caused the warning. The TEMPnn   
               options are not used in any MXG VMXGSUM invocations.     
               Jul 30: Added GLOBAL to VMXGSUM and VIEW MXGENG.         
   Thanks to Mike Hoey, Ameren, USA.                                    
Change 19.150  Example of TREND summarization for the ASUMCEC dataset,  
TRNDCEC        similar to TRND70PR trending of ASUM70PR for LPAR/MDF,   
Jul 26, 2001   but TRENDCEC is a the hardware CEC/CPC level.            
   Thanks to Diane Eppestine, Southwestern Bell, USA.                   
Change 19.149  First 19.03 only.  TNG support still had incorrect values
VMACTNG        for STARTIME for some PLATFORMS, now corrected on all.   
Jul 26, 2001                                                            
======Changes thru 19.148 were in MXG 19.03 dated Jul 26, 2001======    
Change 19.148  Support for NTSMF V and Windows 2000 changes to 
VMACNTSM       the SYSTEM and PROCESS objects, including new variables  
Jul 26, 2001   for I/O activity at the process level:                   
Jul 27, 2001         IORDOPRT='IO READ OPERATIONS/SEC'                  
                     IOWROPRT='IO WRITE OPERATIONS/SEC'                 
                     IODTOPRT='IO DATA OPERATIONS/SEC'                  
                     IOOTOPRT='IO OTHER OPERATIONS/SEC'                 
                     IORDBYRT='IO READ BYTES/SEC'                       
                     IOWRBYRT='IO WRITE BYTES/SEC'                      
                     IODABYRT='IO DATA BYTES/SEC'                       
                     IOOTBYRT='IO OTHER BYTES/SEC'                      
               Revisions to PROCESS and UNTDISC made Jul 27, 2001.      
   Thanks to Jim Quigley, ConEd, USA.                                   
Change 19.147  Invalid type 42 subtype 5 record caused INPUT STATEMENT  
Jul 26, 2001   record was overlaid after 20,500 bytes, with a dataset   
               name appearing where there should be no data set name!   
               Segments thru VOLSER DX0004 (starting at byte 20249) were
               valid, but the segment for VOLSER DX0003 (at byte 20409) 
               contains offsets of S42VTVDO=7 and S42VTVXO=1, when those
               offsets must be greater than the current column, or zero,
               and subsequent fields are clearly invalid.  A heuristic  
               circumvention based on those observed values will detect 
               and delete these bad records, while the site contacts IBM
               for a correction to their invalid SMF 42-5 record created
               by DFSMS 2.1                                             
   Thanks to M.J.H. Elbersen, RABOBANK, NL.                             
Change 19.146 -TNG records with (*) in their object name, such as the NT
FORMATS        object "NWLINK IPS(*)(G)" saw the (*) and set TEXT='*'   
VMACTNG        instead of the expected TEXT='G', causing LENTEXT to be  
Jul 25, 2001   missing instead of 16, and deleting that record with an  
Jul 27, 2001   MXG note.  Now, the scan knows to skip (*) when looking  
               for the (X) length field.                                
              -Existing Format MGALFA only decoded single base-36 values
               for TNG field lengths (1)=1, (A)=10, (Z)=35, but now two 
               position base-36 characters, (12)=38 are supported when  
               that value was found for an object length.  Values to    
               (1Z)=71 are now decoded by MGALFA:                       
                -The related tests LENTEXT LE 36 were revised to LE 35, 
                 and a separate test for 36 LE LENTEXT LE 40 was added  
                 due to (10)=36 taking one more position than (Z)=35.   
                -The revised MGALFA format should not have been used in 
                 pre-9907 logic; the old format that stopped at (Z) did 
                 not have values for (11), etc, so an old (12) was seen 
                 as length 12, but the revised format now has (12)=38,  
                 so even though nobody probably still is using the old  
                 TNG format, I fixed it so my QA run with old and new   
                 data still works.                                      
               -STARTIME was correct for the first group of records, but
                it grew well into the future because it was not reset to
                ORIGTIME at the start of each object's counter's input. 
               -STARTIME was still wrong in the first day's MXG 19.03,  
                but was corrected in VMACTNG internally dated Jul 27.   
   Thanks to Greg Jackson, National Life of Vermont, USA.               
Change 19.145  Support for the Volume sections of type 42 subtype 11 XRC
EXTY42XV       (Extended Remote Copy Session statistics) now create new 
IMAC42         dataset TYPE42XV to track the read/write/update activity 
VMAC42         at the VOLSER level.  In addition, all duplicates were   
VMXGINIT       not being removed in TYPE42S2, but adding SMF42FBG (Cache
Jul 20, 2001   Structure Name) to MACRO _BTY42S2 removed all duplicates.
               However, multiple observations from the same subtype 6   
               SMF record exist in TYPE42DS that were also not removed  
               by the NODUP sort.  These multiples have different I/O   
               counts, but otherwise are identical, except that their   
               location in the record (S42JDDSO) is different, so it was
               added to MACRO _BTY42DS to remove the duplicates if dupe 
               SMF records are read, but the two otherwise observations 
               from the same record will now have different S42JDDSO    
               values.  If you discover why there are these multiples,  
               let me know and I'll update this text.                   
                 OBSERVATION COUNT CHANGE:  TYPE42DS fewer obs.         
   Thanks to Mike Delaney, Pershing, USA.                               
Change 19.144  RMF Partition data report was updated to report on the   
ANALRMFR       communication devices. To get full comm reports using the
Jul 20, 2001   DEVICEC=40 parameter for commmunications, add 41 to get  
               the CTC adapters included.                               
   Thanks to Joseph Rannazzisi, Salomon Smith Barney, USA.              
   Thanks to Jiann-Shiun Huang, CIGNA, USA.                             
Change 19.143  Candle did NOT correct the unsupported '20'x (instead of 
VMACNAF        the expected '01'x) value for the century "bit" in their 
Jul 21, 2001   internal time stamps; they ONLY corrected the date part  
               in the SMF header field.  The circumventions of Changes  
               18.025 and 15.211 were replaced with directly forcing the
               century bit into their fields and then using an INPUT    
               function to convert the modified character field.  This  
               circumvention may fail at the end of this century.       
   Thanks to Joseph J. Faska, Depository Trust, USA.                    
Change 19.142  MXG 19.02 only.  The SPIN logic did not keep SPINCNT, so 
VMXGUOW        the SPINUOW dataset continued to grow, as there are many 
Jul 20, 2001   CICS transactions whose end we don't see until the region
               is terminated, and the SPIN logic depends on SPINCNT to  
               recognize and output those type of events into ASUMUOW.  
               This error was not caught in our testing because of an   
               incorrect IMACUOW member in our tailoring library. Sorry!
               This change won't be seen until the second day's run.    
   Thanks to Alan Lankin, Towers Perrin, USA.                           
Change 19.141  The new type 74 subtype 7 FICON Director record has a new
VMAC74         option in ERBRMFxx of FCD/NOFCD that causes creation of  
Jul 18, 2001   that subtype.                                            
Change 19.140  The SASGRAPH argument was not UPCASE'd, causing test to  
ANALCNCR       fail if you typed your SASGRAPH=yes in lower case.       
Jul 18, 2001                                                            
   Thanks to Ian Davies, Independent Consultant, CANADA.                
=Attended the superb SAS 25th Anniversary Party in Raleigh, NC, with    
=7,200 SAS employees and families, with two bands popular in 1976:      
=   The Village People and KC and the Sunshine Band!                    
Change 19.139  An SMF 116 with invalid QWHS segment length of 108 bytes 
VMAC116        (110 is expected) caused INPUT EXCEEDED STOPOVER error.  
Jul 13, 2001   The QWHS segment it self was trashed, with invalid data  
               values for CAID, CCV, CCN, and XTYP, and the 22-byte     
               accounting segment was only 20 bytes.  This change only  
               detects the short segment and prints an error message on 
               the SAS log.  This note will be updated if an APAR is    
               found/developed to correct the IBM error in the record.  
   Thanks to Mat Elbersen, RABOBANK, THE NETHERLANDS.                   
   Thanks to Ian Davies, Independent Consultant, CANADA.                
Change 19.138  Local variables ENTEJECT caused a warning because it did 
GRAFTAPE       not exist, and was not referenced in sample reports, so  
Jul 13, 2001   it was removed from the member.                          
   Thanks to Ian Davies, Independent Consultant, CANADA.                
Change 19.137  IMF Program record's variable FLGUESQL was incorrectly   
VMACCIMS       input @79 when that field is located @80.  It and a few  
Jul 13, 2001   other flag variables were also formatted $HEX2.          
   Thanks to Sergio Fastella, ALITALIA, ITALY.                          
Change 19.136 -TPF datetimestamp variables are written in GMT zone, but 
VMACTPF        MXG now converts them all to your local time of day, by  
VMXGTPFI       using the DB/DE records, which are written first in each 
Jul 11, 2001   file, containing the GMT datetime and a local time and   
Jul 12, 2001   local date (but its '01JUL' with no year, so conversion  
               from GMT to local has special logic to deal with JAN01   
               and DEC31 data to set the local year correctly!          
              -Variable SHIFT is now created in all datasets that have  
               STARTIME, that is, all interval datasets.  Your IMACSHFT 
               definitions are used with STARTIME to set the shift of   
               each observation.                                        
Change 19.135  MXG 19.01 and 19.02, IMS Log processing.  Change 19.061  
ASMIMSL5       was incorrect, causing invalid time stamp values.  The   
ASMIMSL6       asterisk in column one that was added by that change:    
Jul 11, 2001        *      BO    DROPMAP    NONRECOV  Change 19.061     
               is removed by this change so the statement now reads:    
                           BO    DROPMAP    NONRECOV  Change 19.135     
   Thanks to Rita Bertolo, Canadian Pacific Railway, CANADA.            
Change 19.134  Documentation only.  When I/O delay is NOT included in   
VMAC7072       velocity in your WLM, MXG's calculated VELOCIOD variable 
Jul  9, 2001   estimates what the velocity would be if I/O delays, in   
               R723CIOD/PCTDLIOD, and WLM-managed batch initiator delay,
               in R723CTDQ/PCTDLTDQ, were both included.  Both impacts  
               are in the one VELOCIOD variable, because I didn't think 
               more velocity estimate variables were needed for the now 
               several possible combinations, and because you could     
               always use the EXTY72GO exit to recalculate your own     
               estimate if really needed.                               
               My VELOCIOD won't match either of RMF report's values in 
               I/O PRTY or INIT MGMT; IBM calculations assume only the  
               one impact, and also say that if R723VELI is not on, that
               both I/O useage and I/O delay are not included!          
               When I/O delay and/or Init delay are enabled in your WLM,
               i.e., when R723VELI='Y', there is no discrepancy, because
               VELOCITY and VELOCIOD are equal and correct.             
   Thanks to Steve Dyck, CDS, USA.                                      
Change 19.133  Some JCL Examples for Assembly and LinkEdit of programs  
DOC            written in IBM ASM still had PGM=IEV90 and PGM=IEWL for  
Jul  3, 2001   the Assembler and Link Editor, but Carl, an ASM Guru at  
               SAS, pointed out that the more likely names in use in    
               this millennium would be PGM=ASMA90 and PGM=HEWL.        
   Thanks to Carl Meredith, SAS Institute, USA.                         
Change 19.132  Support for both VM/ESA V2.4 and z/VM V3.1.  The V2.4    
VMACVMXA       changes were added first, then the 3.1 LIST1403 was used 
Jun 30, 2001   to update those changes, which are listed separately in  
               this change text.                                        
               Some of the new numeric variables may be accumulated and 
               will need to be DIF'd, so you should verify their values 
               before using!                                            
     These new variables were added in the Jun 30 change:               
     Dataset   New Variables                                            
     SYTSYP:   PLSDGUCT PLSXITCT                                        
     SYTPRP:   PFXSPINT PFXSPINC                                        
     SYTUWT:   CALLLIST                                                 
     MTRPRP:   PFXTYPE CALUDED                                          
     MTRUSR:   VMDBYVAL VMDMXSHR                                        
     MTRSCH:   SRMXPCTG                                                 
     STOSHR:   ASCCTXBK                                                 
     USEINT:   HFLLIST  HFPGACT  VMDSLCNT                               
     PRCPRP:   CALUDED  PFXTYPE  HFUSERM                                
     IODDEV:   THRDLYS SCMCQTIM                                         
     IODCAD:   CALSSS2                                                  
   Thanks to Pat Curren, SuperValu Inc, USA.                            
Change 19.131  Validation of SOL260S TNG data found several minor errors
VMACTNG        that have been corrected and MXG's values now matches the
Jun 29, 2001   Excel spreadsheet created by TNG.                        
   Thanks to Bill Shanks, SEMA, ENGLAND.                                
   Thanks to Paul Hargreaves, SEMA, ENGLAND,                            
Change 19.130  IBM has redefined type 103 variable TIMEWRIT as the time 
VMAC103        since the last SMF write, now called SMFRecordingInterval
Jun 29, 2001   in IBM documentation, so it's label was clarified.       
   Thanks to Dave Cogar, Computer Associates, USA.                      
Change 19.129  Using UTILBLDP with BUILDPDB=NO option printed warning:  
Jun 29, 2001   because IDFLAG was not initialized in that loop.  Insert 
                 %LET IDFLAG=NO;                                        
               after the existing %LET DE2FLAG=NO; in that loop.        
   Thanks to Ian Davies, Independent Consultant, CANADA.                
Change 19.128  Running MXG under unix hit another lower case problem:   
VMXGINIT        ERROR: File does not exist /mxg/sourclib/AAAAAAAA.SAS   
Jun 28, 2001   Under unix SAS, %INCLUDE SOURCLIB(MEMBER) looks for file 
INSTALL        "", while INFILE SOURCLIB(MEMBER) looks for    
Feb  4, 2003   "member.dat", both in lower case only, so all MXG source 
               files must be lower cased on unix.  It turns out that    
               when the MEMBER name has no extension, unix SAS looks    
               only for lower case file name, but if ANY extension name 
               is used (MEMBER.EXT), SAS instead looks for a file name  
               in the case of the source code, and the MXG statement    
               that was added that caused the error is in upper case:   
                 INFILE SOURCLIB(AAAAAAAA.SAS)                          
               One earlier fix (actually, one still discussed in INSTALL
               member's instructions until Feb, 2003!) was to uppercase 
               the source file to AAAAAAAA.SAS, because that is the only
               file in MXG that is read with an INFILE syntax.  Or, you 
               could have lowercased the VMXGINIT member, or I might be 
               able to modify the MXG install process for unix to UPCASE
               that one file.                                           
               But instead, the %LOWCASE macro function was inserted in 
               the INFILE statement for ASCII (i.e. unix/linux/WINDOWS):
                 INFILE SOURCLIB(%LOWCASE(AAAAAAAA.SAS))                
               which will cause unix to look for, and you  
               don't have to change anything to run MXG under unix.     
               This also works under Windows because file names there   
               are not case sensitive.                                  
               Note: Don't try this under EBCDIC systems; using MVS     
                     syntax of INFILE SOURCLIB(%LOWCASE(AAAAAAAA));     
                     fails with a JFCB error, because MVS still can't   
                     handle lower case DDnames.                         
               Feb 4, 2004: The INSTALL member was revised, telling     
               you to leave the filename in lower case.    
   Thanks to Chris Weston, SAS ITSV Development, USA.                   
   Thanks to Mark Rothschild, Caremark, USA.                            
Change 19.127  An obscure exposure in VMXGSUM is corrected; if you had  
VMXGSUM        both INTERVAL= and NORMn= arguments, some variables could
Jun 28, 2001   be missing in the output dataset.  None of the MXG uses  
               of VMXGSUM had both, but the ASUMCACH enhancement added  
               the INTERVAL= to an existing NORM1= argument, uncovering 
               the error.  Correction was to relocate a code segment.   
   Thanks to Chuck Hopf, MBNA, USA.                                     
Change 19.126  DFHSM 1.4 via PTF and standard in DFHSM 1.5 and later,   
VMXGHSM        two new variables for stacked volumes (field sequence    
Jun 28, 2001   number DGNFLSEQ, file block ID DGNFBID) were added to the
               DGN dataset.  A reserved area was used for the two new   
               fields, so the IBM change is COMPATIBLE.                 
   Thanks to Wanda Prather, Johns Hopkins Applied Physics Lab, USA      
Change 19.125  Support for TPF releases PUT08, PUT10, and PUT12, which  
VMACTPF        inserted data fields incompatibly in several records.    
VMXGTPFI       The major changes were internal, to add the many new     
Jun 27, 2001   variables for the 9th thru 16th Instruction Streams into 
Jun 29, 2001   TPFSX dataset, and two new variables in dataset TPFDX.   
Jul 10, 2001   Variable SXTWCSPR was dropped from TPFSX dataset and the 
               VMXGTPFI was revised to not reference that variable.     
               Internal mapping formats for TPFDR & TPFDH now use CPUID 
               so that TPF data from multiple systems can be processed  
               by concatenation of the input files.  New variable SYSTEM
               is created in dataset TPFINTRV; you must update the table
               in your member IMACTPF to map which CPUIDs are in which  
               system to populate variable SYSTEM.  There still is one  
               observation per CPUID per interval in TPFINTRV dataset,  
               but if you update that table, variable SYSTEM will exist 
               so that you can use it in subsequent summarization.      
               Jul 10: Added ZDATE to TPFINTRV.                         
                       Obs with FFCCHHR='00'X are now OUTPUT in TPFFF;  
                       they are Virtual File Access and should not have 
                       been deleted.                                    
                       Several misspellings of 9-G variables corrected. 
   Thanks to Robert Wilcox, Sabre, USA.                                 
   Thanks to Jim Gilbert, Sabre, USA.                                   
Change 19.124 -Adding the processing of SOLVE SMF to BUILDPDB caused    
VMACMDF        Change temporary variable YYYY to YYYYCH in two places to
VMACSOLV       eliminate the conflict and the warning message.          
Jun 28, 2001  -Changed CONDCODE to CONDCODH in VMACLDMS, to avoid a     
               conflict, and because it is the Highest CondCode value.  
              -Changed temp variable DOMFLAGn to DOMDFLGn in VMACMDF.   
              -This change was precipiated by the VMACSOLV error, but   
               the MXG QA stream should have caught this conflict of    
               variable types, because ANALCOMP is now run to compile   
               simultaneously all SMF-reading MXG programs to find any  
               such conflicts.  Why were all three not caught then? In  
               fact, this error was caught by the April 5 QA run, but it
               took this error to remind me to use that enhancement to  
               make these corrections!                                  
   Thanks to John Temme, Department of Defence, AUSTRALIA.              
Change 19.123  Enhancement to ASUMCACH, for DASD Cache and DASD I/O.    
ASUMCACH       Variables that identify the control unit are added using 
Jun 28, 2001   a PROC FORMAT as a table lookup.  Summarization is now   
               forced to QTRHOUR level (so that if there are multiple   
               systems where the TYPE74 and TYPE74CA dataset times are  
               not exactly aligned, we will now always put the data     
               together.  And additional variables are created to allow 
               better downstream reporting capabilities.  The SORT order
               of the output is now SYSPLEX STARTIME DEVNR VOLSER, so   
               you can examine the data by SYSPLEX.                     
   Thanks to Chuck Hopf, MBNA, USA.                                     
Change 19.122  Documentation of an example use of the EXPDBSPN exit.    
EXPDBSPN       The site had used IEFACTRT exit to put account info for  
Jun 26, 2001   STCs in type 30_4 and 30_5 SMF records in PGMRNAME, but  
               BUILDPDB keeps PGMRNAME only from TYPE26 and TYPE30_1,   
               and their exit was after the type 30-1 was created.      
               Adding variable PGMRNAME to the Keep list for 30_5 did   
               now work, because the MXG MERGE statement has TYPE30_5   
               first, and then TYPE30_1 (as required by BUILD005 logic),
               causing the blank value in TYPE30_1 for these STCs to    
               overwrite the non-blank PGMRNAME in TYPE30_5.  For this  
               site's specific SMF modifications, the solution was to   
               use the EXPDBSPN exit, which is taken just before the    
               "Big Merge" (see member DOCPDB for more details than you 
               probably want to read), and in their exit code, add the  
               PGMRNAME from their TYPE30_5 dataset into the TYPE30_1   
               dataset, and then the "Big Merge" logic works just fine. 
               This example is the code they inserted into EXPDBSPN:    
                  DATA TEMP30_5 (KEEP=READTIME JOB JESNR PGMRNAME);     
                  SET TYPE30_5;                                         
                  DATA TYPE30_1;                                        
                  MERGE TYPE30_1 (IN=IN1) TEMP30_5 (IN=IN5);            
                  BY READTIME JOB JESNR;                                
                  IF IN1 THEN OUTPUT;                                   
               and they also had to insert:                             
                  %LET ADD30U5=PGMRNAME;                                
               before their %INCLUDE SOURCLIB(BUILDPDB); statement, to  
               add the variable PGMRNAME to be kept in TYPE30_5 inside  
               the BUILDPDB logic.                                      
   Thanks to Duncan Walker, Experian Limited, ENGLAND.                  
Change 19.121  The macros did not UPCASE the DDNAME, so it returned an  
VGETENG        incorrect value if you used lower case DDNAME in the MXG 
VGETOBS        macro invocation.                                        
Jun 26, 2001                                                            
Change 19.120  IBM APAR OW49536 documents new bit which is now variable 
VMAC7072       LCPUVARY='Y' in dataset TYPE70PR if this LPAR was varied 
Jun 26, 2001   online during this interval.                             
Change 19.119  New VMXGSUM option OUTVIEW=YES (default is OUTVIEW=NO)   
VMXGSUM        will cause VMXGSUM's output dataset to be a VIEW instead 
Jun 25, 2001   of a dataset.  We will use this internally so MXG will   
               be faster & cheaper when we can pass the output from one 
               VMXGSUM execution into another data step (or VMXGSUM!).  
               Note that if you use OUTVIEW=NO, the View will have the  
               same name as the OUTDATA= that you specified, but, since 
               it is a VIEW, that dataset will NOT exist when VMXGSUM   
               finishes, and if you do not reference the VIEW after it  
               is created, it will not physically exist as a dataset.   
   Thanks to Chuck Hopf, MBNA, USA.                                     
Change 19.118  Test for &SASVER EQ 6 was changed to &SASVER GE 6, but   
ANALDB2R       luckily, running under Version 8 produced the correct    
Jun 25, 2001   reports.  The test will bypass a data step when under SAS
               V6+ (by using the INHERIT option), but executing the data
               step under V8 still worked correctly.                    
   Thanks to Chuck Hopf, MBNA, USA.                                     
Change 19.117  IMS Log processing with TYPEIMS7 (resources, no response)
TYPEIMS7       warning messages *** LCODE 35X NOT OUTPUT for ENQFLG=0C  
VMACIMS        and FLAG2=40x or 60x are now output to IMS35O dataset.   
Jun 23, 2001   The warnings had no impact on the IMS0708 dataset that is
               create by the TYPEIMS7 program, since only 07 and 08 log 
               records are used in IMS0708.                             
               In addition, the MXG logic to set NMSGPROC=1 for 08-only 
               matches caused the total NMSGPROC in IMS0708 to be more  
               that the true NMSGPROC in the 07 reocrds, so NMSGPROC=0  
               is now set for the 08-only matches in TYPEIMS7.          
               And IMSQBLDN is now a positive number; it was initialized
               to -34, but that RETAIN statement was corrected.         
   Thanks to Rita Bertolo, Canadian Pacific Railway, CANADA.            
Change 19.116  New %MACROS allow you to read many PDB libraries for one 
VMXGSET        only those DDnames that are found will be used!  You can 
VMXGINIT       control, by the DDNAMES (or LIBNAMES) in your JCL, which 
Jun 22, 2001   PDB libraries will be read, but you do have to change the
               SET statement in your SAS program!  Two %MACROS are used:
              -%VGETDDS  -  "Get" ddnames:                              
                 %VGETDDS(DDNAMES=WEEK: PDB: ALLWEEK);                  
               You tell VGETDDS the DDnamePrefixes and specific DDnames 
               that you want to use.  That example will find all DDnames
               starting with WEEKn, PDBn, and the DDnames MON TUE WED   
               THU FRI SAT SUN that are SAS data libraries, and only    
               those DDnames will then be read by the second macro.     
              -%VMXGSET  -  Use in place of your SET statement:         
                  DATA COMBINE.JOBS;                                    
               You tell VMXGSET what MXG dataset (aka table) you want to
               read, and if any of your datasets are on tape media, you 
               can specify DEFER=YES (SAS V8+ only) and the OPEN=DEFER  
               option will be on the SET statement that we construct,   
               causing each individual dataset in the SET statement to  
               be opened, read, and closed, left to right, so you use   
               UNIT=AFF in your JCL, and need only one tape drive to    
               read all of your datasets!                               
                  The only caution with DEFER=YES is that it cannot be  
                  used if there is a BY statement with %VMXGSET, because
                  a BY statement opens all datasets in a SET statement. 
               So to read five PDB libraries, PDB1-PDB5, you would have 
               // EXEC MXGSASV9                                         
               //PDB1 DD DSN=YOUR.PDB(0),DISP=SHR                       
               //PDB2 DD DSN=YOUR.PDB(-1),DISP=SHR                      
               //PDB3 DD DSN=YOUR.PDB(-2),DISP=SHR                      
               //PDB4 DD DSN=YOUR.PDB(-3),DISP=SHR                      
               //PDB5 DD DSN=YOUR.PDB(-4),DISP=SHR                      
               //COMBINE DD DSN=YOUR.OUTPUT.PDB,DISP=(,CATLG)....       
               //SYSIN DD *                                             
                 DATA COMBINE.JOBS;                                     
                 ...  rest of your subsetting logic ...                 
               More details.                                            
               You would execute %VGETDDS(DDNAMES=....); once to build  
               the DDnames, and then execute a DATA step that executes  
               %VMXGSET(DATASET=....) for each data set to be read.     
               (While not likely, you can also execute %VGETDDS multiple
               Special values exist for %VGETDDS's DDNAMES= argument:   
                 CCCCCCCC  - 1-8 char, specific DDname (all characters) 
                 CCCCCCnn  - 1-7 char, final 1-2 numeric - scan CCCCCC1,
                             CCCCCC2 .. until an CCCCCCn+1 is not found 
                             use CCCCCC1 to CCCCCCn DDnames             
                 ALLWEEK   - SUN MON TUE WED THU FRI SAT  DDnames       
               Note:  If there is more than one tape dataset, and you   
                      use OPEN=DEFER and UNIT=AFF so that only one tape 
                      drive is needed, there will be two mounts of each 
                      tape dataset's first volume: one to recognize it  
                      is a PDB, and, because UNIT=AFF will dismount the 
                      first to recognize the second, there will be the  
                      re-mount of the first dataset when the read       
                      begins.  Of course if your tapes are in a VTS,    
                      there is no actual second physical mount, but you 
                      will see both of the mounts on the SYSLOG.        
               Currently, an arbitrary limit of 99 DDs can be used in   
               the ultimate SET statement that results.                 
               Even though references are mostly to MVS DDnames, the    
               new macros work also work on ASCII SAS platforms.        
              -VMXGINIT was updated to GLOBAL the VGETDDS name.         
              -HOWEVER: PRIOR TO 2005, there was a serious problem      
               in that some LIBNAMEs could have been missed by VGETDSN, 
               but only if the Data Library were controlled by HSM, and 
               only if you were missing an IBM Patch.  That should not  
               now be a problem, but you can read the full details in   
               the text of (old) MXG Change 23.244.  (Updated 2009).    
   Thanks to Chuck Hopf, MBNA, USA.                                     
   Thanks to Rick Langston, SAS Institute, USA.                         
   Thanks to Jim Horne, Lowe's Companies, USA                           
Change 19.115  You can disregard these confusing SAS NOTES:             
                A DIFFERENT OPERATING SYSTEM.                           
                DATA STEP VIEW.                                         
               These notes are because MXG now uses VIEWs where possible
               to eliminate I/Os, but the "source" is already in your   
               MXG Source library, so there is nothing to save or do.   
   Thanks to Freddie Arie, Texas Utilities, USA.                        
Change 19.114  RMF type 74 subtype 5 (Cache Subsystem) "broken" records 
VMAC74         cause the same "INPUT STATEMENT EXCEEDED" error that was 
Jun 21, 2001   seen with subtype 4.  See the extensive discussion in the
               text of Change 17.398.  IBM RMF Development has agreed to
               create only 'self-contained' records (and they may well  
               have done so, as this particular RMF record was written  
               by SP5.1), but this change replaced the statement:       
                  IF SMF745XN GT 0 THEN DO;                             
               with this replacement statement:                         
                  IF NDVCNT LE SMF745XN THEN DO;                        
               so that MXG will only look for Extension sections when   
               they exist in the first "broken" record.                 
               In this instance, the first record had 254 Device Data   
               Sections, but only 11 Device Data Extension Sections     
               (i.e., for the first 11 devices).  A second SMF record   
               contains the remaining 243 Extension Sections, but there 
               is no Device Section with which to match them, so they   
               are never input.  This change prevents MXG from INPUTing 
               a non-existent extension section, but that will cause    
               all of these variables to have missing values in TYPE74CA
               when a broken record is processed:                       
                    R745XDVN     /*DEVICE*NUMBER*- SAME AS DEVN */      
                    RSV          /*R745XRSV*LOWER*IO*MILLISEC*/         
                    DCTC         /*XCTC*DEV CACHE TRKS CONFIGED*/       
                    DCTR         /*XCTR*DEV CACHE TRKS REMOVED */       
                    DVRD         /*XVRD*DEV READS*BY CU*/               
                    DVRH         /*XVRH*DEV READ HITS*BY CU*/           
                    DVWR         /*XVWR*DEV WRITES*BY CU*/              
                    DVWH         /*XVWH*DEV WRITE HITS*BY CU*/          
                    TSRR         /*XSRR*TRKS*STAGED*FOR RAID RE*/       
                    SFRD         /*XFRD*TRKS*READ*FROM SIDEFILE*/       
                    CWCC         /*XWCC*CONCUR*COPY*CONTAM*WRIT*/       
                    PPRC         /*XPRC*PPRC*WRITE*COUNT*/              
               The MXG change now also protects the LN/RN/1N/VN INPUTs  
               in case those segments are in a second record.           
   Thanks to MXG/ITSV Technician, Promise Co. LTD, JAPAN.               
Change 19.113  Several examples were revised; some caused errors and the
NEWUSER        others were updated to be clearer.                       
Jun 20, 2001                                                            
   Thanks to Lary Nova, COMSI, USA.                                     
Change 19.112  PDB.CICINTRV dataset can contain negative minimum values 
VMXGCICI       or missing values, when there are no INT (Interval) CICS 
Jun 20, 2001   statistics records, i.e., when there are only 'EOD' data.
               First, if there are no 'INT' records, and you request the
               default INTERVAL=HALF-HOUR for PDB.CICINTRV, you will get
               unexpected results - I can't create intervals where there
               are not, so you must request INTERVAL=EOD in CICINTRV.   
               But even if you specified INTERVAL=EOD, there was still  
               an error in the logic in VMXGCICI, because in each of the
               processing code for these datasets ('suffixes'):         
                 DL1 DL3 DBU PGG IRC DMR FEP FEC FET JCR LDR LS1 LS3    
                 SDR SMD SMT TC1 TDR XMC USG XMG XMR                    
               a statement  IF FIRST.APPLID THEN DELETE;  existed that  
               could cause those datasets to be not included in the     
               PDB.CICINTRV (so their variables would be missing).      
               This change removed that code from VMXGCICI.             
                    Additional internal documentation note:             
                    These yyy's did not have the DELETE statement:      
                      TC  TSR DMG VT  AUT LDG DTB TCR DQR DQG TSQ       
                      DS  ST  FCR M   TDG SDG SMS AUS CO1 CO3 CON,      
                    These yyy's are not currently used in VMXGCICI:     
                      CSF6/7/8/9, D2G,D2R,LGR,LSG,NCS4,NCS4,NQG,        
   Thanks to Sally Weber, Washington Mutual, USA.                       
Change 19.111  Support for DFSMS/RMM data in MXG is confusing, because  
VMACEDGR       IBM has similar data in different formats that can be    
VMACEDGS       written to SMF or dumped with IBM's EDGHSKP utility in   
Jun 20, 2001   two different formats.  This is documentation only.      
               1. MXG's "EDGSxxxx" processing:                          
               RMM can create two SMF records with different SMF IDs,   
               so MXG has two separate macros to define the SMF record  
               numbers your installation told rmm to use:               
                 _IDEDGSU for the "Security" record, one subtype,       
                          populates dataset EDGSSECU if found,          
                 _IDEDGSA for the "Audit" record, many "subtypes":      
                          EDGATYPE='C' populates EDGSAREC, only from    
                          SMF records, but the "Audit" record also has  
                          all of the rmm control records subtypes with  
                          EDGATYPE=D/K/O/P/E/F/U/R/S that populate the  
                          EDGSPVOL datasets.                            
               MXG's members TYPEEDGS and TYPSEDGS will read the infile 
               "SMF" and create all of the EDGSxxxx datasets.           
               But the IBM utility EDGSKIP can create a Control Backup  
               flat file from the rmm Control file (EDGSKIP with BACKUP 
               option), and that flat file is in almost-SMF-format that 
               contains the same Audit subtypes, so the same EDGSxxxx   
               datasets can be crated from either SMF records or the    
               Control Backup file.  Because of slightly different input
               format, two different members are needed in MXG, but they
               both create all of the EDGS datasets, which will be      
               populated with observations when those subtypes are read 
                TYPEEDGS - Reads Infile "SMF" to create "EDGS" datasets 
                TYPEEDGB - Reads Infile "LOGSMF" from Backup option to  
                           create "EDGS" datasets.                      
               2. MXG's "EDGRxxxx" processing:                          
               But you can also run EDGHSKP to Extract instead of Backup
               (EDGSKKIP with RPTEXT), and that creates a flat file that
               is physically different in record layout, but it contains
               almost all of the same record subtypes.  Unfortunately, I
               did not recognize the similarities, so MXG dataset names 
               are EDGRxxxx, and different variable names are used:     
                TYPEEDGR - Reads Infile "EDGHSKP" from Extract option to
                           create "EDGR" datasets.                      
               This table should identify which MXG datasets are similar
               from these multiple possibilities:                       
               Type     "EDGS" process                  "EDGR" process  
                -        EDGSSECU   SMF - Security      does not exist  
                C        EDGSAREC   SMF - Activity      does not exist  
                D        EDGSDREC   Data Set            EDGRDEXT        
                K        EDGSKREC   Vital               EDGRKEXT        
                O        EDGSOREC   Owner               EDGROEXT        
                O        EDGSOVOL     ", per volume     does not exist  
                P        EDGSPREC   Sftw Product        EDGRPEXT        
                P        EDGSPVOL     ", per volume     does not exist  
                E/F/U    EDGSRREC   LIB Shelf Location  EDGRREXT        
                R/S      EDGSSREC   Storage Loc Shelf   EDGRSEXT        
                V        EDGSVREC   Volume              EDGRVEXT        
   Thanks to Dale Haug, Philip Morris, USA.                             
Change 19.110  New CICSTRAN variables BARSPACT and BATIAECT were wrongly
VMAC110        spelled BARACTCT and BADFTECT, but are now corrected to  
Jun 19, 2001   agree with the IBM field names.                          
   Thanks to Gary L. Keers, Indiana Power & Light, USA.                 
Change 19.109  ACCOUNTn variables in TYPE33 APPC SMF records are blank  
VMAC33         if the TP profiles specify TAILOR_ACCOUNT(YES) and the   
Jun 19, 2001   RACF WORKATR account code is not populated.  Specifying  
               TAILOR_ACCOUNT(NO) corrected that problem, but caused MXG
               to set READTIME to a missing value because these lines:  
               were executed when MXG found both a TP usage section and 
               an accounting section in the type 33 SMF record, i.e.,   
               only when TAILOR_ACCOUNT(NO) is specified.  When YES is  
               specified, there is no accounting section in the SMF     
               record.  Those lines were inserted only to suppress a SAS
               "UNINITIALIZED VARIABLE" note, back when there was no JOB
               name nor READTIME in the type 33 record, so that the MXG 
               IMACACCT member could be used to decode the ACCOUNTs, but
               as both JOB and READTIME are now input in the VMAC33     
               member, that protection is unneeded, and its unintended  
               consequence, this error, is eliminated by deleting them. 
   Thanks to Walter Medenbach, IBM Global Services, AUSTRALIA.          
Change 19.108  MXG output only one observation per SMF 108 subtype 2/6  
VMAC108        record, because multiple sections were not expected, but 
Jun 13, 2001   as they are now known to exist, many observations that   
Jul  9, 2001   were not output are now created:                         
                 Subtype 2:  513 records, 10487 observations (now)      
                 Subtype 6:  527 records, 71592 observations (now)      
               Additionally, variables DOMRVN and DOMPVN are now kept in
               each subtype dataset (to identify version changes).      
               Jul 9: SM180UDO re-spelled as SM108UDO.                  
                 OBSERVATION COUNT CHANGE: TYPE1082 more obs.           
                 OBSERVATION COUNT CHANGE: TYPE1086 more obs.           
   Thanks to Wolfgang Vierling, Allianz, GERMANY.                       
Change 19.107  New exit member EXTPFINT for the TPFINTRV dataset is now 
EXTPFINT       added, so that new variables can be created in TPFINTRV. 
VMXGTPFI       See comments in the exit member.                         
Jun 12, 2001                                                            
   Thanks to Jim Gilbert, Sabre, USA.                                   
Change 19.106  Archaic VMACIMS member had incorrect IMSRECNO because the
VMACIMS        statement LOCRECNO=LEN-3; was missing for three IMS 5.1  
Jun 11, 2001   code segments for the 35x log record (which is not used  
               by the TYPEIMS7 program, which is now the only user of   
               the VMACIMS member, and it doesn't use the 35x records). 
   Thanks to Siegfried Trantes, IDG Informationsvararbeitung, GERMANY.  
Change 19.105 -SU_SEC variable is now kept in 8 bytes, because the new  
UTILRMFI       larger values can loose some low decimal digits in 4.    
VMAC7072       For example, a Z-series 5-way has SU_SEC=10540.1845, but 
VMXGRMFI       that was truncated in 4 bytes to only SU_SEC=10540.1818, 
Jun 11, 2001   so the magnitude of the truncation is small, only .0027. 
Jun 21, 2001  -The original implementation of VMXGRMFI/UTILRMFI for WLM 
               required blanks between the parameters of the WORKnn=    
               operands of VMXGRMFI, causing confusion and errors.  Both
               members were revised to now tolerate blanks, but they are
               no longer required. The / character still is required as 
               a delimiter to positionally identify the operand.        
              -Use of both KEEPxxx and DROPxxx VMXGRMFI arguments is not
               supported; now you will get a USER ABEND 1913 if you try.
   Thanks to Larry Nova, TransAmerica Commercial Finance, USA.          
Change 19.104 -TYPE72GO variables VELOCITY/VELOCIOD/VELOCCPU were       
VMAC7072       propagated into subsequent periods in the same SMF record
VMXGRMFI       if there was no activity in those subsequent periods.    
Jun 11, 2001   Now, all are set to missing if they cannot be calculated.
              -Temporary dataset WORK.RMF72DS (built in VMXGRMFI) is now
               deleted, as it should have been, for housecleaning.      
              -Comment references to NORM70=YES were removed, as that   
               normalization is now automatically performed for all the 
               variables in R70NRM list.  NORM70 was never needed.      
   Thanks to Shantha Peetham-Baran, Cap Gemini Ernst & Young, ENGLAND.  
Change 19.103A The default DDname of "PDB" in BUILDPDB can be changed by
VMXGINIT       re-invocation of the %VMXGINIT macro in your //SYSIN.    
Jun 11, 2001   If you want to write directly to the "MON","TUE",etc.,   
               'day-of-week' dataset and not have a "PDB" ddname, you   
               can use a DATA step to create the name of "Day-of-Week"  
               in a macro variable &DAY, and then use that macro as the 
               default value instead of "PDB":                          
                 DATA _NULL_;                                           
                 DAY=UPCASE(PUT((TODAY()-1),WEEKDATE3.));  /*variable*/ 
                 CALL SYMPUT('DAY',DAY);             /*macro variable*/ 
                 RUN;                                /*force evaluate*/ 
                 %VMXGINIT(DEFAULT=&DAY);                    /*invoke*/ 
                 %INCLUDE SOURCLIB(BUILDPDB.....);                      
               The change made in member VMXGINIT was cosmetic; a flag  
               for first-time is now used to change the text of the note
               printed on the SAS log to "RE-INITIALIZED" (and the new  
               DEFAULT value is printed) when VMXGINIT is re-executed.  
   Thanks to Derek Twist, CSC, AUSTRALIA.                               
Change 19.103  Support for StorageTek VSM NCS 4.0 ("HSC") enhancements  
FORMATS        for subtypes 13, 14, 18, and 19 add new variables, but   
VMACSTC        the record changes are INCOMPATIBLE (STCnnTIM is now 4   
Jun 11, 2001   bytes, vice 8, in different format), so this MXG change  
               is required for that version's SMF records.  New things: 
                Dataset   Variables   Description         FORMAT        
                STCVSM13  STC13RCI    RECALL INDICATOR       $MGSTCRC.  
                                          '01X:MOUNTED WITHOUT A RECALL'
                                          '02X:MOUNTED AFTER A RECALL'  
                          STC13MGT    MANAGEMENT CLASS                  
                STCVSM14  STC14MGT    MANAGEMENT CLASS                  
                STCVSM18  STC18MT     MIGRATE REQUEST TYPE   $MGSTCMT.  
                          STC18MGT    MANAGEMENT CLASS                  
                          STC18SCL    STORAGE CLASS                     
                STCVSM19  STC19RT     RECALL REQUEST TYPE    $MGSTCRT.  
                          STC19MGT    MANAGEMENT CLASS                  
                          STC19SCL    STORAGE CLASS                     
   Thanks to Martin Jensen, JyskeBank, DENMARK.                         
Change 19.102  Variable CPCMODEL ('ZX7' or 'Z77' for example) is added  
ASUM70PR       to PDB.ASUM70PR and PDB.ASUMCEC datasets to identify what
Jun 10, 2001   is the exact model of the platform.  This is important if
               a Z-series machine is an 'upgrade' from a G6, as the CPU 
               Serial Number does not change, even though the physical  
               hardware does.                                           
   Thanks to Chuck Hopf, MBNA, USA.                                     
Change 19.101  Variable PGMRNAME was removed from the KEEP= list for the
BUILD005       TYPE30_4 dataset in the BUILDPDB logic.  If a job had no 
BUIL3005       Purge record, the always-blank-PGMRNAME-in-TYPE30_4 would
Jun 10, 2001   blank out the PGMRNAME from the TYPE30_1 dataset.        
               See Change 19.194.                                       
   Thanks to Duncan Walker, Experian, ENGLAND.                          
Change 19.099  Syntax for Goal Mode no longer requires the -99 place    
VMXGRMFI       holder.                                                  
Jun  9, 2001                                                            
   Thanks to Larry Nova, COMSI, USA.                                    
======Changes thru 19.099 were in MXG 19.02 dated Jun  1, 2001======    
Change 19.098  First MXG 19.02 only.  Two lines were left from testing: 
VMXGRMFI       Lines 2398 and 2417:    IF SYSTEM='SYSA' THEN            
Jun  1, 2001   must be deleted.  This error caused PDB.RMFINTRV to have 
               many missing variables, including NRCPUS and PARTNCPU.   
======Changes thru 19.097 were in MXG 19.02 dated May 27, 2001======    
Change 19.097  Labels for two variables were confusing and are revised: 
   Thanks to Simon Everitt, NPI Financial Services, ENGLAND.            
Change 19.096  Variables SMF94IN4 and SMF94EX4 were not multiplied by a 
VMAC94         1024*1024, but now are (as were IN3 and EX3) to convert a
May 24, 2001   raw megabyte value back into bytes, so the MGBYTES format
               will correctly display these bytes-completed variables.  
   Thanks to David Bixler, Fiserv, USA.                                 
Change 19.095  EMC's InfoMover SMF records INFSTART and INFTIME are now 
VMACINMV       INPUT as &PIB.4.2; their bad values reported back in MXG 
May 24, 2001   Change 17.396 are now corrected to the normal SMF time   
               format, replacing the MXG circumvention that had &RB4.   
               and a divide by 150.                                     
   Thanks to Bob Bradley, United Airlines, USA.                         
Change 19.094  Documentation.  Variable DB2SRBTM is missing in DB2ACCT, 
VMACDB2        beginning with DB2 Version 6.1, and as documented by IBM 
May 23, 2001   and as noted in member ADOCDB2.  This note added so that 
               searching changess for DB2SRBTM will expose itself.      
               But as a result, if you have any reporting code that uses
               because the SAS assignment statement A=B+C will have A   
               missing if B or C are missing.  Instead, you must replace
               the assignment statement with a SUM() statement:         
               or, you could remove +DB2SRBTM from your equation.       
Change 19.093  Support for Release 5.06 (INCOMPATIBLE, in TYPE1082 data 
VMAC108        set, because DOMUNAME was expanded from 32 to 36 bytes). 
May 23, 2001   And new field DOMPRPID, Process ID, is added to TYPE108  
   Thanks to Wolfgang Vierling, Allianz, GERMANY.                       
Change 19.092  The PDB.ASUMUOW dataset is enhanced to now keep variable 
VMXGUOW        USERCHAR (the real transaction name of some transactions 
May 23, 2001   can be stored in the USERCHAR field). The first non-blank
May 25, 2001   (character) or non-missing (numeric) value is output. All
               CICS "ID" variables are now listed in new MACRO _KUOWIDC 
               so you can override and add additional "ID" variables.   
               The current list of "ID" variables from CICSTRAN is:     
               To add another variable, say CLIPADDR, you would code:   
                 %LET MACKEEP=                                          
                       MACRO _KUOWIDC                                   
                             CLIPADDR  %                                
               New macros _KUOWIDD and _KUOWIDDM for DB2 and MQ are now 
               defined as null, but can be used in future tailoring.    
               Option LISTALL=YES on the VMXGUOW invocation can be used 
               to identify which HOLDxxxx, FRSTxxxx, or LASTxxxx        
               variable is being used to retain/sum the values for which
               real variables in the data step that builds ASUMUOW.     
               If you really want to create observations in PDB.ASUMUOW 
               you can use this instream logic before your include:     
                  %LET MACKEEP=                                         
                             MACRO _NOOBS  %  MACRO _YESOBS %           
                  %INCLUDE SOURCLIB(ASUMUOW);                           
   Thanks to Alan Lankin, Towers Perrin, USA.                           
Change 19.091  An incorrect statement in format $MGFDROP was not caught 
FORMATS        by SAS, and caused no error, but should have.  The text  
May 23, 2001   '00'X'='00'X:OTHER (FDRABRM)' was corrected to now read  
               '00'X='00'X:OTHER (FDRABRM)'                             
   Thanks to Joseph J. Faska, Depository Trust, USA.                    
Change 19.090  Documentation.  Comments had the wrong IBM field name for
VMAC74         two variables.  Corrected field name in comments are:    
May 21, 2001       @45+OFFSMF LENDDSS       &PIB.2. /*SMF74DDL*/        
                   @47+OFFSMF NRDDSS        &PIB.2. /*SMF74DDN*/        
   Thanks to Michael Spencer, BMC Software, USA.                        
May 21, 2001   libraries are still created with half-track blocksize and
               SAS Institute will eventually eliminate the spurious     
               message; a SAS Usage Note will be created later.  The SAS
               defect was precipitated by a BLKSIZE(DASD)=HALF statement
               in MXG's CONFIGV8 member, and to circumvent the SAS error
               and eliminate the warning, I have replaced the statement 
               so as to still set the desired half track block size for 
               new SAS data libraries on DASD.                          
               You could make the WARNING go away by removing that      
               BLKSIZE(DASD)=HALF statement from CONFIGV8, but without  
               those device-specific half-track values being set in your
               CONFIGV8 member, you will instead get the SAS System     
               default value of 6144 that is set their SAS.CNTL(CONFIG) 
               member in your //CONFIG DD concatenation.                
                  SAS Institute still sets their default block size for 
                  new MVS SAS data libraries to 6144, because, for some 
                  SAS datasets that have INDEXes, the half-track block  
                  size may be sub-optimal, but specifically for MXG, and
                  in general for any data-intensive SAS application that
                  writes large volumes of SAS data that are sequentially
                  accessed and do NOT use SAS Indexes, a small 6144 byte
                  block size will waste massive amounts of CPU time, I/O
                  I/O time, cause unneeded EXCPs, SIOs, and waste real  
                  memory! And your DASD datasets at 6144 byte blocksize 
                  will also waste DASD space! You want your MXG-built   
                  SAS datasets to be built with half-track blocksize on 
   Thanks to John R. Myers, Vanguard, USA.                              
   Thanks to Tricia Henry, John Fairfax Holdings, AUSTRALIA.            
             and now others, but they reported it first!                
Change 19.088  Variable INITTIME in both TYPETMNT and TYPETALO were off 
VMACTMNT       by one full day starting March 1, 2001, because the MXG  
May 15, 2001   logic using YEARSEC did not protect for this year's leap 
               day, and because ASMTAPES does not get the century bit on
               when it copies these IBM fields.  The logic using YEARSEC
               was revised to force the century bit for INITTIME.       
   Thanks to Joan Nielsen, i-structure, USA                             
   Thanks to Mike Shapland, i-structure, USA.                           
Change 19.087  This contributed example sums up all of the CPU time for 
ANALUSS        a job using Unix System Services (USS) under MVS's OMVS  
May 15, 2001   (OpenEdition), as described by its author:               
               Jobs that call Unix System Services (USS) can have their 
               Unix work spawned to independant address spaces that are 
               started tasks.  OMVS creates the jobnames for these      
               address spaces by appending a 1-digit numeric suffix to  
               the jobname of the original job.  (Job ABCD will spawn   
               STC OMVS address spaces named ABCD1, ABCD2, etc).  Eight 
               character jobnames will spawn A/S's named the same as the
               job (e.g., ABCD5678 will spawn ABCD5678). There will     
               likely be more than one OMVS ASID per job, so the CPU for
               the USS work of a job will be in multiple type 30 records
               with different job names, numbers, and initiate times.   
               This program matches up those job records and sums up the
               CPU time for the job.  (The starting and ending time of  
               the USS tasks will be within the start/end time of the   
               originating job.)                                        
               The program makes these assumptions:                     
                1.  An 8-digit USS jobname could be spawned by either a 
                    7 or 8 digit job.  The code assumes the 8-digit USS 
                    job is spawned by an 8-digit job unless it's found  
                    to come from a 7-digit job.                         
                2.  We assume the job started yesterday.  This code     
                    could be removed or changed.                        
   Thanks to Alan Lankin, Towers Perrin, USA.                           
Change 19.086  JCL example still referenced &&SOURCLIB, but that temp   
ANALDSET       dataset is no longer created nor used in the revised JCL 
May 15, 2001   to analyze dataset activity from 14/15/64 and SMF 30s.   
   Thanks to Freddie Arie, TXU, USA.                                    
Change 19.085  TLMS date variables BAPURCH BACLNDT BACERTDT with invalid
VMACTLMS       julian day-value of zero (Packed field '0100000C'x in the
May 15, 2001   record) caused INVALID ARGUMENT FOR DATEJUL FUNCTION.    
Jul  6, 2001   This change tests the day value of those three fields and
               sets the date missing if the day value is zero.          
               Also, the value of BACTIME was not correctly converted to
               a time value but now is and is formatted as TIME8.       
               Jul 6: Variable BALUNIT was changed to BAIUNIT to match  
               the TLMS dsect name.                                     
   Thanks to Dietmar Lakemann, Rechenzentrum Verden GmbH, GERMANY.      
   Thanks to Ian Davies, Independent Consultant, CANADA.                
Change 19.084  MXG output observations in TYPE73 for channels that were 
VMAC73         offline (but with all zeros, the extra observations had  
May 15, 2001   no real impact), but they are no longer output.  The old 
               MXG logic had bit tests to protect for MVS/ESA 4.3 that  
               can now be removed, and the test to output TYPE73 now is:
                 IF ONLINE='Y' AND VALIDPTH='Y' THEN DO;                
               Also, variable SMF73BSY was added to the KEEP list, in   
               case it is needed for later re-calculation.              
               I was writing this update for ADOC73 to better document  
               that there are two, different, kinds of observations in  
               TYPE73, when I found the need for this change.           
               TYPE73 Contains Different types of Observations, based on
               the value of SMF73CMG, the CPMF Group:                   
               SMF73CMG = . or 0  ==>  old record, without extension    
                  PCHANBY calculated from SMF73BSY/NRSTCPS              
                  PNCHANBY calculated from SMF73PBY/SMF73PTI            
               SMF73CMG = 1    ==> CPMF=COMPAT                          
                  When present, variables SMF73TUT/SMF73PUT, the new    
                  durations when Total Channel Path, LPAR Channel Path  
                  was busy are INPUT (i.e., will be non-missing).       
                    PCHANBY re-calculated from SMF73TUT/SMF73PTI        
                    PNCHANBY re-calculated from SMF73PUT/SMF73PTI       
                  "Normal" TYPE73 record for ESCON channels, CTC's, etc.
                  FICON channels are reported upon, but only to the same
                  level of detail as other channel types.               
               SMF73CMG = 2    ==> CPMF=EXTENDED                        
                  This "new" extended subtype is currently written for  
                  OSD and FICON channels (SMF73CPD=11x:OSA DIRECT       
                  EXPRESS, SMF73CPD=1Cx:FICON BRIDGE).  It adds         
                  read/write/total byte counts for total/lpar from which
                  MXG creates four read/write rates in bytes/second:    
                 and re-calculates PCHANBY and PNCHANBY:                
                 and calculates the new "Bus Busy Percent" in PBUSBY    
                 (which is non-missing only in these SMF73CMG=2 obs).   
               Whether type 73 (and type 79-12) records contain CMG 1 or
               2 data is determined by the CPMF parameter of IEAOPTxx   
               member of PARMLIB.  CPMF=COMPAT produces MG1 format data 
               records and CPMF=EXTENDED produces the MG2 format record.
               Note that all TYPE73 observations have variables PCHANBY 
               and PNCHANBY calculated for Total/LPAR percent channel   
               busy measurements, so if you need seconds of busy time   
               you can calculate as BUSYTM= PCHANBY*DURATM/100;         
                 OBSERVATION COUNT CHANGE: TYPE73 fewer obs.            
   Thanks to David M. Kellerman, ADP, USA.                              
Change 19.083  MXG's creation of SMF70WLA and MSU4HRAV/MSUINTRV values  
VMXGRMFI       in PDB.RMFINTRV is wrong if you now have the new z/OS    
May 14, 2001   records that have SMF70WLA populated by IBM.  I thought  
May 16, 2001   SMF70WLA would contain the "this-system" MSU capacity in 
May 26, 2001   the type 70 record, so in records without that field, I  
               created SMF70WLA in PDB.RMFINTRV, and for a 1-way system 
               I set SMF70WLA=36 (the correct MSU capacity available to 
               that LPAR with one engine), but now I find that IBM puts 
               SMF70WLA=253 in their record, which is the "all-engine"  
               or total "image" MSU capacity of the CPC, the hardware   
               MSU capacity of the box.  Spinning was also corrected.   
                 *** NOTE: IBM NOW STORES THE LPAR CAPACITY VALUE, 36,  
                           AND NOT THE CPC MSU VALUE, 253.  THIS WAS    
                           APPARENTLY AN EARLY TEST SITE?               
                           SEE CHANGE 20.168.                           
               Since MXG generally never changes the value of IBM fields
               in IBM records (although sometimes "Sums" are converted  
               into "Averages", and labelled accordingly):              
                 - corrects the MXG value of SMF70WLA in PDB.RMFINTRV   
                   to contain the IBM value and the label now reads     
                 - and creates new variable ZOS70WLA in PDB.RMFINTRV    
                   to contain the value that you really want, the MSU   
                   capacity of this MVS System, so you can compare this 
                   MVS System's MSU usage (MSU4HRAV/MSUINTRV) with its  
                   MSU capacity (ZOS70WLA).  Both SMF70WLA and ZOS70WLA 
                   variables are kept in the PDB.RMFINTRV dataset       
               So now: NOTE: after Change 20.168:                       
                 SMF70WLA is the Defined Capacity of the LPAR           
                 ZOS70WLA is the same as SMF70WLA                       
                 MSU4HRAV is MXG's 4-hour average hourly MSU            
                 MSUINTRV is the MSU count for this RMF interval.       
                 SMF70LAC is IBM's 4-hour average hourly MSU            
   Thanks to Pat Curren, SuperValu Inc, USA.                            
Change 19.082  Support for HMF Subtypes 29, 30, and 31 create threee new
DIFFHMF        MXG datasets:                                            
EXTYHMFT         Subtype  "dddddd"  DATASET  Description                
EXTYHMFV           30      TYHMFU   TYPEHMFU CNT2 IFENTRY               
VMACHMF        Datasets TYPEHMFT and TYPEHMFU have accumulated counters 
VMXGINIT       so their sort macros _STYHMFT and _STYHMFU were added to 
May 14, 2001   the DIFFHMF member.                                      
   Thanks to Perry Lim, Union Bank of California, USA.                  
   Thanks to Theo Peelen, Rabobank, THE NETHERLANDS.                    
Change 19.081  Support for DB2 SMF 102 IFCID 096 was mis-aligned.  Field
VMAC102        QW0096WF should have been &PIB.4. instead of 2, and a two
May 10, 2001   byte reserved field was not input after QW0096RC.        
   Thanks to John Mourtgos, Albertsons, USA.                            
Change 19.080  NPM processing with TYPS28 invoked only _S028IN7 macro to
TYPS28         sort the NPMINPMT dataset; instead, it should invoke the 
May 10, 2001   _S28 macro so that all NPM datasets are sorted to the PDB
               DD name.                                                 
   Thanks to Sue Kemper, Universal City Studios, USA.                   
Change 19.079  JCL with comments to run ASUMUOW using batch pipes or    
JCLUOWP        pipes plex.  SAS Institute has enhanced their product at 
May  9, 2001   our request so that it interfaces with IBM's BatchPipes  
               product; this example shows how to use SAS and pipes to  
               significantly reduce run time and physical I/Os.  The SAS
               support for BatchPipes will be available in SAS Version 9
               but if there is enough demand to Technical Support at SAS
               for support, a "hot fix" for SAS 8.2 could be possible.  
               There are 3 jobs and they must all run concurrently.     
              -READDB2 reads the DB2 SMF data, and, using a view,       
               passes DB2ACCT to a SORT which outputs into the PIPE for 
               DB2ACCT and uses a pipe fitting to harden the DB2ACCT    
              -READCICS reads the CICSTRAN data and again, using a      
               view, passes the data the SORT which then  outputs into  
               the PIPE for CICSTRAN and hardens the CICSTRAN dataset.  
              -ASUMUOW uses the PIPEs from READDB2 and READCICS to read 
               the DB2ACCT and CICSTRAN datasets and create ASUMUOW.    
               Note the SPININ and SPIN DD usage in ASUMUOW allows the  
               SPIN dataset to be a GDG for ease of recovery.           
               The hardening via a pipe fitting is certainly optional   
               but does not materially affect the run, time. In theory, 
               when the sort of CICSTRAN ends, so does ASUMUOW.         
   Thanks to Chuck Hopf, MBNA, USA.                                     
Change 19.078  Truncated type 14 record caused INPUT STATEMENT EXCEEDED 
VMAC1415       error because MXG did not validate the real length with  
May  9, 2001   the length fields in the record.  This rare bad record is
               now detected and deleted with an MXG message but the rest
               of the SMF file will now be read.                        
   Thanks to Howard Unich                                               
Change 19.077  IBM made changes to the SMF 120 record (Websphere CB) and
VMAC120        now with actual records, the MXG design was revised, as  
May  9, 2001   only five datasets are now created:                      
May 11, 2001     TYP120CC - Container and Class information, from either
                            Subtype 2 (Container Activity) or Subtype 4 
                            (Container Interval).  Variable SM120STY can
                            be used to identify which event created the 
                            observation; the interval records will also 
                            have DURATM,SM120SST,SM120SET non-missing.  
                 TYP120CM - Class and Method information, from either   
                            Subtype 2 (Container Activity) or Subtype 4 
                            (Container Interval).  Variable SM120STY can
                            be used to identify which event created the 
                            observation; the interval records will also 
                            have DURATM,SM120SST,SM120SET non-missing.  
                 TYP120SA - Server Activity from subtype 1              
                 TYP120SC - Communications Session from subtype 1       
                 TYP120SI - Server Interval from subtype 3              
   Thanks to Martyn Jones, ABN AMRO, THE NETHERLANDS.                   
Change 19.076  The STRTTIME/ENDTIME values in CICSTRAN segments could be
VMAC110        later than the SMFTIME of the physical record; the MXG   
May  8, 2001   conversion from STCK(GMT) to LOCAL did not include the   
               Leap Seconds.  The revised equation is now:              
   Thanks to Ralph Alcorn, Safeway, USA.                                
Change 19.075  TSO/MON variables were input but not kept in TSOMCALL.   
VMACTSOM       These variables are now labeled and kept:                
                  TSMPTRAN TSMPURR                                      
               Variable TSMPURR=00x observations do not have counts in  
               the LONG, TRIV, or NONTRIV transaction counts; those     
               counts exist only if the '01'x bit is on in TSMPURR.     
   Thanks to Gerry Girard, Canadian Utilities, USA.                     
Change 19.074  KEEPALL=YES is now specified in the VMXGSUM invocation in
ASUMCICS       these ASUMxxxx members that are all included in JCLPDBx  
ASUMDB2A       examples.  Using KEEPALL=YES bypasses the execution of   
ASUMDB2B       many DATA steps by VMXGSUM, saving CPU time in these ASUM
ASUMJOBS       members.  (The prior KEEPALL=NO default caused steps to  
ASUMTMNT       be executed to build a KEEP= list that was used only for 
May  7, 2001   the INPUT dataset to prevent variable not found errors in
               subsequent PROC MEANS executions.)                       
              -In ASUMJOBS, IF JSTRTIME=. was changed to IF INITTIME=.  
               to eliminate jobs that did not initiate more robustly.   
Change 19.073  Support for DCOLLECT APAR OW48529 which documents the    
FORMATS        value of 3 for DSCAVAIL as "Continuous Preferred" so the 
Apr 18, 2001   MGDCODV format was updated to decode that value.         
   Thanks to Jim Petersen, HomeSide Lending, USA.                       
Change 19.072  USERADD=HSM, resulting in _IDHSM, but in VMACHSM the IF  
UTILBLDP       statement is looking for _IDHSMDS.                       
May  2, 2001   Also, COMPLETE has five macro names, now generated.      
   Thanks to Wayne Bell, National General Insurance Co., USA.           
Change 19.071  To allow for the override of _IDTMNT with IMACTMNT       
ASMFTAPE       Line 53 ( MACRO _IDTMNT 238 % ) must move before the     
Apr 26, 2001   %INCLUDE(VMACSMF,VMAC21,VMACTMNT);                       
   Thanks to Normand Poitras, IBM Global Services, USA.                 
Change 19.070  The _BTY78SP BY list for TYPE78SP was not complete enough
VMAC78         to remove duplicate records, so it was revised to be:    
MONTHBLx                       SUBPOOL %                                
APR 26, 2001   with the addition of SUBPOOL. Since TYPE78SP is optional 
               job-level subpool monitoring, this exposure is minimal,  
               but since TYPE78SP is a part of the BUILDPDB process, the
               BY lists for it in the WEEKBLDx and MONTBLx also had to  
               be updated.                                              
   Thanks to Iven Willy, Fortis Bank, ENGLAND                           
Change 19.069  The BY-list MACRO _BFDRDSF had DSNAME instead of FDRDSN  
VMACFDR        as the name of the variable, causing DSNAME NOT FOUND.   
TESSUSR1       Added TYPSFDR to test stream for _S, _B macros.          
Apr 26, 2001                                                            
   Thanks to David Ehresman, University of Louisville.                  
Change 19.068  Format $MG073CD for type 73 records was updated to       
FORMATS        include 23X Internal Coupling Peer.                      
Apr 12, 2001                                                            
   Thanks to Jerry Urbaniak, Acxiom CDC, USA.                           
Change 19.067  Preliminary support for BMC Mainview Batch Optimizer, BMO
TYPEMBO        that will replace HiperCache product.  BMO records quite 
Apr  6, 2001   different; code works but at Alpha test site now.        
   Thanks to Jim Petersen, HomeSide Lending, USA.                       
Change 19.066  GOPTIONS statement was mis-located; it should be located 
GRAFRMFI       after the %SYSPROD(GRAPH) statement.  Only impact was if 
Apr  6, 2001   you did not have SAS/GRAPH on your system.               
   Thanks to Art Hunter, Penn Mutual Life Insurance Company, USA.       
VMACNTSM       and PAGING FILE is now PAGINGFILE, both without the old  
Apr  6, 2001   blank, requiring the test for object name to             
               now look for either spelling.                            
   Thanks to Bob Gauthier, Albertsons, Inc, USA.                        
Change 19.064  Cosmetic, to avoid confusion.  In this example JCL for a 
JCLTREND       TRENDing, the DISP=OLD on //CICSTRAN and //WEEK is not   
Apr  6, 2001   needed, as both are input-only in that job, and so they  
               were changed to DISP=SHR.                                
   Thanks to Art Hunter, Penn Mutual Life Insurance Company, USA.       
Change 19.063  SAS Version 8.2 Spurious NOTE "might be uninitialized".  
VMXGWORL       Fortunately, there is no impact, other than the printing 
Apr  6, 2001   of several new NOTES on the SAS log, and SAS Technical   
Apr  9, 2001   Support now acknowledges the note should not have been   
Jun 11, 2001   printed and SAS be revised to recognize that NOBS will be
               initialized by the NOBS=NOBS parameter.                  
               The MXG change was to initialize the NOBS variable before
               the CALL to prevent the compiler notes.                  
               Read on, only if details interest you.                   
               Some of the new NOTES include these:                     
                  546: LINE AND COLUMN CANNOT BE DETERMINED             
                  HAS OCCURRED.                                         
               Enabling the SPOOL option did print the source statement,
               which was inside the VMXGWORL macro, which MXG uses to   
               figure out if observations are in "WorL", i.e., in the   
               "_W" OR the "_L" dataset macro.  That code:              
                  CALL SYMPUT('MXGOBS',NOBS);                           
                  SET CONTENTS NOBS=NOBS;                               
               is code originally recommended by SAS as a safe way to   
               set macro variable &MXGOBS non-zero if there are obs in  
               dataset "CONTENTS", to set it zero if there are 0 obs,   
               or to not-fail if there is no "CONTENTS" dataset.        
               The NOBS variable in our SYMPUT is uninitialized when the
               CALL SYMPUT is seen, but SET CONTENTS NOBS=NOBS populates
               variable NOBS, so MXG's logic works just fine.           
                  If we moved the CALL to be after the SET, NOBS would  
                  have been populated, but that logic won't work here:  
                    If the CALL is after the SET, the CALL statement    
                    won't be executed when there are zero observations  
                    in CONTENTS or when CONTENTS dataset doesn't exist. 
               SAS added this new "may be" note to correct a problem    
               where it an uninitialized variable was not identified,   
               but that fix unintentionally fired spuriously here, and  
               SAS will correct the compiler to recognize the NOBS=NOBS 
               will populate the CALL statement, even when the CALL is  
               seen before the SET statement.                           
               To eliminate the printing to these notes  SAS V8.2, MXG  
               simply added a compiler faker statement:                 
                 IF NOBS=. THEN NOBS=.;                                 
               before each of the two CALL SYMPUTs in member VMXGWORL   
               to satisfy the compiler's need for NOBS to appear in an  
               assignment statement; this will work now and when SAS has
               fixed the spurious NOTE.                                 
               11Jun01:  The extraneous %PUT statement was deleted:     
                 %PUT BARRY DEBUG &MXGLYES= &MXGWORL= &MXGOBS=;         
Change 19.062  MXG 19.01 only.  Change 19.059 introduced an error when  
VMACSOLV       temporary variable MONTH was changed to numeric.  Now, it
Apr  5, 2001   is reverted back to character but renamed MONTHSL.       
Change 19.061  IMS 01 records with the recovery bit on were deleted,    
ASMIMSL5       causing differences in observation counts in IMSSUMSO,   
ASMIMSL6       IMSMERGE, and NODTOKEN.  The Branch statement (at line   
Apr  5, 2001   1444 in ASMIMSL6, line 1415 in ASMIMSL5), following the  
               TM MSGFLAGS,MSGFNRQU statement, was commented out to     
               prevent the incorrect deletion of valid 01 records.      
               NOTE: JUL 11: This change was in error and was undone by 
               Change 19.135.                                           
======Changes thru 19.060 were in MXG 19.01 dated Apr  4, 2001======    
Change 19.060  Variable BLKSIZE in the optional TYPE30_D => PDB.DDSTATS 
VMACEXC1       dataset is wrong in OS/390 R2.10 and z/OS; I input the   
Apr  4, 2001   new 8-byte SMF30XBS as floating point with RB8, causing  
               values of -1E64 or +1E18, as the input should have been  
               binary &PIB.8.  However, IBM uses the first bit as a flag
               that the block size was changed, and then I re-discovered
               that SAS cannot store all digits of a field input as PIB8
               when the first bit is turned on:                         
                       X = '8000000000006D10'X;      /*hex literal */   
                       Y = INPUT (X,&PIB.8.);        /*input as binary*/
                       Z = MOD(Y,8000000000000000X); /*get the 6d10 */  
               returns z= 28762 under PC SAS,                           
                       z= 27904 under OS/390 SAS,                       
                   but z= 27920 is the correct value for '6D10'x.       
               so the actual INPUT was revised to use &PIB.7.           
               Fortunately, BLKSIZE/MULTSIZE variables are rarely used. 
   Thanks to Rob Gibson, CentreLink, AUSTRALIA.                         
Change 19.059  Compiling of all MXG members that process SMF records has
VMACF127       uncovered a few conflicts where variables are defined as 
VMACLDMS       numeric in one record and character in another record.   
VMACMOUN       Renaming the variable in the more-seldom-used product    
VMACDECS       eliminate the possible exposure.                         
VMACRMDS       VMACF127 - Not-kept DEVNUM renamed.                      
VMACROSC       VMACLDMS - JESNR is now a numeric variable.              
VMACSOLV       VMACMOUN - Variable UCBTYPE is now a numeric variable.   
VMACAIMR       VMACDECS - Variable DSORG now DSORGDEC.                  
VMACLMS        VMACRMDS - Not-kept RECSEQNO renamed.                    
VMAC102        VMACROSC - Not-kept DELETE renamed.                      
VMACHBUF       VMACSOLV - Not-kept YYYY now numeric.                    
VMAC90         VMACAIMR - Not-kept YY1-SS1 and YY2-SS2 now YY-SS.       
VMAC90A        VMACORAC - Not-kept Reserved variables renamed.          
Apr  4, 2001   VMACLMS  - Not-kept DSTYPE renamed to DSTEMPTY.          
               VMAC102  - Not-kept VALUE renamed VALUE4BY.              
               VMACHBUF - RECTYPE renamed RECTYPEC.                     
               VMAC90   - Not-kept DOMFLAG renamed.                     
               VMAC90A  - DOMFLG renamed DOMFLG90.                      
Change 19.058  If you changed the PDB2ACC default from PDB to DB2ACCT,  
JCLTEST6       the JCL TEST programs failed, because MXG had failed to  
JCLTEST8       provide a //DB2ACCT DD statement in some steps.          
Apr  4, 2001                                                            
   Thanks to Jesse Gonzales, Gap Inc, USA.                              
======Changes thru 19.057 were in MXG 19.01 dated Apr  3, 2001======    
Change 19.057  The NTCONFIG dataset only recorded model/speed/etc for   
Mar 31, 2001   variables exist for 32 processors.                       
   Thanks to Bob Gauthier, Albersons, Inc, USA.                         
Change 19.056  Protection for invalid ALOCTIME in type 30 records, while
VMAC30         IBM investigates the cause.  Step records with ALOCTIME  
Mar 31, 2001   that is a fraction of a second earlier than the INITTIME 
               are not possible (steps initiate first, then allocate,   
               and then load), but are written by OS/390 R2.10.  The    
               MXG logic must compare those times to determine the step 
               ALOCDATE and LOADDATE (because ALOC/LOAD have only times 
               with no dates in type 30s), and it concluded "INIT Today,
               ALOC Tomorrow" when the ALOC Time was earlier than INIT. 
               The IBM error of the earlier ALOC time causes MXG to add 
               one day to the ALOCTIME variable, which then caused the  
               DSENQTM to be 23:59 hh:mm, ALOCTM to be -23:59, and the  
               EXECTM could also be very large, positive or negative.   
               Knowing that it will take IBM time to diagnose and fix   
               their eror, I have revised the MXG logic to be smarter.  
               Now, if the INITDATE and TERMDATE are the same, then the 
               ALOCDATE and LOADDATE are known so the "date bump" logic 
               is bypassed (all seen observations fell into this case). 
               So only when the TERMDATE is a day or more later than the
               INITDATE will the INITTIME, ALOCTIME (and LOADTIME) be   
               tested, and their dates are now bumped only if the delta 
               is more than 5 seconds, so small errors in the time value
               in the SMF record won't cause the algorithm to misfire.  
               Note Sep 25, 2001:  IBM APAR OW50134 acknowledges their  
               error, but that APAR resolution is "FIN", Fixed in Next. 
   Thanks to Andrew Hebden, Barclays, ENGLAND.                          
Change 19.055 -Change 18.233 documented new SYNC59 parameter, but it was
VMXGDUR        actually added until this change.  SYNC59 argument values
VMXGSUM        can be:                                                  
Mar 30, 2001      N - do nothing.                                       
                  Y - add 1 Minute to time                              
                  nnn - add nnn  minutes to time                        
               and a null value is the same as N.                       
              -Additionally, a typo for TEMP02 option that caused error 
               FILE DDD.MXGSUM1.VIEW IS SEQUENTIAL when TEMP02 was used 
               was corrected.                                           
   Thanks to Karen Florup, Fidelity Investments, USA.                   
Change 19.054  MXG 18.10-18.18.  MXG creates duplicate observations in  
VMAC115        MQ-Series dataset MQMMSGDM, because there were duplicate 
Mar 29, 2001   _ETY1152 macro executions.  Delete the first invocation  
               of _ETY1152 macro (line 598), leaving one at line 639.   
                 OBSERVATION COUNT CHANGE: MQMMSGDM fewer obs.          
   Thanks to Jun dela Rosa, U.S. Customs Service, USA.                  
Change 19.053  TCP SMF118 ERROR.4. HFS FILE TWO NAME ERROR message may  
VMACTCP        be created-in-error, if the second HFS filename is first 
Mar 29, 2001   in the SMF record.  MXG protection logic (for invalid    
               offset values) tested IF COL LE ... (which assumed that  
               COL would increase as the record was read.  But now that 
               records with the physical positions reversed are found,  
               changing those tests to  IF 205 LE ... will protect for  
               invalid offsets, and let MXG find the name segments in   
               whatever order IBM writes them in their SMF record.      
               The only impact of this error was that one or both HFS   
               filenames would be blank.                                
               Apr 9, 2003: IBM APAR PQ73030 will correct the offsets,  
               which should only be non-zero for a RENAME event.        
   Thanks to Bruce Widlund, Merrill Consultants, USA.                   
Change 19.052  INVALID DATA for MOUNSMND/MOUNEMND occurs if those dates 
VMACMOUN       are nulls; one pair of PD4 INPUT was protected with "??",
Mar 29, 2001   but now all PD4 INPUTs are protected.                    
   Thanks to Normand Poitras, IBM Global Services, CANADA.              
Change 19.051  Support for APAR OW46622 identifies Address Spaces that  
VMAC79         have Temporal Affinity (see also OW45238).  No code was  
Mar 28, 2001   changed, since R791FLG and R792FLG variables already are 
               input and kept, and bit 7 ('.......1'B) is the flag.     
Change 19.050  Support for Landmark's The Monitor for IMS V1.1 records. 
EXTIMCH        Use TYPSTIMS to create and deaccumulate these datasets:  
EXTIMCJ         TIMSCH    History Statistics                            
EXTIMCJD        TIMSCJ    Transaction Statistics                        
EXTIMCK         TIMSCJD   Transaction Statistics - Detail               
EXTIMCKD        TIMSCK    Database Statistics                           
EXTIMCL         TIMSCKD   Database Statistics - Detail                  
EXTIMCL1        TIMSCL    Buffer Statistics                             
EXTIMCL2        TIMSCL1   Buffer Statistics - First Pools               
EXTIMCL3        TIMSCL2   Buffer Statistics - Second Pools              
EXTIMCM         TIMSCL3   Buffer Statistics - Third Pools               
EXTIMCN         TIMSCM    Input Messages                                
EXTIMCO         TIMSCN    Interval Statistics                           
EXTIMCP         TIMSCO    Output Messages                               
EXTIMCT         TIMSCP    PSB Completion                                
EXTIMCU         TIMSCT    Thread Termination                            
EXTIMCUD        TIMSCU    PST Statistics                                
EXTIMCX         TIMSCUD   PST Statistics - Detail                       
IMACTIMS        TIMSCX    Exception Alerts                              
TYPETIMS       Use the INFILE name of MONITIMS for the Landmark records.
VMACTIMS       If your data records are compressed, Assemble and install
VMXGINIT       member EXITMON6, an "Infile Exit" for SAS V6/V8, that can
Mar 28, 2001   read the compressed records.  See comments in EXITMON6.  
Apr  1, 2001                                                            
               All above datasets have been created, and unexpected and 
               unwanted accumulated counters were found, so that you    
               must use member TYPSTIMS to first write to //WORK and    
               then SORT/Deaccumulate into the //PDB library.           
               Detection of accumulated fields requires non-zero values,
               and some of the fields in the test data were zero, so you
               need to use PROC MEANS MIN ; to examine each dataset for 
               negative minimum (improper deaccum) or large minimum     
               (variable that probably should be deaccumulated).        
                 TIMSCU: CUMSGOQ and CUPWAIT are occasionally negative  
                         and some timestamps are always missing.        
   Thanks to Warren Waid, J. C. Penny Company Inc, USA.                 
Change 19.049  Using JCLTEST8, warnings about CODEPASS option was       
JCLTEST8       printed, because the instream proc still referenced the  
Mar 27, 2001   (CONFIG) member instead of (CONFIGV8) for SAS V8.        
   Thanks to Art Hunter, Penn Mutual, USA.                              
Change 19.048  Variable STC11CSP should have been input as &PIB2.2 so   
VMACSTC        that its value is 20 for a 20 MegaByte/Sec Channel Speed.
Mar 27, 2001                                                            
   Thanks to Chuck Hopf, MBNA, USA.                                     
Change 19.047  Support for optional CICS TCP/IP timings and counts from 
IMACICDA       the EZA01 segment adds ten variables to the CICSTRAN     
IMACICEZ       dataset, but ONLY if you remove the comment block in the 
IMAC110        IMACICEZ member.  You need to also run UTILCICS to see   
Mar 26, 2001   where the EZA01 segment was added, and may have to change
               the expected order of segments in member IMACICDA.       
   Thanks to Andreas von Imhof, Rabobank, THE NETHERLANDS.              
Change 19.046  Support for IMS Version 7.1 IMS Log Records is almost    
VMACIMS        compatible; only the '40'x log record was incompatibly   
Mar 26, 2001   changed (and it is needed only if he message queue was   
               built), based on documentation review of the log DSECTS. 
               Some additional fields are now decoded, but no new       
               variables were added to the existing log record datasets.
   Thanks to Engelbert Smets, Provinzial Versicherungen, GERMANY.       
Change 19.045  Variable VERSNRMF was kept in most, but not all, RMF/CMF 
VMAC7072       datasets, but is now kept in TYPE70PR/7204/72SC/78PA and 
VMAC78         TYPE78SP datasets.                                       
Mar 26, 2001                                                            
   Thanks to Ian Davies, Independent Consultant, CANADA.                
Change 19.044  NETSPY type 'R' records caused INPUT STATEMENT EXCEEDED  
VMACNSPY       because MXG expected 89 bytes, but NETSPY 5.3 creates a  
Mar 26, 2001   type R record of only 77 bytes, so the three fields that 
               were added (NSPYBPQU NSPYBPST NSPYRNLP) are now input if 
   Thanks to Reuben de Leeuwe, IZB, GERMANY.                            
VMAC42         for type 42 subtype 5 record. This particular subtype has
Mar 26, 2001   internal offset variables, and the MXG logic looped on   
Mar 27, 2001   those offset variables (instead of looping on the count  
               field, as these internal segments have no count field),  
               but the MXG logic to convert from IBM offset value to the
               SAS byte location:   OFFzzzz=OFFzzzz-3+OFFSMF;  was      
               being executed even when OFFzzzz=0, causing OFFzzzz=1    
               when a VSAM subtype 5 was read (OFFSMF=4 for VSAM SMF).  
               Now,   IF OFFzzzz GT 0 THEN OFFzzzz=OFFzzzz-3+OFFSMF;    
               logic protects for the input zero value with VSAM input. 
               (BSAM SMF has OFFSMF=0, so it produced OFFxxxx=-3 if the 
               input value was zero, but since the subsequent MXG logic 
               tests IF OFFxxxx GT 0 THEN DO;  so the segment was not   
               input when not present with BSAM dumped SMF input).      
   Thanks to Ken Williams, IBM Global Services, ENGLAND.                
   Thanks to Mark Williams, Marks and Spencer, ENGLAND.                 
Change 19.042  Variables XMGMXT, XMGPAT, and XMGPQT should have been in 
VMXGCICI       a MAX= argument instead of the SUM= argument in the first
Mar 26, 2001   %VMXGSUM invocation.  Their values were incorrect in the 
               PDB.CICINTRV dataset.                                    
   Thanks to Brian Hawthorne, MONY Life Insurance Company, USA.         
Change 19.041  Support for APAR II12xxx clarifies documentation of the  
VMAC50         VTAM type 50 record.                                     
Mar 23, 2001                                                            
Change 19.040  If a file spanned more than five volumes, the VOLSERs in 
VMACCTLG       CTLGDSN dataset were overlaid with the subsequent VOLSER;
Mar 23, 2001   (i.e., VOLSER1='BARRY6' instead of 'BARRY1' if 6 vols).  
   Thanks to Gordy Rogers, Principal Financial Group, USA.              
Change 19.039  Error: INVALID ARGUMENT TO SQRT FUNCTION is corrected;   
ANALUOW        small negative values due to rounding caused the error.  
Mar 22, 2001                                                            
   Thanks to Ed Long, FMR, USA.                                         
Change 19.038  Change 18.286 corrected 1.024 to 1024 for SMF30JQT/RQT/  
VMAC30         HQT/SQT, but ENCLACTM should also have been corrected to 
Mar 22, 2001   use 1024 instead of 1.024 as the multiplier.             
   Thanks to Alan Freed, ADP, USA.                                      
Change 19.037  Format MG060ID for type 60 records was updated from the  
FORMATS        SMF manual; several UNKNOWNs are now known.              
Mar 19, 2001                                                            
   Thanks to Chuck Hopf, MBNA, USA.                                     
Change 19.036  Variable ABENDS in PDB.JOBS counts each OMVS/USS pseudo  
BUILD005       step record as an abend.  Change 10.325 set variable     
BUIL3005       ABEND='OMVSEX' to identify each pseudo step record       
Mar 17, 2001   (created when an OMVS/USS address space is "dubbed"), but
               Change 16.183, which added variable ABENDS to PDB.JOBS,  
               should have skipped over these steps.  The test in       
               BUILD005 to count abends was revised to now read:        
                  IF ABEND NE: '  ' AND ABEND NE:'OMVSEX'               
                  AND ABEND NE: 'FLUSH' THEN DO;                        
               This error also could cause ABEND to be blank when it    
               should not have been, if the job had both pseudo steps   
               and other real steps that did have abends or returns.    
   Thanks to Rex Pommier, Western Surety Company, USA.                  
Change 19.035  New values for format MGSTCLB for variable STC07LBL are  
FORMATS        added:                                                   
Mar 16, 2001             /* $MGSTCLB FORMAT FOR VMACSTC */              
                VALUE $MGSTCLB                                          
                 '1'='1:VERIFY LABEL VOLSER (IGNORE MEDIA)'             
                 '2'='2:VERIFY UNLABELED CARTRIDGE (IGNORE MEDIA)'      
                 '3'='3:BYPASS VOLSER AND MEDIA LABEL CHECK'            
                 '4'='4:RECOVERY CARTRIGE NUMBER SPECIFIED'             
                 '5'='5:VERIFY MEDIA TYPE, BYPASS VOLSER CHECK'         
                 '6'='6:VERIFY MEDIA TYPE AND VOLSER'                   
                 '7'='7:VERIFY MEDIA TYPE AND UNREADABLE VOLSER'        
   Thanks to Martin Jensen, Jyskebank, DENMARK.                         
Change 19.034  Support for TNG for SOL260S records added.  The SOL260S  
VMACTNG        records seem to be the same as SOL240S, so both formats  
Mar 16, 2001   will create the same SOnnn Solaris TNG MXG datasets.     
   Thanks to Paul Hargreaves, SEMA, ENGLAND.                            
Change 19.033  Documentation/example only.  No code change was made.    
CONFIGV8       If you want to change the global MXG Default "PDB" DDNAME
VMXGINIT       to something else, for example "MXG" because that's what 
Mar 14, 2001   someone before you did, you should NOT make the change by
               EDITing the VMXGINIT member, because that member changes 
               with every MXG version to GLOBAL all MXG macro variables,
               and you would have to re-tailor every time you install a 
               new MXG version.  Instead, you can change the DEFAULT=PDB
               to DEFAULT=MXG by EDITing a USERID.SOURCLIB(CONFIGV8),   
               and changing  the statement that invokes %VMXGINIT:      
               to set the DEFAULT=MXG:                                  
               The CONFIGV8 member is one that sites may choose to EDIT,
               since some of those options are site choices, but it does
               not typically change between MXG versions, and it is the 
               intended location for any changes to the %VMXGINIT parms.
               Further note: there should never be members starting with
               VMAC nor VMXG in your USERID.SOURCLIBs, except as interim
               corrections until you install the next MXG version.  Old 
               VMAC/VMXG members in your tailoring libraries can cause  
               ABENDs, and require re-tailoring with each new Version.  
               They should always be removed when the new version is    
               installed, and all MXG tailoring can be put in the MXG   
               exit members or in your //SYSIN input stream, so you     
               never have to change your changes.                       
               And while I'm in tutorial mode, if you have tailored any 
               VMXG members into your USERID.SOURCLIB, you probably did 
               it because you wanted to change the default arguments,   
               and you found how to make it work.  But that is not the  
               correct way to %MACROs should be used.  Instead of EDIT  
               of the VMXGxxxx member that defines the %MACRO %VMXGxxxx,
               you simply EDIT the invocation of the %VMXGxxxx macro,   
               and change the parameter value there.  For a specific    
               example, member RMFINTRV is where the statement that     
               invokes the execution of %VMXGRMFI macro is located, to  
               create PDB.RMFINTRV dataset.  To change workloads, etc., 
               you would EDIT the existing %VMXGRMFI                    
               %VMXGRMFI statement in your RMFINTRV                     
               member in USERID.SOURCLIB(RMFINTRV), adding the new parm:
               In this manner, never editing the VMXG/VMAC members, the 
               install of a new MXG version means that you never have to
               retrofit your MXG tailoring.                             
   Thanks to Jerry J. Lentz, State of Arizona, USA.                     
Change 19.032  INPUT STATEMENT EXCEEDED RECORD for Shadow Direct subtype
VMACSHDW       06 record; the record says there was 417 bytes of SQL    
Mar 14, 2001   text, but there were only 256 bytes of data, so the logic
               to parse the SQL text into 100 byte chunks was revised to
               use LENLEFT=MIN((LENGTH-COL+1,SM06SQLN) to control the   
               length of text bytes read.                               
   Thanks to Chris Morgan, IBM Integrated Technology Services, ENGLAND. 
Change 19.031  The CHAIN logic in processing IMF IMS transactions was   
VMACCIMS       revised by this user-contributed enhancement. When IMS   
Mar 14, 2001   transactions are chained, the IMF record for the second  
               and subsequent transactions contain the arrival time of  
               the original transaction, which produced incorrect input 
               queue time measures. The CHAIN algorithm sorted thru the 
               chain and reset the arrival time of the second to the end
               time of the preceding.   But the original algorithm was  
               redesigned by Wolfgang:                                  
               - When transactions were started before the prior        
                 transaction had finished, the RESPNSTM was cumulative; 
                 that is corrected, and noted in new variables NEGTIME  
                 and NEGCNT (kept only so you can see the impact of the 
                 enhancement to see how wrong prior values were!).      
               - Data Steps 2 and 3 were removed, coding was moved into 
                 the last step, reducing the execution and CPU time, I/O
                 and work space required.                               
   Thanks to Wolfgang Vierling, AGIS GmbH, GERMANY.                     
Change 19.030  If your OS/390 was back level and did not have OW37565   
VMAC7072       (flags ICF CPUs) MXG logic added in Change 19.015 caused 
Mar 13, 2001   LPARCPUS=0 in TYPE70PR and missing data in ASUM70PR.  The
Nov 15, 2001   logic now confirms the APAR is installed by checking the 
               NRCIXGT0 field before using SMF70CIX to id an ICF CPU.   
               Note added Nov 15, 2001:   LPARCPUS=0 was a symptom here 
               because it was always zero AND caused missing data in the
               ASUM70PR dataset, in that specific environment.  After   
               this change, it is still normal to have observations in  
               TYPE70PR with LPARCPUS=0: those with LPARNAME='PHYSICAL',
               or with SMF70CIN='ICF', or with LCPUADDR=. (for inactive 
               LPARs) will have LPARCPUS=0, and that's okay.            
   Thanks to Joe Montana, Acxiom, USA.                                  
Change 19.029  Support for Tandem G06/G07/G08 TANCPU & TANDISK records. 
VMACTAND      -New fields were added to the end of the TANCPU record,   
Mar 13, 2001   and variable DISKIOSF is now input as DISKIOS because it 
               is just the 8-byte DISKIOS field.  The calculation of    
               rates was moved to the end of the TANCPU logic.          
               Code is in place for G06, G07, and G08 changes, but only 
               G06 with LRECL=770 has been validated.                   
              -New fields were added to end of TANDISK record.          
               Code is in place for G06, G07, and G08 changes, but only 
               G06 with LRECL=746 has been validated.                   
   Thanks to Patricia A. Wingfield, Bank of America, USA.               
Change 19.028  Variables DSGPERCT and DS1PERCT-DS6PERCT in PDB.CICDS are
VMAC110        are not interval TCB Busy percent, as labeled, but are   
Mar 12, 2001   the instantaneous value at the end of interval, which can
               be quite different from the actual TCB Percent Busy:     
                  Hour        03  06  09  12  15  18                    
                  DSGPERCT:   88  74  88  77  69  19                    
                  AVGPERCT:   22  70  58  65  64  40                    
               IBM doesn't create DSxPERCT fields for the newer TCBs.   
               The PDB.CICINTRV dataset has all 11 TCBs DSnPERCT values 
               and all are recalculated (DSGPERCT=100*DSGACT/DURATM) so 
               they do match their label in the PDB.CICINTRV dataset.   
               The only change was to add "AT END" to the labels for the
               7 TCB variables DSGPERCT-DS6PERCT in the PDB.CICDS data  
   Thanks to Normand Poitras, IBM Global Services, CANADA.              
Change 19.027  Duplicate DB2ACCT records created by IBM Parallel Trans  
EXDB2ACC       are now deleted, but without this change, you will have  
VMACDB2        duplicate DB2 accounting, negative DB2TCBTM, missing     
VMXGUOW        ELAPSTM, and these strange values in your DB2ACCT data:  
Mar 12, 2001     QWACESC 01JAN1900:02:00:00  QWACEJST less than a second
Jun  5, 2001     QWACBSC 05JUN2001:19:20:21  QWACBJST minutes           
               The double accounting was introduced by IBM in DB2 APARS 
               PQ22260,PQ22451,PQ10864,PW06968,PQ45496 but it sure was  
               not obvious from the text of those APARs.  The end result
               is that, now, when DB2 parallelism is used, instead of   
               writing many individual child records, IBM "rolls up"    
               (sums) all child records into a single record, but that  
               record now is a duplicate of the previously existing     
               parent record.  IBM finally documented how to identify   
               and delete these duplicate DB2ACCT records:  New MXG     
               bit flag variable QWACPARR is now created                
                 IF QWACFLGS='.........1......'B THEN QWACPARR='Y';     
                 ELSE                                 QWACPARR=' ';     
               to identify these "rolled up" records, and the statement:
                 IF DB2PARTY='P' AND QWACPARR='Y' THEN DELETE;          
               was added in the EXDB2ACC exit member so that MXG will   
               delete this duplicate data.                              
               Note: That IF/DELETE statement was a circumvention and it
                     was removed from all exits by Change 22.121.       
               Additionally, VMXGUOW was similarly updated so ASUMUOW   
               will also delete the dupes, and it could be re-run       
               against existing DB2ACCT/CICSTRAN data to re-build       
               PDB.ASUMUOW without duplicates.  Normally, I am reluctant
               to delete any SMF data, but this duplication is so       
               obscure and could be so impacting, that I chose to delete
               them in MXG to prevent their accidental introduction into
               DB2ACCT (and ASUMUOW), which are used for DB2 billing.  I
               am not aware of any other data in these records which    
               justifies keeping them, but since the logic was added in 
               the Exit, you could easily change it to create these     
               rolled-up data records, if needed.                       
               This note's documentation was enhanced Jun 5, but no code
               was changed.                                             
   Thanks to Being Hwang, DOA, State of Wisconsin, USA.                 
   Thanks to Gunther Vogt, Audi AG, GERMANY.                            
Change 19.026  ASUMV14 summarizes STK VTS dismount records to get total 
ASUMV14        bytes compressed and uncompressed and the compression    
ASUMV11        ratio.  ASUMV11 summarizes STCVSM11 to the QTR hour too  
Mar 10, 2001   get the back end channel busy for STK VSM.               
               Note that the STCVSM11 dataset must be selected from only
               one system; each system connected to the VSM writes what 
               are effectively duplicate records, at slightly different 
   Thanks to Chuck Hopf, MBNA, USA.                                     
Change 19.025  CICS CPU time captured in CICSTRAN/CICDS/TYPE30/TYPE72 is
ADOC110        now docummented in member ADOC110.  This change adds the 
VMAC110        variables QRCPUTTM, MSCPUTTM and KY8CPUTM, which already 
VMXGCICI       exist in the CICSTRAN dataset, to the CICDS Dispatcher   
Mar 10, 2001   Statistics dataset and to the CICINTRV summary dataset.  
Change 19.024  Cosmetic.  Status variables DVLCSMSS DVLCSMS2-DVLCSMS8   
VMACDCOL       are now formatted with existing MGDCOVS format, as were  
Mar  8, 2001   variables DVLSMSS DVLSMSS2-DVLSMSS8.                     
   Thanks to Jim Horne, Lowe's Companies, USA.                          
Change 19.023  Change 19.015 removed NRCPUS from TYPE70PR dataset; this 
ANALRMFR       change revises the RMF reporting to match that change.   
Mar  6, 2001                                                            
Change 19.022  The First SQL Page Number QW0006PN, a 3-byte character to
ANALDB2R       display up to 999, was replaced by QW0006PG, a numeric,  
Mar  6, 2001   so now the '1ST PAGE' value for large values will print. 
   Thanks to Andrew Schmid, EDS Canberra, AUSTRALIA.                    
Change 19.021  If the rarely used TEMP01 and TEMP02 options of VMXGSUM  
VMXGSUM        are used, and TEMP02 is tape format, there will be a SAS 
Mar  6, 2001   error attempting to open two datases on a tape.          
   Thanks to Khoan Dang, MBNA, USA.                                     
VMXGRMFI       NOT FOUND.  The default, PDB=PDB, worked fine.  The test 
Mar  6, 2001    %ELSE %IF &PDB=PDB %THEN %DO;   was changed to now read:
                %IF &PDB=PDB OR &PDB=SMF %THEN %DO;                     
   Thanks to Wayne A. Schumack, Blue Cross of Minnesota, USA.           
Change 19.019  INPUT EXCEEDED RECORD LENGTH SMF 102 subtype 140 because 
VMAC102        new fields INCOMPATIBLY inserted by DB2 5.1 were not read
Mar  5, 2001   in for this Audit Trace record subtype.                  
   Thanks to Brad Dorn, Kohl's, USA.                                    
Change 19.018  Protection for zero-divide in new z/OS variable SMF70CPA,
VMAC7072       (no actual error in the MXG output, only a hex dump print
Mar  5, 2001   on the SAS log) because OS/390 2.10 unexpectedly writes  
               SMF type 70 records with LENCPUC=40, (2.10 doc says 28). 
               If LENCPUC GE 40, MXG Inputs SMF70CPA/SMF70WLA/SMF70LAC  
               (new MSU capacity stuff) and then divided without testing
               the denominator before the divide, and the new fields are
               all zero in the R2.10 extended segment.  And MXG expected
               SMF70WLA to be missing if the record did not contain that
               new MSU capacity measure, using IF SMF70WLA=. THEN DO... 
               logic in VMXGRMFI to detect its presence, so this change 
               also forces SMF70WLA=. if it is found to contain zeroes. 
   Thanks to Alan Freed, Automatic Data Processing, USA.                
Change 19.017  Support for APAR OW46268 for TYPE74 USS Kernel data was  
VMAC74         already in place; incorrect format and documentation was 
Mar  5, 2001   recognized during MXG validation of those fields.        
Change 19.016  Cosmetic.  The A2THID=UPCASE(AUTHID) should have been    
ANALDB2R       AUTHID (only impact would be if you typed selection names
Mar  1, 2001   in lower case, and none would have been selected).  Three
               repeated  IF AUTHID=:'   ' THEN AUTHID='   ' "compiler   
               fakers" were redundant and were deleted.                 
   Thanks to Tom Parker, CSC Hogan Systems, USA.                        
Change 19.015  If you have 2064 (z900) CPU with ICF-s installed, and    
ASUM70PR       do not have the PTF for APAR OW48190 installed, the count
VMAC7072       of ICF-s will be incorrect, causing incorrect CPU busy.  
VMXGRMFI       Without that APAR (no PTF until April), the IBM type 70  
Mar  1, 2001   70 field SMF70CIX does NOT properly flag ICF CPUs, so the
Mar  6, 2001   PARTNCPU and LPARCPUS variables that count real CPs will 
               be wrong in TYPE70, TYPE70PR, ASUM70PR, and RMFINTRV, and
               MSU4HRAV will also be incorrect.  This change completely 
               revises how ICFs are counted, moving that logic from the 
               ASUM70PR back into VMAC7072 so all four datasets above   
               will be correct, and this change corrects the count with 
               logic that works whether or not you have installed the   
               PTF for OW48190.                                         
               Caveat:  You must use VMAC7072, VMXGRMFI, and ASUM70PR   
               from this change; make sure you do not have any of those 
               three members in your "USERID.SOURCLIB" (or if you do,   
               you must re-tailor your changes into these new members). 
               First, the code loops thru the type 70 PR/SM segments to 
               count the number of non-zero values of SMF70CIX.  If the 
               count is always zero, then APAR OW37565 (which populates 
               SMF70CIX with 1 for "CP" and 2 for "ICF") is not on this 
               system, so ICF's can't be counted.  A non-zero value in  
               NRCIXGT0 proves the SMF70CIX field is valid, and IFCs can
               be counted, and then I can recognize an invalid value of 
               zero in SMF70CIX is really an ICF, as that is the IBM    
               error that will be fixed by OW48190s PTF: SMF70CIX had a 
               zero instead of a 2 for an ICF.  This allows MXG to count
               and remove ICFs from the PARTNCPU count of CPs in a box. 
               However, the variable PARTNCPU in TYPE70 and TYPE70PR did
               include ICFs; it was only in PDB.ASUM70PR/PDB.RMFINTRV   
               that both PARTNCPU and LPARCPUS were corrected for ICFs. 
               This change now corrects all four datasets, so the logic 
               in ASUM70PR (which both creates PDB.ASUM70PR and updates 
               PDB.RMFINTRV) was revised to no longer subtract ICFs.    
               Note also that VMXGRMFI at Change 19.012 is also neeeded 
               to support the 2064 processors, independent of this fix, 
               for variable MSU4HRAV valid on 2064s, so it is listed    
               here as well to alert you to use all three new memgers.  
              -Variable NRCPUS was removed from TYPE70PR, because it did
               not belong there; LPARCPUS is the correct variable that  
               counts CPs in this LPAR, while NRCPUS is a TYPE70-only   
               variable that counted the CPUs in the SYSTEM that wrote  
               this type 70 record, and NRCPUS in TYPE70PR could be     
               misleading and/or confusing.                             
              -Mar 6 additions.  The summarization interval in ASUM70PR 
               and RMFINTRV is set in member IMACRMFI's macro _DURSET   
               definition; by default, each original interval is output.
               If you change the interval of your PDB.RMFINTRV data:    
               a. You can tailor your own RMFINTRV member, using        
                  but then you have to change the _DURSET definition in 
                  your IMACRMFI member to set variable STARTIME hourly: 
                  because member ASUM70PR not only created PDB.ASUM70PR 
                  using _DURSET, but also then reads and rewrites the   
                  PDB.RMFINTRV dataset (adding Platform Busy, Percent of
                  Hardware, etc., variables), so, instead,              
               b. Leave the default INTERVAL=DURSET, in the RMFINTRV    
                  member (if you still need one), and just tailor the   
                  STARTIME value in member IMACRMFI.                    
               c. Watch for a possible re-design to make it consistent. 
   Thanks to Pat Curren, SuperValu Inc, USA.                            
Change 19.014  The original text of this change (about CPUTM in CICSTRAN
VMAC110        possibly being the sum of many variables) was wrong; the 
Feb 23, 2001   MXG equation for billable CPU time in CICSTRAN:          
Mar 12, 2001     CPUTM=SUM(TASCPUTM,CPURLSTM).                          
               has always been correct and should not be changed.       
               See member ADOC110 for the new note on CPU capture in the
               CICSTRAN, CICDS/CICINTRV, SMFINTRV and TYPE72/72GO data, 
               which provides a schematic of what's captured where.     
   Thanks to Trevor A. Holland, TELSTRA, AUSTRALIA.                     
Change 19.013  Support for TLMS Release 5.5 (COMPATIBLE).  Two new      
VMACTLMS       variables, BACUNIT (Create Unit) and BALUNIT (Last Unit) 
Feb 23, 2001   were added compatibly at the end of the record; both of  
               these new fields were actually added back in Release 5.4.
   Thanks to Jon Whitcomb, Great Lakes Higher Education Corp, USA.      
Change 19.012  Change 18.348 created QWACALOG/AWCL/AWAR/OCSE/SLSE/DSSE/ 
ASUMDB2A       OTSE/IXLT from QWAX variables, but did so incorrectly,   
VMACDB2        they were not formatted as TIME12, and ASUMDB2A was not  
Feb 23, 2001   revised to include the QWACs instead of the QWAXs.       
Apr  4, 2001   Line 105 in 18.18's ASUMDB2A was removed to eliminate the
               "duplicate variables" message (but it had no impact).    
   Thanks to Chris Weston, SAS Institute ITSV, USA.                     
Change 19.011  MXG 18.18 only, new variables only.  Incorrect SUBSTR()  
VMXGRMFI       argument caused CPCNRCPU to be missing, CPFCNAME could   
Feb 19, 2001   have extraneous characters, CPUTYPE='2064'x was not found
Mar  1, 2001   in the MG070CP table because CPCMODE3='404040'x should be
               removed.  The correct block of code now reads:           
                  IF CPUSTUFO NE CPUSTUFI THEN DO;                      
                    CPCMSU  =INPUT(SUBSTR(CPUSTUFO,1,4),4.);            
               No change was made to the logic in member FORMATS that   
               creates the MG070CP format, but comments that describe   
               that format's format were revised to match the format.   
               Note: This correction only applied if the FORMAT was     
                     used.  If SMF70WLA was populated, the FORMAT is    
                     not used.  But Change 20.168 is then needed.       
   Thanks to Pat Curren, SuperValu Inc, USA.                            
Change 19.010  The FTPREPLY character variable contains '000000FA'x, but
VMACTCP        is converted by this change to ' 250', its numeric value 
Feb 19, 2001   in a character variable, by inserting this statement     
               and by changing the input from $EBCDIC4. to $CHAR4. to   
               prevent conversion of the binary value.                  
                  Using $CHAR versus $EBCDIC under OS/390 doesn't matter
                  here, but under ASCII, leaving the $EBCDIC4. informat 
                  would convert any binary value that happened to be a  
                  valid EBCDIC character into its ASCII equivalent:     
                   (eg: '0000C1FA'x becomes '000041FA'x when INPUT with 
                    $EBCDIC4. informat under ASCII SAS.)                
               Now the Reply values for the Client (FTPREPLY) will be in
               the same format as the Server (FTPRSRSR) reply.          
Change 19.009  Support for CA/TNG post-9907 (INCOMPAT).  The initial MXG
VMACTNG        support was for the "old" data records, which had simple 
Feb 19, 2001   data format, but CA's complete revision (with internal   
               version 6 or higher), with its base-36 counting and with 
               repeat-count counters, is now supported with this change.
   Thanks to Roman Jost, Gjensidige, NORWAY.                            
Change 19.008  Variable SYNCNAME was added to the KEEP= for IMS597 so   
VMACIMSA       that variable PROGRAM will be populated in Fast Path     
Feb 19, 2001   dataset.                                                 
   Thanks to Bruce Widlund, Merrill Consultants, USA.                   
Change 19.007  MXG 18.18 only. The BY statement in _SHPSUGL was missing 
VMACMWSU       its ending semicolon, and the extra semicolon at the end 
VMACMWUX       of MACRO _BHPUXDS was removed.                           
Feb 19, 2001                                                            
Change 19.006  The calculation of RDHITPCT in TYPE42DS was incorrect in 
VMAC42         the denominator; the revised equation is:                
               The previous denominator was just CACHCAND and the value 
               calculated was too low.                                  
   Thanks to Ep van der ES, Dow Chemicals, BELGIUM.                     
Change 19.005  NTSMF files that have been COPYed and APPENDed without   
VMACNTSM       the /B parameter (search NEWSLTRS) and/or concatenated on
Feb 16, 2001   MVS have been found with a record of nulls (hex zeroes)  
               that MXG did not expect.  This change detects and deletes
               those records, printing a message that these bad records 
               were found in your input.                                
   Thanks to Howard Glastetter, Weyerhaeuser, USA.                      
Change 19.004  SAS does not permit an ARRAY name to be the same as a    
VMACSYNC       variable name; a new ARRAY named DD defined in VMACSYNC  
Feb 16, 2001   conflicted with a variable named DD in VMACRMDS, (only   
               if you tailored MXG to process both RMDS and SYNCSORT SMF
               records in the same MXG datastep).  Changing the ARRAY   
               names in VMACSYNC transparently corrects the conflict.   
   Thanks to Chris Weston, SAS Institute ITSV, USA.                     
Change 19.003  IMS Version 7 requires Omegamon/IMS V500, but Candle says
TYPEITRF       the upgrade from V300 to V500 is transparent as far as   
Feb 14, 2001   their ITRF data records are concerned.                   
   Thanks to Gene Quinn, Blue Cross of Rhode Island, USA                
Change 19.002  Two new VGETxxx %MACROs were included in MXG 18.18 but   
VGETENG        they (and the new VGETxxx prefix) were not documented.   
VGETOBS        %MACROS that "Get" and return a value are named VGETxxx, 
VMXGENG        and the value "got" is returned in a macro variable that 
Feb 14, 2001   is named VGETxxx.  The two new implementations are:      
                Executing                     Will return               
                %VGETENG(DDNAME=yyyyyyyy);    The Name of the SAS Engine
                                              that created that yyyyyyyy
                                              data library, in &VGETENG.
                                              (Needed by MXG so we can  
                                               exploit V8 features.)    
               %VGETOBS(DDNAME=,DATASET=);   The number of observations 
                                              in dataset DDNAME.DATASET 
                                              in &VGETOBS.              
               The earlier %VMXGENG macro still exists for compatibility
               but it now invokes %VGETENG.                             
   Thanks to Chuck Hopf, MBNA, USA.                                     
Change 19.001  The _BTY30UV BY list in VMAC30 was not quite the same as 
VMAC30         the order needed in BUILDPDB, and was corrected to be:   
                              DESCENDING INTBTIME MULTIDD EXTRADD  %    
               (Note that SMFTIME is appended during the initial NODUP  
               sort in _STY30UV sort, but is not needed subsequently.)  
   Thanks to Barry McQueen, Department of Defence, Australia.           
LASTCHANGE: Version 19.