MXG Version 29.29 is  dated Jan 23, 2012, thru Change 29.307.   
Second  MXG Version 29.29 is  dated Jan 18, 2012, thru Change 29.301.   
First   MXG Version 29.29 was dated Jan 17, 2012, thru Change 29.298.   
        MXG Version 29.09 was dated Jan  4, 2012, thru Change 29.291.   
        MXG Version 29.08 was dated Dec 20, 2011, thru Change 29.284.   
        MXG Version 29.07 was dated Nov 24, 2011, thru Change 29.262.   
Second  MXG Version 29.07 was dated Nov 21, 2011, thru Change 29.259.   
First   MXG Version 29.07 was dated Nov 14, 2011, thru Change 29.253.   
        MXG Version 29.06 was dated Sep  8, 2011, thru Change 29.204.   
First   MXG Version 29.06 was dated Sep  1, 2011, thru Change 29.198.   
        MXG Version 29.05 was dated Jul 11, 2011, thru Change 29.151.   
        MXG Version 29.04 was dated May 17, 2011, thru Change 29.116.   
Final   MXG Version 29.03 was dated Apr 19, 2011, thru Change 29.094.   
First   MXG Version 29.03 was dated Apr 11, 2011, thru Change 29.086.   
Early   MXG Version 29.03 was dated Apr  4, 2011, thru Change 29.077.   
        MXG Version 29.02 was dated Mar  1, 2011, thru Change 29.050.   
        MXG Version 29.01 was dated Feb  4, 2011, thru Change 29.022.   
First   MXG Version 29.01 was dated Feb  3, 2011, thru Change 29.020.   
Annual  MXG Version 28.28 was dated Jan 18, 2011, thru Change 28.331.   
        MXG Newsletter FIFTY-SEVEN is dated Jan 18, 2011.               
Instructions for ftp download can be requested by using this form:                          
Your download instructions will be sent via return email.               
Contents of member CHANGES:                                             
I.    Current MXG Software Version 29.29 is available upon request.     
II.   SAS Version requirement information.                              
III.  WPS Version requirement information.                              
IV.   MXG Version Required for Hardware, Operating System Release, etc. 
V.    Incompatibilities and Installation of MXG 29.29.                  
VI.   Online Documentation of MXG Software.                             
VII.  Changes Log                                                       
  Member NEWSLTRS contains Technical Notes, especially APARs of interest
  and is updated with new notes frequently.  All Newsletters are online 
  at in the "Newsletters" frame.                     
  Member CHANGES contains the changes made in the current MXG version.  
  Member CHANGESS contains all changes that have ever been made to MXG. 
  All MXG changes are also online at, in "Changes".  
I.  MXG Version 29.29 dated Jan 23, 2012, thru Change 29.307.           
    Major enhancements added in MXG 29.29, dated Jan 23, 2012           
  TYPEIMS  29.307  Support for IMS Version 12: Adds ZIIP/ZAAP CPU times.
  RMFINTRV 29.305  INTERVAL=SHIFT generated warnings & incorrect output.
  TYPETMS5 29.304  USER ABEND 1234 can be bypassed for TMSCLEAN input.  
  IMACICRD 29.302  Comment within comment block if default used.        
    Major enhancements added in MXG 29.29, dated Jan 18, 2012           
  TYPENDM  29.301  Old Version 4.7 "PS" record INPUT STATEMENT EXCEEDED.
  TYPERMFV 29.300  Wrong ASMRMFV in first 29.29, VMACRMFV updated.      
    Major enhancements added in MXG 29.29, dated Jan 17, 2012           
  VMACSMF  29.290  USER ABEND 69 due to invalid SMFTIME now bypassed.   
  TYPENDM  29.295  NDM/Connect-Direct V5.0 added jobname/jctjobid.      
  TYPEXAM  29.294  Support for VNDNIC, LPARNW, USVCPU segments.         
  TYPE110  29.293  Support for CICS Statistics STID=143 and 144.        
  ASMDBLKU 29.289  ASMDBLKU, ASM version of UDEBLOCK, revised.          
  ASMRMFV  29.297  Continued RMF III enhancements.                      
  TYPERMFV 29.297  Continued RMF III enhancements.                      
  TYPEDCOL 29.296  DCOLLECT support updated to execute on ASCII.        
  BLDSMPDB 29.292  Support for execution under unix.                    
  VMXGALOC 29.292  Support for execution under unix.                    
  VMXGPPDS 29.298  Compare contents of multiple PDS/PDSE libraries.     
    Major enhancements added in MXG 29.08, dated Dec 22, 2011           
  ANALGRID 29.284  Color-intense grid of "hot spots" of any variable.   
                   (Examples, ANALGRID.)   
  ASUM4HRS 29.268  %MACRO calculates "Four Hour" running average values 
                   (or running average for any number of hours).        
                   ("Task Time" is recommended by IBM for analysis).    
  ASMTAPEE 29.280  "YOU SPECIFIED ASCENV" Assembly error with z/OS 1.13.
                   (MXGTMNT does NOT need to be reassembled on 1.13)    
  TYPE16   29.264  Support for DFSORT z/OS 1.13 COMPAT new variables.   
  TYPESVIE 29.273  Support for SYSVIEW subtypes 34 and 35.              
  TYPETLMS 29.269  Support for CA TLMS tape library 2003 record changes.
  TYPETMS5 29.274  CA-1 TMS Extended Format TMC records have no impact. 
  TYPE120  29.272  SM1209CI and SM1209CX can be negative.               
  MXGSASxx 29.265  MXGTEMP temporary DDNAME/FILENAME added to MXG JCL.  
    Major enhancements added in MXG 29.07, dated Nov 24, 2011           
  TYPEIMST 29.230  Further updates to IMS56FA transaction processing.   
  SMFSRCH  29.236  SMFSRCH, search SMF records for text, print all obs. 
  TYPE7072 29.220  Support for z/OS 1.13 (WAS IN MXG 29.03 or later).   
  TYPETMO2 29.244  Support for TMON/CICS V3.3 (mostly COMPATIBLE) TCE.  
  TYPEQACS 29.208  Support for IBM i-series (AS400), more than 32 CPUs. 
  TYPEDB2  29.213  Support for DB2 V10 IFCID 225 Subtype4 INCOMPATIBLE. 
  TYPETPMX 29.211  Support for Throughput Manager APAR TMT6214, st=16.  
  TYPEBETA 29.233  Support for BETA93 Version 4.1.0 subtype 25 changes. 
  TYPEAXWY 29.231  Support for Axway CFT/ESA (Cross File Transfer) SMF. 
  TYPEPOC  29.219  Support for Tivoli Workload Schedulr Ver 8.3 INCOMPAT
  TYPEFERT 29.247  Support for ZEN FERRET V2.3 (INCOMPATIBLE).          
  TYPEMPLX 29.247  Support for ZEN IMPLEX V5.1 (COMPATIBLE)             
  TYPEZOSA 29.247  Support for new ZEN OSA MONITOR V1.3 SMF records.    
  TYPEITRV 29.223  Support for APAR OA37114, ITRF (OMEGAMON IMS V420)   
  TYPE70x  29.239  Variable SHIFT (used as "ZONE") added to all RMF.    
  TYPEDB2  29.209  DB2 V10 ID=100 ST=1 INVALID HEADER.                  
  TYPEVMXA 29.207  z/VM MONWRITE Broken Control Rec if 2.14 (SCALL) rec.
  TYPE102  29.235  IFCID=22 in Change 28.234 wrong in DB2 V9.           
  TYPSXAM  29.249  TYPSXAM didn't sort all XMdddddd datasets to the PDB.
  ASUM113  29.243  Calculation of ESTSCP1M incorrectly had small values.
  ASMRMFV  29.217  Enhanced RMF III RCDSD section support, CHAR->NUM fix
  TYPE120  29.240  Length of Character Variable SMF1209FH can't change. 
  TYPEaaaa 29.238  All USER SMF have MACRO _IDaaaa nnn as SMF record id.
  TYPE16   29.232  DFSORT variables ICEMNVLX, ICEMNVLY, ICEMNVLZ wrong? 
  TYPETPMX 29.229  TPMCA7JN, TPMPI, and TPMDUEOT may be wrong.          
  TYPE1415 29.226  False ERROR.TYPE1415.DEFECTIVE.EXTENDED... log msg.  
  TYPEDB2  29.225  INVALID DB2 V10 QMDA segment for QMDAPTYP='JCC'.     
  TYPE80A  29.223  New TOKENIDs starting with NOxxxx (NOCPUTIMEMAX, etc)
  TYPE110  29.221  CICS Statistics datasets CICDB2GL,CICSMDSA, corrected
  TYPE119  29.215  Variables T119STCK/TISSTCK/TIESTCH were still GMT.   
  TYPE78PA 29.214  Values in TYPE78PA ending with TOTL could be wrong.  
  TYPE845  29.212  Invalid JES3 JMF SMF 84 Subtype 1 Segmented Records. 
    Major enhancements added in MXG 29.06, dated Sep  8, 2011           
  SAS V9.3 29.159  Support for SAS Version 9.3 - SAS Hot Fix E80004:    
    SAS V9.3 Hot Fix E80004 (for SAS Problem Note SN43828) is REQUIRED  
    to correct an error in the %MACRO compiler, which is SAS portable   
    code, so the Hot Fix is required for ALL platforms for SAS V9.3.    
      The %MACRO compiler error is in processing %LET statements.       
      While only two MXG members actually failed in MXG QA tests, ANY   
      use of %LETs can fail in MXG (or in your own %MACRO code).        
  MANY     29.169  MXG ODS HTML ASCII examples failed if no PATH=.      
    Seen first with SAS V9.3; complete revision of MXG ODS HTML examples
    with new %macros with consistent arguments, etc, for all platforms. 
  TYPEVMXA 29.172  Support for APAR VM64961, SMF 113 in z/VM MONWRITE!! 
  TYPE113  29.176  Support for APAR OA36816, SMF 113 HIS DATALOSS parm. 
    IBM now recommends SMF 113 always be created.                       
  TYPEIMST 29.162  Validation of TYPEIMST, many changes for IMS56FA.    
    Finally: IMS Transaction CPU/Response from ONE IBM IMS LOG RECORD.  
  TYPEADAB 29.189  Support for Software AG's ADABAS SMF user record.    
  TYPECFS  29.186  Support for InfoSphere Classic Federation Server SMF.
  TYPE23   29.177  Support for APAR OA35175, logstream stats in SMF 23. 
  TYPE30   29.175  Support for APAR OA35617, SMF30CRM VELOCITY MNGED?   
  TYPE30   29.174  Support for APAR OA34895, EXCP/IOTM Missed, SMF Lock.
  TYPE57   29.173  Support for APAR OA36966, JES3 expanded NJEJOBNO.    
  TYPEIDMS 29.156  Support for IDMS/R Performance Monitor Version 18.   
  TYPEVMXA 29.163  z/VM Crypto Record (5,10) with PRCAPMCT=6 error.     
  TYPE115  29.161  MXG 29.03-MXG 29.05 dataset MQMCFMGR was wrong.      
  TYPEDM   29.158  NDM-CDI Version 5 new fields supported.              
  TYPE110  29.155  CICS/TS 4.2  Statistics variables overlooked, added. 
  VMXGSUM  29.154  AUTOCALL %macro's %CMPRES/%QCMPRES removed.          
  TYPE111  29.153  UNDECODED CTGRECID message, possible CPU loop.       
  TYPE7072 29.152  VMSYSTEM='Y' RMF records validated, and revised.     
  RMFINTRV 29.194  Stats on Page Dataset Slot Usage added to RMFINTRV.  
  ASUM113  29.193  zVM MONWRITE VXPRCMFC (SMF 113 for z/VM) included.   
  ASUMUOW  29.188  Case 4 example prevents blank TRANNAME in ASUMUOW.   
  ASMRMFV  29.187  Do not use ASMRMFV in MXG29.05, fails with 0C4 ABEND.
  GRAFWRKX 29.185  Workload RMFINTRV graph's update uses new workloads. 
    Major enhancements added in MXG 29.05, dated Jul 11, 2011           
  TYPE110  29.135  Support for CICS/TS 4.2. CICSTRAN supported in 29.03.
  TYPE110  29.149  Support for CICS/TS 4.2. MNSEGCL=5 requires  29.05.  
  TYPE120  29.136  Support for WebSphere WAS 8.0 (COMPATIBLE).          
  TYPE70   29.127  Support for z/OS 1.12 VMGUEST option, CPU Time in 70.
  TYPEIMST 29.144  IMS Transactions in IMS56FA, replaces JCLIMSL6!!!    
  TYPETIMS 29.123  Support for TMON/IMS Version 3.0 (INCOMPATIBLE).     
  TYPEPOEX 29.134  Support for Informatica's POWER EXCHANGE SMF record. 
  TYPEDB2  29.140  New LUUVTIME instead of QWACBSC for start time.      
  TYPE90A  29.142  Enclave variables decoded in TYPE9030 dataset.       
  UTILARCH 29.137  New UTILARCH archives data (like Outlook archive).   
  TYPEDB2  29.131  DB2PARTY added to DB2ACCTP, Rollup impact documented.
  TYPEDB2  29.128  DB2 INVALID DISTRIUTED HEADER message corrected.     
  TYPEDB2  29.121  QWHADSGN/QWHAHAMN were sometimes blank.              
  TYPE102  29.125  DB2 SMF 102 IFCID 22 INPUT STATEMENT EXCEEDED error. 
  TYPEXAM  29.126  XAM variables in VXSYTEP2 were not all input/kept.   
  TYPE111  29.124  Variables CTGIAREQ/CTGLALRQ revised keeps.           
  ANALDB2R 29.145  Performance and Reporting Enhancements               
    Major enhancements added in MXG 29.04, dated May 17, 2011           
  TYPE105  29.100  Support for GDPS Global Mirror V3R8 SMF 105 record.  
  DB2ACCT  29.111  DB2 CICS TRAN name could be wrong, now from QWHCCV.  
  TYPEIMSA 29.110  the exit _IMSTRN invocation was accidentally removed.
  BUIL3005 29.106  JES3 PDB.JOBS variable JOBCLAS8 has after change.    
  VMXGSRCH 29.103  RESULTS=FINDVAR finds all datasets with a variable.  
  TYPE70PR 29.098  Counts ICFCPUS/IFLCPUS/IFACPUS/ZIPCPUS too high.     
  TYPE110  29.097  INPUT EXCEEDED 110-2 MNSEGLC=5 with DPL segment      
    Major enhancements added in MXG 29.03, dated Apr 19, 2011           
  TYPE110  29.094  1st MXG 29.03 ONLY. CICSTRAN CPUTM plus fields WRONG.
  TYPE116  29.057  Support for Websphere for z/OS MQ Version 7.0.1.     
  TYPE115  29.057  Support for Websphere for z/OS MQ Version 7.0.1.     
  TYPEBBMQ 29.056  Support for MainView MQ (MVMQ) Version 4.4.          
  TYPEQACS 29.078  Support for OS/400, AS/400 Version 7.1 (INCOMPATIBLE)
  TYPE110  29.076  CICS CPUTM exceeds ELAPSTM, zAAP/zIIP Equivalent time
  TYPE120  29.081  Support for User Field in SMF 120 Subtype 9 record.  
  TYPETPMX 29.071  Support for Throughput Manager subtype 10 and 16.    
  TYPENTSM 29.075  Support for 62 new objects and 1425 new NT metrics.  
  UTILVREF 29.075  MXG now creates DATASET names up to 32 characters.   
  BUILDPDB 29.068  MXG 28.28-29.02. ABEND=JCL obs missing in PDB.JOBS.  
  TYPERACF 29.067  RACF UNLOAD dataset RACF0270 UID limit variables.    
  TYPEBETA 29.059  Support for Beta 93 Version 4.2 subtypes 25/50.      
  TYPE30   29.058  Variable CPUCEPTM always now set to a missing value. 
  MONTHxxx 29.052  SAS 9.1.3 Only.  %QCMPRES needed versus %CMPRES.     
  TYPE85   29.093  INPUT STATEMENT EXCEEDED st 79, z/OS 1.12.           
  ASUM70PR 29.092  ZIPCPUS/IFACPUS included parked time.                
  TYPEVMXA 29.092  z/VM new PDB.VXINTUSR sums all engines for each VM.  
    Major enhancements added in MXG 29.02, dated Mar  1, 2011           
                   (Unfortunately, EVEN with the newest MXG 29.01).     
               The MXG2828 or MXG2901 ftp credentials are still valid;  
               you can download 29.02 and copy the two members you need 
               (VSETMNTH, and BUILDxxx or BLDSMPDB), or you can ftp     
               only those specific files to correct the error, for this 
               month and for future months, or you can install 29.02.   
               Without these updated members/29.02, future MONTHly's can
               also be missing one or more day's PDBs in your MONTH PDB.
               The complete details are in Change 28.041, below.        
  TYPENDM  29.042  Support for NDM-CDI Version 5 records (COMPATIBLE).  
  VMACDB2H 29.037  DB2 V9.1 false "INVALID DISTRIBUTED HEADER" message. 
  TYPE30   29.034  Invalid data for SMF30RGT is true, circumvented.     
  TYPECIMS 29.033  Support for IMF Version 4.5 is in place.             
  TYPE0    29.032  PDB.IPLS, now, DOES always report a SYSTEM IPL.      
  TYPEDB2  29.031  DB2 V9.2 only, most QBGxxx variables DB2GBPST wrong. 
  TYPEVMXA 29.026  Support for zVM APAR VM64794 (COMPATIBLE).           
  TYPE30   29.025  Small negative CPUUNITS now set to zero.             
  TYPE26J2 29.024  Cosmetic: INREASON NOT DECODED messages corrected.   
    Major enhancements added in MXG 29.01, dated Feb  4, 2011           
                   These two impacted MONTHLY build:                    
  MONTHBLD 29.017  SERIOUS ERROR CORRECTED: last day's PDB skipped.     
  BLDSMPDB 29.017  LIBNAME WEEK1 not found corrected.                   
                   These two eliminate possibility of NOTSORTED errors: 
  BLDSMPDB 29.008  SORTEDBY=NO default to eliminate NOTSORTED exposure. 
  WEEKBLD  29.008  MXGNOBY default to eliminate NOTSORTED exposure.     
  MONTHBLD 29.008  MXGNOBY default to eliminate NOTSORTED exposure.     
  TYPEENDV 29.012  Support for Endeavor Version 14 (INCOMPATIBLE).      
  TYPE111  29.001  Support for IPIC creates obs in TY111CXI.            
  TYPE115  29.015  Support for MQ Version 7 compression statistics.     
  TYPE89   29.002  Support for APAR OA31615, zIIP/zAAP times added,     
                   and false error messages are eliminated.             
    Please read CHANGESS for the complete list of major enhancements.   
  See member NEWSLTRS or the Newsletters frame at for
  current MXG Technical Notes.                                          
  All of these enhancements are described in the Change Log, below.     
II.   SAS Version requirement information:                              
      MXG 26.03 thru MXG 29.09 will execute under SAS Version 9.3, on   
      all supported platforms, but SAS V9.3 Hot Fix E80004 is REQUIRED  
      (for SAS Problem Note SN43828) to correct an error in the %MACRO  
      compiler, which is SAS portable code, so the Hot Fix is required  
      for ALL platforms for SAS V9.3.                                   
       The %MACRO compiler error is in processing %LET statements. While
       only two MXG members failed repeatedly in MXG QA tests on z/OS,  
       there were random %LET errors in ASCII QA tests, so ANY use of   
       %LET statement on ANY platform are vulnerable to this error, as  
       the %MACRO compiler is SAS portable code, used on all platforms. 
      With Hot Fix E80004, the full MXG QA test stream executed with no 
      errors, and there were no new warnings on z/OS.  Users of ODS will
      want MXG 29.06, because SAS V9.3 did expose incompatibilities in  
      MXG code for ODS reporting, now corrected in MXG Version 29.06.   
      See Changes 29.159 and 29.169.                                    
        To find the Hot Fix for all platforms, open, 
        and then search SAS Notes for 43828 (NOT SN-43828, NOT E80004), 
        and then Pull Down the Hot Fix tab.                             
      MXG 26.03 thru MXG 29.29 will execute under SAS V9.2, or with     
      SAS V9.1.3 with Service Pack 4, on all supported SAS platform.    
        SAS Hot Fix for SAS Note 37166 is required to use a VIEW with   
        the MXG EXITCICS/CICSFIUE CICS/DB2 Decompression Infile Exit.   
        SAS V9.1.3 is NOT supported by SAS on Windows SEVEN platform.   
      And, only for z/OS 1.10 with SAS V9.1.3 with ANY version of MXG,  
      the SAS Hot Fix for SN-35332 is REQUIRED (to be completely safe). 
        Without this Hot Fix, "LIBREF XXXXXXXX IS NOT ASSIGNED" errors  
        can occur even though //XXXXXXXX DD is a valid SAS Data Library.
        This error ONLY occurs with z/OS 1.10 and SAS V9.1.3; it does   
        NOT occur with SAS V9.2, nor with z/OS 1.9.  It can be          
        circumvented by adding a LIBNAME statement that specifies the   
        ENGINE name. See the Technical Note in Newsletters for SN-35332.
      Old MXG code may continue to execute with SAS V8.2, but V8 is now 
      "Level B" support from SAS Institute, and there are known errors  
      in V8.2 that are only fixed in SAS V9.  I no longer QA with V8.2; 
      While many MXG programs (accidentally) will still execute under   
      V8.2, I can not guarantee that all of MXG executes error free.    
      MXG Software has not executed under SAS V6 in many years.         
      The "PDB" libraries (i.e., SAS data libraries) must be created by 
      SAS V8 or later, but any of those data libraries can be read or   
      updated by the SAS Versions that MXG Supports, above.             
      For SAS Version V9.3:                                             
        SAS Hot Fix SN43828 is required; see text of Change 29.159.     
        With that hot Fix, MXG Versions 26.03 or later should execute   
        under SAS V9.3 on all platforms without error.                  
        SAS Data Libraries created by SAS V8.2, V9.1.3, V9.2 and V9.3   
        are interchangeable and can be read/written by any of those     
        versions, provided they are on the same platform.  (On ASCII,   
        the 32-bit and 64-bit SAS versions are NOT the same "platform".)
        SAS V9.3 did change ODS processing defaults and syntax that     
        might cause errors with MXG 29.05 or earlier; MXG 29.06,        
        Change 29.160 documents the major revisions made in MXG to fully
        support V9.3 ODS, and MXG 29.06 is STRONGLY recommended for ODS 
        with SAS V9.3.                                                  
      For SAS Version V9.2 (TS1M0):                                     
        Big Picture: SAS Version V9.2 is COMPATIBLE with MXG Software.  
        On z/OS, SAS changed the DSNAMES for some of the SAS libraries, 
        so you do need to use the new MXGSAS92 JCL Procedure for MXG,   
        but it still uses the CONFIGV9 configuration file.              
        However, NEW, and documented in Change 27.356, with SAS V9.2:   
          The standard SAS JCL Procedure can be used for MXG:           
             // EXEC SAS,CONFIG='MXG.SOURCLIB(CONFIMXG)'                
          instead of using the MXGSAS92 JCL Procedure example.          
        SAS Data Libraries are compatible for V8.2, V9.1.3, and V9.2.   
        V9.2-created "PDBs" can be read/written by SAS V8.2 or V9.1.3,  
        and vice versa.                                                 
        MXG Versions 26.03+ execute with SAS V9.2 with NO (new) WARNINGS
        and with NO ERRORS reported.                                    
          Pre-MXG 26.03, SAS Hot Fix F9BA07 was required to suppress a  
          new SAS V9.2 WARNING, that on z/OS, set CC=4 (condition/return
          code). That warning is harmless (to MXG code) and all MXG     
          created SAS datasets were correct, even with that warning.    
          The ONLY exposure was ONLY on z/OS, and ONLY if condition code
          tests are used in your MXG jobstreams.                        
        SAS Version 9.2 requires z/OS 1.7 or later, both officially as  
        documented by SAS Institute, and actually as V9.2 fails with 0C4
        under z/OS 1.4.                                                 
      For SAS V9.1.3 on z/OS with Service Pack 4:                       
        On z/OS 1.10, Hot Fix SN-35332 is REQUIRED.                     
        CONFIGV9 now specifies V9SEQ instead of V6SEQ.  As V6SEQ does   
        not support long length character variables, it can't be used.  
       SAS V9.1.3 with current Service Pack 4 is STRONGLY RECOMMENDED.  
       For (back-level!) 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 tape engines V7SEQ, V8SEQ, or V9SEQ.            
        Both fixes ARE included in SAS V9.1.3, but V9.1 or 9.1.2 is NOT 
          SAFE without those two hot fixes, and if you do NOT have those
          two fixes on 9.1 or 9.1.2, you MUST set V6SEQ in CONFIGV9.    
        With MXG 23.02 or later, V9SEQ is the default sequential engine 
        specified in CONFIGV9, but if you are back at SAS V9.1 or V9.1.2
        you MUST install the two hot fixes listed above.                
       For SAS Version 8.2, HotFix Bundle 82BX08 (or later) was required
         as an absolute minimum level when that SAS Version was last    
         supported by MXG Software.  PLEASE INSTALL SAS V9.x ASAP.      
       Sequential Engine Status:                                        
          V9SEQ was fixed in V9.1.3; it has been default in CONFIGV9.   
          V8SEQ was always safe under SAS V8.2, but it wasted CPU time  
            by always compressing when writing in tape format.          
          V6SEQ, if used under V9.1.2, requires SN-013514, but V6SEQ    
                 should no longer be used, as it does not support long  
                 length variables.                                      
      MXG QA tests are executed on z/OS with SAS V9.1.3 and V9.2 and    
      on Windows XP with 32-bit INTEL, and on Windows Seven Ultimate    
      32-bit and 64-bit OS on 64-bit hardware, but MXG is installed     
      on many more hardware and software platforms: since they all work,
      we don't need to list them.  If SAS executes so does MXG.         
      Prior QA tests have been run with all SAS releases available at   
      that time on Linux RH8 on Intel, on Solaris v2.8 on a Model V880, 
      and on HP-UX v11.11 model rp5470, confirming full compatibility.  
      MXG should execute under SAS V9.1.3 or V9.2 on every possible SAS 
      platform without errors! Each new MXG version is also tested with 
      the SAS ITSV/ITRM product by the ITRM developers.                 
III.  WPS Version requirement information:                              
      WPS Version 2.4   requires MXG 27.09 (see Change 27.239).         
      WPS Version 2.3.5 required MXG 27.05.                             
      See NEWSLETTERS for "MXG Support for WPS Software"                
IV.   MXG Version Required for Hardware, Operating System Release, etc. 
    Availability dates for the IBM products and MXG version required for
    error-free processing of that product's data records:               
                                       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       *24.10        
      z/OS IRD TYPE70PR                Mar 11, 2004       *24.10        
      z/OS IRD TYPE70,RMFINTRV         Mar 22, 2002       *24.10        
      z/OS 1.6 - No IFAs               Sep 30, 2004       *22.09        
      z/OS 1.6 - With IFAs             Sep 30, 2004       *22.11        
      z/OS 1.7 (COMPATIBLE CHANGES)    Sep 30, 2005       *24.10        
      z/OS 1.7 (SPLIT70 CORRECTION)    Sep 30, 2005       *24.10        
      z/OS IFA data in RMF 79s         Sep 30, 2005        23.10        
      z/OS 1.8 - ASMTAPEE assembly     Sep 30, 2005       *25.03        
      z/OS 1.8 - SMF 119 INCOMPAT      Sep 30, 2005       *25.06        
      z/OS More than 32 LPARs          Jan 30, 2006       *24.24        
      z/OS SPLIT RMF 70 records        Jan 30, 2006       *24.24        
      z/OS Dupe SYSTEMs in a SYSPLEX   Jan 30, 2006       *24.02        
      z/OS IRD errors corrected        May 15, 2006        24.03        
      z/OS ASUMCEC errors corrected    May 15, 2006       *24.24        
      z/OS ASUM70LP errors corrected   Jun 13, 2006       *24.24        
      z/OS zIIP Processor Support      Jun 22, 2006       *24.24        
      z/OS Dedicated zIIP Support      Mar  8, 2008       *26.01        
      z/OS Dedicated zAAP Support      Mar  8, 2008        26.01        
      z/OS 1.8 (COMPATIBLE CHANGES)    Sep 20, 2006       *24.24        
      z/OS 1.9 (INCOMPAT, 54 CPs)      Sep 27, 2007        25.10        
      z/OS 1.9 MXGTMNT at ML-39 reASM  Sep 27, 2007        25.10        
      z/OS new z10 variables           Mar  5, 2008        26.01        
      z/OS 1.8 With HiperDispatch      Sep 15, 2008       *26.10        
      z/OS 1.9 With HiperDispatch      Sep 15, 2008       *26.10        
      z/OS 1.10 (INCOMPAT, MXG code)   Sep 15, 2008        26.07        
      z/OS 1.10 With HiperDispatch     Sep 15, 2008       *26.10        
      z/OS 1.10 RMF III, SMF 119       Jul 20, 2009        27.05        
      z/OS 1.11                        Sep  2, 2009        27.08        
      z/OS 1.11 New 30 variables       Apr 14, 2010       *28.02        
      z/OS 1.12                        Aug 17, 2010       *28.05        
      z/OS 1.12 SMF 85 Subtype 79      Aug 17, 2010       *29.03        
      z/OS 1.12 VMGUEST option         Aug 17, 2010       *29.06        
      z/OS 1.13                        Sep 30, 2010        29.03        
      z/OS 1.13 - MXGTMNT only         Dec 15, 2010        29.08        
      z990 CPUs - CPUTYPE '2084'x      Aug 25, 2003        21.04        
      z890 CPUs - CPUTYPE '2086'x      Jun 24, 2004        22.07        
      z9   CPUs - CPUTYPE '2094'x      Jul 20, 2005       *24.24        
      z9EC CPUs - CPUTYPE '2094'x:                                      
             with 64-bit z/OS - no change required        *24.24        
             with 32-bit z/OS only:    Aug 26, 2006        24.06        
      z9BC CPUs - CPUTYPE '2096'x:                                      
             with 64-bit z/OS - no change required         24.01        
             with 32-bit z/OS only:    Jul 27, 2006       *24.24        
      z10  CPUs - CPUTYPE '2097'x      Dec  7, 2008        25.11        
      z10  HiperDispatch/Parked Time   Mar  3, 2008       *26.10        
      z196 (INCOMPAT IF GT 64 ENG)     Aug 17, 2010        28.05        
      CICS/ESA 3.2                     Jun 28, 1991         9.9         
      CICS/ESA 3.3                     Mar 28, 1992        10.01        
      CICS/ESA 4.1                     Oct 27, 1994        13.09        
      CICS/ESA 5.1 aka CICS/TS V1R1    Sep 10, 1996        14.07        
      CICS-Transaction Server V1R1     Sep 10, 1996        14.07        
      CICS-TS V1R1 with APAR UN98309   Sep 15, 1997        15.06        
      CICS-TS V1R2  CICS/TS 1.2        Oct 27, 1997        15.06        
      CICS-TS V1R3  CICS/TS 1.3        Mar 15, 1999        17.04        
      CICS-TS V2R2  CICS/TS 2.2        Feb  9, 2002        19.19        
      CICS-TS V2R3  CICS/TS 2.3        Aug 13, 2004        22.04        
      CICS-TS V3R1  CICS/TS 3.1        Jan 18, 2005        22.22        
      CICS-TS V3R2  CICS/TS 3.2        Dec  6, 2007        25.11        
      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        
      CICS-TS for Z/OS Version 3.2     Jun 29, 2007        25.03        
      CICS-TS/3.2 Compressed Records   Nov  3, 2007        25.11        
      CICS-TS/4.1 (CICSTRAN INCOMPAT)  Mar 13, 2009        27.01        
      CICS-TS/4.1 (STATISTICS ST=2)    Sep 18, 2009        27.08        
      CICS-TS/4.2 CICSTRAN/STATISTICS  Jun 24, 2011        29.03        
      CICS-TS/4.2 CICSRDS MNSEGCL=5    Jun 24, 2011        29.05        
      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, no packages    Mar 31, 2004        20.20        
      DB2 8.1 New Data Packages wrong  Mar 31, 2004        21.08        
      DB2 8.1 Support with Packages    Mar 31, 2004        23.09*       
      DB2 8.1 with all zIIP Variables  Sep 30, 2006        24.08        
      DB2 8.1 +PK47659                 Sep 12, 2008        26.08        
      DB2 9.1 See Change 25.265.       Dec  7, 2007        25.11        
      DB2 9.1 Full Support +PK/56356   Sep 12, 2008        26.08        
      DB2 10.1 Tolerate                Oct  1, 2010        28.06        
      DB2 10.1 Full plus Compressed.   Nov  1, 2010        28.07*       
      DB2 10.1 Invalid Header pre APAR Jan 12, 2011        28.28*       
      DB2 10.1 IFCID=225 INCOMPAT      Sep 23, 2011        29.07*       
      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        
      DFSORT SMF V1R5                  Mar  1, 2006        24.02        
      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        
      MQ Series 6.0                    Feb 14, 2006        23.23        
      Webshpere MQ Series 7.0          ??? ??, 2009       *28.06        
      Websphere MQ Series 7.1          MAR 12, 2011        29.03        
      Websphere MQ Series 8.0          Jun 24, 2011        29.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        
      WebSphere 6.0                    Feb 18, 2006        23.23        
      WebSphere 7.0                    Oct  7, 2010        28.06        
      WebSphere 8.0                    Jul 17, 2011        29.05        
      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        
      z/VM    5.2                      Jan 22, 2006        24.01        
      z/VM    5.3 TOLERATE             Jun  7, 2007        25.05        
      z/VM    5.3 NEW VARIABLES        Sep 12, 2008        26.08        
      z/VM    5.4 (COMPATIBLE)         Sep 12, 2008        27.01*       
      z/VM    6.1 (NO CHANGES)         Jul  7, 2008        27.01        
      z/VM    6.2                      Dec  2, 2011        29.04        
      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        
      IMS log 9.1                      Mar 96, 2004        26.01*       
      IMS log 10.0                     Mar 06, 2007        26.01*       
      IMS log 11.0                     Apr  1, 2010        28.02*       
      IMS log 12.0                     Jan 23, 2012        29.29*       
      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        
      AS400 5.4.0                      Aug 26, 2006        24.06        
      AS400 6.1.0                      Jun 29, 2008        26.05        
    Note: Asterisk by 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        
       NTSMF 3.1.4                     Mar 15, 2009        27.01        
       NTSMF 4.0                       Mar 15, 2011        29.03        
       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 DB2 Version 4.0                     22.10        
       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 TCE 2.1 -                      20.04        
       The Monitor for CICS TCE 2.2 - 20.335, 21.134       21.04        
       The Monitor for CICS TCE 2.3 including CICS/TS 3.1  22.08        
       The Monitor for CICS TCE 3.2 (almost all)           25.11        
       The Monitor for CICS TCE 3.2 (almost all)           27.01        
       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        
       The Monitor for CICS/TS V2.3 for CICS/TS 3.1        22.08        
       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 IMS V550/V560 (ITRF)                   25.05        
       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 
       SAR/VIEW R11                                        23.07 23.196 
      BMC, was 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        
       IMF 3.3 (for IMS 7.1 and 8.1)                       22.08*       
       IMF 4.1 (for IMS 9.1)                               26.02*       
       IMF 4.4 (for IMS 9.1)                               27.07*       
       IMF 4.5 (for IMS 11.1)  (No change since 4.4)       27.07        
       LMS 3.1                                             12.12A       
      Oracle V9, V10                                       24.06        
       APAF 4.1, 4.3                                       16.08        
      Velocity Software                                                 
       XAMAP 3.4                                           22.10        
       XAMAP 3406                                          24.03        
       XAMAP 3.7                                           27.10        
       XAMAP 4.1                                           29.07        
V.    Incompatibilities and Installation of MXG 29.29.                  
 1. Incompatibilities introduced in MXG 29.29:                          
  a- Changes in MXG architecture made between 29.29 and prior versions  
     that can introduce known 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 JCLINSTT for 
    SAS Version 9.                                                      
    MXG Definitions with regard to MXG Software Changes:                
    COMPATIBLE   A change in a data record which did not alter either   
    COMPAT       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.    
    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.                               
    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.     
VI.   Online Documentation of MXG Software.                             
    MXG Documentation is now described in member DOCUMENT.              
    See also member INDEX, but it may be overwhelming.                  
VII.  Changes Log                                                       
--------------------------Changes Log---------------------------------  
 You MUST read each Change description to determine if a Change will    
 impact your site.  All changes have been made in this MXG Library.     
 Member CHANGES always identifies the actual version and release of     
 MXG Software that is contained in that library.                        
 The CHANGES selection on our homepage at            
 is always the most current information on MXG Software status,         
 and is frequently updated.                                             
 Important changes are also posted to the MXG-L ListServer, which is    
 also described by a selection on the homepage.  Please subscribe.      
 The actual code implementation of some changes in MXG SOURCLIB may be  
 different than described in the change text (which might have printed  
 only the critical part of the correction that need be made by users).  
 Scan each source member named in any impacting change for any comments 
 at the beginning of the member for additional documentation, since the 
 documentation of new datasets, variables, validation status, and notes,
 are often found in comments in the source members.                     
Alphabetical list of important changes in MXG 29.29 after MXG 28.28:    
  Member   Change    Description                                        
  Many     29.169  MXG ODS HTML ASCII examples failed if no PATH=.      
  ANALDB2R 29.145  Performance and Reporting Enhancements               
  ASMDBLKU 29.289  ASMDBLKU, ASM version of UDEBLOCK, revised.          
  ASMRMFV  29.187  Do not use ASMRMFV in MXG29.05, fails with 0C4 ABEND.
  ASMRMFV  29.217  Enhanced RMF III RCDSD section support.              
  ASMTAPEE 29.280  "YOU SPECIFIED ASCENV" Assembly error with z/OS 1.13.
  ASUM113  29.193  zVM MONWRITE VXPRCMFC (SMF 113 for z/VM) included.   
  ASUM113  29.243  Calculation of ESTSCP1M incorrectly had small values.
  ASUM4HRS 29.268  %MACRO calculates "Four Hour" running average values 
  ASUM70PR 29.092  ZIPCPUS/IFACPUS included parked time.                
  ASUMMIPS 29.237  Calculation of ZIPUSED and ZIEUSED incorrect.        
  ASUMUOW  29.007  Doc: variables required for ASUMUOW/ASUMCICX.        
  ASUMUOW  29.009  ASUMUOW fails is //CICSTRN,//DB2ACCT on tape.        
  ASUMUOW  29.188  Case 4 example prevents blank TRANNAME in ASUMUOW.   
  BLDSMPDB 29.008  SORTEDBY=NO default to eliminate NOTSORTED exposure. 
  BLDSMPDB 29.017  LIBNAME WEEK1 not found corrected.                   
  BLDSMPDB 29.246  A dash in filename text tripped up %UPCASE().        
  BLDSMPDB 29.292  Support for execution under unix.                    
  BUIL3005 29.106  JES3 PDB.JOBS variable JOBCLAS8 has after change.    
  BUILDPDB 29.068  MXG 28.28-29.02. ABEND=JCL obs missing in PDB.JOBS.  
  DB2ACCT  29.111  DB2 CICS TRAN name could be wrong, now from QWHCCV.  
  DB2ACCTP 29.053  Doc. QWACxxxx variables in DB2ACCTP always missing.  
  EXITCICS 29.064  Rare (one-site) error in INFILE exit corrected.      
  GRAFWRKX 29.185  Workload RMFINTRV graph's update uses new workloads. 
  IMACICRD 29.302  Comment within comment block if default used.        
  JCLSPLIT 29.241  Example to split SMF had 102 records copied twice.   
  MONTHBLD 29.008  MXGNOBY default to eliminate NOTSORTED exposure.     
  MONTHBLD 29.017  SERIOUS ERROR CORRECTED: last day's PDB skipped.     
  MONTHxxx 29.052  SAS 9.1.3 Only.  %QCMPRES needed versus %CMPRES.     
  MXGSASxx 29.265  MXGTEMP temporary DDNAME/FILENAME added to MXG JCL.  
  RMFINTRV 29.005  Doc: INTERVAL=QTRHOUR became default in 28.01.       
  RMFINTRV 29.194  Stats on Page Dataset Slot Usage added to RMFINTRV.  
  RMFINTRV 29.305  INTERVAL=SHIFT generated warnings & incorrect output.
  SAS V9.3 29.159  Support for SAS Version 9.3 - SAS Hot Fix SN43828.   
  SMFSRCH  29.236  SMFSRCH, search SMF records for text, print all obs. 
  TYPE0    29.032  PDB.IPLS, now, DOES always report a SYSTEM IPL.      
  TYPE102  29.125  DB2 SMF 102 IFCID 22 INPUT STATEMENT EXCEEDED error. 
  TYPE102  29.235  IFCID=22 in Change 28.234 wrong in DB2 V9.           
  TYPE105  29.100  Support for GDPS Global Mirror V3R8 SMF 105 record.  
  TYPE110  29.076  CICS CPUTM exceeds ELAPSTM, zAAP/zIIP Equivalent time
  TYPE110  29.094  1st MXG 29.03 ONLY. CICSTRAN CPUTM plus fields WRONG.
  TYPE110  29.097  INPUT EXCEEDED 110-2 MNSEGLC=5 with DPL segment      
  TYPE110  29.135  Support for CICS/TS 4.2 was in 29.03.                
  TYPE110  29.155  CICS/TS 4.2  Statistics variables overlooked, added. 
  TYPE110  29.221  CICS Statistics datasets CICDB2GL,CICSMDSA, corrected
  TYPE110  29.293  Support for CICS Statistics STID=143 and 144.        
  TYPE111  29.001  Support for IPIC creates obs in TY111CXI.            
  TYPE111  29.124  Variables CTGIAREQ/CTGLALRQ revised keeps.           
  TYPE111  29.153  UNDECODED CTGRECID message, possible CPU loop.       
  TYPE113  29.060  z196 Est Finite CPI, Est SCPL1m calcs revised.       
  TYPE113  29.080  New variables and label revisions.                   
  TYPE113  29.176  Support for APAR OA36816, SMF 113 HIS DATALOSS parm. 
  TYPE115  29.015  Support for MQ Version 7 compression statistics.     
  TYPE115  29.057  Support for Websphere for z/OS MQ Version 7.0.1.     
  TYPE115  29.161  MXG 29.03-MXG 29.05 dataset MQMCFMGR was wrong.      
  TYPE116  29.057  Support for Websphere for z/OS MQ Version 7.0.1.     
  TYPE119  29.215  Variables T119STCK/TISSTCK/TIESTCH were still GMT.   
  TYPE120  29.081  Support for User Field in SMF 120 Subtype 9 record.  
  TYPE120  29.136  Support for WebSphere WAS 8.0 (COMPATIBLE).          
  TYPE120  29.240  Length of Character Variable SMF1209FH can't change. 
  TYPE120  29.272  SM1209CI and SM1209CX can be negative.               
  TYPE1415 29.226  False ERROR.TYPE1415.DEFECTIVE.EXTENDED... log msg.  
  TYPE16   29.232  DFSORT variables ICEMNVLX, ICEMNVLY, ICEMNVLZ wrong? 
  TYPE16   29.264  Support for DFSORT z/OS 1.13 COMPAT new variables.   
  TYPE19   29.183  Variables SMF19TRK and SMF19TRM were wrong.          
  TYPE23   29.177  Support for APAR OA35175, logstream stats in SMF 23. 
  TYPE26J2 29.024  Cosmetic: INREASON NOT DECODED messages corrected.   
  TYPE30   29.025  Small negative CPUUNITS now set to zero.             
  TYPE30   29.034  Invalid data for SMF30RGT is true, circumvented.     
  TYPE30   29.058  Variable CPUCEPTM always now set to a missing value. 
  TYPE30   29.174  Support for APAR OA34895, EXCP/IOTM Missed, SMF Lock.
  TYPE30   29.175  Support for APAR OA35617, SMF30CRM VELOCITY MNGED?   
  TYPE57   29.173  Support for APAR OA36966, JES3 expanded NJEJOBNO.    
  TYPE70   29.127  Support for z/OS 1.12 VMGUEST option, CPU Time in 70.
  TYPE7072 29.077  z/OS under z/VM: MXG messages, nonexistent RMF data. 
  TYPE7072 29.152  VMSYSTEM='Y' RMF records validated, and revised.     
  TYPE7072 29.220  Support for z/OS 1.13 (REQUIRES MXG 29.03 or later). 
  TYPE70PR 29.098  Counts ICFCPUS/IFLCPUS/IFACPUS/ZIPCPUS too high.     
  TYPE70x  29.239  Variable SHIFT (used as "ZONE") added to all RMF.    
  TYPE78PA 29.214  Values in TYPE78PA ending with TOTL could be wrong.  
  TYPE80A  29.223  New TOKENIDs starting with NOxxxx (NOCPUTIMEMAX, etc)
  TYPE845  29.212  Invalid JES3 JMF SMF 84 Subtype 1 Segmented Records. 
  TYPE85   29.093  INPUT STATEMENT EXCEEDED st 79, z/OS 1.12.           
  TYPE89   29.002  Support for APAR OA31615, zIIP/zAAP times added.     
  TYPE89   29.178  Variable CECSER in 89 now contains only 4 positions. 
  TYPE90A  29.142  Enclave variables decoded in TYPE9030 dataset.       
  TYPEADAB 29.189  Support for Software AG's ADABAS SMF user record.    
  TYPEAXWY 29.231  Support for Axway CFT/ESA (Cross File Transfer) SMF. 
  TYPEBBMQ 29.056  Support for MainView MQ (MVMQ) Version 4.4.          
  TYPEBETA 29.059  Support for Beta 93 Version 4.2 subtypes 25/50.      
  TYPEBETA 29.233  Support for BETA93 Version 4.1.0 subtype 25 changes. 
  TYPEBVIR 29.006  Variables DVRTBV01-32 incorrectly formatted.         
  TYPECFS  29.186  Support for InfoSphere Classic Federation Server SMF.
  TYPECIMS 29.033  Support for IMF Version 4.5 is in place.             
  TYPEDB2  29.031  DB2 V9.2 only, most QBGxxx variables DB2GBPST wrong. 
  TYPEDB2  29.121  QWHADSGN/QWHAHAMN were sometimes blank.              
  TYPEDB2  29.128  DB2 INVALID DISTRIUTED HEADER message corrected.     
  TYPEDB2  29.131  DB2PARTY added to DB2ACCTP, Rollup impact documented.
  TYPEDB2  29.140  New LUUVTIME instead of QWACBSC for start time.      
  TYPEDB2  29.209  DB2 V10 ID=100 ST=1 INVALID HEADER.                  
  TYPEDB2  29.213  Support for DB2 V10 IFCID 225 Subtype4 INCOMPATIBLE. 
  TYPEDB2  29.225  INVALID DB2 V10 QMDA segment for QMDAPTYP='JCC'.     
  TYPEDCOL 29.296  DCOLLECT support updated to execute on ASCII.        
  TYPEDM   29.158  NDM-CDI Version 5 new fields supported.              
  TYPEENDV 29.012  Support for Endeavor Version 14 (INCOMPATIBLE).      
  TYPEFERT 29.247  Support for ZEN FERRET V2.3 (INCOMPATIBLE).          
  TYPEIDMS 29.156  Support for IDMS/R Performance Monitor Version 18.   
  TYPEIMS  29.307  Support for IMS Version 12: Adds ZIIP/ZAAP CPU times.
  TYPEIMSA 29.110  the exit _IMSTRN invocation was accidentally removed.
  TYPEIMST 29.144  IMS Transaction Detail in new IMS56FA dataset!!      
  TYPEIMST 29.162  Validation of TYPEIMST, many changes for IMS56FA.    
  TYPEIMST 29.230  Further updates to IMS56FA transaction processing.   
  TYPEITRV 29.223  Support for APAR OA37114, ITRF (OMEGAMON IMS V420)   
  TYPEMPLX 29.247  Support for ZEN IMPLEX V5.1 (COMPATIBLE)             
  TYPENDM  29.010  NDMPRCNM/NDMPRCNO/NDMSTEP now kept where they exist  
  TYPENDM  29.042  Support for NDM-CDI Version 5 records (COMPATIBLE).  
  TYPENDM  29.295  NDM/Connect-Direct V5.0 added jobname/jctjobid.      
  TYPENDM  29.301  Old Version 4.7 "PS" record INPUT STATEMENT EXCEEDED.
  TYPENTSM 29.075  Support for 62 new objects and 1425 new NT metrics.  
  TYPEPOC  29.219  Support for Tivoli Workload Schedulr Ver 8.3 INCOMPAT
  TYPEPOEX 29.134  Support for Informatica's POWER EXCHANGE SMF record. 
  TYPEQACS 29.078  Support for OS/400, AS/400 Version 7.1 (INCOMPATIBLE)
  TYPEQACS 29.208  Support for IBM i-series (AS400), more than 32 CPUs. 
  TYPERACF 29.067  RACF UNLOAD dataset RACF0270 UID limit variables.    
  TYPERMFV 29.013  CPCGRPLM and LCPUPOLR variables were wrong.          
  TYPERMFV 29.297  Continued RMF III enhancements.                      
  TYPERMFV 29.300  Wrong ASMRMFV in first 29.29, VMACRMFV updated.      
  TYPESVIE 29.273  Support for SYSVIEW subtypes 34 and 35.              
  TYPETIMS 29.123  Support for TMON/IMS Version 3.0 (INCOMPATIBLE).     
  TYPETLMS 29.269  Support for CA TLMS tape library 2003 record changes.
  TYPETMO2 29.244  Support for TMON/CICS V3.3 (mostly COMPATIBLE) TCE.  
  TYPETMS5 29.274  CA-1 TMS Extended Format TMC records have no impact. 
  TYPETMS5 29.304  USER ABEND 1234 can be bypassed for TMSCLEAN input.  
  TYPETPMX 29.071  Support for Throughput Manager subtype 10 and 16.    
  TYPETPMX 29.211  Support for Throughput Manager APAR TMT6214, st=16.  
  TYPETPMX 29.229  TPMCA7JN, TPMPI, and TPMDUEOT may be wrong.          
  TYPEVMXA 29.014  z/VM MONWRITE "exit" at EOF to detect ftp failure.   
  TYPEVMXA 29.026  Support for zVM APAR VM64794 (COMPATIBLE).           
  TYPEVMXA 29.092  z/VM new PDB.VXINTUSR sums all engines for each VM.  
  TYPEVMXA 29.163  z/VM Crypto Record (5,10) with PRCAPMCT=6 error.     
  TYPEVMXA 29.172  Support for APAR VM64961, SMF 113 in z/VM MONWRITE!! 
  TYPEVMXA 29.207  z/VM MONWRITE Broken Control Rec if 2.14 (SCALL) rec.
  TYPEXAM  29.126  XAM variables in VXSYTEP2 were not all input/kept.   
  TYPEXAM  29.294  Support for VNDNIC, LPARNW, USVCPU segments.         
  TYPEZOSA 29.247  Support for new ZEN OSA MONITOR V1.3 SMF records.    
  TYPEaaaa 29.238  All USER SMF have MACRO _IDaaaa nnn as SMF record id.
  TYPSXAM  29.249  TYPSXAM didn't sort all XMdddddd datasets to the PDB.
  UTILARCH 29.137  New UTILARCH archives data (like Outlook archive).   
  UTILVREF 29.075  MXG now creates DATASET names up to 32 characters.   
  VMAC102  29.242  On ASCII COMPRESS turned off, QW0145TX maybe trashed.
  VMACDB2H 29.037  DB2 V9.1 false "INVALID DISTRIBUTED HEADER" message. 
  VMACSMF  29.079  MXG will ABEND if SMFTIME is invalid.                
  VMACSMF  29.290  USER ABEND 69 due to invalid SMFTIME now bypassed.   
  VMXGGETM 29.224  Enhancements to select records with LOOKFOR=text.    
  VMXGMPDB 29.292  Support for execution under unix.                    
  VMXGPPDS 29.298  Compare contents of multiple PDS/PDSE libraries.     
  VMXGPRNT 29.250  INSTREAM replaces TMPPRNT.SAS for ASCII restrictions.
  VMXGSRCH 29.103  RESULTS=FINDVAR finds all datasets with a variable.  
  VMXGSUM  29.054  Macro variable DSETEXST redefined.                   
  VMXGSUM  29.154  AUTOCALL %macro's %CMPRES/%QCMPRES removed.          
  WEEKBLD  29.008  MXGNOBY default to eliminate NOTSORTED exposure.     
  See member CHANGESS for all changes ever made to MXG Software.        
Inverse chronological list of all Changes:                              
NEXTCHANGE: Version 29.                                                 
====== Changes thru 29.307 were in MXG 29.29 dated Jan 23, 2012=========
Change 29.307  Support for IMS 12: ADDS ZIIP/ZAAP TIME TO IMS LOG DATA! 
VMACIMS        IBM changes were COMPATIBLY made, used RESERVED fields,  
Jan 21, 2012   and those CPU times were added by APAR PM36273.          
               These new variables are now created in IMS01/IMS01M:     
                  MSGEWTKN='WLM*TOKEN TO*C2*CORRELATOR'                 
               These new variables are now created in IMS07 and IMS0708:
               This new variable is now created in IMS07 and IMS0708:   
               These two variables are now created in IMS56FA:          
                  DLRGUR  ='DL/I*GUR*CALLS'                             
                  TPEZAAP ='ZAAP*ZIIP*CPU*TIME'                         
   Thanks to Paul Volpi, UHC, USA.                                      
   Thanks to Jerome Bachmeier,, UHC, USA.                               
Change 29.306  DEBUG=1 was on in several XAM file processing sections,  
VMACXAM        causing log messages but no actual errors in processing. 
Jan 20, 2012                                                            
   Thanks to Clayton Buck, UniGroup, USA.                               
Change 29.305  Using INTERVAL=SHIFT for RMFINTRV generated MXG WARNINGS 
VMXGDUR        and produced incorrect output, because TYPE75 addition in
VMXGINIT       Change 29.194 didn't test that INTERVAL value.  But after
VMXGRMFI       the VMXGRMFI fix for SHIFT, and because VMXG70PR uses the
VMXGSUM        same macros, both summary programs were tested with all  
Jan 22, 2012  -For RMFINTRV, all "Normally used" INTERVAL= values from  
               SECOND thru FOURHOUR were correct, but for long-duration 
               values of EIGHTHOUR thru ANNUAL, variable STARTIME was a 
               missing value, and an "invalid" string did not circumvent
               by setting INTERVAL=DETAIL as documented.  Changes had to
               be made to VMXGRMFI where END versus START had been used.
              -For ASUM70PR and ASUM70LP datasets, there were no errors,
               but both ASUMCEC and ASUMCELP had populated-but-wrong    
               STARTIME values (close, but wrong) for long-durations.   
              -VMXGDUR was the culprit with inconsistent ENDTIME values 
               returned when FLORCEIL was CEIL for long duration values.
               (No one reported errors, other than SHIFT, "NEVER USED?")
              -VMXGINIT added new &MXGDURTM a global macro.             
              -Other members that invoked VMXGDUR were verified to only 
               expect START values, so they didn't need revision here.  
              -VMXGSUM cosmetic: INTERVAL=NONE is no longer printed when
               no INTERVAL= was specified, as NONE could be confusing.  
   Thanks to Scott Wiig, US Bank, USA.                                  
Change 29.304  Change 29.195 sets USER ABEND 1234 if TYPETMS5 reads data
VMACTMS5       that is not a TMC (because the results are wrong when the
Jan 20, 2012   file was created by TMSGRW.)  But TYPETMS is also used to
               read the output of the TMSCLEAN program, to list scratch 
               volumes, so this change allows you to disable that ABEND 
               when you know the file is not a TMC, with this syntax:   
                 //SYSIN DD *                                           
                 %LET MXGABND=1;                                        
                 %INCLUDE SOURLIB(TYPETMS5);                            
               You will still get the ERROR message on the log that the 
               file was not a TMC as an alert, without the ABEND.       
   Thanks to Robert Carballo, ACS, USA.                                 
Change 29.303  Since MXG 27.06, DB2PM-like Statistics Short Report has  
ANALDB2R       had wrong Total GETS and Buffer Totals Hit Ratios values.
Jan 19, 2012   The SUM statement in line 18777 repeated QB1             
                 GETS =SUM(QB1TGET,QB1TGET,QB1TGET,QB1TGET,0);          
               but should have summed all four buffer counts:           
                 GETS =SUM(QB1TGET,QB2TGET,QB3TGET,QB4TGET,0);          
   Thanks to Paul Billick, QVC, Inc, USA.                               
Change 29.302  CICSTRAN: If your old IMACEXCL member included IMACICRD, 
IMACICRD       but you didn't have an IMACICRD in 'USERID.SOURCLIB',    
Jan 19, 2012   (listed as required in the UTILEXCL job's report), then  
               the new default IMACICRD in MXG 29.29 was %INCLUDEd, but 
               it had a comment within the commment block (that I had   
               missed in my QA tests) that caused a 180 SYNTAX ERROR.   
   Thanks to Harald Seifert, Huk-Coburg, GERMANY.                       
====== Changes thru 29.301 were in MXG 29.29 dated Jan 18, 2012=========
Change 29.301  NDM-CDI Version 4.7 "PS" record INPUT STATEMENT EXCEEDED.
VMACNDM        Change 29.295 input PSSGPE1D offset, added in V5.0, from 
Jan 18, 2012   two reserved bytes, but (old) 4.7 PS records have '4040'x
               in those two bytes, and the NEXT two bytes are zero.     
               Since NDM-CDI records don't contain a version number, the
               the logic was revised to test the value of the offset vs.
               the record length to circumvent the error.               
   Thanks to Raff Rushton, IBM Global Services, USA.                    
Change 29.300  First 29.29 ONLY: RMF III PROCESSING WAS BROKEN.         
ASMRMFV        Fixed in 29.29 dated Jan 18:                             
VMACRMFV       so that version contains these two corrected members.    
Jan 18, 2012  -The VMACRMFV member in MXG 29.29 failed when reading DVT 
Jan 22, 2012   because updates made to VMACRMFV for the new ASMRMFV did 
               not work with RMFBSAM files created with the old ASMRMFV.
               This change to VMACRMFV revised the DVT logic so that    
               records created by the old or the new ASMRMFV program are
               correctly processed.                                     
              -The ASMRMFV member in MXG 29.29 was NOT the updated code,
               even though it had "Jan 14, 2012, Change 29.297" in the  
               comments and log messages; it was the ASMRMFV from 29.05 
               that had none of the last six month's enhancements, and  
               it had an R in column 1 of the fourth line which caused  
               the assembly to fail with errors, in the first iteration.
              -This change MAY be INCOMPATIBLE - the new VMACRMFV might 
               ABEND with RCD data in RMFBSAM files created by earlier  
               ASMRMFV versions, so the ONLY safe implementation is to  
               assemble the Jan 18 ASMRMFV and use that new program to  
               read the VSAM RMF file to create the RMFBSAM output file,
               and then use the new VMACRMFV to read that RMFBSAM file. 
               (If your existing ASMRMFV load module was created from   
               an MXG version earlier than MXG 29.05, the new VMACRMFV  
               should execute without an ABEND, but no guarantee.)      
               Added Jan 22:                                            
              -ZRBDVT now only outputs DEVICES WITH ACTIVITY, where the 
               activity is calculated/tested in EXZRBDVT exit member:   
                 IF ACTIVITY GT 0 THEN DO;                              
                   OUTPUT _WZRBDVT;                                     
               Tutorial: Your tailoring logic in EXdddddd dataset exits 
               to control output of an MXG dataset needs this structure:
                 IF something THEN DO;                                  
                   OUTPUT _dddddd;                                      
               and can't use a DELETE, nor "IF something;" statements,  
               because they stop the read-current-record, and cause SAS 
               to read the next record, so any remaining segments in a  
               record with more than one observation per record would be
               skipped and the output observation count could be small. 
              -By only outputing active devices in ZRBDVT with detail   
               device-level-per-minute data, it's more practical to use 
               the RMF III detail DVT dataset for DETAIL I/O STATISTICS.
   Thanks to Jack Schudel, University of Florida, USA.                  
   Thanks to Rodger Foreman, TransUnion Corp, USA.                      
Change 29.299  Cosmetic installation issues with first MXG 29.29.       
FTP           -The file size of ter2929.ter was incorrect in the emailed
SENDDATA       instructions sent on the 17th. 27,319,296 was correct for
Jan 18, 2012   that iteration.                                          
              -Appendix A in the download instructions failed on JES3:  
                 IAT4401  LOCATE FOR STEP=STEP2OF2 DD=INFILE            
                 IAT4404 DATASET NOT FOUND ON MAIN PROCESSOR A          
               because that DSN was dynamically allocated in the PGM=FTP
               step, but JES3 doesn't know that.  The example is changed
               to define the DSN in a DD statement, so the new example  
               now works on both JES2 and JES3. This is not a new issue,
               but had not been previously reported, probably because   
               JES3 techies knew how to resolve this JES3 "feature"!    
   Thanks to James E. Lund, Texas A&M University, USA.                  
====== Changes thru 29.298 were in MXG 29.29 dated Jan 17, 2012=========
Change 29.298  VMXGPPDS utility reads PDS and PDSE datasets, originally 
VMXGPPDS       to print text in two-column format.  It is now enhanced  
Jan 15, 2012   to output the Index entry for each PDS member, keeping   
               these variables in a dataset for each PDS/PDSE library:  
               with an example showing how it can be used to compare the
               members (i.e., which is most recent?) in different PDS or
               PDSE libraries. Both text and load libraries can be read,
               but index information is only usable for text PDS/PDSEs. 
Change 29.297  Detail and Summary reports from ASMRMFV have been        
ASMRMFV        reformatted for improved legibility, content, and        
VMACRMFV       clarity.  Message RMFV105I is updated by the changes.    
Jan 12, 2012  -When the DVT is selected in ASMRMFV the entries are now  
               blocked up to use as much as possible of a 32K logical   
               record.  The number of DVT records output was reduced by 
               99.5% during testing.  The actual data volume is         
               unchanged.  This was to reduce I/Os for performance.     
              -A new ASMRMFV report column DATA ACTION shows the data   
               destination for each table as: OUTPUT, FILTER, or SKIP.  
              -A new ASMRMFV report column ENTRIES COUNT shows the      
               number of logical table entries processed.  The meaning  
               of an entry varies with the RMF III table type.  See     
               source code documentation for more details.              
              -The minimum and maximum LRECL output are now shown for   
               filtered and skipped records if the optional RMFFILT     
               and/or RMFSKIP DD statements are provided.               
              -Input table counts are supported up to 999,999,999.      
              -Output record and entry counts are supported up to       
              -A new message RMFV032E is added to show the error code   
               from the IBM decompression routine ERB3RDEC should a     
               failure occur.  In this case the start and end time of   
               the problem RMF III sample set is also shown.  This      
               should be a rare event.                                  
              -The discussion on final ASMRMFV return codes is expanded.
              -A discussion is added on how RMF Monitor III options     
               affect the data contents in tables.                      
              -Prologue documentation in source is updated to include   
               discussion on new ASMRMFV column headings.               
              -VMACRMFV is changed to support blocked DVT entries in    
               input records.                                           
              -In VMACRMFV the DEVTYPE variable length has been         
               corrected to 12 bytes.                                   
              -In VMACRMFV the calculation of the DEVACTTM variable has 
               been changed to avoid excessive Missing Value counts from
               These are available only with RMF z/OS 1.9 and up.  They 
               will be missing values for older releases.               
              -Nine new data variables are added to the ZRBDVT file:    
               DVTFLAG3 - Flag Byte                                     
               DVTHPAVB - Device Is HyperPAV Base Device (Y/N/?)        
               DVTHPCON - Number Configured HyperPAV Aliases for LSS    
               DVTHPSM  - Number of Successful PAV Samples              
               DVTHPNUM - Accumulated Number of HyperPAV Aliases        
               DEVALCH  - Number of Alias Exposures Has Changed (Y/N)   
               DEVLCUOK - LCU Number Is Valid (Y/N)                     
               DEVPAV   - Multiple Exposure Device(Y/N)                 
               DEVVDASD - Virtual DASD (Y/N)                            
               The first 5 variables are available only with RMF z/OS   
               1.9 and up.  They will be missing values for older       
               releases. The last 4 variables are available to all MXG  
               users with RMF Monitor III.                              
              -A new option ZERODVT/NOZERODVT has been added to ASMRMFV.
               The default is NOZERODVT and will filter out the initial 
               DVT entry for each MINTIME interval.  This entry is all  
               binary zeros and has no value in a PDB.                  
              -VMACRMFV will also check for a zero initial DVT entry and
               skip processing for it if detected.                      
              -These are companion programs and the same maintenance    
               level of each must be used for successful results, i.e., 
               you MUST assemble the ASMRMFV program to use the VMACRMFV
               in 29.29.                                                
Change 29.296 -DCOLLECT support updated to execute on ASCII platforms,  
VMACDCOL       by conditionally specifying RECFM=S370VBS when MXG is    
VMXGINIT       executed under ASCII.  (On z/OS that DCB parm is set by  
Jan 14, 2012   the DSCB at OPEN; S370VBS reads V/VB/or VBS RECFMs.)     
              -Variable ZTIME added to all keep lists (zEE time when zEE
               dataset was created) so that multiple executions of the  
               IDCAMS DCOLLECT process can be differentiated by time.   
              -The alternative to differentiate multiple executions of  
               DCOLLECT is to use the variable INFILENM, which contains 
               the "dsname/file-name" of the input data, but INFILENM   
               is only "input" and is not kept in any DCOL dataset. You 
               could add INFILENM to any DCOL dataset(s) with syntax    
                 %LET MACKEEP=  MACRO _KDCOLxx  INFILENM  %  ;          
               (and repeat the MACRO _KDCOLxx for each dataset) in your 
               //SYSIN, but this new alternative is now created:        
              -New macro variable &MXGINFIL is created with null value  
               in VMXGINIT, and is added to the KEEP= list for all DCOL 
               datasets.  So you could then insert this statement       
                 %LET MXGINFIL=INFILENM;                                
               in your SYSIN stream, and variable INFILENM will be kept 
               in all of the DCOLLECT datasets                          
   Thanks to Nick Johns, Sainsbury's Supermarkets Ltd, ENGLAND.         
Change 29.295  Version 5.0 of NDM/Connect-Direct added jobname and the  
VMACNDM        JES JCTJOBID to the PS and RJ records.                   
Jan 14, 2012                                                            
   Thanks to Peter L., whose company won't allow him to be cited.       
Change 29.294 -Support for Velocity Software segments VNDNIC, LPARNW,   
EXXMLPAR       and protection for USVCPU segment (no data of interest): 
EXXMDNIC         dddddd   dataset                                       
VMACXAM          XMDNIC   XMVNDNIC                                      
VMXGINIT         XMLPAR   XMLPARNW                                      
Jan 11, 2012  -Some values in XMLPARNW look wrong, and test data doesn't
               contain fields PCTMGTM nor PCTLOGICAL.                   
   Thanks to Robert Obee, IMSHealth, USA.                               
Change 29.293 -Support for CICS Statistics STID=144 adds new dataset    
VMAC110        CICEPR.                                                  
Jan 10, 2012  -STID=143 message SKIP=4 with STILEN=156 was eliminated.  
               There was no new data in the record.                     
   Thanks to Joachim Sarkoschitz, DATAEV, GERMANY.                      
Change 29.292  Execution under unix is now supported, having found and  
BLDSMPDB       protected for these variants between WIN and UNIX:       
VMXGALOC      -The XWAIT option is only supported on WIN, causing error 
Jan 14, 2012   conditions on UNIX and zOS but is now protected.         
              -If NOT EXIST does not work on UNIX, so the logic now used
               is %SYSFUNC(FILEEXIST(FILENAME)) which returns a zero if 
               the file does not exist, or a 1 when the file exists.    
                 Using SYSFUNC also allows the MXGNOTES to only appear  
                 when we actually create or delete a directory.         
              -md (or MD) is not recognized on UNIX as make directory so
               the full mkdir command name (in lower case) is now used. 
              -rmdir (rd) is used to remove directories under Windows,  
               but the UNIX command is rm with different subparameters: 
                on Windows the command is rd /q /s                      
                on UNIX the equivalent is rm -r                         
              -These changes do not impact z/OS execution of BLDSMPDB.  
               They have been tested under AIX 5.3, RedHat LINUX, and   
               should work on all xNIX platforms.                       
   Thanks to Ruth Larsen, CA Technologies, USA.                         
====== Changes thru 29.291 were in MXG 29.09 dated Jan  4, 2011=========
Change 29.291  Lines 541 & 542 were missing a second close-parenthesis, 
ANALGRID       some arguments were not UPCASE'd, and some selection     
Jan 14, 2012   arguments were not printed on the log when used.         
               Examples added and footnotes formats match grid formats. 
   Thanks to David Bixler, FISERV, USA.                                 
Change 29.290 -Invalid SMFTIME (Julian date 366 in 2011) in IBM BVIR SMF
VMACSMF        record (HISTORY FILE FOR TS7700 VTS TAPE SYSTEM) caused  
Jan  2, 2012   a USER ABEND 69, because MXG logic for a bad SMFTIME was 
VMACBVIR       intended to catch the reading of a non-SMF file.  This is
VMACNAF        the FIRST time an actual customer has ever ABENDed due to
               my choice, which I now realize is too harsh, so now, only
               the ERROR message is printed by default. You can enable  
               the ABEND with %LET MXGABND=1; in your SYSIN.            
                  (BVIR records are supported in MXG's TYPEBVIR code.)  
              -A second SMF record type, from VTAM SuperSession product,
               also caused the USER ABEND 69 because its Julian date had
               an invalid Julian date of 637 in 2012! Two in two days!! 
                  MXG's TYPENAF supports those SMF records, but the last
                  update was in 2005, and they have been incompatibly   
                  changed, with new subtypes and inserted data fields;  
                  MXG will be updated when doc is available.            
   Thanks to Jim S. Horne, Lowe's Companies, USA.                       
   Thanks to Jorge Fong, NYC Information Technology, USA.               
Change 29.289  The ASMDBLKU program is an ASM version of UDEBLOCK, that 
ASMDBLKU       constructs a valid VBS file on z/OS from a V/VB/VBS file 
Dec 30, 2011   that was previously downloaded to an ASCII platform, as  
               that file is just a serial stream of bytes that cannot   
               be "back-loaded" and read on z/OS.  You upload the file  
               from your ASCII platform back to z/OS, and then UDEBLOCK 
               or ASMDBLKU will read those chunks and reconstruct those 
               records into a valid VBS file on z/OS.  This would likely
               be needed only if IBM or another vendor needs for you to 
               send the VBS file for a problem, and you only have the   
               downloaded file.  UDEBLOCK required SAS on z/OS while    
               ASMDBLKU doesn't. Additionally, UDEBLOCK was functional  
               but VERY expensive for DASD space, since it created a    
               single block for each record and wrote one record per    
               track.  ASMDBLKU is smarter and wastes no DASD space.    
               Multiple enhancements were made to the original ASMDBLKU:
              -The SMFOUT file is now generated as a true RECFM=VBS file
               so no DCB overrides in JCL are required to process it    
               subsequently into a PDB build.                           
              -QSAM blocking is now used so that SMFOUT disk space      
               requirements are significantly less than before when only
               one record per 32K block was output.                     
              -The PGSER macro system service SVC call to zero the      
               output buffer after each I/O was replaced with MVCL logic
               thus providing up to a 64% CPU time reduction seen in    
              -The SMFOUT file now has DCB BLKSIZE=0 to use System      
               Determined BLKSIZE.  Up to a 41% further reduction in    
               disk space usage was determined in testing.              
              -SMFIN and SMFOUT files now use DCB BUFNO=20 to reduce    
               elapsed time with up to a 33% time reduction seen in     
               testing.  There was some corresponding increase in below 
               the line storage, but the program ran successfully with  
              -Most ASMDBLKU messages are reformatted for improved      
               clarity, legibility, and content.                        
              -There are now separate and distinct messages for length  
               errors for the SMFIN physical block, BDW, and RDW values 
               respectively.  Previously, these types of error were not 
              -Length error messages now show the invalid length value  
               and the related record number.                           
              -The SMFIN file is now checked for RECFM=U and DSORG=PS   
               prior to any processing.                                 
              -SMFIN and SMFOUT byte counts are now accumulated and     
               reported.  SMFOUT byte counts do NOT include the BDW     
               fields added by QSAM.  Up to 19 decimal digit totals are 
               supported (9,999,999,999,999,999,999).                   
              -Minimum and maximum LRECL values read from the SMFIN file
               are now reported as message DBLKU25I.                    
              -Minimum and maximum LRECL values written to the SMFOUT   
               file are now reported as message DBLKU26I.               
              -A missing DD statement for SMFIN or SMFOUT now generates 
               Return Code 16 as a severe error.                        
              -Two character Return Codes are now displayed.  Before    
               Return Codes higher than 8 were not supported.           
              -Record counts for SMFIN and SMFOUT files are now scaled  
               up to 9 decimal digits (999,999,999).                    
              -Message DBLKU30I indicating final utility status is now  
               the last message displayed.                              
              -Message DBLKU30I ended message is consistent in          
               appearance and format with DBLKU00I started message.     
              -PRINT OFF/PRINT ON added to suppress printing of the     
               change log during assembly.                              
              -Prologue comments outside of the assembler source have   
               been updated.                                            
Change 29.288  Reserved Change.                                         
Dec 30, 2011                                                            
Change 29.287  Many VMWARE objects were revised to contain xxxxVMHO and 
EXNTDTSC       xxxxVMGU (Host and Guest names), changing NRNAMES, which 
IMACNTSM       caused MXG NRNAMES Messages.  New DTS.ALERTCONFIG object 
TYPENTSM       is supported.                                            
Dec 31, 2011                                                            
Change 29.286  Variable LPARCPUS was incorrectly typo'd as LPARCPU. Been
ANAL113        this way since 2010, so I assume either no use, or users 
Dec 22, 2011   recognized and fixed the typo without report to support, 
               so Thomas gets this citation for finding the old error.  
   Thanks to Thomas Puddicombe, CSC, USA.                               
Change 29.285  Presumed error in back level SAS 9.2 TS0202M2 on z/OS, as
FORMATS        NO error with 9.3 TS0202M3 nor 9.1.3/SP4 nor 9.3 on z/OS.
CREATEBC       A split line in EBCDIC text for $MGZOSVT caused no error 
PROCSRCE       when PROC FORMATS created $MGZOSST/$MGZOSVT, but the two 
Dec 22, 2011   formats could not be loaded when TYPEZOSA was executed by
               TESTUSR1.  The original ASCII text had a unexpected '0A'x
               character (Line Feed) in that line, but that only caused 
               the EBCDIC text to be split there; no unprintable text   
               character was created in EBCDIC, and the longer right    
               hand value was still valid syntax, and was handled fine  
               on all other z/OS SAS versions.                          
              -However, the unexpected '0A'x in ASCII text reminded me  
               to look for other unprintables in the EBCDIC text, and   
               three values ('01'x,'1C'x,'1D'x) are now detected in the 
               PROCSRCE/CREATEBC QA members, and corrected before EBCDIC
               members are created for distribution.  Fortunately, none 
               of these characters cause execution errors.              
   Thanks to Scott Wiig, US Bank, USA.                                  
====== Changes thru 29.284 were in MXG 29.08 dated Dec 20, 2011=========
Change 29.284  ANALGRID creates a color-intense grid report of the value
ANALGRID       of any variable, with time intervals as columns and date 
Dec 20, 2011   as the row, to visually identify "hot spots".  This is   
               based on the original design that was contributed by Bob.
               See, ANALGRID for examples. 
   Thanks to Robert A. Obee, IMS Health, USA.                           
Change 29.283  MXG 29.06-29.07. RMFINTRV with INTERVAL less than QTRHOUR
VMXGRMFI       created an invalid PDB.RMFINTRV dataset with too many obs
Dec 20, 2011   but with ERROR: INCONSISTENT RMF DATA printed on the log.
               Change 29.194 added TYPE75 summary data to RMFINTRV, but 
               had INTERVAL=QTRHOUR instead of INTERVAL=&INTERVAL.      
   Thanks to Yves Terweduwe, CIPAL, BELGIUM.                            
Change 29.282  The example summary of TYPE72GO to create ASUM72GO was   
ASUM72GO       updated to support "SYNC59" data written at :59 or :00   
Dec 20, 2011   intervals.                                               
   Thanks to Brian Carter, HP Enterprise Services, ENGLAND.             
BUILD005       variables are created in TYPE30_V and PDB.SMFINTRV data  
BUIL3005       sets, to report the interval percentage of time when an  
Dec 18, 2011   address space was dispatched on a physical processor.    
               PCTTASKTIME can exceed 100% when multiple tasks are      
               used for parallelism; values more than 25% are probably  
               of most interest. You can create the variables from your 
               PDB.SMFINTRV (or TYPE30_V) dataset, using:               
                 IF INTRVLTM GT 0 THEN                                  
   Thanks to Bernie Pierce, IBM, USA.                                   
Change 29.280 -z/OS 1.13 ASM ERROR when assembling ASMTAPEE/MXGTMNT:    
Dec 20, 2011     THE OPEN MACRO SUPPORTS ONLY ASCENV=P."                
               But there is NO NEED to ASM a new load module under 1.13;
               your currently executing MXGTMNT module works just fine! 
              -This IBM note (migration guide) is the ONLY clue of the  
               incompatible change, which impacts OPEN/CLOSE macros, but
               doesn't mention any by name:                             
                DFSMSdfp: Accommodate 64-bit & AR mode rules enforcement
                in DFSMS macros; required if you have code that invokes 
                DFSMS macros (but not all!).  Before z/OS V1R13, many   
                DFSMS macros that did not support 64-bit or AR mode did 
                not react to being invoked in 64-bit or AR mode, and    
                generated code that might have been invalid in 64-bit or
                AR mode. Starting with z/OS V1R13, these macros are     
                changed to issue an assembly-time message and suppress  
                expansion if they are invoked in 64-bit or AR mode."    
              -But as noted above, you didn't really need to ASM.  Now, 
               from MXG's "asmguy", his comments on this change:        
                Nothing is going to happen to an existing site using    
                MXGTMNT and in fact the modification I have to make for 
                this does not result in any change to the executable    
                The SYSSTATE macro is an assembler directive - it sets  
                a flag that tells any macros that support AR mode       
                (Access Register, used for cross memory access) to use  
                their AR mode compatible expansion. Macros that don't   
                have an AR mode expansion used to ignore this because   
                they had nothing to do, and it's always the coder's     
                responsibility to make sure that when those non-AR      
                compatible macros are executed, that the system is not  
                in AR mode.  This is similar to switching back and forth
                from 24-bit to 31-bit mode: some macros can't tolerate  
                31-bit mode.  Nothing has really changed though; it is  
                still the coders responsibility to make sure the system 
                is not in AR mode and macros that can't tolerate AR mode
                still can't, except now IBM is requiring the coder to   
                explicitly set SYSSTATE to indicate to the assembler    
                that the system is not in AR mode.                      
                Of course this is all very silly because the assembler  
                can't know ahead of time that the system is or isn't in 
                AR mode.  So regardless of whether or not SYSSTATE is   
                coded this way the system still could be in AR mode,    
                OPEN/CLOSE will still expand the same way, and if the   
                system really is in AR mode OPEN/CLOSE will abend when  
                So the bottom line is that nothing has changed except   
                our need to do something for no reason at all.          
               -This ASMTAPEE is now ML-48 in the MXGTMNT startup msg.  
   Thanks to Thomas Maguire, CitiGroup, USA.                            
Change 29.279 -ASMRMFV incorrectly calculated the RCDSDI offset, causing
Dec 13, 2011   RCD Table Record had an RCDSD Subsystem Delay array, but 
               the record didn't have an RCDRD Response Time array.     
              -Also a formatting error in message RMFV102I was corrected
               *** END OF DATA *** showing record input count.          
   Thanks to Scott Chapman, American Electric Power, USA.               
Change 29.277  NPM VCS segment with an invalid fifth ECSA segment (with 
VMAC28         buffer size of 180 Kbytes), and without the DATA segment 
Dec  8, 2011   for buffer size 64Kbytes.  The segment length is the 176 
               expected length, so this circumvention skips the invalid 
               segment if size is 180 and doesn't input the last data   
               segment; when IBM fixes the record, the circumvention    
               does not need to be removed.                             
               APAR OA38371 will correct the error, ETA Feb, 2012.      
   Thanks to Karen Florup, Bank of America, USA.                        
Change 29.276  RMF III dataset ZRBASI variable ASIPER, PERIOD, is input 
VMACRMFV       where ASIDMN, DOMAIN, was previously located. ASIDMN is  
Dec  8, 2011   set to zero, its value ever since domains departed z/OS. 
Change 29.275  The CLRMFV Clist will now check for non-zero Return Codes
CLRMFV         from the TSO LISTCAT LEVEL command.                      
Dec  8, 2011  -3 messages indicating the error, the data set name level,
               and the Return Code are now issued.                      
              -In addition, the first 4 lines of LISTCAT output for the 
               error condition are displayed.                           
              -Prior to this change CLRMFV could issue a non-zero MAXCC 
               message at completion and the reason was difficult to    
               determine when LISTCAT was involved.                     
              -A non-zero LISTCAT Return Code is most commonly caused by
               a data set name level that does not exist.               
   Thanks to Rodger Foreman, Acxiom CDC, USA.                           
Change 29.274  CA-1 TMS "Extended Format TMC Catalog" records are COMPAT
VMACTMS5       with ALL versions of MXG, as there was NO change in the  
Dec  7, 2011   TMC's 340 byte record's length. The text of Change 28.040
               that thought there were new length(s) was wrong and gone.
Change 29.273 -Support for subtypes 34 and 35 of SYSVIEW for IMS creates
EXSV34DA         dddddd   dataset   description                         
EXSV34TR         SV34TR   SV34TRAN  Subtype 34 Transaction              
EXSV35EV         SV34DA   SV34DAC   Subtype 34 DAC Segment              
EXSV35TR         SV35TR   SV35TRAN  Subtype 35 Transaction              
IMACSVIE         SV35EV   SV35EVNT  Subtype 35 Event Segment            
VMACSVIE      -There are errors in the subtype 34 and 35 that I have    
VMXGINIT       circumvented in this iteration, and SYSVIEW support has  
Dec  7, 2011   confirmed the errors in the 34 and are looking at similar
               errors in the 35 record; both will likely be corrected in
               a future PTF from CA.  The value in IMRA_DBIOTIME is     
               appears to be defective, also.                           
   Thanks to Anthony G. Hurlston, CSC, USA.                             
Change 29.272 -Variable SM1209CI and SM1209CX can be negative, but they 
VMAC120        were INPUT as PIB, so a negative field becomes a large   
Dec  7, 2011   positive value in MXG.  They are now input as IB.        
               IBM Support reports than when work does not complete,    
               ENDTIME isn't populated, and since CI is calculated as   
               END-START, you get a negative value. But you can also get
               a negative value of -1 if WebSphere was unable to reach  
               its internal service that supplies the END time: for     
               example, an in-flight transaction when the server was    
               configured to "Drain" work during termination, but that  
               transaction still could have completed normally, so all  
               of the other fields could be completely valid.           
               IBM chose to NOT suppress these records even when they   
               might contain incomplete values, because many other data 
               values could be useful in diagnosing problems, and there 
               should be relatively few of these records.  You probably 
               should filter these records from your daily reporting    
               totals, but rather than testing for a negative value in  
               CI/CX, which have valid transaction data, IBM Support    
               suggests to exclude transactions that have any value in  
               the minor code, SM1209CJ, and perhaps to simply count the
               number that were excluded.                               
              -Variable SM1209BM now has value '' instead of the
               value '7.0.0.*' when the fourth byte was GT 9.           
   Thanks to Wayne Bell, UniGroup, Inc, USA.                            
Change 29.271  Variable R799CNF bit 3 now creates R799CPD='Y' if the    
VMAC79         connect/pending/disconnected time is not valid.  All     
Dec  6, 2011   other bits were already decoded into unique variables.   
   Thanks to Heimir Hauksson, Barclays, ENGLAND                         
Change 29.270  Variable POUNAL was incorrectly multiplied by 4096 when  
VMACQACS       it should have been multiplied by 1024 to convert KB to  
Dec  6, 2011   bytes.                                                   
   Thanks to Thierry Wehrle,  BNP Paribas, FRANCE                       
Change 29.269  CA TLMS tape library records were changed sometime since 
VMACTLMS       2003 when the MXG TYPETLMS was last updated, causing the 
Dec  5, 2011   TYPETLMS dataset to contain mostly trashed field as MXG  
               INPUT BAUNIQUE and BAVOL1ST as PIB4 but they appear to   
               be only 2-byte fields.                                   
   Thanks to Gene Palmer, CitiGroup, USA                                
Change 29.268  The new ASUM4HRS %macro calculates "Four Hour" running   
ASUM4HRS       Average Values of the variable(s) you chose, but any     
VGETFMT        integer number of hours can be used instead of "Four".   
VGETLABL      -New VGETFMT/VGETLABL/VGETLEN internal macros retrieve the
VGETLEN        FORMAT, LABEL, and LENGTH of a variable so that the new  
VMXGDUR        Average Value variable will have the same attributes as  
VMXGSUM        the inputted variable.                                   
VMXGPARS      -VMXGDUR,VMXGSUM adds duration tokens for EIGHTHR and     
Dec 13, 2011   TWELVEHR.  These duration tokens now can be used:        
                 THREEMIN, TWOMIN, MINUTE OR SECOND, or DETAIL.         
              -VMXGPARS now parses at two blanks to create a new line.  
Change 29.267  Variable MPL72, the average number of concurrent resident
VMXGRMFI       ASIDs, is now created in PDB.RMFINTRV dataset.  Variables
Nov 29, 2011   APPCAVG and APPCMAX to count those ASIDs are also added. 
   Thanks to Chuck Hopf, Independent Consultant, USA.                   
Change 29.266  In TYPE70PR dataset, variables SMF70MSU and SMF70LAC are 
VMAC7072       output in each TYPE70PR obs, but from the one TYPE70 obs 
Nov 29, 2011   for "THIS" LPAR, so they are repeated for all LCPUADDRs  
               in this LPARNAME (being kept here only so they can be in 
               ASUM70PR).  Since they are z/OS-only relevant, they are  
               now only populated in the SMF70CIN='CP' observations as  
               their non-missing value in obs for VM, ZIIPs, etc, was   
               unexpected and unwanted.                                 
   Thanks to Lars Fleischer, SMT Data, DENMARK.                         
Change 29.265A MXG 29.07 corrections found during ITRM validation.      
VMAC42        -Macro token PSUVMXA added in Change 29.120 was misspelled
VMACCIMS       as PSUMVXA in the GLOBAL statement in VMXGINIT.          
VMACNTSM       Also, the hardcoded PDB. in MACRO _LTYVMXA PDB.VMXAINTV  
VMACTPMX       in the (optional) ASUMVMXA member was corrected to the   
VMXGINIT       default &PVMAINT macro destination DD for VMXAINTV.      
               are no longer kept in CIMSTRAN as they are GMT offsets   
               that are already used to convert times to local zone.    
              -Variable VWGMACBY was accidentally removed from the NTSMF
               dataset VMWGUMEM.                                        
              -TYPETPMX variables JBL54051,JBL55044-JBL55051 were always
               missing values, DKROCOND=WARN printed warnings due to    
               typos in the variable name in the assignment statements. 
               All of the JBL54xxx and JBL55xxx are also now labeled.   
              -TYPE42 variables SMF42PTE and SMF42PTS are now labeled.  
   Thanks to Chris Weston, SAS ITRM Development, USA.                   
Change 29.265  Temporary DDNAME/FILENAME MXGTEMP is added to the MXG JCL
VMXGCNFG       for z/OS for future cases when more than one temporary DD
MXGSAS         is required. Currently, only SMFSRCH uses that DDNAME.   
Nov 25, 2011                                                            
Change 29.264  Support for DFSORT for z/OS 1.13 adds COMPATIBLY two new 
VMAC16         variables to TYPE16 dataset:                             
Nov 25, 2011     ICEMCPUZE='ZIIP*ELIGIBLE*CPU*TIME'                     
Change 29.263  Variables SMF30JQT/SMF30RQT/SMF30HQT/SMF30SQT are missing
BUILD005       values in PDB.SPUNJOBS for jobs that had TYPE30_5 job    
BUIL3005       term obs with MULTIDD='Y' (which have only EXCP counts.) 
Nov 25, 2011   And those TYPE30_5 with MULTIDD='Y' shouldn't ever have  
               been used in BUILDPDB logic; MXG uses the step records   
               for EXCP counts and only wanted the TYPE30_5 values from 
               the "real" TYPE30_5 that has MULTIDD=' '.  So this change
               deletes MULTIDD='Y' observations during processing of the
               TYPE30_5 records in BUILDPDB and BUILDPD3.               
   Thanks to Esther Remiro, La Caixa, SPAIN.                            
====== Changes thru 29.262 were in MXG 29.07 dated Nov 24, 2011=========
Change 29.262  First MXG 29.07 Only, and only if IMACEXCL is tailored to
VMAC110        read exclude fields.   WARNING: UNBALANCED QUOTES message
Nov 23, 2011   was printed, BUT ALL DATASETS WERE CREATED CORRECTLY.    
               There were no unbalanced quotes, but 29.07 had introduced
               new " &CICXLTR " syntax into the existing PUT '***ERROR' 
               statement printed when MXG detects there are excluded    
               fields that are not supported in your IMACEXCL tailoring;
               the enhancement prints your selection statements from the
               current IMACEXCL member in use to help error resolution. 
               And for reasons I know not now, that macro reference was 
               the cause of the spurious warning.  Now SYMGET('CICXLTR')
               is used to retrieve the text for the PUT statement.      
   Thanks to Gerard Bosker, Rabobank Nederland, THE NETHERLANDS.        
Change 29.261 -An incomplete comment in Change 29.147 caused the new and
VMAC0          "true" IPLs datasets WORK.TYPE0 and PDB.IPLS to have ZERO
Nov 23, 2011   observations since that change in MXG 29.06.  That this  
               error was accidentally discovered when trying to diagnose
               the unbalance quote warning in Change 29.262, by counting
               the two comment tokens ( /* */ ) separately to see if the
               counts are equal (because often unbalanced quote errors  
               result from unbalanced comments, or new comments wrapping
               around commented text) suggests that few sites have IPLs 
               that needed to be reported!                              
              -An incorrect pair of single quotes was changed to single 
               quote in optional IMACICBB code, discovered the same way 
               when counting quotes.  The pair was inside the comment   
               block, and it's been there a long time; either tailoring 
               users caught it and fixed it when enabling that optional 
               CICS segment, or nobody uses this optional segment.      
   Thanks to Gerard Bosker, Rabobank Nederland, THE NETHERLANDS.        
Change 29.260  At only one site, the EXITCICS decompression of DB2 V10  
VMACDB2H       records created records with INVALID HEADER values that  
EXITCICS       caused STOPOVER ABEND.  This change thought the SMF data 
Nov 23, 2011   was valid and added protection for the "truncated" data  
Dec 18, 2011   segments, but that protection, while safe, was not needed
               and the problem in the SAS INFILE exit code in EXITCICS  
               is being investigated by SAS Technical Support.  The DB2 
               V10 compressed records can be uncompressed using the IBM 
               utility program xxxxxxx until the problem is resolved,   
               but this is most strange as MANY sites are successfully  
               reading compressed DB2 (and CICS!) records with EXITCICS.
               This is the text of the original change:                 
               DB2 V10 record with INVALID HEADER caused STOPOVER ABEND.
               The ID=101 SUBTYPE=1 record had invalid offsets that are 
               now protected.  The starting INPUT location was compared 
               with the LENGTH of the record, but in this case, while   
               the start offset happened to be less than the LENGTH,    
               the length of data to be input was beyond the LENGTH,    
               causing the STOPOVER ABEND.  Now both the start and end  
               of each of these truncated name fields is validated and  
               an error message "INVALID DB2 RECORD QWHC=...." printed. 
               This text will be updated when an APAR/PTF is known.     
   Thanks to Gerard Bosker, Rabobank Nederland, THE NETHERLANDS.        
====== Changes thru 29.259 were in MXG 29.07 dated Nov 21, 2011=========
Change 29.259  Cosmetic. Diagnostic PUTLOG statement in IFCID=140 code  
VMAC102        was left and printed A_N_= nnn .... on the SAS log for   
Nov 18, 2011   each IFCID=140 record, but no other impact.              
   Thanks to Stephen Hoar, Lloyds Banking, ENGLAND.                     
Change 29.258  Comparison of I/O Connect Times in RMF 74 and SMF 30 show
BUILD005         DEVCONTM SMF74CNN - DEVICE CONNECT TIME   2,058,143 sec
BUIL3005         SMF30AIC          - DASD CONNECT          2,150,200 sec
IMAC30IO         IOTMTOTL SMF30TCN - ASID IO all ASIDs     1,482,821 sec
VMAC30           IOTMTODD SMF30DCT - DD IO all ASIDS       1,253,434 sec
Nov 18, 2011     IOTMNODD  MXGcalc - TOTL not in DDs         229,387 sec
               RMF DEVCONTM and RMF SMF30AIC match quite closely, but   
               that "hardware" IOTM captured in RMF and in SMF30AIC is  
               much larger (2150200-1482821= 677,379 sec) than the IOTM 
               that is captured in SMF30TCN, Address Space IOTM Total.  
               To investigate, variable in TYPE30/JOBS/STEPS/SMFINTRV   
               is created to see if the cause of this uncaptured IOTM   
               can be identified/correlated.  This text will be updated 
               when more is known (including my asking IBM).            
                 Some initial investigation with different data shows   
                 -Of 9881 records with non-zero SMF30AIC, 1867 had a    
                  negative IOTMNOCA, but only 40 were more than -10 sec 
                  and the max negative was 2 jobs at -3 minutes.        
                  MOST OF THESE WERE PROGRAM=DSNYASCP although our old  
                  friend IFASMFDP had instances of -37, -17 and -12 sec.
                 -Of the other 7119 with positive IOTMNOCA, 592 were    
                  greater than 3 seconds, AND ALL WERE PROGRAM=BPXPRFC. 
                  which is the first step of an OMVS Spawned Address    
                  Space Substep.  This suggests that the use of I/O by  
                  USS-OMVS is ONE source of NOT-Captured IOTM in 30s.   
                  There are many OMVS I/O counters in the OMVS segment  
                  in SMF 30s, but none have the I/O Connect Time.       
                 -But, a third sites data looking at DB2 and ADABAS jobs
                  shows large positive uncaptured values for ADABAS but 
                  for DB2 jobs, large negative uncaptured, i.e., time in
                  SMF30TCN is LARGER than the time in SMF30AIC.         
                 -This issue is under discussion with IBM z/OS folks;   
                  I think that IOTM for USS is captured in AIC but not  
                  in IOTM, and there are errors in which address space  
                  records IOTM when there are "partner" database ASIDs, 
                  but the total IOTM are correct.  We'll see!!          
                    JOB     INTBTIME    IOTMTOTL   SMF30AIC   IOTMNOCA  
                  DB2JOB01  13:14:00.15  0:10:23.25  0:00:42.06  -581.19
                  DB2JOB01  13:29:00.16  0:09:08.14  0:02:49.97  -378.16
                  DB2JOB01  13:44:00.16  0:07:51.57  0:01:34.28  -377.29
                  DB2JOB01  14:14:00.17  0:10:44.91  0:00:23.18  -621.73
                  DB2JOB01  14:29:00.21  0:10:22.25  0:00:55.89  -566.35
                  ADABAS72  13:14:00.05  0:02:46.90  0:12:50.75   603.85
                  ADABAS71  13:29:00.09  0:01:40.57  0:08:55.19   434.61
                  ADABAS72  13:29:00.09  0:03:54.11  0:16:02.57   728.45
                  ADABAS72  13:44:00.04  0:03:32.12  0:16:39.49   787.37
                  ADABAS72  13:59:00.02  0:03:05.23  0:16:01.69   776.46
                  ADABSD72  14:14:00.07  0:02:48.06  0:15:40.71   772.64
                  ADABSD72  14:29:00.05  0:02:05.13  0:11:20.71   555.58
   Thanks to Meral Temel, Garanti Teknoloji, TURKEY.                    
Change 29.257  WMQGETTM was not divided by the 4096 factor needed for   
VMAC110        CICS 8-byte time durations, so it was a little too large!
Nov 17, 2011                                                            
   Thanks to Robert C. Crawford, USAA, USA.                             
Change 29.256  Change 29.120 revisions to ASUMVMXA were not included in 
ASUMVMXA       that change until today.                                 
Nov 17, 2011                                                            
Change 29.255  z/VM datasets VXSUMIOD and VXDEVTOT created by _SIODDEV  
VMACVMXA       were left in //WORK, and dataset macros _LSUMIOD/_LDEVTOT
VMXGINIT       were not defined nor were &PSUMIOD nor &PDEVTOT; all are 
Nov 16, 2011   now defined and used so they now default to //PDB.       
               _RPT36 was revised to use _LDEVTOT as its input dataset. 
   Thanks to Scott Barry, SBBWorks Inc, USA.                            
Change 29.254  IMF variable ARRVTIME has resolution to only one decimal 
VMACCIMS       place, but "newer" variable TRNARVTH time has two decimal
Nov 19, 2011   places, so ARRVTIME is now revised to use the DATE part  
               of original ARRVTIME but with TRNARVTH's value for TIME. 
   Thanks to Ken Jones, Xwave, CANADA.                                  
====== Changes thru 29.253 were in MXG 29.07 dated Nov 14, 2011=========
Change 29.253  Preliminary support for Velocity Software Version 4.1 has
VMACXAM        eliminated warning messages about new segments, and most 
Nov 14, 2011   new data fields are decoded, and this level set has been 
               validated with data records thru MXG's QA job stream.    
   Thanks to Douglas C. Walter, Citigroup, USA.                         
Change 29.252  The new SM120XP/SM120XZ times are in microseconds rather 
VMAC120        than the (strange) duration units that MXG decoded. Also,
Nov 14, 2011   the MXG code caused INVALID ARGUMENT messages if executed
               on ASCII; those fields had not been translated to EBCDIC 
               before they were used in the INPUT function.             
              -The undocumented SM120XZ field is the CPU time that has  
               been offloaded by WebSphere to zIIP engines, and it is so
               labeled now.                                             
   Thanks to Millard Stephens, FMR, USA.                                
   Thanks to Warren Cravey, FMR, USA.                                   
   Thanks to Raj Ramachandran, IBM, USA.                                
Change 29.251  Support for Demand Technology Performance Sentry NTSMF V4
EXNTDTSA       adds three new objects that create three new datasets:   
EXNTVMWA         dddddd   dataset   description                         
EXNTVWVS         NTDTSA   DTSALRTR  DTS.AlertRecipient                  
IMACNTSM         NTVMWA   VMWAREh   VMWARE                              
VMXGINIT      -Existing VMWARE objects were INCOMPATIBLY changed by the 
Nov 12, 2011   insertion of a separate field for the 2nd instance field.
               Previously a single field contained both instance values,
               separated by a '::', that MXG parsed in the two instance 
               variables.  MXG now detects NRNAMES=2 and uses separate  
               fields when they exist, but that new NRNAMES value causes
               error messages (and no observations output), if you read 
               NTSMF V4 (new)  records with MXG prior to 29.07.         
                 These segments have two fields stored for xxxxINST/INS2
                     VWGC VWHC VWGD VWHD VWGN VWHN VWHS                 
                 These segments have one field that is still parsed to  
                 populate the two xxxxINST and xxxxINS2 instances:      
                     VWGA VWHA VWGM VWHM VWGS                           
              -New variables xxxxVMHO (VM*HOST), xxxxCPU (CPU*NUMBER),  
               xxxxVMGU (VM*GUEST) are created from new fields added at 
               the end of many existing VMWARE records.                 
              -Many new variables were added to existing VMWARE datasets
               in Version 4, too many to list here, but you can find all
               in VMACNTSM after the text "ADDED BY CHANGE 29.251" in   
               the KEEP= list for all datasets.                         
Change 29.250  Windows SEVEN restricts writes to the root, program file,
VMXGPRNT       and other directories.  VMXGPRNT writes text/code to file
Nov 10, 2011   TMPPRNT and then %INCLUDEd TMPPRNT, but the MXG default  
               file C:\MXGTEMP.SAS was in the root directory, so it was 
               restricted from access.  The circumvention was to change 
               filename TMPPRNT to INSTREAM, which is the MXG ddname    
               specifically designed (and used internally by MXG) to    
               dynamically create SAS code and/or MXG macro definitions 
               "instream" and then %INCLUDE them.  TMPPRNT was never    
               needed, but the original contribution was left asis.     
                 FWIW: Even with the error, all datasets were printed;  
                 The error prevented the printing of the variable name  
                 along with its label, which is the ONLY reason you want
                 to use VMXGPRNT/VMXGPRAL, and why I saw the error, as  
                 I use VMXGPRAL all the time, especially to understand  
                 all of the variables in a new dataset I've just built. 
Change 29.249  TYPSXAM example to create and sort all datasets to PDB   
TYPSXAM        did not sort all fifty-six datasets.  The structure of   
Nov 10, 2011   MXG support for XAM is different because XAM has five    
               INFILEs that create fifty-six datasets.  Each infile has 
               a macro pair _TXAMfff and _SXAMfff where _TXAMfff reads  
               infile fff to create all fff datasets and _SXAMfff sorts 
               the fff datasets to the PDB.  But, the _SXAMfff macros   
               have not been updated in a long time so the newer XAM    
               datasets were not in the XAM PDB data library.           
               The simple resolution is to replace the five _SXAMfff    
               macro invocations in TYPSXAM with the _SXAM product sort 
               macro that sorts ALL of the XAM product's datasets (and  
               all of the _Sxxxx product sort macros are validated to   
               sort all datasets as part of MXG's robust QA jobstream). 
                 An additional problem is avoided: the _SXAMDEV token   
                 name is used for both the data set sort token and for  
                 the _SXAMfff "infile fff" token.  Using _SXAM and not  
                 using the _SXAMfff tokens avoids a major redesign and  
                 new (INCOMPATIBLE) naming conventions.                 
   Thanks to Debbie Mattos, Lockheed Martin, USA.                       
Change 29.248  INVALID ARGUMENT TO SUBSTR in SYSLOG IEC205I message text
VMACTMNT       in ASMTAPEE/MXGTMNT tape mount/syslog monitor SMF record.
Nov  9, 2011   Parsing to INPUT the mmm after TOTALBLOCKS=mmm into the  
               SYSLBLKS variable in TYPESYMT dataset expected 16 bytes  
               and failed when there were fewer characters for mmm.  Now
               the parse stops at the first blank character.            
                  This change in format of the IEC205I message occurred 
                  after PTF UA90604, in APAR OA90604, which included    
                  IFG0194J, which contains message IEC205I.             
                  The prior PTF level was UA60149.                      
                  APAR OA38051 now documents:                           
                    Unnecessary information on the third line of IEC205I
                    Characters *HAS will appear after spaces            
                  and it was these unexpected characters instead of     
                  blanks that led to this MXG circumvention change.     
   Thanks to Clayton Buck, UniGroup, USA.                               
Change 29.247  Support for ZEN FERRET, ZEN IMPLEX and ZEN OSA user SMF  
EXFERSAW       records from William Data Systems GmbH products.         
EXZOSAEV      -VMACMPLX - ZEN IMPLEX V5.1 adds two new variables        
IMACFERT       header (COMPATIBLY) and those variables are kept in all  
IMACZOSA       ZEN IMPLEX datasets.                                     
VMACFERT      -VMACZOSA. Support for ZEN OSA MONITOR V1.3 SMF record,   
VMACMPLX       creates TYPEZOSA dataset with separate observations for  
VMACZOSA       each value segment in each SMF record.  All four subtypes
VMXGINIT       (CHAN,LPAR,I/O,QUEUE) have the same record structure with
Nov 10, 2011   a fixed suite of OSA descriptors and one or more value   
Dec 16, 2011   segments; MXG creates a separate observation for each of 
               the value segments in each SMF record. Variable ZOSARESC,
               the resource name is EBCDIC text in the I/O and QUEUE    
               record, but because it is a hex string in the CHAN record
               it's value is instead kept in variable ZOSARESH.         
              -VMACFERT.  Support for ZEN FERRET V2.3.  INCOMPATIBLE.   
               -Datasets FERRETCP, FERETEE, FERETRT datetime field was  
           1    changed from mm/dd/yy to ddMONyy, so prior MXG versions 
                will fail due to this INCOMPATIBLE change.              
               -Two new fields have been added to the RTP and CP data   
                section, a flag byte which indicates the type of history
                and a field showing the transmission priority.          
               -Support for new Session Awareness Section creates new   
                FERRTSAW dataset, although some minor issues have just  
                been opened.                                            
                -The key section for SAW has PLU and SLU, but those     
                 fields are also in the data segment                    
                -Offset value to SAW is 106, but segment starts in byte 
                 109; the offset value should be 112, and three less to 
                 get to the SAS byte location of that offset.           
   Thanks to Bruce Sloss, PNC Bank, USA.                                
   Thanks to Ronald Delp, PNC Bank, USA.                                
Change 29.246  If a filename in macro variable &PDB had a DASH, this    
BLDSMPDB       compiler error was caused when %UPCASE(&PDB) was used:   
Nov  8, 2011    "ERROR: A character operand was found in the %EVAL      
                 function or %IF condition where a numeric operand is   
                 required. The condition was: %upcase(&runday) eq       
                 %upcase(&pdb) and %length(&rerun) ne 0 "               
               because that DASH was not "masked" and was thus seen as  
               a mathematical minus and not a part of the filename.     
               This is obscure, to say the least, but SAS documents that
               neither %UPCASE() nor %STR() macro functions mask special
               characters, and that %QUPCASE() should be used instead.  
               But in this specific test, the UPCASE() was never needed 
               as both arguments were previously LOWCASED() which DOES  
               mask special characters.  But the &RUNDAY EQ &PDB test   
               cannot be used because that dash will still look like a  
               minus sign, so the circumvention/re-design now uses      
               IF %QUOTE(&RUNDAY) EQ %QUOTE(&PDB) to mask the DASH and  
               successfully compile.                                    
   Thanks to Mitchell Loren, Los Angeles County Education, USA.         
Change 29.245  Change 29.195 added a test TMSCTL=:'TMSCTL#' to protect  
VMACTMS5       when a non-TMC file is read, but that PoundSign was not  
Nov  8, 2011   recognized with some character sets, so the test is now  
               shortened to TMSCTL='TMSCTL' to avoid a false positive.  
   Thanks to Akre Trond Maurita, EDB, NORWAY.                           
Change 29.244  Support for TMON/CICS V3.3 (mostly COMPATIBLE) TCE data. 
VMACTMO2      -TMON/CICS V3.3 increased MRO's TAMRSYID field from 4 to 8
Nov 10, 2011   bytes, to hold the IPIC CONNID.  Unfortunately, while MXG
               does use segment length to keep aligned with each of the 
               repeated MRO segments, inserting 4 bytes (instead of new 
               8 bytes at the end) shifts/trashes the TAMRxxxx variables
               in the MONIMRO dataset due to this INCOMPATIBLE change,  
               but there are no error messages nor condition code set,  
               so V3.3 is INCOMPATIBLE ONLY IF YOU USE MONIMRO dataset; 
               MXG Version 29.07 is required for V3.3 only for MONIMRO. 
               And, fortunately, MONIMRO is very rarely used in reports.
               TMON records with earlier MXG versions will not cause    
               errors nor ABENDS, just bad data in one seldom used      
              -TAMRFLG1 and TAMRFLG2 fields are listed in V3.3 as new   
               but were previously input and kept in MONIMRO dataset.   
              -The DSECT for the header showed an optional, inserted    
               40-byte extended-common-header segment, that would have  
               made all V3.3 records incompatible, but, fortunately,    
               that segment will NOT exist in V3.3 records.  And, more  
               fortunately, MXG is updated to support its existence, so 
               if/when it appears in a future record, it won't be an    
               incompatible change.                                     
Change 29.243  Calculation of ESTSCP1M had (0.57*(0.1*RNI)) but that was
ASUM113        a typo, now corrected to    (0.57+(0.1*RNI)). MXG's error
VMAC113        caused very small values in ESTSCP1M.                    
Nov  2, 2011                                                            
   Thanks to Dave Cogar, Wells Fargo Bank, USA.                         
Change 29.242  ONLY if executing MXG on ASCII, and ONLY if MXG default  
VMAC102        option COMPRESS=YES was changed to COMPRESS=NO (which    
Nov  1, 2011   causes SQL text to be broken into 100 byte chunks that   
Nov  3, 2011   are output in dataset T102T14x instead of T102S14x), the 
               DB2 Audit variables QW0140TX,QW0141TX,QW0142TX,QW0145TX  
               were only readable text in the last segment or if there  
               were less than 100 bytes of SQL text, because MXG's logic
               for this "chunking" algorithm was written long ago and it
               was only validated back then on z/OS.  MXG INPUT those   
               fields with $EBCDIC100, but that INPUT should have been  
               with $CHAR100, and then the INPUT function with $EBCDIC  
               informat does that translation to readable text.         
               And variable QW0124T's INPUT was also corrected.         
   Thanks to Lars Fleischer, SMT Data, DENMARK.                         
   Thanks to Jorgen Lund, SMT Data, DENMARK.                            
Change 29.241  The example to split SMF records into 5 groups output DB2
JCLSPLIT       ID=102 records in "B" DB2 output file, and then failed to
Oct 28, 2011   add 102 to the NOTYPE list in the "E" group (ALL OTHER), 
               so all 102s were output in both "B" and "E" output files.
               The 102 is now added to the NOTYPE list in "E".          
   Thanks to Jennifer D. Ayers, WVOT Data Center, USA.                  
Change 29.240  The length of new variable SM1209FH could not be changed 
VMAC120        as described in Change 29.081.  That text was rewritten. 
Nov  8, 2011                                                            
Change 29.239  Variable SHIFT (also used as "ZONE") is now created in   
VMAC7072       all of the RMF datasets, from STARTIME.                  
Oct 27, 2011                                                            
   Thanks to Frank Lund, EDB ErgoGroup, NORWAY.                         
Change 29.238  Change 25.142 and Change 28.211 identified USER SMF      
VMACARB        VMAC's using "MACRO _xxxxID nnn%" instead of "MACRO      
VMACDLMN       _IDxxxx nnn%" but those changes did not revise those     
VMACDMON       members to use the more-recent-and-preferred  _IDxxxx    
VMACHURN       syntax.  All VMAC's are now updated to support both forms
VMACM204       of the _ID macro to tell MXG what SMF record number to   
VMACNSPY       process as product xxxx, but only to be consistent, just 
VMACPDSM       in case we needed to generate them internally in MXG.    
VMACRMDS       Note that using UTILBLDP is recommended to read multiple 
VMACROSC       SMF records, and by using it's USERADD=xxxx/nnn argument 
VMACRTE        set the SMF IDs, you do not need the _ID definitions in  
VMACTSOM       your IMACKEEP tailoring.                                 
VMACVVDS      -But some inconsistencies in _IDxxxx macron names exist:  
VMACWYLA        Arbiter can write each of its subtypes with a separate  
VMACWYLB         SMF record ID (_IDARB00-IDARB0C).                      
VMACX37         VMACM204 has _IDM204L and _IDM204S for Log/Since-Last.  
Oct 26, 2011    VMACTSOM has _IDTSOMC and _IDTSOMS for Command/System.  
                VMACHSM  has _IDHSMDS and _IDHSMD1 for Daily/FSR Stats. 
                VMACHBUF was in 25.142 but had been updated to _IDHBUF. 
                VMACWYLB was in 25.142 but had been updated to _IDWYLB. 
Change 29.237  The calculation of ZIPUSED and ZIEUSED did not include   
ASUMMIPS       the divide by CAPZIPRT*100.                              
Oct 24, 2011                                                            
   Thanks to Bernhard Bablok, Allianz Managed Operations, GERMANY.      
Change 29.236  SMFSRCH is a VERY slick new tool to print all SMF records
COMPALL        that contain a specific "LOOKFOR" character text string. 
COMPALLN       All SMF records are scanned for the "LOOKFOR" text       
SMFSRCH          - using IF INDEX(_INFILE_,"LOOKFOR") syntax -          
TYPESMF        and selected SMF records are written to the temporary    
VMXGGETM       DDNAME/filename of MXGTEMP, from where TYPESMF program   
VMXGPRAL       reads them to create every possible MXG dataset that can 
VMXGSRCH       be built from SMF records, including "USER" SMF records. 
Nov 11, 2011   Then, ONLY the observations in those datasets that have  
               a variable containing the "LOOKFOR" text are printed.    
                (This extra filtering is needed because some datasets   
                 created from the selected records won't contain that   
                 "LOOKFOR" text.  Consider if LOOKFOR=USERID, TYPE 30-4 
                 records with that USERID will be selected and TYPE30_D 
                 dataset will have many observations, one per DD name,  
                 but the USERID field is not kept in dataset TYPE30_D,  
                 so this final filtering prevents those unwanted "false 
                 positive" observations from being printed.)            
               The selected SMF records can be kept by making //MXGTEMP 
               a permanent dataset, and the selected MXG-created SAS    
               datasets can also be kept.                               
              -The //MXGTEMP DD may need to be added to your JCL.       
              -SMFSRCH creates all possible datasets that can be created
               from IBM or USER SMF records.  IBM fixed-numbered records
               are automatically output, but only the USER SMF records  
               that have a "MACRO _IDxxxx nnn % definition in IMACKEEP  
               or in IMACxxxx will create observations (BUT: you can use
               the USERADD=xxxx/nnn argument to tell MXG the nnn you use
               for product xxxx and those datasets can be populated).   
              -SMFSRCH reports the counts/sizes of SMF records input and
               selected, and maps USER SMF records to their product if  
               the_IDxxxx macro was found.                              
              -New parameters added to VMXGGETM, used in new SMFSRCH:   
                BEGTIME= earliest datetime to be selected               
                ENDTIME= latest   datetime to be selected               
                INCODE=  A stub of code executed after the header       
                         is read                                        
                LOOKFOR= text string to be searched in each SMF record  
              -TYPESMF executes all TYPExxxx member that read any SMF   
               records, reading SMF once for each TYPExxxx member, so   
               it is only used in SMFSRCH to read the selected records. 
              -VMXGPRAL's TITLE "PRINT OF FIRST MAX OBS.." corrected.   
   Thanks to Jeffrey Dyke, USDA, USA.                                   
Change 29.235  Change 29.125 (MXG 29.05-29.06) corrected DB2 IFCID=22   
VMAC102        error with DB2 V10, but did not work for DB2 V9.  And, in
Oct 19, 2011   testing this update the T102I022 dataset was found to be 
               in serious need of realignment.                          
   Thanks to Tom Buie, Southern California Edison, USA.                 
Change 29.234  Cosmetic.  Messages that EXCLUDED FIELDS are revised to  
VMAC110        print the value of the triplets (dictionary records) that
Oct 19, 2011   are defined in your IMACEXCL tailoring, to make it easier
               to see that your UTILEXCL missed a dictionary record.    
Change 29.233  Support for BETA93 Version 4.1.0: Subtype 25 was changed,
VMACBETA       with fields removed, causing wrong or missing values in  
Oct 18, 2011   dataset BETA25, plus INVALID DATA FOR BETASTRT messages. 
               These variables are now missing/blank with 4.1.0:        
               Additionally, missing value messages for some datetimes  
               are circumvented by testing DATE GT 0 before calcs.      
   Thanks to Michael Brenning, Finanz Informatik, GERMANY.              
Change 29.232  DFSORT variables ICEMNVLX,ICEMNVLY, and ICEMNVLZ are not 
VMAC16         documented as to their units, but data shows they are in 
Oct 15, 2011   KB and not Bytes, so they are now multiplied by 1024 to  
Oct 25, 2011   convert to bytes, and then so MGBYTES format will print  
               16M rather than 16K previously printed. IBM has privately
               verified that the units are 16M and plan to update their 
               DFSORT documentation to show the units attribute.        
   Thanks to Neil Ervin, Wells Fargo Bank, USA.                         
Change 29.231  Support for Axway CFT/ESA (Cross File Transfer) two SMF  
EXAXWAY        record formats ("2.3" and "2.4" but "2.3" format records 
FORMATS        (8-byte vs 32-byte fields) are created/creatable with the
IMACAXWY       current CFTMON 2.6.4.  As there is no version number and 
TYPEAXWY       the two records have same length, three one-byte fields  
TYPSAXWY       that must be blank in 2.4 are used to identify version of
VMACAXWY       the record.  The 2.4 code with 32-byte fields is INPUT   
VMXGINIT       first so the kept variables will be the longer length.   
Oct 15, 2011                                                            
Nov 17, 2011                                                            
   Thanks to Richard Wendland, US Bank, USA.                            
   Thanks to Claude Breault, Centre de Services Partages Quebec, CANADA.
Change 29.230  Comparison of BMC IMF FA and IBM 56FA IMS Log records.   
ASUM56FA      -Variable IMSRECCH added to CIMSTRAN to capture that IMS  
EXIMS56C       log sequence number at the end of each IMS log record; it
FORMATS        was already in IMF56FA.  In TYPECIMS variable IMSRECNR is
IMACIMS        the _N_ sequence number and is NOT input from the record.
TYPEIMST      -IMS56FA records are written as pairs for a single IMF FAx
VMACCIMS       log record. The pair have the same ARRV and STRT times,  
VMACIMS        and are written 5 milliseconds apart at transaction end. 
VMXGINIT      -See the new IMS Technical Note in NEWSLETTER FIFTY-NINE  
Oct 11, 2011   for a detail explanation of what is captured in IMS56FA  
Oct 21, 2011   transaction event records, and a comparison with IMF.    
Oct 27, 2011  -ASUM56FA program (still in testing) is added to MXG.     
Change 29.229 -Variable TPMCA7JN is now input &PIB.2. + 2 versus &PIB.4.
VMACTPMX      -Variable TPMPI was decimal 243 for 'F3'x which is EBCDIC 
Oct 11, 2011   numeric/character three. INPUTing TPMPI as $EBCDIC1 would
Oct 15, 2011   create a character variable with value '3', but TPMPI is 
               a numeric variable, so the field into TPMPICH $EBCDIC1., 
               but then TPMPI=INPUT(TPMPICH,1.); will preserve TPMPI to 
               remain a numeric variable, but with value 3 versus 243.  
              -Datetime variable TPMDUEOT is now correctly populated but
               that variable can have a missing value.                  
   Thanks to Tren Csuy, Humana, USA.                                    
   Thanks to Scott Barry, SBBWorks Inc, USA.                            
Change 29.228  Variables SMF30SNF and SMF30ZNF, the zAAP and zIIP       
BUILD005       factors that were used to normalize those Engine's CPU   
BUIL3005       time are now kept in PDB.JOBS.  This updates Change      
Oct 11, 2011   28.139.                                                  
Nov 17, 2011   Nov 17:  (DROP=_26NJE) was added to DATA TYPE26J2 to     
               ensure dropping of those NJE variables from PDB.JOBS,    
               if those variables were still somehow in SPIN26.         
   Thanks to Jim S. Horne, Lowe's Companies, USA                        
Change 29.227 -Revised code to read HP MeasureWare NT records with new  
VMACMWNT       fields added in GLOG record:                             
Oct  8, 2011      PKDSKPCT='PEAK*DISK*PERCENT'                          
               and with the MXG code restructured to match the changed  
               fields in the REPORT command used to extract the data.   
              -DDMMYY8 format revised to DDMMYY10 for those dates.      
   Thanks to Frank Tonneau, KBC Global Services NV, BELGIUM.            
   Thanks to Geert Debatselier, KBC Global Services NV, BELGIUM.        
VMAC1415       could print for a record without an Extended Segment. MXG
Oct  7, 2011   code now tests SMF14XSG first to validate existence.     
   Thanks to Herbert Sweeney, Verizon Data Services, USA.               
Change 29.225  INVALID THIRD ARGUMENT OF SUBSTR message and hex dump of 
VMACDB2        the record was caused by DB2 V10 record with INVALID QMDA
Oct  7, 2011   segment for QMDAPTYP='JCC' - invalid because it does not 
               match the DSNDQMDA DSECT in the DB2 Macro Library.  Now, 
               the first three records are detected and MXGWARN messages
               are printed on the log, while a PMR will be opened.      
   Thanks to Kim Morrell, RCMP, CANADA.                                 
Change 29.224 -Utility VMXGGETM selects SMF records for counts or to be 
VMXGGETM       written, and is enhanced with new arguments SYSTEM=,     
Oct  3, 2011   BEGTIME=, and ENDTIME=, to select SMF records by SYSTEM  
Oct 24, 2011   and/or ranges of SMFTIME values.  This could alternately 
               be done with the powerful but obscure %LET MACFILE= logic
               (the "instream" equivalent of IMACFILE EDIT tailoring).  
              -LOOKFOR=text, added: selects SMF records with that text. 
   Thanks to Chuck Hopf, Independent Consultant, USA.                   
Change 29.223  Support for APAR OA37114, ITRF (OMEGAMON IMS V420 TRF)   
VMACITRF       TRFOUT record adds five new variables (COMPATIBLY) that  
Oct  2, 2011   are output in MXG dataset ITRFMSG.                       
                  MI      ='SPA*INDICATOR*PSTMI'                        
                  MSRC    ='MESSAGE*SOURCE*FLAG*PSTFLAG1'               
                  SCHF1   ='QUICK*SCHEDULED*PSTSCHF1'                   
                  SPAL    ='CURRENT*SPA*SIZE'                           
                  VSFLG   ='PRIMED*MSG*INDICATOR*PSTVSFLG'              
Change 29.222  New tokenid values are now decoded in TYPE80A:           
VMAC80A           TOKMEMLI='MEMLIMIT'                                   
Oct  2, 2011      TOKSHMEM='SHMEMMAX'                                   
               These "NO" value tokens have no data values so they are  
               output in TYPE80TK with their TOKDANAM to record that the
               option was in effect, suppressing a NOT DECODED message: 
                 NOMMAPAREAMAX NOASSIZEMAX                              
   Thanks to Angelito Lontoc, Northern Territory Government, AUSTRALIA. 
Change 29.221 -CICS Statistics dataset CICDB2GL fields that were not    
FORMATS        identified as new were overlooked, but are now added:    
VMAC110           D2GPSIGN='PARTIAL*SIGNONS'                            
Oct  3, 2011      D2GCTHCR='COMD*THREAD*CREATES'                        
Oct 16, 2011      D2GPTHCR='POOL*THREAD*CREATES'                        
              -Statistics Dataset CICSMDSA variable SMSDSAIN indexes the
               type of DSA, but values of '00'x have been found for RDSA
               EUDSA, and ERDSA, so the SMSDSANM (DSA Name) is used to  
               set their value in SMSDSAIN to '04'x, '86'x, and '08'x   
               when '00'x is found, and the FORMAT $MGCICDS (which maps 
               SMFDSAIN to the name of the DSA) is updated with values  
               '09'x (ECDSA), '8D'x (GCDSA) and '7F'x (ESDSA) that were 
               undocumented in the CICS Data Areas.  Variable SMSDSAIN  
               existed before variable SMSDSANM, the actual DSA Name, so
               with these undocumented and '00'x values in SMSDSAIN, the
               variable SMSDSANM should be used instead of SMSDSAIN to  
               identify which DSA name is being reported in CICSMDSA.   
              -The CICSMDSA variables for "ABOVE THE BAR" storage were  
               wrong; they are in (undocumented, but now obvious) units 
               of 1 GB, so they are now converted to bytes and formatted
               with MGBYTES to print the correct storage values:        
               NOTE: ABOVE WRONG, THEY ARE IN MB NOT GB. CHANGE 30.094. 
                These variables are DSA-specific and corrected:         
                These variables are in the header of the CICSMDSA record
                and thus repeated in each observation for the interval, 
                but are also corrected:                                 
                 SMSGDCUL SMSGDHWL SMSGDCUR SMSGDHWM                    
   Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.  
Change 29.220  Support for z/OS 1.13.  REQUIRES MXG 29.03 or later.     
VMAC7072      -VMAC7072.  IBM now stores 'FF' character ('C6C6'x !) for 
VMAC71         the CPUID (SMF70CID) for engines that don't exist in the 
Mar 24, 2011   CPU Data Section, which MXG saw as 50886 decimal, which  
VMAC23         caused ARRAY SUBSCRIPT OUT OF RANGE error.  MXG logic    
Apr  2, 2011   relocated the initialization of the two arrays that used 
VMAC113        CPUID as the subscript, and created a DO group to only   
VMAC6          process the CPU Data Sections with valid CPUID number.   
VMAC42        -VMAC71.  TEST for OFFSWAP GE 0 AND NRSWAP GE 0 caused    
VMAC64         INPUT STATEMENT EXCEEDED.  That test should have been GT 
Sep 30, 2011   for a long time (since SWAP datasets went away!!).       
               Accidentally didn't fail with prior z/OS but was wrong.  
               Cosmetic: SWAPAUX calculation was moved back inside the  
               DO group for (now non-existent) SWAP counts so that it   
               doesn't cause a Missing Values message.                  
              -VMAC23.  Two new triplets are decoded, for the new Spin  
               Lock and Bind Breakdown Instrumentation sections, but    
               both are currently "For Internal Use Only".              
              -VMAC6. The Reserved 16-bytes in SMF6INDC=7 Extended Mode 
               segment contains SMF6IPV6, currently just input and not  
               kept nor decoded.  SMF6URIL, added by OS25152 is not in  
               the Pre-GA SMF Manual.                                   
              -VMAC42. New variables added to several datasets:         
                 SMF42GRU='READ REQS*RETRIED FOR*CASTOUT*LOCKS'         
                 SMF42GRJ='READ REQS*RETRIED FOR*CASTOUT*LOCKS'         
                 SMF42JQ2='READ REQS*RETRIED FOR*CASTOUT*LOCK'          
                 SMF42JRC='READ REQS*RETRIED FOR*CASTOUT*LOCKS'         
                 SMFA2JQ2='READ REQS*RETRIED FOR*CASTOUT*LOCK'          
                 These fields were added by APAR OA30300.               
              -VMAC64. New variable added to TYPE64:                    
              -VMAC7072. New ID=72 Subtype 5 adds 13 new datasets:      
                dddddd  Dataset   Description                           
                TY725A  TYPE725A  RMF III SERIALIZATION DELAY           
                TY725B  TYPE725B  RMF III CMS LOCK DELAY                
                TY725D  TYPE725D  RMF III CMS LATCH LOCK DELAY          
                TY725E  TYPE725E  RMF III CMS SMF LOCK DELAY            
                TY725F  TYPE725F  RMF III LOCAL LOCK DELAY              
                TY725G  TYPE725G  RMF III CML LOCK OWNER DELAY          
                TY725H  TYPE725H  RMF III CML LOCK REQUESTOR DELAY      
                TY725J  TYPE725J  RMF III GRS LATCH REQUESTOR DELAY     
                TY725K  TYPE725K  RMF III GRS ENQUEUE STEP DELAY        
                TY725L  TYPE725L  RMF III GRS ENQUEUE SYSTEM DELAY      
                TY725M  TYPE725M  RMF III GRS ENQUEUE SYSTEMS DELAY     
              -VMAC7072. New variables added to TYPE70XT dataset:       
                 R7023CRT='EXEC TIME*ALL OPS*4096-BIT*CRT-FMT'          
                 R7023CRC='NUMBER OF*ALL OPS*4096-BIT*CRT-FMT'          
              -VMAC71.  New variable added to TYPE71:                   
               All Logical Swap and ESTORE variables are now reserved.  
              -VMAC113. New variables added to TYPE113                  
Change 29.219  Support for Tivoli Workload Scheduler For z/OS Ver 8.3 is
FORMATS        completely incompatible with numerous changes to many of 
IMACOPC        the tracklog file's records.                             
VMACOPC       -The _OPCVER macro is no longer used, since this update   
Sep 24, 2011   supports the current version.  However, it may have to   
Sep 27, 2011   be reinstated in the future since IBM still does not     
Nov 14, 2011   provide the version number in each record.               
              -There are numerous instances in different MT0TYPE records
               that end with a 4-byte field of hex zeros where the next 
               MTDTYPE/MTDOPER pair were expected. Probably APAR-able,  
               but it was more expeditious to detect and delete them in 
               MXG than to take the time to document them for a PMR.    
              -Invalid TRL 29 record caused INVALID ARGUMENT messages;  
               the internal %DT macro now tests the incoming arguments  
               and if the date or time is missing, RETURNs, preventing  
               those cosmetic messages.  With or without those messages 
               the date values returned were and are missing values.    
              -Nov 14:                                                  
                 This is not a used record type so the error will not   
                 be pursued until a customer who actually needs this    
                 record type raises the issue.                          
              -There are one new MTD segment, MTDTYPE=16 that is not    
               not documented in SC32-1261-03.                          
              -MTD17 segment is decoded.                                
   Thanks to Louis Deledalle, BNP Paribas, FRANCE                       
Change 29.218  Variable CNT30REC is added to PDB.STEPS dataset to count 
BUILD005       the number of physical SMF 30 records created for this   
BUIL3005       step (which were all consolidated into this observation).
Sep 22, 2011                                                            
Change 29.217  Corrected and improved support for the RCDSD section in  
ASMRMFV        RMF III RCD data is provided.                            
VMACRMFV      -ASMRMFV now correctly calculates the length of the RCDSD 
Sep 20, 2011   array that before could cause a SAS INPUT LENGTH ERROR in
Sep 27, 2011   VMACRMFV processing.                                     
Nov  2, 2011  -ASMRMFV now correctly handles an RCDSD when a Class with 
Nov 20, 2011   zero periods is detected.  An RCDSD cannot exist in this 
EXZRBRCP       case because the RCDSD pointer is part of the period data
NOV 13, 2013  -VMACRMFV formats for the variables RCDRGCAP and RCDRCGD  
               were reversed.                                           
              -New variables RCDBPMI and RCDSDPH are added to the       
               ZRBRCDD file by VMACRMFV.                                
              -VMACRMFV now reads both the Begin-To-End and Execution   
               Phase data for each RCDSD entry.  Current documentation  
               for RMF III did not clarify that each RCDSD entry is     
               actually a pair of arrays for these two Phases.          
              -ASMRMFV when processing a CFI Table with the RMF III     
               CFDETAIL option in effect, did not correctly handle the  
               condition where no connections exist for a CF Structure. 
               This resulted in a corrupted CFI Table record and an SAS 
               INVALID DATA message during VMACRMFV processing.         
              -When the number of records output for a RMF III table    
               exceeded 16,277,215 the output record counter in ASMRMFV 
               would wrap to zero resulting in a very low incorrect     
               count for that table type.  The total record count output
               by ASMRMFV would then not match the input record count   
               from VMACRMFV.                                           
              -VMACRMFV did not count the 4 byte RDW (Record Descriptor 
               Word) in its report of bytes read but ASMRMFV did. Now,  
               the RDW length is added so that the VMACRMFV byte count  
               matches the ASMRMFV byte count.  However, as neither     
               ASMRMFV nor VMACRMFV knows how many blocks were written, 
               both byte counts will not include the 4-byte BDWs (Block 
               Descriptor Word) for each block.                         
              -The RMF Monitor III version id variable names are now    
               more consistent with the naming pattern of xxxVERG3.     
               RCDVERS is now RCDVERG3 (RCD version id).  OPDVER is now 
               OPDVERG3 (OPD version id).  SPGVER is now SPGVERG3 (SPG  
               version id).                                             
              -A new variable SVPRTC (Response Time Unit Code) is added 
               to files with Service Policy data.  It is the decoded    
               value of SVPRTU.  This indicates the response time units 
               for a goal.  Values are I=Milliseconds, S=seconds        
               M for Minutes, H for Hours, and ? for Unknown.           
              -Added SPACE/NOSPACE parameter option:                    
               -SPACE displays two new messages RMFV030I and RMFV031I   
                for each RMF Monitor III VSAM data set processed.       
               -Message RMFV030I shows HARBA (High Allocated Relative   
                Byte Address), HURBA (High Used Relative Byte Address), 
                and AVAIL (Available Free Space in Bytes).              
               -Message RMFV031I shows percent of Allocated Space Used  
                and percent of Allocated Space Available (Free).        
               -Both standard & extended format (EF) VSAM data sets are 
                supported, but RMFV030I message format varies slightly  
                to accommodate the much larger data sets possible in EF 
               -Assembler symbolic variable &SPACE can be changed by    
                users prior to assembly from the distributed default of 
                'Y' (SPACE in effect) to 'N' (NOSPACE in effect).       
               -In conjunction with the existing INDEXES parameter SPACE
                is intended to assist MXG users in properly sizing their
                RMF Monitor III data sets.                              
               -Program prologue comments documentation was updated.    
              -Nov 20, 2011:                                            
               Change 29.204 (29.05) changed these version variables    
                 OPDVERG3 SPGVERG3 CPUVERNU SVPDVN   SVPRTU             
               from NUM to CHAR, which would create errors combining    
               PDBs built with different MXG Versions, so they are now  
               changed back to their original numeric nature.  This code
               change was NOT in MXG 29.07 dated Nov 14.                
              -Nov 13, 2013:  Exit member EXZRBRCP is no longer called  
               as ZRBRCP dataset is no longer output, because ZRBRCS and
               ZRBRCR now include ZRBRCP variables.                     
   Thanks to Neil Ervin, Wells Fargo Bank, USA.                         
   Thanks to Dan Case, Mayo Clinic, USA.                                
Change 29.216  Cosmetic.  The comment in JCLIMSL6 that two %LETs are    
JCLIMSL6       needed to set MACKEEP with _IMSVERS was wrong, as it is  
TYPEIMSB       only in the STEP04 step that the _IMSVERS must be set.   
Sep 19, 2011   In TYPEIMSB, the %INCLUDE of VMACIMS and IMACKEEP and    
               the comment "to get _IMSVERS" was removed because that   
               program has no dependency on any of the IMS macros.      
   Thanks to Trevor Ede, HP, NEW ZEALAND.                               
Change 29.215  Variables T119STCK, TISSTCK and TIESTCK weren't converted
VMAC119        from GMT to LOCAL, but now are.                          
Sep 19, 2011                                                            
   Thanks to Robert Stoffregen, Great Lakes Higher Education Corp., USA.
Change 29.214  Almost cosmetic. In subtype 2 (TYPE78PA dataset) eight   
VMAC78         variables ending with TOTL were mislabeled as samples but
Sep 19, 2011   they are the total memory for all samples, so they are   
               now correctly labeled and added to MGBYTES format to show
               they contain memory values. Variables LGMOMIN/TOFRMIN are
               RB8 floating point fields, but they can contain hex value
               7FFFFFFFFFFFFFFFx (presumably on systems that don't have 
               large memory frames), so they are now set missing (rather
               than decimal values 7.237E75!).  Some datetimestamps are 
               no populated (hex zeros for TODSTAMP8), so they are set  
               to a missing value (automatically, by SAS).              
   Thanks to Tony P. Steward, CSC, ENGLAND.                             
Change 29.213  Support for DB2 V10 IFCID 225 (Subtype=4) INCOMPATIBLE.  
CLEARDB2       The IFCID 225 record contains important storage metrics, 
EXDB2225       and is written each statistics interval.  In DB2 V8, it  
READDB2        was a trace record (ID=102,IFCID=225), creating T102S225 
VMACDB2        dataset. In V9, it became a statistics interval record   
VMXGINIT       (ID=100,SUBTYPE=4) creating DB2STAT4 dataset, but with   
Sep 20, 2011   the same suite of 8-byte field/MXG-variable names, and   
Sep 23, 2011   because it was then recognized as useful, those QW0225xx 
               variables were added transparently into PDB.DB2STATS from
               either DB2 V8 T102S225 or DB2 V9 DB2STAT4 datasets.      
               But now, DB2 V10 completely and incompatibly restructured
               (but also significantly enhanced the storage metrics) in 
               the IFCID=225 record, still writing it as SUBTYPE=4, with
               some fields preserved, but with many new fields with long
               names, that I now use for MXG variable names, rather than
               struggling to create unique two-character suffixes and   
               8-byte names (but two new prefixes are needed for the new
               separate storage used by DBM1 & DIST address spaces, so  
               those sets of variable's names are QWA225xx/QAB225xx.    
              -For DB2 V10, IFCID=225 records are output in PDB.DB2ST225
               dataset, and all variables in DB2ST225 are automagically 
               merged into PDB.DB2STATS dataset with all these programs:
              -With DB2 V10, the PDB.DB2STAT4 dataset will have zero    
               observations from DB2 V10 data, since it is populated    
               only from DB2 V9 IFCID=225 records.                      
              -Test data from the same DB2 Subsystem (QWHSSSID), when   
               the release changed from V8 to V10, had negative CPUTM in
               that statistics interval, because there is no field in a 
               DB2 Header that clearly identifies when a DB2 subsystem  
               is started (i.e., unlike CICS records, that have the JOB 
               and READTIME). Normally, a restart resets QWHSISEQ to a  
               smaller value, but in this case, that sequence number was
               larger in the V10 record than the prior V8 record!  So,  
               MXG now tests both QWHSISEQ and SEQCHECK to circumvented 
               the IBM omission.  That SEQCHECK test in the "bad" data  
               interval did identify the problem, so the previous test  
               of SEQCHECK GT 0 was enhanced to 0 LT SEQCHECK LE 5 to   
               confirm the inteval is valid with no restart.            
   Thanks to Betty Wong, Bank of America, UDS.                          
Change 29.212  Invalid JES3 JMF SMF 84 Subtype 1 Segmented Records.     
VMAC84         After long discussions with JES3 SMF 84 Support Folks, I 
Sep 16, 2011   understand how JMF creates multiple, segmented records   
Oct 11, 2011   when there are more entries (FCTs) that will fit in one  
               SMF record.  I can probably circumvent the absence of the
               JMF PROD section (source of start/end times!) that is NOT
               written in the 2nd and subsequent segments, but ONLY if I
               add post-processing steps to sort and to populate those  
               missing values, and ONLY if there are no missing segments
               in the SMF file.                                         
              -BUT, there is NO WAY that I can directly process each of 
               these segmented records, because sections (FCT ENTRY) are
               truncated and split (a/k/a "spanned" in JES3 circles) and
               written in two separate physical SMF records, but there  
               are no length fields to identify how many bytes were in  
               which record.                                            
              -Processing these JMF segmented records will require a new
               MXG design, to first reconstruct legitimate VB records   
               without truncated sections, and then process those SMF   
               records in a separate process. I get to do this because  
               IBM regards this as "working as documented".             
              -But, fortunately, JMF records are not typically created  
               every day; they tend to be turned on and then off for a  
               study, so we can live with waiting a day to process all  
               of the JMF records from a study.  And, this one very     
               small glitch in just one part of one subtype of the VERY 
               comprehensive JES 3 Monitoring Facility is now bypassed, 
               so all the rest of the JMF datasets are fully usable,    
               all of the other segments of this subtype 1 record, and  
               even those first 78 FCT entries are output; MXGWARN notes
               on the SAS log alert you there were FCT segments missed. 
              -The specific case investigated: There were more FCT than 
               would fit in one SMF record. FCT entries are variable    
               length sections with many optional subsections.  JMF     
               created 4 physical SMF records, segment numbers 1-4:     
               -The First segment has JMF PROD, JMF GENE, R84JES3O and  
                R84IRBSC offsets populated and has no FCT entries.      
               -The Second segment doesn't have JMF PROD nor JMF GENE   
                (needed for Interval Start and End times), and has only 
                R84FCTO, which points to a valid FCT "Header" section   
                (but R84FAWLN is the TOTAL length of all FCTs, and in   
                R84FCTN=250 is the total count of all FCTs in all segs; 
                what's needed here is how many FCTs are in THIS record! 
                This second segment then contains 78 complete FCT entry 
                sections, with R84FSEQN 1 thru 78, but then, only the   
                first part of FCT number 79 was written in this SEGNR=2 
                SMF record: the last 72 bytes were truncated.           
               -The Third segment also has no JMF PROD nor GENE sections
                and does NOT contain an FCT Header section; it contains 
                only FCT entries, but it's data area STARTS with those  
                last 72 bytes of FCT entry number 79, and then FCT entry
                number 80 thru 187 are contained in this SEGNR=3 record.
               -Finally, the Fourth Segmented Record is like the third, 
                no PROD/GENE/FCT Header, only FCT entries, but its data 
                area (happens?) to start with FCT Entry R84FSEQN=188's  
                byte one, and then FCTs 189 thru 250 are complete in the
                SEGNR=4 JMF record.                                     
               -Unrelated to the above issues, truncated subtype 2      
                records were discovered; IBM APAR OA37982 is now open to
                correct that error.                                     
   Thanks to Lucy F. Trabulus, Bank of America, USA.                    
Change 29.211  Support for Throughput Manager APAR TMT6214, corrects the
VMACTPMX       invalid subtype 16 triplets when there were more than 76 
Sep 21, 2011   steps in a job.  Those invalid triplets caused the ERROR:
               INPUT STATEMENT EXCEEDED RECORD.  The APAR corrects the  
               error by creating multiple "continuation" records when   
               when there are more than 76 steps, and installing their  
               APAR eliminates the INPUT STATEMENT EXCEEDED ERROR.      
               A new version of MXG is NOT required to support the APAR.
               But, to create observations in TPM16J dataset, you need  
               Change 29.200, in MXG 29.06, to correct an unrelated MXG 
               coding error that caused zero observations to be created.
               And, job-info variables were only added to the TPM16J    
               dataset by THIS change, which will be in MXG 29.07, or   
               can be requested now via email from    
              -Support for Subtype 5 PCS segment is added, with those   
               variables added to the existing TPMSLM dataset when the  
               PCS segment is present.  The variable names are taken    
               verbatim from the DSECT, so most are longer than the old 
               8-byte ASM DSECT field names.                            
Change 29.210  The spelling of most variables available in this header  
IHDRTMVS       exit for selection were wrong.  And, variable LMRKJOBC is
VMACTMVS       NOT the JOB name of the Landmark Monitor for z/OS, but is
Sep 14, 2011   the SYSTEM ID of that system, so it's label is corrected,
               and it can be used to select by SYSTEM.                  
   Thanks to Sam Bass, McLane Co., USA.                                 
Change 29.209  DB2 V10 ID=100 SUBTYPE=1 with INVALID HEADER caused INPUT
VMACDB2H       EXCEEDED RECORD LENGTH error.  The defective record had  
Sep 14, 2011   0122x (290 decimal) for the offset to the un-truncated   
               QWHSOPID field, with that QWHSTYP=2 starting in byte 5375
               but 5375+290=5665, while the LENGTH of the data portion  
               was only 5534 bytes.  Protection for this invalid header 
               field has been added for all of the "untruncated" fields 
               in the QWHSTYP=2 Header segment. IBM might be contacted. 
   Thanks to Tom Pierce, LabCorp, USA.                                  
Change 29.208  IBM i-Series (AS400) with more than 32 CPUs create two   
VMACQACS       records in QAPMSYSC dataset (IBM "QAPMSYSCPU") for each  
Sep 14, 2011   interval, with the first 32 engines in the first record  
               and the second 32 engines in the second record.  You must
               now invoke the _SQAPSYC macro after your _TQAPSYC macro  
               when you read the QAPMSYSC infile:                       
                 %INCLUDE SOURCLIB(VMACQACS);                           
               as the _SQAPSYC macro now sums those two records to      
               create a single observation per interval, with the       
               (corrected) PCTCPUBY percentage, and the new variable    
               SCPUSUM with the total CPU time for all online engines.  
   Thanks to Karen Florup, Bank of America, USA.                        
Change 29.207  MONWRITE Broken Control Record error due to incomplete   
VMACVMXA       decoding of the 2.14 (SCLALL) Schedule Domain record.    
Sep 13, 2011   The error message gives no clue the cause is the 2.14.   
               This is the first MONWRITE file in a long time that had  
               SCL (Schedule) domain records enabled; they are rarely   
               turned on due to large volume, and provide low-level     
               trace-like event data that requires pretty deep knowledge
               of z/VM internals to be useful, but now they too are     
   Thanks to David J. Schumann, Blue Cross of Minnesota, USA.           
Change 29.206  Cosmetic.  VMXGSUM now dies gracefully with an MXGERROR: 
FORMATS        message if there is no input dataset to process.         
Sep 13, 2011                                                            
   Thanks to                                                            
Change 29.205  Cosmetic.  New format MGEDGCF decodes variable COMEFROM  
FORMATS        to identify which variable will be missing when invalid  
VMACEDGR       dates (e.g., 2000/000) are found in RMM records.         
Sep 13, 2011                                                            
   Thanks to                                                            
====== Changes thru 29.204 were in MXG 29.06 dated Sep  8, 2011======== 
Change 29.204 -Support for RMF III RCD data, promised in Change 29.187, 
EXZRBRCX       is now completed.  The new ZRBRCDX dataset contains the  
IMACRMFV       Response Times for Reporting Classes and the existing    
VMACRMFV       ZRBRCDT datasets is updated with Response Times for the  
VMXGINIT       Service Classes.                                         
Sep  7, 2011  -BY lists BZRTRCS/RCR/RCP/RCD were revised.               
Sep 13, 2011  -Cosmetic changes, PCT, Version, etc.                     
Change 29.203  The labels for variables PC24RHWM and PC24SHWM for the   
VMAC110        "Below 16MB" areas had ERDSA and ESDSA but those labels  
Sep  7, 2011   should have been RDSA and SDSA.                          
   Thanks to Steven Kimball, Aetna, USA.                                
   Thanks to Victoria Lepak, Aetna, USA.                                
Change 29.202  The _IDEDGSA macro default value should be 512 but it was
VMACEDGS       left with 8Ax (138) after a test with user's data, and if
Sep  7, 2011   you have an ID=138 record in your SMF file, JCLTEXTx will
               fail (INPUT STATEMENT EXCEEDED).                         
   Thanks to Walter Noniewicz, State of Connecticut, USA.               
Change 29.201 -Support for DB2 V10 restructured IFCID=217 record, which 
VMAC102        caused T102T217 and T102U217 to have zero observations,  
Sep  7, 2011   but (fortunately) the incompatible record format did NOT 
               cause an execution error.  Dataset T102S217 now has only 
               one unique variable, and new QW0217AL and QW0217AS ASIDs 
               were added to T102T217 & T102U217 datasets respectively. 
               Dataset T102V217 always has zero observations (after V8).
              -Unrelated, many offseg+lenseg LE LENGTH segment tests are
               corrected to offseg+lenseg-1; the incorrect test could   
               have prevented reading legitimate segments.              
   Thanks to Betty Wong, Bank of America, UDS.                          
Change 29.200  No observations were created in TPM16J dataset because   
VMACTPMX       the MXG test comparing segment offset+length with the    
Sep  7, 2011   record length was off by one, preventing input/output.   
   Thanks to Scott Barry, SBBWorks Inc, USA.                            
Change 29.199  The %SYSPROD(GRAPH) function doesn't validate that the   
GOPTIONS       product is installed; it only confirms that the SETINIT  
DOC            licenses SAS/GRAPH.  The MXG test in VMXGINIT to set     
VMXGINIT       GOPTIONS for SAS/GRAPH examples in MXG GRAFxxxx members  
Sep  4, 2011   (that was added without a change number in MXG 28.05)    
               is true when the SETINIT said yes, but GOPTIONS/PATTERNn 
               statements fail when SAS/GRAPH isn't actually present,   
               with a 180 syntax error on the GOPTIONS statement, since 
               those procedure-specific statements can't compiled if the
               product isn't installed. The new PROC PRODUCT_STATUS will
               list all products that are installed, but its use would  
               require a PROC PRINTTO to trap its output to a file, a   
               DATA step to read that file, and new %macro variable and 
               logic, just to set these (optional!) SAS/GRAPH options.  
               So, to prevent a 180 error in VMXGINIT, these statements 
           PATTERN1 V=S;  PATTERN2  V=L1; PATTERN3 V=R1; PATTERN4 V=X1; 
           PATTERN5 V=L2; PATTERN6  V=R2; PATTERN7 V=X2; PATTERN8 V=L3; 
           PATTERN9 V=R3; PATTERN10 V=X3;                               
               are no longer set in VMXGINIT, but are moved into the new
               GOPTIONS member, and all GRAFxxxx members were updated to
               set them with %INCLUDE SOURCLIB(GOPTIONS);               
              -Also, MXG macro variables SASGRAF and SASSTAT are removed
               from VMXGINIT; they were never referenced in any MXG code
               and were set by %SYSPROD(), so they too could be wrong.  
   Thanks to Richard Haynes, Blue Cross Blue Shield of Kansas, USA.     
====== Changes thru 29.198 were in MXG 29.06 dated Sep  1, 2011======== 
Change 29.198  iSERIES variable GDES21 was multiplied by 4096, but it   
VMACQACS       should have been multiplied by 1024; when GDES11 is all  
Aug 31, 2011   nines, GDES21 contains the storage assigned to the LPAR. 
   Thanks to David Bixler, FISERV, USA.                                 
Change 29.197  Two new segments in Velocity Software XAM Version 4.1 CPU
VMACXAM        record are decoded (PRCINS,PRCDIA) but not output as they
Aug 31, 2011   are repeated and hence need new datasets created, and the
               new STOASC (DEV) and new SYTLCK (SYS) weren't documented;
               these four segments were protected for the NEW SEGMENT   
               messages but were not decoded.  See Change 29.253.       
Change 29.196  MXG calculation of GMTOFF30 in SMF 30 records could be   
VMAC30         off by 0.01 second, only for positive GMT Offsets, but   
Aug 31, 2011   that impacted the BUILDPDB logic that combines MULTIDD=Y 
               records for a step, when there were intervening SMF 30s  
               from a different job in between the MULTIDD=Y records.   
               The MULTIDD=Y records don't contain SMF30IST, so GMTOFF30
               must be retained from the prior non-MULTIDD record, but  
               in this case, SMF30IST was 0.07 with SMF30ISS 0.073983 in
               the non-MULTIDD, but an intervening step's non-record had
               SMF30ISS of 0.075983 with SMF30IST of 0.08, causing MXG's
               (failing) fuzzy logic use GMTOFF30 of .01 in MULTIDD=Ys  
               from the first step.  This caused BUILDPDB to not include
               the EXCP/IOTM counts in PDB.SMFINTRV for the MULTIDD's,  
               so while TYPE30_V had 26 million EXCPs, only 24 million  
               were in PDB.SMFINTRV for that day's DB2 intervals.       
               The real culprits, aside from MXG's failing fuzzy logic, 
               is the absence of GMTOFF in SMF 30 records, the absence  
               of SMF30IST in the MULTIDD=Y records, and SMF30ISS being 
               an 8-byte (LOCAL) TODSTAMP with microsecond resolution,  
               while SMF30IST (GMT) is an 8-byte SMFSTAMP with only 10  
               millisecond resolution.  The correction for MXG's logic  
               error is to first use ROUND(SMF30ISS,.01) before its     
               comparison with SMF30IST so both have 10 millisecond,    
               rounded, values, so GMTOFF30 is correctly calculated for 
               both positive and negative GMT offsets.                  
               A formal request to IBM SMF30 development to add the long
               overdue GMT Offsset has again been made so that MXG logic
               is not needed to compensate for its absence.             
   Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.                    
Change 29.195  MXG now terminates reading TMS data with USER ABEND 1234 
VMACTMS5       and an ERROR message if the input file is not the TMC.   
Aug 30, 2011   The TMSGRW TMS utility program creates 340 byte records  
               that MXG read, but they produced incorrect results.      
               MXG support requires the TMC data as its input file.     
   Thanks to Srini Anne, State of California, USA.                      
Change 29.194  Statistics on Page Datasets are added to RMFINTRV (so if 
VMXGRMFI       your DB2 DBAs add massive buffers and eat up all of your 
Aug 27, 2011   page datasets, you'll at least be able to prove why the  
               system died for lack of paging space!).  New variables:  
                 MAXCOMN ='MAXIMUM*COMMON*SLOTS USED'                   
                 MAXLOCL ='MAXIMUM*LOCAL*SLOTS USED'                    
                 MAXPLPA ='MAXIMUM*PLPA*SLOTS USED'                     
                 PCTCOMN ='PERCENT*COMMON*SLOTS USED'                   
                 PCTPLPA ='PERCENT*PLPA*SLOTS USED'                     
   Thanks to Chuck Hopf, Independent Consultant, USA.                   
Change 29.193 -ANALZPCR with PDB=SMF reads 113s as well as the others   
ANALZPCR       and invokes ASUM113.                                     
UTILBLDP      -UTILBLDP adds SMF 113 processing, conditionally:         
Aug 27, 2011   If BUILDPDB EQ YES and USERADD does not contain 113 it is
               added to USERADD, and if INCLAFTR doesn't contain ASUM113
               it is added there.                                       
   Thanks to Chuck Hopf, Independent Consultant, USA.                   
Change 29.192  If the length of text in the list of DDNAMEs passed into 
UTILCONT       UTILCONT exceeded 256 bytes, the list was truncated and  
Aug 26, 2011   remaining datasets were not read.  Increased to 32000.   
   Thanks to David Bixler, FISERV, USA.                                 
Change 29.191  Windows 7 may error when attempting to write files to the
DOC            root directory (e.g., C:\ if that is your boot directory)
Aug 24, 2011   or to the c:\windows or the c:\program files directories,
               with a message about "Insufficient authorization to use".
               The error may be circumvented if the program is "run as  
               authorized", but some MXG examples of ASCII syntax had   
               "c:\" that could cause the error, so all     
               instances of that syntax were revised to explicitly      
               have a directory name (e.g. "c:\mxg\').      
               In addition, some ASCII LIBNAME examples (which always   
               point to a directory rather than a file) did not have    
               a final slash character (LIBNAME PDB 'C:\PDB';) and thus 
               were unclear that the syntax requires a directory name.  
               Those examples are now changed to include a final slash  
               (LIBNAME PDB 'c:\pdb\';) to reinforce that the object is 
               a directory and not a filename.                          
Change 29.190  In this "JCLSPLIT" example, CICSTRAN was incorrectly sent
BLDSPSMA       to //WORK DD instead of the correct //CICSTRAN DDname.   
Aug 23, 2011                                                            
   Thanks to Art Cuneo, Blue Cross Blue Shield of Illinois, USA.        
Change 29.189  Support for Software AG's ADABAS SMF User record creates 
EXADUSER       sixteen new datasets:                                    
EXADSTG          DDDDDD     MXG       MXG                               
EXADIODD         DATASET    DATASET   DATASET                           
EXADTHRD         SUFFIX     NAME      LABEL                             
EXADCSG          ADSTG      ADABSTG   ADABAS STG RECORD                 
EXADMSGB         ADCMD      ADABCMD   ADABAS CMD RECORD                 
EXADMSGC         ADCSP      ADABCSP   ADABAS CSP RECORD                 
EXADMSGH         ADCSG      ADABCSG   ADABAS CSG RECORD                 
EXADREV          ADCSB      ADABCSB   ADABAS CSB RECORD                 
IMACADAB         ADCSF      ADABCSF   ADABAS CSF RECORD                 
TYPEADAB         ADLOK      ADABLOK   ADABAS LOK RECORD                 
Aug 24, 2011     ADREV      ADABREV   ADABAS REV RECORD                 
              -Datasets ADPARM, ADSTG, ADTHRD, ADFILE, and ADCMD are now
               decoded and validated with SMF records; the others have  
               been coded but are untested with actual data records.    
              -Datasets ADABTHRD and ADABFILE do not have fields that   
               identify the Thread/File; counters ADTHRDNR and ADFILENR 
               are created as the sequence number in each record, but in
               the test data, only the first instance in each record has
               a non-zero count (but there are many instances in each   
               record with zero counts that perhaps should be deleted). 
   Thanks to Wayne Campos, Corelogic, USA.                              
Change 29.188 -Blank TRANNAME in ASUMUOW occurred with MXG 28.05 that   
IMACUOW        were not present with MXG 28.04, so new Case 4 example is
VMXGUOW        created to handle this sequence of DB2/CICS/MQ records.  
Aug 23, 2011   Precipitated possibly by our changes to VMXGUOW, as the  
               only site difference is that remote program definitions  
               with a remote tranid on them are used.                   
              -New debugging TRACEUOW=TRAN option was added/needed to   
               diagnose this problem: at the endpoint, it tells you     
               everything there is to know about that particular UOW    
               when the TRANNAME comes up blank.                        
              -All of the macros that are typically tailored are now    
               defined in the IMACUOW member, and you should EDIT that  
               member into your "USERID.SOURCLIB(IMACUOW) and make your 
               tailoring there, and should NOT now ever have VMXGUOW in 
               your "USERID.SOURCLIB" tailoring library.                
   Thanks to Dave Campbell, SunTrust, USA.                              
Change 29.187 -MXG 29.05 only.  ASMRMFV could fail with 0C4 ABEND. Under
ASMRMFV        some conditions, IBM did not create a Period Data        
VMACRMFV       Extension for a Report Class in the RCD record. The count
Aug 23, 2011   field was unexpectedly zero, causing a loop counter to   
Sep  1, 2011   become negative, and the 0C4 during an MVCL command.     
               This condition was never observed during testing.        
              -This ASMRMFV properly outputs the RCD records, but the   
               MXG code in VMACRMFV has not yet been updated to read    
               those records, and prior VMACRMFV could fail trying to   
               read the new RCD output, so this VMACRMFV skips over any 
               RCDG3 records.  If you want those data, contact support  
               since the VMACRMFV updates should be done by the time you
               read this text.                                          
   Thanks to Neil Ervin, Wells Fargo Bank, USA.                         
   Thanks to Jason, Bierman, Great Lakes Higher Education Corp., USA.   
Change 29.186  Support for InfoSphere Classic Federation Server Account 
EXCFSACC       user SMF record creates two new datasets:                
FORMATS          DDDDDD     MXG       MXG                               
TYPECFS          DATASET    DATASET   DATASET                           
TYPSCFS          SUFFIX     NAME      LABEL                             
               These possible violations are formatted in MGCFSTY:      
                 101:NOT AUTH TO ISSUE A DROP TABLE FOR TABLE           
                 102:NOT AUTH TO ISSUE A DROP INDEX FOR TABLE           
                 103:NOT AUTH TO ISSUE A DROP VIEW FOR VIEW             
                 200:NOT AUTH TO CREATE TABLE                           
                 201:NOT AUTH TO CREATE INDEX                           
                 202:NOT AUTH TO ISSUE THE CREATE VIEW STATEMENT        
                 303:NOT AUTH TO CALL STORED PROCEDURE                  
                 500:NOT AUTH TO ISSUE GRANT STATEMENT                  
                 501:NOT AUTH TO ISSUE REVOKE STATEMENT                 
   Thanks to Jeana M. Bechtel, Edward D. Jones, USA.                    
   Thanks to Jim Poletti, Edward D. Jones, USA.                         
Change 29.185  GRAFWRKX used the old IMACWORK workloads to graph the    
GRAFWRKX       workload variables and had work1-work99 parameters       
Aug 13, 2011   for the new.  This change removes the need to specify    
               workload parameters unless you want to alter the order   
               in which the bars are stacked. Support for the old       
               IMACWORK workloads is removed but VGETWKLD is used to    
               capture all of the workloads unless you specify WORK1-   
               WORK99 values. If you do not specify WORKx values the    
               workloads are stacked alphabetically from bottom of the  
               bar to the top. Except that uncaptured will ALWAYS be    
               at the bottom.  If you specify WORK1-x workloads then    
               the bars are stacked bottom to top starting with WORK1   
               and going up numerically. You can still use the old      
               IMACWORK definitions but the parameters are dead and     
               do not function.                                         
Change 29.184  GRAFRMFI used the old IMACWORK workloads to graph the    
GRAFRMFI       workload variables and had no provision for the new      
VGETWKLD       VMXGRMFI sets of workload variables.  It now uses        
Aug 13, 2011   VGETWKLD to find the workloads that are defined in       
               your RMFINTRV dataset (whichever method is used) and     
               uses those workloads and labels to graph the workload    
               This is part of the ODS change 29.169, but the change in 
               the member are so extensive that it warranted a separate 
               Numerous issues corrected in this change/circumvention:  
              -TIME VALUE NOT VALID FOR TIME FORMAT.  SAS V9.3 only.    
               if all obs had a missing value for a TIME variable, that 
               WARNING was printed; circumvented with WHERE clause, but 
               that raised another WARNING about WHERE CLAUSE changing. 
               The more insidious problem was the structure:            
                PROC GPLOT;                                             
                PLOT A                                                  
                PLOT B                                                  
                PLOT C                                                  
                PLOT D                                                  
                PLOT E ....                                             
                Which worked fine unless all the obs had missing values 
                for one of the variables. For example, if A has all     
                missing values, then, instead of skipping over B, it    
                made a copy of A.  Even worse, IF B C D E all had       
                missing values, then you got 5 copies of A instead of   
                the 1 you really wanted.                                
                The solution was to change the structure to:            
                 PROC GPLOT;                                            
                 PLOT A                                                 
                 PROC GPLOT;                                            
                 PLOT B                                                 
                 PROC GPLOT;                                            
                 PLOT C                                                 
                 PROC GPLOT;                                            
                 PLOT D                                                 
                 PROC GPLOT;                                            
                 PLOT E ....                                            
                It runs a little slower but it eliminated that problem  
                as well as the warning about the where clause changing. 
                WARNING:  This routine can produce hundreds of graphs;  
                the number is a function of the number of system, days, 
                and workloads.                                          
               -Code to execute from any populated RMFINTRV dataset:    
Change 29.183  Variable SMF19VLI never existed and is no longer created.
VMAC19         This is an overlay for SMF19TRK and SMF19TRM which were  
Aug 13, 2011   invalid prior to this correction.                        
   Thanks to Neal Musitano, Jr., Department of Veterans Affairs, USA.   
Change 29.182 -Invalid ASP.NET Applications record caused ERROR: INPUT  
IMACNTSM       but header said 75 should exist, which is what MXG       
VMACNTSM       expected).  Circumvention detects number of words in the 
VMXGINIT       NT SMF record and deletes with an MXGERROR: message.     
Aug 11, 2011  -New Object .NET DATA PROVIDER FOR SQLSERVER supported    
              -Segments ACSR,SQGS,SQDA,SQSS,QLSS and SQBS have IDPROCES 
               and SQLVERSN variables added.                            
              -After circumvention code was implemented, user found out 
               the data file had been truncated during ftp transfer, but
               I left the update in place since it was tested and safe. 
   Thanks to Xiaobo Zhang, FISERV, USA.                                 
Change 29.181  %ANALDB2R argument PMIOS05 was not %UPCASED by MXG, so no
ANALDB2R       IO SUMMARY REPORT was produced if  PMIOS05=yes  was used.
Aug 11, 2011                                                            
   Thanks to Howard L. Curtis,  Progress Energy, LLC, USA.              
Change 29.180  Harmless MXGWARN: DURATM=INTERVAL WAS SPECIFIED message  
ASUMMIPS       is eliminated; DURATM was in the SUM= list when it should
Aug 10, 2011   not have been.                                           
   Thanks to Bernhard Bablok, Allianz, GERMANY.                         
Change 29.179  Undefined TOKEN= $ZEKE_Z with TOKENID=59674 now skipped, 
VMACTPMX       as are all of the defined-but-not-used ZEKE fields.      
Aug 10, 2011                                                            
   Thanks to Scott Wiig, U.S. Bank, USA.                                
Change 29.178  Variable CECSER, a 6-byte text variable with only the    
VMAC89         left four positions populated, with two blanks at the    
Aug  9, 2011   right end, is now created in TYPE89 and TYPE892 datasets 
               to match CECSER in the RMF TYPE70xx data.  SMF89SER is a 
               three-byte character variable containing text in hex with
               format $HEX6., so it printed '0178E0', including the 01x 
               CPUID value.  But CECSER in RMF records is only the text 
               '78E0  ' value, and that is now the value in CECSER in   
               the TYPE89 and TYPE892 datasets.                         
   Thanks to Warren Cravey, FMR, USA.                                   
Change 29.177  Support for APAR OA35175, logstream statistics in SMF 23,
EXTY23LS       creates new TYPE23LS dataset with these new data:        
VMAC23           SMF23LFG='VARIOUS*FLAGS'                               
VMXGINIT         SMF23LFH='HWM*BUFFER*ALLOCATION'                       
Aug  9, 2011     SMF23LFL='CURRENT*BUFUSEWARN*IN EFFECT'                
                 SMF23LFM='CURRENT*DSPSIZMAX*IN EFFECT'                 
                 SMF23LSL='LENGTH*OF LOGSTREAM*NAME'                    
                 SMF23LF1='BUFUSEQARN*FROM THE*GLOBAL*OPTION?'          
                 SMF23LF2='DSPSIZMAX*FROM THE*GLOBAL*OPTION?'           
               APAR OA37002 (see NEWSLTRS) adds new DSPSIZMAX argument  
               for SMFPRMxx to set logstream buffer size(s).            
   Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.  
Change 29.176 -APAR OA36816 adds bit to SM113CF1 in SMF 113 HIS record  
FORMATS        that is now decoded by $MG113FL format to display:       
Aug  9, 2011   '08X:LOST COUNTER DATA' when SM113CF1 is printed.        
              -And it adds new option of interest to HIS SMF 113 users: 
                 The DATALOSS parameter for the F HIS command has been  
                 enhanced to control what action is taken by HIS when   
                 any type of instrumentation data is lost. Prior to this
                 enhancement, the DATALOSS parameter only reacted to    
                 sampling data lost due to a buffer overflow. The       
                 DATALOSS parameter now reacts to instrumentation data  
                 lost due to a Loss Of Sample Data Measurement Alert and
                 a Loss Of Counter Data Measurement Alert.  By          
                 specifying DATALOSS=IGNORE these types of              
                 instrumentation data loss can now be ignored, and the  
                 instrumentation run may continue.                      
Change 29.175  Support for APAR OA35617 documents two new SMF30PF2 bits 
VMAC30         creating SMF30CRM (ASID IS VELOCITY GOAL MANAGED) and    
Aug  9, 2011   SMF30PIN (INCOMPLETE WLM DATA?), one-byte flag variables.
               SMF30PIN was just observed (overlooked) and now created. 
               The APAR documents SMF30CRM with this note:              
                 the address space matched a classification rule which  
                 specified "manage region using goals of both", which   
                 means it is managed towards the velocity goal of the   
                 region.  But, transaction completions are reported     
                 and used for management of the transaction service     
                 classes with response time goals.  This option should  
                 only be used with CICS TORs, the associated AORs       
                 should remain at the default "manage region using      
                 goals of transaction".                                 
Change 29.174  Support for APAR OA34895 adds new EXCP/IOTM SMF 30 fields
IMAC30IO       (transparently) with step/interval total I/O Count and   
VMAC30         I/O Connect times (new MXG variables EXCPMISS/IOTMMISS)  
Aug  9, 2011   with counts that would have also been in a DD segment(s),
Aug 27, 2011   but weren't, because an SMF Lock (to update the TIOT for 
VMAC434        serialization) could not be obtained. The xxxxMISS counts
VMAC40         ARE included in the asid/step totals, EXCPTOTL/IOTMTOTL, 
               read directly from the SMF record, but were not counted  
               in any of its DD segments, so they are ALSO already in   
               MXG creates with EXCPNODD=EXCPTOTl-EXCPTODD.             
                 All of the above is true, WITH OR WITHOUT this change. 
               This change only creates the new variables and keeps them
               in datasets in TYPE30_V, TYPE30_4, TYPE30_5, TYPE30_6 and
               PDB.SMFINTRV, and in BUILDPDB's PDB.STEPS/PDB.JOBS (where
               member IMAC30IO controls which SMF 30 I/O variables are  
               kept in the those BUILDPDB/BUILDPD3 datasets.  These new 
               "missed" variables would be useful to at least partially 
               explain steps with large values in NODD and TOTL fields, 
               if the xxxxMISS values are non-zero.  See NODD in ADOC30.
              -Compiler faker added in VMAC434/VMAC40.                  
              -Transparently added, but if you (incorrectly) have an old
               VMAC30 in your tailoring library, that will cause        
                ERROR: EXCPMISS NOT FOUND in BUILDPDB at MXGSUM3.       
   Thanks to Christa Neven, KBC Global Services, BELGIUM.               
Change 29.173  Support for APAR OA36966 for JES3 expands NJEJOBNO to    
VMAC57         four bytes in SMF 57 record.                             
Aug  9, 2011                                                            
Change 29.172  APAR VM64961 adds SMF 113 Hardware Monitor counters to   
EXPRCMFC       the z/VM MONWRITE data on z/10 and later processors. PTFs
VMACVMXA       will be available for z/VM 5.4 and z/VM 6.1 and 6.2.     
Aug  8, 2011   Dataset VXPRCMFC contains the same variable names as     
               TYPE113, but there is no SYSTEM variable in z/VM so it   
               wasn't added into ASUM113.  This support was in MXG      
               29.04, but undocumented.                                 
Change 29.171  The example WEEKBLDT had four instances of _WKBLD that   
WEEKBLDT       should have been spelled _WEEKBLD; they caused a SAS     
Aug  7, 2011   180 syntax error, after creating WEEK.TYPE72 dataset.    
   Thanks to Ron Wells, American General Finance, USA.                  
Change 29.170  The insertion of the _TODAY old style macro caused       
BLDSMPDB       the forceday option to fail.                             
Aug  7, 2011                                                            
   Thanks to Cletus McGee, ALFA Insurance, USA.                         
Change 29.169  MXG examples that use ODS HTML on ASCII that did not have
ANAL72GO       a PATH= statement failed with                            
ANALAVAI       but only in QA Tests with SAS V9.3; no user had reported 
ANALDB2B       this error, which can occur with SAS V9.1,V9.2, or V9.3, 
ANALHTML       nor had we seen the error with earlier SAS Versions.     
ANALIDMS       SAS Note SN15046 says to eliminate the error you should  
ANALINIT       use this recommended syntax on ASCII platforms:          
ANALPKGS           ODS HTML PATH="C:\mxg\"(URL=NONE) body="temp.html";  
ANALRAID       Previously, MXG had inconsistent ODS examples; this      
ANALRANK       change formalizes MXG support to create HTML output.     
ANALS225      -We use two new %macros VMXGODSO/VMXGODSC to OPEN/CLOSE   
GRAFCEC        ODS output in our examples, and they can be used in your 
GRAFRAID       report programs, to create HTML output. The macros can be
GRAFRMFI       invoked on z/OS to send html output to either a PDSE or  
GRAFTAPE       to a ZFS filesystem, or on ASCII to .html files.         
GRAFWLM       -A consistent set of macro variables are used in arguments
GRAFWRKX       so %LET's can be used to change ODS argument's values.   
VMXGODSO       change revised all of the MXG members with ODS examples. 
VMXGODSC      -SAS ODS inconsistencies we discovered and handle:        
Aug 14, 2011   the URL= must be either a quoted string or unquoted NONE,
               and the STYLE= and TRANTAB= arguments are unquoted.      
              -SAS HTMLBLUE default does not break PROC PRINT output    
               lines, requiring scrolling across to see all variables.  
               ODS LISTING; will change the default back to what you    
               were used to for all interactive output.                 
Change 29.168  Velocity Software XAM variable PERFCPU is now in seconds 
VMACXAM        and formatted TIME12.2 in datasets XMHSTAPP and XMHSTSFT.
Aug  1, 2011   Those datasets contain HSTAPP resource usage of a group  
               of processes that form an application (in snmpd.conf or  
               ESATCP 'guessing'). If you want to look at individual    
               processes, you would use dataset VXVSISFT instead.       
   Thanks to Joe Faska, Depository Trust, USA.                          
Change 29.167  MXG example reports using PDB.RMFINTRV only recognized   
VGETWKLD       workload names created with (now archaic) IMACWORK logic.
Aug  1, 2011   The VGETWKLD internal macro will parse the workload names
               created by the (now-recommended) WORKnn= arguments that  
               should be used to define workload names in RMFINTRV.     
Change 29.166  For DB2 Version 8.1, dataset DB2GBPST was mostly wrong as
VMACDB2        two 4-byte reserved fields (after QBGLXR and QBGLMR) were
Aug  1, 2011   not input, causing all subsequent variables to be wrong. 
   Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.                    
Change 29.165 -Variable POSIT was incorrectly zero, as only the first 8 
VMACRACF       bytes of the 10-byte POSITCH field were INPUT as numeric.
Jul 31, 2011  -Vars OTHRSPEC/OTHRSPE1 are renamed to FRSTSPEC/OTHRSPEC  
               and re-labeled.                                          
   Thanks to Bill Arrowsmith, Euroclear, BELGIUM.                       
   Thanks to Christopher Roberts, Euroclear, BELGIUM.                   
Change 29.164  Variables S17FBKNM S17SEXNM S17FMFNM are now kept in the 
VMAC117        S117THRD dataset.                                        
Jul 31, 2011                                                            
   Thanks to Fabio Massimo Ottaviani, EPVTECH, ITALY.                   
Change 29.163  MXG 29.05, Change 29.129 for z/VM Crypto Record (5,10),  
VMACVMXA       from z/VM 5.4, if PRCAPMCT=6, because that subtype does  
Jul 29, 2011   NOT have the undocumented 32 bytes found in 4 and 8, and 
               this was the first instance of that subtype.  Since MXG  
               can so readily circumvent the IBM error (see 29.129), and
               since this is an (ancient?) z/VM 5.4 record, fixing the  
               doc does not have (appropriately, IMO) high priority, as 
               this is a fairly obscure event - how many do use crypto  
               on z/VM systems, especially z/VM 5.4 systems.            
   Thanks to Tom Draeger, Aurora Health Care, USA.                      
Change 29.162 -Corrections/enhancements to TYPEIMST (IMS56FA TRANSACTs):
VMACIMS       -STRTTIME and ARRVTIME were reversed in MXG logic.        
Aug  2, 2011  -But, after fixing, ARRVTIME can be greater than STRTTIME:
               - Case 1: WFI and PWFI, because the UOR Start Time begins
                 when the previous transaction completes, then the      
                 program waits for the next message to appear, so the   
                 STRTTIME=ARRVTIME is the wait time of the program.     
               - Case 2: Message Switch; the first transaction's        
                 STRTTIME should be greater than the ARRVTIME unless    
                 it is a WFI; see case 1, but the Message Switch        
                 transaction afterward will have the UOR STRTTIME of    
                 the first transaction, therefore the ARRVTIME of the   
                 message will be greater than the STRTTIME.             
               In both cases, IF ARRVTIME GT STRTTIME then QUEUETM=0    
               and SERVICETM=RESPTM and STRTTIME=ARRVTIME to match IMF. 
              -Comparison of QUEUETM/INPQUETM between IMS56FA and IMS   
               has differences of up to 0.1 seconds, because ARRVTIME in
               IMF has only to 0.1 second resolution while in IMS56FA it
               has TODSTAMP resolution; this also caused similar small  
               differences between RESPTM/RESPNSTM variable's values.   
              -PROGTYPE in prior data was a one-byte text character, but
               in IMS56FA it is a more robust bit map, so the data value
               in the 56FA record is now input into PROGTYHX with $HEX2.
               format, then PROGTYPE is constructed as a test character.
               One-byte flag variables are created from PROGTYHX bits:  
              -These variables are now not kept in IMS56FA dataset:     
                 TPCPTICH TPCPSOXN                                      
               and removed from the BY list for that dataset, as they   
               do not exist in that record.                             
              -NMSGPROC=1 is set ONLY if CALLMSGU is GT 0 because 56FA  
               records are also written for a Message GU-CALL that did  
               not get a message from the IMS Message QUEUE; for MPPs   
               these show only a small CPU time, TPLTERM is blank, and  
               no calls are counted at all.                             
              -TPLTERM was renamed LTERM in IMS56FA dataset.            
              -IMSVERSN is set to 10.1 instead of 10.10.                
              -Either SYSABEND or USRABEND, but not both, are populated;
               COMPCODE='00000C4000'X correctly set SYSABEND='0C4';     
               but also incorrectly set USRABEND='U16E3' (i.e. 16,000+).
              -If there are no GU calls to the message queue, then there
               is no ARRVTIME, so neither QUEUETM nor RESPTM exist; they
               are both set to missing values when CALLMSGU LE 0.       
               exists to correct this intermittent problem:             
                  TPEXTIME is IMSCPUTM in MXG IMS56FA dataset; values   
                  'FFFFFFFBAFBA5708'x &'FFFFFFFCC4B4F0C8'x occurred in  
                  two transactions with SYSABEND='0C4' (but the other   
                  0C4's had zero values.  MXG prints an error message   
                  for the first five instances, and sets IMSCPUTM to a  
                  missing value when an invalid CPU time value is found.
   Thanks to Rudolf Sauer, T-Systems, GERMANY                           
Change 29.161  MXG 29.03-MXG 29.05, dataset MQMCFMGR was wrong, with 64 
VMAC115        identical outputs of only the first segment for each SMF 
Jul 29, 2011   ID=115 record, if QESTSTR was non-blank in that segment, 
               so there were MANY more obs created than should have been
               and many valid segments were not output.                 
   Thanks to Paul Volpi, UHC, USA.                                      
Change 29.160  VMXGFIND failed when dataset names created by SAS were   
VMXGFIND       32-characters, because VMXGFIND added a prefix of text   
Jul 28, 2011   "LIBNAME_" to that SAS-created dataset name.  Now, if    
               only a single input LIBNAME is found, that prefix is     
               omitted and when there is more than one libname, if the  
               result exceeds 32 characters, only the first 32 are used.
Change 29.159 -Support for SAS Version 9.3 requires SAS Hot Fix SN43828.
FORMATS        This error in SAS Portable Code, in compiling the %macro 
Jul 26, 2011   %LET statement, and the %SYSRPUT and %SYSLPUT statements,
               could impact SAS V9.3 on ALL platforms, although it was  
               only detected in MXG QA tests on z/OS, in the members    
               ANALCNCR and VMXGRMFI, both of which invoke %VMXGSUM.    
               The compiler error caused misalignment between the left  
               half (variable name) and the right half (value) of the   
               %LET statement.                                          
              -On ASCII, 32-bit and 64-bit SAS versions are different   
               operating systems, even on the same platform; so separate
               "bit-specific" FORMAT directories are required, but the  
               same FORMATs can be used for V9.2 or V9.3 for the same   
               "bit" version. Member FORMATS errored when I tried to run
               it under 32-bit V9.3, writing to a V9.2 64-bit directory.
              -On both ASCII and z/OS, SAS Data Libraries can be read or
               written by either V9.2 or by V9.3, and on ASCII, under   
               either 32-bit or 64-bit environments.                    
Change 29.158  NDM-Connect Direct CT Version 5 record has 4 new fields. 
VMACNDM        There is no version value in the record, but there is a  
Jul 26, 2011   new offset to 2 of the 4 new fields, so that offset is   
               used to conditionally assume all four are present.       
                 NDMRIP6 ='IPV6*ADDRESS'                                
   Thanks to Eric R. Carlson, Kroger, USA.                              
Change 29.157  MXG 29.06 QA tests clean ups:                            
VMAC7072      -VMAC7072: These variables removed from DROP statement    
Jul 24, 2011             LCPUDEXD-LCPUDEXZ LCPUDEVA-LCPUDEUI            
                         LCPUWAXD-LCPUWAXZ LCPUWAVA-LCPUWAUI            
               because they never existed; QA test enabled DKROCOND=WARN
               which caused spurious warning messages.                  
Change 29.156  IDMS/R Performance Monitor for Version 18 adds variables:
VMACIDMS      -Dataset IDMSTAS:                                         
Jul 24, 2011      TASCPTI ='SRB*TIME*ON*CP'                             
                  TASENTI ='ENCLAVE*SRB*CPU*TIME'                       
                  TASSYTI ='CPU*TIME*ON*CP'                             
                  TASTITI ='TCP*CPU*TIME'                               
                  TASUSTI ='USER*MODE*CPU*TIME'                         
                  TASZPTI ='SRB*TIME*ON*ZIP'                            
               Initial observations were that                           
                  TASSYTI (.920) = TASTITI (.777) + TASENTI (.143)      
                    CPU          =    TCB             ENCL SRB          
                  TASCPTI (.016)                                        
                  TASZPTI (.127)                                        
                  TASENTI (.0007)                                       
              -Added to all datasets, and inserted into the header, so  
               it caused INVALID DATA FOR PMHSDATE messages:            
                  SMFHJOB ='PM*JOB*NAME'                                
   Thanks to Scott Barry, SBBWorks Inc, USA.                            
Change 29.155  CICS/TS 4.2 Statistics variables now input:              
VMAC110        Dataset CICISR:                                          
Jul 24, 2011      ISRTDBYR='IPCONN*PS*TD*REQS*BYTES*RECEIVED'           
               Dataset CICWBR:                                          
   Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.  
Change 29.154  Circumventions for a macro errors ONLY in archaic SAS V8,
VMXGSUM        that were also perfectly cloned into WPS V8 architecture.
Jul 24, 2011   While SAS V8 is no longer supported by SAS Institute and 
               while MXG officially does not always work under V8, these
               errors encountered in VMXGSUM from VMXGRMFI in BUILDPD3  
               with both SAS V8 and WPS were circumvented in MXG, and   
               could be useful in avoiding AUTOCALL issues in SAS V9s:  
              -%IF %LENGTH(&A &B) GT 0 THEN %DO incorrectly returned 1  
               when &A and &B were both null with V8/WPS but returned 0 
               with all SAS V9s. The error was circumvented by replacing
               the test string of multiple macro variables with single  
               ORed tests of each macro variable, to avoid the exposure.
              -The SAS provided-in-SASMACRO-library AUTOCALLed %macro   
               functions %CMPRES/%QCMPRES (which call %QLEFT, %VERIFY,  
               %QTRIM, %LEFT, %QLEFT, %VERIFY and %TRIM) were removed   
               from VMXGSUM, as they were never actually needed, and    
               their removal circumvented V8 and WPS macro errors.      
                 I had thought they were needed to compress blanks from 
                 the %macro arguments, which are limited to 65584 bytes,
                 and long ago longer argument errors had occurred, but  
                 that error occurs when the %macro is invoked, prior    
                 to these functions execution.  Hindsight is beautiful. 
   Thanks to Scotie Mills, TI, USA.                                     
Change 29.153  UNDECODED CTGRECID and CPU loop caused by Change 29.001, 
VMAC111        which incorrectly calculated the SKIP value of bytes to  
Jul 19, 2011   be skipped in the SMF ID=111, CTGRECID=7 record.         
   Thanks to Victoria Lepak, Aetna, USA.                                
Change 29.152  VMSYSTEM='Y' (Change 29.127) support was revised when RMF
VMAC7072       70 records were read.  A divide by zero (creating TYPE70 
Jul 19, 2011   from WORK.SORT70SP, because ONTM(LCPUADDR+1) was zero,   
               because the VMSYSTEM='Y' records do NOT populate the     
               "on time" in SMF70ONT (which populates ONTM array, and I 
               believe this is a defect that IBM needs to correct, and  
               a PMR has been opened to address this and other issues). 
               However, knowing SMF70ONT is NOT populated, MXG code was 
               revised and SMF70ONT=DURATM when VMSYSTEM='Y', which then
               corrected calculations of PCTCPUBY for these new records,
               and logic was revised to correctly capture the actual    
               LPARNAME of the z/OS system that was running under z/VM. 
====== Changes thru 29.151 were in MXG 29.05 dated Jul 11, 2011======== 
Change 29.151  Support for RCD record in ASMRMFV is completed in time to
ASMRMFV        be included in MXG 29.05, but I procrastinated and did   
Jul 10, 2011   not complete the updates in VMACRMFV to actually process 
               and create the new variables.  You can safely install the
               new ASMRMFV program to create the RMFBSAM file with RCD  
               data, so that it could be examined when the VMACRMFV has 
               been updated. Contact if you want the    
               updated VMACRMFV when it's ready.  This change will be   
               revised when RCD support is completed.                   
               Jan 18, 2012: MXG 29.29 DATED JAN 18, 2012 IS REQUIRED   
               AND THE UPDATED VMACRMFV TO READ RCD DATA.               
Change 29.150  New ONLYJOBS program creates 'only' the PDB.JOBS dataset 
ONLYJOBS       (but also creates PDB.STEPS, PDB.PRINT, which are needed 
Jul  9, 2011   to create PDB.JOBS, and creates PDB.SMFINTRV, which may  
               be useful for long running jobs, from SMF 6/30/26, with  
               selection for only some JOB names in the example.        
   Thanks to Jerry Ellis, Liberty Mutual, USA.                          
VMAC110        in MNSEGCL=5 record; eight bytes were inserted by 4.2.   
Jul  7, 2011   See Change 29.135, which added Support for CICSTRAN and  
               CICS Statistics records (which was in MXG 29.03 but was  
               not announced).  This change is required for CICS/TS 4.2 
               if your site creates MNSEGCL=5 (dataset CICSRDS) records,
               but luckily it only causes messages and hex record dumps;
               it does NOT cause an ABEND.                              
   Thanks to Tom Buie, Southern California Edison, USA.                 
Change 29.148  DATEFMT= parameter added to both BLDSMPDB and VMXGALOC to
BLDSMPDB       control the format of the date in the directories created
VMXGALOC       by VMXGLOC.  The default of DATE7 does not allow you to  
Jul  7, 2011   sort the directories into an order that puts the         
               directories in calendar order.  The only formats that    
               would do that are JULIAN and YYMMDD but the code will    
               accept: DATE MMDDYY DDMMYY YYMMDD and JULIAN with        
               whatever length you specify.  If you use one of the      
               MMDDYY etc formats and you specify MMDDYY8. you will get 
               07-05-11 but if you use MMDDYYN8. you will get 07052011. 
Change 29.147  Change 29.032 revised dataset PDB.IPLS to only report a  
VMAC0          true SYSTEM IPL, but the IPLTIME from SMF 90 is on GMT,  
Jul  5, 2011   so this change uses the SMFTIME of the SMF 90 record for 
               IPLTIME so it is always on the Local time zone.          
   Thanks to Rudolf Sauer, T-Systems, GERMANY.                          
Change 29.146  Support for RCD record.                                  
Jul  5, 2011                                                            
Change 29.145  Revisions (again!) to enhance DB2 processing, especially 
ANALDB2R       with large volumes of DB2 SMF data.                      
ASUMDB2A      -Macro variable DB2RSELA added in VMXGINIT.               
ASUMDB2B      -New parameters in ANALDB2R:                              
ASUMDB2G       BUFFDETL=NO - suppresses reading the DB2ACCTB/DB2ACCTG   
ASUMDB2P       JOB=        - select only records with JOB=xxxxxxx       
TRNDDB2A      -Values for Class 3 Suspension in ANALDB2R reports were   
TRNDDB2B       corrected. Values for Global Contention are still being  
TRNDDB2G       reviewed.                                                
TRNDDB2P      -If selection criteria are specified in ANALDB2R:         
VMXGINIT        With PDB=SMF they are passed to READDB2                 
Jul  5, 2011    With PDB=PDB they are passed to ASUMDB2x members in the 
READDB2          DB2RSELA macro variable so that only records that meet 
                 the criteria are summarized.                           
                Performance improvement in ANALDB2R:                    
                 IF PMACC01=YES and PMACC02 NE YES                      
                  Suppresses buffer data and ASUMs of buffer data       
                 If DB2ACCTP has 0 OBS suppress ASUMDB2P                
              -New parameter in READDB2                                 
                JOB=        - select only records with JOB=xxxxxxx      
              -Some changes in ASUMDB2x/TRNDDB2x members are cosmetic to
               eliminate UNINIT messages; others are to pick up the time
               ranges of the records for heading and sorting and adding 
               of a thread count for calculating averages.  KEEPALL=YES 
               reinstated in ASUMDB2P,ASUMDB2G,ASUMDB2B, and ASUMDB2A so
               that ANALDB2R can be used with user-tailored ASUMDB2x    
               datasets (i.e., with dropped variables) without messages 
               about UNINIT variables.                                  
              -In TRNDxxxx, variable THREADs added to SUM list so that  
               ANALDB2R could be executed against Trend datasets.       
   Thanks to Neil Ervin, Wells Fargo Bank, USA.                         
Change 29.144 -IBM IMS Log 56FAx records ARE INDIVIDUAL TRANSACTIONS!   
IMACIMST       Finally, you can track individual IMS transaction CPU and
TYPEIMST       Response times, without using the MXG circumventions     
Jul  2, 2011   and without ANY sorting/merging/etc.  And, the IMF56FA   
               dataset contains the ARRVTIME of the transaction, which  
               is NOT contained in IMS0708 dataset, although it is      
               contained in the IMSTRAN from JCLIMSL6.                  
              -The TYPEIMST member builds only the IMS56FA.IMS56FA      
              -MOST variable names are changed from the prior IMS56FA   
               dataset, so its variables are now identical to those in  
               the "circumvention" datasets IMS0708/IMSTRAN so that your
               existing reports should work without error or with minor 
              -Most of the DLRxxxxx variables in dataset IMS0708 do not 
               exist in the IMS56FA dataset, and variables DTOKEN       
               also missing/blank in IMS56FA, but all of the really     
               important variables are present.                         
              -References to IMS Version 11.0 were corrected to 11.1.   
              -References to IMS Version 10.0 were corrected to 10.1.   
              -Numerous duration variables in the LCODE=45x statistics  
               records are now correctly divided by 4096.               
   Thanks to Raymond J. Smith, UHC, USA.                                
Change 29.143  Extremely strange: INVALID ARGUMENT FOR MOD function and 
Jul  1, 2011   the DEVCLASS and ARGUMENT were both valid, and this was  
               deep in the middle of a BUILDDB run.  Fortunately, the   
               search for the INVALID ARGUMENT message found this note: 
                 SAS Problem Note 13269: Various numeric functions may  
                 return incorrect results.                              
                 The result returned by some numeric functions may be   
                 incorrect.  This problem can occur if the result of    
                 the function is assigned to a variable that is also    
                 used as an argument to the function.  The functions    
                 affected are:                                          
                   BETA, COALESCE, COMB, CONVX, CONVXP, DATDIF, DUR,    
                   PCTL2, PCTL3, PCTL4, PCTL5, PERM, PROBDF, PVP,       
                   RXMATCH, SMALLEST, YRDIF and YIELDP.                 
                 The function may also incorrectly return a missing     
                 value and issue a NOTE to the SAS log reporting that   
                 one of the arguments to the function is invalid.       
                 The SAS Note states:                                   
                   THIS PROBLEM IS FIXED IN SAS 9.1.3 SERVICE PACK 2    
                   AND SAS 9.2.                                         
                 BUT THE ERROR WAS UNDER SAS V9.1.3 WITH SP 4!!!        
                However, the text in the SAS Note and the MOD statement 
                identified in the error message agreed; the same named  
                variable was the input and the output                   
                so the code now uses a different variable name, and the 
                error was eliminated!!!                                 
   Thanks to Jean-Denis Lacourse, CGI, CANADA.                          
Change 29.142 -Additional bits in SMF 90 Subtype 30 are now decoded:    
VMAC90A           SMF9030C='ENCLAVE*SERVICE*CLASS*RESET'                
Jul  1, 2011      SMF9030D='ENCLAVE*QUIESCED'                           
              -Variable PRODUCT is added to all TYPE90nn datasets.      
   Thanks to Siegfried Trantes, Gothaer-Systems, GERMANY.               
   Thanks to Willi Weinberger, Gothaer-Systems, GERMANY.                
   Thanks to Sabine Richard, Gothaer-Systems, GERMANY.                  
Change 29.141  Skipped Change Number.                                   
Change 29.140  Some DB2 Trace Records IFCID 6/7 have QWHSSTCK events    
VMACDB2        before the QWACBSC start time in their DB2ACCT and       
VMACDB2H       DB2ACCP observations.  IBM DB2 support answer:           
Jun 29, 2011     "The logic in DB2 does full thread allocation and then 
                  clocks the begin time for the transaction.  If an I/O 
                  is required during allocation, you may see a 6/7 pair 
                  outside the transaction bounds.  So in the end, this  
                  appears to be working without error."                 
               But the time value in QWHSLUUV in these transaction DOES 
               precede the first IFCID 6, showing that the actual start 
               time WAS captured when the LUUV was created, and that    
               the LUUV creation event should be used for QWACBSC time. 
               That suggestion is under discussion with IBM.            
               While waiting, new variable LUUVTIME is created in both  
               DB2ACCT and DB2ACCTP to be used in place of QWACBSC when 
               analyzing DB2 trace records.  For QWHCATYP=8 REMOTE UOW  
               transactions, LUUV is not a valid time value, but for    
               those records, LUUVTIME is set equal to QWACBSC so that  
               all observations have a usable LUUVTIME for match up     
               with other records.                                      
               Note that for DB2PARTY='R' or ='P' (Rollup, Parallel),   
               LUUVTIME can be MUCH earlier than QWACBSC, because in    
               those records QWACBSC NOT the transaction start time, as 
               is documented in Change 29.131.                          
               Note also that variable ACE rather than QWHSACE should   
               be used to match up transactions; for DB2PARTY='P' obs,  
               ACE is set to QWACPACE, which is constant for all of     
               the records for that transaction (while QWHSACE in the   
               parallel records is not consistent).                     
Change 29.139  RACF variables RES25TEA-RES25TEF, RES25MEA-RES25MEF in   
VMAC80A        dataset TYPE8020 and CLASNAME-CLASNAM5 in TYPE8024 from  
Jun 29, 2011   DTP=43 segments were wrong because the segment count     
               variables NR25SEGS and NR43SEGS were never reset to 0    
               for a new record.                                        
   Thanks to Lars Fleischer, SMT Data, DENMARK.                         
Change 29.138  If you use a LIBNAME statement to allocate a tape SAS    
zOS Only       data library and VGETENG is invoked before any datasets  
Jun 25, 2011   are written to the tape, you may get a 413-18 error from 
               zOS indicating a failure to correctly open the dataset.  
               Your job will still get a CC=0 so it is not a serious    
               error, but it is an annoying warning message.            
                  LIBNAME TEST V9SEQ;                                   
               Will cause:                                              
                  ERROR: OPEN FAILED. ABEND CODE 413. RETURN CODE 18.   
               This can be suppressed by writing a 0 OBS 0 VARS dataset 
               to the tape immediately after the LIBNAME, using         
                 LIBNAME TEST V9SEQ;                                    
                 DATA TEST.A;RUN;                                       
                to suppress the message (although it will also put a    
                very small additional dataset on the tape).             
Change 29.137  UTILARCH - Archival of SAS datasets from a data library, 
UTILARCH       similar to the way OUTLOOK archives its EMAIL store.     
Jun 25, 2011   All observations for chosen datasets dated earlier than  
               the chosen archive date are written to the archive data  
               library (which could be new, or archived observations    
               can be appended to an existing archived dataset), and    
               the observations that were archived are then removed     
               from the original input dataset (which can be rewritten  
               or could be written to a new "unarchived" data library). 
               You can specify:                                         
                 INDD=      LIBNAME of the input data library.          
                 OUTDD=     LIBNAME of the output un-archived, reduced  
                            dataset.  If OUTDD is NOT specified, the    
                            unarchived observations replace the dataset 
                            in the INDD library.  OUTDD is required if  
                            INDD is on TAPE or DASD sequential format.  
                 INARCHIVE= LIBNAME of the current archive data library.
                            If the dataset(s) selected exist in OUTDD,  
                            newly archived observations are APPENDed.   
                 ARCHIVE=   The new archive data library.  This could   
                            be the same as INARCHIVE, as long as they   
                            are not tape nor sequential format on DASD. 
                 DATEVAR=   The name of the date variable to be tested. 
                 KEEPDAYS=  The number of days of detail data to keep   
                            unarchived.  Obs more days old are archived.
                 KEEPDATE=  The date literal (01JAN2011) to keep; obs   
                            earlier than this date are archived.        
                            Either KEEPDAYS or KEEPDATE but not both    
                            must be specified.                          
                 ARCHDAYS=  The number of days of data to keep in the   
                            archive.  If not specified, the archive     
                            will continue to grow in size.              
                 ARCHDATE=  The date literal (01JAN2010) of the oldest  
                            date to be kept in the archive.             
                            Either ARCHDAYS or ARCHDATE or NEITHER, but 
                            not both, must be specified.                
                 DATASETS=  one or more SAS datasets to be archived     
               If the datevar is gt TODAY()-KEEPDAYS, the OBS is        
               written back to the detail.  If it is lt that value      
               but GT today()-sum(keepdays,archdays) it is written      
               to the archive (if archdays is specified - if it is      
               not specified the archive grows to infinity.)            
   Thanks to Brian A. Harvey, HCL America, USA.                         
Change 29.136  Support for WebSphere WAS 8.0 (COMPATIBLE).  These new   
VMAC120        variables are added to dataset TYP1209E:                 
Jun 25, 2011      SM1209FK='CLASSIFICATION*ONLY*TRACE?'                 
Jul 17, 2011      SM1209FM='SMF*REQUEST*ACTIVITY*ENABLED?'              
                  SM1209FP='SMF*REQUEST*ACTIVITY*CPU DETAIL?'           
              -Variable SM1209CE is expanded to 16 bytes.               
              -Variables SM1209DX and SM1209DZ are deprecated; they are 
               still set, but use SM1209GF and SM1209GG because DX/DZ   
               may not exist, since the z/OS Request Info Section       
               (and the Platform Neutral Request Info Section) might not
               be present if this is Async Work.                        
              -New values added to format MG1209T for SM1209CK and to   
               format MG1209C for SM1209EM.                             
              -Jul 17: Updated VMAC120 was moved into SOURCLIB.  This   
               Change was NOT included in MXG 29.05 dated Jul 11, 2011. 
   Thanks to David Follis, IBM, USA.                                    
Change 29.135  Support for CICS/TS 4.2 was available in MXG 29.03 but   
VMAC110        not announced until today when it became GA.  See Change 
Jun 24, 2011   29.063 for details.                                      
Change 29.134  Support for Informatica's POWER EXCHANGE SMF record adds 
EXPOEXCL       five new datasets:                                       
EXPOEXEX         DDDDDD  MXG       MXG                                  
EXPOEXFI         DATASET DATASET   DATASET                              
EXPOEXLI         SUFFIX  NAME      LABEL                                
VMACPOEX         POEXDB  POEXDB2   POWER EXCHANGE DB2                   
Jun 24, 2011   Only POEXLIST and POEXCLIE datasets have been validated  
               with data records, and these problems have been reported 
               to the vendor's support team:                            
               a. The STCK fields are in GMT but there is no GMT Offset;
                  it is possible to use Fuzzy Logic to compare END time 
                  when it is populated (see below) to calculate a GMT   
                  Offset, but well-written SMF records always contain   
                  the GMT Offset that is in effect when the event       
                  records are created, when they contain time/date-times
                  on the GMT clock.                                     
               b. The records contain Subtypes but BIT 1 in SMFxFLG is  
                  not set; the SMF Manual Table 13-2 documents that bit 
                  that should be set for records containing Subtype.    
               c. The Reserved Field at offset 290 in the General       
                  section is only 28 bytes, but was documented as 32    
               d. For the Client Records:                               
                  1. In the General section, the Character START/END are
                     LOCAL zone, but they are identical to each other   
                     and are the same as SMF time (except that SMFTIME  
                     has higher resolution).  The STCK START/END are GMT
                     zone, and are also identical to each other.        
                  2. In the Extended section, the STCK START/END times  
                     are not populated.                                 
                  3. The Reserved Field in the General Section contains 
                     an IP address in character format.                 
                  4. The Client IP Address is not populated.            
                  5. The Client User ID contains hex rather than EBCDIC 
                     text; I don't know if that is correct or not, but  
                     if it contains HEX it needs to be documented.      
               e. For the Listener Records:                             
                  1. The START fields are many days/hours prior to the  
                     SMF TIME, and are constant for each JOB.  The CHAR 
                     field is Local Time Zone, the STCK field is GMT    
                     Time Zone.                                         
                  2. The SMF times are at 5 minute intervals, but are   
                     not synchronized with TIME OF DAY, as all interval 
                     records should be.                                 
                  3. The END TIME fields (both CHAR and STCK) are not   
                     populated, so it is NOT possible to use Fuzzy Logic
                     to reset the Start Time to the local clock.        
   Thanks to Bobbie Justice, Kohl's, USA.                               
Change 29.133 -Variables LPARNAME and LPNUMBER are added and are kept in
VMACVMXA       data is NOT the "LPARNUM" variable in TYPE70PR from RMF. 
Jul  5, 2011   In TYPE70PR, variable LPARNUM is a z/OS assigned sequence
               number that has no connection with the actual Partition  
               number of each LPAR, which is precisely what is stored by
               MONWRITE in its LPNUMBER variable.  In TYPE70PR, there is
               a variable PARTISHN, but that is the actual Partition    
               that wrote that SMF 70 record, and since the IFL LPARs do
               not write SMF records, there is no possible way to match 
               the z/VM MONWRITE LPNUMBER to the IFL LPAR data.         
               However, merging the TYPE70PR IFL observations with the  
               MONWRITE data does not need the LPNUMBER/LPARNUM; the    
               data can be merged by matching the LPARNAME and ENDTIME. 
               Jul 26: See MXG Newsletter FIFTY-EIGHT VM Technical Notes
               for comparison of synchronized MONWRITE and RMF data.    
               And, only SHARED IFLs have actual utilization; DEDICATED 
               IFLs always report 100% utilization in TYPE70PR/ASUM70PR.
Change 29.132 -When sending the output to HTML, PROC GCHART creates     
GRAFCEC        files with the name GCHART GCHART1 GCHART2 etc.  If you  
GRAFWRKX       send the output of both routines to the same place, the  
UTILWORK       second one overwrites the output of the first.  Added a  
Jun 22, 2011   NAME= to all the GCHARTS so the charts created by        
Jul  5, 2011   GRAFWRKX will be GRFWRK GRFWRK1 etc and the ones from    
               GRAFCEC will be GRFCEC GRFCEC1 etc.                      
              -If COMPAT=YES was incorrectly specified (COMPAT went away
               years ago), UTILWORK generated an RMFINTRV member with   
               USEREPRT and USECNTRL set to COMPAT=YES, causing VMXGRMFI
               to look for performance groups.  Now, COMPAT=GOAL is set.
              -If run on ASCII in the background, your session will stop
               to display every graph being produced - a real pain in   
               the butt. This can be suppressed using the GOPTIONS      
               NODISPLAY; option and a graphics catalog will still be   
               created.  So you may want something like:                
                 GOPTIONS NODISPLAY;                                    
                 PROC GCHART GOUT=MYGRAPHS DATA=whatever;               
                  VBAR whatever;                                        
                 GOPTIONS DISPLAY;                                      
                 FILENAME HTML 'C:\MXG\';                               
                 ODS HTML CLOSE:                                        
               The graphs will be constructed and HTML put in C:\MXG\.  
               Clicking on FRAME.HTML will display the graphs after the 
               background task is complete.                             
   Thanks to Chuck Hopf, Independent Consultant, USA.                   
Change 29.131  When DB2 ROLLUP is specified, DB2ACCT and DB2ACCTP will  
VMACDB2        have two observations, the Originating and the Rollup,   
Jun 21, 2011   but only DB2ACCT created DB2PARTY to identify which.     
               This changes creates DB2PARTY in DB2ACCTP dataset.       
               In DB2ACCT, with Parallelized DB2 and ROLLUP specified:  
               -In the DB2PARTY='O' observation, QWACBSC/QWACESC are the
                start and end times, but in DB2PARTY='R' record, both   
                BSC and ESC are set to the END time of the transaction. 
               In DB2ACCTP, with Parallelized DB2 and ROLLUP specified: 
               -In the DB2PARTY='O' observation, QPACSCB/QPACSCE both   
                are missing values, and in DB2PARTY='R' record, both    
                are set to the END time of the transaction.             
               -Parallelization is only recognizable because the value  
                in QPACSCT (and in QPACZITM if zIIPs exist) are much    
                larger than the ELAPSTM in the DB2ACCT 'O' observation. 
               In both DB2ACCT and DB2ACCTP, population of variables is 
               inconsistent between the 'O' and 'R' record; in ACCTP the
               QPACPKID is blank in the 'O' but populated in the 'R',   
               while most other QPACxxxx variables have values in both. 
               In ACCT, the QBnxxxx and QXxxxxx variables are missing in
               the 'R', but most other variables are populated in both. 
   Thanks to Glen Bowman, Wakefern, USA.                                
Change 29.130 -Cosmetic - if you were running with AUTOALOC=YES, a SAS  
BLDSMPDB       warning was generated when a PROC COPY was used to copy  
Jun 21, 2011   the contents of PDB to the day of the week. That is now  
               suppressed unless AUTOALOC=NO.                           
              -New parameter AUTOTRND= added to allow you to add or     
               subtract the TRNDxxxx members that are invoked when      
               trending is being done.  Default TRNDxxxx members are:   
               TRNDRMFI TRND72GO TRNDTMNT TRNDTALO                      
Change 29.129  z/VM 5.4 Crypto Record (5.10) with PRCAPMCT=8 printed    
               and subsequent misalignment, due to 32 undocumented bytes
               for that crypto subtype. Investigating further.          
               IBM has confirmed the documentation of this record is in 
               error; the MXG code and this change will be updated when 
               the IBM correction is available.                         
   Thanks to Victoria Lepak, Aetna, USA.                                
VMACDB2H       QWHDSVNM length (QWHDLOSL) was greater than 16 bytes even
Jun 15, 2011   after Change 29.036 due to error calculating LENLEFT.    
   Thanks to Lorena Ortenzi, UniCredit Group, ITALY.                    
   Thanks to Paolo Uguccioni, UniCredit Group, ITALY.                   
Change 29.127  Support for z/OS 1.12 VMGUEST option to add CPU time to  
VMAC7072       the RMF 70 records for z/OS systems running under z/VM.  
Jun 14, 2011   New variable VMGUEST='Y' is added to PDB.TYPE70PR dataset
               if this z/OS is run under z/VM with the VMGUEST option   
               specified in Monitor I options (in your ERBRMFxx member).
               Two observations in PDB.TYPE70PR exist with the option;  
               one with LPARNAME='PHYSICAL' that contains the Dispatch  
               CPU Time of z/VM itself for this z/OS system, and one    
               with the LPARNAME='VMSystem' for the z/OS CPU TIME.      
               In the RMF Reports:                                      
                 The header of the Partition Data section provides data 
                 about the z/VM partition running the z/OS guest, with  
                 'VMSystem' reported as the MVS PARTITION NAME field.   
                 The IMAGE CAPACITY field displays the CPU capacity     
                 available to the z/VM partition; NUMBER OF VMSystem    
                 PROCESSORS presents the number of processors that are  
                 assigned to the z/VM partition. All other header fields
                 in the RMF report will be N/A.  The partition data     
                 reports data of the z/OS system running as z/VM guest. 
                 The CPU time used by z/VM itself is reported as        
                 partition name '*VMSystem*'. In the reported partition 
                 data, the physical processor utilization represents the
                 logical processor utilization of the z/VM partition.   
Change 29.126  Data set VXSYTEP2 variables kept that were not input:    
VMACXAM           SYTEP1FL  ECMCPBT  ECMCPBTB                           
Jun 13, 2011   and variables input that were not kept:                  
Jun 15, 2011    SYTEP2FL $CHAR1.  /*SYTEP1*FLAGS*/                      
                CSCCMCMM  &RB.4.  /*MAXIMUM*WRITES*PERSEC*/             
                CSCCMCMR  &RB.4.  /*MAXIMUM*READS*PERSEC*/              
                CSCCMCMU  &RB.4.  /*BYTES*PER*DATA*UNIT*/               
                ECMBCBCC  &RB.4.  /*BUSY*CYCLES*USED FOR*I/O*/          
                ECMCCWUC  &RB.4.  /*CHPATH*DATA*UNITS*TOTAL*/           
                ECMCCWU   &RB.4.  /*CHPATH*DATA*UNITS*LPAR*/            
                ECMCDWUC  &RB.4.  /*CHPATH*WRITE*DATA*UNITS*TOTAL*/     
                ECMCDWU   &RB.4.  /*CHPATH*WRITE*DATA*UNITS*LPAR*/      
                ECMCDURC  &RB.4.  /*CHPATH*READ*DATA*UNITS*TOTAL*/      
                ECMCDUR   &RB.4.  /*CHPATH*READ*DATA*UNITS*LPAR*/       
               SYTEP2FL is now kept in place of SYTEP1FL, ECMCPBT/B are 
               no longer kept and the other twelve are now kept.        
               Jun 15: All references to WORKUNITS and WORK*UNITS in the
               variable labels was changed to DATA*UNITS; while Barton  
               documented them as WORKUNITS in the PL/1 descriptors that
               are the only XAM documentation, apparently later in the  
               Velocity reports/documentation they are now called DATA  
               UNITS so I've changed the labels as requested.           
   Thanks to Patricia Hansen, ADP, USA.                                 
Change 29.125  DB2 SMF 102 IFCID 22 INPUT STATEMENT EXCEEDED if length  
VMAC102        of QW0022AN,'ACCESS INDEX NAME' was greater than 18, due 
Jun 10, 2011   to error in MXG logic in handling truncated name fields. 
               Also, for DB2 V10, QW0022PA was incorrectly read as PIB2 
               which caused the new CY/NP/F2/TT variables to be wrong.  
   Thanks to Joe Babcock, Bank of America, USA.                         
Change 29.124  Variables CTGIAREQ and CTGLALRQ were incorrectly kept in 
VMAC111        dataset TY111CXI, but those fields do not exist in the   
May 28, 2011   subtype 07 record, so they have been removed from that   
               dataset's KEEP list.  They do exist in subtypes 01/02/03 
               so they were sometimes populated and sometimes missing in
               TY111CXI dataset, depending on the order of subtypes in  
               the SMF record.  These three different subtype sequences 
               have been observed in SMF 111 records, for no apparent   
               reason, but as each subtype is independent, with this    
               MXG correction, there is no impact on different orders:  
                 00  01  05 04 06 07 03                                 
                 07  00  01 05 04 06 03                                 
                 00  07  01 05 04 06 03                                 
   Thanks to Gordon E. Griffith, Edward Jones, USA.                     
   Thanks to Jeana M. Bechtel, Edward D. Jones, USA.                    
Change 29.123  Support for TMON/IMS Version 3.0 (INCOMPATIBLE).  New    
EXTIMCM1       variables added to TIMSCM, TIMSCP, and TIMSCT datasets.  
EXTIMCM2       Six new datasets, one for each of the three segments in  
EXTIMCM3       the CM and CP records are created.  The datasets TIMSCM, 
EXTIMCP2       TIMSCP2, TIMSCP3, and TIMSCT were validated with data;   
EXTIMCP3       no other subtypes were examined for changes.             
May 28, 2011                                                            
   Thanks to Santosh Kandi, J.C. Penney, USA.                           
Change 29.122  Lengths of variables CUVENDOR $3 and CUSERIAL $12 are now
VMAC74         set in a length statement.  Because they were created by 
May 27, 2011   a SUBSTR function, their default length was set from the 
               length of the input variable, which was $28.             
               Change 25.155 noted that the SUBSTR function sets length 
               from the input variable, while SCAN and other functions  
               default to $200.  The length for these SUBSTR could be   
               set at compile time, because the third argument is fixed,
               but it isn't, so the LENGTH statement sets the length.   
   Thanks to Rudolf Sauer, T-Systems, GERMANY                           
Change 29.121  MXG 28.28-29.04.  DB2 Data Sharing Variables QWHADSGN and
VMACDB2H       QWHAMAMN were blank if there was a Distributed Header for
May 27, 2011   DB2ACCT or DB2ACCTP datasets.  All DDF records have a    
               QWHSTYP=16 segment, but they can exist in other records. 
   Thanks to Paul Volpi, UHC, USA.                                      
Change 29.120  Updates discovered during ITRM Dictionary Build:         
ASUMVMXA      -VMACTPMX. By list _BTMP10 variable TPMCMLNN (MSU) should 
VMAC82         have been TPMCMLNM (LPAR NAME).                          
VMACTPMX      -VMAC82.   Labels 21th/22th/23th/31th/32th/33th corrected.
VMACVMXA      -VMACVMXA                                                 
VMXGINIT       Macro _SUSELOF had disappeared from the _DELTALL macro,  
May 26, 2011   now reinstated.                                          
Jun 22, 2011   Variable SCKRZWCT was a typo and does not exist.         
Nov 17, 2011   Variables NBAD113 and RESETCTR are DROPped.              
               Variable CURALLOC does not exist and reference removed.  
               Variable PLXCPUCN was a typo and does not exist.         
               Variable VL3CAF label is now CAPABILITY vs CAPACILITY.   
              Nov 27, 2011: These updates were not made until today:    
              -ASUMVMXA. Macro variable PSUVMXA now defined in VMXGINIT 
               rather than in ASUMVMXA, and existing macro _LVMAINT is  
               for the location of VMXAINTV and the old _LTYVMXA token  
               is removed.                                              
   Thanks to Chris Weston, ITRM Development, USA.                       
Change 29.119 -The below segment of an INPUT statement was accidentally 
QASAS          left in the middle of a LABEL statement:                 
VMACQACS         DSSRLN  ='DISK*UNIT*SERIAL*NUMBER'                     
May 23, 2011          DSPTROP    &PIB.8. /*TOTAL*PATH*READ*OPERATIONS*/ 
Jul  6, 2011          DSPTWOO    &PIB.8. /*TOTAL*PATH*WRITE*OPERATIONS*/
                      DSWWWNN    $CHAR8. /*WORLD*WIDE*NODE*NAME*/       
                 DSSRVT ='DISK*SERVICE*TIME'                            
               but it did NOT generate a compiler error, because the SAS
               delimiter for label text is the equal sign.  It did cause
               variables DSPTROP DSPTWOO & DSWWWNN to have blank labels,
               and it created a very long label for variable DSSRLN that
               SHOULD have been detected in the QA LONG LABEL tests, but
               wasn't, because the QASAS still had the archaic TYPEQAPM 
               executed AFTER the current TYPEQACS, so the old QAPMDISK 
               (with only 74 variables and none of the above new ones)  
               overwrote the new (103 variables) QAPMDISK dataset in QA.
              -Removing the ancient TYPEQAPM member from the QA stream  
               caused these datasets to no longer be created/documented 
               in the DOCVER member (but this is only cosmetic); those  
               datasets have not been actually available in years).     
                QAPMSTNL QAPMSTNY QAPMX25                               
   Thanks to Richard Schwartz, State Street Bank, USA.                  
Change 29.118  Change 29.084 deleted temporary MXGENG dataset because   
UTILCONT       %VGETENG was thought to only create two macro variables, 
VGETENG        but UTILCONT/VMXGSIZE had undocumented invocations of    
VMXGSIZE       %VGETENG that required that dataset to exist.  The new   
May 18, 2011   CLEANUP=YES/NO is added to all three members to allow    
               the dataset to be kept and deleted later when needed.    
   Thanks to Paul Naddeo, FISERV, USA.                                  
Change 29.117 -ASCII only, CICSTRAN variables RTYPE/RRTYPE should have  
UTILEXCL       been input with $EBCDIC informat in VMAC110/UTILEXCL.    
VMAC110       -VMACSVIE, variable CNTL_TIME in SV03THRE dataset is now  
VMACSVIE       converted back from GMT to local time zone.              
May 18, 2011  -VMACSVIE, variable DB2_PROGRAM in SV27DB2 is $ASCII.     
              -VMACSVIE, variable SCUCRSTG is no longer formatted.      
              -VMACSVIE stores CICS task number as PIB4 and not PD4 so  
               these variables inputs were changed:                     
              -VMACSVIE, variable THRS_GROUP and THRS_CLASS corrected.  
   Thanks to Matthew Chappell, Dept. of Transport Main Roads, AUSTRALIA 
====== Changes thru 29.116 were in MXG 29.04 dated May 17, 2011======== 
Change 29.116  The SQL Statement Number in all of the original SQL Trace
FORMATS        IFCIDS 53,58,59,60,61,64,65,66 plus 125,183, and 247 have
VMAC102        been wrong (fixed value of 16448 usually) ever since they
May 14, 2011   were relocated and increased from 2 to 4 bytes in DB2 V8.
               In making this update, several overlooked variables are  
               also now output in these T102Snnn DB2 trace datasets, and
               several new formats were created to decode them.         
   Thanks to Joachim Sarkoschitz, DATEV, GERMANY.                       
Change 29.115  Arguments PDB= and PDBOUT= were not UPCASED, causing  the
GRAFWRKX       PDB=trend to not be recognized.  Now they are.           
May 10, 2011                                                            
Change 29.114 -Testing JCLSIMPL default example exposed macro language  
BLDSMPDB       syntax errors corrected in this BLDSMPDB:                
May 10, 2011      NOTE: Line generated by the macro variable "RERUN".   
May 15, 2011       20     "                                             
                   ERRROR 77-185: Invalid number conversion on ""d.     
              -Tests also exposed errors in VMXGDBSS where SHIFT was not
               being created in ASUMDBSx datasets, causing a later      
               failure when the ASUMs were executed.                    
              -New PDB=NONSMF argument added to BLDSMPDB to support the 
               new JCLSMOTH non-SMF processing in Change 29.105.        
   Thanks to Vinnie Falzone, The Prudential, USA.                       
Change 29.113  Variables CTGLALRQ (Lifetime) and CTGIAREQ (Interval) in 
VMAC111        TY111CXI dataset were reversed.                          
May 10, 2011                                                            
   Thanks to Gordon E. Griffith, Edward Jones, USA.                     
Change 29.112  Documentation only.  This paragraph was added:           
IMACACCT         If you have created a SPIN data library and then decide
May  5, 2011     to DROP ACCOUNTn and LENACCTn variables that were kept 
                 originally, you will need to copy and DROP the unwanted
                 ACCOUNTn and LENACCTn variables from the three datasets
                 SPIN30_1, SPIN30_5, and SPIN26, and copy & DROP the    
                 unwanted SACCTn variables from SPIN30_4, and then copy 
                 the revised datasets back into your SPIN data library. 
                 Otherwise, the unwanted will still be in both the SPIN 
                 and the PDB JOBS/STEPS/PRINT datasets.                 
   Thanks to Stan Dylnicki, Royal Bank of Canada, CANDADA               
Change 29.111  For CICS Attach, the CICS TRAN name is extracted from the
VMACDB2        QMDACORR field, but that value is sometimes wrong and the
May  4, 2011   correct CICS TRAN name exists instead in QWHCCV field, so
               MXG now uses QWHCCV as the source of CICS TRAN.          
               A PMR will be opened with IBM to determine if this is an 
               IBM error, since DSNWMSGS states that QWHCCV/QMDACORR are
               supposed to be the same.                                 
   Thanks to Richard Schwartz, State Street Bank, USA.                  
Change 29.110  The invocation of the dataset exit token _EIMSTRN was    
TYPEIMSA       accidentally removed from TYPEIMSA in MXG 28.28, but is  
May  4, 2011   in now reinstated.                                       
   Thanks to Craig Collins, State of Wisconsin DOA, DET, USA.           
VMACDB2        were incorrectly kept in both DB2STAT0 and DB2STAT1 and  
May  4, 2011   were not deaccumulated in _SDB2ST0.                      
   Thanks to Jane S. Stock, USPS, USA.                                  
Change 29.108 -Invalid UARG record was not true; the MXG test for NWORDS
VMACNMON       LE 5 should have been LE 4.  Additionally, the UARGTYPE=2
May  4, 2011   UARG record now sets THCOUNT=1 so that observations will 
               be created in the PDB.NMONUARG dataset.                  
              -INVALID ARGUMENT error messages are caused by invalid VM 
               record that has the second word T0001, an interval marker
               which should contain data values, but the invalid record 
               instead contains the field descriptions. MXG now detects 
               and prints a clear error message referencing this change.
   Thanks to Xiaobo Zhang, FISERV, USA.                                 
Change 29.107  Format MG099TC is updated to decode 70+ new trace codes  
FORMATS        added by z/OS 1.12 for the SMF 99 variable S99TCOD.      
May  4, 2011                                                            
   Thanks to Michael Oujesky, Bank of America, USA.                     
Change 29.106  JES3 PDB.JOBS variable CLASS is the 8-byte JOBCLASS when 
BUIL3005       the job was read-in, from the TYPE26J3 purge record, IBM 
May  3, 2011   field SMF26CLN. CLASS is stored into JOBCLASS when CLASS 
               is non-blank (i.e., when a Purge Record exists).  But the
               job class can be changed in exits, in particular, in the 
               IATUX29 exit; that new JOBCLAS8 value is in the SMF 30   
               records, so this change now keeps JOBCLASS8 in the JES3  
               PDB.JOBS dataset, where it's label will be               
               If no purge record was found by BUIL3005, the value in   
               JOBCLAS8 from the 30 record is stored into JOBCLASS.     
   Thanks to Jeff Ramsay, ArcelorMittal, USA.                           
Change 29.105  JCLSIMPL and JCLSPxxx examples use UTILBLDP/BLDSMPDB and 
BLDSIMPL       are THE now-recommended z/OS jobs for a "SIMPLE" BUILDPDB
BLDSPMTH       or the "SPLIT SMF" family of "BUILDPDB" jobs.            
BLDSPSMA       JCLSIMPL creates a "simple", PDB library, with one job   
BLDSPSMB       that reads the SMF file, showing how to add an SMF record
BLDSPSMC       and invoking all of the default ASUMxxxx members to build
BLDSPSMD       a "single", default PDB data library from raw SMF data.  
BLDSPSME       You could do the same with BUILDPDB and the EXPDBxxx exit
BLDSPUOW       members, but these more recent utility macros are now the
BLDSPWEK       recommended way to build/tailor a simple BUILDPDB:       
JCLSIMPL         UTILBLDP - defines what data is to be created in a PDB.
JCLSPCPY                    You can add, subtract, or change what's kept
JCLSPGDG                    by each of these jobs use UTILBLDP to create
JCLSPLIT                    a specific suit of MXG datasets in a PDB    
JCLSPMTH                    built from SMF data records.                
JCLSPOTH         BLDSMPDB - flexible job manager creates day/week/etc   
JCLSPSMA                    PDBs using the UTILBLDP execution preceding 
JCLSPSMB                    its invocation to define the PDB contents.  
JCLSPSMC                    Processes SMF and non-SMF data records.     
JCLSPSME       JCLSPxxx is a family of jobs to read "split" subsets of  
JCLSPUOW       SMF and other data records to parallelize the BUILDPDB,  
JCLSPWEK       using the above+ UTILBLDP and BLDSMPDB members:          
VMXGALOC        JCLSPGDG - run once to create GDGs, and then never again
VMXGPARS                   unless there is a need to alter a GDG base or
May 16, 2011               to change dataset names.                     
Nov  9, 2011    JCLSPLIT - first job in daily stream - standalone -     
                           splits the daily SMF into pieces for         
                           subsequent processing                        
                        SMF.ALL      - All SMF for archive              
                        SMF.CICS     - SMF 110.1                        
                        SMF.DB2      - SMF 101/102                      
                        SMF.IO       - SMF 14/15/42/61/65/66/74/240/241 
                        SMF.MQ       - SMF 115/116                      
                        SMF.SPLITPDB - All other SMF records            
                 concurrently to process the split SMF files:           
                 JCLSPSMA - Read only CICS SMF 110, create:             
                      CICSTRAN.CICSTRAN CICSBAD.CICSBAD.                
                 JCLSPSMB - Read only DB2 SMF 101/102, create:          
                        ASUMDB2A ASUMDB2B ASUMDB2G ASUMDB2P ASUMDB2R    
                 JCLSPSMC - Read only I/O records, create:              
                   PDB: TYPE1415 TYPE42AD TYPE42AU TYPE42CC TYPE42CU    
                        TYPE42CV TYPE42DS TYPE42EX TYPE42NF TYPE42NU    
                        TYPE42SC TYPE42SR TYPE42TO TYPE42VL TYPE42VS    
                        TYPE42VT TYPE42XR TYPE42XV TYPE42S1 TYPE42S2    
                        TYPE42S3 TYPE42S4 TYPE42D1 TYPE42D2 TYPE42D3    
                        TYPE42D4 TYPE42L1 TYPE42L2 TYPE42P1 TYPE42P2    
                        TYPE42P3 TYPE42X1 TYPE42X2 TYPE42X3 TYPE42X4    
                        TYPE4220 TYPE4221 TYPE422A TYPE4222 TYPE4223    
                        TYPE4224 TYPE424A TYPE4225 TYPE4226 TYPE4237    
                        TYPE6156 TYPE64   TYPE64X  TYPE74   TYPE74CA    
                        TYPE74ID TYPE74CF TYPE74CO TYPE74LK TYPE74ME    
                        TYPE74OM TYPE74PA TYPE74ST TYPE74DU TYPE74SY    
                        TYPE74TD TYPE746B TYPE746F TYPE746G TYPE747P    
                        TYPE747C TYPE748  TYPE748A TYPE748R TYPE748X    
                        HSMVSRFU HSMVSRST HSMWWFSR HSMWWVOL             
                 JCLSPSMD - Read only MQ records, create:               
                        MQMLOG   MQMMSGDM MQMQUEUE                      
                 JCLSPSME - Read all remaining SMF, create:             
                       ASUM70GC ASUM70GL ASUM70LP ASUM70PR ASUMCEC      
                       DB2GBPAT DB2GBPST DB2STAT0 DB2STAT1 DB2STAT2     
                       DB2STAT4 DB2STATB DB2STATR DB2STATS DDSTATS      
                       IPLS     IPLSMF   JOBS     NJEPURGE PRINT        
                       RMFINTRV RMFWKLRV SMFINTRV SMFRECNT SPIN26       
                       SPIN30TD SPIN30_1 SPIN30_4 SPIN30_5 SPIN6        
                       TAPES    TYPE0203 TYPE23   TYPE30MR TYPE30MU     
                       TYPE30OM TYPE30_6 TYPE7    TYPE70   TYPE7002     
                       TYPE70EN TYPE70PR TYPE70X2 TYPE70Y2 TYPE71       
                       TYPE72   TYPE7204 TYPE725A TYPE725B TYPE725C     
                       TYPE725D TYPE725E TYPE725F TYPE725G TYPE725H     
                       TYPE725I TYPE725J TYPE725K TYPE725L TYPE725M     
                       TYPE72DL TYPE72GO TYPE72MN TYPE72SC TYPE73       
                       TYPE73L  TYPE73P  TYPE75   TYPE77   TYPE78       
                       TYPE78CF TYPE78CU TYPE78IO TYPE78PA TYPE78SP     
                       TYPE78VS TYPE89   TYPE892  TYPE89I  TYPESTAT     
                 JCLSPOTH - DCOLLECT, TMC.                              
                 JCLSPUOW - after JCLSPLTA and JCLSPLTB have run,       
                            build PDB.ASUMUOW from CICSTRAN and DB2ACCT,
                            build PDB.CICS from PDB.ASUMUOW.            
                            Nov 9:  (+1) instead of (0) for PDB and SPIN
                            DDnames, and DISP/SPACE parameters added    
                 JCLSPCPY - Copies these datasets into PDB library:     
                            ASUMCACH CICS     ASUMUOW  ASUMDB:          
                 JCLSPWEK - weekly job using BLDSMPDB to drive the bus  
                 JCLSPMTH - monthly job using BLDSMPDB to drive the bus 
               BLDSPxxx members are for ASCII execution to create the   
               same suite of PDB datasets. except that there is no      
               GDG nor SPLIT members.                                   
                 BLDSPSMA - Read only CICS SMF 110, create:             
                      CICSTRAN.CICSTRAN CICSBAD.CICSBAD.                
                 BLDSPSMB - Read only DB2 SMF 101/102, create:          
                        ASUMDB2A ASUMDB2B ASUMDB2G ASUMDB2P ASUMDB2R    
                 BLDSPSMC - Read only I/O records, create:              
                   PDB: TYPE1415 TYPE42AD TYPE42AU TYPE42CC TYPE42CU    
                        TYPE42CV TYPE42DS TYPE42EX TYPE42NF TYPE42NU    
                        TYPE42SC TYPE42SR TYPE42TO TYPE42VL TYPE42VS    
                        TYPE42VT TYPE42XR TYPE42XV TYPE42S1 TYPE42S2    
                        TYPE42S3 TYPE42S4 TYPE42D1 TYPE42D2 TYPE42D3    
                        TYPE42D4 TYPE42L1 TYPE42L2 TYPE42P1 TYPE42P2    
                        TYPE42P3 TYPE42X1 TYPE42X2 TYPE42X3 TYPE42X4    
                        TYPE4220 TYPE4221 TYPE422A TYPE4222 TYPE4223    
                        TYPE4224 TYPE424A TYPE4225 TYPE4226 TYPE4237    
                        TYPE6156 TYPE64   TYPE64X  TYPE74   TYPE74CA    
                        TYPE74ID TYPE74CF TYPE74CO TYPE74LK TYPE74ME    
                        TYPE74OM TYPE74PA TYPE74ST TYPE74DU TYPE74SY    
                        TYPE74TD TYPE746B TYPE746F TYPE746G TYPE747P    
                        TYPE747C TYPE748  TYPE748A TYPE748R TYPE748X    
                        HSMVSRFU HSMVSRST HSMWWFSR HSMWWVOL             
                 BLDSPSMD - Read only MQ records, create:               
                        MQMLOG   MQMMSGDM MQMQUEUE                      
                 BLDSPSME - Read all remaining SMF, create:             
                       ASUM70GC ASUM70GL ASUM70LP ASUM70PR ASUMCEC      
                       DB2GBPAT DB2GBPST DB2STAT0 DB2STAT1 DB2STAT2     
                       DB2STAT4 DB2STATB DB2STATR DB2STATS DDSTATS      
                       IPLS     IPLSMF   JOBS     NJEPURGE PRINT        
                       RMFINTRV RMFWKLRV SMFINTRV SMFRECNT SPIN26       
                       SPIN30TD SPIN30_1 SPIN30_4 SPIN30_5 SPIN6        
                       TAPES    TYPE0203 TYPE23   TYPE30MR TYPE30MU     
                       TYPE30OM TYPE30_6 TYPE7    TYPE70   TYPE7002     
                       TYPE70EN TYPE70PR TYPE70X2 TYPE70Y2 TYPE71       
                       TYPE72   TYPE7204 TYPE725A TYPE725B TYPE725C     
                       TYPE725D TYPE725E TYPE725F TYPE725G TYPE725H     
                       TYPE725I TYPE725J TYPE725K TYPE725L TYPE725M     
                       TYPE72DL TYPE72GO TYPE72MN TYPE72SC TYPE73       
                       TYPE73L  TYPE73P  TYPE75   TYPE77   TYPE78       
                       TYPE78CF TYPE78CU TYPE78IO TYPE78PA TYPE78SP     
                       TYPE78VS TYPE89   TYPE892  TYPE89I  TYPESTAT     
                 BLDSPOTH - DCOLLECT, TMC.                              
                 BLDSPUOW - after JCLSPLTA and JCLSPLTB have run,       
                            build PDB.ASUMUOW from CICSTRAN and DB2ACCT,
                            build PDB.CICS from PDB.ASUMUOW.            
                 BLDSPWEK - weekly job using BLDSMPDB to drive the bus  
                 BLDSPMTH - monthly job using BLDSMPDB to drive the bus 
Change 29.104 -Interval summarization of CICS Statistics CICLDR dataset 
ASUMCLDR       in PDB.ASUMCLDR and Trending in TREND.TRNDCLDR is useful 
TRNDCLDR       to track CICS Program Loader activity.                   
TRNDCELP      -Trending for ASUMCELP and ASUM70LP per-LPAR datasets,    
TRND70LP       adds zIIP, zAAP, and IFL statistics.                     
May  1, 2011                                                            
   Thanks to Chuck Hopf, Independent Consultant, USA.                   
Change 29.103  New option RESULTS=FINDVAR will find every dataset in    
VMXGSRCH       every allocated LIBNAME, or in specific LIBNAMES, that   
May  1, 2011   contains any of the variables listed in VARS= argument.  
Jul  8, 2011   With FINDVAR option, the VALUE= argument is ignored.     
               Jul 2011: COUNT option was restored in code, was lost.   
   Thanks to Chuck Hopf, Independent Consultant, USA.                   
Change 29.102  Change 29.052 documented this MONTHxxx error 180-322:    
MONTHASC        NOTE: Line generated by the macro function "SUBSTR".    
MONTHBLD                ---                                             
MONTHDSK                180                                             
READDB2         ERROR 180-322: Statement is not valid or it is used out 
UTILBLDP                     of proper order.                           
May  2, 2011  was caused by the %CMPRES macro (in SASAUTOS) generating  
              a line of code when it should have stored that text in a  
              macro variable, and that this "SAS V9.1.3 ONLY" error was 
              circumvented by replacing %CMPRES with %QCMPRES.  But this
              error is also in SAS V9.2, both ASCII and z/OS platforms, 
              on May 1, but not on May 2.  On May 1, a Sunday, with the 
              default STARTDAY of MON, the to-be-generated SET statement
              has the (maximum) of six daily and five weekly elements,  
              which tripped up %CMPRES, while %QCMPRES worked fine.     
              But on May 2, with only five week tokens to be generated, 
              both %CMPRES and %QCMPRES worked fine.                    
             -Detailed traces with all possible %MACRO debugging options
              failed to reveal the actual cause of the error.           
             -But, the SAS documentation for %CMPRES and %QCMPRES states
              "The %CMPRES and %QCMPRES macros compress multiple blanks 
               and remove leading and trailing blanks.  If the argument 
               might contain a special character or mnemonic operator:  
                  & % ' " ( ) + - * / < > =  ^ ~ ; , # blank           
                  AND OR NOT EQ NE LE LT GE GT IN                       
               use %QCMPRES.                                            
               %CMPRES returns an unquoted result, even if the argument 
               is quoted.                                               
               %QCMPRES produces a result with the special characters   
               and mnemonic operators masked, so the macro processor    
               interprets them as text instead of as elements of the    
               macro language."                                         
              Since all MXG uses of %CMPRES are objects of a %LETs for a
              text string, and since some of those text strings can have
              those special characters, all %CMPRES are now %QCMPRES.   
   Thanks to Rodger Foreman, Acxiom, USA.                               
Change 29.101  Support for z/VM 6.2, COMPATIBLE RECORD CHANGES BY IBM.  
EXISFILC       MXG code might fail if you create SYTLCK (0.23) records; 
EXISFISA       See note at bottom to read 6.2 data with prior MXG code. 
EXISFISC       z/VM 6.2 MONWRITE is a MAJOR enhancement, with these 19  
EXISFNOD       new records (VXPRCMFC has the z/OS SMF 113 Counters!):   
EXMTRISC         1   23  MTRISC VXMTRISC ISFC End Point Configuration   
EXMTRSSI         1   24  MTRILC VXMTRILC ISFC Logical Link Configuration
EXMTRTOP         1   25  MTRSSI VXMTRSSI SSI Configuration Information  
EXPRCMFC         1   26  MTRTOP VXMTRTOP System Topology                
EXPRCTOP         4   11  USERLS VXUSERLS Guest Relocation Started       
EXSSISCH         4   12  USERLS VXUSERLS Guest Relocation Ended         
EXSSISLT         5   13  PRCMFC VXPRCMFC CPU-Measurement Facility       
EXSSISCS         5   14  PRCTOP VXPRCTOP System Topology                
EXSSIXDI         6   31  IODMDE VXIODMDE Minidisk Activity              
EXSSIXLK         9    1  ISFISC VXISFISC ISFC End Point Status Change   
EXUSERLS         9    2  ISFISA VXISFISA ISFC End Point Activity        
EXUSERLS         9    3  ISFILC VXISFILC ISFC Logical Link Def Change   
FORMATS          9    4  ISFNOD VXISFNOD ISFC Logical Link Activity     
IMACVMXA        11    1  SSISSC VXSSISSC State Change Synch Activity    
VMACVMXA        11    2  SSISMI VXSSISMI State/Mode Information         
VMXGINIT        11    3  SSISCH VXSSISCH State Change/Event             
May  6, 2011    11    4  SSISLT VXSSISLT Slot Definition                
Oct 22, 2011    11    6  SSIXLK VXSSIXLK XDISK Serialization Sample     
Nov  2, 2011    11    7  SSIXDI VXSSIXDI XDISK Activity                 
               and with changes to these 36 existing datasets:          
                0  VXSYTPRP (0.02) VXSYTRSG (0.03) VXSYTSHS (0.07)      
                   VXSYTUSR (0.08) VXSYTUWT (0.12) VXSYTSCP (0.13)      
                   VXSYTXSG (0.14) VXSYTCUM (0.17) VXSYTLCK (0.23)      
                1  VXMTREPR (1.01) VXMTRSYS (1.04) VXMTRPRP (1.05)      
                   VXMTRDEV (1.06) VXMTRMEM (1.07) VXMTRSPR (1.09)      
                   VXMTRDDR (1.14) VXMTRUSR (1.15) VXMTRCCC (1.18)      
                2  VXSCLSHR (2.09) VXSCLIOP (2.11)                      
                3  VXSTORSG (3.01) VXSTORSP (3.02) VXSTOASP (3.04)      
                   VXSTOADD (3.21)                                      
                4  VXUSELON (4.01) VXUSELOF (4.02) VXUSEACT (4.03)      
                   VXUSEINT (4.04) VXUSEATE (4.09)                      
                5  VXPRCCFN (5.06) VXPRCCFF (5.07) VXPRCAPC (5.09)      
                6  VXIODVON (6.01) VXIODVSW (6.21)                      
                8  VXVNDSES (8.01)                                      
               10  VXAPLSDT (10.02)                                     
              -Dataset VXPRCMFC is created with TYPE113 variable names, 
               including all of the metrics from John Burg's papers, so 
               the existing ASUM113 dataset can be used to summarize the
               new hardware counters from either z/VM or z/OS records.  
              -The sort order was changed on some existing datasets that
               had not previously been validated for the NODUP option.  
               The _Bdddrrr "BY LIST" macro for each dataset has been   
               validated to ensure that  PROC SORT NODUP; BY _Bdddrrr;  
               removes duplicates; some existing dataset's _Bdddrrr list
               was insufficient and had to be extended to ensure the    
               physical adjacency of duplicate records.                 
                 The validation reads the same MONWRITE file twice and  
                 the _SVMXA macro sorts all datasets. The SAS log       
                 message for each sort is examined to ensure that       
                 exactly one half of the input observations were        
                 reported as duplicates.                                
              -The validation of the BY LIST with NODUP is NOT because  
               MONWRITE has a duplicate record problem; it is required  
               for the DIF() validation of the MXG deaccumulation logic.
               Because MONWRITE records contain accumulated values, the 
               deaccumulation logic (a DATA step in the _Sdddrrr macro) 
               uses the same "BY LIST" _Bdddrrr macro as the NODUP did. 
               The deaccumulated datasets are then examined with PROC   
               MEANS for MIN.  If a non-accumulated field (cardinal,    
               min, max, end point) is deaccumulated, or if its sort    
               order is not correct, its minimum value will be negative.
              -This change was a significant project; there were 3417   
               source lines inserted, and 730 lines deleted in the main 
               VMACVMXA code member, which now has 24,653 lines.  The   
               update took from Monday thru Saturday, 40-50 hours.      
               I documented the original VM/XA MONWRITE development in  
               1988, 150 hours across 10 days for 75 datasets and 15,000
               lines, I think, but I can't find that note right now!    
              -Not new in z/VM 6.2, but it has always been the case that
               when the same MONWRITE data file was read twice, two MXG 
               created datasets had an odd number of observations, where
               an even number should have been created. The two datasets
               VXMTREPR (1.01) and VXMTRDDR (1.14) records are written  
               at MONITOR START, but prior to the MTRSYS (1.04), which  
               contains the GMT Offset (SYSZONE) value.  MXG deletes    
               records with SYSZONE missing, because the MRHDRTOD can't 
               be converted to local time and thus is unknown.          
               But because SYSZONE is retained so it can be used for all
               other records in this collect, if data from a different  
               system is concatenated, the new system's 1.01 record will
               use the non-missing SYSZONE from the prior system and was
               output with the wrong MRHDRTOD value.  Fortunately, IBM  
               has added SYSZONE field to 1.01 MONITOR START record so  
               the MXG logic now exploit that addition and will use the 
               1.01 for MONITOR START when it contains SYSZONE.         
              -Also not new in z/VM 6.2, there is no SYNC option to make
               MONWRITE interval records synchronized with TIME of DAY; 
               the intervals when the MONITOR SAMPLE INTERVAL or the    
               MONITOR START command is issued.  A formal requirement   
               has just been submitted, and this text will be updated if
               IBM accepts that request.  In the interim, this example  
               from IBM can be used to STOP and reSTART the monitor with
               TOD synchronization to second zero of the next minute:   
                 /* Make the monitor intervals start on second zero */  
                 'CP MONITOR STOP'                                      
                 Parse value time('N') with hh ':' mm ':' ss .          
                 mm=mm+1      /* Wait for the next minute*/             
                 If ss=59 then mm=mm+1    /*May need a bit more time*/  
                 If mm>60 then do         /* Overflow to the hour*/     
                 'WAKEUP' hh':'right(mm,2,0)':00'  /*Wait*/             
                 'CP MONITOR START'                /*Start the monitor*/
                 Note:  changing the  mm=mm+1  to  hh=hh+1              
                    and changing to   'WAKEUP' hh':00:00'               
                 will cause MONWRITE data to be on an hourly boundary.  
               To process z/VM 6.2 records with MXG 29.03 or earlier,   
               this code will skip all 0.23 records:                    
               //SYSIN DD *                                             
                 %LET MACVMXX=                                          
                     IF MRHDRDM=0 AND MRHDRRC=23 THEN DO;               
                       INPUT +SKIP @;                                   
                       GOTO MWENDIT;                                    
                 %INCLUDE SOURCLIB(....);                               
Change 29.100  Support for GDPS Global Mirror V3R8 SMF ID=105 record,   
EXTY1051      which creates these two new datasets:                     
EXTY1052       dddddd  Dataset   Description                            
IMAC105        TY1051  TYPE1051  GDPS SESSION DATA                      
VMAC105        TY1052  TYPE1052  GDPS LOGICAL SUBSYSTEM DATA            
Apr 28, 2011                                                            
   Thanks to Paul Volpi, UHC, USA.                                      
Change 29.099 Omegamon User SMF "OMCI" record tested for versions before
VMACOMCI      testing for SUBTYPE and RECSUBTY, and records from the old
Apr 27, 2011  version 420 printed error messages that that version was  
              unknown.  But these were ID=112 records with SUBTYPE=203  
              and RECSUBTY=0, which are "112s" and not "OMCI", so the   
              code now accepts '420' for version but also deletes these 
              non-OMCI records ahead of the version test.               
   Thanks to Richard Schwartz, State Street Bank, USA.                  
Change 29.098  Variables ICFCPUS, IFLCPUS, IFACPUS, ZIPCPUS, only in the
VMXG70PR      PDB.ASUMCEC dataset, were wrong (too high, they were the  
Apr 27, 2011  SUM across all LPARs with those specialty engines).       
   Thanks to Otto Burgess, OPM, USA.                                    
EXCICRDD      (on ASCII) SMF 110 subtype 1 MNSEGCL=5 records, if any DPL
IMAC110       DPL Resource Segments exist (i.e., MNR5NUMX GT 0).        
VMAC110       DPL segments, new in CICS/TS 4.1, were not input, causing 
VMXGINIT      mis-alignment, but they now create new CICSRDPL dataset.  
Apr 26, 2011  Also, new variables added by CICS/TS 4.1 are now output   
              in the existing CICSRDS dataset that were overlooked.     
   Thanks to Paul Volpi, UHC, USA.                                      
Change 29.096  Documentation only. APAR PK99058 corrects Tivoli Storage 
VMAC42        Manager z/OS Server Accounting Record CPU usage field,    
Apr 25, 2011  (variable CLICPUTM in TYPE42AD), in TSM Version 5.5 only, 
              which had failed to populate that field.                  
   Thanks to Jacob Nudel, Thomson Reuters, USA.                         
Change 29.095  Parameter DALYKEEP= added to bldsmpdb to control which   
BLDSMPDB      dataset are selected by the PROC COPY from the PDB into   
Apr 22, 2011  the Day-Of-Weed dataset, and can be a SELECT statement or 
====== Changes thru 29.094 were in MXG 29.03 dated Apr 19, 2011======== 
VMAC110        (if you did NOT use UTILEXCL to create IMACEXCL).  A mass
Apr 19, 2011   change command went awry and inserted 16* in all of the  
               time duration variables in blocks of "fall thru" code for
               CICS/TS 3.2 or later.  This SHOULD have printed the MXG  
               ***ERROR VMAC110: CPU 10X LARGER THAN ELAPSED.           
               See Change 29.076 for the CPU 10X LARGER enhancement.    
   Thanks to Matthew Chappell, Dept. of Transport Main Roads, AUSTRALIA 
Change 29.093  INPUT STATEMENT EXCEEDED for subtype 79; value '1120' was
VMAC85         added to the two tests for variable R85PVRM in the block 
Apr 18, 2011   that reads subtype=79, support z/OS 1.12 INCOMPAT change.
   Thanks to Robert Chavez, Florida Power and Light, USA.               
Change 29.092  Variables ZIPCPUS and IFACPUS in PDB.ASUMCEC/PDB.ASUM70PR
VMXG70PR       were the average number online, but that included parked 
Apr 13, 2011   time.  They are now corrected to count the number of     
               AVERAGE*ONLINE*NOTPARKED specialty engines.  Variables   
               NRZIPCPU and NRIFACPU are the number installed.          
   Thanks to Jim S. Horne, Lowe's Companies, USA.                       
Change 29.091  If MXG's default COMPRESS=YES is changed to COMPRESS=NO, 
VMAC102        all SQL Text variables are broken into 100 byte chunks   
Apr 13, 2011   and multiple observations are created in the T102Tnnn    
               datasets, but the last two characters of each chunk have 
               been missing since DB2 V8.1 changed the structure of     
               the length fields; MXG still subtracted 2 bytes which it 
               should not have. DB2 SQL text is created in these IFCIDS:
               63 124 140 141 142 145 168 which are now all corrected.  
   Thanks to Mark Tomlinson, Lloyds Banking, ENGLAND.                   
   Thanks to Stephen Hoar, Lloyds Banking, ENGLAND.                     
Change 29.090  Typo for the IMS08D and IMS0A08 datasets _Wdddddd entries
VMACIMS        had _VIMS08 _KIMS08 which are now _VIMS08D _KIMS08D and  
Apr 13, 2011   _VIMS0A8 and _KIMS0A8 respectively.  Since the _VIMS08   
               and _VIMS08D keep the same variables, the IMS0708 dataset
               was not impacted, and, fortunately, no one uses IMS0A78. 
   Thanks to Rudolf Sauer, T-Systems, GERMANY                           
Change 29.089 -The z/VM MONWRITE dataset PDB.VXBYUSR has one observation
VMACVMXA       for every VMDCPUAD (CPU ADDRESS) configured for each VM, 
VMXGINIT       so it doesn't have the interval total for each machine.  
Apr 13, 2011   The new PDB.VXINTUSR sums PDB.VXBYUSR to create one obs  
               for each interval for each machine, counting configured  
               (ENGCONFG) and online (ENGONLIN) engines.                
              -Variables VMDVTMP VMDTTMP VMDVTMS VMDTTMS are correctly  
               deaccumulated with this change.                          
   Thanks to Ron Lewis, State Street Bank, USA.                         
Change 29.088  These "user id" variables are added to TMDBDB2 dataset   
VMACTMDB        DBHCEUID DBHCEUTX DBHCEUWN                              
Apr 12, 2011   (and should have been added a long time ago!).           
   Thanks to Patricia Abel, Regie des rentes du Quebec, CANADA.         
   Thanks to Liliane Paquet, Centre de services partages Quebec, CANADA.
Change 29.087  Comments in IMACIMS7 and IMACIMS7 for _IMSVERS values are
IMACIMS        inconsistent; 10.1 or 11.1 were listed, but the values   
Apr 12, 2011   needed are only 10.0 and 11.0 (so the misleading values  
               worked fine!).                                           
               And Change 28.311 did not change the datasets created;   
               that change only restructured the internal IMS processing
               code to separate and then recombine the TM and DBCTLs.   
   Thanks to Daniel Strgarsek, SAS Institute, GERMANY.                  
====== Changes thru 29.086 were in MXG 29.03 dated Apr 11, 2011======== 
Change 29.086  The QA conflict report from DOCVER showed SYSTEM was $8  
ANALID         in PDB.SMFRECNT, but SYSTEM is always $4.  After 2 hours 
Apr 10, 2011   of tests with inserted PROC CONTENTS, I found it only    
               occurred when there were no observations in TYPEID, which
               is normal for the QASAS job that creates DOCVER, and then
               remembered that when the old PROC FREQ was replaced with 
               the enhanced ANALID (with PROC TABULATE to capture both  
               counts and bytes), an extra step was needed to create the
               PDB.SMFRECNT (because PROC TABULATE didn't, with no obs),
               and finally found the statement SYSTEM='        '; that  
               should have been SYSTEM='    '; to set its length to $4. 
Change 29.085 -Revision to limit search to the LIBNAME requested and a  
VMXGSRCH       missing semicolon was inserted, although no syntax error 
Apr 10, 2011   was reported.                                            
              -If VARS= is specified without VALUE=, the results are the
               list of datasets that contain that variable.             
Change 29.084 -Temporary dataset MXGENG is now deleted by VGETENG.      
VGETENG       -Variables QWHSACE QWHSMTN QWACACE ACE are now consistent 
VMACDB2        LENGTH 5 and FORMAT HEX8 addresses, QWARACE is LENGTH 8  
VMAC102        and FORMAT HEX16 in VMACDB2/VMACDB2H/VMAC102.            
VMACDB2H      -Variables TOKLEN and TOKVERS in VMAC80A are labeled.     
VMAC80A       -Variable CTGAPPLQ is labeled, comments for CTGAPLID now  
VMAC111        match in VMAC111.                                        
Apr 10, 2011                                                            
   Thanks to Chris Weston, SAS/ITRM Development, USA.                   
Change 29.083 -Variable QWAXOTSE was added twice in three places; it was
ANALDB2R       not detected because it was zero in the test SMF data.   
Apr  9, 2011  -May 1: The formula for calculating the average time (per 
May  1, 2011   thread) that was "not accounted for" was revised, thanks 
               to this equation provided by IBM DB2 Support in response 
               to a customer PMR, i.e., the Class 2 Elapsed times minus 
               the sum of Class 2 CPU and Class 3 Suspension durations: 
                    /*** CLASS 2 ELAPSED ***/                           
                    /**** CLASS 2 CPU ****/                             
                   /**** CLASS 3 SUSPENSIONS ****/                      
              -The Accounting Trace Reports had many fields missing in  
               the headers because they had not been listed in the      
               SORTBY= arguments.                                       
              -For the ACCOUNTING reports, selection was not being done.
               If you specified DB2=DB20 you still got all of the data  
               for all of the subsystems.                               
   Thanks to Neil Ervin, Wells Fargo Bank, USA.                         
Apr  9, 2011   many of the LPAR-Specific Variables, when IRD is active  
               and/or Hiperdispatch is enabled.  In those environments, 
               only the "LPn" variables for the "THIS LPAR" observation 
               (i.e., "THIS SYSTEM") in "SYSTEM-LEVEL" ASUM70PR/ASUM70LP
               datasets are always valid. These LPAR-Specific variables:
                 LPnNRPRC  LPnDUR  LPnLAC  LPnONT  LPnPAT  LPnWST       
                 LPCTnBY   LPCTnOV                                      
                 LPnZIUTM  LPnZIKTM LPnIFUTM LPnIFKTM                   
               will be WRONG in the ASUM70PR/ASUM70LP observations from 
               the "OTHER LPARs", because those LPAR-Specific variables 
               are based on SMF70ONT/SMF70PAT, which are ONLY valid in  
               the "THIS LPAR" observation.                             
               This PROC PRINT shows the six ASUM70PR observations from 
               each of six SYSTEMs, with the set of LPAR-Specific fields
               for LPAR 2 (SYSA).  You can see that ONLY the observation
               in ASUM70PR for SYSTEM=SYSA, the "THIS LPAR, THIS SYSTEM"
               observation, are valid and match the ASUMCEC observation:
               (Note that not ALL of the variables are WRONG!).         
          SYSK     SYSA   6:00:00.01  1:21:32.11  1:21:00.97  0:00:31.14
          SYSA     SYSA   2:33:48.28  1:21:31.41  1:21:00.27  0:00:31.14
          SYSC     SYSA   6:00:00.43  1:21:32.38  1:21:01.24  0:00:31.14
          SYSD     SYSA   6:00:00.30  1:21:32.50  1:21:01.36  0:00:31.14
          SYSG     SYSA   6:00:01.16  1:21:32.21  1:21:01.07  0:00:31.14
          SYST     SYSA   6:00:00.09  1:21:32.20  1:21:01.07  0:00:31.14
         ASUMCEC:  SYSA   2:33:48.28  1:21:31.41  1:21:00.27  0:00:31.14
                  *******  *******                    ********          
          SYSK     22.64   0.14416  22.6486  0.14416    6.0       8     
          SYSA     53.00   0.33744  22.6521  0.14421    2.6       8     
          SYSC     22.64   0.14416  22.6495  0.14416    6.0       8     
          SYSD     22.65   0.14417  22.6502  0.14417    6.0       8     
          SYSG     22.64   0.14416  22.6479  0.14416    6.0       8     
          SYST     22.64   0.14416  22.6490  0.14416    6.0       8     
         ASUMCEC:  53.00   0.33744  22.6454  0.14416    2.6       8     
          SYSK     16.2389     13        .       129.378    129.378     
          SYSA     16.2420     13      29.2360   129.360    129.398     
          SYSC     16.2389     13        .       129.385    129.383     
          SYSD     16.2389     13        .       129.388    129.387     
          SYSG     16.2389     13        .       129.381    129.374     
          SYST     16.2389     13        .       129.381    129.380     
         ASUMCEC:  16.2420     13      29.2360   129.360    129.360     
         SYSTEM     LP2CSF     LP2ONT       LP2WST       LP2ZIPTM       
                               ******       ******                      
          SYSK       10G     6:00:00.01  3:59:14.35    0.00:18.94       
          SYSA       10G     2:33:47.23  0:33:06.46    0.00:18.94       
          SYSC       10G     6:00:00.43  3:59:15.35    0.00:18.94       
          SYSD       10G     6:00:00.30  3:59:15.46    0.00:18.94       
          SYSG       10G     6:00:01.16  3:59:15.21    0.00:18.94       
          SYST       10G     6:00:00.09  3:59:14.81    0.00:18.94       
         ASUMCEC:    10G     2:33:47.23  0:33:06.46    0.00:18.94       
         SYSTEM          LP2ZIUTM      LP2ZIKTM      LP2ZIWTM           
                         ********      ********      ********           
          SYSK          2:00:00.00             .    1:59:41.11          
          SYSA          1:59:57.87    0:00:00.00    1:59:38.98          
          SYSC          2:00:00.14             .    1:59:41.25          
          SYSD          2:00:00.10             .    1:59:41.20          
          SYSG          2:00:00.39             .    1:59:41.49          
          SYST          2:00:00.03             .    1:59:41.13          
         ASUMCEC:       1:59:57.87    0:00:00.00    1:59:38.98          
               The non-LPAR-Specific variables ARE VALID; it's ONLY the 
               variables identified above that can be WRONG.            
              -And, for ASUMCEC to ALWAYS BE RIGHT, you MUST have READ  
               the PDB.TYPE70PR observations FOR ALL LPARS (ALL SYSTEMS)
               as input to ASUM70PR when you create PDB.ASUMCEC/CELP.   
              -This change was ONLY documentation; no code was changed. 
   Thanks to Larry Stahl, IBM Global Services, USA.                     
Change 29.082  The default ASUM70GC/ASUM70GL interval was hard coded at 
VMXG70PR       HOUR, which matched the default for ASUMCEC/ASUMCELP, but
Apr  9, 2011   now INTERVAL=&CECINTRV is used so the group data interval
               matches the CEC interval data, if you change CECINTRV.   
               With hindsight, these two datasets should have been named
               ASUMCEGC and ASUMCEGL because both are summarized at the 
               CEC level (e.g., by CECSER, and NOT by SYSPLEX SYSTEM),  
               but it's too late to change dataset names now.           
              -New variable MAX70NSW, the maximum percent of time when  
               the LPAR was soft-capped, is now created in PDB.ASUM70GL,
               as the hourly average in SMF70NSW could mask intervals   
               that were capped.                                        
   Thanks to Chuck Hopf, Independent Consultant, USA.                   
Change 29.081 -Support for SMF 120 Subtype 9 User Field SM1209FH creates
VMAC120        that variable in dataset TYP1209E.  While up to 5 user   
VMXGINIT       segments of 2048 bytes each per record can be created,   
Apr  8, 2011   this change keeps only the first segment, and only the   
Nov  8, 2011   first 12 bytes of the optional field are kept in SM1209FH
               although temporary variable SM1209F input all 2048 and is
               to be used as the source of SM1209FH, which can contain  
               HEX, EBCDIC or ASCII text.  The MXG default is ASCII, to 
               match the original test data that was received, but that 
               can be tailored if you have EBCDIC or HEX data values.   
              -Variable SM1209FB is the data length in SM1209FH, and the
               variable SM1209FF contains the user-chosen datatype, and 
               temporary variable SM1209F was input with $VARYING2048., 
               so if your 12-bytes were EBCDIC instead of MXG's ASCII   
               default, then you would insert this statement            
               in your EXT1209E to input the text as EBCDIC, and/or     
               you could use your installer's chosen SM1209FF datatype  
               value to conditionally input as ASCII/EBCDIC/SUBSTR/etc. 
              -The length of a character variable can NOT be changed in 
               a dataset exit member EXddddd.  Only numeric variables   
               can have their length changed in a dataset exit member,  
               as SAS uses the first instance for character length and  
               the last LENGTH statement for numeric variables.         
              -The existing IMACFILE/MACFILE exit is taken before the   
               LENGTH statements in all VMACs are compiled, so it could 
               be used to change length of SM1209FH with this syntax:   
                 //SYSIN DD *                                           
                  %LET MACFILE=  %QUOTE( LENGTH SM1209FH $40; );        
                  %INCLUDE SOURCLIB(BUILDPDB);                          
               in the job that reads the SMF 120 records.  However that 
               is not the real purpose of the IMACFILE exit, and it may 
               already exist for record selection, and the insertion of 
               the LENGTH statement could cause non-fatal messages with 
               UNINITIALIZED VARIABLE SM1209FH if the program that is   
               %INCLUDEd doesn't process SMF 120 records. Using MACFILE 
               is totally slick but not righteous; there's a better way.
              -Nov 8:  This change creates macro variable &VARSM1209FHLN
               in VMXGINIT and uses it   LENGTH SM1209FH $&VARSM1209LN; 
               in VMAC120, so that the default of 8 can be more easily  
               changed (for example, to $40) and converted to EBCDIC:   
                 //SYSIN DD *                                           
                  %LET MACKEEP=                                         
                    %QUOTE  (                                           
                       MACRO  _ET1209E                                  
                  %LET VARSM1209FHLN=12;                                
                  %INCLUDE SOURCLIB(BUILDPDB);                          
              -Nov 8: Change text was completely rewritten.             
   Thanks to Larry Gray, Lowe's Companies, USA.                         
   Thanks to Jim S. Horne, Lowe's Companies, USA.                       
Change 29.080 -New variables from Meral's excellent SHARE paper at      
Apr  7, 2011   are created in TYPE113 and ASUM113 datasets:             
               with different equations for z10 vs z196 calculation.    
              -These original z10 counters were defined as:             
                EXTND128='DIRWRIT*TO L1-I*RETURNED*FROM L2'             
                EXTND129='DIRWRIT*TO L1-D*INSTLD*FROM L2'               
               but the z196 reversed contents so the labels are changed 
                EXTND128='DIRWRIT*TO L1-D*RETURNED*FROM L2'             
                EXTND129='DIRWRIT*TO L1-I*INSTLD*FROM L2'               
               with the Data count in 128 and the Instructions in 129.  
               Since there is no way to have two different labels for   
               the same SAS variable, I chose to use the z196 choice,   
               hoping z10 users will find this note.  Fortunately, all  
               calculations use the sum of this pair of counters, so the
               impact is minor unless you are looking in great detail   
               level for the old z10 processor.                         
               Apr 19: SM113DOL corrected to SM113DON.                  
   Thanks to Meral Temel, Garanti Teknoloji, TURKEY.                    
   Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.  
   Thanks to Chris Weston, SAS ITRM Development, USA.                   
Change 29.079  MXG will now ABEND if SMFTIME is invalid.  Occasionally, 
VMACSMF        using the SAS ftp access method, SAS would stop after    
Apr  7, 2011   writing a horrendous SAS log (6 MILLION PAGES, not lines)
               of MXG messages "FIRST RECORD IN GROUP SYSTEM= SMFTIME=".
               The rerun was always successful, suggesting the error is 
               in the ftp Server, but this enhancement will stop the MXG
               job by detecting that missing value in SMFTIME.          
               SAS was executing under Windows/XP with Service Pack 3.  
   Thanks to Bruce Orr, U.S. Customs and Border Protection, USA.        
Change 29.078  Support for OS/400, AS/400, Version 7.1 INCOMPAT (due to 
FORMATS        IBM change in the LRECL for QAPMDISK file to 539).       
Apr  7, 2011   files have been validated with 7.1 records, so it is     
               possible other files may also be INCOMPATIBLE.  There    
               are also a number of new files that are not supported,   
               until a user needs those data and provides test files.   
              -Dataset QAPMCONF, new variables:                         
                 GDESF1T  GDESF1S  GDESFT  GDESG1-  GDESG9   GDESGA     
                 GDESHT   GDESMT   GDESPF                               
               and new formats are created in FORMATS member, so that   
               you must update your format library.                     
              -Dataset QAPMCONF, new variables                          
                 DSPTROP DSPTWOO DSWWWNN                                
               In addition, variable DSIOARN was documented and INPUT as
               $EBCDIC15., but data in the records show only 10 bytes so
               the INPUT was reduced and PMR was opened with IBM Support
               to determine the true length of the field.               
   Thanks to Paul Naddeo, FISERV, USA.                                  
   Thanks to David Bixler, FISERV, USA.                                 
Change 29.077 -Executing z/OS under z/VM caused MXG to print 3 messages:
Apr  2, 2011   but the TYPE70 observation had already been output in the
               TYPE70SP dataset (thanks to the "Split 70s" redesign, so 
               nothing was lost).  Under z/VM, the CPUID segment of the 
               RMF 70 record does not exist.  The revised message reads:
                 MXGNOTE: RMF70 CPUID SECTION DOES NOT EXIST            
                 THIS IS NORMAL IF z/OS IS EXECUTING UNDER Z/VM.        
                 OTHERWISE THIS IS AN INVALID RMF 70 RECORD.            
              -Prior to z/OS 1.12, the PRCS/PRDS segments of the RMF    
               70 record did not exist when z/OS was run under z/VM.    
               But in z/OS 1.12, APAR OA35675 captures the CPU dispatch 
               time of both the z/OS partition and the z/VM "overhead". 
               See Change 29.127 which added support for that APAR.     
              -On the topic of z/OS under z/VM, past Newsletters noted: 
               - To construct the configuration and recording of TYPE78 
                 data, RMF must read the IOCDS data set, but under z/VM,
                 the IOCDS is not available to z/OS, so some type RMF 78
                 records will not exist.                                
               - Under z/VM, the RMF I/O Queueing Activity Report shows 
                 only the static configuration data.                    
              -And IBM's Running Guest Operating Systems documents that:
                -When you analyze the z/OS environment, remember that   
                 you have two operating systems running in a single     
                 processor. Both z/VM and z/OS are vying for the basic  
                 system resources, such as processor, I/O, storage, and 
                 paging. Each is generating its own accounting          
                 information, and each is supplying its own performance 
                -Remember that z/OS is unaware that it is running as a  
                 guest under z/VM. What the z/OS guest thinks is        
                 real-time is actually the time-of-day clock and        
                 processor timer facility.  Elapsed time as measured by 
                 the time-of-day clock is accurate. The guest's virtual 
                 processor timer (VPT) runs whenever the guest is       
                 dispatched or is in a voluntary wait state. It does not
                 run if the guest is in a CP wait state. Thus, when z/VM
                 dispatches another virtual machine and later dispatches
                 the z/OS guest, z/OS does not realize it had stopped   
                -Information about guest system performance is          
                 frequently published in Washington System Center       
                 flashes. Contact your marketing team for obtaining     
                 flashes that pertain to your particular installation.  
              -And IBM's RMF Programmer's Guide documents for z/VM:     
                -Partition Defined Capacity Used Percent is zero.       
              -And IBM's RMF Reports Manual documents for z/VM:         
               -When Channel Path Measurement Facility (CPMF) is not    
                available, for example, on z/OS systems running as z/VM 
                guests, RMF uses sampled data from SRM so that the      
                reported channel utilization is only an approximate     
                value. With increasing channel speed, the channel       
                utilization value becomes more and more inaccurate.     
                Therefore, in such cases, RMF does not provide accurate 
                values of FICON channel utilization.  Beginning with    
                z990 processors, the channel data from SRM is no longer 
                available. As a result, the channel utilization data on 
                a z/OS system running as z/VM guest, is not reported.   
               -In the DEV and DEVV reports, LCU will be blank if this  
                is a non-dedicated device in a z/VM guest system        
               -Running in a z/VM guest environment, these RMF reports: 
                  Partition Data Report                                 
                  LPAR Cluster Report                                   
                  Group Capacity Report                                 
                do not exist (because TYPE70PR has zero observations).  
                Dataset TYPE70 variable VMSYSTEM='Y' for z/OS under VM. 
               -For the CPU Activity Report:                            
                If RMF is running as a guest under z/VM, it only reports
                the z/OS busy time percentage. If you want to measure   
                partition utilization (as well as the individual CPU    
                utilization of the single guests, namely LPAR busy time 
                percentage), you need to use a z/VM monitor.            
   Thanks to MP Welch, Aprize, USA.                                     
   Thanks to Bruce Widlund, Merrill Consultants, USA.                   
Change 29.076  CICS CPUTM can significantly exceed ELAPSTM if you have  
VMAC110        "knee-capped, i.e. slow" CP engines with zIIP/zAAPS.     
Apr  1, 2011   The specific case had CPUTM=25 and ELAPSTM=5 on a CP with
               a zAAP that was 10 times faster (or that CP was 10 times 
               slower!).  CICS Support responded to the PMR documenting 
               that CICS uses the TIMEUSED macro to capture CPU time:   
                 "Note: TIMEUSED returns normalized CPU time.  Some     
                 servers are configured with System z(TM) Application   
                 Assist Processors (zAAPs) or IBM System z9 Integrated 
                 Information Processor and IBM System z10(TM) Integrated
                 Information Processors (zIIPs), which run at a faster  
                 speed than the normal CP processors.  In this case,    
                 zAAP time and zIIP time is normalized to the equivalent
                 time it would take to run on a normal CP when          
                 accumulated into total CPU time. "                     
               The specific case had CPUTM=25 and ELAPSTM=5 on a machine
               with a zAAP that was 10 times faster (or a CP that was 10
               times slower!), which printed a recently added MXG ERROR 
               message "CPUTM MUCH LARGER THAN ELAPSED".  This message  
               was added to enhance MXG's detection of mis-aligned SMF  
               records when CICS fields were excluded or optional fields
               were added.  Previously, the only way for MXG to catch   
               mis-alignment was to test that TASKNR was a valid packed 
               decimal or that STRTTIME was a missing value, but both of
               those fields are at the beginning of the segment, and    
               some combinations of EXCLUDEd fields with optional data  
               segments passed those tests as the record was read, but  
               the CICSTRAN dataset contained invalid values for fields 
               later in the record, but that was only after the MXG job 
               had completed and the user analyzed the data.  This test 
               was added for more robust detection, but the original was
               only for CPUTM GT 2*ELAPSTM, which in this specific case 
               was a spurious ERROR message.  I have changed the test to
               CPUTM GT 10*ELAPSTM and added a note in the message that 
               this could be normal if you have knee-capped CP engines. 
              -These CPU time variables in CICSTRAN recorded those 25   
               Normalized CPU seconds: TASDSPTM (USRCPUT), KY8CPUTM,    
               L8CPUTTM, and the total CPUTM, for this transaction that 
               obviously spent some serious time on the zAAP engine.    
   Thanks to Hugo L. Michel, Prince Georges County, MD, USA.            
   Thanks to Dan Zachary, IBM CICS Support, USA.                        
Change 29.075 -Support for NTSMF's 62 new objects and 1425 new metrics. 
EXNTD001       And, a MAJOR redesign in MXG architecture, isolated now  
EXNTD062       to the NTSMF product support, but a possible harbinger   
VMACNTSM       with that dataset name being the OBJECT name (with blanks
VMXGINIT       and periods changed to underscores). The "dddddd" dataset
Mar 31, 2011   tokens for the new datasets are "NTD001-NTD062", and the 
VMXGINV        variable/metric names use the D001 part of the dddddd    
UTILVREF       token as their prefix, and are sequentially numbered,    
               e.g. D0010001-D00010008 are the 8 variable names for the 
               dataset with NTD001:_NET_CLR_NETWORKING, and the labels  
               for the metrics are the metric name, shortened to forty  
               characters with asterisks inserted for the SPLIT='*' SAS 
               operand (to split labels when printing).                 
               Previously, I created unique dataset names and variable  
               names that were arbitrarily limited to 8 characters, but 
               this design was implemented by the MAKENTSM code member  
               that programmatically generates all of the structural    
               code that is then cut/pasted to add the new datasets and 
               their exit members.  The _UNTDISC utility provides the   
               cut and paste text for the metric names, that become the 
               labels for each variable; that is (and will always be) a 
               manual process, as that's how I discover what new metrics
               are created, and get an understanding of each new object.
               It is also where the conversion of values to be          
               consistent (like converting KB fields to bytes) and      
               assignment of MXG formats (like MGBYTES to those         
               converted fields, both for the "print pretty" aspect, but
               more importantly, to document (in PROC CONTENTS) the     
               variables that contains storage units) that requires     
               human knowledge is done.  The new objects are listed in  
               IMACNTSM rather than here!                               
              -The increase of DATASET name required revisions to the   
               internal programs VMXGINV and UTILVREF that create the   
               DOCVER members; for datasets with names longer than 9,   
               DOCVER now has two lines, one for the DATASET name and   
               a second line for the DATASET label.  Additional updates 
               were needed in a number of the internal QA programs to   
               support the longer dataset names.                        
Change 29.074  MXGWARM: MORE THAN 20 DUPLICATE LABELS, for TYPE8224 with
VMAC82         SMF82DCN, MORE THAN 20 UNAUTH DUPE for TYPE8225 are notes
Mar 30, 2011   that you had more than the 20 I thought was enough.  With
               a max of 36 now observed, I've increased to 40 the number
               of these variables that are kept in the two datasets.    
                  But, with MXG's default of COMPRESS=YES, why have any 
                  limit at all: there really isn't any real cost of DASD
                  space, if the extra variables are all blanks.         
               If this is really a normal need, to know each of the     
               instances of the duplicate KEY, when there might be more 
               than 40, then MXG would create a new dataset with one    
               observation per instance, and free itself from any       
               array-size constraints!                                  
   Thanks to Bruce Hewson, Citibank N.A., SINGAPORE.                    
   Thanks to Alan Yang, Citibank N.A., SINGPORE                         
Change 29.073  Documentation comments (ONLY) were updated to show how   
READDB2        to create ONLY the PDB.DB2STATS dataset, with no other   
Mar 28, 2011   datasets written to the PDB library.  It should also be  
               noted that, to create observations in PDB.DB2STATS, both 
               DB2STAT0 and DB2STAT1 must have observations; DB2STAT4   
               can have zero observations.                              
   Thanks to Jane S. Stock, USPS, USA.                                  
Change 29.072 -Documentation comments (ONLY) were updated to show how   
UTILBLDP       the MACFILEX argument can be used to skip unwanted SMF   
Mar 28, 2011   records and subtypes.                                    
Apr  7, 2011  -Some MXGWARN were changed to MXGNOTE and text revised.   
   Thanks to Nicholas Ward, CentreLink, AUSTRALIA.                      
Change 29.071  Support for Throughput Manager subtypes 10 and 16 records
EXTPM10        creates new datasets:                                    
EXTPM16S         dddddd  Dataset  Description                           
EXTPM16J         TPM10   TPM10    Description                           
IMACTPMX         TPM16S  TPM16S   Step Termination                      
VMACTPMX         TPM16J  TMP16J   Job Termination                       
Mar 28, 2011                                                            
Change 29.070  Replaced by Change 29.220.                               
Mar 24, 2011                                                            
Change 29.069  The DB2 Report of TOP users of resources was revised to  
ANALDB2T       report separately for each DB2 SubSystem.                
Mar 24, 2011                                                            
   Thanks to Ron Wells, American General, USA.                          
   Thanks to Rick Brooks, American General, USA.                        
Change 29.068  MXG 28.28-29.02.  Many ABEND='JCL' jobs had ABEND='   '  
BUILD005       and all variables from TYPE26J2 were blank or missing in 
Mar 24, 2011   the PDB.JOBS dataset.  Change 28.304 unintentionally     
               output all TYPE26J2 obs with SYSEXEC LE ' ' to the       
               PDB.NJEPURGE dataset, so they were not used to build the 
               PDB.JOBS obs.  Instead, only the Purge records that have 
                 INREASON IN ('JR','JT','SR') AND SYSEXEC LE ' '        
               are (now, correctly) output in PDB.NJEPURGE.  Fortunately
               since purge records with SYSEXEC LE ' ' did NOT execute, 
               there was no actual loss of resources, except for the    
               counting JCL errors.                                     
   Thanks to Lars-Olof Thellenberg, Handelsbanken, SWEDEN.              
Change 29.067  RACF UNLOAD utility dataset RACF0270 (OMVS) decodes these
VMACRACF       ten variables for UID limits:                            
Mar 28, 2011      ASSIZEMAX  ='MAXIMUM*ASID SIZE FOR UID'               
                  CPUTIMEMAX ='MAXIMUM*CPU TIME*FOR UID'                
                  MEMLIMIT   ='MAXIMUM*SIZE OF*NON-SHARED*MEMORY'       
                  PROCUSERMAX='MAXIMUM*PROCESSES*FOR UID'               
                  SHMEMAX    ='MAXIMUM*SIZE OF*SHARED*MEMORY'           
                  THREADSMAX ='MAXIMUM*THREADS*FOR UID'                 
   Thanks to Ed Webb, SAS Institute, USA.                               
Change 29.066  Duplicate formats $MG119SU were sourced in FORMATS; the  
FORMATS        last read was used correctly.  The first is now $MG119ST 
VMAC119        and is used to decode SSH_FSCMD, SSH FTP Subcommand.     
Mar 16, 2011                                                            
   Thanks to MP Welch, Aprize, USA.                                     
Change 29.065  SMF 111 CTG variable CTGAPLID is conditionally INPUT for 
VMAC111        dataset TY111CXI, but always INPUT for TY111GD dataset;  
Mar 16, 2011   when it existed in GD but not in CXI, but only when the  
               GD segment preceded the CXI segment in a physical record,
               the value from the GD segment was carried forward into   
               the CXI dataset.  Now, the value is blanked after output 
               in the GD segment to prevent being carried forward.      
   Thanks to Gordon E. Griffith, Edward D. Jones, USA.                  
   Thanks to Jim Poletti, Edward D. Jones, USA.                         
   Thanks to Jeana M. Bechtel, Edward D. Jones, USA.                    
Change 29.064  The INFILE Exit for Compressed CICS and DB2 records did  
EXITCICS       not always work, sometimes causing an I/O Error message. 
Mar 16, 2011   Code that had been moved in testing was restored.        
   Thanks to Harald Seifert, Huk-Coburg, GERMANY.                       
Change 29.063  Support for CICS/TS 4.2 was available in MXG 29.03, but  
UTILEXCL       was announced in Change 29.135.  This change was Reserved
VMAC110        until the product became GA on June 24.                  
Mar 15, 2011   These new variables are added to the CICSTRAN dataset:   
Apr  2, 2011     ECSEVCCT='SYNCHRONOUS*EMISSION*EVENTS'                 
Jun 24, 2011     OADID   ='ORIGINATING*ADAPTER*ID'                      
                 OADATA1 ='ORIGINATING*ADAPTER*ID*DATA 1'               
                 OADATA2 ='ORIGINATING*ADAPTER*ID*DATA 2'               
                 OADATA3 ='ORIGINATING*ADAPTER*ID*DATA 3'               
                 PHTRANNO='PREVIOUS*HOP*DATA TRANS*SEQ NR'              
                 PHTRAN  ='PREVIOUS*HOP*DATA*TRANSACTION*ID'            
                 PHCOUNT ='PREVIOUS*HOP*DATA*COUNT'                     
              -UTILEXCL needed revisions because new fields inserted in 
               the middle of the record that were unknown to UTILEXCL   
               were not correctly handled in the prior UTILEXCL, which  
               created an IMACEXCL that had syntax errors that could be 
               visibly seen (the IBM field after the (last) new field   
               was NOT preceded by an INPUT statement.)  This was NOT   
               an incompatibility with CICS/TS 4.2, but using the prior 
               UTILEXCL with CICS/TS 4.2 dictionary records did cause   
               the syntax error when that new IMACEXCL was used.        
              -New Statistics STID=19, Dataset CICSMD, exactly the same 
               fields as STID=6 in this iteration.                      
              -New Statistics STID=20, Dataset CICSMT, exactly the same 
               fields as STID=5.                                        
              -New Statistics STID=29, existing Dataset CICSMDSA        
                 SMSVHBYT='HIDDEN IN*PRIVATE MEMORY*OBJECTS'            
                 SMSSHBYT='SHARED*FROM*LARGE MEMORY*OBJECTS'            
                 SMSHSPMO='HWM AUX*SLOTS*BACK*PRIVATE*MEMORY'           
              -New fields in STID=48, Dataset CICTSQ:                   
              -New fields in STID=142, Dataset CICEPG:                  
Change 29.062 -UNKNOWN OPTION VNVERR should have been spelled VNFERR in 
ASUMUOWT       VMXGUOW.  The error only occurs when ASUMUOWT is used for
VMXGUOW        TMON CICS input.  ASUMUOWT was not called in MXG QA job  
Mar 15, 2011   or I would have caught this typo; that will be corrected.
Mar 18, 2011  -Debugging option TRACEUOW(YES) was left on in ASUMUOWT,  
               causing many thousands of lines FIRST.UOWICCHR= ...      
               to be printed on the log.                                
   Thanks to Frank Lund, EDB ErgoGroup, NORWAY.                         
Change 29.061  Variables PCTZAPBY, PCTZALBY, PCTZIPBY, PCTZILBY are     
VMACRMFV       added to dataset ZRBCPU.  These represent the Physical   
Mar 13, 2011   and Logical Busy Percentage for ZAAP and ZIIP engines    
   Thanks to Rodger Foreman, Acxiom, USA.                               
Change 29.060  Two calculations for z196 Est Finite CPI and Est SCPL1M  
ASUM113        were revised by John Burg in his March SHARE session:    
VMAC113          IF BASIC01 GT 0 THEN DO;                               
Mar 13, 2011       ESTFINCP=((BASIC03+BASIC05)/BASIC01)*(.57+(0.1*RNI));
                 IF SUM(BASIC02,BASIC04,0) GT 0 THEN DO;                
Change 29.059  Support for Beta 93 Version 4.2 new subtypes 25 and 50   
EXTYBETF       creates two new datasets:                                
EXTYBETG          dddddd     Dataset   Description                      
IMACBETA          TYBETF     BETA25    93 SPOOL ACCESS                  
Mar 13, 2011                                                            
   Thanks to Andreas Menne, Finanz Informatik, GERMANY.                 
Change 29.058  Variable CPUCEPTM is now set to a missing value in all of
VMAC30         the datasets that contain it (TYPE30_4,TYPE30_V,TYPE30_5,
Mar 11, 2011   PDB.STEPS,PDB.JOBS, where it was flat out WRONG, and in  
               PDB.SMFINTRV, where it was validly deaccumulated, but is 
               not needed).  The error, starting in Change 22.326, was  
               that CPUCEPTM was an ACCUMULATED CPU time and was NOT the
               CPU time of the interval, step, or job. In Change 22.326 
               MXG did deaccumulate it, but only in PDB.SMFINTRV, and in
               that process, lost the value of the first interval.  IBM 
               corrected their error, creating a new deaccumulated field
               MXG variable CPUCIPTM, added in Change 23.329, which was 
               kept in all of the above datasets since that 2006 change.
               But then in 2007, forgetting that it was completely wrong
               I carelessly kept it in PDB.STEPS and PDB.JOBS.  While it
               might be better to just remove the variable, it is safer 
               to now set CPUCEPTM to a missing value, and hope/presume 
               that if/when you notice it is missing, that you will have
               first searched CHANGESS and will have found this text to 
               tell you to use CPUCIPTM instead.  Note that CPUCIPTM is 
               already contained in CPUTCBTM so you would only even want
               to use it when examining the components of CPUTCBTM.     
               An obscure comment in VMAC30 notes that the variables    
                 and CPUCIPTM are all included in CPUTCBTM.             
   Thanks to Alfred Holtz, Medco, USA.                                  
   Thanks to Charles D'Angelo, Medco, USA.                              
   Thanks to Alex Pasterick, Medco, USA.                                
Change 29.057  Support for Websphere for z/OS MQ Version 7.0.1 (COMPAT).
EXTY116C      -SMF 115 record, dataset MQMMSGDM, new variables:         
Mar 12, 2011      QTSTTMSG                                              
Apr 19, 2011  -SMF 116 record, datasets MQMACCT1 and MQMQUEUE:          
               New variables added from both WQ and WTAS segments:      
                  WTASSUN  WTASSUSC WTASSUSL                            
                  WQPUBCN  WQPUTOSR WQSELCOU WQSELMXL                   
               New MQCFSTAT dataset has one obs with these 5 variables  
                  WQCFCOUN  &PIB.4.  /**TIMES*IN THE*ROUTINE*/          
                  WQCFSYCN  &PIB.4.  /**SYNC*REQUESTS*/                 
                  WQCFSYET  &PIB.4.6 /**SYNC*ELAPSED*TIME*/             
                  WQCFASCN  &PIB.4.  /**ASYNC*REQUESTS*/                
                  WQCFASET  &PIB.4.6 /**ASYNC*ELAPSED*TIME*/            
               with those statistics for the Coupling Facility, if used,
               for each of the five MQ Verbs (variable WQVERB);         
                  OPEN CLOSE GET PUT PUT1                               
               and for each of the thirteen MQ requests (WQREQSTY):     
                  LOCK     UNLOCK   WRITELC  SIGXCF   SIGCF    READ     
                  WRITE    STARTMON STOPMON  NEW      MOVE     MOVEENT  
               but observations are ONLY created in MQCFSTAT if there   
               are non-zero counts in one of the statistics variables.  
               Apr 19: VMAC110 QJSTDRE1/3 corrected to QJSTDRQ1/3       
   Thanks to Victoria Lepak, Aetna, USA.                                
   Thanks to Chris Weston, SAS ITRM Development, USA.                   
Change 29.056  Support for MainView MQ (MVMQ) Version 4.4 (INCOMPAT);   
VMACBBMQ       MXG code had not been updated since 2007 and many new    
Mar 13, 2011   fields were inserted in 'E6'x (dataset BBMQQUES) record, 
               the 'E5'x (dataset BBMQCHAN)  record was completely      
               revised with several new fields, and the 'E1'x (dataset  
               BBMQQMGR) had new fields added at the end.  The VERSREL  
               value in the 4.4 records contains 4.2, so the logic to   
               detect MVMQ Version was change to use the Length ENTL    
               field.  This iteration suppresses checking for compress  
               bit while EXITMNVW is examined for possible error.       
   Thanks to James Swwinarski, Credit-Suisse, SWITZERLAND.              
Change 29.055  JCLUOWV, an example to read DB2 & CICS data that creates 
JCLUOWV        PDB.ASUMUOW using SAS Views was altered by Change 28.220 
Mar  9, 2011   but undocumented; the default ASUMDB2x members that were 
               %INCLUDed were changed, creating different PDB.ASUMDB2x  
               datasets.  While any or all of the ASUMs are optional, it
               was not my intent to create different datasets, so the   
               default original ASUMs are restored, with this note:     
   Thanks to Carolyn Saul, West Virginia Office of Technology, USA.     
Change 29.054 -STRING variable length was increased to 1000 to support  
ASUMDB2A       potentially longer arguments.                            
ASUMDB2B      -Macro variable DSETEXST=NO, defined/set in VMXGINIT, was 
ASUMDB2G       incorrectly re-defined in VMXGSUM, ASUMDB2A, ASUMDB2B,   
ASUMDB2P       ASUMDB2G and ASUMDB2P, preventing it from being changed  
VMXGSUM        to YES by ANALDB2R, the only place it is currently used. 
Mar 13, 2011   Re-definitions are now removed from those five members.  
                 With DSETEXST=NO, VMXGSUM calls VGETOBS to determine if
                 the input dataset exists, gracefully failing was an MXG
                 message if it doesn't.  With DSETEXST=YES, when the    
                 existence is already known, VGETOBS is bypassed, saving
                 a read of the full input dataset if it happens to be   
                 on tape or in sequential format on disk.               
               Because the redefinition text was DSETEXST=&DSETEXST,    
               SAS errors about RECURSIVE REFERENCE to DSETEXST could   
               have occurred, although (fortunately) none were reported.
Change 29.053  Documentation. Since DB2 Version 7.1, when DB2ACCTP data 
TYPEDB2        was moved to SMF 101 Subtype 1, there has been no QWAC   
Mar  4, 2011   segment for Packages.  The KEEP list for DB2ACCTP still  
               had variables QWACBSC QWACESC and QWACWLME, which have   
               been missing values in DB2ACCTP since then. I could drop 
               them, but if I do, someone out there with an old report  
               program that referenced them, would then fail, so they   
               will still be kept (but if you are real picky, you can   
               easily drop them by putting this macro definition        
               in your IMACKEEP member in your "USERID.SOURLIB").       
   Thanks to Wayne Bell, UniGroup, Inc, USA.                            
Change 29.052  The newest MONTHxxx fails, z/OS ONLY, SAS 9.1.3 only.    
MONTHBLD       %CMPRES must be changed to %QCMPRES.  As often is the    
Mar  3, 2011   case with %MACRO errors, the error message gives no clue:
                 OF ORDER.                                              
               The %CMPRES function was added to print the generated SET
               statement, for diagnostics, to verify the results of the 
               7x7 tests (7 Startdays, 7 Rundays), but was added after  
               the z/OS MONTHxxx logic verification, and while it works 
               just fine on SAS 9.2, the 9.1.3 %CMPRES function fails,  
               inserting a semicolon that terminated the %LET statement.
               The stronger %QCMPRES function works on SAS 9.1.3.       
               May 1: See CHANGE 29.102.  Error occurred on SAS V9.2.   
   Thanks to Kim Tyson, Toyota, USA.                                    
Change 29.051  Variable STORCLAS can be uninitialized, with hex zeroes  
VMAC42        for some system datasets (SYS1.MANX,SYS1.PROCLIB); now,   
Mar  2, 2011  hex zeros are translated to blanks.                       
   Thanks to John R. Paul, Highmark, USA.                               
====== Changes thru 29.050 were in MXG 29.02 dated Mar  1, 2011=========
Change 29.050  DB2 IFCID 319, ACCESS CONTROL AUTH EXIT PARMS, specific  
FORMATS        to IFCID=319 fields, are now decoded and output; three   
VMAC102        formats are created to decode three variables.           
Change 29.049  The interval DELTATM was not summed when there was more  
ASUM113        than one engine for a type of engine causing LPARBUSY    
Feb 25, 2011   to exceed 100%. The sum of the DELTATM across engine type
Feb 28, 2011   is now stored in DELTASUM and used for LPARBUSY, while   
               DELTATM has the interval duration and is used for the    
               (now corrected) calculation of LPARCPUS.                 
   Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.  
Change 29.048  Macro variable MXGCIXT is created and inserted after all 
VMXGCICI       of the CICS Statistics WORK.INTxxxx datasets have been   
VMXGINIT       created (summarized), so they could be copied to a       
Feb 25, 2011   permanent data library.                                  
Change 29.047  DB2 variables QWACZIS1 QWACZIS2 QWACZIEL QWACZITR are now
VMXGUOW        added to PDB.ASUMUOW when DB2ACCT data is found.         
Feb 25, 2011                                                            
Change 29.046  On z/OS only (a LIBNAME is always needed on ASCII):      
DOC            if your program starts with an ASUM/TRND member, or it   
Feb 25, 2011   invokes VMXGSUM, and the internal macro VGETOBS is used  
               (to detect the presence or absence of input datasets,    
               intended to conserve resources and avoid strange errors),
               there are two potential exposures:                       
               SAS - if the LIBNAME is on tape, we cannot detect that,  
               and the PROC SQL will read the entire tape volume(s) to  
               populate the DICTIONARY.TABLES internal table we use.    
               WPS - WPS does not populate dictionary.tables until the  
               LIBNAME(s) are opened, which causes these error messages:
                  NOTE: No rows were selected                           
                  NOTE: RUN has no effect in proc sql ... immediately.  
                  MXGERROR: BE STOPPED.                                 
                  NOTE: Procedure SQL step took :                       
               In this case, you must have a LIBNAME statement for each 
               data library to cause that table to be populated.        
               Alternatively, you could also use PROC DATASETS          
               DDNAME=xxxxx; to populate the table.                     
               In both cases, inserting %LET DATAEXST=YES; as the first 
               SYSIN statement eliminates VMXGSUM's call to VGETOBS to  
               verify the dataset exists.  However, if they don't exist,
               that will cause VMXGSUM to then fail for that reason.    
   Thanks to Kare Martin Torsvik, Ergogroup, NORWAY.                    
   Thanks to Atle Mjelde, Ergogroup, NORWAY.                            
Change 29.045  TRNDRMFI example TRENDINT should have been INTERVAL.     
TRNDRMFI       UTILRMFI %IF J LT 5 should have been %IF &J LT 5.        
Feb 27, 2011                                                            
   Thanks to Matthew Chappell, Dept. of Transport Main Roads, AUSTRALIA 
Change 29.044  ASM utility to convert a PC "RECFM=U" V/VB/VBS file that 
ASMDBLKU       was uploaded to z/OS into a readable "RECFM=V/VB/VBS"    
Feb 25, 2011   dataset.  This is the ASM equivalent of the SAS UDEBLOCK 
               for sites that don't have a z/OS SAS license.            
Change 29.043 -If you needed to rerun a specific day, and you use the   
BLDSMPDB       AUTOALOC=YES option, the FORCEDAY parameter was not found
Feb 24, 2011   in the macro; it is now properly defined. To rerun with  
               AUTOALOC=YES, the syntax is forceday=ddmmmyy, where the  
               ddmmyy is the date to be rerun (e.g., 21feb11).          
              -If you need to rerun a day and AUTOALOC=YES is NOT used, 
               specify rerun= the day of the week to be rerun, MON, etc.
   Thanks to Cletus McGee, ALFA Insurance, USA.                         
Change 29.042  NDM-CDI Version 5 records are read without actual errors,
VMACNDM        but the test file contained 'XO' records, which printed  
Feb 24, 2011   "NDM. HEADER ONLY" messages because no records had been  
               available for validation.  These records are now decoded 
               and are output in NDMDT dataset.                         
Change 29.041  Your FEB MONTHly PDB could be missing MON data, if your  
MONTHBLD       i.e., if the Last Change is  28.125 thru 29.017, i.e.,   
MONTHBL3       if it was copied from MXG 28.04 thru 29.01 (yes, that    
MONTHDSK       new version that was supposed to have fixed the MONTHs). 
MONTHWEK       It depends on the MONTHxxx member, the version it came   
Feb 27, 2011   from, and the STARTDAY of your week (MXG default is MON):
                 The possible combinations that are good or bad:        
                 Using MONTHBLD or MONTHBL3:                            
                 From version:     MXG 29.01       MXG 28.04-MXG 28.28  
                 (Last Change)   Change 29.017    Change 28.125-28.324. 
                 STARTDAY       SUN       MON        SUN       MON      
                 VSETMNTH     OLD  NEW  OLD  NEW   OLD  NEW  OLD  NEW   
                               X   ok   ok   ok    ok    X    X    X    
                 Using MONTHASC or MONTHDSK:                            
                 From version:          MXG 28.04-MXG 29.01             
                 (Last Change)         Change 28.125-28.324.            
                 STARTDAY                 SUN       MON                 
                 VSETMNTH               OLD  NEW  OLD  NEW              
                                        ok    X    X    X               
                              X: MON's PDB data will be missing.        
               The safe correction, of course, is to "drop in" MXG 29.02
               before Tuesday's MONTHxxx, but I realize that's unlikely!
               To correct, you MUST download the new VSETMNTH file      
               - VSETMNTH.SAS (ASCII) or VSETMNTH.EBC (z/OS) - and copy 
               into your tailoring library.                             
                 With MONTHBLD/MONTHBL3 from MXG 29.01, the new VSETMNTH
                 is all that is required.                               
                 If your MONTHBLD/MONTHBL3 was from 28.04-28.28, then   
                 you can download the new member and cut your list of   
                 the datasets you create (i.e., from 1st MACRO _DSET to 
                 the end of your MONTHBLx) and replace the default list 
                 in the new MONTHBLx), or you can EDIT your MONTHxxx    
                 (see below) to change the CALL SYMPUT.                 
                 With MONTHASC/MONTHDSK from 28.04 including 29.01,     
                 you can download the new member and cut/paste your list
                 of datasets (see preceding note), or you can EDIT your 
                 MONTHxxx (see below) to change the CALL SYMPUT.        
                 To EDIT/fix MXG's error in MONTHBLD/MONTHBL3 pre 29.01 
                 or the MXG error in MONTHASC/MONTHDSK from 28.04-2901: 
                 Change the one line:                                   
                  CALL SYMPUT('LASTDAY',PUT(TODAY,WEEKDATE3.));         
                  CALL SYMPUT('WEEKDATR',PUT(TODAY,WEEKDATE3.));        
               The ftp credentials you already have for 28.28 or 29.01  
               are still valid, so you can either download MXG 29.02 and
               copy those new members to your Tailoring Library from it,
               or you can download only the specific files you need:    
                 The files with .sas are ASCII for MXG ASCII execution. 
                 The files with .ebc are EBCDIC (to avoid any code page 
                 translation issues), but they must be moved as binary  
                 to a PDS with DCB attributes of RECFM=FB and LRECL=80. 
               And, what do you do when it after March 1st when you find
               this needed correction?  Download/EDIT as described in   
               the preceding paragraphs for your BUILDxxx programs and: 
                -If the rerun is during the same processing week, then  
                 simply EDIT your MONTHxxx and change the statement     
                 (as is documented in the ADOCMNTH member).             
                -If the rerun is not until the NEXT week, then you would
                 use the MONTHWEK member (z/OS) or the MONTHASW (ASCII) 
                 member (from your current MXG version - it doesn't use 
                 the defective VGETMNTH that created all this flail),   
                 cut/paste your list of datasets to be created, and then
                 read the last 5 WEEKly PDBs to rebuild your MONTHly.   
               2. IF YOU USE BLDMSPDB:                                  
                 You must have the new BLDSMPDB and VSETMNTH, then:     
                 To rebuild the past month's PDB on z/OS or on ASCII    
                 with AUTOALOC=NO (default), but ONLY if you are in the 
                 first week of the new month:                           
                 To rebuild the past month's PDB on ASCII with          
                 AUTOALOC=YES (ASCII ONLY), but ONLY  if you are in the 
                 first week of the new month:                           
                 To rebuild the past month when it is beyond the first  
                 week of the month:                                     
                 With AUTOALOC=NO:                                      
                    LIBNAME WEEK6 'your sixth week';                    
                    %LET USEWEEKS=YES;                                  
                 With AUTOALOC=YES:                                     
                    %LET USEWEEKS=YES;                                  
               3. IF YOU USE BLDNTPDB:                                  
               To rerun the current month, whether during the week with 
               the first of the month, or a following week, use:        
               To rerun a prior month, you must ensure the correct week 
               pdbs are allocated to week1 thru week5, and then us:     
               Additional changes were made by this enhancement.        
               -New macro variable (if you set it to) USEWEEKS=YES:     
                 -drives logic in VSETMNTH to use only the WEEKly PDBs  
                  when the rerun is in the week after the week with the 
                  first of the month.                                   
                 -allocates LIBNAME WEEK6 because some months need      
                  to read six months of weeklies when a MONTH PDB is    
                  created only from the past weekly pdbs.               
               -Documentation in BLDSMPDB for RUNMNTH=FORCE, RERUN=YES, 
                and FORCEDAY='date' are corrected and updated.          
               -The default WEEKs kept is now 12 in both BLDSMPDB and   
                VMXGALOC, but I recommend a MUCH LARGER number of WEEK  
                PDBs be kept for historic reasons, with all of the PDB  
                datasets (and only a few, if any, kept in MONTHly PDBs).
               -I believe only SUN and MON are commonly used for the    
                Startday, but the below table shows all of the possible 
                datasets that could have been missing prior to this     
                Table of which PDB's are missing with bad VSETMNTH:     
                Eg.: On Feb 1 and Mar 1, which are RUNDAY=TUE, the      
                table shows that "mon" PDB will be missing from your    
                MONTH PDB if your week starts on SUNDAY, or that the    
                "tue" PDB will be missing if MONDAY is STARTDAY, but    
                in the worst case, it shows six dailies could have      
                been skipped in building the monthly.                   
            Your          RUNDAY = DAY OF 1st of MONTH                  
            Week      MON    TUE    WED    THU    FRI    SAT    SUN     
              SUN     mon    tue    wed    thu    fri    su-fr  ok      
              MON     ok     tue    wed    thu    fri    sat    mo-sa   
              TUE     tu-su  ok     wed    thu    fri    sat    sun     
              WED     mon    we-mo  ok     thu    fri    sat    sun     
              THU     mon    tue    th-tu  ok     fri    sat    sun     
              FRI     mon    tue    wed    fr-we  ok     sat    sun     
              SAT     mon    tue    wed    thu    sa-th  ok     sun     
   Thanks to Michael Creech, Lender Processing Services, USA.           
Change 29.040  Variables MAXVMSIZ and VMDSSIZE in dataset XAMUSR were   
VMACXAM        incorrectly input as PIB.4. instead of RB.4. so the      
Feb 23, 2011   formatted value printed as 1164M instead of 3071M.       
               While XAM apparently prints 3072M, the actual RB value   
               in the record, '48BFFFFF'x is only  3221225216 while the 
               actual bytes in 3072M (megabyte) is 3221225472.          
   Thanks to Craig Collins, State of Wisconsin DOA, DET, WISCONSIN.     
Change 29.039  Format MGRMFCX, dataset TYPE7002 variable R7023CT and    
FORMATS        dataset TYPE70X2 variable R7024CT, Crypto Processor Type,
Feb 23, 2011   was incorrect, expecting 'F5'x EBCDIC numbers in hex, but
               the actual values are hex (e.g.,'05'x); the hex value was
               printed; now the decoded '05X:PCIXCC' will be printed.   
   Thanks to Giuseppe Giacomodonato, EPV Tech, ITALY.                   
Change 29.038  Variable ASISDCCP in dataset ZRBASI is now a percentage, 
VMACRMFV       as labeled; and divided by total samples.  Previously, it
Feb 22, 2011   was the (numerator) sample count.                        
   Thanks to Scott Wiig, USBank, USA.                                   
Change 29.037  DB2 V9.1, MXG 28.28-29.01, may print false messages about
Feb 21, 2011   but the test added in Change 28.326 (to detect a truly   
               invalid header that ONLY exists in DB2 V10.1 and that is 
               to be corrected by APAR PM32425) was off by one byte for 
               DB2 V9.1 records.  For either release, nothing is really 
               "deleted"; the only impact is that the INPUT of variable 
               QWHDRQNM, the Requestor Location Name, is skipped, so the
               "DELETED" in the message is changed to "QWHDRQNM SKIPPED"
               and the V10 APAR is printed in the message text.         
   Thanks to Lorena Ortenzi, UniCredit Group, ITALY.                    
Change 29.036  Julian dates of 1999/000 with COMEFROM=7 printed harmless
VMACEDGR       messages that the date was invalid, but should have NOT  
Feb 18, 2011   printed the message; instead the invalid date is stored  
Mar 13, 2011   into RDEXPDCH as character, and RDEXPDTO is set missing, 
Mar 20, 2011   and the test covers COMEFROM=7/48/53 now.                
               Mar 13: DATEDATE=1999/366 now also protected.            
   Thanks to Douglas C. Walter, Citigroup, USA.                         
   Thanks to Brent Turner, Citigroup, USA.                              
Change 29.035  SAS compiler error when _NNTSM was invoked to substitute 
COMPALLN       _NULL_ replacement tokens, and a _NULL_ definition had   
VMACNTSM       only one space between the macro name and "_NULL_" text: 
Feb 17, 2011       MACRO _WNTWFP _NULL_ %%                              
               Inserting an extra blank so that the definition now reads
                   MACRO _WNTWFP  _NULL_ %%                             
               eliminated this error (with full diagnostic options on,  
               the generated code could be seen to be in error, with the
               next line in the source being 'swallowed' into _WNTWFP.) 
               The error was replicated with other _NULL_'s in VMACNTSM.
               All of the VMACxxxx that define _NULL_'s with similar    
               syntax were revised to eliminate the exposure, and some  
               members either did not define _Nxxxx or did not have     
               correct syntax (e.g., the MACRO keyword was missing).    
               to have two blanks.  And, in the process, I discovered   
               several members did not have correct syntax for their    
               _NULL_ definitions( the MACRO keyword was missing).      
               these VMACxxxx members were corrected:                   
               16   DECS 113  HURN SUIN OMVT                            
               MBO  INMV IISL GUTS FDR  AIXT 97   42   109  CISM        
               The error occurred with both PC SAS V9.2 and V9.1.3,     
               but only on Windows (both XP and Seven, 32 and 64 bit).  
   Thanks to Lars Fleischer, SMT Data, DENMARK.                         
Change 29.034  Invalid data for datetime variable SMF30RGT caused error 
VMAC30         message and hex dump, and left SMF30RGT a missing value. 
Feb 17, 2011   Datetime variable SMF30RGT (IXCARM REGISTER event) is    
               input from two IBM fields, SMF30RGT (the time part) and  
               SMF30RGD (the julian date part), but while SMF30RGT had  
               a valid time value, SMF30RGD was null (i.e., hex zeros). 
               The error is circumvented by inserting double question   
               marks for the INPUT of SMF30RGT, while IBM will be       
               contacted to correct their invalid data value in the     
               Automatic Restart Management (ARM) segment of SMF 30-5.  
Change 29.033  Support for IMF Version 4.5 is in place; there were no   
VMACCIMS       changes in the IMS F9/FA records between 4.4 and 4.5.    
Feb 14, 2011                                                            
Change 29.032 -Dataset PDB.IPLS now DOES always report a SYSTEM IPL, but
FORMATS        previously that was not true.  PDB.IPLS is created from  
VMAC0          SMF type zero records, but ID=0 are written both when SMF
VMAC90A        is started (at SYSTEM IPL), and when SMF is RESTARTED    
VMACSMF        (after an SMF address space ABEND, I/O error, etc).  This
Feb 13, 2011   is NOT new; at least since 1992, member ADOC0 has noted  
               (albeit obscurely) that the ID=0 doesn't always report a 
               system was IPL'd.                                        
              -A true System IPL writes either an ID=90 subtype 8 (IPL  
               PROMPT) or ID=90 subtype 10 (IPL SRM).  Now, VMAC0 reads 
               ID=0, ID=90.8 and ID=90.10 records, initially outputting 
               all in dataset TYPE0, but when TYPE0 is sorted by _S0    
               (the product sort macro, invoked by BUILDPDB/PD3/TYPS0), 
               now these two datasets are created:                      
                 PDB.IPLS   - actual system IPLS - ID=90.8 or 90.10 obs 
                 PDB.IPLSMF - all SMF ID=0 observations.                
              -But, note that when SMF has to be restarted, there were  
               SMF records that could not be written and were lost, and 
               no ID=7 record would have been written.                  
              -VMACSMF required update because SMF ID=90 records do not 
               have their subtype in the standard SMF header.           
              -Cosmetic.  TYPE90nn datasets now have variable CMDMVS to 
               identify which command created the record, and CMDMVS is 
               formatted with MG090CM to describe the command.          
              -Format MG090CM was updated for new commands.             
              -These "bogus IPL" events were overlooked because IBM has 
               done such a fine job in those 19 years to eliminate      
               unscheduled IPLs, that tracking them became unimportant! 
               It was only after SMF ABENDs due to a non-IBM product    
               required restarting the SMF address space that this need 
               to redesign MXG's PDB.IPLS dataset surfaced.             
   Thanks to Jerry Urbaniak, Acxiom, USA.                               
Change 29.031  DB2 V9.1 only; most QGBxxx variables in DB2GBPST were not
VMACDB2        correct; MXG had correct INPUT for V8.1 and V10.2 but did
Feb  9, 2011   not have a separate INPUT segment for 9.1, and MXG missed
               the restructure in DB2 V9.1.                             
   Thanks to Rachel Holt, Fidelity Systems, USA.                        
   Thanks to Lori Masulis, Fidelity Systems, USA.                       
Change 29.030 -For DB2 connections (DBMDPTYP='DSN', variable DBMDACCT is
VMACTMDB       input and kept in TMDBDB2 dataset; for Client connections
Feb  9, 2011   these variables are now kept in TMDBDB2 dataset:         
Feb 18, 2011     DBMDPLAT $EBCDIC18.  /*CLIENT*PLATFORM*/               
                 DBMDAPPL $EBCDIC20.  /*CLIENT*APPLICATION*NAME*/       
                 DBMDATID  $EBCDIC8.  /*CLIENT*AUTH*ID*/                
                 DBMDSFLN    &PIB.1.  /*DDCS*ACCOUNT*SUFFIX*LENGTH*/    
                 DBMDSUFX $EBCDIC200. /*DDCS*ACCOUNT*SUFFIX*/           
              -TMDB Version 4.1 BF/BG/BH/BI/BJ/BK/BL/BM records were off
               by 2 bytes, causing DATABASE NAME and other fields to be 
              -Feb 18.  Revisions to BI record's restructure.           
   Thanks to Liliane Paquet, Centre de services partages Quebec, CANADA.
   Thanks to Patricia Abel, Regie des rentes du Quebec, CANADA.         
   Thanks to Ernie Amador, UC Davis Health System, USA.                 
Change 29.029  Variable KW18SP03 was input but not kept nor labeled.    
Feb  9, 2011                                                            
   Thanks to Kim Westcott, NYS Office of Technology, USA.               
Change 29.028  Yet another NDM 'RT' subtype INPUT EXCEEDED error because
VMACNDM        the records do not match the documentation, offsets are  
Feb  8, 2011   inconsistent (PACCT/SACCT sometimes -3, sometimes +1),   
               ACCT values that are not EBCDIC, two segments after ACCT 
               that are undocumented, with wide variances in the data   
               from sites running the same CDI versions, so this change 
               stops reading at the end of the fixed portion of the data
               record, and only looks for the CPUTIME= text string at   
               that point in the record.  If you REALLY, REALLY, need   
               the NDMRT variable data, or the undocumented fields to be
               decoded, be prepared to open a support issue with the CDI
               vendor and have them contact me with their DSECT/data.   
Change 29.027  Cosmetic.  Several variables were incorrectly spelled in 
ADOC110        the documentation of CICS variables.                     
Feb  7, 2011                                                            
   Thanks to Clayton Buck, UniGroup, USA.                               
Change 29.026  Support for zVM APAR VM64794 adds variables to dataset   
VMACVMXA       VXMTRSYS, and new format $MGVXENS to decode new variable 
Feb 11, 2011   SYSESTAT (Ensemble Status).                              
   Thanks to Al Holtz, MEDCO, USA.                                      
   Thanks to Frank Bright, MEDCO, USA.                                  
Change 29.025  Small negative values for CPUUNITS in type 30 subtype 4  
VMAC30         records have been observed in steps with CPUTCBTM=0, when
Feb  7, 2011   the calculated ZIPUNITS (using normalized CPUZIPTM) is   
Nov  3, 2011   greater than the SM30CSUL (original CPU+zIIP+zAAP units).
               While not significant, MXG now forces CPUUNITS=0 when    
               CPUTCBTM=0. The maximum negative CPUUNITS value was -169,
               but with LOSU_SEC=30018, that is only 0.009 CPU seconds. 
               Nov 3: Original text corrected; negative CPUUNITS weren't
               set to zero, but CPUUNITS was set to zero if CPUTCBTM was
               zero.  So small negative values (-1.59 in one record in 8
               million type 30s) could still occur if CPUTCBTM non-zero.
               And, they printed a debugging message with _N_= CPUUNITS=
               that should have been and is now disabled.               
Change 29.024  MXG-created variables INREASON and SOURCE were blank when
VMAC26J2       INDEVICE=Nnnn.RDm and INTRDR=' ', printing messages that 
Mar 24, 2011   is now set.  INREASON and SOURCE are "my" variables that 
               were only used in understanding NJE Purge Records and are
               not actually used for anything.                          
               Mar 24: SOURCE=INDEVICE wasn't set for INTRDR='Y'.       
   Thanks to Jack Schudel, University of Florida, USA.                  
   Thanks to Lars-Olof Thellenberg, Handelsbanken, SWEDEN.              
Change 29.023  Using GTF input, IFCID 3 (DB2ACCT) observations were not 
VMACDB2        output, and a (spurious) INVALID PROD section message was
Feb  5, 2011   printed.  The OFFSMF value has to be changed when GTF is 
               input, but the logic for ID=101 SUBTYPE=0 was incorrect. 
   Thanks to Tony Curry, BMC, USA.                                      
====== Changes thru 29.022 were in MXG 29.01 dated Feb  4, 2011=========
Change 29.022  After Change 28.146 (MXG 28.04+), Buffer Hit Ratio on the
VMXGDBSS       %ANALDB2R(PDB=SMF,...) statistics reports were 100 times 
Feb  4, 2011   too large.  In MXG-built datasets BPHITRAT is a fraction 
               (e.g., .952), but in DB2PM reports IBM prints 95.2.  But 
               Change 28.146 incorrectly multiplied by 100 when creating
               the PDB.ASUMDBSS dataset, and then ANALDB2R multiplied.  
               This change restores the correct fractional value in the 
               ASUMDBSS dataset and lets ANALDB2R still do the multiply.
   Thanks to Ron Wells, American General, USA.                          
   Thanks to Rick Brooks, American General, USA.                        
Change 29.021  Variables SMF89DTO and SMF89HOF were accidentally removed
VMAC89         from dataset TYPE892, and should not have been.  Since   
Feb  4, 2011   they are needed by Al's LCS Product, MXG 29.01 refreshed.
Mar 12, 2011   Mar 12: Variables SMF89SIF,SMF89LPV,SMF89LCR are kept.   
====== Changes thru 29.020 were in MXG 29.01 dated Feb  3, 2011=========
Change 29.020  The definition of MACRO _NEDA, to null all datasets, was 
VMACEDA        missing the MACRO preceding the _WEDAxxx token.          
Feb  3, 2011                                                            
   Thanks to Scott Barry, SBBWorks Inc, USA.                            
Change 29.019  Sample ACF2 reports looked for PDB.ACF2ARR when the real 
ANALACF2       dataset created by TYPSACF2 is named PDB.ACF2AR.         
Feb  3, 2011                                                            
   Thanks to Vitullo Carmen, State of Delaware, USA.                    
Change 29.018  Calculation of MEMP for z196 now subtracts the two       
ASUM113        counters EXTND152 and EXTND155, per John Burg's SHARE    
VMAC113        paper, which I had overlooked since last August.         
Feb  3, 2011   BUT: FEB 18:  The revised calculation was ONLY in the    
Feb 18, 2011   VMAC113 in 29.01; I forgot the calculation is repeated   
               for the z196 code in ASUM113 until today when it was     
               discovered, because, without the correction, the RNI     
               values for z196 were larger than for the same workload   
               on the z10 when they should be about the same.           
   Thanks to Meral Temel, Garanti Teknoloji, TURKEY.                    
   Thanks to Adnam Can, Garanti Teknoloji, TURKEY.                      
Change 29.017 -SERIOUS: MONTHBLD/MONTHBL3/MONTHASC in 28.28 will skip   
MONTHBLD       reading the last day's PDB library (the JAN 2011 MONTH   
MONTHBL3       will be MISSING the MON PDB's observations).             
MONTHASC       This new statement added by Change 28.324                
BLDSMPDB       MUST be corrected to:                                    
Feb  3, 2011      CALL SYMPUT('WEEKDATR',(PUT(TODAY,WEEKDATE3.)));      
               That is the permanent correction.                        
              -BUT, to RERUN JAN 2011 NOW, since it is already Feb 2,   
               you must ALSO replace the existing statement             
                   TODAY=TODAY();       with                            
               just for the JAN REBUILD (and then restore that statement
               before you run the next month's build).                  
                 MONTHBLx normally must execute on the 1st day of the   
                 next month; but comments in MONTHBLx point to ADOCMNTH,
                 for instructions on how to rerun on a different day of 
                 the month; as long as you rebuild during this week,    
                 there is no change needed to the JCL for the JOB.      
                 If you don't see this until NEXT week, then you need   
                 to read the instructions for the required JCL change   
                 when you need to rebuild a MONTHly in a later week     
                 than the normal week with the 1st day of the month.    
              -BLDSMPDB: LIBNAME WEEK1 NOT FOUND when runmnth=yes. Can  
               be circumvented by adding LIBNAME WEEK1 statement with   
               this syntax to rebuild JAN 2001:                         
                 libname week1 'c:\mxg\week1\';                         
               An undocumented requirement of VSETMNTH needs WEEK1,     
               which is now LIBNAME'd to the same directory as WEEK.    
              -I personally apologize for my failure to validate these  
               changes made by MXG Change 28.324.                       
              -Cosmetic, but possibly confusing.  The %PUT statement    
               that prints the date selections printed "LT", but the    
               actual and correct test is for "LE".                     
   Thanks to Robb Hermes, Sentry Insurance, USA.                        
   Thanks to Wanda Prather, FRTIB, USA.                                 
Change 29.016  When the _SMF macro was redesigned to store DB2 IFCID in 
VMACSMF        SUBTYPE, and READDB2 was revised to generate tests using 
Feb  2, 2011   the SUBTYPE instead of IFCID, the _DB2GTF macro was not  
               updated, so %READDB2(INFILE=GTF,IFCIDS=xxx) failed to    
               output any observations. Macro  _DB2GTF is now revised.  
   Thanks to Tony Curry, BMC, USA.                                      
Change 29.015  Support for Version 7, which (COMPATIBLY) added three    
VMAC115        sets of eight variables providing compression statistics,
Feb  1, 2011   one set for each of the three algorithms, although only  
               the first algorithm's variables are currently populated. 
   Thanks to Martyn Jones, Euroclear, BELGIUM.                          
Change 29.014  A new "exit", macro variable &EOFVMXA, for MWINPUT file, 
VMACVMXA       it inserted at the EOF of reading that MONWRITE data so  
VMXGINIT       users can take action if the input file is empty or has  
Jan 29, 2011   invalid (no Control Record) contents.  MONWRITE data is  
               ftp'd to the MXG platform, but an ftp failure causes an  
               empty file, which MXG processes without error, but that  
               has not observations created; that is reported in MXG's  
               "SUCCESSFULLY READ" message as having zero records.      
               This exit allows you to insert your own code to detect   
               there was a failure and you create your own log message  
               and then ABORTing the MXG job to externalize the error.  
               For example, the exit could be used with this syntax:    
                 %LET EOFVMXA=                                          
                 IF NRDRRECS LE 0 OR NRCRTOTL LE 0 OR                   
                    NRBYTOTL LE 0 THEN DO;                              
                 PUT ' ';                                               
                 PUT '#####################################';           
                 PUT 'ERROR: Z/VM MONWRITE FILE IS INVALID.';           
                 PUT '#####################################';           
                 PUT '>>>> CONTACT z/VM Support ON-CALL <<<< ';         
                 PUT '#######################################';         
                 PUT '# DETAILS:';                                      
                 PUT '#######################################';         
                 PUT //" MXG &MXGVERS FOUND THESE COUNTS:"              
                  //+5 'THERE WERE ' NRDRRECS ' MONITOR RECORDS '       
                  //+5 'FROM ' NRCRTOTL ' CONTROL RECORDS WHICH '       
                  //+5 'CONTAINED ' NRBYTOTL COMMA15. ' BYTES, ( '      
                            NRBYTOTL MGBYTES. 'B)';                     
                 PUT '#######################################';         
                 PUT '#######################################';         
                 ABORT ABEND 16;                                        
                 %INCLUDE SOURCLIB(TYPEVMXA);                           
              -Note that after your DO/END group, the "ELSE" is required
               because the exit is inserted ahead of an existing PUT.   
              -Also note that the first line of the sample PUT statement
               has double quotes around the text; this is required so   
               that the &MXGVERS macro variable's value is printed. With
               single quotes only the text MXGVERS would be printed.    
   Thanks to Frank Bright, MEDCO, USA.                                  
   Thanks to Frank Bright, MEDCO, USA.                                  
Change 29.013 -Variable CPCGRPLM in ZRBCPU is only four bytes but MXG   
VMACRMFV       input as 8 bytes; the commented +4 is moved ahead of the 
Jan 30, 2011   input and the informat changed to PIB4.                  
              -Variable LCPUPOLR was incorrectly input from two bits in 
               the first byte of LCPUCHIN; it is the last bit of first  
               byte and first byte of second byte (which is now input   
               and kept as LCPUCHI2).                                   
   Thanks to Matthew Chappell, Dept. of Transport Main Roads, AUSTRALIA 
Change 29.012  Support for Endeavor Version 14 (INCOMPATIBLE because MXG
VMACENDV       did not test the segment length and 20 bytes were added),
Jan 31, 2011   causing many missing variables in ENDVERAC dataset.  The 
               fields added are now decoded and seven variables created.
   Thanks to Rob D'Andrea, CIS, ENGLAND.                                
Change 29.011  Cosmetic. Variables with DATETIME value were stored as   
VMACIMS        length 5 instead of length 8, which can truncate times   
ASUMSYTA       up to 4 seconds.                                         
VMACBE91        DATASET     MEMBER     VARIABLE                         
VMACCYFU        ASUMTAPE    ASUMSYTA    REALMSMF                        
VMAC28          BETA91C     VMACBE91    BE91CSST                        
VMACPMTR        PERFMETR    VMACPMTR    STARTIME                        
VMACPW          PWPDPD      VMACPW      ENDTIME                         
VMACSHDW        PWPDPDI     VMACPW      ENDTIME                         
VMACTMVS        SHADOW05    VMACSHDW    SM05LGTM                        
VMAC90A         TMVSCO      VMACTMVS    IPLTIME                         
VMACVMXA        TYPE9033    VMAC90A     SMF9033T                        
VMACXAM         TYPE9034    VMAC90A     SMF9034T                        
Jan 28, 2011    VXSYTSPT    VMACVMXA    SRXATOD                         
                XAMSYVSW    VMACXAM     VQSCTTOD                        
Change 29.010  Variables NDMPRCNM, NDMPRCNO, and NDMSTEP were not kept  
VMACNDM        in all datasets where they exist in the "NDMPRC" header  
Jan 25, 2011   or in the "Record" data segment; the table in comments at
               the top of VMACNDM has been updated with a new column to 
               identify the datasets that have those variables, and all 
               datasets that are decoded now contain these variables.   
   Thanks to Michael Oujesky, Bank of America, USA.                     
Change 29.009  VMXGUOW fails if //CICSTRAN or //DB2ACCT is on tape, with
VMXGUOW        MXG 28.06 thru MXG 28.28, but the error is circumvented  
Jan 24, 2011   if you add LIBNAME statements to tell MXG it's on tape:  
Jan 31, 2011     //SYSIN DD *                                           
                    LIBNAME CICSTRAN V9SEQ;                             
                    LIBNAME DB2ACCT  V9SEQ;                             
                    %LET PCICTRN=CICSTRAN;                              
                    %LET PDB2ACC=DB2ACCT;                               
                    %LET MACKEEP=  MACRO _NOOBS % MACRO _YESOBS %       
                    %INCLUDE SOURCLIB(ASUMUOW,ASUMCICX);                
              -Prior to Change 28.204, VMXGUOW only tested existence of 
               the _Ldddddd dataset token, but in 28.204, a test for the
               existence of that LIBNAME was added (so we could tell you
               what you did wrong when you didn't have one).  But under 
               z/OS, if the LIBNAME had not been referenced in this SAS 
               session, it is not in DICTIONARY, and MXG fell thru to   
               use WORK for the LIBNAME, but as WORK.CICSTRAN did not   
               exist (your data was in CICSTRAN.CICSTRAN on tape), MXG  
               failed with NOT FOUND BY VARIABLES and MXGWARNS.         
              -In this revision, the EXTFILES table is scanned and if   
               the &PCICTRN "ddname" is found, _LCICTRN is set to       
               CICSTRAN. Likewise, _LDB2ACC and _LMONTSK are set to the 
               normal defaults if not found.                            
              -In all cases, if the LIBNAME pointed to does not exist,  
               VMXGUOW will still fail.                                 
   Thanks to Hugo L. Michel, Prince Georges County, MD, USA.            
Change 29.008 -WEEKBLD/MONTHBLD: to eliminate NOTSORTED errors, MXGNOBY 
VMXGINIT       is now specified in VMXGINIT so there will be no testing 
BLDSMPDB       of the sort order of the input, and no NOTSORTED error.  
Feb  3, 2011  -BLDSMPDB: SORTEDBY=NO is now specified as the default.   
               (Also, LIBNAME=WEEK1 was in error and changed to WEEK.)  
              -Previously, you had to define MXGNOBY with this statement
                  %LET MXGNOBY= MACRO _BY %  MACRO _SORTBY %  ;         
               in your //SYSIN DD, to disable the sort testing and the  
               interleave of input observation in sort order.  That will
               still work fine, but no longer needed with this change.  
               Although I can't see a reason why you would want to go   
               back to the NOTSORTED exposure, you can redefine macro   
               MXGNOBY as null with this syntax to reinstate sorting:   
                  %LET MXGNOBY=  ;                                      
              -The exposure occurs when MXG has to change the sort order
               of a dataset when it is built, and that dataset with new 
               sort order is combined in WEEKBLD/MONTHBLD with datasets 
               that were created with the previous sort order.          
              -The only reason MXG ever changes the sort order is when  
               the initial order was insufficient to remove duplicates  
               with the NODUP option of PROC SORT.  Errors can occur if 
               your old WEEKBLD has the old sort order (TYPE72DL in MXG 
               28.28), or if MXG failed to update the new order in its  
               WEEKBLD/MONTHBLD member (DB2STATS in MXG 28.28)          
              -MXG does not require the WEEKLY and MONTHLY datasets to  
               be sorted; no report programs should ever expect ordered 
               data as there is no way to guarantee someone else didn't 
               sort the dataset after it was first created.             
              -Building sorted output is only a possible performance    
               benefit: if subsequent programs happen to use the same   
               order in their PROC SORT, SAS is smart enough to bypass  
               the unneeded sort, and that was the original purpose for 
               creating WEEKBLD/MONTHBLD in sort order.  And, because   
               the "daily" datasets were already sorted, the WEEKBLD and
               MONTHBLD programs preserved that sort order with a BY    
               statement, without re-sorting.                           
              -However, it turns out that disabling the sort order test 
               and building the output as the concatenation of the input
               datasets instead of interleaving observations to preserve
               the sort order is a REAL performance benefit: benchmarks 
               show a reduction of about 12% of the CPU time with the   
               MXGNOBY enabled.                                         
Change 29.007  Documentation if CICSTRAN variables are EXCLUDEd/DROPPED.
ASUMUOW        This isn't new behavior, and has been in place long time.
ASUMCICX       For ASUMUOW to execute, these BY-VARIABLES are REQUIRED: 
Jan 21, 2011         TRANNAME STRTTIME ENDTIME NETSNAME                 
                     UOWID    UOWIDCHR UOWTIME                          
                  There is no circumvention; ASUMUOW fails without them.
                  These KEPT variables from CICSTRAN aren't required for
                  execution, but MXGWARN messages will be printed if    
                  these variables do not exist in your CICSTRAN:        
                  This list is defined in MACRO _KUOWIDC, which you can 
                  redefine to keep only your variables to eliminate the 
                  MXGWARN messages.                                     
               For ASUMCICX to execute, these BY-VARIABLES are REQUIRED:
                  SYSTEM SHIFT                                          
                  If any do not exist, ASUMCICX fails.                  
                  This list is defined in MACRO _BSUCICS and some can be
                  removed, but you could end up with useless output if, 
                  for example, you didn't keep STRTTIME.                
               If some of these variables are not kept, you can redefine
               _KUOWIDC and _BSUCICS to list only those that exist.     
               For example, these variables are removed from CICSTRAN:  
                   USER OPERATOR TERMINAL USERCHAR                      
               Then you would add the MACRO _KUOWIDC and _BSUCICS into  
               the %LET MACKEEP= in your current JOB:                   
                  //UOWCICX  EXEC MXGSAS92                              
                  //CICSTRAN DD DSN=YOUR.CICSTRAN,DISP=SHR              
                  //DB2ACCT  DD DSN=YOUR.DB2ACCT,DISP=SHR               
                  //PDB      DD DSN=NEW.ASUMUOW,DISP=(,CATLG),...       
                  //SYSIN DD *                                          
                   %LET PCICTRN=CICSTRAN;                               
                   %LET PDB2ACC=DB2ACCT;                                
                   %LET MACKEEP=                                        
                     MACRO _KUOWIDC APPLID LUNAME SYSTEM %              
                     MACRO _NOOBS % MACRO _YESOBS %                     
                   %INCLUDE SOURCLIB(ASUMUOW);                          
                   %INCLUDE SOURCLIB(ASUMCICX);                         
   Thanks to Hugo L. Michel, Prince Georges County, MD, USA.            
Change 29.006  Variables DVRTBV01-DVRTBV32, Returned Borrowed Volumes,  
VMACBVIR       were incorrectly formatted $MGBVIPT but $MGBVIPO is the  
Jan 21, 2011   correct format to decode when printed.                   
   Thanks to Doug Boettcher, Atco I-Tek, CANADA.                        
Change 29.005  Documentation of INTERVAL= change in default RMFINTRV.   
Jan 19, 2011   MXG 28.01, Change 28.046, in MXG default RMFINTRV member,
               but that was not documented, carelessly, but also because
               I didn't think anyone used MXG's default RMFINTRV member.
               I expected each site to have their own tailored RMFINTRV 
               with both INTERVAL= and WORKnn= (maps Service Classes to 
               WORKLOADs) definitions, and thus my default would only be
               used by new sites, and only before they read the INSTALL 
               instructions to tailor those RMFINTRV definitions, so I  
               could change the interval with impunity.  Well, almost!  
               I replaced DETAIL with QTRHOUR because DETAIL creates an 
               observation for every RMF start, including those short   
               interval at each IPL that have VERY high CPU Busy and are
               outliers on normal interval graphs and reports, whereas  
               INTERVAL=QTRHOUR creates equal intervals and smooth data.
               But, with DETAIL, you get an observation with the exact  
               STARTIME of each interval, and if SYNC59 is in use, those
               startimes were of 59:00 14:00 29:00 44:00. But SYNC59=YES
               is the default for Real Intervals, so changing from the  
               INTERVAL=DETAIL to INTERVAL=QTRHOUR, for SYNC59 sites,   
               changed their STARTIMEs to 00: 15: 30: & 45: when they   
               "dropped-in" MXG 28.28 after MXG 27.27.  Tailoring their 
               RMFINTRV with INTERVAL=DETAIL restored original values.  
Change 29.004  ISO format dates with 19990000 for "never expire" are now
VMACEDGR       detected and the DATE variable is set missing.           
Jan 20, 2011                                                            
   Thanks to Harald Seifert, Huk-Coburg, GERMANY.                       
Change 29.003  If you have ancient JCL with //SASAUTOS DD DSN=&&NULLPDS,
VMXGGETM       MXG 28.28 UTILGETM ran much longer (10x) because it did  
Jan 19, 2011   not read the (new in 28.28) %DATATYP macro function from 
               the SAS-provided AUTOCALL PDS. The ERROR message didn't  
               stop the read of the large SMF file, but the message     
               wasn't the expected APPARENT MACRO %DATATYPE NOT FOUND.  
               Because of the way %DATATYP was used, the error was:     
                ERROR: Character operand was found in the %EVAL function
                      ... where %DATATYP(&NRECORD) NE NUMERIC ....      
               The JCL &&NULLPDS token was removed many MXG versions ago
               for unrelated problems and lack of need, but I was not   
               aware that the &NULLPDS stopped the AUTOCALL search, but 
               only recent MXG versions actually use macros (%TRIM) from
               that library. But the %DATATYP was added ONLY to detect  
               that you had mistyped an alphabetic text for NRECORD=,   
               and only in your own %VMXGGETM invocation (UTILGETM has  
               NRECORD=50), so we shot ourselves in the foot adding it. 
               And ONLY to prevent a less-than-clear warning message.   
               DATATYP is no longer used; the logic is in a data step.  
Change 29.002 -APAR OA31615 was NOT supported by MXG 28.28 as claimed.  
VMAC89         That APAR will cause many INVALID SMF89CTZ log messages, 
Jan 20, 2011   but the job does NOT ABEND (unless the log fills!).      
Jan 21, 2011  -MXG detection of records with Invalid Intersect Segments 
Feb  3, 2011   had no limit on the number of Invalid Record messages,   
               but also falsely detected some valid records as invalid. 
               The MXG test was corrected so only true Invalid segments 
               are detected, and only the first 3 are printed on log.   
              -But, feedback from IBM has clarified the new intersect   
               data in new TYPE89I dataset, and MXG was wrong to carry  
               the PRODxxxx variables from the Usage Data Section; those
               variables were removed from the KEEP= list, and from the 
               Sort Order in MACRO _BTY89I, which now uses the CPO-CPI  
               and IPO-IPI variables to order and remove duplicates, and
               is sequenced SMF89UST SMF89IST within those variables.   
              -Unrelated to the APAR, these variables in subtype 2 have 
               never been populated and are no longer kept in TYPE892:  
                 MACHTIME SMF89UET SMF89UST                             
   Thanks to Jim Poletti, Edward D. Jones, USA.                         
   Thanks to Jeana M. Bechtel, Edward D. Jones, USA.                    
   Thanks to Al Sherkow, I/S Management Strategies, Ltd.                
   Thanks to Scott Barry, SBBWorks Inc, USA.                            
   Thanks to Harald Seifert, Huk-Coburg, GERMANY.                       
Change 29.001  Support for SMF 111 IPIC now creates obs in TY111CXI.    
VMAC111        No observations were created because MXG incorrectly had 
Jan 19, 2011   them to be in CTGRECID=2 when they are CTGRECID=7, so the
Jan 24, 2011   code for IPIC was relocated to that correct subtype, and 
               obs are now created.                                     
              -Warning added when a new subtype is detected.            
              -Change 28.329 for SMF 111 was NOT included in 28.28 as   
               originally claimed.                                      
   Thanks to Jim Poletti, Edward D. Jones, USA.                         
   Thanks to Jeana M. Bechtel, Edward D. Jones, USA.                    
   Thanks to Gordon E. Griffith, Edward D. Jones, USA.                  
LASTCHANGE: Version 29.