****************NEWSLETTER TWENTY-THREE*********************************
              MXG NEWSLETTER NUMBER TWENTY-THREE March 15, 1993         
Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE
                         TABLE OF CONTENTS                              
I.    MXG Version 10.10 Announcement, Status and Enhancements          2
II.   Incompatibilities, Installation, and Space for MXG 10.10         4
III.  Documentation of MXG Software                                    6
IV.   MXG  Technical Notes                                              
      1. MXG Tape Mount Monitor with MIM                               7
      2. MGBYTES format.                                               7
V.    MVS  Technical Notes                                              
      1. APAR OY56235 - JES2 type 26 invalid times fill SPIN library.  7
      2. APAR OY57134 - IFASMFDP Blocksize correction                  7
      3. APAR OY57971 - TYPE 73 two CHPID '00', no CHPID 'FF'x         7
      4. SMF/RMF Enhancements in MVS/ESA 4.3 and DFSMS 1.1             8
      5. ISOGON's TICTOC product Zap PMR0011.                         10
      6. "MVS/ESA Resource Accounting - What's Captured Where"        11
      6. "Z/OS Resource Accounting - What's Captured Where"        11   
VI.   VM   Technical Notes                                              
      1. APAR VM52395 corrects invalid VM type 01 account records.    24
VII.  CICS Technical Notes                                              
      1. Correction to IBM Document ID Q504977 "Main Task" CPU time.  24
VIII. SAS Technical Notes                                               
      1. Technical note on BUILDPDB virtual storage usage.            24
      2. MEMSIZE and REGION relationship.                             25
      3. SASOPT73 can restrict your SAS options.                      25
      4. Use SMS Guaranteed Space for multi-volume SAS library.       25
      5. SAS 6.07 CMS requires GLOBAL statement.                      26
      6. SAS 6.07 ZAP Z6074721 corrects 0C4 with double ampersand.    26
      7. PROC COPY zero observation dataset ABENDs.                   26
      8. INVALID HEADER error.                                        26
      9. Nested parenthesis in SUM results in invalid values.         26
     10. PROC GPLOT "SAS SYSTEM STOPPED" error corrected by Z6071258. 27
     11. SAS 6.07 CPU loop or Wait loop if //WORK has UNIT=(SYSDA,3)  27
     12. XSWISS font name changed to SWISS.                           27
     13. 0C4 ABEND in Data Step compiler V6-SYS-DATA-5266             27
     14. SAS V6-SYS-FILE-4673 corrects CRITICAL ERROR IN VTOC         27
     15. MXGSAS sample JCL Procedure provided.                        27
IX.   Change Log                                                      28
      Alphabetical list of important changes                          28
      Changes 10.323 thru 10.105                                   32-80
I.    MXG Software Status and Enhancements:                             
  MXG 10.10 is the Production Version of MXG 10 (i.e., the version that 
  we "Produce" for all sites), dated March 15, 1993, and it was shipped 
  to you along with this MXG Technical Newsletter number TWENTY-THREE.  
  MXG 10.10 is a major revision, with many latent enhancements, and near
  transparent installation.  Sites with normal MXG tailoring should need
  less than 2 hours to unload, tailor, and submit the test jobstreams.  
  Make sure you read the COMPATIBILITY warning in Installation section  
  of this Newsletter (repeated, always, in member CHANGES).             
  Check member CHANGES in MXG Version 10.10 for last minute additions!  
  Versions 10.7-10.9 were skipped to make the Production Version 10.10. 
  Versions 4.4 thru 9.9 were truly the n.n release, but I now plan to   
  number all future Production releases equal to the version number!    
  Major enhancements added in MXG 10.10, that were not in MXG 10.6:     
    Support for OpenEdition MVS, OMVS, RMF record enhancements.         
    Preliminary RS6000 AIX VMSTAT,IOSTAT,PS command processing          
    GMT offset, GMTOFFTM, available in MVS/ESA 4.3 RMF records.         
    DCOLLECT options SMSDATA creates nine new SMS construct datasets.   
    RMF reports can be produced from MXG TYPE70xx datasets.             
    Additional online MXG documentation members (ADOC and ACHAP).       
  Major enhancements added in MXG 10.6, that were not in MXG 10.5:      
    Support for Empact's Hipercache SMF record.                         
    Support for IMF Release 2.8.                                        
    Support for Oracle                                     
    Support for IBM 3495 Tape Library Dataserver's type 94 SMF record.  
    Support for (incompatible) Omegamon/CICS DATACOM SPE PTF QOC0109.   
    Support for STOPX37 Release 3.5.                                    
    Support for Empact's POOL-DASD user SMF record.                     
    Support for Candle's IMS Transaction Reporting Facility, ITRF.      
    Support for Landmark for CICS's Release 9 and Release 1.0.          
    IBM-like RMF reports can be created with new ANALRMFR.              
    Additional HOGAN application fields added in CICSTRAN               
    HP's MPE data or HP/UX Unix data are both supported by TYPEHPCS     
    SLR-like IMS processing for sites with heavy fast-path in TYPESLRI  
    Additional CMF "type 240" subtypes supported in TYPECMF             
  Major enhancements added in MXG 10.5, that were not in MXG 10.4:      
    Support for MVS/ESA 4.3 and RMF 4.3.                                
    Support for NPM Release 1.6.                                        
    Support for NETSPY Release 4.3 and LANSPY 1.1.                      
    Support for IDMS Release 12 PM records confirmed.                   
  Major enhancements added in MXG 10.4, that were not in MXG 10.3:      
    Support for ESCOM Multi-Image Facility (EMIF)                       
    Support for VM/ESA 2.0                                              
    Validation of support for Velocity Software's XAMAP History files.  
  Major enhancements added in MXG 10.3, that were not in MXG 10.2:      
    Support for NPM 1.5.1 incompatible changes.                         
    Correction of MXG-10.2-only error in ASUM70PR                       
    Support for DFSORT Release 12 new fields.                           
    Cleanup of all reported errors in prior prereleases.                
    Toleration support for VM/ESA 2.0 MONWRITE data.                    
  Major enhancements added in MXG 10.2:                                 
    Powerful new "_L" and "_K" macro architecture allows full tailoring 
      of MXG datasets (variables kept/dropped, compression, blocksize,  
      the DDNAME to which the dataset is written, etc.).                
    Support for DB2 Trace IFCID 172/ 177 added, Audit/SQL reports fixed.
    Support for FACOM AIM Version 12 type 116 SMF record changes.       
    Support for FACOM PDLF Type 127 for MSP/EX.                         
    Support for HP Unix (HP/UX) PCS Performance Collection System data  
    Support for IBM TCP/IP Version 2 Release 2 SMF record.              
    Support for IBM TIRS type 96 SMF record coded.                      
    Support for Network Alert APAR OY49717 in SMF Type 37.              
    Support for OMEGAMON II for VTAM V150 user SMF record coded.        
    Support for OPC changes.                                            
    Support for SAP Accounting data in CICS type 110 or journal file.   
    Support for SIMWARE SIM/XFER VTAM user SMF record.                  
    Support for TMS Billing-by-dataset using enhanced DSNBRECD dataset. 
    Support for VSE DOS POWER Version 4.2                               
    Support for Xerox Printer's SFS Status File System records.         
    Support for XCOM 6.2 Version 2.2.2G SMF record.                     
    Alert that Legent's MIM can corrupt MXG Tape Mount counting.        
    "Appended" IMS Log enhancements; has now been tested with IMS 2.2.  
    Continued enhancement of ANALDB2R for DB2 reports.                  
  Major enhancements added in MXG 10.1 but not listed in Newsletter 22: 
    OPC/A log processing major revision, additional datasets created.   
    Verstand's product, TTX, is now included in MXG Software.           
    Support for AS400 V2R1M0 added, and AS400 support was revised.      
    NPM 1.5.1 subtypes 144-150 (NPMEVX25 dataset) errors were corrected.
    Sample IEFU83 exit to filter type 40 records for tape-only added.   
  Major enhancements added in MXG 10.1 that were listed in NL 22:       
   Required for CICS/ESA 3.3,                                           
   Required for VM/ESA 1.1.1,                                           
   Required for TYPEIMS users; major revision in IMS log processing.    
   Strongly recommended for DB2 sites, because it:                      
      - has significant corrections in ANALDB2R reporting,              
      - has speeded up MXG DB2 processing and reduced WORK space needed,
      - allows DB2ACCT direct to tape for sites with large DB2 activity,
      - has new ASUMDB2A to summarize and reduce size of DB2ACCT.       
      - has MVS Account fields added to DB2ACCT (DB2 2.3).              
   Offers support for these new products or releases:                   
     Support for AICorp's KBMS user SMF record.                         
     Support for Amdahl's APAF replacement for MDFTRACK.                
     Support for Blue Line's Vital Signs for VTAM type 28.              
     Support for Fujitsu's FACOM MSP/EX (incompatible) SMF records.     
     Support for MVS/ESA 4.2 Dynamic I/O Reconfig in MXG Tape Monitor.  
     Support for NETSPY Release 4.2 added.                              
     Support for NETSPY Token-Ring records added.                       
     Support for ROSCOE Release 5.7 changes to SMF data.                
     Support for RSD's WSF/WSF2 Release 3.4.1.                          
     Support for SPMS 1.2.13 incompatible changes.                      
     Support for STOPX37 Release 3.4.                                   
     Support for Software Ag "Natural Process" SMF record.              
     Support for System Center's NETMASTER type 37 SMF records.         
     Support for The Network Director North Ridge Software              
     Support for UNIX iostat and vmstat commands from ULTRIX.           
     ASMVTOC avoids 213/314 abends reading VTOC of TPF or VM  volumes.  
     MINTIME=,MAXTIME= parameters added to VMXGSUM.                     
     MXG Tape Mount Monitor supports MVS/ESA dynamic reconfiguration.   
     TAPE3490 (3490s allocated) added to PDB.STEPS/JOBS.                
    Each of those enhancements are described in the Change Log, below.  
    The following table lists announced availability dates for the IBM  
    product, and the corresponding Version of MXG required to support   
    that IBM product.                                                   
                                       Availability     MXG Version     
      Product Name                     Date              Required       
      MVS/370, MVS/XA (all)            long ago             8.8         
      RMF 4.1.2 (for MVS/ESA 3.1.3)    Sep  7, 1990.        8.8         
      RMF 4.2   (for MVS/ESA 4.1)      Oct 26, 1990.        8.8         
      MVS/ESA 4.1                      Oct 26, 1990.        8.8         
      MVS/ESA 4.2                      Mar 29, 1991.        9.9         
      RMF 4.2.1 (for MVS/ESA 4.2)      Mar 29, 1991.        9.9         
      MVS/ESA 4.2.2                    Aug     1991.        9.9         
      RMF 4.2.2 (for MVS/ESA 4.2.2     Aug     1991.        9.9         
      MVS/ESA 4.3                      Mar 23  1993.       10.10        
      RMF 4.3.0 (for MVS/ESA 4.3       Mar 23  1993.       10.10        
      CICS/ESA 3.1                             1990         8.8         
      CICS/ESA 3.2                     Jun 28, 1991.        9.9         
      CICS/ESA 3.3                     Mar 28, 1992.       10.1         
      DB2 2.2.0                                1990         8.8         
      DB2 2.3.0                        Oct 28, 1991.       10.1         
      DFSMS 1.1                        Mar 23, 1993        10.10        
      VM/ESA  1.1.0 (370 Feature)      Oct 26, 1990.        8.8         
      VM/ESA  1.1.0 (ESA Feature)      Mar 29, 1991.        8.8         
      VM/ESA  1.1.1                    Dec 27, 1991.       10.1         
      VM/ESA  2.0                      Dec 23, 1992.       10.4         
II.   Incompatibilities, Installation, and Space Requirements.          
 1. Incompatibilities in MXG 10.10 which will cause syntax errors:      
      a.  If these members exist in your USERID.SOURCLIB, then you must 
          replace them, by re-tailoring your changes starting with the  
          new MXG 10.10 member:                                         
          These members defined the DDNAME to which MXG sent certain    
          datasets (eg., MACRO _CICTRAN CICSTRAN % set the DDname for   
          DATA _CICTRAN.CICSTRAN).  The new "_L" architecture provides  
          the same function with different syntax (eg., now the macro   
          _LCICTRN defines both the DDNAME (LIBREF) and dataset name).  
          Change 10.175 provides specific details of what old-names have
          to be changed to what new-names for these incompatibly changed
      b.  If you had tailored BUILDPDB/3 to create TYPETMNT (the MXG    
          Tape Mount Monitor records), you will need to remove your     
          tailoring in members EXPDBINC,EXPDBVAR,EXPDBCDE,EXPDBOUT.     
          In MXG 10.10 TYPETMNT is automatically created by BUILDPDB/3. 
    Sites migrating to MXG 10.10 from MXG 9.9 or later should find no   
    other compatibility issues.                                         
    Sites jumping to 10.10 from an MXG version earlier than 9.9 must    
    read the compatibility section of the installation instructions in  
    MXG Newsletter TWENTY-ONE pp 37-38 (also in member NEWSLTRS).       
 2. Installation and re-installation procedures are described in detail 
    in member INSTALL, but they are summarized here:                    
     a. Allocate a 70-cyl PDS:  MXG.V1010.MXG.SOURCLIB, & use IEBUPDTE  
        to read the MXG tape to create the 1800+ member Source Library. 
     b. Allocate a 1-cyl PDS:  MXG.V1010.USERID.SOURCLIB for your site  
        "Installation Tailoring" Source Library.  Installation specific 
        tailoring (like telling MXG your shift hours, which performance 
        groups are TSO, CICS, etc.) is done by copying and modifying MXG
        source members into V104.USERID.SOURCLIB.                       
     c. Allocate a 1-cyl SAS Data Library:  MXG.V1010.MXG.FORMATS and   
        execute SAS to create the library of Formats required by MXG.   
        Sample JCL for the above three steps is in member JCLINSTL.     
     d. If re-installing MXG, copy your existing USERID.SOURCLIB library
        members into the MXG.V1010.USERID.SOURCLIB. Then examine the set
        of IMACs that were changed incompatibly (see member CHANGES).   
        If any members in MXG.V1010.USERID.SOURCLIB are in that list,   
        you must reinstall your site's tailoring for that IMAC, starting
        with the IMAC member from the MXG 10.10 Source Library.         
     d. If this is the initial install of MXG, tailor these members into
        your MXG.V1010.USERID.SOURCLIB tailoring library:               
          IMACACCT (Account Length),                                    
          IMACSHFT (Shift Definitions),                                 
          IMACWORK (Performance Group to Workload mapping), and         
          IMACSPIN (for BUILDPDB).                                      
        Each IMAC member is self-documenting, and IMACAAAA is the index 
        of all of the IMACs.  You should at least scan IMACAAAA to see  
        the acronyms MXG uses for the many products MXG supports.       
     e. EDIT and submit member JCLTEST6 (JCLTEST if still on SAS 5.18)  
        to verify that your tailoring did not create any errors.        
     f. EDIT and submit JCLPDB to create a Daily PDB for testing.  Or   
        use the TYPE.... members to process specific data sources, use  
        the ANAL.... members for report examples, the GRAF.... members  
        for SAS/GRAPH reports.                                          
     You have now installed MXG 10.10 in its own set of libraries. When 
     parallel testing is complete and are ready to implement MXG 10.10  
     in production, rename your three current MXG Production Libraries  
     and and rename the MXG.V1010.x.y libraries to their Production     
     Again, detailed installation instructions are in member INSTALL    
Always read comments in the CHANGES member for compatibility issues, as 
well as for any last minute changes.                                    
Whenever you install changes or test a new version of MXG (or even your 
own reports), be extra careful to look on the SAS log for any real error
conditions. Search for all occurrences of "ERROR:" and  "ERROR :"  and  
"UNINITIALIZED" and "NOT CATLGD", as they may indicate a serious error. 
A PROC PRINT and a PROC MEANS of each new MXG-built SAS dataset can help
you to understand their contents, and should be used to examine any     
unusually large, negative, or suspicious values.  Print all variables in
the dataset, and read the variable's descriptions in its ADOC member.   
III.  Documentation of MXG Software.                                    
Member CHANGES always contains the version number of MXG Software, and  
it lists changes that were installed in that version.  Members named    
CHANGEnn are the CHANGES member from MXG Version "nn".   Each change in 
MXG software is documented by a Change number and text.  The text of    
each Change identifies the member(s) that were added or altered by that 
change. Documentation (especially for new product's support) is often   
also found in comments at the beginning of those members listed in the  
change entry.  The CHANGE member is designed to be read online (with SPF
BROWSE); you can search for specific product name references (CICS,     
MVS/ESA, etc.), or the MXG member name.                                 
Member NEWSLTRS contains the text of all newsletters (up through the    
newsletter that accompanied that MXG release). You can search NEWSLTRS  
for product name or acronym to find the technical notes, APARs, etc.    
from all MXG newsletters.  The Change Log pages of each Newsletter are  
in member CHANGES or CHANGEnn and are not repeated in member NEWSLTRS.  
Member DOCVER lists alphabetically ALL datasets and variables that can  
be build by this MXG Software Version.  "Delta-documentation" between   
MXG versions, which lists only those datasets and variables that were   
changed by version "nn" is found in DOCVERnn members for each version.  
Chapter FORTY in the MXG Guide and MXG Supplement books are still the   
primary documentation of MXG datasets and their variables (at least for 
those data sources that existed in 1987!).  This should be the first    
place you look for information about MXG variables and/or datasets.     
As each section of chapter FORTY is rewritten, it becomes an ADOCxxxx   
member of MXG.SOURCLIB, providing online documentation for product xxxx.
ADOCs contain alphabetic descriptions of datasets and variables, the    
instructions on how to enable that product, bibliography to the vendor  
documentation, sample PROC PRINT and PROC MEANS of real data, and the   
MXG member names that you use to process that product, etc.  Sounds     
great? It will be when finished - this is work in progress!             
Beginning with MXG 10.3, there has been an IMACxxxx member for every    
product supported by MXG.  Once you know the xxxx suffix for a product, 
you then know the names of all of the MXG members for that product:     
   IMACxxxx - Defines record IDs, and "_K,_L" macros for product xxxx.  
   ADOCxxxx - "Chapter FORTY" style dataset and variable documentation. 
   VMACxxxx - The "real" code member, often documentation in comments.  
   TYPExxxx - Standalone member to test or process product xxxx records.
   ASUMxxxx - Summarization example (only for some products)            
   TRNDxxxx - Trending example (only for some products)                 
   ANALxxxx - Reporting/analysis example (only for some products)       
   GRAFxxxx - SAS/GRAPH report example (only for some products)         
   EXyyyzzz - OUTPUT exit for each dataset.  There can be more than one 
              dataset per product.  The EX member name suffix yyyzzz is 
              the same as the suffix of "_L" and "_K" macros defined in 
              IMACxxxx for the product.  See further discussion under   
              "Using the MXG Exit Facilities".                          
   Member IMACAAAA is an index of all IMACs, and is the best place to   
   begin to find what xxxx suffix Merrill chose for which product!      
   You can often find additional documentation by searching members     
   NEWSLTRS, CHANGES, and the CHANGEnn members for the xxxx suffix.     
Finally, remember that MXG is source code, so you can often find your   
answer by BROWSE/EDIT of the source member, especially the VMACs that   
actually create the data set, or ANALs that analyze the MXG data sets.  
In most cases, the MXG Variable name is the IBM or Vendor's field or    
DSECT field name. In other cases, the DSECT field name is carried as a  
comment beside in the MXG INPUT statement to map field name to MXG's    
variable name.  MXG does expect that you will also have access to the   
vendor's documentation of the data records you are processing.          
The MXG Technical Newsletter is published aperiodically, one copy per   
licensed site, and describes changes and enhancements to the software,  
provides APARs and PTFs affecting MXG users, and provides tutorial      
information of interest to MXG users.                                   
IV.   MXG Technical Notes                                               
  1.  The MXG Tape Mount Monitor (in member ASMTMNT) seems to be very   
      low overhead - Freddie Arie reports that with 35,000 tape mounts  
      per month, the MXGTMNT task used only 6 CPU minutes per month!    
      MIM and other tape allocators that set Mount Pending can cause    
      mount records for non-mount events.  You can delete the non-mount 
      events that have TAPMNTTM less than 5 seconds.  See discussion in 
      Change 10.200.                                                    
  2.  The MXG-built format named MGBYTES does not stand for "megabytes",
      but is a format that prints the value of variables that contain   
      bytes in Kilobytes, Megabytes, Gigabytes, suffixing the numeric   
      value with KB, MB, GB as necessary.  This conversion does not     
      alter the true value of the variable, which always contains bytes.
      If a variable TESTSTOR has format MGBYTES (in member DOCVER or in 
      a PROC CONTENTS listing), you could see the exact number of bytes,
      without the KB, MB, etc., suffix, simply by printing the variable 
      using FORMAT TESTSTOR; to eliminate the assigned MGBYTES format.  
      Note that in many cases, a storage value with format MGBYTES may  
      have been stored as "frames" in the SMF record; MXG multiplied the
      number of frames by 4096 to convert the value to bytes, and then  
      applied MGBYTES format so it prints pretty!                       
V.    MVS Technical Notes                                               
  1.  APAR OY56235 PTFs UY85272 (JES 4.1) and UY85272 (JES 4.2) correct 
      invalid READTIME, JSTRTIME and JENDTIME values in TYPE26J2 and    
      PDB.JOBS. This IBM error can cause your SPIN library to fill, so  
      put this fix on!                                                  
  2.  APAR OY57134 corrects the IFASMFDP (SMF Dump program) so that it  
      no longer creates BLKSIZE=32767 by default.  Actual SMF records   
      can be no greater than 32760, and now BLKSIZE=32760 is the default
      set by IFASMFDP, because some utilities had problems with a value 
      of 32767.  (You could avoid the problem by explicitly specifying  
      the BLKSIZE=32760 in your JCL for the dump job, but this APAR     
      corrects the basic problem.)                                      
  3.  APAR OY57971 acknowledges that there are two '00'X CHPID values in
      TYPE73, and no 'FF'X CHPID value.                                 
  4.  SMF AND RMF ENHANCEMENTS ADDED IN MVS/ESA 4.3                     
SMF Global Recording Interval Synchronization now permits RMF and SMF   
interval records to be matched exactly.  You synchronize with the new   
SYNCVAL and INTVAL values in the SMFPRMxx member of your SYS1.PARMLIB.  
Variable SYNCTIME is added to the TYPE23, TYPE30_V (type 30 subtype 2   
and 3 intervals) and TYPE70xx thru TYPE79xx datasets.  SYNCTIME is the  
datetime value when the SMF Global Recording Interval ended, but it, and
INTBTIME/INTETIME in TYPE30_V are written from the GMT clock, so if you 
have a non-zero value for TIMEZONE in SYS1.PARMLIB(CLOCKxx), the records
contain a GMT value in SYNCTIME, INTBTIME, and INTETIME, but SMFTIME,   
Fortunately, the GMT offset in type 30 can be determinted from the old  
interval begin time, and SYNCTIME in RMF can be compared to SMFTIME to  
actually benefit us - with fuzzy logic that delta is now the retained   
variable GMTOFFTM, the GMT offset at the end of each RMF interval!      
Synchronization also changes the contents of the TYPE30_V interval data.
Formerly, INTETIME was the SMFTIME when the interval record was written,
but now, INTETIME is the time when the synchronized interval ended.  If 
the task is swapped out when an interval ends, the SMF record will not  
be written until later, when the task is swapped back in, and the begin 
time of the next interval record, INTBTIME, will be the time of the swap
swap in, and not set to the ending time of the previous interval.  This 
makes the INTBTIME to INTETIME duration the true duration during which  
the resources reported in the interval record were consumed, even though
the elapsed interval of execution can be much longer for swapped tasks. 
The original SMF30IST interval begin time is still recorded on the local
clock, but the new INTBTIME and INTETIME fields are on the GMT clock.   
Fortunatly, the difference between SMF30IST and INTBTIME fields is the  
GMT offset in effect, so MXG could correct INTBTIME and INTETIME back to
local, and furthermore, new variable GMTOFFTM is created and retained.  
The JES2 type 26 Purge Record was enhanced with these long-wanted data: 
  SUBMUSER -  Submitting USERID                                         
  NOTIFYND -  Job end execution notify NODE                             
  NOTIFYUS -  Job end execution notify USERID                           
  ACCOUNTn -  Job card accounting fields finally!!!                     
  NRACCTFL -  Number of accounting fields.                              
  LENACCTn -  Length of nth accounting field                            
  DUPJBDLY -  Flag that job was delayed due to Duplicate Job Name Hold  
  OFFLPURG -  Flag that this is a Spool Offload purge record.           
APPC Accounting in TYPE33_1 now contains JOB READTIME and STEPNAME.     
The new TYPE33_2 dataset contains resources at the conversation level,  
particularly needed if you use an APPC/MVS Server address space to      
process multiple conversations concurrently, since now you can collect  
information for each conversation in the server address space.          
New DFSMS TYPE42SR dataset provides response statistics for each Storage
Class for each interval, containing:                                    
  AVGCONMS- Average connect time per SSCH                               
  AVGCUQMS- Average CU queue time per SSCH                              
  AVGDISMS- Average disconnect time per SSCH                            
  AVGPNDMS- Average pending time per SSCH                               
  CACHCAND- Count of cache candidates                                   
  CACHHITS- Count of cache hits                                         
  IOCOUNTS- Total i/o count                                             
  RESPTIME- Average response time per SSCH                              
  STORCLAS- Average connect time per SSCH                               
  WRITCAND- Count of write candidates                                   
  WRITHITS- Count of write hits                                         
New DFSMS TYPE42DS dataset provides the above response statistics, but  
at the data set level, with additional details.                         
TYPE70s:  Variable SYNCTIME was added to all RMF datasets for matchup   
with SMF records, and new variable INTRVSYN flags if synchronization was
in effect.                                                              
TYPE71:  CPUPAGTM, the CPU time spent in page movement in central store.
When a particular type of frame (eg. below 16MB or nonreconfigurable) is
mandated by a request but is not found in the available frames, the real
storage manager uses a process called prefsteal to attempt to find a    
correct type of frame and move the contents of that frame elsewhere in  
central or expanded storage.  The TCB/SRB timer is stopped during this  
process in consideration of the general desire that these times be as   
repeatable as possible.  This new variable, CPUPAGTM, is the CPU time   
that was not previously captured during this process.                   
TYPE72MN:  A significant MVS/ESA 4.3 RMF enhancement is the addition of 
many new RMF III variables to the TYPE72MN dataset, written for each    
performance group for each interval.  New sampled measures for the      
percentage of time when each performance group was USING devices or CPU,
or was DELAYed for devices, CPU, storage, ENQ, HSM, JES, MOUNT, message,
XCF will make TYPE72MN a very useful source of delay analysis.          
Additional measures of CSTORE and ESTORE usage and "long" logical swaps 
are included in these new variables:                                    
  AVGELPTM=AVG ELAPSED*TIME PER*ENDED TRANS                             
  AVGQUETM=AVG JES/APPC*QUEUE TIME*PER ENDED                            
  CPUVECTM=VECTOR*CPU USED*DURATION                                     
  LONGESTO=LONG SWAPS*TO EXPANDED*STORAGE                               
  LONGPHYS=LONG SWAPS*TO PHYSICAL*AUXSTORE                              
  LSWSAMPS=TOTAL*LOGICAL SWAP*SAMPLES*/                                 
  PCTDLDEV=PCT WHEN*DEVICE*DELAY                                        
  PCTDLENQ=PCT WHEN*ENQ*DELAY                                           
  PCTDLHSM=PCT WHEN*HSM*DELAY                                           
  PCTDLJES=PCT WHEN*JES*DELAY                                           
  PCTDLMNT=PCT WHEN*MOUNT*DELAY                                         
  PCTDLMSG=PCT WHEN*MESSAGE*DELAY                                       
  PCTDLPRO=PCT WHEN*PROCESSOR*DELAY                                     
  PCTDLSTO=PCT WHEN*STORAGE*DELAY                                       
  PCTDLXCF=PCT WHEN*XCF*DELAY                                           
  PCTUNKN =PCT WHEN*UNKNOWN*STATE                                       
  PCTUSDEV=PCT WHEN*DEVICE*USING                                        
  PCTUSPRO=PCT WHEN*PROCESSOR*USING                                     
  PSWSAMPS=TOTAT*NON-LOGICAL*SWAP SAMPLES                               
  TRANS   =ENDED*TRANSACTION*COUNT                                      
TYPE73:  In MVS/ESA 4.2, APAR OY45991 PTF UY77343 now writes a CHPID    
segment for all 256 possible paths whether they exist or not, so now MXG
only OUTPUT TYPE73 observations if the CHPID is ONLINE.  This logic was 
externalized into member EXTY73 in case you want observations for       
OFFLINE channel paths.                                                  
TYPE74TD: New "Tape Device" dataset contains the maximum number of tape 
devices allocated each interval, recorded if device class TAPE is being 
recorded.  This dataset was also added to BUILDPDB/BUILDPD3 and         
WEEKBLD/MONTHBLD logic.                                                 
TYPE74:  New variable, TAPEMNTS, counts the number of tape mounts       
detected during the interval for each tape device.  Variables MTPATBEG  
and MTPATEND are "Y" flags if MTP (mount pending) existed at begin or   
end of interval.  If MTP does not exist at either begin or end, MXG     
calculates the average mount pending per tape mount per device in new   
variable AVGMTPTM.  In RMFINTRV AVGMTPTM is calculated for all          
devices that had both MTP flags blank.                                  
  (Only when both flags are blank do we know for sure that the mount    
   pending time duration and the number of mounts are exactly matched.) 
TYPE79C: New variables R79FLAG, R79CPBY and R79CCPTS added.             
TYPE90:  Variables MINBUFF and MAXBUFF are now reserved in IPL SMF, SET 
SMF, or SETSMF Operator Command event records.  No real loss here, since
the maximum number of buffers each interval is always in TYPE23 dataset.
TYPE94   The type 94 record from the 3495 Tape Library Dataserver has   
hourly counts and durations (min/max/avg for counts/durations) of drives
mounted, mount requests pending, demounts, ejects, audit requests, and  
the count of insert stores.                                             
TYPE96   The type 96 record from The Integrated Reasoning Shell, TIRS   
accounts for TIRS resounce usage.  The SMF Manual title "Cross Memory   
Service Provider Charge Back" is certainly pompous for this TIRS record!
Type 118/119:  The TCP/IP SMF record sample used ID=70!  APAR PN34837   
now assigns IBM record numbers 118 and 119 for the TCP/IP product.      
BUILDPDB Logic was changed to use the type 26 OFFLPURG field to detect  
purge records created by the SPOOL Transfer/Offload program.  New       
and NRACCTFL were added to the list of variables kept from TYPE26J2 (in 
member IMACPDB).  The order of datasets in the MERGE for PDB.JOBS was   
changed, moving GOOD26J2 to be first so that the TYPE26 ACCOUNTn fields 
will be used in PDB.JOBS when they exist.  (Leaving it where it was     
could have blanked out valid ACCOUNTn data since the SAS MERGE uses the 
values from the last dataset, for sites not yet on MVS/ESA 4.3!)        
RMFINTRV The new CPUPAGTM from TYPE71 is kept in RMFINTRV as a separate 
variable,  is also added to CPUTM, the sum of all captured CPU time, and
hence the CPUPAGTM is NOT included in CPUOVHTM, the MXG variable for    
uncaptured CPU time in RMF.                                             
DCOLLECT has added a new field to the type "A" record with the amount of
space used by a VSAM entry (formerly only allocated size was given).    
  5.  The TICTOC product from ISOGON, designed to test applications for 
      the year 2000+, can corrupt dates and data in SMF type 4, 5, and  
      30 records.  TICTOC establishes a "virtual clock" by trapping SVC 
      11, but SMF uses SVC 11.  When the virtual clock was returned to  
      SMF, it created invalid job initiation, JINITIME (which is used in
      MXG's SPIN decision logic) and corrupts JELAPSTM, for any job that
      used TICTOC for application testing.  The virtual clock also      
      corrupted the CPUTCBTM field, but ISOGON has corrected both errors
      (by only returning a "virtual clock" value if the caller is in    
      Problem State and in a User Protect Key), so that now the SMF     
      times appear to be valid.  Their zap is PMR0011, and it is        
      included in TICTOC Release 2.0, due out later this year.          
  6.  MVS/ESA Resource Accounting, Cost Transfer, and Billing Issues    
  6.  z/OS Resource Accounting, Cost Transfer, and Billing Issues       
       z/OS Resource Accounting, Cost Transfer, and Billing Issues      
                     What's Captured Where                              
                    Herbert W. Barry Merrill                            
                       Merrill Consultants                              
                   Originally presented at the                          
               SHARE Winter 1993 Meeting Session M724                   
                     Wednesday, March 3, 1993                           
     This paper is also contained in member ACHAP31 of MXG Software,    
     as it is a consolidation and revision of that chapter.             
   Computer system accounting is implicitly tied to the effectiveness   
   of the DP management.  While your chief executive officers want      
   effective cost accounting for their data processing budgets, many    
   DP managers drag their feet because they do not want to be held      
   accountable, and justify those delays by claiming that resource      
   accounting cannot be accomplished.  Successful computer system       
   accounting is thus both a technical and a political issue. This      
   chapter is a technical tutorial on the excellent resource capture    
   mechanisms that do exist in MVS/ESA, and how they can be used to     
   distribute the cost of your major hardware components to users.      
This material is Copyright (c) 1993 by Merrill Consultants, Dallas, TX.,
and will be published in MXG Technical Newsletter TWENTY-THREE, March   
15, 1993.  Permission is hereby granted to SHARE, Inc., and to SHARE    
member installations to reproduce this material for their internal use. 
All other rights are reserved.                                          
       Topic                                                 Page       
   CPU RESOURCE ACCOUNTING                                     2        
   CPU CAPTURE AT THE SUBSYSTEM LEVEL                          6        
   DB2 CPU USAGE CAPTURE                                       7        
   CICS CPU CAPTURE                                            8        
   MEMORY                                                      9        
   CHANNELS AND CONTROL UNITS                                 10        
   DISK DRIVES                                                10        
   TAPE DRIVES                                                11        
   TAPE VOLUMES                                               11        
   TAPE MOUNTS                                                12        
   PRINTERS                                                   12        
   TERMINALS, CONTROL UNITS, AND PORTS                        13        
CPU RESOURCE ACCOUNTING                                                 
The CPU resource is always the most expensive shareable resource in any 
data processing system, and it will always be the primary resource used 
for cost recovery and chargeback.  Charges must be based on utilization 
in order to equitably distribute the cost of the processor itself.      
MVS records the total CPU time consumed in the hardware platform in     
TYPE70 dataset variable CPUACTTM, it records the CPU time captured for  
each address space in the TYPE30 dataset, and it records the CPU time   
for each service class, so the accounting and cost recovery of CPU time 
should be relatively straightforward, right?  Ain't nothin' that        
straightforward: read on!                                               
A major issue in CPU accounting are the capture ratios, which quantify  
how much of the total CPU time caused by a workload is captured in the  
accounting records for that workload.  In most instances, uncaptured CPU
time results when MVS simply does not know which task caused the burst  
of CPU time.                                                            
   An example is the I/O interrupt processing CPU time of the First     
   Level Interrupt Handler, FLIH, the module that gets control when an  
   I/O interrupt occurs.  Although FLIH knows which device is involved, 
   it does not know which task owns that device at the time of the      
   interrupt processing, and thus its CPU time cannot be assigned to an 
   address space or a service class.  For a long time, even the Second  
   Level Interrupt Handler, SLIH, did not record its CPU usage, but     
   MVS/ESA added instrumentation to capture SLIH time in CPUIIPTM.      
Uncaptured CPU time is still CPU time that the hardware had to deliver, 
and you had to buy that hardware, so you must measure the uncaptured CPU
time, and recover it by inflating the recorded CPU time by dividing by  
the capture ratio.  So how do we measure how much CPU time is captured? 
We can use RMF or SMF data to calculate capture ratios, but they do not 
necessarily provide the same answers!                                   
The "RMF Uncaptured CPU time" is the TYPE70 CPU active time minus the   
"identifiable" CPU times recorded in RMF; this difference measures how  
much CPU time was uncaptured, as measured by RMF, during an interval.   
IBM has made major improvements in minimizing the uncaptured CPU time by
improving the instrumentation within MVS; early MVS/370 typically       
captured only 70% of the CPU time, MVS/XA improved to 80%, and with the 
addition of the new Page Movement CPU time in MVS/ESA 4.3, over 90% of  
the total CPU time may be identifiable in the RMF data.                 
That "RMF Identifiable" CPU time is the sum of the five CPU measures in 
TYPE72GO (TCB, SRB, I/O Interrupt, Hiperspace, and Region Control Task) 
for all of the Service Classes, plus the CPU measure in TYPE71 for Page 
   Only Service Classes can be used in this calculation because any CPU 
   time in a Reporting Class duplicates CPU time in its Service Class.  
The RMF Uncaptured CPU time (historically, but inaccurately named       
CPUOVHTM in MXG's RMFINTRV dataset) is calculated as:                   
and it represents the total CPU time that was consumed but that was not 
captured in RMF data.  And we could calculate the RMF capture ratio:    
       RMF Capture Ratio= CPUTM/CPUACTTM;  (express as percentage)      
So can't we then take the TYPE72GO data for each Service Class, inflate 
the measured CPUTM by dividing by the above capture ratio to recover    
100% of the CPU time consumed?  Of course not, that would be too easy,  
and there's an additional problem.  While RMF "identifies" all of the   
CPUTM, only some of the service classes represent directly chargeable   
work.  For example, service classes for VTAM, CATALOG, RMF, etc.        
represent real work that was consumed, but that work is not attributable
to a specific workload or account number: TSO users, as well as IMS and 
CICS transactions cause the CPU time that VTAM used; RMF resources      
(while small) are not attributable to any user, and CATALOG resources   
are caused by all catalog references!  The new CPUPAGTM is "identified" 
CPU time, but it, along with the CPUSRBTM in Service Class SYSSTC,      
record the paging subsystem's use of CPU!                               
We must identify those service classes that map directly to our billable
workloads (for example, the service class(s) in which Batch, TSO, CICS, 
IMS, etc., execute) and from them, construct workload specific variables
with the sum of TYPE72GO CPUTM from those workload specific service     
classes (for example, variables BATCPU, TSOCPU, CICSCPU, IMSCPU, etc.)  
for each RMF interval.  MXG's member IMACWORK is the table which maps   
service classes to specific workloads, and it    is used to build the   
RMFINTRV dataset from which capture ratios can be calculated.  The RMF  
CPU time that is captured in these workload specific variables will be  
 Workload Specific CPUTM =  BATCPU + TSOCPU + CICSCPU + IMSCPU;         
and there now exists a new "Workload Specific Uncaptured" CPU time:     
which now includes all of the CPU time that was not recorded in one of  
the workload specific service classes.  We can thus now calculate the   
Workload Specific Capture Ratio:                                        
It is this capture ratio that we must use in our chargeback analysis, as
it takes into account not only the MVS uncaptured CPU time, but also the
CPU time consumed in service classes (like VTAM, RMF, etc.) that are not
mappable to specific workloads.                                         
   A note for the serious analyst:  The capture ratio calculated above  
   is the average capture ratio across all workloads, which assumes that
   the same amount of uncaptured CPU time is caused by each workload.   
   That clearly may not true; interactive workloads (especially TSO) may
   capture significantly less CPU time than does batch, as was shown in 
   Chapter 26 of the 1984 MXG Guide, which found MVS/XA captured 80% of 
   Batch, 76% of IMS, 66% of CICS, but only 58% of TSO, with the average
   capture ratio of 70%!                                                
   Calculation of individual capture ratios for each workload can be    
   done using SAS/STAT linear regression tools:                         
      PROC GLM DATA=RMFINTRV;                                           
   as was described in that chapter.                                    
   There is now an even easier way to get a good estimate of the        
   capture ratio of your workloads; the MXG dataset PDB.RMFINTRV        
   contains the variable CAPTURAT, which is the total system capture    
   ratio.  By plotting the CAPTURAT versus time of day for each of      
   your systems:                                                        
       PROC PLOT DATA=PDB.RMFINTRV;                                     
        BY SYSPLEX SYSTEM;                                              
        PLOT CAPTURAT*STARTIME;                                         
   you can examine those times of day on a particular system when the   
   workload is "all CICS", or "all TSO", and make a very accurate       
   estimate of that workload's capture ratio.                           
   However, when the overall capture ratio was only 70%, measuring the  
   individual capture ratio of each workload was much more critical,    
   because there was so much more variation between workloads.  But if  
   overall capture ratio is over 90%, and with the TSO capture ratio    
   improved by CPURCCTM, it may not be so critical to calculate each of 
   the workloads individual RMF capture ratio.  Of much more immediate  
   concern is the determination of the CPU time captured by the SMF     
   accounting records themselves.                                       
Historically, we have used RMF to calculate the RMF Capture Ratio and   
the Workload Specific Capture Ratio because there was no other choice;  
SMF type 30 data could not be synchronized and thus it was simply not   
possible to accurately compare SMF CPU time with RMF CPUACTTM.  Now that
IBM has finally provided SMF interval synchronization (requested in a   
SHARE CME requirement that I authored in 1978!), the same analysis      
described above for RMF could now be accomplished using the SMF type 30 
data.  However, not only are the CPU times recorded in RMF different    
than the CPU times recorded in SMF, but also the CPU times in the       
TYPE30_4 step termination record are not exactly the same as the CPU    
times in the TYPE30_V step interval records!  Let us examine these      
MVS/XA recorded only CPUTCBTM and CPUSRBTM in RMF TYPE72GO, TYPE30_4 and
in the TYPE30_V datasets.  MVS/ESA 3.1.0e added three new CPU times,    
(CPUIIPTM,CPUHPTTM,CPURCTTM) to the TYPE30_4 and TYPE30_V data, but     
those three CPU times were not added to the RMF TYPE72 data until 4.2   
The CPUPAGTM that was added by MVS/ESA 4.3 to the RMF TYPE71 data is not
recorded anywhere in SMF type 30 data; in fact, IBM describes this Page 
Movement CPU time as the time when the CPU timer was suspended, and says
that the reason the CPU timer was suspended during page movement was to 
make the recorded task CPU time more repeatable (albeit less accurate!).
There are two other CPU measures that exist only in the type 30 step    
termination data.  These fields, CPITCBTM and CPISRBTM contain the      
"Initiator State" or "Privileged State" CPU time caused by the step, and
they record the CPU time at the beginning of the step and the CPU time  
at the ending of the step that is not recorded elsewhere.               
So what are the beginning and ending step events that are recorded in   
CPITCBTM and CPISRBTM?  The major events recorded at the beginning of   
steps appear to be allocation related.  Specifically, the CPU time to   
execute the System Managed Storage allocation rules (ACS) is captured in
these times.  This has been both observed and verbally confirmed by IBM 
SMS Level Two Support technicians.  Additionally, one site with Boole & 
Babbage's IAM Product noted a step increase in these CPU times when that
product was enabled.  There may also be a small amount of CPU time due  
to the creation of the address space included in these CPU times.       
At the end of step, the CPITCBTM and CPISRBTM times result primarily    
from SMF itself!  At step termination, the DD segments are scanned by   
the type 30 SMF "DD Consolidation" algorithm in an attempt to minimize  
the length of the type 30 record, by consolidating into a single entry  
all DD segments with the same DDNAME and Device Address.                
In 1987, Diane Eppestine at Southwestern Bell saw that whenever their   
SAR job (a SYSOUT processing subsystem) was cancelled, the CPU went to  
100% busy for 30-60 minutes.  Instruction traces found the "loop" was in
DD Consolidation.  SAR dynamically allocates a DD for each SYSOUT file  
it processes; by the end of the week that step had over 75,000 DD       
entries!  DD consolidation reads the first DD segment, scans the        
remaining 74,999 segments for a match, reads the second and scans the   
remaining 74,998 for a match, etc.  etc., etc., all at DPRTY=FE!  In    
response to Diane's discovery, Bill Richardson, IBM SMF Development,    
subsequently provided a new SMF option, DDCONS(NO), specified in        
SYS1.PARMLIB(SMFPRMxx), so that you can disable this very unwise (in my 
opinion) algorithm, and thereby eliminate its wasted CPITCBTM and       
CPISRBTM CPU time.                                                      
   The time of DDCONS(YES) is measurable because SMFTIME timestamps when
   each record is moved (memory-to-memory) to the SMF ASID.  For step   
   events with more than 1635 DD segments, multiple physical type 30    
   records are created, each with its own time stamp.  One specific case
   found a subtype 2 interval event created seven type 30 records at    
   Time of Day of .19 .19 .19 .22 .32 .36 & .46 TOD seconds (i.e., it   
   took only 270 milliseconds to create these seven records, since there
   is no DDCONS in the creation of the subtype 2). These seven records  
   contained 9182 DD segments that had been allocated during that       
   interval.  The step then terminated at 18.89 TOD seconds, creating   
   two subtype 3 records both with that timestamp, containing 1929 DD   
   segments.  DDCONS then began, and it then took until 36.50 TOD       
   seconds to create the first subtype 4 record, and then the last of   
   the eight subtype 4 records was not created until 40.93 TOD seconds. 
   These subtype 4s had 11,070 DD segments, while the subtype 2s and 3s 
   had 11,111 total DD segments.  Thus this invocation of DDCONS took   
   22.04 elapsed seconds (and recorded CPITCBTM of 22.00 CPU seconds!)  
   from the end of step until the step actually ended, and this DDCONS  
   invocation could remove only 31 DD segments from the step record!    
   Examine a day's TYPE30_4 (or PDB.STEPS) data and sum the CPITCBTM and
   CPISRBTM, then specify DDCONS(NO) and show management how many CPU   
   seconds you have been wasting due to DD consolidation!               
   SMFPRMxx MEMBER TO SPECIFY DDCONS(NO).                               
      Solid = captured   Dashed = calculatable                          
TYPE 70 (RMF-captured CPU measurement of real or logical CPUs):         
    Elapsed Interval (Duration multiplied by number of CPUs)            
 ___________________________________________________________ ---------  
                      CPU                                       CPU     
                    Executing                                 Waiting   
 _________ _________ _________ _________ _________ _________            
   CPU 1     CPU 2     CPU 3     CPU 4     CPU 5     CPU 6              
   Busy      Busy      Busy      Busy      Busy      Busy               
 Total Hardware CPU Busy Time (from Type 70 "non-wait")                 
 Total Hardware CPU Busy Time (from Type 70 "non-wait")                 
TYPE72GO (service classes) plus TYPE 71 Paging                          
 _____ _____ _____ _____ _____ _____ -----------------------            
  TCB   SRB   IIP   RCT   HPT   PAG    RMF Uncaptured CPU               
  CPU   CPU   CPU   CPU   CPU   CPU                                     
 _____ _____ _____ _____ _____ _____                                    
  RMF   RMF   Captured in      New                                      
  TCB   SRB    RMF 4.2.1,      in                                       
  CPU   CPU    MVS/ESA 4.2+    RMF                                      
 ___________ _____ _____ _____ _____                                    
              Existed,   New,                                           
   TCB+SRB   Moved from  was                                            
             Uncaptured  RMF                                            
                to       TCB                                            
 _____ _____ _____ _____ _____ _____   = RMF CPUTM, sum of 6 measures   
TYPE 30 step termination:                                               
 _____ _____ _____ _____ _____ ----- _____ _____ -----------            
  SMF   SMF   SMF   SMF   SMF         SMF   SMF   Uncaptured            
  TCB   SRB   IIP   RCT   HPT         TCB   SRB    SMF step             
  CPU   CPU   CPU   CPU   CPU         CPI   CPI      CPU                
 _____ _____ _____ _____ _____       _____ _____   = CPUTM, sum of 7.   
TYPE 30 interval:                                                       
 _____ _____ _____ _____ _____ -----------------------------            
  SMF   SMF   SMF   SMF   SMF   Uncaptured SMF interval CPU             
  TCB   SRB   IIP   RCT   HPT                                           
  CPU   CPU   CPU   CPU   CPU                                           
 _____ _____ _____ _____ _____                     = CPUTM, sum of 5.   
CPU CAPTURE AT THE SUBSYSTEM LEVEL                                      
Thus far, we have only looked at what is captured at the address space  
level, and for many applications this is adequate.  For example, if your
CICS regions individually service individual business units, using their
type 30 step termination records may well be adequate for cost recovery.
However, in most instances, a single CICS region services multiple users
from different cost centers, which would require CPU capture at the     
transaction level to distribute cost to each department.                
   Many multiple user address spaces (VTAM, CATALOG and monitor address 
   spaces like NPM, RMF, SMF) do not provide discrete CPU time per user,
   requiring the use of regression techniques described earlier for     
   their redistribution.                                                
For subsystems that do provide transaction level accounting, we have yet
another capture ratio: how much of the CPU time that is captured in the 
type 30 (or type 72) data is captured in that application's transaction 
records.  The answer varies widely, especially if DB2 access from CICS  
or IMS is involved.                                                     
DB2 CPU USAGE CAPTURE                                                   
When DB2 is accessed by Batch, TSO, IMS, and CICS address spaces, almost
all of the DB2 CPU time is recorded in the address space of the caller, 
because DB2 access uses MVS cross-memory services.  Thus for those      
callers, the DB2 CPU time is recorded in the type 30 records and in the 
type 72 records for the service class of the caller.  (Some benchmarks  
for these caller's use of DB2 showed that over 96% to the DB2-caused CPU
time was recorded in the caller's service classes, with less than 4%    
recorded in the DB2 MAST, DBM1, and IRLM service classes.)     So the   
good news is that the usage of DB2 CPU time is already recorded in your 
accounting records, as long as you are using type 30 data for your      
accounting.  Using the RMF type 72 data for your capacity planning      
similarly includes DB2 CPU time in those workload records.              
For DB2-under-IMS transaction accounting, the DB2-caused maintask CPU is
included in the CPU time recorded in the IMS log 07 (program scheduled) 
record; however, in 2/2005, it was reported that only the maintask CPU  
time is included, and that DB2 parallel subtask CPU time is NOT included
IBM has been made aware of the unexpected discovery, but has made no    
response as to if, or when, that CPU time will also be captured in IMS. 
Unfortunately, there is only one bucket for CPU time in the IMS         
log, and it includes not only the DB2-caused CPU time, but also all of  
the transaction's CPU time in the IMS Control and IMS Message Processing
Regions. Neither Candle/IBM's ITRF product nor Landmark-ASG TMON for IMS
product capture the portion of CPU time due to DB2 in their IMS         
monitors.  However, BMC's IMS Measurement Facility, IMF, (originally    
Control/IMS) is implemented as a monitor sitting on top of IMS itself,  
so it is able to capture and segregate CPU time into eight separate CPU 
buckets, one of which is the DB2 CPU time caused by the transaction.    
The key point about DB2 under IMS is that the DB2-caused CPU time is    
included in the transaction-level CPU time, no matter which IMS data    
source you use.                                                         
Such was not the case for DB2-under-CICS transaction accounting!  Before
the "OTE" (Open Transaction Environment) existed, the below indented    
paragraphs documented the DB2 CPU capture under CICS:                   
   While the DB2 CPU time caused by CICS transactions is captured in the
   type 30 records for each region, and while that DB2 CPU time is      
   captured in the type 72 service class and reporting class record for 
   each CICS region, as well as in the type 110 subtype 2 record's CICS 
   Statistics CICDS dataset (so it is included in MXG's CICINTRV        
   dataset), prior to "OTE", the DB2 CPU time caused by a CICS          
   transaction was NOT recorded in any transaction record from any CICS 
   monitor.  Neither the CICSTRAN dataset from IBM's SMF 110 subtype 1  
   CICS Monitor facility, nor from Candle's Omegamon for CICS, nor from 
   the MONITASK dataset from ASG-Landmark's The Monitor for CICS, could 
   capture any DB2 CPU time in the CICS transaction data.  Fortunately, 
   there was an accounting solution: DB2 itself creates a type 101 SMF  
   accounting record for each DB2 transaction event from any connection 
   in dataset DB2ACCT.  The DB2ACCT observations for CICS connections   
   had to be selected from the DB2ACCT data (but only CICS Attaches,    
   since CPU time in DB2ACCT for Batch, TSO, and IMS connections has    
   already been captured in their type 30 and/or IMS log CPU time).     
   DB2ACCT variable QWHCATYP identifies the source of the connection; a 
   value of 4 indicates CICS attach.  Thus to account CICS at the       
   transaction level, you must use both CICSTRAN and the QWHCATYP=4     
   subset of DB2ACCT in your chargeback.                                
      Prior to DB2 2.3, if the DB2 thread was reused, only one DB2ACCT  
      record was created (for the thread), and it could represent many  
      CICS transactions, which prevented accurate CICS accounting with  
      DB2, but now each DB2 transaction causes a CICSTRAN observation,  
      even with thread re-use.  Also, QWHCATYP did not exist prior to   
      DB2 2.3, which prevented accurate connection identification!      
   The DB2ACCT data can be matched with the CICSTRAN data by merging on 
   variables NETSNAME (the originating network name) and UOWTIME (which 
   is the first six bytes of the UOWID, the Unit-of-Work ID field), and 
   the MXG member ASUMUOW combines DB2ACCT and CICSTRAN to create the   
   PDB.ASUMUOW dataset that contains both the CICSTRAN CPU time (CPUTM) 
   and the DB2 CPU time (DB2TCBTM), and you had to add those variables  
   together to properly account for the CICS and DB2 CPU time at the    
   transaction level.                                                   
      Only the first six bytes of UOWID are used for the same unit of   
      work because the last two bytes of UOWID count commits and/or sync
      points, and may not be the same across the same transaction.  Note
      that there can be multiple observations in CICSTRAN with the same 
      values of NETSNAME and UOWTIME; in CICS Multiple Region Option,   
      MRO, environments, the Terminal Owning Region (TOR), the          
      Application Owning Region (AOR), and the File Owning Region (FOR) 
      create individual CICSTRAN observations for a single CICS event,  
      and all records from the same CICS event/uow will contain the same
      values in NETSNAME and UOWTIME.  In DB2ACCT dataset, MXG created  
      variables named NETSNAME and UOWTIME by substringing DB2 variable 
      QWHCTOKN (added in DB2 2.3), padding as necessary, to conform     
      exactly with the structure of those pre-existing CICS variables,  
      so that a SAS MERGE of DB2ACCT and CICSTRAN can be used in the    
      ASUMUOW program to match CICS and DB2 transactions.               
   While you must select DB2ACCT observations only for CICS in your     
   charge-back (to avoid double accounting), the other observations in  
   DB2ACCT are completely valid if you want to know how much of your    
   Batch, TSO, or IMS CPU time was actually consumed in DB2 access.     
Most of the preceding paragraph is still true, even with OTE, except    
for this MAJOR change:                                                  
   With the Open Transaction Environment, "OTE" (which automatically    
   exists when you have CICS/TS 2.2 or later calling DB2 V6 or later,), 
   the CICS transaction record's CPU time (e.g., TASCPUTM in CICSTRAN or
   MONITASK datasets) DOES now include the DB2 CPU time! The bottom line
   for CICS accounting with OTE is that you do NOT add the two CPU times
   (CPUTM and DB2TCBTM) in the PDB.ASUMUOW dataset, because CPUTM       
   includes DB2TCBTM.                                                   
While the PDB.ASUMUOW dataset is no longer required to capture the DB2  
CPU time, it is still strongly recommended that it be created and used  
for CICS transaction accounting, since it combines the multiple CICSTRAN
observations for MRO environments into a single observation for each    
"Unit of Work", so there are many fewer observations to pass into your  
billing system, and PDB.ASUMUOW will have the correct TRANNAME of the   
unit of work:                                                           
  Using only CICSTRAN, you will not see the actual transaction name,    
  because the CPU time will usually be in the CICSTRAN observation from 
  the "AOR", and that record will have TRANNAME='CSMI' (the mirror      
  transaction), so you can't map CPU time to TRANNAME from CICSTRAN in  
  an MRO environment, independent of the OTE environment.  Furthermore, 
  the TERMINAL/LUNAME in that AOR record won't identify the source of   
  the CICS user.  The real TRANNAME/TERMINAL/LUNAME will only be found  
  in the "TOR" observation for that unit of work.                       
Also, PDB.ASUMUOW is useful because of the additional DB2ACCT variables 
which are useful for performance and capacity measurement, independent  
of its use for accounting; the MXG program ANALUOW analyzes delays in   
the PDS.ASUMUOW data.   And finally, in MXG 22.13, the MQ-Series data   
from SMF 116 (MQMACCT and MQMACCTQ) data is merged into PDB.ASUMUOW when
you use the ASUMUOW program.                                            
For the accounting of DB2 Distributed work (DRDA from DDCS, for example,
(a DRDA Transaction from DDCS running in an AIX workstation), it is     
necessary to directly charge back using the DB2ACCT dataset.  DB2ACCT   
distributed work observations have QWHCATYP values of 7 or 8, and a plan
name of DISTSERV, and the only field to tie the transaction back to the 
workstation which generated the DB2 activity is the AUTHID, but that may
be constant for all transactions, depending on the software running in  
the workstation that created the DB2 activity.                          
For Distributed work, that CPU time in DB2ACCT is also recorded in the  
type 30 records for the DISTSERV address space and in TYPE72GO for the  
DISTSERV's service class, but there is no other address space involved. 
    Very high CPU time per transaction (for transactions that have few  
    GETPAGES) has been seen (5 CPU hours for 186 transaction!  This may 
    simply be the cost of Distributed Architecture (translating each of 
    the SQL calls and Results to be sent back for different platforms   
    must involve more code than DB2 talking to CICS, since DRDA has to  
    manage itself too), or it may be just that the startup and shutdown 
    costs of DRDA are significantly higher than for normal threads.     
The CPUSRBTM/DB2SRBTM in DB2ACCT is now always missing:                 
    I have previously documented (member ADOCDB2, variable description) 
    that the SRB CPU time in DB2 Accounting records was invalid, but I  
    did not know how wrong it was, or why it looked ok sometimes, until 
    I read IBM's library item Q576462, repeated here:                   
  Q: User is doing some DDF testing and has run some accounting reports.
     SRB times (both class 1 and 2) are about 8 times the TCB times.    
  A: The SRB times in the accounting records, in general, account for   
     SRBs that run in the user address space.  These SRBs are caused    
     by the user's processing, unrelated to anything that DB2 does,     
     but since the SRBs are asynchronous, they sometimes run while the  
     user is processing in DB2.  With two notable exceptions, these SRB 
     times while unrelated to DB2 will almost always be insignficant.   
     One exception is CICS, where there are multiple subtasks accessing 
     DB2 from a single CICS address space.  CICS (not DB2) will often   
     do a significant amount of processing via SRBs.  If there are      
     several DB2 tasks running concurrently when CICS issues an SRB     
     (unrelated to these tasks!) then the time for that SRB will show   
     up not once, but once in each of the accounting records for each   
     of the tasks.  Thus if you add up the SRB times from the DB2       
     accounting records for CICS attachment, it will often greatly      
     exceed the actual amount of SRB time used by CICS.                 
     The other exception is when using DDF.  The requestor times are    
     not affected, but the times at the server (or DBAT, using DB2PM    
     terminology) will show very very large SRB times.                  
     When you look at the DB2 ACCOUNTING records, use only the TCB      
     CPU time, and never look at the SRB time.  When you look at the    
     DB2 STATISTICS records, you should use the TCB and SRB times for   
     all three/four address spaces, but remember that much of the SRB   
     time reported for the DDF address space may also be reported in    
     DB2 accounting records (as TCB time).                              
CICS CPU CAPTURE                                                        
Even without the DB2-under-CICS issues raised above, the amount of CPU  
time captured in CICS transaction records historically has been much    
less than the CPU time recorded for the region in its type 30 or its    
type 72 service class records.  The following table, while showing      
pre-ESA CICS numbers, demonstrates the observed capture of three CICS   
regions executing in the same 3090 model 400 processor in a 900 second  
                        Seconds in          Percentage of CPUTCBTM      
                       Region TYPE72GO      in CICSTRAN dataset         
            Region       CPUTCBTM                 TASCPUTM              
               A          111.72                    41.1                
               B          127.06                    37.5                
               C          198.76                    66.0                
The CICS CPUTCBTM time that is not captured in the CICSTRAN transaction 
accounting TASCPUTM is the CPU time to start-up and to shut-down each   
transaction.  Until a transaction is attached, CICS monitoring cannot   
capture CPU time, and CICS monitoring terminates before the transaction 
is detached.  It appears that this CPU cost to start-up and shut-down a 
transaction is fixed; it is independent of what a transaction ultimately
does.  Thus there should be a fixed amount of CPU time per transaction  
that is not recorded, and we should be able to measure that cost per    
CICS transaction and use it, along with the TASCPUTM actually recorded  
for the transaction, to improve the recovery of CICS CPU time.          
We can determine this "fixed-cost per CICS transaction" by selecting RMF
TYPE72GO for the service class of a CICS region to get that region's    
recorded RMF CPUTM for each interval, and by summing CICSTRAN for the   
same interval from the same region (APPLID) to create variables NRTRANS 
(the number of transactions that ended during each interval), WTFCIOCN  
(the number of times that File Control had to wait, indicating that a   
physical I/O was performed for a transaction), and TASCPUTM (the CICS   
recorded transaction CPU time).  We can then use linear regression:     
   PROC GLM;                                                            
   MODEL CPUTM=NRTRANS WTFCIOCN TASCPUTM;                               
to generate the coefficients of the equation relating these independent 
variables to the total recorded CPUTM.  The coefficient of NRTRANS is   
that "fixed-cost per CICS transaction" (in seconds), and the coefficient
of WTFCIOCN is the CPU cost (in seconds) of each physical I/O!          
The coefficients of these three terms can be evaluated as potential     
billing factors to reproduce the total CPU time caused by each          
transaction.  What has been proposed here is that the real CPU cost to  
deliver CICS CPU service results from adding together the following     
three cost components:                                                  
 a) a cost for the existence of each transaction (NRTRANS), recovering  
    the static cost of each ATTACH/DETACH,                              
 b) a cost for I/O (WTFCIOCN), the CPU cost of doing I/O operations for 
    each transaction, and                                               
 c) a cost for the actual CPU seconds (TASCPUTM times it's coefficient) 
    for each transaction.                                               
Prior results (not only for CICS and other on-line systems, but even for
batch job steps) suggest that the major component of CPU time recovery  
may be the NRTRANS component.  I regret that those studies were         
proprietary to the enterprise for which they were done and thus have not
been published, but they showed that the start-up and shutdown costs of 
a transaction can often be more significant numerically that the actual 
CPU time recorded by the transaction accounting.                        
With the three coefficients, you can then take the CICSTRAN data and    
apply them transaction by transaction to create a billable CPU time for 
each interval, which can then be compared with the recorded TYPE72GO    
CPUTM for validation.  By examining the sum of the three components of  
CICS CPU time, you may discover that the addition of the NRTRANS        
component brings the CPU captured to very nearly 100%, and you can also 
see how much CPU is recovered from NRTRANS, WTFCIOCN, and TASCPUTM.     
Remember that this constructed CPU time per transaction still does not  
include the uncaptured MVS CPU time discussed previously.               
Although you might like to be able to recover the cost of real memory   
(Central and Expanded Storage) by charging memory usage to each task,   
that possibility disappeared with the departure of MVT and other "real" 
memory systems (in which tasks really did own "K-core" units for which  
we could legitimately charge).  With virtual memory operating systems,  
all real memory is owned by the operating system, and not by individual 
address spaces.  The amount of memory "doled out" to an address space is
thus not under the control of that address space, but rather depends on 
the other work that is concurrently requesting services, and (sometimes)
the whims of the memory management algorithms.  Since a task does not   
control how much memory it does or does not get, real memory cannot     
legitimately be used for chargeback.  In addition, because the amount of
memory allocated varies widely from run to run, attempting to charge for
real memory space-time occupancy would have very serious problems with  
   See the paper on I/O Blocksizes in Chapter 42 of the 1984 MXG Guide. 
   PAGESECS variation of 30-40% were noted between execution of the same
You must treat the cost of memory just like the cost of floor space and 
air conditioning; they cannot be explicitly allocated to users but must 
be recognized as prerequisite resources you must purchase so that you   
can deliver CPU cycles to user workloads.                               
   How do we know we need more air conditioning resources for our CPUs? 
   We examine the thermometer and when it gets "too high", we buy more  
   air conditioning.  Similarly, when we need more memory, we recognize 
   its need by looking at the memory thermometer, the page fault rate!  
   When it is "too high", we must buy more memory!                      
CHANNELS AND CONTROL UNITS                                              
Channels and control units are meant to allow programs in execution to  
read and write blocks of data. Channels and control units are shareable 
resources, and their charges should be distributed based on usage. If   
channels and control units serving tape devices are separate from those 
serving disk devices, it is reasonable to sum the cost of tape channels 
and control units and divide by the number of tape I/Os in order to     
establish a price-per-tape I/O.  Similarly, sum the cost of disk        
channels and disk control units and divide by the number of disk I/Os to
establish a cost-per-disk I/O.  Under MVS/ESA using I/O connect time    
instead of I/O counts is much wiser, as it eliminates the inequity of   
charging the same for a 99 byte I/O as for a 32760 byte I/O, and is     
strongly recommended.  In addition, since I/O counts in RMF are the     
number of I/O operations, SSCHs (formerly SIOs), but SMF I/O counts can 
be either EXCPs (blocks transferred, for sequential access methods) or  
SSCHs for all other access methods), additional validation problems will
result if I/O counts are used instead of I/O connect time.              
The key issue is to distribute the cost of the shared channels and      
control units to the users who use them in moving blocks of data.  Some 
channels and control units service only the data center - eg., paging   
channels. Their costs must be included in the cost of memory and cannot 
be not directly charged to users.                                       
Even this resource recovery is no longer straightforward.  When we use  
memory as buffers (CICS LSR, DB2 Buffer Pools, etc.), the recorded I/O  
operation will be counted only for the first user that caused the I/O   
operation.  If that block of data remains in the buffer all day long,   
other users will not count an I/O and thus will not be charged!  Is it  
fair, then, to charge the bright user who came to work earliest for his 
I/O and give a free ride to the johnny-come-latelies?  Probably not!    
And this is not just a problem with program buffers.  Cached controllers
create exactly the same problem with both I/O counts and I/O connect    
time: I/O time is much less when the data is already in the cache!      
DISK DRIVES                                                             
Disk drives are used to store data, and the owner of the data should pay
the storage cost.  If an entire volume is dedicated to an application,  
the monthly cost of that volume can be billed to that application.  For 
shared disk drives, the VTOC/VVDS can be read and used to identify the  
owner of each data set, who can then be charged for the number of bytes 
allocated.  One method is to take the total cost of the disk drive,     
divide by the number of bytes on the volume, but this only recovers     
costs if 100% of the volume is allocated, so the percentage of the DASD 
farm's capacity that can be allocated must be determined, and used to   
inflate the per byte cost of DASD storage.                              
DCOLLECT, an SMF IDCAMS facility will read VTOCs and VVDSs to create a  
flat file processed by TYPEDCOL to record non-VSAM allocation and usage 
and VSAM data space allocations (in DFSMS 1.1).  Alternatively, MXG has 
ASMVTOC and ASMVVDS programs to dynamically allocate all DASD devices   
and read their VTOCs and VVDSs to provide considerable more detail (for 
example, location of each extent for non-VSAM, and VSAM space used for  
VSAM), with or without SMS.                                             
TAPE DRIVES                                                             
Tape drives are owned for the life of each allocation by a specific job.
It is the duration of allocation that must be used to distribute the    
cost of tape drives. The PDB.STEPS contains TAPEDRVS, the number of tape
drives allocated by the step, and EXECTM, the duration of step execution
after drives are allocated, so their product is used to calculate tape  
drive hours per job.  You can sum all jobs to get the total tape hours  
allocated; divide that sum into the dollar costs of your tape drives to 
determine the per-hour tape drive charge. This measure reflects actual  
elapsed time of a job step and is a good measure if your installation is
reasonably well tuned, causing job elongation to be constrained.        
If you have widely varying execution times, however, it may be unfair to
charge tape drives based on true elapsed time. If the installation wants
to eliminate the variability of tape drive hours due to using the actual
elapsed hours, you can instead estimate the number of hours that the job
would have used the tape drive if it was the only job in the system. You
can execute tape jobs in a controlled run and determine the relationship
between tape drive hours and the tape resource (connect time or EXCPs)  
to establish an equation that estimates the billable tape drive hours   
from each I/O connect second (or EXCP).  These estimated billable tape  
hours can be summed and divided into the cost of tape drives to create a
per unit rate for billable tape drive hours to recover tape drive costs.
However, there remains one serious problem in using step records for the
calculation of tape drive hours: dynamic allocations.  The step record  
contains a DD segment for each tape allocation, with the unit address of
the tape drive, but there is no flag to indicate if the tape drive was  
allocated for the entire life of the step (statically), or if the tape  
drive was deallocated dynamically (using FREE=CLOSE, for example), or   
dynamically allocated and then dynamically deallocated for brief periods
of time (as done by both HSM and DB2MSTR).  MXG's variable TAPEDRVS is  
the number of unique tape drive addresses found in the step record, but 
if DB2MSTR happens to allocate a tape drive 15 times during the day (as 
it does to back up the log), and if each allocation happens to get a    
different drive address, the step record for DB2MSTR will look like it  
had 15 tape drives allocated for the entire life of the step!  The only 
safe solution is to identify which jobs use dynamic allocation of tape  
devices, and to then exclude those jobs in charging for tape drive      
hours!  Only dynamic deallocation is recorded in the type 40, and it can
not be enabled just for tape drives, so enabling type 40 to count tape  
dynamic allocations would also create many type 40s from TSO users.  MXG
member ASMIEFU8 is SMF exit IEFU83 code that filters only type 40s for  
tape deallocations that will let you enable type 40s to identify which  
jobs have to be excluded from tape drive charges.                       
The MXG Tape Mount Monitor, ASMTMNT, is being modified to also track    
tape drive allocation-to-deallocation, and it will write an SMF record  
for each tape drive allocation, dynamic or static, which can then be    
used directly to account for and measure tape drive allocation hours.   
TAPE VOLUMES                                                            
Storage of tape volumes requires floor space and racks. The total cost  
of storage can be divided by the number of tapes in the library to      
establish a monthly cost for a stored volume. The tape management system
catalog can be used to determine ownership of each volume, and a daily  
or weekly program can determine the number of days each volume is owned 
by its creating user, who can then be charged at one-thirtieth of the   
monthly rate for each day of tape storage. The job costs of the tape    
management system runs can also be added to the storage costs if they   
are significant.                                                        
TAPE MOUNTS                                                             
Tape mounts require people time. Scratch tape mounts require a great    
deal less people time than permanent tape data sets do. Unfortunately,  
SMF does not record any durations for tape mount time but provides only 
the count of mounts for each step for billing. The TYPE30 step data in  
PDB.STEPS can be used to identify scratch requests from specific volume 
requests.  A work study analysis could be used to identify the ratio of 
time to fetch and mount permanent volumes versus the time to fetch and  
mount scratch volumes, and, thus, the relative cost of a permanent mount
to a scratch mount can be established.  The total cost of tape mounter's
salaries can then be distributed by time to mount a scratch or permanent
tape at different rates, and the job steps causing mounts can be charged
Since the duration and nature of each tape mount is recorded in SMF with
the MXG Tape Mount Monitor, ASMTMNT, it is used not only for chargeback,
but also for monitoring the efficiency with which tapes are mounted.    
The TYPE6 record data in the PDB.PRINT data set provides the data needed
to distribute the cost of printing to the end-user.  The method used in 
distributing these costs depends on the type(s) of printers used.  What 
works for one class might not work for other classes of printers.       
For older line printers, charges based on the number of lines printed is
probably the most accurate and equitable method.  For some of the       
early laser printers (like the IBM 3800-1) the line count can be        
distorted by font changes within lines but counting lines printed is    
still the best method.  The PDB.PRINT variable TOTLINES, which is       
TOTLINES=SUM(PRINTLNE,PUNCHCRD,EXTWTRLN), must be used to count lines.  
Almost all lines printed now are counted in the EXTWTRLN field, because 
IBM changed OUTDEVCE (it used to contain the name of the printer or     
punch, but it now contains the VTAM node name, so PRint versus PUnch can
not be detected, and EXTWTRLN is the fall-thru bucket!).                
PSF printers should be billed based on the number of sheets printed,    
SHEETPRN, which is the number of physical page sides that were printed. 
SHEETPRN per minute is a good printer throughput measure; the printer   
can never produce sheets at more than the rated speed of the printer,   
and thus using SHEETPRN recovers the cost of the individual pieces of   
paper, and the exclusive use of the printer.  Alternatively for PSF, you
may want to consider the use of DOCLENFT (the length of the paper       
printed).  This number is useful because the meter that is read by the  
CE each month is measuring the number of feet of paper that passes      
beneath the print head and thus your printer maintenance bill is        
directly related to DOCLENFT.  There is one small problem with this     
number that only applies to continuous form printers like the IBM       
3800-3.  DOCLENFT is always measured in the direction of paper flow.  In
the case of a cut sheet printer, this is ALWAYS across the 8.5 inch side
of a standard size sheet of paper.  Continuous forms can be obtained    
with the tractor feed on either the 8.5 inch sides or the 11 inch sides 
and the same document can be produced on either stock simply by rotating
the text (which may be as simple as changing the form number.)  Thus a  
100 page job could potentially reflect 70.8 feet one day and 91.75 on   
another simply by changing the paper.  If you are still using the forms 
with the feed on the long side, you may want to evaluate the possible   
cost savings of using the other orientation of the paper.  What about   
PAGECNT?  Don't use it.  To PSF printers, one page is one sheet of paper
whether SIMPLEX or DUPLEX.  Thus a user printing a 100 page document    
DUPLEX would be billed for 50 pages while a SIMPLEX user would be billed
100 pages for the same document.                                        
What is in TOTLINES under PSF?  It all depends: line-mode data counts   
the number of line images spooled in TOTLINES, and PSF-mode data counts 
the number of records spooled, but a record could be single line or a   
multi-page graph.  You can tell that PSF created the type 6 data because
variable SUBSYS6='PSF' (others are: JES2,JES3,EXTW,SAR,EXD,CADI,BUND),  
but there's nothing in the type 6 to identify the print's data mode.    
  Nov 2005 notes:                                                       
  1. TOTLINES can be very large when the record has a file transfer     
     segment (variable SMF6BYTE will be non missing).                   
  2. IBM variable SMF6PRMD does identify LINE vs PAGE mode in SMF 6 PSF 
Print workstation printers (Xerox printers like the 4050, 4090, 4135,   
and 9700s) present other challenges, because they contain their own     
operating systems and disk storage (early Xerox used a PDP 11 inside),  
and the PDB.PRINT information represents only what was sent by JES or   
PSF to the print workstation.  PRINTIME/PRENTIME are the time print was 
transmitted, and not when actually printed.  These printers can store   
the SYSOUT, print the SYSOUT, copy it to tape or floppy, or purge the   
output prior to printing all without notifying the MVS host of the      
action taken!  To further muddy the water, there are commands, called   
DJDEs, that can be sent along with the datastream to modify the number  
of copies, to set print to SIMPLEX or DUPLEX, to set how many logical   
pages are on a physical page, etc.  This all means that any relationship
between the TYPE6 record and what actually happened on these printers is
purely coincidental.  The good news is that there is a Xerox-provided   
facility, SFS, that will create a billing record of each                
job printed with the print facilities actually used, including the      
number of sheets of paper printed and which bins were used.  The        
bad news is that SFS does not automatically send these data records to  
the mainframe, and that you must modify SFS (see the example in member  
ADOCSFS) to add the JOB name and JESNR to the SFS record.               
Although special forms are less common than earlier, they still exist   
and users should be charged for the use and storage of the special forms
that they use.  All of these data sources provide indications of the    
forms that were used and these should be charged based on the operator  
time to mount the form (like a tape mount) and the cost of storing the  
blank forms (like a tape volume.)                                       
TERMINALS, CONTROL UNITS, AND PORTS                                     
If a terminal is shared across applications (for example, a VTAM        
terminal used for CICS, TSO, and CMS), it is difficult to distribute the
cost of that terminal since not all applications provide a connect time 
measure.  It is even worse, if a session manager product is used, for   
the same terminal may be logged on to multiple systems simultaneously.  
If the terminal is exclusively or mostly used by a single application,  
say CICS, then the monthly cost of the terminal and its share of the    
control unit and 3705 can be distributed directly to that application by
fixed monthly charges.  If TSO terminals are shared by different        
departments, the duration of each TSO session and the terminal name are 
both contained in the session data in PDB.JOBS, allowing numerous       
opportunities for distributing the cost of terminals to individual      
departments and identifying which terminals are used by which           
departments.  For terminals used by IMS and CICS, there are no connect  
time records, and cost accounting of terminal usage must be done        
VI.   VM Technical Notes                                                
  1. IBM APAR VM52395 applies to VM/ESA 1.1.1 and corrects invalid      
     values for EXCPPGIN and EXCPPGOU in type 01 VM accounting records. 
VII.  CICS Technical Notes                                              
  1. IBM Document ID Q504977 discusses using the "Main Task" CPU TCB    
     time to determine the "single engine requirement" for a CICS       
     region, but the calculation of "Main Task" CPU TCB in that article 
     is wrong, and produces a CPU measure which is not only not the     
     Main Task CPU time, but in fact is greater than the total CPUTCBTM!
     The article calculated "Main Task" by subtracting the "Wait Time"  
     OSWAITTM (MXG name, OSWTELAT IBM name) from the interval duration. 
     Since the calculation produced a value greater than CPUTCBTM (MXG  
     name, ADSPTIME IBM name), I conclude that OSWAITTM is not capturing
     all of the wait time in the CICS region and have asked IBM for     
     comments.   However, the primary message of that article is good;  
     it is the Main Task CPU time that must be used to determine the    
     single engine requirement, which is why the CICSYSTM dataset in MXG
     contains variables MAINCPTM and SUBTCPTM with their sum CPUTCBTM!  
VIII. SAS Technical Notes                                               
  1. This technical note summarizes my investigation of virtual storage 
     use in a very large BUILDPDB, so that I could better understand    
     MEMSIZE required, and this note is simply technical information.   
     See the subsequent note on MEMSIZE and REGION for recommendations. 
     The virtual storage required by BUILDPDB for I/O buffers is set by 
     SAS options BLKSIZE=, BUFSIZE, and BUFNO=.  The BLKSIZE= option is 
     an attribute of the SAS data library, and it sets the size of the  
     physical block that will be moved to and from DASD.  The BUFSIZE=  
     option is an attribute of each SAS dataset and each SAS dataset in 
     a data library can have a different BUFSIZE.  The BUFSIZE must be  
     a multiple of BLKSIZE.  The default BUFSIZE=0 causes SAS to compute
     an "optimum" BUFSIZE based on the record length of an observation. 
     The BUFNO= option is the number of buffers of size BUFSIZE that are
     allocated in virtual storage.  Each SAS dataset needs BUFNO times  
     BUFSIZE virtual storage.  A very large BUILDPDB (164 datasets vice 
     81 in the default BUILDPDB) was tested with BLKSIZE=4096, BUFNO=2, 
     and with BUFSIZE=24576 and required TOTAL MEMORY=34269K.  That was 
     reduced by 7244K when BUFSIZE=4096 was used; by extrapolation, the 
     total buffer virtual memory required with BUFSIZE=24756 is 8451K,  
     or 25% of the total virtual storage of this SAS data step.  An     
     additional experiment was run to investigate the virtual storage   
     impact of %INCLUDE and oldstyle macro processing (by saving the SAS
     log with source code to disk); it showed that the %INCLUDE and old 
     style macro processing required 6336K virtual storage.  These tests
     are summarized in the following virtual storage map:               
          TOTAL VIRTUAL MEMORY allocated            34269K              
             data set buffers                               (8451K)     
             macros/include processing                      (6336K)     
             generated program size                         (2181K)     
             task memory                                    (4842K)     
          Unidentified (compiler,spvr,etc)          12459K              
     As a final reminder, this 34269K run was a very large BUILDPDB.    
     The default BUILDPDB in MXG 10.1 requires only 14857K! These tests 
     were run using ENTRY=SASHOST, so that all of the virtual storage   
     required came out of the user's address space.  If your site has   
     installed SAS in the LPA and you use entry=SASLPA, you will see a  
     2M to 4M reduction in the virtual storage used by your ASID.       
     While this was informative, it turns out the real value of these   
     tests was the confirmation of my long-held belief that the use of  
     oldstyle (substitution) macros and %INCLUDEs has no significant    
     impact on the cost of execution (save for the 6M virtual storage). 
     The CPU time for the full blown BUILDPDB was 106.0 seconds; the    
     pure code run with no macros nor %INCLUDES was 94.5 seconds!       
       The blocksize used, 4096, IS NOT RECOMMENDED for MXG, but was    
       used so BUFSIZE could be iterated.  MXG still strongly recommends
       all of its SAS data libraries be built with half-track blocksize 
       (23040 for 3380, 27648 for 3390s), which causes BUFSIZE to also  
       be half-track, and with BUFNO=2, SAS will move one track of data 
       per physical I/O operation.                                      
  2. MEMSIZE and REGION.  The SAS option MEMSIZE sets the total virtual 
     storage above AND below the 16MB line that SAS can use.  The "very 
     large" BUILDPDB that needed 34269K total virtual was executed with 
     REGION=4M and MEMSIZE=38M, and the job's SYSOUT message IEF374I    
     shows VIRT 2072K EXT 32768K for a total of 34840K above and below. 
     The EXT 32768K value shows we were limited to 32M above the line,  
     which is the IBM default specified in IEFUSI.  If the job actually 
     needed 42M, the job would fail because the 32M above plus the 4M   
     below total only 36M.  We could have specified a REGION=9M         
     to get a total MEMSIZE of 41M, but the size of your private area   
     (typically 9M max) limits how much you can get below the line!     
     The solution is simple.  Specify a REGION=42M, while overrides the 
     IEFUSI default of 32M, and you can get what you need.  (Note that  
     you cannot specify a REGION value between the private area and 16M,
     but a value greater than 16M is valid.   Since the default BUILDPDB
     in MXG 10.1 requires only 15M, few sites should have a problem!    
    -z/OS 1.12 message IEF032I/33I replaced IEF374I/276I.               
  3. SAS options can be restricted by your site's SAS installer. The    
     restrictions are in BAMISC(SASOPTRS) used by job BAOPT2(BAOPT2),   
     which creates a load module named SASOPT73 (was SASOPTRS in 6.06), 
     that must be in a linklist library.  So how do you know that your  
     installer created this module?   From TSO "READY", simply type in  
     SASOPT73.  If you get a "COMMAND NOT FOUND" message, then there    
     are no local restrictions in effect; if you ABEND, you have the    
     proof that there are local restrictions placed on SAS options!     
  4. Multi-volume SAS datasets can be created as described in the       
     "SAS Companion for the MVS Environment", pages 533-534, but that   
     implementation requires permanent datasets to be allocated and     
     cataloged, and is not well suited for temporary data libraries like
     //WORK that may need multiple volumes!  Sites with System Managed  
     Storage, SMS, have what appears to be a superior solution that does
     allow SAS to use multi-volume data libraries for temporary files.  
     You need only to have your SMS Storage Administrator create an SMS 
     Storage Class with the "Guaranteed Space" attribute. Since a volume
     can be in multiple storage classes, you can put your existing DASD 
     temporary workspace volumes in this STOCLASS.  You then need only  
     to specify this STOCLASS for your WORK DD, with UNIT=(SYSDA,3), and
     with VOL=SER=(VOL1,VOL2,VOL3) and you are home free!  This works   
     because the "Guaranteed Space" attribute does two things.  First,  
     it permits you to specify a VOLSER on your DD (normally, only SMS  
     itself can be the VOLSER godzilla!).  Second, it allocates one     
     primary extent on each VOLSER you specify, thereby creating a DSCB1
     entry with the same DSNAME in each VTOC, which is all that is      
     really required for SAS to be able to use the multiple volumes.    
     Note that the SMS name "guaranteed space" is a slight misnomer,    
     since SMS can't guarantee there will be free space on the volumes, 
     but it does guarantee that if the space you allocated is available 
     at initial allocation time, it will still be there until the job   
     ends.  (In a non-SMS environment, UNIT=(SYSDA,3) allocates only the
     first volume until it needs to go to the next volume, and your job 
     could die hours into its run if that third volume was full when you
     finally needed it.)  The IBM SMS manuals advice caution in the use 
     of "guaranteed space"; the only rationale I know is concerned with 
     archived and then restored by HSM, which requires the same VOLSERs 
     to have space for the restore, but that does not apply if your use 
     is for a temporary library that goes away at end of job!  Your DASD
     storage administrator may not like it because it takes control away
     from SMS, but I know of no other objection, and this technique has 
     been in use by its discoverers, John Astle and Wayne Moray-Hype of 
     National Australia Bank for three months with no problems.  By the 
     way, you could write ACS routines to select the VOLSERs and would  
     then not have to specify them on your DD statement.  Additionally, 
     this technique can be used with a temporary or permanent DSNAME.   
  5. SAS 6.07 CMS had a problem with %INCLUDES; only the first library  
     in a concatenation was examined.  Tracking 248801 is still open,   
     but using GLOBAL statement (see REXXTES6 example) circumvents!     
  6. SAS 6.07 ZAP Z6074721 corrects 0C4 ABEND in the %MACRO compiler if 
     a double ampersand (&&) was encountered.                           
  7. Usage note 2665 (to be fixed in September 93 Maintenance) discusses
     an ABEND of PROC COPY when a zero-observation dataset that has the 
     "Sorted" flag turned on is copied to a tape-format data library.   
     This ABEND only hit one MXG site, but since many sites copy their  
     Daily and Weekly PDBs to tape with PROC COPY (in fact, that is the 
     MXG recommendation for archiving), why did we not see this ABEND in
     MXG testing of SAS 6.07?  Well it turns out there are two different
     kinds of zero-observation datasets, and the ABEND affects only one.
     In SAS 6.07, a dataset now has a "Sorted" flag if that dataset is  
     known to be sorted by SAS (a "strong SORT assertion").  But if you 
     PROC SORT an input zero-observation dataset to an output dataset,  
     the "Sorted" flag is not enabled in the new dataset.  Since all of 
     the MXG-built zero-observation datasets are built by PROC SORT from
     zero-observation input datasets, none have the "Sorted" flag on,   
     and thus PROC COPY of MXG PDB's to tape did not fail.  How do you  
     build a zero-observation dataset with the "Sorted" flag on?  Well, 
     here's one way:   OPTIONS OBS=0; PROC COPY IN=MON OUT=SAT; RUN;    
     to initialize a PDB library with zero-observation datasets.  While 
     the MON.datasets that had zero observations are copied into SAT as 
     "NotSorted", all of the MON.datasets that had non-zero observations
     are copied into SAT now as "Sorted", and if you now try to use a   
     PROC COPY IN=SAT OUT=TAPE (for example, to backup the SAT library),
     the PROC COPY ABENDed!   As you can see, the exposure to this SAS  
     error was extremely limited - in fact, only one MXG site reported  
     the error, though the problem did affect other SAS customers!      
       Note: the MXG Circumvention without the September maintenance    
       is to not backup SAT until you have put data in it!              
  8. INVALID HEADER for a dataset in the WORK library has occurred in   
     three sites, ABENDing the job, but a re-run has (thus far) always  
     been successful.  Since the error has not been repeatable, the SAS 
     Institute folks can't work on the problem.  Tracking 256220.       
  9. Complex nested parenthesis inside a SUM() function can result in   
     invalid values.  This has not occurred in any MXG use of SUM(),    
     but was noticed in user report code.  Zaps Z6073413,2570,and 4338  
     are required to eliminate the exposure.                            
      BECAUSE OF ERRORS" with no other error condition. The error occurs
      when the input dataset has zero observations, and is corrected by 
      SAS Zap Z6071258.                                                 
 11. SAS 6.07 may go into a CPU loop if the //WORK DD specifies multiple
     volumes with UNIT=(SYSDA,3).  As described in item 4, above, you   
     cannot use that MVS multi-volume specification for SAS libraries.  
 12. Although documented by SAS on page 65 of the SAS 6.07 Changes and  
     Enhancements, you may have overlooked that the XSWISS font name    
     no longer exists, and it must be replaced with SWISS.              
 13. SAS 6.07 may fail with an 0C4 ABEND due to an error in the SAS     
     Data Step Compiler.  Temporary ZAP V6-SYS-DATA-5266 corrects the   
     problem (it will be on the May 1993 SAS Usage Notes tape) and this 
     problem appears to be avoided in SAS 6.08, so this is presently a  
     6.07-only problem.                                                 
 14. SAS 6.07 error in the CCHHR option causes VMXGVTOC to miss extents 
     and produce "CRITICAL ERROR IN VTOC PROCESSING" if there are more  
     than three extents.  SAS ZAP V6-SYS-FILE-4673 is available on the  
     June 1992 SAS Usage Notes Tape.  This error was apparently only in 
     the CCHHR option, and not the similar but different CCHHR= option. 
     This error did not affect the recommended alternative to VMXGVTOC, 
     the ASMVTOC/VMXGVTOF members which are faster, better, and do not  
     use either CCHHR or CCHHR= options. This note was in Newsletter 22.
 15. MXG has always shown JCL samples using the SAS or SAS607 procedure,
     adding the CONFIG= parameter, and DDs for //LIBRARY and //SOURCLIB,
     but now there is an MXGSAS JCL Procedure in the MXG Source Library.
     All MXG JCL examples now use // EXEC MXGSAS to minimize JCL errors 
     for new users, and member INSTALL expects you to put MXGSAS in your
     Proclib.  However, MXGSAS is also an instream PROC in JCLTEST6 and 
     JCLPDB6 members, so you can test before putting it in PROCLIB.     
     Since the new install procedure suggests 'MXG.V1010.x.y' as the    
     High-Level for your testing of MXG 10.10, and then renaming the    
     'MXG.V1010.x.y' libraries to 'MXG.x.y' Production names,  MXGSAS   
     defines MXGHLQ= as the MXG Hi-Level Qualifier, and SASHLQ for SAS  
     Hi-Level Qualifier, so Testing would use                           
         //  EXEC MXGSAS,MXGHLQ='MXG.V1010'                             
     and after you have renamed the test libraries to production, only  
         //  EXEC MXGSAS                                                
     is required.  Note that CONFIG=MXG.MXG.SOURCLIB(CONFIG07) is not   
     required with MXGSAS, as (CONFIG07) is already inside the PROC.    
     For large volumes of input records, you can specify TIME= in CPU   
     minutes, WORK= space in cylinders (and in rare cases, SORT= wor    
     space in cylinders).                                               
IX.   Change 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 of the MXG SOURCLIB will always be more accurate than   
 the printed changes in a Newsletter, because the software is created   
 after the newsletter is sent to the printer!                           
 Member CHANGES always identifies the actual version and release of     
 MXG Software that is contained in that library.                        
 The actual code implementation of some changes in MXG SOURCLIB may be  
 different that described in the change text (which might have printed  
 only the critical part of the correction that can be made by paper).   
 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.                     
Alphabetic INDEX of significant changes in MXG 10.10 (since MXG 9.9):   
  Member    Change   Description                                        
  All      10.175  Powerful new "_L" and "_K" macros tailor MXG datasets
  All      10.261  Support for MVS/ESA 4.3.                             
  ADOCAAAA 10.087  Twenty-Five ADOCs documentation members now exist.   
  ANALDB2R 10.001  DB2 Report truncated character values.               
  ANALDB2R 10.034  SORTBY= operand parsed only the first SORT variable. 
  ANALDB2R 10.046  LIBRARY SMF IS NOT VALID message with PMSQL04 report.
  ANALDB2R 10.047  DBID/OBID hex values printed instead of name.        
  ANALDB2R 10.055  Date/time selection in PMSACC01/02 produced no report
  ANALDB2R 10.094  ANALDB2R Accounting report uses ASUMDB2A if exists.  
  ANALDB2R 10.135  DB2 Audit report may not be produced.                
  ANALDB2R 10.158  DB2 SQL Trace report FORMAT NOT FOUND error.         
  ANALDB2R 10.272  Buffer Pool statistics average values wrong.         
  ANALDSET 10.097  VSAM data sets may have wrong PROGRAM name.          
  ANALMONI 10.066  TMON/CICS sample report filled WORK file.            
  ANALRMFR 10.301  IBM's RMF reports produced from MXG datasets.        
  ANALRMFR 10.301  IBM-formatted RMF reports are now produced by MXG.   
  ASMIMSLG 10.084  Major revision in IMS log processing algorithms.     
  ASMIMSLG 10.142  Revision to "Appended" IMS log processing.           
  ASMIMSLG 10.191  "Appended" IMS process might miss RACF segment       
  ASMISMLG 10.146  New "Appended" IMS log processing works with IMS 2.2.
  ASMTMNT  10.012  MXG Tape Mount Monitor supports Dynamic I/O Reconfig.
  ASMTMNT  10.136  (MXG 10.1 only). ABEND S55F at startup.              
  ASMTMNT  10.226  MXG Tape Monitor sets TMNTRTRN=3 for MIM event.      
  ASMTMNTO 10.177  MXG Tape Mount Monitor for sites still on MVS/XA.    
  ASMVTOC  10.073  Avoid 213/314 abends reading VTOC of VM/TPF volumes  
  ASMVTOC  10.157  (MXG 10.1 only). Assembler error MSGAREA.            
  ASMVTOC  10.202  Use ASMVTOCO for ASMVTOC under MVS/ESA 3.1.3.        
  ASMVVDS  10.156  ASMVVDS fails with User 666 Abend.                   
  ASUM70PR 10.131  PR/SM,MDF,MLPF summarization now supports 16 LPARs.  
  ASUM70PR 10.218  MXG 10.2 only, corrupted Effective/Management times. 
  ASUM70PR 10.284  Amdahl MDF LPARNUM=0 now supported.                  
  ASUMDB2A 10.090  DB2 Account "transactions" summarized into ASUMDB2A. 
  BUILDPDB 10.117  BUILDPDB under SAS 6.07 needs changes.               
  BUILDPDB 10.129  Execution under CMS requires changes.                
  BUILDPDB 10.153  Step account variable SACCT1 now added to PDB.       
  BUILDPDB 10.190  JES APAR OY56235 filling SPIN library circumvention. 
  BUILDPDB 10.298  TOTLINES added to PDB.PRINT dataset.                 
  CMS      10.129  SAS 6.07 under CMS has problems for MXG.             
  CONFIG07 10.109  Option S=72, s2=72 added to MXG Config members.      
  EXCICJRN 10.132  New exit for CICS journal data sent to SMF.          
  EXTY72   10.064  CPURCTTM PTF now exists, circumvention removed.      
  GRAFDB2  10.151  Not all DB2 graphs were produced.                    
  GRAFLPAR 10.052  LPAR CPU utilization reports added.                  
  GRAFTRND 10.049  Graphic trending reports were not always correct.    
  GRAFxxxx 10.227  SAS 6.07 replaced XSWISS font name with SWISS.       
  IMACACCT 10.119  Invalid type 30 subtype 1 SMF caused INPUT STATEMENT.
  IMACDB2  10.149  CORRNAME/CORRNUM set from QWHCATYP now.              
  IMACDOS  10.168  Support for VSE DOS POWER Version 4.2 account records
  IMACFACO 10.100  Fujitsu's FACOM MSP/EX SMF records now supported.    
  IMACFMTS 10.173  Member made archaic by SAS 6.07 FMTSEARCH option.    
  IMACICSA 10.164  Support for SAP Accounting data in CICS type 110.    
  IMACICUS 10.297  Optional HOGAN application variables in CICSTRAN.    
  IMACPDB  10.053  New macro _DB2ACCT added. Compatibility exposure.    
  IMACPDB  10.068  TAPE3490 (3490s allocated) added to PDB.STEPS/JOBS.  
  IMACPDB  10.133  PDB.JOBS can have JELPSTM missing when it should not.
  JCLPDB6  10.127  (MXG 10.1 only) JCLPDB6 fails, TYPETMNT not found.   
  JCLTEST6 10.030  INVALID DATA FOR SMFTIME, SAS zap MV313550 required. 
  MNTH.... 10.091  Trending with INTERVAL=MONTH members added.          
  MONTHBLD 10.206  All JCLPDB6 PDB & ASUM.... datasets are in MONTHBLD. 
  READDB2  10.045  TRACECLS= parameter does not select all IFCIDs.      
  RMFINTRV 10.299  Additional statistics added to RMFINTRV dataset.     
  TRNDDB2A 10.093  TRNDDB2A Account Trending uses ASUMDB2A if exists.   
  TTXPDS   10.111  Verstand's TTX product is now included in MXG.       
  TYPE102  10.072  DB2 SQLCODE can be negative, MXG read as positive.   
  TYPE102  10.170  DB2 Trace IFCID 172 and 177 now tested and supported.
  TYPE102  10.174  DB2 optimizer's cost estimate was incorrect.         
  TYPE102  10.183  DB2 Trace statement Numbers now print as decimals.   
  TYPE102  10.281  DB2 T102S044 lock fields were incorrect.             
  TYPE110  10.017  Invalid type 110 subtype 2 could cause MXG to loop.  
  TYPE110  10.038  Omegamon error causes INVALID DATA FOR SMFPSRSN.     
  TYPE110  10.059  Type 110 STOPOVER due to bad record eliminated.      
  TYPE110  10.061  Support for CICS/ESA 3.3.0 monitor (CICSTRAN) data.  
  TYPE110  10.062  Support for CICS/ESA 3.3.0 statistics datasets.      
  TYPE110  10.234  Enhanced CICS error messages for EXCLUDE/INCLUDE.    
  TYPE110  10.278  OMEGAMON/CICS V550 DATACOM SPE is incompatible.      
  TYPE110  10.280  Fourth TCBs CPU time was not included in CICINTRV.   
  TYPE24   10.037  Spool off-load type 24 can cause STOPOVER abend.     
  TYPE28   10.095  Blue Line's Vital Signs for VTAM type 28 supported.  
  TYPE28   10.106  NPM 1.5.1 NPMEVX25 (subtypes 144-150) error fixed.   
  TYPE28   10.134  Line PCTBUSY in each direction measured separately.  
  TYPE28   10.141  (MXG 10.1 only). INVALID DATA FOR NPMPDUTH.          
  TYPE28   10.155  NPM variables LLBSSTIM/LLBSPTIM incorrect.           
  TYPE28   10.264  Support for NPM Release 1.6                          
  TYPE30   10.031  Variables ACTDLYTM, RESDLYTM, DSPDLYTM created.      
  TYPE30   10.108  Some APPC variables in TYPE30 have wrong value.      
  TYPE33   10.232  Error in processing SMF type 33 (APPC) records.      
  TYPE37   10.098  System Center's NETMASTER type 37 SMF record support.
  TYPE37   10.167  Support for Type 37 Network Alert APAR OY49717.      
  TYPE39   10.040  INPUT STATEMENT EXCEEDED for subtype 5.              
  TYPE40   10.065  New dataset TYPE40_D can be created for tape analysis
  TYPE41   10.015  DIV type 41 SMF record timestamps mis-documented.    
  TYPE42   10.005  Type 42 SMF record causes STOPOVER ABEND.            
  TYPE6    10.003  PSF type 6 record had FORM truncated.                
  TYPE6    10.124  Incompatible change to type 6 SMF record by PSF.     
  TYPE6    10.139  PRUWTR type 6 SMF record has incorrect READTIME.     
  TYPE6156 10.255  VSAM Data and Index component names & SMS data added.
  TYPE70   10.256  TCP/IP SMF record defaults to type 70!               
  TYPE70   10.260  Negative CPUACTTM/PCTCPUBY in TYPE70 with PR/SM/     
  TYPE7072 10.010  TYPE70PR variable NRPRCS corrected.                  
  TYPE7072 10.042  PCTRDYWT variable now created.                       
  TYPE7072 10.317  GMT Offset, GMTOFFTM, available in MVS/ESA 4.3.      
  TYPE70x  10.320  Support for OpenEdition MVS, OMVS, RMF records.      
  TYPE71   10.014  SWAP counts corrected.                               
  TYPE73   10.179  ESCON converter flag variable ESCACVC not set.       
  TYPE73   10.247  MVS/ESA 4.2.2 EMIF Feature corrupts TYPE73 data set. 
  TYPE73   10.259  Only real channels create TYPE73 observations now.   
  TYPE74   10.137  MVS/ESA XCF Type 74 causes INPUT STATEMENT EXCEEDED. 
  TYPE75   10.099  MVS/ESA 4.2.0 changed format of DEVNR/UNITADR.       
  TYPE78   10.201  CMF Type 78 incorrect R783CPDN value causes 0 obs.   
  TYPE79   10.123  Type 79 subtype 1 corrections.                       
  TYPE79   10.283  RMF 79 records appear to be un-deaccumulatable.      
  TYPE80A  10.251  RACF events consolidated in new TYPE80A dataset.     
  TYPE84   10.224  JES3 type 84 INPUT STATEMENT EXCEEDED error.         
  TYPE94   10.285  Support for IBM 3495 Tape Library Dataserver SMF.    
  TYPEAICO 10.048  Support for AICorp's KBMS user SMF record.           
  TYPEAIM6 10.161  Support for FACOM's AIM Version 12 type 116 SMF.     
  TYPEAPAF 10.078  Support for Amdahl's APAF replacement for MDFTRACK.  
  TYPEAPAF 10.143  Variable Balance not kept in APAFDOMA                
  TYPEASTX 10.245  Support for Legent's ASTEX Trace Record              
  TYPECIMS 10.063  IMF flag variables wrong if multiple bits are on.    
  TYPECMF  10.230  Boole's CMF variable R783PT in error.                
  TYPECMF  10.292  Support for IMF Release 2.8.                         
  TYPEDB2  10.024  MVS Account fields added to DB2ACCT!                 
  TYPEDCOL 10.221  DCOLLECT variable UCTOTAL was incorrectly documented.
  TYPEDCOL 10.307  DCOLLECT SMSDATA writes SMF constructs records.      
  TYPEF127 10.162  Support for FACOM PDLF Type 127 for MSP/EX Version.  
  TYPEFTP  10.176  NETVIEW FTP SMF record timestamps reversed.          
  TYPEHIPR 10.300  Support for Empact's HiperCache SMF records.         
  TYPEHPCS 10.178  Support for HP Unix (HP/UX) PCS Performance Data.    
  TYPEHPCS 10.294  HP's MPE operating system records now supported.     
  TYPEHSM  10.080  FSTTRKR/W large values are actually negative values. 
  TYPEIDMS 10.219  IDMS variable DBKDBKEY was incorrectly documented.   
  TYPEIDMS 10.265  Support for IDMS Release 12 PM records confirmed.    
  TYPEILKA 10.121  Invalid data because incorrect offset/documentation. 
  TYPEIMSA 10.205  NMSGPROC value wrong. Must use ASMIMSLG for IMS log. 
  TYPEIMSA 10.288  Zero service time corrected.                         
  TYPEITRF 10.273  Support for Candle's IMS Trans Report Facility,ITRF. 
  TYPEM204 10.120  MODEL204 variable M24IODEV input, EXM24ACT eliminated
  TYPEMON8 10.020  Landmark CICS "INVALID OFFSETS" message.             
  TYPEMON8 10.067  MONITASK variables STRTTIME/CREATIME now equal.      
  TYPEMON8 10.145  Landmark CICS variable TAMRCNT input incorrectly.    
  TYPEMON8 10.271  Support for Landmark's/CICS Release 9 and Release 1. 
  TYPENATP 10.033  Support for Software Ag "Natural Process" SMF record.
  TYPENETP 10.039  NETPACTM was total response, should be average.      
  TYPENRS  10.075  Support for The Network Director North Ridge Software
  TYPENSPY 10.015  Support for NETSPY Token-Ring records added.         
  TYPENSPY 10.057  Support for NETSPY Release 4.2 added.                
  TYPENSPY 10.144  NETSPY type 'N' records cause INPUT STATEMENT EXCEED.
  TYPENSPY 10.262  Support for NETSPY Release 4.3 and LANSPY 1.1        
  TYPEOMCI 10.182  Omegamon V550 ESRA (user) SMF "INPUT EXCEEDED".      
  TYPEOMVT 10.194  Support for OMEGAMON II for VTAM V150 user SMF.      
  TYPEOPC  10.112  Major revision for OPC/A log processing.             
  TYPEOPC  10.204  Support for Changes to OPC records.                  
  TYPEOPC  10.302  RECFM= parameter removed so RECFM=U data can be read.
  TYPEORAC 10.291  Support for Oracle                      
  TYPEPOOL 10.274  Support for Empact's POOL-DASD user SMF record.      
  TYPEQAPM 10.110  Support for AS400 V2R1M0 and restructured members.   
  TYPERMDS 10.102  RMDS messages INVALID DATA FOR RMDSMXVR eliminated.  
  TYPEROSC 10.022  Support for ROSCOE Release 5.7 changes to SMF data.  
  TYPEROSC 10.101  ROSCOE ADSFUN.. variables values corrected.          
  TYPEROSC 10.138  ROSCOE JCK and Documentview added to ROSCOVPE.       
  TYPERSxx 10.319  Support for RS6000 AIX VMSTAT,IOSTAT,PS commands.    
  TYPESFS  10.186  Support for XEROX Printer's SFS Status File System.  
  TYPESIM  10.180  Support for SIMWARE SIM/XFER VTAM user SMF record.   
  TYPESIM  10.222  SIMWARE initial support revised.                     
  TYPESLRI 10.290  SLR-like IMS log processing for Fast Path.           
  TYPESMF  10.019  Header/Trailer messages on log were not always right.
  TYPESPMS 10.011  SPMS R2.1.4 invalid record circumvented.             
  TYPESPMS 10.069  SPMS 1.2.13 inserted four byte field, causing errors 
  TYPESTC  10.105  STC 4400 decode used wrong bits of STC07TYP.         
  TYPESTC  10.116  STC4400 HSC SMF record for Release 1.2 incompatible. 
  TYPESTC  10.193  STC 4400 Silo HSC variables formatted.               
  TYPESTC  10.229  STC 4400 variables LSBECON1/2 incorrectly documented.
  TYPESYNC 10.115  SYNCSORT variable COREREQ can be negative.           
  TYPETCP  10.184  Support for IBM's TCP/IP Version 2 Release 2 SMF.    
  TYPETIRS 10.181  Support for IBM type 96 SMF record from TIRS.        
  TYPETMNT 10.200  Legent's MIM corrupts MXGTMNT Tape Mount count.      
  TYPETMS5 10.060  TMS inactive DSNBs now deleted, caused wrong VOLSER. 
  TYPETMS5 10.082  TMS.TMS had DSNB fields, TAPEFEET calculation changed
  TYPETMS5 10.185  DSNBs could have been skipped.                       
  TYPETMS5 10.196  TMS Billing-by-dataset enhanced in DSNBRECD dataset. 
  TYPETMS5 10.289  "Dead" tapes no longer create DSNBRECD observation.  
  TYPETMVS 10.058  TMON/MVS "INVALID DATA for WKLCPURF" message.        
  TYPETPX  10.007  TPX variable TPXELAP has wrong value.                
  TYPEVM   10.233  VMSQLxxx datasets enhanced for SQL/DS under VM.      
  TYPEVMXA 10.036  VM/ESA 1.1.1 additions now supported.                
  TYPEVMXA 10.071  VM/ESA VXSYTCUP dataset has only 49 observations.    
  TYPEVMXA 10.163  Candle's VCOLLECT 5.1.0 still writes invalid "VVBs". 
  TYPEVMXA 10.244  Support for VM/ESA Release 2.0.                      
  TYPEWSF  10.081  Support for RSD's WSF/WSF2 Release 3.4.1.            
  TYPEWSF  10.150  WSF 3.3.6 caused error (no problem with 3.4.1).      
  TYPEX37  10.013  STOPX37 Release 3.4 is supported.                    
  TYPEX37  10.276  Support for Empact's STOPX37 Release 3.5.            
  TYPEXAM  10.231  Support for Velocity Software's XAMAP History files. 
  TYPEXCOM 10.165  Support for XCOM 6.2 Version 2.2.2G SMF record.      
  VMXGHSM  10.254  HSM dates TTOCDLR and TTOCXPDT were wrong.           
  VMXGSUM  10.089  MINTIME=,MAXTIME= parameters added to VMXGSUM.       
  VMXGVTOC 10.054  ISAM index space not recognized in VTOC.             
  VMXGVTOC 10.243  SAS 6.07 ZAP V6-SYS-FILE-4673 required.              
  VMXGVTOF 10.125  Variable DS4VTOCE input but not kept.                
  VMXGVTOF 10.171  VTOCs with freespace starting in track 1 missed it.  
  WEEKBLD  10.008  NOT SORTED when implementing MXG 9.9                 
  WEEKBLD  10.009  TYPE70PR,DB2ACCT/STAT0/STAT1 added to weekly/monthly.
  WEEKBLD  10.206  All JCLPDB6 PDB & ASUM.... datasets are in WEEKBLD.  
  WEEKBLD  10.225  BY list for WEEK.ASUM70PR wrong.                     
  XMAC7072 10.023  344 Compiler circumvention causes UNINITIALIZED msg. 
  XUNIX    10.076  Support for ULTRIX UNIX iostat and vmstat commands.  
Inverse chronological list of all Changes:                              
---Changes 10.323-10.105 were printed in MXG NEWSLETTER TWENTY-THREE--- 
     and can be found in member CHANGES of MXG Version 10.10