MXG Version 22.22 is  dated Feb  1, 2005, thru Change 22.378   
Early    MXG Version 22.22 was dated Jan 22, 2005, thru Change 22.366   
         MXG Version 22.13 was dated Jan 13, 2005, thru Change 22.350   
First    MXG Version 22.13 was dated Jan 12, 2005, thru Change 22.345   
Final    MXG Version 22.12 was dated Dec 11, 2004, thru Change 22.316   
Second   MXG Version 22.12 was dated Dec 10, 2004, thru Change 22.313   
First    MXG Version 22.12 was dated Dec  2, 2004, thru Change 22.308   
         MXG Version 22.11 was dated Oct 26, 2004, thru Change 22.277   
         MXG Version 22.10 was dated Oct 13, 2004, thru Change 22.264   
         MXG Version 22.09 was dated Aug 25, 2004, thru Change 22.227   
Final    MXG Version 22.08 was dated Aug 20, 2004, thru Change 22.219   
Second   MXG Version 22.08 was dated Aug 13, 2004, thru Change 22.207   
First    MXG Version 22.08 was dated Aug 12, 2004, thru Change 22.205   
Final    MXG Version 22.07 was dated Jul 25, 2004, thru Change 22.180   
         MXG Version 22.07 was dated Jul 23, 2004, thru Change 22.177   
         MXG Version 22.06 was dated Jun 15, 2004, thru Change 22.129   
         MXG Version 22.05 was dated May 22, 2004, thru Change 22.108   
         MXG Version 22.04 was dated May  2, 2004, thru Change 22.099   
         MXG Version 22.03 was dated Apr  5, 2004, thru Change 22.066   
First    MXG Version 22.03 was dated Apr  2, 2004, thru Change 22.063   
         MXG Version 22.02 was dated Mar 24, 2004, thru Change 22.055   
         MXG Version 22.01 was dated Mar 11, 2004, thru Change 22.036   
First    MXG Version 22.01 was dated Mar 10, 2004, thru Change 22.034   
Final    MXG Version 21.21 was dated Feb 11, 2004, thru Change 21.320   
         MXG Newsletter FORTY-FOUR was dated Feb 11, 2004.              
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 22.22 is now available upon request.         
II.   Incompatibilities and Installation of MXG 22.13.                  
III.  Online Documentation of MXG Software.                             
IV.   Changes Log                                                       
I.  MXG Software Version 22.22 is available upon request.               
    Major enhancements added in MXG 22.22                               
  BUILDPDB 22.365  BUILDPDB now sets Condition/Return code of zero.     
  ASUMMIPS 22.354  Interval Capacity by Workload, MIPS and MSU used.    
  TYPE110  22.359  Support for CICS/TS 3.1 with no EXCLUDEd fields.     
  TYPE7072 22.349  Negative PCTMVSBY/CPUMVSTM/SHORTCPs, SMF70CNF bit 6. 
  TYPE30   22.375  IBM error in CPUIFATM, MXG error in SRVTCBTM.        
  TYPETPF  22.374  Support for MQ Series in TPF operating system.       
  TYPEQACS 22.371  Support for OS/400 5.3.0, new QAPMSYS dataset.       
  TYPEVMXA 22.369  Support for z/VM 4.4 and 5.1 new data (INCOMPATIBLE).
    Major enhancements added in MXG 22.13                               
  BUILDPDB 22.342  TYPE115/TYPE116 are now in BUILDPDB, will cause error
                   if you have already tailored MXG to add 115/116s.    
                   You must remove your 115/116 tailoring from EXPDBxxx 
                   or you will get this error message if you miss this: 
                     ERROR: DATA SET WORK.MQMLOG IS ALREADY OPEN ....   
  BUILDPDB 22.320  MULTIDD='Y' obs now combined in PDB.SMFINTRV.        
  BUILDPDB 22.326  Variable CPUCEPTM now deaccum in PDB.SMFINTRV.       
  TYPE110  22.312  Support for CICS/TS 3.1 (INCOMPATIBLE).              
  UTILEXCL 22.350  Support for CICS/TS 3.1 new fields, errors fixed.    
  ASUMUOW  22.336  MQMACCT/MQMACCTQ data can be added to PDB.ASUMUOW    
  TYPE70   22.325  "Short CPs" variable SHORTCPS created in TYPE70.     
  TYPE70PR 22.325  "Short CPs" variable SHORTCPS created in TYPE70PR.   
  TYPETNG  22.339  Major TNG enhancement - array sizes dynamically set. 
  TYPE74   22.334  Support for APAR OA06476 type 74 subtype 5 and 8.    
  ONLYINTV 22.326  Example to build only PDB.SMFINTRV/PDB.TYPE30_6.     
  TYPE6    22.321  Support for second format type 6 PrintWay record.    
  TYPE7072 22.340  Revision to support for varying IFAs online/offline. 
  IMAC6ESS 22.332  Support for GEPARMKY 0036, 0041, 0043, fix 0034x.    
  TYPEHIOM 22.331  Support for hIOmon File I/O Performance Monitor.     
                    This is a Windows environment monitor that tracks   
                    I/O activity to the filename and user.              
  MONTHDSK 22.343  "MONTHBLD" program to build MONTHLY PDB on disk.     
    Major enhancements added in MXG 22.12                               
      MXG 22.12 corrects IRD errors introduced in MXG 22.10/22.11.      
      MXG 22.12 corrects TYPE6 errors introduced in MXG 22.10/22.10.    
  TYPE6    22.309  Final correction for type 6 INPUT EXCEEDED errors.   
  TYPE6    22.298  SMF 6 STOPOVER on PrintWay section - missing @;      
  TYPE7072 22.307  Negative CPU values for IRD - Required CHANGE.       
  TYPEHURN 22.304  Support for ObjectStar subtype 45 Page Sweep.        
  TYPE6    22.302  Support for VPS V1 R8.0 VPS-FAX data                 
  TYPE102  22.294  Support for APAR PQ73385,PQ91101 for IFCIDs 217, 225 
  TYPE102  22.294  Support for APAR PQ87848 for IFCID 173               
  TYPECIMS 22.314  Support for Mainview IMS IMF 4.1.00 (NO CHANGES!).   
  TYPENSPY 22.312  Support for NetSpy Version 7.0 (COMPATIBLE).         
  TYPEQACS 22.311  Support for OS/400 5.3.0 CONF/DISK/POLL/JOBL data.   
  ASMRMFV  22.316  Enhanced support for RMF III VSAM files.             
  TYPETNG  22.291  Support TNG NT Platforms NTW400I, WNS502I, ZPP501I.  
  VMACSMF  22.300  Use of FTP access to read SMF MVS-to-MVS supported.  
  ASUM70PR 22.293  LP0xxxxx variables now populated with PHYSICAL's data
  CICINTRV 22.288  Comments show how to create PDB.CICINTRV from SMF.   
  VMXGPRAL 22.287  Enhancement to use PROC FREQ, example for 102 "who". 
  TYPE80A  22.286  Numerous enhancements, multiple RACF segments, etc.  
  ANALSIZE 22.276  Utility to analyze size of SAS data libraries.       
  ASUM70PR 22.274  Vars TOTSHARE/TOTSHARC kept for orig/current weights.
    Major enhancements added in MXG 22.11                               
     MXG 22.11 is NOW required for z/OS 1.6 with IFA/zAAPs, and it HAS  
     been tested with SMF 30, 70, and 72s from a system with real IFAs! 
       MXG 22.09 and MXG 22.10 do correctly support z/OS 1.6 without any
       zAAP engines, but actual test data uncovered MXG errors and IBM  
       undocumented fields (Changes 22.272, 22.262, 22.265) that caused 
       most of the IFA/IFE fields to contain invalid values.            
     Additional enhancements in 22.11:                                  
  TYPE30   22.272  Support for zAAP IFA engines.                        
  TYPE7072 22.272  Support for zAAP IFA engines.                        
  TYPE30   22.265  Support for APAR OA09118, adds CPUCOEFF to SMF 30s.  
  TYPE94   22.268  Support for VTS R7.3 additional statistics.          
  TYPECMF  22.266  Support for CMF Version 5504 User SMF (INCOMPAT).    
  VMACDB2H 22.270  22.08-22.10 only. DB2 V8.1 INPUT STATEMENT EXCEEDED. 
  TYPE71   22.269  22.07-22.10 only. LPAxxxx variables missing values.  
    Major enhancements added in MXG 22.10                               
     MXG 22.10 supports z/OS 1.6, but only if there are no IFA engines. 
     Additional enhancements in 22.10:                                  
  TYPE7072 22.260  Support for z/OS 1.6 WITH IFA engines.               
  TYPEVMXA 22.240  Support for z/VM 4.4, INCOMPAT.                      
  TYPENTSM 22.246  Support for NTSMF Release 2.4.7 COMPATIBLE.          
  TYPEXAM  22.245  Support for XAMAP Release 3.4 INCOMPAT.              
  TYPETDSL 22.249  Support for TDSLink product's user SMF record.       
  TYPEBETA 22.250  Support for BETA93 Release 3.5 subtypes 0-5.         
  TYPETMDB 22.235  Support for ASG/Landmark TMON for DB2 V4.0 (COMPAT)  
  SYSLOG   22.238  Preliminary support for SYSLOG file.                 
  ANALGART 22.242  Example analysis for Gartner Group requests.         
  ASUMCIMS 22.241  Example summarization of the four IMF datasets.      
  ERRORASC 22.239  ASCII platform errors when incorrect SMF download.   
  ANALFLSH 22.236  New member tracks concurrent flash copies executing. 
  TRND.... 22.258  Symbolics &TRENDINP,&TRENDNEW,&TRENDOLD added.       
    Major enhancements added in MXG 22.09                               
     MXG 22.09 supports z/OS 1.6, but only if there are no IFA engines. 
     See Change 22.221 and especially MVS Technical Notes in NEWSLTRS.  
    Major enhancements added in MXG 22.08                               
     MXG 22.08 is required for safe execution with SAS V9.1.2 or V9.1.3.
     While MXG 22.07 had critical revisions for SAS 9.1.2, more design  
     changes were discovered in V9.1.2 that required more MXG changes.  
      In addition, Syncsort's add-on product PROC SYNCSORT was found to 
      corrupt INFORMATs, causing fatal errors in BUILDPDB, but because  
      I could remove all MXG INFORMAT statements faster than they could 
      even examine their error, I believe you can safely use that add-on
      with MXG code (but you'll need to check your own code for INFORMAT
      and watch for their eventual revised version that will work with  
      SAS V9.1.2).  Note, the errors are in the PROC SYNCSORT add-on    
      product (which prints "PROC SYNCSORT" on your SAS log if used).   
      We have not seen these errors with the Syncsort Sort product.     
      The Syncsort ticket number # SR387805 is open for PROC SYNCSORT.  
     The details of the MXG changes that support V 9.1.2 and V 9.1.3 are
     in the change text of the below MXG changes, but for execution of  
     MXG under "MVS", the only critical changes required are to:        
     - Install MXG 22.08 and use MXGSASV9 and CONFIGV9 from 22.08, and  
     - Run the UTILS2ER utility against all of your source libraries to 
       see if any lines of your SAS programs conflict with S2=72 option 
       that was required to replace the previous S2=0 option in MXG.    
     Changes related to SAS V9.1.2 and MXG execution:                   
  CONFIGV9 22.207  NOTHREADS specified for 9.1.2 error, fixed in 9.1.3. 
    (the NOTHREADS change caused the Aug 13 re-date of MXG 22.08!),     
  CONFIGV9 22.108  CRITICAL Hot Fix SN-012437 Required for SAS V9.1.2   
  CONFIGV9 22.123  SAS V9 on MVS VB INCOMPAT: S2=72 must be S2=0.       
  MXGSASV9 22.130  Revised MXG JCL example for SAS V9, NLS names, etc.  
  MXGSASV9 22.126  SAS dsnames must be "W0", w-zero, not w-oh.          
  CONFIGV9 22.108  Support for V6SEQ under SAS V9.1                     
  UTILS2ER 22.123  Utility to detect errors with S2=0 in your programs. 
  FLASH    22.108  CRITICAL SAS Hot Fix SN-012437 is REQUIRED for V9.1.2
  Many     22.184  SAS V9.1.2 $VARYING design change protected.         
  AUTOEXEU 22.102 file for unix, protects SASAUTOS error. 
  Some     22.108  Support for SAS V9.1 and V6SEQ without Hot Fix.      
  Many     22.192  Protection for PROC SYNCSORT error with SAS V9.1.2   
    Additional important enhancements in MXG 22.08:                     
  TYPETMO2 22.191  Support for ASG/TMON TCE for CICS/ESA 2.3, COMPATIBLE
  Many     22.180  Support for IFA CPU variables for zAAP processors.   
  Many     22.177  Update to define MACRO _Vdddddd for numeric SMF plus.
  Many     22.192  All INFORMAT $NOTRAN statements were removed.        
  TYPEIMS7 22.199  Major revision to IMS0708 dataset, all events output.
  VMACDB2H 22.196  Support for extended length DB2 id variables.        
  TYPENTSM 22.193  Support for NTSMF Exchange/Outlook/DTS CPU objects.  
  TYPENTSM 22.190  Support for NTSMF MicroStrategy Server objects.      
  TYPEOMVT 22.186  Omegamon/VTAM V520 IRNUM 29 Divide by zero corrected.
  TYPE80A  22.185  Invalid SMF 80 Extended Relocate Section protected.  
  ANALRMFR 22.181  Enhancements to RMF reporting.                       
  ADOC110  22.189  Major updated added 1300 lines of CICS documentation.
  Note: The Aug 20 re-date of MXG 22.08 was made only because it was    
        easy to do; I discovered that members were missing from the     
        3480 tapes (not from ftp nor CD-rom shipments) and so I chose   
        to create replacement tapes with the added changes that were    
        made during the week.                                           
    Major enhancements added in MXG 22.07                               
  TYPE7072 22.152  Support for IFA Processors, APAR OA05731.            
  TYPE7072 22.137  Support for z890 CPUTYPE 2086, OS/390-INCOMPAT.      
  TYPE74   22.141  Support for RMF 74 subtype 8 ESS Link Stats record.  
  TYPETNG  22.170  Support for TNG Windows Server 2003 new objects+fix. 
  IMACICHO 22.169  Hogan optional CICS data member now exists           
  TYPEHMF  22.168  Support for HMF V2.7 new subtypes, compatible.       
  TYPEHPDM 22.166  Support for STK ExHPDM user SMF record.              
  BUILDPDB 22.165  BUILDPDB detects overlapped SMF data previously read.
  IMAC6ESS 22.161  Support for ESS GEPARMKY 003Bx and 0045x fields.     
  TYPETNG  22.160  REGION reduced for JCLTEST8 TESTOTHR due to TYPETNG. 
  UTILBLDP 22.149  Enhancement supports subtype selection in ZEROOBS.   
  VGETENG  22.148  Enhancement to get Engine and Device Type of LIBNAME 
  ASUM42DS 22.147  Performance enhancement reduce I/O, CPU  using view. 
  TYPE119  22.146  TYP119nn datasets had GMT time zone, now have local. 
  JCLRMF   22.143  Example to create "RMF-only" PDB from SMF data.      
  ASUMUOW  22.139  Variables APPLID/USER/LUNAME/TERMINAL incorrect.     
  ANAL4GB  22.138  Revised to use DCOLLECT to detect large VSAM files.  
  IEFU84   22.136  SMF exit to get Initiator Name and Number for jobs.  
  ASUM70PR 22.135  MVS System Name of each LPAR, SMF70STN, added.       
  TYPE70   22.134  Percent when each engine online PCTONLN0-PCTONLNX.   
  TYPENDM  22.133  Support for several additional NDM-CDI subtypes.     
  TYPENSPY 22.131  TYPENSPY and TYPENETM combined, only one SMF record. 
  TYPENETM 22.131  TYPENSPY and TYPENETM combined, only one SMF record. 
  MXGSASV9 22.130  Revised MXG JCL example for SAS V9, NLS names, etc.  
  UTILCONT 22.175  Utility to Inventory the Megabyte Sizes of PDBs.     
    Major enhancements added in MXG 22.06                               
       Really major:                                                    
        Change 22.123 -  SAS V9 on "MVS" INCOMPAT due to RECFM=VB on the
                         SAS-supplied SASMACRO library requires the MXG 
                         default S2=72 be changed to S2=0, which itself 
                         raises another potential incompatibility in SAS
                         programs, so new UTILS2ER must be run against  
                         your SAS programs before migration to SAS V9,  
                         or your programs may have strange ABENDs.  See 
                         extensive discussion in text of Change.        
        Change 22.121 -  CPU time for DB2 Parallel Trans was not output 
                         (i.e., lost, could be very large) in DB2ACCT.  
                         See the Change text, and also the DB2 Technical
                         Note in Newsletter FORTY-FIVE.                 
  CONFIGV9 22.123  SAS V9 on MVS VB INCOMPAT: S2=72 must be S2=0.       
  UTILS2ER 22.123  Utility to detect errors with S2=0 in your programs. 
  TYPEDB2  22.121  DB2 Parallel CPU time lost, not output in DB2ACCT.   
  TYPEDB2  22.124  MXG 22.04-05, QWHSSTCK missing in SMF 102 trace data.
  EXDB2ACC 22.121  DB2 Parallel CPU time lost, not output in DB2ACCT.   
  TYPEIPAC 22.125  Support for IPAC subtype 5 IPAC05 corrections.       
  IMAC6ESS 22.117  Support for optional ESS segment GEPARMKY=003Bx.     
  BUILDPDB 22.115  JES3 PDB only; wrong TYPE26J3 used in BUILDPD3.      
  TYPE102G 22.109  TYPE102G to read DB2 Trace written to GTF didn't.    
  BLDIMPDB 22.128  ASCII equivalent of JCL for JCLIMSLx execution.      
  TYPEIMSA 22.113  ASCII execution only, APPLID not readable.           
  ANALFIOE 22.127  Run time improvement if SMF, instead of PDB, input.  
  BLDSMPDB 22.111  unix case sensitivity corrections                    
  BLDNTPDB 22.111  unix case sensitivity corrections                    
  MXGSASV9 22.126  SAS dsnames must be "W0", w-zero, not w-oh.          
    Major enhancements added in MXG 22.05                               
  CONFIGV9 22.108  Support for V6SEQ under SAS V9.1                     
  FLASH    22.108  CRITICAL SAS Hot Fix SN-012437 is REQUIRED for V9.1.2
  TYPE102C 22.104  Support for Candle Omegamon II for DB2 IFCID Trace.  
  AUTOEXEU 22.102 file for unix, protects SASAUTOS error. 
    Major enhancements added in MXG 22.04                               
  TYPE110  22.094  Support for CICS/TS 2.3 with no EXCLUDEd fields.     
                   (If you use UTILEXCL with your CICS/TS 2.3 data,     
                    there was no error, but CICSTRAN without IMACEXCL   
                    was wrong if all fields were present in 110-1.)     
  TYPEQACS 22.095  Support for OS/400 5.2 QAPMMIOP record new fields.   
  TYPETNG  22.085  Support for NT objects SESSION and USER in TNG cubes.
  TYPEAIX  22.083  Support for AIX PTX new objects.                     
  TYPEIBSM 22.079  Support for IBM Session Manager user SMF record.     
  TYPETPMX 22.077  Support for alternative multiple-ACCT field TPM data.
  TYPE74   22.075  Support for 1024 structures in Coupling Facility.    
  UTILEXCL 22.068  Support for optional RMI data in CICSTRAN.           
  VMXGINIT 22.096  Macro variables &MACINTV and &MAC30DD created.       
  TYPEDB2  22.090  MXG 22.02-22.03 only. QWHSSTCK 1960 date in DB2ACCT. 
  TYPEDB2  22.084  Large QBSTGET in DB2STATB due to DB2 restart fixed.  
  TYPE70   22.087  Non-PR/SM, IORATE/PCTTPI variables too low.          
  TYPE7072 22.072  TYPE72GO with R723CWMN GT 0, Periods not output.     
  MONTHASC 22.064  Example "MONTHBLD" for ASCII systems.                
  AUTOEXEC 22.064  LIBNAME DUMMY added to support MONTHASC.             
    Major enhancements added in MXG 22.03                               
    Revision of ThruPut Manager TYPETPMX to not use ARRAYS to save CPU. 
     (34 new datasets); Change 22.060.                                  
    Major enhancements added in MXG 22.02                               
    If you are using IRD, you must install MXG 22.12 or later:          
      (This note originally said MXG 22.02, but now, Change 22.307 in   
       MXG 22.12 is required for IRD values to be correct!)             
  --Full Support for IRD (Intelligent Resource Director) is now in all  
    CPU-related datasets.  IRD support was incremental in MXG:          
            Datasets            When        MXG Version  Change         
          ASUM70PR/ASUMCEC   Sep 22, 2003     21.05      21.170         
          TYPE70PR           Mar 11, 2004     22.01      22.011         
          TYPE70,RMFINTRV    Dec  2, 2005     22.12      22.307         
    PCTCPUBY in TYPE70 and RMFINTRV were wrong in any interval when IRD 
    varied CPUs offline.  I'm embarrassed, since PCTCPUBY is the second 
    most important variable in all of MXG (CPUTM for billing is the most
    important); this is the first PCTCPUBY error in MXG's history!  When
    all engines remained online, however, there was no error.           
  BUILDPDB 22.052  PDB.STEPS can have wrong EXCP,IOTM,TAPExxxx values,  
                   but only in rare circumstance of identical INITTIMEs.
  RMFINTRV 22.050  Variable PCTCPUBY wrong in RMFINTRV when IRD active. 
  TYPE70   22.050  Variable PCTCPUBY wrong in TYPE70 when IRD is active.
  DB2STATB 22.045  Negative QBSTGET, other QBSTxxx, when 4-byte wrapped.
  TYPEDB2  22.042  DB2 Stats records not written in subtype order.      
  ANALALL  22.040  Example now can write all SMF for selected job(s).   
  ASMTAPEE 22.038  ML-31 of MXGTMNT corrects GMT, MSC APAR support.     
    Major enhancements added in MXG 22.01                               
  VMXGRMFI 22.017  BUILDPDB run time elongation, if output is to tape.  
                   Circumvention: USE FREE=CLOSE on tape DDs. See text. 
  TYPE117  22.029  Support for SMF 117 WBIMB WebSphere Business Integrat
  TYPE82   22.005  Support for SMF 82 Crypto subtypes 14 thru 19.       
  TYPEENDV 22.032  Support for Endeavor Release 4.0, INCOMPATIBLE.      
  TYPEHURN 22.006  Support for Huron/Object Star additional subtypes.   
  TYPESMSX 22.030  Support for DF/SMS Storage Class Exit User SMF record
  Many     22.018  Hardcoded "SPIN" DDname now &SPININ,&SPINOUT macros. 
  TYPE120  22.014  WebSphere SMF 120s had GMT for many timestamps.      
  TYPE30   22.022  Variable SRVTCBTM,SRVSRBTM,CPUTOTTM created in TYPE30
  TYPETPMX 22.008  (Final?) revisions to internal Thruput array names.  
  TYPE30   22.021  Job delays SMF30HQT/JQT/RQT/SQT revisions.           
  See member NEWSLTRS or the Newsletters frame at for       
  current MXG Technical Notes that used to be in CHANGES.               
  All of these enhancements are described in the Change Log, below.     
    SAS Version requirement information:                                
      MXG 22.08 or later is REQUIRED for SAS V9.1.2 or V9.1.3; see      
      "Major Enhancements in MXG 22.08" in CHANGES for details.         
      MXG executes best under the most recent SAS Version, with all     
      Critical HotFixes installed by your SAS Installer:                
       For SAS V9.1 or V9.1.2 on z/OS:                                  
        SN-013514 is REQUIRED to be able to read datasets that were     
          created by V6SEQ (tape) engine.                               
        SN-012437 is REQUIRED to prevent creation of corrupt/unreadable 
          datasets with V7SEQ,V8SEQ, or V9SEQ.                          
        Both fixes ARE included in SAS V9.1.3; earlier MXG notes that   
          they were required for 9.1.3 are wrong.                       
       For SAS Version 8.2, HotFix Bundle 82BX08 is REQUIRED to be safe.
       Sequential Engine Status:                                        
          V9SEQ is fixed in V9.1.3; it would be my default in CONFIGV9, 
            but I can't tell that you are at V9.1.3, and because V9SEQ  
            was badly broken prior to 9.1.3, I still have to use V6SEQ  
            and MXG's default in CONFIGV9.  You should change to V9SEQ  
            in CONFIGV9 if you have installed SAS V9.1.3.               
          V6SEQ, if used under V9.1.2, requires SN-013514.              
          V8SEQ was always safe under SAS V8.2, but it wasted CPU time  
            by always compressing when writing in tape format.          
      MXG New Version QA tests are executed on z/OS with SAS V9.1.3 and 
      V8.2, and on (archaic) V6.09, and on Windows XP with SAS V9.1.3.  
      Previous tests of MXG Software have been run with SAS V9.1.2, SAS 
      V8.2 and V9.1 with Linux RH8 on Intel, with V9.1 on Solaris v2.8  
      model v880, and V9.1 on HP-UX v11.11 model rp5470, confirming full
      compatibility.  So MXG executes with SAS V9.1+ or SAS V8.2 on     
      every possible SAS platform! Each new MXG version is also tested  
      with SAS/ITSV/ITRM by ITRM developers.                            
    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 OW41318       Mar 31, 2000        18.03        
      OS/390  2.8.0                    Aug 24, 1999        16.09        
      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        
      z/OS    1.2+ APAR OW52227        Apr 26, 2002        20.02        
      z/OS    1.3+ APAR OW52227        Apr 26, 2002        20.02        
      z/OS    1.2 JESNR Z2 MODE        Apr 26, 2002        20.03        
      z/OS    1.3 JESNR Z2 MODE        Apr 26, 2002        20.03        
      z/OS    1.4 Tolerate             Sep 27, 2002        20.03        
      z/OS    1.4 Support              Sep 27, 2002        20.06        
      z/OS    1.4 Over 16 CPUs/LPARs   May 29, 2003        21.02        
      z/OS    1.4 DFSMS/rmm, RACF      Aug 29, 2003        21.04        
      z/OS    1.5                      Mar 31, 2004        21.21        
      z/OS    IRD ASUM70PR/ASUMCEC     Sep 22, 2003        21.05        
      z/OS    IRD TYPE70PR             Mar 11, 2004        22.01        
      z/OS    IRD TYPE70,RMFINTRV      Mar 22, 2002        22.12        
      z/OS    1.6 - No IFAs            Sep 30, 2004       *22.09        
      z/OS    1.6 - With IFAs          Sep 30, 2004       *22.11        
      z990 CPUs - CPUTYPE '2084'x      Aug 25, 2003        21.04        
      z890 CPUs - CPUTYPE '2086'x      Jun 24, 2004        22.07        
      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     Jan 25, 2002        19.19        
       CICSTRAN subtype 1 support only                    *19.19        
       CICSTRAN subtype 2 completed                       *19.08        
      CICS-TS for Z/OS Version 2.3     Dec 19, 2003                     
       Using UTILEXCL to create IMACEXCL:                  21.04        
       Reading un-Excluded CICS with TYPE110, no IMACEXCL:*22.04        
      CICS-TS for Z/OS Version 3.1     Mar 15, 2005                     
       Using UTILEXCL to create IMACEXCL:                  22.13        
       Reading un-Excluded CICS with TYPE110, no IMACEXCL: 22.22        
      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 6.1.0 parallel DB2           Mar 15, 1999        19.19        
      DB2 7.1.0 parallel DB2           Mar 31, 2001        19.19        
      DB2 7.1.0 corrections            Mar 31, 2001        20.06        
      DB2 8.1 Tolerate                 Mar 31, 2004        20.20        
      DB2 8.1 New Data Supported       Mar 31, 2004        21.08        
      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        
      MQ Series 5.3                    Dec 16, 2002        21.05        
      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        
      WebSphere 5.0 APAR PQ7463        Aug 19, 2003        21.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        
      z/VM    3.1 DATABYTE=0           May  2, 2002        20.02        
      z/VM    4.2 ??                   May  2, 2002        20.02        
      z/VM    4.4                      Jan 22, 2005        22.22        
      z/VM    5.1                      Jan 22, 2005        22.22        
      IMS log 4.1                      Jul  4, 1994        12.02        
      IMS log 5.1                      Jun  9, 1996        14.05        
      IMS log 6.1                      ???  ?, 199?        20.03        
      IMS log 7.1                      ???  ?, 200?        20.03        
      IMS log 8.1                      May 21, 2003        21.02        
      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        
      AS400 5.2.0 - Most records       Jul 23, 2003        21.03        
      AS400 5.2.0 - QAPMMIOP           Jul 23, 2003        22.04        
      AS400 5.3.0                      Jan 22, 2005        22.22        
    Note: Asterisk before the version number means the Version number   
          was changed (to the MXG version required), after an earlier   
          MXG version was listed as supporting this product release,    
          usually because an APAR modified the product's data records.  
          Or a coding error in MXG could be the reason for the change!  
    Availability dates for non-IBM products and MXG version required:   
                                                        MXG Version     
      Product Name                                       Required       
      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        
       NTSMF 2.4.4                     Aug  9, 2002        20.04        
       NTSMF 2.4.5   INCOMPAT          Apr  1, 2003        21.02        
       NTSMF 2.4.7                     Sep 30, 2004        22.08        
       The Monitor for DB2 Version 2                       13.06        
       The Monitor for DB2 Version 3.0                     16.02        
       The Monitor for DB2 Version 3.1                     20.04        
       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 CICS/ESA 2.1 -                      20.04        
       The Monitor for CICS/ESA 2.2 - 20.335, 21.134       21.04        
       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        
       The Monitor for MVS/ESA 3.0  -                      19.19        
       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        
       NETSPY 6.0                                          20.10 20.305 
       NETSPY 7.0                                          20.10 20.305 
      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       
       APAF 4.1, 4.3                                       16.08        
      Velocity Software                                                 
       XAMAP 3.4                                           22.10        
II.   Incompatibilities and Installation of MXG 22.10.                  
 1. Incompatibilities introduced in MXG 22.22 (since MXG 21.21):        
  a- Changes in MXG architecture made between 22.22 and 21.21 that might
     introduce incompatibilities.                                       
 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.                     
_PAGE_  8                                                               
Alphabetical list of important changes in MXG 22.22 after MXG 21.21:    
  Member   Change    Description                                        
  Many     22.018  Hardcoded "SPIN" DDname now &SPININ,&SPINOUT macros. 
  Many     22.177  Update to define MACRO _Vdddddd for numeric SMF plus.
  Many     22.180  Support for IFA CPU variables for zAAP processors.   
  Many     22.184  SAS V9.1.2 $VARYING design change protected.         
  Many     22.192  All INFORMAT $NOTRAN statements were removed.        
  Many     22.192  Protection for PROC SYNCSORT error with SAS V9.1.2   
  Some     22.108  Support for SAS V9.1 and V6SEQ without Hot Fix.      
  ADOC110  22.189  Major updated added 1300 lines of CICS documentation.
  ANAL4GB  22.138  Revised to use DCOLLECT to detect large VSAM files.  
  ANAL94   22.114  IBM VTS Stat Report used SMFTIME, not STARTIME.      
  ANALALL  22.040  Example now can write all SMF for selected job(s).   
  ANALFIOE 22.127  Run time improvement if SMF, instead of PDB, input.  
  ANALFLSH 22.236  New member tracks concurrent flash copies executing. 
  ANALGART 22.242  Example analysis for Gartner Group requests.         
  ANALIDMS 22.372  Sample contributed report for IDMS response times.   
  ANALPATH 22.275  Support for 256 LCUs in the example report.          
  ANALRMFR 22.062  REPORT=ALL request failed due to HTTP report, fixed. 
  ANALRMFR 22.181  Enhancements to RMF reporting.                       
  ANALSIZE 22.276  Utility to analyze size of SAS data libraries.       
  ASMRMFV  22.316  Enhanced support for RMF III VSAM files.             
  ASMTAPEE 22.038  ML-31 of MXGTMNT corrects GMT, MSC APAR support.     
  ASMTAPST 22.366  Prototype test MXGTMNT for STK HSC = please test.    
  ASUM42DS 22.147  Performance enhancement reduce I/O, CPU  using view. 
  ASUM70PR 22.135  MVS System Name of each LPAR, SMF70STN, added.       
  ASUM70PR 22.274  Vars TOTSHARE/TOTSHARC kept for orig/current weights.
  ASUM70PR 22.293  LP0xxxxx variables now populated with PHYSICAL's data
  ASUMCACH 22.248  Protection for zero obs in PDB.TYPE74CA.             
  ASUMCIMS 22.241  Example summarization of the four IMF datasets.      
  ASUMHSM  22.282  Variable DATETIME was missing.                       
  ASUMJOBS 22.031  Incorrect stats for jobs that did not purge.         
  ASUMMIPS 22.354  Interval Capacity by Workload, used MIPS and MSU.    
  ASUMUOW  22.139  Variables APPLID/USER/LUNAME/TERMINAL incorrect.     
  ASUMUOW  22.336  MQMACCT/MQMACCTQ data can be added to PDB.ASUMUOW    
  AUTOEXEC 22.064  LIBNAME DUMMY added to support MONTHASC.             
  AUTOEXEU 22.102 file for unix, protects SASAUTOS error. 
  BLDIMPDB 22.128  ASCII equivalent of JCL for JCLIMSLx execution.      
  BLDNTPDB 22.111  unix case sensitivity corrections                    
  BLDSMPDB 22.111  unix case sensitivity corrections                    
  BLDSMPDB 22.329  Major enhancement to "PC Job Stream" for SMF on PC.  
  BUILDPDB 22.052  PDB.STEPS can have wrong EXCP,IOTM,TAPExxxx values.  
  BUILDPDB 22.115  JES3 PDB only; wrong TYPE26J3 used in BUILDPD3.      
  BUILDPDB 22.165  BUILDPDB detects overlapped SMF data previously read.
  BUILDPDB 22.320  MULTIDD='Y' obs now combined in PDB.SMFINTRV.        
  BUILDPDB 22.326  Variable CPUCEPTM now deaccum in PDB.SMFINTRV.       
  BUILDPDB 22.342  TYPE115/TYPE116 added to BUILDPDB, may cause errors. 
  BUILDPDB 22.365  BUILDPDB now sets Condition/Return code of zero.     
  CICINTRV 22.288  Comments show how to create PDB.CICINTRV from SMF.   
  CONFIGV9 22.108  CRITICAL Hot Fix SN-012437 Required for SAS V9.      
  CONFIGV9 22.123  SAS V9 on MVS VB INCOMPAT: S2=72 must be S2=0.       
  DB2STATB 22.045  Negative QBSTGET and other QBSTxxx, 4-bytes wrapped. 
  ERRORASC 22.239  ASCII platform errors when incorrect SMF download.   
  EXDB2ACC 22.121  DB2 Parallel CPU time lost, not output in DB2ACCT.   
  IEFU84   22.136  SMF exit to get Initiator Name and Number for jobs.  
  IHDRMQM  22.290  New "header" exit for MQ record selection.           
  IMAC6ESS 22.117  Support for optional ESS segment GEPARMKY=003Bx.     
  IMAC6ESS 22.161  Support for ESS GEPARMKY 003Bx and 0045x fields.     
  IMAC6ESS 22.332  Support for GEPARMKY 0036, 0041, 0043, fix 0034x.    
  IMACICHO 22.169  Hogan optional CICS data member now exists           
  IMACSHFT 22.058  Temporary variable SHFTTIME now dropped and not kept.
  IMACZDAT 22.004  New ZTIME variable available.                        
  JCLMNTHD 22.343  JCL example to build MONTHLY PDB on disk.            
  JCLRMF   22.143  Example to create "RMF-only" PDB from SMF data.      
  MONTHASC 22.064  Example "MONTHBLD" for ASCII systems.                
  MONTHDSK 22.343  "MONTHBLD" program to build MONTHLY PDB on disk.     
  MXGSASV9 22.126  SAS dsnames must be "W0", w-zero, not w-oh.          
  MXGSASV9 22.130  Revised MXG JCL example for SAS V9, NLS names, etc.  
  ONLYINTV 22.326  Example to build only PDB.SMFINTRV/PDB.TYPE30_6.     
  RMFINTRV 22.050  Variable PCTCPUBY wrong in RMFINTRV when IRD active. 
  RMFINTRV 22.088  Second VMXGRMFI invocation requires SPINRMIN= arg.   
  RMFINTRV 22.289  Duplicate observations for first hour.               
  SYSLOG   22.238  Preliminary support for SYSLOG file.                 
  TESTOTHR 22.279  TYPEVTOC no longer executed in MXG test stream.      
  TRND.... 22.258  Symbolics &TRENDINP,&TRENDNEW,&TRENDOLD added.       
  TYPE102  22.074  T102S125 variables QW0125SN/PC/PL/PN/TS missing.     
  TYPE102  22.234  Support for IFCIDs 140-145 SQL text that was blank.  
  TYPE102  22.294  Support for APAR PQ73385,PQ91101 for IFCIDs 217, 225 
  TYPE102  22.294  Support for APAR PQ87848 for IFCID 173               
  TYPE102C 22.104  Support for Candle Omegamon II for DB2 IFCID Trace   
  TYPE102G 22.109  TYPE102G to read DB2 Trace written to GTF didn't.    
  TYPE110  22.059  CICS/TS 2.3 Pool Variables corrected in CICDSPOO.    
  TYPE110  22.094  Support for CICS/TS 2.3 with no EXCLUDEd fields.     
  TYPE110  22.359  Support for CICS/TS 3.1 with no EXCLUDEd fields.     
  TYPE117  22.029  Support for SMF 117 WBIMB WebSphere Business Integrat
  TYPE119  22.073  TYP11910 variables UCINxxxx,UCOUxxxx corrected.      
  TYPE119  22.146  TYP119nn datasets had GMT time zone, now have local. 
  TYPE120  22.014  WebSphere SMF 120s had GMT for many timestamps.      
  TYPE30   22.021  Job delays SMF30HQT/JQT/RQT/SQT revisions.           
  TYPE30   22.022  Variable SRVTCBTM,SRVSRBTM,CPUTOTTM created in TYPE30
  TYPE30   22.221  Support for z/OS 1.6 and zAAP/IFA Processors.        
  TYPE30   22.265  Support for APAR OA09118, adds CPUCOEFF to SMF 30s.  
  TYPE30   22.272  Support for zAAP IFA engines.                        
  TYPE30   22.375  IBM Error in CPUIFATM, MXG Error in SRVTCBTM.        
  TYPE30MR 22.345  TYPE30MR dataset restructured and corrected.         
  TYPE42   22.254  False ERROR:INVALID TYPE 42 SUBTYPE 5 corrected.     
  TYPE42DS 22.055  TYPE42DS variable AVGIOQMX small negative value.     
  TYPE57   22.057  Support for optional ESS fields.                     
  TYPE6    22.153  SUBSYS='TCP' or 'TCPE' for Printway SMF 6 records.   
  TYPE6    22.298  SMF 6 STOPOVER on PrintWay section - missing @;      
  TYPE6    22.302  Support for VPS V1 R8.0 VPS-FAX data                 
  TYPE6    22.309  Final correction for type 6 INPUT EXCEEDED errors.   
  TYPE6    22.321  Support for second format type 6 PrintWay record.    
  TYPE70   22.050  Variable PCTCPUBY wrong in TYPE70 when IRD is active.
  TYPE70   22.087  Non-PR/SM, IORATE/PCTTPI variables too low.          
  TYPE70   22.116  Variables SMF70NSI/NSA/NSW incorrectly divided.      
  TYPE70   22.134  Percent when each engine online PCTONLN0-PCTONLNX.   
  TYPE70   22.325  "Short CP" variable SHORTCPS created in TYPE70.      
  TYPE7072 22.063  Calculation of variable PCTDLTDQ in TYPE72GO revised.
  TYPE7072 22.072  TYPE72GO with R723CWMN GT 0, Periods not output.     
  TYPE7072 22.137  Support for z890 CPUTYPE 2086, OS/390-INCOMPAT.      
  TYPE7072 22.152  Support for IFA Processors, APAR OA05731.            
  TYPE7072 22.221  Support for z/OS 1.6 and zAAP/IFA Processors.        
  TYPE7072 22.260  Support for z/OS 1.6 WITH IFA engines.               
  TYPE7072 22.272  Support for zAAP IFA engines.                        
  TYPE7072 22.307  Negative CPU values for IRD - Required CHANGE.       
  TYPE7072 22.340  Revision to support for varying IFAs online/offline. 
  TYPE7072 22.349  Negative PCTMVSBY/CPUMVSTM/SHORTCPs, SMF70CNF bit 6. 
  TYPE70PR 22.011  PCTCPUBY for IRD was incorrect.                      
  TYPE70PR 22.150  LPAR names for LPARs 16-32 now 8 bytes, were only 1. 
  TYPE71   22.269  22.07-22.10 only. LPAxxxx variables missing values.  
  TYPE74   22.075  Support for 1024 structures in Coupling Facility.    
  TYPE74   22.141  Support for RMF 74 subtype 8 ESS Link Stats record.  
  TYPE74   22.334  Support for APAR OA06476 type 74 subtype 5 and 8.    
  TYPE78   22.091  Variable PCTALLBY, TYPE78CU always missing, correct. 
  TYPE80A  22.185  Invalid SMF 80 Extended Relocate Section protected.  
  TYPE80A  22.286  Numerous enhancements, multiple RACF segments, etc.  
  TYPE82   22.005  Support for Crypto subtypes 14 thru 19.              
  TYPE94   22.268  Support for VTS R7.3 additional statistics.          
  TYPEAIX  22.083  Support for AIX PTX new objects.                     
  TYPEBETA 22.250  Support for BETA93 Release 3.5 subtypes 0-5.         
  TYPECIMS 22.314  Support for Mainview IMS IMF 4.1.00 (NO CHANGES!).   
  TYPECMF  22.266  Support for CMF Version 5504 User SMF (INCOMPAT).    
  TYPEDB2  22.042  DB2 Stats records not written in subtype order.      
  TYPEDB2  22.084  Large QBSTGET in DB2STATB due to DB2 restart fixed.  
  TYPEDB2  22.090  MXG 22.02-22.03 only. QWHSSTCK 1960 date in DB2ACCT. 
  TYPEDB2  22.121  DB2 Parallel CPU time lost, not output in DB2ACCT.   
  TYPEDB2  22.124  MXG 22.04-05, QWHSSTCK missing in SMF 102 trace data.
  TYPEENDV 22.032  Support for Endeavor Release 4.0, INCOMPATIBLE.      
  TYPEHIOM 22.331  Support for hIOmon File I/O Performance Monitor.     
  TYPEHMF  22.168  Support for HMF V2.7 new subtypes, compatible.       
  TYPEHPDM 22.166  Support for STK ExHPDM user SMF record.              
  TYPEHURN 22.006  Support for Huron/Object Star additional subtypes.   
  TYPEHURN 22.304  Support for ObjectStar subtype 45 Page Sweep.        
  TYPEIBSM 22.079  Support for IBM Session Manager user SMF record.     
  TYPEIMS7 22.199  Major revision to IMS0708 dataset, all events output.
  TYPEIMSA 22.113  ASCII execution only, APPLID not readable.           
  TYPEIPAC 22.125  Support for IPAC subtype 5 IPAC05 corrections.       
  TYPEMVCI 22.296  Reading CMRDETL on ASCII platform - BLKSIZE error    
  TYPENDM  22.133  Support for several additional NDM-CDI subtypes.     
  TYPENETM 22.037  Support for NetMaster 5000x subtype.                 
  TYPENETM 22.131  TYPENSPY and TYPENETM combined, only one SMF record. 
  TYPENSPY 22.131  TYPENSPY and TYPENETM combined, only one SMF record. 
  TYPENSPY 22.312  Support for NetSpy Version 7.0 (COMPATIBLE).         
  TYPENTSM 22.082  Variable MEMINBOX in NTCONFIG was wrong.             
  TYPENTSM 22.190  Support for NTSMF MicroStrategy Server objects.      
  TYPENTSM 22.193  Support for NTSMF Exchange/Outlook/DTS CPU objects.  
  TYPENTSM 22.246  Support for NTSMF Release 2.4.7 (COMPATIBLE).        
  TYPEOMVT 22.186  Omegamon/VTAM V520 IRNUM 29 Divide by zero corrected.
  TYPEQACS 22.095  Support for OS/400 5.2 QAPMMIOP record new fields.   
  TYPEQACS 22.311  Support for OS/400 5.3.0 CONF/DISK/POLL/JOBL data.   
  TYPEQACS 22.371  Support for OS/400 5.3.0.                            
  TYPESASU 22.163  Cannot use NODUP option with TYPESASU SAS user SMF.  
  TYPESMSX 22.030  Support for DF/SMS Storage Class Exit User SMF record
  TYPETDSL 22.249  Support for TDSLink product's user SMF record.       
  TYPETMDB 22.235  Support for ASG/Landmark TMON for DB2 V4.0 (COMPAT)  
  TYPETMNT 22.237  DDNAME/STEPNR missing in PDB.ASUMTMNT corrected.     
  TYPETMO2 22.191  Support for ASG/TMON TCE for CICS/ESA 2.3, COMPATIBLE
  TYPETNG  22.081  Protection for '9E'x for Left Square Bracket.        
  TYPETNG  22.085  Support for NT objects SESSION and USER in TNG cubes.
  TYPETNG  22.160  REGION reduced for JCLTEST8 TESTOTHR due to TYPETNG. 
  TYPETNG  22.170  Support for TNG Windows Server 2003 new objects+fix. 
  TYPETNG  22.291  Support TNG NT Platforms NTW400I, WNS502I, ZPP501I.  
  TYPETNG  22.339  Major TNG enhancement - array sizes dynamically set. 
  TYPETPF  22.374  Support for MQ Series data from TPF Operating System.
  TYPETPMX 22.008  (Final?) revisions to internal Thruput array names.  
  TYPETPMX 22.060  Restructure TPM support, multiple datasets created.  
  TYPETPMX 22.077  Support for alternative multiple-ACCT field TPM data.
  TYPETPMX 22.142  INNODE, JBSBIND, JVLVOL, REQCLA varnames supported.  
  TYPEVIOP 22.101  Support new VIO/PLUS (Performance Enhancer) subtypes.
  TYPEVMXA 22.240  Support for z/VM 4.4, INCOMPAT.                      
  TYPEVMXA 22.369  Support for z/VM 4.4 and z/VM 5.1 additions.         
  TYPEXAM  22.245  Support for XAMAP Release 3.4 (INCOMPATIBLE).        
  UTILBLDP 22.149  Enhancement supports subtype selection in ZEROOBS.   
  UTILBLDP 22.277  New MACFILEX argument to insert SAS code.            
  UTILBLDP 22.301  Use of ZEROOBS= parameter could fail.                
  UTILCONT 22.356  ABEND with SAS V9 when PDB=WORK requested fixed.     
  UTILEXCL 22.068  Support for optional RMI data in CICSTRAN.           
  UTILEXCL 22.317  The final @; was not created in IMACEXCL.            
  UTILS2ER 22.123  Utility to detect errors with S2=0 in your programs. 
  VGETENG  22.148  Enhancement to get Engine and Device Type of LIBNAME 
  VMACDB2H 22.196  Support for extended length DB2 id variables.        
  VMACDB2H 22.270  22.08-22.10 only. DB2 V8.1 INPUT STATEMENT EXCEEDED. 
  VMACSMF  22.271  _LOGSMF revised for TYPENDML.                        
  VMACSMF  22.300  Use of FTP access to read SMF MVS-to-MVS failed.     
  VMXGINIT 22.096  Macro variables &MACINTV and &MAC30DD created.       
  VMXGPRAL 22.287  Enhancement to use PROC FREQ, example for 102 "who". 
  VMXGRMFI 22.017  BUILDPDB run time elongation, if output to tape.     
Inverse chronological list of all Changes:                              
NEXTCHANGE: Version 22.                                                 
====== Changes thru 22.378 were in MXG 22.22 dated Feb  1, 2005=========
Change 22.378  Type 74 subtype 8 (ESS 2105 PPRC RMD data) with nulls for
Jan 30, 2005   to be midnight on 1JAN1960.  Now, R748CFTM is set missing
               when R748CFDT is not populated.                          
   Thanks to Shirley Fung, Hong Kong & Shanghai Bank, HONG KONG.        
Change 22.377  This elegant tweak discovered by this user to my enhanced
TYPETNG        dynamic array sizing uses even less virtual storage when 
VMACTNG        you have multiple TNG cubes from different systems.  My  
Jan 29, 2005   enhancement in Change 22.339 kept all instances from all 
               systems to set the array sizes, but by changing counting 
               true count of unique instances needed for the array size 
               is much smaller; for example, NT042I dropped from 1008 to
               489, and REGION dropped from 266MB to only 149MB.        
              -TYPETNG now prints the INSTREAM file on the log after it 
               was created, useful for debugging.                       
   Thanks to Peter Krijger, ANZ National Bank Limited, NEW ZEALAND.     
Change 22.376 -MXG 22.22 is the last to be tested under SAS V6 on MVS,  
UTILXRF1       because my MVS QA site is removing Version 6, but the    
UTILXRF2       final tests discovered two variables whose names were    
Jan 29, 2005   longer than 8 bytes.  While SAS V8+ permits longer names,
Jan 30, 2005   it is my intention to NEVER use them in MXG, not only as 
               I find them user-unfriendly, but also because all of my  
               ADOC/DOC members are designed for 8-byte variable names. 
               But this last test was a great wakeup, so I have enhanced
               my Cross Reference utility, run during my Alpha QA tests,
               to detect long variable names, and also, for similar     
               reasons, detect if I have created labels longer than 40. 
              -Dataset Labels were missing from many datasets in DOCVER,
               even though the MXG code had a LABEL= dataset option in  
               the VMACxxxx members.  Dataset labels are propagated from
               the input to the output dataset if PROC COPY or PROC SORT
               is used (even if the dataset name is changed in SORT),   
               but creating a new dataset from an old dataset does not  
               propagate the dataset label.  Most MXG _Sdddddd dataset  
               macros use PROC SORT, and test data is used to determine 
               the correct BY list to remove duplicates, but when there 
               is no test data,  DATA _Ldddddd; _Wdddddd;  is used to   
               copy the "Work" dataset to the "PDB" output library, and 
               it was those instances that had missing labels in DOCVER.
               While getting test data and revising the _Sdddddd to SORT
               and remove duplicates is the eventual solution, to get   
               the dataset labels for MXG 22.22, I revised CROSSREF to  
               copy the _Wdddddd datasets to one library, and to copy   
               the _Ldddddd datasets to a second library, and to use the
               label from the _Wdddddd dataset if the _Ldddddd copy had 
               a blank label.  I could not just use the _Wdddddd data,  
               because some of the _Sdddddd macros add new variables;   
               in particular, when adjacent interval records have to be 
               deaccumulated, the _Sdddddd logic creates the DELTATM.   
              -There are still a few datasets that don't have labels.   
   Thanks to Jake M. Drew, MBNA, USA.                                   
Change 22.375  MXG variable SRVTCBTM, a CPU TCB time that is calculated 
VMAC30         from CPU TCB Service Units was wrong if the task executed
Jan 29, 2005   on a zAAP (IFA) engine, because the MXG calculation used 
               CPUUNITS before IFAUNITS had been removed from CPUUNITS. 
              -Now, the order of calculation is correct.                
                 - SRVTCBTM was added by Change 22.022 to the TYPE30xx  
                   datasets so that it could be compared with CPUTCBTM. 
                   Cheryl thought that using Service Units might provide
                   higher resolution and less truncation for small jobs 
                   due to the .01 second precision of CPUTCBTM, but my  
                   analysis had not shown a significant difference.     
                 - Change 22.221 documented that the "raw" CPUUNITS in  
                   SMF 30 records include the IFA Service Units, but as 
                   IBM provides the CPUIFATM and the coefficients, that 
                   MXG created a separate variable, IFAUNITS, and those 
                   IFA Service Units are removed from CPUUNITS.         
              -However, new analysis of SRVTCBTM in type 30 records for 
               2086 (z/890s) for tasks that use IFAs shows an error in  
               IBM's creation of CPUIFATM: the calculated SRVTCBTM is   
               significantly larger than CPUTCBTM when IFAs are used:   
                 IFA?   SRVCLASS   CPUTCBTM   SRVTCBTM  Diff  CPUIFATM  
                 Yes     STCHI        31.14      90.58   +59     80     
                 Yes     STCMED      129.29     333.35  +204    211     
                 Yes     STCHI      4057.62    4517.82  +460    689     
                 Yes     STCMED       23.37     118.91   +95     13     
                 No      STCHI      1253.96    1248.32    -5            
                 No      STCHI       242.15     241.79     0            
                 No      STCMED      266.03     265.80     0            
               IBM is fully aware of this problem and will undoubtedly  
               correct it in the near future.                           
Change 22.374  Support for MQ Series data from TPF creates two datasets 
EXTPFMQC         dddddd   dataset   description                         
Jan 28, 2005                                                            
Change 22.373  Change 22.055 set AVGIOQMS to zero if a negative value   
VMAC42         was calculated, due to clock differences, but that change
Jan 28, 2005   only applied to AVGIOQMS for TYPE42SR dataset.  Now, the 
               other two datasets, TYPE42VT and TYPE42DS are protected. 
   Thanks to Karl Lasecki, Chemical Abstracts Service, USA.             
Change 22.372  Sample contributed report for IDMS response times, using 
ANALIDMS       the PDB.IDMSTAS dataset built by TYPEIDMS from the IDMS-R
Jan 28, 2005   SMF record.  The report also shows how you can send any  
               SAS report to your company's web site.                   
   Thanks to Pat Curren, SuperValu Inc, USA.                            
Change 22.371  Support for OS/400 5.3.0.  New data in QAPMJOBM, QAPMSYSC
EXQAPJSU       Change 22.311 supported new data in QAPMCONF, QAPMDISK,  
IMACQACS       QAPMPOLL and QAPMJOBL.  As always with AS/400 support, if
JCLTEST8       you are running MXG on z/OS, you must make the LRECL of  
JCLTEST9       the MVS dataset into which the QAPM file is sent to be   
QASAS          the same as the LRECL in the table in VMACQACS for that  
VMACQACS       dataset; on ASCII, it's the LRECL in your FILENAME that  
VMXGINIT       must match.                                              
Jan 28, 2005  -The new QAPMSYS with 567 variables replaces QAPMSYSL, but
               none of the old JSxxxx variables from QAPMSYSL exist in  
               QAPMSYS.  QAPMSYS is the "long" (LRECL=3344) system file,
               and you will need to add _TQAPSYS and //QAPMSYS DD to    
               create the new dataset.                                  
              -The new QAPMJSUM dataset is created with Job Statistics  
               Performance Data.                                        
              -The new QAPMDPS dataset is created with Data Port Service
               Performance Data.                                        
              -Variables added to QAPMSYSC:                             
               SCTACT - The number of CPUs, so variable PCTCPUBY is now 
               calculated as 100*SUM(OF SCPU01-SCPU32)/(SCTACT*INTSEC). 
              -Variables added to QAPMJOBM:                             
                 JBASH    JBASHA   JBBFA    JBBFW    JBBTA     JBBTW    
                 JBCOP    JBCOS    JBDOP    JBDOS    JBFSH     JBFSHA   
                 JBNSJE   JBPGA    JBPGD    JBPJE    JBSJD     JBTNW    
                 JBTWT    JBUJD    JBXRBR   JBXRBW   JBXRFS    JBXRRR   
                 JBXRRW   JCUSR                                         
              -Variables added to QAPMSYST:                             
               SYIFTA   SYIFTE   SYIFUS   SYJOC1   SYJOC2   SYJOC3      
               SYJOER   SYJOES   SYJOIB   SYJOS1   SYJOS2   SYJOS3      
               SYSDFRL  SYSDNFE  SYSDNFO  SYSDNST  SYSDPFD              
               SYSDPFF  SYSDTET  SYSPTU   SYUTA                         
   Thanks to Clayton Buck, Unigroup, USA.                               
Change 22.370  The dataset name in the comments in the code that invokes
TYPEHO15       the _Edddddd macro was incorrect in a number of members, 
VMAC84         but in some cases, it wasn't the name in comments, but it
VMACARB        was the _Edddddd that was wrong, which caused those data 
VMACCMFV       to be output to the wrong dataset.  Fortunately, none of 
VMACTMDB       these are "mainstream" datasets, so that error was never 
VMACVITA       noticed.  The MXG QA stream now validates the comment and
Jan 27, 2005   the _Edddddd macro are consistent.                       
               invoke it.  This change corrects the dataset name typos  
               and makes the macro use more consistent within MXG code. 
   Thanks to Jake M. Drew, MBNA, USA.                                   
Change 22.369  Support for new fields added to z/VM 4.4 and z/VM 5.1;   
EXIODQDS       INCOMPATIBLE only because MXG did not properly use the   
EXMTRQDC       offsets and lengths for the SYTCUG and SYTCUP datasets.  
FORMATS       -Added prior to z/VM 4.4, but not in MXG until now:       
Jan 26, 2005              VL3RESVD VL3STNBY                             
                          IPQEFHI  IPQDSKIP VMDCTPVG VMDMVB2G           
              -Added in z/VM 4.4:                                       
                          SYSSCMEX SYSTRCPC                             
                          SYSMMODL SYSMPOM SYSMSEQC SYSMTYPE            
                STOASP -  SCGSSCH                                       
                STOASS -  SCMSSCH (expanded to 4 bytes)                 
                SYTSCG -  CALTLKCT CALTLKTM                             
              -Added in z/VM 5.1:                                       
                IODDEV -  EDEVTYPE RDEVDEV                              
                IODDTD -  RDEVDEV                                       
                IODVOF -  RDEVDEV                                       
                IODVON -  EDEVFCP1-EDEVFCP8 EDEVLUN1-EDEVLUN8           
                MTRDEV -  EDEVFCP1-EDEVFCP8 EDEVLUN1-EDEVLUN8           
                MTRPAG -  RDEVDEV                                       
                MTRSYS -  CPUCAPAB SCPCAPAB                             
                STOASS -  RDEVDEV                                       
                STOATC -  RDEVDEV                                       
                SYTCUP -  LCXPUPID                                      
                SYTXSG -  TCMFSHVM TCMRDCT TCMPIN4K                     
                          VEBTVSCT VEBVIRAI                             
                          VEBTVSCT VEBVIRAI                             
                          VEBTVSCT VEBVIRAI                             
                SYTSYG -  SCPCAPAB                                      
              -New Datasets created in z/VM 5.1:                        
                MTRQDC - QDIO DEVICE CONFIGURATION                      
                IODQDS - QDIO ACTIVITY                                  
                Other new records will be supported only if you         
                have a need and can send test data for them:            
                  MTRCCC, IODVSM, IODVSR, IODSZI, IODQDA, IODQDD.       
   Thanks to Kris Ferrier, State of Washington Dept Info Services, USA. 
   Thanks to Alexandre Dorsimont, SCNH, FRANCE.                         
Change 22.368  The "TOTALS" record was still output in XAMSYT, because  
EXXAMSYT       the test in EXXAMSYT was spelled 'TOTAL' but the actual  
Jan 26, 2005   LPAR name test needed to be 'TOTALS:'.                   
   Thanks to Joachim Mayr, Amadeus, GERMANY.                            
Change 22.367  MXG 22.13-22.22 only.  Change 22.320 combined MULTIDD obs
BUILD005       from TYPE30_V into one PDB.SMFINTRV obs, but if you used 
BUIL3005       IMACINTV to only output some of the TYPE30_V obs, then   
Jan 25, 2005   PDB.SMFINTRV had more obs than were in TYPE30_V.  All DDs
               for all tape devices from all interval records are output
               in TYPE30TD, independent of the TYPE30_V selections.  The
               TYPE30TD then becomes TYPE30VT, which is merged with the 
               INTVS (which is a stripped down TYPE30_V) and INT30VSIO  
               (the sum of all I/Os for the interval records), but now, 
               the merge is only OUTPUT if the obs is in INTVS.         
   Thanks to Ron Lundy, AHOLD, USA.                                     
====== Changes thru 22.366 were in MXG 22.22 dated Jan 22, 2005=========
Change 22.366  The MXGTMNT Tape Mount Event and Sampling Monitor ML-32  
ASMTAPEE       is in member ASMTAPEE, with these enhancements:          
ASMTAPST      -The ML-32 revisions are primarily for IBM Tape Devices,  
ASMTAPSK       because it defaults to use the IBM Volume Mount Exit, and
Jan 22, 2005   STK doesn't support that exit.  Thus these defaults in   
Jan 27, 2005   the ASMTAPEE member will ONLY work with IBM devices:     
                  MXIT=ON,  use the IBM Volume Mount Exit to capture all
                    Mount Events (exit-driven, not sampling for mounts),
                    which also gets job-level fields for the Mount Event
                    so Cross Memory Service calls are not needed for the
                    mount record.                                       
                  XMEMF=ON, use Cross Memory Services to get job-level  
                    fields for the Allocation Event, which are detected 
                    by sampling.                                        
                  ARCV=ON,  enable detection of Allocation Recovery thru
                    exit, to write a separate subtype for each delay    
                    because a tape device could not be allocated.  This 
                    subtype creates the (new) PDB.TMNTTARC dataset.     
              -However, you can use ML-32 with STK devices: you have to 
               set MXIT OFF, so that the old sampling monitor is used to
               detect mount events, even though that means that many of 
               your fast VTS mounts will not be captured.  You also need
               to leave XMEMF ON, so that Cross Memory Services is used 
               to get the job-level information for both mount events   
               and allocate events, even though that may increase the   
               CPU time used by the MXGTMNT monitor (because there is no
               way to know that an address space is no longer present,  
               except to issue the XMEM call, and then go thru the very 
               CPU-expensive recovery mechanism when XMEM fails to find 
               the job, because it had already ended).                  
              -And if you have both IBM and STK devices, you will need  
               to assemble two different MXGTMNT programs and run them  
               in two Started Tasks, and use the EXCLUDE LIST DD to tell
               the IBM instance to exclude the STK devices by DEVNR, and
               to tell the STK instance to exclude the IBM devices.     
               You can create the same SMF record for both monitors, or 
               you could set different SMF IDs, and then you would use  
                MACRO _IDTMNT  nnn OR ID= mmm %  in the IMACKEEP member 
               to tell MXG to process both IDs as MXGTMNT records.      
              -STK devices are allocated by STK's HSC product, which    
               does not call the IBM volume mount exit; we have written 
               a test program for the HSC SLSUX01 exit, but have not had
               an STK site run the program, which will determine if we  
               can use that exit for STK devices (and thus eliminate the
               sampling and missed mounts).  Here's what we need:       
                ASMTAPST is a test exit for potential STK support.  The 
                program is a wrapper for the site's current SLSUX01 HSC 
                exit.  There is a DD in the linkedit step, HSCLOAD, that
                points to the location of the site's current SLSUX01    
                exit.  The output of the linkedit is a combined SLSUX01 
                exit that the site will use, instead of their current   
                SLSUX01 exit code.  The HSCLOAD and SYSLMOD DDs must not
                point to the same library, or the site's SLSUX01 will be
                replaced.  Once the ASM/LKED are done, the site will    
                have to define the new MXG version of that exit to HSC. 
                 The logic is as follows:                               
                  -HSC calls the MXG SLSUX01.                           
                  -MXG SLSUX01 executes the site's local SLSUX01 as-is, 
                   taking whatever actions, were coded by the site.     
                  -Control is returned to MXG SLSUX01 where the code    
                   will do some data gathering and issue WTOs to the job
                   log, reporting what was discovered, from which we can
                   tell if the HSC exit can be used for STK devices.    
                  -MXG SLSUX01 returns to HSC.                          
                 Once you've installed our exit, run some jobs that     
                 cause both VTS and non-VTS tape mounts, and send us the
                 MXGTMNT job log, which will show us if all mounts do   
                 actually go through the exit, and what environment     
                 exists at the time the exit is taken.  From that info, 
                 we may be able to figure out how to handle the STK     
                 devices.  Unfortunately, we have to depend on you to   
                 run these tests, as STK has been unwilling to run these
                 tests for us on their systems.                         
                  - Just discovered: STK no longer provides a dummy exit
                    SLSUX01 in HSC 6.0!  Member ASMTAPSK is the variant 
                    of ASMTAPST that doesn't call that user exit.       
              -ML-32 corrects ML-31, in which setting MEXIT bypassed the
               XMEMF call in the Allocation Monitor (causing job-level  
               fields to be missing in the allocation records).  Now,   
               XMEMF on/off is independent of the MEXIT on/of setting.  
              -The TMNT004I message is updated before it is issued at   
               MXGTMNT initialization, to show any user modifications.  
              -STEPNAME is now correctly populated, and PROCSTEP name   
               has been added to TYPETMNT record for mounts.            
              -Using MXIT on IBM systems is only supported on z/OS.  We 
               have seen, on OS/390 systems, that second and subsequent 
               mounts for a job-step are not captured by MXIT, and also 
               mounts from STCs (like DFHSM and JES2) are also missed.  
               This is just not worth fixing for those archaic systems. 
              -There is one know error in ML-31/ML-32; the Mount Start  
               time is taken as the entry time into the Volume Mount    
               Exit, which now appears to be the same as the Allocation 
               Allocation Start time, and for most mounts that is very  
               close to the IEF233I Mount Message timestamp, and hence  
               not a problem.  But one site experienced very significant
               delays (30 minutes!, due to hardware errors) between the 
               TMNTTIME time and the IEF233I time, so ""  
               is now working on a revision, ML-33, but it won't be done
               and tested in time for MXG 22.22; please email a request 
               to when you read this text, asking for   
               ML-33, and we'll email the revised ASMTAPEE when ready.  
Change 22.365  BUILDPDB now sets Condition/Return Code of zero under V9!
BUILD005       SAS V9 tightened when Condition Codes were returned, and 
Jan 21, 2005   returned a CC=0 with SAS Version 8.2, but CC=4 with V9,  
               because JES3 JOBCLASS is $8, VMAC30 reads JES2 and JES3  
               30s, but VMAC26J2 for JES2 26s had JOBCLASS of $1, and   
               VMAC26J2 was located first in BUILDPDB to set $1 length. 
               This design increased JOBCLASS length in VMAC26J2 to $8, 
               eliminating the WARNING in the SMF-reading step where    
               VMAC30 and VMAC26J2 coexist, and new LENGTH JOBCLASS $1  
               statements were inserted in BUILD005 to keep only $1 for 
               JES2 JOBCLASS in the PDB and SPIN datasets, so that old  
               and new datasets built before and after this redesign    
               will still have a one byte JES2 JOBCLASS variable.       
              -TYPE30 used by itself always had JOBCLASS $8, so that did
               not change; only if you use TYPE26J2 by itself would you 
               notice that JOBCLASS's length is now $8 instead of $1.   
               But with MXG's COMPRESS=YES default, you shouldn't see   
               any increase in the size 'cause those 7 blank bytes will 
               get compressed real good!                                
              -The SAS change was noted in MXG Newsletter FORTY-FOUR,   
               but that note was revised, citing this MXG change.       
              -This should make migration from V8 to V9 even easier.    
Change 22.364  Variables BLKPAGE, BLKSAUIN, and NRBLKPAGE in TYPE71 are 
VMAC71         rates (per second, like all paging activity rates), but  
Jan 21, 2005   their labels did not so indicate; now, they do.          
   Thanks to David Kaplan, DTC, USA.                                    
Change 22.363 -The JES3 Workload Management Section variables (added to 
BUILD005       SMF 26 in OS/390 R2.4; already in TYPE26J2 and PDB.JOBS  
BUIL3005       for JES2, are now kept in JE3's TYPE26J3 and PDB.JOBS.   
VMAC26J3         JOBMODE0='RAN*IN*MODE=WLM'                             
Jan 21, 2005     JOBMODE1='RAN*F*J=JOB,RUN'                             
                 SMF26WCL='SERVICE*CLASS AT*EXECUTION'                  
              -Variable SMF26WSE, the Scheduling Environment name, was  
               only previously kept in JES2's PDB.JOBS, but this change 
               adds SMF26WSE to PDB.STEPS for both JES2 and JES3, as it 
               is often useful examine STEPS-level data (i.e., PROGRAM) 
               and the Scheduling Environment name that caused that PGM 
               to execute on this SYSTEM.                               
   Thanks to Julian Smailes, Experian, ENGLAND.                         
Change 22.362  Cosmetic.  The include of VMACSMF in these products was  
Several        not needed, as they read different INFILES.  No error,   
Jan 21, 2005   but it could have been confusing. Members changed:       
               TYPEOMDB, TYPEUNIA, TYPEUNIK, and TYPEVITA and TYPS's.   
    Thanks to Freddie Arie, TXU, USA.                                   
Change 22.361  Variable SYSTEM was blank in PDB.ASUMUOW if there was no 
VMXGUOW        DB2ACCT observation for that unit of work.  The value of 
Jan 20, 2005   SYSTEM comes from the last of the two input datasets     
               (CICS,DB2) that contributed to the PDB.ASUMUOW obs, so   
               if there are DB2 obs, the SYSTEM of the last DB2ACCT     
               observation will be the source of the value of SYSTEM.   
    Thanks to Ron Root, Texas Comptroller of Public Accounts, USA.      
Change 22.360  On z/890s with z/OS 1.4 but with SMF70LAC=0, values in   
FORMATS        the variables CECSUSEC, CPCNRCPU, CPUMSU were missing    
VMXGRMFI       because the $MG070CP format's table for CPUTYPE='2086'x  
Jan 19, 2005   was wrong.  When SMF70LAC GT 0, those variables are in   
               the SMF 70, but the $MG070CP table has to be used when   
               CECSUSEC IS MISSING was printed (obscurely) on the SAS   
               log by RMFINTRV code; this change enhanced that message  
               in case it again occurs. Changes 21.299 and 20.168 noted 
               that SMF70LAC was zero on basic (non-LPAR) machines, or  
               on LPAR'd machines if APAR OW55509 was not installed and 
               the LPAR had no defined capacity limit. This system was  
               not running in 64-bit mode, which may also be required   
               for SMF70LAC to be non-zero.                             
   Thanks to Diane Parker, AmerisourceBergen Corp, USA.                 
Change 22.359  Full support for CICS/TS 3.1 was only in UTILEXCL in     
VMAC110        22.13 as the three new fields (328,341,342) during the   
Jan 18, 2005   ESP were not added to VMAC110 INPUT for SMFPSRVR=64.0    
               until today.  MXG 22.13 tested MCTSSDCN=283, but now     
               MCTSSDCN=286 and MCTSSDRL=1848 is tested for             
               non-excluded-field records.  Using UTILEXCL to create    
               IMACEXCL has always been the recommended way to minimize 
               the size of your CICS 110s, and even if there are added  
               fields, since UTILEXCL read your CICS dictionary records,
               it will generate code to skip over any unrecognized      
               fields (and will tell you on the log it found unknown    
               fields, so they can be added to the MXG UTILEXCL and     
               VMAC110 members.                                         
   Thanks to Roland Schiradin, Alte-Leipziger, GERMANY.                 
   Thanks to Lambros Theodorides, Alte-Leipziger, GERMANY.              
Change 22.358  CALTODON, the datetime stamp when user Logged on, was not
VMACVMXA       converted from GMT to local time, but now it is.         
Jan 18, 2005                                                            
   Thanks to Xiaobo Zhang, ISO, USA.                                    
Change 22.357  UTILBLDP failed with USERADD=118 because VMACTCP defines 
UTILBLDP       the macros for SMF 118; originally, the TCP record was a 
Jan 18, 2005   User SMF record, and only later was given ID=118.  Now,  
               UTILBLDP is coded for this inconsistency and will work if
               use USERADD=118 or USERADD=TCP.                          
   Thanks to Keith McWhorter, Georgia Technology Authority, USA.        
Change 22.356  UTILCONT reports SAS Data Set sized in MegaBytes; as is  
UTILCONT       documented in its comments, it can cause log messages of:
Jan 18, 2005     WARNING: LIBRARY xxx WAS ALREADY ALLOCATED             
                 ERROR:   LIBRARY xxx MAY NOT BE REASSIGNED             
                 ERROR:   DISP=SHR CONFLICTS ASSIGNED                   
                 ERROR:   LIBNAME XXX IS NOT ASSIGNED                   
               but with MXG default options, these messages to NOT cause
               a condition code, nor does the job fail, and the reports 
               are produced.  However, if you have set the SAS Option to
               ERRORCHECK=STRICT (default is NORMAL), then errors like  
               the above in LIBNAME statements do cause ERRORABEND to be
               invoked, and the step fails with USER ABEND 999.         
               An ABEND did occur with %UTILCONT(PDB=WORK); due to the  
               changes made in Change 22.175, when MXG 22.12 was tested.
               This change to UTILCONT detects that the LIBNAME of WORK 
               was requested and does not reassign it, avoiding those   
               messages for the WORK library, and the ABEND.            
   Thanks to Hugh Lapham, Royal Canadian Mounted Police, CANADA.        
Change 22.355  EDGRKEXT was wrong; the first +1 did not exist. New      
Jan 17, 2005   are now output.                                          
   Thanks to Reinhard Nitsch, Provinzial Vershicherungen, GERMANY.      
Change 22.354  Capacity used for each interval for each workload, for   
ASUMMIPS       each service and reporting class from PDB.TYPE72GO, and  
Jan 16, 2005   for each job from PDB.SMFINTRV, with MIPSUSED, MSUUSED,  
Jan 22, 2005   and PCTUSED variables, is created in two output datasets 
               named PDB.RMFMSUSE and PDB.SMFMSUSE by the ASUMMIPS code.
               I think MSU is a much better capacity measure than MIPS, 
               but I used "MIPS" to name the member, so that, when your 
               boss asks for an MXG report on MIPS used, you will find  
               this program, which uses MSUUSED and MSU Capacity for the
               PCTUSED, but also calculates MIPSUSED from MSUUSED.      
              -Note that the conversion from MSU to MIPS uses a factor  
               that you will likely have to change to meet your boss's  
               MIPS rating of your hardware.  IBM giveth the MSU rating.
               Comments show how to determine the factor for your boss, 
               and you can set different factors for different systems. 
              -The MIPSUSED are the MSUUSED, multiplied by the factor   
               you set; the default factor is 5.8 MIPS for each MSU, but
               IBM now has a factor of 6.7 MIPS for each MSU for T-REX. 
              -See MXG Newsletter FORTY-ONE, MVS Technical Note 24, for 
               my documentation of MSU metrics and the MSU capacity     
               variables that are reported in the ASUMMIPS examples.    
              -PDB.RMFMSUSE is created from RMFINTRV and TYPE72GO data, 
               for capacity used by each Service and Reporting Class in 
               each interval.  Be careful: PDB.RMFMSUSE has duplicate   
               data, because it keeps both the Reporting and Service    
               Class obs.  You will need to select which obs are of     
               interest for your reporting, before you do any summary of
               the data in PDB.RMFMSUSE.                                
              -PDB.SMFMSUSE is created from RMFINTRV and SMFINTRV data, 
               for capacity used by each JOB in each interval.  If your 
               SMFINTRV data is NOT globally synchronized, the results  
               in PDB.SMFMSUSE may be inaccurate:                       
                 If your RMF Interval is on 0 minutes, but your SMF data
                 is on 3 minutes, the 00:00 to 00:10 interval created in
                 PDB.SMFMSUSE includes CPU time from jobs's intervals   
                 that executed from 00:03 to 00:13.                     
              -In both datasets, the MSU capacity is calculated from the
               CECSUSEC of the hardware platform, not from the SU_SEC of
               the MVS System, because that's what IBM uses in its MSU  
               calculations.  I use the NRCPUS (average number of CPUs  
               that IRD gave to this MVS system ) to get the capacity   
               of the specific interval (DURATM).  To compare with IBM  
               hourly MSU rates, you need to multiply by the ratio of   
               3600 divided by DURATM of your interval data.            
              -The PCTUSED is the percentage of MSUUSED by the job or   
               service/reporting class during this interval, divided    
               by the interval MSU capacity (using average NRCPUS),     
               which MXG calculates in variable INTMSUCP.               
              -Be careful to not confuse MIPS/MSU counts with MSU rates.
               Read the Newsletter Article (again).                     
              -Macros define the input "RMFINTRV" dataset that is used, 
               which sets the output interval, and macros define the    
               output dataset names.  The MXG default interval for      
               "RMFINTRV" is your RMF Interval, but you can execute the 
               RMFINTRV program many times to create multiple "RMFINTRV"
               datasets, each with different interval (see comments in  
               member RMFINTRV). For example, Hourly in RMFINTHR,       
               Shiftly in RMFINTSH, Daily in  RMFINTDY.   Comments in   
               ASUMMIPS member show how to execute it and how to tailor 
               it for your needs.                                       
   Thanks to George Canning, Abbey Plc, ENGLAND.                        
VMXGRMFI       is printed when the sum (CPU72TM) of the workloads that  
Jan 16, 2005   you defined, either in your tailored RMFINTRV member     
                 (the recommended way to define which Service/Reporting 
                 Classes you want combined into PDB.RMFINTRV workloads),
               or in your tailored IMACWORK member (the old way), do not
               match the sum (CPUTM) of all Service-only Classes.       
               The text of the message was enhanced to show both times  
               in both TIME12.2 and 8.2 formats and they are collimated 
               for easier reading.                                      
              -If you do receive that error message, you need to review 
               your RMFINTRV/IMACWORK definitions, and review your data,
               which is the purpose of the UTILRMFI program, which will 
               examine both your TYPE72GO and STEPS/SMFINTRV data to    
               provide explicit answers, but UTILRMFI requires manual   
               EDITing, and could require re-reading of your SMF data.  
               This PROC FREQ might be sufficient to show the error:    
                  PROC FREQ DATA=PDB.TYPE72GO                           
                  BY SYSPLEX SYSTEM;                                    
                  WEIGHT CPUTM;                                         
                  FORMAT STARTIME DATETIME13.;RUN;                      
               My error message was the result of using an old RMFINTRV 
               that had USEREPRT=GOAL (use ONLY Reporting Classes), but 
               the test data I was looking at (for other purposes!) did 
               not have 100% of its Service Classes mapped to Reporting 
               Classes.  The preceding PROC FREQ showed that the CPUTM  
               was exactly equal to the RPRTCLAS=' ' observations, and  
               that CPU72TM was exactly equal to the RPRTCLAS='Y' obs,  
               and that CPU72TM was less than CPUTM.  The PROC FREQ is  
               also useful since it shows the CPU time and the names of 
               all Service and Reporting Classes in the interval.       
Change 22.352  Test for short record expanded to test both LENMONI and  
VMACTMO2       LENGTH, because an archive file contained two 80-byte    
Jan 14, 2005   records that contained '4040'x for LENMONI.              
   Thanks to Tom Parker, CSC, USA.                                      
Change 22.351  HSM format MGHSMFU for 13 is 13:FULL VOLUME DUMP instead 
FORMATS        of 13:DELETE BACKUP VERSIONS, and descriptions were made 
Jan 14, 2005   clearer for migration formats.                           
   Thanks to Michael Yuan, University of California, USA.               
====== Changes thru 22.350 were in MXG 22.13 dated Jan 13, 2005=========
Change 22.350  New CICS/TS 3.1 variables WBREPRDL, WBREPWDL, PGCRECCT   
UTILEXCL       were found in PDB.CICSDICT and are now supported in the  
VMAC110        UTILEXCL member, and WBSNDOU1 test was corrected.        
Jan 13, 2005  -Duplicate variables were not removed from SORTTEST so    
               and additional DATA step was added to remove them all.   
               Without this change, 180 errors when TYPE110 was executed
               with IMACEXCL built by the earlier UTILEXCL.             
   Thanks to Tory Lepak, Aetna, USA.                                    
Change 22.349  Change 22.325 created SHORTCPS/PLCPRDYQ variables, but   
VMAC7072       negative values were found in a few TYPE70 observations. 
VMXGINIT       Those obs also had PCTMVSBY and CPUMVSTM negative, values
Jan 13, 2005   of MVSWAITx greater than DURATM, and unreasonably large  
Jan 29, 2005   IORATE values, at two sites, both using IRD (Intelligent 
               Resource Director, the WLM component that varies engines 
               on/offline as needed.  The occasionally bad data records 
               occurred with both z/OS 1.4 and 1.5, and all of the RMF  
               70 records with bad data had SMF70CNF bit 6 on ('02'x or 
               '03'x in MXG variables CAIx), and no observations with   
               bit 6 off had bad data values, and only some CPU Data    
               segments in each bad record had bad data.                
              -None of the LPAR bits indicated a change in CPUs, but in 
               one z/OS 1.5 case examined closely, in the LPAR segment  
               for the CPUID that had CAI='02'x, SMF70ONT was only 230  
               milliseconds less than SMF70INT/DURATM; the next interval
               shows that engine remained offline (CAI='00'x), so it    
               appears the bad data may only occur when IRD has varied  
               an engine off right at the end of an interval.           
              -When engines had been IRD'd on/off with good data, they  
               had SMF70ONT values that were a multiple of 10 minutes,  
               the normal WLM decision interval for varying engines.    
              -SMF70CNF bit 6 was documented in the SMF manual as       
                 "CPU reconfigured during the measurement interval (data
                 for this CPU is incorrect)"                            
               However, RMF Development now says that the "incorrect"   
               part of the doc is out of data, is no longer true, and   
               will be revised.                                         
              -Both sites had SLIH counts of 20-30 million in 900 second
               (15 minute) interval data, which was much above the value
               in normal observations from both sites.                  
              -Many obs had SMF70WAT (CPUWAITM) much larger than DURATM 
               in the observations with bit 6 on (as much as 26 Hours of
               Wait in a 15 minute interval) at one site, while the     
               second size always had SMF70WAT of zero when bit 6 was on
               (which is likely also wrong, as that would be 100% busy  
               for that engine, which was inconsistent with the other   
               engines in the LPAR for that interval).                  
              -One of the sites will opening a PMR with IBM, after I had
               extensive discussions with RMF Development, but that will
               require IBM Support to design a SLIP trap to diagnose the
               problem, which will take some time and effort by both IBM
               and the customer.                                        
              -I had revised MXG code to detect that CNF bit 6 is on, in
               this original change, so that you could choose to cause  
               those bad values to be instead be set to a missing value,
               simply by inserting this optional statement:             
                     %LET CNFBIT6=1;                                    
               after your //SYSIN.  And this change originally made the 
               MXG default to calculate the bad values, so that you'd   
               know they existed.  Fortunately, that bad data only      
               affects variables that are "MVS-specific" and are not the
               "mainstream" variables you use for CPU calculations; they
               have been there some time and were not observed until I  
               added the Short CPs variables.                           
               HOWEVER: UPDATE JAN, 2006:  SPLIT 70 Rewrite eliminated  
               the CNFBIT6 macro variable option, and these data are    
               always presented.  See change 23.321.                    
              -Several MXG sites without IRD have run the program and   
               none have seen the symptoms, but that's not conclusive.  
              -In conclusion, these MXG variables in PDB.TYPE70 and in  
               PDB.RMFINTRV (where not all are kept) may be negative or 
               incorrect with MXG's default                             
               when corresponding CAIx variables have 02x or 03x values.
              -Additional notes from RMF Development elaborate meanings:
                MXG Variable LPARCHNR='Y' if Bit 1 of SMF70PFG is on:   
                  Bit 1 of PFG (Number of Logical Processors has        
                  Changed) does not indicate any online/offline         
                  activity; it it indicates whether the number of       
                  logical processors changed and does not care whether  
                  those processors are online or offline or whether     
                  their on/of status changed.                           
                MXG Variable LCPUVARY='Y' if Bit 5 of SMF70VPF is on:   
                  Bit 5 of VPF (log proc varied online during interval) 
                  is only set when the processor turned ONLINE compared 
                  to the status at the end of the previous interval     
                  (this is more or less a bit from the old days, prior  
                  to WLM CPU mgmt).                                     
              -You can use the below program, to analyze your existing  
               TYPE70 data to see if the problem exists in at your site:
                 /* CNFBIT6 PROGRAM, EXAMINE SMF70CNF BIT 6 ERRORS  */  
                 /*  THERE ARE NO VALID OBSERVATIONS...             */  
                 PROC CHART DATA=PDB.TYPE70;                            
                 HBAR CPUWAIT1-CPUWAIT9 IORATE CAI1-CAI9;               
                 TITLE3 ONLINE STATUS OF 02-03 ARE SMF70CNF BIT 6 ON;   
                 LABEL SYSPLEX='SYSPLEX' SYSTEM='SYSTEM'                
                       MVSLEVEL='MVSLEVEL' DURATM='DURATM';             
   Thanks to MP Welch, SPRINT, USA.                                     
   Thanks to Chuck Hopf, MBNA, USA.                                     
   Thanks to Michael Oujesky, MBNA, USA                                 
Change 22.348  The actual variable names are CPUIFATM and CPUIFETM, but 
Several        there still were references in several members to the    
Jan 12, 2005   original-last-August names of IFACPUTM and IFECPUTM.     
   Thanks to Raimo Korhonen, CompMeas Consulting Oy, FINLAND.           
Change 22.347  The IMACEXCL member generated for CICS/TS 3.1 data could 
UTILEXCL       fail with 180 abend starting with variable PGTOTCCT.     
Jan 12, 2005                                                            
   Thanks to Victoria Lepak, Aetna, USA.                                
Change 22.346  PCTCPUBY for non PR/SM system was wrong; it was either   
VMAC7072       the busy of the last engine, or missing, if the last CPU 
Jan 12, 2005   was offline. And the IORATE was way wrong, as it was the 
               IORATE of the last engine, not the total of all engines. 
   Thanks to Mary Kay Pettengill, (i)Structure, USA.                    
====== Changes thru 22.345 were in MXG 22.13 dated Jan 12, 2005=========
Change 22.345  The support for Multi-System Remote Enclave CPU segment  
VMAC30         in Change 22.051 was flat out wrong; I was misled by my  
Jan 12, 2005   own error: my code INPUT the MOF/MLN/MNO triplet at the  
               same location as the ARM triplet offset.  The data DOES  
               agree with IBM documentation, and, with this change, the 
               IBM field names are the MXG variable names in TYPE30MR.  
               Note: the SMF30MRD/SMF30MRI CPU times are normalized by  
               MXG back to the system on which this type 30 was created,
               but both SMF30MRA and LOSU_SEC variables are kept in the 
               TYPE30MR dataset, in case you want to do it differently. 
               The sum of SMF30MRD/SMF30MRI in all MR segments in this  
               SMF 30 record are summed into variables CPUMRDTM/CPUMRITM
               which already existed in TYPE30_4(PDB.STEPS) and TYPE30_5
               and are now also kept in TYPE30_V (PDB.SMFINTRV).        
               However, CPUMRDTM/CPUMRITM are NOT added into CPUTM, at  
               least not yet by this change; since they have never been 
               right, they could not have been used, and it is not      
               clear exactly what use will be made of those CPU times   
               that occurred on other systems. Your feedback is wanted! 
               Especially, since I do not have any type 30 records with 
               the Multi-System segment with which to validate!!        
              -The original MXG variable names RMSU_SEC and MRENSYST are
               now replaced by SMF30MRA and SMF30MRS respectively.      
   Thanks to Robert Vaupel, IBM RMF Development, GERMANY.               
Change 22.344  If you have too many LPARs and LCPUADDRs, it is possible 
VMAC7072       for IBM to split your RMF 70 data into multiple physical 
Jan 11, 2005   records for each interval, and this is not YET supported 
               in MXG (because no one yet has actually made it happen). 
               At least now, MXG will detect the split records and will 
               alert you with error messages and hex dumps of the first 
               10 records with SMF70RAN non-zero, and will tell you that
               your TYPE70, TYPE70PR, ASUM70PR, ASUM70LP, and ASUMCEC   
               data are wrong, and that TYPE70 will have multiple obs   
               for a single RMF interval.  Eventually, MXG will support 
               the split records, and this change text will be revised. 
====== Changes thru 22.343 were in MXG 22.13 dated Jan 10, 2005=========
Change 22.343  Discussion and examples for building MONTHLY PDBs.       
JCLMNTH       -The existing JCLMONTH and JCLMNTH both assume you want to
JCLMNTHD       build your MONTH PDB on tape.  The original JCLMONTH read
JCLMONTH       five weekly PDBs and created MONTH as a sequential format
MONTHBLD       ("tape format") SAS data library, but there are multiple 
MONTHDSK       mounts and rewinds when multiple data steps are used to  
Jan  9, 2005   write multiple datasets to a seq-format library on tape. 
               So the JCLMONTH was revised (in 1987!) to write each     
               dataset first in sequential format to //TAPETEMP DD on   
               DASD, and MVS's MOD was used to add each dataset to the  
               end of the tape, to eliminate backspace/rewind delays.   
              -But even then, if your weekly PDBs were each on tape, the
               JCLMONTH required six tape drives, one for each weekly   
               PDB and one for the MONTH output data library.  So 1992s 
               JCLMNTH example enhanced the process by requiring only   
               one tape drive, by first PROC COPYing each weekly tape   
               PDB with SELECT of the needed datasets to temporary DASD,
               (with UNIT=AFF so only one tape drive was needed to read 
               all weekly PDBs), and then the MONTH PDB was created     
               using //TAPETEMP, MOD, and UNIT=AFF on the same drive.   
              -While both JCLMONTH or JCLMNTH were designed to write the
               //MONTH to tape, you could write MONTH to a DASD DD.     
               However, a data library in sequential (tape) format has  
               no directory, so you must read all N-1 preceding SAS     
               data sets to read the Nth dataset you wanted, wasting CPU
               and I/O.                                                 
              -In addition, you may have been wasting a lot of DASD     
               space if you wrote your //MONTH to DASD in sequential    
               format.  This entire discussion was precipitated when the
               reporting site's monthly job failed when it ran out of   
               disk space; they had moved from SAS V8.2 to SAS V9.1.3,  
               but were unaware they were creating their Monthly PDB in 
               sequential format:                                       
                 -Using SAS V8, V8SEQ, and COMPRESS=YES (MXG Default),  
                  and writing //MONTH to DASD in sequential format, they
                  needed only 55,830 tracks, because V8SEQ, SAS 8.2 and 
                  COMPRESS=YES did compress sequential format libraries,
                  but V9SEQ and SAS V9.1.3 does NOT compress seq format,
                  so its data library was 106,710 (uncompressed) tracks!
                 -So I had Chuck then run these benchmarks to reveal the
                  source of their ABEND:                                
                  Tracks   Engine   SAS Version  CPU sec   Compress     
                   34305   DASD V8    8.2        ---         Yes        
                  106710   V6SEQ      8.2         65         Yes        
                  106725   V9SEQ      9.1.3       26         No         
                  106725   V9SEQ      9.1.3       26         Yes        
                   34380   DASD V9    9.1.3      138         Yes        
                   63705   DASD V9    9.1.3       22         No         
                  106723   V8SEQ      8.2         22         No         
                   55830   V8SEQ      8.2        126         Yes        
                   34305   V8SEQ      8.2        133         Yes        
                   50145   V8SEQ      8.2         20         No         
                  106725   V8SEQ      9.1.3       26         No         
                  106725   V8SEQ      9.1.3       26         Yes        
                   34380   DASD V8    9.1.3      137         Yes        
                   63705   DASD V8    9.1.3       20         No         
                  -Even though COMPRESS was specified, not all engines  
                   and versions actually compress sequential format, but
                   that is what I want: if you are writing to tape, the 
                   IDRC hardware compress the tape, so you don't want   
                   SAS to burn CPU time to also compress the data.      
                   Furthermore, you can write a single SAS dataset to   
                   an extended-sequential, striped, hardware-compressed 
                   DASD device, which also shouldn't be SAS-compressed. 
                  -MXG CONFIGV9 still specifies V6SEQ today, because I  
                   cannot tell from within SAS if you are at V9.1.3, or 
                   if you have the critical Hot Fix for earlier V9s.    
                   Originally I recommended V6SEQ, even under SAS V8.2, 
                   because it did NOT waste CPU time by compressing.    
                   While V9SEQ eliminated that compression, prior to    
                   SAS V9.1.3, you MUST use V6SEQ, because there were   
                   data corruption errors using V8SEQ or V9SEQ under    
                   SAS V9s prior to 9.1.3.  If you have installed 9.1.3,
                   it is NOW safe for you to change CONFIGV9 to V9SEQ.  
              -So back to the new JCL examples, and documentation of all
               of your choices.  This change adds example JCLMNTHD and  
               member MONTHDSK, which should be used when yow want your 
               monthly on DASD, and your weekly PDBs are also on DASD.  
               Additionally, once you've built "Last Month's" PDB on    
               DASD, you can archive it to a tape GDG by using:         
                   PROC COPY IN=MONTH OUT=MNTHTAPE MT=DATA;             
               to write all of those datasets in a single write to tape 
               when you're finished with this month's reporting and then
               free up the DASD space.                                  
                 JCL      Code     Weekly  Monthly  Select   Tape       
                 Member   include    On      On     Copy     Drives     
                 JCLMONTH MONTHBLD  Tape    Tapes    No       Six       
                 JCLMNTH  MONTHBLD  Tape    Tapes    Yes      One       
                 JCLMNTHD MONTHDSK  Disk    Disk     No       None      
                 JCLMNTHT MONTHDSK  Tape    Disk     Yes      One       
              -To be complete, JCL example JCLMNTHT is created, but it  
               is likely to be unneeded - if you can't find space on    
               DASD for your weekly PDBs, then why try to write a month 
               to DASD?  (Perhaps, if you only build a small number of  
               datasets monthly, which is really what I personally think
               best - I only created the JOBS/STEPS/PRINT/RMFINTRV in my
               monthly, and did all of my other reporting week-to-week. 
   Thanks to Bruce Green, MIB, USA.                                     
Change 22.342  INCOMPATIBLE MXG CHANGE TO BUILDPDB, if you have tailored
BUILD001       your build to add SMF 115 or SMF 116 records.  If so, you
BUIL3001       MUST remove the references to 115 and/or 116 in the PDB  
BUILDPDB       you overlook this revision to your tailoring, your first 
BUILDPD3       test of the new MXG BUILD will fail, because of duplicate
BUILD606       dataset names being built in the first Data Step.        
Jan 10, 2005                                                            
Change 22.341 -If you have IFAs but don't have APAR OA09118 installed   
VMAC30         (adds CPUCOEFF to SMF 30), MXG-created IFAUNITS/IFEUNITS 
Jan  7, 2005   variables are missing, causing CPUUNITS to still include 
               the IFAUNITS.  Now, if there are RMF 72s from the same   
               SYSTEM in the SMF file that precede the type 30 record,  
               the old MXG logic to calculate EXCPRMF using CPUCOEFF    
               from RMF is used to also populate IFAUNITS and IFEUNITS  
               and to subtracts IFAUNITS from CPUUNITS.  If both the    
               IFAUNITS and EXCPRMF are still missing values, then both 
               the APAR is not installed and there was no RMF 72 record 
               from this system before that type 30 record.             
              -The IFA CPU time variables are now formatted TIME12.2.   
   Thanks to Bernie Pierce, IBM, USA.                                   
Change 22.340 -If zAAP engines are offline, MXGs PCTIFABY in TYPE70 was 
VMAC7072       100%, and IFAACTTM was equal to the DURATM, because MXG  
Jan  6, 2005   did not consider offline IFAs.  This change restructures 
               MXG code for IFAs, summing IFAs SMF70ONT into IFAUPTM and
               summing IFAs LCPUPDTM into IFAACTTM to calculate PCTIFABY
               and also new variable NRIFAONL, the number of IFAs that  
               were online (which, like NRCPUS, the number of CPs that  
               were online) can be a fraction if some are offline.      
              -The MXGCIN variable is also now correctly set to IFA even
               for offline IFAs.  The original NRIFAS variable is now a 
               count of installed IFAs, but is not used in calculations.
              -The IFAWAITn and PCTIFBYn variables (32 of each!) are no 
               longer created; they are not needed in TYPE70 and they   
               can be determined from TYPE70PR.                         
              -If CP engines were varied on/off, PCTMVSBY was wrong, as 
               it was calculated based on DURATM instead of SMF70ONT;   
               this also led to incorrect values of the new SHORTCPS    
               variable, that was added in Change 22.325.               
              -Mar 7, 2005: The MXGCIN 'guess' depends on IRD, because  
               variable SMF70SPN, the LPAR Cluster Name, is only found  
               in systems that are in an LPAR Cluster.                  
   Thanks to Dave Cogar, CA, USA.                                       
Change 22.339 -Major enhancement to TNG support:                        
EXTNT100-      The instance macro variables values and the MAXROW value 
EXTNT127       are now set dynamically from the input performance cubes,
EXTNT127       so you won't get any ARRAY SUBSCRIPT OUT OF RANGE errors!
FORMATS        The cube's headers are read in a quick pass of the input,
IMACTNG        and then used to write the %LET PPoooI=nnn; statements   
TYPETNG        (to //INSTREAM) for each object that was found in your   
TYPSTNG        input; the input is then re-read to create the output.   
VMACTNG        This will also minimize the amount of virtual storage    
VMXGINIT       required for the MXG job; a REGION of only 200MB was     
Jan  6, 2005   used for test data with many objects and many instances  
Jan 21, 2005   that previously required over 400MB.  And since the array
               size is now based on data, the default instance macro    
               variables in VMXGINIT are now all set to one, and metric 
               macro variables are back in the VMACTNG member, since    
               they are only changed when new metrics are added by CA,  
               and that requires other changes in the VMACTNG code.     
              -Support for 28 new NT objects with over 600 metrics:     
                   Dataset   dddddd    Object Name                      
                   TNT100    NT100     ASP.NET APPS V1.1.43             
                   TNT101    NT101     ASP.NET V1.1.4322                
                   TNT102    NT102     DOUBLE-TAKE CONNECTI             
                   TNT103    NT103     DOUBLE-TAKE KERNEL               
                   TNT104    NT104     DOUBLE-TAKE SECURITY             
                   TNT105    NT105     DOUBLE-TAKE SOURCE               
                   TNT106    NT106     DOUBLE-TAKE TARGET               
                   TNT107    NT107     FTP SERVER                       
                   TNT108    NT108     GOPHER SERVICE                   
                   TNT109    NT109     GROUPSHIELD FOR MICR             
                   TNT110    NT110     HTTP SERVICE                     
                   TNT111    NT111     INDEXING SERVICE                 
                   TNT112    NT112     INDEXING SERVICE FIL             
                   TNT113    NT113     MSEXCHANGE INTERNET              
                   TNT114    NT114     MSEXCHANGECCMC                   
                   TNT115    NT115     MSEXCHANGEDS                     
                   TNT116    NT116     MSEXCHANGEES                     
                   TNT117    NT117     MSEXCHANGEIMC                    
                   TNT118    NT118     MSEXCHANGEIS                     
                   TNT119    NT119     MSEXCHANGEIS PRIVATE             
                   TNT120    NT120     MSEXCHANGEIS PUBLIC              
                   TNT121    NT121     MSEXCHANGEMSMI                   
                   TNT122    NT122     MSEXCHANGEMTA                    
                   TNT123    NT123     MSEXCHANGEMTA CONNEC             
                   TNT124    NT124     MSEXCHANGEPCMTA                  
                   TNT125    NT125     SQLSERVER:BACKUP DEV             
                   TNT126    NT126     DATABASE                         
                   TNT127    NT127     RSVP SERVICE                     
              -When processing TNG data on ASCII platforms, which have  
               a default LRECL=255, you will need to add LRECL=32000 to 
               your FILENAME statement.                                 
              -Jan 20: temporary datasets used in _UTNGCNT now deleted. 
   Thanks to Peter Krijger, ANZ National Bank Limited, NEW ZEALAND.     
Change 22.338  The AUTOEXEx and CONFIGVx members now specify the option 
AUTOEXEC       DLDMGACTION=REPAIR for all platforms; the option causes  
AUTOEXEU       SAS to automatically repair and rebuild indexes and the  
CONFIGV8       integrity constraints, when a damaged SAS dataset is     
CONFIGV9       detected; the most common reason for a damaged data set  
Jan  4, 2005   is when it was left open because of a prior abnormal     
               termination (i.e., on z/OS, an x22 timeout ABEND). SAS   
               defaults are inconsistent, with z/OS having REPAIR for   
               batch and PROMPT for interactive, but FAIL for batch and 
               REPAIR for interactive for Windows systems.              
   Thanks to Dan Squillace, SAS Institute Cary, USA.                    
Change 22.337 -WARNING: BIT MASK .. TOO LONG because the RACF variables 
VMAC80A        KW23SPEC and KW23IGNR are only one byte each, but the bit
Jan  4, 2005   tests were wrong, and were testing for two bytes.        
              -Variable RACF07DT was increased to 200 bytes.            
   Thanks to Erling Andersen, SMT, DENMARK.                             
Change 22.336  Major enhancement: MQMACCT/MQMACCTQ data (SMF 116) can be
ASUMUOW        added to the PDB.ASUMUOW dataset for CICS transactions   
IMACUOW        created by MQ-Series (but you must enable their addition 
JCLMQMCI       in your IMACUOW member or in your input per comments.    
VMXGUOW        IBM does NOT provide the variables NETSNAME/UOWTIME in   
VMXGINIT       MQMACCT/MQMACCTQ datasets that are used to directly match
Jan 10, 2005   up to CICSTRAN data. (IBM MQ-series support claimed that 
               the STCK value in QWHCNID in MQMACCT could be used, but  
               its value is NOT the same as the UOWTIME STCK value.)    
               So this heuristic algorithm first matches CICSTRAN with  
               from CICSTRAN, which is then used to merge MQMACCT and   
               MQMACCTQ (which can have more than one obs per uow if    
               multiple MQ queues are used) with the CICSTRAN (and any  
               DB2ACCT data, although DB2ACCT data is not required).    
              -There is a clear exposure in using the TASKNR within an  
               APPLID to get the NETSNAME/UOWTIME from CICSTRAN, as the 
               IBM maximum for TASKNR is currently 99999, even though   
               the field is a PD4 that could contain 9999999, but there 
               is no other way at the present time.                     
              -You MUST have tailored either IMACUOW or ASUMUOW to even 
               create observations in PDB.ASUMUOW in the first place,   
               since the MXG default is to create zero observations.    
               You must re-tailor using the new IMACUOQ or ASUMUOW      
               member from this MXG to add the MQ Series variables.     
              -ASUMUOW will not fail, even if there are no MQ data.     
              -Variable MQTRAN counts the number of MQMACCT/MQMACCTQ    
               records that were included in the Unit of Work.          
              -MXG's BUILDPDB was revised by Change 22.342 to add the   
               processing of SMF 115 and 116 data in the default PDB.   
              -Member JCLMQMCI is a JCL example that uses VMXGUOW for   
               standalone processing of SMF for CICSTRAN, DB2ACCT and   
               SMF 116 data to create PDB.ASUMUOW with all three.       
              -MXG 22.12.  Error due to IMACUOW missing an end comment  
               symbol.  At the same time, CICSUOW dataset was           
               externalized by  MACRO _UOWICIC so that it's destination 
               can be overridden.                                       
              -VMXGINIT defines macro variable MXGMQADD, default blank. 
              -Cosmetic.  Using %INCLUDE SOURCLIB(ASUMUOW); with no DB2 
               observations caused UNINITIALIZED variable messages that 
               are now eliminated by adding compiler fakers for DB2PARTY
               QWACFLGS and QWHSSSID variables, and missing value notes 
               have also been almost completely suppressed.             
   Thanks to Ove Dall-Hansen, Codan Insurance, DENMARK.                 
   Thanks to Diane Eppestine, SBC, USA.                                 
Change 22.335  Unused Change Number.                                    
Change 22.334  Support for APAR OA06476 changes to RMF 74 records.      
EXTY748A      -Subtype 5 adds these new metrics to TYPE74CA dataset:    
EXTY748R          R7451CT1='BYTES*READ'                                 
EXTY748X          R7451CT2='BYTES*WRITTEN'                              
FORMATS           R7451CT3='READ*RESPONSE*TIME'                         
IMAC74            R7451CT4='WRITE*RESPONSE*TIME'                        
VMAC74            R7451PBR='PHYSICAL*STORAGE*BYTES*READ'                
Jan  1, 2005      R7451PRO='PHYSICAL*STORAGE*READ*OPERATIONS'           
                 "Millisec" values are formatted TIME13.3 (so a value of
                 99 milliseconds will print as 0:00:00.099).            
              -Subtype 8 creates three new datasets:                    
               TYPE78A -  ESS RANK ARRAY DATA                           
                R748AASP='ARRAY*SPEED*IN 1000*RPM'                      
               TYPE78R -  ESS RANK STATISTICS DATA                      
                R748RAIX='INDEX TO*FIRST ARRAY*SECTION OF*RANK'         
                R748RCNT='COUNT OF*ARRAYS*IN RANK'                      
               TYPE78X -  ESS EXTENT POOL STATISTICS                    
                R748XRNA='ALLOCATED*REAL*EXTENTS*IN POOL'               
                R748XRNS='REAL*EXTENTS*IN EXTENT*POOL'                  
                R748XSDY='SOURCES OF*DYNAMIC*RELOCATIONS'               
                R748XTDY='TARGETS OF*DYNAMIC*RELOCATIONS'               
                R748XVNS='VIRTUAL*EXTENTS*IN EXTENT*POOL'               
Change 22.333  Cosmetic. If you used "views" for MXG datasets that still
DOC            "housecleaned" with PROC DELETE DATA=_Wdddddd syntax, you
Jan  1, 2005   got a non-fatal SAS warning message; replacing the syntax
               with the preferred %%VMXGDEL(DDDDDD=dddddd); eliminates  
               the messages.  (All were oversights where VMXGDEL should 
               have been used.)  These members were revised:            
                VMAC29   VMAC30   VMAC50   VMAC79   VMACAIX  VMACCIMS   
   Thanks to Joe Babcock, Bank One, USA.                                
Change 22.332  Support for (Optional) ESS segment GEPARMKY field values 
IMAC6ESS       0036x=ESSRETAS, 0041x=ESSOFSTF, and 0043x=ESSOFSTB, plus 
VMAC6          correction for '034'x field, which can have time-in-text 
Dec 30, 2004   formats of 10:00  or 0150:00:00.                         
Jan  2, 2005                                                            
   Thanks to Dr. Alexander Raeder, Itellium, GERMANY.                   
   Thanks to Harmuth Beckmann, Itellium, GERMANY.                       
Change 22.331  Support for hIOmon File I/O Performance Monitor.         
VMACHIOM       This Windows family I/O monitor records activity at the  
Dec 30, 2004   individual file for each process for each user, with both
               I/O activity counts, Bytes read/written, and duration of 
               the I/O.  A special export option MXGall creates a csv   
               file of all 117 I/O metrics, with nulls for those fields 
               that are not being monitored, and that file is the file  
               supported in the TYPEHIOM code.  Only a single dataset is
               presently created, for both files and devices, but that  
               may change, based on user feedback.  The inexpensive I/O 
               monitor can be downloaded at, and 
               a free trial is offered.                                 
   Thanks to Tom West, hyperI/O LLC, USA.                               
Change 22.330  Documentation.  The CPUxxxTM variables created from SMF  
ADOC30         30 records were not fully documented; they are updated   
Dec 30, 2004   and identify what's included in which variables.         
   Thanks to Michael Bouros, Morgan Stanley, USA.                       
Change 22.329  Major enhancement to "PC Job Streams" for running MXG on 
BLDNTPDB       ASCII systems to create "SMF" or "NTSMF" PDB Libraries.  
BLDSMPDB       Uses the new VMXGALOC utility macro to allocate daily,   
VMXGALOC       weekly, and monthly PDB Directories, creating directory  
VMXGSUM        names that contain the DATE of the data, and logic to    
Dec 30, 2004   read the correct directories for the MONTH PDB.          
Jan 16, 2005  -UPCASE(KEEPALL) was added in VMXGSUM for pc execution.   
UTILBLDP      -Note: Only VMXGSUM was updated in MXG 22.13; the other   
TRND70         three members were not revised until Jan 16, 2005.       
ANALSHCP      -UTILBLDP now supports OUTFILE=INSTREAM, needed for the   
               BLDSMPDB enhancement that lets you specify BUILDPDB= to  
               use the tailored UTILBLDP output for your BUILDPDB code. 
              -UTILBLDP now has an internal table of SMF records that   
               are automatically created by MXG's default BUILDPDB, so  
               that your USERADD= list can be compared and errors       
               prevented if you list a record that's already in PDB.    
              -UTILBLDP/BLDSMPDB logic for OUTFILE argument is robusted.
               If the name is a PC dataset name it has to be inside     
               quotes, but if it is not (something like INSTREAM or like
               SOURCLIB(MYPDB) then it must NOT be inside quotes in your
               invocation. If a colon or backslash is found in your text
               it will be put in quotes and treated as a PC filename.   
              -TRND70 now adds PCTMVSBY SHORTCPS PLCPRDQY MAXSHCPS and  
               MAXRDYQ to TRND70 dataset.                               
              -ANALSHCP provides sample reports of SHORTCPs and PLCPRDYQ
               for your systems.                                        
   Thanks to Chuck Hopf, MBNA, USA.                                     
Change 22.328  Cosmetic, unless you used the _NTNG macro to null all of 
VMACTNG        the TNG datasets (the _NULL should have been _NULL_ in   
Dec 29, 2004   each of the lines in MACRO _NTNG), or tried to use the   
               _KTNT015 macro to tailor NT015 (it was spelled _KTNT016).
   Thanks to Freddie Arie, TXU, USA.                                    
Change 22.327  Cleanup of BUILDPDB/BUILDPD3.                            
BUILDPDB      -In BUILDPDB/BUILDPD3, TYPE30MR was not sorted into //PDB 
BUILD002       (unless you used BUILD002, which did contain _STY30MR).  
BUILDPD3      -Work datasets STEPS, STEPSIO, SPJB30T4 were created in   
SPUNJOBS       SPUNJOBS but were not deleted, now they are.             
Dec 24, 2004                                                            
BUILD005       in what I regard as an IBM Design Error, is accumulated  
BUIL3005       in the SMF 30 subtype 2 and 3 interval records; no other 
ONLYINTV       CPU metrics are accumulated in those records.  This means
Dec 24, 2004   that the TYPE30_V dataset built from SMF is no longer    
               valid.  But since MXG can correct IBM errors faster than 
               they can even acknowledge their errors (Level 2 says it's
               not their problem to fix), this redesign in BUILDPDB code
               deaccumulates the CPUCEPTM in the PDB.SMFINTRV dataset.  
                 (Of course, the CPUCEPTM will be missing in the first  
                  interval for each task that has more than one interval
                  record, since there is no prior interval record in    
                  "today's" SMF file.)                                  
               Dataset PDB.SMFINTRV is automatically built by BUILDPDB. 
              -If you want to create PDBINTRV.SMFINTRV (and the other   
               interval dataset, PDBINTRV.TYPE30_6) directly from your  
               raw SMF file, you can use this example that uses the     
               BUILDPDB logic, but builds only the PDBINTRV.SMFINTRV    
               and the PDBINTRV.TYPE30_6 interval datasets:             
                  //PDBINTRV DD DSN=YOUR.PDB.OUTPUT,DISP=(,CATLG),....  
                  //SMF      DD DSN=YOUR.SMF.DATA,DISP=SHR              
                  //PDB      DD UNIT=SYSDA,SPACE=(CYL,(5,5))            
                  //SPIN     DD UNIT=SYSDA,SPACE=(CYL,(5,5))            
                  //SYSIN DD *                                          
                   %INCLUDE SOURCLIB(ONLYINTV);                         
   Thanks to Tony Hirst, Wells Fargo, USA.                              
Change 22.325  Variable SHORTCPS=PCTMVSBY/PCTCPUBY is created in TYPE70 
VMAC7072       and TYPE70PR datasets, based on Kathy Walsh's Paper that 
Dec 23, 2004   was presented at SHARE in August, 2004, available at     
Jan 10, 2004     
Oct 12, 2004   WebIndex/PRS1077, titled                                 
               "Performance Impacts of Running CICS in a Shared LPAR".  
               The term 'Short CPs' was created by IBM WSC Performance  
               Staff, and is a performance effect created by the LPAR   
               hipervisor enforcing LPAR weights on busy processors or  
               capped LPARs, that can reduce the MIPS delivered by the  
               logical CPs to the partition.  She suggested that when   
               the SHORTCPS ratio exceeded 2, it could be a sign of     
               trouble.  But Don Deese pointed out that another way of  
               looking at the phenomenon is as a measure of the queueing
               delay when the LPAR is waiting for a CP engine to be     
               assigned, and that a ratio of 2:1 means that for 50% of  
               the elapsed time, the LPAR was waiting for a CP engine.  
               He suggests that even a lower ratio may be the threshold 
               of pain; a ratio of 1.5:1 means the LPAR was 33% waiting.
               Don is working on an extensive discussion of this topic  
               in the next release of his CPExpert product, and I have  
               created variable PLCPRDYQ=100*(PCTMVS-PCTCPUBY)/PCTMVSBY;
               so that you can use either the ratio or the percent of   
               time when there was a delay in your analysis to see if   
               this construct is useful in measuring your LPARs.        
   Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.  
   Thanks to Dr. Robert Cross, JP Morgan, USA.                          
Change 22.324  Cosmetic.  Missing value messages eliminated by testing  
VMACTNG        three NT006 fields before they are multiplied by 1024 or 
Dec 23, 2004   1024*1024.                                               
Change 22.323  Line 3624 should have named TOTSHARE TOTSHARC in KEEP=   
VMXG70PR       list for &OUT70LP dataset, instead of SYSSHARE CURSHARE, 
Dec 23, 2004   to keep those variables in the PDB.TYPE70LP dataset.     
   Thanks to MaryBeth Delphia, Texas Comptroller of Public Accounts, USA
Change 22.322  Hasty creation of JCL examples for MXG under SAS V9.1.3  
MXGSASV9       did not have sufficient testing; W-OH should have been   
JCLTEST9       W-zero, WORKVOL was not referenced in JCLTEST9, WORK     
JCLPDB9        sizes are all now 500,500, the WORK=200 in JCLPDB9 was   
Dec 23, 2004   removed (with only a primary allocation, you cannot use  
               multiple volumes), and comments with "V8" were revised to
               "V9".  The instream JCL PROC in the JCLTEST9 example now 
               matches the symbolics in MXGSASV9.                       
               Feb 23, 2005: This change originally changed the INSTREAM
               LRECL to 72, but Change 23.012 corrected that back to 80.
   Thanks to Bruce Green, MIB, Inc, USA.                                
   Thanks to Michael Gebbia, Eddie Bauer, USA.                          
Change 22.321  Type 6 PrintWay records apparently come in two flavors,  
VMAC6          and Change 22.302 did not protect both; in some records  
Dec 21, 2004   the SMF6PQNM is always 24 bytes, and SMF6PQLN is the     
               number of non-blank bytes, and in other records, SMF6PQNM
               is only the length of SMF6PQLN. (And, to make it more    
               fun, in VPS-FAX records, SMF6PQLN is always zero, but    
               PQNM is 24 bytes!).  Additional test for blanks when     
               SMF6PQLN is less than 24 bytes now protects INPUT        
               STATEMENT EXCEEDED error that occurred even with Change  
               22.302/MXG 22.12 installed.  And, variable SMF6PQLN is   
               now output in TYPE6 dataset.                             
   Thanks to Robert Vance, Zurich Insurance Co., USA                    
   Thanks to Reiner Luken, Zurich Insurance Co., USA                    
Change 22.320  This long-overdue enhancement for PDB.SMFINTRV combines  
BUILD005       the MULTIDD='Y' observations from TYPE30_V into a single 
BUIL3005       observation in PDB.SMFINTRV, with the correct totals for 
Dec 15, 2004   EXCPxxxx, IOTMxxxx, and TAPEDRVS variables for each SMF  
               interval.  There will be fewer observations created in   
               PDB.SMFINTRV, and variables EXCPNODD, IOTMNODD, and      
               TAPEDRVS are now correct for each interval.  Variable    
               EXTRADD is set to zero, since those extra DDs have been  
               consolidated in the single observation per interval.     
               Note: Long ago, the MULTIDD='Y' observations were summed 
               into the PDB.STEPS dataset in the BUILDPDB logic.  It    
               was only PDB.SMFINTRV that still contained MULTIDD='Y'   
                  MULTIDD='Y' - steps with more DDs than can fit in one 
                  SMF 30 record write multiple type 30 records; those   
                  additional records contain only IOTMxxxx,EXCPxxxx and 
                  TAPEDRVS values, and are flagged with MULTIDD='Y'.    
               See Change 23.015 if ERROR: PDB.SMFINTRV NOT SORTED is   
               encountered in your WEEKLY or MONTHLY PDB jobs.          
   Thanks to Mary Kay Pettengill, (i)Structure, USA.                    
Change 22.319  The R747AVFR/R747AVFT average frame size received/sent   
VMAC74         in dataset TYPE747P needed to be multiplied by four; the 
Dec 15, 2004   source fields are in words, and have 4 bytes per word.   
   Thanks to Pat Jones, DST, Inc, USA.                                  
Change 22.318  The JCLINSTL example used the SAS V8 JCL procedure; new  
JCLINST9       JCLINST9 had the minor changes to execute under SAS V9.  
Dec 15, 2004   The correct CONFIGV9 member and ENTRY=SAS are now in the 
               example that uses the site's installed SAS JCL procedure 
               to create the MXG Format library during install.  Once   
               this JCL example has been executed, the MXGSASV9 JCL proc
               should be use for all subsequent MXG testing/execution.  
   Thanks to Burchell Williams, HIPUSA, USA.                            
Change 22.317  The final @; was not correctly created in the second and 
UTILEXCL       subsequent GRNR's, when there were optional segments; at 
Dec 15, 2004   first, I blamed the conversion of CMODLENG from numeric  
Dec 21, 2004   to character was the culprit, and revised that logic in  
               the COMDNAME='USER' code segment to                      
               !!PUT(CMODLENG,4.)!!, but in fact the real error was a   
               hanging end-comment-*/ in line 745 that I had            
               accidentally removed during the testing of the CMODLENG  
               code change!                                             
   Thanks to Sally Jordan, Bear Sterns, USA.                            
   Thanks to MaryBeth Delphia, Texas Comptroller of Public Accounts, USA
====== Changes thru 22.316 were in MXG 22.12 dated Dec 11, 2004=========
Change 22.316  Enhanced Support for RMF III VSAM files have many added  
ASMRMFV        features and options, all of which are discussed in the  
ADOCRMFV       documentation note at the beginning of ADOCRMFV member.  
Dec 11, 2004   No changes are required to the CLRMFV nor TYPERMFV code. 
   Thanks to Jerry Urbaniak, Acxiom CDC Inc, USA.                       
Change 22.315  Example ASUM and TRND members for IBM SMF 94 VTS data.   
Dec 11, 2004                                                            
Change 22.314  Support for MainView for IMS IMF 4.1.00.  DSECTS show no 
TYPECIMS       changes in the IMF records for IMS Version 9.1           
Dec 11, 2004                                                            
   Thanks to Tony Curry, BMC, USA.                                      
====== Changes thru 22.313 were in MXG 22.12 dated Dec 10, 2004=========
Change 22.313  Optional field CMODNAME='DFHAPPL', CMODHEAD='APPLNAME'   
IMACICAP       had CMODIDNT='001', which tripped up MXG logic because   
IMACICD6       only CMODNAME=:'DFH' (starting with) was tested; '001'   
IMACICD7       generated an extra input of TRANNAME in the wrong place  
UTILEXCL       in IMACEXCL, which failed when it was executed.          
VMAC110       -All of the CMODNAME tests were revised to test for the   
Dec 10, 2004   full name (DFHTASK/DFHCICS/etc).                         
              -New exits for optional fields and variables created:     
                CMODNAME   CMODHEAD     EXIT         Variable           
                DFHAPPL    APPLNAME     IMACICAP     APPLNAME           
                CANDEXNM   CANDEXNM     IMACICD6     CANDEXNM           
                CANDEXTY   CANDEXTY     IMACICD7     CANDEXTY           
   Thanks to Sally Jordan, Bear Stearns, USA.                           
Change 22.312  Support for NetSpy Version 7.0 (COMPATIBLE).             
VMACNSPY      -New variables in NSPYTCP.                                
              -New variables in NSPYTCPS.                               
                NSPYUNOP NSPYUOUD NSPYURBS NSPYUSBS                     
   Thanks to Leon Schiebel, IBM Global Services, CANADA.                
   Thanks to Nick Varvarigos, IBM Global Services, CANADA.              
   Thanks to Norman Hollander, CA, USA.                                 
Change 22.311  Support for OS/400 5.3.0 for QAPMCONF, QAPMDISK, QAPMPOLL
VMACQACS       and QAPMJOBL data files/data sets.                       
Dec 10, 2004                                                            
   Thanks to Paul Gillis, Pacific Systems Management Pty, AUSTRALIA.    
   Thanks to Clayton Buck, UniGroup, Inc, USA.                          
Change 22.310  An OPTIONS SOURCE; statement inserted to circumvent a SAS
ANALRMFR       V8 compiler error under Win98 caused a compiler error on 
Dec 10, 2004   z/OS with SAS 9.1.3.  Using a conditional test resolved. 
   Thanks to Steve Gear, Schneider National, INC.                       
Change 22.309  Change 22.302 revised the IBM File Transfer segment code 
VMAC6          to support VPS, but I failed to test with IBM data after 
Dec  8, 2004   the revision, causing INPUT STATEMENT EXCEEDED, on IBM   
               data.  I was misled by IBM doc that said the SMF6PQLN was
               the "length of the significant portion" of SMF6PRTQ but  
               it's DSECT length was 24 bytes, so I assumed 24 bytes.   
               It turns out that SMF6PQLN is the length of the field,   
               so the INPUT was restored to variable length, and code   
               knows that the VPS record does always have 24 bytes, and 
               the SMF6PQLN field is 0 in the VPS record.  Both IBM and 
               VPS records have been tested with this change.           
   Thanks to George Waselus, State of Arizona, USA.                     
====== Changes thru 22.308 were in MXG 22.12 dated Dec  2, 2004=========
Change 22.308  Duplicate variable names in KEEP= list are detected by   
VMACTDSL       one of Freddie's many QA tests that read MXG source; most
Dec  1, 2004   were just duplicates, but the second instance of TDSL09PR
               should have been TDSL09PN.                               
   Thanks to Freddie Arie, TXU, USA.                                    
   Thanks to Jacky Hofbauer, Atlantica, FRANCE.                         
Change 22.307  MXG 22.10 & 22.11 only.  Support for IRD was STILL wrong,
VMAC7072       causing PCTCPUBY, PCTMVSBY, CPUACTTM and other PCTxxxxx  
Dec  1, 2004   to be wrong in ANY interval in which CPUs were varied by 
Dec  2, 2004   IRD.  If more than 33% of the engines were varied off,   
               some of those values could actually be negative values!  
               The revised NRCPUS calculation for IRD in Change 22.233  
               tested the LPARWLMG flag for the last LPAR (PHYSICAL)    
               instead of that flag for this MVS system's LPAR.  Now,   
               the correct LPAR's flag is used, and variable LPARWLMG   
               is kept in TYPE70 dataset so you can tell when IRD is    
               managing this system's CPUs. This change also protects   
               for manual vary of engines when IRD is not in control.   
               The magnitude of the numeric error depended on what pct  
               of the engines were offline; my IRD test data had 12     
               CPUs, and only 1-2 were offline, masking the problem;    
               it took negative values to cause me to see my errors.    
   Thanks to Dan Case, Mayo Foundation, USA.                            
Change 22.306  Support for CICS/TS 3.1: INCOMPATIBLE, as ALWAYS, since  
EXCICPIR       IBM CICS Development continues to insert fields in the   
EXCICPIW       middle of the existing SMF 110 subtype 1 CICSTRAN record.
EXCICWBG      -New variables added to CICSTRAN dataset:                 
EXCICWBR         DSCHMDCN='DSCHMDLY*COUNT'                              
FORMATS          DSCHMDTM='DSCHMDLY*DURATION'                           
IMACCICS         ICSTACCT='LOCAL*IC*START*REQUESTS'                     
Nov 30, 2004     L9CPUTCN='L9CPUT*COUNT'                                
Dec 10, 2004     L9CPUTTM='L9CPUT*DURATION'                             
Jan  2, 2005     MAXSTDCN='MAXSTDLY*COUNT'                              
                 PCDLCRDL='BYTES IN*DPL RETURN*CHANNEL'                 
                 PCDLCSDL='BYTES IN*DPL REQUESTS*ISSUED'                
                 PCRTNCDL='BYTES IN*PSEUDOCONV*CONTAINERS'              
                 WBCHRIN1='BYTES*RCVD FOR*RECEIVE OR*CONVERSE'          
                 WBCHROU1='BYTES*SENT FOR*SEND OR*CONVERSE'             
                 WBRCVIN1='RECEIVE OR*CONVERSE*REQUESTS'                
                 WBSNDOU1='SEND OR*CONVERSE*REQUESTS'                   
              -New SP, L9, X8, and X9 TCBs exist in CICS/TS 3.1 and CPU 
               time for each TCB is in CICSDS and CICINTRV datasets. The
               full list of CICS TCBs are:                              
                 TCB   VAR PREFIX  DESCRIPTION                          
                  QR      DSG      QUASI REENTRANT MODE                 
                  RO      DS2      RESOURCE OWNING MODE                 
                  CO      DS3      CONCURRENT MODE                      
                  SZ      DS4      SECONDARY LU MODE                    
                  RP      DS5      ONC/RPC MODE                         
                  FO      DS6      FILE OWNING MODE                     
                  SL      DS7      SOCKETS OWNING MODE (SL)             
                  SO      DS8      SOCKETS OWNING MODE (SO)             
                  J8      DS9      J8 - OPEN MODE                       
                  L8      DSA      L8 - OPEN MODE                       
                  S8      DSB      S8 - SOCKETS (SSL) MODE              
                  H8      DSC      H8 - NOT IN CICS/TS 3.1+             
                  D2      DSD      D2 - DB2 MODE                        
                  JM      DSE      JM - JVM CLASS CACHE MODE            
                  J9      DSF      J9 - OPEN MODE                       
                  SP      DSH      SOCKETS PTHREAD OWNING MODE (SP)     
                  L9      DSI      L9 - OPEN MODE                       
                  X8      DSJ      X8 - OPEN MODE                       
                  X9      DSK      X9 - OPEN MODE                       
              -New variables in CICCONSR Statistics Dataset (STID=52):  
                A14ESPCN A14ESPCS A14ESPCR A14ESTCN A14ESTCS A14ESTCR   
                A14ESICN A14ESICS A14ESICR                              
              -New DS4 variables for H8 POOL statistics are added to    
               dataset CICDSPOO (STID=60).                              
              -Four new Statistics Datasets are created; the full list  
               of all STIDs and their datasets is in ADOCCICS member:   
                  MXG                                        Symbolic   
                  Dataset                                    IBM        
                  Name    STID   Description of Data Set     Name       
                  CICWBG   101   URIMAPS (Global)            STIWBG     
                  CICWBR   104   URIMAPS (Resource)          STIWBR     
                  CICPIR   105   PIPELINE (Resource)         STIPIR     
                  CICPIW   106   WEBSERVICE (Resource)       STIPIW     
Change 22.305  INVALID NUMERIC DATA, 'TOTALS:' AT LINE ... COL ... and  
               due to IF NOT UPCASE(NAME)='TOTAL:' THEN DO;  syntax.    
               Using  IF NOT (UPCASE(NAME)='TOTAL:') THEN DO; or        
               using  IF UPCASE(NAME) NE 'TOTAL:' THEN DO;  corrects.   
   Thanks to Rodger Foreman, Acxiom, USA.                               
Change 22.304  Support for subtype 45 (PAGE SWEEP LIMIT EXCEEDED) record
EXHRN45        in ObjectStar SMF user records.                          
IMACHURN       The pdf documentation of this subtype is incorrect.      
VMACHURN       The first 64 bytes of the HU45MSG field are decoded into 
VMXGINIT       un-labeled variables HU45H1-HU45H5 (hex), HU45C1-HU45C3  
Nov 30, 2004   (EBCDIC text) and HU45N1-HU45N5 (numeric values).        
   Thanks to Mark King, S.A. Dept of Human Services, AUSTRALIA.         
   Thanks to Robyn Mcgeachie, S.A. Dept of Human Services, AUSTRALIA.   
Change 22.303 -MXG Change 21.251 added support for the optional new data
VMACSASU       in the SAS user SMF record, but MXG code was off by one  
Nov 29, 2004   byte, causing the last digit of JESNR to be lost.        
              -SAS Version 9.1.3 has SASVEREL ' 9.10', which SAS sets   
               for all 9.1 images (9.1.0 1MO, 9.1.0 1M2, and 9.1.0 IM3),
               and that will also be the value when SAS releases the new
               Service Pack levels starting with SP1.                   
              -The ENTRY had to be changed to SMFEXIT3 in BASMF job to  
               create the optional 64 bytes in the SMF User Record.     
                 //SYSLIN DD *                                          
                   INCLUDE SYSLIB(SMFEXIT)                              
                   ENTRY SMFEXIT3                                       
                   NAME SMFEXIT(R)                                      
   Thanks to MP Welch, SPRINT, USA.                                     
   Thanks to Wilson Chen, SPRINT, USA.                                  
   Thanks to Tom White, SPRINT, USA.                                    
Change 22.302  Support for VPS V1 R8.0 VPS-FAX, which uses the PrintWay 
VMAC6          file transfer segment to add information for TCP/IP print
Nov 29, 2004   devices.  Minor revision to MXG coding for that existing 
               segment will populate existing variable SMF6URI with:    
                 mailto:email address (primary recipient)               
   Thanks to Peter Harmut, R + V Versicherung, GERMANY.                 
Change 22.301  Use of ZEROOBS= parameter could fail due to incorrect    
UTILBLDP       tests for length of operands; using MACFILEX= option did 
Nov 29, 2004   circumvent the MXG coding error.                         
   Thanks to Willy Iven, Fortis Bank Belgium, BELGIUM.                  
Change 22.300  Using the FTP access method to read SMF data from one MVS
VMACSMF        system when MXG executes on a different MVS system fails 
Nov 26, 2004   needs JFCB=SMFJFCB on the INFILE SMF statement so that   
               either BSAM or VSAM SMF file can be read transparently,  
               but the FTP access method does not support that option.  
               Since that option is needed only to read VSAM SMF data,  
               and since the ftp access method itself does not support  
               reading any VSAM file, and because there is no way to    
               know that you have allocated your SMF filename using the 
               ftp access method, the solution is to create a macro     
               variable &MXGJFCB in VMXGINIT that is initialized to the 
               string  JFCB=SMFJFCB by default, and use that macro      
               variable in VMACSMF instead of the hard-coded option.    
               Then, if you want to use the FTP access method to read   
               SMF data from a different MVS system, you can eliminate  
               the SAS error by using                                   
                 %LET MXGJFCB= ;                                        
               to remove the JFCB option from MXG's INFILE statement.   
   Thanks to MP Welch, SPRINT, USA.                                     
   Thanks to Maurice Pascal, ???, ???                                   
Change 22.299 -STORHWMH and STORHWMK were defined in both _KUOWCIC and  
VMXGUOW        _KUOWCICX, but they are high water marks (maxima) and so 
Nov 26, 2004   should only have been maximized.                         
              -Macro _SUOWTMO did not correctly handle max and mins;    
               macros _KUOWCIX and _KUOWCIN were inserted after _KUOWIDC
               and _KUOWCIC as was done in _SUOWCIC.                    
              -Macro _SUOWTMO was reading the CICSTRAN dataset and not  
               MONITASK; SET _LCICTRN was changed to SET _LMONTSK.      
   Thanks to Erling Andersen, SMT Data A/S, DENMARK.                    
Change 22.298  MXG 22.11 only.  A missing @; caused SMF type 6 records  
VMAC6          with the "PrintWay" File Transfer Section to fail with   
Nov 22, 2004   INPUT STATEMENT EXCEEDED error                           
   Thanks to Randy Shumate, LEXIS-NEXIS, USA.                           
Change 22.297  Short 'IF' NDM/CDI record caused INPUT STATEMENT EXCEEDED
VMACNDM        error; instead of the expected 64 byte NDMRUID, there    
Nov 17, 2004   were only 45 bytes at the end of the record.  INPUT of   
               NDMRUID is now conditional if it exists.                 
   Thanks to Bernie Mazur, Bank of Montreal, CANADA.                    
Change 22.296  Processing CMRDETL data on ASCII platform failed because 
VMACMVCI       the INFILE statement and VMXGRFV attributes contained the
Nov 17, 2004   BLKSIZE= parameter, which is not supported on ASCII:     
                 Perhaps ASCII SAS should be smart enough to disregard, 
                 instead of fail, but since ASCII files are nothing but 
                 a single string of bytes, BLKSIZE has no meaning there.
   Thanks to Steven Olmstead, Thompson, USA.                            
Change 22.295  Variable ACCIPAD, IP Address, is now output in WSFEVTPR  
VMACWSF        as well as WSCEVTSC.                                     
Nov 16, 2004                                                            
   Thanks to Stephane Attouz, Infosud, FRANCE                           
Change 22.294 -Support for APAR PQ73385 which adds data to IFCID 217 and
VMAC102        to IFCID 225.                                            
VMACDB2       -Support for APAR PQ87848 which adds data to IFCID 173 to 
Nov 12, 2004   monitor Dynamic SQL Statements that exceed RLF ASUTIME   
               Limit (and issued SQLCODE905).                           
              -Support for APAR PQ91101 which adds more data to IFCID   
               225, and which added QISESTMT to DB2ACCT dataset.        
Change 22.293  In PDB.ASUM70PR and PDB.ASUMCEC, all LP0xxxxx variables  
VMXG70PR       for LPARNAME='PHYSICAL' are always missing values; at one
Nov  9, 2004   time, Amdahl used zero for a real LPAR, so MXG test for  
               LPARNAME didn't populate LP0xxxx variables unless it was 
               a real Amdahl LPARNUM=0).  But since Amdahl is now long  
               gone, it makes sense to populate the PHYSICAL LPAR data  
               in the LP0xxxx variables for consistency and so that the 
               newer PDB.ASUM70LP dataset can contain the data for the  
               LPARNAME='PHYSICAL'.  In PDB.ASUM70PR and PDB.ASUMCEC,   
               the existing LPPUPDTM and PCTPOV variables are unchanged,
               and the calculations that included LPPUPDTM and LP0UPDTM 
               are revised to not double account the PHYSICAL time.     
   Thanks to Anthony Lobley, EDS, ENGLAND.                              
Change 22.292  Debugging PUT statement is no commented out.             
VMACSFS        The Xerox SFS architecture is being replaced by an export
Nov  8, 2004   file produced by the Xerox Docutech 6135 network printer.
   Thanks to Robert McElhaney, Texas Workforce Commission, USA.         
Change 22.291 -Concatentating TNG files from multiple systems caused    
VMACTNG        incorrect results when the sets of fields were different;
Nov  8, 2004   values from the first system could be propagated into the
               subsequent system's output, because the initialization DO
               loop limit had the instance macro (&NT018I for example)  
               but the upper value should be  %EVAL(&NT018I*&MAXROWS).  
               In addition, the init of the NTxxxINM variables had to be
               relocated into their own DO loop.                        
              -New NT Platform Names of NTW400I, WNS502I, and XPP501I   
               are all supported.                                       
              -Also, NT Platform Names are now defined in a new _NTPLAT 
               macro, so that new TNG names can be added in only one    
               place, or can be added in your IMACKEEP member.          
   Thanks to Peter Krijger, ANZ National Bank Limited, NEW ZEALAND.     
Change 22.290  Enhancement for MQM processing creates new IHDRMQM exit  
IHDRMQMH       that can be used to select MQ records using variables    
VMAC115         MQMSSSID SUBTYPE SYSTEM STARTIME                        
VMAC116         SM115REL (blank if ID=116)                              
VMXGINIT        SM116REL (blank if ID=115)                              
Nov  5, 2004   Either member IHDRMQMH can be edited with your selection 
               logic, or %LET MQCMQMH= %QUOTE(your code;); can be used. 
               The existing TYPENQM member will process both SMF 115 and
               SMF 116 records in one pass.                             
   Thanks to Helmut Roese, COM Software, USA.                           
Change 22.289  The PDB.RMFINTRV dataset could have duplicate obs for the
VMXGRMFI       first hour, if your RMFINTRV logic summarized your detail
Nov  5, 2004   RMF data (e.g., written at 15 minutes, but you tailored  
               IMACRMFI or your RMFINTRV memer to create HOURLY data),  
               but only if some SMF records for that interval were in   
               yesterday's SMF and the rest of that interval's records  
               were in today's SMF data.  The MXG logic to calculate the
               MSU4HRAV was at fault, incorrectly combining the data in 
               SPINRMFI with today's data.                              
   Thanks to Normand Poitras, IBM Global Services, CANADA.              
Change 22.288  Comments in CICINTRV show how to create PDB.CICINTRV from
CICINTRV       SMF data; CICINTRV is automatically included by TYPS110  
VMAC110        and by BUILDPDB/BUILDPD3.                                
Nov  5, 2004   Default in VMAC110 now creates WORK.CICSACCT instead of  
               PDB.CICSACCT, so that a //PDB DD is not required if you  
               run %INCLUDE SOURCLIB(TYPE110).  CICSACCT has had zero   
               observations for years, but historically was written to  
               the //PDB library.                                       
   Thanks to Neil Ervin, Charles Schwab, Inc, USA.                      
Change 22.287  Enhanced %VMXGPRAL utility.  New option to run PROC FREQ 
VMXGPRAL       can be used to find out who's writing DB2 SMF 102 Trace  
Nov  4, 2004   Records with this example:                               
                - Note: the KEEP statement should almost never be used, 
                        but it turns out that by using MACDB2H to insert
                        that statement inside the READDB2 processing,   
                        only those variables listed will be output, so  
                        the Trace Datasets won't take much disk space.  
                  I first kept QWHCCV and QWHCCN, but the SMF 102 trace 
                  records do not contain the Correlation Header.        
   Thanks to Hoang Ho, Experian, USA.                                   
Change 22.286 -Two variables were not converted to EBCDIC when MXG was  
VMAC80A        executed on ASCII platforms:                             
Nov  4, 2004      RACF07DT ENTITYNM                                     
Nov  5, 2004  -Support for RACFTYPE=29 DTP adds variable RACF29AD to the
Nov  8, 2004   TYPE8020 and TYPE8021 datasets.                          
Nov  9, 2004  -RACFTYPE=42 DTP segment variable CLASNAME was not kept.  
Nov 10, 2004   In almost all datasets with variable CLASNAME, it comes  
Dec 10, 2004   from DTP=17 segments.  But datasets TYPE8024 and TYPE8X24
Dec  7, 2006   can have CLASNAME from DTP=21 and/or DTP=42 segments:    
                - TYPE8024 dataset can have both 21 and 42 segments, and
                  can have more than one DTP=42 segment, so that dataset
                  contains variables CLASNAME,CLASNAM1-CLASNAM4 from any
                  DTP=42 segments, and variable CLASNA21 from DTP=21s.  
                - TYPE8X24 dataset contains only DTP=21 segments, so the
                  variable name kept is CLASNA21, so as to matches the  
                  name in the related TYPE8024 dataset.                 
                  This text was revised 2006, no code was changed.      
              -Multiple RACFTYPE=24 DTP segments, up to fifteen, are now
               supported in RALTER (TYPE8020) and RDEFINE (TYPE8021) in 
               variables RESBYTE1-RESBYTEF and RESNAME1-RESNAMEF, like  
               the handling of multiple RACFTYPE=44 DTP segments in the 
               ADDUSER (TYPE8010) and ALTUSER (TYPE8013) datasets.  The 
               choice of 15 is arbitrary, and could be increased if it  
               is needed, or a secondary dataset could be created in the
               future if there are many more repeated segments in one   
               SMF 80 record.                                           
              -Multiple RACFTYPE=25 DTP segments in RALTER/DELMEM are   
               also supported, as above.                                
              -Note that some cases of multiple segments currently will 
               be created as separate observations in additional data   
               sets, rather than separate variables.  Specifically:     
                 Dataset   Command            Multiple Segments         
                 TYPE8X13  ALTUSER            40s                       
                 TYPE8Y13  ALTUSER            41s                       
                 TYPE8X24  SETROPTS           21s                       
              -Dataset Label for TYPE8X13 and TYPE8Y13 were corrected to
               ALTUSER (incorrectly had SETROPTS).                      
              -Variable RACF07DT is now correctly input and it length is
               set at $80 to hold installation data.                    
              -Variable RESBYTE uninitialized was corrected.            
   Thanks to Erling Andersen, SMT Data A/S, DENMARK.                    
   Thanks to Larry Krause, Rite-Aid, USA.                               
Change 22.285  Label values for two variables were incorrect/incomplete 
VMAC7072       and are revised to this description:                     
                   And PCTDLPDE is not a delay; only PCTDLCDE will show 
                   if there actually was a delay.                       
   Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.  
Change 22.284  Allocation Recovery subtype 7 (TYPETARC) support was not 
FORMATS        correct for variables after TARCDSN, now revised to match
VMACTMNT       the DSECT.  But the SMF records are not always correct;  
Nov  2, 2004   many have 0 for DEVNR and following fields, all have ACTN
               value 0, and ASID is only two bytes.  Those errors in the
               SMF record will be corrected in the next ASMTAPEE.       
   Thanks to Doug Medland, IBM Global Services, CANADA.                 
Change 22.283  Cosmetic. Error BIT MASK ... TOO LONG caused examination 
VMAC1415       of all bit tests and three members were found to have    
VMAC63678      bit literals that were not 8 or 16 symbols; fortunately, 
VMACF127       none of those tests are currently executed, but the code 
Nov  2, 2004   was revised nonetheless:                                 
              -TYPE1415 - bad test was inside ISAM code, not used now!  
              -TYPE6367 - VSAM catalog records no longer exist.         
              -TYPEF127 - FACOM operating system, probably defunct.     
Change 22.282  Variable DATETIME was missing, because MXG code to create
ASUMHSM        it from REQUEST was located before REQUEST was created;  
Nov  2, 2004   this caused WHERE clause errors in a tailored IMACSHFT   
Nov  5, 2004   member that used WHERE clauses and did not expect missing
               values in DATETIME (nor should it have, since the error  
               was in MXG, not in the tailored IMACSHFT!).              
              -SUMBY FSRTYPE SHIFT logic in the internal invocations of 
               ANALCNCR had to be revised to remove SHIFT from SUMBY, as
               it conflicted with SYNCINTV=YES default in ANALCNCR, and 
               the recalculation of SHIFT was relocated.  This change   
               also corrected deeper errors, and the number of output   
               observations in PDB.ASUMHSM is now correct.              
   Thanks to Karl Lasecki, Chemical Abstracts, USA.                     
   Thanks to Bruce Zink, Honda of America Manufacturing, USA.           
Change 22.281  RACF SMF80DTP 44 segment with only SEGNAME and no text   
VMAC80A        caused *** RACF EV(44) ERROR. INVALID RACFDLNN=0 and     
               hex dump of each record.  Code revised to protect zeroes.
   Thanks to Ike Hunley, Blue Cross Blue Shield of Florida, USA.        
Change 22.280  NRCPUS calculated in PDB.RMFINTRV using SMF70ONT could   
VMXGRMFI       have fractional values (0.999) instead of an integer when
Oct 29, 2004   IRD was not involved; the calculation was revised to add 
               0.005 and FLOOR/1000 to produce the expected integer.    
               Note that with IRD, fractional NRCPUS is very legitimate.
   Thanks to Thomas Heitlinger, FIDUCIA IT AG, GERMANY.                 
Change 22.279  Member TYPEVTOC is no longer executed in the test stream;
TESTOTHR       it caused 0C4s under SAS V9 because of CCHHR= operang,   
Oct 28, 2004   but it has been archaic ever since DCOLLECT/TYPEDCOL was 
               released.  Because it is no longer in the test stream,   
               the three datasets it created VTOCLIST,VTOCMAP,VTOCINFO  
               will no longer be documented in DOCVER.                  
   Thanks to Randy Shumate, LEXIS-NEXIS, USA.                           
Change 22.278  In (archaic) VMAC90, variable SMF9029N was changed from  
VMAC90         character to numeric in Change 21.320, but if you combine
Oct 28, 2004   TYPE90 built before and after that change, you got the   
               This change replaces SMF9029N with SMF9029X to avoid that
               error, but use of VMAC90A is the preferred solution.     
   Thanks to Andreas von Imhof, Rabobank, THE NETHERLANDS.              
====== Changes thru 22.277 were in MXG 22.11 dated Oct 26, 2004=========
Change 22.277  New argument MACFILEX allows you to insert SAS code after
UTILBLDP       the SMF header has been read (like MACFILE), for user    
Oct 26, 2004   tailoring of what records to read or not to read.        
Change 22.276  A utility to analyze the size of SAS data libraries, with
ANALSIZE       the number of datasets, number of variables, data bytes, 
VMXGSIZE       compressed bytes, and average compression percentages.   
Oct 26, 2004                                                            
   Thanks to Chuck Hopf, MBNA, USA.                                     
Change 22.275  The array LCUZ in data step C4 was changed to LCU1-LCU256
ANALPATH       and the final report will show up to 256 LCUs if present.
Oct 26, 2004                                                            
   Thanks to Harald Seifert, HUK Coburg, GERMANY.                       
Change 22.274  Variables TOTSHARE and TOTSHARC are now kept in both the 
VMXG70PR       PDB.ASUM70PR and PDB.ASUMCEC so the original and current 
Oct 26, 2004   total Weights are available; for summary intervals that  
Oct 27, 2004   had more than one RMF record, the weights from the first 
               record are kept.                                         
   Thanks to Chuck Hopf, MBNA, USA.                                     
Change 22.273  The variable PCTCPUBY in QAPMSYST is now set to a missing
VMACQACS       value, because there is no "total" CPU busy in QAPMSYST; 
Oct 26, 2004   it is still kept so your report programs won't fail with 
               VARIABLE NOT FOUND errors, but set missing because it was
               calculated from SHCPUTM, which is only the SystemTask CPU
               time.  New PCTCPTBY='PERCENT WHEN*SYSTASK*CPU BUSY' is   
               now calculated from SHCPUTM.                             
   Thanks to Chris Selley, Zurich, ENGLAND.                             
Change 22.272  Support for zAAP IFA engines now requires MXG 22.11 due  
VMAC30         to this change and change 22.265.                        
VMAC7072      =TYPE72GO Corrections:                                    
Oct 25, 2004  -New zAAP CPU time CPUIFETM was incorrectly adjusted with 
               R723NFFI from R723IFCT, but IFCT is the time when zAAP-  
               eligible work executed on a CP, and that work executes at
               the CPU speed, so the NFFI adjustment in MXG was wrong.  
              -Label CPUIAFTM='IFA*EQUIVALENT*CPU TIME' more accurately 
               describes the contents of that MXG variable.             
              -Variables R723IFCT (now, always equal to CPUIFETM), and  
               R723IFAT (unadjusted, equal to CPUIFATM ONLY if R723NFFI 
               is 256, and hence probably more confusing that useful),  
               are both now kept in TYPE72GO dataset.                   
              -Calculation of IFAUNITS, IFEUNITS was corrected, and the 
               code to subtract IFAUNITS from CPUUNITS was relocated.   
              =TYPE30 Corrections:                                      
              -All TYPE30 IFA/IFE CPU times were wrong: I could blame   
               IBM, because there are two undocumented bytes after the  
               SMF30TF2 field that caused misalignment (but my +2 after 
               the SMF30TF2 was also wrong, it is now +1 for the second 
               byte of TF2, but now there's a new +2 needed to skip over
               those undocumented two bytes). However, my guess that the
               new times were like the immediately preceding SMF30CEP   
               field (input PIB4.6, multiply by 1024) was also wrong;   
               the new CPU times are PIB4.2 without the multiply).      
               And the offsets in the SMF manual are wrong starting at  
               SMF30TF2. (In my defense, Change 22.221 did note that the
               changes had NOT been tested with data!).                 
   Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.  
   Thanks to Adam Warkow, Citigroup Technology Infrastructure, USA.     
Change 22.271  The Macro _LOGSMF, used to read log files (like NDM/CDI) 
VMACSMF        that have "SMF Records" without the SMF Header, did work 
Oct 23, 2004   when last tested, but DATA STEP STOPPED DUE TO LOOPING   
               error occurred using the TYPENDML example!  Inserting    
               INPUT @; after the ELSE DO; appears to now be required   
               by SAS, and eliminated that error.                       
   Thanks to Albert Jacobs, KBC, BELGIUM                                
Change 22.270  22.08-22.10 only. INPUT STATEMENT EXCEEDED RECORD LENGTH 
VMACDB2H       error with DB2 V8.1 SMF 100/101 records.  INPUT of new   
Oct 23, 2004   variable QWHSLOCO was PIB4, but the field is only PIB2.  
   Thanks to Roman Jost, ERGO Integration, NORWAY.                      
Change 22.269  MXG 22.07-22.10.  Six variables in TYPE71 dataset:       
Oct 23, 2004   had missing values, because an extraneous "V" was added  
               to each variable name in its INPUT statement, when I had 
               added the IBM SMF field name in comments on each line.   
   Thanks to Matthew Chappell, Queensland Transport, AUSTRALIA.         
Change 22.268  Support for VTS R7.3 adds many statistics to TYPE94 and a
FORMATS        few to TYPE94P; some 2-byte fields were expanded to four 
VMAC94         bytes, but existing, reserved bytes were used for the    
Oct 23, 2004   expansion, so the changes are compatible.  You can tell  
Oct 27, 2004   that R7.3 has been installed because S94LVVCF=730.       
               Oct 27: MXG 22.11 input these fields as $HEX2 per IBM doc
                       but IBM reports show them as decimal values, so  
                       they were changed to PIB2 numeric variables:     
Change 22.267  The debugging PUT statement at line 745 should have been 
VMACMVCI       removed; it could flood sysout with millions of lines of 
Oct 22, 2004   text:  COL=390 T6ECPRID=F5 AFTER F4X                     
   Thanks to Udo Froehline, Signal Iduna, GERMANY.                      
Change 22.266  Support for CMF Version 55.04 user SMF record (INCOMPAT).
VMACCMF        INPUT STATEMENT EXCEEDED for CMF Version 5504 because the
Oct 22, 2004   BMC user SMF record removed four fields from subtype 1;  
               CMFREC01 was changed by BPM8956/BPM9152.  MXG now INPUTS 
               those fields only for the old length of CMF01CSL=232.    
   Thanks to Peter Giles, Centrelink, AUSTRALIA.                        
Change 22.265  Support for APAR OA09118 adds the Service Definition     
VMAC30         Coefficients (CPUCOEFF,SRBCOEFF,IOCOEFF,MSOCOEFF) into   
Oct 22, 2004   the SMF type 30 records; these fields are needed now for 
Oct 25, 2004   zAAP calculations, but have always been wanted in SMF 30.
              -If the SDCs are in the SMF 30 record, variable IFAUNITS  
               will be non-missing, and variable CPUUNITS will contain  
               ONLY the CP TCB Service Units (i.e., IFAUNITS will be    
               subtracted from CPUUNITS if this APAR is installed).     
              -And if SDC values are present, the MXG-created variables 
               SRVTCBTM and SRVSRBTM will use the CPUCOEFF/SRBCOEFF from
               the SMF record, rather than the &CPUCOEFF/&SRBCOEFF macro
               default values of one, and CPUTOTTM will use the correct 
               SRVTCBTM/SRVSRBTM values.  See text of Change 22.022.    
              -This change replaced Change 22.256.                      
====== Changes thru 22.264 were in MXG 22.10 dated Oct 13, 2004=========
Change 22.264  Variable QTGSUSLM in DB2STATS was not deaccumulated, so  
VMACDB2        it have very large and meaningless values. DIF() logic   
Oct 13, 2004   was added.                                               
   Thanks to John Shuck, Suntrust, USA.                                 
Change 22.263  Revision of the original ANALDSET (DataSet Analysis) that
ANAL42DS       uses the TYPE42DS interval records instead of TYPE1415   
Oct 13, 2004   and TYPE64 close records.  However, only SMS managed DISK
               datasets are captured in TYPE42DS (but then ANALDSET only
               reports on CLOSED datasets, so both may be necessary!).  
   Thanks to Chuck Hopf, MBNA, USA.                                     
Change 22.262  Hardcoded DDNAME of PDB for PDB.DTSLOGPR and PDB.DTSCPU  
VMACNTSM       were replaced by their symbolic &PNTDTLP and &PNTDTCP.   
Oct 13, 2004                                                            
   Thanks to Matthew Chappell, Queensland Transport, AUSTRALIA.         
Change 22.261  The token for dataset TYPE4237 was missing from the _N42 
VMAC42         and _S42 macro definitions, so that dataset was not NULLd
Oct 13, 2004   if _N42 was used, or wasn't sorted if _S42 was used.     
   Thanks to Ambat Ravi Nair, ATOSORIGIN, SINGAPORE.                    
Change 22.260 -MXG Change 22.221 for z/OS 1.6 IFAs has now been tested  
VMAC7072       with real IFAs and found wanting, causing negative values
Oct 12, 2004   in PCTCPUBY and incorrect CPUWAITTM (but only for systems
               that actually have an IFA; there are NO errors using MXG 
               22.08+ with z/OS 1.6 if you do NOT have any zAAPs).      
               The code has been updated for all three configurations of
               Shared/Dedicated and Wait Completion Yes/No, but only the
               Shared, Wait Complete=NO data has been validated.        
              -New variable MXGCIN in TYPE70PR is an attempt to identify
               IFAs (which have SMF70CIN='ICF') from ICFs, with values: 
                 'PHY' - Physical                                       
                 'CP ' - CP Engine                                      
                 'VM ' - VM Engine                                      
                 'IFA' - IFA Engine                                     
                 'ICF' - ICF (Coupling Facilit) or IFL (Linux) Engine   
                 '   ' - SPARE Engine                                   
               but this is a heuristic algorithm based on my test data, 
               but could use validation with your system's data.        
              -New variables IFACROSS and IFAHONOR are now kept in the  
               TYPE72GO dataset, where they are created, instead of the 
               TYPE70 dataset, where I originally kept them.            
                 However: it really makes no sense for IBM to have put  
                 the global parameters in the service-class TYPE72GO    
                 records, but since that's where IBM put them, I have   
                 to do the same.                                        
              -I originally spelled IBM field R723IFCU as R723IFEU in   
               TYPE72GO dataset, trying to use "IFE" for IFA-Eligible   
               and "IFA" for IFA-Actual, but the variable name is now   
               changed back R723IFCU to be consistent with the IBM name.
              -The test data was from an early system, and these notes  
               may not be relevant to current IFAs, but are documented  
               in case these data are observed:                         
                - During Startup Interval, the IFAWAITM is slightly     
                  larger (tenths of a second) than the Interval Duration
                  which causes PCTIFABY to be slightly negative.  While 
                  I could detect and set PCTIFABY to zero, I will wait  
                  to see if this is actually necessary with your data.  
                - The PHYSICAL LPAR data has LCPUADDR values that are   
                  totally unexpected: 0,2,5,7,8,10,12,14,16,18,21,23,24,
                  for the 32 engines!  While this has no impact, it does
                  look strange; IBM says its working as designed.       
                  - Update from Martin Packer, Oct 17, 2005:            
                    It turns out there is an explanation: when LCPUADDR 
                    is displayed as a hex value, the first nybble is the
                    book number minus one, the second is the CPU number.
                    So the values above are for book 1 thru book 4, with
                    hex CPU numbers of 00,02,05,07,08,0A,0C,0E          
              -See Change 22.272, which corrected further errors and is 
               required for zAAP IFA processors.                        
   Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.  
Change 22.259  Variable NDMCPUTM had missing value in NDMPT dataset; a  
VMACNDM        circumvention now detects that "CPUTIME=" text is present
Oct 12, 2004   and inputs NDMCPUTM.                                     
   Thanks to Andreas von Imhof, RaboBank, THE NETHERLANDS.              
Change 22.258  All TRND.... members were enhanced with macro variables  
TRND....       &TRENDINP, &TRENDNEW, and &TRENDOLD (all of which are set
Oct 12, 2004   to "TREND" by default) so that you can override the MXG  
               default, and create a new TREND library, instead of reuse
               (so that your TREND libraries can be GDGs, which is      
               required for CA's 11 job recovery product).              
              -Summarization of DB2ACCTB (Buffer used by Plans) should  
               have had WEEK.DB2ACCTB instead of WEEK.DB2ACCT.          
   Thanks to Chuck Hopf, MBNA, USA.                                     
Change 22.257  Summarization of MXGTMNT Tape Mount Monitor data can now 
ASUMTMNT       alternatively use the STK VSM STCVSM13 and STCVSM16 data 
Oct 11, 2004   sets as input.  Comment blocks must be removed, and you  
               must provide a way to identify the VSM devices.          
Change 22.256  This change was replaced by Change 22.265.               
Oct 11, 2004                                                            
Change 22.255  MXG format $MGSASPR, which maps the SAS procedure name to
FORMATS        SAS Product Name, was updated for alternative spellings  
Oct 11, 2004   (eg., SUMMERY for SUMMARY).  The SMF record contains what
               name was typed in, but when incorrectly spelled, SAS can 
               often "guess" the correct procedure name, leaving the    
               wrong spelling in the SMF record.                        
   Thanks to Dr. Alexander Raeder, Itellium, GERMANY.                   
VMAC42         message caused only the last entry for that VOLSER to be 
Oct 11, 2004   not output in TYPE42VT dataset; all other entries were   
               correctly output.  Three tests for invalid length were   
               revised: each needed "-4" to be added to each test:      
                  0 LT S42VTVXO LT COL OR S42VTVXO+S42VTVXL-4 GT LENGTH 
                  0 LT S42VTVVO LT COL OR S42VTVVO+S42VTVVL-4 GT LENGTH 
   Thanks to John Parkes, Experian, USA.                                
Change 22.253  Change 22.211 required BLDNTPDB/BLDSMPDB invocation text 
BLDNTPDB       in your source code to be all lower case, but internal   
Oct 11, 2004   code in BLDNTPDB was incorrect; using upper case text    
               in your invocation caused errors in the Week and Month   
   Thanks to Terry Heim, ECOLAB, USA.                                   
Change 22.252  Variable QW0258TS is revised; it is input TODSTAMP8. and 
VMAC102        formatted as DATETIME21.2, and the divide by 4096 was    
Oct 12, 2004   removed.                                                 
              -All raw DB2 datetimestamps are on GMT clock, so each must
               be converted to local by the addition of GMTOFFDB, and   
               then each must then be in a %VMXGTIME call (in case your 
               site uses %TIMEBILD to convert all times to a different  
               time zone).  These variables were missing the GMTOFFDB   
               addition: QW0022TS,QW0022BT,QW0125TS,QW0316TS.           
               Also, extraneous refs for QW0260TS,QW0261TS,QW0262TS     
               were removed.                                            
   Thanks to Christa Neven, KBC, BELGIUM.                               
Change 22.251  Format $MGSTCMR, for the type of mount, had additional   
FORMATS        values '03'x thru '07'x that are now decoded.            
Oct 10, 2004                                                            
   Thanks to Gilles Fontanini, ABS Decision, FRANCE.                    
Change 22.250  Support for Release 3.5 of BETA93 product for subtypes   
FORMATS        0, 1, 2, 3, and 5 has been revised and 0-3 validated:    
VMACBETA      -Dataset BETA1 new variables:                             
                - However, the new REPRINT variables BETARPUS, BETAREPR,
                  BETABTKN, BETARMOD, and BETARBTK appear to be trashed 
                  in the SMF record, producing missing/strange values.  
              -Dataset BETA3 is now valid; most variables were missing. 
              -Dataset BETA5 new variables:                             
              -Some inconsistent variable names (FRM2,FRMX,EXT2,EXTX)   
               were eliminated.                                         
              -Other subtypes will be validated when sample records are 
               received; some timestamps are now SMFSTAMP8 format, but  
               only real records will reveal their internal formats.    
              -The subtype 50 record still has not been validly created 
               so it is not yet supported.                              
   Thanks to Graham Cornwell, Donovan Data Systems, ENGLAND.            
   Thanks to Klaus Messer, COMLAB GmbH, GERMANY.                        
Change 22.249  Support for TDSLink user SMF record creates 26 datasets: 
EXTDS01F        dddddd    dataset   description                         
EXTDS01I        TDS01T    TDSL01TC  TCP REJECTED PORTS                  
EXTDS01M        TDS01I    TDSL01IC  ICMP EVENTS                         
EXTDS01T        TDS01F    TDSL01FT  FTP EVENTS                          
EXTDS01V        TDS01X    TDSL01XO  XOT EVENTS                          
EXTDS01X        TDS01V    TDSL01VT  VTAM EVENTS                         
EXTDS04         TDS01M    TDSL01MV  MVS EVENTS                          
EXTDS06         TDS04     TDSL04    XOT CONNECTIONS                     
EXTDS07         TDS06     TDSL06    TCP CONNECTIONS                     
EXTDS08         TDS07     TDSL07    IP INTERFACES                       
EXTDS09         TDS08     TDSL08    LOCAL APPLICATIONS                  
EXTDS0A         TDS09     TDSL09    REMOTE APPLICATIONS                 
EXTDS0B         TDS0C     TDSL0C    TCP/IP STACK                        
EXTDS0C         TDS0A     TDSL0A    IP NETWORKS                         
EXTDS0E         TDS0D     TDSL0D    CSM BUFFERS                         
EXTDS0F         TDS0E     TDSL0E    PING OBJECTS                        
EXTDS10G        TDS0F     TDSL0F    MQ SERIES QUEUES                    
EXTDS10L        TDS10X    TDSL10XC  XCA HEADER                          
EXTDS10M        TDS10G    TDSL10GR  GROUP                               
EXTDS10R        TDS10P    TDSL10PU  PHYSICAL UNIT                       
EXTDS10S        TDS10S    TDSL10SK  SKLETAL PHYSICALUNIT                
EXTDS10X        TDS10L    TDSL10LU  LOGICAL UNIT                        
EXTDS11         TDS10R    TDSL10RX  CROSS DOMAIN RESOURCE               
EXTDS12         TDS11     TDSL11    CPU AND MEMORY                      
TYPETDSL        TDS12     TDSL12    DISK                                
Oct  7, 2004                                                            
   Thanks to Khalid Meskinia, SAS France, FRANCE.                       
   Thanks to Alain Delaroache, Atlantica (Credit Agricole), FRANCE      
   Thanks to Jacky Hofbauer, Atlantica (Credit Agricole), FRANCE.       
Change 22.248  ASUMCACH revised to tolerate zero obs in PDB.TYPE74CA.   
ASUMCACH       Previously, zero obs caused $CACHID format to not be     
Oct  6, 2004   created.                                                 
   Thanks to Jeff Harder, Indiana Farm Bureau, USA.                     
Change 22.247  Default test for Oracle SUBSYSID EQ 'OSDI' replaced the  
VMACORAC       SUBSYSID EQ 'TGW9' value, left after debugging.  If you  
Sep 30, 2004   re-define the _IDORACO macro in your IMACKEEP, it will   
               use your subsystem IDs, rather than the default in the   
               VMACORAC member, but 'OSDI' should have been the default 
               in the MXG code.  See also change 20.111 text.           
   Thanks to John Rivest, TDS Corporate, USA.                           
Change 22.246  Support for Demand Technology's NTSMF Release 2.4.7.     
Sep 30, 2004   has only seven variables, down from thirty nine.         
              -EPOXY object, dataset EPOXY, has two new variables.      
              -MSEXCHANGEIS MAILBOX object, dataset MSEXCHPU has six    
               new variables.                                           
Change 22.245 -Support for Velocity Software's XAMAP Release 3.4, which 
EXXAMSYT       is INCOMPATIBLE, because new SYTCUP segment with LPARNAME
VMACXAM        of "Totals:" had an invalid value for the number of LCPUs
Sep 30, 2004   causing INPUT STATEMENT EXCEEDED RECORD LENTH error if   
               Release 3.4 records are read without this change.        
              -The "Totals:" record is not output, as it duplicates the 
               CPU time in XAMSYT dataset, and caused 200% CPU busy's!  
               That tailoring code is externalized into the EXXAMSYT    
               exit member, if you ever decide you need it, unlikely.   
              -New variables are added to the XAMSYS dataset:           
                VL3RESVD VL3STNBY                                       
              -New variables added to the XAMSYT dataset:               
              -Additional data from SUBSUM, PRCIOP, and IODVSW will be  
               added later, when someone asks to use the new data, or   
               I get bored/caught up. The preceding changes are all     
               that are needed to keep your current reports valid, and  
               add those new variables.                                 
               This note will be revised when that happens.             
   Thanks to Tony Curry, BMC, USA.                                      
Change 22.244  RACF REMOVE event, dataset TYPE8023, did not decode the  
VMAC80A        Data Type 6 segment; the OWNER/GROUP and bit variables   
Sep 30, 2004   are now created.                                         
   Thanks to Robert D. Mitchell, UBS, USA.                              
Change 22.243  INPUT STATEMENT EXCEEDED if old VMACNSPY member (prior to
VMACNSPY       Change 22.131) read a NETSPY record that is a NETMASTER  
Sep 30, 2004   subtype.  NETSPY and NETMASTER are now combined and write
Referenced:    a single SMF record with both NSPY and NETM subtypes, and
EXNETM50       Change 22.131 added support to create both NETM and NSPY 
VMXGINIT       datasets from the single SMF record.  However, messages  
               INVALID NETSPY SUBTYPE were printed with Change 22.131,  
               and NETMASTER datasets all had zero observations, because
               the more robust test for NETMASTER subtype must be first,
               and the test for a NETSPY subtype can be executed when it
               is clear the record is not a NETMASTER subtype.          
               Note that TYPENETM will still process NetMaster subtypes 
               in the NETSPY record, but if you have added both NSPY and
               NETM logic to your BUILDPDB, either VMACNSPY will ABEND, 
               because both want to create the five NETMxxxx datasets.  
               You should remove NETM tailoring and use only NSPY to    
               create both NSPYxxxx and NETMxxxx datasets.              
              -This VMACNSPY requires MXG 22.02 or later, because 22.02 
               contained Change 22.037, which created the new EXNETM50  
               member and updated VMXGINIT to support the new NETM5000  
               NetMaster dataset.                                       
   Thanks to Andy Creet, Department of Defence, AUSTRALIA.              
Change 22.242  Example analysis provides Gartner Group with information:
ANALGART        Batch Workload (e.g., MVS Batch Percentage CPU)         
Sep 28, 2004    Interactive Workload (e.g., MVS/TSO Percentage CPU)     
                Online Workload (e.g., CICS,DB2,IDMS Percentage CPU)    
               across all partitions data.                              
               The example assumes your Batch Work is in WORKLOAD=JES2, 
               TSO in WORKLOAD=TSO, Enclaves in DDF, CICS in CICS, so   
               you may need to tailor those definitions, and then it    
               reads your PDB library and build a tailored "RMFINTRV"   
               dataset named GARTNER, and print a summary report.       
   Thanks to Atle Mjelde, Ergo, NORWAY.                                 
Change 22.241  Example summarization of the four IMF datasets:          
ASUMCIMS         PDB.ASUMIMTR :  /*SUMMARY OF CIMSTRAN */               
VMXGINIT         PDB.ASUMIMDD :  /*SUMMARY OF CIMSDBDS */               
Sep 28, 2004     PDB.ASUMIMDB :  /*SUMMARY OF CIMSDB2  */               
                 PDB.ASUMIMPR :  /*SUMMARY OF CIMSPROG */               
   Thanks to Ray Dorsing, Affiliated Computer Services, USA.            
Change 22.240  Support for z/VM 4.4 INCOMPAT changes in SYTCUP record.  
VMACVMXA       New LCPTYPE='HARDWARE*CPU*TYPE' variable inserted in the 
Sep 28, 2004   record is now supported.  As no other errors with data   
               from z/VM 4.4 have been reported, I can claim "support"  
               with this change, but there could be new data variables  
               that are not yet decoded.                                
   Thanks to Reinhard Lidzba, AGIS Allianz Dresdner, GERMANY.           
Change 22.239  Member ERRORASC shows ASCII platform errors that occur if
ERRORASC       you incorrectly download SMF data, and the member shows  
Sep 28, 2004   how to use the %UDUMPEBC utility to determine what is in 
               the downloaded file, and how to resolve the cause of the 
                 ERROR: Undetermined I/O failure.                       
                 ERROR: Unrecoverable I/O error detected...             
               This was originally in the undocumented "ERRORS" member, 
               but it contained unprintable characters that caused other
               problems when that member was downloaded, so the revision
               updated the contents and removed the unprintables.       
   Thanks to Dan Squillace, SAS Institute, USA.                         
Change 22.238  First pass at support for z/OS 1.4 SYSLOG file.          
SYSLOG        -Appends the type 'S' continuation record to create a     
Sep 30, 2004   single event record                                      
              -Creates LOGGROUP sequence number for multi-record SYSLOG 
               events.  See preliminary comments.                       
                 Please contribute suggestions for enhancements, as this
                 present implementation is still in first tests; some   
                 important LOG events may be create new datasets, etc.  
              -Original example completely replaced.                    
   Thanks to Freddie Arie, TXU Energy, USA.                             
Change 22.237 -To monitor STK tape devices with ML-31, you must use the 
VMACTMNT       XMEM=YES,MXIT=NO options when you assemble ASMTAPEE, to  
Sep 27, 2004   capture the job-level information via Cross Memory calls.
                 Instead, for IBM tape devices, MXIT=YES,XMEM=NO is used
                 to eliminate Cross Memory calls and capture all mounts 
                 in the IBM Volume Mount Exit - STK's HSC does not use  
                 that exit, so you still have to use XMEM, until we can 
                 find a usable HSC exit, research long underway.        
               Using the above options for STK caused DDNAME and STEPNR 
               to be blank/zero, because of a logic error in VMACTMNT:  
                 The MXIT architecture captures these new variables:    
                   ASID     INITTIME JOBCLASS LOCLINFO PGMRNAME         
                 and these old variables:                               
                   DDNAME STEPNR                                        
                 ML-31 SMF records have a new segment with those fields,
                 but they are not populated unless MXIT=YES was used;   
                 MXG incorrectly INPUT those variables if the segment   
                 was detected, causing the DDNAME/STEPNR fields in the  
                 new segment overwrote the valid old .  That logic was  
                 corrected in this change.                              
                -PDB.ASUMTAPE had missing values in RACFxxxx and ASID   
                 variables because of the TYPETMNT error; that blank    
                 DDNAME in TYPETMNT caused ASUMTAPE's merge of TYPETMNT,
                 TYPETALO, and IBM TYPE21 datasets to fail to correctly 
                 propagate old ASID variables from TYPETALO into the    
                 output PDB.ASUMTAPE dataset.  Fixing TYPETMNT fixed.   
   Thanks to Normand Poitras, IBM Global Services, USA.                 
Change 22.236  New ANALFLSH member tracks how many flash copies are run 
ANALFLSH       in each 15 minute interval, as lots of parallel flashes  
FORMATS        can degrade performance. New format $MG022ST decodes the 
VMAC22         copy status, and tests for LENGTH-COL were corrected to  
Sep 26, 2004   use LENGTH-COL+1 for the bytes remaining in the record.  
               Since multiple records are written from multiple systems,
               the ANALFLSH report must be tailored to select data from 
               only one system, since TYPE22_A dataset can have pseudo  
               duplicates.  The sort order for TYPE22_A was changed to  
               SYSTEM SMFTIME SMF22CUA SMF22VOL to remove acutal dupes  
               when TYPS22 is used to sort TYPE22_A dataset.            
Change 22.235  Support for ASG/Landmark TMON for DB2 Version 4.0.       
VMACTMDB       Only one dataset, TMDB7P appears to have been changed.   
Sep 26, 2004                                                            
   Thanks to Martin Legendre, Regie des Rentes du Quebec, CANADA.       
=Drove to East Coast(NYC, NJ, DEL) then drove thru Hurricane Ivan in GA 
=enroute to FLA (Wakulla County), then drove thru Hurricane Ivan again  
=one week later in Shreveport, LA.  Rain was 6 inches per hour, for     
=about an hour both times, but traffic only slowed to 60 mph.           
Change 22.234  Support for DB2 V8.1 IFCIDs 140,141,142,145 SQL text that
VMAC102        was relocated; without this change the QW014nTX variable 
Sep  9, 2004   was blank even when there was SQL text in the record.    
   Thanks to Ep van der Es, Dow, BELGIUM.                               
Change 22.233  MXG's calculation of NRCPUS when IRD was NOT active could
VMAC7072       be very slightly wrong, calculating 2.0020 for 2 engines.
Sep  1, 2004   The use of NRCPUS=ROUND(SMF70ONT/DURATM,.001) was the    
               cause, but by replacing that calculation with            
               the correct IRD calculation (LPARWLMG='Y') is done, and  
               for non-IRD, MXG had correctly counted the integer number
               of engines, which is unperturbed when LPARWLMG NE 'Y'.   
   Thanks to Al Sherkow, I/S Management Strategies, Ltd., USA.          
Change 22.232  CMR time is added to the calculation of MPL74 time:      
Sep  1, 2004   Originally, errors in the CMR field in the record caused 
               it to be left out, but APARs have corrected the value.   
               This agrees with Cathy Cronin's "FICON and FICON Express 
               Channel Performance Version 2.0" IBM White Paper.        
   Thanks to Ray Waugh, Merrill Lynch, USA.                             
Change 22.231  If an NTSMF data set was unlabeled, using %BLDNTPDB with 
EXNTDB2D       new PDB.DTSCPULP was build from two datasets by did not  
FORMATS        have a label.                                            
IMACNTSM      -FORMATS was updated with the $MGDDDDD and $MGDDDSN for   
VMACNTSM       all of the new NTSMF datasets.                           
VMXGINIT      -DATABASE object with 170 fields support added.           
Aug 31, 2004  -MSEXCHANGEIS object with 126 fields support added.       
               object with 28 fields is support added.                  
              -New objects DB2 DATABASE and DB2 APPLICATIONS with 94 and
               90 fields respectively create NTDB2DAT,NTDB2APL datasets.
   Thanks to Terry Heim, ECOLAB, USA.                                   
Change 22.230  Variable A17DTCFP, CFDT Pool Name was hex zeros rather   
VMAC110        than blanks when there was no pool name. MXG now tests   
Aug 30, 2004   and sets the variable to blanks instead of hex zeroes.   
   Thanks to Harald Seifert, HUK=COBURG, GERMANY.                       
   Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.  
Change 22.229  Cosmetic.  ABNDRSNC TERMIND UNINITIALIZED messages were  
BUILD005       printed the first time BUILDPDB/BUILDPD3 were executed,  
BUIL3005       with nothing in the //SPIN library, but those messages   
Aug 26, 2004   had no impact.  Compiler fakers suppress the messages.   
Change 22.228  Second instance of INCLASS in the KEEP list should have  
VMACTPMX       been INCLASSJ.                                           
Aug 26, 2004                                                            
   Thanks to Bruce W. Christopher, Housholde International, USA.        
====== Changes thru 22.227 were in MXG 22.09 dated Aug 25, 2004=========
Change 22.227  Typo left a start-comment /* as the last line of member  
VMAC99         VMAC99, which caused problems.  Stray text was deleted.  
Aug 25, 2004                                                            
   Thanks to Chris Weston, SAS ITSV Development Cary, USA.              
Change 22.226  Back-level ASG/TMON Version 2.0 records caused INVALID DO
VMACTMO2       LOOP CONTROL because I forgot that SAS won't tolerate a  
Aug 25, 2004   missing value and had added DO _I_=1 TO TAAMQCNT; without
               testing that TAAMQCNT had been input; it was a new field 
               in ASG/TMON Version 2.3 that was missing when 2.0 records
               were read. All the DO _I_ statements are now protected.  
   Thanks to Nori Abakah, Progress Energy, USA.                         
Change 22.225  ANALDB2R(PDB=PDB,PMAUD02=YES) caused FORMAT MGD140O NOT  
ANALDB2R       FOUND (but a $MGD140O did exist in the format library),  
Aug 25, 2004   because the variable that was PUT with $MGD140O format   
               did not exist, and thus was created as numeric, causing  
               SAS to look for a numeric rather than a character format.
               The variable did not exist because not all datasets that 
               ANALDB2R expected were in the PDB library.  If you use   
               %ANALDB2R(PDB=SMF...), it creates all needed datasets for
               the requested reprots; if %READDB2(INFILE=SMF,IFCIDS=...)
               is used to create a PDB, and all IFCIDs are not requested
               then using %ANALDB2R(PDB=PDB ..) may fail.  You can use  
               %READDB2(INFILE=SMF,CLASS=AUDIT...) to create a PDB with 
               all needed datasets for AUDIT reports (and that PDB will 
               have zero obs datasets for the IFCIDs with no records,   
               with all datasets created, all variables exist.  Seeing  
               this exposure, a "compiler faker" was added for each of  
               the character variables that are PUT with FORMAT, forcing
               those variables to be character variables, to circumvent 
               the error when all expected datasets are not present.    
   Thanks to Sharon Nagy, Comerica Bank, USA.                           
Change 22.224  SMF 6 or 57 record with ESS segment, but with SMF57TUL=0,
VMAC57         was not expected, caused INPUT STATEMENT EXCEEDED error. 
VMAC6          Since there was an ESS segment, text was assumed present!
Aug 24, 2004   Now, the text length is tested.  This text was revised   
Oct 26, 2004   Oct 26, when same error did occur with SMF 6 record.     
   Thanks to Scott Wiig, US Bank, USA.                                  
   Thanks to Jurgen Strauch, Zweckverband Kommunale Stuttgart, GERMANY. 
Change 22.222  NDM subtype QE record caused INPUT STATEMENT EXCEEDED.   
VMACNDM        The CDI DSECT does not agree with the record; the QTYPE  
Aug 24, 2004   field is only 1 byte in the record but the DSECT shows a 
Aug 26, 2004   halfword.  The Queue Status contains a valid 'SS', and   
               the SEQ field contains '0000'x, but the error was because
               MXG always expected that was followed by an 8-byte field 
               with SYSPLEX SERVER NAME, but that field does not exist  
               in all releases of NDM.  Code was added to conditionally 
               input SERVER NAME only when it exists for the QE, TP, PI 
               and FA subtypes, and all with SERVER NAME field.         
              -Invalid value for OFFSET to JOB DATA SET NAME protected. 
   Thanks to Gerrit Van Meerbeek, HP/Procter and Gamble Cie, BELGIUM.   
Change 22.221  Support for z/OS 1.6, but now, Change 22.272 is required.
VMAC30         Change 22.180 and prior APARs supportd most z/OS 1.6 new 
VMAC7072       data and changes in MXG 22.07 and 22.08, but TYPE72GO    
BUILD005       code (ONLY FOR z/OS 1.6 RECORDS) was wrong, causing many 
BUIL3005       INVALID DATA messages and incorrect output in TYPE72GO   
Aug 25, 2004   when z/OS 1.6 records were read (NO errors with 1.5 RMF).
               The SKIP=SKIP-16 needed to be SKIP=SKIP-28 in SUBTYPE=3  
               code block for LENSCS GE 532.                            
              -The extensive MXG Technical Note on IFAs/zAAPs in MXG    
               Newsletter FORTY-FIVE discussed MXG revisions to some of 
               the existing MXG variables; this change implements those 
               new calculations and new variables for TYPE72GO/TYPE70:  
              -In TYPE72GO:                                             
                 CPUIFATM - IFA CPU Time spent on IFA                   
                 CPUIFETM - CP CPU Time that was Eligible to run on IFA 
                 IFAUNITS - IFA Service Units spent on IFA              
                 IFEUNITS - CP Service Units that were Eligible for IFA 
                 CPUTCBTM - CP CPU Time (does NOT contain IFA CPU time) 
                 CPUUNITS = CP Service Units (NOT contain IFA Units)    
              -It is likely the VELOCITY calculations in TYPE72GO will  
               be changed, but this is just a note that they have NOT   
               been revised to include IFA samples.                     
              -TYPE70 dataset was revised to include only CP engines in 
               existing PCTCPUBY, CPUACTTM, etc, and labels now include 
               "CP" to identify.  New IFA Capacity Variables added.     
                 PCTCPUBY,CPUACTTM,CPUUPTM,CPUWAITM are all "CP-only".  
                 PCTIFABY,IFAACTTM,IFAUPTM,IFAWAITM are all "IFA-only". 
                 Individual PCTIFBYn and IFAWAITn variables exist for   
                 each of the possible 32 IFA engines.                   
                 IFAUPTM ='IFA ENGINE*AVAILABLE*(UP) TIME'              
                 NRIFAS  ='NUMBER OF*IFA*ENGINES*AVAILABLE'             
                 PCTIFABY='ALL IFAS*PERCENT*BUSY (DISPATCHED)'          
                 IFAWAIT0-IFAWAITX - IFA wait for each of 32 engines    
                 PCTIFBY0-PCTIFBYX - IFA PCT BUSY for each engine.      
              -This data has been tested with z/OS R 1.6 RMF 72 records,
               but not with IFAs installed, so please validate the      
               old and new percentages when you install an IFA.         
               Change 22.272 updates have been tested with 30s and 72s. 
              -TYPE30 variable's names were changed to be consistent:   
                 CPUIFATM='TOTAL*CPU TIME*ON*IFA'                       
                 CPUDFATM='DEPENDENT*ENCLAVE*CPU TIME*ON IFA'           
                 CPUEFATM='INDEPENT*ENCLAVE*CPU TIME*ON IFA'            
                 CPUIFETM='IFA-ELIGIBLE*CPU TIME*ON*CP'                 
               and these variables are added to the PDB.JOBS & PDB.STEPS
               in the BUILDPDB/BUILDPD3 logic.                          
   Thanks to Pat Curren, SuperValu Inc, USA.                            
Change 22.220  All 275 ADOC members were updated with new variables and 
ADOC....       the variable lengths were corrected back to their MVS    
Aug 22, 2004   lengths.  The text in these documentation members was not
               touched by the elegant utility that Freddie implemented, 
               which uses the text in DOCVER to update the variables.   
   Thanks to Freddie Arie, TXU, USA.                                    
====== Changes thru 22.219 were in MXG 22.08 dated Aug 20, 2004=========
MXG 22.08 was re-dated Aug 20, 2004, when I discovered seven members    
were missing from the 3480 tapes,including VMAC0 which caused JCLTESTx  
to fail.  The re-dated version included these additional changes:       
Change 22.219 -Variable DISKRATE was misspelled in two KEEP= lists ad   
VMACMWUX       DISKRT.                                                  
Aug 20, 2004  -Variable DISKNAME was increased to $64 as $20 was too    
               short; only $35 were seen thus far, but this will avoid  
               yet another change later, hopefully!                     
              -Comments revised to caution that a dollar sign should not
               be used as a delimiter, as dollar signs appear in the tty
               field in the MeasureWare PROC records.                   
   Thanks to Roman Gudz, Penske Logistics, USA.                         
   Thanks to Albert Jacobs, KBC, BELGIUM.                               
Change 22.218  The PDB exit _EDBJOBS was relocated so it precedes the   
BUILD005       OUTPUT ACCOUNT; statement; if you used the _EDBJOBS exit 
BUIL3005       to populate ACCOUNTn variables for Started Tasks that do 
Aug 20, 2004   not have accounting parameters on their "JOB" card, your 
               code worked just fine for the PDB.JOBS dataset, but the  
               observations in PDB.STEPS and especially in PDB.SMFINTRV 
               contained blanks for the ACCOUNTn variables, because the 
               ACCOUNT (temporary) dataset is used to "back fill" those 
               other PDB datasets.  With this code relocation, any exit 
               changes to ACCOUNTn variables will be propagated into the
               PDB.STEPS, PDB.PRINT, and PDB.SMFINTRV datasets.         
               Note:  It used to be that you HAD to use a table lookup  
                      based on JOB name to assign ACCOUNTn variables    
                      for STCs, but for all current OS/390 and z/OS,    
                      you can put account fields on the "JOB" card for  
                      the STC, and they will automatically be carried   
                      into the PDB.JOBS/STEPS/PRINT/SMFINTRV datasets.  
   Thanks to Ken Jones, Xwave, CANADA.                                  
Change 22.217  The extraneous IF in IF BYTEAVAIL=MAX(...) was removed,  
VMACNTSM       but it had no impact since the prior test for AVAILMEK   
Aug 20, 2004   was never satisfied.                                     
   Thanks to Xiaobo Zhang, ISO, USA.                                    
Change 22.216  The utility to convert character-variables-containing-hex
UTILCVRT       after you move SAS datasets from MVS to ASCII worked fine
Aug 20, 2004   but added temp variables LENGTH and _I_ to the output.   
               Now it doesn't, and LENGTH was respelled as _L_.         
   Thanks to Al Sherkow, I/S Management Strategies, Ltd., USA.          
Change 22.215  Creating CPU graphs of NT SMF data caused errors VARIABLE
Aug 20, 2004   sumby= statement was corrected and the DROP was removed. 
   Thanks to Matthew Chappell, Queensland Transport, AUSTRALIA.         
Change 22.214  Commas were missing after XX='EN' and YY='WO' in lines   
MXGSASV9       15 and 16 in the JCL procedure for SAS V9.               
Aug 20, 2004                                                            
   Thanks to Wade Peterson, McMaster-Carr Supply Company, USA.          
Change 22.213  Variable R723CRTF was not kept in the TRND72GO dataset   
TRND72GO       because it was misspelled as R723CRFT in the ID=         
Aug 19, 2004   statement.                                               
              -The default example TRND72GO summarizes at the SRVCLASS  
               level of detail, but you may prefer to summarize at the  
               PERIOD level, since Goals and Importance can be set at   
               the lower level.  You can add PERIOD at the end of the   
               SUMBY= statement in your tailored TRND72GO if you want   
               the PERIOD level included in the trending summary.       
   Thanks to Rick Mansfeldt, IBM Global Services, USA.                  
Change 22.212  The FTPREPLY field changed from a binary value to EBCDIC 
VMACTCP        numeric; APARs PQ92769 and PQ83055 documents this change 
Aug 18, 2004   in the format of the field; MXG code supports both the   
               old and the new format transparently.                    
   Thanks to Tom White, SPRINT, USA.                                    
Change 22.211  The JCL example for testing with SAS Version 9 needed the
JCLTEST9       //MONITASK and //SPIN DDs in step TESTOTHR.              
Aug 17, 2004                                                            
   Thanks to Paul Gillis, Pacific Systems Management Pty. Ltd           
VMAC84         the statement  LOCJSTOF+LOCJSTOF+48;  in VMAC84 should   
Aug 17, 2004   have been:     LOCJSTOF=LOCJSTOF+48;                     
   Thanks to Paul Gillis, Pacific Systems Management Pty. Ltd           
Change 22.209  While all INFORMAT xxx $NOTRAN statements were removed in
BUILD005       Change 22.192, using PROC SYNCSORT still caused BUILDPDB 
BUIL3005       to fail, because the SPIN.SPIN30_4 dataset had variables 
Aug 17, 2004   with that INFORMAT.  This change removes the informat for
               the two variables ABNDRSNC TERMIND as that dataset is    
               read, eliminating that (hopefully!) final exposure.      
               Alternatively, you could just use                        
                  DATA SPIN.SPIN30_4;                                   
                   SET SPIN.SPIN30_4;                                   
                   INFORMAT ABNDRSNC TERMIND ;                          
               to replace the SPIN30_4 data set and remove the INFORMAT.
              -I discovered the INFORMAT statement must be AFTER the SET
               statement to remove the informat from the variables!     
   Thanks to Michael L. Kynch, International Paper, USA.                
   Thanks to Peter Giles, Centrelink, AUSTRALIA.                        
Change 22.208 -Support for TOKDANAM=GID creates new variable TOKGID in  
IMAC6ESS       TYPE80xx datasets that can contain the 53 segment.       
VMAC80A       -Removed unneeded PUT statement in IMAC6ESS member that   
Aug 13, 2004   was observed in the log.                                 
   Thanks to Engelbert Smets, Provinzial Rheinland Versicher., GERMANY. 
====== Changes thru 22.207 were in MXG 22.08 dated Aug 13, 2004=========
Change 22.207  FLASH. For MVS SAS V9.1 and V9.1.2. SAS Note SN-12943    
CONFIGV9       reports incorrect results with PROC MEANS,SUMMARY,REPORT 
Aug 13, 2004   and TABULATE only on "MVS", if threading is used, and the
               SAS default option is THREADS.  Specifying NOTHREADS does
               corrects the error, which is fixed in SAS V9.1.3, and SAS
               will have a Hot Fix very soon for V9.1 and V9.1.2, but I 
               still decided this was sufficiently critical to re-date  
               the MXG 22.08 release and include NOTHREADS in CONFIGV9  
               member, since you could easily change that option in your
               CONFIGV9 later, or use OPTIONS= on your // EXEC statement
               when you have the fix and find threading is of value.    
   Thanks to MP Welch, SPRINT, USA.                                     
Change 22.206  Cosmetic.  Some fields caused 'Note 49' and blanks were  
VMACEREP       inserted, to support that future version possible change.
Aug 13, 2004                                                            
   Thanks to Thomas Heitlinger, FIDUCIA IT AG, GERMANY.                 
====== Changes thru 22.205 were in MXG 22.08 dated Aug 12, 2004=========
Change 22.205  New CICS Statistics datasets were not listed in IMACCICS,
IMACCICS       and worse, were not invoked in the _CICSTAT nor _S110ST  
VMAC110        macros, and the example to use both in Change 18.152 did 
Aug 12, 2004   not work.  The new datasets are now added/listed.        
              -The _S110ST macro sorts all CICS Statistics datasets from
               the "Wdddddd" work default (WORK) to their "Pdddddd" PDB 
              -The _CICSTAT changes both the _W and _Pdddddd names, to  
               the value (ddname) you stored in macro variable CICSTAT, 
               but could not be used with the _S110ST macro because the 
               same DD would be used for both _W and _P datasets.       
              -The new _CICSTAS (S=sort!) changes only the Pdddddd for  
               the output of the SORTs, so it can be used in EXPDBOUT   
               ahead of _S110ST to sort all CICS statistics datasets to 
               the DDname specified in macro variable CICSTAT.          
               To COPY all cics stats datsets to DDname "CICSSTAT", use 
                 %LET CICSTAT = CICSSTAT;                               
               in your EXPDBOUT member, and all of the CICS statistics  
               datasets will be CICSSTAT.CICxxxxx.                      
   Thanks to Nori Abakah, Progress Energy, USA.                         
Change 22.204  Support for new fields added by DB2 V7 and V8 in T102S172
VMAC102        for IFCID=172 (all units of work involved in a deadlock).
Aug 12, 2004   The test for QWHSRELN EQ 7.1 was changed to GE 6, as the 
Aug 13, 2004   "V7" data existed starting with DB2 Version 6.           
   Thanks to Andy Creet, Department of Defence, AUSTRALIA.              
   Thanks to Brad Kiemann, Department of Defence, AUSTRALIA.            
Change 22.203  Cosmetic. VGETJESN decodes JCTJOBID to create JESNR and  
VGETJESN       TYPETASK, but if JCTJOBID was hex zeros or blank, as for 
Aug 12, 2004   some records for JOB='INIT', unnecessary messages that   
               WARNING - TYPETASK NOT DECODED were printed on the log.  
               Now, VGETJESN tests to see that JCTJOBID is non-blank,   
               so the unnecessary warning messages won't be printed.    
   Thanks to Ng Kin, Acxiom, USA.                                       
Change 22.202  Cosmetic.  Invalid SMF 42 subtype 21 record cause MXG to 
VMAC42         print an MXG error message that APAR OA02184 corrects the
Aug 11, 2004   bad records, but that APAR only corrects errors when the 
               delete used ISPF STOW command; if the delete was done by 
               DESERV FUNC=DELETE, the record is wrong and IBM has just 
               created APAR OA08693 to correct that error.  The text of 
               MXG's error message said the record was DELETED, but at  
               the point of the error, MXG had already output TYPE4221. 
               The bad segment prevents an output to TYPE422A dataset,  
               so the text of the error message was clarified that it is
               the rest of the record that is being deleted.            
   Thanks to Scott Wiig, U.S. Bank, USA.                                
Change 22.201  Aren't you glad SAS developers use MXG for testing new   
VMXGSUM        releases of SAS?  Their early tests of SAS V9.2 found an 
Aug 11, 2004   MXG syntax error that had previously been absorbed with  
               no compiler error.  The text   %ELSE  %THEN  %DO; was    
               corrected to  %ELSE %DO;                                 
   Thanks to Rick Langston, SAS Institute Cary, USA.                    
Change 22.200  Variables SASVEREL SASUSER and SASJOBID are created by a 
VMACSASU       SUBSTR() of a $64 variable, so they defaulted to length  
Aug 11, 2004   of 64.  They are now defined in a LENGTH $8 statement.   
               These fields were added by Change 22.251, but, now, see  
               Change 22.303 for the (final?) correction.               
   Thanks to Dr. Alexander Raeder, Itellium, GERMANY.                   
Change 22.199  Major revision to IMS0708 dataset, created by TYPEIMS7,  
EXIMS78        from the IMS 07/08 log records.  Previously, transactions
EXIMSMRY       with the same DTOKEN were summed into only one output    
TYPEIMS7       observation, but that destroyed the detail "servictm" of 
VMACIMS        each program schedule event, and there can be thousands  
VMXGINIT       of Quick Restart program schedules with the same DTOKEN. 
Aug 12, 2004   And each program schedule event could have serviced many 
               (NMSGPROC) transactions for each detail event.  This     
               redesign eliminates the summarization by DTOKEN, creating
               one observation for each program schedule event, with the
               detail NMSGPROC, IMSCPUTM, etc., for each schedule event.
              -If both 08 and 07 are found, STRTTIME and ENDTIME will   
               be non-missing; if only an 07 end event with no matching 
               08 start is found, STRTTIME will be missing, and for an  
               08 only with no 07 start (or back-to-back 08s) ENDTIME   
               will be missing.                                         
              -For events with the same DTOKEN, new variable INSTANCE   
               counts individual event instances.                       
              -New variables SYSABEND and USRABEND decode the COMPCODE  
               into more meaningful variables in IMS0708 detail dataset.
              -VMACIMS had to be revised to increase the stored length  
               of IMSRECNO to 8 bytes; it is now used to sequence events
               within each DTOKEN. Originally it was a PIB4. field that 
               was stored in 5 bytes, but it was changed to a PIB8 field
               in IMS Version 6, and should have been increased then.   
              -VMXGINIT was updated to support the new tokens PIMS78 and
               PIMSMRY which can be used to set the DDNAME of IMS0708   
               and IMSSUMRY datasets.  The default value for the output 
               DD is the _IMSTRAN old-style macro, so if you have set it
               in your IMACIMS7 member to "IMSTRAN", the new TYPEIMS7   
               will still create IMSTRAN.IMS0708, or the example in the 
               TYPEIMS7 member shows you can use %LET PIMS78=IMSTRAN; in
               your //SYSIN stream to set the destination DDname.       
              -But in case you really want the summary by DTOKEN, new   
               IMSSUMRY data set can be created by the _IMSUMRY macro,  
               as documented in comments in TYPEIMS7 member.            
              -And the original TYPEIMS7 program is preserved in the MXG
               member ZTYPIMS7, just in case you feel a need to revert. 
              -The requestor of this change also wanted to create a new 
               dataset, IMSABEND, with only ABENDing transactions, but I
               decided against making that an "MXG dataset", because the
               IMACKEEP member and the _KIMS78 and _EIMS78 macros can   
               easily be used to create the new dataset, as shown below 
               in the example that also creates a new ORIGUSID variable 
               at the same time:                                        
                  MACRO _KIMS78                                         
                   ORIGUSID )                                           
                  MACRO _EIMS78                                         
                   IF '0' LE IMSUSID LE '9' THEN IMSUSID='INTERNAL';    
                   OUTPUT _LIMS78;                                      
                   IF COMPCODE NOT                                      
                     THEN OUTPUT IMSABEND;                              
               The use of the _Kdddddd and _Edddddd macros to create new
               datasets is documented in the DOCMXG member.             
   Thanks to Glenn Lundgren, SEB IT Service, SWEDEN.                    
Change 22.198  The PCTWFLOW calculation was revised to match the WFL %  
ZRBRPT3        value shown on the RMF III panels, using the revised     
Aug  6, 2004   equation from the RMF Programmers Guide that had been    
               overlooked since 1996.                                   
   Thanks to Randy Shumate, LexisNexis, USA.                            
   Thanks to Steven L. Hankins, LexisNexis, USA.                        
Change 22.197  The Ficon Open Exchange analysis program was revised to  
ANALFIOE       keep only Online channels, and to delete Ficon Bridge    
Aug  5, 2004   channels, to which the analysis does not apply.          
               The example in comments to create the datasets from SMF  
               was revised again, now using the three _Sdddddd dataset  
               sort macros instead of the _Sxxxx product sort macros.   
   Thanks to Dr. H. Pat Artis, Performance Associates, USA.             
   Thanks to Betty Wong, Bank of America, USA.                          
Change 22.196  Support for longer length DB2 identification variables:  
Aug  5, 2004   is prepared to read in the up-to-128-byte character text,
               but the length of those variables is not changed, yet.   
               Only when you actually increased-length data would you   
               want to increase their stored length in each observation 
               in your DB2ACCT dataset, and that can be done in your    
               //SYSIN in the job that creates your DB2ACCT data, using:
                  %LET MACFILE= %QUOTE( LENGTH QWHSLOCN $128;);         
               The longer fields can also now be in UNICODE, but until I
               have test data, and until there is a need, I chose not to
               to add that alternative code (UNICODE requires SAS V8,   
               and because the DB2 code is used in BUILDPDB, the longer 
               I hold off adding the UNICODE support, the longer those  
               few sites still running SAS V6 can limp along).          
   Thanks to Charles Harbour, John Deere, USA.                          
Change 22.195  INVALID DATA FOR YYYY warning for SMF 102 IFCID=22 when  
VMAC102        the QW0022TS field contained nulls; the inputs with NUM  
Aug  4, 2004   informat were protected with ?? syntax.                  
   Thanks to Jim Poletti, Edward Jones, USA.                            
Change 22.194  Typo.  SUN.ASUM79PR should have been SUN.ASUM70PR.       
Aug  4, 2004                                                            
   Thanks to Ingegerd Jansson, Volvo Information Technology AB, SWEDEN. 
Change 22.193  Support for many new NTSMF objects, including DTS CPU    
EXNTDTCP       configuration records, Exchange 2003, Exchange 2000      
EXNTDTLP       instant messaging, Outlook 2003, and RSVP objects create 
EXNTIACP       these new datasets:                                      
EXNTIAUP         dddddd dataset   description                           
EXNTMEII         NTDTCP DTSCPU    NT DTS.CPU                            
EXNTMSGC         NTMEII MSEXIM    NT MSEXCHANGEIM                       
EXNTRSVI         NTOUTL OUTLOOK   NT OUTLOOK                            
EXNTSMSM         NTRSVP RSVPSERV  NT RSVP SERVICE                       
Aug  3, 2004     NTSMSM SMSMSE    NT SMS SMSMSE 4.5                     
Aug  5, 2004  -Most of the sample data records from the test system have
               zero values, so it is impossible to know which, if any,  
               will need to be de-accumulated; if you have real data for
               any of these objects, please contact for 
               instructions on sending us your file for validation.     
              -The new DTSCPU and DTSLOGPR objects indicate HyperThread 
               Support and Status.  MXG merges the two objects into an  
               enhanced PDB.DTSLOGPR dataset (in the _SNTDTLP sort macro
               when you use TYPSNTSM) with the CPU information from the 
               DTSCPU object and the logical processor information from 
               the DTSLOGPR object.  HyperThreading is determine by:    
                 DTCPNLPS - Number of Logical Processors Supported      
                 DTCPNLPA - Number of Logical Processors Active.        
                                             DTCPNLPS       DTCPNLPA    
               Hyperthreading Unsupported:    missing         one       
               Supported/Disabled:           not missing      one       
               Supported/Enabled:            not missing   more than 1  
              -The new HyperThread objects were added structurally by   
               NTSMF 3.4.7, so this change supports that release.       
Change 22.192  All INFORMAT xxxx  $NOTRAN.; statements are removed from 
DOC            all source code.  That informat has never actually done  
Aug  2, 2004   anything; it was planned to "mark" the hex-containing    
               character variables, so SAS could detect NOTRAN and not  
               translate them, but that was never implemented in SAS,   
               and the circumvention (to use UTILCVRT instead) has been 
               provided in MXG since Change 19.271.                     
               Note that the $NOTRAN. format will always be created in  
               the MXG FORMATS member, to protect old MXG datasets.     
               The motivation for this change was the error in Syncsort 
               PROC SYNCSORT product under SAS Version 9.1.2, which does
               not correctly handle INFORMATs, and since the $NOTRAN was
               no longer needed, removing all will eliminate one more   
               possible error, if you have the PROC SYNCSORT product and
               they have not fixed their error when you install 9.1.2.  
               Search NEWSLTRS for PROC SYNCSORT for details.           
                  VMAC1415 VMAC21   VMAC22   VMAC28   VMAC33   VMAC36   
                  VMAC37   VMAC38   VMAC39   VMAC41   VMAC42   VMAC60   
                  VMAC6156 VMAC64   VMAC78   VMAC79   VMAC80   VMAC84   
                  VMAC88   VMAC89   VMAC8911 VMAC90   VMAC90A  VMAC91   
                 Subnote: in my class, discussing "sub-second" response 
                 response time, I compare measures of EDITing under TSO 
                 with three (okay, old!) connections: 2400 and 9600 baud
                 and local channel attached, and measured a max of 900  
                 "TGET"s (inputs) per hour.  This PC updated 120 members
                 took 20 minutes; there were at least one sequence of   
                 SELECT, FIND, MARK, DELETE, FIND, SAVE for each member,
                 so, without the delay due to TSO swapping, this  EDIT  
                 session exceeded 2100 transactions per hour.           
Change 22.191  Support for ASG/TMON TCE for CICS/ESA 2.3: COMPATIBLE, as
EXMONAMQ       all new fields were added at the end of records, so MXG  
IMACTMO2       21.21 or later will read the new records without error.  
VMACTMO2       The new version added many fields now supported in MXG in
VMXGINIT       the many TMON datasets, and one new dataset is created:  
Aug  2, 2004    Dataset MONITASK dataset new variables:                 
                 TAWRDCT  ='WAIT FOR*REDISPATCH*COUNT'                  
                 TAWRDTM  ='WAIT FOR*REDISPATCH*TIME'                   
                 TAUSRWCT ='USERWAIT*TIME'                              
                 TAUSRWTM ='USERWAIT*COUNT'                             
                Dataset MONISYST new variables:                         
                 TIUSRWCT='WAIT FOR*REDISPATCH*COUNT'                   
                 TIUSRWTM='WAIT FOR*REDISPATCH*TIME'                    
                 TIWRDCT ='WAIT FOR*REDISPATCH*COUNT'                   
                 TIWRDTM ='WAIT FOR*REDISPATCH*TIME'                    
                Dataset MONIAWT new variables:                          
                 TAAWTWRC='WAIT FOR*REDISPATCH*COUNT'                   
                 TAAWTWRT='WAIT FOR*REDISPATCH*TIME'                    
                Dataset MONICMX new variables:                          
                  TICMX   ='TICMX*SEGMENT*COUNT'                        
                Dataset MONIIWT new variables:                          
                  TIIWTWRC='WAIT FOR*REDISPATCH*COUNT'                  
                  TIIWTWRT='WAIT FOR*REDISPATCH*TIME'                   
                Dataset MONITJ new variables:                           
                Dataset MONIPA new variables:                           
                 PACBRNM ='CORBASERVER NAME'                            
                 PADSCWC ='STG CONSTRAINT WAIT COUNT'                   
                 PADSCWT ='STG CONSTRAINT WAIT TIME'                    
                 PADSMWC ='TCB MISMATCH WAIT COUNT'                     
                 PADSMWT ='TCB MISMATCH TIME'                           
                 PADSTHW ='PEAK OPEN TCBS'                              
                 PAEJBACT='BEAN ACTIVATION REQUESTS'                    
                 PAEJBCCT='BEAN CREATION REQUESTS'                      
                 PAEJBMCT='EJB METHOD CALLS'                            
                 PAEJBPCT='BEAN PASSIVATION REQUESTS'                   
                 PAEJBRCT='BEAN REMOVAL REQUESTS'                       
                 PAEJBTCT='TOTAL EJB REQUESTS'                          
                 PAHTDLYC='HOT POOL DELAYS'                             
                 PAHTDLYT='HOT POOL DELAYS TIME'                        
                 PAJ9CPUC='J9 CPU COUNT'                                
                 PAJ9CPUT='MODE J9 CPU TIME'                            
                 PAJTDLYC='JVM TCB DELAYS TIME'                         
                 PAJTDLYT='JVM TCB DELAYS'                              
                 PAKY9CPC='KEY 9 CPU COUNT'                             
                 PAKY9CPT='KEY 9 CPU TIME'                              
                 PAKY9DSC='KEY 9 DISPATCH COUNT'                        
                 PAKY9DST='KEY 9 DISPATCH TIME'                         
                 PAPTPWTC='PARTNER WAIT COUNT'                          
                 PAPTPWTT='PARTNER WAIT TIME'                           
                 PAROCPUC='RO CPU COUNT'                                
                 PAROCPUT='RO CPU TIME'                                 
                 PARODSPC='RO DISPATCH COUNT'                           
                 PARODSPT='RO DISPATCH TIME'                            
                 PASOI1C ='SOCKET CHARS RECEIVED'                       
                 PASOIMC ='SOCKET RECEIVE REQUESTS'                     
                 PASOO1C ='SOCKET CHARS SENT'                           
                 PASOOMC ='SOCKET SEND REQUESTS'                        
                Dataset MONIPA new variables:                           
                 PIKY9DST='KEY 9*DISPATCH*TIME'                         
                 PIKY9DSC='KEY 9*DISPATCH*COUNT'                        
                 PIKY9CPT='KEY 9*CPU*TIME'                              
                 PIKY9CPC='KEY 9*CPU*COUNT'                             
                 PIDSMWT ='TCB*MISMATCH*TIME'                           
                 PIDSMWC ='TCB*MISMATCH*WAIT*COUNT'                     
                 PIDSCWT ='STG*CONSTRAINT*WAIT*TIME'                    
                 PIDSCWC ='STG*CONSTRAINT*WAIT*COUNT'                   
                 PISOOMC ='SOCKET*SEND*REQUESTS'                        
                 PISOO1C ='SOCKET*CHARS*SENT'                           
                 PISOIMC ='SOCKET*RECEIVE*REQUESTS'                     
                 PISOI1C ='SOCKET*CHARS*RECEIVED'                       
                Dataset MONITKP new variables:                          
                Dataset MONITR  new variables:                          
                New Dataset MONIAMQ for MQ variables:                   
                 TAAMQOPC='MQOPEN*CALLS '                               
                 TAAMQOPT='MQOPEN*CALL*TIME '                           
                 TAAMQP1C='MQPUT1*CALLS '                               
                 TAAMQP1T='MQPUT1*CALL*TIME '                           
Change 22.190  Support for NTSMF Objects MicroStrategy Server Jobs and  
EXNTMSSJ       MicroStrategy Server Users create new datasets MSTRSRJB  
EXNTMSSU       and MSTRSRUS (MSTRSRJB is complete, but only structure   
IMACNTSM       code exists MSTRSRUS, with no fields, as the dictionary  
VMACNTSM       record for the User's object has not yet been created).  
VMXGINIT       Because some of the fields are presented as totals, and  
Jul 29, 2004   are not deaccumulated interval values, the _SNTMSSJ sort 
               macro must be used to de-accumulate the datasaet, so the 
               first observation for each instance has missing values.  
               Additional heuristics to detect when these total values  
               went to zero (perhaps a shutdown of the process?) were   
   Thanks to Bob Gauthier, Albertsons, USA.                             
Change 22.189  Major update added 1300 lines of text to document most of
ADOC110        the undescribed CICSTRAN variables, using IBM's CICS     
Jul 29, 2004   Performance Analyzer Report Reference 1.3 manual.        
Change 22.188  Variables S94VCA41-S94VCA48, S94CA481-S94CA488, and      
VMAC94         S94CA351-S94CA358 are all multiplied by 60 (so their     
Jul 29, 2004   internal value is seconds) and then formatted TIME8.     
               so they will print as hh:mm:ss units of time, since they 
               are all rolling average cache ages.                      
   Thanks to Bruce Widlund, Merrill Consultants, USA.                   
Change 22.187  The format to map SAS Procs to their Product for the SAS 
FORMATS        user SMF record was updated for PROC SORTT, which is an  
Jul 29, 2004   undocumented way of forcing the internal SAS Sort utility
               to be used instead of a "host" sort product.             
   Thanks to Dave Thorn, SunGard Availability Service, USA.             
Change 22.186  Omegamon/VTAM V520 IRNUM 29 caused DIVISION BY ZERO and  
VMACOMVT       LOOPING; the test for IRNUM IN (29,30) was incorrect for 
Jul 28, 2004   IRIND NE 'L'.                                            
   Thanks to Phil Baxter, Capgemini Group, ENGLAND.                     
Change 22.185  Invalid SMF 80 Extended Relocate Section contained token 
VMAC80A        PROGRAM but there was no length of program name nor the  
Jul 28, 2004   program name field following the token) caused and INPUT 
               STATEMENT EXCEEDED RECORD error.  Circumvention tests for
               expected length field, while IBM support is contacted.   
   Thanks to Engelbert Smets, Provinzial Rheinland Versicher., GERMANY. 
Change 22.184  ASCII Execution only, SAS V9 only: EBCDIC character      
DOC            variables can contain hex zeros instead of blanks due to 
Jul 28, 2004   a V9 SAS design change, which can cause character tests  
               to fail and/or cause spurious MXG error messages when an 
               expected character was not found.  Under ASCII execution,
               the $VARYINGn informat reads a variable length string,   
               but the value is "raw" and must be converted to EBCDIC if
               that's what's really in the text.  Previous to Version 9:
                  INPUT VARIABLE $VARYINGnn. LENTEXT @;                 
                  VARIABLE=TRANSLATE(VARIABLE,' ','80'X);               
               was sufficient: when LENTEXT was less than nn, $VARYINGnn
               returned ASCII blank '20'x for the extra characters, the 
               INPUT function converted them to '80'x, and thus the     
               TRANSLATE of '80'x back to blank was necessary.  Now, SAS
               V9 $VARYING informat returns hex zeros, rather than ASCII
               blanks for the extra characters, and the INPUT function  
               passes the hex zeros into it's output, so it is necessary
               now to use these statements for each $VARYING variable:  
                  INPUT VARIABLE $VARYINGnn. LENTEXT @;                 
                  VARIABLE=TRANSLATE(VARIABLE,' ','80'X);               
                  VARIABLE=TRANSLATE(VARIABLE,' ','00'X);               
               to convert those unexpected hex zeros to character blank.
               All 511 TRANSLATE statements with '80'x were replicated  
               and the '80'x changed to '00'x in the second instance in 
               these 55 MXG members:                                    
                 UTILXREF VMAC102  VMAC103  VMAC119  VMAC120  VMAC24    
                 VMAC33   VMAC37   VMAC42   VMAC4789 VMAC59   VMAC6     
                 VMAC60   VMAC6156 VMAC80A  VMACACC  VMACACF2 VMACASXT  
                 - An alternative was to replace the INPUT and TRANSLATE
                   functions with INPUTC(variable,'$EBCDIC.'); but its  
                   syntax needs additional quotes (the second argument  
                   is not an INFORMAT, but a literal/variable containing
                   an informat), the length has to be removed, (it fails
                   if the informat has an "n" value), and in some cases 
                   just didn't seem to work correctly (returned only one
                   character when there were three), all of which made  
                   it very unattractive to EDIT/CHANGE those many times!
                 - The TRANSLATE statement supports multiple pairs, so  
                   it could have been written as                        
                     VARIABLE=TRANSLATE(variable,' ','80'x,' ',00'x);   
                   but that too was mechanically risky, and was too long
                   for some existing lines of code, so a second function
                   statement was inserted.                              
Change 22.183  The Working Set Size variables ACTVWSS and VMDWSSPR are  
VMACXAM        in 4096 byte blocks, so they are now converted to bytes  
Jul 27, 2004   and FORMATed MGBYTES to "print pretty" storage units.    
Aug  8, 2004   Aug 8: Semi-colon added to FORMAT statement to correct   
               error detected in Freddie's QA tests.                    
   Thanks to Rodger Foreman, Acxiom, USA.                               
   Thanks to Freddie Arie, TXU, USA.                                    
Change 22.182  The field FCFILENM was truncated at 32 bytes; the INPUT  
VMAC119        was 64 bytes, but the statement MINLEN=MIN(32,LEN11903); 
Jul 26, 2004   is now corrected to MINLEN=MIN(64,LEN11903);.            
   Thanks to Ken Jordan, Pacific Gas & Electric, USA.                   
Change 22.181  Enhancements to RMF Reporting.                           
ANALRMFR      -Online Time Percentage field added to CPU Activity Report
Jul 26, 2004  -Updates to Partition Data Report                         
              -LPAR Cluster Report added, use REPORT=LCLUS to request.  
   Thanks to Jim S. Horne, Lowe's Companies, Inc, USA.                  
====== Changes thru 22.180 were in MXG 22.07 dated Jul 25, 2004=========
Change 22.180  IFA CPU variables added by APAR OA05731, Change 22.152   
VMAC22         variable names are clarified and more consistent:        
VMAC30          R723IFAT - IFA*CPU TIME*ON IFA                          
VMAC7072        R723IFCT - IFA-ELIGIBLE*CPU TIME*ON CP "C-for Coulda?"  
VMAC71         Some additional revisions were made for IFA processors.  
VMAC74         This change includes new fields added to RMF 74-5 by     
VMAC75         APAR OA04877.                                            
Jul 24, 2004                                                            
Change 22.179  The UCICSCNT utility to examine and count CICS records in
FORMATS        your SMF file was enhanced with additional reports on the
UCICSCNT       Statistics STIDs found in your data, and corrected so the
Jul 23, 2004   PROC FREQs always work without error.  New formats for   
               a description of STID and MNSEGCL are added in FORMATS.  
   Thanks to Tren Burner, City of San Antonio (TEXAS, of course), USA.  
Change 22.178  The INSTANCE=, argument allows selection by "UOWIDCHR",  
ANALDB2R       the first six bytes of UOWID (which is also QWHSLUUV),   
Jul 23, 2004   but the internal logic was wrong in ANALDB2R.  The test  
               and comments for how to use INSTANCE= were revised; the  
               value passed must be hex characters, with no quotes and  
               without the "X" that is used for hex literals in data    
               step logic.                                              
   Thanks to Jim Mourgelas, TD Bank Financial Group, USA.               
====== Changes thru 22.177 were in MXG 22.07 dated Jul 23, 2004=========
Change 22.177  Update to define MACRO _Vdddddd in selected members.     
VMACIDMS      -VMACIDMS: The _Sdddddd macros now invoke PROC SORT with  
VMACTMS5                 NODUP and the _Bdddddd macros are defined.     
Jul 22, 2004  -VMACTMS5: _Vdddddd defined.                              
Aug  8, 2004  -Aug 8: These members were EDITed and support _V macros:  
                   VMAC20   VMAC25   VMAC26J2 VMAC26J3 VMAC28   VMAC31  
                   VMAC32   VMAC33   VMAC36   VMAC37   VMAC38   VMAC39  
                   VMAC40   VMAC41   VMAC434  VMAC4345 VMAC44   VMAC4789
                   VMAC50   VMAC5234 VMAC535  VMAC5568 VMAC57   VMAC59  
                   VMAC60   VMAC6156 VMAC6367 VMAC68   VMAC69   VMAC7   
                   VMAC75   VMAC81   VMAC83   VMAC85   VMAC88   VMAC89  
                   VMAC8911 VMAC90   VMAC90A  VMAC91   VMAC92   VMAC94  
                   VMACTMNT VMACTPF VMACTSOM                            
   Thanks to Dale Houg, Abbott Labratories, USA.                        
   Thanks to Dr. Alexander Raeder, Itellium, GERMANY.                   
Change 22.176  Invalid SMF 42 subtype 5 caused INPUT STATEMENT EXCEEDED 
VMAC42         error; this record contained only volume segments, with  
Jul 21, 2004   422 valid segments, but the 423rd segment was overlaid.  
               It has valid S42VTNXT (00004FE4x) VOLSER (IMS210), DEVNR 
               (6BC5x) and S42VTFL1 (80x, indicating online), and 2 in  
               S42VTUNC, but the 2nd and 3rd offsets are overlaid:      
                S42VTVDO/S42VTVDL are '000000000000'x                   
                S42VTVXO/S42VTVXL are '000000006C87'x and               
                S42VTVVO/S42VTVVL are '0001C4C2F2C2'x,                  
               and the hex dump shows that last data is a VOLSER DB2B91 
               overlaying the third offset/length, and the rest of the  
               record is control unit information that doesn'b belong   
               there.  MXG added tests to detect these invalid offsets, 
               and prints error messages for the first five bad records,
               and prints a hex dump of the first bad record; variable  
               OFFVOL in the error message is the start of the defective
               volume segment.                                          
               This text will be updated when an IBM fix is identified. 
   Thanks to Richard Haynes, Blue Cross Blue Shield of Kansas, USA.     
Change 22.175  Major revision to this Utility to inventory the Contents 
UTILCONT       of SAS data libraries, reporting on size of each dataset 
Jul 21, 2004   in MegaBytes, and the percentage of the library occupied 
               by each SAS dataset. The inventory can be output to the  
               ASUMSIZE dataset, which could be added to your PDB and   
               then TRENDed over time to monitor growth of your PDBs.   
               But only datasets are reported; DICTIONARY.TABLES doesn't
               provide the size of CATALOGS (GRAPHS, SASMACR) in the    
               You can specify the list of LIBNAMEs to be inventoried   
               PDB=PDB WEEK MONTH (default is PDB=PDB), so to size the  
               datasets in yesterday's PDB in a standalone job on MVS   
               you would need to use this syntax:                       
                  // EXEC MXGSASV9                                      
                  //PDB DD DSN=YOUR.PDB,DISP=SHR                        
                  //SYSIN DD *                                          
               Under MVS, when you supply a list of LIBNAMEs, UTILCONT  
               issues a LIBNAME DDNAME SHR; statement for each LIBNAME; 
               the DICTIONARY.TABLES requires that each LIBNAME has     
               been 'referenced' (OPENed, or in a LIBNAME statement).   
               If any LIBNAME is sequential-format (e.g., tape), that   
               ENTIRE physical library must be read to find its size,   
               taking time and resources; you can skip reading of all   
               sequential format libraries using EXCLUDE=SEQUENTIAL,    
               or just don't put that LIBNAME in your list!             
               Instead, you can use PDB=_ALL_ to inventory all LIBNAMEs 
               that have been referenced; the _ALL_ choice enables the  
               default list to skip sequential and 'SAS-owned' LIBNAMEs 
               that we think you don't want reported, but you can use   
               %UTILCONT invocation if you do want sequentials reported.
               On MVS, the reported size closely matches the MVS dataset
               allocated size, but on ASCII platforms the actual files  
               are slightly larger than the reported size; the directory
               of variables is not included in pagesize*number-of-pages.
Change 22.174  Using the IDCAMS EXPORT Catalog function, the output file
VMACCTLG       always has a few defective records, but those records do 
Jul 20, 2004   not appear to actually contain any catalog segments. This
               change revises the old "NOT UNDERSTOOD" MXG messages with
               specific description of the two possible defects found.  
               IBM's "trench-holder" technican who "owns" the catalog   
               records refused to provide any documentation, claiming   
               the catalog records are "object code only", and their    
               contents could not be released, and his manager was also 
               unable to listen to reason (like, do they really think   
               think Microsoft is going to create a competing catalog   
               dataset, as kludgy as IBM's???), so I can only continue  
               to delete the defective records in the export file.      
              -The comments now contain the JCL for the IDCAMS program. 
   Thanks to Greg Burt, Fifth Third Bank, USA.                          
Change 22.173  Support for RMF 99 subtypes 3, 4, and 8 create four new  
EXTY99U3       datasets:                                                
EXTY994I         dddddd   dataset   description                         
EXTY998L         TY99U3   TYPE99_3  99-3 Service Class Period           
EXTY998P         TY994I   TYPE994I  99-4 Device Cluster                 
IMAC99           TY998L   TYPE998L  99-8 LPAR                           
VMAC99           TY998P   TYPE998P  99-8 Priority Table                 
VMXGINIT      -None of the "Plot" tables are created for these subtypes;
Jul 17, 2004   only tables that had test data are supported.            
              -I made blind guesses as to the format of two variables,  
               S998CPUT and S998PTMA.                                   
   Thanks to Richard S. Ralston, Humana, USA.                           
Change 22.172  ASCII only.  Zero observations in TYPEVVDS because the   
VMACVVDS       INPUT of VVRTYPE was $EBCDIC1. instead of $CHAR1.  Other 
Jul 17, 2004   HEX-containing variables were also corrected and INPUT   
               with $CHAR and formatted with $HEX.  On "MVS", $EBCDIC   
               and $CHAR are the same, but not so on ASCII platforms    
               This member was overlooked, because most sites use the   
               TYPEDCOL/DCOLLECT data to examine VVDS data, but the     
               TYPEVVDS has more detail information and is now correct. 
   Thanks to Glenn Bowman, Wakefern, USA.                               
Change 22.171  Enhancement for RMF III VSAM file reading program.       
ASMRMFV       -The very last CSR table entry was not being output.      
Jul 16, 2004  -RMFV104I message for RED record type always showed Y for 
               SELECT, even when that table was not selected.  Only the 
               message was incorrect; data exclusion did occur if RED   
               table was not selected.                                  
   Thanks to Jerome Urbaniak, Acxiom CDC Inc, USA.                      
   Thanks to Len Romano, Hewitt Associates, USA.                        
Change 22.170  Support for TNG NT Windows Server 2003 Enterprise Ed 5.2,
EXTNT067       PLATFORM='WNE502I', added 35 new objects, some of which  
  thru         are also created on PLATFORM='NTS500I.  New NT datasets  
EXTNT099       NT065 thru NT099 are documented in updated IMACTNG.      
FORMATS       -LENTEXT GT 99 tests caused errors with INSTANCE names    
IMACTNG        greater than 36 characters; all were revised to test for 
VMACTNG        GT 35 (TNG's base-35 encoding has '10'=36) to bump LOC   
VMXGINIT       by 2 positions; this should have been fixed earlier, but 
Jul 16, 2004  -New MIB-2 Object data had over 12,000 instances for three
               metrics, which makes little or no sense, and until that  
               data is better understood, only the first instance will  
               be output in new NT089 dataset.                          
              -If you use the distributed TYPETNG/TYPSTNG members, you  
               must remove the %LET MAXROWS=1; statement that was added 
               by Change 22.160 to override the MAXROWS=288 MXG default 
               (288 supports 24 hours of 5-minute-interval data cubes). 
              -With MAXROWS=288 and the MXG default array sizes, the    
               TYPETNG program now needs about 300MB of virtual memory. 
   Thanks to Peter Krijger, National Bank of New Zealand, NEW ZEALAND.  
Change 22.169  Support for Hogan System's optional CICS segment was not 
IMACICHO       complete; UTILEXCL recognized Hogan data was present, but
VMAC110        the IMACICHO member did not exist.  It does now, and will
UTILEXCL       create these four Hogan variables:                       
Jul 15, 2004     FPSAPPL - Application Code                             
                 FPSFUNC - Function Code                                
                 FPSCSCR - Current Screen                               
                 FPSSIPR - Previous Screen                              
               Old code in IMACICUS had additional Hogan variables:     
                 FPSACTN ='HOGAN*ACTION*CODE'                           
                 FPSOPTN ='HOGAN*OPTION*CODE'                           
                 FPSSCRN ='HOGAN*SCREEN*NAME'                           
                 PLDVERS ='HOGAN*PAS*VERSION'                           
                 TCTPLD  ='HOGAN*ODS TCTNAME/*PAS PLDNAME'              
                 TCBFUNC ='HOGAN*ODS TCT*TRANCODE'                      
               and those variables will be in the _VCICTRN macro if the 
               Hogan data is detected by UTILEXCL, but only the fields  
               actually created in your IMACICHO will exist in CICSTRAN.
   Thanks to Scott Wiig, USBank, USA.                                   
Change 22.168  Support for HMF V2.7 adds subtypes 26, 27, 28 creating   
EXTYHMFP        St  dddddd   Dataset   Description                      
VMXGINIT       Variables in TYPEHMFT TYPEHMFU stored in the original    
Jul  7, 2004   named/labeled variables; both 29 and 30 subtypes have    
               fewer variables, but Change 21.143 did not handle that   
               revision correctly.                                      
   Thanks to Perry Lim, Union Bank of California, USA.                  
Change 22.167  Variable STATIND in TYPE77 is a one byte numberic flag   
ADOC77         byte, but it should have been formatted as HEX2.  The bit
VMAC77         descriptions in ADOC77 were incomplete and incorrect, and
Jul  8, 2004   bit 6 ON was not even documented by IBM, but the bits are
               now correct.  A value of 03 is normal, as it indicates   
               that bit 6 and bit 7 are on, i.e., you have a GRS=STAR   
   Thanks to Rodger Foreman, Acxiom, USA.                               
Change 22.166  Support for STK ExHPDM user SMF record.                  
EXHPDM00          DDDDDD    DATASET   DESCRIPTION                       
EXHPDM02          HPDM00    HPDMAU00  AUDIT STARTUP/SHUTDOWN            
EXHPDM03          HPDM01    HPDMAU01  AUDIT CLIENT REQUEST              
VMACHPDM      -Problems in data:                                        
VMXGINIT       Variable SOV2DEVN, 'Device Definition Name' has '0E'x in 
Jul 19, 2004   in first byte, then 7 blanks in subtype 2, but is text   
               'DEVICE3' in subtype 3 records.                          
   Thanks to Al Holtz, MEDCO, USA.                                      
Change 22.165  BUILDPDB now detects "overlapped" SMF data was read in.  
BUILD005       If you read the same SMF file in two separate PDB runs,  
BUIL3005       or if you rerun BUILDPDB to re-create a PDB library and  
Jul  8, 2004   did not restore the SPIN library, there will be duplicate
Aug 25, 2004   observations in the SPIN30_1 dataset; MXG now detects the
Oct 28, 2004   duplicates, and prints ERROR. DUPLICATE TYPE 30 SUBTYPE 1
               messages on the SAS log.  I had considered ABENDing for  
               this condition, but in this implementation, only error   
               messages are printed.                                    
              -The symptom that detected this problem was a change in   
               the number of observations in PDB.SMFINTRV, and messages 
               the TYPE30_V interval dataset, because the SPIN30_1 data 
               is used to populate the ACCOUNTn variables in PDB.SMINTRV
               dataset, even though no interval records are "spun".     
              -For any rerun of BUILDPDB, you must restore the //SPIN   
               library to contain what it did before that failed run;   
               BUILDPDB automatically backs up your SPIN datasets into  
               the PDB library, so all you need do is to go back to the 
               last successfully build PDB library and restore the SPIN:
                 // EXEC MXGSASV9                                       
                 //PDB DD DSN=LAST.GOOD.PDB,DISP=SHR                    
                 //SPIN DD DSN=YOUR.SPIN,DISP=OLD                       
                 //SYSIN DD *                                           
                   PROC COPY IN=PDB OUT=SPIN;                           
                    SELECT SPIN: ;                                      
               and then you can rerun BUILDPDB with the SMF data that   
               failed; you may need to edit IMACZDAT to set the ZDATE   
               of the re-built PDB library, if you have skipped a day.  
              -Aug 25: Added restriction to only examine BAT/TSO/STC job
               records with a JES Number.  OMVS/USS creates multiple job
               initiate records with the same READTIME/JOB/JINITIME and 
               a missing JESNR that erroneously caused the "duplicate"  
               MXG message.                                             
              -Oct 28: Corrected tests for BAT to JOB and TSO to TSU, as
               those are the correct spelling of TYPETASK values.  With 
               original spelling, only STC tasks were being examined.   
               And the CRITICAL ERROR. DUPLICATE TYPE 30 message now    
               shows where the overlapped records were found.           
   Thanks to Tim Gilchrist, Department of Defence, AUSTRALIA.           
   Thanks to Pat Curren, SuperValu Inc, USA.                            
   Thanks to Udo Froehling, Signal-Iduna, GERMANY.                      
Change 22.164  The %VGETJESN invocation was moved after variable SYSTEM 
VMACSFTA       has been set.  Initially, I saw no error in my tests, but
Jul  8, 2004   the PUT in VGETJESN for error conditions had a blank for 
Aug 11, 2004   SYSTEM that was corrected by the relocation.  However, I 
               now have test data that failed with error messages that  
               NOTE: INVALID NUMERIC DATA, STEPNAME='XXXX' that were    
               corrected by this change, so it all depends on which of  
               the SoftAudit files have data as to whether this change  
               is cosmetic, or required!                                
   Thanks to Jim Kovarik, Aegon, USA.                                   
   Thanks to Ng Kin, Acxiom, USA.                                       
Change 22.163  The SAS User SMF record does not contain enough data to  
VMACSASU       permit the use of the NODUP option in PROC SORT to safely
Jul  7, 2004   remove duplicates; NODUP removed 51,596 non-duplicates   
               from 2,687,811 SMF records.  Using READTIME JOB SMFTIME  
               has only 10 milliseconds resolution, which is much larger
               than the elapsed time of many SAS steps, especially the  
               repetitive SORTing of small datasets.  A sequence number 
               of the proc/data step within the session is needed to be 
               able to safely remove duplicates, but for now, the NODUP 
               option was removed from the PROC SORT for TYPESASU, to   
               prevent the unwanted deletion of records that appear to  
               be duplicates, but aren't.                               
   Thanks to MP Welch, SPRINT, USA.                                     
Change 22.162  In TYPEBET0 dataset, new variable BETARETP, Retention    
VMACBETA       Period is now input as &PIB.4. where BETAEXPD was &PD4., 
VMACBE97       in VMACBETA, and in BETA974 dataset, variable B974XPDT is
Jul  7, 2004   input as &PD.4., as it is an expiration date.            
   Thanks to Ruben de Leeuwe, Independent Consultant, THE NETHERLANDS.  
Change 22.161  Support for optional ESS segment GEPARMKY=003B creates   
IMAC6ESS       variable ESSITRAY (INTRAY) and GEPARMKY=0045 creates the 
VMAC6          variable ESSPORNO (PORTNO) in TYPE6 when comment block   
Jul  7, 2004   in member IMAC6ESS is opened.                            
   Thanks to Engelbert Smets, Provinzial Rheinland Versich., GERMANY    
Change 22.160  TYPETNG/TYPSTNG default array sizes, based on actual TNG 
TYPETNG        data from a large site, requires REGION=280M, but this   
TYPSTNG        caused INSUFFICIENT MEMORY errors in TESTOTHR step of the
JCLTEST8       JCLTESTn test job for sites that didn't even have TNG.   
Jul  7, 2004   This change inserted  %LET MAXROWS=1; so that only 20M   
               is required, but a site with real TNG data will need to  
               remove that statement, and may need 280M.  However,      
               sites with TNG should  read Change 21.269 which discusses
               other MXG facilities for actual processing of TNG data.  
   Thanks to Pius Nwaobasi, IBM Global Services, USA.                   
Change 22.159  Variable SMF89LPI now always contains the correct LPAR ID
VMAC89         whether less than or greater than 15, and SMF89LP3 is no 
Jul  5, 2004   longer kept, now that doc indicates what both contained. 
Change 22.158  "Support" for JMF SMF 84 subtype 10, but only the header 
EXTY84A        variables are input; no one has actually ever requested  
VMAC84         MXG to support this JES3-only SMF record, and I'd be very
VMXGINIT       pleased if no one ever does.                             
Jul  5, 2004                                                            
Change 22.157  TYPE78IO new variable:                                   
VMAC78           R783GFLG='IOQ*GLOBAL*FLAGS'                            
Jul  5, 2004                                                            
Change 22.156  TYPE73 new variables added by z/OS 1.5:                  
VMAC73           CHANDCMG='CHANNEL*PATH IS*DCM*MANAGED'                 
Change 22.155  TYPE71 new variables added by z/OS 1.5:                  
                 SMF71POH='PAGEOUTS*TO AUXSTOR*FOR ABOVE*2GB*BAR'       
Change 22.154  TYPE1415 new variable created:                           
Jul  5, 2004   and FORMATed $HEX2.:                                     
                 Bit          Meaning                                   
                 '1.......'B  DSN found in EDI exclusion table          
                 '.1......'B  DSN being opened for out, already open in 
                 '..1.....'B  DSN being opened for in, already open out 
                 '...1....'B  application requested EDI be bypassed     
Change 22.153 -TYPE6/PDB.PRINT variable SUBSYS='TCP ' is for PrintWay   
VMAC6          basic mode records; SUBSYS='TCPE' is now set if the SMF 6
Jul  5, 2004   record is from PrintWay Extended mode records.           
              -New variables for PrintWay file transfer:                
                 SMF6FTL ='*FILE*TRANSFER*LEVEL*INDICATOR'              
               and SMF6BYTE is now input from PIB8 field.               
Change 22.152  Support for IFA Processors, APAR OA05731.                
FORMATS       -TYPE70 dataset, new variables:                           
VMAC7072         IFAAVAIL='IFA Processor AVAILABLE?'                    
Jul  5, 2004     IFACROSS='IFA*CROSSOVER?'                              
Dec 12, 2005     IFAHONPR='IFA*HONOR*PRIORITY?'                         
              -TYPE72GO dataset, new variables:                         
                 R723NFFI='*NORMALIZATION*FACTOR*FOR IFA*TIMES'         
                 R723ECTC='CPU TIME*WHILE DP*RAISED'                    
                 R723IFEU='IFA-ELIGIBLE*ON CP*USING*SAMPLES'            
                 R723IFAC='IFA*CPU TIME*ON IFA'                         
                 R723IFEC='IFA-ELIGIBLE*ON CP*CPU TIME'                 
              -TYPE791 dataset, new variables:                          
                 R791TIFA='IFA*CPU TIME*ON IFA' (normalized to CP secs) 
                 R791TCP ='CPU TIME*SPENT ON*STANDARD CPS'              
                 R791TIFC='IFA-ELIGIBLE*CPU TIME*ON CP'                 
              -TYPE792 dataset, new variables:                          
                 R792TIFA='IFA*CPU TIME*ON IFA' (normalized to CP secs) 
                 R792TCP ='CPU TIME*SPENT ON*STANDARD CPS'              
                 R792TIFC='IFA-ELIGIBLE*CPU TIME*ON CP'                 
               Dec 12, 2005:  TYPE791/TYPE792 variable names/labels now 
                 match the actual variable names.                       
Change 22.151  Cosmetic, only labels were changed.                      
VMAC71         in MVS/370 those variables contained the sum of CSA+LPA, 
Jul  4, 2004   but ever since MVS/XA, they contain only the CSA Fixed   
               Frame counts, so LPA was removed from their Labels.      
              -Variables that had just "FRAMES" in their label now have 
               CSTORE*FRAMES if the area was CSTORE.                    
              -Unfortunately, some variables in TYPE71 are in units of  
               byte-storage (and formatted MGBYTES to "print pretty"),  
               while these old variables still have counts of frames,   
               but there is no way to be consistent without destroying  
               your existing reports.  Hindsight is wonderful, but can't
               be applied now!                                          
   Thanks to Mayflor Dageforde, Blue Cross Blue Shield of Kansas, USA.  
Change 22.150  The LPAR name variables for LPARs 16-32 were only one    
VMXG70PR       byte long; their initialization was corrected to eight   
Jul  2, 2004   bytes to hold the full name.                             
   Thanks to Bruce Widlund, Merrill Consultants, USA.                   
Change 22.149  Enhancement to the UTILBLDP utility that "builds" a "PDB"
UTILBLDP       (actually, builds the SYSIN code) for arbitrary combos of
Jul  1, 2004   SMF records:                                             
                 - ZEROOBS= parameter supports subtypes, so datasets    
                   built from specific SMF subtype can be created with  
                   zero observations.                                   
                       USERADD= 74,                                     
                       ZEROOBS=  74.1 74.5,                             
                   creates TYPE74 and TYPE74CA with zero observations,  
                   but all other TYPE74XX datasets will be populated.   
                 - New MACFILEX= parameter allows insertion of code that
                   would normally be inserted with %LET MACFILE= ....;  
                   UTILBLDP internally uses MACFILE=, so your MACFILE=  
                   insert is ignored.  Probably not needed, as the main 
                   need for MACFILE= here was to suppress subtypes!     
                  -See member JCLRMF                                    
   Thanks to Sue Castona, Rockwell, USA.                                
Change 22.148  With assistance from SAS developers, %VGETENG(DDNAME=XXX)
VGETENG        returns the SAS Engine name (in macro variable &VGETENG) 
VMXGENG        and the Device Type (in macro variable &VGETDEV), if xxx 
VMXGTAPE       points to an existing SAS data library that was OPENed,  
VMXGINIT       and sometimes even if the library has not been opened.   
Jul  6, 2004   The redesign also corrects these previous glitches:      
Jul 20, 2004     - If the XXX pointed to a sequential format library,   
                   on disk or on tape, the entire data library was read,
                   wasting CPU, I/O, and elapsed time.                  
                 - VMXGTAPE failed when the LIBNAME had not been opened.
              -When a LIBNAME statement exists for XXX, VGETENG/VGETDEV 
               are always correct, whether XXX has been opened or not,  
               unless there is a LIBNAME (XXX or some other ddname) that
               points to a non-existent data library on tape, i.e., a   
               DISP=NEW file that has not yet been written to.          
                  The logic searches LIBNAMEs, and if an uncreated tape 
                  DD is found (perhaps before your wanted XXX ddname) an
                  IEC145I 413-18 message is printed on SYSMSG and SASLOG
                  has an I/O ERROR HAS OCCCURRED message, and the search
                  is terminated (with a zero return code).  If the XXX  
                  ddname is the uncreated file,  VGETENG will have the  
                  Engine from LIBNAME XXX statement, but VGETDEV will   
                  always be blank for an un-created file.               
              -If there is NO LIBNAME statement, the engine and device  
               are correct only if the DDNAME has been OPENED, but the  
               function does not fail; engine is UNKNOWN and device is  
               blanks for unopened or even uncreated ddnames, on tape or
               on disk.  Test %VMXGENG before using in production!      
              -If XXX accesses a REMOTE SAS/CONNECT file, the MVS device
               type will be correct; on ASCII VGETDEV will be blank.    
              -The other %macros, VMXGENG and VMXGTAPE were revised with
               the new logic, and return their original variables, but  
               they exist only for backwards compatibility, as MXG's    
               convention for %macros that "get" something is %VGETxxxx.
              -VMXGINIT was updated to %GLOBAL macro variable VGETDEV.  
      LIBNAME Statement in SYSIN:         YES                 NONE      
                                   VGETENG   VGETDEV    VGETENG  VGETDEV
    DISP=NEW                       CORRECT   CORRECT    UNKNOWN  BLANK  
    DISP=NEW                       CORRECT   BLANK      UNKNOWN  BLANK  
                 The 413-18 ONLY occurs when there is a LIBNAME, the    
                 device is TAPE, and the DDNAME has not been referenced.
   Thanks to Lewis King, SAS Institute Cary, USA.                       
   Thanks to Rick Langston, SAS Institute Cary, USA.                    
   Thanks to Chuck Hopf, MBNA, USA.                                     
   Thanks to Diane Eppestine, SBC, USA.                                 
Change 22.147  Performance enhancements to reduce I/O and CPU time, by  
ASUM42DS       eliminating second pass of TYPE42DS, which was input to  
Jun 30, 2004   VMXGSUM and then input again to ANALCNCR.  The redesign  
               builds a View to create input to ANALCNCR at the same    
               time the data is being read into VMXGSUM.  New SAS NOTES:
                 DATA STEP VIEW SAVED ON FILE WORK.SUM142DS             
                 DATA STEP VIEW SAVED ON FILE WORK.MXGSUM1              
                 COMPRESSING ....                                       
                 MISSING VALUES ....                                    
               are printed on the log.  The savings?                    
                   Resource        Before          After Redesign       
                    EXCPs          1.8 Million        760K              
                    CPU time        78 minutes         46 minutes       
                    Elapsed        236 minutes        135 minutes       
   Thanks to Chuck Hopf, MBNA, USA.                                     
Change 22.146  Most variables in the TYP119nn datasets, except for the  
VMAC119        STARTIME and SMFTIME, were on the GMT clock, but all of  
Jun 29, 2004   the internal variables are corrected to local time zone. 
   Thanks to Robert Sample, Atlanta Journal Constitution, USA.          
Change 22.145 -TYPETCPC and TYPETCPF FTP Client/Server in SMF 118 record
VMACTCP        has GMT time in TOD variables FTPSTART and FTPEND; they  
Jun 29, 2004   are now corrected to local time zone.                    
              -Variable ELAPSTM is added to TYPETCPC/TYPETCPF datasets. 
              -Without this change, ANALTCP reports sometimes had wrong 
               TOD and zero duration because of the GMT time issue.  No 
               change was needed in the ANALTCP code.                   
   Thanks to Robert Sample, Atlanta Journal Constitution, USA.          
Change 22.144  DB2 Trace IFCID 140 variable QW0140RC, Return Code from  
FORMATS        Access Control Exit has legitimate negative value of -1  
VMAC102        if the Exit was not called, so the input was changed to  
Jun 29, 2004   IB instead of PIB; additionally, new format MGD140R is   
               created to decode all of the return codes.  Also, the    
               QW0140RS, a four-byte reason code is HEX8. formatted.    
              -Additional new values for format MGD140P for V7 and V8   
               are added.                                               
   Thanks to Larry Stahl, IBM Global Services, USA.                     
Change 22.143  An example that reads only RMF SMF records to create an  
JCLRMF         "RMF-only" PDB library, including PDB.RMFINTRV, and the  
Jun 29, 2004   PDB.ASUM70PR, PDB.ASUM70LP, and PDB.ASUMCEC summary data.
               The default example skips the RMF 74 subtypes 1 and 5,   
               so that PDB.TYPE74 and PDB.TYPE74CA datasets will have   
               zero obs (i.e., they take no disk space).                
               This example uses the enhancement in Change 22.149.      
   Thanks to Sue Castona, Rockwell, USA.                                
Change 22.142  Support for Thruput Manager SMF record VARNAME/TOKENID of
VMACTPMX       INNODE/16448, JBSBIND/50240, JVLVOL/57920, REQCLA/58082  
Jun 28, 2004   was added to the CARDS; section; these VARNAMEs had only 
               blank values for TOKENID, but had existing variables.    
   Thanks to Kasandra Natzke, Information Resources, Inc, USA.          
Change 22.141  Support for RMF 74 subtype 8 ESS LINK STATISTICS record, 
FORMATS        added by APAR OA04877, creates new dataset TYPE748 with  
EXTY748        counts of I/O operations, Bytes Read/Written, and Active 
VMAC74         Time for ECKD, PPRC, and SCSI devices.  Also, TYPE74CA   
Jun 28, 2004   dataset has Bytes Read/Written, and Time to Read/Write.  
               The APAR adds the fields to the 74-5 and 74-8 records,   
               but the new data is only populated if the ESS D/T 2105   
               device has micro code version (Sand) or higher.
   Thanks to Willy Iven, Fortis Bank, BELGIUM.                          
BUILD005       because Change 22.052 did not add STEPNR in all places   
BUIL3005       where it was needed (CVRT30TD and SPIN30TD); fortunately,
Jun 25, 2004   the exposure only occurs if two adjacent steps have the  
               same INITTIME, and all sorts are now protectd.           
   Thanks to Rich Lopez, Johnson and Johnson, USA.                      
Change 22.139  The CICS ID variables in PDB.ASUMUOW: APPLID,USER,LUNAME,
UTILUOWC       SYSTEM,TERMINAL, and USERCHAR were incorrectly kept from 
VMXGUOW        the LAST transaction segment, but should have been kept  
VMXGUOWT       from the FIRST transaction segment.  The sort order was  
Jun 29, 2004   was changed in Change 21.220, from descending ENDTIME to 
               ascending STRTTIME to recognize the TOR transaction as   
               the first transaction within the UOW, but the logic to   
               store those ID variables was not changed.                
              -LISTALL= argument, primarily for debugging, can now be   
               used to add any of the FRSTxxxx, LASTxxxx, and HOLDxxxx  
               variables to the PDB.ASUMUOW dataset.                    
              -New UTILUOWC member can be used to examine the CICSTRAN  
               observations that made up a Unit-of-Work, for debugging. 
              -Oct 2, 2020: Revised UTILUOW replaces UTILUOWC.          
   Thanks to Carla Fleming, King County, USA.                           
   Thanks to Sydney Cheung, King County, USA.                           
Change 22.138  The original ANAL4GBO member uses the SMF TYPE64 records 
ANAL4GB        to identify VSAM files that are approaching the 4GB size 
ANAL4GBO       limit, but that only saw VSAM files that were opened in  
Jun 25, 2004   the SMF file that was read.  This revision uses the      
               DCOLCLUS dataset, created from IBM's DCOLLECT option of  
               IDCAMS (JCL example in JCLDAYDS) so that all VSAM files  
               can be examined for their size.                          
                - Using TYPE64, the HIGHALLOC was 3354M from TYPE64, but
                  LISTCAT showed only 1234M, because it was run at a    
                  later time, and that VSAM file was defined as reusable
                  and an RST was specified on the ACB at OPEN, so it was
                  reset to empty before the LISTCAT was run.            
                  Thus both members may be useful in tracking VSAM size.
   Thanks to Dennis Cole, Commerce Bank NJ, USA.                        
Change 22.137  Support for z890 new CPUTYPE='2086'x, REQUIRED ONLY for  
FORMATS        OS/390 R2.10; MXG does not error with data from z890s,   
VMAC7072       but without this change, MSU-containing variables will be
VMXGRMFI       missing if you are still running your z890 under OS/390. 
Jun 28, 2004  -The '2084x CPUTYPE tests added to support the z990 CPU   
               in Changes 21.141, 21.149, and 21.216 are expanded to now
               also test for the '2086'x CPUTYPE of the z890.           
              -The table of "MSU" values in MG070CP format are updated  
               with IBM announced Software Pricing MSU for the z890,    
               which will eliminate the "CPUTYPE NOT IN TABLE" messages.
   Thanks to Ed May, Western Power, AUSTRALIA.                          
   Thanks to Al Sherkow, I/S Management Strategies, Ltd, USA.           
Change 22.136  The SMF Exit code to put Initiator Name and Init Number  
IEFU84         if the PROGRAM field in the SMF 30 subtype 1 record that 
Jun 24, 2004   was announced in Change 19.269 now exists in the member  
               IEFU84, which is the JOB to assemble that SMF exit. Your 
               System Programmer will need to install the exit for you, 
               as it must be placed in an authorized load library, and  
               he/she will want to examine this SMF exit code.          
               MXG member VMAC30 already has the code in place and will 
               now populate the variables INITNAME and INITNUM after you
               have installed the IEFU84 exit to add the data to SMF 30.
               But note that only "real" initiators have names/numbers; 
               WLM-managed initiators will have blank initname and no   
               value for initiator number.                              
   Thanks to Stan Dylnicki, Royal Bank of Canada, CANADA.               
Change 22.135  The "MVS" SYSTEM NAME of each LPAR, SMF70STN, is added to
VMXG70PR       datasets ASUM70PR and ASUMCEC as variables LP0STN-LPXSTN,
Jun 24, 2004   and in dataset ASUM70LP as SMF70STN.                     
   Thanks to Jim S. Horne, Lowe's Companies, Inc, USA.                  
Change 22.134  The percentage of DURATM when each of the 32 CPU engines 
VMAC7072       was online is added in variables PCTONLN0-PCTONLNX in the
Jun 24, 2004   TYPE70 dataset.                                          
   Thanks to Jim S. Horne, Lowe's Companies, Inc, USA.                  
Change 22.133 -Support for additional NDM-CDI Connect Direct subtypes:  
VMACNDM             FA,FI,GO,IF,NL,PI,SY,TP,TR,UU,WS,ZI                 
Jun 23, 2004  -Exit members EXNDMEV,EXNDMSB,EXNDMWS were deleted, as    
               those subtypes are now output into existing datasets.    
              -Comments in VMACNDM identify all known subtypes, those   
               that have known DSECTS, and those for which I have had   
               test data; if you have observations created in any of the
               datasets identified as "NO DSECT", contact support@mxg.  
   Thanks to Jim Petersen, Washington Mutual, USA.                      
   Thanks to Stuart Hubbard, Washington Mutual, USA.                    
   Thanks to Thomas Heitlinger, FIDUCIA IT AG, GERMANY.                 
Change 22.132  This example for detail trace of the events in the life  
ANALJOBE       of a JOB did not keep CPUTM, had MULTIDD mispelled, did  
VMACSYNC       not use MACJBCK to select specific jobs whose events are 
Jun 25, 2004   to be tracked, and deleted some 14/15 records for some   
               long-running jobs.                                       
Change 22.131  NETSPY now writes both TYPENSPY and TYPENETM subtypes in 
VMACNSPY       one SMF ID, which caused messages ERROR.VMACNSPY.1 with  
Jun 22, 2004   NSPYENTL=54754 and NSPYOFF=1539954642 in the text.  This 
               change merges the VMACNETM code into the VMACNSPY code so
               that NETSPY records (all of which have alpha subtypes)   
               and NETMASTER (which have two-byte hex subtype) are now  
               processed with the single TYPENSPY/VMACNSPY member to    
               creates all NSPY and NETM datasets.  This change requires
               MXG 22.01+, because of the new EXNETM50 and the revised  
               VMXGINIT members added by Change 22.037.                 
              -While TYPENETM will still decode NETMASTER records, it is
               now archaic, since TYPENSPY creates both NETMASTER and   
               NETSPY datasets.                                         
              -Change 22.243 is required; it corrected this change.     
   Thanks to Susan Fassette, Erie Insurance Group, USA.                 
Change 22.130  The "W0" in DSNAMEs in SAS V9 is only part of new naming 
MXGSASV9       conventions, many of which are documented in the section 
Jun 15, 2004   "Languages, Encodings, and Installation Codes" in the SAS
Aug 24, 2004   "Installation Instructions for SAS 9.1.2 Foundation for  
               z/OS" manual.  The DSNAME and MEMBER names created depend
               on the two NLS/LOCALE options for your country, the "XX" 
               Language Value and the "YY" Encode Value. Some DSNAMES   
               use XXYY, some member names end in YY, and both SASHELP  
               and SASMSG have ENYY in their DSNAME for the help and the
               messages that have not been translated into local.  For  
               example, "ENW0" for English in US, "DEW3" for most GERMAN
               languages, but "DEWB" for GERMAN in Switzerland.         
              -To support this SAS change, the MXGSASV9 JCL procedure   
               example has two new symbolic parameters, &XX and &YY with
               &XX=EN and &YY=WO as their default values, and you can   
               see in that JCL where the XX and where the YY is used to 
               form part of the DSNAME or MEMBER names.                 
              -New DD statements added in V9 are also added in the JCL  
               example: TRNSHLP, ENCDHLP, and TMKVSENV.                 
   Thanks to Bernd Klawa, Stat Bielefeld, GERMANY.                      
====== Changes thru 22.129 were in MXG 22.06 dated Jun 14, 2004=========
Change 22.129  "MVS" SAS only, I think!  In SAS V9, the NLSCOMPATMODE   
CONFIGV9       option was changed to default to NONLSCOMPATMODE, which  
Jun 15, 2004   doesn't fail if your LOCALE option is ENGLISH or blank,  
               but with a LOCALE=GERMAN_GERMANY or other non-blank and  
               non-ENGLISH value, with the new NONLSCOMPATMODE option,  
               every "@" causes this error at compile time:             
                 ERROR: The name 'A7'x49 is not a valid SAS name.       
                 where that 'A7'x is a funny looking printed symbol.    
                 (in the VMXGINIT code at statement INPUT @49 ....).    
               Changing the NONLSCOMPATMODE option back to the V8.2     
               default of NLSCOMPATMODE eliminated the error, so I have 
               added option NLSCOMPATMODE to the CONFIGV9 member, as it 
               appears to be safer, and I've listed the SAS help note   
               about the option for you to read, below.  This note is   
               was added so MXG 22.06 could be completed, but it may be 
               revised when I know more about these options.            
               Specifying LOCALE=GERMAN_GERMANY and NONLSCOMPATMODE did 
               not cause a failure using SAS 9.1.2 under Windows/XP.    
               The SAS help documentation for NLSCOMPATMODE:            
               "NLSCOMPATMODE provides compatibility with previous      
               releases of SAS in order to process data in languages    
               other than English, which is the default language.       
               Programs that ran in previous releases of SAS will       
               continue to work when NLSCOMPATMODE is set.              
               When NONLSCOMPATMODE is in effect, SAS does not support  
               substitution characters in SAS syntax.  If you run SAS   
               with NONLSCOMPATMODE, you must update existing programs  
               to use national characters instead of substitution       
               characters.  For example, Danish customers who have      
               substituted the '' for the '$' character in existing SAS
               programs will have to update the SAS syntax to use the   
               '$' ("national character") in their environments.        
               Note:   NLSCOMPATMODE might affect the format of outputs 
               that are produced using ODS. If you are using ODS, set   
               the option value to NONLSCOMPATMODE."                    
               There is additional, extensive, documentation of LOCALE  
               and NLS in SAS Technical Note TS-653 at     
               Jan 2012:  See Change 27.356, which shows how to use the 
               CONFIMXG and // EXEC SAS and //MXGNAMES to use the site's
               default SAS JCL and removes the NLSCOMPATMODE option.    
   Thanks to Bernd Klawa, Stat Bielefeld, GERMANY.                      
Change 22.128  New BLDIMPDB is "JCL" for ASCII platforms, for STEP03/04 
BLDIMPDB       of the JCLIMSLx/ASMIMSLx IMS log processing on ASCII SAS 
TYPEIMSB       platforms; BLDIMPDB provides the filename statements with
Jun 14, 2004   correct DCB attributes that are used after STEP01/STEP02 
               (which do not require SAS) were executed on "MVS".       
              -Member TYPEIMSB had to be changed to process character   
               fields containing hex data as $CHAR rather than $EBCDIC, 
               logic was added to convert text fields back to EBCDIC.   
   Thanks to Steven Hudson, Avnet Inc, USA.                             
Change 22.127  The example in comments to read SMF data (instead of PDB)
ANALFIOE       was enhanced to create only the datasets, and keep only  
Jun 14, 2004   the variables that are required, reducing run time and   
               DASD space.  This is not needed if you run ANALFIOE with 
               BUILDPDB, since the PDB has all of the needed datasets   
               to analyze concurrent FICON Open Exchanges.              
   Thanks to Neil Ervin, Charles Schwab, Inc, USA.                      
Change 22.126  The "WO" must be "W0", i.e., w-zero not w-oh in the DSNs 
MXGSASV9       and member names in the JCL example.                     
Jun 11, 2004                                                            
   Thanks to Robert Chavez, Office Depot, USA.                          
Change 22.125  Support for Mobius/IPAC subtype 5 IPAC05 dataset duration
VMACIPAC       variables were incorrectly input, but nobody had noticed,
Jun  9, 2004   until now.  Version 6.2 data has been validated.         
   Thanks to Marty Wertheim, Bank of America, USA.                      
Change 22.124  MXG 22.04-MXG 22.05, QWHSSTCK was missing in SMF 102 DB2 
VMACDB2H       trace records after Change 22.090; the reset for ID=101  
Jun  9, 2004   statement should have also have reset ID=102.            
   Thanks to David M. Forbes, McLeodUSA, USA.                           
Change 22.123  SAS Version 9 INCOMPATIBILITY, on "MVS" only, CRITICAL:  
CONFIGV9       The MXG default value for the SAS system option S2=      
UTILS2ER         (it sets the line size of source statements that will  
MXGSASV9          be read from %INCLUDE and AUTOCALL members),          
Jun  8, 2004   which is set in the MXG CONFIGV9 member,                 
Jun 12, 2004   MUST now be changed for MVS from the MXG default of S2=72
                 (which was chosen so that SAS only read columns 1-72,  
                  and prevented errors when user-written code had mixed 
                  blank and non-blank lines, or had invalid line numbers
                  in columns 73-80.  Only user-written code members had 
                  the exposure, since all of MXG fits in 72 positions), 
               to be S2=0, because:                                     
               - MVS SASMACRO library was changed from RECFM=FB to VB.  
                 There are no standards for line size of SAS-provided   
                 %macros; previous MVS-used %macros fit in RECFM=FB, but
                 new V9 macros now have line sizes up to 255 positions. 
                    These new macros were created on ASCII platforms,   
                    where all text files are variable length, with 255  
                    default length (which SAS handled because it treats 
                    variable length input and fixed length differently),
                    so the coders (with no legacy background) had no    
                    reason to restrict their code to the 72 bytes that  
                    we had found necessary on MVS systems, and they did 
                    all of their testing on ASCII platforms.            
                      If they had known of the restriction, their macros
                      could easily have been written to fit, this change
                      wouldn't have been necessary, so you could have   
                      read their source code, to understand and learn,  
                      without line wrapping on green screen terminals!  
               - So the MVS folks had to change RECFM from FB to VB to  
                 deliver these long-length %macros, and since the real  
                 SAS System default is S2=0, the MVS QA tests did not   
                 see any of the errors that their change causes when the
                 S2 option is set to S2=72.                             
               - And, unfortunately, while MXG programs do use some of  
                 the SAS-provided %macros (%LOWCASE,%LEFT,%CMPRES,%TRIM)
                 the utilities that use them (UTILBLDP,BLDSMPDB) weren't
                 executed with the arguments that happen to invoke them 
                 in our QA, so we missed this V9 problem in our testing.
               - The SAS Change to RECFM=VB with the MXG S2=72 default  
                 has caused real errors, and has the potential for more:
                  - With VB and S2=72, real errors occurred:            
                    A site that had always put their own local %macros  
                    in the SASMACRO FB library in previous SAS versions 
                    got "macro not found" errors when they copied their 
                    %macros into the VB file, and executed with S2=72,  
                    because SAS started reading in column 73, and never 
                    saw their %macro definition.  SAS Technical Support 
                    recommended they change S2=0, SAS Note SN-011929,   
                    which did correct this error.                       
                       An alternative to putting user %macros in the    
                       SAS-supplied library is to put them in the MXG   
                       "USERID" tailoring source library, because MXG   
                       uses MAUTOSOURCE SASAUTOS=(SOURCLIB SASAUTOS)    
                       precisely so that %macros will be found.         
                  - But with VB and S2=0, potential errors may be worse:
                    Since MXG has always set S2=72, any text in your own
                    source code in columns 73-80 was ignored, but now,  
                    if you have a member with invalid line numbers in   
                    columns 73-80 (mixed numbers and characters; some   
                    vendors use 73-76 for a line number and put version 
                    characters in 77-80), or if you have a member with  
                    unnumbered first line and numbers in later lines,   
                    your perfectly running job now will fail under V9   
                    (with a 180 syntax error, at the non-blank line),   
                    and the defective numbering will not be identified. 
                       That member must be either all unnumbered or all 
                       lines must be numbered to eliminate this error.  
                    MXG set S2=72 to protect users from the very common 
                    human error we found in MVS systems, when a user    
                    EDITed a new line with blank number into a member   
                    that was already numbered, but now, you must detect 
                    and correct those members so that S2=0 can be used. 
               - But since CONFIGV9 must now specify S2=0 to prevent the
                 real errors encountered, those potential errors due to 
                 "bad" line numbers MUST be detected and corrected prior
                 to migration to V9.  The new UTILS2ER program MUST be  
                 run against each of your Source PDS libraries that have
                 SAS code; it will identify all members with "bad" line 
                 numbers, so that you can EDIT those members and avoid  
                 the potential errors caused by changing S2=72 to S2=0, 
                 prior to migrating to SAS Version 9 on "MVS".          
               - Tutorial on S2 option values:                          
               - The S2=72 option has completely different meanings for 
                 RECFM=VB than for RECFM=FB:                            
                 -For FB, S2=72 says to only read the first 72 positions
                 -For VB, S2=72 says to skip the first 72 positions and 
                  start reading in column 73!                           
               - The S2=0 option is also different, for the two RECFMs: 
                 -For FB, the last 8 columns of the first line of each  
                  member is read; if that first line does not have a    
                  valid sequence number, SAS reads the full LRECL of the
                  source line.  If that first line has a valid sequence 
                  number, SAS reads all but the last 8 columns of that  
                  member's lines.                                       
                 -For VB, columns 1-8 of the first line of each member  
                  is read, and if a valid line number is found, SAS then
                  internally uses S2=8 to start reading in column 9.    
                  If there is no line number in columns 1-8, SAS then   
                  internally uses S2=0 to read the entire line length.  
               - Fortunately, SAS separately opens each member, so with 
                 S2=0 and either FB or VB, SAS examines each member for 
                 line numbers, so you can have one member without line  
                 numbers, and another member with line numbers, even in 
                 the same PDS, without any error; it is only when you   
                 have invalid line numbers, or have a blank line before 
                 a numbered line, that the 180 syntax error will happen.
                 Note that MXG did NOT change the S=72 default value:   
                  - S controls SAS action on code read in from //SYSIN  
                  - S2 controls SAS action on code read by %INCLUDE or  
                    by SASAUTOS)                                        
                because you want that protection: it is very common to  
                have mixed numbered and unnumberd lines in your members 
                that have both the JCL and the SAS code, that you EDIT  
                and SUBMIT, and using S=72 allows that inconsistency,   
                so your job will continue to run without errors.        
                 Summary of changes:                                    
                 -CONFIGV9 now specifies S2=0 instead of S2=72.         
                 -UTILS2ER is a new program to find S2=0 bad lines.     
                 -MXGSASV8/V9 has //INSTREAM with SPACE=(CYL,(1,20))    
                  instead of CYL,(1,1), which could only hold 168,000   
                  lines of source for UTILS2ER.  With (1,20) that temp  
                  file has room for 3 million lines from each PDS.      
   Thanks to Michael L. Kynch, International Paper, USA.                
Change 22.122  Cosmetic.  Error messages were made consistent, with both
VMAC28         SYSTEM and SMFTIME printed with all errors.              
Jun  8, 2004                                                            
   Thanks to Pascal Maurice-Prestataire, La Poste, FRANCE.              
Change 22.121  See the extensive discussion of DB2 Parallel Transactions
VMACDB2        (and the significant loss of DB2TCBTM if you have any)   
EXDB2ACC       in the "DB2 Technical Notes, Newsletter FORTY-FIVE).     
EXDB2ACB      -This old code in the MXG exit members EXDB2ACC/ACP/ACB:  
Jun  6, 2004   was removed by this change, and should be removed from   
               your exits.  It was added by Change 20.266 to resolve a  
               problem with duplicate records, but the new DB2PARTY='R' 
               value is set when QWACPARR='Y', so the DELETE could never
               have been executed.                                      
              -New value 'R' for the RollUp record, and value 'P' is now
               for the Parallel Task (or Utility Subtask):              
                 DB2PARTY  Description     Set by                       
                   'R'      Rollup         QWACPARR EQ 'Y'              
                   'P'      Parallel       QWACPACE GT 00000000X        
                   'O'      Parent/Orig    QWACPCNT GT 0, QXMAXDEG GT 0 
                   'S'      Sequential     None of the above            
              -The code to set DBPARTY was relocated, and the test for  
               'O' is now set IF QWACPCNT GT 0 OR QXMAXDEG GT 0, which  
               is a stronger test for the Parent/Originating record.    
               Without this change, DB2PARTY was "S" for the Parent.    
              -In DB2PARTY='R' Rollup records QWACESC is not a datetime 
               value, but as noted in IBM APAR PQ41012, it contains the 
               total elapsed time for all child tasks, a duration.  MXG 
               now detects when QWACESC is smaller than QWACBSC, (or if 
               QWACESC or QWACBSC are zero) and for those observations: 
                 MXG stores the "QWACESC" time in variable CHIELPTM.    
                 MXG creates QWACESC as datetime, equal to QWHSSTCK.    
                 QWACBSC may be zero                                    
                 ELAPSTM is set to missing                              
               For all other observations, CHIELPTM will be missing,    
               and ELAPSTM=QWACESC-QWACBSC.                             
   Thanks to Andy Creet, Department of Defence, AUSTRALIA.              
   Thanks to Andy Schuermann, Department of Defence, AUSTRALIA.         
Change 22.120  MXG 22.05, MVS only, using UTILBLDP, you will get error: 
Jun  4, 2004   during tests for Change 22.102, I had mis-understood SAS 
               techs to say that the %LOWCASE and other %MACROS had been
               implemented in base SAS, and that SASAUTOS was no longer 
               required, so I had changed SASAUTOS=SOURCLIB in testing, 
               but found it was only the function LOWCASE and not the   
               %macro %lowcase that had been implemented; unfortunately 
               I failed to go back and correct the SASAUTOS= statements 
               in those CONFIGVn members.  The correct statement is     
                 SASAUTOS=(SOURCLIB SASAUTOS)                           
               which has always been required in CONFIGxx and AUTOEXEx  
               to retrieve the SAS-provided %macros that are not defined
               in base SAS:  %LOWCASE, %CMPRES, %LEFT, and %TRIM.       
   Thanks to Jim S. Horne, Lowe's Companies, Inc, USA.                  
Change 22.119  Cosmetic: Four of the BY statements in the _CHAIN macro  
VMACCIMS       were replaced by _BIMFTRN, since that "BY" macro had the 
Jun  3, 2004   same variables as the replaced BY statements.            
   Thanks to Joe Babcock, Bank One, USA.                                
Change 22.118  Cosmetic: Semi-colons at the end of some MACRO _BTY91xx  
VMAC91         were removed, to be consistent with other definitions.   
Jun  3, 2004                                                            
   Thanks to Joe Babcock, Bank One, USA.                                
Change 22.117  Support for optional ESS segment GEPARMKY=003B creates   
IMAC6ESS       variable ESSFRMLN (FORMLEN) in dataset TYPE6, when the   
VMAC6          comment block in member IMAC6ESS is opened.              
Jun  3, 2004                                                            
   Thanks to Engelbert Smets, Provinzial Rheinland Versich., GERMANY    
Change 22.116  Variables SMF70NSI SMF70NSA SMF70NSW were incorrectly    
VMAC7072       divided by NRSAMPLE, which is ten times greater than the 
Jun  3, 2004   SMF70DSA that should have been used.                     
   Thanks to Bruce Widlund, Merrill Consultants, USA.                   
Change 22.115  JES3 only.  The BUILDPD3 program could use the wrong type
BUIL3005       26 purge record, which caused ABEND='JCL' for jobs that  
Jun  2, 2004   had actually executed, especially for jobs that were read
               in on one system and sent to a second system via NJE for 
               execution, because the first TYPE26J3 observation was the
               one used.  This revision uses the SYSEXEC field, which is
               non-blank only in the "execution" purge record; all other
               purge records are output in dataset PDB.DJEPURGE prior to
               the logic that matches the purge record with the other   
               job records.                                             
              -The READTIME value can be different in the purge record  
               that was written for the job's output processing which   
               occurred on the original node.  The first two 26 records 
               (one on the read-in system, one on the execution-system) 
               but the third 26 record had a READTIME that was after the
               purge time of the execution purge record. As this was a  
               non-execution purge record, it is output in PDB.DJEPURGE,
               but searching for it by READTIME would not find the obs. 
   Thanks to Ray C. Lau, Nav-International, USA.                        
   Thanks to Roger Rush, Nav-International, USA.                        
Change 22.114  This VTS Library Statistics report replicated the IBM    
ANAL94         report, but IBM uses the SMFTIME (end) rather than the   
Jun  1, 2004   STARTIME (begin) of the interval, so, to match their     
               report, SMFTIME is now used, and the REPORT TITLE has    
               been modified to indicate it the end of the interval.    
   Thanks to Cheri Sample, Ford Motor Car Company, USA.                 
Change 22.113  ASCII execution only, using ASMIMSLx/JCLIMSLx steps 3 & 4
TYPEIMSA       on PC, variable APPLID was unreadable because it was not 
May 27, 2004   converted back to EBCDIC. APPLID=SUBSTR(DTOKEN,1,4); was 
               replaced by APPLID=INPUT(SUBSTR(DTOKEN,1,4),$EBCDIC4.);  
   Thanks to Mark Van Der Eynden, Hewlett-Packard Australia, AUSTRALIA. 
Change 22.112  INPUT STATEMENT EXCEEDED if MVRECLEV EQ '02'X but you did
VMACEDGS       see the circumvention in the comments to change the 58 in
May 26, 2004   _SKPEDGS to 122, because the INPUTs for MVAUTID1-8 were  
               not compared with their length.  However, this error is  
               now eliminated, as logic now tests MVRECLEV and sets the 
               value to either +58 or +122 automagically.               
   Thanks to Chuck Hopf, MBNA, USA.                                     
Change 22.111  Durn unix, and it's case sensitivity: these two members  
BLDSMPDB       must be all lower case, and all of the %UPCASE functions 
BLDNTPDB       must be changed to %LOWCASE, and when you type in the    
May 26, 2004     %bldsmpdb(....)  or %bldntpdb(....) those text lines   
               must also be typed in lower case.                        
              -References to &SYSSCP were changed to &OPSYS, because    
               &SYSSCP is a SAS-owned macro variable that cannot be     
               %LOWCASEd, but &OPSYS is set in VMXGINIT and can be.     
   Thanks to Steven Hudson, Avnet Inc, USA.                             
Change 22.110  The label for R744STSA was reversed; it is now           
May 25, 2004                                                            
   Thanks to Thom Kight, Fidelity Systems, USA.                         
Change 22.109 -DB2 data written to GTF and read with TYPE102G caused    
ANALDBTR       because some IFCID 070 and 071 Trace Records contain only
VMAC102        a product section; MXG expected a second section with the
VMACDB2H       QW0070 and QW0071 DSECTs, as described in DSNDQW01.  The 
VMACSMF        two IFCIDs now only INPUT the second if QWHSNSDA GE 2.   
May 30, 2004   When QWHSNSDA=1, T102S070/T102S071 dataset will have     
               missing values for the variables from those DSECTS, i.e.,
               QW0070FR/CK or QW0071RT/RS/NI/FR will have missing value.
              -Additionally, these two IFCIDs have only the Standard DB2
               Header and the CPU Header in their Product Section. the  
               Correlation Header does not exist, so the QWHCCN QWHCCV  
               and all QWHC variables are missing in T102S070/T102S071. 
              -The _GTFDB2 macro in VMACSMF was corrected to run under  
               ASCII SAS; $EBCDIC was changed to $CHAR and $HEX format  
               was added.                                               
              -The _GTFDB2 macro did not store TODSTAMP into QWHSSTCK,  
               so the use of GTF data for ANALDBTR to create "PAIRS"    
               datasets, and/or the use oF PMSQLnn reports in ANALDB2R  
               did not work, causing blanks for Interval Start, etc.    
              -ANALDBTR did not include _114PAIR in ALLPAIRS macro,     
               causing S114S115/S114S116 DATA SET NOT FOUND errors in   
              -ANALDB2R had misspelling of QW006PG vice QW0006PG, and an
               incorrect &TRACEIN..S183S183 that is now just S183183; it
               had caused a DATASET PDB.S183S183 not found error.       
   Thanks to Wayne Montefiore, CSC GIS Engineering Services, AUSTRALIA. 
====== Changes thru 22.108 were in MXG 22.05 dated May 22, 2004=========
Change 22.108  CRITICAL for SAS V9.1, if you did NOT install CRITICAL   
CONFIGV9       SAS Hot Fix in SN-012437 for V9.1 and for V9.1.2:        
VMAC110        Summary: -SAS V9.1, using V7SEQ,V8SEQ,or V9SEQ, creates  
VMAC120                  corrupted and un-readable datasets, with no    
VMAC80A                  error messages until you try to read the data, 
VMACOMDB                 and the data is NOT recoverable; it's lost!    
VMACSMSX                  See the FLASH posted May 21 to MXG-L/ITSV-L,  
VMACTMTC                  or see FLASH in Newsletters at   
May 22, 2004            -SAS V9.1, using V6SEQ, creates valid datasets  
                         that have no errors, but if a dataset has any  
                         long-length variables (greater than 200 bytes),
                         the copy/write caused error messages, and you  
                         could not copy/write that dataset.             
                        -SAS 9.1.3 has corrected all known errors and   
                         V9SEQ can be safely used; however, CONFIGV9    
                         still has V6SEQ, because I cannot tell that you
                         are running under SAS V9.1.3.                  
                        -Under SAS V8.2, V8SEQ creates valid datasets,  
                         and supports "long length" variables; the error
                         only occurs under SAS V9.1, without hot fix.   
               This revision shortens all "long-length" variables in    
               datasets from MVS data, so that SEQENGINE=V6SEQ can be   
               safely used without errors; and the change reinstates    
               the SEQENGINE=V6SEQ in the CONFIGV9 member.              
               There is now another CRITICAL change to CONFIGV9 that is 
               also required for SAS V9, in Change 22.123.              
                 These SMF variables were reduced to $200 bytes length, 
                  (and it is extremely unlikely that your MVS data has  
                   and text longer than 200 bytes in these fields):     
                    SMF TYPE      Dataset        Variable  Orig length  
                      80          TYPE80EK       EKC80FRD    1024       
                      80          TYPE8XEK       EKC80FRD    1024       
                     110          CICSJR         SJRPRPTH     255       
                     110          CICPGR         PGRJVCLS     255       
                     120          TYP120JI       SM120JI7     400       
                     120          TYP120WA       SM120WAL     400       
                     120          TYP120WA       SM120WAQ     400       
                     120          TYP120WI       SM120WIQ     400       
                     120          TYP120WI       SM120WIW     400       
                   USER SMSX      IGDACSSC       ACEROJFL     256       
                   USER SMSX      IGDACSSC       ACEROMFL     256       
                   USER SMSX      IGDACSSC       ACEROSFL     256       
                   USER TMTC      TMTCIS         ISCONTCT     256       
                   USER TMTC      TMTCIS         ISDESCR      256       
                   USER TMTC      TMTCIS         ISLOC        256       
                   USER TMTC      TMTCIS         ISNAME       256       
                   USER TMTC      TMTCIS         ISOBJID      256       
                 These MVS-but-not-SMF variables were reduced to $200,  
                  (and data loss here is also unlikely):                
                   Product        Dataset        Variable               
                   Candle OMDB    DB0035         QMDAASTR     247       
                   Candle OMDB    DB0630         QW0063ST    5000       
                   Candle OMDB    DB1920         QW0192DT     250       
                   Candle OMDB    DB2060         QW0206MR     256       
                   Candle OMDB    DB2060         QW0206MS     256       
                   Candle OMDB    DB2080         QW0208MR     256       
                   Candle OMDB    DB2080         QW0208MS     256       
                   Candle OMDB    DB2360         QW0236MR     256       
                   Candle OMDB    DB2360         QW0236MS     256       
                   Candle OMDB    DB2571         QW0257MS     256       
                   Candle OMDB    DB3120         QW0312PR     250       
                   Candle OMDB    DB3140         QW0314PL     256       
                   Candle OMDB    DB3190         QW0319D1     256       
                   Candle OMDB    DB3240         QW0324CP     254       
                   Candle OMDB    DB3270         QW0327MS     256       
                 And what's at least "slick" about this change:         
                 If you need the extra characters in these variables,   
                 once you have installed the Hot Fix, you can increase  
                 them back to their maximum length just by inserting a  
                   LENGTH var1 var2 ... varn   $256 ;                   
                 statement in one EXdddddd member for each product!     
                   MXG code still INPUTs the original long length, but  
                   this change inserted a LENGTH varx $200; statement   
                   in the VMACxxxx member, but SAS uses the LAST        
                   LENGTH statement, and the EXdddddd member's code     
                   will then change the stored length of the variable.  
                 But not all variables over 200 bytes were changed:     
                 - These variables created by TYPEWWW from Web Logs were
                   unchanged; that code is normally run on ASCII SAS,   
                   which does not use the SEQENGINE option, and         
                      Dataset   Variable                    LENGTH      
                      WWWIIS    BROWSER  URISTEM               256      
                        "       COMPNAME CSBYTES  CSHOST      4096      
                        "       CSVERSN  PORT     SCBYTES     4096      
                        "       SITENAME STATUS32 URIQUERY    4096      
                      WWWLOG    BROWSER  URISTEM               256      
                      WWWLOG    URIQUERY                      4096      
                      WWWREFER  REFERER                       4096      
                      WWWURQRY  URIQVALU                      4096      
                      WWWCOOKE  COOKVALU                      4096      
                 - These variables are ONLY longer that 100 bytes if the
                   COMPRESS=YES option is enabled, none of the datasets 
                   are likely to be created in BUILDPDB nor archived,   
                   especially the T102Snnn DB2 trace datasets that are  
                   usually created only for ad hoc analysis.  And all of
                   these variables can be changed by inserting          
                      %LET SASCHRLN=100;                                
                      OPTIONS COMPRESS=NO;                              
                   as your first //SYSIN statement:                     
                      Dataset   Variable                    LENGTH      
                      T102S004  QW0004MS                     32000      
                      T102S005  QW0005MS                     32000      
                      T102S059  QW0059CN                     32000      
                      T102S061  QW0061CN                     32000      
                      T102S062  QW0062ON                     32000      
                      T102S063  QW0063ST                     32000      
                      T102S064  QW0064CN                     32000      
                      T102S065  QW0065CN                     32000      
                      T102S066  QW0066CN                     32000      
                      T102S090  QW0090CT                     32000      
                      T102S092  QW0092P1                     32000      
                      T102S097  QW0097P1                     32000      
                      T102S124  QW01242T                     32000      
                      T102S140  QW0140TX                     32000      
                      T102S141  QW0141TX                     32000      
                      T102S145  QW0145TX                     32000      
                      T102S168  QW0168ST                     32000      
                      T102S180  QW0180DS                     32000      
                      T102S194  QW0194DS                     32000      
                      T102S203  QW0203PA                     32000      
                      T102S204  QW0204TH                     32000      
                      T102S206  QW0206MR QW0206MS            32000      
                      T102S207  QW0207HR                     32000      
                      T102S208  QW0208MR QW0208MS            32000      
                      T102S236  QW0236MR QW0236MS            32000      
                      T102T124  QW01242T                     32000      
                      T102T140  QW0140TX                     32000      
                      T102T141  QW0141TX                     32000      
                      T102T145  QW0145TX                     32000      
                      TMDBBD    QW0140TX                     32000      
                      TMDBBD0   QW0140TX                     32000      
                      SHADOW06  SM06SQSR                     32000      
               Note: Jan 11, 2011.  Change 28.325 updated this list.    
   Thanks to Diane Parker, AmerisourceBergen Corp, USA                  
Change 22.107  Formats MGTMDRC for ASG/TMON DB2 and MGDB2RC for IBM DB2 
FORMATS        slightly out of sync, but now match.                     
May 22, 2004                                                            
   Thanks to Chuck Hopf, MBNA, USA.                                     
Change 22.106  Variables EDSDSMEM, EDSESMEM, EDTDSMEM, EDTESMEM were not
VMACENDV       correctly input.                                         
May 22, 2004                                                            
   Thanks to Lindsay Oxenham, IBM Global Services, AUSTRALIA.           
Change 22.105  MXG 22.04 ONLY.  If there were no optional CICS segments,
UTILEXCL       the IMACEXCL created by UTILEXCL failed with ERROR 22-322
May 22, 2004   on this statement:  STRTTIME=STRTTIME+MCTMNTAD-MCTMNLSO; 
               The error was due to a mislocated comment symbol after   
               the LASTCHEK: label around a debugging PUT statement.    
              -ZDATE protected if _RPTEXCL run against PDB.CICSDICT that
               had been created by an old UTILEXCL prior to ZDATE keep. 
   Thanks to George Waselus, Arizona State Department of Admin, USA.    
   Thanks to Noel D'Sousa, CSC, AUSTRALIA.                              
   Thanks to Helmut Roese, Com-Software, GERMANY.                       
Change 22.104  Support for Candle Omegamon II for DB2 IFCID Trace data  
TYPE102C       that is written to a sequential file.  Use the file name 
VMAC102        //CANDB2 to point to their file, and %INC the TYPE102C   
VMACSMF        program to create obs for all IFCIDs in the file.        
May 20, 2004                                                            
   Thanks to Joseph Pugh, Fujitsu, ENGLAND.                             
Change 22.103  Cosmetic. Example had lines 648 and 652 the same; the    
DOCPDB         second  MACRO _LDBJOBS &PDBJOBS..JOBS  % statement in    
May 20, 2004   line 652 was deleted.                                    
   Thanks to Christa Neven, KBC BankVerzekeringsHolding, BELGIUM.       
Change 22.102  SAS under unix does not fileref SASAUTOS (SN=000444), and
AUTOEXEC       this caused  NO LOGICAL ASSIGN FOR SASAUTOS followed by  
AUTOEXEU       WARNING: Apparent invocation macro LOWCASE not resolved. 
May 20, 2004   ERROR 23-2: Invalid option name ) messages, plus the MXG 
               Version number and date are missing from this message:   
               The real cause of this error is that the %LOWCASE macro  
               function is not implemented in base SAS, but instead is  
               provide as a %MACRO in the "SASAUTOS" library; if that   
               function (and %LEFT) were in base SAS, there             
               would be no need to concatenate the "SASAUTOS" fileref   
               with the MXG SOURCLIB.  For both z/OS and Windows and    
               Linux, SAS does "fileref" the SASAUTOS (with a -SET in   
               the SASVn.CFG file, so this syntax in the MXG-provided   
               AUTOEXEC.SAS works just fine.                            
               However, under unix, you must provide the "pointer" to   
               the SASAUTOS directory; you could use a FILENAME to do   
               that, but it is simpler to use the new AUTOEXEU member   
               for your under unix, as it contains         
               which should be the correct location of unix sasautos.   
               For Windows, of course, the location is different, and   
               is the correct syntax.                                   
               If any of the above fail in the future, all you need do  
               is to search your disk for the file "", which 
               will be found in some directory under the sas root, and  
               use that directory name in your AUTOEXEC/AUTOEXEU file.  
   Thanks to Steven Hudson, Avnet Inc, USA.                             
Change 22.101  Support for VIO/PLUS subtypes 1 and 2 create new datasets
EXTYVIOL       subtyp dddddd     dataset    description                 
VMXGINIT       error.  Both new subtypes have been validated with data. 
May  5, 2004                                                            
   Thanks to Billy Westland, Kaiser Permanente, USA.                    
   Thanks to Raff Rushton, Kaiser Permanente, USA.                      
Change 22.100  Invalid SMF 80 created by EKC's ETF/R FIRECALL product   
May  4, 2004   second segment length was 197, but only 7 bytes remained 
               in the record.  This vendor's "ETFR" modified SMF 80 was 
               supported by Change 21.215, after a similar error in that
               record was circumvented by Change 21.201.  This new EKC  
               record contains "EKCS" rather than "ETFR", and eventually
               I'll support that unique record, also, but for now, this 
               additional test will prevent your daily job from ABENDing
               no matter what EKC comes up with next.                   
               May 22: EKC Inc fix for this error is their PTF LK12029. 
   Thanks to John Grasing, Metropolitan Life, USA.                      
====== Changes thru 22.099 were in MXG 22.04 dated May  2, 2004=========
Change 22.099  Documentation only.  If a "dddddd" macro variable WTNT063
VMXGINIT       %GLOBALed but was not %LET a value, then SAS syntax      
May  2, 2004   errors 22, 202, and 455 and their messages were created: 
                   +   &WTNT063..NT063                                  
             ERROR 22-322: Syntax error, expecting one of the following:
                 a name, a quoted string, RC, _DATA_, _LAST_,;, _NULL_. 
             ERROR 202-322: The option or parameter is not recognized   
                 and will be ignored.                                   
             ERROR 455-185: Data set was not specified on the DATA      
Change 22.098  Variables LCPUSHAR,LPnSHARE in ASUM70PR/ASUM70LP/ASUMCEC 
VMXG70PR       are the Initial Weight of the LPAR (SMF70BPS).  Now, new 
May  2, 2004   variables LCPUSHAC,LPnSHARC in those datasets contain the
               Current Weight of the LPAR (SMF70ACS).                   
   Thanks to Karl Lasecki, Chemical Abstracts Service, USA.             
Change 22.097  Assembly error for ASMRMFV if an old OS/390 MACLIB was   
ASMRMFV        used: "ASMA017W Undefined keyword parameter - GETDS/LOC" 
May  2, 2004   because the old GETDSAB macro did not support LOC=ANY.   
               Reassemble with a current z/OS MACLIB, or you can remove 
               ",LOC=ANY" from the GETDSAB macro call in ASMRMFV source,
               if you're still stuck with an old system and MACLIB.     
               No change was made in MXG code; documentation only.      
   Thanks to Dr. Alexander Raeder, Itellium, GERMANY.                   
Change 22.096  Global macro variables &MACINTV and &MAC30DD are defined 
IMAC30DD       in VMXGINIT and located in IMACINTV and IMAC30DD so that 
VMXGINIT       can be optionally created using %LET MACINTV= syntax as  
May  2, 2004   an alternative to EDITing the IMAC members.              
   Thanks to Dr. Alexander Raeder, Itellium, GERMANY.                   
Change 22.095  Support for OS/400 5.2 QAPMMIOP with three new fields    
VMACQACS       that were added compatibly at the end of the record;     
May  2, 2004   the length for QAPMMIOP is now 290 instead of 272.       
   Thanks to Clayton Buck, UniGroup, USA.                               
Change 22.094  CICS/TS 2.3 records with no excluded fields had wrong    
VMAC110        values for all variables after CBSRVRNM in the CICSTRAN  
May  1, 2004   dataset.  If, instead, you had excluded fields from SMF, 
Aug 13, 2004   like all my test CICS/TS 2.3 data, and used the UTILEXCL 
               program to create your IMACEXCL tailoring member, that   
               code did input CBSRVRNM correctly as $EBCDIC4., but the  
               code for un-excluded records input CBSRVRNM as $EBCDIC8, 
               throwing every thing else in the record off by 4 bytes.  
               Note: Not to defend my error, but I do STRONGLY recommend
                     that even if you do not have any EXCLUDEd fields in
                     CICS data, you should still use UTILEXCL to create 
                     a tailored IMACEXCL for your installation; it will 
                     minimize the size of CICSTRAN by keeping only the  
                     CICS variables in your current release(s), and some
                     some optional CICS fields are only decoded if you  
                     use UTILEXCL to create an IMACEXCL to create your  
                     CICSTRAN data.                                     
               Aug 13: More Important Note: Variable TASCPUTM is one of 
               the VERY MANY CICSTRAN variables that are wrong if you   
               read CICS/TS 2.3 records without this change.  As listed 
               in CHANGES since last May, MXG 22.04 or later is the     
               REQUIRED version to support CICS/TS 2.3 records fully.   
   Thanks to Helmut Roese, COM Software, GERMANY.                       
Change 22.093  Cosmetic. Blank lines between FIRST/LAST record messages 
VMACSMF        were removed, _N_= value is consistently located, and new
May  1, 2004   Start of Read SMF and End of Read Time of Day messages.  
Change 22.092  For SMF 116 Subtype 1 and 2, the CICS and IMS id fields, 
VMAC116        variables    QWHCTNO,QWHCTRN,QWHCTASK for CICS   and     
May  1, 2004   variables    QWHCPST, QWHCPSB for IMS                    
               were not in the same location as the subtype 0 record.   
               New input statements correct those variables in the      
               MQMACCTQ and MQMQUEUE datasets.                          
   Thanks to Helmut Roese, COM Software, GERMANY.                       
Change 22.091  Variable PCTALLBY in dataset TYPE78CU should have always 
VMAC78         been a missing value, with z/OS 1.2+, per the June, 2002,
May  1, 2004   note added to the text of Change 19.203, but it has been 
               alway 100% instead of missing.  The test was revised so  
               that it now is as documented, always missing value.      
   Thanks to Phil Baxter, Cap Gemini Ernst & Young, ENGLAND.            
   Thanks to Simon Bolland, Cap Gemini Ernst & Young, ENGLAND.          
Change 22.090  MXG 22.02-22.03 only. Change 22.045 corrected QWHSSTCK in
VMACDB2        DB2STATx datasets (so statistics intervals would MERGE), 
VMACDB2H       but that change caused QWHSSTCK in the DB2ACCTx datasets 
May  1, 2004   to be zero (printed as year 1960).                       
              -MXG Logic in VMACDB2H was revised to RETAIN the STCK of  
               the first ID=100 record in variable STATSTCK, and use    
               QWHSSTCK=STATSTCK for statistics data, but directly use  
               QWHSSTCK=THISSTCK for ID=101 DB2ACCTx datasets.          
              -The RETAIN QWHSSTCK in VMACDB2 was removed as not needed.
   Thanks to Dean Ruhle, J. C. Penney, USA.                             
Change 22.089  Variable QWHCCV was INPUT $EBCDIC12. in MXG 20.20, but as
VMAC116        the field contains both EBCDIC text characters and binary
May  1, 2004   hex values, the INPUT was changed to $CHAR12 in MXG 21.21
               so that the hex values were preserved when MXG executed  
               under ASCII.  On EBCDIC platforms, there is no difference
               between $EBCDIC and $CHAR, but $CHAR informat variables  
               must be formatted $HEX: a binary '00'x value, PROC PRINTd
               can stop VTAM output, so QWHCCV is now $HEX24 formatted. 
               16Jan04: Note that my choice to format QWHCCV as $HEX24  
               will cause printed reports to be expanded from 12 to 24  
   Thanks to Dean Ruhle, J. C. Penney, USA.                             
Change 22.088  If VMXGRMFI is invoked a second time with PDB= non-null, 
RMFINTRV       to re-read the PDB.TYPE7xx datasets to create different  
VMXGRMFI       output "PDB.RMFINTRVs", perhaps with different workload  
Apr 30, 2004   definitions, the SPINRMFI dataset was reused and became  
May 19, 2004   corrupted, causing spurious observations to be created.  
                 This does NOT happen with the example in RMFINTRV using
                 PDB=, TRENDIN=PDB.RMFINTRV, to resummarize the first   
                 output to create separate hourly and daily summary     
                 datasets PDB.RMFINTHR and PDB.RMFINTDY.  When the PDB= 
                 argument is null, the SPINRMFI dataset is not used.    
                    The SPINRMFI is only needed to keep the prior day's 
                    last four hours, for calculation of MXG's MSU4HRAV. 
               If your PDB= argument is non-null in subsequent VMXGRMFI 
               invocations, you must use the SPINRMIN= argument to name 
               your spin dataset (e.g. SPINRMIN=SPINRMXX,), so that that
               summarization's SPIN will be in SPIN.SPINRMXX dataset.   
               The default value for SPINRMIN is SPINRMFI, and I suggest
               you use SPINRMxx naming convention for your dataset.     
              -This change also created new argument SPINRMOU, for the  
               output dataset name, for consistency, but it is unlikely 
               to be used.  SPINRMOU defaults to the value in SPINRMIN. 
              -Each VMXGRFI with PDB=non-null must use a different SPIN 
               dataset; the SPINRMIN= argument changes the dataset name,
               but the default "SPIN" library is used for all of them.  
               There is an alternative: you can have multiple "SPIN"    
               libraries, instead of multiple "SPIN" datasets, using the
               &SPININ/&SPINOUT macro variables created in Change 22.018
                (so that you could have different input and output SPIN 
                libraries so you could use a GDG for your SPIN library).
               So you could %LET SPININ=SPIN01, to change the DDNAME for
               each %VMXGRMFI invocation.                               
              -May 19: Example in comments in RMFINTRV was missing the  
                       comma after SPINRMIN=SPINRMDY, now corrected.    
   Thanks to Karl Lasecki, Chemical Abstracts Service, USA.             
   Thanks to Jim S. Horne, Lowe's Companies, Inc, USA.                  
Change 22.087  Non-PR/SM systems. Datasets PDB.TYPE70 and PDB.RMFINTRV  
VMAC7072       had variables IORATE and PCTTPI too low; they contained  
Apr 30, 2004   values from only the last CPU, instead of the totals.    
               This error was introduced in MXG 21.05 when Change 21.170
               moved the three lines inside the PR/SM Control Section,  
               which does not exist on non-PR/SM systems.  The lines are
               relocated after the PR/SM Control Section (NRPRCSS) loop.
   Thanks to Dean Ruhle, J. C. Penney, USA.                             
Change 22.086  The second IF ID=xx AND MVSXA THEN DO; statement should  
VMAC74         have been ELSE IF ID=xx ...., for performance reasons,   
VMAC75         and to be consistent with SMF TYPE logic in MXG, but it  
VMAC76         had no other impact on execution.                        
Apr 30, 2004                                                            
   Thanks to Dr. Alexander Raeder, Intellium, GERMANY                   
Change 22.085  Support for TNG NT platform  SESSION and USER objects:   
EXTNT064          dddddd    Dataset   Description  Vars    Instances    
FORMATS           TNT063    NT063     SESSION       77        181       
IMACTNG           TNT064    NT064     USER          17         75       
VMACTNG        You must update your MXG Format Library with this FORMATS
VMXGINIT       member (see FORMAT step of JCLINSTL).                    
Apr 29, 2004                                                            
   Thanks to Peter Krijger, National Bank of New Zealand, NEW ZEALAND.  
Change 22.084  Large QBSTGET in PDB.DB2STATB after Change 22.045 occurs 
VMACDB2        if the DB2 Subsystem was restarted, and the buffer pool  
Apr 29, 2004   was not used in every interval.  MXG Logic was revised   
               to use QWHSACE to detect a restart had occurred.         
   Thanks to Steve Dyck, Canadian Depository for Securities, CANADA.    
Change 22.083  Support for additional unix AIX PTX objects create new   
EXAIXIP        datasets:                                                
EXAIXNFS          dddddd    dataset    description                      
EXAIXRPC          AIXIP     AIXIP     AIX IP DATA                       
EXAIXTCP          AIXNFS    AIXNFS    AIX NFS DATA                      
EXAIXUDP          AIXRPC    AIXRPC    AIX RPC DATA                      
IMACAIX           AIXTCP    AIXTCP    AIX TCP DATA                      
VMACAIX           AIXUDP    AIXUDP    AIX UDP DATA                      
Apr 29, 2004                                                            
   Thanks to Glenn Bowman, Wakefern, USA.                               
Change 22.082  Variable MEMINBOX in NTCONFIG dataset was 1/100th of the 
VMACNTSM       actual memory in the box; the INFORMAT MEMINBOX 16.2 was 
Apr 28, 2004   changed to INFORMAT MEMINBOX 16. because the value is an 
               integer, and does not have two implied decimal places.   
   Thanks to Diane Parker, AmeriSource Bergen, USA.                     
Change 22.081 -If the translate table used to send TNG ASCII data to MVS
VMACTNG        created '9E'x/'9F'x for Left/Right Square Bracket & '4F'x
Apr 28, 2004   for Exclamation Point, those unexpected values caused MXG
               Bracket test now has '9E'x for that EBCDIC value, and has
               '92'x, because the ftp of the '9E'x value back to ASCII  
               created that unexpected value.  The full test now is:    
                 IF TYFLG IN : ('[','5B'X,'AD'X,'BA'X,'92'X,'9E'X)      
              -Change 21.269 blanked variable DOMAIN, but did not note  
               that there is no "domain" value in TNG, and that variable
               should not have been created.  SYSTEM is the one to use. 
              -The "DATA FROM PLATFORM" message now has the SYSTEM from 
               each new Header record; it was blank in the first message
               and had the prior record's SYSTEM value in the rest.     
   Thanks to Gunner Jacobsen, Nordea, NORWAY.                           
Change 22.080  Variable CPUTM was removed from PDB.CICS built from ASG- 
ASUMCICT       The Monitor's MONITASK dataset, since TASCPUTM is the TCB
Apr 28, 2004   CPU time variable.  CPUTM had been removed from PDB.CICSs
               built by ASUMCICS and ASUMCICX by was accidentally left  
               in the ASUMCICT member.                                  
   Thanks to Frank Lund, EDB IT Drift, NORWAY.                          
Change 22.079  Support for IBM Session Manager User SMF record creates  
EXIBSMSM       IBMSESMG dataset.  Unfortunately, there is no field that 
IMACIBSM       indicates what Application was connected to, so for a    
TYPEIBSM       specific USERID/LTERM (variables SSTUSER/SSTTNAM), that  
TYPSIBSM       connected to multiple applications, records with overlap 
VMACIBSM       between Session Start (SSTSTRTT) and SMFTIME (Signoff).  
VMXGINIT       Use SMFTIME instead of the lower resolution SSTSTIME for 
Apr 28, 2004   the signoff time.  Query to IBM as to why there is no    
               field for the application to which session connected.    
   Thanks to Dave Crandall, Farmers Insurance, USA.                     
Change 22.078  Cosmetic.  Variable PCTDLCCA Label was corrected to be   
VMAC7072                    PCTDLCCA='CPU*CAPPING*DELAY*PERCENT'        
Apr 27, 2004   instead of RESOURCE*GROUP... (which is in PCTDLPDE).     
   Thanks to Ronald Kveton, Experian, USA.                              
Change 22.077  Support for "second flavor" of ACCT fields; original data
VMACTPMX       had the "standard type 30 job accounting string", but new
Apr 27, 2004   data has multiple ACCT fields; new logic detects which is
               present and still populates ACCOUNT1-ACCOUNT9, LENACCT1- 
               LENACCT9 from the individual fields.                     
              -TSSUSR2 and TSSUSR3 fields now supported.                
   Thanks to Lawrence Jermyn, Fidelity Systems, USA.                    
Change 22.076  Cosmetic. Variable _N_ was added to PUT statements for   
IMACACCT       error conditions and messages were single spaced.        
Apr 27, 2004                                                            
Change 22.075  ARRAY SUBSCRIPT OUT OF RANGE error occurs if you have    
VMAC74         more than 255 structures in your CF; the temporary arrays
Apr 27, 2004   allocated only 255 elements, but they have been raised to
               1024 elements, which I believe is the maximum number of  
               structures supported in a CF.                            
   Thanks to Bob Miller, CONSECO, USA.                                  
Change 22.074  DB2 Trace SMF 102 Subtype 125 dataset T102S125 variables 
VMAC102        QW0125PC QW0125PL QW0125PN QW0125TS QW0125SN were missing
Apr 27, 2004   values because the test for QWT02R1L GE 64 should have   
               been GE 62.  The original DSECT showed two reserved bytes
               but those bytes do not exist in the current record, so   
               the +2 at the end of segment was also removed.           
   Thanks to Ron Alterman, PG&E, USA.                                   
Change 22.073  SMF 119 Subtype 10 dataset TYP11910 had invalid values in
VMAC119        variables  UCINDTGR UCOUDTGR UCINBYTE UCOUBYTE because +2
Apr 27, 2004   was needed to skip two reserved bytes before UCINDTGR.   
   Thanks to Thomas Heitlinger, FIDUCIA IT AG, GERMANY.                 
Change 22.072  For Service or Reporting Classes with R723CWMN GT 0, not 
VMAC7072       all periods were output.  With three periods, only the   
Apr 27, 2004   first period was output; with four periods, only the 1st 
Aug  5, 2004   and 2nd periods were output.  This is NOT a new error;   
               MXG has always been this way:                            
                 Inner loop  IF R723CWMN GT 0 THEN DO _I_=1 TO R723CWMN;
                 (for the two state/delay sections), and the outer loop 
                 (for each period), DO _I_=1 TO NRSCS; used the same _I_
                 variable!  Transaction Service Classes have R723CWMN=2 
                 (begin and end entries), causing _I_=3 when R723CWMN=2,
                 so if NRSCS (number of periods) was 2 or 3, only the   
                 first period's data was created.  (With 4 periods in   
                 the service class, only the first and second period    
                 data was output, but not the 3rd nor 4rd, etc.).       
               The DO variable in the inner loop was changed to _II_ to 
               correct this error.                                      
              -The April text cited R723TYPE=3 as the only exposure, but
               the error actually occurred with any service or reporting
               class with R723CWMN non-zero.  This text was revised in  
               August, but the April code change was not affected.      
   Thanks to Tom Koelle, CitiGroup, USA.                                
   Thanks to Dave Crandall, Farmers Insurance, USA.                     
Change 22.071  Test string for "SAS Product SMF Record" change to SASU  
UTILBLDP       (it was SAS) to correctly include VMACSASU, etc., when   
Apr 26, 2004   SAS USER records are to be processed.                    
   Thanks to Dr. Alexander Raeder, Itellium, GERMANY.                   
Change 22.070  Modification to VMXGSUM to prevent a bizzare abend that  
VMXGSUM        should not happen but did happen in one isolated case,   
VMXGSUME       where a slash was used. Addition of %STR resolved.       
Apr 26, 2004                                                            
Change 22.069  The BLDSMPDB utility for daily/weekly/monthly/trend PDB  
BLDSMPDB       had used SMF= for its input argument, but Change 22.060  
Apr 26, 2004   replaced hardcoded SMF DDname in VMACSMF with &SMF, which
               caused BLDSMPDB code to fail; the name in BLDSMPDB was   
               changed to SMFIN= to eliminate the conflict and error.   
   Thanks to ???, ???, USA.                                             
Change 22.068 -Support for optional RMI data for both CMODNAME='RMI' in 
VMAC110        IMACICRM and CMODNAME='DFHRMI' in IMACICRD adds similar  
UTILEXCL       but different sets of RMIxxxxx variables.                
IMACICRD      -UTILEXCL was revised to support DFHRMI and RMI segments; 
IMACICRM       without this change, if CMODNAME='DFHRMI' was in the CICS
Apr 17, 2004   dictionary, the IMACEXCL created by UTILEXCL failed with 
               a SAS 180 error, underscoring variable TRANTYPE.         
   Thanks to Neil Ervin, Charles Schwab, USA.                           
Change 22.067  Ending */ comment was missing, but the only impact was   
SPUNJOBS       that work datasets were not be deleted.                  
Apr 16, 2004                                                            
   Thanks to Dov Brosch, Bank Hapoalim, USA.                            
====== Changes thru 22.066 were in MXG 22.03 dated Apr  5, 2004=========
Change 22.066  Cosmetic. Labels for SOMSGIN1 and SOMSGOU1 were reversed.
Apr  5, 2004                                                            
   Thanks to Allan J. Winston, MBNA, USA.                               
Change 22.065  The six undocumented ESS fields in SMF 57 (Change 22.057)
VMAC6          are also in SMF 6 records, and are decoded in variables  
Apr  5, 2004   SMF6C1, SMF6C2, SMF6C3, SMF6N1, SMF6N2,and  SMF6N3       
   Thanks to Rainer Hertwig, Lufthansa Systems Infratec GmbH, GERMANY.  
Change 22.064 -Executing "MONTHBLD" on ASCII platforms caused errors, as
AUTOEXEC       it was designed to run on "MVS", with RECFM=FB, which SAS
MONTHASC       does not honor on ASCII; it presumed MVS JCL provided the
INSTALL        required //DUMMY DD'; it created the MONTHPDB in "tape"  
Apr  2, 2004   (sequential) format, to eliminate MVS tape mounts, etc.  
               This new MONTHASC member executes under ASCII and creates
               a "disk" format SAS Data Library, but it also executes on
               "MVS", and it may be preferred there, now that Virtual   
               Tape drives have eliminated most of the concerns about   
               tape mounts, and the "disk" format library with directory
               is much faster to access a single dataset; furthermore,  
               the "disk" format PDB can be migrated to tape by HSM!    
              -AUTOEXEC member was revised to add LIBNAME DUMMY, which  
               is used for "dummy" datasets in MONTHASC.                
              -INSTALL for MXG install under ASCII was revised to note  
               that you need to create c:\mxg\dummy directory and the   
               c:\mxg\userid\ file, if you did not copy the 
               MXG product from CD-ROM (that directory and file are now 
               created on the CD-ROM).                                  
   Thanks to Joe Keey, BOC, ENGLAND.                                    
====== Changes thru 22.063 were in MXG 22.03 dated Apr  2, 2004=========
Change 22.063  The delay percentages in TYPE72GO are calculated by using
VMAC7072       R723CTSA, execution samples, if it is non-zero as the    
Apr  1, 2004   denominator, replacing VALDSAMP.  But PCTDLTDQ, pct total
               delay including batch, when there was batch queueing is  
               incorrect, because in that case, VALDSAMP and R723CTSA   
               can be major-different (R723CTSA=7, VALDSAMP=202,206!),  
               so the calculation of PCTDLTDQ is now based on VALDSAMP  
               instead of R723CTSA, to get a sensible percentage!       
   Thanks to Phil Baxter, CGEY, ENGLAND                                 
   Thanks to Simon Bolland, CGEY, ENGLAND.                              
Change 22.062  When REPORT=ALL is specified, the HTTP report abends with
Apr  1, 2004   logic was not included in the "ALL" logic, but now it is.
   Thanks to David Klein, DOITT - City of New York, NY.                 
Change 22.061  Cosmetic.  VARIABLE QWGTDSC1 IS UNINITIALIZED had no     
UDB2GTF        impact; it was in a Debugging PUT that was not executed. 
Apr  1, 2004   This UDB2GTF utility is required as a pre-step to convert
               GTF 256-byte "chunks" into readable VB records, which can
               then be read by MXG. The output DDNAME of UDB2GTF is     
               GTFOUT, so to process that converted file, you would use 
               %READDB2(GTF=GTFOUT,IFCIDS=ALL) to create all possible   
               DB2 datasets and populate those found in your data.      
   Thanks to George French, Liberty Mutual, USA.                        
   Thanks to John Pierce, Liberty Mutual, USA.                          
Change 22.060 -The ARRAYs added in TYPETPMX in MXG 21.21 cause horrific 
EXTPMACT       CPU time increases, from 3 Minutes to 71 Minutes for     
EXTPMAFF       TYPETPMX to read 4 million SMF records (4GB), of which   
EXTPMAFT       only 16,000 (70MB) were TPM records. (Processing the SMF 
EXTPMBFR       file of only those 16K TPM records took 3 CPU minutes.)  
EXTPMBND       The ARRAYs were used to store the variables that can have
EXTPMBVL       multiple instances (like the list of VOLSERs used), and  
EXTPMDEA       you had to update IMACTPMX to tell MXG the maximum number
EXTPML10       of instances of each of the arrays.  The problem is that 
EXTPML11       real variables were defined in each array, and that was  
EXTPML12       the cause of the CPU increase; for real variables, SAS   
EXTPML13       initializes each array variable before each SMF record   
EXTPML14       is read.  Using _TEMPORARY_ instead of real variables    
EXTPML15       eliminated the CPU hit, as did removing the ARRAYs and   
EXTPML16       their references.                                        
EXTPML17      -With real variables in an ARRAY, SAS initializes every   
EXTPML18       one of the variables for each new SMF record, even for   
EXTPML19       the non-TPM SMF records that are skipped after their ID  
EXTPML20       in INPUT and tested, before any arrays were referenced.  
EXTPML21      -The only solution was to completely rewrite TYPETPMX and 
EXTPML22       eliminate the use of real variable ARRAYs, and instead,  
EXTPML23       create 34 new TPMxxxxx datasets, one for each variable   
EXTPML24       that can have multiple instances, keeping the instanced  
EXTPMLL1       variable and JOB JESNR SMFTIME SYSTEM variables so you   
EXTPMLL2       can select and report, or use those key variables to     
EXTPMLL3       JOIN the instanced dataset with TYPETPMX if needed.      
EXTPMLL4       There is a counter variable in TYPETPMX for each of the  
EXTPMLL5       instanced variables to tell you if there are instances.  
EXTPMLL6      -The %LETs that you were required to update in IMACTPMX,  
EXTPMLL7       which told MXG the maximum number of instances are no    
EXTPMLL8       longer required and were removed ("a Good Thing"), as    
EXTPMLL9       were the now-unnecessary DROP statements in the EXTYTPMX 
EXTPMLLM       exit member for those instanced variables.  And TYPETPMX 
EXTPMLMT       dataset now has only 480 variables, but you may have to  
EXTPMVVL       revise your TPMX reports as a result of this redesign.   
EXTYTPMX      -Before TYPETPMX was redesigned, a circumvention was seen 
IMACTPMX       possible: my changing the hardcoded INFILE SMF ... in the
VMACSMF        MACRO _SMF definition in VMACSMF to INFILE &SMF ..., and 
VMACTPMX       transparently adding %LET SMF=SMF in VMXGINIT, you could 
VMXGINIT       then change the INFILE name "on the fly", and could use  
Apr  1, 2004   the MACFILE exit to send the TPM records to a temp file, 
               and then use "TYPETPMX" only against the TPM records:    
                  //  EXEC MXGSASV9                                     
                  //SMF DD YOUR.SMF,DISP=SHR                            
                  //SMFOUT DD UNIT=SYSDA,SPACE=(CYL,(200,200))          
                  //SYSIN DD *                                          
                  %INCLUDE SOURCLIB(VMACTPMX); /*defines _IDTPMX*/      
                  %LET MACFILE=                                         
                          IF ID=_IDTPMX THEN DO;                        
                            FILE SMFOUT DCB=SMF;                        
                            PUT _INFILE_;                               
                            FILE LOG;                                   
                  %INCLUDE SOURCLIB(BUILD001);                          
                  %LET MACFILE= ;                                       
                  %LET SMF=SMFOUT;                                      
                  %LET PTYTPMX=PDB;                                     
                  DATA _VARTPMX; _SMF; _CDETPMX; RUN;                   
                  %INCLUDE SOURCLIB(BUILD002,BUILD003,BUILD004,BUILD005)
               Although this specific need to change the SMF infile to  
               use the temporary SMFOUT file is no longer needed with   
               the revised TYPETPMX support, it was left in place for   
               possible future use.                                     
   Thanks to Richard S. Ralston, Humana, USA.                           
Change 22.059  New CICS/TS 2.3 Pool variables were added using reserved 
VMAC110        fields in STID=60 subtype 2 SMF 110 stat record, but were
Mar 30, 2004   not input (no vertical bars in CICS Data Areas!):        
                 DSGTOTMT DSGTOTMW                                      
                 DS2MMWTS DS2MMWTM DS2CMMWS DS2PMWWS DS2CMMWT           
                 DS2TOTMT DS2TOTMW                                      
                 DS3MMWTS DS3MMWTM DS3CMMWS DS3PMWWS DS3CMMWT           
                 DS3TOTMT DS3TOTMW                                      
               These new variables measure TCB Mismatch Waits/durations 
               and MVS Storage Waits/durations, and are output in the   
               CICDSPOO datas for the three pools.                      
   Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.  
Change 22.058 -Temporary variable SHFTTIME should have been DROPed in   
IMACSHFT       IMACSHFT when it was added by Change 21.204; now it is   
VMACTMDB       DROPped so it will not be kept in any MXG dataset.       
Mar 29, 2004  -Variables added to ASG Monitor for DB2 in Change 21.237  
               were not labeled.                                        
   Thanks to Chris Weston, SAS Institute ITRM, USA.                     
Change 22.057 -Support for the optional ESS fields in TYPE57J2, for JES2
VMAC57         sysout transmission between NJE nodes; the ESS variables 
Mar 29, 2004   are now (optionally) created if your IMAC6ESS member has 
               been tailored (comment block removed) to keep them.      
              -Six undocumented variables SMF57C1-C3 and SMF57N1-N3 are 
               decoded from the 28 bytes following SMF57TUL; they will  
               be re-labeled if their documentation can be located.     
              -SMF 57 is created when sysout was sent thru this JES2 NJE
               node, but it counts only the number of logical TP records
               (which may or may not count actual lines or images!).    
              -The SMF 57 record is also created by unisys's DEPCON     
               (output management tool), which routes print from unisys 
               to the z/OS print queue.   While actual lines printed may
               not be available, at least the destination printer is    
               available, but as there is no MVS "job" that created the 
               output, merging with BUILDPDB for unisys print accounting
               is not really possible.                                  
   Thanks to Rainer Hertwig, Lufthansa Systems Infratec GmbH, GERMANY.  
Change 22.056  Q3STHWIB variable should still be good; UNINIT Q3STHIWB  
VMACDB2        note caused by a typo, but code is executed only if field
Mar 26, 2004   wrapped, and the next interval's Q3STHIWB value is valid.
   Thanks to Lori A. Masulis, FMR, USA.                                 
====== Changes thru 22.055 were in MXG 22.02 dated Mar 24, 2004=========
Change 22.055  TYPE42DS variable AVGIOQMS=RESP-PND+DIS+CON+CUQ is often 
VMAC42         a negative 0.128 milliseconds, which is one clock tick in
Mar 24, 2004   the type 42 "clock", and AVGIOQMS is at best an estimate 
               of an average value.  Since this is a calculated value,  
               rather than a value in an SMF record, I think it wise to 
               just set these negative values to zero, and document what
               I've done here, so you don't get sidetracked by the small
               negatives; the max AVGIOQMS was 902 Millisec/SIO.        
   Thanks to Ron Alterman, PGE, USA.                                    
Change 22.053  Cosmetic.  The MXG-created character variable CPCFNAME   
VMXGRMFI       was inconsistently built, sometimes with a dash 2064-2C8,
VMXG70PR       sometimes without, 20642C8.  It now always has the dash. 
Mar 24, 2004                                                            
   Thanks to Kenneth D. Jones, xwave, CANADA.                           
Change 22.052  PDB.STEPS can have some EXCP, IOTM, TAPEDRVS, TAPNMNTS   
BUILD005       and TAPSMNTS counts from one step of a job output in the 
BUIL3005       previous step of that job, if both steps have exactly the
VMAC30         same INITTIME: the first step was FLUSHED (condition code
Mar 23, 2004   bypass), so it was never initiated, nor allocated, nor   
               executed), AND, the next step initiated instantaneously, 
               without any delay, in the same 10 millisecond clock tick.
               MXG's BUILDPDB logic was revised to use INITTIME STEPNR  
               instead of INITTIME to separate the two steps, so these  
               I/O counts are now output in the correct PDB.STEPS obs.  
               While I/O counts were in the wrong PDB.STEPS observation,
               the values were correct, so the PDB.JOBS observation did 
               have the correct total I/O counts for the job (although  
               the TAPEDRVS count could have been incorrect).  Also, in 
               PDB.STEPS the STEPNR was not equal to variable STEP (but 
               that is normal for restarted jobs, as STEP is a counter  
               of steps executed, and restarted jobs will have multiple 
               instances of the same STEPNR with different STEP values).
              -Member VMAC30 had to be changed to add STEPNR to KEEP=   
               list for the TYPE30TD dataset.                           
   Thanks to John R. Parla, CIGNA, USA.                                 
   Thanks to Ray Dunn, CIGNA, USA.                                      
   Thanks to Paul E. Cohen, CIGNA, USA.                                 
Change 22.051  The Multi-System Remote Enclave CPU segment is 80 bytes  
BUILD002       instead of the 20 bytes documented in SMF; I have guessed
VMAC30         what some of the fields contain, but the MRENxxxx names  
Mar 22, 2004   will likely be changed when I understand what's what.    
Mar 24, 2004   But assuming the data is eventually valid, I have added  
Jan 12, 2005   _STY30MR to the BUILD002 so that PDB.TYPE30MR will now be
               automatically created in the PDB library in BUILDPDB/PD3.
              -Jan 12, 2005:  This Change was COMPLETELY wrong; the code
               was completely revised by Change 22.345, with correct    
               SMF30MRx variable names.                                 
   Thanks to Chuck Hopf, MBNA, USA.                                     
Change 22.050  IRD caused wrong PCTCPUBY in TYPE70 and RMFINTRV datasets
VMAC7072       for intervals in which engines were varied offline.  The 
VMXGRMFI       MXG support for IRD should now be complete; it was added 
Mar 22, 2004   in these increments for these "CPU-measuring" datasets:  
                    Datasets            When        MXG Version  Change 
                  ASUM70PR/ASUMCEC   Sep 22, 2003     21.05      21.170 
                  TYPE70PR           Mar 11, 2004     22.01      22.011 
                  TYPE70,RMFINTRV    Mar 22, 2002     22.02      22.050 
               MXG accumulated CPUWAITM for each engine only when it was
               online at the end of interval (CAIx='01'B), but when IRD 
               varies an engine CAIx='11'B, so CPUWAITM for that engine 
               was not added, causing CPUACTTM and PCTCPUBY both to be  
               too large.  Now, CPUWAITM is accumulated if SMF70ONT is  
               non-zero (i.e., the engine was used, a stronger test).   
              -An unrelated error in the first RMF interval after an IPL
               was also detected and corrected.  The first records have 
               their interval DURATM greater than SMF70ONT, but CAI0=01 
               so engines were not varied off.  For one IPL, the 25 sec 
               difference caused PCTCPUBY and CPUACTTM to be NEGATIVE!  
               These first interval records have short DURATM because   
               RMF is synchronizing with time of day:                   
                  IPL TIMESTAMP       STARTIME      DURATM     SMF70ONT 
                22FEB04:02:15:05.95  02:19:12.00  0:09:47.39  0:09:24.26
                22FEB04:02:22:46.45  02:26:59.00  0:02:00.63  0:01:35.19
                22FEB04:01:28:39.42  01:31:52.00  0:12:07.05  0:11:39.81
               I conclude that RMF starts to count DURATM before engines
               are available for use, so MXG now uses SMF70ONT (if it is
               non-zero) instead of DURATM to correct IBM's error.      
              -Variable CPUPDTTM is added to PDB.RMFINTRV.  (It was the 
               validation of this user request that exposed the prior   
               MXG error!).                                             
   Thanks to Kenneth D. Jones, Xwave, CANADA.                           
Change 22.049  Variable TMNTUSER added to the Mount record is actually  
VMACTMNT       the existing LOCLINFO variable (in all JOB-related SMF   
Mar 21, 2004   records), so TMNTUSER variable no longer exists.         
Change 22.048  If SPF Statistics are enabled, the MXG.SOURCLIB PDS will 
JCLINSTL       now require 1199 directory blocks; JCL examples with 999 
JCLTEST9       blocks were increased to 1199.  Without SPF statictics,  
COVERLTR       only 399 blocks are required.                            
Mar 21, 2004                                                            
   Thanks to Peter Giles, Centrelink, AUSTRALIA.                        
Change 22.047 -Datasets QAPMTCP and QAPMIFC were not automatically built
TYPEQACS       by TYPEQACS/TYPSQACS, so they were not listed in DOCVER. 
TYPSQACS      -Variables PCTCPUBY NRCPUS were not labelled in QAPMSYSL. 
VMACQACS      -Variable INTSEC was not kept in QAPMTCP nor QAPMIFC.     
Mar 21, 2004                                                            
   Thanks to Chris Weston, SAS ITRM, USA.                               
Change 22.046  %VMXGTIME was invoked before SYSTEM had been input in two
VMACRMFV       places; the %VMXGTIME and IMACSHFT invocations were moved
Mar 20, 2004   to below the INPUT of variable SYSTEM.                   
   Thanks to Michael Oujesky, MBNA, USA.                                
Change 22.045  Dataset PDB.DB2STATB was not protected for wrap of 4-byte
VMACDB2        counters, which caused negative values in variables like 
               which can have very large raw values before their DIF(). 
               All other DB2 variables that are DIF()'d were protected. 
               This error was introduced in Change 21.140 when DB2STATB 
               was restructured and I forgot to protect for wrapping.   
   Thanks to Ron Alterman, PGE, USA.                                    
Change 22.044  The %%INCLUDE SOURCLIB(VGETJESN) should have been only   
ANALEPMV       one  %INCLUDE SOURCLIB(VGETJESN) because it is inside a  
Mar 18, 2004   %MACRO statement; two are needed inside MACRO statements.
   Thanks to David Klein, DOITT - City of New York, NY.                 
Change 22.043  APPL records with or without the nine APPRM variables are
VMACMWUX       supported in a heuristic test for LENGTH LE/GT 565, based
Mar 18, 2004   on 535/536 length without, 594/595 with, in test data.   
   Thanks to Miguel Fernandez, Information Services International, USA. 
Change 22.042  DB2 Statistics SMF 100 Subtypes 0, 1, and 2 have always  
VMACDB2H       been written to SMF in order, but because their QWHSSTCK 
Mar 18, 2004   datetime values could be fractions apart, I retained STCK
               from each 0 into its 1 so DB2STAT0 and DB2STAT1 had the  
               same value in QWHSSTCK, so they could be MERGEd to create
               DB2STATS directly.  But now, one site's DB2 6.1 SMF 100  
               records are completely out of order, with subtype 0 with 
               an earlier STCK written after that interval's subtype 1  
               with a later STCK value, and MXG's algorithm to create a 
               common QWHSSTCK value created this ERROR message:        
                 DB2 TYPE 100 SUBTYPE 1 FOUND AT START OF INPUT FILE.   
               The error corrupts the DB2STATS0,DB2STATS1 and DB2STATS  
               datasets; QWHSSTCK will have wrong values, and subtype 1s
               from one interval may be merged with subtype 0 from next 
               interval in the DB2STATS dataset, and negative values in 
               DB2STATB dataset may result when this message is printed.
              -The QWHSSTCK logic now recognizes the start of interval  
               as a delta of 10 seconds, and the first record's STCK is 
               now stored in QWHSSTCK for all three STAT subtypes.      
              -It's only a guess as to why this has not been seen before
               but it may be the "tactical" interval of one minute that 
               exposed the error; for whatever reason, it is now clear  
               that each of these subtypes are created by independent   
               subtasks, so their physical writes are not in any order, 
               and my ASSUMEption of order was wrong.                   
   Thanks to Ron Alterman, Pacific Gas and Electric, USA.               
Change 22.041  If you EXCLUDEd variable OPERATOR or TERMINAL in CICS SMF
ASUMCICS       and if you used ASUMCICS (which we no longer recommend)  
Mar 17, 2004   to create PDB.CICS, the length of OPERATOR and TERMINAL  
               are now $1, but they were $4 in previous versions.  This 
               can cause a warning if you combine PDB.CICS datasets in  
               your MONTHBLD that were built with two different versions
               of MXG.  This change restores the length to $4 for both. 
               See Change on why ASUMCICS may not be the         
               right program to use.                                    
   Thanks to Gary Keers, AES, USA.                                      
Change 22.040  The ANALALL example, which selects all SMF records from a
ANALALL        JOB(s), creates all MXG datasets from those SMF records, 
Mar 17, 2004   and then prints all observations and all variables, can  
               also be used to create an SMF output VBS file with all of
               the selected SMF records.  Comments in the member show   
               how to add                                               
                       FILE SMFOUT DCB=SMF;                             
                       PUT _INFILE_;                                    
                       FILE LOG;                                        
               after the IF JOB=:  selection in %LET MACJBCK=, and how  
               to add an //SMFOUT DD statement for those records.       
   Thanks to Alex Puno, LACO, USA.                                      
Change 22.039  If you use the _N42 macro to null data set creation, the 
VMAC42         _WTY4237 null definition was missing; it has been added. 
Mar 16, 2004                                                            
   Thanks to Jon Whitcomb, Great Lakes Educational Loan Services, USA.  
Change 22.038  ML-31 of the Exit-Based MXG Tape Mount, Allocation, and  
ASMTAPEE       Allocation Recovery monitor corrects GMT timestamps that 
Mar 15, 2004   should have been on the local clock, and supports an IBM 
Mar 25, 2004   MSC APAR that changed bit meanings.  The MXGTMNT DIAG    
               command provides additional diagnostics in its WTO text, 
               but will also write a "dump" to a file (for sites where  
               taking a "system dump" is political issue), if there is  
               an MXGDUMP DD included in the monitor program's JCL:     
                  //MXGDUMP DD RECFM=FB,LRECL=4160,BLKSIZE=4160,        
                  //           UNIT=SYSDA,SPACE=(CYL,(100,100)),        
                  //           DISP=(,CATLG),DSN=YOUR.CHOICE            
               The DIAG command is issued from a console:               
                   F jobname,DIAG                                       
               where jobname is the "job" name of the MXGTMNT monitor.  
              -The IBM IEF-VOLUME-MNT exit in our Exit-Based logic is   
               not called by StorageTek's HSC software, so you will NOT 
               see any mount records with HSC with MXIT=YES in ML-31.   
               Now that we've examined the dump and saw that STK did not
               call the IBM exit, and knew who/what to ask, STK has been
               very cooperative in providing documentation of HSC, so I 
               believe it is only a matter of time (weeks?) before our  
               "" will develop the needed enhancement to  
               support both HSC and IBM tape mounts with MXIT=YES.      
               April 1, 2004.                                           
Change 22.037  Support for NetMaster subtype 5000x record, Performance  
EXNETM50       Monitoring record.                                       
Mar 24, 2004                                                            
   Thanks to Andy Creet, Department of Defence, AUSTRALIA.              
====== Changes thru 22.036 were in MXG 22.01 dated Mar 11, 2004=========
Change 22.036  The MG070CP format, used only if you are still on OS/390,
FORMATS        or running z/OS on a non-zSeries machine, was updated for
Mar 11, 2004   the 2066-E1 and 2066-X2 processors.                      
   Thanks to Al Sherkow, I/S Management Strategies, Ltd., USA.          
   Thanks to Edward Ogonosky, Blue Cross Northeast PA, USA.             
Change 22.035  The z/VM MONWRITE "User" dataset, VXBYUSR, was left in   
VMACVMXA       the //WORK file and was not written to the //PDB, but now
VMXGINIT       is; this is the dataset with interval data for each CMS  
Mar 11, 2004   "user", i.e., each VM Machine, and is THE dataset to use 
               to track individual Linux-under-VM machine activity. Only
               the default output "DDname" was changed.                 
   Thanks to Reinhard Kelm, GAD, GERMANY.                               
Change 22.034 -Support for Candle optional CANADABN and CANADABT fields 
IMACICD4       (for Adabas Count/Duration variables of same NAME) is    
IMACICD5       added.  UTILEXCL will detect and tell you to open the    
UTILEXCL       comments in the appropriate IMAC, if fields exist in your
VMAC110        CICS SMF 110 records, with Candle's additions.           
Mar 10, 2004                                                            
   Thanks to James Hein, Erie Insurance, USA.                           
Change 22.033 -Support for XIDTYP='A' ADAPATER record in new QAPMIOP5   
EXQAPIO5       dataset.                                                 
IMACQACS      -Correction for LRECL=359 QAPMIOPD record which has an    
VMACQACS       extra byte betwen XIDTYP and XIDTA1.                     
Mar 10, 2004                                                            
   Thanks to Stan Dylnicki, Royal Bank of Canada, CANADA.               
Change 22.032  Support for Endeavor Release 4.0 user SMF (INCOMPATIBLE, 
VMACENDV       because ELEMT, DSNAME, and DSMEM fields were relocated.  
Mar 10, 2004   The Action Record (subtype 2) has been validated with    
               new data; the Block Header's record version had to be    
               used to identify the new format record because C1VER was 
               not changed (only has before/after 2.5), and SM2RECVN is 
               '01' in the new records.  The Security Record (subtype 2)
               also had incompatible changes, and has been coded, but no
               subtype 1 records have been validated.  The DSECT shows  
               a subtype 3 (ESI Exception) and a subtype 4 (MCF CHANGES)
               but there is no sub-DSECT for those records; if a 3 or 4 
               is found, MXG will print one record on the log.          
   Thanks to John Paul, Highmark, USA.                                  
Change 22.031  The ASUMJOBS logic calculated the Initiation Wait Time as
ASUMJOBS       IWT=INITTIME-JRDRTIME, but JRDRTIME is only in the Purge 
Mar  9, 2004   record, so a PDB.JOBS observation that did not have a    
               Purge record (probably because member IMACSPIN had not   
               been tailored to change MXG's SPINCNT=0 default) had a   
               missing value for JRDRTIME, causing IWT to be missing.   
               This caused the summarized observations in PDB.JOBSKED to
               have incorrect bucket percentages because IWT missing was
               counted as a zero-wait job. It also caused IWT (summed)  
               to be equal to IWTMAX in some obs that had NUMJOBS more  
               than one (but closer examination showed that these case  
               actually had had only one job with non-missing IWT!).    
               The IWT calculation was revised; if JRDRTIME is missing, 
               IWT=INITTIME-SUM(READTIME,RDRTM) is used, as those data  
               are in the JOB Termination record.  And if the IWT is    
               still a missing value, that job will be deleted.         
   Thanks to Miguel F. Montferrer Carvajal, RSI EDS, ESPAGNE.           
Change 22.030  Support for DF/SMS Storage Class Exit User SMF record,   
EXSMSXSC       written at Storage Class assignment, so you can examine  
FORMATS        how your ACS rules actually perform.   New dataset:      
IMACSMSX         dddddd     Dataset   Description                       
TYPSSMSX       I arbitrarily only output the first six VOLSERS of the   
VMACSMSX       possible 1464 volumes that a dataset can have, until     
VMXGINIT       someone needs all of them!.  I was unaware of that limit.
Mar  9, 2004                                                            
   Thanks to Tobias Cafiero, Depository Trust and Clearing Company, USA.
Change 22.029  Support for new SMF 117 record from WBIMB, WebSphere     
EX117FLO       Business Integration Message Broker creates four new     
EX117THR       datasets:                                                
EX117NOD           dddddd     Dataset   Description                     
EX117TRM           117FLO     S117FLOW  MESSAGE FLOW                    
FORMATS            117THR     S117THRD  THREAD                          
IMAC117            117NOD     S117NODE  NODE                            
TYPE117            117TRM     S117TERM  TERMINAL                        
TYPS117        Data for FLOW, THREAD, and NODE have been validated.     
Mar  8, 2004                                                            
   Thanks to Victoria LePak, AETNA, USA.                                
   Thanks to Jeff Martens, AETNA, USA.                                  
Change 22.028  The BY-list-macro _BCICRDQ for new CICSRDQU had TSQNAME, 
VMAC110        but that should have been TSQUEUE.  This misspelling was 
Mar  5, 2004   missed because CICSRDQU is not sorted by default.        
   Thanks to Chris Weston, SAS ITRM, USA.                               
Change 22.027 -Variable SM120WIP is a count, not a duration; it is input
VMAC120        now as &PIB.4. instead of &PIB.4.3, and is no longer in  
Mar  5, 2004   the TIME13.3 format list.                                
Mar 10, 2004  -For subtype=7, MXG output only the first server segment  
               from web application section, causing the counts in the  
               web activity TYP120WA dataset to be wrong, and much lower
               than corresponding web interval counts in TYP120WI.  All 
               server segments are now output.                          
   Thanks to Andre Baltimore, Unigroup Inc, USA.                        
Change 22.026  Cosmetic.  The time-of-day when the read of the SMF file 
VMACSMF        ended is now printed in the "SUCCESSFULLY READ SMF FILE" 
Mar  4, 2004   message on the SAS log.                                  
Change 22.025  The JCL Procedure for MXG and SAS execution for SAS V 9.1
MXGSASV9       is slightly different than the original SAS V9.0 JCL. The
Mar  4, 2004   entry point is SAS, the "BATCH" config member is BATWO,  
               and the DSNAMES are now .WO.AUTOLIB, .ENW0.SASHELP, and  
   Thanks to Ed Finnell, University of Alabama, USA.                    
Change 22.024  This text just documents all of the names of %MACROs that
doc            are currently defined anywhere in MXG source code.       
                   CDE_BVR  CDE_DCL  CDE_DCR  CDE_DGN  CDE_DSR  CDE_DVL 
                   CDE_L2CR CDE_MC1  CDE_MCA  CDE_MCB  CDE_MCC  CDE_MCD 
                   CDE_MCM  CDE_MCO  CDE_MCP  CDE_MCR  CDE_MCT  CDE_MCU 
                   DSNUPDT  DSNUPDT  DSNUPDT  DT       EMAIL    EPIVARS 
                   OUT_DSR  OUT_DVL  OUT_L2CR OUT_MC1  OUT_MCA  OUT_MCB 
                   OUT_MCC  OUT_MCD  OUT_MCM  OUT_MCO  OUT_MCP  OUT_MCR 
                   OUT_VSR  PCSRREPT PERIOD   PMACC01  PMACC02  PMAUD01 
                   PMAUD02  PMAUD03  PMIOS01  PMIOS02  PMIOS03  PMIOS04 
                   PMIOS05  PMLOK01  PMLOK02  PMLOK03  PMLOK04  PMSPR01 
                   PMSQL01  PMSQL02  PMSQL03  PMSQL04  PMSTA01  PMSTA02 
                   PMTRC01  PMTRC02  PMTRN01  POLICY   PRINTIT  PRINTNL 
                   PRT_DGN  PRT_DSR  PRT_DVL  PRT_L2CR PRT_MC1  PRT_MCA 
                   PRT_MCB  PRT_MCC  PRT_MCD  PRT_MCM  PRT_MCO  PRT_MCP 
                   PRT_VAC  PRT_VSR  PSSTAT   RCLASS   RDCAT    READDB2 
                   READMAP  READMXG  READREC  READSAR  REAL     REG     
                   RPTRMG   RPTTCR   RPTTSR   RPTXMR   SCLASS   SCPER   
                   SPLITCHK SPMAP    SRIF     SRVPOLCY STM      SUMRIZE 
                   VAR_BVR  VAR_DCL  VAR_DCR  VAR_DGN  VAR_DSR  VAR_DVL 
                   VAR_L2CR VAR_MC1  VAR_MCA  VAR_MCB  VAR_MCC  VAR_MCD 
                   VAR_MCM  VAR_MCO  VAR_MCP  VAR_MCR  VAR_MCT  VAR_MCU 
                   XMINX    _MTG01   _MTG02   _NDMMAKE _VRD30           
Change 22.023  No Change, doc only. PCHANBY over 100% for SMF73ACR='OSD'
VMAC73         channels occurs but variable VARIED='Y' (bit 6 SMF73FG2) 
Mar  4, 2004   is true in those obs.  The SMF manual says for bit 6:    
                "Data Recorded is incorrect because channel path was    
                reconfigured during the interval".  While I could chose 
               to not calculate fields, it has always been my policy to 
               give you whatever IBM puts in the record, so you can then
               chose to keep or not to keep that observation in reports.
               And, hopefully, the larger-than-100% value will cause you
               to find this note, understand why, and then take actions 
               for your installation to delete those observations from  
               your reports.                                            
   Thanks to Frank DeBree, DEXIA, BELGIUM.                              
Change 22.022 -Variable LOSU_SEC (unweighted service units per second of
BUILD005       the hardware platform where this step executed) is kept  
BUIL3005       in PDB.STEPS and PDB.JOBS.                               
VMAC30        -Two new service-unit-based CPU variables are created in  
Mar  4, 2004   TYPE30_x, PDB.SMFINTRV, PDB.STEPS, and PDB.JOBS datasets;
               so they can be compared with the SMF-recorded TCB and SRB
                  SRVTCBTM='SERVICE*UNIT*BASED*TCB TIME'                
                  SRVSRBTM='SERVICE*UNIT*BASED*SRB TIME'                
               The CPUUNITS, SRBUNITS & LOSU_SEC are in SMF 30 records, 
               but the CPUCOEFF/SRBCOEFF coeffs are not.  They are only 
               in RMF 72s, but since they almost never are changed, the 
               new variables use macro variables which default to ONE,  
               a very common weighting value.  You MUST override default
               coefficients, using these %LETs in IMACKEEP or //SYSIN:  
                  %LET CPUCOEFF=10;                                     
                  %LET SRBCOEFF=10;                                     
               if CPUCOEFF and SRBCOEFF in TYPE72/TYPE72GO are not one. 
               Note: IBM added those coefficients into the SMF 30 record
                     with APAR OA09118, and they will be used if that   
                     APAR has been installed.  See Change 22.341.       
               Cheryl Watson suggested using SU-based CPU time instead  
               of SMF CPU time, because SUs have more precision than the
               .01-second SMF resolution, and truncation of those extra 
               decimal places added up to a few hours of CPU per month. 
               I examined 879 step records (z/OS 1.5), and did find 216 
               steps with SRV TCB/SRB CPU times greater than their SMF  
               TCB/SRB CPU times, but the max delta was only 0.0069 secs
               and the "extra" SRV time, due only to truncation, was a  
               total of only 0.62 seconds for those 216 steps.          
               However, I also found there were 377 other steps that had
               SMF TCB/SRB CPU time greater than SRV CPU; 38 steps had  
               deltas of over 1 second, and the total SMF CPU captured  
               was 168 seconds more than the SRV captured CPU time, so  
               replacing the SMF CPU with the SRV CPU seems unwise.     
               But what does make sense, now that I have the variables, 
               is to use the maximum TCB/SRB time, so any decimals that 
               would have been truncated won't be, creating new variable
                 CPUTOTTM='TOTAL CPU*MAX TCB,SRB*FROM SMF OR SU'        
               with this equation in SMF 30 processing:                 
               However, remember that CPUTOTTM is COMPLETELY DEPENDENT  
               on you having %LET correct CPUCOEFF and SRBCOEFF values, 
               if your coefficients are not the MXG default of one.     
              -Now, see also the text of Change 22.265.                 
   Thanks to Cheryl Watson Walker, Watson & Walker, USA.                
Change 22.021 -Job delay variables SMF30HQT/JQT/RQT/SQT should not have 
VMAC30         been created in TYPE30_V,PDB.SMFINTRV,TYPE30_6 interval  
Mar  3, 2004   datasets from subtype 2,3,6 type 30 records, because they
Mar  8, 2004   are job-level, and not interval-level.  Their value is   
Mar 12, 2004   now always set to a missing value for those records.     
              -TYPE30_4 dataset, those job-related variables will now be
               missing except in the STEPNR=1 observation.              
              -TYPE30_5 dataset, those job-related variables will now be
               missing if TYPETASK IN ('STC','OMVS'), as they are not   
               "jobs that are initiated".                               
              -No changes were made to BUILDPDB code; those variables   
               are summed from their TYPE30_5 observation(s) into the   
               PDB.JOBS dataset, so they will be non-zero if variable   
               INBITS contains a "J" in the third character, indicating 
               that a 30-5 job termination was found for this job.      
              -Variable SMF30PF2, flag byte 2 is now kept.              
              -Jobs run under CA's JobTrack control have zeros for these
               variables in their type 30-5 record, even though they are
               non-zero in step records, but it is not JobTrack's error.
               We now find that ANY job that has a flushed last step has
               zero values for SMF30HQT/JQT/RQT/SQT in the job's SMF 30 
               subtype 5, even when the step records have non-zero      
               values; JobTrack showed up because it adds a non-executed
               step at the end of every job under its control for       
               tracking information! The zero values, I believe, are an 
               IBM error in failing to propagate the values when the    
               last step is flushed, and a problem report will be opened
               with IBM; this note will be updated when IBM replies.    
   Thanks to Bret Hoesly, TDS, USA.                                     
Change 22.020  The example to create only DB2ACCT.DB2ACCT & PDB.DB2STATS
Mar  2, 2004   redesign in Change 21.140 moved the interval statistics  
               for buffers into DB2STATB, which is now required as input
               to create the desired PDB.DB2STATS summary dataset.  The 
               example now creates DB2STATB, DB2STAT0, and DB2STAT1 so  
               PDB.DB2STATS can be created, but they are written to the 
               //WORK file, so only the two desired datasets are kept.  
                  //SYSIN DD *                                          
                   %LET PDB2ACC=DB2ACCT;                                
                   %LET PDB2ST0=WORK;                                   
                   %LET PDB2ST1=WORK;                                   
                   %LET PDB2STB=WORK;                                   
                   %LET MACKEEP=                                        
                           MACRO _WDB2ACC _LDB2ACC %                    
                           MACRO _WDB2ST0 DB2STAT0 %                    
                           MACRO _WDB2ST1 DB2STAT1 %                    
                           MACRO _WDB2STB DB2STATB %                    
                           MACRO _SDB2 _SDB2STB _SDB2STS %              
                           MACRO _SDB2ACP %                             
                           MACRO _SDB2ACB %                             
                           MACRO _SDB2ACG %                             
                           MACRO _SDB2PAT %                             
                           MACRO _SDB2ST2 %                             
                           MACRO _SDB2STR %                             
                           MACRO _SDB2PST %     );                      
                   %INCLUDE SOURCLIB(TYPSDB2);                          
   Thanks to John Croasdale, Abbey National, ENGLAND.                   
Change 22.019 -Variables STARTIME and DURATM are now created in each of 
VMAC119        the 119 interval statistic datasets, TYP11905, TYP11906, 
Mar  3, 2004   TYP119A7, and TYP119B7. There are four duration variables
               in TYP11905, but all have identical values in test data, 
               so DURATM is set to the MAX of the four variables.  Some 
               labels were revised and misspellings corrected. All other
               TYP119xx datasets are events, rather than intervals, so  
               they don't contain the STARTIME/DURATM pair.             
              -Variable TCDURTM and UDDURTM are now divided by 4096 vice
               by 496.                                                  
              -Protective double question mark modifiers were inserted  
               before the two &NUM.3. inputs for FCLREPLY and FSLREPLY. 
   Thanks to Chris Weston, SAS ITRM, USA.                               
Change 22.018  All references to the "SPIN" DDNAME/LIBNAME have been    
ASUMTALO       replaced with macro variables &SPININ or &SPINOUT, so    
ASUMTAPE       that input and output can be separate MVS datasets.  As  
BUIL3005       both macro variables default to "SPIN", this should be a 
BUILD005       transparent change.  This enhancement is needed by sites 
JCLUOWP        that run their MXG jobstream under CA's Job Scheduler,   
JCLUOWV        which requires separate datasets for its recoverability. 
SPINSORT       To use this enhancement, you would change your JCL to    
VMACFRYE           // EXEC MXGSASV9                                     
VMXGINIT           //SPININ DD DSN=OLDSPIN,DISP=SHR                     
VMXGRMFI           //SPINOUT DD DSN=NEWSPIN,DISP=(,CATLG),...           
VMXGUOTT       and put your %LETs either in //SYSIN or in IMACKEEP:     
VMXGUOW                 %LET SPININ=SPININ;                             
VMXGUOWT                %LET SPINOUT=SPINOUT;                           
Mar  2, 2004  -These VMXGRMFI temporary datasets that should have been  
               deleted, now are:                                        
                 MERGEMSU MERGESOR SPUNRMFI                             
              -Typo'd member named VMAGUOTT was discovered and deleted. 
Change 22.017  FLASH: BUILDPDB (only-under"MVS") runtime elongation can 
VGETENG        be significant IF any output libraries (like CICSTRAN or 
VMXGRMFI       DB2ACCT) are on tape or in sequential format on DASD.    
VMXGSUM          This problem does NOT affect ITRM's normal job, because
VMXGSUME         %CPPROCES/CMPROCES puts everything in //WORK, and ITRM 
Mar  2, 2004     doesn't use tape libraries during its "BUILD".         
Mar 12, 2004   This problem was introduced in MXG 19.19, when %VGETENG  
               was added in VMXGRMFI, to test if a //SPIN DD existed.   
               VMXGRMFI is called by RMFINTRV, which is automatically   
               included in MXG's BUILDPDB.  If you do NOT use tapes for 
               output in your BUILDPDB job, you don't have this problem.
               The PROC SQL with FROM DICTIONARY.MEMBERS in VGETENG gets
               the ENGINE of //SPIN, but no WHERE LIBNAME=SPIN clause   
               was used, so the PROC SQL had to read all LIBNAMEs to    
               populate the DICTIONARY.MEMBERS table.  If your CICSTRAN 
               and DB2ACCT are both multi-vol on tape, you would have   
               these mount messages on the BUILDPDB's job log:          
                  SMF Opened, read started               14:25          
                  CICSTRAN  Mount-Dismount 5 vols        14:24-16:06    
                  DB2ACCT   Mount-Dismount 2 vols        14:24-15:25    
                  SMF Closed, read completed                   16:12    
                  VGETENG-remount/read 2 DB2ACCT vols    16:17-16:30    
                  VGETENG-remount/read 5 CICSTRAN vols   16:40-17:09    
                    Total Elapsed time:  164 minutes with re-read.      
               VGETENG wasted 52 minutes, mounting and reading the seven
               tapes!  For DASD data libraries, PROC SQL only has to    
               read the directory of SAS datasets in that library, but  
               for sequential format libraries, PROC SQL has to read the
               entire sequential file, because tape format libraries do 
               not have a directory of datasets.                        
               And PROC SQL doesn't print any message on the SAS log to 
               tell you it was the cause of the extra CICSTRAN & DB2ACCT
               mounts. The only clue to the elongation are those extra, 
               and unexpected, tape mount messages on the job's SYSOUT! 
               Elapsed and CPU time, and EXCPs of your daily job can be 
               reduced significantly, if you use tape output on MVS in  
               your BUILDPDB job, with either circumvention:            
               Immediate circumvention, any of the three fixes:         
                 1. Replace MXG 21.21 with MXG 22.01, now available.    
                    See text of Change 22.017 for lots of details.      
                 2. Change the JCL:                                     
                    Add ,FREE=CLOSE to the //CICSTRAN and //DB2ACCT and 
                    to any other output DDs that are on tape/seq format.
                 3. Or, change the MXG source code:                     
                    a. EDIT/CREATE member EXPDBOUT in USERID.SOURCLIB   
                       tailoring library, and add a statement:          
                            LIBNAME CICSTRAN CLEAR;                     
                            LIBNAME DB2ACCT  CLEAR;                     
                       for each tape (or sequential format) DDNAME.     
                    b. Or do the same in your //SYSIN stream, using:    
                         //SYSIN DD *                                   
                           %LET MACKEEP=                                
                              %QUOTE(   MACRO _EPDBOUT                  
                                          LIBNAME CICSTRAN CLEAR;       
                                          LIBNAME DB2ACCT  CLEAR;       
                           %INCLUDE SOURCLIB(BUILDPDB);                 
                  of job....                          
               Discussion of the circumventions:                        
               - Using FREE=CLOSE.  This appears to always be safe.     
                 The FREE=CLOSE occurs when CICSTRAN/DB2ACCT/etc are    
                 closed, at the end of reading the SMF file, so PROC SQL
                 in VMXGRMFI won't see those sequential LIBREFs so they 
                 won't be read.  But even if your job does then %INCLUDE
                 any of the ASUMCICx, ASUMDB2A, or ASUMUOW members that 
                 read those data libraries, SAS is still able to re-open
                 the LIBREF that was FREE=CLOSEd, without any error.    
                 Like magic!                                            
                 And using FREE=CLOSE on //SMF DD seems always wise and 
                 courteous, so the device can be available to another.  
               - Using LIBNAME xxxxxxxx CLEAR; in EXPDBOUT also appears 
                 to be completely safe.  EXPDBOUT is a little later than
                 the close of the SMF file, after a few PROC SORTs, but 
                 the CLEAR closes the LIBNAME so PROC SQL in VMXGRMFI   
                 never sees those LIBNAMES to read, but the allocation  
                 can be re-opened, if, for example, you %INCLUDE any of 
                 the ASUMxxxx's that read DB2ACCT or CICSTRAN.          
               - With either circumvention, harmless messages are on the
                 SASLOG for each DDNAME, at deallocation time:          
                          IT WAS ALLOCATED EXTERNALLY                   
                    NOTE: LIBREF XYZ HAS BEEN DEASSIGNED                
               - The circumventions do not have to be removed when you  
                 install an MXG Version with this change.               
               - The choice of changing JCL or MXG source depends only  
                 on whichever is easier to do within your production    
                 change control system for your MXG daily jobs!         
               Permanent Changes made in this change:                   
               a. VMXGRMFI.  The permanent correction in this change:   
                  - %VGETENG(DDNAME=SPIN) and ENGINE logic was removed. 
                  - If you execute VMXGRMFI/RMFINTRV by itself, a //SPIN
                    DD is now required; you'll get an obvious SAS error 
                    if you don't have one.                              
                   The test that caused this problem was added only to  
                   prevent an abend that might happen, only if you used 
                   RMFINTRV in a standalone job.  RMFINTRV is normally  
                   created by BUILDPDB, and a //SPIN DD has always been 
                   provided in JCLPDBxx examples, but when the MSU4HRAV 
                   variable was created in PDB.RMFINTRV, the history of 
                   the last four hours was to be "spun" in SPIN.SPINRMFI
                   if a //SPIN DD was found.  But if you ran RMFINTRV in
                   a standalone job that didn't have a //SPIN DD, the   
                   MSU change would cause your "running just fine" daily
                   job to fail.  So the VGETENG and associated logic was
                   added in VMXGRMFI in MXG 19.19 to protect no //SPIN. 
                   Unfortunately, even that was also wrong. The PROC SQL
                   with DICTIONARY.MEMBERS sees only LIBNAMEs that are  
                   OPEN, and BUILDPDB has not OPENed the SPIN library   
                   when RMFINTRV is called, VGETENG set ENGINE=UNKNOWN  
                   and so SPIN.SPINRMFI has never been created; only the
                   WORK.SPINRMFI has been output, and then deleted!     
                      Fortunately, the only impact is that MSU4HRAV in  
                      PDB.RMFINTRV has missing values for the first four
                      hours of each day.  But since you have been wisely
                      using the PDB.ASUM70PR/ASUMCEC/ASUM70LP LPAR data 
                      to measure and report "MSU" capacities, you have  
                      never noticed nor used MSU4HRAV in PDB.RMFINTRV.  
                      It was added for convenience when looking at a    
                      single SYSTEM in RMFINTRV data.                   
                   Now, SPIN.SPINRMFI will always be created.           
               b. VGETENG: Permanent change, but VGETENG is NOT used in 
                           VMXGRMFI with this change.  Read carefully.  
                   You can heal VGETENG's missing WHERE clause problem  
                   by copying the member VMXGENG into member VGETENG,   
                   and then CHANGE "VMXGENG" "VGETENG" ALL.  The old    
                   VMXGENG member does have the needed WHERE clause.    
                   However, even with a WHERE clause, if the DDNAME is a
                   sequential format library, PROC SQL still must read  
                   all of that (one) data library.  And if it happens to
                   be a multi-volume, extended format, striped, and DASD
                   hardware compressed dataset; it will take time and   
                   there won't even be mount messages to account for the
                   wasted time.                                         
                   The VMXGENG member worked fine with its WHERE clause,
                   but when I standardize macro/member names that "GET" 
                   a value to start with VGET instead of VMXG prefix, I 
                   got a VGETENG without the WHERE clause.  We would not
                   be having this pleasant conversation if I had used   
                   %VMXGENG in VMXGRMFI in place of the new %VGETENG.   
                   But since the %VGETENG is not removed from VMXGRMFI, 
                   it really doesn't matter, now.                       
               c. VMXGSUM, VMXGSUME:  A very minor exposure to delay.   
                   If you created your own %VMXGSUM execution that uses 
                   TEMP01=, TEMP02=, TEMP03= arguments (DDNAMEs for temp
                   workspace), a PROC SQL; FROM DIRECTORY.MEMBERS is    
                   used to find the engine, which was then set to VnSEQ,
                   if the fall-thru case of UNKNOWN engine is found, so 
                   that an extended-format, hardware compressed, striped
                   file can be used, if that's in the DATACLAS/STORCLAS.
                   Since this PROC SQL does have the WHERE clause, only 
                   the one TEMPnn DD would be read, but it would be read
                   once for every %VMXGSUM invocation.                  
                   But because the primary reason for TEMPnn= arguments:
                      to circumvent limitations back in SAS Version 6   
                      for multi-volume temporary disk data libraries    
                   was eliminated by SAS V8 multi-volume support, I have
                   removed this exposure by removing the PROC SQL and   
                   logic for ENGINE in the VMXGSUM members.  If you are 
                   bright enough to use those specialized files that    
                   require a sequential engine, that I believe you are  
                   also bright enough to know that you need to add a    
                       LIBNAME TEMPnn VnSEQ;                            
                   in your program before your %VMXGSUM invocation.     
                   Especially since SAS will tell you if is needed!     
                d. Two other MXG "utility"s use FROM DICTIONARY.MEMBERS:
                   - VGETDDS, which you would use ahead of VMXGSET to   
                     read multiple SAS libraries for the same dataset.  
                   - VGETDSN, which returns the MVS DSNAME of a SAS data
                   As both members have WHERE clauses for the LIBNAME,  
                   so only one library would be read in any case, and as
                   both are optional and unlikely to be used during the 
                   BUILDPDB process, they remain unchanged.             
   Thanks to Jim Poletti, Edward D. Jones, USA.                         
Change 22.016  The ANALSRVC report still had BY SYSTEM STARTIME for the 
ANALSRVC       RMF sort order, and failed with RECORDS OUT OF ORDER;    
ANALPGNS       BY SYSPLEX SYSTEM STARTIME has been the RMF sort order   
ANALSTOR       for years, but these examples had not been updated until 
ADOCPDB        now.                                                     
Mar  1, 2004                                                            
   Thanks to Dave Crowley, Blue Cross Blue Shield of Florida, USA.      
Change 22.015  Cosmetic.  White space was inserted after single quotes  
ANALDB2R       to eliminate the SAS Version 9.1 " 49 " Warning message. 
Feb 29, 2004                                                            
   Thanks to Bruce Widlund, Merrill Consultants, USA.                   
Change 22.014  WebSphere SMF 120 records don't have GMT offset, and the 
VMAC120        MXG algorithm was wrong, so all of the SM120xxx datetime 
Feb 27, 2004   variables were wrong, if your GMT offset is non-zero.    
               Some were off by one-GMT-offset, some were off by two!   
               And SM120WAU could still be wrong, if it spans the       
               Spring/Fall time changes, since it can be several days   
               earlier than the SMFTIME of the record.                  
   Thanks to Tom Draeger, Aurora Health, USA.                           
Change 22.013 -Members EXNDMIP and EXNDMSP were removed; all references 
EXNDMIP        to NDMIP and NDMSP were removed; the IP and SP subtypes  
EXNDMQT        are output in the NDMDT dataset.                         
EXNDMSP       -Member EXNDMQT and all references to NDMQT were removed; 
EXNDMTI        subtype "QT" is output in NDMQE.                         
EXNDMUM       -Member EXNDMTI and all references to NDMTI were removed; 
VMACNDM        subtype "TI" is output in NDMCI.                         
VMXGINIT      -Member EXNDMUM and all references to NDMUM were removed; 
Feb 26, 2004   subtype "UM" is output in NDMAE.                         
              -Data set Label "NDM AUTHORIZATION" was revised to show   
               the subtypes, for severaly NDM datasets.                 
   Thanks to Chris Weston, SAS ITRM, USA.                               
Change 22.012 -Variables RACFUSER & RACFTERM were reversed in MXG code. 
VMACTMNT      -The new subtype 6 stats record from ML-28/ML-29 caused an
Feb 26, 2004   INPUT STATEMENT EXCEEDED error; MXG expected ML-30, which
               which added two new fields.                              
              -Pending March 3: some timestamps created in ASMTAPEE are 
               on GMT clock, and support for a bit-changing APAR are in 
   Thanks to Tom L. White, SPRINT, USA.                                 
   Thanks to Jon Whitcomb, Great Lakes Educational Loan Services, USA.  
   Thanks to Normand Poitras, IBM Global Services, USA                  
Change 22.011  Calculation of PCTCPUBY in PDB.TYPE70PR for IRD was not  
VMAC7072       correct for any engine with SMF70ONT less than DURATM.   
Feb 24, 2004   The calculation of PCTCPUBY was revised to use SMF70ONT  
               as the denominator instead of DURATM when IRD has varied 
               the engine off during the interval.  This only affected  
               the PDB.TYPE70PR dataset; both PDB.ASUM70PR and ASUMCEC  
               with MXG 21.05 (Change 21.170), but see Change 22.050.   
   Thanks to Scott Barry, SBBWorks, USA.                                
Change 22.010  Two typographic errors were corrected; /* before SMCASID 
RMFMON         instead of just /, and in the PUT statement variable name
Feb 24, 2004   IRARMCNS instead of IRAMCNS.                             
   Thanks to Daniel T. Cannon, The Hartford, USA.                       
Change 22.009  Hyperspace buffers, reads, and writes variables are now  
VMACMBO        input and kept.                                          
Feb 24, 2004                                                            
   Thanks to Job Babcock, Bank One, USA.                                
Change 22.008 -The TPMX arrays were redesigned so that it is no longer  
EXTYTPMX       fatal to have more instances in your data than you %LET  
IMACTPMX       in your IMACTPMX member.  A new message will be printed: 
Feb 22, 2004   with the name "JBL19nn" of the %LET statement to change, 
Feb 24, 2004   but extra instances are skipped and all records are now  
Feb 25, 2004   output.  New variables with the same name as the macro   
Mar 11, 2004   variable are created in TYPETPMX dataset, so you can use 
               PROC MEANS DATA=TYPETPMX MAX; to see how many instances  
               were found in your data.  The %LET statements in IMACTPMX
               set the number of variables created in each array, and   
               all variables are normally kept, but you can increase the
               %LET to eliminate the message, and then use the example  
               DROP statements in your EXTYTPMX member, if you don't    
               want to output that many instance variables.             
              -Array names were changed (since they are internal to the 
               VMACTPMX code) and all now match the base of the variable
               name that are output; the "WHEN" values in the format are
               also changed for the arrays and also match the base name.
              -Format "VARNAME" values were also changed to match their 
               array base name.                                         
              -Bind variables were not output, but are now.             
              -The original count variables are still kept, to prevent a
               VARIABLE NOT FOUND condition, but those variables can be 
               removed by uncommenting this DROP statement in EXTYTPMX: 
                      JBLL4C JBLL5C JBLL6C JBLL7C JBLL8C JBLL9C JBL10C  
                      JBL11C JBL12C JBL13C JBL14C JBL15C JBL16C JBL17C  
                      JBL18C JBL19C JBL20C JBL21C JBL22C JBL23C JBL24C; 
              -Documentation of the syntax of the PROC FORMAT in the    
               IMACTPMX member was (hopefully!) improved.               
   Thanks to Richard S. Ralston, Humana, USA.                           
VMACEDGR       kept in EDGRVEXT dataset; previously it was only INPUT   
Feb 18, 2004   and kept in EDGRXEXT dataset.                            
   Thanks to Ray Bole, IBM Global Services, USA.                        
Change 22.006  Support for Huron/Object Star subtype 23, and corrections
EXHRN23        for subtypes 08, 11, 22, 24, 26, which could cause an    
IMACHURN       INPUT STATEMENT EXCEEDED error.  New HURN23 dataset is   
VMACHURN       created. The symbol  #   was removed from labels; they   
VMXGINIT       are not needed and don't always print correctly. Huron   
Feb 18, 2004   Versions R3 and R4 have been tested with this change.    
   Thanks to Greg Meyer, Isuzu, USA.                                    
Change 22.005  Support for subtypes 14 thru 19 for SMF 82 CRYPTO records
EXTY8214       creates new TYPE8214 thru TYPE8219 datasets.             
Feb 17, 2004                                                            
   Thanks to Willy Iven, Fortis Bank, BELGIUM.                          
Change 22.004  New variable ZTIME='ZEE DATETIME*ZEE OBS*WAS CREATED' is 
IMACZDAT       created and retained in member IMACZDAT, which currently 
VMACEDGS       creates the existing ZDATE variable.  ZTIME is needed for
VMACTMS5       raw data that doesn't have a "datetime" event variable,  
Feb 17, 2004   like TMS/CA-1 and DFSMS/rmm tape data that are created by
               taking a "snapshot" of the tape catalog by running a job.
               The new ZTIME variable can be used to detect or separate 
               multiple runs, and can be used for duplicate observation 
               detection, and can eliminate the need for ITSV sites to  
               tailor MXG exits.                                        
               Variable ZTIME is kept in TYPETMS5 and TYPEEDGS datasets.
   Thanks to Christa Neven, KBC BankVVerzekeringsHolding, BELGIUM.      
Change 22.003  Several new APPLICATION PRM METRICS are now supported and
VMACMWUX       these variables created in HPUXAPPL dataset.             
Feb 16, 2004    APPPRMMD='APPPRM*LOGGING*MODE*APP=0*PRM=1?'             
   Thanks to Miguel Fernandez, Information Services International, USA. 
Change 22.002 -MQ Series variable WTINDXTY, index type, is now decoded  
FORMATS        with format MG116IN:                                     
Feb 16, 2004      VALUE  MG116IN                                        
Feb 17, 2004       0='0:NO INDEX'                                       
                   1='1:MSG_ID INDEX'                                   
                   2='2:CORREL_ID INDEX'                                
                   4='4:MSG_TOKEN INDEX'                                
                   5='5:GROUP_ID INDEX'                                 
               Index type can be a critical factor in WebSphere MQ      
               message retrieval. With No Index, message retrieval for a
               browse is sequential, and can take a long time for large 
               queues, since each page must be retrieved to see whether 
               the page contains the message of interest.  With indexing
               it can take only one page retrieval, and the difference  
               can be seconds or even minutes.  If the browse is of many
               messages, the difference can be "many" times the scan of 
               a single queue, since the queue must be scanned for each 
               message retrieved.  And this really gets *ugly* if the   
               queue has spilled over to the page set on DASD.          
              -Labels for WQPUTPMS,WQPUT1PM are 'PERSISTENT*CREATED...' 
               instead of 'PERSISTENT*GOT'. MQPUT calls create messages,
               MQGET calls retrieve messages (either GET-and-delete or  
               BROWSE).  And the distinction between NON-PERSISTENT and 
               PERSISTENT is important because the two types should not 
               normally be intermingled in a queue, for performance.    
   Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA   
Change 22.001  Support for MQ Series counts and times in ASG-TMON/CICS  
VMACTMO2       adds four variables to MONITASK and                      
Feb 12, 2004   See MXG Tech Note 4.A in Newsletter FORTY-FOUR, 11Feb04. 
   Thanks to Alex Nielsen,                                              
The below Change may be required for your MXG 21.21, depending on its   
internal date.  Tape were copied starting Feb 6, and that edition of the
MXG 21.21 annual version need this change.  But if your CHANGES in your 
MXG 21.21 indicates Feb 11, 2004, then this change is already installed.
Change 21.320  MXG 21.21 final post-QA corrections/incompatibilities:   
CLRMFV        -SEQENGINE=V6SEQ changed to V8SEQ/V9SEQ in CONFIGV8/V9.   
               in May, 2004, in Change 22.108.                          
CONFIGV8       See MXG Tech Note 4.A in Newsletter FORTY-FOUR, 10Feb04. 
CONFIGV9      -VMACDB2. Remove line 8259: PUT _N_= 'HAVE 239 ';         
EXTMNSTS      -UTILEXCL. Add a second percent-sign to change line 218 to
IMACTMNT                   %%INCLUDE SOURCLIB(IMACZDAT);                
UTILEXCL      -CLRMFV. Cosmetic. A "NOT" and EQUAL symbols slipped thru 
VMAC90         and were changed to "NE"; NOTs don't translate well among
VMACDB2        platforms, and were removed back in Change 8.093         
VMACTMNT      -Only if you received MXG on CD: Change line 57 in member 
VMXGINIT       VMACTMNT, removing  "DEVNR", changing the line to be:    
Feb 10, 2004           MACRO _BTYSTS SYSTEM SHIFT INTBTIME %            
              -The CD-only VMACTMNT error was caused by my accidental   
               copying of support for the new TYPESTAT statistics data  
               from the subtype 6 ASMTAPEE ML-30 SMF record, after the  
               ftp and tape files were built.  TYPESTAT was validated,  
               but I didn't use TYPSTMNT to test its sort macro. Member 
               EXTMNSTS was added and VMXGINIT updated for TYPESTAT and 
               the sort has been tested in this final iteration.        
              -Variables SMF9029N,SMF9029A,SMF9030I in archaic VMAC90   
               were renamed A, N, and Y, only in case someone foolishly 
               uses both VMAC90 and VMAC90A in same step.  Use VMAC90A. 
   Thanks to George Canning, Abbey National Plc, ENGLAND.               
   Thanks to Vernon Kelley, IBM, USA.                                   
LASTCHANGE: Version 22.