COPYRIGHT (C) 1984-2014 MERRILL CONSULTANTS DALLAS TEXAS USA

MXG NEWSLETTER FORTY-ONE

****************NEWSLETTER FORTY-ONE************************************
                                                                        
                                                                        
                                                                        
                                                                        
                                                                        
                                                                        
                                                                        
                                                                        
                                                                        
    MXG NEWSLETTER NUMBER FORTY-ONE, September 1, 2002                  
                                                                        
Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE
                                                                        
                         TABLE OF CONTENTS                          Page
                                                                        
I.   MXG Software Version 20.05.                                        
                                                                        
II.   MXG Technical Notes                                               
                                                                        
III.  MVS Technical Notes                                               
                                                                        
24.  MSU, Million Service Units per Hour, will replace MIPS.            
23.  APAR OW56033 for NPM/IP SMF record eliminates the creation of many 
22.  APAR OW56001 will provide four zappable fields to customize SMF    
21.  New RMF FICON data is not written to SMF by default; IBM default of
20.  TYPE42DS Data Set Statistics with no Statistics Section S42DSIOO=0,
19.  APAR OW55586 officially documents that swap data sets are no longer
18.  APAR OW52583 corrects blank value in SMF30PFL when a step is       
17.  APAR OW55564 corrects zero value in SMF70SER (CPUSERnn) in first   
16.  APAR OW55359 describes how SMF type 42 subtypes 15-19 (VSAM RLS)   
15.  APAR PQ59911 for WebSphere Application Server V4.0.1 for z/OS and  
14.  APAR OW53698 z/OS R1.2, ARCHLVL=2, plus reconfigure storage offline
13.  APAR OW47277 discusses in detail internal corrections for problems 
12.  APAR OW54399 corrects problems in 64-bit mode at R10 and above that
11.  The new "Z2 mode" of JES2/JES3 INCOMPATIBLY changes the JCTJOBID   
10.  "The writing of SMF record 117 is not documented and should have   
 9.  APAR PQ57650 reports that RMF Type 79 subtype 15 (IRLM Long Lock)  
 8.  APAR OW43846 reports incorrect value for SMF15NTU (variable TTRN in
 7.  APAR OW52822 alters how CLOSE macro options are handled for VSAM,  
 6.  Item RTA000016291 responds to a comparison of the 3470 Get requests
 5.  APAR PQ60740 for TCP SMF record (confusingly listed as "TCB SMF",  
 4.  APAR PQ58984 documents performance degradation for WebSphere V4.0.1
 3.  APAR OW54176 for OMVS USS fixes storage shortage in the OMVS ASID  
 2.  RMF Reports from IBM incorrectly report IOSQ when a SysPlex report 
 1.  APAR OW51126 documents that DASD Connect Time for Ficon Connections
                                                                        
IV.   DB2 Technical Notes.                                              
                                                                        
 1.  APAR PQ53472 corrects internal lengths so that data areas for the  
                                                                        
V.    IMS Technical Notes.                                              
                                                                        
VI.   SAS Technical Notes.                                              
                                                                        
16.  SAS Technical Note SN-001705 confirms that SAS Version 8.2 has no  
15.  On MVS, MXG's CONFIGxx options specify MSGCASE, which overrides the
14.  Quick way to go from a SAS database on MVS to an EXCEL spreadsheet 
13.  Support for SAS Version 9.                                         
12.  How many //SORTWKnn DDs are needed for a large sort?  Divide the   
11.  Reading a text file (under ASCII SAS) that contains CTRL+Z (Hex 1A)
10.  SAS HotFIX 82BA77 is still Strongly Recommended to correct errors; 
 9.  An SMFTIME value of 'EE1B897F0102050F'x, created by Computer Ass   
 8.  Required SAS Hot Fix Bundle is 82BX03 for Version 8.2 TS2M0 on MVS.
 7.  A "DOMAIN ERROR" (MVS only thus far) occurs when SAS V8 creates an 
 6.  SAS V8.2 with SAS/SHARE can corrupt updated SAS datasets and/or    
 5.  V8 COMPRESS=YES and SEQENGINE=V8SEQ compresses tape and disk data  
 4.  If character variables that should have lower case values all have 
 3.  SAS note SN-001262 reports a problem under unix that we have also  
 2.  It turns out it IS possible to reassign the SOURCLIB fileref in    
 1.  Under Windows with SAS V8.2, SAS fix 82BA62 corrected this error:  
                                                                        
VII.  CICS Technical Notes.                                             
                                                                        
 2.  A MAJOR change in CICS-DB2 Accounting occurs with DB2 Version 6 or 
 1.  APAR PQ63141/PQ63143 adds new statistics to type 110 data.         
                                                                        
VIII. Windows NT Technical Notes.                                       
                                                                        
IX.   Incompatibilities and Installation of MXG 20.05.                  
         See member CHANGES and member INSTALL.                         
X.    Online Documentation of MXG Software.                             
         See member DOCUMENT.                                           
XI. Changes Log                                                         
     Alphabetical list of important changes                             
     Highlights of Changes  - See Member CHANGES.                       
                                                                        
      COPYRIGHT (C) 2002 MERRILL CONSULTANTS DALLAS TEXAS USA           
                                                                        
I.   MXG Software Version 20.05 is now available.                       
                                                                        
 1. Major enhancements added in MXG 20.05:                              
                                                                        
    See CHANGES.                                                        
                                                                        
II.  MXG Technical Notes                                                
                                                                        
                                                                        
III. MVS Technical Notes.                                               
                                                                        
24.  MSU, Million Service Units per Hour, will replace MIPS.            
                                                                        
    I now believe that the IBM MSU, Million Service Units per hour, will
    replace MIPS, and that the MSU will be the primary metric to express
    CPU hardware capacity and/or workload consumption, whether or not   
    MSU is also used for Software Pricing.  MIPS was a constant provided
    by a consulting company to describe your processor.  MSU is also a  
    constant, but provided by IBM to describe your processor. For either
    constant, that constant and CPU seconds are used to describe and    
    to measure your capacity and your capacity used in MIPS or in MSU.  
                                                                        
    And since one MSU is about 5.8 MIPS, if your management still wants 
    to see capacity in MIPS instead of MSU, you can just multiply the   
    MSU values by 5.8 to report in MSU-based-MIPS.                      
                                                                        
    Dataset PDB.RMFINTRV reports MSU capacity and usage for each z/OS   
    System ("image"); datasets PDB.ASUM70PR and PDB.ASUMCEC provide the 
    MSU statistics for each LPAR and for the hardware ("CPC/CEC").      
                                                                        
    -These are the important MSU-related variables:                     
                                                                        
      CECSUSEC - The IBM-supplied hardware constant raw CPU service per 
                 CPU_SEC value of this CEC/CPC platform.  E.g. 10081 for
                 a 2064-104.  Multiply by 3600 times the number of CPU  
                 engines and divide by a million to get the CPCMSU.     
                 This is the "Software" Service Unit per Second factor  
                 that is constant for all LPARs in a CEC.               
                                                                        
      CPCMSU   - The total capacity of the CEC/CPC in hourly MSU rate.  
                 E.g., the above 2064-104 is a 145 MSU platform.        
                                                                        
      MSUINTRV - a count, and not a rate, is CPUseconds*CECSUSEC/1000000
                 and should not normally be used, since it is not a rate
                 and MSU's in general are rates.  It is used only for   
                 calculations of rates; use only if you must sum counts.
                                                                        
      MSUPERHR - MSUINTRV * 3600 / DURATM  - is the interval count of   
                 MSU (extended to an hourly MSU rate if the interval is 
                 less than an hour).                                    
                                                                        
      MSU4HRAV - MXG 4-hour rolling average MSU per hour from RMF       
                 Interval data.  MXG calculates the value across an IPL,
                 "SPIN"ing the last four hours for tomorrow's input.    
                 Always calculated.                                     
                                                                        
      SMF70LAC - IBM 4-hour rolling average of the MSU rate.  Not       
                 calculated when Hardware Capped.  Reset at IPL.        
                                                                        
      SMF70WLA - The Defined Capacity of the LPAR MSU rate.  Zero if    
                 capacity is not defined.  Based on LPAR share and CPC  
                 capacity if Hardware Cap.                              
                                                                        
                                                                        
    -Al Sherkow's excellent research with IBM has found that:           
                                                                        
      SU_SEC (in TYPE72GO) and LOSU_SEC (in TYPE30s) provides the factor
      for the HARDWARE MSUs.  SU_SEC does vary with the number of       
      logical general purpose engines in the LPAR. On a single machine  
      with LPARs that have different numbers of logical engines you will
      have different SU_SEC for each different LPAR.                    
                                                                        
      CECSUSEC (SMF70CPA) is used (ASUMMIPS) to compute the SOFTWARE MSU
      capacity of the machine, and it is always based on the number of  
      physical engines on the entire machine, not just those assigned to
      an LPAR.  As IRD or VARY change the number of logical GP engines  
      in an LPAR SU_SEC changes also, but SMF70CPA does not.            
                                                                        
      CECSUSEC (SMF70CPA) changes with physical engine changes, such as 
      Upgrades, CBU testing and Capacity on Demand. With CBU testing    
      SU_SEC does not change until some of those new physical engines   
      are VARY'd into the LPARs.                                        
                                                                        
      The WLM measures MSU for its 4-hour rolling average and max values
      based on 10 second samples of "LPAR Effective CPU Time", averaged 
      over a five minute period.                                        
                                                                        
      This value is used internally by WLM when managing (i.e. Soft     
      "capping") to "Defined Capacity", but those 5-minute data values  
      are not written to RMF 70 records.                                
                                                                        
      SMF70LAC, IBM's 4-hr Average Hourly MSU, contains the most recent 
      calculation of the 4-hr average.  It was calculated within the    
      last 5 minutes but represents four hours of data from those 5     
      minute data values.                                               
                                                                        
      The WLCTool uses SMF70LAC when it exists but also supports data   
      from machines running in basic mode, using their existing RMF data
      and reports at the customers SMF interval.                        
                                                                        
      The Sub Capacity Reporting Tool uses SMF70LAC.                    
                                                                        
      The SMF 99 subtype 1 record field SMF99_SLAvgMsu has the current  
      WLM view of the four hour average in 48 service buckets with the 5
      minute interval data.  The buckets are broken up by service       
      accumulated with the partition was capped and while the partition 
      was uncapped.                                                     
                                                                        
    -MXG can never exactly match the IBM 10-second sampled MSU values   
     from WLM 5-minute buckets using RMF interval data, especially for  
     the maximum values, but using 15 minute or hour intervals still    
     provides very accurate MSU measures, as demonstrated below.  The   
     RMFWDM command was issued at 12:43 and is compared to the 15-minute
     RMF interval at 12:30, and with the hour RMF interval starting at  
     12:00:                                                             
                                                                        
                                                  Hourly MSU Rate       
                                             4-hr Average    Maximum    
                                                                        
               RMFWDM snapshot                       41        58       
               IBM SMF70LAC in 12:30 RMFINTRV        42        43       
                                                                        
               MSU4HRAV (RMFINTRV 15-min data)       41.95     44.4     
               MSU4HRAV (RMFINTRV hourly data)       40.28              
               MSUPERHR (RMFINTRV 15-min data)                 55.4     
               MSUPERHR (RMFINTRV hourly data)                 43.8     
               IBM SMF70LAC (one hour RMFINTRV)      43        43       
                                                                        
               5-min max=58, 15-min max=55, hour max=44, LAC max=43     
                                                                        
                 STARTIME MSUINTRV MSUPERHR MSU4HRAV SMF70LAC           
                                                                        
                 08:30:00   11.48    45.93    33.93     31              
                 08:45:00   13.84    55.37    35.88     33              
                 09:00:00   11.08    44.35    37.01     35              
                 09:15:00    8.78    35.14    37.57     36              
                 09:30:00   12.66    50.55    39.07     36              
                 09:45:02   13.16    52.62    40.56     38              
                 10:00:03   10.17    40.77    40.91     40              
                 10:15:01   10.73    42.94    41.57     40              
                 10:30:01   10.88    43.48    42.30     41              
                 10:45:02   10.58    42.35    42.99     41              
                 11:00:02   11.18    44.65    43.66     42              
                 11:15:04   10.93    43.81    44.48     43              
                 11:30:02    9.75    38.98    43.78     43              
                 11:45:02    7.89    31.58    43.89     43              
                 12:00:02    9.55    38.20    43.54     43              
                 12:15:02    9.79    39.20    43.18     43              
                 12:30:01    6.65    26.61    41.95     42              
                    (This system had SMF70WLA=50, CPCMSU=118.92)        
                                                                        
                   This LPAR was the 10th LPAR; PDB.ASUMCEC/PDB.ASUM70PR
                   had these values for 10th LPAR's LPn variables:      
                                                                        
                      STARTIME  LPALAC   LPAMSU   LPAMSUHR   LPAMSU70   
                       12:30       42      6.65      26.62       50     
                                                                        
    -MXG'S MSU calculations use the total LPAR CPU time (LPAR Partition 
     Dispatch CPU time), because that is the MSU the LPAR really        
     consumed, and that is what you should use for (conservative)       
     capacity measurement.  But because the CPU Dispatch time is        
     slightly larger than the CPU Effective, and because IBM samples the
     Effective CPU to calculate SMF70LAC for WLC Software Charging,     
     MXG's MSU4HRAV can be slightly larger than IBM's SMF70LAC (and     
     recall that the value in SMF70LAC is a truncated integer).         
                                                                        
    -Keith Munford has also observed that:                              
      -With Defined Capacity and Hard Capping both enabled:             
       -The value in SMF70LAC (4-hr average) is zero; IBM has APAR      
         OW55509 open internally and LAC should be fixed.  However,     
         MXG's MSU4HRAV variable is always valid.                       
       -The value in SMF70WLA is not the Defined Capacity that you set  
        on the HMC Management Console for that LPAR, but instead        
        SMF70WLA is the MSU rating of the CPC, weighted by the LCPUSHAR 
        for the LPAR:                                                   
         E.g.:   WLA Set Value = 18    CPCMSU = 119                     
               LCPUSHAR = 43 (out of 299) = 14.38%                      
               IBM recorded  SMF70WLA=17  (.1438*119=17.11).            
      -With Defined Capacity not enabled but with Hard Capping enabled, 
       SMF70LAC is still zero, and SMF70WLA is again the CPCMSU rating  
       weighted by its LCPUSHAR:                                        
         E.g.:   WLA Set Value = none  CPCMSU = 153                     
               LCPUSHAR = 85 (out of 400) = 21.25%                      
               IBM recorded SMF70WLA=33 (.2125*153=32.51).              
                                                                        
    -The text of MXG Changes 20.046, 20.043, 19.083, 19.018 and 18.317  
     all had something to say about WLA and MSU; some were revised to be
     accurate when read now, and to be consistent with what is now      
     known.  See also Changes 20.168, 20.169 for associated MSU notes.  
                                                                        
23.  APAR OW56033 for NPM/IP SMF record eliminates the creation of many 
     duplicate observations.  As long as you used MXG to sort the data  
     in NPMIP01 or NPMIP02 datasets into your PDB, those duplicates were
     automatically removed, but this APAR eliminates their creation.    
     16Aug02.                                                           
                                                                        
22.  APAR OW56001 will provide four zappable fields to customize SMF    
     buffer options (minimum size, expansion increment, etc?).  No date 
     set yet for its availability.  15Aug02.                            
     04Oct02: PTFs now exist, and the text of this APAR has extensive   
     documentation of how SMF buffers are allocated and how you can     
     prevent loss of SMF data due to "spikes" in SMF data volume.       
                                                                        
21.  New RMF FICON data is not written to SMF by default; IBM default of
     NOFCD must be changed to FCD in ERBRMFxx member in SYS1.PARMLIB.   
                                                                        
20.  TYPE42DS Data Set Statistics with no Statistics Section S42DSIOO=0,
     have missing values in D42DSIOR thru S42DSMXs are reportedly caused
     by BMC's Mainview Batch Optimizer 2.2.0 (data optimizer component),
     and BMC is working on a fix.  7AUG02.                              
                                                                        
19.  APAR OW55586 officially documents that swap data sets are no longer
     supported, starting with z/OS, and the SMF 75 mapping no longer    
     mention "Swap Data Sets", but only refer to "Page Data Sets".      
     It also corrects errors in TYPE74CF Coupling Facility R744RSST.    
                                                                        
18.  APAR OW52583 corrects blank value in SMF30PFL when a step is       
     skipped via the COND parameter when using SCHENV JCL Parm in WLM.  
                                                                        
17.  APAR OW55564 corrects zero value in SMF70SER (CPUSERnn) in first   
     RMF interval, after OW53929 has been installed.   This would impact
     the PDB.ASUMCEC dataset, since the CECSER is taken from SMF70SER.  
                                                                        
16.  APAR OW55359 describes how SMF type 42 subtypes 15-19 (VSAM RLS)   
     can be accidentally not written.                                   
                                                                        
15.  APAR PQ59911 for WebSphere Application Server V4.0.1 for z/OS and  
     OS/390 is an internal defect fix and new function APAR to provide  
     the complete Java interface, and the Web Container will use this   
     interface to sent web container activity (such as HttpSession and  
     servlet) to the SMF data, in the form of two new subtypes (7,8) to 
     the SMF type 120 record.  An MXG change to VMAC120 will be needed. 
     21Jun2002.                                                         
                                                                        
14.  APAR OW53698 z/OS R1.2, ARCHLVL=2, plus reconfigure storage offline
     command corrupts OUXB fields (which show up in type 30 records in  
     service unit fields (SERVICE,CPU,SRB,MSO) to be billions.  IBM says
     to IPL and set RSU=0,REAL=0 in IEASYSxx to tell z/OS the system has
     no reconfigurable storage, so the function (take storage offline). 
     that causes the corruption will never be invoked.  21Jun2002.      
     My comment: don't reconfigure storage offline.                     
                                                                        
13.  APAR OW47277 discusses in detail internal corrections for problems 
     found during the tests of LPAR CPU Management and License Manager  
     in OS/390 R11. 19Jun2002.                                          
                                                                        
12.  APAR OW54399 corrects problems in 64-bit mode at R10 and above that
     surfaced as lots of auxiliary paging slots in use, periodic high   
     page rates, and high UIC and high AFQ.                             
                                                                        
11.  The new "Z2 mode" of JES2/JES3 INCOMPATIBLY changes the JCTJOBID   
     field, which impacts not only the JESNR and TYPETASK variables in  
     many MXG datasets, but may impact applications, exits, utilities   
     and vendor products, especially message-based automation products, 
     that use or display JOBID, JESNR, or TYPETASK.  The z2 mode of JES 
     was released with z/OS 1.2, but there was no vendor alert from IBM!
     This new mode permits 200,000 jobs and 999,999 job numbers, with   
     current JOBID format JOBnnnnn/TSUnnnnn/STCnnnnn format replaced    
     with Jnnnnnnn/Tnnnnnnn/Snnnnnnn/Onnnnnnn format when z2 mode is    
     enabled. Only 999,999 job numbers can be used; the first digit of  
     the seven-digit JESNR is always a zero.                            
        (The old mode of JES is now called "OS/390 Release 4            
        Compatibility Mode").  Many exposures are documented by IBM in  
        JES2/JES3 Flash 10114, dated November, 2001, at this url:       
                                                                        
 http://www-1.ibm.com/support/techdocs/atsmastr.nsf/PuballNum/Flash10114
                                                                        
     MXG Change 20.101 documents the (VERY MANY) MXG members that have  
     to be modified to fully support the Z2 mode; that Change will be in
     MXG Version 20.03, to be available later this month. 12JUN02.      
                                                                        
     Added 19Aug02:  These new JESNR values can be seen on an OS/390    
     system, if that system is part of a JESplex that has a z/OS 1.2    
     system; jobs read in on the z/OS 1.2 system that are then sent to  
     the OS/390 system will carry thru the original 7-digit JESNR.      
                                                                        
     And Levi, Ray, and Shoup's VPS product's maintenance to support the
     z/OS operating system will also create the 7-digit JESNR, even when
     running under OS/390 R2.10.                                        
                                                                        
                                                                        
10.  "The writing of SMF record 117 is not documented and should have   
     been removed on an earlier release of MQSeries/390.  It was not    
     meant for customer usage."  APAR PW60966.  06Jun02.                
                                                                        
 9.  APAR PQ57650 reports that RMF Type 79 subtype 15 (IRLM Long Lock)  
     has blank DBNAME in field R79FRSNA, when the database is DL/I (but 
     not if the DB is FP). 06Jun02.                                     
                                                                        
 8.  APAR OW43846 reports incorrect value for SMF15NTU (variable TTRN in
     dataset TYPE1415) for striped extended format datasets that go thru
     partial release.  6Jun02.                                          
                                                                        
 7.  APAR OW52822 alters how CLOSE macro options are handled for VSAM,  
     and cannot be installed with OBJECTSTAR, and could impact other    
     applications.  From the APAR text:                                 
     "It is documented in the 'Macro Instructions for Data Sets'        
     publication that the CLOSE macro options should be ignored for VSAM
     ACBs but CLOSE was not ignoring them. Specifically the FREE option 
     of CLOSE and it's corresponding FREE=CLOSE JCL parameter were      
     incorrectly being honored causing the VSAM data set to be          
     prematurely unallocated by CLOSE.  IFG0202L was modified to ignore 
     all CLOSE options for VSAM ACBs.  It should be noted that any      
     application that depended upon the VSAM data set being unallocated 
     by CLOSE will need to be modified prior to this APAR being         
     installed. Otherwise, the application could fail."                 
                                                                        
     Object Star Flash May 27, 2002 :                                   
     "Situation:                                                        
      IBM has released APAR OW52822 for z/OS which can adversely affect 
      the behavior of ObjectStar.  This APAR removes the ability to     
      de-allocate a closed VSAM data set (FREE=CLOSE).  If this APAR is 
      applied, VSAM data sets, including Pagestore data sets, Journals, 
      and the DBDLIB, will be unavailable for processing in offline mode
      if they have been opened by the Data Object Broker.               
     Corrective Action                                                  
      DO NOT apply this APAR until a suitable ObjectStar solution can be
      developed and tested."                                            
                                                                        
     There is no indication in SMF records that FREE=CLOSE was used in  
     any program, for VSAM or non-VSAM.   31May2002.                    
                                                                        
 6.  Item RTA000016291 responds to a comparison of the 3470 Get requests
     in SMF 110 data with the SMF 64 count of 10999 retrieves (while the
     count of deletes, inserts, and updates were identical).  IBM reply:
     "CICS stats record the activity requested by the CICS application, 
     and NOT the number of SIO/EXCPs required to satisfy each request.  
     Unless a VSAM KSDS is using LSR and there are a sufficient number  
     of buffers in the LSR pool to hold the entire sequence set, then it
     is likely 2 SIOs will be required for each GET or GET UPDATE issued
     by an application program.  And if the entire index set is not in  
     memory, then more than 2 SIOs will be required."                   
     See MXG member ANALBLSR and ADOCBLSR to enable BLSR (recommended!).
                                                                        
 5.  APAR PQ60740 for TCP SMF record (confusingly listed as "TCB SMF",  
     because TCP/IP development uses "TCB" for "TCP Control Block"),    
     documents that variable CURRESTA (Current ESTABS) in the Stat      
     record (dataset TYPETCPS) can be negative.  OPEN as of 20May02.    
                                                                        
 4.  APAR PQ58984 documents performance degradation for WebSphere V4.0.1
     for z/OS and OS/390, when SMF server and container interval records
     were turned on.  The APAR text describes the design changes in how 
     WebSphere creates SMF records (available now in PTF UQ66083) that  
     improve the SMF recording performance (by eliminating and reducing 
     many calls and restructuring string objects).  The observed impact 
     of WebSphere SMF records, before the APAR, reported that LoadRunner
     response dropped from 400 per second at .04 seconds response, to   
     130 per second at .16 seconds when pre-APAR SMF was turned on, but 
     no post-APAR statistics were reported.                             
                                                                        
 3.  APAR OW54176 for OMVS USS fixes storage shortage in the OMVS ASID  
     caused by failure to free the DSSB Control Block when an hfs was   
     unmounted. 20May02.                                                
                                                                        
 2.  RMF Reports from IBM incorrectly report IOSQ when a SysPlex report 
     is requested; one-system-report request  (WLMGL(RCPER,SYSNAM(AB))) 
     will properly report the IOS Queue Time.  See APAR OW53514.        
                                                                        
 1.  APAR OW51126 documents that DASD Connect Time for Ficon Connections
     includes both productive connect time, and delays due to multiplex 
     delays in the Ficon architecture, and changes the way WLM measures 
     the I/O delay contribution to Performance Index, by replacing the  
     measured connect time with a fixed 1 millisecond per Ficon I/O     
     request, in the WLM calculation of PI when I/O Priority Management 
     is in effect.                                                      
                                                                        
IV.  DB2 Technical Notes.                                               
                                                                        
 1.  APAR PQ53472 corrects internal lengths so that data areas for the  
     DISPLAY DATABASE CLAIMERS, LOCKS, and USE are valid.               
                                                                        
V.   IMS Technical Notes.                                               
                                                                        
                                                                        
VI.  SAS Technical Notes.                                               
                                                                        
16.  SAS Technical Note SN-001705 confirms that SAS Version 8.2 has no  
     problems with OS/390 thru R2.10, nor with z/OS, nor with the 64-bit
     hardware of z900-z/800s, nor with larger real storage addresses.   
                                                                        
15.  MXG's CONFIGxx options (MVS only) specify MSGCASE and CAPSOUT which
     override the SAS defaults of NOMSGCASE and NOCAPSOUT, so that all  
     MVS SAS output and messages are upper case: some printers did not  
     support lower case and printed garbage with SAS defaults, and JCL  
     text you create must be upper case.  This is a problem when you    
     need to create lower case text under SAS on MVS (for example, for  
     case-sensitive passwords when you ftp to non-MVS sites); you will  
     need to specify OPTIONS NOMSGCASE NOCAPSOUT; for that program.     
       Also: SAS/GRAPH may refuse to print graphs if you use CAPSOUT.   
                                                                        
     MXG's AUTOEXEC (ASCII execution only) does not change the defaults,
     since SAS under ASCII has always supported mixed case.             
                                                                        
     Mar 6, 2007:  CAPSOUT is ONLY valid on z/OS; OPTIONS CAPSOUT; under
                   ASCII SAS you get ERROR Unrecognized option name.    
                                                                        
14.  Quick way to go from a SAS database on MVS to an EXCEL spreadsheet 
     if you have SAS Connect; there is an upper limit on how many rows  
     EXCEL can handle (but if that is exceeded, there is an option to   
     create a comma separated values or tab delimited or DBASE or ACCESS
     output file that can be imported:                                  
        Start a CONNECT session                                         
        Issue a LIBNAME command                                         
        Go To FILE/EXPORT and follow the onscreen directions.           
     And the inverse function, to read the EXCEL file into a SAS dataset
     is there, under FILE/IMPORT.                                       
                                                                        
13.  Support for SAS Version 9.                                         
                                                                        
     A more extensive technical note on SAS V9 will be written in a     
     later Newsletter article, but initial tests are very encouraging:  
                                                                        
    -MXG has been tested under SAS Version 9 Early Adopter Release on   
     both z/OS and Windows platforms, with no errors, and with no data  
     incompatibilities between V8 and V9.  Data libraries and catalogs  
     built with V8 can be read and written with SAS V9, and libraries   
     and catalogs built with V9 can be read and written with SAS V8.    
                                                                        
     Following paragraph was revised, March 1, 2003:                    
     Although the V9SEQ sequential engine was supposed to have been     
     redesigned as we have wanted, i.e., it was supposed to NOT honor   
     the OPTIONS COMPRESS=YES global option, the V9SEQ engine still does
     compress tape datasets, so SEQENGINE=V6SEQ is still the MXG default
     in CONFIGV8 and CONFIGV9.  We do NOT recommend the use of either   
     the V8SEQ (which has destructive errors) nor the V9SEQ (because it 
     still compresses tape datasets, even in the V9TSM0 Release.        
     Since all "MVS" tape devices have hardware compression, you don't  
     want SAS to also use software compression and CPU time when writing
     to tape.  And if you write a large dataset in sequential format to 
     DASD, so that it can be an extended-format and hardware-compressed 
     file, again, you don't want SAS to also use software compression.  
       But if you ever should need to have SAS software compress data   
       that is written with the sequential engine, you can still use the
       COMPRESS=YES option on your DATA statement, and SAS will honor   
       your request and compress that dataset and write to that device. 
                                                                        
     Very briefly, in MXG 20.04 and 20.05, there was a CONFIGV9 member  
     that did not have a SEQENGINE option, so those two releases did use
     the V9SEQ engine, but in MXG 20.06 (but not documented with a      
     Change), the CONFIGV9 was changed to specify SEQENGINE=V6SEQ.      
                                                                        
    -Noted in testing the Early Adapters Release, to be corrected in    
     SAS V9.1 or later:                                                 
                                                                        
     Almost too obscure to document: on MVS (in CONFIGxx), MXG changes  
     the SAS default option from NOMSGCASE to MSGCASE (so SAS Messages  
     are printed in upper case), but in the V9 Early Adopter release, if
     you enabled its new DLEXCPCOUNT option (displays EXCP counts on the
     MVS log), those counts are corrupted; using  OPTIONS=NOMSGCASE;    
     correctly printed the counts, and this error is fixed in real V9.  
       Note 15Nov2002: Fixed in SAS V9.1 per Usage Note SN-008247.      
                                                                        
     The message "WARNING: Compression was Disabled ...." set a Return  
     Code (a/k/a Condition Code) of four.                               
                                                                        
12.  How many //SORTWKnn DDs are needed for a large sort?  Divide the   
     size of the file to be sorted, in MegaBytes, by 1000, round up to  
     the next integer, and allocate that many 1500 cylinder sort works: 
       A work file of 1500 cylinders will be easier to allocate during  
         peak use of your work pool, to avoid allocation failure reruns.
       Each file of 1500 cylinders holds about 1180 MegaBytes.  Using a 
         divisor of 1000 instead of 1180 and rounding adds 20-25% extra 
         work space for the sort program.                               
                                                                        
11.  Reading a text file (under ASCII SAS) that contains CTRL+Z (Hex 1A)
     character is stopped at that character, because it is treated as an
     end of file character.  In SAS V8.2 and later, a new option exists,
     IGNOREDOSEOF, which will allow these characters to be read.        
                                                                        
10.  SAS HotFIX 82BA77 is still Strongly Recommended to correct errors; 
     a new problem is caused by that fix and reported under SN-007513,  
     but that error ONLY applies to the use of PROC SOURCE, and 7513 has
     a back-out zap if you encounter the 0C1 running PROC SOURCE after  
     you have installed 82BA77.  12Jun02.                               
                                                                        
 9.  An SMFTIME value of 'EE1B897F0102050F'x, created by Computer Ass   
     products that overlay the first byte of time field with 'EE'x or   
     'EF'x, is invalid for SMFSTAMPw informat, but SAS does not error.  
     Instead, SAS treats the time part's first bit as a negative, so the
     time value is several days earlier.  SAS will not correct SMFSTAMP.
       The real source of the problem, of course, is CA - for every case
       in which they overlay the Reader Time Field, they are supposed to
       provide code for your CA guru to install in the appropriate SMF  
       exit (IEFU83/U84/U85) that removes their overlay, so your CA guru
       needs to read the installation notes and do it right.  But if SAS
       had chosen to detect and report the invalid time value, you would
       know you have invalid SMF data from CA, and could get it fixed.  
                                                                        
 8.  Required SAS Hot Fix Bundle is 82BX03 for Version 8.2 TS2M0 on MVS.
     This note in Sept had 82BA77, but was revised Oct, 2002.  The new  
     SAS Hot Fix Bundle 82BX03 is now required for MXG under "MVS".  The
     new 82BX03 bundle includes 82BB15, 82BA77, and 82BA57, so the fixes
     SN-006609,SN-007032,SN-006754,SN-007000,SN-007065, and SN007066    
     are included, but there are new fixes after 82BA77 that correct new
     I/O errors; it is ALWAYS wises to install the current SAS Hot Fix. 
                                                                        
                                                                        
 7.  A "DOMAIN ERROR" (MVS only thus far) occurs when SAS V8 creates an 
     invalid internal value for a floating point data value read with RB
     (floating point) informat.  With RB informat, SAS does not validate
     that the exponent is valid (because of performance concerns), and a
     data value of '0000000000000001'x creates invalid data values with 
     no error message on the SAS log at time of create.  Only later when
     the data are read with PROC MEANS does the "DOMAIN ERROR" message  
     print on the log, stopping the job, with no identification of what 
     variable contained the invalid data.  (Under PC SAS, wrong values  
     like 1E-74 are created, but do not cause the DOMAIN ERROR.)        
                                                                        
     But the ultimate cause of the DOMAIN ERROR is the incorrect use of 
     RB informat, or a mis-alignment in MXG's INPUT logic.  Thus far:   
      Change 20.051, SMF 89, the field should have been INPUT with PIB. 
      Change 20.050, SMF 78, MXG's INPUT statement was mis-aligned.     
      Change 20.083  SMF 79, MXG should have used PIB instead of RB.    
      Change 20.097  SMF 91, SDI/SDO doc RB wrong, fields are PIB.      
                                                                        
 6.  SAS V8.2 with SAS/SHARE can corrupt updated SAS datasets and/or    
     cause DOMAIN ERROR condition.  SAS/SHARE Hot Fix 82SH02 has their  
     downloadable correction.  21Mar02.                                 
                                                                        
 5.  V8 COMPRESS=YES and SEQENGINE=V8SEQ compresses tape and disk data  
     sets, and there is no global option to disable tape compression.   
     You do NOT want to compress tape data, because all tape drives have
     hardware compression, so software compression only wastes CPU time.
     And even tape-format datasets written to disk should not use SAS   
     software compression, since they can be written to extended-format 
     datasets that are hardware compressed on modern disks.             
                                                                        
     Luckily, MXG 19.19 CONFIGV8 Options still sets  SEQENGINE=V6SEQ    
     (early V8 SEQ had errors, not fixed until V8.2) and the V6 tape    
     engine never compressed tape datasets, so MXG 19.19's addition of  
     COMPRESS=YES (accidentally!) only compresses SAS disk data sets.   
                                                                        
     I have opened a dialogue with SAS Technical Support to eliminate   
     compression of tape datasets (or at least default tape compression 
     off, and provide an option, if someone somewhere can actually show 
     that there is an advantage to them to compress tape datasets).     
                                                                        
 4.  If character variables that should have lower case values all have 
     upper case values instead, it is because MXG's CONFIGxx members for
     MVS set the SAS option CAPSOUT, which converts all lower case to   
     upper case.  Specify  OPTIONS NOCAPSOUT; if you want both cases.   
                                                                        
 3.  SAS note SN-001262 reports a problem under unix that we have also  
     caused on MVS:  if you have //USER DD or if you have a directory   
     named "user" off of the sas root, the USER environmental variable  
     is not ignored in V8 like it was in V6, and data sets are sent to  
     the USER libref instead of WORK, but subsequent reference expects  
     it in WORK, so it is not found!  Don't use //USER or don't have a  
     directory named user, or you can add  -user  work   to your config 
     file to circumvent this problem.                                   
                                                                        
 2.  It turns out it IS possible to reassign the SOURCLIB fileref in    
     your MXG jobs, although it is not clear that you would want to, but
     an MXG site that successfully had reassigned SOURCLIB in their PDB 
     job years ago found that their statements FILENAME SOURCLIB CLEAR; 
     with "FILE IS ALREADY OPEN" when testing MXG 19.19.  After much    
     research, a call to SAS Institute Technical Support revealed that  
     this has been a documented limitation since SAS Version 6 in their 
     Technical Note V6-4731: you cannot clear an AUTOCALLed LIBREF.  I  
     was ready to accept this, and the site redesigned without the need,
     but a complete description from SAS developers of the limitation:  
        Once the autocall libraries have been searched, filerefs remain 
        assigned until both SASAUTOS= option is changed AND there is a  
        subsequent request for an autocall macro.  If it is recognized  
        that the new SASAUTOS= option is different, then the filerefs   
        associated with the previous SASAUTOS are cleared, and the new  
        filerefs are assigned and are the new autocall list.            
     showed a circumvention was available, if this were ever really     
     needed.   You can reassign SOURCLIB if you first change the current
     SASAUTOS= option, then autocall a macro from the new SASAUTOS, so  
     that then you can clear the SOURCLIB fileref, and then can reassign
     SOURCLIB to the new source libraries (for %INCLUDEs), and reset the
     SASAUTOS= option to resolve %macros from the reassigned SOURCLIB.  
                                                                        
     Here is an example of what you would need to do.  The "MDUMPEBC"   
     %MACRO exists only in member/file MDUMPEBC in the MYSTUFF fileref: 
                                                                        
         // EXEC MXGSASV8                                               
            FILENAME MYSTUFF 'D:\MXG\MYSTUFF';                          
            OPTIONS SASAUTOS=MYSTUFF;                                   
            %MDUMPEBC(DUMPIN=SMF,FIRST=1,LAST=1);                       
            RUN;                                                        
            FILENAME SOURCLIB CLEAR;RUN;                                
            FILENAME SOURCLIB ('D:\MXG\USERID' 'D:\MXG\SOURCLIB') ;     
            RUN;                                                        
            OPTIONS SASAUTOS=(SOURCLIB SASAUTOS);                       
            RUN;                                                        
            %INCLUDE SOURCLIB(TYPE0);RUN;                               
                                                                        
                                                                        
 1.  Under Windows with SAS V8.2, SAS fix 82BA62 corrected this error:  
     FATAL ERROR: WRCODE=80000805, MODULE='wtdelet': Unexpected return  
     from vtswtch().                                                    
                                                                        
                                                                        
                                                                        
VII. CICS Technical Notes.                                              
                                                                        
 2.  A MAJOR change in CICS-DB2 Accounting occurs with DB2 Version 6 or 
     later when called from CICS Version 2.2 or later, i.e., OTE.       
                                                                        
     The change is documented in CICS DB2 Guide for CICS/TS for z/OS    
     Version 2.2, Section 9.11.4, titled 'Calculating CICS and DB2      
     Transaction Processor Times for DB2 Version 6 or later'.           
                                                                        
    -Key points:                                                        
                                                                        
     This is the new Open Transaction Environment, OTE.                 
                                                                        
     CICS must be at V2.2 and DB2 must be at V6 for this to happen.     
                                                                        
     With DB2 V6, DB2 CPU time is now recorded in SMF 110s in CICSTRAN! 
                                                                        
     Do NOT add DB2ACCT DB2TCBTM to the CICSTRAN CPUTM with OTE!        
                                                                        
     Some CICS CPU time is now also recorded in the DB2TCBTM in DB2ACCT.
                                                                        
     It is only the SMF 110 subtype 1 CICS transaction data (CICSTRAN)  
     and the DB2 SMF 101 (DB2ACCT) CPU times that are changed.  With or 
     without OTE, when CICS calls DB2, the DB2 CPU time continues to be 
     captured in the CICS type SMF 30 records (for the calling address  
     space), and that DB2 CPU time is also captured in the CICS RMF 72  
     Service Class or Performance Group data, and it is also captured in
     the SMF 110 subtype 2 CICS statistics data (CICDS or PDB.CICINTRV).
                                                                        
     This is the new OTE Open Transaction Environment architecture, and 
     the accounting change applies to both THREADSAFE and non-THREADSAFE
     transactions.                                                      
                                                                        
     For transactions that are declared as THREADSAFE, OTE can reduce   
     the real CPU time significantly (especially for transactions that  
     make many DB2 calls).  However, the capture of DB2 time in CICSTRAN
     and CICS in DB2 is a result of the OTE architecture and thus it    
     occurs whether the transaction is threadsafe or not.               
       So expect CICS CPUTM to be less for THREADSAFE transactions.     
                                                                        
     Thread create and thread terminate CPU time is now captured in the 
     CICSTRAN and DB2ACCT records for the transaction that created or   
     terminated the thread; previously this was uncaptured in both.     
                                                                        
    -IBM's note (mildly edited) states:                                 
                                                                        
     "When CICS is connected to DB2 Version 6 or later, the CICS DB2    
     attachment facility uses CICS-managed open TCBs rather than CICS   
     subtask TCBs.  This means that the CICS monitoring facility can    
     measure activity that was previously only reported in the DB2 SMF  
     101 accounting record, such as processor time consumed in DB2 (the 
     Class 1 and Class 2 CPU time).  For example, the L8 open TCB CPU   
     time captured by CICS does include all DB2 Class 1 CPU time.       
                                                                        
     When CICS is connected to DB2 V6 or later, do not add together the 
     CPU time from the CICS (SMF 110-1) and the DB2 accounting (SMF 101)
     records when calculating the total CPU time for a single           
     transaction, because the DB2 CPU time would then be included twice.
                                                                        
     The total CPU time for a single CICS transaction is simply the CPU 
     time from the CICS record, performance class, data field 008, field
     name USRCPUT (MXG variable TASCPUTM).  This field includes all the 
     TCB CPU time used by the transaction when it was running on any TCB
     managed by the CICS dispatcher, including L8 TCBs, the QR TCB, and 
     TCBs in any other modes."                                          
                                                                        
    -My additional comments:                                            
                                                                        
     All CICS transactions connected to DB2 V6 do exploit the OTE (open 
     transaction environment), which was not clear from that IBM note.  
                                                                        
     While all MXG notes telling you to use ASUMUOW program to combine  
     CICSTRAN and DB2ACCT data to create and then use PDB.ASUMUOW to get
     the total CPU time for account for CICS+DB2 are now wrong with OTE,
     ASUMUOW does not add the two CPU times together; (luckily?) they   
     are kept in two separate variables, so you must check to see if you
     were using their sum for you CICS billing and capacity measurement.
                                                                        
     Since the total CICS+DB2 billable CPU time is now captured in CPUTM
     in CICSTRAN, you may not need to create PDB.ASUMUOW for your CICS  
     and DB2 chargeback and capacity measurement.  However, ASUMUOW is  
     still valuable for its other DB2 metrics.  And even without DB2,   
     ASUMUOW combines all of the TOR, AOR, FOR, etc., MRO transactions  
     from CICSTRAN into one ASUMUOW observation for each UOW (and with  
     the real TRANNAME from the AOR and the real LUNAME from the TOR!), 
     and lots fewer observations for billing and capacity measurement.  
                                                                        
     IBM's note is correct that USRCPUT/TASCPUTM does contain all of the
     CICS and DB2 TCB CPU time for the combined activity, but that isn't
     the total CPU time that is captured in CICSTRAN.  Instead, the MXG 
     variable CPUTM in CICSTRAN is the sum of TASCPUTM + RLSCPUTM and is
     the correct total CPU time to use for billing and capacity,        
     because the RLSCPUTM (field 175, RLSCPUT) is SRB CPU time that is  
     not included in TASCPUTM.  (Fortunately, RLSCPUTM is rarely large, 
     so if you've been using TASCPUTM instead of CPUTM, your numbers may
     be okay, but variable CPUTM in all MXG datasets is the one variable
     to use for the total unoverlapped captured CPU time!)              
                                                                        
     IBM's note also states that the CPU time captured in the SMF 110   
     will be larger with DB2 V6+:                                       
       The CICS L8 CPU time also includes the cost of creating a DB2    
       thread.  With DB2 V5 or earlier, this CPU time was not captured  
       in either CICSTRAN nor in DB2ACCT.  With DB2 V6 or later, if a   
       transaction causes a DB2 thread to be created, the thread create 
       CPU time is charged to the creating transaction, and, if at the  
       end of a CICS transaction, the thread is terminated (because it  
       is unprotected and no other task is waiting to us it), that      
       thread terminate CPU time is charged to that transaction."       
                                                                        
     Finally, the Class 1 CPU time in DB2ACCT (DB2CPUTM) is no longer   
     just due to DB2; a significant amount of CICS application code is  
     now included in that CPU time in the SMF 101 record, and there is  
     no way to measure how much Class 1 was DB2 and how much was CICS.  
                                                                        
     My thanks to Tony Steward and Nick Jealous who alerted me to the   
     change, and to IBM CICS gurus Chris Baker and John Tilling from    
     Hursley, whose very timely SHARE 99 papers and answers were used to
     write this note.  20AUG02, revised and reordered 27AUG02.          
                                                                        
    Added 01Sep02:                                                      
    -An excellent IBM publication, Redpaper REDP0162, "DB2 for z/OS and 
     OS/390 Version 7 Selected Performance Topics", February 19, 2002,  
     easily found at www.ibm.com/redpaper, provides additional useful   
     information on CICS and DB2 Accounting changes:                    
                                                                        
       -The H8, J8, and L8 Open TCBs are documented:                    
        H8 - TCBs allocated by hot-pool HPJ-compiled Java Programs      
        J8 - TCBs allocated for the execution of a JVM Program (Java    
                  programs that requires a JVM)                         
        L8 - TCBs allocated by non-Java program accessing a resource    
                  manager through a task-related user exit enabled with 
                  OPENAPI option.  Used by the CICS/DB2 attachment.     
                                                                        
       -Figure 5-13 in the Redpaper is an excellent schematic of where  
        CICS and DB2 CPU times are currently captured, and a revised    
        Figure 5-13 for the OTE environment was presented by IBM at the 
        SHARE 99 meeting:                                               
                                                                        
                        Figure 5-13  CPU Accounting Before OTE          
                                                                        
               ----CICS ADDRESS SPACE-----  --DB2 ADDRESS SPACE--       
                                                                        
              . CICS QR     .  CICS       ..          DB2        .      
              . MAIN TCB    .  ATTACH TCB ..          TCB        .      
              .             .             ..                     .      
              .             .             ..                     .      
              . 1 __________________      ..                     .      
              .             .      2 ___________________         .      
              .             .       ____________________ 3       .      
              .   __________________ 4    ..                     .      
              . 5 __________________      ..                     .      
              .             .      6 ___________________         .      
              .             .       ____________________ 7       .      
              .   __________________ 8    ..                     .      
              . 9           .             ..                     .      
               ---------------------------  ---------------------       
                                                                        
                CICS CMF CPU = 1+5+9                ==> TASCPUTM        
                DB2 Class-1 CPU = 2+3+4+6+7+8       ==> DB2TCBTM        
                DB2 Class-2 CPU = 3+7                                   
                                                                        
                                                                        
                                                                        
                  Revised Figure 5-13  CPU Accounting with OTE          
                                                                        
               ----CICS ADDRESS SPACE-----  --DB2 ADDRESS SPACE--       
                                                                        
              . CICS QR     .  CICS (L8)  ..          DB2        .      
              . MAIN TCB    .  OPEN TCB   ..          TCB        .      
              .             .             ..                     .      
              .             .             ..                     .      
              . 1 __________________      ..                     .      
              .             .      2 ___________________         .      
              .             .       ____________________ 3       .      
              .             .   ____ 4      ..                   .      
              .             . 5 ____        ..                   .      
              .             .      6 ___________________         .      
              .             .       ____________________ 7       .      
              .   __________________ 8      ..                   .      
              . 9           .             ..                     .      
              .             .             ..                     .      
               ---------------------------  ---------------------       
                                                                        
                CICS CMF CPU = 1+2+3+4+5+6+7+8+9   ==> TASCPUTM has more
                DB2 Class-1 CPU = 2+3+4+5+6+7+8    ==> DB2TCBTM has CIC 
                DB2 Class-2 CPU = 3+7                                   
                                                                        
                                                                        
        The CPU "5" moves from under the QR TCB to the L8 Attach TCB;   
          i.e., QR TCB may be less, L8 TCB may be more.                 
        The DB2 Class-1 CPU changes to 2+3+4+5+6+7+8 (was 2+3+4+6+7+8); 
          i.e., CPU time for CICS functions ("5") is now recorded in the
                DB2 SMF 101, in dataset DB2ACCT, in variable DB2TCBTM.  
           ==>  DB2 101's didn't record CICS CPU time before OTE.       
        The DB2 Class-2 CPU is unchanged, 3+7.                          
        The CICS TASCPUTM is now 1+2+3+4+5+6+7+8+9 (was 1+5+9);         
          i.e., DB2 CPU time ("2","3","4","6","7","8") is now included  
                in CICS SMF 110 CICSTRAN dataset, in variable TASCPUTM. 
           ==>  CICS 110's didn't record DB2 CPU time in the transaction
                records before OTE.                                     
                                                                        
        The SHARE paper is in the SHARE San Francisco Proceedings,      
        Session 1042, Tuesday, August 20th, 2002.                       
                                                                        
                                                                        
 1.  APAR PQ63141/PQ63143 adds new statistics to type 110 data; IBM has 
     finally made the documentation of those changes available in Oct,  
     2002, and Change 20.225 added support and documents the Studs that 
     were changed.                                                      
                                                                        
                                                                        
VIII. Windows NT Technical Notes.                                       
                                                                        
IX.   Incompatibilities and Installation of MXG 20.05.                  
                                                                        
 1. Incompatibilities introduced in MXG 20.05 (since MXG 19.19):        
    See CHANGES.                                                        
                                                                        
 2. Installation and re-installation procedures are described in detail 
    in member INSTALL (which also lists common Error/Warning messages a 
    new user might encounter), and sample JCL is in member JCLINSTL.    
                                                                        
                                                                        
X.    Online Documentation of MXG Software.                             
                                                                        
    MXG Documentation is now described in member DOCUMENT.              
                                                                        
                                                                        
XI.   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 http://www.MXG.com            
 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 19.19 now in MXG 20.xx:
                                                                        
  Dataset/                                                              
  Member   Change    Description                                        
                                                                        
  See Member CHANGES or CHANGESS in your MXG Source Library, or         
  on the homepage www.mxg.com.                                          
                                                                        
Inverse chronological list of all Changes:                              
                                                                        
Changes 20.xxx thru 20.001 are contained in member CHANGES.