****************NEWSLETTER FORTY-FOUR***********************************
    MXG NEWSLETTER NUMBER FORTY-FOUR, Feb 11, 2004.                     
Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE
                         TABLE OF CONTENTS                          Page
I.    MXG Software Version.                                             
II.   MXG Technical Notes                                               
III.  MVS Technical Notes                                               
IV.   DB2 Technical Notes.                                              
V.    IMS Technical Notes.                                              
VI.   SAS Technical Notes.                                              
VII.  CICS Technical Notes.                                             
VIII. Windows NT Technical Notes.                                       
IX.   Incompatibilities and Installation of MXG.                        
         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.                       
I.   MXG Software Version 21.21, the 2004 Annual Version, Feb 6, 2004,  
     was mailed to all sites by Feb 13, 2004.                           
 1. Major enhancements added in MXG 21.21:                              
    See CHANGES member of MXG Source, or    
II.  MXG Technical Notes                                                
 1. None.                                                               
III. MVS Technical Notes.                                               
11. A closed ETR documents that SRVCLASS='SYSOTHER' can occur in SMF 30 
    records, even when you have a Default Fall-Thru Service Class, if   
    the SMF record is being written, i.e., if SMF requests the service  
    class data from WLM, during a "Service Policy Activation".  During  
    that event, WLM cannot return the valid service class name, so it   
    is coded to return "SYSOTHER".  Working as Designed, no APAR.       
10. APAR OA06350 discusses problems with WLM-managed Initiators that did
    not start for what appeared to be very long times.                  
 9. Erratic, large values for DEVCONTM and DEVDLYTM ('FFFFnnnn'x, in the
    RMF 74 record, IBM fields SMF74CNN and SMF74DVB, a result typical of
    a subtraction underflow error) were found when OA05197 and OA05589  
    APARs were installed, but only for FICON connections, and only for  
    random read tests.  Those APARs revised calculations of values in   
    the RMF records, but their code changes have no impact on actual I/O
    performance.  With both APARs removed, the erratic large values in  
    those two fields did go away, but the RMF numbers without the APARs 
    showed cache hit response time increased and thruput reduced, so the
    APARs were re-installed, large values discarded while IBM works on  
    the problem, and the numbers with the APARs presumed more correct.  
    Jan 27, 2004: IBM has PE'd APAR OA05197 with new APAR OA06168 which 
    acknowledges an RMF coding error is the cause of negative values for
    FICON, and the PTF for OA06168 should correct the error.            
    Feb 16, 2004: APARs OA05197+ was installed and fixed the error.     
    But the changes in how FICON connect time is measured with and with 
    out the APAR is discussed in the text of OA05589:                   
      Because of the multiplexing capability built into fiber channel   
      and FICON, physical disconnection during execution of a channel   
      program is rare.  Control Unit queue time is accumulated during   
      connect time and not disconnect time, as was the case with ESCON. 
      The RMF device activity reporting has to be changed to reflect    
      this difference from ESCON.  Affected RMF releases: OS/390-2.10 up
      to z/OS-1.5                                                       
      With this APAR OA05589 RMF device activity reporting will be      
      changed for FICON attached devices as following:                  
        CU queuing time is now subtracted from Connect time and no      
        longer from Disconnect time.                                    
      For ESCON attached devices the calculation for connect and        
      disconnect time remain unchanged:                                 
         CU queuing time is subtracted from Disconnect time.            
 8. APAR OA04323 has no impact on MXG Software; it increased the number 
    of channels to 512, which caused some system monitor programs to    
    fail because they had internal tables that were too small.          
 7. APAR OA05542 reports large values in SMF30SRV, ACTIVETM, SMF30PSF.  
    See also APAR OW53698 for IOUNITS and SERVUNIT errors.              
 6. APAR PQ82309 reports growth in the Subpool 230 Protect Key 0 virtual
    storage when using MULC and creating SMF 89 records. 01Jan04.       
 5. APAR PQ81716 reports incorrect SMF 119 End Time Stamp for TN3270    
    sessions that start before midnight UTC and end after midnight UTC. 
 4. APAR OA06009 reports SMF 64 fields SMF64RIO, SMF64BMH and SMF64CFH  
    are not being updated while running RLS. 1Jan04                     
 3. How can you move SMF files between MVS Systems?                     
    a. XMIT/RECEIVE                                                     
    b. ftp data directly, to pre-allocated VBS file '':    
       MODE B                                                           
       TYPE E                                                           
       GET '' '' (REPLACE                   
    c. TRSMAIN                                                          
       //PACKIT   EXEC PGM=TRSMAIN,PARM=PACK                            
       //* PGM=TRSMAIN is an alias entry point for the new PGM=AMSTERSE,
       //* so you get the new features without having to change PGM=.   
       //* And if you do change to PGM=AMSTERSE instead of PGM=TRSMAIN, 
       //* you must ALSO change INFILE/OUTFILE ddnames to SYSUT1/SYSUT2 
       //SYSPRINT DD   SYSOUT=*                                         
       //INFILE   DD   DISP=SHR,                      
       //FTPOSA   EXEC PGM=FTP,REGION=4M                                
       //SYSPRINT DD SYSOUT=*                                           
       //INPUT  DD *                                                    
        < >                                                   
         put '' (replace                           
     d. ftp as RECFM=U to PC, ftp PC file to MVS RECFM=U,BLKSIZE=32760, 
        and then use MXG's UDEBLOCK utility to re-create the VBS records
        from the uploaded RECFM=U file.                                 
 2. ABEND 0C9 in DFSORT (especially in SAS invoked sorts!!) is corrected
    by APAR PQ80787.  The ABEND is in ICEKPUT at X'1230' when E33 Exit  
    is used (and SAS uses that exit).  Nov 20, 2003.                    
 1. Type 42 Subtype 21 (DELETE ALIAS) SMF records are not written if you
    have CA's PDSMAN product, and you have FASTSTOW=Y (i.e., FAST STOW  
    option of PDSMAN is enabled).  The deletion 'feature' is not yet in 
    the PDSMAN documentation for FASTSTOW option, but it was CA support 
    that recommended disabling FASTSTOW so the SMF records are written. 
    Nov 19, 2003.                                                       
IV.  DB2 Technical Notes.                                               
 3.  Another source of negative DB2TCBTM is noted in APAR PQ83772, is   
     Turning on DB2 Accounting Trace Class 2 on corrected the problem.  
     The problem reportedly only occurs with CICS/TS 2.2.  17Feb04.     
 2.  APAR PQ79622 corrects error that caused QWACBJST to be greater than
     QWACEJST, which caused negative DB2TCBTM.  The error occurred when 
     an SQL statement fired a trigger and that trigger called either a  
     UDF or a stored procedure, that class 1 non-nested CPU time could  
     erroneously be a negative value.                                   
 1. The DB2PM product statistics reports did not correctly deaccumulate 
    buffer pool activity in intervals in which a Buffer Pool was skipped
    (where that Buffer Pool had had activity in the previous interval). 
    MXG properly deaccumulated across the missed intervals, and IBM's   
    DB2PM has accepted the error in APAR PQ81241. PTF issued 4Mar2004.  
V.   IMS Technical Notes.                                               
VI.  SAS Technical Notes.                                               
 5. MXG has added long-length variables to some datasets, which cause   
            COULD NOT BE COMPLETED                                      
    when you PROC COPY any of those datasets from a V8/V9 data library  
    to a V6 data library (like your daily DISP=OLD PDB data library     
    build years ago with SAS V6).                                       
    If DDNAME points to a disk data library, then you must create a new 
    data library under V8/V9 and use PROC COPY IN=OLD OUT=NEW MT=DATA;  
    to preserve the existing datasets                                   
    If DDNAME is a tape data library, see the next technical note, 4.   
 4. SAS Version 9.1 (TS1M0) had been tested by MXG under Windows, Linux,
    and z/OS versions of SAS, with no real problems or errors, and with 
    only positive execution results; there is either equal or slightly  
    better performance (Elapsed, CPU) with V 9.1.                       
     A. Feb 11, 2004: FLASH: MXG default changed to V8SEQ or V9SEQ.     
        Please replace V6SEQ in CONFIGV8/CONFIGV9 with V8SEQ/V9SEQ, to  
        be completely safe and avoid potential errors.                  
        In the Feb 6, 2004 (first) MXG 21.21 code and in the Newsletter 
        FORTY-FOUR that was in NEWSLTRS member, MXG still used the      
        SEQENGINE=V6SEQ option, because it saved some CPU time by not   
        compressing when datasets were written/copied to tape.  But I   
        had failed to test PROC COPY to tape with all MXG datasets, and 
        today discovered that copying some datasets would fail with     
        if the MXG dataset contains long-length variables.  Only a few  
        MXG datasets, built under SAS V8/V9 have long-length variables, 
        but for long text strings, like SQL text, it is the right thing 
        to do (the alternative: break text into 200 byte chunks!).      
        So to avoid the errors, the MXG Sequential Engine default was   
        changed in the Feb 11, 2004 edition of MXG 21.21.               
        The original note in Feb 6 Newsletter, below, is technically    
        correct as to why V6SEQ was originally used, but the additional 
        CPU time for the "unnecessary" compression to IDRC tape drives  
        is so small that I now wonder if I should have ever spent all   
        this time/effort discussing it; for a 265 MegaByte file, the    
        added CPU time was only 20 CPU seconds on a SU_SEC=10000 CPU!   
        This is the original Technical Note in Feb 6, Newsletter:       
        MXG still uses SEQENGINE=V6SEQ for SAS V 9.1 instead of V9SEQ,  
        because the V9SEQ engine spends CPU time when PROC COPY to tape 
        with COMPRESS=YES is used: since all MVS tape devices are IDRC  
        hardware compressed, we don't want SAS to compress to tape.     
        In SAS V9.1, the V9SEQ engine WAS changed for the DATA step,    
        and SAS datasets written to tape in a DATA step are no longer   
        compressed.  But there's nothing wrong with V6SEQ, and nothing  
        new/needed in V9SEQ, and the V6SEQ engine has always not invoked
        SAS compression when writing to a tape device, so there is no   
        reason to change MXG, and if I did, some site somewhere would   
        see and investigate an avoidable CPU bump in their copy jobs.   
           It turns out the real "culprit" isn't PROC COPY, per se, but 
           the NOCLONE option of PROC COPY.  If we could change the text
           of every PROC COPY statement in source code (in MXG, and in  
           all of your tailoring and personal libraries!), to add the   
           NOCLONE option (assuming there's enough blank space on each  
           line), we see that CPU time results with V9SEQ match V6SEQ.  
     B. Condition Code (also called Return Code) value of 4 can be      
        expected with MXG's BUILDPDB, because of                        
        The warning now identifies the variable, and can't be avoided   
        for JOBCLASS; JOBCLASS is $8 for JES3, but only $1 for JES2.    
        And if you use CA-7 for job control and it now expects RC=00,   
        you'll need to change that in CA-7 before running under SAS 9.1.
        UPDATED: JAN 21, 2005:  MXG Change 22.365 has eliminated this   
        Condition Code problem with SAS V9.  With MXG 22.22 or later,   
        the JES2 default BUILDPDB will end with Condition Code of ZERO. 
     C. Windows-only comparisons, XP on 3.2 GHz Processor, with disk    
        copy speed: 8.7 MegaBytes/sec to same disk, 23.4 MB/sec to a    
        second disk:                                                    
        Input SMF is 882 MegaByte "JOBS" (SMF 6s, 26s, 30s).            
                            V9.0 ET   V9.1 ET      V9.0 CPU   V9.1 CPU  
           With Compress:    1910      2042         488         382     
           No Compress       3143      3000         354         330     
        2. BUILDPDB, no DDSTATS/SMFINTRV created:                       
                                      V9.1 ET     V9.1ET                
                                      FULLSTATS   NOFULLSTATS           
           With Compress:               278         264                 
         a.  COMPRESS=YES on Windows definitely reduces run time from   
             large BUILDPDB run time of 50 minutes without, to only     
             34 minutes, for one additional minute of CPU time.         
         b.  FULLSTATS used to cause E.T increase, but not with 9.1;    
             BUILDPDB took 4 min 38 seconds with FULLSTATS, and took    
             4 min 24 seconds, so FULLSTATS don't cost much and provide 
             diagnostic data that is helpful!                           
     D. MXG and SAS V9.1 were run under Windows XP, Linux RH8, z/OS 1.4.
        Linux and Windows used the same AMD 1400 1.5 GHz processor with 
        500 MB and removable drives; z/OS runs were on an IBM 2064-210. 
        The 842MB SMF file was used.                                    
        The DATA step cost is tabulated, and the PROC SORT of TYPE30_D, 
        which was 3.4 GigaBytes in size are compared:                   
        Data Step            LINUX      WINDOWS       z/OS              
          Elapsed Time      4:27.70     7:40.02     11:03.36            
          CPU time          3:59.46     3:57.64      5:56.7             
        PROC SORT                                                       
          SORTSIZE DEFAULT     48MB        64MB        MAX              
          Elapsed          15:39.82    28:19.89     12:28.98            
          User CPU          5:01.43     4:02.93      5:23.16            
          SORTSIZE            200MB       200MB                         
          Elapsed          15:26.10    28:19.89                         
          User CPU          5:01.02     4:02.93                         
          SORTSIZE            400MB       400MB                         
          Elapsed          19:12.40    35:05.38                         
          User CPU          5:02.79     4:15.81                         
         a. SAS V9.1 under LINUX significantly outperforms Windows XP,  
            in both the DATA step and in the SORTS.                     
         b. SAS V9.1 under z/OS is significantly slower than either     
            LINUX or Windows for the DATA step.                         
         c. SAS V9.1 under z/OS is better for PROC SORT, but that was   
            with SYNCSORT on z/OS.  Newsletter FORTY showed that the    
            SYNCSORT product under Windows was significantly better     
            than the internal SAS sort under V9.0, but SYNCSORT on      
            Windows was not available for these tests.                  
         d. On ASCII platforms the SORTSIZE parameter does impact the   
            elapsed time, and elongation occurs if SORTSIZE is too      
            large or too small. SAS V9.1 defaults were increased from   
            the old 2MB default, and seem fine for this 3.4 GB sort.    
         e. But what is really demonstrated is the repeatability and the
            reliability of the SAS System's MVA Architecture to meet the
            needs of your SAS applications on any of these platforms. It
            takes SAS 5-10 minutes to read a 1 GB SMF file and to create
            an MXG "MVS" PDB data library, and 15 minutes to sort a 4 GB
            dataset, no matter where you run it; that's pretty cool!    
            And clearly this is not a capacity comparison of the two    
            hardware platforms; running MXG on Intel requires dedicated 
            hardware, at least during the creation of the PDB libraries,
            while z/OS can support thousands of users during BUILDPDB.  
            But it should give you confidence that MXG will continue to 
            measure your computer systems, no matter where SAS runs, and
            your MXG and SAS skills are transferable across platforms.  
    if you try to read a Large Block Interface tape file with block size
    greater than 32760.                                                 
      (introduced in OS/390 R2.10, LBI, Large Block Interface, allows   
       256K for 3590s, 65535 for other tapes, no change for DASD).      
    SAS Note SN-010759 documents that LBI support is being looked at for
    a future release after SAS 9.1, and "until this, it will not be     
    possible to read those tape files".                                 
 2. ABEND 0C4 in the FORMATS step of JCLINSTL with SAS Version 9 was    
    caused by REGION=6M statement on the JOB card.  REGION=64M or       
    REGION=0M has been recommended for Version 8 and 9 for BUILDPDB.    
    Also make sure there is not a REGION= parameter on the STEP card.   
    Nov 2008:  0C4 also occurs with SAS Version 9.1.3 if ENTRY=SASHOST  
               is used.  ENTRY=SAS is the correct name for V9.1.3.      
 1. For execution under Windows systems, batch file examples using the  
    START command are discussed in SN-010991 which lists the link:      
      "For more information about running jobs in batch, see:                   
      which then lists the link:                                                
      that does discuss batch execution of SAS under Windows.           
VII. CICS Technical Notes.                                              
 1.  APAR PQ81482 corrects CICS ABENDS and overlays that are caused when
     PTF UQ79397 is applied after APAR PQ63141, when MNRES=ON in your   
     CICS SIT to enable Transaction Resource Class monitoring, if DFHMCT
     is coded with FILE=8 or more.                                      
VIII. Windows NT Technical Notes.                                       
IX.   Incompatibilities and Installation of MXG 20.20.                  
 1. Incompatibilities introduced in MXG 21.07 (since MXG 20.20):        
    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            
 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 20.20 now in MXG 21.xx:
  Member   Change    Description                                        
  See Member CHANGES or CHANGESS in your MXG Source Library, or         
  on the homepage                                          
Inverse chronological list of all Changes:                              
Changes 21.yyy thru 21.001 are contained in member CHANGES.