***********************NEWSLETTER FIFTY-NINE****************************
          MXG NEWSLETTER NUMBER FIFTY-NINE, Jan 17, 2012                
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 is dated Jan 23, 2012.            
    You can always use this form                                                           
    to request the ftp download instructions for the current version.   
 1. The current version is MXG 29.29, dated Jan 23, 2012.               
    See CHANGES member of MXG Source, or    
II.  MXG Technical Notes                                                
 1.  TYPE 30 CPU times in MXG variables come directly from IBM fields:  
        MXG Variable NAME     IBM SMF Manual Field NAME                 
           CPISRBTM              SMF30ISB                               
           CPITCBTM              SMF30ISB                               
           CPUHPTTM              SMF30HPT                               
           CPUIIPTM              SMF30IIP                               
           CPURCTTM              SMF30RCT                               
           CPUSRBTM              SMF30CPS                               
           CPUTCBTM              SMF30CPT                               
           CPUTM is the SUM of the above seven CP Engine times.         
           CPUZIPTM              SMF30_TIME_ON_ZIIP                     
             CPUZIPTM (zIIP/zAAP Engine CPU time) is NEVER combined with
             the CP ENGINE CPU times variables (original CPU variables.)
           CPUZIETM              SMF30_ELIGIBLE_TIME_ZIIP_ON_CP         
             CPUZIETM is already included in the CPUTM because it is the
             CPU time CONSUMED on the CP engines.                       
III. MVS, a/k/a z/OS, Technical Notes.                                  
 4. APAR PM54994 for SMF 119 record has been opened; the NIIITIME field 
    contains invalid '0000000F000000000'x and '000000001C000000'X values
    in subtype 19 and 21 records.                                       
 3. IBM's TRSMAIN program became AMATERSE in z/OS 1.9: "In z/OS Release 
    1.9 the TRSMAIN program has been added to the BCP element of z/OS,  
    and it has been redesigned to support large format sequential data  
    sets. This program has also been rewritten to follow IBM programming
    conventions.  The new utility is called AMATERSE.  TRSMAIN is       
    shipped as an alias entry point to AMATERSE.  When the TRSMAIN entry
    point of AMATERSE is invoked, ddnames INFILE and OUTFILE remain as  
    the defaults, so little or no change to JCL should be required to   
    take advantage of AMATERSE. The ddnames INFILE and OUTFILE that were
    required by the TRSMAIN utility are replaced by SYSUT1 and SYSUT2   
    respectively when the utility is called as AMATERSE."               
    All MXG unterse examples use PGM=TRSMAIN and INFILE/OUTFILE DDs, and
    since using PGM=TRSMAIN does execute the new rewritten program, the 
    examples were not changed to use PGM=AMATERSE (I assume you'll find 
    this technical note if you search for AMATERSE instead of TRSMAIN). 
 2. APAR OA37002 reports MKCRTIME and MKLCTIME in SMF 42 subtype 22     
    are on GMT zone when the event creating the record is an ADDVRS     
    event, but are on local time zone when the event is an DELETEVRS.   
    No PTF forthcoming, resolution is FIN ("Fixed in Next").            
 1. APAR PM47067 corrects WebSphere Version 8 SMF 120 Subtype 1 error   
    that had zero bytes in the SM120SDR, SM120CDR and SM1290EGR fields. 
IV.   DB2 Technical Notes.                                              
V.   IMS Technical Notes.                                               
 2.  How do you enable creation of the IMS56FA Transaction Record?      
     IMS logs statistical information about the transactions within a   
     unit of recovery (work done by an application program between sync 
     points) in log record X'56FA' for non-message-driven applications, 
     or when either:                                                    
     -The keyword MODE=SNGL is specified in the TRANSACT macro          
     -The CMTMODE(SNGL) parameter is specified on a CREATE TRAN or      
      UPDATE TRAN command                                               
     IMS logs statistical information about the transactions after each 
     message in log record X'56FA' for message-driven applications when 
     -The keyword MODE=MULT is specified in the TRANSACT macro          
     -The CMTMODE(MULT) parameter is specified on a CREATE TRAN or      
      UPDATE TRAN command                                               
     You can enable or disable this logging on a program basis for      
     non-message driven applications, and on a                          
     transaction-by-transaction basis for message-driven applications.  
     Use the following commands to enable or disable this logging on a  
     transaction-by-transaction basis:                                  
     -For an existing transaction, issue the UPDATE TRAN or UPDATE      
      TRANDESC command and specify the new TRANSTAT() parameter.        
     -For a new transaction, issue the CREATE TRAN or CREATE TRANDESC   
      command and specify the new TRANSTAT() parameter.                 
     To enable or disable this logging on a program basis:              
     -For an existing application program, issue the UPDATE PGM or      
      UPDATE PGMDESC command and specify the new TRANSTAT() parameter.  
     -For a new application program, issue the CREATE PGM or CREATE     
      PGMDESC command and specify the new TRANSTAT() parameter.         
     You can enable or disable this logging globally during system      
     definition by specifying a new parameter, TRANSTAT= Y or N, in the 
     Diagnostics Statistics section of the new DFSDFxxx PROCLIB member. 
     This setting applies to any transactions and application programs  
     that are created with the system definition process.               
     Any transactions or application programs that are created after an 
     IMS cold start using the online change process or the Destination  
     Creation exit routine (DFSINSX0, formerly called the Output        
     Creation exit routine) inherit the TRANSTAT= parameter setting that
     is specified in the DIAGNOSTICS_STATISTICS section of the DFSDFxxx 
     PROCLIB member.                                                    
     To determine whether or not this logging is enabled for a given    
     transaction or application program, issue one of the following     
     type-2 commands:                                                   
      QUERY TRAN                                                        
      QUERY TRANDESC                                                    
      QUERY PGM                                                         
      QUERY PGMDESC                                                     
 1.  IBM IMS log record IMS56FA comparison with BMC's IMF CIMSTRAN.     
  BOTH IMS VERSION 10 AND 11.                                           
  A. CPU TIME and Transaction Count Comparisons:                        
     BMC IMF created 13,852 transaction records and                     
         IMF created      6 BMP records.                                
     IBM IMS56FA had 13,831 records that had MSG GU (NMSGPROC GT 0)     
     and IMS56FA had 22,252 BMP records.                                
     The   IMS56FA  TRAN CPU time was 329.52 in those 13,831 "TRAN"s    
       and IMS56FA  BMP  CPU time was  15.61 in those 22,252 "BMP"s     
       and IMS56FA "MXG" CPU time was  12.00 captured in ACCUM/RESET,   
     Total IMS56FA  CPU TIME time was 357.15 seconds                    
     Total CIMSTRAN IMF TRAN time was 323.53 in those 13852 "TRAN"s     
      and  CIMSTRAN IMF BMP time was    0.02 in those     6 "BMP"s      
     Total CIMSTRAN CPU TIME time was 323.55.                           
     Here is the source of the IMS56FA "MXG" IMS CPU Time:              
     If there are Message GET Unique's in a record, NMSGPROC=1 is set as
     this is a "real" transaction record and NMSGPROC should be used to 
     to count transactions.  NMSGPROC=0 if there were no MSG GU and this
     is a "NOT-TRAN" record.  Of the 49,778 records, 13,831 were "TRAN".
     Then, 22,256 were BMPs (a "NOT-TRAN", because NMSGPROC=0, TRANSACT 
     name is blank, and ARRVTIME is not populated; there were the above 
     15.61 CPU Seconds in the BMP records.  The remaining 13,691 56FA   
     records totaled 297.11 more CPU seconds, but if added to the other 
     56FA CPU times the 56FA would have captured TWICE the IMF CPU time,
     and the IFA CPU Time has always matched the IMS 07 Program CPU Time
     so something else is involved.                                     
     When all of the 56FA records are sequenced by TPOASN and ARRVTIME, 
     there were pairs of records for almost every transaction, sometimes
     there were more than two records written.  The last always has     
     NMSGPROC=0, a "NOT-TRAN" record, while the first thru penultimate  
     have NMSGPROC=1 and are "TRAN" records.  According to IBM Support  
     for IMS, these "NOT-TRAN" (second) records:                        
       Can represents the processing done by the application after it   
       received the STATUSQC call for the GU to the IOPCB, indicating   
       that there are no further messages and it should terminate.      
       Though no messages were processed, IMS still reports the         
       processing done so that you can capture any cleanup processing   
       done by the application. These "NOT-TRAN" records have values of 
       TPMGU=0, TPLTERM=blanks, TPINUTC=0, TPINDATE=X'0000000F', and    
       TPINTIME=X'0000000F', meaning that no input message was processed
       during this commit scope, most likely due to QC status on the    
       last message GU that was issued.  In this case, the TPCPTERM bit 
       would be on in flag byte TPCPFLGS.  This would be a 56FA record  
       written during application termination after the application     
       terminated upon receiving QC status from its last message GU call
       issued.  However, this type of 56FA log record should not be     
       ignored because it still represents processing time performed by 
       the application.  The application could have continued to do some
       work after receiving QC status but before terminating and        
       returning to IMS.                                                
     So pairs of IMS56FA records were matched up with their IMF record. 
     The IMS56FA "TRAN" (first) IMSCPUTM is ALWAYS slightly larger than 
     the CPUTM in the IMF transaction (typically about 1 millisecond, so
     IBM's exit point for their transaction record is later than the IMS
     exit that IMF uses!)                                               
     By looking at the sequenced transactions records, the "NOT-TRAN"   
     (second) records come with two different contents:                 
     -Many have IMSCPUTM that is slightly LARGER than the "TRAN" record:
      this flags that this record's CPU Time is ACCUMULATED, and so its 
      CPU Time cannot be used "AS-IS", as it contains (DUPLICATES!) the 
      CPU time in the preceding "TRAN" record.                          
     -Many have an IMSCPUTM that is much LESS than the time in the first
      record: this flags that this record's CPU Time was RESET, so the  
      CPU Time in these "NOT-TRAN" records are valid.                   
     Here are the three sequenced CPUTM values in three records for five
     transactions; 1,4 are RESETs and 2,3,5 are ACCUMULATED:            
        Transact:      1           2         3         4         5      
        IMF         0.133260   0.005130  0.011920  0.007720  0.030480   
        56FA TRAN   0.134220   0.005575  0.013168  0.008525  0.031700   
           Second   0.004140   0.006284  0.013675  0.000817  0.033420   
     So, the new ASUM56FA program sorts IMS56FA data, and assumes that  
     if the NOT-TRAN record's IMSCPUTM was LESS than the TRAN record,   
     then the CPU clock had been RESET so that value of IMSCPUTM is     
     valid and OUTPUT, but if the NOT-TRAN record's IMSCPUTM was MORE   
     than the TRAN record, then that record was ACCUMULATED and so the  
     delta CPU time from the TRAN (first) record's (stored) IMSCPUTM to 
     this NOT-TRAN (second) record's IMSCPUTM is calculated and OUTPUT. 
     The sort order is STIMSID IMSUSID TPOASN ARRVTIME ENDTIME with     
     each "pair" having the same TPOASN and ARRVTIME values.            
     The resultant IMSCPUTM CPU time totals in ASUM56FA dataset are:    
                 ==NOT-TRAN==    ====TRAN====    ====Total====          
                 Records   CPU   Records   CPU   Records   CPU          
      BMP        22252   15.61       0           22252   15.61          
      ACCUM       8435    8.73      11     .03    8446    8.77          
      RESET       5255    3.26      14     .02    5269    3.29          
      FIRST          0           13690  325.29   13690  325.29          
      SINGLE         4     .01     116    4.18     121    4.19          
        CPU Totals       27.61          329.52          357.15          
     By sorting and sequencing to identify RESET from ACCUMULATED, an   
     additional 12 seconds of IMS CPU Time was captured; member ASUM56FA
     can be included after TYPEIMST to capture this additional CPU time,
     but that could be a lot of CPU and I/O time to post process IMS56FA
     to capture a few extra seconds.                                    
     So, if you can live without that small amount of CPU time from the 
     RESETs and ACCUMs, you can minimize the MXG resource requirements  
     for TYPEIMST, using this new EXAMPLE in member TYPEIMST's comments 
     that will create ONLY the IMS56FA dataset, and only keeps the 56FA 
     records with NMSGPROG GE 1 OR BMP='Y'.                             
      // EXEC MXGSASV9                                                  
      //IMSLOG   DD DSN=YOUR.IMSLOG.DATA,DISP=SHR                       
      //IMS56FA  DD DSN=YOUR.IMS.IMS56FA.PDB,DISP=(,CATLG)....          
      //SYSIN    DD *                                                   
       %LET MACKEEP=                                                    
           MACRO _IMSVERS 10.1  %                                       
           MACRO _WIMS56G  &WIMS56G..IMS56FA %                          
           MACRO _EIMS56G                                               
             IF NMSGPROC GE 1 OR BMP='Y' THEN OUTPUT _WIMS56G;          
       %LET WIMS56G=IMS56FA;                                            
       %LET MACIMSH=                                                    
          %QUOTE( IF LCODE=56X AND TPCPSSTY='FA'X; ) ;                  
       %INCLUDE SOURCLIB(TYPEIMST);                                     
  B. CALL differences and equalities:                                   
     There are exact matches of total call counts between IMF and 56FA  
     for some Database counters: DELETE, INSERT, REPLACE, PURGE, and for
     these Message counters GET NEXT, GET UNIQUE, and INSERT.  There are
     more buckets for many more call types in 56FA than in IMF, but the 
     totals show the counts of calls match quite closely:               
                   56FA     GET      GET    GETHOLD     56FA      IMF   
                   CALL    HOLD   PARENT    PARENT     TOTAL    TOTAL   
        DB GN   125,015     767  225,793    10,417   361,292  363,008   
        DB GU   234,519  37,101                      271,620  273,809   
                                              total: 632,912  636,817   
  C. I/O Reads and Writes:                                              
     IMF provides separate counts for Reads/Writes and KEY/NO-KEP while 
     the 56FA provides total Reads and total Writes, that match:        
     IMF I/O Counts                                                     
        Reads    Reads     Reads     Writes    Writes    Writes         
        KEY      NO-KEY    Total     KEY       NO-KEY    Total    TOTAL 
       14,203   43,466    57,669     1,163    19,952    21,015    78,684
     IMS 56FA Counts  VSAM Reads                   VSAM Writes          
                          57,629                        21,090    78,719
  D.  Miscellaneous                                                     
      IMF provides CHARACTER counts transmitted and Virtual Storage used
      metrics that are not provided in IMS56FA.                         
      IMF provides 11 components of CPUTM, 56FA has only the one total. 
      This Log had 260,000 records, 60MB of only FAx and 56x records.   
      IMF FAx took 15MB, IBM 56FA took 25MB, and there were 20MB of the 
      other unneeded 56x subtypes (5600: 10MB, 5607: 5MB, 5612: 5MB),   
      so you should select only LCODE='56FA'x records when you create   
      the log file that MXG will read, if you only want IMS56FA data.   
VI.  SAS Technical Notes.                                               
 3.  To convert a SAS dataset to EXCEL, use the FILE pulldown and then  
     select EXPORT, which usually works, but not when there are too many
     variables for EXCEL to handle.  This alternative has worked so far:
       ODS HTML BODY='d:\db2acct.html';                                 
       PROC PRINT SPLIT='*' DATA=PDB.DB2ACCT;                           
       ODS HTML CLOSE;                                                  
     When the HTML window opens up, right click on the window and one of
     the options given is 'EXPORT TO EXCEL'; click on that and you have 
     an EXCEL spreadsheet.                                              
 2.  SAS Problem Note 43996:  An error occurs when you run Merrill      
     Consultants' MXG software with SASŪ 9.2 reports error messages     
       No MKLEs  found                                                  
       ERROR: VM 1319: The PCE address=1C351414 and MEMORY= address=    
     might occur if a job contain macros that perform only text         
     substitution (that is, with no conditional logic), such as jobs    
     that use MXG software, with z/OS SAS.                              
     The circumvention is to NOT use the debugging-only MPRINT option.  
 1.  A confusing quirk of the maximum integer value that can be stored  
     in SAS variables with stored lengths less than 8 bytes was seen and
     resolved as a "feature" when the value is an exact power of two.   
     The table of maximum integer versus stored length is in Newsletter 
     TWENTY-EIGHT - Find "3. How can I have 10 digits...." and read that
     note if you are not familiar with how SAS stores numeric variables.
     I discovered that the value of 34,359,738,368 was not truncated in 
     ANY length variable, even a variable with length 2 on z/OS or with 
     length 3 on PC/unix.  The reason is that the value is exactly 32GB,
     and for values that are 2**X, the SAS floating point representation
       PC/unix: 3 bytes, 11-bit exponent, 22-bit mantissa, 1 sign bit   
       z/OS:    2 bytes,  7-bit exponent,  8-bit mantissa, 1 sign bit   
     is sufficient for full representation.  But, storing a value that  
     is one less than 32GB, 34,359,738,367, the result is truncated:    
          length       value        lost in truncation                  
            8      34,359,738,367            0                          
            7      34,359,738,367            0                          
            6      34,359,738,367            0                          
            5      34,359,738,304           63                          
            4      34,359,721,984       16,383                          
            3      34,359,544,064      194,303                          
          length       value        lost in truncation                  
            8      34,359,738,367            0                          
            7      34,359,738,367            0                          
            6      34,359,738,367            0                          
            5      34,359,738,352           15                          
            4      34,359,734,272        3,095                          
            3      34,358,689,792    1,048,575                          
            2      34,091,302,912  268,435,455                          
     So, the table of maximum integer value is a "guaranteed" safe table
     but there are exceptions noted above.                              
VI.A.  WPS Technical Notes.                                             
 1. Text                                                                
VII. CICS Technical Notes.                                              
 1. APAR PM43494 for CICS Transaction Gateway corrects an error that    
    wrote multiple statistics records to both the log and the SMF file, 
    when a normal shutdown of CICS TG was started while there was still 
    work running in progress.  Now, only one record will be written.    
VIII. Windows NT Technical Notes.                                       
 1. Text                                                                
IX.  z/VM Technical Notes.                                              
X.    Email notes.                                                      
 1. Text                                                                
XI.   Incompatibilities and Installation of MXG vv.yy.                  
 1. Incompatibilities introduced in MXG 29.29 (since MXG 28.28):        
    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 29.yyy thru 29.001 are contained in member CHANGES.