Annual   MXG Version 23.23 is  dated Feb 20, 2006, thru Change 23.358   
PreRel   MXG Version 23.23 was dated Feb 15, 2006, thru Change 23.351   
Final    MXG Version 23.11 was dated Feb  2, 2006, thru Change 23.340   
Third    MXG Version 23.11 was dated Feb  2, 2006, thru Change 23.338   
Second   MXG Version 23.11 was dated Jan 31, 2006, thru Change 23.336   
First    MXG Version 23.11 was dated Jan 30, 2006, thru Change 23.336   
         MXG Version 23.10 was dated Jan 23, 2006, thru Change 23.328   
         MXG Version 23.09 was dated Dec  7, 2005, thru Change 23.309   
Third    MXG Version 23.09 was dated Dec  6, 2005, thru Change 23.309   
Second   MXG Version 23.09 was dated Dec  1, 2005, thru Change 23.303   
First    MXG Version 23.09 was dated Nov 30, 2005, thru Change 23.300   
         MXG Version 23.08 was dated Oct 27, 2005, thru Change 23.273   
First    MXG Version 23.08 was dated Oct 25, 2005, thru Change 23.271   
Final    MXG Version 23.07 was dated Aug 10, 2005, thru Change 23.209   
First    MXG Version 23.07 was dated Aug  9, 2005, thru Change 23.207   
         MXG Version 23.06 was dated Jun 29, 2005, thru Change 23.176   
         MXG Version 23.05 was dated Jun  7, 2005, thru Change 23.154   
First    MXG Version 23.05 was dated Jun  5, 2005, thru Change 23.148   
         MXG Version 23.04 was dated May  4, 2005, thru Change 23.107   
         MXG Version 23.03 was dated Apr 22, 2005, thru Change 23.090   
         MXG Version 23.02 was dated Apr  4, 2005, thru Change 23.061   
         MXG Version 23.01 was dated Mar 15, 2005, thru Change 23.050   
         MXG Version 22.22 was dated Feb  1, 2005, thru Change 22.378   
         MXG Newsletter FORTY-SIX was dated Feb 1, 2005.                
Contents of member CHANGES:                                             
  Member NEWSLTRS (and the Newsletters frame at now 
  contain the current MXG Technical Notes that used to be put in member 
  CHANGES between Newsletters.  New Technical Notes are now added (and  
  now dated!) in NEWSLTRS/Newsletters with each new MXG Version.        
I.    2006 Annual MXG Software Version 23.23 automatically was sent.    
II.   Incompatibilities and Installation of MXG 23.23.                  
III.  Online Documentation of MXG Software.                             
IV.   Changes Log                                                       
I.  2006 Annual MXG Software Version 23.23 dated February 20, 2006.     
    The Annual Version was available for ftp download on Feb 20, but    
    a CD-ROM containing MXG 23.23 will also be sent to all sites; the   
    copying/packaging began on the 20th, with mailing on Feb 25th, so   
    all sites should receive the package in early March.                
    Major enhancements added in MXG 23.23 - 2006 Annual MXG Version     
  TYPE70   23.348  Final "70's Record Rewrite", PARTNCPU corrected.     
  TYPE115  23.347  Support for MQ for z/OS Version 6.0 (COMPAT)         
  TYPE110  23.342  Support for CANDLE UMBRELLA optional CICSTRAN data.  
  READDB2  23.345  New WANTONLY= enhancement for %READDB2 utility.      
  MONTHxxx 23.351  &MXGSYSN macro variable for compatibility.           
  WEEKxxx  23.351  &MXGSYSN macro variable for compatibility.           
  MACKEEP  23.346  DB2 Tailoring Example to add DB2 102 to PDB.         
    Major enhancements added in MXG 23.11                               
    1. Corrections for "Split 70/Over 60 LPAR" RMF 70 Re-Write.         
  TYPE70   23.330  Corrections to Split 70/Over 60 LPAR Change 23.321.  
    2. Yet another major revision to RMF 70 processing:                 
  TYPE70   23.336  Support for RMF with repeated SYSTEMs in a SYSPLEX.  
    3. ITRM sites that build RMFINTRV do NOT have to change anything;   
       the previous "INCOMPATIBILITY" that required _STY70 to be put    
       in your EXPDBOUT member is NOT needed when RMFINTRV is created,  
       and everyone SHOULD create the XRMFINT/RMFINTRV dataset.         
    "Routine" enhancements/changes:                                     
  TYPENDM  23.331  Support for NDM/Connect Direct subtype TF, TL, TW.   
  TYPE30   23.329  Support for SMF30CEPI field, new CPUCIPTM variable.  
  TYPE7072 23.335  Variables SMF70OIL and SMF70SYN now KEPT in TYPE70.  
  TYPE30_V 23.334  IMACINTV default now OUTPUTs TYPE30_V/PDB.SMFINTRV.  
  TYPEVMXA 23.332  Variables HFLLIST,HFPGACT were accumulated.          
    Major enhancements added in MXG 23.10                               
    1. Support for over 60 LPARs.  Support for Split RMF 70 records.    
       Required extensive rewrite of the "heart and soul" logic in the  
       VMAC7072 and VMXG70PR members, potentially impacting datasets    
       from TYPE7072, TYPS7072, BUILDPDB/BUILDPD3, or RMFINTRV programs.
       New DATA records that now exist that required this change:       
       INCOMPATIBLE: If you have more than 32 LPARs defined, versions   
                     earlier than MXG 23.10 will fail with ARRAY errors.
                     See Change 23.322/23.321 text.                     
       INCOMPATIBLE: IBM now splits RMF 70 records when you have lots of
                     LPARs and lots of spare engines; MXG 22.22+ detects
                     and reports split records were found in messages on
                     the SAS log, but created incomplete/wrong data in  
                     TYPE70/TYPE70PR/ASUM70PR/ASUMCEC from split 70 SMF.
                     See Change 23.322/23.321 text.                     
       New stuff YOU may have to do when you install MXG 23.10 or later:
       INCOMPATIBLE: ITSV/ITRM sites that run BUILDPDB but do NOT create
                     the XRMFINT (RMFINTRV) dataset, MUST insert this   
                     text (an invocation of that old-style macro) in the
                     EXPDBOUT member of the site's "USERID.SOURCLIB" MXG
                     tailoring library.  See Change 23.322/23/321 text. 
                     Note: MOST ITRM SITES DON'T HAVE TO DO ANYTHING!   
                           It is rare for an ITRM site's data dictionary
                           to specify processing of the RMF 70 records  
                           and then NOT create the XRMFINT dataset.     
                           This is ONLY REQUIRED if you have NOT        
                           installed ITRM 27IS03 hotfix applied         
       INCOMPATIBLE: If you use the _VAR7072/_CDE7072 macros in your own
                     programs (or the programs you inherited!), then you
                     must also add the statement  _STY70 after the data 
                     step that reads the SMF data.                      
                     MXG 23.10+ and be corrected and protected.         
       NOTE:  This is the most extensively tested change in MXG history:
              un-split RMF/CMF 70 records from 34 sites with old and new
              z/OS levels, were read with the old and new code and their
              outputs compared with the TEST70SP program; PLEASE use the
              TEST70SP program to read a day's RMF data and then examine
              its reports for any un-documented discrepancies.          
               - SPLIT records can't be directly compared, since the old
                 code mishandled them.   But the MXG data sets were run 
                 thru ANALRMFR and those reports exactly matched IBM's  
                 CPU reports for the split records.  That code has been 
                 in production for weeks with split records with no     
                 reported errors.  MXG now writes a note on the SAS log 
                 that split records were processed, but it's just FYI.  
               - The rewrite corrected some errors and inconsistencies  
                 that are noted in the change text that will cause false
                 positives in the PROC COMPARE output; primarily these  
                 were intervals in which a policy change occurred or in 
                 which an LPAR was not active for the full interval, or 
                 in CPUs with CAI error bits set, and the new results   
                 appears to be correct and consistent.                  
    Major enhancements added in MXG 23.09                               
    1. Critical corrections that require you to install MXG 23.09 for:  
      -JES3 with MXG 23.02 thru 23.08 must install MXG 23.09; there were
       zero observations created in TYPE26J3.  Change 23.282.           
      -DB2 V8.1 Package Data could be truncated. Change 23.280.         
      -z/VM VXSYTEPM deaccumulation now correct. Change 23.290          
      -ASUM70PR corrected for RMF Intervals with DURATM less than 1 min.
  TYPE26J3 23.282  HIPER: 23.02-23.08, JES3 only.  No obs in TYPE26J3.  
  TYPEDB2  23.280  DB2ACCTP Package Data required fix (final, trunc!).  
  TYPEVMXA 23.290  z/VM MONWRITE VXSYTEPM dataset finally correct.      
  ASUM70PR 23.289  RMF Intervals with DURATM less than one minute fix.  
  TYPE70PR 23.288  BMC SMF 70 from z9 have LPARCPUX=0, counts wrong.    
  VMXG70PR 23.276  PDB.ASUMCEC PCTL0OV,LP0MGTTM,LPCT0OV were zero.      
    2. New ML-37 of MXGTMNT captures SYSLOG messages for mounts, but can
       also capture any SYSLOG message into its SMF records.            
  ASMTAPEE 23.300  ML-37 MXGTMNT monitor now captures SYSLOG messages   
  ASUMTAPE 23.300  Now merges SYSLOG, MXGTMNT, and IBM SMF 21s.         
  TYPETMNT 23.300  New TYPESYMT, TYPESYSL datasets from SYSLOG messages.
    3. Easy creation of desired DB2 datasets with only wanted variables.
  READDB2  23.287  Selective creation of DB2 datasets and data now easy.
    4. Other enhancements, followed by less important fixes:            
  TYPE30   23.292  Support for APAR OA11675, EXCPTOTL max now 4 gig.    
  TYPENDM  23.291  Support for CDI/NDM subtypes HW and NM.              
  TYPEVM   23.285  Support for VM Account optional YYMMDD date format.  
  TYPESTC  23.279  Support for STK VTCS 6.0 and 6.1 SMF records (COMPAT)
  TYPE80A  23.275  Support for CA TopSecret 103-105,109,255 SMF80DTPs.  
  TRNDxxxx 23.293  New &INTTRND can change default INTERVAL=WEEK in TRND
  TYPE6    23.284  Print accounting for "Printway" tcp/ip SMF 6 records.
  TYPE26J2 23.277  New UNSPUNJB, JOEPURGE status variables created.     
  TYPE30   23.296  TYPE30_6 RESIDTM/ACTIVETM wrapped after 51 days.     
  TYPEDB2  23.295  DB2ACCTG dataset didn't contain nine QBGA variables. 
  TYPETMVS 23.294  TYPETMVS CIJN and other CI variables INCOMPAT.       
  TESTIBM1 23.281  MXG 23.08 only. ERROR: File WORK.TYPE791.DATA does ..
  VGETENG  23.298  MXG 23.08 only: FILE INSTREAM IN USE.                
  INSTREAM 23.298  MXG 23.08 only: INSTREAM DD was required, not now.   
    Major enhancements added in MXG 23.08                               
  TYPE70   23.270  PCTIFBYn variables restored to TYPE70 dataset.       
  TYPEVMXA 23.269  z/VM MONWRITE dataset VXSYTEMP is now validated.     
  TYPE79   23.268  RMF 79 subtype 9 records are now validated/corrected.
  RMFINTRV 23.265  23.05-23.07. IFA/IFE CPU times zero in RMFINTRV wkld.
  TYPESYSI 23.258  Support for CA SYSVIEW IMS user SMF records.         
  TYPEMWSU 23.254  ADOCMWSU for HP MeasureWare on Sun was updated.      
  ASUMTAPE 23.253  Initial rewrite of ASUMTAPE for TMNT/21 records only.
  ASUMUOW  23.251  More robust definition of "TRANNAME" in PDB.ASUMUOW. 
  READDB2  23.249  OBID and DBID are decoded in DB2 102 Trace datasets. 
  ASMTAPEE 23.247  ML-36 is now available of MXGTMNT.                   
  VGETDDS  23.244  Using VGETDDS to get all DDNAMES can fail.           
  ASMRMFV  23.243  Enhancement to RMF III VSAM Support                  
  TYPE82   23.242  Support for SMF type 82 subtypes 20 and 21 added.    
  ASUMUOW  23.240  IRESPTM and ELAPSTM in PDB.ASUMUOW revised.          
  VMXGDUR  23.239  Support for DURATM keywords TENMIN and FIVEMIN.      
  ASUM70PR 23.237  Variables NRIFACPU,NRIFLCPU added to PDB.ASUM70PR/CEC
  TYPEENDV 23.236  Support for Endeavor Release 7; no changes.          
  TYPEDB2  23.235  DB2TCBTM in DB2ACCT obs with DB2PARTY='R' was wrong. 
  GRAFWLM  23.234  CPU Utilization graph by goal importance, Enrico's.  
  TYPEWWW  23.233  Enhancement/corrections to Web Log support.          
  TYPE1023 23.231  Support for DB2 IFCIC 225.                           
  TYPETMS5 23.229  Support for DEVTYPE='3592' devices in CA-1.          
  TYPEEREP 23.228  INPUT STATEMENT EXCEEDED for IBM ATL record.         
  TYPENDM  23.227  NDMCPUTM in NDMCT is now deaccumulated and correct.  
  TYPEIPAC 23.223  Support for Mobiud/IPAC Rel 6.3 INCOMPATIBLE.        
  TYPE6156 23.219  ICF Catalog 05 record GATGEN and GATWRAP corrected.  
  TYPE88   23.213  All SMF88xxx datetime variables are now local zone.  
    Major enhancements added in MXG 23.07                               
  TYPEDB2  23.181  DB2 V8.1 DB2ACCTP still wrong for multi-package.     
  ASMTAPEE 23.177  ML-34 MXGTMNT now GA, has ASMHSCEX for HSC mounts!!! 
  TYPE7072 23.186  Support for z9 CPU, new CPUTYPE='2094'x INCOMPAT.    
  TYPEMGCR 23.200  Support for MegaCryption's user SMF record           
  TYPETPFC 23.199  Support for TPF Continuous Data Collection TPFCDC.   
  TYPETNG  23.193  Support for TNG AIX CA PROCESS GROUP (PID) object.   
  TYPE7072 23.187  Support for APAR OA10346 adds LPAR User Partion ID.  
  MXGABND  23.184  New %LET MXGABND=nnnn forces ABEND for CICS EXCL ERR.
  TYPE89   23.183  Support for APAR OA11036 added MACHTIME to SMF 89.   
  ASUMTALO 23.201  Condition Code (Return Code) 4 in ASUMTALO eliminated
  BUILD005 23.197  Hardcoded "SPIN" DD replaced by &SPINOUT.            
  IMACICDA 23.190  Comments only. IMACICDA is not used with IMACEXCL.   
    Major enhancements added in MXG 23.06                               
  TYPE6    23.159  PSF SMF 6 with SMF6LN6=24 another INPUT EXCEEDED.    
  TYPE22   23.175  Support for subtype 11 I/O Configuration Change      
  TYPESAMS 23.172  SAMS POOLS record INCOMPATIBLY CHANGED.              
  TYPE99   23.169  Support for SMF 99 Subtype 2 additional segments.    
  TYPEMVCI 23.166  Support for additional CMRFILE fields in CMRDETL.    
  TYPE120  23.164  Support for PQ96144, SM120JHF/JHT corrected.         
  TYPESYNC 23.163  New "SMS" UCB Address caused INVALID ARGUMENT error. 
  TYPE102  23.160  Many new variables added to T102S106 dataset.        
    Major enhancements added in MXG 23.05                               
  TYPEVMXA 23.128  z/VM 5.1 record 1.19 IBM misdocumented, had ERRORs.  
  TYPE119  23.146  Support for new FTP Server Security Section in st 70.
  TYPEPRPR 23.142  Support for Oce's Prisma Print log file.             
  TYPECYFU 23.139  Support for CyberFusion user SMF record validated.   
  TYPECMF  23.136  Support for 2180 RAID RANK data in CMF user record.  
  TYPE80A  23.135  Support for Top Secret Versions 5.2 and 5.3.         
  TYPE80A  23.134  Unexpected RACF TOK80LN2=0 record was deleted.       
  TYPESTC  23.125  Support for HSC V6 changes to STCLMU subtype 4 SMF.  
  TYPEIWAY 23.133  Support for Iway Software's IWAY (aka EDA/SQL) SMF.  
  TYPE102  23.131  Support for DB2 IFCID=313 creates T102S313 dataset.  
  ASUMMIPS 23.126  RPRTCLAS added to identify Service/Reporting Classes.
  ASUM70PR 23.121  BY VARIABLES NOT SORTED corrected, PROC SORT added.  
  TYPE6    23.120  Support for ESS GEPARMKY=004Dx variable ESSMAIL2.    
  TYPETNG  23.113  Zero observations with a Solaris cube.               
  FORMATS  23.144  "Expanded Length" format values revised logic for S2.
  TYPEDB2  23.111  Support for DB2 V8.1 Package Data INCOMPATIBLE.      
  BUILDPDB 23.124  Duplicate SMF 30 interval records duped in SMFINTRV. 
    Major enhancements added in MXG 23.04                               
  TYPEIMS  23.099  Support for IMS Version 9.1 was already in MXG 22.22 
  TYPEDB2  23.098  Support for DB2 V8.1 restructured Package Data.      
  TYPE30   23.101  Support for APAR OA10901, SMF30ZNF zAAP noralize fact
  TYPE74   23.093  Support for Type 74 subtype 8 corrected.             
  TYPETMO2 23.100  TMON for CICS/TS V2.3 for CICS/TS 3.1. No Changes.   
  VGETJESN 23.096  Blank TYPETASK in TYPE30_6 data, STCs, corrected.    
  TYPE6    23.091  Printway File Transfer, z/OS 1.6 from VPS corrected. 
  ASUMTALO 23.104  Enhancement to summarize by "groups".                
  ASUMTMNT 23.104  Enhancement to summarize by "groups".                
    Major enhancements added in MXG 23.03                               
  ASUM70PR 23.071  PDB.ASUMCEC contains CEC total IFA CPU time          
  RMFINTRV 23.071  IFA CPU time added to PDB.RMFINTRV                   
  TYPE7072 23.070  Correction for IBM inability to get STARTIME right.  
  ASUM70PR 23.069  Short RMF interval impacts PDB.ASUMCEC.              
  TYPERMFV 23.080  RMF III data for IFAs added to ZRBASI, ZRBENC        
  ANALPATH 23.078  Path Activity Report includes CMR and OTH pend.      
  UTILEXCL 23.075  CMODNAME=RMI,CMODHEAD=DB2CLOCK didn't generate skip. 
  ANALFIOE 23.074  FICON Open Exchange analysis includes CMR pend time. 
  TYPE73   23.072  Support for APAR OA09921 IBM TotalStorage DS6000.    
  BUILDPD3 23.282  BUILDPD3 now sets Condition/Return Code of zero.     
  TYPE80A  23.066  Support for RACF Events 27, 28, 29 for unix.         
  TYPE78SP 23.064  TYPE78SP only had below-16MB subpool variables.      
  TYPE90A  23.081  WLM Service Policy new name tracked in TYPE9024.     
    Major enhancements added in MXG 23.02                               
  TYPEVMXA 23.051  Support for z/VM Linux Application Server data.      
  TYPEVMXA 23.061  Support for z/VM TCP/IP Application Server data.     
    Major enhancements added in MXG 23.01                               
  Typos    23.012  MXG 22.22 JCLTEST/MXGSASVn had error-causing typos.  
                   These typos only affected your testing of 22.22.     
  VMXGUOW  23.017  Default IMACUOW in 22.22 caused NO BY error.         
                   If you use ASUMUOW, you MUST update your IMACUOW.    
                   If you don't use ASUMUOW, remove it from JCLPDBn.    
  WEEKxxx  23.015  Sort Order for SMFINTRV may have to be changed.      
  MONTHxxx 23.015  Sort Order for SMFINTRV may have to be changed.      
  TYPETMS5 23.045  Support for TMS Release 11 - no changes.             
  TYPEMPLX 23.027  Support for IMPLEX Versions 3.1 and 3.3              
  TYPESTC  23.022  Support for VSM subtype 20, problems with ST 4.      
  TYPECYFU 23.020  Support for CyberFusion user SMF record.             
  TYPE80A  23.006  Support for many new RACF events.                    
  TYPESAMS 23.004  Support for SAMS Vantage "LSPACE" record subtype.    
  TYPECSF2 23.024  CONTROL-D SF2 records INCOMPATIBLY changed.          
  UTILCONT 23.025  Failed if DISP=NEW dataset was contented.            
  TYPE74   23.029  AVGxxxMS variables now FORMAT 6.3.                   
  TYPEVMXA 23.050  z/VM VXBYUSR CPU and DELTATM corrected.              
  TYPEDB2  23.011  DB2 QWHT/QWHU/QWHD/QWHA could be blank/missing.      
  ASUM70PR 23.021  LP0xxxxx variables were not populated.               
  TYPEQACS 23.007  CPU variables in QAPMJOBL were incorrect.            
  TYPENDM  23.001  INPUT STATEMENT EXCEEDED for NDM subtype 'SY'.       
  See member NEWSLTRS or the Newsletters frame at for       
  current MXG Technical Notes that used to be in CHANGES.               
  All of these enhancements are described in the Change Log, below.     
    SAS Version requirement information:                                
      MXG 22.08 or later is REQUIRED for SAS V9.1.2 or V9.1.3; see      
      "Major Enhancements added in MXG 22.08" in CHANGES, for the major 
      items, then search Newsletters for V9 for all of the minor items. 
      MXG executes best under the most recent SAS Version, with all     
      Critical HotFixes installed by your SAS Installer:                
       For SAS V9.1.3 on z/OS:                                          
        There are no reported errors, and MXG's CONFIGV9 now specifies  
        V9SEQ instead of V6SEQ.  V6SEQ does not support long length     
        character variables.  SAS V9.1.3 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 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 still  SAS V9.1 or V9.1.2,
        you MUST install the two hot fixes listed above.                
       For SAS Version 8.2, HotFix Bundle 82BX08 is REQUIRED to be safe.
       Sequential Engine Status:                                        
          V9SEQ is fixed in V9.1.3; it is now the default in CONFIGV9.  
          V6SEQ, if used under V9.1.2, requires SN-013514.              
          V8SEQ was always safe under SAS V8.2, but it wasted CPU time  
            by always compressing when writing in tape format.          
      MXG New-Version QA tests are executed on z/OS with SAS V9.1.3 and 
      V8.2, and on Windows XP with SAS V9.1.3.  But previous QA tests   
      have been run with all SAS releases on z/OS, SAS V8.2 and V9.1 on 
      Linux RH8 on Intel, with V9.1 on Solaris v2.8 on Model V880, and  
      V9.1 on HP-UX v11.11 model rp5470, confirming full compatibility. 
      MXG should execute under SAS V9.1.3 or V8.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.                 
    Availability dates for the IBM products and MXG version required for
    the 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        21.05        
      z/OS    IRD TYPE70PR             Mar 11, 2004        22.01        
      z/OS    IRD TYPE70,RMFINTRV      Mar 22, 2002        22.12        
      z/OS    1.6 - No IFAs            Sep 30, 2004       *22.09        
      z/OS    1.6 - With IFAs          Sep 30, 2004       *22.11        
      z/OS    1.7 (COMPATIBLE CHANGES) Sep 30, 2005        23.05        
      z/OS    IFA data in RMF 79s      Sep 30, 2005        23.10        
      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       *23.09        
      More than 32 LPARs               Jan 30, 2006        23.11        
      SPLIT RMF 70 records             Jan 30, 2006        23.11        
      Duplicate SYSTEMs in a SYSPLEX   Jan 30, 2006        23.11        
      CICS/ESA 3.2                     Jun 28, 1991         9.9         
      CICS/ESA 3.3                     Mar 28, 1992        10.01        
      CICS/ESA 4.1                     Oct 27, 1994        13.09        
      CICS/ESA 5.1 aka CICS/TS V1R1    Sep 10, 1996        14.07        
      CICS-Transaction Server V1R1     Sep 10, 1996        14.07        
      CICS-TS V1R1 with APAR UN98309   Sep 15, 1997        15.06        
      CICS-TS V1R2  CICS/TS 1.2        Oct 27, 1997        15.06        
      CICS-TS V1R3  CICS/TS 1.3        Mar 15, 1999        17.04        
      CICS-TS for Z/OS Version 2.1     Mar 15, 2001        18.11        
      CICS-TS for Z/OS Version 2.2     Jan 25, 2002        19.19        
       CICSTRAN subtype 1 support only                    *19.19        
       CICSTRAN subtype 2 completed                       *19.08        
      CICS-TS for Z/OS Version 2.3     Dec 19, 2003                     
       Using UTILEXCL to create IMACEXCL:                  21.04        
       Reading un-Excluded CICS with TYPE110, no IMACEXCL:*22.04        
      CICS-TS for Z/OS Version 3.1     Mar 15, 2005                     
       Using UTILEXCL to create IMACEXCL:                  22.13        
       Reading un-Excluded CICS with TYPE110, no IMACEXCL: 22.22        
      DB2 2.3.0                        Oct 28, 1991        10.01        
      DB2 3.1.0                        Dec 17, 1993        13.02A       
      DB2 4.1.0 Tolerate               Nov  7, 1995        13.07        
      DB2 4.1.0 Full support           Sep 11, 1996        14.07        
      DB2 5.1.0 Tolerate               Jun 27, 1997        14.14        
      DB2 5.1.0 Full support           Jun 27, 1997        15.02        
      DB2 6.1.0 initial support        Mar 15, 1999        16.09        
      DB2 6.1.0 all buffer pools       Mar 15, 1999        18.01        
      DB2 6.1.0 parallel DB2           Mar 15, 1999        19.19        
      DB2 7.1.0 parallel DB2           Mar 31, 2001        19.19        
      DB2 7.1.0 corrections            Mar 31, 2001        20.06        
      DB2 8.1 Tolerate, 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*       
      DFSMS/MVS 1.1                    Mar 13, 1993        11.11        
      DFSMS/MVS 1.2                    Jun 24, 1994        12.02        
      DFSMS/MVS 1.3                    Dec 29, 1995        13.09        
      DFSMS/MVS 1.4                    Sep 28, 1997        15.04        
      DFSMS/MVS 1.4 HSM                Sep 23, 1998        16.04        
      DFSMS/MVS 1.5                    ??? ??, 1999        16.04        
      MQM 1.1.2, 1.1.3, 1.1.4          Apr 25, 1996        14.02        
      MQ Series 1.2.0                  May 26, 1998        16.02        
      MQ Series 2.1.0                  Oct  2, 1999        17.07        
      MQ Series 5.2                    Dec 16, 2000        18.10        
      MQ Series 5.3                    Dec 16, 2002        21.05        
      NETVIEW 3.1 type 37              ??? ??, 1996        14.03        
      NPM 2.0                          Dec 17, 1993        12.03        
      NPM 2.2                          Aug 29, 1994        12.05        
      NPM 2.3                          ??? ??, 1996        15.08        
      NPM 2.4                          Nov 18, 1998        17.01        
      NPM 2.5                          Feb ??, 2000        18.02        
      NPM 2.6                          Nov ??, 2001        19.06        
      RMDS 2.1, 2.2                    Dec 12, 1995        12.12        
      RMDS 2.3                         Jan 31, 2002        19.11        
      TCP/IP 3.1                       Jun 12, 1995        12.12        
      TCP/IP 3.4                       Sep 22, 1998        16.04        
      WebSphere 5.0 APAR PQ7463        Aug 19, 2003        21.04        
      WebSphere 6.0                    Feb 18, 2006        23.23        
      DOS/VSE POWER V6.3.0             Dec 19, 1998        16.08        
      VM/ESA  2.0                      Dec 23, 1992        10.04        
      VM/ESA  2.1                      Jun 27, 1993        12.02        
      VM/ESA  2.2                      Nov 22, 1994        12.06        
      VM/ESA  2.3                      Jun  1, 1998        16.08        
      VM/ESA  2.4                      Mar  1, 2001        19.03        
      z/VM    3.1                      Mar  1, 2001        19.03        
      z/VM    3.1 DATABYTE=0           May  2, 2002        20.02        
      z/VM    4.2 ??                   May  2, 2002        20.02        
      z/VM    4.4                      Jan 22, 2005        22.22        
      z/VM    5.1                      Jan 22, 2005        22.22        
      IMS log 4.1                      Jul  4, 1994        12.02        
      IMS log 5.1                      Jun  9, 1996        14.05        
      IMS log 6.1                      ???  ?, 199?        20.03        
      IMS log 7.1                      ???  ?, 200?        20.03        
      IMS log 8.1                      May 21, 2003        21.02        
      IMS log 9.1                      Dec ??, 2004?       22.08        
      AS400 3.7.0                      Nov  1, 1996        15.01        
      AS400 4.1.0                      Dec 30, 1996        15.08        
      AS400 4.2.0                      Apr 27, 1998        16.02        
      AS400 4.4.0                      Sep 27, 1999        17.07        
      AS400 4.5.0                      Jul 27, 2000        18.07        
      AS400 5.2.0 - Most records       Jul 23, 2003        21.03        
      AS400 5.2.0 - QAPMMIOP           Jul 23, 2003        22.04        
      AS400 5.3.0                      Jan 22, 2005        22.22        
    Note: Asterisk before the version number means the Version number   
          was changed (to the MXG version required), after an earlier   
          MXG version was listed as supporting this product release,    
          usually because an APAR modified the product's data records.  
          Or a coding error in MXG could be the reason for the change!  
    Availability dates for non-IBM products and MXG version required:   
                                                        MXG Version     
      Product Name                                       Required       
      Demand Technology                                                 
       NTSMF Version 1 Beta                                14.11        
       NTSMF Version 2.0                                   15.05        
       NTSMF Version 2.1                                   15.06        
       NTSMF Version 2.2                                   16.04        
       NTSMF Version 2.3                                   17.10        
       NTSMF 2.4.4                     Aug  9, 2002        20.04        
       NTSMF 2.4.5   INCOMPAT          Apr  1, 2003        21.02        
       NTSMF 2.4.7                     Sep 30, 2004        22.08        
       The Monitor for DB2 Version 2                       13.06        
       The Monitor for DB2 Version 3.0                     16.02        
       The Monitor for DB2 Version 3.1                     20.04        
       The Monitor for CICS/ESA 1.2 -                      12.12        
       The Monitor for CICS/ESA 1.3 -                      15.01        
       The Monitor for CICS/ESA 2.0 -                      15.06        
       The Monitor for CICS/ESA 2.1 -                      20.04        
       The Monitor for CICS/ESA 2.2 - 20.335, 21.134       21.04        
       The Monitor for CICS/ESA 2.3 including cics/ts 3.1  22.08        
       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 MVS/ESA 3.1  -                      21.02        
       Omegamon for CICS V200 User SMF                     12.05        
       Omegamon for CICS V300 User SMF                     13.06        
       Omegamon for CICS V400 User SMF                     16.02        
       Omegamon for CICS V400 type 110 segments            16.02        
       Omegamon for CICS V500 User SMF                     18.01        
       Omegamon for IMS V110 (ITRF)                        12.12        
       Omegamon for IMS V300 (ITRF)                        14.04        
       Omegamon for MVS V300                               13.05        
       Omegamon for MVS V400                               13.06        
       Omegamon for DB2 Version 2.1/2.2                    13.05        
       Omegamon for VTAM V160                              12.04A       
       Omegamon for VTAM V400                              15.15        
       Omegamon for VTAM V500                              18.08        
       Omegamon for SMS V100/V110                          12.03        
       ACF2 6.2                                            16.04        
       ASTEX 2.1                                           14.04        
       NETSPY 4.7                                          14.03        
       NETSPY 5.0                                          14.03        
       NETSPY 5.2                                          16.05        
       NETSPY 5.3                                          18.03        
       NETSPY 6.0                                          20.10 20.305 
       NETSPY 7.0                                          20.10 20.305 
       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)                               22.08        
       LMS 3.1                                             12.12A       
       APAF 4.1, 4.3                                       16.08        
      Velocity Software                                                 
       XAMAP 3.4                                           22.10        
II.   Incompatibilities and Installation of MXG 23.09.                  
 1. Incompatibilities introduced in MXG 23.09 (since MXG 22.22):        
  a- Changes in MXG architecture made between 23.11 and 22.22 that might
     introduce incompatibilities.                                       
      ITRM Sites MUST add _STY70 invocation in their EXPDBOUT member.   
         See Change 23.321.                                             
      If you use MXG _VAR7072 and _CDE7072 in your own program to read  
         RMF 70s, you MUST now invoke _STY70 after your data step due   
         to MXG support for split SMF 70 records.  Change 23.321.       
 2. Installation and re-installation procedures are described in detail 
    in member INSTALL (which also lists common Error/Warning messages a 
    new user might encounter), and sample JCL is in member JCLINSTL.    
    MXG Definitions with regard to MXG Software Changes:                
    COMPATIBLE   A change in a data record which did not alter either   
                 the location or the format of all of the previously-   
                 kept MXG variables is COMPATIBLE, and you can continue 
                 to run the old version of MXG software, which will read
                 the new records without error, but none of any new data
                 fields or any new record subtypes will be created/kept 
                 until you install the MXG Version with this change.    
                 A change that alters any previously kept variable is   
                 INCOMPATIBLE, and requires the new version to be used. 
    TOLERATE     In other words, the old MXG Version TOLERATES the new  
                 data records, if they are COMPATIBLY changed.          
    EXPLOIT      Once you use the new MXG Version to read the changed   
                 records, all of the new fields, subtypes, etc, that are
                 described in this change will be created in the MXG    
                 datasets, so the new MXG Version EXPLOITS the new data,
                 and you have full support of the new data records.     
    INCOMPAT     A change in a data record that causes the current MXG  
                 version to fail, visibly or invisibly, with or without 
                 error conditions or messages, and the output datasets  
                 may contain wrong values and incomplete observations,  
                 and/or observations may have been lost.                
                 You MUST install the new MXG Version with this change  
                 to process data records that have been INCOMPATIBLY    
                 changed by their vendor.                               
III.  Online Documentation of MXG Software.                             
    MXG Documentation is now described in member DOCUMENT.              
    See also member INDEX, but it may be overwhelming.                  
IV.   Changes Log                                                       
--------------------------Changes Log---------------------------------  
 You MUST read each Change description to determine if a Change will    
 impact your site.  All changes have been made in this MXG Library.     
 Member CHANGES always identifies the actual version and release of     
 MXG Software that is contained in that library.                        
 The CHANGES selection on our homepage at            
 is always the most current information on MXG Software status,         
 and is frequently updated.                                             
 Important changes are also posted to the MXG-L ListServer, which is    
 also described by a selection on the homepage.  Please subscribe.      
 The actual code implementation of some changes in MXG SOURCLIB may be  
 different than described in the change text (which might have printed  
 only the critical part of the correction that need be made by users).  
 Scan each source member named in any impacting change for any comments 
 at the beginning of the member for additional documentation, since the 
 documentation of new datasets, variables, validation status, and notes,
 are often found in comments in the source members.                     
_PAGE_  8                                                               
Alphabetical list of important changes in MXG 23.11 after MXG 22.22:    
  Member   Change    Description                                        
  Typos    23.012  MXG 22.22 JCLTEST/MXGSASVn had error-causing typos.  
  ANALFIOE 23.074  FICON Open Exchange analysis includes CMR pend time. 
  ANALPATH 23.078  Path Activity Report includes CMR and OTH pend.      
  ASMHSCEX 23.177  ML-34 MXGTMNT GA, has ASMHSCEX for HSC mounts!!      
  ASMRMFV  23.243  Enhancement to RMF III VSAM Support                  
  ASMTAPEE 23.177  ML-34 MXGTMNT GA, has ASMHSCEX for HSC mounts!!      
  ASMTAPEE 23.247  ML-36 is now available of MXGTMNT.                   
  ASMTAPEE 23.300  ML-37 MXGTMNT monitor now captures SYSLOG messages   
  ASUM70PR 23.021  LP0xxxxx variables were not populated.               
  ASUM70PR 23.069  Short RMF interval impacts PDB.ASUMCEC.              
  ASUM70PR 23.071  PDB.ASUMCEC contains CEC total IFA CPU time          
  ASUM70PR 23.121  BY VARIABLES NOT SORTED corrected, PROC SORT added.  
  ASUM70PR 23.237  Variables NRIFACPU,NRIFLCPU added to PDB.ASUM70PR/CEC
  ASUM70PR 23.289  RMF Intervals with DURATM less than one minute fix.  
  ASUM70PR 23.322  Support for 60 LPARs - INCOMPATIBLE                  
  ASUMCACH 23.073  MODEL, taken from DEVMODEL, added to BY list.        
  ASUMDB2  23.319  Summary of DB2ACCT detail into interval buckets.     
  ASUMMIPS 23.126  RPRTCLAS added to identify Service/Reporting Classes.
  ASUMTALO 23.104  Enhancement to summarize by "groups".                
  ASUMTALO 23.201  Condition Code (Return Code) 4 in ASUMTALO eliminated
  ASUMTAPE 23.253  Initial rewrite of ASUMTAPE for TMNT/21 records only.
  ASUMTAPE 23.300  Now merges SYSLOG, MXGTMNT, and IBM SMF 21s.         
  ASUMTMNT 23.104  Enhancement to summarize by "groups".                
  ASUMUOW  23.240  IRESPTM and ELAPSTM in PDB.ASUMUOW revised.          
  ASUMUOW  23.251  More robust definition of "TRANNAME" in PDB.ASUMUOW. 
  BUILD005 23.197  Hardcoded "SPIN" DD replaced by &SPINOUT.            
  BUILDPD3 23.282  BUILDPD3 now sets Condition/Return Code of zero.     
  BUILDPDB 23.124  Duplicate SMF 30 interval records duped in SMFINTRV. 
  CONFIGV9 23.061  SEQENGINE=V9SEQ now default in CONFIGV9 for 9.1.3.   
  FORMATS  23.144  "Expanded Length" format values revised logic for S2.
  GRAFWLM  23.234  CPU Utilization graph by goal importance, Enrico's.  
  IMAC6ESS 23.008  Invalid ESS data caused INPUT STATEMENT EXCEEDED.    
  IMACICDA 23.190  Comments only. IMACICDA is not used with IMACEXCL.   
  INSTREAM 23.298  MXG 23.08 only: INSTREAM DD was required, not now.   
  MACKEEP  23.346  DB2 Tailoring Example to add DB2 102 to PDB.         
  MONTHxxx 23.351  &MXGSYSN macro variable for compatibility.           
  MXGABND  23.184  New %LET MXGABND=nnnn forces ABEND for CICS errors.  
  READDB2  23.249  OBID and DBID are decoded in DB2 102 Trace datasets. 
  READDB2  23.287  Selective creation of DB2 datasets and data now easy.
  READDB2  23.345  New WANTONLY= enhancement for %READDB2 utility.      
  RMFINTRV 23.071  IFA CPU time added to PDB.RMFINTRV                   
  RMFINTRV 23.265  23.05-23.07. IFA/IFE CPU times zero in RMFINTRV wkld.
  TESTIBM1 23.281  MXG 23.08 only. ERROR: File WORK.TYPE791.DATA does ..
  TRNDxxxx 23.293  New &INTTRND can change default INTERVAL=WEEK in TRND
  TYPE102  23.056  Dataset T102S199 was incorrect; only first seg output
  TYPE102  23.131  Support for DB2 IFCID=313 creates T102S313 dataset.  
  TYPE102  23.160  Many new variables added to T102S106 dataset.        
  TYPE1023 23.231  Support for DB2 IFCIC 225.                           
  TYPE110  23.077  CICS STAT RECORD STID=106 message.                   
  TYPE110  23.342  Support for CANDLE UMBRELLA optional CICSTRAN data.  
  TYPE115  23.347  Support for MQ for z/OS Version 6.0 (COMPAT)         
  TYPE116  23.049  MQM variable QWHCCV QWHSSSID renamed.                
  TYPE119  23.146  Support for new FTP Server Security Section in st 70.
  TYPE120  23.164  Support for PQ96144, SM120JHF/JHT corrected.         
  TYPE22   23.175  Support for subtype 11 I/O Configuration Change      
  TYPE26J2 23.277  New UNSPUNJB, JOEPURGE status variables created.     
  TYPE26J3 23.282  HIPER: 23.02-23.08, JES3 only.  No obs in TYPE26J3.  
  TYPE30   23.101  Support for APAR OA10901, SMF30ZNF zAAP noralize fact
  TYPE30   23.292  Support for APAR OA11675, EXCPTOTL max now 4 gig.    
  TYPE30   23.296  TYPE30_6 RESIDTM/ACTIVETM wrapped after 51 days.     
  TYPE30   23.329  Support for SMF30CEPI field, new CPUCIPTM variable.  
  TYPE30_V 23.334  IMACINTV default now OUTPUTs TYPE30_V/PDB.SMFINTRV.  
  TYPE6    23.091  Printway File Transfer, z/OS 1.6 from VPS corrected. 
  TYPE6    23.120  Support for ESS GEPARMKY=004Dx variable ESSMAIL2.    
  TYPE6    23.159  PSF SMF 6 with SMF6LN6=24 another INPUT EXCEEDED.    
  TYPE6    23.284  Print accounting for "Printway" tcp/ip SMF 6 records.
  TYPE6156 23.219  ICF Catalog 05 record GATGEN and GATWRAP corrected.  
  TYPE70   23.270  PCTIFBYn variables restored to TYPE70 dataset.       
  TYPE70   23.330  Corrections to Split 70/Over 60 LPAR Change 23.321.  
  TYPE70   23.348  Final "70's Record Rewrite", OS/390 support!         
  TYPE7072 23.013  LPARCPUX kept in TYPE70PR for count of reserved CPs  
  TYPE7072 23.070  Correction for IBM inability to have STARTIME right. 
  TYPE7072 23.083  Variable NRCPUD, CPU segments this MVS, added.       
  TYPE7072 23.186  Support for z9 CPU, new CPUTYPE='2094'x, INCOMPAT.   
  TYPE7072 23.187  Support for APAR OA10346 adds LPAR User Partion ID.  
  TYPE7072 23.306  PARTNCPU final correction for z9 microcode error.    
  TYPE7072 23.321  Support for Split RMF 70 Records: INCOMPATIBLE       
  TYPE7072 23.322  Support for 60 LPARs - INCOMPATIBLE                  
  TYPE7072 23.335  Variables SMF70OIL and SMF70SYN now KEPT in TYPE70.  
  TYPE70PR 23.288  BMC SMF 70 from z9 have LPARCPUX=0, counts wrong.    
  TYPE73   23.072  Support for APAR OA09921 IBM TotalStorage DS6000.    
  TYPE74   23.029  AVGxxxMS variables now FORMAT 6.3.                   
  TYPE74   23.093  Support for Type 74 subtype 8 corrected.             
  TYPE78SP 23.064  TYPE78SP only had below-16MB subpool variables.      
  TYPE79   23.268  RMF 79 subtype 9 records are now validated/corrected.
  TYPE80A  23.006  Support for many new RACF events.                    
  TYPE80A  23.066  Support for RACF Events 27, 28, 29 for unix.         
  TYPE80A  23.134  Unexpected RACF TOK80LN2=0 record was deleted.       
  TYPE80A  23.135  Support for Top Secret Versions 5.2 and 5.3.         
  TYPE80A  23.275  Support for CA TopSecret 103-105,109,255 SMF80DTPs.  
  TYPE82   23.242  Support for SMF type 82 subtypes 20 and 21 added.    
  TYPE88   23.213  All SMF88xxx datetime variables are now local zone.  
  TYPE89   23.183  Support for APAR OA11036 added MACHTIME to SMF 89.   
  TYPE90A  23.081  WLM Service Policy new name tracked in TYPE9024.     
  TYPE99   23.169  Support for SMF 99 Subtype 2 additional segments.    
  TYPEBE91 23.311  Support for Beta 91 Version, INCOMPATIBLE.   
  TYPECMF  23.136  Support for 2180 RAID RANK data in CMF user record.  
  TYPECSF2 23.024  CONTROL-D SF2 records INCOMPATIBLY changed.          
  TYPECYFU 23.020  Support for CyberFusion user SMF record.             
  TYPECYFU 23.139  Support for CyberFusion user SMF record validated.   
  TYPEDB2  23.011  DB2 QWHT/QWHU/QWHD/QWHA could be blank/missing.      
  TYPEDB2  23.082  QWHSLOCN CONTAINS UNICODE TEXT message               
  TYPEDB2  23.098  Support for DB2 V8.1 restructured Package Data.      
  TYPEDB2  23.111  Support for DB2 V8.1 Package Data INCOMPATIBLE.      
  TYPEDB2  23.181  DB2ACCTP data was still wrong for DB2 V8.1, fixed.   
  TYPEDB2  23.235  DB2TCBTM in DB2ACCT obs with DB2PARTY='R' was wrong. 
  TYPEDB2  23.280  DB2ACCTP Package Data required fix (final, trunc!).  
  TYPEDB2  23.295  DB2ACCTG dataset didn't contain nine QBGA variables. 
  TYPEENDV 23.236  Support for Endeavor Release 7; no changes.          
  TYPEEREP 23.228  INPUT STATEMENT EXCEEDED for IBM ATL record.         
  TYPEHSM  23.179  All byte-containing HSM variables FORMATed MGBYTES.  
  TYPEIMS  23.099  Support for IMS Version 9.1 was already in MXG 22.22 
  TYPEIPAC 23.223  Support for Mobiud/IPAC Rel 6.3 INCOMPATIBLE.        
  TYPEIWAY 23.133  Support for Iway Software's IWAY (aka EDA/SQL) SMF.  
  TYPEMGCR 23.200  Support for MegaCryption's user SMF record           
  TYPEMPLX 23.027  Support for IMPLEX Versions 3.1 and 3.3              
  TYPEMPLX 23.143  IMPLEX subtype 4 revised, validated.                 
  TYPEMVCI 23.166  Support for additional CMRFILE fields in CMRDETL.    
  TYPEMWSU 23.254  ADOCMWSU for HP MeasureWare on Sun was updated.      
  TYPENDM  23.001  INPUT STATEMENT EXCEEDED for NDM subtype 'SY'.       
  TYPENDM  23.227  NDMCPUTM in NDMCT is now deaccumulated and correct.  
  TYPENDM  23.291  Support for CDI/NDM subtypes HW and NM.              
  TYPENDM  23.331  Support for NDM/Connect Direct subtype TF, TL, TW.   
  TYPEPRPR 23.142  Support for Oce's Prisma Print log file.             
  TYPEQACS 23.007  CPU variables in QAPMJOBL were incorrect.            
  TYPERMFV 23.080  RMF III data for IFAs added to ZRBASI, ZRBENC        
  TYPESAMS 23.004  Support for SAMS Vantage "LSPACE" record subtype.    
  TYPESAMS 23.172  SAMS POOLS record INCOMPATIBLY CHANGED.              
  TYPESTC  23.022  Support for VSM subtype 20, problems with ST 4.      
  TYPESTC  23.125  Support for HSC V6 changes to STCLMU subtype 4 SMF.  
  TYPESTC  23.279  Support for STK VTCS 6.0 and 6.1 SMF records (COMPAT)
  TYPESYNC 23.163  New "SMS" UCB Address caused INVALID ARGUMENT error. 
  TYPESYSI 23.258  Support for CA SYSVIEW IMS user SMF records.         
  TYPETHST 23.076  BMC THRDHIST file contains invalid package records.  
  TYPETMNT 23.300  New TYPESYMT, TYPESYSL datasets from SYSLOG messages.
  TYPETMO2 23.100  TMON for CICS/TS V2.3 for CICS/TS 3.1. No Changes.   
  TYPETMS5 23.045  Support for TMS Release 11 - no changes.             
  TYPETMS5 23.229  Support for DEVTYPE='3592' devices in CA-1.          
  TYPETMVS 23.294  TYPETMVS CIJN and other CI variables INCOMPAT.       
  TYPETNG  23.113  Zero observations with a Solaris cube.               
  TYPETNG  23.193  Support for TNG AIX CA PROCESS GROUP (PID) object.   
  TYPETPFC 23.199  Support for TPF Continuous Data Collection TPFCDC.   
  TYPETPFC 23.324  TPF Continuous Data rate variables now calculated.   
  TYPEVM   23.285  Support for VM Account optional YYMMDD date format.  
  TYPEVMXA 23.050  z/VM VXBYUSR CPU and DELTATM corrected.              
  TYPEVMXA 23.060  Support for z/VM 5.1 enhanced: all new data supported
  TYPEVMXA 23.128  z/VM 5.1 record 1.19 misdocumented, caused ERRORs.   
  TYPEVMXA 23.269  z/VM MONWRITE dataset VXSYTEMP is now validated.     
  TYPEVMXA 23.290  z/VM MONWRITE VXSYTEPM dataset finally correct.      
  TYPEVMXA 23.332  Variables HFLLIST,HFPGACT were accumulated.          
  TYPEWWW  23.026  Zero length URIQVALU caused INVALID ARGUMENT.        
  TYPEWWW  23.233  Enhancement/corrections to Web Log support.          
  TYPExxxx 23.052  New EOdddddd, _Odddddd MXG architecture enhancements.
  UTILBLDP 23.036  CC=4 with BUILDPDB=NO eliminated, now CC=0.          
  UTILBLDP 23.057  Enhanced; USERADD supports SMF record number.        
  UTILBLDP 23.087  EXPDBOUT= a %INCLUDE failed when output executed.    
  UTILCONT 23.025  Failed if DISP=NEW dataset was contented.            
  UTILEXCL 23.075  CMODNAME=RMI,CMODHEAD=DB2CLOCK didn't generate skip. 
  VGETDDS  23.244  Using VGETDDS to get all DDNAMES can fail.           
  VGETENG  23.298  MXG 23.08 only: FILE INSTREAM IN USE.                
  VGETJESN 23.096  Blank TYPETASK in TYPE30_6 data, STCs, corrected.    
  VMXG70PR 23.276  PDB.ASUMCEC PCTL0OV,LP0MGTTM,LPCT0OV were zero.      
  VMXGDUR  23.239  Support for DURATM keywords TENMIN and FIVEMIN.      
  VMXGFOR  23.127  Semi-colon at end of macro invocation in AUTOCALL.   
  VMXGUOW  23.017  Default IMACUOW in 22.22 caused NO BY error.         
  %VMXGVERS 23.005 New %VMXGVERS member embedded to detect old versions.
  WEEKBLD  23.246  Support for adding un-sorted datasets to WEEKLY PDB. 
  WEEKxxx  23.015  Sort Order for SMFINTRV must be changed              
  WEEKxxx  23.351  &MXGSYSN macro variable for compatibility.           
Inverse chronological list of all Changes:                              
NEXTCHANGE: Version 23.                                                 
====== Changes thru 23.358 were in MXG 23.23 dated Feb 20, 2006=========
Change 23.358  Support for WebSphere Application Server z/OS Version 6.0
VMAC120        compatibly added 8-byte fields to replace 4-byte fields  
Feb 18, 2006   in the Server Activity CSS and Server Interval SIL data. 
               MXG stores the new data into the existing variable names,
               which were already formatted MGBYTES and thus kept long. 
   Thanks to Victoria Lepak, Aetna, USA.                                
Change 23.357  Macro variable "SYSNAME" is renamed "MXGSYSN" as SAS has 
DOC            recommended (SN-012275) that "SYS" not be used as a macro
Feb 18, 2006   variable name's prefix.  Only sites with duplicate SYSTEM
               names in the same SYSPLEX will need to change the default
               value (blank) to "SYSNAME" as noted in Change 23.351.    
               Those sites could simply put this statement              
                  %LET MXGSYSN=SYSNAME;                                 
               in their IMACKEEP member so their WEEKLY/MONTHLY will use
               SYSNAME in its BY processing.                            
   Thanks to Chuck Hopf, MBNA, USA.                                     
Change 23.356  Cosmetic, unless you are running a non-PR/SM system.  The
VMAC7072       recalculation of CPUUPTM and CPUACTTM used the PR/SM vars
Feb 17, 2006   and overwrote the just-finished non-PR/SM calculation.   
   Thanks to Douglas C. Walter, CITIGROUP, USA.                         
Change 23.355  Enhancement to DB2PM-like reports, adds CONNTYPE= option 
ANALDB2R       for selection criteria for Accounting Detail (PMACC02).  
Feb 17, 2006   For example, CONNTYPE=4, selects only CICS connections.  
   Thanks to John Paul, HighMark, USA.                                  
Change 23.354  MXG 23.23 PreRel; variable PARTNCPU, the count of engines
VMAC7072       in the box/partition, could be too large, if you have ICF
Feb 17, 2006   or IFA engines, in some cases.  The test to use SMF70BNP 
Feb 19, 2006   instead of NRCPSCPU (temp count PHYSICAL CPs) was added  
               to protect sites that won't let an LPAR see its physical 
               segments, was replaced with IF NRCPSCPU GT 0 instead of  
               comparing IF PARTNCPU GT NRCPSCPU.                       
              -Feb 19: NRCPSCPU was removed from a DROP statement where 
                       it didn't belong, but it is NOT a kept variable. 
              -Apr  7: How do you cause SMF 70s to not have a PHYSICAL  
                       LPAR segment, and not report on other LPARs?     
                       On the HMC, there is a Global Performance Data   
                       Control switch, which controls the amount of data
                       returned by the Diagnose instruction RMF uses to 
                       obtain CPU utilization information; if not on,   
                       the RMF 70s will contain only information on this
                       SYSTEM, and there will be no PHYSICAL segments.  
   Thanks to Stan Adriaensen, Axa-Tech Belgium GIE, BELGIUM.            
   Thanks to Scott Barry, SBBWorks, USA.                                
Change 23.353  Support for OCE Prisma Ser5ver Version 3.04 added new    
FORMATS        data, compatibly, to their user SMF records, and new     
VMACPRPR       values for the existing MGPRPRA format, in this perfectly
Feb 17, 2006   written user contribution update.                        
   Thanks to Siegfried Trantes, IDG, GERMANY.                           
   Thanks to Willi Weinberger, IDG, GERMANY.                            
Change 23.352  Short ML-36 SYSLOG record caused INPUT STATEMENT EXCEEDED
VMACTMNT       error for the subtype 8 record.  ASMTAPEE at ML-38 fixes 
Feb 16, 2006   the short record, and VMACTMNT now tests SYSLLEN before  
               it inputs the MSGID fields in the captured SYSLOG event. 
   Thanks to Keith McWhorter, Georgia Technology Authority, USA.        
====== Changes thru 23.351 were in MXG 23.23 dated Feb 15, 2006=========
Change 23.351  Change 23.336 had to change the RMF dataset sort order to
MONTHBL3       by inserting SYSNAME, but if SYSNAME does not exist in an
MONTHBLD       old PDB, your weekly/monthly/etc combining job fails with
MONTHDSK       While MXG must use SYSNAME in its logic, only sites with 
VMXGINIT       duplicate SYSTEM names actually need SYSNAME in their    
WEEK70PR       BY list for their weekly/monthly jobs, so this change:   
WEEKBL3          - defines macro variable &MXGSYSN, with blank value    
WEEKBL3D         - uses &MXGSYSN in BY statements for post processing of
WEEKBL3T           daily/weekly/monthly datasets.                       
WEEKBLD        With the blank default, then your weekly/monthly jobs    
WEEKBLDD       will not fail when old/new RMF datasets with/without the 
WEEKBLDT       SYSNAME variable are combined.                           
Feb 15, 2006      If you have duplicate SYSTEM names, then when all of  
Feb 18, 2006      the input datasets to the week/month merge contain    
                  variable SYSNAME, you would then use this statement   
                      %LET MXGSYSN=SYSNAME;                             
                      %INCLUDE SOURCLIB(Weekbld, monthbld, ... etc);    
               Feb 18: The PreRelease use macro variable "SYSNAME" but  
                       Change 23.357 changed it to MXGSYSN.             
Change 23.350  Labels for variables DSxTCBAF are now "ATTACH*FAILURES"  
VMAC110        instead of "ATTACHES".                                   
Feb 15, 2006                                                            
   Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.  
Change 23.349  The exit _EPDBOUT is again invoked when BUILDPDB=NO; it  
UTILBLDP       had been in MXG 22.22, but was lost along the way.  Note,
Feb 15, 2006   however, that EXPDBOUT=_EPDBOUT and BUILDPDB=YES can not 
Feb 16, 2006   be used together, and a new warning message will be print
               if they are both specified.                              
              -Feb 16, 2006: Revised so EXPDBOUT= argument is now always
               created either when BUILDPDB=YES is used or if EXPDBOUT  
               argument is non-blank.                                   
   Thanks to Scott Barry, SBBWorks, Inc, USA.                           
   Thanks to Robbie A. McCoy, Salt River Project, USA.                  
Change 23.348  Final (?) "70's Record Rewrites" change, for OS/390 R2.1!
VMAC7072       The last error in validation was caused by really old RMF
VMXG70PR       records from OS/390 R2.1 that didn't have SMF70CIN field,
VMXGRMFI       which caused PARTNCPU to be zero.  The revision uses the 
Feb 14, 2006   value in SMF70BNP when SMF70CIN is not populated.        
              -PROC DELETEs were added for a few WORK datasets that were
               not deleted after their last use, but now are.           
   Thanks to Dr. Alexander Raeder, AtosOrigin, GERMANY.                 
Change 23.347  Support for Websphere MQ for z/OS Version 6.0 (COMPAT).  
VMAC115       -Added compatibly, i.e., at end of SMF 115 records:       
VMAC116        Data Set MQMMSGDM new sets of duration variables:        
Feb 14, 2006     LMSDEL  ='DB2 BLOB*DELETE*REQUESTS'                    
                 LMSDSCUW='DB2 BLOB DELETE*SQL DELETE*CUM-TM'           
                 LMSDSMXW='DB2 BLOB DELETE*SQL DELETE*MAX-TM'           
                 LMSINS  ='DB2 BLOB*INSERT*REQUESTS'                    
                 LMSISCUW='DB2 BLOB WRITE*SQL DELETE*CUM-TM'            
                 LMSISMXW='DB2 BLOB WRITE*SQL DELETE*MAX-TM'            
                 LMSITCUW='DB2 BLOB WRITE*THREAD DELETE*CUM-TM'         
                 LMSITMXW='DB2 BLOB WRITE*THREAD DELETE*MAX-TM'         
                 LMSLIS  ='DB2 BLOB*LIST*REQUESTS'                      
                 LMSLSCUW='DB2 BLOB LIST*SQL DELETE*CUM-TM'             
                 LMSLSMXW='DB2 BLOB LIST*SQL DELETE*MAX-TM'             
                 LMSLTCUW='DB2 BLOB LIST*THREAD DELETE*CUM-TM'          
                 LMSLTMXW='DB2 BLOB LIST*THREAD DELETE*MAX-TM'          
                 LMSSEL  ='DB2 BLOB*READ*REQUESTS'                      
                 LMSSSCUW='DB2 BLOB READ*SQL DELETE*CUM-TM'             
                 LMSSSMXW='DB2 BLOB READ*SQL DELETE*MAX-TM'             
                 LMSSTCUW='DB2 BLOB READ*THREAD DELETE*CUM-TM'          
                 LMSSTMXW='DB2 BLOB READ*THREAD DELETE*MAX-TM'          
                 LMSUPD  ='DB2 BLOB*UPDATE*REQUESTS'                    
                 LMSUSCUW='DB2 BLOB UPDATE*SQL DELETE*CUM-TM'           
                 LMSUSMXW='DB2 BLOB UPDATE*SQL DELETE*MAX-TM'           
                 A BLOB object is used to access binary large objects   
                 (BLOBs), such as sound byte (wav) or image (gif) file, 
                 using the DB2Blob interface with Java 2.  With the BLOB
                 class, the LOB threshold property specifies the maximum
                 large object (LOB) size (in kilobytes) retrieved as    
                 part of a result set.  LOBs over that threshold are    
                 retrieved in pieces, requiring communications overhead 
                 with the server, so they can reduce the frequency of   
                 communications, but they also download more LOB data,  
                 that unwanted data that was never used.  Smaller LOBs  
                 may increase the frequency of communications with      
                 server, but may move much wasted data.                 
              -Added compatibly, i.e., at end of SMF 116 records:       
               Data Set MQMACCTQ:                                       
                 WTASVER ='WTAS*VERSION*NUMBER'                         
                 WTASDBPT='WTAS*DB2 BYTES*WRITTEN'                      
                 WTASDBGT='WTAS*DB2 BYTES*READ'                         
               Data Set MQMQUEUE:                                       
                 WQFLAGS '=FLAGS'                                       
                 WQGETDVA'=SUCCESSFUL DESTRUCTIVE GETS'                 
                 WQGETJCN'=NUMBER OF FORCE JOURNAL GETS'                
                 WQMAXQDP'=MAXIMUM ENCOUNTERED QUEUE DEPTH'             
                 WQPUT1JN'=FORCE MQPUT1 JOURNAL WRITES                  
                 WQPUT1PW'=MQPUT1 CALLS WHERE MSG PASSED'               
                 WQPUTJCN'=FORCE JOURNAL WRITES'                        
                 WQSETJCE'=ELAPSED WAIT*FOR SET'                        
                 WQSETJCN'=NUMBER OF SET'                               
   Thanks to Victoria Lepak, Aetna, USA.                                
Change 23.346  Documentation example; to add DB2 102 records to BUILDPDB
IMACKEEP       and to create the T102S022 T102S044 T102S063 datasets and
Feb 13, 2006   copy them into the //PDB library you would use:          
                %LET MACKEEP=%QUOTE(                                    
                  MACRO _CDEUSER                                        
                    _HDR102 _C102022 _C102044 _C102063 _C102105 _END102 
                  MACRO _VARUSER                                        
                    _V102022 _V102044 _V102063 _V102105                 
                 %LET EPDBOUT=%QUOTE(                                   
                   PROC COPY INDD=WORK OUTDD=PDB;SELECT T102: ;         
                 %INCLUDE SOURCLIB(VMAC102);                            
                 %INCLUDE SOURCLIB(BUILDPDB);                           
               We're not sure why both RUN; statements are required, but
               the PROC COPY doesn't execute without them.              
   Thanks to Ricci Hsial, China Trust, TAIWAN.                          
Change 23.345  Enhancement for the %READDB2 utility to read DB2 records.
READDB2        New WANTONLY option lets you create observations only in 
Feb 13, 2006   selected datasets, with sub-options to DROP or KEEP the  
               variables you want in that dataset, and logic to choose  
               which observations are output.  See documentation in the 
               comments, but for example.                               
                         DB2ACTB=YES/IF QBACGET GT 0);                  
               would create observations only in the DB2ACCTB dataset,  
               and only if the observation had non-zero GETS count.     
Change 23.344  The KEEP= list for dataset FICON73 needed SYSNAME added, 
ANALFIOE       as a result of the RMF changes in MXG 23.11.             
Feb 10, 2006                                                            
   Thanks to Brian Crow, British Telecom, ENGLAND.                      
Change 23.343  MXG 23.11. PDB.TYPE72GO NOT SORTED. Several BY statements
VMXGRMFI       had only BY SYSPLEX SYSNAME STARTIME; but the correct BY 
Feb 10, 2006   list is  BY SYSPLEX SYSTEM SYSNAME STARTIME;.  This error
               only occurred when SYSTEM and SYSNAME were not the same. 
   Thanks to Paul Naddeo, FISERV, USA.                                  
====== Changes thru 23.342 were in MXG 23.23 dated Feb  9, 2006=========
Change 23.342  Support for more Optional CICSTRAN "Candle" CICS fields  
IMACICD9        Field/Variable   Label                           IMAC   
VMAC110        The UTILEXCL program must be used to create a tailored   
Feb  8, 2006   IMACEXCL member, and the UTILEXCL output tells you which 
Feb 15, 2006   of the IMACICxx members also must be EDITed to create the
               optional variable(s) in the CICSTRAN dataset.            
   Thanks to John Shuck, SunTrust, USA.                                 
Change 23.341  CICS Statistics dataset CICSJR variable SJRPRXMX, the XMX
VMAC110        value, was read as an 8-byte binary value, but the field 
Feb  5, 2006   contains either blanks or '32M     ' in EBCDIC text, and 
               reading text fields as binary gets large values:         
                 input field read as binary       decimal    exponential
                  8-bytes of blanks                           4.6*10**18
                  'F3F2'x -32- in first bytes                17.5x10**18
                  4-bytes of hex FFx           4,294,967,294    4x10**9 
                  4-bytes of FFx               1,077,952,576    1x10**9 
               Now, new character variable SJRPRXCH is the text field,  
               which is parsed and decoded into the original numeric    
               variable SJRPRXMX, now formatted MGBYTES.                
   Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.  
====== Changes thru 23.340 were in MXG 23.11 dated Feb  2, 2006=========
Change 23.340  MXG support for Omegamon for DB2 Archive file records.   
VMACOMDB      -A short IFCID 44 record caused INPUT STATEMENT EXCEEDED; 
Feb  2, 2006   the record was only 350 bytes, and contained none of the 
               actual IFCID 44 data fields; MXG now INPUTs the first 350
               and tests to see if there is any more before INPUTing.   
              -IFCID 63 had a fixed INPUT of $5000 for the SQL text,    
               which caused INPUT STATEMENT EXCEEDED error when there   
               was a shorter text.  This statement was taken as-is from 
               Candle's SAS code in 2003, but apparently no IFCID 63    
               data had been tested before by an MXG user or Candle!    
               The MXG logic now INPUTs using VARYING informat          
   Thanks to Rosaline E. Howe, IBM Global Services, USA.                
Change 23.339 -Harmless DIVIDE BY ZERO because TOTSHARC was not tested  
VMAC7072       to be non-zero, but results are still fine; the variables
Feb  2, 2006   LPARSHAR and LPARSHAC will be missing when TOTHARC=0.    
              -SHIFTHRS references in DROPs removed as it doesn't exist.
              -Missing labels, and other RMFINTRV cosmetics cleaned     
              -TEST70SP did not include VMXGRMFI for NEWRMFI compare,   
               which caused many false positive comparison differences. 
   Thanks to Bruce Widlund, Merrill Consultants, USA.                   
   Thanks to Chris Weston, SAS ITRM Cary, USA.                          
====== Changes thru 23.338 were in MXG 23.11 dated Feb  2, 2006=========
Change 23.338  ML-38 of MXGTMNT, Tape Mount/etc Monitor program adds new
ASMTAPEE       event trace to the STK user exit in ASMHSCEX; we now have
ASMHSCEX       excellent cooperation with STK developers who are working
Feb  1, 2006   with "asmguy" to install ML-38 at STK so we can diagnose 
               why we miss so many mounts in that user exit.            
              -ASMTAPEE corrects MXGC009E Unrecoverable error messages; 
               the error was introduced back in ML-30 with the Volume   
               mount enhancement, but only one site has reported only   
               two instances, and it was with ML-37.                    
              -ML-38 also corrected 0C4 ABEND during processing of an   
               IEC6000I reply message in offline device allocation.     
               This note added Feb 21.                                  
   Thanks to Keith McWhorter, Georgia Technology Authority, USA.        
Change 23.337  Missing values for these PR/SM variables in PDB.RMFINTRV 
VMXG70PR       can occur, even with Jan 31 MXG 23.11, but only if there 
VMXGRMFI       were short intervals, as when an LPAR is started/stopped,
Feb  2, 2006   or as when a Policy Change is issued, which wrote two    
               short intervals (an 8:45 STARTIME with a 2 minute DURATM,
               an 8:47 STARTIME with 13 minute DURATM).                 
              -Previously, those variables were extracted by ASUM70PR   
               from PDB.ASUM70PR dataset and merged into PDB.RMFINTRV;  
               however the rewrite in Change 23.322 to ASUM70PR uses the
               SMF70GIE time interval (9:00 in the above example),      
               but the PDB.RMFINTRV is created for each of the STARTIME 
               values, so all of the old logic was moved from VMXG70PR  
               into the VMAC7072 and VMXGRMFI members.                  
              -So: ASUM70PR no longer updates PDB.RMFINTRV.             
              -This, too, was not a trivial revision.                   
               The biggest difficulty with this change was validation;  
               these short intervals created invalid data in the old    
               ASUM70PR/ASUMCEC datasets, which now have fewer obs than 
               the old MXG version, so this change was filled with false
               positive differences in the PROC COMPARE output!         
   Thanks to Diane Eppestine, AT&T Services, Inc, USA.                  
====== Changes thru 23.336 were in MXG 23.11 dated Jan 31, 2006=========
Change 23.336  Support for RMF with repeated SYSTEM names in a SYSPLEX. 
VMAC7072       Variable SYSNAME (SMF70SNM) was inserted in the BY list  
VMXG70PR       for all RMF-based datasets.  These RMF records all have  
VMXGRMFI       the same value in variable SYSTEM, but SYSNAME is unique 
ANALRMFR       to each system and must be used to separate them.  Test  
VMAC7072       data's SYSTEM was different from each of the two SYSNAME 
ADOC7xxx       values.  The new RMF sort order is changed to:           
Jan 29, 2006                                                            
ANALRMFR       This change in sort order should have NO impact if you   
VMAC70PR       have no repeated SYSTEM names in a SYSPLEX.  By putting  
VMXG70PR       SYSNAME to the right of SYSTEM, merges with old MXG data 
Jan 31, 2006   (that were sorted BY SYSPLEX SYSTEM STARTIME...) won't   
               be impacted, and your report code with logic testing for 
               FIRST.SYSTEM or LAST.SYSTEM won't be impacted.           
                 ONLY if you have multiple SYSTEM names in a SYSPLEX do 
                 you need to deal with this changes.  You MUST revise BY
                 statements in your report programs, inserting SYSNAME  
                 after SYSTEM, and using SYSNAME instead of SYSTEM in   
                 reports. Tests for FIRST.SYSTEM or LAST.SYSTEM must be 
                 changed to FIRST.SYSNAME or LAST.SYSNAME in your code. 
                 But without this change, these multiple SYSTEM names   
                 created incorrect output, without any error messages.  
               You might think having repeated SYSTEM names is dumb, but
               it is useful for Disaster Recovery LPARs, and can avoid  
               changing SYSTEM in JCL, etc., when moving a SYSTEM to a  
               SYSPLEX that already has a SYSTEM with that same name.   
               Some initial revisions were made to ANALRMFR, but they   
               are still being validated, and those reports will be     
               enhanced to support selection by SYSNAME or SYSTEM.      
               Full list of members changed by this change:             
                 ACHAP35  ADOC7072 ADOC70PR ADOC71   ADOC73   ADOC74    
                 ADOC75   ADOC76   ADOC77   ADOC78   ADOC89   ADOCPDB   
                 MONTHDSK QASAS    TEST70SP TRNDRMFN VMAC7072 VMAC71    
                 VMAC75   VMAC76   VMAC77   VMXG70PR VMXGRMFI WEEKBL3   
               These changes are in the MXG 23.11 dated Jan 31, 2006:   
               Jan 31 updates (hooray - no critical changes!!):         
               -ANALRMFR: revised, not DROP SYSNAME after SHAR74).      
               -VMAC7072: cosmetic removal of duplicate SYSNAME in KEEP=
                          in several places, eliminated NOTE on log.    
               -VMXG70PR: variable SMF70GIE now kept in RMFINTRV.       
               -If _STY70 is executed twice, you will get an ABEND and  
                  ERROR: DATASET WORK.TYPE70SP NOT FOUND                
                That error is intended, as it alerts you that your      
                program has caused that macro to be executed a second   
                time.  Please rerun with                                
                    OPTIONS SOURCE SOURCE2 MACROGEN MPRINT;             
                and send the full log to so we can      
                understand what you were doing that is incompatible with
                the new MXG redesign.                                   
               -VMAC73: variable SYSNAME was added to KEEP= list for the
                always-zero-obs TYPE73L,TYPE73P datasets; WEEKBLD etc   
                need those variables because they are in the BY list,   
                even though those datasets have not had observations for
                decades.  (And I can't safely stop creating them, as    
                that can only cause somebody's report program to fail.) 
   Thanks to Al Sherkow, I/S Management Strategies, Ltd., USA.          
   Thanks to Alain Delaroche, CA-Atlantica, FRANCE.                     
   Thanks to Chris Weston, SAS ITRM Cary, USA.                          
Change 23.335  Variables SMF70OIL and SMF70SYN are added to dataset     
VMAC7072       TYPE70; they have always been INPUT but were not kept.   
Jan 27, 2006     SMF70OIL='ORIGINAL*INTERVAL*LENGTH'                    
   Thanks to Al Sherkow, I/S Management Strategies, Ltd., USA.          
Change 23.334  MXG's unwise default to NOT create observations from type
IMACINTV       30 subtype 2/3 records is finally changed so that now,   
INSTALL        observations will always be output into TYPE30_V dataset,
Jan 26, 2006   if the SMF file contained SMF 30 subtype 2/3 records.    
              -Always use PDB.SMFINTRV, created by BUILDPDB and NOT the 
               "raw" TYPE30_V dataset, nor the PDB.SMFINTRV created by  
               TYPS30 program; those other "PDB.SMFINTRV/TYPE30_V" data 
               sets still have incomplete data because they still have  
               those multiple observations if MULTIDD='Y'. Only MXG's   
               BUILDPB logic combines the multiple TYPE30_V obs into    
               a single complete observation in PDB.SMFINTRV.           
              -The default was unwise because many new users have wasted
               their time and were frustrated when they got no output,  
               and wasted more time looking for what they had done wrong
                  OK, they had done something wrong: they had failed to 
                  read (and understand the impact of) every word in the 
                  INSTALL member, which is where I documented that zero 
                  obs would be created by default!                      
              -I originally chose to not write the interval record when 
               they first appeared in 1980, because I was concerned for 
               the additional disk space that might blind-side your fine
               running daily job, and because back then they weren't    
               sychronized with time of day, and were not of much use.  
              -Now, however, PDB.SMFINTRV is synchronized, so you can   
               create legitimate interval sums of all tasks to compare  
               with RMF, and potentially use in place of PDB.RMFINTRV   
               for workload measurement, and it so important that it is 
               normally created by everyone, and so I could have saved  
               many support calls if I'd changed the default a long time
               ago.  And, the cost of a little of DASD space is still a 
               lot cheaper than the cost of the beginner's time and     
               frustration, so it now is populated by default.          
Change 23.333  Cosmetic.  Missing Value calculations when OFFWQ was a   
VMAC116        missing value; now, OFFQW is tested first so those log   
Jan 26, 2006   messages are eliminated.                                 
Change 23.332  Variables HFLLIST and HFPGACT are accumulated in the raw 
VMACVMXA       z/VM MONWRITE data, but were not de-accumulated in MXG.  
Jan 25, 2006   Logic to use DIF() was added to properly decode and      
Feb  1, 2006   convert them to percentages.                             
               Feb 1: typo HFLPGACT corrected to HFPGACT                
   Thanks to Kris Ferrier, State of Washington DIS, USA.                
   Thanks to Bruce Widlund, Merrill Consultants, USA.                   
Change 23.331  Support for NDM/Connect-Direct subtypes TF, TL, and TW   
EXNDMTX        (TCQ Full, TCQ Below Threshold, or TCQ At Threshold)     
IMACNDM        create observations in the new NDMTX dataset.            
Jan 25, 2006                                                            
   Thanks to David Kaplan, Depository Trust, USA.                       
Change 23.330  Change 23.321/322 corrections:                           
TEST70SP       The "best tested ever" revisions in MXG 23.10 for RMF 70s
VMAC7072       were still not perfect.  The TYPE70/TYPE70PR/ASUM70PR and
VMXG70PR       ASUMCEC datasets have had no reported data-value errors, 
VMXGRMFI       but the RMFINTRV dataset had missing values for the PR/SM
Jan 24, 2006   variables, due to an incorrect sort order, and errors in 
Jan 26, 2006   building the WEEK/MONTH PDBs with new/old data uncovered 
Jan 27, 2006   the need for additional PROC SORTs to put the new data   
               back in the old and expected sort order.                 
               Chronological list of revisions to the revision:         
              -VMXG70PR.  Cosmetic.  Variables SYSPLEX SYSTEM were in   
               KEEP list for the new ASUMCELP but should not have been; 
               only impact was a possible WARNING message.              
              -TEST70SP fails in its comparison of OLDRMFI and NEWRMFI, 
               with VARIABLES SYNCTIME LPARNAME LCPUADDR not found.  The
               two BY statements for the two SORTs and one BY statement 
               for the DATA step in lines 88-96 of TEST70SP should be:  
                 BY SYSPLEX SYSTEM STARTIME;                            
                 BY SYSPLEX SYSTEM STARTIME;                            
                 BY SYSPLEX SYSTEM STARTIME;                            
              -VMXGRMFI fails if SPIN.SPINRMFI dataset had observations:
               because the new logic needed a sort of the old SPINRMFI  
               into the new sort order.                                 
              -VMXG70PR rebuilt PDB.RMFINTRV caused OUT OF SORT ORDER   
               error when (for example, WEEKBLD) old and new RMFINTRV   
               datasets were combined.  Adding a final sort to force the
               output to be BY SYSPLEX SYSTEM STARTIME corrected.       
              -VMXG70PR creation of PDB.TYPE70PR needed an additional   
               PROC SORT to put it in the original SORT order for the   
               WEEKLY merge.                                            
              -VMXG70PR rebuild PDB.RMFINTRV had missing values for the 
               "PLATCPUS" variable; re-sequencing the BY statements was 
               All four members have now been redated 27Jan2006, so you 
               will know you have all current changes.                  
   Thanks to Dr. Alexander Raeder, AtosOrigin, GERMANY.                 
   Thanks to Alain Delaroche, CA-Atlantica, FRANCE.                     
   Thanks to Diane Eppestine, AT&T Services, Inc, USA.                  
Change 23.329  Variable CPUCEPTM, CPU Time while Enqueue Promoted is    
VMAC30         accumulated in SMF 30 interval records, but Change 22.326
BUILDPDB       added logic to deaccumulate CPUCEPTM in PDB.SMFINTRV.    
BUILDPD3       Now, IBM has added field SMF30CEPI, the interval CPU time
Jan 23, 2006   and MXG creates new variable CPUCIPTM from that field in 
               all of the TYPE30 datasets, as well as in PDB.STEPS and  
   Thanks to Scott Barry, SBBWorks, Inc, USA.                           
====== Changes thru 23.328 were in MXG 23.10 dated Jan 23, 2006=========
Change 23.328  New macro variable &MXGEOF with null value is now called 
VMACSMF        when EODOFSMF or ENDOFLOG condition is true; you could   
VMXGINIT       use &MXGEOF to execute code, like storing the MNSMFTME   
Jan 22, 2006   value into a macro variable for subsequent use.  While   
Jan 26, 2006   this may look slightly kludgy, using an old-style macro  
               to hold the text (quotes, parens, semicolons etc.) that  
               is to be stored into a %LETed macro variable is often    
               much safer, cleaner, and easier to type-in, although the 
               use of %LET macvar= %QUOTE ( ... text ... ) ; may often  
               be all that is required, and, occasionally, you can even 
               use %LET macvar= ... text ... ;, but this always works to
               pass executable SAS code into a macro variable:          
                 MACRO _MXGEOF                                          
                 %LET MXGEOF= _MXGEOF ;                                 
                 %INCLUDE SOURCLIB( .. any SMF processing ) ;           
                 %PUT &MNSMFTME;                                        
               Jan 26: Two instances of ENDOFSMF in seldom-used JOURNAL 
               INFILEs were corrected to ENDOFLOG; only impact was an   
               UNINITIALIZED VARIABLE ENDOFLOG message on the log.      
   Thanks to Dr. Alexander Raeder, AtosOrigin, GERMANY.                 
Change 23.327  Enhancements to IBM-RMF-Report-like report examples.     
ANALRMFR       Revisions for Change 23.321 to insert _STY70 when PDB=SMF
Jan 22, 2006   and REPORT=CPU is requested.                             
   Thanks to Bruce Widlund, Merrill Consultants, USA.                   
Change 23.326  Macro variable PSUDB2 (used only by the new ASUMDB2) was 
VMXGINIT       not GLOBALed, even though it was %LET in VMXGINIT, caused
   Thanks to John Riera, InfoCrossing, USA.                             
Change 23.325  Syntax error 180 underscoring _C1020, only when TRACECLS 
READDB2        argument is used, was introduced by Change 23.287 and is 
Jan 18, 2006   corrected by relocating the test for TRACECLS argument to
Feb 17, 2005   after the include of VMAC102 code.                       
               Feb 17: MAC102S initialized, eliminated error if no 102s 
               were requested.                                          
   Thanks to Thomas Zuber5, Independence Blue Cross, USA.               
Change 23.324  On IBM's recommendation, these TPF Continuous Data values
VMACTPFC       are now converted to rates per second by division by the 
Jan 20, 2006   TPFCTDIF interval duration, which is already in seconds  
               and fractions.  Their labels were also revised as shown: 
                 Variable           Label                               
                 TPFCHMSG      HIGH*SPEED*MESSAGES*PER SEC              
                 TPFCLMSG      LOW*SPEED*MESSAGES*PER SEC               
                 TPFCROEN      ROUTED*ENTRIES*PER SEC                   
                 TPFCCREN      CRTD*ENTS*PER SEC                        
                 TPFCSIMS      SSCP*INPUT*MESSAGES*PER SEC              
                 TPFCCIMS      INSDB*IN*MESSAGES*PER SEC                
                 TPFCCMTS      COMMITS*PER SEC                          
                 TPFCCFRQ      CF*REQUESTS*PER SEC                      
   Thanks to Chris Weston, SAS Institute Cary, USA.                     
   Thanks to Martha Hays, SAS Institute Cary, USA.                      
   Thanks to Luis R. Vega-Zayas, IBM, USA.                              
Change 23.323  IBM APAR OA14365 corrects negative CPUUNITS in SMF 30s,  
VMAC30         which occurs only when IFAs are used, and only when the  
Jan 16, 2006   address space had little activity.  The negative value is
               created when CPUUNITS=CPUUNITS-IFAUNITS finds IFAUNITS   
               are greater than CPUUNITS.   CPUUNITS is SMF30CSU, and   
               IFAUNITS=CPUIFATM*CPUCOEFF*LOSU_SEC or in IBM names:     
                (SMF30_TIME_ON_IFA) * SMF30CPC * (16000000/SMF30SUS)    
               MXG now detects that the CPUUNITS are negative, and      
               prints warning messages on the SAS log that you need to  
               install this APAR.   Text revised March 6, 2006.         
   Thanks to Micchia Marco Antonio, UniCredit, ITALY.                   
Change 23.322  Support for 60 LPARs and corrections to ASUM70PR logic:  
VMAC7072       z/OS 1.7 now supports up to 60 LPARs; your MXG code will 
VMXG70PR       fail with messages (ARRAY OUT OF RANGE) if you have an   
Jan 19, 2006   LPARNUM greater than 32.  This change was extensive:     
                  Size of temporary ARRAY S70LPCP was increased from 32 
                  to 60.  No other changes were required for the TYPE70 
                  and TYPE70PR datasets.                                
              -VMXG70PR summarization.                                  
               1. New PDB.ASUMCELP dataset is created from PDB.ASUMCEC, 
                  with only one set of variable names, and it should be 
                  used for reporting instead of PDB.ASUMCEC.            
               2. Major mechanical rewrite to support 60 LPARS.         
                  Created 28 sets of 25 new variables for each of the   
                  new LPARs in the PDB.ASUM70PR and PDB.ASUMCEC datasets
                  (so they are even more unwieldy for report writing).  
                  While those datasets are valid, I strongly recommend  
                  that you instead use PDB.ASUM70LP and PDB.ASUMCELP    
                  datasets, instead of PDB.ASUM70PR and PDB.ASUMCEC;    
                  those "LP" datasets have only one set of variable     
                  names, for easy reporting, and you can select by      
                  LPARNAME.  The LPARNUM is no longer valid because an  
                  LPARNAME's LPARNUM will change if a new LPARNAME is   
                  created (LPARNUMs are set by alphabetical LPARNAME    
                    But in case you have reports based on those clumsy  
                    sets of variable names in ASUM70PR/ASUMCEC datasets,
                    the variable names for LPARs 33-34 have Y and Z as  
                    markers (1-9 and A-X were used for LPARs 0-32), and 
                    these new names are created for LPARs 35-60 in the  
                    (archaic, but valid) ASUM70PR and ASUMCEC datasets: 
                        LPARS 0-34   LPARS 35-60                        
                         LPnAAAAA     LQnAAAAA                          
                         LPCTnAAA     LQCTnAAA                          
                         PCTLnAAA     PCTQnAAA                          
               3. MXG variable CPUOVHTM has been wrong for some time;   
                  it contained both LPPUPDTM and LP0MGTTM, which are    
                  identical measurements of the "PHYSICAL" CPU time, and
                  only one of them should have been included; this error
                  caused both the CPUOVHTM and PCTOVHD values to be     
                  slightly too large.                                   
               4. LPARs with the same STARTIME but different DURATM's   
                  caused incorrect calculations in PCTCPUBY and/or in   
                  individual LPAR percentages, which could be over 100%,
                  in the ASUM70PR/ASUM70LP/ASUMCEC summary datasets.    
                  To properly summarize data across a CEC, neither the  
                  STARTIME nor SYNCTIME can be used to identify the     
                  minimum set of interval data from all systems on that 
                  CEC.  STARTIME has been documented as varying by one  
                  to several seconds for the same logical interval on   
                  the same CEC.  While SYNCTIME is constant in all RMF  
                  records for a "normal" interval, when a WLM Policy    
                  Change was made for six of nine LPARs in a CEC, there 
                  were six 1.5-minute-DURATM obs, three 15-minute-DURATM
                  obs, and then six 13.5-minute obs.  Those six 1.5     
                  minute short duration records, written as a result of 
                  the policy change, each had a unique SYNCTIME, so it  
                  could not be used to group the observations.  Only the
                  SMF70GIE value appears to be safe to use to get all of
                  the pieces together in CEC and 70PR/70LP summarization
                  and this redesign now uses SMF70GIE in place of the   
                  STARTIME for the grouping into summary intervals.     
                    (RMF Development later confirmed that they also use 
                    SMF70GIE for their report grouping. 26Apr2006.)     
               5. PDB.ASUMCEC will contain invalid data if your LPARs   
                  are on different time zones; you must use TIMEBILD to 
                  force all of the datetimes to a single time zone for  
                  ASUMCEC/ASUMCELP to be valid.                         
               6. For ASUMCEC/ASUMCELP, comparisons should be extremely 
                  close, but possibly not exact, for "normal" intervals.
                  For intervals were some LPARs were not present for the
                  full interval, or when a Policy Change was issued,    
                  i.e., when there are more than one STARTIME in an     
                  SMF70GIE interval, the new code should be correct,    
                  creating only one observation for each SMF70GIE,      
                  whereas the old code had an observation for each      
                  STARTIME, and the old data for those "broken"         
                  intervals was usually incorrect.                      
               7. The circumvention member EXCECTIM is now unnecessary  
               and is no longer referenced by MXG code.                 
   Thanks to Alain Delaroche, CA-Atlantica, FRANCE.                     
Change 23.321  Support for Split RMF 70 records: CRITICAL. SPLIT70.     
VMAC7072      -If you have enough LPARs (32) with SPARE engines, IBM now
XMAC7072       splits the RMF 70 data into multiple physical SMF records
TEST70SP       that are completely INCOMPATIBLE and REQUIRE this change.
               Change 22.344, Jan, 2005, added that logic in MXG 22.22. 
              -But until I had actual records, I couldn't revise MXG.   
              -The support required a complete restructure of the code  
               and logic that creates the TYPE70 and TYPE70PR datasets  
               from RMF or CMF type 70 SMF records.  None of the other  
               datasets created in the VMAC7072 "product" code were     
               touched by this change.  Work started at CMG, and across 
               the holidays in chunks of development and testing using  
               RMF and CMF data from 33 sites that were not split (so   
               the old and new logic could be compared; the old logic   
               created trashed data with split records so there is no   
               "old" for split).  Instead, the ANALRMFR RMF-like report 
               was compared with IBM RMF reports from the one split RMF 
               70 record that precipitated this major redesign!         
              -As long as you use BUILDPDB/3, RMFINTRV, TYPE7072 or the 
               TYPS7072 MXG code to read your RMF/CMF 70/72 records, the
               MXG redesign will execute transparently with MXG 23.10+: 
                - Dataset WORK.TYPE70 initially has zero observations   
                  after the SMF data is read; instead, new WORK.TYPE70SP
                  dataset will have observations, whether your records  
                  are split or not.                                     
                - The WORK.TYPE70PR dataset is created from SMF, but it 
                  is completely invalid if it was created from a SPLIT  
                  SMF 70 record.                                        
                - The redesign now must invoke the _STY70 Data Set Sort 
                  macro, which processes the WORK.TYPE70SP/TYPE70PR data
                  and in that process, creates these temporary datasets:
                    SORT70SP - Sort of TYPE70SP                         
                    PHYSICAL - LPARNAME='PHYSICAL' obs from TYPE70PR    
                    NUCPCXPU - Count CPs, ICFs, IFLs, IAFs from PHYSICAL
                    THISPART - PARTISHN=LPARNUM subset from PHYSICAL    
                    FROM70PR - Summary, create LPARn vars from THISPART 
                  Three (SORT70SP, FROM70PR, NUCPSCPU) are then merged  
                  to create the PDB.TYPE70 output dataset, which is also
                  enhanced by the addition of these new variables:      
                      LPARNAME SMF70BDA LCPUDEDn-x, LCPUWAIn-x          
                  Then _STY70 logic sorts TYPE70PR into SORT70PR so it  
                  can be MERGEd with NUCPSCPU to populate the PARTNCPU  
                  and NRICFCPU/NRIFLCPU/NRIFACPU variables from the     
                  PHYSICAL segments to create the PDB.TYPE70PR dataset. 
              -If you use YOUR OWN CODE that uses the _VAR7072 _CDE7072 
               macros, then you MUST also invoke the  _STY70 macro to   
               create the TYPE70 and TYPE70PR datasets; otherwise, you  
               will have zero observations in TYPE70 and bad data in the
               TYPE70PR dataset.  (If you already use the _S7072 product
               sort macro to sort all of the 7072 datasets, you're home 
               free, since the product sort macro always invokes the    
               data set sort macro for all datasets from that product.) 
                  The default output DD for _STY70 is "PDB" for both the
                  TYPE70 and TYPE70PR datasets.  If you want your old   
                  code to continue to write those two datasets to the   
                  "WORK" DDname, you would insert:                      
                      %LET PTY70=WORK;                                  
                      %LET PTY70PR=WORK;                                
                  before your DATA step.                                
              -Note that _STY70PR sort macro is now null and must be    
               replaced with _STY70.                                    
              -The MXG TYPE7072 member now must invoke the _STY70 macro,
               but with %LETs inserted in TYPE7072 so that the rebuilt  
               TYPE70/TYPE70PR datasets are still written to //WORK.    
                 (So an existing %INCLUDE SOURCLIB(TYPE7072) will still 
                  create those datasets in the //WORK library.)         
               But if you use %INCLUDE SOURLIB(TYPE7072), you can not   
               add an invocation of _STY70, because of that under the   
               covers execution.  And you'll get an error if you do:    
              -You can get ERROR: FILE WORK.TYPE70SP DOES NOT EXIST:    
               a. if you do attempt to invoke _STY70 a second time,     
               b. if you have an old VMAC7072 in your "USERID" tailoring
                  source libraries                                      
               c. if your predecessor had (incorrectly) tailored MXG and
                  had redefined MACRO _VAR7072 or MACRO _CDE7072 macros 
                  (usually in IMACKEEP member).  It has ALWAYS been     
                  incorrect installation tailoring to redefine those    
                  critical MACRO _VARxxxx or MACRO _CDExxxx macros in   
                  your USERID MXG Tailoring Library, precisely because  
                  they block MXG from it correct definitions.           
              -ITRM/ITSV section: revised Jan 31, 2006:                 
               Most ITRM sites do NOT have to do anything at all for the
               new 70's architecture, as long as you create XRMFINT (the
               RMFINTRV MXG dataset) with your %CMPROCES ITRM execution.
                  ONLY if you process RMF 70 records, but do NOT create 
                  the RMFINTRV dataset, you will, at present, need to   
                  insert the text    _STY70    in your EXPDBOUT member. 
                  This original change text said all ITRM sites needed  
                  to add that statement, but that text was wrong, and it
                  is the rare site that would process 70s without also  
                  creating the XRMFINT/RMFINTRV dataset.  A later change
                  to ITRM can be expected that will make the invocation 
                  of _STY70 internal to ITRM, and that statement will   
                  need to be removed at that time.                      
              -This iteration has no protection for incomplete sets of  
               split records: first record filled today's SMF file, next
               record is in tomorrow's SMF file.  That may be done in a 
               later iteration, using the //SPIN DD to hold data.       
              -VSETZERO member has been removed from the VMAC70s logic. 
                  It was added in MXG 23.03 by Change 23.070 in an      
                  attempt to deal with inconsistent STARTIME values     
                  across LPARs, by setting STARTIME to the exact minute 
                  when seconds were 58,59, or 01-10.                    
               It is removed because the unchanged STARTIME value must  
               be used for the merge of the split records, but also     
               because VMXG70PR is revised in Change 23.323 to use the  
               SMF70GIE variable for the merge, and the minimum value of
               STARTIME is used only for reporting those summary data.  
              -In both rewrites, I discovered a few cases in which the  
               old MXG code was inconsistent or even wrong:             
                - LPARn variables for unused LCPUADDRs were occasionally
                  zeros when they should have been a missing value; now 
                  they are always missing.  Had no impact on your data, 
                  but they cause false positives in PROC COMPARE in the 
                  TEST70SP program because they are different.          
                - Handling of engines with CAI='00'x (not on at end of  
                  interval) and CAI='02'x or CAI='03'x (error flag on)  
                  was inconsistent in the old code.  Since SMF70ONT now 
                  should be populated, it is used to determine if each  
                  engine's dispatch/wait times are included in totals,  
                  impacting the values in those individual "n" engine   
                  variables and the totals, in particular variables     
                     MVSWAITn,CPUWAITn,CPUPDTMn,CPUEFFMn and            
                  If these values differ in your compare, look first at 
                  the CAIn variables to see if they account for the     
                  compare differences, knowing the new is correct now.  
                - Because values are now summed and then divided that   
                  were previously divided and then summed, some small   
                  differences (less than .001 absolute value) were found
                  in some time and percentage variables, but they only  
                  impacted the PROC COMPARE, and not the real world.    
                - Duplicate SMF records were not always deleted, which  
                  caused PCTCPUBY in ASUM70PR and ASUMCEC over 100%.    
                  The sort order of TYPE70PR to remove duplicates is:   
                - Variables NRICFCPU and NRIFAS in ASUM70PR/ASUMCEC were
                  sometimes incorrect in the old code.                  
             - The SMF6CNF bit macro no longer exists; not needed with  
               the revised handling of the CAI '02'x and '03'x values.  
             - APAR OA14024 just reported that the IBM RMF Report Writer
               fails with an ABEND 0C4 when it tried to read a split SMF
               70 record from a system with 60 LPARs, because the total 
               length of all records was then over 64K bytes, a value   
               that killed the report writer, due use of a signed field.
               And this happened after an RMF Developer told me that it 
               was very simple to reassemble their split data!          
             - This SMF 70 record really did not need to be split by    
               IBM now! The record contained 368 LCPUADDR segments from 
               the 32 LPARs, but there were actually only 68 LCPUADDR in
               use; all of the other LCPUADDR segments were for each of 
               the SPARE engines on the z9, so if IBM had chosen to only
               write the non-SPARE engine's, this rewrite would not have
               occurred now.  But, the rewrite is now done so the future
               is safe.                                                 
             - New TEST70SP member creates TYPE70/TYPE70PR datasets with
               the old MXG 23.09 code (in XMAC7072 member) and with the 
               new VMAC7072 code, and uses PROC COMPARE to identify any 
               differences between new and old logic.  TEST70SP can ONLY
               be used with NON-SPLIT RMF 70s.                          
                 (The old code didn't support split records, which cause
                  multiple TYPE70 observations with same STARTIME and   
                  with incorrect data values.)                          
               It also created new and old ASUM70PR and ASUMCEC data and
               compares them, but if your data has multiple STARTIMEs in
               an SMF70GIE interval, the old and new will not compare,  
               as the old was split into multiple observations, but the 
               new logic correctly summarizes those multiples, so there 
               will be fewer observations in the new compared with the  
               old, which PROC COMPARE reports as lots of differences,  
               but there is no error.                                   
   Thanks to Matt Clarke, Charles Schwab & Co., Inc, USA.               
   Thanks to Neil Ervin, Charles Schwab & Co., Inc, USA.                
Change 23.320 -Truncated SMF 102 record caused INPUT STATEMENT EXCEEDED 
VMAC102        RECORD LENGTH error is now detected and reported on the  
Dec 23, 2005   SAS log as a truncated record, rather than an ABEND.     
              -IFCID 83 record from DB2 V7.1 caused similar ABEND, but  
               this was because the MXG code for that IFCID was only    
               for DB2 V8.1, as only that version's test data had been  
               received; now, both V7 and V8 IFCID 83 are supported.    
   Thanks to Tony Pratt, Tampa Electric, USA.                           
Change 23.319  New ASUMDB2 program summarizes DB2ACCT events to create  
ASUMDB2        interval (hourly default) transaction counts, resources, 
VMXGINIT       and response time buckets, using the same macro variables
Dec 18, 2005   to define those buckets as are used in ASUMCICS/ASUMCICX 
               that creates PDB.CICS.                                   
   Thanks to John Rivera, (i)Structure, USA.                            
Change 23.318  Incorrect syntax with character text for NRPERIODS caused
VMXGRMFI       strange and unobvious error messages; now, if NRPERIODS  
Dec 18, 2005   is not a number, the execution will ABEND so you can fix 
               your syntax.                                             
   Thanks to Robbie A. McCoy, Salt River Project, USA.                  
Change 23.317 -Syntax error in TRNDUOW due to a semi-colon after a ELSE.
TRNDCEC       -Variable NRPRCS NOT FOUND in TRNDCEC because it was      
TRNDUOW        removed some time ago.                                   
Dec 18, 2005  -TRND members had not been fully tested in QA, now are.   
   Thanks to Freddie Arie, Merrill Consultants, USA.                    
Change 23.316  Changes to VGETENG required corresponding changes to this
UTILCONT       utility that provides the size of contents of your SAS   
Dec 15, 2005   data libraries.                                          
   Thanks to Paul Naddeo, FISERV, USA.                                  
Change 23.315  Dataset ICFD70PR NOT SORTED error due to short interval  
ASUM70PR       RMF records required yet another sort to force proper    
Dec 15, 2005   sequence.                                                
   Thanks to Jimmy J. Hu, Ameren, USA.                                  
Change 23.314  Documentation only.  APAR OA06476 documents that TYPE74CA
VMAC74         fields R745INCR, R745BYTR, R745BYTW, R745RTIR, R745RTIW  
Dec 13, 2005   have never been populated and are now reserved fields    
               that will always be zeros.  The data was planned for the 
               2105 800 models, but the data was not available on those 
               boxes.  The data has become available with the 2105 box, 
               but that interface and APAR OA06476 adds new R7451INC,   
               and R7451CT1-4 to RAID Rank/Extent Pool Section.         
Change 23.313 -Variables R791TIFC/R792TIFC were incorrectly normalized  
VMAC79         by R791NFFI/R792NFFI, but they are already in CP seconds 
Dec 12, 2005   so they are no longer normalized.                        
              -Variables R791TCP and R729TCP are now deaccumulated, and 
               the label for R792TCP is now correct.                    
              -Text in Change 22.152 now has correct variable names and 
               labels for TYPE791 and TYPE792 IFA-related variables.    
              -Change 23.132 updated to list the TYPE79 changes made.   
   Thanks to Rick Southby, Insurance Australia Group (IAG), AUSTRALIA.  
Change 23.312  New CICSBAD dataset contains "bad" CICSTRAN observations,
EXCICBAD       that were previously output in CICSTRAN dataset, but are 
IMACCICS       known to be defective, and so are now output in CICSBAD. 
VMAC110        There are two "bad" conditions supported in this change: 
VMXGINIT      -When a user types in a TRANNAME that is not a valid name,
Dec  9, 2005   there still is a type 110 segment created with missing   
Feb  9, 2006   fields, and TRANNAME contains whatever was typed.  Those 
               records are identified by PROGRAM='########', and are    
               now output into dataset CICSBAD rather than CICSTRAN.    
               While these records are usually just typos, hackers have 
               been known to keep typing names until they find one that 
               works, so these records might be useful in CICS security 
               issues.  Each record has between 3 and 4 milliseconds of 
               CPU time in TASCPUTM, which I presume is the fixed cost  
               to create a CICSTRAN observation (speculation - there may
               be uncaptured CPU) on a SU_SEC=10000 speed engine.       
              -When a CICS task is executing on an OPEN TCB, and is then
               purged, APAR PQ86971 documents that all of the clocks are
               invalid when this happens, and that APAR adds a new bit  
               to the TRANFLAG field to identify these tasks.  Since the
               clock values are all wrong, these transactions are now   
               also output in CICSBAD instead of CICSTRAN.              
              -So, CICSBAD will now contain all PROGRAM='########' obs, 
               and all transactions purged on an open TCB, and CICSTRAN 
               will no longer have any of those invalid transactions.   
              -The format for CPU-time fields were changed to TIME13.3, 
               to display the millisecond level; TIME16.6 would show the
               full resolution, but would cause reports based on the    
               current length to be shifted, so it was not chosen.      
Change 23.311  Support for Beta 91 Version, which INCOMPATIBLY  
VMACBE91       changed the header of their record, and all subtypes.    
Dec  8, 2005   This iteration supports BETA91B and BETA91C datasets,    
Dec 12, 2005   which were validated with '44'x and '50'x subtypes.  Two 
               other datasets have not been tested with real records.   
   Thanks to Herve Brusseaus, Fortis Bank, LUXEMBOURG.                  
Change 23.310  Variable ESMFNTRN was always missing because it existed  
VMACMPLX       only in a LABEL statement, and was misspelled.  The count
Dec  8, 2005   of transactions is in variable ESMFTRAN.                 
   Thanks to Sudie Wulfert-Schickedanz, Anheuser-Busch., USA.           
====== Changes thru 23.309 were in MXG 23.09 dated Dec  7, 2005=========
Change 23.309  INVALID ARGUMENT TO FUNCTION SQRT error when an invalid  
VMXGUOW        transaction (PROGRAM='########') was processed.  In the  
TRNDUOW        VMXGUOW member, CICSTRAN obs with that PROGRAM name are  
Dec  7, 2005   now deleted prior to summary, and TRNDUOW is protected.  
   Thanks to Bruce Widlund, Merrill Consultants, USA.                   
Change 23.308  MXG 23.08-23.09.  Note VARIABLE JOBINFO1 IS UNINITIALIZED
VMAC26J2       because of an incomplete ending-comment; fortunately, the
Dec  5, 2005   only impact was that these four variables: OPTJOURN,     
               OPTOUTPT, TYPRUN and RESTARTD will all be blank.         
   Thanks to Jon Whitcomb, Great Lakes Educational Loan Service, USA.   
Change 23.307  INPUT STATEMENT EXCEEDED after "DTP=24 SEGMENT.." message
VMAC80A        because the additional segments were not processed after 
Dec  5, 2005   that MXG message.                                        
Dec  9, 2005  -Dec 9.  Same error corrected for DTP=25 SEGMENT.         
   Thanks to Coen Wessels, Unicible, SWITZERLAND.                       
   Thanks to Mark Nouwen, Dexia, BELGIUM.                               
Change 23.306  MXG variables PARTNCPU and NRICFCPU/NRIFACPU/NRIFLCPUs   
VMAC7072       still wrong on z9s, because IBM's SMF70BNP field is in   
VMXG70PR       error on z9s.  MXG calculated PARTNCPU from SMF70BNP,    
Dec  5, 2005   but in earlier platforms, SMF70BNP included the count of 
Dec  7, 2005   ICFs, which MXG subtracted.  So when the z9 added new    
               'IFA' and 'IFL' values to SMF70CIN, I assumed those also 
               needed to be subtracted from SMF70BNP.  Now, however,    
               IBM confirmed SMF70BNP is in error and will be changed   
               with the next z9 microcode:                              
                 the expected MCL number containing this change is      
                 J99671.014 in driver d63j  (Jan, 2006)                 
               and recommended that instead to count of engines in the  
               PHYSICAL segments, rather than use SMF70BNP, so this     
               change does set PARTNCPU from the count of CPs in the    
               PHYSICAL partition records.                              
                Dec 7:  The Dec 5 change accidentally fixed the z9 data 
                        and un-fixed other processors, because I had    
                        spelled PARTNCPU as PLATCPUS in both the code   
                        and text of the original change.  PARTNCPU is   
                        the name in the type 70 datasets; PLATCPUS is   
                        the name only in the RMFINTRV dataset.          
              -In VMXG70PR, NRICFCPU and NRIFACPU could also be wrong;  
               a SUM was used where a MAX was required; because my test 
               data has only one of each, the SUM and MAX were the same 
               and the logic error was not detected.                    
              -Variable NRPRCS is no longer kept in PDB.ASUM70PR and    
               PDB.ASUMCEC datasets; it has no meaning for those data.  
   Thanks to Dave Crandall, Farmers Insurance, USA.                     
Change 23.305  Optional OPID variable was never INPUTed!                
Dec  2, 2005                                                            
   Thanks to Lucy Fukushima, California Health and Welfare, USA         
Change 23.304  ANALCNCR could fail when an observation with missing     
ANALCNCR       values for the number of concurrent events was being     
Dec  2, 2005   generated, which caused the calculation of the Y-axis    
               to fail.  The record with missing values is dropped and  
               axix calculations were protected for the possibility of  
               missing values.                                          
   Thanks to Bruce Hewson, Citibank N.A., SINGAPORE.                    
====== Changes thru 23.303 were in MXG 23.10 dated Dec  1, 2005=========
Change 23.303  First MXG 23.09 only, and only under SAS Version 8: ERROR
Dec  2, 2005   the PROC SQL will work under either V8 or V9.            
                 The LIBNAMES dataset in the DICTIONARY was new in V9,  
                 and we failed to test under V8 with the first 23.09.   
               Dec 2:  We now test version, and use LIBNAMES with V9 or 
               use MEMBERS with V8.  The advantage of the LIBNAMES is   
               that we can get the engine as long as the LIBNAME has    
               been referenced (either with a LIBNAME statement, or     
               implicitly by referencing a dataset), whereas the MEMBERS
               only exists if a dataset in the library has been opened. 
   Thanks to Robbie A. McCoy, Salt River Project, USA.                  
Change 23.302 -The RACF Unload Utility output have always had a 4-digit 
EXRAC2A0       numeric "RECNR", in EBCDIC, but now a new '02A0' value   
IMACRACF       is found, which caused INVALID DATA FOR RECNR error.     
VMACRACF       Since numeric RECNR was a kept variable in all datasets, 
VMXGINIT       new character variable RECTYPE is now INPUT and used in  
Nov 30, 2005   all tests, were also changed to character syntax.        
              -The new RACF02A0 dataset, for USER OVM DATA, is now      
               created by this change.                                  
              -I am now aware of additional new RECTYPE values and they 
               are listed in the comments in VMACRACF as "NOT DECODED", 
               as I need test records to support them.                  
   Thanks to Bruce Hewson, Citigroup N.A., SINGAPORE.                   
Change 23.301  The MXSMFTME and MNSMFTME variables now exclude SMF 2 & 3
VMACSMF        header/trailer records (created in the output SMF file   
Nov 30, 2005   when IFASMFDP dumps, or later copies, an SMF file).  The 
               ID 2 and 3s record when the dump/copy program ran, and   
               do not describe the range of timestamps of the SMF data. 
   Thanks to Erik Janssen, ING Netherlands, THE NETHERLANDS.            
====== Changes thru 23.300 were in MXG 23.09 dated Nov 30, 2005=========
Change 23.300 -ML-37 of MXGTMNT monitor now captures SYSLOG messages in 
ASMTAPEE       a new SMF subtype 8 for these mount-related events:      
ASUMTAPE         IEC501A IEC501E IEC705I IEF233A IEF502E IEF234E IOS070E
EXTMNSTS         IECTMS6 IECTMS9 IOS690I IEF235D                        
EXTMNSYM       and a new subtype 9 record can be written for any other  
EXTMNSYS       SYSLOG messages you want captured in your SMF data!      
IMACTMNT      -Two new MXG datasets are created from MXGTMNT's subtypes:
VMACTMNT         dddddd  dataset  description                           
VMXGINIT         TMNSYT  TYPESYMT Mount-specific SYSLOG, subtype 8      
Nov 28, 2005     TMNSYL  TYPESYSL User-selected SYSLOG messages, st 9.  
Jun 15, 2006  -Added Jun 15, 2006:                                      
               This redesign REQUIRES you to use ASMTAPEE at ML-38 or   
               later, as it depends on the SYSLOG Mount-specific records
               and there will be zero observations in PDB.ASUMTAPE if   
               there are zero obs in TYPESYMT syslog mount dataset.     
              -For the IBM IEF_VOLUMEMNT exit, we seem to capture every 
               mount that is issued with an IEF233A mount message, and  
               we appear to capture no mount that is issued with any of 
               the other messages, in particular, the IEC501A message   
               that is issued for second-volume mounts of a multi-volume
               tape dataset.  IBM Support confirmed that is correct for 
               their exit; it is taken only for Allocation's mounts, and
               those OPEN/CLOSE/EOV mounts (the IEC501x messages) do not
               go thru that exit.  I hope to propagate the jobstuff from
               the first mount into the second mount for these multi-vol
               mounts, but there are also IEC501A mounts that are the   
               first and only mount for a job, so I need more test data 
               from the ML-37 monitor with SYSLOG data to fully resolve 
               what is and is not captured in the IBM exit, and how the 
               logic in ASUMTAPE can be enhanced further.               
              -Revised Jun 15, 2006:                                    
               For the STK UX01 exit, STK Support has now installed our 
               ASMHSCEX and have captured 100% of all HSC-controlled    
               tape mounts, both to virtual and to real tape devices, in
               several tests in their labs by Sun Technicians.          
              -For IBM, SYSLOG data goes a very long way to resolve.    
               True, you do NOT know the actual duration of the mount   
               (TAPMNTTM will be missing if MXGTMNT missed the mount)   
               and the READTIME variable will be missing, so you cannot 
               directly MERGE the ASUMTAPE back to the PDB.JOBS for any 
               simple match for billing, but almost all of the jobstuff 
               that we got from the MXGTMNT data is now picked up from  
               the SYSLOG data, so the PDB.ASUMTAPE with these changes  
               is of far better quality than it every as been before.   
              -But expect revisions to the ASUMTAPE program after more  
               test data has been received; early adapters of this new  
               code are requested to send their SMF records (the MXGTMNT
               user-SMF record, AND the SMF type 21 dismounts) so that  
               the new data can be better understood; member SENDATA in 
               MXG 23.09 has the instruction (and new ip address) to    
               send SMF data to our ftp site.                           
              -The Tape Allocation subtypes that create TYPETALO data   
               is still sampled, so job-related data can be missing in  
               that dataset; I hope to be able to merge the job-stuff   
               from this new PDB.ASUMTAPE dataset into those missing    
               variables in PDB.ASUMTALO, in a later enhancement.       
              -Additional documentation notes:                          
               This enhancement makes the MXGTMNT program in ASMTAPEE,  
               the "MXG Tape Mount, Tape Allocation, Tape Swap, Tape    
               Allocation Recovery, and SYSLOG message monitor".  The   
               messages captured in the "MXG-owned" subtype eight are   
               these that needed for tape mount event events:           
                IEF233A - First Volume Mount, Allocation Issued         
                IEF501E - 2nd+ Volume for OPEN/CLOSE/EOV "Look Ahead"   
                       ==>  3 seconds --                                
                IOS070E - MOUNT PENDING sss                             
                IECTMS9 - DEVNR,VOLSER, DSNAME17 at OPEN                
                       ==>  actual time to mount      ==> TAPMNTTM      
                IEC705I - TAPE ON DEVNR,VOLSER                          
                       ==>  duration tape was mounted ==> TAPMTDTM      
                TMS014  - Copy of IEC502E or IEF234E message            
                IEF502E - Intermediate Volume KEEP                      
                IEC234E - Last Volume KEEP                              
               and these additional messages are captured in subtype 8  
               to identify causes of known tape mount delays:           
                IEF690I - FOLLOWING VOLUMES UNAVAILABLE                 
                IEF235D - JJJ STEP WAITING FOR VOLUMES                  
                IEC205I - VOLUME LIST                                   
               New dataset TYPESYMT (SYSLOG MounTs) decodes those SYSLOG
               records, which include the JOB, JESNR, SYSTEM, ASID, and 
               the EVENTIME (same .01 second resolution as SMFTIME).d   
               The below left-to-right examples show some examples of   
               the sequence of SYSLOG mount-related event records:      
                233A                       234E                         
                233A TMS6 TMS9 705I TMS014 234E                         
                233A TMS6 TMS9 705I TMS014 502E      for first vol      
                    501A TMS6 TMS9 705I TMS014 502E  for intermediates  
                    501A TMS6 TMS9 705I TMS014 234E  for final volume   
                    501E TMS6 TMS9 705I TMS014 234E  for final volume   
                233A 070E           TMS014 502E                         
                690D 235D           705I       234E                     
               New dataset TYPESYSL (SYSLOG Messages) can be populated  
               with any SYSLOG messages you chose to ask MXGTMNT to     
               capture in subtype 9.  At present, you must EDIT the name
               table in the ASMTAPEE and re-assemble, but ASMTAPEE will 
               be revised so you can use the console MODIFY command to  
               turn on or turn off capture of any SYSLOG message.       
               I plan to create an ANALSYSL program to decode those     
               SYSLOG messages that you decide to capture, so let me    
               know what messages you find important and useful.        
Change 23.299  Support for SPLIT RMF 70 records, created on a z9 with   
VMAC7072       25 LPARS.  To be investigated.  Check text of this change
Nov 28, 2005   in the final MXG 23.09 that will be dated Nov 30, 2005.  
               No change made yet, await test data with split records.  
Change 23.298  MXG 23.08 would fail if you did not have a //INSTREAM DD 
VGETENG        in your JCL Procedure (there is one in MXGSASVn example),
Nov 28, 2005   because VGETENG was changed to require the use of that DD
               in the "mainstream" RMFINTRV processing, or would fail if
               you used UTILBLDP and then %INCLUDE INSTREAM; to execute 
               the program built by UTILBLDP, with FILE INSTREAM IN USE 
               error.  Both errors were introduced when revisions added 
               the use of //INSTREAM in VGETENG; both are corrected by  
               backing out the use of //INSTREAM in VGETENG.            
                 That addition was yet another attempt to improve the   
                 accuracy of VGETENG's logic to "GET" the ENGINE of a   
                 LIBREF.  Originally, this was to avoid a second tape   
                 mount, but knowing the library is on tape when we are  
                 going to read with a VIEW, we can avoid a second read  
                 of the full (possibly multi-volume) tape dataset.      
                 However, is just not possible to know the media of an  
                 un-referenced DD, so we must revert to the original    
                 logic that can only identify a tape that has been      
                 previously referenced in this step.                    
                    So you could force that reference with a LIBNAME    
                    statement, or a  DATA _NULL_; SET DD.XX; STOP;      
                    if you see there are multiple mounts on syslog.     
                    In the case of VMXGSUM, which does not use the      
                    VGETENG logic, we are still investigating if we     
                    can detect and eliminate the second read with a     
                    VIEW when the input is  on tape.                    
   Thanks to Scott Barry, SBBWorks, Inc, USA.                           
Change 23.297  Support for TCP field ACCEPT in dataset AIXTCP.          
Nov 23, 2005                                                            
   Thanks to Long N. Nguyen, Department of Home Security, USA.          
Change 23.296  Macro _STY30U6 deaccumulates TYPE30_6 into PDB.TYPE30_6, 
VMAC30         but it did not protect for wrapping of the four-byte     
Nov 22, 2005   RESIDTM and ACTIVETM fields, which wrap at 1221 hours.   
               Additionally, ACTIVETM was not deaccumulated, but now is.
               The created variable UPTM contains the original ACTIVETM 
               before deaccumulation, but UPTM will reset to zero every 
               51 days or so.                                           
              -Noted and corrected: INTETIME and SYNCTIME in TYPE30_6   
               were on GMT rather than local time if GMTOFF30 non-zero. 
   Thanks to Jean-Denis Lacourse, CGI, CANADA.                          
   Thanks to Robert Petel, CGI, CANADA.                                 
Change 23.295  Dataset DB2ACCTG didn't contain these nine QBGA variables
Nov 22, 2005     QBGAS3   QBGAU1   QBGAWS                               
               although their sums were kept in DB2ACCT.  All variables 
               are now kept in DB2ACCTG.                                
   Thanks to Steve Olmstead, Thomson BETA Systems, USA.                 
Change 23.294  TMVSCI dataset variable CIJN was off by four bytes, which
VMACTMVS       caused wrong values in it and the subsequent CI variables
Nov 22, 2005   that track storage.  In addition, the percentage field's 
Nov  5, 2005   values were all off by a factor of 100, as I missed the  
               precision of that field in the TMVS documentation.       
   Thanks to Richard Jay Schwartz, State Street Bank, USA.              
Change 23.293  The MXG Trending default INTERVAL=WEEK, is replaced with 
TRND72GO       INTERVAL=&INTTRND, with macro variable INTTRND defaulting
VMXGINIT       to WEEK, i.e., the INTERVAL= value is externalized so it 
Nov 22, 2005   can be changed with %LET INTTRND= whatever ; before your 
               %INCLUDE SOURCLIB(TRNDxxxx); statement (where "whatever" 
               is one of the valid values defined in VMXGDUR).          
               Only the TRNDxxxx members that had INTERVAL=WEEK, were   
               changed; a few don't use the INTERVAL= argument (instead 
               using a date/time variable in their SUMBY= argument) and 
               a few had INTERVAL=DATE, left unchanged.  TRNDCICS/CICX  
               have INTERVAL=&TRCIINTV, but the %LET TRCIINTV=WEEK; is  
               inside those two members, so it couldn't be externally   
               changed.   Now, INTERVAL=&INTTRND, is specified and the  
               useless reference to TRCIINTV is removed.                
   Thanks to Stan Dylnicki, Royal Bank of Canada, CANADA.               
Change 23.292  Support for APAR OA11675, which increases EXCPTOTL's old 
VMAC30         maximum count of 2 gig to a new maximum of 4 gig.  The   
VMAC32         field counts the step's lifetime total EXCPs (blocks or  
VMAC33         SSCHs, depending on the Access Method used); the original
Nov 14, 2005   APAR text and title erroneously said "2 gigabytes".  If  
               the count is now over 4 gig, (4,294,967,295), the APAR   
               stores 'FFFFFFFF'x and turns on a new bit to indicate the
               count exceeded the maximum.  MXG creates EXCPERR='Y' if  
               that bit is on, and sets EXCPTOTL to a missing value.    
               The variable name is EXCPTOTL in SMF 30s and PDB datasets
               and in SMF 33s, but was named EXCPS in TYPE32.           
Change 23.291  Support for NDM subtypes:                                
EXNDMHW          Subtype  Description                                   
EXNDMNM            HW     HIGH WATER MARK STAT RECORD - supported       
IMACNDM            NM     Unknown - Header only until I get the DSECT   
Nov 13, 2005                                                            
   Thanks to David Kaplan, Depository Trust, USA.                       
Change 23.290  Deaccumulation of the VXSYTEPM dataset was still wrong;  
VMACVMXA       four byte wrap was not protected, but IBM has created a  
Nov 12, 2005   new "architecture" that needed additional logic. For each
               device's first instance, CALINIT='Y' and the contents of 
               that "initial" record is all zeros, so it is deleted.    
               However, the second record must also be deleted, as it   
               does not start from zero, but has some large non-zero    
               values that must be used in the DIF() but the observation
               after the CALINIT='Y' instance must then be deleted also.
               And since records with CALINIT='Y' are deleted, there is 
               no reason to keep that variable in VXSYTEMP dataset.     
   Thanks to Melanie Higching, British Telecom, ENGLAND.                
Change 23.289  For RMF intervals with DURATM less than one minute, MXG's
VMXG70PR       summarization into PDB.ASUM70PR didn't store the second  
Nov 10, 2005   interval's DURATM in SYSDUR, which caused values over 100
               percent in PCTCPUBY and the LPCTnBY value for that LPAR. 
               Change 23.070 documented these very short RMF intervals  
               (created when a WLM Policy Change was made), and dataset 
               PDB.ASUMCEC was corrected by that change, but 23.205 was 
               and additional revision, and it reinstated EXCECTIM exit 
               to force the STARTIME for all three datasets created by  
               the ASUM70PR/VMXG70PR program to the nearest minute, both
               for cross-CEC timing issues, and to consolidate these RMF
               short intervals. But the logic for PDB.ASUM70PR/ASUM70LP 
               to set SYSDUR was based on IF FIRST.LPARNUM, but that    
               didn't "see" the second instance with same STARTIME.     
               By adding DURATM as the last BY variable in the BY in    
               INCODE=, and by setting SYSDUR from IF FIRST.DURATM, the 
               summary DURATM is correct for those two datasets, which  
               also corrects the percentages based on DURATM.           
              -The WLM Policy Change was installed at 10:32:06, and the 
               STARTIME and DURATM of the adjacent RMF records were:    
                   STARTIME   DURATM                                    
                   hh:mm:ss   hh:mm:ss                                  
                   10:15:00   00:15:00                                  
                   10:30:00   00:00:20                                  
                   10:30:20   00:01:46                                  
                   10:32:07   00:12:52                                  
   Thanks to Jerry Urbaniak, Acxiom CDC Inc, USA.                       
Change 23.288  BMC CMF Product SMF 70 records for z9 have SMF70BND=0,   
VMAC7072       MXG variable LPARCPUX, in the LPARNAME='PHYSICAL' segment
Nov 10, 2005   which processor counts, especially for NRIFACPU, NRIFLCPU
Jun  6, 2006   and NRICFCPU will always be zero; investigation with BMC 
               is in progress.                                          
               Jun 8, 2006 update: The error was only in the first level
               of CMF support for the z9, and was corrected by CMF APAR 
               BAM9572, PTF BPM9543.                                    
Change 23.287  Usability enhancement for selective output of DB2 data.  
READDB2        You can choose which datasets are to be created, which   
Nov 10, 2005   observations are to be output, and even which variables  
Nov 16, 2005   will be kept in any of the created datasets:             
Nov 22, 2005                                                            
               SELECTION CRITERIA:                                      
                DB2     = DB2 SUBSYSTEM(S)  WHICH SHOULD BE SELECTED    
               DATASET CRITERIA:                                        
                DB2ACCT=  Any of the below syntax                       
                DB2ACTB=   "                                            
                DB2ACTP=   "                                            
                       =YES   - DATASET IS CREATED WITH ALL OBS/VARS    
                       =NO    - DATASET IS CREATED WITH 0 OBS           
                       =KEEP/VAR1 VAR2 VAR3.. - DATASET IS CREATED AND  
                                         KEEPS ONLY THE LISTED VARIABLES
                       =DROP/VAR1 VAR2 VAR3... - DATASET IS CREATED AND 
                                         DROPS ALL THE LISTED VARIABLES 
   Thanks to John W. McAlinney, Vanguard, USA.                          
Change 23.286  Change 23.153 revised the value of SMF "subtype" for DB2 
VMXGGETM       102 trace records to contain the "IFCID" because that is 
Nov  9, 2005   the "logical" subtype for the 102s that don't have an SMF
               subtype in the SMF header.  That change also stores IFCID
               for subtype in the 100 and 101 records, even though they 
               do have SMF subtypes, because DB2 documentation refers to
               IFCIDs and not to SMF subtypes.  These are the values    
               that were changed, but not documented.                   
                 IFCID:        1      2    202      3    239            
                 Rec.Sty:  100.0  100.1  100.2  101.0  101.1            
               This change only added documentation notes in the member.
   Thanks to Daniel T. Cannon, The Hartford, USA.                       
Change 23.285  VM Accounting datetimes were incorrect; Change 23.109 had
TYPEVM         used the record LENGTH to identify the date format, but  
Nov  9, 2005   that test was not sufficient, and I can find no other way
Nov 11, 2005   to discriminate safely between MMDDYY or YYMMDD than to  
Nov 15, 2005   have you tell me in a new MACRO _DATEVM with values:     
                  _DATEVM    Date Format                                
                     1         MMDDYY       (Default)                   
                     2         YYMMDD                                   
               The default format is the IBM MMDDYY format; you can use 
               this syntax to change the macro value if needed:         
                  //SYSIN DD *                                          
                   %LET MACKEEP=   MACRO _DATEVM  1  %   :              
                   %INCLUDE SOURCLIB(TYPEVM);                           
               Nov 15: LENGTH=LENGTH restored to the INFILE statement.  
               Even though it can't be used for date-discrimination, it 
               is needed to identify some VM data records.              
   Thanks to Wah Chu, SIAC, USA.                                        
Change 23.284  PDB.PRINT,TYPE6 variables TOTLINES,NRLINES is 4294967295,
VMAC6          sometimes, in tcp/ip "Printway" file transfer records,   
Nov  7, 2005   which are SMF 6 records written by PSF for "print" output
               that was sent via tpc/ip to an ip address.  That decimal 
               value results when SMF6NLR contains 'FFFFFFFF'x is the   
               SMF record.                                              
              -These TYPE6/PDB.PRINT tcp/ip records have SUBSYS='TCP',  
               and only variable SMF6BYTES can be used for print bills  
               or printer resource measurements.                        
              -They do not have the PSF-APA segment, so SHEETPRN and the
               other fields from that segment are all missing.          
              -Why NRLINES is someimes bad and sometimes has reasonable 
               values is unknown (query pending to IBM), but NRLINES has
               never been recommended (see the PRINTERS section in the  
               MVS/ESA RESOURCE ACCOUNTING" article in NEWSLTRS.        
              -But because that large value is confusing and could mess 
               up your old print billing system with it, I have chosen  
               to test for the 'FFFFFFFF'x field value, and now set the 
               variable NRLINES to a missing value for those instances. 
              -PDB.PRINT variable TOTLINES is the equivalent of NRLINES.
               Do not use the old PRINTLNE/PUNCHCRD/EXTWTRLN variables, 
               because there is no safe way to identify which kind of   
               device was at the destination, and they are archaic in   
               any case.  TOTLINES is their sum, and the field to use,  
               if you still must have some count of "linew".            
              -Note that in non-TCP records for PSF, NRLINES can also be
               wierd when the SMF6PRMD printer mode is "DATA" and not   
               "LINE", but at least those records have valid SHEETPRN   
               in their PSF-APA segments.                               
              -Note for back-level-MXG users: SUBSYS='TCP' was added in 
               MXG 22.08 (Change 22.153), but SMF6BYTE has been input   
               since Change 13.328, and it will be non-missing only in  
               tcp/ip print records, so it could be used alternatively  
               to identify these records.                               
   Thanks to Thomas Heitlinger, FIDUCIA IT AG, GERMANY.                 
   Thanks to Philip Matthei, State of New York, USA.                    
Change 23.283  Support for ASG-Landmark TMVS Version 3.2 has confirmed  
VMACTMVS       that any changes made were COMPATIBLE, but I won't take  
Nov  3, 2005   time to compare all of the DSECTS to look for new data   
               until a user finds a need for it.  The last change in    
               MXG was prior to MXG Version 20.20.                      
               See Change 23.294 for internal record changes in 3.2.    
   Thanks to Richard Evans, Worldspan, USA.                             
Change 23.282  MXG 23.08-MXG 23.02.  Change 23.068 used a rare GOTO that
VMAC26J3       should have been a LINK statement.  The GOTO caused the  
Nov  3, 2005   RETURN statement after the label to be a DELETE statement
               so the rest of the record was never read nor was the exit
               for the OUTPUT every called for that record.             
                 This behaviour of the RETURN statement only occurs when
                 there are OUTPUT statements in the SAS data step.      
                 If there are no OUTPUT statements, a RETURN after GOTO 
                 causes all datasets in the DATA statement to be OUTPUT.
               With the LINK statement, the label is called, but RETURN 
               brings the program back to the statement after the LINK, 
               so the rest of the record is read and OUTPUT.            
   Thanks to Dave Falzon, EDS Ottawa, CANADA.                           
Change 23.281  MXG 23.08.   ERROR: File WORK.TYPE791.DATA does not exist
TESTIBM1       when JCLTESTx is run.  TYPE79 now sorts the TYPE79xx data
Nov  2, 2005   (to deaccumulate) to the PDB library, but the TESTIBM1   
               program's PROC MEANS still expected those data in WORK.  
               TESTIBM1 was changed to find TYPE79xx in the default PDB.
   Thanks to Bernd Klawa, Stadwerke Bielefeld GmbH, GERMANY.            
Change 23.280  DB2 Package Data could STILL be wrong, if any of these   
VMACDB2        fields are longer than the original un-truncated length: 
Nov  1, 2005       variable   label                           was    now
Nov  2, 2005      QLACLOCN='LOCATION*NAME'                    $16    $16
Dec 13, 2005      QPACLOCN='LOCATION*NAME'                    $16    $16
                  QPACCOLN='PACKAGE*COLLECTION ID'            $18    $18
                  QPACPKID='PROGRAM*NAME'                     $18    $18
                  QPACASCH='NESTED*ACTIVITY*SCHEMA*NAME'       $8    $17
                  QPACAANM='NAME*OF*ACTIVITY'                 $18    $18
               In the observed case, QPACASCH was increased to 16 bytes 
               and contained 'SYSPROC.S1BNLERP' as one example value.   
               For now, I've increased the default length of QPACLOCN   
               to $17, pending an understanding of whether the increase 
               was made by the installation or by IBM.  The revised code
               inputs them all with $VARYING128, which is the maximum   
               documented length  With MXG's COMPRESS=YES default, they 
               could be changed to default $128 length, but that could  
               dramatically increase the size of the DB2ACCTP dataset   
               if you have turned off COMPRESS=YES, so I chose to leave 
               the other above fields in their original stored lengths. 
               The original text contained this next statemnt:          
 Insert Mar 27, 2013:  THIS 2006 statement is false in sas version 9:   
              "You can change the stored length by the addition of:     
                    LENGTH QPACxxxx  $nn ;                              
               in the EXDB2ACP exit; SAS uses the last LENGTH statement 
               to set the variables stored length."                     
               SAS uses the FIRST instance of the character variable to 
               set its length, and prints a WARNING that first length if
               a LENGTH statement with a different length os found.     
 end of Mar 27, 2013 Insert.                                            
              -Dec 13, 2005: HOORAY, package date WAS FIXED in November;
               this is only additional documentation about package data:
               In DB2 V8 data, in dataset DB2ACCTP, QWACBSC and QWACESC 
               variables (begin/end datetimes), are now always missing, 
               because V8 creates only SMF 101 Subtype 1 IFCID=239 data.
               In V7 and earlier, IFCID=0003, Subtype=0 records (first  
               ten packages) did populate those variables, but IFCID=239
               records always had BSC/ESC missing for the 11th-plus     
   Thanks to Tory Lepak, Aetna, USA.                                    
Change 23.279  Support for VTCS 6.0 and 6.1 SMF records (COMPATIBLE).   
FORMATS        These new variables are created, but only CTP appears to 
VMACSTC        be new in 6.1 records, all other variables below do have 
Nov  1, 2005   real values in 6.0 SMF records:                          
                Dataset STCVSM13:                                       
                     decoded by $MGSTCCT format:                        
                        '0000'X='0000X:S-CART 400MB'                    
                        '0001'X='0001X:E-CART 800MB'                    
                  STC15MNR='MOUNTED*WITHOUT*A RECALL?'                  
                  STC15MRC='MOUNTED*AFTER*A RECALL?'                    
                Dataset STCVSM14:                                       
                     decoded by $MGSTCCT format:                        
               In the 6.0 data tested, STC14DSN was always blank; STK is
               investigating why.                                       
              -Variables 13FLG,14FLG,13HID,14HID,13SEQ,14SEQ,13VTI,14VTI
               and STC13OID are archaic and always missing; those fields
               only existed prior to version 5.0.                       
   Thanks to Ruth Whitney-Parker, CitiGroup, USA.                       
   Thanks to Nathan Loewenthal, CitiGroup, USA.                         
Change 23.278  This change was implemented in Change 23.300 and its text
               was relocated into that change.                          
Change 23.277  Two new job status variables are created from new bits in
VMAC26J2       SMF26IX2 (old PRPRTY variable):                          
                 JOEPURGE='JOE*PURGED*DUE TO*PSO/SAPI?'                 
   Thanks to Leendert Keesmaat, UBS AG, SWITZERLAND.                    
Change 23.276 -PDB.ASUMCEC variables LP0MGTTM, LPCT0OV and PCTL0OV were 
VMXG70PR       always zero after Change 23.021, due to incorrect logic. 
Oct 31, 2005   This error was only in PDB.ASUMCEC; those variables were 
               correct in PDB.ASUM70PR.                                 
              -Also, ASUMCEC variables IFAUPTM, IFAACTTM, and IFAWSTTM  
               were not formatted with TIME12.2 format.                 
   Thanks to Wayne Bell, UniGroup, Inc, USA.                            
Change 23.275  Support for CA TopSecret SMF 80 records with SMF80DTP of 
EXTY80TS       103,104,105,109,255 values.  This is preliminary support,
IMAC80A        as the DSECT does not exactly match the SMF record, so   
VMAC80A        further validation is required.  Dataset TYPE80TS is     
VMXGINIT       created from all of those DTP values.                    
Oct 28, 2005                                                            
   Thanks to Chris Hober, Charles Schwab, USA.                          
   Thanks to Neil Ervin, Charles Schwab, USA.                           
Change 23.274  The MACRO definition for MACRO _N120 was missing the text
VMAC120        MACRO for each of the _NULL_ entries; attempting to use  
Oct 27, 2005   the _N120 macro to null out all datasets failed.         
   Thanks to Xiaobo Zhang, ISO, USA.                                    
====== Changes thru 23.273 were in MXG 23.08 dated Oct 27, 2005=========
Change 23.273  NOT SORTED error in building PDB.ASUMCEC (error was right
VMXG70PR       after the - IFA2 FOR CEC note on the log) can occur with 
Oct 27, 2005   some data values.  The reset of STARTIME to the nearest  
               minute (in EXCECTIM) caused the out of order condition,  
               which is now corrected by a PROC SORT.                   
   Thanks to Joe Montana, Acxiom, USA.                                  
Change 23.272 -First MXG 23.08 only.  ARRAY SUBSCRIPT OUT OF RANGE error
VMAC7072       due to MXG logic introduced in Change 23.237 to count IFA
Oct 27, 2005   and IFL engines using the (new-in-z9) SMF70CIN values in 
               new NRIFACPU and NRIFLCPU variables (which are non-zero  
               ONLY if you have a z9 processor that puts IFA and IFL in 
               the SMF70CIN field).  The new logic was fine, but the new
               LCPUADDR values that are greater than the number of real 
               engines in the LPARNAME='PHYSICAL' caused the failure.   
               The solution was to relocate the LPARNAME='PHYSICAL' test
               that sets MXGCIN='PHY' above the test for LCPUADDR.      
              -New MACHTIME was in the year 2041; the SMF documentation 
               had SMF70HWM after SMF70LAC, but the new SMF70HOF field  
               was inserted between LAC and HWM in z/OS 1.7.            
   Thanks to Joe Montana, Acxiom, USA.                                  
====== Changes thru 23.271 were in MXG 23.08 dated Oct 25, 2005=========
Change 23.271  An unknown NAF record segment caused the record to be    
VMACNAF        DELETEd, so subsequent segments were not OUTPUT.  The    
Oct 22, 2005   DELETE was removed and the number of messages limited,   
               and a hex dump of the first five unknown records is now  
               printed on the SAS log.                                  
               When documentation for the 'C0' segment is found, the    
               segment causing the problem will be supported.           
   Thanks to Joe Babcock, JPMC, USA.                                    
Change 23.270  Due to popular demand, though I really fail to see the   
VMAC7072       need, I've put back the individual IFA engine percentage 
Oct 21, 2005   busy variables, PCTIFBY0-PCTIFBY9,PCTIFBYA-PCTIFBYX in   
Oct 25, 2005   the KEEP= list for dataset TYPE70.                       
               Oct 25: And now, they have non-missing values; those     
               variables were added in 22.09 and then removed, but even 
               in 22.09 their values were always missing.               
   Thanks to Stan Dylnicki, Royal Bank of Canada, CANADA.               
   Thanks tO Lawrence Jermyn, Fidelity Systems, USA                     
Change 23.269  z/VM MONWRITE dataset VXSYTEPM, Extended Channel Metrics,
VMACVMXA       had not been data-tested for accumulated data values.    
Oct 21, 2005   Now, ESCON variables ECMCPBTC and ECMCPBTL and FICON     
               variables ECMCBC ECMCCWUC and ECMCCWUL are DIF()'ed.     
               ESCON and FICON observations have different variables    
               populated; variable CSCCMCMG identifies FICON/ESCON.     
               The default _TESTMW macro invokes the _SSYTEMP macro that
               does the actual deaccumulation.                          
              -Bit CALINIT was on in one observation, uncovering a data 
               record that must be used to initialize the DIF() function
               but then must be delete.                                 
   Thanks to Melanie Hitchings, BT, ENGLAND.                            
   Thanks to Brian Crow, BT, ENGLAND.                                   
Change 23.268  RMF 79 subtype 9 records had never been validated; some  
TYPE79         fields are accumulated and some are not, and IBM doesn't 
VMAC79         choose to document which is which, so real data is needed
Oct 20, 2005   to know that these variables had to be deaccumulated:    
                  R799PCT R799ALC R799ATV R799CMR R799CNN R799CUB       
                  R799DIS R799DPB R799DVB R799MEC R799PEN R799SCC       
                  R799QUE R799UTL                                       
               in the _STY799 "Dataset Sort Macro, which is invoked by  
               the _S79 "Product Sort Macro".                           
              -The TYPS79 member did invokes the _S79 macro, but that   
               is now also added to the TYPE79 member so you don't      
               accidentally create only the accumulated datasets.       
              -Variables R799DPB and R799PCT have clearly invalid values
               but IBM documents them as "not used".                    
   Thanks to Jerry Ellis, Liberty Mutual, USA.                          
Change 23.267  Optional CICS OPID field with CMODHEAD='OPID' creates new
IMACICO1       OPID variable in CICSTRAN dataset, but only if UTILEXCL  
UTILEXCL       was used to create an IMACEXCL, and only if a dictionary 
VMAC110        record had that CMODHEAD entry, and only if the comment  
Oct 20, 2005   block in member IMACICO1.                                
   Thanks to Lucy Fukishima, California Health and Welfare, USA.        
Change 23.266  Documentation.  DFSORT SMF Release 16 SMF 16 records are 
VMAC16         already supported; there have been no changes to the IBM 
Oct 20, 2005   SMF 16 SMF record since Release 14.                      
Change 23.265 -MXG 23.05-MXG 23.07, the RMFINTRV workload variables with
VMXGINIT       IFA and IFE CPU times were always zero; Change 23.123 did
VMXGRMFI       not correctly create those workload variables.           
Oct 20, 2005  -Logic was added to VMXGRMFI in Change 23.215 to determine
Nov  3, 2005   if a VIEW could be used, but macro variable name VGETENG 
               was not GLOBALed in VMXGINIT, which caused SAS error that
               MACRO VARIABLE UNRESOLVED errors!                        
               Nov 3: Text updated.  Adding VGETENG also required there 
                      be a //INSTREAM DD, which has been in MXGSAS JCL  
                      for years, but I never told ITRM this change made 
                      it now required that their JCL also have this     
               Nov 28: See Change 23.298 which eliminated the use of the
                      //INSTREAM in VGETENG to avoid this exposure.     
   Thanks to Wolfgang Vierling, Allianz, GERMANY.                       
Change 23.264  The subtype 31 SARR records had a coding error; the code:
Oct 19, 2005   should have been:                                        
                IF SV31IOF+SV31ILN-1 LE LENGTH AND SV31ILN GE 1 THEN DO;
   Thanks to Wim Desmecht, NV INFOCO, BELGIUM.                          
Change 23.263  The length of MXG-created variable CPCFNAME, which is the
VMXG70PR       concatenation of CPUTYPE and CPCMODEL, was increased from
Oct 12, 2005   $8 to $10 because an Amdahl GS2108E system has 2000-2108E
               for CPCFNAME, which wouldn't fit in 8 bytes.             
   Thanks to Steve Rowe, DST Systems, Inc, USA.                         
Change 23.262  Documentation note only.  If you get these error messages
Oct 12, 2005    DATASET WORK.TYPE30_4 MAY BE INCOMPLETE                 
               The error is due to a corrupted SPIN library (due to a   
               prior failure when testing a %UTILBLDP or BUILDPDB run   
               that didn't complete successfully).                      
                - If this is still in testing, and there WAS nothing of 
                  value in the SPIN library, then you only need to use  
                  PROC DELETE DATA=SPIN._ALL_;  and can then re-test.   
                - If this should happen after BUILDPDB/UTILBLD is in    
                  production and you had data in the SPIN data library  
                  (VERY RARE, because you had to have done something to 
                  MXG to cause this failure and then tried to run the   
                  production BUILDPDB job), then you must restore the   
                  //SPIN data library to the way it was prior to what   
                  you did that caused the failure, from the last PDB    
                  data library from the last succesful BUILDPDB.  This  
                  is easy, because BUILDPDB backs up your SPIN library  
                  datasets into each PDB data library, so you would use:
                     //YESTER DD DSN=YOUR.LAST.PDB,DISP=SHR             
                     //SPIN   DD DSN=YOUR.SPIN,DISP=OLD                 
                      PROC COPY IN=YESTER OUT=SPIN;                     
                        SELECT SPIN: ;                                  
                  (the 'colon' is the wildcard in the SELECT statement).
Change 23.261  Invalid Extended Segment section in SMF 14 record caused 
Oct 11, 2005   tried to read the rest of the record after detecting this
               bad segment, but the rest of this record was also trash, 
               so now, the error messages are printed:                  
                           TYPE1415 OBSERVATION WAS NOT OUTPUT.'        
               and the rest of the INPUT is now skipped.                
   Thanks to Sidney Owens, District of Columbia Government, USA.        
Change 23.260  Linux under z/VM dataset VXAPLSLM variable PGFAUMI label 
VMACVMXA       said "PAGE*FAULTS*MINOR*ONLY" but the field contained the
Oct  6, 2005   MAJOR*ONLY faults.  This change creates PGFAUMJ with the 
Oct 13, 2005   MAJOR*ONLY faults, and corrects the value in PGFAUMI so  
               it is the MINOR*ONLY to match it's label.                
               Oct 13: Original divide changed to multiply.             
   Thanks to Kris Ferrier, State of Washington DIS, USA.                
Change 23.259  The SMF _ID macro for some early SMF records didn't start
VMACWYLB       with _ID; this change adds the "standard" ID maro name of
Oct  4, 2005   MACRO _IDxxxx nnn  %  to replace those archaic spellings,
               but the original macro can still be used, since the code 
                 IF ID=_oldname OR _ID= _IDxxxx THEN DO;                
               is used in these members:                                
                  Oldname    Standard                                   
                  _WYLBUR    _IDWYLB                                    
   Thanks to Freddie Arie, Merrill Consultants, USA.                    
Change 23.258  Support for SYSVIEW for IMS user SMF records.            
EXSYSIDL         dddddd   Dataset   Description                         
IMACSYSI       This code is still in early testing, but because all of  
TYPESYSI       the test file has only the TRN, CNT and CLK segments, and
TYPESYSI       exactly one each, and multiple segments doesn't make any 
TYPSSYSI       sense for the transaction, I now combine those three into
VMACSYSI       a single obs in the SYSITRAN dataset.  Because none of   
VMXGINIT       other segments are populated, the code, for now creates a
Oct  5, 2005   separate dataset for each segment, which may or may not  
               be the final design.                                     
              -Also, there is undocumented data in the records.  While  
               the triplet count is 3 and the first three triplets are  
               populated for the TRN, CNT, and CLK segments, the eighth 
               triplet, "WRK" is also populated, pointing to a segment  
               with at least 8 populated TODSTAMP fields, but the WRK   
               segment is not described in the DSECT.                   
   Thanks to John Rivera, (i)Structure, USA.                            
   Thanks to Ken Steiner, (i)Structure, USA.                            
   Thanks to David Zelmer, (i)Structure, USA.                           
Change 23.257  All variables created from TEMP were LENGTH $200, even   
VMACTPMX       though the actual INPUT was  INPUT TEMP $VARYING16. And, 
Oct  4, 2005   variables JBBND and JLIMT should have had $VARYING17. as 
               they can contain two levels and a period.  So, lacking a 
               clear knowledge of exact maximum lengths, I folded all of
               the $VARYINGnn (nn=6,14,16,64,80), into (nn=17,80) using 
               only TEMP17 and TEMP80 variables to set the kept lengths.
               Note that as long as the MXG default option COMPRESS=YES 
               is still in effect, essentiall no space was wasted even  
               when the length was $200.                                
   Thanks to Lawrence Jermyn, Fidelity Systems, USA.                    
Change 23.256  Updated revision; warning messages RMFV022W and RMFV023W 
ASMRMFV        could be incorrectly issued, ASI data would be missing   
Oct  4, 2005   and ASMRMFV would set Return Code 4.                     
   Thanks to Jerry Urbaniak, Acxiom CDC, USA.                           
Change 23.255  The text for several TNG metrics in $MGTNGVN format were 
FORMATS        truncated in their VALUE statement, printing MXG messages
Oct  3, 2005   about UNKNOWN fields.  Fields 31,34,36,37,46,and 113 for 
               the NT data for the SMPT Server Object were corrected.   
   Thanks to Peter Krijger, ANZ National Bank Limited, NEW ZEALAND.     
Change 23.254  The ADOCMWSU member for HP MeasureWare for Sun has been  
ADOCMWSU       updated with the REPORT command syntax that creates the  
VMACMWSU       data fiels with the fields that TYPEMWSU expects.        
Oct  3, 2005  -VMACMWSU's test for TYPE was expanded to test 'TRAN' so  
Oct  5, 2005   those records will now be output.                        
   Thanks to Albert Jacobs, KBC Bankverzekieringsholding, BELGIUM.      
Change 23.253  Initial rewrite of the ASUMTAPE program that combines    
ASUMTAPE       MXG's Tape Mount TYPETMNT data with IBM's Tape Dismount  
VMACTMNT       TYPE21 SMF data to create PDB.ASUMTAPE dataset, with the 
VMAC21         start and end times of the mount, the dismounted time,   
Sep 30, 2005   and bytes read, written, and any tape error counts.      
Oct 19, 2005   Because the "Exit-Driven" architecture of ASMTAPEE ML34+ 
               captures all mounts and populates all JOB-related data,  
               only the PDB.TYPETMNT and PDB.TAPES (a/k/a TYPE21) are   
               needed to create PDB.ASUMTAPE.  (PDB.TYPETALO was used   
               to populate missing fields when mounts were sampled.)    
              -The SPIN.SPINMOUN and SPIN.SPIN21 will hold incomplete   
               mount/dismount records, to be reintroduced tomorrow.     
              -These variables, from the allocation event, are no longer
               created in PDB.ASUMTAPE:                                 
                 SMFVOL01 TERMNAME TMNT008I XMEMABND                    
              -These job-related variables were only in the Allocate    
               record; they are now created in PDB.TYPETMNT and will be 
               created in PDB.ASUMUOW, but they will be blank until the 
               ASMTAPEE monitor program adds them to the mount record:  
              -VMAC21 now sets BLKSIZE=. if SMF21LB is not on.          
              -"Group" definition macros, _GRPMNNM and _GRPMNCD, are now
               added in ASUMTAPE to group SYSTEMs that have overlapping 
               DEVNRs.  Using the example in the comments to create a   
               _GRPMNNM variable, ASUMTAPE groups BY _GRPMNNM DEVNR so  
               each "location/group" is analyzed correctly.             
              -A macro _DEBUG is defined in ASUMTAPE, and when invoked  
               it will print a log of the sequence of mount, dismount   
               and allocation records for diagnostics if there is a     
               problem case observed; if you can also send the JOBLOG of
               the job(s) involved, it will help our investigations.    
              -This revision is in early testing; it appears to work    
               perfectly when there is a match of mount/dismount, and   
               it recognized back-to-back dismounts (i.e., missed mount)
               in variable STATUS, but it needs extensive validation and
               comparisons to the SYSLOG of weird cases before I can    
               fully say it's ready for prime time.                     
              -In testing this revision, I discovered that ASMTAPEE at  
               ML-34 thru ML-36 do NOT capture all tape mounts in their 
               exit logic: these are two known cases of missed mounts:  
                 - Multi Volume Mounts - Only first Mount is captured in
                    the IBM Volume Mount Exit; STK's HSC exit sees all. 
                 - DFHSM Mounts to 3590s - None captured, but mounts for
                   other jobs on 3590s are captured.                    
               An investigation by "asmguy" has just been started today 
               as a result of this (unwanted!) discovery, which will    
               likely require SLIP traps, dumps, and possibly multiple  
               iterations to find out why these mounts were not seen.   
              -Oct 19: Macros _grpALxx are renamed to _grpMNxx to be    
               consistent; AL is for allocation and MN is for mounts,   
               and ASUMTAPE should be used instead of TYPETMNT for tape 
              -See further revisions in Change 23.300 and later.        
   Thanks to Normand Poitras, IBM Global Services, CANADA.              
   Thanks to Beau Chavis, Bank of America, USA.                         
   Thanks to Jim Sherman, Lockheed-Martin, USA.                         
Change 23.252  TMS/CA-1 DEVTYPE variable was blank for TRTCH='E2'X, but 
VMACTMS5       now DEVTYPE='STK9840-C' is decoded for that TRTCH value. 
Sep 29, 2005   DEVTYPE='STK9842' already was decoded for TRTCH='E7'X.   
   Thanks to John Gebert, FDIC, USA.                                    
Change 23.251  Enhancement to set TRANNAME in PDB.ASUMUOW from CICSTRAN 
VMXGUOW        observation in each Unit of Work that was not the CSMI   
Sep 29, 2005   transaction but that had the longest IRESPTM duration, as
               a more robust identification of the "real" transaction.  
   Thanks to Chuck Hopf, MBNA, USA.                                     
Change 23.250  OPTIONS NODSNFERR NOVNFERR; was missing from the TRNDCACH
TRNDCACH       member; it is needed to protect the first-time-through,  
Sep 28, 2005   when the TREND.TRNDCACH member doesn't yet exist.        
               All other TRND members had that option, so I assume it   
               was inadvertently deleted.                               
   Thanks to Tom Kelman, Commerce Bank of Kansas City, USA.             
Change 23.249  Using %READDB2 to process DB2 Trace 102 SMF record now   
ANALDB2R       decodes the DBID and OBID values, if you enabled 105/107 
READDB2        IFCIDs, and those records are in the input SMF data file.
VFMT102        (Previously, only the %ANALDB2R report printed the real  
Oct 22, 2005   names of the OBID or DBID).  Formats $MGDB2DB/$MGDB2OB   
               are created by VFMT102 member, used by both ANALDB2R and 
               VMAC102, if 105 or 107 records were found, but only cover
               the time frame of the trace, since DBID and OBID can     
               change.  The 105/107 records are only written at OPEN,   
               and the formats use the timestamp range of the data read 
               by READDB2, so you may still find $HEX4. values for the  
               DBID and OBID variables some of the time.                
   Thanks to Chuck Hopf, MBNA, USA.                                     
Change 23.248  An ending */ was missing in the exit member, but there   
EXDB2ACC       were subsequent end comments that apparently prevented an
Sep 22, 2005   error, as this was observed by Bruce, rather than the    
               result of a reported error condition.  Sometimes, a      
               missing end comment, even when there are subsequent ends 
               for other comments, has caused strange errors.           
   Thanks to Bruce Widlund, Merrill Consultants, USA.                   
Change 23.247  ML-36 of ASMTAPEE corrects a problem in the Allocation   
ASMTAPEE       Monitor introduced in ML-35 that cause a major increase  
Sep 22, 2005   in the CPU time of the MXGTMNT task.                     
   Thanks to Normand Poitras, IBM Global Services, CANADA.              
Change 23.246  Support for adding un-sorted datasets to your WEEKly PDB.
WEEKBLD        MONTHxxx programs supported adding unsorted datasets by  
WEEKBLDT       using   MACRO _BY %     MACRO _SORTBY %  in place of     
WEEKBLDD       the normal MACRO _BYLIST var1 var2 % definition, but the 
WEEKBL3        WEEKxxxx programs were not revised to define those two   
WEEKBL3D       macros, until now.  As a reminder, once these two macros 
WEEKBL3T       have been specified, all subsequent datasets will be     
Sep 16, 2005   treated as non-sorted, so the un-sorted dataset build    
               macros should be at the very bottom of your EXPDBWEK or  
               EXPDBMON tailoring member.                               
   Thanks to Cheryl Heiner, State of Montana, USA.                      
Change 23.245  A single quote (') in the WLM data for a variable was not
REXXWLM        converted to two single quotes (''), which could cause a 
Sep 16,2005    SAS error.                                               
   Thanks to Sam Bass, McLane Company, USA.                             
Change 23.244  Using MXG's %VGETDDS(DDNAMES=XYZ: ...) and %VMXGSET to   
VGETDDS        read from all SAS data libraries in your JCL that have   
VMXGSET        DDNAMES starting with "XYZn" can fail to read all DDs,   
Sep 16, 2005   but ONLY if you have installed the IBM PATCH for HSM that
               is documented in IBM APAR OY63500, and ONLY if one of the
               "XYZn" datasets is independently being migrated by HSM!  
               That PATCH allows HSM to bypass normal DSENQ protection; 
               the site runs an HSM job every 30 minutes to migrate data
               from ML0 to ML2.  The HSM task started the migration, and
               then the MXG job started to run (because DSENQ had been  
               bypassed).  VGETDDS tests each XYZn DD with PROC SQL to  
               find its ENGINE, but SAS did not recognize that XYZ3 was 
               a SAS Data Library in its DICTIONARY.MEMBERS table (due  
               to its migration-in-progress status), so VGETDDS saw     
               UNKNOWN engine, and stopped its search for other XYZn    
               DDNAMES when the first UNKNOWN engine type is found.     
               Since VGETDDS only saw XYZ1 and XYZ2, the XYZ3 DDNAME    
               was never opened by SAS, so the OPEN ABEND discussed in  
               the IBM APAR text never happened.                        
               If you have the "PATCH" in OY63500, and you permit your  
               PDBs to be migrated by HSM while trying to use one, there
               is no possible MXG fix for this error; the only clues    
               that there was an error was that many fewer obs were     
               read than expected, and/or the VGETDDS message on the log
               explicitly said it only found two XYZn DDNAMES.          
                 (But the whole point of VGETDDS/VMXGSET is so your JCL 
                  determines how many XYZn DDNAMES are read, and so you 
                  DON'T have to tell me how many to expect!).           
               The only way to prevent I can think of is to put these   
               PDB libraries in a dataclass that is not migrated by the 
               interval task, to eliminate the exposure.                
Change 23.243  Enhanncement to RMF III VSAM support ASMRMFV/TYPERMFV.   
ADOCRMFV      -ASMRMFV corrects a few issues, reduces CPU utilization by
ASMRMFV        use of MVCL instruction, and adds the ASI Extension that 
CLRMFV         had been requested by Lawrence Jermyn, along with other  
DOCLRMFV       minor changes.  The ASI Extension improves the ability to
VMACRMFV       subset and group RMF Monitor III data for historical     
Sep 15, 2005   analysis at the Address Space level.  This version also  
Sep 16, 2005   offers additional Assembly Language symbolics to let you 
               tailor the ASMRMFV defaults.                             
              -CLRMFV: There are no changes to the CLIST; its just here 
               as a reminder that it is used to process RMFV data.      
              -ADOCRMFV: Extensive notes on what Jerry did are added!   
              -DOCLRMFV:  Updated notes.                                
                 ASICNM   ASICDE   ASICWN   ASICRN  ASICPO   ASICPN     
                were added to ZRBASI dataset.  ASIVERG3 values '0F'x and
                greater indicate that the zAAP fields are present in the
              -Sep 16: Old SVP Buffer Table cleanup added.              
   Thanks to Jerry Urbaniak, Acxiom CDC, USA.                           
Change 23.242  Support for SMF type 82 subtypes 20 and 21 is added.     
EXTY8220        Subtype  dddddd   Dataset   Description                 
EXTY8221         20      TY8220   TYPE8220  Crypto Coprocessor Timings  
FORMATS          21      TY8221   TYPE8221  ICSF Sysplex Group Change   
IMAC82        -In TYPE8220, MXG variables NQAPDQAP and DQAPWAIT are the 
VMAC82         calculated delta times between TNQ-TDQ and TDQ-TWT, after
VMXGINIT       using the TWT-SMFTIME delta to create GMT82OFF. Since it 
Sep 12, 2005   is the coprocessor duration, and not time of day, that is
               of interest, the original SMF82TNQ, SMF82TDQ and SMF82TWT
               variables are not kept.                                  
              -SMF82TSF, Coprocessor sub function code is not documented
               in the SMF manual; it is a $HEX4. value, and will be     
               formatted when it's possible values are known.           
              -SMF82TRN will be missing until you install z/OS 1.7.     
              -TYPE8221 code has not been tested with records, yet.     
   Thanks to Ian Arnett, TD Canada Trust, CANADA.                       
Change 23.241  Two more typos: NR25SEGS in the WHEN (24) group should   
VMAC80A        have been NR24SEGS, and NR44SEGS in the WHEN(43) group   
Sep 12, 2005   should have been NR43SEGS.                               
   Thanks to Bill Arrowsmith, Euroclear, BELGIUM.                       
   Thanks to Stephen Morris, National Australia Bank, AUSTRALIA         
Change 23.240  IRESPTM, the response time of the CICS Unit of Work, and 
VMXGUOW        ELAPSTM, the total elapsed duration of the DB2 portions  
Sep  9, 2005   of the Unit of Work, some which could be in parallel,    
               are revised. IRESPTM is now the maximum of the CICSTRAN  
               segments in this unit of work, while ELAPSTM is the sum  
               of the individual elapsed times of the DB2ACCT segments, 
               in the PDB.ASUMUOW dataset built by INCLUDE of ASUMUOW.  
               In addition, new variable DB2IDLE, which was originally  
               created by archaic ANALDB2C, but lost when ASUMUOW was   
               built, is now created.  DB2IDLE is the elapsed time from 
               last CICS ENDTIME to the DB2 QWACESC End time, and is the
               duration when the DB2 thread was idle, but has not ended,
               presumably for possible thread reuse.  DB2IDLE is then   
               subtracted from the sum of the DB2ACCT ELAPSTMs, so the  
               final ASUMUOW ELAPSTM does NOT include DB2IDLE time.     
              -This change can make ELAPSTM smaller than before, for    
               serial transactions that had DB2IDLE time.               
              -This change can make ELAPSTM larger than before, for DB2 
               Parallel transactions (DBPARTY='P'), because the prior   
               ELAPSTM was start to finish.  But since parallel=3 can   
               burn 3 hours of CPU time, the elapsed time must be the   
               sum of the parallel elapsed time, rather than start to   
               finish of the unit of work.                              
              -In addition, the _TRANUOW user exit has these additional 
               variables available for examination, etc.                
                 HOLDIRSP: MAX of IRESPTM from CICSTRAN                 
                 HOLDELAP: SUM of ELAPSTM from DB2ACCT                  
                 HOLDFSTR: Min of CICS STRTTIME start datetime          
                 HOLDLSTR: Max of CICS STRTTIME start datetime          
                 HOLDFBSC: Min of DB2 QWACBSC begin datetime            
                 HOLDLESC: Max of DB2 QWACESC end datetime              
   Thanks to Hugh Lapham, Royal Canadian Mounted Police, CANADA.        
Change 23.239  Support for DURATM keywords TENMIN and FIVEMIN.  Code had
VMXGDUR        been added in VMXGDUR, but not in VMXGSUM.  Obscure notes
VMXGSUM        in member VMXGSUM did say that if you use DURATM= with an
Sep  9, 2005   unsupported keyword, variable DURATM will not be created.
               The actuality is that these DURATM= values:              
                   HOUR   THREEHOUR DATE    WEEK                        
               do create variable DURATM, while these DURATM= values    
                   MONTH and SHIFT                                      
               do not create variable DURATM.                           
   Thanks to Tom Kelman, Commerce Bank of Kansas City, USA.             
Change 23.238  Sites that run UTILEXCL daily to create IMACEXCL code    
UTILBLDP       (due to frequent CICS dictionary changes), normally write
Sep  8, 2005   their IMACEXCL code to a "flat file" rather than a PDS   
               (avoids need to compress the PDS), adding //IMACEXCL DD  
               to point to that code, and adding %INCLUDE IMACEXCL;     
               using MACKEEP= logic. However, the include of an external
               DD statement was not supported in UTILBLDP.  Now, it is, 
               with the new IMACEXCL= argument.                         
   Thanks to Chuck Hopf, MBNA, USA.                                     
Change 23.237 -Variables NRIFACPU and NRIFLCPU are added to PDB.ASUM70PR
VMAC7072       and PDB.ASUMCEC datasets built by ASUM70PR for processors
VMXG70PR       that populate 'IFA' and 'IFL' in SMF70CIN (only z9 now). 
Sep  7, 2005   Variables LPnDSA are now labeled.                        
              -MXGCIN variable now contains new IFA and IFL values.     
Change 23.236  Support for Endeavor Release 7; there were no changes to 
VMACENDV       their user SMF record.                                   
Sep  6, 2005                                                            
   Thanks to Herb Strozinsky, US Bank, USA.                             
Change 23.235  DB2TCBTM for Rollup observations (DB2PARTY='R') is wrong 
VMACDB2        and could be less than QWACAJST (the TCB time in DB2).   
Sep  6, 2005   APAR PQ41012 documented that in rollups the accumulated  
               Elapsed and TCB were in QWACESC & QWACEJST, but only the 
               elapsed time was corrected in Change 22.121. Now, the    
               DB2TCBTM is recalculated when DB2PARTY='R' is set, using:
               (The final component, QWACTRTE is added in later.)       
   Thanks to Scott Barry, SBBWorks, Inc, USA.                           
Change 23.234  Peter Enrico's presentation at SHARE in August 2005 had  
GRAFWLM        graphs of CPU utilization grouped by SYSSTC, SYSTEM, work
Sep  8, 2005   with a goal, and work without a goal, to show how much   
               work could or couldn't be managed by WLM.  This analysis 
               produces similar SAS/GRAPH stacked bar charts, showing   
               CPU Time and MSU consumed by these groupings from top to 
                      IMP 1 CPU CRITICAL                                
                      IMP 1                                             
                      IMP 2 CPU CRITICAL                                
                      IMP 2                                             
                      IMP 3 CPU CRITICAL                                
                      IMP 3                                             
                      IMP 4 CPU CRITICAL                                
                      IMP 4                                             
                      IMP 5 CPU CRITICAL                                
                      IMP 5                                             
                      (All unclassified discretionary work - should have
                       no unclassified work!)                           
                      (All work classified as discretionary, regardless 
                       of importance. Discretionary work is work in a   
                       service class period that does not have a goal.  
               An example of the output can be viewed at                
               See comments in the member for usage documentation.      
   Thanks to Peter Enrico, Enterprise Performance Strategies, Inc.      
   Thanks to Chuck Hopf, MBNA, USA.                                     
Change 23.233  Several corrections and enhancements to Web Log support: 
VMACWWW       -ELAPSTM, at least for BEA WebLog was way too small; their
Sep  2, 2005   "time-taken" field contains 'seconds.fraction' value, but
Sep  3, 2005   MXG expected a millisecond integer value.  Now, MXG will 
               detect a period in the time field, and inputs ELAPSTM as 
               'seconds.fraction' when a period is found; otherwise, the
               field is input and divided by 1000 to get seconds.       
              -Example FILENAME now has LRECL=4096 to match the INPUT   
               $VARYING4096.  If LRECL was not specified, LRECL=255 is  
               the default, which causes "ONE OR MORE LINES TRUNCATED". 
              -TRANSLATE(RECORD,' ','09'x); added, because BEA log has  
               a hard tab, '09'x between fields instead of blanks.      
                  Dealing with '09'x can be nasty, since it is usually  
                  turned into a blank by most editors, and blanked by   
                  SAS when input records are displayed, so you often    
                  don't even know there's an '09'x value, until your    
                  read and display the field in hex, using:             
                    INPUT FIELD $CHAR50.; PUT FIELD= $HEX100.;          
              -Change 23.026 protected one of the two URIQVALU=SUBSTR();
               now both are protected for URIQVALU=0, which happens when
               when an = in the URIQUERY string is immediately followed 
               by an &, causing LTOAND=1 and thus causing URIQVALU=0.   
               Before Change 23.026, CSBYTES and SCBYTES were kept as   
               length $4096 because MXG used CSBYTES=WORD(....); and    
               WORD's is $4096, so CSBYTES/SCBYTES wasted space when    
               SAS compression was not used (COMPRESS=YES is default).  
               That change made them numeric, saving space, but they    
               were now 4-byte length due to MXG's DEFAULT=4.  However, 
               byte-containg fields need more resolution, and thus they 
               are now properly set to LENGTH &MXGBYLN. ;               
              -BYTES added to KEEP= list for _VWWWIIS and WWWIIS22 was  
               added to $16 length statement.                           
   Thanks to Andrzej Dabrowski, Computing Services, CSIR, SOUTH AFRICA. 
Change 23.232  NDM dataset NDMPS ('PS'/'SW' records) now has variables  
Sep  1, 2005   both input and kept, if this is an 'SW' subtype.         
              -Missing value messages were eliminated for DATE fields   
               that are known to have missing values; MXG now tests the 
               DATA field before constructing the DHMS function inputs. 
   Thanks to Tom Neurauter, Fidelity Systems, USA.                      
Change 23.231  Support for DB2 IFCID=225 variables                      
VMAC102          QW0225FA QW0225GA QW0225VA QW0225SJ                    
Sep  1, 2005   that report DB2 storage used "Above The Bar".            
   Thanks to Valerie J. Chisholm, Aetna, Inc, USA.                      
Change 23.230  "EXIT-DRIVEN" MXGTMNT Tape Mount Monitor is AVAILABLE!!  
ASMTAPEE       ML-35 should be the FINAL iteration in this major effort 
ASMHSCEX       that replaces the original sampling tape mount monitor   
Sep  1, 2005    (it sampled the tape UCBs every 1/2 second, working just
                 fine for many years of real tape drives, but sampling  
                 now misses many of your very fast VTS tape mounts)     
               with this event driven monitor that instead uses exits to
               capture EVERY tape mount for real drives, silos, and/or  
               VTS devices, whether mounted by IBM or STK software.     
              -What's now available is this enhancement that supports   
               multiple instances of STK's HSC and/or CSC running in the
               same system.                                             
              -The Exit Driven architecture has been available for some 
               time, using the IBM Volume Mount exit for all real tape  
               devices (whether IBM or STK drives), and for IBM VTS.    
               It was the enhancement to use the STK User Exit in their 
               HSC and CSC software, used for STK Silos and STK VTSs,   
               that was extremely difficult to develop, primarily due to
               the complete refusal of STK to provide any technical help
               (i.e., STK wouldn't/couldn't tell in which address space 
               their exit was executed!), so MXG's had to
               figure it all out without assisance from that vendor.    
              -Both ASMTAPEE and ASMHSCEX were updated by this change.  
              -The solution for multiple HSC/CSC is in the new ASMHSCEX,
               which now create two exits, SLSUX01 for HSC, and SCSUX01 
               for CSC, so all you're HSC guru will have to do is to    
               define the appropriate exit to whichever one (or ones)   
               your site is running for your STK Silos and VTSs.        
              -What to do when both are run:                            
               There may be a little extra overhead for those sites that
               run multiple exits on the same system, but that won't    
               affect a site that only runs one exit.  Exit 01 in HSC or
               CSC behave the same; either exit will provide the        
               information we need.  With ML-35, you can run any number 
               of those exits, but now, we'll create only one record per
               tape mount!                                              
               Asmguy's advice when both are running is to pick one,    
               whichever is most likely to be active all the time, and  
               define the exit to it.  If you want to run multiple exits
               on the same SYSTEM, ML-35 will allow this, but there is  
               additional overhead involved.  If you chose to do this,  
               you can just define the exits as you would normally, and 
               no change is required to ASMTAPEE, as it automatically   
               will detect that multiple exits are running, and respond 
              -ML-35 ASMTAPEE is NOT compatible with earlier ASMHSCEX.  
               You must use the ML-35 ASMHSCEX with the ML-35 ASMTAPEE. 
             - ML-35 corrected several old ASM coding exposures found by
               Dick Zieske, mostly dealing with cleanup of CSA when     
               MXGTMNT is cancelled, rather than STOPed, or if MXGTMNT  
               ever ABENDS (which has never happened in production)!    
             - Sampling is still used for Tape Allocation records.      
   Thanks to "" who has figured out how to use the HSC/CSC
              exits in spite of complete lack of help from STK.         
   Thanks to Dick Zieske, AIG, USA.                                     
   Thanks to Steve Martin, Fidelity Systems, USA.                       
   Thanks to Paul Naddeo, FiServ, USA.                                  
   Thanks to Jeff Holst, FiServ, USA.                                   
   Thanks to Normand Poitras, IBM Global Services, CANADA.              
   Thanks to Dan Squillace, SAS Institute Cary, USA.                    
   Thanks to Shirley Fhng, Hong Kong Shanghai Bank, Hong Kong.          
   Thanks to Shane Dowling, DEWR, AUSTRALIA.                            
   Thanks to Scott Chapman, American Electric Power,USA.                
   Thanks to Patricia J. Jones, DST Systems, USA.                       
Change 23.229  Support for DEVTYPE='3592' tape devices.  Observations   
VMACTMS5       were output by MXG for those devices, but variable DEN   
Aug 31, 2005   was not decoded, causing "DENSITY IS MISSING" non-fatal  
               log messages; more important: variable DEVTYPE was blank.
               DEN and DEVTYPE are populated by table lookup in the MXG 
               program, after I find out what hex value CA has chosen.  
   Thanks to Todd Wright, CSC Australia, AUSTRALIA.                     
Change 23.228  INPUT STATEMENT EXCEEDED RECORD error from IBM ATL record
VMACEREP       that had a message shorter than the 96-bytes that MXG had
Aug 31, 2005   hardcoded for the INPUT of ETRMESSG.  Code was revised.  
   Thanks to Steven Clark, DHL, USA.                                    
Change 23.227  The NDMCT dataset contains accumulated NDMCPUTM for multi
TYPENDM        step processes; deaccumulation is always done by MXG in  
VMACNDM        the "_Sdddddd" macro, the "Data Set Sort" macro, so the  
Aug 31, 2005   heuristic logic to sequence and deaccumlate adjacent data
               was added to the _SNDMCT macro.                          
              -The TYPSNDM macro automatically sorts the output, but if 
               you have added processing of NDM data to your BUILDPDB,  
               you should replace your PROC COPY; SELECT NDM:; with the 
               "Product Sort" macro _SNDM in your EXPDBOUT member to    
               sort all of the NDM datasets, and deaccumulate NDMCT.    
              -If you are using ITRM, you only need the _SNDMCT "Dataset
               Sort Macro" in your EXPDBOUT, since ITRM will separately 
               handle the adding of the other NDM datasets to DETAIL.   
              -While the TYPExxxx members normally only write to //WORK,
               when an xxxx product requires deaccumulation, I add the  
               _Sdddddd data set sort macro (s) to the TYPExxxx member  
               to ensure you don't accidentally use the unaccumulated   
               data, so _SNDMCT was added to the TYPENDM member's code. 
   Thanks to Thomas Clark, SEI Investments, USA.                        
Change 23.226  Nearly Cosmetic. MXG deleted STK subtype 4 records that  
VMACSTC        were in error (see Change 23.125), but did not print a   
Aug 30, 2005   message on the log that you were missing that PTF.       
               Now it does advise you that records were deleted.        
   Thanks to Chuck Hopf, MBNA, USA.                                     
Change 23.225  Requesting RUNTRND=DAILY in %BLDSMPDB did not work as    
BLDSMPDB       expected.                                                
Aug 30, 2005                                                            
   Thanks to Tom Kelman, Commerce Bank of Kansas City, USA.             
Change 23.224  Cosmetic corrections found during ITRM dictionary build. 
VMXG70PR      -TYPE70LP: SMF70DSA was not labeled.                      
VMACCMF       -CMF27C93: C2795RFL,C2795RTY "THUS:" removed from label.  
VMACNDM       -NDMRJ:    NDMJOBNM,NDMRJDSN,NDMSYSRC were not labeled.   
VMAC79        -TYPE791/TYPE792: R791NFFI,R792NFFI were not labeled.     
Aug 30, 2005                                                            
   Thanks to Chris Weston, SAS Institute ITRM Cary, USA.                
Change 23.223  Support for Mobius/IPAC Release 6.3 (INCOMPAT, because of
EXIPAC08       changes in the length of IPSPAGE/IPEPAGE fields in the   
IMACIPAC       subtype 1 record).  Other changes in this release:       
VMXGINIT      -Variable IPLOC is now $8; it includes the former reserved
Aug 30, 2005   one following byte.                                      
Aug 31, 2005  -New subtype 8 creates dataset IPAC08, similar to IPAC03. 
              -But, there still is no change in their VERSION field, so 
               the LENGTH of the record must be used to identify the new
               data added to the subtype 1 and 3 records.               
              -And, the vendor documentation for Release 6.3 does not   
               document the SMF records they write:                     
                The REQSTART and REQEND documentation is unchanged, but 
                records show the values are reversed physically, with   
                END first and START last, and the format of their time  
                part still says 0hhmmssF, but the data shows four-byte  
                EBCDIC numeric HHMM value.                              
                The vendor's technical support chose not to compare the 
                hex dump of their defective record we sent, which shows 
                the START field with 2208 and the END field with 2205,  
                but simply replied that their their dsects were the     
                definitive documentation source.                        
               Just in case they ever acknowledge their error, and fix  
               their code so the records match the "definitive" DSECT,  
               MXG code now tests START versus END and reverses their   
               values if necessary.                                     
   Thanks to Erik Janssen, ING Netherlands, THE NETHERLANDS.            
   Thanks to Debby Blackey, HCA Health Care, USA.                       
Change 23.222  Change 23.216 was updated for APAR OA10346; new values   
VMAC7072       in SMF70CIX for "IFA", "IFL", are now used to create new 
Aug 29, 2005   NRIFACPU and NRIFLCPU variables, and the count of those  
               non-"CP" engines is subtracted from variable PARTNCPU.   
               Without this change, PARTNCPU included IFAs and IFLs.    
               MXG variable MXGCIN was also updated with new SMF70CIN.  
               Data from z9 processor was used to validate this change, 
               which also validated Change 23.186, the z9 support.      
Change 23.221  The default example variable names for the TSO workload  
RMFINTRV       was incorrectly/accidentally changed from the historic   
Aug 29, 2005   "TSO" to "TSOP" in the RMFINTRV member in MXG 22.07.     
               The example is now corrected so the TSO variables will   
               start with just the historic "TSO" prefix.  If you have  
               your own tailored RMFINTRV member, it controlls the names
               of the variables, so this change would have no impact.   
               However, if you were using the MXG 22.07-23.07 default,  
               this change could cause your reports to fail, since your 
               reports expect TSOP.... variable names, so your best     
               choice is to copy the RMFINTRV from 22.07-23.07 into your
               tailoring library, and your variables will continue to be
               spelled TSOPxxxx.  I made his reversion because the MXG  
               example reports expect the TSOxxxx variable names.       
   Thanks to Paul N. Ross, Computer Sciences Corporation, USA.          
Change 23.220  MXG logic error caused INPUT STATEMENT EXCEEDED INPUT    
VMAC80A        for a valid SMF 80 record that contained no segments.    
Aug 30, 2005   I noted the "USER IS NOT DEFINED TO RACF" bit was on.    
               Originally I had the customer open a problem with IBM    
               for their "short record" error, because the OFFSET was   
               greater than the LENGTH of the SMF record, but now I am  
               "eating my own words", as the record was completely valid
               and it was an MXG logic error that wasted both IBM's and 
               this MXG Customer's time:                                
                 IBM's response was completely accurate and to the point
                 and completely detailed the offset and locations that  
                 proved the record was completely valid.  It's one of   
                 the best written and complete replies I've seen!       
               I had inserted code in MXG to read in a 4-byte test for  
               a vendor product, but I put the input before the group   
               DO _I_= 1 TO NRSET that input the segments that exist.   
               My input was always executed, even when NRSET=0!         
               That IBM reply recommended the use of the count field,   
               which is now done, but I also test LENLEFT GE 4 to make  
               sure there really are 4 bytes left to be read.           
               The error was overlooked when tested with the vendor SMF 
               because they all had the field, and there were no errors 
               when QA SMF 80s from several sites were read, so the code
               was released in October, 2003.  Since then, billions and 
               bullions of SMF 80 records have been read, and all had   
               one or more segments and no error.                       
               I can live with those odds!                              
   Thanks to Christa Neven, KBC Bankverzekieringsholding, BELGIUM.      
   Thanks to Victor_Van-Cakenberghe,IBM, BELGIUM                        
Change 23.219  The ICF Catalog 05 record variable GATGEN should have    
VMAC6156       been input as &PIB.2., instead of one byte, and variable 
VMACCTLG       GATWRAP='Y' is now set if the first bit of GATGEN is on, 
Aug 29, 2005   to mark that this GDG member has "wrapped"; i.e., its    
               generation number has exceeded 9999.  If GATWRAP is on,  
               GATGEN=GATGEN-32768 to contain the correct Gen number.   
               This discovery was precipitated by IGD07001I ABENDs in   
               production, which occurred when a GDG that had GATWRAP   
               on for some members, and GATWRAP off for others, when    
               that GDG generation number goes from 999 to 1000.        
                 Normally, when all members of a GDG have wrapped, the  
                 next catalog action turns off the wrap bit in all of   
                 the catalog records.  For a "normal" GDG, that should  
                 happen when the +256th gen is created after wrap, as   
                 only 255 members can exist in the catalog.  But this   
                 site had had a very old application that originally    
                 created +1 thru +5 each day, and then deleted +1 thru  
                 +4, leaving only +5 in the catalog.  However, back when
                 Clinton was President, an application change was made  
                 that created only +1 thru +3 and deleted only +1 & +2, 
                 so there were 2 old GooooVoo's left in the catalog.    
                 When the GDG wrapped, and when the create of +1 would  
                 have created G1000V00, those old GooooVoo's still had  
                 their wrap bit off, and the production job failed:     
               IGD07001I; GDG ROLL IN ERROR - RETURN CODE 140 REASON 122
                 Return Code 140:                                       
                   Inconsistent or conflicting arguments were provided. 
                 Reason Code 122:                                       
                   Catalog G1000Vxx will cause the GDG to exceed the    
                   limit of 10,999.                                     
                 Programmer Response:                                   
                   Clean up the GDG in error then catalog G1000Vxx.     
               The site found Information APAR II07276, which explained 
               how wrap works, but it says to 'see the "Z" page for     
               internal details of the wrap bit interface'.             
               So the site asked IBM Support: "We need to identify other
               GDGs that have the same exposure to causing ABENDs.  Can 
               I look at the 'Z' page?  Does the 'wrap bit' appear in   
               SMF 61, 65, 66 ICF Catalog records?"                     
               IBM Level 2 Catalog Support refused to answer the quite  
               valid question, with this answer:                        
                 "Unfortunately, the 'Z' page in our info APARs refer to
                 information meant for IBM eyes only, for helping us get
                 to problem determination quicker.  We are not at       
                 liberty to discuss any control block internals that are
                 not provided in our published manuals.  As for         
                 information in SMF records relating to this, this info 
                 would be included in the updated record portion        
                 of the SMF record, however we cannot discuss offsets   
                 for those either.  I am sorry I cannot be more helpful.
                 Please let me know if there are any other questions    
                 that I can answer for you."                            
               Even escalation to my IBM Poughkeepsie z/OS support did  
               not convince IBM Level 2 Catalog Support to identify     
               which bit is the "GATWRAP" bit.  The ICF Support and     
               Developers hid behind "OCO", Object Code Only, as the    
               reason they could not provide catalog record             
               documentation (but DSECTS are NOT CODE!).                
               So I suggested the site could create a GDG and force it  
               to wrap, and by examining SMF records, we concluded that 
               first bit of GATGEN was the GATWRAP bit.                 
               Then, I remembered I still had lots of archaic printed   
               manuals, and located the very old "MVS/XA Catalog        
               Diagnosis Reference for DFP Release 1.2", which confirmed
               that the GATWRAP bit was indeed the first bit of the     
               GATGEN field in the 05 Catalog Record!                   
   Thanks to Daniel F. Schwarz, Inc, Univ of Wisconsin Hospitals, USA.  
   Thanks to Joseph Stoll, University of Wisconsin Hospitals, USA.      
Change 23.218  Format $MGDB2PT did not have value for 'R'='R:ROLLUP'.   
Aug 23, 2005                                                            
   Thanks to Scott Barry, SBBWorks, Inc, USA.                           
Change 23.217  Typo at line 392 had WEEKBLD instead of _WEEKBLD.        
Aug 23, 2005                                                            
   Thanks to Hugh Lapham, Royal Canadian Mounted Police, CANADA.        
=Attended the 50th Anniversary meeting of SHARE, the world's first      
=computer User Group, in Boston.                                        
Change 23.216  APAR OA10346 was supported by Change 23.187, but it was  
VMAC7072       revised on Aug 18, with these new enhancements:          
VMXG70PR      -TYPE72Y2 dataset, variables CRYIH2R and CRYIH2s created  
Aug 19, 2005   for hashing rate and hashing size for SHA=256.           
              -Tests in VMXG70PR were revised, because SMF70CIN can now 
               contain "IFA", "IFL", "ICF" or "CP" to identify the type 
               of processor.                                            
   Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.  
Change 23.215  While not "hard-coded" DDname, these two statements that 
VMXGRMFI       were inadvertently left in the middle of VMXGRMFI        
Aug 18, 2005     %LET SPININ = SPIN;                                    
                 %LET SPINOUT = SPIN;                                   
               were just as bad as hardcoded, and cause errors if you   
               had changed your SPIN library's DDNAME elsewhere in MXG. 
               Both lines were deleted.                                 
   Thanks to Ken Williams, CPT Global, ENGLAND.                         
   Thanks to Mark Williams, Marks and Spencer, ENGLAND.                 
Change 23.214  Cosmetic.  Label for variable A20E2HWM was corrected to  
VMAC110        now read A20E2HWM='PEAK*CONTENTION*WINNERS'.             
Aug 17, 2005                                                            
   Thanks to Scott Wiig, U.S. Bank, USA.                                
Change 23.213  All SMF88xxx datetime variables were on GMT time zone.   
VMAC88         Now, the GMT88OFF offset is calculated and the variables 
Aug 17, 2005   are all now on the same time zone as SMFTIME.            
   Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.  
Change 23.212  Cosmetic.  Labels for RTSMAP01-RTSMAP14 were clarified to
VMAC7072       'BUCKET nn*RESPONSE TIME*GOAL*PERCENT' because they      
Aug 16, 2005   contain the percentage of R723CVAL, rather than a goal   
               value.  If you want to know the goal value of the nnth   
               bucket, it is RTSMAPnn*R723CVAL.                         
   Thanks to Dave Crandall, Farmers Insurance, USA.                     
Change 23.211  Requesting USERADD=6 25 26J3 21 30, INCLAFTR=BUIL3001    
UTILBLDP       generated a MACRO _WTY26J2 _LTY26J2; statement which     
Aug 16, 2005   should have been MACRO _WTY26J3 _LTY26J3 % statement.    
   Thanks to Hansruedi Zaugg, EDS, SWITZERLAND.                         
Change 23.210  MXG 23.07 only. Typo of CURRSHARE in the DROP statement  
VMXG70PR       should have been CURSHARE. Fortunately, there was no real
Aug 16, 2005   impact on any of the expected variables, just that the   
               variable CURSHARE was unnecessarily kept.  The typo did  
               cause an error when MXG ran under V6, because the 9-byte 
               variable name exceeded SAS V6 limits.  MXG variables are 
               normally also 8-bytes-max; our QA tests for name length, 
               but only for kept variables, and since CURRSHARE was a   
               typo that didn't exist in a KEEP= statement, this typo   
               was missed.                                              
                 Note: I thought this was fixed in the final 23.07, by  
                 Change 23.208, but I typo'd the typo, and MXG 23.07    
                 had CURRSHAR instead of CURSHARE, so the problem was   
                 not corrected until MXG 23.08.                         
   Thanks to Jon Whitcomb, Great Lakes Higher Education Corporation, USA
====== Changes thru 23.209 were in MXG 23.07 dated Aug 10, 2005=========
Change 23.209  Not sure why, but the includes of VMAC7072,VMAC6,IMACKEEP
ASUMPRTR       inside ASUMPRTR cause it to fail when it was INCLUDed in 
Aug 10, 2005   EXPDBOUT in BUILDPDB to create the PDB.TYPE6ENH dataset. 
               Removing those three members from the %INCLUDE statement 
               in ASUMPRTR eliminated the ERROR: OLD-STYLE MACRO NAME   
               Those members only need to be included when SMF data is  
               read, and that JCL example in the comments has the needed
               %INCLUDE statement, so the %INCLUDE for them in ASUMPRTR 
               was redundant, anyhow.                                   
   Thanks to Keith McWhorter, Georgia Technology Authority, USA.        
Change 23.208  Replaced by Change 23.210.                               
====== Changes thru 23.207 were in MXG 23.07 dated Aug  9, 2005=========
Change 23.207  Variables IAMNOA and IAMNOP have traded places; they were
VMACIAM        coded as documented, but the documentation was wrong.    
Aug  9, 2005   Aug 10: it was IAMNOD and IAMNOP that traded places.     
Aug 10, 2005                                                            
   Thanks to Ken Wantuch, BB&T IT Systems Engineering, USA.             
Change 23.206  Line 2704 contained a semicolon after SMFPSRVR, but that 
ANALCISH       should have been a comma.  Only caused error if CFEC FEPI
Aug  9, 2005   Connection Statistics report was requested.              
   Thanks to Scott Wiig, U.S. Bank, USA.                                
Change 23.205 -Variables LPnNSW/SMF70NSW, percent when LPAR was capped, 
EXCECTIM       were wrong in PDB.ASUMCEC/ASUM70LP/ASUM70PR and could    
VMXG70PR       even be greater than 100%.  Weighted average had wrongly 
Aug  9, 2005   used LPARDUR instead of SMF70DSA.  Logic revised.        
Aug 10, 2005  -LP1LAC was always missing in PDB.ASUM70LP because of a   
Nov 10, 2005   typo that had SMF71LAC instead of SMF70LAC.              
              -LPnLAC was often missing in PDB.ASUMCEC because logic to 
               select the first LPARNUM in each CECSER has been wrong.  
               Variable PCTMVSBY is populated only in "this system" obs 
               in TYPE70PR dataset, so adding DESCENDING PCTMVSBY to the
               end of the sort order that creates CECCLEAN forces that  
               "this system" observation to be the one that is kept.    
              -The optional EXCECTIM member is reinstated in VMXG70PR   
               to change STARTIME in PDB.ASUMCEC, PDB.ASUM70PR, and in  
               PDB.ASUM70LP datasets to the exact nearest minute for the
               summarized output's STARTIME value; observations with    
               slight differences caused duplicate or semi-duplicate    
               output. Nov 10: this paragraph revised; originally, it   
               said only PDB.ASUMCEC's STARTIME was changed.   But, now,
               you also need Change 23.289 for full short-interval fix. 
              -Aug 10 enhancement:  VMXG70PR logic (ASUM70PR) now adds  
               variable LPARNSW, percent when this LPAR was capped, to  
               the PDB.RMFINTRV dataset, so your system-level analysis  
               will contain LPAR capping.                               
   Thanks to Chuck Hopf, MBNA, USA.                                     
Change 23.204  Documentation only.  Change 23.021 correctly populated   
ASUM70PR       the "PHYSICAL" LPAR's data in LP0xxxxx variables, so the 
Aug  9, 2005   total MSU, summed across all LPARs, from PDB.ASUMCEC,    
               will be slightly larger than the MSUs from versions prior
               to MXG 23.01.                                            
               Oct 31, 2005: See Change 23.276.                         
   Thanks to Huch Lapham, Royal Canadian Mounted Police, CANADA.        
Change 23.203  Change 23.143 did not correctly handle the length 8 data 
VMACMPLX       fields, and MXG's INPUT did not match the MPLX DSECT.    
Aug  9, 2005                                                            
   Thanks to David Bixler, FISERV, USA.                                 
Change 23.202 -Variables KW21GL01-KW21GL05 are no longer created nor    
VMAC80A        nor kept in dataset TYPE8021, as the RDEFINE command does
Aug  8, 2005   not contain the GLAUFLGS field.                          
Aug 30, 2005  -Variables CLASNAM1-CLASNAM4 are now created in TYPE8024  
               to support up to 5 class names.                          
              -Support for SMF80DTP (43) for SETROPTS GENLIST/NOGENLIST 
               and enhancement for (42) for SETROPTS RACLIST/NORACLIST; 
               up to five class names (CLASNAME,CLASNAM2-CLASNAM5) are  
               now kept from either 42 or 43 RACFTYPE entry.            
                 This assumes that the SETROPTS record contains either  
                 a (42) or a (43) segment, but not both.  My test data  
                 had no event 24 records so I could not validate that   
                 assumption.  If wrong, then new variable names will be 
                 needed and this text will be revised.                  
                -Aug 30: tests for NR44SEGS should be NR42SEGS in the   
                 WHEN (42) logic; caused job to fail.                   
   Thanks to Adam Thorn, Euroclear, BELGIUM.                            
   Thanks to Aimee Steel, Euroclear, BELGIUM.                           
   Thanks to Bill Arrowsmith, Euroclear, BELGIUM.                       
Change 23.201  Condition Code (Return Code) 4 in ASUMTALO eliminated.   
ASUMTALO       The LENGTH statement in ASUMTALO specified DEVICE $8, but
Aug  8, 2005   the actual length of DEVICE is only $7; both the LENGTH  
               entry and the (redundant) "Compiler Faker" statement were
               revised to make DEVICE only seven characters long.       
               The message appears when SPIN.SPINTALO exists, i.e., only
               on the second or later execution of ASUMTALO, but it had 
               no impact, other than setting the condition code.        
              -After years of seeing those spurious LENGTH OF CHARACTER 
               VARIABLE HAS ALREADY BEEN SET messages, when there was no
               change in the length (before SAS fixed the message so it 
               now only prints when the lengths are different), this is 
               the first time that message actually uncovered an error! 
                 Note: The message text suggests that putting the LENGTH
                 statement ahead of the SET statement will eliminate the
                 message; however, that is not acceptable because if the
                 LENGTH statement precedes the SET statement, then this 
                 DATA step could inadvertently truncate the kept length 
                 of a variable, but there would be no warning message.  
                 Instead, MXG puts the LENGTH statement after the SET   
                 statement so that any mismatch will be detected.       
   Thanks to Mike Allen, Pacific Corp., USA.                            
Change 23.200  Support for MegaCrytion's user SMF record creates:       
EXMGCRCR         dddddd    dataset   description                        
TYPEMGCR       The start and stop datetimestamps MGCRSTRT/MGCREND are   
TYPSMGCR       on the GMT clock, and there is no GMT Offset in the      
VMACMGCR       record that could safely be used to infer the zone,      
VMXGINIT       until the vendor adds the GMTOFFSET field to the record. 
Aug  4, 2005                                                            
   Thanks to John Rivera, i-structure, USA.                             
Change 23.199  Support for TPF Continuous Data Collection, TPFCDC, which
EXTPFC80       is a new data source for TPF and creates many datasets:  
EXTPFC81         dddddd   dataset  description                  typetype
EXTPFC82         TPFC80   TPFC80   SYSTEM MESSAGES                  80X 
EXTPFC83         TPFC81   TPFC81   SYSTEM LISTS                     81X 
EXTPFC84         TPFC82   TPFC82   SYSTEM BLOCKS                    82X 
EXTPFC85         TPFC83   TPFC83   DASD/POOLS                       83X 
EXTPFC86         TPFC84   TPFC84   DASD DEVICES                     84X 
EXTPFC87         TPFC85   TPFC85   SYSTEM VFA                       85X 
EXTPFC88         TPFC86   TPFC86   SUBSYSTEM VFA                    86X 
EXTPFC89         TPFC87   TPFC87   MPIF                             87X 
EXTPFC8A         TPFC88   TPFC88   TAPE                             88X 
EXTPFC8B         TPFC89   TPFC89   TCP/IP                           89X 
EXTPFC8C         TPFC8A   TPFC8A   I-STREAM                         8AX 
EXTPFC8D         TPFC8B   TPFC8B   SUBYSTEM MESSAGES                8BX 
EXTPFC8E         TPFC8C   TPFC8C   SUBSYSTEM USER                   8CX 
EXTPFC8F         TPFC8D   TPFC8D   LODIC                            8DX 
EXTPFC90         TPFC8E   TPFC8E   MQ SUMMARY                       8EX 
EXTPFC91         TPFC8F   TPFC8F   MQ QUEUE DETAIL                  8FX 
EXTPFC93         TPFC90   TPFC90   MQ CHANNEL DETAIL                90X 
EXTPFC94         TPFC91   TPFC91   USER DATA                        91X 
IMACTPFC         TPFC93   TPFC93   CDC RECORD                       93X 
TYPETPFC         TPFC94   TPFC94   STATIC SYSTEM INFO               94X 
TYPSTPFC       TPFCDC "records" have a '93'x segment with total length  
UTILTPFC       the number of segments that follow in that record, and   
VMACTPFC       then those segments, which can have repeated entries,    
VMXGINIT       and each of which contains its own-length field, follow. 
Aug  3, 2005  -MXG creates an observation in each of the above datasets 
Aug 19, 2005   for each instance of each segment.                       
              -But the TPF creation splits these logical records into   
               multiple physical "tape" records that are most definitely
               NOT standard variable length records, and that cannot be 
               directly read.  The first 4095 bytes of data start the   
               first physical record, but TPF adds a 16-byte trailer    
               segment, creating a 4111-data-byte (4115 LRECL) variable 
               length first-record.  The remaining bytes of the logical 
               record start in the first byte of the second "tape"      
               record, which is padded with nulls thru data byte 4095,  
               and to which the TPF 16-byte trailer is added at the end.
              -Because of this non-standard record format, you will have
               to pass the TPFCDC data file twice: first, with the MXG's
               UTILTPFC program, which will read those split records and
               create a legitimate VBS record for each split record, and
               then second, that output file is processed by TYPETPFC to
               create the preceding 20 TPFCDC datasets.                 
                 Note: UTILTPFC is heuristic based on the sample data,  
                       and it reads a pair of records for each event.   
                       It will need revision if your TPF data length    
                       causes more than two split records to be needed. 
              -Product Problems Reported to IBM:                        
                1. Their complicated split process is not working; one  
                   byte of data is lost from the segment that is split! 
                   In my test data that was always the '87'x segment,   
                   so MXG resets that segment's length, but that only   
                   works if the '87' is the segment across the split.   
                   MXG will be revised when IBM corrects their error.   
                   Oct 28 Update:  IBM APAR PJ30503 corrects the one    
                   byte loss error.                                     
                2. Two fields in the '90'x segment have blanks instead  
                   of binary numeric values.  Aug 19 update: IBM says   
                   the two fields (TPFCBTSZ, TPFCSZLB) do not apply when
                   the MQ Channel Type is SERVER (TPFCCTYP='V'); MXG now
                   sets those two variables missing when TPFCCTYP='V'.  
              -Product exposure:                                        
               Several character fields have field lengths that can be  
               changed by the TPF installation; MXG code expects these  
               lengths for those fields; other lengths cause errors:    
                    Length Field Name       Length     MXG Variable     
                  CDC_SS_NAME_LEN              4      TPFCSSNA,TPFCSS   
                  CDC_SSU_NAME_LEN             4      TPFCSSUN,TPFCSSU  
                  MQ_Q_MGR_NAME_LENGTH        48      TPFCQMGR          
                  MQ_Q_NAME_LENGTH            48      TPFCQNAM          
                  MQ_Q_CHANNEL_NAME_LENGTH    20      TPFCCHAN          
   Thanks to Luis R. Vega-Zayas, IBM TPF, USA.                          
Change 23.198  Support for existing NT objects with fewer data fields   
Aug  4, 2005   DATABASE==>INSTANCES with NRDATA=92, and MSEXCHANGE IS   
               with NRDATA=110) than MXG code expected.  Those objects  
               records were deleted prior to this change.               
   Thanks to Paul Billick, Harleysville Insurance, USA.                 
Change 23.197  The hardcoded "SPIN" DD in PROC COPY IN=SPIN OUT=&PDBMXG 
BUILD005       in BUILD005/BUIL3005 was changed to &SPINOUT so the new  
BUIL3005       SPIN datasets will be backed up from the correct DD.     
Aug  4, 2005   If the &SPINOUT was different than "SPIN", you could get 
               a VARIABLE NOT FOUND error when SPUNJOBS executed.       
   Thanks to Ken Williams, CPT Global, ENGLAND.                         
   Thanks to Mark Williams, Marks and Spencer, ENGLAND.                 
Change 23.196 -Support for CA SAR/VIEW R11,they INCOMPATIBLY CHANGED the
FORMATS        SMF records, increasing these variables to $EBDCID32:    
Aug  3, 2005     SV31DIST,SV31BNDL,SV32RID,SV33RID,SV34RID              
               and by increasing SV33LTM to PIB4.  The test for SARR    
               Version got messy; SMFVPRL is now '11.0' but it used to  
               be '2.0 ', so instead of IF SMFVPRL GE '11.0' THEN....,  
               each test was more complicated:                          
                IF INPUT(SCAN(SMFVPRL,1,'.'),5.) GE 11 THEN ....        
              -Format MGSARTY new value '10:DOC VIEW WEB' for Interface 
               Type was added.                                          
   Thanks to Mark Schrager, Metropolitan Life, USA.                     
Change 23.195  Line fifteen had an end comment but no start comment,    
GRAFTALO       which caused the %MACRO statement to never be read.      
Aug  3, 2005                                                            
   Thanks to Ep van der Es, Dow Chemicals, THE NETHERLANDS.             
Change 23.194 -Missing value messages for DB2RDWTM when testing IMACEXCL
UTILEXCL       built by UTILEXCL found DB2RDYTM had been misspelled as  
Aug  2, 2005   DB2RDWTM, which does not exist.  Value of DB2RDYTM was   
               incorrect by a factor of 16 due to that typo.            
              -Calculation of SEGLEFT for optional segments was only    
               correct for the first segment; fortunately, it appears   
               to have had no impact; using SEGSTRT instead of LOC in   
               each calculation corrects the exposure.                  
   Thanks to Normand Poitras, IBM Global Services, CANADA.              
Change 23.193  Support for TNG AIX new object CA PROCESS GROUP (PID)    
EXTAI025       creates new MXG AI025 dataset.  New variables are added  
FORMATS        to datasets AI018 (CA KERNEL GROUP), AI020 (CA NETWORK   
VMACTNG        GROUP), and AI016, (CA INTERFACE GROUP).                 
Aug  2, 2005                                                            
   Thanks to Dale Gilbert, AhYum, USA.                                  
Change 23.192  Variable NDMUID in dataset NDMRJ (Run Job) was truncated 
VMACNDM        to 8 bytes, instead of being input as $EBCDIC64., because
Jul 30, 2005   the test for that input did not contain 'RJ'.            
Aug 10, 2005  -Aug 10: additional variables are now read in from 'RJ'.  
   Thanks to Tom Neurauter, Fidelity Systems, USA.                      
Change 23.191  Cosmetic.  Invocation of VMXGSUM had "ANALCACH" instead  
ASUMCACH       of "ASUMCACH" for the printed message text.              
Jul 30, 2005                                                            
   Thanks to Chuck Hopf, MBNA, USA.                                     
Change 23.190  Comments only.  IMACICDA is not used if IMACEXCL controls
IMACICDA       the input for a CICS APPLID/REGION.  When IMACEXCL is    
Jul 27, 2005   used, it controls the INPUTing of the optional CICS data 
               segments.  Only when there is no IMACEXCL, or IMACEXCL   
               does not protect an APPLID, does IMACICDA control the    
               order of the optional CICS data segments MXG expects.    
   Thanks to Normad Poitras, IBM Global Services, CANADA.               
Change 23.189  The example should have had //DAY DD instead of //PDB DD,
PDBCPYDY       to copy from the "TODAY" PDB library just created by the 
ACHAP35        BUILDPDB program, into the day-of-week PDB library. I use
Jul 21, 2005   //PDB in the "build", but //DAY thereafter to refer to   
               the "today" PDB library.                                 
   Thanks to Jeff Harder, Farm Bureau Insurance, USA.                   
Change 23.188  Variable R744QFLG should have been defined LENGTH $1, but
VMAC74         ended up as CHAR 34 because it's formatted $MG074QF which
Jul 20, 2005   set the kept length as the longest text in that format.  
               This variable was not caught by Change 23.170 because it 
               does NOT appear in an INPUT statement, which was expected
               in our original QA analysis program, but that report has 
               been revised to catch any other similar syntax issues.   
   Thanks to Travis Hicks, IBM GS (Telstra Account), AUSTRALIA.         
Change 23.187  Support for APAR OA10346 adds the LPAR's User Partition  
VMAC7072       Identifier (UPID, the value you specified on your HMC    
Jul 20, 2005   Customize Image Profile) to RMF 70 PR/SM section for each
               LPAR, as variable SMF70UPI in TYPE70PR dataset.          
               As was reported in MXG Newsletter 46, APAR II13668 said  
               that after z990s, LPARNUM (SMF70LPN) was no longer a     
               static identifier, but instead is now a system generated 
               number of the alphabetical location of the LPAR name, and
               the LPARNUM of an LPAR changes when you add/delete LPARs.
               But now, IBM has accepted Edward Williams suggestion and 
               added the new SMF70UPI variable to TYPE70PR dataset.     
               MXG code                                                 
                 If you want to use SMF70UPI in your reporting, please  
                 send me some SMF 70 records (see member SENDDATA) after
                 you have the APAR installed, so we can decide how to   
                 add SMF70UPI to the ASUM70PR and ASUM70LP datasets, and
                 so I can validate those changes.                       
   Thanks to Edward Williams, BMC, USA.                                 
Change 23.186  Support for new CPUTYPE '2094'x for the z9 processors;   
VMAC7072       this is an INCOMPATIBLE change: without this change, your
VMXGRMFI       TYPE70PR dataset will contain extra observations for     
Jul 20, 2005   nonexistent LCPUADDR, and incorrect data values.         
Aug 29, 2005  -The exposure in VMXGRMFI for RMFINTRV is minimal; the    
               CPUTYPE test is used only for OS/390 or very early z/OS  
               that did not have SMF70WLA or SMF70LAC populated, and it 
               is used only to create CECSUSEC, CPCNRCPU, CPCFNAME and  
               CPCMSU variable's values from table lookups.             
              -In VMAC7072 there are several CPUTYPE tests with impact: 
                It is used to set SMF70ONT missing when it is zero for  
                some cases, which affects counting of CPU engines, and  
                which is used to identify spare engines so they are not 
                output in PDB.TYPE70PR; without this change, extra and  
                spurious observations are created in PDB.TYPE70PR.      
                It is also used to populate SMF70CPA for OS/390 and     
                early z/OS before SMF70CPA was added to the SMF record. 
   Thanks to Patricia Hansen, ADP, USA.                                 
Change 23.185  Roscoe creation of PDB.ROSCOE didn't work when UTILBLDP  
VMACROSC       was used to create the sysin stream to add ROSCOE to PDB.
Jul 19, 2005   Most "DIF" members invoke the _Sdddddd macro for that    
               dataset with accumulated data, but ROSCOE is unique and  
               is now revised, so that DIFFROSC is included when _SROSC 
               is invoked, and all of the datasets that are processed in
               DIFFROSC no longer have their _Sdddddd sort macro invoked
               in the revised _SROSC macro.  And, the ROSCOE datasets   
               that are merged into PDB.ROSCOE are no longer kept.      
   Thanks to Jeff Harder, Farm Bureau Insurance, USA.                   
Change 23.184  Optional new %LET MXGABND=nnnn;  enhancement can be used 
VMXGINIT       to make MXG fail with a USER ABEND nnnn, instead of just 
VMAC110        printing error messages on the SAS log.  This option is  
VMXGRMFI       whether or not you want the job to USER ABEND nnnn.      
Jul 19, 2005                                                            
Oct 19, 2005  -To enable the new MXGABND enhancement, you would insert: 
                 %LET MXGABND= 333;                                     
               as your first SYSIN statement, and if any of the below   
               errors occur, your MXG job will USER ABEND 333.          
              -The default value for MXGABND is 0000, for NO ABEND.  You
               must use a value between 0001 and 4095 for nnnn.         
                  Actually, you can use a larger value for nnnn, but the
                  ABEND code you see will be MOD(ABEND,4096) so using   
                  nnnn=4096 resulted in USER ABEND U0000,               
                  nnnn=8000 resulted in USER ABEND U3904, and           
                  nnnn=9999 resulted in USER ABEND U1807.               
               The option is only available for these specific errors:  
              -SMF type 110 CICS record processing (Jul 19, 2005):      
                 ***ERROR.TYPE110.CICS/ESA 3.1.0. EXCLUDED FIELDS HAVE  
                  BEEN DETECTED. YOU MUST RUN UTILEXCL.                 
                  RECORD WAS DELETED. CICSTRAN DATA WAS LOST.           
                 ***ERROR.VMAC110 STRTTIME HAS MISSING VALUES and       
                     Those errors means that your CICS records have     
                     changed or that you have excluded data and you must
                     run the UTILEXCL program to create IMACEXCL and to 
                     tailor the IMACICxx's that you may also need to    
                     EDIT to properly read the data.  But, as the       
                     message was only printed in the middle of the SAS  
                     log of the daily job, which can be kilothousands of
                     lines of text, they requested a new option that    
                     would let them choose to cause the MXG job to ABEND
                     for these CICS errors that delete data, in addition
                     to the error message (which will now be the last   
                     thing printed on the log!!).                       
              -RMFINTRV creation (Oct 19,2005):                         
                 ***ERROR.RMFINTRV.CPUTM IS MISSING.                    
                     The CPUTM variable from TYPE72GO dataset is missing
                     which can be caused by incorrect tailoring in your 
                     EXTY72GO exit member.                              
                This change will be updated if other error messages are 
                added to this enhancement.                              
   Thanks to Mike Perry, Morgan Stanley, USA.                           
   Thanks to Min-che Li, Morgan Stanley, USA.                           
Change 23.183  Support for APAR OA11036, which adds MACHTIME to SMF 89  
VMAC89         and variables SMF89HOF and SMF89DTO values.              
Jul 18, 2005                                                            
   Thanks to Al Sherkow, I/S Management Strategies, Ltd., USA.          
Change 23.182  Test of LENCPUC GE 24 should have been GE 64 to input the
VMAC7072       SMF70HWM and SMF70HOF fields in support for APAR OA11375.
Jul 18, 2005                                                            
   Thanks to Al Sherkow, I/S Management Strategies, Ltd., USA.          
Change 23.181 -DB2ACCTP, Package Data, was still wrong for new DB2 V8.1 
VMACDB2        IFCID=239 record with LENQPAC=0 and more than one package
Jul 17, 2005   segment.  The INPUTed LENQPAC at the beginning of each of
Aug 12, 2008   those segments does not include its own length, so a new 
               LENxxxx=LENxxxx+2;  statement had to be added to each of 
               of the adjustment DO groups invoked when LENxxxx=0.  The 
               text of Change 23.140 was revised to show new statement. 
              -For DB2 V7.1 and later, variables QBACxxxx and QTXAxxxx  
               are always missing in DB2ACCTP package data; those       
               variables only have values in the DB2ACCT dataset.       
               MXG logic for the IFCID=0003 record prior to V7.1 had    
               incorrectly input the QBAC and QTXA fields before the    
               loop across each of the OFFQPAC segments.  Re-locating   
               the QPAC segment to be processed before the other        
               segments now correctly causes those sets of variables to 
               be always  missing in DB2ACCTP.                          
                 Note: the text in this paragraph was completely wrong  
                       prior to Aug, 2008, but the QBACxxxx,QTXAxxxx    
                       variables have ALWAYS been missing values i      
                       the DB2ACCTP dataset, in spite of that text,     
                       now revised.                                     
              -It was noted that in the DB2 V8.1 DB2ACCTP IFCID=239 data
               that QWACBSC and QWACESC are both missing, making it less
               easy to match the DB2ACCTP back to it's DB2ACCT obs.     
              -Missing value calculation for QGBAXN eliminated, but that
               variable is now always missing; instead, use QBGAEX.     
   Thanks to Victoria Lepack, Aetna, USA.                               
Change 23.180  DATETIME logic had incorrect word numbers for the SCAN of
VMACPRPR       YYYY and SS, now corrected.                              
Jul  8, 2005                                                            
   Thanks to Christa Neven, KBC Bankverzekieringsholding, BELGIUM.      
Change 23.179  Variables VSRNBYTR and VSRNBYTW in dataset HSMVSRFU were 
VMACHSM        way too small, as their value in the record was in KB but
Jul  8, 2005   their label indicated bytes.  They are now multiplied by 
Jul 11, 2005   1024 to convert their value to bytes, and are formatted  
               with MGBYTES format to "print pretty".  These variables  
                  FSRTBYTW DSRBYTR  DSRBYTW                             
               that contain bytes in both their values and labels are   
               now also formatted with MGBYTES for consistency.         
               However, these storage-value variables:                  
                  DSRNGBR ='GIGABYTES*READ'                             
                  DSRNGBW ='GIGABYTES*WRITTEN'                          
                  VSRTOTKB='TOTAL*CAPACITY*OF VOLUME (IN KB)'           
               are NOT converted to bytes, and are NOT formatted MGBYTES
               because they agree with their labels, and changing their 
               internal value to bytes could impact existing reports.   
               Life is filled with compromises when you don't make the  
               correct first choice!                                    
   Thanks to Robert Chavez, Office Depot, Inc, USA.                     
   Thanks to Chuck Hopf, MBNA, USA.                                     
Change 23.178  Variable PARTISHN was not labeled in dataset TYPE73, so  
VMAC73         it was also unlabeled in dataset TYPE73OE.               
Jul  8, 2005                                                            
   Thanks to Chuck Hopf, MBNA, USA.                                     
Change 23.177  ML-34 of ASMTAPEE and the HSC exit are production status!
ASMHSCEX       Beta Tests with the new HSC exit uncovered some minor    
VMACTMNT       errors that are now corrected, but the exit works fine to
Jul  3, 2005   capture all HSC-controlled tape mounts, just like the IBM
Jul 11, 2005   Volume Mount Exit, previously implemented in ML-34, works
               to capture all IBM-controlled tape mounts.  Sampling is  
               no longer used to detect tape mounts, so none are missed.
               As currently implemented, ASMHSCEX supports only a single
               HSC or CSC, but now that we are aware that both products 
               and even multiple copies of HSC and/or CSC can exist, we 
               are investigating how to support those environments, and 
               will have a revised ASMHSCEX for those installations.    
              -Primary correction was in ASMHSCEX, which populated the  
               JOB file with the JCTJOBID value instead of JOB name.    
              -But because JCTJOBID=JOB, the MXG logic to create JESNR  
               from the JCTJOBID caused JESNR to be missing:            
                 JOB=JCTJOBID is a valid condition for "early ASID" STCs
                 the don't have a "JESNR".                              
              -And beta tests exposed MXG errors in VMACTMNT that caused
               INITTIME and PROCSTEP to be missing/blank.               
              -With this Change, ML-34 is now ready for production use. 
   Thanks to Steve Martin, Fidelity Systems, USA.                       
====== Changes thru 23.176 were in MXG 23.06 dated Jun 29, 2005=========
Change 23.176 -Support for SMF 6 ESS GEPARMKY='04D'x with more than one 
IMAC6ESS       segment creates ESSMAIL3 and ESSMAIL4 variables.  Caused 
VMAC6          INPUT STATEMENT EXCEEDED error.                          
Jun 29, 2005  -Support for SMF 6 ESS GEPARMKY='04B'x creates ESSMFILE.  
              -Support for SMF 6 ESS GEPARMKY='04E'x creates ESSRPLY2.  
   Thanks to Engelbert Smets, Provinzial, GERMANY                       
   Thanks to Cornelia Opel, Provinzial, GERMANY                         
Change 23.175  Support for SMF 22 Subtype 11 I/O Configuration Change   
EXTY22UA       creates new dataset:                                     
IMAC22           dddddd   Dataset   Description                         
VMAC22           TY22UA   TYPE22_A  I/O Configuration Change            
Jun 28, 2005                                                            
   Thanks to Shane Dowling, DEWR, AUSTRALIA.                            
Change 23.174  Change 18.338 created the _Vdddddd macro definitions, but
VMACMVCI       not all MXG code members have been revised to create that
Jun 27, 2005   token.  This change creates _VMVCICS and _VMVCICF in the 
               VMACMVCI member.                                         
   Thanks to David Edge, Thomson BETA Systems, USA.                     
Change 23.173  Using TYPEHSM, datasets HSMWWFSR and HSMWWVSR were not   
DIFFHSM        sorted into the //PDB library, because TYPEHSM included  
Jun 24, 2005   the DIFFHSM member, which had separate _Sdddddd sorts    
               for each dataset, but DIFFHSM had not been updated to add
               sorts for those two datasets.  Using TYPSHSM, those data 
               were sorted into the //PDB, because it invoked the _SHSM 
               product sort macro, which does list all HSM datasets.    
               The DIFFHSM member is revised to use the _SHSM member.   
                 Normally, TYPExxxx members leave all of their datasets 
                 in the //WORK file, while the TYPSxxxx members sort all
                 of the xxxx products datasets into the //PDB library.  
                 But when there are accumulated data in the product, the
                 TYPExxxx member always will invoke the sort into //PDB 
                 to de-accumulate that dataset, and HSM writes SMF data 
                 with accumulated values, so both TYPEHSM and TYPSHSM   
                 now produce identical results.                         
   Thanks to Ian Arnett, TD Canada Trust, CANADA.                       
   Thanks to Luc Audet, TD Canada Trust, CANADA                         
Change 23.172 -SAMS POOLS record was INCOMPATIBLY CHANGED in 002053V4 by
VMACSAMS       increasing NRVOLS field from 4 to 6 bytes, causing all of
Jun 24, 2005   the variables to the right to have wrong values. With the
Jul 20, 2005   help of CA Technical Support to provide the DSECTS of the
Jul 30, 2005   SMF record, MXG code for POOLS was corrected and revised:
              -The SAMS Version is used, rather than the circumvention  
               to test LRECL, to detect the longer NRVOLS field.        
              -Data in SAMSFBYX/TBYX/VBYX/LBYX were wrong because those 
               four fields are packed decimal, not binary values, and   
               MXG was using the incorrect informat for them.           
              -New in 002053V4 variables SAMSPALL & SAMSBALL are input. 
              -New in 002053V5 variables SAMSESA/ESB/ESC describe the   
               storage group in three lines of text.                    
              -Support for 002053V6 was revised and valided Jul 30; the 
               V6 record's POOLS record was completely restructured.    
              -Variable SAMSJOBN was removed from the KEEP= and LABEL   
               statements, as there is no "JOB" name field in SAMS SMF. 
   Thanks to Abily Christelle, GICM, FRANCE.                            
   Thanks to Patrick Notteghem, CA, FRANCE.                             
Change 23.171 -Variable LOCLINFO is INPUT $EBCDIC8, which works fine if 
VMAC30         SMF30UID contains text or hex characters on z/OS, but if 
Jun 24, 2005   executed on ASCII, that INPUT statement changes any hex  
               characters.  The only solution for ASCII execution is to 
               create a second variable, LOCLINCH, INPUT as $CHAR8 and  
               FORMATed $HEX16. so any non-text characters in that field
               are preserved, and available in the EXTY30Un exits.      
              -Missing value calculations when SMF30IST was missing were
               eliminated; SMF30IST only exists in subtype 2, 3, and 6. 
   Thanks to Sudie Wulfert-Schickedanz, Anheuser-Busch, USA.            
Change 23.170  Character Variables formatted with $MGdddxx formats that 
VMAC102        were NOT in a LENGTH $1 statement were stored in LENGTH  
VMAC110        of the maximum text in the $MGdddxx format values, which 
VMAC74         wasted disk space.  Now, all character variables with $MG
VMAC84         format names have been identified, and added to a LENGTH 
VMAC85         statement if needed to reduce their stored length.       
VMACAIM6       VMAC74:   R744QFLG                                       
VMACBE91       VMAC84:   JMFJSJSR                                       
VMACBE97       VMAC85:   R85ODT   R85OVT   R85TVT                       
VMACCIAO       VMAC92:   SMF92MFG SMF92UFG                              
VMACEDGR       VMACAIM6: IOCTYPE                                        
VMACFTP        VMACBE91: BE91STP                                        
VMACHIOM       VMACBE97: B970OBT                                        
VMACHURN       VMACCIAO: CIAOETYP                                       
VMACNSPY       VMACEDGR: RDVRSTYP RRTYPE2  RSTYPE2                      
VMACOMSM       VMACHIOM: HIOOSTYP                                       
VMACQACS       VMACHURN: HU62UMOD HU62UTYP                              
VMACSAR        VMACNSPY: NSPYRTPS                                       
VMACSPMS       VMACOMSM: OMDEVMDL                                       
VMACTIE        VMACSAR:  SARPMDX                                        
Jun 20, 2005   VMACSARX: GCRPMDX                                        
Jul 21, 2005   VMACSPMS: SPMSRLS                                        
               VMACSYSV: TRANTYPE                                       
               VMACTIE:  TIELOG                                         
   Thanks to Freddie Arie, Merrill Consultants, USA.                    
Change 23.169  Support for additional SMF 99 Subtype 2 data segments.   
EXTY99Q2      -These variables added to TYPE99_2 dataset:               
EXTY99R2          PCADP   ='CURR*ACHIEAVABLE*DEMAND*PCT'                
EXTY99V2          PGRIN   ='GROUP*NAME'                                 
FORMATS           PIFAD   ='IFA*DELAY*SAMPLES'                          
IMAC99            PIFAU   ='IFA*USING*SAMPLES'                          
VMAC99            PIFLAG  ='FLAGS'                                      
VMXGINIT          PSAMHST ='SAMPLE*HISTORY*ROWS*USED'                   
Jun 22, 2005      PSBCPUD ='SAMPLE*BASED*CPU*DELAYS'                    
                  PSBCPUU ='SAMPLE*BASED*CPU*USINGS'                    
                  PSBIOD  ='SAMPLE*BASED*I/O*DELAYS'                    
                  PSBNIOD ='SYSPLEX*WIDE*NON I/O*DELAYS'                
                  PSPMDP  ='MINPCT*PROCTIME*DEMANDED'                   
                  PSWCPUU ='SYSPLEX*WIDE*CPU USING*SAMPS'               
                  PSWCT   ='SHORT*WAIT COUNT*ACCUMULATE'                
                  PSWIDLE ='SYSPLEX*WIDE*WIDE IDLE*SAMPS'               
                  PSWNONI ='SYSPLEX*WIDE*NON-IDLE*SAMPS*                
                  PSWOTHR ='SYSPLEX*WIDE*OTHER*SAMPS'                   
              -New datasets are created from subtype 2 segments:        
                  dddddd  Dataset   Description                         
                  TY99R2  TYPE99R2  99-2-Q REMOTE QUEUE DATA            
                  TY99Q2  TYPE99Q2  99-2-Q QUEUE SERVER DATA            
                  TY99S2  TYPE99S2  99-2-S SERVER SAMPLE DATA           
                  TY99V2  TYPE99V2  99-2-V SERVER DATA                  
   Thanks to Chuck Hopf, MBNA, USA.                                     
Change 23.168  Cosmetic.  Blanks in SMF6TARG (IP Address) are removed.  
Jun 21, 2005                                                            
   Thanks to Thomas Peiper, Tietoenator, SWEDEN.                        
Change 23.167  The Installation Data field, INSTDATA, was inconsistently
VMACRACF       input as $200 with +55, or $40 with +215, and variables  
Jun 21, 2005   OMVSHOME, OMVSPROG, USRDATA, and APPLDATA did not input  
               their full $255 byte field.  The $200 was the SAS V6     
               limit for character variables, but I've been reluctant to
               change those inputs to $255, because that would cause an 
               avoidable ABEND with V6, and besides, is there really    
               anything in those last 55 bytes that is needed?  However,
               since this RACF Unload utility code didn't exist when SAS
               V6 was The Thing for MXG years ago, I've chosen to       
               increase all these variables to input and be stored as   
               $255, and hope no V6 sites try to use this support!  Some
               MXG members are already documented as requiring SAS V8   
               (like records with UCS data, for example), but the few   
               sites that I know are still on V6 are not their by their 
               own choice, so I'll try to protect the really important  
               SMF records, until a real need arises.                   
   Thanks to Len Rugen, State of Missouri, USA.                         
Change 23.166 -Fields were added to CMRFILE, probably Version 5.6, but  
VMACMVCI       there is no length-of-file-segment field in the CMRDETL  
Jun 21, 2005   record, so the new fields were overlooked, causing trash 
               values in the second and subsequent file segments in each
               CMRDETL record with more than one file segment.          
               New variables are created and kept in CMRFILE dataset:   
                 T6EF1='RNU*COUNT'    T6EF2='RPU*COUNT'                 
                 T6EF3='RWD*COUNT'    T6EF4='REDSET*COUNT'              
                 T6EF5='RDUSET*COUNT' T6EF6='RNXSET*COUNT'              
                 T6EF7='RPVSET*COUNT' T6EF8='RNUSET*COUNT'              
                 T6EF9='RPUSET*COUNT' T6ET1='RNU*TIME'                  
                 T6ET2='RPU*TIME'     T6ET3='RWD*TIME'                  
                 T6ET4='REDSET*TIME'  T6ET5='RDUSET*TIME'               
                 T6ET6='RNXSET*TIME'  T6ET7='RPVSET*TIME'               
                 T6ET8='RNUSET*TIME'  T6ET9='RPUSET*TIME'               
                 T6ETA='READ*TIME'    T6ETB='RDU*TIME'                  
                 T6ETD='WRT*TIME'     T6ETE='RWT*TIME'                  
                 T6ETG='DEL*TIME'     T6ETH='UNK*TIME'                  
                 T6ETJ='SBR*TIME'     T6ETK='RNX*TIME'                  
                 T6ETL='RPV*TIME'     T6ETM='EBR*TIME'                  
                 T6ETO='RBR*TIME'     T6ETP='OTH*TIME'                  
                 T6ETQ='FCTOT*COUNT'  T6ETR='FCTOT*TIME'                
                 T6ETS='FCWAIT*COUNT' T6ESR='SRECS*COUNT'               
              -T6EV1,T6EV2,T6EV3 are protected for hex zeros for Volume 
               Serial Numbers; T6EV3 contains hex values in byte 4 that 
               are changed to blanks by MXG.                            
              -Variable TFILI was kept as $27, because it was assigned  
               the $MGMVICT format without also being set to the $1     
               length in a LENGTH statement. Variables that are assigned
               an MXG-built character format will have the length of the
               longest value statement, if their length is not fixed in 
               a LENGTH statement; this was overlooked, but we'll add a 
               new report to detect any other cases of wasted space.    
              -Variable SYSTEM was always blank; it was only populated  
               in Version 5.3 records, but now it is populated from the 
               T6ESMFID SMF TYPE field.                                 
              -These variables are now set to blank if they contained   
               hex zeros:                                               
                 T6EBMSN T6ECMP53 T6EOPID T6EPSBN T6ERPTCL T6ETMID      
                 T6EAUTH T6ECORR                                        
              -However, when T6EBMSN starts with "CSMI" in EBDCIC4., the
               last four bytes are non-printable ('1C796A00'x) which may
               be trash left over, or may be actual "data" for the BMS  
               Map Name.  I've chosen to detect these and store only the
               "CSMI    " back in T6EBMSN, and have stored the last four
               hex bytes in new variable T6ECSMI until we have an answer
               from the vendor as to why that field has mixed EBCDIC and
               HEX when it starts with the mirror transaction name CSMI.
   Thanks to David Edge, Thomson BETA Systems, USA.                     
Change 23.165  New MGFMTVR identifies which MXG Version's FORMATS member
FORMATS        was used to create the format library pointed to by the  
Jun 21, 2005   //LIBRARY (or LIBRARY LIBREF).  Using this program       
                  DATA _NULL_; FMTVERS=.; PUT FMTVERS MGFMTVR. ;        
               will print, on the SAS Log:                              
   Thanks to Ron Alterman, Pacific Gas and Electric, USA.               
Change 23.164  Additions in WAS Version 6.01, support for PQ96114 and   
FORMATS        MXG errors are corrected:                                
VMAC120       -MQ Series variable SM120CSO has new values of 5 and 6:   
Jun 21, 2005   now decoded by the MG120CO format:                       
                  5:HTTP SESSION and                                    
                  6:HTTP ENCRYPTED SESSION                              
              -MQ Series variable SM120JB3 has overlooked values 4,5 and
               a new value of 6 now decoded by MG1203B format:          
                  4='4:BMP ENTITY BEAN'                                 
                  5='5:CMP ENTITY BEAN'                                 
                  6='6:MESSAGE DRIVEN BEAN'                             
              -Variables SM120JHF and SM120JHT are now correctly input  
               as &PIB.8 instead of &PIB.4.  JHF was always zero, and   
               JHT contained the value of JHF when they were wrong.     
   Thanks to Martyn Jones, Euroclear, BELGIUM.                          
   Thanks to Phil Downes, Euroclear, BELGIUM.                           
Change 23.163  INVALID ARGUMENT FOR INPUT FUNCTION because SyncSort has 
VMACSYNC       a new and unexpected value of 'SMS' for ths UCB Address. 
Jun 18, 2005   'SMS' is now tested to circumvent the error message.     
   Thanks to Jim Dammeyer, State Farm Insurance, USA.                   
Change 23.162  ML-34 of MXG Tape Mount Monitor provides ASMHSCEX member 
ASMHSCEX       that you assemble to create an HSC SLSUX01 user exit that
ASMTAPEE       your HSC guru then installs in HSC, so that all of the   
Jun 15, 2005   HSC-controlled mounts (STK VTS or STK Silos) will be     
Jun 22, 2005   captured by exit (event-driven), instead of by sampling. 
                 (Sampling, even at .5 seconds missed a lot of the very 
                  fast VTS mounts; using an exit captures 100% of them.)
               The STKX option tells MXGTMNT to use the HSC exit, like  
               the MXIT option in ML-31 used the IBM Volume Mount Exit; 
               the difference is that you have to install the HSC exit, 
               while IBM's exit was already there!  With MXIT and STKX  
               enabled, all mounts to real drives, all IBM VTS mounts,  
               and (finally!) all HSC-controlled mounts are captured!   
               The SLSUX01 exit, created by assembly of the ASMHSCEX,   
               itself can be used in one of two ways, depending on your 
               site's current use of the STK HSC exit, and you control  
               which way via the SYSPARM input during assembly.  If your
               site does not currently use the STK HSC exit, SYSPARM(N),
               which is the default, results in just the MXG replacement
               exit code being assembled.  But if your site does use the
               HSC exit, specifying SYSPARM(Y) at assembly of ASMHSCEX  
               will cause MXG code to include your existing exit code   
               during the link edit step that creates the exit module.  
               Then, when MXG's exit is subsequently defined to HSC, our
               exit will invoke your exit as if we weren't there, then  
               we'll do our thing to collect the necessary data and pass
               that to the TMNT address space.  This is well documented 
               in the ASMHSCEX comments, but please let us know if the  
               instructions need clarification or improvement.          
               You can assemble ASMTAPEE member to create the MXGTMNT   
               program load module before you assemble ASMHSCEX to      
               create the MXG SLSUX01 HSC exit, or vice versa; there is 
               no forced order for installation, and enablement of      
               MXGTMNT can occur in any order.                          
               The implementation of the MXG HSC Exit is quite robust:  
                - it is essentially a NOP if it detects MXGTMNT is not  
                  enabled or is not running, or, conversely,            
                - if MXGTMNT is enabled, but the exit is not there, the 
                  environment exists to support the exit, but nothing   
                  will happen until the exit is running.                
               We believe HSC 5.1 and HSC 6.0 versions are supported,   
               based on STK documentation; it might also work with 5.0, 
               but we don't have enought information from STK to confirm
               if that is true, and, besides, 5.0 is archaic!           
               You can only specify STKX=YES at assembly or start-up of 
               the monitor; you cannot start the monitor and then use   
               a command to turn on STKX later; that might be added in  
               the future, but it would have delayed delivery of this   
               We have Alpha tested this code as thoroughly as we can,  
               and we have NEVER caused a system outage with any ML of  
               the monitor, but since we don't have a Silo or VTS on our
               test system, we ask that you ONLY test ML-34 on an HSC   
               test system that can afford to be "crashed", before you  
               use it on an real system.  When we have more feedback    
               from Beta test sites, this text will be revised to       
               confirm successful tests at real sites.                  
            a. Jun 22 update:                                           
              -First test of the HSC Exit did not succeed but it did no 
               harm: on the first mount after initializing the monitor  
               and exit, the user exit ABENDed with S978, and then it   
               disabled itself; tape mount processing then proceeded as 
               usual without the exit. examined the dump
               and the listing of the assembly of the HSC exit and      
               corrected a "dumb mistake, bad branch" error in ASMHSCEX,
               now dated Jun 22, 2005.                                  
              -An IBM-only site raised three question,:                 
               1. Why do I get STKX=NO in the monitor output while I    
                  have 'OPTIONS2 DC AL1(DOARCV+DOMXIT+DOSTKX) in the    
                  assembler code:                                       
                 asmguy answer ==>                                      
                  Because I forgot to add code to change the STKX=NO to 
                  STKX=YES if the code is modified to turn this on      
                  instead of using input parms.  This is a tough one for
                  me to remember since it's counter to the way I think  
                  and I always use parms when I test so I don't catch   
                  these things.  Anyway, I'll correct it.               
               2. What does 'MXGC003I MXG STK MOUNT EXIT MONITORING     
                  ENABLED' mean?                                        
                 asmguy answer ==>                                      
                  This is a message that indicates the environment      
                  necessary to support the STK exit has been enabled in 
                  MXGTMNT as a result of STKX=YES.                      
               3. Do I need XMem at all?                                
                 Barry's answer ==>                                     
                  XMEM is still needed to get the job-related fields in 
                  the TYPETALO allocation records, at least for now, as 
                  they are independent of the mount records.  But I plan
                  to examine if I need to revise ASUMTAPE to use the new
                  exit-driven mount records to populate TYPETALO info,  
                  once we've got the monitor working and I've got some  
                  SMF data from a site with both IBM and HSC mounts.    
            b. Jun 24 update:                                           
              -For HSC, you may need to create exit SCSUX01 instead or  
               in addition to the SLSUX01 exit, depending on the HSC    
               interface your site uses.  SCSUX01 is required if CSC is 
               used for remote access to the robot and VSMs, which may  
               be all that's available on your test system.  SLSUX01 is 
               used for local access.   Changing all SLSUX01 to SCSUX01 
               in ASMHSCEX and reassembling worked just fine, but we can
               create a new SYSPARM option for ASMHSCEX that will create
               both HSC and CSC exits in the same member.               
            c. Jun 28 update:                                           
               No errors have been reported by two sites successfully   
               using ML-34 and the new HSC exit.  I'm awaiting test data
               to update the ASUMTAPE program, but that won't happen    
               until late July, after some vacation time.               
   Thanks to "".                                          
   Thanks to Paul Naddeo, FiServ, USA.                                  
   Thanks to Jeff Holst, FiServ, USA.                                   
   Thanks to Normand Poitras, IBM Global Services, CANADA.              
Change 23.161  Comments said PDB.TYPE73OE dataset would be created, but 
ANALFIOE       the code created WORK.TYPE73OE; this change creates the  
Jun 15, 2005   old style MACRO _LANFIOE PDB.TYPE73OE % so the default   
               dataset will be PDB.TYPE73OE, but also so that you could 
               change the DD or Dataset name using MACKEEP/IMACKEEP.    
   Thanks to Chuck Hopf, MBNA, USA.                                     
Change 23.160  New variables added to T102S106 dataset:                 
VMAC102        QWO4ADM2='OFF*SYSTEM*ADMIN ID2'                          
Jun 14, 2005   QWO4DFID='OFF*SYSTEM*DEFAULT*USER ID.'                   
               QWO4OPR1='OFF*MVS*OPERATOR ID'                           
               QWO4OPR2='OFF*MVS*OPERATOR ID2'                          
               QWO4REGA='OFF*DDL REG*ART NAME'                          
               QWO4REGC='OFF*DDL REG*TABLE OWNER'                       
               QWO4REGO='OFF*DDL REG*ORT NAME'                          
               QWP4DSMX='MAXIMUM*NUMBER OF*DATASETS'                    
               QWP4EDBC='EDM*POOL*DBD*CACHE SIZE'                       
               QWP4ESTC='EDM*POOL*STATEMENT*CACHE SIZE'                 
               QWP4LEM ='MAXIMUM*NUMBER OF*LE TOKENS'                   
               QWP4MDEG='MAX DEGREE*OF PARALLELISM'                     
               QWP4MXNC='MAX*CURSORS*OPEN PER*THREAD'                   
               QWP4MXSP='MAX*ACTIVE*STORED PROCS*PER THREAD'            
               QWP4NPAG='NPAGES*THRESHOLD*FOR OPTIMIZER'                
               QWP4PDIX='PAD INDEXES BY DEFAULT?'                       
               QWP4RAC ='ROUTINE*AUTHORIZATION*CACHE SIZE'              
               QWP4SJXP='MAX SIZE*MEMORY POOL*FOR STARJOIN'             
               QWP4EDMX='EDM POOL MAX DATA SPACE SIZE'                  
               QWP4EDDS='EDM POOL DATA SPACE SIZE'                      
   Thanks to Ron Alterman, Pacific Gas and Electric, USA.               
Change 23.159  Yet another INPUT STATEMENT EXCEEDED RECORD for PSF SMF 6
VMAC6          record with SMF6LN6=24 (See Changes 23.091, 22.309).     
Jun 13, 2005   The logic for SUBS=7 and SMF6LN6=24 was revised based on 
               the current SMF manual so that when SMF6LN6=24, there is 
               no longer an attempt to input SMF6PRTQ name, since there 
               cannot be roome for a name field when SMF6LN6=24.        
   Thanks to Diane Eppestine, Southwestern Bell, USA.                   
Change 23.158  MXG RMF-like reports printed whole numbers for AVG RESP  
ANALRMFR       TIME and AVG IOSQ TIME but IBM reports now print one     
Jun 13, 2005   decimal place, so MXG format was changed to match.       
   Thanks to Bob Anders, McMaster-Carr Supply Co., USA.                 
Change 23.157  SMF file might not have been found, depending on use of  
BLDSMPDB       SMFIN= argument, and whether FILENAME SMF existed.  The  
Jun 10, 2005   &SMF was changed to FILENAME SMF "&SMFIN"; to correct.   
   Thanks to Joe Key, BOC Gasses, ENGLAND                               
   Thanks to Alex DaSilva, BOC Gasses, ENGLAND                          
Change 23.156  ASUMUOWT had incorrect syntax for _LMONTSK definition.   
ASUMUOWT       Two periods are required.                                
Jun  9, 2005                                                            
   Thanks to Chris Weston, SAS Institute Cary, USA.                     
Change 23.155 -First 23.05 only; incorrect syntax for default options in
ASMTAPEE       "OPTIONS  DC" statement, with a comma instead of plus.   
Jun  9, 2005  -One site with ASM option CASE as their default had to use
               ASM option COMPAT(NOCASE) because ASMTAPEE contains both 
               upper and lower case text, for readability.              
   Thanks to Dan Squillace, SAS Institute Cary, USA.                    
   Thanks to Shirley Fhng, Hong Kong Shanghai Bank, Hong Kong.          
====== Changes thru 23.154 were in MXG 23.05 dated Jun  7, 2005=========
Change 23.154  First 23.05 only.  Line 3138 extended into column 3138.  
ASMTAPEE       Comments clarified.                                      
Jun  7, 2005                                                            
   Thanks to Dan Squillace, SAS Institute Cary, USA.                    
Change 23.153 -Utility to read SMF to count IDs and Subtypes did not    
VMXGGETM       count ID=102 correctly, when run on ASCII platform; those
Jun  7, 2005   PIB4. and PIB2. should have been &PIB.4. and &PIB.2. so  
               that the code was transparently portable across all SAS  
               platforms.  With PIB4. on ASCII, extremely large values  
               were created, which caused the ID=102 sub-logic to never 
               be executed, so all ID=102 had SUBTYPE=0 on ASCII.       
              -The realization that I had not checked ALL MXG members to
               be transparently portable cause me to search and find    
               these members with either PIB instead of &PIB., or with  
               $ instead of $CHAR or $EBCDIC; all are now corrected:    
                 XTYPEMVT XTYPEVS1                                      
               Fortunately, all are pretty obscure, non-mainstream code,
               or someone would have certainly noticed the incorrect    
               data values if they were exected on ASCII platforms.     
   Thanks to Alfred Holtz, Medco Health Solutions, USA.                 
Change 23.152  First MXG 23.05 Only. Debug PUTs at lines 2147 and 2148: 
Jun  7, 2005        TOKENID= TOKFIELD= TOKFIELD= $HEX16.;               
               printed unneeded lines of text on the SAS log.           
   Thanks to Lawrence Jermyn, Fidelity Systems, USA.                    
Change 23.151  MXG 23.03-First 23.05. Debug PUT statement at line 1425  
VMACNDM          PUT _N_= COL= NDMPNODE= NDMSNODE= ;                    
Jun  6, 2005   printed unneeded lines of text on the SAS log.           
   Thanks to Michael Creech, Fidelity Information Systems, USA.         
   Thanks to David Kaplan, DTCC, USA.                                   
Change 23.150  First MXG 23.05 only.  VARIABLE NOT FOUND ERROR due to   
ASUMMIPS       typo:  BY RPPTCLAS ... should be BY RPRTCLAS ....        
Jun  6, 2005                                                            
   Thanks to Pat Curren, Supervalu Inc, USA.                            
Change 23.149  Cosmetic.  Examples of defining start and end of SHIFTs  
IMACSHFT       was clarified to make it easier for neophytes to change  
Jun  6, 2005   the values to define their installation's shifts.        
====== Changes thru 23.148 were in MXG 23.05 dated Jun  5, 2005=========
Change 23.148  General cleanup and revision to QA job stream:           
ANALVM        -Uninitialized xxxIFE and xxxIFA in RMFINTRV corrected.   
QASAS         -Specific reference to VMPDB removed in ANALVM, test of   
TESTANAL       ANALVM removed from TESTANAL as it was tested in TESTVM. 
TRNDNTIN      -QASAS code revised to PROC DELETE all LIBREFs.           
TRNDPRTR       set built in TRNDPRTR.                                   
VMXGRMFI      -TRNDNTIN,TRNDNTLD revised to use only &Pdddddd, and      
Jun  5, 2005   eliminated the confusing _L macro definitions.           
   Thanks to Freddie Arie, Merrill Consultants, USA.                    
   Thanks to Bruce Widlund, Merrill Consultants, USA.                   
Change 23.147  The response time buckets for the PDB.CICS dataset that  
ASUMCICS       is built by ASUMCICX from PDB.ASUMUOW dataset (which is  
ASUMCICT       the recommended way to measure CICS response with MRO),  
ASUMCICX         (or for the PDB.CICS dataset that can be built by the  
VMXGINIT         not-recommended ASUMCICS/ASUMCICT members from CICS    
Jun  3, 2005     transaction segments in datasets CICSTRAN/MONITASK)    
               are defined as macro variables but they could not be     
               overridden without tailoring the ASUM member.  Now, the  
               macro variables are externally defined in VMXGINIT, and  
               can be overridden in your //SYSIN DD *, before your      
               %INCLUDED SOURCLIB(ASUMCICx); statement.  The default    
               values remain unchanged:                                 
                 %LET SUCIVAL1=1;                                       
                 %LET SUCIVAL2=2;                                       
                 %LET SUCIVAL3=3;                                       
                 %LET SUCIVAL4=4;                                       
                 %LET SUCIVAL5=5;                                       
                 %LET SUCIVAL6=8;                                       
                 %LET SUCIVAL7=10;                                      
                 %LET SUCIINTV=HOUR;                                    
   Thanks to Frank Lund, EDB, NORWAY.                                   
Change 23.146  Support for new subtype 70 "FTP Server Security Section" 
FORMATS        adds these variables to TYP11970 dataset.                
Jun  1, 2005     FSPSCIPH='CIPHER*SPECIFICATION'                        
               and new formats were created to decode four of them.     
   Thanks to Randy Shumate, LexisNexis, USA.                            
Change 23.145  The sample RMF III report had typos; ASISUPR should have 
ZRBRPT3        been spelled ASISUCPR, and ASISCDOP should be ASISCDQP.  
Jun  1, 2005                                                            
   Thanks to Mike Obrien, Bank of America, USA.                         
Change 23.144  The "expanded length" format values introduced for TNG in
FORMATS        Change 23.113 were most definitely non-trivial to code.  
May 31, 2005   Initially, PROC FORMAT on ASCII SAS V9.1.3 ran without an
               error, but values were not-found if a spanned-line had a 
               blank in column 72; those lines were then shifted right  
               so column 72 was non-blank, and values were then found.  
               But on z/OS V8.2, the new code failed to execute, with an
               error 22-322 which underlined the equal sign on a line   
               that had 72 characters.  Meanwhile, the new code executed
               without error on z/OS 9.1.3, AND all values were found,  
               even for the spanned-text lines!                         
               Noting that the V8.2 execution errors were on lines that 
               were exactly 72 positions, the code was revised to delete
               a blank on the left of the '=' where possible, or the    
               line was split at the equal sign, and now the PROC FORMAT
               executed without the 22-322 error on V8.2 on z/OS.       
               But now, values were not-found for spanned-text lines on 
               z/OS V8.2, while they were found on z/OS V9.1.3!   This  
               problem had been opened with SAS Technical Support, and  
               their tests suggested that OPTIONS S2 might be involved, 
               as they could replicate the error when OPTIONS S2=71 was 
               used.  Our real breakthrough was to compare execution on 
               z/OS V8.2 using %INCLUDE, versus copying the code into   
               the //SYSIN DD * and submitting the code; the instream   
               test had no errors AND properly found all values, while  
               the %INCLUDE-built format had values not-found!          
               More tests proved that the PROC FORMAT execution on z/OS 
               requires S2=72, while PROC FORMAT under ASCII requires   
               S2=0, so the end result is that member FORMATS now tests 
               its execution platform and sets S2=72 for PROC FORMAT on 
               EBDCIC, but sets OPTION S2=0 when executed on ASCII.     
                 For z/OS, MXG's CONFIGV8 member has always had S2-72,  
                 but two of the test sites were using SAS default S2=0, 
                 which was known only in hindsight!  MXG's CONFIGV9 for 
                 z/OS has S2=0 (as extensively discussed in CHANGES; see
                 "Major Enhancements in MXG 22.08" and Newsletter 45),  
                 but the AUTOEXEC for ASCII execution does not specify  
                 either S= nor S2= option, so the S2=0 option on ASCII  
                 accounts for my early tests not failing in execution.  
                 This problem is still open at SAS, to understand what  
                 is the righteous way to code formats that have values  
                 that won't fit on one line, but the revised FORMATS    
                 member now appears to work on all platforms with the   
                 internal setting of S2 above.                          
Change 23.143  IMPLEX subtype 4 record's IMPLEXRT dataset did not have  
VMACMPLX       all of the possible variables kept, and the deaccumulate 
May 31, 2005   logic was incomplete, causing zero observations in the   
               PDB.IMPLEXRT dataset; groups of the new variables will be
               missing, as they are only input for specific values of   
               the EXMFRTYP variable.  Some of the MXG tests for other  
               DIF()'d variables that were missing the "LT 0" for their 
               final test are now corrected.                            
   Thanks to David Bixler, FISERV, USA.                                 
Change 23.142  Support for Oce's Prisma Print log file creates these    
EXPR1000       forty-five new datasets:                                 
EXPR1011          DDDDDD   MXG       MXG                                
EXPR1012          DATASET  DATASET   DATASET                            
EXPR1020          SUFFIX   NAME      LABEL                              
EXPR1031          PR1000   PRPR1000  PR1000:INPUT FILTER                
EXPR1032         *PR1010   PRPR1010  PR1010:PRINT JOB MANAGER JOB       
EXPR1040         *PR1011   PRPR1011  PR1011:PRINT JOB MANAGER FILE      
EXPR1041         *PR1012   PRPR1012  PR1012:ODS                         
EXPR1042         *PR1020   PRPR1020  PR1020:UI-MANAGER                  
EXPR1043         *PR1030   PRPR1030  PR1030:SPOOL PARAMETER READ        
EXPR1110         *PR1031   PRPR1031  PR1031:JOB FINISHED OR DELETED     
EXPR1120         *PR1032   PRPR1032  PR1032:USER DATA                   
EXPR1130         *PR1040   PRPR1040  PR1040:SNIPDS BACKEND              
EXPR1140         *PR1041   PRPR1041  PR1041:BINS USED                   
EXPR1200         *PR1042   PRPR1042  PR1042:INPUT BIN USED              
EXPR1201         *PR1043   PRPR1043  PR1043:OUTPUT BIN USED             
EXPR1202         *PR1110   PRPR1110  PR1110:HOST DOWNLOADED             
EXPR1400          PR1120   PRPR1120  PR1120:LP TRANSMISSION             
EXPR1410          PR1130   PRPR1130  PR1130:HOT DIRECTORY PRINT JOB     
EXPR1411          PR1140   PRPR1140  PR1140:LU 6.2 PRINT JOB            
EXPR1412          PR1200   PRPR1200  PR1200:XFILTER LCDS REPORT INFO    
EXPR1413          PR1201   PRPR1201  PR1201:XFILTER LCDS ADDITIONAL     
EXPR1420          PR1202   PRPR1202  PR1202:XFILTER LCDS MORE ADDITI    
EXPR1421          PR1400   PRPR1400  PR1400:B1 START SUBSYSTEM          
EXPR1422          PR1410   PRPR1410  PR1410:E1 VOLUME HANDLING          
EXPR1423          PR1411   PRPR1411  PR1411:F5 HDR1 HANDLING            
EXPR1424          PR1412   PRPR1412  PR1412:F6 HDR2 HANDLING            
EXPR1425          PR1413   PRPR1413  PR1413:F7 HDR3 HANDLING            
EXPR1426          PR1420   PRPR1420  PR1420:N5 PARAMETER SECTION 1      
EXPR1430          PR1421   PRPR1421  PR1421:N6 PARAMETER SECTION 2      
EXPR1451          PR1422   PRPR1422  PR1422:N7 PARAMETER SECTION 3      
EXPR1452          PR1423   PRPR1423  PR1423:P4 PARAMETER SECTION 4      
EXPR1453          PR1424   PRPR1424  PR1424:P5 PARAMETER SECTION 5      
EXPR1454          PR1425   PRPR1425  PR1425:P6 PARAMETER SECTION 6      
EXPR1455          PR1426   PRPR1426  PR1426:P7 PARAMETER SECTION 7      
EXPR1456          PR1430   PRPR1430  PR1430:PRINTING RUN                
EXPR1457          PR1451   PRPR1451  PR1451:U1 USER SPECIFIC            
EXPR1458          PR1452   PRPR1452  PR1452:U2 USER SPECIFIC            
EXPR1459          PR1453   PRPR1453  PR1453:U3 USER SPECIFIC            
EXPR1600          PR1454   PRPR1454  PR1454:U4 USER SPECIFIC            
EXPR1601          PR1455   PRPR1455  PR1455:U5 USER SPECIFIC            
EXPR1602          PR1456   PRPR1456  PR1456:U6 USER SPECIFIC            
EXPR1603          PR1457   PRPR1457  PR1457:U7 USER SPECIFIC            
FORMATS           PR1458   PRPR1458  PR1458:U8 USER SPECIFIC            
IMACPRPR          PR1459   PRPR1459  PR1459:U9 USER SPECIFIC            
TYPEPRPR          PR1600   PRPR1600  PR1600:FTP BACKEND                 
TYPSPRPR         *PR1601   PRPR1601  PR1601:FTP JOB FINISHED            
May 30, 2005   All of the datasets are created, but only those fifteen  
               asterisk-flagged datases have been decoded and validated 
               with test data records; all others have only one variable
               kept.  As there are multiple records for a single job, it
               may be necessary to post-process these data to combine to
               get job totals, so this is preliminary support.          
   Thanks to Krista Neven, KBC Bankverzekeringsholding, BELGIUM.        
Change 23.141  Enhancement adds MIPFACTR= as a parameter to convert MSU 
GRAFWRKX       to MIPS, added graph of MIPS used, supported LPARSHAR as 
May 30, 2005   a percentage to fix the LPAR percentages.                
   Thanks to Chuck Hopf, MBNA, USA.                                     
Change 23.140  DB2 Version 8.1 Support: More IBM INCOMPATIBLE changes.  
VMACDB2        Errors INVALID DATA FOR QLACCPUR, QLACCPnt, causing      
Jul 17, 2005   Change 23.111 discovered that DB2 8.1 sets QPACLEN=zero  
               to indicate that the real QPACLEN is in the first 2 bytes
               at OFFQPAC, but when a QLACLEN=0 segment caused errors,  
               I realized this "feature" apparently can apply to all DB2
               segments, so VMACDB2 was revised to test each segment for
               LENxxxx=0 and NRxxxx non-zero, with this inserted code   
                  IF LENxxxx EQ 0 AND NRxxxx GT 0 THEN DO;              
                    INPUT @OFFxxxx LENxxxx &PIB.2. @;                   
                    LENxxxx=LENxxxx+2;    <<= See Change 23.182         
               to pick up the new LEN and modify the OFFSET.            
              -Note: The LENQLAC=0 SMF records did NOT produce that same
               INVALID DATA message when those records were read by SAS 
               under Windows; instead, the misaligned RB8. fields were  
               input as very large negative numbers, but there was no   
               error message, and I had not used PROC MEANS to see that 
               that invalid values existed in the output dataset. This  
               is one of few real differences in executing MXG on ASCII 
               platforms; ASCII is more tolerant of bad data than z/OS! 
              -Change 23.181 updated this text and is required for V8.1.
   Thanks to Ingvar Rosenberg, SEB, SWEDEN.                             
   Thanks to Glenn Lundgren, SEB, SWEDEN.                               
Change 23.139  Support for CyberFusion user SMF record has been revised,
FORMATS        now that DSECTS that match the data records have been    
VMACCYFU       received.  All of the bit mapped fields are now decoded  
May 29, 2005   by 43 new MGCYFxx formats, although there are a few cases
               where the hex value is not described in the DSECT EQU's, 
               so some final tweaking will be required.                 
   Thanks to Robin Murray, ManuLife, CANADA.                            
Change 23.138  Cosmetic.  Labels for SMF88SC1/2/3 are clarified to read:
ADOC88           SMF88SC1='TYPE 1*COMPLETIONS'                          
VMAC88           SMF88SC2='TYPE 2*COMPLETIONS'                          
May 30, 2005     SMF88SC3='TYPE 3*COMPLETIONS'                          
               and the explanation from the SMF manual Section  
               was added in the ADOC88 member for those three variables.
   Thanks to Helmut Rose, COM Software, GERMANY.                        
Change 23.137  Support for CA SYSVIEW CICS XPFCMCR DSECT user SMF data  
EXSYSVCI       record creates these new datasets:                       
EXSYSVPC      -Subtype 17: Documented in XPFCMRC, creates these data:   
EXSYSVFC         dataset   dddddd   description                         
TYPSSYSV       The SYSVCICS dataset is the same in structure as CICSTRAN
VMACSYSV       and almost all of the variable names are also the same,  
VMXGINIT       although not all of the (newer) CICSTRAN fields exist in 
May 29, 2005   the SYSVCICS dataset, and there are a few CICSTRAN vars  
               that are output instead in SYSVPROG,SYSVFILE or SYSVTEMP.
               There are additional segments in the SYSVIEW subtype=17  
               record, but they were not populated in the test data, so 
               only the subtypes that could be validated were decoded in
               this initial support.  If data from the other segments is
               really needed, updates will be made to this support.     
              -Subtype 23: Documented in XPFCSDCR, creates this data:   
                  dataset   dddddd  description                         
               In a radical departure from previous MXG code, the names 
               of the variables in SYSVINTV are longer than 8-bytes. The
               DSECT names are repeated inside structured names, and to 
               compact the names and avoid duplicates would have taken  
               more time that it was worth, at least for this first pass
               as support for the SYSVIEW product, and especially for   
               this SYSVINT dataset, neither of which I expect will have
               very much usage. I think long names, in general, are more
               confusing than useful, so if it turns out that SYSVINTV  
               is of significant value, I'll revisit and compact the MXG
               variable names.                                          
                - The DOCVER member will still only show the first eight
                  characters of the variable names, as that format is   
                  limited so the format and label fit on one line.  You 
                  can always use a PROC CONTENTS to see the full name of
                  each variable in SYSINTV.                             
   Thanks to James D. Lieser, United Health Group, USA.                 
Change 23.136 -Updates to BMC CMF "240" USER SMF record:                
VMACCMF       -New variables in CMF27C93 and CMF27CSC for 2105's:       
May 26, 2005     C276RCRM='RECORD*CACHE*READ*MISSES'                    
                 C276LRED='LOC RCD*DMN/REC*CA*WRITES'                   
                 C2795AID='DEVICE ADAPTER ID'                           
                 C2795HDD='NO. OF HDD'S IN RAID RANK'                   
                 C2795HSS='HDD sector size'                             
                 C2795NVS='NVS space allocation'                        
                 C2795RFL='FLAGS BYTE, THUS:'                           
                 C2795RID='RAID RANK ID'                                
                 C2795RMR='record mode read requests'                   
                 C2795RRQ='RAID rank read requests'                     
                 C2795RRT='RAID RANK READ RESPONSE TIME'                
                 C2795RTY='RAID RANK TYPE, THUS:'                       
                 C2795SR ='RAID rank FB sectors read'                   
                 C2795SW ='RAID rank FB sectors written'                
                 C2795TSP='TRACKS TRANSFERRED TO PPRC VO'               
                 C2795WRQ='RAID rank write requests'                    
                 C2795WRT='RAID RANK WRITE RESPONSE TIME'               
                 C2795XCW='XRC or CC contaminated writes'               
                 C2795XSF='XRC or CC sidefile read requests'            
   Thanks to John Kington, Convergys, USA.                              
   Thanks to Dr. H. Pat Artis, Performance Associates, USA.             
Change 23.135 -Top Secret Version 5.2 and 5.3 are now supported, simply 
VMAC80A        by expanding the test for RACFVRSN to include 52x,53x.   
May 26, 2005  -Top Secret creates its own user record with SMF80DTP=114,
               but that record is really in SMF 80 format, so the user  
               SMF record can be processed with MXG TYPE80A code, using:
                 //SMF DD                                               
                 //SYSIN DD *                                           
                  %LET MACFILE=  %QUOTE ( IF ID=231 THEN ID=80; ) ;     
                  %INCLUDE SOURCLIB(TYPS80A);                           
               to change the (example) ID=231 records back to ID=80 so  
               they are processed by TYPE80 code.                       
              -The SMF80DTP=114 record is not yet decoded, so the above 
               code will only output the RACF header variables into the 
               TYPE80CM dataset; when documentation from CA is received,
               the DTP=114 record will be decoded.                      
   Thanks to Brent Turner, CitiGroup, USA.                              
Change 23.134 -RACF Extended TP2=301 with TOK80LN2=0 was not expected,  
VMAC80A        so it generated an error message on the SAS log stating  
May 26, 2005   the record was deleted, but now, a valid TP2=301 segment 
               only TOK80FLG and TOKSUBSY='OMVS' is created, for NOOMVS 
               for RACFEVNT=13:ALTUSER record, although the record is   
               still does not agree with the IBM documentation:         
                 MXG TOK80LN2 is byte 11 of the TP2=310 segment, which  
                 is documented:                                         
                 Byte 11: Length of subkeyword; 0 if byte 1 bit 1 is set
                  ==> but byte 1 bit 1 is not set.                      
                 Byte 1 bit 4 "keyword has no subfield"                 
                  ==> should be set, but it isn't.                      
              -However, the documentation did allow the creation of two 
               new variables in datasets TYPE8009,8010,8012,8013:       
                 KW301DEL='SEGMENT*DELETED*VIA A*NOXXX*KEYWORD?'        
               so that you could detect the NOOMVS event.               
   Thanks to Erling Andersen, SMT, DENMARK.                             
Change 23.133  Support for Iway Software's IWAY (formerly EDA/SQL) SMF  
EXIWAY1        record, creates these four datasets:                     
EXIWAY2           DDDDDD    MXG       MXG                               
EXIWAY4           DATASET   DATASET   DATASET                           
EXIWAY5           SUFFIX    NAME      LABEL                             
TYPEIWAY          IWAY2     IWAY02    IWAY SERVER END TASK              
TYPSIWAY          IWAY4     IWAY04    IWAY SERVER BEGIN QUERY           
VMACIWAY          IWAY5     IWAY05    IWAY SERVER END QUERY             
May 26, 2005                                                            
   Thanks to Luis Mendoza, ABNAMRO, USA.                                
Change 23.132  Support for z/OS 1.7 (COMPATIBLE) and APAR OA10556.      
VMAC1415      -TYPE70 dataset                                           
VMAC7072       -New MACHTIME='MACHINE*TOD*DATETIME*STAMP' is created by 
VMAC88          addition of new SMF70HOF='HYPERVISOR*DATETIME*OFFSET' to
VMAC94          SYNCTIME (SMF70IET + SMF70LGO).  MACHTIME will be the   
VMAC74          true GMT datetime value, independent of the IPL time and
May 21, 2005    site GMT offsets, and will be used by SCRT to know the  
Oct  5, 2005    true time for IBM bills, since it is possible to IPL    
Dec 12, 2005    with repeated/future/past datetimes, causing double     
Oct  1, 2012    accounting for MSUs, etc.  However, this value has not  
                yet been validated with SMF70LGO populated.             
               -SMF70HWM='CPC*PHYSICAL*MODEL*IDENTIFIER' is created, and
                STFBIT04='SMF70MDL*MODEL*CAPACITY*ONLY?' flag, if true, 
                then SMF70MDL contains only the CPC MODEL CAPACITY, and 
                SMF70HWM has the CPC PHYSICAL MODEL IDENTIFIER.         
               -STFBIT03='SMF70LAC*NO LONGER*INCLUDES*CPU WAIT?'        
               -SMF70Q00='PERCENT*WHEN*IN READY*LE N CP-S' thru variable
                SMF70Q12='PERCENT*WHEN*IN READY*LE N+12 CP-S' now track 
                the PCTRDYWT, but based on IN-READY greater than the    
                number of CP engines.                                   
              -TYPE70PR dataset:                                        
               -LPARCLND='CAPACITY*LIMIT*NOT*DEFINED' is now reserved.  
                so the new label (new in Sep 2012, MXG 30.07) reads     
                LPARCLND='RESERVED*FIELD*SINCE*Z/OS 1.7' and the value  
                is now a blank instead of either Y or N.                
               -Note that if LPARWTFD='Y' (WAIT TIME FIELD DEFINED?) is 
                true, then LPARCPUX (SMF70BND) contains the maximum     
                logical processors defined as shown at the HMC, starting
                with z900 processors.  The Active Logical Processors    
                have an online time SMF70ONT greater than zero, which is
                how/why MXG now counts NRCPUS.                          
              -TYPE70Y2 Crypto dataset, new variables:                  
                 R702NH2I='SHA-256*PCMF INSTR*USED TO*HASH'             
              -TYPE74CA dataset, new variable:                          
              -TYPE791/TYPE792:  (Note added Dec 12, 2005):             
                -MXG used variable name suffix TIFE (Eligible CPU) but  
                 the IBM field name is TIFC, and my choice caused some  
                 confusion, so the IBM Field name of TIFC is now used.  
                -R791NFFI/R792NFFI normalization factor was added and   
                 is used to normalize R791TIFA/R792TIFA times back to   
                 CP seconds.                                            
              -TYPE88 dataset, new variables:                           
                 SMF88EAF='IXLOGR*STAGING*ASYNC BUFFER*FULL'            
                 SMF88ERS='RESERVED*WRONG NAME'  SMF88EDO in manual,    
                 but that field name already exists. Investigating.     
              -TYPE94 dataset, new variables:                           
                 S9SDEMN1='SECURE*DATA*ERASE*MOUNTS*DC 1'               
                 S9SDEMN2='SECURE*DATA*ERASE*MOUNTS*DC 2'               
                 S94XLCSG='VTC 0*WRITE*PROTECT*MODE'                    
                 S94XLCSH='VTC 1*WRITE*PROTECT*MODE'                    
                 S94XLCSI='VTC 2*WRITE*PROTECT*MODE'                    
                 S94XLCSJ='VTC 3*WRITE*PROTECT*MODE'                    
                 S94XLCSK='VTC 4*WRITE*PROTECT*MODE'                    
                 S94XLCSL='VTC 5*WRITE*PROTECT*MODE'                    
                 S94XLCSM='VTC 6*WRITE*PROTECT*MODE'                    
                 S94XLCSN='VTC 7*WRITE*PROTECT*MODE'                    
               -TYPE99U7 dataset Subtype 7 new variable                 
               -TYPE99UA dataset Subtype 10 - need test data to decode  
               -TYPE1415 dataset, new flag variable ('Y',' '):          
                Note that if SMF14LGE='Y', the value in variable TTRN   
                will contain 'TTTR', and if EXTNDSEQ='Y' the value in   
                TTRN will contain 'TTTT', the total number of tracks    
                used across all volumes.                                
                Oct 5, 2005:  Original Reserved Change Number replaced. 
Change 23.131  Support for DB2 IFCID=313 creates T102S313 dataset, with 
FORMATS        dataset labeled 'CHECKPOING LONG RUNNING UR-S'.          
May 24, 2005                                                            
   Thanks to Christa Neven, KBC Bankverzekeringsholding, BELGIUM        
Change 23.130  To update the ITRM data dictionary for MXG datasets, all 
IMACACCT       of my code and datasets created by that code are examined
IMACICD6       and numerous corrections were made as a result of that   
IMACICMR       process.  Most are spelling errors, but many cause the   
RMFINTRV       variable to be not-kept, or incorrectly labeled, etc.    
VMAC110        VMAC110:  FILADDCN changed to FCADDCN in CICSRFDI keep.  
VMAC30                   DSxACT/TCT/TDE/TWT for DSH/DSI/DSJ/DSK FORMATed
VMAC6                    DSGTOTMT/DS2/DS3/DS4 formatted.                
VMAC7072                 DSGTOTWL dual use, now DSGTOTWT kept in CICDS  
VMAC80A                    instead of DSGTOTWL, DGTOTWT labeled.        
VMACDB2        VMACICE:  SRCEOD changed to SRCEOE in ICEBR8SN keep.     
VMACICE        IMACICD6: $EBCDUC8. changed to $EBCDIC8.                 
VMACTPMX       IMACICMR: CMDDB2CT formatted TIME12.2.                   
VMACVMXA       IMACACCT: IDMSCPTM formatted TIME12.2. (in comments).    
May 24, 2005   VMAC80A:  KW24ASTE,KW24KERB kept, labeled in TYPE8024.   
                         CLAS26NM,RES25MEx,RES25TEx labeled in 25/26.   
               VMACTPMX: TPMUSERC,TPMXPLEX labeled.                     
               VMAC30:   SMF30MRD,SMF30MRI formatted TIME12.2           
               VMAC6:    SMF6FTL, leading asterisk removed in label     
               VMAC7072: IFAWAITM, R723IFAT, R723IFCT formatted TIME12.2
                         MXGCIN, NRPHYCPS, R723NFFI labeled.            
                         Also NRPHYCPS now labeled in ASUMCEC,ASUM70PR. 
               VMACDB2:  QISESTMT kept in DB2STATS                      
               RMFINTRV: PCTIFABY labeled.                              
               VMACVMXA: APLSDTST labeled.                              
                         USAPLxxx temporary variables dropped in        
                           VXAPLCMS/SLM/SLN/SLP/SLO datasets            
                         PCT-prefixed VXAPLSLP/SLO and TICKS labeled.   
                         MRHDRRC labeled                                
                         BYTOA and BYFRA are MGBYTES formatted, LENGTH 8
                          and BFFRA was removed from LENGTH 8.          
                         Stray text in label of PT4ID corrected.        
                         IFINOCWR/IFOUOCWR are kept, logic corrected.   
                         New variables in VXAPLSRV labeled, kept.       
                         Temp variable OLDTODON is dropped from VXBYUSR.
   Thanks to Chris Weston, SAS ITRM Development Cary, USA.              
Change 23.129  Cosmetic.  Label for IPMIGR2 should have been SECONDARY  
May 23, 2005                                                            
   Thanks to Tom Parquette, AXA Technology Services, USA.               
Change 23.128  New z/VM 5.1 1.19 record was misdocumented by IBM,  which
May 23, 2005   Correct MRHDRLEN=368 was doc'd as 365, and two bytes at  
               offset 42 were not listed in the length column, but MXG  
               was also not guilt-free, as I had guessed wrong at where 
               those two undocumented bytes were located.  Dataset      
               VXMTRQDC is now corrected.                               
   Thanks to Pat Curren, SuperValu Inc, USA.                            
Change 23.127  A semi-colon at the end of a %MACRO invocation caused a  
VMXGFOR        "180" syntax error, and now I know that it is NOT true   
May 24, 2005   that every SAS statement ends with a semi-colon!         
               While MXG Change 20.327 removed all invocations of the   
               now-unneeded %VMXGFOR macro from all MXG PROC SORTs,     
               a site with an old PROC SORT DATA=A OUT=B %VMXGFOR; in   
               their report program failed with "FORCE" underlined.     
                 %VMXGFOR was only needed because Version 5 of SAS did  
                 not support the FORCE keyword; that macro generates    
                 a blank for V5 and "FORCE" with V6 or later.           
               It turns out the culprit was the addition of the new     
               statement after the %MEND; statement in the VMXGFOR      
               member, added by Change 23.005.  It also turns out that  
               it was that final semicolon after %VMXGVERS() that caused
               the error, in this reply from SAS Technical Support:     
               "The problem is the semi-colons in the autocall source   
               files that follow the macro call.  These semi-colons are 
               superfluous for the macro call, but not harmless when    
               contained in an autocall source file.  When a macro call 
               is determined to be the first reference to an autocall   
               macro, the file containing the autocall macro definition 
               is processed until the end-of-file is reached and then   
               the macro is called.  In this instance the macro         
               definition is read and processed. This consumes the      
               autocall source file up to and including the semi-colon  
               following the %MEND.  Then the following macro call      
               (i.e., to %VMXGVERS) in the autocall source file is      
               processed.  This consums the autocall source file up to  
               and including the right parenthesis, leaving the         
               semi-colon.  The dangling semi-colon is then inserted    
               into the source stream (as model text) and then a call is
               placed to the autocall macro that started the process.   
               This behavior is present in versions 6 thru version 9."  
               So, a final semi-colon has NEVER been needed after the   
               invocation of a %MACRO, and none of the examples in the  
               SAS Macro Manual (yes, we Read The Fine Manual!) show a  
               semi-colon after the invocation.  For example, you can   
               use   %ANALDB2R()  and the report program executes!      
               Fortunately, it appears that only the %VMXGFOR member is 
               vulnerable, because it inserts text into a SAS statement.
               All other VMXGxxxx members that have %VMXGVERS added are 
               "standalone" executions, and the extra semi-colon, even  
               though those members are autocalled, is superfluous.     
               But now I know what caused this strange error, and have  
               removed the trailing semicolon from the %VMXGVERS call   
               in the (still-archaic) VMXGFOR autocalled member.        
   Thanks to Matt Feeney, Defence Department, AUSTRALIA.                
Change 23.126 -Dataset PDB.RMFMSUSE contains both Service and Reporting 
ASUMMIPS       Class obs, but variable RPRTCLAS was not kept, so you    
May 18, 2005   couldn't identify which class the observation was for.   
May 23, 2005   Now, RPRTCLAS is kept in PDB.RMFSUSE.                    
May 24, 2005  -Member IMACKEEP was not included, so you could not use   
               the MACKEEP= to tailor the ASUMMIPS execution.  As an    
               example that you can now use:                            
                 //SYSIN DD *                                           
                  %LET MACKEEP=                                         
                           MACRO _RMFOUT RMFMSUSE %                     
                           MACRO _MIPSMSU                               
                             IF SYSTEM='TREX' THEN MIPSFACT=6.7;        
                             ELSE                  MIPSFACT=5.7;        
                   %INCLUDE SOURCLIB(ASUMMIPS);                         
               changes the output from PDB.RMFMSUSE to WORK.RMFMSUSE and
               changes the MIPSFACT (MIPS per MSU) depending on SYSTEM. 
              -The default PROC PRINT for RMFMSUSE is now sorted by the 
               RPRTCLAS variable, so if you have both Reporting Class & 
               Service Class data, you will get separate reports.  Since
               they will overlap, having a single report was deceptive. 
              -The default PROC PRINT for SMFMSUSE did not use _SMFOUT, 
               causing an error if _SMFOUT was redefined.               
   Thanks to Dan Case, Mayo Foundation, USA.                            
   Thanks to Chuck Hopf, MBNA, USA.                                     
   Thanks to Jim Horne, Lowe's Companies, Inc, USA.                     
Change 23.125  HSC V6 changed the STCLMU (subtype 4) SMF record, now STK
VMACSTC        PTF L1H12EW documents the new record, but that PTF also  
May 17, 2005   changes the record again, so records written with HSC V6 
               without the PTF will produce strange results in STCLMU.  
              -And, of course, no version flag is in the STK record, so 
               the (archaic) logic to test the Record Length is required
               to determine if this is a valid pre-V6 record, a short   
               pre-V6 record (fixed by a prior PTF), an invalid HSC V6.0
               prior to the PTF, or a valid HSC V6.0 record after PTF.  
              -And there are undocumented bytes in the record, as well, 
               between offsets 11 and 16 (decimal).                     
   Thanks to Dean A. Ruhle, JC Penney Co., Inc, USA.                    
   Thanks to Michael Gresham, JC Penney Co., Inc, USA.                  
   Thanks to David M. Cole, STK, USA.                                   
Change 23.124 -Duplicate SMF type 30 interval records caused duplicate  
VMAC30         observations in PDB.SMFINTRV because the revisions in MXG
BUILD005       Change 22.320 removed the NODUP option from the SORT.    
May 17, 2005   This change restores the NODUP option.                   
              -The _BTY30UV macro in VMAC30 was revised so the first    
               five variables match the sort order used in BUILDPDB:    
                                MULTIDD DESCENDING EXTRADD              
               just for consistency, even though the PDB.SMFINTRV that  
               can be created with TYPS30 (or with the _STY30UV macro   
               invocation) is NOT the same PDB.SMFINTRV dataset that is 
               created by BUILDPDB:                                     
                -The BUILDPDB-built PDB.SMFINTRV has consolidated all of
                 the "MULTIDD" observations into a single observation.  
                -The TYPS30/_STY30UV-built PDB.SMFINTRV still contains  
                 all of the additional and confusing "MULTIDD" obs.     
   Thanks to Joan Nielsen, (i)Structure, USA.                           
Change 23.123  Variables CPUIFATM and CPUIFETM (total) are added to the 
VMXGRMFI       PDB.RMFINTRV dataset, and individual workload variables  
May 17, 2005   (like BATIFA, BATIFE, etc) with IFA/IFE CPU times added. 
               Oct 19, 2005: See Change 23.265; 23.123 was incomplete.  
   Thanks to Andre Baltimore, Unigroup, Inc, USA.                       
Change 23.122  Datasets PDB.TYPE70LP and PDB.ASUMTAPE were not in the   
WEEKBLD        default WEEKBLD member, but as they are created in the   
WEEKBLDD       JCLPDBx daily job examples, they are now added to the    
WEEKBLDT       weekly example job.                                      
May 17, 2005                                                            
   Thanks to Hugh Lapham, Royal Canadian Mounted Police, CANADA.        
VMXG70PR       corrected by an insertion of a PROC SORT to ensure the   
May 16, 2005   order is correct; values for SHIFT were the culprit.     
   Thanks to Tony Curry, BMC, USA.                                      
Change 23.120  Support for ESS GEPARMKY=004Dx creates ESSMAIL2 variable 
IMAC6ESS       in TYPE6 dataset when IMAC6ESS is enabled.               
May 13, 2005                                                            
   Thanks to Engelbert Smets, Provinzial, GERMANY.                      
Change 23.119  Change 23.025 was not tested with TRENDIN data, and the  
UTILCONT       semicolon after &PDBOUT..ASUMSIZE  should not have been  
May 13, 2005   there, since the macro code is still part of the SET.    
   Thanks to Jeffrey A. Harder, Farm Bureau Insurance, USA.             
Change 23.118  Processing CICS Journal Records (SUBTYPE=0) didn't output
VMAC110        the last record.  The test was changed to                
May 12, 2005    IF LOC+GLRHLEN-1 LE LENGTH THEN GOTO JOUR5202;          
   Thanks to Helmut Roese, COM Software, USA.                           
Change 23.117  If you built your own program, and had _CDE40 before the 
VMAC40         _CDE30 macro, you got ERROR 48-59 with the below two     
May 12, 2005   notes:                                                   
               because MXG didn't fully protect the variable PROGRAM.   
              -Per the text of Change 20.243, PROGRAM was added to the  
               ARRAY statement for character variables in VMAC40 so that
               the _CDE40 could be located prior to the _CDE30.         
              -This is really a bummer, as PROGRAM is not even input in 
               SMF 40 records, but the code in VMAC40 makes a call on   
               VMACEXC2, which has a PUT statement in case of an error  
               in the decoding EXCP segments, and when the PUT was the  
               first instance of variable PROGRAM, SAS made it numeric  
               which then spawned numerous other errors when it was     
               referenced as a character variable.                      
   Thanks to Michael S. Noud, IRS, USA.                                 
Change 23.116  Very bad values for some data fields in TYPE 74 subtype 5
VMAC74         records for HDS on their Tagmastore USP, like negative   
May 12, 2005   values for SCTO (R745DTC).  Under investigation with HDS.
               Reporting site now has a microcode fix which is believed 
               to correct the error; no fix number at press time.       
Change 23.115  The default OPTIONS and OPTIONS2 did not agree with the  
ASMTAPEE       documentation in Change 23.030, and the internal comments
May 11, 2005   about default options were inconsistent.  The comments   
May 29, 2005   were clarified, and the default options in OPTIONS and   
               OPTIONS2 are set as documented, for IBM VTS Systems.     
               As noted, if you have STC VTS, you must remove DOMXIT to 
               disable the IBM Volume Mount Exit, because we still have 
               not been able to find an equivalent Exit in STK's HSC,   
               but we're still working on that enhancement.             
               Updated: Jul, 2005.  See Change 23.162/23.177/23.230.    
              -Line 3139 extended into column 72, making it look like a 
   Thanks to Shane Dowling, DEWR, AUSTRALIA.                            
Change 23.114  DCOLLECT dataset DCOLCLUS, VSAM Dataset Info, was not    
DAILYDSN       used in the original "Daily Dataset Billing" (JCLDAYDS), 
May 11, 2005   but has been added so that it will be there if needed.   
   Thanks to Chairat Tiajanpan, KCS, Thailand.                          
Change 23.113 -Zero obs with a Solaris cube.  The _UTNGCNT array sizer  
ADOCTNG        only worked for NT data, so the INSTREAM code was not    
EXTNT128       generated due to a missing OUTPUT statement, and the new 
EXTNT129       MIB-2 UNKNOWN object was processed last, causing 0 obs.  
EXTNT130       New So028 dataset supports the MIB-2 object and new field
EXTSO028       added to existing So027 dataset is now supported.        
FORMATS       -Cubes with data from multiple days had only last day's   
IMACTNG        data output.  Two tests that previously read             
VMACTNG        appear to be the culprit, and by commenting out to be    
May 10, 2005   data from all days was output. That heuristic was needed 
May 23, 2005   early on in TNG support, but I think subsequent redesign 
May 28, 2005   eliminated the need for that part of the test to invoke  
               outputting, BUT PLEASE VALIDATE THAT YOU GET DATA FROM   
              -New NT platform names of NTP500I and WNS502I were added  
               to the MACRO _NTPLAT to eliminate UNKNOWN PLATFORM msgs. 
              -Support for new Objects for NT: RAS PORT, MICROSOFT      
               GATHERER, and MICROSOFT SEARCH.                          
              -May 28: $MGTNGVN Format was completely revised, as two   
               Solaris metrics were identical in first forty characters:
                 'Interface Traffic (Lifetime) Collisions %'            
                 'Interface Traffic (Lifetime) Collisions'              
               causing INSTANCES EXCEEDED error messages when tested.   
               That %MGTNGVN format, used to lookup the concatenation of
               Platform abbreviation, Object Name, and Metric Name, had 
               only allowed 40 positions for metric name.  To eliminate 
               future duplicate exposures, all TNG cubes were read to   
               find the maximum metric name of 58 chars, so the format  
               was expanded to allow 64 char metric names, but with the 
               2-char platform abbreviation and the 20-character object 
               name, the "expanded length format" now had DEFAULT=86 in 
               its VALUE statement.  But with only 72 positions of MXG  
               input text, some of the value definitions had to be split
               into two lines, a nasty but necessary implementation.    
               But then the fun began.  Read Change 23.144 for solution.
                Since more than 40 bytes of METRIC name are now being   
                looked-up in the format, data for all past test cubes   
                was read to find all metrics longer than 40 bytes, and  
                those 55's format data-values were revised so they would
                be found in the new format; the longest was 58 bytes.   
                But if I missed one, it will show up as an observation  
                in the UNKNOWN dataset, so please check your SAS log to 
                make sure I found them all.                             
   Thanks to Michael L. Kynch, International Paper, USA.                
   Thanks to Peter Krijger, ANZ National Bank Limited, NEW ZEALAND.     
Change 23.112  Change 23.070 reset STARTIME for 58,59, and 01 seconds,  
VSETZERO       but that didn't protect delays beyond 1 second; new data 
May  9, 2005   shows that 70 and 72 records with seconds 02 are created;
               in fact, the SMFTIME of the 72 subtype 4 was 4.5 seconds 
               after the interval pop, and that subtype 4 had 00 seconds
               for its STARTIME!  So the test in VSETZERO is now revised
               to set seconds 58 thru 05 back to seconds 00.  The main  
               impact without this change was that the PDB.ASUMCEC had  
               had two observations, one with 01 seconds, one with 02   
               seconds as their STARTIME.                               
   Thanks to Diane Eppestine, SBC, USA.                                 
Change 23.111  Support for DB2 V8.1 DB2ACCTP Package Data now validated.
VMACDB2        Change 23.098 guessed wrong, but IBM didn't help; in the 
VMACDB2H       new IFCID=239 structure, the LENQPAC is zero!  But, in   
May  9, 2005   a very weak defense of their redesign, there is a very   
               obscure note that says it is now "legal" to have a DB2   
               data segment with Length=zero, and it now means: read the
               first two bytes at the offset, and use that as the length
               of the data segment!  So with a hex dump of one of the   
               new records, the code is now corrected and DB2ACCTP will 
               be valid for DB2 V8.1 or earlier versions as well.       
              -There was also an extraneous PUT QWHSRELN= in VMACDB2H   
               added by Change 23.098, only for DB2 V8.1, but lots of   
               messages would have been printed, if you had DB2 V8.1,   
               since it put that message for EVERY SMF 100/101 record!  
               It was removed by this change.                           
              -Note that this change is required for DB2 V8.1 if there  
               are ANY package segments in your DB2 records; prior notes
               that earlier versions of MXG support DB2 V8.1 are wrong. 
   Thanks to Steve Olmstead, Thomson, USA.                              
Change 23.110  Cosmetic.  Variable ESMFFAVG was listed in the KEEP list 
TYPEVM         but was a misspelling and was removed; variables ESMFIAVG
May  5, 2005   and ESMFOAVG are now FORMATed TIME12.2.                  
   Thanks to Sudie Wulfert-Schickedanz, Anheuser-Busch.                 
Change 23.109  Support for VM:Account product, which reversed the order 
TYPEVM         of dates from MMDDYY to YYMMDD and writes longer records.
May  5, 2005   This iteration does not support the additional data but  
               that support will be added in a later change.            
   Thanks to Richard J. Reents, Abbott Labs, USA.                       
Change 23.108  -Label was missing for variable PCTCPTBY in VMACQACS     
VMAC110         label for SYBTAC was changed to *.                      
VMACDB2        -VMAC110, new Stat variables prefixed DSH/DSI/DSJ/DSK    
VMXGRMFI        that are time values were not FORMATed TIME12.2;        
May  5, 2005    DSxTOTMT variables were not formatted TIME12.2;         
May 17, 2005    DSGTOTWT replaces DSGTOTWL in CICDS variable; TOTWL is  
                a suffix for CICDSPOO variables and had been reused.    
               -VMACDB2, new 8.1 variable QISESTMT was not kept.        
               -RMFINTRV, variable PCTIFABY labeled, ZOS70WLA removed.  
   Thanks to Chris Weston, SAS Institute ITRM Development, USA.         
====== Changes thru 23.107 were in MXG 23.04 dated May  4, 2005=========
Change 23.107  Several macro definitions were incomplete or mislocated. 
VMACVMXA      -MACRO _SAPLSRV statement was missing; its code was       
May  4, 2005   inside the MACRO _SAPLEDT definition.                    
May 16, 2005  -Invocations of _SAPLEDT and _SAPLSDT were missing in     
               the _DELTALL macro definition.                           
              -The _SSYTSCG and _SSYTSYG macros had the DELTATM located 
               too late, and it was not set negative when missing to    
               protect the subsequent divides by DELTATM.               
              -There is no _SAPLAPL macro, but there's a _VAPLAPL macro 
               now created.  The VMXA design preceded the _Vdddddd      
               macro definition (lists variables kept in the "dddddd"   
               token's dataset), and the old VMACVMXA uses _Vdddrrr     
               macros for domain/record groupings.  _VAPLAPL wraps all  
               of the 25 Application Server _WAPLrrr datasets, each of  
               which has its own _Sdddddd macro, so that's why there    
               is on _SAPLAPL sort macro definition.                    
              -A number of ommissions for new variables were fixed.     
   Thanks to Chris Weston, SAS Institute ITRM Development, USA.         
Change 23.106 -Variable TIWRDCT should not have been kept in MONIIDS nor
VMACTMO2       should its second label exist; that name was used twice  
May  3, 2005   but was caught in QA and the correct TIIDSWRC/TIIDSWRT,  
May  5, 2005   fields were input and labelled, but I failed to clean up 
               this part of the original duplicate names.               
              -Label for PAJTDLYT and PAJTDLYC were reversed, and some  
               lables had blanks instead of '*' SPLIT characters.       
   Thanks to Chris Weston, SAS Institute ITRM Development, USA.         
Change 23.105  TYPE73 variable SMF73CSS, Channel Subsystem ID was moved 
VMAC73         to the end of the Channel Path Control Section, if bit 2 
May  3, 2005   of SMF73CFL (Hardware allows multiple logical channel    
               subsystems) is enabled, by z/OS 1.5, but I missed that   
               relocation. SMF73CSS is now conditionally INPUT from the 
               new location when that bit is enabled.                   
   Thanks to Joel Giacobbe, Federal Reserve Bank, USA.                  
Change 23.104  The ASUMTALO/ASUMTMNT summarization of tape drives and   
ANALCNCR       tape mounts is enhanced so that you can summarize by     
ASUMTALO       "groups" that you define, and ANALCNCR can now be used   
ASUMTMNT       to determine which jobs were active at the time of the   
May  3, 2005   maximum tape drive allocation.                           
May 11, 2005  -For ASUMTALO, the default assumed all tape devices were  
May 16, 2005   shared across all systems in the PDB.TYPETALO input data,
May 18, 2005   and were thus summarized by DEVICE.                      
              -For ASUMTMNT, the default summarized all tape mounts BY  
               SYSTEM as the high level variable.                       
               a. This change provides these local tailoring options:   
              -For ASUMTALO, you can define a "group" variable and then 
               create it based on SYSTEM, and that "group" variable     
               will then be used as the high-level summary variable in  
               the BY statements.  For example, you can create a group  
               variable named LOCATION and populate that variable with  
               this example using the new old-style macros "instream":  
               //SYSIN DD *                                             
               %LET MACKEEP=                                            
                 MACRO _GRPALNM   LOCATION   %                          
                 MACRO _GRPALCD                                         
                  IF SYSTEM IN ('SYS1','SYS2') THEN LOCATION='DALLAS';  
                  ELSE IF SYSTEM IN ('XYZ1','XYZ2') THEN LOCATION='NYC';
               %INCLUDE SOURCLIB(ASUMTALO);                             
              -The ASUMTALO data will then show tape device utilization 
               for each DEVICE type within each LOCATION.               
              -For ASUMTMNT, you can also define a "group" variable and 
               create it based on SYSTEM, and that "group" variable     
               will then be used as the high-level summary variable in  
               the BY statements.  The two macro names are different, in
               case you want to sum TMNT different than TALO, but the   
               structure is similar in this example:                    
               //SYSIN DD *                                             
               %LET MACKEEP=                                            
                 MACRO _GRPMNNM   LOCATION   %                          
                 MACRO _GRPMNCD                                         
                  IF SYSTEM IN ('SYS1','SYS2') THEN LOCATION='DALLAS';  
                  ELSE IF SYSTEM IN ('XYZ1','XYZ2') THEN LOCATION='NYC';
               %INCLUDE SOURCLIB(ASUMTMNT);                             
              -The ASUMTMNT data will then report tape mount statistics 
               for each SYSTEM within each LOCATION.  If you want your  
               mount statistics to be summarized by each LOCATION (and  
               nor for each SYSTEM at each LOCATION, you would just add 
                   SYSTEM='    ';                                       
               as the last statement in your _GRPMNNG definition.       
              -For your daily "BUILDPDB" job, which normally includes   
               both ASUMTALO and ASUMTMNT, you can put all four of those
               macro definitions (_GRPALNM,_GRPALCD,_GRPMNNM,_GRPMNCD)  
               in a single %LET MACKEEP= for that job (or they could be 
               defined in the IMACKEEP member and then would apply to   
               any execution of their respective ASUM members).         
               b. Revision to find contributors to maximum value:       
              -ANALCNCR was enhanced so that you can print each of the  
               input events that caused the "maximum concurrent value". 
               When you specify   %LET MXGDEBUG=ANALCNCR; prior to the  
               execution of ANALCNCR, then dataset WORK.MXGDEBUG will   
               be created with the first phase observations, and you can
               then use this program to find the time of the peak value,
               and then print the specific input events that created the
               maximum.  For example, ASUMTALO calculates maximum tape  
               drives allocated, so you would use:                      
                   %LET  MXGDEBUG= ANALCNCR;                            
                   %INCLUDE SOURLCIB(ASUMTALO);                         
                   PROC SORT DATA=MXGDEBUG;                             
                    BY DESCENDING CONCURNT;                             
                   DATA _NULL_;                                         
                    SET MXGDEBUG;                                       
                    IF DEVICE=:'9840HSM';                               
                    CALL SYMPUT('PEAKTIME',PEAKTIME);                   
                   PROC PRINT DATA=PDB.TYPETALO;                        
                    WHERE DEVICE=: '9480HSM' AND                        
                         ALOCSTRT LE "&PEAKTIME"DT LE ALOCEND;          
               to print which observations from the PDB.TYPETALO data   
               caused that maximum tape drive allocations.              
                 For ANALCNCR with other input data, the test for the   
                 "DEVICE" variable would need to be changed to use the  
                 appropriate variable, the SET PDB.TYPETALO would need  
                 to be changed to the input dataset, and the correct    
                 start and end variables would need to be used in the   
                 selection around "&PEAKTIME"DT test.                   
               c. Additional chagnes:                                   
              -ANALCNCR was revised to re-locate the INCODE= operand;   
               this was required so that the "group" support, above,    
               could be implemented.                                    
              -A new TRACE= option for internal debugging was created   
               in ANALCNCR, unlikely to be needed outside development!  
              -An unrelated enhancement was also made to ASUMTMNT; the  
               definition of the mount time values for each of the mount
               "buckets" was externalized, so they can also be changed  
               by redefining those macros with %LET MACKEEP=, as above. 
   Thanks to Andre D. Walker, Bank of America, USA.                     
Change 23.103  Documentation.  Selecting ANALDB2R for an interval period
ANALDB2R       (13:00 to 14:00), MXG's criteria selects any transaction 
May  3, 2005   that started in that interval, or ended in that interval,
               or started before and ended after that interval, so the  
               MXG report can easily show an "INTERVAL DURATION" that is
               greater than the one hour you requested, but it includes 
               all transactions that spent any time in the requested    
               interval.  IBM's DB2PM reports appear to only include the
               transactions that started and ended within the requested 
               interval, so MXG can report more activity than DB2PM.    
   Thanks to Peter Farrell, Commerce Bank of Kansas City, USA.          
Change 23.102  Cosmetic, but confusing!  The label for PAGEINS/PAGEOUTS 
VMAC30         is corrected to the TOTAL PAGE IN/OUT FROM AUX STORE, as 
May  3, 2005   they count both blocked and unblocked pages moved.       
   Thanks to Melanie Hitchings, BT, ENGLAND.                            
Change 23.101  Support for APAR OA10901, new SMF30ZNF variable with the 
VMAC30         zAAP CPU Normalization factor is added to the datasets   
May  2, 2005   TYPE30_V/PDB.SMFINTRV, TYPE30_4 and TYPE30_5.            
Change 23.100  ASG/Landmark TMON for CICS/TS V2.3 supports CICS/TS 3.1  
VMACTMO2       with toleration PTFs for their product, but there are no 
May  1, 2005   changes to their data dictionary, i.e., there were no    
               changes made in their records to add any new 3.1 fields. 
   Thanks to Roland Schiradin, Alte-Leipziger, GERMANY.                 
Change 23.099  Support for IMS Version 9.1 was already in MXG 22.22:    
VMACIMS         -IMS Monitors: BMC IMF, Candle ITRF, Landmark TIMS.     
May  1, 2005    -MXG's "Supported" TYPEIMS7 to create IMS0708 dataset   
                -MXG's ASMIMSL6/JCLIMSL6 to create IMSTRAN dataset.     
              -There were no significant changes by IBM to any of the   
               IMS log records in IMS Version 9.1, compared with 8.1.   
              -The three IMS Monitors that are fully supported by MXG   
               (and are STRONGLY recommended - See Newsletter 25!!),    
               BMC's IMF, ASG/Landmark's TIMS, and IBM/Candle's ITRF    
               products all create their own data records:              
               -IMF writes two records to the IMS log file, 'F9'x, 'FA'x
                but there were no changes made by IMF Version 4.1.00 for
                IMS Version 9.1 to the IMF records.  However, MXG 22.08 
                is required for IMF records for all IMS versions, due to
                corrections in sequencing of CIMSTRAN in Change 22.199. 
                Also, Change 22.241 in MXG 22.10 added ASUMCIMS example 
                for summarization of CIMSTRAN/CIMSDBDS IMF datasets.    
               -TIMS writes data to its own file; the last update to    
                TYPETIMS code was in MXG Version 20.09.                 
               -ITRF writes additional records to the IMS log, but then 
                an ITRF program combines their records with IBM records 
                to create their file that MXG TYPEITRF then processes;  
                the last TYPEITRF code change was in MXG Version 17.09. 
              -MXG's only "Officially Supported" IBM-IMS-log-record read
               program is TYPEIMS7, which combines log records 07 and 08
               to create the IMS0708 dataset (capturing only resources, 
               with no response time).  Those records were not changed  
               by IBM in IMS V9.1, but MXG Change 22.199 (in MXG 22.08) 
               was a major revision to the TYPEIMS7 logic for all IMSs. 
               - You must update the _IMSVERS macro in IMACIMS to tell  
                 MXG the IMS version you are processing, and you cannot 
                 concatenate IMS logs from different versions, as IBM   
                 does not put a version number in their log records!    
              -MXG's "pseudo-supported" IBM-IMS-log-record read programs
               in the JCLIMSL6 jobstream required no changes to support 
               IMS Version 9.1, but you must re-assemble ASMIMSL6 with  
               the IBM IMS Macro Library for IMS Version 9.1 to create  
               the load module for V9.1 records, and you must run       
               separate JCLIMSLx jobs with different load libraries and 
               process each IMS version's data separately; you cannot   
               concatenate the IMS logs from two versions and read with 
               JCLIMSLx.  MXG 20.03 contained the last changes to these 
               members, and thus there was no need to create L7, L8, or 
               L9 suffixed ASMIMSLx/JCLIMSLx members.                   
               -For processing JCLIMSLx/ASMIMSLx on ASCII platforms, MXG
                Version 22.06 is required due to Change 22.128.         
              -IBM did insert fields in the IMS log 31x record in V9.1, 
               and VMACIMS is updated by this change (in MXG 23.04) for 
               that insert, but the insert was after any "important" IMS
               data, and could only be observed if you were looking at  
               the IMS31I or IMS31O datasets that are written to //WORK,
               but are neither kept nor used by MXG programs.           
   Thanks to Roland Brugger, Credit Suisse, SWITZERLAND.                
Change 23.098  DB2 Version 8 restructured Package Data, and added many  
VMACDB2        new variables to DB2ACCTP dataset:                       
                 QBACDPF  QBACNGT  QBACSIO                              
               Originally, the first ten packages executed by a plan    
               were written as ten segments in the SMF 101 subtype 0    
               IFCID=0003 records, and if more than 10 packages were    
               executed, additional SMF 101 subtype 1 IFCID=239 records 
               were created.  MXG creates an observation in the DB2ACCTP
               dataset from each package segment, independent of whether
               it was in the 0003 or the 239 IFCID record.  But with    
               DB2 V8.1, package segments are no longer written in IFCID
               0003 records; instead only the IFCID 0239 records will   
               contain package data, and there are three new DSECTS     
               added that are always present, one of each for each      
               package segment.                                         
                 (QXPK, QBAC, and QTXA, and in that order; the DB2 MACRO
                  Library had inconsistent documentation that will be   
                  corrected with a doc APAR)                            
               MXG will transparently use either 0003 and 0239 or just  
               0239 segments to create the DB2ACCTP observations, and   
               those added new variables will exist, but will only be   
               populated (i.e., non-missing) from DB2 V81 records.      
   Thanks to Steven Olmstead, Thomson BETA Systems, USA.                
   Thanks to Ray Willoughby, Thomson BETA Systems, USA.                 
   Thanks to John B. Tobler, IBM Silicon Valley Lab, USA.               
Change 23.097  Variables CTCKPNTS MAXLOCKS TOTLOCKS were added to the   
VMACCIMS       KEEP list of both CIMSTRAN and CIMSPROG, but those three 
Apr 29, 2005   variables are only INPUT from the CIMSTRAN records, so   
               they are now removed from CIMSPROG KEEP list.            
   Thanks to Christa Neven, KBC Bankverzekeringsholding, BELGIUM        
Change 23.096  Change 22.203 protected decoding of JCTJOBID if it was   
VGETJESN       blank or hex zero, to prevent unnecessary log messages,  
Apr 29, 2005   but that caused TYPETASK to be blank in TYPE30_6 data,   
               because the "Early Address Spaces" records that are      
               written as type 30 subtype 6 interval records now have   
               have blanks for JCTJOBID.                                
                (Historically, these records had JOB name in JCTJOBID,  
                 then JCTJOBID was hex zeros, but now JCTJOBID contains 
                 blanks in current z/OS type 30 subtype 6 records).     
               But they have SUBSYS='STC', so the logic was revised to  
               sets TYPETASK='STC' (and JESNR=.) if JCTJOBID is blank or
               hex zero, and SUBSYS='STC'.                              
                 (And if blank-TYPETASK-value-messages are printed now, 
                  more code will be added to test and figure it out!)   
   Thanks to Michael Creech, Fidelity Information Services, Inc, USA.   
Change 23.095  Variable PCTCFULL='PCT OF*CACHE*USED' was added to the   
VMAC41         TYPE41VF dataset.  Variable SMF41FND is clarified in the 
Apr 29, 2005   ADOC41 as the number of objects found in cache in this   
               interval, which is NOT the total number of objects in the
               cache (that number does not exist in SMF 41 records).    
   Thanks to Ulrich Krueger, National Semiconductor Corp., USA.         
Change 23.094  The PROC DATASETS for HSMSTAT needed MT=ALL because that 
ASUMHSM        dataset is a VIEW, and the default MemType=DATA caused a 
Apr 29, 2005   warning note.                                            
   Thanks to Chris Weston, SAS Institute ITRM Development, USA.         
VMAC74         because I didn't have any test data to catch my typos!   
Apr 28, 2005   The INPUT of R748RCNT was missing a period, variables    
               R748AASP/AAWD/AACP are now PIB1/2/4 instead of RB8, and  
               variables R748XRCP thru R748XTDY are PIB4. and not RB4.  
   Thanks to Miguel Francisco Monferrer Carvajal, EDS, SPAIN.           
Change 23.092  MXG 23.03 only, and only for ITSV/ITRM.  Two hardcoded   
VMXG70PR       references to "PDB." caused errors with ITSV/ITRM.  The  
Apr 28, 2005   macro variable "&PTY70PR.." replaced them to correct.    
   Thanks to Chris Weston, SAS Institute ITRM Development, USA.         
VMAC6          a VPS record with the Printway File Transfer segment. The
Apr 28, 2005   Changes 22.309, 22.321 are revised, based on the z/OS 1.6
               SMF Manual, which documents both the basic and extended  
               mode for records created by SUBSYS='TCP', but the values 
               in SMF6INDC in SUBSYS='VPS' records are 5 and 3 instead  
               of the 1 or 7 expected, so MXG logic is revised again to 
               provide special handling for VPS SMF 6 records that have 
               a file transfer segment.  But in one SMF 6 record written
               for SUBSYS='PSF', it's file transfer segment does not    
               agree with either the basic or extended mode TCP segments
               or with the PSF segment documentation, so heuristic logic
               is added to (hopefully) protect PSF records as well.     
   Thanks to Udo Frohling, Kommunales Rechenzentrum Niederrhein, GERMANY
Spent week in NYC at The Plaza during its last week as a real hotel, but
our real purpose was to attend the Jammy Awards ceremony at Madison     
Square Garden, where our "godson", Keller Williams won one of only nine 
Jammy's: Best Live Album, "Stage".  See  
====== Changes thru 23.090 were in MXG 23.03 dated Apr 22, 2005=========
Change 23.090  Executing MXG under ASCII platforms has some differences:
INSTALL       -If you use the ftp access method to read your MVS data   
IMACFILE       directly, you won't have a copy of the SMF data on your  
Apr 22, 2005   ASCII system; although most sites back up their SMF data 
               on MVS, it is possible to backup your SMF data on your   
               ASCII platform, as you are reading SMF with ftp access.  
                 Writing a 13GB backup file added 20 minutes run time.  
                 See the article "Can you run MXG on a PC' in NEWSLTRS. 
               Or, if you want to create an SMF file on your ASCII      
               system that contains selected SMF data, the below example
               shows how you can use the "IMACFILE" exit to create an   
               SMF VBS file on your ASCII system.                       
              -The _NULL_ data step creates macro variable, &DATETXT,   
               with the date and time as a text string, which is then   
               used to create the name of the "backup" SMF VBS file.    
              -The "instream" tailoring statement %LET MACFILE= adds    
               the code inside the %QUOTE() function (required because  
               there semi-colons in the code that would otherwise have  
               terminated the %LET statement) to the exit that is taken 
               after the SMF header has been read.                      
                 If you want to select SMF records, you would add an    
                 IF ... THEN DO; statement after the %QUOTE( and would  
                 add an END; statement before the ) that ends %QUOTE.   
                 The SMF header variables ID SMFTIME SYSTEM and SUBTYPE 
                 are available for selection, although some records with
                 subtypes don't put their subtype in the SMF header.    
              -Example to read SMF via FTP and create a local SMFBKUP   
               file of the input SMF records:                           
               The example shows how to concatenate multiple SMF files: 
                  //SYSIN DD *                                          
                   DATA _NULL_;                                         
                    CALL SYMPUT('DATETXT',DATETXT);                     
                   FILENAME SMF FTP ("'SYS1.SMF'" "'SYS2.SMF'" ... )    
                          USER='XXXXXX' HOST='YYYYYYY'                  
                          S370VS RCMD='SITE RDW' LRECL=32760            
                   FILENAME SMFBKUP "C:\MXG\SMFDATA\&DATETXT" ;         
                   %LET MACFILE=                                        
                        FILE SMFBKUP RECFM=N LRECL=32760;               
                        PUT BDW &PIB.2. '0000'X RDW &PIB.2. '0000'X     
                            _INFILE_ @;                                 
                   %INCLUDE SOURCLIB(BUILDPDB);                         
               The backup file name  c:\mxg\smfdata\D2005-04-19-T04-20  
               contains the date and time of creation of the file. The  
               backup file is slightly larger than the input file       
                  (325,498,825 versus 325,484,807, or +14,018 bytes)    
               because each VBS record creates a separate block.  And,  
               the FILE with RECFM=N option does print the output file  
               name on the SAS log, there is not message that any data  
               was written.  SAS Technical Support says that is because 
               RECFM=N doesn't write records that none are counted, but 
               a suggestion to provide byte count has been made, so that
               you will know if the file was actually written to.       
              -Comments with this example were added to IMACFILE and to 
               member INSTALL, but no there was no change to MXG code.  
              -Example to read SMF via FTP and select a subset of SMF   
               records to be created on the ASCII platform;             
               The example shows how to concatenate multiple SMF files: 
                  //SYSIN DD *                                          
                   DATA _NULL_;                                         
                    CALL SYMPUT('DATETXT',DATETXT);                     
                   FILENAME SMF FTP ("'SYS1.SMF'" "'SYS2.SMF'" ... )    
                          USER='XXXXXX' HOST='YYYYYYY'                  
                          S370VS RCMD='SITE RDW' LRECL=32760            
                   FILENAME SMFBKUP "C:\MXG\SMFDATA\&DATETXT" ;         
                   %LET MACFILE=                                        
                        IF ID IN (70,72);                               
                        FILE SMFBKUP RECFM=N LRECL=32760;               
                        PUT BDW &PIB.2. '0000'X RDW &PIB.2. '0000'X     
                            _INFILE_ @;                                 
                   %INCLUDE SOURCLIB(VMACSMF);                          
                   DATA _NULL_;                                         
   Thanks to Michael Gebbia, Eddie Bauer, USA.                          
   Thanks to Glenn Bowman, Wakefern, USA.                               
Change 23.089  Variable DCVDVNUM, the Device Number, is retained from   
VMACDCOL       the DCOLVOLS record and kept in the DCOLDSET dataset;    
Apr 21, 2005   this is possible because the DCOLLECT output is ordered  
               with the DCOLVOLS record before the DCOLDSETs on that    
   Thanks to Frank Lund, EDB IT Drift, NORWAY.                          
Change 23.088 -Variables EV40FLG1 EV40FLG2 and CATGNAME from RACFTYPE=40
EXTY8066       were incorrectly kept in TYPE8007 dataset and were not   
IMAC80A        kept in TYPE8008 dataset, now they are correct.          
VMAC80A       -Variables FROMRESN (13), VOLUME FVOLUME (14) and CLAS26NM
VMXGINIT       (from RACFTYPE/DTP=26) are kept in TYPE8019.             
Apr 23, 2005  -FROMVOLS in RACFTYPE=6 for RACFEVNT=8 is an 8-byte field,
Apr 27, 2005   but MXG only input 6 bytes, shifting SECLEVEL/SECLABEL.  
May 12, 2005   Now, FROMVOLS is input as $EBCDIC8 and the "undocumented"
May 17, 2005   +2 bytes are removed from that INPUT statement.          
May 29, 2005  -Variables KW09IG06 ande KW09SP06, UNIVERSAL, added to    
May 30, 2005   dataset TYPE8009                                         
              -Variables SECLEVEL,SECLABEL,KW11SP28-29,KW11IG28-29      
               added to TYPE8011.                                       
              -Variables CLASSP02,04,05,06 added to TYPE8010,TYPE8013.  
              -Variable KW19CL07 added to TYPE8019.                     
              -Variables KW19FC00-KW19FC07 replace 00-04, which were    
               incorrectly decoded.                                     
              -Variables KW24S102-S109 added, decoded from KW24RSV1.    
              -Variables KW25VI00-VI01 added, decoded from KW24OVIO.    
              -Variables KW59ST00-ST06 added, decoded from KW24STAT.    
              -Dataset TYPE8066 created for RACDCERT command; however,  
               only the standard RACF variables are output in this      
               iteration - time ran out for 23.02 QA, but this record   
               will be fully decoded in the next iteration.             
              -Variable LOGSTR change length to 200 from 64, but not    
               until May 12!                                            
              -Additional variables, thru KW24S132, KW24I117, KW24KERB  
               are decoded, May 17.                                     
              -ACEEUSER variable now kept in TYPE8024.                  
              -Second (290) should have been (291).                     
              -KW24SP46/KW24SP47/KW24IG46/KW24IG47 are corrected.       
              -KW11xx13 and later were incorrectly aligned with th4eir  
               bits and labels, and KW11xx28 and KW11xx29 should not    
               have been created for ALTDSD event.                      
              -KW10ER00-KW10ER31 are now decoded and kept in both the   
               TYPE8010 and TYPE8013 datasets;  all three of the sets   
               of bit maps KW10ERnn, KW10IGnn, and KW10SPnn are the same
               for ADDUSER (10) and ALTUSER (13), except that some bits 
               that can be enabled for ADDUSER won't be for ALTUSER.    
   Thanks to Bill Arrowsmith, Euroclear, BELGIUM.                       
   Thanks to Andrew Davis, Euroclear, BELGIUM.                          
   Thanks to Aimee Steel, Euroclear, BELGIUM.                           
Change 23.087 -If USERADD= contained two references (SYNC/208 SYNC/214) 
UTILBLDP       with different SMF IDs, UTILBLDP generated incorrect code
VMXGINIT       but now it will use only the first reference.            
BUILDPD3       failed.  Unfortunately, because of macro timing issues,  
BUILD001       the only way UTILBLDP can create a %INCLUDE statement    
BUIL3001       for EXPDBOUT= required a new macro variable, &BLDPOUT,   
Apr 21, 2005   to be defined in VMXGINIT and inserted in the BUILxxxx   
               members where _EPDBOUT is invoked.                       
   Thanks to Robert Chavez, OfficeDepot, USA.                           
Change 23.086  DB2STATS variable QDSTNQR2 should not have been DIF()'d. 
VMACDB2        Variable QDSTQDBT should have been, and now is DIF()'d   
Apr 21, 2005   as it contains accumulated values.                       
   Thanks to Fred Nijdam, Rabobank, THE NETHERLANDS.                    
Change 23.085  Dataset ICEBRGCH old variables ENDTIME,STARTIME were not 
VMACICE        adjusted in VMXGTIME macros, old variable CHANSPED is now
Apr 19, 2005   converted to bytes and FORMATed MGBYTRT as it is channel 
               speed in Bytes per second, and new PCHANBY variable is   
               created.  When ICEBERGs are shared across systems, you   
               must choose data from only one system, since each system 
               creates a replicated SMF record for each interval.       
   Thanks to Chuck Hopf, MBNA, USA.                                     
Change 23.084  The UTILEXCL utility now has "standard" MXG macro tokens 
EXCICDIC       _VCICDIC/_WCICDIC/_PCICDIC/etc instead of hard-coded name
IMACICD8       for the CICSDICT dataset.                                
UTILEXCL      -Optional CANVRSN field is now supported in IMACICD8.     
Apr 19, 2005                                                            
   Thanks to Michael Oujesky, MBNA, USA.                                
Change 23.083 -Variable NRCPUD, the number of CPU segments in "this" MVS
VMAC7072       SMF 70 record is now kept in datasets TYPE70 and TYPE70PR
Apr 18, 2005   as it describes the maximum engines this system could use
               perhaps as an upper bound on engines under IRD control.  
               variables have been reinstated in TYPE70 dataset, as it  
               turns out they are useful in IFA analysis.               
   Thanks to Art Cuneo, Health Care Service Corporation, USA.           
   Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.  
Change 23.082  ***ERROR. QWHSLOCN CONTAINS UNICODE TEXT message printed 
VMACDB2H       with DB2 V8 record, so that I could see what IBM stored  
Apr 18, 2005   in QWHSLOCN when QWHSFLAG='80'X.  Now, with this first   
               instance of QWHSFLAG on, I can see that the text value   
               in QWHSLOCN is simple ASCII data, so MXG's INPUT of the  
               QWHSLOCN is now revised to INPUT either EBCDIC or ASCII  
               based on QWHSFLAG.  The IBM documentation for QWHSFLAG in
               the DSECT is "%U fields contain Unicode UTF-8)", which I 
               assumed meant that QWHSLOCN would contain UNICODE data   
               (i.e., 2-byte, DBCS text), but I've now googled UTF-8 and
               find that UTF-8 is an ASCII-preserving encoding method,  
               so the INPUT with $ASCII16. is all that is needed!       
               With the ERROR message, the only error is that the value 
               in QWHSLOCN, Local Location Name, was trashed.           
   Thanks to Ian Arnette, Toronto Dominion Bank, CANADA.                
   Thanks to ???        , Toronto Dominion Bank, CANADA.                
Change 23.081  Changes in WLM Service Policy can be tracked by TYPE9024,
VMAC90A        now that the new policy name is input as SVPOLNSP from   
Apr 17, 2005   the IWMVSPOL DSECT.                                      
   Thanks to Chuck Hopf, MBNA, USA.                                     
Change 23.080  Support for RMF III IFA data added by z/OS 1.6.  New data
VMACRMFV       was added to ZRBASI and ZRBENC datasets.  No change was  
Apr 17, 2005   required to the ASMRMFV program, which automatically sees
               and writes out the longer records.                       
   Thanks to Jerry Urbaniak, Acxiom CDC, USA.                           
   Thanks to Robert Vance, Zurich Insurance Company, USA.               
Change 23.079  INVALID DATA FOR MM in NDM NDMRTYPE='SS' SMF record.  MXG
VMACNDM        input two bytes that should have been substringed from   
Apr 14, 2005   NDMSID0, which also should have been INPUT as $CHAR8 and 
               formatted $HEX16 because it can have hex and character   
   Thanks to Bernie Mazur, Bank of Montreal, CANADA.                    
Change 23.078  The path activity report is enhanced to report the CMR   
ANALPATH       (which can be significant for FICON channels) and the OTH
Apr 14, 2005   pend time in separate columns on the report.             
   Thanks to Tony P. Steward, CSC, ENGLAND.                             
Change 23.077  ***ERROR.TYPE110.SUBTYPE 2. CICS STAT RECORD STID=106.   
VMAC110        MXG missed an 8-byte reserved field before PIWPGMNM, and 
Apr 13, 2005   incorrectly only "skipped" 1160 bytes of the 1168 STILEN.
Apr 15, 2005   The last three variables, PIWPGMNM, PIWCONNM, PIWUSECT in
               dataset CICPIW were wrong.                               
   Thanks to Roland Schiradin, Alte-Leipziger, GERMANY.                 
   Thanks to Lambros Theodorides, Alte-Leipziger, GERMANY.              
Change 23.076  Invalid Package Data detected. The pseudo SMF 101 record 
TYPSTHST       created by BMC's DB2 THRDHIST file contain a standard    
Apr 12, 2005   triplet for the first 10 packages, like an IBM IFCID 0003
               record, but then, additional segments are written to the 
               end of the 32752 byte record.  Unfortunately, there is   
               only room for 69/70 segments.  Instead of writing a valid
               IFCID 289 record with additional segments, THRDHIST puts 
               part of the next segment, as many bytes as fit, to fill  
               the records (splitting in the middle of a field!), and   
               then creates a new record, without header, with the rest 
               of that segment, followed by the remaining packages.     
               This is an invalid architecture, to split fields across  
               physical records.  Until BMC redesigns its file, the best
               MXG can do is to process those 69 or 70 segments that are
               complete, and report with a message to the SAS log that  
               additional package segments existed but could not be     
               processed.  (Prior to this change, MXG tested the triplet
               to ensure MXG did not read beyond the end of the record, 
               but when the product of number of segments times their   
               length exceeded the record size, all packages were just  
               skipped, without an error message).                      
   Thanks to Bernd Rueckrich, R & V Versicherung AG, GERMANY            
Change 23.075 -UTILEXCL.  Optional CMODNAME='RMI',CMODHEAD='DB2CLOCK'   
UTILEXCL       did not generate an UNKNOWN FIELD SKIPPED message, and   
IMACICUS       did not skip that field in the created IMACEXCL code.    
Apr 11, 2005   The MXG code for a CMODNAME='RMI', with multiple fields, 
               decoded in IMACICRM was revised to recognize this new    
               RMI variant (which is not to be confused with yet        
               another RMI-containing segment with CMODNAME='DFHRMI'    
               that is supported in IMACICRD!                           
              -IMACICUS.  Cosmetic; comments were clarified.            
   Thanks to Christen Ole Christiansen, IBM, DENMARK.                   
Change 23.074  This Analysis of FICON Open Exchanges is based on work by
ANALFIOE       Dr. Pat Artis that was documented in Change 21.087.  He  
Apr 11, 2005   has revised his calculation, slightly, by inclusion of   
               the new DLYCMRTM, the Command Response Time, which is a  
               subset of PEND time that occurs after the channel has    
               selected the I/O for processing, in his note "Managing   
               Complex FICON Configurations."  DLRCMRTM is added to the 
               calculation by this change.                              
   Thanks to Scott Barry, SBBWorks, USA.                                
   Thanks to Mike Crowder, Humana, USA.                                 
Change 23.073  Variable MODEL, taken from DEVMODEL, is a numeric value  
ASUMCACH       that is added to the BY list in TRNDCACH to provide more 
TRNDCACH       granularity in the summarization.  All values of MODEL   
Apr 10, 2005   are numeric (3390 33903 33909), but this revision will   
               need revision if a non-numeric DEVMODEL is ever created. 
   Thanks to Diane Eppestine, SBC, USA.                                 
Change 23.072  Support for APAR OA09921 for IBM TotalStorage DS6000 adds
VMAC78         the Preferred Pathing Function, with these new variables 
VMAC79         in type 78 subtype 3 records:                            
Apr 10, 2005    -TYPE78CF - R783CPAT - PATH*ATTRIBUTES                  
                -TYPE78CU - LCUDST   - DATA STATUS BITS                 
                -TYPE78IO - R783CSS  - CHANNEL SUBSYSTEM ID.            
               and in type 79 subtype 14 records                        
                -TYPE79E  - R79ECPAT - PATH ATTRIBUTESS                 
                -TYPE79E  - LCUDST   - DATA STATUS BITS                 
Change 23.071  Enhanced IFA summarization in PDB.RMFINTRV, PDB.ASUM70PR,
VMXGRMFI       PDB.ASUM70LP, and PDB.ASUMCEC.  However, you have to be  
VMXG70PR       careful in understanding how IFAs are reported; they are 
VMXGDUR        much like CPs when they are shared across LPARs:         
Apr 16, 2005   - "System-level" datasets (RMFINTRV/ASUM70PR/ASUM70LP)   
                 can NOT provide accurate utilization of shared IFAs.   
                 If you have 4 shared IFAs and two MVS systems, these   
                 system obs do have the IFAACTTM (IFA CPU time) used by 
                 that SYSTEM/LPAR, but each obs will also show there    
                 were 4 IFAs, so any percent-used calculation will be   
                 only this system's part of the utilization of all four 
                 installed shared IFAs.                                 
               - "CEC/CPC-level" dataset PDB.ASUMCEC does correctly sum 
                 the IFAACTTM across all systems running on that CECSER,
                 and the PCTIFABY in PDB.ASUMCEC is the correct percent 
                 utilization of all four IFAs by both LPARs.            
              -VMXGDUR was enhanced with operands for interval values of
               10-minute and 5-minute.                                  
   Thanks to Scott Weiner, WPS Insurance Corporation, USA.              
Change 23.070  IBM cannot guarantee that RMF STARTIME values will be the
VSETZERO       exact-on-the-minute value that you thought you'd get when
VMAC7072       SYNC(SMF) is specified in ERBRMFxx member of parmlib:    
VMAC71           "When RMF Monitor I runs with SYNC(SMF) option, RMF    
VMAC73            will be triggered by SMF via ENF37 at the end of the  
VMAC74            SMF interval.  SMF sends this ENF37 signal shortly    
VMAC75            before the interval end, and RMF starts its interval  
VMAC76            processing after receiving that signal.  During this  
VMAC77            interval processing, RMF sets the interval start time 
VMAC78            for the next interval in the SMFxxIST field, and you  
VMAC79            must expect some deviation in SMFxxIST time values;   
VMACCMF           since SMF ENF37 is sent shortly before the interval   
VMACEPMV          end, SMFxxIST times can also be earlier than the end. 
Apr 10, 2005      If you use SMFxxIST field data, which only have one   
                  second granularity, you must plan to tolerate small   
                  deviations in SMFxxIST times."                        
                    per Peter Muench, IBM RMF Development, Germany.     
               IBM's SMFxxIST is the STARTIME variable in MXG RMF data. 
               Data with STARTIME at :59 seconds instead of :00 caused  
               the HOUR of the STARTIME to be one hour early, so with   
               IBM's note that STARTIME cannot be guaranteed to be the  
               expected exact minute, it is now up to MXG to detect and 
               correct STARTIME in your RMF datasets.                   
              -New VSETZERO member is %INCLUDEd in all RMF-processing   
               code members to detect that seconds of STARTIME were     
               58, 59, or 01, and it resets the STARTIME to the exact   
               correct hour:minute:00 value.                            
              -Note that it is still possible to have STARTIME values   
               that are not exact minutes; for example, the value in    
               Change 23.069 of 19:59:40 would not be changed.          
   Thanks to Wolfbang Vierling, Allianz, GERMANY.                       
   Thanks to Bernd Tekath, Allianz, GERMANY.                            
Change 23.069 -RMF Interval less than one minute caused incorrect data  
VMXG70PR       in PDB.ASUMCEC, because MXG logic recalculated STARTIME  
Apr  9, 2005   (only for PDB.ASUMCEC) to the nearest exact minute value.
               The STARTIME was 19:59:40 and DURATM was 19 seconds, due 
               to a WLM Policy Reset just before 20:00:00, with a normal
               15 minute interval with STARTIME of 20:00:00, but the obs
               in PDB.ASUMCEC had STARTIME of 20:00 with DURATM=19 secs,
               and all the calculated PCTxxxxx values were all wrong.   
               This change removed the code in VMXG70PR that modified   
               STARTIME for PDB.ASUMCEC, which corrected the error due  
               to the short interval data, but ONLY because all of the  
               SYSTEMS on this CEC had identical short intervals, and   
               because MXG default _DURSET in IMACRMFI was in effect,   
               causing each original STARTIME value was to be output    
               (i.e., no summarization to a new INTERVAL was requested).
               The result was that there were two observations created  
               in PDB.ASUMCEC, one with its STARTIME of 19:59:40 and    
               DURATM of 19 seconds, and one at STARTIME of 20:00:00    
               with DURATM of 15 minutes, and each was valid, because   
               all of the SYSTEMs had the same short interval data.     
              -But if you want PDB.ASUMCEC summarized so that only one  
               observation is created at the "expected" 15-minute DURATM
               then you must tailor the IMACRMFI member to set STARTIME 
               to the 15 minute time, and then that short interval will 
               be summed into a 19:45 STARTIME with DURATM of 15 min.   
               REQUESTED.  For example, if systems have 15 minute and   
               hourly RMF data on the SAME CEC, PDB.ASUMCEC dataset has 
               an observation on the hour with DURATM of 60 minutes, but
               there will also be hour:15, hour:30, and hour:45 STARTIME
               observations with DURATM of 15 minutes, and all of that  
               data in PDB.ASUMCEC is likely wrong.  Only if you set the
               IMACRMFI summarization to hourly can MXG create a valid  
               PDB.ASUMCEC dataset from that kind of mixed DURATM data. 
              -Note that it is ONLY the PDB.ASUMCEC dataset that had any
               problems; whether you have short DURATM or mixed DURATMs,
               the PDB.ASUM70PR and PDB.ASUM70LP datasets were always   
               correct, since they are summarized by SYSPLEX SYSTEM.    
                 Nov 10: Not True. See Change 23.289 which is needed.   
              -The IMACRMFI default tailoring sets the interval for the 
               datasets, but that can be overridden if you have tailored
               either the ASUM70PR member or the RMFINTRV member to use 
               their INTERVAL= arugment, instead of changing IMACRMFI.  
               Setting the INTERVAL= or IMACRMFI work equally well.     
              -Change 21.315 reset the STARTIME in VMXG70PR for ASUMCEC,
               but the Change 23.070 enhancements eliminates both that  
               need and this exposure, so that code was safely removed  
   Thanks to Diane Eppestine, SBC, USA.                                 
Change 23.068  BUILDPD3 now sets Condition/Return Code of zero under V9!
VMAC26J3       MXG Change 22.365 fixed the problem for JES2 BUILDPDB and
Apr  9, 2005   this revision fixes the problem for JES3.  Two changes   
               were needed; JOBCLASS is now input as J3CLSONE as $1 and 
               then stored into JOBCLASS, and the initial reference to  
               ACCOUNT1 was relocated after the include of IMACACCT so  
               the length would be set by your IMACACCT tailoring.  An  
               extremely-rare-in-MXG GOTO was used to preserve the flow 
               of execution.                                            
               Nov 3: This did not work as expected and caused zero     
               observations in TYPE26J3; corrected in Change 23.282,    
               added in MXG 23.09.                                      
   Thanks to Diane Eppestine, SBC, USA.                                 
Change 23.067  Cosmetic. MXG 23.02 only.  The four listed members will  
VGETDDS        cause this MXGERROR: message to be printed on the log:   
VGETDSN          THAN THE EXECUTING MXG VERSION OF 23.02....            
VGETENG        Disregard for those members; they were not updated when  
VGETSORT       MXG 23.02 was created.                                   
Apr  9, 2005  -Also, the message text now prints MXGWARN: vice ERROR.   
Change 23.066  Support for RACF Events 27, 28, and 29 for unix          
EXTY8028          dddddd    Dataset   Description                       
EXTY8029          TY8028    TYPE8028  RACF EVT 28 DIRECTORY SEARCH      
EXTY8030          TY8029    TYPE8029  RACF EVT 29 CHECK ACCESS TO DIR   
VMAC80A           TY8030    TYPE8030  RACF EVT 30 CHECK ACCESS TO FILE  
Apr  9, 2005                                                            
   Thanks to Peter Schubert, CITEC, AUSTRALIA                           
Change 23.065 -Variable EXPCTSRD in dataset VXSTOASP was not            
VMACVMXA       deaccumulated, but now it is.                            
Apr  8, 2005  -Variable TCMMIDSZ was changed to bytes by 20.04, but     
Apr 10, 2005   its label still had PAGES instead of BYTES.              
              -Variables PFXSPINC and PFXSPINT were incorrect because   
               their deaccumulation assumed descending order, but these 
               two variables are accumulated in ascending order.        
   Thanks to Fabio Massimo Ottaviani, DTS Italia, ITALY.                
   Thanks to Brian Crow, BT, ENGLAND.                                   
Change 23.064  Dataset TYPE78SP, Virtual Storage Subpool for monitored  
VMAC78         jobs, only contained subpool information below the 16MB  
Apr  8, 2005   line (because I thought a subpool was either above or    
               below when I wrote that code years ago!).  Now, variables
               SUBPOOL5-SUBPOOL9 are created, and they will be populated
               if the subpool for this job allocated above-16MB-space.  
              -The storage variables were not in a LENGTH .. &MXGBYLN   
               statement, so their stored length was the MXG default of 
               4 bytes, which could have caused small truncation if the 
               value was large (e.g., 999M instead of 1G).  They all now
               have the correct length set in a LENGTH statement.       
   Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.  
Change 23.063  Cosmetic.  Label is now ACTRELAP='ELAPSED*TIME'.  Label  
VMACENTX       for prior variable had been copied incorrectly.          
Apr  5, 2005                                                            
   Thanks to Chris Taylor, GMAC Insurance, USA.                         
Change 23.062  Variables SRMWSSDL, SRMWSSD1, SRMWSSD2, SRMWSSD3 in      
VMACVMXA       VXSYTSCG are working set sizes, but were still in pages, 
Apr  5, 2005   which is inconsistent with other z/VM working set size   
               variables, so they are now converted to bytes and        
               formatted MGBYTES.                                       
   Thanks to Kris Ferrier, State of Washington DIS, USA.                
====== Changes thru 23.061 were in MXG 23.02 dated Apr  4, 2005=========
Change 23.061  The SEQENGINE=V9SEQ is now set in CONFIGV9 for z/OS.  You
CONFIGV9       must be at SAS V9.1.3, or you must have HotFix SN-012437 
Apr  3, 2005   if you are using SAS V9.1 or V9.1.2, but almost everyone 
               is now installing V9.1.3, so I deem it safer to use V9SEQ
               now.  The problem is that using V6SEQ does not work when 
               character variables are greater than 200 bytes, and there
               are many new variables that need to be 255 or greater;   
               clinging to V6SEQ because you've not installed a Hot Fix 
               is not fair to all the smarties that are using V9.1.3.   
               If you've not installed that Hot Fix and are still using 
               V9.1/V9.1.2, then you MUST change the V9SEQ in CONFIGV9  
               back to V6SEQ (you cannot use V8SEQ with SAS Version 9). 
               If you want all the historic details of which sequential 
               engine did what, you can search CHANGESS and NEWSLTRS    
               members for V9SEQ for the litany of iterations on what   
               works and what doesn't work.                             
                  (While we can tell that you are at 9.1.3, for sites   
                   still back on 9.1/9.1.2 we cannot tell if you have   
                   the hot fix installed.)                              
Change 23.060  Support for z/VM 5.1 enhanced; all new data supported.   
ADOCVMXA      -Nine new "standard" MONWRITE datasets are created:       
EOAPLCMS         Domain Record dddddd  Dataset   Description            
EOAPLTC0           1      18   MTRCCC  VXMTRCCC  CPU Capability Change  
EOAPLTC1           2      11   SCLIOP  VXSCLIOP  I/O Priority Changes   
EOAPLTC2           5       8   PRCIOP  VXPRCIOP  IOP Utilization        
EOAPLTC3           6      21   IODVSW  VXIODVSW  Virtual Switch Activity
EOAPLTC4           6      22   IODVSF  VXIODVSF  Virtual Switch Failover
EOAPLTC5           6      23   IODVSR  VXIODVSR  Virtual Switch Recovery
EOAPLTC6           6      24   IODSZI  VXIODSZI  SCSI Device Activity   
EOAPLTC7           6      25   IODQDA  VXIODQDA  Activate QDIO Device   
EOAPLTC8           6      27   IODQDD  VXIODQDD  Deactivate QDIO Device 
EOAPLTC9      -Eight existing MONWRITE datasets have new variables:     
EOAPLTCA         Domain Record dddddd  Dataset                          
EOAPLTCB           0       8   SYTUSR  VXSYTUSS                         
EOAPLTCC           2       4   SCLADL  VXSCLADL                         
EOAPLTCC           2       5   SCLDDL  VXSCLDDL                         
EOAPLTCD           2       6   SCLAEL  VXSCLAEL                         
                   3      12   STOASC  VXSTOASC                         
EOAPLVMR           4       1   USELON  VXUSELON                         
EXAPLSL0           4       9   USEATE  VXUSEATE                         
EXAPLSLM           4      10   USEITE  VXUSEITE                         
EXAPLSLN           6      26   IODQDS  VXIODQDS                         
EXAPLSLP      -Domain 10 (Application Server) logic was revised; the    
EXIODQDD       separate decoding of Sample and Event data under two     
EXMTRCCC       separate internal macro pairs (_VAPLSDT,_CAPLSDT) and    
EXPRCIOP       (_VAPLEDT,_CAPLEDT) was replaced with a single internal  
EXSCLIOP       pair (_VAPLAPL,_CAPLAPL) because "Configuration Class"   
FORMATS        data for TCP/IP can be either Sample or Event, or both.  
IMACVMXA      -These new datasets are created from domain 10 records:   
VMACVMXA          Source:  CMS APPLDATA  MDGPROD=5684030MT1020100       
VMXGINIT            MXG Dataset VXAPLCMS 'CMS Multitasking'             
Apr  3, 2005      Source:  TCP/IP        MDGPROD=5735FALSTx0ttt00       
                    Multiple MXG datasets are created, based on the     
                    hex value "x" in MGDPROD:                           
                      x    Dataset   Description                        
                      00   VXAPLTC0  TCP/IP MIB Record                  
                      01   VXAPLTC1  TCP/IP TCB OPEN Record             
                      02   VXAPLTC2  TCP/IP TCB CLOSE Record            
                      03   VXAPLTC3  TCP/IP Pool Limit Configuration    
                      03   VXAPLTCX  TCP/IP Pool Data                   
                      04   VXAPLTC4  TCP/IP Pool Size                   
                      05   VXAPLTC5  TCP/IP LCB Link                    
                      06   VXAPLTC6  TCP/IP UCB OPEN                    
                      07   VXAPLTC7  TCP/IP UCB CLOSE                   
                      08   VXAPLTC8  TCP/IP Link Definition             
                      09   VXAPLTC9  TCP/IP ACB                         
                      0A   VXAPLTCA  TCP/IP CPU                         
                      0B   VXAPLTCB  TCP/IP CCB                         
                      0C   VXAPLTCC  TCP/IP Tree Size                   
                      0D   VXAPLTCD  TCP/IP Home                        
                      0E   VXAPLTCE  TCP/IP IPv6 Home                   
                  Source:  VMRM          MDGPROD=5739A03RM0000000       
                    MXG Dataset VXAPLVMR 'VMRM Workloads'               
               Most of these new datasets have been tested with data,   
               but some of the de-accumulation may be incomplete, as I  
               only have a few observations in some of the TCP/IP data. 
               If you want to use the new data, especially TCP/IP stuff,
               please contact to send your MONWRITE data
               so we can investigate these new metrics together.        
              -ADOCVMXA notes were revised; Richard Steele's paper from 
               1988 was changed into plain text, without control chars, 
               and moved to the top of the member, and IBM Manuals that 
               show you how to set up the MONWRITE Virtual Machine and  
               its Saved Segment are now references to make it easier   
               to enable and gather the MONWRITE data from z/VM.        
Change 23.059 -z/VM format MGVXCMG had wrong values for CSCCMCMG, the VM
FORMATS        Channel Measurement Group, which should have been values 
Mar 31, 2005   1-ESCON, 2-FICON, 3-HiperSockets for z/VM, like z/OS.    
   Thanks to Fabio Massimo Ottaviani, DTS Italia, ITALY.                
Change 23.058  Cosmetic.  Comments referencing Change 22.050 should have
VMACHMF        been 20.018, and Change 22.162 should have been 22.168.  
Mar 31, 2005                                                            
   Thanks to Larry Stahl, IBM Global Services, USA.                     
Change 23.057  UTILBLDP enhancements.  The USERADD= xxxx text required  
UTILBLDP       you to list the "product suffix" xxxx value (e.g., 7072) 
Mar 30, 2005   but if you only listed part of the suffix (USERADD=70),  
               incorrect code was generated and  you got errors.  Now,  
               the USERADD= argument can either be the product suffix,  
               or an SMF record number processed by that product.  And, 
               if you should list duplicate entries (USERADD=7072 72,)  
               UTILBLDP is now smart enough to remove the duplicates.   
   Thanks to Jake M. Drew, MBNA, USA.                                   
Change 23.056  DB2 Trace dataset T102S199 was incorrect; it contained   
VMAC102        only the first segment, and the DBID/OBID were formatted 
Mar 30, 2005   only as $HEX2 when they should have been $HEX4.          
   Thanks to Karthik Vinayagam, Morgan Stanley, USA.                    
Change 23.055  Variable DSEXCP: the label should have been EXCP*COUNT*  
Mar 30, 2005                                                            
   Thanks to Stephen Hahne, Capital One Financial Services, USA.        
Change 23.054  All z/VM variables that had "SLOTS" in their label are   
VMACVMXA       now corrected to contain "BYTES" in their labels, as all 
Mar 30, 2005   of the variables had already been converted from a count 
               of 'slots' to the count of 'bytes'.  These variables also
               had been correctly formatted with MGBYTES format; it was 
               only their label that was incorrect.                     
   Thanks to Kris Ferrier, State of Washington DIS, USA.                
Change 23.053  Variables TTETIME, TTSTIME, and TITIME are now all on the
VMAC119        Local time zone, and their labels all have "GMT" removed.
Mar 25, 2005   TTETIME and TITIME were converted to local but had wrong 
               label, and TTSTIME was not coverted from GMT to local.   
   Thanks to Victor Chacon, Verizon Wireless, USA.                      
   Thanks to Alan Klein, Verizon Wireless, USA                          
Change 23.052 -z/VM MONWRITE POSSIBLE BAD CONTROL RECORD were because   
EOAPLSL0       the 1.17 record test should be SKIP=SKIP-16; instead of  
EOAPLSLM       SKIP-52.  This caused many of the domain 1 records to be 
EOAPLSLN       skipped and were not output.  Fortunately, these are the 
EOAPLSLP       seldom-needed startup information for MONWRITE, and the  
EOdddddd       1.17 record is after all of the critical-to-MXG records. 
VMACVMXA      -The 1.19 record would have been skipped, as its test for 
Mar 25, 2005   MRHDRRC should have been for 19 instead of 17.           
              -MXG architecture enhancement creates new EOdddddd members
               and for "second Output" of a dataset, and defines new    
               macro tokens named _Odddddd for instream override of the 
               exit.  This "second Output" exit is needed when raw data 
               is accumulated, so filtering of observations can't be    
               done during the "first Output" in the DATA step, but only
               after the deaccumulation is available for creation of an 
               interval "usage" variable, USdddddd that is tested in the
               new second Output EOdddddd exit member, so only intervals
               with activity are output during the final pass of data:  
                -The EOdddddd member now tests to not output "nulls":   
                 IF USdddddd GT 0 THEN DO;                              
                   OUTPUT _Ldddddd;                                     
                -The MACRO _Odddddd %%INCLUDE SOURCLIB(EOdddddd);  %    
                 is defined in VMACxxxx, adjacent to the _Edddddd.      
                -The _Sdddddd macro sets contain:                       
                   IF DELTATM GT 0 THEN DO;                             
               Dataset updated thus far to only output active intervals:
                 Dataset  - USdddddd Usage Activity Variable(s)         
                 VXAPLSLP - TICKS  (sum of all clock's ticks)           
                 VXAPLSL0 - TICKS  (sum of all clock's ticks)           
                 VXAPLSLM - PGALLOC                                     
                 VXAPLSLN - SUM(PKTSRCVD,PKTSSEND)                      
              -Example in IHDRVMXA shows how you can skip domains and/or
               records from being output, when you want to select which 
               datasets are created from MONWRITE data.                 
               Some DATA step times reading 1024MB MONWRITE:            
                Elapsed   CPU   WORK MB  Description                    
                  641      87    1382    Output ALL                     
                  589      61     902    Skip Domain 7 (SEEK)           
                  413      20      20    Only Domain 10 (APPL SERVER)   
                  321      18       0    No Output, READ ALL,DDecode Hdr
Change 23.051  Support for z/VM Linux Application Server data creates   
EXAPLSLM       four new datasets:                                       
EXAPLSLN        APLSLM    VXAPLSLM  LINUX MEMORY                        
VMXGINIT       This support is preliminary, and is in process of being  
Mar 16, 2005   validated - the clock tick duration value for Linux times
Mar 24, 2005   is not provided, so actual CPU time is not yet measured  
               in the VXAPLSLP/SL0 Processor records, and the Linux time
               stamp is 18 to 20 seconds earlier than the start of the  
               MONWRITE interval; both issues are to be opened with IBM.
   Thanks to Mike Reeves, Fidelity Systems, USA.                        
   Thanks to Warren Cravey, Fidelity Systems, USA.                      
   Thanks to Rachel Holt, Fidelity Systems, USA.                        
====== Changes thru 23.050 were in MXG 23.01 dated Mar 15, 2005=========
Change 23.050  z/VM MONWRITE dataset VXBYUSR didn't accurately recognize
VMACVMXA       a new LOGON after the same VMDUSER had logged of, causing
Mar 11, 2005   incorrect DELTATM and CPU times for the first interval of
               each LOGON in the MONWRITE file.  The logic now tests for
               a change in CALTODON to recognize each LOGON interval.   
   Thanks to Mike Salyer, CitiGroup, USA.                               
Change 23.049  MQ-Series Variable QWHCCV is renamed to QWHCCVMQ because 
VMAC116        it conflicted with DB2 variable QWHCCV, and when MQ was  
Mar 10, 2005   added to BUILDPDB, the MQ $HEX24. format on QWHCCV made  
               the DB2 QWHCCV jibberish.                                
                  You can make the DB2 QWHCCV print correctly simply    
                  by adding FORMAT QWHCCV $12.;  to your DB2 reports.   
               At the same time, variable QWHSSSID in MQ-Series is now  
               renamed to QWHSIDMQ and labeled 'MQ*SUBSYSTEM*NAME' so   
               that it wont override the DB2 QWHSSSID label.            
               Yes, I know that changing variable names may cause your  
               MQ Reports to fail, but since only bleeding-edge sites   
               have begun to use the MQ data, changing now is better    
               than changing later.                                     
   Thanks to Mike Gebbia, Eddie Bauer, USA.                             
Change 23.048  Amdahl CPUTYPE='2000'X does not populate SMF70ONT, z/OS  
VMAC7072       up time of each engine, so for intervals when engines are
Mar 10, 2005   varied on or off line, MXG cannot accurately calculate   
               the true capacity, since it doesn't know how much of the 
               interval that varied engine was available.  The result is
               that NRCPUS counted 2 engines, but part of a third engine
               was available, and the CPU time in RMF 72 Service Class  
               records slightly exceeded the CPUACTTM of those two CPUs.
               This was detected ONLY by a NEGATIVE CPU UNCAPTURED TIME 
               warning from RMFINTRV, which compares the 70 and 72 CPU  
               times, and there is no cure for the Amdahl deficiency,   
               so this part of this change is only documentation of the 
               expected existence of that message with this processor.  
               (In TYPE70 for this interval, variable CAI3='03'x shows  
               the third engine was varied, so you can confirm the cause
               of the warning message, but I can't use that information 
               to delete the interval without creating more questions!).
              -In addition, this same interval record also caused error 
               DIVIDE BY ZERO; the unexpected SMF70ONT=0 value caused   
               PCTCPUBY to be zero when the new SHORTCPS variable was   
               created (the PCTCPUBY for this record is recalculated    
               later), but the real cause of the DIVIDE BY ZERO ERROR   
               was, as always, a programmer's error in not correctly    
               testing the divisor.  IF PCTCPUBY GT . AND PCTMVSBY GT . 
               is now revised to test both variables for GT zero.       
                  Historic Note:  When I was using Netscape years ago,  
                  and had reported erratic Divide by Zero errors and    
                  had stated that this was clearly a programmer error,  
                  their Senior Technician replied "a divide by zero     
                  error is not a programming error - it is a normal     
                  event that happens with Windows".  B.S.: A DIVIDE     
                  BY ZERO ERROR IS ALWAYS A PROGRAMMING ERROR.          
                    I later found Netscape's problem; I had printed and 
                    the printer was there, but when I had turned off the
                    printer, Netscape failed to test that the printer   
                    was still alive, and failed with the DIVIDE error.  
   Thanks to Robert Blackburn, Dominion Resources Services, Inc, USA.   
Change 23.047  The date part of READTIME,  JHRRDOD, was changed from PD4
VMACESPH       0101303F for 30Oct2001 to 2005066F for 07Mar2005, causing
Mar 10, 2005   INVALID ARGUMENT TO FUNCTION DATEJUL when MXG read the   
               changed data format.  MXG now tests for the new format.  
   Thanks to Larry Riggen, Cinergy, USA.                                
VMACDB2        were incorrectly INPUT in DB2 V7 records; those fields   
Mar 10, 2005   only exist in DB2 V8.  The test IF LENQXST GE 440 for    
               that INPUT should have been GE 460.                      
              -Those five QX variables were not INPUT at all in the STAT
               records, but now are kept and deaccumulated in DB2STATS, 
               for DB2 Version 8.                                       
              -Variable QBGAWS was incorrectly INPUT in DB2 V7 records, 
               but it only exists in V8; logic was corrected.           
   Thanks to Allan Winston, MBNA, USA.                                  
Change 23.045  Support for TMS Release 11 is already in place in MXG, as
TYPETMS5       the Appendix A for the TMC Volume and DSNB records shows 
Mar  9, 2005   no changes to those records.                             
   Thanks to Norm Hollander, CA, USA.                                   
Change 23.044  Two new variables were added to ASUMCACH, and new member 
ASUMCACH       TRNDCACH was created:                                    
TRNDCACH         NREXPOSR - Maximum number of exposures during interval 
Mar  9, 2005     INTCHGEX - Number of intervals in which exposure count 
               Also, labels for IORATE, IORATEC, and DURATM now exist.  
   Thanks to Diane Eppestine, SBC, USA.                                 
Change 23.043  Global Macro Variables EPDBVAR,EPDBCDE,EPDBOUT are now   
VMXGINIT       defined in VMXGINIT, and referenced in their counterpart 
EXPDBCDE       can use those macro variables for "instream" tailoring.  
Mar  9, 2005                                                            
Change 23.042  New SAS options DMSLOGSIZE=999999 and DMSOUTSIZE=999999  
CONFIGV9       with those maximum values that increase the number of    
Mar  9, 2005   lines that can be sent to the log or list windows; the   
               old limit was 99,999.  Unfortunately, these options must 
               be set at SAS initialization, and cannot be set in the   
      file under ASCII.  For ASCII execution, you 
               must either update your sas.cfg file, or you can add     
                -dmslogsize 999999 to the options in your SAS icon.     
   Thanks to Kevin Hobbs, SAS Institute Cary, USA.                      
Change 23.041  This new analysis member calculates the DELTATM between  
ANAL30V        the end of one SMF 30 interval to the start of the next  
Mar  8, 2005   interval for each job, and it also calculates SWAPEDTM,  
               the duration when the job was swapped out after the true 
               INTETIME end-of-interval.  The true "resource duration"  
               of each type 30 interval record (subtype 2, 3, and 6) is 
               from INTBTIME to INTETIME, but if a task is swapped out  
               at the end of the interval, the SMF record is not written
               until the task is swapped back in, which can be minutes  
               or hours later, and since no resources were consumed     
               while the task was swapped out, SMF resets the INTBTIME  
               of the next interval to the SMFTIME of the prior record. 
               So if you look at just the time between INTETIME and the 
               next INTBTIME, you can see very large values, because it 
               is the sum of SWAPEDTM plus DELTATM, but in a test with  
               70,000 interval records, I found a maximum DELTATM value 
               of only 0.37 seconds.  I did discover that the "normal"  
               sort sequence of READTIME JOB JESNR INITTIME was not     
               sufficient for some started tasks (notably OPSOSF) that  
               have multiple instances per system and that start before 
               SMF initialization - those STCs have missing JESNR, but  
               had identical values for those variables for what were   
               separate instances, so SYSTEM ALOCTIME LOADTIME were     
               inserted in the sort sequence to separate them; if that  
               heuristic fails, the DELTATM can be a negative value.    
   Thanks to Dave Thorn, SUNGARD, USA.                                  
Change 23.040  Condition Code/Return Code 0004 is set in ANALPRTR due to
Mar  8, 2005   when there were no observations in PDB.ASUMPRTR; those   
               two macro variables are normally created by CALL SYMPUT  
               in a DATA step, but when there are no observations, that 
               data step is not executed.  To resolve the reference, the
               %LET EARLIEST=; and %LET LATEST=; statements are inserted
               at the beginning of the member, so there is no unresolved
               macro even when there are no observations.               
                  In this open code, the choice was either to use the   
                  pair of %LETs, or to put both macro variables in a    
                  %GLOBAL statement.  Both choices effectively "GLOBAL" 
                  the macro variable, since its value will exist for any
                  later program that references that same name.  One big
                  difference is that using %GLOBAL does not change the  
                  value if the macro variable was already %GLOBALed, so 
                  you could (accidentally?) pick up a prior value, while
                  the %LET will set the always reset the macro variable 
                  value. Finally, while not documented in Change 19.230,
                  using %GLOBAL to initialize macro variables to null   
                  saved measurable CPU time, compared with using the    
                  several hundred %LET statements, so the VMXGINIT      
                  member now only uses %LETs where a non-null initial   
                  value is required.  If ANALPRTR were pervasively used,
                  I'd have put these two macro variables in VMXGINIT,   
                  but it is very old analysis, and the CPU times that it
                  estimates are way out of date, and new printer devices
                  may not be amenable to its thruput measurements, so   
                  using the two %LETs was the simple choice.            
   Thanks to Scott Barry, SBBWorks, Inc, USA.                           
Change 23.039  Archaic variable QTXASUS is now set missing; long ago it 
VMACDB2        was replaced by QTXASLOC, and while it was documented as 
Mar  7, 2005   archaic in ADOCDB2, it caused confusion because it had a 
               value, when it should no longer be used.  Instead, the   
               three variables QTXASLOC, QTXASLAT and QTXASOTH break out
               the suspends for Lock, Latch, and Other conflicts.       
   Thanks to Marty Pruden, Nestle Purina PetCare Co., USA.              
Change 23.038  Code was revised to eliminate MISSING VALUE messages by  
VMAC30         either relocating calculations or by testing prior to    
Mar  7, 2005   the calculation.                                         
Change 23.037 -TYPE30MU and TYPE89 variable MULCURD is now forced to be 
VMAC30         a missing value when the MULCUDF/MULCURT is zero, so that
VMAC89         a value is not carried forward when there are multiple   
Mar  7, 2005   segments.                                                
              -The TYPE30MU decoding now expects MULCUDF=2 to be &PIB.8.
               and MULCUDF=3 to be &RB.8., which is consistent both with
               IBM documentation and the SMF 89 record descriptions.    
               All of my 30 test data has MULCUDF=2 with MULCURD=0, or  
               has MULCUDF=0, so this correction has not been confirmed 
               with real data; I do have 89 test data with MULCURT=2 and
               binary values for MULCURD, so it makes sense to align the
               MXG calculations in 30s with those in the 89 records.    
   Thanks to Scott Barry, SBBWorks, Inc, USA.                           
UTILBLDP       Condition Code 4 was set with SAS V9, because RMFINTRV   
VMXGRMFI       was not protected with OPTIONS DKROCOND=NOWARN when it   
Mar  9, 2005   was executed outside of BUILDPDB code.  Now, RMFINTRV    
               is internally protected, and, in addition, when %UTILBLDP
               is used with BUILDPDB=NO, it generates DKROCOND=NOWARN   
               at the top and resets to DKROCOND=WARN at the bottom.    
                 OPTION DKROCOND=NOWARN is extremely useful for MXG;    
                 it lets me have variables in the KEEP= list that are   
                 optional (e.g.: CICSTRAN has a lot of optional vars    
                 that won't exist unless you open the comments in the   
                 appropriate IMACICxxx tailoring member; using NOWARN   
                 suppresses the normal warning that those variables were
                 not referenced).  But prior to SAS V9, NOWARN was just 
                 my convention to keep unneeded messages from your log; 
                 in V9, SAS now sets Condition Code 4 with WARN, so it  
                 is now necessary to protect all known instances in MXG.
   Thanks to Scott Barry, SBBWorks, Inc, USA.                           
Change 23.035  The incorrect references to _LTY30TD were replaced with  
UTILBLDP       _WTY30TD.                                                
Mar  7, 2005                                                            
   Thanks to Scott Barry, SBBWorks, Inc, USA.                           
Change 23.034  The addition of a new dataset (TYPE30TD) to VMAC30 caused
ANALJOBE       the old ANALJOBE program to fail, because I failed to add
Mar  7, 2005   the needed override for that new dataset into ANALJOBE.  
               Adding overrides for that dataset would have worked, but 
               Scott very nicely revised the logic to use the _Vdddddd  
               macro tokens so that new datasets could be added to any  
               of the VMACxxxx members used in ANALJOBE, transparently, 
               and I don't have to remember to revise ANALJOBE to keep  
               up with future new datasets in the VMACx it uses!        
               He also removed the hardcoded MACJBCK= statement which   
               prevented the use of an instream MACKEEP=.               
   Thanks to Scott Barry, SBBWorks, Inc, USA.                           
   Thanks to Sam Bass, McLane Co., USA.                                 
Change 23.033  Example in comment should have been UTILS2ER instead of  
UTILS2ER       FINDS2ER, which was the earlier iteration; the member    
Mar  7, 2005   FINDS2ER should not have been kept and is now deleted.   
   Thanks to Tom White, SPRINT, USA.                                    
Change 23.032  Variables ASID and TARCASID were not formatted $HEX4. but
VMACTMNT       now they are.  ASID was only $HEX2. and TARCASID had no  
Mar  6, 2005   format, so it printed a decimal value.                   
   Thanks to Scott Chapman, American Electric Power,USA.                
Change 23.031  Variables SRCDSN and TRGDSN do not exist in ICEBR8SN data
VMACICE        set, but were accidentally in the KEEP= list, causing    
Mar  6, 2005   confusion.  They are now removed.                        
   Thanks to Doug Medland, IBM Global Services, CANADA.                 
Change 23.030 -ML-33 of MXGTMNT corrects zero values in these variables 
ASMTAPEE       in the TYPETARC Tape Allocation Recover Event records:   
Mar  2, 2005     DEVNR and UCBTYPE were all 0s.                         
                 DEVNRCHR was blank                                     
                 TARCSTRT and TARCEND had the same timestamps.          
                 TARCELAP was 0                                         
                 TYPESCRN was always 0.                                 
              -ML-33 Mount records now have the Mount Time stamp from   
               the mount message.  Hardware errors caused a 20 minute   
               delay between allocation reserving the drive and the     
               issuance of the mount message.  Allocation handed off to 
               OAM the request for the mount, but before issuing the    
               mount, OAM first made a call to the library to get       
               eligible device pools.  Because of the VTS harware       
               problems, it was late in responding to the request,      
               causing the mount message to be delayed.                 
              -Mar 11: Mount Records Mount Time is still not correct;   
               under investigation.                                     
   Thanks to Scott Chapman, American Electric Power,USA.                
   Thanks to Patricia J. Jones, DST Systems, USA.                       
Change 23.029  The display format for the average service times, which  
VMAC74         are in milliseconds, are now printed by default to show  
Mar  1, 2005   three decimal places:                                    
                 AVGCONMS AVGDISMS AVGIOQMS AVGENQMS            6.3     
               The need for this higher resolution is because the z990  
               changed the measurement resolution from 128 microsecond  
               units to one-half microsecond; Pat showed that with a    
               real value of 192 microseconds, the old resolution with  
               truncation was reported as .1 millisecond, but with the  
               new resolution and rounding, the disk service time was   
               reported as .2 milliseconds per SSCH, causing concern    
               that service time had increased, when, in fact, there    
               was not change in the actual service time, but a great   
               improvement in the measurement of disk service times.    
               His full paper on this subject, "Understanding the       
               Differences between z900 and z990 Service Time           
               Measurements" is available at  
   Thanks to Dr. H. Pat Artis, Performance Associates, USA.             
Change 23.028  DB2STATS variables QDSTCIN2 and QDSTNADS had very large  
VMACDB2        values. MXG deaccumulated them, because IBM documentation
VMACDB2H       did not indicate otherwise, and early test data had all  
Mar  1, 2005   zeroes, but data now shows they should not have been DIFd
               and both are no longer deaccumulated.                    
              -Record with only header 1 and header 2 created false     
               error message that header was invalid.                   
   Thanks to Peter Farrell, Commerce Bank, USA.                         
Change 23.027  Support for IMPLEX Versions 3.1 and 3.3.                 
Feb 28, 2005                                                            
   Thanks to Bob Gauthier, Albertsons, Inc, USA.                        
Change 23.026 -Byte-containing fields were carried as characters; they  
VMACWWW        are now numeric with MGBYTE format to "print pretty".    
Feb 28, 2005  -IIS Web Logs printed INVALID THIRD ARGUMENT FOR SUBSTR   
Mar  2, 2005   because MXG did not expect a zero length URIQVALU.       
   Thanks to Bob Gauthier, Albertsons, Inc, USA.                        
Change 23.025  %UTILCONT(PDB=PDB); failed if //PDB was DISP=NEW, with   
Mar  7, 2005   AND IT RESIDES ON MULTIPLE VOLUMES                       
               The cause is our choice to not issue PROC CONTENTS if the
               DDNAME points to a sequential library, unless you told us
               to by removing SEQUENTIAL from the EXCLUDE= opearand.    
               (The CONTENTS against a sequential library has to read   
               the entire library, including all datasets, because there
               is no directory in sequential librarys).  The problem is 
               that we cannot detect the engine unless the library:     
                a) has had activity, or                                 
                b) a LIBNAME statement has been issued.                 
               To solve that old problem, we used a LIBNAME xxx DISP=SHR
               in UTILCONT so we could always know the engine of the    
               library, but that is what caused this error!             
               In this redesign, for z/OS only, when PDB= is a list of  
               one or more DDNAMEs, the LIBNAME is issued only when the 
               DD is not allocated, then a %VGETENG determines the      
               engine, the MXGENG dataset is deleted, and %VGETENG is   
               reinvoked to get to get the full list of all datasets in 
               that library.                                            
   Thanks to Jeffrey A. Harder, Farm Bureau Insurance, USA.             
   Thanks to Paul Naddeo, FISERV Phildelphia, USA.                      
Change 23.024  CONTROL-D SF2 records were INCOMPATIBLY changed; fields  
VMACCSF2       for SF2PAGE and SF2DPAGE were increased in place from 6  
Feb 25, 2005   to 8 bytes.                                              
   Thanks to Brian Crow, British Telecom, ENGLAND.                      
Change 23.023  ABEND 878-10 with REGION=180M got thru seven systems data
ASMRMFV        before the failure.  REGION=200M processed the data from 
Feb 25, 2005   all ten systems at one time.                             
   Thanks to Chuck Hopf, MBNA, USA.                                     
Change 23.022 -Support for VSM subtype 30.                              
VMACSTC       -HSC V6 made changes to subtype 4, STCVMU dataset, but the
VMXGINIT       SMF record does not agree with the documentation, and the
IMACSTC        result is large and invalid values.  No MXG change has   
EXSTCV30       been made, pending STK corrections to their data or doc. 
Feb 24, 2005  -Apr 18: Debugging PUT statement, un-commented in tests of
Apr 18, 2005   this enhancement, is now re-commented, as it printed an  
               un-needed line of text on the log for each STC record.   
   Thanks to Michael Creech, Fidelity Information Services, Inc, USA.   
Change 23.021 -LP0xxxxx variables were not populated; Change 22.293 was 
VMAC7072       not properly migrated from test to my master library.    
VMXG70PR       Only LP0MGTTM is populated with the CPU time, since all  
Feb 23, 2005   PHYSICAL CPU time is really "management" time.           
Feb 28, 2005  -Variable SHIFT was added to PDB.ASUM70LP dataset.        
               Oct 31, 2005: See Change 23.276.                         
   Thanks to Ken Jones, Xwave, CANADA.                                  
   Thanks to Jim Horne, Lowe's Companies, Inc, USA.                     
Change 23.020  Support for CyberFusion user SMF record.                 
Feb 23, 2005                                                            
   Thanks to Robin Murray, ManuLife, CANADA.                            
Change 23.019  Although using DCOLLECT (see JCLDAYDS JCL example) is the
ASMVTOC        recommended way to "graze" your DASD farm, ASMVTOC can be
Feb 21, 2005   used, but the comments did not give an example of how to 
               use the //VOLLIST DD to exclude volumes.  The comments   
               now show the explicit syntas.                            
   Thanks to Brian Crow, British Telecom, ENGLAND.                      
   Thanks to Fabio Massimo Ottaviani, DTSITALIA, ITALY.                 
Change 23.018  Invalid ID=9 record caused ARRAY SUBSCRIPT OUT OF RANGE, 
VMXGGETM       when UTILGETM was used by JCLTEST8.  The SMF 9 record    
Feb 18, 2005   does NOT contain a subtype, but the first byte was '7F'x,
               with bit 1 (the '40'x bit) on, and that caused MXG to    
               read the bytes 19-20 as a two-byte SUBTYPE value, which  
               contained '0200'x, so SUBTYPE=512. Subtype was originally
               a one-byte field, so only values of 0-511 were valid     
               subtypes. But as subtypes can now be two bytes, and      
               because the array is only used in VMXGGETM to tabulate   
               the count of SMF IDs and their SUBTYPEs, MXG only        
               intended to count subtypes 0-511 (and it protected known 
               larger subtypes, like CICS records from Boole & Babbage  
               by resetting them).  The array error was because MXG's   
               protection was incorrect, the statement IF SUBTYPE GT 512
               should have been IF SUBTYPE GT 511, and that is the      
               statement corrected by this change.  The 02 value in byte
               19 that caused SUBTYPE=512 is SMF9VPC, which identifies  
               the issuer of the Vary Path command that caused this SMF 
               9 to have been written, and I now see a new value        
                  2=Enterprise System Connection Manager                
               previously, only 0=Operator was written, which explains  
               why we are now correcting this problem in VMXGGETM.  BUT:
               The real error is that Bit 1 in SMF9FLG is on, which says
               there's a valid subtype, which is not true for ID=9.     
   Thanks to Charles Bellamy, SCANA, USA.                               
Change 23.017  If %INCLUDE SOURCLIB(ASUMUOW) is used (JCLTESTV8/9 do),  
VMXGUOW        but IMACUOW was not updated to tell MXG that you want us 
Feb 17, 2005   to create observations in PDB.ASUMUOW, your job will fail
               You were not supposed to have to update IMACUOW, but the 
               changes we made to add MQ-Series data to PDB.ASUMUOW were
               always tested with a tailored IMACUOW; I failed to test  
               with the default IMACUOW in MXG 22.22, and we always     
               build the PDB.ASUMUOW dataset in our QA streams, to make 
               sure it is created without error.                        
               The source of the problem is arguably a SAS design error;
               we added the creation of a second dataset in a data step 
               whose first dataset was created as a VIEW, but the       
               default IMACUOW sets OPTIONS OBS=0; to prevent ASUMUOW   
               from sorts of both CICSTRAN and DB2ACCT.  Unfortunately, 
               it turns out that that second dataset is NEVER created   
               when OBS=0 is in effect.  While SAS Technical Support    
               investigates to see if this is a feature or a defect, we 
               circumvent the error by always creating that dataset     
               (_UOWCIC) with zero obs, before the data step with the   
               VIEW, so that it always will exist. If you enable IMACUOW
               to create obs, the dataset is re-created with obserations
               when the VIEW is executed.                               
   Thanks to Alan Chenoweth, EDS, USA.                                  
   Thanks to Linda Piekarski, National Grange Mutual Insurance Co., USA.
Change 23.016  A VM 4.4 system's MONWRITE control block data contained a
VMACVMXA       value of 00028709X instead of the normal 00008709X;      
Feb 17, 2005   change line 5071 to test for both values:                
             IF IPARMLF1 NE 00008709X AND IPARMLF1 NE 00028709X THEN DO;
               while we await a reply from IBM VM Support as to whether 
               this is an error or an undocumented feature.             
   Thanks to Mike Salyer, Citicorp, USA.                                
Change 23.015  If you create a WEEK.SMFINTRV or MONTH.SMFINTRV, your job
MONTHBL3       sort order of PDB.SMFINTRV was changed in MXG 22.13 for  
MONTHBLD       Change 22.320 consolidation of MULTIDD='Y' observations. 
MONTHBLS       The original BY list in BUILDPDB was:                    
WEEKBL3        and the new sort order internally is                     
WEEKBL3T       In the cases that failed, there were multiple instances  
WEEKBLD        of the same STC JOBNAME that was an "early ASID" that had
WEEKBLDD       started before SMF (i.e., it did NOT have a JESNR), and  
WEEKBLDT       both interval records had exactly the same values for    
Feb 16, 2005   READTIME JOB JESNR and INITTIME, but the INTBTIMEs  were 
               .01 seconds out of order, causing the NOT SORTED.        
               The solution is simple: in your WEEKBLD/MONTHBLD members,
               change the BY list for the PDB.SMFINTRV dataset to only: 
                  READTIME JOB JESNR                                    
               to eliminate the exposure.                               
              -While using %INCLUDE SOURCLIB(TYPS30) will create dataset
               PDB.SMFINTRV, that is no longer a recommended way,       
               because that dataset still contains the multiple         
               MULTIDD='Y' obs.  See the example in the text of Change  
               22.320 if you want to create PDB.SMFINTRV directly from  
               SMF without BUILDPDB.                                    
   Thanks to Kevin Fletcher, CONSECO, USA.                              
Change 23.014  Consoldiated into Change 23.012.                         
Change 23.013 -Variable LPARCPUX is now kept in TYPE70PR, because it is 
VMAC7072       the count of logical CPs assigned to the LPAR, and that  
Feb 13, 2005   includes the number of "initial" CP engines, the number  
               of "reserved" CPs (which also includes ICFs, IFLs, and   
               IFAs that are assigned to the LPAR). This is important so
               that enough "reserved" CPs can be known for each LPAR.   
               If too few reserved CPs were defined, you cannot         
               non-disruptively use Dynamic Capacity Upgrade on Demand  
               to implement an upgrade to an LPAR.                      
   Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.  
Change 23.012 -Typos in MXG 22.22 JCL examples:                         
COVERLTR      -JCLTEST9: Line 130, WORKVOL=5 needs a comma.             
JCLTEST8                 Lines 166,168 need // in col 1 and 2.          
JCLTEST9                 Line 392 should be MXGSASV9                    
MXGSASV9      -JCLTEST8 and JCLTEST9:                                   
MXGSASV9                 //TESTQAPM step needs //QAPMJSUM DD DUMMY.     
README        -MXGSASV9: Lines 58 and 60,  JCL needs //.                
UPRINDOC      -MXGSASV8 and MXGSASV9:  the INSTREAM DD should be:       
Feb 12, 2005             //INSTREAM  DD UNIT=SYSDA,SPACE=(CYL,(1,20)),  
Feb 22, 2005             //             RECFM=FB,LRECL=80,BLKSIZE=0     
Feb 23, 2005             The change to LRECL=72 caused unnecessary error
May 23, 2005             when UTILS2ER was run, and there's no value in 
                         changing the historic LRECL from 80 to 72.     
              -Coverltr: Ref to Change 22.133 should be 22.123 for V9.  
              -README    File on CD and the README member was missing an
                         equal sign: SPACE=(80,2,1)) SPACE=(CYL,(25,5)).
                         The PUT should be PUT 'c:\mxgcd\ieb....'.      
              -UPRINDOC: JCL example was missing ending comma, line 11. 
                         Comments updated for example ASCII execution.  
                         The program works, but produces an error; the  
                         lines after the RUN; after %INCLUDE INSTREAM;  
                         were debugging lines that should be deleted.   
   Thanks to Linda Piekarski, National Grange Mutual Insurance Co., USA.
   Thanks to Sam Bass, McLane Company, USA.                             
   Thanks to Jack Basile, PCH, USA.                                     
   Thanks to Francisco Ojeda, SAS Cary, USA.                            
   Thanks to John Mattson, EPSON, USA.                                  
   Thanks to David Klein, DOITT, City of New York, USA.                 
   Thanks to Sam Bass, McLane Company, USA.                             
   Thanks to Brian Felix, Wachovia Corporation, USA.                    
   Thanks to Jim Horne, Lowe's Companies, Inc, USA.                     
Change 23.011  MXG 22.22-22.12. DB2 variables QWHT../QWHU../QWHD./QWHA..
VMACDB2H       from DB2 Trace, CPU, Distributed, Data Sharing Header may
Feb 11, 2005   be blank or missing; the extraneous statement at line 130
Feb 25, 2005     LENLEFT=LENGTH-COL+1;                                  
May 20, 2005   must be deleted.  Of course, they can also be blank when 
               those headers don't exist in a particular record, which  
               is completely normal!  In addition, for SMF records that 
               are created from TMON/DB2 data, that statement caused the
               records have headers at the start, rather than the end of
               the SMF record (which is okay, since they are relocatable
               sections with a "triplet" location pointers); it was MXG 
               recalculation of LENLEFT that was the cause of the error.
               May 20,2005: This error also causes THREADTY variable to 
               be blank when it shouldn't be!                           
   Thanks to Marty Pruden, Nestle Purina PetCare Co, USA.               
   Thanks to C. C. VanHook, DST Systems, USA.                           
   Thanks to Steve Cunningham, DST Systems, USA.                        
   Thanks to Craig Gifford, City of Lincoln NE, USA.                    
Change 23.010  Some fields that could contain '00'x are translated to a 
VMAC119        blank value.  RACFUSER, TTPOL, TTPROF, FCHOSTNM, FCM1,   
Feb  8, 2005   FCRS, FCSUSER, and UDLPHIGH.                             
   Thanks to Bruce Widlund, Merrill Consultants, USA.                   
Change 23.009  The RACF Database "Installation data" filed, INSTDATA,   
VMACRACF       can be $255, but only $40 was input.                     
Feb  8, 2005                                                            
Change 23.008 -Invalid ESS data that cannot be corrected in MXG caused  
IMAC6ESS       INPUT STATEMENT EXCEEDED.  0038x segment had Length=127, 
VMAC6          but only 27 bytes of data, 0027x segment had length=0.   
Feb  3, 2005   While IBM is contacted to resolve their errors, the only 
               circumvention is to insert  MACRO STOPOVER MISSOVER %    
               as the first statement after //SYSIN.  You will still see
              -A 0047x segment had 64 bytes when MXG expected 62, so the
               size of FSSDATA field was increased to 99 bytes in this  
              -The 0044x segment is supported creates ESSOFSTY variable.
   Thanks to Dr. Alexander Raeder, Itellium, GERMANY.                   
Change 23.007  Five CPU variables in QAPMJOBL were incorrectly input as 
VMACQACS       milliseconds (&PD8.3) instead of microsedonds (&PD.8.6). 
Feb  3, 2005   The "8.3" was changed to "8.6" for these variables in    
               the VMACQACS (with Change 22.371 as the last change):    
                 JBCPU   5672                                           
                 JBRUT   5736                                           
                 JBSZWT  5757                                           
                 JBTCPU  5780                                           
                 JBMTXT  5792                                           
   Thanks to Paul Gillis, Pacific Systems Management Pty, AUSTRALIA.    
Change 23.006 -Support for RACF Events 32-34,38-39,42-45,48,50,54-55,57,
EXTY8032       59,61-62, and 64 creates these                           
EXTY8033       these 18 new TYPE80A datasets:                           
EXTY8034          dddddd    Dataset   Description                       
EXTY8038          TY8032    TYPE8032  RACF EVT 32 CHANGE DIRECTORY      
EXTY8039          TY8033    TYPE8033  RACF EVT 33 CHANGE FILE MODE      
EXTY8042          TY8034    TYPE8034  RACF EVT 34 CHANGE FILE OWNERSHIP 
EXTY8043          TY8038    TYPE8038  RACF EVT 38 INIT OF PROCESS       
EXTY8044          TY8039    TYPE8039  RACF EVT 39 TERM OF PROCESS       
EXTY8045          TY8042    TYPE8042  RACF EVT 42 MAKE DIRECTORY        
EXTY8048          TY8043    TYPE8043  RACF EVT 43 MAKE NODE             
EXTY8050          TY8044    TYPE8044  RACF EVT 44 MOUNT FILE SYSTEM     
EXTY8054          TY8045    TYPE8045  RACF EVT 45 OPEN NEW FILE         
EXTY8055          TY8048    TYPE8048  RACF EVT 48 REMOVE DIRECTORY      
EXTY8057          TY8050    TYPE8050  RACF EVT 50 SET EFFECTIVE UID     
EXTY8061          TY8054    TYPE8054  RACF EVT 54 UNLINK                
EXTY8062          TY8055    TYPE8055  RACF EVT 55 UNMOUNT FILE SYSTEM   
EXTY8064          TY8057    TYPE8057  RACF EVT 57 CHECK PRIVILEGE       
IMAC80A           TY8059    TYPE8059  RACF EVT 59 RACLINK               
VMAC80A           TY8061    TYPE8061  RACF EVT 61 IPCGET                
VMXGINIT          TY8062    TYPE8062  RACF EVT 62 IPCCTL                
Feb  9, 2005      TY8064    TYPE8064  RACF EVT 64 CHKOWN2               
              -SMF 80 records with SMF80EVT=0 were discovered and were  
               being output to TYPE80CM dataset (which should always    
               have zero observations, since it is used only for events 
               that are not supported in MXG, and once you have one of  
               those events and send the SMF data, that event will be   
               supported!).  IBM APAR OA03336 documents on condition    
               that causes SMF80EVT=0 and installing the PTF for that   
               APAR eliminated the RACFEVNT=0 observations.             
   Thanks to Peter Schubert, CITEC, AUSTRALIA                           
Change 23.005  An old VMXGSUM member in "USERID.SOURCLIB" caused message
VMXGVERS       (The INSTALL instructions remind you to remove all of the
Feb  2, 2005   VMXGxxxx & VMACxxxx members from your tailoring library  
               when you install a new version.)  But even if you enable 
               diagnosic OPTIONS SOURCE SOURCE2 MACROGEN MPRINT; we can 
               only see members %INCLUDEd from your library; %VMXGxxxx  
               members are AUTOCALLed %MACROs, and they do not print the
               source text on the log.  To prevent these errors due to  
               a back-level %VMXG.... or %VGET.... macro, each of them  
               now invoke the %VMXGVERS macro that compares the member's
               internal version number with the current MXG version, and
               if they are inconsistent, prints this message:           
                 MXGERROR:  VMXGxxxx IS BACK-LEVEL AT NN.MM, ....       
               reminding you to remove that back-level VMXGxxxx member. 
   Thanks to Bill Whitehead, Experian, USA.                             
Change 23.004  Support for SAMS Vantage "LSPACE" record subtype, creates
EXSAMLSP       SAMSLSPC dataset.                                        
Feb  1, 2005                                                            
   Thanks to Christelle Abily, GICM, FRANCE.                            
Change 23.003  Unused Change.                                           
Change 23.002  Comments only.  Description of the arguments for SYSTEM= 
ANALAVAI       and APPn= were confusing, and have been clarified.       
Feb  1, 2005                                                            
   Thanks to Allen O. Homonyom, Department of the Army, USA.            
Change 23.001  NDM Subtype 'SY' caused INPUT STATEMENT EXCEEDED RECORD  
VMACNDM        error; the length in NDMSYOPL included itself, which was 
Jan 30, 2005   not documented, causing MXG to read one byte too many.   
               After the @; after the INPUT of NDMSYOPL, insert         
                 IF NDMSYOPL GT 0 THEN NDMSYOPL=NDMSYOPL-1;             
   Thanks to Victor Chacon, Verizon Wireless, USA.                      
LASTCHANGE: Version 23.