****************NEWSLETTER THIRTY***************************************
             MXG NEWSLETTER NUMBER THIRTY September 10, 1996            
Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE
                         TABLE OF CONTENTS                          Page
I.   MXG Software Version 14.07 is now available upon request.         3
II.  MXG Technical Notes                                               6
 1.  Data Mining the Original Data Warehouse - 25 years + 1 million    6
 2.  MXGTMNT, the Tape Mount and Tape Allocation Monitor Program      20
 3.  "RMFINTRV" data for both detail and hourly intervals             20
 4.  Some allegations that the KEEPALL=NO option in %VMXGSUM "costs"  20
 5.  BUILDPDB processes SMF data at 41MB per 3090-300S CPU-minute.    21
III. MVS Technical Notes.                                             21
 1.  APAR OW16564 corrects zero value in PCHANBY variable in TYPE73   21
 2.  APAR OW16847 and OW19029 corrects TYPE30 variables EXCPTOTL      22
 3.  APAR OW17491 corrects TYPE21 variable TAPCUSER Tape Unit Serial  22
 4.  APAR OW17121 reports incorrect values for TYPE6 variables JOB    22
 5.  APAR OW17469 reports excessive count of type 80 SMF records      22
 6.  APAR OW18822 corrects the invalid JESNR in type 26 SMF records   22
 7.  ISPF Find and Change commands use the equal-sign as a wild card  22
 8.  Hitachi 9021 Skyline Processors trash TYPE73 (Channel Path Busy) 22
 9.  APAR OW19482 corrects variable TTRN in dataset TYPE1415          22
10.  APAR OW03645 reports extremely high disconnect time in type 74   22
11.  CA's CA-SPOOL Release 1.8 creates massive numbers of records     22
12.  APAR OW01699 corrects TYPE72MN (type 72 subtype 2 RMF Mon II)    23
13.  APAR OW20318 corrects TYPE42TO (type 42 subtype 1) DURATM        23
15.  CPUTM in interval type 30s does not match step type 30s          23
16.  APAR OW18543 corrects blank values for Service Class & Report    24
17.  APAR OW20904/OW22093 (negative or zero disconnect time)          24
18.  SMF dump job will run faster with less resources with BUFND=46   24
19.  Boole & Babbage's Cache RMF Reporter (user SMF record) wrong.    25
20.  APAR OW20844 increases the maximum number of job numbers         25
21.  Experiments with BUFNO for Sequential Access (BSAM,QSAM)         25
22.  APAR PN87013 (open) reports TCP/IP TELNET LOGN SMF error.        26
23.  APAR OW20823 for RACF type 80 record corrects missing data       26
24.  CA's CA-1 (TMS) product APAR G081058 for CA1 5.1.                26
25.  APAR OW20956 reports that TYPE1415 variable TRKSALOC wrong.      26
26.  APAR OW21083 fixes large values in CPUUNITS & SERVICE variables. 26
27.  Sites with MVS/ESA 5.2.2 have noticed negative PCTPNCHA values.  26
28.  To create SMFINTRV (TYPE30_V) globally synchronized.             26
29.  APAR OW19074 corrects three distinct RMF ABENDS                  26
30.  APAR OW22119 for DCOLLECT record type 'VL' corrects system       26
IV.  DB2 Technical Notes.                                             27
 1.  DB2 records its media manager VSAM I/O counts in EXCP buckets.   27
V.   IMS Technical Notes.                                             27
 1.  One site using Candle's ITRF reports their experiences:          27
 2.  IMS FASTPATH DEBD I/O counts via the VSAM Media Manager counted. 27
VI.  SAS Technical Notes.                                             27
 1.  SAS USER ABEND 0315 (physical I/O error to a SAS data library)   27
 2.  Further comments about resources in PROC SQL versus DATA step.   27
 3.  USER ABEND 0318 may occur if your site upgrades STOPX37          27
 4.  OUT OF MEMORY conditions and REGION=0M.                          28
 5.  SAS can enter either a CPU or wait loop with broken VBS.         28
 6.  Permanent ARRAYs with large numbers of elements (over 4096?)     28
 7.  SAS 6.09E Maintenance TS450 has no reported problems with MXG.   29
VII. CICS Technical Notes.                                            29
 1.  CICS data volume reduction with EXCLUDE, CICS Blocksize,         29
 2.  Support for Landmark's TMON for CICS/ESA 1.3.                    30
 3.  APAR PN79698 closes a problem with TASCPUTM.                     31
 4.  CICS/ESA 4.1, IBM creates a CICSTRAN obs for undefined trans     31
VIII. Incompatibilities and Installation of MXG 14.07.                31
IX.  Online Documentation of MXG Software.                            33
X.   Changes Log                                                      34
     Alphabetical list of important changes                           35
     Changes 14.209 thru 14.001                                    37-77
So what's the big picture?  Who needs to request and install MXG 14.07? 
1. Anyone installing these products, which are INCOMPATIBLE (i.e., the  
   new records cause an error), needs at least the MXG version listed:  
      CICS/ESA 5.1.0           14.07   ASTEX 2.1                14.04   
      TMON/DB2 Version 3       14.07   IMS APAR PN76410         14.04   
      Omegmaon/VTAM V200       14.06   OS/400 Release 3.6       14.04   
      MODEL204 Release 3.2.1   14.06   Thruput Manager #V041238 14.03   
      SoftAudit Version 5.1    14.06   CRR in Type 74 Subtype 4 14.06   
2. Leading edge sites installing OS/390 Release 2 (or MVS/ESA 5.2.2):   
     MXG 13.13 and later tolerate OS/390 Release 2, but to capture      
     the several new variables and new subtypes of type 74 and 89,      
     you must install MXG 14.05 or later.                               
3. Anyone with DB2 4.1:  Although MXG 13.13 handles the important DB2   
   accounting and most statistics records correctly, some of the new    
   statistics information on global buffers and remotes, and protection 
   for IBM skipping sequence numbers were not correct until MXG 14.07.  
4. Anyone else.  There are lots of enhancements (like TYPE80A for RACF, 
   which decodes many more RACF commands for simplified reporting) in   
   the 209+ changes since January's 13.13.  I plan to ship the next     
   Annual MXG Version (to be numbered 14.14) in early 1997 to all sites.
So what's in near-future development?                                   
  Support for TRENDSMP data (September, 1996)                           
  Windows NT PERFMON collector and MXG support (4th Quarter, 1996)      
I. MXG Software Version Status.                                         
 1. MXG Software Version 14.07, dated Sep 10, 1996, is now available,   
    free, upon request.  No tape was shipped with NEWSLETTER THIRTY.    
   Major enhancements added in MXG 14.06 dated Aug 20, 1996:            
   Support for CICS/ESA 5.1.0 (INCOMPATIBLE).                           
   Support for TMON/DB2 Version 3 (INCOMPATIBLE).                       
   Support for Boole and Babbage's PRO/SMS SMF record.                  
   Major enhancements added in MXG 14.06 dated Aug 20, 1996:            
   Support for Omegamon/VTAM V200 (INCOMPATIBLE).                       
   Support for MODEL204 Release 3.2.1 (INCOMPATIBLE).                   
   Support for SoftAudit Version 5.1 (INCOMPATIBLE).                    
   Support for APAR OW15406 for RMF adds support for Year 2000.         
   Support for Tandem Controller and Line records added.                
   Sample code to read Network General's Sniffer Network Monitor data.  
   VM Print sent to JES2 is now merged in PDB.JOBS.                     
   BUILDPD3 now sums JES3 type 25 MDS Tape Mounts/Fetches.              
   More RACF Reports for Command Events decoded by TYPE80A.             
   DB2 4.1 DB2STATS interval lost due to QWHSISEQ skipped values.       
   CICINTRV restored to pre-14.04 version, fixed for CICS 4.1.          
   Redesigned TRNDTALO to "SPIN" active allocations.                    
   SMF Simulator (ANALSMF) now tests a CISIZE of 18432 for 3390s.       
   Major enhancements added in MXG 14.05 dated Jul 15, 1996:            
   Support for OS/390 Version 1 Release 2 (COMPATIBLE).                 
     MXG 13.13 and later tolerate OS/390 Release 2, but to capture      
     the several new variables and new subtypes of type 74 and 89,      
     you must install MXG 14.05 or later.                               
   Support for SMF type 89 subtype 2 (Measured Usage Product Summary).  
   Support for DB2 trace data written to GTF instead of SMF.            
   Support for HP MeasureWare for HP-UX platform                        
   Support for RDS's EOS Enterprise Output Solution                     
   Support for Landmark TMON/MVS spanned records.                       
   Support for RMF type 74 subtype 5 Cache RMF Reporter.                
   Support for Anacomp, Inc's XSTAR product's SMF record                
   Support for DFSORT Release 13 APAR PN71337.                          
   New JCLADHOC example of MXG ad hoc job to select specific data.      
   Revised MXGSAS JCL procedure adds TAILORNG= symbolic parameter.      
   New DB2 trace datasets to hold all SQL text are created.             
   MXG JCL examples now specify REGION=0M                               
   VMXGTAPE utility macro to determine if lib/dsn is on tape.           
   UDEBLOCK utility to create valid RECFM=U on MVS from PC data.        
   ASMIMSLG/ASMIMSL5 SLOTS table was moved above the 16MB line.         
   Major enhancements added in MXG 14.04 dated Jun 15, 1996:            
   Support for ASTEX 2.1 (INCOMPATIBLE)                                 
   Support for NDM 1.4 (compatible) new variables                       
   Support for IMS APAR PN76410 (INCOMPATIBLE) for ASMIMSLG processing. 
   Support for APAR PN78083 to SMF type 42 (ADSM) required no change.   
   Enhanced CICINTRV was installed as default (but removed in 14.06).   
   Major enhancements added in MXG 14.03 dated May 27, 1996:            
   Support for RACF 1.10 (compatible) - toleration of new records.      
   Support for NETSPY Release 4.7.                                      
   Support (partial) for AS/400,OS/400 Release 3.6 (INCOMPATIBLE).      
   Support for Thruput Manager #V041238 (INCOMPATIBLE).                 
   All datetime constants '01JAN00:...' were changed to '01JAN1900:....'
   Corrections to errors that were only in MXG 14.02:                   
     TYPE37   14.107  INPUT STATEMENT EXCEEDED ID=37                    
     TYPE72   14.102  INPUT STATEMENT EXCEEDED ID=72                    
     TYPENSPY 14.097  Zero obs in NSPYLU.                               
   Major enhancements added in MXG 14.02 dated April 25, 1996:          
    ASMTAPES MAINTLEV 9, monitor no longer quits writing, TMNT013I msg. 
    Support for IBM's Cache RMF Reporter CRR Version 1.7.               
    Support for Netview FTP (File Transfer) SMF subtype 51x record.     
    Support for second length STK HSC Subtype 08 record.                
    Support for Shared Page Groups statistics in TYPE71.                
    Support for STK's NearOAM user SMF record.                          
    Support for IBM's RMDS Version 2.2 (no change).                     
    Support for NPM APARs OW08565/OW10584 for 3746/900.                 
   Major enhancements added in MXG 14.01 dated March 7, 1996:           
    Support for OS/390 Release 1.1.0 (already in MXG 13.13).            
    Support for FACOM MSPE/EX PTF 93061 ID=127 SMF record.              
    Support for SMF type 6's ESS segment added and externalized.        
    MAINTLEV 8 of the MXG Tape Mount and Tape Allocation Monitor        
    INPUT EXCEEDED for NETSPY 4.6, type A record.                       
    INPUT EXCEEDED for STK HSC subtype 8 record corrected.              
    INPUT EXCEEDED for DB2 4.1 type 101 subtype 2 (packages).           
    INPUT EXCEEDED for DFSMS/rmm type "O" record.                       
    INPUT EXCEEDED for EREP type '40'X record.                          
    INPUT EXCEEDED for PSF 6 SMF, PSF wrote truncated record.           
    INPUT EXCEEDED for VSAM 64 SMF, CF Cache Structure segment.         
    ASMVTOC failed to assemble.                                         
    INVALID DATA FOR HH,MM,SS with SAMS SMF record.                     
    VARIABLE SYSTEM uninitialized in ASMIMSLG processing.               
    Hipercache SMF record values for VSAM segment wrong.                
    NDM/Connect Direct timestamps missing, data wrong.                  
    TLMS dates were not decoded correctly.                              
    NPM dataset NPMVSVVR variables were trashed.                        
  All of these enhancements are described in the Change Log, below.     
    Table of availability dates for the IBM products and MXG version:   
                                       Availability     MXG Version     
      Product Name                     Date              Required       
      MVS/ESA 4.1                      Oct 26, 1990.        8.8         
      MVS/ESA 4.2                      Mar 29, 1991.        9.9         
      MVS/ESA 4.2.2                    Aug     1991.        9.9         
      MVS/ESA 4.3                      Mar 23  1993.       10.10        
      MVS/ESA 5.1.0 - compatibility    Jun 24, 1994        12.02        
      MVS/ESA 5.1.0 - Goal Mode        May  3, 1995        13.01        
      MVS/ESA 5.2.0                    Jun 15, 1995        13.05        
      MVS/ESA 5.2.2                    Oct 19, 1995        13.09        
      OS/390  1.1.0                    Feb 22, 1996        14.01        
      OS/390  1.2.0                    Sep ??  1996        14.05        
      CICS/ESA 3.2                     Jun 28, 1991.        9.9         
      CICS/ESA 3.3                     Mar 28, 1992.       10.01        
      CICS/ESA 4.1                     Oct 27, 1994.       13.09        
      CICS/ESA 5.1                     Sep 10, 1996        14.07        
      CRR 1.6                          Jun 24, 1994.       12.02        
      DB2 2.3.0                        Oct 28, 1991.       10.01        
      DB2 3.1.0                        Dec 17, 1993.       13.02A       
      DB2 4.1.0 Tolerate               Nov  7, 1995        13.07        
      DB2 4.1.0 Full support           Nov  7, 1995        14.07        
      DFSMS/MVS 1.1                    Mar 13, 1993.       11.11        
      DFSMS/MVS 1.2                    Jun 24, 1994.       12.02        
      DFSMS/MVS 1.3                    Dec 29, 1995.       13.09        
      NPM 2.0                          Dec 17, 1993.       12.03        
      NPM 2.2                          Aug 29, 1994.       12.05        
      NPM 2.3, 2.4                     ??? ??, 1996.       14.03        
      RMDS 2.1, 2.2                    Dec 12, 1995.       12.12        
      TCP/IP 3.1                       Jun 12, 1995.       12.12        
      VM/ESA  2.0                      Dec 23, 1992.       10.04        
      VM/ESA  2.1                      Jun 27, 1993.       12.02        
      VM/ESA  2.2                      Nov 22, 1994.       12.06        
    Table MXG support for non-IBM products:                             
                                       Availability     MXG Version     
      Product Name                     Date or Change    Required       
       The Monitor for DB2 Version 3                       14.07        
       The Monitor for DB2 Version 2                       13.06        
       The Monitor for CICS/ESA 1.2 -                      12.12        
       The Monitor for CICS/ESA 1.3 -                      12.12A       
       The Monitor for MVS/ESA 1.3  -                      12.05        
       Omegamon for CICS V300 User SMF                     12.05        
       Omegamon for CICS V400 User SMF                     13.06        
       Omegamon for IMS V110 (ITRF)                        12.12        
       Omegamon for IMS V300 (ITRF)                        14.04        
       Omegamon for MVS  V300               13.170         13.05        
       Omegamon for MVS  V400               13.201         13.06        
       Omegamon for DB2 Version 2.1/2.2                    13.05        
       Omegamon for VTAM V160                              12.04A       
       Omegamon for SMS V100/V110                          12.03        
       ASTEX 2.1                                           14.04        
      Boole & Babbage                                                   
       IMF 3.1 (for IMS 5.1)                               12.12        
       LMS 3.1                                             12.12A       
II.   MXG Technical Notes.                                              
 1. The following Invited Paper will be presented at CMG 96 and SUGI 97.
                 Data Mining the Original Data Warehouse:               
            Twenty-Five Years and a Million Lines of SAS Later          
                       H. W. "Barry" Merrill, PhD                       
The author of MXG Software provides a historical perspective of how and 
why the SAS System became the pervasive tool for managing and mining of 
the original data warehouse, the Performance Data Base, built from SMF  
data.  The architecture of the MXG implementation is described to show  
how MXG, currently 911,749 lines of SAS code in 3,011 files (members),  
executes under MVS, VM, UNIX, OS/2, Windows 95 or Windows NT to create  
1,908 SAS tables (datasets) with 78,278 columns (variables) from the raw
data records produced by 268 products, where the input volume ranges    
from only hundreds of megabytes to fifteen gigabytes per day; some CICS 
tables contain in excess of 130 million rows (observations).            
a. Notre Dame - 1959 - WOW! from an IBM 610 digital computer.           
b. Purdue, 1964-1967 - IBM 7090/7094 and IBM 360/44.                    
c. State Farm Mutual Automobile Insurance Company, 1972-1976.           
d. Sun Oil Company, 1976-1984.                                          
e. Architecture of MXG Software SMF Processing - Single Record          
f. Architecture of Building the Performance Data Base - BUILDPDB        
g. Mining costs and tons of warehouse data dug up and delivered:        
h. Growth of the MXG Source Library                                     
i. SAS does not stand for Single Authored Software.  Acknowledgements.  
a. Notre Dame - 1959 - WOW! from an IBM 610 digital computer.           
As a Notre Dame sophomore in EE in September, 1959, my first EE lab     
experiment was to calculate the determinant of a 4x4 matrix.  As the    
ancient Lab Instructor finished his instructions, he said "I have to    
read this.  The IBM corporation has donated a Model 610 dig-it-tal      
computer, located in room 240, and students can sign up for hour-long   
blocks."  Putting down the sheet of paper, he said "those digital things
will never last, but next year, as Juniors, you can learn to use the    
Bendix G15 Analog Computer - that's how engineer's solve real problems!"
      In 2013, John Ehrman took Judy and I thru the Computer Museum in  
      California, where I related this story and saw their Bendix G15   
      computer, but it is described as a digital computer, but I was    
      still certain of my story. Then, in 2014, I posted this first     
      experience to the IBM-Main forum, and one respondant said the G-15
      was digital. Fortunately, my story was proven when a poster noted 
      that if the G-15 had the optional DA-1, Differential Analyzer     
      hardware, it provided all of the analog hardware, the             
      potentiometers and meters, and plugboard circuitry that made it   
      function as an analog computer, even though all of the            
      underpinnings that processed the data were digital circuits, and  
      that old prof would have seen it only as an analog computer.      
        P.S. In those early years, there were problems far more suited  
             to analog computation, especially analysis of transients,  
             before the speed of digital computers, and tools like the  
             Fast Fourier Transform, were able to sample sufficiently   
             fast to eliminate the analog advantage.                    
I went to room 240, looked thru the peephole and saw a large gray box,  
a table with typewriter, and what I assumed to be a senior, and opened  
the door to enter.  As the door unhinged, so did the student, shouting  
"Shut that door!" as he strode across the room to the door, flailing    
his arms.  As he stepped out into the hall shouting "Didn't you read the
damn sign?", he discovered his sign had fallen face down on the floor.  
Calming, he informed me that you must get the operator's attention, so  
he could put the machine in "QUIESCE/STOP" (which took 5-10 seconds),   
and only then was it safe shuffle in, slowly.  The vacuum tube machine  
was so heat sensitive, that the air currents would cause computation to 
fail, requiring a program restart.                                      
He pointed me to the IBM manuals and I began at page one.  Several hours
later, I had learned to punch paper tape and print them on the Selectric
and decided to calculate the determinate on my new toy.  By Saturday, I 
had punched my program, printed it, and was now ready to run my first   
computer program.  As I watched the paper tape whir thru the reader, the
addresses flickered on the nixie tubes; I crossed my arms and thought   
"Wow, it is 1959, I am a sophomore in college and am running a real     
program on a digital computer".  The paper tape came to the end, the    
printer came alive, and I received my first computer output, four       
characters: WOW!  It took until Sunday to find the senior, who found    
that I had sort of missed the difference between "program" and "data",  
that the first punch in the tape was a control character that put the   
610 in a scan mode, that in the fifth-from-end position there was a     
control character to print the tape as machine instructions, and what   
had been printed were the code letters for the last four program        
instructions: W=Carriage Return, O=Line Feed, W= Carriage Return,       
!=Print Accumulator!  (Two Carriage Returns were always used to ensure  
that the very slow print head was all the way left before print.)       
I did finally get the determinant computed, and submitted the first EE  
lab problem that used a digital computer at Notre Dame, but I did       
nothing further with computers while there.  I dropped out of Notre Dame
in 1962, joined the Navy, was in the Cuban blockade on a surface ship,  
then on a Diesel submarine, and then won a Navy scholarship that sent   
me back to college in EE at Purdue University in 1964.                  
b. Purdue, 1964-1967 - IBM 7090/7094 and IBM 360/44.                    
At Purdue, I took a one-hour Fortran II course, using a 7090/7094 and   
was hooked.  I worked on Linear Programs to model power grids, got a job
in the Tab department wiring plug boards for sorters, collators and     
printers, implemented the Fast Fourier Transform from the original      
Cooley-Tukey paper, worked for the Laboratory for Agricultural Remote   
Sensing (pattern recognition of crops from spectral data which led to   
the Earth Resource Technology Satellite), built the ground-truth data   
for LARS agronomists, and set fire to our 360/44 Serial #2 (twice!) with
a tight loop in the floating point divide unit that lacked a heat sink. 
I showed one PhD candidate in  Psychology how pattern recognition and   
vector distance could be used to cluster petroleum engineers that found 
oil from those that did not, and coded Fortran programs to manipulate   
data to invoke the BIMD statistical subroutines for another.  I finished
my BSEE and MSEE in August, 1967, but the Navy needed nuclear submarine 
drivers, not programmers, so again I set computing aside for a second   
masters in Nuclear Propulsion and sightseeing in the Barents Sea, until 
shore duty running the airline to Guantanamo Bay Cuba, where I taught   
calculus and ran the overseas extension for Old Dominion University.    
c. State Farm Mutual Automobile Insurance Company, 1972-1976.           
Leaving the Navy in 1972, my Psychologist friend, now working at State  
Farm Automobile Insurance in Bloomington, IL, suggested that I might    
find a home there.  Dave Vitek had gone to the Boole and Babbage User   
Group (BBUG, the predecessor of CMG) and decided that maybe, instead of 
trusting the IBM salesman as your capacity planner, State Farm could    
measure its own computers, and had funded a ten-person Measurement Unit 
for a feasibility study.  Steve Cullen had drafted an excellent attack  
plan to evaluate tools, and in short order we had Kommand/PACES for     
accounting, Software Monitors (SYSTEM LEAP and PROGRAM LEAP), Hardware  
Monitors (TESDATA XRAY), and Simulation (SAM).  Because Kommand was only
for billing, Denny Maguire had started to write PL/1 programs to extract
fields from SMF records, and I had revived an old Plot subroutine from  
LARS days, when I found this brief announcement in Datamation:          
   The Institute of Statistics at North Carolina State University       
   announces the availability of the Statistical Analysis System, a     
   package of 100,000 lines, one third each in Fortran, PL/1 and        
   Assembler, that does printing, analysis and plotting of data.        
I wrote for information, and got a typical university document, with    
some pages dittoed, some pages typed, some printed, each on paper of a  
different color, but immediately saw the power and simplicity of the    
INPUT statement for SMF data.  However, in the list of supported data   
formats, there was no reference to Packed Decimal.  You only need to get
seven bytes into an SMF record to encounter a Packed Decimal field, so I
called the Institute and asked Tony Barr, the author of the SAS compiler
about support.  "Well, we haven't got around to documenting it yet, but 
if you type in PD4. it will work jest fine" he said, so I convinced     
State Farm to risk the 1972 purchase price of $100 for the SAS package. 
Starting in 1964, Tony Barr and Dr. Jim Goodnight had collaborated to   
develop an ANOVA routine for the Department of Agriculture.  Tony had   
been an IBM developer of the data base for the cold war's Distant Early 
Warning (DEW line) radar system, and Jim was a well-known statistician. 
Both recognized the weakness of the existing stat packages: they were   
only subroutines that had to be invoked by other programs that had to   
prepare and manage the data to be analyzed.  By creating a language, a  
database, and the statistics, the Statistical Analysis System expanded  
well beyond the original ANOVA routine and had been tested at several   
Agricultural Experimental Stations and other universities, but the 1972 
announcement was the first public release of the Statistical Analysis   
System, and in October, 1972, State Farm was the first real customer to 
install the SAS package from NCSU's Statistics Department.              
Within days of receipt of SAS, we were extracting CPU time and PROGRAM  
name and K-Core-Hours to produce reports on resource consumption direct 
from SMF records, and, because SAS stores in floating point, we found   
that Kommand lost hours of CPU time thru truncation.  Presentations on  
the use of SAS software and the PDB were given to the Bloomington and   
Chicago chapters of the ACM and DPMA; the SAS data base was mentioned in
my paper (on the use of the SAS data base to create simulation input for
the System Analysis Machine directly from actual SMF data) presented at 
the 1973 SSCS (Symposium on the Simulation of Computer Systems) at NBS, 
and at a BOF session at the Seventh Annual Interface Symposium at Iowa  
State.  Many XRAY hardware monitor users became aware of State Farm's   
PDB through the Midwest TESDATA Users Group, which held its inaugural   
meeting in 1973 at State Farm.  These presentations were only half      
technical; we also had to convince attendees that staffing of this new  
measurement concept was cost justified by the real dollar savings.  John
Chapman had used an XRAY at Standard Oil and invited me to join SHARE's 
Computer Measurement and Evaluation (CME) project, and the PDB was      
described in a closed session of the CME project at SHARE 42 in Houston 
in March of 1974.  The first open session presentation on the use of the
SAS System to process SMF data was before to an audience of over 750    
(half of the attendees!) at the Chicago SHARE 43 meeting that August.   
That session was split with an IBM presentation on their new Statistics 
Gathering Package, an FDP that selected a few fields from a few SMF     
records.  IBM spoke first, then I showed what we had done with SAS at   
State Farm.  One attendee stood and asked the IBM author of SGP, Bill   
Tetzlaff, "Now that you have seen SAS, is there any reason why you would
still recommend your SGP product?"  Several hundred SHARE sites acquired
SAS that fall as a result of this SHARE session!                        
d. Sun Oil Company, 1976-1984.                                          
In 1974, SAS added File 13, SAS.MERRILL, to their distribution tape with
code examples for reading SMF data.  In 1976, I completed my course work
at the University of Illinois (65 miles each way on a CB500 Honda), and 
when State Farm decided not to rapidly migrate to the new MVS operating 
system, I left for Dallas and Sun Oil company, where I demonstrated that
the analysis of SMF with SAS was valid for VS2 as well.  In 1979 I wrote
my dissertation, "A Comprehensive Approach to the Measurement of Large  
Scale Computer Systems" and received my PhD in EE from U of I.  In 1979,
Jane Helwig, director of publications at SAS Institute (which had become
an independent company in 1975, marketing "the SAS System" instead of   
the "Statistical Analysis System") said users wanted a book and SAS code
that showed how to measure computers, so we worked together on what was 
to be titled "The Analysis of SMF and RMF Data Using the SAS System".   
Just before printing, Jane called to say that no one liked the name, and
asked if my ego could handle the title "Merrill's Guide to Computer     
Performance Evaluation using the SAS System", which became a 395 page   
blue book, sold by SAS with a tape of sample programs for $395.  By     
1983, MVS/XA loomed with radical changes to SMF data, and many of the   
book's users were asking for a real software product, so in 1984, SAS   
published "Merrill's Expanded Guide to Computer Performance Evaluation  
Using the SAS System", an 835 page red book ($50), and SAS distributed  
the new MXG Software tape ($700) that was shipped with the then optional
Merrill Consultant's "Support Subscription" agreement ($500 annually),  
and I left Sun Oil.  Judy, who had taught Business College and had been 
an executive with an apparel firm, said that she would run the business 
and I would write and support the software; she does and I do.  In 1987,
SAS Institute published the 630 page red book "Merrill's Expanded Guide 
Supplement" and in 1991, Merrill Consultants replaced the old Support   
Subscription with a License Agreement and took over all distribution of 
MXG Software and MXG Books.                                             
MXG Software has been installed at over 5,200 data centers in all states
and 49 countries (although there are only about 3,000 licenses now, due 
to data center consolidations), and over 15,000 people bought the books.
e. Architecture of MXG Software SMF Processing - Single Record          
So much for history.  The design of MXG Software exploits many features 
of the SAS System, especially in the DATA steps that are used to convert
raw SMF data into SAS tables (aka "datasets") that are stored in SAS    
data libraries (aka SAS "databases").  A simple SAS program to read the 
SMF file and decode type 0 (IPL) records is shown in Figure 1:          
                        Figure 1                                        
DATA TYPE0;                                                             
INFILE SMF;                                                             
LENGTH DEFAULT=&MXGLEN IPLTIME 8;                                       
FORMAT DOWNTM   SMCAJWTM     TIME12.2                                   
       IPLTIME           DATETIME21.2                                   
INPUT @1 MVSXAFLG     PIB1.                                             
      @2 ID           PIB1.                                             
      @3 SMFTIME SMFSTAMP8.                                             
     @11 SYSTEM   $EBCDIC4.                                             
IF ID=0 THEN DO;                                                        
  INPUT @15 SMCAJWTM   PIB4.   /*SMF0JWT*/                              
        @19 SMFBUFF    PIB4.   /*SMF0BUF*/                              
        @23 VIRTSIZE   PIB4.   /*SMF0VST*/                              
        @27 SMCAOPT    PIB1.   /*SMF0OPT*/                              
        @28 REALSIZE   PIB4.   /*SMF0RST*/                              
  OUTPUT TYPE0;                                                         
But to process more than one SMF record, a separate program for each    
record type would be needed, and the SMF file would have to be read once
for each SMF record.  Instead, for each record type, MXG creates one    
source member, VMAC0, that defines two "old-style" substitution MACROs, 
_VAR0 and _CDE0 with the code segments that are unique to each record:  
  MACRO _VAR0  TYPE0  %                                                 
  MACRO _CDE0  Figure 1 code from LENGTH thru END;   %                  
and one source member, VMACSMF, for the INFILE SMF code segment:        
  MACRO _SMF   INFILE SMF ...;   %                                      
and you can construct a SAS program that will read multiple SMF records 
in one pass of the SMF data using simple macro references:              
 %INCLUDE SOURCLIB(VMAC0,VMAC6,VMAC30,VMACSMF);                         
 DATA _VAR0 _VAR6 _VAR26 _VAR30 ; _SMF; _CDE0 _CDE6 _CDE26 _CDE30 ;     
to create SAS datasets from type 0, 6, 26 and type 30 SMF records.      
These old-style MACRO statements are used simply as shorthand; SAS will 
replace the macro name with its contents as SAS reads the source code.  
They were not replaced by the newer %MACRO facility, because MACRO can  
handle any text string, whereas %MACRO has real problems if the text has
parenthesis, and because %MACROS must be compiled, while MACROs are     
simply read and stored.  All MXG MACRO names start with an underscore.  
The actual MACRO definitions for _VAR0 and _CDE0 in member VMAC0 can    
now be examined in detail in Figure 2 to see the SAS features used:     
                       Figure 2                                         
%INCLUDE SOURCLIB(IMAC0);  /* DEFINES _LTY0 AND _KTY0 */                
MACRO _VAR0                                                             
 _LTY0      /* TYPE0 */                                                 
        (LABEL='TYPE 0 IPL SMF'                                         
               SMCAJWTM SMFBUFF  SYSTEM   VIRTSIZE ZDATE                
               /* ADDED BY MVS/ESA 5.1 */                               
               PRODUCT  SYSNAME   SYSPLEX                               
MACRO _CDE0                                                             
IF ID=0 THEN DO;                                                        
  DOWNTM  ='ESTIMATED*SYSTEM*DOWNTIME'                                  
  IPLTIME ='SMF*RECORD*TIME STAMP'                                      
  OPTDSETS='CREATE*DATA SET/DASD*RECORDS?'                              
  OPTVOL  ='CREATE*VOLUME*RECORDS(19/69)?'                              
  PRODUCT ='MVS*PRODUCT*NAME'                                           
  REC     ='TEMPORARY*SCRATCHES*(PERM/ALL)?'                            
  SMCAJWTM='JOB WAIT*(ABEND 522)*LIMIT'                                 
  SMFBUFF ='SMF*BUFFER*SIZE(BYTES)'                                     
  SYSNAME ='SYSNAME*PARAMETER*FROM IEASYSXX'                            
  SYSPLEX ='SYSPLEX*NAME FROM*COUPLEXX'                                 
  SYSTEM  ='SYSTEM*ID'                                                  
 LENGTH DEFAULT=&MXGLEN IPLTIME 8;                                      
 FORMAT DOWNTM   SMCAJWTM     TIME12.2                                  
        IPLTIME           DATETIME21.2                                  
        ZDATE                  DATE9.                                   
   IF NBAD0 LE 3 THEN                                                   
       '                RECORD IS DELETED ' _N_= SYSTEM= /              
       +16 SMFTIME=;                                                    
 INPUT @15+OFFSMF SMCAJWTM   &PIB.4.   /*SMF0JWT*/                      
       @19+OFFSMF SMFBUFF    &PIB.4.   /*SMF0BUF*/                      
       @23+OFFSMF VIRTSIZE   &PIB.4.   /*SMF0VST*/                      
       @27+OFFSMF SMCAOPT    &PIB.1.   /*SMF0OPT*/                      
       @28+OFFSMF REALSIZE   &PIB.4.   /*SMF0RST*/                      
 IF LENGTH-OFFSMF GE 56 THEN                                            
 INPUT @32+OFFSMF                +1  /*RESERVED*/                       
       @33+OFFSMF PRODUCT  $EBCDIC8. /*MVS*PRODUCT*NAME*/               
 OPTDSETS='NO ';                                                        
 IF SMCAOPT='...1....'B THEN OPTDSETS='YES';                            
 OPTVOL='NO ';                                                          
 IF SMCAOPT='...01...'B THEN OPTVOL='YES';                              
 IF SMCAOPT='......1.'B THEN REC='ALL';                                 
 %%INCLUDE SOURCLIB(EXTY0);  /* _LTY0 OUTPUTS TYPE0 */                  
END;  /* END CDE0 */                                                    
Instead of the TYPE0 dataset name, MACRO _VAR0 contains the MACRO name  
_LTY0, the "Library" macro, that is defined in IMAC0, the "Installation 
Tailoring member" for the VMAC0 member.  The default definition in IMAC0
is MACRO _LTY0 TYPE0 %, to create the WORK.TYPE0 dataset; by using an   
externalized macro name in place of a hardcoded name, you can tailor    
IMAC0 to send the TYPE0 dataset to tape for a large dataset to          
save DASD space, or could rename TYPE0, without ever modifying the MXG  
Source Library.  By concatenating a tailoring library that contains all 
of your changes ahead of the MXG Source Library:                        
       //         DD DSN=MXG.MASTER.SOURCE.LIBRARY,DISP=SHR             
installing a new version of MXG is little more than replacing the old   
MXG Version's Source Library with the new MXG Version's Source Library. 
The KEEP= list inside the parenthesis names the variables that are to be
kept in dataset TYPE0.  Without the dataset KEEP= operand, all variables
defined in the DATA step would be kept.  At the end of the KEEP= list is
the _KTY0 token, defined in IMAC0, which defaults to null.  If you wish 
to create new variables NEWVAR1 and NEWVAR2 in dataset TYPE0, you would 
define  MACRO _KTY0 NEWVAR1 NEWVAR2 %  to add those variables to KEEP=  
list.  Moreover, if you want to drop variables that you don't need (to  
reduce the stored size of TYPE0), for example OPTDSETS and OPTVOL, you  
would define MACRO _KTY0 DROP= OPTDSETS OPTVOL %  and those variables   
would not be kept in dataset TYPE0, because the DROP= list overrides the
KEEP= list!  You can also use the KTY0 macro name to add any dataset    
option (for example, COMPRESS=YES) for the TYPE0 dataset.               
When variables are listed in a KEEP= list but are not created, those    
variables are not kept.  This is exploited in CICS type 110 processing, 
where optional segments (DL/I, DBCNTL) may or may not exist.  MXG names 
those variables in the KEEP= list, but the optional processing code (in 
IMACICDL,IMACICDB) is commented out, so SAS never sees the creation of  
those variables, and they are not kept.  In this way, only one member,  
the optional IMACs, needs to be tailored to create them.  The SAS option
DKROCOND=WARN/NOWARN (Drop/Keep/Rename Output) can be enabled to see if 
variable names are listed but not referenced.                           
Inside the _VAR0 definition, the dataset LABEL= operand describes the   
dataset (that label is visible thru PROC CONTENTS), and the KEEP= list  
is commented when new variables are added by a new release.  Variables  
in the KEEP= list are listed alphabetically and collimated for ease in  
reading, but that ordering has no actual effect on the built dataset.   
Instead, by making the first SAS statement inside the _CDE0 macro to be 
the LABEL statement, and by listing variable names alphabetically, the  
dataset is created with variables in alphabetical order, so PROC PRINTs 
and PROC MEANS will show the variables in order, which is very useful   
when the dataset has hundreds of variables.                             
The LENGTH statement follows the LABEL statement and always contains    
DEFAULT=&MXGLEN, causing SAS to store numerics in only 5 stored bytes,  
SAS default is 8 bytes, halving the DASD storage required.  Four bytes  
floating point will store exact integers up to 16,777,216 and will keep 
seven significant digits, quite sufficient for most numerics.  However, 
variables that contain DATETIME stamps require 8 bytes (using only four 
bytes for a DATETIME variable will truncate up to 255 seconds), and some
accounting variables (like Service Units) are also kept in 8 bytes (that
will store 16 significant digits, integers up to 72,057,594,037,927,936)
The FORMAT statement assigns the display format for variables, but does 
not affect the internal value of the SAS variable.  Time variables are  
stored internally as seconds and fractions; most SMF durations have     
resolution of .01 second so they are FORMATed TIME12.2 (999:59:59.99).  
Datetime variables are stored internally as the number of seconds before
or after Jan 1, 1960, the SAS epoch, and are FORMATed as DATETIME21.2   
(15AUG2019:12:00:00, the startime of the third Woodstock) and display   
the four-digit year.  Date variables are stored internally as the number
of days since the SAS epoch and are FORMATed DATE9 (15AUG2019).         
Although FORMATs are assigned during creation of the variable, you can  
always override in your reports with your own FORMAT statement.  This is
especially true of the DATETIME format.  If you want to count IPLs by   
Date and Hour, you do not have to use DATEPART() and HOUR() functions to
create new variables in a new dataset; instead, you can directly process
the MXG dataset in your report program and shorten the format length:   
To count by date, use FORMAT IPLTIME DATETIME7.;  Because of this SAS   
feature, MXG datasets always have one DATETIME variable instead of two  
separate Date and Time variables.                                       
Following the FORMAT statement, variables LENGTH and OFFSMF are tested  
to detect invalid type 0 records (SYSPROGs who create SMF record often  
have unexpectedly created a record with ID=0).  LENGTH and OFFSMF are   
created in MACRO _SMF, a portion of which is shown in Figure 3:         
                     Figure 3                                           
     MACRO _SMF                                                         
                  END=ENDOFSMF RECFM=VBS LRECL=32760 JFCB=SMFJFCB;      
       RETAIN OFFSMF PREVID PREVSYS;                                    
       IF OFFSMF=. THEN DO;                                             
          IF SUBSTR(SMFJFCB,100,1)='....1...'B  THEN OFFSMF=4; /*VSAM*/ 
          ELSE OFFSMF=0;                                                
          %%INCLUDE SOURCLIB(IMACZDAT); /* SET ZDATE=TODAY() */         
       INPUT @1+OFFSMF MVSXAFLG   &PIB.1.                               
             @2+OFFSMF ID         &PIB.1.                               
             @3+OFFSMF SMFTIME SMFSTAMP8.                               
            @11+OFFSMF SYSTEM   $EBCDIC4.                               
       %%INCLUDE SOURCLIB(IMACFILE);                                    
The leading semicolon before INFILE is needed to terminate the DATA     
statement that will precede it (since the _VARxxxx tokens cannot end    
with a semicolon).                                                      
The OFFSMF test is initialization logic; once OFFSMF has been set, the  
RETAIN statement will keep that value.  The JFCB=SMFJFCB operand on the 
INFILE puts the SMF Job File Control Block in variable SMFJFCB; if the  
fifth bit of the 100th byte of the JFCB is on, your //SMF DD points to  
an undumped VSAM SMF file.  SMF records in the VSAM SMF file have four  
bytes that are not present in the dumped SMF BSAM records; by setting   
OFFSMF=4 for VSAM and using +OFFSMF in the INPUT statement, those extra 
bytes are skipped, so you can transparently read either dumped BSAM or  
un-dumped VSAM SMF data.                                                
IMACZDAT externalizes the code to set variable ZDATE (Zee Date Zee obs  
was created) so it can be changed in case of a rerun.  The SMF header's 
four always-present variables are INPUT, and exit member IMACFILE is    
called.  IMACFILE can be used to delete or select SMF records by time,  
ID, or system, to write selected raw SMF records to a flat file, etc.   
Returning to the _CDE0 section, variable SMFTIME that was INPUT in the  
_SMF macro is stored into IPLTIME, and then the variables unique to the 
type 0 record are INPUT.  SAS provides a wide range of SMF INFORMATS    
(SMFSTAMP, TODSTAMP and RMFSTAMP) that convert data into SAS datetime   
values; these unique INFORMATs work the same on all SAS platforms.      
However, INFORMATs IB, PIB, PD, RB, and NUM under MVS must be changed to
S370FIB, S370FPIB, S370FPD, S370FRB, and S370FF when SAS is executed on 
ASCII platforms.  For these INFORMATs, MXG uses a macro variable name   
(&PIB) in its source code, and member VMXGINIT (invoked by the CONFIG   
member at startup) executes either %LET PIB=S370FPIB or %LET PIB=PIB,   
depending on the execution platform, for transparent execution anywhere!
While numeric variables can be used for fields containing hex values,   
using HEX format for display, MXG now INPUTs hex fields into character  
variables with INFORMAT $CHAR and assign a $HEX FORMAT, because a one   
byte character variable stores in one byte, while a one byte numeric    
needs two storage bytes on MVS and three bytes on ASCII platforms, and  
a four-byte numeric must be stored in five-bytes to see all of the bits.
MXG detects when IBM has added new data to a record, to make MXG fully  
backwards compatible with all levels of MVS.  The test for LENGTH-OFFSMF
detects the new data added by MVS/ESA 5.1.  While bits in MVSXAFLG might
have been used to identify the MVS version that wrote the record, it is 
usually safer to test the record length rather than a version indicator,
because developers must set the length correctly, but do not always     
update version numbers!                                                 
Although not shown in the _SMF macro in Figure 3, variables PREVSYS and 
PREVTIME contain the SYSTEM and SMFTIME from the immediately preceding  
SMF record, so that variable DOWNTM, an estimate of the outage, can be  
calculated for the TYPE0 (IPL) dataset.  Then _CDE0 creates variables,  
converts SMCAJWTM to seconds, and the TYPE0 Data Set Exit member EXTY0  
is INCLUDEd.  That member contains comments and the SAS statement:      
    OUTPUT _LTY0;                                                       
to externalize the OUTPUT of the TYPE0 dataset.  In the Data Set Exit   
you can create new variables to be output, or you can add logic to      
conditionally execute the OUTPUT statement and thereby output only      
certain observations.  The exit is taken after all variables have been  
created, so any criteria can be used for selection.  The Data Set Exit  
member plus the _L and _K macro definitions in the IMAC member allow    
complete user tailoring of the contents of all MXG datasets.            
f. Architecture of Building the Performance Data Base - BUILDPDB        
I coined the term PDB, for the Performance Data Base, while at State    
Farm in the fall of 1972, when I began to regularly use my SAS program  
to process weekly SMF data records (from OS/360 MVT Release 20.6!).  I  
recall a comment that we would need to build a warehouse to store the   
SMF data tapes, and a reply that we would let SAS manage the warehouse! 
The original PDB used only type 0, 1, 4, 5, 6, and 12 SMF records, and  
the weekly PDB, A.PERF155(0), was built on a mountable 3330-1 device;   
six weekly PDBs would fit on one 3330 back then! I implemented the daily
PDBs in 1973, at the request of Operations, who had come to like the    
weekly reports and wanted daily detail.  All trending, capacity planning
and serious analysis must use weekly data, rather than daily or monthly,
to see the true growth, because holiday-containing weeks fall out of a  
weekly plot, while monthly data varies according to the number of work  
days (and when they fall in the week) and cannot be normalized safely.  
The term PDB was in wide-spread use inside State Farm by 1973, when     
Mario Morino and Doug Denault came to Bloomington, to install the first 
copy of their new TSO/MON product.  They arrived Monday morning, and    
with the help of Kathy Colbert and Steve Cullen, they had assembled and 
started the monitor by noon.  They then began to compile their COBOL    
report programs, which were still compiling at 6pm when Kathy handed me 
the SMF format for the TSO/MON SMF record as they went out to supper. I 
wrote the SAS code to decode the new record, added it to the PDB job,   
and came in the next morning to find the new code was successful; when  
Mario and Doug showed up at 8am, I gave them a SAS plot of the number of
TSO users versus time of day, and thus did Mario learn of the power of  
SAS! (Only late that second day did their programs produce any reports!)
The MXG BUILDPDB logic consists of five phases.  In the first phase,    
the input SMF file is read and multiple SAS datasets are created in the 
//WORK data library.  The simple macro references for this phase are:   
 _VAR0    _VAR0203 _VAR6  _VAR21 _VAR26J2 _VAR30 _VAR7072 _VAR71        
 _VAR73   _VAR74   _VAR75 _VAR77 _VAR78   _VAR89 _VAR110  _VARDB2       
 _VARTMNT _VARUSER                                                      
 _CDE0    _CDE0203 _CDE6  _CDE21 _CDE26J2 _CDE30 _CDE7072 _CDE71        
 _CDE73   _CDE74   _CDE75 _CDE77 _CDE78   _CDE89 _CDE110 _CDEDB2        
 _CDETMNT _CDEUSER;RUN;                                                 
This DATA step creates 116 SAS datasets in the //WORK library, creates  
the CICSTRAN dataset (one per CICS transaction, from type 110) and the  
DB2ACCT dataset (one per DB2 plan, from type 101) direct to tape (to    
minimize DASD space and yet capture each CICS transaction and DB2 plan).
Programs ASUMCICS and ASUMDB2A, executed after BUILDPDB, read the tape  
detail transaction datasets to create the summary datasets PDB.CICS and 
PDB.ASUMDB2A that are compact for CICS and DB2 response and resources.  
Four PDB exits, EXPDBINC, EXPDBVAR, EXPDBCDE, and EXPDBOUT allow other  
SMF records to be added to the PDB in the one reading of the SMF file.  
In the second phase of BUILDPDB, datasets TYPE0, TYPE0203, TYPE21,      
are SORTed from the //WORK data library into the //PDB data library.  By
creating PDB datasets in SORT order, report programs do not have to do  
a SORT; instead, they can use BY statements with the report procedures  
to save CPU time and I/O activity for reporting.  The sort order is     
preserved into the WEEKLY and MONTHLY PDB libraries as well.            
The third phase SORTs these RMF datasets into the //PDB data library:   
and then invokes member RMFINTRV to read and MERGE these datasets:      
 TYPE70 TYPE71   TYPE72   TYPE72GO TYPE73P  TYPE74 TYPE75   TYPE78      
to create one observation per RMF interval in the PDB.RMFINTRV dataset. 
PDB.RMFINTRV contains the PCTCPUBY from type 70, and (by using member   
IMACWORK to map performance groups or service classes to workloads) type
72 resources are summed in Batch, TSO, CICS, etc workload variables, so 
uncaptured CPU time and capture ratio can be measured, and the paging   
swapping and I/O activity is contained in a single observation for each 
RMF interval, providing hour-by-hour capacity measurement data.         
The fourth phase reads the 47 CICS statistics datasets that were written
to the //WORK library and invokes member CICINTRV to summarize them into
the PDB.CICINTRV (interval) and PDB.CICEODRV (shutdown) CICS datasets.  
The fifth phase of BUILDPDB operates on the type 30 subtype 1, 4, and 5 
records, the type 6, and type 26 records to create accounting, resource 
and activity data for Jobs, TSO, STC, APPC, and Open MVS address spaces.
Records for incomplete jobs (i.e., executed but not printed, or still   
running when SMF was dumped, etc.) that were written yesterday to the   
PDB's //SPIN data library are merged in with today's new SMF data.  The 
completed jobs are written to the PDB.JOBS (one observation per job, 223
variables), to the PDB.STEPS (one per step, 200 variables), and to the  
PDB.PRINT (one per print file, 51 variables) and job accounting fields  
are propagated into PDB.STEPS and PDB.PRINT so that resource billing by 
account at the job, step, or program level can be done directly from the
PDB.  Today's still-incomplete job's records are written to the //SPIN  
library for tomorrow's processing.  The IMACSPIN member defines SPINCNT,
the number of days BUILDPDB will SPIN records.  While the PDB.JOBS,     
PDB.STEPS and PDB.PRINT data sets contain observations for completed    
jobs, the dataset PDB.SPUNJOBS describes all jobs in the //SPIN library,
so all of yesterday's work can be analyzed.  Holding the records in the 
//SPIN library until the job has purged produces a single picture of the
job.  If records are not SPUN, one day's PDB can have an obs with only  
the CPU time from the type 30s, another day's PDB can have an obs with  
only print lines from the type6, and yet another day's PDB will have an 
obs with just Purge record data, and all three obs from this one job    
will have many missing values and an incomplete picture, although no    
resources are lost.  The individual SPINxxxx data sets are copied from  
the SPIN library into the PDB library for backup purposes.  You can     
always go back to the last successful run, copy the SPINxxxx datasets   
from that PDB into the SPIN library, and then restart after an error.   
While dataset TYPE70PR (one obs for each PR/SM, MDF, or MLPF LCPUADDR in
each LPAR) contains LPAR utilization, INCLUDing ASUM70PR after BUILDPDB 
summarizes TYPE70PR to creates the more usable PDB.ASUM70PR dataset with
resources consumed by each LPAR and with total CPU busy for all LPARS.  
g. Mining costs and tons of warehouse data dug up and delivered:        
The first phase of BUILDPDB took 1 hour and 1 minute of elapsed time and
16 minutes of CPU time on an IBM 9021-952 to process two 3490 tapes with
596,814 SMF records totaling 2,314 Megabytes (2.3 Gigabytes) of raw SMF 
data from three MVS systems.  The total BUILDPDB step plus the ASUM70PR,
ASUMDB2A, ASUMCICS and ASUMJOBS summaries took 1 hour 55 minutes elapsed
and 24 CPU minutes.  The WORK file required only 256 Megabytes (324     
cylinders of 3390).                                                     
This Performance Data Base PDB output data library contains 143 datasets
totaling 3,040 Megabytes, but 2,290 of those Megabytes are in CICSTRAN  
for its 2,333,338 CICS transactions.  The high-volume CICSTRAN dataset  
is written directly to tape, to archive each transaction, but using no  
DASD space.  Then CICSTRAN's 2,290 MB are summarized into only 21 MB in 
the 214,088 observations of the PDB.CICS summary dataset by ASUMCICS    
(which invokes the VMXGSUM generic summarization %MACRO and took only 22
minutes elapsed and 3 and a half minutes of CPU for that summarization).
So the online DASD PDB required only 910MB (1150 cylinders on a 3390).  
Its contents are shown in Figure 4.  Most of the volume is taken by only
a few datasets: DB2ACCT (427MB for 266,513 DB2 plan executions, which   
could be sent to tape like CICSTRAN), STEPS (83MB for 88,777 steps),    
ASUMDB2A (69MB, the summarized output from DB2ACCT), TYPE74 (48MB), JOBS
(34MB for 31,472 job executions), TSOMSYST (30MB), TYPE30MU (22MB) and  
CICS (21MB), plus all other RMF data (24 MB) account for 760 MB.  But   
many important datasets are less than one megabyte; the RMFINTRV summary
dataset has 24 hours of each of the 3 system's 15-minute RMF interval   
data (288 obs) in only 452 Kilobytes (9 tracks) of DASD space!          
                         Figure 4                                       
Dataset        Obs  Vars    Len  MBYTEs Description                     
ASUM70PR       288   218    836         RMF  PR/SM LPAR INTERVAL SUMMARY
ASUMDB2A     52110   323   1383    69   DB2  DB2ACCT INTERVAL SUMMARY   
CICAUSS       4648    31    172     1   CICS AUTOINSTALL TERMINAL USS   
CICAUTO         96    43    203         CICS AUTOINSTALL GLOBAL         
CICCONMR      2110    37    183         CICS ISC/IRC MODE ENTRY         
CICCONSR      2044    48    223         CICS ISC/IRC SYSTEM ENTRY       
CICCONSS        90    27    139         CICS ISC CONNECTION - SECURITY  
CICDQG          96    38    183         CICS TDQUEUE TRANSIENT DATA GLOB
CICDQR        1992    28    140         CICS TDQUEUE TRANSIENT DATA SPEC
CICDS           96    87    367         CICS DISPATCHER, CPU BY TCB     
CICDTB          96    21    115         CICS DYNAMIC TRANSACTION BACKOUT
CICEODRV        96   290   1180         CICS END OF DAY                 
CICFCR        2352    70    435     1   CICS FILE CONTROL SPECIFIC      
CICINTRV         0   290   1180         CICS INTERVALS                  
CICJCR         196    32    162         CICS JOURNAL CONTROL SPECIFIC   
CICLDG         576    43    208         CICS LOADER DOMAIN FOR PROGRAM  
CICLDR      165362    28    144    23   CICS LOADER DOMAIN FOR PROGRAM  
CICLSRFR       688    25    135         CICS LSRPOOL FILE STATS EACH FIL
CICLSRR         76   294   1220         CICS LSRPOOL POLL STATS EACH POO
CICM            96    27    139         CICS MONITOR DOMAIN GLOBAL      
CICPAUTO        96    22    119         CICS AUTOINSTALL PROGRAM        
CICS        214088    23    105    21   CICS INTERVAL TRANS SUMMARY     
CICSDG          96    21    115         CICS SYSTEM DUMP GLOBAL         
CICSDR         496    24    131         CICS SYSTEM DUMP SPECIFIC       
CICSEXCE       205    39    194         CICS EXCEPTIONS                 
CICSMD       15092    35    164     2   CICS STORAGE MANAGER DOMAIN SUBP
CICSMDSA       768    64    335         CICS STORAGE MANAGER DSA AND EDS
CICSMT         384    30    146         CICS STORAGE MANAGER TASK SUBP  
CICST           96    22    119         CICS STATISTICS DOMAIN GLOBAL   
CICSTRAN   2133338   260   1126  2290   CICS TRANSACTIONS               
CICTCR       12476    35    166     2   CICS TERMINAL CONTROL SPECIFIC  
CICTDG          96    21    115         CICS TRANSACTION DUMP GLOBAL    
CICTDR        1368    24    127         CICS TRANSACTION DUMP SPECIFIC  
CICTM           96    53    243         CICS TABLE MANAGER GLOBAL       
CICTSQ          96    57    259         CICS TSQUEUE TERMPORARY STORAG  
CICUSG          96    24    127         CICS USER DOMAIN STATISTICS     
CICUSSRV       147   290   1180         CICS USS INTERVAL SUMMARY       
CICVT           96    30    151         CICS VTAM GLOBAL                
CICXMC        1050    37    183         CICS TRANSACTION MANAGER TCLASS 
CICXMG          96    31    155         CICS TRANSACTION MANAGER GLOBAL 
CICXMR       32216    32    168     5   CICS TRANSACTION MANAGER TRANS  
DB2ACCT     266513   354   1680   427   DB2 PLAN ACCOUNTING             
DB2ACCTB         0    46    294         DB2 PLAN BUFFER POOLS           
DB2ACCTG        11    39     39         DB2 PLAN GROUP BPOOLS           
DB2ACCTP         0    79    458         DB2 PLAN PACKAGES               
DB2GBPAT         0    23    105         DB2 GLOBAL BUFFERS              
DB2GBPST         0    44    148         DB2 STAT GB POOLS               
DB2STAT0       571   540   2130     1   DB2 STATS SUBTYPE 0             
DB2STAT1       571   510   1987     1   DB2 STATS SUBTYPE 1             
DB2STAT2      2296    24    111         DB2 STATS SUBTYPE 2             
DB2STATB      1150    80    348         DB2 STATS BUFFER POOLS          
DB2STATR       357    54    256         DB2 REMOTES                     
DB2STATS       571  1037   4047     2   DB2 STATISTICS INTERVAL         
DDSTATS          0    26    148         TYPE 30 DD SEGMENTS             
IPLS             0    14     70         TYPE 0 IPLS                     
JOBS         31472   223   1121    34   JOBS/TSO/STC/APPC/OMVS          
JOBSKED        194    19     89         JOB SCHEDULING CLASS SUMMARY    
NJEPURGE         0    62    357         NJE PURGE EVENTS                
PRINT        15322    51    363     5   TYPE 6 PRINT EVENTS             
RMFINTRV       288   402   1608         RMF INTERVAL SUMMARY            
RRTMPSE        718    67    301         ROSCOE ACCOUNTING               
SMFINTRV         0   218   1078         SMF INTERVAL ACCOUNTING         
STEPS        88777   200    989    83   STEPS FOR JOBS/TSO/STC/APPC/OMVS
TAPEMNTS         0    18     18         MXGTMNT TAPE MOUNT SUMMARY      
TAPES         1862    28    124         TYPE 21 TAPE DISMOUNTS          
TSOMCALL      9075   110    573     5   TSO/MON USER RESPONSE           
TSOMSYST     39372   183    785    30   TSO/MON SYSTEM INTERVAL         
TYPE0203       140     5     27         SMF DUMP HEADER/TRAILER         
TYPE23          72    22    110         SMF INTERVAL STATISTICS (STATUS)
TYPE30MU    142337    24    165    22   MEASURED USAGE DATA             
TYPE30_6      1392   148    636     1   SYSTEM ASID INTERVALS           
TYPE37        7941   102   1091     8   NETVIEW HARDWARE MONITOR EXTERNA
TYPE70         288   382   1435         RMF CPU ACTIVITY                
TYPE70PR      4800    34    121         RMF PR/SM LPAR ACTIVITY         
TYPE71         288   307   1248         RMF PAGING ACTIVITY             
TYPE72       15941    89    396     6   RMF PERFORMANCE GROUP           
TYPE7204         0    73    321         RMF MONITOR III GOAL MODE       
TYPE72DL         0    35    166         RMF GOAL MODE DELAY SAMPLES     
TYPE72GO         0   151    797         RMF GOAL MODE SERVICE CLASS     
TYPE72MN     14699    81    345     5   RMF MONITOR III COMPAT          
TYPE72SC         0    16     97         RMF SERVICE CLASS SERVED        
TYPE73       47520    45    197     9   RMF CHANNEL PATH                
TYPE74      118712   101    423    48   RMF DEVICE ACTIVITY             
TYPE74CA         0   149    483         RMF CRR CACHE CONTROLLER        
TYPE74CF       384   188   1050         RMF COUPLING FACILITY           
TYPE74OM         0    82    336         OPENMVS KERNEL ACTIVITY         
TYPE74ST      1728    56    259         RMF CF STRUCTURE REQUESTS       
TYPE74TD       288    11     61         RMF TAPE DRIVES ALLOCATED       
TYPE75        1344    40    225         RMF PAGE DATASET ACTIVITY       
TYPE77        9917    43    266     3   RMF ENQ ACTIVITY                
TYPE78           0    29    128         RMF I/O QUEUEING                
TYPE78CF     15080    32    131     2   RMF I/O CONFIGURATION           
TYPE78CU      5155    23    110         RMF LCU CU-HDR QUEUEING         
TYPE78IO      1152    23    107         RMF IOP QUEUE                   
TYPE78PA         0   102    569         RMF JOB-LEVEL VIRTUAL STORAGE   
TYPE78SP         0    18    109         RMF JOB-LEVEL SUB POOLS         
TYPE78VS       288   445   2430         RMF VIRTUAL STORAGE             
TYPE89           0    29    188         MEASURED USAGE INTERVAL         
TYPETALO         0    42    286         MXG TAPE ALLOCATION MON         
TYPETMNT         0    16     82         MXG TAPE MOUNT MONITOR          
TYPETSWP         0     7     33         MXG TAPE SWAP EVENT             
      Total Size in Megabytes:   3200MB                                 
And what about that 130 million observation CICSTRAN dataset?  One      
massive site read that many CICS transactions from 68 SMF tapes (3490E  
compressed) to select 1500 CICS transactions.  The job took 30 elapsed  
hours and 5 CPU hours!                                                  
h. Growth of the MXG Source Library                                     
An Annual MXG Version is created in first quarter of each year, and     
throughout the year, interim Versions are created as needed to keep     
up with new products and changes to old records.  The fourteenth MXG    
Annual Version will ship in early 1997, but MXG 14.06, the August, 1996 
Current Version, was the 99th MXG Version created!  Figure 5 lists the  
measurements of each of the Annual MXG Versions and MXG 14.06. Sometime 
in 1997, the MXG source library should exceed 1,000,000 source lines.   
                            Figure 5                                    
                 HISTORY OF MXG VERSIONS AND RELEASES                   
14.06   20AUG96  3011   911,749  72,939,920  69.6  15,196   1908  78,278
13.13   20JAN96  2940   885,344  70,827,520  67.3  14,756   1868  76,219
12.12   20MAR95  2533   776,687  62,134,960  59.3  12,945   1573  66,221
11.11   26MAR94  2286   654,341  52,347,280  49.9  10,975   1360  55,168
10.10   15MAR93  1965   534,902  42,792,160  40.8   9,999   1195  47,296
 9.9     1MAR92  1605   388,651  31,092,080  29.6   6,477   1093  41,332
 8.8     8APR91  1367   300,000  24,000,000  22.8   5,000    872  30,420
 7.7    15FEB90  1100   230,000  18,400,000  17.5   3,834    679  22,277
 6.6    15JAN89   910   165,614  13,249,120  12.6   2,760    552  18,048
 5.5    01FEB88   785   136,880  10,951,296  10.7   2,281    456  14,909
 4.4    01MAR87   661   108,166   8,653,472   8.8   1,803    360  11,770
 3.2    01FEB86   537    79,444   6,635,648   6.8   1,346    264   8,632
 2.0    01FEB85   413    50,722   4,057,024   4.9     845    169   5,526
 1.0      AUG84   289    22,000   1,760,000   3.0     367     73   2,387
   The original MXG 3420 Tape Reel contained 99 feet of source code!    
i. SAS does not stand for Single Authored Software.  Acknowledgements.  
While I have designed all and written most of the MXG Software, many    
users have contributed code examples, and my three consultants have ably
tested each new release, have covered my technical calls while I am out 
teaching, and who have personally contributed significantly to MXG, are 
hereby acknowledged specifically:                                       
      Chuck Hopf          Bruce Widlund         Freddie Arie            
Overseas, where we are represented by the local SAS Office, there are   
also scores of dedicated SAS technicians who have provided local        
language and local time of day help with MXG queries.                   
But our real thanks for our success are to the dedicated MXG users, who 
have taken the time to learn those prerequisite skills of SAS, JCL, TSO,
and PC technology, and who have waded thru 1,497 pages in two Books, 730
pages in 30 Newsletters, and 2,994 Changes in 99 Releases to learn how  
to use MXG Software to measure and thereby improve the performance of   
their company's computer systems - they have made all of us look good!  
                            Chapter 99                                  
 This chapter cites and thanks all contributors to MXG Software, who    
 are hereby officially awarded the title of "Chapter 99 CodeSharks"!    
 Named by Judith S. "99" Merrill, Vice President and Partner, in honor  
 of the diligent sleuthing of the MXG code performed by each CodeShark, 
 she also established our policy that credit should be given to every   
 MXG user who made any contribution to MXG Software, whether they       
 provided an entire program, or found a programming error, or offered a 
 suggestion, or even just found a comma out of place in a comment!      
  Contributors with Eleven or more Changes - Descending Ranking         
       Name of Contributor   Total Number of Changes                    
         Chuck Hopf               130                                   
         Diane Eppestine           50                                   
         Norbert Korsche           45                                   
         Freddie Arie              40                                   
         Tom Parker                34                                   
         Joseph Faska              28                                   
         Pete Shepard              27                                   
         Siegfried Trantes         23                                   
         Don Deese                 19                                   
         Bruce Widlund             18                                   
         Rodney L. Reisch          18                                   
         Susan Marshall            17                                   
         Tom Elbert                16                                   
         Jim Gilbert               15                                   
         Dan Kaberon               14                                   
         Neil Ervin                14                                   
         Waldemar Schneider        14                                   
         Rod Fernandes             12                                   
         Shaheen Pervaiz           12                                   
         Bob Rutledge              11                                   
         Dan Squillace             11                                   
         Dick Whiting              11                                   
         Don Friesen               11                                   
         George Scott              11                                   
         Ray Dickensheets          11                                   
 2.  MXGTMNT, the Tape Mount and Tape Allocation Monitor Program (in the
     member ASMTAPES, in MXG 14.01 and earlier (MAINTLEV 8 and earlier),
     can stop writing Tape Allocation subtype SMF records, after first  
     sending the messages TMNT008E or TMNT013E to SYSLOG, causing zero  
     observations in dataset TYPETALO.                                  
        (The Tape Mount Monitor part of MXGTMNT continued to write Tape 
        Mount subtypes, and the Allocation monitor can be restarted     
        using the Modify Command, F MXGTMNT,ALLOC=YES.)                 
     The TMNT013E stoppage resulted when the Allocation Monitor had been
     waiting more than 2 seconds for its own lock that controls access  
     to its own SRB, because we thought a long wait should not occur,   
     and so to protect against any possible error in our code, we       
     decided to stop the allocation monitor component.  Two sites (both 
     with very large tape-intensive multi-image environments) reported  
     stoppages.  On investigation with Mike ONeill at Dun and Bradstreet
     (we commented out the stoppage and then examined SYSLOG) he found  
     that across four days there were two instances on two of three MVS 
     images when five or six TMNT013E messages were written, all in one 
     minute!  So what we had were occasional system 'stalls', but no    
     real reason to shut down the allocation monitor.                   
     So beginning with MXG 14.02 (See Change 14.086, MAINTLEV 9), the   
     TMNT013E Error and Stoppage of the Allocation Monitor was replaced 
     by Informational Message TMNT013I - Possible Stall, and the        
     Allocation Monitor now continues to write allocation subtypes.     
     Now that I realize we are detecting system "hangs", or "stalls",   
     the ASMTAPES will be enhanced to actually report these events by   
     creating a new subtype=5 "Possible Stall" event record, so that you
     can analyze if, how often, and how long these "stalls" occur, and  
     can investigate (perhaps by examining SYSLOG to see what system    
     messages immediately preceded the image-wide delay) their cause.   
     Even in advance of that enhancement, you can use MAINTLEV 9 and    
     scan SYSLOG for TMNT013I messages to detect these "stalls".        
     The TMNT008E stoppage occurs if we are unable, after 25 tries, to  
     schedule our SRB in the address space of a tape-using job. This was
     a problem with MAINTLEV 7 and earlier while trying to schedule an  
     SRB for a swapped-out address space, but this has not occurred with
     MXG 13.13, and we no longer expect to see this condition.          
 3.  If you want "RMFINTRV" data for both detail and hourly intervals,  
     you can use this (rather clumsy!) technique until I the new %MACRO 
     %RMFINTRV exists.  You would need to create "YOUR.SPECIAL.PDS" and 
     EDIT member IMACRMFI into "YOUR.SPECIAL.PDS" (and would set the    
     MACRO _DURSET therein for hourly summary - see its comments).      
      //RMFINTHR EXEC MXGSAS                                            
      //PDB      DD DSN=&&PDB,UNIT=SYSDA,SPACE=(CYL,(5,5))              
      //REALPDB  DD DSN=YOUR.REAL.PDB,DISP=OLD                          
      //SOURCLIB DD DSN=YOUR.SPECIAL.PDS,DISP=SHR                       
      //         DD DSN=YOUR.USERID.SOURCLIB,DISP=SHR                   
      //         DD DSN=YOUR.MXG.SOURCLIB,DISP=SHR                      
       PROC COPY IN=REALPDB OUT=PDB;                                    
        SELECT TYPE7072 TYPE71 TYPE73 TYPE74 TYPE75 TYPE78;             
       %INCLUDE SOURCLIB(RMFINTRV);                                     
       DATA REALPDB.RMFINTHR; SET PDB.RMFINTRV;                         
 4.  Some allegations that the KEEPALL=NO option in %VMXGSUM "costs"    
     have been counteracted by extensive measurements.  The KEEPALL=NO  
     option (the default in VMXGSUM) will significantly reduce the DASD 
     work space, CPU time, elapsed time, and I/O consumed by VMXGSUM,   
     because only the variables that are needed are kept.               
     ASUM42DS example:  1,133,117 raw observations reduced to 100,628   
                        observations with 25 variables kept:            
              KEEPALL   WALL    CPU    EXCP   DASD WORK SPACE           
                NO      12:40   2:53   14976      231MB                 
                YES     23:05   4:03   23411      460MB                 
     The only real "cost" of KEEPALL=NO is the cost of the additional   
     DATA and SORT steps that are used to parse the VMXGSUM arguments to
     determine the list of variables to be kept.  That cost is a fixed  
     function of the number of variables that are kept, and is not      
     affected by the number of observations processed.  With a small    
     number of variables (16) the CPU increase is only 2 seconds, while 
     for a lot of variables (354) the CPU increase is still only about  
     15 seconds.  The above example shows that small CPU increase is    
     insignificant when compared with the savings when you actually     
     perform VMXGSUM summarization of typical MXG datasets.             
     The KEEPALL=NO option did increase the size of the SAS log because 
     of the NOTES printed on the log for the additional DATA/SORT steps 
     (800 more lines in the preceding example), but Change 14.145 has   
     enhanced VMXGSUM to insert OPTIONS NONOTES; before those parsing   
     steps (which is reset after parsing) so these extra lines will no  
     longer appear on the log (although enabling the DEBUG option in    
     VMXGSUM will print them if ever needed for diagnostics).           
 5.  BUILDPDB processes SMF data at 41MB per CPU-minute on a 3090-300S. 
     You can separate the Compile cost of BUILDPDB from the Read+Write  
     cost to estimate the CPU time per megabyte of data.  By specifying 
     //SMF DD DUMMY in your JCL, the CPU cost of Compile with no records
     read is measured (use the CPU Time on the SAS log following the    
     "MXG HAS SUCCESSFULLY READ xxx MB of SMF DATA" message and use that
     message for SMF data volume).  Then execute BUILDPDB with real     
     //SMF DD DSN=... to measure Compile+Read+Write CPU time.  The delta
     between the two runs measures the CPU time to read that amount of  
     SMF data and create all of the //WORK datasets.  For example, on a 
     3090-300S, the Compile+Read+Write with 30MB took 143 seconds while 
     the Compile phase took 99 seconds so BUILDPDB took 143-99=44 CPU   
     seconds for the 30MB, or processes 41MB of SMF data per CPU minute.
III.  MVS Technical Notes.                                              
 1.  APAR OW16564 corrects zero value in PCHANBY variable in TYPE73 that
     began with MVS/ESA 5.2.0.  One site had added test IF PCHANBY GT 0 
     THEN before the OUTPUT statement in member EXTY73 (so as to output 
     TYPE73 observation only if there was channel activity during the   
     interval) and found that test reduced 16,896 observations from 5.1 
     to only 8,000 (i.e., half of the time there was no channel         
     activity), but with the IBM error in MVS/ESA 5.2 data, only 55     
     observations had non-zero PCHANBY value!  (Note that the MXG test  
     inside VMAC73 to invoke the EXTY73 exit does not test for usage of 
     the channel, but rather will output only real channel segments.    
     IBM writes 255 channel segments in each type 73 record.  Without   
     the MXG heuristic to delete the false channel segments, there would
     have been 26,456 observations output instead of 16, 896!).  You    
     could add your test to EXTY73 to only output if PCHANBY is non-zero
     to reduce observations, but even with 16,896 observations, the size
     of a daily TYPE73 dataset is only about 500,000 bytes!             
 2.  APAR OW16847 and OW19029 corrects TYPE30 variables EXCPTOTL and all
     EXCPxxxx variables (i.e., both SMF30TEP and SMF30BLK values) for   
     DB2 I/O.  The variables had very large values.  The APAR text      
     reads:  "ICYSTOR will now clear the count field, and ICYPFCP will  
     be changed to put the blocks per track into the SMF count field.   
     The VSAM Media Manager does all I/O for Linear Datasets.  Most DB2 
     Tablespaces reside on Media Manager controlled linear data sets.   
     The DBM1 Address Space calls the VSAM Media Manager to perform     
     these asynchronous database I/O operations." and comments that the 
     problem was reported with both DB2 3.1 and DB2 4.1.  This is the   
     first printed reference I have seen that confirms that DB2 I/O is  
     captured in type 30 records; with the APAR, it appears the count is
     not only captured but also is now accurate! ASCBIOSC is the field  
     that is updated by SMFIOCNT service that was corrected by the APAR.
     No MXG Change was required; this APAR only corrected the value that
     IBM wrote in the record, and MXG was already prepared for the full 
     four byte positive value.                                          
 3.  APAR OW17491 corrects TYPE21 variable TAPCUSER (Tape Unit Serial,  
     which identifies which unit created the tape, and can be quite     
     helpful in tracking the source of tape errors).  The problem was   
     caused by DF/SMS 1.3 which inserted a macro call that used Register
     zero (which had already been used by IFG0194F to store TAPCUSER).  
 4.  APAR OW17121 reports incorrect values for TYPE6 variables JOB,     
     READTIME, and LOCLINFO for type 6 records created by PSF for APPC  
     transaction initiators running under JES2 and printed on the same  
     JES2 node; the record contains values for the APPC transaction     
     initiator instead of the transaction itself.                       
 5.  APAR OW17469 reports excessive count of type 80 SMF records after  
     MVS/ESA 5.1 if commands are issued by STCs (e.g., for each START   
     INIT command issued by JES2, an SMF80 event type 1 qualifier 25    
     record is created).  This fix is in addition to APAR OW14521.      
 6.  APAR OW18822 corrects the invalid JESNR in type 26 SMF records that
     was fixed by MXG in Change 13.263.  The APAR will make the 4-digit 
     field zeroes is the JES number is over 9999, but the MXG change has
     already corrected the value of JESNR in MXG, so MXG does not need  
     this APAR to be installed.                                         
 7.  ISPF Find and Change commands use the equal sign as a wild card in 
     a picture clause.  To find strings starting with ABC that have X   
     in the 6th position,  FIND  P'ABC==X'  is the valid syntax.        
     And Picture clauses can be used in Change commands.  To blank      
     columns 73 80 for all non-excluded lines you can use               
     CHANGE  P'=' ' ' 73 80 ALL NX                                      
 8.  Hitachi 9021 Skyline Processors trash TYPE73 (Channel Path Busy)   
     until you install HDS Microcode Fix EC SCTC943.                    
 9.  APAR OW19482 corrects variable TTRN in dataset TYPE1415 so that it 
     counts total tracks for striped datasets.  Without this APAR, the  
     TTRN contains only the tracks used in the first stripe.            
10.  APAR OW03645 reports extremely high disconnect time in type 74     
     RMF records for 9345 and 9394 devices behind 3990-6 with EC C88981H
     or higher.                                                         
11.  CA's CA-SPOOL Release 1.8 creates massive numbers of type 6 SMF    
     records that have nothing to do with printing; instead, they are   
     written when data is moved from the JES2 spool to the CA-SPOOL     
     spool, and CA support indicates they should not have been written. 
     CA APAR GS98190 dated 31May96 will suppress creation of these      
     "spurious" type 6 records.  These records all have the JOB name of 
     the CA-SPOOL address space, but there is no generic flag by which  
     MXG can identify these spurious records.  I have suggested to CA   
     that if they would set a unique identifier in these type 6 records,
     (as they do for EXD and SAR type 6 records), and make the records  
     optional, they might be useful to measure CA-SPOOL's internal      
     performance, but their volume is so large that not writing makes   
     more sense, at least until they can be separated from "real" 6's.  
     Note that actual printing done by CA-SPOOL is separately recorded  
     in their user SMF record, supported by MXG member TYPECMA.         
12.  APAR OW01699 corrects TYPE72MN (type 72 subtype 2 - RMF Monitor II)
     swap counts which were out of order, fixes R722LSEF(which was      
     always zero), and corrects ESCON bits in SMF72PRF.                 
13.  APAR OW20318 corrects TYPE42TO (type 42 subtype 1) variable DURATM;
     for PDSE and VSAM/Record Level Sharing IBM put out Timer Units     
     rather than seconds until you install this APAR.                   
14.  Note 14 was a duplicate of note 6.                                 
15.  CPUTM in interval type 30s does not match step type 30s, because   
     the CPITCTBM/CPISRBTM times (the "initiator TCB and SRB CPU time") 
     are step-level measurements, and are always zero in the interval   
     records.  These "initiator" buckets record the CPU time used by the
     step before the program starts or after the program ends (the other
     five CPU fields in all SMF type 30s and in RMF type 72s record the 
     CPU time used between program start and program end)               
        It would really have been useful if IBM had provided separate   
        buckets for the "before" values and the "after" values, since   
        then we could assign the "initiator" times to correct shift and 
        time-of-day and include them in interval summaries, but all we  
        have now is the lumped "initiator" CPU time in the step record. 
     These "initiator" CPI CPU time values can be significant.  They are
     the CPU time spent by the step between its initiation and its      
     program load (this includes data set enqueue in the first step, and
     it especially includes the cost of allocation of each DD in the    
     step - here is where the CPU time to execute your SMS allocation   
     rules is recorded), and the CPU time spent by the step between its 
     program end and when its SMF type 30 subtype 4 is written (which   
     includes DDCONS CPU time, see above, and the time to create the    
     type 30 subtype 3 and 4 records).                                  
     Thus if you match the interval data to the step data you will find 
     more CPUTM in the steps than in the intervals, because CPITCBTM and
     CPISRBTM are not in CPUTM in the interval data.                    
        However, this is true only if there is a step termination record
        for each step that had interval records.  Even if you IPL-to-IPL
        there will be some started tasks that were never "taken down"   
        and thus had no step termination records, but had many interval 
        records written, so there the sum of the interval records, while
        still missing the "initiator" times, will be greater than the   
        step records.  It is even worse if you just read a day's SMF    
        data and try to compare the steps data to the interval data:    
        you'll have step records today whose interval records were in   
        yesterday's SMF file, and you'll have interval records today    
        for tasks won't end until tomorrow, and match is impossible!    
     If you are using only the interval records for billing, you are    
     missing the "initiator" CPU time that was used, and you should     
     consider billing off of the sum of the interval data plus the      
     initiator CPU times from the step records.                         
     This note added to ADOC30.  Written Jun 15, 1996.                  
16.  APAR OW18543 corrects blank values for Service Class and Report    
     Class in type 30 records with MVS/ESA 5.2.                         
17.  APAR OW20904 (negative disconnect time or zero disconnect time     
     calculated from CMB values in type 74, the "core-clobber" problem) 
     has been solved in child APAR OW22093.  RMF will now move a copy   
     of the CMB (Channel Measurement Block) into local storage and then 
     build the type 74 records.  Previously, RMF would move one entry   
     at a time, and CMB updates between individual loads caused the     
     error.  The fix also check sample count before and after copying   
     of the CMB to validate that it had not changed during copy.  This  
     note was revised October 3, 1996.                                  
18.  Your SMF dump job will run lots faster and use less resources if   
     you disregard the old recommendations in the SMF manual and provide
     plenty of buffer space.  Although MXG recommends the use of half   
     track CISIZE for SMF (see "Impact of VSAM CI Size..." in Newsletter
     25), benchmarks were run at a site which had an SMF CISIZE of 16K  
     (16384) on a 3390; using BUFND=46 on the INDD DD statement of the  
     IFASMFDP program, the run time was HALF of the time with default   
       BUFND  (Bufferspace) Wall Time         CPU Time      EXCP Count  
          2      23768       5 minutes      6.98 seconds      41892     
          5      81720       4 minutes      5.67 seconds      32857     
         46     753665      2.5 minutes     4.68 seconds      24609     
         92    1507330      2.5 minutes     4.70 seconds      24609     
     The SMF default is 2 buffers (horrible); the SMF manual's very old 
     suggestion of using BUFSPACE=81720 (wow, 10*8172!) is better, but  
     clearly using the VSAM rule of thumb for sequential I/O, "set BUFND
     equal to the number of Control Intervals that fit in one Control   
     Area, plus one" is clearly superior.  Note also that the "rule of  
     thumb" appears to be optimal; doubling BUFND to 92 provided no     
     improvement from the "CIs in a CA + 1".                            
     With SMF CA size of one cyl and SMF CISIZE of 16384 (16K),three    
     CI's fit on one 3390 track so you would need 3*15+1=46 buffers for 
     BUFFERSPACE=753664.  With half-track CISIZE of 26624, you would    
     need 2*15+1=30 buffers for BUFFERSPACE=825344.                     
     You can specify AMP=('BUFND=46') (16K) or AMP=('BUFND=31') (26K) on
     your INDD statement in your JCL for IFASMFDP dump program to       
     significantly speed up the process.  Alternatively, you can specify
     BUFFERSPACE=753664 or BUFFERSPACE=825344 when you define your SMF  
     VSAM data set.  Note that BUFND can be specified thru JCL (i.e., if
     you use a DD statement to statically allocate the SMF VSAM dataset 
     in your dump job), but if instead you dynamically allocate your    
     IFASMFDP input file, then only BUFFERSPACE is available for you to 
     increase, and BUFFERSPACE can only be set when the VSAM dataset is 
     created - it cannot be altered after the fact.                     
     What about the memory requirements?  True, the virtual storage size
     is increased, but by less than 1MB, but the real storage occupied  
     (as measured in pageseconds in the type 30 record) shows that less 
     real storage is used with 46 buffers than with the SMF default; the
     larger bufferspace takes less real memory because the I/O is done  
     quicker and those memory pages are made available sooner to some   
     other task:                                                        
          BUFND      AVGWKSET   PAGESECS                                
            2          1173       1002                                  
            5          1220        823                                  
           10          1185        663                                  
           15          1204        640                                  
           30          1415        728                                  
           46          1639        802                                  
           92          1674        845                                  
     Once again, moving lots of data per I/O saves time, CPU, and real  
     memory!  Large bufferspace for either VSAM or BSAM/QSAM is goodness
     for sequential access.                                             
19.  Boole & Babbage's Cache RMF Reporter (user SMF record) is wrong.   
     In their record, they store the REPORLVL=1.6, but the format of    
     the record is from IBM's Release 1.5.  Since MXG believed the      
     value and expected the 1.5 format, many variables have strange     
     values.  Boole is working on PTF BPM5835 to correct their error.   
20.  APAR OW20844 increases the maximum allowable value for job numbers 
     from 32787 to 65534.  There is no impact on MXG, as it already will
     handle these larger values in variable JESNR.  However, the SMF    
     records created by Software Engineering of America's $AVRS and by  
     Xerox's XPSM do not yet even support JESNR's greater than 9999, as 
     they have only a 4-byte numeric field for JESNR.                   
21.  Experiments with BUFNO for Sequential Access (BSAM,QSAM), including
     that rare experiment of RTFM (Reading The Fine Manual), discovered 
     that unstriped SAM is limited to transfer of 240K bytes per I/O,   
     and is also limited to a maximum of 30 buffers.  Thus the maximum  
     number of SAM buffers (BUFNO=) should be                           
                    MIN ( 30 , 240K/BLKSIZE) ;                          
     The above is true for most sequential datasets but NOT for extended
     sequential datasets.  Even with a stripe value of 1, more data can 
     be read with a single IO than with an ordinary sequential dataset. 
     This does not necessarily mean faster, it just means more data is  
     moved. Whether faster or not depends on the buffers.               
     The algorithm for building the minimum size of the channel program 
     for extended datasets with half-track blocks (1 slice = 1 track) is
       IF BUFNO LE 1 slice  then amount = BUFNO*BLKSIZE                 
       IF BUFNO LT 2 slices then amount = 1 slice                       
       IF BUFNO LT 5 slices then amount = min(bufno/2)                  
       IF BUFNO GE 5 slices then amount = 5 slices                      
     This yields slightly more than the 240K MAX for normal QSAM (272K  
     for an 80-byte records blocked at 27920.) The default buffers for  
     an extended sequential dataset can be calculated as:               
       2*blocks per track*number of stripes                             
     Thus with 8 stripes of half-track blocks 32 buffers is the default.
     Just like regular QSAM, these buffers live on low memory unless you
     add a DCBE with RMODE31=BUFF and run as RMODE 31.                  
     Data striping can yield significant savings in elapsed time.       
     In one experiment reading a 2.3GB SMF dataset the results were:    
        Device             Elapsed    Connect   CPU    MB/Sec           
        6390 - parallel    0:19:15      09:22   18.1    1.85            
        6390 - ESCON       0:07:58      03:58   18.2    4.47            
        6390 - 8 stripes   0:01:27      04:49   18.4   26.47            
     Data striping is enabled by using both a data and a storage class. 
     The storage class defines the Sustained Data Rate (SDR) desired for
     the storage class (in this case a rate of 32MB/sec was used) and   
     the data class defines the maximum number of stripes that can be   
     allocated for that data class.  Using the SDR and the maximum      
     number of stripes, SMS calculates the number of stripes to use on  
     3390 devices as SDR/4.                                             
22.  APAR PN87013 (open) reports TCP/IP TELNET LOGN SMF records are not 
     always written if DEFAULTAPPL parameter is specified.              
23.  APAR OW20823 for RACF type 80 record corrects missing data in the  
     relocate section data type 44 (x'2C') that occurred in certain     
     circumstances described in the APAR text.                          
24.  CA's CA-1 (TMS) product APAR G081058 for CA1 5.1 (on 9604 tape)    
     will eliminate the IEC507D messages (and the required operator     
     reply!) that were introduced with 5.1 whenever multiple datasets   
     are created on one tape.  Previously, CA-1 hooked MVS/DFP code to  
     suppress the issuance of that WTOR (Write to Operator with Reply)  
     but in release 5.1, CA1 no longer puts hooks via PDZAP; instead,   
     the hooks are dynamically front-ended via other CA services.  This 
     APAR corrects their oversight in their new release.  MXG's MONTHBLD
     and WEEKBLD are examples of SAS jobs that create multiple datasets 
     per tape and exposed this CA-1 error.                              
25.  APAR OW20956 acknowledges that TYPE1415 variable TRKSALOC is not   
     valid for PDSE datasets (it always contains one) and that in a     
     future PDSE release, the correct number of tracks will be returned.
26.  APAR OW21083 fixes large values in CPUUNITS and SERVICE variables  
     (SMF30CSU,SMF30SRV) in TYPE30_V subtype 3 interval records for DB2 
     4.1 DDF address space.  IBM's APAR reports "negative" values, but  
     MXG inputs these variables as PIB (Positive Integer Binary) and the
     IBM "negative" values have first bits on, causing large positive   
     values in MXG datasets (and that is intentional, so that a large   
     value slaps you in the face, whereas the small negative value might
     be overlooked if MXG had INPUT with IB instead of PIB).            
27.  Several sites with MVS/ESA 5.2.2 have noticed negative values for  
     the calculated Channel Pending time in TYPE74 data.  One specific  
     device's interval of 556.13 seconds duration with 155 SSCHs shows  
     Active Time (SMF74ATV/DEVACTTM) of 1.12 seconds and its components 
     Pending Time (SMF74PEN/DEVPNDTM) 0.07 seconds, Disconnect Time     
     (SMF74DIS/DEVDISTM) 0.76 seconds, and Connect Time                 
     (SMF74CNN/DEVCONTM) 0.29 which do add to 1.12 seconds.  However,   
     the Pend for Device (SMF74DVB/DLYDEVTM) is 1.94 seconds, while     
     Pend for CU (SMF74CUB/DLYCUBTM) and Pend for Dir Port (SMF74DPB,   
     DLYDIRTM) are both zero.  The Pend for Channel is calculated by    
     subtracting the Pend Components from Pend: PEN-(DVB+CUB+DPB), but  
     with DVB value greater than PEN, the calculation is negative. How  
     can Pend for Device be greater than total Pend time?  How can Pend 
     for Device be greater than Device Active Time?  Awaiting IBM reply.
28.  To create SMFINTRV (TYPE30_V) globally synchronized, you must      
     specify INTVAL(15), SYNCVAL(15), and SYS(EXITS(INTERVAL(SMF,SYNC)) 
     in SMFPRMxx member of SYS1.PARMLIB (for 15 min. in this example)   
29.  APAR OW19074 corrects three distinct RMF errors in which RMF itself
     goes down with ABENDU1204 in ERBSMF1QB, ABENDC0D RC2A000201 in     
     LOGREC or ABEND0C4 RC10 in ERBFME0Q plus ABEND0FE in ERBMFEVT.     
30.  APAR OW22119 for DCOLLECT record type 'VL' corrects SMS system     
     status, MVS System status, and Confirmed SMS status.               
IV.   DB2 Technical Notes.                                              
 1.  DB2 will now record its media manager VSAM I/O counts in the EXCP  
     buckets in the type 30 record.  This enhancement was contained in  
     DB2 Version 4.1, but has now been retrofitted back into DB2 V3 by  
     APAR PN76648.  With V3+APAR or V4, you must specify SMFIO=YES on   
     the MMSRV CONNECT request and be at DFSMS 1.1 or above.  IBM notes 
     "do NOT be alarmed if you see the DBM1 ASID with EXCP counts that  
     range into the 'millions'."!                                       
V.    IMS Technical Notes.                                              
 1.  One site using Candle's ITRF reports their experiences:            
     They were unable to process ITRF records written to SMF because the
     Candle extractor program generated OTR037 INPUT LOG SEQUENCE ERROR 
     and after several iterations with Candle tech support (who thought 
     the data records needed to be sorted) the error remained until     
     further information from Candle indicated they strongly recommend  
     writing to the IMS log instead of SMF.                             
     Switching to writing to the IMS log, they found they have to run   
     a separate Candle extractor job for each IMS region, but they can  
     then combine the three output files into a single input for the    
     MXG processing.                                                    
     They have observed that for transactions running at the time of    
     OLDS switch, the response time is garbage (119,302+ hours!).       
     Candle is still working on that open problem.                      
 2.  IMS FASTPATH DEBD I/O counts via the VSAM Media Manager are now    
     recorded in the EXCP buckets in the type 30 for IMS with APAR      
VI.   SAS Technical Notes.                                              
 1.  SAS USER ABEND 0315 (physical I/O error to a SAS data library)     
     occurs if your SMS Management Class specifies the RELEASE option.  
     SAS re-opens its data library for each new SAS dataset in that     
     library, and RELEASE does not work correctly with these multiple   
     opens.  However, if you add the RELEASE parameter to the DD        
     statement for the SAS data library, the ABEND won't occur, because 
     SAS can recognize the explicit RELEASE request and is then smart   
     enough to suppress its multiple opens!                             
 2.  Further to my comments in Newsletter TWENTY-NINE about resources   
     used by PROC SQL, Paul Shipley, Telstra, AUSTRALIA, notes:         
      PROC SQL does seem to consistently use more CPU resources than    
      DATA steps and PROC SORT steps.  While PROC SQL merges quicker and
      can be easier to write (especially with multiple datasets and     
      keys), normally use PROC SQL only:                                
       - where the computer resources are so small it doesn't matter    
       - for one-time jobs where the programmer time savings are worth  
         more than computer resources, or                               
       - for many-to-many joins (such as Cartesian products) which can  
         be coded very easily in PROC SQL and can be very difficult in  
         DATA/SORT step logic.                                          
 3.  USER ABEND 0318 will occur if your site upgrades STOPX37 to Boole &
     Babbage's PROSMS replacement and your installer did not read their 
     instructions to disable PROSMS for PGM=SAS.  Just like STOPX37,    
     PROSMS tries to protect for out of space conditions by allocating  
     additional space, but if the additional space is on a different    
     volume, SAS will fail when it tries to use that extra space, as it 
     does not meet the SAS multi-volume requirements.  This can be an   
     erratic ABEND; the job will fail and them may the rerun may succeed
     with no change, depending on where DASD space was found.  The real 
     problem is that your primary space allocation is not large enough, 
     and the job is living on extents.  Increasing the primary Space    
     allocation so that no secondaries are required will circumvent     
     the problem, but you must also disable PROSMS for PGM=SAS to       
     avoid the exposure.                                                
     Update Jan 22, 2001:  Under SAS Versions 7 and 8 it is still true  
     that you must disable STOPX37/PROSMS etc.  You can configure by    
     PROGRAM name (SAS, SASXA1, SASHOST, etc. etc), or from SAS Note    
     001876, "configure the third party product to exclude data sets    
     accessed via EXCP.  SAS uses EXCP processing to access disk format 
     SAS libraries".                                                    
 4.  OUT OF MEMORY conditions were previously discussed in Newsletter   
     TWENTY-EIGHT (Section VI.5), but I was unaware of using REGION=0M  
     to bypass site restrictions in IEASYS.  Specifying REGION=56M on   
     a stress test of an enhanced BUILDPDB failed and IEF374 indicated  
     I could only get 32M of Extended space.  Changing to REGION=0M     
     allowed the job to successfully run (and it needed 53M).  There    
     were site restrictions in effect when a non-zero region was        
     requested, but the REGION=0M bypassed the restriction and permitted
     the job to successfully execute.  Change 14.147 makes REGION=0M    
     the default in MXG JCL examples.                                   
 5.  Under rare circumstances, SAS can enter either a CPU loop or wait  
     loop after trying to read an SMF file with an invalid VBS segment. 
     VBS errors were thought fixed in SAS 6.08 at TS415 by Usage Note   
     V6-SYS.FILE-9321, but this new instance spawned Usage Note fix     
     V6-SYS.FILE-C441, to be available in the first maintenance for     
     SAS 6.09E (tentatively TS455, but no date has been set).  The new  
     problem occurred reading an SMF multi-volume BSAM disk file that   
     contained a broken segment. Only two sites are believed to have    
     experienced the error.  Since one of the best features of SAS has  
     been its ability to detect and correct broken VBS segments, the    
     closure of this exposure is welcome.                               
 6.  Permanent ARRAYs with large numbers of elements (over 4096?) can be
     unbelievably expensive in CPU time, both for the compile of the SAS
     program and for execution, because permanent arrays create real SAS
     variables.  You must use a permanent array if you intend to OUTPUT 
     the variables in the array, but if you are only using the array to 
     hold counters or temporary strings, use _TEMPORARY_ in the ARRAY   
     statement and you can save lots of CPU time.  In fairness, the     
     manual "SAS Language" does state (see ARRAY statement) "You can    
     improve the performance time by using temporary data elements",    
     but I never knew then what I know now!  When Dan Squillace at SAS  
     observed a CPU time jump in BUILDPDB between MXG 13.13 and 14.05   
     (with his 137MB SMF file, CPU jumped from 293 seconds to 485!),    
     Freddie and Bruce ran tests which isolated the jump to MXG 14.04,  
     and I then isolated the CPU delta to Change 14.121, which had added
     two 4096-element arrays to VMAC78 processing.  Using my small (5MB)
     SMF file with TYPE78 and iterated array sizes shows the impact:    
         Array elements:       0    512   1024   2048   4096   4096-Temp
         TYPE78 CPU sec:       7      8     10     14     24      7     
     for small array sizes, permanent arrays are not expensive, but with
     4096 elements, the CPU cost jumped from 7 to 24 seconds, so using  
     permanent arrays indeed can be expensive.  Further tests using my  
     small 5MB SMF file to compare permanent with temporary showed:     
                                    4096-Perm   4096-Temp    Increase   
         BUILDPDB Compile seconds      98           148        +50      
          my 5MB  Read/Write secs       9            23        +14      
                  Total CPU  secs     107           171        +64      
     BUILDPDB, a 60,000+ line SAS program with 14,694 variables suffered
     a +50 second increase in the CPU time in the Compile phase alone,  
     when the two ARRAY statements with 4096 permanent variables were   
     added, but it was not the ARRAY statement itself that caused the   
     increase; rather, it was the creation of 8,172 more SAS variables  
     that increased the CPU time, with or without an ARRAY statement!   
     And these new 8,172 variables have to be inserted into the middle  
     of the "Program Data Vector" which has one entry per variable,     
     causing it to expand, which increases CPU time because variables   
     that previously were adjacent now span addressable units (MVS      
     registers limit SAS to about 40K at a time) so more loads,         
     branches, etc., are necessary.  That's why the compile time jumped!
     But I observed also that the simple existence of these 8,172       
     variables also increased (from 9 to 23 seconds) the CPU time just  
     to read the 5MB SMF file and create //WORK datasets.  Some of this 
     increase is also loading time to manage the larger "Program Data   
     Vector", but also, as SAS documents, the ARRAY statement is        
     culpable because all variables in permanent arrays are set to be   
     missing with each new record processed (whether or not the block of
     code referencing the array was executed for this SMF record),      
     whereas temporary arrays are automatically retained.               
     So there is both a per-compile CPU cost and a per-record CPU cost  
     when 8,172 variables are added to BUILDPDB and permanent variables 
     are used in an ARRAY statement.  Using _TEMPORARY_ instead, in the 
     ARRAY statement, where possible, can save a lot of CPU time!       
     Fortunately, MXG ARRAYs in data step code have only a few elements 
     (mostly 16 or 64).  While a few ARRAYs in reporting programs have  
     999 elements, those programs have only hundreds of variables.      
     Addressability of the data vector only becomes a performance issue 
     for large programs with tens of thousands of variables.  So I do   
     not expect any other big paybacks in using temporary rather than   
     permanent arrays, but over time I intend to replace all permanent  
     ARRAYs that I can with temporary ARRAYs, mostly because it is the  
     righteous thing to do. Only when variables in the array must be    
     kept in SAS datasets, will the array be permanent.  Change 14.166  
     shows the syntax changes to make permanent temporary.              
 7.  SAS 6.09E Maintenance TS450 has no reported problems with MXG, nor 
     should it, since SAS Institute now executes MXG Software as a part 
     of their Quality Assurance test stream!  Only one impacting error  
     was not repaired in TS450; (usage note V6-SYS-FILE-C441, broken VBS
     record, see above) that is to be fixed in TS455.  Tests with       
     BUILDPDB under TS450 show no noticeable change in CPU resources    
     when compared with SAS 6.09 TS425.                                 
VII.  CICS Technical Notes.                                             
 1. CICS data volume reduction with EXCLUDE, CICS Blocksize, etc.       
     The physical amount of data created by CICS can be reduced by      
     telling CICS to "exclude fields" from the transaction segments in  
     DFHMCT.  The default transaction segment in CICS 4.1.0 is 572 bytes
     long and contains 107 fields, so a maximum of about 56 transactions
     fit in one physical 32K byte SMF record.                           
     Your CICS type 110 records will still be about the same length, but
     there will be fewer total records.  Reducing the segment size by   
     excluding fields does reduce the volume of data that is written to 
     SMF and that will definitely reduce the MXG run time (which is     
     mostly driven by data bytes, not record count).                    
     A maximum type 110 record size of 6000 bytes is not good, because  
     CICS has to stop every 6000 bytes to hand over a record to the SMF 
     writer's address space, instead of sending 32K bytes per record.   
     It takes 5 SVCs at 6K to transfer the same data that takes only one
     SVC at 32K, so CICS has to interrupt itself five times as often    
     with that smaller buffer size in CICS.  A larger buffer size in    
     CICS will also reduce the number of I/Os necessary for the SMF     
     writer to write, the SMF dump program to read and write, and for   
     any SMF-processing program to read, and will reduce run time of    
     those programs as well!  (For CICS 2.1 transactions, the default   
     segment was only 320 bytes and only 61 fields.)                    
     To process "Excluded" SMF records in MXG, exits already exist for  
     your tailoring.  In member IMACEXCL, you comment out the fields    
     that you have excluded in your DFHMCT and thus cause MXG to not    
     INPUT those excluded fields (instructions are in comments in       
     member IMACEXCL).                                                  
     Then in member IMACCICS, in the _KCICTRN macro definition, you     
     use the DROP= A B C ...  syntax to drop those variables from the   
     CICSTRAN dataset, thereby reducing the size of the CICSTRAN data   
     set (see text of Change 10.175 in member CHANGESS for "_K" macro   
     usage instructions).                                               
     In CICS chargeback, the CPU time recorded in the CICSTRAN          
     transaction observation is often less than half of the CPU time    
     actually used (which is captured in the region's type 30 SMF record
     and in the type 72 for the CICS performance group (or service class
     in WLM mode).                                                      
     That uncaptured CPU time comes from two sources:                   
       - CPU time spend in DB2 on behalf of transactions in this CICS   
         region, because that CPU time is not captured in the           
         transaction segment, but is included in the type 30 and the    
         type 72 data.                                                  
       - A fixed CPU time per transaction to start and stop the         
         transaction, no matter what the transaction eventually does.   
     The DB2-caused CPU time is captured in the DB2 type 101 SMF        
     record which becomes the DB2ACCT dataset in MXG, so you could get  
     a good estimate of that fixed-per-transaction cost by calculating  
      fixed           (CPU TIME from 30) - (CPU time from 101s)         
      per        =   _____________________________________________      
      transaction        (Number of Transactions from type 110)         
     You might want to schedule a startup and shutdown of CICS with no  
     work and look at its type 30 CPU time and subtract that cost from  
     the numerator if it is significant.  My paper in the CMG 1993      
     Transactions "MVS/ESA Resource Accounting" which is also in member 
     NEWSLTRS of the MXG Source Library, has further discussions, and it
     has been updated to document "Z/OS Resource Accounting".           
 2. Support for Landmark's TMON for CICS/ESA 1.3.                       
    Raw data still must be converted when Landmark's Dump program is    
    executed, as noted in comments in TYPETMON.  Landmark has never     
    released the internal format of their records, and I have corrected 
    old comments that implied MXG could read their native records - it  
    MXG 13.06+ support for TMON 1.3 is in member TYPETMON, but that new 
    MXG support requires the MONICICS (input) file to have RECFM=VB in  
    the DCB.  See text of Change 13.204.                                
    MXG 12.12A and MXG 13.01 thru MXG 13.05 supported TMON 1.3 with     
    their member TYPETMON, but required RECFM=U for MONICICS.           
    See Change 12.320.                                                  
    MXG 12.12 did not correctly support TMON 1.3, but the post-shipment 
    "Flash" letter sent in March, 1995, announced that MXG 12.12A did.  
 3. APAR PN79698 closes a problem with TASCPUTM (IBM's USRCPUT) field   
    being zero because an ISV DASD manager (unnamed) was issuing STIMER 
    REAL requests which were canceling the CICS STIMER (and the CICS    
    STIMER is needed to record the task CPU times!                      
 4. Beginning with CICS/ESA 4.1, IBM creates a CICSTRAN observation when
    an undefined transaction ID (TRANNAME) was typed in by the CICS     
    user.  Variable TRANNAME contains whatever was typed in, and the    
    PROGRAM variable contains '########'.  (With CICS/ESA 4.1 and DTR,  
    Dynamic Transaction Routing, you no longer have to define all of    
    your tran names in the TOR).  IBM now acknowledges in APAR PN70976  
       "CICS issues an attach for the transaction, and then attempts to 
       route the transaction, passing the transid specified on the      
       DTRTRAN SIT parameter (or CRTX, the default).  The monitoring    
       record will contain the name of the program associated with the  
       routing transaction in the field TMRPGMN.  If DTRTRAN has not    
       been specified, TMRPGMN will contain "########", which is the    
       program name of the definition of CRXT, the default DTRTRAN      
    PTF UN79168 creates a new CICS value 'NO' for the CICS SIT parameter
    DTRTRAN which causes:                                               
       "Dynamic Transaction Routing to not be initiated if an undefined 
       transaction ID is entered; instead, the CSAC transaction will be 
       attached, and a monitoring record will be written for this       
    so the PTF does not eliminate the undefined transaction record, but 
    rather changes it to be a TRANNAME=CSAC transaction.  Without the   
    PTF, it would be wise for you to either delete these transactions   
    with PROGRAM='########' from your CICS reports (your CICS users will
    disbelieve reports with trashed TRANNAME values), or separately     
    count them as Undefined.  With the PTF, you will only see more CSAC 
    transactions and will never know what four letter combinations were 
    typed in by sloppy (lots) or disgruntled (a few) CICS terminal      
    operators.  About 350 undefined transactions were seen out of       
    several million CICS transactions in one day at one site.           
VIII. Incompatibilities and Installation of MXG 14.07.                  
 1. Incompatibilities introduced in MXG 14.07 (since MXG 13.13):        
  a- IMACs that were changed (if they exist in your USERID.SOURCLIB, you
     must refit your tailoring, starting with the new IMAC member):     
  b- Other incompatibility changes:                                     
       Dataset TYPE116 (MQM) variable QWHCATYP replaced by QWHCXTYP.    
       Dataset CACHE90 from VMACACHE now TYPE74CA from VMAC74. CH14.152.
  c- These products were incompatibly changed by their vendor, and they 
     require MXG 14.xx as indicated:                                    
       See products listed as INCOMPATIBLE in Section I, above.         
 2. Installation and re-installation procedures are described in detail;
    in member INSTALL (which also lists common Error/Warning messages a 
    new user might encounter), and sample JCL is in member JCLINSTL:    
     a. Install member MXGSAS as JCL Procedure MXGSAS in your PROCLIB.  
     b. Allocate a 105-cyl PDS: MXG.V1407.MXG.SOURCLIB, and use IEBUPDTE
        to read the MXG tape to create the 2955+ member Source Library. 
     c. Allocate a 1-cyl PDS:  MXG.V1407.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 V1407.USERID.SOURCLIB.                      
     d. Allocate a 1-cyl SAS Data Library:  MXG.V1407.MXG.FORMATS and   
        execute SAS to create the library of Formats required by MXG.   
     e. If this is the initial install of MXG, tailor these members into
        your MXG.V1407.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. If re-installing MXG, copy your existing USERID.SOURCLIB library
        members into the MXG.V1407.USERID.SOURCLIB.  Then, compare the  
        members in your USERID.SOURCLIB with the list of members that   
        were incompatibly changed (above, in this section) in this MXG. 
        If any of the incompatibly changed members exist in your dataset
        MXG.V1407.USERID.SOURCLIB, then you must reinstall your site's  
        tailoring for that IMAC, starting with the IMAC member from the 
        MXG 14.07 Source Library.                                       
     f. EDIT and submit member JCLTEST6 to verify that your tailoring   
        did not create any errors.                                      
     g. EDIT and submit JCLPDB6 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 14.07 in its own set of libraries. When 
     parallel testing is complete and are ready to implement MXG 14.06  
     in production, rename your three current MXG Production Libraries  
     and rename the MXG.V1407.x.y libraries to their Production names!  
     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:", "ERROR :", " NOT " 
"APPARENT", and "NOT CATLGD", as they usually 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.   
IX.   Online Documentation of MXG Software.                             
Since 1994, the contents of the two MXG Books, (the 1984 MXG Guide, and 
the 1987 MXG Supplement) are contained in the MXG Source Library, as are
all MXG Technical Newsletters and all MXG Changes, so all MXG           
documentation is actually online in the software itself; even the       
Installation Instructions are online, in members INSTALL/JCLINSTL!      
ACHAPxxx members are the text of the 42 chapters from the two MXG books,
to which the text from newsletters and changes has been added.  Some of 
these chapters are still rough; while some of the chapters have actually
been completely revised, many of these ACHAPxxx are little more than a  
concatenation of the two original chapters, often without the figures   
or tables.  The revision is work still in progress!                     
Members ADOCxxxx are what were in Chapter FORTY, and should be the first
place you look for information about MXG variables and/or datasets.  The
ADOCxxxx members alphabetically describe each dataset and all variables 
that are created by product xxxx, the instructions on how to enable that
product, bibliography of the vendor documentation, sample PROC PRINT and
PROC MEANS of real data, references to MXG reports that use these data, 
and the MXG member names that you use to process that product.  While   
this too is work in progress, the most heavily used data sources,       
especially the common SMF records, have been revised and are up to date.
There is 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, because of MXG naming conventions: 
  IMACxxxx - Defines record IDs, and the _Lyyyzzz and _Kyyyzzz macros   
             that name the dataset(s) created from product xxxx.        
  ADOCxxxx - "Chapter FORTY" style dataset and variable documentation of
             all datasets created from product xxxx, with sample output.
  VMACxxxx - The "real" source code member, often extensively commented.
  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 tailoring of each MXG dataset, not used by 
             most MXG sites, but powerful if needed.  There can be more 
             than one dataset created from one product.  The yyyzzz     
             suffix of the EXyyyzzz member name is the same as the      
             suffix of "_L" and "_K" macros defined in the IMACxxxx for 
             its product. See Using the MXG Exit Facilities in ACHAP33. 
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 or CHANGESS 
for the xxxx suffix.                                                    
Member CHANGES identifies this Version and Release of MXG Software, and 
describes all changes made in this Release, plus new technical notes.   
Member CHANGESS contains each of the CHANGES members from each version  
of MXG, so this member contains ALL changes ever made to MXG Software.  
Since each MXG change lists the names of the members that were added or 
altered, names the new product/version supported by a change, or lists  
error messages corrected by a change, this member is designed to be read
online (with SPF BROWSE); you can search for specific product acronyms  
(CICS, MVS/ESA, etc.), or the MXG member name or anything else.  Many of
the changes are actually mini-tutorials, especially for new products.   
Member NEWSLTRS contains the text of all newsletters.  You can search   
NEWSLTRS for product name or acronym to find all of Dr. Merrill's       
published and unpublished technical papers, technical notes announcing  
enhancements in new operating systems or subsystems, new datasets and   
products, important APARs and PTFs, and other technical information of  
importance to MXG users.  (Since the Change Log that is printed in each 
newsletter is in member CHANGESS, it is not repeated in NEWSLTRS.) MXG  
Technical Newsletters are typically published twice a year, with one    
printed copy sent to each licensed site's technical addressee.          
Member DOCVER lists alphabetically ALL datasets and variables that are  
built by this MXG Software Version, abbreviated to a line per variable. 
Members DOCVERnn are the "delta-documentation" between MXG versions, and
list only those datasets and variables that were added/deleted/changed  
by version "nn", so you can identify when a variable/dataset was added. 
Finally, remember that MXG is source code, and you can often find your  
answer by BROWSING the source members, especially the VMACxxxx members. 
The MXG Variable name is frequently the vendor's field name, or the     
vendor's field name is often in a comment adjacent to the variable's    
INPUT, so you can cross reference MXG to the vendor's documentation.    
The migration from print to online is clearly work in progress, but at  
least the two books are now machine-readable!  When all 42 chapters     
are completely revised and updated in the source library, I will decide 
which, if any, will also be made available in printed form, but the     
primary media for all future MXG documentation will be these members of 
the MXG source library, which can be immediately updated in each new    
version of MXG as changes occur.                                        
X.    Changes Log                                                       
--------------------------Changes Log---------------------------------  
 You MUST read each Change description to determine if a Change will    
 impact your site. All changes have been made in this MXG Library.      
 Member CHANGES of the MXG SOURCLIB will always be more accurate than   
 the printed changes in a Newsletter, because the software tapes are    
 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 than 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.                     
Alphabetical list of important changes after MXG 13.13:                 
  Member   Change    Description                                        
  all      14.019  Support for OS/390 Release 1.0 already in MXG 13.13! 
  many     14.158  Support for OS/390 Release 2.0 tolerate by MXG 13.13!
  ANALCNCR 14.162  FILE WORK.SPLIT DOES NOT EXIST corrected.            
  ANALCNCR 14.175  Specifying both output dataset and reports failed.   
  ANALDB2R 14.022  DB2 report PMAUD03, if PDB is on tape, will fail.    
  ANALDB2R 14.073  VARIABLE QWHSIID NOT FOUND corrected in DB2 reports. 
  ANALDSET 14.064  Using Tape instead of DASD for ANALDSET fails.       
  ANALSMF  14.178  SMF Simulator now tests a CISIZE of 18432 for 3390s. 
  ASMIMSL5 14.129  Support for IMS 5.1 APAR PN76410 (INCOMPATIBLE)      
  ASMIMSLG 14.148  SLOTS table moved above the 16MB line.               
  ASMTAPES 14.037  MAINTLEV 8 of MXG Tape Mount and Allocation Monitor. 
  ASMTAPES 14.086  MAINTLEV 9, monitor does not stop, new TMNT013I.     
  ASMVTOC  14.003  Archaic assembly member was wrong on MXG 13.13       
  ASUMAPAF 14.062  SORT ORDER error if you increase number of domains.  
  BUILDPD3 14.169  JES3 type 25 MDS Tape Mounts/Fetches in BUILDPD3.    
  BUILDPDB 14.185  VM Print sent to JES2 is now merged in PDB.JOBS.     
  CICINTRV 14.188  Old CICINTRV replaced CICINTRZ, fixed for CICS 4.1.  
  DIFFDB2  14.167  DB2 4.1 DB2STATS interval missing due to QWHSISEQ.   
  DIFFDB2  14.194  Extra obs in DB2STATB/DB2STATR, negative SEQCHECK.   
  IHDRDCOL 14.027  First of new "IHDRyyyy" - "INFILE header" exits.     
  IMAC6ESS 14.036  Decoding of SMF type 6 ESS segment is added.         
  IMACEXCL 14.024  CICS Excluded Field support enhanced for multiples.  
  IMACICOC 14.123  Omegamon for CICS OMSUPRTM/OMDCOMTM incorrect.       
  JCLADHOC 14.140  New example for ad hoc job to select specific data.  
  JCLTMON  14.012  Example JCL for Landmark's The Monitor for CICS.     
  JCLall   14.147  All MXG JCL examples now specify REGION=0M.          
  MONTHBLD 14.010  NOTSORTED error with ASUMCICS in monthly logic.      
  MXGSAS   14.140  Revised MXGSAS JCL procedure adds TAILORNG= parm.    
  TRNDTALO 14.130  INVALID DO LOOP error if ALOCSTRT=. or ALOCEND=.;    
  TRNDTALO 14.176  Redesign of TRNDTALO to "SPIN" active allocations.   
  TYPE102  14.047  DB2 Trace T102S096 vars QW0096SN,SC,SK corrected.    
  TYPE102  14.138  New datasets with all SQL text added for DB2 trace.  
  TYPE102  14.206  Dataset T102S231 corrected.                          
  TYPE110  14.089  Support for PN69653 (YYYY digit year in COLLTIME).   
  TYPE110  14.106  Variables MCTMNTAD/SMFPSRVR added to CICSEXCE.       
  TYPE110  14.184  CICSTRAN variable TRANTYPE increased to two bytes.   
  TYPE110  14.209  Support for CICS/ESA 5.1.0 (INCOMPATIBLE).           
  TYPE116  14.087  Variable QWHCATYP was INCOMPATIBLY renamed QWHCXTYP. 
  TYPE16   14.150  Support for DFSORT Release 13 APAR PN71337.          
  TYPE28   14.023  Some NPM VVR (VTAM Virtual Route) variables trashed. 
  TYPE28   14.065  NPM APARs OW08565 and OW10584 for 3746/900 supported.
  TYPE30   14.099  Auto Restart section INPUTs were incorrect.          
  TYPE30   14.172  Variable EXECTM in TYPE30_V wrong if only subtype 3. 
  TYPE42   14.063  DASDMPL 1000 times too large in TYPE42DS.            
  TYPE42   14.131  Support for APAR PN78083 required no change to MXG.  
  TYPE6    14.009  Truncated PSF type 6 record INPUT STATEMENT EXCEEDED 
  TYPE64   14.004  INPUT STATEMENT EXCEEDED, CF Cache Structure segment.
  TYPE7072 14.051  ELAPSTM added to TYPE72GO, and RMFINTRV for WLM.     
  TYPE7072 14.059  TYPE72GO variable VALDSAMP and delay PCTs wrong.     
  TYPE7072 14.180  Variable PERFINDX now created in TYPE72GO.           
  TYPE71   14.058  Support for Shared Page Groups added.                
  TYPE72   14.085  MVS/ESA 5.2.2 variables overlooked in TYPE72GO.      
  TYPE73   14.164  APAR OW15406 for RMF adds support for Year 2000.     
  TYPE74   14.085  MVS/ESA 5.2.2 variables overlooked in TYPE74OM.      
  TYPE74   14.152  Support for type 74 subtype 5 Cache RMF Reporter.    
  TYPE78   14.121  Variable PCTALLBY, LCUIORT added to TYPE78CU dataset.
  TYPE78   14.166  ARRAY statement changed to _TEMPORARY_ to save CPU.  
  TYPE80   14.070  Support for IBM APAR OW19251 (RACF year 2000).       
  TYPE80   14.114  Support for RACF 1.10 (toleration).                  
  TYPE80A  14.170  More RACF Reports for Command Events decoded.        
  TYPE88   14.066  INPUT STATEMENT EXCEEDED corrected.                  
  TYPE89   14.158  Support for Subtype 2 (Measured Usage Product Sumry).
  TYPE99   14.069  TYPE99_2 now has obs for each period vice just first.
  TYPECACH 14.093  Support for IBM's Cache RMF Reporter CRR 1.7         
  TYPECMF  14.033  MXG now recognizes 3990 model 6 in CMF user SMF.     
  TYPEDB2  14.011  DB2 4.1 type 101 subtype 2 INPUT STATEMENT EXCEEDED. 
  TYPEDB2  14.044  Protection for truncated DB2 record.                 
  TYPEDB2  14.071  Dataset DB2STATB now always has observations.        
  TYPEDB2  14.105  QWSDLR length 8, QWSCIID corruption corrected.       
  TYPEDB2  14.174  VMACDB2 ERROR ... QWHSIID=230 UNEXPECTED fixed.      
  TYPEDB2  14.195  DB2STATR, DB2 remote counts, corrected.              
  TYPEDB2  14.208  Datasets DB2GBPST and DB2GBPAT all BP now output.    
  TYPEDMON 14.125  Support for ASTEX 2.1 (INCOMPATIBLE).                
  TYPEF127 14.032  Support for FACOM MSPE/EX PTF 93061 for ID=127 SMF.  
  TYPEFTP  14.054  Support for FTP subtype 51x SMF record.              
  TYPEHIPR 14.015  Hipercache VSAM buffer field wrong in MXG 13.13.     
  TYPEIMS  14.030  Early testing IMS log records for IMS 5.1            
  TYPEM204 14.171  Support for MODEL204 Release 3.2.1 (INCOMPATIBLE).   
  TYPEMOVT 14.168  Support for Omegmaon/VTAM V200 (INCOMPATIBLE).       
  TYPEMWUX 14.134  Support for HP MeasureWare for HP-UX platform.       
  TYPENDM  14.034  NDM or Connect Direct timestamps missing, data wrong.
  TYPENDM  14.116  Support for NDM 1.4 (compatible) adds variables.     
  TYPENOAM 14.057  Support for STK's NearOAM user SMF record.           
  TYPENSPY 14.005  INPUT STATEMENT EXCEEDED, NSPY 4.6, type A, invalid. 
  TYPENSPY 14.111  Support for NETSPY Release 4.7 (compatible).         
  TYPEOPC  14.077  INVALID MTD SUBTYPE, observations not output.        
  TYPEORAC 14.103  Accounting data input incorrectly for ORACLE.        
  TYPEQAPM 14.098  Support for AS/400,OS/400 Release 3.6 (INCOMPATIBLE) 
  TYPERMDS 14.092  Support for IBM's RMDS Version 2.2 (no change)       
  TYPESAMS 14.013  INVALID DATA FOR HH,MM,SS with SAMS SMF record.      
  TYPESFTA 14.179  Support for SoftAudit Version 5.1 (INCOMPATIBLE).    
  TYPESNIF 14.186  Network General's Sniffer Network Monitor data.      
  TYPESTC  14.001  INPUT STATEMENT EXCEED for HSC subtype 8 record.     
  TYPESTC  14.055  STK's HSC Subtype 08 now in two lengths, 38 and 40!  
  TYPESYNC 14.115  Syncsort variables SORTBEGN/END midnight spanning.   
  TYPETLMS 14.014  TLMS year 2000 dates were not decoded correctly.     
  TYPETMDB 14.197  Support for TMON/DB2 Version 3 (INCOMPATIBLE).       
  TYPETMON 14.042  INVALID DATA for TIGETMCT or TIFREMCT corrected.     
  TYPETMS5 14.018  TMS datasets TMSRECS,DSNBRECS now deleted from WORK. 
  TYPETMVS 14.135  Support for Landmark TMON/MVS spanned records.       
  TYPETPM  14.113  Support for Thruput Manager #V041238 (INCOMPATIBLE). 
  TYPEVM   14.008  INVALID DATA FOR PWCOUNT in VMID=06 VM Accounting.   
  TYPEWSF  14.143  Support for RDS's EOS Enterprise Output Solution     
  TYPEX37  14.091  STOPX37 SMF records changed by Boole, useless now.   
  TYPEXSTR 14.144  Support for Anacomp, Inc's XSTAR product SMF record. 
  TYPPROS  14.207  Support for Boole & Babbage's PRO/SMS.               
  UCICSCNT 14.060  Enhanced CICS diagnostic tool for EXCLUDE/INCLUDE.   
  UDB2GTF  14.154  Support for DB2 records written to GTF.              
  UDEBLOCK 14.155  Utility to create valid RECFM=U on MVS from PC data. 
  UTILGETM 14.018  Type 110 Subtype 2818 recognized and counted.        
  VMXGSUM  14.177  If DESCENDING was used with KEEPALL=NO, it was lost. 
  VMXGTAPE 14.153  Utility macro to determine if lib/dsn is on tape.    
  WEEKBLDT 14.010  NOTSORTED error with ASUMCICS in weekly logic.       
  YEAR2000 14.100  Use of Date literal '01JAN00' changed to '01JAN1900' 
Inverse chronological list of all Changes:                              
  Changes 14.209 thru 14.001 were printed in MXG Newsletter THIRTY,     
  and are contained in member CHANGESS.