***********************NEWSLETTER SIXTY*********************************
          MXG NEWSLETTER NUMBER SIXTY, August 6, 2012                   
Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE
                         TABLE OF CONTENTS                              
I.    MXG Software Version.                                             
II.   MXG Technical Notes                                               
III.  MVS, aka z/OS, Technical Notes                                    
IV.   DB2 Technical Notes.                                              
V.    IMS Technical Notes.                                              
VI.   SAS Technical Notes.                                              
VI.A. WPS Technical Notes.                                              
VII.  CICS Technical Notes.                                             
VIII. Windows NT Technical Notes.                                       
IX.   z/VM Technical Notes.                                             
X.    Email notes.                                                      
XI.   Incompatibilities and Installation of MXG.                        
         See member CHANGES and member INSTALL.                         
XII.  Online Documentation of MXG Software.                             
         See member DOCUMENT.                                           
XIII. Changes Log                                                       
     Alphabetical list of important changes                             
     Highlights of Changes  - See Member CHANGES.                       
I.  The 2012 Annual Version MXG 29.29 was dated Jan 23, 2012.           
 1. The current version is MXG 30.05, dated Aug  8, 2012.               
    You can always use this form                                                           
    to request the ftp download instructions for the current version.   
    See CHANGES member of MXG Source, or    
II.  MXG Technical Notes                                                
 3. Processing DB2 compressed data using MXG EXITCICS vs IBM DSNTSMFD:  
     On z/OS, compressed DB2 data can be processed in a two-step job    
     using the IBM DSNTSMFD program to first decompress the SMF data,   
     which is then read with MXG's TYPEDB2 as the second step, or the   
     the EXITCICS (Version 2) "CICSIFUE Infile Exit" can be used by the 
     MXG TYPEDB2 program to decompress records as they are read.        
     The DB2 SMF file contained 2 million DB2 records:                  
       The two-step process took:        142.76 TCB Seconds CPU         
                                           6 min 10 seconds Elapsed     
                                         138,000 EXCPs                  
       The MXG one-step EXITCICS took    140.83 TCB Seconds CPU         
                                           3 min 55 seconds Elapsed     
                                          76,466 EXCPs                  
     So the CPU times are essentially the same, but the one step had    
     half the I/O activity.  While elapsed times are notoriously hard to
     compare, pretty clearly, the one-step process is faster due to the 
     elimination of the write-then-read time of the two-step process.   
 2.  Does MXG do any date/time checking while reading the SMF data?     
     Specifically, if the dump time for my SMF data is not midnight but 
     some other arbitrary time will I lose any data?                    
     First, no, MXG NEVER "loses" any data.                             
     Second, I've NEVER recommended running MXG exactly at midnight:    
      - the evening batch processing often extends beyond midnight, so  
        delaying the dump/BUILDPDB until later in the morning will give 
        you more information on "yesterday's" batch job processing.     
      - often, there is a significant flurry of activity right after    
        midnight.  Some applications run programs to store the new "day"
        in a date file, and operations often runs backups at midnight,  
        so BUILDPDB would be competing with (or impacting) those jobs.  
     Instead, I suggest that BUILDPDB should be run N hours prior to    
     when the reports are required, where N/2 is the typical run time   
     of the daily job and its reports!                                  
     MXG does NO date selection by default; you can select times in your
     IFASMFDP dump process, or you can use MXG's IMACFILE/MACFILE exit  
     to select by SMFTIME, but without that tailoring, MXG simply reads 
     the input SMF file(s) to create a PDB data library from all of the 
     SMF records in that input.                                         
     If you dump SMF data at 6AM, then your daily PDB will contain the  
     only the interval data (e.g., RMF) from 6AM yesterday until 5:59AM 
     today, but it will contain the event data (e.g., job completions)  
     for more of yesterday's batch processing.  If management wants the 
     interval RMF reports to cover midnight to midnight, you can read   
     two adjacent PDBs to select only yesterday's twenty-four hours:    
       DATA RMFREPORT;                                                  
        IF       PUT(TODAY(),WEEKDATE3.)='MON' THEN DO;                 
          SET SUN.RMFINTRV MON.RMFINTRV;                                
          IF PUT(DATEPART(STARTIME),WEEKDATE3.)= 'SUN';                 
          SET MON.RMFINTRV TUE.RMFINTRV;                                
          IF PUT(DATEPART(STARTIME),WEEKDATE3.)= 'MON'                  
        . . .                                                           
     But for the PDB.JOBS data, you would first have to define what you 
     mean as "yesterday": all jobs that were read in, or all jobs that  
     started execution, or all jobs that started and ended execution, or
     all jobs that were read in, executed, printed, and purges?  What   
     about jobs that were read in two days ago and are still running?   
     A "Job" is only output into PDB.JOBS when the job has purged, i.e.,
     when ALL of the SMF records for that job (30s, 6s, and 26s) have   
     been read, since only then are we guaranteed we have all of the    
     records for a job.  But each BUILDPDB also outputs "inflight jobs" 
     into the PDB.SPUNJOBS dataset, for all jobs that are still         
     incomplete.  So, if you want a tactical report of all jobs,        
     completed or inflight, that INITIATED and COMPLETED EXECUTION,     
     you would use this logic:                                          
       DATA JOBSREPORT;                                                 
        IF       PUT(TODAY(),WEEKDATE3.)='MON' THEN DO;                 
          SET SUN.JOBS MON.JOBS MON.SPUNJOBS;                           
          IF PUT(DATEPART(JINITIME),WEEKDATE3.)= 'SUN';                 
     because the JINITIME variable comes from the 30-5 Job Terminate SMF
     record.  If you wanted all jobs that INITIATED, you would use the  
     variable INITTIME, since it is the minimum initiate time from the  
     30-4 step records.  The complete documentation of which datetime   
     variables in PDB.JOBS come from which SMF records is to be found in
     the DOCPDB member.                                                 
 1.  Processing compressed DB2 V10 SMF Data on ASCII.                   
     A comparison of the cost of processing compressed DB2 SMF data on  
     ASCII (Windows Seven Ultimate), decompressing with the internal SAS
     code algorithm (which has to be use because INFILE exits are not   
     supported on ASCII platforms, so the EXITCICS exit cannot be used) 
     shows the decompression elapsed time and CPU time is about 2.8 more
     than the cost to process uncompressed records; compression reduced 
     the size of the file by a factor of 5, so, as always, compression  
     is a tradeoff between space and time (in seconds, below).          
       (Note that Newsletter 57 reported the internal SAS algorithm is  
       VERY expensive on z/OS, compared with the EXITCICS exit.)        
        One Million ID=101 records                                      
           2500MB           500MB                                       
        UNCOMPRESSED      COMPRESSED                                    
        ELAPSED  CPU      ELAPSED CPU                                   
           57      3         19     1   DATA _NULL_;INFILE SMF;INPUT;   
          107    100        284   282   %INCLUDE SOURCLIB(TYPEDB2);     
           50     97        265   281   Difference (Processing - Read)  
III. MVS, a/k/a z/OS, Technical Notes.                                  
10. An IBM-Main posting noted that DFSORT supports large format data    
    sets for sortworks, so each can use more than 64K tracks.  DFSORT   
    dynamically allocates them as large format, or for //SORTWKnn DD's  
    allocated in JCL allocated, you need to specify DSNTYPE=LARGE on the
    DD statements and DFSORT will support that.                         
 9. Using FTP to Transfer a VB files between two z/OS Systems.          
    You must specify the EBCDIC and BLOCK attributes                    
      type e                                                            
      mode b                                                            
    or the transferred data file will be corrupted/unreadable.          
    Item 20 in MXG Member FTPING has detail documentation and examples  
    (from an IBM tech note) for moving VB files between z/OS systems,   
    either directly z/OS-to-z/OS, or indirectly through an ASCII        
    platform, using either HFS or TSO TRANSMIT/RECEIVE to create an     
    intermediate file that can be sent z/OS-???-z/OS.  If you do have to
    use and ASCII platform, I think the better choice that is not in the
    IBM note would be to use TERSE/UNTERSE to create that intermediate  
    file, since it would reduce the transfer times to/from/between the  
    ASCII systems.                                                      
 8.  APAR OA38430 reports RMF CF Activity Report can show the CF        
     utilization (% busy) is very low, the service times are high and   
     the standard deviations are large.  Where a low % busy around 1%,  
     the service times are in the thousands of microseconds and the     
     standard deviation may be in seconds.  The CF engines were         
 7.  APAR PM57383 reports SMF 120 subtype 9 user name field in variable 
     SM1209ES can sometimes be blank, while that name field is correct  
     in subtype 1 records.                                              
 6.  APAR PM58287 reports SMF 117 field IMFLMFNM, which is MXG variable 
     S17FMFNM (MESSAGE*FLOW*NAME), is too short at 32 characters.  When 
     corrected, this will require an MXG change since the field can not 
     be increased in its current place in the middle of the record.     
 5.  APAR PM57680 reports changes to SMF 64 record causes the DSD record
     DSNAME field to be incorrect for VSAM datasets.                    
 4.  Observed: PGM=ADRDSSU, DFDSS backup program does NOT write SMF 42  
     subtype 6 records for the INPUT datasets that were backed up; only 
     the OUTPUT dataset created SMF records, so there is no tracking of 
     which datasets were backed up.  Whether this is intentional or an  
     oversight is under query to IBM support.                           
 3.  APAR PM49660 reports Waiter Information is missing in SMF 79       
     Subtype 15.                                                        
 2.  APAR PM55328 reports SMF 118 Records with Subtype=0 are written    
     even though SMFCONFIG TYPE118 keywords are all set to NO.          
 1.  In 2042, the current 8-byte STCK (TODSTAMP8.) datetime value will  
     wrap, with a value '17SEP2042:23:53:47.370495'.  In z/OS 1.11, IBM 
     introduced the STCKE instruction with a 16-byte output.            
       Note: the SMFSTAMP and RMFSTAMP formats will NOT wrap in 2042,   
       or ever, as they have a separate date-part with the century bit. 
     SAS will eventually provide an extended TODSTAMP16. (?) informat to
     read the STCKE value, but until then, if a vendor creates a record 
     with the extended TODSTAMP value, this code can be used to decode  
     STCKE now and after 2042.  This example STCKE value is 1.04 seconds
     after the 8-byte STCK would have wrapped:                          
     and this code                                                      
       INPUT STCKE1ST &PIB.1. STCKE2ND &PIB.8.6 +7  @;                  
       IF STCKE1ST=0 AND STCKE2ND=0 THEN STCKE=.;                       
       ELSE STCKE=STCKE1ST*FFTOD+STCKE2ND/4096;                         
       FORMAT STCKE DATETIME25.6;                                       
       LENGTH STCKE 8;                                                  
     produced the value of STCKE=17SEP2042:23:53:48.419071              
IV.   DB2 Technical Notes.                                              
 4.  Comparisons of creating DB2ACCT, DB2ACCTP and AUDIT records.       
     All tests read the same 1787MB SMF file, creating 400,755 DB2ACCT  
     observations and 456,617 DB2ACCTP observations, both on tape with  
     no sorting, and all T102S140-T102S145 Audit datasets were created, 
     but only T102S145 had 4 observations.  A tailored KEEP kept only   
     145 variables in DB2ACCT (559 without tailoring) and kept only     
     113 variables in DB2ACCTP (168 without tailoring):                 
         Test    Compress  KEEP Used  CPU Seconds                       
          1          no       yes       133.8                           
          2          no        no       151.4                           
          3         yes       yes       183.4                           
          4         yes        no       198.8                           
     As might be expected, reducing variables and disabling COMPRESS    
     is the cheapest for the CPU resource (but MAXIMUM for DASD space!),
     and enabling COMPRESS and keeping ALL variables is the most costly 
     for CPU, with an increase of 50% over the minimum CPU time.        
 3.  Changes to STATIME and SYNCVAL parameters in DB2 Version 10.       
     In DB2 Version 10, the interval when statistics records are created
     was changed.  The subsystem parameters STATIME and SYNCVAL apply   
     only to IFCID 0105 (T102S105), IFCID 0106 (T102S106), and IFCID    
     0199 (T102S199) records.  All other interval statistics records,   
     IFCID 0001 (DB2STAT0 and DB2STATR), IFCID 0002 (DB2STAT1, DB2STATB,
     and DB2GBPST), IFCID 0202 (DB2STAT2), IFCID 0217 (T1020217), IFCID 
     0225 (DB2ST225) and IFCID 0230 (DB2GBPAT) are no longer controlled 
     by STATIME and SYNCVAL, and the corresponding trace records are    
     written at fixed, one-minute intervals.                            
 2.  APAR PM54177 reports that QWACBSC and QWACESC in DB2ACCT dataset   
     for Distributed Transactions can contain zero.  APAR text is:      
       DB2 accounting logic expects to be called to start an accounting 
       interval to record transaction begin times. Some distributed     
       client behavior can result in accounting begin being skipped. The
       case is when SET statements are followed by a COMMIT without     
       additional SQL. Without the begin accounting call, an accounting 
       IFCID3 record will be written with zero begin times upon COMMIT. 
       PROBLEM CONCLUSION:                                              
       Accounting has been changed to reject accounting intervals where 
       no begin times have been collected. This will eliminate the      
       IFCID3 records with QWACBSC and QWACBJST equal to zero.          
 1.  APAR PM51653 reports IFCID 239 Class 7 Package Accounting Time is  
     incorrect when fetching from a stored procedure result set; the    
     error is in QPACTJST or QPACCLS7_ZIIP.                             
V.   IMS Technical Notes.                                               
 3.  APAR PM27227 reports IMS V12 can fill SMF with type 79 records.    
 2.  APAR PM36273 added zAAP/zIIP CPU Usage time in TYPE56FA and TYPE07 
     log records; the APAR was supported in MXG 29.29 Change 29.307,    
     (DLRZAAP in 07s, TPEZAAP in 56FA).                                 
 1.  APAR PM33465 reports STRTTIME is incorrect in IMS 56FA log record  
     for IFP Transactions and PWFI and WFI Full Function Transactions.  
VI.  SAS Technical Notes.                                               
 7.  Changing the length of MXG variables.                              
     There are many long-length character variables created by MXG,     
     primarily due to open systems text fields, but you can change      
     the length of any MXG CHARACTER variable created from SMF data by  
     adding a LENGTH statement in your IMACFILE member, or by passing   
     that LENGTH statement with the &MACFILE macro variable:            
       //SYSIN DD *                                                     
        %LET MACFILE=                                                   
          %QUOTE( LENGTH                                                
                  VAR1 VAR2 VAR3                                        
                  $8 ;                                                  
        %INCLUDE SOURCLIB(whatever);                                    
     The IMACFILE exit places that LENGTH statement so it is seen first 
     by the SAS compiler, prior to the MXG default LENGTH statement; for
     character variables, SAS uses the FIRST instance of LENGTH.        
     You can NOT change the LENGTH of a NUMERIC variable in the IMACFILE
     exit nor with &MACFILE, because SAS uses the LAST instance of a    
     LENGTH statement for numeric variables, but you can a LENGTH       
     statement in the EXdddddd exit member for that record to change a  
     numeric variable's length, since that code is seen AFTER the MXG   
     LENGTH statement by the SAS compiler.                              
 6.  SAS WARNING about NLSCOMPATMODE Option.                            
     This z/OS-only SAS Warning is harmless, including SAS V9.3 in 2012:
       TECHNICAL SUPPORT.                                               
     The NLSCOMPATMODE option is set in MXG's CONFIGV9, which is used in
     the MXGSASV9 and MXGSAS92 JCL Procedure Examples, primarily for all
     non-USA sites, as was documented in Change 22.129 (text below).    
     However, it is now the "official" recommendation to NOT use either 
     of those "old" JCL Procedure Examples, but instead, as contained in
     the MXGSAS93 and INSTALL members, to use the new "MXGNAMES"        
        NEW, and documented in Change 27.356, with SAS V9.2 or later:   
        YOUR SITE'S standard SAS JCL Procedure can be used for MXG:     
          // EXEC SAS,CONFIG='MXG.SOURCLIB(CONFIMXG)'                   
        instead of using the MXGSAS92 JCL Procedure example.            
     in part because that new JCL example eliminates the need for the   
     NONLSCOMPATMOD option to be set.  Here is the text of 27.356:      
     Change 27.356, Jan 17, 2010:                                       
      -The standard SAS JCL procedure can now be used for MXG on z/OS.  
       You do not need a separate MXGSASVn JCL procedure; instead, use  
       this JCL example (in member JCLMXG), after you EDIT the DSNAMES  
       of your MXG Source, MXG "USERID" and MXG Formats datasets into   
       your MXGNAMES member in your MXG "USERID" tailoring library:     
         // EXEC SAS,CONFIG='MXG.SOURCLIB(CONFIMXG)'                    
       or you can provide the names in the jobstream, with:             
         // EXEC SAS,CONFIG='MXG.SOURCLIB(CONFIMXG)'                    
         //MXGNAMES DD *                                                
          %LET MXGUSER1=HLQ.MXG.USERID;                                 
          %LET MXGSOURC=HLQ.MXG.SOURCLIB;                               
          %LET MXGFORMT=HLQ.MXG.FORMATS;                                
      -In addition, the VMXGCNFG macro that was designed by Rich        
       allocates the //SOURCLIB with OPEN_ED-1047 encoding; by doing so,
       the setting for NLSCOMPATMODE is moot, and by doing this, all NLS
       sites running with a locale that is non-ENGLISH_UNITEDSTATES will
       never need to worry about NLSCOMPATMODE, so MXG never has to     
       worry about those SAS language encoding issues again.            
     Change 22.129, Jun 15, 2004, which originally set NONLSCOMPATMODE: 
       In SAS V9, the NLSCOMPATMODE option was changed to default to    
       NONLSCOMPATMODE, which doesn't fail if your LOCALE option is     
       ENGLISH or blank, but with a LOCALE=GERMAN_GERMANY or other      
       non-blank and non-ENGLISH value, with the new NONLSCOMPATMODE    
       option, every "@" causes this error at compile time:             
         ERROR: The name 'A7'x49 is not a valid SAS name.  where that   
         'A7'x is a funny looking printed symbol.  (in the VMXGINIT code
         at statement INPUT @49 ....).                                  
       Changing the NONLSCOMPATMODE option back to the V8.2 default of  
       NLSCOMPATMODE eliminated the error, so I have added option       
       NLSCOMPATMODE to the CONFIGV9 member, as it appears to be safer, 
       and I've listed the SAS help note about the option for you to    
       read, below.  This note is was added so MXG 22.06 could be       
       completed, but it may be revised when I know more about these    
       Specifying LOCALE=GERMAN_GERMANY and NONLSCOMPATMODE did not     
       cause a failure using SAS 9.1.2 under Windows/XP.                
       The SAS help documentation for NLSCOMPATMODE:                    
       "NLSCOMPATMODE provides compatibility with previous releases of  
       SAS in order to process data in languages other than English,    
       which is the default language.  Programs that ran in previous    
       releases of SAS will continue to work when NLSCOMPATMODE is set. 
       When NONLSCOMPATMODE is in effect, SAS does not support          
       substitution characters in SAS syntax.  If you run SAS with      
       NONLSCOMPATMODE, you must update existing programs to use        
       national characters instead of substitution characters.  For     
       example, Danish customers who have substituted the '' for the   
       '$' character in existing SAS programs will have to update the   
       SAS syntax to use the '$' ("national character") in their        
       Note:   NLSCOMPATMODE might affect the format of outputs that are
       produced using ODS. If you are using ODS, set the option value to
       There is additional, extensive, documentation of LOCALE and NLS  
       in SAS Technical Note TS-653 at                     
 5.  Copying and backing up SAS data libraries on z/OS.                 
     Disk to disk copy - full library copy of all members:              
     -PROC COPY always works, but IEBGENER uses much less CPU time than 
      SAS.  However, with IEBGENER you lose the audit in the SAS log    
      that shows which datasets and how many observations were copied.  
      And SAS validates that all MXG-created formats do exist in the    
      //LIBRARY DD during the copying.  GENER just copies blocks.       
     -Copying a 185 cylinder PDB, IEBGENER used 2.71 CPU seconds while  
      PROC COPY used 41.99 CPU seconds for the same data library copy.  
      A second test of a single member disk dataset with 100,000 obs in 
      DB2ACCT showed a larger disparity between GENER and PROC COPY     
      where GENER took .5 seconds and PROC COPY 8.7.  It is likely that 
      the time consumed by PROC COPY is a function of the number of     
      members in the library being copied, the number of variables in   
      each member, and the number of OBS in each member.                
     -However, PROC COPY is expensive only when COMPRESS=YES is enabled 
      (it is the MXG default), AND ONLY IF the CLONE default is used,   
      because CLONE compresses again the already compressed data.       
      Instead, specifying PROC COPY NOCLONE for the same PDB took only  
      12.1 seconds, and copying that library to another took only 2.81  
      seconds, not much different than IEBGENER.  This investigation    
      suggests that you should ALWAYS use NOCLONE when you are copying  
      within the same SAS platform; only if you are copying from one    
      platform to another would CLONE perhaps be required.              
     -But neither COPY nor IEBGENER support concatenated data libraries,
      and the output dataset can NOT use DFSMS hardware compression nor 
      striping: either will create unreadable output that causes this   
      error when the SMS compressed/striped dataset is read:            
     -PROC COPY to an SMS compressed dataset will cause a 213-B8 ABEND  
      for every SAS dataset in the library, then followed by error      
        ATTEMPT TO OPEN SAS DATA LIBRARY x FAILED                       
     -DFHSM MIGRATE/BACKUP can also be used to copy SAS data libraries, 
      and the recalled dataset will be readable by SAS.                 
     Disk to tape copy - full library copy of all members:              
     -You must use PROC COPY if the library is to be used by SAS, or you
      can use DFHSM to back up the library on tape, but you can NOT use 
      IEBGENER to copy a disk SAS data library to tape.                 
     -Using IEBGENER to copy a disk SAS data library to tape doesn't    
      fail during writing, but reading the tape copy causes error:      
 4.  SAS Note 45711. Reported for SAS 9.2, an intermittent ABEND or a   
     CPU loop can occur.  Observed with ANALDB2R execution that had     
     produced reports correctly and successfully on z/OS, but then the  
     job went into a CPU loop that required manual cancellation.        
 3.  SAS has opened a defect for LIBNAME using the VOLSER option.  The  
     circumvention is to put single quotes around the VOLSER value, so  
     VOLSER='123456' syntax will resolve correctly.  When the VOLSER    
     value is specified without those quotes, the error message is      
          ERROR: Libname OUTDD is not assigned.                         
          ERROR: Error in the LIBNAME statement.                        
     with no other clue that VOLSER is the culprit.                     
 2.  Use of the new JCL to execute the SAS PROC using MXGNAMES/CONFIMXG 
     generated this true error message                                  
         ERROR: INSUFFICIENT AUTHORIZATION                              
         TO ACCESS SYS3.MXG.V3001.LOCAL.SOURCLIB(VMXGINIT).             
     but that DSNAME was not the culprit; the site's MXGNAMES had       
       %LET MXGUSER1=SYS3.MXG.V3001.LOCAL.SOURCLIB;                     
       %LET MXGUSER2=XYZ.PERSONAL.SAS.SOURCE;                           
       %LET MXGSOURC=SYS3.MXG.V3001.SOURCLIB;                           
       %LET MXGFORMT=SYS3.MXG.V3001.FORMATS;                            
     and it was actually the MXGUSER2= DSNAME for which this user didn't
     have read access.  With concatenated DSNAMEs, SAS (incorrectly?)   
     reports the DSNAME of the FIRST dataset in the concatenation as the
     cause of the error, so if you get this error, just check ALL of the
     DSNAMEs in the concatenation (and with MXG, check both the SOURCLIB
     and SASAUTOS DDs, since SAS also doesn't include the DDNAME in its 
     error message.                                                     
 1.  SAS Version 9.3 REQUIRES SAS HOT FIX E80004, noted in the CHANGES  
     member, but the symptoms were not listed, and it impacts ALL SAS   
     platforms.  The macro compiler fails with messages like these:     
       ERROR: EXPECTING A VARIABLE NAME AFTER %LET.                     
              OR UNDERSCORE.                                            
     See SAS Problem Note SN43828 to install the Hot Fix.               
VI.A.  WPS Technical Notes.                                             
 1. Text                                                                
VII. CICS Technical Notes.                                              
 1. CICS SMF 110 Subtype 1 (CICSTRAN) records are created automatically 
    with OMEGAMON, as that product forces MNPER=ON for you.             
VIII. Windows NT Technical Notes.                                       
 1. Text                                                                
IX.  z/VM Technical Notes.                                              
 1. Text                                                                
X.    Email notes.                                                      
 1. Text                                                                
XI.   Incompatibilities and Installation of MXG vv.yy.                  
 1. Incompatibilities introduced in MXG 30.02 (since MXG 30.01):        
    See CHANGES.                                                        
 2. Installation and re-installation procedures are described in detail 
    in member INSTALL (separate sections for each platform, z/OS, WIN,  
    or *nix), with examples of common Errors/Warnings messages a new MXG
    user might encounter, and in member JCLINSTT for SAS V9.2 or member 
    JCLINSTW for WPS. INSTALL also shows how to read SMF data on PCs/nix
    using the FTP ACCESS METHOD.                                        
XII.  Online Documentation of MXG Software.                             
    MXG Documentation is now described in member DOCUMENT.              
XIIV. Changes Log                                                       
--------------------------Changes Log---------------------------------  
 You MUST read each Change description to determine if a Change will    
 impact your site. All changes have been made in this MXG Library.      
 Member CHANGES always identifies the actual version and release of     
 MXG Software that is contained in that library.                        
 The CHANGES selection on our homepage at            
 is always the most current information on MXG Software status,         
 and is frequently updated.                                             
 Important changes are also posted to the MXG-L ListServer, which is    
 also described by a selection on the homepage.  Please subscribe.      
 The actual code implementation of some changes in MXG SOURCLIB may be  
 different than described in the change text (which might have printed  
 only the critical part of the correction that need be made by users).  
 Scan each source member named in any impacting change for any comments 
 at the beginning of the member for additional documentation, since the 
 documentation of new datasets, variables, validation status, and notes,
 are often found in comments in the source members.                     
Alphabetical list of important changes after MXG VV.RR in MXG VV.RR+1:  
  Member   Change    Description                                        
  See Member CHANGES or CHANGESS in your MXG Source Library, or         
  on the homepage                                          
Inverse chronological list of all Changes:                              
Changes 30.yyy thru 30.001 are contained in member CHANGES.