/* Copyright (C) 1984, 1990 Merrill Consultants Dallas Texas USA */    
 /************************   CHANGES ******************************/    
 This is the production MXG Version 7.7, dated February 15, 1990.       
 The Production Version 7.7 of MXG was shipped during the last week of  
 February, 1990, to all supported MXG sites.                            
  MXG Version 7.7  is   dated February  15, 1990, thru Change 7.247).   
  (Newsletter SIXTEEN   dated February  14, 1990, thru Change 7.243).   
  (PRERELEASE MXG 7.6   dated January   29, 1990, thru Change 7.228).   
  (PRERELEASE MXG 7.5   dated December  22, 1989, thru Change 7.207).   
  (PRERELEASE MXG 7.4   dated November  25, 1989, only for an ESP).     
  (PRERELEASE MXG 7.3   dated November  25, 1989, thru Change 7.190).   
  (Newsletter FIFTEEN   dated November  11, 1989, thru Change 7.165).   
  (PRERELEASE MXG 7.2   dated October   19, 1989, thru Change 7.161).   
  (BETA test  MXG 7.1   dated September 14, 1989, thru Change 7.140).   
  (BETA test  MXG 7.0   dated May       31, 1989  thru Change 7.098).   
  (Newsletter FOURTEEN  dated April      1, 1989, thru Change 7.035).   
   Previous Version 6.6 dated January   20, 1989, had 206 changes.      
 Operating System and Subsystem Version.Releases supported in MXG 7.7:  
  MVS/ESA thru 3.1.3 and DFP thru 3.2.                                  
  CICS thru 2.1.                                                        
  DB2 thru 2.2.0.                                                       
  RACF thru 1.9.                                                        
  VM/370 thru Release 6 and HPO thru Release 5 (no known problems).     
  VM/XA SP thru 2.1 plus later PTFs.                                    
  IMS 2.1 and IMS 2.2 (see special note for 1.3).                       
 New Devices Recognized and/or supported in MXG 7.7:                    
  3490 and 9348 tape drives (cart and reel respectively) recognized.    
  3480/3490 Tape Compression (IDRC) recognized.                         
  3390 DASD devices recognized and counted in EXCP3390/IOTM3390.        
 Most important new enhancement in MXG Version 7.7:                     
  MXGTMNT, the long awaited MXG Tape Mount Monitor, captures how long   
   operators take to mount tapes, and identifies which job mounted what 
   tape on which tape drive when, with no system modifications. The     
   monitor wakes up every 2 seconds to scan the UCB chain, and writes   
   a User SMF record when each tape mount is satisfied.                 
 Alphabetic (by acronym, of course) list of major changes, enhancements,
 and new products/versions now included and supported in MXG 7.7:       
  ACF2 'ARE' data sets captured.                                        
  AION Development System SMF record from AION.                         
  VSAM activity included with non-VSAM in ANALDSET I/O analysis by job. 
  ARBITER SMF records from Tangram product.                             
  CMF and RMF records can now be differentiated.                        
  CPU Serials added to RMFINTRV.                                        
  DB2 Audit Class trace type 102 records.                               
  DB2 SQL text ("what he typed in") is captured.                        
  DB2PM-like reporting enhancements for DB2 2.2 in ANALDB2R.            
  DFP 3.2 TYPE42 SMF record.                                            
  DOS/VSE Power 3.1.2.                                                  
  FILEAID SMF record from COMPUWARE product.                            
  GTF format DB2 trace data supported.                                  
  ICF TYPE6156 VOLSER capture and enhancement.                          
  IDRC (Improved Data Recording Compression) for 3480/3490 tapes.       
  IMS 1.3 transaction processing: see Change 7.075.                     
  IMS 2.0 and IMS 2.1 response measurement corrections.                 
  JES2 mods to capture SYSOUT release timestamp in type 6 SMF record.   
  MDFTRACK SMF record from Amdahl MDF environment.                      
  MVS/ESA 3.1.3 SMF and RMF records.                                    
  MVS/ESA CPU timings in step records.                                  
  NAF SMF record from Candle's Network Accounting Facility.             
  NETSPY Release 3.2 SMF record.                                        
  NETVIEW TYPE37 Release 2 Hardware Monitor External Log Record.        
  NETVIEW TYPE39 Release 2 Session Monitor External Log Record.         
  OMEGAMON Command Audit SMF record from Candle.                        
  PDB.STEPS contains STEP accounting fields (if any).                   
  PDSMAN/XP Release 6 SMF record.                                       
  RACF 1.9 (based on SMF 3.1.3 manual) SMF records.                     
  RMF Monitor II Type 79 SMF record (fourteen subtypes).                
  RMF Monitor III VSAM data set records and TYPE72MN enhancement.       
  ROSCOE 5.6 support for variable number of complexity levels.          
  STOPX37 Release 3.3 SMF record from Empact product.                   
  STX Release 1.0+ supported.                                           
  TLMS (Tape Library Management System) catalog records.                
  TMON/MVS data records (non-SMF) from Landmark's Monitor for MVS.      
  TMS (Tape Management System) catalog records.                         
  TPX Release 2.0.0 SMF supported.                                      
  TREND data base validation and enhanced report examples.              
  TSO/MON Version 5.2 SMF record from Legent product.                   
  VM/XA SP 2.1 plus PTFs, and protection for VCOLLECT environment.      
  VMXGVTOC enhanced for VSAM with 128 extents and DASD VTOC data.       
  VSAM TYPE64 PTF to add important data for Hiperbatch aid.             
  Validation and cleanup of all reported MXG 6.6 errors.                
 Pre-release by pre-release delta of changes (for testers, thanks!):    
  Significant changes added in 7.7 that were not in 7.6:                
   Support for Release 3.3 of Empact's STOPX37 product.                 
   IMS 2.2 algorithm enhancements improve IMS log response captured.    
   ANALDB2R updated for DB2 2.2 (most reports, except DDF).             
   Lots of final cleanup from pre-release testing.                      
  Significant changes added in 7.6 that were not in 7.5:                
   Support for all 14 subtypes of the type 79 RMF Monitor II record.    
   Support for VM/XA SP 2.1 plus new PTFs, and integrity enhancements.  
   Enhanced decoding of TYPE6156 ICF Catalog record to add VOLSER(s).   
   Support for Candle's Network Accounting Facility SMF records.        
   Support for Legent's TSO/MON Version 5.2 added.                      
   Support for Landmark's TMON/MVS product.                             
  Significant changes added in 7.5 that were not in 7.3:                
   Support for MVS/ESA 3.1.3, including the major enhancements in type  
    6 SMF record and a new type 42 DFP and 83 RACF SMF records.         
   Support for the VSAM PTF changing SMF 64 record (for Hiperbatch Aid) 
   Support for DB2 Release 2.2.0 changes to 100, 101, and 102 records.  
   Support for Netspy Release 3.2.                                      
   Support for PDSMAN/XP Release 6.                                     
   Validation of NETVIEW type 37 SMF record modem section.              
   Correction of JES3 type 6 (prerelease only) error.                   
  Significant changes added in 7.3 that were not in 7.2 or Newsletter 15
   DB2 I/O, Locking, and Record Trace reports added to ANALDB2R.        
   MVS/XA & ESA Pathing configuration and activity report in ANALPATH.  
   3390 DASD device support is official (support is already in 7.2).    
   RMDS pagecounts are fixed.                                           
   D3330DRV (mountable drive count) eliminated from 30s and PDB.        
   GTF format DB2 type 102 trace data now correct.                      
   VMXGVTOC cleanup (deletes to clean WORK, last track counting, etc.)  
   TPX Release 2.0.0 new release supported,                             
   STX Release 1.0+ new product supported.                              
 Prior changes added in 7.2 and earlier are listed in Newsletter 15.    
 Documentation of enhancements in MXG Version 7.7.                      
 Details on enhancements, and their impact will usually be found in the 
 text of the actual Change description itself.                          
 While Changes can and should be read in the printed Newsletter, it is  
 very helpful to use SPF BROWSE/EDIT to scan the online documentation   
 available in member CHANGES of the MXG Source Library interactively.   
 Member CHANGES contains the current MXG version status and changes that
 have been installed in that software. Member(s) CHANGEnn are copies of 
 member CHANGES as it stood when MXG version nn was created.            
 In addition, the Change Number lists the member(s) affected by that    
 change. Browse those members, especially the ANAL...., IMAC...., and   
 VMAC.... members for further documentation and usage notes.            
 Member NEWSLTRS contains the text of all newsletters (including the    
 newsletter that accompanied that MXG release). You can usually search  
 on product name or acronym to find the MXG acronym and member names    
 that document, support, and process that product's data records.       
 Member DOCVER07 contains abbreviated Chapter FORTY style documentation 
 of just those variables and datasets that were added by MXG Version 7.7
 since MXG Version 6.6, the "delta-documentation".  For example, you    
 could browsing DOCVER07 for the TYPE70 thru TYPE79 (RMF) dataset       
 descriptions, to learn what new information IBM has added to RMF data  
 records. There is a DOCVERnn member in the library for each version.   
 Penultimately, member DOCVER contains abbreviated Chapter FORTY format 
 documentation of ALL 22,277 variables from the 679 MXG data sets that  
 can be created by MXG Software Version 7.7 (alphabetically by data set 
 name and variable name).                                               
 Finally, MXG is a source distributed system, so you can often find your
 answer by BROWSE/EDIT of the source member, especially the VMAC...'s   
 that actually create the data set, or ANAL....'s that create the MXG   
 report.  In many instance, the MXG Variable is the IBM or Vendor's     
 documented field name. In other cases, the IBM field name is carried   
 as a comment beside the MXG variable that contains that information.   
   In looking thru MXG library members online, try these SPF techniques:
    Make a COPY of member CHANGES (don't use the actual member, because 
    you will use an EDIT command, which can delete/change data          
    For example:                                                        
    EDIT a non-existent new member and COPY in (for example) CHANGES.   
    On the command line, enter EXCLUDE ALL.                             
    On the command line, enter FIND "VM/XA" ALL , for example.          
     which will result in your display containing only those            
     lines that contain VM/XA.                                          
    You can then un-exclude the lines before and after each occurrence  
     by typing L5 or F3 on the line number of the excluded lines to now 
     display or un-exclude the Last 5 or First 3 lines.                 
    When done, CANCEL from the command line and nothing will be written.
    The use of SPF commands EXCLUDE ALL and FIND ALL is a major tool in 
     creating and maintaining MXG software.  It's especially useful is  
     scanning through a large number of lines of text, like MXG CHANGES 
     and NEWSLTRS members. Unfortunately, it is only available as a     
     subcommand of EDIT; you cannot EXCLUDE under BROWSE.               
  2. Installation sizing and instructions for MXG 7.7.                  
  The MXG Installation instructions are found in Chapter 32 of the MXG  
  Supplement for version replacement as well as new install.            
  The MXG tape still is distributed as a Non-Labelled (NL) tape with a  
  single file, DCB=RECFM=FB,LRECL=80,BLKSIZE=6160, containing an        
  unloaded Partitioned Data Set containing 1100 members (and about      
  220,000 lines of source) in IEBUPDTE format. Under CMS/SAS this format
  is known to the TAPPDS command instead of the MVS IEBUPDTE program.   
  At 303 feet of 6250BPI tape, MXG no longer fits on those little       
  half-full minireels with 300 feet of tape. (They were only $6.50 each 
  when a full 600 foot reel was $11.75, and in 1984 MXG Version 1 was   
  only 99 feet long.)  Now, for those of you who are still in those dark
  ages and require MXG on 3420 tape reels, MXG arrives on that same 7   
  inch mini reel, but now it's full (and 600 feet now costs $6.50!).    
    If you received a mini-reel instead of a 3480 cartridge, please     
     let us know as soon as you can accept 3480 tape cartridges.        
    We can create about 250-300 cartridges per hour, but only about 100 
     of the reels per hour, and they have more errors!  And cartridges  
     are only $5.75!                                                    
    Judy still holds the world land speed record of 11 seconds per 3420 
     tape mount building MXG Version 4.                                 
  The MXG Version 7.7 SOURCLIB requires SPACE=(CYL,(30,1,199)) with     
  a DCB attribute of DCB=RECFM=FB,LRECL=80,BLKSIZE=23440.               
  The MXG Version 7.7 SASLIB format library (built by the first step    
  of JCLTEST) requires SPACE=(CYL,(2,1,99)) and the blocksize is        
  set when JCLTEST's first step is run.                                 
  See the comments below in the Changes log for compatibility issues    
  with installation tailoring IMAC.... members.                         
  Pre-releases of MXG 7.7 have been installed by over 400 sites this    
  year, and no real problems in installation have been encountered.     
  The major portions of all the important code have been running in a   
  production status at many sites for months.  MXG 7.7 has been better  
  tested than any of the preceding 28 releases, but as it must always   
  be, it's up to you to validate with your own data.                    
III. CHANGE LOG                                                         
==========================Changes Log=================================  
 You MUST read each Change description below to determine if a Change   
 will impact your installation.  All of these changes have been made    
 to this MXG Source Library.                                            
 Member CHANGES of the MXG SOURCLIB will always be more accurate than   
 the printed changes in a Newsletter, because the software is created   
 after the newsletter is sent to the printer!                           
 Member CHANGES always identifies the actual version and release of     
 MXG Software that is contained in that library.                        
 The actual code implementation of some changes in MXG SOURCLIB may be  
 different that described in the printed NEWSLETTER (which might have   
 printed only the easily installed, critical part of the correction).   
 Always read the comments at the beginning of each source member named  
 under the Change Number when you receive a new Version of MXG.         
 Documentation of new datasets and variables, validation status, notes, 
 etc., are usually in comments in the source members.                   
 If you have to install printed changes from an MXG Newsletter, you     
 could copy the affected member(s) from MXG.SOURCLIB into your existing 
 USERID.SOURCLIB and then make these changes therein.                   
 Or alternately, you might create a new PDS, named MXG.CHANGLIB, and put
 these in-between-version changes in that PDS, concatenating it between 
 USERID.SOURCLIB and MXG.SOURCLIB until you get the next MXG version.   
 When you do, you then delete this MXG.CHANGLIB library, as the changes 
 will have been installed for you in the new MXG version.  It is wise to
 record your changes in a member named CHANGES in the installation's    
 USERID.SOURCLIB as a permanent log of tailoring, etc.                  
 Whenever you install changes or test a new version of MXG (or even for 
 your own reports), be extra careful to look on the SAS log for any real
 error conditions. Search for all occurrences of "ERROR:"  "ERROR :"    
 "UNINITIALIZED" "NOT CATLGD", as they usually indicate a serious error.
 PROC PRINT and PROC MEANS of each new MXG-built SAS dataset will go    
 a long way in explaining their contents, and can be examined to detect 
 unusually large, negative, or suspicious values.                       
 Summary of critical actions to be taken in installing new version:     
     a. All IMAC.... members in your USERID.SOURCLIB must be compared   
        with the new IMAC.... members, and if there is a difference,    
        you MUST start with this version's IMAC and retrofit your       
        installation changes. This is especially critical for IMACPDB   
        and IMAC30IO which were changed by several changes.             
     b. It is always wisest to PROC PRINT the first 50 observations of  
        critical datasets created with the new version. A visual scan   
        will easily confirm if there were unexpected changes. This is   
        especially important for PDB.JOBS, which can be affected by     
        user tailoring in IMACPDB.                                      
Completed changes which have been installed and tested in this library: 
NEXTCHANGE: Version  7                                                  
Change 07.247  Amdahl MDF record fields DOMMIN,MAX,TGT,ATGT,DUTIL,NORM, 
VMACMDF        SUTIL,UTIL should have been input as PD4.2 instead of    
Feb 15, 1990   PIB4., and now they are.                                 
   Thanks to Vince Loeffler, G. D. Searle, USA.                         
Change 07.246  QA runs uncovered TMON/MVS variables JISTART and STARTIME
VMACTMVS       that should have been set to LENGTH 8 (because they are  
Feb 15, 1990   datetime stamps). Now they are, and ZDATE is now kept.   
Change 07.245  TSO/MON will capture member names of PDS data sets that  
VMACTSOM       TSO users access, but MXG kept only the first eight names
Feb 15, 1990   in MEMBER1-MEMBER8 (and also did not re-initialize). Now,
               multiple observations are created when necessary so that 
               all member names referenced are in TSOMDSNS dataset.     
   Thanks to Pete Shepard, Ashland Oil, USA.                            
Change 07.244  DASD/MON support did not keep two variables, RSRCNT and  
VMACDMON       RFTCNT in the DMON.... data sets, but now it does.       
Feb 15, 1990                                                            
   Thanks to Greg Scriba, First National Bank of Chicago, USA.          
===========Changes thru Change 7.243 comprised MXG Version 7.7========= 
-Newsletter SIXTEEN accompanied MXG Version 7.7 to Merrill's customers- 
Change 07.243  Alpha testing of TSO/MON release found that USRTHKTM had 
VMACTSOM       been INPUTed with TU4. format but then was inadvertently 
Feb 12, 1990   also divided by 38400. (Before TU4. format existed, you  
               had to INPUT PIB4. and then divide that by 38400 to get  
               a TU4. data field into a SAS Time/Timestamp variable).   
               I probably should change all the old "PIB4./38400" fields
               to TU4. and delete all of the /38400 lines, but that is  
               too risky a fix (and totally unnecessary in execution)   
               this close to production shipment, so I chose to change  
               the TU4. back to PIB4.     At a later time I will make   
               and test the mostly-cosmetic change from "PIB4./38400"   
               to TU4.!                                                 
   Thanks to Pete Shepard, Ashland Oil, USA.                            
Change 07.242  PDB logic and user tailoring are controlled by IMACPDB,  
IMACPDB        (which must always be from the same version of MXG as is 
Feb  8, 1990   the BUILDPDB/BUILPD3 member being executed). Two changes 
               were made:                                               
              -The new _SUMPRN macro allows users to name additional    
               variables in TYPE6/PDB.PRINT data sets that are to be    
               summed in that job's observation in PDB.JOBS. Not likely 
               needed at most sites (but requested by a few), it should 
               have been there along to be consistent with the other    
               standard PDB-build data sets.                            
              -The archaic PROTECT= option was externalized in MXG 6.4  
               into macro _PROTECT so sites could disable protection.   
               SAS Version 6.06 does not have a PROTECT= option, and    
               when you execute under SAS 6.06 with PROTECT= specified, 
               you get a NOTE: that the option is no longer supported,  
               and a condition code of 04 is set by SAS 6.06! This part 
               of this change creates a temporary new style %macro      
               %VMXGPRO which detects SAS version and does not supply   
               the option when you finally execute under SAS Version 6! 
               The comments have been revised in this important member  
               for user's wishing to tailor MXG PDB data sets:          
        Installation exit IMACPDB to control the Performance Data Base. 
        This member externalizes macros critical to building your PDB.  
        Most sites should not have to change this member, unless they   
        want to tailor the contents of the standard MXG PDB data sets.  
        If you tailor member IMACPDB, you must ALWAYS update that old   
        tailoring starting with the new IMACPDB member in a new version 
        of MXG. IMACPDB and BUILDPDB/3 must be at the same MXG version! 
   These following macros are defined here in IMACPDB and referenced in 
    either BUILDPDB or BUILDPD3. Please read comments carefully before  
    changing the contents of these macro definitions, and scan CHANGES. 
  Macro       Purpose/Description                                       
  _PDB6       List of variables kept from TYPE6 in PDB.PRINT.           
  _PDB26J2    List of variables kept from TYPE26J2 (JES2) in BUILDPDB.  
  _PDB26J3    List of variables kept from TYPE26J3 (JES3) in BUILDPD3.  
  _PDB30_1    List of variables kept from TYPE30_1 in PDB.              
  _PDB30_4    List of variables kept from TYPE30_4 in PDB.              
  _PDB30_5    List of variables kept from TYPE30_5 in PDB.              
  _SUMPRN     Subset of _PDB6 variables to be summed into PDB.PRINT.    
  _MAXSTP     Subset of _PDB30_4 variables to be MAXed into PDB.STEPS.  
  _MINSTP     Subset of _PDB30_4 variables to be MINed into PDB.STEPS.  
  _SUMSTP     Subset of _PDB30_4 variables to be summed into PDB.STEPS. 
  _PDBADD2    List of PDB.JOBS variables back-merged into PDB.STEPS JES2
  _PDBADD3    List of PDB.JOBS variables back-merged into PDB.STEPS JES3
  _PDBSUMS    Externalized logic of MXG summing algorithms, should only 
                be changed if _MAXSTP or _MINSTP are changed. Careful!  
  _NODUP      Archaic, needed before SAS 5.16 to disable NODUP option.  
               Since 5.16 is dead, default now enables NODUP option for 
               all PDB datasets that are SORTed in BUILDPDB. The CICS   
               datasets from type 110 are not sorted by BUILDPDB.       
  _PROTECT    Archaic default enables PROTECT=ZZZZZ for most PDB data   
              sets. The PROTECT option goes away in SAS 6.06, and MXG   
              will recognize execution under 6.06 and will not supply   
              the option (thereby avoiding an otherwise unavoidable     
              SAS NOTE: on your log, and a condition code 04!).         
Change 07.241  VM/Monitor USER records do not indicate if a LOGON event 
VMACVMON       occurred. MXG attempted to detect a LOGON in processing  
Feb  8, 1990   User interval records by testing the deaccumulated value 
               of each variable. If a LOGON occurred, its interval data 
               values should be less than the accumulated resources in  
               the preceding record from this user. However, two of  the
               user fields used in LOGON detection are only two byte    
               counters, which can wrap/overflow inside VM/Monitor, and 
               when either DRPCANUS or DRPPOPUS overflowed at the wrong 
               time, MXG falsely detected a logon event, and this caused
               incorrect TTIME, VTIME, etc. values. Now, MXG's algorithm
               for LOGON detection no longer uses the DRPCANUS/DRPPOPUS 
               two byte counters.                                       
   Thanks to Rob Owens, SAS Institute Europe, GERMANY.                  
Change 07.240  TSO/MON Release 5.2 shipped in January 1990 will require 
VMACTSOM       Legent's maintenance tape TSM9002 to correct problems in 
Feb  8, 1990   their capture of service units. TSO/MON Release 5.2 that 
               is accompanied by a Ship Letter Dated Feb 5, 1990 or     
               later already contains TSM9002 (which corrects errors MXG
               found testing a Legent-supplied early beta test tape).   
               The support for TSO/MON 5.2 required an additional MXG   
               change, which could impact the existing MXG variables    
               which contain the swap sizes and maximum swap sizes      
               in both TSOMCALL and TSOMSYST data sets. Prior to 5.2    
               TSO/MON recorded the number of 2K blocks, but now TSO/MON
               TSO/MON records the number of 4K pages. Since all of the 
               swap sizes and high water marks are actually             
               measures of storage (bytes, frames, pages, KB, MB, etc.) 
               which can be printed accurately and uniformly with  MXG's
               MGBYTES format, all of these old variables are now       
               into bytes and formatted with MGBYTES. Unless you test   
               the value of those variables or calculate other report   
               variables, the only impact will be that the size will be 
               printed 396K instead of 99 pages (5.2+) or instead of 198
               2K blocks (5.1 and earlier). This fix also preserved old 
               variables SWAPSIZE, SWAPHIGH, NRSWAPS to protect reports,
               but now swaps are split into two variables each for      
               I firmly believe presenting KB, MB, GigaBytes, and their 
               rates per second is far more communicative than using    
               units of pages, frames, slots, etc., for both the swap   
               size of a single user (which might be 200K, 400K, etc.), 
               and for the total swapping load (which might be 9000G    
               for a 15 minute interval, or 10 MB/sec to/from if 100    
               100K users are swapped once per second). By expressing   
               these transfers of data between memories in MB/sec or    
               similar consistent units, comparisons with channel speed,
               memory speeds, etc. become clearer, not just in TSO but  
               in all subsystems in all operating systems.              
   Thanks to Pete Shepard, Ashland Oil, USA.                            
Change 07.239  Change 7.142 for PR/SM environment corrected CPUWAITM if 
VMAC7072       the number of LPARS was greater than the number of real  
Feb  8, 1990   processors. That fix also corrects an error in CPUWAITM  
               when CPUs are varied ONLINE or OFFLINE under PR/SM.      
               In verifying that the fix solved both problems, it was   
               noted that the fix was made only to PR/SM SHARED,WAIT=NO 
               environment (the normal, expected use of PR/SM). Although
               no one has ever (nor likely will ever) specified WAIT=YES
               for their PR/SM partition, the fix of 7.142 was applied  
               to lines 136200-141000.                                  
   Thanks to Lou DeRosa, Commercial Union, USA.                         
   Thanks to Igor Polevoy, Commercial Union, USA.                       
Change 07.238  Several collected changes to various things.             
ANALAUDT     1.ANALAUDT line 01500001 should be RACFQUAL=107 instead of 
Feb  7, 1990   RACFEVNT=107.                                            
             2.Misspelled SMF6LN3 now correct in text of Change 7.105.  
             3.VMAC37 variables BRFMODEL and BRFTYPE removed from keep  
               list, as they did not exist.                             
             4.VMAC102 variables QW0080CK,QW0082CK and QW0082F1 are now 
               formatted $HEX2. for printing.                           
   Thanks to Susan Marshall, SAS Institute Europe, GERMANY.             
Change 07.237 -NETVIEW NPM Type 28 records occasionally produce MXG note
VMAC28         "nonzero AOF segment for NPMSUBTY F1 (NPM End)". In the  
Feb  7, 1990   two dumps viewed, the AOF triplet does point to a data   
               segment, but it contains trashy data (like an uncleared  
               buffer?). There is no AOF segment documented for the F1  
               subtype (and none expected; this is the stopping of the  
               NPM monitor). It sure looks like an IBM coding error in  
               NETVIEW/NPM, but since it's only impact is the note on   
               the MXG log, and because this is not important, no one   
               has gone thru the tedious process of several calls to the
               support center Level I and Level II until they find that 
               no reported problem exists and IBM then issues an APAR,  
               (Authorized Problem Activity Report), which is IBM's     
               acceptance of the problem, and then they wait for the IBM
               Product Change Team to produce the PTF (Program Temporary
               Fix), that now must be installed (a change, with its     
               exposure to breaking something that was already fixed).  
               Hoping it eventually goes away or gets reported, you can 
               ignore the note for the F1 subtype.                      
              -Variable BASTIME does not exist in subtype 51x and 61x,  
               entry E337883 confirms these values are zero for those   
               subtypes. MXG now causes BASTIME to be missing for those 
               subtypes. Update Nov 2001: See Change 19.221.            
   Thanks to H. Beer, Hessische Landesbank, GERMANY.                    
   Thanks to Siegfried Trantes, Gothaer Versicherungsbank VVAG, GERMANY.
Change 07.236  Support for Empact's STOPX37 Product Release 3.3 added   
Feb  7, 1990   VSTYPE, and VSDTYPE and corrected the length of SELECTBK,
               ACTIONBK, and ACTION37. The Empact supplied SAS code for 
               3.3 is incorrect for at least one field, and this support
               has not yet been tested with actual 3.3 records.         
   Thanks to Duane Reaugh, Empact Software, USA.                        
Change 07.235  DB2 discoveries and enhancements support DB2 2.2.0:      
ANALDB2R     1.DB2STAT0 and DB2STAT1 records have slightly different    
VMACDB2        values for QWHSSTCK (time stamp). To associte the two    
VMAC102        records from the same interval, MXG carries the subtype  
Feb  6, 1990   0 QWHSSTCK into the subtype 1, unless the absolute time  
Feb  8, 1990   delta between the 0 and 1 subtypes was greater than one  
               second (to detect when the previous 0 is the last from   
               one SMF file and the new subtype 1 is the first from this
               system). I assumed one second delta would be enough, but 
               it is not! One site sent these data for adjacent SMF     
               type 100 records:                                        
                      Subtype   SMFTIME (SMF)     QWHSSTCK (DB2)        
                        0        33:42.55           33:42.4624          
                        1        33:43.69           33:43.6992          
                  a. DB2 STCK to SMF buffer delta time is 90 millisecs. 
                     This possibly represents the elapsed time for DB2  
                     to collect and pass the subtype 0 to SMF.          
                  b. Delta from STCK of 0 to 1 is 1.25 seconds between  
                     DB2 time stamps AND delta from SMFTIME is 1.14     
                     seconds suggest a momentary glitch delayed DB2.    
               As a result, the THISSTCK check in VMACDB2 now tests for 
               a delta of 60 seconds between subtype 0 and 1 before a   
               mis-match is declared. (No records are lost).            
             2.The DB2ACCT, DB2STAT0, and DB2STAT1 data sets now contain
               the 16-byte DDF variable QWHSLOCN (This Location Name) if
               this DB2 is part of a Distributed Data Facility network. 
             3.QWHSLOCN was also added to all T102Snnn trace datasets.  
               In the trace record, for DDF, there is a new header with 
               several new DDF fields (including QWHDRQNM, the location 
               name of the Requestor/Server DB2), which is decoded, but 
               kept only in the T102S106 dataset.  Location names are   
               $CHAR16. fields (though in the pre-release, QWHDRQNM was 
               incorrectly $CHAR8.).                                    
             4.Type 102 trace subtype 106 T102S106 variables QWP9....,  
               for DDF are now created and decoded.                     
             5.Variable QXNSMIAP in VMACDB2 is now spellec QXMSMIAP.    
             6.The CPU time of the 4th address space (DDF) is created   
               in QWS4EJST and QWS4SRBT and is added to DB2CPUTM.       
             7.New member XDB2HDR is a debugging aid that decodes the   
               type 102 record header(s). Hopefully you won't need it!  
             8.DDF may create multiple segments in type 100 and 101     
               records (NRQTXA and/or NRQLST greater than 0), but MXG   
               currently only processes the first segment. Once we have 
               real DDF data in hand, we'll decide what to do (i.e.,do  
               we create multiple variables, or multiple observations?).
             9.EDM pool reports from variables QB1TCBA-QB4TCBA and      
               QISEPAGE,CT,FREE,DBD, and SKCT were incorrect (only the  
               ANALDB2R report was wrong; the values were correct in    
               the DB2STAT0 data set), and have been fixed.             
            10.ANALDB2R (DB2PM-like reporting) has been updated thru DB2
               Release 2.2.0. The status of all DB2 reporting is in the 
               comments in member ANALDB2R. Only the SQL TRACE and the  
               Transit Trace reports were not completed in MXG 7.7. The 
               reports are generally updated for DDF fields, but we have
               had no test DDF data.  In all trace reports from DB2PM in
               DDF environment, QWHDRQNM, (DDF location) is printed in  
               the header, but not all MXG trace reports have this one  
               field (although the system parameter report and other    
               important reports have been updated.                     
   Thanks to Siegfried Trantes, Gothaer Versicherungsbank VVAG, GERMANY.
Change 07.234  MXG Algorithms to process IMS log records into IMSTRAN   
IMACIMS        observations now are further enhanced. Variables MODNAME,
VMACIMS        longer be occasionally missing; incorrect KEEP/DROP logic
Feb  5, 1990   in VMACIMS was changed.  A new macro, _IMSVTAM, is now   
               defined in IMACIMS to indicate if VTAM is your IMS access
               method (default _IMSVTAM is yes). For IMS 2.2 or later,  
               VTAMNODE will be captured. Output queue time was missing 
               sometimes because CLINENR was set to LINENR/TERMNR but in
               VTAM environment NODENAME/VTAMNODE should have been used;
               now CLINENR is set appropriately. The response times for 
               WFI and multiple transactions per program schedule were  
               sometimes missing, because only one observation was      
               created for type 35 events, but a type 35 could be both  
               the end of one transaction and the start of a second;    
               MXG now creates multiple observations when appropriate,  
               and this new logic seems to have closed that loophole.   
               I keep hoping each IMS iteration will be the last, yet   
               I know it never will be. This one, though, was a cleanup 
               of many small problems which have existed since Pete     
               re-vamped the original MXG algorithms in 1988!  These    
               changes have been well tested on IMS 2.2 and tested on   
               2.1 data, but not yet on IMS/ESA 3.1 data records.       
               A new debugging macro _IMSDBUG that provides a decoded   
               trace of each IMS log record used in MXG logic is also   
               defined and described in VMACIMS.                        
   Thanks to Pete Shepard, Ashland Oil, USA.                            
   Thanks to Ervin Claxon, Ashland Oil, USA.                            
Change 07.233  VM/370 Monitor MXG dataset VMONPERF variables Q1LOGDRP   
VMACVMON       and Q1LOGDRP were documented in the MXG Supplement p 551f
Feb  5, 1990   as being renames of MN002Q1B/MN002Q2Bm but the change was
               not made in VMACVMON until now.                          
   Thanks to Bob Small, Grumman Data Systems, USA.                      
Change 07.232  Landmark's MONITASK record for TRANSACT='OVHD' does not  
TYPEMONI       contain User segments, and the second fix in Change 7.108
Feb  5, 1990   is now added permanently to prevent STOPOVER when reading
               Landmark-created summary files. Note that OVHD transact  
               do not exist in the "raw" (normal) Landmark records.     
Change 07.231  The new-style macro %GRAFRMF was both defined in this    
GRAFRMFI       member, and automatically invoked as the last line of    
Feb  2, 1990   the member, preventing you from passing/changing any of  
               the macro arguments for RMF reports from RMFINTRV. Now,  
               the member only defines the macro, and no longer invokes 
               it for you.                                              
Change 07.230  The variables kept in PDB.STEPS did not include the nine 
IMACPDB        variables documented on page 278 of the MXG Supplement:  
                USRSZHI/USRSZLOW  that were supposed to have been added 
               back in Version 5!  Now they have been added to the list 
               (in the MACRO definition for _PDB30_4 list in IMACPDB).  
   Thanks to Elliot Weitzman, Oryx Energy Company, USA.                 
Change 07.229  TYPE70PR (PR/SM only) variable PRSMSLIC (dispatch time   
VMAC7072       slice duration) and flag variables DIAG204F, NRPRCHGD,   
Jan 30, 1990   and SLICCHGD (X'204' failure, number of processors were  
               changed, or time slice was changed respectively) were not
               kept, labelled, and the last two were not even created,  
               and PRSMSLIC should have been PIB2.3 instead of PIB3.    
               Fortunately, that it took until now for this to be seen  
               suggests they are not of critical import, but due to     
               detailed debugging by this user, they are now valid.     
   Thanks to Diane Eppestine, Southwestern Bell Telephone, USA.         
===========Changes thru Change 7.228 comprised Prerelease 7.6========== 
Change 07.228  NETSPY 3.2 Appendix B did not agree with actual DSECT of 
VMACNSPY       the T and U records, causing LUUID and LUGTRGT1-4 to be  
Jan 29, 1990   missing (but no ABEND nor ERROR, because the Appendix    
               said to expect 116 bytes, but there were only 108, so the
               conditional INPUT was never executed).Change the test    
               IF NSPYENTL GE 116 to GE 108  and change the subsequent  
               four occurrences of PIB4.6 to PIB2. (for the LUGTRGT1-4  
               variables), and delete the four lines where LUGTRGT1-4   
               are multiplied by 65536,                                 
   Thanks to Brian Cooper, Wyeth-Ayerst Labs, USA.                      
Change 07.227  The alpha test site for Change 7.219 found it deficient  
VMACVMXA       in two places. The calculation of SKIPTHIS was changed   
Jan 29, 1990   to SKIPTHIS=LENGTH-COL-1; and the ELSE INPUT was changed 
               to just INPUT to properly skip over VM/XA spanned        
   Thanks to S. Rolin Hymans, Comparex Belgilux, BELGIUM.               
Change 07.226  VM/XA changes only in pre-releases 7.2+ caused DELTATM   
VMACVMXA       in VMXAINTV to be picked up inadvertently from VXSUMIOD, 
Jan 29, 1990   where it was inadvertently summed. (DELTATM is the delta 
               between interval records of the same type, and is used   
               to calculate rates. In VXDEVTOT, DELTATM is appropriately
               summed, because it aggregates device activity across the 
               day by device address. In VXSUMIOD, however, the interval
               is the aggregate, and DELTATM is now taken from the first
               occurrence within the interval device records. Note that 
               DELTATM between device records in an interval will not be
               exactly the same as the DELTATM between other interval   
               records, because all records are not written at the same 
               time.) The fix: removed DELTATM from the _VSUMIOD macro  
               definition, added DELTATM explicitly after the references
               to _VSUMIOD in building the VXDEVTOT, added ID DELTATM;  
               to the subsequent PROC MEANS for VXSUMIOD, and added     
               (DROP=DELTATM) after the VXSUMIOD reference in the MERGE 
               that builds VXBYTIME.  MXG MACRO _TESTINT, which will    
               process only the interval VM/XA data records, was also   
               updated to properly handle the I/O interval records.     
                A brief benchmark of VM/XA processing costs for 30      
                intervals with 1000 Logged on VM machines shows total   
                MONWRITE output was 37,735,588 (35MB), written as       
                1372 4KB control records interspersed with the 3290     
                data blocks which varied from 4KB to 28KB but averaged  
                16K. That's about one Megabyte per Logged On user for   
                30 intervals (at 15 min intervals, thats 7.5 hours, or  
                one prime shift). MXG  _TESTMW took 70.99 TCB 3090-200  
                seconds for the data step and totalled 117.20 TCB and   
                46,146 EXCP to create all possible data sets and sample 
                VM/XA reports, in 14 elapsed minutes of execution. The  
                _TESTINT macro (keeps only interval records and not all)
                took only 9 minutes elapsed with 40.37 TCB in the data  
                step and 77.33 total TCB with only 31,464 EXCPs.        
   Thanks to Rob Owens, SAS Institute Europe, GERMANY.                  
   Thanks to Margaret Curtis, Rutherford Appleton Laboratories, ENGLAND.
   Thanks to Yam Tan, British Airways, ENGLAND.                         
Change 07.225  This update to DB2PM-like reports enhances  more of the  
ANALDB2R       reports to support DB2 2.2.0 reports, although not all   
Jan 28, 1990   of the new information (especially the DDF Distributed   
               Data Facility information) has been added to all of      
               the existing reporting. See the table in the comments    
               of the member to identify if the report tolerates or     
               exploits the new data fields. Member was renumbered.     
Change 07.224  Typos crept into XMAC71 change 7.038 (to circumvent the  
XMAC71         SAS Error 344 condition) that could cause variable type  
Jan 26, 1990   conflict for variable FRAMES in TYPE71. Line 0318 XMAC71 
               that was    IF FRAMES=. THEN FRAMES=.;                   
               must be     IF FRAMES=' ' THEN FRAMES='        ';        
               (to initialize FRAMES, which is non-existent if MVS/XA). 
   Thanks to Bruce Widlund, Texas Utilities, USA.                       
Change 07.223  Typos crept into ANALPATH, added in MXG 7.3. Line 105    
ANALPATH       should have been HEX4.; vice HEX4; and Line 222 should be
Jan 26, 1990   PDB.TYPE73 vice DB.TYPE73.                               
   Thanks to Christophe Faure, SAS Institute, FRANCE.                   
Change 07.222  Preliminary support for type 79 SMF record written by RMF
EXTY791        Monitor II session to the SMF file. This support used an 
EXTY792        SMF Manual from MVS/ESA 3.1.3 and an MVS/XA 2.2 DSECT in 
EXTY793        ERBSMF79. If I am lucky, it should support all MVS/ESAs  
EXTY794        and MVS/XAs 2.2 and later. If I should be really lucky,  
EXTY795        some of the MVS/370 subtypes and MVS/XA before 2.2 may   
EXTY796        also be processed without error, but caveat user.        
EXTY798        Added in MXG 7.6, the code has yet to read a 79 record.  
EXTY79A        For subtypes 1 thru 12, exact IBM field names are used as
EXTY79B        variable names, and one observation is OUTPUT for each of
EXTY79C        the segments in each subtype into the twelve MXG-built   
EXTY79D        TYPE791-TYPE999 + TYPE79A-TYPE79C datasets.              
EXTY79E        For subtypes 13 and 14, because they so parallel the type
EXTY79EF       78 SMF record, their dataset names and variable names are
FORMATS        taken from the existing TYPE78, TYPE78CF, and TYPE78CU   
TYPE79         MXG datasets to create these four new data sets:         
Jan 25, 1990     TYPE79D,TYPE79DF,TYPE79E,TYPE79EU                      
                 where Ds (13X) are non-3090s and Es(14X) are 3090 plus.
               The implementation for this subtyped SMF record creates a
               _VAR... and _CDE... MXG macro for each subtype, allowing 
               you to construct programs for selected subtypes, if your 
               really need to.                                          
               If you have turned on the right monitoring in RMF Monitor
               II, you should have only subtypes of interest, and the   
               standard MXG program for processing an SMF record:       
               %INCLUDE SOURCLIB(TYPE79); RUN;                          
               will create all 16 of the possible TYPE79.. datasets that
                can be created, and for those of the 14 subtypes that   
                are found in your SMF file, non-zero observations will  
                appear in the associated MXG-built dataset.             
               Alternatively, as an example of this new MXG design for  
                SMF records with subtypes, you could create/execute the 
                following MXG program:                                  
               %INCLUDE SOURCLIB(EXTY79);                               
               DATA _VAR791 _VAR792 _SMF _CDE79S _CDE791 _CDE792 ;RUN;  
               to create only the TYPE791 and TYPE792 MXG datasets from 
               the subtype 1 and subtype 2 SMF type 79 records. If you  
               do create your own subtype-specific program, note the new
               required _CDE79S reference to process the RMF 79 header  
               and product section. (It's already in member TYPE79).    
               Future enhancements might include an "ANAL79" to merge   
               some subtypes together, and might include an "IMAC79" for
               session selectivity, etc.  Let me know what you need.    
   Thanks to Ervin Claxon, Ashland Oil, USA.                            
   Thanks to Tom Skasa, General Electric Medical Systems, USA.          
   Thanks to Sterling Green, General Electric Capital, USA.             
   Thanks to Bob Rutledge, Sherwin Williams Paint, USA.                 
Change 07.221  Change 7.189 (only in  MXG 7.3 and 7.5) was incorrect.   
ASUMCICS       While intended to transparently use either Landmark or   
Jan 24, 1990   IBM CICS transaction data, it failed miserably if either 
               source was missing (but it worked great, when both were  
               present!). Now it self-detects what kind of CICS data    
               you want summarized from the detail transaction data to  
               the PDB.CICS (Trending, summarized) CICS data set. Sorry 
               for not testing all possible alternatives on this one!   
Change 07.220  Line 002000 contained a truncated line, and should be    
XSYSLOG        deleted. (Variable EVENTIME was already calculated just  
Jan 20, 1990   a few lines above).                                      
   Thanks to Freddie Arie, Lone Star Gas, TEXAS.                        
Change 07.219  This change is a series of enhancements to VM/XA Monitor 
VMACVMXA       support.                                                 
Jan 15, 1990 1.VM/XA MONWRITE can span logical records across physical  
               blocks, but VM does not support a "VBS" format, and the  
               2-byte field that could be used for "spanning" flag is   
               a reserved field in VM/XA! As long as the spanned record 
               happened to split on a field boundary, MXG'S Change 7.086
               (which removed STOPOVER), and the robustness of SAS, made
               spanning "supported"!  Now, however, we find 1.13 records
               split in the middle of the 8-byte MRHDRTOD field!  (This 
               occurred at a site that named 240 specific devices to be 
               monitored, causing a 1.14 record that did not leave space
               enough in that page for the 1.13 record to fit!)         
               This circumvention detects a spanned logical record and  
               and notes the encounter on the log, deleting the bad data
               record, and IBM has been notified of their design error. 
               It may be that this is the only exposure, as in most of  
               the other records in which there can be multiple segments
               the individual segments are actually separate logical    
               records and may (accidentally) be protected. How could   
               IBM overlook this design oversight?  Because if you are  
               thinking about "data pages in memory" rather than the    
               resultant "physical block on external storage device",   
               and are simply moving addresses across virtual storage,  
               the operating system takes care of "page spanning" for   
             2.If no Monitor START event precedes each package of VM/XA 
               MONWRITE data, numerous problems result. First, since    
               there is no 1.4 record, the GMT offset delta is unknown, 
               causing all timestamps to be of unknown time zone! All   
               of the records found before an end-of-interval have to   
               be deleted, because BEGINMTR and ENDTIME are unknown.    
               Furthermore, since MONWRITE records contain accumulated  
               data (instead of the actual data for the interval), the  
               first interval will ultimately also be thrown away, as it
               is valid only to initialize values for de-accumulation.  
               Still further, no Monitor START event record means that  
               there is no MTRDEV Configuration record, which is needed 
               to map the static device information (such as device type
               class, path, etc.) to the device activity records. All of
               those variables will be blank in the IOD... datasets.    
               MXG now will process VM/XA data that is not precedeed by 
               a Monitor START record correctly, but even MXG cannot do 
               anything about the missing data.                         
               How can there be no START event? This problem came about 
               at a site using Candle's VCOLLECT product that creates a 
               new MONWRITE file each day with its End-of-Day routine.  
               The second and subsequent files are incomplete. The only 
               safe solution seems to require Candle to STOP/START the  
               monitor as the initial records written to each new day"s 
               MONWRITE file.                                           
               This is not a problem with IBM's MONWRITE-created files, 
               since their ONLY way to dump VM/XA data requires you to  
               STOP and then START the monitor!                         
               The real culprit here is the IBM design in which monitor 
               data records are created that are not self-described and 
               contain no independent information without the prior time
               interval. VM/XA should have looked at RMF design!        
             3.Since no startup records can be guaranteed, the MXG logic
               that attempted to capture VMDTTIME,VMDVTIME and VMDCTIME 
               in the first interval has been eliminated. Until IBM adds
               a flag in the USER data record itself, it is impossible  
               to unambiguously and safely capture these CPU times from 
               USER logon to the first interval.  The remainder of the  
               MXG algorithm to detect subsequent logon events (done by 
               setting variable LOGON) has not been altered.            
             4.VM/XA SP Release 2.1 did not alter the contents of any   
               data records, but several VM/XA APARs have changed many  
               MXG data sets by creating additional variables. As is    
               always the case, member DOCVER07 in the MXG SOURCLIB     
               library provides the delta-documentation of the datasets 
               and variables added.  These support of these IBM changes 
               required these sources of documentation:                 
                  I.  CP Programming Services, Release 2.1 SC23-0370-2. 
                      Appendix B, Monitor Records, which is now the     
                      basic source of documentation of VM/XA records.   
                 II.  VM/XA System Product Release 2.1 Program Directory
                      for VMSUP Level: 8905 for VM36583 and VM37852.    
                III.  INFO/SYS Entry E343842 for VM35968.               
                 IV.  INFO/SYS Entry E337409 for VM35962.               
                  V.  INFO/SYS Entry E336950 for VM35321.               
               a. Variable VMDCPUAD has been added to three MXG datasets
                  for schedule domain, VXSCLADL,VXSCLDDL and VXSCLAEL by
                  VM35321 (supported in MXG 7.0 and later).             
               b. Variable RDEVCUIV flags if Control Unit information is
                  available in the VXIODATD, VXIODVON, and VXMTRDEV MXG 
                  data sets, and RDEVOFFL in VXMTRDEV identifys if the  
                  device was OFFLINE/ONLINE at Monitor START by VM35962.
               c. VM35968 adds information on I/O activity (variables   
                  RDEVSKCT,RDEVSKSM,RDEVWRCT,RDEVRDCT containing Seek   
                  counts and cylinders ('passed over while the arm is   
                  passing over uninteresting data', according to Siebo),
                  and separate counts of Read or Write channel programs 
                  to VXIODDEV at the device level. Variables IORDWRIT,  
                  added to the VXSEKSEK seek trace record that IBM had  
                  previously reported as in error and unusable. This is 
                  thought to mean that seek data is now usable.         
               d. VM36583 and VM37852 add 27 new fields to the interval 
                  VXSYTXSG dataset extending ESTORE (or XSTORE if you   
                  must, even though MVS' used ESTORE long before VM was 
                  able to use "XSTORE") efficiency measurements.        
   Thanks to Phil Strange, BP International, ENGLAND.                   
   Thanks to Martyn Stevens, Barclays Bank London, ENGLAND.             
   Thanks to Rob Owens, SAS Institute Europe, GERMANY.                  
Change 07.218  VM/370 Monitor data variable STGUTIL could be missing as 
VMACVMON       it was not in the RETAIN statement. Now it is.           
Jan 15, 1990                                                            
   Thanks to Rob Owens, SAS Institute Europe, GERMANY.                  
Change 07.217  TYPE76 RMF Trace variables INTRVAVG and AVG were slightly
VMAC76         wrong if the last sample set did not have complete sample
Jan 15, 1990   count. The calculations were corrected to use NSAMPLE for
               NRSETS*SAMP_SET for INTRVAVG, and SAMP_LST instead of    
               SAMP_SET for AVG if _I_=NRSETS (i.e., for last set).     
   Thanks to Steve Cavill, SAS Institute, AUSTRALIA.                    
Change 07.216  TYPE60 VVR variables are now labeled.                    
Jan 12, 1990                                                            
Change 07.215  TYPE6156 ICF Catalog Activity records have been enhanced 
FORMATS        to extract volume serial numbers from the catalog section
VMAC6156       at the end of the record, if a volume segment exists. Up 
Jan 12, 1990   to five volumes (VOLSER1-VOLSER5) will be contained in   
               each observation and multiple observations (sequenced in 
               variable MULT6156) are created if the entry has more than
               five volumes. Catalog records consist of a sequence of   
               catalog cell records, identified by a hex "cell type".   
               Not all TYPE6156 records contain a 04 Volume record; to  
               examine the structure of the catalog segments, variable  
               CATCELLS contains the first 16 cell types encountered.   
               Expected sequences of ICF catalog cells are:             
                   C1 01 03 04                  Non-VSAM dataset        
                   C2 01 05                     GDG Base subrecord      
                   C2 01 05 C8 01 03 04         GDS subrecord           
                   C3 01 02 03 06               Cluster component       
                   C4 01 02 04                  Data component          
                   C7 01 03                     AIX component           
                   C7 01 C4 01 04 C9 01 04      AIX subrecord           
                   C9 01 02 04                  Index component         
                   D8 23                        Secondary VVR           
                   D9 01 02 03                  Path record             
                   E3 03                        Truename record         
                   E4 01 03 04                  User catalog connector  
                   E7 03                        Alias                   
                   E9 21 60 23                  Primary VVR             
                       Multiple occurrences of 02 03 can occur. Multiple
                       04 (volume) occur for multi-volume entries.      
               There are cases with no 04 volume cell in the record.    
               Variable ACTION shows DEFINE action for non-VSAM files   
               files with no 04 cell, and have found SCRATCH action     
               for GDS G0002V00 but there was no C8 entry for that      
               gen!   (The catalog record for a GDS consists of the     
               base GDG entry followed by a C8 01 03 04 for each        
               generation; MXG parses the GooVoo in the entry name      
               and finds its C8 entry in the catalog record to extract  
               the VOLSER(s) of that generation). We have also found    
               catalog records containing only the E3 03 (Truename)     
               entry, and a GDS with only the base GDG C2 01 05 entry.  
               Format $MG060ID now decodes the possible values of the   
               ENTTYPID entry type id field, although we still have     
               found three data values that IBM level 2 could not       
               explain (although they did offer to build a slip trap    
               we were unwilling to install!). Thus far, we have found: 
                A - non-VSAM ("Alien")   N - undocumented               
                B - GDG Base             P - Pagespace                  
                C - Cluster              R - Path                       
                D - Data                 S - undocumented               
                F - Free                 T - Truename                   
                G - Alternate Index      U - User Catalog               
                H - GDG                  V - Volume                     
                I - Index                X - Alias Name                 
                K - VSAM VVR             Y - Upgrade                    
                M - Master Catalog      00 - undocumented               
              Perhaps ENTTYPID will assist in explaining why an ICF     
              entry was changed, but does not have a volume record.     
              For VSAM entries, the catalog record typically contains   
              04 volume records for the cluster, the index component    
              and the data component. In this implementation of MXG,    
              ALL volume records are extracted and stored in VOLSERn    
              variables, in the sequence found in the catalog record.   
   Thanks to Connie Lee, Morgan Stanley, USA.                           
Change 07.214  Sample RMF Monitor III report programs variable DYDELAY  
ZRBRPT1        should have been spelled DVDELAY.                        
Jan  9, 1990                                                            
   Thanks to Brian Redmond, Home Savings, USA.                          
Change 07.213  Support for Candle's Network Accounting Facility (NAF)   
EXNAFENT       SMF records (written by Candle Products CL/SUPERSESSION, 
EXNAFGLI       CL/GATEWAY, and VTAMPLUS) have been added by this user   
EXNAFGOF       contribution. Data sets NAFSTART, NAFSHUTD, NAFENTVA,    
EXNAFGPO       are created from subtypes of these network records.      
EXNAFGPR       This support includes NAF thru Version 145 of Candle's   
EXNAFLOF       CL product line.                                         
Jan  9, 1990                                                            
   Thanks to Gene Quinn, Blue Cross of Rhode Island, USA.               
Change 07.212  Support for TSO/MON Version 5.2 has been added. This     
VMACTSOM       version adds a number of resource fields (swaps, paging, 
Jan  8, 1990   service units, I/O connect time) to the TSOMSYST and     
               TSOMCALL datasets. MXG 7.6 or later is required for      
               TSO/MON Version 5.2 if TSO/MON options ACCOUNTING=YES    
               or DSNAMES=nnn were specified (because TSO/MON inserted  
               data before the accounting/dsname sections, and because  
               MXG did not use the offsets to those sections until MXG  
   Thanks to Ken Dove, Legent, USA.                                     
Change 07.211  Duplicate records were not deleted by the NODUP option   
BUILDPDB       in the PROC SORT of DATA=TYPE70PR because the BY list    
BUILDPD3       was insufficient to guarantee that duplicate observations
Jan  5, 1990   ended up physically adjacent. The variable LCPUADDR had  
               to be added to the end of the BY list in BUILDPDB/3.     
   Thanks to Earl Ryan, Life Insurance Company of Georgia, USA.         
Change 07.210  The OUTPUT statements in _ANALMON deaccumulation macro   
TYPEMONI       are now includes of EXMONSYS, and the first definition   
Jan  5, 1990   (unused) of _ANALMON deaccumulaton macro was removed.    
   Thanks to Glenn Thompson, Comalco, AUSTRALIA.                        
Change 07.209  -Further ANALDB2R report validation fixed Accounting     
ANALDB2R       trace long (max page locks) and total lock suspends,     
GRAFTMNT       corrected ABEND in IOS report if PDB did not contain     
ASUMVMON       IOS trace data, and eliminated uninitialized variable    
GRAFVMON       message if nondefault sort parameters are used.          
Jan  5, 1990  -GRAFTMNT did not properly handle tape mount reporting    
               if multiple systems were used, now it does.              
              -ASUMVMON spelled PFAULT incorrectly as PFAULTT.          
              -GRAFVMON had trailing ./ IEBUPDTE command.               
   Thanks to Bob Olah, Dun and Bradstreet, USA.                         
Change 07.208  Support for Landmark's TMON/MVS product ("TMV or TMVS"). 
EXTMVIOL       are currently created, though there may be more later.   
EXTMVIOD       Landmark cooperated extensively in the development and   
EXTMVIV        testing/validation of this support. Most variable names  
EXTMVJI        are Landmark field names, except for "standard" MXG names
EXTMVJIS       like STARTIME,ENDTIME,DURATM,SYSTEM, etc.                
EXTMVNQ        Release 1.12 of TMON/MVS must be installed (as record    
EXTMVPS        formats have been changed from earlier releases).        
EXTMVSYS       Unfortunately TMON/MVS does not create SMF records, which
EXTMVSW        will necessitate a separate jobstream to read their data 
EXTMVUI        from the MXG-required DDNAME of TMVSIN.                  
FORMATS        The TMON/MVS monitor data can be created in compressed   
TYPETMVS       format (as is Landmark's Monitor for CICS data), and     
VMACTMVS       the MXG-provided "SAS Infile Exit" named TMON (created   
Jan  5, 1990   by member EXITMONI as described therein and in the       
               CICS chapter in the MXG Supplement) can be used to allow 
               MXG to directly decode their compressed format data.     
               After the "TMON" exit has been installed by EXITMONI     
               change "INFILE TMVSIN" to "INFILE TMVSIN TMON" to invoke 
               that exit which will handle either un-compressed or the  
               compressed data automatically.                           
   Thanks to George Greenacre, Landmark Systems, USA.                   
               Note added Oct 24, 1990. Landmark renamed Release 1.12 to
               Release 1.1 (went from 1.11 to 1.1!).                    
===========Changes thru Change 7.207 comprised Prerelease 7.5========== 
Change 07.207  IBM added nine new fields to the type 64 SMF record for  
VMAC64         VSAM activity. Added to support IBM's marketing aid for  
Dec 22, 1989   Hiperbatch analysis, these new fields (ACBSTRNO,BUFDRNO, 
               may prove useful in normal VSAM analysis, as the data    
               now indicates concurrent strings, buffer counts, and     
               read/write sequential/indexed flags as well.             
               PTF UY40839 (APAR OY23661) added the data to the type    
               64 record, but failed to update the IDAEXTWA macro to    
               document the order of the new fields!  APAR OY26396      
               contains the actual DSECT of the new fields.             
   Thanks to Lawrence Jermyn, Fidelity Systems, USA.                    
   Thanks to Diane Eppestine, Southwestern Bell Telephone, USA.         
Change 07.206  NETVIEW type 37 record's LPDA (Modem report) section was 
VMAC37         off by a few bytes, and some fields were not formatted to
Dec 22, 1989   display in hex.  The quick fix is to change BRFLSL from  
               $1. to $2. and insert +3 after BRFADDR to align MXG with 
               the apparently undocumented changes in this record!      
   Thanks to Bruce Widlund, Texas Utilities, USA.                       
Change 07.205  DB2 2.1 writes an SMF type 100 record with SUBTYPE='80'x 
VMACDB2        instead of the expected value of 0 or 1. When or why is  
Dec 21, 1989   not known at this moment, but it appears the field that  
               was originally documented as subtype is now a reserved   
               field. This change uses the product section IFCID value  
               to set SUBTYPE when the expected subtype value of 0 or 1 
               was not originally found.  I'm still pursuing this one.  
               Find the lines:                                          
                   @21+OFFSMF DB2BUF   $CHAR4.                          
               and insert this new logic following that @;    :         
                 IF ID=100 AND SUBTYPE NE 0 AND SUBTYPE NE 1 THEN DO;   
                   INPUT @25+OFFSMF  OFFPROD  PIB4. @;                  
                   INPUT @LOC  QWHSSIID PIB2. @;                        
                   IF QWHSSIID=1 THEN SUBTYPE=0;                        
                   IF QWHSSIID=2 THEN SUBTYPE=1;                        
   Thanks to Elliot Weitzman, Oryx Energy Company, USA.                 
Change 07.204  This is a "protective" change to protect you from your   
VMAC6          own system programmers.  A JES2 system programmer at one 
VMAC26         site made incompatible changes to their type 6 and 26    
Dec 20, 1989   SMF records when the site added support for 99,999 JES   
               numbers! This change eliminates the "NOTE: INVALID DATA  
               FOR JESNR IN LINE nnn bytes bb-ee.  linenr : col " if    
               these incompatible records are processed by MXG.         
               What did the system programmer do? The 4-byte EBCDIC     
               field JESNR (which could contain only 0001-9999 in its   
               original EBCDIC format) was changed to a 4-byte packed   
               decimal (SAS PD4.) format! Programs expecting a 4-byte   
               EBCDIC format raised a data exception when they found    
               illegal EBCDIC numeric values in what was now a valid    
               packed decimal field. What did IBM do? As described in   
               the SMF manual, IBM stores EBCDIC value 0000 (which was  
               never a valid job number), and tells you instead to skip 
               3 bytes and read the 5-byte EBCDIC job number from the   
               previously-existing JCTJOBID field. What did MXG do?     
               The TYPE6 data set was okay, but the above "NOTE:" was   
               printed; MXG captured the 5-digit field correctly even   
               with their modfication. However, the TYPE26J2 dataset    
               had blank value for JESNR, and this caused BUILDPDB to   
               put all these jobs into SPIN rather than the PDB. The    
               simple fixes to MXG were:  a) in both VMAC6 and VMAC26J2 
               change  JESNR  4.  to JESNR ??  4.  - this suppresses the
               NOTE: and the Error condition when invalid data found,   
               and b) in both VMAC6 and VMAC26 change IF JESNR NE 0 to  
               IF JESNR GT 0  and c) insert new line in VMAC6 after the 
               line IF JESNR GT 0 THEN INPUT .. JESNR ?? 4. @; reading: 
               IF JESNR EQ . THEN INPUT @65+OFFSMF JESNR ?? PD4. @;     
               The site had made its own mods to JES mods before IBM!   
               Now MXG is robust enough to support this mod.            
   Thanks to Robert Manalo, EDS, USA.                                   
Change 07.203  Change 7.061 was not applied to XMAC74 (which is only    
XMAC74         used to circumvent a SAS limitation in large shops),     
Dec 20, 1989   causing AVGPNCHA, AVGPNCUB and AVGPNDEV to be seconds    
               instead of milliseconds. Applied the changed.            
   Thanks to Bruce Widlund, Texas Utilities, USA.                       
Change 07.202  Prerelease-only correction. VMAC6 corrections to handle  
VMAC6          the SYSOUT release time (Change 7.137, added in MXG 7.1) 
Dec 19, 1989   did not handle JES3 print record variables DATAERR,      
               OUTPRTY, SUPGROUP correctly, and could cause STOPOVER.   
               The INPUT statement after SUBSYS='JES3' OR SUBSYS='SAR'  
               should not have the offsets (OFFTONXT, OFFTONXT+nn).     
               Remove the offset from before variables DATAERR, OUTPRTY 
               SUPGROUP, SMF6RVSJ, and SMF6RSVU.                        
   Thanks to MP Welch, Sisters of Charity of the Incarnate Word, USA.   
Change 07.201  Variable SUBSYS6 has been created, equal to SUBSYS, to   
IMACPDB        identify the Subsystem (JES2,JES3,EXTW,PSF,SAR,EXD,CADI) 
VMAC6          which created the print record. While SUBSYS already is  
Dec 19, 1989   in TYPE6, BUILDPDB already uses SUBSYS from the TYPE30_4 
               (probably not a wise choice now!) Rather than changing a 
               meaning of an existing variable, adding SUBSYS6 here and 
               in IMACPDB (to the _PDB6 macro list of kept variables)   
               avoids a compatibility exposure. Why do you need SUBSYS? 
               Some sites want to recover CPU time spent by printing    
               subsystems (read PSF) by surcharging that subsystem's    
               PRINT charges. Unfortunately, additional CPU time caused 
               by PSF has been shown to occur primarily when a non-PSF  
               data stream is converted, and it is not possible to know 
               if data-stream-conversion occurred from a type 6 record. 
               record.  (Call XEROX at 213-333-2068 for a free copy of  
               publication number 720P60340 "Benchmark Report JES2 vs   
               PSF in Text Oriented Printing" by Tom Bell and Chuck     
               Hopf.  IBM should capture the CPU time for print events  
               and store it in the type 6, or at least a flag bit should
               be set if PSF did convert the data stream. One comparison
               shows if PSF takes 7 CPU seconds for Line Mode JES2 Dump 
               convert and print, a JES2 controlled 3800 Model 3 in Mod 
               1 emulation mode would take 1 sec. But conversion cost   
               may be only half the cost.  A DCF prepared PSF data      
               stream of same size took 3 seconds. Sustained print rates
               of 200 pages per minute are seen feasible for 3800 Model 
               3. The type 6 record does record PAGEDEFS FORMDEFS       
               FONT.... activity for PSF; nonzero counts here does      
               guarantee only that those PSF functions were invoked.    
Change 07.200  NETSPY Release 3.2 added fields to the LU and APPL data  
VMACNSPY       sets, and is now supported.                              
Dec 15, 1989                                                            
   Thanks to David W. Anderson, Chase Lincoln First Bank, USA.          
Change 07.199  TPX Version 2 causes STOPOVER because the length of the  
VMACTPX        subtype 5 is incorrect. Their fix number TGB308A fixes   
Dec 12, 1989   their problem. MXG failed to recognize the redefinition  
               of TPXM1SP0 over its two preceding fields (TPXPESIZ &    
               TPXPECD8) in a subtype 1 record, also causing STOPOVER.  
               This is corrected by inserting a new statement  M4=-4;   
               after the @; after TPXMSMRT $CHAR8. and before the IF,   
               and then putting  +M4  just before (TPXM1SP0-TPXM1SP9    
   Thanks to Larry Doub, RJR, USA.                                      
Change 07.198  Goal Systems PDSMAN/XP Release 6 added five new fields   
VMACPDSM       (incompatibly, in the middle of the existing data!) which
Dec 12, 1989   are now supported by this change. LGJOB, LGMGEN, LGLMM,  
               LGNMM and LGRMGEN were added.                            
   Thanks to Lesley Woolston, Manufacturers Hanover, ENGLAND.           
Change 07.197  MVS/ESA 3.1.3 added numerous new data fields to SMF data.
EXTY42AU     1.TYPE6 data now identifies the Step which caused the print
EXTY42CU       activity, and added security related information in these
EXTY42SC       new PRINT variables:                                     
TYPE42           SPAGELBL STDUPLEX SYSAREA  TMBUPLEX                    
TYPE83         The variables SMF6STNM (stepname), SMF6PRNM (procstep)   
VMAC6          and SMF6DDNM (ddname of print file) have been added      
VMAC1415       to the default list of TYPE6 variables that will be      
VMAC42         automatically carried into PDB.PRINT in MXG's BUILDPDB.  
VMAC80       2.TYPE1415 data variables PDSE, TRUNC, and NULLSEG added,  
VMAC83         and several fields documented as zero if PDSE-managed    
Dec 11, 1989   variable for PDSE-managed datasets counts pages read or  
               written. Before MVS 3.1.1, PDSE was referred to ILIB.    
             3.TYPE80 additional bit added to $MG080AU for BYPASS, new  
               character variable RACFVRMN (version, release, mod level)
               replaces numeric RACFVERS, and new RACFTOSK (security    
               label) added by RACF 1.9.0.                              
             4.New type 42 SMF DFP 3.2 record provides SMS statistics   
               configuration, and audits changes in five data sets      
               built from this record.  Interval buffer statistics for  
               3990 cache controlers (total and by storage class) are   
               in TYPE42TO and TYPE42SC. Control Unit configuration and 
               delta statistics are in TYPE42CU (and SMS managed volumes
               behind that control unit are in TYPE42VL). TYPE42AU      
               audits operator VARY SMS commands, ACTIVATEs in ISMF     
               or SETSMS, or ENF occurred because operator issued a     
               vary command to an SMS-managed volume.  This is a new,   
               and significant source of information for management of  
               System Managed Storage, as well as 3990 statistics.      
             4.New type 83 SMF RACF Audit Record (For RACF Datasets     
               whose security label was changed by ADDSD, ALTDSD,       
               or DELDSD) is now supported in MXG dataset TYPE83.       
             5.Two new SMF options were introduced in MVS/ESA 3.1.3 that
               allow the installation to never loose SMF data. LASTDS   
               and NOBUFFS can specify MSG (console message and continue
               processing with loss of SMF data) or HALT (puts MVS in a 
               restartable wait state) whenever either no buffers or no 
               SMF data set is available to SMF. These options are now  
               contained in MXG TYPE90 dataset.                         
Change 07.196  DB2 2.2.0 changed SMF 102 SMF values in 21,30,31,44,62,  
FORMATS        and 140 IFCIDs, affecting formats $MGD044D, $MGD062S,    
IMAC102        $MGD062O, $MGD140P, and creating $MGD063O. IFCID'S 63 and
VMAC102        106 were changed incompatibly, although only 106 has new 
Dec  9, 1989   variables. The new Distributed Header is decoded, and now
               all header variables are output in T102S106. Twelve new  
               IFCIDs (with many new variables) were added by DB2 2.2.0,
               and these IFCIDS (plus the seven DB2 2.1 IFCIDS that had 
               not been previously decoded) are now supported by MXG.   
               With this change, ALL data produced by DB2 is now thought
               to be supported by MXG. (There may be additional formats 
               added to MXG for a few of these new variables). The list 
               of IFCIDs within class has been updated in IMAC102. There
               are also eight new "trace class" macro definitions that  
               are necessary in MXG (but only until SAS Version 6.06 is 
               universally available; the MXG use of the _DB2TCn macros 
               is necessary only because of an internal SAS limit on the
               number of iterative DO statements, which has effectively 
               been eliminated in SAS Version 6.06). A later change will
               be made to ANALDB2R to provide reports on  these new DB2 
               DB2 elements. Initially, though, the changes primarily   
               support Distributed Data Facility, and the addition of   
               the Monitor Class data records (which contain the same   
               data already available in the DB2ACCT & DB2STAT datasets 
               from the 100/102 records!).                              
               For the record, these new IFCIDs were added by this      
               change: TC1 (153), TC6 (156), TC7 (164,165,166,167),     
               TC8 (125,168), new TC14 (67), new TC15 (154), new TC16   
               (157,158,159,160,161,162,163), new Monitor Class MC1     
               (124,147,148,149,150), new MC4 (155), new AC7 (169),     
               new AC9 (146), new Accounting Class ACT4 (151), and a    
               new Statistics Class ST2 (152)! Whew!                    
               Summary of this change: many hours to decode many record 
               segments which are unlikely ever to be needed by any     
               rational performance analyst!!!!!!!                      
Change 07.195  MXG assigned COMNDTYP of blank for command from a CCB,   
FORMATS        but blank is a CLIST from an FCB. This is corrected by:  
VMACTSOM         Add '40'X to $MGTSOCD format in FORMATS                
Dec  7, 1989     Insert after 033700:    RETAIN COMNDTYP ' ';           
                 Insert after 042200:    COMNDTYP='00'X;                
                 Delete       042800.                                   
               Variable COMND may contain an 8-byte name or a 2-byte    
               command abbreviation padded with nulls instead of blanks,
               which makes testing difficult. The translate function is 
               now used to convert nulls to blanks. In addition, the    
               date part of ENDTIME is wrong if the interval crossed    
               midnight. Correct by insert after line 037000:           
                 IF TIMEPART(SMFTIME) LT STRTTIME THEN                  
   Thanks to Pete Shepard, Ashland Oil, USA.                            
   Thanks to Steve Cavill, SAS Institute, AUSTRALIA.                    
Change 07.194  ACF2 variables ACTMFCBT (buffer text) and ACTMFKEY       
VMACACF2       (record key) were not labeled and not kept, but now they 
Dec  7, 1989   are.                                                     
   Thanks to Ken Williams, ANZ Bank, AUSTRALIA.                         
   Thanks to Raymond Wallace, NRMA, AUSTRALIA.                          
Change 07.193  Support for DB2 Version 2 Release 2 has been added for   
VMACDB2        the DB2ACCT, DB2STAT0, and DB2STAT1 data sets built from 
Dec  6, 1989   SMF type 100 and 101 records.  IBM changes appear to be  
               compatible. DB2 2.2 added five QX..... variables for the 
               MIAP (Multiple Index Access Path) and Create/Drop Alias, 
               and 21 QLAC.... variables for DDF (Distributed Data      
               Facility) accounting to DB2ACCT.  DB2STAT0 was also      
               enhanced with 18 QLST.... variables identical to their   
               QLAC.... counterparts for DDF statistics, and new Q3ST   
               and Q9ST DDF counters. DB2STAT1 was enhanced with the    
               same five QX..... variables for MIAP and QTAUCCH. Note   
               that DDF elapsed and CPU times are captured only in the  
               DB2ACCT data set (and not in DB2STAT0).                  
               DB2ACCT variable DB2TCBTM is now calculated only if both 
               QWACBJST and QWACEJST are both non-zero, as IBM now does 
               document that zero value for either field means that no  
               CPU timing was available. An additional IBM note says    
               that QWACEJST is invalid for END OF MEMORY (RINV=24 or   
               28 decimal), QWACBSRB, QWACESRB, and QWACASRB are invalid
               for DB Access Agents, but it is not clear how to identify
               that situation. A final note in the PL/S DSECT says that 
               QWACEJST may be invalid when QWACRINV > 20 while the ASM 
               DSECT says it is invalid for EOM condition. I am still   
               checking with IBM:                                       
               IFCID 0003 (Type 101 SMF, DB2 Accounting record):        
               1. When "may" QWACEJST be invalid when QWACRINV > 20 ?   
               2. Is QWACRINV of 24 or 28 only values for EOM which     
                  cause EJST to be invalid?                             
               3. How does one know this record is for DB Access Agents?
               4. When data is invalid, is it non-zero or zero?         
               5. What are units of QLACCPUL, QLACCPUR, and QLACDBAT?   
Change 07.192  Continued validation of STX found the test in line 017500
VMACSTX        should test for '02'X, '03'X (instead of '02X' and '03')!
Nov 24, 1989   and '12'X and '13'X should have been added, and corrected
               labels for Application connect timestamps, swlu and lu.  
   Thanks to Larry Doub, RJR, USA.                                      
Change 07.191  VM/SP Monitor channels 17-32 were not input due to bad   
VMACVMON       logic. Remove the ELSE in three lines 272000, 272400 and 
Nov 24, 1989   272800.                                                  
   Thanks to Bob Small, Grumman Data Systems, USA.                      
===========Prerelease 7.4 was for special ESP customer support========= 
===========Changes thru Change 7.190 comprised Prerelease 7.3========== 
Change 07.190  The DASDMON interval start date could be the wrong date. 
ANALDMON       The Start date in the record is not the interval start,  
Nov 24, 1989   but rather the date when DASDMON initiated! The program  
               now uses the SMF record Date to correctly calculate the  
               interval start and end dates.                            
   Thanks to Danny High, Blue Cross Blue Shield Texas, USA.             
Change 07.189  The ASUMCICS trend program uses detail transaction data  
ASUMCICS       to create PDB.CICS with response distributions (pct in 2 
ASUMDBDS       sec) for reports and input to TRNDCICS. Now the program  
Nov 24, 1989   will read either data source transparently; you no longer
               have to remove comment blocks to use Landmark data.      
               The new ASUMDBDS program similarly sums the MONIDBDS     
               detail data into PDB.MONIDBD which matches PDB.CICS.     
   Thanks to Chuck Hopf, Hopf Consulting, USA.                          
Change 07.188  New DB2 Reports were added. I/O Reports (PMIOS01-05), the
ANALDB2R       Locking Reports (PMLOK01-03), and Record Trace Reports   
IMACDB2        (PMTRC01-01) are completed. The Correlation Name and     
VMAC102        Correlation Number are decoded differently for IMS, CICS 
NOv 25, 1989   and other by the new _DB2CORR macro defined in IMACDB2.  
               However, detection of IMS, CICS, etc. in IMACDB2 can be  
               based only on job name (unless you can find a better     
               test), and you may need to modify those names if you     
               are concerned with CORRNAME and CORRNUM values. New      
               DATASET and PAGESET selection was added for I/O reports. 
               Preparation of the Record Trace report uncovered several 
               obscure type 102 variables that were spelled wrong or    
               left out of the KEEP= list.                              
               How much storage does MXG need for DB2 data sets?        
               A site with 10000 DB2 plans executed per day will need   
               122 tracks of 3380 DASD for storage of the DB2ACCT data  
               set, and the DB2STAT0/DB2STAT1 data sets will need 8     
               tracks each (at 15 minute intervals), for a total of     
               only 138 tracks (9 cyl, or only 6 megabytes per day!)    
   Thanks to Chuck Hopf, Hopf Consulting, USA.                          
Change 07.187  SAR variable SARSW should be @165 vice @164 and @164 is  
XMACSAR        GCRMODFT $CHAR1.                                         
Nov 24, 1989                                                            
   Thanks to Dee Ramon, Mutual of America, USA.                         
Change 07.186  Reading SMF type 71 records and ROSCOE data directly from
VMAC71         VSAM SMF file needed help. Line 066400 in VMAC71 needed a
VMACROSC       +OFFSMF at the end, and line 114600 in VMACROSC should   
Nov 24, 1989   have tested for LENGTH > 428+OFFSMF  .                   
   Thanks to Susan Marshall, SAS Institute Europe, GERMANY.             
Change 07.185  Contributed report for MVS/XA and MVS/ESA I/O pathing    
ANALPATH       configuration and activity, using TYPE73, TYPE74, TYPE78 
Nov 24, 1989   and TYPE78CF datasets from a PDB. Self-describing.       
   Thanks to Cindy Batson, Hewitt Associates, USA.                      
   Thanks to Dan Kaberon, Hewitt Associates, USA.                       
Change 07.184  Logic expected subtype of zero, but non-zero value was   
VMAC110        not protected. Now it is.                                
Nov 24, 1989                                                            
Change 07.183  SAS 5.18 accepted LENGTH DEFAULT=4 4; syntax, but Version
VMACVMXA       6.06 testing detected the incorrect syntax, which is now 
Nov 21, 1989   corrected in line 456800.                                
   Thanks to Dan Squillace, SAS Institute Cary, USA.                    
Change 07.182  Change 7.151 fixed IMS, but part of the change was not on
TYPEIMS        MXG 7.2. The two PROC SORTs (lines 107610 to 107670) were
Nov 21, 1989   to have been deleted, but were not. NOT SORTED error.    
   Thanks to Lynn Delacourt, Volvo GM Heavy Truck Corporation, USA.     
Change 07.181  Change 7.035 discussed potential problems if you tried to
IMAC30IO       eliminate D3330DRV variable. This change eliminates that 
IMACPDB        variable from the default I/O KEEP= list (in IMAC30IO)   
BUILDPDB       and the MAX/MIN/SUM logic was redesigned (in IMACPDB).   
BUILDPD3       If you have not modified either IMAC30IO or IMACPDB, this
Nov 21, 1989   change is not impacting. HOWEVER, if IMACPDB or IMAC30IO 
               have been changed by your site, YOU MUST retrofit your   
               tailoring, using the new members in this MXG Version.    
               I'm still working on a way to fix this once and for all  
               sites without impact.  An additional change was made in  
               IMACPDB that should not be impacting. The NODUP option   
               is now always used in BUILDPDB, and the _NODUP macro is  
               no longer referenced in BUILDPDB/3. (For compatibility,  
               though, the macro is still defined in IMACPDB).          
   Thanks to Elliot Weitzman, Oryx Energy Company, USA.                 
Change 07.180  RMDS page counts for one class of data was stored as PD4.
TYPERMDS       while all other counts were PIB4.! Change line 035600 to 
Nov 21, 1989   PD4. from PIB4. There is no change in the SMF record for 
               RMDS Release 4.0, so we therefore now support RMDS 4.0!  
               (Documentation for the SMF record is in SC30-3442-1,     
               Installing and Customizing RMDS Release 4).              
   Thanks to Sim Fleisher, Depository Trust, USA.                       
Change 07.179  3390 DASD Devices are supported. EXCP3390 and IOTM3390   
VMACEXC2       variables are created in TYPE30, PDB.STEPS and PDB.JOBS  
VMACUCB        data sets, and variable DEVICE (TYPE1415, TYPE74, etc.)  
Nov 14, 1989   will recognize 3390. This change is in MXG 7.2.          
Change 07.178  CICS UOWTIME is now set missing if there actually is not 
VMAC110        a timestamp in UOWID. This is a further enhancement found
Nov 14, 1989   when verifying Change 7.170.                             
Change 07.177  Additional DB2 reporting has uncovered inconsistence in  
VMAC102        variable names and some re-definitions of the same field 
Nov 14, 1989   as two variables.                                        
             1.QW0021RP $CHAR8. is redefined over QW0021KD thru K2.     
             2.QW0044RP $CHAR8. is redefined over QW0044KD thru K2.     
             3.DBID and OBID variables were inconsistent. Most were     
               $CHAR2. formatted $HEX2. but some were PIB2. numerics.   
               Now all are $CHAR2., formatted $HEX4. and labels are     
               consistent. Note this affects the variables suffixed     
               with DB for DBID, but IBM uses PS and OB for PAGESET and 
               RECORD OBID, and also KP for PAGESET. This inconsistency 
               in different names for the same logical entity will not  
               be corrected in the MXG built T102Snnn datasets, but the 
               MXG MENU macro variable names used in reporting will be  
               DATABASE and PAGESET, no matter which IFCID variable name
               contains the information.                                
   Thanks to Chuck Hopf, Hopf Consulting, USA.                          
Change 07.176  GTF format DB2 Trace Data was still not quite correct,   
VMAC102        even after Change 7.122. The GTF header inserts 12       
Nov 14, 1989   bytes before the triplets but the offsets themselves are 
               relative to byte 1. MXG used OFFSMF=12 (set in _GTF) to  
               flag the difference, but failed to use it properly!      
               The logic at lines 085900 thru 08500 now reads:          
                  IF OFFSMF=12 THEN DO;                                 
                    INPUT @29 SM102SSI $CHAR4. @;                       
                  ELSE OFFPROD=OFFSMF-3+QWT02PSO;                       
                The reset IF OFFSMF=12 THEN OFFSMF=0 after the triplets 
                have been INPUT is still correct.                       
   Thanks to Susan Marshall, SAS Institute Europe, GERMANY.             
Change 07.175  Support for STX Release 1.0+ has been coded and syntax   
EXSTX...       tested (no error first execution with SMF DD DUMMY!) but 
IMACSTX        real data has not been yet processed.                    
VMACSTX        and STXCONOF are created.                                
Nov 11, 1989                                                            
   Thanks to Larry Doub, RJR, USA.                                      
Change 07.174  Support for Release 2.0.0 of TPX has been added to decode
VMACTPX        the new format records as well as the prior releases. The
Nov 11, 1989   2.0.0 record is incompatible with prior TPX records, and 
               does require MXG 7.3. TPX 2.0.0 writes a wrong value for 
               length field MONO5LEN, (it's x28, but there are x30 bytes
               in the segment based on MONO6LEN and MONO6ID) that MXG   
               detects and circumvents. New variables were added to the 
               TPXSTART, TPXAPLOF and TPXTRMOF datasets by TPX 2.0.0.   
   Thanks to ???, Swan Hunter Shipbuilders, ENGLAND.                    
   Thanks to Larry Doub, RJR, USA                                       
     for excellent dumps and documentation.                             
Change 07.173  MXG VTOC processing had further validation:              
VMXGVTOC     a.Change 7.164 was misspelled. The Delete list should have 
Nov  9, 1989   listed datasets EXTENT EXTENTS in place of EXTEND.       
             b.Line 128 example should be NEW=INFO vice NEW=MAP.        
             c.EQ MXTRACK should be EQ MXTRACK-1 in lines 649, 667.     
             d.LAST=MXTRACK should be LAST=MXTRACK-1 lines 652, 670.    
             e.VOLSER should be added to the KEEP= for INFO line 245.   
             f.Labels added for VTOCINFO new variables NTPC, DEVCYL,    
               DEVTRK, TOTRACKS, FCYL, FTRK, LCYL, and LTRK.            
   Thanks to Phil Henninge, Timken Company, USA.                        
Change 07.172  CA/DISPATCH variables are created in TYPE6 dataset by the
VMAC6          enablement of their decoding in MXG member IMACCADI. The 
Nov  9, 1989   variable CADIRCIP was incorrectly spelled as CADIRCVR in 
               the KEEP= list in member VMAC6, causing CADIRCIP to not  
                A note on this MXG technique. SAS does not validate that
                variables in a KEEP= list actually exist. If a variable 
                name appears only in the KEEP= list, that variable will 
                not be created. All of the CADI.... variables are in the
                TYPE6 KEEP= list, but they will not exist in your TYPE6 
                dataset unless you modify IMACCADI, as all of the code  
                that creates the CADI variables (LABEL, FORMAT, INPUT)  
                is inside a comment block in IMACCADI. Removing that    
                comment block is all that is necessary to cause the     
                variables to be created AND kept. This technique works  
                for KEEP= list, but not for the KEEP statement; SAS does
                validate the existence of all variables in KEEP statemen
   Thanks to Carol Arnold, K-Mart Apparel, USA.                         
Change 07.171  CICS UOWTIME changes discussed in 7.170 are all true, but
TYPEMONI       there was one other error (only in MXG's Landmark code)  
Nov  6, 1989   that actually precipitated the discoverys in 7.171.      
               Line 060700 (ENDTIME=DHMS(ENDDATE,0,0,ENDTIME); must be  
               moved to new line 014710 (immediately before the line    
               so that ENDTIME is converted into a datetimestamp first, 
               before it is used in the UOWTIME decode algorithm!       
   Thanks to Terry Baker, Royal Insurance, USA.                         
====FLASH 7.2 (accompanied 7.2 shipment starting in November, 1989)==== 
================printed Changes 7.170 to 7.162========================= 
Change 07.170  CICS UOWTIME can be between 01JAN60 and 22JUL60, or can  
TYPEMONI       have right date and wrong time, or both may be wrong.    
VMAC110        IBM stores times in two different non-unique formats:    
Nov  3, 1989    - a 6-byte STCK value in sixteenths of a microsecond,   
                   which wraps every 204 days and which therefore       
                   requires logic to decide in which 204-day interval   
                   since Jan 1, 1900 this UOWTIME occurred, or          
                - a 6-byte HHMMSS in EBCDIC characters.                 
               Unfortunately, there is no sure way to identify which    
               format was used. HHMMSS only applies to DL/I batch       
               originators, but there is not yet an unambiguous test    
               to identify DL/I session. The 6-byte EBCDIC HHMMSS       
               field can contain hex F0F0F0F0F0F0x thru F2F3F5F9F5F9x,  
               all of which are also valid STCK values (on days 192 to  
               195 on the 204-day clock)!  MXG always preserved the     
               value in UOWTIME, but its datetime value was sometimes   
               quite far off.  Since NETSNAME and UOWTIME are used      
               to match up the TOR, AOR, and FOR transaction record     
               for an MRO event, and MXGs algorithm did support that    
               merge without error.  MXG expected NETSNAME would end    
               with 12 nulls if not from DL/I, but actually NETSNAME    
                can contain            when the originating terminal is 
            netname                     local terminal, from TCT        
            networkid.LUname            VTAM ISC LUTYPE6.2 or IRC link  
            newtorkid.generic_applid    non-VTAM or ISC LUTYPE6.1       
            jobname.stepname.procname   DL/I batch session              
               and non-nulls caused MXG to fail to add BASETIME (real   
               start datetime of the present 204-day interval) to the   
               204-day value in UOWTIME. Then adding UOWTIME to the SAS 
               base date of 01JAN60 created the 1960 datetimes!         
               Further, MXG logic tested for a HHMMSS format first; a   
               real STCK value of 15:15:51 on day 192 of the 204-day    
               clock was changed to 00:00:00 HHMMSS!. Until DL/I can    
               be uniquely identified, MXG now always presumes the more 
               likely STCK format. At a specific site with knowledge of 
               specific newtworkid values in NETSNAME, one should be    
               able to recognize DL/I and convert back to HHMMSS, but   
               a generic solution is not obvious at present. UOWTIMEs   
               value itself may not be very important; as long as it is 
               constant across MRO regions, it serves its purpose.      
               In the interim, a quick circumvention happens to be to   
               change  IF SUBSTR(NETSNAME,9,12)='0000...00'X THEN       
               to      IF     1=1                            THEN       
               to always cause the addition of BASETIME to UOWTIME and  
               to thereby bypass the ELSE DO logic testing for HHMMSS   
               or HH.MM.SS values at present. I hope it does turn out   
               that the actual UOWTIME value is useful enough for this! 
   Thanks to Terry Baker, Royal Insurance, USA.                         
Change 07.169  The length of variable CHARACTS needs to be 8 to keep the
VMACSYNC full  resolution of total bytes sorted (just to make sure      
Nov  2, 1989   comparisons are exact). With length 4, no significant    
               digits were lost, but low order truncation occurred.     
   Thanks to Glen Farmer, Hallmark Cards, USA.                          
Change 07.168  The format name MG080IA. was incorrectly spelled MG080AI.
Nov  2, 1989                                                            
   Thanks to Richard Stevens, US Trust, USA.                            
Change 07.167  This utility which iteratively invokes VMXGVTOC to read  
VMXGVTOR       all online VTOCs used DO variable I in the outer loop but
Nov  2, 1989   changes to VMXGVTOC also used I. While VMXGVTOC was the  
               culprit, changing the "DO I=" in VMXGVTOR to "DO IVOR="  
               was simpler and safer.                                   
   Thanks to Don Wensel, Philip Morris, USA.                            
Change 07.166  Change 7.098 was correct in its text, but the spelling in
MONTHBLD       the member should be DDNAME= instead of LIBNAME= in both 
Nov  2, 1989   PROC DATASETS.                                           
-----Changes thru Change 7.165 were published in NEWSLETTER FIFTEEN-----
Change 07.165  A comma was lost when re-writing comments in this example
EXITMONI       JCL to create the TMON infile exit. Line 048500 needed a 
Oct 30, 1989   comma at its end.                                        
Change 07.164  MXG DASD VTOC processing did not clean up the WORK file  
VMXGVTOC       if multiple DASD Volumes are processed. After line 068200
Oct 30, 1989   insert:                                                  
                    PROC DATASETS DDNAME=WORK MT=DATA NOLIST;           
               MXG's 3090-200 CPU time to read 206 triple density 3380  
               DASD volumes is about 20 minutes per day.                
   Thanks to Phil Henninge, Timken Company, USA.                        
Change 07.163  TYPE71 variable EXTREADS (Pages Read from ESTORE) is only
VMAC71         valid if you have MVS/ESA (RMF 4.1+), but MXG created a  
Oct 30, 1989   value even with RMF 3.5. Now it will be missing if you   
               are not yet on RMF 4.1+.                                 
   Thanks to George Scott, Rockwell International Corporation, USA.     
Change 07.162  Format libraries in SAS Version 6.06 will be in a SAS    
FORMATS        data library, and must be created/referenced with the    
Oct 21, 1989   DDNAME of LIBRARY, while SASLIB can still be used for    
               SAS Version 5.18 Format libraries (i.e., MXG.SASLIB).    
               This incompatibliity between SAS Version 5.18 and 6.06   
               will be disussed in Newsletter SIXTEEN. This change uses 
               the SAS Version under which MXG is executing to decide   
               if MXG Formats are to be created in the LIBRARY (6.06+)  
               or the SASLIB (5.18-) DDNAMES.                           
========Changes thru 7.161 comprised the pre=release of MXG 7.2=========
========Changes thru 7.161 comprised the pre=release of MXG 7.2=========
Change 07.161  This change is documentation of the procedures used in   
Oct 19, 1989   the final testing of this prerelease of MXG 7.2.         
               It may help you in structuring validation of your own SAS
               based systems, and will let you see MXG's test plan.     
               This process accomplishes these goals:                   
                A. Syntax check and execution (no data actually read) of
                   all MXG code to build all possible MXG datasets.     
                B. Detection of conflicting definitions of same variable
                   in different MXG datasets (CHAR/NUM type, length and 
                C. Detection of known coding errors, such as variables  
                   without labels, DATETIME formatted variables with a  
                   length other than 8, etc.                            
                D. Automatic generation of DOCVER documentation of the  
                   contents of all variables in all MXG 7.2 datasets.   
                E. Automatic generation of DOCVER07 delta-documentation 
                   of all changes in contents between MXG Verion 6.6 and
                   this prerelease.                                     
             1.UTILXREF creates all possible MXG datasets and uses PROC 
               CONTENTS to create a SAS dataset of all variables in MXG 
               which is then analyzed for these known conditions:       
               -type conflicts (char and num in different datasets),    
               -missing label for variables,                            
               -DATETIME formatted variable not length=8.               
               The SYSOUT is also examined for SAS ERROR: messages and  
                for UNINITIALIZED variable messages and any NOT CATLGD  
                JCL messages are located.                               
Change 07.160  Support for the ACF2 ARE data was added to the ACF2JR    
VMACACF2       dataset created from the ACSMFREC='L' ACF2 SMF record.   
Oct 19, 1989                                                            
   Thanks to Raymond Wallace, NRMA, Sydney, AUSTRALIA.                  
Change 07.159  DB2 Trace dataset T102S063 contained only the first 200  
IMAC102        bytes of the SQL text for each BIND, but the actual size 
IMAC102A       of the SQL text can be more than 200 characters. The SQL 
IMAC102B       text can be useful in understanding why a particular DB2 
VMAC102        inquiry consumes large resources (DB2ACCT is used to find
Oct 19, 1989   the expensive executions, and their SQL inquiry text in  
               T102S063 is then examined to see why). Now, MXG will     
               create multiple observations in T102S063 for each 200    
               bytes of SQL text (new variable SEG10263 counts 200-byte 
               segment number).                                         
   Thanks to Bob Olah, Dun and Bradstreet, USA.                         
Change 07.158  This is not a change, but rather an observation that the 
TYPEMONI       byte-count on Landmark's own reports defaults to average 
Oct 18, 1989   number of bytes per screen (PRIOUCHR/TCOUPRCN) but MXG   
               PRIOUCHR variable is total bytes for the transaction and 
               TCOUPRCN is the total number of screen. Landmark reports 
               will match MXG totals if "T" is added after the Landmark 
               field number on their report control statements.         
   Thanks to Tim Follen, Blue Cross of Ohio, USA.                       
Change 07.157  Preliminary support for Sterling Software's DMS/OS DASD  
TYPEDMS        management product's VTOC reading utility. Their utility 
Oct 17, 1989   will read all VTOCs somewhat faster than MXG's VMXGVTOC  
               utility, and their utility's output is then used by this 
               member to create the DMSLIST dataset, similar to the     
               VTOCLIST dataset creatable by VMXGVTOC. However this     
               member does not create the VTOCMAP nor VTOCINFO datasets 
               created when MXG actually reads VTOCs with VMXGVTOC.     
   Thanks to Chuck Hopf, Hopf Consulting, USA.                          
Change 07.156  Trend Data Base implementation of MXG Tape Mount Monitor 
ASUMTMNT       datasets includes a daily TAPEMNTS dataset and also a    
TRNDTMNT       from data either in PDB or TREND database.               
Oct 17, 1989                                                            
   Thanks to Chuck Hopf, Hopf Consulting, USA.                          
Change 07.155  Variable TMNTMTPY in line 004900 should have been spelled
VMACTMNT       TMNTMTYP. In MXG 7.1 Beta only.                          
Oct 17, 1989                                                            
Change 07.154  This change eliminates a compatibility exposure between  
BUILDPDB       MXG 6.6 and 7. The SPIN6 dataset built by MXG 6.6 may not
BUILDPD3       be in order expected by MXG 7 (it depends on whether the 
Oct 17, 1989   site added PRENTIME to the BY list in BUILDPDB/3 in its  
               implementation of MXG 6.6). This change inserts a PROC   
               SORT of the SPIN6 dataset before combining it with  the  
               new TYPE6 dataset to avoid the possibility of the "out   
               of sort order" condition.                                
Change 07.153  In what is believed to be the final revision for VTOC    
VMXGVTOC       measurement, VMXGVTOC was again INCOMPATIBLY changed.    
Oct 16, 1989   Previous users will need to change their reporting.      
               The MXG VTOC-reading facility now creates three datasets:
                VTOCLIST - one obs per dataset, tracks allocated, tracks
                           used, creation, expiration dates, etc. This  
                           was previously named VMXGVTOC.               
                VTOCMAP  - one obs per extent/free space. A map of the  
                           DASD volume. Previously named VMXGFREE.      
                VTOCINFO - one obs per volume, from the DSCB4. Size of  
                           the volume, and VTOC flags such as Indexed   
                           VTOC, Available DSCB0s, Available tracks,    
                           System Managed Storage status, etc. New.     
               The description of this VTOC facility for DASD space     
               management and accounting is contained in extensive      
               comments at the beginning of the member itself.          
   Thanks to Don Wensel, Philip Morris, USA.                            
Change 07.152  IMS log processing variable MSGLEN (message length) may  
VMACIMS        be wrong. The LOC=MSGPRFLL in MXG 6.6 was changed in     
Oct 16, 1989   MXG 7.0 to LOC=MSGPRFLL+1 to locate where MSGLEN is to   
               be INPUTed. It appears this change in 7.0 was wrong and  
               the MXG 6.6 logic is restored. Please look at the value  
               of variable MSGLEN for message size of a known IMS tran  
               and confirm if this LOC= logic is correct for your site. 
   Thanks to Pete Shepard, Ashland Oil, USA.                            
Change 07.151  IMS log processing logic which merges datasets PRG and   
TYPEIMS        INOUT was incorrectly changed in MXG 7.0. The PROC SORTs 
Oct 16, 1989   of PRG and INOUT just before the MERGE (lines 107610 to  
               107670) were deleted, and the BY variable of TRANSACT    
               for the merge was changed to the original DTOKEN. This   
               merge was more robust than the initial 7.0 change. All   
               other logic changes in 7.0 appear to be correct. A nit   
               was also noted: the format for ARRVTIME should be 19.2   
               for consistency with other DATETIME formats.             
   Thanks to Pete Shepard, Ashland Oil, USA.                            
Change 07.150  -EXPLORE/VM variable SERIAL should be input as $CHAR4.   
TYPEVMXP        and formatted as $HEX8. in member VMACVMXP.             
Oct 16, 1989    was moved to member TYPEVMXP.                           
   Thanks to Pete Shepard, Ashland Oil, USA.                            
Change 07.149  Variable OTH0CPU was not in the KEEP= list for dataset   
GRAFTRND       ALLCPU.                                                  
Oct 16, 1989                                                            
   Thanks to Pete Shepard, Ashland Oil, USA.                            
Change 07.148  VM/XA Monitor dataset VXIODDEV variables AVGCONMS,       
VMACVMXA       AVGDISMS and AVGPNDMS are 1000 times to large. The 1000* 
Oct 12, 1989   in lines 686900-687100 was removed. This dataset is not  
               typically kept, and all three values are correct in the  
               VXDEVDET, VXDEVTOT, VXSUMIOD datasets that are used in   
               MXG VM/XA report examples (because these averages were   
               recalculated correctly in building those datasets).      
   Thanks to Jeff Goodfellow, GTE Services, USA.                        
Change 07.147  Numerous discoveries during testing 7.1 Beta DB2 reports.
ANALDB2R       All but subpart 4 apply only to ANALDB2R reporting and   
VMACDB2        only to the STATISTICS reports.                          
Oct 12, 1989                                                            
              -All QSDCKPT changed to QWSDCKPT.                         
              -Second WRITE OUTPUT LOG BUFFERS lines 945200-945300 are  
               replaced by semicolon and line 944600 should be QJSTBFWR.
              -After DB2 COMMANDS, lines containing @ 85 PUOR 'N/A'     
               should contain only @85 'N/A'.                           
              -The Buffer Pool variables DB2ACCT QBnC... and DB2STAT1   
               QBnT... (where n is 1, 2, 3, 4) now correctly contain the
               data corresponding with buffer pool id values 0, 1, 2, 80
               for BP0, BP1, BP2, and BP32. Previously, n=1 variables   
               contained whatever BP was in the first segment. No data  
               was lost, but now the variable name n=1 to 4 does match  
               the contents correctly. (This was the VMACDB2 part).     
               The Buffer Pool reporting now uses a DO loop instead of  
               repetitive code, and only prints reports for pools with  
               activity. (This was the ANALDB2R part).                  
              -QWHSSTCK (time stamp) in the DB2STAT1 dataset might not  
               be exactly the same ast QWHSSTCK in the DB2STAT0 dataset,
               but DB2 reporting requires MERGE of those separate data. 
               Now, QWHSSTCK will be retained from subtype 0 to subtype 
               1 of the DB2 Type 100 SMF record so that the MERGE will  
               not fail. This change also compares the STCK value in a  
               subtype 1 with the previously retained STCK from the 0,  
               and PUTs error if out of sequence data is encountered.   
               QISEDBD, QB1TCBA, QB2TCBA, QB3TCBA and QB4TCBA values are
               end-of-interval values, but MXG summed their values. Now,
               the MXG summarization calculates the average value of the
               end-of interval data values for the interval.            
              -CORRNMBR and CORRNUM were redundantly named, and were not
               parsed correctly for IMS connections. Now, CORRNUM is the
               only variable used in ANALDB2R, and the values of the    
               QWHCCN (=:IMS,=:CICS, all else) is used to decide how to 
               parse CORRNAME and CORRNUM from QWHCCV.                  
              -Second occurrence of DATABASE SERVICES in summary CPU    
               report (QJS3 variables) are actually for the IRLM, and   
               now the heading is correct.                              
              -Macro variables were defined both in the ANALDB2R macro  
               definition, and in the macros called by ANALDB2R. This   
               redundant code added unnecessary lines and required care 
               in making redundant changes. Now, all macro variables are
               defined only in the ANALDB2R definition and are no longer
               explicitly defined in the actual report macro.           
              -QJST.... variables IDEN,CTHD,SIGN,TERM,ABRT,PREP,COMM,   
               INDT,RIUR,SYNC,CTHW should have been Q3ST in ANALDB2R.   
   Thanks to Jan van Lent, Fokker, NETHERLANDS.                         
Change 07.146  Variables QBnTPFDC, QBnTWKPD, QBnTWMAX, added by Change  
DIFFDB2        7.130 to DB2STAT1 dataset were not deaccumulated. Now the
Oct 12, 1989   dozen variables are DIF()'d. Only MXG 7.1 Beta.          
   Thanks to Bob Olah, Dun and Bradstreet, USA.                         
Change 07.145  Line 942200 should be ARCHIVE LOG instead of ACTIVE LOG, 
ANALDB2R       Line 459300 NODUPKEY (PC syntax) should be NODUP for the 
Oct 12, 1989   mainframe syntax. Only MXG 7.1 Beta.                     
   Thanks to Pete Galaveri, Readers Digest, USA.                        
Change 07.144  Change 7.137 new line 012301 mistyped SMF6LN1 as SMFLN1, 
VMAC6          causing "UNINITIALIZED" message and missing values. This 
Oct 12, 1989   only affected the 7.1 Beta code.                         
   Thanks to Chuck Hopf, Hopf Consulting, USA.                          
Change 07.143  Line inserted by Change 7.008 after line 23610 did not   
BUILDPDB       agree with Change. Line 023610 should be IF LAST.JESNR as
Oct 12, 1989   stated in the Change, replacing FIRST.JPURTIME in code.  
   Thanks to Debby Blackey, Marshalls, USA.                             
Change 07.142  PR/SM environment TYPE70 CPUWAITM and PCTCPUBY were wrong
VMAC7072       if the number of logical processors was greater than the 
Oct 11, 1989   number of real processors. An MVS 3090-400 was given six 
               logical processors by PR/SM. The type 70 record shows MVS
               NRCPUS is four, shows CPUs1-4 are online (CAI1-CAI4 are  
               '01'B, online-for-entire-interval), shows CPUSER1-CPUSER4
               with the real serial numbers, and shows other CAIn and   
               CPUSERn values are blank. For the PARTISHN in which this 
               MXG is executing, there are six Logical Processor Data   
               Sections, creating six TYPE70PR observations, but the    
               only four that have non-zero LCPUPDTM PR/SM Dispatch also
               have LCPUADDR values 1-4 matching the online CAIn values!
               MXG correctly calculated individual CPU percent busy and 
               CPU wait in PCTCPBY0-8 and CPUWAIT0-8 variables using the
               duration minus dispatch DURATM-LCPUPDTM, but MXG did not 
               correctly calculate CPUWAITM and PCTCPUBY in TYPE70 when 
               6 PR/SM Logical Processors are assigned to a 4-CPU MVS!  
               MXG summed wait time for all 6 LPARS, causing actual CPU 
               busy to be much lower than accurate. This change precedes
               each of the nine CPUWAIT=CPUWAIT+CPUWAITM; statements in 
               lines 141300 to 146800 (logic for SHARED, WAIT=NO) with  
                IF CAIn EQ '......01'B THEN CPUWAIT=CPUWAIT+CPUWAITM;   
               and then changed n in CAIn to 0 thru 8 respectively.     
               IBM RMF reporting was also wrong with this data. Their   
               RMF Summary Report CPU BUSY reported an average 54% busy 
               (they used CPU0-3) instead of the true 65% busy from CPU 
               1-4 values.  The CPU ACTIVITY report was also wrong with 
               CPU1s printed value taken from CPU0 (of 0%) and with the 
               2-4 CPU values taken incorrectly from CPU1-3 fields to   
               incorrectly report 61.4% busy when 78.5% was correct.    
   Thanks to O. V. Hanger, A. C. Nielsen Co., USA.                      
   Thanks to Tim Klevar, General Electric Plastics, USA.                
Change 07.141  Change 7.070 (only in MXG 7.0 BETA) was incorrect. The   
ANALDSET       lines of code after DATA DSETOPEN.DSETOPEN; from "IF" to 
Oct 11, 1989   "DROP" must be moved to after TYPETASK=TYPETASZ;         
   Thanks to Debby Blackey, Marshalls, USA.                             
========Changes thru 7.140 were on the 7.1 Beta Tape=================== 
Change 07.140  IBM's Cache DASD RMF Reporter created SMF records do not 
VMACACHE       agree with documentation. GSLEN is 40, but the SD1IDCU is
Sep 14, 1989   in SD2ID instead of SD1ID. I am still researching when   
               this change occurred (this user is at CRR 1.3). The fix  
               is at line 028200-28300: change SD1ID=SD1IDCU to         
                  (SD1ID=SD1IDCU OR SD2ID=SD1IDCU)                      
   Thanks to Tom Healy, Chemnet, USA.                                   
Change 07.139  SYNCSORT SMF record SIRECFM/SORECFM were decoded wrong,  
VMACSYNC       because SIRFM and SORFM were input as PIB1. but they are 
Sep 14, 1989   actually EBCDIC numerics and should have been inputted   
               as 1. instead of PIB1.  The CPUTCBTM in the SYNCSORT     
               record is sometimes wrong; values of 15 hrs 32 minutes   
               have been found by two different sites on SYNCSORT 3.2   
               and 3.3 (one site found one record per day, the second   
               found 50 such records in a month's SMF data). SYNCSORT   
               says this can happen if a SORT EXIT routine issues the   
               STIMER macro, but one site thinks the problem still      
               exists even when exits were not used. Still open.        
   Thanks to Sam Sheinfeld, Kraft General Foods, USA.                   
   Thanks to Russ Berlin, Time-Life, USA.                               
   Thanks to Sal Fazzino, General Electric Capital, USA.                
    who reported this first, but who was not listed in Newsletter 15!   
Change 07.138  This user contribution creates a SAS Function, FMXGSID,  
FMXGSID        which can be invoked from a SAS program and returns the  
Sep 13, 1989   character variable of the SMF System Id (SMCASID, MXG's  
               variable SYSTEM) on which the job executed. This was     
               used to add SYSTEM to MXG VTOC datasets.                 
   Thanks to Gerald Baxter, British Telecom (Red Lion Square), ENGLAND. 
Change 07.137  This two-line JES2 system modification stores in a batch 
ASMsysmod      job's SMF type 6 record the time that that print file was
VMAC6          released to print. This permits direct measurement of the
Sep 18, 1989   printer queue duration for help print jobs. The mod was  
               originally coded by Carol Toll, Sun Company, and then it 
               was re-designed by Dean Tesar of Hewitt, who reduced it  
               to the following system modification:                    
               In macro IFASMFR                                         
                          after field SMF6RET                           
                          and before field SMF6END2.                    
                          add new line:                                 
                                    SMF6JTME DS BL4  JOE CREATE TIME    
               In source HASPPRPU (near label PPSMFBLD)                 
                          after MVC SMF6OWC,JOECURCL-JOE(R2)            
                          and just before     USING DCT,R2              
                          add new line:                                 
                                    MVC SMF6JTME,JOECRTME-JOE(R2)       
               As with all system modifications, you accept liability   
               for all testing and validation of this enhancement to    
               your SMF data records. VMAC6 was modified to use the     
               type 6 length fields and will create RLSETIME if it      
               exists in your type 6 record.                            
   Thanks to Dan Kaberon, Hewitt Associates, USA.                       
Change 07.136  Variables CPUSER0-CPUSER9, CPU Serial Number from TYPE70,
RMFINTRV       have been added to RMFINTRV, as they may be useful to    
Sep 13, 1989   know which operating system was on which hardware when.  
   Thanks to Dave Clarke, British Airways, ENGLAND.                     
Change 07.135  NETSPY Versions earlier than 3.1 miscounted transactions 
VMACNSPY       because missing value of character variable (hex 40) just
Sep 13, 1989   happened to be the bit that 3.1 started using. Insert a  
               new line 038010    ELSE X2='00'X;                        
               in case your NETSPY is an old version.                   
   Thanks to Maria Clarke, Telecom Australia, AUSTRALIA.                
Change 07.134  NETVIEW NPM Type 28 record subtype 41x (DRN Command, in  
VMAC28         MXG dataset NPMCMDNC) are not structured as documented by
Sep 13, 1989   IBM. There is no TOF segment, and the AOF pointers point 
               to a PMC segment! This required relocation of the tests  
               for NPMSUBTY EQ 41X, and copying the present PMC handler 
               to before AOFTYPE='SAA' processing, and changing TOF to  
               AOF in that new PMC handler.                             
   Thanks to Anthony P. Lobley, EDS, ENGLAND.                           
Change 07.133  IDMS 10.2 Monitor dataset IDMSTAS variables TASBFLD1-3   
VMACIDMS       should have been TASUFLD. The Batch Account Codes will be
Sep 13, 1989   decoded in the next MXG. See unfinished changes, above.  
   Thanks to Dick Whiting, Precision Castparts, USA.                    
Change 07.132  The new 3480-IDRC "Improved Data Recording Capability"   
VMAC1415       mode should be decodable from TYPE1415 variable TRTCH.   
Sep 13, 1989   This change creates a new variable IDRC='Y' or 'N' for   
               tape data sets to indicate if IDRC was in effect. This   
               has not been verified. The new logic is:                 
                   IF      TRTCH=08X THEN IDRC='Y';                     
                   ELSE IF TRTCH=04X THEN IDRC='N';                     
   Thanks to Gene Tolini, IBM Vendor Support, USA.                      
Change 07.131  NETVIEW "Pseudo-SMF" records can be written to a journal 
TYPE39J        log file instead of SMF. These pseudo-SMF records do not 
VMACSMF        have legitimate VBS architecture, and do not have the    
Sep 13, 1989   data in the standard SMF header (MVSXA, SMFTIME, SYSTEM).
               This change adds a new macro named _NETVLOG which is used
               in TYPE39J (J for Journal Log) in place of the _SMF macro
               normally used. For a quick fix, make a copy of _SMF macro
               and name it _NETVLOG. Therein, 1) Change RECFM on the    
               INFILE statement from VBS to U, and add BLKSIZE=32760.   
               2) Insert just before the INPUT statement a new line:    
               to align the rest of the record with normal SMF format.  
               3) Create TYPE39J from TYPE39, but replace _SMF with     
               The actual fix is more extensive, as unnecessary code in 
               SMF was removed. Better still, put NETVIEW data in SMF!  
   Thanks to Gary Korkowski, The St. Paul Companies, USA.               
Change 07.130  The DB2 DSECTS for DB2 Dated 11/17/88, which were used to
VMACDB2        add support for DB2 Version 2.1 (and which were supplied 
Sep 13, 1989   by IBM) have been changed! There were three additional   
               fields in the buffer manager statistics (DB2STAT1) which 
               MXG did not know about, and which caused subsequent data 
               about buffers to be wrong. MXG added three new variables 
               QBnTPFDC, QBnTWKPD, and QBnTWMAX (where "n" is 1 thru 4, 
               for each of the four buffer pools), by adding logic for  
               LENBUFM GE 116, just like the LENBUFM GE 104 logic took  
               care of the last IBM change. The support for DB2 2.2     
               will add protection (with +SKIP logic) to eliminate this 
               exposure in the future.                                  
   Thanks to Bob Olah, Dun and Bradstreet, USA.                         
Change 07.129  Additional summarization routines for the DOS/VSE POWER  
ASUMDOS        and VM/370 Monitor data, a daily sample job for DOS/VSE  
ASUMVDEV       CICS journal and VM/Monitor processing, upgrading of the 
ASUMVMON       GRAF.... members to use PROC PLOT instead of PROC GPLOT  
ASUMVMON       if you do not have SAS/GRAF, additonal REXX examples for 
DALY110J       MXG under CMS version of SAS, Trending for DOS POWER, VM 
DALYVMON       Device data and VM/370 Monitor. These are preliminary    
GRAFREGR       examples and are subject to change.                      
Sep 12, 1989                                                            
   Thanks to Chuck Hopf, Hopf Consulting, USA.                          
Change 07.128  The validation of 7.0 Beta uncovered many opportunities: 
FORMATS      1.VMACVMON, line 256000 set LENDV2=2 for RELEASVM EQ '05'. 
VMACIDMS     2.TYPERTEJ, added MISSOVER on INFILE statement because IDMS
VMACRTE        10.1 writes short records.                               
VMACVMON     3.VMACRTE (IDMS 10.1 only) line 1301 added colon to now    
TYPERTEJ       read  DBKFILE : $CHAR16.  to protect for occasional short
Sep 12, 1989   IDMS record.                                             
             4.VMACIDMS: all PIB4.4 inputted variables are now formatted
               TIME14.4 (180+ variables!). Variable SMFHDCVN was labeled
               'DC SYSTEM*VERSION*NUMBER' and added to all KEEP= lists. 
               INSTIMSY and INSTIMUS changed from PIB4. to PIB4.4 and   
               added to TIME14.4 format list. DELTATM formatted TIME12.2
               and variables PGMTYPE, TASPTYPE, TASTTYPE are now format 
               $MGIDMPP., $MGRTEPT., and $MGIDMTT. respectively.        
             5.FORMATS: values 6420 and 0A420 added to $MGVM6TY with    
               formatted value of 3380. (Appeared in VM HPO 5.0). New   
               formats $MGIDMPP and $MGIDMTT added.                     
   Thanks to Dick Whiting, Precision Castparts, USA.                    
Change 07.127  The validation of 7.0 Beta DB2 processing uncovered more 
VMACDB2        cleanup. Labels for QWHCOPID and QXSETSQL were corrected,
Sep 11, 1989   the order in which QWHCOPID and QWHCPREV are INPUT was   
               reversed, DB2ACCT CPU times are now validated and set to 
               missing if Begin is greater than End, or if the End time 
               is missing (see INFO/MVS E321145), and the second INPUT  
               of QTXANPL was deleted, correcting subsequent QTXA....   
   Thanks to Stan Majka, Virginia Power, USA.                           
Change 07.126  The 7.0 Beta changes to the Audit report from RACF TYPE80
ANALAUDT       had minor glitches. Line 168 should be OUTPUT SUF and not
Sep 11, 1989   INSUF, and lines 77-79 were replicated and INSUF changed 
               to SUF (to create SUF with same variables as INSUF).     
   Thanks to Raymond Zieverink, Belk Stores Services, USA.              
Change 07.125  This major contribution supports the ARBITER product from
ANALARB        Tangram Systems which creates eleven different SMF record
EXARB...       types with a total of thirty datasets created from the   
IMACARB        many subtypes.                                           
Sep 10, 1989                                                            
   Thanks to J-P Tonnieau, GMF System Team SARAN, FRANCE.               
Change 07.124  MVS/370 CACHE DASD analysis report was updated for XA &  
ANALCACH       MVS/ESA. (MVS/370 TYPE74 variables LCHAN and DEVBUSY are 
Sep 10, 1989   logically LCU and PCTDVUSE in MVS/XA and MVS/ESA). You   
               you still have to tailor this report as described in the 
               comments therein. The report combines RMF TYPE74 device  
               statistics with RMF Cache DASD Reporter TYPECACH data.   
   Thanks to Bruce L. Green, Medical Information Bureau, USA.           
Change 07.123  DB2 APAR PL29461 PTF UL34399 added new data to a segment 
FORMATS        of the IFCID 0001 (Subtype 0, Type 100 SMF record) which 
VMACDB2        MXG did not compatibly handle ("+SKIP" logic was missing 
VMAC102        for this particular data segment in MXG code). This made 
Sep  8, 1989   CPU variables for the 2nd and 3rd Address Space to be    
               wrong: QWS2PROC,EJST,SRBT and QWS3PROC,EJST,SRBT, and the
               sum of all 3 address spaces cpu, CPUTM, when the above   
               PTF is installed on your DB2 Version 2.1 Systems. The PTF
               new variables QWSnASID and QWSnASCB, the ASID and ASCB   
               respectively, are now added to the DB2STAT0 dataset, new 
               values for format MGD140P in member FORMATS were added,  
               and labels for trace variables QW0083QD,QW0087QD,QW0140SC
               and QW140TC were changed based on IBM comment changes.   
               Only the change to member VMACDB2 is critical: You must  
               make the following change in member VMACDB2 if you have  
               the above PTF installed on any of your DB2 systems:      
               Find the line:                                           
                 IF 0 LT OFFASID LT LENGTH AND NRASID GT 0 THEN DO;     
               Insert a new line following that line, containing:       
               Find the next three occurrences of a line containing only
               "@;". Insert the following new line after each of these  
               "trailing at-signs" (only three times, not four):        
                 IF SKIP GT 0 THEN INPUT +SKIP @;                       
   Thanks to Chun-Heng Liu, Brooklyn Union Gas, USA.                    
Change 07.122  DB2 trace records read from GTF (instead of SMF) do not  
VMAC102        create observations because the reset was mislocated; in 
Sep  8, 1989   addition, SMF102SSI was incorrect.                       
               Find the present line:                                   
                  IF OFFSMF=12 THEN OFFSMF=0;                           
               Change that line so that it reads:                       
                  IF OFFSMF=12 THEN INPUT @29 SM102SSI $CHAR4. @;       
               Immediately before the present line containing:          
                  OUTPUT SUBTYPES;                                      
               Insert this new line:                                    
                  IF OFFSMF=12 THEN OFFSMF=0;                           
   Thanks to Susan Marshall, SAS Institute Europe, GERMANY.             
Change 07.121  GRAFRMFI-produced graphs of RMF data gave funny-looking  
GRAFRMFI       graphs if your RMFINTRV dataset INTERVAL was less than   
Sep  7, 1989   one hour. This change still produces plots versus hour,  
               but uses fractional values to plot between hours if      
               necessary. New line 009310 inserted                      
               and change *HOUR= to *HOURPART in all occurrences.       
   Thanks to Joseph Ng Khek Uak, Port of Singapore Authority, SINGAPORE.
Change 07.120  Was accidentally skipped, and was never used.            
Change 07.119  Boole & Babbage RMF replacement CMF product's SMF records
VMAC7072       can be created simultaneously with RMF records. This will
VMAC71         cause MXG datasets to contain essentially duplicate data 
VMAC73         for the intervals when both monitors were running. This  
VMAC74         change decodes the IBM reserved field at OFFRMFP+28 and  
VMAC75         sets variable PRODUCT's value (normally "RMF") to either 
VMAC76         "CMF-CPM" or "CMF-IPM", depending on the CMF mode that   
VMAC77         created the record. This allows CMF and RMF records to   
VMAC78         be separated, if both should exist. Since the variable   
Sep  7, 1989   PRODUCT exists only in MVS/XA and later, this change does
               not support identification of MVS/370 CMF from RMF data. 
               On the subject of CMF, though not related to this change,
               CMF creates a PR/SM data segment in its type 70 record   
               under either IBM's PR/SM or Amdahl's MDF hardware. MXG   
               creates observations in TYPE70PR from the PR/SM segment. 
               (RMF users must use TYPEMDF, Change 7.087, to decode its 
               separate SMF record from Amdahl's MDFTRACK instead.)     
               Also, note there is no type 79 record created by CMF.    
   Thanks to Richard L. Gimarc, Boole & Babbage, USA.                   
   Thanks to Allan Callahan, SAC Offutt AFB, USA.                       
Change 07.118  MXG DB2PM-like reporting has been further enhanced. All  
ANALDB2R       reports possible have been tested with DB2 Version 2.1   
Sep  6, 1989   data (as well as prior DB2 versions). Additional reports 
               have been added, and all reports planned for MXG Version 
               7 have been named (even though some do not yet exist).   
               See member for revised documentation and details.        
Change 07.117  DB2 Report PMACC01 values on **TOTAL** lines were totals 
ANALDB2R       of averages because wrong denominator was used in three  
Sep  5, 1989   places. Insert three lines to correct:                   
                line 07951000    FREQ=L2FREQ;                           
                line 08411000    FREQ=L1FREQ;                           
                line 08871000    FREQ=GFREQ;                            
   Thanks to Alan W. Maloney, Telenet Communications, USA.              
Change 07.116  A minor omission, &OTHER6 was left out in lines 019300 to
GRAFTRND       019600.  12="&OTHER6" inserted after 11=, and &OTHER7 to 
Sep  5, 1989   &OTHER9 became 12 to 15, deleting the extra &OTHER9.     
   Thanks to Raymond Zieverink, Belk Stores Services, USA.              
Change 07.115  ACF2 data sets ACF2NRA & ACF2NRB contain 0 observations. 
VMACACF2       ACF2 SMF record subtype 'A' has JOB name of hex zero.    
Sep  5, 1989   MXG includes IMACJBCK (an MXG macro which allows for JOB 
               name selection during creation of MXG data sets) BEFORE  
               checking the record subtype, which caused all ACF2 'A'   
               records to be deleted. Line 0345's %INCLUDE was moved to 
               after 0365 and executed within a do group:               
                 IF ACSMFREC NE 'A' THEN DO;                            
                   %%INCLUDE SOURCLIB(IMACJBCK);                        
               Additionally, line 0376 (ACFAPMLN) should be PIB2. vice  
               PIB1., and line 0379 AFCAPARM should be spelled ACFAPARM.
               Finally, ACFACID is formatted as $HEX2. (in line 0328).  
   Thanks to Raymond Wallace, NRMA, AUSTRALIA.                          
   Thanks to Bill Gibson, SAS Institute, AUSTRALIA.                     
Change 07.114  VMAC7072 PR/SM variables were wrong (only) when SMF data 
VMAC7072       was read from the VSAM SMF file. Line 132700 should read:
Sep  5, 1989     LOCPRDS=OFFPRDS+BDNSKIP*LENPRDS-3+OFFSMF;              
               Additionally, SMFTIME was not kept in TYPE72MN, and      
               ZDATE was not kept in TYPE72MN or TYPE70PR datasets.     
   Thanks to Barry Pieper, First Bank System Information Services, USA. 
   Thanks to Siegfried Trantes, Gothaer Versicherungsbank VVAG, GERMANY.
Change 07.113  RMF Monitor III VSAM data set support validation found a 
VMACZRB        few changes. In VMACZRB, field GEISIZ is now spelled as  
ZRBJCL         GEISIZE.  The lengths (see inital comments in VMACZRB) of
Sep  5, 1989   ASISIZE was changed from 84 to 88, and of GEISIZE was    
               changed from 92 to 96 by RMF 3.5. In ZRBJCL, the correct 
               DDNAME is RMFIII vice ZRBIII.  It has been reported that 
               only minor changes (tests LENGTH was tested for explicit 
               value instead of GE, I think) are needed for this code to
               also support RMF 4.0 (MVS/ESA) RMF III, but that has not 
               been identified/tested yet.                              
   Thanks to Neil Ervin, Sara Lee Direct, USA.                          
Change 07.112  Member ANALBNC1, for the analysis of benchmark runs, is  
ANALBNC1       not really complete (in that the benchmark job stream is 
Sep  5, 1989   not yet in existence) but some users have still found the
               member was a good starting point for comparisons of their
               own benchmark stream. This change upgrades the code so   
               that at least it runs without errors due to incomplete   
               comments, misspelled variables, etc.                     
   Thanks to Harry Olschewski, DVG Kiel, GERMANY.                       
Change 07.111  This is a major revision to the MXG VTOC reading utility.
VMXGVTOC       All variables are now labeled, and additional fields in  
Sep  1, 1989   the VTOC (tracks allocated, tracks used, expiration date,
               last use date, etc.) are now decoded in the MXGVTOC data 
               set.  The VTOC itself is now recognized as occupying DASD
               space, and free space after the last dsname on the volser
               is now included in the MXGFREE data set. With this change
               MXG really does capture the VTOC information for capacity
               management of your DASD farm as well as for the billing  
               of DASD usage. The number of tracks on the volume is now 
               contained in the MXGVTOC data set in the DSNAME of the   
               VTOC data set (see comments in member).                  
   Thanks to J. Cary Jones, Philip Morris, USA.                         
   Thanks to Chris Luckman, SAS Institute, ENGLAND.                     
   Thanks to Jugdish Mistry, SAS Institute, SCOTLAND.                   
Change 07.110  In searching for info on 3480-IDRC in INFO/MVS, I found a
VMACEXC2       reference to a new Device Type of x'81' for Device Class 
VMACUCB        of x'80' (Magnetic Tape), decoded as device type 9348. On
Aug 31, 1989   Sep 5, the 9348 (a 1600/6250 reel drive) was announced!  
               In examining UCBTYPE for decoding the 9348, a new Device 
               Class value of x'04' (Character Reader) was noted. Also  
               on Sep 5, IBM announced the 3490 tape cartridge device,  
               (a 3480 with IDRC built-in and a smaller footprint).     
               MXG member VMACUCB creates values of variable DEVICE.    
               MXG member VMACEXC2 accumulates EXCP/IOTM counts into the
               device-specific variables (EXCP3420, EXCP3480, etc.).    
            a. VMACUCB now sets DEVICE variable values of 2400, 3420,   
               3480 or 9348. (Previouly, DEVICE was either 3420 or 3480,
               and 3420 meant "all tapes not-3480").                    
            b. VMACEXC2 IOTM/EXCP summarization for Tape Class continues
               to keep only XXXX3420 and XXXX3480 variables, and 9348   
               counts are included in the XXXX3420 variables. XXXX3420  
               variables still mean "all tapes not 3480".               
            c. VMACUCB also now creates a value of CHARRDR for DEVICE   
               for device class of x'04'. (If you had actually had any  
               x'04' values, MXG would have produced an error message on
               the SAS log, and none have ever been reported!)          
             d.VMACEXC2 counts EXCP/IOTM counts from device class x'04' 
               in the XXXXUREC variables.                               
  Attended SHARE to present paper on the history of SMF Product's 1969  
  release, twenty years ago (and the 20th anniversary of the SHARE CME  
  Project as well).  The paper is published in MXG Newsletter FIFTEEN,  
  in Volume One of the SHARE 73 PROCEEDINGS, and elsewhere as well.     
Change 07.109  Unknown DOS Accounting records caused MXG to STOP reading
TYPEDOS        the DOS file, which was inappropriate. Now, if an unknown
Aug  3, 1989   record id is encountered, a message and a hex dump of the
               first ten occurrences are printed on the SAS log, but the
               MXG program continues to read the rest of the POWER data.
               The unkonwn record encountered was RECID='D', which looks
               like an execute record, but is still under investigation;
               it may be created by a vendor-product.                   
   Thanks to P.J. Penrith, Kleinwort Benson, ENGLAND.                   
Change 07.108  Landmark's Monitor for CICS History Data OVHD Records are
TYPEMONI       incorrect due to an error in Landmark's TMV630 program.  
Aug  1, 1989   The OVHD,History record (not typically used by MXG users)
               is one byte too short, and causes an "INPUT EXCEEDED" SAS
               error message and STOPOVER ABEND. Landmark now has a fix 
               to create valid records, but until you apply their fix,  
               this circumvention will avoid the ABEND:                 
                 Insert after line 040600 (USER       $CHAR8.)  :       
                      @; IF SUBSTR(TRANSACT,1,4) NE 'OVHD' THEN INPUT   
                 Insert after line 040800 (@;)                  :       
                      ELSE INPUT LUNAME $CHAR7. @;                      
               Remember to remove this fix after you get the fix from   
               Landmark installed.                                      
   Thanks to Neil Ervin, Sara Lee Direct, USA.                          
               October 19, 1989 update:                                 
               Another site tried the above circumvention before they   
               got the fix from Landmark, and still abended, because    
               in their case, the record had no FILESEGs, so that the   
               input DO loop is not executed, then the code in line     
               048600 is executed, and the STOPOVER occurs in trying    
               to input UTNUM PIB1.                                     
               Their additional circumvention, then, was                
                 IF SUBSTR(TRANSACT,1,4)='OVHD' THEN UTNUM=0;           
                 ELSE INPUT UTNUM PIB1. @;                              
   Thanks to Anthony Miekle, Composite Buyers, AUSTRALIA.               
Change 07.107  Change 7.060 (7.0 Beta ONLY) added type 37 support for   
VMAC37         NETVIEW 1.2 and NETVIEW 1.3 records. Earlier versions of 
Aug  1, 1989   NETVIEW (1.1) and prior NPDA (V3R2,V3R3) STOPOVERed. The 
               code now supports all of these records, and additionally 
               now decodes the local and remote modem reports into 12   
               new variables each.                                      
   Thanks to Bruce Widlund, Texas Utilities, USA.                       
Change 07.106  IDMS SMF records have been further validated and a few   
VMACIDMS       fields (which had existed in the old RTE records) are now
Aug  1, 1989   added in this minor enhancement.                         
                Add TASMSSEV to keep list in line 013700.               
                Label TASMSSEV='TASK ABEND*SEVERITY*CODE'               
                      PMHTSKID='TASK ID*NUMBER' after 019700.           
                Add TASPRTY to the $HEX2. format list in 072400.        
                Insert after 136100:                                    
   Thanks to Rodney L. Reisch, Wacovia Bank and Trust Company, USA.     
Change 07.105  Type 6 PSF records had variable FORM wrong, because IBM's
VMAC6          8-byte "form" field in the Common Section of the PSF type
Jun 30, 1989   6 record does not contain the form! This fix may change  
Feb  7, 1990   if IBM ever moves an 8-byte form name into the PSF record
               but for now, you must change line 021300-021500 to read: 
      ELSE IF SMF6LN3 GE 14 THEN INPUT +8 @;                            
               Feb 7, 1990 update: SMF6LN3 was printed here in CHANGES  
               as SMFLN3 in error, and corrected today. VMAC6 was okay. 
   Thanks to Agneta Bergsten, SPP, SWEDEN.                              
Change 07.104  Shift calculation changes made in Version 6.6 did not    
IMACSHFT       affect the SHIFT variable, but the value of the DATETIME 
Jun 28, 1989   variable passed back to the caller was not always right. 
               Since the returned value was used only infrequenly and   
               only in trending, this should not really cause a problem:
               Insert new line 005701:                                  
                   ELSE IF WEEKDAY(DATEPART(DATETIME)) EQ 2 THEN        
               Remove ELSE from beginning of line 005800.               
   Thanks to Gary Kallenber, CONTEL, USA.                               
Change 07.103  New style macro %VMXGSUM requires SAS System Option of   
ANALDB2R       MWORK=28K, else an 1453 Invalid Parameter Length error   
Jun 28, 1989   occurs. While MWORK=28K was shown in MXG Trending example
               in 6.6, rewrite of ANALDB2R using the new style macro did
               not remind you to specify MWORK=28K for DB2 reports.     
Change 07.102  MXG Tape Mount Monitor SMF record processing code had two
FORMATS        formats reversed (lines 004900 and 005000) and failed to 
VMACTMNT       decode TMNTMTYP (Type of Mount, 0=Demand, 1=Private, and 
Jun 28, 1989   2=Scratch) correctly. New format MGTMNTM. added to member
               FORMATS. Replace present line  TMNTRTRN PIB4. with two:  
                      TMNTRTRN PIB2.                                    
                      TMNTMTYP PIB2.                                    
   Thanks to Ray Dickensheets, Yellow Freight System, USA.              
Change 07.101  VM/370 Monitor data for USER class did not exactly match 
VMACVMON       VMMAP. MXG did not output the first interval record, and 
Jun 28, 1989   then deleted the second interval user record in the DIF()
               logic. Change line 248700 (precedes EXVMOUSR's include)  
               to read IF INTRVCNT GT 0 THEN DO; instead of GT 1 THEN.  
   Thanks to Rob Owens, SAS Institute Europe, GERMANY.                  
Change 07.100  TMS DSN record caused STOPOVER due to bad logic. Correct 
VMACTMS5       by inserting   IF I=1 THEN   before  INPUT in line 0146. 
Jun 28, 1989   Also, all packed decimal input fields were precedeed with
               ?? (between variable and PDn.) to protect if the field   
               has nulls instead of a valid PD field. The ?? tells SAS  
               to suppress the "invalid PD" message and to suppress the 
               hex dump of a record with invalid PD data!               
   Thanks to Brenda Rabinowitz, Prudential-Bache Securities, USA.       
Change 07.099  Default record ID of 255 in IMACAION caused STOPOVER when
IMACAION       an SMF ID=255 record (from a diferent product) was read. 
Jun 18, 1989   Default should have been 512.                            
   Thanks to Jim Kane, Reader's Digest, USA.                            
========Changes thru 7.098 were on the 7.0 Beta Tape=================== 
Change 07.098  Creation of CICS data sets by BUILDPDB beginning in 6.6  
BUILDPDB       removed the PROTECT=ZZZZZ option from the CICSACCT,      
May 31, 1989   CICSEXCE, and CICSYSTM data sets. This could cause an    
               error when 6.6 attempts to reuse a 5.5 PDB library. (See 
               extensive discussion of PROTECT= in member CHANGE06). To 
               avoid the problem, you can simply scratch and reallocate 
               each PDB library before its re-use. Alternatly, you could
               simply delete the three protected datasets from the PDB  
               library before you run MXG 6.6, by executing:            
                PROC DATASETS NOLIST DDNAME=PDB MT=DATA;                
   Thanks to Greg Bowman, Walmart, USA.                                 
Change 07.097  MXG support for type 79 SMF records is not functional.   
VMAC79         This member needs lots more work before it can even be   
May 31, 1989   tested. Do not try to use or understand it.              
Change 07.096  HSM can create an SMF user record, whose contents is in  
EXHSMDSR       LY35-0080-1 pp180ff as the Daily Statistics Record. The  
EXHSMFUN       MXG support creates two data sets, HSMDSRST (statistics) 
IMACHSM        and HSMDSRFU (for each function) from the DSR record.    
TYPEHSM        There are two other subtypes of the DSR record that are  
VMACHSM        documented (FSR, p191 and VSR, p348s) but are not yet in 
May 31, 1989   this preliminary code. I have only bench tested the code.
               Member VMXGHSM contained the basic code for the DSR data 
               record, and FSR and VSR will be restructures of that code
               as well. All of these segments existed (apparently) in a 
               single SMF record, but there is yet another SMF record   
               that I can not recognize.  This is just a beginning.     
   Thanks to J. D. Hill, CyCare Systems, USA.                           
Change 07.095  The VMSQL... datasets created from VM/ACCOUNT cards will 
TYPEVM         exist only if your VM SQL machine's name (USER) begins   
May 30, 1989   with SQLDBA. If your SQL machine has a different name,   
               see comments in the member. Additionally, data records   
               with apparently invalid values for SQLCPUTM (FFF91A25x)  
               have been reported to IBM, but no response yet. MXG uses 
               PIB4. format, and these values show up as large positive 
               values. Using IB4. instead would create negative values, 
               which might be easier to detect if you are looking for   
               bad values.  But I think PIB4. is still safer, since you 
               can hardly overlook the bad data with large positive data
               values, but with mixed positive and negative numbers, the
               summing could cause the bad data to be overlooked. You   
               should always compare CPU measurement with the elapsed   
               duration of the interval (in this case, how long the VM  
               SQL machine was executing) to detect this type of IBM    
               error (which should eventually be fixed by an IBM PTF).  
               Should I externalize the test for SQL machine name into  
               a new macro name in a new member of MXG?                 
   Thanks to Norbert Korsche, OMV-AG, AUSTRIA.                          
Change 07.094  EPILOG CL1000 Version 440 support was tabled until later.
XMACEPIL       I did not have all of the DSECTs I need when working on  
XXACEPIL       XMACEPIL, and when Candle provided me with their sample  
May 30, 1989   code, it did not agree with the actual records. Member   
               XXACEPIL is partially corrected, decoding at least the   
               header (due to the DSECTS sent for Change 7.090), but    
               development was pended awaiting DSECTS and test data from
   Thanks to David Lloyd, Talbots, USA.                                 
   Thanks to M. Peller, Braun AG, GERMANY.                              
Change 07.093  Type 22 SMF record for 3990-3 Cache DASD controller has  
VMAC22         had its problems. The subtype 10 data was left out of ESA
May 30, 1989   by IBM, and in the fix to that problem, four new bytes   
               have been added to the end of the record. Unfortunately, 
               segment length is not in the data record, and if IBM ever
               writes more than one subtype 10 per section, the TYPE22_A
               data may be incorrect. This is not an important record.  
               The missing segment was reported in MVS/ESA with APARS   
               OY22641/OY11323, and PTFs OY22641/UY90164 add the new    
               fields and for ESA creates the missing subtype.          
Change 07.092  Preliminary support for SMF record created by COMPUWARE  
IMACFILA       product FILEAID.  The access records seem usable, but the
TYPEFILA       Field Update and Comprehensive Update records appear to  
VMACFILA       be of questionable value, especially since pointers do   
May 25, 1989   not appear to exist to connect the record to its dataset!
   Thanks to Mark A. Hawkes, Monarch Systems Group, USA.                
   Thanks to Timothy T. Tadeo, Monarch Systems Group, USA.              
Change 07.091  This contributed report uses the TYPE30_5 record to count
ANALBATQ       how many batch jobs are in the input queue. This report  
May 25, 1989   has not been extensively tested yet, and may change.     
   Thanks to Neil Ervin, Sara Lee Direct, USA.                          
Change 07.090  Support for Candle's Omegamon Audit (hence OMAU) SMF user
EXTYOMAU       record, written for each execution by an operator of an  
IMACOMAU       audited OMEGAMON command. The code is syntax checked and 
TYPEOMAU       visually validated with a hex dump of the data. but  has 
VMACOMAU       not been actually used to read real audit records.       
May 25, 1989                                                            
   Thanks to Jonathan Swann, Belk Stores Services, USA.                 
Change 07.089  Support for AION Development System's SMF record, which  
EXTYAION       creates data set AIONACCT, an accounting record created  
IMACAION       when AION executes under IMS.                            
May 25, 1989                                                            
   Thanks to David Daner, Sun Refining and Marketing, USA.              
Change 07.088  Variable DOWNTIME in TYPE90 is a duration, not a datetime
VMAC90         stamp and should have been FORMATed TIME12.2 instead of  
May 25, 1989   DATETIME21.2. (It really should have been spelled DOWNTM 
               to be consistent, but its too late to change its name.)  
               Move DOWNTIME from line 009100 to 009000.                
   Thanks to Jonathan Swann, Belk Stores Services, USA.                 
Change 07.087  Support for Amdahl's SE Tool MDFTRACK's SMF record. This 
EXTYMDF        record describes activity in other MDF Domains, using the
IMACMDF        MDFWATCH data. Amdahl cautions that this is not really a 
TYPEMDF        supported product but instead it is an SE's tool and is  
VMACMDF        subject to change (and not all fields are documented).   
May 25, 1989    - GBLTOD is GMT while GBLBEGTS/GBLENDTS/SMFTIME local.  
                - GLBENDTS/GBLBEGTS resolve only to seconds.            
                - GLBINTMS is the actual interval duration.             
                - Units of DOMMIN,TGT,MAX,NORM,ATGT and GBLELTM? All    
                  are same (and 879.068 if PIB4.3).                     
                - Units of DOMDUTIL, DOMSUTIL,DOMUTIL.                  
                - Validity of DOMNTSC.                                  
                - Validity of GBLRSERN.                                 
                - Avg Time slice calculation?                           
               By comparing your online screen displays of the numbers  
               with a PROC PRINT of the MXG-built data sets, you should 
               be able to figure out how to replicate the screen report 
               values exactly from the MXG variables. Let me know.      
   Thanks to Dennis Dwyer, Citicorp St. Louis, USA.                     
Change 07.086  FOR VM/XA ONLY: Remove both occurrences of STOPOVER in   
VMACVMXA       the two INFILE statements for VM/XA Monitor processing!  
May 24, 1989   I never thought I'd recommend not using STOPOVER, but it 
               looks like that's the best way to deal with the newest   
               idiosyncracy of VM/XA.  MONWRITE creates logical records 
               that span physical blocks! The only case in which this   
               spanning has occurred so far is the MTRDDR (1.14) record,
               written only at VM/XA Monitor Start-Up. A large number of
               devices + userids created a 1980 byte record which began 
               at byte 3021 of one 4096 byte block (1076 bytes in the   
               first block, 904 in the second). If this had been real   
               IBM VBS Record Format, SAS could handle spanned records, 
               but the VM/XA data is a series of blocks of 4096 byte    
               pages written in blocks of from 4096 to 7*4096=28672     
               bytes, containing two different sets of control records  
               interleaved between sequences of blocks of data records. 
               This non-standard record structure would permit the DCSS 
               to be re-created in an analysis program. The IBM manual  
               suggested algorithm required keeping track of page within
               block and byte within page and databytes within control  
               interval; that's a lot of unnecessary CPU processing if  
               it's really "data processing" (i.e., reading lots of     
               monitor data) you want.  Besides, maybe someday we'll    
               get MONWRITE re-written to create real, valid, VB data   
               record format to really minimize the I/O overhead.       
               The MXG Algorithms treat the VM/XA Monitor data as an    
               imperfect VB architecture, building heuristics to skip   
               over defects, such as the End of Frame record, a valid   
               self-describing 20 byte record followed by an undescribed
               number of hex zeros - if the Record Length included the  
               zeros following the header, the MONWRITE data records    
               would at least be valid Variable-Blocked data between the
               control records! But spanned logical records were not in 
               IBM documentation, nor seen until now.                   
               The STOPOVER option has been discussed in the book, and  
               in previous CHANGExx/NEWSLTRS entries.  It is very useful
               to protect me and you from coding and data errors. It    
               makes SAS stop reading input records when the MXG program
               tries to read beyond the end of the current logical (to  
               SAS) record.  HOWEVER, the simplest fix to the VM/XA     
               Monitor's "spanning" of data is to remove STOPOVER from  
               the INFILE statements. SAS will continue on to the next  
               block with no other change to the MXG algorithm! You will
               receive a "SAS READ BEYOND THE END OF A LOGICAL RECORD"  
               note (which does not set any error condition) on the log.
               Martyn Stevens has coded a circumvention which works at  
               his site, but which works only if the end of each 1.14   
               record occurs exactly at the end of a page. The removal  
               of STOPOVER is thought to be a more robust solution, and 
               it demonstrates the versatility of SAS. The ability to   
               read multiple logical records as a single data record is 
               a boon to social scientists with 80-byte card image data,
               10 card images per subject. SAS lets you treat that as a 
               single, 800 byte record (which reduces the human errors  
               in data entry, coding, etc.). STOPOVER is still useful in
               SMF and other structured data records, but I think the   
               tests built into MXG are strong enough to detect any real
               VM/XA errors softly. The removal of STOPOVER in this case
               may let the latent power of SAS shine through, but Martyn
               says even MISSOVER may not always work and he is sending 
               a VM/XA monitor tape for further analysis.               
   Thanks to Martyn Stevens, Barclays Bank, ENGLAND.                    
Change 07.085  VM/XA IUCV/VMCF fields had two labels reversed; PLSVSEVM 
VMACVMXA       should be "GOOD FROM" and PLSVSTVM should be "GOOD TO".  
May 24, 1989   The following table may make IUCV/VMCF analysis easier.  
                                 --------TO---------        --FROM--    
           Service Destination    GOOD        BAD             GOOD      
  IUCV:    BLKIO                PLSISTBL    PLSISUBL        PLSISEBL    
           CCS                  PLSISTCC    PLSISUCC        PLSISECC    
           MSG                  PLSISTM     PLSISUM         PLSISEM     
           MSGALL               PLSISTMA    PLSISUMA        PLSISEMA    
           MONITOR              PLSISTMO    PLSISUMO        PLSISEMO    
           RPI                  PLSISTRA    PLSISUTA        PLSISETA    
           SIGNAL               PLSISTSI    PLSISUSI        PLSISESI    
   VMCF:   A Virtual Machine    PLSVSTVM    PLSVSUVM        PLSVSEVM    
   Thanks to Rob Owens, SAS Institute Europe, GERMANY.                  
Change 07.084  The 1984 MXG Guide, page 213, shows the IBM CICS tables  
MXG Guide      that need to be assembled to create type 110 CMF SMF data
May 24, 1989   records.  The syntax CLASS=(PERFORM,ACCOUNT,EXCEPTION) is
               not acceptable, apparently, for CICS 1.7. A site reported
               IBM support said a separate DFHTYPE=RECORD statement is  
               needed in the MCT for each Class of data monitored. Also,
               the example on page 213 should have suggested CONV=YES be
               specified, so that each CICS interaction/conversation's  
               response time is measured.                               
   Thanks to Bill Fox, National Futures Association, USA.               
RMFINTRV       DEVPNDTM were documented in the MXG Supplement to contain
May 24, 1989   only DASD device data, but RMFINTRV was never updated to 
               select only DASD type 74 records. (Note that even after  
               this change, that total SIO counts are still carried in  
               the SIO78CNT variable). Insert new line 072010:          
                IF SUBSTR(PUT(UCBTYPE,HEX8.),5,2)='20';                 
   Thanks to Cathy Librachi, Aurora Health, USA.                        
Change 07.082  CICSTRAN variables MAXTASK and SHRTSTOR were not correct,
VMAC110        because once either condition was found in a transaction,
May 24, 1989   the rest of the transactions in that physical SMF record 
               were also flagged "Y", because the two variables were not
               Insert two new lines 058410 and 069310:                  
                  ELSE MAXTASK=' ';                                     
               Insert two new lines 058510 and 069410:                  
                  ELSE SHRTSTOR=' ';                                    
   Thanks to Dennis Mahbubani, Aetna Casualty, USA.                     
Change 07.081  TYPE72MN (MVS/ESA-Only RMF Monitor III records) are all  
VMAC7072       trashed because MONIDLS, MONPGIN and MOSLOT should have  
May  9, 1989   all been PIB4. (this was a finger fault; the SKIP logic  
               expected 4-byte counters!)                               
   Thanks to Don Friesen, B.C. Systems, CANADA.                         
Change 07.080  These sample CICS SAS/GRAPH routines had not been updated
GRAFCICS       for SAS 5.18. All GOUT= were changed to PDB.GRAFCICS and 
May  9, 1989   the final data step deleted. After execution, the graphs 
               can be replayed with PROC GREPLAY IGOUT=PDB.GRAFCICS;    
   Thanks to Bill Salassi, BHP Systems, AUSTRALIA.                      
Change 07.079  DB2ACCT and DB2STAT0 variable QTXAPREC was decoded into a
VMACDB2        set of eight new variables: QTXABLLM QTXAIOLM QTXAINLM   
May  9, 1989   QTXASALM QTXASELM and QTXASPLM for ease in reporting DB2.
Change 07.078  IBM added four undocumented bytes to the end of RMF 77   
VMAC77         record in MVS 3.1.0e (and, yes, it is a lower case "e" in
May  4, 1989   the MVSLEVEL variable!). MXG did not use "skip" logic in 
               type 77 processing, and the TYPE77 data set is trashed.  
               Insert two new lines after line 018800:                  
                  018810  SKIP=LENEDSS-156;                             
                  018820  IF SKIP GT 0 THEN INPUT +SKIP @;              
   Thanks to Carol Rogers, K-Mart Apparel, USA.                         
Change 07.077  If you used %VMXGSUM with MAX= but without MIN=, wrong   
VMXGSUM        values were calculated. This did not affect any MXG code,
May  4, 1989   as all MXG uses of %VMXGSUM specified both MAX= and MIN=.
               Delete line 031500  %LET LASTX = &NUMMIN;                
Change 07.076  Landmark Monitor system record daccumulation (MONISYST)  
TYPEMONI       is wrong. The revised de-accumulation algorithm added in 
May  4, 1989   MXG 6.6 to process concatenated files always fails. This 
               ONLY affects the MONISYST data, and not the MONITASK data
               set. (That it took until now to be noticed suggests that 
               few users take advantage of the MONISYST dataset!). The  
               correction is to change lines 084600 thru 088900. Each   
               line is now of the form  Hnn = Variable;                 
               Each line must be changed to read   Hnn=Variable+Hnn;    
               For example, after the change:                           
                 084600    H1    =CPUTCTBM+H1 ;                         
                 089000    H45   =WTTSIOTM+H45;                         
   Thanks to Joseph J. Faska, Depository Trust, USA.                    
Change 07.075  Processing IMS 1.3 Log data is NOT possible with the MXG 
TYPEIMS1       algorithms for IMS 2.1 and IMS 2.2. These power of these 
VMACIMS1       algorithms (which recognize each IMS transaction instead 
May  4, 1989   of each program schedule) depend on several fields that  
               simply do not exist in the archaic 1.3 release:          
                -LINENR is not in type 35 log record                    
                -LTERM  is not in type 31O log record                   
                -ARRVTIME is always nulls in 03P record                 
                -DLRTOKEN only exists in the 07/08 records              
               The ability to recognize multiple transactions within a  
               program schedule is absolutely dependent on these data.  
               Thus MXG cannot claim to support transaction measurement 
               for IMS 1.3.  We have restored MXG Version 5.5 IMS logic 
               in new members TYPEIMS1/VMACIMS1 for IMS 1.3 sites. That 
               code made no attempt to recognize multiple transactions  
               per program schedule, but instead matched IBM's DFSILTA0 
               results to produce one observation in IMSTRAN for each   
               program schedule.  Since only 7 sites have requested our 
               IMS 1.3 processing, we can only offer this restoration.  
Change 07.074  Unused change number.                                    
Change 07.073  In TYPE26J2, TYPETASK may contain JOB0, TSU0, or STC0 as 
VMAC26J2       IBM prepared for JESNR greater than 9999 in the JCTJOBID 
May  4, 1989   field. This change reads only the first three bytes of   
               JCTJOBID into TYPETASK, but keeps its length at four to  
               avoid conflict with other data sets. Insert new line     
               013311 after 013310:  TYPETASK='    '; /*4 blanks*/      
               In line 013400 Change $CHAR4. to $CHAR3.                 
               In line 013500 Change +4 to +5                           
   Thanks to Carol Harper, E G & G Idaho, USA.                          
Change 07.072  In TYPE90, variable DETAIL was not reset for each class  
VMAC90         os SMF recording (JOB, TSU, STC). Now it is by insertion 
May  4, 1989   of ELSE DETAIL=' '; after DETAIL='Y';                    
   Thanks to Diane Eppestine, Southwestern Bell Telephone, USA.         
Change 07.071  In ROSCOE 5.6 RTM the number of complexity levels is set 
TYPEROSJ       by ROSCOE sysgen parameter RTMCMARK and the number of    
VMACROSC       time levels is sysgened by RTMTMARK. The actual number   
VMACSMF        of buckets in the RTM record is one less than the number 
May  3, 1989   of levels. MXG expects three complexity level buckets and
               five time level buckets (assumed RTMCMARK=4,RTMMARK=6).  
               You will encounter a STOPOVER abend if you sysgen less.  
               This change now uses information in the record to read in
               only as many fields as exist. Many lines were changed.   
               An unrelated change to ROSCOE processing was also made:  
               member TYPEROSJ has been deleted, and the code in VMACSMF
               that set OFFROSC was removed, because ROSCOE journal and 
               ROSCOE SMF records can be processed with member TYPEROSC 
               using a DDNAME of SMF for either dataset. TYPEROSJ was   
               only for ROSCOE 5.4 and earlier, and caused confusion.   
   Thanks to Art A. Brax, Jefferson Co. Colorado School District, USA.  
   Thanks to Sandy Recchio, Chase Lincoln First Bank, USA.              
Change 07.070  This enhancement to dataset activity analysis added VSAM 
ANALDSET       TYPE64 records, new fields (eg. OPENTIME) from TYPE1415, 
Apr 30, 1989   and enhanced the description of the job. If you want to  
               know which program in which job opened which file for    
               how long and for how much I/O, this is the place to go.  
Change 07.069  This enhancement to DB2PM-like reporting adds many small 
ANALDB2R       changes as a result of more detailed validation with DB2 
Apr 30, 1989   Version 2.1 data and report formats, and adds additional 
               reports. This revision now invokes %VMXGSUM to summarize 
               which reduced the size from 12,000 lines to only 7,150!  
Change 07.068  The VTOC processing code only expected 16 extents, since 
VMXGVTOC       the code was written before there was VSAM. With this    
Apr 30, 1989   enhancement, MXG now expects up to 128 extents to fully  
               support VSAM data spaces in a VTOC.                      
Change 07.067  The long promised MXG Tape Mount Monitor, MXGTMNT, lives!
ASMTMNT        Member ASMTMNT contains the assembly source for the load 
EXTMNTMN       module MXGTMNT and the JCL to create the proclib member  
EXTMNTSW       MXGTMNT. MXGTMNT executes in its own address space and it
IMACTMNT       creates an SMF record for every tape mount with the start
TYPETMNT       and end timestamps, duration of the mount, and the job   
VMACTMNT       causing the mount.  MXGTMNT also creates a record if a   
Apr 30, 1989   "tape swap" occurs as the result of a permanent error.   
               The installation instructions for the tape mount monitor 
               are contained in comments at the beginning of ASMTMNT.   
               Please read completely before executing. Member IMACTMNT 
               contains the SMF record ID that you chose in ASMTMNT.    
               Member TYPETMNT/VMACTMNT creates two data sets from the  
               SMF record: TYPETMNT contains mount information and      
               TYPETSWP contains swap events.  The monitor has been     
               tested under MVS/370 and MVS/XA, and should execute under
               MVS/ESA as well. Members ASMTPMON and ASMTP370 have been 
               replaced by ASMTMNT.                                     
Change 07.066  Exits EXPDBWEK and EXPDBMON have been added to the PDB   
EXPDBMON       WEEKBLD and MONTHBLD members so that users who have added
EXPDBWEK       additional SMF records to BUILDPDB/3 (using the MXG Exit 
MONTHBLD       Facility, page 139 in the MXG Supplement) can copy those 
WEEKBLD        additional data sets into their MONTH and WEEK PDBs.     
Apr 29, 1989                                                            
Change 07.065  DB2 Trace SMF type 102 record support has been expanded  
FORMATS        and further validated and revised with Release 2.1 data. 
IMAC102        The subtype 106 (System Parameter) record (in T102S106)  
VMAC102        was completely re-formatted by IBM in 2.1, requiring a   
Apr 28, 1989   rewrite.  Subtypes 67, 98, 99, 101, 112, 122, and 123    
May  9, 1989   have now been tested with 2.1 data. An entire new class, 
               Audit (subtypes/IFCIDs 140-145) is now supported, though 
               only subtypes 140 and 141 were available for testing.    
               Logic now tests QWHSNSDA (in 2.1) or record length (1.3) 
               to determine the actual number of triplets, which avoided
               a STOPOVER conditions. Subtype 53 and 58 were rewritten  
               to decode the SQLCA and to avoid STOPOVER conditions. New
               macros are now defined in IMAC102 for the Audit classes. 
               Some subtypes that were not in their correct trace class 
               groups were moved to where they belong, and the subtype  
               to trace class documentation (in IMAC102) revised. This  
               was a significant change to type 102 processing for 2.1. 
               Note: All 120+ T102Snnn datasets are always created by   
               MXG, but only those "enabled" by IMAC102 will actually   
               have observations. However, SAS requires virtual storage 
               for each data set at compile time. With only a 4MB region
               it was necessary to specify SAS Option BLKSIZE=8192 for  
               the TYPE102 program to execute.                          
   Thanks to Stan Stoots, Virginia Power, USA.                          
   Thanks to Stan Majka, Virginia Power, USA.                           
   Thanks to Peter Gallinari, Reader's Digest Association, USA.         
VMAC110        were not initialized and could be carried forward into   
Apr 27, 1989   a subsequent exception observation. All six variables    
               are now initialized to missing after line 101600.        
   Thanks to Dee Ramon, Mutual of America, USA.                         
Change 07.063  Trending RMFINTRV from PDBs built before MXG 6.6 causes  
TRNDRMFI       Variable Not Found condition (which cannot be solved by  
Apr 27, 1989   the NOVNFERR SAS option), because of the new OTH6-OTH0   
               variables added in MXG 6.6 to RMFINTRV that are not in   
               RMFINTRV built by prior versions of MXG. If you want to  
               use previously built PDB librarys as input for trending  
               you must create 70 new lines after 014500 (one line for  
               each of the 14 variables in each of the 5 OTHn groups).  
               The 70 variable names are in lines 003900-004100 and in  
               lines 005700-006800. Each new line will be:              
                   IF variable=. THEN variable=.;                       
               For example, the first line will be:                     
                   IF OTH6ACTV=. then OTH6ACTV=.;                       
   Thanks to Georg Simon, Federal Reserve Bank of Philadelphia, USA.    
Change 07.062  NETSPY records caused zerodivide condition because the   
VMACNSPY       denominator in lines 041200 thru 041500 should have been 
Apr 26, 1989   TOTRSPNO instead of TRANSNO.                             
   Thanks to ???, KF Data, SWEDEN.                                      
Change 07.061  TYPE74 variables AVGPNCHA, AVGPNCUB, AVGPNDEV are labeled
VMAC74         as containing milliseconds of pending time for channel,  
Apr 25, 1989   control unit, and device, but erroneously are in seconds.
               This change corrects the calculation so that the values  
               are in milliseconds and agree with the labels. In lines  
               039700 thru 039900, change the lines which now read:     
               to read:                                                 
   Thanks to Ron Higgins, American Honda, USA.                          
Change 07.060  NetView Release 2 writes "Hardware Monitor External Log  
VMAC37         Record" as SMF type 37 Records and their contents are    
Apr 27, 1989   described in NetView Administration Reference SC30-3361-2
               (Appendix A pages 97ff). This change adds support for    
               three new segments (LPDA-2, LAN, and Generic Event) into 
               the TYPE37 data set.                                     
Change 07.059  NetView Release 2 writes "Session Monitor External Log   
VMAC39         Record" as SMF type 39 Records and their contents are    
Apr 27, 1989   described in NetView Administration Reference SC30-3361-2
               (Appendix A pages 163ff). This change adds support for   
               new subtypes 7 and 8. Subtype 7 in TYPE39_7, Init Failure
               is identical to pre-existing TYPE39_6 dataset. Subtype 8 
               in TYPE39_8, Storage and Event contains 44 new variables.
               (VM NetView also writes SMF format data to its external  
               file which should be processable with TYPE39, but this   
               has not yet verified).                                   
   Thanks to Russell Brooks, James River Corporation, USA.              
Change 07.058  JES3 BUILDPD3 prints TYPE30_5 (twice!) due to debugging  
BUILDPD3       code (lines 013900 and 014300) which are now deleted.    
Apr 20, 1989   Two PROC CONTENTS of the PDB and WORK ddnames are deleted
               (lines 059100 thru 059400) because ANALCONT provides the 
               same report. (Some sites did not want the contents, but  
               I find them worthwhile in tracing problems.)             
   Thanks to George Scott, Rockwell International Corporation, USA.     
Change 07.057  VM/XA Monitor records have been altered by PTF VM35971   
VMACVMXA       and VM35321 which are now supported by MXG. VM35971 adds 
Apr 20, 1989   VMDCTMIG (Pages Migrated from ESTORE to DASD), VMDCTXWT  
               (Pages written from main to ESTORE) and VMDCTXRD (pages  
               read into main from ESTORE) to the VXUSEACT and VXUSEATE 
               detail data sets. MXG adds the new variables to the MXG  
               created VXBYUSR, VXSUMUSR and VMXAINTV datasets, storing 
               the values as rates per second as are other paging data. 
               PTF VM35321 adds VMDCPUAD (CPU Address) to the VXSCLADL, 
               VXSCLDDL and VXSCLAEL Schedule records. This now permits 
               MXG to properly de-accumulate those data (prior to this  
               fix, the schedule data was unusable because VMDCPUAD was 
               needed to de-accumulate those data).                     
   Thanks to Richard Steele, Louisville Gas and Electric, USA.          
Change 07.056  TPX SMF records read directly from active VSAM data set  
VMACTPX        cause STOPOVER because MXG was incomplete. In line 032000
Apr 19, 1989   change TPXOFF=TPXOFF-3; to TPXOFF=TPXOFF-3+OFFSMF;       
               There is no problem processing TPX records from a normal 
               SMF dumped dataset.                                      
   Thanks to Bob Lemaster, Central Bank of the South, USA.              
Change 07.055  Support for the TLMS (Tape Library Management System) CA 
TYPETLMS       product is added by this user contribution. The code was 
Apr 19, 1989   restructured but has yet been tested with real data in   
               its revised form. The TLMS Catalog is read to create an  
               observation for each tape volume.                        
   Thanks to Wing Louie, Chase Manhattan Bank CDC, USA.                 
Change 07.054  NPM Type 28 Subtype 5C (Dynamic Reconfigure Notification)
VMAC28         caused STOPOVER because DRNTNAM, Target Resource Name, is
Apr 18, 1989   not always present (this is not documented by IBM).      
               Insert new line 164310 after line 164300:                
                 164310    @; IF LENTOF GE 19 THEN INPUT                
               to conditionally input DRNTNAM when it is actually there!
   Thanks to Larry Doub, R J R, USA.                                    
Change 07.053  DB2 Version 2.1 causes "VMACDB2 DATA. UNEXPECTED ID=100  
VMACDB2        NRINSD=14 and NRIFCID=13" messages on the SAS log. This  
Apr 18, 1989   is not really a problem to worry about. The NRINSD and   
               NRIFCID count the number of Destination Data Sections and
               Instrumentation Data Sections in the record, which count 
               records written for the monitor, and do not relate to the
               DB2 system itself. As a result, MXG kept only the first  
               three NRINSD destination names and only the first five   
               IFCIDs (see page 203 of the MXG Supplement for the list  
               of variables that are kept). I don't think the counters  
               are useful, and if they were, it should be done with an  
               additional data set. Until someone demonstrates a need to
               use this obscure data, I have re-worded the text of the  
               knew for sure it was always 14/13 I might suppress the   
               note. This change also corrected some minor logic errors 
               in deciding when to print the message: Line 094800 should
               GT 3 instead of GT 5, and -4 should be -2, and 094900 is 
               PIB2. instead of $CHAR4.                                 
   Thanks to Siegfried Trantes, Gothaer Versicherungsbank VVAG, GERMANY.
Change 07.052  SYNCSORT SMF records read from "active" VSAM SMF file    
VMACSYNC       caused STOPOVER abend (but worked fine from dumped SMF). 
Apr 18, 1989   Remove +OFFSMF from line 026200.                         
   Thanks to Dave Greene, Kwasha Lipton, USA.                           
Change 07.051  RMF Monitor III VSAM data sets are supported by this     
EXZRB...       major user contribution. (In MVS/ESA, a very small       
IMACZRB        part of the Monitor III data is written as a subtype     
TYPEZRB        of the Type 72 record and supported in TYPE72MN data     
VMACZRB        set introduced in MXG Version 6.6). The workload         
ZRBJCL         delay monitor data is far more extensive that that,      
ZRBRPTn        and this extensive set of code processes those VSAM      
ZRBWORK        RMF III data into several data set names. Although       
Apr 12, 1989   the "ERB" acronym is the more appropriate name for       
               these data, I renamed Dick's use of ERB to ZRB as I      
               expect this code will be short lived as MVS/ESA takes    
               over in the future.                                      
   Thanks to Dick Whiting, Precision Castparts, USA.                    
Change 07.050  Concatenated VM/Monitor data contained invalid values    
VMACVMON       for the first interval after each START event, because   
Apr 12, 1989   MXG incorrectly outputted all intervals, when it was     
               intended to only output beginning with the second. In    
               all twenty occurrences of IF INTRVCNT GT 0 THEN ....     
               must be changed to        IF INTRVCNT GT 1 THEN          
   Thanks to Rodney L. Reisch, General Electric Plastics, USA.          
Change 07.049  The references to _CICOTHR for the ddname of the CICS    
ANALCICS       ACCT, EXCE, and YSTM data sets should have been changed  
Apr 11, 1989   to _CICACCT.CICSACCT, _CICEXCE.CICSEXCE and              
               _CICYSTM.CICSYSTM to be consistent with IMACCICS.        
   Thanks to Mark Hutchinson, Atlantic States Bank, USA.                
Change 07.048  IMS Log Record decoding corrections.                     
VMACIMS      a.After 024700 (the @; after DEST $CHAR8.), insert line    
Apr  9, 1989     IF _IMSVERS GE 2.2 THEN INPUT MSGIHSQN $CHAR8. @;      
               IMS 2.2 added this eight byte field and MXG missed it.   
               Without the fix, IMS 2.2 abended with STOPOVER (though   
               several IMS sites looked at the hex dumps, inserted an   
               +8 before the SIZELU6 variable to align and circumvent!) 
             b.Change 027400 from LOC=MSGPRFLL; to LOC=MSGPRFLL-3;      
               so that MSGXDLEN is correctly read in and used for the   
               MSGLEN, MSGSZIN, and MSGSZOUT variables.                 
             c.Both references to unused unkept COMMFLAG were deleted.  
             d.Insert after line 043500 (between DLRTOKEN and PSTTSKID  
                @; IF _IMSVERS GE 2.1 THEN INPUT                        
             e.Insert after line 056010 (between MSGDRRN and DLRTOKEN   
                @; IF _IMSVERS GE 2.1 THEN INPUT                        
               Items d. and e. prevent STOPOVER with IMS 1.3 data.      
             f.Any time stamp was set missing if PTIME was exactly zero 
               (midnight). The PTIME/PDATE INPUT statement uses the ??  
               syntax (suppresses hex dump and error message and makes  
               value missing for invalid PD. data). Thus PTIME could be 
               zero, causing MXG to not calculate a datetime variable.  
               All statements testing PTIME GT 0 were changed to test   
               PTIME GT . (missing value).                              
             g.Log type 35x records were not always output, causing the 
               ENQTIME to be missing which caused an out-of-sort-order  
               failure to merge ENQTIME with other transaction records. 
               Heuristic logic testing ENQFLAG and FLAG2 bits determine 
               if a 35x record is for input, output, message-switch, or 
               program-to-program, brute-force determined by finding a  
               combination, then looking at a detail trace to determine 
               the proper IMS35x data set to output. Values previously  
               unseen were skipped and not output. Now, unknown values  
               are printed on the SAS log. (If you should encounter a   
               new combination, call and we'll discuss how you can dump 
               the IMS log records to figure out which IMS35x dataset it
               should be put in - I sure wish there were a better way!) 
               This change restructured logic in IMACIMS to remove the  
               RETURN statements and replaced IF's with ELSE IF's.      
   Thanks to Harry Olschewski, DVG Kiel, GERMANY.                       
   Thanks to Siegfried Trantes, Gothaer Versicherungsbank VVAG, GERMANY.
Change 07.047  RACF Auditor reports from SMF type 80 record exposures.  
ANALAUDT     1.In member ANALAUDT, references to _RACF must be changed  
FORMATS        to _AUDT (which sets the DDNAME containing your TYPE80   
Apr  9, 1989   data set, defined in IMACANAL).                          
             2.The remainder of this change corrects only the values of 
               variables ALLOW and INTENT in SUF/INSUF Auth. reports.   
               There is no other impact if you do not put this fix on.  
               This report decoded ALLOW and INTENT from the wrong byte 
               of RACFDATA, in a block of code in the wrong location,   
               and were not RETAINed for multi-observation RACF events! 
             a.ANALAUDT changes:                                        
               -Add ALLOW INTENT to RETAIN at line 009400.              
               -Block COPY lines 016300 thru 018100 (from /* RESOURCE   
                to associated END;) TO AFTER line 012500. In the new    
                block you copied:                                       
                -Add OR RACFQUAL=200 after RACFQUAL=201                 
                -Change both tests for RACFDLN GE 3 to RACFDLN GE 1     
                -Change SUBSTR(RACFDATA,3,1) to SUBSTR(RACFDATA,1,1)    
                 in ten statements within this copied block.            
                -Delete the statement OUTPUT INSUF;                     
               -Now, go back to lines 016300 thru 018100, delete the    
                entire block, and replace it with these two lines:      
                  016400 IF RACFQUAL=201 THEN OUTPUT INSUF;             
                  016500 IF RACFQUAL=200 THEN OUTPUT SUF;               
             b.Additional cosmetic changes made for next Version that   
                are truly optional for now:                             
                -In ANALAUDT, after RETAIN at line 009400 new line:     
                   FORMAT ALLOW INTENT MG080AI.;                        
                -In FORMATS, after MG080EV definition, add new format:  
                   VALUE MG080AI                                        
             c.One additional change, but only for users of the FACOM   
               operating systems type 80 records. Format MG080QU has a  
               slightly different meaning for four values, which are    
               changed in member FORMATS (after VALUE MG080QU) to now   
               describe either IBM or FACOM type 80 records:            
                   101:INVALID PASSWORD (FACOM: OR GROUP)               
                   102:INVALID GROUP (FACOM:UIDCARD)                    
                   103:INVALID OIDCARD (FACOM:TERMINAL)                 
                   104:INVALID TERMINAL (FACOM:APPLICATION)             
   Thanks to Ingrid Ahmer of Australian National, AUSTRALIA.            
    (railways), who sent an excellent discussion and fix for the code   
    relocation logic.                                                   
   Thanks to Thomas Peiper, KommunData, SWEDEN.                         
Change 07.046  MVS Step Accounting fields were decoded in MXG TYPE30_4  
IMACACCT       variables ACCOUNTn, but BUILDPDB/3 does not carry these  
IMACPDB        STEP accounting fields into PDB.STEP. Instead, the JOB   
VMAC30         accounting variables ACCOUNTn from the TYPE30_1 (Init)   
Apr 30, 1989   or TYPE30_5 (Job termination) records are used through   
               out BUILDPDB/3 logic, which is what almost every site    
               really wants. Step level accounting really does not work:
               you can't tell which step caused which PDB.PRINT data;   
               which account do you use in PDB.JOBS if different fields 
               are used on different steps, etc.  However, IBM does not 
               provide a mechanism for putting job-level account fields 
               in type 30_1 or type3-_5 records for Started Tasks (STC).
               This change creates additional variables SACCTn in both  
               TYPE30_V (interval) and TYPE30_4 (step) records, and the 
               SACCTn variables are now added to PDB.STEPS.  Please NOTE
               that PDB.JOBS is unchanged; ACCOUNTn variables for STCs  
               will still contain blanks. Further design considerations 
               of BUILDPDB logic is required before step account fields 
               could replace blank job accounting fields in PDB.JOBS.   
             1.Member VMAC30                                            
               SACCT1-SACCT9 was added to KEEP of TYPE30_4 and TYPE30_V 
             2.Member IMACACCT                                          
               SACCT1-SACCT9 were added. IMACACCT is usually modified as
               described on page 311 of the MXG Guide; changes made to  
               the number and length of ACCOUNTn variables must also now
               be made to the SACCTn variables.                         
             3.Member IMACPDB:                                          
               SACCT1-SACCT3 added to the MACRO _PDB30_4 list of which  
               TYPE30_4 variables will be carried into PDB.STEPS. (MXG  
               defaults to 3 ACCOUNT and now 3 SACCT variables).        
   Thanks to Michel Leveille, CTTL, USA.                                
Change 07.045  MXG Programs can be executed through JCL with either an  
JCLPDB         explicit DD DSN=MXG.SOURCLIB(XXXXXXXX) member name in the
JCLTREND       JCL, or by a //SYSIN DD * JCL statement followed by SAS  
PDBTREND       %INCLUDE SOURCLIB(XXXXXXXX); statements. MXG members that
Apr  9, 1989   contain JCL were inconsistent, some used member name and 
               some used %INCLUDE.                                      
            1. In favor of member name:                                 
            a. There was a historical limitation when JES could not     
               submit a job from a job if the submitted job contained a 
               SYSIN DD * JCL statement. The submitted job would simply 
               not execute. Making the DD * statements a member of a PDS
               and then using only member name DD statements solved the 
               problem. (This still is occasionally encountered at some 
               sites and/or levels of JES - anyone know why/when/what?) 
            b. JCL is easier to comment out than SAS. JCL needs only a  
               asterisk in col 3 of the DD statement. SAS usually needs:
               an INSERT character to make room for the leading /*,     
               typing of the /* delimiter before the statement,         
               a long shift cursor to the end of the statement,         
               typing of the */ delimiter after the statement,          
               (and only if you did not first have to cursor right, char
               delete to make room in the line buffer!)                 
            c. Production jobs which failed could be re-submitted in one
               step by editing the JCL member, commenting out the member
               names that had successfully completed and submitted to   
               run from that point.                                     
            2. In favor of %INCLUDE.                                    
            a. The MXG Exit Facility. You need the ability to change any
               MXG program in your USERID.SOURCLIB, and the use of JCL  
               member name prevents you from making effective use of the
               Exit Facility. Items b. and c. above were encountered at 
               State Farm and Sun, before there was an Exit Facility!   
            3. The conclusion. MXG will now use only %INCLUDE statements
               in JCL examples. Furthermore, all %INCLUDE statements in 
               JCL examples will be precedeed by five blanks to make any
               editing easier (as long as I don't forget to do so).     
   Thanks to Susan Marshall, SAS Institute Europe, GERMANY.             
Change 07.044  IDMS Performance Monitor SMF record processing did not   
VMACIDMS       retain TASBFLDS and TASNDBLV in the IDMSTAS data set. Add
Apr  9, 1989   TASBFLDS to the RETAIN statement (line 130300) and change
               the 2nd occurrence of TASMXRBB line 131000 to TASNDBLV.  
               Variable TASTTYPE in IDMSTAS identifies the type of task 
               (DC Task, CICS ERU, Batch ERU, or TPMON ERU) and several 
               variables only apply to specific task types. MXG did not 
               initialize these variables, and because these variables  
               must be retained (the IDMSTAS record is segmented into   
               256 byte pieces because of the 256 byte IDMS Journal),   
               the "other" variables will have retained values from a   
               prior IDMSTAS observation. As long as you use TASTTYPE   
               you should not have a problem, but the real fix inserted 
               25 lines after 123300 to initialize the retained values: 
                 SKIP=SKIP-40;                                  123300  
                 TASTSKCD ='        ';                          123310  
                 TASPGMNM ='        ';                          123320  
                 TASLTEID ='        ';                          123330  
                 TASPTEID ='        ';                          123340  
                 TASUSER  ='                                ';  123350  
                 TASPGDBN ='        ';                          123360  
                 TASPGNOD ='        ';                          123370  
                 TASLDLST ='        ';                          123380  
                 TASAMNAM ='        ';                          123390  
                 TASFACCD =' ';                                 123391  
                 TASCTI   ='        ';                          123392  
                 TASCPGNM ='        ';                          123393  
                 TASCTETI ='        ';                          123394  
                 TASCLID1 ='    ';                              123395  
                 TASCLID2 ='    ';                              123396  
                 TASCTEOI ='        ';                          123397  
                 TASCJBNM ='        ';                          123398  
                 TASBJBNM ='        ';                          123399  
                 TASBPGNM ='        ';                          123400  
                 TASBNFLD =.;                                   123401  
                 TASBBALN =.;                                   123402  
                 TASBFLDS ='                                ';  123403  
                 TASTPGNM ='        ';                          123404  
                 TASTLID1 ='    ';                              123405  
                 TASTLID2 ='    ';                              123406  
          IF TASTTYPE='1.......'B THEN DO; /*ONLINE - DC TASK */123410  
   Thanks to Randy Springs, Glidden Paint, USA.                         
Change 07.043  VM/370 Account records contain blanks (rather than hex   
TYPEVM         zeros) for the VECVMTM and VECVIRTM vector CPU fields.   
Apr  9, 1989   (Four bytes of blanks input as PIB4.3 is 1,077,952.576!) 
               Lines inserted after 036900 to conditionally input:      
                 036910    @;                                           
                 036920    INPUT @65 TSTCHAR1 $CHAR4.                   
                 036930          @69 TSTCHAR2 $CHAR4.                   
                 036940    @;                                           
                 036950    IF TSTCHAR1 NE ' ' AND TSTCHAR2 NE ' '       
                                THEN INPUT                              
   Thanks to J. D. Hill, CyCare Systems, USA.                           
Change 07.042  NPM Type 28 SMF record subtype 60x,61x, and 62x were not 
VMAC28         output. Expand the test at line 200300 to include those  
Apr  9, 1989   three values of NPMSUBTY (and change comment in 200400   
               for EX028IN8 to read for NPMINNSA vice NPMINPMT).        
   Thanks to J. D. Hill, CyCare Systems, USA.                           
Change 07.041  Variables QTXAFLG1, QTXAIRLM, and QWHCOPID were not kept 
VMACDB2        in DB2ACCT keep list, but will be needed in DB2PM-like   
Apr  9, 1989   reports for DB2 Version 2.1. They are now kept.          
Change 07.040  Support for Tape Management System (TMS) Catalog records 
ANALTMS5       (tape volume sizes, last use, etc.) is now upgraded from 
TYPETMS        "X-rated (i.e, extra but not supported member) XMACUCC1" 
VMACTMS5       to these members.  There may be additional logic added   
Apr  8, 1989   after further testing. See comments in TYPETMS.          
   Thanks to Joseph J. Faska, Depository Trust, USA.                    
Change 07.039  The subtype 3 (Storage) type 22 SMF record (seldom if    
VMAC22         ever needed) fails with MVS/370 and old MVS/XA because   
Apr  7, 1989   NRPAGES may not exist and LOWADDR may be 2 or 4 bytes.   
               Change lines 046100 to 046300 to read:                   
             046100 IF LENGTH-COL EQ 1 THEN INPUT LOWADDR PIB2. @;      
             046200 ELSE IF LENGTH-COL GE 3 THEN INPUT LOWADDR PIB4. @; 
             046300 ELSE IF LENGTH-COL GE 7 THEN INPUT LOWADDR PIB4.    
                                                       NRPAGES PIB4. @; 
   Thanks to Dana Yam, Washington University, USA.                      
Change 07.038  These five members are one possible circumvention for a  
XMAC7072       "SAS Error 344 - Compiler Limit Exceeded" condition in   
XMAC71         executing BUILDPDB/3.  By copying these five members to  
XMAC73         your USERID.SOURCLIB library and renaming them to their  
XMAC74         corresponding VMAC.... name, the number of interative    
XMAC75         "DO" statements is reduced, and BUILDPDB might be able   
Apr  5, 1989   to compile successfully. (The ultimate fix will be SAS   
               Version 6 on the mainframe, which eliminates the limit in
               their compiler.) These members reduce the number of "DO"s
               by processing only MVS/XA and MVS/ESA RMF records, but   
               depending on which additional SMF processing members you 
               have added to BUILDPDB/3, even with this circumvention in
               place, you might still exceed the compiler limit.        
               An alternate circumvention which completely avoids any   
               exposure, and is only slightly more complicated, is to   
               use the IMACFILE exit to write the newly wanted SMF data 
               records to a temporary SMFOUT file, which is then passed 
               to an additional step in your BUILDPDB/3 job, which then 
               creates the additional data sets and copies them into the
               PDB ddname. In this way you will still only read your SMF
               dataset once, and by good choices of which records are in
               this temporary data set versus which records you process 
               in BUILDPDB/3, you can keep the temporary data set small.
               The XMAC7... members on Version 6.6 were unfortunately   
               not built correctly, and created different exposures. If 
               you need to use these five XMAC7... members to attempt to
               avoid the compiler limit, you will need to recreate them 
               their corresponding VMAC.... member, replace the MVS/370 
               processing lines with the indicated "Initialization IF"  
               statements so they end up as shown below:                
                Replace lines 043900 thru 085000 to be:                 
                043900    IF (ID=70 OR ID=72) AND NOT MVSXA THEN DO;    
                044000      IF SUPATERN=' ' THEN SUPATERN=' ';          
                085000    END;  /* TYPE 70, 72 RECORD FOR NON-MVSXA */  
                Replace lines 031500 thru 046100 to be:                 
                031500    IF ID=71 AND NOT MVSXA THEN DO;               
                031600      IF FRAMES  =. THEN FRAMES  =.;              
                031700      IF LPSWRCLM=. THEN LPSWRCLM=.;              
                031800      IF PVTMVCLC=. THEN PVTMVCLC=.;              
                031900      IF PVTMVDWN=. THEN PVTMVDWN=.;              
                032000      IF PVTMVUP0=. THEN PVTMVUP0=.;              
                032100      IF PVTMVUP1=. THEN PVTMVUP1=.;              
                046100    END;  /* MVS/370 TYPE 71 RECORD */            
                Replace lines 012700 thru 002270 to be:                 
                012700    IF ID=73 AND NOT MVSXA THEN DO;               
                012800      IF AVGENQUE=. THEN AVGENQUE=.;              
                012900      IF CHANMAP0=. THEN CHANMAP0=.;              
                013000      IF CHANMAP1=. THEN CHANMAP1=.;              
                013100      IF C0ANYCH =. THEN C0ANYCH =.;              
                013200      IF C0BYWT  =. THEN C0BYWT  =.;              
                013300      IF C1ANYCH =. THEN C1ANYCH =.;              
                013400      IF C1BYWT  =. THEN C1BYWT  =.;              
                013500      IF DEFCUBY =. THEN DEFCUBY =.;              
                013600      IF DEFDEVBY=. THEN DEFDEVBY=.;              
                013700      IF DEFERED =. THEN DEFERED =.;              
                013800      IF DEFLCHBY=. THEN DEFLCHBY=.;              
                013900      IF DEFPHYBY=. THEN DEFPHYBY=.;              
                014000      IF FQCUBY  =. THEN FQCUBY  =.;              
                014100      IF FQDEVBY =. THEN FQDEVBY =.;              
                014200      IF FQLCHRQ =. THEN FQLCHRQ =.;              
                014300      IF FQPHYRQ =. THEN FQPHYRQ =.;              
                014400      IF LCHAN   =. THEN LCHAN   =.;              
                014500      IF LCI     =. THEN LCI     =.;              
                014600      IF PCTDEFCU=. THEN PCTDEFCU=.;              
                014700      IF PCTDEFDV=. THEN PCTDEFDV=.;              
                014800      IF PCTDEFER=. THEN PCTDEFER=.;              
                014900      IF PCTDEFLC=. THEN PCTDEFLC=.;              
                015000      IF PCTDEFPY=. THEN PCTDEFPY=.;              
                015100      IF QUEUE0  =. THEN QUEUE0  =.;              
                015200      IF QUEUE1  =. THEN QUEUE1  =.;              
                015300      IF QUEUE2  =. THEN QUEUE2  =.;              
                015400      IF QUEUE3  =. THEN QUEUE3  =.;              
                015500      IF QUEUE4  =. THEN QUEUE4  =.;              
                015600      IF SIO73CNT=. THEN SIO73CNT=.;              
                015700      IF AVGPHYNQ=. THEN AVGPHYNQ=.;              
                015800      IF CPUID   =. THEN CPUID   =.;              
                015900      IF PCHANWT =. THEN PCHANWT =.;              
                016000      IF IDWRONG=' ' THEN IDWRONG=' ';            
                022700    END;  /* MVS/370 TYPE 73 RECORD */            
                Replace lines 012800 thru 002380 to be:                 
                012800    IF ID=74 AND NOT MVSXA THEN DO;               
                012900      IF CUBUSY  =. THEN CUBUSY  =.;              
                013000      IF DEFERCUB=. THEN DEFERCUB=.;              
                013100      IF DEFERED =. THEN DEFERED =.;              
                013200      IF DEFERSVD=. THEN DEFERSVD=.;              
                013300      IF DEVBUSY =. THEN DEVBUSY =.;              
                013400      IF LCHAN   =. THEN LCHAN   =.;              
                013500      IF PCTDEFCU=. THEN PCTDEFCU=.;              
                013600      IF PCTDEFER=. THEN PCTDEFER=.;              
                013700      IF PCTDEFRS=. THEN PCTDEFRS=.;              
                013800      IF PCTQUEDV=. THEN PCTQUEDV=.;              
                013900      IF PCTQUEPA=. THEN PCTQUEPA=.;              
                014000      IF QUEUE0=  . THEN QUEUE0  =.;              
                014100      IF QUEUE1=  . THEN QUEUE1  =.;              
                014200      IF QUEUE2=  . THEN QUEUE2  =.;              
                014300      IF QUEUE3=  . THEN QUEUE3  =.;              
                014400      IF QUEUE4=  . THEN QUEUE4  =.;              
                014500      IF UNITADR= . THEN UNITADR =.;              
                023800    END;  /* MVS/370 TYPE 74 RECORD */            
                Replace lines 006500 thru 012000 to be:                 
                006500    IF ID=75 AND NOT MVSXA THEN DO;               
                012000    END;  /* MVS/370 TYPE 75 RECORD */            
   Thanks to Larry Cecil, First National Bank of Chicago, USA.          
Change 07.037  Version 6.6 added variable PRENTIME to PDB.PRINT and its 
BUILDPDB       BY-list, but the change was incomplete and needed to be  
BUILDPD3       fixed (see Change 7.006) and documented (Change 7.036).  
Apr  3, 1989   Another exposure to incorrect sort order was seen and is 
               fixed by this change. The exposure only exists on the    
               very first run of the new BUILDPDB when PRENTIME does not
               yet exist in SPIN library, and only if the same job had  
               multiple print files with exactly the same PRINTIME on   
               different devices with one record in SPIN and one record 
               in today's SMF, AND only if the device names are not in  
               ascending alphabetical sequence! No one has reported the 
               exposure, but once noted, it was fixed by this change.   
               References to JPURTIME in this change fix another first  
               time exposure induced by Change 7.008, and make JES3     
               purge records sort order consistent with JES2.           
               Changes made to both BUILDPDB and BUILDPD3:              
  BUILDPDB BUILDPD3                                                     
   019310   019710    IF PRENTIME=. THEN PRENTIME=.;                    
   019320   019720    IF OUTDEVCE='        ' THEN OUTDEVCE='        ';  
   019330   019720    IF SYSPRN  ='    '     THEN SYSPRN  ='    ';      
   019410   019810    SYSTEM=SYSPRN;                                    
   020110   020510    IF JPURTIME=. THEN JPURTIME=.;                    
     n/a    023900    BY READTIME JOB JESNR JPURTIME;                   
   Thanks to Raymond Zieverink, Belk Stores Services, USA.              
Change 07.036  Implementation Considerations for WEEKBLD/MONTHBLD.      
WEEKBLD        Changes to MXG Software can usually be implemented at any
MONTHBLD       time. A powerful feature of the SAS system is its ability
Apr  3, 1989   to add variables to existing datasets and to create new  
               datasets automatically. To further ease implementation,  
               MXG logic uses SAS options "NOVNFERR" and "NODSNFERR" to 
               avoid "variable not found" and "dataset not found" errors
               whenever approriate.  Unfortunately, the NOVNFERR option 
               does not work if the variable is in a BY-list. Thus when 
               Version 6.6 added variable PRENTIME to PDB.PRINT dataset,
               we failed to document all that you might have to do to   
               avoid a "variable not found" or "data set is not sorted" 
               error in WEEKBLD or MONTHBLD. This is that documentation:
               If you implement the new BUILDPDB/3 code on Monday after 
               you have built your weekly PDB, you will avoid any change
               to WEEKBLD, since all of the new daily PDBs will contain 
               PRENTIME and will be correctly sorted.                   
               If you must implement the new BUILDPDB/3 in the middle of
               a week, you must modify WEEKBLD by inserting new line:   
                003110 PROC SORT;                                       
               (between the SET MON.PRINT ... SUN.PRINT; statement and  
               the BY ... statement). This will create the WEEK.PRINT   
               by concatenating all seven dailies in unsorted order, but
               now WEEK.PRINT will contain PRENTIME (since at least one 
               of the seven dailies was built with MXG 6.6 code). Then, 
               WEEK.PRINT is sorted by the original BY list. The only   
               cost of this modification is the double processing of the
               WEEK.PRINT dataset.                                      
               You MUST modify MONTHBLD since at least one prior weekly 
               PDB will have been built before the 6.6 BUILDPDB. You    
               must remove "PRENTIME OUTDEVCE SYSTEM" from the end of   
               the MACRO _BYLIST definition for the MONTH.PRINT dataset 
               in line 016001.  As soon as all input datasets used by   
               WEEKBLD/MONTHBLD have been built with the new version of 
               MXG, you can remove the modified members from your USERID
               SOURCLIB or MXG.CHANGLIB libraries and use the unmodified
               MXG code.                                                
               Page 263 of the MXG Supplement documented the sort order 
               of the PDB.PRINT data set, and should now read:          
   Thanks to Bill Salassi, BHP Petroleum, AUSTRALIA.                    
========Changes thru 7.035 were printed in NEWSLETTER FOURTEEN==========
Change 07.035  If you used the new member IMAC30IO to remove variable   
IMAC30IO       D3330DRV from the _IO30DR macro defined therein, and you 
IMACPDB        did NOT also change member IMACPDB to adjust the dummy   
Mar 15, 1989   X1-X9 variables, your PDB.JOBS data set contains wrong   
               values for ALL numeric values in the _SUMSTP macro that  
               is defined in IMACPDB. The documentation in IMAC30IO was 
               grossly inadequate, because it did not tell you to read  
               the instructions in lines 020000-023900 in IMACPDB. This 
               error affects ONLY the PDB.JOBS data set. Any TYPE30 data
               sets and the PDB.STEPS were built correctly, even if you 
               removed D3330DRV. Also, removing other variables from the
               other two macros (_IO30EX and _IO30TM) in IMAC30IO would 
               not cause any error.                                     
      FIX:     The simple fix is to simply leave variable D3330DRV in   
               the MACRO _IO30DR definition in IMAC30IO.                
               If you really are concerned about the extra four bytes   
               and do want to delete D3330DRV from your PDB.JOBS and    
               PDB.STEPS data, you can remove D3330DRV from the MACRO   
               _IO30DR definition in IMAC30IO, but you must then change 
                a) Line 024400, change DROP=X1-X9 to DROP=X1-X8         
                b) Line 024700, remove X9 from the SUM= list            
   Thanks to Trevor Holland, AUSTRALIA.                                 
   Thanks to Richard Evans, Mervyn's, USA.                              
               Comments expanded April 9, 1989:                         
               And even if you do delete D3330DRV as described above,   
               you will still find an UNINITIALIZED value note because  
               BUILDPDB/3 still have D3330DRV in two length statements  
               where it should have been changed to _MAXSTP:            
                BUILDPDB  BUILDPD3                                      
                  051600   051900   change D3330DRV to _MAXSTP          
                  055300   056100     "       "           "             
   Thanks to Lucy Fukishima, California Health & Welfare Agency, USA.   
Change 07.034  The FMXGUCBL function to dynamically allocate all DASD   
FMXGUCBL       devices may attempt to allocate a printer device. This is
FMXGUCBL       a soft error condition. It turns out that the FMXGUCB7   
Mar 15, 1989   function (provided because FMXGUCBL was thought to be an 
               MVS/XA-only function) actually uses an MVS/XA facility   
               that was retro-fitted into MVS/370. FMXGUCB7 not only is 
               usable under MVS/XA, it does not try to allocate printer 
               devices!  This change replaces FMXGUCBL member with the  
               contents of FMXGUCB7, changes FMXGUCB7 therein to read   
               FMXGUCBL, and deleted member FMXGUCB7.                   
   Thanks to Susan Marshall, SAS Institute Europe, GERMANY.             
   Thanks to Dan Squillace, SAS Institute Cary, USA.                    
Change 07.033  The VTOC processing example in member TYPEVTOC should use
TYPEVTOC       %VMXGVTOC instead of the erroneous %_MXGVTOC, and comment
TYPEVTOC       refering to member VMACVTOC should have been VMXGVTOC.   
Mar 15, 1989   Member VMACVTOC was replaced by VMXGVTOC and now VMACVTOC
               has been deleted to avoid the confusion.                 
   Thanks to Chun-Heng Liu, Brooklyn Union Gas, USA.                    
Change 07.032  MVS/ESA-only variables for SQA, LPA, CSA, LSQA, and REGS 
VMAC71         frames in CS (Central Storage, formerly Real Storage) and
Mar 15, 1989   in ES (Expanded Storage, formerly Extended Storage) are  
               missing. The test in these lines should have been:       
                083000  IF VERSNRMF GE 410 AND LENPGDS GE 504 THEN DO;  
                085600  IF VERSNRMF GE 410 AND LENPGDS GE 536 THEN DO;  
   Thanks to Don Friesen, B.C. Systems, CANADA.                         
Change 07.031  RMF Monitor III variables in Subtype 2 SMF Type 72 record
Mar 15, 1989   need zero divide protection in lines 165794 thru 165810: 
                  IF denominator GT 0 THEN WSETACT = numerator/denominat
                  ELSE WSETACT=.;                                       
   Thanks to Don Friesen, B.C. Systems, CANADA.                         
Change 07.030  In member ASUMCICS the label in line 009100 for variable 
ASUMCICS       RESPBKT6 should be 8 SEC instead of 6 SEC. Additionally, 
VMXGSUM        in member VMXGSUM the example in comments for "min, max, 
Mar 15, 1989   and sum" actually calculated mean, max and sum (and also 
               misspelled statistics).                                  
   Thanks to Susan Marshall, SAS Institute Europe, GERMANY.             
Change 07.029  An unexpected limitation of CMS SAS (although it is noted
new macros     in a documentation footnote): new style %MACRO names are 
Mar  9, 1989   limited to seven position names! Current MXG %MACROs that
               are now eight-characters long: ANALDB2R ANALDMON ANALNSPY
   Thanks to J. D. Hill, CyCare Systems, USA.                           
Change 07.028  Value tested for RECFM=VM should have been (line 003200):
VMACRCFM        003200  ELSE IF RECFMT='0100001.'B THEN RECFM='VM  ';   
Mar  9, 1989                                                            
   Thanks to Mr. Rathfelder, Taylorix, GERMANY.                         
Change 07.027  Beginning and ending times of DB2 reports were taken from
ANALDB2R       SMF timestamp and not the actual interval, causing loss  
Mar  9, 1989   of first interval.                                       
                Line 089300 Change VAR SMFTIME; to VAR QWHSSTCK DURATM; 
                Line 089400 Change MIN=MINSMF MAX=MAXSMF; to            
                                   MIN=MINSMF MAX=MAXSMF SUM=X1 DURATM; 
   Thanks to Jan van Lent, Fokker, NETHERLANDS.                         
Change 07.026  DOS/VSE POWER records have again (incompatibly) changed  
IMACDOS        the location of the RECID and the OFFSET that need to be 
Apr 26, 1989   set in IMACDOS.  IMACDOS now defaults to DOS 2.1.7.      
                VSE Version    OFFSET value    RECID @xx value          
                  3.1.2            0               @43                  
                  2.1.7            8               @51                  
                  2.1.3           16               @59                  
                  Earlier          0               @43                  
                Note that processing DOS data usually requires the JCL  
                LABEL parameter of (,NL) or (,LTM).                     
   Thanks to Bill Sikora, EDS Auburn Hills Mi, USA.                     
   Thanks to Barry Debenham, Cigna Services, ENGLAND.                   
Change 07.025  Cache DASD SMF record variables RWRATIO and READHR could 
VMACACHE       be non-zero even though there was no activity to a device
Mar  9, 1989   because they were not reset missing from the prior device
               segment in the same record. Insert two new lines:        
                051410  ELSE RWRATIO=.;                                 
                051510  ELSE READHR=.;                                  
               to reset when the denominators are zero.                 
   Thanks to Ray Dickensheets, Yellow Freight System, USA.              
Change 07.024  IDMS 10.2 Performance Monitor data written to Journal and
TYPEIDMJ       not to SMF was not correctly handled. There is a header  
Mar  9, 1989   of 20 bytes when data is written to the IDMS journal that
               is not in the SMF format data. Change to read            
                 001100  INPUT +20 PMSTYPE PIB1.                        
               (and make sure IMACIDMS was updated with the same value  
               set by #PMOPT RECID= in your IDMS gen.)                  
   Thanks to Mike Eisenhart, York International, USA.                   
Change 07.023  The PROC DATASETS NOLIST; DELETE DUMMY. _DSET; in the old
MONTHBLD       definition of _MNTHBLD is not acceptable to SAS. The full
Mar  8, 1989   dataset name is not supported in the DELETE statement. In
               place, and also at the end of the new definition which   
               follows the old definition, the correct syntax added is: 
               All this simply keeps the DUMMY library at minimum size. 
   Thanks to Pat Stockel, New Jersey Educational Computing Network, USA.
Change 07.022  Reading SMF data with the CMS version of SAS will cause a
VMACSMF        DMSSOP0363 Code 04 OPEN error. The CMS Version of SAS is 
Mar  8, 1989   limited by IBM's CMS OS Simulation code, which does NOT  
               support LRECL=32760, even though SMF records can contain 
               a real LRECL of 32760.  MXG Version 6.6 did change the   
               LRECL value in _SMF macro in VMACSMF from 32756 to 32760 
               precisely because we encountered STOPOVER abends when SMF
               data with real LRECL=32760 was encountered. If you must  
               process your SMF data under CMS SAS, you will need to    
               change the LRECL in the _SMF macro to 32756, and try it. 
               If the actual SMF data contains records actually 32760   
               bytes LRECL, you will STOPOVER abend, but if there are   
               no records that long you will be home free. If you do    
               have actual LRECL=32760 physical records, there may be   
               no immediate solution, but please call. (The IBM limit   
               is described on page 172 of SC19-6209 for VB and VBS     
               support under CMS Release 4). I have an open problem     
               with IBM on this IBM limitation.                         
   Thanks to J. D. Hill, CyCare Systems, USA.                           
Change 07.021  Sample CMS REXX EXEC for testing of MXG had the wrong    
REXXTEST       name for the FILEDEF in line 000523. Change MONWRITE to  
Mar  7, 1989   MWINPUT (and also in line 000524 change DIKS to DISK).   
   Thanks to J. D. Hill, CyCare Systems, USA.                           
Change 07.020  CICS sample reports for AMXT and CMXT task delays could  
ANALCICS       require lots of work space because all CICSTRAN variables
Mar  7, 1989   were kept. This change keeps only the needed variables.  
               Remove semicolon from line 043300 and insert new line:   
   Thanks to Janet Davis, Anchor Systems, USA.                          
Change 07.019  IBM documents SMF type 30 triplets (offset,length,number)
VMAC30         as present if "number" is non-zero, but one site found a 
Feb 20, 1989   record with length=0 and non-zero offset and number. (In 
               addition, the offset put this section in the middle of   
               the EXCP section!)  Though this is probably an APARable  
               IBM problem, it caused MXG a STOPOVER abend. As a result,
               MXG added a nonzero length test to each test for offset  
               and number, and then compares the record length to the   
               offset+(length*number)-1 to protect MXG from yet another 
               potential IBM data error. Whenever a bad triplet is found
               MXG prints an error message on the log, then deletes the 
               bad record and continues processing the SMF data.        
               Added Apr 5, 1989: ACCT section variable NRACCT does NOT 
               count the number of sections of length LENACCT, instead  
               NRACCT is the count of accounting fields within the one  
               account segment of length LENACCT. Test for ACCT is thus 
   Thanks to John Brown, Performance Systems Incorporated, USA.         
Change 07.018  The variable DEVICE for a Channel-to-channel adapter     
VMACUCB        was OTHER. This minor change now sets DEVICE='CTC'.      
Feb 15, 1989   Add new line                                             
                004110    ELSE IF DEVCLASS=41X THEN DEVICE='CTC';       
   Thanks to Bill Mullen, BGS, USA.                                     
   Thanks to Rodney L. Reisch, General Electric Plastics, USA.          
Change 07.017  Type 80 SMF records for RACF Version 1 Releases 8.1 and  
FORMATS        8.2 were already supported by MXG 6.6! There is only one 
VMAC80         new flag field and three new values of RACFQUAL (204-206,
Feb 15, 1989   whose meaning can easily be deduced from Table 1 in the  
               Appendix 10 of SC28-1343-4) added by RACF 1.8, and none  
               are significant.  This change creates variable RACFRE2   
               and adds three values to the MXG MG080QU. format.        
Change 07.016  This VM/370 HPO-only change affects user class variables 
Mar  8, 1989   and their values in VMONPERF.  DRPCANUS and DRPPOPUS were
               never de-accumulated and have always been wrong. In VM   
               HPO (version 4.2 and version 5, although documented only 
               for version 5) the user class record was incompatibly    
               changed by IBM, affecting the other user class variables 
               input after DRPPOPUS. This should be low impact for most 
               VM/370 HPO sites (unless, of course, you need the data!).
             a.This part supports the incompatible changes documented in
               Release 5 HPO, which have also been found (almost exact, 
               missing only the new VMACNT field) in HPO 4.2 data.      
               I don't yet know the PTF which made the 4.2 changes.     
               Move line 246700 to after 248600                         
               Change line 246800  GE to EQ                             
               Replicate lines 246800 to 248100                         
               Change line 248110 EQ 178 to GE 192                      
               Copy 246200 to 246500 after 248110                       
               Change 248111 from PIB4. to PIB8.                        
               Remove @133 @135 @137 from 248112 thru 248114            
               Change @139 PPSTSWUS PIB2. (line 248120) to              
                      @145 PPSTSWUS PIB4.                               
               Change line 248130 from PPSTPPUS PIB2. to PPSTPPUS PIB4. 
             b.This part applies to both HPO releases and corrects the  
               DPRCANUS and DRPPOPUS variables (and eliminates their    
               meaningless average and maximum value variables DRP...AV 
               and DRP...MX).                                           
               New Lines:                                               
                315910  DRPCANUS=DIF(DRPCANUS);                         
                315920  DRPPOPUS=DIF(DPRPOPUS);                         
                319910  IF . LT DRPCANUS LT 0 THEN LOGON=1;             
                319920  IF . LT DRPPOPUS LT 0 THEN LOGON=1;             
                322810  DRPCANUS=.;                                     
                322820  DRPPOPUS=.;                                     
               Line 328700 (follows /*AVG), DRPCANUS DRPPOPUS. This line
                must be moved immediately following 329400 (DEFRQ).     
               Line 330800 change X12 to X10.                           
               Lines 331000 and 331200, remove DRPCANAV DRPPOPAV.       
               Line 331500 remove X11 X12.                              
               Line 331800 add DRPCANUS DRPPOPUS after DEFRQ.           
               Lines 333900 thru 334200 (Labels for DRP...), delete.    
               Line 338100 remove DRPCANAV DRPCANMX DRPPOPAV DRPPOPMX   
   Thanks to Ron Roberts, The Equitable Life Assurance Society, USA.    
Change 07.015  This new member will be incomplete in your source library
ANALALL        even though the complete member is on the source tape!   
Feb 15, 1989   The member (to read SMF and print all records from a job)
               contains IEBUPDTE ./ control cards, which were processed 
               (unexpectedly) by IEBUPDTE in creating your MXG.SOURCLIB!
               Had you looked at the IEBUPDTE log, you would have seen a
               IEB816I message for ANALALL, followed by three IEB816I   
               messages for IMACJBCK, IMAC30DD, and IMACINTV which were 
               actually part of ANALALL! (Later in the log you would see
               the real IMACJBCK,IMAC30DD,IMACINTV create with IEB817I.)
               To create the ANALALL member, copy the source tape to a  
               sequential dataset on disk (IEBGENER,FB,80,6160), with   
               SPACE=CYL(1) and DISP=(,CATLG,CATLG). The job will ABEND 
               with B37, but the one cylinder data set will contain the 
               ANALALL member. Then use your editor to block copy the   
               lines between ./ ADD NAME=ANALALL & ./ ADD NAME=ANALAUDT.
               I have changed the "./" to "XY" and added comments to    
               change them back to avoid the problem in the future.     
Change 07.014  The Assembler parameters OJB/OBJECT and SYSLIN/SYSGO may 
EXITMONI       be different for different levels of ASM. Assembler XF   
Feb 15, 1989   (IFOX00) used SYSGO and OBJ. Early Assembler H (IEV90)   
               required SYSLIN and OBJECT, and if OBJ was used, NOOBJECT
               was set (with no condition code) and no object deck was  
               created, causing the LINKEDIT step to fail. An old PTF   
               (PP29236) to ASM H allows either OBJECT or OBJ (probably 
               as a result of ASM XF user complaints), even though only 
               OBJECT is actually documented for ASM H.  This change is 
               for info only, and was revised after Newsletter FOURTEEN.
   Thanks to John McAlpine, CSX, USA.                                   
   Thanks to Bob Rutledge, CSX, USA.                                    
Change 07.013  This is an interesting problem. Three separate STOPOVER  
VMACVMON       abends were encountered on three different VM/SP records 
Feb 15, 1989   that were shorter than expected. The culprit turned out  
               to be an error in VM Systems Group's VCOPY Product (a    
               replacement for IBM's CMS COPYFILE command). This site   
               used IBM's COPYFILE to copy VM/Monitor data. COPYFILE has
               has an option "TRUNC" (although IBM's default is NOTRUNC)
               that truncates blanks (X'40') when a fixed length file is
               converted to a variable length file (to save DASD space).
               When VCOPY replaced IBMs COPYFILE, its default of TRUNC  
               and a coding error in VCOPY (now fixed by Fix Co0263) had
               truncated all X'40's at the end of VM monitor records!   
               If you have VCOPY, you can either request the fix from   
               the vendor, change their system wide default to NOTRUNC, 
               or specify NOTRUNC on the COPYFILE statement to avoid    
               the unexpected data trunction. Hopefully, you will not   
               encounter the problem, but the MXG circumventions made   
               (before the truth was known) were left in place!         
               Change line 212800 to read:                              
                 INPUT @9 USER : $8. @; /*MN098UID*/                    
               Change line 216400 to read                               
                 IF LENDATA GE 1 AND LENDATA+19 LE LENGTH THEN          
               Insert two new lines after 229400:                       
                 229410:     @;                                         
                 229420:     IF LENGTH GE 40 THEN INPUT                 
   Thanks to Steve Smith, Hammermill Paper Co, USA.                     
Change 07.012  MVS/ESA TYPE1415 data now uses three bits of SMF14RIN to 
VMAC1415       indicate ILIB managed data set (Bit 0 on), Trunc macro   
Feb 15, 1989   issued (Bit 1 on) and/or Null segment encountered (Bit 3 
               on). MXG read byte one of SMF14RIN as variable RECIND1 & 
               byte two as RECIND2, but kept only RECIND1 (because all  
               bits in RECIND2 were formerly reserved). This change adds
               RECIND2 to the KEEP list for TYPE1415.                   
Change 07.011 -In a major enhancement to CPU data capture in MVS/ESA,the
IMACPDB        type 30 SMF records capture three new CPU measures:      
VMAC434        CPUHPTTM - Hiperspace CPU. The CPU time used to read from
VMACSMF                   and write to hiperspaces by this step/job.    
Feb 15, 1989   CPUIIPTM - CPU I/O SLIH time. The CPU time used by the   
                          Second Level Interrupt Handler in servicing   
                          I/O requests for this step/job.               
               CPURCTTM - Region Control Task CPU Time. The RCT handles 
                          QUIESCE and RESTORE and thus predominately is 
                          involved in SWAP management. This CPU measure 
                          should significantly help TSO capture.        
               All three CPU measures are NOT captured in the RMF TYPE72
               performance group data, nor are they in the type 4 or 34 
               step records. While the CPUHPTTM is a new measure of an  
               MVS/ESA-only activity (movement in/out of hiperspaces),  
               the CPUIIPTM and CPURCTTM now capture CPU times that have
               been THE major contributor to uncaptured CPU times: I/O  
               interrupt handling and TSO swap processing.              
               IBMs CPU timing comparisons in the DFSORT 11 announcement
               (289-036) use the sum of ALL CPU measures (the three new,
               plus the two TCB measures AND the two SRB measures). For 
               those of you who have had trouble convincing your bosses 
               to use TCB plus SRB for billing, etc., you can use this  
               example from big blue!  Note that IBM refers to "five"   
               CPU fields, but there are really seven fields now.       
              -Variables RECLAIMS, COMRECLM, and LPARECLM in TYPE30 and 
               TYPE434 (and hence in PDB.STEPS and PDB.JOBS) no longer  
               exist in MVS/ESA. In their same location are three new   
               MVS/ESA only variables:                                  
                 CREADMIS - Incorrect CREADS. Number of misses when an  
                  attempt to read data from an expanded-storage-only    
                  hiperspace failed because the data was not found (was 
                  variable RECLAIMS)                                    
                 HIPAGINS - Hiperspace pageins from auxiliary storage   
                  into processor storage (was variable COMRECLM).       
                 HIPAGOUT - Hiperspace pageouts (was variable LPARECLM).
               MXG 6.6 will "Tolerate" the new CPU fields (i.e. execute 
               without error), but for MXG to be "Capable" (i.e., to    
               create the new CPU fields in TYPE30 and PDB.JOBS/STEPS   
               data sets, and to create the three Hiper-related fields  
               you must make the following changes:                     
              -In member VMAC30:                                        
              -Add the three CPU variables (CPUHPTTM,CPUIIPTM,CPURCTTM) 
               and the Hiper variables (CREADMIS,HIPAGINS,HIPAGOUT) to: 
                -KEEP list for TYPE30_V, TYPE30_4, TYPE30_5, TYPE30_6.  
                -LABEL statement.                                       
               c. CPU vars only to FORMAT statement for TIME12.2 format.
              -Delete the CPUTM=SUM( ... ); statement, line 056800.     
              -Insert the following seven lines after line 057500:      
                 IF LENCPU GE 56 THEN INPUT                             
                        CPUIIPTM  PIB4.2                                
                        CPURCTTM  PIB4.2                                
                        CPUHPTTM  PIB4.2                                
              -Insert these lines after line 062000 (contains @;):      
               (Note that in the MXG implementation this change is more 
                extensive; variable MVSESA is now created by VMACSMF for
                MVS/ESA. This change avoids that additional Edit.)      
                 IF MVSXAFLG='....1...'B THEN DO; /* MVS/ESA */         
              -In member IMACPDB add the six new variables (CPUHPTTM,   
                 -The  _PDB30_4 definition at lines 013200-013300.      
                 -The _SUMSTP definition at lines 017700-017800.        
   Thanks to Dave Greene, Kwasha Lipton, USA.                           
Change 07.010  DB2 reports had minor errors. The use of "ALL" (to create
ANALDB2R       reports for all plans, all ids, etc.) was removed in MXG 
VMAC102        6.6 (but not specifically documented) because you might  
Feb 17, 1989   have "ALL" as a plan name, etc.  Now, to create reports  
               for "all" of something, use the default (by specifying no
               value for the argument).                                 
               In ANALDB2R:                                             
                 Line 235800 and 235900 must be reversed so DB2COUNT+1  
                 precedes the CALL SYMPUT statement.                    
                 Line 254300 should be QWPZTOUT and line 255100 should  
                 be QWPZISWI. (They are reversed).                      
               In VMAC102:                                              
                 Insert new line after 081900:                          
   Thanks to Ervin Claxon, Ashland Oil, USA.                            
Change 07.009  Processing multiple VM/XA Monitor files will cause the   
VMACVMXA       "Range is Repeated" error message in attempting to create
Feb 16, 1989   the temporary Format which maps Device Information to the
               RDEVSID value. Duplicate RDEVSID values do exist in the  
               VXMTRDEV data set, but MXG's logic to remove duplicate   
               values incorrectly included BEGINMTR in the BY statement.
      FIX:     Remove BEGINMTR from both BY statements in lines 678500  
               and 678800.                                              
   Thanks to Ray Dickensheets, Yellow Freight System, USA.              
Change 07.008  The JES2 Spool Transfer program causes multiple job purge
BUILDPDB       records. If a job which is still in the execution queue  
Mar 11, 1989   after it has been executed (eg., a job which encountered 
               a DSENQ conflict that was canceled and requeued, or any  
               job processed by the MVS Throughput Manager product) is  
               spool transfered and reloaded, two purge records will be 
               created (one at offload, one after real execution) and   
               both contain non-blank values for SYSEXEC. A non-blank   
               SYSEXEC separated the "real" purge record (for PDB.JOBS) 
               from the multiple NJE purge records (into PDB.NJEPURGE). 
               If two (or more) purge records with non-blank SYSEXEC are
               found in the same BUILDPDB run, duplicate observations in
               PDB.JOBS were built. The use of just SYSEXEC to identify 
               "real" purge records is insufficient. Part of this fix is
               a guarantee that only one "real" purge record is used by 
               MXG, even if multiple are found. The other part of the fi
               selects the purge record created at offload by JES2 Spool
               Transfer program (DEVNAME, Transmit Device Name beginning
               with OFF) into the PDB.NJEPURGE data set. If your site   
               does not use Spool Transfer, you have no exposure.       
      FIX:   1.BUILDPDB.                                                
               Insert new line after 014200:                            
                 014210     DEVNAME=:'OFF' OR                           
               Add JPURTIME to the end of the BY list at line 023500.   
               Insert new line after 023600:                            
                 IF LAST.JESNR THEN OUTPUT;                             
               Add DEVNAME to line 008600 (inside _PDB26J2 macro).      
   Thanks to Don Friesen, B.C. Systems, CANADA.                         
Change 07.007  MONTHBLD on the MXG 6.6 Library causes a SAS 180 SYNTAX  
MONTHBLD       error. In making the member more comsmetically appealing,
Feb 14, 1989   the invocations of _MNTHBLD ended up ending in column 72.
               Since the next line starts with MACRO, SAS combined the  
               end of one line with the beginning of the next to create 
               the string _MNTHBLDMACRO, which SAS cannot recognize!    
      FIX:     Delete the blank before the percent sign in each line    
               than ends with _MNTHBLD in column 72.                    
   Thanks to John Mattson, National Medical Enterprises, USA.           
Change 07.006  Variable PRENTIME in PDB.PRINT was added to the sort list
BUILDPDB       in BUILDPDB but was left in a DROP list in BUILDPDB/3 and
BUILDPD3       not added to the BY list in WEEKBLD. This caused PRENTIME
WEEKBLD        to not exist in PDB.PRINT and caused WEEKBLD to ABEND.   
Feb  9, 1989                                                            
      FIX:  1.BUILDPDB: remove PRENTIME from DROP statement line 048300 
            2.BUILDPD3: remove PRENTIME from DROP statement line 048700 
            3.WEEKBLD:  add PRENTIME to line 003200 between PRINTIME and
   Thanks to John Mattson, National Medical Enterprises, USA.           
   Thanks to Gary Ruedinger, Response Graphics, USA.                    
Change 07.005  DB2 Trace 102 SMF record subtype 58 or subtype 87 caused 
VMAC102        STOPOVER ("Input exceeded record length") for DB2 1.3 or 
Mar 11, 1989   earlier records.                                         
      FIX:     Insert new line after line 163900:                       
                 163910  @;  IF QWT02R1L GE 302 THEN INPUT              
               Add PIB4. after QW0087FR in line 144400.                 
               In subtypes 15,17,18,22,53, and 58 incorrect calculations
                caused the input to end before all fields had been read.
                Change ENDPROD to ENDPRODA in lines 098200,250800, and  
                Change OFFPROD to OFFPRODA in lines 160200,166400,      
                260400, and 263900.                                     
   Thanks to Jan-Ake Christoffersson, Gotabankendata, SWEDEN.           
   Thanks to Susan Marshall, SAS Institute Europe, GERMANY.             
Change 07.004  NPM type 28 produces "Unexpected Subtype" message for 08X
VMAC28         NPMSUBTY for the ENABLE NSA event record.                
Feb  7, 1989                                                            
      FIX:     Change first occurrence of 09X in line 197600 to 08X.    
   Thanks to Michelle Buchecker, IBM Boulder, USA.                      
Change 07.003  JCL for HSM processing included non-existent testing name
JCLHSM         of XMXGHSM.                                              
Feb  7, 1989                                                            
      FIX:     Change XMXGHSM to VMXGHSM in line 006600.                
   Thanks to Billy Westland, Candle Corporation, USA.                   
Change 07.002  MXG variable CPUTM in the CIMSTRAN data set from IMF data
VMACCIMS       from Boole & Babbage did not include all CPU variables,  
Feb  7, 1989   and the variable was not in the KEEP list. Also, SERIALIO
               was not protected if it overflowed its two byte counter. 
      FIX:   1.Insert new line 002410 (after 002400) containing  CPUTM  
             2.Add CPUCOPTM,CPUMOPTM, to the SUM function arguments     
               in line 044000.                                          
               CPUDB2TM to the SUM function arguments in line 070400.   
             4.Change LE 12 to LE 13 in line 065900.                    
   Thanks to Kenneth D. Jones, Maritime Telephone and Telegraph, CANADA.
   Thanks to Agneta Bergsten, SPP, SWEDEN.                              
Change 07.001  TREND data base code fixes. Always specify SAS Options   
GRAFTRND       MACRO and DQUOTE when using %MACROs. GRAFTRND will only  
TRNDJOBS       produce first and last pair of graphs if MXG Version 5.5 
TRNDRMFI       PDBs were used (because SU_SEC variable did not exist in 
TRND72         RMFINTRV until 6.6). When a macro variable is set by data
PDBTREND       value in a data step, a RUN; statement seems required at 
VMXGSUM        the end of the data step to actually set the macro value.
Mar  9, 1989                                                            
      FIX:   1.GRAFTRND: Change all occurrences of OTHRn (ten separate  
               times for n=0,1,...,9) to OTHn (without the R).          
               Line 007800 add OTH6CPU OTH7CPU OTH8CPU OTH9CPU          
               Insert two new lines:                                    
               011310 RUN;                                              
               017110 RUN;                                              
             2.TRNDJOBS line 002300 Add NUMJOBS after SUM= (before IWT) 
               Insert new line after 001200:                            
                  001210  %INCLUDE SOURCLIB(VMXGSUM,VMXGDUR);           
               Line 001400 add (IN=INWEEK) after WEEK.RMFINTRV          
               Lines 002600,29,32,35,38,41,44,47,50,53,56,59,62,65,68,75
                    OTH1CNT OTH2CNT OTH3CNT OTH4CNT OTH5CNT OTH6CNT     
                    OTH7CNT OTH8CNT OTH9CNT TRIVCNT to respective line. 
               Lines 011400,115,117,119,121,123,125,127,129,131,133,135 
                      137,139,141,143 change / ....TRAN to / ....CNT    
               Insert new line after 014500:                            
                  014510  IF INWEEK THEN DO;                            
               Insert new lines after 014700:                           
                  014710  END;                                          
                  014711  IF SU_SEC  =. THEN SU_SEC=.;                  
                  014712  IF PARTNCPU=. THEN PARTNCPU=.;                
                  014713  BATCNT=BATTRAN*DURATM;                        
                  014714  TSOCNT=TSOTRAN*DURATM;                        
                      .  (one for each of the 16 ...CNT variables added 
                       .    in lines 002600-007500 above)               
                  014727 OTH9CNT=OTH9TRAN*DURATM;                       
                  014728 TRIVCNT=TRIVTRAN*DURATM;                       
               After line 15400 insert                                  
                     OTH1CNT OTH2CNT OTH3CNT OTH4CNT OTH5CNT OTH6CNT    
                     OTH7CNT OTH8CNT OTH9CNT TRIVCNT;                   
             4.TRND72   line 001400 Semi-colon must be a comma          
             5.PDBTREND line 009500 %GRAFTRN must be %GRAFTRND          
                  insert new lines after 011200:                        
                  011210  PROC SORT;                                    
                  011220  BY SYSTEM PERFGRP;                            
               line 025900 Add DATETIME &DATETIME 8 before semicolon    
               new line 025910  IF DATETIME=. THEN DATETIME=.;          
               line 035400 Add DATETIME &DATETIME 8 at end of line      
               new line 035510  IF DATETIME=. THEN DATETIME=.;          
   Thanks to Alan W. Maloney, Telenet Communications, USA.              
   Thanks to J. D. Hill, CyCare Systems, USA.                           
   Thanks to Pete Shepard, Ashland Oil, USA.                            
   Thanks to Rich Lopez, Ethicon, USA.                                  
LASTCHANGE: Version  7                                                  
            This page is (almost) blank (intentionally).                
End of Changes Log, but how's this for page filler, printed verbatim    
 from an entry in IBM's INFO/SYS (SMF6CPS is COPIES in TYPE6):          
                                        E343725 (HIT LIST 000003/000013)
                                           LINES:   1 THRU   15 OF   15 
H E343725 S=TOOLS C=GY4 D=JUL89 E=JUL91                          L=00015
                          F   -SUGG -OY21704--5665-27-501--IN-INCORROUT 
REPORTED RELEASE    R220                                                
ERROR DESCRIPTION:                                                      
SMF6CPS IS NOT UPDATED CORRECTLY.                                       
                Change WILL NOT BE IMPLEMENTED.                         
89/07/19,CHICAGO FS