***********************NEWSLETTER SIXTY-ONE*****************************
          MXG NEWSLETTER NUMBER SIXTY-ONE, JANUARY 21, 2013             
Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE
                         TABLE OF CONTENTS                              
I.    MXG Software Version.                                             
II.   MXG Technical Notes                                               
III.  MVS, aka z/OS, Technical Notes                                    
IV.   DB2 Technical Notes.                                              
V.    IMS Technical Notes.                                              
VI.   SAS Technical Notes.                                              
VI.A. WPS Technical Notes.                                              
VII.  CICS Technical Notes.                                             
VIII. Windows NT Technical Notes.                                       
IX.   z/VM Technical Notes.                                             
X.    Email notes.                                                      
XI.   Incompatibilities and Installation of MXG.                        
         See member CHANGES and member INSTALL.                         
XII.  Online Documentation of MXG Software.                             
         See member DOCUMENT.                                           
XIII. Changes Log                                                       
     Alphabetical list of important changes                             
     Highlights of Changes  - See Member CHANGES.                       
I.  The 2012 Annual Version MXG 29.29 was dated Jan 23, 2012.           
 1. The current version is MXG 30.30, dated Jan 21, 2013.               
    You can always use this form                                                           
    to request the ftp download instructions for the current version.   
    See CHANGES member of MXG Source, or    
II.  MXG Technical Notes                                                
 1. Compressed CICS or DB2 data should be decompressed on z/OS before   
    it is read on ASCII platforms with MXG.                             
    On ASCII, MXG internal SAS code that decompresses CICS SMF 110s took
    over TWO HOURS to read a 652 MB compressed CICS SMF file that needed
    only TWO MINUTES for PGM=DFH$MOLS to decompress on z/OS, and then   
    only NINE MINUTES for MXG to process the 2354 MB CICS file on ASCII.
    (MXG does print a NOTE when this internal code is executed.)        
    The below results STRONGLY RECOMMEND that compressed CICS ID=110    
    subtype 1 records should be decompressed with PGM=DFH$MOLS on z/OS  
    and that data read from the ASCII platform.  Unfortunately, DFM$MOLS
    will only write SMF 110 subtype 1 records; it does NOT pass other   
    SMF records into its output, so you will need to split the 110-1's, 
    run them thru DFH$MOLS, and concatenate with the other SMF data.    
    Also, you must use a new CICS version's DFH$MOLS program to read    
    a new CICS version's records; you cannot use the CICS 4.2 DFH$MOLS  
    to uncompress CICS 5.1 data (USER ABEND 106). See member DFH$MOLS.  
    The same algorithm is used for DB2 compressed SMF records, so I also
    STRONGLY RECOMMMED that DB2 ID=101 compressed records should also be
    first decompressed on z/OS by PGM=DSNTSMFD and then the decompressed
    records are read by MXG on ASCII.  DSNTSMFD does write all other SMF
    records in its input to its output. See member DSNTSMFD.            
    Newsletter FIFTY-SEVEN compared processing CICS data on ASCII, but  
    didn't use the ftp access method, and its example was not dense CICS
    compressed data.  This new measurement's SMF file is 110-only, with 
    85900 records, 78620 of which are compressed subtype 1 records; the 
    SMF file is 652 MB, of which 562 MB are compressed subtype 1s, which
    uncompress to 2354 MB.                                              
     a. Use DFH$MOLS first to uncompress the file and read UNCOMPRESSED.
     c. Use MXG's internal SAS algorithm to read COMPRESSED NO EXIT.    
                                 Elapsed    User CPU SYS CPU    Size    
      a. DFH$MOLS on z/OS        00:02:00   00:00:05          652/2354MB
         UNCOMPRESSED on ASCII   00:09:36   00:08:57 00:00:05   2354 MB 
           total                 00:11:36                               
      c. INTERNAL SAS on ASCII   02:19:24   02:13:04 00:00:29   2354 MB 
    The uncompressed file requires z/OS disk space, 2354 MB, but ONLY   
    for eleven minutes, and it is a temporary file.                     
    And, for reasons I do NOT (yet) understand, DFH$MOLS program SORTs  
    the input SMF file. The DFH$MOLS log statistics show:               
      Records Read     85,900  ( 652MB)                                 
      Records Written  78,260  (2354MB)                                 
      Sortwork Tracks  10,419  ( 549MB)                                 
III. MVS, a/k/a z/OS, Technical Notes.                                  
 5. APAR PM79239 for HTTP Server for z/OS 5.3 reports a remote          
    attacker could execute arbitrary commands on the system, with       
    a base CVSS Score of 10, which, I presume, is the reason the        
    APAR is a FLASH(ALERT), and why IBM reps are calling customers.     
    APAR OA41000 or OA41031 for z/OS, and APAR OA41059/60/61 for        
    Tivoli Netview are also a part of the Security Vulnerability.       
 4. APAR PM74888, PTF UK90705 12/21/2012, corrects wrong data is        
    in SMF 101 records for QWACZIIP_ELIGIBLE, only for DB2 utilities.   
    This is MXG variable QWACZIEL in DB2ACCT, T102S148 or T102S369.     
    record can be incorrect.  When an agent executes a utility, a call  
    to record the stop of accounting time executing that utility will   
    not correctly obtain the zIIP time of the CPU.  This incorrect value
    will then be used in a calculation of QWACZIIP_ELIGIBLE for the     
    subsequent accounting record, resulting in incorrect values for     
    QWACZIIP_ELIGIBLE field.  This error could appear in any of these   
    records: IFCID3, IFCID148 and IFCID369.  One instance in one record 
    had over 14,576 HOURS in QWACZIEL without the PTF.                  
 3. APAR OA39058 makes changes to the ID=99 SUBTYPE=14 records, to      
    consolidate the current two-records-per-interval into a single      
    record.  See Change 30.259.                                         
 2. APAR OA40532 reports SMF 21 read/write counts in SMF21BR, SMF21BW,  
    SMF21BRN and SMF21BWN can be zero when data was transferred; the    
    APAR cites only device type 3592 Model E07 as having the error.     
 1. APAR OA40596 reports CPU time fields in TYPE 42 subtype 19 are not  
    correct, but did not identify if both SMF42JNE and SMF42JNF are     
    wrong, and the APAR reports that RMF III RLSLRU CPU times are taken 
    from the 42-19 and is also wrong.  The APAR is OPEN, but it has a   
    circumvention(divide by 4096*10**6) but MXG has already divided by  
    4096*10**3 so it's unclear if dividing current by 1000 is correct.  
    Additionally, APAR OA40653 identifies these ID=42 variables are all 
    incorrect (all fields in the SMF2AJPY array): SMF2AJPZ SMF2AJQA     
IV.   DB2 Technical Notes.                                              
 1. Text                                                                
V.   IMS Technical Notes.                                               
 1. Text                                                                
VI.  SAS Technical Notes.                                               
 3. ITSV Sites using %CPSTART with an MXG Program HARDCODED with "PDB." 
    will fail when MXG writes to //PDB, which has DISP=SHR in ITSV.     
    The hardcoded value is the cause of the error, and the MXG program  
    corrected; ever since Change 15.320, the macro variable &PDBMXG has 
    been the correct syntax.                                            
      The ITSV "PDB" is a logical grouping of data libraries, with      
      different summarization levels.                                   
      In MXG, PDB is the default LIBNAME to which most programs write   
      their output SAS datasets.                                        
    But, to document how this interface between ITSV and MXG works, you 
    could use that MXG program with hardcoded PDB. after %CPSTART, by   
    invoking %VMXGINIT after %CPSTART to change the MXG default to WORK:
        //SYSIN DD *                                                    
         %CPSTART(MODE= . . . .   );                                    
         %INCLUDE SOURCLIB(ANALZIPC);                                   
    Then, all of the datasets that would have been written to //PDB are 
    in the //WORK data library, and all reports were produced. If you   
    also want to KEEP those "//PDB" datasets created by the MXG program,
    you can add this LIBNAME statement in your JCL                      
         //           UNIT=SYSDA,SPACE=(CYL,(500,500))                  
    and add this SAS statement after the %INCLUDE in the SYSIN program. 
         PROC COPY IN=WORK OUT=REALPDB MT=DATA;                         
    Note that when %CPPROCES/%CMPROCES are used to create an MXG "PDB"  
    library, they replace the BUILDPDB functionality, with a %VMXGINIT  
    to change the default to WORK, and then execute a constructed DATA  
    step of _VARxxxx and _CDExxxx tokens for the MXG datasets you want, 
    which are then copied from WORK to DETAIL, where they are renamed   
    to their ITSV names.  But %CxPROCES also defines VIEWs for datasets 
    in their DETAIL library that, when you use the PDB LIBNAME, return  
    the original MXG dataset and variable names, so you can %INCLUDE    
    MXG programs that expect their data in the PDB data library and they
    work just fine "as-is" after you use %CxPROCES.                     
 2. SAS Version 9.2 on z/OS ABEND 0C4 in SASVM occurred in DAILYDSN job 
    with MXG 30.04 but ran fine with MXG 29.05.  Customer compared MXG  
    options with their CONFIG options and found MPRINT in their CONFIG  
    that was NOT in MXG's default, and removing the MPRINT from CONFIG  
    eliminated the error, even though OPTIONS MPRINT is very OFTEN used 
    by MXG support for diagnostics.  SAS Technical Support confirmed the
    actual error is Problem Note 39533 for 0C4 in SASVM, SASXAL, SASXA1 
    and that error is corrected in SAS V9.3, but the 9.2 circumvention  
    is to use OPTIONS NOCARDIMAGE.  Yes, removing an option sometimes   
    did circumvent this error, but NOCARDIMAGE is the 9.2 culprit.      
    In SAS 9.4 the z/OS default will become NOCARDIMAGE, which is the   
    current default on ASCII platforms.                                 
 1. TRACEBACK ERROR with SAS 9.1.3 SP 4 on z/OS.                        
   -TRACEBACK errors can be due to insufficient region size, although   
    some cases in 9.1.3 were actual compiler errors that were corrected.
    A site testing MXG 30.04 with no REGION specified on the JOB card,  
    but with 250M specified on the STEP card, failed during the compile 
    of PROC SQL inside the _SDB2 macro (i.e., after the "big DATA step" 
    had successfully read the SMF data), with a "TRACEBACK ERROR" (and  
    NO other clue).                                                     
   -My first guess, memory:                                             
    While the SAS 'initialized' message reported 250MB was available,   
    the IBM step terminate IEF032A message showed the SYS+EXT was ONLY  
    93MB+11MB, and the last SAS memory note reported the above-the-line 
    virtual storage was 93MB (but only 672K below!), so both suggested  
    that the job's region had been limited to about 100MB.  In z/OS,    
    when there is no REGION parameter on the JOB card, it is the site's 
    IEFUSI exit that limits the allocated region size, and, sure enough,
    this site had a 101MB limit specified in their IEFUSI exit.  The    
    site changed IEFUSI to 250M and reran, but encountered the same     
    error at the same place, so this may NOT have been memory-related,  
    in spite of the preceding guess.  Fortunately, the site was able    
    to (WISELY!) upgrade to SAS Version 9.3 to eliminate the error.     
   -The answer from SAS Technical Support:                              
    With SAS Version 9.1.3 there were known (and now fixed) issues with 
    PROC SQL when OPTIONS THREADS was enabled, and changing to use the  
    OPTIONS NOTHREADS would have been their recommendation.             
    They think the memory numbers were an artifact and not the cause.   
VI.A.  WPS Technical Notes.                                             
 1. Text                                                                
VII. CICS Technical Notes.                                              
 1. Text                                                                
VIII. Windows NT Technical Notes.                                       
 1. Text                                                                
IX.  z/VM Technical Notes.                                              
 1. Text                                                                
X.    Email notes.                                                      
 1. Text                                                                
XI.   Incompatibilities and Installation of MXG vv.yy.                  
 1. Incompatibilities introduced in MXG 30.30 (since MXG 29.29):        
    See CHANGES.                                                        
 2. Installation and re-installation procedures are described in detail 
    in member INSTALL (separate sections for each platform, z/OS, WIN,  
    or *nix), with examples of common Errors/Warnings messages a new MXG
    user might encounter, and in member JCLINSTT for SAS V9.2 or member 
    JCLINSTW for WPS. INSTALL also shows how to read SMF data on PCs/nix
    using the FTP ACCESS METHOD.                                        
XII.  Online Documentation of MXG Software.                             
    MXG Documentation is now described in member DOCUMENT.              
XIIV. Changes Log                                                       
--------------------------Changes Log---------------------------------  
 You MUST read each Change description to determine if a Change will    
 impact your site. All changes have been made in this MXG Library.      
 Member CHANGES always identifies the actual version and release of     
 MXG Software that is contained in that library.                        
 The CHANGES selection on our homepage at            
 is always the most current information on MXG Software status,         
 and is frequently updated.                                             
 Important changes are also posted to the MXG-L ListServer, which is    
 also described by a selection on the homepage.  Please subscribe.      
 The actual code implementation of some changes in MXG SOURCLIB may be  
 different than described in the change text (which might have printed  
 only the critical part of the correction that need be made by users).  
 Scan each source member named in any impacting change for any comments 
 at the beginning of the member for additional documentation, since the 
 documentation of new datasets, variables, validation status, and notes,
 are often found in comments in the source members.                     
Alphabetical list of important changes after MXG VV.RR in MXG VV.RR+1:  
  Member   Change    Description                                        
  See Member CHANGES or CHANGESS in your MXG Source Library, or         
  on the homepage                                          
Inverse chronological list of all Changes:                              
Changes 30.yyy thru 30.001 are contained in member CHANGES.