****************NEWSLETTER THIRTEEN*************************************
             MXG NEWSLETTER NUMBER THIRTEEN  JAN 20, 1989               
Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE
 This Newsletter accompanies the production shipment of MXG Version 6.6.
I.  MXG SOFTWARE VERSION 6.6                                            
    1. The thirty-seven major enhancements in MXG Version 6.     page  2
    2. Installation instructions.                                page  3
    3. Compatibility considerations.                             page  4
    4. Documentation.                                            page  5
II. ADMINISTRATIVE ANNOUNCEMENTS                                        
    1. "CPE Reporting System" tape to be sent to you by SAS.     page  6
    2. MXG Software default media.                               page  6
    3. MXG Newsletters are now "online".                         page  6
    4. 1989 Planning.                                            page  7
III.TECHNICAL NOTES                                                     
    1. HOT PTFs: MVS                                             page  8
    2. HOT PTFs: VM                                              page  8
    3. Technical Notes, IBM                                      page  8
    4. Technical Notes, MVS                                      page  9
    5. Technical Notes, VM                                       page 12
    6. Technical Notes, SAS                                      page 15
IV. Change log.                                                  page 16
     Changes through Change 6.206 - 6.058                   thru page 46
I.  MXG SOFTWARE VERSION 6.6                                            
The Production release of MXG Version 6 is MXG 6.6, January 15, 1989.   
The library is at Change 6.206, and MXG 6.6 produces 552 datasets with  
18048 variables from its 911 members, and creates 151 SASLIB formats.   
 1. The major enhancements in MXG Version 6.                            
 a. Support for the documented MVS/ESA changes in SMF and RMF records.  
    SMF changes include JESNR changes in SMF 6, 26, and 30 records now  
    that up to 99999 JES numbers are allowed.  This caused several      
    changes in SMF data.  The change was needed by IBM because lots of  
    sites found the 9999 job limit was eaten up by jobs left on spool!  
    The old 4-byte JESNR field will be zero and the JESNR will be in the
    JCTJOBID field instead, which could affect your installation's JES  
    mods, if they used the old 4-byte JESNR instead of JCTJOBID.  The   
    MVS/ESA support includes RMF 3.5, RMF 4.1.0 and RMF 4.1.1 changes.  
 b. Support for PR/SM changes to TYPE70 CPU measures.  First,there is a 
    new TYPE70PR data set created by MVS 2.2's partition which describes
    the processor utilization of all partitions (not just this MVS      
    2.2).  Second, the TYPE70 CPU busy now uses the PDT partition       
    dispatch time to correct the MVS CPUBUSY and CPUWAIT variables.     
    (PR/SM puts zeroes in the old CPUWAIT field and stores partition    
    busy time in a new data segment). Third, read IBM's disclaimers in  
    the RMF User's Guide on what is and is not measured. Fourth, under  
    PR/SM you cannot know the actual hardware CPU busy of individual CPU
    engines, but do get the overall activity of all engines. (If you    
    have Vector Processors this could be a problem, since you will no   
    longer know CPUBUSY for the CPU engine to which the VP is attached.)
 c. VM/XA SP1 and SP2 Monitor support and reports (35 reports so far).  
    See extensive discussion below under Technical Notes, VM.           
 d. Support for DB2 Version 1 type 102 trace data records. Many DB2     
    reports similar in format to DB2PM are now produced by ANALDB2R.    
 e. Support for NPM 1.3 new type 28 SMF record. This record replaces the
    type 38 (NPA/NPM), type 39 (NLDM) and VSAM VTAM Session statistics  
    (MXG's XNPMSESS) data sources. Twenty eight data sets are created   
    from TYPE28, all now start with NPM..... and a number of variable   
    names were changed. Member VMAC28 cross-references these changes for
    your reports.  Support includes Network Gateway Accounting too!!!   
 f. IMS log record processing was completely re-written (in MXG 6.4) to 
    capture individual transaction response, even for Message Switches  
    WFI (Wait for Input) programs. Prior MXG logic captured only program
    schedule events (07 record), like IBM's DFSILTA0 utility. Separate  
    responses are measured for each transaction event, and TYPEIMS now  
    supports the IMS 2.2 log record format changes made by IBM.         
 g. Support for IDMS-R 10.2.1 Performance Monitor SMF records.          
 h. Support for IMF Version 2.5 has been added.                         
 i. Support for NETSPY Release 3.1.                                     
 j. Support for EPILOG 1000 (CICS) Release 4.30.                        
 k. VM/SP Release 4 and 5 Monitor validation corrections were made and  
    enhanced summary reports match VM MAP numbers better.               
 l. Goal Systems EXPLORE/VM records are now supported.                  
 m. VPS (a SYSOUT handler) support in TYPE6 data set.                   
 n. EXD (a SYSOUT handler) support in TYPE6 data set.                   
 o. CA-DISPATCH (a SYSOUT handler) support in TYPE6 data set.           
 p. $AVRS (a SYSOUT handler) support in TYPESAVR data set.              
 q. Landmark Version 7.1 support.                                       
 r. CICS 1.7 UOWTIME variable decoded for the (undocumented) third data 
    format for both CMF and Landmark records.                           
 s. Building MONTHLY PDBs using only one tape drive now always works.   
 t. Support for RMDS Release 3.0 SMF record.                            
 u. ASMVMCOPY (assembly source) and REXXCOPY (an exec) permits a VM/SP  
    site to "dump" their VM/Monitor spool records to a CMS file. Without
    this program, you either used VM MAPs MONTAPE/MONDISK command or you
    used the SAS MONITOR INFILE exit to "dump" the VM/SP Monitor data.  
 v. Support for AIM database manager records from FUJITSU's FACOM OS.   
 w. Support for type 1, 127, and 234 records from FACOM OSIV/F4.        
 x. Support for SAS user SMF record (PROC/DATA step resources).         
 y. Support for CA-ROSCOE Release 5.6                                   
 z. Support for 3990-3 Cache DASD RMF Reporter (user) SMF records.      
aa. Support for Duquesne's DASDMON SMF record.                          
bb. IDMS 10.2 exits 05 and 13 ASM code for TYPE200-203 MXG datasets.    
cc. Support for Duquesne's TPX Session Manager SMF record.              
dd. Support for SQL/DS VM/Account records.                              
ee. Support for STC 4400 Tape Silo SMF record.                          
ff. Support for HSM data records.                                       
gg. Support for COM-PLETE SMF records.                                  
hh. VSAM DASD measurement with ASMVVDS program to read VVDS and         
    create SMF data record for DASD management and chargeback.          
ii. MXG Newsletters online in member NEWSLTRS.                          
ii. Initial implementation of the "fabled" MXG Trend Data Base          
    with examples of CICS, RMF, etc. weekly/monthly/etc trending.       
  All reported 5.5 problems have been fixed in this release.            
  See the Change log and read the comments in the  referenced  MXG      
  source member for complete details of these enhancements and changes. 
 2. Installation instructions.                                          
  Installation instructions are in Chapter 32 of the MXG Supplement.    
  (which are also contained in member INSTALL of the source library.)   
  However, since those instructions were written, MXG has expanded!     
  The SASLIB MXG format library must be re-allocated with the SPACE     
  parameter of CYL(1,1,99), because there are now 151 formats in this   
  library, and the original MXG Guide showed only 10 directory blocks!  
  The MXG formats are then created in the SASLIB PDS by the first step  
  of JCLTEST, which executes a PROC FORMAT. Unfortunately, if there is  
  not enough directory space, PROC FORMAT only prints a cryptic message 
  ("STOW FAILURE") on the SAS log, and does not set a return code. You  
  will discover the actual error only later when you get SAS error 170  
  FORMAT NOT FOUND, when you run an MXG job that now needs one of the   
  MXG formats expected in SASLIB!  (Actually, only 26 directory blocks  
  are currently required, but why not plan for the future with 99!)     
  Similarly, the allocation for SOURCLIB needs to be increased to the   
  present recommendation of CYL,(25,5,199) with the DCB parameter set   
  to RECFM=FB,LRECL=80,BLKSIZE=23440, (with 130 directory blocks used). 
 3. Compatibility considerations.                                       
  This library is a complete replacement for the Version 5.5 (or prior) 
  MXG.SOURCLIB data set. It is forward and backward compatible with all 
  data sources (eg., it still processes MVS/370 as well as new MVS/ESA  
  changed records.)  The sooner you install it, the less likely you are 
  encounter an error condition which is fixed in this Version!          
  These are the known exposures which you must protect when you install 
  this (or any) new version of MXG. (Users report it takes a half-day.) 
  First, there MUST be no VMAC.... members left in your USERID. library 
  when you install a new MXG version. Since MXG uses %INCLUDE to pickup 
  its macro definitions, if you have a VMAC.... member in your library  
  concatenated ahead of MXG, you will not pickup the new MXG macro and  
  instead will execute a (probably modified) macro from a prior version 
  of MXG.  In the past, some leading edge sites found it necessary to   
  make "emergency" changes to a VMAC.... member and had copied it into  
  their USERID library.  Those VMAC.... members in your USERID.SOURCLIB 
  library MUST be removed when the new version of MXG is installed.     
  TO YOUR SITE. The IMAC.... & EX...... members are designed to allow   
  ALL installation tailoring to be external to the VMAC.... members.    
  See the MXG supplement pages 134ff or call for help, but please avoid 
  storing VMAC.... members in your USERID.SOURCLIB library.             
  Second, BUILDPDB and BUILDPD3 must not be in your USERID.SOURCLIB, for
  the same reasons as the VMACs. MXG Supplement pages 137ff show how you
  can add new data sets or change their contents with the EXPDB... and  
  IMACKEEP exits.                                                       
  Third, we create an unavoidable compatibility exposure to your MXG    
  system whenever we change an IMAC.... member that you have already    
  modified into your USERID.SOURCLIB library.  YOU MUST compare the     
  following list of changed IMAC.... members with the members of your   
  USERID.SOURCLIB, and if the member exists in your library, you must   
  retro-fit your tailoring into a copy of our new IMAC.... member. The  
  change number(s) describing what we changed, as well as comments in   
  each member itself, should aid in your tailoring.                     
        IMACs in MXG 5.5              Read Change Number                
        that were changed                                               
          IMACACCT                       6.131                          
          IMACCICS                       6.148                          
          IMACEPIL                       6.091, 6.013                   
          IMACICDL                       6.044                          
          IMACIMS                        6.116, 6.053                   
          IMACMONI                       6.096                          
          IMACPDB                        6.129, 6.105                   
          IMACRMDS                       6.042                          
          IMACSHFT                       6.206                          
        IMACs new in prerelease       Read Change Number                
        that were changed.                                              
          IMACDB2T                       6.103, 6.079                   
          IMACEXD                        6.084, 6.037                   
          IMAC102                        6.201                          
        IMAC that might need          Read Change Number                
       to be changes by you                                             
           IMACKEEP                       6.148                         
        New IMAC which should         Read Change Number                
         be noted for impact.                                           
          IMAC30IO                       6.129                          
  You could see more observations in TYPE74 with MXG 6.6 than with 5.5. 
  Observations are now output only for non-zero values of the SIOCOUNT, 
  PCTDVUSE, or MOUNT variables; prior versions did not test MOUNT. The  
  addition of MOUNT captures tape devices which had mount pending but   
  no other activity during an RMF interval.                             
  VM/XA processing now requires a new FILEDEF/DDNAME of INSTREAM, a     
  3-track temporary file, into which MXG creates SAS code which is      
  then %INCLUDEd to create the look-up table of device attributes for   
  VXIODDEV and related data sets from VXMTRDEV. The INSTREAM DD is      
  referenced only during building the VXIODDEV data set(s).             
 4. Documentation.                                                      
  It was hoped that the Chapter FORTY style documentation of each of the
  new data sets and their variables would be available coincident with  
  MXG 6.6.  However, the choice was made to ship the software now and to
  send the documentation as a (very large!) Newsletter later this year. 
  Member DOCVER06 alphabetically lists all NEW data sets and all NEW    
  variables which did not exist in MXG Version 5.5.  Member DOCVER is a 
  complete list of ALL variables in ALL data sets built by Version 6.   
  Both members give the complete label, which is usually adequate for   
  initial use of the data.  Since in most cases the field names of the  
  data source are used as the MXG variable names, the vendor's manuals  
  should not be overlooked for additional descriptions.  Best of all,   
  build the new data sets with the TYPE.... member for a day's data, and
  then PROC PRINT the first 50 observations, examining what values your 
  installation's data creates. PROC MEANS and PROC FREQ can also be very
  useful tools in understanding the range of values and the frequency of
  occurrence of the new data.                                           
  Finally, use member CHANGES to find all of the member names that are  
  associated with a change of interest, and then examine each listed    
  member for comments at the beginning of the member.  Most of the new  
  data sets are initially described in their VMAC.... member, and the   
  associated IMAC.... may also contain specific comments on how to set  
  up MXG to process a particular data.  When none of this helps, call!  
II. ADMINISTRATIVE ANNOUNCEMENTS                                        
1. "CPE Reporting System" tape to be sent to you by SAS Institute.      
  The CPE Reporting System (originally called the CPE Starter Set)  is  
  a SAS/AF  application which has been available free upon request from 
  SAS Institute.  It was developed (primarily by  Allan  Russell, SAS   
  Technical Manager of SAS Institute's European subsidiary) in          
  SAS/AF  gives  end  users  (for  example,  your  manager) the ability 
  to analyze, select, plot, and to apply the power of the SAS System  to
  SAS data  sets  through  a  series  of  screens  and  menus which     
  require no knowledge of the SAS language.                             
  The CPE Reporting System is both an example of how to use SAS/AF  and 
  a fine  set  of  hourly, daily, and weekly reports of interest to     
  managers and CPE technicians alike.  It contains  a  tutorial  on  its
  use,  and generates  a wide range of reports from the MXG data sets   
  built from MVS (PDB.IPLS,  PDB.JOBS,  PDB.STEPS,  and  PDB.RMFINTRV). 
  It  is   easily extended to provide SAS/AF services for the analysis  
  of any data.                                                          
  We  are  providing  SAS Institute with our mailing list of supported  
  MXG sites, and shortly after you receive MXG Version 6.6 from us in   
  Dallas, you will receive your free copy of the CPE Reporting System   
  directly from the SAS Institute (or from your local SAS office).      
2. MXG Software default media.                                          
  We announced our intention to change tape media default from 3420s to 
  3480s in Newsletter TWELVE, and included a return postcard if your    
  site could not accept 3480 cartridges, since the vast majority of USA 
  sites do have 3480s. However, at the request of our overseas offices, 
  we will continue to ship 3420 mini-reels to overseas sites, and will  
  send 3480 cartridges overseas only to sites who so request. The MXG   
  default media for the USA and Canada will remain 3480s.               
3. MXG Newsletters are now "online".                                    
  The new member NEWSLTRS now contains the text of this and all prior   
  Newsletters.  Not only will this (hopefully) eliminate your requests  
  for multiple printed copies of our Newsletters, but also it permits   
  you to BROWSE and search for technical information by computer!  The  
  change log portion of each newsletter has always been contained in the
  members CHANGEnn for prior MXG version nn, and in member CHANGES for  
  the current MXG version.                                              
4. 1989 Planing.                                                        
   a. The 3-day CPE class taught by Dr. Merrill will be offered in the  
      USA in February (preceding SHARE in Los Angeles), in October at   
      SAS in Cary, and in December (preceding CMG in Reno). SAS Cary    
      makes the arrangements for these courses.  The course will also   
      taught in Paris in July (the 200th anniversary of Bastile Day!)   
      and also in England in late July.  An Australian class is also    
      being planned adjacent to CMGA in September in Melbourne.         
  b. Things that did not get completed in time for Version 6:           
    - VM/SP Release 6 Shared File System Account Record.                
    - IMS Fastpath log record analysis.                                 
    - Tape mount monitor for MVS/XA.                                    
    - Chapter 40-style documentation for everything new.                
  c. MXGMENU - a statement of direction.                                
  MXGMENU will be the interactive facility for the installation and     
  tailoring of MXG, for report selection and generation, and for the    
  management of the MXG environment.  MXGMENU will be delivered after   
  SAS Institute releases a full function mainframe Version 6 of the SAS 
  System, probably in 1990.  MXGMENU will take as its starting the      
  previously described "CPE Reporting System".   MXGMENU will execute   
  PROC DISPLAY and will not require the site to have SAS/AF, but may    
  well motivate its acquisition.  MXGMENU will exclusively use Version  
  6 SAS/AF features and Screen Contorl Language, and will execute on    
  the mainframe or the microframe.                                      
  For reporting, MXGMENU will publish and use a standard set of macro   
  names as tokens for selection and control, such as for Dates, Times,  
  Shifts, Jobnames, Transaction Names, User names, etc.  Unlike the     
  present "CPE Reporting System", which carries most of its reporting   
  code inside the SAS/AF catalog, all of the report code used by the    
  MXGMENU will be in the MXG Source library.  This will allow reports   
  to be produced directly in batch, TSO, or CMS, or from the MXGMENU.   
  (Standardization of MXG report tokens will also make it easier for    
  users to share and contribute reports!)                               
  For installation tailoring, MXGMENU will interactively interrogate    
  the installer and then create appropriate definitions in IMAC....     
  members in the user's tailoring USERID.SOURCLIB library to override   
  MXG defaults.  For example, you will be able to specify "MVS/ESA"     
  and thereby create only MVS/ESA (or only MVS/370, etc.) relevant      
  variables in MXG data sets. MXGMENU will also set up the sources      
  and summary levels of the data to be kept in the MXG Trend Database.  
  MXGMENU will be a free, intrinsic component of MXG Software.          
III. TECHNICAL NOTES                                                    
1. HOT PTFs: MVS                                                        
   OY13794   NPM type 28 data invalid.                                  
   OY01945   SMF Buffer errors causing IEE979W message and data loss.   
   OY12066   SMF Buffer errors corrected. On 8805.                      
   OZ97236   ACTJTIME only 3-byte storage for step CPU, can wrap if task
              uses lots of CPU (this is an old problem, still unfixed). 
   OY06621   Type 41 JOB, PTF UY22185, UY20659, may need SYSGEN.        
   OY09186   VIO paging into ESTORE (RMF 3.5 and later).                
   OY15663   TYPE 64 VSAM EXCP counts are now accurate for shared VSAM. 
   PL20996   CICS Clock gets ahead of MVS clock!                        
2. HOT PTFs: VM                                                         
   VM27244   TAPPDS fails with virtual storage error message DMSTPD105S.
   VM35321   VM/XA Monitor Scheduler record needs CPU address in record.
3. Technical Notes: IBM                                                 
  The IBM Internal document titled "RMF Accuracy and Capacity Assessment
  Under VM/XA" is currently available to your IBM SE thru PROFS under   
  the VM/XA SP Forum, but is supposed to become a real publication      
  soon.  It is the best discussion of what happens to RMF data when you 
  execute MVS under VM I have ever read. It was written by Robert Youngs
  of the IBM UK Chiswick Center.                                        
  The MVS/ESA SMF Manual is a new publication, GC28-1819-0. The EXCP    
  counting is clarified somewhat in Chapter 8, but it still fails to    
  discuss connect time measurements. Also, Chapter 9 expands CPU timing 
  discussion to include Vector Facility timing and adds more reasons why
  CPU-time measures may vary from run-to-run.                           
4. Technical Notes: MVS                                                 
  a. VSAM EXCP counting.                                                
  In October 1988, APAR OY15663 became available, which corrected the   
  VSAM EXCP counting problem in TYPE 64 SMF records. The following is   
  the problem corrected by that APAR, and thus will no longer be true.  
  The EXCPS variable in TYPE64 contains the change in EXCPs since the   
  VSAM file was opened by this job, but (some, none, all) of the change 
  may not be caused by this job. If the same VSAM file is concurrently  
  opened by four jobs that issue 9000 EXCPs each, their four type 64    
  records contain 9000, 18000, 27000 and 36000 EXCPS respectively, even 
  though 9000 EXCPs are properly recorded in the type 30 step data. It  
  does not even appear possible to write a de-accumulation algorithm for
  type 64 records that will always be correct, and the counting problem 
  for multiple-opened VSAM files applies to the other variables (INSERTS
  DELETES, etc.) which are calculated from changes in catalog counts.   
  Again, the preceding problem is eliminated with APAR OY15663.         
  b. DB2 Account data.                                                  
  DB2 Account data sometimes contains a 0 value for beginning CPU time  
  and 23:59 hh:mm for the EJST ending CPU time when a plan abends, which
  results in a large "measured" CPU time. Two sites have noted this flaw
  but it has not been repeatable enough to get IBM attention.           
  c. NETVIEW 2.1.                                                       
  NETVIEW 2.1 created type 39 (NLDM RTM data) records will have missing 
  data unless LOG=YES, SAW=YES, SETSTATS=YES (even though documentation 
  says NO) are specified in AAUPRMLP member of NETVIEW library.         
  d. ACTFRMTM in TYPE72.                                                
  The new TYPE72 variable ACTFRMTM, Active Frame Time is the number of  
  page-seconds of pages of Central Store (CS) and Expanded Store (ES)   
  that were owned by resident tasks in each performance group period.   
  The new TYPE72 variable PGPAGEIN, Pageins for this perfgrp period, can
  be directly compared with Storage Isolation parameter PWSS which      
  controls the sum of CS and ES frames.  The number of ES pages owned by
  a performance group can be estimated by comparing ACTFRMTM (CS+ES)    
  with PAGESECS (CS only, calculated from MSOUNITS). However at the task
  level in type 30, we can only get the count of CS pages from MSOUNITS.
  In summary, type 72 contains CS and ES pages, type 30 has CS only.    
  e. IO Counting in TYPE70.                                             
  I had previously noted that IO's counted in TYPE70 are higher than the
  count of IO's in TYPE78IO, but did not know why. LY17-5550 explains   
  the difference (typically 12-14% higher in TYPE70) is because the 70  
  counts SSCH's and Resumes (like 78), but the 70 includes PCI counts,  
  Device End following Channel End, and Unsolicited Interrupts.         
  f. CICS 1.7 EXCLUDE option.                                           
  One CICS 1.7 CICS Monitor Facility (type 110 data) user reported that 
  he tried to EXCLUDE ALL followed by INCLUDE specific transaction data 
  fields, but the unexpected result was that not only were CICSTRAN data
  fields excluded, but also CICSYSTM global fields were also excluded   
  (except for fields 1-9 which appear to be always kept!). MXG supports 
  the use of EXCLUDE, but requires you to EDIT VMAC110 into your USERID.
  SOURCLIB. (Find "EXCLUDE" in VMAC110 and follow the instructions.) IBM
  has suggested most of the CPU overhead of CMF is in the capture of CPU
  timings and Paging activity, which are usually important fields.  If  
  your aim is to save space, make sure you calculate how much you can   
  save before you go to all this effort. A CICS 1.7 transaction is 336  
  bytes (CICS 1.6.1 was 186 bytes).With 1,500,000 transactions per week 
  CICS 1.7 would write 504MB of data per week, which would only require 
  a total IO transfer time (at 3MB per sec) of 168 seconds per week!    
  Remember that you can put the CICSTRAN data directly to tape with MXG 
  and keep all CICS detail data. When you read CICSTRAN to summarize and
  measure response time, remember to use (KEEP= ... ) on both the DATA  
  and the SET statements to minimize SAS CPU costs and bytes moved.     
  g. SMF dump sample program.                                           
  The IBM sample program SMFDUMP, which automatically detects the active
  SMF data set, dumps, switches, etc., without operator action, can be  
  found (currently!) in IPO1.SAMPLIB or with CBIPO in MVS Process Aids, 
  (T00616.SAMPLIB). See also member IEFU29 which will automatically     
  submit SMFDUMP when a MAN data set fills.                             
  h. MXG execution and storage costs.                                   
  Analysis of CPU time to process SMF data into a SAS dataset suggests  
  that MXG requires 100 seconds to read each 400 MB of input SMF data,  
  and requires an additional 100 seconds for each 40 MB of output SAS   
  data libraries.  Times are TCB+SRB on a 3090-400.  One site with two  
  3081's and heavy workload reported that its total DASD requirements   
  for MXG online data sets (eight dailies, one weekly, 5 years RMFINTRV,
  all MXG source libraries, etc.) was 350 CYL (250 MB) of 3380 DASD.    
  Triple density 3380AKs purchase for $25,000 per 1873 MB means their   
  250 MB was purchased for only $3216. They keep 3-years PDB (156       
  weekly, 36 monthly) on 192 3480 tape cartridges ($6.50 each) for      
  $1248. Total MXG storage cost is a one time $4464!                    
  i. 922 Abend.                                                         
  An MVS 922 ABEND can cause TYPE30 CPU times to be irrationally high,  
  and the record may be missing the IO, PROC, EXCP and STOR segments.   
  j. Large blocksize is good.                                           
  Yet another reminder why large blocksize for sequential data sets is  
  good. At 32760 blocksize a 3480 tape holds 215 MB, while at 4096 the  
  same tape can only hold 124 MB.                                       
  k. Sorting.                                                           
  How much do we sort? One site with a 3090-300 and 3090-200 supporting 
  TSO (200 concurrent of 600 total user ids) issued 3550 sorts that took
  19 hours of CPU time. SMF recorded 47 CPU hours in type 30s, TYPE70   
  recorded 55 CPU hours available. SORTs were 40% of the TSO load.      
  l. IMS log processing.                                                
  IMS log records can be separated (database recovery or performance) by
  the DFSUARCO program control card COPY statement to write selected IMS
  log records (see TYPEIMS) to a user defined DD.  To print the DSECTS  
  of IMS log records, assemble   ILOGREC TYPE=DSECT,RECID=ALL           
  Re-constructing an IMS transaction from the many different IMS log    
  records is complicated because there is no unique field which ties all
  records together.  The MXG algorithms were re-designed (largely by    
  Pete Shepherd) and then compared with Boole and Babbage's IMF data    
  records. Resources (CPU, DL/I calls) are always correct, and response 
  times are extremely close.  If multiple transactions are processed by 
  a program schedule (eg., Wait-For-Input), there is only a single 07   
  log record written, with total CPU and DL/I calls. MXG divides these  
  resources across all of the transactions processed. As a result, you  
  might find fractional DL/I counts recorded for a transaction! The new 
  algorithms have been validated with IMS 2.1 and IMS 2.2 data and seem 
  robust, (as long as all of the records for a transaction are on the   
  IMSLOG tape presented to MXG). For IMS 1.3 data, however, it has been 
  reported that sometimes variables MLOGONID, ODEST, MODNAME, MTYPE,    
  LTERM, DEST, and/or LOGONID may be blank.  If IMS is really the bread 
  and butter of your installation, you probably should not depend on us 
  to always be able to recognize transactions, and should lobby IBM to  
  enhance the IMS log records (like CICS's Unit-Of-Work ID field), or   
  should consider an IMS monitor that creates individual transaction    
  records, like IMF.                                                    
  m. NJE impact on job time stamps for Batch Service measurement.       
  NJE sites tracking job service times note that the READTIME variable  
  is the time (at the originating node) when the JOB card was first     
  read, but the JRDRTIME (in each type 26 purge record) is the time (at 
  each node) when the job completed read-in at that node. The MXG       
  PDB.NJEPURGE data set may be useful in tracking job times. In the     
  PDB.JOBS data set, since MXG keeps only the purge record from the     
  actual execution node, the variable JRDRTIME will be the actual time  
  when the job arrived at its execution node, and thus the delta between
  JRDRTIME to JSTRTIME will be the initiation wait time at the execution
  node. (However, that wait will also include time the job spent in     
  hold, if any).                                                        
  n. Clarification of contents of MXG variable CPUTM.                   
  The variable CPUTM (in type 30 data sets, as well as in PDB.STEPS &   
  PDB.JOBS) is the sum of all four CPU measures captured at the step    
  level: CPUTCBTM, CPITCBTM, CPUSRBTM, and CPISRBTM. The equation has   
  never changed, but Chapter 40 in the MXG Guide incorrectly documents  
  CPUTM as the sum of only CPUTCBTM and CPUSRBTM.  The MXG Supplement   
  correctly described CPUTM on page 366.  Note that these CPI...TM      
  values (CPU time in the "initiator" or "privileged state") are not    
  captured in the type 72 RMF record (they are in the uncaptured CPU    
  time, see MXG Guide page 82 Fig 10.1 and MXG Supplement page 34).  The
  magnitude of these CPI "initiator" times is not typically very large  
  (eg. 13 hours out of a total type 30 CPUTM of 683 hours, 2%), but the 
  CPI time is directly attributable to the step and thus is included in 
  the CPUTM variable which should be used for both the chargeback and   
  the capacity measurement of processor utilization.                    
  o. An important date: When DATETIME clocks wrap:                      
  A date for your grandchildren. At 23:53:48 on Sep 17, 2042, the IBM   
  8-byte hardware clock will fill and reset to Jan 1, 1900.             
  With regard to the IBM clock date, it must be corrected by year 2011, 
  as the retention period for a cataloged tape volume can be as long as 
  30 years.                                                             
  And it turns out the Open Systems wrap earlier:                       
  The year 2038 problem ("Unix Millennium bug"), is UNIX result of      
  storing its system time as a 32-bit signed integer with the number of 
  seconds after the Unix/POSIX epoch time of midnight, January 1, 1970. 
  This value will roll over on February 19, 2038.                       
5. Technical Notes: VM                                                  
  a. VM/XA Monitor description.                                         
  VM/XA Monitor creates many new data records in brand new format. The  
  CP MONITOR Command determines which domains, records, and which data  
  will be created in a DCSS. The new MONWRITE CMS command extracts the  
  data from the DCSS and writes the data to a CMS file which is read    
  directly by MXG to create the 75 VX...... detail datasets and 1300+   
  variables. The sample classes are sorted and build dataset VMXAINTV,  
  the primary interval analysis data set, and VXBYUSR, the machine by   
  machine interval analysis data set. The IBM documentation for the     
  records are in the Appendix of SC23-0370-1. The IBM field names for   
  monitor data are of the form of dddrrr_ffffffff; ddd is the name of   
  the Domain and rrr is the name of the record type in that domain and  
  ffffffff is the field name. MXG creates data sets named VXdddrrr and  
  whose variables are named ffffffff, so that (finally) there will be no
  transformation between IBM and MXG nomenclature!  This is a major new 
  addition to MXG which has been validated by a number of users.        
  Additional IBM documentation will be found in:                        
      LY27-8058 - Features Summary, pp 478-482                          
      SC23-0353 - Administration, pp 137-145.                           
      SC23-0370 - CP Programming Services, pp 145-149, pp 237-421.      
      SC23-0354 - CMS Command Reference, pp 371-373.                    
      SC23-0358 - CP  Command Reference, pp 271-288.                    
      LY27-8054 - CP Diagnostic Reference.                              
    The current documentation of this major MXG enhancement is in the   
    comments in member VMACVMXA, CHANGES, and DOCVMXAF.                 
  b. VM/XA Monitor known problems.                                      
  The following information was presented at SHARE in August and at the 
  Confederate CMG in October.  The following problems have been observed
  in VM/XA Monitor data:                                                
    1. Interval end time and interval duration are inconsistent.        
       a. 30 second interval request generates 30.1 second data.        
       b. MTREND data does not accurately represent collection interval.
          Writing user data extended 6 second interval to 9 seconds in  
          MTREND, but actual delta varied by record from 6 to 9 seconds.
       c. Must use individual record-to-record DELTATM for rates of data
          in that record, but then a logic interval has many slightly   
          different durations.                                          
       d. ENDTIME should represent end of collection of interval but    
          each MRHDRTOD is slightly different.                          
       e. MXG algorithm: Set ENDTIME as timestamp of first 0.1 (SYTSYP) 
          record, but use DELTATM of 0.2 (SYTPRP) as common DURATM of   
          interval, since SYTPRP contains CPU busy data. However, rates 
          from other records are built using individual record          
    2. CPU measurement is inconsistent or incorrectly documented        
       a. The sum of "user" PFXUTIME and "system" PFXTMSYS from SYTPRP  
          (0.2) is greater than "TTIME" from USEACT (4.3) data.         
          PFXTMSYS is not captured at the user level:                   
                             DWR1     DWR2     IBM1    HNET1    HNET2   
       SYSTEM:  Total CPU:  873.94 12552.51  2700.70  874.00   125.18   
                PFXTMSYS:    92.38  2832.56   369.43   92.00    73.62   
                PFXUTIME:   781.56  9719.95  2331.27  782.00    51.56   
         USER:  VMDTTIME:   773.94  9771.93  2341.12  774.00    51.56   
                VMDVTIME:   433.56  7483.90  1667.81  434.00    31.93   
                their diff: 340.38  2288.03   673.31  340.00    20.63   
                 by user:    88.5%    77.4%    67.4%   88.5%    41.2%   
       b. In SYTPRP (0.2) the sum of PFXTMSYS+PFXTOTWT+PFXUTIME should  
          match DELTATM between records, but is as much as 24 seconds   
          short in a 900 second interval!  LOSTTM variable in VMXAINTV  
          calculates the unaccounted time.                              
       c. A small amount of user CPU time is always lost in the USER    
          data. CPU time used prior to the first interval record is lost
          and CPU time used between the final interval record and the   
          user's logoff is not recorded.                                
    3. Response time validation is erratic.                             
       a. Controlled single-user experiment with one transaction in each
          30 second interval with two long transactions (Copy 1MB file  
          from 2K "Q" to 1K "A" on same volume) clocked 51.99 and 52.20 
          at terminal and were measured as 51.96 and 52.12 by VM,       
          showing very good agreement for these two non-trivial         
       b. However, the response time is recorded not in when the        
          transaction ended, but when the next transaction start is     
          recognized (two intervals later in this case!)                
       c. Logon and IPL CMS seemed to take 7.28 seconds but VM recorded 
          33.91 seconds.                                                
       d. Unexpected trivial transactions were counted because SMART was
          also running. Assuming SMART response was near zero the       
          product of number*duration matches the measured trivial       
          response quite well.                                          
       e. The biggest problem with response measurements in VM/XA is the
          actual definition of trivial itself. The Scheduler desires    
          that 85% of all transactions count as trivial. To make this   
          happen, the SRME1ETS elapsed time slice is adjusted from .5 to
          5 seconds to ensure that (if possible) 85% are classified as  
          trivial! As a result, the CALMPTRV and CALUPTRV "Average      
          Trivial" response value is meaningless unless you also look at
          the value of SRME1ETS. (MP and UP counts are intended to      
          separate Guests (MP) from CMS (UP) responses). Thus the value 
          of CALMPTRV and CALUPTRV are best described as "the average   
          response of those 85% of transactions that completed in the   
          elapsed time given by SRME1ETS".  In fact, the value of       
          SRME1ETS may itself be a better measure of interactive        
          response, as long as it is less than its upper bound of 5     
          seconds! Detail comparison:                                   
                                        --Monitor Reported--            
          Action            Stopwatch   Non-trivial   Trivial           
                                sec      avg   nr     avg  nr           
          FILELIST              .86                  .44   2            
          XEDIT                 .74                  .71   2            
          SAVE                  .74                  .49   2            
          SCROLL                .50                  .48   2            
          END                   .72                  .39   2            
          UNKNOWN CMD           .72      1.12  1     .48   2            
          DISCONNECT            .66                  .35   4            
          LOGON                 .79                   0    1            
          IPL                  5.54      1.14  1     .72   4            
          FINISH CMS INIT      1.74     33.91  1     .49   1            
          EXEC DISK ACCESS     3.37      1.13  1     .51   1            
          FILELIST             1.26      2.51  1     .50   1            
          SORT                  .54      1.15  1     .53   1            
          COPY 1031 BLK                              .48   2            
          COPY completed      51.99                  .49   1            
          no action                                  .55   1            
          ERASE FILE              .50   51.96  1     .47   1            
          COPY same 26391 rec                        .46   2            
          COPY completed        52.20                .48   1            
          no action                                  .63   1            
          END                     .88   52.12  1     .51   1            
          QUERY DISK              .80                .50   2            
    4. Scheduler records cannot be used for CPU measurement of Guests   
       which allocate more than one CPU (i.e., MVS). CPU time is        
       accumulated by CPU Address, but CPUAD is not in the SCHEDULE     
       domain records.                                                  
    5. Some USER domain USEACT records show small VTIME with no TTIME.  
    6. Many fields are only two bytes, which wraps at 65536. An hourly  
       interval would lose data on any field with a rate greater than 36
       per second, with no indication that data values were lost.  Use  
       15 minutes or less for interval.                                 
    7. One accumulated field is not monotonic: :VMDVCSCT, the Virtual   
       Console Requests. This might result from a user who disconnects  
       (count reset to zero at disconnect?)                             
    8. It was thought that (SYSUSRS-SRMCDORM) could be used as a count  
       of "Active" users but it failed (and the difference is now named 
       NONDORM) because SYSUSRS counts virtual machines while SRMCDORM  
       counts VMDBLKS (one for each CPU defined by each machine.)  The  
       variable ACTIVE is now calculated from user records (non-zero    
       VTIME during the interval) but itself suffers because the        
       interval size affects the definition, and because it counts      
       VMDBLKS, not machines.                                           
    9. IODDEV HFRDEVCNT is wrong. It accumulates an accumulation!       
   10. SEEK data is wrong. The record indicates a seek did occur, but   
       the serialization of data and the data in the record itself is   
       not always valid.                                                
   11. HFUSERC in VXPRCPRP and VMXAINTV (VMDBKS in PLDV is not valid -  
       it appears to be accumulation of accumulation.  data is new to   
       everyone (especially IBM!).                                      
   12. Additional problems have been reported by IBM by MXG and other   
       vendors and are under investigation. Unfortunately, the list of  
       known problems has not been made available, and is not in IBM's  
       Support Center as of this writing. I can only give you my list!  
6. Technical Notes: SAS                                                 
   Z516.2120 Allows 3380-K's to contain SAS data sets with over 32000   
             tracks. (This was never possible before 3380-K's so it     
             is required only if you want to create a very large SAS    
             data set.) Note that this zap is a very big one and is     
             to be on the SAS 5.18 maintenance release and thus it is   
             recommended that you wait until then.                      
   Z516.4669 Makes PROC CONTENTS aware of 3380-K's. See above zap.      
   Z518.5694 Makes PROC GPLOT not set CC 12. (See Change 6.106).        
   Z518.5779 Makes GROUP statement in PROC GREPLAY work correcty.       
   The mainframe SAS/PC Device Driver (GRLINK) under 5.18 will not work 
   when you are trying to create SAS/GRAPHs with a batch job.  This     
   device driver expects the PC to be online and will not generate the  
   graphs when the PC is offline (as it is to a batch job).  To         
   circumvent this problem, specify                                     
              GSFMODE=NONE HPOS=80 VPOS=43;                             
    or use the %VMXGGOPT invocation of                                  
   This will allow you to build a graphics catalog in a batch job and   
   then replay the graphs with SAS/PC AND have graphs that look right!  
   To execute MXG code under SAS/PC, you must first download the MXG    
   member FORMATS and build the formats on the PC. You must create a    
   directory and establish LIBREFS of SASLIB and LIBRARY pointing to    
   that directory.  Member FORMATS will execute under SAS/PC and the    
   resulting 150+ formats requires only 250K.  Members ANALDB2R,        
   ANALDMON, and ANALNPMR have been tested on a PC. ANALDB2R took over  
   35 elapsed minutes on an AT, compared with less than one minute on a 
   3090 mainframe.                                                      
   WAS AT OBSERVATION 16744450 has occurred at two sites during         
   execution of the JCLTEST program.  This error results from a design  
   limit in SAS. The DIRMACR dataset is where old-style macro           
   definitions are stored, and it (unlike real SAS datasets) has a fixed
   limit in its size.  Both sites had (correctly!) made use of MXG      
   member IMACKEEP to keep only desired variables. But because JCLTEST  
   repetitively re-includes IMACKEEP, and because SAS does not reuse the
   space in DIRMACR (even though the same macro names are being         
   re-defined with each include), DIRMACR filled!  Removing IMACKEEP    
   temporarily from USERID.SOURCLIB allowed JCLTEST to complete         
   successfully. THERE IS NO REAL PROBLEM HERE, since your normal MXG   
   jobs do not re-include IMACKEEP hundreds of times!