*********************NEWSLETTER FORTY-SIX*******************************
       MXG NEWSLETTER NUMBER FORTY-SIX, Dated February 1, 2005.         
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 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.  The Annual MXG Version, 22.22, dated February 1, 2005, was sent     
    on CD-ROM to all sites by Feb 2, 2005.                              
 1. Major enhancements added in MXG 22.22:                              
    See CHANGES member of MXG Source, or    
II.  MXG Technical Notes                                                
 1. You can use the SAS FTP access method to directly read MVS SMF data 
    on your execution platform (another MVS or an ASCII pc/unix system!)
    without first downloading the SMF file, and without converting the  
    data file to RECFM=U:                                               
     - read with ftp access takes no disk space to store the SMF data   
     - run time is faster with ftp-access than the sum of the time to   
       ftp-download plus read the downloaded data:                      
       - MVS to ASCII direct read took 82 seconds ET, ftp download took 
         200 seconds ET and then 27 seconds ET to run TYPE30 on ASCII.  
       - MVS to MVS direct read took 1 min 11 sec ET (17 CPU seconds),  
         ftp download took yyy ET (zzz CPU), plus 35 seconds ET (14 CPU)
         to read the downloaded file.  And the ftp access job had only  
         903 EXCPs (those must be the output writes, with none of the   
         ftp access I/O being counted!), while reading the downloaded   
         file recorded 12,000 EXCPs.                                    
    This FILENAME statement syntax will read your MVS data using the    
    ftp-read-access, and prompt for password:                           
            RECFM=S370VS RCMD='SITE RDW' LRECL=32760 PROMPT;            
    or you can use this syntax and supply the password:                 
            RECFM=S370VS RCMD='SITE RDW' LRECL=32760 PASS='password';   
    To use the ftp access on MVS, you will need MXG 22.12 or later, and 
    as documented in Change 22.300, you will need to use                
               %LET MXGJFCB=;                                           
    as your first //SYSIN DD statement.                                 
    SAS Note SN-013919 documents "ERROR: Service FTP not found" will    
    occur if your services file, usually in                             
    does not include the following line                                 
      ftp    21/tcp   # File Transfer Protocol (Control)                
III. MVS Technical Notes.                                               
12. APAR PQ98850 corrects the values of variables QESTMNUS,QESTMLUS in  
    MXG dataset MQMCFMGR, from SMF 115 MQ-Series Coupling Facility Data.
11. APAR OW19569 changes the Message Identifiers for SMF Data Set name  
    messages, if you choose to use new SMF dataset names.  Formerly,    
    you could only have SYS1.MANn as the DSNAME of your VSAM SMF file,  
    but you can now choose any 44-character name in your SMFPRMnn member
    of SYS1.PARMLIB.  But, if you do, the old messages (IEE360I,IEE362A,
    IEE362I,IEE364I,IEE949I-IEE953I,IEE960I and IEE966I) are now change 
    to new numbers listed in the APAR.  This would be very important if 
    your Automated Operations product does any management of SMF data   
    based on Message ID.                                                
10. Information APAR II13668 documents that the LPARNUM (SMF70LPN) is no
    longer what it used to be!  Prior to the 2084, machines used to use 
    the customer input value for what was called 'partition number', and
    those old machines used it to identify both the logical partition   
    number and the MIF image ID number for its I/O.  Beginning with the 
    2084 and all future machines, that input control for HCD/IOCP       
    applies only to the I/O for the partition, in concert with the CSS. 
    There is no customer control over the number (SMF70LPN/LPARNUM) that
    identifies the logical partition number itself.  The customer does  
    specify the MIF image ID number to identify its I/O in the 2084     
    IOCDS, but the partition-number in SMF70LPN is internally generated 
    alphabetically, based on LPARNAME by CSS.  This changed terminology 
    is documented in the z990 IOCP User's Guide (SB10-7037).            
    In the PDB.ASUM70PR and PDB.ASUMCEC MXG datasets, the set of LPnXXXX
    variables for each LPAR was based on the LPARNUM, so with 2084s what
    used to be in LP3XXXXX variables can be in any of the LPnXXXXX sets 
    of variables, and that could change again tomorrow.  Instead of     
    using the PDB.ASUM70PR dataset for PR/SM LPAR analysis, you should  
    use the PDB.ASUM70LP dataset, that has only one set of variable     
    names, and one observation for each LPARNAME, which should be used  
    in your reporting/selection, instead of LPARNUM, now.               
    And instead of using the PDB.ASUMCEC, which has the similar LPnXXXXX
    sets of variables, the PDB.ASUMCELP provides one set of variable    
    names, reporting the full utilization of all LPARs/SYSPLEx in a CEC.
    Also, while the LPARNUM might not be what you expected numerically, 
    because it is assigned to the LPARs alphabetically, the LPARNUM and 
    the PARTISHN number will match for the LPAR of "this" MVS system, os
    the logic in VMAC7072 is not affected by this change.               
 9. APAR PQ98201 fixes several internal defects for WebSphere 5.2.3,    
    including incorrect values in X500Name information in SMF Audit     
 8. APAR PQ98850 corrects SMF MQ-Series for z/OS Version 5.3 SMF record 
    data fields QESTMNUS and QESTMLUS (Max Elements and Max Entries)    
    that had extremely large values, sometimes.                         
 7. APAR OA10164 (finally - I reported this to IBM in 1993!) changes the
    Internal Clock Times of IBM's VTS device so they match the mainframe
    clock; previously, the VTS clock ran on its own time, and was hours 
    away from reality when I first tried to match SMF 94 with internal  
    log data from the VTS device.                                       
 6. A question posted to MXG-L regarding the difference between SMF30AIS
    (25,000) and EXCPDASD (400) for an IMS BMP was answered by my best  
    SMF30AIS is an Address Space total count of SSCHs, the number       
    of I/O operations caused by this address space to DASD devices,     
    and is captured at the hardware level, and includes I/O operations  
    that this address space performed via cross memory services to      
    any other address spaces, plus any I/O from dependent enclaves.     
    EXCPDASD is the sum of SMF30BLK, the Block Count for each DASD DD   
    in this address space's TIOT, and those Block Count values depends  
    on the Access Method:                                               
     - for "well behaved" sequential Access Methods, QSAM/BSAM, it will 
       be the count of blocks, i.e., "EXCPs"                            
     - for VSAM it will be the count of SSCHs                           
     - for EXCP Access it is whatever the Access Method programmer      
       chose to pass to the IFASMFEX routine that updates the DD segment
       in the TIOT, and will be zero if IFASMFEX is not called from that
       I/O Driver.                                                      
    And, of course, there is nothing in the TIOT segment that indicates 
    what access method was used for that DD!                            
    Especially when the Access Method is EXCP, the I/O coder may not    
    even call IFASMFEX, since there is no requirement that he/she do so.
    This is why there are zero EXCPs for your //SORTWKnn DD's, whether  
    you use SYNCSORT or DFSORT.                                         
    Years ago, SYNCSORT published benchmarks in advertisements showing  
    that their sort program performed many fewer I/Os than IBM's sort.  
    I was asked by a third party to examine their veracity, and found   
    that I/O counts existed only for //SORTIN and //SORTOUT DDs, and    
    that SYNCSORT was passing the number of SIOs to IFASMFEX, while IBM 
    was passing the (larger) number of Blocks/EXCPs to IFASMFEX.        
    This caused SYNCSORT to have to "fess up", and they had to create a 
    "Special Core ZAP" that allowed you to choose to count EXCPs rather 
    than SIOs, because of the false impact on existing billing systems. 
    With regard to IMS, I have a vague recollection that OSAM does not  
    normally call IFASMFEX when I/O is performed, but, rather, only when
    IMS files were closed, and that that caused the EXCP count in RMF 72
    to only be updated at the "end of day", but I was unable to find any
    reference, and that may no longer be true.                          
 5. SYNCSORT Early Warning Notice EW5981-0 was required for z/OS 1.5 to 
    resolve WER061A Equip Check (HDS DASD) ABEND 1188 RC 094B96104 error
 4. A large number of IsUserInRole SMF 80 records are created with CA's 
    Top Secret Security Product that are not errors. IBM APAR PQ96045   
    eliminates these "false" SMF 80 AUDIT records, but CA fix BEA6729   
    for Top Secret V5.2 is also required for their product.             
 3. APAR OA08887 reports incorrect values in RMF 74.4 variables R744PNU,
    R744PBSY, and R744PWAI (MXG variables CFNUMnn,CFBUSYnn,CFWAITnn.    
 2. As of z/OS 1.3, the Media Manager is used to do all I/O for the CAS 
    (Catalog Address Space), causing the number of CAS I/Os to increase;
    before z/OS 1.3, CAS used VSAM to do Catalog I/O and the Media Mgr  
    was only used for VVDS I/O, but VSAM specifically omitted the       
    collection of StartIO or block counts when running under the CAS.   
    So there really was no increase in I/O with z/OS 1.3, but rather a  
    significant underreporting of CAS I/Os prior to 1.3.                
 1. Striping enhancements to extended-format sequential datasets made in
    z/OS 1.5 now allow a maximum of 59 stripes, and thus 59 volumes, and
    so an extended-format striped sequential dataset now supports up to 
    4GB of blocks (not bytes!).  Since each volume can have 123 extents,
    the dataset can have a maximum of 7257 extents.                     
IV.  DB2 Technical Notes.                                               
  3.  DB2 APARs PQ91101, PQ86477, PQ85650, PQ87440, PQ87783, PQ87848,   
      PQ88889, PQ90547, PQ91544, PQ73385, PQ74506, and PQ65302 all have 
      references to IFCID 225 or 217, and without some (or maybe all?)  
      of those APARs installed, enabling either (or both) of those DB2  
      IFCIDs can corrupt data in all SMF 102 trace records.             
  2.  My understanding of some DB2 objects; please correct if wrong:    
        Plans can call packages.                                        
        Packages can call stored procedures.                            
        Packages can be bound into collections.                         
        But not all packages call stored procedures, so there is no real
          relationship between the count of observations in DB2ACCTP    
            (each obs in DB2ACCT is the execution of a package)         
          and the value of QPACSPNS, the count of stored procedures that
            were called by that package execution.                      
          So in a DB2ACCTP observation, QPACSPNS is zero if the package 
          did not call a stored procedure, or non-zero if it did.       
  1.  If you run DB2 under "MVS" running as a VM guest when in z/Arch   
      mode, Hiperpools will not function under DB2 without APAR PQ87231.
V.   IMS Technical Notes.                                               
 1. APAR PQ65904 documents problems with excessive number of false IMS  
    Scheduling Messages, each of which showed .01 CPU seconds in IMS 07 
    Log records; these false schedules can be recognized by IBM field   
    DLRGUMES (which is MXG variable CALLMSGU) being zero.               
VI.  SAS Technical Notes.                                               
 9. A comparison of SAS reading selected SMF records in one pass versus 
    using IFASMFDP to first select and write out the desired subset of  
    SMF data, and then SAS reading that subset appears to be a draw.    
    An 8989 MegaByte SMF file with all SMF records was read by IFASMFDP 
    selecting 30, 72, and 89 records, which totaled 3097 MB, which was  
    then read with MXG's BUILDPDB (tailored to read only those records).
    IFASMFDP used 0.45 CPU minutes and 5.26 Elapsed minutes to read and 
    write, and the BUILDPDB used 12.51 CPU minutes and 21.26 Elapsed min
    to read the 3GB file, for a two-step total of 12.96 CPU, 26.62 ET.  
    BUILDPDB's 9GB read in one step took 13.26 CPU, 33.97 ET.  The two  
    step job issued 334,076 EXCPS to the one step total of 101,724.     
 8. Under ASCII platforms, if you want to see the actual statements in  
    the autoexec file that is being executed, sas -echoauto will do it. 
 7. Under SAS V9 on "MVS", new "+SAS processed" messages are printed on 
    the SYSMSG log, which I find useful, but which are enabled by the   
    option DLEXCPCOUNT, which I chose to enable in CONFIGV9, but which  
    can be changed to NODLEXCPCOUNT if you really don't like them!      
 6. Use of BUFNO=nnn, especially with large (200!) values of nnn, on the
    //PDB or //SPIN or //CICSTRAN SAS data library DDs has caused very  
    strange out-of-memory errors, including SYSTEM ABEND 878-10, with no
    SAS messages on the log, and the ABEND occurred long after those DDs
    had been written to during the SMF-processing phase - the error was 
    deep inside the RMFINTRV logic.  Remove the BUFNOs!!  Benchmarks run
    by Martin Kline at American Century show these results:             
      BUFNO:      1000        100         20      DEFAULT       2       
      IOTM       17:21      16:17       15:59      15:49      15:51     
      Elapsed    34:13      30:29       30:22      33:35      32:36     
      CPUTM      13:11      12:28       12:31      12:38      12:38     
      CPUTCBTM   13:03      12:20       12:23      12:29      12:29     
      TCB+IO     30:25      28:37       28:23      28:18      28:20     
 5. The new V9 PROC MIGRATE can convert SAS V6, V7, or V8 data libraries
    to V9 format; the manual for the new procedure is available at 
 4. Yet another error in the Sequential Engine, this time in V6SEQ under
    V9.1, V9.1.2, and V9.1.3.  SAS Note SN-013514 has the hot fix.      
    The error occurs when the V6SEQ engine under those V9 versions tried
    to read a SAS dataset that was sorted by more than 10 variables when
    it was created, and it causes this error message:                   
      ERROR: The format xxxx was not found or could not be loaded       
       ('xxxx' is not a real format name, but typically unprintables).  
    The original V6SEQ dataset can still be read with the V6SEQ engine  
    in Version 8, so the dataset is not actually corrupt; it is only the
    the V6SEQ engine in SAS V9 that is broken and must be repaired with 
    the hot fix, and then it can be read with SAS version 9's.          
    appears to have been caused by Syncsort adding dynamic SORTWKnn DDs.
    The job had 12 SORTWKnn DDs in the JCL, but the job log shows there 
    were DELETED messages for SORTWK13 thru SORTWK22, indicating that   
    SyncSort dynamically added 10 DDs.   The job failed half of the time
    but a rerun was successful.  Adding 10 SORTWKnn DDs to the job has  
    apparently corrected the error.                                     
    the library was externally allocated is discussed in SN-007759:     
       If any of the following hot fixes have been installed:           
         81BA50, 82BA57, 82BX01 (or its replacement),                   
       and a direct access bound library is allocated externally to SAS 
       with DISP=OLD or DISP=SHER via JCL or TSO ALLOCATE command, and  
       assigned by SAS more than once during the lifetime of the MVS    
       allocation, any attempt to use the library after the reallocate  
       will generate that error.                                        
    The hot fix is available in that SAS note.                          
 1. New SAS Option ERRORBYABEND is not needed in MXG's CONFIGV9 member, 
    because the ERRORABEND option already causes a USER 999 ABEND when  
    a BY list is not in order.  It appears ERRORBYABEND was created for 
    sites that ONLY want an abend on a bad BY list, when ERRORABEND was 
    not desired.  The SAS default is NOERRORBYABEND.                    
VII. CICS Technical Notes.                                              
VIII. Windows NT Technical Notes.                                       
IX.   Incompatibilities and Installation of MXG 22.02.                  
 1. Incompatibilities introduced in MXG 22.10 (since MXG 21.21):        
    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 21.21 now in MXG 22.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 22.yyy thru 22.001 are contained in member CHANGES.