***********************NEWSLETTER FIFTY-FOUR****************************
          MXG NEWSLETTER NUMBER FIFTY-FOUR, AUG 11, 2009.               
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 2009 Annual Version MXG 26.26 was dated Feb 12, 2009.           
    All sites were mailed a letter with the ftp download instructions.  
    The availability announcement was posted to both MXG-L and ITSV-L.  
    You can always request the current version using the form at                               
 1. The current version is MXG 27.08, dated Oct  1, 2009.               
    See CHANGES member of MXG Source, or    
II.  MXG Technical Notes                                                
 1.  DB2 CPU Cost using MACDB2H Header Exit vs _EDB2ACC Dataset Exit.   
     An SMF file of 58GB of 35 Million SMF records, 17 Million DB2 101  
     Subtype 0 (DB2ACCT) was processed using the MACDB2H "Header Exit"  
     or using the _EDB2ACC "Dataset Exit" to select/output 36998 obs,   
     with and without using the MACFILE "SMF Header Exit" to skip the   
     other SMF records in the file.  The INPUT program was TYPEDB2, with
     _NDB2 nulling out the OUTPUT of all but DB2ACCT; however, the _NDB2
     only nulls the OUTPUT of those other datasets - the DB2 records are
     still fully decoded to the point of the OUTPUT.  The _EDB2ACC exit 
     selected which observations were to be output to DB2ACCT, whereas  
     the MACDB2H code threw away the unwanted records as soon as the DB2
     header was INPUT, so it eliminated all of the decoding code for the
     unwanted records.  Only 11 variables were KEPT in DB2ACCT.         
        Records Read           Exit Used  CPU Time mm:ss   DB2ACCT obs  
         ALL 35MM Records      _EDB2ACC       23:32         36998       
         17MM ID 101 ST 0        None         14:33         17MM        
         17MM ID 101 ST 0      _EDB2ACC       13:59         36998       
         17MM ID 101 ST 0       MACDB2H        6:38         36998       
     Skipping half the records in the MACFILE exit dropped the CPU time 
     from 23 minutes to 14 minutes, but that run output all 17 MM obs.  
     Using the _EDB2ACC reduced that time by 34 seconds, showing that   
     the cost to write 17MM vs 36000 (short) observations is cheap.     
     Then, using MACDB2H to eliminate the decoding dropped CPU time to  
     only 6 minutes.                                                    
     The MACDB2H exit was used to "look ahead" and INPUT the QMDA fields
     that were used in the selection. (Note that SUBTYPE had to be INPUT
     in the MACFILE exit because SMF 101 records do NOT have the subtype
     bit enabled; that has been corrected in VMACSMF in MXG 27.03 which 
     inputs the SUBTYPE for the 101, 110, 115, and 116, in spite of the 
     absence of the bit that says the subtype field is valid.)          
          %LET MACFILE=                                                 
               %QUOTE ( IF ID=101 ;                                     
                        INPUT @19+OFFSMF SUBTYPE &PIB.1. @;             
                        IF SUBTYPE=0;                                   
                      )    ;                                            
            %LET MACDB2H=                                               
               %QUOTE (   IF OFFQMDA GT 0 AND NRQMDA GT 0;              
                          INPUT @OFFTEST+41  TESTCNAM $EBCDIC8.         
                                             TESTCTYP $EBCDIC8.         
                          IF TESTCNAM='BATCH' OR TESTCTYP='BATCH';      
          %LET MACKEEP=                                                 
              %QUOTE(  _NDB2                                            
                       MACRO _SDB2                 %                    
                       MACRO _WDB2ACC  PDB.DB2ACCT %                    
                                     QB1CGET QB2CGET QB3CGET QB4CGET    
                                     QB1CRIO QB2CRIO QB3CRIO QB4CRIO %  
           %INCLUDE SOURCLIB(TYPEDB2);                                  
III. MVS, a/k/a z/OS, Technical Notes.                                  
15. APAR OA27752 corrects possible low counting of SMF 30 EXCPs in the  
    DD Segments; IBM field SMF30BLK in the DD segments is EXCPTODD and  
    all of the per-device EXCP counts (EXCP3380 etc.) in MXG TYPE30xx   
    Since migration to z/OS R7 from R4, customer noticed the DD level   
    EXCP count (SMF record type 30 SMF30BLK or type 15 SMFEXCP) is      
    slightly less than it should be.  For example, when a program does  
    10,000 blocks BSAM WRITE, SMF30BLK /SMFEXCP shows (1st) 9,795 (2nd) 
    9,801 (3rd) 9,831 (4th) 9,838 ..  The count varies each time and    
    2-3% less than 10,000.  This,typically, occurs on PSE (extended     
    format) with multiple extents.  The cause seems to be the fix of    
    OA05045 (FIN) for IEASMFEX.  With this fix code, IEASMFEX sometimes 
    returns RC4 to SMFIOCNT macro issuer when local/CML lock is not     
    available and so it does not update DD level EXCP count. But it     
    looks nobody cares about this RC04 from IEASMFEX.                   
    For PSE case, SMFIOCNT macro is issued from ICYDIE.                 
    The SMF30BLK field of the SMF type 30 record reports the block I/O  
    counts at the DD level. The value in this field may be slightly low 
    at releases above z/OS 1.6.  Lower values in this field can be      
    attributed to lock contention for updating the TCT I/O Table        
    (TCTIOT) control block, where the interim count value for this field
    is maintained. Serialization for updating the TCTIOT was introduced 
    at z/OS 1.7 causing some attempts to increment the count in the     
    TCTIOT to be rejected.                                              
    PROBLEM CONCLUSION:                                                 
    Internal SMF services are updated to use a different serialization  
    mechanism to update the TCTIOT.  Although this solution will not    
    completely eliminate the possibility that a TCTIOT update can be    
    rejected, resulting in lower DD level block I/O counts, it will     
    reduce the possibility of this.                                     
14. APAR OA29803 corrects JES2 SMF 26 variable SMF26WCL when the Service
    Class was changed; it has the same value as SMF26WOC, the initial   
    WLM Service Class, without this APAR.  Jul 20, 2009.                
13. APAR OA27563 corrects errors in SMF ID=42 ST=21,24 and 25 records:  
     -SMF 42 subtype 25 contains an incorrect triplet count.            
      Subtype 25 contains x'0003' at offset 18 for the number of        
      triplets present, but there are actually 4 triplets.              
     -SMF 42 subtype 21 and 24 userID token not correctly formatted.    
    And now, after Change 27.155 circumvented the mislocated ICHRUTKN,  
    a new APAR OA29737 adds these notes of the fixes in the original    
    OA27563 APAR, with no new PTF:                                      
     -Record has truncation - Solution: Apply existing APAR OA27563.    
      Correct start location is skewed by +2 bytes.                     
     -SMF42 ST24 and ST21 records are incorrectly created with a 2      
      byte field ( SMF42P#A or SMF42LNA ) for Alias Names section       
      when there are no alias names. Jul 13, 2009.                      
12. From the text of APAR OA26104 New Function: Work Dependent Enclaves:
    "For SQL statements that are eligible for parallel query execution, 
    DB2 creates additional independent enclaves.  These enclaves are    
    created under subsystem DB2 (which the DBM1 space is connected to)  
    and are classified according to the classification rules for        
    subsystem DB2. In order for these enclaves to be classified         
    correctly, the classification rules for subsystem DB2 must be       
    updated to replicate existing classification rules for every        
    subsystem that may cause a stored procedure to run that exploits CPU
    parallelism.  Furthermore, these additional independent enclaves are
    regarded as new transactions."                                      
    Updates to                                                          
      MVS Programming: Workload Management Services                     
      SA22-7619-14 / SA22-7619-16 / SA22-7619-17                        
      Section "Enclave Resource Accounting":                            
      The accounting for resources consumed by an enclave depends on    
      whether it is an independent, work-dependent, dependent, or a     
      foreign enclave. (...)                                            
      For an independent enclave and work-dependent enclaves, CPU       
      service is included in the SMF 30 record of the owning address    
      space, and in the SMF 72 record for the enclave service class or  
      performance group period. MSO service is not calculated for either
      kind of enclave.                                                  
      For dependent, work-dependent, and independent enclaves, IOC      
      service is included in the SMF 30 and 72 records associated with  
      the address space where the enclave work is executing. SRB service
      for enclaves is always zero.(...)                                 
      Table "Enclave Characteristics and Resource Accounting"           
        ** NOTE: if a cell is omitted here, it's content hasn't         
              changed  **                                               
        Dispatchable unit type:                                         
          Work-dependent enclave: SRBs and/or tasks                     
        New transaction:                                                
          Work-dependent enclave: no                                    
          Dependent enclave:                                            
            Depends on the TYPE parameter passed to IWM4ECRE:           
            If TYPE=DEPENDENT, the home a.s. at the time the            
            service was issued.                                         
            If TYPE=WORKDEPENDENT, the creating (dependent)             
            enclave's home a.s.                                         
            If TYPE=MONENV, the a.s. associated with the                
             monitoring environment - see note 1                        
          Work-dependent enclave:                                       
            owner a.s. of the creating independent enclave              
            a.s. where enclave work is dispatched                       
        Service class/report class:                                     
          Work-dependent enclave:                                       
            same as owning independent enclave's                        
        CPU time:                                                       
          Independent enclave:                                          
            owner's SMF30CPT - MXG CPUTCBTM (total)                     
            owner's SMF30ENC - MXG CPUENCTM (independent and            
                                             work-dependent only)       
          Work-dependent enclave:                                       
            owner's SMF30CPT - MXG CPUTCBTM (total)                     
            owner's SMF30ENC - MXG CPUENCTM (independent and            
                                             work-dependent only)       
        CPU service by address space:                                   
          Independent enclave:                                          
            owner's SMF30CSU - MXG CPUUNITS (total)                     
            owner's SMF30ESU - MXG ENCLCPSU (independent and            
                                             work-dependent only)       
          Work-dependent enclave:                                       
            owner's SMF30CSU - MXG CPUUNITS (total)                     
            owner's SMF30ESU - MXG ENCLCPSU (independent and            
                                             work-dependent only)       
        CPU service by period:                                          
          Independent enclave:    enclave's R723CCPU - MXG CPUUNITS     
          Dependent enclave:      owner's R723CCPU - MXG CPUUNITS       
          Foreign enclave:        enclave's R723CCPU - MXG CPUUNITS     
          Work-dependent enclave: enclave's R723CCPU - MXG CPUUNITS     
        DASD I/O connect time by a.s. (see note 3)                      
          Independent enclave:    owner's SMF30EIC                      
                                  (independent and work-dependent only) 
          Dependent enclave:      owner's R723CCPU - MXG CPUUNITS       
          Foreign enclave:        enclave's R723CCPU - MXG CPUUNITS     
          Work-dependent enclave:                                       
            owner's SMF30Eic (independent and work-dependent            
        DASD I/O connect time by period (see note 3)                    
          Independent enclave:    enclave's R723CICT                    
          Dependent enclave:      owner's R723CICT                      
          Foreign enclave:        enclave's R723CICT                    
          Work-dependent enclave: enclave's R723CICT                    
        DASD I/O counts by address space:                               
          Independent enclave:    owner's SMF30EIS                      
            (independent and work-dependent only)                       
          Work-dependent enclave: owner's SMF30EIS                      
            (independent and work-dependent only)                       
        DASD I/O counts by period:                                      
          Independent enclave:    enclave's R723CIRC                    
          Dependent enclave:      owner's R723CIRC                      
          Foreign enclave:        enclave's R723CIRC                    
          Work-dependent enclave: enclave's R723CIRC                    
        Page delay samples, with storage mgt. (see note 4)              
          Work-dependent enclave: enclave's R723CSPV - MXG PCTDLSPV     
        Page delay samples, without storage mgt. (see note 4)           
          Work-dependent enclave: enclave's R723CAXM - MXG PCTDLAXM     
        IOC service:                                                    
          Work-dependent enclave:                                       
            server's SMF 30 and 72 records                              
        SRB service:                                                    
          Work-dependent enclave: n/a                                   
        MSO service:                                                    
          Work-dependent enclave: n/a                                   
11. APAR OA29102 (HIPER,PERVASIVE,DATALOSS) for HSM corrects an error   
    in z/OS 1.8 and 1.9 that corrupts Create Date when a VSAM file was  
    RECALLed or RECOVERed; the invalid value 1901.921 is stored, and    
    it is possible VSAM datasets with that create date could have been  
    prematurely deleted.  Among more details in the APAR text is this   
    note with regard to possible DATALOSS:                              
      4) Recover datasets that were prematurely deleted.                
      To determine if any VSAM datasets were deleted, first determine   
      the window that VSAM datasets were susceptible to the problem.    
      Determine the time frame between when PTFs UA46732/UA47067 R180   
      or UA46733/UA47068 R190 were applied and when the fixing ++APAR   
      or PTF was applied.  For this time frame, collect all SMF         
      records type 60 to 65 and HSM FSR records (SMF 241 if using the   
      default value for SETSYS SMF(type)+1).  The SMF data along with   
      the date of when the ptfs were applied will be needed by IBM      
      support to determine what datasets may have been prematurely      
      deleted.  Contact IBM support once you have the all of the        
      above information.                                                
    You might detect any current VSAM datasets with that Invalid Create 
    Date of 1901.921 by reading the EXPORT of your CATALOG with MXG's   
    TYPECTLG program; that invalid value for OWNCREDT should print notes
    on the SAS log; once I see an example of how that is stored in three
    bytes of packed decimal, I will detect that value and format it so  
    you can identify all such VSAM datasets in your catalog.            
10. APAR OA28459 for SMF 42 Subtype 6 removes an exposure to SMSVSAM    
    ABEND 0C4 in IGWMCOLP in SMSVSAM.                                   
 9. APAR PK83021 reports DFH$MOLS fails with ABENDU0103 if the SMF110   
    records are longer than 32754.  The PTF changes the LENGTH in the   
    DFH$MOLS created DFSORT RECORD control statement from the wrong     
    32752 value to the proper maximum of 32756 bytes for an SMF record. 
 8.  Work-dependent Enclave Resource Accounting.                        
     Documentation in "MVS Programming: Workload Management Services",  
     SA22-7619, Chapter 3. Creating and Using Enclaves has been updated 
     with more extensive information, but this summarizes whats where:  
     The accounting for resources consumed by an enclave depends on     
     whether it is an independent, work-dependent, dependent, or a      
     foreign enclave.                                                   
     For an independent enclave and work-dependent enclaves, CPU service
     is included in the SMF 30 record of the owning address space, and  
     in the SMF 72 record for the enclave service class or performance  
     group period. MSO service is not calculated for either kind of     
     For dependent, work-dependent, and independent enclaves, IOC       
     service is included in the SMF 30 and 72 records associated with   
     the address space where the enclave work is executing. SRB service 
     for enclaves is always zero.                                       
 7.  Measuring the amount (length) of a tape volume that has data, is no
     longer possible as discussed in this thread on IBM-Main in June 09:
        Length of tape (in metres) nowadays is bulls*t:                 
        1. Serpentine recording. It's like audio cassettes with A and B 
        side, but modern tapes have multiple dozen of "sides" (72 for   
        TS1130 aka Jaguar3).  Because of that real physical tape length 
        should be multiplied by "number of sides".                      
        2. Blocking. Space (length) occupied "brutto" depends on the    
        block size, both logical and physical.  Physical means modern   
        tape drives do its own reblocking "under the cover".            
        3. Last but not least: COMPRESSION.  While you may find out how 
        much of a tape has data bytes (maybe provided by RMM/CA-1), of  
        course "the number of bytes" has little to do with dataset(s)   
        size, and you cannot predict exactly how well your future data  
        will be compressed.  Of course you can always estimate it using 
        "not less than" operator, but such estimates will be veeeeery   
        inaccurate, unless you record really non-compressible data.     
        This post was then added to the thread:                         
        Actually, that will depend on the TAPEMAP utility. Some (the one
        included with the CA-1/Copycat and CA TLMS/Copycat utilities for
        example) will actually get the physical tape position from the  
        device at the end of each file to give an accurate position map 
        of all files on the tape. But you are correct, based strictly on
        the amount of data written does nothing to determine how much of
        the tape has been used; not since IDRC was introduced.          
 6.  APAR PK84730 is an error in IBM ftp introduced in z/OS 1.10 that   
     showed up when the SAS ftp access method tried to read a data file 
     that was on tape.  There was no ftp error message; the problem only
     surfaced with this SAS message on the log when SMF records were    
     read with MXG under z/OS 1.10:                                     
             NOTE: Invalid data for SMFTIME in line 1 3-10.             
     but the tape was read without that message under z/OS 1.10.        
     However, the APAR text notes that the error could fail with        
         200-Conflicting SITE operands RDw and READTAPEFormat.          
             READTAPEFormat ignored.                                    
     IBM Support has opened that APAR and is working on the PTF, but by 
     modifying the ftp command to have two site commands, this syntax   
     has circumvented the error:                                        
            FILENAME SMF FTP                                            
                USER='username' HOST='where.i.loading.from'             
                RCMD='SITE RDW;SITE READTAPEFORMAT=S'                   
                S370VS LRECL=32760 PASS='password' DEBUG;               
 5.  APAR PK77275 for SMF 120 Subtype 9 corrects a problem with the CPU 
     usage subsection not being generated when enabled via the MODIFY   
 4.  APAR PK83225 for SMF 120.                                          
     SMF data is not returned by the data collector(DC) if SMF type 120 
     subtype 8 (Web container interval) records have not been written by
     the pap server, detected by the CYN1 U83 exit, and recorded into   
     the CYN1 subsystem. In our Web console BE, this message is         
     CYNVE0388E The data is currently unavailable.                      
     This situation exists until Http traffic is received. Those        
     customers using WebSphere as an EJB server without Web container   
     activity are not seeing any data in the SMF Data page.  With this  
     APAR, CAM will be changed so that the DC will return SMF data once 
     SMF 120-3 ( server interval) records are detected.  Web container  
     activity no longer is required for this page to be populated.      
 3.  APAR OA28499 is opened for an issue that caused PTF UA46066 (for   
     APAR OA27699) to be PE'd.  That was a PTF that is recommended if   
     you use logstreams for SMF, but it causes a buffer shortage if you 
     are instead using MANx datasets and you have a high volume of SMF  
     records.  The 'IEE986E SMF HAS USED    25% OF AVAILABLE BUFFER'    
     messages are NOT issued, but you will get RC 28 from SMFWTM.  The  
     APAR OA28499 is open for z/OS 1.10, but the error may apply to     
     lower levels with PTF UA46066 applied.                             
 2.  APAR OA27752 reports incorrect reduction in recorded EXCP counts in
     DD segments in SMF 30 (IBM SMF30BLK, all EXCPxxxx variables in     
     TYPE30 and PDB.STEPS/PDB.JOBS except EXCPTOTL), and in SMF 14/15   
     (IBM SMFEXCP, MXG EXCPCNT in TYPE1415), migrating from z/OS 1.4    
     to 1.7.  No PTF or explanation, so it's not clear if this is ONLY  
     a z/OS 1.7 issue or if it impacts subsequent z/OS releases.  Text  
     here will be updated when a PTF exists for this APAR.  18Feb2009.  
 1.  APAR Identifier OA29582 adds new EMPTYEXCPSEC(SUPPRESS) option in  
     SYS1.PARMLIB to suppress all empty EXCP entries, so the SMF 30     
     records will NOT have DD-level EXCP Segments for SYSOUT, which can 
     significantly reduce the size of SMF 30 records, and APAR OA32914  
     corrects an initial error where that option was not honored for    
     Dynamic Allocations.                                               
     APAR PM17542 enables DB2 V10 to use the S99DASUP FLAGS2 bit to do  
     more than remove EMPTY DD segments: S99DASUP completely removes all
     DD segments for the DB2 address space records.                     
     APAR PM17542 also adds the new parameter for PARMLIB's ALLOCxx     
     SYSTEM MEMDSENQMGMT(ENABLE) for z/OS 1.12 that allows DB2 to manage
     its dataset ENQs in memory.                                        
     many DD segments were suppressed.                                  
     The option prevents the creation of null segments in SMF 30 records
     for SMS Candidate Volumes, and could significantly reduce the size 
     of your step and job termination records, especially if your site  
     has a default of (SYSDA,5) for every allocation!!                  
     The MVS Initialization and Tuning Reference, under the SMFPRMxx    
     parmlib parameter definitions, EMPTYEXCPSEC:                       
       SUPRESS specifies that the system suppress the creation of empty 
       EXCP sections.  Empty sections can be the result of non-dataset  
       allocations, such as DD DUMMY, or for spool file allocations     
       (i.e., SYSIN, SYSOUT JES DDs), or for non-allocated candidate    
       volumes in the SMS storage group.                                
     One MICS site reported a 28% reduction in CPU time with removal of 
     all of their empty EXCP segments.                                  
        New EMPTYEXCPSEC option in PARMLIB is only in z/OS 1.10+.       
        While EMPTYEXCPSEC option is documented in the z/OS 1.9 SMF     
        manual in Section (Execute Channel Program (EXCP)     
        Section) of z/OS MVS System Management Facilities (SMF) Document
        SA22-7630-16, for z/OS 1.9, testing on a z/OS 1.9 system        
        resulted in                                                     
        IEE947I '/* DEFAULT RETRY                 */                    
     IBM has confirmed that the option only exists in z/OS 1.10, where  
     it is listed in the Release Guide as a 1.10 enhancement            
IV.   DB2 Technical Notes.                                              
 1. APAR PK84187 corrects QWSAPSRB "Negative" value, but would be seen  
    in MXG as a very LARGE positive value.  Due to timing conditions,   
    the value for QWSAPSRB_zIIP could be greater than the total SRB time
    for the address space.  This could result in an incorrect value for 
    PROBLEM CONCLUSION: The total SRB time is loaded after the zIIP     
    time.  Thus the total time should exceed the total zIIP time.  This 
    will result in correct values for QWSAPSRB.                         
V.   IMS Technical Notes.                                               
VI.  SAS Technical Notes.                                               
 8.  "ERROR 455-185: Data set was not specified on the DATA statement"  
     is usually caused by an incorrect _VARxxxx token in the DATA       
     DATA statement (e.g., spelling _VAR7072 as _VAR70720 which does    
     not exist, so SAS thinks that's just a variable name), or an       
     override that nulled out the _VARxxxx definition.                  
 7.  NEVER use FLOWOVER; if you MUST circumvent STOPOVER, then you MUST 
     use MISSOVER instead.  As documented in the INSTALL member, if you 
     get an INPUT STATEMENT EXCEEDED RECORD LENGTH error condition, the 
     MXG job will stop at that point because the MXG default option on  
     the INFILE statement is STOPOVER (and the job ends with a USER 999 
     ABEND, because MXG also specifies option ERRORABEND).              
     Once you have sent the full log with the hex dump of the record to, so we can diagnose the cause (usually, due to a   
     new version of the product that created the record read with an old
     version of MXG Software!), you can circumvent the error using:     
       MACRO STOPOVER MISSOVER %                                        
       %INCLUDE SOURCLIB.....                                           
     which will change the MXG STOPOVER default to MISSOVER (without you
     having to EDIT the MXG code that has the "STOPOVER" text).         
     With MISSOVER, the variables MXG is trying to INPUT beyond the end 
     of the record will be set to a missing value, which may have other 
     unintended consequences, but the next logical record in the        
     input file is read.  But with FLOWOVER, the variables beyond the   
     end of this current logical record will be populated from the NEXT 
     logical record, and thus that next record will NEVER be examined   
     by MXG for its record ID, etc.  Using FLOWOVER will GUARANTEE that 
     the next record (or records) will be SKIPPED.                      
 6.  "Why did MXG translate lower case text into upper case?"  Actually,
     it's the SAS system option CAPS/NOCAPS that determines, at INPUT,  
     whether lower case characters are unchanged (NOCAPS), or whether   
     are all translated to uppercase (CAPS), but CAPS/NOCAPS option is  
     NOT used for input from "external files" (i.e. essentially all MXG 
     fields are input from external files), so MXG preserves original   
     Note that NOCAPS only applies to when the Data Set is created; once
     you have created a mixed-case variable, you cannot use OPTIONS CAPS
     to then print it in upper case.                                    
    -Specifically, the SAS help documentation of CAPS states:           
        specifies that SAS translate lowercase characters to uppercase  
        in these types of input:                                        
        -data following CARDS, CARDS4, DATALINES, DATALINES4, and       
         PARMCARDS statements                                           
        -text enclosed in single or double quotation marks              
        -values in VALUE and INVALUE statements in the FORMAT procedure 
        -titles, footnotes, variable labels, and data set labels        
        -constant text in macro definitions                             
        -values of macro variables                                      
        -parameter values passed to macros.                             
        Note: Data read from external files and SAS data sets           
              are NOT translated to uppercase.                          
        specifies that lowercase characters that occur in the types of  
        input that are listed above are not translated to uppercase.    
 5.  Character variables IMPORTed from Excel Spreadsheets with SAS V9.2 
     have very different lengths than when IMPORTed with SAS V9.1.3, but
     V9.2 does warns you that it truncated a character field. With 9.1.3
     all character variables are length $255 (even when the Excel field 
     is longer, and 9.1.3 did NOT warn that a variable was truncated).  
     With V9.2, most character variables have length/format/informat set
     to the actual length of the Excel field.  However, if the length is
     greater than 255, the V9.2 character variable is truncated to $255,
     with this WARNING message to alert you to that truncation:         
       Failed to scan text length or time type for column .
     SAS Note 33257 documents how to change the Windows Registry        
     key "TypeGuessRows" to a zero, which increases the number of Excel 
     rows (that will be read to determine the variable attributes) from 
     the default of 8 to 16384, which causes SAS V9.2 to use the maximum
     field length as the character variable's length, eliminates the    
     truncation, and eliminates the warning message.  May 28, 2009.     
 4.  SAS Problem Note SN-035112 documents HotFix E9BC81, which corrects 
     the error discussed in March, 2009, in the text of Change 27.014,  
     in MXG 27.02, which applied the ATTRIB TRANSCODE to all MXG-built  
     character variables that contain HEX data (i.e., with $HEX format  
     or with an MXG-created FORMAT that maps character hex values).     
     The TRANSCODE=NO attribute is needed on all of these variable so   
     that, if you move that SAS dataset from EBCDIC to ASCII platforms, 
     those HEX-containing character values are NOT translated, since    
     TRANSCOD=YES is the SAS default, and that would corrupt the data.  
     Prior to the HotFix, the TRANSCODE attribute was NOT passed into a 
     dataset that was created by a SAS VIEW, but that is corrected now  
     by the HotFix.                                                     
 3.  Perhaps the FINAL note on MEMSIZE= parameter, for SAS on z/OS.     
     Ever since SAS V9 in 2000, I have STRONGLY recommended that you    
     NEVER have a MEMSIZE= parameter in your CONFIGxx members (MXG's or 
     SAS's CONFIG options.) SAS Technical support has also discouraged  
     the use of MEMSIZE=, as it can ONLY limit the virtual storage to   
     less virtual storage than is actually available to the address     
     space.  but prior to SAS 9.2 it was not enforced.  SAS 8 through   
     SAS 9.1.3 only reset MEMSIZE value if what is set is greater than  
     REGION- MEMLEAVE.  In SAS 9.2, the logic is changes, and SAS now   
     will always reset the MEMSIZE= option to the (REGION-MEMLEAVE)     
     value. Note that this ONLY applies to SAS on z/OS platforms.       
     MEMSIZE can still needed on some unix and windows platforms.       
 2.  SAS V9.2 on z/OS requires about 20MB more virtual storage for the  
     same job than SAS V9.1.3 required.  For example, an enhanced       
     BUILDPDB with additional SMF records that ran in 72MB with 9.1.3   
     required 92MB when executed with SAS V9.2 Phase 1:                 
                  Data   Program   Total                                
         9.1.3    73728   3308     77036   KB, SAS Total Memory         
                  EXT    SYS                                            
                  73728  12344     86072   KB, IBM IEF374I, last two    
         9.2      92934  17426    109360   KB, Total Memory             
                  94132  12276    106408   KB, IBM IEF374I, last two    
     Note that it is the "Data" or IEF374I "EXT" value that is limited  
     by the REGION size (JOB/STEP); the "Program" or (second) SYS value 
     is the area below the 16MB line.                                   
     So there was right at 20MB virtual more needed by 9.2, but no      
     significant difference between the IEF374 and Total Memory.        
    -z/OS 1.12 message IEF032I/33I replaced IEF374I/276I.               
 1.  A problem with SAS Connect Logon Scripts not working when z/OS was 
     upgraded to z/OS 1.10, in which the telnet TSO logon does not      
     a ready prompt, was due to an IBM error which is corrected by IBM  
     APAR OA26966 and PTF UA44635.                                      
VI.A.  WPS Technical Notes.                                             
 1.  X                                                                  
VII. CICS Technical Notes.                                              
 1.  X                                                                  
VIII. Windows NT Technical Notes.                                       
IX.  z/VM Technical Notes.                                              
X.    Email notes.                                                      
XI.   Incompatibilities and Installation of MXG vv.yy.                  
 1. Incompatibilities introduced in MXG 27.yy (since MXG 26.26):        
    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 JCLINST9 for 
    SAS V9.1.3 or JCLINST8 for SAS V8.2.                                
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 26.26 now in MXG 27.01:
  Member   Change    Description                                        
  See Member CHANGES or CHANGESS in your MXG Source Library, or         
  on the homepage                                          
Inverse chronological list of all Changes:                              
Changes 27.yyy thru 27.001 are contained in member CHANGES.