COPYRIGHT (C) 1984-2014 MERRILL CONSULTANTS DALLAS TEXAS USA

MXG NEWSLETTER ALL

 /* COPYRIGHT (C) 1984-2014 MERRILL CONSULTANTS, DALLAS, TEXAS */
 Last Updated: Apr 23, 2014.

                   MXG Technical NEWSLETTERS

                 Text of MXG Technical Newsletters

 This member contains the text of all published MXG Newsletters.  This
 lets you search for the text of technical information in each MXG
 Newsletter.  EXCLUDE ALL, then FIND "MXG NEWSLETTER NUMBER" ALL

 The "Change Log" part of each newsletter is NOT provided here, since
 that information is in members CHANGEnn for previous MXG Versions, and
 is in member CHANGES for the current MXG Software Version.

 All Newsletters and all Changes are also online at
  http://www.mxg.com/changes  and http://www.mxg.com/newsletters
     (which might even be where you are reading this text!).

 The most recent newsletter is listed first.

 MXG Newsletters are a part of the MXG Software Product, and intended to
 be read only by employees of or consultants at supported sites, i.e.,
 sites with an active MXG License or sites that have licensed SAS/ITSV.
 Please be fair to us and our copyright; become a licensed MXG customer
 so that you can legally read this material, and so that we can keep
 your MXG Software up to date and always usable.

 Newsletters are 72 characters per line (to be easily read with 3270
 technology) with no font control characters.




***********************NEWSLETTER SIXTY-FOUR-TO-BE*********************



          MXG NEWSLETTER NUMBER SIXTY-FOUR-TO-BE - UNDATED

Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE

                         TABLE OF CONTENTS

I.    MXG Software Version.
II.   MXG Technical Notes
III.  MVS, aka z/OS, Technical Notes
IV.   DB2 Technical Notes.
V.    IMS Technical Notes.
VI.   SAS Technical Notes.
VI.A. WPS Technical Notes.
VII.  CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX.   z/VM Technical Notes.
X.    Email notes.
XI.   Incompatibilities and Installation of MXG.
         See member CHANGES and member INSTALL.
XII.  Online Documentation of MXG Software.
         See member DOCUMENT.
XIII. Changes Log
     Alphabetical list of important changes
     Highlights of Changes  - See Member CHANGES.

     COPYRIGHT (C) 1984,2014 MERRILL CONSULTANTS DALLAS TEXAS USA

I.  The Current Version MXG 32.04 is dated Apr 23, 2014.

    The 2014 Annual Version MXG 31.31 was dated Jan 20, 2014.

    You can always use this form
         http://www.mxg.com/Software_Download_Request
    to request the ftp download instructions for the current version.

    ALWAYS USE THE MOST CURRENT VERSION OF MXG.

    See CHANGES member of MXG Source, or http://www.mxg.com/changes.

II.  MXG Technical Notes

 1. Using LABEL statement to change the order of variables in a dataset.
    In general, MXG attempts to create datasets with the variables in
    alphabetic order, to make it easier to find a variable in the output
    of PROC PRINT/PROC MEANS, etc.  But you might want a few "key" vars
    to always be first, and you can do that with this syntax:
        DATA NEW;
        LABEL MYFIRST= MYSECOND= MYTHIRD= ;
        SET OLD;
    The NEW dataset will have the three MY variables first followed by
    the other variables in alphabetic order, and ALL variables will have
    their original label.  In fact, you cannot use that LABEL statement
    to change a label.  SAS uses the LAST label statements' value for
    the variable's label.  Here, the inserted LABEL statement only sets
    the order because it is the first reference to those variable names.
      (So, you could tailor the last EXdddddd member and add your
       replacement label there, it will be after all LABEL statements.)

III. MVS, a/k/a z/OS, Technical Notes.

 2. Use of IBM File Manager can corrupt SMF files when copied.  The File
    Manager defaults to PAD=ON with x'00' as the default pad character,
    causing all final '00'x bytes to be REMOVED from the output copy.
    Changing to use PAD=OFF preserves the original SMF record.

 1. Comparison of CPU times captured by RMF I, RMF III, and SMF.
    This is NOT earthshattering; an MXG user asked who well the CPU
    timings compared between RMF I, RMF III, and SMF 30 records,
    and sent four hours data to analyze with MXG.

    Initial summary:

  - Four hours of data from five systems with z/OS 1.3 on a 2827-709,
    2817-712 and 2817-720 from RMF I, RMF III, and SMF is compared.

    This is not perfectly matched data: the site's RMF I data is written
    at 15 minute intervals but with SYNC(59) instead of SYNC(0), while
    the SMF 30s are written hourly and are NOT synchronized with SMF,
    and RMF III writes every 30 seconds. z/OS 1.3

    REPORT 1 - OVERALL COMPARISONS

  - The "Hardware" records in REPORT 1 are close; the RMF III CPUG3
    data recorded 909 seconds more Partition Dispatch Time (0.4%) than
    did RMF I TYPE70 out of 203,223 seconds CPU time.

  - The RMF III "Service Class" data in RCDG3 is slightly larger than
    the RMF I type 72 subtype 3 records, recording 791 more (0.4%).
    The RMF I/III average Capture Ratio for all systems is 89.5% of
    the "hardware" CPU is recorded in Service Class in RMF I and III.

  - The RMF III "Address Space" data in ASIG3 varies with 1503 more
    total in RMF III than SMF Interval time, but it is inconsistent,
    as three systems recorded more time in SMF than RMF III.  But since
    SMF was NOT synchronized, that these numbers are this close is good!
    But, the SMF Capture Ratio is only 85% of the "hardware" CPU time.

        Seconds of CPU time captured by RMF I, RMF III, and SMF.

                            SYS0    SYS1   SYS2   SYS3   SYS4   Total
      "Hardware CPU Time":
        Dataset  Variable
a. RMF3 ZRBCPU   CPUPHYSI   23214   55501  30298  29877  64321  203223
b. RMF1 TYPE70   CPUACTTM   23135   55009  30218  29883  64067  202314
c. RMF1 ASUM70LP LCPUPDTM   23135   55009  30218  29883  64067  202314

      "Service Class CPU:"
       Dataset   Variable
d. RMF3 ZRBRCDS  CPUTM      20655   51494  26443  26645  56688  182027
e. RMF1 RMFINTRV CPUTM      20568   51134  26393  26671  56467  181236
r  RMF1 TYPE72GO CPUTM      20568   51134  26393  26671  56467  181235

      "Address Space CPU:"
       Dataset   Variable
g. RMF3 ZRBASI   ASICPUTA   19595   49032  25064  24713  54456  172863
h. SMF  SMFINTRV CPUTM      19909   46615  26684  26380  51771  171360

      These are the preceding CPU time metrics and their source:

      RMF3 ZRBCPU   - RMF III Record CPUG3.
      RMF1 TYPE70   - RMF   I Type 70 Subtype 1
      RMF1 ASUM70LP - MXG Summary of TYPE70 PR/SM
      RMF1 TYPE72GO - RMF   I Type 72 Subtype 3 Service Class only
      RMF1 RMFINTRV - MXG Summary of TYPE72GO
      RMF3 ZRBRCDS  - RMF III Record RCDG3.
      RMF3 ZRBASI   - RMF III Record ASIG3.
      RMF1 SMFINTRV - SMF Type 30 Subtype 2/3


 REPORT 2 - COMPARISON OF RMF I TYPE72-3 AND RMF III SERVICE CLASS

  - This table compares the total CPU time and total ZIP time for each
    Service Class.  And here too, RMF III recorded 792 more seconds than
    RMF I, although a few classes had more RMF I than RMF III, but these
    data were not perfectly synchronized, so these again show goodness.


        SRVCLASS RMF3CPUTM RMF72CPUTM DELTACPU RMF3ZIPTM RMF72ZIPTM

        BATHI      7724.78   7787.33  -62.56      9.73     32.43
        BATHOT     2347.31   2356.11   -8.80      4.26      5.84
        BATLOW    33171.44  32792.04  379.40      2.95    137.36
        BATMED    76069.23  75951.35  117.87    -54.48    274.11
        BATMEDW      98.59     98.59   -0.00       .        0.00
        DBHIGH     8029.33   7990.11   39.22   4946.80   5068.98
        DBLOW      9454.16   9438.17   16.00       .        0.00
        DDFADHOC     99.60     99.60    0.00       .        0.00
        DDFCICS       1.84      1.84   -0.00       .        0.00
        DDFPROD     839.37    837.34    2.04    909.92   1000.51
        OMVS         62.09     46.04   16.05     11.00     12.34
        ONLINHI    8804.13   8731.83   72.30    115.32    131.60
        ONLINMED   8712.54   8662.36   50.18     54.85     79.23
        ONLINTST     13.96     13.88    0.08      1.77      3.56
        STCHI      3934.09   3903.70   30.39    207.75    250.54
        STCLOW     3895.26   3868.81   26.44      0.07      0.72
        STCMED      889.73    886.05    3.68      0.01      0.15
        STCNDM     3565.27   3554.12   11.15       .        0.00
        SYSOTHER      0.00      0.00    0.00       .        0.00
        SYSSTC     6755.58   6717.66   37.92   1208.46   1293.00
        SYSTEM     7178.80   7119.08   59.72       .        0.00
        TSOPROD     330.44    328.99    1.45       .        0.00
        TSOSPEC      50.44     50.44    0.00       .        0.00
                 ========= ========== ======  ======== ==========
                 182027.98 181235.44  792.54   7418.41   8290.38




IV.   DB2 Technical Notes.

 1. Text


V.   IMS Technical Notes.

 1.

VI.  SAS Technical Notes.

 1.

VI.A.  WPS Technical Notes.

 1. Text


VII. CICS Technical Notes.

 1. Text

VIII. Windows NT Technical Notes.

 1. Text

IX.  z/VM Technical Notes.

 1. Text


X.   Email notes.

 1. Text



XI.   Incompatibilities and Installation of MXG vv.yy.

 1. Incompatibilities introduced in MXG 32.04 (since MXG 31.31):
    See CHANGES.

 2. Installation and re-installation procedures are described in detail
    in member INSTALL (separate sections for each platform, z/OS, WIN,
    or *nix), with examples of common Errors/Warnings messages a new MXG
    user might encounter, and in member JCLINSTT for SAS V9.2 or member
    JCLINSTW for WPS. INSTALL also shows how to read SMF data on PCs/nix
    using the FTP ACCESS METHOD.

XII.  Online Documentation of MXG Software.

    MXG Documentation is now described in member DOCUMENT.


XIIV. Changes Log

--------------------------Changes Log---------------------------------

 You MUST read each Change description to determine if a Change will
 impact your site. All changes have been made in this MXG Library.

 Member CHANGES always identifies the actual version and release of
 MXG Software that is contained in that library.

 The CHANGES selection on our homepage at http://www.MXG.com
 is always the most current information on MXG Software status,
 and is frequently updated.

 Important changes are also posted to the MXG-L ListServer, which is
 also described by a selection on the homepage.  Please subscribe.

 The actual code implementation of some changes in MXG SOURCLIB may be
 different than described in the change text (which might have printed
 only the critical part of the correction that need be made by users).

 Scan each source member named in any impacting change for any comments
 at the beginning of the member for additional documentation, since the
 documentation of new datasets, variables, validation status, and notes,
 are often found in comments in the source members.

Alphabetical list of important changes after MXG VV.RR in MXG VV.RR+1:

  Dataset/
  Member   Change    Description

  See Member CHANGES in your MXG Source Library for THIS MXG version, or
  see Member CHANGESS in your MXG Source Library for all 8,935 changes
  since 1984, and online at http://www.mxg.com/changes.


***********************NEWSLETTER SIXTY-THREE***************************



          MXG NEWSLETTER NUMBER SIXTY-THREE  Feb 26, 2014

Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE

                         TABLE OF CONTENTS

I.    MXG Software Version.
II.   MXG Technical Notes
III.  MVS, aka z/OS, Technical Notes
IV.   DB2 Technical Notes.
V.    IMS Technical Notes.
VI.   SAS Technical Notes.
VI.A. WPS Technical Notes.
VII.  CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX.   z/VM Technical Notes.
X.    Email notes.
XI.   Incompatibilities and Installation of MXG.
         See member CHANGES and member INSTALL.
XII.  Online Documentation of MXG Software.
         See member DOCUMENT.
XIII. Changes Log
     Alphabetical list of important changes
     Highlights of Changes  - See Member CHANGES.

     COPYRIGHT (C) 1984,2014 MERRILL CONSULTANTS DALLAS TEXAS USA

I.  The Current Version MXG 32.02 is dated Feb 26, 2014.
    The 2014 Annual Version MXG 31.31 was dated Jan 20, 2014.

    You can always use this form
         http://www.mxg.com/Software_Download_Request
    to request the ftp download instructions for the current version.

    See CHANGES member of MXG Source, or http://www.mxg.com/changes.

II.  MXG Technical Notes

 1. FORMAT NOT FOUND errors usually occur when the LIBREF/DD LIBRARY
    (the MXG.FORMATS catalog) was not updated (with FORMATS step in the
    JCLINSTL), or if the REGION= virtual memory size is insufficient.
    An additional source was found when ISPF 3.3 was used to copy a fine
    FORMAT library on LPAR into an existing dataset that had LRECL=4096.
    Rebuilding the dataset letting SAS set the DCB attributes eliminated
    these errors.

III. MVS, a/k/a z/OS, Technical Notes.

 5. APAR OA41968
    "High Paging with Large Frames NOT being broken down to 4K frames",
    introduces the new parmlib value of INCLUDE1MAFC of the existing
    IEASYSxx LFAREA parmlib parameter to Specify that the 1 MB pages are
    to be included in the available frame count (RCEAFC):  APAR text:
      By installing this PTF and specifying this new parameter value,
      system behavior will change in the following manner:
      - RSM will perform less paging when there is an abundance of
        available fixed 1M pages in the system.
      - RSM is more likely to break up fixed 1M pages to satisfy 4K page
        demand.  Although RSM attempts to coalesce broken up fixed 1M
        pages when there is fixed 1M page demand, there is no guarantee
        that coalescing will be successful, especially if one of the 4K
        frames making up the fixed 1M page is fixed long term.
    OA42066 is a also required for this enhancement/fix.

 4. APAR PI07971 for IBM/Sterling Connect-Direct 5.1 revises their zIIP
    engine use for handling compressed data to first check a threshold
    value before invoking zIIP processors and SRB mode.  This will
    reduce the overhead that resulted when small record sizes were being
    compressed.

 3. JES2 APAR OA41698 revises sending of ENF 58 and 70 (Notifications of
    a job end event), previously sent to all members of the SYSPLEX but
    with this APAR, send only to the members of this JESPLEX.  The ENF
    processing on non-JESPLEX members was observed to consume/waste CPU
    time on those systems.  Option ENFSCOPE=SYSPLEX/JESPLEX enables.

 2. APAR PI07940 reports SMF ID=119 Subtype=70 variables FSDRIP FSDLIP
    FSDRPort FSDLPort FSDConnID can be incorrect in the Rename and
    Delete command's records, where they should not be populated as
    there is no data connection, but the values from a prior connection
    were being incorrectly output.  Now they are zero in those records.

 1. SMF 30 DD segments can be not-written with EMPTYEXCPSEC or S99DASUP.
     See Newsletter FIFTY-FOUR, MVS Technical Note 1. "APAR OA29582" for
     the original discussion of EMPTYEXCPSEC option.

    -APAR OA29582 added the EMPTYEXCPSEC(SUPPRESS) option in z/OS 1.10.
     That option applies to ALL address spaces and their type 30 records
     will have EMPTY DD segments NOT-WRITTEN.  Variable SMF30DAS is the
     count of DD segments that were suppressed by this option.

    -APAR PM17542 for DB2 V10 exploits new z/OS 1.12 S99DASUP option,
     which completely removes ALL of the DD segments from the SMF 30
     records for that DB2 subsystem.  Use of S99DASUP is enabled in
     DB2 with the SYSTEM MEMDSENQMGMT(ENABLE)
       but DB2 still decides whether to use S99DASUP or not.
     SMF30DAS does NOT contain any counts of these non-written DDs.
       (MEMDSENQMGT also enables DB2 management of Dataset Enqueues
        in memory, a second performance improvement in that APAR.)

     I found this post from Steven B Jones, IBM BCP Development in reply
     to a question about the independence of the two options:

      "MEMDSENQMGMT and S99DASUP are independent, as you say.  S99DASUP
       allows an authorized caller to suppress some of the accounting
       overhead associated with Allocation.  It is intended for use with
       VSAM data sets, since VSAM records more information in its SMF
       records than Allocation and SMF, which makes the overhead of us
       maintaining the information pointless.

       MEMDSENQMGMT is associated with another feature in Allocation
       processing.  The ALLOCxx parmlib member contains MEMDSENQMGMT
       keyword to allow an installation the ability to disable the
       feature, in case of odd interactions with ancient programs.  Once
       enabled, though, a program must use the IEFDDSRV MODIFY FEATURE
       service to enable the feature for job step/ address space.

       Two levels of enablement may seem excessive, but with Allocation,
       we're learning that we can never know what programs have done to
       and with our data areas and allowing a programmer to choose to
       enable a feature may have effects that the installation needs to
       control.

IV.   DB2 Technical Notes.

 1. Text


V.   IMS Technical Notes.

 1. APAR PI05160 for IMS Connect Extensions V2 provides new function to
    offload some CEX Event Recording processing to zIIP engines via a
    start=up option for CEX.

VI.  SAS Technical Notes.

 2.  SAS Note 51008 reports using SAS ODS Graphics on z/OS with Java
     versions:
        •Java 1.6.0.1 SR6
        •Java 1.6.0.0 SR14
        •Java 1.7.0.0 SR5
     caused these errors when MXG invoked ODS:
       ERROR: The Java proxy could not create a new classloader.
       ERROR: The Java proxy failed to update a classloader.
       ERROR: Unable to attach current thread.
     That SAS note provides a  -jreoptions=  statement to add to your
     HLQ.CONFIG(SITE) file to circumvent the error, documented in the
     note for SAS 9.3, but the errors also occurred with SAS 9.4.


 1. SAS Note 45793 for z/OS 1.13 reports an 0C4 ABEND can occur when
    concatenated files are read but a file in the concatenation doesn't
    exist.  IBM APAR OA37610 will correct the 0C4 ABEND so that you get
    a SAS ERROR message rather than the ABEND.

VI.A.  WPS Technical Notes.

 1. Text


VII. CICS Technical Notes.

 1. Text

VIII. Windows NT Technical Notes.

 1. Text

IX.  z/VM Technical Notes.

 1. Text


X.   Email notes.

 1. Text



XI.   Incompatibilities and Installation of MXG vv.yy.

 1. Incompatibilities introduced in MXG 31.09 (since MXG 30.30):
    See CHANGES.

 2. Installation and re-installation procedures are described in detail
    in member INSTALL (separate sections for each platform, z/OS, WIN,
    or *nix), with examples of common Errors/Warnings messages a new MXG
    user might encounter, and in member JCLINSTT for SAS V9.2 or member
    JCLINSTW for WPS. INSTALL also shows how to read SMF data on PCs/nix
    using the FTP ACCESS METHOD.

XII.  Online Documentation of MXG Software.

    MXG Documentation is now described in member DOCUMENT.


XIIV. Changes Log

--------------------------Changes Log---------------------------------

 You MUST read each Change description to determine if a Change will
 impact your site. All changes have been made in this MXG Library.

 Member CHANGES always identifies the actual version and release of
 MXG Software that is contained in that library.

 The CHANGES selection on our homepage at http://www.MXG.com
 is always the most current information on MXG Software status,
 and is frequently updated.

 Important changes are also posted to the MXG-L ListServer, which is
 also described by a selection on the homepage.  Please subscribe.

 The actual code implementation of some changes in MXG SOURCLIB may be
 different than described in the change text (which might have printed
 only the critical part of the correction that need be made by users).

 Scan each source member named in any impacting change for any comments
 at the beginning of the member for additional documentation, since the
 documentation of new datasets, variables, validation status, and notes,
 are often found in comments in the source members.

Alphabetical list of important changes after MXG VV.RR in MXG VV.RR+1:

  Dataset/
  Member   Change    Description

  See Member CHANGES in your MXG Source Library for THIS MXG version, or
  see Member CHANGESS in your MXG Source Library for all 8,935 changes
  since 1984, and online at http://www.mxg.com/changes.


***********************NEWSLETTER SIXTY-TWO*****************************




          MXG NEWSLETTER NUMBER SIXTY-TWO, SEP  1, 2013

Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE

                         TABLE OF CONTENTS

I.    MXG Software Version.
II.   MXG Technical Notes
III.  MVS, aka z/OS, Technical Notes
IV.   DB2 Technical Notes.
V.    IMS Technical Notes.
VI.   SAS Technical Notes.
VI.A. WPS Technical Notes.
VII.  CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX.   z/VM Technical Notes.
X.    Email notes.
XI.   Incompatibilities and Installation of MXG.
         See member CHANGES and member INSTALL.
XII.  Online Documentation of MXG Software.
         See member DOCUMENT.
XIII. Changes Log
     Alphabetical list of important changes
     Highlights of Changes  - See Member CHANGES.

     COPYRIGHT (C) 1984,2013 MERRILL CONSULTANTS DALLAS TEXAS USA

I.  The 2013 Annual Version MXG 30.30 was dated Jan 21, 2013.

 1. The current version is MXG 31.07, dated Sep 20, 2013.

    You can always use this form
         http://www.mxg.com/Software_Download_Request
    to request the ftp download instructions for the current version.

    See CHANGES member of MXG Source, or http://www.mxg.com/changes.

II.  MXG Technical Notes

 1. Sending data to ftp.mxg.com.
    Merrill Consultant's Secure FTP server supports SSL, TLS, and SSH,
    and SFTP for sending data


III. MVS, a/k/a z/OS, Technical Notes.


 8.  TRSMAIN PARM SPACK creates a much smaller file than PACK in this
     comparison of compressing SMF data with both options, but SPACK
     takes about three times as long:
       Method  --CPU--   ----IN---- ---OUT---
       PACK    1.4 sec   38,055,864 6,951,936 18%
       SPACK   3.4 sec   38,055,864 3,459,072  9%
     IBM supports only version 2 of TRSMAIN, shipped in 1993, and later
     versions.  Further, support is limited to the SPACK option.

 7.  SMF bytes counted in ANALID may be compressed or uncompressed size.
     When MXG executes under z/OS:
      a. With %LET SMFEXIT=CICS to use the CICSIFUE Infile exit, the SMF
         record has been decompressed before the MXG code in _SMF runs,
         so the LENGTH reported is always the uncompressed length.
      b. If you do NOT enable the use of the CICSIFUE Infile exit, the
         SMF records are still compressed when _SMF is executed, so the
         LENGTH reported is always the compressed length.
           To compare the size of your SMF data before/after enabling
           compression of CICS and DB2 data, run ANALID once with the
           INFILE exit enabled, and once without to see the total size
           reduction.
           One snapshot of daily volume before/after:
             DB2 and CICS compressed   - 17,663,216,116 bytes
             DB2 and CICS uncompressed - 45,403,944,137 bytes
             Savings of                - 27,740,728,021 bytes
             Compressed data is about 39% the size of  uncompressed.
     When MXG executes under ASCII:
      a. There is no CICSIFUE exit for ASCII, so the LENGTH seen in _SMF
         is the compressed length.

 6.  APAR OA40596 reports errors in these SMF 42 Subtype 19 fields
       SMF42JNE SMF42JNF SMF42JPE SMF42JPF
       SMF2AJNE SMF2AJNF SMF2AJPE SMF2AJPF
     were corrected, but RMF III uses those fields and APAR OA41815 is
     needed to correct RMF III data.

 5.  Sites with ATAM, Tivoli's Automated Tape Allocation management, who
     use MXG's Tape Mount Monitor MXGTMNT/ASMTAPEE program, will have
     problems allocating tapes and ATAM error messages ATH016W, if the
     ATAM guru did not specify EXITCOMPAT=Y in the ATAM startup parms.
     Member ADOCTMS5 has complete details from pages 121-123 of the ATAM
     User's Guide.

 4. SMF70NSW and SMF70NCA can both be zero on z/EC12 due to a hardware
    issue.  Both are created in ERBMFDCP based on data returned from the
    hardware Diagnose 204 instruction, and there is a Hardware Fix to
    correct: "Setting of WLM capping is missing on Diag 204 from 2827"
    in MCL H09168-002 from bundle 24.

 3. The RMF Monitor I TYPE78VS CSA/SQA Virtual Storage data won't match
    RMF Monitor III CSA/SQA Measurements because those data are based on
    different sources:
      The MI VSTOR report shows the virtual storage allocation.
      The RMF Monitor III shows the real central storage occupation.
    For example, DREF pages are not backed by central storage frames
    until they are referenced, so they will be counted in VSTOR data,
    may not (yet) be counted in the RMF III data.

 2. APAR OA41459 corrects an IBM error that was discovered when SAS was
    used to write compressed data files with tailored compression table.


 1. An IBM-MAIN post noted that IBM has been using 36-core mainframe
    modules in the zEC12, for a total of 120 usable PUs, of which, in
    maximum configuration,16 are configured as SAPs, 2 are spares, 1 is
    a reserve, and 101 are customer configurable as CPs, IFLs, zIIPs,
    zAAPs, ICFs, or additional SAPs.


IV.   DB2 Technical Notes.

 1. Text

V.   IMS Technical Notes.

 1. Text


VI.  SAS Technical Notes.

 6.  In a %MACRO definition, syntax for a comment can be either

            /* comment text */
     Or
            %* comment text ;

     BUT: If you INCORRECTLY use:
            *%PUT text ;
     the %PUT is executed as it is NOT seen as a comment; without that %
     it would be seen as base code and then it would be a comment.

 5. The AUTONAME option in PROC MEANS will truncate long variable names
    to fit the suffix (_SUM _MAX _MIN etc) to be added to the variable
    name.  With similar variable names there will NOT be duplicate
    names, but there will be names where the suffix added will have a
    number appended to it. AUTONAME is rarely used in MXG (ANAL72GO
    ANALINIT ANALHTML UGMTCHK) and it is safe in all of those cases.
    But, it is an option in VMXGSUM and should be used cautiously to
    avoid confusion.

    In case 1 there will be multiple variables with the same name where
    the suffix is _SUM _SUM1 and _MAX _MAX1. There will be a NOTE in the
    SAS LOG telling you this was done.

       CASE 1:
        DATA VIPDLW;
        VIP_DLC_WQ_QDEPTHAVG_OBS_HWM_OBS=5;
        VIP_DLC_WQ_QDEPTHAVG_OBS_HWM_OBX=9;
        PROC MEANS NOPRINT DATA=VIPDLW ;
        VAR VIP_DLC_WQ_QDEPTHAVG_OBS_HWM_OBS
        VIP_DLC_WQ_QDEPTHAVG_OBS_HWM_OBX ;
         OUTPUT OUT=TEST ( DROP= _FREQ_ _TYPE_ )
          MAX(VIP_DLC_WQ_QDEPTHAVG_OBS_HWM_OBS
              VIP_DLC_WQ_QDEPTHAVG_OBS_HWM_OBX )=
          SUM(VIP_DLC_WQ_QDEPTHAVG_OBS_HWM_OBS
              VIP_DLC_WQ_QDEPTHAVG_OBS_HWM_OBX )=
        /INHERIT KEEPLEN AUTONAME ;
        RUN;

    In case 2, there is no similarity in the names and they are simply
    truncated with no NOTE in the log.

       CASE 2:
        PROC CONTENTS;
        DATA VIPDLW;
        VIP_DLC_WQ_QDEPTHAVG_OBS_HWM_OBS=5;
        WIP_DLC_WQ_QDEPTHAVG_OBS_HWM_OBX=9;
        PROC MEANS NOPRINT DATA=VIPDLW ;
        VAR VIP_DLC_WQ_QDEPTHAVG_OBS_HWM_OBS
        WIP_DLC_WQ_QDEPTHAVG_OBS_HWM_OBX ;
         OUTPUT OUT=TEST ( DROP= _FREQ_ _TYPE_ )
          MAX(VIP_DLC_WQ_QDEPTHAVG_OBS_HWM_OBS
              WIP_DLC_WQ_QDEPTHAVG_OBS_HWM_OBX )=
          SUM(VIP_DLC_WQ_QDEPTHAVG_OBS_HWM_OBS
              WIP_DLC_WQ_QDEPTHAVG_OBS_HWM_OBX )=
        /INHERIT KEEPLEN AUTONAME ;
        RUN;
        PROC CONTENTS;

 4. For z/OS jobs using ODS GRAPHICS, SAS notes that "the region size of
    a typical SAS job needs to be increased when features are used that
    incorporate Java.  The increase will vary depending upon the
    application. At a minimum, regions for SAS jobs using Java require
    256 MB. For a batch job, add either REGION=256M to the JOB card.
    For a TSO session, specify SIZE(262144)."  However, we see a MUCH
    bigger region required for the new ODS version of GRAFWRKS that uses
    PROC SGPLOT procedure, which required 677M.

 3. We have tested the Early Adopter release of SAS 9.4, on z/OS 1.13
    and on ASCII (WIN7 and WIN8) with the MXG 31.02 QA job stream and
    have found NO PROBLEMS and so far, COMPLETE COMPATIBILITY with 9.3.

    An additional performance comparison was made reading an SMF file of
    6334MB (6.2GB) with 3,715,924 records (6GB SMF 30 intervals, 334MB
    SMF 70s, a FULL year's data!), with lots of sorts and reports, under
    WIN7 on a notebook with i7-3840QM @ 2.80 GHz CPU, with input SMF on
    a fast USB 3 drive, and with WORK and PDB outputs on separate
    (FAST!) SSD drives, with no significant differences:

                  SAS 9.3                             SAS 9.4
            CPU Time    Elapsed Time            CPU Time  Elapsed Time
             mm:ss       mm:ss                    mm:ss     mm:ss
             10:05       11:07                    10:29     11:11

 2. A site with SAS 9.2 had three datasets concatenated to //SOURCLIB
    on z/OS, with the first DSN having BLKSIZE=32720 and the other two
    with BLKSIZE=27920; when TYPE110 was run, 60 lines were completely
    skipped causing a series of strange errors.  60*80=4800 which is
    the delta between 32720 and 27920.  Changing the first DSN BLKSIZE
    to 27920 to match the other two DSNs resolved the problem for the
    user, but SAS will now investigate why this was an error.

 1. SAS Note 46767 reports MXGNAMES/CONFIMXG can't have a //SOURCLIB DD
    until SAS 9.4 corrects a defect.  One is not needed with MXGNAMES
    because the //SOURCLIB and //LIBRARY (required) DDs are dynamically
    allocated; the correction in 9.4 is to NOT loop and instead simply
    ignore the static DD allocation if it exists in the JCL.

VI.A.  WPS Technical Notes.

 1. MXG Support for WPS Software:

       The Current MXG Version and the Current WPS Version are required
       for any problem to be considered.

       Note that your MXG Software License Agreement states legally:

        Merrill agrees to provide continuous product support for MXG in
        the following areas:
          When error conditions
            (i.e., the SAS execution of MXG code produces either a
            return code or an ABEND)
          are the results of errors in MXG Code, they will be corrected.

        If you encounter an error testing MXG under WPS:

           You should report the error to WPS Technical Support for
           initial investigation.

           If WPS support believes the error is an MXG problem, they can
           contact MXG, or may choose to refer you to MXG Support.

           MXG Support may then request you to send data to MXG:

              - the raw data file that caused the error
              - your site's USERID.SOURCLIB (tailoring) source library
              - your program

           If the error can be replicated under the SAS System, it will
           be corrected per the above license terms.



VII. CICS Technical Notes.

 1. Text

VIII. Windows NT Technical Notes.

 1. Text

IX.  z/VM Technical Notes.

 1. APAR VM64961 is needed for the CPU Measurement Facility (SMF 113)
    data in z/VM 5.4 or later to be valid and completed; Change 29.172
    added support and created VXPRCMFC dataset that has the same counter
    variable names as existing SMF 113 records.



X.    Email notes.

 1. Text



XI.   Incompatibilities and Installation of MXG vv.yy.

 1. Incompatibilities introduced in MXG 31.03 (since MXG 30.30):
    See CHANGES.

 2. Installation and re-installation procedures are described in detail
    in member INSTALL (separate sections for each platform, z/OS, WIN,
    or *nix), with examples of common Errors/Warnings messages a new MXG
    user might encounter, and in member JCLINSTT for SAS V9.2 or member
    JCLINSTW for WPS. INSTALL also shows how to read SMF data on PCs/nix
    using the FTP ACCESS METHOD.

XII.  Online Documentation of MXG Software.

    MXG Documentation is now described in member DOCUMENT.


XIIV. Changes Log

--------------------------Changes Log---------------------------------

 You MUST read each Change description to determine if a Change will
 impact your site. All changes have been made in this MXG Library.

 Member CHANGES always identifies the actual version and release of
 MXG Software that is contained in that library.

 The CHANGES selection on our homepage at http://www.MXG.com
 is always the most current information on MXG Software status,
 and is frequently updated.

 Important changes are also posted to the MXG-L ListServer, which is
 also described by a selection on the homepage.  Please subscribe.

 The actual code implementation of some changes in MXG SOURCLIB may be
 different than described in the change text (which might have printed
 only the critical part of the correction that need be made by users).

 Scan each source member named in any impacting change for any comments
 at the beginning of the member for additional documentation, since the
 documentation of new datasets, variables, validation status, and notes,
 are often found in comments in the source members.

Alphabetical list of important changes after MXG VV.RR in MXG VV.RR+1:

  Dataset/
  Member   Change    Description

  See Member CHANGES or CHANGESS in your MXG Source Library, or
  on the homepage www.mxg.com.

Inverse chronological list of all Changes:

Changes 31.yyy thru 31.001 are contained in member CHANGES.


***********************NEWSLETTER SIXTY-ONE*****************************




          MXG NEWSLETTER NUMBER SIXTY-ONE, JANUARY 21, 2013

Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE

                         TABLE OF CONTENTS

I.    MXG Software Version.
II.   MXG Technical Notes
III.  MVS, aka z/OS, Technical Notes
IV.   DB2 Technical Notes.
V.    IMS Technical Notes.
VI.   SAS Technical Notes.
VI.A. WPS Technical Notes.
VII.  CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX.   z/VM Technical Notes.
X.    Email notes.
XI.   Incompatibilities and Installation of MXG.
         See member CHANGES and member INSTALL.
XII.  Online Documentation of MXG Software.
         See member DOCUMENT.
XIII. Changes Log
     Alphabetical list of important changes
     Highlights of Changes  - See Member CHANGES.

     COPYRIGHT (C) 1984,2013 MERRILL CONSULTANTS DALLAS TEXAS USA

I.  The 2012 Annual Version MXG 29.29 was dated Jan 23, 2012.

 1. The current version is MXG 30.30, dated Jan 21, 2013.

    You can always use this form
         http://www.mxg.com/Software_Download_Request
    to request the ftp download instructions for the current version.

    See CHANGES member of MXG Source, or http://www.mxg.com/changes.

II.  MXG Technical Notes

 1. Compressed CICS or DB2 data should be decompressed on z/OS before
    it is read on ASCII platforms with MXG.

    On ASCII, MXG internal SAS code that decompresses CICS SMF 110s took
    over TWO HOURS to read a 652 MB compressed CICS SMF file that needed
    only TWO MINUTES for PGM=DFH$MOLS to decompress on z/OS, and then
    only NINE MINUTES for MXG to process the 2354 MB CICS file on ASCII.
    (MXG does print a NOTE when this internal code is executed.)

    The below results STRONGLY RECOMMEND that compressed CICS ID=110
    subtype 1 records should be decompressed with PGM=DFH$MOLS on z/OS
    and that data read from the ASCII platform.  Unfortunately, DFM$MOLS
    will only write SMF 110 subtype 1 records; it does NOT pass other
    SMF records into its output, so you will need to split the 110-1's,
    run them thru DFH$MOLS, and concatenate with the other SMF data.
    Also, you must use a new CICS version's DFH$MOLS program to read
    a new CICS version's records; you cannot use the CICS 4.2 DFH$MOLS
    to uncompress CICS 5.1 data (USER ABEND 106). See member DFH$MOLS.

    The same algorithm is used for DB2 compressed SMF records, so I also
    STRONGLY RECOMMMED that DB2 ID=101 compressed records should also be
    first decompressed on z/OS by PGM=DSNTSMFD and then the decompressed
    records are read by MXG on ASCII.  DSNTSMFD does write all other SMF
    records in its input to its output. See member DSNTSMFD.

    Newsletter FIFTY-SEVEN compared processing CICS data on ASCII, but
    didn't use the ftp access method, and its example was not dense CICS
    compressed data.  This new measurement's SMF file is 110-only, with
    85900 records, 78620 of which are compressed subtype 1 records; the
    SMF file is 652 MB, of which 562 MB are compressed subtype 1s, which
    uncompress to 2354 MB.


     a. Use DFH$MOLS first to uncompress the file and read UNCOMPRESSED.
     c. Use MXG's internal SAS algorithm to read COMPRESSED NO EXIT.

                                 Elapsed    User CPU SYS CPU    Size
      a. DFH$MOLS on z/OS        00:02:00   00:00:05          652/2354MB
         UNCOMPRESSED on ASCII   00:09:36   00:08:57 00:00:05   2354 MB
           total                 00:11:36

      c. INTERNAL SAS on ASCII   02:19:24   02:13:04 00:00:29   2354 MB

    The uncompressed file requires z/OS disk space, 2354 MB, but ONLY
    for eleven minutes, and it is a temporary file.

    And, for reasons I do NOT (yet) understand, DFH$MOLS program SORTs
    the input SMF file. The DFH$MOLS log statistics show:
      Records Read     85,900  ( 652MB)
      Records Written  78,260  (2354MB)
      Sortwork Tracks  10,419  ( 549MB)

III. MVS, a/k/a z/OS, Technical Notes.

 5. APAR PM79239 for HTTP Server for z/OS 5.3 reports a remote
    attacker could execute arbitrary commands on the system, with
    a base CVSS Score of 10, which, I presume, is the reason the
    APAR is a FLASH(ALERT), and why IBM reps are calling customers.
    APAR OA41000 or OA41031 for z/OS, and APAR OA41059/60/61 for
    Tivoli Netview are also a part of the Security Vulnerability.

 4. APAR PM74888, PTF UK90705 12/21/2012, corrects wrong data is
    in SMF 101 records for QWACZIIP_ELIGIBLE, only for DB2 utilities.
    This is MXG variable QWACZIEL in DB2ACCT, T102S148 or T102S369.
    APAR DESCRIPTION: Value QWACZIIP_ELIGIBLE in an IFCID accounting
    record can be incorrect.  When an agent executes a utility, a call
    to record the stop of accounting time executing that utility will
    not correctly obtain the zIIP time of the CPU.  This incorrect value
    will then be used in a calculation of QWACZIIP_ELIGIBLE for the
    subsequent accounting record, resulting in incorrect values for
    QWACZIIP_ELIGIBLE field.  This error could appear in any of these
    records: IFCID3, IFCID148 and IFCID369.  One instance in one record
    had over 14,576 HOURS in QWACZIEL without the PTF.

 3. APAR OA39058 makes changes to the ID=99 SUBTYPE=14 records, to
    consolidate the current two-records-per-interval into a single
    record.  See Change 30.259.

 2. APAR OA40532 reports SMF 21 read/write counts in SMF21BR, SMF21BW,
    SMF21BRN and SMF21BWN can be zero when data was transferred; the
    APAR cites only device type 3592 Model E07 as having the error.

 1. APAR OA40596 reports CPU time fields in TYPE 42 subtype 19 are not
    correct, but did not identify if both SMF42JNE and SMF42JNF are
    wrong, and the APAR reports that RMF III RLSLRU CPU times are taken
    from the 42-19 and is also wrong.  The APAR is OPEN, but it has a
    circumvention(divide by 4096*10**6) but MXG has already divided by
    4096*10**3 so it's unclear if dividing current by 1000 is correct.
    Additionally, APAR OA40653 identifies these ID=42 variables are all
    incorrect (all fields in the SMF2AJPY array): SMF2AJPZ SMF2AJQA
    SMF2AJQB SMF2AJQ6 SMF2AJQC SMF2AJQD SMF2AJQF SMF2AJQ7


IV.   DB2 Technical Notes.

 1. Text

V.   IMS Technical Notes.

 1. Text


VI.  SAS Technical Notes.

 3. ITSV Sites using %CPSTART with an MXG Program HARDCODED with "PDB."
    will fail when MXG writes to //PDB, which has DISP=SHR in ITSV.
    The hardcoded value is the cause of the error, and the MXG program
    corrected; ever since Change 15.320, the macro variable &PDBMXG has
    been the correct syntax.
      The ITSV "PDB" is a logical grouping of data libraries, with
      different summarization levels.
      In MXG, PDB is the default LIBNAME to which most programs write
      their output SAS datasets.
    But, to document how this interface between ITSV and MXG works, you
    could use that MXG program with hardcoded PDB. after %CPSTART, by
    invoking %VMXGINIT after %CPSTART to change the MXG default to WORK:
        //SYSIN DD *
         %CPSTART(MODE= . . . .   );
         %VMXGINIT(DEFAULT=WORK);
         %INCLUDE SOURCLIB(ANALZIPC);
         RUN;
    Then, all of the datasets that would have been written to //PDB are
    in the //WORK data library, and all reports were produced. If you
    also want to KEEP those "//PDB" datasets created by the MXG program,
    you can add this LIBNAME statement in your JCL
         //REALPDB DD DSN=YOUR.REAL.OUTPUT.PDB,DISP=(NEW,CATLG),
         //           UNIT=SYSDA,SPACE=(CYL,(500,500))
    and add this SAS statement after the %INCLUDE in the SYSIN program.
         PROC COPY IN=WORK OUT=REALPDB MT=DATA;

    Note that when %CPPROCES/%CMPROCES are used to create an MXG "PDB"
    library, they replace the BUILDPDB functionality, with a %VMXGINIT
    to change the default to WORK, and then execute a constructed DATA
    step of _VARxxxx and _CDExxxx tokens for the MXG datasets you want,
    which are then copied from WORK to DETAIL, where they are renamed
    to their ITSV names.  But %CxPROCES also defines VIEWs for datasets
    in their DETAIL library that, when you use the PDB LIBNAME, return
    the original MXG dataset and variable names, so you can %INCLUDE
    MXG programs that expect their data in the PDB data library and they
    work just fine "as-is" after you use %CxPROCES.

 2. SAS Version 9.2 on z/OS ABEND 0C4 in SASVM occurred in DAILYDSN job
    with MXG 30.04 but ran fine with MXG 29.05.  Customer compared MXG
    options with their CONFIG options and found MPRINT in their CONFIG
    that was NOT in MXG's default, and removing the MPRINT from CONFIG
    eliminated the error, even though OPTIONS MPRINT is very OFTEN used
    by MXG support for diagnostics.  SAS Technical Support confirmed the
    actual error is Problem Note 39533 for 0C4 in SASVM, SASXAL, SASXA1
    and that error is corrected in SAS V9.3, but the 9.2 circumvention
    is to use OPTIONS NOCARDIMAGE.  Yes, removing an option sometimes
    did circumvent this error, but NOCARDIMAGE is the 9.2 culprit.
    In SAS 9.4 the z/OS default will become NOCARDIMAGE, which is the
    current default on ASCII platforms.

 1. TRACEBACK ERROR with SAS 9.1.3 SP 4 on z/OS.

   -TRACEBACK errors can be due to insufficient region size, although
    some cases in 9.1.3 were actual compiler errors that were corrected.
    A site testing MXG 30.04 with no REGION specified on the JOB card,
    but with 250M specified on the STEP card, failed during the compile
    of PROC SQL inside the _SDB2 macro (i.e., after the "big DATA step"
    had successfully read the SMF data), with a "TRACEBACK ERROR" (and
    NO other clue).
   -My first guess, memory:
    While the SAS 'initialized' message reported 250MB was available,
    the IBM step terminate IEF032A message showed the SYS+EXT was ONLY
    93MB+11MB, and the last SAS memory note reported the above-the-line
    virtual storage was 93MB (but only 672K below!), so both suggested
    that the job's region had been limited to about 100MB.  In z/OS,
    when there is no REGION parameter on the JOB card, it is the site's
    IEFUSI exit that limits the allocated region size, and, sure enough,
    this site had a 101MB limit specified in their IEFUSI exit.  The
    site changed IEFUSI to 250M and reran, but encountered the same
    error at the same place, so this may NOT have been memory-related,
    in spite of the preceding guess.  Fortunately, the site was able
    to (WISELY!) upgrade to SAS Version 9.3 to eliminate the error.
   -The answer from SAS Technical Support:
    With SAS Version 9.1.3 there were known (and now fixed) issues with
    PROC SQL when OPTIONS THREADS was enabled, and changing to use the
    OPTIONS NOTHREADS would have been their recommendation.
    They think the memory numbers were an artifact and not the cause.

VI.A.  WPS Technical Notes.

 1. Text

VII. CICS Technical Notes.

 1. Text

VIII. Windows NT Technical Notes.

 1. Text

IX.  z/VM Technical Notes.

 1. Text



X.    Email notes.

 1. Text



XI.   Incompatibilities and Installation of MXG vv.yy.

 1. Incompatibilities introduced in MXG 30.30 (since MXG 29.29):
    See CHANGES.

 2. Installation and re-installation procedures are described in detail
    in member INSTALL (separate sections for each platform, z/OS, WIN,
    or *nix), with examples of common Errors/Warnings messages a new MXG
    user might encounter, and in member JCLINSTT for SAS V9.2 or member
    JCLINSTW for WPS. INSTALL also shows how to read SMF data on PCs/nix
    using the FTP ACCESS METHOD.

XII.  Online Documentation of MXG Software.

    MXG Documentation is now described in member DOCUMENT.


XIIV. Changes Log

--------------------------Changes Log---------------------------------

 You MUST read each Change description to determine if a Change will
 impact your site. All changes have been made in this MXG Library.

 Member CHANGES always identifies the actual version and release of
 MXG Software that is contained in that library.

 The CHANGES selection on our homepage at http://www.MXG.com
 is always the most current information on MXG Software status,
 and is frequently updated.

 Important changes are also posted to the MXG-L ListServer, which is
 also described by a selection on the homepage.  Please subscribe.

 The actual code implementation of some changes in MXG SOURCLIB may be
 different than described in the change text (which might have printed
 only the critical part of the correction that need be made by users).

 Scan each source member named in any impacting change for any comments
 at the beginning of the member for additional documentation, since the
 documentation of new datasets, variables, validation status, and notes,
 are often found in comments in the source members.

Alphabetical list of important changes after MXG VV.RR in MXG VV.RR+1:

  Dataset/
  Member   Change    Description

  See Member CHANGES or CHANGESS in your MXG Source Library, or
  on the homepage www.mxg.com.

Inverse chronological list of all Changes:

Changes 30.yyy thru 30.001 are contained in member CHANGES.


***********************NEWSLETTER SIXTY*********************************




          MXG NEWSLETTER NUMBER SIXTY, August 6, 2012

Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE

                         TABLE OF CONTENTS

I.    MXG Software Version.
II.   MXG Technical Notes
III.  MVS, aka z/OS, Technical Notes
IV.   DB2 Technical Notes.
V.    IMS Technical Notes.
VI.   SAS Technical Notes.
VI.A. WPS Technical Notes.
VII.  CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX.   z/VM Technical Notes.
X.    Email notes.
XI.   Incompatibilities and Installation of MXG.
         See member CHANGES and member INSTALL.
XII.  Online Documentation of MXG Software.
         See member DOCUMENT.
XIII. Changes Log
     Alphabetical list of important changes
     Highlights of Changes  - See Member CHANGES.

     COPYRIGHT (C) 1984,2011 MERRILL CONSULTANTS DALLAS TEXAS USA

I.  The 2012 Annual Version MXG 29.29 was dated Jan 23, 2012.

 1. The current version is MXG 30.05, dated Aug  8, 2012.

    You can always use this form
         http://www.mxg.com/Software_Download_Request
    to request the ftp download instructions for the current version.

    See CHANGES member of MXG Source, or http://www.mxg.com/changes.

II.  MXG Technical Notes

 3. Processing DB2 compressed data using MXG EXITCICS vs IBM DSNTSMFD:

     On z/OS, compressed DB2 data can be processed in a two-step job
     using the IBM DSNTSMFD program to first decompress the SMF data,
     which is then read with MXG's TYPEDB2 as the second step, or the
     the EXITCICS (Version 2) "CICSIFUE Infile Exit" can be used by the
     MXG TYPEDB2 program to decompress records as they are read.
     The DB2 SMF file contained 2 million DB2 records:

       The two-step process took:        142.76 TCB Seconds CPU
                                           6 min 10 seconds Elapsed
                                         138,000 EXCPs

       The MXG one-step EXITCICS took    140.83 TCB Seconds CPU
                                           3 min 55 seconds Elapsed
                                          76,466 EXCPs

     So the CPU times are essentially the same, but the one step had
     half the I/O activity.  While elapsed times are notoriously hard to
     compare, pretty clearly, the one-step process is faster due to the
     elimination of the write-then-read time of the two-step process.

 2.  Does MXG do any date/time checking while reading the SMF data?
     Specifically, if the dump time for my SMF data is not midnight but
     some other arbitrary time will I lose any data?

     First, no, MXG NEVER "loses" any data.

     Second, I've NEVER recommended running MXG exactly at midnight:
      - the evening batch processing often extends beyond midnight, so
        delaying the dump/BUILDPDB until later in the morning will give
        you more information on "yesterday's" batch job processing.
      - often, there is a significant flurry of activity right after
        midnight.  Some applications run programs to store the new "day"
        in a date file, and operations often runs backups at midnight,
        so BUILDPDB would be competing with (or impacting) those jobs.
     Instead, I suggest that BUILDPDB should be run N hours prior to
     when the reports are required, where N/2 is the typical run time
     of the daily job and its reports!

     MXG does NO date selection by default; you can select times in your
     IFASMFDP dump process, or you can use MXG's IMACFILE/MACFILE exit
     to select by SMFTIME, but without that tailoring, MXG simply reads
     the input SMF file(s) to create a PDB data library from all of the
     SMF records in that input.

     If you dump SMF data at 6AM, then your daily PDB will contain the
     only the interval data (e.g., RMF) from 6AM yesterday until 5:59AM
     today, but it will contain the event data (e.g., job completions)
     for more of yesterday's batch processing.  If management wants the
     interval RMF reports to cover midnight to midnight, you can read
     two adjacent PDBs to select only yesterday's twenty-four hours:
       DATA RMFREPORT;
        IF       PUT(TODAY(),WEEKDATE3.)='MON' THEN DO;
          SET SUN.RMFINTRV MON.RMFINTRV;
          IF PUT(DATEPART(STARTIME),WEEKDATE3.)= 'SUN';
        END;
        ELSE IF  PUT(DATEPART(STARTIME),WEEKDATE3.)='TUE' THEN
          SET MON.RMFINTRV TUE.RMFINTRV;
          IF PUT(DATEPART(STARTIME),WEEKDATE3.)= 'MON'
        . . .

     But for the PDB.JOBS data, you would first have to define what you
     mean as "yesterday": all jobs that were read in, or all jobs that
     started execution, or all jobs that started and ended execution, or
     all jobs that were read in, executed, printed, and purges?  What
     about jobs that were read in two days ago and are still running?
     A "Job" is only output into PDB.JOBS when the job has purged, i.e.,
     when ALL of the SMF records for that job (30s, 6s, and 26s) have
     been read, since only then are we guaranteed we have all of the
     records for a job.  But each BUILDPDB also outputs "inflight jobs"
     into the PDB.SPUNJOBS dataset, for all jobs that are still
     incomplete.  So, if you want a tactical report of all jobs,
     completed or inflight, that INITIATED and COMPLETED EXECUTION,
     you would use this logic:
       DATA JOBSREPORT;
        IF       PUT(TODAY(),WEEKDATE3.)='MON' THEN DO;
          SET SUN.JOBS MON.JOBS MON.SPUNJOBS;
          IF PUT(DATEPART(JINITIME),WEEKDATE3.)= 'SUN';
        END;
     because the JINITIME variable comes from the 30-5 Job Terminate SMF
     record.  If you wanted all jobs that INITIATED, you would use the
     variable INITTIME, since it is the minimum initiate time from the
     30-4 step records.  The complete documentation of which datetime
     variables in PDB.JOBS come from which SMF records is to be found in
     the DOCPDB member.


 1.  Processing compressed DB2 V10 SMF Data on ASCII.

     A comparison of the cost of processing compressed DB2 SMF data on
     ASCII (Windows Seven Ultimate), decompressing with the internal SAS
     code algorithm (which has to be use because INFILE exits are not
     supported on ASCII platforms, so the EXITCICS exit cannot be used)
     shows the decompression elapsed time and CPU time is about 2.8 more
     than the cost to process uncompressed records; compression reduced
     the size of the file by a factor of 5, so, as always, compression
     is a tradeoff between space and time (in seconds, below).
       (Note that Newsletter 57 reported the internal SAS algorithm is
       VERY expensive on z/OS, compared with the EXITCICS exit.)

        One Million ID=101 records
           2500MB           500MB
        UNCOMPRESSED      COMPRESSED
        ELAPSED  CPU      ELAPSED CPU
           57      3         19     1   DATA _NULL_;INFILE SMF;INPUT;
          107    100        284   282   %INCLUDE SOURCLIB(TYPEDB2);
           50     97        265   281   Difference (Processing - Read)


III. MVS, a/k/a z/OS, Technical Notes.


10. An IBM-Main posting noted that DFSORT supports large format data
    sets for sortworks, so each can use more than 64K tracks.  DFSORT
    dynamically allocates them as large format, or for //SORTWKnn DD's
    allocated in JCL allocated, you need to specify DSNTYPE=LARGE on the
    DD statements and DFSORT will support that.

 9. Using FTP to Transfer a VB files between two z/OS Systems.
    You must specify the EBCDIC and BLOCK attributes
      type e
      mode b
    or the transferred data file will be corrupted/unreadable.
    Item 20 in MXG Member FTPING has detail documentation and examples
    (from an IBM tech note) for moving VB files between z/OS systems,
    either directly z/OS-to-z/OS, or indirectly through an ASCII
    platform, using either HFS or TSO TRANSMIT/RECEIVE to create an
    intermediate file that can be sent z/OS-???-z/OS.  If you do have to
    use and ASCII platform, I think the better choice that is not in the
    IBM note would be to use TERSE/UNTERSE to create that intermediate
    file, since it would reduce the transfer times to/from/between the
    ASCII systems.

 8.  APAR OA38430 reports RMF CF Activity Report can show the CF
     utilization (% busy) is very low, the service times are high and
     the standard deviations are large.  Where a low % busy around 1%,
     the service times are in the thousands of microseconds and the
     standard deviation may be in seconds.  The CF engines were
     dedicated.

 7.  APAR PM57383 reports SMF 120 subtype 9 user name field in variable
     SM1209ES can sometimes be blank, while that name field is correct
     in subtype 1 records.

 6.  APAR PM58287 reports SMF 117 field IMFLMFNM, which is MXG variable
     S17FMFNM (MESSAGE*FLOW*NAME), is too short at 32 characters.  When
     corrected, this will require an MXG change since the field can not
     be increased in its current place in the middle of the record.

 5.  APAR PM57680 reports changes to SMF 64 record causes the DSD record
     DSNAME field to be incorrect for VSAM datasets.

 4.  Observed: PGM=ADRDSSU, DFDSS backup program does NOT write SMF 42
     subtype 6 records for the INPUT datasets that were backed up; only
     the OUTPUT dataset created SMF records, so there is no tracking of
     which datasets were backed up.  Whether this is intentional or an
     oversight is under query to IBM support.

 3.  APAR PM49660 reports Waiter Information is missing in SMF 79
     Subtype 15.

 2.  APAR PM55328 reports SMF 118 Records with Subtype=0 are written
     even though SMFCONFIG TYPE118 keywords are all set to NO.

 1.  In 2042, the current 8-byte STCK (TODSTAMP8.) datetime value will
     wrap, with a value '17SEP2042:23:53:47.370495'.  In z/OS 1.11, IBM
     introduced the STCKE instruction with a 16-byte output.
       Note: the SMFSTAMP and RMFSTAMP formats will NOT wrap in 2042,
       or ever, as they have a separate date-part with the century bit.
     SAS will eventually provide an extended TODSTAMP16. (?) informat to
     read the STCKE value, but until then, if a vendor creates a record
     with the extended TODSTAMP value, this code can be used to decode
     STCKE now and after 2042.  This example STCKE value is 1.04 seconds
     after the 8-byte STCK would have wrapped:
        '01000000010000000000000000000000'x
     and this code
       FFTOD=INPUT('FFFFFFFFFFFFFFFF'x,TODSTAMP8.)+
            +INPUT('0000000000000001'x,&PIB.8.6)/4096;
       INPUT STCKE1ST &PIB.1. STCKE2ND &PIB.8.6 @;
       IF STCKE1ST=0 AND STCKE2ND=0 THEN STCKE=.;
       ELSE STCKE=STCKE1ST*FFTOD+STCKE2ND/4096;
       FORMAT STCKE DATETIME25.6;
     produced the value of STCKE=17SEP2042:23:53:48.419071

IV.   DB2 Technical Notes.

 4.  Comparisons of creating DB2ACCT, DB2ACCTP and AUDIT records.
     All tests read the same 1787MB SMF file, creating 400,755 DB2ACCT
     observations and 456,617 DB2ACCTP observations, both on tape with
     no sorting, and all T102S140-T102S145 Audit datasets were created,
     but only T102S145 had 4 observations.  A tailored KEEP kept only
     145 variables in DB2ACCT (559 without tailoring) and kept only
     113 variables in DB2ACCTP (168 without tailoring):

         Test    Compress  KEEP Used  CPU Seconds
          1          no       yes       133.8
          2          no        no       151.4
          3         yes       yes       183.4
          4         yes        no       198.8

     As might be expected, reducing variables and disabling COMPRESS
     is the cheapest for the CPU resource (but MAXIMUM for DASD space!),
     and enabling COMPRESS and keeping ALL variables is the most costly
     for CPU, with an increase of 50% over the minimum CPU time.

 3.  Changes to STATIME and SYNCVAL parameters in DB2 Version 10.
     In DB2 Version 10, the interval when statistics records are created
     was changed.  The subsystem parameters STATIME and SYNCVAL apply
     only to IFCID 0105 (T102S105), IFCID 0106 (T102S106), and IFCID
     0199 (T102S199) records.  All other interval statistics records,
     IFCID 0001 (DB2STAT0 and DB2STATR), IFCID 0002 (DB2STAT1, DB2STATB,
     and DB2GBPST), IFCID 0202 (DB2STAT2), IFCID 0217 (T1020217), IFCID
     0225 (DB2ST225) and IFCID 0230 (DB2GBPAT) are no longer controlled
     by STATIME and SYNCVAL, and the corresponding trace records are
     written at fixed, one-minute intervals.


 2.  APAR PM54177 reports that QWACBSC and QWACESC in DB2ACCT dataset
     for Distributed Transactions can contain zero.  APAR text is:
       DB2 accounting logic expects to be called to start an accounting
       interval to record transaction begin times. Some distributed
       client behavior can result in accounting begin being skipped. The
       case is when SET statements are followed by a COMMIT without
       additional SQL. Without the begin accounting call, an accounting
       IFCID3 record will be written with zero begin times upon COMMIT.
       PROBLEM CONCLUSION:
       Accounting has been changed to reject accounting intervals where
       no begin times have been collected. This will eliminate the
       IFCID3 records with QWACBSC and QWACBJST equal to zero.

 1.  APAR PM51653 reports IFCID 239 Class 7 Package Accounting Time is
     incorrect when fetching from a stored procedure result set; the
     error is in QPACTJST or QPACCLS7_ZIIP.


V.   IMS Technical Notes.

 3.  APAR PM27227 reports IMS V12 can fill SMF with type 79 records.

 2.  APAR PM36273 added zAAP/zIIP CPU Usage time in TYPE56FA and TYPE07
     log records; the APAR was supported in MXG 29.29 Change 29.307.

 1.  APAR PM33465 reports STRTTIME is incorrect in IMS 56FA log record
     for IFP Transactions and PWFI and WFI Full Function Transactions.


VI.  SAS Technical Notes.

 7.  Changing the length of MXG variables.

     There are many long-length character variables created by MXG,
     primarily due to open systems text fields, but you can change
     the length of any MXG CHARACTER variable created from SMF data by
     adding a LENGTH statement in your IMACFILE member, or by passing
     that LENGTH statement with the &MACFILE macro variable:

       //SYSIN DD *
        %LET MACFILE=
          %QUOTE( LENGTH
                  VAR1 VAR2 VAR3
                  $8 ;
                 );
        %INCLUDE SOURCLIB(whatever);

     The IMACFILE exit places that LENGTH statement so it is seen first
     by the SAS compiler, prior to the MXG default LENGTH statement; for
     character variables, SAS uses the FIRST instance of LENGTH.

     You can NOT change the LENGTH of a NUMERIC variable in the IMACFILE
     exit nor with &MACFILE, because SAS uses the LAST instance of a
     LENGTH statement for numeric variables, but you can a LENGTH
     statement in the EXdddddd exit member for that record to change a
     numeric variable's length, since that code is seen AFTER the MXG
     LENGTH statement by the SAS compiler.


 6.  SAS WARNING about NLSCOMPATMODE Option.

     This z/OS-only SAS Warning is harmless, including SAS V9.3 in 2012:
       SAS HAS BEEN STARTED IN NLS COMPATIBILITY MODE WITH THE
       NLSCOMPATMODE OPTION. THIS OPTION WILL BE DEPRECATED IN A FUTURE
       RELEASE OF SAS AND NLS COMPATIBILITY MODE WILL NO LONGER BE
       SUPPORTED. FOR MORE INFORMATION, CONTACT A SAS REPRESENTATIVE OR
       TECHNICAL SUPPORT.
     The NLSCOMPATMODE option is set in MXG's CONFIGV9, which is used in
     the MXGSASV9 and MXGSAS92 JCL Procedure Examples, primarily for all
     non-USA sites, as was documented in Change 22.129 (text below).

     However, it is now the "official" recommendation to NOT use either
     of those "old" JCL Procedure Examples, but instead, as contained in
     the MXGSAS93 and INSTALL members, to use the new "MXGNAMES"

        NEW, and documented in Change 27.356, with SAS V9.2 or later:
        YOUR SITE'S standard SAS JCL Procedure can be used for MXG:
          // EXEC SAS,CONFIG='MXG.SOURCLIB(CONFIMXG)'
          //MXGNAMES DD DSN=MXG.USERID.SOURCLIB(MXGNAMES),DISP=SHR
        instead of using the MXGSAS92 JCL Procedure example.
     in part because that new JCL example eliminates the need for the
     NONLSCOMPATMOD option to be set.  Here is the text of 27.356:

     Change 27.356, Jan 17, 2010:

      -The standard SAS JCL procedure can now be used for MXG on z/OS.
       You do not need a separate MXGSASVn JCL procedure; instead, use
       this JCL example (in member JCLMXG), after you EDIT the DSNAMES
       of your MXG Source, MXG "USERID" and MXG Formats datasets into
       your MXGNAMES member in your MXG "USERID" tailoring library:

         // EXEC SAS,CONFIG='MXG.SOURCLIB(CONFIMXG)'
         //MXGNAMES DD DSN=MXG.USERID.SOURCLIB(MXGNAMES),DISP=SHR

       or you can provide the names in the jobstream, with:

         // EXEC SAS,CONFIG='MXG.SOURCLIB(CONFIMXG)'
         //MXGNAMES DD *
          %LET MXGUSER1=HLQ.MXG.USERID;
          %LET MXGSOURC=HLQ.MXG.SOURCLIB;
          %LET MXGFORMT=HLQ.MXG.FORMATS;

      -In addition, the VMXGCNFG macro that was designed by Rich
       allocates the //SOURCLIB with OPEN_ED-1047 encoding; by doing so,
       the setting for NLSCOMPATMODE is moot, and by doing this, all NLS
       sites running with a locale that is non-ENGLISH_UNITEDSTATES will
       never need to worry about NLSCOMPATMODE, so MXG never has to
       worry about those SAS language encoding issues again.

     Change 22.129, Jun 15, 2004, which originally set NONLSCOMPATMODE:

       In SAS V9, the NLSCOMPATMODE option was changed to default to
       NONLSCOMPATMODE, which doesn't fail if your LOCALE option is
       ENGLISH or blank, but with a LOCALE=GERMAN_GERMANY or other
       non-blank and non-ENGLISH value, with the new NONLSCOMPATMODE
       option, every "@" causes this error at compile time:
         ERROR: The name 'A7'x49 is not a valid SAS name.  where that
         'A7'x is a funny looking printed symbol.  (in the VMXGINIT code
         at statement INPUT @49 ....).
       Changing the NONLSCOMPATMODE option back to the V8.2 default of
       NLSCOMPATMODE eliminated the error, so I have added option
       NLSCOMPATMODE to the CONFIGV9 member, as it appears to be safer,
       and I've listed the SAS help note about the option for you to
       read, below.  This note is was added so MXG 22.06 could be
       completed, but it may be revised when I know more about these
       options.

       Specifying LOCALE=GERMAN_GERMANY and NONLSCOMPATMODE did not
       cause a failure using SAS 9.1.2 under Windows/XP.

       The SAS help documentation for NLSCOMPATMODE:

       "NLSCOMPATMODE provides compatibility with previous releases of
       SAS in order to process data in languages other than English,
       which is the default language.  Programs that ran in previous
       releases of SAS will continue to work when NLSCOMPATMODE is set.

       When NONLSCOMPATMODE is in effect, SAS does not support
       substitution characters in SAS syntax.  If you run SAS with
       NONLSCOMPATMODE, you must update existing programs to use
       national characters instead of substitution characters.  For
       example, Danish customers who have substituted the 'Ĺ' for the
       '$' character in existing SAS programs will have to update the
       SAS syntax to use the '$' ("national character") in their
       environments.

       Note:   NLSCOMPATMODE might affect the format of outputs that are
       produced using ODS. If you are using ODS, set the option value to
       NONLSCOMPATMODE."

       There is additional, extensive, documentation of LOCALE and NLS
       in SAS Technical Note TS-653 at www.sas.com.

 5.  Copying and backing up SAS data libraries on z/OS.

     Disk to disk copy - full library copy of all members:
     -PROC COPY always works, but IEBGENER uses much less CPU time than
      SAS.  However, with IEBGENER you lose the audit in the SAS log
      that shows which datasets and how many observations were copied.
      And SAS validates that all MXG-created formats do exist in the
      //LIBRARY DD during the copying.  GENER just copies blocks.
     -Copying a 185 cylinder PDB, IEBGENER used 2.71 CPU seconds while
      PROC COPY used 41.99 CPU seconds for the same data library copy.
      A second test of a single member disk dataset with 100,000 obs in
      DB2ACCT showed a larger disparity between GENER and PROC COPY
      where GENER took .5 seconds and PROC COPY 8.7.  It is likely that
      the time consumed by PROC COPY is a function of the number of
      members in the library being copied, the number of variables in
      each member, and the number of OBS in each member.
     -However, PROC COPY is expensive only when COMPRESS=YES is enabled
      (it is the MXG default), AND ONLY IF the CLONE default is used,
      because CLONE compresses again the already compressed data.
      Instead, specifying PROC COPY NOCLONE for the same PDB took only
      12.1 seconds, and copying that library to another took only 2.81
      seconds, not much different than IEBGENER.  This investigation
      suggests that you should ALWAYS use NOCLONE when you are copying
      within the same SAS platform; only if you are copying from one
      platform to another would CLONE perhaps be required.
     -But neither COPY nor IEBGENER support concatenated data libraries,
      and the output dataset can NOT use DFSMS hardware compression nor
      striping: either will create unreadable output that causes this
      error when the SMS compressed/striped dataset is read:
         ERROR 11 READING LIBRARY DATA SET x TO RETRIEVE LAAS
         LIBRARY x IS NOT IN A VALID FORMAT FOR ACCESS METHOD
     -PROC COPY to an SMS compressed dataset will cause a 213-B8 ABEND
      for every SAS dataset in the library, then followed by error
        ATTEMPT TO OPEN SAS DATA LIBRARY x FAILED
        OPEN TYPE=J FAILED TO POSITION LIBRARY DATASET x TO VOLUME 1
     -DFHSM MIGRATE/BACKUP can also be used to copy SAS data libraries,
      and the recalled dataset will be readable by SAS.

     Disk to tape copy - full library copy of all members:
     -You must use PROC COPY if the library is to be used by SAS, or you
      can use DFHSM to back up the library on tape, but you can NOT use
      IEBGENER to copy a disk SAS data library to tape.
     -Using IEBGENER to copy a disk SAS data library to tape doesn't
      fail during writing, but reading the tape copy causes error:
        LIBRARY x IS NOT IN A VALID FORMAT FOR ACCESS METHOD V9SEQ

 4.  SAS Note 45711. Reported for SAS 9.2, an intermittent ABEND or a
     CPU loop can occur.  Observed with ANALDB2R execution that had
     produced reports correctly and successfully on z/OS, but then the
     job went into a CPU loop that required manual cancellation.

 3.  SAS has opened a defect for LIBNAME using the VOLSER option.  The
     circumvention is to put single quotes around the VOLSER value, so
     VOLSER='123456' syntax will resolve correctly.  When the VOLSER
     value is specified without those quotes, the error message is
          ERROR: Libname OUTDD is not assigned.
          ERROR: Error in the LIBNAME statement.
     with no other clue that VOLSER is the culprit.

 2.  Use of the new JCL to execute the SAS PROC using MXGNAMES/CONFIMXG
     generated this true error message
         ERROR: INSUFFICIENT AUTHORIZATION
         TO ACCESS SYS3.MXG.V3001.LOCAL.SOURCLIB(VMXGINIT).
     but that DSNAME was not the culprit; the site's MXGNAMES had
       %LET MXGUSER1=SYS3.MXG.V3001.LOCAL.SOURCLIB;
       %LET MXGUSER2=XYZ.PERSONAL.SAS.SOURCE;
       %LET MXGSOURC=SYS3.MXG.V3001.SOURCLIB;
       %LET MXGFORMT=SYS3.MXG.V3001.FORMATS;
     and it was actually the MXGUSER2= DSNAME for which this user didn't
     have read access.  With concatenated DSNAMEs, SAS (incorrectly?)
     reports the DSNAME of the FIRST dataset in the concatenation as the
     cause of the error, so if you get this error, just check ALL of the
     DSNAMEs in the concatenation (and with MXG, check both the SOURCLIB
     and SASAUTOS DDs, since SAS also doesn't include the DDNAME in its
     error message.

 1.  SAS Version 9.3 REQUIRES SAS HOT FIX E80004, noted in the CHANGES
     member, but the symptoms were not listed, and it impacts ALL SAS
     platforms.  The macro compiler fails with messages like these:

       ERROR: EXPECTING A VARIABLE NAME AFTER %LET.
       ERROR: SYMBOLIC VARIABLE NAME .... MUST BEGIN WITH A LETTER
              OR UNDERSCORE.
       ERROR: MACRO PARAMETER CONTAINS SYNTAX ERROR.

     See SAS Problem Note SN43828 to install the Hot Fix.


VI.A.  WPS Technical Notes.

 1. Text

VII. CICS Technical Notes.

 1. CICS SMF 110 Subtype 1 (CICSTRAN) records are created automatically
    with OMEGAMON, as that product forces MNPER=ON for you.

VIII. Windows NT Technical Notes.

 1. Text

IX.  z/VM Technical Notes.

 1. Text



X.    Email notes.

 1. Text



XI.   Incompatibilities and Installation of MXG vv.yy.

 1. Incompatibilities introduced in MXG 30.02 (since MXG 30.01):
    See CHANGES.

 2. Installation and re-installation procedures are described in detail
    in member INSTALL (separate sections for each platform, z/OS, WIN,
    or *nix), with examples of common Errors/Warnings messages a new MXG
    user might encounter, and in member JCLINSTT for SAS V9.2 or member
    JCLINSTW for WPS. INSTALL also shows how to read SMF data on PCs/nix
    using the FTP ACCESS METHOD.

XII.  Online Documentation of MXG Software.

    MXG Documentation is now described in member DOCUMENT.


XIIV. Changes Log

--------------------------Changes Log---------------------------------

 You MUST read each Change description to determine if a Change will
 impact your site. All changes have been made in this MXG Library.

 Member CHANGES always identifies the actual version and release of
 MXG Software that is contained in that library.

 The CHANGES selection on our homepage at http://www.MXG.com
 is always the most current information on MXG Software status,
 and is frequently updated.

 Important changes are also posted to the MXG-L ListServer, which is
 also described by a selection on the homepage.  Please subscribe.

 The actual code implementation of some changes in MXG SOURCLIB may be
 different than described in the change text (which might have printed
 only the critical part of the correction that need be made by users).

 Scan each source member named in any impacting change for any comments
 at the beginning of the member for additional documentation, since the
 documentation of new datasets, variables, validation status, and notes,
 are often found in comments in the source members.

Alphabetical list of important changes after MXG VV.RR in MXG VV.RR+1:

  Dataset/
  Member   Change    Description

  See Member CHANGES or CHANGESS in your MXG Source Library, or
  on the homepage www.mxg.com.

Inverse chronological list of all Changes:

Changes 30.yyy thru 30.001 are contained in member CHANGES.


***********************NEWSLETTER FIFTY-NINE****************************




          MXG NEWSLETTER NUMBER FIFTY-NINE, Jan 17, 2012

Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE

                         TABLE OF CONTENTS

I.    MXG Software Version.
II.   MXG Technical Notes
III.  MVS, aka z/OS, Technical Notes
IV.   DB2 Technical Notes.
V.    IMS Technical Notes.
VI.   SAS Technical Notes.
VI.A. WPS Technical Notes.
VII.  CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX.   z/VM Technical Notes.
X.    Email notes.
XI.   Incompatibilities and Installation of MXG.
         See member CHANGES and member INSTALL.
XII.  Online Documentation of MXG Software.
         See member DOCUMENT.
XIII. Changes Log
     Alphabetical list of important changes
     Highlights of Changes  - See Member CHANGES.

     COPYRIGHT (C) 1984,2011 MERRILL CONSULTANTS DALLAS TEXAS USA

I.  The 2012 Annual Version MXG 29.29 is dated Jan 23, 2012.

    You can always use this form
         http://www.mxg.com/Software_Download_Request
    to request the ftp download instructions for the current version.

 1. The current version is MXG 29.29, dated Jan 23, 2012.

    See CHANGES member of MXG Source, or http://www.mxg.com/changes.

II.  MXG Technical Notes

 1.  TYPE 30 CPU times in MXG variables come directly from IBM fields:

        MXG Variable NAME     IBM SMF Manual Field NAME
           CPISRBTM              SMF30ISB
           CPITCBTM              SMF30ISB
           CPUHPTTM              SMF30HPT
           CPUIIPTM              SMF30IIP
           CPURCTTM              SMF30RCT
           CPUSRBTM              SMF30CPS
           CPUTCBTM              SMF30CPT

           CPUTM is the SUM of the above seven CP Engine times.

           CPUZIPTM              SMF30_TIME_ON_ZIIP
             CPUZIPTM (zIIP/zAAP Engine CPU time) is NEVER combined with
             the CP ENGINE CPU times variables (original CPU variables.)
           CPUZIETM              SMF30_ELIGIBLE_TIME_ZIIP_ON_CP
             CPUZIETM is alreacy included in the CPUTM because it is the
             CPU time CONSUMED on the CP engines.

III. MVS, a/k/a z/OS, Technical Notes.

 4. APAR PM54994 for SMF 119 record has been opened; the NIIITIME field
    contains invalid '0000000F000000000'x and '000000001C000000'X values
    in subtype 19 and 21 records.

 3. IBM's TRSMAIN program became AMATERSE in z/OS 1.9: "In z/OS Release
    1.9 the TRSMAIN program has been added to the BCP element of z/OS,
    and it has been redesigned to support large format sequential data
    sets. This program has also been rewritten to follow IBM programming
    conventions.  The new utility is called AMATERSE.  TRSMAIN is
    shipped as an alias entry point to AMATERSE.  When the TRSMAIN entry
    point of AMATERSE is invoked, ddnames INFILE and OUTFILE remain as
    the defaults, so little or no change to JCL should be required to
    take advantage of AMATERSE. The ddnames INFILE and OUTFILE that were
    required by the TRSMAIN utility are replaced by SYSUT1 and SYSUT2
    respectively when the utility is called as AMATERSE."

    All MXG unterse examples use PGM=TRSMAIN and INFILE/OUTFILE DDs, and
    since using PGM=TRSMAIN does execute the new rewritten program, the
    examples were not changed to use PGM=AMATERSE (I assume you'll find
    this technical note if you search for AMATERSE instead of TRSMAIN).

 2. APAR OA37002 reports MKCRTIME and MKLCTIME in SMF 42 subtype 22
    are on GMT zone when the event creating the record is an ADDVRS
    event, but are on local time zone when the event is an DELETEVRS.
    No PTF forthcoming, resolution is FIN ("Fixed in Next").

 1. APAR PM47067 corrects WebSphere Version 8 SMF 120 Subtype 1 error
    that had zero bytes in the SM120SDR, SM120CDR and SM1290EGR fields.

IV.   DB2 Technical Notes.

 1.


V.   IMS Technical Notes.

 2.  How do you enable creation of the IMS56FA Transaction Record?

     IMS logs statistical information about the transactions within a
     unit of recovery (work done by an application program between sync
     points) in log record X'56FA' for non-message-driven applications,
     or when either:
     -The keyword MODE=SNGL is specified in the TRANSACT macro
     -The CMTMODE(SNGL) parameter is specified on a CREATE TRAN or
      UPDATE TRAN command
     IMS logs statistical information about the transactions after each
     message in log record X'56FA' for message-driven applications when
     either:
     -The keyword MODE=MULT is specified in the TRANSACT macro
     -The CMTMODE(MULT) parameter is specified on a CREATE TRAN or
      UPDATE TRAN command
     You can enable or disable this logging on a program basis for
     non-message driven applications, and on a
     transaction-by-transaction basis for message-driven applications.
     Use the following commands to enable or disable this logging on a
     transaction-by-transaction basis:
     -For an existing transaction, issue the UPDATE TRAN or UPDATE
      TRANDESC command and specify the new TRANSTAT() parameter.
     -For a new transaction, issue the CREATE TRAN or CREATE TRANDESC
      command and specify the new TRANSTAT() parameter.
     To enable or disable this logging on a program basis:
     -For an existing application program, issue the UPDATE PGM or
      UPDATE PGMDESC command and specify the new TRANSTAT() parameter.
     -For a new application program, issue the CREATE PGM or CREATE
      PGMDESC command and specify the new TRANSTAT() parameter.
     You can enable or disable this logging globally during system
     definition by specifying a new parameter, TRANSTAT= Y or N, in the
     Diagnostics Statistics section of the new DFSDFxxx PROCLIB member.
     This setting applies to any transactions and application programs
     that are created with the system definition process.
     Any transactions or application programs that are created after an
     IMS cold start using the online change process or the Destination
     Creation exit routine (DFSINSX0, formerly called the Output
     Creation exit routine) inherit the TRANSTAT= parameter setting that
     is specified in the DIAGNOSTICS_STATISTICS section of the DFSDFxxx
     PROCLIB member.
     To determine whether or not this logging is enabled for a given
     transaction or application program, issue one of the following
     type-2 commands:
      QUERY TRAN
      QUERY TRANDESC
      QUERY PGM
      QUERY PGMDESC

 1.  IBM IMS log record IMS56FA comparison with BMC's IMF CIMSTRAN.

  THIS ANALYSIS MAY BE WRONG BECAUSE IBM NOW SAYS APAR PM33425 CORRECTED
  THE IMS56FA CPU TIMES.  THIS NOTE WILL BE UPDATED WHEN NEW IMS LOG
  DATA IS ANALYZED AFTER THE APAR HAS BEEN INSTALLED.  APAR APPLIES TO
  BOTH IMS VERSION 10 AND 11.

  A. CPU TIME and Transaction Count Comparisons:

     BMC IMF created 13,852 transaction records and
         IMF created      6 BMP records.
     IBM IMS56FA had 13,831 records that had MSG GU (NMSGPROC GT 0)
     and IMS56FA had 22,252 BMP records.
     The   IMS56FA  TRAN CPU time was 329.52 in those 13,831 "TRAN"s
       and IMS56FA  BMP  CPU time was  15.61 in those 22,252 "BMP"s
       and IMS56FA "MXG" CPU time was  12.00 captured in ACCUM/RESET,
     Total IMS56FA  CPU TIME time was 357.15 seconds

     Total CIMSTRAN IMF TRAN time was 323.53 in those 13852 "TRAN"s
      and  CIMSTRAN IMF BMP time was    0.02 in those     6 "BMP"s
     Total CIMSTRAN CPU TIME time was 323.55.

     Here is the source of the IMS56FA "MXG" IMS CPU Time:
     If there are Message GET Unique's in a record, NMSGPROC=1 is set as
     this is a "real" transaction record and NMSGPROC should be used to
     to count transactions.  NMSGPROC=0 if there were no MSG GU and this
     is a "NOT-TRAN" record.  Of the 49,778 records, 13,831 were "TRAN".
     Then, 22,256 were BMPs (a "NOT-TRAN", because NMSGPROC=0, TRANSACT
     name is blank, and ARRVTIME is not populated; there were the above
     15.61 CPU Seconds in the BMP records.  The remaining 13,691 56FA
     records totaled 297.11 more CPU seconds, but if added to the other
     56FA CPU times the 56FA would have captured TWICE the IMF CPU time,
     and the IFA CPU Time has always matched the IMS 07 Program CPU Time
     so something else is involved.

     When all of the 56FA records are sequenced by TPOASN and ARRVTIME,
     there were pairs of records for almost every transaction, sometimes
     there were more than two records written.  The last always has
     NMSGPROC=0, a "NOT-TRAN" record, while the first thru penultimate
     have NMSGPROC=1 and are "TRAN" records.  According to IBM Support
     for IMS, these "NOT-TRAN" (second) records:
       Can represents the processing done by the application after it
       received the STATUSQC call for the GU to the IOPCB, indicating
       that there are no further messages and it should terminate.
       Though no messages were processed, IMS still reports the
       processing done so that you can capture any cleanup processing
       done by the application. These "NOT-TRAN" records have values of
       TPMGU=0, TPLTERM=blanks, TPINUTC=0, TPINDATE=X'0000000F', and
       TPINTIME=X'0000000F', meaning that no input message was processed
       during this commit scope, most likely due to QC status on the
       last message GU that was issued.  In this case, the TPCPTERM bit
       would be on in flag byte TPCPFLGS.  This would be a 56FA record
       written during application termination after the application
       terminated upon receiving QC status from its last message GU call
       issued.  However, this type of 56FA log record should not be
       ignored because it still represents processing time performed by
       the application.  The application could have continued to do some
       work after receiving QC status but before terminating and
       returning to IMS.

     So pairs of IMS56FA records were matched up with their IMF record.
     The IMS56FA "TRAN" (first) IMSCPUTM is ALWAYS slightly larger than
     the CPUTM in the IMF transaction (typically about 1 millisecond, so
     IBM's exit point for their transaction record is later than the IMS
     exit that IMF uses!)

     By looking at the sequenced transactions records, the "NOT-TRAN"
     (second) records come with two different contents:
     -Many have IMSCPUTM that is slightly LARGER than the "TRAN" record:
      this flags that this record's CPU Time is ACCUMULATED, and so its
      CPU Time cannot be used "AS-IS", as it contains (DUPLICATES!) the
      CPU time in the preceding "TRAN" record.
     -Many have an IMSCPUTM that is much LESS than the time in the first
      record: this flags that this record's CPU Time was RESET, so the
      CPU Time in these "NOT-TRAN" records are valid.

     Here are the three sequenced CPUTM values in three records for five
     transactions; 1,4 are RESETs and 2,3,5 are ACCUMULATED:

        Transact:      1           2         3         4         5
        IMF         0.133260   0.005130  0.011920  0.007720  0.030480

        56FA TRAN   0.134220   0.005575  0.013168  0.008525  0.031700
           Second   0.004140   0.006284  0.013675  0.000817  0.033420


     So, the new ASUM56FA program sorts IMS56FA data, and assumes that
     if the NOT-TRAN record's IMSCPUTM was LESS than the TRAN record,
     then the CPU clock had been RESET so that value of IMSCPUTM is
     valid and OUTPUT, but if the NOT-TRAN record's IMSCPUTM was MORE
     than the TRAN record, then that record was ACCUMULATED and so the
     delta CPU time from the TRAN (first) record's (stored) IMSCPUTM to
     this NOT-TRAN (second) record's IMSCPUTM is calculated and OUTPUT.

     The sort order is STIMSID IMSUSID TPOASN ARRVTIME ENDTIME with
     each "pair" having the same TPOASN and ARRVTIME values.
     The resultant IMSCPUTM CPU time totals in ASUM56FA dataset are:

                 ==NOT-TRAN==    ====TRAN====    ====Total====
                 Records   CPU   Records   CPU   Records   CPU
     T56FATYP:
      BMP        22252   15.61       0           22252   15.61
      ACCUM       8435    8.73      11     .03    8446    8.77
      RESET       5255    3.26      14     .02    5269    3.29
      FIRST          0           13690  325.29   13690  325.29
      SINGLE         4     .01     116    4.18     121    4.19

        CPU Totals       27.61          329.52          357.15

     By sorting and sequencing to identify RESET from ACCUMULATED, an
     additional 12 seconds of IMS CPU Time was captured; member ASUM56FA
     can be included after TYPEIMST to capture this additional CPU time,
     but that could be a lot of CPU and I/O time to post process IMS56FA
     to capture a few extra seconds.

     So, if you can live without that small amount of CPU time from the
     RESETs and ACCUMs, you can minimize the MXG resource requirements
     for TYPEIMST, using this new EXAMPLE in member TYPEIMST's comments
     that will create ONLY the IMS56FA dataset, and only keeps the 56FA
     records with NMSGPROG GE 1 OR BMP='Y'.

      // EXEC MXGSASV9
      //IMSLOG   DD DSN=YOUR.IMSLOG.DATA,DISP=SHR
      //IMS56FA  DD DSN=YOUR.IMS.IMS56FA.PDB,DISP=(,CATLG)....
      //SYSIN    DD *
       %LET MACKEEP=
         %QUOTE(
           MACRO _IMSVERS 10.1  %
           _NIMS
           _NIMS_56
           MACRO _WIMS56G  &WIMS56G..IMS56FA %
           MACRO _EIMS56G
             IF NMSGPROC GE 1 OR BMP='Y' THEN OUTPUT _WIMS56G;
           %
              );
       %LET WIMS56G=IMS56FA;
       %LET MACIMSH=
          %QUOTE( IF LCODE=56X AND TPCPSSTY='FA'X; ) ;
       %INCLUDE SOURCLIB(TYPEIMST);

  B. CALL differences and equalities:

     There are exact matches of total call counts between IMF and 56FA
     for some Database counters: DELETE, INSERT, REPLACE, PURGE, and for
     these Message counters GET NEXT, GET UNIQUE, and INSERT.  There are
     more buckets for many more call types in 56FA than in IMF, but the
     totals show the counts of calls match quite closely:

                   56FA     GET      GET    GETHOLD     56FA      IMF
                   CALL    HOLD   PARENT    PARENT     TOTAL    TOTAL
        DB GN   125,015     767  225,793    10,417   361,292  363,008
        DB GU   234,519  37,101                      271,620  273,809

                                              total: 632,912  636,817

  C. I/O Reads and Writes:

     IMF provides separate counts for Reads/Writes and KEY/NO-KEP while
     the 56FA provides total Reads and total Writes, that match:

     IMF I/O Counts
        Reads    Reads     Reads     Writes    Writes    Writes
        KEY      NO-KEY    Total     KEY       NO-KEY    Total    TOTAL
       14,203   43,466    57,669     1,163    19,952    21,015    78,684

     IMS 56FA Counts  VSAM Reads                   VSAM Writes
                          57,629                        21,090    78,719

  D.  Miscellaneous

      IMF provides CHARACTER counts transmitted and Virtual Storage used
      metrics that are not provided in IMS56FA.

      IMF provides 11 components of CPUTM, 56FA has only the one total.

      This Log had 260,000 records, 60MB of only FAx and 56x records.
      IMF FAx took 15MB, IBM 56FA took 25MB, and there were 20MB of the
      other unneeded 56x subtypes (5600: 10MB, 5607: 5MB, 5612: 5MB),
      so you should select only LCODE='56FA'x records when you create
      the log file that MXG will read, if you only want IMS56FA data.

VI.  SAS Technical Notes.


 3.  To convert a SAS dataset to EXCEL, use the FILE pulldown and then
     select EXPORT, which usually works, but not when there are too many
     variables for EXCEL to handle.  This alternative has worked so far:

       ODS HTML BODY='c:\db2acct.html';
       PROC PRINT SPLIT='*' DATA=PDB.DB2ACCT;
       RUN;
       ODS HTML CLOSE;

     When the HTML window opens up, right click on the window and one of
     the options given is 'EXPORT TO EXCEL'; click on that and you have
     an EXCEL spreadsheet.


 2.  SAS Problem Note 43996:  An error occurs when you run Merrill
     Consultants' MXG software with SAS® 9.2 reports error messages
       No MKLEs  found
       ERROR: VM 1319: The PCE address=1C351414 and MEMORY= address=
     might occur if a job contain macros that perform only text
     substitution (that is, with no conditional logic), such as jobs
     that use MXG software, with z/OS SAS.
     The circumvention is to NOT use the debugging-only MPRINT option.

 1.  A confusing quirk of the maximum integer value that can be stored
     in SAS variables with stored lengths less than 8 bytes was seen and
     resolved as a "feature" when the value is an exact power of two.
     The table of maximum integer versus stored length is in Newsletter
     TWENTY-EIGHT - Find "3. How can I have 10 digits...." and read that
     note if you are not familiar with how SAS stores numeric variables.
     I discovered that the value of 34,359,738,368 was not truncated in
     ANY length variable, even a variable with length 2 on z/OS or with
     length 3 on PC/unix.  The reason is that the value is exactly 32GB,
     and for values that are 2**X, the SAS floating point representation
       PC/unix: 3 bytes, 11-bit exponent, 22-bit mantissa, 1 sign bit
       z/OS:    2 bytes,  7-bit exponent,  8-bit mantissa, 1 sign bit
     is sufficient for full representation.  But, storing a value that
     is one less than 32GB, 34,359,738,367, the result is truncated:
          length       value        lost in truncation
            8      34,359,738,367            0
            7      34,359,738,367            0
            6      34,359,738,367            0
            5      34,359,738,304           63
            4      34,359,721,984       16,383
            3      34,359,544,064      194,303
          length       value        lost in truncation
            8      34,359,738,367            0
            7      34,359,738,367            0
            6      34,359,738,367            0
            5      34,359,738,352           15
            4      34,359,734,272        3,095
            3      34,358,689,792    1,048,575
            2      34,091,302,912  268,435,455
     So, the table of maximum integer value is a "guaranteed" safe table
     but there are exceptions noted above.

VI.A.  WPS Technical Notes.

 1. Text

VII. CICS Technical Notes.

 1. APAR PM43494 for CICS Transaction Gateway corrects an error that
    wrote multiple statistics records to both the log and the SMF file,
    when a normal shutdown of CICS TG was started while there was still
    work running in progress.  Now, only one record will be written.

VIII. Windows NT Technical Notes.

 1. Text

IX.  z/VM Technical Notes.

 1.



X.    Email notes.

 1. Text



XI.   Incompatibilities and Installation of MXG vv.yy.

 1. Incompatibilities introduced in MXG 29.29 (since MXG 28.28):
    See CHANGES.

 2. Installation and re-installation procedures are described in detail
    in member INSTALL (separate sections for each platform, z/OS, WIN,
    or *nix), with examples of common Errors/Warnings messages a new MXG
    user might encounter, and in member JCLINSTT for SAS V9.2 or member
    JCLINSTW for WPS. INSTALL also shows how to read SMF data on PCs/nix
    using the FTP ACCESS METHOD.

XII.  Online Documentation of MXG Software.

    MXG Documentation is now described in member DOCUMENT.


XIIV. Changes Log

--------------------------Changes Log---------------------------------

 You MUST read each Change description to determine if a Change will
 impact your site. All changes have been made in this MXG Library.

 Member CHANGES always identifies the actual version and release of
 MXG Software that is contained in that library.

 The CHANGES selection on our homepage at http://www.MXG.com
 is always the most current information on MXG Software status,
 and is frequently updated.

 Important changes are also posted to the MXG-L ListServer, which is
 also described by a selection on the homepage.  Please subscribe.

 The actual code implementation of some changes in MXG SOURCLIB may be
 different than described in the change text (which might have printed
 only the critical part of the correction that need be made by users).

 Scan each source member named in any impacting change for any comments
 at the beginning of the member for additional documentation, since the
 documentation of new datasets, variables, validation status, and notes,
 are often found in comments in the source members.

Alphabetical list of important changes after MXG VV.RR in MXG VV.RR+1:

  Dataset/
  Member   Change    Description

  See Member CHANGES or CHANGESS in your MXG Source Library, or
  on the homepage www.mxg.com.

Inverse chronological list of all Changes:

Changes 29.yyy thru 29.001 are contained in member CHANGES.


***********************NEWSLETTER FIFTY-EIGHT***************************




          MXG NEWSLETTER NUMBER FIFTY-EIGHT, Oct  1, 2011.

Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE

                         TABLE OF CONTENTS

I.    MXG Software Version.
II.   MXG Technical Notes
III.  MVS, aka z/OS, Technical Notes
IV.   DB2 Technical Notes.
V.    IMS Technical Notes.
VI.   SAS Technical Notes.
VI.A. WPS Technical Notes.
VII.  CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX.   z/VM Technical Notes.
X.    Email notes.
XI.   Incompatibilities and Installation of MXG.
         See member CHANGES and member INSTALL.
XII.  Online Documentation of MXG Software.
         See member DOCUMENT.
XIII. Changes Log
     Alphabetical list of important changes
     Highlights of Changes  - See Member CHANGES.

     COPYRIGHT (C) 1984,2011 MERRILL CONSULTANTS DALLAS TEXAS USA

I.  The 2011 Annual Version MXG 28.28 was dated Jan 18, 2011, but it was
    replaced by MXG 29.01 dated Feb  4, 2011.
    You can always use this form
         http://www.mxg.com/Software_Download_Request
    to request the ftp download instructions for the current version.

 1. The current version is MXG 29.06, dated Sep  8, 2011.

    See CHANGES member of MXG Source, or http://www.mxg.com/changes.

II.  MXG Technical Notes

 1. Daily BUILDPDB on 8GB 64-bit Intel Duocore E7500 2.93 Ghz,
    Windows Seven Professional 64-bit,
    SAS V9.2 64-bit.

    SMF read:   19,803,835,294 Bytes  @7345KByte/Sec 9,819,991 records
    MXG BUILDPDB "Big data" step:
       1:08:00 elapsed  13:50 total CPU (12:42 User, 1:08 System)
    Total daily run including some reports
       1:27:00 elapsed  22:08 total CPU (20:21 User, 1:47 System)
    Output PDBs:
     CICSTRAN CICSTRAN   4,677,295 obs   3.00 Gigabytes
     PDB                                 3.35 Gigabytes
              DB2ACCT      867,135       1.30 Gigabytes
              DB2ACCTP   1,267,153       0.60 Gigabytes
              TYPE42DS   2,057,402       0.50 Gigabytes
              SMFINTRV     275,725       0.20 Gigabytes
              STEPS        260,484       0.20 Gigabytes
               Rest of PDB               0.55 Gigabytes


III. MVS, a/k/a z/OS, Technical Notes.


14.  CA TSO/MON V6.2 CAUSES MXG JOBS TO FAIL ON z/OS 1.12.
     DO NOT RUN z/OS 1.12 WITH TSO/MON 6.2 WITHOUT THESE APARS.
     IMPACTS ALL APPLICATIONS THAT USE FLOATING POINT INSTRUCTIONS.

     MXG jobs that ran fine on z/OS 1.10 failed when run on z/OS 1.12
     because TSO/MON corrupts the floating point instructions.

     Errors in three separate jobs processing different SMF records:
     - INVALID DATA FOR SMFTIME IN LINE 85041 3-10.
     - ***ERROR. INVALID DB2 PRODUCT HEADER ID=101 QWHSLEN=50370
     - INVALID ARGUMENT TO FUNCTION DATEJUL
     There is no clue in any of these errors that TSO/MON is involved.

     These two APARs for TSO/MON are required to correct:.

     TSO/MON HIPER APAR RO34278 (8/25/2011, was test APAR T5QV357 8/11)
     documents that "Applications using Floating Point registers will
     experience a series of data exceptions followed by an S059 abend.
     SAS applications using 2 dimensional arrays may run into
     subscripting problems Customers experiencing these problems were
     migrating to z/OS 1.12."

     TSO/MON APAR R029589 (Apr 27, 2011), corrects PTF R022614 states:
     "When moving to the z/OS 1.12 operating system, you will experience
     various abends in the TSO user address spaces, as well as other
     applications.  This can sometimes be observed during the data
     recording phase or when TSO users are logging on or off, and when
     batch TSO jobs start. The problem is exacerbated when system
     control blocks are overlaid, which causes the system to become
     unstable."

     Both of these CA APARs are HIPER - which means that if your TSO/MON
     "guru" has signed up for alerts, he/she will have been notified by
     CA of the critical need for these corrections.

     SAS Problem Note 44042 also documents this TSO/MON error.

13. IBM APAR OA24074, documented in MXG Newsletter FIFTY-TWO, changed
    the RMF Report calculation of Percent MVS Busy, by subtracting the
    Hiperdispatch Parked Time SMF70PAT, and MXG's PCTMVSBY was revised
    to match IBM since the Parked Time is NOT a part of capacity.
    But, that APAR did NOT document that IBM chose NOT to also revise
    their calculation of LPAR Busy (PCTCPUBY), but MXG has always
    correctly calculated PCTCPUBY and PCTMVSBY by NOT including the
    parked time in the denominator of capacity.  IBM's choice was just
    recently restated in a PMR which stated:
      With hiperdispatch, RMF changed the way it calculates the MVS busy
      to not take into account parked engines.  This is described in the
      text of APAR OA24074 with an example there of how parked engines
      can affect the MVS BUSY calculation.  However LPAR BUSY does not
      consider whether engines are parked.  This can throw people off,
      especially if there are a large # of engines.  It is one reason
      that you will still want to define some reasonable number of
      logical engines for your LPAR, not necessarily the max possible.
      For example, if you had 32 physical engines on the box,  and an
      LPAR that only ever used a weight equivalent of 4 engines, then
      you might define 8 engines to the LPAR (some number larger than 4
      for a buffer), and let hiperdispatch park some of them.  But you
      might not want to define all 32 to that LPAR.  Even though
      hiperdispatch would park most of them, the reporting which
      includes the parked engines can confuse people if they are not
      expecting it.
    In other words, IBM RMF REPORTS ARE WRONG and do not match the
    more-correct MXG calculations of both PCTCPUBY and NRCPUS, both
    of which take into account the parked time as "not available".

12. APAR OA36831 corrects negative (or very large) values in SMF 74
    fields SMF74SSC, SMF74MEC, SMF74CNN, SMF74PEN and SMF74ATV, in an
    interval with Hyperswap activity.

11. APAR OA35175 new SMFPRMxx SMF parameter DSPSIZMAX for SMF Logstreams
    allows you to specify the maximum amount of storage that each SMF
    logstream data space will consume.  This parameter applies to any
    logstreams specified with the LSNAME or DEFAULTLSNAME keyword which
    does not have this keyword specified as a suboption.  This option
    can not be changed when SMF is active.  If it is attempted to be
    changed message IFA760I will be issued. The default is 2 GigaBytes.
    See MXG Change 29.177 and APAR OA35175 which add data to SMF 23.

10. APAR OA36761 reports correction to variables SM42GRW and SMA2GRW in
    SMF 42 subtype 16 records (TYPE42D1,TYPE42D3 MXG datasets).

 9. Tabulation of IBM Created SMF Records that contain JOB name, with
    list of other accounting fields that are needed or present; Cheryl
    Watson proposed a series of SHARE requirements for each owner of
    SMF records that are used for accounting and cost recovery to add
    the z/OS ACCOUNT fields.  I reviewed and suggested that SYSPLEX is
    now needed for accounting, since you can have multiple instances of
    the same SYSTEM name in a CEC, and that JCTJOBID has always been
    required to fully match JOB-level accounting information, because
    JOB and READTIME are not necessarily unique.  This table shows all
    of the IBM-created SMF records that contain JOB name, with their
    status with regard to the other requested fields, for Cheryl to
    rank for importance and submit to SHARE:

      RECORD     JOB   READTIME JCTJOBID  ACCOUNT SYSPLEX
        6        YES     YES      YES       NEED    NEED
       10        YES     YES      NEED      NEED    NEED
       14/15     YES     YES      NEED      NEED    NEED
       16        YES     YES      NEED      NEED    NEED
       17/18     YES     YES      NEED      NEED    NEED
       21        NEED    NEED     NEED      NEED    NEED
       24        YES     YES      NEED      NEED    NEED
       25        YES     YES      NEED      NEED    NEED
       26        YES     YES      YES       YES     NEED
       30        YES     YES      YES       YES     YES
       32        YES     YES      YES       NEED    YES
       32        YES     YES      NEED      NEED    YES
       36        YES     YES      NEED      NEED    NEED
       40        YES     YES      NEED      NEED    NEED
       41        YES     NEED     NEED      NEED    NEED
       42        YES     YES      YES       NEED    NEED
       57        YES     NEED     YES       NEED    NEED
       59        YES     NEED     YES       YES     NEED
       60        YES     YES      NEED      NEED    NEED
       61/65/66  YES     YES      NEED      NEED    NEED
       62/64     YES     YES      NEED      NEED    NEED
       79        YES     NEED     NEED      NEED    YES
       80        YES     YES      NEED      NEED    NEED
       83        YES     YES      NEED      NEED    NEED
       84        YES     NEED     YES       NEED    NEED
       85        YES     NEED     NEED      NEED    NEED
       90        YES     NEED     YES       NEED    NEED
       91        YES     YES      YES       NEED    NEED
       92        YES     YES      NEED      NEED    NEED
       99        YES     NEED     NEED      NEED    NEED
      103        YES     NEED     NEED      NEED    NEED
      110        YES     YES      NEED      NEED    NEED
      111        YES     NEED     NEED      NEED    NEED
      112        YES     NEED     NEED      NEED    NEED
      113        YES     YES      NEED      NEED    NEED
      114        YES     NEED     NEED      NEED    YES
      119        YES     YES      NEED      NEED    YES
      120        YES     NEED     YES       NEED    YES
      122        YES     NEED     YES       NEED    NEED
      123        YES     NEED     NEED      NEED    NEED

 8.  DSNTYPE=LARGE or Extended Format support in SAS V9.2:

     All the DSNTYPE=LARGE does is allow more than 64k tracks per volume
     to be allocated.  The support could not be put in place till z/OS
     1.7 when EXCP had the ability to address beyond the 64k track limit
     through the TTR, but DSNTYPE=LARGE can be used; see SAS Note 17038.

     Extended Format, Striped, Hardware Compressed z/OS datasets have
     always been useable, but ONLY for "single dataset data libraries in
     sequential format", i.e., your CICSTRAN.CICSTRAN dataset can be
     hardware compressed if written to an EF dataset, but you can't
     really write multiple SAS datasets to that sequential data library,
     since it must be tape format, i.e., with NO directory, so you would
     have to read the entire first dataset to get to or to start writing
     a second dataset to that library.  SAS also refers to these
     datasets as "sequential access bound libraries (tape format) on
     disk", and SAS Note 17038 specifically states that DSNTYPE=LARGE
     can NOT be used for those datasets.
     SAS does not have extended format for a SAS bound library on disk
     because it is not supported by EXCP which is the access method
     service used for SAS I/O for the bound library.  The tape engine
     can be used (and stored on DISK) because this is using BSAM as the
     access method.  SAS thinks that IBM does not intend to extend the
     support to EXCP either, but IBM also said that before DSNTYPE=LARGE
     support existed, but that was then delivered in z/OS 1.7.

 7.  APAR OA35989 corrects a HiperDispatch problem when processors are
     not unparked.  On a large test system that was idle, except for a
     small test partition that is running with HiperDispatch=YES, low
     polarized processors may not be unparked, even though there is
     sufficient demand on the small partition and there is a large
     amount of free capacity on the CEC.
       In module IRABAADJ the free CEC capacity in variable
       VCM_CecCapFree is checked against a limit. The variable is of
       type Fixed(31) and is multiplied by 256 for the compare.  If the
       amount of free CEC capacity is very large, an overflow may occur
       due to this multiplication.  As a result, a very large free CEC
       capacity value may not be recognized and a vertical low processor
       will not be unparked.

 6.  In Nov 2010, APAR OA25831 was installed, PTF UA56641 for z/OS 1.10.
     After the IPL of each LPAR, the total frames (SMF71TFC + SMF71FIN)
     was 261 frames less than the total storage assigned to the
     partition.  Eventually IBM created APARs to correct the problems,
     APAR OA35901 only for z/OS V1.10 (fixed in base of z/OS  V1.12)
     APAR OA35898.  The fix for APAR OA35901 is in the base of z/OS
     V1.12 and the ++APAR fixtest for OA35898 restores the correct total
     frame count.  Most users will probably never notice the error since
     the total number of frames was so small.  SMF71TFC is PVTPOOL and
     SMF71FIN is PVTFPFN in MXG TYPE71 dataset.

 5.  APAR OA33307 is needed for z/OS 1.11; it corrects high CPU time in
     MASTER address space and increased paging.

 4.  APAR PM35809 corrects Average CPU Time in SMF 120 subtype 6 and 8
     interval records, variables SM120WJ4 and SM120JMQ, which w
     accurate because integer arithmetic was losing the remainder.

 3.  There no SMF 30 interval records for the BPXAS address space.
     From a posting to IBM-Main in 2011, an IBM answer, from a prior PMR
     stated:
        Since address space BPXAS creates the spawn or forked address
        space, it will not write any SMF interval records.  The interval
        record will be generated in the name of the forked or spawned
        address space during the processing of that job.   BPXAS is like
        the initiator with no job running in it at that time.

 2.  IBM 'Driver 79' maintenance has affected SMF70CSF (Central Storage)
     with zero values for all LPARs on the physical 2097 CEC, while the
     values on the new z196 LPARs appear to be correct.  IBM's response
     was  "open a hardware record indicating SMF70CSF is zero and you
     will need hardware MCL N24404.008 in Bundle 37.  The hardware
     record is the delivery method for the fix."

 1. APAR OA31856 reports TYPE42DS Read Disconnect Time and Read count
    (S42DSRDD/S42DSRDT) were invalid if an EXCP Channel Program was
    built using a Locate Record Extended, because any writes were
    considered to be reads.

IV.   DB2 Technical Notes.

 5. APAR PM17542 enables DB2 Performance Improvements with z/OS 1.12,
    one of which was to eliminate EXCP/IOTM counting at the DD level in
    DB2 SMF type 30 records by eliminating the DD segments, losing the
    EXCPDASD,EXCPTAPE,EXCPTODD counts at the device-type level.
    However, OA37361 reports that "after PM17542, SMF IO counting at the
    Address Space level are no longer available", which was NOT IBM's
    intention, so this newer APAR reinstates ASID counts, which are the
    EXCPTOTL/IOTMTOTL variables in MXG.
       The Media Manager only records SMF IO counts if the caller
       requested it and a DD token exists.  A data set allocated via
       dynamic allocation with the S99DASUP bit set on, will not
       generate a DD token. Any EXCP/IOTM to those dynamic allocation
       with S99DASUP on will be seen in EXCPTOTL and EXCPNODD but
       will NOT be counted in EXCPTODD.

 4. APAR PM39194 corrected zero values in QWACBSC and QWHSSTCK in
    SYSPLEX Query Parallel Rollup SMF 101 DB2ACCT records.

 3. APAR PM27872 announces sample program DSNTSMFD that decompresses
    DB2 SMF 100, 101, and 102 compressed records (and DSNTEJDS JCL to
    ASM/LKED/run).  There is a limit of 512 DB2 Subsystems, because
    the program reports detail statistics on each subsystem, and the
    program will fail on the 513rd subsystem, but that limit is set
    in DB2_ARRAY_MAX in the sample ASM source code.  Of course, this
    utility is not needed by MXG users on z/OS, since EXITCICS will
    decompress not only the DB2 100,101,102 but also CICS 110 and 112.

 2. APAR PM30468 reports that DB2 zIIP usage for DB2 V10 Prefetch and
    for Deferred Write zIIP direct, is erroneously reported under MSTR,
    instead of DBM1.

 1. APAR II07124 discusses problems in DB2 pausing for 1 to 5 minutes
    while writing SMF records when the (now know to be STUPID default)
    DDCONS=YES is in use, and recommends DDCONS=NO (See item 3.g in MXG
    NEWSLETTER SIXTEEN, "No EXCP data for type 30 subtypes 4 and 5...."
    for MXG's extensive discussion of DDCONS and DETAIL vs NODETAIL
    But this Information APAR adds this note:
    If the DB2 address space is run as a batch job, then the INTERVAL
    and NODETAIL options will have no effect.  If the DB2 address space
    is run as a started task (STC) then either the INTERVAL and NODETAIL
    options must be put on the SYSSTC parameter, or the SYSSTC parameter
    must inherit those options from the SYS parameter.

V.   IMS Technical Notes.

 1. Text


VI.  SAS Technical Notes.

 3. If using Enterprise Guide and you choose a device driver for
    graphics routines you may get a message:
       Insufficient authorization to use yadayada
    Circumvention according to SAS knowledge base is to make the first
    statement
       ODS LISTING CLOSE;

 2. Some TYPE70 variables cannot be dropped when TYPE70 is created,
    because they are used internally in the MXG logic in VMAC7072
    to create the TYPE70PR dataset.  In particular, this error message
    ERROR: VARIABLE LPARWLMG and PARTNCPU IN THE DROP KEEP RENAME LIST
    HAS NEVER BEEN REFERENCED  will occur if you drop those variables.
    a. You could create WORK.TYPE70 with your tailoring, and then use
        PROC SORT NODUP IN=TYPE70 (DROP=LPARWLMG PARTNCPU)
                       OUT=PDB.TYPE70;
        BY _BTY70;
       to DROP those variables from your final PDB.TYPE70 dataset.
    b. However, there is an alternative, for this case, where the MXG
       code that references these two variables is the statement
       MERGE SORT70SP (IN=IN70SP DROP=LPARWLMG PARTNCPU)
             FROM70PR (IN=FROMPR) ....
       You can specify OPTIONS DKRICOND=NOWARN; to prevent the error
       message where these variables are dropped from an INPUT.
    c. To be compete, MXG defaults the OPTIONS DKROCOND=NOWARN; for
       variables in the OUTPUT with Drop/Keep/Rename, because there are
       specific cases where variables are in the KEEP= list that may or
       may not exist. (In CICSTRAN, there are optional segments and
       their variables are in the KEEP= list, but they only exist if
       you have tailored their corresponding IMACICxx member to create
       them, and the DKROCOND=NOWARN value prevents a similar error
       message.
    d. The above case for DKRICOND=NOWARN is the first instance where
       that has been needed, but I'm not prepared to make it also an
       MXG default, at least not from this one instance.

 1. Install of SAS V9.2 for z/OS is rumored to be difficult, but by just
    following the SAS Install Instructions at:
       http://preview.tinyurl.com/443mlpd
    we found that the upload and install of the (7.5 GB) z/OS SAS Depot
    V9.2 SAS/BASE Component (which is all that is required for MXG)
    took less than two hours for a competent systems programmer, even
    one who had not done a z/OS SAS install in many years (BUT ONLY if
    everything needed is already in place!).

    What might be needed to be in place prior to the SAS upload? The
    size of the depot itself will typically vary between 5GB and 17GB
    depending on the mix of products to be installed.  Given that the
    SAS Depot will likely be uploaded to a ZFS filesystem (the other
    option is NFS attached), and with the z/OS restriction of 4GB for
    the size of a (normal) zFS mount point, you will either need the
    authority to define a larger zFS mount point, or be able to use an
    existing zFS mount point(s) large enough for the SAS Installation.
    Either must be created with the SMS Data Class EXTENDED attribute.

    In fact, if you take the most straight forward approach you will
    need two zFS directories of 5GB to 17GB because the SAS Depot stages
    into a second zFS directory (SASHOME) which is used during the
    actual install to z/OS datasets.

    Once the needed zFS space (with EXTENDED attribute) and commensurate
    z/OS space needed for the target DSNs is available it should be
    clear sailing.

    But, one last note, do NOT use that EXTENDED attribute for the Data
    Class of your SAS Data Libraries on z/OS; it is not supported due
    to SAS's use of the EXCP access method.

VI.A.  WPS Technical Notes.

 1. Text

VII. CICS Technical Notes.

 1. Text

VIII. Windows NT Technical Notes.

 1. Text

IX.  z/VM Technical Notes.

 1. z/VM MONWRITE data from two z/VM LPARs was compared with RMF 70 data
    (SMF70CIN=IFL data for both "IFL LPAR" and "IFL PHYSICAL") for this
    four shared-IFL system with 23 hours of matching data.

    RMF only has IFL Utilization for SHARED IFLs WITH WAITCOMPLETE=NO,
    in TYPE70PR,ASUM70PR,ASUM70LP,ASUMCEC, and ASUMCELP datasets.

    For DEDICATED IFL, or SHARED with WAITCOMPLETE=YES, the RMF 70 LPAR
    IFL Utilization is always 100% Busy; for these environments, z/VM
    MONWRITE (TYPEVMXA) must be used to measure IFL utilization.

    The RMF "IFL BUSY" time was 87.31 hours (so the IFLs were busy 94.7%
    of those 23 hours).  Those 87.31 hours of IFL BUSY time are 5239
    minutes, and MONWRITE captured 5182 minutes (98.9%) of that hardware
    busy time.  And of the 57 minutes not captured in MONWRITE, 49
    minutes were the z/OS IFL Management Time.  Or, MONWRITE captured
    all but 7 minutes of the 5189 minutes of the "Effective Dispatch
    Time" recorded by z/OS.

           COMPARISON OF RMF 70 IFL CPU TIME AND MONWRITE CPU TIME

          VMCPU    =  MONWRITE CPU (PFXUTIME+PFXSYSTM)
          IFLACTTM =  RMF Partition CPU Dispatch Time, SMF70CIN='IFL'
                       (both LPAR and PHYSICAL for IFL)
                      *****ONLY VALID FOR SHARED IFLs*****
          DIFF     =  IFLACTTM minus VMCPU
          LCPUMGTM =  LCPUPDTM minus LCPUEDTM
          LCPUPDTM =  Logical/Physical LPAR Partition Dispatch CPU Time
          LCPUEDTM =  Logical/Physical LPAR Effective Dispatch CPU Time

            HR   VMCPU   IFLACTTM  DIFF   LCPUMGTM  LCPUPDTM  LCPUEDTM
               hh:mm:ss hh:mm:ss hh:mm:ss hh:mm:ss  hh:mm:ss  hh:mm:ss
             0  3:45:32  3:48:37  0:03:05  0:02:41   3:48:37   3:45:56
             1  3:31:17  3:34:15  0:02:58  0:02:37   3:34:15   3:31:38
             2  3:52:58  3:55:15  0:02:17  0:02:00   3:55:15   3:53:15
             3  3:57:03  3:58:57  0:01:54  0:01:39   3:58:57   3:57:18
             4  3:56:34  3:58:25  0:01:51  0:01:36   3:58:25   3:56:49
             5  3:47:43  3:49:55  0:02:12  0:01:55   3:49:55   3:48:00
             6  3:38:32  3:41:11  0:02:39  0:02:19   3:41:11   3:38:52
             7  3:39:53  3:42:27  0:02:35  0:02:15   3:42:27   3:40:12
             8  3:44:08  3:46:29  0:02:20  0:02:02   3:46:29   3:44:27
             9  3:45:52  3:48:14  0:02:21  0:02:02   3:48:14   3:46:11
            10  3:52:52  3:54:56  0:02:04  0:01:48   3:54:56   3:53:08
            11  3:54:01  3:56:04  0:02:03  0:01:47   3:56:04   3:54:17
            12  3:48:54  3:51:14  0:02:20  0:02:02   3:51:14   3:49:12
            13  3:41:47  3:44:20  0:02:32  0:02:13   3:44:20   3:42:07
            14  3:43:33  3:46:12  0:02:40  0:02:20   3:46:12   3:43:53
            15  3:33:38  3:36:26  0:02:48  0:02:27   3:36:26   3:33:59
            16  3:34:50  3:37:50  0:03:00  0:02:37   3:37:50   3:35:13
            17  3:47:36  3:49:56  0:02:20  0:02:02   3:49:56   3:47:54
            18  3:48:37  3:50:55  0:02:18  0:02:01   3:50:55   3:48:55
            19  3:28:17  3:31:28  0:03:11  0:02:48   3:31:28   3:28:40
            20  3:44:45  3:47:22  0:02:37  0:02:18   3:47:22   3:45:05
            21  3:47:22  3:50:02  0:02:40  0:02:19   3:50:02   3:47:43
            22  3:56:37  3:58:38  0:02:02  0:01:46   3:58:38   3:56:53
               ======== ======== ========= ========  ========  ========
               86:22:20 87:19:09  0:56:49  0:49:33  87:19:09  86:29:36

 2. MONWRITE does not provide synchronized interval records (yet???).
    The below procedure is only run a IPL time or any situation the
    requires a recycle.  This procedure holds the Monitor START command
    until the next hour boundary, with the hour padded with a zero if
    had only one digit, as the WAKEUP command doesn't support a single
    digit hour.

       /* Make the monitor intervals start on the hour   */
       'CP MONITOR STOP'
       Parse value time('N') with hh ':' mm ':' ss .
       hh=hh+1                      /*Wait for the next hour*/
       If ss=59 then mm=mm+1        /*May need a bit more time*/
       If mm>60 then do             /*Overflow to the hour*/
         mm=mm-60
         hh=hh+1
       end
       If hh<10 then hh = '0'hh
       'WAKEUP' hh':00:00'          /*Wait*/
       'CP MONITOR START'           /*Start the monitor*/



X.    Email notes.

 1. Text



XI.   Incompatibilities and Installation of MXG vv.yy.

 1. Incompatibilities introduced in MXG 29.05 (since MXG 28.28):
    See CHANGES.

 2. Installation and re-installation procedures are described in detail
    in member INSTALL (separate sections for each platform, z/OS, WIN,
    or *nix), with examples of common Errors/Warnings messages a new MXG
    user might encounter, and in member JCLINSTT for SAS V9.2 or member
    JCLINSTW for WPS. INSTALL also shows how to read SMF data on PCs/nix
    using the FTP ACCESS METHOD.

XII.  Online Documentation of MXG Software.

    MXG Documentation is now described in member DOCUMENT.


XIIV. Changes Log

--------------------------Changes Log---------------------------------

 You MUST read each Change description to determine if a Change will
 impact your site. All changes have been made in this MXG Library.

 Member CHANGES always identifies the actual version and release of
 MXG Software that is contained in that library.

 The CHANGES selection on our homepage at http://www.MXG.com
 is always the most current information on MXG Software status,
 and is frequently updated.

 Important changes are also posted to the MXG-L ListServer, which is
 also described by a selection on the homepage.  Please subscribe.

 The actual code implementation of some changes in MXG SOURCLIB may be
 different than described in the change text (which might have printed
 only the critical part of the correction that need be made by users).

 Scan each source member named in any impacting change for any comments
 at the beginning of the member for additional documentation, since the
 documentation of new datasets, variables, validation status, and notes,
 are often found in comments in the source members.

Alphabetical list of important changes after MXG 27.27 now in MXG 29.07:

  Dataset/
  Member   Change    Description

  See Member CHANGES or CHANGESS in your MXG Source Library, or
  on the homepage www.mxg.com.

Inverse chronological list of all Changes:

Changes 29.yyy thru 29.001 are contained in member CHANGES.


***********************NEWSLETTER FIFTY-SEVEN***************************




          MXG NEWSLETTER NUMBER FIFTY-SEVEN, JANUARY, 18, 2011.

Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE

                         TABLE OF CONTENTS

I.    MXG Software Version.
II.   MXG Technical Notes
III.  MVS, aka z/OS, Technical Notes
IV.   DB2 Technical Notes.
V.    IMS Technical Notes.
VI.   SAS Technical Notes.
VI.A. WPS Technical Notes.
VII.  CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX.   z/VM Technical Notes.
X.    Email notes.
XI.   Incompatibilities and Installation of MXG.
         See member CHANGES and member INSTALL.
XII.  Online Documentation of MXG Software.
         See member DOCUMENT.
XIII. Changes Log
     Alphabetical list of important changes
     Highlights of Changes  - See Member CHANGES.

     COPYRIGHT (C) 1984,2011 MERRILL CONSULTANTS DALLAS TEXAS USA

I.  The 2011 Annual Version MXG 28.28 is dated Jan 18, 2011.

    All sites were EMAILED the ftp download instructions on Jan 18, 2011
    The availability announcement was posted to MXG-L.
    IF your email address is in our database AND your license is paid.
    Otherwise, you can always use this form
         http://www.mxg.com/Software_Download_Request
    to request the ftp download instructions for the current version.

 1. The current version is MXG 28.28, dated Jan 18, 2011.

    See CHANGES member of MXG Source, or http://www.mxg.com/changes.

II.  MXG Technical Notes

 2.  Removal of duplicate (SMF) records on z/OS - new ANALDUPE member.

     500,000 SMF Records Processed

     Several techniques for removal of duplicate SMF records on z/OS
     are provided in the new ANALDUPE member.  Two approaches are both
     sort-based but are limited by requirements for MASSIVE amounts of
     disk space or tape drives and require more CPU time than the two
     elegant solutions created by MP Welch, who imagined a solution and
     discovered that the SAS V9 MD5 (digital signature) function could
     be used to create a unique Hash Value for each record, and the Hash
     Values are then sorted (instead of the full record), to MASSIVELY
     reduce the disk and CPU requirements.  A one-pass solution using
     a hash table works fine, but could rapidly exhaust virtual storage,
     so the recommended solution creates the MD5 Hash Value, but then
     uses a second step (freeing temp space of the first step) and a SAS
     Format for the look up table to remove duplicates.

            SORT ONE       SORT TWO       SORT THREE         SORT FOUR
            DISK BASED     TAPE BASED     MD5 HASH FUNCTION  MD5 HASH
            29 SORTWRK     7 TAPE DRIVES  HASH TABLE         SAS FORMAT
            1000 CYL       REQUIRED       ONE PASS           TWO STEP

     CPU     41.40  SEC     49.80  SEC     16.2   SEC        16.2  SEC
     SRB      3.60  SEC      6.60  SEC      0.6   SEC         1.2  SEC
     EXT     31,780 K       31,776 K       43,848 K          50,284 K
     SYS     11,860 K       11,864 K       11,884 K          12,060 K
     EXCP   484,000        463,000         84,000           126,000
     CONN    27.052 SEC     20.40  SEC     15.00  SEC        18.00  SEC
     CLOCK  648.00  SEC   1380.00  SEC     18.00  SEC        42.00  SEC

     Clearly it's much more efficient to hash a record and operate on a
     shorter value than operating on the full record itself. In this
     case, it works particularly well because there is no expectation
     nor requirement to reorder the records.  The Hash table filled 2GB
     of memory at 3.5 million unique records. But the two pass hash will
     handle hundreds of millions of records in most shops.


 1.  Processing Compressed CICS data on z/OS and on Windows.

     An SMF file of 125,712 ID=110 records that created 267,899 CICSTRAN
     transactions was 212 MB when IBM Compression was enabled, and was
     970 MB when uncompressed by the IBM utility DFH$MOLS.  The example
     JCL for CICS decompression is in new DFH$MOLS member in MXG 28.06.

    -On z/OS, three alternatives exist to process compressed CICS data:

     a. Use DFH$MOLS first to uncompress the file and read UNCOMPRESSED.
     b. Use EXITCICS (SAS Infile Exit) to read COMPRESSED WITH EXIT.
     c. Use MXG's internal SAS code to read COMPRESSED WITH INTERNAL.

       Average 7 runs:    Elapsed    TCB    SRB   EXCP  Connect  Size
                           (min)    (min)  (min)         (sec)

      a. DFH$MOLS            .8      .07    .00   53158   11.2  212/970
         UNCOMPRESSED       2.0      .62    .01   47934   11.3   970 MB
             total          2.8      .69    .01  101092   22.5

      b. COMP WITH EXIT     2.3      .70    .00   14549    5.7   212 MB

      c. INTERNAL SAS      22.4     9.88    .00   14554    5.7   212 MB

      As previously reported, the INTERNAL SAS algorithm on z/OS is VERY
      CPU intensive (and it takes a long time, too!).  DFH$MOLS and read
      UNCOMPRESSED is only slightly slower than reading COMPRESSED+EXIT,
      but the uncompressed file needs nearly 5 times the disk space for
      the (temporary) uncompressed file, and I/O activity with DFH$MOLS
      (read compressed, write uncompressed, then read uncompressed) took
      six times the EXCPs and four times the IOTM (Connect Time), so the
      reading of the compressed file with the EXITCICS exit is best.

      Note that executing on z/OS with the ftp access method to read
      data from a different z/OS system CAN NOT use the EXITCICS code.
      The INFILE exit and the ftp access method are mutually exclusive.

    -Executing SAS on Windows/ASCII platforms (which includes using the
     SAS ftp access method), SAS Infile Exits do not exist (and, if they
     existed, the ASM code in EXITCICS couldn't execute on ASCII), so if
     the SMF data file is downloaded and then processed, there are only
     two ways to process compressed CICS data:


     ORIGINAL EXAMPLE - SEE REVISED EXAMPLE IN NEWSLETTER SIXTY-ONE.

     a. Use DFH$MOLS first to uncompress the file and read UNCOMPRESSED.
     c. Use MXG's internal SAS algorithm to read COMPRESSED NO EXIT.

                         Elapsed     User   SYS    Size
      a. DFH$MOLS            .4      .07    .00   212/970
         ftp download       2.0      .04    .00    970 MB
         UNCOMPRESSED        .4      .23    .05    970 MB
           total            2.8      .34    .05

      c. ftp download       0.5      .01    .00    212 MB
         INTERNAL SAS       3.8     2.71    .05    212 MB
           total            4.3     2.75    .05

    The internal algorithm on Windows is only ten times as CPU intensive
    reading the compressed file, compared to reading uncompressed, but
    a lot more disk space is needed for the uncompressed file.

    Unfortunately, at this test site, we were not able to use the SAS
    ftp access method on ASCII to read the uncompressed and compressed
    files directly from z/OS, without download, for that comparison, but
    prior tests using the access method to directly read z/OS files have
    always been cheaper and faster than reading the downloaded files, so
    I would expect that if you can tolerate the temporary disk space on
    z/OS for the uncompressed file, using DFH$MOLS first would be best.



III. MVS, a/k/a z/OS, Technical Notes.

19. APAR OA34480 for z/OS 1.12 RMF III, ERB944I REPORT IS NOT AVAILABLE
    REASON CODE 2, due to an incorrect check for "zFS inactive or
    shutting down.

18. APAR OA34375 provides new function SMARTENDPOINT for IFASMFDL for
    SMF Dumping from Logstreams, and a new keyword SMARTEPOVER so that
    the amount of time that is added to the end date/time to calculate
    the smart end point can be controlled by the user.
    The SMF Manual is updated with these descriptions:

     SMARTENDPOINT      Specifies that processing of input records in
                        the logstream should discontinue once it has
                        been determined that records for all known SIDS
                        contain a date and time that is past the
                        IFASMFDL specified date and time plus the
                        specified SMARTEPOVER value.

                        The default behavior is that IFASMFDL continues
                        to read records all the way to the end of the
                        logstream.

                        This keyword only applies to the DUMP option.

    SMARTEPOVER(hhmm)  Specifies the amount of time that is added to the
                       end date and time to determine the SMARTENDPOINT
                       time.

                       The value specified by hhmm can range from zero
                       (0000) to two hours (0200). The value to specify
                       can be determined by taking the following
                       considerations into account:

                       - If no SIDs are being specified then this value
                         should be set to double the maximum MAXDORM
                         value of any image recording into the
                         logstream. This allows for the best results
                         from SID auto-detection.

                       - If all SIDs are being specified then this value
                         can be minimized down to zero.

                       - If only a single SID is being recorded into
                         this logstream (for example in a DASD-only
                         logstream) then this value can be minimized
                         down to zero.

                       The default for this value is two hours (0200).

                       This keyword only applies when SMARTENDPOINT is
                       specified.


17.  z/OS 1.10 new parameter USEZOSV1R9RULES VSM has no impact on MXG.
     It is a new optional control of allocation of GETMAINs, which MXG
     never issues; that is SAS's job, and the default in DIAG is (YES)
     which means no change from prior allocation scheme.

16.  APAR PM16750 reports invalid BLKSIZE for SMF 42 subtype 6 after
     using the IBM File Manager (FMNQSAM) DSU function with a procedure
     containing REXX CHG_OUT function.

15.  APAR OA34190 reports incorrect capacity data in SMF 30/89/90-34
     when a dynamic processor speed change occurs.

14.  APAR OW47653 lists a number of errors in RMF Post Processor Reports

13.  APAR OA29314 makes no changes, but documents all of the things that
     DO NOT happen with regard to wlm weight management and group
     capacity, especially the (BAD) design that:
        Group capacity will function together with IRD weight management
        as long as the partitions in the group are not subject to
        capping. No weight moves will take place for partitions as long
        as the group is being capped.

12.  APAR OA32067 corrects SMF 42 Subtype 16 with SMF2ADG2=14880, which
     was greater than the LRECL of the SMF record.  The text of the APAR
     is interesting reading!

11.  Duplicate JESNR for OMVS "jobs" in SMF 30 subtype 1,2,3,4 and 5.

     MXG has always used SMF 30 variables READTIME JOB JESNR to identify
     all of the records created by a "job", and JESNR was incremented
     each time a new "job" was read in.  Now, OMVS/USS processes can
     reuse WLM initiators, which retain their JESNR, so the SMF records
     for different OMVS jobs will have the same duplicated JESNR.

     These OMVS jobs creates subtype 1/3/4/5 records.  By using READTIME
     along with JOB and JESNR, these job's SMF records can be grouped to
     identify each job, but only accidentally because the closest values
     of READTIMEs for these duplicate JESNR jobs are 0.09 seconds, and
     READTIME's resolution is 0.01 seconds.  At some point, OMVS jobs
     will have identical READTIME and JESNR for different jobs, and we
     will not be able to identify which SMF records belong to which job.

     For the interval, step terminate, and job terminate SMF 30 records,
     the OMVS Segment has exactly what we need, the OMVS Process ID,
     to identify each OMVS "job"'s unique set of SMF data, but the SMF
     30 subtype 1 job initiate record does not have an OMVS/USS Segment.
     If IBM could add that segment to the job initiate record, or even
     just the PID and perhaps PPID fields, then we would have the data
     to satisfy our billing/chargeback/auditors that we can correctly
     identify the resources and identity of each JOB in z/OS, a feature
     that is unique to the z/OS platform!

     But whether IBM does or does not add that identification data to
     the SMF 30 subtype 1 records for OMVS tasks, I should be able to
     solve the IBM exposure in MXG code, by adding the PID and PPID to
     READTIME JOB JESNR to group the subtype 2/3/4/5 data, and I should
     be able to detect and protect that unlikely instance in the
     BUILDPDB logic when identical Subtype 1 records were created.



     From IBM USS/OMVS support's explanation:

      When a USS application issues a fork or spawn request (and a new
      address space for the request is required), USS will go to pool of
      WLM initiator address spaces to satisfy the fork/spawn request.
      This is done to cut down on the overhead of address space
      creation.
      When a fork/spawn is called, the new process will run in the WLM
      initiator address space if one is available in the WLM init pool.
      If no idle WLM inits are available then a new one is created to
      satisfy the request.
      When the requesting process terminates, the WLM init is returned
      to the pool of WLM inits. There it will wait for a new fork/spawn
      request. If 30 continuous minutes pass and the init is not used
      again, it is ended.  But on a system that with significant USS
      activity, it is more likely that it be re-used before the 30
      (continuous) minutes elapses.

      When a WLM init is re-used, the only thing it retains from the
      previous job is its JOBID.

      The following statements apply to WLM inits and USS:
      - The WLM initiator will keep its JES jobid for its entire
        lifespan (whether it is unused or in use).
      - The JOBNAME associated with a WLM initiator will change when it
        is 'in use'.  When it is idle it will have a JOBNAME of BPXAS
      - WLM initiators are eligible to be re-used when ANY process
        issues a fork/spawn call.

      When a new address space is created as part of a fork/spawn call,
      USS will typically add a numeric suffix to differentiate the
      parent process from the child process. It only does this IF the
      parent process has a jobname of 7 characters or less.  With a
      jobname of 8 characters, USS will not add a numeric suffix to the
      jobname.

      With OMVS processes, each process has a Process ID (PID) and when
      a child process is created, the PID of the Parent is recorded as
      the PPID. You can use this Parent PID (PPID) to find the parent
      that started this process.
         A PPID of 1 is special as that is BPXOINIT. That means the
         original parent has ended and the child is now an orphan.
         The PPID is set to 1 which is BPXOINIT in this case.
         The command D OMVS,A=ALL displays the PID and PPID for each
         OMVS process so you can see how to chain back thru the PPID to
         the parent process and if it has a PPID then back to that
         parent and so on.


     From IBM USS/OMVS support's explanation:

      When a USS application issues a fork or spawn request (and a new
      address space for the request is required), USS will go to pool of
      WLM initiator address spaces to satisfy the fork/spawn request.
      This is done to cut down on the overhead of address space
      creation.
      When a fork/spawn is called, the new process will run in the WLM
      initiator address space if one is available in the WLM init pool.
      If no idle WLM inits are available then a new one is created to
      satisfy the request.
      When the requesting process terminates, the WLM init is returned
      to the pool of WLM inits. There it will wait for a new fork/spawn
      request. If 30 continuous minutes pass and the init is not used
      again, it is ended.  But on a system that with significant USS
      activity, it is more likely that it be re-used before the 30
      (continuous) minutes elapses.

      When a WLM init is re-used, the only thing it retains from the
      previous job is its JOBID.

      The following statements apply to WLM inits and USS:
      - The WLM initiator will keep its JES jobid for its entire
        lifespan (whether it is unused or in use).
      - The JOBNAME associated with a WLM initiator will change when it
        is 'in use'.  When it is idle it will have a JOBNAME of BPXAS
      - WLM initiators are eligible to be re-used when ANY process
        issues a fork/spawn call.

      When a new address space is created as part of a fork/spawn call,
      USS will typically add a numeric suffix to differentiate the
      parent process from the child process. It only does this IF the
      parent process has a jobname of 7 characters or less.  With a
      jobname of 8 characters, USS will not add a numeric suffix to the
      jobname.

      With OMVS processes, each process has a Process ID (PID) and when
      a child process is created, the PID of the Parent is recorded as
      the PPID. You can use this Parent PID (PPID) to find the parent
      that started this process.
         A PPID of 1 is special as that is BPXOINIT. That means the
         original parent has ended and the child is now an orphan.
         The PPID is set to 1 which is BPXOINIT in this case.
         The command D OMVS,A=ALL displays the PID and PPID for each
         OMVS process so you can see how to chain back thru the PPID to
         the parent process and if it has a PPID then back to that
         parent and so on.


10.  Impact of NO REGION versus REGION on JOB and STEP JCL statements.

      REGION         REGION    REGREQST in TYPE30_4
      on JOB         on STEP    that the step
      "CARD"  step   "CARD"     received

       none  step 1   none       64M <- IEFUSI site limit no REGION
       none  step 1   100M      100M
        0M   step 1   none       10M <- IEFUSI site limit for 0M
       100M  step 1   none      100M
       100M  step 1   400M      100M

       none  step 1    10M       10M
       none  step 2   100M      100M
       none  step 3   400M      400M
       none  step 4    40M       40M
       none  step 5    64M       64M


 9.  APAR OA34261 corrects error in RMCTADJN (MXG R723NADJ) when running
     at reduced speed, (e.g., due to Power Save Mode).  In control block
     IRARMCT, module IRAEVSSI may return incorrect values due to
     rounding problems when the machine is running at reduced speed.
        Instead of computing RMCTADJN from RMCTADJC proportionally to
        the ratio of actual and nominal CPU capability, module IRAEVSSI
        has been changed to calculate RMCTADJN similar to RMCTADJC by
        applying the MP factors to the nominal CPU capability.  D/T2817

 8.  APAR OA34576 documents that false contention values may differ
     between SMF 74, SMF 42, and the D SMS,CFLS command results.
        False Contention is recorded by XCF when it detects multiple
        values hashing to same entry in a coupling facility lock
        structure.  When this is detected a counter is incremented
        internally, and passed to RMF(SMF 74) via macro call.  The
        requestor of the lock will be notified of false contention via
        the completion exit once the request has been satisfied.  False
        contention can occur on IXLLOCK, IXLALTER, or IXLRELEASE calls.
        When a request hits contention, it becomes globally managed by
        XCF.  If it was incorrectly in contention and the global manager
        runs the request it is marked in False Contention.  Thus even
        release requests can incur false contention counts.
        But, in SMSVSAM's (SMF 42 and the D SMS command), only lock or
        alter requests have their values recorded for false contention,
        while Release requests are ignored.
        SMF 74s may have higher false contention counts than SMF 42.
     LOCAL FIX:
        Use RMF and SMF 74's to keep track of false contention values.
        False contention can occur during release request.
        Currently, SMF42 only records lock and alter requests.
        Due to skipping the release requests, SMF74 false contention
        values are higher than the SMF42 records.

 7.   APAR OA33682 addresses Page Fixing Storage issues between 16M-2G.


 6.   APAR OA33527 reports Logical OUT and READY count in RMF 70s can be
      wrong in z/OS 1.11.

 5.   APAR OA31895 corrects an error in RMF 73 records (although the
      text only mentions corrections to the RMF IOQ Report) that when
      Channel Paths are added dynamically, they are not recorded.

 4.   APAR OA30563 and z/OS 1.12 added the MAXEVENTINTRECS parameter in
      SMFPRM to determine if type 30 and type 89 interval records will
      be generated when the processor capacity is changed.  This could
      be important for billing issues, since the CPU times recorded are
      potentially impacted by a capacity change.  The default value of
      MAXEVENTINTRECS is zero, so no event driven interval records are
      created when capacity is changed.  If non-zero, the value limits
      the maximum number of event driven interval records allowed during
      a regular scheduled interval. The capacity changes are recorded in
      SMF70CCR and can be due to POWERSAVE or CYCLESTEERING or EXTERNAL.

 3.   APAR OA34007 reports SMF30 TIME_ON_ZIIP can be negative in subtype
      3 records; this caused LARGE values in CPUZIPTM.

 2.   APAR OA33712 reports SMF64DAU and SMF64RLM were swapped, but now
      are correct.  OA33712 is an AE fix completion for OA33315.

 1.   APAR OA33841 corrects SMF 14/15 error; CLOSTIME/SMF30OPD was set
      incorrectly to zero time if OPENTIME/SMF30OPE was midnight, i.e.
      exactly zero time.

IV.   DB2 Technical Notes.

 2. How do you find out who deleted/dropped a DB2 database/table.

    If you had the DDL Audit Trace enabled it is easy.
         %ANALDB2F(PMACC01=NO,PMACC02=NO,PMSTA01=NO,
                   PMAUD02=YES,AUDIT=DDL);
    will print those events.

    But even if trace is not enabled, it still can be done:
    Looking at the TYPE6156 records, selecting the zOS dataset name:

      PROC PRINT DATA=TYPE6156 (WHERE=(ENTRNAME='whatever.yours'));
      VARIABLES SMFTIME JOB ENTRNAME ACTION;

    you can find the time when the zOS datasets were deleted, but they
    will show the job name of the DB2*DBM1 address space as the user.
    Then looking at DB2ACCT records in the same time period with
    QXDRPDB OR QXDRPTA OR QXDRPIC GT 0:

      PROC PRINT DATA=DB2ACCT.DB2ACCT  (where=
      (   (qxdrpdb gt 0 or qxdrpta gt 0 or qxdrpic gt 0)
                          and
         ('18NOV2010:12:30:45.99'DT LE QWHSSTCK LE
          '18NOV2010:12:40:55.11'DT)  ));
      VARIABLES QWHCAID QWACBSC QWACESC QXDRPDB QXDRPTA QXDRPIX;

    will show the RACFUSER that did the dirty deed in QWHCAID;

 1. APAR PM17542.  DD Segments NOT WRITTEN as part of DB2 Performance
    Improvements in z/OS 1.12.
       DB2 exploits z/OS 1.12 new allocation functions to improve the
       performance of allocation, deallocation, open, and close of the
       data sets in DB2 page sets.  It will improve the performance when
       opening a large number of data sets concurrently, and shutdown
       time, especially for DB2 users with high DSMAX.  Significant
       reduction in elapsed time has been observed by DB2 and z/OS
       performance test.  Allocation will manage DB2 data set ENQs in
       memory, and SUPPRESS CERTAIN DB2 DD-LEVEL ACCOUNTING IN THE SMF
       records to save significant overhead.
          ATTENTION to DB2 DBA and system programmers:
          To make the APAR effective:
           - Update the ALLOCxx parmlib member to set
                SYSTEM MEMDSENQMGMT(ENABLE).
           - or issue command SETALLOC SYSTEM,MEMDSENQMGMT=ENABLE.
          Updating the ALLOCxx parmlib is strongly recommended as it
          remains effective across IPLs.  If the SETALLOC command is
          used to enable SYSTEM MEMDSENQMGMT, a DB2 restart is required
          to make the change effective.
       "Suppress CERTAIN DB2 DD-LEVEL ACCOUNTING" means that DB2 with
       this APAR sets the new S99DASUP bit, described in MVS Programming
       Authorized Assembler Services Guide:
          S99DASUP    Used by authorized programs to suppress the
          DD-level accounting. Setting this bit can affect the SMF
          data created for the following:
             The EXCP section of SMF Record Type 30.
             SMF Record Type 40.
             SMF Record Type 14 for the fields SMF14NTR and SMF14NER.
          This bit is only recommended for programs allocating VSAM data
          sets with generated DD names, or when the exploiting program
          has established that the usefulness of the SMF data is less
          than the benefit to system performance.  Because the data is
          used by an installation and suppressed by the exploiting
          program, an external switch controlling the program's use of
          this bit is strongly recommended.
       But the Services Guide is unclear (are ALL DD Segments suppressed
       or is S99DASUP set for individual DD's), but Bob Rogers' SHARE
       presentation added information:
         Suppress DD accounting (in SMF 30 records)
           Suppresses creation of SMF Type 30 EXCP section data on
              a per-DD basis
           Reduces CPU in Allocation and Unallocation processes
           Requested by program with S99DASUP flag on DynAlloc
       S99DASUP is set ONLY for Selected Dynamically Allocated DD's.
       But, thanks to Merrill Consultant's IBM "TLC" Technical liasion
       Consultant in Poughkeepsie, who contacted the author of the APAR,
       she has confirmed that the APAR suppresses all Database Dataset
       Dynamic Allocation Requests in the DBM1 Address Space, so when
       enabled, SMF 30 records for DBM1 will not contain DD segments
       for those allocations.

V.   IMS Technical Notes.

 1.


VI.  SAS Technical Notes.

 2. Using SAS Enterprise Guide 4.2 or earlier with ANALDB2R, the
    standard SAS report can fail to open when there exist unprintable
    characters in DB2 data.  You may see some of the report if you
    invoke HTML output, but in that HTML report you may see reams of
    blank pages.  SAS Support said that EG 4.22 had added new data
    cleansing functionality that would resolve the errors, adding:
    To use this functionality, you must first bring the data down to
    your PC, then use the "file > import" menu option in EG. After
    importing the data, run your code against the newly imported data.
    See also SAS Note http://support.sas.com/kb/32/133.html.
    There are DB2 variables with mixed valid EBCDIC and HEX values.
       Wherever possible, MXG changes '00'x in EBCDIC text fields to a
       blank, because IBM initialized text fields with '00'x.  Or, MXG
       formats all-hex variables with $HEX format so they are printable.
       But mixed fields can start with a useful EBCDIC text (netname)
       followed by a TODSTAMP in hex aren't formatted $HEX because that
       would make the useful EBCDIC name unreadable (except to certain
       hex'd sysprogs!).
    See member UTILNPRT in MXG 28.08 to identify all variables in all
    SAS datasets that have non-printable character values.

 1. z/OS SAS Version 9 USER ABEND U0998-16D is actually ABEND 16D RC 8
    and only occurred on a system where the SAS write-SMF-record exit
    was installed, but the SAS Load Library module was not copied over
    when a SYSRES was cloned.


VI.A.  WPS Technical Notes.

 1. X

VII. CICS Technical Notes.

 1.

VIII. Windows NT Technical Notes.

 1. Using MicroSoft Security Essential, MSE, causes various errors when
    the MXG QA job is run, never at the same place in the job:

    ERROR: User does not have appropriate authorization level for
           library WORK.
           Followed, sometimes, with a second error:
           FATAL: Code generation error detected during BY compare
           generation.
    ERROR: File Deletion Failed For MXGSUM1  (after prior successes).
    ERROR: An I/O error has occurred on file WORK._tf6737.UTILITY.
    ERROR: An I/O error has occurred on file WORK.OPTVAR.DATA.
    ERROR: Rename of temporary member for WORK.OPTVAR.DATA failed.
    ERROR: Rename of temporary member for WORK.TMVSCH.DATA failed.

    Only by disabling MSE Settings to:
      -exclude the SAS.EXE process
      -exclude files *.sas7bdat and to
      -exclude the c:\qa\ directory, where all output was written, AND
      -exclude the c:\sastemp\ "WORK" directory.
    were both errors were eliminated.

    However, that "does not have appropriate authorization level" error
    can also occur, especially with Windows 7, without MSE, when your
    program is attempting to write to the root directory or to the
    Program Files directory, especially when not executing your program
    "as administrator".

    This issue had been open with SAS Institute and Microsoft support
    since February, 2010; finally, in October, a new MicroSoft "Senior
    Escalation Engineer" attempted resolution, providing instructions
    to install several MicroSoft diagnostics tools that either failed to
    initialize or failed to capture the event data, including runs with
    TTTracer that generated over 85 GigaBytes of trace (how do you send
    a file that big??) that still did not capture anything of use to MS.
    Then, out of the blue, in November, 2010, fourteen updates were auto
    installed by MicroSoft autoupdate, and the error went away.  The MS
    escalation engineer was unable to identify which update corrected.

    Moral: Disable MSE for SAS.

    Update: May, 2011.
    RUN SAS AS ADMINISTRATOR.
    Starting with SP1 for Windows 7, writing to any sub-directory under
    c:\PROGRAM FILES is restricted, with NOT AUTHORIZED error messages,
    unless SAS is RUN AS ADMINISTRATOR.  This is where the default SAS
    root directory is located, which is where xxx.log and xxx.lst files
    are created by default.
    A Windows 7 system that does NOT have SP1 and its recent updates
    does not restrict saving/writing into the SAS root directory here.

    Update: May, 2011.
    Disable Microsoft Security Essentials, again.
    After autoinstall of SP1 for Windows 7, the above MSE error has
    reoccurred, and in some cases, even using the above settings was
    not sufficient; MSE real-time monitoring had to be turned off for
    the full MXG QA job to complete.  These errors occur at different
    times and places in the 33 minute QA job, and always involves a
    file in the WORK library that is being written to, or is being
    deleted (MXGSUM1) or is being renamed (OPTVAR), in the QA run with
    zero observations.

    These errors with MSE and authorization are on 64 bit Windows 7
    Ultimate on 64 bit hardware with 64 bit SAS, on two separate
    machines; on two more machines that do NOT have SP1, these errors
    do NOT occur.

IX.  z/VM Technical Notes.

 1.

X.    Email notes.

 1.  X



XI.   Incompatibilities and Installation of MXG vv.yy.

 1. Incompatibilities introduced in MXG 28.28 (since MXG 27.27):
    See CHANGES.

 2. Installation and re-installation procedures are described in detail
    in member INSTALL (separate sections for each platform, z/OS, WIN,
    or *nix), with examples of common Errors/Warnings messages a new MXG
    user might encounter, and in member JCLINSTT for SAS V9.2 or member
    JCLINSTW for WPS. INSTALL also shows how to read SMF data on PCs/nix
    using the FTP ACCESS METHOD.

XII.  Online Documentation of MXG Software.

    MXG Documentation is now described in member DOCUMENT.


XIIV. Changes Log

--------------------------Changes Log---------------------------------

 You MUST read each Change description to determine if a Change will
 impact your site. All changes have been made in this MXG Library.

 Member CHANGES always identifies the actual version and release of
 MXG Software that is contained in that library.

 The CHANGES selection on our homepage at http://www.MXG.com
 is always the most current information on MXG Software status,
 and is frequently updated.

 Important changes are also posted to the MXG-L ListServer, which is
 also described by a selection on the homepage.  Please subscribe.

 The actual code implementation of some changes in MXG SOURCLIB may be
 different than described in the change text (which might have printed
 only the critical part of the correction that need be made by users).

 Scan each source member named in any impacting change for any comments
 at the beginning of the member for additional documentation, since the
 documentation of new datasets, variables, validation status, and notes,
 are often found in comments in the source members.

Alphabetical list of important changes after MXG 27.27 now in MXG 28.28:

  Dataset/
  Member   Change    Description

  See Member CHANGES or CHANGESS in your MXG Source Library, or
  on the homepage www.mxg.com.

Inverse chronological list of all Changes:

Changes 28.yyy thru 28.001 are contained in member CHANGES.


***********************NEWSLETTER FIFTY-SIX*****************************




          MXG NEWSLETTER NUMBER FIFTY-SIX AUGUST 18, 2010.

Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE

                         TABLE OF CONTENTS

I.    MXG Software Version.
II.   MXG Technical Notes
III.  MVS, aka z/OS, Technical Notes
IV.   DB2 Technical Notes.
V.    IMS Technical Notes.
VI.   SAS Technical Notes.
VI.A. WPS Technical Notes.
VII.  CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX.   z/VM Technical Notes.
X.    Email notes.
XI.   Incompatibilities and Installation of MXG.
         See member CHANGES and member INSTALL.
XII.  Online Documentation of MXG Software.
         See member DOCUMENT.
XIII. Changes Log
     Alphabetical list of important changes
     Highlights of Changes - See Member CHANGES or www.mxg.com/changes

     COPYRIGHT (C) 1984,2010 MERRILL CONSULTANTS DALLAS TEXAS USA

I.  The 2010 Annual Version MXG 27.27 was dated Jan 20, 2010.

    All sites were mailed a letter with the ftp download instructions.
    The availability announcement was posted to both MXG-L and ITSV-L.
    You can always request the current version using the form at
         http://www.mxg.com/Software_Download_Request

 1. The current version is MXG 28.05, dated Aug 18, 2010.

    See CHANGES member of MXG Source, or http://www.mxg.com/changes.

II.  MXG Technical Notes

 2. The OPTION USER=PDB (or USER=ANYTHING) should not be used with MXG.
    If you set that option in tailoring code that is executed AFTER the
    VMXGINIT has initialized MXG, WITHOUT REINVOKING %VMXGINIT; there
    can be strange errors (like obs to PDB.ZZxxxxxx temporary datasets)
    because MXG doesn't see that you have changed the option.
    While resetting the USER= option might work most of the time, there
    are MXG programs (especially reports) that will fail if USER=WORK
    (the default) is not in effect.

 1. Using ASUMUOW can cause a Condition Code 4 Return Code 4 if you do
    not have MQ data.  You MUST modify your ASUMUOW member to
     - deleting the line with    _SUOWMQ
     - adding statement          %LET MXGMQADD=NO;

III. MVS, a/k/a z/OS, Technical Notes.

26. APAR OA29367 - Gryphon Support, Websphere Portal for z/OS.
    New support is provided for the IBM zEnterprise 196 (z196) processor
    family with D/T2817 models M15, M32, M49, M66, M80.
     Characteristics:
     - New channel path types OSX and OSM for the data transfer and
       management with the BladeCenter zBX.
     - Support of an additional subchannel set, SCHSET 2.
     - Support of 128 coupling facility channels.
     - Support of 32 hipersocket channels.
     In addition to this function, the following enhancements are
     shipped:
     - The possibility to over-define CF CIB channel path connections
       between a stand-alone CF CEC and an OS CEC.


25. APAR OA32935 provides SRM Support for greater than 64 physical
    processors on a CEC, citing all users of an IBM zEnterprise 196.
    Support for OA32935 was delivered in MXG 28.04 in Change 28.143.

24. APAR OA33358 reports slow zIIP assisted IQDIO transfer speed, for
    users running zIIP_assisted IQDIO Multiwrite (SIGA-wm) traffic.

23. APAR PK72057 reports SDSF reporting of CPU Usage for Individual
    Address Spaces is incorrect; the MVS CPU% in the DA panel may not
    add up to the CPU usage shown in the DA title line; the error is
    only for the "DA panel using RMF" (ISFDAR/ISFDAR1).  SDSF gets CPU
    usage for individual address spaces from RMF and then normalizes the
    value based on total CPU usage.  The problem is SDSF is using the
    LPAR CPU usage and not the MVS CPU usage.  As a result, the
    individual CPU% values may not add to be equal to or close to the
    DA title line CPU usage. Corrected in the SDSF in base z/OS 1.11.

22. APAR OA33049 reports high CPU consumption in GRS Address Space while
    RMF III ZFS option is on; after RSU 0910, CPU consumption by GRS was
    doubled.

21. APAR PM18254 (WebSphere) reports SMF 120 Subtype 9 records can be
    missing the Security Data if a self-contained WEB Module (.war file)
    was not packaged within an .ear file.

20. APAR OA33399 reports the NOHONORIEFUSIREGION option only works for
    the first step in a multi-step STC or JOB.

19. APAR OA33696 will permit IFASMFDP to run unauthorized.  Two recent
    APARS, OA29894 and OA32258, have forced IFASMFDP user exits to run
    in APF authorized mode; with this APAR, it is possible to run
    IFASMFP non-authorized, and thus the user exists also run as such.

18. APAR OA33523 reports SMF 42 subtype 16 records sometimes indicate
    GT4KNOTACTIVE when >4K Caching is enabled.

17. APAR OA32169 reports invalid values ("negative" for SMF30OST, MXG
    variable OMVSOST, CPU TIME ACCUMULATED BY SYSCALLS if the USS
    parameter SYSCALL_COUNT is toggled.

16. Change 11.338 added these new fields to TYPE42DS (SMF 42 subtype 6):
      S42AMZRB   Number of directory reads
      S42AMZWB   Number of directory writes
    but they were not yet populated, because "The directory counts do
    not include STOW or BLDL yet, and there's more design ongoing to
    capture as much as possible (eg., VIO and PDSEs)."
    Now, 17 years after those fields were added, an ETR was opened with
    IBM Support because those fields were still zero; their replies:

      Action taken:
       Reviewed ETR, no known issue in this area.
       Reviewed source code, but, could not locate where these values
       are updated.
      Action plan:  Discuss with defect support.
        ...
      I was able to locate this Q&A item:
      RTA000142416
      IBM STATUS:
      Could you tell me when we should expect to see any value in the
      field S42AMZRB of the SMF TYPE42 subtype6 records?  This customer
      finds that this field is always zero, even for pds's.
      IBM STATUS:
      CMM only builds the SMF42 record from information supplied by
      other components.
        ...
      IBM STATUS:
      As it turns out it was significant that I couldn't find where this
      field gets updated.  It doesn't.  There are plans to put code into
      BLDL (for directory reads) and STOW (for directory writes), but it
      hasn't been done yet.  Sorry for the confusion in the
      documentation.  I have marked this PMR for inclusion in the ASKQ
      data base so at least if someone else has the same problem they
      will be able to find it.
        ...
      I am still waiting for a confirmation from the change team that
      this is still valid.
    This Technical Note will be updated if/when an APAR exists that
    populates those fields.

15. APAR OA31800 reports RMF monitoring metrics prefixed with CPC_ are
    no longer zeros when RMF is stopped or restarted.

14. APAR OA32286 reports z/OS 1.11, ONLY with HiperDispatch, has high
    LPAR Management CPU time and/or high Uncaptured Time, and most
    noticeably on systems where processors are frequently in "no work"
    waits.  The presence of undispatchable asynchronous exit WEB blocks
    on an otherwise quiet WUQ magnifies the problem.  The APAR text has
    verification instructions to confirm the error exists.
    The current status local fix: Turn Off HiperDispatch.

13. APAR OA31417 corrects the Average Used Slots variable SMF75AVU,
    which was too low when large page datasets are used and Monitor I
    runs with a very small CYCLE time (e.g., 100 milliseconds).

12. APAR PM05716 corrects SMF119 datetime variable TIESTCK in dataset
    TYP11902 to now include Leap Seconds, so that end time is greater
    than the TISSTCK start time.

11. APAR OA32123 reports RMF Monitor III SYSWKM report does not
    correctly report the address spaces that are serving the particular
    service class.  Pending a PTF, refreshing the WLM policy will cause
    the control blocks to be correctly rebuilt.

10. APAR OA31325 reports RMF Monitor III (ASMRMFV/TYPERMFV) DEVR report
    shows invalid DSC$, CON%, with both greater than 100%.

 9. APAR PK87712 for SMF 120 Subtype 9 records corrects the Process ID
    of the Servant PID.

 8. APAR OA31055 reports Concurrent Copy in z/OS 1.10 causes system-
    wide performance degradation, longer run times, etc., and claims
    the problem is fixed by disabling the creation of SMF 42 subtype 4
    records for CC, Snapshot, and VCC.  The APAR is HIPER.

 7. Current 8-byte TODSTAMP format will wrap in year 2041; in 1998, IBM
    defined a 16-byte "ETOD" datetimestamp to support dates beyond 2041,
    now required in the RACF Database for Certificate End dates, but the
    RACF DataBase will store the first 8 bytes of "ETOD" into existing
    8-byte TODSTAMP field.  The first byte of the 16-byte ETOD format
    will contain '38'x if the actual field is in ETOD format, or will
    be less than '38'x if the actual field value is in TOD format.

 6. APAR OA31072 reports High CPU used by CPM, Capacity Provisioning
    Manager, due to Java garbage collections in CPM ASID, and this
    excess CPU demand can cause significant overflow of zAAP eligible
    work to CP engines. The PTF changes the REGION and HEAP SIZES.

 5. APAR PK95003 indicates the zAAP CPU time will be added to the
    SMF 120 records "in a future fix pack". No clue when or where.

 4. APAR OA31856 reports TYPE42DS (type 42 subtype 6) Average Read
    Disconnect Time (S42DSRDD) and the total number of read operations
    (S42DSRDT) were invalid.  Any EXCP channel program built using a
    Locate Record Extended command was counted as a Read operation and
    any disconnect time was included in S42DSRDD.  Any read or write
    channel program built using the Media Manager I/O Driver using a
    Locate Record Extended command was considered a write operation by
    the code that collects data set I/O statistics. The APAR corrects
    all these errors.

 3. EAV volumes, Extended Address Volumes, permit VSAM and Extended SEQ
    Format datasets to exceed 62520 cylinders in size; the format of EAV
    CCHH is now represented as CCCCcccH and the cylinder address is now
    cccCCCC.  That is, the high 12 bits of the old HH are appended to
    the front of the old CC, relying on the fact that no current DASD
    requires 16 bits to specify the head.  Further information on EAV
    internal CCHH representation is in IBM documentation for the TRKADDR
    macro.  MXG Version 27.02 contained the updates to DCOLLECT support
    which was the only data source that contained cylinder counts.
    SAS Note 35858 discusses their support for EAV, delivered in SAS
    Version 9.2.  EAV was first released in z/OS 1.10.

 2. APAR OA31055 reports CONCURRENT COPY causes SYSTEM-WIDE Performance
    degradation in z/OS 1.10.

    "Client reported that, after upgrading to z/OS 1.10, DFSMSdss DUMP
     jobs using Concurrent Copy were taking longer than expected to
     complete, or not completing at all.

     The client also observed higher than normal system CPU utilization,
     prolonged contention on the SYS.ANT.QUEUE.ELEMENT latch, and
     increased ECSA usage in subpool 241 (from storage containing
     eyecatcher SDMSIV). This combination of symptoms significantly
     degraded overall system performance.

     System performance problems became worse after the jobs were
     cancelled, due to fragmentation associated with orphaned common
     storage.

     Cancelling the Concurrent Copy jobs may also cause storage control
     sessions to be left on the storage subsystem.  This can eventually
     use up all available sessions on the control unit and prohibit the
     creation of new Concurrent Copy sessions.

     ANTMAIN GRS LATCH CONTENTION HIGH CPU

     This APAR is still Open, Jan 26, 2010.


 1. APAR OA31624 reports z/OS 1.11 IEFACTRT exit in SYS1.SAMPLIB uses
    the field that gets displayed in the job log (total service units)
    it is using the new SMF30SRB_L field instead of the SMF30SRV_L field
    for total Service Units printed on the "flower box" or Banner page.
    The APAR contains the corrected ASM code for the EXIT.

IV.   DB2 Technical Notes.

 2. APAR PM06953 reports that CP Query Parallelism can now run as a
    single enclave.
    Problem Description:
    When a parallel query is offloaded to the zIIP engines, each
    parallel task is scheduled in its own enclave and managed by Work
    Load Manager as such.
    As a result, there is no way for a user to consistently define
    periods to distinguish between, for example, individual enclaves of
    a high-consumption query from a single enclave of a low-consumption
    query.  This limits a user's ability to utilize WLM to favor
    low-consumption workloads.
    Because z/OS did not initially provide a TIMEUSED support to include
    a time-on-CP function vs. time-on-zIIP for multiple SRBs in an
    enclave, each parallel task needed to be scheduled in its own
    enclave in order to extract the correct accounting information.
    However, that created a problem where WLM could not make the
    distinction between one of many enclaves belonging to a
    high-consumption query from a single enclave belonging to a
    low-consumption query.  As such, a user cannot define periods that
    consistently favor low-consumption queries.
    PROBLEM CONCLUSION:
    DB2 code has been modified to create only one enclave for all
    parallel tasks under a query.  This allows WLM to manage each query
    as a whole, and properly distinguish between high-consumption
    queries and low-consumption queries so that users can define periods
    to consistently favor one set or the other.


 1. PM02853 reports incorrect CPU times for RRS threads for both CP and
    zIIP specialty engines.  Specifically, QWACAJST could be greater
    than (QWACEJST-QWACBJST), or QWACCLS2_zIIP (MXG QWACZIS1) could be
    greater than QWACCLS1_zIIP (MXG QWACZIS2). The APAR text describes
    the scenario when a dissociated agent commits a TCB not associated
    with that agent, and, if the accounting interval for the dissociated
    agent is set to COMMIT, the current accounting interval will end and
    a new one will begin at the time of a commit, BUT only class 2 time
    is counted during the commit, AND those class 2 CP and zIIP engine
    CPU times during the commit may be wrong!

V.   IMS Technical Notes.

 1. Variable DLRMSCH/LINTMSCH, the Elapsed Time for Schedule Processing
    can have extremely large values in IMS Version 11.  Two APARs are
    relevant:

    IMS 10 APAR PK87069 (PTF= UK55674) seems relevant. It was put in IMS
    11 with APAR PM10048. It closed in Mar 2010 (PTF UK55640).  It's
    Abstract has: IMS TYPE08 LOG RECORD HAS INCORRECT SCHEDULING
                  STATISTICS IN TWO SITUATIONS
    ERROR DESCRIPTION:
    During processing of a V10 log record, it was found that under 2
    circumstances the scheduling statistics in the 08 log record are
    incorrect.
    -The first is if the 08 record is the result of a quick reschedule.
     In this case, the fields are binary zeroes instead packed zeroes,
     causing post processing programs to abend.
    -The second case is after a false schedule, which is most likely to
     happen in a shared queues environment. In this case, the next 08
     record has an abnormally high value, which does not reflect the
     actual scheduling times.

    IMS 10 APAR PK89913 (PTF = UK51145). It was put in IMS 11 by APAR
    PK98858. It closed in Oct 2009 (PTF= UK55639). It's Abstract has:
    VALUE IN THE LINTMSCH FIELD IN X'08' LOG RECORD TOO LARGE FOR FIRST
    TRANSACTION


VI.  SAS Technical Notes.

 7.  The Windows 64-bit SAS Version 9.2 can NOT read or update a FORMATS
     catalog that was created by 32-bit SAS Version 9.2.  Previously, a
     single FORMATS file created with 8.2, 9.1.3, or 32-bit 9.2 could be
     used or updated by any of those releases.  Now, separate LIBNAMES
     and separate directory for 32-bit SAS and for 64-bit SAS is needed.
     The error message you get is
        ERROR: File LIBRARY.FORMATS.CATALOG was created
               for a different operating system.

 6.  SAS V9.2 has an (obscure) Compiler Error with a Date Literal that
     has a null value (e.g. ""D).  Changing the string to " "D, i.e.,
     inserting a blank, circumvents the error.  SAS Note 35161.

 5.  SAS V9.2 Warnings when combining datasets with different lengths.

     As previously noted, SAS V9.2 TS2M0 and TS2M2 print new WARNINGs:

     WARNING: Multiple lengths were specified for the variable XXXXXXX
              by input dataset(s).  This may cause truncation of data.

     when datasets with different length variables are combined, i.e.
     with SET, MERGE, UPDATE, etc., or when /INHERIT is not used when
     data sets are created with PROC MEANS and subsequently combined.

     MXG History of dealing with this WARNING (that sets CC=4):

        Apr, 2008.  MXG 26.03.  Internal code changes in MXG eliminated
                                the warnings, but, also
                                Added VARLENCHK=NOWARN to VMXGINIT

        Aug, 2008.  MXG 26.07.  Removed VARLENCHK=NOWARN to VMXGINIT,
                    because Hot Fix F9BA07 restored behavior to 9.1.3.
                    BUT: Hot Fix F9BA07 is ONLY for (ancient) 9.2 TS1M0.

        Apr, 2010   SAS 9.2 TS2M0 and TS2M2 reinstated the WARNINGs by
                    default, eliminating the Hot Fix change, and instead
                    documented OPTION VARLENCHK=NOWARN as the solution
                    you should enable to eliminate the warning.

                    MXG 28.03 reinstated VARLENCHK=NOWARN in VMXGINIT,
                    so that the WARNING will NOT be printed nor will the
                    condition code be set.  This protects future MXG
                    versions when MXG has to change a variable's length
                    but also protects user code from the WARNING.

                    SAS Note SN-031850 discusses the warning for both
                    TS2M0 and TS2M2, but incorrectly says to install
                    Hot Fix F9BA07 for TS2M0, whereas that Hot Fix is
                    ONLY for the old 9.2 TS1M0 release.

 4. Change 12.153 from 1994 documented that JCLTESTx, Step TESTOTHR will
    abend with 213-04 for //DISK DDname if your site sends temporary
    allocations to VIO, so VOL=SER=XXXXXX was added in the JCL example
    so the allocation would be made to real DASD.
    SAS Note 19273 documents VIO restrictions for SAS Data Libraries:
     Any library that is allocated to Virtual Input/Output (VIO) must
     have a data set name that is system generated.  The data set name
     must be configured as &name, where name is a string of 1 to 8
     characters.  IBM supports no other nomenclature for data sets
     allocated in VIO.  Due to this restriction by IBM, the following
     two examples are NOT valid for SAS data libraries that are
     allocated to VIO:

     Example 1
     //TEMPLIB DD DSN=USERID.MY.SASLIB,DSN=(NEW,DELETE)
     //      UNIT=VIO,SPACE=(CYL,(5,5))
     Example 2
     libname templib2 '.my2.saslib' disp=(new,delete)
             unit=vio space=(cyl,(5,5));

     The following two examples ARE valid for SAS data libraries that
     are allocated to VIO:

     Example 3
     //TEMPLIB DD DSN=(NEW,DELETE)
     //      UNIT=VIO,SPACE=(CYL,(5,5))
     Example 4
     libname templib2 '&temp' disp=(new,delete)
             unit=vio space=(cyl,(5,5));

 3. ABEND 40A with Reason Code 008 occurs when SAS V9.1.3 is executed
    without a //CONFIG DD.

 2. I was unaware that ASCII wildcards can be used in input FILENAMEs:

     FILENAME SMF 'D:\SMFDATA\SMF*.RECORDS.U' RECFM=S370VBS LRECL=32760;

    will read all files that match smf*, in ASCII ascending order.

    I was also unaware that LIBNAME statement supports concatenation
    for input.  This LIBNAME opens the first directory as read/write,
    and any subsequent directories as read only:

     LIBNAME PDBS ('D:\PDBLIBS\PDB\' 'D:\PDBLIBS\SPIN\');

    Using  DATA;SET PDBS.SPIN6; reads the SPIN6 dataset from the "SPIN"
    directory.  SAS stops in the first directory that has the dataset,
    so you can't use this SAS facility to concatenate daily PDBs to read
    all of the "JOBS" datasets in those seven PDB libraries.  That is,
    however, supported in the VGETDDS/VMXGSET utilities in MXG; see the
    comments in those members, recently enhanced.

 1. SAS documents in SAS Note 10483 that a DD DUMMY in the middle of a
    concatenated input causes SAS to stop reading that INFILE. I was not
    aware that this "expected" behavior existed, and not sure I think it
    is righteous, but the behavior is based on the IBM JCL Reference:
     "12.1.6.8  Do Not Concatenate Data Sets after a DUMMY Data Set.
         If you define a data set using the DUMMY parameter, do not
         concatenate other data sets after it.  When the processing
         program asks to read a dummy data set, the system takes an
         end-of-data set exit immediately and ignores any data set that
         might be concatenated after the dummy."
    However, there are exceptions; both IDCAMS REPRO and SEARCHFOR will
    read all DDs in a concatenation and do not stop at a DD DUMMY, and
    I believe that all DDs in a //SORTIN are read by all SORTs.
    This also applies to DSNAME=NULLFILE.



VI.A.  WPS Technical Notes.

 1. X

VII. CICS Technical Notes.

 1. APAR PM06737 corrects the optional OMEGAMON data segments that are
    missing section length header fields in Release 801 in TDSZ.  The
    offset for  MQ_TOT_CNT appears to be off by four bytes, so the
    contents of column MQ_TOT_CLCK appears to be what should be the
    contents of MQ_TOT_CNT.  The same problem will occur with the
    OMEGDB2, OMEGDLI, OMEGMQ and OMEGUEVNT sections within the
    SMF_CICS_T record.  The problem is that a 4 byte section length
    field is missing from the top of these sections, which means all the
    resulting fields within the section are off by 4 bytes.
    Please contact support@mxg.com if you install this APAR to see if an
    MXG Change exists - I need data with the APAR before I can update.

VIII. Windows NT Technical Notes.

 1.  Microsoft Security Essentials (1.0.1611.0), the anti-virus product
     that replaced One Care, causes SAS ERRORs on Windows 7 and XP:

         ERROR: User does not have appropriate authorization level
                for library WORK.

         FATAL: Code generation error detected during BY compare
                generation.

     (That second "FATAL" message is not always present).

     Changing the MSE settings to exclude the sas.exe process and to
     exclude scanning SAS7BDAT-suffixed files eliminates the error.

     SAS Development is in discussion with MicroSoft to resolve.

IX.  z/VM Technical Notes.

 1.  APAR VM64728 reports z/VM Monitor User Share Data by Processor Type
     is incorrect.  The five sets of user share data collected (one for
     each processor type) in the MRMTRUSR (Domain 1 Record 15), MRUSELON
     (Domain 4 Record 1), MRUSELOF (Domain 4 Record 2), and MRSCLSHR
     (Domain 9 Record 2) CP MONITOR records are not valid.  That is, the
     user share data for CP, zAAP, IFL, ICF, and zIIP CPU types is not
     correct. The specification of an address being used as a pointer to
     the share data in the modules HCPMNE, HCPMOD, and HCPMXL to collect
     the data and move it into the appropriate fields in the monitor
     records is incorrect.

X.    Email notes.

 1.  X



XI.   Incompatibilities and Installation of MXG vv.yy.

 1. Incompatibilities introduced in MXG 28.04 (since MXG 27.27):
    See CHANGES.

 2. Installation and re-installation procedures are described in detail
    in member INSTALL (separate sections for each platform, z/OS, WIN,
    or *nix), with examples of common Errors/Warnings messages a new MXG
    user might encounter, and in member JCLINSTT for SAS V9.2 or member
    JCLINSTW for WPS. INSTALL also shows how to read SMF data on PCs/nix
    using the FTP ACCESS METHOD.

XII.  Online Documentation of MXG Software.

    MXG Documentation is now described in member DOCUMENT.


XIIV. Changes Log

--------------------------Changes Log---------------------------------

 You MUST read each Change description to determine if a Change will
 impact your site. All changes have been made in this MXG Library.

 Member CHANGES always identifies the actual version and release of
 MXG Software that is contained in that library.

 The CHANGES selection on our homepage at http://www.MXG.com
 is always the most current information on MXG Software status,
 and is frequently updated.

 Important changes are also posted to the MXG-L ListServer, which is
 also described by a selection on the homepage.  Please subscribe.

 The actual code implementation of some changes in MXG SOURCLIB may be
 different than described in the change text (which might have printed
 only the critical part of the correction that need be made by users).

 Scan each source member named in any impacting change for any comments
 at the beginning of the member for additional documentation, since the
 documentation of new datasets, variables, validation status, and notes,
 are often found in comments in the source members.

Alphabetical list of important changes after MXG 27.27 now in MXG 28.05:

  Dataset/
  Member   Change    Description

  See Member CHANGES or CHANGESS in your MXG Source Library, or
  on the homepage www.mxg.com.

Inverse chronological list of all Changes:

Changes 28.yyy thru 28.001 are contained in member CHANGES.


***********************NEWSLETTER FIFTY-FIVE****************************




          MXG NEWSLETTER NUMBER FIFTY-FIVE, JAN 20, 2010

Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE

                         TABLE OF CONTENTS

I.    MXG Software Version.
II.   MXG Technical Notes
III.  MVS, aka z/OS, Technical Notes
IV.   DB2 Technical Notes.
V.    IMS Technical Notes.
VI.   SAS Technical Notes.
VI.A. WPS Technical Notes.
VII.  CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX.   z/VM Technical Notes.
X.    Email notes.
XI.   Incompatibilities and Installation of MXG.
         See member CHANGES and member INSTALL.
XII.  Online Documentation of MXG Software.
         See member DOCUMENT.
XIII. Changes Log
     Alphabetical list of important changes
     Highlights of Changes  - See Member CHANGES.

     COPYRIGHT (C) 1984,2010 MERRILL CONSULTANTS DALLAS TEXAS USA

I.  The 2010 Annual Version MXG 27.27 is dated Jan 20, 2010.

    All sites were mailed a letter with the ftp download instructions.
    The availability announcement was posted to both MXG-L and ITSV-L.
    You can always request the current version using the form at
     http://www.mxg.com/ship_current_version.

 1. The current version is MXG 27.27, dated Jan 20, 2010.

    See CHANGES member of MXG Source, or http://www.mxg.com/changes.

II.  MXG Technical Notes


 3.  SAS option COMPRESS=YES impact on z/OS MXG Execution.

     The MXG default for all platforms is COMPRESS=YES. For all ASCII
     platforms benchmarks have proven that IS correct and desirable: on
     ASCII systems, COMPRESS=YES minimizes both disk space and CPU time
     needed to create MXG datasets.

     On z/OS, while COMPRESS=YES does minimize disk space required, it
     does require additional CPU time. So, like most performance issues,
     it all depends - on whether your disk space is the limiting factor
     (in spite of the incredible reduction in the real costs for disks)
     or if the CPU Time consumption is of more concern (at 3am??).

     At CMG 2009, Chuck Hopf reported an MXG tailoring that set option
     COMPRESS=NO for the SMF/SORT processing to a TEMPPDB to save CPU
     time, followed by a PROC COPY with COMPRESS=YES to minimize the
     size of the output PDB data library.  But then I discovered that in
     SAS V9, COMPRESS=YES can be specified on a LIBNAME statement, which
     eliminated the tailoring, the TEMPPDB and the PROC COPY. Chuck then
     reran these tests, reading an 11GB SMF file, always compressing the
     the output PDB library:


     Compress Option CPUTM   WORK   PDB  CICSTRAN DB2ACCT PDBTEMP TOTAL
                      sec     cyl   cyl    cyl     cyl     cyl     cyl

     YES, GLOBAL      2745   2441   1813   1223    2765           8242
     NO, PROC COPY    1867   6934   1816   5114   10046    6006  29916
     NO, LIBNAME YES  2376   6934   1816   1223    2765          12737
     NO, TAPE         2061   6934   1816   TAPE    TAPE           8750


     The COMPRESS=YES option minimizes the total disk space for all of
     the output data libraries AND for the WORK library, but at a cost
     of 15 minutes more CPU time, from 31 to 46, a 48% increase.

     To save those 15 CPU minutes using COMPRESS=NO+PROC COPY for only
     the PDB library, the total disk space for the job increased from
     8242 to 29,916 cyls, nearly four times, and the output libraries
     increased nearly three times, from 5801 to 16976 cylinders.

     The intermediate choice, using COMPRESS=NO for WORK library with
     COMPRESS=YES on the three output LIBNAMES, saves 8 minutes CPU Time
     (or an increase of 27% from the minimum); the total disk space for
     the job increased only by 50%, from 8242 to 12,737 cylinders, and
     that increase was all in the uncompressed temporary WORK library
       //SYSIN DD *
        OPTIONS COMPRESS=NO;
        %LET PDB2ACC=DB2ACCT;
        LIBNAME PDB      COMPRESS=YES;
        LIBNAME DB2ACCT  COMPRESS=YES;
        LIBNAME CICSTRAN COMPRESS=YES;
        %INCLUDE SOURCLIB(BUILDPDB);

     The last choice, writing the CICSTRAN and DB2ACCT datasets to TAPE
     LIBNAMEs, compressing only the output PDB library, increased the
     CPU time from minimum by only 3 minutes, to 34, with only 8750 cyl
     required for the uncompressed WORK and compressed PDB libraries.

     Note that for TAPE output on z/OS, again, it all depends!!
     With the Global COMPRESS=YES option, TAPE output is NOT COMPRESSED;
     this makes complete sense, since ALL tape control units compress at
     that hardware level, at NO CPU cost.  However, if COMPRESSS=YES
     is specified either as a dataset option or as a LIBNAME option, SAS
     does compress tape output datasets.   This could be required if you
     have virtual tape systems that write uncompressed to DASD.

     Additionally, compression of datasets in a libref are always at
     the dataset level.  For example, if you use COMPRESS=YES option on
     a LIBNAME, all created datasets will be compressed, but you could,
     later, add an uncompressed dataset to that data library.

     So, my recommendation for z/OS is to still use the MXG default of
     Global COMPRESS=YES.  I think the exposure and cost of running out
     of disk space, causing a BUILDPDB job to ABEND, is far higher than
     the small increase in CPU time, especially if the BUILDPDB is run
     in the slack time of day.  But, the above tests do quantify the
     possible CPU time savings, if that truly is the limiting factor.

 2.  Removal of duplicate observations from MXG's PDB.JOBS.

   A "job" is a unique instance of READTIME JOB JESNR, but a PDB.JOBS
   observation is created from multiple SMF type 6, 26 and 30 records
   which might be created in several days' SMF datasets.

  -There are several sources of possible duplicates in PDB.JOBS:

   a. Duplicate records have NEVER been created in the VSAM SMF dataset,
      but design errors in the SMF VSAM dumping procedures, human errors
      or hardware or software failures in the SMF processing jobstream
      have created actual duplicate records in the SMF datasets that MXG
      processes.  If you have a well designed SMF dumping procedure,
      and never experience a job failure, you cannot have duplicates.

   b. If duplicated SMF records do exist in the input SMF file that MXG
      reads (e.g., same SMF dataset concatenated to itself), BUILDPDB
      will NOT create duplicates in PDB.JOBS, because the NODUPRECS SORT
      option is used to remove duplicates from the datasets MXG creates
      in the BUILDPDB program.  These sorts require BY lists that span
      all possible sequences so that duplicates are physically adjacent,
      and that is why sometimes, the MXG BY list has had to be changed
      to guarantee that adjacency for duplicate removal.

   c. But "pseudo-duplicates" can be created by BUILDPDB that we do NOT
      want to remove: PDB.JOBS observations with the same READTIME JOB
      and JESNR, but that are not actual duplicates.  The SPINCNT value
      in IMACSPIN sets the number of BUILDPDB executions (days) when
      records for inflight (incomplete) jobs are held; jobs are "spun"
      until the job's Purge record is read.  When SPINCNT is exceeded,
      whatever records happen to be in that SPIN library will be output
      to that PDB.JOBS.  Then, when more of that job's records are read,
      another observation with the same READTIME JOB JESNR is output, in
      a different day's PDB.JOBS.  But these are not duplicates; each
      will have different sets of variables populated from the different
      SMF records that were read.  For example, if SPINCNT=0, a job that
      executed today, but was in the held output queue when SMF VSAM was
      dumped, will create a PDB.JOBS observation with the CPU/EXCP/etc
      execution resource variables populated, but all of the scheduling
      datetimes (JSTRTIME,JPURTIME,etc) from the Purge record will have
      missing values.  Then, tomorrow, when the print/purge SMF records
      are read, a second observation for that job will be output with
      that same READTIME JOB JESNR, but with only the print lines and
      scheduling datetime variables populated.  We do NOT want to delete
      these pseudo-duplicate observations from our PDB.JOBS dataset.

   d. But "real" duplicate observations can be created, if
      SMF records that were read "yesterday" are accidentally reread
      again "today".  This would create separate PDB.JOBS observations
      in two different daily PDBs that WOULD have identical values for
      all resources.  Those duplicate observations differ ONLY in their
      ZDATE/ZTIME values (the "run date" of the BUILDPDB execution), so
      if you do then combine the daily PDBs into the same WEEKs PDB,
      you CAN use this PROC SORT to delete these true duplicates.

         PROC SORT NODUPKEY DATA=WEEK.JOBS OUT=WEEK.NODUPJOB;
           BY READTIME JOB JESNR INBITS JINITIME JTRMTIME INITTIME
           PRINTIME JPURTIME CPUTM EXCPTOTL EXCPTODD EXCPNODD PRINTLNE;

      Option NODUPKEY must be used here, instead of MXG's normal NODUP,
      because ZDATE/ZTIME are NOT identical in each pair of duplicates.

   e. BUT: if only some of the job's records are repeated, or if the job
      already is "SPINing" (has some records held in the SPIN library),
      then the re-reading of only some of a job's SMF records is much
      more insidious, and the above PROC SORT would not likely detect
      that kind of duplication.

 1.  Search Arguments.

     Some examples of search arguments for MXG and related information:

     Using Google to keyword search at a specific site, for example, at
     www.mxg.com or at www.ibm.com:

       +websphere +db2 +wlm +classification site:mxg.com

       +websphere +db2 +wlm +classification site:ibm.com

     Alternatively, this url is the Google Advanced Search page:

       http://www.google.com/advanced_search?q=site:www.mxg.com&hl=en

     For mxg.com, you can also use the SITE SEARCH option (on left) at

       http://www.mxg.com/newsletters/

     But the MXG-L ListServer Postings Archive is not at www.mxg.com,
     so the above site searches will not find MXG-L postings.  The link
     to search all MXG-L postings, since its Oct, 1996, inception, is:

       http://peach.ease.lsoft.com/scripts/wa.exe?A0=MXG-L


III. MVS, a/k/a z/OS, Technical Notes.

13. APAR OA30974 reports that if you use SMF Logger AND have removed all
    MANx datasets from SMFPRmxx, but have LASTDS(HALT) specified there,
    an IPL will fail, as it enters a WAIT DOD RSN01 wait state.  Remove
    the LASTDS(HALT) to circumvent until IBM has a PTF for the APAR.

12. APAR OA31547 reports that SMF 89 records can stop being written if
    they change SMF recording from NOACTIVE to ACTIVE. APAR Still Open.

11. APAR PK86020 reports A REPORTING PROBLEM WITH THE RMF WORKLOAD
    ACTIVITY REPORT WITH RESPECT TO THE TRANS-TIME
    ERROR DESCRIPTION:
    A reporting problem with the RMF Workload Activity report with
    respect to the Trans-Time.  Here is a sample report that shows the
    TRANS-TIME values that are not correct:
        TRANS-TIME HHH.MM.SS.TTT
        ACTUAL               973
        EXECUTION            875
         QUEUED               97
    USERS AFFECTED:  All users of IBM WebSphere Application
                     Server V6.1.0 viewing RMF diagnostic
                     reports.
    The RMF Workload Activity report shows an incorrect queued
    value under the TRANS-TIME values.
    PROBLEM CONCLUSION:
    Because the queue times are reported based on the values in the
    thread at the time of capture, the values presented may be incorrect
    if the thread has switched during the course of processing.  This
    may occur if SSL or webservices are active.  The problem is resolved
    by copying these values through the java portion to circumvent the
    loss of the values during thread switching.
    APAR PK86020 is currently targeted for inclusion in Service Level
    (Fix Pack) 6.1.0.29 of WebSphere Application Server V6.1

10. APAR OA31088 reports Z/OS 1.11 B10 INCORRECT FREE SPACE AND LARGEST
    FREE EXTENT IN SMS VOLUME CONTROL BLOCK IMMEDIATELY AFTER VARY
    ONLINE
    ERROR DESCRIPTION:
    In z/OS 1.11 environment, free space and largest free extent are
    incorrect for new volumes that have been varied online and have not
    had any datasets allocated to it.  The incorrect statistics are in
    the volume statistics control block (IGDVLD) which feeds downstream
    systems such as RMF.  Beginning in Z/OS 1.11, an additional call is
    now being made such that the volume statistics will be updated when
    the volume is varied online eliminating the need to allocate a small
    1 trk dataset to the volume (APAR OA23901 included in 1.11 base).
    This client saw incorrect RMF Storage Group and volume statistics
    Additional symptom:
    ISMF LISTSYS statistics are incorrect after the vary.
    ISMF LISTVOL command statistics seem to be correct.
    LOCAL FIX:
    Allocate a dataset to the volume which will update the free space
    and largest free extent statistics correctly.

 9. APAR OA30299 reports SMF74DCI SMF74DCT BLANK FOR DEVICE FOLLOWING
    HIPERSWAP
    After a hyperswap or DDR device swap, IOS will issue an ENF 28 DDR
    and ENF 23 Device Online for the target device of the swap.  Both
    ENFs are processed by RMF listen exit module ERBMFEAR.  But RMF
    module ERBMFIDA, which updates the DDB, is only called when
    processing the ENF 23 for device online event.  Since ENF 28 DDR
    runs asynchronously, it can happen that the ENF 28 is processed
    before ENF23 so that the call to ERBMFIDA is skipped. As result of
    this the RMF DDB is not updated.  Affected RMF releases: z/OS-1.9 up
    to and z/OS-1.11
    PROBLEM CONCLUSION: With this APAR, the ENF 28 listen exit handler
    in module ERBMFEAR is changed to call ERBMFIDA when the
    configuration token in EDDDB field EDDDSDCT is blank.

 8. APAR OA31471 reports variable SMF75AVU, MXG variable AVGUSED,
    the average number of used slots in the RMF PP PAGESP report is too
    low. The problem occurs when large page datasets are used and RMF
    Monitor I zz data gatherer session runs with a very small cycle time
    (e.g. 100 ms).

 7. APAR OA30633 reports HIGH CPU IN GRS WHEN ZFS QUERYING FILE SYSTEM
    OWNER FOR RMFGAT DATA GATHERING.
    When running with RMFGAT data gathering option "ZFS", RMF makes
    requests to zFS to collect statistics on zFS file systems.  As a
    result, zFS makes ISGQUERY requests to GRS to determine the owner of
    each file system.  The GRS GQSCAN routine scans for enqueues across
    the sysplex and can be CPU intensive.  LOCAL FIX:
    BYPASS/CIRCUMVENTION: The collection of ZFS data can be turned off
    by specifying Monitor III data gatherer option "NOZFS".

 6.  APAR OS30551 reports zeros for buffer statistics above 2GB until
     buffer utilization exceeds 80%.  APAR OA27343 created the error.
     APAR OA72343 was installed.

 5.  Daylight Savings Time and CMF and GMT Offset.

     With BMC's CMF monitor instead of RMF, you must bounce the MVSPAS
     (CMF) Address Space after the CEC Clocks were reset for DST Fall
     Back of the clocks.  If the STCs were not bounced, the values in
     the CMF fields that MXG INPUTs as GMTOFFTM and GMTOFF72 continued
     to remain the offset prior to the Fall Back. The incorrect GMTOFF72
     did not cause incorrect timestamps in the TYPE72GO dataset, but the
     incorrect GMTOFFTM variable apparently caused datasets ASUM70PR &
     ASUM70LP timestamps to correspond to the incorrect GMT offset.
     The wrong GMT Offset will continue to be in your RMF SMF records
     until the CMF Address Space is restarted.


 4.  Comparison of Seconds of CPUTM in PDB.TYPE72GO and PDB.SMFINTRV,
     shows RMF and SMF interval data match very well.

           Startime     SYS1    SYS2    SYS3   SYS4     Total


     SMF   05NOV09:00   4350     671    2641    212      7876
     RMF   05NOV09:00   4339     665    2751    217      7974  +  96

     SMF   05NOV09:01   3696     670    1473    201      6041
     RMF   05NOV09:01   3802     678    1330    206      6016  -  25

     SMF   05NOV09:02   5044     753    3041    204      9043
     RMF   05NOV09:02   5050     761    3012    211      9036  -   7

     SMF   05NOV09:03   7527     836    4359    213     12936
     RMF   05NOV09:03   7507     856    4369    268     13002  +  66

     SMF   05NOV09:04   4465     851    4411    278     10006
     RMF   05NOV09:04   4752     868    4522    237     10380  + 374


 3.  An interesting post on IBM-MAIN by John Eells, IBM z/OS Technical
     Marketing, on what IBM can/can't do when a change is introduced:
     We can't win on the default.  We can only pick which group of
     customers to annoy:
     - If we default a behavioral change we introduce a migration
       action. Customers overwhelmingly tell us they hate migration
       actions. "Look at this behavioral change, see if you care, and
       change something if you don't want it to happen" is a migration
       action.
     - If we don't default the behavioral change, people who want it
       tell us that "everyone" would want it to be the default.
      We have historically been poor predictors of which group will be
      larger, so we are "defaulting" more and more to avoiding
      behavioral changes that "just happen."

 2.  APAR OA30246 reports that XRC zIIP-eligible-work in Service Class
     SYSTEM is not dispatched on a zIIP, but executes on the CP engines
     when HiperDispatch is Enabled.  Pending a PTF, the APAR recommends
     that zip-eligible work be moved to Service Class SYSSTC, or to
     disable HiperDispatch.

 1. Summary: "EXCP" counts recorded for access to HFS & ZFS filesystems:

    An  HFS file, 10,000 50-byte records, 496K, or 123 4096-byte blocks,
    & a ZFS file,  1,000 50-byte records,  49K, or  13 4096-byte blocks,
    was created/copied on z/OS 1.9 by different programs.
     Total "EXCP"s were between 50 and 23,710 for HFS.
     Total "EXCP"s were between 37 and  5,416 for ZFS

     These "EXCP" counts are displayed on JOBLOG and are included in the
     SMF 30 Address Space Total EXCP count, EXCPTOTL (SMF30TEP).

                                         HFS               ZFS
                                        496K               49K
         Job Description                EXCPTOTL         EXCPTOTL

     TEST92LD -SAS92 LOAD             23710,23290         5416
     TEST91LD -SAS91 LOAD             21856,21785         3867
     TEST92RD -SAS92 READ             13364,13295         4464
     TEST91RD -SAS91 READ             11787,11763         2891
     TESTGENR -IEBGENER READ            309,  306          n/a
     TESTFAST -FASTGENR READ            298,  285           65
     TESTSORT -SYNCSORT READ            209,  209           70
     TZOS92LD -SAS92 LOAD z/OS         3301               3324
     TZOS91LD -SAS91 LOAD z/OS         1764               1771
     TSTWGENR -IEBGENER WRITE           301                n/a
     TSTWFAST -FASTGENR WRITE           268                 53
     TSTWSORT -SYNCSORT WRITE           252                 62
     ZOSCGENR -IEBGENER COPY            113                 53
     ZOSCFAST -FASTGENR COPY             50                 28
     ZOSCSORT -SYNCSORT COPY             46                 37


All of the SMF records written for two of these test jobs were analyzed
in detail: the SAS-TEST91LD and FASTGENR-TESTFAST are analyzed in
detail below; the other job's SMF data will

SAS was used to create a 10,000 record text file of 50 byte records,
 written to an dynamically allocated HFS1 Filename.

FASTGENR was then used to copy that hfs file, with a static SYSUT1 DD,
 to a disk data set.

A. EXCP counts in DD Segments in SMF type 30 subtype 2, 3, 4, and 5):

 1. There was no DD segment created segment for the dynamically
      allocated HFS1 DDNAME in the SAS job.

 2. While there was a SYSUT1 DDNAME in the type 30 records for the
      FASTGENR job, it contained ONLY the DDNAME; there were no EXCPs
      recorded, and there was no DEVNR nor DEVCLASS/DEVTYPE information.

B. EXCP counts in the address space fields in the SMF 30 record:

 1. HFS "EXCP" counts ARE captured in the SMF 30 record; but only in
      in the address space total EXCP Count EXCPTOTL(SMF30TEP/TEX).
    - RMFEXCP are the EXCPs counted in IO Service Units (SMF30IO/IOL),
      and the HFS EXCP count IS included in RMF IO Service Units.
    - EXCPTODD is the sum of all EXCPs in the DD segments.
    - EXCPNODD is the EXCPs count NOT counted in the DD segments,
      calculated as EXCPTOTL minus EXCPTODD.
    - EXCPDASD is the total DD EXCPs count to DASD devices.
    - SMF30AIS is the total count of DASD SSCH's (NOT BLOCKS/EXCPs)
    - IOTM variables are the IO Connect Time durations, as above.

       JOB         EXCPTOTL RMFEXCP  EXCPTODD  EXCPNODD EXCDASD SMF30AIS

       SAS           21785   21778     1379     20406     1379    704
       FASTGENR        285     280      101       184      101    213

       JOB         IOTMTOTL RMFIOTM  IOTMTODD  IOTMNODD
       SAS           0.51     n/a      0.37      0.14
       FASTGENR      0.02     n/a      0.02      0.01

   Observations:

   a. SAS wrote 10,000 blocks of 50 bytes each, but counted 20,000 EXCP,
      and that count was also shown on the SAS log; why 20000 was the
      count will be investigated with their HFS guy when he is back from
      vacation, but that count of 20000 was passed to IEASMFEX, as it
      does show up in the EXCPTOTL and RMFEXCP.

   b. FASTGENR, the SYNCSORT replacement for IEBGENER, counted 101
      "EXCP"s to the 3390 output disk device in the EXCP segment for
      SYSUT2; the "EXCP"s reading the HFS file were counted as 184 in
      the EXCPNODD (i.e., included in EXCPTOTL and RMFEXCP).
      But FASTGENR and SYNCSORT have NEVER counted EXCPs, but, instead
      count SSCHs, and that is what it passed to IEASMFEX.
        (I was involved in legal issues between DFSORT and SYNCSORT
         because SYNCSORT published false I/O comparisons that used the
         SIOs for SYNCSORT but BLOCKS/EXCPs for DFSORT, many years ago.
         There was a "Special Core Zap" from SYNCSORT that would change
         their count to BLOCKS, but I don't know if it still exists, and
         I suspect no one uses is now!).
      In addition, the FASTGENR log shows that it read and wrote
      10,000 logical records; however it shows a total size of
      800,000 bytes, whereas only 500,000 bytes were written, so
      even FASTGENR can't correctly count HFS activity.

   c. While HFS EXCP counts are in the EXCPNODD field, there are other
      I/O counts included in EXCPNODD, for all file I/O that does not
      have a DD:  Catalog I/O, LinkList I/O, and JES2 SPOOL I/O, and the
      JES2 Spool I/O count can be significant.

C. HFS-only EXCP counts do exist in the OMVS Segment of type 30s.

   The old "OMVS" segment is now known as
   "z/OS UNIX System Services Process Section" in the SMF manual.

   I LOVE the fact that UNIX is in CAPITAL LETTERS!

   MXG's first technical note on measuring unix, by Chuck Hopf,
   was subtitled "or how i learned to type in lower case".

  1. The SAS job created one "OMVS" segment, while the FASTGENR created
      two segments, having apparently spawned/forked/whatever unix does
      that created a second PID for their copy program.  The first three
      columns are the only block count fields that were non-zero; the
      last columns are the only other metrics that were non-zero.

                DIR     DATA    DATA        PATHNAME  PATHNAME SYSCALLS
                READ    READ    WRITE       LOOKCALL  LOOKCALL REQUESTED
       JOB      BLOCKS  BLOCKS  BLOCKS      LOGICAL   PHYSICAL BY
                                            FILES     FILES    PROCESS

                OMVSODR OMVSOFR OMVSOFW     OMVSOLL   OMVSOLP   OMVSOSC

      SAS          65       0    20000          8       37       21

      FASTGENR-1   16       0        0          2        8        3
      FASTGENR-2   26     125        0          3       13        4

      FASTGENR     42     125        0          5       21        7

      Comparing the type 30 with the type 30 OMVS segment:

                   Total I/O Blocks OMVS   Total NODD IO COUNT
      SAS                20065                  20406
      FASTGENR             167                    184

   Observations:

   a. The UNIX segment EXCP counts can indeed be subtracted from the
      address space EXCP counts, for sites that do NOT want to include
      HFS EXCPs in their billing, if they are using the EXCPTOTL field.

   b. I polled MXG users, and most said that when EXCP counts were used
      in chargeback, they used only the EXCPDASD and EXCPTAPE counts
      (MXG sums DD EXCP counts by device type); the use of EXCPTOTL that
      includes HFS (and SPOOL) counts are not commonly used in billing.


D. HFS-only EXCP counts do exist in the Type 92 records.

   The jobs each created one subtype 10 and one subtype 11; only the 11
   has resource metrics:

         BYTES    BYTES    DIR I/O  DATA I/O DATA I/O READCALL WRITECALL
         READ     WRITTEN  BLOCKS   BLOCKS   BLOCKS   ISSUED   ISSUED
                           RD/WR    READ     WRITTEN
         SMF92CBR SMF92CBW SMF92CDI SMF92CIR SMF92CIW SMF92CSR SMF92CSW

  SAS:       0      498K      12        0     20000       0     20000
  SYNC:    498K       0       10      125         0       9         0

  Observations:

  a. While FASTGENR reported 800,000 bytes copied, the SMF 92 shows that
     FASTGENR is wrong (it used a default LRECL=80 times 10,000 logical
     records), and that SAS was right (it showed 10,000 logical records
     with the correct 50 byte LRECL).

  b. The EXCP counts for HFS activity, 20012 for SAS and 135 for SYNC
     in the SMF 92 are consistent with the counts in the OMVS segment
     and the EXCP counts passed into the type 30 step records, but
     the values are the counts passed by the application, blocks for
     SAS, and SSCH for FASTGENR, and there's no way to tell which is
     which.

E. No SMF 42 subtype 6 records were created for hfs for these jobs.

   And I did NOT expect to see those records, as they are documented in
   the SMF manual "records DASD data set level I/O statistics", and, for
   these two jobs, hfs was NOT a DASD data set.

   There were type 42 subtype 6 records created for the DASD DDnames for
   the two jobs, and they captured these counts, for comparison with the
   SMF 30s:

   JOB      TOTAL NUMBER CACHE       Sequential  Read        Sequential
   TOTAL    OF IOS       CANDIDATES  blocks      Operations  I/O's
            IOCOUNT                  read        to Dataset
            (S42DSION)   (S42DSCND)  (S42aMSRB)  (S42DSRDT)  (S42DSSEQ)

   SAS         442         187          27        431            5
   FASTGENR    101           1                      1          100

  Observations

  a. Whereas the EXCP counts in the TYPE 30 are whatever the application
     access method passed to SMF, type 42 subtype 6 counts are direct
     from the hardware, independent of the access method, etc.
  b. The FASTGENR SSCH count of 101 SSCHs in the type 42 is the same as
     the SSCH count passed by FASTGENR into the SYSUT2 DD segment, and
     that was the only DD allocated to DASD, since SYSUT1 points to the
     hfs file.  But the (relatively new) SMF30AIS field, documented as
     "DASD I/O Start Subchannel Count for address space and dependent
     enclaves" count of 213 appears to me to be in error.
     The SAS EXCPDASD count of 1379 is consistent with SMF30AIS of 704,
     as half-track blocking is normally used by SAS.
  c. I believe there would be type 42 subtype 6 records created for the
     z/OS VSAM file that "contains" the HFS file system, but those data
     would have the JOB name of the address space from which the actual
     physical I/O occurs, and those counts would be for all users of the
     file system, with no counts for the actual jobs that cause the I/O.

F. Data on the banner page may include HFS counts in the "EXCP Count"

   This site uses the IBM "banner page" to print EXCP counts on Job Log;
   the EXCP count that is printed is, indeed, that EXCPTOTL/SMF30TEP
   Address Space Total Count, and which we now know DOES include the HFS
   "EXCP"s, and those counts are only slightly larger than the two
   products reported on their execution logs:

                   Banner        Product
                   Page          Log's
                   EXCPs         EXCPs
    SAS            21785         20240
    FASTGENR         285           240

   Observation:

   a. This is very likely the source of the large EXCP counts that have
      been reported, since it requires no analysis of the SMF 30 records
      (and I think this is also the EXCP count displayed by SDSF).

G. Conclusions

   1. Whatever is counted by the application as an "EXCP" for HFS access
      whether blocks or SSCHs (at the whim of the I/O programmer!) is
      included in the EXCPTOTL field in the SMF 30 records, and is the
      count that is displayed by banner pages and SDSF.

   2. The type 30 OMVS segments are now used in MXG 27.08 Change 27.213,
      to create the new USSEXCPS count variable that could be used to
      "back-out" these large counts, if the site is actually using the
      EXCPTOTL field in chargeback and has significant USS activity.
      See MXG Newsletter FIFTY-FIVE, MXG Technical Note titled
       1. Summary: "EXCP" counts recorded for access to HFS & ZFS ....
       HFS "EXCP" counts ARE captured in the SMF 30 record, BUT....

   3. With the inaccuracies in counting HFS and zFS EXCPs, and because
      they are included in the RMF IO Service Units,  alternative ways
      to count, including dividing the total bytes in the 92s by 4096
      are under consideration by IBM.  This research is in progress and
      this note will be updated is corrections are made.

IV.   DB2 Technical Notes.

 1.  X

V.   IMS Technical Notes.

 1.  X

VI.  SAS Technical Notes.

  9. SAS Note 32778 reports ABEND 413 Return Code 18 (413-18) can occur
     with SAS V9.2, if you create a new library on tape, when the new
     tape dataset is allocated in Job Control.  For example, this JCL
     can cause this ABEND:

      //CICSTRAN DD DSN=TAPE.CICSTRAN,DISP=(NEW,CATLG,DELETE),
      //       UNIT=3590-1

     The error message that results will be similar to the following:

     IEC145I 413-18,IFG0194A,TAPEDD,V921M0,CICSTRAN,0470,,TAPE.CICSTRAN

     The following error messages might also appear in the SAS log:

      ERROR: OPEN of CICSTRAN failed. Abend code 413. Return code 18.
      ERROR: An I/O error has occurred on file CICSTRAN.

     To circumvent this problem, explicitly name the engine with which
     the library should be assigned, as in the following example:

       //SYSIN DD *
       LIBNAME CICSTRAN V9SEQ;

  8. Exposure on Windows to FAIL/ABEND with LOCK NOT AVAILABLE ERROR.

     SAS Technical Support confirms that execution of SAS under Windows
     has ALWAYS been exposed to a LOCK NOT AVAILABLE error because any
     file's lock can be "grabbed" by another process at any time, even
     a SAS dataset file in the WORK data library!  MXG creates a dataset
     WORK.ZZdddddd with PROC SORT, reads it with SET ZZdddddd and then
     PROC DELETE DATA=ZZdddddd.  But in several QA runs under Windows 7,
     SAS lost its file lock after the DATA step closed successfully,
     causing the PROC DELETE to fail, terminating the QA job:
       -"Lock held by another process" is probably caused by a backup
        program, antivirus program, encryption, or an indexing
        application like Google Desktop that is accessing or touching
        the SAS temporary files while they are in use by SAS.  If a
        backup program or virus scan is running on an interval, that
        would explain why the problem is intermittent.
       -To fix the lock, add the file extensions used by SAS to the
        exclude list of the interfering application; you should exclude
          .lck , .sd2,  .sc2 , .SPDS, and .Sas*
        where the .SAS* wild card excludes these extensions:
          .sas7bdat /* DATA */     .sas7bfdb /* FDB */
          .sas7butl /* UTILITY */  .sas7bitm /* ITEMSTOR */
          .sas7bput /* PUTILITY */ .sas7baud /* AUDIT */
          .sas7bcat /* CATALOG */  .sas7bbak /* BACKUP */
          .sas7bpgm /* PROGRAM */  .sas7bdmd /* DMDB */
          .sas7bndx /* INDEX */    .sas7bods /* SASODS */
          .sas7bvew /* VIEW */     .sas /* SAS program file */
          .sas7bacs /* ACCESS */
          .sas7bmdb /* MDDB */
        Caution: careful when excluding non-temporary SAS data sets from
        a backup.  SAS Recommends that backups occur when SAS is not
        running.
        Caution two: other applications can use those suffixes:
            SC2 - windows scheduler
            SD2 - sound designer
            LCK - database control
            SPDS - ACROBAT
       -If the problem application is not a backup program or virus scan
        then the cause is still probably a third party program. A way to
        determine which program(s) are causing the lock is to use
        utility from Microsoft Sysinternals called Process Monitor. You
        can download Process Monitor for free from Microsoft at

          http://technet.microsoft.com/en-us/sysinternals/
                    bb896645.aspx?PHPSESSID=d926

          Open Process Monitor, click filter and make these 3 changes:
            1)Path "begins with" "%temp%\SAS Temporary Files"
              (Click ADD) (use your work path name, if different).
            2)Process Name is Sas.exe then Exclude (click Add)
            3)Process Name is Explorer.exe then Exclude (click Add)
            Click Apply and OK.

          Then clear the log.

          Then start SAS and run the SAS program that creates the lock
          error. What Process Name(s) are listed in Process Monitor?

          This particular filter doesn't always find the problem.
          Usually the best advice is to ask your internal support team
          for help using this tool to find the problem

     We have not yet been able to identify what process grabbed the file
     lock, because the lock conflict is intermittent.

     BUT: The pathname of the WORK data library was NOT the SAS default:
          it did NOT contain the text "TEMP" nor "SAS Temporary"
     We have changed that pathname to the SAS default, and there has not
     (YET!) been a lock conflict, so we presume/assume that the process
     causing the conflict automatically excluded scanning of directories
     with "TEMP" in their name.

  7. SAS USER U1319 ABEND if EXITCICS/CICSIFUE and /VIEW=_WCICTRN used.

     Using a VIEW for CICSTRAN with the CICSIFUE decompression INFILE
     user exit caused a USER ABEND U1319 error, that is now corrected in
     the SAS HotFix for SAS Note 37166.

     This SYSIN input caused the U1319 abend :

        %LET SMFEXIT=CICS;
        %INCLUDE SOURCLIB(VMACSMF,VMAC110,VMXGUOW,IMACKEEP);
        DATA
        _VAR110
          /VIEW=_WCICTRN;
        _SMF
        _CDE110
        _S110

     with these cryptic messages on the SAS log:

        +No MKLEs found
        +ERROR: VM 1319: The PCE address= 1848CB54
                         and MEMORY address=000D98D8
        IEA995I SYMPTOM DUMP OUTPUT  749
        USER COMPLETION CODE=1319

     Removing /VIEW=_WCICTRN, the execution works fine with the Exit.
     Also using TYPS110 worked fine (because it doesn't have a /VIEW).

     Change 27.260 is a VERY-EXPENSIVE-ON-Z/OS-alternative to EXITCICS.

  6. You can NOT concatenate DSNAMEs behind //LIBRARY DD on z/OS; the
     job will die with a 0C4 ABEND, as documented in SAS Note 12807 or
     SAS Note 16096. The SYSMSG shows these z/OS messages:
       IGD103I SMS ALLOCATED TO DDNAME LIBRARY
       IGD103I SMS ALLOCATED TO DDNAME
       And subsequently we see this:
       IGD104I SYSDPCP.SL9.BILLPROJ.LBL4MATS RETAINED,DDNAME=SYS00004
       IEC131I 1,MXGDAY,MXGSASV9,RDJFCB ISSUED FOR DCB WITH BLANK DDNAME
     And the SAS log has this error message:
     +ERROR: SYSTEM ABEND00C4 OCCURRED IN MODULE SASVC FUNCTION VVCLCHK.

  5. The use of WHERE ALSO statement and OPEN=DEFER with a SET statement
     with multiple datasets does not work as expected; while the WHERE
     and WHERE ALSO are applied to the first dataset in the SET, only
     the WHERE expression is applied to all other datasets in the SET
     statement.  Removing OPEN=DEFER causes the WHERE ALSO to be used
     for all data sets, or, if OPEN=DEFER is required (when datasets
     in the SET statement are on tape), then the WHERE and WHERE ALSO
     expressions must be combined (with an AND) into a single WHERE.

  4. SYSTEM COMPLETION CODE=EC6 REASON CODE=0000FD1D is actually a USS
     ABEND, because SAS 9 is now a thread running as a USS process,
     but that REASON is the old SYSTEM 322 ABEND, CPU Time Exceeded.

     It can be a little cumbersome finding the appropriate doc for the
     particular failure. However, for the FD* reason codes on the SEC6
     abend here is what is documented:

     FDxx
     If xx is in the range of X'01' to X'7F', a signal was received
     causing termination and a dump to be taken.  This condition is
     usually the result of an application programming exception. For a
     description of the signal represented by the value xx, check the
     appropriate appendix "BPXYSIGH - Signal Constants" or "Signal
     Defaults" in z/OS UNIX System Services Programming: Assembler
     Callable Services Reference.

     In that referenced document, not very pleasant to read, the FD is
     fixed, and the 1D is the signal constant in Hex. The doc shows the
     decimal. So convert x'1d' to decimal and it is 29.  For 29 we see:

     SIGXCPU#   EQU  29   CPU time limit exceeded

     SAS 9 with the threading is the cause of these new USS type ABENDS,
     rather than what we are accustomed to.  So when executing within a
     thread and a failure such as the CPU timeout occurs it will surface
     the SEC6 system abend code.  From this type of abend code it is the
     REASON CODE which has the information needed to further determine
     the cause.  While MXG sets OPTION NOTHREADS (See Change 22.207),
     that simply disables thread enabled PROCs from using threads.  SAS
     itself is running as a thread; in SAS V9, the entry points were
     changed from the earlier SASHOST/SASXA1/SASXAL to SAS/SASB/SASLPA,
     which are the wrapper programs for TK environment, which makes SAS
     itself run as a thread. Hence the system requirement for an OMVS
     segment sufficient that the user environment can be "dubbed".

 3. ERROR: SYSTEM ABEND 0C4 OCCURRED IN MODULE SASXKERN FUNCTION YPCDO2
    was caused by a back-level DSNAME for the SASMSG file.

 2.  SAS Hot Fix for SN-35332 is REQUIRED for z/OS 1.10 with SAS V9.1.3,
     because  ERROR: LIBNAME XXXXXXXX IS NOT ASSIGNED  can occur for
     jobs with a completely valid //XXXXXXXX DD statement.  Jobs that
     run without error on z/OS 1.9 can fail on z/OS 1.10 using the same
     JCL and SAS/MXG datasets.  If LIBNAME is LIBRARY, there may also be
     a separate message ERROR: FORMAT MGBYTES COULD NOT BE LOADED.

     The error has NOT occurred with SAS V9.2.

     The error can be circumvented with addition of a LIBNAME statement
     that explicitly specifies the engine name:   LIBNAME LIBRARY V9  .

     But, INSTALL the Hot Fix (or, better, INSTALL SAS V9.2), as adding
     a source statement to PROD Source libraries may not be possible!

     In z/OS 1.10 IBM increased the internal work area required for its
     OBTAIN service call to 140 bytes (from 101), but SAS's work area
     was the old size; OBTAIN in 1.10 validates that now-required size,
     which caused an OBTAIN failure, which SAS surfaced with the above
     error message. The LIBNAME with ENGINE circumvention works because
     SAS doesn't need to issue an OBTAIN when the ENGINE is known.

     SN-35332 is dated March, 2009, but only one MXG site saw the error,
     and not until September, and only on one of their several z/OS 1.10
     systems!

 1.  Out of Space conditions running MXG jobs on WINDOWS may need to be
     examined by issuing DOS DIR commands at various points in the job.
     You can use
        systask command "dir d:\*.* >> c:\mxg\dirsize.txt" nowait;run;
     to APPENDed each execution to the single file dirsize.txt, or
        systask command "dir d:\*.* > c:\mxg\atstart.txt" nowait;run;
        systask command "dir d:\*.* > c:\mxg\aftersort.txt" nowait;run;
     etc to send each dir command to a separately named file.

    -You can run out of space on an empty volume if Disk Quotas have
     enabled by your System Administrator.  You can view if quotas
     are enabled and their size with these steps:
      1. Open My Computer.
      2. Right click the volume you want to enable disk quotas and click
         Properties.
      3. Click the Quota tab.
      4. Click the Enable Quota Management option.
      5. To limit the amount of disk space for new users click the Limit
         disk space to option.
      6. Set the appropriate values for the Limit disk space to and the
         Set warning level to options.
      7. Click OK.


VI.A.  WPS Technical Notes.

 1.  X

VII. CICS Technical Notes.

 1.  CICS Capacity was limited by the single QR TCB.

     In the old days, a CICS subsystem's capacity was limited by the
     amount of CPU TCB time needed for that single QR TCB.

     Based on my analysis when OTE was brand new, of the CPU time
     consumed by each of these new CICS TCBs, I planned this post to
     argue that going to OTE didn't help much, because most of the CICS
     CPU time was still being spent under the QR TCB.

     I could NOT have been more wrong!

     Analyzing new CICS/TS 4.1 Open Beta data from a VERY aggressive OTE
     exploiter site shows (from their SMF 110, subtype 2 Dispatcher
     Statistics segments, MXG CICDS and CICINTRV datasets):

     Total TCB CPU in Dispatcher Records  = 13,080 seconds
     Total TCB CPU in QR TCB              =  2,776 seconds
     Total TCB CPU in L8 TCB              = 10,298 seconds
     Total TCB CPU in all other TCBs      =      6 seconds

     Aha, you say, OTE still doesn't help; the CPU time just moved from
     the QR TCB to the L8 TCB, so the capacity limit just moved from one
     TCB to the other, right?

     Wrong again.

     While the QR TCB can attach only a single TCB, these new TCBs can
     attach multiple TCBs; in fact, the SMF data shows that the L8 TCB
     attached a maximum of 22 TCBs, each of which is a separate
     dispatchable unit.

     So, it REALLY does look like that these multiple OTE TCBs do
     eliminate the old "one-TCB" CICS capacity limitations, and does
     indeed spread your CICS time across MANY TCBs.

     (Total SRB time in the Dispatcher Records was only 65 seconds.)



VIII. Windows NT Technical Notes.

 1.  X

IX.  z/VM Technical Notes.

 1.  X

X.    Email notes.

 1.



XI.   Incompatibilities and Installation of MXG vv.yy.

 1. Incompatibilities introduced in MXG 27.yy (since MXG 26.26):
    See CHANGES.

 2. Installation and re-installation procedures are described in detail
    in member INSTALL (separate sections for each platform, z/OS, WIN,
    or *nix), with examples of common Errors/Warnings messages a new MXG
    user might encounter, and in member JCLINSTT for SAS V9.2 or member
    JCLINSTW for WPS. INSTALL also shows how to read SMF data on PCs/nix
    using the FTP ACCESS METHOD.

XII.  Online Documentation of MXG Software.

    MXG Documentation is now described in member DOCUMENT.


XIIV. Changes Log

--------------------------Changes Log---------------------------------

 You MUST read each Change description to determine if a Change will
 impact your site. All changes have been made in this MXG Library.

 Member CHANGES always identifies the actual version and release of
 MXG Software that is contained in that library.

 The CHANGES selection on our homepage at http://www.MXG.com
 is always the most current information on MXG Software status,
 and is frequently updated.

 Important changes are also posted to the MXG-L ListServer, which is
 also described by a selection on the homepage.  Please subscribe.

 The actual code implementation of some changes in MXG SOURCLIB may be
 different than described in the change text (which might have printed
 only the critical part of the correction that need be made by users).

 Scan each source member named in any impacting change for any comments
 at the beginning of the member for additional documentation, since the
 documentation of new datasets, variables, validation status, and notes,
 are often found in comments in the source members.

Alphabetical list of important changes after MXG 26.26 now in MXG 27.yy:

  Dataset/
  Member   Change    Description

  See Member CHANGES or CHANGESS in your MXG Source Library, or
  on the homepage www.mxg.com.

Inverse chronological list of all Changes:

Changes 27.yyy thru 27.001 are contained in member CHANGES.


***********************NEWSLETTER FIFTY-FOUR****************************




          MXG NEWSLETTER NUMBER FIFTY-FOUR, AUG 11, 2009.

Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE

                         TABLE OF CONTENTS

I.    MXG Software Version.
II.   MXG Technical Notes
III.  MVS, aka z/OS, Technical Notes
IV.   DB2 Technical Notes.
V.    IMS Technical Notes.
VI.   SAS Technical Notes.
VI.A. WPS Technical Notes.
VII.  CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX.   z/VM Technical Notes.
X.    Email notes.
XI.   Incompatibilities and Installation of MXG.
         See member CHANGES and member INSTALL.
XII.  Online Documentation of MXG Software.
         See member DOCUMENT.
XIII. Changes Log
     Alphabetical list of important changes
     Highlights of Changes  - See Member CHANGES.

     COPYRIGHT (C) 1984,2009 MERRILL CONSULTANTS DALLAS TEXAS USA

I.  The 2009 Annual Version MXG 26.26 was dated Feb 12, 2009.

    All sites were mailed a letter with the ftp download instructions.
    The availability announcement was posted to both MXG-L and ITSV-L.
    You can always request the current version using the form at
     http://www.mxg.com/ship_current_version.

 1. The current version is MXG 27.08, dated Oct  1, 2009.

    See CHANGES member of MXG Source, or http://www.mxg.com/changes.

II.  MXG Technical Notes

 1.  DB2 CPU Cost using MACDB2H Header Exit vs _EDB2ACC Dataset Exit.

     An SMF file of 58GB of 35 Million SMF records, 17 Million DB2 101
     Subtype 0 (DB2ACCT) was processed using the MACDB2H "Header Exit"
     or using the _EDB2ACC "Dataset Exit" to select/output 36998 obs,
     with and without using the MACFILE "SMF Header Exit" to skip the
     other SMF records in the file.  The INPUT program was TYPEDB2, with
     _NDB2 nulling out the OUTPUT of all but DB2ACCT; however, the _NDB2
     only nulls the OUTPUT of those other datasets - the DB2 records are
     still fully decoded to the point of the OUTPUT.  The _EDB2ACC exit
     selected which observations were to be output to DB2ACCT, whereas
     the MACDB2H code threw away the unwanted records as soon as the DB2
     header was INPUT, so it eliminated all of the decoding code for the
     unwanted records.  Only 11 variables were KEPT in DB2ACCT.

        Records Read           Exit Used  CPU Time mm:ss   DB2ACCT obs
         ALL 35MM Records      _EDB2ACC       23:32         36998
         17MM ID 101 ST 0        None         14:33         17MM
         17MM ID 101 ST 0      _EDB2ACC       13:59         36998
         17MM ID 101 ST 0       MACDB2H        6:38         36998

     Skipping half the records in the MACFILE exit dropped the CPU time
     from 23 minutes to 14 minutes, but that run output all 17 MM obs.
     Using the _EDB2ACC reduced that time by 34 seconds, showing that
     the cost to write 17MM vs 36000 (short) observations is cheap.
     Then, using MACDB2H to eliminate the decoding dropped CPU time to
     only 6 minutes.
     The MACDB2H exit was used to "look ahead" and INPUT the QMDA fields
     that were used in the selection. (Note that SUBTYPE had to be INPUT
     in the MACFILE exit because SMF 101 records do NOT have the subtype
     bit enabled; that has been corrected in VMACSMF in MXG 27.03 which
     inputs the SUBTYPE for the 101, 110, 115, and 116, in spite of the
     absence of the bit that says the subtype field is valid.)

          %LET MACFILE=
               %QUOTE ( IF ID=101 ;
                        INPUT @19+OFFSMF SUBTYPE &PIB.1. @;
                        IF SUBTYPE=0;
                      )    ;
            %LET MACDB2H=
               %QUOTE (   IF OFFQMDA GT 0 AND NRQMDA GT 0;
                          OFFTEST=OFFQMDA-3+OFFSMF;
                          INPUT @OFFTEST+41  TESTCNAM $EBCDIC8.
                                             TESTCTYP $EBCDIC8.
                          @;
                          IF TESTCNAM='BATCH' OR TESTCTYP='BATCH';
                       );
          %LET MACKEEP=
              %QUOTE(  _NDB2
                       MACRO _SDB2                 %
                       MACRO _WDB2ACC  PDB.DB2ACCT %
                       MACRO _VDB2ACC KEEP=JOB SYSTEM DB2SRBTM DB2TCBTM
                                     QB1CGET QB2CGET QB3CGET QB4CGET
                                     QB1CRIO QB2CRIO QB3CRIO QB4CRIO %
                   );
           %INCLUDE SOURCLIB(TYPEDB2);


III. MVS, a/k/a z/OS, Technical Notes.


15. APAR OA27752 corrects possible low counting of SMF 30 EXCPs in the
    DD Segments; IBM field SMF30BLK in the DD segments is EXCPTODD and
    all of the per-device EXCP counts (EXCP3380 etc.) in MXG TYPE30xx
    datasets.

    DD LEVEL EXCP COUNT DECREASED BY 5% GOING TO Z/OS 1.7 FROM 1.4.

    Since migration to z/OS R7 from R4, customer noticed the DD level
    EXCP count (SMF record type 30 SMF30BLK or type 15 SMFEXCP) is
    slightly less than it should be.  For example, when a program does
    10,000 blocks BSAM WRITE, SMF30BLK /SMFEXCP shows (1st) 9,795 (2nd)
    9,801 (3rd) 9,831 (4th) 9,838 ..  The count varies each time and
    2-3% less than 10,000.  This,typically, occurs on PSE (extended
    format) with multiple extents.  The cause seems to be the fix of
    OA05045 (FIN) for IEASMFEX.  With this fix code, IEASMFEX sometimes
    returns RC4 to SMFIOCNT macro issuer when local/CML lock is not
    available and so it does not update DD level EXCP count. But it
    looks nobody cares about this RC04 from IEASMFEX.

    For PSE case, SMFIOCNT macro is issued from ICYDIE.

    The SMF30BLK field of the SMF type 30 record reports the block I/O
    counts at the DD level. The value in this field may be slightly low
    at releases above z/OS 1.6.  Lower values in this field can be
    attributed to lock contention for updating the TCT I/O Table
    (TCTIOT) control block, where the interim count value for this field
    is maintained. Serialization for updating the TCTIOT was introduced
    at z/OS 1.7 causing some attempts to increment the count in the
    TCTIOT to be rejected.
    PROBLEM CONCLUSION:
    Internal SMF services are updated to use a different serialization
    mechanism to update the TCTIOT.  Although this solution will not
    completely eliminate the possibility that a TCTIOT update can be
    rejected, resulting in lower DD level block I/O counts, it will
    reduce the possibility of this.

14. APAR OA29803 corrects JES2 SMF 26 variable SMF26WCL when the Service
    Class was changed; it has the same value as SMF26WOC, the initial
    WLM Service Class, without this APAR.  Jul 20, 2009.

13. APAR OA27563 corrects errors in SMF ID=42 ST=21,24 and 25 records:
     -SMF 42 subtype 25 contains an incorrect triplet count.
      Subtype 25 contains x'0003' at offset 18 for the number of
      triplets present, but there are actually 4 triplets.
     -SMF 42 subtype 21 and 24 userID token not correctly formatted.
    And now, after Change 27.155 circumvented the mislocated ICHRUTKN,
    a new APAR OA29737 adds these notes of the fixes in the original
    OA27563 APAR, with no new PTF:
     -Record has truncation - Solution: Apply existing APAR OA27563.
     -SMF42 SUBTYPE24 AND SUBTYPE21 USER INFORMATION SECTION
      Correct start location is skewed by +2 bytes.
     -SMF42 ST24 and ST21 records are incorrectly created with a 2
      byte field ( SMF42P#A or SMF42LNA ) for Alias Names section
      when there are no alias names. Jul 13, 2009.

12. From the text of APAR OA26104 New Function: Work Dependent Enclaves:

    "For SQL statements that are eligible for parallel query execution,
    DB2 creates additional independent enclaves.  These enclaves are
    created under subsystem DB2 (which the DBM1 space is connected to)
    and are classified according to the classification rules for
    subsystem DB2. In order for these enclaves to be classified
    correctly, the classification rules for subsystem DB2 must be
    updated to replicate existing classification rules for every
    subsystem that may cause a stored procedure to run that exploits CPU
    parallelism.  Furthermore, these additional independent enclaves are
    regarded as new transactions."

    Updates to
      MVS Programming: Workload Management Services
      SA22-7619-14 / SA22-7619-16 / SA22-7619-17
      Section "Enclave Resource Accounting":

      The accounting for resources consumed by an enclave depends on
      whether it is an independent, work-dependent, dependent, or a
      foreign enclave. (...)

      For an independent enclave and work-dependent enclaves, CPU
      service is included in the SMF 30 record of the owning address
      space, and in the SMF 72 record for the enclave service class or
      performance group period. MSO service is not calculated for either
      kind of enclave.

      For dependent, work-dependent, and independent enclaves, IOC
      service is included in the SMF 30 and 72 records associated with
      the address space where the enclave work is executing. SRB service
      for enclaves is always zero.(...)

      Table "Enclave Characteristics and Resource Accounting"
        ** NOTE: if a cell is omitted here, it's content hasn't
              changed  **
        Dispatchable unit type:
          Work-dependent enclave: SRBs and/or tasks
        New transaction:
          Work-dependent enclave: no
        Owner:
          Dependent enclave:
            Depends on the TYPE parameter passed to IWM4ECRE:
            If TYPE=DEPENDENT, the home a.s. at the time the
            service was issued.
            If TYPE=WORKDEPENDENT, the creating (dependent)
            enclave's home a.s.
            If TYPE=MONENV, the a.s. associated with the
             monitoring environment - see note 1
          Work-dependent enclave:
            owner a.s. of the creating independent enclave
        Server:
            a.s. where enclave work is dispatched
        Service class/report class:
          Work-dependent enclave:
            same as owning independent enclave's
        CPU time:
          Independent enclave:
            owner's SMF30CPT - MXG CPUTCBTM (total)
            owner's SMF30ENC - MXG CPUENCTM (independent and
                                             work-dependent only)
          Work-dependent enclave:
            owner's SMF30CPT - MXG CPUTCBTM (total)
            owner's SMF30ENC - MXG CPUENCTM (independent and
                                             work-dependent only)
        CPU service by address space:
          Independent enclave:
            owner's SMF30CSU - MXG CPUUNITS (total)
            owner's SMF30ESU - MXG ENCLCPSU (independent and
                                             work-dependent only)
          Work-dependent enclave:
            owner's SMF30CSU - MXG CPUUNITS (total)
            owner's SMF30ESU - MXG ENCLCPSU (independent and
                                             work-dependent only)
        CPU service by period:
          Independent enclave:    enclave's R723CCPU - MXG CPUUNITS
          Dependent enclave:      owner's R723CCPU - MXG CPUUNITS
          Foreign enclave:        enclave's R723CCPU - MXG CPUUNITS
          Work-dependent enclave: enclave's R723CCPU - MXG CPUUNITS
        DASD I/O connect time by a.s. (see note 3)
          Independent enclave:    owner's SMF30EIC
                                  (independent and work-dependent only)
          Dependent enclave:      owner's R723CCPU - MXG CPUUNITS
          Foreign enclave:        enclave's R723CCPU - MXG CPUUNITS
          Work-dependent enclave:
            owner's SMF30Eic (independent and work-dependent
                              only)
        DASD I/O connect time by period (see note 3)
          Independent enclave:    enclave's R723CICT
          Dependent enclave:      owner's R723CICT
          Foreign enclave:        enclave's R723CICT
          Work-dependent enclave: enclave's R723CICT
        DASD I/O counts by address space:
          Independent enclave:    owner's SMF30EIS
            (independent and work-dependent only)
          Work-dependent enclave: owner's SMF30EIS
            (independent and work-dependent only)
        DASD I/O counts by period:
          Independent enclave:    enclave's R723CIRC
          Dependent enclave:      owner's R723CIRC
          Foreign enclave:        enclave's R723CIRC
          Work-dependent enclave: enclave's R723CIRC
        Page delay samples, with storage mgt. (see note 4)
          Work-dependent enclave: enclave's R723CSPV - MXG PCTDLSPV
        Page delay samples, without storage mgt. (see note 4)
          Work-dependent enclave: enclave's R723CAXM - MXG PCTDLAXM
        IOC service:
          Work-dependent enclave:
            server's SMF 30 and 72 records
        SRB service:
          Work-dependent enclave: n/a
        MSO service:
          Work-dependent enclave: n/a


11. APAR OA29102 (HIPER,PERVASIVE,DATALOSS) for HSM corrects an error
    in z/OS 1.8 and 1.9 that corrupts Create Date when a VSAM file was
    RECALLed or RECOVERed; the invalid value 1901.921 is stored, and
    it is possible VSAM datasets with that create date could have been
    prematurely deleted.  Among more details in the APAR text is this
    note with regard to possible DATALOSS:

      4) Recover datasets that were prematurely deleted.
      To determine if any VSAM datasets were deleted, first determine
      the window that VSAM datasets were susceptible to the problem.
      Determine the time frame between when PTFs UA46732/UA47067 R180
      or UA46733/UA47068 R190 were applied and when the fixing ++APAR
      or PTF was applied.  For this time frame, collect all SMF
      records type 60 to 65 and HSM FSR records (SMF 241 if using the
      default value for SETSYS SMF(type)+1).  The SMF data along with
      the date of when the ptfs were applied will be needed by IBM
      support to determine what datasets may have been prematurely
      deleted.  Contact IBM support once you have the all of the
      above information.

    You might detect any current VSAM datasets with that Invalid Create
    Date of 1901.921 by reading the EXPORT of your CATALOG with MXG's
    TYPECTLG program; that invalid value for OWNCREDT should print notes
    on the SAS log; once I see an example of how that is stored in three
    bytes of packed decimal, I will detect that value and format it so
    you can identify all such VSAM datasets in your catalog.

10. APAR OA28459 for SMF 42 Subtype 6 removes an exposure to SMSVSAM
    ABEND 0C4 in IGWMCOLP in SMSVSAM.

 9. APAR PK83021 reports DFH$MOLS fails with ABENDU0103 if the SMF110
    records are longer than 32754.  The PTF changes the LENGTH in the
    DFH$MOLS created DFSORT RECORD control statement from the wrong
    32752 value to the proper maximum of 32756 bytes for an SMF record.

 8.  Work-dependent Enclave Resource Accounting.

     Documentation in "MVS Programming: Workload Management Services",
     SA22-7619, Chapter 3. Creating and Using Enclaves has been updated
     with more extensive information, but this summarizes whats where:

     The accounting for resources consumed by an enclave depends on
     whether it is an independent, work-dependent, dependent, or a
     foreign enclave.

     For an independent enclave and work-dependent enclaves, CPU service
     is included in the SMF 30 record of the owning address space, and
     in the SMF 72 record for the enclave service class or performance
     group period. MSO service is not calculated for either kind of
     enclave.

     For dependent, work-dependent, and independent enclaves, IOC
     service is included in the SMF 30 and 72 records associated with
     the address space where the enclave work is executing. SRB service
     for enclaves is always zero.


 7.  Measuring the amount (length) of a tape volume that has data, is no
     longer possible as discussed in this thread on IBM-Main in June 09:

        Length of tape (in metres) nowadays is bulls*t:

        1. Serpentine recording. It's like audio cassettes with A and B
        side, but modern tapes have multiple dozen of "sides" (72 for
        TS1130 aka Jaguar3).  Because of that real physical tape length
        should be multiplied by "number of sides".

        2. Blocking. Space (length) occupied "brutto" depends on the
        block size, both logical and physical.  Physical means modern
        tape drives do its own reblocking "under the cover".

        3. Last but not least: COMPRESSION.  While you may find out how
        much of a tape has data bytes (maybe provided by RMM/CA-1), of
        course "the number of bytes" has little to do with dataset(s)
        size, and you cannot predict exactly how well your future data
        will be compressed.  Of course you can always estimate it using
        "not less than" operator, but such estimates will be veeeeery
        inaccurate, unless you record really non-compressible data.

        This post was then added to the thread:

        Actually, that will depend on the TAPEMAP utility. Some (the one
        included with the CA-1/Copycat and CA TLMS/Copycat utilities for
        example) will actually get the physical tape position from the
        device at the end of each file to give an accurate position map
        of all files on the tape. But you are correct, based strictly on
        the amount of data written does nothing to determine how much of
        the tape has been used; not since IDRC was introduced.

 6.  APAR PK84730 is an error in IBM ftp introduced in z/OS 1.10 that
     showed up when the SAS ftp access method tried to read a data file
     that was on tape.  There was no ftp error message; the problem only
     surfaced with this SAS message on the log when SMF records were
     read with MXG under z/OS 1.10:
             NOTE: Invalid data for SMFTIME in line 1 3-10.
     but the tape was read without that message under z/OS 1.10.

     However, the APAR text notes that the error could fail with
         200-Conflicting SITE operands RDw and READTAPEFormat.
             READTAPEFormat ignored.

     IBM Support has opened that APAR and is working on the PTF, but by
     modifying the ftp command to have two site commands, this syntax
     has circumvented the error:

            FILENAME SMF FTP
               ("'MXG.SMF.PROD.DAILY(-00)'"
                "'MXG.SMF.DEVA.DAILY(-00)'"
                "'MXG.SMF.TST1.DAILY(-00)'")
                USER='username' HOST='where.i.loading.from'
                RCMD='SITE RDW;SITE READTAPEFORMAT=S'
                S370VS LRECL=32760 PASS='password' DEBUG;


 5.  APAR PK77275 for SMF 120 Subtype 9 corrects a problem with the CPU
     usage subsection not being generated when enabled via the MODIFY
     command.

 4.  APAR PK83225 for SMF 120.
     SMF data is not returned by the data collector(DC) if SMF type 120
     subtype 8 (Web container interval) records have not been written by
     the pap server, detected by the CYN1 U83 exit, and recorded into
     the CYN1 subsystem. In our Web console BE, this message is
     displayed:
     CYNVE0388E The data is currently unavailable.
     This situation exists until Http traffic is received. Those
     customers using WebSphere as an EJB server without Web container
     activity are not seeing any data in the SMF Data page.  With this
     APAR, CAM will be changed so that the DC will return SMF data once
     SMF 120-3 ( server interval) records are detected.  Web container
     activity no longer is required for this page to be populated.

 3.  APAR OA28499 is opened for an issue that caused PTF UA46066 (for
     APAR OA27699) to be PE'd.  That was a PTF that is recommended if
     you use logstreams for SMF, but it causes a buffer shortage if you
     are instead using MANx datasets and you have a high volume of SMF
     records.  The 'IEE986E SMF HAS USED    25% OF AVAILABLE BUFFER'
     messages are NOT issued, but you will get RC 28 from SMFWTM.  The
     APAR OA28499 is open for z/OS 1.10, but the error may apply to
     lower levels with PTF UA46066 applied.

 2.  APAR OA27752 reports incorrect reduction in recorded EXCP counts in
     DD segments in SMF 30 (IBM SMF30BLK, all EXCPxxxx variables in
     TYPE30 and PDB.STEPS/PDB.JOBS except EXCPTOTL), and in SMF 14/15
     (IBM SMFEXCP, MXG EXCPCNT in TYPE1415), migrating from z/OS 1.4
     to 1.7.  No PTF or explanation, so it's not clear if this is ONLY
     a z/OS 1.7 issue or if it impacts subsequent z/OS releases.  Text
     here will be updated when a PTF exists for this APAR.  18Feb2009.

 1.  APAR Identifier OA29582 adds new EMPTYEXCPSEC(SUPPRESS) option in
     SYS1.PARMLIB to suppress all empty EXCP entries, so the SMF 30
     records will NOT have DD-level EXCP Segments for SYSOUT, which can
     significantly reduce the size of SMF 30 records, and APAR OA32914
     corrects an initial error where that option was not honored for
     Dynamic Allocations.
     APAR PM17542 enables DB2 V10 to use the S99DASUP FLAGS2 bit to do
     more than remove EMPTY DD segments: S99DASUP completely removes all
     DD segments for the DB2 address space records.
     APAR PM17542 also adds the new parameter for PARMLIB's ALLOCxx
     SYSTEM MEMDSENQMGMT(ENABLE) for z/OS 1.12 that allows DB2 to manage
     its dataset ENQs in memory.

     Variable SMF30DAS='EXCP*SEGMENTS*THAT WERE*SUPPRESSED' reports how
     many DD segments were suppressed.

     The option prevents the creation of null segments in SMF 30 records
     for SMS Candidate Volumes, and could significantly reduce the size
     of your step and job termination records, especially if your site
     has a default of (SYSDA,5) for every allocation!!

     The MVS Initialization and Tuning Reference, under the SMFPRMxx
     parmlib parameter definitions, EMPTYEXCPSEC:
       SUPRESS specifies that the system suppress the creation of empty
       EXCP sections.  Empty sections can be the result of non-dataset
       allocations, such as DD DUMMY, or for spool file allocations
       (i.e., SYSIN, SYSOUT JES DDs), or for non-allocated candidate
       volumes in the SMS storage group.

     One MICS site reported a 28% reduction in CPU time with removal of
     all of their empty EXCP segments.

        New EMPTYEXCPSEC option in PARMLIB is only in z/OS 1.10+.
        While EMPTYEXCPSEC option is documented in the z/OS 1.9 SMF
        manual in Section 13.34.2.7 (Execute Channel Program (EXCP)
        Section) of z/OS MVS System Management Facilities (SMF) Document
        SA22-7630-16, for z/OS 1.9, testing on a z/OS 1.9 system
        resulted in

        IEE945I UNRECOGNIZABLE OPTION 'EMPTYEXCPSEC' IN PARMLIB INPUT
        IEE947I '/* DEFAULT RETRY                 */
                 EMPTYEXCPSEC(SUPPRESS)' SKIPPED DUE TO PREVIOUS ERROR

     IBM has confirmed that the option only exists in z/OS 1.10, where
     it is listed in the Release Guide as a 1.10 enhancement


IV.   DB2 Technical Notes.

 1. APAR PK84187 corrects QWSAPSRB "Negative" value, but would be seen
    in MXG as a very LARGE positive value.  Due to timing conditions,
    the value for QWSAPSRB_zIIP could be greater than the total SRB time
    for the address space.  This could result in an incorrect value for
    QWSAPSRB.
    PROBLEM CONCLUSION: The total SRB time is loaded after the zIIP
    time.  Thus the total time should exceed the total zIIP time.  This
    will result in correct values for QWSAPSRB.

V.   IMS Technical Notes.

VI.  SAS Technical Notes.

 8.  "ERROR 455-185: Data set was not specified on the DATA statement"
     is usually caused by an incorrect _VARxxxx token in the DATA
     DATA statement (e.g., spelling _VAR7072 as _VAR70720 which does
     not exist, so SAS thinks that's just a variable name), or an
     override that nulled out the _VARxxxx definition.

 7.  NEVER use FLOWOVER; if you MUST circumvent STOPOVER, then you MUST
     use MISSOVER instead.  As documented in the INSTALL member, if you
     get an INPUT STATEMENT EXCEEDED RECORD LENGTH error condition, the
     MXG job will stop at that point because the MXG default option on
     the INFILE statement is STOPOVER (and the job ends with a USER 999
     ABEND, because MXG also specifies option ERRORABEND).
     Once you have sent the full log with the hex dump of the record to
     support@mxg.com, so we can diagnose the cause (usually, due to a
     new version of the product that created the record read with an old
     version of MXG Software!), you can circumvent the error using:
       MACRO STOPOVER MISSOVER %
       %INCLUDE SOURCLIB.....
     which will change the MXG STOPOVER default to MISSOVER (without you
     having to EDIT the MXG code that has the "STOPOVER" text).

     With MISSOVER, the variables MXG is trying to INPUT beyond the end
     of the record will be set to a missing value, which may have other
     unintended consequences, but the next logical record in the
     input file is read.  But with FLOWOVER, the variables beyond the
     end of this current logical record will be populated from the NEXT
     logical record, and thus that next record will NEVER be examined
     by MXG for its record ID, etc.  Using FLOWOVER will GUARANTEE that
     the next record (or records) will be SKIPPED.

 6.  "Why did MXG translate lower case text into upper case?"  Actually,
     it's the SAS system option CAPS/NOCAPS that determines, at INPUT,
     whether lower case characters are unchanged (NOCAPS), or whether
     are all translated to uppercase (CAPS), but CAPS/NOCAPS option is
     NOT used for input from "external files" (i.e. essentially all MXG
     fields are input from external files), so MXG preserves original
     case.
     Note that NOCAPS only applies to when the Data Set is created; once
     you have created a mixed-case variable, you cannot use OPTIONS CAPS
     to then print it in upper case.

    -Specifically, the SAS help documentation of CAPS states:

        CAPS
        specifies that SAS translate lowercase characters to uppercase
        in these types of input:

        -data following CARDS, CARDS4, DATALINES, DATALINES4, and
         PARMCARDS statements
        -text enclosed in single or double quotation marks
        -values in VALUE and INVALUE statements in the FORMAT procedure
        -titles, footnotes, variable labels, and data set labels
        -constant text in macro definitions
        -values of macro variables
        -parameter values passed to macros.

        Note: Data read from external files and SAS data sets
              are NOT translated to uppercase.

        NOCAPS
        specifies that lowercase characters that occur in the types of
        input that are listed above are not translated to uppercase.


 5.  Character variables IMPORTed from Excel Spreadsheets with SAS V9.2
     have very different lengths than when IMPORTed with SAS V9.1.3, but
     V9.2 does warns you that it truncated a character field. With 9.1.3
     all character variables are length $255 (even when the Excel field
     is longer, and 9.1.3 did NOT warn that a variable was truncated).
     With V9.2, most character variables have length/format/informat set
     to the actual length of the Excel field.  However, if the length is
     greater than 255, the V9.2 character variable is truncated to $255,
     with this WARNING message to alert you to that truncation:

       Failed to scan text length or time type for column .

     SAS Note 33257 documents how to change the Windows Registry
       HKEY_LOCAL_MACHINE-SOFTWARE-Microsoft-Jet-4.0-Engines-Excel
     key "TypeGuessRows" to a zero, which increases the number of Excel
     rows (that will be read to determine the variable attributes) from
     the default of 8 to 16384, which causes SAS V9.2 to use the maximum
     field length as the character variable's length, eliminates the
     truncation, and eliminates the warning message.  May 28, 2009.

 4.  SAS Problem Note SN-035112 documents HotFix E9BC81, which corrects
     the error discussed in March, 2009, in the text of Change 27.014,
     in MXG 27.02, which applied the ATTRIB TRANSCODE to all MXG-built
     character variables that contain HEX data (i.e., with $HEX format
     or with an MXG-created FORMAT that maps character hex values).
     The TRANSCODE=NO attribute is needed on all of these variable so
     that, if you move that SAS dataset from EBCDIC to ASCII platforms,
     those HEX-containing character values are NOT translated, since
     TRANSCOD=YES is the SAS default, and that would corrupt the data.
     Prior to the HotFix, the TRANSCODE attribute was NOT passed into a
     dataset that was created by a SAS VIEW, but that is corrected now
     by the HotFix.

 3.  Perhaps the FINAL note on MEMSIZE= parameter, for SAS on z/OS.
     Ever since SAS V9 in 2000, I have STRONGLY recommended that you
     NEVER have a MEMSIZE= parameter in your CONFIGxx members (MXG's or
     SAS's CONFIG options.) SAS Technical support has also discouraged
     the use of MEMSIZE=, as it can ONLY limit the virtual storage to
     less virtual storage than is actually available to the address
     space.  but prior to SAS 9.2 it was not enforced.  SAS 8 through
     SAS 9.1.3 only reset MEMSIZE value if what is set is greater than
     REGION- MEMLEAVE.  In SAS 9.2, the logic is changes, and SAS now
     will always reset the MEMSIZE= option to the (REGION-MEMLEAVE)
     value. Note that this ONLY applies to SAS on z/OS platforms.
     MEMSIZE can still needed on some unix and windows platforms.

 2.  SAS V9.2 on z/OS requires about 20MB more virtual storage for the
     same job than SAS V9.1.3 required.  For example, an enhanced
     BUILDPDB with additional SMF records that ran in 72MB with 9.1.3
     required 92MB when executed with SAS V9.2 Phase 1:

                  Data   Program   Total
         9.1.3    73728   3308     77036   KB, SAS Total Memory
                  EXT    SYS
                  73728  12344     86072   KB, IBM IEF374I, last two

         9.2      92934  17426    109360   KB, Total Memory
                  94132  12276    106408   KB, IBM IEF374I, last two

     Note that it is the "Data" or IEF374I "EXT" value that is limited
     by the REGION size (JOB/STEP); the "Program" or (second) SYS value
     is the area below the 16MB line.

     So there was right at 20MB virtual more needed by 9.2, but no
     significant difference between the IEF374 and Total Memory.
    -z/OS 1.12 message IEF032I/33I replaced IEF374I/276I.

 1.  A problem with SAS Connect Logon Scripts not working when z/OS was
     upgraded to z/OS 1.10, in which the telnet TSO logon does not
     a ready prompt, was due to an IBM error which is corrected by IBM
     APAR OA26966 and PTF UA44635.


VI.A.  WPS Technical Notes.

 1.  X

VII. CICS Technical Notes.

 1.  X


VIII. Windows NT Technical Notes.


IX.  z/VM Technical Notes.


X.    Email notes.

 1.



XI.   Incompatibilities and Installation of MXG vv.yy.

 1. Incompatibilities introduced in MXG 27.yy (since MXG 26.26):
    See CHANGES.

 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 JCLINST9 for
    SAS V9.1.3 or JCLINST8 for SAS V8.2.

XII.  Online Documentation of MXG Software.

    MXG Documentation is now described in member DOCUMENT.


XIIV. Changes Log

--------------------------Changes Log---------------------------------

 You MUST read each Change description to determine if a Change will
 impact your site. All changes have been made in this MXG Library.

 Member CHANGES always identifies the actual version and release of
 MXG Software that is contained in that library.

 The CHANGES selection on our homepage at http://www.MXG.com
 is always the most current information on MXG Software status,
 and is frequently updated.

 Important changes are also posted to the MXG-L ListServer, which is
 also described by a selection on the homepage.  Please subscribe.

 The actual code implementation of some changes in MXG SOURCLIB may be
 different than described in the change text (which might have printed
 only the critical part of the correction that need be made by users).

 Scan each source member named in any impacting change for any comments
 at the beginning of the member for additional documentation, since the
 documentation of new datasets, variables, validation status, and notes,
 are often found in comments in the source members.

Alphabetical list of important changes after MXG 26.26 now in MXG 27.01:

  Dataset/
  Member   Change    Description

  See Member CHANGES or CHANGESS in your MXG Source Library, or
  on the homepage www.mxg.com.

Inverse chronological list of all Changes:

Changes 27.yyy thru 27.001 are contained in member CHANGES.

***********************NEWSLETTER FIFTY-THREE***************************




          MXG NEWSLETTER NUMBER FIFTY-THREE, FEB  3, 2009

Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE

                         TABLE OF CONTENTS

I.    MXG Software Version.
II.   MXG Technical Notes
III.  MVS, aka z/OS, Technical Notes
IV.   DB2 Technical Notes.
V.    IMS Technical Notes.
VI.   SAS Technical Notes.
VI.A. WPS Technical Notes.
VII.  CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX.   z/VM Technical Notes.
X.    Email notes.
XI.   Incompatibilities and Installation of MXG.
         See member CHANGES and member INSTALL.
XII.  Online Documentation of MXG Software.
         See member DOCUMENT.
XIII. Changes Log
     Alphabetical list of important changes
     Highlights of Changes  - See Member CHANGES.

     COPYRIGHT (C) 1984,2009 MERRILL CONSULTANTS DALLAS TEXAS USA

I.  The 2008 Annual Version MXG 25.25 was dated January 28, 2008.

    All sites were mailed a letter with the ftp download instructions.
    The availability announcement was posted to both MXG-L and ITSV-L.
    You can always request the current version using the form at
     http://www.mxg.com/ship_current_version.

 1. The current version is MXG 26.26, dated Feb  3, 2009.

    See CHANGES member of MXG Source, or http://www.mxg.com/changes.

II.  MXG Technical Notes

 1. Recent measurements of the revised MXG QA Stream (no PROC COPYs).

    With SAS V9.1.3 and MXG 26.09 on two z/Series machines:
      On z/OS:
        Machine    Elapsed   CPU   Virtual           SAS
         SU_SEC    minutes   min   storage   OpSys  Version
          21621      90.7   16.50   123558K   z/OS   9.1.3
           9708     104.8   45.19   124340K   z/OS   9.1.3
         3.2GHz       9.4    6.2    146173k   WinXP  9.1.3
         3.2GhZ      10.0    6.25   101840k   WinXP  9.2


III. MVS, a/k/a z/OS, Technical Notes.

21.  One site experienced several minutes of extremely bad performance
     that was caused by an HDS hard disk failure: HDS says the impact of
     future failure can be lessened by turning on SOM (System Option
     Mode) 359.   When the controller hardware detects a DASD sector
     error, it reassigns that sector to a spare sector and rebuilds it
     there.  If SOM 359=OFF, the time out value to indicate sector
     failure and initiate reassignment of the sector is 4.5 sec and
     after eleven sector failures the hard drive is blocked and disk
     sparing initiated.  With SOM 359=ON the time out value for sector
     failure and reassignment is 3 sec and after three such failures the
     hard drive is blocked and disk sparing initiated.  HDS says that
     "given the proactive approach to maintenance" at the site, they
     recommend setting SOM359 to ON for the USPV controllers.  This
     might cause more hard drive sparing to be triggered in the
     environment but looks like it would lower the adversely impacted
     time when sparing occurs from about one minute to about ten
     seconds.


20. APAR PK78309 for WebSphere SMF 103 subtype 2 record documents four
    previously internal-use fields, but they have been decoded by MXG
    for years in variables THWANSSL THWASSL THWAASYN THWAMSGQ

19. SYNCSORT 1.3 - Records Dropped by Sort program.
    The sort processes to good End of Job, but records are dropped.
    This problem occurs when one or more empty datasets are in the
    SORTIN concatenation, and PAV aliases are assigned to the SORTIN
    I/O, and SyncSort screws up their EOV processing.
    Fix is EW6629

18. APAR PK77184 reports QPACCLS7_ZIIP for all packages is higher than
    the value of QWACTRTT_ZIIP when there are repeated calls to a
    trigger without nesting results.

17. APAR OA26693 reports High CSM 32K ECSA buffer usage caused storage
    shortage, when HiperSockets users were running with either a zIIP-
    enabled application such as DB2 performing socket API while on a
    zIIP, or, running with TCP/IP zIIP IPSec enabled.

16. APAR OA26761 reports missing channel paths in RMF IOQ data when new
    channel paths that were added to existing devices by a Dynamic
    Activation of an I/O configuration.

15. APAR OA26488 reports performance enhancements for queued XES locking
    requests and corrects the count of requests that are CHNGD from
    synchronous to asynchronous in the RMF Coupling Facility Structure
    Activity report.

14. APAR OA26753 reports no Link Statistics from 2107 with Microcode R3.

13. APAR OA26842 reports that READTIME was binary zeros in SMF 42
    subtype 9 records.

12. FMIDs identify the base level of an IBM product; for z/OS they are:
      HBB7709  z/OS 1.6
      HBB7720  z/OS 1.7
      HBB7730  z/OS 1.8
      HBB7740  z/OS 1.9
      HBB7750  z/OS 1.10 (a guess)

11. APAR OA26842 reports SMF 42 subtype 9 field S42RDST, the time part
    of READTIME is not being populated.

10. APAR OA26555 reports HIGH CPU IN VLF address space, and possible
    causes.

 9. APAR II13495 is a long discussion of "HOW DFSORT TAKES ADVANTAGE OF
    64-BIT REAL ARCHITECTURE".

 8. APAR OA08719 reports FMID HBB7709, z/OS 1.6, SMF 30 records contain
    zeros in the step termination (subtype 4) record for IFA CPU time
    fields "SMF30_TIME_ON_IFA" and "SMF30_TIME_IFA_ON_CP" which are MXG
    variables CPUIFATM and CPUIFETM in PDB.STEPS an TYPE30_4 datasets.
    Those fields were filled in from fields that were erroneously
    cleared before the record was written.

 7. What products execute on zIIPs?
    This note will be updated as new programs/products are reported:
   - IBM DB2 and DB2 Utilities
   - IBM Communications Server for IPSEC
   - IBM Communications Server for Hipersocket Large Messages.
   - IBM XML, some parts of the parser.
   - IBM Extended Remote Copy (XRC) data mover address spaces (OA23174).
   - SYNCSORT
   - IBM Scalable Architecture for Financial Reporting (SAFR)
   - System Data Mover (SDM) benefits (z/OS Global Mirror).
   - Encryption and Compression:
   - CA-Vtape (option to use software compression to compress the cache)
   - CA Brightstore Tape Encryption (both compression and encryption).
   - CA Datacom
   - CA Netmaster for IP Packet Analysis (also uses zAAPs)
   - CA Insight for DB2 (when the SQL is already running on a zIIP.
   - CA IDMS R17 offloads some system mode time to zIIPs.
   - PKZIP
   - Neon Enterprise Software - IMS Utilities
   - Progress Software - Data Direct
   - Phoenix Software - Most products, including (E)JES
   - Shadow 7 (from DataDirect, uses zIIP and zAAP)
   - BMC: Effective August, 2009, the majority of CMF data collectors
     (BMC's replacement for RMF) were converted from TCB to SRB and
     became eligible for dispatching to zIIP;

     An earlier version of this list showed DFSORT but that is not
     correct.  IBM's official position, Jan 21, 2009 is stated:
        At this time, IBM has no plan for enabling DFSORT to exploit the
        system z9 Integrated Information Processor (zIIP). IBM realizes
        DFSORT remains a prominent component of our customers' batch
        workloads. However, the added controls that would need to be
        implemented in order to maintain our high standards for
        performance, reliability and system integrity are not justified
        in view of estimations that there is a low offload potential and
        the value to clients may be marginal.  IBM will continue to
        focus its DFSORT development efforts on the enhanced function,
        performance, reliability and service items that we believe
        provide the most value to our clients.  The foregoing represents
        IBM's current intent and is subject to change.
     But, now, August 1, 2009, APAR PK85856, provides this statement:
     "DFSORT support for additional zIIP offload by DB2 Utilities.  In
     conjunction with DB2 APAR PK85889, this PTF enables DB2 Utilities
     to offload portions of sort workload to zIIPs when they are
     available.

 6. APAR OA26611 reports HyperPAV can cause RMF DASD Device TYPE74 data
    can report misleading data for CONNECT, DISCONNECT, PEND & RESPONSE
    times.

 5. APAR OA26077 for z/OS 1.10 reports an undetected loss of data with
    a multi-volume tape dataset with QSAM and BUFNO GT 1 or BSAM with
    NCP GT 1 specified, impacting applications such as HSM, IEBGENER,
    IDCAMS and DB2.

 4. APAR OA25243 for RMF III notes that GDACSAHWM and GDAECSAHWM report
    the high water marks of CSA and ECSA allocations from the (E)CSA
    areas, but fail to take into account the use of (E)CSA for (E)SQA
    allocations, giving a misleading representation of the amount of the
    (E)CSA areas available for additional (E)CSA allocations.

 3.  APAR OA26027 for the IFASMFDL program (the "SMF DUMP" if you send
     your SMF data to the System Logger instead of to a VSAM file) fixes
     an incorrect use the START parameter; without the PTF for the APAR,
     records were copied from a START of zero rather than your desired
     START time, so many extra records could have been selected.

 2.  Information APAR II10549 for TYPE70PR lists the diagnostics and
     instructions to open a "hardware PMH" if LCPUEDTM GT LCPUPDTM,
     i.e., if Effective Dispatch time greater than Total Dispatch time,
     usually due to a non-responding coupling facility.

 1.  APAR PK67436 corrects the TCP Port statistics SMF record, Type 119,
     subtype 7, which had an incorrect number of current sessions.


IV.   DB2 Technical Notes.

 2. APAR PK74210 reports INCORRECT VALUES FOR QWACCLS1_ZIIP (IIP CPU
    TIME) for RRS threads that do TCB agent switching.  That is MXG
    variable QWACZIS1 in DB2ACCT dataset.

 1. APAR II14438 lists known issues with OMEGAMON DB2 that can cause
    high CPU utilization by OMEGAMON, and the Information APAR has
    some performance tuning tips.

V.   IMS Technical Notes.

VI.  SAS Technical Notes.

 5.  Do NOT use BUFNO= on any DD statement for a SAS Data Library, or
     you can anticipate a S878-10 ABEND.

     The DCB is primed with the BUFNO from the JCL, but SAS is not
     clearing the BUFNO from the DCB in the open exit.  The system then
     allocates the buffers in virtual, but SAS uses its own area of
     storage above the line for the I/O buffer. Any change would require
     a significant redesign in SAS to clear the DCB BUFNO field, which
     is a future objective in a new SAS Note on this ABEND.

 4.  SAS Usage Note 34071 reports that the use of DSNTYPE=LARGE
     on a DD in JCL for a SAS Data Library may generate SAS Error:
     ERROR: OPEN TYPE=J failed to position library data set
            libname.xxxxxxxx.DATA to volume number 1.
     The error is corrected in hot fix E9BC06 that is associated
     with SAS Note 17038.  Jan 12, 2009.

 3.  SAS V9.2 Warnings when combining datasets with different lengths.

     As previously documented, SAS V9.2 prints new WARNING messages:

     WARNING: Multiple lengths were specified for the variable XXXXXXX
              by input dataset(s).  This may cause truncation of data.

     when datasets with different length variables are combined, i.e.
     with SET, MERGE, UPDATE, etc.

     MXG History:
        Apr, 2008.  MXG 26.03.  Internal code changes in MXG eliminated
                                the warnings, but, also
                                Added VARLENCHK=NOWARN to VMXGINIT

        Aug, 2008.  MXG 26.07.  Removed VARLENCHK=NOWARN to VMXGINIT.
                    because Hot Fix F9BA07 restored behavior to 9.1.3.
                    BUT: That Hot Fix was ONLY for 9.2 TS1M0.

        Apr, 2010   SAS 9.2 TS2M0 and TS2M2 reinstated the WARNINGs by
                    default, but documented VARLENCHK=NOWARN as the
                    way to eliminate the warning.

                    MXG 28.02 reinstated VARLENCHK=NOWARN in VMXGINIT,
                    so that the WARNING will NOT be printed nor will the
                    condition code be set.  This protects future MXG
                    versions when MXG has to change a variable's length
                    but also protects user code from the WARNING.

     But not all variables with different lengths are WARNED.  The two
     datasets OLD and NEW contain 2 character and 2 numeric variables
     with different LENGTHs as shown.  Combining OLD and NEW to create
     DATA BOTHOLD; SET OLD NEW; with OLD listed first printed warnings
     only for variables CH2 and NR1; changing the order with NEW first,
     DATA BOTHNEW; SET NEW OLD; instead printed warnings for variables
     CH1 and NR2.
     So the WARNING is only printed for the variable that is truncated
     (i.e. when the shorter-length is in the first input dataset, as
     that shorter-length sets the variable's length in the output data.
     So BOTH:OLD-NEW's variables CH2 and NR1 are truncated and WARNED,
     and BOTH:NEW OLD's variables CH1 and NR2 are truncated and WARNED.

          Dataset:  OLD    NEW   BOTHOLD:OLD-NEW  BOTHNEW:NEW-OLD
           CH1       $8     $4        $4               $8  W
           CH2       $4     $8        $8  W            $4
           NR1        5      8         8  W             5
           NR2        8      5         5                8  W

     Because lengths are taken from the 1st dataset in the SET statement
     it is STRONGLY recommended that you install a new MXG version into
     production on the FIRST day of a new week (e.g., if your PDBs run
     from MON to SAT, install on Tuesday morning so the MONDAY PDB will
     have any new variable lengths, so that that first-day-of-week PDB
     will set the length of the next WEEK's PDB library).

 2.  What SAS Procedures are included in SAS Base Product with SAS V9.2?

     This list of SAS Procedures in Base SAS V 9.2 is taken from that
     version's SAS Procedures Manual:
       APPEND     BMDP      CALENDAR  CATALOG    CHART     CIMPORT
       COMPARE    CONTENTS  CONVERT   COPY       CORR      CPORT
       DATASETS   DBCSTAB   DISPLAY   DOCUMENT   EXPLODE   EXPORT
       FCMP       FONTREG   FORMAT    FORMS      FREQ      IMPORT
       ITEMS      JAVAINFO  MEANS     MIGRATE    OPTIONS   OPTLOAD
       OPTSAVE    PDS       PDSCOPY   PLOT       PMENU     PRINT
       PRINTTO    PROTO     PRTDEF    PRTEXP     PWENCODE  RANK
       REGISTRY   RELEASE   REPORT    SCAPROC    SOAP      SORT
       SOURCE     SQL       STANDARD  SUMMARY    TABULATE  TAPECOPY
       TAPELABEL  TEMPLATE  TIMEPLOT  TRANSPOSE  TRANTAB   UNIVARIATE
       VAXTOINTEG  WEBMDDB

 1.  For z/OS, in a LIBNAME statement: If you specify a GDG as +0 (which
     is valid syntax) SAS refuses to allocate the LIBNAME saying it does
     not support adding members to a GDG, but +0 is not adding one.
     So,
       LIBNAME PDB 'MXG.PDB(+0)' DISP=SHR;  fails
       LIBNAME PDB 'MXG.PDB(0)' DISP=SHR; works


VI.A.  WPS Technical Notes.

 1.  WPS cannot read a z/OS RECFM=VB file when RECFM=VBS is specified.
       ERROR: Failed to open SMF : EDC5129I No such file or directory.
     The RECFM=VBS parameter is INTENTIONALLY used in the VMACSMF code,
     because VBS is a superset of both V and VB files on z/OS, and so
     the VBS specification should always process any of the three file
     types that might be presented.  This is a WPS design error that
     has been reported to WPS technical support and this note will be
     revised when the error is corrected.

VII. CICS Technical Notes.

 1.  MQ TCB CPU time included in CICSTRAN and TYPE30 and TYPE72.

     With CICS/TS 3.2 and Websphere MQ 5.3.1 or later, using the CICS
     Attachment Facility, the MQ TCB CPU time consumed on behalf of a
     CICS transactions (which will be under the L8 and/or KY8 TCBs) is
     included in IBM SMF 110 subtype 1 fields USRCPUT, L8CPUT, and
     KY8CPUT, which are MXG variables TASCPUTM, L8CPUTTM and KY8CPUTM in
     MXG dataset CICSTRAN.  That MQ CPU time is also recorded in the
     address space of the CICS region, so it is also in the CPUTCBTM in
     the type 30 records for that "job" and in the TYPE72GO for that
     address space's service class.


VIII. Windows NT Technical Notes.


IX.  z/VM Technical Notes.


X.    Email notes.

      1. Outlook Restore Line Breaks corrupts received ftp instructions.

         Our ftp instructions for MXG download are sent by email from
         an Outlook client.  One MXG user noticed that his Outlook
         client was combining two lines of text into a single line.
         The two LOCSITE ftp control statements in Appendix Ds example
         were combined, while the identical pair of LOCSITE statements
         in Appendix A were correctly seen as two lines.
         These four lines of text in the original ftpxxxx.txt file:

            BINARY
            LOCSITE LRECL=1024 RECFM=FB BLKSIZE=6144 UNIT=SYSDA
            LOCSITE PRIMARY=5000 SECONDARY=300 GET ... (replace
            CLOSE
            QUIT

         Were received as


            BINARY
            LOCSITE LRECL=1024 ... UNIT=SYSDA LOCSITE PRI... SECONDARY=
            300 GET ter2605.ter 'MXG.MXG2605.TERSED' (replace CLOSE QUIT

         The received message also contained the "Restore Line Breaks"
         message, and Microsoft KB articles did document that that was
         a flag that this issue was unique to "Plain Text" messages, and
         suggested that use of html would circumvent the problem.
         But html has these exposures:
          -It destroys collimation, unless I change to a fixed font,
          -HTML documents can contain executable stuff, and ours has
           many instances of the same url, which can trigger corporate
           spam filters to false-positive on our ftp instructions, i.e.
           you don't get our instructions, and
          -the url you see and can finger in an html document can be
           quite different than the actual link - you have to display
           the html document in plain text to see if the actual url/ip
           address is what was displayed, i.e., html documents can
           contain false-url-pointers.

         MicroSoft also suggested you could eliminate this problem
         by disabling this Outlook option
           "Remove Extra Line Breaks in Plain Text Messages"
         by unchecking that option under
          TOOLS ==> EMAIL OPTIONS == Uncheck Remove Extra Line Breaks...

         But: if you didn't know to remove that option, then your ftp
         download example's text was corrupted.


         The solution was to alter the email creation:

         There were TWO sets of those five lines in the JCL examples in
         our ftp download instructions, but only the second set of lines
         were corrupted.  I finally noticed that the first pair had
         blanks before the text, while the failing pair started in
         column 1.  By experimentation, I discovered that insertion of
         two blanks (but not just one!), BEFORE (and not after, as some
         have claimed) eliminated the corruption in the received email,
         no matter what you had done with that Outlook default option.

         Now chuffed that I had found a circumvention, if not a real
         solution and now Googling the EXACT text of the Outlook option.
         I found this circumvention reported at least as early as 2005
           December 17, 2005. Robin Good's Email Newsletter.
         BUT NOT BY MICROSOFT, EVEN NOW, AT THE END OF 2008.

         Now, I add two blanks before each line in the MXG ftp download
         instructions, and, for those of you using the MicroSoft Outlook
         (or I suspect Exchange Server) as your email client, the
         control statements in the MXG JCL examples will not be
         merged, even using the (ill-advised) default Outlook option.


XI.   Incompatibilities and Installation of MXG vv.yy.

 1. Incompatibilities introduced in MXG 26.yy (since MXG 25.25):
    See CHANGES.

 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 JCLINST9 for
    SAS V9.1.3 or JCLINST8 for SAS V8.2.

XII.  Online Documentation of MXG Software.

    MXG Documentation is now described in member DOCUMENT.


XIIV. Changes Log

--------------------------Changes Log---------------------------------

 You MUST read each Change description to determine if a Change will
 impact your site. All changes have been made in this MXG Library.

 Member CHANGES always identifies the actual version and release of
 MXG Software that is contained in that library.

 The CHANGES selection on our homepage at http://www.MXG.com
 is always the most current information on MXG Software status,
 and is frequently updated.

 Important changes are also posted to the MXG-L ListServer, which is
 also described by a selection on the homepage.  Please subscribe.

 The actual code implementation of some changes in MXG SOURCLIB may be
 different than described in the change text (which might have printed
 only the critical part of the correction that need be made by users).

 Scan each source member named in any impacting change for any comments
 at the beginning of the member for additional documentation, since the
 documentation of new datasets, variables, validation status, and notes,
 are often found in comments in the source members.

Alphabetical list of important changes after MXG 24.24 now in MXG 25.01:

  Dataset/
  Member   Change    Description

  See Member CHANGES or CHANGESS in your MXG Source Library, or
  on the homepage www.mxg.com.

Inverse chronological list of all Changes:

Changes 25.yyy thru 25.001 are contained in member CHANGES.

*********************NEWSLETTER FIFTY-TWO*******************************




              MXG NEWSLETTER NUMBER FIFTY-TWO, AUG 24, 2008.

Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE

                         TABLE OF CONTENTS

I.    MXG Software Version.
II.   MXG Technical Notes
III.  MVS, aka z/OS, Technical Notes
IV.   DB2 Technical Notes.
V.    IMS Technical Notes.
VI.   SAS Technical Notes.
VI.A. WPS Technical Notes.
VII.  CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX    z/VM Technical Notes.
X.    Incompatibilities and Installation of MXG.
         See member CHANGES and member INSTALL.
XI.   Online Documentation of MXG Software.
         See member DOCUMENT.
XII. Changes Log
     Alphabetical list of important changes
     Highlights of Changes  - See Member CHANGES.

     COPYRIGHT (C) 1984,2008 MERRILL CONSULTANTS DALLAS TEXAS USA

I.  The 2008 Annual Version MXG 25.25 was dated January 28, 2008.

    All sites were mailed a letter with the ftp download instructions.
    The availability announcement was posted to both MXG-L and ITSV-L.
    You can always request the current version using the form at
     http://www.mxg.com/ship_current_version.

 1. The current version is MXG 26.07, dated Aug 24, 2008.

    See CHANGES member of MXG Source, or http://www.mxg.com/changes.

II.  MXG Technical Notes

 3. Why are some tape mounts NOT captured by ASMTAPEE/MXGTMNT monitor,
    and how MXG solves that problem.

    The standard answer, it seems, is "it all depends ...".

    The ASMTAPEE/MXGTMNT Tape Mount Monitor uses an IBM-provided exit,
    if your tape drive allocations are controlled by IBM software, or
    MXGTMNT uses the MXG-provided ASMHSCEX code (that you install in
    STK user exit SLSUX01), if HSC controls tape drive allocations.

    For the IBM IEF_VOLUMEMNT exit, MXGTMNT captures every mount that
    is issued with an IEF233A or IEF233D mount message, and we do NOT
    capture any mount that is issued with IEC501A nor IEC501E messages.
    Specifically, those IEC501x messages that are NOT captured are for
    second-and-subsequent volume mounts of a multi-volume tape dataset.
    IBM has confirmed that is "working as designed" for their exit, as
    it is taken only for Allocation's mounts, whereas the IEC501x mounts
    are OPEN/CLOSE/EOV mounts that do not go thru that exit.

    The IBM Volume Mount Exit also misses ALL mounts issued by some
    programs: DFHSM, OPC, and DMS jobs mount tapes that MXGTMNT does not
    capture in the IBM exit, because those mounts are issued from OPEN
    which doesn't use the IBM exit.  These mounts can cause SMF type 21
    dismount records, but some have a blank volume serial, and some
    missed mounts do not have standard SYSLOG mount messages.  Also,
    none of DFHSMS mounts on 3590s are captured, while mounts for other
    jobs on 3590s are captured by the MXGTMNT monitor.

    For the STK SLSUX01 exit, STK Support installed our exit and it
    captured 100% of all HSC-controlled tape mounts, both to virtual and
    to real tape devices, in several tests in their labs by Sun
    Technicians.

    The solution to these missed mounts in the MXGTMNT event monitor is
    its separate capture of SYSLOG tape mount events, and MXG's ASUMTAPE
    program that combines the MXGTMNT event, the SYSLOG events, and the
    IBM TYPE21 dismount event, to create the PDB.ASUMTAPE dataset that
    DOES contain an observation for EVERY tape mount event.

    The MXGTMNT monitor captures SYSLOG messages in its subtype 8 record
    for these mount-related events:
     IEC501A IEC501E IEC705I IEF233A IEF233D IEF502E IEF234E IOS070E
     IECTMS6 IECTMS9 IOS690I IEF235D
    Dataset TYPESYMT (SYslog MounTs) decodes those SYSLOG records, which
    include the JOB, JESNR, SYSTEM, ASID, and the EVENTIME. These SYSLOG
    events are used in the ASUMTAPE program to populate these variables:

    Used to set SYLMTIME - SYSLOG MOUNT START TIMESTAMP:
        IEF233A - First Volume Mount, JCL Allocation Issued
        IEF233D - First Volume Mount, Dynamic Allocation Issued
        IEF501A - OPEN/CLOSE/EOV, MULTI-VOL, or DEFERRED MOUNT
        IEF501E - 2nd+ Volume for OPEN/CLOSE/EOV "Look Ahead"
    Used to set SYLVTIME - SYSLOG MOUNT VERIFY/END TIMESTAMP:
        IECTMS6 - DEVNR,VOLSER,IS APPROVED FOR TRTCH CHANGE
        IECTMS9 - DEVNR,VOLSER, DSNAME17 at OPEN
        IEC705I - TAPE ON DEVNR,VOLSER
    Used to set SYLKTIME - SYSLOG KEEP TIMESTAMP:
        IEF502E - Intermediate Volume KEEP
        IEC234E - Last Volume KEEP

    Additional SYSLOG messages, below, are captured in TYPESYMT, for
    investigation in cases of long tape mount delays, but they are not
    used in the construction of PDB.ASUMTAPE:

        IEF690I - FOLLOWING VOLUMES UNAVAILABLE
        IEF235D - JJJ STEP WAITING FOR VOLUMES
        IEC205I - VOLUME LIST

    ASUMTAPE creates variables BEGTMNT, ENDTMNT, the begin and end times
    of each tape mount event, their delta in TOTMNTTM, the mount delay
    to jobs, as well as TAPMTDTM, the duration when the tape volume was
    mounted from mount until its keep/dismount for this job:
       BEGTMNT='BEGIN TIME*OF TAPE*MOUNT EVENT'
          IF SYLMTIME GT 0 and TMNTTIME GT 0 THEN
             BEGTMNT=MIN(TMNTTIME,SYLMTIME);
          ELSE iF SYLMTIME GT 0 THEN BEGTMNT=SYLMTIME;
          ELSE IF TMNTTIME GT 0 THEN BEGTMNT=TMNTTIME;
          ELSE                       BEGTMNT=.;
          It is the minimum timestamp of the start of the mount event,
          from SYSLOG or MXGTMNT.
       ENDTMNT='END TIME*OF TAPE*MOUNT EVENT'
          IF SYLVTIME GT 0 AND TENDTIME GT 0 THEN
             ENDTMNT=MAX(TENDTIME,SYLVTIME);
          ELSE IF SYLVTIME GT 0 THEN ENDTMNT=SYLVTIME;
          ELSE IF TENDTIME GT 0 THEN ENDTMNT=TENDTIME;
          ELSE                       ENDTMNT=.;
          It is the maximum verification time or mount end, from SYSLOG
          or MXGTMNT.
       TOTMNTTM='TIME IT TOOK*TO MOUNT*TAPE VOLUME'
          IF ENDTMNT  GT 0 AND BEGTMNT  GT 0 THEN
            TOTMNTTM=ENDTMNT-BEGTMNT;
          It is the duration the job was delayed for this tape mount.
       TAPMTDTM='DURATION*TAPE WAS*MOUNTED*TO DISMOUNT'
          IF (SYLKTIME GT 0 OR TY21TIME GT 0) AND BEGTMNT GT 0 THEN
            TAPMTDTM=MAX(SYLKTIME,TY21TIME)-BEGTMNT;
          It is the duration that the tape volume was mounted on the
          device for this mount event.

    The variable DSNAME will be populated in PDB.ASUMTAPE if the DSNAME
    was captured in TYPETMNT or if it was non-blank in any of these
    SYSLOG messages that can contain a DSN: IEC233A,IEC705I, IEC501A or
    IEC501E.  Some events can never have a DSNAME (e.g., HSM only-234E
    KEEP), but variable MNTHAVE identifies which SYSLOG records were
    found for this mount event so MNTHAVE can be used to identify those
    cases where the DSNAME is always blank.

    Each line below is an example, left to right, of the sequence of
    the SYSLOG messages for several example mount events:

       233A                       234E

       233A TMS6 TMS9 705I TMS014 234E

       233A TMS6 TMS9 705I TMS014 502E      for first vol
           501A TMS6 TMS9 705I TMS014 502E  for intermediates
           501A TMS6 TMS9 705I TMS014 234E  for final volume
             or
           501E TMS6 TMS9 705I TMS014 234E  for final volume

       233A 070E           TMS014 502E

       690D 235D           705I       234E


 2. The CPU cost of performance monitoring and capacity planning.

    One MXG user reports they currently write 500 GB of SMF data per day
    or an average rate of 6 MegaBytes per second across all platforms.

    They dump SMF multiple times each day, and build multiple "PDB's"
    throughout the day, and run many ad hoc analysis reports as well.

    They have SMF, RMF, OMEGAMON, and NETVIEW monitors consuming CPU.

    The daily total CPUTM for each of their workloads were:

      OMEGAMON            28:56:37
      MXG JOBS            19:05:01
      RMF III             12:20:05
      RMF  I               6:29:11
      SMF DUMPS            4:12:30
      MONITORS             2:17:10
      SMF ASID             0:29:16

      TOTAL CPUTM         73:30:50   = 2% of 3744 HOURS with 156 CPs


    Thus this sites total daily cost of 74 CPU hours is an average use
    of 3 CP engines all day long, but with 156 CP Engines, that is ONLY
    2% of the installed CP engine capacity, for the entire CPU cost of
    performance monitoring, data collection, building PDBs, archiving,
    and all MXG daily reporting and ad hoc analysis.

    The UKCMG2008.PPT presentation at http://www.mxg.com/downloads ends
    with the above statistics and a SAS/GRAPH showing the daily profile
    of this site's CPU consumption for all of the above work.

 1.  The MXGTMNT Tape Mount Monitor must be at the current ML-39 level
     before you execute it under z/OS 1.9.  Otherwise it will ABEND with
      B78-5C, which was corrected in ML-39.

III. MVS, a/k/a z/OS, Technical Notes.

27. APAR PK85069 corrects ABEND with SMF 120 Subtype 9, but notes that
   "Certain types of threads lack a request-specific object that is used
   in generating the SMF 120 subtype 9 CPU usage subsection.  When
   WebSphere Application Server for z/OS attempts to write out the SMF
   120 subtype 9 CPU usage subsection, it encounters a null pointer,
   which causes the server to terminate.
   PROBLEM CONCLUSION:
   The SMF 120 subtype 9 CPU usage subsection will now only be written
   from threads that contain the necessary request-specific object.

26. Enabling HIPERDISPATCH=YES in OPT for a z9 processor unintentionally
    disables IRD.  An IBM APAR will be created, but you can correct the
    error by setting HIPERDISPATCH=NO until the PTF for the APAR exists.
    APAR OS26225 has been opened to ultimately correct this IBM error.

25. APAR OA23592 reports incorrect values in SMF30UCT (MXG PRODTCB in
    dataset TYPE30MU, Measured Usage, and in SMF89UCT (MXG PRODTCB in
    dataset TYPE89).  Values are much larger than they should be, and
    could be massively larger, when subtraction incorrectly produced
    a "negative" number that MXG sees as large positive value.

24. APAR PK66063 for TCP/IP V3 corrects many things that impact the
    SMF 119 records, as well as TCP/IP itself.  Jul 20, 2008.

23. APAR OA25065 and OA25603, together, cause SMF 42 subtype 6 interval
    records to now be written for the SMSPDSE and SMSPDSE1 address
    spaces; those are not "full-function" address spaces (i.e., the
    started before SMF was fully enabled at IPL), and the 42-6 were only
    written for full function ASIDs, but this APAR revised code for
    those address spaces.

22. APAR OA25225 corrects a continual growth in storage used for the TCT
    because TCTT30UJ work area (used for SMF type 30 records) was not
    freed by IEFTB721 at job end, causing orphaned storage in subpool
    255, which could lead to an auxilliary storage shortage,
    resulting in MSGIRA200E.

21. APAR OA25825 reports zIIP work not being dispatched on CPs when zIIP
    is full but CPs have capacity.   Algorithm acknowledged as wrong.

20. APAR OA25095 reports that SMF 72-3 records may not be written for
    some CICS or IMS Reporting Class Data.  z/OS 1.9 stopped writing
    72-3 for inactive Reporting Classes, but that inactive-test was not
    correct for CICS or IMS address spaces that are managed to the goals
    of the region in the WLM policy and also have reporting only classes
    set up in the CICS or IMS subsystem.  This caused the variables
    IMSTRAN and CICSTRAN in the PDB.RMFINTRV dataset to have zero
    counts.

19. APAR OA24435 reports RMF MON III zFS Summary Report incorrectly
    reports 0 for USE% for an aggregate >= 2G in size. Jun 10, 2008.

18.  CF Utilization when you have shared ICFs and your CFs are at
     microcode level 15 can be wrong; the correction is a microcode
     update to the CF, MCL number G40953.004, which is documented as
       CFCC code returning inaccurate value to software applications
       used to calculate performance data(RMF, Omegamon). Incorrect
       processor wait time will affect processor utilization numbers.
       Problem only shows up when using SHARED CP's or SHARED ICF's in
       the CFCC image. Jun 10, 2008.

17.  APAR PK62236 reports that SMF 116 records for long running threads
     can be corrupted by statistics from a different queue.

16.  APAR PK65203 reports that SMF 115 records for Version 6 do not
     include GETS/PUTS via the new internal SPIGET/SPIPUT calls,
     causing major reduction in MQGET/MQPUT counts between releases.

15.  APAR OA24361 corrects high CPU time in RMF I address space when
     VSTORE is specified to monitor an address space's virtual storage
     usage, and the address space has lots of subtasks sharing the same
     subpool. May 14, 2008.

14. APAR OA25063 confirms that SMF 42 subtype 6 records are NOT written
    for the SMSPDSE and SMSPDSE1 address spaces, because they are not
    full function.  The APAR is OPEN, so it is not clear if this will be
    corrected, i.e, for all not-full-function-ASIDs (those that started
    before SMF had completed its initialization, and identifiable
    because they write SMF 30 interval subtype 6 records instead of 2.)
    May 13, 2008.


13. The IEF374I step termination message EXT xxxxK value records the
    virtual storage used above the line, and is useful to prove that
    OUT OF MEMORY errors were the result of site restrictions or due
    to the absence of a REGION parameter on the JOB statement, when
    that EXT xxxxK value showed only 32M was used.

    The message syntax is VIRT xxxxK  SYS xxxxK  EXT xxxxK  SYS xxxK
    and this note is only about the last two fields in the message.

    This note revised after IBM provided documentation, May 14, 2008.

    The IEF347I message SYS xxxxK value previously was observed to have
    a value limited by the size of the private area, typically 10MB, and
    the sum of the SYS xxxxK value and the EXT xxxxK value matched the
    value that SAS reports for Total Memory on the SAS log.

    But a job was observed to have recorded a SYS value of 516,208K, or
    over 504MB; that job had a REGION=300MB limit on the JOB statement,
    and its EXT value was 180MB, so that job used 180MB of the 300MB
    REGION limit, plus the 504MB outside that REGION limit, for a total
    of 180MB+504MB=684MB total virtual storage!

    The IBM "LOOK AT" documentation for IEF374I message states that the
    SYS xxxxK value is the high-watermark that the address space used
    from the extended LSQA, the extended SWA, and the "extended high
    private area", which in this message, refers to 'authorized' private
    subpools.  When it is talking about 'user' region subpools it uses
    the term "user region of the private area".

    The EXT xxxxK is reported from TCTELWM which is for user region
    subpools.  The value in TCTELWM cannot (and does not) exceed the
    REGION value (except that a REGION value less than 16M will always
    get 32M Above the Line, and, of course, a user's requested REGION
    can be altered in the site's IEFUSI exit.

    The SYS xxxxK is reported from TCTEHWM which is just LSQA and SWA
    (authorized private subpools), not user region subpools.  That value
    of 504MB is recorded in SMF type step termination records, SMF30EAR,
    is recorded in SMF type 30 step termination records, MXG variable
    LSQSZHI, documented as the Local System Queue and SWA areas above
    the 16MB line.

    Further examination of another site's SYSLOG showed that almost all
    jobs reported 9990K for the SYS xxxxK value, but there were six jobs
    with values over 100MB, the largest being 940MB, so this is not a
    unique observation at one site's accidentally observed job.

    However, it is unclear if there is a real problem here:

    If that extended private area can be page fixed (for example, SORT
    packages can page-fix half of the REGION size), this additional and
    uncontrolled virtual storage allocation could definitely impact the
    real storage usage of the entire system.

    But, this virtual storage allocation may be caused by LE, Language
    Edition, which allocates storage heaps and is known to over-allocate
    when sizes are not correctly specified; fortunately, LE's heap area
    cannot be page-fixed by a sort products.  I have an open query with
    IBM support about any potential impacts of this allocation; this
    note will be updated when more is known.   May 14, 2008.
    May 22: Additional information from IBM in reply to my questions:

   -Is the SYS, i.e. the Extended LSQA or Extended SWA area, fixed
    memory?

    LSQA subpools can be 203-205 (DREF), 213-215 (DREF), 223-225 (FIXED)
    233-235 (FIXED), and 253-255 (FIXED). DREF and FIXED are always
    backed in real. With DREF, RSM can change the frame that backs that
    ata.  The SWA subpools are 229-230, 236-237 and 249, which are all
    pageable.

   -Isn't the purpose of REGION= to limit virtual storage allocated?

    Yes

   -If so, isn't this over-allocation a defect?

    I'd call it "working as designed"; the design is based on an
    assumption of well-behaved programs when it comes to applications
    that are using authorized subpools such as LSQA and SWA (and common
    storage, too).

   -Is there any real cost to large virtual storage allocations?

    If you exceed the availability of virtual storage addresses in an
    address space, you'll get an ABEND878, for example. Of course, if
    the virtual is getting backed in either real or aux, you can also
    end up with shortages in those kinds of storage as well.

   -If the step record shows no PAGEOUTS, does that guarantee that the
    pages were never initially backed on auxiliary storage, i.e., no
    physical I/O for paging if never referenced/stored?

    We only back virtual pages in auxiliary storage if we need to do
    page replacement when the system is real storage constrained. If the
    step record shows no PAGEOUTS it is an indication that virtual is
    not getting backed on AUX. Also, read the Subpools Attributes Table
    8-1 in MVS Diagnosis Reference for more details on how storage is
    backed in real. For example, "Virtual storage is first backed by
    central storage when it is referenced or when it is page-fixed by a
    program using the PGSER macro. The location of the central storage
    backing this subpool depends on the value of the LOC parameter on
    the GETMAIN, STORAGE, or CPOOL macro invocation used to obtain the
    storage."

   -I had not contacted the vendor of this new application, yet, as
    I didn't want to cause them alarm unless there is an exposure.

    The software vendor should be aware of which LSQA and/or SWA
    subpools they are using, as this is authorized storage, and use of
    it (especially ELSQA fixed and/or DREF) should be used
    carefully.
   -z/OS 1.12 message IEF032I/33I replaced IEF374I/276I.

12. zIIP and zAAP measurements when they are faster than CPU engines,
    a/k/a "knee-capped" CP engines of slower speed.

    When specialty engines are faster than the speed of your CPs, there
    is a normalization factor to convert the recorded seconds to their
    NORMALIZED (EQUIVALENT) time, as if they had executed on your CPs.

    In all MXG workload datasets, TYPE72GO and RMFINTRV, (and TYPE30),
    (and DB2ACCT), all time variables for zIIPs and zAAPS are NORMALIZED
    seconds, and all of the service units are segregated by engine type.

    However, the IBM RMF reports present these data quite differently.
    This system has the normalization factor, R723NFFS=569/256=2.222,
    that is, one second of zIIP is equal to 2.222 seconds of CP time.

    ====================================================================
      MXG Dataset TYPE72GO dataset values:
    ====================================================================

       SERVICE     CPUUNITS     ZIPUNITS     CPUTCBTM   CPUZIPTM
     3,932,091    1,793,920    2,137,167       178.92     213.16

    ====================================================================
      RMF WORKLOAD REPORT:
    ====================================================================

    Under "SERVICE TIMES", the RMF "CPU" value of 392.9 seconds is the
    total of the real CPU time on CP engines, plus the NORMALIZED CPU
    time on the zIIP and zAAP engines; it is NOT the CPU "TCB" time.
      ( 392.9 = 178.92 + 213.16    "RMF CPU" = CPUTCBTM + CPUZIPTM )

    But also under "SERVICE TIMES", the RMF "IIP" (zIIP) value of 96.1
    seconds is the UN-NORMALIZED, raw, seconds on the zIIP engine.
    And the RMF "AAP" value for zAAPs is also the UN-NORMALIZED value.

    And under "SERVICE", the RMF "CPU" value of 3931K is the TOTAL
    SERVICE units from CPs, zIIPs, and zAAPs.

      REPORT BY: POLICY=OWL        WORKLOAD=CSSDDF
      TRANSACTIONS    ---SERVICE----  SERVICE TIMES  ---APPL %---
      AVG      0.23   IOC         0   CPU    392.9   CP      4.98
      MPL      0.23   CPU      3931K  SRB      0.0   AAPCP   0.00
      ENDED      51   MSO         0   RCT      0.0   IIPCP   0.07
      END/S    0.01   SRB         0   IIT      0.0
      #SWAPS      0   TOT      3931K  HST      0.0   AAP      N/A
      EXCTD       0   /SEC      1092  AAP      N/A   IIP     2.67
      AVG ENC  0.23                   IIP     96.1
    ====================================================================

    While the workload datasets have normalized CPU time, in all of the
    "hardware" datasets, TYPE70, TYPE70PR, ASUM70PR etc., the CPU times
    for the zIIP and zAAP engines are the raw seconds of CPU Dispatch
    Time on those engines, and is NOT normalized.  As a result, then,
    the total ZIPACTTM recorded in TYPE70 for the above system for the
    day was 10,887 seconds, but the total CPUZIPTM in TYPE72GO for the
    day was 23,079 seconds.

    Those 10,887 raw hardware seconds would be 24,190 normalized seconds
    so the zIIP capture ratio at this site is 23079/24190 = 95.4%.

11. Increased uncaptured CPU time and elongated elapsed time on z10 for
    zip-engine-using jobs with back-level z/OS 1.7 or 1.6 are reported
    after OA20135 was applied are corrected in APAR OA24462.  Same error
    for z/OS 1.8 is corrected in APAR OA21991 and does not occur on 1.9.

10. APAR PK63170 finally has DB2 setting the SMFxFLG in the SMF header
    to indicate that the subtype value in the header is valid, BUT ONLY
    for SMF 100 and SMF 101 records; DB2 failed to also set the flag for
    the SMF 102, with over 350 subtypes, but (apparently) DB2 was not
    willing to move the 102 subtype (IFCID) into the header from the DB2
    Product segment at the end of the record; that enhancement request
    has been sent to IBM DB2 developers, so there's always a chance it
    might happen!

 9. APAR OA22341 reports correction to RMF Monitor III CPC Report, only
    for intervals in which logical processors were varied online or
    offline.  The MSU and physical utilization counts were too low,
    because online and dispatch times were not considered during these
    changing intervals.  Now they are.

 8. Understanding RMF Workload Manager report - Excellent IBM Discussion
    Source..........: CA ASKQQA
    Last updated....: 20080331

     PROBLEM DETAILS:
     I have a few questions:
     1) Is there a way to determine quickly how much CPU each SERVICE
        CLass is using?
     2) Recently we had a sharp increase in our CPU running the same
        workload as last week.
        12/26/2007
        CPU SYSA (55%), SYSB(54%)
        01/02/2008
        CPU SYSA (39%), SYSB(74%)
       We are not having any problems, but we did see SYSB spiking into
       the high 90% within the a given 15minute interval, but it average
       out to 74% for the fifteen minutes (10:00 to 10:15).  Looking at
       TMON it shows us that Service Classes (CICSABK and CICSAAT)
       increased on SYSB. When I looked at the RMF workload manager
       report here is what I see. For the APPL% or CP% IT WAS 324.9.

       VELOCITY MIGRATION:   I/O MGMT  86.3%    INIT MGMT 86.3%

               ---RESPONSE TIME---  EX   PERF   AVG   --USING%--  -----
                 HH.MM.SS.TTT       VEL  INDX  ADRSP   CPU   I/O  TOTAL
       GOAL                         60.0%
       ACTUALS
       SYSB                         86.3% 0.7    6.0  38.1  25.1   10.0

       ------ EXECUTION DELAYS % -------------  ---DLY%-- -CRYPTO%-    %
         I/O  CPU AUX                           UNKN IDLE  USG  DLY QUIE
                     XMEM

         7.6  2.3  0.1                           0.0 26.8  0.0  0.0  0.0

     Is the USING% for CPU the actual CPU% that this service classes was
     using during this 15 minute interval?

     We are trying to assess what caused the CPU to spike this week.
     There is no additional workload added year end will not be
     processing until next week.

     Does the APPL% or CP% correlate to actual CPU use?

     IBM RESPONSE:
     In the RMF WLMGL Report, the field APPL% CP is the sum of the cpu
     times (tcb, srb, rct, iit, hst) divided by the reporting interval.
     An engine can theoretically be dispatched for the entire interval,
     so his is like saying the percentage of an engine.  For example, if
     APPL% CP is 324.9,  that's like saying 3 and a quarter of engine's
     worth of cpu resource.  So you can quickly scan the APPL% values by
     srvclass, to see which srvclass had increased usage of cpu resource
     during the SYSB cpu usage spike.  Once you've identified the
     srvclass which had increased 'APPL% CP' drastically (comparing to
     interval from a good normal time), you can go back to the WLM
     policy to check what types of jobs get classified into that
     srvclass that has grown.

     CUSTOMER UPDATE:
     Thanks for the quick reply. I do have another question. While
     looking at SYSB CPU Activity report, it shows the LPAR MGMT time
     being greater than 5 during several intervals (Highest at 6.50). My
     question is: Here is the Partition Data Information:
       MVS PARTITION NAME                  ZZ0202
       IMAGE CAPACITY                         620
       NUMBER OF CONFIGURED PARTITIONS         10
       NUMBER OF PHYSICAL PROCESSORS           12
                          CP                   12
                          ICF                   0
       WAIT COMPLETION                         NO
       DISPATCH INTERVAL                  DYNAMIC

       --------- PARTITION DATA -----------------  -- LOGICAL
                          ----MSU----  -CAPPING--  PROCESSOR-
       NAME       S   WGT  DEF    ACT  DEF   WLM%  NUM   TYPE
       ZZ0202     A    81    0    442  NO     0.0   12   CP
       ZZ0201     A     5    0     15  YES    0.0    1   CP
       ZZ0203     A     3    0      3  NO     0.0    1   CP
       ZZ0204     A     5    0      6  NO     0.0    1   CP
       ZZ0205     A     3    0      2  NO     0.0    2   CP
       ZZ0206     A     3    0      4  NO     0.0    1   CP
       ZZ0207     A     1    0      0  NO     0.0    1   CP
       ZZ0208     A     1    0      0  NO     0.0    1   CP
       ZZ0209     A     5    0      1  NO     0.0    2   CP
       *PHYSICAL*

         TOTAL

       PARTITION PROCESSOR DATA --
        ----DISPATCH TIME DATA----
         EFFECTIVE       TOTAL
        02.01.38.060  02.08.12.931
        00.04.09.386  00.04.13.893
        00.00.56.486  00.00.59.156
        00.01.47.096  00.01.49.786
        00.00.28.968  00.00.31.089
        00.01.01.477  00.01.03.485
        00.00.00.000  00.00.00.000
        00.00.00.000  00.00.00.000
        00.00.15.943  00.00.17.880
                      00.04.51.677
        ------------  ------------
        02.10.17.420  02.21.59.902

       -- AVERAGE PROCESSOR UTILIZATION PERCENTAGES --
       LOGICAL PROCESSORS  --- PHYSICAL PROCESSORS ---
       EFFECTIVE    TOTAL  LPAR MGMT  EFFECTIVE  TOTAL
           67.58    71.23      3.66      67.57  71.23
           27.71    28.21      0.04       2.31   2.35
            6.28     6.57      0.02       0.52   0.55
           11.90    12.20      0.02       0.99   1.02
            1.61     1.73      0.02       0.27   0.29
            6.83     7.05      0.02       0.57   0.59
            0.00     0.00      0.00       0.00   0.00
            0.00     0.00      0.00       0.00   0.00
            0.89     0.99      0.02       0.15   0.17
                                   2.70              2.70
                                  ------     ------ ------
                                   6.50      72.38  78.89
     Also from the CPU ACTIVITY you see

       CPU     ONLINE TIME   LPAR BUSY       MVS BUSY
       NUMBER  PERCENTAGE    TIME PERC       TIME PER
              100.00             80.82           88.68
              100.00             80.19           86.27
              100.00             78.81           83.67
              100.00             76.98           81.06
              100.00             74.73           78.31
              100.00             72.41           75.72
              100.00             70.07           73.24
              100.00             67.88           70.94
              100.00             66.39           69.71
              100.00             64.16           67.21
              100.00             62.05           64.84
              100.00             60.29           62.88
           TOTAL/AVERAGE         71.23           75.21

     Can you explain why we are seeing the LPAR Busy is less than MVS
     Busy.  Now the only difference between SYSA and SYSB is that SYSB
     has one LPAR CAPPED.  One other item. After working the numbers, it
     shows me because the weight is (SYSB)810 out of 1090 (Total
     weights). This tells me that I am guarantee 8.88% CP which to me is
     9CPs, whereas all the rest of the LPARs (4 of them at 0.6 CP, 2 of
     them at 0.4 and 2 at 0.1). Since we are capping one Active
     Partition, what is the bottom line to this.  Am I limiting my Main
     LPAR by only giving it a weight of only 810. If I bump it up to 900
     and ensure the rest equals 1000, this will ensure my main LPAR
     would get at least 10-11 CP? Your thoughts.

     IBM RESPONSE: MVS BUSY is a totally different view of cpu
     utilization from LPAR BUSY (and it can be a little confusing at
     first), so LPAR BUSY and MVS BUSY values won't necessarily match.
     The MVS BUSY is the percentage of time this z/OS did not go into
     a wait state.  So MVS BUSY represents how busy the LPAR was, but it
     doesn't show how much the LPAR has consumed its online logical
     engines.  You would look at the LPAR BUSY to determine this.
     The LPAR BUSY is the percentage of this LPAR's online logical
     CPs that the LPAR actually consumed.  If the number of logical CPs
     for an LPAR is equal to the number of physical CPs for the box,
     then LPAR BUSY is like saying what percentage of the box the LPAR
     is using.

     PR/SM will distribute the cpu resources to all LPARs on the same
     CEC based on their set WEIGHTs, regardless these LPARs are in the
     same sysplex or not.
       If the processor box is not 100% utilized, PR/SM would allow an
     LPAR to use more than its weight % share, but only if there is some
     other LPAR that does not have enough work to do to consume its full
     weight % share.  Because ZZ0202 is not being capped, PR/SM will
     allow it to use more than its weight % share, if the processor box
     is not 100% utilization and if there is some other LPAR that does
     not consume its full weight % share.

     The PHYSICAL PROCESSORS TOTAL is 78.89% so the processor box is not
     100% utilized in this reporting interval.  But I agree that if you
     bump the weight of ZZ0202 to 900 out of total of 1000, this will
     ensure ZZ0202 gets its 90% weight share of cpu resource, when the
     processor box is pushing at 100% utilized.

    Let me know if I can be of further assistance.

     CUSTOMER UPDATE:
     Thanks for the great explanation, but I am a little confused. When
     I looked at the CPU Activity reports during two 15 minute periods
     10:15 and 10:30, the LPAR Management is at 6.50 and 5.33. So this
     tells me that HYPERVISOR is working hard compare to a maximum of
     2.3 and 1.2 on the previous week same timeframe. As well since LPAR
     Busy is less than MVS Busy, this tells me MVS did not get all of
     its work done.

     1) IS this true and is this why the LPAR Management is HIGH?


     Further when I looked at the Partition Processor Data it says:
         ----DISPATCH TIME DATA----
          EFFECTIVE       TOTAL
         02.01.38.060  02.08.12.931
         00.04.09.386  00.04.13.893
         00.00.56.486  00.00.59.156
         00.01.47.096  00.01.49.786
         00.00.28.968  00.00.31.089
         00.01.01.477  00.01.03.485
         00.00.00.000  00.00.00.000
         00.00.00.000  00.00.00.000
         00.00.15.943  00.00.17.880
                            00.04.51.677

     2) Could you explain what effective versus Total means in these two
        columns?


      Finally, when I looked at: the AVERAGE PROCESSOR Utilization. You
      will see ZZ0204 LPAR is 11.90 and 12.20 in the following table.
         LOGICAL PROCESSORS
         EFFECTIVE    TOTAL
                67.58    71.23
                27.71    28.21
                 6.28     6.57
                11.90    12.20
                 1.61     1.73
                 6.83     7.05
                 0.00     0.00
                 0.00     0.00
                 0.89     0.99

     On previous reports this ZZ0204 LPAR was effective 4.4 and 4.5.
     3) Can I assume that this means this LPAR was doing more work and
        got the processor when it needed it?

     4) Now because we only have one LPAR capped in the whole
        enterprise, and it is sitting on this particular CPC. Does that
        do anything bad on the way it handles the stealing and assigning
        of Physical CP. BY the way, the capped LPAR is part of the Same
        SYSPLEX, it is the Backup CMC LPAR?

     IBM RESPONSE:
     First to point out, the sum of your weights is 107, so the big LPAR
     is actually defined to have 81/107 = .757 = 75.7 % of the box.
     Also,   0.757 * 12 = 9.084 = 9 CPs, so the LPAR is already defined
     to be able to use 9 CPs worth of CPU resource.

     1) LPAR BUSY being less than MVS BUSY means that MVS dispatched
        work onto one of its logical CPs, but PR/SM took away that
        physical engine away from the logical engine to give to another
        LPAR.  Therefore MVS still thinks it has a logical engine (MVS
        BUSY clock keeps ticking) but PR/SM knows that LPAR is no longer
        running on a physical engine (LPAR BUSY clock is no longer
        ticking).  The LPAR MGMT column shows overhead of PR/SM
        HYPERVISOR, yes.  But a big difference between LPAR BUSY and MVS
        BUSY does not necessarily mean a big difference in LPAR MGMT.

     2) The difference between EFFECTIVE and TOTAL is LPAR MGMT time.

     3) Yes the ZZ0204 LPAR must have had more work to do than the
        previous interval you are comparing it with, since it used about
        3x the amount of CPU compared with the previous interval.

     4) Having a capped LPAR only means that the LPAR is not allowed to
        use more than its weight % share of the box.  It should not
        greatly affect the Hypervisor overhead.  I imagine that the same
        LPAR was capped last week so we can rule out the capping as
        being the cause of the increased Hypervisor overhead.  The only
        worry I would have about capping is that since the LPAR is in
        the same sysplex as the other LPARs, is it able to get the
        resources it needs so as not to affect sysplex-wide resources
        like SYSTEMS level enqueues.  I imagine it is getting enough
        since it is still using less than its weight % share.


        Let me mention the type of things that can cause higher LPAR
        MGMT.  You want to keep the total # of logical CPs low.  When
        the ratio of logical to real CPs increases (ie. more logical)
        then the pr/sm dispatch interval is shortened.  This is so that
        pr/sm can give good response time to all the logical CPs.  But
        this causes extra overhead.   Therefore you might want to look
        at why you have so many small LPARs, and can you possibly
        combine some of them so that we have less work to do in managing
        one logical CP for each LPAR when the LPAR hardly ever does
        anything.  Also, make sure your HMC is not getting any more
        messages to the HMC log compared to 'normal'.  We saw a problem
        some time back when LPAR MGMT went high (>10%), and it turned
        out there was an IEFUSI exit issuing messages to the HMC
        console.  We spin waiting for access to the service processor to
        deliver that message, and then do DIAG 44 instruction to tell
        PR/SM that we are just spinning, and this caused the higher LPAR
        MGMT.

 7.  APAR OA22993 reports a storage leak in SMSVSAM MMF processing when
     RMF III collects SMF 42 records, due to IGWMCIDB control blocks
     being left behind when keeping statistics on large numbers of data
     sets, leading to ABEND 878 when Subpool 229 Protect Key 5 fills.
        When RMF collects statistics, a new CIDB block is obtained each
        time and is not freed when SMF42 records size is greater than
        what fits in RMF provided space.  Over time with alot of
        statistics collection, SMSVSAM is filled with CIDB blocks which
        eventually leads to ABEND878.

        Note: You can put the SMSVSAM JOB name in VSTORE parameter in
              your RMF Monitor I options (ERBRMFxx in PARMLIB) to enable
              virtual storage monitoring and use TYPE78SP and TYPE78PA
              data sets to track that JOB's virtual storage in sub pools
              and in its private area, to detect this problem early.

 6.  CPU Parked Time Metric.

     PR/SM data for LCPUADDR 5 in dataset TYPE70PR:

                       "Online Duration"
      ======================SMF70ONT===========================
                             299.97

        Online, "Parked"    Online,"Dispatched or Not Parked"
      =====CPUPATTM====== ======= (SMF70ONT-CPUPATTM) =========
             103.22                      196.75

                               Online            Online
                            "Dispatched"      "Not Parked"
                          ====LCPUPDTM==== ======PATWAITM======
                               96.80              99.96


     MVS data for CPUID 5 in dataset TYPE70:

                       SMF70WAT
                      =ORIGWAIT=
                        0.0000


     This data for LCPUADDR=5 shows a CP engine that was parked for 103
     seconds of that 5 minute interval.  RMF subtracts the SMF70PAT
     parked duration from the SMF70ONT online duration to calculate the
     Percent MVS Busy value.  In this interval, ORIGWAIT was zero for
     this engine, as MVS never entered the wait state on that engine,
     so RMF calculates the MVS busy percent as:

      PCTMVSBY= 100*(SMF70ONT-ORIGWAIT-SMF70PAT)/(SMF70ONT-SMF70PAT);

      PCTMVSBY= 100*( 299    -0       -103)     /(299     -103) = 100%

     The IBM calculation of the PCTCPUBY, the LPAR CPU busy percent, is
     NOT altered by parked time; PCTCPUBY=32%, calculated as

        PCTCPUBY= 100*(LCPUPDTM/SMF70ONT); = 100 * (96 / 299 );

     The "PATWAITM", the time when the CP engine is "not parked", is the
     time when this CP engine could/should have been parked, but was
     still online and not-dispatched, because the algorithm to park a
     CPU only executes occasionally.  It is not created in TYPE70PR.
     MXG Change 26.191 implemented the change in PCTMVSVY calculation.

 5.  APAR OA23174 enables the use of zIIP engines for XRC.

 4.  APAR OA20921 reports incorrect total frames in TYPE71 for z/OS 1.8
     systems with more than 128GB real storage.  RMF reported 540,932
     while D,STORE reported 540672.

 3.  Increase in I/O Counts:
     APAR Identifier ...... II10752
     ICF CATALOG PERFORMANCE PROBLEMS
     Note 15 states:

      Beginning with HDZ11G0 and in subsequent versions of DFSMS I/O
      statistics for catalogs and the Catalog Address Space will appear
      differently than earlier releases. Prior to z/OS 1.3 VSAM did the
      I/O to VSAM data sets, including catalogs. Starting with HDZ11G0
      VSAM uses Media Manager to do all I/O. Prior to HDZ11G0 VSAM
      specifically omits the collection of Start-I/O or block counts
      when accessing a catalog. Media Manager does not differentiate
      between I/O to catalog or another type of data set. You may now
      see higher I/O counts for Catalog Address Space I/O requests. The
      actual I/O rates have not changed, simply the reporting of them.

 2.  Improve IDCAMS EXPORT processing of catalogs>
     APAR Identifier ...... II10752
     ICF CATALOG PERFORMANCE PROBLEMS
     Note 16 states:

      To improve IDCAMS EXPORT processing of catalogs, specify the
      BUFND, BUFNI and BUFNO parameters. To specify BUFND and BUFNI you
      will need to use the INFILE parameter for EXPORT.  Sample JCL is
      below:

           //EXPRTCAT EXEC PGM=IDCAMS
           //SYSPRINT DD   SYSOUT=*
           //INCAT    DD   DSN=MY.CATALOG,DISP=SHR,
           //  AMP=('BUFND=XXX','BUFNI=YYY')
           //OUTCAT   DD   DSN=MY.EXPORTED.CATALOG,DISP=(NEW,CATLG),
           //  UNIT=SYSDA,SPACE=(CYL,(10,10)),BUFNO=ZZ
           //SYSIN    DD   *
             EXPORT MY.CATALOG -
             INFILE(INCAT) -
             OUTFILE(OUTCAT) -
             TEMPORARY
           /*

      For BUFND (XXX) use the number of CI's per CA for data component
      of the catalog. For BUFNI, compute the number of index records by
      dividing the High Used RBA of the index component by the index
      component CISIZE and add a value of 5 to 10 to that calculation.
      For BUFNO (ZZ) use a value in the range of 30 to 40.

 1. APAR PK56492: ITCAMfWAS Version 6 generated huge count of SMF ID=92
    subtype 10/11 records.  APAR provides a PTF to disable the function
    that was erroneously creating those records.

 0. zIIP and zAAP measurements when they are faster than CPU engines.

    When specialty engines are faster than the speed of your CPs, there
    is a normalization factor to convert the recorded seconds to their
    NORMALIZED (EQUIVALENT) time, as if they had executed on your CPs.

    In all MXG workload datasets, TYPE72GO and RMFINTRV, (and TYPE30),
    all time variables for zIIPs and zAAPS are NORMALIZED seconds, and
    all of the service units are segregated by engine type.

    However, the IBM RMF reports present these data quite differently.
    This system has the normalization factor, R723NFFS=569/256=2.222,
    that is, one second of zIIP is equal to 2.222 seconds of CP time.

    ====================================================================
      MXG Dataset TYPE72GO dataset values:
    ====================================================================

       SERVICE     CPUUNITS     ZIPUNITS     CPUTCBTM   CPUZIPTM
     3,932,091    1,793,920    2,137,167       178.92     213.16

    ====================================================================
      RMF WORKLOAD REPORT:
    ====================================================================

    Under "SERVICE TIMES", the RMF "CPU" value of 392.9 seconds is the
    total of the real CPU time on CP engines, plus the NORMALIZED CPU
    time on the zIIP and zAAP engines; it is NOT the CPU "TCB" time.
      ( 392.9 = 178.92 + 213.16    "RMF CPU" = CPUTCBTM + CPUZIPTM )

    But also under "SERVICE TIMES", the RMF "IIP" (zIIP) value of 96.1
    seconds is the UN-NORMALIZED, raw, seconds on the zIIP engine.
    And the RMF "AAP" value for zAAPs is also the UN-NORMALIZED value.

    And under "SERVICE", the RMF "CPU" value of 3931K is the TOTAL
    SERVICE units from CPs, zIIPs, and zAAPs.

      REPORT BY: POLICY=OWL        WORKLOAD=CSSDDF
      TRANSACTIONS    ---SERVICE----  SERVICE TIMES  ---APPL %---
      AVG      0.23   IOC         0   CPU    392.9   CP      4.98
      MPL      0.23   CPU      3931K  SRB      0.0   AAPCP   0.00
      ENDED      51   MSO         0   RCT      0.0   IIPCP   0.07
      END/S    0.01   SRB         0   IIT      0.0
      #SWAPS      0   TOT      3931K  HST      0.0   AAP      N/A
      EXCTD       0   /SEC      1092  AAP      N/A   IIP     2.67
      AVG ENC  0.23                   IIP     96.1
    ====================================================================

    While the workload datasets have normalized CPU time, in all of the
    "hardware" datasets, TYPE70, TYPE70PR, ASUM70PR etc., the CPU times
    for the zIIP and zAAP engines are the raw seconds of CPU Dispatch
    Time on those engines, and is NOT normalized.  As a result, then,
    the total ZIPACTTM recorded in TYPE70 for the above system for the
    day was 10,887 seconds, but the total CPUZIPTM in TYPE72GO for the
    day was 23,079 seconds.

    Those 10,887 raw hardware seconds would be 24,190 normalized seconds
    so the zIIP capture ratio at this site is 23079/24190 = 95.4%.


IV.   DB2 Technical Notes.
 4. APAR PK90013 provides enhancements to a batch reporting program,
    DSN1SMFP, that supports "Common Criteria", an international standard
    that helps to ensure security of computer systems in a network
    environment.  A Common Criteria-compliant environment is very
    restrictive and is not intended for use by most DB2 customers.
    The DSN1SMFP program reads these DB2 IFCID records:
       * 0003: Accounting - DDF Data by Location (security-relevant
               fields only)
       * 0004: Trace Start
       * 0005: Trace Stop
       * 0023: Utility Start
       * 0024: Utility Change
       * 0025: Utility End
       * 0083: An Identify Request End
       * 0106: System Parameters (security-relevant fields only)
       * 0140: Audit Authorization Failures
       * 0141: Audit DDL Grant/Revoke
       * 0142: Audit DDL Create/Alter/Drop
       * 0143: Audit First Write
       * 0144: Audit First Read
       * 0145: Audit DML Statement
       * 0269: Trusted Connection
       * 0270: Trusted Context Create/Alter
       * 0350: SQL Statement
    and apparently writes each IFCID to a separate DD.  If you nave
    need of DSN1SMFP reporting from MXG, please provide an example
    report, and MXG will be enhanced to match the report.  However,
    I believe as a minimum, you can use
      %READDB2(IFCIDS= 3 4 5 23 24 25 83 106 140 141 142 143 144 145 269
                      270 350);
      %VMXGPRAL(DDNAME=WORK,NOBS=MAX);
    to print ALL of the variables from each of those IFCIDs.

 3. APAR PK69111 reports "millions of" IFCID 173 (SMF 102) records being
    written, currently no PTF but a local fix of "Stop RLF". Jul 20, 08.

 2. DB2 SMF 102 IFCID 142 ALTER records are not written for all alters.
    At present, only ALTERs where the AUDIT attribute is changed are
    audited.  Changes such as the addition of a column, VARCHAR length,
    etc, are not currently written to SMF.  DB2 support commented that
    they do have an upcoming design change request for DB2 V9 that will
    change the audit behaviour for the ALTER TABLE such that any ALTER
    of an audited table will be audited, including ALTERs to add
    columns, but no date has been announced.  May 22, 2008.

 1. APAR PK62743 for Websphere for Z/OS 510 reports increased zAAP CPU
    and Elapsed Runtime Increases.  The CPU and runtime increases are
    directly related to the number of times a resource lookup is done as
    the application runs.  Under LOCAL FIX:  If possible, change the
    application code to do less resource lookup calls. (Caching resource
    data often helps reduce the number of resource lookup calls, FYI.)

V.   IMS Technical Notes.

VI.  SAS Technical Notes.

 9. IBM APAR OA25725 required for SAS ITRM if some files are stored in a
    zSeries File System (zFS): SAS, and several Customers of SAS ITRM
    3.1.1, have discovered, and IBM has corrected, a problem in the zFS
    file system component of the z/OS operating system.  This problem is
    fully documented in the following Usage Note:
       Usage Note 16333: Possible corruption of SAS IT Resource
       Management aggregation table if it is stored in a zSeries File
       System (zFS) available at
       http://support.sas.com/kb/16/333.html.
    ALL consumers of SAS ITRM 3 are encouraged to obtain and apply APAR
    OA25725 at their earliest possible convenience.

 8. SAS Note 32065 lists all z/OS dataset names used by SAS V9.2. 28May.

    The following is a description of all the physical data sets that
    are created when installing SAS version 9 on z/OS. You may not
    have all of these data sets because some only are created if you
    license specific SAS products. This list applies to SAS 9.0
    through SAS 9.1.3. The data sets are slightly different in SAS 8.2
    and SAS 9.2.

    SAS Technical Support highly recommends that you not delete any of
    these data sets, even if you know you will never use them. Future
    updates or adding additional products to this image may fail if
    the image is not complete. If you want to save DASD space, then we
    recommend that you archive any unused data sets to tape instead of
    deleting them.

    Files that make up the SAS System

    ** &prefix is the prefix specified at the time of your install.

    ** For more information on Languages / Encodings see the last
       section in the SAS Installation Guide for z/OS


    &prefix.BAMISC          - Base Miscellaneous PDS
    &prefix.CLIST           - Where generated CLISTS are written
    &prefix.CNTL            - Install CNTL data set
       - If you installed using the wizard, it will be called
         &prefix.Vxxxxxxx.CNTL where xxxxxxx is based on the
         julian date of the installation.
    &prefix.CNTL.RENEW      - Contains SID/setinit information
    &prefix.CTMISC          - SAS/Connect Miscellaneous PDS
    &prefix.DBCS.LIBRARY    - Double Byte Character Set Load Library
    &prefix.DBRM            - SAS/Access to DB2 Miscellaneous PDS
    &prefix.DQ.*            - SAS/Data Quality data sets
    &prefix.xxyy.SASHELP    - SASHELP library (xx=language,yy=encoding)
       - Allocated to SASHELP DD in CLIST and PROC
    &prefix.xxyy.SASMSG     - SASMSG library (xx=language,yy=encoding)
       - Allocated to SASMSG DD in CLIST and PROC
    &prefix.xxyy.XREG.TXT   - Registry source (xx=language,yy=encoding)
      - The registry is built during the install
    &prefix.GRMISC          - SAS/Graph Miscellaneous PDS
    &prefix.ITMADPT.*       - SAS Solution adapters files
    &prefix.ITRM.*          - IT Resource Management files (ITRM)
    &prefix.LIBRARY         - SAS Load Library
       - Allocated to the STEPLIB DD in the JCL proc, and to tasklib
         in the CLIST
    &prefix.NEWS            - News data set, echoed into SAS LOG
    &prefix.PROCLIB         - Generated JCL procs are written here
    &prefix.SAMPLE          - Sample library - contains source code
    &prefix.SAMPSIO         - Sample data library
       - SAS data library that contains the data that the programs
         in the SAMPLE library use
    &prefix.SASC.TRANSLIB   - SAS/C transient library
    &prefix.*.TTF           - True type font files
    &prefix.SASSAML         - Used with SAS/Share product
    &prefix.SEMISC          - SAS/Session Miscellaneous PDS
    &prefix.TKMVSENV        - Default settings for environment vars
       - The TKMVSENV member is allocated to the TKMVSENV DD in
         CLIST/JCL Proc
    &prefix.TOOLKIT.*       - SAS/Toolkit files
    &prefix.USAGE.HFAUD     - Hot Fix Audit files
    &prefix.USAGE.LIBRARY   - SAS Note library
    &prefix.USAGE.ZAPS      - Zap library
    &prefix.WEB.TAR         - USS TAR files
       - Used during installation
    &prefix.yy.AUTOLIB      - Autocall library (yy=encoding)
       - Allocated to SASAUTOS DD in CLIST and PROC
    &prefix.yy.ITRM.*       - ITRM SAS data libraries (yy=encoding)
    &prefix.yy.MAPS         - SAS/Graph Maps data set (yy=encoding)
    &prefix.yy.SRVCFG       - Config files for various servers
    &prefix.yy.SRVCLIST     - generated CLISTS for various servers
    &prefix.yy.SRVCNTL      - Misc stuff for various servers
    &prefix.yy.SRVENV       - Environment variable settings for servers
    &prefix.yy.SRVPARM      - parm files for various servers
    &prefix.yy.SRVPROC      - procs for various servers
    &prefix.yy.SRVREXX      - REXX execs for various servers
    &prefix.yy.TARFILES     - USS tar files
       - Used during the install
    &prefix.yy.TESTS        - Installation validation files
       - Used after the install by the VALID jobs
    &prefix.yy.XREG.TXT     - Registry source (yy=encoding)
        - The registry is built during the install
    &prefix.ZT.*.GFONT - Asian language graphic fonts


 7. Support for SAS Version 9.2: WARNING/RETURN CODE issues RESOLVED!

    Previous MXG Versions run without error with SAS Version 9.2.
                          and
    MXG Version 26.03 or SAS Hot Fix F9BA07 eliminated the new WARNING.

    SAS V9.2 Hot Fix F9BA07 corrects the WARNING/RETURN CODE issues that
    were introduced in SAS 9.2, that were reported in this Note prior to
    August 20, 2008, and that were also circumvented in MXG 26.03.
    SAS Note SN-031850 discusses the original problem, but that Hot Fix
    restores SAS 9.2 to the prior 9.1.3 behavior; INSTALL THIS HOT FIX!

    SAS V9.2 does set CONDITION CODE 4 for all WARNING messages, whereas
    only some WARNINGs previously set a non-zero RETURN CODE  But, prior
    to the Hot Fix (and without MXG 26.03 revisions) a new message
       "WARNING: Multiple lengths specified for variable XXXXXX"
    set condition code 4 (17,000 times in the MXG QA with first V9.2!).

    HOWEVER: EVEN THEN, THE V9.2 OUTPUT DATASETS WERE PERFECTLY VALID,
             AND THOSE MESSAGES HAVE NO REAL IMPACT ON MXG OUTPUT.

    Changes 26.189, 26.090, 26.078, 26.065 and 26.060 have V9.2 details.

    Additionally, SAS changed the DSNAMES of some of their datasets in
    their z/OS JCL procedure; see Change 26.193.


 6. Using SAS/ITRM's %cpdupchk macro to remove duplicate input records
    can be very CPU-intensive, when there are lots of output datasets
    created, as this example using TYPETNG (over 200 datasets) shows:

        With %cpdupchk macro, cpprocess step took:
            real time           10:14:17.77
            cpu time            5:52:36.51

        Without %cpdupchk macro, cpprocess step took:
            real time           4:07:35.24
            cpu time            2:14:21.26


 5. SAS error message
      LIBRARY xxxx IS NOT IN A VALID FORMAT FOR ACCESS METHOD SASE7
    resulted at one site because the RECFM=FS had not been set in the
    DCB when the library was created.  Usually, DISP=NEW datasets will
    get their DCB from SAS, but site SMS allocation defaults may need
    to be overridden to specify RECFM=FS for SAS datasets.


 4. SAS format SIZEKMG displays bytes differently than MXG's MGBYTES.

    The SAS format SIZEKMG prints byte values with K, M, etc suffix,
    as MXG's MGBYTES format has done for years, but SAS rounds values,
    so 32255 bytes (31.4KB) is 31KB with SIZEKMG and 31KB with MGBYTES.
    so 32256 bytes (31.5KB) is 32KB with SIZEKMG and 31KB with MGBYTES.
    so 32767 bytes (31.9KB) is 32KB with SIZEKMG and 31KB with MGBYTES.
    so 32768 bytes (32.0KB) is 32KB with SIZEKMG and 32KB with MGBYTES.

    If you prefer the rounding up in your printed reports, you can use
    this old style macro definition:

       MACRO MGBYTES SIZEKMG %

    and all of the MGBYTES. references in MXG source code will instead
    be compiled as SIZEKMG. and you'll have rounded values printed.
    Jan 29, 2008.

 3. SAS REALMEMSIZE is not useful option for MVS.

    The REALMEMSIZE option was designed primarily for use on operating
    systems such as Windows or Unix where an individual user's virtual
    memory can exceed real memory.  On MVS that situation is unlikely.
    REALMEMSIZE is probably not a useful tuning option on MVS so it is
    recommended to be left at its default value. The option
    specification is only for compatibility with other systems.

    REALMEMSIZE is not adjusted to the real memory size because the
    concept doesn't really apply on MVS, given that virtual memory is
    capped by the REGION specification and we don't even know how much
    real memory is on the system. The option is really about REAL
    memory, not virtual memory.

    Jan 25, 2007, provided by SAS Developers.



 2. MXG "compatibility or support" with SAS/ITRM.

    There is often confusion with the term "support" or "compatibility"
    between SAS/ITRM Versions and MXG Software Versions.  In Cary, SAS
    executes the current SAS/ITRM (now 2.7) every night with the newest
    MXG Version (now 25.11), and it has been years since there has been
    any execution issues; often, you must "drop in" the newest
    MXG Version to support a new operating system release, and you can
    always do that without installing a new ITRM Version, so we believe
    that MXG and ITRM are always mutually "compatible".

    With regard to ITRM "supporting" new MXG variables or new datasets
    in ITRM output "PDB" data libraries, the ITRM Version does impact:
    Only the MXG variables and datasets that existed in the MXG Version
    that was used to update the ITRM dictionary will be kept in ITRM
    output datasets (not even the DETAIL will have new vars/datasets).
      However: you can use the MXG EXPDBOUT exit to PROC COPY any MXG
               dataset from WORK to a separate LIBNAME; the EXPDBOUT
               exit is taken after SMF has been written to WORK and
               before ITRM has processed them.

    The ITRM 2.7 dictionary was created from MXG 24.04, but a hotfix is
    coming soon with an ITRM dictionary based on Sep, 2007's MXG 25.08.


 1. Use of SAS SPD Engine (SPDE) with MXG.

    MXG makes extensive use of SAS Views which are not supported with
    the SAS SPD Engine (SPDE), per SAS 9 documentation on The SPD
    Engine.  Also, consider that a zFS (as well as hiperspace, for that
    matter) is a fixed-size at SAS initialization time and do not honor
    the concept of getting additional "extents" depending on an
    individual process requirement.  Scott Barry posting, 21Dec2007.


VI.A.  WPS Technical Notes.

 7. Comparison of SAS V9.2 and WPS 2.3 on z/OS:

    BUILDPDB and ASUMs with 448 MegaByte input SMF file;

    z/OS Step Totals:

                             SAS V9.2           WPS 2.3       RATIO

                          mm:ss     sec       mm:ss    sec
    Total CPU time        03:45     225       08:30    510      2.26

    Total Elapsed time    08:00     480       16:58   1018      2.10

    Total EXT Memory        104  MegaBytes       188 MegaBytes
    Total SYS Memory         11  MegaBytes       504 MegaBytes
    Total Memory            115  MegaBytes       692 MegaBytes

    SMF Data Step

                          mm:ss     sec       mm:ss    sec
     Elapsed time         01:12     72        03:27    207      2.85

     SMF Read Rate         6.22 MB per sec      2.16 MB per sec

     See MVS Technical Note 13 in this newsletter for additional
     information on the virtual storage in the EXT and SYS fields
     of the IEF374I step termination message.
    -z/OS 1.12 message IEF032I/33I replaced IEF374I/276I.

 6. With the below five exceptions, the MXG QA test did complete with
    WPS 2.2.2 Build 8792 on Windows earlier this year.

 5. WPS 2.2.2 Build 8792 failed in ANAL30DD because the %RUN; statement
    is not supported, leading to these error messages:

                    %RUN;
           WARNING: Apparent invocation of macro "RUN" not resolved
           ERROR: Expected a statement keyword : found "%"

    The %RUN; statement was unintended; it was supposed to be just RUN;
    but (unbeknownst to me before now), there is a %RUN; statement that
    is used to terminate a %INCLUDE *; statement for terminal input.
    WPS Issue 5050, corrected in WPS 2.2.2 GA Build 9037, Mar 10, 2008.

 4. WPS 2.2.2 Build 8792 failed in ANALRMFR with a compiler error inside
    a %macro expansion:

       +  SMF70SPN SMF70CIN SMF70STN SORTNUM; TITLE DATA=TEMP70S ;
       +! PROC PRINT DATA=TEMP70S HEADING=H;
       +! WHERE (SMF70CIN='IFA' OR SMF70CIN='IIP');
       +! RUN; DATA _NULL_;
       +! RETAIN PCTEFVT0-PCTEFVT9 PCTEFVTA PCTEFVTB PCTEFVT;

       ERROR: Found "DATA" when expecting one of ANGLE, A, COLOR, C,
              FONT, F, HEIGHT, H, JUSTIFY, J, ROTATE, R
     WPS Issue 5049, corrected in WPS 2.2.2 GA Build 9037, Mar 10, 2008.

 3. WPS 2.2.2 Build 8792 failed in ANALCISH in the $macro processor with
       ERROR: The %IF condition is invalid. The condition was:
          &REP EQ CICDMR OR &REP EQ CICDMG AND &SWDOMN EQ 0
    Discovered Feb 9.
    WPS Issue 5048, corrected in WPS 2.2.2 GA Build 9037, Mar 10, 2008.


 2. WPS 2.2.2 Build 8792 executed MXG QA tests but these members do not
    execute for the reason noted:

      ANALAVAL  - PROC CALENDAR does not exist in WPS.
      ANALCICS  - HBAR statement in PROC CHART is not supported.
      ANALCISH  - ERROR: THE %IF CONDITION is invalid.
      ANALMONI  - HBAR statement in PROC CHART is not supported.
      ANALMPL   - VREVERSE in PLOT statement is not known in PROC PLOT.
      ANALTAPE  - VREVERSE in PLOT statement is not known in PROC PLOT.
      ANALPATH  - OVERPRINT option in PUT statement is not supported.
      ANALPRNT  - HBAR statement in PROC CHART is not supported.
      ANALRMFR  - ERROR: Found "DATA" when expecting Angle.
      ANALSMF   - HBAR statement in PROC CHART is not supported.
      ANAL30DD  - %RUN;- Expected a statement keyword, found "%"
      ANAL80A   - PROC REPORT not known.


 1. WPS 2.2.1, the then current GA Version, failed in MXG QA test,
    with    ERROR: Illegal length 40 supplied for format
    (an internal WPS "format", not related to an MXG Format).
    This has been corrected (Bug 5004) in WPS 2.2.2 Build 8792,
    but only for z/OS; as of Feb 9, there is no z/OS Build 8777+.
    WPS Issue 5004, corrected in WPS 2.2.2 GA Build 9037, Mar 10, 2008.


VII. CICS Technical Notes.

 1. MXG updates to an ASKQQA Item:

  How can I exclude specific fields from performance-class monitoring
  records; we don't use any web related transactions, so how can I
  exclude those fields from my SMF 110 subtype 1 CICSTRAN records?

  Excluding unused fields in the MCT can reduce the size of the CMF
  performance records written as SMF 110 records and is very commonly
  done by MXG users.


  a. There are some sample MCTs in SDFHSAMP that show how to exclude
     fields.  The names of the members are of the form DFHMCTxx.  One
     these, DFHMCTF$, is designed for a file owning region (FOR) where
     there would be no web work done so it does show the web entries
     being excluded.  However, it does exclude other items that you
     would not want to exclude in a TOR or AOR.

  b. The groups that you might exclude that are related to the web
     include DFHDOCH (document handler), DFHSOCK (assuming you do not
     use any CICS TCPIPSERVICEs) and DFHWEBB (web support).  There may
     be individual fields in some other groups that relate to the web so
     you could review the other groups.

     Other groups not specifically related to the web that are often
     candidates for exclusion are DFHCBTS (business transaction
     services), DFHDATA (IMS and DB2), DFHEJBS (EJBs) and DFHFEPI
     (FEPI).



VIII. Windows NT Technical Notes.


IX.  z/VM Technical Notes.


X.    Incompatibilities and Installation of MXG vv.yy.

 1. Incompatibilities introduced in MXG 25.yy (since MXG 24.24):
    See CHANGES.

 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 JCLINST9 for
    SAS V9.1.3 or JCLINST8 for SAS V8.2.

XI.   Online Documentation of MXG Software.

    MXG Documentation is now described in member DOCUMENT.


XII.  Changes Log

--------------------------Changes Log---------------------------------

 You MUST read each Change description to determine if a Change will
 impact your site. All changes have been made in this MXG Library.

 Member CHANGES always identifies the actual version and release of
 MXG Software that is contained in that library.

 The CHANGES selection on our homepage at http://www.MXG.com
 is always the most current information on MXG Software status,
 and is frequently updated.

 Important changes are also posted to the MXG-L ListServer, which is
 also described by a selection on the homepage.  Please subscribe.

 The actual code implementation of some changes in MXG SOURCLIB may be
 different than described in the change text (which might have printed
 only the critical part of the correction that need be made by users).

 Scan each source member named in any impacting change for any comments
 at the beginning of the member for additional documentation, since the
 documentation of new datasets, variables, validation status, and notes,
 are often found in comments in the source members.

Alphabetical list of important changes after MXG 24.24 now in MXG 25.01:

  Dataset/
  Member   Change    Description

  See Member CHANGES or CHANGESS in your MXG Source Library, or
  on the homepage www.mxg.com.

Inverse chronological list of all Changes:

Changes 25.yyy thru 25.001 are contained in member CHANGES.

*********************NEWSLETTER FIFTY-ONE*******************************




       MXG NEWSLETTER NUMBER FIFTY-ONE, December 6, 2007.

Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE

                         TABLE OF CONTENTS

I.    MXG Software Version.
II.   MXG Technical Notes
III.  MVS, aka z/OS, Technical Notes
IV.   DB2 Technical Notes.
V.    IMS Technical Notes.
VI.   SAS Technical Notes.
VI.A. WPS Technical Notes.
VII.  CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX    z/VM Technical Notes.
X.    Incompatibilities and Installation of MXG.
         See member CHANGES and member INSTALL.
XI.   Online Documentation of MXG Software.
         See member DOCUMENT.
XII. Changes Log
     Alphabetical list of important changes
     Highlights of Changes  - See Member CHANGES.

     COPYRIGHT (C) 1984,2007 MERRILL CONSULTANTS DALLAS TEXAS USA

I.  The 2007 Annual Version MXG 24.24 was dated February 5, 2007.

    All sites were mailed a letter with the ftp download instructions.
    The availability announcement was posted to both MXG-L and ITSV-L.
    You can always request the current version using the form at
     http://www.mxg.com/ship_current_version.

 1. The current version is MXG 25.11, dated DEC  7, 2007.

    See CHANGES member of MXG Source, or http://www.mxg.com/changes.

II.  MXG Technical Notes


III. MVS, a/k/a z/OS, Technical Notes.

 7. APAR OA22991 documents why RMF III XCF DELAY REPORT may present
    misleading information:
     RMF III XCF Delay report may show jobs in a 100% XCF Delay when in
     fact they do no XCF signaling. RMF III in its display uses the
     home asid at the time an XCF signal was sent as passed from XCF in
     field AMDHOME (initialized from SIOCB_HomeAsidF) as passed from XCF
     module IXCA1MG.  This is misleading because a function/routine may
     be driven via a timer pop and do an IXCMSGO while executing under
     any job in the system. XCF is known to do this for transport layer
     signals. For signals issued while in Timer SLIH mode, XCF should
     not indicate a AMDHOME asid of the current dispatched job, but
     rather the signal sender.  VERIFiCATION STEPS:
       a. In a svcdump requested while RMF III is reporting XCF
       DELAYS for a particular job, do a XESDATA SIGNAL DETAIL report.
       b. Max down to the bottom of the report and examine the
       measurement data for MSGPEND. There should be entries that
       show MASID=0006 and MHOME=xxxx where xxxx is the asid of
       the job that is invalidly being report in an XCF Delay.

 6. APAR OA22958 documents, with no correction, why the RMF WLMGL WKLD
    Activity report has lower SSCHRT than expected when Device Pend
    Time is zero:

     RMF Workload activity reports may report a lower than expected
     DASD Start Subchannel Rate (SSCHRT) value as compared to the
     actual dasd activity rates for the system.   This will occur as
     the calculated PEND and control unit queue times are zero.   IOS
     does not capture measurements when the wait time (PEND + CUQ)
     is zero for an individual i/o interrupt.
     VERIFICATION STEPS:
     a. Lower than expected SSCH Rate on Workload activity report.
        when comparing TOTAL dasd activity to TOTAL reported
        workload.  Anything greater than 10%  can be explained
        by this phenomenon.
     b. Also review overall pend time for dasd.  If zero, then this
        is supporting evidence.

 5. APAR OA22388 reports and corrects SMF64BUF and SMF64CB flags in the
    SMF64RSC byte which were not turned on for biases other than DO with
    SMB processing.

 4.  HIPER APAR OA21884 - JES HANGS DURING ALL-MEMBER WARMSTART

     ERROR DESCRIPTION:  z/OS 1.8 ONLY:

     During an all member warm start, JES2 can $wait in HASPMISC near
     ENFP9200. This happens when there is a new or different WLM Policy
     defined that doesn't match the policy last in effect when JES2 was
     shut down.  The $WAIT will not be resolved because the checkpoint
     processor is not dispatchable during warmstart -- meaning JES2 will
     not start.

     The problem reported by OA21884 occurs only if an all-member JES2
     warmstart is performed **and** a new WLM service definition was put
     into place while JES2 was not running.

     The fixing PTF for z/OS 1.8 is UA35883.

 3.  CICS Transactions from LU 6.2 devices may all have the same UOWID
     value.  A possible explanation:

        One possible source of these transactions was found with CA's
        CommBridge software, related to CA's recommended implementation
        using Microsoft SNA Server, which creates the problem, instead
        of IBM's SNA Server solution, IBM Communication Server (CS),
        which includes FTP server/client and other TCP/IP related
        tools/services, including SNA over TCP/IP, references below.

        One test server was changed to use the IBM solution, apparently
        free with z/os, and the UOWIDs are all unique, so they can be
        used to correlate to other related transactions/threads/tasks.

        Thus when all transactions have the same UOWID, it's likely
        that there's some software sitting on a Windows Server using a
        transaction spawner which is supplying an FMH-5 header package
        in the transaction (possibly the last boot time for the server
        box), which is causing CICS not to generate a unique UOWID
        string.

        z/OS Communications Server:
        http://www-306.ibm.com/software/network/commserver/zos/features/

        visual of IBM CS enabled environment:
        ftp://ftp.software.ibm.com/software/network/commserver/
             brochures/commservspec.pdf

        IBM Redbook...Modernizing the SNA Environment:
        http://www.redbooks.ibm.com/redbooks/pdfs/sg247334.pdf

 2.  SYNCSORT can page fix many pages when many concurrent SORTs are
     running with the 64-bit version of SYNCSORT.  A new fix from them
     will limit memory to 64M per sort (which covered 98% of the sorts
     at the reporting site).   The problem is that the 64-bit version
     changed the meaning of VSCORET; originally the upper limit on
     memory, now is the lower limit.  The SYNCSORT enhancement, XXXXXXX
     now provide the missing upper limit.

 1.  SMF 30 interval records are NOT written for GDPS HyperSwap Address
     Spaces GEOHSWP, GEOXCFST, and XCFAS.  The IBM claim is that the SMF
     recording must be stopped otherwise the HyperSwap tasks can be left
     hanging, which in turn may result in production systems being
     shutdown because the HyperSwap cannot complete.  At the present
     time, this appears to ONLY be documented in an explanation
     provided by a GDPS support specialist (PMR 31381,070,618).

     We turn off SMF interval recording in three address spaces
     (GEOHSWP, GEOXCFST and XCFAS), for the following reason. SMF
     interval processing is done by scheduling an SRB to run in each
     address space. This SRB gets the CMS and local lock of the address
     space and then builds the SMF interval record. In the process of
     building the interval record the SRB code references SMF control
     blocks in the address space that are not page fixed.  On systems
     that have real storage contention these control blocks are going to
     be paged out, because they don't get referenced very often. If we
     are in the process of doing a HyperSwap where we have I/O suspended
     to all of the PPRC volumes and the paging volumes are included in
     these volumes, this SMF SRB effectively dead locks the address
     space because it has the CMS and local lock and has taken a page
     fault that can not complete until the HyperSwap completes. The
     HyperSwap process is completely dependent on these three address
     space functioning. In our testing before we created this capability
     to turn off SMF interval processing in an address space, we
     certainly saw hangs in the HyperSwap process because of this
     problem in the GEOHSWP and GEOXCFST.  I don't believe that we saw a
     hang because of this problem in the XCFAS address space, but I just
     wanted to make sure that it would not happen.  Based on this you
     will not get the interval records.

     Thus, at the present time, the only way to track the resource
     consumption of these address spaces, especially XCFAS, is to set up
     a separate Service Class for each ASID, and use the RMF Type 72
     records instead of type 30 records; while this provides some of
     the information, it is only a subset of the type 30 data.

IV.   DB2 Technical Notes.

 2. DB2 usage of zIIP Engines.  From APAR PK18454:

    The DB2 accounting trace records provide information related to
    application programs including processor resources consumed by the
    application. Accumulated zIIP CPU time is not accumulated in the
    existing class 1, class 2, and class 7 accounting fields.  New
    accounting fields are defined to let users know how much time is
    spent on IBM zIIPs, as well as how much time zIIP eligible work
    overflowed to standard processors. CPU time eligible for offload to
    a zIIP processor is provided in the accounting records even if a
    zIIP is not online or DB2 is not running on a z9 mainframe.

    Changes to IFCIDs 0003, 0231, 0239, 0147 and 0148 as mapped by the
    following macros:
      DSNDQPAC - PACKAGE/DBRM ACCOUNTING DATA MAPPING MACRO
      DSNDQWAC - ACCOUNTING DATA MAPPING MACRO
      DSNDQWHU - IFC CPU HEADER MAPPING MACRO
      DSNDQW01 - IFCID HEADER MAPPING MACRO
      DSNDQW02 - IFCID HEADER MAPPING MACRO
      DSNDQW03 - PARALLEL GROUP TASK TIME TRACE MAPPING MACRO


 1. Blank Package Names with ACCUMACC GE 2:

    A user reported blank package names to IBM when they upgraded to V8,
    in DB2PM reports, and received this reply from DB2 Support:

    "This is working as designed, because you have rollup ON (which you
    do if ACCUMACC GE 2), the only valid fields in accounting records
    will be documented at the top of the external mapping macros.

    For example, in your case you may want to refer to DSNDQPAC which
    maps package information.  Clearly text cannot be rolled up, so
    textual fields are excluded from the list (attached below) of valid
    data fields.

      DDF and RRSAF threads:
      A rollup record is written with accumulated counter data for an
      end user when the number of occurrences of the end user on the
      thread reaches the Zparm value for ACCUMACC.  End user is defined
      as the concatenation of the following three values:
       - End user userid (QWHEUID, 16 bytes)
       - End user transaction name (QWHCEUTX, 32 bytes)
       - End user workstation name (QWHCEUWN, 18 bytes)
         QPACSCT  QPACTJST QPACARNE QPACAWTI QPACAWTL QPACAWTR QPACAWTW
         QPACAWTE QPACALOG QPACARNL QPACARNR QPACARNW QPACARNS QPACALCT
         QPACARND QPACAWDR QPACAWCL QPACARNC QPACAWAR QPACANAR QPACAWTP
         QPACARNH QPACAWTG QPACAWTJ QPACARNG QPACARNJ QPACAWTK QPACAWTM
         QPACAWTO QPACAWTQ QPACARNK QPACARNM QPACARNN QPACARNO QPACARNQ
         QPACCLS7_ZIIP
      By rolling up accounting data, there is some loss in detail.
      Users will have to weigh the cost/benefit of rollup.
      We are sorry that we can't make everything work as you may want,
      but we will try."

     The DSNZPARM ACCUMACC parameter, new with V8, defaults to '10'.
     The user set a ACCUMACC to 'NO' and no longer saw the problem.

     MXG note added Apr 9, 2008:  The MXG variable QWACRINV in the
     DB2ACCT dataset has value 1, 2, or 3 if that observation is
     an ACCUMACC Rollup Record, with accumulated and sometimes quite
     questionable values. Use only after examination of your data.

V.   IMS Technical Notes.

VI.  SAS Technical Notes.


 1. Memory shortages might cause SAS jobs to end abnormally.

    SAS Note SN-V9-018401 is repeated in its entirety:

    If SAS jobs end abnormally on a sporadic basis, you should review
    the SAS log for memory-related termination codes such as 878, 80A,
    or 0F9.  You might encounter these termination codes whenever you
    run system routines.  Or A78 ABENDS.

    The abnormal endings that are referenced above might occur when a
    previous SORT procedure uses a very large amount of memory. In
    particular, the IBM product DFSORT 1.13 and later has a block-mode
    sorting feature that enables a SAS job to use very large amounts of
    memory. When a SAS job attempts to use this memory, the abnormal
    endings might occur.

    SAS Technical Support recommends three steps that you should follow
    if your SAS job ends abnormally due to memory-related problems:

    1. Ensure that your SAS job does not use an unlimited value for the
    REGION= option (for example, REGION=0M). SAS Technical Support
    strongly recommends that you limit the memory that is available to
    SAS jobs. Some SAS procedures will use as much memory as you make
    available. Such a situation can adversely affect the performance of
    your system.  Most SAS@ 9.1.3 jobs can run efficiently within a 64MB
    region, but you might need to increase the region size for some
    jobs.

    2. Set the MEMLEAVE= system option so that you reserve a portion of
    the available region that SAS will not use. This precaution helps to
    ensure that some memory will be available for running system
    routines. The MEMLEAVE= option defaults to 512K. If your SAS job has
    memory-related problems, a general guideline is to set the MEMLEAVE=
    option to 10% of the size of your region. For example, if
    REGION=128MB, then set MEMLEAVE=13MB.

    3. If your SAS job uses DFSORT, you might observe in the SAS log
    that a prior PROC SORT used a large amount of memory. If your SAS
    job ends abnormally with a termination code such as 878, 80A, or
    0F9, as a last resort you should turn off DFSORT's block-mode
    sorting feature by specifying the NOSORTBLKMODE system option.


VI.A.  WPS Technical Notes.


1.  Current status of MXG testing under WPS Betas in November, 2007.


 a. What has been tested successfully:

    MXG QA compile-only (dummy INFILEs) TYPExxxx and TYPSxxxx members
       This exercised the MXG DATA-step Code for compile errors,
       and created DOCVER to compare the contents of WPS-built
       datasets (variables, LENGTHs, LABELs, FORMATs).
          Steps 1 thru 36 of the QAJOBXX were tested.
    Default BUILDPDB with 480MB SMF File
    Tailored BUILDPDB with IMACEXCL with 480 MB SMF File
    TYPETPMX with small file - verified 72 position FORMATs worked.
    TYPENTSM with test file  - verified open-system-style MXG code.


 b. WPS Betas are often updated daily, and as errors were encountered in
    MXG tests on z/OS and Windows/XP, a new Beta was generated which did
    correct each error that could be fixed short-term.  The current Beta
    tested is World Programming System 2.02 (02.02.00.08458) of Nov 27.
    Subsequently, the GA Release 2.2 (02.02.00.08460) was also tested.


 c. MXG Version 25.11 is required for testing under WPS; its updates
    eliminate the need for user modifications to MXG Software, and new
    WPS-specific members (CONFIGW2, MXGWPSV2, JCLINSTW, AUTOEXEW) were
    added.


 d. Facilities used by MXG Software not yet in WPS for z/OS:

     INFILE CCHHR option - needed only for TYPEEREP (EREP, SYS1.LOGREQ),
                           VMXGVTOC (archaic, replaced by TYPEDCOL), and
                           the UTILSPAC utility report.
     VIEWS               - for CPU & I/O performance, used in VMXGSUM
                           invoked over 60 time in QA BUILDPDB, and in
                           all ASUMxxxx and TRNDxxxx members.
                           eliminates a full pass of the input data.
     PROC CONTENTS       - minor, does not report High Block Used size.


 e. Facilities used by MXG Software not yet in WPS for z/OS and Windows:

     INFILE with ftp access method - performance slower, more disk space
     SAS/GRAPH, SAS/STAT, SAS/ETS, etc.
     Currently WPS supports the Base DATA Step Support and a few PROCs,
      including PRINT, MEANS, CONTENTS GPLOT, GCHART, with more planned.


 f. Output differences - minor

     PROC MEANS printed output - some values printed with one digit more
                                  resolution by WPS.
                               - no error in output values spot checked
                               - prevents automated output comparisons


 g. Untested - most due to complexity or time to set up multiple inputs:

    The WPS Workbench and its Workspace(s) and Projects.
      The WPS interactive human interface, was not used.
      It is VERY different than the SAS Windows or TSO interfaces.
      I didn't have the time to learn another human interface.
      But if you know Eclipse platform stuff, might be familiar.


     DATA Libraries on TAPE

     WEEKBLDT, MNTHBLD special TAPE format to DISK, DISP=MOD, etc.

     TESTTRND, TESTANAL  - requires extensive test data

     ANALxxxx            - requires test data

     ASUMxxxx            - except ASUMJOBS, ASUM70PR were tested.

     UTILxxxx            - specialized utilities for MXG Tech Support

     Internal SORT       - on z/OS, internal SAS SORT may be required
                           when BY list variables don't fit in first
                           4096 bytes.

     NFS Files           - not tested.

     Broken VBS files    - not tested.


 h.  Migration issues  - see WPS Migration Instructions:

     On z/OS, copy all archived SAS Data Libraries on DASD (including
     HSM migrated) to tape (Sequential) format with the SAS System
     first.

     WPS can read SAS Data Libraries in SEQUENTIAL format on tape or
     DASD.

     WPS cannot read DASD format SAS Data Libraries


 i. Customer reports:

     Several MXG customers have been running their BUILDPDB on z/OS.

     Early tests had to make source-level-changes to a few MXG members.

     Most had relatively simple BUILDPDBs with minimal tailoring.


 j. MXG Support Position for testing of WPS Releases:

       The Current MXG Version and the Current WPS Version are required.

       Your current MXG Software License Agreement states:

        Merrill agrees to provide continuous product support for MXG in
        the following areas:
          When error conditions
            (i.e., the SAS execution of MXG code produces either a
            return code or an ABEND)
          are the results of errors in MXG Code, they will be corrected.

        If you encounter an error testing MXG under WPS:

           You should report the error to WPS Technical Support for
           initial investigation.

           If WPS support believes the error is an MXG problem, they can
           contact MXG, or may choose to refer you to MXG Support.

           MXG Support may then request you to send data to MXG:

              - the raw data file that caused the error
              - your site's USERID.SOURCLIB (tailoring) source library

           If the error can be replicated under the SAS System, it will
           be corrected per our license terms.


2.  Run time comparisons:

    All tests were run as batch commands or batch jobs, with inputs and
      outputs read from and written to disk files, using -autoexec to
      point to autoexew.sas.

            BUILDPDB,ASUMJOBS,ASUM70PR with 448 MB SMF File

                            z/OS Comparison

        CPU TCB    Elapsed     ----------- Compressed ----------------
        minutes    minutes     Work Size     PDB Size    CICSTRAN Size

  SAS:   3.88        5.20       209 MB        55 MB         59 MB

  WPS:  10.67       18.50       233 MB        59 MB         67 MB


                         Windows/XP Comparison

  SAS:    1.20       2.18       Note 1        65 MB          63 MB

  WPS:    1.93       2.71       Note 1        78 MB          70 MB


     z/OS tests were executed on IBM 2094 CPU Model S08, SU_SEC=9708.
     Windows tests executed on Intel Duo Core T5500 @ 1.66 GHz.


     Note 1:  Neither WPS nor SAS provide a way to track maximum work
              space on ASCII


3.  Revisions to SAS Clones article in MXG Technical Newsletter FIFTY:

      WPS is no longer vapour-ware.

      The company has bent over backwards to provide corrections.

      Performance of WPS, when written in JAVA, was so poor (run times
      were at least ten times worse than the current Beta) that the
      product no longer uses JAVA, so it cannot exploit zAAP engines.

      Items listed in sub-paragraphs i, ii., iii., and iv. have all been
      addressed to my satisfaction, with the exception of the items that
      are listed above in this note.

      Pricing is significantly reduced from those original IBM prices.

      As an example, an MXG site in the USA was quoted an IBM price for
      a 21 Value Unit system (about 1000 MIPS) of $42,000 first year and
      $8,400 for renewals.  WPS can be licensed through IBM or through
      World Programming; their home page is at http://www.teamwpc.co.uk


4.  Summary:

       Most of MXG has compiled successfully under WPS on both z/OS and
       Windows/XP.

       BUILDPDB has compiled and processed SMF data on both z/OS and
       Windows/XP.

       A lot of MXG still needs to be tested with data.

       WPS is still in development.

       WPS will roll this Beta into a GA release of WPS 2.2 this week.

       WPS on z/OS requires thrice the CPU and Elapsed Run Time of SAS.

       WPS on Windows/XP CPU and run times are similar to SAS run times.

       Disk Space required on both platforms are similar.

       So, it is your choice at this time to test MXG under WPS.

       And, it's your evaluation of your MXG programs that should
         determine if you believe that WPS is "Ready for Prime Time",
         at your site, with your current CPU and run times and with the
         MXG programs and SAS facilities that you utilize.


5.  QA Steps successfully compiled and executed with dummy input.

     STEP  3. CREATE FORMAT LIBRARY
     STEP  4. RUN TESSNT
     STEP  5. RUN TESSIBM
     STEP  6. RUN TESSIBM1
     STEP  7. RUN TESSIBM2
     STEP  8. RUN TESSIBM3
     STEP  9. RUN TESSUSER
     STEP 10. RUN TESSUSR1
     STEP 11. RUN TESSOTHR
     STEP 12. RUN TYPSCMHM
     STEP 13. RUN BUILDPD3+ASUMS
     STEP 14. RUN BUILDPDB+ASUMS
     STEP 15. RUN TYPERMFV
     STEP 16. RUN TYPECMFV+TYPEMVCI
     STEP 17. RUN TESSHSM
     STEP 18. RUN TESSFACO
     STEP 19. RUN TESSDOS
     STEP 20. RUN TESSVM
     STEP 21. RUN TESSCRAY
     STEP 22. RUN TESSHPCS
     STEP 23. RUN TESSUNIA
     STEP 24. RUN TESSUNIK
     STEP 25. RUN TESSQAPM
     STEP 26. RUN TESSQACS
     STEP 27. RUN TESSTUX
     STEP 28. RUN TESSPW
     STEP 29. RUN ASUMPRTR
     STEP 30. RUN TYPEIMS7
     STEP 31. RUN TESSIMSD
     STEP 32. RUN COPYSTEP
     STEP 33. RUN TESSTRND - partially completed, not WPS fault.
     STEP 34. RUN TESSMNTH
     STEP 35. RERUN TYPE-S FOR NON PROC SORT FOR DATASET LABEL
     STEP 36. RUN CROSSREF
     STEP 37. RUN DOCVER   - output DOCVER file is identical.



VII. CICS Technical Notes.



VIII. Windows NT Technical Notes.


IX.  z/VM Technical Notes.


X.    Incompatibilities and Installation of MXG vv.yy.

 1. Incompatibilities introduced in MXG 25.yy (since MXG 24.24):
    See CHANGES.

 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 JCLINST9 for
    SAS V9.1.3 or JCLINST8 for SAS V8.2.

XI.   Online Documentation of MXG Software.

    MXG Documentation is now described in member DOCUMENT.


XII.  Changes Log

--------------------------Changes Log---------------------------------

 You MUST read each Change description to determine if a Change will
 impact your site. All changes have been made in this MXG Library.

 Member CHANGES always identifies the actual version and release of
 MXG Software that is contained in that library.

 The CHANGES selection on our homepage at http://www.MXG.com
 is always the most current information on MXG Software status,
 and is frequently updated.

 Important changes are also posted to the MXG-L ListServer, which is
 also described by a selection on the homepage.  Please subscribe.

 The actual code implementation of some changes in MXG SOURCLIB may be
 different than described in the change text (which might have printed
 only the critical part of the correction that need be made by users).

 Scan each source member named in any impacting change for any comments
 at the beginning of the member for additional documentation, since the
 documentation of new datasets, variables, validation status, and notes,
 are often found in comments in the source members.

Alphabetical list of important changes after MXG 24.24 now in MXG 25.01:

  Dataset/
  Member   Change    Description

  See Member CHANGES or CHANGESS in your MXG Source Library, or
  on the homepage www.mxg.com.

Inverse chronological list of all Changes:

Changes 25.yyy thru 25.001 are contained in member CHANGES.

*********************NEWSLETTER FIFTY***********************************




       MXG NEWSLETTER NUMBER FIFTY, September 5, 2007.

Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE

                         TABLE OF CONTENTS

I.    MXG Software Version.
II.   MXG Technical Notes
III.  MVS, aka z/OS, Technical Notes
IV.   DB2 Technical Notes.
V.    IMS Technical Notes.
VI.   SAS Technical Notes.
VI.A. WPS Technical Notes.
VII.  CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX    z/VM Technical Notes.
X.    Incompatibilities and Installation of MXG.
         See member CHANGES and member INSTALL.
XI.   Online Documentation of MXG Software.
         See member DOCUMENT.
XII. Changes Log
     Alphabetical list of important changes
     Highlights of Changes  - See Member CHANGES.

     COPYRIGHT (C) 1984,2007 MERRILL CONSULTANTS DALLAS TEXAS USA

I.  The 2007 Annual Version MXG 24.24 was dated February 5, 2007.

    All sites were mailed a letter with the ftp download instructions.
    The availability announcement was posted to both MXG-L and ITSV-L.
    You can always request the current version using the form at
     http://www.mxg.com/ship_current_version.

 1. The current version is MXG 25.08, dated Sep  5, 2007.

    See CHANGES member of MXG Source, or http://www.mxg.com/changes.

II.  MXG Technical Notes

 3.  Changes to Daylight Saving Time in 2007 have no MXG impact.

      MXG Software code is impervious to Daylight Savings Time; we give
      you the data that is in your RMF,SMF, etc. data, as you choose to
      create it.

      If you choose to set your clocks back on an active system, you
      corrupt many datetime values (i.e, jobs end before they start,
      negative elapsed times, intervals end times before their begin
      time, etc.), and you will create multiple records with the same
      STARTIME in all RMF datasets, as well as CICINTRV, SMFINTRV, and
      any other interval datasets, but that's the result of your choice
      to set back clocks on an active system, and not of MXG's doing.
      If the  records also contain an actual GMT Offset field, those
      pairs of same-STARTIME observations can be identified, but your
      hourly reports for the hour of time setback will have
      pseudo-duplicate data.

      MXG Change 24.224 (in MXG 24.09) for the ASUM70PR summarization
      example now protects the TYPE70PR RMF data so that those
      pseudo-duplicates are summarized as separate observations, with
      different GMTOFFTM values, but with the same STARTIME values,
      i.e., you still have duplicate STARTIME values in your data.

      Note that if your installation uses the TIMEBILD architecture (to
      tell MXG to change all datetime variables from SYSTEM's that are
      on different time zones to a common timezone), as long as you
      correctly update the mapping table in advance of the time change,
      MXG will correctly handle each system's time change, but, again,
      if you choose to set clocks back on an active system, all of the
      preceding caveats apply.

      It is precisely when you have local time as a result of the GMT
      Offset that you are exposed to errors if you change the time
      (i.e., change the GMT Offset) backwards on an active system.  If
      you have a GMT Offset of zero, and you keep all your clocks on
      GMT, there would be no change in your timestamps.

      This information was posted to our MXG-L ListServer in Jan, 2007.

 2.  Very Long Stored-Length MXG Variables + COMPRESS=YES on z/OS.

     a. This new text was added in November, 2009:

     Be careful if you change from YES to COMPRESS=NO:

     While SAS on z/OS does measure an appreciable increase in both the
     CPU time and Elapsed Time, changing the MXG default to COMPRESS=NO
     to save CPU time could massively increase disk space requirements.
     And, only SAS on z/OS has the CPU time increased.  Benchmarks of
     SAS on Intel showed COMPRESS=YES used LESS CPU & Run Time, because
     Intel's cost of CPU-to-do-I/O was reduced more, with less data,
     than the cost of CPU-to-Compress that data.

     Many MXG datasets now contain character variables with long stored
     lengths, $128 or $256 or even $32000 bytes, the maximum text length
     of new thingies like Open Systems Path Names, SQL Text, Websphere
     names, DB2 Unicode text, CICS user identities, etc., but since SAS
     stores character data in fixed length fields, and since these new
     data fields typically have only 8 characters and a lot of blanks,
     the COMPRESS=YES option is really REQUIRED to store these highly
     compressible text data fields.

     And, a CPU increase may be secondary to running out of disk space.


     b. This was the original 2007 Newsletter Article, with the list of
        long variables updated in November, 2009:

     MXG's COMPRESS=YES default can be changed to COMPRESS=NO (in your
     CONFIGV9 for z/OS or AUTOEXEC for ASCII);  one z/OS site reported
     they exchanged a 25% reduction in the CPU time, for a 10% increase
     in EXCP counts, and a whopping 70% increase in DASD space, but as
     their job ran when its LPAR was capped, the run time was reduced.
     COMPRESS offers resource and time tradeoffs, but "IT ALL DEPENDS".

     However, there a few MXG datasets that really SHOULD be compressed,
     because they define "Very Long Stored-Length" variables, with their
     LENGTHs of 1024 or 32000 bytes, required because those text fields
     (SQL text, open system path names, etc.) can be that long!

     So, if you change BUILDPDB to COMPRESS=NO, and you have obs in the
     below datasets created from SMF, you could see an even larger
     increase in DASD space required because of those long variables!

     Three groups of datasets with "Very Long Stored-Length" variables,
     1024 or more bytes, created by MXG 25.07+, could require increased
     disk space if COMPRESS=YES is disabled, with no other impact:

       1. Datasets automatically built by standard BUILDPDB:

       Datasets  Variables     Description                     Length

       TYPESYMT   SYSLTEXT     Syslog Mount-Related Event text   1024
       TYPESYSL   SYSLTEXT     Syslog Message Text               1024
       ASUMTAPE   SYSLTEXT     Syslog Message Text               1024

       2. Datasets built from SMF records, could impact BUILDPDB if
          user-added.  Many MXG sites have added TYPE80A processing of
          ID=80 RACF records, which creates a lot of TYPE80nn datasets,
          and TOKDCE is kept in them all.  Some MXG sites have added the
          creation of specific T102Snnn DB2 TRACE (ID=102, IFCID=nnn),
          especially those that contain the long-length SQL text fields.

       Datasets  Variables     Description                     Length

       TYPE80nn   TOKDCE       DCE                               1024
       TYPE83LD   LDAPLDAP     LDAP*RELOCATE*007                 1024
       TYPE83LD   LDAPNAME     LDAP*RELOCATE*008                 1024
       TYPE9201   SMF92PPN     PATHNAME*OF DIRECTORY             1024
       TYPE9215   SMF92APN     FILE*PATH*NAME                    1024
       T102Snnn   QW0nnnTX     SQL Text 140,141,142,145         32000
                  QWnnnnnT     SQL Text 124                     32000
                  QW0nnnCN     Cursor Name 59,61,64,65,66       32000
                  QW0nnnCT     Command Value 90                 32000
                  QW0nnnDS     MSG or FMH-5 DATA 180,194        32000
                  QW0nnnHR     RECOVERY LOG NAME 207            32000
                  QW0nnnON     Object Name 62                   32000
                  QW0nnnMR     LAST MESSAGE RCVD 206,208,236    32000
                  QW0nnnMS     LAST MESSAGE SENT 206,208,236    32000
                  QW0nnnPA     LOCATION NAMES 203               32000
                  QW0nnnP1     AMS COMMAND TEXT 92,97           32000
                  QW0nnnMS     Message Text 4,5                 32000
                  QW0nnnSP     SQL STMNT    350                 32000
                  QW0nnnST     SQL STMNT    63,168              32000
                  QW0nnnTH     INFORMATION FOR THREAD  204      32000
       T1028005   QBMCTEXT     BMC DB2 SQL Text                  4096
       SHDWnn     SM06SQSR     SQL Source String                32000


       3. Datasets NOT created from SMF records, with long variables:

       TYPETPFC   TPFCUSER     User Data Field                   1024
       RACFnnnn   HFSNAME      Path Name of File/Directory       1024
       TYPEWWW    COOKVALU     Cookie Value                     32000
                  URIQUERY     Request Argument                 32000
                  SITENAME     S-Sitename                       32000

     You can specify COMPRESS=NO globally in your CONFIGV9/AUTOEXEC, but
     then compress individual datasets, by redefining the "Keep" macro
     to contain MACRO _Kdddddd COMPRESS=YES % for each "dddddd" dataset
     to be compressed.  All of your _Kdddddd definitions can be stored
     in your IMACKEEP tailoring member, or "instream" with:
       //SYSIN DD *
         %LET MACKEEP=
          %BQUOTE(
              MACRO _KTY8001  COMPRESS=YES  %
              MACRO _KTY8002  COMPRESS=YES  %
                        ...
              MACRO _KTY80nn  COMPRESS=YES  %
          );
         %INCLUDE SOURCLIB(....);

     If you DO compress, there is no space taken for long LENGTHs, but
     if you DON'T compress, and you don't need the full default length,
     you can reduce the variable's length and save disk space.  You can
     change the length of any character variable created from SMF by
     adding a LENGTH statement in your IMACFILE member, or by passing
     that LENGTH statement with the &MACFILE macro variable:

       //SYSIN DD *
        %LET MACFILE=  %BQUOTE(  LENGTH TOKDCE $8; ) ;
        %INCLUDE SOURCLIB(TYPS80A);

        The IMACFILE exit places that LENGTH statement so it is seen
        before the normal MXG LENGTH statement, so TOKDCE would be $8 vs
        $1024 in all of the TYPE80nn RACF datasets.

        You can NOT change the LENGTH of a NUMERIC variable in the
        IMACFILE exit nor with &MACFILE, because SAS uses the LAST
        instance of a LENGTH statement for numeric variables (and the
        FIRST for character variables!).  But you can add a LENGTH
        statement in any EXdddddd exit member for that product to change
        a numeric variable's length, since that code is seen AFTER the
        MXG LENGTH statement.

 1.  Comparison of BUILDPDB on z/OS with Version 23 and 24, SAS 9.1.3:

           Input SMF file: 9070 MegaBytes

                                CPU     Elapsed
           Job or Step          mm:ss   mm:ss

           V23 SMF read Step    11:22   15:16
           V23 BUILDPDB Job     13:19   19:36

           V24 SMF read Step    11:13   15:05
           V24 BUILDPDB Job     13:08   19:19

     This is a heavily enhanced BUILDPDB that processes many additional
     SMF records and creates many more datasets than the MXG default.
     The big data step required a REGION=130M for the buffers for those
     added datasets.  The CPU times are on a SU_SEC=10,000 machine.

III. MVS, a/k/a z/OS, Technical Notes.

20. APAR PK44207 corrects errors introduced in RMF maintenance APARs
    that caused RMF messages "WSAM IS UNABLE TO CAPTURE CPU AND PAGING".

19. APAR OA21590 corrects SMF ID=85 OAM errors.

18. APAR OA20955 documents new facilities when SMF data is recorded to
    System Logger log streams rather than VSAM files, and an exit that
    allows programs to allocate a log stream specifying SUBSYS=LOGR and
    read it via normal QSAM I/O instead of via Logger IXGBRWSE service.

17. APAR OA20761 for z/OS 1.9 has corrected the sample IEFACTRT exit
    that was initially shipped with z/OS 1.9; the erroneous member
    did not handle time stamps correctly as noted in the APAR text.

16. APAR OA18118 added SMF14KET to ID=15 with Tape Encryption elapsed
    duration, but also corrected the encryption encoding.  Change 25.047
    in MXG 25.03 added SMF14KET support.

15. APAR OA21982 corrects invalid ID=0 SMF records that are supposed to
    be ID=40 records.  Dynamic Allocation is the culprit and these ID=0
    records contain all zeros except for the length in the RDW.  Since
    MXG has always recommended that ID=40 records be turned off except
    for ad hoc enablement for specific problems, and since ID=40 SMF
    records have NEVER been used in BUILDPDB, the exposure here is that
    you reporting might think you missed an IPL because the record is
    output in the TYPE0 (a/k/a PDB.IPLS) dataset.  Pending a PTF, IBM
    also recommends turning off recording of ID=40s in your SMFPRMxx.

14. Specifying the RMF Monitor I CACHE Option in only one SYSTEM's RMF
    parameters eliminates redundant records on other systems and has
    been always recommended.  There are other RMF Monitor I options,
    ESS(RANK) and ESS(LINK) and FCD along with CACHE that should all be
    in one, and the same, SYSTEM, per these IBM suggestions:
      ESS(RANK) - Link performance statistics are gathered.
      ESS(LINK) - Extent pool statistics and rank statistics gathered.
                   As ESS data gathering involves cache activity
                   measurement, it is recommended to specify both
                   options in common.
                     If you specify ESS together with NOCACHE, cache
                     data is gathered implicitly without writing SMF
                     74.5 records!
                   In a SYSPLEX, options CACHE and ESS can be specified
                   on any system sharing the measured devices.
                   Therefore specify the ESS and CACHE options together
                   on one selected system only to avoid duplicate data
                   gathering.
      FCD       - FICON director activities are measured.
                   FICON directory activity is gathered by port address.
                   There is no indication which system in the sysplex
                   requested the I/O.  Therefore, the data can be
                   gathered on any system sharing the FICON directories.
                   To avoid having duplicate data, you should set the
                   FCD option on one system only.
      CACHE     - Create SMF 74.5 TYPE74CA Cache Statistics
                   IMPORTANT: CACHE is the DEFAULT option IBM sets in
                   RMF Monitor I, so you MUST then ADD a statement with
                   NOCACHE in RMF parms for all but that one SYSTEM.

13. APAR OA21982 reports SMF records with ID=0 and all other fields zero
    are actually SMF ID=40 records written from IEFDB4F9.  Disabling the
    ID=40 records in SMFPRMxx member of SYS1.PARMLIB will eliminate the
    bad records, and MXG does not use ID=40 records, as their EXCPs have
    long ago been added to the ID=30 records.

12. OA19058 corrected z/OS 1.7 problems with JES Initiators not
    executing (STARTING status for 40 minute).

11. ORACLE Version 10 SMF records contain invalid counts in the
    PHYREADS LOGWRITS and LOGREADS variables, but it appears that
    Oracle is not interested in correcting their errors.  While
    they have had BUG 5708760 open for seven months with no fix,
    that BUG references an earlier BUG 5702425 that appears to be
    marked "NOT FEASIBLE TO FIX".   If Oracle finally corrects
    these counts in their Accounting data, this technical note
    will be revised to cite their correction.
    March 2008 Update: Oracle 10.2.0.3 appears to correct I/O counts.
    SMF fix 6725982, 6138068, and 6646891 may all be required for both
    the I/O count fix and for Oracle on z/OS 1.9

10. APR PK42977 for Websphere documents how to enable SMF 120 record
    types in the administrative console.

 9. APAR OA21256 reports incorrect WLM calculation of CPU service
    units and zIIP service times; the problem is caused by a long
    running enclave, and impacts R723CCPU, R723CSUP, R723CRCP,
    MXG variables CPUUNITS, R723CSUP, and TRANS in TYPE72GO.

 8. APAR OA19440 corrects a bad value in the LCCAWTIM field, which is
    used to calculate the wait time then used to calculate LCPUPDTM
    (SMF30PDT). The occasionally-bad LCCAWTIM value caused extremely
    large values (10**13 or 10**14 seconds!) in LCPUPDTM and very small
    (10 millisec) in SMF70ONT.  The error was seen in SMF 70 records
    from BMC's CMF product, but the cause was the IBM error fixed by the
    PTF for the APAR, currently only available for z/OS 1.8.

 7. APAR OA18452 changes RMPTTOM to 300 and reduces uncaptured CPU time.
    This APAR was actually announced on MXG-L on 23March because MXG'ers
    were instrumental in identifying the problem for IBM to correct.
    The posting noted that the uncaptured CPU time now is primarily a
    function of the SRM Interval (influenced by RMPTTOM), the number of
    Address Spaces in the LPAR, and the number of LPARs in the CEC.

 6. APAR OA20028 corrects ABENDs in many IO routines that were
    introduced by OA10379 (MIDAW Support).

 5. APAR PK32855 (planned in Fix Pack 6.0.2.18 for Websphere Application
    Server V6.0.1) will remove CPU cost of SMF120CRE field when SMF 120
    records are not enabled.

 4. APAR OA20477 corrects error in CSA Leak due to Websphere 120 SMF
    records with z/OS 1.8 toleration PTFs installed.

 3. APAR OA17704 reports incorrect values for "Above 2GB" in RMF VSAM
    LRU Overview Buffer Counts by Pool, because SMF data was wrong.
    See also InfoApar II1419

 2. Under z/OS 1.7 and 1.8 a sequential library on DASD that is backed
    up via HBACKDS may potentially lose updates or be truncated, as
    documented in SAS Usage Note SN-019315.  Under z/OS V1R7 and V1R8,
    with every supported version of SAS (6.09 through 9.1.3), updates to
    an existing sequential access bound library on DASD can potentially
    be lost if the library data set is backed up via HBACKDS, migrated,
    and then subsequently recalled.  This situation occurs because SAS
    processes the library via the open mode INOUT, and the DS1IND08 bit
    is not turned on after the library has been updated.
    This problem involves an HSM feature known as fast subsequent
    migration.  In short, if you migrate a data set to tape (ML2),
    recall it, and then migrate it back, HSM normally creates a new tape
    copy.  Fast subsequent migration, if enabled, allows HSM to work a
    little smarter:  If the data set has not been modified between the
    recall and the subsequent migration request, the original tape copy
    can be considered valid again (it is marked as stale once the recall
    has been done).  However, this can result in the data set being
    back-leveled if the data set has really been changed.
    This problem does not exist for versions of z/OS prior to V1R7, nor
    does it exist for direct access bound libraries.

    To correct this problem, you need IBM PTFs UA32296 and UA32297.


 1.  APAR OA19943 is REQUIRED for all users of MXGTMNT/ASMTAPEE, the MXG
     Tape Mount Monitor, to be safe.  That APAR impacts any task that
     acts as an EMCS Console, and that's how MXG traps SYSLOG messages.
     but there is NOTHING that the task did wrong, but without the APAR,
     if the MXGTMNT task is not dispatched, the dispatcher will chain
     SRB's to the task's TCB until it becomes unmanageable, and a spin
     loop (i.e., 100% CPU Busy) occurs, without this maintenance.

     This problem was repeatedly experienced on day, and it took over
     seven hours and IBM's involvement to locate the culprit APAR.



IV.   DB2 Technical Notes.

 5.  APAR PK46171 corrects DB2 zIIP Accounting Field QLACCLS1_ZIIP in
     DB2ACCT, "TIME*EXECUTING*ON ZIP" values of 1250999:53 (hh:mm!),
     because DB2 was not initializing the field causing residual data.
     The bad values occurred only once, when Capacity did a WLM Policy
     Change.  This APAR cites QWACBJST and QWACEJST as being corrected.

 4.  The PAR.TASKS CPU TIME in DB2ACCT is NOT captured in CICSTRAN.
     The IBM DB2PM (now a/k/a DB2 Performance Expert) Accounting Long
     Report section "CP CPU TIME" is the total CP Engine CPU time for
     two subgroups, AGENT and PAR.TASKS, and AGENT has four subtotals
     for CPU time labeled NONNESTED, STORED PROC, UDF, and TRIGGER.
     This note maps the MXG variables/observations in the PDB.DB2ACCT
     dataset to those report CPU times, and, for DB2 calls from CICS,
     documents which DB2 CPU times are NOT captured in the TASCPUTM
     (IBM USRCPUT) in MXG's CICSTRAN dataset from ID=110 SMF records.

     That "Long" Report summarizes many DB2ACCT observations, perhaps
     for a PLAN, or AUTH, or ACE, and does not map to a single obs.

     The "AGENT" subgroup are all DB2ACCT records with DB2PARTY='S',
     the non-parallel workload.

     The "PAR.TASKS" subgroup are all DB2ACCT records with DB2PARTY of
     'P' (Parallel), 'R' (Rollup), or 'O' (Originator).

     DB2PM Report Example with annotation:

      CP CPU TIME   .024 Total CPU time on CP Engines  AGENT+PAR.TASKS
                         Part is in TASCPUTM.

       AGENT        .008 Allied Agent CPU Time         NONNESTED+STORED+
                         Part is in TASCPUTM.          UDF+TRIGGERS
                                                       sum of next five:

        NONNESTED   .008 CPU TIME ON ORIG THREAD       QWACEJST-QWACBJST
                         L8 or L8 TCB.
                         All NONNESTED is in TASCPUTM.

        STORED PROC .000 CPU time in Stored Procedure  QWACSPCP
                         They execute in a WLM ASID.
                         No QWACSPCP is in TASCPUTM.

        UDF         .000 CPU time for UDF              QWACUDCP
                         They execute in a WLM ASID.
                         No QWACUDCP is in TASCPUTM.

        TRIGGER     .000 Report prints the sum of
         TRIGGER-TT .000 Main Task Triggers            QWACTRTT
                         Is Included in EJST-BJST, so
                         QWACTRTT already in TASCPUTM.

         TRIGGER-TE .000 Nested Trigger Activity       QWACTRTE
                         Not Included in EJST-BJST
                         No QWACTRTE is in TASCPUTM.

       PAR.TASKS    .016 CPU in Parallel, Rollup       DB2TCBTM
                         or Originator Records
                         DB2PARTY DEFINITION               ACE
                           R      QWHCPARR='Y'             QWACPACE
                                  Child Task Rollup
                           P      QWACPACE GT 0            QWACPACE
                                  Child parallel/subtask
                           O      QXMAXDEG,QWACPCNT GT 0   QWHSACE
                           S      ELSE                     QWHSACE
                         (no PAR.TASKS is in CICSTRAN).


     Conclusions:

      -For both AGENT and PAR.TASKS, that is, for all DB2ACCT obs:

         DB2TCBTM=(QWACEJST-QWACBJST)+QWACSPCP+QWACUDCP+QWACTRTE;

       is total TCB CPU time recorded in that SMF 101 record.
       MXG Change 25.291 in MXG 25.25 added QWACUDCP to DB2TCBTM.

      -For AGENT records, that is DB2ACCT obs with (DB2PARTY='S') that
       are from CICS Attach (QWACATYP=4), the part of that DB2TCBTM that
       is NOT recorded in SMF 110 CICSTRAN variable TASCPUTM is:

         NOTINCICS= SUM(QWACSPCP,QWACUDCP,QWACTRTE);

      -But for PAR.TASKS records, DB2ACCT obs with DB2PARTY=O/P/R/ from
       CICS Attach, NONE of the total DB2TCBTM in that DB2ACCT obs is
       recorded in the SMF 110 CICSTRAN variable TASCPUTM.  Not in CICS:

         NOTINCICS=DB2TCBTM;
         NOTINCICS=SUM(QWACEJST-QWACBJST)+QWACSPCP+QWACUDCP+QWACTRTE;

     On IBM's report, if a group has non-zero QWACTRTT and QWACTRTE, the
     AGENT value should be smaller than the sum of its four components,
     because IBM includes QWACTRTT in their single TRIGGERS CPU time,
     but (presumably) do NOT include it in the sum as it's also already
     included in NESTED (EJST-BJST) CPU time.

     See Change 25.168 for the _RDB2ACC Diagnostic Report macro that may
     be useful for general examination of DB2 Parallel activity.

     Jan 2008: IBM'S APAR PK48816 documents that PAR.TASKS CPU time is
     not included in SMF 110 TASCPUTM (USRCPUT).


 3.  APAR PK23432 fixes DB2 GETPAGE counts in the range of 4 billion
     due to an incorrect subtraction, in DB2ACCT and DB2ACCTB data.

 2.  APAR PK37569 reports that COMMIT_COUNT, PARAL_SUBTASK_NUM and
     ROLLUP_PARAL_TASK (Tivoli names) are wrong when ACCUMAC option
     (to reduce the number of SMF 101 records written) is enabled.

 1.  APAR PK28561 alters what IBM writes in SMF 101 Subtype 1 IFCID 239
     records; previously all five segments were populated by default,
     but this APAR creates a new Accounting Class 10, and only if that
     class is enabled will all five segments be populated. Without class
     10 enabled, only the QPAC and QPKG segments will exist, and data
     from the QXPK, QBAC, and QTXA in DB2ACCTP dataset will be missing.


V.   IMS Technical Notes.

VI.  SAS Technical Notes.

10. Error Unrecognized SAS option name, GUIDE  CONFIGURATION ... were
    caused by the CONFIG DD for SAS V9 execution pointing to an old
    (BATCH) member rather than the correct (BATWO) member.

 9. Two examples that will create a Comma Separated Variable (?) CSV
    flat file from a SAS dataset:

      Example 1:

        ODS CSVALL BODY='some file';
          PROC PRINT or TABULATE or whatever
          RUN;
        ODS CSVALL CLOSE;

       Example 22:

        DATA _NULL_;
         SET dataset;
         FILE 'some file' DLM=',';
         PUT var1 var2 var3 var4 var5...;


 8. RECORD FORMATS ARE DIFFERENT error occurred with part of a MONTHly
    PDB was written to TAPETEMP with SEQENGINE=V9SEQ, but the program
    then changed to specify SEQENGINE=V6SEQ, which cause the error.

 7. If you get RC=4 or other non-zero Return Codes on z/OS in SAS V9,
    you can insert this statement before and after a section of code
         %PUT SYSCC IS &SYSCC;
    to print the current value of the return code, and can see when
    the value is changed in your code.  In SAS Version 9, WARNINGs set
    RC=4, but under SAS Version 8, that was not always true.

 6. The UTILEXCL utility fails if you have the PROC SYNCSORT add-on
    product,  with a WER723A or other WER7xxa error message.  This is
    NOT the SYNCSORT Sorting product, but occurs with the PROC SYNCSORT
    add-on that you purchased that is supposed to speed up SAS sorts.
    The problem is that the UTILEXCL utility has a very long BY list,
    and this causes the PROC SYNCSORT failure.  You MUST remove the
    PROC SYNCSORT Load Library from your //STEPLIB DD to run UTILEXCL.
    Even when you remove the Load Library for PROC SYNCSORT, the normal
    SYNCSORT sort won't be used, because SAS will recognize the long
    by list and won't call the HOST sort program (telling you so on the
    SAS log).  Setting  OPTIONS SORTPGM=SAS; won't work until you remove
    the PROC SYNCSORT Load Library from //STEPLIB DD for this job.
    The by list in UTILEXCL is longer than the 4096 byte Syncsort limit;
    the existence of the PROC SYNCSORT loadlib prevents SAS from getting
    control to switch to its own sort, that has no such limitation.
    The example in ANALDUPE also fails if PROC SYNCSORT is installed.

 5. SAS Note SN-V9-017038 reports that SAS V9.1.3 with Service Pack 4
    and with that Hot Fix can use DSNTYPE=LARGE datasets under z/OS 1.7
    and later for bound SAS data libraries on disk.

    DSNTYPE=LARGE z/OS datasets can occupy more than 64K tracks on a
    single volume, so those datasets can fill all available tracks on
    the largest volumes (54GB) that are currently available, reducing
    the number of volumes for large SAS data libraries.

    To create a "direct access bound library that resides in a DSNTYPE=
    LARGE data set", you must externally allocate the library data set
    with the DSNTYPE=LARGE parameter:

      // EXEC MXGSASV9
      //LARGEDB DD DSN=YOUR.DSNTYPE.LARGE,DISP=(,CATLG),UNIT=SYSDA,
      //           SPACE=(CYL,(5000,5000)),DSNTYPE=LARGE


    Nov 7, 2007 update:  Prior to z/OS 1.7, there was an IBM limit of
    64K tracks when the I/O access method was EXCP, but IBM removed that
    limit in 1.7, and the SAS Hot Fix above revised SAS EXCP code so the
    DSNTYPE=LARGE can be fully exploited.

 4. Some z/OS memory errors (ONLY reported in SYSLOG, not in SAS log!)
    were caused by incorrect default OPTION values; setting these values
        MEMLEAVE=10M
    in the CONFIGV9 member and executing with
        REGION=256M
    eliminated those errors, which surfaced only in UTILEXCL with a
    massive PDB.CICSDICT dataset as input.

 3. IBM APAR PQ38655 is required if you are using IBM's OS/390 ftp
    server with the SAS ftp Access method to ftp data from tape.

 2. MXG 25.02's BUILDPDB has been successfully executed with SAS 9.1.3
    on Windows Vista Home Premium Edition, on Windows Vista Enterprise,
    and on Windows Vista Enterprise running on Microsoft Virtual PC,
    with no errors nor any unexpected warnings.

    However, this is NOT a guarantee of safety, since SAS Institute's
    official statement in October 2007, in SN-020430, for SAS 9.1.3 is:
          ( http://support.sas.com/techsup/unotes/SN/020/020430.html )
      I. Which Microsoft Windows Vista(TM) operating systems does SAS
         9.1.3 support?
         * SAS supports the following Windows Vista(TM) 32-bit editions:
           - Enterprise
           - Business
           - Ultimate
         * SAS does NOT support Windows Vista(TM) 32-bit Home Editions:
           - Premium
           - Basic
         * SAS does NOT support Windows Vista(TM) 64-bit editions.

    SAS has officially announced that VISTA wouldn't be fully supported
    until SAS 9.2, which is not expected until late 2007 or early 2008.

    Comparing runs on a 2.4GHz Vista with a 2.8GHz XP, with same memory
    but unknown disk differences is not a valid point in benchmark-space
    but comfortable:  2:05 vs 2:19 run time, 1:42 vs 1:24 User CPU time.


 1. ABEND EC6 when running an MXG job processing a lot of DB2 SMF data,
    is actually a SYSTEM 322 CPU TIME EXCEEDED condition, that just
    happened to occur in z/OS Unix System Services; there was also
       BPXP013I THREAD ... WAS TERMINATED DUE TO CPU TIME OUT.


VI.A WPS Technical Notes.

 1. World Programming System, WPS, a product of World Programming, in
    their words, "an alternative to SAS", has been installed on both
    z/OS and Windows platforms, and Merrill Consultants has run tests
    under two Beta versions of WPS Software.  WPS has already replicated
    most of the SAS language functions that are required for execution
    of most of MXG Software, and there are several MXG sites that run
    their production MXG jobs under WPS Beta's on z/OS quite happily,

    While much of MXG does execute under WPS Beta Version 2.0.8, there
    are still significant errors to be resolved by WPC before I can
    complete the execution of my suite of "SAS Clone" tests, and thus
    I don't think it is worth your while to examine the WPS product for
    MXG execution until those critical issues have been delivered so
    that WPS can be fully evaluated.  The current status is:

    - MXG Version 25.07 contains the initial minor changes required for
      transparent MXG execution under SAS or WPS, and the new AUTOEXEW
      for ASCII WPS autoexec.sas, and the new CONFIGW2 and MXGWPSV2 JCL
      procedure example for MXG execution under WPS Version 2.0.8.


    - "Compiler" tests compile the MXG code, and then execute that code,
      to output all datasets with all variables and their attributes
      defined, so the output structures can be compared, log messages
      be examined.  DUMMY input files are used, so all output datasets
      have zero observations.

    - "Execution" tests compile and execute with actual input data files
      and output dataset's variables are populated with values and obs.

    - On both Windows and z/OS platforms, almost all of the simple,
      straightforward MXG programs that contain a single DATA step and
      read an input file do execute without error under WPS, and appear
      to produce compatible output datasets.

    - A number of other, complicated, MXG programs that do execute under
      Windows currently ABENDing under z/OS, notably BUILDPDB and the
      DB2 processing TYPSDB2 programs.
        However, BUILDPDB did execute successfully in prior tests on
        z/OS, so I expect this z/OS-only problem to be resolved soon.

    - Almost all of the MXG QA compiler test steps on Windows are now
      successful.  All variable's attributes (LENGTH,FORMAT,LABEL) in
      all MXG datasets can be compared between WPS and SAS compilers.
       Many datasets and variables do match perfectly, but we found some
       WPS code that did not replicate SAS's handling of attributes.
       When corrected by WPC, this phase of the validation be completed.

    - Almost all of the MXG QA execution tests on Windows with real data
      do execute successfully, but I have not yet done ANY comparison
      of the accuracy of the data values of WPS vs SAS data libraries.

    - Many of the MXG QA compiler tests on z/OS do execute, but there
      are ABENDS in critical SMF-processing steps that are under also
      investigation and must be resolved before that the first phase
      of z/OS validation can be completed.

    - Until the critical z/OS compiler tests are successful, we cannot
      run second phase, execution tests, on z/OS for that validation.

    - And there are still several both-platform critical problems (all
      in progress of repair) that prevent us from continuing testing of
      MXG under WPS.  Based on their past response, I expect corrections
      soon, and likely to be measured in a-few-weeks to a-month-or-so,
      before they have successfully corrected all of the errors that MXG
      has exposed in this third iteration of WPS QA tests.

    - I have not started the third phase, comparing the accuracy of the
      data values in the created output datasets with good and bad input
      data on either platform.

    - I have not started the fourth phase, comparing the execution time
      and resource requirements (CPU, Memory, I/O, Disk space) on either
      platform.  However, compile run times on Windows are similar.

    - I am aware that there are a few MXG sites that have been actually
      running their tailored MXG production jobs under WPS, even under
      earlier WPS beta's.  But my job is to evaluate WPS to validate if
      all of MXG runs with their product correctly, or to at least then
      identify what does, and what doesn't work!

    - Upon successful completion of all four phases of my validation on
      both z/OS and Windows platforms, I will revisit my original
      "SAS Clone" newsletter article with specific updates with regard
      to how well WPS meets my criteria.

    - I'd also like to formally state the business relationship between
      Merrill Consultants and World Programming Company: WPC licenses
      MXG Software for its software development, testing, and support,
      and Merrill Consultants licenses WPC for its testing.  Both of the
      company's technicians cooperate on problem resolution.
      August 10, 2007.


VII. CICS Technical Notes.



VIII. Windows NT Technical Notes.


IX.  z/VM Technical Notes.

 1. Adding PAVs to the z/VM configuration caused messaged on zVM:
      FCXPMN446E Incomplete monitor data: DCSS size too small
    when the IBM performance tool kit processed the MONWRITE data.
    The MONWRITE file did NOT have a 1.9 MTRxxx record written at
    startup, causing INTERVAL and HFRATE to be missing in VXBYUSR.
    Increasing the sample and event storage sizes in the DCSS, the
    MONWRITE data was valid.

X.    Incompatibilities and Installation of MXG vv.yy.

 1. Incompatibilities introduced in MXG 25.yy (since MXG 24.24):
    See CHANGES.

 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 JCLINST9 for
    SAS V9.1.3 or JCLINS8 for SAS V8.2.

XI.   Online Documentation of MXG Software.

    MXG Documentation is now described in member DOCUMENT.


XII.  Changes Log

--------------------------Changes Log---------------------------------

 You MUST read each Change description to determine if a Change will
 impact your site. All changes have been made in this MXG Library.

 Member CHANGES always identifies the actual version and release of
 MXG Software that is contained in that library.

 The CHANGES selection on our homepage at http://www.MXG.com
 is always the most current information on MXG Software status,
 and is frequently updated.

 Important changes are also posted to the MXG-L ListServer, which is
 also described by a selection on the homepage.  Please subscribe.

 The actual code implementation of some changes in MXG SOURCLIB may be
 different than described in the change text (which might have printed
 only the critical part of the correction that need be made by users).

 Scan each source member named in any impacting change for any comments
 at the beginning of the member for additional documentation, since the
 documentation of new datasets, variables, validation status, and notes,
 are often found in comments in the source members.

Alphabetical list of important changes after MXG 24.24 now in MXG 25.01:

  Dataset/
  Member   Change    Description

  See Member CHANGES or CHANGESS in your MXG Source Library, or
  on the homepage www.mxg.com.

Inverse chronological list of all Changes:

Changes 25.yyy thru 25.001 are contained in member CHANGES.

*********************NEWSLETTER FORTY-NINE******************************




       MXG NEWSLETTER NUMBER FORTY-NINE, February  5, 2007.

Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE

                         TABLE OF CONTENTS

I.    MXG Software Version.
II.   MXG Technical Notes
III.  MVS Technical Notes
IV.   DB2 Technical Notes.
V.    IMS Technical Notes.
VI.   SAS Technical Notes.
VII.  CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX    z/VM Technical Notes.
X.    Incompatibilities and Installation of MXG.
         See member CHANGES and member INSTALL.
XI.   Online Documentation of MXG Software.
         See member DOCUMENT.
XII. Changes Log
     Alphabetical list of important changes
     Highlights of Changes  - See Member CHANGES.

     COPYRIGHT (C) 2005 MERRILL CONSULTANTS DALLAS TEXAS USA

I.  The 2007 Annual Version MXG 24.24 was dated February 5, 2007.
    All sites were mailed a letter with the ftp download instructions.
    The availability announcement was posted to both MXG-L and ITSV-L.
    You can always request the current version using the form at
     http://www.mxg.com/ship_current_version.

 1. The current version is MXG 24.24, dated Feb  5, 2007.

    See CHANGES member of MXG Source, or http://www.mxg.com/changes.

II.  MXG Technical Notes

 2. Comparison of TRSMAIN and ZIP compression techniques.

    We create both Windows Zipped and z/OS Tersed distribution files for
    MXG Software, which is a single sequential pure text file, currently
    2,119,181 lines of text; the lines are FB 80 on z/OS, but are not
    numbered, so the file is smaller as a variable-length ASCII file.

    Our current version's stored sizes are:

      Size of FB 80 EBCDIC file, z/OS     169,534,800 bytes
      Size of PC ASCII variable length    104,353,987 bytes

      Zipped PC file                       17,589,006 bytes
      Tersed  FB 80                        21,653,504 bytes

      Terse reduced the z/OS file by a factor of 7.82.
      Zip reduced the ASCII file by a factor of  5.93.

      But, the 8-bit z/OS file is 62% larger than the ASCII file; not
      only is there the 8-bit EBDCIC vs 7-bit ASCII, but the ASCII
      file  lines are the actual length of text, while each line of
      the z/OS  file is 80 bytes long.

      But the 169:21 reduction, almost 8:1 reduction of the 80-byte
      EBCDIC  text to its TERSEd equivalent is very consistent with my
      experience  with not only text files, but also z/OS customer's SMF
      data files.


 1. We consistently see that if you are executing MXG on ASCII, using
    the SAS ftp access method to directly process the raw data with MXG
    is always faster than using ftp to copy the raw data to the local
    machine, and then reading that local file with MXG.
    This recent comparison with 1.93 GB of z/VM MONWRITE data showed:
      ftp download (7m50s) + TYPEVMXA (7m38s) =  15m 28s  = 928 sec
      ftp access method direct with TYPEVMXA  =  12m 41s  = 761 sec
    which is 17% faster. 26Aor2006


III. MVS Technical Notes.

48. BMC's Mainview GUI can have a CPU Loop in program BBW9IC00 that is
    corrected by their APARs BPY9689 and BPY9610.

47. APAR OA23161 reports RMF Monitor I, II, and III stop recording data
    on a device after a dynamic activate of an I/O configuration that
    removed a sysplex LPAR from the device candidate list.  The device
    is still available to other sysplex systems, but the device is
    missing in all of the RMF Monitor records on other sysplex systems.

46. APAR PK56492 reports massive numbers of SMF 92 subtype 10 or 11
    records (for OPEN/CLOSE directories under /var/ibm/tivoli..).

45. APAR OA22492 reports IFASMFDL, the "IFASMFDP SMF Dump Program" when
    SMF is recorded to a Logstream, will stop processing other Logstream
    datasets when an empty logstream is encountered.

44. APAR OA22791 reports an ABEND 0C1 when Restarting SMF, but with no
    fix, and with "the only negative impact being that the user
    issuing the request for an SMF service will receive control back
    with R15=16 ('10'x) and with the service not performed (e.g., if
    the request was to write an SMF record, that record will NOT be
    written.  IN OTHER WORDS, A LOST SMF RECORD IS NOT AN ERROR TO IBM!
    Fortunately, the probability of the condition is very low.

43. APAR OA22768 corrects ABEND 30A-014 when switching back from SMF
    Logstream Recording to Dataset Recording.

42. Information APAR II14219 has extensive "support use" information for
    DB2 z/OS zIIP exploitation.

41. APAR OA19618 corrects R723CIOC (IOUNITS) very large values.

40. APAR OA19231 reports incorrect CU type in RMF; moving DASD to a Z9
    showed the incorrect 3990-6 when it should have been a 3105.

39. APAR OA19546 corrects RMF III CPUG3 zero offset while data is there.

38. APAR PK35466 corrects SMF 116 MQ Client data WSTIDCHL and WTIDCHLC.

37. APAR PK36010 corrects SMF 14, 15 records; missing close events in
    the IMS Audit Management Expert reporting.

36. APAR PK37355 corrects MAXQDPTH in SMF 116 statistics records, which
    was not being reset across SMF intervals for long running tasks.

35. APAR PK37848 fixes several problems in SMF 119 records for FTP.

34. APAR PK29870 corrects SMF 16 CPU time of 24 hours, which occurs when
    DFSORT is called from a program that uses dynamic allocation, due to
    yet another conflict when two tasks (DFSORT, DYNALOC) both issue
    STIMER.

33. APAR PK32855 eliminates excess CPU time in WebSphere even when SMF
    120 records are disabled.

32. APAR OA19739 corrects report output from IFASMFDP for a site that
    dumped an entire year's SMF data; the total record count should have
    been 1,300,202,341, but the report truncated the leading digit so it
    showed only 300,202,341.  DUMPED AN ENTIRE YEAR's SMF?????

31. zIIP CPU Time Comparisons between TYPE72GO and TYPE30_V.

  A. The zIIP CPU times in the RMF Type 72 Service Class/Reporting Class
     are compared with zIIP CPU times in SMF Type 30 Interval Record.

    Total zIIP times match very well, between SMF and RMF, and between
    Service Class and Reporting Classes.  The totals for Service Classes
    match totals for Reporting Classes, and many service classes match
    both their reporting class data in TYPE72GO and their address space
    data in TYPE30_V/SMFINTRV.
    But: MANY Service Class pairs do NOT match up, because the Service
         Class of the address space can be different than the service
         class of the classified transaction, and because of where the
         resources are recorded in cross-memory transactions.
         There is no error here, just different recording techniques.

    Original example:


                         C72ZIPTM    C72ZIETM    C30ZIPTM    C30ZIETM
    Reporting Classes     8508.93      725.89     8609.19      742.41
    Service Classes       8508.93      725.89     8609.19      742.41

    Comparison of SMF 30 and TYPE 72 ZIP CPU measurements

    Report 1 - MATCHED Service/Reporting Classes

    Some Service Classes/Reporting Classes entries match almost exactly
    between their type 72 and type 30 data.  Horizontally, you can see
    the match between the 72 and 30 data for each class.  In groups,
    you can see that the Service Class and Reporting  Class totals match
    exactly.  And you can see that two of the Service  Classes (BATWGWK
    and BATWLO match exactly their corresponding Reporting  Classes
    (RTNGGWK and RTCGPG4), but the other four don't pair exactly.

           MATCHED ZIP TIMES - TYPE72GO COMPARED WITH TYPE30 INTERVAL

       --------------------- SERVICE CLASSES --------------------------

       SRVCLASS  C72ZIPTM   C72ZIETM   C30ZIPTM   C30ZIETM    PCT30MORE

       BATWGWK       9.74       0.10       9.85       0.10     101.193
       BATWHI     1224.36      62.27    1257.39      66.16     102.870
       BATWHIP       8.57       0.14       8.62       0.15     100.628
       BATWLO      151.46       2.49     153.52       2.63     101.425
       BATWMD     7106.10     660.39    7171.03     672.87     100.997
       BATWMDP       8.71       0.50       8.78       0.50     100.854
                 --------   --------   --------   --------
                  8508.93     725.89    8609.19     742.41

       -------------------- REPORTING CLASSES -------------------------

       RPTCLASS  C72ZIPTM   C72ZIETM   C30ZIPTM   C30ZIETM    PCT30MORE

       RTCGPG2    7502.62     691.14    7582.38     706.20     101.157
       RTCGPG3     151.46       2.49     153.52       2.63     101.425
       RTCGPG4     813.72      31.29     831.67      32.60     102.279
       RTNGGWK       9.74       0.10       9.85       0.10     101.193
       RTNGHRJ      18.33       0.69      18.63       0.70     101.602
       RTNGPG5      13.06       0.18      13.14       0.18     100.605
                 --------   --------   --------   --------
                  8508.93     725.89    8609.19     742.41
                 ========   ========   ========   ========
                 17017.86    1451.79   17218.38    1484.82


     Report 2 - UNMATCHED Service/Reporting Classes

     The DB2 Service and Reporting Classes DDF and RDDF are for Enclaves
     that do not have an SMF 30 address space, but their CPU times are
     included in the address space record for DB2PRD Service Class,  and
     the address space record for RDP1DIST/RDP2DIST Reporting Class.


         ---------------SERVICE CLASSES -------------------------

         SRVCLASS    C72ZIPTM    C72ZIETM    C30ZIPTM    C30ZIETM

         DB2PRD          0.80        0.00     5623.12      354.17
         DDFPRDET     2754.39      141.25         .           .
         DDFPRDLA        0.03        0.00         .           .
         DDFPRDLO     2676.61      187.98         .           .
         DDFPRDMD       80.15       11.14         .           .
         DDFPSAGT        0.52        0.07         .           .
         DDFPSSQP        5.06        0.29         .           .
                     --------    --------    --------    --------
                      5517.56      340.73     5623.12      354.17


         --------------REPORTING CLASSES ------------------------

         RPTCLASS    C72ZIPTM    C72ZIETM    C30ZIPTM    C30ZIETM

         RDDFDEF      2676.61      187.98         .           .
         RDDFPRDM       80.15       11.14         .           .
         RDDFPRDX        0.03        0.00         .           .
         RDDFTA       2754.39      141.25         .           .
         RDDRAPS         0.52        0.07         .           .
         RDDRCON         5.06        0.29         .           .
         RDP1DIST        0.26        0.00     2806.69      206.08
         RDP2DIST        0.53        0.00     2816.43      148.09
                     --------    --------    --------    --------
                      5517.56      340.73     5623.12      354.17
                     ========    ========    ========    ========
                     11035.12      681.46    11246.24      708.34


    Newer example. Report produced by ANALZIPC Zip CPU analysis program:

                     R72   R72   R30   R30    R30    R72   R30   R72
                     ZIP   ZIE   ZIP   ZIE    TCB    TCB   SRB   SRB
        SRVCLASS:
          BATDEVHI     0     0     0     0      1      1     0     0
          BATDEVMD     0     0     0     0   2907   3417    50    56
          BATPRDHI     0     0     0     0    791      3     1     0
          BATPRDLO     0     0     0     0   7463   7484    87    82
          BATPRDMD     0     7     0    13  25230  20798  1580  1506
          CICPRDHI     0     0     0     0  61519  61534   970   971
          CICPRDR1     0     0                         0           0
          CICPRDR2     0     0                         0           0
          CICPRDR3     0     0                         0           0
          DDFHI      281  3571                     11624           0
          DDFHOT      77  1774                      5671           0
          DDFLO     1363  2606                      6889           0
          DDFMD       33   611                      2338           0
          OMVSBAT      0     0     0     0     71     59     8     7
          ONLPRDLO     0     0     0     0     30     30     6     6
          STCHI        2     0  1763  8631  33147   6290  6791  6793
          STCLO        0     0     0     0   4452   4458   455   455
          STCMD        0     0     0     0   2307   2649    95    96
          SYSOTHER     0     0                         0           0
          SYSSTC       0     0     0     0   3177   3202  3170  3171
          SYSTEM       0     0     0     0   2056   2910  5205  5562
          TSOPRDMD     0     0     0     0   4880   5108    65    61
                    ----  ----  ----  ---- ------ ------ ----- -----
                    1757  8572  1763  8645 148038 144471 18491 18771

    B.  This note revised March, 2008, then numbers were added to the
        schematic in Oct 2011.


    Details:

       Variables and schematic of zip CPU times recorded in SMF 30

      These are the MXG field names and descriptions of the zIIP
      variables data created from the SMF type 30 records:

        ZIP   CPUZIPTM      /*SMF30_TIME_ON_ZIIP*/
        DZI   CPUDZITM      /*SMF30_DEP_ENCLAVE_TIME_ON_ZIIP*/
        EZI   CPUEZITM      /*SMF30_IND_ENCLAVE_TIME_ON_ZIIP*/

        ZIE   CPUZIETM      /*SMF30_ELIGIBLE*TIME_ZIIP_ON_CP*/
        DZE   CPUDZETM      /*SMF30_DEP_ENCLAVE_TIME_ZIIP_ON_CP*/
        EZE   CPUEZETM      /*SMF30_IND_ENCLAVE_TIME_ZIIP_ON_CP*/

        EZQ   CPUEZQTM      /*SMF30_IND_ENCLAVE_TIME_ZIIP_QUAL*/
        DZQ   CPUDZQTM      /*SMF30_DEP_ENCLAVE_TIME_ZIIP_QUAL*/


         CPU TIME ON ZIIP ENGINES            CPU TIME ON CP ENGINES
                "Actual"                           "Eligible"
    ------------CPUZIPTM------------   ------------CPUZIETM------------
                855,964                              2,491
    -UNCAPTUR---CPUDZITM---CPUEZITM-   -UNCAPTUR---CPUDZETM---CPUEZETM-
                 (DEP)      (IND)                   (DEP)      (IND)
       4,224     64,875    786,905           24        863      1,604

     "QUALIFIED DEPENDENT ENCLAVES"    "QUALIFIED INDEPENDENT ENCLAVES"
     (Sum of DEP Actual and Eligible)  (SUM of IND Actual & Eligible)
     (Includes ZIP and CPU TIMES)      (Includes ZIP and CPU TIMES)
                "Actual"                           "Eligible"
    ------------CPUDZQTM------------   ------------CPUEZQTM------------
                 73,784                          1,420,409
    -UNCAPTUR---CPUDZITM---CPUDZITM-   -UNCAPTUR---CPUEZITM---CPUEZETM-
                 (DEP)      (IND)                   (DEP)      (IND)
          53     64,875        862      662,000    756,805      1,604

    ----IND-PLUS-DEPN-CP---
           663,984
    --CPUENCTM---CPUDETTM--
       (IND)      (DEP)
      652,655     11,329

    The "Independent Enclave zIIP Qualified" time ("EZQ")=1,142,409 is
    greater than the SUM of the "Independent Enclave CPU Time on zIIP"
    ("EZI")=756,805 plus the "Zip-Eligible Independent Enclave CPU Time
    on CP" ("EZE")=1,604, by about 662,000 seconds, which happens to be
    (coincidentally?) very close to the 663,984 sum of the "ENCLAVE CPU
    TIME" ("ENC")=652,655 plus the "DEPENDENT ENCLAVE CPU TIME" ("DET")
    of 11,329 seconds.

30. The VTF Mainframe (CopyCross) V2.1.0 product requires PTF BV00340 if
    you want to ftp data from a tape device with that product installed.

29. APAR OA19453 reports SMF7NRO (MXG variable LOSTRECS) could be wrong
    if the value is over 64K.

28. Very obscure condition, but if you had different values for the TCB
    CPUCOEFF than the SRB SRBCOEFF, APAR OA19462 corrects an error; the
    CPUCOEFF, instead of the SRBCOEFF, was used to calculate SRBUNITS,
    but only in JBB77S9, HBB7772S and HBB7730 levels of z/OS.

27. APAR OA19852 corrects the invalid CPURCTTM, NEGATIVE SERVICE UNITS,
    etc that were introduced by OA19257, which had PE APAR OA19282 prior
    to the final correction in OA19852, the PTF for which, has now been
    validated by MXG users.  Text of this change revised 27Feb2007.

    OA19257 corrects slight imprecision in calculation of CPU and SRB
    Service Units in SRM code that was discarding the remainder of the
    division, which could have caused values to be too small; with this
    APAR, more CPU time is captured due to the higher precision.
    These IBM fields could have been too small
     SMF30CSU SMF30SRB R723CCPU R723CSRB RQSVCPU RQSVSRB RCAECPU RCAESRB
    They become these MXG variables in these datasets:
        Dataset TYPE72GO, RMFINTRV, TRNDRMFI:
          CPUUNITS and SRBUNITS
          CPUTCBTM, CPUSRBTM, CPUTM
        Datasets TYPE30_V,TYPE30_4,TYPE30_5,SMFINTRV,JOBS,STEPS
          CPUUNITS and SRBUNITS
          SRVTCBTM, SRVSRBTM, TOTCPUTM
    But note that the variables CPUTCBTM, CPUSRBTM, and CPUTM in the
        datasets TYPE30_V,TYPE30_4,TYPE30_5,SMFINTRV,JOBS,STEPS
    are NOT impacted by this APAR, as they are NOT service-unit-based.

26. From an IBM-Main posting as to the contents of Unix Systems Services
    Process Identifiers (PIDs):  The right two bytes are sequential,
    similar to the customary unix PID. The leftmost byte is an attempt
    to insure long-term uniqueness.  The remaining second from left byte
    is reserved for sysplex use; here are some data examples:
         PID in decimal      PID in hex
           83886667         '0500024B'x
                590         '0000024E'x
           16777806         '0100024E'x
                589         '0000024D'x
           83886673         '05000251'x

25. APARs OA12857, OA12858, and OA12861 are required to populate the
    PDSE cache statistics in the SMF 14 and 15 records.

24. APAR OA17891 corrects SMF 89 fields SMF89UCT, SMF89USR, and SMF 30
    fields SMF30UCT, SMF30UCS; these are MXG variables PRODTCB and
    PRODSRB in TYPE30MU (Measured Usage) and TYPE89 datasets.
    No change was required in MXG code as these were value corrections.
    However, APAR OA19852 is needed to correct errors in OA17891 that
    impacted the SMF30UCT and SMF89UCT Usage Segment CPU times, as well
    as correcting yet another error in the CPURCTTM.

23. APAR PK32078 reports incorrect Websphere CPU time if servlets have
    names greater than 128 characters.

22. APAR PK32519 corrects the counts in variable TSIPDSCA which were
    incorrectly being included in variable TSIPDSCO.

21. APAR OA14282 reports WLM data fields were missing in JES2 SMF 26
    record, if the JOB had no accounting fields; now corrected so
    WLM data fields do not depend on the existence of ACCOUNTn data.

20. APAR OA12079 reports JES3 SMF 26 SMF26NAM and SMF26MSG can be
    incorrect in purge record for output received back from a JES3
    node and processed on a JES3 system.

19. APAR OA17663 reports SMF type 30 subtype 2 records can stop being
    written for an address space that takes an ABEND553 (rc4,rc8,rcC)
    unless the OPERATOR takes the appropriate corrective action that is
    described in the APAR text.

18. APAR OA15461 corrects RMF STARTIME to include "Leap Seconds", the
    (currently) 23 second addition to TAI (International Atomic Time)
    (old "GMT") that creates UTC (Coordinated Universal Time).  Leap
    seconds were added to SMFINTRV INTBTIME long ago by OW43279.
    There is a circumvention in the APAR:  If you use SYNC(RMF,xx)
    option in RMF, with xx=00-59, leap seconds ARE considered to
    trigger a new RMFINTRV.  However, if you instead use SMF interval
    synchronization (SYNC(SMF)), SMF signals a new interval and that
    time did NOT include leap seconds, so records requested for 15 min
    intervals were written at 11:14:37, 11:29:37, etc, prior to this
    APAR.

17. Humor.  A discussion of comments in IBM programs reminded me of this
    from an OS/360 ASM program before code that Branched to ABEND:
     "Self-defenestration is preferable to omphaloskepsis."

16. APAR OA17615 reports WLM managed PAV devices may not have an alias
    moved (when it should have been), if the device had EVER held a
    RESERVE in the past; the PTF switches off the RESERVE bit when there
    is no RESERVE indication in the UCB.

15. APAR OA17732 reports very high CPU in RMF address space after an
    address space failed in memory termination, but due to damaged
    data within the ASID, the memterm processing also failed, which
    caused RMF to internally ABEND every scan of this ASID, which was
    occurring every 10 seconds, resulting in an IPL being required.

14. APAR PK25614 reports SMF 116 records show wrong Buffer Pool and
    Pageset Numbers (MQINQ,MQSET).

13. APAR OA17374 reports HiperBatch stats SMF64HIT,SMF64MIS,SMF64WIS
    are all zeros when DLF is setup to read COFXIT00 with VSAM entries
    that comply with HiperBatch eligibility rules.

12. APAR OA16949 reports RMF 74 subtype 5 and 8 records may not be
    written after an IPL, when 2105, 2107, or 1750 device types are
    being configured as 2105s.

11. APAR OA14652 reports loss of type 30 interval records for some tasks
    only after APAR OA08702 was installed, and the SYNC SMF option was
    in effect.  NDM  records were the first noted to be not written.

10. MIDAW, IBM's Modify Indirect Addressing Word facility, has no impact
    on MXG Software. MIDAW is a new facility for indirect addressing for
    FICON Express2 feature on z9-109s, and may reduce channel, director,
    and control unit overhead.

 9. Measuring SMSVSAM to recognize potential bottlenecks.
    This note is an EDITed extract from IBM Item RTA000175395:

    In addition to processor resources, memory, and access to I/O
    devices SMSVSAM has its own resources that should be monitored to
    recognize potential bottlenecks that may be developing. The primary
    SMSVSAM resources are:

    a. SMSVSAM data space which contains the RLS buffer pool.
    b. SMSVSAM cache structures in the coupling facility.
    c. SMSVSAM lock structure in the coupling facility.
    d. SHCDS data sets.

    a. SMSVSAM data space which contains the RLS buffer pool.

       Historical:

       SMF Type 42 Subtype 19 records are for VSAM RLS Local Buffer
         Manager LRU Statistics Summary.  This data includes information
         information for each system and a sysplex-wide summary.

         Fields of interest are:
          SMF42JOO Total Buffer size goal (in megabytes) - Low value.
          SMF42JOP Average Buffer size goal (in megabytes) - high value
          SMF42JOQ Total Buffer size goal (in megabytes) - high value.
          SMF42JNI Average number of Buffer Manager LRU where BMF was
                   over the goal, and normal algorithms were bypassed to
                   reclaim buffers.
          SMF42JNL Total number of times that BMF was called in interval
                   (across sysplex).
          SMF42JUA Average number of buffer manager LRU processed, where
                   BMF was over the goal accelerated the aging, but did
                   not go into panic mode (the sysplex).
       Real Time:

       RMF Mon III can be used to see the current status of the buffer
       pool.  From the RMF Sysplex Report Selection Menu, you could
       select option 10, VSAM RLS activity by storage class, to see what
       the current health status of the buffer pool. It will report: LRU
       status of local buffers under control of BMF (Buffer Management
       Facility).

        Good           BMF is at or below its goal on all systems.
        Accelerated    BMF is over the goal on at least one system, and
                       the buffer aging algorithms were accelerated.
        Reclaimed      BMF is over the goal on at least one system, and
                       the buffer aging algorithms were bypassed to
                       reclaim buffers.

       In addition to the buffer information, lock contention is
       displayed along with data rates and hit percentages for BMF, CF,
       and DASD.

    b. SMSVSAM Cache Structures in the Coupling Facility.
       The initial and maximum size of the cache structures are defined
       in a policy stored in the CFRM data set. There is historical data
       and real time data available.

       Historical:
       The RMF Coupling Facility Usage Summary and Coupling Facility
       Structure Activity Post Processor report has performance data
       concerning the RLS cache structures.  In the Coupling Facility
       Usage Report, there is a column for directory reclaims and
       directory reclaims for buffer invalidations (XI). What want to
       avoid are directory reclaims and directory reclaims for buffer
       invalidation. There should be no directory reclaims for buffer
       invalidation and preferably no directory reclaims at all. Seeing
       reclaims is an indication that the cache structure is not large
       enough.  To find whether or not there are any false buffer
       invalidations, SMF record type 42 subtype 16 field SMF42GCK can
       be used. There should be no false invalidations.

       In the Coupling Facility Structure Activity report, there is data
       concerning the number of synchronous requests, asynchronous
       requests, and how many synchronous requests were converted to
       asynchronous for each structure. One should also look at the
       number of synchronous requests that have been converted to
       asynchronous.  Conversion could be done because the host is
       sending so many requests to the CF and the CF doesn't have the
       capacity to handle them or more or faster links are required.
       This report also has data concerning delays and the cause of
       these delays.  There are also SMF Type 42 Subtype 18 records that
       contain data for CF cache usage.

       Real Time:
       To obtain data concerning the number of synchronous,
       asynchronous, and the number of synchronous requests changed to
       asynchronous can be found in the RMF Mon III Coupling Facility
       activity which is option 7 from the RMF Sysplex Report Selection
       Menu. To obtain information concerning reclaims for a particular
       structure, simply position your cursor on the cache structure
       name and hit enter.

    c. SMSVSAM Lock Structure in the Coupling Facility.
       The initial and maximum size of the IGWLOCK00 lock structure is
       defined in a policy stored in the CFRM data set. There is
       historical data and real time data available.

       HISTORICAL:
       SMF Type 42 Subtype 17 records contain data on RLS lock structure
       activity. It is recommend to keep all contention for locks below
       1% and false contention below 0.5 %.

       Real Time:
       The D SMS,CFLS command will display the contention rates.

    d. SHCDS data sets.
       Data concerning the utilization of these resources is provided by
       system commands, SMF records (type42 subtypes 15, 16, 17, 18, and
       19), and RMF records.

 8. APAR OA17065 reports ABEND of the SMF Address Space and RLS takes an
    OC4 with >255 Extent Relief.  SMSVSAM calculated the size of SMF 64
    records based on the number of extents, but didn't protect for the
    many more extents with GT 255 Extent Relief, causing it to create an
    SMF record that was too large, which overlaid bits that SMF needed
    to process the record.  This led to SMF abending and in turn RLS
    took an 0C4 during the close of the dataset opened to RLS.

 7. The TYPE74 DLYCMRTM='INITIAL*COMMAND*RESPONSE*CMR TIME'
      is a subset of PEND time.
    - PEND starts when the SSCH puts the ORB in an HSA subchannel
    - CMR starts when the ORB is selected for processing by a
      channel. CMR time will always be less than or equal to
      PEND time.
    - PEND and CMR end when a CMR is presented to the channel
      for the first CCW.
    - Essentially, the difference between CMR and PEND is
      subchannel queueing.  While subchannel queueing is
      common under ESCON, it only occurs in FICON when all of
      the channels that serve a device have reached their OE
      limit, i.e., 32 or 64
    - You should use (CMR+DISC+CONN)*SSCH_RATE to get a device's
      contribution to channel MPL.
    - CMR should never be added to get service time
      (i.e., PEND+DISC+CONN) since it is a subset of PEND.
      Thanks to Dr. H. Pat Artis.

 6.  A "memory leak" (known as a PROGRAMMING ERROR to real programmers)
     in WebSphere when SMF 120s are created and a send error occurs.
     APAR PK24786 associated with SERVICE LEVEL W510234 of WebSphere
     Application Server V5.1.0 for z/OS corrects the ERROR.

 5.  DFSORT SMF type 16 records with exactly 24 hours of CPU Time are
     reported in APAR QP72589, which was closed "Fixed In Next", but the
     APAR was not available in time for DF Sort Release 1.5.  The APAR
     text cites dynamic allocation and STIMER as being involved in the
     incorrect value in ICECPUT field.


 4.  APAR II13674 documents data in the RMF MONITOR III CPC REPORT,
     showing which fields are populated pre and post z/OS 1.6.

 3.  APAR OA15360 corrects SMF89IST, which was equal to SMF80IET in the
     type 89 subtype 2 record.

 2.  APAR OA15281 reports the value in SMF71ACA (MXG Variable HIUICAV in
     TYPE71 dataset) is smaller than the minimum SMF71LIC/HIUICMN, due
     to incorrect accumulation, and affects z/OS 1.2 thru 1.7.  20Apr06.

 1.  APAR OA15712 reports invalid CPU time in SMF30CPT/CPUTCBTM in SMF
     type 30 records due to invalid Enclave CPU time; CPUTCBTM was more
     than the 15 minute SMF interval duration, and occurs when an
     enclave transaction is restarted, because in that case, the field
     ENCB_TIME_ON_CP is never reset to zero.  Apr 20, 2006.


IV.   DB2 Technical Notes.

 6.  Two MXG sites with DB2 V8 and zIIP engines have opened a problem
     with IBM DB2 Support: field QWACZIS1, the new zIIP CPU Time in the
     SMF 101 (DB2ACCT) record, contains a negative value ('FFFFFFnn'x),
     which becomes an extremely large value in MXG, as the INPUT is with
     PIB (Positive Binary), since only positive values make any sense.
     These negative values are the result of incorrect subtraction in
     IBM DB2 code, so there will ultimately be an APAR and PTF, and this
     note will be updated when that exists.  Oct 13, 2006.

 5.  APAR PK30886 reports SMF 102 IFCID 145 Audit Trace record was not
     written for LOCK TABLE statement nor for REFRESH TABLE statement.

 4.  APAR PK19368 corrects DB2 creation of additional unexpected SMF 102
     IFCID 254 records; they were created for each IFCID 230 record.

 3.  APAR PK18669 discusses why the DB2TCBTM CPU Time in DB2ACCT can
     be larger than the TASCPUTM in CICSTRAN, due to under-reporting of
     up to 16 microseconds per transaction with the current CICS clock
     resolution.  The APAR is CLOSED as a FUTURE requirement to use all
     8 bytes of STCK versus the current use of only the middle 4 bytes.
     The FUTURE is announced in CICS/TS 3.2, with expanded time fields.

 2.  APAR PK12365 corrected errors with QWHCBSC having missing values
     in DB2ACCT records with QWACRINV=3.  18May2006.

 1.  APAR PK19191 corrects the values in DB2ACCT and DB2STATS variables
     QLSTROWS and QLACROWS, which were not properly incremented when
     using block fetching for a cursor.  The weekly counts dropped from
     300 million to 1 million when DB2 V8.1 was installed but this APAR
     was not.  4May2006.

V.   IMS Technical Notes.

 1. APAR OA18996 reports problems with SMF 42 subtype 6 (TYPE42DS) due
    to DSSB overlay in IMS in some instances.
VI.  SAS Technical Notes.

11. New in SAS Version 9, the PUTLOG statement can be useful debugging
    programs which have multiple FILE statements; PUTLOG directs DATA
    step output to the SASLOG file, regardless of the current "FILE" in
    effect.

10. The V9SEQ sequential engine does NOT honor the GLOBAL option to
    COMPRESS=YES, when the output device is a tape drive on z/OS,
    because all tape devices have hardware compression, and to also use
    SAS Software compression only wastes CPU time for no value.  But a
    tape dataset can be compressed by using the dataset option instead:
    DATA MYSTUFF(COMPRESS=YES);  if you ever really need to compress
    with SAS software even when writing to a tape device (but I cannot
    fathom why you would want to!).
      One reason:  If you use EMC COPYCROSS to write to tape, you can
      disable it's compression, and since SAS V9.1.3+ does NOT compress
      when a dataset is written to tape device AND the Global option
      COMPRESS=YES is in effect (the MXG default), you may choose to
      enable compression for each dataset written to tape, by using the
      Dataset Option COMPRESS=YES for each dataset, which can be enabled
      by adding a statement
         MACRO _Kdddddd COMPRESS=YES  %
      in your IMACKEEP tailoring member for each dataset to be written
      to tape.  The mapping of the "dddddd" value for each MXG dataset
      can be found in the IMACxxxx member for that product.

 9. SAS Note SN-015924 reports that variables with DATETIME formats can
    print truncated values (like '02AUG2005:00:00:00.00' instead of the
    correct value '02AUG2005:00:23:14.99').  The problem is most severe
    when literals are used to create datetime values with more decimal
    places than the places in the format (.999 input, .2 place format),
    but I have replicated it with artificially created datetime values,
    if the decimal value happens to be certain fractional values.
    While no MXG site has reported the truncation, it would be wise to
    install Service Pack 4, a prerequisite, and this correction.
    Changing the DATETIME format in your report to show no decimals, or
    to show more decimal places will print the correct date and time.

 8. The undocumented xmrlmem options will display the amount of virtual
    storage that SAS can use:  DATA; X=GETOPTION("xmrlmem"); PUT X=;

 7. Using %UTILBLDP as a single create-and-execute under SAS V9.1.2 got
    ERROR: Text expression length (-nnn) exceeds maximum length (65534).
    This error is discussed in SAS SN-V8+ -01437 which reports it is not
    fixed until SAS V9.2; however, it does not fail under SAS V 9.1.3 at
    another site, and running %UTILBLDP as a two-step process to create
    the SAS code and then separately execute the created code works at
    the 9.1.2 site.

 6. PROC SYNCSORT (not the SYNCSORT Sort Product, but the SAS add-on)
     ERROR:INVALID SEQUENCE OF COMMANDS FOR FILE PDB.xxxxxxxx.DATA
     ERROR:WER755A XVPUTE ERROR ENCOUNTERED.FUNCTION CODE=0,RC=8001F8OB
    resulted when PROC SYNCSORT was trying to write to a SAS library
    that had been created by SAS V6, and the new dataset being written
    has a variable longer than 200 bytes.

    Disabling PROC SYNCSORT exposed the real SAS error message:

     ERROR: THE CHARACTER VARIABLE SYSLTEXT HAS TOO LONG A VALUE FOR THE
            PDB LIBRARY.

    which has NOTHING to do with SYNCSORT; it says your PDB DSNAME was
    created by SAS V6, and the new MXG Version you are testing creates
    new long-length character variables that cannot be written to a V6
    data library.  MXG has required SAS V8 or V9 for these new data for
    several years; its only because you've been using a back-level of
    MXG that your daily job did not fail earlier!

    If the output DDNAME is DISP=NEW, then the problem is that you must
    have an out-of-date JCL that points to an old version CONFIGV9, or
    you have an old version VMXGINIT (which should never be tailored!).
    Instead, you must have a CONFIGV9 for z/OS with SEQENGINE=V9SEQ and
    if you MUST tailor VMXGINIT, it must have TAPENGN=V9SEQ.

    If, instead, your failing program is overwriting, i.e., reusing an
    existing SAS data library, that data library (and any similar "PDB"
    data libraries), must be converted from the non-supported-V6 format
    to a SAS V9 format data library, by executing PROC COPY under V9
    with DISP=NEW for the new data library, renaming the ORIGPDB to
    V6OLD, and then renaming the NEWPDB back to the original ORIGPDB
    DSNAME:
        // EXEC MXGSASV9
        //OLDPDB DD DSN=ORIGPDB,DISP=SHR
        //NEWPDB DD DSN=NEWPDB,DISP=(,CATLG),SPACE=(CYL,(500,500))
        //SYSIN DD *
         PROC COPY IN=OLDPDB OUT=NEWPDB MT=DATA;

        Then  RENAME ORIGPDB to V6PDB

        Then  RENAME NEWPDB  to ORIGPDB

      You also need to examine your "day of week" (MON/TUE/WED/DAY/WEEK)
      DSNAMES to see if they are also in the old V6 format, by looking
      at the SAS Engine in the proc contents output:
        PROC CONTENTS DATA=OLDPDB._ALL_ NODS DETAILS;TITLE OLDPDB;
        PROC CONTENTS DATA=MON._ALL_ NODS DETAILS;TITLE MON PDB;
      If they were created by V7, V8, or V9, they support long lengths.

 5. Error message  "Restricted options module not in linklist library"
    occurs when the SAS installation option OPRESTRICTIONS=XXXXXXXX was
    set in the site's config file, but when SAS did its BLDL for that
    restricted options module XXXXXXXX, it was not found in a LinkList
    library, and for security, SAS does not allow user overrides for a
    restricted options module.  The default restricted options module
    name in V9 is SASOP910, and it is created by the SAS installer
    running the BAOPTS2 job in the SAS installation CNTL data set.  You
    can read PROC OPTIONS DEFINE; output to see which options can be
    restricted.

 4. A comparison of I/O rates to read/write a SAS tape/disk dataset on
    z/OS, using a 180 MegaByte DB2ACCT dataset:

      Disk   Tape   Elapsed                                    Total
      EXCP   EXCP   seconds   Description of test              MB/Sec

       466      0     6.2     Read from disk, no write           29
         0   5747    17.5     Read from tape, no write           10
       466   5747    25.3     Read from disk, write to tape.     14
       Calculated:   19.1     Write to tape, delta case 1-3.      9

      The estimated Write-to-Tape time of 19.1 seconds was surprisingly
      close to the observed Read-from-Tape time of 17.5 seconds.  Long
      ago, I observed write costs that were four times the read cost.

      Each Tape EXCP count was a block count of 32760 byte blocks.
      Each Disk EXCP count was an SSCH/SIO count of 404,016 bytes.  The
           Disk dataset's pagesize was 55296, so SAS read 7 pagesizes,
           or 7 tracks, or 14 half-track-DASD-blocks per EXCP counted.

 3. The V9SEQ sequential engine does NOT honor the GLOBAL option to
    COMPRESS=YES, when the output device is a tape drive on z/OS,
    because all tape devices have hardware compression, and to also
    use SAS Software compression only wastes CPU time for no value.
    But a tape dataset can be compressed by using the dataset option
    instead:  DATA MYSTUFF(COMPRESS=YES);  if you ever really need to
    compress with SAS software even when writing to a tape device.


 2. SAS Note SN-013725 reports ABEND 0C4 while attempting to read an
    empty file with INFILE statement options such as LRECL=, BLKSIZE=,
    and RECFM=, and this ERROR message may be printed:
      ERROR: System abend 0C4 occur4red outside of the SAS environment.
        or
      ERROR: SYSTEM abend 0C4 occurred in module SASXAL function
             VXBSM at offset 00582C.
        The note then says "To circumvent the problem, remove any
        external I/O options specified in the INFILE statement."

    However, in my tests, it was only the CCHHR= operand that caused the
    error, the only MXG code that still requires CCHHR INFILE option is
    TYPEEREP.  But more important, SAS Service Pack 2 for 9.1.3 has
    fixed the problem.  April 20, 2006.

 1. In SAS 9.1 and above, new options DMSOUTSIZE and DMSLOGSIZE allow
    you to increase the number of lines send to your SAS Output and
    SAS Log window, to avoid the "Output window full" condition.
    They must be specified in your SASV9.cfg file.

VII. CICS Technical Notes.

  1. Threadsafe transactions can save significant CPU time, as was noted
     in Newsletter FORTY-ONE's article on Open Transaction Environment,
     OTE.  CICSTRAN variable DSCHMDCN's count and DSCHMDTM's duration
     (in CICS/TS 3.1, replacing the earlier count in CHMODECT) provides
     the count/duration of task switches between the QR and L8 TCBs, and
     can be used to identify which transactions are most likely to
     benefit from being made to be threadsafe.


VIII. Windows NT Technical Notes.


IX.  z/VM Technical Notes.


X.    Incompatibilities and Installation of MXG vv.yy.

 1. Incompatibilities introduced in MXG vv.yy (since MXG 23.23):
    See CHANGES.

 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.


XI.   Online Documentation of MXG Software.

    MXG Documentation is now described in member DOCUMENT.


XII.  Changes Log

--------------------------Changes Log---------------------------------

 You MUST read each Change description to determine if a Change will
 impact your site. All changes have been made in this MXG Library.

 Member CHANGES always identifies the actual version and release of
 MXG Software that is contained in that library.

 The CHANGES selection on our homepage at http://www.MXG.com
 is always the most current information on MXG Software status,
 and is frequently updated.

 Important changes are also posted to the MXG-L ListServer, which is
 also described by a selection on the homepage.  Please subscribe.

 The actual code implementation of some changes in MXG SOURCLIB may be
 different than described in the change text (which might have printed
 only the critical part of the correction that need be made by users).

 Scan each source member named in any impacting change for any comments
 at the beginning of the member for additional documentation, since the
 documentation of new datasets, variables, validation status, and notes,
 are often found in comments in the source members.

Alphabetical list of important changes after MXG 24.01 now in MXG 24.02:

  Dataset/
  Member   Change    Description

  See Member CHANGES or CHANGESS in your MXG Source Library, or
  on the homepage www.mxg.com.

Inverse chronological list of all Changes:

Changes 24.yyy thru 24.001 are contained in member CHANGES.

*********************NEWSLETTER FORTY-EIGHT*****************************




       MXG NEWSLETTER NUMBER FORTY-EIGHT, Feb 20, 2006.

Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE

                         TABLE OF CONTENTS

I.    MXG Software Version.
II.   MXG Technical Notes
III.  MVS Technical Notes
IV.   DB2 Technical Notes.
V.    IMS Technical Notes.
VI.   SAS Technical Notes.
VII.  CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX    z/VM Technical Notes.
X.    Incompatibilities and Installation of MXG.
         See member CHANGES and member INSTALL.
XI.   Online Documentation of MXG Software.
         See member DOCUMENT.
XII. Changes Log
     Alphabetical list of important changes
     Highlights of Changes  - See Member CHANGES.

     COPYRIGHT (C) 2005 MERRILL CONSULTANTS DALLAS TEXAS USA

I.  The Annual MXG Version, 23.23, dated February 20, 2006, was sent
    on CD-ROM to all sites shortly thereafter.

 1. The current version is MXG 23.23, dated Feb 20, 2006.

    See CHANGES member of MXG Source, or http://www.mxg.com/changes.

II.  MXG Technical Notes

 2. ASCII to ASCII translations.

    These ASCII "text" characters, received in emails from international
    customers, must be translated into their "MXG expected" ASCII hex
    value, so MXG source can execute on all EBCDIC and ASCII platforms:

       Description       Received in Emails      MXG Expected ASCII
         single-quote         '92'x                   '27'x
         double-quotes        '93'x,'94'x             '22'x
         dash                 '96'x                   '2D'x
         at-sign              'F5'x                   '40'x

 1. How can I count the DB2 IFCIDs in my SMF file?

    You can use this tailored execution of %READDB2:

        %LET MACKEEP=
          %QUOTE(
                 MACRO _E102SSSS OUTPUT T102SSSS;
                 KEEP QWHSSSID QWHSIID;
                 DELETE;
                 %
          );
       %READDB2(IFCIDS=0-350);RUN;
       PROC FREQ DATA=T102SSSS;
       TABLES QWHSIID*QWHSSSID;
       TITLE DB2 IFCIDS FOUND FOR EACH SUBSYSTEM;
       RUN;

    The %LET MACKEEP= is used to re-define the _E102SSSS old-style macro
    so that after the T102SSSS dataset observations are output with only
    the two variables in the KEEP statement, the DELETE statement will
    cause no other T102xxxx datasets to be output, so there will not be
    and disk space required for those data.
    But this only will show the IFCIDs that were actually created; you
    could have other IFCIDs enabled for events that didn't happen in
    the specific SMF file you read with that program.


III. MVS Technical Notes.

27. APAR OA14557 corrects very high SMF73TUT/SMF73PUT values in error
    when a channel is cycled offline and back online in one interval.

26. APAR OA14557 corrects errors in SMF73TUT/SMF73PUT when a channel is
    taken off line and back on line within one RMF interval.

25. APAR OA14131 changes the SRM IEAOPTxx option IFAHONORPRIORITY=YES
    processing, and points to WSC FLASH10432 for additional information
    as to why IBM recommends that option; the APAR also notes that the
    IFACROPSSOVER option is no longer required to be specified to use
    IFAHONORPRIORITY=YES.  If IFACROSSOVER and IFAHONORPRIORITY are both
    specified YES, they operate independent of each other.  The intent
    of the APAR is to allow more zAAP eligible work to run on zAAP
    processors while still remaining responsive to the zAAP demand.

24. Specifying REGION=0M in the JCL is equivalent to specifying
    MEMLIMIT=NOLIMIT.  Options for altering this behavior include:
     - Using IEFUSI to set MEMLIMIT ceilings for your system, since
       IEFUSI settings override the JCL, or,
     - Use SMFPRMxx system default settings, but this works only if
       there is no REGION or MEMLIMIT specification in this JCL.
    However, APAR OA14391 reports the wrong MEMLIMIT is assigned for
    jobs started with REGION=0 that have an IEFUSI exit controlling the
    REGION, but that IEFUSI exit does NOT control the MEMLIMIT, if
    MEMLIMIT was specified in the JCL or SMF.

23. RMF/CMF type 70 records with no PHYSICAL segments are created if the
    "Global Performance Data Control" on the Security Panel (Customer
    Image Profiles) is changed from checked (default) to unchecked.
    When checked, an LPAR can view CPU utilization and IOP data for all
    LPARs in the configuration.  When unchecked, the LPAR can view only
    its own information.  But this field MUST be checked when running
    RMF at a level that supports FICON, even if no FICON hardware is
    installed. See pages 3-71 to 3-73, z9 109 PR/SM Planning Guide.

22. APAR OA14365 corrects negative values in CPUUNITS variable in SMF 72
    records when IFA Processors are used.  The APAR lists R723IFAT and
    R723CCPU as impacted, and states "The IFA times that WLM returns are
    not always in sync with the IFA times WLM returns as part of the TCB
    time in the IWMWRCAA fields.  This can result in the IFA time being
    slightly larger than the TCB times for an address space at a time
    where it has little activity".  13JAN2006.

21. APAR OA14282 corrects JES 2 SMF 26 records to include WLM data even
    when there are no JOB account fields.

20. APAR OA14674 corrects SMF 42 subtype 19 SMF42JRA and RMF III VSAM
    LRU report; the buffer size high field did not include all storage
    cells.  04JAN2006

19. APAR OA14652 reports SMF 30 subtype 2 interval records not recorded
    after apply of APAR OA08702.  04JAN2006.

18. APAR OA14124 for Unix System Services reports certain instructions
    in the file system layer of USS cause excessive CPU cache misses,
    which results in a degradation of performance. But the APAR text
    RECOMMENDATION: Maintaining certain statistics counters in the file
    system causes writing to storage3 that is outside the CPU cache is
    PROBLEM CONCLUSION: The internal statistics for the Lookup Look
    Aside (LLA) table will no longer be maintained.  The number of file
    system reads and writes will no longer be maintained unless SMF
    accounting is active for SMF type 92 Subtype Unmount records!!!

17. MXG's example JCL Procedures MXGSASVn have always had //SORTWKnn DD
    statements (static allocation), which prevent dynamic allocation by
    the sort product for the work space needed for each individual sort.
    Part of this was historic: SAS releases a decade or more ago didn't
    properly support dynamic allocation by all existing sort products.

    But use of dynamic allocation may now be wiser, since sort products
    now get the file size from SAS, so they allocate only the workspace
    needed for that sort, and then free the disk space, whereas with the
    static allocation, your step holds all of that work space for the
    entire life of the step.  And, that static allocation must be large
    enough for the very largest sort in the step.

       The SAS option FILSZ is the default for many versions; it passes
       the file size to the host sort package.  Originally SAS had to
       provide an alternative (OPTIONS NOFILSZ) to disable passing, as
       it took a few years for all sort packages to support FILSZ.
       (SAS believes that all sort packages now support FILSZ.)
       To see what values SAS passed to your host sort, you can use the
       OPTIONS SORTLIST; statement to get lots of details on each sort
       printed on the SAS log.

    But there ARE cases where static //SORTWKnn DDs are required:

    - Really big sorts, that require more than 6 Sort Work Areas; as
      documented in SAS Note 8750:
           With DYNALOC and SORTPGM=SORT, allocation will be done by the
           non-SAS sort utility, and in this case, the number of
           sortwork data sets which will be allocated is limited to the
           number specified in the SORTWKNO= option. The maximum value
           for the SORTWKNO= option is 6.
      Instead, when manually allocated, the sort package will use all
      that you choose to allocate; I've seen massive DB2 sorts require
      32 sort work DDs.   This paragraph added April, 2008.

    - A critical job that does multiple sequential sorts in one step
      (like a daily BUILDPDB), with the static DDs, you are guaranteed
      to keep the work space for all of those sorts; with dynamic
      allocation, you can get halfway thru the sorts, and then fail when
      there is not enough work space in your pool (because other jobs
      have now allocated that work space that you just freed!).

    You might blame the ABEND on poor storage administration, but using
    static DDs could get you through the night!

    Like most technical answers, "it all depends....".

16. APAR OA11469 corrects impossible values for Low Impact Frames, when
    running in 64-bit mode; errors in IRARMSTM, the UIC Update process,
    incorrectly counts some address spaces more than once when it gets
    interrupted.  Low Impact Frames are CSFRLOxx variables in TYPE71,
    and all of the "Impact" frame metrics are documented in ADOC71.

 == Notes below were included in MXG 23.08 ==

15. APAR OW45020 discusses delays in varying DASD devices offline if the
    SMF type 69 record has NOT been turned off.  The IBM recommendation
    is to NEVER specify TYPE(69) and ALWAYS specify NOTYPE(69).

14. APAR PK13643 documents a caution that Application SYNCH TO OS THREAD
    option can significantly increase the number of SMF type 80 RACF
    records for security auditing.

13. APAR OA10814 has something to do with WLM Managed Initiators not
    starting when you thought they should have.

12. APAR OA13570 corrects zeros in RLS Cache Statistics in both RMF 74
    and SMF 42 subtype 15; the error was introduced by APAR OA05619.

11. APAR OA06476 added Raid Rank and other new data to RMF 74 subtypes
    5 and 8; those new data were not fully supported until MXG 23.04,
    Change 23.023, although the original attempt was Change 22.141.

10. Kathy Walsh's Latest zAAP information listed these APARs:
    OA11794 - SMF30ENC (enclave CPU time) may contain zeroes
    OA12009 - IFA CPU fields in SMF 72 have incorrect values
    OA12550 - IFA Using and Delay Samples - documentation APAR.

 9. Don Deese reports these PR/SM enhancements in z9 109:

   * PR/SM treats CP, ICF, IFL, and IFA as separate individual pools of
     resources.

   * PR/SM allows weights and capping to be specified individually for
     CPs and IFAs assigned to an LPAR (IFAs no longer inherit the
     specifications from the CP specifications).

   * PR/SM allows individual specification of reserved CPs and IFAs
     (the new LPAR Processor definition panel allows the same options
     for IFAs as for CPs....interestingly, although IRD doesn't support
     this as yet, the panel also has a check box for "enable WLM
     manager" for both CPs and IFAs).

   * The new panels also allow many of these specifications for ICF and
     IFL LPARs (e.g., initial and reserved ICF and IFL).

 8. APAR OA11469 reports an error in internal MCVUIC4S field can cause
    RMF to report a larger-than-possible-value for the number of low
    impact frames (MXG variables CSFRLOAV CSFRLOMN CSFRLOMX).

 7. APAR OA12361 corrects variable R723SCSR, (IBM field R723SCS#), which
    can have negative values if the Classes Served array changed between
    two invocations.

 6. APAR OA10346 adds the User Specified Partition Number, UPID, to the
    RMF 70 record.

 5. APAR OA07320 "AVT CORRECTIONS FOR WLM OFFLOAD SUPPORT" has changes
    to correct IFA CPU times, which could be higher than the total time
    in service units, and other IFA-related corrections.

 4. APAR OA09978 reports Peer Wait Subchannel Counts and Times, MXG
    variables R744SPST and R744SPTC, can have invalid values.

 3. Information APAR II13941 documents why the IEFACTRT exit (which is
    normally used to print step and job end statistics on your joblog)
    can have a negative elapsed time for very short jobs.

 2. APAR OA11207 documents that SMF 89 recording is lost if SMF is
    switched from  ACTIVE to NOACTIVE and back to ACTIVE with a SET
    command, and an IPL is required to restore creation of SMF 89s,
    although the APAR also states "Closed SUG ... A solution to this
    problem will be delivered from IBM in a Release (if any) to be
    available within 24 months."

 1. APAR OA10091 reports that SMF 42 records may not be written for PDSE
    libraries, beginning with DFSMS/MVS Release 1G0.

V.   IMS Technical Notes.


VI.  SAS Technical Notes.

 9. The THREADS option in SAS V9 may or may not help MXG jobs perform:

   -Use of THREADS is bypassed when BY statements are used.  Only when
    you use a CLASS statement (instead of a BY statement) will the
    PROC SUMMARY/MEANS consider using THREADS.

   -THREADS requires more than one CPU engine for any real benefit.

   -For MEANS/SUMMARY, the REGION size completely controls whether
    THREADS are used, and there is no way to know if threads were
    enabled and/or used, with the default SUMSIZE=0 option value.

    The SAS System option SUMSIZE=0 default allows all of your REGION
    to be used for summarization, but if you specify a non-zero value
    for SUMSIZE, you are restricted to that portion of your REGION size.
    If you use a value for SUMSIZE that is larger than your REGION size,
    you will get a message:
       AN ERROR HAS OCCURRED WHILE SORTING A CLASS INTERACTION TYPE.


   -When the REGION size is not large enough, THREADS does all its I/O
    to DISK; at least it does tell you that has happened with this note:
        NOTE: PROCESSING ON DISK OCCURRED DURING SUMMARIZATION.
              PEAK DISK USAGE WAS APPROXIMATELY 98 MBYTES.
              ADJUSTING SUMSIZE MAY IMPROVE PERFORMANCE.
    but it's impossible to predict; you must iterate REGION size to find
    the minimum value for that specific set of CLASS variable's values.
    The NOTHREADS EXCP count of 3,469 jumped to 76,060 with THREADS when
    compared in an 80 MB REGION; we had to increase the REGION size to
    180 MB to drop the EXCP count back to the NOTHREADS value.  However,
    with that large region, the CPU time was very significantly reduced,
    from xxxx to yyyy.

     The below paragraph was written in 2006, and the virtual memory
     issues may be history now, since you can use the NWAY option to
     only create the lowest CLASS level, and the new-in-SAS-V9.2 TYPES
     statement allows you to select some but not all CLASS combinations.
     Not that MEANS and SUMMARY are now identical so any past notes that
     they were different (which they were) are not true for a long time.
     As for the last sentence, your mileage may vary:

     However, my dislike of the CLASS statement for summarization is due
     to its exposure to causing erratic and unpredictable OUT OF MEMORY
     ABENDS in your production job.  The virtual storage needed by CLASS
     statements increases exponentially with the number of subgroups and
     intersects in the input data, which can vary widely from day to day
     and grows over time, and can have a step increase when new things
     are added.  As a result MXG has rarely ever to maybe never ever
     used CLASS statements in its mainline summarization.
     And past benchmarks showed that using a PROC SUMMARY with a CLASS
     statement was always more CPU-expensive than a PROC SORT plus a
     PROC SUMMARY with a BY statement.

 8. SN-014771 reports errors "NOTE: Semantic dump disabled" and 0C4
    ABEND if the incorrect release of PROC SYNCSORT is used with SAS V9.
    You must use PROC SYNCSORT release 2.3.b.   Note that this is only
    for the separate "PROC SYNCSORT" product and is not an error in the
    SYNCSORT "sort" product.  26Jan2006.

 7. Syntax errors for variant characters (brackets, exclamation mark,
    the dollar sign, the at-sign, the English pound sign, exclamation
    mark, CRLF) may be fixed by turning off the scanner-translation
    table (by setting the 6th position of the TRANTAB= to a zero).
    See SN-015485 for the exact (and less-than-obvious) syntax.

    But the NLSCOMPATMODE option, required for MXG so that a single text
    file of SAS code executes on all SAS systems worldwide, which is
    set in CONFIGV9, to override the default NONLSCOMPATMODE value,
    can also impact these variant characters.  The MXG override is ONLY
    required when creating it's SAS datasets; once they exist, that
    option can be reset for reporting and printing, etc.  One European
    site found that the exclamation mark and CRLF that were not being
    created in ods output with the MXG default, were created with the
    SAS default.  NEWSLTRS and CHANGESS have more on NLSCOMPATMODE.

 6. SN-016064 documents that System C03 and USER U998 ABENDS may occur
    on z/OS SAS when external files (i.e., non-SAS data libraries) are
    opened using BPAM and BSAM access methods.  "This is especially
    likely to occur when using %INCLUDE or an autocall macro.  The
    likelihood of failure increases as more files are opened.

 5. PATTERN DSCB NOT FOUND with SAS Version 9.1.3 when creating an MXG
    weekly PDB as a new member of an MVS GDG (Generation Data Group)
    with z/OS should not happen, since the requirement that your JCL
    has a "MODEL DSCB" went away when SMS came to manage our datasets.
    However, this site found that ERROR because, buried deep in their
    ACS Rules, was logic that if PROGRAM=SAS, then do not SMS manage
    the dataset, with a comment that this was done for SAS Version 5!!
      (SAS V5 datasets were a problem for SMS management).
    Removing that condition from SMS eliminated the errors.

 4. SAS will offer LPAR-Size-in-MSU-based pricing for SAS Version 9.1.3,
    more properly called "Sub-Capacity Licensing", starting in January,
    2006.  Previously, only "CEC-size-based" pricing was available.
    Pricing will start at 30 MSU.  This technical description of MSU and
    LPAR was taken from a July 2005 post to MXG-L by Dan Squillace:
       MSU capacity is a term specific the IBM z/OS and OS/390 operating
       systems.  It is a processor-speed-independent way of stating the
       computing capacity of a system.   Each processor on a machine is
       capable of generating a given number of 'service units' per
       second of work.  One MSU is one Million Service Units per hour.
       There are multiple MSU values associated with a given machine.
       The MSU capacity of the entire physical system, or Central
       Electronic Complex, is known as the 'CEC Capacity'.  Each LPAR
       running an OS on the CEC has its own MSU capacity, known as its
       'image capacity'.  This image capacity is the value used in SAS
       Software sub-capacity licensing.  Note: In the simplest case, a
       machine may have just one LPAR in which case the image capacity
       equals the CEC capacity.

    PLEASE don't expect your SAS Salesperson to know all about this at
    this time, as the prices and details are still being finalized by
    SAS Institute. Instead, take this note as a "heads-up" of what's
    coming, and watch http://www.sas.com for the official announcement
    later this year.

 3. +INVALID VALUE SPECIFIED FOR OPTION SEQENGINE IN CONFIG FILE and an
    USER ABEND U0999, but with no SAS log printed, has occurred at two
    sites, and in both cases, they were using SAS Version 8.0, which was
    never a production release from SAS, and which was never supported
    by MXG, because of flaky errors like this one.

 2. SAS note SN-015716 reports that using the TIME() or DATETIME()
    function to get the time of day has always been wrong on "MVS",
    by 44 seconds; they were adding leap seconds instead of subtracting
    them.  Only these FUNCTIONs are impacted, and they are not used in
    MXG Software to populate any datetime variables.

 1. New SAS Version 9  OPTIONS MAUTOLOCDISPLAY  can be used to identify
    autocalled library from which a %macro was compiled.

VII. CICS Technical Notes.

 1.  You cannot change DFHMCT (i.e., change the INCLUDE/EXCLUDEs) by
     turning the monitoring off and back on, even though that does write
     a dictionary record (CEMT SET MON NOPERF, CEMT SET MON PERF).
     You must recycle the region in order to change the MCT.

VIII. Windows NT Technical Notes.

IX.  z/VM Technical Notes.


X.    Incompatibilities and Installation of MXG vv.yy.

 1. Incompatibilities introduced in MXG vv.yy (since MXG 22.22):
    See CHANGES.

 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.


XI.   Online Documentation of MXG Software.

    MXG Documentation is now described in member DOCUMENT.


XII.  Changes Log

--------------------------Changes Log---------------------------------

 You MUST read each Change description to determine if a Change will
 impact your site. All changes have been made in this MXG Library.

 Member CHANGES always identifies the actual version and release of
 MXG Software that is contained in that library.

 The CHANGES selection on our homepage at http://www.MXG.com
 is always the most current information on MXG Software status,
 and is frequently updated.

 Important changes are also posted to the MXG-L ListServer, which is
 also described by a selection on the homepage.  Please subscribe.

 The actual code implementation of some changes in MXG SOURCLIB may be
 different than described in the change text (which might have printed
 only the critical part of the correction that need be made by users).

 Scan each source member named in any impacting change for any comments
 at the beginning of the member for additional documentation, since the
 documentation of new datasets, variables, validation status, and notes,
 are often found in comments in the source members.

Alphabetical list of important changes after MXG 22.22 now in MXG 23.01:

  Dataset/
  Member   Change    Description

  See Member CHANGES or CHANGESS in your MXG Source Library, or
  on the homepage www.mxg.com.

Inverse chronological list of all Changes:

Changes 23.yyy thru 23.001 are contained in member CHANGES.

*********************NEWSLETTER FORTY-SEVEN ****************************




       MXG NEWSLETTER NUMBER FORTY-SEVEN, June 5, 2005.

Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE

                         TABLE OF CONTENTS

I.    MXG Software Version.
II.   MXG Technical Notes
III.  MVS Technical Notes
IV.   DB2 Technical Notes.
V.    IMS Technical Notes.
VI.   SAS Technical Notes.
VII.  CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX    z/VM Technical Notes.
X.    Incompatibilities and Installation of MXG.
         See member CHANGES and member INSTALL.
XI.   Online Documentation of MXG Software.
         See member DOCUMENT.
XII. Changes Log
     Alphabetical list of important changes
     Highlights of Changes  - See Member CHANGES.

     COPYRIGHT (C) 2005 MERRILL CONSULTANTS DALLAS TEXAS USA

I.  The Annual MXG Version, 22.22, dated February 1, 2005, was sent
    on CD-ROM to all sites by Feb 2, 2005.

 1. The current version is MXG 23.05, dated Jun 5, 2005.

    See CHANGES member of MXG Source, or http://www.mxg.com/changes.

II.  MXG Technical Notes

 2. SAS Clones

   I. WPS from WPC - THIS NOTE WAS WRITTEN IN 2005.
      READ MORE RECENT NEWSLETTERS, AS MUCH HAS CHANGED SINCE THEN
   a. A purported clone of the SAS System, the WPS, "World Programming
      System", from World Programming Corporation, is, in my opinion,
      still only vapor-ware.  Several postings to MXG-L have questioned
      MXG support for WPS, and MXG users have been told many things by
      IBM sales reps; IBM is now an authorized reseller of the product:
       - "80% of SAS code is supported"
       - "most PROCs are supported but not all proc statements"
       - "We are due a new version in third quarter that will have quite
          a few of those PROCs you have asked about, except we will not
          have PROC REPORT, CHART and CALENDAR by then.  If you are
          looking for MXG support, we should be able to help by around
          end third quarter as well."
       - "WPS provides the functionality of SAS BASE utilizing the SAS
         Language.  WPS in some situations may be a viable alternative
         to SAS Base."
       - "Existing mainframe SAS applications can be executed under WPS
         and in many cases there will be no need to change your existing
         applications at all."
      And the company's home page states:
       - "Note that MXG is not CURRENTLY supported, check back soon".

      Several USA sites told me they expected to install WPS in Feb/Mar,
      but none have received the product.

      I first became aware of WPS in August, 2004, when an IBM contact
      asked if I would consider supporting a SAS clone.  At that time
      I had reservations, but after an hour-long conversation with Sam,
      the President of WPC, I made him this offer:
      - Send me your product to install.  If it works perfectly to run
        MXG, then I will be morally obliged to announce that fact to my
        MXG users; while I have a strong allegiance to SAS Institute and
        its products, I have a stronger allegiance to the thousands of
        individuals who have based their careers on MXG Software, and I
        would be wrong to remain mute if there existed an alternative
        product that they should consider.
      - However, if your product fails to execute MXG properly, then I
        have no obligation to tell you why it failed.
      - He chose not accept my offer.

   b. The ONLY possible reason for replacing the SAS System would be
      for cost savings, but it was very unclear that there are any
      savings, especially in the short term, based on these 2004 price
      quotes from IBM:
      -One site was told WPS's price was "no more than 1.5 times the
       cost of SAS."  The site's quote was $600,000 for a site license
       on a "Class K" system, for which a Base SAS license is $38,000.
      -One site currently paying $250,000 US for Base SAS site licenses
       was quoted $1,250,000 list price for WPS acquisition, although
       IBM suggested that might be discounted by 20%.  The annual fee
       for maintenance (2nd year?) would be 20% of that list price,
       ($250,000 annually), with no discount possible.  And those were
       for the "Enterprise License"; the MSU-based license price was
       well over $2,000,000.
      -But now, apparently having read earlier versions of this article,
       IBM has corrected their prices cited above, and have new claims.
       The site paying $250,000 annually was told their cost now to
       acquire the product would be $170,000 for an 18 month license (so
       they would have overlap with the existing SAS License!), and that
       maintenance would be $34,000 annually.  According to the IBM
       announcement, purchase would be from IBM, but maintenance would
       be via a separate contract with WPC, rather than with IBM, so it
       is no longer an IBM product with a single interface!
      But these were only quotes, not actual contracts presented for
      review, nor were terms provided (does maintenance include new
      versions, or are they priced upgrades, etc.), and prices can
      always be changed, and discounts may be offered; if you actually
      have a license and can provide your price and terms, I'll gladly
      update this note with actual facts rather than these sales quotes.
          The difference between a used car salesman
                             and a computer salesman
          is that the used car salesman KNOWS when he's lying.

   c. Legality of a clone.  There is no legal issue for creating a
      product that processes SAS statements, as SAS statements have been
      legally defined to be a language.  The SAS database architecture
      and the code implementation is protected.  The original WPS
      product was written java and uses their own proprietary database
      architecture, providing even further legal isolation.
        Historical note: in the 1970s, Vanderbilt University folks used
        the Source Code that was then distributed with the $100 SAS tape
        to attempt to clone SAS for their unix; that copyright case is
        cited as the clearest example of copyright infringement, with
        entire chunks of SAS source code, and with the same spelling
        errors in comments, found in their clone's code.
   d. In early 2005, my comments on their java implementation stated:
      The WPS product is completely written in Java with their own data
      store.  Sam acknowledged last year that performance was not up to
      snuff yet, but he touted that the new zAAP (IFA) engines would
      solve that problem.  Since IFAs on z/990s are the same speed as
      z/900 CPs, IFAs can't improve performance on those boxes; it is
      true that IFAs on z/890s can be faster than the CPs, but that's
      only if you chose to buy "degraded" CP engines.  I'm not aware of
      Java itself being touted as boosting performance, so I remain
      skeptical that WPS will ever outperform SAS run times.
      Then, in Spring, 2005, I was told that performance was still such
      an issue, especially I/O performance, that they were considering
      a rewrite of parts of the Java kernel to improve its performance.
   e. Now, in Fall 2005: it turns out that WPS had so many problems with
      java performance that their entire product was re-written in C,
      and java is used no more.  So, WPS can NOT exploit IFA engines,
      and it can't offload any CPU time from your CP engines.  Its CPU
      time will impact any MSU-based charges, just like SAS would.

        Opinion:  I do not believe it is possible to out-perform SAS in
                  CPU time per megabyte of data processed.

 II. Clones in general

   a. Whether it's WPS or some future SAS clone, however, my real issue
      is: what product evaluation criteria would have to be met before
      you or I would consider a technical alternative to the SAS System?
      The following bullets are my list of considerations, and if there
      ever exists a possible contender to investigate, I will elaborate
      and expand these criteria after benchmarking the contender:
      1. Execution performance attributes
        - CPU consumption, interference, chargeback
           (Save $$ for software, but CPU cost $$$$ ??)
        - I/O performance, elongation exposure, chargeback
        - Elapsed run time comparisons
        - Disk Space requirements
        - File compression, effectiveness, CPU costs of compression
        - Data store - z/OS files or NFS, backup, etc.
        - SORT performance - internal to the product, or third party?
      2. Numerical accuracy
        - SAS floating point representation protects decimal places
        - variable length to control significant digits
      3. Full support of ALL SAS features and facilities
        - informats for input side conversion
        - formats for presentation and table lookup
        - bit and byte level tests
        - important Procedures
        - datetime, hex, etc., representations
        - old-style substitution macros
        - "new-style" %macros, argument sizes.
        - multilevel nesting, interleaved old-style and new-style macros
        - National Language symbols (UK Pounds vs US Dollars, etc.)
      4. Accuracy of the interpreter
        - It's one thing to successfully compile error-free SAS code
        - But how good are the diagnostics if the code has errors?
          - years of SAS development to identify errors clearly
          - substitutions when you typo
          - clarity of the location and cause of syntax errors
        - And of equal importance, how are data errors handled?
          - invalid data recognition
          - hex dumps of bad records
          - exact location of the bad data in the record
          - error handling when invalid data is detected
      5. Size of the product development and support team
        - WPC originally 5 ex-IBMers from Hursley, England, labs
        - Now supposedly 21 (how many admin now, versus technical?)
        - compare the staff at SAS Institute

   b. Morality of replacing the SAS System with a clone?

      Should a product like MXG
      - that was created by 'children of the sixties'
      - to 'give away the keys to the kingdom'
      - that exists solely because of the brilliant design of the SAS
        language and its incredible performance with large data files
      - that can execute on any platform thanks to the multiple platform
        implementation of the SAS System
      consider supporting a clone product
      - whose sole and total motivation and only possible value is to
        make money for them by undercutting the price of SAS on z/OS
      - by only replicating parts of the original product?

      There are only two reasons that should cause you to consider the
      replacement of the SAS System on z/OS:
       1. the high cost of SAS on z/OS due to its CEC-based pricing, or
       2. bitterness toward SAS Institute for its perceived predatory
          pricing on z/OS, and/or toward the perceived arrogant attitude
          of its z/OS sales reps.
      If the first applies, then you should carefully examine the below
      benchmark results of running MXG on a PC, because it shows you can
      - save far more money
      - have guaranteed execution of all of your SAS programs
      - have full technical support from SAS Institute
        - and even in your local language
      - and gain benefit of continued enhancements to the SAS System
      simply by moving your existing SAS applications to a platform with
      lower price.
      If the second applies, perhaps moving to a cheaper platform will
      get you a new sales rep, but as a minimum, you'll impact his/her
      sales performance!  But in fairness, you need to look, not at the
      absolute dollar cost, but the cost of SAS as a percentage of your
      total budget for hardware and software, and recognize, that for a
      small percentage of total, you are able to measure, manage, and to
      control the costs and services provided by that budget, so the
      "high" cost of SAS may not really be all that high after all.


 1.  Can I really move my MXG processing to a PC (or unix Workstation)?

   A. Yes, you can:

    Glenn Bowman reported via a posting to MXG-L that he had moved his
    processing of 13 GigaBytes per day to an IBM PC running Windows/XP.
    He provided run time statistics, and at my request ran additional
    reports on the sizes of the output libraries, for this note.

    This first table shows the size of the output "PDB" data libraries
    created from the 13 GB input SMF file; his tailored PDB processes
    additional SMF records that create more output datasets in his PDB
    library than the "vanilla" MXG PDB.  There were 3,642,163 CICSTRAN
    observations and 3,046,583 DB2ACCT observations created.

    His 13 GB of SMF input required only 9GB of (compressed) disk space
    on his PC for all of that data, and the work file was only 5GB in
    size (because CICSTRAN and DB2ACCT were directly written to their
    own "PDB" libraries):

                MXG ANALYSIS OF OUTPUT LIBRARIES SPACE REQUIRED

                                          BYTES
          Library             Number of    OF     COMPRESSED    AVG %
          Name      DATASETS  Variables   DATA      BYTES    COMPRESSION

          CICSTAT       89       6021      693M      440M       36.40
          CICSTRAN       1        397     9274M     3895M       58.00
          DB2ACCT        1        494     9044M     3708M       59.00
          PDB          156      15199     1889M     1152M       38.98
          SPIN           7        385       21K       21K        0.00
              Total                      20900MB    9195MB


    Glenn initially processed this data with the original technique of
    converting the data from VBS to RECFM=U on MVS, then ftping the SMF
    data to a PC file, and then running BUILDPDB to read the disk file.
    But then, after his initial post, he was made aware that it is NOT
    necessary to download any raw data to the PC, by using the SAS ftp
    access method to directly read the raw SMF data, with these results:

     Original MVS:    Daily job on 9672-X77 8 hours, over  480 minutes

     Old way on PC:   Convert VBS to RECFM=U    25 minutes
                      ftp the 13 GB SMF file    36 minutes
                      BUILD001 (READ SMF)       67 minutes
                      BUILD002-5,ASUMs, etc     44 minutes
                                    Total daily run time   172 minutes

     New way on PC:   BUILD001 with ftp access  48 minutes
                      BUILD002-5,ASUMs, etc     44 minutes
                                    Total daily run now     92 minutes

    Using ftp access dropped his daily run time from about 3 hours to
    an hour and a half, and no disk space for SMF data on PC is needed.

    And his hardware platform:  A 3.2GHz Pentium 4 with 512MB RAM, with
    one 40GB and two 250GB Internal Hard Drives (all 7200 RPM), and one
    USB 250GB External Hard Drive.

    Additional notes from Glenn:
    - Originally he ftp'd with an FTP server product called NFM, but it
      took ten times as long as ftp, so NFM was abandoned.
    - Originally he used the MVS batch ftp to PUT the SMF data to the PC
      but every other day it would fail with some unknown error, so he
      then changed his process and used the PC to GET the SMF data.
    - His 2x250GB drives are compressed and he keeps two weeks input SMF
      data and two weeks detail PDBs online; his weekly PDB backups are
      subsequently uploaded back to MVS and backed up to Tape GDGs for
      archiving.
    - His 13GB of SMF is software compressed by SMS on the mainframe,
      and MXG sets the SAS COMPRESS=YES so all MXG data is compressed.
    - SAS is NOT licensed on MVS; SAS is ONLY licensed on his PC.


   B. "Just because you CAN does not necessarily mean you SHOULD!"

     If there are other users of SAS on the mainframe, that may be all
     that is needed to justify the cost of SAS on MVS, but even in their
     absence, I still recommend that it is better if you can execute
     your MXG application to build your MXG datasets on the industrial
     strength mainframe, not only because SAS under MVS is technically
     superb at handling large volumes of data efficiently, but also
     because
     - the job scheduling products eliminate human management time
     - the file management facilities of MVS (i.e., MVS catalog, JCL,
       single DDNAME for an entire PDB library are more human-friendly,
     - ESPECIALLY, HSM performs automatic DASD space management of what
       data is on disk and what data is migrated to tape, eliminating
       the need for human management of backups and disk space.
     - ESPECIALLY, Workload Manager/Goal Mode, can prevent MXG from
       interfering with interactive users (if that's what you want!);
       ASCII platforms have nothing in the way of intelligent software
       that lets you determine who gets what on a shared system.
     - everything is automated, so that MVS execution of MXG Software
       requires much less human time to monitor and manage the MXG job
       stream.
     But once you have built your MXG datasets on your mainframe, then
     it does make sense to use SAS on your Workstation or PC to graph,
     to report, and develop analyses and reports, especially when your
     plotters and graphic presentation devices are PC or Workstation
     based.  You can bring down only the summary data you need for
     today's analysis or testing, keeping the PDB data libraries
     archived on the mainframe you are measuring.
     Many MXG users on MVS process not only their MVS data, but they
     also ftp their other platform measurement data (z/VM with its linux
     data, raw NTSMF data for their Windows Platforms, AS/400 QACS data,
     and TNG and PTX and other unix data) to MVS where they clone their
     SMF BUILDPDB process to create and archive the MXG-built SAS
     datasets for all of their platforms on MVS.

     But MXG was enhanced in 1995 to run on PCs and Workstations, not
     because it was the best place to execute MXG, but because some MXG
     technicians were told they would lose their job if they could not
     move the SAS work off the mainframe (typically, MXG was the only
     SAS application at these sites, and the SAS mainframe license cost
     can exceed the technician's salary!)   MXG Software successfully
     executes under all flavors of Windows, UNIX, and linux, and there
     are performance benchmarks in past MXG Technical Newsletters.
     And you no longer have to even download the raw SMF data; you use
     the SAS ftp access method to read the z/OS data directly with MXG.

     However: you really must use a dedicated Workstation for MXG.  Do
     NOT believe that you can put your MXG Application on an existing
     shared unix/linux/windows server without serious impact.  As NONE
     of those operating systems have a concept of a Workload Manager,
     and because SAS is designed to be fast and efficient, your daily
     MXG job can easily "steal" the entire system from the other users
     of those unprotected "ASCII" systems, and thus a dedicated
     workstation is far safer than a shared server for MXG execution on
     an ASCII Platform.  Even if you plan to run your MXG daily job at
     3am, there will be a time when a 9am rerun is required, so make
     sure your boss is aware of this paragraph if he/she makes you use a
     shared server.

     And, you will spend much more of your time managing the execution,
     backup, etc, as noted above.

     A small number of MVS data sources still require partial execution
     on MVS, although SAS is NOT required for these programs:
     - Assembly programs (all start with ASM in MXG source) cannot be
       executed on PCs or Workstations, so IBM'S RMF III data must be
       first processed with ASMRMFV before download, and users of
       ASMIMSLx will have to run part of the JCLIMSLx process on MVS
       before download for the SAS steps.
     - INFILE exits are not supported on ASCII platforms.  Compressed
       data from Landmark and Candle can be read directly by SAS
       on MVS because assembly routines for decompression are provided
       as INFILE exits (EXITMON6 for ASG/Landmark, Candle provides a
       load module), but if you move your processing to ASCII, you will
       have to first uncompressed on the mainframe before download.

     But due to SAS Pricing on z/OS platforms, many MXG customers have
     successfully moved their MXG application from the mainframe to
     Unix/Linux on workstations or dedicated PCs with Windows/XP, all of
     my own development and Alpha tests are executed with SAS V9.1.3 on
     a Windows/XP platform; only final QA tests are executed on z/OS.

     However, many MVS sites have still kept SAS running on their z/OS
     platforms, so they can still enjoy the data management with minimal
     human time, by creating a "penalty box" on a small capacity machine
     to minimize the cost of the SAS base license, using the Scheduling
     Environment to direct all of their SAS jobs to run in that LPAR,
     using PROC CPORT/CIMPORT to move SAS datasets to their Workstation,
     where SAS and SAS/Graph are licensed for analysis and reporting.
     The Mullen Award winning paper at CMG 2005 by MP Welch and Chris
     Schreck, "Mainframe Software Licensing - Software Licensing Cost
     Reduction Strategies for Large Mainframe Environments" described
     exactly how SPRINT set up that environment.  Their paper can be
     downloaded from http://www.mxg.com/downloads.asp.

     If you cannot afford to keep SAS on your z/OS platform, you can
     save some software dollars by moving the MXG Application to ASCII,
     but it will cost some people dollars for management of job streams
     and for data management, archiving, and backup, and be prepared to
     install a dedicated workstation because of the lack of any workload
     management on those ASCII systems in their present state.


III. MVS Technical Notes.

23. DCOLLECT run against 3390-54 produces incorrect information for
    DCVPERCT: DCOLLECT shows 21% free, but ISPF shows 0% full with
    978,450 tracks total, and 977,940 tracks free, and ISMF shows 99%
    free.  IBM delivered Usermod ANDCOL1 (as FIXTEST) with Prereq
    UA17960, and that corrected the DCOLLECT output.

22. A discussion on IBM-Main cause me to post this technical note:

    Don't get a rumor started that RMF is expensive!

    Looking at data from one of our largest sites, with ten LPARs and
    over 30,000 DASD devices to monitor, they run both RMF Monitor I
    and RMFGAT Monitor III  (and as strongly recommended, they only
    capture the DASD CACHE data from one system):

         Monitor I daily CPU costs:
           RMF Cache Collecting LPAR      26 minutes per day
           RMF Sum of other 9 LPARS       51 minutes per day
             total                        77 minutes per day

    They also choose to run RMF III, which is more than ten time as
    expensive than Monitor I, but well worth it for its ability to
    investigate delays:

         Monitor III daily CPU costs:
           RMFGAT Cache Collecting LPAR  330 minutes per day
           RMFGAT Sum of other 9 LPARS   540 minutes per day
             total                       870 minutes per day

         Total RMF I and RMF III         947 minutes per day

     Their 47 Engines have a total capacity of 67,680 CPU Minutes, so
     the total cost of RMF I and RMF III is only 1.3% of capacity.
     They create and process about 400 GigaBytes of SMF data daily.
     The SMF dumping of that data took 163 minutes CPU time, and 27
     hours elapsed time for all ten systems.  The MXG processing of
     those 400GB took 12 hours of CPU time and 33 Elapsed Hours (but
     there is tremendous parallelism: SMF is dumped frequently and
     split, the DB2 and CICS data is processed with each dump, and
     the reports are run in parallel, etc.).

     Summarized:     RMF and RMFGAT Address Spaces  947 minutes
                     IFASMFDP runs                  163 minutes
                     MXG Processing 400GB data      720 minutes
                        Total Daily Cost           1830 minutes
      which is 2.1% of installed CPU capacity for the site.



21.  APAR OA04644 discusses imbalance in page dataset activity if you
     have PAV enabled on some paging devices, but not all.  At one site
     10 of their 20 page volumes had zero utilization when D ASM command
     was issued from the console.  The 10 unused were all non-PAV.
     The APAR applies from z/OS 1.3 onwards, and it creates a separate
     queue for PARTE control blocks for page datasets residing on PAV
     devices.  Then, if a page out occurs, ASM's search for where to put
     that page first searches the PAV device queue, before looking at
     the other devices.  If a PAV device is located with a response time
     less than the average of all other device types, it will be chosen
     as the candidate for the page out.

20.  There are some address spaces that must run at DPRTY='FF' because
     they cannot be classified by WLM, but instead must run in the
     SYSTEM service class. These include these ASID names:
      *MASTER* RASP TRACE    DUMPSRV XCFAS   GRS   SMSPDSE  SMSVSAM
      CONSOLE  WLM  IEFSCHAS JESXCF  ALLOCAS IOSAS BPXOINIT
      IXGLOGR  SMF  CATALOG  JES2MON ANTMAIN WAD1CT
     There's nothing you can do about them, but if they start using lots
     of CPU time, they can cause severe degradation to other work.  For
     example, without APAROA06341, ANTMAIN began eating up full engines
     when 4 or 5 SnapShot copies were simultaneously run, killing batch!

19. APAR OA06341 reports increased job elapsed time for DSS Copy and
    Virtual Concurrent Copy performing COPY DATASET of data residing
    on SVA storage subsystem, and a big increase in CPU utilization
    in the ANTMAIN address space.  A circumvention to specify
    FASTREPLICATION(NONE) if the DFDSS parameters.

18. APAR OA08991 reports high CPU utilization in SMSPDSE address space
    after installation of UA10647; utilization steadily increases and
    doesn't level off, eventually leading to CPU performance problems.

17. A reoccurrence of these errors under SAS Version 9.1.3:
      EXPECTING PAGE 218, GOT PAGE -1 INSTEAD.
      PAGE VALIDATION ERROR WHILE READING WORK.XXXXXXX.DATA
      FILE WORK.XXXXXXX.DATA IS DAMAGED. I/O PROCESSING DID NOT COMPLETE
    which are erratic (4 failures in 25 executions) are believed by SAS
    to be caused either by BMC's MainView Batch Optimizer, MBO, fixed
    by BMC APAR BQ32297, or by IBM's SHARK DASD, fixed by OA11453.
    Aug 2007: BMC says BQ32297 was created in 2003 and released for
    general availability in MAINVIEW Batch Optimizer Release 2.3.00,
    and that maintenance is also in the now-current Release 2.4.00.
    Oct 2010: CATALOG VMXGIN IS IN A DAMAGED STATE with SAS V9.2 is
    caused by HyperPAV and Mainview Batch Optimizer.
    See MXG Newsletter 42 MVS Technical Note "6. BMC reports Fix...."


16. APAR OA09846 reports high response time in RMF 74 records for DASD
    connected to FICON channels when using the Extended Measurement Word
    facility; EMW is used on all 2084 and 2086 machines with full
    exploitation of the new hardware features.  The Disconnect time can
    be extremely large; the text indicates that while Connect Time might
    be exposed to the same problem, that there were no actual reports of
    connect time errors.

15. APAR OA11326 reports SMF 70 CPUWAITM much larger than RMF DURATM, in
    records that also have SMF70CNF bit indicating CPU reconfiguration
    activity during the interval.

14. APAR OA11469 reports values for low impact frames could exceed the
    total central storage on the system, for 64-bit systems.

13. APAR OA11068 discusses high CPU usage with PDSE default Hyperspace
    values after APAR OA06884, and documents new PDSE Hyperspace parms
    to rectify the problem. It also documents that the SMF_TIME(YES) is
    the default option in IGDSMSxx that synchronizes of SMF 42 interval
    record subtypes 1, 2, 15, 16, 17 and 18, and that SMF_TIME(YES)
    overrides IGDSMSxx parameters CACHETIME, BMFTIME, and CF_TIME.

12. APAR OA11465 corrects "negative" values for IFA CPU times in SMF 30
    records for multi-step jobs that use zAAP processors, both in
    CPUIFATM (SMF30_TIME_ON_IFA) and CPUIFETM (SMF30_TIME_IFA_ON_CP).
    An IBM "negative" value means the first bit is on, but MXG INPUTs as
    PIB, MXG will have a large positive number and not a negative one.
    These other APARs also exist in the area of IFAs:
     OA10707, OA07950, OA05731, OA09650, OA08110, OA07091, OA07320.

11. Using BMC's CMF Monitor (RMF Replacement) Version 5.5.05, you will
    need to apply PTF #BPM9335; without that fix, variable PVTFPFN,
    RMF field SMF71FIN (frames in nucleus) that was 5424 before the
    version change became only 2339 frames after the new version.
    Since PVTFPFN and PVTPOOL are added to create CSTORE in TYPE71
    dataset, CSTORE was also incorrect without the fix.

10. APAR II14006 reports a serious problem on 2084 and 2086 CPUs with
    (maintenance) MCL089 in the J13486 (SE-SP) stream if the machines
    are at Driver 55.  The SU_SEC value is one-quarter what it should
    be after that maintenance, both in the operating system and in the
    RMF records and on RMF reports.  The major operational impact is
    that period switching is based on service units that are calculated
    from that constant, so tasks will receive four times the defined
    DUR service units before they are switched to the next period, and
    the DB2 facility that terminates DB2 transactions after some number
    of service units will also not kick in until the transaction has
    used four times the CPU time limit that you chose.   Fixes for the
    IBM error are available and documented in the APAR text.
    While not documented in the APAR text, the value of R723NFFI, the
    IFA Normalization Factor, was also incorrect due to MCL089, as
    were R791NFFI and R792NFFI values.

 9. z/OS 1.6 has revised the SMF buffer processing, and has externalized
    new BUFSIZMAX and BUFUSEWARN parameters that you can set in SMFPRMXX
    and documented the BUFSIZMAX can be 1024MB, but 1.6 also removed the
    "knobs" that were used with APAR OW56001 to set the size of buffer
    expansion increments.  Those changes are now very well documented in
    Item BDC000031621, in response to a series of user questions:
    The IBM answers:

    You are correct, with z/os 1.6 level, you lose some control.  The
    APAR offset will NOT work to set parms.  A new mechanism was used to
    set the parameters.  You can only set the max buffer size and the
    warning level percentage.  You cannot set the increment size and the
    init size as they default to 8 MB.  But I understand your concern
    and have verified the changes made to SMF buffer processing, and the
    conclusion is that you will NOT need these changes that you have
    used in the past.  Let me now explain the reasons motivating this
    positive statement:

    During initialization, SMF gets the BUFSIZMAX value that you have
    specified and getmains in SP 229 of the SMF address space BCAs
    (buffer chains) of BQEs (Buffer Queue element holding SMF CIs)for
    the size that you have specified.

    SMF now has two chains:

      In-use chain:
        two BCAs are initially set for the initial 8 MB
        (pointed to by SLCABCAP)

      Available chain:
        contains the number of BCAs needed to represent
        the storage you have requested minus the initial 8 MB

    As  SMF records get written, SMF records gets saved into BQEs while
    waiting for physical write to the SMF datasets.  When the in_use
    chain fills at 75%, buffers from the available chain get added to
    the In-Use chain to offer staging space for the incoming SMF
    records.  When records have been written and the activity is such
    that the buffers are no longer needed, they get returned to the
    available chain.  Buffers from the available chain never get
    freemained unless you dynamically reduce the BUFSIZMAX.

    As you can see, logic has changed and SMF does not do multiple
    getmains and freemains as it did before.  Therefore the need to
    change the increment size is not necessary since it is only used to
    set the initial In_use buffers.

 8. APAR OA10901 adds the zAAP Normalization factor into the SMF 30
    record.

 7. If your site's ACS (allocation) rules have a really stupid default
    that has a "fall thru" that puts that allocation in a Data Class
    that allocates an Extended Sequential dataset, instead of a simple
    Physical Sequential Data Class, when you write to that allocation,
    you will get these SAS error messages on the log:
      ERROR: OPEN TYPE=J FAILED TO POSITION LIBRARY DATA SET PDB....
      ERROR: ATTEMPT TO OPEN SAS DATA LIBRARY PDB FAILED.
    and your SYSMSG will have this IBM error message
      IEC143I 213-B8,IFG0194D,....
    because SAS does not support Extended Sequential for data libraries.
    (You can allocate a sequential format, tape, library to a Data Class
    that is Extended Sequential, so that you can hardware compress it;
    see "How do you hardware compress a SAS dataset" in Newsletter 36.)

 6. APAR OA07672 revises how WLM-managed initiators are started, and
    adds new SMF 99 trace codes.

 5. APAR OA06687 reports incorrect values for Queue Delay (R723CQ) and
    Other Unknown Delay (R723CUNK) can be propagated into other service
    classes if one of the WLM managed initiators registered batch
    classes experiences Queue or Unknown delay, and large values may be
    seen in those variables for non-batch service classes.

 4. MXG revised:  Use the IBM Default MSOCOEFF of zero, not .0001.

    Thanks to a query to IBM support from an MXG user when I couldn't
    answer why his MSOUNITS didn't match his PAGESECS with the IBM
    published formula, IBM has discovered that the MSOCOEFF value that
    is used internally in their code has a minimum value of 0.0122.
    While the WLM definition supports a value as small as 0.0001, and
    while that value is reported in TYPE72s and TYPE30s, the smallest
    value that can be represented internally is 0.0122. IBM will update
    the SMF Manual to show the actual formula used for scaling:

    MSO COEFF used for Calculations =

                       Input MSO Coeff multiplied by 10000     4096
                       ____________________________________ *  ____ + 1
                              10000                             50

    The result is truncated to the nearest integer value.  As a result,
    input values between 0.0001 and 0.0122 all result in a value of 1,
    and a MSO coefficient of 1 results in a value of 82, which is then
    used by WLM to calculate MSO service.  That 4096 is a page frame
    size of 4096 bytes: "To make MSO roughly commensurate with CPU
    service units, the raw number is divided by fifty to yield MSO
    Service Units."

    IBM's recommended default MSOCOEFF is zero, but MXG had previously
    recommended that you use 0.0001, for these two reasons:
    - So that both MSOUNITS in type30 and type 72 are non-zero.  While
      memory service units are, in principle, poor metrics, because they
      ONLY count memory when the program is executing TCB CPU time, and
      do not record any pages owned when a task is resident and waiting,
      they are useful when non-zero primarily to show how poor they have
      always been, since you can now compare the MSOUNITS page-seconds
      with the ACTFRMTM resident-frame seconds; I've seen completely
      erratic MSOUNITS when compared with the better ACTFRMTM metric.
        However: memory variability is to be EXPECTED; memory is NOT
                 something a program chooses to use some amount of, but
                 real memory is "doled out" to programs by WLM, based
                 on your service level objectives, and the instantaneous
                 system utilization when your program ran, etc.
      I have used that variability to prove to management exactly why we
      cannot "charge" for "memory used", so I preferred to record them.
    - So that MSOUNITS are NOT a significant percentage of total service
      units.  In compat mode, Service Unit absorption rates were used in
      MPL management (i.e., swapping decisions) and even earlier were
      used in those beloved "OBJ" curves, and the early IBM defaults of
      10,10,5,3 for CPU/SRB/IO/MSO caused MSO to be a major percent of
      total service.  But memory is NOT work - work is CPU and I/O, and
      making "work" and swap decisions based on total service that was
      dominated by MSOUNITS was wrong, which is precisely what the APAR
      that changed the minimum MSOCOEFF from 0.1 to 0.0001 stated was
      its purpose - to REMOVE the impact of MSO from total service, and,
      ultimately, why IBM now sets a default of zero for MSOCOEFF.
    That second issue, major decisions based on service units, is no
    longer true.  In WLM/Goal Mode, service units are now used ONLY to
    determine period switch of service classes with multiple periods,
    so a high percentage from MSO Service doesn't impact all workloads.

    But how bad can the percent of service from MSOUNITS be with 64-bit
    hardware, even with a 100:1 ratio of CPUCOEFF to MSOCOEFF?  Pretty
    bad, as this z/OS 1.6 data from CPUs with SU_SEC 10K-19K shows:

      CPU=10  SRB=10  IO=6  MSO=0.1 (i.e. 100:1 CPU:MSO ratio)

       Total Service= 40,010,255,811
       MSO Service  = 29,371,433,067
       CPU Service  =  6,340,430,161
       SRB Service  =  2,414,650,968
       IO Service   =  1,187,416,751
       CPU+SRB+IO   = 10,388,822,744

    Even with a 100:1 ratio, MSOUNITS were 73% of total service units!
    Reducing the MSOCOEFF from 0.1 to 0.0122 would reduce MSO Service
    to 3,583,384,834, and total to 13,972,137,579, but even then, with
    a ratio over 800:1, MSOUNITS would still be 25% of total service.

    And note that this data had CPUCOEFF=10, which is 10 times recent
    recommendations to set CPUCOEFF to ONE! I believe the motivation for
    the CPUCOEFF=1 was because the SMF 30 records did not contain the
    service coefficients, so by setting CPU/SRB=1, you could calculate
    CPU time from CPU Service.  But IBM recently put the coefficients in
    the 30s, so using a larger CPUCOEFF could be one way to ensure that
    MSOUNITS are a small percent of total service but still record the
    MSOUNITS in your 30s and 72s.

    Ok, the real truth:  I had thought that with MSOUNITS=0 that the
    PAGESECS field in SMF 30s was also zero, and so my suggestion to
    use MSOCOEFF=0.0001 was really to preserve that SMF 30 field; I
    had only used MSOUNITS in SMF 72s to show how bad they were when
    IBM added the Active Frame Time field (ACTFRMTM) in TYPE72GO, and
    now, knowing that the "terrible" PAGESECS are still recorded with
    MSOCOEFF=0, I believe that MSOCOEFF=0 is the best choice, since it
    will prevent MSOUNITS from being included at all in total service
    units, and thus MSOUNITS will NOT impact period switching of your
    service classes with multiple periods, and you won't have to change
    your existing CPU/SRB/IO coefficients!

    Note that you may need to change your DUR value in those multiple
    period service classes, if MSOUNITS are currently a significant
    portion of the total service units with your present coefficients.

    APAR OA10641 documents the above 0.0122 value and the equation.


 3. APAR PQ98205 reports excessive SMF 80 records and "memory leak"
    (known to real System Programmers as a MEMORY CODING ERROR) in
    WebSphere V5.0.  The SMF80 records are EVENT CODE 67.
    The fix, to free the old memory before replacing the security token
    with a new one, is still not immediate; this is JAVA folks, and the
    cleanup is, like Basic on TRS-80s, done via "garbage collection".

 2. Info APAR II13427 lists changes required for CA-TOP SECRET and ACF2
    by WebSphere 401, 500, and 501 releases.

 1. Info APAR II13360 lists many problems caused by third party products
    in OPEN/CLOSE/EOV and Access Methods PDSE/HFS/CMM/CVAF/DADSM.


IV.  DB2 Technical Notes.

 4. IBM Redbook "Stored Procedures: Through the Call and Beyond"
    discusses how to keep track of "nested" DB2 times.

 3. APAR PQ99525 fixes a couple of problems for "nested" DB2 access;
    i.e. Stored Procedures, Triggers, and User-Defined Functions (UDF).
    a. Class 1 accounting for these items could capture and record small
       fractions of Class 2 In-DB2-Time, causing QWACASC and QWACAJST
       having non-zero values when Class 2 accounting was NOT active.
    b. UDFs and Stored Procedures require In-DB2-Time to connect and
       disconnect to DB2; this time was not being accounted for in
       Class 2 times (QWACSPTT,QWACSPEB,QWACUDTT,QWACUDEB).  Class 3
       suspension time is recorded during this connect and disconnect
       processing, and thus Class 3 time could be significantly greater
       than Class 2 time.

 2. APAR PK04803 reports QWACEJST may be zero, or less than QWACBJST for
    RRSAF threads that execute in multiple tasks; these records would
    also have QWACRINV equal to 6 and/or 16.  Fix expected July, 2005.

 1. The IBM Redbook "Distributed Functions of DB2 for z/OS and OS/390",
    publication SG24-6952 discusses high volumes of SMF 101 records if
    DB2 thread pooling is used:
      -DB2 thread pooling can be a disadvantage at very high transaction
       rates, because an SMF accounting record is cut every time a
       thread becomes inactive. In such scenarios it may be better to
       avoid thread pooling and stick with CMTSTAT=ACTIVE. If so, you
       should ensure that some kind of client-side pooling is active
       (such as WebSphere connection pooling, discussed in 6.1.6,
       "Application connection pooling with ODBC and JDBC" on page 159),
       so that threads are kept open for the application connections,
       and the applications perform regular commits, but do not
       disconnect.
      -The recently announced Version 8 of DB2 for z/OS will provide
       some relief in this area as well. DB2 V8 will allow roll-up
       accounting information for DDF threads. Instead of writing an
       accounting record every time a thread gets pooled, an accounting
       record is only written after 'n' occurrences, where 'n' is a new
       DSNZPARM.  See "DB2 UDB for z/OS Version 8 Technical Preview",
       publication SG24-6871:
      -z/OS Version 8 Technical Preview, SG24-6871:
       6.8.2 Roll up accounting data for DDF and RRSAF threads.
       If you establish a connection to DB2 V7 via DDF, you normally
       want to use DB2's type 2 inactive threads. This function is also
       known as thread pooling. This feature is enabled by specifying
       CMSTAT=INACTIVE in DSNZPARM. Using the inactive thread support
       allows you to connect up to 150,000 users to a single DB2
       subsystem. However, if you are running high volume OLTP workloads
       in this environment, you might encounter a performance
       bottleneck, because DB2 cuts an accounting record on every COMMIT
       or ROLLBACK when using thread pooling, and SMF might have a hard
       time to keep up with the massive number of DB2 accounting records
       that are produced.
      -You may encounter a similar problem when using the RRS attach, in
       combination with WebSphere. WebSphere drives the RRS signon
       interface on each new transaction, and DB2 cuts an accounting
       record when this happens. An accounting record is cut, even
       though some of these transactions contain just one SELECT
       statement followed by a COMMIT.
      -DB2 V8 adds a new installation option to activate the rollup of
       accounting information for DDF threads that become inactive, and
       RRS threads.  The new option DDF/RRSAF ACCUM has been added to
       installation panel DSNTIPN.  The default is NO.  The values
       accepted for this option range from 2 to 65535.  The
       corresponding DSNZPARM is ACCUMACC.
      -When NO is specified, DB2 writes an accounting record when a DDF
       thread is made inactive, or when signon occurs for an RRSAF
       thread.  If any number between 2 and 65535 is specified, DB2
       writes an accounting record after every n occurrences of end user
       on any RRS or DDF thread, where n is the number specified for
       this parameter.  An end user is identified as the concatenation
       of the following three values:
          End user userid (QWHEUID, 16 bytes),
          End user transaction name (QWHCEUTS, 32 bytes), and
          End user workstation name (QWHCEUWN, 18 bytes).
      -Even when you specify a value between two and 65535, DB2 may
       choose to write an accounting record prior to the nth occurrence
       of the end user in the following cases:
        -A storage threshold is reached for the accounting rollup
         blocks.
        -You have specified accounting interval = 'COMMIT' on the RRSAF
         signon call.
      -When no updates have been made to the rollup block for 10
       minutes, that is the user has not performed any activity for over
       10 minutes that can be detected in accounting.
      -Search the archives at MXG-L for ACCUMACC for several postings
       that discuss the data that is lost when ACCUMACC is enabled.


V.   IMS Technical Notes.


VI.  SAS Technical Notes.


 5. SAS Clones.

  This article was written in the Summer of 2006, and has been
  superseded by the WPS Technical Note VI. in MXG Technical
  Newsletter FIFTY-ONE, dated December 6, 2007.

  a. WPS is still vapor-ware:

    I offered to test WPS last August to WPC company president
     - if it worked perfectly I'd be morally obligated to report
     - if it failed I would not be obliged to share my knowledge
     - He couldn't handle that offer
    - Several USA sites were to get the software in March, not yet.
    - Purportedly '80%' of base SAS statements supported?
    - 'Not Ready for Prime Time', maybe this fall?
    - Company stated that 'MXG IS NOT SUPPORTED', maybe in 2006!
    - Company wants to run your SAS code first to see what breaks
    - Written Java, can exploit zAAP.
    - But they are rewriting their Java Kernel for performance!
    - Not one single execution comparison yet published

    - Pricing is not competitive in first year(s)?
       Site paying equivalent of USD200,000 per year for base SAS only
       IBM quotes to that site in equivalent USD:
         WPS - MSU Based Price       $2,100,000
         "List price is $2,500/MSU for WPS"
         WPS - 'Enterprise' License  $1,200,000

  b. Issues for MXG to support any SAS clone:

    i. Execution Performance attributes
       - CPU consumption/interference/chargeback
       - I/O performance/elongation/chargeback
       - Elapsed run time comparisons
       - Disk Space required
       - File compression, effectiveness, costs
       - z/OS files or NFS files - backup, etc.
       - SORT performance

   ii. Numeric accuracy
       - floating point representation
       - significant digits

  iii. Full support of all SAS language facilities
       - informats
       - formats
       - functions
       - bit and byte tests
       - important Procedures
       - datetime, hex, etc, representations
       - old-style macros, %macros, heavily nested, interleaved

   iv. Accuracy of interpreter
       - it's one thing to interpret error-free SAS code
       - but how good are the diagnostics when the code has errors?
         - years of SAS development to identify errors clearly
       - invalid data handling:
         - hex dumps of bad records?
         - exact location of data error?
         - error handling when invalid data detected?
         - broken VBS data segment support?

    v. Size of development and support team
       - was 5 ex-IBMers from Hursley
       - now supposedly 21 people

   vi. Morality
       Should a SAS-based product that is essentially free,
       created by 'children of the sixties',
       support a SAS-clone product whose total motivation
       is to under-cut the price of that outstanding product,
       by only replicating parts of that product?
       WHEN YOU CAN SAVE MORE MONEY BY MOVING SAS TO A PC?????

 4. The ID variable is kept from the last observation when PROC MEANS is
    used to create an output dataset.

 3. SAS Note SN-014639 documents why you get those BPX messages, like
     BPXP018I THREAD ... ENDED WITHOUT BEING UNDUBBED ... CODE 0003E7
    They only show that there was a USER 999 ABEND ('3E7'x=999 dec),
    and that Unix System Services had been called ('dubbed'), and have
    no impact.  The USER 999 ABEND means:  look on the SAS log for the
    real ERROR message; option ERRORABEND is in effect, and it causes
    any SAS error message to cause the step to end with USER 999 ABEND.

 2. Using PROC MEANS N MIN MAX SUM DATA=PDB.RMFINTRV; VARIABLES CPU: ;
    (to investigate all variables starting with CPU) fails with RMFINTRV
    because it has character variables that start with CPU.  In emails
    with SAS Support requesting that the ERROR be changed to a WARNING,
    they suggested this alternative, using the _CHARACTER_ option:
    PROC MEANS N MIN MAX SUM DATA=RMFINTRV (DROP=_CHARACTER_);
    VARS CPU: ;  which works with all PROCs that expect only numerics.
    And, if only character vars are wanted, you can use this syntax:
    PROC FREQ DATA=RMFINTRV (DROP=_NUMERIC_); TABLES CPU: ;

 1. SAS option MAUTOLOCDISPLAY will show the library/directory name from
    which an AUTOCALLed macro was loaded, useful in diagnosing problems
    when a user hasn't removed old VMXGxxxx members that define %MACROs,
    since MXG uses AUTOCALL to compile all of its %MACROs.


VII. CICS Technical Notes.


VIII. Windows NT Technical Notes.

IX.  z/VM Technical Notes.

 1. APAR VM63636 reportedly corrects paging problems i z/VM 5.1


X.    Incompatibilities and Installation of MXG 23.01.

 1. Incompatibilities introduced in MXG 23.01 (since MXG 22.22):
    See CHANGES.

 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.


XI.   Online Documentation of MXG Software.

    MXG Documentation is now described in member DOCUMENT.


XII.  Changes Log

--------------------------Changes Log---------------------------------

 You MUST read each Change description to determine if a Change will
 impact your site. All changes have been made in this MXG Library.

 Member CHANGES always identifies the actual version and release of
 MXG Software that is contained in that library.

 The CHANGES selection on our homepage at http://www.MXG.com
 is always the most current information on MXG Software status,
 and is frequently updated.

 Important changes are also posted to the MXG-L ListServer, which is
 also described by a selection on the homepage.  Please subscribe.

 The actual code implementation of some changes in MXG SOURCLIB may be
 different than described in the change text (which might have printed
 only the critical part of the correction that need be made by users).

 Scan each source member named in any impacting change for any comments
 at the beginning of the member for additional documentation, since the
 documentation of new datasets, variables, validation status, and notes,
 are often found in comments in the source members.

Alphabetical list of important changes after MXG 22.22 now in MXG 23.01:

  Dataset/
  Member   Change    Description

  See Member CHANGES or CHANGESS in your MXG Source Library, or
  on the homepage www.mxg.com.

Inverse chronological list of all Changes:

Changes 23.yyy thru 23.001 are contained in member CHANGES.

*********************NEWSLETTER FORTY-SIX*******************************




       MXG NEWSLETTER NUMBER FORTY-SIX, Dated February 1, 2005.

Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE

                         TABLE OF CONTENTS

I.    MXG Software Version.
II.   MXG Technical Notes
III.  MVS Technical Notes
IV.   DB2 Technical Notes.
V.    IMS Technical Notes.
VI.   SAS Technical Notes.
VII.  CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX.   Incompatibilities and Installation of MXG.
         See member CHANGES and member INSTALL.
X.    Online Documentation of MXG Software.
         See member DOCUMENT.
XI. Changes Log
     Alphabetical list of important changes
     Highlights of Changes  - See Member CHANGES.

      COPYRIGHT (C) 2004 MERRILL CONSULTANTS DALLAS TEXAS USA

I.  The Annual MXG Version, 22.22, dated February 1, 2005, was sent
    on CD-ROM to all sites by Feb 2, 2005.

 1. Major enhancements added in MXG 22.22:

    See CHANGES member of MXG Source, or http://www.mxg.com/changes.

II.  MXG Technical Notes

 1. You can use the SAS FTP access method to directly read MVS SMF data
    on your execution platform (another MVS or an ASCII pc/unix system!)
    without first downloading the SMF file, and without converting the
    data file to RECFM=U:
     - read with ftp access takes no disk space to store the SMF data
     - run time is faster with ftp-access than the sum of the time to
       ftp-download plus read the downloaded data:
       - MVS to ASCII direct read took 82 seconds ET, ftp download took
         200 seconds ET and then 27 seconds ET to run TYPE30 on ASCII.
       - MVS to MVS direct read took 1 min 11 sec ET (17 CPU seconds),
         ftp download took yyy ET (zzz CPU), plus 35 seconds ET (14 CPU)
         to read the downloaded file.  And the ftp access job had only
         903 EXCPs (those must be the output writes, with none of the
         ftp access I/O being counted!), while reading the downloaded
         file recorded 12,000 EXCPs.

    This FILENAME statement syntax will read your MVS data using the
    ftp-read-access, and prompt for password:

      FILENAME SMF FTP "'MVS.DSNAME'" USER='USERNAME' HOST='FTP HOST'
            RECFM=S370VS RCMD='SITE RDW' LRECL=32760 PROMPT;

    or you can use this syntax and supply the password:

      FILENAME SMF FTP "'MVS.DSNAME'" USER='USERNAME' HOST='FTP HOST'
            RECFM=S370VS RCMD='SITE RDW' LRECL=32760 PASS='password';

    To use the ftp access on MVS, you will need MXG 22.12 or later, and
    as documented in Change 22.300, you will need to use
               %LET MXGJFCB=;
    as your first //SYSIN DD statement.

    SAS Note SN-013919 documents "ERROR: Service FTP not found" will
    occur if your services file, usually in
       c:\WINNT\system\drivers\etc
    does not include the following line
      ftp    21/tcp   # File Transfer Protocol (Control)

III. MVS Technical Notes.

12. APAR PQ98850 corrects the values of variables QESTMNUS,QESTMLUS in
    MXG dataset MQMCFMGR, from SMF 115 MQ-Series Coupling Facility Data.

11. APAR OW19569 changes the Message Identifiers for SMF Data Set name
    messages, if you choose to use new SMF dataset names.  Formerly,
    you could only have SYS1.MANn as the DSNAME of your VSAM SMF file,
    but you can now choose any 44-character name in your SMFPRMnn member
    of SYS1.PARMLIB.  But, if you do, the old messages (IEE360I,IEE362A,
    IEE362I,IEE364I,IEE949I-IEE953I,IEE960I and IEE966I) are now change
    to new numbers listed in the APAR.  This would be very important if
    your Automated Operations product does any management of SMF data
    based on Message ID.

10. Information APAR II13668 documents that the LPARNUM (SMF70LPN) is no
    longer what it used to be!  Prior to the 2084, machines used to use
    the customer input value for what was called 'partition number', and
    those old machines used it to identify both the logical partition
    number and the MIF image ID number for its I/O.  Beginning with the
    2084 and all future machines, that input control for HCD/IOCP
    applies only to the I/O for the partition, in concert with the CSS.
    There is no customer control over the number (SMF70LPN/LPARNUM) that
    identifies the logical partition number itself.  The customer does
    specify the MIF image ID number to identify its I/O in the 2084
    IOCDS, but the partition-number in SMF70LPN is internally generated
    alphabetically, based on LPARNAME by CSS.  This changed terminology
    is documented in the z990 IOCP User's Guide (SB10-7037).
    In the PDB.ASUM70PR and PDB.ASUMCEC MXG datasets, the set of LPnXXXX
    variables for each LPAR was based on the LPARNUM, so with 2084s what
    used to be in LP3XXXXX variables can be in any of the LPnXXXXX sets
    of variables, and that could change again tomorrow.  Instead of
    using the PDB.ASUM70PR dataset for PR/SM LPAR analysis, you should
    use the PDB.ASUM70LP dataset, that has only one set of variable
    names, and one observation for each LPARNAME, which should be used
    in your reporting/selection, instead of LPARNUM, now.
    And instead of using the PDB.ASUMCEC, which has the similar LPnXXXXX
    sets of variables, the PDB.ASUMCELP provides one set of variable
    names, reporting the full utilization of all LPARs/SYSPLEx in a CEC.

    Also, while the LPARNUM might not be what you expected numerically,
    because it is assigned to the LPARs alphabetically, the LPARNUM and
    the PARTISHN number will match for the LPAR of "this" MVS system, os
    the logic in VMAC7072 is not affected by this change.

 9. APAR PQ98201 fixes several internal defects for WebSphere 5.2.3,
    including incorrect values in X500Name information in SMF Audit
    records.

 8. APAR PQ98850 corrects SMF MQ-Series for z/OS Version 5.3 SMF record
    data fields QESTMNUS and QESTMLUS (Max Elements and Max Entries)
    that had extremely large values, sometimes.

 7. APAR OA10164 (finally - I reported this to IBM in 1993!) changes the
    Internal Clock Times of IBM's VTS device so they match the mainframe
    clock; previously, the VTS clock ran on its own time, and was hours
    away from reality when I first tried to match SMF 94 with internal
    log data from the VTS device.

 6. A question posted to MXG-L regarding the difference between SMF30AIS
    (25,000) and EXCPDASD (400) for an IMS BMP was answered by my best
    guess:

    SMF30AIS is an Address Space total count of SSCHs, the number
    of I/O operations caused by this address space to DASD devices,
    and is captured at the hardware level, and includes I/O operations
    that this address space performed via cross memory services to
    any other address spaces, plus any I/O from dependent enclaves.

    EXCPDASD is the sum of SMF30BLK, the Block Count for each DASD DD
    in this address space's TIOT, and those Block Count values depends
    on the Access Method:
     - for "well behaved" sequential Access Methods, QSAM/BSAM, it will
       be the count of blocks, i.e., "EXCPs"
     - for VSAM it will be the count of SSCHs
     - for EXCP Access it is whatever the Access Method programmer
       chose to pass to the IFASMFEX routine that updates the DD segment
       in the TIOT, and will be zero if IFASMFEX is not called from that
       I/O Driver.
    And, of course, there is nothing in the TIOT segment that indicates
    what access method was used for that DD!

    Especially when the Access Method is EXCP, the I/O coder may not
    even call IFASMFEX, since there is no requirement that he/she do so.
    This is why there are zero EXCPs for your //SORTWKnn DD's, whether
    you use SYNCSORT or DFSORT.

    Years ago, SYNCSORT published benchmarks in advertisements showing
    that their sort program performed many fewer I/Os than IBM's sort.
    I was asked by a third party to examine their veracity, and found
    that I/O counts existed only for //SORTIN and //SORTOUT DDs, and
    that SYNCSORT was passing the number of SIOs to IFASMFEX, while IBM
    was passing the (larger) number of Blocks/EXCPs to IFASMFEX.
    This caused SYNCSORT to have to "fess up", and they had to create a
    "Special Core ZAP" that allowed you to choose to count EXCPs rather
    than SIOs, because of the false impact on existing billing systems.

    With regard to IMS, I have a vague recollection that OSAM does not
    normally call IFASMFEX when I/O is performed, but, rather, only when
    IMS files were closed, and that that caused the EXCP count in RMF 72
    to only be updated at the "end of day", but I was unable to find any
    reference, and that may no longer be true.

 5. SYNCSORT Early Warning Notice EW5981-0 was required for z/OS 1.5 to
    resolve WER061A Equip Check (HDS DASD) ABEND 1188 RC 094B96104 error
    messages.

 4. A large number of IsUserInRole SMF 80 records are created with CA's
    Top Secret Security Product that are not errors. IBM APAR PQ96045
    eliminates these "false" SMF 80 AUDIT records, but CA fix BEA6729
    for Top Secret V5.2 is also required for their product.

 3. APAR OA08887 reports incorrect values in RMF 74.4 variables R744PNU,
    R744PBSY, and R744PWAI (MXG variables CFNUMnn,CFBUSYnn,CFWAITnn.

 2. As of z/OS 1.3, the Media Manager is used to do all I/O for the CAS
    (Catalog Address Space), causing the number of CAS I/Os to increase;
    before z/OS 1.3, CAS used VSAM to do Catalog I/O and the Media Mgr
    was only used for VVDS I/O, but VSAM specifically omitted the
    collection of StartIO or block counts when running under the CAS.
    So there really was no increase in I/O with z/OS 1.3, but rather a
    significant underreporting of CAS I/Os prior to 1.3.

 1. Striping enhancements to extended-format sequential datasets made in
    z/OS 1.5 now allow a maximum of 59 stripes, and thus 59 volumes, and
    so an extended-format striped sequential dataset now supports up to
    4GB of blocks (not bytes!).  Since each volume can have 123 extents,
    the dataset can have a maximum of 7257 extents.


IV.  DB2 Technical Notes.

  3.  DB2 APARs PQ91101, PQ86477, PQ85650, PQ87440, PQ87783, PQ87848,
      PQ88889, PQ90547, PQ91544, PQ73385, PQ74506, and PQ65302 all have
      references to IFCID 225 or 217, and without some (or maybe all?)
      of those APARs installed, enabling either (or both) of those DB2
      IFCIDs can corrupt data in all SMF 102 trace records.

  2.  My understanding of some DB2 objects; please correct if wrong:
        Plans can call packages.
        Packages can call stored procedures.
        Packages can be bound into collections.
        But not all packages call stored procedures, so there is no real
          relationship between the count of observations in DB2ACCTP
            (each obs in DB2ACCT is the execution of a package)
          and the value of QPACSPNS, the count of stored procedures that
            were called by that package execution.
          So in a DB2ACCTP observation, QPACSPNS is zero if the package
          did not call a stored procedure, or non-zero if it did.

  1.  If you run DB2 under "MVS" running as a VM guest when in z/Arch
      mode, Hiperpools will not function under DB2 without APAR PQ87231.

V.   IMS Technical Notes.

 1. APAR PQ65904 documents problems with excessive number of false IMS
    Scheduling Messages, each of which showed .01 CPU seconds in IMS 07
    Log records; these false schedules can be recognized by IBM field
    DLRGUMES (which is MXG variable CALLMSGU) being zero.

VI.  SAS Technical Notes.

 9. A comparison of SAS reading selected SMF records in one pass versus
    using IFASMFDP to first select and write out the desired subset of
    SMF data, and then SAS reading that subset appears to be a draw.
    An 8989 MegaByte SMF file with all SMF records was read by IFASMFDP
    selecting 30, 72, and 89 records, which totaled 3097 MB, which was
    then read with MXG's BUILDPDB (tailored to read only those records).
    IFASMFDP used 0.45 CPU minutes and 5.26 Elapsed minutes to read and
    write, and the BUILDPDB used 12.51 CPU minutes and 21.26 Elapsed min
    to read the 3GB file, for a two-step total of 12.96 CPU, 26.62 ET.
    BUILDPDB's 9GB read in one step took 13.26 CPU, 33.97 ET.  The two
    step job issued 334,076 EXCPS to the one step total of 101,724.

 8. Under ASCII platforms, if you want to see the actual statements in
    the autoexec file that is being executed, sas -echoauto will do it.

 7. Under SAS V9 on "MVS", new "+SAS processed" messages are printed on
    the SYSMSG log, which I find useful, but which are enabled by the
    option DLEXCPCOUNT, which I chose to enable in CONFIGV9, but which
    can be changed to NODLEXCPCOUNT if you really don't like them!

 6. Use of BUFNO=nnn, especially with large (200!) values of nnn, on the
    //PDB or //SPIN or //CICSTRAN SAS data library DDs has caused very
    strange out-of-memory errors, including SYSTEM ABEND 878-10, with no
    SAS messages on the log, and the ABEND occurred long after those DDs
    had been written to during the SMF-processing phase - the error was
    deep inside the RMFINTRV logic.  Remove the BUFNOs!!  Benchmarks run
    by Martin Kline at American Century show these results:

      BUFNO:      1000        100         20      DEFAULT       2
      IOTM       17:21      16:17       15:59      15:49      15:51
      Elapsed    34:13      30:29       30:22      33:35      32:36
      CPUTM      13:11      12:28       12:31      12:38      12:38
      CPUTCBTM   13:03      12:20       12:23      12:29      12:29
      TCB+IO     30:25      28:37       28:23      28:18      28:20

 5. The new V9 PROC MIGRATE can convert SAS V6, V7, or V8 data libraries
    to V9 format; the manual for the new procedure is available at
    support.sas.com/rnd/migration/resources/procmigrate/migratebook.html

 4. Yet another error in the Sequential Engine, this time in V6SEQ under
    V9.1, V9.1.2, and V9.1.3.  SAS Note SN-013514 has the hot fix.
    The error occurs when the V6SEQ engine under those V9 versions tried
    to read a SAS dataset that was sorted by more than 10 variables when
    it was created, and it causes this error message:
      ERROR: The format xxxx was not found or could not be loaded
       ('xxxx' is not a real format name, but typically unprintables).
    The original V6SEQ dataset can still be read with the V6SEQ engine
    in Version 8, so the dataset is not actually corrupt; it is only the
    the V6SEQ engine in SAS V9 that is broken and must be repaired with
    the hot fix, and then it can be read with SAS version 9's.

 3. Using SYNCSORT, ERROR: SORT DID NOT COMPLETE SUCCESSFULLY. SEE
    MESSAGES ON THE LOG.  HOST SORT CANNOT BE USED, along with Syncsort
    WER061A I/O ERR JOB,STEP,DC51,D,SASSWK02,**- OP, WRNG.LEN.RECORD,
    appears to have been caused by Syncsort adding dynamic SORTWKnn DDs.
    The job had 12 SORTWKnn DDs in the JCL, but the job log shows there
    were DELETED messages for SORTWK13 thru SORTWK22, indicating that
    SyncSort dynamically added 10 DDs.   The job failed half of the time
    but a rerun was successful.  Adding 10 SORTWKnn DDs to the job has
    apparently corrected the error.

 2. "ERROR LIBREF IS NOT IN A VALID FORMAT FOR ACCESS METHOD SASE7" if
    the library was externally allocated is discussed in SN-007759:
       If any of the following hot fixes have been installed:
         81BA50, 82BA57, 82BX01 (or its replacement),
       and a direct access bound library is allocated externally to SAS
       with DISP=OLD or DISP=SHER via JCL or TSO ALLOCATE command, and
       assigned by SAS more than once during the lifetime of the MVS
       allocation, any attempt to use the library after the reallocate
       will generate that error.
    The hot fix is available in that SAS note.

 1. New SAS Option ERRORBYABEND is not needed in MXG's CONFIGV9 member,
    because the ERRORABEND option already causes a USER 999 ABEND when
    a BY list is not in order.  It appears ERRORBYABEND was created for
    sites that ONLY want an abend on a bad BY list, when ERRORABEND was
    not desired.  The SAS default is NOERRORBYABEND.

VII. CICS Technical Notes.


VIII. Windows NT Technical Notes.


IX.   Incompatibilities and Installation of MXG 22.02.

 1. Incompatibilities introduced in MXG 22.10 (since MXG 21.21):
    See CHANGES.

 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.


X.    Online Documentation of MXG Software.

    MXG Documentation is now described in member DOCUMENT.


XI.   Changes Log

--------------------------Changes Log---------------------------------

 You MUST read each Change description to determine if a Change will
 impact your site. All changes have been made in this MXG Library.

 Member CHANGES always identifies the actual version and release of
 MXG Software that is contained in that library.

 The CHANGES selection on our homepage at http://www.MXG.com
 is always the most current information on MXG Software status,
 and is frequently updated.

 Important changes are also posted to the MXG-L ListServer, which is
 also described by a selection on the homepage.  Please subscribe.

 The actual code implementation of some changes in MXG SOURCLIB may be
 different than described in the change text (which might have printed
 only the critical part of the correction that need be made by users).

 Scan each source member named in any impacting change for any comments
 at the beginning of the member for additional documentation, since the
 documentation of new datasets, variables, validation status, and notes,
 are often found in comments in the source members.

Alphabetical list of important changes after MXG 21.21 now in MXG 22.xx:

  Dataset/
  Member   Change    Description

  See Member CHANGES or CHANGESS in your MXG Source Library, or
  on the homepage www.mxg.com.

Inverse chronological list of all Changes:

Changes 22.yyy thru 22.001 are contained in member CHANGES.

*********************NEWSLETTER FORTY-FIVE******************************




       MXG NEWSLETTER NUMBER FORTY-FIVE, August 25, 2004.

Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE

                         TABLE OF CONTENTS

I.    MXG Software Version.
II.   MXG Technical Notes
 8. MXG 22.08 or later required for full support of SAS V9.1.2/V9.1.3.
 7. MXG 22.04 or later is required to support all CICS/TS 2.3 SMF data.
 6. MXG 22.06 is required for DB2 Parallel
 5. If you are using IRD, you must install MXG 22.02 or later:
 4. Still OS/390?
 3. MXG Default Media is now changed to CD-ROM.
III.  MVS Technical Notes
33. What are IFA's?
32. Where does IFA CPU time show up:
IV.   DB2 Technical Notes.
 1. DB2 Accounting Discoveries, Jun 5, 2004:
V.    IMS Technical Notes.
VI.   SAS Technical Notes.
 1.            Impact of BUFNO option for SAS data sets
VII.  CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX.   Incompatibilities and Installation of MXG.
         See member CHANGES and member INSTALL.
X.    Online Documentation of MXG Software.
         See member DOCUMENT.
XI. Changes Log
     Alphabetical list of important changes
     Highlights of Changes  - See Member CHANGES.

      COPYRIGHT (C) 2004 MERRILL CONSULTANTS DALLAS TEXAS USA

I.   MXG Software Version 22.09 is now available upon request.

 1. Major enhancements added in MXG 22.09:

    See CHANGES member of MXG Source, or http://www.mxg.com/changes.

II.  MXG Technical Notes

 8. MXG 22.08 or later required for full support of SAS V9.1.2/V9.1.3.

    The good news:
    Most importantly, there are no data incompatibilities between V8 and
    V9.  Data libraries and catalogs built with V8 can be read and
    written with SAS V9, and libraries and catalogs built with V9 can be
    read and written with SAS V8.

    The bad news:

    MXG 22.08+ is required for safe execution with SAS V9.1.2 or V9.1.3.

    While MXG 22.07 had critical revisions for SAS 9.1.2, more design
    changes were discovered in V9.1.2 that required more MXG changes.
     Plus, using the PROC SYNCSORT add-on product caused fatal errors
     in BUILDPDB, because INFORMAT names were truncated with this error:
       ERROR: INFORMAT $NOT WAS NOT FOUND OR COULD NOT BE LOADED"
     See MXG Newsletter FORTY-FIVE, SAS Technical Note 12 for details.
     While SYNCSORT and SAS examined the error, MXG Change 22.192
     removed all MXG INFORMAT $NOTRAN statements, so MXG 22.08+ will not
     fail even without the ultimate fix from PROC SYNCSORT for SAS V9.
     - This error was only with the add-on product (it prints the text
       "PROC SYNCSORT" on SAS log);
     - There were no errors with Syncsort's SORT product itself).
     - SAS Institute has determined the error was in the SAS Toolkit and
       not actually in PROC SYNCSORT, see SAS Usage Note XX-yyyyyyy.
     - A new PROC SYNCSORT patch will ultimately be required, after they
       get the revised SAS Toolkit; Syncsort ticket number # SR387805
       refers to the problem.

    SUMMARY OF THE CRITICAL ACTIONS FOR YOU TO RUN MXG WITH SAS V9.1+:

     Install MXG 22.08, use MXGSASV9 and CONFIGV9 from 22.08, and

     Run UTILS2ER utility against all of your SAS programs to see
     if any lines conflict with S2=72 option that replaced S2=0
     option set by MXG previously.



    Details on Changes related to SAS V9.1.2 and MXG execution:

    a. CONFIGV9:
    NOTHREADS required for SAS V9.1.2, fixed in 9.1.3. Change 22.207.
     SAS Note SN-12943 reports incorrect results, no error message:
     PROC MEANS, SUMMARY, REPORT, TABULATE
     Only on "MVS", only if threading is used. V9 default is THREADS
     While fixed in 9.1.3, I chose to force NOTHREADS in CONFIGV9.
     Can use OPTIONS=THREADS with 9.1.3 on // EXEC to change.

    b. CONFIGV9:
     NLSCOMPATMODE is required for MXG code to execute worldwide;
     in V9, SAS changed their default to NONLSCOMPATMODE, but MXG
     overrides that in CONFIGV9 to the NLSCOMPATMODE that's required.
     Only on "MVS" (thus far!), doesn't fail if LOCALE is ENGLISH/blank
     But with LOCALE=GERMAN_GERMANY or other non-blank, or non-ENGLISH
       every @ symbol causes an error at compile time.
     Extensive discussion in text of Change 22.129 for NLS and LOCALE.
     Once MXG has built its SAS datasets, these text-handling options
     can be changed: in one case, exclamation marks and CRLF were not
     produced in ods output with MXG's NLSCOMPATMODE, but changing it
     back to SAS's NONLSCOMPATMODE default produced desired results.

    c. CONFIGV9:
    S2=0 option now required; MXG previously used S2=72 in CONFIGxx.
     Only on "MVS".  Extensive discussion in Change 22.123.
     S2 sets line size of source read by %INCLUDE or AUTOCALL.
     V9 MVS SASMACRO library was changed from RECFM=FB to RECFM=VB
       -no standard for line size of SAS-provided %macro text
       -new macros were written by ASCII folks, line length 255
       -Rather than make the authors correct, RECFM changed to VB.
     BUT: RECFM VB has entirely different meaning for S2 than FB.
       S2=72  FB ==> read only first 72.  VB: ==> START IN 72!!!!
     MXG had always specified S2=72 to protect you from line numbers
       S2=0  ==> look at last 8 columns to see if line numbers exist
     All MXG code is only 72 positions, so S2=0 is no-risk to MXG code.
     BUT: If you have SAS code with mixed blanks and numbers in 73-80,
          option S2=0 will cause your code to syntax error.
     So: New MXG UTILS2ER utility will read all of your source libraries
          and identify any exposures in your SAS programs.

    d. CONFIGV9:
    V6SEQ may still be required with SAS V9.1, V9.1.2
     Only on "MVS".  SN-012437 and Change 22.108 discuss.
     SAS V9.1 and V9.1.2 create corrupted and unreadable datasets
      with no error at create time, and data is unrecoverable,
      if V7SEQ, V8SEQ, or V9SEQ are used.
     SAS Hot Fix in SN-012437 does correct the error for V9.1/9.1.2
     BUT: I can't guarantee you have that hot-fix installed, so
     MXG SEQENGINE default was again set back to V6SEQ in 22.05.
        But: V6SEQ failed with long-length variables, so
             Change 22.108 shortened all MVS variables.
             MXG has had numerous iterations on SEQENGINE!
             Mostly because unnecessary compress was done to tape.

    e. MXGSASV9:
    MVS JCL Example has new symbolics for new SAS NLS/LOCALE options.
     XX='EN' - Default Language Value (ENGLISH)
     YY='W0' - Default Encode Value (USA)
      'DEW3' is for most GERMAN, but 'DEWB' is for SWIZTERLAND.
     You must look at the SAS JCL proc built by your SAS installer
     to find the correct XX and YY values, and then set them as
     your MXGSASV9 JCL Procedure defaults.  The symbolics in MXGSASV9:
       //CONFIG   DD  DSN= ... CNTL(BAT&YY.)
       //SASAUTOS DD  DSN= ...&YY..AUTOLIB
       //SASHELP  DD  DSN= ...&XX.&YY..SASHELP
       //         DD  DSN= ...EN&YY..SASHELP
       //SASMSG   DD  DSN= ...&XX.&YY..SASMSG
       //         DD  DSN= ...EN&YY..SASMSG
       New DD statements for TRNSHLP, ENCDHLP and TMKVSENV were added.

    f. ASCII-execution code change:
     EBCDIC character variables INPUT with $VARYING had hex zeros
       where they should have had blanks
       because of a SAS V9 Design Change in $VARYING informat.
     $VARYING always has returned a "raw" $CHAR string that must
       be converted if the string is EBCDIC text, using:
        INPUT VARIABLE $VARYINGnn. LENTEXT @;
        VARIABLE=INPUT(VARIABLE,$EBCDICnn.);
      but when LENTEXT was less than nn, the "pad" of '80'x was
      found on SAS ASCII platforms, so the statement
        VARIABLE=TRANSLATE(VARIABLE,' ','80'x);
      was added to translate the unexpected/undocumented '80'x.
      Now, also undocumented, in V9, the "pad" of '00'x is returned!
      So an additional
        VARIABLE=TRANSLATE(VARIABLE,' ','00'x);
      had to be added 511 times in 55 members.

 7. MXG 22.04 or later is required to support all CICS/TS 2.3 SMF data.

     MXG 21.04 supported UTILEXCL/IMACEXCL to read CICS/TS 2.3 SMF 110s,
      so if you used UTILEXCL to read your CICS/TS 2.3 Dictionary to
      create IMACEXCL, that IMACEXCL correctly read SMF 110 data.
     And if you had EXCLUDEd fields, you HAD to use UTILEXCL.
     But if you read SMF 110 records with MXG 21.04 thru 22.03, and all
      CICS fields were present, TASCPUTM and many other variables were
      completely wrong, and there were no error messages!
     MXG 22.04 or later supported full CICS/TS 2.3 records.
     You are still advised to use UTILEXCL/IMACEXCL, even with all data,
      as it only outputs CICSTRAN variables that exist in your CICS.
     My original CICS/TS 2.3 test data had EXCLUDEd fields!

 6. MXG 22.06 is required for DB2 Parallel

     CPU time for DB2 Parallel Trans was not output
      (i.e., lost, could be very large) in DB2ACCT.
     Code in MXG Exit Members EXDB2ACC/EXDB2ACP/EXDB2ACB
      deleted all obs with DB2PARTY='P', which was wrong
      because those obs contain the DB2TCBTM for parallel events.
     New DB2PARTY='R' for the Roll-Up observations also added.
     Extensive DB2 Technical Note in Newsletter FORTY-FIVE and
     additional documentation in Change 22.121 text.

 5. If you are using IRD, you must install MXG 22.02 or later:

    Full Support for IRD (Intelligent Resource Director) in all
    CPU-related datasets.  IRD support was incremental in MXG:
          Datasets            When        MXG Version  Change
        ASUM70PR/ASUMCEC   Sep 22, 2003     21.05      21.170
        TYPE70PR           Mar 11, 2004     22.01      22.011
        TYPE70,RMFINTRV    Mar 22, 2002     22.02      22.050

    PCTCPUBY in TYPE70 and RMFINTRV were wrong in any interval
     when IRD varied CPUs offline.
    I'm embarrassed, since PCTCPUBY is the second most important
    of all of the variables in MXG
      (CPUTM for billing is the most important);
    This is the first PCTCPUBY error in MXG's TWENTY-YEAR history!

    When all engines remained online, however, there was no error.

 4. Still OS/390?

  MXG 22.07 is required for z890 and 21.04 for z990s.
  IBM changed CPUTYPE value
    z990 - 2084x
    z890 - 2086x
  Only impacts MSU variables that MXG had to set via
    a table lookup based on CPU TYPE for OS/390.
  With z/OS, MSU fields are in the SMF records so there
    is no table lookup required.

 3. MXG Default Media is now changed to CD-ROM.

    I have changed the default media for MXG Software Shipments from
    a 3480 tape cart (which contains a single 120MB EBCDIC text file),
    to a CD-ROM (contains same EBCDIC file; upload-as-binary to MVS, and
    read it with IEBUPDTE like a tape to create your MXG SOURCLIB PDS).

    And the CD-ROM also has MXG Source in ASCII files, so for ASCII MXG
    execution, or to view the MXG source text on your workstation, you
    only have to copy the CD-ROM to your workstation's hard drive.

    However, still better than any media shipment, is for you to use ftp
    to download the 120 MB unzipped EBCDIC file for MVS execution, or
    the 15 MB zipped ASCII directory for workstation execution of MXG.
    The 120 MB unzipped EBCDIC file download takes about 15 minutes on
    a typical mainframe connection with a T1 line.

    But, if it is simply impossible for you to download via ftp, and you
    still cannot read/upload from a CD-ROM, I will continue to send 3480
    tapes until your site can upgrade its technology and media support.

    Annual Shipment (typically, in February of each year:
    - Since you never know when the Annual Version will arrive, I plan
      to automatically ship a CD-ROM to all MXG sites (and to ITSV sites
      that have requested the Annual Shipment), even to sites that can
      ftp download, so I know everyone has the current version.  Sites
      that still have to have a 3480 tape will need to request a tape,
      but with that CD in hand next February, they may discover they
      really don't need to wait for a tape to install the new version!
    - Concurrent with the Annual Shipment, I post to MXG-L and ITSV-L
      that ftp-capable sites can request ftp instructions via email, as
      I'm not yet prepared to database email addresses for auto send!

    Current Version Shipment requests:
    - Use the form   http://www.mxg.com/ship_current_version  to request
      the current version via ftp and you will receive ftp instructions
      in a reply email (example instructions are in that page), or, use
      it to request shipment on CD-rom, or you can use the form even to
      request 3480 shipment, if your site is both ftp and cd challenged.

    Problems solved by CD-ROM:

    - Firewall issues that prevent ftp download, internet restrictions.
      You really should fix that internal issue to get download access
      to our ftp site (text-only-files!), so you don't have to wait and
      I don't have to creating, packaging and send ad hoc packages.
    - Onerous Tape Mount Procedures, like Security and LABEL=NL issues:
        One site's "IEBUPDTE" job was cancelled after 17 hours, because
        the tape librarian had copied the NL tape to an Standard Label
        tape, but changed BLKSIZE from 32720 to 80!  When correct 32720
        blocksize was used, the IEBUPDTE job took less than 1 minute.
    - Rare tape read errors, which cause additional delays.  The annual
      shipment outsourcer's old 3480/3490 drives built three carts with
      Data Checks (DCK error) and two blank carts (NCA error).
        The 3480's created for ad hoc shipments on my Overland drive
        have never caused a Data Check, but I have carelessly sent out
        one or two blanks every year.  Overland no longer supports their
        auto-loader, so I only have a single-loader as backup for the
        auto-loader's eventual failure.
    - Cannot create 3590 media.  Overland doesn't manufacture one; even
      if they did, I'd never buy one, with ftp and CD-ROM alternatives.
    - Character translation, like dollar-signs versus pound-signs in UK.
      CD-ROM has separate EBCDIC and ASCII files for binary transfer.
    - Shipment advantages when media is required.
      - Thinner Package, CD much cheaper than 3480 cart (unless you buy
        "new" tapes from e-Bay, but those may be "lifted" new tapes)
      - Annual Shipment outsourcer is really primarily a CD maker.
      - Customs advantage - less hassles on CDs containing print matter,
         as cart's have caused custom's delays in some countries.
      - CD-ROM has MXG Logo, tapes have a paper label.

    Potential Negative Advantages of CD-ROM.

    - Scratched CD:
      We've been shipping MXG on CD for four years, and all CD-s have
      been read without error.  Even one CD that was run over with a
      fork-lift (tire print on package), shattered jewel case, but the
      CD had been read without an error.
    - Blank CD:
      Like carts, I screw up; I have sent 4 blanks in 4 years.  CD's are
      packaged inside a thin jewel case, wrapped in an envelope in a
      White Stayflat cardboard shipping envelope.
    - But CDs do eliminate the opportunity to meet/date your company's
      tape librarian and/or the tape apes.

 2. FLASH: Do NOT use SEQENGINE=V7SEQ, V8SEQ, or V9SEQ under SAS V9.1,
    until you have installed V9.1 Hot Fix for SAS Note SN-012437, which
    should be available May 24, 2004.  And this is NOT just an MXG/ITRM
    problem: all SAS datasets built by those SEQENGINEs under V9.1, both
    those written/copied to tape, or to DASD in sequential format, can
    be corrupted and unreadable and unrecoverable, with no error message
    when the dataset was created: ONLY when you attempt to read the data
    will you discover it is unreadable and the data lost.

    ONLY SEQENGINE=V6SEQ can be used under V9.1 on MVS, without hot fix.

    But, using V6SEQ with MXG under SAS V9.1 may create error messages,
    if you copy or write any of these datasets to tape or to sequential
    format on DASD (which is exactly what MONTHBLD/WEEKBLD may do):
        Product     Datasets
        TYPE80A     TYPE80EK  TYPE8XEK
        TYPE110     CICSJR    CICPGR
        TYPE120     TYP120JI  TYP120WA  TYP120WA  TYP120WI  TYP120WI
        IBM  SMSX   IGDACSSC  IGDACSSC  IGDACSSC
        TMON TMTC   TMTCIS
        CANDLE OMDB DB0035/0630/1920/2060/2080/2360/2571/3120/3140/3190
    because those datasets contain long-length character variables, but
    you do get error messages that prevent the creation of bad data, and
    none of those datasets are built/copied in the default BUILDPDB or
    WEEKBLD or MONTHBLD programs, so this should have minimal impact.
    However, MXG Version 22.05, revised those datasets so their
    variables are all 200 bytes or less, and you can install that 22.05
    and safely use SAS V9.1 with V6SEQ.  Complete details will be in
    Change 22.108 on or before May 24.

    The V7/V8/V9SEQ engines create damaged SAS datasets that can't be
    read, if the dataset has a "large" number of formatted variables.
      One case had 128 variables with the SAS-supplied hhmm  format,
      so it was not "MXG-created" formats that cause the corruption.
    And there is NO clue when the dataset was created that it can't be
    read later.  Only these read-time error messages tell you your data
    was destroyed:

      ERROR: The format xxxxx  was not found or could not be loaded.
        and that  xxxxx text contains strange, unprintable characters.

    And even if you copy the dataset with OPTIONS NOFMTERR, the copy is
    still unreadable; you then get these different error messages:

      ERROR:  Format xxxxx was not found or couldn't be loaded for
              variable vvvvvvvv.
      ERROR:  Format name for variable vvvvvvv was not a valid SAS
              name.  Perhaps the input dataset is corrupted.

    You MUST change CONFIGV9 so that it specifies SEQENGINE=V6SEQ.

    In MXG Source Library:
      - Thru MXG 20.07, CONFIGV9 had V6SEQ specified.
      - MXG 21.21 dated Feb 6 still had V6SEQ in CONFIGV9
                 (this was the Annual 3480 tape shipment build)
      - MXG 21.21 dated Feb 11 changed CONFIGV9 to specify V9SEQ,
                 due to Change 21.320, added after tape copy started;
                 (this was the CD-ROM shipment, and all ftp downloads).
      - MXG 22.01 thru MXG 22.04 still had SEQENGINE=V9SEQ.
      - MXG 22.05 and later now has V6SEQ, and that will remain for some
          time, to protect sites that did not install the Hot Fix.

    To the credit of SAS Institute Technical Support and Developers,
    it took only two weeks from discovery to a tested hot fix!

    And please note:  THERE IS NO ERROR USING V8SEQ WITH SAS V8.2.
    It is only execution under SAS V9 that has this error.

    In the discussion in Newsletter FORTY-FOUR, you can see I did do
    extensive benchmarking of the V9SEQ engine, but unfortunately, I
    was concerned only with the CPU costs of compression, and never
    attempted to read the datasets that were created.

    This FLASH was originally sent May 21, based on my read of an early
    copy of the SAS Note, and I concluded V8SEQ was safe for V9.1, but
    today SAS Technical Support (working on Saturday!) corrected me, so
    this note, dated May 22, 2004, does replace the earlier note; the
    error occurs with V7SEQ, V8SEQ, or V9SEQ under V9, without the fix.


 1. FLASH: BUILDPDB (only-under"MVS") runtime elongation can be
    significant IF any output libraries (like CICSTRAN or DB2ACCT) are
    on tape or in sequential format on DASD.
      This problem does NOT affect ITRM's normal job, because
      %CMPROCES/%CPPROCES puts everything in //WORK, and ITRM doesn't
      use tape libraries during its "BUILD".
    This problem was introduced in MXG 19.19, when %VGETENG was added in
    VMXGRMFI, to test if a //SPIN DD existed.  VMXGRMFI is called by
    RMFINTRV, which is automatically included in MXG's BUILDPDB.  If you
    do NOT use tapes for output in your BUILDPDB job, you don't have
    this problem.

    The PROC SQL with FROM DICTIONARY.MEMBERS in VGETENG gets the ENGINE
    of //SPIN, but no WHERE LIBNAME=SPIN clause was used, so the PROC
    SQL had to read all LIBNAMEs to populate the DICTIONARY.MEMBERS
    table.  If your CICSTRAN and DB2ACCT are both multi-volume on tape,
    you would have these mount messages on the BUILDPDB's job log:

                                              hh:mm-hh:mm
       SMF Opened, read started               14:25
       CICSTRAN  Mount-Dismount 5 vols        14:24-16:06
       DB2ACCT   Mount-Dismount 2 vols        14:24-15:25
       SMF Closed, read completed                   16:12
       VGETENG-remount/read 2 DB2ACCT vols    16:17-16:30
       VGETENG-remount/read 5 CICSTRAN vols   16:40-17:09
         Total Elapsed time:  164 minutes with re-read.

    VGETENG wasted 52 minutes, mounting and reading the seven tapes! For
    DASD data libraries, PROC SQL only has to read the directory of SAS
    datasets in that library, but for sequential format libraries, PROC
    SQL has to read the entire sequential file, because tape format
    libraries do not have a directory of datasets.

    And PROC SQL doesn't print any message on the SAS log to tell you it
    was the cause of the extra CICSTRAN & DB2ACCT mounts. The only clue
    to the elongation are those extra, and unexpected, tape mount
    messages on the job's SYSOUT!

    Elapsed and CPU time, and EXCPs of your daily job can be reduced
    significantly, if you use tape output on MVS in your BUILDPDB job,
    with either circumvention:


    Immediate circumvention, any of the three fixes:

      1. Replace MXG 21.21 with MXG 22.01, now available.
         See text of Change 22.017 for lots of details.

      2. Change the JCL:

         Add ,FREE=CLOSE to the //CICSTRAN and //DB2ACCT and to any
         other output DDs that are on tape/seq format.

      3. Or, change the MXG source code:

         a. EDIT/CREATE member EXPDBOUT in USERID.SOURCLIB tailoring
            library, and add a statement:
                 LIBNAME CICSTRAN CLEAR;
                 LIBNAME DB2ACCT  CLEAR;
            for each tape (or sequential format) DDNAME.

         b. Or do the same in your //SYSIN stream, using:

              //SYSIN DD *
                %LET MACKEEP=
                   %QUOTE(     LIBNAME CICSTRAN CLEAR;
                               LIBNAME DB2ACCT  CLEAR;
                         );
                %INCLUDE SOURCLIB(BUILDPDB);
                ....rest of job....

    Discussion of the circumventions:

    - Using FREE=CLOSE.  This appears to always be safe.  The FREE=CLOSE
      occurs when CICSTRAN/DB2ACCT/etc are closed, at the end of reading
      the SMF file, so PROC SQL in VMXGRMFI won't see those sequential
      LIBREFs so they won't be read.  But even if your job does then
      %INCLUDE any of the ASUMCICx, ASUMDB2A, or ASUMUOW members that
      read those data libraries, SAS is still able to re-open the LIBREF
      that was FREE=CLOSEd, without any error.  Like magic! And using
      FREE=CLOSE on //SMF DD seems always wise and courteous, so the
      device can be available to another.

    - Using LIBNAME xxxxxxxx CLEAR; in EXPDBOUT also appears to be
      completely safe.  EXPDBOUT is a little later than the close of the
      SMF file, after a few PROC SORTs, but the CLEAR closes the LIBNAME
      so PROC SQL in VMXGRMFI never sees those LIBNAMES to read, but the
      allocation can be re-opened, if, for example, you %INCLUDE any of
      the ASUMxxxx's that read DB2ACCT or CICSTRAN.

    - With either circumvention, harmless messages are on the SASLOG for
      each DDNAME, at deallocation time:
         NOTE: DATASET XYZ HAS NOT BEEN DEALLOCATED BECAUSE
               IT WAS ALLOCATED EXTERNALLY
         NOTE: LIBREF XYZ HAS BEEN DEASSIGNED

    - The circumventions do not have to be removed when you install an
      MXG Version with this change.

    - The choice of changing JCL or MXG source depends only on whichever
      is easier to do within your production change control system for
      your MXG daily jobs!


III. MVS Technical Notes.

44. APAR PQ92957 documents illegal User ABEND U5320 from BMC Backup
    Utility; the maximum User ABEND value is 4096.

43. APAR PQ92769 changes the format of SMF 118 records for the reply
    type; MXG change 22.212 supported that internal format change in the
    VMACTCP support.  The APAR also corrects blank value for data set
    type to the 'S' documented value, and changes the offset to HFS when
    there is no HFS data, which has no impact on anything I can see!

42. APAR PQ91647 corrects SMF 118 and 119 records so that they are now
    written when FILETYPE=JES and DELE command is issued to the FTP
    server.

41. APAR OW08447 reports that PrintWay Extended Mode does not write type
    6 SMF records unless an SMF6 exit (ANFUXSMF) was installed!  The PTF
    for this APAR seems to eliminate the need for the exit.

40. APAR OA08769 reports incorrect SMF 83 relocation section 01 after
    changing a SECLABEL on a data set profile.

39. APAR OA03292 corrects IEBGENER (!!!!!): when used to copy a PS SMF
    dataset with RECFM=VBS,LRECL=32767,BLKSIZE=27998
      (which, in my opinion, is flat out wrong; SMF data can only be
       validly written with LRECL=32760, and if the user had used that
       value, the APAR might not even exist; IBM accepts and corrects
       any case in which their records have LRECL GT 32760)
    to a PS-E striped output, the output dataset was twice as large as
    it should have been.  The APAR changes IEBGENER so that it will not
    copy the blocksize from the input dataset when the RECFM is NOT
    undefined or default, which will cause SDB to be tried.

38. APAR OA08719 corrects IFA CPU times that were incorrectly zeroed in
    SMF 30 step termination records.

37. Search www.ibm.com for IFA and you will find Integrated Fax Adapter
    for iSeries, and references to the IFA trade show, but no zAAPs!

36. Support for VSAM IMBED, REPLICATE and KEYRANGE attributes will be
    withdrawn beyond z/OS 1.7.  No supported release of OS/390 nor z/OS
    currently allows you to define new VSAM datasets with these
    attributes, and using them for existing data sets can waste DASD
    space and can often degrade performance; when support is withdrawn,
    you will not be able to process VSAM files with these attributes.

35. Effective with z/OS 1.7, support for ISAM datasets will be withdrawn
    and you will no longer be able to process ISAM datasets.  The ISAM
    Compatibility Interface remains available to help you migrate to
    VSAM without application changes.

34. IBM will remove support for STEPCAT and JOBCAT JCL statements in
    z/OS 1.7 (expected in September, l 2005), claiming there are other
    facilities in DFSMSdfp that allow catalog requests to be directed
    to specific catalogs, and the utility of these two JCL statements
    has been drastically reduced by the implementation of System Managed
    Storage and the placement of Unit Control Blocks UCBs above the 16MB
    line.  When STEPCAT/JOBCAT support is withdrawn, any remaining JCL
    using those two statements will have to be changed, or JCL errors
    will occur.

33. What are IFA's?

    For z/OS on z890s and z990s, IFA was the internal name of special
    purpose processors ("engines") that are now called zAAPs, for ZOS
    Attached Assist Processors, but all of the RMF/SMF field names use
    IFA; zAAP is the marketing name for these engines.  IFAs are engines
    that execute only Java code, and are not included in MSU capacity,
    so if you add new Java applications, or can offload current Java to
    an IFA, you can increase hardware capacity without any increase in
    software costs.  If you purchase IFAs, you can choose to force all
    of your Java workload to execute only on the IFAs, thus maximizing
    the offload of work from your CP engines, or you can let Java work
    execute on your CPs when they are not busy: if you let Java execute
    on your CPs, you can let it run at the priority of the Service Class
    or it can be run even lower than discretionary.  New keywords of
    IFACROSSOVER and IFAHONORPRIORITY let you choose how you use IFAs.

32. Where does IFA CPU time show up:

    - What's really important about this preliminary discussion is that
      it exists at all; IBM has been extremely pro-active, especially at
      the SHARE meeting in NYC in August, to provide early documentation
      of what's captured where, well in advance of the z/OS 1.6 delivery
      that is a prerequisite to use these new engines.  The following
      notes are based heavily on those SHARE presentations and follow up
      from IBMers, with additional valuable input from Cheryl Watson.

  a. Service Units.  In all records that contain Service Units, the TCB
     Service Units that formerly had only the service units due to TCB
     time on CP engines now includes SUs from both IFAs and on CPs.
     If you use Service Units for billing, your billing units may be
     increased when Java work runs on IFAs.
     Why did IBM include IFA service in TCB service?
     Because WLM manages based on service units; an all-Java workload
     would have zero TCB service units, could be using 100% of all IFAs,
     and WLM wouldn't know that, unless IFA service is included.

  b. SMF 30. Existing CPUTCBTM/SMF30CPT CPU time does NOT include IFA
     CPU time, so existing billing based on TCB CPU time will not change
     (but CPU time on IFAs will not be recovered unless you change your
     billing code).  New variable CPUIFATM is the CPU time on IFAs, so
     you can choose to charge IFA CPU time at a different rate than the
     CP CPU time, or you could add the CPUIFATM to the total CP CPU time
     in MXG's CPUTM variable to charge both CPU times at the same rate.
       While on the z990s the CPs and IFAs run at the same speed, on the
       z890s, the IFAs run at full speed (365MIPS) while the CPs have 28
       different "speeds", so the IFA CPU time are normalized back to
       the CP speed of the specific z890 model.

     MXG will NOT add the CPUIFATM into the existing CPUTM variable.

     MXG creates new variable CPUIFETM ('Eligible') that contains the
     part of CP CPU time in CPUTCBTM that was executed on a CP, but that
     was eligible to run on an IFA.  So even before you install an IFA,
     with z/OS 1.6 and Java SDK V1.4 you can measure exactly how much
     of your CP CPU time is Java time that could be offloaded to an IFA.
       The zAAP Projection Tool (WSC White Paper WP100431) can be used
       now on z/OS 1.4+ to estimate current CP CPU time for Java apps.
     These eight IFA-related CPU variables are created in type 30 data:
       CPUIFATM='TOTAL*EQUIVALENT*CPU TIME*ON*IFA'
       CPUDFATM='DEPENDENT*ENCLAVE*CPU TIME*ON IFA'
       CPUEFATM='INDEPENT*ENCLAVE*CPU TIME*ON IFA'
       CPUIFETM='IFA-ELIGIBLE*CPU TIME*ON*CP'
       CPUDFETM='IFA-ELIGIBLE*DEP ENCLAVE*CPU TIME*ON CP'
       CPUEFETM='IFA-ELIGIBLE*IND ENCLAVE*CPU TIME*ON CP'
       IFAUNITS='IFA-EQUIVALENT*CPU*SERVICE*UNITS'
       IFEUNITS='IFA-ELIGIBLE*CPU*SERVICE*UNITS'
     The original bad news in this Note (prior to MXG 22.11) stated:
        While IFA CPU time is available in SMF 30 data, the CPUCOEFF,
        SU_SEC, and R723NFFI (normalization) factors are NOT, so without
        a table lookup for those factors, you can't back out the IFA
        Service Units from the total IFA+CP Service Units in type 30s.
      However: IBM APAR OA09118 added the Service Definition Coefficient
      values, and Change 22.265 uses those values to back out the IFA
      CPU Service Units from the CP Service Units in CPUUNITS variable.
     Maybe bad news: There are concerns as to the repeatability of CPU
     metrics, especially since Java work can run on either IFAs or CPs
     when IFACROSSOVER=YES is specified, and additional concerns for the
     repeatability of the normalization factors on z890s.  Only when we
     have data from real sites running real Java work will we know the
     magnitude of these concerns.
     The good news:  since so few sites are actually running much Java
     on their current z/OS systems, these future concerns won't impact
     your current chargeback, and you will be able to benchmark and
     measure your work's repeatability before IFAs are in production.

  c. SMF 70.  TYPE70 MVS System data flags each CPU, so new IFATYP0-X
     variables indicates whether an engine is a CP or an IFA.  The MXG
     PCTCPUBY calculation and related capacity metrics will still be
     based ONLY on the CP engines, as has always been the case.  New
     PCTIFABY calculation and related IFA capacity metrics are added
     to TYPE70 dataset so IFA capacity can also be tracked, separately.
     The IBM RMF CPU Activity report shows separate lines and averages
     for the CPs and the IFAs.
       SMF70IFA='NUMBER OF*IFA PROCESSORS*ONLINE' (IBM provided)
       NRIFAS  ='NUMBER OF*IFA*ENGINES*AVAILABLE' (MXG count)
       IFAAVAIL='IFA*PROCESSOR*AVAILABLE?'
       IFACROSS='IFA*CROSSOVER?'
       IFAHONPR='IFA*HONOR*PRIORITY?'
       IFAACTTM='IFA ENGINE*EXECUTING*(ACTIVE) CPU TIME'
       IFAUPTM ='IFA ENGINE*AVAILABLE*(UP) TIME'
       PCTIFABY='ALL IFAS*PERCENT*BUSY (DISPATCHED)'
       PCTIFBY0-PCTIFBYX='IFA 0*PERCENT*BUSY' (each engine thru IFA 32)
       IFATYP0-IFATYPX='IFA OR CP*TYPE*CPU 0' (each engine thru IFA 32)
       IFAWAIT0-IFAWAITX='IFA WAIT*DURATION*IFA 0' (each thru IFA 32)

  d. SMF 70 for PR/SM.
       TYPE70PR PR/SM LPAR dataset contains observations for all engines
       including CPs, ICFs, IFLs, and IFAs, and starting with the z9,
       variable SMF70CIN identifies the type of engine.  The LCPUPDTM is
       the "CPU" time (Partition Dispatch Time) on that type of engine.
       For analysis of Linux IFLs and Integrated Coupling Facility ICFs,
       you must use the detail TYPE70PR dataset, and select based either
       on SMF70CIN if it is populated or LPARNAME.  However, Dedicated
       IFLs always report 100% utilization in RMF TYPE70PR/ASUM70PR.
       See NEWSLTRS article in Newsletter FIFTY-EIGHT titled
        "1. MONWRITE data from 2 z/VM" since MONWRITE must be used.

       But for your "MVS" PR/SM metrics, I strongly recommend that you
       use the summary datasets, ASUM70PR, ASUM70LP, ASUMCEC, ASUMCELP,
       which have always used the "CP" engine LCPUPDTM to populate the
       "MVS" CPU variables, and now has new "IFA" variables from their
       "IFA" engine observations in TYPE70PR.   And using these ASUMs,
       rather than your own TYPE70PR summarization means you won't have
       to modify it for frequent changes in these data; let MXG do it!

  e. SMF 72.  CPU TCB Service Units, raw R723CCPU/CPUUNITS contains sum
     of IFA + CP Service Units, and CPUUNITS is used to calculate the
     CPUTCBTM.  HOWEVER: MXG variable CPUTCBTM will contain ONLY the CP
     CPU time, and CPUUNITS will contain ONLY the CP Service Units, so
     existing CP capacity metrics and Capture Ratio will be accurately
     preserved (by subtracting the new CPUIFATM variable with IFA CP CPU
     time after CPUTCBTM is calculated from CPUUNITS, and by subtracting
     new IFAUNITS, IFA Service Units, from CPUUNITS).  The IFA timings
     of CPUIFATM (CPU time on IFA) and CPUIFETM (CP CPU time that was
     eligible to run on an IFA), and the corresponding IFA service units
     in IFAUNITS and IFEUNITS exist so IFA use and eligible capacity can
     be measured and tracked for each service class period.
     The bad news: The RMF Workload Report now shows CP+IFA times in the
     "TCB" line, which will no longer match the CPUTCBTM in MXG; the RMF
     report does have a new line with "IFA" CPU time R723IFAT/CPUIFATM,
     and APPL% CP, APPL% IFACP, and APPL% IFA percentages are reported.
       Note: The CPUIFATM and CPUIFETM times are actually converted from
             R723IFAT(IFAUNITS) and R723IFCT(IFEUNITS) service units
             using the new R723NFFI normalization factor.
     These IFA-related variables are created in the TYPE72GO dataset:
       R723NFFI='*NORMALIZATION*FACTOR*FOR IFA*TIMES'
       R723IFAU='IFA*USING*SAMPLES'
       R723IFEU='IFA-ELIGIBLE*ON CP*USING SAMPLES'
       R723IFAD='IFA*DELAY*SAMPLES'
       CPUIFATM='IFA*CPU TIME*ON IFA'
       CPUIFETM='IFA-ELIGIBLE*ON CP*CPU TIME'
       IFAUNITS='IFA*CPU*SERVICE*UNITS'
       IFEUNITS='CP*IFA*ELIGIBLE*SERVICE*UNITS'
     The calculation of Velocity may need to be changed in MXG, but only
     when data exists so that the using/delay samples are better known.

  f. SDSF display.  JOB-level data for CPU% includes both CP and IFA CPU
     percent, but a new IFA CPU column will eventually be added.
     The Bad News:  The CPU percent busy field in the top line of the
     display DOES (incorrectly?) include IFAs in the denominator, so a
     two-CP one-IFA system with 100% in both CPs and 0% in the IFA
     displays CPU Busy of 66% on SDSF, because the capacity was based on
     three total engines, not the two CP engines.
       Unrelated to IFA, but it was just observed that the JOB %CPU
       includes the "Initiator" CPU time (CPITCBTM/CPISRBTM see ADOC30),
       the CPU time before your program actually starts executing, so
       you might see CPU time while watching a job start to run, but the
       CPU time in the IEF374I message could be zero; only "standard"
       program TCB/SRB time is shown in that message.  The "initiator"
       TCB/SRB time is only captured in the SMF 30 subtype 4 records.
      -z/OS 1.12 message IEF032I/33I replaced IEF374I/276I.

  g. IEF374I step term and IEF376I job term log messages contain the sum
     of CP and IFA CPU time, but IBM intends to either add a separate
     IFA CPU time value, or more likely a new IEFnnnI log message.

  h. CICS TASCPUTM already includes the J9 Java TCB's CPU time, which is
     also separately available in the J9CPUTTM variable, but that is the
     total Java CPU time, so we can't tell how much was on a CP and how
     much was on an IFA at the transaction level.  You will have the SMF
     30s for each CICS region, especially the interval records, to see
     how much time is CP, IFA, and/or IFA eligible, at the region level,
     and you may have to use those percentages in your chargeback code.

  i. IMS Message CPU time - unconfirmed, but it is expected that the IMS
     07 log record contains both TCB and IFA CPU time.

31. APAR PQ89007 appears to state that SMF120NCS never should have been
    created.

30. APAR PQ91625 reports SMF 119 can have a blank member name if a PDS
    member is renamed during the ftp transfer.

29. APAR PQ91912 reports SMF 120 subtype 3 incorrectly reports a large
    number of Heap Allocation Failures in SM120HIC.

28. APAR PQ92496 reports SMF 120 subtype 1 byte transferred fields are
    too small, and cites transfer of over 2 GigaBytes in a 2 minute
    interval (which is only 17MB/sec!) will cause the fields to wrap,
    producing very large or truncated numeric values.

27. APAR OA08065 corrects SMF6UIF (MXG variable LOCLINFO) to contain the
    value from JMRUSEID for PrintWay-creates SMF type 6 records; the
    previous value was from the PrintWay JOB's userid.

26. IFA CPU measurements are corrected by APAR OA08606, and APAR OA07320
    corrects WLM handling of IFAs.

25. IBM "Driver 55" for z990s and z890s has both a Hardware Model and
    a Software Model Number, but that driver change has no impact on RMF
    data nor on MXG software.  The CPUTYPE remains 2084x, the CPCMODEL
    is still 309 (the Software Model Number), and the Serial 0AC4DCx is
    unchanged; using the D M=CPU command shows both model numbers:
      CPC ND = 002084.B16.IBM.02.0000000AC4DC
      CPC SI = 2084.309.IBM.02.00000000000AC4DC

24. Differences between VSAM RLS Architecture and Performance and RLS is
    discussed in IBM Item RTA000172667, in answers to ten questions, and
    requests that you only ask one question per WWQ&A record, because
    "our funding is based on the number of records we respond to."!

23. Uncataloged datasets on SMS volumes can occur, as discussed in IBM
    Item RTA000039164, as a result of system failures, or an authorized
    program could have bypassed security and uncataloged them, or if you
    did a physical dump and restore of the volume: DFDSS/SDFSMSdss will
    restore a VSAM dataset in that case, but cannot catalog it and will
    give an ADR318I message to indicate that the data set "may" need to
    be cataloged (physical dumps do not preserve enough information
    about VSAM datasets to reconstruct the catalog entries).  The last
    reference date should be the uncatalog date, since on an SMS managed
    volume the catalog should be consulted every time the data set is
    accessed; MXG dataset TYPE6156 will identify who uncataloged the
    dataset.

22. APAR PQ86871 for Tivoli reports it incorrectly interpreted values
    greater than 2,147,483,683 as a negative value in SMF 100 records.

21. APAR PQ88991 report WebSphere SMF 120 records are inaccurate,
    sometimes, in subtype 5 and 6 J2EE interval and container subtypes,
    with incorrect average response time values, usually too high.

20. APAR PQ88997 report SMF 117 and SMF 118 records fail to get the
    HOSTNAME filled in, sometimes.

19. APAR OA04877 reports new subtype 8 of RMF type 74 record with link
    performance statistics.

18. APAR OA06367 reports that SMF 89 usage segments will be consolidated
    during interval processing, for each registered product, to correct
    the growth of Subpool 230, key 0, caused by the prior algorithm of
    keeping each and every segment for the life of the job.

17. APAR OA07251 reports that when specifying a RANGE of SMF records in
    SMFPRMxx, the subtypes can be misinterpreted so that you don't get
    the subtypes you expected.  SYS(TYPE(1,28:30(6))) in SMFPRMxx, but
    D SMF,O shows SYS(TYPE(1,28(6),30)), and the display is correct; all
    subtypes of SMF 30 are created, not just the subtype 6 expected.
    Circumvention: enumerate IDs with subtypes: SYS(TYPE(1,28:29,30(6)))

16. APAR OA07396 reports ABACKUP creates SMF Type 1 (not since MVT, when
    it was recorded system wait time, and poorly at that!), even though
    the site has SETSYS NOSMF was specified in APARB.

15. APAR OA06258 reports incorrect Switch ID in RMF FCD Report, and
    creates new bit in R747SPFL to identify a Cascaded Switch.

14. APAR OA07664 reports large number of SMF 80 when running an HTTP
    server, after the apply of OA04416; the massive increase records
    were for the 'PUBLIC" userid (surrogate).  Only circumvention now
    is to use IEFU83/IEFU84 to exclude those created by a surrogate
    userid.

13. APAR OA07737 reports that you cannot have an MVS SYSNAME in your
    SMFPRMxx member that has a first character numeric that is followed
    by any of these characters H,M,S,P,T in any of the remaining
    positions of the name, e.g., SYSNAME(9H99) is invalid.

12. APAR OA07706 subtly indicates IBM has always been wrong in SMF 30
    records SMF30TRR, MXG variable DIVRREAD, in that the value passed
    by DIV (Data In Virtual) to SMF is accumulated, and not a DELTA
    value.

11. OA06932 reports LSPACE ABEND738 if SMF 19 records are turned on, as
    LSPACE is issued for each DASD volume, one at a time, at SMF INIT.
    Long ago, we had problems with SMF 19, and with DCOLLECT or similar
    DASD management tools, there is no real value, and lots of real
    exposure if you permit SMF to write SMF 19 records.
    See also APAR OW45020 re both SMF 19 and SMF 69 LSPACE problems;
    SMFPRM of NOTYPE((69),(19) is recommended.

10. APAR OA07693 documents an ABEND90A in IEASMFDP, the SMF dump program
    if there are more than 8 output DD statements, "because the updated
    compiler requires updates on how some of the GETMAINs and FREEMAINs
    services are invoked".

9.  APAR OA06073 corrects error in IBM's DISPLAY STOR command, which had
    a slightly incorrect value for installed storage; the command showed
    a value of 384MB, but the sum of PVTPOOL and PVTFPFN was 386.9MB.

8.  APAR OW57651 caused extremely large values in CPU time for OMVS
    or USS tasks in Type 30 records; APAR OA06407 corrects those data
    as well as other SMF30 fields (like CPUUNITS, etc).

7.  APAR OA07041 corrects SMF30SQT, which was not populated correctly
    in the job termination record when the last step was flushed; the
    field was incorrectly zeroes in the subtype 4 and subtype 5 record.

6.  Discretionary work swapped out for an hour with low CPU utilization
    may be addressed in APAR OA07058 or OW50378, per MXG-L posts.

5.  Type 42 Subtype 21 (DELETE ALIAS) SMF records are only written if
    SMF type 14 and 15 are collected, and this is not documented!

4.  For z990s, APAR OA06346 is critical; without it installed, RMF will
    CPU-loop, if CRYPTO is specified in ERBRMF00, and of course CRYPTO
    is the default,  You can specify NOCRYPTO and re-cycle RMF to
    circumvent the RMF loop, but the APAR apparently is a full fix, with
    several PTFs to install. Mar 17, 2004.

3.  Yet another FICON APAR, OA04856, corrects DASD I/O calculations for
    connect and disconnect times in RMF 74s, and using and delay data in
    RMF 72s.

2.  APAR OW57679, June 2003, reported incorrect processing of channel
    subsystem for control unit queueing for FICON connections caused
    negative values for disconnect time.

1.  A second, unrelated APAR that messes with SMF 30 record fields, and
    in particular with SMF30SRV, is fixed in APAR OA06407.  This is in
    addition to APAR OA05542, reported in the previous MXG Newsletter.
    Blank values in SRVCLASS were corrected by this APAR.

IV.  DB2 Technical Notes.

2. DB2 Trace IFCIDs 316, 317, and 318 are documented in SG24-6418-00
   "The detailed information about the statement cache is only available
   to online monitor programs.  The information cannot be externalized
   to SMF or GTF, so it cannot be processed by a DB2 PM batch job."!!!

 1. DB2 Accounting Discoveries, Jun 5, 2004:

   DB2ACCT observations from DB2 Parallel "Rollup" Records, QWHCPARR='Y'
   have all been deleted since Change 19.027, by code in EXDB2ACC/ACP
   exits, back when duplicate DB2ACCT data was discovered and deleted.
   But that has changed in the last three years, and detail examination
   of current DB2 V6 and V7 data proves my decision to delete was wrong.
   MANY HOURS OF CPU TIME COULD HAVE BEEN MISSING IN DB2ACCT dataset.
      There are a number of IBM APARs, listed at the end of this note,
      that changed the contents of DB2ACCT parallel data records.


   a. A single DDF Unit of Work (NETSNAME UOWTIME) created 45 DB2ACCT
      records with QWHCPLAN QWHCAID QWHSLOCN QWHCCV QLACLOCN QWHCCN all
      the same values.  This UOW started at 21May 08:59 and ran until
      24May 18:07, three days later.  There were 11 groups of ACEs, with
      43 of 45 records written on the first day, from 08:59 to 12:48
      (and they included nine pairs of DB2 Parallel Origin/Parent "O"
      and Rollup "R" records, below).  Then at 14:11 on the 21st, the
      "serious" DB2 parallel event started, ran for 75 elapsed hours,
      ending at 18:07 on the 24th, and wrote one pair of parallel
      records, observations 44 and 45 in the below details of all 45
      DB2ACCT records from that UOW:

                                   REPORT ONE
                               UNIT OF WORK SUMMARY
        FOR SAME DDF QWHCPLAN QWHCAID QWHSLOCN QWHCCV QLACLOCN QWHCCN

       NETSNAME =GA0400FD..A508  UOWTIME=27APR2004:23:37:15.959288

                             Q         D    D  Q        Q  Q          Q
                   Q         W         B    B  W        W  X      E   W
                   W         H         2    2  A        A  M      L   H
                   A         S         T    P  C        C  A      A   S
                   C         S         C    A  P        P  X      P   W
O      A           B         T         B    R  C        A  D      S   S
b      C           S         C         T    T  N        C  E      T   E
s      E           C         K         M    Y  T        E  G      M   Q

           21MAY2004 1MAY2004
 1 141CC1C8 08:59:39 08:59:39.972   0:00:00 S  0 00000000  0  0:00:00 73
 2 141CC1C8 09:02:07 09:02:08.120   0:00:00 S  0 00000000  0  0:00:00 74

 3 141CA708 09:13:06 09:13:07.129   0:00:00 S  0 00000000  0  0:00:00 08
 4 141CA708 09:13:54 09:13:55.783   0:00:00 S  0 00000000  0  0:00:01 09

 5 0F7F3E38 09:51:38 09:51:38.338   0:00:00 S  0 00000000  0  0:00:00 90
 6 0F7F3E38 09:51:38 09:57:16.717   0:00:05 O 13 00000000 11  0:05:38 22
 7 0F7F3E38 09:57:16 09:57:16.717   0:00:14 R 13 0F7F3E38  .          23
 8 0F7F3E38 10:01:09 10:01:10.096   0:00:00 S  0 00000000  0  0:00:00 03

 9 141CB8C8 10:06:11 10:06:11.114   0:00:00 S  0 00000000  0  0:00:00 16
10 141CB8C8 10:06:11 10:10:01.715   0:00:03 O 13 00000000 11  0:03:50 33
11 141CB8C8 10:10:01 10:10:01.715   0:00:00 R 13 141CB8C8  .          34
12 141CB8C8 10:17:06 10:17:06.675   0:00:00 S  0 00000000  0  0:00:00 17
13 141CB8C8 10:17:06 10:18:19.075   0:00:02 O 13 00000000 11  0:01:12 19
14 141CB8C8 10:18:19 10:18:19.075   0:00:00 R 13 141CB8C8  .          20
15 141CB8C8 10:21:29 10:21:29.106   0:00:00 S  0 00000000  0  0:00:00 27
16 141CB8C8 10:21:29 10:23:02.009   0:00:02 O 15 00000000 11  0:01:32 28
17 141CB8C8 10:23:02 10:23:02.009   0:00:00 R 15 141CB8C8  .          29

18 0F7F6388 10:49:31 10:49:31.675   0:00:00 S  0 00000000  0  0:00:00 82
19 0F7F6388 10:50:17 10:53:21.605   0:00:02 O 13 00000000 11  0:03:03 86
20 0F7F6388 10:53:21 10:53:21.605   0:00:19 R 13 0F7F6388  .          87
21 0F7F6388 11:00:01 11:00:01.705   0:00:00 S  0 00000000  0  0:00:00 95
22 0F7F6388 11:00:07 11:01:07.192   0:00:15 S  0 00000000  0  0:00:59 98
23 0F7F6388 11:02:06 11:02:06.929   0:00:00 S  0 00000000  0  0:00:00 99
24 0F7F6388 11:02:17 11:04:08.340   0:00:23 S  0 00000000  0  0:01:50 02
25 0F7F6388 11:11:56 11:11:57.058   0:00:00 S  0 00000000  0  0:00:00 25

26 141C93B8 11:12:27 11:14:32.848   0:00:01 O 13 00000000 11  0:02:05 33
27 141C93B8 11:14:32 11:14:32.858   0:00:15 R 13 141C93B8  .          34

28 0F7F6388 11:14:57 11:14:57.769   0:00:00 S  0 00000000  0  0:00:00 35

29 141CC548 11:19:36 11:19:36.259   0:00:00 S  0 00000000  0  0:00:00 50
30 141CC548 11:19:52 11:20:33.852   0:00:00 O  2 00000000 11  0:00:41 53
31 141CC548 11:20:33 11:20:33.851   0:00:12 R  2 141CC548  .          54
32 141CC548 11:20:39 11:20:40.348   0:00:00 S  0 00000000  0  0:00:00 55

33 141CC708 11:21:52 11:21:53.536   0:00:00 S  0 00000000  0  0:00:00 58
34 141CC708 11:22:09 11:23:22.843   0:00:00 O 13 00000000 11  0:01:13 62
35 141CC708 11:23:22 11:23:22.841   0:00:12 R 13 141CC708  .          63
36 141CC708 11:23:31 11:23:32.136   0:00:00 S  0 00000000  0  0:00:00 64

37 141CC388 12:35:17 12:35:17.945   0:00:00 S  0 00000000  0  0:00:00 79
38 141CC388 12:37:50 12:37:51.791   0:00:00 S  0 00000000  0  0:00:00 92
39 141CC388 12:38:24 12:39:08.285   0:00:00 O 13 00000000 11  0:00:43 93
40 141CC388 12:39:08 12:39:08.285   0:00:07 R 13 141CC388  .          94
41 141CC388 12:54:03 12:54:03.458   0:00:00 S  0 00000000  0  0:00:00 41
42 141CC388 12:54:44 12:56:41.133   0:00:08 S  0 00000000  0  0:01:56 49
43 141CC388 12:58:40 13:00:55.932   0:00:08 S  0 00000000  0  0:02:15 73

44 10800A88 21MAY2004 24MAY2004
            14:11:41 18:07:45.923   0:00:00 O  6 00000000  6 75:56:04 91
45 10800A88 24MAY2004 24MAY2004
            18:07:45 18:07:45.922 188:40:38 R  6 10800A88  .          92

   Notes on this data, created with MXG 22.05 (prior to 22.121 fix):

   1. Each pair of DB2 Parallel records are now identified DB2PARTY
             DB2PARTY  Description     Set by
               'R'      Rollup         QWACPARR EQ 'Y'
               'P'      Parallel       QWACPACE GT '00000000'X, NOT PARR
               'O'      Parent/Orig    QWACPCNT GT 0 OR QXMAXDEG GT 0
               'S'      Sequential     None of the above
      and the data shows the "O" Parent record is written first in each
      pair and that is followed by the "R" Rollup record.

   2. The QWACBSC (Begin Datetime) in the Rollup record is not the start
      of the parallel event, but rather is the ending datetime value.

   3. The QWACESC (End Datetime) in the Rollup record is not even a date
      time, but in that record, is the total children elapsed time.

   4. The below examples show QWACESC from the raw record, but now, MXG
      sets QWACESC=QWHSSTCK, sets ELAPSTM=., and puts the children's
      elapsed time in new variable CHIELPTM.

   5. Essentially ALL of the DB2 Parallel CPU time (DB2TCBTM) is only in
      the rollup record of each pair (188 CPU hours in 75 elapsed hours
      in obs 44 and 45). And, yes, it was that QWHSPARR='Y' record that
      was the one that was NOT output in DB2ACCT until Change 22.121.

   6. The Rollup record is written after the Parent, in QWHSWMSG order,
      but the Rollup's QWHSSTCK can be slightly earlier (see OBS 44/54).

   7. The Rollup record DOES NOT contain "rolled up" values, as can be
      seen by comparing the Parent and Rollup Records, especially in the
      obs 44 and 45, for the fields that are documented in DSNWMSGS as
      supposedly "rolled-up", for example, the Buffer Pool counts in
      REPORT TWO which show values for Buffer Pool 1 in the Parent, but
      no BP 1 counts in the rollup record, and the BP 2,3 counts are
      only in the Rollup, so it appears all records are needed to
      account for the event:


                   REPORT TWO - ROLLUP FIELDS


 Obs  DB2PARTY  QXMAXDEG  QB1CGET  QB1CRIO  QB2CDPF    QB2CGET   QB2CLPF

  44     O          6       302       7         .             .     .
  45     R          .         .       .        29    1905773502     0

 Obs  QB2CRIO   QB2CSEQ    QB2CSIO   QB3CDPF  QB3CGET  QB3CRIO  QB3CSEQ

  44        .         .           .     .         .        .       .
  45  1947039  63565784  1847086248     7        89       64       0

 Obs  QB3CSIO  QB3CSWS  QTXACHG  QTXACLNO  QTXALOCK  QTXANPL  QTXAUNLK

  44      .       .        1         13       109       73        3
  45    117       0        6        460        18        0        6

 Obs  QWACABRT      QWACAJST  QWACARNE  QWACARNL  QWACARNR  QWACARNS

  44      1       0:00:00.04        14         0         0      2
  45      0     188:40:55.65   3894206  37604434  41181854      0

 Obs  QWACARNW       QWACASC      QWACAWTE      QWACAWTI      QWACAWTL

  44      0      75:56:04.46    0:00:03.29    0:00:00.06    0:00:00.00
  45      0     404:58:20.00    0:00:00.00    6:30:57.64    3:39:22.35

 Obs      QWACAWTR        QWACAWTW    QWACCOMM    QXMIAP

  44    0:00:00.00      0:00:00.00        0          0
  45   28:38:08.40      0:00:00.00        6          .


   7. Similarly, for the fields that are not documented as rolled up,
      different values exist in both records:


               REPORT THREE -  NON-ROLLUP FIELDS

 Obs DB2PARTY  QB2CPID  QB3CPID  QLACABRR  QLACBROW  QLACBTBF  QLACBYTR

  44    O         .        .         0         0         0        0
  45    R         1        2         0         0         0        0

 Obs QLACBYTS QLACCNVR QLACCOMR     QLACMDWT QLACMSGR QLACMSGS QLACROWS

  44    0         0        0      0:00:00.00     0        0        0
  45    0         0        0      0:00:00.00     0        0        0

 Obs QLACSQLR QLACTRNR QMDAASLN QMDASFLN QTXASUS QWACARNA     QWACASRB

  44     2        0       47        0       0        4      0:00:00.00
  45     2        0       47        0       0        5      0:00:00.00

 Obs     QWACAWFC      QWACBJST  QWACDSNS      QWACDSSE      QWACEJST

  44            .    0:00:16.68      .                .    0:00:16.72
  45            .    0:00:16.68      .                .  188:40:55.65

 Obs               QWACESC  QWACLRAB  QWACOCNS      QWACOCSE  QWACOTNS

  44 24MAY2004:18:07:45.92     0          .                .      .
  45 18JAN1900:06:58:20.00     0          .                .      .

 Obs     QWACOTSE                  QWACRINV                  QWACSLNS

  44            .    12:NORM:DEALLOCATE, NORMAL PROG TERM        .
  45            .    12:NORM:DEALLOCATE, NORMAL PROG TERM        .

 Obs     QWACSLSE     QWACSPCP QWACSUCV QWAXARNC QWAXARND     QWAXAWCL

  44            .   0:00:00.00  8217.77     .        .               .
  45            .   0:00:00.00  8217.77     .        .               .

 Obs     QWAXAWDR QWAXDSNS     QWAXDSSE QWAXOCNS     QWAXOCSE QWAXOTNS

  44            .     .               .     .               .     .
  45            .     .               .     .               .     .

 Obs     QWAXOTSE QWAXSLNS     QWAXSLSE   QWHCATYP   QXALTSEQ QXALTVW

  44            .     .               . 8:REMOTE UOW    302      7
  45            .     .               . 8:REMOTE UOW      .      .

 Obs QXCALL QXCASCDP QXCLOSE QXCON1 QXCON2 QXCRESEQ QXCRTAB QXDEGBUF

  44    0       0       0       0      0       0       0        0
  45    .       .       .       .      .       .       .        .

 Obs QXDEGCUR QXDELET QXDESC QXDROSEQ QXDRPTA QXFETCH QXINCRB QXINSRT

  44     0       0       0       0       0      283      0       0
  45     .       .       .       .       .        .      .       .

 Obs QXLOCK QXMSMIAP QXNORGRP QXOPEN QXPREP QXPRRESI QXREDGRP QXSELECT

  44    0       0        1       1      1       0        0        0
  45    .       .        .       .      .       .        .        .

 Obs QXSETCDG  QXSETCRL  QXSETHV  QXSETPTH  QXSETSQL  QXSTFND  QXSTNFND

  44     0         0        0         0         0        0         1
  45     .         .        .         .         .        .         .

 Obs QXTOTGRP    QXUPDTE

  44     1          0
  45     .          .

   8. And you can see from REPORT FOUR, most character variables in the
      two parallel observations are the same:


                   REPORT FOUR - CHARACTER VARIABLES


 Obs    JOB      PLAN    SYSTEM  THREADTY  TRAN  UOWIDCHR      QWDAXCQO

  44  BIGDB2JB DISTSERV   MVPQ    D:DBAT         225421404040
  45  BIGDB2JB DISTSERV   MVPQ    D:DBAT         225421404040

 Obs  QWHADSGN   QWHAMEMN   QWHCAID   QWHCCN      QWHCCV      QWHCEUID

  44                        BIGDB2JB  SERVER   CVODBC32.EXE   bigdb2jb
  45                        BIGDB2JB  SERVER   CVODBC32.EXE   bigdb2jb

 Obs    QWHCEUTX      QWHCEUWN    QWHCOPID    QWHCPLAN

  44  CVODBC32.EXE                BIGDB2JB    DISTSERV
  45  CVODBC32.EXE                BIGDB2JB    DISTSERV

 Obs  QWHCTOKN                                        QWHDCCNT

  44  47413034303046442E41353038000900225421404040      2020
  45  47413034303046442E41353038000900225421404040      2020

 Obs  QWHDLUNM  QWHDNETI  QWHDPRID   QWHDRQNM   QWHDSVNM  QWHDUNIQ

  44                      SQL07020  99.9.9.253            202020202020
  45                      SQL07020  99.9.9.253            202020202020

 Obs  QLACFLA1   QLACFLA2   QLACFLG1   QLACFLG2    QLACLOCN    QLACPRID

  44     Y                                        99.9.9.253   SQL07020
  45     Y                                        99.9.9.253   SQL07020

 Obs    QMDAAPPL    QMDAATID  QMDAAUTH  QMDACNAM  QMDACORR  QMDACTYP

  44  CVODBC32.EXE  bigdb2jb
  45  CVODBC32.EXE  bigdb2jb

 Obs  QMDALOCN   QMDALUNM   QMDANETN   QMDAPLAN   QMDAPLAT   QMDAPMOD

  44                                                 NT         0
  45                                                 NT         0

 Obs  QMDAPREL   QMDAPTYP   QMDAPVER   QTXAFLG1   QTXAILMT   QTXANRUN

  44     02      SQL:OS/2      07                    N          N
  45     02      SQL:OS/2      07                    N          N

 Obs  QTXARLID   QWACFLGS   QWACNID   QWACWLME    QLACLOCN    QLACPRID

  44               0003                MIMSVU    99.9.9.253   SQL07020
  45               0043                MIMSVU    99.9.9.253   SQL07020

 Obs    QMDAAPPL      QMDAATID    QMDAAUTH    QMDACNAM    QMDACORR

  44  CVODBC32.EXE    bigdb2jg
  45  CVODBC32.EXE    bigdb2jb

 Obs  QWHSACE    QWHSIID     QWHSISEQ  QWHSLOCN  QWHSLUCC  QWHSLUNM

  44 10800A88  3:ACCOUNTING    59326   DCBDBR1     0006      A508
  45 10800A88  3:ACCOUNTING    59327   DCBDBR1     0006      A508

 Obs QWHSLUUV      QWHSMTN QWHSNID  QWHSRELN         QWHSRMID

  44 040520225421 00000006 GA0400FD    6.1   1AX:ACCOUNT AND STATISTIC
  45 040520225421 00000006 GA0400FD    6.1   1AX:ACCOUNT AND STATISTIC

 Obs   QWHSSIID    QWHSSSID                QWHSSTCK  QWHSWSEQ  QWHSLUCN

  44 3:ACCOUNTING    DBR1    24MAY2004:18:07:45.923    46091       6
  45 3:ACCOUNTING    DBR1    24MAY2004:18:07:45.922    46092       6

   9. The bottom line:

      MXG Change 22.121, in MXG 22.06, as made these corrections to
      the MXG logic for processing DB2 parallel transactions:

      a. Variable DB2PARTY was previously set to "S" instead of "O", and
         the Rollup and Parallel records both had "P" instead of set to
         separate values.  This is the DB2PARTY definitions now:
           DB2PARTY  Description     Set by
             'O'      Parent/Orig    QWACPCNT GT 0 OR QXMAXDEG GT 0
             'R'      Rollup         QWACPARR EQ 'Y'
             'P'      Parallel       QWACPACE GT '00000000'X, NOT PARR
             'S'      Sequential     None of the above
           (Prior to this change, "O" obs were "S".  Both "R" and "P"
            were "P" and the "R" were deleted in the Exit members.)

      b. The exit members EXDB2ACC and EXDB2ACP no longer DELETE any
         observations, so datasets DB2ACCT/DB2ACCTP/DB2ACCTB will now
         contain one observations from each 101 SMF records.
            To see how much CPU time was lost from DB2ACCT, create your
            PDB.DB2ACCT with this change, and then use:
               PROC FREQ DATA=PDB.DB2ACCT;
               TABLES QWHSSSID*QWACBSC*DB2PARTY/NOROW NOCOL NOPERCENT;
               WEIGHT DB2TCBTM;
               FORMAT QWACBSC DATETIME9.;
            to tabulate the CPU seconds for each start date; note that
            the WEIGHT statement uses integer seconds, so any fractional
            DB2CPUTM won't be included, but this is a fast tabulation;
            you could PROC SORT and PROC MEANS if you need absolutes.

      c. ELAPSTM was always calculated only when the QWACESC end time is
         later than the QWACBSC begin time, and both were nonzero. In
         the preceding example, QWACESC is a duration, not a datetime,
         and APAR PQ41012 documents that it is now the elapsed time of
         the children, in the rollup record, so now, for DP2PARTY='R',
         QWACESC is set equal to QWHSSTCK, the record-write-timestamp,
         the original value of QWACESC is stored in CHIELPTM, but the
         ELAPSTM is set missing, as it could be misinterpreted.
         This does mean there will be an overlap of the BSC/ESC values
         in the two records written for the parallel event.

      d. There are numerous IBM PTFs that correct DB2 Parallel data:

             APAR    Last Change Date    Date Closed

                        yyyy mo dd        yyyy mo dd
             PQ22451    1999/03/02        1999/02/01
             PQ41012    2000/12/01        2000/11/14
             PQ45519    2001/05/02        2001/04/02
             PQ50538    2002/05/16        2001/10/03
             PQ78546    2003/12/02        2003/10/25
             PQ85650    2004/04/05        2004/03/23


V.   IMS Technical Notes.

 1. None.


VI.  SAS Technical Notes.

14. WRITE ACCESS DENIED can be caused, on "MVS", if you attempt to
    write to a SAS Data Library, but you have DISP=SHR; you must
    have exclusive DISP to write to a SAS Data Library (except that
    the SAS/SHARE product does permit writes).  The message can also
    because if the submitter of the job (RACFUSER) does not have the
    correct RACF/ACF2 access authority to write to the dataset, and
    this condition does NOT product any other RACF/ACF2 messages; you
    only get the SAS 999 ABEND and the DENIED message on the SAS log.

13. While MVS-S/390-z/OS and Windows platforms no longer use MEMSIZE,
    for unix and Linux platforms, there still is a MEMSIZE parameter
    that can cause out-of-memory errors.  The MEMSIZE value is normally
    set in the sasv8.cfg or sasv9.cfg configuration file, but it can
    also be set on the sas command (look at properties of the command to
    see if your SAS installer has put the limit there!).  SN-010731 SAS
    note documents that unix operating systems have limits on how large
    a process can grow, and while you may have several gigs of RAM on
    the system, increasing the value of the -MEMSIZE option might not be
    able to make additional memory available.  That note show limits of
    1, 2, or 3 gigabytes, but MXG rarely needs more than 64 MegaBytes.

12. ERROR: INFORMAT $NOT WAS NOT FOUND OR COULD NOT BE LOADED with SAS
    V9.1.2, only occurs with PROC SYNCSORT R2.3A BATCH 0423, the patch
    from Syncsort for that add-on for SAS Version 9.1.2, but the error
    was caused by an error in the SAS Toolkit product that Syncsort uses
    to create their product.  The error truncates INFORMAT names, the
    $NOTRAN informat was truncated to $NOT.  PROC SYNCSORT finishes with
    no error, but when the sorted dataset is read, the error occurs.
      Note: this error is ONLY with the add-on 'PROC SYNCSORT' product
      and does NOT occur when SyncSort is used as the Host Sort.
      To bypass PROC SYNCSORT add-on, remove the SyncSort DD statement
      in the //STEPLIB concatenation in your JCL procedure.
      (The Host Sort part of Syncsort is normally in the LINKLIST.)
      (Specifying SORTPGM=SAS is not sufficient to bypass PROC SYNCSORT;
       if the PROC SYNCSORT library in the //STEPLIB, it will be used
       even if SORTPGM=SAS is specified).
    However, MXG Change 22.192 removed all INFORMAT $NOTRAN statements,
    so MXG 22.08 or later can be used with PROC SYNCSORT, even without
    the ultimate fix that will have to come from Syncsort, after they
    get the fix to the SAS Toolkit software from SAS Institute.
    The Syncsort ticket number # SR387805 refers to the error.

11. ERROR: UNABLE TO ALLOCATE C TRANSIENT FILE may not be fatal with SAS
    Version 8, as the Transient Library for C Programs is only required
    in V8 if your job use TCP/IP functions (like ftp, email sockets).
    The SAS CONFIG member (named BATCH in SAS V8) options SASCTRANSLOC
    is probably pointing to an incorrect DSNAME to cause this error.
    Under SAS V9, the C Transient Library is required, but the Install
    of V9 forces it to be located correctly as part of the install.
    Since it is a SAS file specified thru their CONFIG, the option is
    NOT used in the MXG CONFIGV8/CONFIGV9 configuration overrides.
    Jul 28, 2004.

10. OPTIONS ERRORCHECK=STRICT; can cause an ABEND if you want one when
    you %INCLUDE SOURCLIB(xxx); and xxx does not exist.  I was unaware
    of the ERRORCHECK option.

9.  If you are using ODS HTML with the WIN device driver, your SAS
    session may hang.  Changing the device to GIF seems to correct.

8.  SAS Hot Fix C9BA050S addresses issues in SAS 9.1.2 on z/OS where SAS
    components on z/OS fail communications with TCP/IP; the particular
    failure occurred when an MVS job was trying to send a file via email
    and the EMAIL step would hang until timeout; the Hot Fix corrected.

7.  SAS note SN-010122 discusses "No MKLEs found ERROR: VM1319: The PCE
    address= and MEMORY= address= ....".  In the past, VM1319 was due
    to a virtual memory restriction (a MEMSIZE too small, or REGION= too
    small), but this error is also generated in Release 8.2 and 9.1 if
    you have a FILENAME statement with only one dataset name inside the
    parens:  FILENAME  TEST  ('xxxxx.yyyyyy.zzzz') DISP=SHR;
    You must remove the parens when there's only one dataset, but must
    have the parens when two or more datasets are to be concatenated.
    Under SAS 9.1 you also get additional clues:
         ERROR: Logical name assigned but not in current scope.
         ERROR: Error in the FILENAME statement.

6.  SAS Version 9 System EC6 ABEND can result when an OE segment is not
    defined for the user; all users in V9 must have an individual OE
    segment or a site default OE segment as noted in SAS Note SN=011960.
    SAS Note SN=001616 documents that the SAS/C transient library now
    requires an Open Edition (a/k/a OMVS) segment, so that each user has
    permission to use unix System Services, and how to define one.

5.  ERROR: SYSTEM ABEND 0C1 OCCURRED IN MODULE UNKNOWN AT LINE 284090224
    with TRACEBACK pointing to SASSORT module, resulted when the JCL had
    LOAD='OLD.SYNCSORT.LOADLIB', but the site no longer had SYNCSORT.
    Removing the JCL reference eliminated the 0C1 ABEND.  11Jun2004.

4.  SAS under unix still has a MEMSIZE parameter in the CONFIG file that
    limits memory; if there is no MEMSIZE parameter, it defaults to 64M,
    but that is NOT a guarantee; it is a request, but if there are many
    processes running, your SAS job may not be able to get the MEMSIZE
    that you requested, and there is no clue that the OUT OF MEMORY was
    due to too small a MEMSIZE, or because there was not enough memory
    available at the time your job started.  And unix processes hold on
    to all of the memory, so even though (in MXG's BUILDPDB), it is only
    the first DATA step that needs 64M, that memory is not freed for the
    many smaller steps (DATA and PROC) that follow.

3.  SAS 9.1 introduced an error if you have an eight-byte member name in
    a DD statement that is then %INCLUDEd:
       //YOURSTUF DD DISP=SHR,DSN=YOUR.SOURCE.LIBRARY(MEMBER00);
       //SYSIN DD *
        %INCLUDE YOURSTUF;
    SAS fails with these errors in the SAS log:
       ERROR: MEMBER NAME MEMBER00::F IS LONGER THAN 8 CHARACTERS
       ERROR: CANNOT OPEN %INCLUDE FILE DDNAME
    You can remove the member name from your JCL, and change your input
    source to use  %INCLUDE YOURSTUF(MEMBER00);, but the error is fixed
    in SAS 9.1 TSLEVEL 1M2, and a hot fix for 9.1 is available at
      www.sas.com/techsup/download/hotfix/b9 sbcs prod list.html#012075
    (or, for sites using Asian Language (DBCS) Support, download from:
      www.sas.com/techsup/download/hotfix/b9 dbcs prod list.html#012075

2.  SAS Version 9.1 requires ENTRY=SAS instead of ENTRY=SASHOST, which
    was the entry point for SAS Version 8.  If you use the old MXGSASV8
    JCL procedure and/or ENTRY=SASHOST with SAS Version 9.1+, your job
    will die with an 0C4 ABEND with Reason Code 00000011.  Instead, use
    the MXGSASV9 JCL Procedure example with V9+. 27Apr2004.
    Apr 2007: Also, V8 SASXA1 is SASB (Non-LPA bundle configuration),
    and V8 SASXAL is SASLPA (LPA bundle configuration) as V9 entries.

 1.            Impact of BUFNO option for SAS data sets

Diane Eppestine and Jack Hudnall of SBC read the recommendation in a
book published by SAS Institute, "Tuning SAS Applications in the OS/390
and z/OS Environments" by Michael A. Raithel.  That book recommended
BUFNO=10, so they ran BUILPDB to measure the impact of changing BUFNO.

MXG Defaults have been BUFNO=2 and BLKSIZE=27648 (Half Track), as that
moves one track of data per SSCH, which my 1984 paper in ACHAP42 found
was optimal or near-optimal for all sequential I/O operations.

While SAS defaults now BUFNO=3 and BLKSIZE=6144, they chose to compare
the MXG Default BUFNO=2 with the proposed BUFNO=10, with BLKSIZEs of
both 6144 and 27648 (and found one run with BLKSIZE=MAX ended up with
actual BLKSIZE=4096, because SAS does not yet support superblocking):


JOB    BLKSIZE  BUFNO    EXCP     IOTM     VIRT      CPU      ELAPS
                         DASD     DASD     SIZE       SU      TIME
                                 mm:ss                        MM:SS
B        27648   10       8672   02:22.4    89M    4581623    10:31
A        27648    2      14102   02:30.0    79M    4604366    10:08
D        6144    10      16327   02:50.4    78M    4550875    10:25
E        4096    10      18228   02:55.6    77M    4567742    11:21
C        6144     2      29079   03:05.4    71M    4553833    11:04


          PDB    BLKS    CYLS      WORK    BLKS   CYLS     DATA BYTES
JOB    BLKSIZE   TRK     SIZE     BLKSIZE  TRK    SIZE      PER SSCH

B        27648    2      394       27648    2      599        276,480
A        27648    2      394       27648    2      592         52,296
D         6144    8      444        6144    8      663         61,440
E         4096   12      444        4096   12      661         40,960
C         6144    8      444        6144    8      657         12,288

The above comparisons above are sorted by IOTMDASD (I/O Connect Time).

But also note that this also sorts them by EXCPDASD, Region Size, and
almost by elapsed time, but especially they are also sorted by the
number of data-bytes per SSCH, which I still believe is the key.

The half-track runs (2:22 and 2:30) took 28-43 secs (20%-30%) less I/O
time than the runs with smaller blksize (2:50,2:55,3:05).  And between
half-track runs, increasing BUFNO from 2 to 10 saved only 8 I/O seconds;
it did also reduce the EXCP count from 14,102 to 8,678.  All of the
smaller BLKSIZE runs had appreciably more EXCP counts.

I was apprehensive that increasing BUFNO from 2 to 10 with half-track
would increase the Virtual Storage (REGION) size, and it did, from 79MB
with MXG's default to 89MB with BUFNO=10, as every output SAS dataset
required additional virtual storage for those extra buffers.  However,
10MB more REGION is not really a resource of concern at most sites, and
if REGION=0 specified, you don't have to change your Region Size!

The CPU Service Units are not quite in descending order, but the total
difference from maximum to minimum (4604366-4550875) is only 1 percent,
so changing BUFNO or BLKSIZE has minimum impact on the CPU time.

The last table shows the Size of the Output PDB and WORK libraries, and
reaffirms that half-track blksize reduces the size of those libraries.

In summary, the MXG Half-Track BLKSIZE with BUFNO=2 still seems a wise
choice; using BUFNO=10 saved very little I/O Connect Time, with no CPU
time savings; it reduced EXCP count by 40%, but especially with changing
BLKSIZEs, reducing EXCP counts result from reduced numbers of blocks in
the SAS data sets, but no savings in IOTM shows there was no real saving
in the amount of I/O that used your channels and disk devices.

But then Chuck Hopf benchmarked a larger SMF file (3275MB); his results
show similar modest reductions, except for EXCP counts:

       BUFNO   Elapsed    CPU     EXCPTOTL    IOTMTOTL  REGION
                mm:ss     mm:ss                mm:ss      MB

         2      38:52     18:40    113,824     12:36     79M
        10      34:59     18:27     78,331     12:24     88M

Because the 10MB increase in REGION size could cause a perfectly running
BUILDPDB to unnecessarily ABEND, I choose to leave the MXG default in
CONFIGV8 member of BUFNO=2, but you are free to change it!


VII. CICS Technical Notes.


VIII. Windows NT Technical Notes.


IX.   Incompatibilities and Installation of MXG 22.02.

 1. Incompatibilities introduced in MXG 22.01 (since MXG 21.21):
    See CHANGES.

 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.


X.    Online Documentation of MXG Software.

    MXG Documentation is now described in member DOCUMENT.


XI.   Changes Log

--------------------------Changes Log---------------------------------

 You MUST read each Change description to determine if a Change will
 impact your site. All changes have been made in this MXG Library.

 Member CHANGES always identifies the actual version and release of
 MXG Software that is contained in that library.

 The CHANGES selection on our homepage at http://www.MXG.com
 is always the most current information on MXG Software status,
 and is frequently updated.

 Important changes are also posted to the MXG-L ListServer, which is
 also described by a selection on the homepage.  Please subscribe.

 The actual code implementation of some changes in MXG SOURCLIB may be
 different than described in the change text (which might have printed
 only the critical part of the correction that need be made by users).

 Scan each source member named in any impacting change for any comments
 at the beginning of the member for additional documentation, since the
 documentation of new datasets, variables, validation status, and notes,
 are often found in comments in the source members.

Alphabetical list of important changes after MXG 20.20 now in MXG 21.xx:

  Dataset/
  Member   Change    Description

  See Member CHANGES or CHANGESS in your MXG Source Library, or
  on the homepage www.mxg.com.

Inverse chronological list of all Changes:

Changes 22.yyy thru 22.001 are contained in member CHANGES.

****************NEWSLETTER FORTY-FOUR***********************************




    MXG NEWSLETTER NUMBER FORTY-FOUR, Feb 11, 2004.

Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE

                         TABLE OF CONTENTS                          Page

I.    MXG Software Version.
II.   MXG Technical Notes
III.  MVS Technical Notes
IV.   DB2 Technical Notes.
V.    IMS Technical Notes.
VI.   SAS Technical Notes.
VII.  CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX.   Incompatibilities and Installation of MXG.
         See member CHANGES and member INSTALL.
X.    Online Documentation of MXG Software.
         See member DOCUMENT.
XI. Changes Log
     Alphabetical list of important changes
     Highlights of Changes  - See Member CHANGES.

      COPYRIGHT (C) 2004 MERRILL CONSULTANTS DALLAS TEXAS USA

I.   MXG Software Version 21.21, the 2004 Annual Version, Feb 6, 2004,
     was mailed to all sites by Feb 13, 2004.

 1. Major enhancements added in MXG 21.21:

    See CHANGES member of MXG Source, or http://www.mxg.com/changes.

II.  MXG Technical Notes

 1. None.

III. MVS Technical Notes.

11. A closed ETR documents that SRVCLASS='SYSOTHER' can occur in SMF 30
    records, even when you have a Default Fall-Thru Service Class, if
    the SMF record is being written, i.e., if SMF requests the service
    class data from WLM, during a "Service Policy Activation".  During
    that event, WLM cannot return the valid service class name, so it
    is coded to return "SYSOTHER".  Working as Designed, no APAR.

10. APAR OA06350 discusses problems with WLM-managed Initiators that did
    not start for what appeared to be very long times.

 9. Erratic, large values for DEVCONTM and DEVDLYTM ('FFFFnnnn'x, in the
    RMF 74 record, IBM fields SMF74CNN and SMF74DVB, a result typical of
    a subtraction underflow error) were found when OA05197 and OA05589
    APARs were installed, but only for FICON connections, and only for
    random read tests.  Those APARs revised calculations of values in
    the RMF records, but their code changes have no impact on actual I/O
    performance.  With both APARs removed, the erratic large values in
    those two fields did go away, but the RMF numbers without the APARs
    showed cache hit response time increased and thruput reduced, so the
    APARs were re-installed, large values discarded while IBM works on
    the problem, and the numbers with the APARs presumed more correct.

    Jan 27, 2004: IBM has PE'd APAR OA05197 with new APAR OA06168 which
    acknowledges an RMF coding error is the cause of negative values for
    FICON, and the PTF for OA06168 should correct the error.
    Feb 16, 2004: APARs OA05197+ was installed and fixed the error.

    But the changes in how FICON connect time is measured with and with
    out the APAR is discussed in the text of OA05589:
      Because of the multiplexing capability built into fiber channel
      and FICON, physical disconnection during execution of a channel
      program is rare.  Control Unit queue time is accumulated during
      connect time and not disconnect time, as was the case with ESCON.
      The RMF device activity reporting has to be changed to reflect
      this difference from ESCON.  Affected RMF releases: OS/390-2.10 up
      to z/OS-1.5
      With this APAR OA05589 RMF device activity reporting will be
      changed for FICON attached devices as following:
        CU queuing time is now subtracted from Connect time and no
        longer from Disconnect time.
      For ESCON attached devices the calculation for connect and
      disconnect time remain unchanged:
         CU queuing time is subtracted from Disconnect time.

 8. APAR OA04323 has no impact on MXG Software; it increased the number
    of channels to 512, which caused some system monitor programs to
    fail because they had internal tables that were too small.

 7. APAR OA05542 reports large values in SMF30SRV, ACTIVETM, SMF30PSF.
    See also APAR OW53698 for IOUNITS and SERVUNIT errors.

 6. APAR PQ82309 reports growth in the Subpool 230 Protect Key 0 virtual
    storage when using MULC and creating SMF 89 records. 01Jan04.

 5. APAR PQ81716 reports incorrect SMF 119 End Time Stamp for TN3270
    sessions that start before midnight UTC and end after midnight UTC.
    01Jan04.

 4. APAR OA06009 reports SMF 64 fields SMF64RIO, SMF64BMH and SMF64CFH
    are not being updated while running RLS. 1Jan04

 3. How can you move SMF files between MVS Systems?

    a. XMIT/RECEIVE

    b. ftp data directly, to pre-allocated VBS file 'SMF.dest.name':

       MODE B
       TYPE E
       GET 'SMF.source.name' 'SMF.dest.name' (REPLACE

    c. TRSMAIN

       //PACKIT   EXEC PGM=TRSMAIN,PARM=PACK
       //* PGM=TRSMAIN is an alias entry point for the new PGM=AMSTERSE,
       //* so you get the new features without having to change PGM=.
       //* And if you do change to PGM=AMSTERSE instead of PGM=TRSMAIN,
       //* you must ALSO change INFILE/OUTFILE ddnames to SYSUT1/SYSUT2
       //SYSPRINT DD   SYSOUT=*
       //INFILE   DD   DISP=SHR,DSN=input.smf.data
       //OUTFILE  DD   DISP=(,CATLG),UNIT=SYSDA,SPACE=(CYL,(20,10),RLSE)
       //       DSN=input.smf.data.packed
       //***********************************************************
       //FTPOSA   EXEC PGM=FTP,REGION=4M
       //INPUT  DD *
          domain.name.bla.bla
          userid
        < >
         bin
         put 'input.smf.data.packed' (replace
         QUIT
       /*
       //OUTPUT DD SYSOUT=*
       //SYSPRINT DD SYSOUT=*


     d. ftp as RECFM=U to PC, ftp PC file to MVS RECFM=U,BLKSIZE=32760,
        and then use MXG's UDEBLOCK utility to re-create the VBS records
        from the uploaded RECFM=U file.

 2. ABEND 0C9 in DFSORT (especially in SAS invoked sorts!!) is corrected
    by APAR PQ80787.  The ABEND is in ICEKPUT at X'1230' when E33 Exit
    is used (and SAS uses that exit).  Nov 20, 2003.

 1. Type 42 Subtype 21 (DELETE ALIAS) SMF records are not written if you
    have CA's PDSMAN product, and you have FASTSTOW=Y (i.e., FAST STOW
    option of PDSMAN is enabled).  The deletion 'feature' is not yet in
    the PDSMAN documentation for FASTSTOW option, but it was CA support
    that recommended disabling FASTSTOW so the SMF records are written.
    Nov 19, 2003.

IV.  DB2 Technical Notes.

 3.  Another source of negative DB2TCBTM is noted in APAR PQ83772, is
     "INCORRECT TIME IN QWACEJST WITH ACCOUNTING TRACE CLASS 2 OFF".
     Turning on DB2 Accounting Trace Class 2 on corrected the problem.
     The problem reportedly only occurs with CICS/TS 2.2.  17Feb04.

 2.  APAR PQ79622 corrects error that caused QWACBJST to be greater than
     QWACEJST, which caused negative DB2TCBTM.  The error occurred when
     an SQL statement fired a trigger and that trigger called either a
     UDF or a stored procedure, that class 1 non-nested CPU time could
     erroneously be a negative value.

 1. The DB2PM product statistics reports did not correctly deaccumulate
    buffer pool activity in intervals in which a Buffer Pool was skipped
    (where that Buffer Pool had had activity in the previous interval).
    MXG properly deaccumulated across the missed intervals, and IBM's
    DB2PM has accepted the error in APAR PQ81241. PTF issued 4Mar2004.


V.   IMS Technical Notes.

 1. None.


VI.  SAS Technical Notes.

 5. MXG has added long-length variables to some datasets, which cause
     ERROR: THE CHARACTER VARIABLE xxxxxxxx HAS TOO LONG A VALUE ....
     ERROR: FILE DDNAME.yyyyyyyy.DATA HAS NOT BEEN SAVED BECAUSE COPY
            COULD NOT BE COMPLETED
    when you PROC COPY any of those datasets from a V8/V9 data library
    to a V6 data library (like your daily DISP=OLD PDB data library
    build years ago with SAS V6).
    If DDNAME points to a disk data library, then you must create a new
    data library under V8/V9 and use PROC COPY IN=OLD OUT=NEW MT=DATA;
    to preserve the existing datasets
    If DDNAME is a tape data library, see the next technical note, 4.

 4. SAS Version 9.1 (TS1M0) had been tested by MXG under Windows, Linux,
    and z/OS versions of SAS, with no real problems or errors, and with
    only positive execution results; there is either equal or slightly
    better performance (Elapsed, CPU) with V 9.1.

     A. Feb 11, 2004: FLASH: MXG default changed to V8SEQ or V9SEQ.

        Please replace V6SEQ in CONFIGV8/CONFIGV9 with V8SEQ/V9SEQ, to
        be completely safe and avoid potential errors.

        In the Feb 6, 2004 (first) MXG 21.21 code and in the Newsletter
        FORTY-FOUR that was in NEWSLTRS member, MXG still used the
        SEQENGINE=V6SEQ option, because it saved some CPU time by not
        compressing when datasets were written/copied to tape.  But I
        had failed to test PROC COPY to tape with all MXG datasets, and
        today discovered that copying some datasets would fail with
         ERROR: THE CHARACTER VARIABLE EKC80FRD HAS TOO LONG A VALUE....
         ERROR: FILE TUE.TYPE8XEK.DATA HAS NOT BEEN SAVED BECAUSE COPY..
        if the MXG dataset contains long-length variables.  Only a few
        MXG datasets, built under SAS V8/V9 have long-length variables,
        but for long text strings, like SQL text, it is the right thing
        to do (the alternative: break text into 200 byte chunks!).

        So to avoid the errors, the MXG Sequential Engine default was
        changed in the Feb 11, 2004 edition of MXG 21.21.

        The original note in Feb 6 Newsletter, below, is technically
        correct as to why V6SEQ was originally used, but the additional
        CPU time for the "unnecessary" compression to IDRC tape drives
        is so small that I now wonder if I should have ever spent all
        this time/effort discussing it; for a 265 MegaByte file, the
        added CPU time was only 20 CPU seconds on a SU_SEC=10000 CPU!

        This is the original Technical Note in Feb 6, Newsletter:
        MXG still uses SEQENGINE=V6SEQ for SAS V 9.1 instead of V9SEQ,
        because the V9SEQ engine spends CPU time when PROC COPY to tape
        with COMPRESS=YES is used: since all MVS tape devices are IDRC
        hardware compressed, we don't want SAS to compress to tape.
        In SAS V9.1, the V9SEQ engine WAS changed for the DATA step,
        and SAS datasets written to tape in a DATA step are no longer
        compressed.  But there's nothing wrong with V6SEQ, and nothing
        new/needed in V9SEQ, and the V6SEQ engine has always not invoked
        SAS compression when writing to a tape device, so there is no
        reason to change MXG, and if I did, some site somewhere would
        see and investigate an avoidable CPU bump in their copy jobs.
           It turns out the real "culprit" isn't PROC COPY, per se, but
           the NOCLONE option of PROC COPY.  If we could change the text
           of every PROC COPY statement in source code (in MXG, and in
           all of your tailoring and personal libraries!), to add the
           NOCLONE option (assuming there's enough blank space on each
           line), we see that CPU time results with V9SEQ match V6SEQ.

     B. Condition Code (also called Return Code) value of 4 can be
        expected with MXG's BUILDPDB, because of
           WARNING: CHARACTER VARIABLE xxxxxxx LENGTH HAS BEEN SET.
        The warning now identifies the variable, and can't be avoided
        for JOBCLASS; JOBCLASS is $8 for JES3, but only $1 for JES2.
        READ: A PERFECTLY GOOD DAILY JOB WITH CC=0 WILL NOW HAVE CC=4.
        And if you use CA-7 for job control and it now expects RC=00,
        you'll need to change that in CA-7 before running under SAS 9.1.

        UPDATED: JAN 21, 2005:  MXG Change 22.365 has eliminated this
        Condition Code problem with SAS V9.  With MXG 22.22 or later,
        the JES2 default BUILDPDB will end with Condition Code of ZERO.

     C. Windows-only comparisons, XP on 3.2 GHz Processor, with disk
        copy speed: 8.7 MegaBytes/sec to same disk, 23.4 MB/sec to a
        second disk:

        Input SMF is 882 MegaByte "JOBS" (SMF 6s, 26s, 30s).

        1. BUILDPDB+ big PDB.DDSTATS + PDB.SMFINTRV, FULLSTATS:
                            V9.0 ET   V9.1 ET      V9.0 CPU   V9.1 CPU
           With Compress:    1910      2042         488         382
           No Compress       3143      3000         354         330

        2. BUILDPDB, no DDSTATS/SMFINTRV created:
                                      V9.1 ET     V9.1ET
                                      FULLSTATS   NOFULLSTATS
           With Compress:               278         264

        Observations:

         a.  COMPRESS=YES on Windows definitely reduces run time from
             large BUILDPDB run time of 50 minutes without, to only
             34 minutes, for one additional minute of CPU time.
         b.  FULLSTATS used to cause E.T increase, but not with 9.1;
             BUILDPDB took 4 min 38 seconds with FULLSTATS, and took
             4 min 24 seconds, so FULLSTATS don't cost much and provide
             diagnostic data that is helpful!

     D. MXG and SAS V9.1 were run under Windows XP, Linux RH8, z/OS 1.4.
        Linux and Windows used the same AMD 1400 1.5 GHz processor with
        500 MB and removable drives; z/OS runs were on an IBM 2064-210.
        The 842MB SMF file was used.

        The DATA step cost is tabulated, and the PROC SORT of TYPE30_D,
        which was 3.4 GigaBytes in size are compared:

        Data Step            LINUX      WINDOWS       z/OS
          Elapsed Time      4:27.70     7:40.02     11:03.36
          CPU time          3:59.46     3:57.64      5:56.7

        PROC SORT
          SORTSIZE DEFAULT     48MB        64MB        MAX
          Elapsed          15:39.82    28:19.89     12:28.98
          User CPU          5:01.43     4:02.93      5:23.16

          SORTSIZE            200MB       200MB
          Elapsed          15:26.10    28:19.89
          User CPU          5:01.02     4:02.93

          SORTSIZE            400MB       400MB
          Elapsed          19:12.40    35:05.38
          User CPU          5:02.79     4:15.81

        Observations:

         a. SAS V9.1 under LINUX significantly outperforms Windows XP,
            in both the DATA step and in the SORTS.

         b. SAS V9.1 under z/OS is significantly slower than either
            LINUX or Windows for the DATA step.

         c. SAS V9.1 under z/OS is better for PROC SORT, but that was
            with SYNCSORT on z/OS.  Newsletter FORTY showed that the
            SYNCSORT product under Windows was significantly better
            than the internal SAS sort under V9.0, but SYNCSORT on
            Windows was not available for these tests.

         d. On ASCII platforms the SORTSIZE parameter does impact the
            elapsed time, and elongation occurs if SORTSIZE is too
            large or too small. SAS V9.1 defaults were increased from
            the old 2MB default, and seem fine for this 3.4 GB sort.

         e. But what is really demonstrated is the repeatability and the
            reliability of the SAS System's MVA Architecture to meet the
            needs of your SAS applications on any of these platforms. It
            takes SAS 5-10 minutes to read a 1 GB SMF file and to create
            an MXG "MVS" PDB data library, and 15 minutes to sort a 4 GB
            dataset, no matter where you run it; that's pretty cool!
            And clearly this is not a capacity comparison of the two
            hardware platforms; running MXG on Intel requires dedicated
            hardware, at least during the creation of the PDB libraries,
            while z/OS can support thousands of users during BUILDPDB.
            But it should give you confidence that MXG will continue to
            measure your computer systems, no matter where SAS runs, and
            your MXG and SAS skills are transferable across platforms.

 3. ERROR: OPEN FAILED FOR FILE XXX: SYSTEM ERROR 013-0E1 results on MVS
    if you try to read a Large Block Interface tape file with block size
    greater than 32760.
      (introduced in OS/390 R2.10, LBI, Large Block Interface, allows
       256K for 3590s, 65535 for other tapes, no change for DASD).
    SAS Note SN-010759 documents that LBI support is being looked at for
    a future release after SAS 9.1, and "until this, it will not be
    possible to read those tape files".

 2. ABEND 0C4 in the FORMATS step of JCLINSTL with SAS Version 9 was
    caused by REGION=6M statement on the JOB card.  REGION=64M or
    REGION=0M has been recommended for Version 8 and 9 for BUILDPDB.
    Also make sure there is not a REGION= parameter on the STEP card.
    Nov 2008:  0C4 also occurs with SAS Version 9.1.3 if ENTRY=SASHOST
               is used.  ENTRY=SAS is the correct name for V9.1.3.

 1. For execution under Windows systems, batch file examples using the
    START command are discussed in SN-010991 which lists the link:
      "For more information about running jobs in batch, see:
       http://support.sas.com/techsup/unotes/SN/004/00449.html
      which then lists the link:
       http://support.sas.com/techsup/technote/ts648/ts648.pdf
      that does discuss batch execution of SAS under Windows.

VII. CICS Technical Notes.

 1.  APAR PQ81482 corrects CICS ABENDS and overlays that are caused when
     PTF UQ79397 is applied after APAR PQ63141, when MNRES=ON in your
     CICS SIT to enable Transaction Resource Class monitoring, if DFHMCT
     is coded with FILE=8 or more.

VIII. Windows NT Technical Notes.

 1.


IX.   Incompatibilities and Installation of MXG 20.20.

 1. Incompatibilities introduced in MXG 21.07 (since MXG 20.20):
    See CHANGES.

 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.


X.    Online Documentation of MXG Software.

    MXG Documentation is now described in member DOCUMENT.


XI.   Changes Log

--------------------------Changes Log---------------------------------

 You MUST read each Change description to determine if a Change will
 impact your site. All changes have been made in this MXG Library.

 Member CHANGES always identifies the actual version and release of
 MXG Software that is contained in that library.

 The CHANGES selection on our homepage at http://www.MXG.com
 is always the most current information on MXG Software status,
 and is frequently updated.

 Important changes are also posted to the MXG-L ListServer, which is
 also described by a selection on the homepage.  Please subscribe.

 The actual code implementation of some changes in MXG SOURCLIB may be
 different than described in the change text (which might have printed
 only the critical part of the correction that need be made by users).

 Scan each source member named in any impacting change for any comments
 at the beginning of the member for additional documentation, since the
 documentation of new datasets, variables, validation status, and notes,
 are often found in comments in the source members.

Alphabetical list of important changes after MXG 20.20 now in MXG 21.xx:

  Dataset/
  Member   Change    Description

  See Member CHANGES or CHANGESS in your MXG Source Library, or
  on the homepage www.mxg.com.

Inverse chronological list of all Changes:

Changes 21.yyy thru 21.001 are contained in member CHANGES.

****************NEWSLETTER FORTY-THREE**********************************




    MXG NEWSLETTER NUMBER FORTY-THREE dated Nov 10, 2003

Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE

                         TABLE OF CONTENTS                          Page

I.    MXG Software Version.
II.   MXG Technical Notes
III.  MVS Technical Notes
IV.   DB2 Technical Notes.
V.    IMS Technical Notes.
VI.   SAS Technical Notes.
VII.  CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX.   Incompatibilities and Installation of MXG.
         See member CHANGES and member INSTALL.
X.    Online Documentation of MXG Software.
         See member DOCUMENT.
XI. Changes Log
     Alphabetical list of important changes
     Highlights of Changes  - See Member CHANGES.

      COPYRIGHT (C) 2003 MERRILL CONSULTANTS DALLAS TEXAS USA

I.   MXG Software Version 21.06 is now available.

 1. Major enhancements added in MXG VV.RR:

    See CHANGES member of MXG Source, or CHANGES frame at www.mxg.com.

II.  MXG Technical Notes

 2. If you execute MXG on unix and have EMC's IFS product, you can read
    the SMF VBS directly from the MVS system, with no file transfer, by
    adding ",raw" to the DSNAME operand, to preserve the BDW and RDWs:
    FILENAME SMF '/mainframe/day.smf1,raw' RECFM=S370VBS BLKSIZE=32760;

 1. Building MXG-recommended daily, weekly, and (maybe) monthly PDBs is
    discussed in ACHAP33 (which needs to be updated!), but Chuck Hopf
    has a different philosophy, in part because of his data volume:

      At some point as a shop grows, it becomes impossible to run the
      WEEKBLD/MONTHBLD programs.  There is simply not enough disk space
      available (or wasn't until it became simpler to build multi-volume
      datasets - the STEPS dataset from last week has 1.1M observations
      and given 20K online DASD volumes across 9 LPARS for 672
      intervals/week it would be a staggering amount for TYPE74.)

      Running WTD/MTD allows for the best of both worlds and has also
      allowed for the extension of the Barry logic that there are 3
      levels of data.  Yesterday/Last week/last month.  In my
      experience, I really only need all of the variables if I am
      looking at yesterday so when I go to the WTD, I keep fewer (only
      those I am likely to use) and when I go to the MTD I keep even
      fewer.

      So, what we have available to us at any point in time is:

      Daily PDBs - 255 generations
      SPIN - 255 generations
      Weekly PDBs - 255 generations
      Monthly PDBs - 255 generations
      WTD PDB - 30 generations
      MTD PDB - 30 generations
      TREND - 255 generations (moving this to a daily update cycle)

      So, I can get to any days data if I need to or any weeks or any
      months in a single dataset. It all depends on the need for
      information.  Not all datasets get carried into the WTD/MTD
      process and most of the data is migrated to level 2 but it is all
      quickly available and online not on tape.

      In this environment, it makes a lot more sense than the classic
      MXG approach where if I wanted to look at detail data from Monday
      before last I would have to go against a weekly PDB. In fact, I
      submit that it makes a lot more sense in almost any environment
      (and eventually I will convince you.)

    I can't disagree, as with reduced variables kept in his week-to and
    month-to-date libraries, he has met his reporting needs, but I've
    never been a fan of x-to-date files.  Originally, I did use a GDG
    for my daily PDBs, but I kept running into DSENQ problems with the
    base GDG names when I wanted to read a daily PDB while today's
    job was still running (or re-running, as BUILDPDB was still in
    development!), and when I found I rarely needed to go back more than
    seven days, I created the seven named day-of-week datasets, and the
    last week's weekly PDB on DASD (this was before HSM), but copied the
    last-weekly to a weekly GDG as my permanent past detail history.

    However, if you have CA-11 (Job Scheduler), you MUST use GDGs for
    all datasets, so that all jobs are recoverable; i.e., when the job
    runs out of space, the data control clerks can increase the space
    allocation and restart the jobs.

    But if you like x-to-date datasets, then you will want to use the
    powerful VMXG2DTE program that Chuck developed to meet his needs!

    And now you have more choices in how you structure your PDBs.

III. MVS Technical Notes.

42. APAR PQ79562 adds an SMF exit for IBM Session Manager, ISZE39SM,
    which will enable the writing of SMF type 242 records at session end
    time.  The Facilities Reference manual under 'Slave Session
    Termination E39' gives details included in type 242 SMF records.
    STATS ON must be set at the System/Profile or User level is SMF
    records are required.
    May, 2004: Change 22.079, TYPEIBSM, supports this SMF record.

41. APAR OA05526 for SMF 66 records corrects hex nulls in ENTRNAME in
    dataset TYPE6156.

40. APAR PQ79901 reports corrections to WebSphere Application Server
    V5.0 for z/OS; EJB AverageResponseTime and MaximumResponseTime were
    zero when they should not have been zero; numerous other errors are
    also corrected.

39. APAR OW55830 for DFSMS/MVS  NFS SMF type 92 records now allows their
    recording to start at NFS server startup; previously, SMF writing
    was disabled and the operator had to explicitly enable SMF using the
    SMF=ON operand of the MODIFY command.

38. APAR OA03169 for z/OS 1.4 reports jobs may hang at step termination
    if LINKAGE=BRANCH (instead of LINKAGE=WTO) is used in IEFACTRT.

37. APAR OA04402 reports stopping of writing RMF records and CPU loop in
    ERBMFCEQ (RMF Address Space) with this "constellation": when ENQ
    gathering is restarted and there is an entry from the previous
    instance left in the intermediate queue of GRS elements, when during
    termination processing an entry is inserted by the RMF ENQ listen
    exit.  Only OS/390 2.10 thru z/OS 1.2 are impacted.  But I liked the
    use of "constellation" to describe multiple things!

36. APAR OA04812 is unlikely to impact, but it reports that data in SMF
    70 records is missing if the interval is less than 5 seconds!
       I have used one minute intervals for benchmarks, but never tried
       that short an interval, but apparently it is supported!
       I recall only one instance of strange data using a 1 minute RMF
       recording interval, where the printer channel activity was only
       recorded every tenth minute, and that one interval's counts were
       for the preceding ten minutes.  IBM's RMF reply was that what
       you see is what you get from devices that only update their own
       counters every 10 minutes.  Oct 30, 2003.

35. SMF Type 108 Domino subtype 2 record's SPR (fix) MIAS5MCJCL corrects
    zero values in variable DOMUCPU, User CPU time, in dataset TYPE1082,
    for DOMUTYP='NRPC' observations; records with DOMUTYP='HTTP' do have
    valid non-zero CPU measurements.  Domino Release 6.02 contains that
    fix, which apparently cannot be retrofitted on Release 5.

34. A new SYNCSORT "feature", ZSPACE, exists in SYNCSORT for z/OS. If
    SYNCSORT determines that enough memory is available and there were
    no SORTWKnn's coded (NOTE BENE: MXG ALWAYS HAS RECOMMENDED THAT YOU
    HAVE REAL //SORTWKnn DDs in your MXG JCL!!!), SYNCSORT will bypass
    the IEFUSI exits and will GETMAIN enough virtual storage to hold the
    SORTWKnn space in virtual memory, with no external ability to
    control, and no limits on how much virtual storage can be used.
    The COREUSED field in the SYNCSORT dataset from their SMF record has
    the virtual memory used, but there is no indicator that ZSPACE was
    used for a particular sort.

33. HIPER APAR OA03577 from IBM for RSM/SRM, and a planned fix from
    SYNCSORT (for their z/OS 1.1 release) should be installed if you
    have lots of sorts with DSM enabled.  Twenty or so parallel sort
    jobs fixed 99% of the page frames between the 16MB Line and the 2GB
    Bar, RSM failed to detect the page shortage, so SRM did not take any
    action to correct the page shortage "below the bar".  The IBM APAR
    addresses the RSM problem so that SRM takes action when
    available frames become too few; the SYNCSORT fix will limit the
    amount of storage that it fixes.  This problem can only occur with
    SYNCSORT's global DSM option enabled; turning off DSM limits the job
    to the memory specified in the VSCORET parm. Turning off DSM helps
    the sysplex overall, but can elongate run times for large sorts.

    Running out of storage "below the bar" was catastrophic, requiring
    the failing system to be removed from the sysplex.  Sysplex recovery
    on this very large complex took about 3 minutes, and essentially all
    work was halted on all systems during that recovery.

    MXG Dataset TYPE71 variables SMF71AFB/MFB/XFB track the number of
    fixed pages between 16M and 2G, with Average/Min/Max values.
      PROC PLOT DATA=PDB.TYPE71;
      BY SYSTEM;
      PLOT (SMF71AFB SMF71MFB SMF71XFB)* STARTIME;
      TITLE 'FIXED FRAMES BELOW THE BAR - 2GB IS 524,288 FRAMES';
    You can also look at MXG Dataset TYPESYNC from SYNCSORT user SMF
    to see JOBNAME COREUSED to identify the causing culprits and decide
    individually to increase/decrease their VSCORET if DSM is OFF.  In
    TYPESYNC dataset, variable SYNDSMVL shows how much memory DSM added
    to the initial memory value for each sort.

    Chuck Hopf found that all of the jobs using large fixed memory had
    SYNCSORT's WER418I messages, written when SYNCSORT dynamically uses
    ZSPACE/HIPERSPACE, and then noted that WER418I only was written for
    jobs with no //SORTWKxx DDs:  If a job does not have SORTWK DDs,
    SYNCSORT tries to do an INCORE sort and fixes all the memory it can:

            SORTWK  VSCORE  VSCORET   ZSPACE   Fixed Memory Used
             NONE    NONE     NONE      YES      124 MegaBytes
             NONE     1MB     16MB      YES      124 MegaBytes
              7       1MB     16MB       NO        6 MegaBytes


32. On Friday, August 22nd, IBM introduced their Mainframe Charter on
    the internet http://ibm.com/zseries/announce/charter/.

    This discussion was contributed to MXG Newsletters by Al Sherkow:

    From the IBM website, the charter provides "a framework for planned
    future investment and to highlight specific ways in which IBM
    intends to deliver ongoing value to zSeries customers."  There have
    not yet been any new announcements but they are expected soon.

    Three areas are of special interest to MXG users are the impact on
    software pricing, on sub-capacity pricing, and on WLC:

    a. MSUs Lowered for z990 Servers, but not the Performance.  This
       will lower your Variable WLC software charges and perhaps your
       MSU-based licenses from other vendors.

    2. z/OS Charges Lowered for Variable WLC Below 315 MSUs.  Provides
       lower monthly charges for smaller installations.

    3. When z/OS is used with a NALC ("New Application License Charge"),
       the z/OS Charges have been lowered to z/OS.e levels

    What Size is a z990?

    IBM has changed the Announced MSU Sizes of the z990 servers without
    changing the actual performance; sizes are now about 10% smaller:

          Model    Previously        August 2003      Pct
                    Announced MSUs    Announced MSUs   Chang

          z990-301       77               70          -9.0%
          z990-305      337              302         -10.4%
          z990-310      601              538         -10.4%
          z990-316      844              761          -9.8%
          z990-324     1192             1076          -9.7%
          z990-332     1512             1365          -9.7%

    To implement this change IBM will upgrade the microcode on all z990s
    to reflect the new Announced MSU Values. Microcode updates should be
    available in September, used by the z/OS Workload Manager and other
    vendor's queries to the hardware for the size/capabilities of LPARs.
    The new MSU size is available for sites using pricing metrics of
    full-capacity WLC, sub-capacity WLC or PSLC pricing.  This new size
    may also apply to the license agreements you have with other
    software vendors, lowering your software cost-of-ownership for the
    same performance.

    What This Means to Your Site

    This will certainly impact your capacity planning and reporting.
    Now you have two different capacities, the existing Hardware MSU
    capacity value calculated from SU_SEC in RMF 72 records, and this
    new Software MSU Capacity (for Software Charging), based on
    SMF70CPA.

    If you were planning an upgrade to a z990-310 with 601 Hardware
    MSUs, you were also planning a software budget impact based on 601
    MSUs.  Now, the maximum software charges will be based on the
    Software 538 MSU capacity, even though you'll have 601 MSUs of
    hardware capacity.  Note that the Hardware Constant
    (SU_SEC,LOSU_SEC) for the z990-310 is 17003.18, while the Software
    SMF70CPA constant is 15220.8239.

    Carefully review your chargeback procedures; if you are using CPU
    time or service units, as recorded in SMF/RMF, they should not see
    any change, but if you are calculating or using MSU as your metric
    for chargeback, you will have to decide which MSU capacity it will
    be matched against, and possibly change your MSU coefficient in
    your billing tables.

    If you have been using a formula for conversion from MIPS to MSUs,
    that may also require changes in your reporting programs.


    MSUs, the SRM Constant, and the z/OS Workload Manager

    The z/OS Workload Manager (WLM) uses the SRM Hardware Constant to
    recover the original CPU seconds from the RMF Service Units in the
    type 72 RMF data, but because the SRM Constant (SU_SEC) is not being
    changed, the CPU times in RMF and SMF data will not change.  What is
    changing is the measure of capacity, as IBM has created this new
    "Software MSU Capacity" for the z990 that is smaller than the nearly
    new "Hardware MSU Capacity" we've just been learning to understand,
    and what is changing in our data records (after a microcode update)
    is that IBM will put the Software MSU Capacity in its MSU-related
    RMF fields, and use it in the 4-hour rolling MSU averages.
       APAR Number OW50998 is needed so that RMF reports and SMF data
       would correctly reflect the announced MSU values.  Before OW50998
       the image capacity on RMF Partition Data Reports and the 4-hour
       rolling averages were not correct.)

    WLM will use the changed MSU values when calculating 4-hour rolling
    averages and image capacities.  These values will also be reported
    in RMF Partition Data Reports, RMF LPAR Cluster Reports, RMF III CPC
    command output, and various other reports and displays, and should
    also be used by your system monitors.  When software products query
    the LPAR and hardware configuration, the changed MSU values will be
    returned to the calling program.  The changed MSU sizes will be put
    in SMF70CPA (MXG variable CPUSUSEC), IBM labeled as the "physical
    CPU adjustment factor").

    z/OS Charges Lowered

    IBM lowered the price of z/OS and some features for sub-capacity
    sizes smaller than 315 MSUs on any zSeries server.  Of course you
    must be using Variable WLC.  Earlier this year IBM lowered the entry
    point to 3 MSUs; this change results in a further cost reduction.
    This price change is effective October 1, 2003.  The Lowered MSUs
    discussed above also apply.  If you have a z990-305 with previously
    announced capacity of 337 (Hardware) MSUs, its capacity now is 302
    (Software) MSUs, so it also falls into the lower z/OS price range.

    There are many installed machines that will benefit from this
    change.  Five z990 models, and twenty-five z900 models and all the
    z800s are smaller than 315 MSUs.  You should note this is a change
    for z/OS only and not for the other Variable-WLC products.  The
    actually prices have not been announced yet, only the fact that they
    will be changed soon.

    z/OS "New Application License Charge"

    Additionally, IBM has also lowered z/OS charges when you have a new
    workload that qualifies for IBM's "New Application License Charge"
    NALC, dropping the price to the level of z/OS.e, and this change is
    also planned for G5, G6, and z900.  To qualify for NALC pricing you
    must be implementing a new workload such as SAP, Domino, PeopleSoft,
    WebSphere, or some others.  Generally a new machine must be acquired
    for the new workload, but you may be able to implement the NALC
    workload in an LPAR.

         More information is also available at
             http://www.sherkow.com/updates/aug2003.html

31. The new large format 3390 DASD (25GB per Volume, 30,000 3990 cyls,
    available on the IBM ESS 2105-F08 (Shark) has the same value for
    variable DEVMODEL='33909' for both 3390-9's and the new Super 9's.

30. When reading concatenated input files, MVS stops reading when it
    encounters a DD DUMMY statement in the concatenation.  This is not
    new, but I didn't realize that was the case until I read SAS Note
    SN-010483 stating that that is expected behavior according to IBM.
    When a program attempts to read a dummy dataset the system does an
    end-of-data exit immediately and ignores any data sets concatenated
    after the DD DUMMY.

29. APAR OW54622 introduced an SQA overflow into CSA condition that
    increased CPU time for many STCs over time; the new GETMAIN larger
    than FREEMAIN was corrected by APAR OW55360.  It has long been known
    that when SQA is too small and expands into the CSA area, path
    lengths are dramatically increased; you can detect this condition in
    MXG dataset TYPE78VS variables SQAEXPNx.

28. SMF Type 42 subtype 6 SMF TYPE42DS missing dataset information can
    be caused by BMC's Mainview Batch Optimizer 2.3.0, and BMC Tracking
    Number F336716 to correct their error.

27. APAR PQ72222 corrects SMF type 119 (TCP/IP V3) records that had an
    invalid BLKSIZE and LRECL of 32768.  The APAR text reconfirms the
    SMF limit of 32756 bytes of data, i.e., LRECL=32760,BLKSIZE=32760.


26. APAR OA02569 corrects error in ICF Catalog Record SMF 60 that had
    trashed values for variable ENTRNAME (IBM field SMF60ENM) for a
    DEFINE USERCATALOG request, but the APAR also corrects blank values
    for ENTRNAME in SMF 66 records for some ALTER requests.

25. WebSphere Service Level W401504 of Version 4.0.1 APAR PQ71127 fixes
    performance problems including high overhead and duplicate SMF 120
    records being written.

24. APAR OA02742 documents errors in IBM RMF WLMGL and CF reports, if
    you happen to be comparing IBM post-processor reports with MXG's
    (correct) ANALRMFR reporting.  Errors included using wrong interval
    for per-second values, or incomplete input data.

23. APAR OA03055 documents the cases in which SMF 88 records will not be
    written for certain logger detected structure full (actually
    logstream full) conditions; the correction will increment SMF88ESF
    if Logger detects that a Logstream has exceeded its allowable limit
    in the structure, but the structure may not be completely full.
    For DASDONLY logstreams, previously undefined SMF88CS1 and SMF88CS2
    variables are now defined by the PTF.  Details are in the APAR text.

22. APAR OA03438 corrects type 42 subtype 6 S42DSMXS (Maximum Data Set
    Service Time) that was incorrectly larger than S42DSMXR (Maximum
    Data Set Response Time); the time for the Control Unit was included
    in the S42DSMXS Service Time, but now is no longer added in.

21. APAR PQ71799 for SMF 103 corrects subtype 2 records created when the
    HTTP Server is run in scalable mode.  Records written by the queue
    manager and by the queue servers contain essentially identical
    combined information, and some of the numbers were inaccurate.
    The APAR also provides new options: "separate", to cause each
    scalable mode server to write only its own statistics to SMF,
    instead of combined data, and "sync" to synchronize SMF 103 records
    to the hour.

20. APAR OA01883 for RMM is needed if your get EDG4025I VOLUME nnnnnn
    REJECTED, or IEC145I 413-08 error messages.  These errors occurred
    when z/OS 1.2, 1.3 or 1.4 is installed without that RMM APAR.
    This APAR also applied to OS/390.

19. APAR OA02898 corrects a problem in SMS when a DELETE GDG FORCE was
    used, but not all members of the GDG were deleted; the error was
    cause by incorrect IBM code in HDZ11G0 changes to SMS.

18. To ftp MVS V/VB/VBS data files to PCs or workstations, or to MXG
    support, you do NOT have to create a RECFM=U copy of the data file,
    at least not with IBM's ftp program.  Bob Charest found that IBM's
    ftp program has a "DD:" argument that can be used to point to the
    DDname of the file to be sent, and by using RECFM=U,BLKSIZE=32760 on
    that DD statement, the full file, including BDWs and RDWs, will be
    downloaded.  The below example can be used to send SMF files to the
    MXG support ftp site, but by changing the PARM= ip address, and the
    "mxgtech mxgtech" (userid password), you can ftp your data file in a
    single step, and that downloaded file can be read directly by MXG.

      //MXGFTPOU JOB ACCT,'ABCD',CLASS=I,MSGCLASS=T,NOTIFY=&SYSUID
      //FTP      EXEC PGM=FTP,PARM='ftp.mxg.com'
      //SYSPRINT DD  SYSOUT=*
      //OUTPUT   DD  SYSOUT=*
      //SMFFILE  DD DSN=YOUR.SMF.DATA,DCB=RECFM=U,BLKZIZE=32760,DISP=SHR
      //INPUT DD *
      mxgtech mxgtech
      quote PASV
      bin
      put //DD:SMFFILE  yourname.smf
      close
      quit
      /*

    The SYSPRINT output will tell you if the ftp transfer succeeded or
    not; in a production environment, you probably want a Return Code
    set if there was any error; the syntax for the IBM ftp program to
    set Return Code 12 on any error is
      //FTP      EXEC PGM=FTP,PARM='ftp.mxg.com (EXIT=12'


17. APAR PQ73030 corrects incorrect hsf filename offsets in SMF 118
    (TCP/IP - supported in MXG TYPETCP because they were originally user
    SMF records).  The offsets should only be non-zero in a RENAME event
    record, but contained trash in other event records.

16. APAR OW54347 (supported in MXG Change 21.058) adds CMR Time to RMF
    74 records and to RMF Device Reports, and eliminates CUBDL (CU Busy
    Delay time) and DPBDL (Director Port Busy Delay Time) from both RMF
    reports and from TYPE74 records.

15. APAR PQ71799 reports incorrect values in RMF reports based on SMF
    103 subtype 2 records - Threads Used and Max Threads Used are zero
    in RMF reports, but the SMF records (and hence MXG!) are non-zero.

14. DFSORT R14 SMF type 16 has incorrect CPU time (variable SORTCPTM,
    IBM field ICECPUT) when DFSORT is called from a program which uses
    dynamic allocation (because dynamic allocation also uses STIMER).
    The incorrect CPU time is always 24 hours (X'0083D600').
    APAR PQ72589 documents the error, with "FIN" - Fixed in Next.

13. JES3 only.  SMF type 25 Fetch counts are corrected by OW56112, for
    both tape (TAPFETCH) and DASD (DSKFETCH) scratch mounts.

12. ***ERROR.VMAC42.42LN4LEN for SMF 42 subtype 20 and 21 records is
    corrected by IBM APARs OA02184 and OA08693. Using STOW DELETE was
    fixed in OA02184, and using DESERV FUNC=DELETE is fixed in OA08693.

11. Previously, you could not use products that extend volumes (STOPX37,
    PRO/SMS, SRM, and VAM) with SAS, but the Hot Fix Bundle 82BX04 has
    changed the way SAS extends volumes so those products can now be
    used with SAS V8.2 and that Hot Fix.  SN-008936 points to SN-005642,
    which points to the 82BB34 Hot Fix List, which shows SN-005642 as
    having been introduced in 82BA57.
       If you have to disable STOPX37 for a specific job step, add
         //PROIGN DD DUMMY
       to the step's JCL.

10. APAR OW53698 has been issued for incorrect IOUNITS and/or SERVUNIT
    in SMF 30s; IOUNITS was very large (2x10**9) and SERVUNIT was not
    the sum of CPUUNITS+SRBUNITS+IOUNITS+MSOUNITS.  The error has been
    fixed by IBM, and only occurred when running in 64 bit mode when a
    SYSEVENT REALSWAP was issued.

 9. Cheryl Watson recommended that I include a warning about trying to
    calculate the published MSU values from the SU_SEC values.  The HDS
    Skylines and Amdahl are not close, and IBM has several instances
    where the calculated MSUs (technical) and published MSUs (marketing)
    differ.

 8. Invalid date/times in READTIME in TYPE26J2 records have been caused
    by Computer Associate's CA-7 product, as a result of zap's that were
    suggested by CA Technical Support (for which there was no formal
    "Fix" Number.

 7. APAR PQ69575 for SMF 119 corrects negative values in connection
    count variables TCHWMRK and TCNCONNS in subtype 7 record.

 6. APAR PQ70810 adds new data to SMF 108.  Incomplete.

 5. APAR PQ67142 sets IBM bit 7 ('......1'B) of byte 5 of TRANFLAG in
    CICSTRAN to true if the Task Abnormally Terminated.  Previously,
    there was no flag to indicate that a transaction had completed and
    issued message DFHAC2236, and which have not issued that message.

 4. APAR PQ70765 reports Remote and Local IP Addresses in SMF 119 are
    incorrect in termination records; the local address is zero and
    the remote address is the local address.

 3. APAR OW52226 reports, without correction, that type 30 variables
    TAPNMNTS (SMF30PTM) and TAPSMNTS (SMF30TPR) mount counts are not
    updated for SMS dynamically allocated datasets which reside on tape.
    While the specific case was JES3 controlled tapes, the APAR applies
    to all SMS tapes, JES2 and JES3.
    Sep 5, 2003: An PTF now exists, and the APAR text reports that the
    error was corrected in DFSMF/MVS 1.5.

 2. APAR OW55803 moves the issuance of IEC705I ("TAPE OPENED") message,
    previously issued after the data set labels had been created, until
    after the OPEN bit (DCBOFOPN) has been set; ABENDs 013 or 613 RC20
    occur after the data set labels were created and before the OPEN was
    successful.  The APAR does not change the fact that SMF 15 records
    will not be created when an OPEN abend is detected.  SMF 15 records
    will be created only after CLOSE, EOV, and FEOV abends (i.e., only
    after the dataset has been successfully opened).

 1. APAR OW57716 for SMF 89 records corrects the CPU Version Number,
    which, after an upgrade of the CPC, still contained the older
    processor, not the upgraded one.

IV.  DB2 Technical Notes.

 2.  APAR PQ75731 fixes QTXANPL which was incorrectly calculated on the
     maximum number of locks held by transactions instead of the locks
     held by user objects - max locks held included locks for catalog
     access that are not considered user locks.

 1.  DB2ACCT data, especially for DDF transactions, with DB2TCBTM much
     greater than ELAPSTM, that have accumulated values (the CPU time
     increases across transactions), are due to IBM errors in  QWACSPCP,
     the CPU Time in Stored Procedures, which MXG includes in DB2TCBTM.
     IBM APARs PQ65302 and PQ55259 correct the errors (actual fixes are
     in PTFs UQ62410, UQ70983, and UQ62410) but neither the APAR nor PTF
     text says anything about QWACSPCP.

V.   IMS Technical Notes.


VI.  SAS Technical Notes.

10.  SAS/ITRM "MVS" executes MXG code, but ITRM renames the datasets
     (DETAIL.XTY70 in place of PDB.TYPE70), and MXG variable names are
     truncated to seven positions, with a meta-data suffix added.

     So you can't use MXG "sample" programs with the ITRM renamed PDB
     datasets?  Not true!

     The MXG "PDB" datasets do exist in the ITRM DETAIL library, because
     ITRM creates a SAS View to map their renames back to the original
     MXG dataset and variable names.  You just use  DATA=PDB.TYPE70  or
     SET PDB.TYPE70; syntax to access the original MXG PDB dataset.
     ITRM builds its data in the DETAIL library, but libref's "PDB" to
     that same library, just for this purpose!

     All PDB datasets that are defined in the ITRM dictionary will have
     a SAS View created, but it will only know about the variables that
     are in that dictionary.

     However, for completely new datasets added by MXG to the "PDB" that
     are not yet in the ITRM dictionary, no VIEW is built, and any new
     variables added to MXG datasets won't be in the VIEW until the ITRM
     dictionary is updated.

     However, however, all of the MXG datasets are actually available in
     the ITRM WORK library, and they will have all of the new variables.
     They can be copied or used ever before ITRM's dictionary has been
     updated, but you will need to insert this statement:
        %let cpstgekp = Y ;
     before your %CMPROCES/%CPPROCES macro, to prevent the deletion of
     all of the WORK datasets.  %CMPROCES/%CPPROCES stages all of the
     datasets into the WORK libref, and then normally deletes all of
     the WORK datasets.


 9.  With SAS/ITRM (formerly SAS/ITSV), to enable the "MXG Debugging"
     options (SOURCE SOURCE2 MACROGEN MPRINT), you need to insert two
     statements between the %cpstart and %cmproces/%cpproces calls:
              %cpstart ..... ;
                %let cp_nmsg=2;
                options macrogen mprint;
              %cmproces ... ;
                 or
              %cpproces ... ;
     With those options, you can tell which members were included from
     which library (yours or mine!), you get the line numbers of the
     compiled code, and you see the values of macro variables that you
     have changed.  Lots of print lines, but it usually lets me resolve
     the problem in a single iteration.

 8.  SAS Note SN-010893 corrects an IBM ETR that claimed SAS had caused
     a full system outage.  IBM APAR OA04838 now acknowledges that the
     system outage was NOT caused in any way by SAS, but instead was a
     bad ESTAE routine in IBM's own DB2 REPLIDATA product!

 7.  New option DTRESET in SAS Version 9 prints the current time and
     date in your output, instead of the date/time of the start of SAS.

 6.  SAS Version 8.2, 9, VM1319 ABEND, or LOGICAL NAME ddname ASSIGNED
     BUT NOT IN CURRENT SCOPE, when you reassign a FILENAME statement
     and use a FILEREF (aka DDNAME) that was externally allocated (i.e.,
     in your JCL), and the DSNAME in the new FILENAME statement is not
     the same as the external DD.  SAS Notes SN-010623 and SN010629 only
     provide a circumvention: "don't do that".

 5.  SAS Version 9.0 prints spurious NOTE for every variable in a label:
       NOTE 49-169: The meaning of an identifier after a quoted string
       may change in a future SAS release.  Inserting white space
       between a quoted string and the succeeding identifier is
       recommended.
     SAS acknowledges this note is in error, and that nothing in MXG has
     to be changed in the future, and have eliminated the spurious note
     in SAS Version 9.1.

 4.  Error message WRITE ACCESS TO MEMBER PDB.CICSACCT.DATA IS DENIED
     was seen at one site when it tried to use a PDB dataset that had
     been copied by the FDR (Fast Dump Restore) product.  Using PROC
     COPY instead eliminated the error.

 3.  High-volume write-once read-once-normally datasets (like CICSTRAN
     or DB2ACCT) are frequently written out as a tape GDG on MVS, but
     only 255 days can be kept in a daily GDG.  An alternative is to
     create a unique MVS dataset name (MXG.CICSTRAN.APR0403) each day,
     and let HSM migrate the dataset to tape after its one use.  You
     can use the LIBNAME statement and SAS code to create the date for
     the DSNAME with this example for MVS:
             DATA _NULL_;
               TODAYDTE=UPCASE(PUT(TODAY(),DATE7.));
               CALL SYMPUT('TODAYIS',TODAYDTE);
               RUN;
             LIBNAME CICSTRAN V6SEQ "MXG.CICSTRAN.D&TODAYIS"
                DISP=(NEW,CATLG) SPACE=(CYL,(200,200)) UNIT=(SYSDA,5);
             RUN;
     will create DSN=MXG.CICSTRAN.D04APR03, and force the format to be
     sequential (tape) format.

     For PC/Unix, this syntax will create a directory name and assign
     the libname CICSTRAN to that directory:
             OPTIONS NOXWAIT;
             DATA _NULL_;
               TODAYDTE=UPCASE(PUT(TODAY(),DATE7.));
               CALL SYMPUT('TODAYIS',TODAYDTE);
               RUN;
               x "md 'c:\mxg\cicstran\d&todayis' ";
               LIBNAME CICSTRAN "C:\MXG\CICSTRAN\D&TODAYIS" ;
             RUN;
     That NOXWAIT option for Windows/ASCII systems is needed here only
     because the X command is used; without NOXWAIT, after the X command
     completed creation of the directory, your SAS session would come
     back to wait for terminal input.

 2.  Using PROC COPY under V8 to copy a Monthly PDB failed on several of
     the datasets with ERROR: THE RECORD FORMATS ARE DIFFERENT.  The PDB
     had been created with an old MNTHBLD that still used the V8SEQ tape
     ending (i.e., LIBNAME xxx TAPE; had not been changed to &TAPENG as
     documented in Change 18.104).  Rebuilding the Month PDB with the
     correct (still V6SEQ) tape engine resolved the errors.

 1.  SAS Version 9.1 has changed the WARNING message that Compression
     was Disabled to a NOTE, so  the Condition Code will be zero instead
     of four.  SAS Note SN-008632 discusses.

VII. CICS Technical Notes.

 2. APAR PQ75068 reports CICS SMF 110 subtype 2 STID=24 A04 data was
    wrong after PQ62574.

 1. No observations in Landmark-ASG TMON MONITASK dataset because their
    VTCECNTL file (Control file for TMON for CICS) loses the group
    association for the CICS jobs when you run the convert program
    against it - this causes the jobs to be associated with the default
    profile, which has the TA (task) records turned off, and it is the
    TA records that create observations in MONITASK dataset.


VIII. Windows NT Technical Notes.

IX.   Incompatibilities and Installation of MXG 20.20.

 1. Incompatibilities introduced in MXG 21.xx (since MXG 20.20):
    See CHANGES.

 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.


X.    Online Documentation of MXG Software.

    MXG Documentation is now described in member DOCUMENT.


XI.   Changes Log

--------------------------Changes Log---------------------------------

 You MUST read each Change description to determine if a Change will
 impact your site. All changes have been made in this MXG Library.

 Member CHANGES always identifies the actual version and release of
 MXG Software that is contained in that library.

 The CHANGES selection on our homepage at http://www.MXG.com
 is always the most current information on MXG Software status,
 and is frequently updated.

 Important changes are also posted to the MXG-L ListServer, which is
 also described by a selection on the homepage.  Please subscribe.

 The actual code implementation of some changes in MXG SOURCLIB may be
 different than described in the change text (which might have printed
 only the critical part of the correction that need be made by users).

 Scan each source member named in any impacting change for any comments
 at the beginning of the member for additional documentation, since the
 documentation of new datasets, variables, validation status, and notes,
 are often found in comments in the source members.

Alphabetical list of important changes after MXG 20.20 now in MXG 21.xx:

  Dataset/
  Member   Change    Description

  See Member CHANGES or CHANGESS in your MXG Source Library, or
  on the homepage www.mxg.com.

Inverse chronological list of all Changes:

Changes 21.yyy thru 21.001 are contained in member CHANGES.

****************NEWSLETTER FORTY-TWO************************************









    MXG NEWSLETTER NUMBER FORTY-TWO  - Feb 7, 2003

Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE

                         TABLE OF CONTENTS                          Page

I.    MXG Software Version.

II.   MXG Technical Notes

III.  MVS Technical Notes

IV.   DB2 Technical Notes.

V.    IMS Technical Notes.

VI.   SAS Technical Notes.

VII.  CICS Technical Notes.

VIII. Windows NT Technical Notes.

IX.   Incompatibilities and Installation of MXG.
         See member CHANGES and member INSTALL.
X.    Online Documentation of MXG Software.
         See member DOCUMENT.
XI. Changes Log
     Alphabetical list of important changes
     Highlights of Changes  - See Member CHANGES.

      COPYRIGHT (C) 2002 MERRILL CONSULTANTS DALLAS TEXAS USA

I.   MXG Software Version VV.RR is now available.

 1. Major enhancements added in MXG VV.RR:

    See CHANGES.

II.  MXG Technical Notes

 2.  I want BUILDPDB to ABEND if there are no SMF records to read.

     This step can be inserted ahead of the include of BUILDPDB:

        DATA _NULL_;
          IF END AND NREC=. THEN DO;
            PUT ' NO SMF RECORDS FOUND.  JOB ABENDED WITH USER 99';
            ABORT ABEND 99;
          END;
          INFILE SMF END=END;
          NREC=1;
          STOP;
     and it will either read one record or ABEND the job.

 1.  How do you rebuild an old daily PDB?

     BUILDPDB has two inputs: today's SMF records, and yesterday's SPIN
     data library of SPINxxxx datasets containing incomplete jobs.

     BUILDPDB has two outputs: today's PDB library, and the updated SPIN
     library of incomplete jobs, to be used as tomorrow's input SPIN.

     The SPIN architecture only affects these job-related datasets:
        PDB.JOBS/PDB.STEPS/PDB.PRINT/PDB.NJEPURGE/PDB.SPUNJOBS
     built from the SMF 6, 26, and 30 records.  The parameter SPINCNT
     that you chose in your IMACSPIN member controls how long jobs are
     held in the SPIN library.

     All other data sets in the PDB are created directly from the input
     SMF file and are not affected by the contents of the SPIN library.

     To recreate a daily PDB, the SPIN library must be restored to be as
     it was before that day's BUILDPDB job ran.

   a. If the day to be recreated is within the last seven days:

     BUILDPDB backs up all of the SPINxxxx datasets into that day's PDB
     library for your backup, so you can restore the SPIN library from
     that previous day's PDB library and use it for your BUILDPDB job:

               //    EXEC MXGSAS
               //PDBPREV  DD DSN=PREVDAY.PDB.LIBRARY,DISP=SHR
               //SPIN     DD DSN=SPINNEW,DISP=(,CATLG),UNIT=SYSDA....
               //SMF      DD DSN=THAT.DAYS.SMF.FILE,DISP=SHR
               //PDB      DD DSN=PDB.TO.CREATE,DISP=(,CATLG),UNIT=....
               //SYSIN DD *
                 PROC COPY IN=PDBPREV OUT=SPIN; SELECT SPIN:;
                 %INCLUDE SOURCLIB(BUILDPDB);

     If you were restoring forward from this day, you would run this job
     on the first day, and would then use the DSN=SPINNEW as your new
     SPIN library.  If you were just recreating one day's PDB, you would
     delete the SPINNEW dataset after the recreate.

   b. If the day to be recreated is earlier than seven days ago:

     You are in a world of hurt, unless you wisely backup your SPIN
     dataset at the end of each day's BUILDPDB job, or you wisely backup
     backed up each day's PDB library after BUILDPDB has executed.

     If you do not have a backup of your SPIN library from the previous
     BUILDPDB execution, and you need to rebuild the JOBS, STEPS and
     PRINT datasets for billing accuracy, then you must first create and
     repopulate a SPIN library, by reading each of the previous SPINCNT
     day's SMF files, one step at a time.  These SPIN-rebuild steps read
     only the SMF 6, 26, and 30 records and execute only the first and
     fifth phases of the BUILDPDB logic, for speed and minimum space.

     For example, if SPINCNT is 30, you would go back to the 31st day
     before the day of interest, and execute these 31 steps:

         //W31  EXEC  MXGSAS
         //SPIN  DD DSN=SPINNEW,DISP=(,CATLG),UNIT=SYSDA....
         //PDB   DD UNIT=SYSDA,SPACE=(CYL,(1000,1000)),DISP=(,DELETE)
         //SMF   DD DSN=SMFDAY(-30),DISP=SHR
         //SYSIN DD *
           %LET MACFILE=  %QUOTE(  IF ID IN (6,26,30);  ) ;
           %INCLUDE SOURCLIB(BUILD001,BUILD005);

         //W30  EXEC  MXGSAS
         //SPIN  DD DSN=SPINNEW,DISP=OLD
         //PDB   DD UNIT=SYSDA,SPACE=(CYL,(1000,1000)),DISP=(,DELETE)
         //SMF   DD DSN=SMFDAY(-29),DISP=SHR
         //SYSIN DD *
           %LET MACFILE=  %QUOTE(  IF ID IN (6,26,30);  ) ;
           %INCLUDE SOURCLIB(BUILD001,BUILD005);

             ... steps for SMF(-28) thru SMF(-1)

         //W0   EXEC  MXGSAS
         //SPIN  DD DSN=SPINNEW,DISP=OLD
         //PDB   DD UNIT=SYSDA,SPACE=(CYL,(1000,1000)),DISP=(,DELETE)
         //SMF   DD DSN=SMFDAY(0),DISP=SHR
         //SYSIN DD *
           %LET MACFILE=  %QUOTE(  IF ID IN (6,26,30);  ) ;
           %INCLUDE SOURCLIB(BUILD001,BUILD005);

     and you would then have the SPIN library recreated to use for the
     input to actually create the day's PDB library.

     We must go back N+1 days if SPINCNT is N rather than just N days.
     Jobs in SPIN prior to the first day would have been output into a
     daily PDB when their SMF records that matched up were read, but as
     we don't have those old SPIN records, those jobs will not match up
     and would have remained in our SPIN if we executed only SPINCNT
     times.  By running SPINCNT+1 times, those SMF records we read that
     will never match up will have been removed from the SPIN library,
     so we will have exactly repopulated the SPIN as it existed.

   c. And what if you no longer have the daily SMF files, but instead
      now have only a weekly file of SMF records that was built by the
      concatenation of those daily SMF files?

     Perfect accuracy gets complicated



III. MVS Technical Notes.

33. APARs OW55729 and OW55902 are HIPER fixes, dealing with MCCAFCTH
    thresholds; OW55729 suggests as a circumvention, setting:
       Total Real Size    Threshold minimum
          <2 GB            MCCAFCTH=(350,400)
         2-6 GB            MCCAFCTH=(2000,2500)
          >6 GB            MCCAFCTH=(5000,6000)
    Without the APARs, zero values for AFC were seen on z/OS 1.3.
    In z900 architecture with all real storage, UIC has not been
    found to be a useful indicator of storage health; the AFC
    (Available Frame Count) seems to better show storage health,
    dropping faster and sooner than the UIC drops under stress.

32. Multiple periods for Reporting Classes was added in z/OS 1.2.
    See the discussion in Juergen Holtz paper "z/OS Workload Manager,
    The Latest & Greatest", SHARE San Francisco, Session 2515, at
    http://proceedings.share.org/sanfrancisco/

31. Benchmark of cost of ASMTAPES/MXGTMNT ML-27 at 2, .5, and .1 sec:

   The high CPU cost of ML-20 thru ML-26 was finally confirmed to be due
   to IBM recovery after the 0E0 ABEND when Cross Memory Services finds
   the address space is gone.  One of the beauties of MXGTMNT was that
   it captured the READTIME of the JOB in that XMEM call, plus some data
   that was not available elsewhere, but since IBM cannot provide a way
   to know that an ASID is gone, we simply cannot afford to use XMEM for
   monitoring mount durations.  The redesign of MXGTMNT in ML-27 turns
   off XMEM (except for step transition detection), which not only drops
   the CPU cost of the monitor so that it is not an issue anymore, but
   also captures almost all allocations and many more of those very fast
   VTS mounts, but not spending elapsed time in those recovery modules.
      Some of the improvement in capture accuracy is due to corrections
      in the earlier designs; at the first UCB with an 0E0, ML-19 and
      earlier levels terminated that intervals UCB scan, never looking
      at the rest of the UCBs; if you had tape devices with addresses
      above your VTS devices, MXGTMNT probably never saw them.

   Billy Westland, at Kaiser Permanente, built a job stream that created
   thousands of very fast DISP=NEW VTS mounts writing one block of data,
   running ML-27 at 2, 0.5, and 0.1 seconds sampling interval.  The test
   drove the 64 VTS UCBs to an AVERAGE of 4.4 mounts per second (note:
   not seconds per mount!), and there were many instances of 12-15 tape
   mounts in one second, a far higher rate than you are likely ever to
   see in a real data center.

   Chuck Hopf ran ML-27 at 1/2 second samples on a system with 344 tape
   devices, but all were offline, so his previously reported CPU cost of
   MXGTMNT of only one second per hour, only shows the cost of nothing.

   But the below benchmarks do show that the CPU cost of MXGTMNT is
   driven primarily by the number of mounts and allocations that are
   seen by sampling, and not the scanning of the UCBs itself.

        RAW DATA FROM ML-27 WITH XMEM VERY-FAST-VTS-MOUNTS BENCHMARK:

             ==SMF Record Count==  ==MXGTMNT==     Seconds   Mounts
             Type   Type   Type     CPU  CPU sec   With a     per
     INTRV    21    TALO   TMNT    secs  Per Hr     mount    Second

     2.00    2621    769    93      3.84    14       605      4.3
      .50    6379   5892   855     13.54    22      1445      4.4
      .10    2651   2666   776     44.02    74       656      4.1

      .50      0     0    0            1      0      NONE     ZERO

     The table shows that with this unrealistically high tape mount rate
     of over 4 mounts per second, the hourly CPU cost of MXGTMNT ranges
     from 14 to 74 seconds per hour as sampling interval is changed; you
     will see much less CPU time per hour in your real environment.

     Note that at 2 seconds, we captured only 30% of the allocations and
     only 4% of the mounts, while at 1/2 second we captured 92% allocate
     and 13% of these mounts, and at 1/10 second interval, we saw 100%
     of the allocates and 30% of these very fast mounts.

     The step elapsed time of these mounting steps were as small as 180
     milliseconds, yet we still see the vast majority of them.


30.  APAR PQ69884 for TCP/IP V3 SMF 119 record reports invalid byte
     count for failed login attempts.

29. APAR OW44949 corrects loss of TYPE 21 (Tape Dismount) SMF records
    when there is a long busy timeout during rewinding of a tape on 3590
    devices, and excessive OBRTMP records are created.

28.  ObjectStar (HURON, TYPEHURN) SMF records are created in error with
     PUT03.  The vendor's fix (AP09925) resolved the bad SMF records,
     which caused INPUT STATEMENT EXCEEDED RECORD LENGTH error in MXG.

27.  For Ficon Director,  these RMF APARs/PTFs are required, otherwise
     all of the ficon director measurements are zeroes:
       OS/390 R2.10 to z/OS 1.1:  OW46170, OW46825, OW48950, OW57147
       z/OS 1.2:                  OW52396

26.  APAR PQ67187 for TCP/IP V3 SMF 119 record ("IBM Communications
     Server for z/OS Version 1 Release 2 and 4 IP") corrects error in
     SMF 118 output byte count, which was sometimes 'FFFFFFFF'x (a -1 if
     input with IB4 but MXG intentionally inputs with PIB4, a value of
     4,294,967,295, which won't be accidentally overlooked!),

25.  APAR OW56033, "NPM for TCPIP" SMF records (TYPENPIP in MXG) reports
     duplicate records were created by the AEST044 program called by the
     AESTNETS started task, and the PTF corrects that error.  MXG Change
     20.070 reported the duplicates, and added code to delete duplicates
     so no new change is required to support this APAR.

24.  Information APAR II10752 discusses ICF Catalog Performance Issues,
     causes of high CPU time in the CAS address space, and suggests many
     parameter values that will help or hinder catalog access.
     Quite a bit of tutorial information is presented.

23.  APAR PQ68057, SMF 119 FTP records, corrects missing local port and
     IP address for the data connection, in both server and client data.

22.  APAR PQ68360 for SMF 118 TCP records documents that the DSNAME is
     blank if an ftp "GET" is done for a file and the local file is a
     DDNAME.  Temporary fix: specify the datasetname explicitly instead
     of using a DD card; the error is "FIN" - "Fixed in Next".

21.  APAR PQ57651 corrects RMF SMF 79 Subtype 15 (IMS Long Lock) to
     populate R76FRSNA, the database name involved in the lock.

20.  PROC SYNCSORT Early Warning EW5504-1 corrects their WER224A ERROR
     if that product is used with SAS V8.2; note this is the additional
     product PROC SYNCSORT Release 2.2C, and not for the base SYNCSORT.

19.  Error message IOS050I CHANNEL DETECTED ERROR, Interface Control
     Checks, and WER061A I/O ERR MISCP were due to missing IBM patches
     in their microcode; the error occurred on SHARK DASD connected to
     ficon, and a circumvention to set new work volumes to 'DISNEW' in
     SMS (so the job must then use non-ficon work packs) worked until
     IBM provided the patches (that were missed by IBMS install team!).

18.  APAR OW56112 for JES3 Type 25 corrects count of scratch volumes.

17.  APAR OW55509 provides new function to update WLM's calculation for
     the 4 hour rolling average MSU even when no capacity limit has been
     defined.  Also, at IPL the 4-hour average rolling average had no
     history and was calculated over too short a time period, which has
     caused the system to be capped during IPL, so now all 48 entries
     are initialized with no load (one uncapped service unit per 5 min
     interval, as close to zero as you could get) so the average that
     controls at IPL time is an unloaded system.
       Note that MXG's MSU calculations keep the prior history and will
       report the true rolling average across IPLs.

16.  JARS truncates SMF records; a site converting from JARS to MXG had
     INPUT STATEMENT EXCEEDED errors on an SMF 110-2 with LENGTH=32718
     because their JARS SMF copy/dump job's JCL had LRECL=32722, which
     truncates any records with LRECL 32723-32760. JARS didn't fail; it
     doesn't use any of the 110-2, 74, etc long records, its copy just
     destroyed them.  As has been stated since day one of MXG:

     For SMF files: ALWAYS use     RECFM=VBS,LRECL=32760,BLKSIZE=0
     to read or write, and never use a smaller LRECL, for SMF VBS files.
       (With SMS, BLKSIZE=0 creates 27998 on DASD, 32760 on tape)

     And, that same DCB will read or write ANY MVS V, VB, or VBS files,
     since V and VB on MVS are subsets of VBS (all three have a 4-byte
     BDW and a 4-byte RDW; V uses only the BDW, VB uses BDW and RDW, and
     VBS uses both and the low two-bytes of RDW for the spanning bits).

     Okay, what about LRECL=32767 instead of LRECL=32760 for VBS?
     Yes, MVS currently does allow you to create a VBS file with 32767
     LRECL, and SAS does support that value, but many other software
     products fail with 32767.  The documented design maximum LRECL for
     SMF has always been 32760 (i.e., 32756 bytes of actual data, plus 4
     bytes of RDW), and IBM has issued APAR/PTFs to acknowledge/correct
     cases when an SMF developer failed to obey that design maximum or
     32760.  Since there is little value in the extra 7 bytes, and lots
     of opportunity for I/O errors, 32760 remains the value of choice.

     This might change if the current hardware/software constraints of
     two-byte lengths in software and physical track length in hardware
     routines are revised to fully support longer blocks and records.

15.  IBM APAR OW57219 has been opened to correct errors in counts of the
     in-flight batch delay samples (they included ALL of the batch delay
     samples).  The impossible values are set missing by Change 19.198
     to circumvent the IBM error, but that change does not need to be
     removed when IBM puts the correct values in the record.

14.  A posting from Martin Packer:  VIO is a Data in Memory (DIM)
     technique that has been shown to use more CPU time.  Obviously,
     it's better if the VIO is done entirely to memory, but it is one of
     those techniques that does require that additional cycles be used.

13.  How can you measure delays to jobs due to Tape Allocation:

     Tape Allocation Recovery cannot be measured from tape mount data:

       NOTE:  NO LONGER TRUE; ASMTAPES AT ML-29 (MXG 21.04+) NOW WILL
              CREATE A NEW SUBTYPE AND NEW DATASET TYPETARC FOR EACH
              TAPE ALLOCATION RECOVERY EVENT.  28AUG2003.

     PDB.ASUMTAPE (built from TYPETMNT, TYPETALO, and TYPE21) is a mount
     event dataset, and each observation tracks one tape mount from
     issuance of the mount until verification that the requested volume
     has been mounted.  The MNTTM is the Mount Pending Delay to the step
     for that specific mount event. You can have many Tape Mount Events
     with only a single Tape Device Allocation (e.g., multi-volume
     dataset).

     Tape Allocation Recovery cannot be measured from IBM Type 10 SMF
     "Allocation Recovery" records:

     An SMF Type 10 is only written when the operator/operator software
     replied to the IEF238 message with the DEVNR/UCBADDR of an offline
     tape device (that was then varied online by the system and given to
     that step as the allocation recovery).

     - This is not the normal way that allocations are recovered
     - You don't normally have tape devices offline
       (Late at night, your tape apes may vary offline those drives that
       are the furthest walk from the tape storage area, and then, as
       the workload arrives in the early morning, they will let
       allocation recoveries vary those drives back online!)
     - There is no start time of the delay in the SMF 10 record

     - The normal way an allocation is recovered, since you don't have a
       bunch of offline tapes, is for your operator/operator software to
       reply to the IEF238 message with WAIT, then reply either
         HOLD   - lets the step keep the devices already allocated
         NOHOLD - frees all devices already allocated
       which causes the step to wait until a tape device is freed by
       another job, and then that device is allocated to this delayed
       step, but there is no SMF 10 record written for these normal
       recoveries.

       Long ago a SHARE request was made to enhance the SMF 10 but
       discarded.  I have just sent a request thru my z/OS Technical
       Liason Consultant to re-open the possibility of writing an SMF 10
       for every Allocation Recovery event, with the addition of the
       Start of Delay datetime, and how the operator replied:
       DEVICE/WAITHOLD/WAITNOHOLD

     Tape Allocation Recovery delay might be inferable from the type 30
     step record, because the delay for allocation occurs during the
     period from Start of Allocation (ALOCTIME) until the Program Load
     (LOADTIME), and MXG variable ALOCTM=LOADTIME-ALOCTIME records the
     duration it took to allocate the step, but:

     ALOCTM is a function of the number of DDs in the step;
      -it takes more time to allocate a new dataset on DASD (must search
         all DSCB5's in the VTOC for best fit) than to allocate an old
         dataset on DASD (one VTOC read)
      -you don't know how many DDs are NEW/OLD in the 30
      -you must use a heuristic that compares the actual ALOCTM with an
         "expected-time-per-DD" times NUMDD to identify those steps with
         longer-than-reasonable ALOCTM durations as likely to have been
         delayed due to allocation recovery,

     but

     ALOCTM also includes the elapsed time to execute your site's ACS
         allocation rules

     and, much worse,

     ALOCTM also includes any delay due to HSM recall, and the step
           record has no clue that a recall occurred.

      -There is an HSM record written for each recall that is processed
       with TYPEHSM that could be merged to identify that the step did a
       recall, but the step could have had both a recall and an
       allocation recovery.

     It may be possible to use the MXGTMNT Tape Allocation dataset
     PDB.TYPETALO (one observation for each tape allocation event) and
     compare its start of each device's actual allocation with the
     ALOCTIME in PDB.STEPS to look for unreasonable delays that might
     have been caused by allocation recovery, but you would have to
     exclude dynamic allocations (they can be identified because their
     start in TYPETALO will be after the step's LOADTIME), and you would
     thus miss entirely any allocation recoveries for dynamic
     allocations (and DB2 database log offloads, for example, use
     dynamic allocation).

12.  APAR OW52227 revises the State Samples Breakdown in the WLMGL
     Report, as noted in the RMF Changes for z/OS 1.4:
     "Up to this release, state samples have been reported as a
     percentage of average transaction response time (response time
     breakdown). The response time is calculated when a transaction
     completes. This can result in percentages greater than 100 when
     samples are included for long running transactions which have not
     completed in the gathering interval (see also "Understanding
     Workload Activity Data for IMS or CICS" in topic 6.1).
     Percentages greater than 100 in the breakdown section are now
     avoided by showing the state values as percentages of the total
     transaction samples (state samples breakdown) instead of
     percentages of response time.
     This functionality is available as SPE and needs to be installed as
     APAR OW52227."

11.  APAR PQ67187 for TCP/IP states that SMF 118 record with negative
     byte counts (in the Bytes Out field) can occur when performing a
     GET with the FTP client.

10.  APAR OW55803 notes that you can see IEC705I "Tape ON devn" messages
     but still not get an SMF 14 or 15 record written, e.g., job ABENDS
     with a SYS 013 RC 20 or SYS 613 RC 20, because "tape ON" message
     is detected after data set labels have been created or destroyed
     (SL/AL mounted & NL requested). The APAR moves the detect/write of
     the IEF705I message until after the OPEN was successful, but does
     not alter that for ABEND conditions, SMF 14/15 records will not be
     created when an OPEN abend is detected; they are created only after
     CLOSE, EOV, and FEOV abends, or a successful open.

 9.  APAR OW56112 for JES3 TYPE 25 SMF record reports fixes incorrect
     count of scratch volumes, and in message IAT5110.

 8.  APAR OW56133 reports that an ABEND in SMF Interval Processing in
     MASTER forces a re-IPL.  0C4 in SMF Interval Processing IEFTB728
     was caused by someone having uncaptured a captured UCB, but SMF's
     ESTAE routine IEEMB836 was not designed to retry, percolating the
     ABEND to detach all of the TCBs at and below the Job Step TCB.
     Unfortunately, since the SMF Interval Processing was running in
     the MASTER address space, all TCBs in MASTER after the first four
     were abended, terminating SYSLOG, LOGREC, and IEEVWAIT task that
     attaches all commands that run in MASTER.  The PTF caused the SMF
     Interval processing to always return to the dispatcher, rather than
     percolate back to RTM.

 7.  APAR OW56457 reports SMF 19 records are written as SMF=0, after
     PTF UW86732 was installed.

 6.  APAR OW55788, various RMF III (RMFVSAM) problems including wrong
     values in ERB3GEN3 records, and incorrect Private Area size and
     address in VSTOR RMFIII report.

 5.  APAR OW55709, JES3 only, obscure situation, can create corrupted
     SMF 26 Purge Record for job who's output had been NJE'd and the job
     number of the job was greater than 32767.  ABEND in IATXSMF.

 4.  APAR OW52300 corrects an error while starting WLM managed inits
     to take a long time to start, and APAR OW53104 for JES2 may be
     involved to prevent errors if you are using JOBCLASS XEQCOUNT.

 3.  APAR OW56582 fixes problems with latch processing that causes the
     NQC field to increase improperly, causing a system hang (in one
     case, when a task holding RACF with SHR is swapped out for any
     reason, since it cannot be raised to PVLDP if the NQC is GT 1).
     While the primary task hit was RACF, the actual error is in GRS,

 2.  IDMS APAR Q020117 is required for IDSM Version 15 to correctly
     capture CPU time in the IDMLOG02 dataset created by VMACIDML.
     Without that APAR, the CPU time (STCTIMUS+STCTIMSU) was only 24%
     of the true CPU time.

 1.  HiperCache product caused MONTHBLD to ABEND erratically (last month
     ran fine), failing with messages about the TAPETEMP DD, either with
     an OUT OF BUFFER MEMORY error or INVALID FORMAT FOR ACCESS METHOD
     SASV6SEQ.  Some runs failed on the MONTH.JOBS (first), some after
     building many of the MONTH datasets (each using TAPETEMP). Messages
     SVCHxxxx identified HiperCache as owning TAPETEMP; disabling the
     HiperCache for this job eliminated the ABENDS.  You Remove/Add the
     job to/from the HiperCache JOBNAMES table depending on whether you
     enable by it default and EXCLUDE in JOBNAMES/ or vice versa.  BMC
     is replacing HiperCache with a MainView product, so not too much
     time will be spent, since disabling solved the errors.

IV.  DB2 Technical Notes.


V.   IMS Technical Notes.

 1. The JCLIMSLn/ASMIMSLn/TYPEIMSA programs leave the BMPS dataset in
    the //WORK library, because PIMSBMP=WORK is set by MXG default.
    If you want to have both IMSTRAN and BMPS datasets in one //IMSTRAN
    data library, you can use  %LET PIMSBMP=IMSTRAN; before the %INCLUDE
    of TYPEIMSA member, but then //IMSTRAN must always point to a disk
    dataset, because IMSTRAN.IMSTRAN and IMSTRAN.BMPS would be both open
    at the same time, and that's not supported if IMSTRAN is a tape.
    So to write the BMPS dataset to an IMSTRAN library that could be on
    either disk or tape, you would add this code after TYPEIMSA include:
      PROC COPY IN=WORK OUT=IMSTRAN;  SELECT BMPS;

VI.  SAS Technical Notes.

11. SAS/GRAPH Warning "The intervals are not evenly spaced" or "No minor
    tick marks will be drawn...." set CC=4 in SAS V8 (was CC=0 in V6).
    The SAS/GRAPH option NOGRAPHC on the GOPTIONS statement will force
    a return code of zero even with these warnings.

10. CA-ALLOCATE PTF is required for it to be able to extend SAS DASD
    datasets to multiple volumes. CA PTF Q022786 corrects errors,
    such as ERROR: Write to XXX.XXX.XXX failed. File is full and may be
    damaged.  SAS Note SN-008518 reports the CA error.

 9. Conversion from very old SAS Version causes SAS ERROR 22-322.
    SAS ERROR 22-322 with OTHER=?< $HEX2. ?> text will occur when you
    use %INCLUDE SOURCLIB(FORMATS); to update an old MXG format library
    that was originally created under Versions 5, 6, or 7 of SAS, as the
    physical architecture of SAS "Catalogs" have incompatibly changed.
    Just erase/scratch the old format file/dataset/catalog and rerun
    the FORMATS program to create a new format library under the new
    version of SAS.   If your MXG format library is that old, you should
    also check PDB/SPIN/WEEK/MONTH/TREND libraries that are probably of
    that old version, and you should create new datasets with SAS V8/V9
    and copy into them the old data, then delete the old, rename the new
    back to the old DSNAME, so all your SAS data libraries are in the V8
    architecture (which is unchanged in V9; you can read/write to/from
    V8/V9 SAS data libraries with SAS V8/V9).

 8. Benchmarks on z/OS 1.2 on z900 of SAS Version 9.0 and Version 8.2.

    This note was revised March 28, 2003.

    The V9.0 to V8.2 benchmarks reported in this note in Newsletter
    FORTY-TWO were invalid comparisons: FULLSTATS were enabled in V9.0
    but were disabled in V8.2.  The benchmarks were rerun with options
    NOSTATS NOFULLSTATS NOSTIMER NOFULLSTIMER NOMEMRPT for both versions
    and the results show that there is NO increase in CPU time for V9.0,
    and there is an significant improvement in elapsed run time with V9:

    Eight comparison tests are run.  S1 is the SAS initialization cost,
    S2 is the cost of both SAS and MXG Initialization.  S3, S4 and S5
    are single-data-step tests with program TYPE30 to measure compile
    cost (DD DUMMY), and the cost with 700MB and 2100MB input.  Steps
    S6, S7, and S8 are multiple-data-and-proc-step tests with program
    BUILDPDB with 0, 700MB, and 2100MB of input:

      S1 -  DATA _NULL_;  with // EXEC SASV9 - i.e., no MXG VMXGINIT
      S2 -  DATA _NULL_;  with // EXEC MXGSASV9, i.e. VMXGINIT executed
      S3 -  INC (TYPE30);   - MXGSASVn - with //SMF DD DUMMY
      S4 -  INC (TYPE30);   - MXGSASVn - with //SMF DD DSN=700MB  - 1x
      S5 -  INC (TYPE30);   - MXGSASVn - with //SMF DD DSN=2100MB - 3x
      S6 -  INC (BUILDPDB); - MXGSASVn - with //SMF DD DUMMY
      S7 -  INC (BUILDPDB); - MXGSASVn - with //SMF DD DSN=700MB  - 1x
      S8 -  INC (BUILDPDB); - MXGSASVn - with //SMF DD DSN=2100MB - 3x


                 SAS Version 9.00 TS M0        SAS Version 8.2 TS2M0

    Step         TCB  SRB  Elaps    SMF        TCB  SRB  Elaps    SMF
                 min  min  min     EXCP        min  min  min     EXCP

                Comparison with NO Statistics enabled in SAS options:

    S1 SAS       .00  .00   0.0    1029       .00  .00   0.0      660
    S2 MXG       .02  .00   0.1    1222       .02  .00   0.0      846
    S3 DUMMY     .03  .00   0.1    1551       .03  .00   0.1     1148
    S4 TYPE30   2.98  .01   4.9   34389      3.09  .01   6.3    33976
    S5 TYPE30   8.85  .03  13.5  100000      9.35  .03  27.1   100000
    S6 DUMMY    1.13  .01   2.9   28287       .97  .00   3.1    14324
    S7 BUILD    5.57  .03  10.7   74596      5.55  .02  14.5    60032
    S8 BUILD   12.15  .06  19.7  145000     12.41  .04  28.5   130000

   For all runs, the CPU time for V9 is the same or slightly less than
   the V8 CPU time, and the elapsed time with V9 is much less than V8.
   These runs are with the Pre-Production 9.00 release; we will re-run
   these same tests when the Production V9.1 is available for testing.


 7. New SAS V9 SYSMSG messages count blocks and I/O operations.

    SAS V9 on "MVS" prints new messages on SYSMSG for each SAS step with
    count of blocks and I/O operations for each SAS database that was
    accessed during that step:

      +SAS processed 21881 blocks and performed 4897 I/O operations
                on library SYS02311.T182432.RA000.DPTTSM01.WORK04.H01

    These messages count only I/O to SAS data libraries, catalogs, etc;
    there is no message for INFILE nor FILE I/O.  Tests with DD DUMMY
    and a known file, and the new count messages, show that:

    - I/O counts for INFILE/FILE that are passed by SAS into type 30
      "EXCP" counters are the number of Blocks, which is correct and
      consistent with IBM documentation for what should be recorded
      for sequential access datasets.

    - I/O counts for Data Libraries, Catalogs, etc, that are passed by
      SAS are NOT the number of Blocks, but instead are the number of
      I/O operations (counted as an SSCH or SIO in RMF).

      This is not new in V9, SAS has always done it this way, sending
      the count of "EXCP" macros in its IEASMFEX call, instead of the
      count of Blocks, but that inconsistency with expectations is now
      being reviewed by SAS Development.

      This "EXCP" confusion is understandable; an ASM programmer issues
      an IBM "EXCP" macro to do I/O, and thus counting "EXCP" macros for
      EXCP count is easy.  But each EXCP macro is serviced by IOS, which
      creates the SSCH (Start Sub-Channel, the channel program that does
      the real I/O), so an EXCP macro with BUFNO=5 will moves 5 Blocks
      as a result of that one "EXCP" macro the ASMer coded.

      And I fibbed in my example text of the new SAS message; the actual
      V9 text says "... and performed 4897 EXCPS on ..."; my example of
      "... 4897 I/O Operations on ..." was to stress what is counted,
      but is also a change under consideration by SAS development.

      Now that you understand what's in  the new messages, you can see
      they may be very useful, especially in diagnostics, to figure out
      how much was read/written from which library.  Those messages for
      the preceding V9 benchmarks show this raw detail on SYSMSG:

          Step  Elapsed   SMF    ==SAS MESSAGE: BLOCKS/"EXCPS"==
                min      EXCP          PDB                WORK

          S1     0.0     1033           -                29/12
          S2     0.1     1229           -               217/98
          S3     0.1     1555           -               332/137
          S4     3.6    29057           -              7047/1389
          S5    11.0    85046           -             21881/4897
          S6     5.3    28333       1013/632          12924/5681
          S7    19.2    77409       6795/1552         87453/25860
          S8    43.2   136999       7080/1637        114573/33363

     And:    TYPE30: had   33/33   to FORMATS,   261/149 to SASHELP.
             BUILDPDB:   1780/1780 to FORMATS,  2518/901 to SASHELP.
                        (MANY data steps in BUILDPDB, one in TYPE30)
             and BUILDPDB:  86/75  to SPIN, 13/7  to CICSTRAN.

 6. BMC reports Fix 361824, available from MAINVIEW Batch Optimizer MBO
    product support at 1-800-841-2031 corrects the failure associated
    with SAS and PAV volumes causing physical I/O errors on the SAS Data
    Library because related I/Os were processed out of order.  With the
    fix, a logical wait will occur between I/Os when the PAV feature is
    enabled. Mar 14, 2003.

    This was the original note:
    The BMC Optimizer Product Hiper-Cache feature appears to be the
    culprit that causes I/O errors when PAV (Parallel Access Volume) is
    enabled on ESS (SHARK) DASD volumes that are used for SAS WORK
    libraries, with these error messages in daily BUILDPDB jobs:
      EXPECTING PAGE 218, GOT PAGE -1 INSTEAD.
      PAGE VALIDATION ERROR WHILE READING WORK.XXXXXXX.DATA
      FILE WORK.XXXXXXX.DATA IS DAMAGED. I/O PROCESSING DID NOT COMPLETE
    but the errors did not repeat when the job was rerun without change.
        Two sites had daily job ABENDs about once a week for about a
        month; both have V8.2 and 82BX03 Hot Fix Bundle installed; one
        SHARK is in 3990 mode, and the other is in 2105-E20 mode.
    Those sites have now disabled the Mainview Optimizer product and the
    ABEND has not reoccurred (i.e., PAV and SHARK by themselves do not
    cause an error, only when Optimizer is also active).  To disable the
    Mainview Batch Optimizer product for a step, add these DD statements
        //DAP@NVPO DD DUMMY
        //DAP@NNPO DD DUMMY
    to the JCL for that step, or in MXGSASV8 JCL proc for all MXG steps.

    I conjectured that the erratic nature might confirm that PAV was
    involved; maybe only when there is concurrent use of the device,
    i.e. when the IBM code for PAV is active, that an exposure exists.

    SAS, IBM, and BMC Technical Support now are investigating GTF traces
    to locate the exact cause of the error, but the error has only been
    seen when Optimizer is active with both PAV and SHARK DASD present
    This note will be updated when a corrective fix has been determined.

    When PAV itself was the suspect, this note on how you would disable
    PAV was researched; it is kept here now only for future reference:
       Your Storage guru would use the IBM Storage Expert Application,
       that runs on the OS/2 platform that controls the SHARKs, to set
       the count of alias (PAVs) for a DEVNR to zero.

 5. New SAS Hot Fix Bundle 82BX03 now replaces all previous Hot Fix and
    Bundles, and should be installed on SAS V8.2 for MXG execution, as
    it corrects additional I/O errors SAS fixed after 82BA77 et al.
    30Oct02.

 4. From Scott Barry's posting to MXG-L, to create a datetime value in
    DDMMMYYYY.HH.MM.SS.SSSS (where separators must be dots, not colons):
       DATA _NULL_;
       NOWIS=DATETIME();
       DMYHMSS=TRANSLATE(PUT(NOWIS,DATETIME23.4),'.',':');
       PUT 'DDMMMYYYY.HH.MM.SS.SSSS=' DMYHMSS;

 3. COMPRESS=YES requires more virtual storage than COMPRESS=NO; this
    is not really a problem, just an FYI, and it only was noted in a
    data step with over 350 datasets being created; job took 93M with
    COMPRESS=YES, and "only" 81M with COMPRESS=NO.

 2. SAS USER COMPLETION CODE=1310 is a virtual memory problem; your JCL
    did not specify REGION= correctly, and/or your installation virtual
    memory limits are way too small for SAS.  There was no //SASLOG DD
    output created - no WELCOME TO SAS message ' as a further clue that
    SAS was never loaded in memory.  This occurred under SAS V8.


 1. A very strange "NOTE: EQUAL SIGN not found." on the SAS log occurred
    during the execution phase of a DATA/INFILE program when a new block
    of code (for a new subtype) was tested.  By inserting PUT statements
      (an ACM survey discovered that the number one debugging tool of
       all programmers is the insertion of "print" statements!)
    the note was created when record 1362 was read, but records 1350 to
    1361 were of the new subtype, so the new code had executed without
    producing the note; this note was somehow data-driven.  Examination
    of the new code found that a syntax error, an incomplete comment
    that swallowing following statements, was the actual cause!




VII. CICS Technical Notes.

 1. APAR PQ67142 reports discrepancies between the ABEND codes in CICS
    type 110-1 (CICSTRAN dataset) and the codes in DHFAC2236 messages.


VIII. Windows NT Technical Notes.

IX.   Incompatibilities and Installation of MXG 20.20.

 1. Incompatibilities introduced in MXG 20.20 (since MXG 19.19):
    See CHANGES.

 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.


X.    Online Documentation of MXG Software.

    MXG Documentation is now described in member DOCUMENT.


XI.   Changes Log

--------------------------Changes Log---------------------------------

 You MUST read each Change description to determine if a Change will
 impact your site. All changes have been made in this MXG Library.

 Member CHANGES always identifies the actual version and release of
 MXG Software that is contained in that library.

 The CHANGES selection on our homepage at http://www.MXG.com
 is always the most current information on MXG Software status,
 and is frequently updated.

 Important changes are also posted to the MXG-L ListServer, which is
 also described by a selection on the homepage.  Please subscribe.

 The actual code implementation of some changes in MXG SOURCLIB may be
 different than described in the change text (which might have printed
 only the critical part of the correction that need be made by users).

 Scan each source member named in any impacting change for any comments
 at the beginning of the member for additional documentation, since the
 documentation of new datasets, variables, validation status, and notes,
 are often found in comments in the source members.

Alphabetical list of important changes after MXG 19.19 now in MXG 20.20:

  Dataset/
  Member   Change    Description

  See Member CHANGES or CHANGESS in your MXG Source Library, or
  on the homepage www.mxg.com.

Inverse chronological list of all Changes:

Changes 20.341 thru 20.001 are contained in member CHANGES.

****************NEWSLETTER FORTY-ONE************************************









    MXG NEWSLETTER NUMBER FORTY-ONE, September 1, 2002

Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE

                         TABLE OF CONTENTS                          Page

I.   MXG Software Version 20.05.

II.   MXG Technical Notes

III.  MVS Technical Notes

24.  MSU, Million Service Units per Hour, will replace MIPS.
23.  APAR OW56033 for NPM/IP SMF record eliminates the creation of many
22.  APAR OW56001 will provide four zappable fields to customize SMF
21.  New RMF FICON data is not written to SMF by default; IBM default of
20.  TYPE42DS Data Set Statistics with no Statistics Section S42DSIOO=0,
19.  APAR OW55586 officially documents that swap data sets are no longer
18.  APAR OW52583 corrects blank value in SMF30PFL when a step is
17.  APAR OW55564 corrects zero value in SMF70SER (CPUSERnn) in first
16.  APAR OW55359 describes how SMF type 42 subtypes 15-19 (VSAM RLS)
15.  APAR PQ59911 for WebSphere Application Server V4.0.1 for z/OS and
14.  APAR OW53698 z/OS R1.2, ARCHLVL=2, plus reconfigure storage offline
13.  APAR OW47277 discusses in detail internal corrections for problems
12.  APAR OW54399 corrects problems in 64-bit mode at R10 and above that
11.  The new "Z2 mode" of JES2/JES3 INCOMPATIBLY changes the JCTJOBID
10.  "The writing of SMF record 117 is not documented and should have
 9.  APAR PQ57650 reports that RMF Type 79 subtype 15 (IRLM Long Lock)
 8.  APAR OW43846 reports incorrect value for SMF15NTU (variable TTRN in
 7.  APAR OW52822 alters how CLOSE macro options are handled for VSAM,
 6.  Item RTA000016291 responds to a comparison of the 3470 Get requests
 5.  APAR PQ60740 for TCP SMF record (confusingly listed as "TCB SMF",
 4.  APAR PQ58984 documents performance degradation for WebSphere V4.0.1
 3.  APAR OW54176 for OMVS USS fixes storage shortage in the OMVS ASID
 2.  RMF Reports from IBM incorrectly report IOSQ when a SysPlex report
 1.  APAR OW51126 documents that DASD Connect Time for Ficon Connections

IV.   DB2 Technical Notes.

 1.  APAR PQ53472 corrects internal lengths so that data areas for the

V.    IMS Technical Notes.

VI.   SAS Technical Notes.

16.  SAS Technical Note SN-001705 confirms that SAS Version 8.2 has no
15.  On MVS, MXG's CONFIGxx options specify MSGCASE, which overrides the
14.  Quick way to go from a SAS database on MVS to an EXCEL spreadsheet
13.  Support for SAS Version 9.
12.  How many //SORTWKnn DDs are needed for a large sort?  Divide the
11.  Reading a text file (under ASCII SAS) that contains CTRL+Z (Hex 1A)
10.  SAS HotFIX 82BA77 is still Strongly Recommended to correct errors;
 9.  An SMFTIME value of 'EE1B897F0102050F'x, created by Computer Ass
 8.  Required SAS Hot Fix Bundle is 82BX03 for Version 8.2 TS2M0 on MVS.
 7.  A "DOMAIN ERROR" (MVS only thus far) occurs when SAS V8 creates an
 6.  SAS V8.2 with SAS/SHARE can corrupt updated SAS datasets and/or
 5.  V8 COMPRESS=YES and SEQENGINE=V8SEQ compresses tape and disk data
 4.  If character variables that should have lower case values all have
 3.  SAS note SN-001262 reports a problem under unix that we have also
 2.  It turns out it IS possible to reassign the SOURCLIB fileref in
 1.  Under Windows with SAS V8.2, SAS fix 82BA62 corrected this error:

VII.  CICS Technical Notes.

 2.  A MAJOR change in CICS-DB2 Accounting occurs with DB2 Version 6 or
 1.  APAR PQ63141/PQ63143 adds new statistics to type 110 data.

VIII. Windows NT Technical Notes.

IX.   Incompatibilities and Installation of MXG 20.05.
         See member CHANGES and member INSTALL.
X.    Online Documentation of MXG Software.
         See member DOCUMENT.
XI. Changes Log
     Alphabetical list of important changes
     Highlights of Changes  - See Member CHANGES.

      COPYRIGHT (C) 2002 MERRILL CONSULTANTS DALLAS TEXAS USA

I.   MXG Software Version 20.05 is now available.

 1. Major enhancements added in MXG 20.05:

    See CHANGES.

II.  MXG Technical Notes


III. MVS Technical Notes.

24.  MSU, Million Service Units per Hour, will replace MIPS.

    I now believe that the IBM MSU, Million Service Units per hour, will
    replace MIPS, and that the MSU will be the primary metric to express
    CPU hardware capacity and/or workload consumption, whether or not
    MSU is also used for Software Pricing.  MIPS was a constant provided
    by a consulting company to describe your processor.  MSU is also a
    constant, but provided by IBM to describe your processor. For either
    constant, that constant and CPU seconds are used to describe and
    to measure your capacity and your capacity used in MIPS or in MSU.

    And since one MSU is about 5.8 MIPS, if your management still wants
    to see capacity in MIPS instead of MSU, you can just multiply the
    MSU values by 5.8 to report in MSU-based-MIPS.

    Dataset PDB.RMFINTRV reports MSU capacity and usage for each z/OS
    System ("image"); datasets PDB.ASUM70PR and PDB.ASUMCEC provide the
    MSU statistics for each LPAR and for the hardware ("CPC/CEC").

    -These are the important MSU-related variables:

      CECSUSEC - The IBM-supplied hardware constant raw CPU service per
                 CPU_SEC value of this CEC/CPC platform.  E.g. 10081 for
                 a 2064-104.  Multiply by 3600 times the number of CPU
                 engines and divide by a million to get the CPCMSU.
                 This is the "Software" Service Unit per Second factor
                 that is constant for all LPARs in a CEC.

      CPCMSU   - The total capacity of the CEC/CPC in hourly MSU rate.
                 E.g., the above 2064-104 is a 145 MSU platform.

      MSUINTRV - a count, and not a rate, is CPUseconds*CECSUSEC/1000000
                 and should not normally be used, since it is not a rate
                 and MSU's in general are rates.  It is used only for
                 calculations of rates; use only if you must sum counts.

      MSUPERHR - MSUINTRV * 3600 / DURATM  - is the interval count of
                 MSU (extended to an hourly MSU rate if the interval is
                 less than an hour).

      MSU4HRAV - MXG 4-hour rolling average MSU per hour from RMF
                 Interval data.  MXG calculates the value across an IPL,
                 "SPIN"ing the last four hours for tomorrow's input.
                 Always calculated.

      SMF70LAC - IBM 4-hour rolling average of the MSU rate.  Not
                 calculated when Hardware Capped.  Reset at IPL.

      SMF70WLA - The Defined Capacity of the LPAR MSU rate.  Zero if
                 capacity is not defined.  Based on LPAR share and CPC
                 capacity if Hardware Cap.


    -Al Sherkow's excellent research with IBM has found that:

      SU_SEC (in TYPE72GO) and LOSU_SEC (in TYPE30s) provides the factor
      for the HARDWARE MSUs.  SU_SEC does vary with the number of
      logical general purpose engines in the LPAR. On a single machine
      with LPARs that have different numbers of logical engines you will
      have different SU_SEC for each different LPAR.

      CECSUSEC (SMF70CPA) is used (ASUMMIPS) to compute the SOFTWARE MSU
      capacity of the machine, and it is always based on the number of
      physical engines on the entire machine, not just those assigned to
      an LPAR.  As IRD or VARY change the number of logical GP engines
      in an LPAR SU_SEC changes also, but SMF70CPA does not.

      CECSUSEC (SMF70CPA) changes with physical engine changes, such as
      Upgrades, CBU testing and Capacity on Demand. With CBU testing
      SU_SEC does not change until some of those new physical engines
      are VARY'd into the LPARs.

      The WLM measures MSU for its 4-hour rolling average and max values
      based on 10 second samples of "LPAR Effective CPU Time", averaged
      over a five minute period.

      This value is used internally by WLM when managing (i.e. Soft
      "capping") to "Defined Capacity", but those 5-minute data values
      are not written to RMF 70 records.

      SMF70LAC, IBM's 4-hr Average Hourly MSU, contains the most recent
      calculation of the 4-hr average.  It was calculated within the
      last 5 minutes but represents four hours of data from those 5
      minute data values.

      The WLCTool uses SMF70LAC when it exists but also supports data
      from machines running in basic mode, using their existing RMF data
      and reports at the customers SMF interval.

      The Sub Capacity Reporting Tool uses SMF70LAC.

      The SMF 99 subtype 1 record field SMF99_SLAvgMsu has the current
      WLM view of the four hour average in 48 service buckets with the 5
      minute interval data.  The buckets are broken up by service
      accumulated with the partition was capped and while the partition
      was uncapped.

    -MXG can never exactly match the IBM 10-second sampled MSU values
     from WLM 5-minute buckets using RMF interval data, especially for
     the maximum values, but using 15 minute or hour intervals still
     provides very accurate MSU measures, as demonstrated below.  The
     RMFWDM command was issued at 12:43 and is compared to the 15-minute
     RMF interval at 12:30, and with the hour RMF interval starting at
     12:00:

                                                  Hourly MSU Rate
                                             4-hr Average    Maximum

               RMFWDM snapshot                       41        58
               IBM SMF70LAC in 12:30 RMFINTRV        42        43

               MSU4HRAV (RMFINTRV 15-min data)       41.95     44.4
               MSU4HRAV (RMFINTRV hourly data)       40.28
               MSUPERHR (RMFINTRV 15-min data)                 55.4
               MSUPERHR (RMFINTRV hourly data)                 43.8
               IBM SMF70LAC (one hour RMFINTRV)      43        43

               5-min max=58, 15-min max=55, hour max=44, LAC max=43

                 STARTIME MSUINTRV MSUPERHR MSU4HRAV SMF70LAC

                 08:30:00   11.48    45.93    33.93     31
                 08:45:00   13.84    55.37    35.88     33
                 09:00:00   11.08    44.35    37.01     35
                 09:15:00    8.78    35.14    37.57     36
                 09:30:00   12.66    50.55    39.07     36
                 09:45:02   13.16    52.62    40.56     38
                 10:00:03   10.17    40.77    40.91     40
                 10:15:01   10.73    42.94    41.57     40
                 10:30:01   10.88    43.48    42.30     41
                 10:45:02   10.58    42.35    42.99     41
                 11:00:02   11.18    44.65    43.66     42
                 11:15:04   10.93    43.81    44.48     43
                 11:30:02    9.75    38.98    43.78     43
                 11:45:02    7.89    31.58    43.89     43
                 12:00:02    9.55    38.20    43.54     43
                 12:15:02    9.79    39.20    43.18     43
                 12:30:01    6.65    26.61    41.95     42
                    (This system had SMF70WLA=50, CPCMSU=118.92)

                   This LPAR was the 10th LPAR; PDB.ASUMCEC/PDB.ASUM70PR
                   had these values for 10th LPAR's LPn variables:

                      STARTIME  LPALAC   LPAMSU   LPAMSUHR   LPAMSU70
                       12:30       42      6.65      26.62       50

    -MXG'S MSU calculations use the total LPAR CPU time (LPAR Partition
     Dispatch CPU time), because that is the MSU the LPAR really
     consumed, and that is what you should use for (conservative)
     capacity measurement.  But because the CPU Dispatch time is
     slightly larger than the CPU Effective, and because IBM samples the
     Effective CPU to calculate SMF70LAC for WLC Software Charging,
     MXG's MSU4HRAV can be slightly larger than IBM's SMF70LAC (and
     recall that the value in SMF70LAC is a truncated integer).

    -Keith Munford has also observed that:
      -With Defined Capacity and Hard Capping both enabled:
       -The value in SMF70LAC (4-hr average) is zero; IBM has APAR
         OW55509 open internally and LAC should be fixed.  However,
         MXG's MSU4HRAV variable is always valid.
       -The value in SMF70WLA is not the Defined Capacity that you set
        on the HMC Management Console for that LPAR, but instead
        SMF70WLA is the MSU rating of the CPC, weighted by the LCPUSHAR
        for the LPAR:
         E.g.:   WLA Set Value = 18    CPCMSU = 119
               LCPUSHAR = 43 (out of 299) = 14.38%
               IBM recorded  SMF70WLA=17  (.1438*119=17.11).
      -With Defined Capacity not enabled but with Hard Capping enabled,
       SMF70LAC is still zero, and SMF70WLA is again the CPCMSU rating
       weighted by its LCPUSHAR:
         E.g.:   WLA Set Value = none  CPCMSU = 153
               LCPUSHAR = 85 (out of 400) = 21.25%
               IBM recorded SMF70WLA=33 (.2125*153=32.51).

    -The text of MXG Changes 20.046, 20.043, 19.083, 19.018 and 18.317
     all had something to say about WLA and MSU; some were revised to be
     accurate when read now, and to be consistent with what is now
     known.  See also Changes 20.168, 20.169 for associated MSU notes.

23.  APAR OW56033 for NPM/IP SMF record eliminates the creation of many
     duplicate observations.  As long as you used MXG to sort the data
     in NPMIP01 or NPMIP02 datasets into your PDB, those duplicates were
     automatically removed, but this APAR eliminates their creation.
     16Aug02.

22.  APAR OW56001 will provide four zappable fields to customize SMF
     buffer options (minimum size, expansion increment, etc?).  No date
     set yet for its availability.  15Aug02.
     04Oct02: PTFs now exist, and the text of this APAR has extensive
     documentation of how SMF buffers are allocated and how you can
     prevent loss of SMF data due to "spikes" in SMF data volume.

21.  New RMF FICON data is not written to SMF by default; IBM default of
     NOFCD must be changed to FCD in ERBRMFxx member in SYS1.PARMLIB.

20.  TYPE42DS Data Set Statistics with no Statistics Section S42DSIOO=0,
     have missing values in D42DSIOR thru S42DSMXs are reportedly caused
     by BMC's Mainview Batch Optimizer 2.2.0 (data optimizer component),
     and BMC is working on a fix.  7AUG02.

19.  APAR OW55586 officially documents that swap data sets are no longer
     supported, starting with z/OS, and the SMF 75 mapping no longer
     mention "Swap Data Sets", but only refer to "Page Data Sets".
     It also corrects errors in TYPE74CF Coupling Facility R744RSST.

18.  APAR OW52583 corrects blank value in SMF30PFL when a step is
     skipped via the COND parameter when using SCHENV JCL Parm in WLM.

17.  APAR OW55564 corrects zero value in SMF70SER (CPUSERnn) in first
     RMF interval, after OW53929 has been installed.   This would impact
     the PDB.ASUMCEC dataset, since the CECSER is taken from SMF70SER.

16.  APAR OW55359 describes how SMF type 42 subtypes 15-19 (VSAM RLS)
     can be accidentally not written.

15.  APAR PQ59911 for WebSphere Application Server V4.0.1 for z/OS and
     OS/390 is an internal defect fix and new function APAR to provide
     the complete Java interface, and the Web Container will use this
     interface to sent web container activity (such as HttpSession and
     servlet) to the SMF data, in the form of two new subtypes (7,8) to
     the SMF type 120 record.  An MXG change to VMAC120 will be needed.
     21Jun2002.

14.  APAR OW53698 z/OS R1.2, ARCHLVL=2, plus reconfigure storage offline
     command corrupts OUXB fields (which show up in type 30 records in
     service unit fields (SERVICE,CPU,SRB,MSO) to be billions.  IBM says
     to IPL and set RSU=0,REAL=0 in IEASYSxx to tell z/OS the system has
     no reconfigurable storage, so the function (take storage offline).
     that causes the corruption will never be invoked.  21Jun2002.
     My comment: don't reconfigure storage offline.

13.  APAR OW47277 discusses in detail internal corrections for problems
     found during the tests of LPAR CPU Management and License Manager
     in OS/390 R11. 19Jun2002.

12.  APAR OW54399 corrects problems in 64-bit mode at R10 and above that
     surfaced as lots of auxiliary paging slots in use, periodic high
     page rates, and high UIC and high AFQ.

11.  The new "Z2 mode" of JES2/JES3 INCOMPATIBLY changes the JCTJOBID
     field, which impacts not only the JESNR and TYPETASK variables in
     many MXG datasets, but may impact applications, exits, utilities
     and vendor products, especially message-based automation products,
     that use or display JOBID, JESNR, or TYPETASK.  The z2 mode of JES
     was released with z/OS 1.2, but there was no vendor alert from IBM!
     This new mode permits 200,000 jobs and 999,999 job numbers, with
     current JOBID format JOBnnnnn/TSUnnnnn/STCnnnnn format replaced
     with Jnnnnnnn/Tnnnnnnn/Snnnnnnn/Onnnnnnn format when z2 mode is
     enabled. Only 999,999 job numbers can be used; the first digit of
     the seven-digit JESNR is always a zero.
        (The old mode of JES is now called "OS/390 Release 4
        Compatibility Mode").  Many exposures are documented by IBM in
        JES2/JES3 Flash 10114, dated November, 2001, at this url:

 http://www-1.ibm.com/support/techdocs/atsmastr.nsf/PuballNum/Flash10114

     MXG Change 20.101 documents the (VERY MANY) MXG members that have
     to be modified to fully support the Z2 mode; that Change will be in
     MXG Version 20.03, to be available later this month. 12JUN02.

     Added 19Aug02:  These new JESNR values can be seen on an OS/390
     system, if that system is part of a JESplex that has a z/OS 1.2
     system; jobs read in on the z/OS 1.2 system that are then sent to
     the OS/390 system will carry thru the original 7-digit JESNR.

     And Levi, Ray, and Shoup's VPS product's maintenance to support the
     z/OS operating system will also create the 7-digit JESNR, even when
     running under OS/390 R2.10.


10.  "The writing of SMF record 117 is not documented and should have
     been removed on an earlier release of MQSeries/390.  It was not
     meant for customer usage."  APAR PW60966.  06Jun02.

 9.  APAR PQ57650 reports that RMF Type 79 subtype 15 (IRLM Long Lock)
     has blank DBNAME in field R79FRSNA, when the database is DL/I (but
     not if the DB is FP). 06Jun02.

 8.  APAR OW43846 reports incorrect value for SMF15NTU (variable TTRN in
     dataset TYPE1415) for striped extended format datasets that go thru
     partial release.  6Jun02.

 7.  APAR OW52822 alters how CLOSE macro options are handled for VSAM,
     and cannot be installed with OBJECTSTAR, and could impact other
     applications.  From the APAR text:
     "It is documented in the 'Macro Instructions for Data Sets'
     publication that the CLOSE macro options should be ignored for VSAM
     ACBs but CLOSE was not ignoring them. Specifically the FREE option
     of CLOSE and it's corresponding FREE=CLOSE JCL parameter were
     incorrectly being honored causing the VSAM data set to be
     prematurely unallocated by CLOSE.  IFG0202L was modified to ignore
     all CLOSE options for VSAM ACBs.  It should be noted that any
     application that depended upon the VSAM data set being unallocated
     by CLOSE will need to be modified prior to this APAR being
     installed. Otherwise, the application could fail."

     Object Star Flash May 27, 2002 :
     "Situation:
      IBM has released APAR OW52822 for z/OS which can adversely affect
      the behavior of ObjectStar.  This APAR removes the ability to
      de-allocate a closed VSAM data set (FREE=CLOSE).  If this APAR is
      applied, VSAM data sets, including Pagestore data sets, Journals,
      and the DBDLIB, will be unavailable for processing in offline mode
      if they have been opened by the Data Object Broker.
     Corrective Action
      DO NOT apply this APAR until a suitable ObjectStar solution can be
      developed and tested."

     There is no indication in SMF records that FREE=CLOSE was used in
     any program, for VSAM or non-VSAM.   31May2002.

 6.  Item RTA000016291 responds to a comparison of the 3470 Get requests
     in SMF 110 data with the SMF 64 count of 10999 retrieves (while the
     count of deletes, inserts, and updates were identical).  IBM reply:
     "CICS stats record the activity requested by the CICS application,
     and NOT the number of SIO/EXCPs required to satisfy each request.
     Unless a VSAM KSDS is using LSR and there are a sufficient number
     of buffers in the LSR pool to hold the entire sequence set, then it
     is likely 2 SIOs will be required for each GET or GET UPDATE issued
     by an application program.  And if the entire index set is not in
     memory, then more than 2 SIOs will be required."
     See MXG member ANALBLSR and ADOCBLSR to enable BLSR (recommended!).

 5.  APAR PQ60740 for TCP SMF record (confusingly listed as "TCB SMF",
     because TCP/IP development uses "TCB" for "TCP Control Block"),
     documents that variable CURRESTA (Current ESTABS) in the Stat
     record (dataset TYPETCPS) can be negative.  OPEN as of 20May02.

 4.  APAR PQ58984 documents performance degradation for WebSphere V4.0.1
     for z/OS and OS/390, when SMF server and container interval records
     were turned on.  The APAR text describes the design changes in how
     WebSphere creates SMF records (available now in PTF UQ66083) that
     improve the SMF recording performance (by eliminating and reducing
     many calls and restructuring string objects).  The observed impact
     of WebSphere SMF records, before the APAR, reported that LoadRunner
     response dropped from 400 per second at .04 seconds response, to
     130 per second at .16 seconds when pre-APAR SMF was turned on, but
     no post-APAR statistics were reported.

 3.  APAR OW54176 for OMVS USS fixes storage shortage in the OMVS ASID
     caused by failure to free the DSSB Control Block when an hfs was
     unmounted. 20May02.

 2.  RMF Reports from IBM incorrectly report IOSQ when a SysPlex report
     is requested; one-system-report request  (WLMGL(RCPER,SYSNAM(AB)))
     will properly report the IOS Queue Time.  See APAR OW53514.

 1.  APAR OW51126 documents that DASD Connect Time for Ficon Connections
     includes both productive connect time, and delays due to multiplex
     delays in the Ficon architecture, and changes the way WLM measures
     the I/O delay contribution to Performance Index, by replacing the
     measured connect time with a fixed 1 millisecond per Ficon I/O
     request, in the WLM calculation of PI when I/O Priority Management
     is in effect.

IV.  DB2 Technical Notes.

 1.  APAR PQ53472 corrects internal lengths so that data areas for the
     DISPLAY DATABASE CLAIMERS, LOCKS, and USE are valid.

V.   IMS Technical Notes.


VI.  SAS Technical Notes.

16.  SAS Technical Note SN-001705 confirms that SAS Version 8.2 has no
     problems with OS/390 thru R2.10, nor with z/OS, nor with the 64-bit
     hardware of z900-z/800s, nor with larger real storage addresses.

15.  MXG's CONFIGxx options (MVS only) specify MSGCASE and CAPSOUT which
     override the SAS defaults of NOMSGCASE and NOCAPSOUT, so that all
     MVS SAS output and messages are upper case: some printers did not
     support lower case and printed garbage with SAS defaults, and JCL
     text you create must be upper case.  This is a problem when you
     need to create lower case text under SAS on MVS (for example, for
     case-sensitive passwords when you ftp to non-MVS sites); you will
     need to specify OPTIONS NOMSGCASE NOCAPSOUT; for that program.
       Also: SAS/GRAPH may refuse to print graphs if you use CAPSOUT.

     MXG's AUTOEXEC (ASCII execution only) does not change the defaults,
     since SAS under ASCII has always supported mixed case.

     Mar 6, 2007:  CAPSOUT is ONLY valid on z/OS; OPTIONS CAPSOUT; under
                   ASCII SAS you get ERROR Unrecognized option name.

14.  Quick way to go from a SAS database on MVS to an EXCEL spreadsheet
     if you have SAS Connect; there is an upper limit on how many rows
     EXCEL can handle (but if that is exceeded, there is an option to
     create a comma separated values or tab delimited or DBASE or ACCESS
     output file that can be imported:
        Start a CONNECT session
        Issue a LIBNAME command
        Go To FILE/EXPORT and follow the onscreen directions.
     And the inverse function, to read the EXCEL file into a SAS dataset
     is there, under FILE/IMPORT.

13.  Support for SAS Version 9.

     A more extensive technical note on SAS V9 will be written in a
     later Newsletter article, but initial tests are very encouraging:

    -MXG has been tested under SAS Version 9 Early Adopter Release on
     both z/OS and Windows platforms, with no errors, and with no data
     incompatibilities between V8 and V9.  Data libraries and catalogs
     built with V8 can be read and written with SAS V9, and libraries
     and catalogs built with V9 can be read and written with SAS V8.

     Following paragraph was revised, March 1, 2003:
     Although the V9SEQ sequential engine was supposed to have been
     redesigned as we have wanted, i.e., it was supposed to NOT honor
     the OPTIONS COMPRESS=YES global option, the V9SEQ engine still does
     compress tape datasets, so SEQENGINE=V6SEQ is still the MXG default
     in CONFIGV8 and CONFIGV9.  We do NOT recommend the use of either
     the V8SEQ (which has destructive errors) nor the V9SEQ (because it
     still compresses tape datasets, even in the V9TSM0 Release.
     Since all "MVS" tape devices have hardware compression, you don't
     want SAS to also use software compression and CPU time when writing
     to tape.  And if you write a large dataset in sequential format to
     DASD, so that it can be an extended-format and hardware-compressed
     file, again, you don't want SAS to also use software compression.
       But if you ever should need to have SAS software compress data
       that is written with the sequential engine, you can still use the
       COMPRESS=YES option on your DATA statement, and SAS will honor
       your request and compress that dataset and write to that device.

     Very briefly, in MXG 20.04 and 20.05, there was a CONFIGV9 member
     that did not have a SEQENGINE option, so those two releases did use
     the V9SEQ engine, but in MXG 20.06 (but not documented with a
     Change), the CONFIGV9 was changed to specify SEQENGINE=V6SEQ.

    -Noted in testing the Early Adapters Release, to be corrected in
     SAS V9.1 or later:

     Almost too obscure to document: on MVS (in CONFIGxx), MXG changes
     the SAS default option from NOMSGCASE to MSGCASE (so SAS Messages
     are printed in upper case), but in the V9 Early Adopter release, if
     you enabled its new DLEXCPCOUNT option (displays EXCP counts on the
     MVS log), those counts are corrupted; using  OPTIONS=NOMSGCASE;
     correctly printed the counts, and this error is fixed in real V9.
       Note 15Nov2002: Fixed in SAS V9.1 per Usage Note SN-008247.

     The message "WARNING: Compression was Disabled ...." set a Return
     Code (a/k/a Condition Code) of four.

12.  How many //SORTWKnn DDs are needed for a large sort?  Divide the
     size of the file to be sorted, in MegaBytes, by 1000, round up to
     the next integer, and allocate that many 1500 cylinder sort works:
       A work file of 1500 cylinders will be easier to allocate during
         peak use of your work pool, to avoid allocation failure reruns.
       Each file of 1500 cylinders holds about 1180 MegaBytes.  Using a
         divisor of 1000 instead of 1180 and rounding adds 20-25% extra
         work space for the sort program.

11.  Reading a text file (under ASCII SAS) that contains CTRL+Z (Hex 1A)
     character is stopped at that character, because it is treated as an
     end of file character.  In SAS V8.2 and later, a new option exists,
     IGNOREDOSEOF, which will allow these characters to be read.

10.  SAS HotFIX 82BA77 is still Strongly Recommended to correct errors;
     a new problem is caused by that fix and reported under SN-007513,
     but that error ONLY applies to the use of PROC SOURCE, and 7513 has
     a back-out zap if you encounter the 0C1 running PROC SOURCE after
     you have installed 82BA77.  12Jun02.

 9.  An SMFTIME value of 'EE1B897F0102050F'x, created by Computer Ass
     products that overlay the first byte of time field with 'EE'x or
     'EF'x, is invalid for SMFSTAMPw informat, but SAS does not error.
     Instead, SAS treats the time part's first bit as a negative, so the
     time value is several days earlier.  SAS will not correct SMFSTAMP.
       The real source of the problem, of course, is CA - for every case
       in which they overlay the Reader Time Field, they are supposed to
       provide code for your CA guru to install in the appropriate SMF
       exit (IEFU83/U84/U85) that removes their overlay, so your CA guru
       needs to read the installation notes and do it right.  But if SAS
       had chosen to detect and report the invalid time value, you would
       know you have invalid SMF data from CA, and could get it fixed.

 8.  Required SAS Hot Fix Bundle is 82BX03 for Version 8.2 TS2M0 on MVS.
     This note in Sept had 82BA77, but was revised Oct, 2002.  The new
     SAS Hot Fix Bundle 82BX03 is now required for MXG under "MVS".  The
     new 82BX03 bundle includes 82BB15, 82BA77, and 82BA57, so the fixes
     SN-006609,SN-007032,SN-006754,SN-007000,SN-007065, and SN007066
     are included, but there are new fixes after 82BA77 that correct new
     I/O errors; it is ALWAYS wises to install the current SAS Hot Fix.


 7.  A "DOMAIN ERROR" (MVS only thus far) occurs when SAS V8 creates an
     invalid internal value for a floating point data value read with RB
     (floating point) informat.  With RB informat, SAS does not validate
     that the exponent is valid (because of performance concerns), and a
     data value of '0000000000000001'x creates invalid data values with
     no error message on the SAS log at time of create.  Only later when
     the data are read with PROC MEANS does the "DOMAIN ERROR" message
     print on the log, stopping the job, with no identification of what
     variable contained the invalid data.  (Under PC SAS, wrong values
     like 1E-74 are created, but do not cause the DOMAIN ERROR.)

     But the ultimate cause of the DOMAIN ERROR is the incorrect use of
     RB informat, or a mis-alignment in MXG's INPUT logic.  Thus far:
      Change 20.051, SMF 89, the field should have been INPUT with PIB.
      Change 20.050, SMF 78, MXG's INPUT statement was mis-aligned.
      Change 20.083  SMF 79, MXG should have used PIB instead of RB.
      Change 20.097  SMF 91, SDI/SDO doc RB wrong, fields are PIB.

 6.  SAS V8.2 with SAS/SHARE can corrupt updated SAS datasets and/or
     cause DOMAIN ERROR condition.  SAS/SHARE Hot Fix 82SH02 has their
     downloadable correction.  21Mar02.

 5.  V8 COMPRESS=YES and SEQENGINE=V8SEQ compresses tape and disk data
     sets, and there is no global option to disable tape compression.
     You do NOT want to compress tape data, because all tape drives have
     hardware compression, so software compression only wastes CPU time.
     And even tape-format datasets written to disk should not use SAS
     software compression, since they can be written to extended-format
     datasets that are hardware compressed on modern disks.

     Luckily, MXG 19.19 CONFIGV8 Options still sets  SEQENGINE=V6SEQ
     (early V8 SEQ had errors, not fixed until V8.2) and the V6 tape
     engine never compressed tape datasets, so MXG 19.19's addition of
     COMPRESS=YES (accidentally!) only compresses SAS disk data sets.

     I have opened a dialogue with SAS Technical Support to eliminate
     compression of tape datasets (or at least default tape compression
     off, and provide an option, if someone somewhere can actually show
     that there is an advantage to them to compress tape datasets).

 4.  If character variables that should have lower case values all have
     upper case values instead, it is because MXG's CONFIGxx members for
     MVS set the SAS option CAPSOUT, which converts all lower case to
     upper case.  Specify  OPTIONS NOCAPSOUT; if you want both cases.

 3.  SAS note SN-001262 reports a problem under unix that we have also
     caused on MVS:  if you have //USER DD or if you have a directory
     named "user" off of the sas root, the USER environmental variable
     is not ignored in V8 like it was in V6, and data sets are sent to
     the USER libref instead of WORK, but subsequent reference expects
     it in WORK, so it is not found!  Don't use //USER or don't have a
     directory named user, or you can add  -user  work   to your config
     file to circumvent this problem.

 2.  It turns out it IS possible to reassign the SOURCLIB fileref in
     your MXG jobs, although it is not clear that you would want to, but
     an MXG site that successfully had reassigned SOURCLIB in their PDB
     job years ago found that their statements FILENAME SOURCLIB CLEAR;
     with "FILE IS ALREADY OPEN" when testing MXG 19.19.  After much
     research, a call to SAS Institute Technical Support revealed that
     this has been a documented limitation since SAS Version 6 in their
     Technical Note V6-4731: you cannot clear an AUTOCALLed LIBREF.  I
     was ready to accept this, and the site redesigned without the need,
     but a complete description from SAS developers of the limitation:
        Once the autocall libraries have been searched, filerefs remain
        assigned until both SASAUTOS= option is changed AND there is a
        subsequent request for an autocall macro.  If it is recognized
        that the new SASAUTOS= option is different, then the filerefs
        associated with the previous SASAUTOS are cleared, and the new
        filerefs are assigned and are the new autocall list.
     showed a circumvention was available, if this were ever really
     needed.   You can reassign SOURCLIB if you first change the current
     SASAUTOS= option, then autocall a macro from the new SASAUTOS, so
     that then you can clear the SOURCLIB fileref, and then can reassign
     SOURCLIB to the new source libraries (for %INCLUDEs), and reset the
     SASAUTOS= option to resolve %macros from the reassigned SOURCLIB.

     Here is an example of what you would need to do.  The "MDUMPEBC"
     %MACRO exists only in member/file MDUMPEBC in the MYSTUFF fileref:

         // EXEC MXGSASV8
            FILENAME MYSTUFF 'D:\MXG\MYSTUFF';
            OPTIONS SASAUTOS=MYSTUFF;
            %MDUMPEBC(DUMPIN=SMF,FIRST=1,LAST=1);
            RUN;
            FILENAME SOURCLIB CLEAR;RUN;
            FILENAME SOURCLIB ('D:\MXG\USERID' 'D:\MXG\SOURCLIB') ;
            RUN;
            OPTIONS SASAUTOS=(SOURCLIB SASAUTOS);
            RUN;
            %INCLUDE SOURCLIB(TYPE0);RUN;


 1.  Under Windows with SAS V8.2, SAS fix 82BA62 corrected this error:
     FATAL ERROR: WRCODE=80000805, MODULE='wtdelet': Unexpected return
     from vtswtch().



VII. CICS Technical Notes.

 2.  A MAJOR change in CICS-DB2 Accounting occurs with DB2 Version 6 or
     later when called from CICS Version 2.2 or later, i.e., OTE.

     The change is documented in CICS DB2 Guide for CICS/TS for z/OS
     Version 2.2, Section 9.11.4, titled 'Calculating CICS and DB2
     Transaction Processor Times for DB2 Version 6 or later'.

    -Key points:

     This is the new Open Transaction Environment, OTE.

     CICS must be at V2.2 and DB2 must be at V6 for this to happen.

     With DB2 V6, DB2 CPU time is now recorded in SMF 110s in CICSTRAN!

     Do NOT add DB2ACCT DB2TCBTM to the CICSTRAN CPUTM with OTE!

     Some CICS CPU time is now also recorded in the DB2TCBTM in DB2ACCT.

     It is only the SMF 110 subtype 1 CICS transaction data (CICSTRAN)
     and the DB2 SMF 101 (DB2ACCT) CPU times that are changed.  With or
     without OTE, when CICS calls DB2, the DB2 CPU time continues to be
     captured in the CICS type SMF 30 records (for the calling address
     space), and that DB2 CPU time is also captured in the CICS RMF 72
     Service Class or Performance Group data, and it is also captured in
     the SMF 110 subtype 2 CICS statistics data (CICDS or PDB.CICINTRV).

     This is the new OTE Open Transaction Environment architecture, and
     the accounting change applies to both THREADSAFE and non-THREADSAFE
     transactions.

     For transactions that are declared as THREADSAFE, OTE can reduce
     the real CPU time significantly (especially for transactions that
     make many DB2 calls).  However, the capture of DB2 time in CICSTRAN
     and CICS in DB2 is a result of the OTE architecture and thus it
     occurs whether the transaction is threadsafe or not.
       So expect CICS CPUTM to be less for THREADSAFE transactions.

     Thread create and thread terminate CPU time is now captured in the
     CICSTRAN and DB2ACCT records for the transaction that created or
     terminated the thread; previously this was uncaptured in both.

    -IBM's note (mildly edited) states:

     "When CICS is connected to DB2 Version 6 or later, the CICS DB2
     attachment facility uses CICS-managed open TCBs rather than CICS
     subtask TCBs.  This means that the CICS monitoring facility can
     measure activity that was previously only reported in the DB2 SMF
     101 accounting record, such as processor time consumed in DB2 (the
     Class 1 and Class 2 CPU time).  For example, the L8 open TCB CPU
     time captured by CICS does include all DB2 Class 1 CPU time.

     When CICS is connected to DB2 V6 or later, do not add together the
     CPU time from the CICS (SMF 110-1) and the DB2 accounting (SMF 101)
     records when calculating the total CPU time for a single
     transaction, because the DB2 CPU time would then be included twice.

     The total CPU time for a single CICS transaction is simply the CPU
     time from the CICS record, performance class, data field 008, field
     name USRCPUT (MXG variable TASCPUTM).  This field includes all the
     TCB CPU time used by the transaction when it was running on any TCB
     managed by the CICS dispatcher, including L8 TCBs, the QR TCB, and
     TCBs in any other modes."

    -My additional comments:

     All CICS transactions connected to DB2 V6 do exploit the OTE (open
     transaction environment), which was not clear from that IBM note.

     While all MXG notes telling you to use ASUMUOW program to combine
     CICSTRAN and DB2ACCT data to create and then use PDB.ASUMUOW to get
     the total CPU time for account for CICS+DB2 are now wrong with OTE,
     ASUMUOW does not add the two CPU times together; (luckily?) they
     are kept in two separate variables, so you must check to see if you
     were using their sum for you CICS billing and capacity measurement.

     Since the total CICS+DB2 billable CPU time is now captured in CPUTM
     in CICSTRAN, you may not need to create PDB.ASUMUOW for your CICS
     and DB2 chargeback and capacity measurement.  However, ASUMUOW is
     still valuable for its other DB2 metrics.  And even without DB2,
     ASUMUOW combines all of the TOR, AOR, FOR, etc., MRO transactions
     from CICSTRAN into one ASUMUOW observation for each UOW (and with
     the real TRANNAME from the AOR and the real LUNAME from the TOR!),
     and lots fewer observations for billing and capacity measurement.

     IBM's note is correct that USRCPUT/TASCPUTM does contain all of the
     CICS and DB2 TCB CPU time for the combined activity, but that isn't
     the total CPU time that is captured in CICSTRAN.  Instead, the MXG
     variable CPUTM in CICSTRAN is the sum of TASCPUTM + RLSCPUTM and is
     the correct total CPU time to use for billing and capacity,
     because the RLSCPUTM (field 175, RLSCPUT) is SRB CPU time that is
     not included in TASCPUTM.  (Fortunately, RLSCPUTM is rarely large,
     so if you've been using TASCPUTM instead of CPUTM, your numbers may
     be okay, but variable CPUTM in all MXG datasets is the one variable
     to use for the total unoverlapped captured CPU time!)

     IBM's note also states that the CPU time captured in the SMF 110
     will be larger with DB2 V6+:
       The CICS L8 CPU time also includes the cost of creating a DB2
       thread.  With DB2 V5 or earlier, this CPU time was not captured
       in either CICSTRAN nor in DB2ACCT.  With DB2 V6 or later, if a
       transaction causes a DB2 thread to be created, the thread create
       CPU time is charged to the creating transaction, and, if at the
       end of a CICS transaction, the thread is terminated (because it
       is unprotected and no other task is waiting to us it), that
       thread terminate CPU time is charged to that transaction."

     Finally, the Class 1 CPU time in DB2ACCT (DB2CPUTM) is no longer
     just due to DB2; a significant amount of CICS application code is
     now included in that CPU time in the SMF 101 record, and there is
     no way to measure how much Class 1 was DB2 and how much was CICS.

     My thanks to Tony Steward and Nick Jealous who alerted me to the
     change, and to IBM CICS gurus Chris Baker and John Tilling from
     Hursley, whose very timely SHARE 99 papers and answers were used to
     write this note.  20AUG02, revised and reordered 27AUG02.

    Added 01Sep02:
    -An excellent IBM publication, Redpaper REDP0162, "DB2 for z/OS and
     OS/390 Version 7 Selected Performance Topics", February 19, 2002,
     easily found at www.ibm.com/redpaper, provides additional useful
     information on CICS and DB2 Accounting changes:

       -The H8, J8, and L8 Open TCBs are documented:
        H8 - TCBs allocated by hot-pool HPJ-compiled Java Programs
        J8 - TCBs allocated for the execution of a JVM Program (Java
                  programs that requires a JVM)
        L8 - TCBs allocated by non-Java program accessing a resource
                  manager through a task-related user exit enabled with
                  OPENAPI option.  Used by the CICS/DB2 attachment.

       -Figure 5-13 in the Redpaper is an excellent schematic of where
        CICS and DB2 CPU times are currently captured, and a revised
        Figure 5-13 for the OTE environment was presented by IBM at the
        SHARE 99 meeting:

                        Figure 5-13  CPU Accounting Before OTE

               ----CICS ADDRESS SPACE-----  --DB2 ADDRESS SPACE--

              . CICS QR     .  CICS       ..          DB2        .
              . MAIN TCB    .  ATTACH TCB ..          TCB        .
              .             .             ..                     .
              .             .             ..                     .
              . 1 __________________      ..                     .
              .             .      2 ___________________         .
              .             .       ____________________ 3       .
              .   __________________ 4    ..                     .
              . 5 __________________      ..                     .
              .             .      6 ___________________         .
              .             .       ____________________ 7       .
              .   __________________ 8    ..                     .
              . 9           .             ..                     .
               ---------------------------  ---------------------

                CICS CMF CPU = 1+5+9                ==> TASCPUTM
                DB2 Class-1 CPU = 2+3+4+6+7+8       ==> DB2TCBTM
                DB2 Class-2 CPU = 3+7



                  Revised Figure 5-13  CPU Accounting with OTE

               ----CICS ADDRESS SPACE-----  --DB2 ADDRESS SPACE--

              . CICS QR     .  CICS (L8)  ..          DB2        .
              . MAIN TCB    .  OPEN TCB   ..          TCB        .
              .             .             ..                     .
              .             .             ..                     .
              . 1 __________________      ..                     .
              .             .      2 ___________________         .
              .             .       ____________________ 3       .
              .             .   ____ 4      ..                   .
              .             . 5 ____        ..                   .
              .             .      6 ___________________         .
              .             .       ____________________ 7       .
              .   __________________ 8      ..                   .
              . 9           .             ..                     .
              .             .             ..                     .
               ---------------------------  ---------------------

                CICS CMF CPU = 1+2+3+4+5+6+7+8+9   ==> TASCPUTM has more
                DB2 Class-1 CPU = 2+3+4+5+6+7+8    ==> DB2TCBTM has CIC
                DB2 Class-2 CPU = 3+7


        The CPU "5" moves from under the QR TCB to the L8 Attach TCB;
          i.e., QR TCB may be less, L8 TCB may be more.
        The DB2 Class-1 CPU changes to 2+3+4+5+6+7+8 (was 2+3+4+6+7+8);
          i.e., CPU time for CICS functions ("5") is now recorded in the
                DB2 SMF 101, in dataset DB2ACCT, in variable DB2TCBTM.
           ==>  DB2 101's didn't record CICS CPU time before OTE.
        The DB2 Class-2 CPU is unchanged, 3+7.
        The CICS TASCPUTM is now 1+2+3+4+5+6+7+8+9 (was 1+5+9);
          i.e., DB2 CPU time ("2","3","4","6","7","8") is now included
                in CICS SMF 110 CICSTRAN dataset, in variable TASCPUTM.
           ==>  CICS 110's didn't record DB2 CPU time in the transaction
                records before OTE.

        The SHARE paper is in the SHARE San Francisco Proceedings,
        Session 1042, Tuesday, August 20th, 2002.


 1.  APAR PQ63141/PQ63143 adds new statistics to type 110 data; IBM has
     finally made the documentation of those changes available in Oct,
     2002, and Change 20.225 added support and documents the Studs that
     were changed.


VIII. Windows NT Technical Notes.

IX.   Incompatibilities and Installation of MXG 20.05.

 1. Incompatibilities introduced in MXG 20.05 (since MXG 19.19):
    See CHANGES.

 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.


X.    Online Documentation of MXG Software.

    MXG Documentation is now described in member DOCUMENT.


XI.   Changes Log

--------------------------Changes Log---------------------------------

 You MUST read each Change description to determine if a Change will
 impact your site. All changes have been made in this MXG Library.

 Member CHANGES always identifies the actual version and release of
 MXG Software that is contained in that library.

 The CHANGES selection on our homepage at http://www.MXG.com
 is always the most current information on MXG Software status,
 and is frequently updated.

 Important changes are also posted to the MXG-L ListServer, which is
 also described by a selection on the homepage.  Please subscribe.

 The actual code implementation of some changes in MXG SOURCLIB may be
 different than described in the change text (which might have printed
 only the critical part of the correction that need be made by users).

 Scan each source member named in any impacting change for any comments
 at the beginning of the member for additional documentation, since the
 documentation of new datasets, variables, validation status, and notes,
 are often found in comments in the source members.

Alphabetical list of important changes after MXG 19.19 now in MXG 20.xx:

  Dataset/
  Member   Change    Description

  See Member CHANGES or CHANGESS in your MXG Source Library, or
  on the homepage www.mxg.com.

Inverse chronological list of all Changes:

Changes 20.xxx thru 20.001 are contained in member CHANGES.

****************NEWSLETTER FORTY****************************************









    MXG NEWSLETTER NUMBER FORTY dated Feb 14, 2002.

Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE

                         TABLE OF CONTENTS                          Page

I.   MXG Software Version 19.19.
II.   MXG Technical Notes
III.  MVS Technical Notes
IV.   DB2 Technical Notes.
V.    IMS Technical Notes.
VI.   SAS Technical Notes.
VII.  CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX.   Incompatibilities and Installation of MXG 19.19.
         See member CHANGES and member INSTALL.
X.    Online Documentation of MXG Software.
         See member DOCUMENT.
XI. Changes Log
     Alphabetical list of important changes
     Highlights of Changes  - See Member CHANGES.

      COPYRIGHT (C) 2002 MERRILL CONSULTANTS DALLAS TEXAS USA

I.   MXG Software Version 19.19 is now available.

 1. Major enhancements added in MXG 19.19:

    See CHANGES.

II.  MXG Technical Notes

 1. Benchmarks of Data Transfer and MXG Processing on PCs.

    Early results were presented to the MXG User Group Meeting at CMG
    2001 in Anaheim, December 5, 2002.

 a. Measurement of sustainable data transfer rates between platforms
    and between disk drives, with the theoretical capacity of two LANS
    is given in this table:

               Table of Sustainable Data Transfer Rates

         KB=KiloBytes  MB=MegaBytes  GB=GigaBytes=1,073,741,824 bytes

       Connection/path      KB/sec   MB/sec   MB/min   MB/hr   GB/day

      Dial In 56kbit            6     .006      .4        20*      1
      T1 1.44mbit             144     .144       8       500*     12
      MVS to 10 mbit LAN      470*    .50       30      1800      42
      10 mbit LAN @100%      1024     1.0       60      3600      85
      750MHz 100mbit LAN              2.4*     144      8640     202
      500MHz C: to D: IDE             6.5*     390     23400     550
      100 mbit LAN @100%    10240    10.0      600     36000     850
      750MHz C: to D: IDE            12.0*     720     43200    1000
      850MHz C: to D: SCSI           24.0*    1440     86400    2000

      Those measures are for raw data transfer bytes.

      Note that a T1 connection transfers 500 MegaBytes per hour, while
      a 100 mbit LAN transfers over 8500 MegaBytes per hour (using about
      25% of the theoretical capacity).  The much higher disk-to-disk
      transfer rates on the PCs show that data transfer time, and not
      the MXG run time, will be the constraint on daily processing time.

 b. Download SMF data, Execute BUILDPDB on three different PCs:

    The SMF file contained only SMF 6, 26, and 30 records:
      842 MegaBytes, Compressed to 72 MegaBytes,  11 to 1.

    On a 2064/1C5 CPU (SU_SEC=10540) BUILDPDB took 18.5 minutes
    elapsed (and 6 minutes CPU).

    To download SMF data, you must first convert it from RECFM=VBS to
    RECFM=U (copy with IEBGENER), and then (optionally) zip (compress)
    the file on MVS (to reduce the download time), and then unzip on the
    PC and process the uncompressed SMF file.  The transfer was over a
    T1 line and the timings in minutes for the processing are these:

    Phase          500 MHz 2 SCSI     850 MHz 2 SCSI     1.3MHz 1 IDE
                   No-ZIP  Zipped     No-Zip  Zipped     No-Zip Zipped

    RECFM=U           1       1          1       1          1      1
    ZIP on MVS                9                  9                 9
    ftp download     89       7         89       7         89      7
    unzip on PC               1                  1                 2
    BUILDPDB         19      19         10      10         38     38

    total minutes:  109      37        100      28        128     57

    With 11:1 compression to reduce the transfer time, the 850 MHz box
    with two fast SCSIs would take 28 minutes to process (including the
    download), as compared with 18.5 minutes for BUILDPDB on MVS.
    Note that the speed of the PC and its disk drives has significant
    impact on the total run time.

    Zipping on MVS:  "Info Zip MVS", SHAREWARE:
    Get program/documentation at ftp://ftp.info-zip.org/pub/infozip/mvs
      Input limit: One full Volume uncompressed; input must be a member
                   of a PDS (RECFM=U conversion outputs to PDS member).

    Unzipping on PC: "Zip Magic for Windows", $40 USD purchase:
    Get program/documentation at (the address has changed several
    times, as the product has changed hands) as of Feb, 2003:
      http://www.aladdinsys.com/win/zipmagic, $39.99, downloadable.
    When installed on PC, can read the zip file directly with MXG, so
      there is no need to unzip (and hence you only need 72MB of disk
      space for the downloaded zipped SMF file, instead of an additional
      842 MB for the expanded SMF file!).  This is really slick!

      Mar 30, 2004 Note:  ZipMagic is NOT supported for Windows/XP,
        although it has worked without error on many files.  If it does
        fail with XP, you have no recourse with the vendor, who has not
        responded as to their plans (if any?) for XP support.  Their
        alternative Stufit product doesn't support direct read of zips.

    MXG Member DOCZIP (in MXG 19.08+) contains the JCL and specifics for
    the installation of both "InfoZip MVS" and "Zip Magic for Windows".

 c. Detail examination of impact of Compression options with PC SAS.

    The TYPE30 program was used to compare compression costs, since it
    reads the SMF file and writes out the SAS datasets in a single SAS
    data step.  The input dataset could be zipped or unzipped, and the
    output SAS datasets could be written compressed or uncompressed.

    MACHINE: 1.3 GHZ ONE IDE DISK:

    Input  Output   Elapsed mm:ss  User CPU  System CPU  Total CPU
     RAW    NO        13:22          2:22       :33        2:55
     RAW    YES       11:27          4:30      1:45        6:15
     ZIP    NO        11:00          2:19       :54        3:13
     ZIP    YES       10:23          4:30      2:04        6:34

     Comment:  Fastest ET was with both zipped input and compressed out.
               Compressing Output saved 2 minutes.
               Compressing Input saved 2.5 minutes.
               Compressing both saved 3.0 minutes, or 22% savings.
               Here, the elapsed cost to do I/O is greater than the
               elapsed cost of compression, and CPU was available.
               Best Time:  10:23.

   MACHINE: 500 MHZ TWO SCSI DISKS:

    Input  Output   Elapsed mm:ss  User CPU  System CPU  Total CPU
     RAW    NO         5:12          4:57       :11        5:08
     RAW    YES        5:35          5:15       :13        5:28
     ZIP    NO         5:52          4:49       :55        5:44
     ZIP    YES        6:09          5:12       :52        6:04

     Comment:  Fastest ET was with unzipped input and uncompressed out!
               Run time is more than halved due to faster I/O.
               Here, the processor is CPU bound, and adding compression
               to a CPU-bound process increases the run time.
               Savings from slowest to fastest was 57 seconds, 30%.
               Best Time:   5:12.

   MACHINE: 850 MHZ SAME TWO SCSI DISKS:

    Input  Output   Elapsed mm:ss  User CPU  System CPU  Total CPU
     RAW    NO         3:00          2:47       :08        2:55
     RAW    YES        3:12          3:00       :09        3:09
     ZIP    NO         3:27          2:48       :34        3:22
     ZIP    YES        3:36          2:59       :34        3:33

     Comment: Faster CPU with same disks; run time dropped from 5 min
              to 3 minutes, but processor is still CPU bound, so fastest
              run time is still unzipped and uncompressed.
              Savings from slowest to fastest was 36 seconds, 16%.
              Best Time:   3:00.

   MACHINE: 850 MHZ ONLY ONE SCSI DISKS USED FOR INPUT AND OUTPUT:

    Input  Output   Elapsed mm:ss  User CPU  System CPU  Total CPU
     RAW    NO         3:48          2:49       :09        2:58
     RAW    YES        3:38          3:00       :09        3:09
     ZIP    NO         3:59          2:49       :34        3:23
     ZIP    YES        3:45          3:00       :34        3:34

     Comment: One disk is slower than two disks; contention increased
              run time from 3 minutes to 3:38, but CPU was the same
              (and these numbers show the consistency of CPU measures).
              Savings from slowest to fastest was 36 seconds, 16%.
              Best Time:   3:38, with output compressed (probably due
              to Write cost being much higher than read cost).

   The overall conclusion is that zipping and compression is always good
   when you have CPU available; even when compression does increase the
   run time, the increase is small, and more than justified by the large
   saving in disk space and transfer time.
   But faster CPUs and faster Disk drives have a bigger impact on run
   time than does compression!

 2. Benchmarks comparing SMF and Web Log processing on Linux & Windows:

    ==========================================
    SMF  (842MB unzipped type 6, 26, and 30s.
          119MB compressed output, 54MB Sorted)

                              Elapsed   Elapsed  Data  Copy  Sort
                              mm:ss       sec    sec   sec   sec

  Dell Inspiron 1.3GHz Win2K  12:44       764    738    18    08
  IBM ThinkPad  1.3GHz Linux   6:26       386    347    15    24
  IBM ThinkPad  1.3GHz Win2K   3:06       186    152    18    16
  Desktop Clone 866MHz WinXP   3:28       208    183     7    16

     Comments:

     Both IBM and Dell are 1.3 MHz CPUs; 2:1 difference might be due to
       disk drives, but I think is actually due to better floating point
       execution on IBM; see below.
     Linux to Win2K, 2:1 difference shows Win2K NTFS outperforms the
       nfs that comes with Red Hat Linux 7.2.

     In all cases, the data step is much longer than the sort time; this
     has always been the case with MXG processing.


    ==========================================
    WebLog (93MB unzipped input, 672MB uncompressed output dataset,
            95MB compressed, 484343 observations 1456 obs length,
            SORTSIZE=256M, only one variable in BY List runs:)

                              Elapsed   Elapsed  Data  Copy  Sort
                              mm:ss       sec    sec   sec   sec

  Dell Inspiron 1.3GHz Win2K   4:08       244     55    13   180
  IBM ThinkPad  1.3GHz Linux   8:25       505     93    28   384
  IBM ThinkPad  1.3GHz Win2K   3:43       223     55    15   163
  Desktop Clone 866MHz WinXP   4:07       247     73    12   162

     In all cases with this character data, sort times are much longer
     than the data step time to read the input and create the dataset!
     I had never seen this behavior, because SMF data is highly numeric.

     This caused me to examine what caused the longer sort times, and it
     was the length of the BY list that was first discovered to have a
     major impact on the sort times.

                                   850   866       850   866
                                   MHz   MHz       MHz   MHz
                                   DATA  STEP      SORT  STEP
                                   secs  secs      secs  secs

       All Variables in BY list:    75    73        612   914
       Only one var in By List:     75    73        176   162

     And those were for the best runtimes with compression enabled; the
     uncompressed 850MHz sort time with all variables was 831 seconds,
     (and copying compressed took 11 seconds, copying uncompressed 204).

     But fortunately, since we really need to be able to sort on more
     than one variable, my webmaster found that SYNCSORT for WINDOWS had
     been released, and it appears to be a solution if you are going to
     sort large character datasets under SAS on Windows:

       All Variables, SYNCSORT:     75    73         90    --

     and clearly, SYNCSORT under Windows outperforms the internal SAS
     sort provided in SAS Version 8 under ASCII, with this kind of
     highly compressible character data.

     On unix, SYNCSORT is available, and SAS does interface with some
     unix systems, but Linux is not yet one of them; SAS Technical Note
     TS-6830 documents the systems that support SYNCSORT as host sort.
     For SAS Version 9, SAS expects to support SYNCSORT under Linux,
     HP/UX, Solaris, and Tru64.  And when SYNCSORT supports the 64 bits
     with AIX 5.1,  SAS intends to support that as well in Version 9.

     SAS Version 9's internal sort will be a portable multi-threaded
     parallel sort that is much faster on SMP hardware than the current
     internal SAS sort, so improvement is planned there.

     On MVS, SAS sites have either SYNCSORT or DFSORT installed, so I've
     never had reason to measure its internal SAS SORT performance.

    Comments:
     1. Note that Dell and IBM are much closer with all character data
        whereas IBM was much faster with SMF numeric data.

III. MVS Technical Notes.

20.   Al Sherkow's posting to MXG-L answers many questions about how to
      and how not to set up WLM policy:

     On Friday, January 11 Joan Kontra asked about manipulating CPU
     resource among LPARs. One option Joan was considering was to
     manage their workload by via changes in WLM. Part of my response
     included:

     "I do not recommend changing WLM policy. Develop a policy and
     stick with it. It may need to evolve as your workloads change over
     time, but switching policies is (in my opinion) not a strategic
     decision."

     Backchannel I received some questions about my email and setting
     up WLM policies:

     1.  How can you have different levels of service as a function of
          shift?

     2.  Can they use the WLM to change service between her daytime and
          nighttime LPARs?

     3.  What's wrong with having the operators change the policy at
          those times of day?  Isn't that also just a console command?

     While WLM was always supposed to manage your workload within your
     sysplex in my opinion WLM is only now, with z900 & zOS, beginning
     to do that. Most of WLM's control was within an image/LPAR. The
     exception being the transaction "spraying" capabilities that could
     choose which of a group of images to send a unit of work to.

     Part of the problem WLM faces is that once a transaction/batch
     job/query begins in an image it stays on that image until it is
     complete. It doesn't matter if higher priority work arrives, and
     it doesn't matter if high priority work is already running on the
     system. In general, work does not move. Now consider another LPAR
     in the sysplex that has available resources. It would be nice if
     work could move from busy LPARs to less busy LPARs.

     With z900 and IRD if the LPARs are on the same CEC then IRD will
     move the CPU resources and/or I/O resources from an LPAR not using
     them to an LPAR that can use them. Remember z900, z/OS and IRD
     introduced the new term "LPAR Cluster". All the LPARs on the same
     CEC in the same sysplex are an LPAR Cluster.

     Today's service policies take advantage of how WLM has been
     working.  Consider CICS and Batch. In many policies CICS has a
     higher importance than batch. Generally production is in one LPAR
     and development/test is in another. Still everything is fine,
     because CICS is higher than batch. Now z900, z/OS and IRD come
     along and these partitions run in a single CEC. The production
     CICS and production batch are running fine, meeting their
     objectives and goals. Development CICS starts missing its
     objectives. The WLM policy has always been operating at a sysplex
     level, but IRD provides new capabilities that truly extend the
     policy across the images within the LPAR Clusters. With IRD, the
     policy is now implemented at the Sysplex level .... so that
     development CICS has the same importance as Production CICS and is
     higher than all batch (including production). IRD takes resources
     away from the production LPAR to help the development LPAR's CICS.
     Viola! Finally WLM is working throughout the sysplex.

     I recommend that sites need to determine the requirements and
     service levels of all their workloads at all times. Also remember
     that service is service, regardless of timeframe. I think you need
     to perhaps consider your "timeframes" when defining the policy and
     use some other means to get work into the correct timeframe
     buckets. In this case "The workload on 'System A' consisting of
     one LPAR is always to be favored during the day". I wonder if she
     means the whole LPAR or something it is running? Their other
     requirement "The workload on 'System B' consisting of 2 LPARs is
     to be favored at night sometimes."

     Perhaps the 'System A' work during the day, and the 'System B'
     sometimes favored could be at the same importance. One critical
     question that has to be answered: "What would they do if these
     workloads were running at the same time?"

     On Changing Policies:
     Even before WLM I was generally opposed to changing IPS at
     different times of the day. In much of performance and managing a
     data center there are alternative techniques to solve a problem
     that will lead to the same conclusion. I think that analyzing data
     from a site that changes SRM parameters (IPS, ICS, OPT or WLM) is
     more difficult. There can be the added problem of an offshift IPS,
     and prime shift IPS and dealing with last night's outage. While
     catching up do you run in 'offshift' or the 'prime' configuration?
     For this reason I prefer a comprehensive 'all time frame' view of
     an installation's service.

     This is also greatly affected by the available capacity. Rarely is
     an upgrade in capacity the size that the site actually needs. The
     engines of today's machines are just too big. I'm not sure anyone
     runs out of MIPS in 250MIPS chunks. Today if I'm upgrading a z900
     the steps are about 250 MIPS each. What works well after an
     upgrade may not work well just before the next upgrade. This is
     the time that parameters are "tweaked" to solve specific problems,
     often without regard to overall service. In IPS terms this is when
     people tried to use time slicing or played with the time slicing
     pattern. (Should we favor a 40% or the pattern or 50% of the
     pattern?) After the upgrade few installations go back and
     "untweak". So over time the "tweaks" build up. I've often found
     this when called in to work on performance problems. Peter Enrico
     has done papers at Share, z/OS Expo and CMG about periodically
     reviewing your WLM Service Policy to see if it is still doing what
     you want. This addresses the same problem.


19.   IBM APAR PQ55355 for Websphere Application Server V4.0.1 for z/OS
      and OS/390 lists many problems in type 120 SMF records that are
      in error and corrected.   PQ55355 is associated with SERVICE LEVEL
      W401009 of WebSphere Application Server V4.0.1.

18.   BMC MAINVIEW CMF originally from Boole and Babbage type 73 values
      for PCHANBY and PNCHANBY are incorrect in their record and are now
      corrected by BMC PTF BPM7996 and discussed in their APAR BAM7806.

17.   APAR PO56039 for MQSeries V5.2 for OS/390 corrects values in many
      SMF 116 fields: WQMAXLAT, WAMINLAT, WQTOTLAT, WQGETMAX, WQGETMIN,
      WQPUTMAX, and WQPUTMIN are documented as incorrect.

16.   SMF Writer design cannot handle normal bursts of SMF data, for
      example when a step with many dynamic allocations ends.  These
      bursts overrun the SMF buffers, causing loss of SMF data.
      A specific, daily example:

      ENDEAVOR, an programming development system used by hundreds of
      programmers allocates many DDs dynamically for each use.  In one
      day, from 9am to 3pm, there were 2,548,964 DD segments that were
      written in 1,735 type 30 subtype 4 SMF records:

      15:06:48.78  First of 1735 Step Termination 30-4 Records
      15:06:50.54  Last of 1735 Step Termination 30-4 Records
                   54 MegaBytes in 1.76 Elapsed Seconds ==> 30 MB/sec

      Then 0.70 Elapsed Seconds from end of step SMF to start of job end

      15:06:51.24  First Job Record SMFTIME
      15:06:52.52  Last of 1735 Job Records SMFTIME
                   54 MegaBytes in 1.28 Elapsed Seconds ==> 42 MB/sec

         Total:  108 MegaBytes in 3.74 Elapsed Seconds ==> 30 MB/sec.

      This is far above the sustainable write-to-VSAM-file rate of the
      SMF writer with current DASD:
        One 3GB volume is filled every 20 minutes   ==> 2.5 MB/sec max

      And IEE986E messages shows five SMF buffer expansions in 15:06:52.

      The SMF Buffer is not designed to absorb 100 MB bursts of data;
      not only due to its small maximum size (which itself requires a
      PTF to allow the 128MB maximum), but the intrinsic serial design
      of the SMF writer causes potential data loss with every buffer
      expansion (eight 8MB expansions from 8MB to 128MB), because the
      writer cannot accept new records during buffer expansions.

      The case of the "multi-DD" step SMF burst occurs randomly, but
      more frequent (and often larger) SMF bursts occur at interval
      end when there are many CICS regions recording statistics data,
      and synchronized interval recording is critical for analysis
      across multiple address spaces, increasing the need for redesign.

      Loss of SMF data records is both an accounting exposure, and a
      security exposure, since any SMF records can be lost during the
      buffer expansions to handle these bursts.  I believe that the
      integrity of the SMF file is a prerequisite for OS/390 being
      designated as a B2/C2 DOD Secure operating system.

      The SMF Writer clearly must be redesigned to handle these bursts!

      Many of the companies in IBM's Gold Consultant program not only
      depend on SMF data being written, but recommend z/OS systems
      because of the SMF integrity in recording security accesses, and
      for performance and capacity measurement, all of which are
      threatened by SMF data loss.  I would like to propose a telephone
      conference call to discuss how members of that group can provide
      resources and assistance to IBM to redesign the SMF writer to
      handle the current and expected SMF data without data loss.

15.  CMF type 70 does not contain the ICF flag, until one or more of
     BPM7293, BPM7307, BPM7308, and/or BPM7309 are installed.
     Dec 16, 2001.

15.  APAR OW52226 for JES3 Only, type 30 fields SMF30PTM and SMF30TPR
     (MXG variables TAPNMNTS and TAPSMNTS) do NOT count JES3 dynamically
     allocated tape mounts.  The APAR is "CLOSED FIN", Fixed-in-Next
     (i.e., the next time IBM has to update that code for some other
     reason).

14.  APAR OW51353 corrects defective VVDS after OW50528.  The impact was
     defective type 60 SMF records, and IBM still refuses to provide the
     VVDS DSECTS, claiming they are "object code only".

13.  APAR OW45447 corrects an IEC027I 737-24 ABEND on CONFIG-002 DD; the
     IBM error occurs when non-SMS and SMS managed datasets were in the
     //CONFIG DD concatenation.  Reversing the order so that the non-SMS
     data set was first avoided the ABEND, but MXG expects its CONFIGV8
     member to be last, because it is the last CONFIG option that is
     used by SAS.  Previously, CONFIGV6 for V6 had to be last so that it
     would override the SAS default for MEMSIZE, but since SAS V8 cannot
     have a MEMSIZE parameter in //CONFIG members, the need for MXG's
     CONFIGV8 member to be last may not be absolute.  I'm checking.

12.  APARs OW50579 and OW50837 are marked "VARIOUS RMF PROBLEMS" and
     both fix a number of problems with RMF I and RMF III reports and
     ABENDs in both RMF Monitor I and Monitor III sessions.

11.  SMF 30 records with ALOCTIME earlier than INITTIME (SMF30AST/30SIT)
     can occur even though it is physically impossible; APAR OW50134
     acknowledges the problem, but that apar is "FIN", Fixed in Next
     (i.e., next 18 months in a new release).

10.  SMF 42 subtypes 15 thru 19 were not written after APAR OW47863 was
     installed; new APAR OW51179 corrects the error.

 9.  SMF VBS records with LRECL greater than 32760 have been found
     beginning with OS/390 R2.7, and IBM has acknowledged their error;
     SMF records can have a maximum LRECL of 32760 (max data LENGTH of
     32756).  APAR OW51139 for SMF Type 8 records, OW51146 for SMF Type
     90 Subtype 32 records.  These records cannot be read with SAS
     V6-V8, so you must use IFASMFDP to copy/delete if they are found.

 8.  With OS/390 R2.10 and DFSMS/rmm, problems with SAS data sets on
     tape required IBM APAR OW49577 for RMM.

 7.  A user noted that IBM's IXGRPT1 utility report from TYPE88 had the
     incorrect values for SMF88ETT and SMF88EO, but MXG was correct.

 6.  APAR OW49920 reports overlays caused when program objects in PDSEs
     are LLA-managed and the object gets staged to VLF.

 5.  APAR O49773 reports missing RMF Cache data from Shark D/T 2105
     after PTF UW77972 is installed.

 4.  Information APAR II12079 discusses lots of FTP errors and issues,
     and reasons why SMF 118 TCP records might not be written for FTP
     Client and/or Server:  there are two parameters in PROFILE.TCPIP
     dataset, SMFCONFIG and SMFPARMS, documented in IP Configuration
     Guide, Chapter 3.  SMFCONFIG FTPCLIENT is shown as an example to
     create the client record.

 3.  APAR OW50084 corrects non-writing of SMF 79 subtype 1,2, or 5 under
     Goal Mode if DOMAIN parameter is specified for ASD/ARD/ASRM, errors
     if CPs are varied ON-line and was OFF-line at the end of interval,
     and many errors in RMF reports.

 2.  APAR OW41696 corrects blank SMF30EXN/OMVSEXNP program name field in
     USS/OMVS type 30 SMF records.

 1.  APAR OW38842 corrects Accounting Fields in SMF Type 30 from USS
     (unix system services, a/k/a OMVS) tasks.  accounting information
     was taken from the calling address space instead of the address
     space associated with the passed ASSB.


V.   IMS Technical Notes.


VI.  SAS Technical Notes.

11.  MOVE TO 41.  82BA62 Fixed Windows error:
     FATAL ERROR: WRCODE=80000805, MODULE='wtdelet': Unexpected return
     from vtswtch().

10. A note on case sensitivity of SAS under unix.
    Under unix operating systems, a file named x.y is different that a
    file named X.y, but when SAS executes under unix, its sensitivity
    to case depends on the syntax.  This note may not be perfect:
     - DDNAMEs and DATASET names are case insensitive in SAS statements
       but the created unix file names will be lower cased.  SAS will
       read x.sas7bdat with SET X; or with set x; in your unix program.
     - Stored variable names are in the case of their first instance in
       the source program, so if you type the variable name in lower
       case it will be stored as a lower case variable name.  Thereafter
       all references to that variable name are case insensitive
     - External files, like MXG Source Directory members, must be lower
       cased and end with .sas, so that the %INCLUDE SOURCLIB(MEMBER);
       syntax can be transparently used across all platforms.
     -  MXG intends to always create only upper case names, so as to
        avoid the mess created by those unix idiots that thought case
        sensitivity was a good idea.  Life is complicated enough just to
        spell things right; getting the right case is asking too much.





 9. An interesting, but probably not generally important note, mostly
    about square brackets.  The beautiful hex dump created by the LIST
    statement (or by input errors like invalid data), interprets some
    hex characters differently in the CHAR line of the dump than in the
    PUT= of the input of that hex character.  The LIST option checks
    each character with the C isprint function to test its printability,
    but isprint's definition of 'printable' is platform dependent; on
    MVS, isprint('[') or (']') is considered unprintable and returns a
    zero, so the CHAR line prints a dot when it sees 'AD'x/'BD'x hex.
    But when you PUT a character variable, there is no printability test
    and so it will be displayed in batch job's logs based on a table in
    ????????, while under TSO, the character you see in a PUT statement
    is controlled by the translate table in the emulator that owns your
    screen.

    If square brackets do not display on your ISPF terminal, you need to
    have your VTAM SysProg set PROGRAM SYMBOLS ON in the VTAM Terminal
    Definition for your terminal.

 8. MXG Software and SAS Versions that you can use.

  a. Independent of which MXG Version you are using:

    We STRONGLY RECOMMEND that you ONLY execute MXG Software under V8:

      SAS V8.2 TS2M0, plus, for MVS-OS/390-z/OS, with the 82BX03 HOTFIX
                            Bundle (that includes critical 82BA57 fix).
                            Original 82BX01, changed to 82BX03 Oct 2002.

    but, if you still must stay in the dark ages, there are no reported
    MXG errors using SAS V6.09e at TS-475 (with SHARK, check SAS notes).

    There were errors in releases of V8 prior to SAS V8.2 that have been
    fixed in the V8.2+82BX01 HOTFIX; you'll be wasting your time and my
    time trying to use any earlier releases of V8 SAS.

  b. MXG will exploit new V8 enhancements when MXG is executed under V8,
     but you do not need a new version of MXG when you install a new SAS
     release for your daily runs.  However, for some new data sources,
     execution under V8 is required: Websphere EE SMF type 120 records
     contain DBCS Unicode characters that were not supported until V8,
     and MXG TYPEWWW WebLog support needs 32000-byte-length-character
     variables (which it fills mostly with blanks, which disappear with
     compression!).

     Note it is only V8-greater-than-200-byte-character-variables that I
     use in MXG; there are no long-variable-names, and since I only see
     complication and confusion with long-variable-names, I do not now
     expect to have MXG variable names longer than eight characters.
        However, if alias names for variables ever exist in SAS, I might
        want to change my mind. I could use the variable's LABEL as an
        alias name, so you could access it either way, and I would have
        a third alias with the original IBM field name as variable name!

 7. An increase in CPU time between V6 and V8 in a unique MXG job was
    found by SAS to be in its keeping track of the count and location of
    missing value calculations, and in this special case, the NOSTMTID
    SAS option significantly reduced the CPU time.  The site had used
    IMACEXCL to keep only 7 variables in CICSTRAN, keeping no datetime
    variables, which caused latent Y2K protection code to be executed
    because those datetime variables were now missing!  The added CPU
    time was not due to the missing value calculations themselves, but
    rather the calls to keep count; with OPTIONS NOSTMTID that counting
    is bypassed, no counts are kept, and significant CPU reduction in
    this unique case.  However, tests with NOSTMTID enabled showed a
    small 0.1%-0.5% increase in CPU time, so it does not seem worth
    enabling by default.   And SAS will revise the count-calls in SAS
    Version 9, now that they have diagnosed the problem.  SN-004513.
    10Apr02 update:  New UTILEXCL logic to create IMACEXCL completely
    eliminate any need for NOSTMTID, as previously expected; but here
    are the CPU times of what happened:
        V18.18   98.77   Original V609 Run, before problem.
        V18.18  229.59   Run with V8.2 that uncovered the problem.
        V18.18  105.31   Run with V8.2 with DSOPTIONS=NOSTMTID
        V19.19   82.29   Now, using IMACEXCL built by UTILEXCL


 6. SAS usage note SN-004513 is an Outstanding Problem that discusses
    possible increased CPU time with Version 8 when missing values are
    passed to functions; the counting and keeping track of which line
    number had missing value calculations, and how many, is apparently
    expensive in V8; the note suggests  OPTIONS DSOPTIONS=NOSTMTID;
    which we are testing.  The specific problem was a heavily tailored
    CICSTRAN dataset in which IMACEXCL was used to only input 6 fields,
    so all of the other variables were missing, which is not normal.
    In this case, the option was very significant; the 217 CPU seconds
    with out the option dropped to 97 seconds when it was enabled to
    create 16 million observations in CICSTRAN.

 5. Should you use //SORTWKnn DDs or Dynamic Allocation for SAS Sorts?

    MXG has always defaulted to having actual //SORTWK01 -> //SORTWK03
    DD statements in its JCL examples.  Here's why:

    a. There is a limit of 6 Sort Work Areas when they are dynamically
       allocated, so if you need more than 6 work units, pre-allocating
       //SORTWKnn DDs is the only way to get more space and/or units.
       Chuck Hopf uses 64 sort work DDs in his monster ASUMUOW job.
    b. If a VIEW or a Sequential-format SAS dataset is involved in the
       SORT, SAS can't determine the size to pass to the sort, so use of
       pre-allocation can ensure enough work space is allocated.
    c. Never use RLSE on //SORTWKnn DD statements, unless only one SORT
       is to occur.  In BUILDPDB, there are multiple sorts, some large
       some small, and some large again, and with RLSE that third sort
       can fail with a B37 when you RLSEd the space that somebody else
       has got now!
    d. The Sort Work DDs must be named //SORTWK01 and be in order, i.e.
       SORTWK01, SORTWK02, ...  SORTWKnn.
    e. The CONTIG parameter is no longer required by sort packages, and
       it can delay or even prevent allocation if that large chunk of
       work space is not currently available on DASD.  Sort benchmarks
       have not shown a significant difference with/without CONTIG now.
    f. But if you want to know the actual allocation algorithm for SAS
       sort work space allocation:
      -Host Sort interface is chosen to be used (either by SORTPGM=HOST
       or the size of the file to be sorted is greater than the value of
       SORTCUTP when SORTPGM=BEST), then
      -SAS checks TIOT to see if SORTWK01 is allocated, uses if found.
      -Otherwise, check to see if SORTWKDD value (see below) has been
       previously allocated, and if the space is sufficient for the
       current sort to be to be performed.
      -If that space is not sufficient then DEALLOC if present.
      -Check if DYNALLOC option is set.  If it is, SAS will not do the
       allocate but instead lets the sort package dynamically allocate
       its sort work area.
      -If NODYNALOC is set, then SAS will now allocate the sort work
       space:
        -SAS DD names are based on the SORTWKDD= option's value, which
         defaults to SASS, so they are of the form SASSWK01 to SASSWKnn
         where nn is the value of the SORTWKNO= options (and it is hard
         limited to six).
        -The size of sort work space allocated is computed as (number
         of OBS)*(RECLEN)*(2).
        -If the size cannot be determined (VIEW or SEQ Format) then
         SORTSIZE= option is used to determine sort work space to
         allocate.
        -Allocation is based on SORTUNIT (TRKS/CYLS/BLKS), SORTDEV
         (3390/3380/SYSDA...).  SAS still adds the CONTIG parameter.
        -If there is a DAIRFAILure message it is written to the SASLOG
         indicating that a dynamic allocation failed allocating that
         specific DD, but SAS will continue to attempt the SORT.
      SAS Technical Support provided assistance in writing item f.
      Dec 12, 2001.

 4. Errors when reading a V6.09-built SAS dataset with SAS V8:
      LIBRARY SPIN IS NOT IN A VALID FORMAT FOR ACCESS METHOD SASE7.
    is probably fixed in Hot Fix 82BA57, below, but is circumvented with
       LIBNAME SPIN    V609;
    that tells SAS V8 to use the V609 engine to read that DDNAME.
    This error first occurred after maintenance for IBM SHARK DASD; one
    one reporting site was backlevel at SAS V8.0, and they also had an
       ERROR FORMAT $MGTRAN NOT FOUND
    when V8.0 tried to use a //LIBRARY format library that had been
    created by V6.09.  Creating a new format library with V8.0 was the
    best solution, but a LIBNAME LIBRARY V609; statement circumvented
    the error.  But, once again, you really need to be at SAS V8.2 with
    all Hot Fixes!  First: Nov 30, 2001.  Last: Jan 10, 2002.
    Update July 12, 2002:  Either of these error messages:
      LIBRARY SPIN IS NOT IN A VALID FORMAT FOR ACCESS METHOD SASE7.
      LIBRARY SPIN IS NOT IN A VALID FORMAT FOR ACCESS METHOD SASEB.
    are now documented in SAS NOTE SN6447; these messages can occur if
    DISP=MOD is coded for an existing SAS Data Library, if you have
    installed any of these hot fixes:   81BA50, 82BA57, 82BX01
    Their temporary circumvention is to use DISP=NEW, but I will update
    this note after I discuss further - SAS needs to support DISP=MOD.

 3. OS/390 Hot FIX 82BA57 for V8.2 fixes many I/O & multi-volume errors
    (and Hot FIX 81BA50 is for V8.1). SAS note SN-05642 discusses and it
    lists these SAS notes that are associated with this defect:
          895 2674 2881 4229 4916 5004.
    Problems included non-read VBS records after error, multiple mounts,
    BY variable position errors, S0C1 in SORT step, B37-04 on SYSOUT DD
    with a PROC PRINTTO, U315/U317/S0C4, etc.
    Nov 20, 2001.

 2. A minor difference in values between ASCII and EBCDIC SAS numeric
    variables that are stored in less than eight bytes is documented.
    There is no error, just differences in the way numeric values are
    stored on different hardware platforms and/or operating systems!

    MXG 19.11 now uses LENGTH DEFAULT=&MXGLEN and &MXGBYLN (See Change
    19.272) to set the stored length of most numeric variables, where
    MXGLEN is 5 on EBCDIC and 6 on ASCII, which both saves disk space,
    and keeps full resolution of fields input from 4 bytes.  Only if the
    exact value of a large-value variable is needed is LENGTH 8 used;
    datetimestamp and byte variables are length 8.

    Because SAS uses floating point internal storage, ASCII systems
    require a minimum of 3 bytes to store a one-byte numeric, while
    EBCDIC systems only require 2 bytes.

    Previous EBCDIC truncation measurements when 'FFFFFFFF'x was INPUT
    as PIB4 and stored in 4 bytes had shown a maximum loss of 255, but
    these new ASCII measurements under WINDOWS show a maximum loss due
    to truncation of 247.

      Hex Value   INPUT PIB4. ASCII     INPUT PIB4. EBCDIC    LENGTH
       FFFFFFFFx     4294967295            4294967295           8
       FFFFFFFFx     4294967295            4294967295           7
       FFFFFFFFx     4294967295            4294967295           6
       FFFFFFFFx     4294967288            4294967295           5
       Truncate loss:         7                     0           5
       FFFFFFFFx     4294965248            4294967040           4
       Truncate loss:      2047                   255           4

    This shows that LENGTH=5 for MVS and LENGTH=6 for ASCII platforms
    will store all fields input as PIB4 without any truncation.

    Originally, Nov 14, 2001, I wrote:
       There's really nothing to fix here, but if you ever need the
       change the length of an MXG numeric variable, you can override
       the MXG code by adding a statement:   LENGTH variable 8;  in your
       EXdddddd "exit member" in your tailoring library.  SAS uses the
       last instance of a LENGTH statement, and the Dataset Exit
       member's code is always seen after the MXG LENGTH statements!

    Nov 29, I realized I can easily externalize the MXG default value
    using DEFAULT=&MXGLEN in place of DEFAULT=&MXGLEN in all MXG source
    and preserve the existing value by using %LET MXGLEN=4; in the MXG
    initialization, and then, if you need full resolution, you can have
    it by using  %LET MXGLEN=n; as your first //SYSIN statement in the
    MXG jobs that create the datasets.  Implemented in Change 19.272.

    If you use a  PUT variable= ; statement in a SAS program that is
    creating and then storing that variable in 4-bytes, the output of
    the PUT will be the full 8-byte value, but a PROC PRINT of the
    dataset will have the (truncated) 4-byte value; SAS uses 8-byte
    virtual storage internally for all numerics; it is only when the
    variable's value is OUTPUT to a dataset that its stored length is
    set by the LENGTH= statement.


 1. SN-002861 is a SAS V8.0 and V8.1 only correction; the error is fixed
    in SAS V8.2.  Tape Format libraries on disk which encountered B37
    out of space conditions require zap z8002861 or Z8012861, and these
    zaps also correct errors in SN-004787 with S837-08 and multiple tape
    volume datasets.  0C4's may also occur, but again, only if you are
    still running 8.0 or 8.1.


VII. CICS Technical Notes.

 1.  APAR AQ61844, about two years old, for CICS 4.1, reduced CPU time
     in LE and COBOL environment's initialization and termination with
     modules ceevgtsi, igzeini, and igezetrm all active.

VIII. Windows NT Technical Notes.

IX.   Incompatibilities and Installation of MXG 19.19.

 1. Incompatibilities introduced in MXG 19.19 (since MXG 18.18):

  a- Landmark data for DB2, IMS, and MVS now have datetime variables
     converted to local time zone by MXG; previously the datetimes
     were incorrectly left in GMT.  This could affect reports if you
     use TYPETMDB, TYPETIMS, or TYPETMV2.  The Landmark CICS data was
     not corrected.  See documentation in Change 19.288.


 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.


X.    Online Documentation of MXG Software.

    MXG Documentation is now described in member DOCUMENT.


XI.   Changes Log

--------------------------Changes Log---------------------------------

 You MUST read each Change description to determine if a Change will
 impact your site. All changes have been made in this MXG Library.

 Member CHANGES always identifies the actual version and release of
 MXG Software that is contained in that library.

 The CHANGES selection on our homepage at http://www.MXG.com
 is always the most current information on MXG Software status,
 and is frequently updated.

 Important changes are also posted to the MXG-L ListServer, which is
 also described by a selection on the homepage.  Please subscribe.

 The actual code implementation of some changes in MXG SOURCLIB may be
 different than described in the change text (which might have printed
 only the critical part of the correction that need be made by users).

 Scan each source member named in any impacting change for any comments
 at the beginning of the member for additional documentation, since the
 documentation of new datasets, variables, validation status, and notes,
 are often found in comments in the source members.

Alphabetical list of important changes after MXG 18.18 now in MXG 19.07:

  Dataset/
  Member   Change    Description

  See Member CHANGES or CHANGESS in your MXG Source Library, or
  on the homepage www.mxg.com.

Inverse chronological list of all Changes:

Changes 19.288 thru 19.001 are contained in member CHANGES.

****************NEWSLETTER THIRTY-NINE**********************************










    MXG NEWSLETTER NUMBER THIRTY-NINE DATED JULY 26, 2001.

Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE

                         TABLE OF CONTENTS                          Page

I.   MXG Software Version 19.03.
II.   MXG Technical Notes
III.  MVS Technical Notes
IV.   DB2 Technical Notes.
V.    IMS Technical Notes.
VI.   SAS Technical Notes.
VII.  CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX.   Incompatibilities and Installation of MXG 19.03.
         See member CHANGES and member INSTALL.
X.    Online Documentation of MXG Software.
         See member DOCUMENT.
XI. Changes Log
     Alphabetical list of important changes
     Highlights of Changes 18.001 thru 18.356 - See Member CHANGES.

      COPYRIGHT (C) 2000 MERRILL CONSULTANTS DALLAS TEXAS USA

I.   MXG Software Version 18.18, the 2001 annual version, was sent to
     all MXG licensees in February, 2001.

 1. Major enhancements added in MXG 19.03:

    See CHANGES.

II.  MXG Technical Notes

 1.  Using a text file of the SAS log's printed hex dump of a VSAM SMF
     record as input to the UTILBHEX program will write a legitimate VBS
     record, but that will still be a VSAM-format record, and under the
     ASCII versions of SAS, there is no JFCB, so MXG can't automatically
     recognize the input is in VSAM-format like it does under z/OS-etc.
     You must set the OFFSMF=4 in member IMACZDAT to make it work.
     Few outside MXG Technical Support need to know this fact.

III. MVS Technical Notes.

22.  An interesting problem, since I remember when 51 hours of MVS 2.2
     up time was magic: APAR OW48782 discusses address spaces not
     swapping in after the system had been IPLed for 51 days, because
     the SRM timing algorithms can no longer run.   I also recall that
     MVS 2.2 had a hard limit of 168 hours in it's earliest incarnation
     and it took 2.5 years before someone hit that SEV 1, but by then
     MVS 3.0 had fixed the problem!

21.  If you use MULC (Measured Usage License Charges?) for DB2, after
     APAR OW30153, new APAR OW16176 corrects a CICS DB2 Performance
     degradation, but the zap with that APAR has a secondary effect of
     the TYPE30MU Usage data being recorded as lower than actual usage.
     IBM doesn't care, since actual MULC charges are in the type 89 SMF
     record, which still has totals correct, but if you use the TYPE30MU
     data to recover charges, you'll need to be aware of this APAR and
     watch for a permanent correction.

20.  APARs OW44428, OW44429, and OW47519 are required prerequisites to
     creating the new FICON directory RMF type 74 subtype 7 records, and
     new RMF option FCD/NOFCD in ERBRMFxx enables their creation.

19.  APARs OW48603 fixes Type 6 SMF records with corrupted data values.
     READTIME was corrupt and JOB contained hex zeroes.  18Jul2001.

18.  APARs PQ41205 and PQ44739 address performance issues with CISCO
     routers and high channel utilization.  These APARS are related
     to claw packing, even though the APAR text refers only to OSA
     devices that tend to be LCS.  Big improvements were reported on
     MXG-L with these APARs.

17.  APAR OW50187 for z/OS V1R2 reports incorrect values in RMF type 72
     records in fields SMF72CTS and SMF72STS.

16.  APAR OW50084 reports multiple RMF problems with both reports and
     records.  Processors never Online at interval end have no CPU Data
     section in type 70; DASD response times are now reported as integer
     but will now be in units of tenths of a millisecond.

16.  APAR OW49733 reports missing Cache RMF 74 subtype 5 (TYPE74CA)
     records after APAR OW46463 was applied; additional symptoms are
     poor performance for PAV devices, visible thru RMF measurements.

15.  APAR OW49744 corrects several values in variables in SMF type 85
     records in subtypes 32 thru 35.

14.  For the record: MXG Software does NOT issue a STIDP, Store CPU ID,
     nor a STSI, nor a STAP instruction, and MXG Software DOES handle
     hexadecimal characters in the CPC Serial Number fields.  Both
     changes were introduced in IBM z900 2064 processor family, but
     have no impact on MXG Software.

13.  EXCP counting for DSS was changed by IBM.  DSS used to use EXCP to
     read VSAM extended format datasets, so EXCP counts were recorded in
     SMF (type 30, type 64), but in DFSMS 1.5.0, DSS was changed to use
     the System Data Mover (ANTMAIN) component to do the reads, and it
     does not use EXCP as DSS did.

12.  From Pat Artis:  Why are Ficon channels busy when they are idle?
     Because that, even when there are no I/O's executing on the FICON
     channel, the channel is still polling for work to do.  This shows
     up as bus utilization on the RMF report and in TYPE73. 1Jun01.

11.  APAR PQ46754 reports FTP failures of all kinds due to TCP/IP acks
     and nacks getting out of sequence, causing TIMEOUTS, etc.

10.  APAR OW49094 reports large values in SMF30BLK (EXCP count in 30s)
     and SMF15NTR always zero with OS/390 R10 and DFSMS R10 HZD11F0 was
     triggered by Partial Release.

 9.  APAR OW48109 describes errors in Type 70 data on 2064s with ICFs,
     in RMF reports, and indicates that "RMF tolerates now a dispatch
     time, some milliseconds greater than the processor online time"!!

 8.  APAR PQ15462 for DB2 deals with very high I/O activity to the BSDS
     (Bootstrap) dataset of the second member of a 2-way datasharing
     group.  The first member is running Capture/MVS DPROPR
     Capture and is related to the way DPROPR calls DB2 and
     whether there are either cdc or ur related records to
     process.

 7.  APAR OW48402 corrects bad values in type 42 subtype 5 TYPE42DS
     dataset records when SMS reads device statistics, and the error
     also created a large number of LOGREC entries NEW HIT RATIO ERROR.

 6.  APAR OW48334 reports high disconnect times in RMF and SMF records
     for 2105 ESS SHARK with PPRC when running on a G5 machine or
     earlier.

 5.  APAR OW47895 confirms IBM's non-support for extended-format VSAM
     MANx files by the SMF writer, and makes no mention of any intention
     to do so.  We need extended-format supported so our VSAM SMF files
     can be striped and/or hardware compressed, but it's not there now.

 4.  APAR OW47863 corrects excessive virtual storage (SP229 Key 5) in
     address space SMSVSAM when using VSAM RLS and RMF Release 10 to
     display VSAMRLS statistics (RMF was not releasing storage).

 3.  APAR OW47827 reports and corrects problems found during internal
     testing of Dynamic CHPID Management under z/OS Release 1.

 2.  APAR OW48124 corrects offset for S42XRVSS and subsequent fields in
     the SMF 42 subtype 11 XRC Volume Data Section.

 1.  APAR PQ43767 corrects high CPU time, high EXCP count, and possibly
     large number of dynamic allocation TYPE30_D records with Imagecopy.


IV.  DB2 Technical Notes.

 1. DB2 APAR UQ41459 on DB2 5.1 caused the SRB Time recorded in SMF/RMF
    to drop substantially.

V.   IMS Technical Notes.

 1. Information APAR II12877 relating to IMS Fast Path reports that
    after migrating from SMS 1.3 to SMS 1.5, I/O counts in SMF type
    30 record (SMF30TEP=EXCPTOTL, the address space total EXCP count,
    and "SMFIOCNT, which I think they mean SMF30IO=IOUNITS) were much
    larger for a BMP job, because FastPath will use ASPACE operand on
    MMCALL for SMS 1.4 and above, which (correctly) will result in the
    Media Manager charging dependent region initiated I/O (i.e. reads)
    to the dependent region rather than to the control region.

VI.  SAS Technical Notes.

11. While OS/390 R2.10 and later now support large blocksize for tape
    files (256K for 3590 tape devices, 65535 for other devices, no
    change for DASD devices) SAS under OS/390 or z/OS will not be able
    to read those large blocksize files until SAS Version 9.  SAS now
    fails with ERROR: OPEN FAILED FOR FILE SMF: SYSTEM ERROR 013-0E1
    if you try to read a large blocksize file from tape.  19Jun01.
    And SAS will not allow LRECL>32760 for RECFM=VBS nor BLKSIZE>32760
    for RECFM=U until Version 9.

10. If creation of the MXG Format library with member FORMATS ends with
    "ERROR: Cannot update record in entry MGxxxxx.FORMATC. Record length
    mismatch.", the correction seems to be to erase the existing format
    dataset in the directory pointed to by the LIBRARY libref and then
    rerun the FORMATS step.  This error has only been observed under SAS
    Version 8 under Windows.  You can erase the format catalog, or you
    can use this step to delete it from within SAS:
      PROC DATASETS DDNAME=LIBRARY MT=CAT;
      DELETE FORMATS;


 9. SAS Hot Fix 81BA40 corrects a number of reported SAS problems, from
    FILENAME causing three mounts for one tape, 0C4 using QSAM or ISAM,
    BY variable position errors, 0C1 in PROC SORT, 0C4 using DFSORT
    Performance Booster, and several others.

 8. Critical fix for SAS Releases V7 thru V8.2 for SMF VBS broken data.
    SAS Releases V7 thru V8.2 do NOT read any subsequent SMF records
    after an invalid VBS segment is detected.  Messages on the log:
         ERROR: INVALID VBS SEGMENT DETECTED.
         FATAL: UNRECOVERABLE I/O ERROR MESSAGE
    after the segment error message.
    For SAS Release 8.1 TS 1M0 Hot Fix 81BA41 is available for download.
    For SAS Release 8.2 TS 1M0 Hot Fix 82BA31 was available but was then
    renumbered to    8.2 TS 1M0 Hot Fix 82BA39, available for download.
    See SAS Note SN-004555.
    Updated Dec 10, 2001:  Hot Fix 82BA57 replaced 82BA31; see above.

 7. Formatting a numeric variable that has stored LENGTH less than 8,
    if the format is a user-defined format created by PROC FORMAT that
    itself uses an existing format name as a label, OTHER=[DATE9.] in
    this specific case, causes 01JAN1960 to be printed for lengths of 4
    or 5, and '********' to be printed for lengths of 6 or 7.  Obscure,
    and unlikely to have an impact, but noted here for reference.
    7May2001.  SAS Usage Note SN-003430.

 6. ABEND 213-B8 on PDB ddname was corrected by specifying the SMS
    DATACLASS=NOCOMP on the PDB DD statement to suppress compression.

 5. ABEND 613-04 on a SAS Tape DDname with OS/390 R2.10 and DFSMS/rmm
    as your tape manager requires IBM APAR OW48403; RMM did not handle
    multiple tape opens properly.

 4. SAS V8.0 and V8.1 cause error messages if NOWORKINIT option is used
    with old-style macros.  The error is fixed in V8.2, and SAS Usage
    Note SN-003514 lists Z8003514 and Z8013514 as available zaps to fix
    the error under V8.0 and V8.1.  (I strongly suggest 8.1 vice 8.0).
    The error text is UNABLE TO OPEN MACRO LIBRARY and THE VALUE SASO
    IS NOT A VALID SAS NAME.

 3. SAS V8.0 and V8.1 Usage Note SN-003821 reports S0C4 ABEND using
    DFSORT Performance Booster interface.  The error will be fixed in
    SAS V8.2 TSLEVEL 2M0, but the error can be circumvented by setting
    the SAS system option NOSORTBLKMODE.  The problem was caused by SAS
    interpreting the "preferred size" passed by DFSORT as a signed
    integer when it is actually an unsigned integer.

 2. SAS fixes are available for SAS 8.0 and 8.1 that correct increases
    in SAS CPU usage on both the new z900, which precipitated this ZAP
    as the increase was very noticeable in the 20-25% range, and for the
    G5/G6-based processors, where only a 5-10% reduction was observed.
    See SAS Note SN-004291 for SAS 8.0 and 8.1.  The problem is fixed in
    SAS Version 8.2 TS2M0 of the SAS System.  Note that SAS 6.09 has an
    associated fix in SAS Note V6-SYS.SYS-G952.

 1. SAS ARRAY names cannot be the same as a SAS variable name.


1. Summary of ALL important SAS V8.1 Issues. Last updated: 17Dec2000.
   This list was shown at the MXG User Group Session at CMG 2000:
   See the prior newsletters' text for more details.

   a. Remove MEMSIZE=64M from CONFIG member (use MXG CONFIGV8 member),
      and let your REGION= parameter control virtual storage.  Must do!

   b. USE SEQENGINE=V6SEQ instead of V8SEQ or install Z8002651.
      The error is fixed in SAS 8.2.

   c. Use SAS member (BATCH) instead of (BATCHXA) in the //CONFIG
      concatenation in your JCL, (or use MXGSASV8 JCL procedure
      example).

   d. Do not use Secondary Allocation and Guaranteed Space for SAS Data
      Library on DASD.  G.S. is no longer required to get multi-volume
      DASD SAS data libraries, but can be used; the existence of G.S.
      AND a secondary allocation causes the error (which will eventually
      be fixed by SAS).

   e. Error with PROC COPY IN=WORK OUT=PDB; if the PDB is a V6 SAS data
      library on disk, while copying the WORK.REGSTRY(MEMTYPE=ITEMSTOR),
      with this SAS Error message:
        ERROR: REQUESTED FUNCTION IS NOT SUPPORTED.
      or if the PDB is a V6 Sequential data library, with this message:
        ERROR: UNABLE TO OPEN CATALOG PDBTAPE.SASMACR(MEMTYPE=CATALOG)
               FOR WRITE ACCESS. ENGINE V6SEQ DOES NOT SUPPORT WRITE
               ACCESS.
      You must add MEMTYPE=DATA to your PROC COPY statement:
          PROC COPY IN=WORK OUT=PDB MEMTYPE=DATA;
      because SAS V8 uses MEMTYPE=ALL as the default, which attempts to
      copy all data structures, which you do not want.  MEMTYPE=DATA is
      required to ensure that only Data Sets are copied.
      Revised 23Jan2001. Revised 25Apr2002.

   f. SAS V8 ABEND S01D when HSWORK is used.  SAS zap Z8001639 fixes.

   g. SAS V8 does not support V5 data libraries:
      -  Use V6 to PROC COPY from V5 to V6 lib (DISP=NEW)
      -  Then use V8 to PROC COPY from the V6 library.

   h. What level of MXG is needed for SAS V8.1?

      MXG 16.16 ran with SAS V8, with a warning note that the SAS
                options CODEPCT and BLKSIZE(TAPE) don't exist.
      MXG 17.01 provided new CONFIGV8 without those two options to
                remove the warning note on MVS.
      MXG 17.07 exploits 32000 byte length of character variables, but
                only if COMPRESS=YES was specified, and only for SQL
                text variable in TYPE102.
      MXG 17.08 exploits the new INHERIT option of PROC MEANS in
                VMXGSUM, to skip a data step that is now unneeded.
      MXG 18.04 changed V8 default to SEQENGINE=V6SEQ.
      MXG 18.05 removed MEMSIZE from CONFIG, (and reinstated options
                S=72,S2=72 that had been removed in 17.17).


VII. CICS Technical Notes.

 1. With CICS and RACF, every time there is a successful or unsuccessful
    signon, a RACF record is always created, because CICS issues RACINIT
    with LOG=ALL, to log all attempts, intentionally.  (LOG=ASIS logs
    only invalid or unsuccessful sign-ons).  ITEM RTA000007479 discusses
    why CICS does not give an option, but that item also reminds you
    that even if CICS itself does not provide a user signon record, the
    RACF records can identify signons to CICS.


VIII. Windows NT Technical Notes.

IX.   Incompatibilities and Installation of MXG 19.01.

 1. Incompatibilities introduced in MXG 19.01 (since MXG 17.17):

  a- No changes in MXG architecture were made between 18.18 and 19.01
     that introduced incompatibilities.

 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.


X.    Online Documentation of MXG Software.

    MXG Documentation is now described in member DOCUMENT.


XI.   Changes Log

--------------------------Changes Log---------------------------------

 You MUST read each Change description to determine if a Change will
 impact your site. All changes have been made in this MXG Library.

 Member CHANGES always identifies the actual version and release of
 MXG Software that is contained in that library.

 The CHANGES selection on our homepage at http://www.MXG.com
 is always the most current information on MXG Software status,
 and is frequently updated.

 Important changes are also posted to the MXG-L ListServer, which is
 also described by a selection on the homepage.  Please subscribe.

 The actual code implementation of some changes in MXG SOURCLIB may be
 different than described in the change text (which might have printed
 only the critical part of the correction that need be made by users).

 Scan each source member named in any impacting change for any comments
 at the beginning of the member for additional documentation, since the
 documentation of new datasets, variables, validation status, and notes,
 are often found in comments in the source members.

Alphabetical list of important changes after MXG 18.18 now in MXG 19.01:

  Dataset/
  Member   Change    Description

  See Member CHANGES or CHANGESS in your MXG Source Library, or
  on the homepage www.mxg.com.

Inverse chronological list of all Changes:

Changes 19.xxx thru 19.001 are contained in member CHANGES.

****************NEWSLETTER THIRTY-EIGHT*********************************










    MXG NEWSLETTER NUMBER THIRTY-EIGHT DATED FEBRUARY 12, 2001

Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE

                         TABLE OF CONTENTS                          Page

I.   MXG Software Version 18.18.
II.   MXG Technical Notes
III.  MVS Technical Notes
IV.   DB2 Technical Notes.
V.    IMS Technical Notes.
VI.   SAS Technical Notes.
VII.  CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX.   Incompatibilities and Installation of MXG 18.18.
         See member CHANGES and member INSTALL.
X.    Online Documentation of MXG Software.
         See member DOCUMENT.
XI. Changes Log
     Alphabetical list of important changes
     Highlights of Changes 18.001 thru 18.356 - See Member CHANGES.

      COPYRIGHT (C) 2000 MERRILL CONSULTANTS DALLAS TEXAS USA

I.   MXG Software Version 18.18, the 2001 annual version, was sent to
     all MXG licensees in February, 2001.

 1. Major enhancements added in MXG 18.18:

II.  MXG Technical Notes

 1. See Change 18.338 for discussion of the new _Vdddddd macro that lets
    you specify  KEEP= A B C ...  if you want to use KEEP= logic instead
    of the old _Kdddddd DROP= syntax.

III. MVS Technical Notes.

14.  DFHSM R140 APAR OW46309 has PTF UW76741 to correct invalid negative
     values for FSR CPU time in HSM records.  Bad fields were added by
     APAR OW05988 and corrected by this APAR.

13.  NPM NRT segment is documented as 204 bytes, but actual segment size
     is 208 bytes; the document was correct and APAR OW47872 will fix
     the code so the record is written correctly.

12.  Syncsort's product PROC SYNCSORT corrupts output datasets because
     they assumed that all numeric floating point fields (i.e., all SAS
     numeric variables!) were 8 bytes long, whereas MXG stores many
     variables in 4 bytes.  This error is not in their Syncsort's SORT
     product, so you can circumvent the PROC SYNCSORT error by instead
     using just the SORT product, or you can use SAS's internal SORT.
     PROC SYNCSORT now has a correction, their PTF EW5422-0.  BUILDPDB
     errored with: DATASET SPJB30TD DATASET IS NOT SORTED right after it
     was sorted; PROC PRINTs showed the variable JOB was good before but
     corrupted after the sort, allowing Syncsort technicians to iterate
     to their final solution.

     I had this same error with Syncsort's Sort product in 1972, when I
     first used SAS with Syncsort; SAS stores all numerics as floating
     point numbers, but permitted any length from 2-8 bytes, but that
     version of Syncsort only supported lengths of 4 and 8 (because the
     FORTRAN programs only had REAL*4 and REAL*8 lengths available!).
     That old error is one of the reasons I generally keep fields as
     either 4 or 8 bytes and don't use those unexpected values, but it
     didn't help their current oversight!

11.  APAR OW42945 also has lots of RMF problems fixed, 5.1 to 2.9.
     ABENDS in both data collectors and report writer, high CPU time
     in RMFGAT, invalid system name in Monitor III Coupling Facility,
     CF reports effective CPUs is one-tenth correct value, etc. Lots!
     High RMFGAT CPU also recommends DFSMS APARS OW43249 and OW43250,
     and references Information APAR II12313.

10.  APAR OW46825 also corrects many RMF ABEND problems, including ABEND
     when the RMF post processor attempts to read Type 103 or Type 108
     records with SPE OW44845 for OS/390 2.7.  The PTF for this APAR
     only fixes the report ABEND if there are NO 103/108 SMF records,
     (and suggests you use IFASMFDP to exclude dumping those records
     until a later APAR, OW47050 exists).  MXG has no problem with those
     changed 103/108 records.  Dec 5: PE OW47050 hold on this fix!

 9.  APAR OW45418 corrects many problems in RMF reports, and some data
     errors (although it's hard to tell whether some corrected errors
     were only in the reports, or in the data records!).
     - IBM field SMF70VPA, MXG's variable LCPUADDR in TYPE70PR can have
       invalid values of '1n'x or '2n'x when the number of processors in
       an LPAR is changed.

     - Type 72 Subtype 4 (Monitor II) records can have DB Delay wrong.

     - Channel Path Partition and Total Utilization (I presume PCHANBY
       PNCHANBY in TYPE73, but might include PCTPTHBY in TYPE78CF?)
       sporadically invalid.

     - Wrong values in TYPE71 when SMF71ISC is not zero.

     - Type 74 data for PAV devices is wrong when RMF retries
       initialization of its internal device tables.  A retry takes
       place when during initialization, listen events arrive for device
       state changes, DDR activity, storage group configuration changes,
       CMB data state changes, VARY device commands, or when channel
       paths become available or unavailable.

       This APAR is pervasive: PTFs for MVS/ESA 5.1 thru OS/390 R2.10!!
       Dec 1, 2000.


 8.  RMF Monitor III can consume large amounts of CPU time capturing
     DASD CACHE control unit data for its delay reporting.  On a CPU
     with SU_SEC=2700, the RMFGAT CPU time dropped from 5 to 1 minute in
     a 15 minute interval (from 33% to 6 % of a engine) when RMF III
     NOCACHE was specified.  Even on a SU_SEC=8000 machine, RMFGAT used
     2 minutes (13% of one CPU) with RMF III CACHE.
       This complex has 129 Logical Control Units, 8,092 DASD Volumes,
       on 4 IBM SHARKs, 17 HDS 7770Es and 4 Amdahl PLATINUMs!  BIG!
     Since all Cache DASD can be measured from a single system, it makes
     sense to run RMF III Cache measurement on only one system (easily
     implemented by using an automated operations tool to disable it on
     all but a single system).

     Running RMF Monitor I Cache measurement, which creates SMF type 74
     subtype 5 records for TYPE74CA dataset, on only one system also
     saves CPU time, but the CPU cost, and hence savings, are much less.
     But by running Monitor I Cache on only one system, you will reduce
     the SMF data volume (as well as reducing TYPE74CA size and the MXG
     CPU and run times!).  With 8,092 volumes that's a savings of 2.6MB
     of SMF data per RMF interval per system, or 250 MB per day with 15
     minute intervals, and TYPE74CA would be 500 MB smaller per day.

     This CPU increase has been observed in both OS/390 2.7 and 2.8, but
     is likely to apply to all releases.  Dec 1, 2000.

     To disable CACHE the following commands can be used to modify RMF:

        Monitor I   - F RMF,MODIFY ZZ,NOCACHE
        Monitor III - F RMF,MODIFY III,NOCACHE

 7.  APAR OW46585 for OS/390 2.6 and above, Goal Mode.  Comments that
     cap delays for service classes with long response time goals,
     even when the service class is missing its goals, and suggests
     that a velocity goal may be better than a long response time goal.

 6.  APAR OW44517 for OS/390 is involved with an increase in CPU wit
     Release 2.8.  The CPU increase can be as much as 10% and shows
     up as uncaptured CPU time. High LPAR overhead, increased CPU by
     system address spaces such as CATALOG, GRS, etc., SRM problems
     that caused SWAPUS in TYPE71 to be high, etc.  13Nov2000.

 5.  APAR II12548 states that "FICON channel reports incorrect RMF data
     for tape.  In the case where the first CCW in the chain gets
     initial status of CMD Retry, SFI is not being called, causing
     incorrect function pending and device disconnect times. 13Nov00

 4.  APAR OW45083 corrects one byte error in SMF type 94 record.

 3.  APAR OW44870 corrects High CPU usage in VLF Module COFMTRIM.

 2.  APAR OW45192 corrects negative service unit values for enclaves, if
     APAR OW40548 has been installed, in TYPE72GO dataset. 03Nov2000.

 1.  APAR OW40458 corrects negative service unit values (which MXG would
     see as large positive values) in TYPE72GO for second period, if a
     multi-period server address space stops being a server. 3Nov2000.

IV.  DB2 Technical Notes.


V.   IMS Technical Notes.


VI.  SAS Technical Notes.

 4. Error message about I/O ERROR on the SAS log and a partial SYSMSG
    text about SOURCLIB, READ, OUT OF EXTENTS, BPAM ... results if you
    mix PDS and PDSE libraries in your SOURCLIB concatenation.  Using
    all PDSs solved the error.  This was a 2001 note and is probably
    no longer accurate in 2006; many sites concatenate PDS and PDSE
    without any problems under SAS V8.2 and V9.1.3.

 3. The old-style substitution type macros,  MACRO  macroname ...  %
    are now documented by SAS on their homepage in technote ts-289, at
    http://ftp.sas.com/techsup/download/technote/ts289.txt.

 2. Under Version 8, a tape format dataset on disk should ALWAYS have a
    BLKSIZE=27798 specified on the DD statement for that dataset, so
    that space is not wasted:
    - If the SAS V8 sequential engine is in use, it will always force a
      32K blocksize if no BLKSIZE was specified on the DD statement in
      your JCL;
    - A BLKSIZE=27798 can be specified on the LIBNAME statement but it
      prints a warning message and the BLKSIZE will STILL be 32K;
    - A BLKSIZE of 27798 cuts the space requirement by 42 percent!
    - And even if compression is specified, the 'super blocking' is
      done by the compression engine, so there the BLKSIZE=27798 has
      no negative impact.
    This BLKSIZE=27798 should be specified where you are using the
    //TAPETEMP DD as in your weekly and monthly jobs, and the MXG JCL
    examples now have the BLKSIZE=27998 specified.


1. Summary of ALL important SAS V8.1 Issues.  17Dec2000.
   This list was shown at the MXG User Group Session at CMG 2000:
   See the prior newsletters' text for more details.

   a. Remove MEMSIZE=64M from CONFIG member (use MXG CONFIGV8 member),
      and let your REGION= parameter control virtual storage.  Must do!

   b. USE SEQENGINE=V6SEQ instead of V8SEQ or install Z8002651.
      The error is fixed in SAS 8.2.

   c. Use SAS member (BATCH) instead of (BATCHXA) in the //CONFIG
      concatenation in your JCL, (or use MXGSASV8 JCL procedure
      example).

   d. Do not use Secondary Allocation and Guaranteed Space for SAS Data
      Library on DASD.  G.S. is no longer required to get multi-volume
      DASD SAS data libraries, but can be used; the existence of G.S.
      AND a secondary allocation causes the error (which will eventually
      be fixed by SAS).

   e. Error with PROC COPY IN=WORK OUT=PDB; if the PDB is a V6 SAS data
      library on disk, while copying the WORK.REGSTRY(MEMTYPE=ITEMSTOR),
      with this SAS Error message:
        ERROR: REQUESTED FUNCTION IS NOT SUPPORTED.
      or if the PDB is a V6 Sequential data library, with this message:
        ERROR: UNABLE TO OPEN CATALOG PDBTAPE.SASMACR(MEMTYPE=CATALOG)
               FOR WRITE ACCESS. ENGINE V6SEQ DOES NOT SUPPORT WRITE
               ACCESS.
      You must add MEMTYPE=DATA to your PROC COPY statement:
          PROC COPY IN=WORK OUT=PDB MEMTYPE=DATA;
      because SAS V8 now used MEMTYPE=ALL as the default.
      Revised 23Jan2001.

   f. SAS V8 ABEND S01D when HSWORK is used.  SAS zap Z8001639 fixes.

   g. SAS V8 8 does not support V5 data libraries:
      -  Use V6 to PROC COPY from V5 to V6 lib (DISP=NEW)
      -  Then use V8 to PROC COPY from the V6 library.

   h. What level of MXG is needed for SAS V8.1?

      MXG 16.16 ran with SAS V8, with a warning note that the SAS
                options CODEPCT and BLKSIZE(TAPE) don't exist.
      MXG 17.01 provided new CONFIGV8 without those two options to
                remove the warning note on MVS.
      MXG 17.07 exploits 32000 byte length of character variables, but
                only if COMPRESS=YES was specified, and only for SQL
                text variable in TYPE102.
      MXG 17.08 exploits the new INHERIT option of PROC MEANS in
                VMXGSUM, to skip a data step that is now unneeded.
      MXG 18.04 changed V8 default to SEQENGINE=V6SEQ.
      MXG 18.05 removed MEMSIZE from CONFIG, (and reinstated options
                S=72,S2=72 that had been removed in 17.17).


VII. CICS Technical Notes.

 2. APAR PQ42713 fixes CICS/TS 1.3 error that lost significant CPU time
    in CICSTRAN variable TASCPUTM (IBM fields USRCPUT), for transactions
    that make use of the RMI, and when an MCT with user EMPs is used.
    (Using an MCT without the EMPs appears to cause correct CPU time to
    be captured).  CPU capture in TS 1/3 was changed to cater for the
    introduction of OPEN TCBs, and an error in that change caused the
    CPU time used from when the task is either dispatched or resumed, up
    to the point when processing of an EMP begins, to be not included.
    The APAR mentions 50% CPU was lost, but I suspect use of EMPs is not
    common.


 1. APAR PQ41392 corrects wrong TERMID in type 110 SMF records for non-
    terminal transactions.  CICS/TS 1.3.  Dec 1, 2000.

VIII. Windows NT Technical Notes.

IX.   Incompatibilities and Installation of MXG 18.04.

 1. Incompatibilities introduced in MXG 18.04 (since MXG 17.17):

  a- No changes in MXG architecture were made between 17.17 and 18.04
     that introduced incompatibilities.

 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.


X.    Online Documentation of MXG Software.

    MXG Documentation is now described in member DOCUMENT.


XI.   Changes Log

--------------------------Changes Log---------------------------------

 You MUST read each Change description to determine if a Change will
 impact your site. All changes have been made in this MXG Library.

 Member CHANGES always identifies the actual version and release of
 MXG Software that is contained in that library.

 The CHANGES selection on our homepage at http://www.MXG.com
 is always the most current information on MXG Software status,
 and is frequently updated.

 Important changes are also posted to the MXG-L ListServer, which is
 also described by a selection on the homepage.  Please subscribe.

 The actual code implementation of some changes in MXG SOURCLIB may be
 different than described in the change text (which might have printed
 only the critical part of the correction that need be made by users).

 Scan each source member named in any impacting change for any comments
 at the beginning of the member for additional documentation, since the
 documentation of new datasets, variables, validation status, and notes,
 are often found in comments in the source members.

Alphabetical list of important changes after MXG 17.17 now in MXG 18.04:

  Dataset/
  Member   Change    Description

  See Member CHANGES or CHANGESS in your MXG Source Library, or
  on the homepage www.mxg.com.

Inverse chronological list of all Changes:

Changes 18.265 thru 18.001 are contained in member CHANGES.

****************NEWSLETTER THIRTY-SEVEN*********************************










             MXG NEWSLETTER NUMBER THIRTY-SEVEN, October 20, 2000

Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE

                         TABLE OF CONTENTS                          Page

I.   MXG Software Version 18.08.
II.   MXG Technical Notes
III.  MVS Technical Notes

IV.   DB2 Technical Notes.
V.    IMS Technical Notes.
VI.   SAS Technical Notes.
VII.  CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX.   Incompatibilities and Installation of MXG 18.08.

X.    Online Documentation of MXG Software.

XI. Changes Log
     Alphabetical list of important changes
     Highlights of Changes 18.001 thru 18.250 - See Member CHANGES.

      COPYRIGHT (C) 2000 MERRILL CONSULTANTS DALLAS TEXAS USA

I.   MXG Software Version 18.08 is now available, upon request.

 1. Major enhancements added in MXG 18.08:

II.  MXG Technical Notes

 1.   Converting from JES3 to JES2 (or vice versa) could cause problems
      in your weekly/monthly jobs or in your regular reporting:
        -JES2's BUILDPDB creates the PDB.NJEPURGE dataset, which is not
         created by JES3, while JES3's BUILDPD3 creates the PDB.TYPE25,
         PDB.DJEPURGE, and PDB.SPIN25 datasets, which are not created by
         JES2.  If those non-created datasets are referenced in reports
         or WEEK/MONTH build jobs, you must revise those programs when
         you change JESes.
        -BUILDPDB for JES2 creates variables in PDB.JOBS, PDB.SPIN26,
         and PDB.SPUNJOBS, from JES2 6 and 26 records, that do not
         exist in those datasets built by BUILPD3 for JES3 records:
            ACTBYTES ACTPAGES DEVNAME  DUPJBDLY INNODE   INREASON
            INROUTE  JOBMODE0 JOBMODE1 OFFLPURG PRNTCOPY PRPRTY
            PRROUTE  PUROUTE  SETUP    SMF26WCL SMF26WIN SMF26WJC
            SMF26WOC SMF26WSE SUBMUSER SYSTRANS

III. MVS Technical Notes.

26.   APAR OW46470 corrects wrong value in TYPE1415 management class and
      data class variables MGMTCLAS and DATACLAS. 19Oct2000.
      See also OW46606. 03Nov2000.

25.   APAR OW46336 corrects wrong value in TYPE26J2 variable JOBMODE1,
      set from IBM bit SMF26SJB to indicate "Job ran because of $S J'.
      IBM never set the bit, so JOBMODE1 was always blank in MXG. 19Oct.

24.   APAR OW43954 corrects a problem with high disconnect time in RMF
      variable R723CIDT in dataset TYPE72GO, that also affected measures
      of velocity and delays.

23.   APAR OW44517 corrects a problem with high uncaptured CPU time,
      with capture ratio dropped by 10% (i.e., CPU time was lost in both
      SMF type 30 and RMF type 72 records).  This APAR applies to OS/390
      R2.5 thru R2.10.

22.   APAR OW45020 recommends you should now specify NOTYPE(69), even
      though there are no type 69 (VSAM Data Space) records.  An LSPACE
      macro is issued if TYPE(69) is specified explicitly or implicitly,
      and that LSPACE can cause an IPL or long delay as discussed in the
      APAR text.  Sep 7, 2000.

21.   BMC's CMF type 71 SMF record had incorrect values for CSFRxxxx
      fields.  Relevant BMC PTF numbers are BPM6617 (introduced error),
      BPM6791 (fixed to make CMF look like RMF) & BPM7077 & BPM7557.
      MXG Change 18.199 is also needed for CSFRxxxx TYPE71 variables.

20.   APAR PN65504 reports SMF type 118 has incorrect timestamps for FTP
      start and stop events if the C-FTP server is used; timestamps for
      the Pascal FTP server had correct numbers.  The C-FTP server used
      the time function of the C runtime, which returned the number of
      seconds since Jan 1, 1980, when it was only the seconds from the
      midnight that should have been returned.

19.   APAR PQ38319 for DFSORT R14 does not impact MXG sorting under SAS,
      but if your site uses DFSORT to sort SMF (or any VBS) records, and
      also uses E15/E35 Sort Exits, this APAR corrects DFSORTS error
      MSGICE204A 5 INCOMPLETE SPANNED RECORDS DETECTED ON SORTIN.

18.   APAR OW45192. RMF 72 records have very large values in CPU time,
      elapsed time, and in CPUUNITS fields ('7FFFFFFF'x > 2*10**9 ), but
      only in records from Performance Groups or Service Classes in
      which enclaves are running.  PTFs for APAR OW40548 (which raised
      the previous limit of 5,000 enclaves per system to over 32,000)
      introduced the error, but only for OS/390 R2.6, R2.7, and R2.8
      (the R2.9 PTF for APAR OW40548 was not in error).

      The bad data was first seen in records from the DDF (Distributed
      DB2), because DDF is the most common user of enclaves, but other
      enclave users include CPU Parallelism in DB2, IBM's Web Server (in
      Scalable mode), and the MQ Series WorkFlow products.

      These bad values cause Negative Uncaptured CPU time error messages
      on the SAS log during creation of MXG dataset RMFINTRV, and trash
      the TYPE72/TYPE72GO and PDB.RMFINTRV datasets.

      Until IBM has a PTF for APAR OW45192, you must delete these bad
      observations, in the MXG exit member EXTY72 or EXTY72GO.  Look at
      your TYPE72/TYPE72GO data to see if CPUUNITS can be used to detect
      and if so, then delete the bad observations using:
        IF CPUUNITS GE 2E09 THEN DELETE;
      in the exit member.  Or you could use the PERFGRP number or the
      SRVCLASS name to delete the DDF (or any other) observations with
      the bad data values.   26Jun2000.

      Sep 21, 2000:  PTFs exist for APAR OW45192 and did correct that
      error at one site.

17.   APAR OW41270, OS/390 R2.8 caused creeping ECSA problem that was
      resolved by OW43069.

16.   APAR OW39924, OS/390 R2.8 and R2.9, macro STCKCONV bad. 17May2000.
      There is a blank line in the IBM STCKCONV macro, and it causes the
      Assembly of ASMTAPES to fail under OS/390 R2.8 and R2.9.  The APAR
      identifies the blank line to be removed (or the High Level ASM
 can
      be used, as the blank line does not trip it up!).

15.   APAR OW40458 corrects large values in TYPE72GO Period 2. 27Apr00.
      If you are in Goal Mode and specify multiple periods for the
      service class that CICS or IMS regions are running in, and you
      are also classifying the transactions, negative/large/invalid
      values for many variables in period 2 and later periods are
      created, because when an address space stops being a server,
      it is moved back to period 1 without updating the workload
      reporting numbers for the period it had been running in.  While
      the APAR fixes the IBM error, the site with the problems real
      culprit was the accidental misclassification of a test CICS
      region into a service class with multiple periods.
        This caused large negative PCTOVHD and CAPTURAT over 100% in the
        PDB.RMFINTRV; CPUTCBTM was greater than CPUACTTM also.

14.   APAR OW43817 corrects SMF type 85 CICS TRAN ID blank.  26Apr2000.
      OAM SMF 85 R85PTRXN was not filled in for customers using the
      Default Security Checking Bypass, because the Authorization Check,
      and the Gathering of Userid, Trans ID were both being bypassed.

13.   APAR OW43581 corrects SMF type 17 fields. Apr 26, 2000
      Installing APAR OW41664 corrupts SMF type 17 fields JOB, READTIME,
      and LOCLINFO, and the DSNAME has 'SYS' in Columns 1-3.  New APAR
      OW43581 corrects the problem created when the strengthening of
      DADSM's name checking by OW41664 destroyed the register used to
      build the type 17 SMF record (Data Set SCRATCH).

12.   APAR OW43846 (FIN=Fixed In Next). Apr 17, 2000.  Incorrect values
      in type 14/15 SMF records for striped extended format sequential
      data sets.  The first stripes number of tracks is not included in
      SMF15NTU if the OPEN was for output with partial release, and both
      SMF14NTU and SMF15NTU are too large by one track for each stripe.

11.   Multi-volume tape data library last vol not read. April 16, 2000.
      IBM APAR OW31263 (1997) for message IEC999I IFG0551H,jjj,prog....
      The 35th volume of a 35 volume CICSTRAN-on-tape was not read after
      being created; the job stopped after the 34th volume.  The SAS log
      reported only that an error had occurred "OUTSIDE THE SAS SYSTEM".

10.   IBM/Tivoli NetView/FTP Apr 6, 2000.  FTP apparently creates SMF
      records for FTP with ID=0 if you do NOT specify SMFREC=nnn INIT
      parameter for FTP.  MXG detects a "Bad IPL" record and deletes;
      a hex dump of the type 0 record shows NFTP as the product name.

 9.   RMF TYPE74 PAV/SHARK Apr 3, 2000.  APAR OW40885 reports incorrect
      (high) values for PAV devices director port busy (DPB), control
      unit busy (CUB) and device busy (DB).

 8.   CA Dispatch. April 1, 2000.  CA Dispatch Release 5.1 can produce
      type 6 SMF records with non Y2K Ready date value in SM6JLDAT (the
      date part of READTIME); this only seems to occur for Dispatch
      data sent directly to 'distribution' (as opposed to printing from
      'online viewing' or 'archiving').  CA has a temporary ptf
      available under CA Problem Number 1195.

 7.   TCP/IP SMF records.  Mar 15, 2000.  APAR PQ36346 reports that the
      wrong STC name (SMFAPINM) is in the SMF INIT API call records.
      The INIT record has the started task name of the TCP/IP stack, the
      TERM record is correct and has the started task name of the
      application.

 6.   FTP SMF records.  Mar 15, 2000. APAR PQ36103 reports that an SMF
      record is not always written when an FTP client user aborts the
      connection to OS/390 FTP server.  IBM reports "FIN", Fixed in Next
      Release, but notes "problem is easily avoided if the client FTP
      user avoids aborting the transfer"!

 5.   WEBSERVER SMF 103.  Mar 15, 2000.  APAR PQ32435 reports that the
      incorrect IP stack address is stored in a VIPA environment.
      The OS/390 Webserver (IHS) writes SMF records TYPE103 subtypes 1
      and 2 to report configuration and performance data.  The customer
      has an environment with multiple Webservers using VIPA and Network
      Dispatching via D/T2216 routers.  They found that the IP address
      of the Webserver, reported in the SMF record, derived from the
      HTTP Server MIB, variable EntityAddress (and also EntityPort) were
      incorrect. The record always contains the default IP stack's
      primary IP address.  They also noted that the records do not
      contain the jobname of the webserver, which would be useful for
      subsequent analysis.  This APAR is recently opened and no PTF yet.


 4.  OMVS/USS TYPE 30. Mar 15, 2000.  Information APAR II12312:
     On OS/390 V1R3 and prior, OMVS used APPC/ASCH initiators for
     address space creation.  From RACF definitions, an OMVS users
     workaccount and workattribute fields were added to the EXEC card
     and this information was recorded in SMF Type30 Subtype 2 and 3
     records, so OMVS Accounting fields are in the SACCTn variables in
     MXG's TYPE30_V and PDB.SMFINTRV datasets.  With OS/390 V2R4+, OMVS
     now uses WLM initiators for address space creation.  From RACF
     definitions, an OMVS users workaccount and workattribute fields are
     added to the JOB card and this information is recorded in SMF
     Type30 Subtype 1 and 5 records, so the OMVS/USS accounting fields
     will be in the ACCOUNTn variables in MXG TYPE30_1 and TYPE30_5
     datasets, and in the PDB.JOBS/PDB.STEPS observations for OMVS jobs.

 3.  DCOLLECT. Mar 8, 2000. APAR OW43104 reports incorrect Device
     Type on the type 'V' records for RVA and SHARK DASD.  RVA shows
     9393 instead of 3390 and the SHARK showed as /UNKN/.

 2.  TYPE92. Mar 3, 2000. According to APAR OW41113, SMF 92 records cut
     for open/close under UNIX System Services capture the SAF (RACF)
     userid of the process (server) rather than the actual caller of the
     service (task).  The "process" level OMVS Real UserId and OMVS Real
     GroupId were being recorded instead of the "task" level OMVS Real
     UserId and GroupId.  As of March 3, 2000, that APAR was only a
     request; there is no PTF yet that actually records the "task" level
     IDs in SMF type 92 records.

 1.  TPX 4.1. Feb 9, 2000.  TPX 4.1 originally wrote GMT time, and then
     added GMT offset, so MXG converted times to Local time, but now TPX
     has added a new PARM, "Reserve Option #45=Y", that changes the time
     values in the record to Local time, but sets no flag in the record
     that the timestamps are now on the local clock, so MXG re-adjusted
     the time away from local by the GMT offset.  (In my opinion, they
     should have just zeroed the GMT offset field when the times are
     local, and MXG would have calculated correctly!).  But instead, you
     must set that parm to N so that the record values are in GMT and
     the non-zero GMT offset will be used by MXG to correct TPX records.

IV.  DB2 Technical Notes.

 1.  DB2STATS. Mar 29, 2000.  APAR PQ21969 corrects QTSLWDD values; the
     incorrect (large) value in the type 100 subtype 1 SMF record caused
     negative values for IN USE DATASETS in DB2PM and ANALDB2R reports.
     DSNB1CST did not decrement the count in QTSLWDD correctly when
     closing a linear pageset with multiple pieces during deferred close
     request processing, i.e., a problem in serialization if several DB2
     jobs 'declaim' at nearly the same time.  APARS PQ23458 affects the
     Program name and PQ24406 affects the count of datasets closed due
     to DSMAX or DDLIMIT being exceeded in error.

V.   IMS Technical Notes.

     Sep 12, 2000.  IMS PTF UQ35642 for APAR PQ30803 has no impact.
     That change to the IMS log record fixes an IBM error, where a bit
     in field DLRNOSTP is now set when it was not, but MXG does not use
     nor care about that bit flag.

VI.  SAS Technical Notes.

12. Starting with SAS 8.1, the Sequential Engine names of SASV5SEQ,
    SASV6SEQ, and SASV7SEQ cannot be used.  However, the engine names
    of V5SEQ, V6SEQ, V7SEQ, V8SEQ, & VnSEQ are still supported and will
    be supported in future versions.  Fortunately, I never knew of the
    SASVnSEQ form, so all MXG notes and references have been for VnSEQ!
    This note was precipitated because the manual What's New in SAS 8.1,
    page 21, Chapter 7 states that "SEQENGINE= now has a default of TAPE
    and no longer supports values in the form SASVnSEQ".  SAS plans to
    change the note to document that the VnSEQ form is still valid.
    Additionally, the default of TAPE will be the VnSEQ engine for the
    Vn release of SAS, i.e., TAPE=V8SEQ when under SAS V8.  28Sep2000.

11. If you use SAS V8's default Engine to write to a SAS Data Library
    that was previously written to by a SAS V6 Engine, and MXG has set
    the new SAS V8 option SASCHRLN=32000 (done for you by VMXGINIT when
    under V8, but only if you also set option COMPRESS=YES, for some
    long text variables in type 102 records), you get ERROR: CHARACTER
    VARIABLE HAS TOO LONG A VALUE FOR THE SASEB ENGINE, because SAS
    recognized the output data library was built with V6, so it changed
    the default Engine from V8 to V6, but the V6 engine doesn't support
    long-length variables! The only permanent fix is to not do that:
    change your data libraries to V8-built.  You must allocate new data
    libraries ("PDBs"), and use PROC COPY to copy from V6 to V8, then
    delete the old data library, and rename the old back to new.  You
    cannot use PROC DELETE nor PROC DATASETS to delete all members and
    re-use the existing data library, because the SAS directory remains
    in V6-format, and so that data library will always be built with the
    V6-engine.  However, if you still must create SAS V6 data libraries
    under MXG under SAS V8, you can reset the value of SASCHRLN by using
       %LET SASCHRLN=100;  as your first //SYSIN.           Sep 6, 2000.

10. Comparing values between MXG PDBs built with V6 versus V8 can show
    some differences, but only in the 7th-8th significant digit.  The
    SAS V8 INHERIT parameter of PROC SUMMARY/PROC MEANS apparently now
    uses the length of the input variable for the internal length use in
    calculations, whereas without it SAS uses an internal length of 8 in
    calculations.  With an input dataset that had length 4 variables,
    the output values with INHERIT are slightly less than the same PROC
    MEANS without INHERIT specified.  INHERIT was designed for MXG so
    that an entire step in VMXGSUM can be avoided.


 9. SAS V8 did not RELEASE space from SAS Data Libraries when it was
    requested.  SAS Technical Note SN-002674 has the fix.  28Jun00.


 8. PROC APPEND with new versions of MXG/ITSV:  26Jun2000.

    If you use PROC APPEND to create week-to-date
    or month-to-date SAS datasets, new variables added to
    MXG datasets will not be added to the APPENDed "Base"
    dataset, and lengths of variables that were changed
    in MXG will not be changed in your "Base" dataset.
       MXG does not actually use PROC APPEND in its code,
       because it breaks the sort order of sorted datasets,
       but now also because it doesn't propagate dataset changes.

    But if you have inherited a job that uses PROC APPEND to
    concatenate NEW observations to a BASE dataset:
      PROC APPEND BASE=BASE.DATASET NEW=NEW.DATASET FORCE;
    and if the contents of NEW.DATASET are different, you get
    a condition code 4 and these warning messages on the SAS log:
     WARNING: Variable x was not found on BASE file and/or
     WARNING: Variable y has different lengths on Base and Data files
             (BASE 4 DATA 8).
    and the output BASE.DATASET will still have only the
    original variables and their original attributes.

    You must replace the "BASE.DATASET" with a dataset with the same
    name:

    a. Somewhere in your jobstream, before the first day of the
       whatever-to-date you are building, or after the last day
       of that period, that BASE.DATASET is being re-set to zero
       observations, instead of being deleted.
          If it were being deleted, then the first execution of
          the PROC APPEND with a null BASE dataset will contain
          all of the variables in the NEW dataset.
       Find where that setting of BASE.DATASET to zero observations
       is located, and replace it with a PROC DELETE DATA=BASE.DATASET
       before the first-day-of-period run.
          However, BASE.DATASET will contain only those variables in the
          NEW dataset; variables dropped by the new version will not
          exist in the replacement BASE.DATASET.  If your reports used
          those now-non-existent variables, they could fail, but because
          of this impact, MXG almost never drops variables!

    b. Or, with complete safety, you can re-create your BASE.DATASET, as
       it now exists, to contain the union of all variables in both the
       BASE.DATASET and NEW.DATASET, with all of the observations in the
       BASE.DATASET, adding nothing from NEW, with this program. Execute
       the program for each DATASET in the BASE library that is being
       PROC APPENDED (after first backing up the BASE library!):

          /* Create WORK.NEWBASE with zero obs but with all variables*/
          OPTIONS OBS=0;
          DATA WORK.NEWBASE;
          SET  NEW.DATASET BASE.DATASET;
          RUN;
          /* Reset option obs to max to now actually read observations*/
          OPTIONS OBS=MAX;
          RUN;
          /* Data step will create a new BASE.DATASET; by listing the */
          /* WORK.NEWBASE first, its attributes will be used to set   */
          /* the attributes of variables found in NEWBASE.            */
          DATA BASE.DATASET;
          SET WORK.NEWBASE BASE.DATASET;
          RUN;

 7. SAS Version 8/8.1 corrupted multi-volume SAS Data Library. Jun 23.
    SAS Version 8 & 8.1 will create a corrupted multi-volume SAS Data
    Library on DASD (but not a problem with multi-volume Tape), if you:
      - Use a STORCLAS with "Guaranteed Space" attribute enabled when
        the library dataset was allocated, and
      - Have a non-zero Secondary Space Allocation value in the SPACE=
        parameter when the library dataset was allocated, and
      - The second volume was actually written to.

    There is NO error during creation, but when the data library is read
    you may get USER 0315 ABEND, with this error message on the SAS log:
       Physical I/O error on SAS data library DATA.SET.NAME on
       volume volser,jobname,stepname,dev-addr,ddname,86-OP
    or you may just get RC=8 with these messages on the SAS log:
       Expecting page NNN, got page -1 instead.
       Page validation error while reading LIBREF.DATASET.DATA
       File LIBREF.DATASET.DATA is damaged.
       I/O processing did not complete.

    Removing the Secondary Space Value will eliminate this error, and,
    if you still must use Guaranteed Space (for example, so you can use
    VOLSER= in your JCL), that is the solution.  However, if the only
    reason you used a STORCLAS with GS was to satisfy SAS V6, then the
    permanent solution is to remove the Guaranteed Space attribute from
    the STORCLASS, or change your JCL to a different STORCLAS that does
    not have the GS attribute specified.

    Under SAS V6, GS was REQUIRED for multi-volume DASD, but GS does not
    use secondary extents, although they were tolerated in your JCL by
    V6.  Now, under SAS V8, the existence of a secondary value and GS
    causes the corruption (but only when the second volume is actually
    opened), but GS is no longer required by V8, and in general, GS
    should not be used with V8:  with GS and five volumes of 3000 PRI
    cylinders, you get 15,000 cylinders whether you need it all or not,
    whereas with SAS V8 and without GS, you allocate only the primary on
    the first volume, until more is needed by today's job!

    Tests with SAS V8 multi-vol DASD strongly suggest that you SHOULD
    have a secondary allocation value, once you have removed the GS
    attribute, as it makes it easier for allocation to find more space
    when available on each volume.

    How do you know if you have Guaranteed Space?  Look at the STORCLAS
    of the Data Library (either in the JCL or on the SYSMSG allocation)
    and go to your Storage Administrator, who can use ISMF to see if the
    GS attribute is specified for that Storage Class.

    SAS Institute is currently investigating a fix (at best, probably,
    to force a failure rather than creating the corrupt dataset), and
    SAS Technical Support Note 002881 will be posted later this week to
    track the problem.

    In summary:  For Multi-Volume Data Libraries under SAS V8:
      a - If you must use Guaranteed Space, do not have a Secondary.
      b - Without Guaranteed Space, do have a Secondary allocation.


 6. SAS V8  PROC COPY IN=WORK OUT=PDB; if the PDB DDNAME points to a V6
    SAS data library, when copying WORK.REGSTRY (MEMTYPE=ITEMSTOR), with
    ERROR: REQUESTED FUNCTION IS NOT SUPPORTED, PDB.REGSTRY.ITEMSTOR HAS
    NOT BEEN SAVED....  While SAS investigates, adding MEMTYPE=DATA to
    the PROC COPY is what you really wanted in the first place, and will
    avoid the incompatibility.  Jun 12, 2000.


 5. The SAS V8 TAPE Engine cannot be safely used.  May 12, 2000.

    The SAS V8 TAPE Engine (V7SEQ=V8SEQ) cannot be used with complete
    safety to create or even to read tape-format datasets.  LABELs of
    variables in datasets that are created (on tape or disk!) from
    V8SEQ-format datasets can be trashed (truncated, overlaid, extra
    blanks) if a SET statement with a (KEEP=) dataset option is used.
    Bad LABELs can destroy reports, and there is no warning, error
    message, nor a condition code set.  V8SEQ can also error if you
    create tape-format on DASD, but at least then, you do get an error!

    These errors were found too late to be fixed in SAS Version 8.1!

    July 26, 2000 update: See SAS Note SN-002651.  SAS ZAP Z8002651 now
    exists for SAS V8.0 and V8.1, and the error is corrected in V8.2.

    Until then, the circumvention is to tell SAS Version 8 to use the
    V6SEQ engine instead of the V8SEQ engine (both to create and to read
    tapes) until SAS Institute has a corrected version.

    The Trashed LABELs error:

    SAS V8 will create V8SEQ-format datasets on tape, and the LABELs in
    the tape dataset are fine, but if you then read that tape dataset to
    create a new dataset, the LABELs in that new dataset are trashed if
    the SET statement also uses the (KEEP=) dataset option:
      DATA SUBSET; SET CICSTRAN.CICSTRAN (KEEP= A B .. Z);
    While this case exposes the error, there may be other exposures.
    MXG uses (KEEP=) to reduce the number of bytes read into memory.  It
    is used in VMXGSUM (invoked by all TRNDxxx members and most ASUMxxxx
    members), and bad labels were found first in TRND70PR.  The (KEEP=)
    option is also used by ASUMUOW, which has only data steps, was the
    second instance of bad labels, and helped isolate the problem.

    The circumvention for Trashed Labels error in SAS V8.0 and V8.1:

    You should add  SEQENGINE=V6SEQ  in your CONFIG member to make V6SEQ
    your default tape (sequential) engine.  However, you must also scan
    your tailoring and report source libraries for any instances of
    "LIBNAME ddname TAPE;" and must change "TAPE" to "V6SEQ", because
    TAPE in a LIBNAME statement overrides the SEQENGINE option, and TAPE
    defaults to V8SEQ under SAS V8, a default that cannot be changed.
    SAS V8 should be able to detect that a tape dataset was built with
    the V6SEQ engine, but it can't.  If you try to read a V6SEQ dataset
    with V8SEQ engine, the step fails with error message:
      LIBRARY ddname IS NOT VALID FORMAT FOR ACCESS SASV7SEQ!
    That's why you should change you CONFIG option to SEQENGINE=V6SEQ.
    However, you could instead add a LIBNAME statement for each tape DD,
    (in your SYSIN stream) with "LIBNAME ddname V6SEQ;" and not have to
    update the CONFIG member, but changing the CONFIG member is probably
    the best circumvention.

    Second V8SEQ error, tape-format-on-DASD.

    V8SEQ also fails if you try to write a tape-format dataset on DASD,
    using just the old DDname convention of //TAPExxxx to invoke the
    tape engine, because that option invokes only the V5SEQ engine, and
    SAS V8 is no longer backwards compatible, as it can only read V5SEQ
    libraries; writing to V5SEQ from V8 causes error messages:
     WARNING:76-63: THE OPTION LABEL IS NOT IMPLEMENTED IN V5TAPE ENGINE
     ERROR: WRITE ACCESS TO MEMBER TAPEXXXX.yyyyyyyy.DATA IS DENIED.
    This is documented in the SAS Companion for MVS, V6, Second Edition,
    Appendix I, page 437, which is also the reference in the V8
    Companion for MVS.

    The circumvention is to use   LIBNAME   ddname  V6SEQ ; for any
    tape-format-dataset-on-DASD.

    MXG's WEEKBLDT and MONTHBLD members use //TAPETEMP for temporary
    files to create weekly and monthly PDBs on tape without rewinds, but
    both had "LIBNAME TAPETEMP TAPE;" statements, so that "TAPE" was
    changed to "V6SEQ" in those two members.

    Even if you specify SEQENGINE=V6SEQ in CONFIG, that only applies if
    the actual device is tape;  to now create a tape format dataset on
    DASD under SAS V8, you must now also specify:
      LIBNAME TAPExxxx V6SEQ;  or  LIBNAME ddname V6SEQ;

    The text of Change 18.104 has details on the actual MXG changes.

 4. SAS V8 OPTION FILEEXT=IGNORE default value must be used with MXG.
    The new options can be used to control the syntax than can be used
    in SAS programs to reference PDS member names; the FILEEXT=VERIFY
    should not be used, since MXG syntax works just fine when OS/390
    "ignores" this option by default.  FILEEXT=VERIFY causes errors:
     ERROR: MEMBER NAME VMXGINIT.SAS CONTAINS AN EXTENSION.
     THE SYSTEM OPTION FILEEXT IS SET TO VERIFY, WHICH REQUIRES THE LAST
            QUALIFIER OF THE PDS OR PDSE TO MATCH THE EXTENSION.
     ERROR: CANNOT %INCLUDE MEMBER VMXGINIT IN THE AGGREGATE SOURCLIB.

 3. SAS V6.09E TS455 or later, VM 1319 and USER ABEND 1319, "No MKLEs"
    can be corrected by SAS zap number Z609E449, although the problem
    can also be circumvented simply by a) making sure your MEMSIZE
    option in MXG's CONFIG member is 64M, and b) making sure your REGION
    parameter is also 64M so that SAS can get its requested MEMSIZE.

 2. SAS V8 ABEND S01D when HSWORK is used.  Apr 25, 2000.
    SAS zap number Z8001639 corrects said ABEND with SAS Version 8.

 1. SAS V8 does not support V5 data libraries. Apr 17, 2000.
    SAS V8 does not support V5 format data libraries (recognizable by
    their old RECFM=U,BLKSIZE=32760 DCB), failing when written-to with a
    WRITE ACCESS DENIED error (which otherwise is the result of using
    DISP=SHR for an output SAS data library).  In this case, it was the
    MXG //SPIN library in the BUILDPDB logic that was still V5, so to
    preserve the data and create a V8-format data library, the site
    first used V6 to PROC COPY from V5 to a V6 library (DISP=NEW), and
    then used V8 to PROC COPY from the V6 library to the (new and not
    backwards compatible) V7/V8 SAS data library (DISP=NEW).

VII. CICS Technical Notes.

 1. APAR PQ41392 corrects wrong TERMID in SMF type 110 records that was
    written for non-Terminal transactions.  The TERMID name was FHCI.

VIII. Windows NT Technical Notes.

IX.   Incompatibilities and Installation of MXG 18.04.

 1. Incompatibilities introduced in MXG 18.04 (since MXG 17.17):

  a- No changes in MXG architecture were made between 17.17 and 18.04
     that introduced incompatibilities.

 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.


X.    Online Documentation of MXG Software.

    MXG Documentation is now described in member DOCUMENT.


XI.   Changes Log

--------------------------Changes Log---------------------------------

 You MUST read each Change description to determine if a Change will
 impact your site. All changes have been made in this MXG Library.

 Member CHANGES always identifies the actual version and release of
 MXG Software that is contained in that library.

 The CHANGES selection on our homepage at http://www.MXG.com
 is always the most current information on MXG Software status,
 and is frequently updated.

 Important changes are also posted to the MXG-L ListServer, which is
 also described by a selection on the homepage.  Please subscribe.

 The actual code implementation of some changes in MXG SOURCLIB may be
 different than described in the change text (which might have printed
 only the critical part of the correction that need be made by users).

 Scan each source member named in any impacting change for any comments
 at the beginning of the member for additional documentation, since the
 documentation of new datasets, variables, validation status, and notes,
 are often found in comments in the source members.

Alphabetical list of important changes after MXG 17.17 now in MXG 18.04:

  Dataset/
  Member   Change    Description

  See Member CHANGES or CHANGESS in your MXG Source Library, or
  on the homepage www.mxg.com.

Inverse chronological list of all Changes:

Changes 18.264 thru 18.001 are contained in member CHANGES.

****************NEWSLETTER THIRTY-SIX***********************************










             MXG NEWSLETTER NUMBER THIRTY-SIX February 10, 2000

Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE

                         TABLE OF CONTENTS                          Page

0.   Summary of Y2K issues that were fixed in MXG 17.17.               3

I.   MXG Software Version 17.17 contains this newsletter, no printing. 4

II.   MXG Technical Notes                                              9

 1. Compatibility issue for products with deaccumulated records.       9
 2. Recent hardware timing measurements for moving files               9
 3. An example of the use of IMACFILE/MACFILE exit:                   10
 4. Make sure your MVS REGION size is 64M, or you may get errors.     10
 5. MXG Definitions with regard to MXG Software Changes               10

III.  MVS Technical Notes                                             11
 1. Typos in previous APAR numbers in NEWSLTRS/CHANGESS.              11
 2. APAR OW36535 corrects Start/Stop in type 42 subtype 6.            11
 3. Problems with ECSA creep are documented in APAR OW34249.          11
 4. CA-SPOOL product APAR GS98190 corrects type 6 record errors.      11
 5. How many volumes can you have in a multi-volume MVS dataset?      11
 6. How does software compression compare with hardware compression?  11
 7. How do you hardware compress a SAS dataset on OS/390?             12
 8. APAR OW38615 for RACF type 80 corrects PERMIT record.             13
 9. APAR OW37742 for Workload Manager "Goal Mode".                    13
10. APAR AR38393 for Hardware Compression bypass compressed.          13
11. APAR OW39277 for VSAM record statistics in LISTCAT.               13
12. LOTUS Domino may need a 2GB region.                               13
13. APAR OW37709, new BMF cache options, may help LOTUS Domino.       13
14. Shark/Parallel Access Volume hardware have several APARs.         13
15. IFASMFDP with //SYSPRINT to disk can lose data on I/O error.     13
17. VSAM Catalog reminder: they stop functioning 1/1/2000.            13
18. APAR OW32140 for WLM, CICS, reduces IRASASRV sampling rate.       13
19. APAR PQ25641 for Smart Batch reports possible data loss.          14
20. APAR PW30654 for TCP/IP have FTPEND earlier than FTPSTART.        14
21. APAR OW37263 needed for OpenEdition/USS type 30 accounting.       14
22. APAR OW39746 corrects TYPE74CF CPU busy exceeding interval.       14
23. APAR OW41239 corrects type 85 mounted duration for OAM.           14
24. APAR OW41169 corrects SHARK and type 42.6 activity counts.        14
25. APAR OW38842 causes blank OMVSEXPN in OMVS/USS TYPE30_4.          14
26. APAR PQ32322 for TCP/IP API has FFFFFFFFx for byte count.         14
27. APAR OW42559 for UCCOLDT in DCOLCAPD is invalid.                  14
28. SHARK/PAV/FICON APARs to 2.8 require MXG 17.08.                   14
29. The size of Hipervolumes on EMC boxes is in DCOLVOLS.             14

IV.   DB2 Technical Notes.                                            14
 1. Excess DB2 SMF type 101 records due to Query CP parallelism.      14
 2. APAR PQ10864 consolidates child task accounting.                  15
 3. APAR PQ27561 for increase QTXACLUN after 5.1
 4. The Sunrise product can corrupt DB2 101/102 timestamps.

V.    IMS Technical Notes.                                             9
VI.   SAS Technical Notes.                                            15
 1.  SAS 6.09 TS460 supports UCB's above the line, 0C4 fixed.         15
 2.  SAS Version 7 ABEND 913-1C fixed in SAS Version 8.               15
 3.  Options CODEPCT/BLKSIZE(TAPE) don't exist in Version 7.          15
 4.  Unknown Exception 80000602 due to bad SAS PROFILE.               15
 5.  WARNING removed in TS 465.                                       15
 6.  SMS "Immediate Release" can cause USER ABEND 315.                15
 7.  SAS V7 zap for SAS data library to exceed 32,767.                16
 8.  SAS V7 errors PROC SORT with Duplicate SORT KEY variable.        16
 9.  New PDJULI2 format and JULDATE7() function for Y2K help.         16
10.  SAS V8 Developer Release VBS I/O error if '1A'x in data.         16
11.  SAS V8 Developer Release has successfully run BUILDPDB.          16
12.  Note on impact of YEARCUTOFF on two digit literal dates.         17
13.  USER ABEND 0318 usually multi-vol, but other causes listed.      17
14.  Format libraries built with V7/V8 cannot be used with V6.        17
15.  Under Win NT, creating FORMATS fails with existing .SC2 file.    17
16.  SAS V8 Production, Win NT reads only first S370VBS concatenate.  17
17.  What level of MXG is needed for SAS Version 8 Release TS M0?     17
18.  Variable Blocked SOURCLIB can be used, with some cautions.       17

VII.  CICS Technical Notes.                                           18
 1. CICS RCT parm TOKENE= replaced in CICS/TS by the CICS RDO.        18
 2. MXG 17.04 or later required for CICS/TS 1.3.                      19

VIII. Windows NT Technical Notes.                                     19

IX.   Incompatibilities and Installation of MXG 17.17.                19

X.    Online Documentation of MXG Software.                           19

XI. Changes Log                                                       19
     Alphabetical list of important changes                           20
     Highlights of Changes 17.001 thru 17.395                      20-24

      COPYRIGHT (C) 2000 MERRILL CONSULTANTS DALLAS TEXAS USA

0.   Summary of Y2K Issues after MXG 16.16 fixed in MXG 17.17:

 a. Y2K Notes:

 MXG Supports Leap Year in Year 2000 because mapping of dates from
 SAS date/datetime values by SAS recognizes Feb 29, 2000 as leapday.

 ANALDATE utility (MXG 17.07, Change 17.262) will examine all SAS
 date/datetime variables in all datasets in a SAS data library
 and reports what dates are found.

 Outstanding APAR OW42559 for DCOLLECT variable UCCOLDT in DCOLCAPD
 dataset, has no PTF; date wrong, records lost, but IBM will fix it.

 b. MXG Software Changes for Y2K Ready after MXG 16.16 (in MXG 17.10+):

Change 17.363 (MXG 17.10):  Julian 0cyyddd were changed to 0cyyddd in
 products that had not been Y2K tested by anyone before.  See text for
 the list of products that were changed and those still not tested.

Change 17.352 (MXG 17.10):  TYPETMS5 variable OUTDATE was still 0cyyddd.

Change 17.344 (MXG 17.10):  Support for ZARA Release 1.3 is required
 because only that release of ZARA is Y2K compliant.

Change 17.341 (MXG 17.10):  VMXGVTOF VTOC reader had dates CREATED,
 EXPIRES, and LASTUSE wrong.  Text of Change contains correction.
 (VMXGVTOC is archaic, having been generally replaced by DCOLLECT.)

Change 17.231 (MXG 17.07):  Soft Audit XPMLKDT/XPMXPDT dates were not
 only not Y2K Ready, but were flat out wrong in MXG decoding.

Change 17.227 (MXG 17.07):  SAP IMS log record 'AE' was not Y2K Ready
 until SAP Release 5.0i. Date was 0DDMMYYF, incompatibly changed to
 YYYYMMDD format by that release, and now supported by this MXG change.

Change 17.216 (MXG 17.06):  MXG Tape Mount Monitor ASMTAPES must have
 been assembled with "ES6" to run under OS/390 R1.3 or later.  If it
 was assembled with ES5 or ESA, the INITTIME date will be 1900 in
 the SMF record, but as long as you are using MXG 17.xx or later, it
 will protect that 1900 date and your MXG dataset will be Y2K Ready
 even if you don't re-assemble the MXGTMNT program from ASMTAPES.

Change 17.136 (MXG 17.04):  TCP SMF record for TELNET in TYPETCPT
 IBM did not use century bit 0cyydddF for this TELLOGFT datetimestamp;
 instead used non-valid yyyydddF format, which creates year 3800 data.
 MXG replaced SMFSTAMP8 format with circumvention code to support.

Change 17.091 (MXG 17.02):  TELEVIEW 4.3
 Release was incompatible, dates had never been validated, now ok.

Change 17.021 (MXG 17.01):  HSM and TMS
 Date values are Y2K compliant, but default print format was 6 instead
 of 7, so the Julian Date of 2000001 prints as 2E6.   The default MXG
 format was changed; you can add FORMAT xxxxxx 7. ; to your reports.

I.   MXG Software Version 17.17 is now available, upon request.

 MXG Newsletter THIRTY-FIVE was the last printed MXG Newsletter.

 MXG Newsletter THIRTY-SIX and all future MXG Newsletters will not be
 distributed in printed form, but will be available in the MXG Source
 Library, member NEWSLTRS, and on the homepage, www.MXG.com.

 1. Major enhancements added in MXG 17.17:

      Support for OS/390 Release 2.9.
      Support for Lotus Domino Server Release 5.02.
      CICINTRV dataset creation logic was wrong.
      Revised utility to print NEWSLTRS/CHANGESS members.
      Revisions and updates with new variables in all ADOCs.

    Major enhancements added in MXG 17.10:

       Year 2000 errors fixed for TYPEZARA and VMXGVTOF.
       Y2K Cosmetic conversion of Julian dates from 00cyyddd to yyyyddd.
       TELNET LOGF Time field is Duration, not datetime, not Y2K prob!
       RMFINTRV/VMXGRMFI enhancements fixed and documented.
       Support for Beta91 Balancing Manager SMF record.
       Support for Software Innovation's LDMS product.
       Added a replica of MICS SNTNSS report from NETSPY (and fixed it).
       EXPDBOUT Example to add CICS Statistics datasets to your PDB.
       Several ANALRMFR enhancements, this was just most recent.
       Test version of VMXGSUM in XMXGSUM, uses SAS View to save DASD+.

    Major enhancements added in MXG 17.09:

       ABEND 2415, some sites due to no RECFM in //NULLPDS in SAS proc.
         Starting with MXG 17.07, VMXGINIT now opens //SOURCLIB, and
         some SMS sites get ABEND2415.  Adding RECFM=U to the //NULLPDS
         DD statement corrects the ABEND.  See Change 17.317.
       Support for IIS Log.
       Support for Windows 2000 Build 2195 NTSMF data.
       Support for remaining CA-VIEW Metrics validated.
       Support for additional Landmark TMVS subtypes.
       More IMS Log revisions for negative values, more in testing.
       RMFINTRV now invokes VMXGRMFI, supports 115 workload, SYNC59
       ASUMTALO Last-complete-interval now corrected.

    Major enhancements added in MXG 17.08:

       TYPEIMSA IMS Log revisions correct negative RESPNSTM/SERVICTM.
       TYPECIMS IMF SQLCALLS are lost due to INCOMPAT change in MVIMF.
       TYPE73 FICON PCHANBY/PNCHANBY wrong in initial FICON support.
       TYPE74 PCTPNCHA/PCTPNOTH/PCTDVPND/PCTPNDEV revisions.
       Support for APAR OW41147 ORGEXPDT=99999 - Read it: Y2K Critical
       Support for CA View Metrics SARSMFUX SMF record.
       Support for RACF Unload IRRDBU00 Started Task subtype.
       Support for TRMS Version 51A08 (COMPATIBLE).
       Support for Landmark DB2 Monitor V 3.2 (INCOMPAT).
       Support for APAR OW40579/41407 SMF 42 subtype 4.
       Support for APAR PQ28258 for SMF 103 record.
       Support for unix PerfMeter Freeware Monitor records.
       Support for DFSMS/MVS V1R5 - in place, no changes.
       Support for CA VIEW Metrics SARSMFUX SMF record.
       Support for SQL*NET NIV adds IPADDR/PORTNR to ORACLE.
       Enhanced TYPE1032 Web Server eliminates negatives.
       Negative QXSELECT because DB2 overflowed counter!
       CECSER wrong if CPUs added or deleted during interval.
       Utility to show IMACWORK definitions CPU sources.
       TYPE90A replaces TYPE90 member for SMF type 90 data.
       CICS Statistics EOD record has missing DURATM.

    Major enhancements added in MXG 17.07:

       Major IMS Enhancements for MXG IMS log processing.
       Support for Domino Server R5.0/R5.01 SMF type 108 record.
       Support for Top Secret 5.1 (INCOMPATIBLE).
       Support for TMON/MVS V2 PTF TD01655 (COMPAT).
       Support for MQ Series Version 2.1 (COMPATIBLE).
       Support for TeleView 4.3B subtype 3 record.
       Support for OS/400 Release 4.4.0 (LRECLs INCOMPAT)
       Support for Mobius View Direct 6.1.2 (INFOPAC).
       Support for APAR OW39508 7060 Multiprise EIO and DSD.
       Support for OS/390 R2.8 (COMPAT, changes were APARs).
       ASUM70PR now creates PDB.ASUMCEC BY CECSER vice BY SYSPLEX.

    Major enhancements added in MXG 17.06:

       Support for OS/390 R2.8 (Compatible, 16.09 or later supports).
       Support for Lotus Notes, SMTPDS, SMTPRS objects in NTSMF data.
       Y2K Ready: ASMTAPES must have been Assembled with ES6 parameter.

    Major enhancements added in MXG 17.05:

       Support for IBM's TPF (Transaction Processing Facility) OS.
       Support for APAR OW31701 for ESS Parallel Access Volumes.
       Support for OW39128 for RACF, adds DSNAME of PDS used for PROGRAM
       Support for STK's VTCS 2.2.0 (INCOMPATIBLE) VSM SMF records
       IBM's sample IXGRPT1 for SMF type 88 records is replicated.
       New PDB.ASUMCEC corrects errors in PDB.ASUM70PR, more useful.
       TYPETASK='OMVS' instead of TYPETASK='STC ' for OMVS/USS jobs.
       OMVS/USS jobs filled SPIN, never purged, now output to PDB.

    Major enhancements added in MXG 17.04 dated Jul 16, 1999:

       Correction for preliminary IMS Log Enhancements.

    Major enhancements added in MXG 17.04 dated Jul 16, 1999:

       Support for CICS TS 1.3 new field inserted in CICSTRAN, INCOMPAT!
         If you have CICS TS 1.3, you must install MXG 17.04 (or the one
         line Change 17.156) or many variables in CICSTRAN will be bad.
       Support for APAR OW37565 identifies CP or ICF CPUs in TYPE70PR.
       ICF CPUs are now detected and deleted automatically in ASUM70PR.
       Significant IMS Log processing enhancements available for test.
       Utility to examine dates in SAS data library for Y2K.
       Support for APAR OW37816, new 2105 cache data in TYPE74CA.
       Support for Connect Direct R 3.2 'CT' record.
       Support for MIM user record enhanced, new dataset.
       Support for RMM European or American Date formats.
       Support (preliminary) for NTSMF Windows 2000 Beta Three records.
       Enhanced RMFINTRV/VMXGRMFI permits over 100 workloads now works.

    Major enhancements added in MXG 17.03:

       Support for Type 42 subtypes 7/8 NFS Usage/Users.
       Support for APAR OW37091 Measured Usage SMF 89 changes.
       Support for SoftAudit Version 7.1 (COMPATIBLE).
       Support for STK's NearOAM V2.2 (COMPATIBLE).
       Support for 32 (up from 16) sortworks for SYNCSORT.
       Support for OS/400 V4.3.0, no change, is in MXG 16.16.
       BUILDPDB vars TAPEDRVS/TAPE3480/etc corrected for MULTIDD='Y'.
       BUILDPDB vars EXCPNODD/IOTMNODD now corrected for MULTIDD='Y'.
       Enhancement for PDB.ASUMTAPE obs with STATUS=MISSEDMNT.


    Major enhancements added in MXG 17.02:

       Support for DB2 type 102 subtype 199, Dataset I/O.
       Support for Lexmark MarkVision Job Statistics
       Support for CICS TS 1.2 Journal segment GLRHTYPE=2, used by SAP.
       Support for SOFTAUDIT 6.1.2 (COMPATIBLE).
       Support for TELEVIEW 4.3 (INCOMPATIBLE).
       Support for RACAL IT Security's SRM product for HSM.
       Support for i-data afp-software's SMF record.
       Support for NTSMF 2.3 (COMPAT), 21 new NT objects added.
       Enhanced RMFINTRV/VMXGRMFI permits over 100 workloads. See 17.04.
       RACF command keywords specified/ignored now decoded in TYPE80A.

    Major enhancements added in MXG 17.01:

       Support for DB2 type 102 subtype 199, Dataset I/O.
       Support for Index Statistics in T102S022.
       Support for deaccumulation of TYPE30_6 data.
       Support for APAR OW37708/APAR OW38073 new fields.
       Support for APAR OW15406 (IODF Creation now YYYY).
       Support for "FICON" channels adds fields compatibly.
       Support for Candle V400 Omegamon for CICS Epilog.
       Support for IXFP/ICEBERG Subtype 8 and fix for subtype 6.
       Support for NTSMF new Quota Server object.
       Support for TANDEM F40, G04 and G05 INCOMPATIBLE.
       Changing Interval with DURSET didn't change ASUM70PR.
       Don't use PDB.TYPETMNT. USE PDB.ASUMTAPE for mounts.
       ML-19 of ASMTAPES suppresses TMNT005E messages.
       TYPEIMSA processing is wrong in 16.16.  Use 17.08.
       STC SILO SMF record sometimes short.
       Unexpected TCP/IP command of STOU protected.
       TMS Julian dates printed as 2E6, format now 7.
       Revised and documented utility to modify BUILDPDB.
       Text in col 72 cause unexpected failure.

  All of these enhancements are described in the Change Log, below.

    Availability dates for the IBM products and MXG version required:

                                       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 15, 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 30, 1996        14.05
      OS/390  1.3.0 Compatibility Mode Mar 28, 1997        14.14
      OS/390  1.3.0 WLM Goal Mode      Mar 28, 1997        15.02
      OS/390  2.4.0                    Sep 28, 1997        15.06
      OS/390  2.5.0                    Feb 24, 1998        15.06
      OS/390  2.6.0                    Sep 24, 1998        16.04
      OS/390  2.7.0                    Mar 26, 1999        16.09
      OS/390  2.8.0                    Aug 24, 1999        16.09
      OS/390  2.8.0 FICON/PAV/SHARK    Aug 24, 1999        17.08
      OS/390  2.9.0                    Mar 31, 2000        17.17
      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 aka CICS/TS V1R1    Sep 10, 1996        14.07
      CICS-Transaction Server V1R1     Sep 10, 1996        14.07
      CICS-TS V1R1 with APAR UN98309   Sep 15, 1997        15.06
      CICS-TS V1R2  CICS/TS 1.2        Oct 27, 1997        15.06
      CICS-TS V1R3  CICS/TS 1.3        Mar 15, 1999        17.04
      CRR 1.6                          Jun 24, 1994        12.02
      CRR 1.7                          Apr 25, 1996        14.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           Sep 11, 1996        14.07
      DB2 5.1.0 Tolerate               Jun 27, 1997        14.14
      DB2 5.1.0 Full support           Jun 27, 1997        15.02
      DB2 6.1.0                        Mar 15, 1999        16.09
      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
      DFSMS/MVS 1.4                    Sep 28, 1997        15.04
      DFSMS/MVS 1.4 HSM                Sep 23, 1998        16.04
      DFSMS/MVS 1.5                    ??? ??, 1999        16.04
      MQM 1.1.2, 1.1.3, 1.1.4          Apr 25, 1996        14.02
      MQ Series 1.2.0                  May 26, 1998        16.02
      MQ Series 2.1.0                  Oct  2, 1999        17.07
      NETVIEW 3.1 type 37              ??? ??, 1996        14.03
      NPM 2.0                          Dec 17, 1993        12.03
      NPM 2.2                          Aug 29, 1994        12.05
      NPM 2.3                          ??? ??, 1996        15.08
      NPM 2.4                          Nov 18, 1998        17.01
      RMDS 2.1, 2.2                    Dec 12, 1995        12.12
      TCP/IP 3.1                       Jun 12, 1995        12.12
      TCP/IP 3.4                       Sep 22, 1998        16.04
      DOS/VSE POWER V6.3.0             Dec 19, 1998        16.08
      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
      VM/ESA  2.3                      ??? ??, ????        16.08
      IMS     4.1                      Aug  6, 1994        12.02
      IMS     5.1                      Jun  9, 1996        14.05
      IMS     6.1                      ???  ?, 199?        16.04
      AS400 3.7.0                      Nov  1, 1996        15.01
      AS400 4.1.0                      Dec 30, 1996        15.08
      AS400 4.2.0                      Apr 27, 1998        16.02
      AS400 4.4.0                      Sep 27, 1999        17.07

    Availability dates for non-IBM products and MXG version required:

                                                        MXG Version
      Product Name                                       Required

      Microsoft
       Windows NT 4.0 and NT 3.51                          14.14
       Windows NT 4.0 Service Pack 2                       15.03
       Windows NT 4.0 Service Pack 5                       16.04
      Demand Technology
       NTSMF Version 1 Beta                                14.11
       NTSMF Version 2.0                                   15.05
       NTSMF Version 2.1                                   15.06
       NTSMF Version 2.2                                   16.04

      Landmark
       The Monitor for DB2 Version 2                       13.06
       The Monitor for DB2 Version 3.0                     16.02
       The Monitor for DB2 Version 3.1                     16.02
       The Monitor for CICS/ESA 1.2 -                      12.12
       The Monitor for CICS/ESA 1.3 -                      15.01
       The Monitor for CICS/ESA 2.0 -                      15.06
       The Monitor for MVS/ESA 1.3  -                      12.05
       The Monitor for MVS/ESA 1.5  -                      12.05
       The Monitor for MVS/ESA 2.0  -                      15.09

      Candle
       Omegamon for CICS V200 User SMF                     12.05
       Omegamon for CICS V300 User SMF                     13.06
       Omegamon for CICS V400 User SMF                     16.02
       Omegamon for CICS V400 type 110 segments            16.02
       Omegamon for IMS V110 (ITRF)                        12.12
       Omegamon for IMS V300 (ITRF)                        14.04
       Omegamon for MVS V300                               13.05
       Omegamon for MVS V400                               13.06
       Omegamon for DB2 Version 2.1/2.2                    13.05
       Omegamon for VTAM V160                              12.04A
       Omegamon for VTAM V400                              15.15
       Omegamon for SMS V100/V110                          12.03
      CA
       ACF2 6.2                                            16.04
       ASTEX 2.1                                           14.04
       NETSPY 4.7                                          14.03
       NETSPY 5.0                                          14.03
       NETSPY 5.2                                          16.05
      Boole & Babbage
       IMF 3.1 (for IMS 5.1)                               12.12
       IMF 3.2 (for IMS 6.1 only)                          15.09
       IMF 3.2 (for IMS 5.1 and 6.1)                       16.04
      Memorex/Telex
       LMS 3.1                                             12.12A
      MXG IMS-Log Not-Officially-Supported
       IMS 6.1  -   ASMIMSL6/TYPEIMSA                      17.08
       IMS 5.1  -   ASMIMSL5/TYPEIMSA                      17.08
      Amdahl
       APAF 4.1, 4.3                                       16.08

II.  MXG Technical Notes

 1. Compatibility issue.  TYPExxxx members may need //PDB or %LET.
    Some TYPExxxx members data must be deaccumulated to be valid:
      SMF records:      TYPE103   TYPE28   TYPEDB2  TYPEHMF  TYPEHSM
                        TYPENTCP TYPEROSC  TYPETPX
      Non-SMF record:   TYPETMDB
    MXG adds %INCLUDE SOURCLIB(DIFxxxx) to those TYPExxxx members to do
    the deaccumulation; the DIF's used to output to the //WORK DDNAME
    but DIF() members now sort their output to the MXG default DDNAME
    of //PDB.  So if you use  %INCLUDE SOURCLIB(TYPExxxx) in your jobs
    you may need to add a DDNAME of //PDB plus a PROC COPY, or you may
    want to use the new %LET Pdddddd=WORK syntax to change that "PDB"
    back to the "WORK" that your old job expects.
    Note: this does not apply if you use BUILDPDB to create the data).

     - You can add a //PDB DD pointing to a temporary dataset and then
       add a PROC COPY after the %INCLUDE of the TYPExxxx member:


           //PDB DD DSN=Temp,UNIT=SYSDA,SPACE=(CYL,(xxx,yyy))
           //SYSIN DD *
             %INCLUDE SOURCLIB(TYPExxxx);
             PROC COPY IN=PDB OUT=WORK;
             ... Your SAS code ....

       to create in the //PDB and then copy them back into //WORK for
       your old program to find.

     - Or, you can change the Pdddddd macro for the dataset;

           //SYSIN DD *
             %LET Pdddddd=WORK;
             %INCLUDE SOURCLIB(TYPExxxx);
             ... Your SAS code ....

       The "Pdddddd" name for each dataset is documented in the IMACxxxx
       member.  The default is usually "PDB", except for these datasets:

         Product      Default Destination    For Dataset
                      Pdddddd=DDname         Named

         CICS 110 -   PCICTRN=CICSTRAN       CICSTRAN
         IMS log  -   PIMSTRN=IMSTRAN        IMSTRAN
                      PIMSxxx=WORK           All IMS Temporary datasets
         HP MW    -   HPxxxx =HPPDB          All HPxxxxxx

 2. Recent hardware timing measurements for moving files:

    Path connection:                 MB/sec  MB/min  MB/Hr   GB/Hr

    Internet @56Kbit Dial In           .016     1       50     .048
    Internet T3                        .100     6      360     .351
    MVS to 10Mbit Lan                  .166    10     1000     .976
    PC-to-PC 100Mbit Lan              3.3     200    12150   11.8
    Pc-to-PC Disk-to-Disk Fast IDE    6.0     360    21600   21.1

      A 56Kbit connection can move a maximum of 19 MegaBytes
      per hour at 100% utilization and no overhead, so how
      can we move 50 MB per hour?  Compression in the modems.
      The SMF data compresses to between 8 to 1 and 10 to 1,
      so the 50 MB MVS file is only 5 MB of compressed data
      which can be delivered across a 56Kbit dial-up line.

 3. An example of the use of IMACFILE/MACFILE exit:

    Your site can choose to write the CADI record as SMF type 6 or as a
    user SMF record number.  Member TYPE6 (included by BUILDPDB) reads
    the type 6, but if your site chose to write, for example, type 239,
    you will need to use the IMACFILE exit (which is taken after the
    SMF header has been read, but before the decoding of the record) to
    change ID=239 to ID=6.  You would insert in member IMACFILE:
        IF ID=239 THEN ID=6;
    and MXG will process your type 239 record with the type 6 logic.
    Alternatively, you could use the %LET MACFILE macro variable syntax:
       %LET MACFILE= %QUOTE(  IF ID=239 THEN ID=6; ) ;
    to change the record ID in your //SYSIN stream.  See DOCMXG.

 4. Make sure your MVS REGION size is 64M, or you may get many strange
    SAS errors, especially when executing a %MACRO.  For example, using
    %BLDNTPDB with a region of only 6MB produced syntax errors "CURRENT
    WORD HAS BECOME MORE THAN 200 CHARACTERS LONG" that was not a true
    syntax error when SAS had enough memory.  Put the REGION=64M on your
    JOB card, so it will apply to all steps. The REGION= on the EXEC has
    effect only when there is no REGION specified on the JOB card.

    Why 64M?  The MXG Default MEMSIZE=64M is specified in CONFIG member
    and restricts SAS, so using the same REGION=64M makes sense, and I
    don't regard region size as a consumable resource.  MXG programs run
    in less than 48M, but if you tailor BUILDPDB for additional records,
    buffering for the additional output datasets requires more virtual
    storage, so MEMSIZE was raised to 64M a few versions ago for safety.
    One site that unwisely read both SMF and Landmark CICS data from two
    input files in a single data step needed 101MB of virtual space!

 5. MXG Definitions with regard to MXG Software Changes:

    COMPATIBLE   A change in a data record which did not alter either
                 the location or the format of all of the previously-
                 kept MXG variables is COMPATIBLE, and you can continue
                 to run the old version of MXG software, which will read
                 the new records without error, but none of any new data
                 fields or any new record subtypes will be created/kept
                 until you install the MXG Version with this change.
                 A change that alters any previously-kept variable is
                 INCOMPATIBLE, and requires the new version to be used.

    TOLERATE     In other words, the old MXG Version TOLERATES the new
                 data records, if they are COMPATIBLY changed.

    EXPLOIT      Once you use the new MXG Version to read the changed
                 records, all of the new fields, subtypes, etc, that are
                 described in this change will be created in the MXG
                 datasets, so the new MXG Version EXPLOITS the new data,
                 and you have full support of the new data records.

    INCOMPAT     A change in a data record that causes the current MXG
                 version to fail, visibly or invisibly, with or without
                 error conditions or messages, and the output datasets
                 may contain wrong values and incomplete observations,
                 and/or observations may have been lost.

                 You MUST install the new MXG Version with this change
                 to process data records that have been INCOMPATIBLY
                 changed by their vendor.

III. MVS Technical Notes.

  1. Some MXG typos in APAR names/numbers in NEWSLTRS or CHANGESS:
     PW13647 is PQ13647, PW18797 is PQ18797, PW61950 is PN61950, and
     PW56441 is PN56441.  All are now corrected.

  2. APAR OW36535 corrects Start/Stop timestamps in type 42 subtype 6
     (TYPE42DS) records.  There is now a PTF available.  This problem
     had been previously reported in OW10694 and OW25265.

  3. Problems with ECSA creep are documented in APAR OW34249, and there
     is another APAR, OW29277 (included in JES 2.7/HJE6607) that may be
     involved in dangling ECSA storage.

  4. The CA-SPOOL product APAR GS98190 (dated 1996) prevents that
     product from writing invalid type 6 SMF records with TYPETASK='FI'
     and invalid data in most other TYPE6 fields.

  5. How many volumes can you have in multi-volume MVS datasets?

     A recent note by IBMer Arliss White explains:

     PDS, PDSE and HFS data sets are limited to one volume.

     Extended format data sets with multiple stripes are limited to
     sixteen volumes.

     A data set on a VIO simulated device is limited to 65,535 tracks
     on one volume.

     All other DASD data sets are limited to 59 volumes.

     Tape data sets are limited to 255 volumes.

     For SMS-managed and non-SMS-managed data sets, you can specify
     up to 59 volume serial numbers.  If the combined number of
     volumes for a cluster and its associated alternate indexes
     Exceed 59, unpredictable results can occur.

     SAS Version 6 has a limit of five volumes for a data library on
     DASD, but SAS Version 7/8 eliminates that constraint.

  6. How does software compression compare with hardware compression for
     MXG's DB2ACCT dataset?  On OS/390 R2.5, a 55 MB SMF file with only
     DB2 records was read to create the twelve DB2xxxxx datasets.  The
     DB2ACCT output was 55MB, and occupied 1110 tracks uncompressed.
     Compressing with SAS Software reduced DB2ACCT to 600 tracks.
     Hardware compression using extended-format striped tape-format
     dataset on ESCON reduced DB2ACCT to only 480 tracks.  On older ECL
     machines, the CPU cost of hardware compression is significantly
     higher than software, but the 70 MIPS-per-engine CMOS processor
     shows no difference between the CPU cost of software or hardware
     compression.  Compressing costs 5 minutes of CPU time per Gigabyte
     written, added to a base cost of 11 minutes of CPU time per
     Gigabyte written uncompressed:

                             ---MVS CPUTM to Create All DB2 Datasets---
                             --------but compress only DB2ACCT---------
       System       Machine  Standard  Striped   SAS Software  Hardware
                    SU_SEC    Create   Uncompr    Compress     Compress
       ECL           2429      32.3     36.6       46.2          55.2
       CMOS SAS V6   2812      24.6     28.9       36.2          35.7
       CMOS SAS V7   2812      28.7     40.8       40.6          41.1

           As a tape-format striped dataset under V6, the dataset size
           jumped up to 1800 tracks, because V6 forced a space wasting
           DASD block size of 32760, but V7 required only 960 tracks: it
           knows about the extended-format datasets and uses half track
           to save space.  It is 960 rather than 1100 because there's no
           directory in a tape-format SAS dataset.

     The same 55MB SMF input file was read under Windows 98 with both V6
     and SAS V7 on a 166MHz Pentium and a 500MHz Pentium III with fast
     IDE drives, and under Windows NT 4.0 Server on a dual 2x200MHZ
     Pentium with SCSI drives.  On the 500MHz machine, creating all DB2
     datasets compressed on the PC took the same time, about 40 seconds,
     as it took that 70 MIPS mainframe to create eleven and compress
     only the DB2ACCT!  And on all of the PC machines, there is no CPU
     cost to compress data; it takes slightly less time to compress than
     to create non-compressed!  The savings of CPU time to move less
     data is greater than the cost of CPU time to compress, on PCs:
                                 ---Elapsed time of Data Step---
       System                    Standard           SAS Software
                                  Create             Compress

       166MHZ PENT II V6:         113.8               115.0
       2x200MHz Dual Pent:         54.7                48.7
       500MHZ PENT III V6:         42.4                40.2
       500MHZ PENT III V7:         43.0                41.6

     All twelve DB2 datasets were 84MB uncompressed, and their total was
     58MB when compressed. The uncompressed DB2ACCT data set (the 1100
     track dataset that SAS compressed to 600 tracks) was 55MB on the PC
     and compressed to 32MB, (about 620 tracks), so MVS and PC software
     compression effectiveness are very similar, although MVS hardware
     compression is more effective at no additional cost on MVS.

     The Dual Pentium time of 48 seconds on the 2x200 compared with 41
     on the 1x500 shows that SAS can exploit multiple engines, although
     some of the reduction may also be due to the faster SCSI drives.
     Here, under NT Server, which separately measures the CPU time, the
     processor time increased from 35 seconds to 42 seconds when
     compression was enabled, but the run time was still much less due
     to the reduced volume of data moved when it is compressed.

     In summary: This paragraph revised to quantify the CPU cost on MVS:

     On dedicated PCs, it is significantly faster (less CPU time too) to
     create compressed datasets than to create uncompressed datasets.

     On "MVS", the CPU cost of compression with either hardware or with
     SAS Software is about the same on (newer) CMOS hardware, but that
     increase is about 40%, which some might regard as expensive, but
     may be only a modest cost when it prevents a job to fail due to
     insufficient disk space.
       Note added Apr 2004:  One site's BUILDPDB increased from 266 to
       477 CPU seconds (79% increase, or 3.5 extra CPU minutes per day),
       but BUILDPDB does lots of compress/decompress/sort/compress/etc.
       which would increase the amount of CPU time.

  7. How do you hardware compress a SAS dataset on OS/390 mainframes?

     You can not use OS/390 hardware compression for a SAS data library,
     but you can hardware compress individual SAS datasets, by creating
     each as a SAS-tape-format, OS/390-extended-format, striped dataset,
     i.e. as a z/OS, extended-format, compressed, striped dataset:

     - To create the dataset in "Tape" format, either write to a DD name
       that starts with "TAPE", or use a LIBNAME statement to set the
       write engine to "TAPE":
          LIBNAME DB2ACCT TAPE;
     - The dataset that is pointed to by the //DB2ACCT DD statement in
       JCL, must create that dataset in a DATACLAS that has specified
          EXTENDED ADDRESABILITY = YES (or MAY)
          COMPACTION = YES
     - You must also put the dataset in a STORCLAS that specifies
          SUSTAINED DATA RATE = 4  (to get one stripe, 8 for two...)

     And note that this one SAS dataset, now a sequential dataset can be
     written to multiple DASD volumes (although it cannot be used for
     Direct Reads - SAS datasets in tape format are read sequential).

  8. APAR OW38615 for RACF type 80 records corrects PERMIT DATASET
     record, which can have an invalid resource name.

  9. APAR OW37742 for Workload Manager "Goal Mode" revises the logic of
     the "small consumer" algorithm to limit the duration when lower
     importance work in a system from preempting higher importance work.

 10. APAR AR38393 for Hardware Compression will now bypass decompression
     and compression when copying a compressed VSAM file to a device
     with same physical attributes.  It was supposed to bypass when it
     could, but the code did not work as advertised.

 11. APAR OW39277 for VSAM record statistics in LISTCAT wrong when using
     "dataset name sharing" with multiple opens to a VSAM dataset under
     some conditions discussed in the APAR text.  The mismatch between
     the LISTCAT and actual number of records in the file could also be
     the result of an abnormal close, and the APAR recommends looking at
     the type 64 records to determine if this APAR would fix the error.

 12. LOTUS Domino may need a 2GB region, and may not perform well if the
     site's IEFUSI exit changes the region size for the FORKed/SPAWNed
     address spaces.  See APAR OW38477 for discussion of why MAXASSIZE
     should be used instead of the IEFUSI exit.

 13. APAR OW37709 discusses new BMF cache options, for PDSE and HFS,
     that can be used to manage the size of the BMF data space cache.
     That APAR notes these options are intended for heavy users of BMF
     caching, "such as LOTUS Domino servers experiencing BMF data space
     storage shortage when running high activity mail databases for 5000
     or more users".  TYPE42 fields added by OW37708 to capture active
     and max BMF buffers were supported by Change 17.059 (MXG 17.01).

 14. For the new Shark/Parallel Access Volume hardware, a set of APARs
     have been recently released, and the list below shows the most
     recent first, and its previous (and prereq'd) APAR next:
     OW39393-->OW35586-->OW37816-->OW37565-->OW39086-->OW38346/OW37254.
     Support is in MXG 17.05.

 15. If you run the IFASMFDP "SMFDUMP" program with //SYSPRINT pointing
     to a disk dataset (rather than SYSOUT), you run the risk of losing
     SMF data if you ever take an I/O error to SYSPRINT, as discussed in
     this new APAR without a fix, OW40176.

 16. Deleted.  Was incorrect; error was in ASUM70PR.

 17. A reminder: VSAM Catalogs will stop functioning on 1/1/2000. Any
     existing VSAM Catalogs must be converted to ICF Catalogs by then!

 18. APAR OW32140 for WLM and CICS Reduces IRASASRV sampling rate if
     there are no Server Address Spaces, i.e., where CICS transactions
     are not being classified by WLM.

 19. APAR PQ25641 for SmartBatch Release 1 or Release 2 BatchPipePlex
     Cross System Piping with EOFREQUIRED=Y, reports that blocks of data
     can be lost, and there is no error nor ABEND message generated.

        It is possible to detect the loss of data records by comparing
        the input block count in the reading job's ASFP391I message in
        its job log with the output block count in the writing job's
        ASFP392I message in its job log.
        The type 91 SMF record contains input and output block counts
        for SmartBatch, and we are going to see if we can write an MXG
        utility to detect if data was lost.  17Sep1999.

 20. APAR PQ30654 for TCP/IP reports that FTP SMF records can have their
     FTPEND earlier than FTPSTART for transmissions that span midnight.
     There is no correction in this APAR (i.e., IBM should have added
     two date fields, one for start and one for end, so there would be
     no ambiguity (and the data would be valid if an FTP transmission
     crossed more than one midnight!), but they didn't!).

 21. APAR OW37263 is required to populate the ACCOUNTn Accounting
     Fields in type 30 records for OpenEdition tasks that were spawned.

 22. APAR OW39746 corrected problems with TYPE74CF Coupling Facility
     CPU busy time exceeding duration of the interval.  The problem
     is related to reconfiguration and goes away when all of the systems
     in the parallel sysplex get IPL'd again.

 23. APAR OW41239 corrects the value of mounted duration in OAM SMF
     type 85 subtype 87 records.

 24. APAR OW41169 corrects several SHARK problems, including capturing
     SMF type 42 subtype 6 activity counts for PAV alias exposures.

 25. APAR OW38842 causes the OMVS/USS field SMF30EXN, TYPE30_4 variable
     OMVSEXNP, the OMVS Executed Program Name, to be blank.
     APAR OW41696 says that APAR OW41764 corrects the error.

 26. APAR PQ32322 reports TCP/IP API SMF records have FFFFFFFFx for byte
     count, (-1 if input with IB4., but MXG stores 4,294,967,295, using
     PIB4. informat, since negative value is invalid!).  The APAR also
     says the records with these values are an extra TERM record that
     did not have an associated INIT record.  The APAR also reports that
     the fix, when available, will also eliminate duplicate records!

 27. APAR OW42559 reports variable UCCOLDT in DCOLLECT dataset DCOLCAPD,
     and DCOLCAPD records being lost.  The UCCOLDT value is 1900dddF
     instead of either 0100dddF which was documented or 2000dddF which
     is not expected (but either 0100dddF or 2000dddF raw values will
     be correctly handled by MXG when IBM issues a PTF to fix the error.

 28. MXG required for OS/390 R2.8 was originally listed as MXG 16.16,
     but there are a number of subsequent APARS for SHARK/PAV/FICON that
     changed RMF records (incompatibly for FICON channel measurements);
     those APARs now require MXG 17.08 or later.

 29. To know the size of Hipervolumes on EMC boxes, DCOLLECT dataset
     DCOLVOLS variable DCVVLCAP shows the actual capacity of each of
     your DASD volumes in megabytes.


IV.  DB2 Technical Notes.

  1. Excess DB2 SMF type 101 records due to Query CP parallelism can be
     prevented (now) only by RLF Parallel Mode Disablement, with RLFFUNC
     and RLFBIND.  Previous APARS provided disablement for dynamic plans
     and now DB2 APAR PQ06968 extends disablement to static plans also.

  2. But the real solution to excess DB2 type 101 records is available
     with the PTF UQ24763 for APAR PQ10864.  This APAR implements a V5
     dcr which rolls up all child task accounting data into a single
     record that is written with the parent task at deallocation time,
     and that record should be handled by MXG without difficulty, but
     I have not yet seen test data records.  Only ANALDB2P might be
     impacted, as it used the child records in analysis of parallelism.

  3. APAR PQ27561 corrects a large increase in QTXACLUN (claim failures)
     after migration to DB2 5.1.  The APAR corrects the counts and has a
     discussion of what was wrongly counted.

  4. The Sunrise product can corrupt the timestamps in DB2 101 and 102
     SMF records.  For Sunrise 4.11 their fix is sd11024, for Sunrise
     4.10 their fix was sd10231.

V.   IMS Technical Notes.
  There are no IMS notes in this Newsletter.

VI.  SAS Technical Notes.

  1. SAS 6.09 at TS460 contains maintenance to support UCB's above the
     line, and using it instead of TS450 has corrected 0C4 ABENDS.  The
     SAS Log stopped at the "Welcome to MXG" message.

  2. SAS Version 7 under MVS and OS/390 fails with ABEND 913-1C if you
     read Shared Multi-Volume DASD SAS Data Libraries.  Daily jobs that
     ran at the same time and that read the same SAS library under V6
     now ABEND under V7 when they try to open the same SAS data library.
        But only if the "PDB" or SAS Data Library is Multi-Volume and is
        on DASD.  Single-volume DASD data libraries have no error, and
        multi-volume SAS tape data libraries cannot be shared!
     The error is fixed in Version 8 and SAS is developing a ZAP for V7
     to fix the problem: see SAS Usage Note V7-SYS.SASIO-0704.
     You can circumvent the error by changing the JCL to use DISP=OLD on
     each DD statement, because that forces MVS to serialize the jobs so
     that only one job runs at a time.  But a 10-minute elapsed parallel
     job stream could become a long elapsed time when serialized.

  3. SAS Version 7 will cause SYSMSG notes that OPTIONS CODEPCT and
     BLKSIZE(TAPE)=FULL are not supported in this version, but those
     changes do not affect the execution of MXG Software, nor do they
     set any condition codes.  If I can get rid of them easily without
     you doing anything, I will, but for now they are harmless.

  4. SAS Error Unknown Exception (80000602), a severe error occurred in
     task SQL for module SABXSHL executing in SABXSHL ... was eliminated
     by the user deleting his SAS PROFILE catalog from SASUSER!

  5. SAS 609 maintenance TS460 introduced a message that can be ignored:
     WARNING:  This is an experimental version which will be replaced
               by XX AMS in Version 7.
     SAS Usage Note V6-SERVER-F759 explains the note, which was removed
     in SAS TS465, but it causes no problem and can be ignored.

  6. Using SMS "Immediate Release" for a SAS Data Library can cause SAS
     to USER ABEND 315, so don't do that.  See SAS Usage Note 2705.
     Incorrect multi-volume allocation can also cause 315 ABENDs; see
     other mentions of 315 in member NEWSLTRS.


  7. SAS V7 ZAP http:/www.sas.com/service/techsup/unotes/V7/0281.html is
     a required zap that also allows SAS data library allocations on MVS
     to exceed 32,767 tracks.  However, a SAS data library allocation is
     still limited to 65,536 tracks (4369 cylinders @15trk/cyl) on one
     volume, in Version 6, 7 and 8.  SAS V7 and V8 also allow more than
     5 volumes in a multi-volume SAS data library.

  8. SAS V7 errors a PROC SORT with DUPLICATE SORT KEY VARIABLE if the
     same name appears twice in the BY statement (due to some problems
     in some host sort programs).  MXG had two unintentional instances
     where SMFTIME was repeated that were removed in 17.04 so MXG would
     execute under V7.  But now SAS V8 does not error, and instead
     prints only a warning message, and then removes the repeated
     variable internally before calling the sort.  And for both V7 and
     V8, the restriction is only for a BY statement with a PROC SORT;
     use with other PROCs is not restricted.

  9. New SAS format/informats for IBM date formats added in V7 and V8:
      PDJULIw.   Reads/Writes Packed Decimal Julian Dates ccyydddF
     New SAS function
      JULDATE7() Returns 7 digit Julian date from a SAS date value,
                 in yyyyddd format, which could then be written to an
                 external file with hex format yyydddC by using:
                    juldate=JULDATE7(sasdate);  put juldate PD4. ;
     Unfortunately, MXG cannot exploit these new features, because I
     can't depend on you having the new SAS version installed, so MXG
     already protects these formats as described in member YEAR2000.

 10. SAS V8 Developer's Release for Windows fails with I/O error when it
     reads a VBS file that contains '1A'x (which Windows erroneously saw
     as a CTRL-Z, which is a Windows End-of-File marker).  The problem
     has been fixed for the V8 Production Release for Windows and unix.
     There is a SAS patch for Windows and Windows NT available at:
       ftp://ftp.sas.com/techsup/download/blind/sashost.dll
     but SAS does not create external usage notes for test releases.
     There is no unix patch because no unix site has reported the error.

     MXG 17.06 was successfully QA'd under SAS V8 Developer's Release,
     with the above fix, and only these minor notes:
       - Trying to create the MXG Formats into a directory with existing
         FORMATS.SC2 file from an earlier version of SAS causes syntax
         errors around the "OTHER" operand.  Erase the old FORMATS.SC2.
       - V8 won't tolerate a LIBNAME to a nonexistent directory.
     Continued testing is planned, but it looks very good so far!

 11. SAS V8 Developer's Release for OS/390 has successfully executed the
     standard MXG BUILDPDB program and the MXG QA stream, with a few new
     warnings and some return code fours under investigation:
     BUILDPDB with 1.8GB SMF file (no CICS, no DB2, mostly 30s & RMF):
         Release   EXCPs   CPU Minutes    Elapsed Minutes
           V6      178K      26.23           49.48
           V8      155K      25.61           44.26
                    -13%      -2%             -11%

     However, SAS Institute has replicated an error that surfaced as an
     out-of-memory problem during compile of an MXG BUILDPDB program
     that used %LET MACKEEP= and %QUOTE( ) to pass a list of _CDExxxx
     old-style macros that expanded to over 60,000 lines of SAS inside
     the %QUOTE( ) function.  It would compile (accidentally?) if the
     list was reordered and made many-per-line instead of one-per-line!
     But this parsing error exists only inside a %QUOTE function with
     thousands of bytes of text, so it doesn't seem pervasive and it
     should be fixed by SAS Production Version 8 availability.

 12. This NOT an MXG Y2K issue, because MXG doesn't use any date literal
     values that are YY, and certainly not any before 1960, but it shows
     what happens when YEARCUTOFF is changed from 1900 to 1960 if you
     have any YY date literals in your own SAS programs, perhaps one to
     calculate your age in days, using:     AGE=TODAY()-'19APR41'D;

     If YEARCUTOFF=1900 you get the correct AGE=21353, but if you use
     the YEARCUTOFF=1960, you get an incorrect AGE=-15172 value!  This
     problem really only arises when the YY start date is earlier than
     the YEARCUTOFF value of 1960, so your kid's ages will be correct!

     MXG sets YEARCUTOFF=1960 so that any YY literals still in your MXG
     report programs will be protected for computer dates (i.e., after
     1960), but you really should use YYYY:  AGE=TODAY()-'19APR1941'D;
     so date durations will be calculated independent of YEARCUTOFF.

 13. USER ABEND 0318 is usually Multi-Volume related, although there are
     a list of other "opportunities" in member NEWSLTRS under "0318",
     and now another cause: specifying DSORG=DA on //CICSTRAN instead
     or DSORG=PS caused USER ABEND 0318 (the JCL was holdover from back
     when SAS Version 5 data libraries were DA,RECFM=U libraries).

 14. Format Libraries built with SAS V7/V8 cannot be used with SAS V6.
     The physical format of SAS data libraries (where format libraries
     are stored as type=catalog) was changed between V6 and V7.

 15. Under Windows NT, attempting to create the FORMATS catalog in a
     directory that contains a FORMATS.SC2 file that is Read Only will
     create SAS ERROR: USER DOES NOT HAVE APPROPRIATE AUTHORIZATION
     LEVEL FOR FILE LIBRARY.FORMATS.CATALOG.  Erase the existing .SC2
     file and recreate by running  %INCLUDE SOURCLIB(FORMATS);

 16. SAS Version 8.0 under Windows/Windows NT reads only the first file
     with concatenated files if the RECFM=S370VBS.  This error was fixed
     in SAS Version 8.0 TS M1, and this note was revised May 15, 2000.

 17. What level of MXG is needed for the SAS Version 8 Release (TS M0)?

     MXG 16.16 runs with SAS V8 (TS M0), with a note that SAS options
               CODEPCT and BLKSIZE(TAPE) no longer exist.

     MXG 17.01 provides new CONFIGV8 without those two options to
               remove the note on MVS, and new AUTOEXEC for the same
               purpose under ASCII SAS.  Change 17.073.

     MXG 17.07 exploits 32000-byte character variable length for the SQL
               text variable in TYPE102 (but only when under V8 and only
               if COMPRESS=YES was also specified).  Change 17.253.

     MXG 17.08 exploits the new INHERIT option of PROC MEANS in VMXGSUM
               to skip a data step now unneeded with V8.  Change 17.265.

     MXG 18.04 changes V8 default to SEQENGINE=V6SEQ.  Change 18.104.

 18. Variable Blocked files can be used on MVS for MXG's USERID.SOURCLIB
     and MXG.SOURCLIB, with some constraints.  First, all libraries in
     the //SOURCLIB concatenation must be all VB; SAS does not support
     mixing RECFM=VB and RECFM=FB files for //SOURCLIB (S013-64 ABEND),
     although all RECFM=VB or all RECFM=FB does work without error.
     But second, SAS does not support RECFM=VB in its //CONFIG file at
     all (S013-20 ABEND), even if all of the //CONFIG datasets are VB.
     Tracking 5203445 is open to request future design change in SAS.

VII. CICS Technical Notes.

 *** THIS ORIGINAL NOTE HAS BEEN REVISED AND UPDATED - SEE ADOCDB2 ****
 ***     DO NOT USE TXID   ***

 1. The CICS RCT parameter TOKENE=YES does not exist now in CICS/TS, as
    the CICS RDO replaced the RCT.  The new parameter is ACCOUNTREC:

       ACCOUNTREC(TXID)  - you DO NOT WANT, but may be your default!
       ACCOUNTREC(UOW)   - the same as TOKENE=YES, use for CICS TS 1.1.
       ACCOUNTREC(TASK)  - MXG/IBM Recommended, less detail than (UOW).

    Specify ACCOUNTREC(UOW) in the RDO to do what TOKENE=YES was doing,
    that is, to cause DB2 to create a DB2ACCT record for each CICS event
    and to send the LU 6.2 token to populate QWHCTOKN in the DB2 record,
    The DB2ACCT and CICSTRAN multiple observations can be matched and
    combined in a "Business Unit of Work" observation in PDB.ASUMUOW.

      Note that the "UOW" in ACCOUNTREC(UOW), should really be "UOWID",
      in my opinion, because the "UOW" option actually creates DB2ACCT
      records for each unique value of the 8-byte UOWID, including the
      sequence number at its end.  To CICS, a "unit of work" is only one
      recoverable unit, or one unique value of that 8-byte UOWID token.

      But in MXG, especially in MRO, a "UOW" has always been a business
      unit of work, the collection of multiple CICS task records from
      TORs, AORs, FORs, plus any DB2ACCT records, that have the same
      first 6-bytes of that 8-byte UOWID field, MXG variable UOWTIME,
      the arrival time of the business work unit.  We may get the LUNAME
      and TRANNAME of the work unit from the TOR task record, but get
      PROGRAM and resources from the AOR record to create PDB.ASUMUOW.
      So while reading about CICS internals, think of a "UOW" as a
      specific value of the 8-byte UOWID, but everywhere else in MXG,
      know that a "UOW" is a business unit of work, combining many CICS
      and DB2 UOWIDs into one unit of work.

    The "UOWID" level DB2ACCT records created with ACCOUNTREC(UOW) is
    the maximum detail available, and provides tracking of the sequence
    of times when elements of a Unit of Work passed from CICS to DB2 and
    back in the CICSTRAN and DB2ACCT datasets, but the UOWID level of
    detail is not needed in the DB2ACCT dataset for PDB.ASUMUOW, so you
    will likely use ACCOUNTREC(UOW) only if you need the detail level
    or are still on CICS TS 1.1.

    In CICS TS 1.2, IBM introduced their (recommended) ACCOUNTREC(TASK)
    option to reduce data volume on the DB2 side, as it causes DB2 to
    create the DB2ACCT observation only at the end of each CICS task,
    but it still populates the QWHCTOKN (because multiple DB2ACCT obs
    can still be created by thread release at intermediate syncpoints).
    Unless you really need the additional level of detail per UOWID,
    specify ACCOUNTREC(TASK) and PDB.ASUMUOW will be cheaper to create!

    Do not use ACCOUNTREC(TXID), equivalent to the RCT's TXIDSO=YES.
    Unfortunately, the MIGRATE function to create your RDO from your old
    RCT may set TXID as the default, so you need to check your RDO and
    change it to either TASK or UOW, because TXID causes QWHCTOKN to be
    blank, preventing DB2 match up with CICS.  Also, only one DB2ACCT
    record is created for multiple CICS transactions, with accumulated
    resources, when TXID is specified.

    What IBM calls a "multi unit of work transaction" is a just a series
    of CICS tasks with the same UOWTIME but different values of UOWID.
    Checkpoints, SYNC, Commits, etc, alter that sequence number.

    The actual MXG definition of a "Unit of Work" uses both the NETSNAME
    (the originator of the CICS transaction) and the UOWTIME to create
    observations in the PDB.ASUMUOW dataset.

 2. MXG 17.04 or later is required for CICS/TS 1.3 (or at least the
    Change 17.156 must be applied to MXG 16.16).

VIII. Windows NT Technical Notes.

   There are no Windows NT Technical Notes in this Newsletter.


IX.   Incompatibilities and Installation of MXG 17.17.

 1. Incompatibilities introduced in MXG 17.17 (since MXG 16.16):

  a- No changes in MXG architecture were made between 16.16 and 17.17
     that introduced incompatibilities.

 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.


X.    Online Documentation of MXG Software.

    MXG Documentation is now described in member DOCUMENT.


XI.   Changes Log

--------------------------Changes Log---------------------------------

 You MUST read each Change description to determine if a Change will
 impact your site. All changes have been made in this MXG Library.

 Member CHANGES always identifies the actual version and release of
 MXG Software that is contained in that library.

 The CHANGES selection on our homepage at http://www.MXG.com
 is always the most current information on MXG Software status,
 and is frequently updated.

 Important changes are also posted to the MXG-L ListServer, which is
 also described by a selection on the homepage.  Please subscribe.

 The actual code implementation of some changes in MXG SOURCLIB may be
 different than described in the change text (which might have printed
 only the critical part of the correction that need be made by users).

 Scan each source member named in any impacting change for any comments
 at the beginning of the member for additional documentation, since the
 documentation of new datasets, variables, validation status, and notes,
 are often found in comments in the source members.

Alphabetical list of important changes after MXG 16.16 now in MXG 17.17:

  Dataset/
  Member   Change    Description

  All      17.060  MXG Enhancement %LET &Wdddddd=ddname for //WORK copy.
  many     17.171  PRINTWAY JCTJOBID='PSnnnnnn' support in TYPETASK.
  many     17.214  Support for OS/390 R2.8 (COMPAT, changes were APARs.
  ADOCall  17.379  Revisions and updates with new variables in all ADOCs
  ANAL42   17.223  Report failed with more than one SYSTEM.
  ANAL88   17.185  IBM's sample IXGRPT1 for SMF type 88 replicated.
  ANAL91   17.243  Batch Pipes Analysis for APAR PQ25641.
  ANALCNCR 17.070  Concurrency analysis now tolerates missing values.
  ANALDATE 17.168  Utility to examine dates in SAS data library for Y2K.
  ANALDB2R 17.300  Field-width enhancement to DB2PM-like reports
  ANALDSET 17.240  MXG 17.03-17.06. DATA SET NOT FOUND corrected.
  ANALDSET 17.343  Revised to use MACKEEP instead of IEBUPDTE, NEXTENT.
  ANALDSOP 17.198  ANALDSET enhancements (42s, 30 interval, 62s, 6156).
  ANALNSPY 17.358  Added and corrected a replica of MICS SNTNSS report.
  ANALRMFR 17.160  All BY variables must be in first 4092 bytes.
  ANALRMFR 17.369  Several enhancements, this was just most recent.
  ASMDALO  17.061  The MXG DASD Allocation Monitor may 0C4.
  ASMIMSL5 17.064  0C4 if &DFSMS left at 0 (for DFP) in IMS 5.1.
  ASMIMSXx 17.172  Significant IMS Log processing enhancements for test.
  ASMIMSxx 17.228  Major IMS Enhancements for MXG IMS log processing.
  ASMIMSxx 17.315  Final IMS Revisions for all know negative values.
  ASMTAPES 17.046  ML-19 of ASMTAPES suppresses TMNT005E messages.
  ASUM70PR 17.045  Changing Interval with DURSET didn't change ASUM70PR.
  ASUM70PR 17.163  ICF CPUs are now detected and deleted automatically
  ASUM70PR 17.203  Dedicated CPU error fixed, use new PDB.ASUMCEC.
  ASUM70PR 17.232  PDB.ASUMCEC now created BY CECSER vice BY SYSPLEX.
  ASUM78CF 17.178  New ASUM78CF member summarizes PDB.TYPE78CF data.
  ASUMDB2A 17.170  DB2 5.1/6.1 new variables added to DB2ACCT summary.
  ASUMTALO 17.242  Lost output when multiple days are input is fixed.
  ASUMTALO 17.320  Last-complete-interval now corrected.
  ASUMTAPE 17.010  PDB.ASUMTAPE replacement for PDB.TYPETMNT.
  ASUMTAPE 17.041  Don't use PDB.TYPETMNT. USE PDB.ASUMTAPE for mounts.
  ASUMTAPE 17.106  PDB.ASUMTAPE with STATUS=MISSEDMNT handling revised.
  ASUMUOW  17.324  WTIRIOTM no longer sum of all IR waits in ASUMUOW.
  AUTOEXEC 17.392  Options S=72,S2=72 removed from AUTOEXEC and CONFIG.
  BUILDPDB 17.025  Adding/Dropping variables from PDB.JOBS/STEPS/PRINT.
  BUILDPDB 17.110  Vars EXCPNODD/IOTMNODD now corrected for MULTIDD='Y'.
  BUILDPDB 17.111  Vars TAPEDRVS/TAPE3480/etc corrected for MULTIDD='Y'.
  BUILDPDB 17.113  PDB.PRINT new variables SMF6PRMD and SMF6USID added.
  BUILDPDB 17.176  OMVS/USS jobs fill SPIN, never purge, now forced out.
  CICINTRV 17.391  CICINTRV dataset creation logic was wrong.
  CONFIGV7 17.073  Revised CONFIG for SAS V7 eliminates warning msgs.
  DOCMXG   17.051  Typos in MACKEEP= examples in documentation corrected
  EX80ASEG 17.247  New TYPE80A exit for Top Secret unique segments.
  EXPDBOUT 17.357  Example to add CICS Statistics datasets to your PDB.
  FORMATS  17.222  Support for APAR OW39508 7060 Multiprise EIO and DSD.
  IMACACCT 17.327  Order of code revised so &MACACCT now works.
  IMACEXCL 17.229  Omegamon Exclude logic needed SMFPSRVR test.
  IMACEXCL 17.356  CICS TS 1.3 Excluded Field example did not work.
  MXGSAS   17.317  ABEND 2415 due to no RECFM=U in //NULLPDS in SAS proc
  PRINTNL  17.381  Revised utility to print NEWSLTRS/CHANGESS members.
  RMFINTRV 17.238  Non-contiguous shift definitions now supported
  RMFINTRV 17.322  RMFINTRV now invokes VMXGRMFI, supports 115 workload
  RMFINTRV 17.360  RMFINTRV/VMXGRMFI enhancements fixed and documented.
  SPUNJOBS 17.311  DATASET CONDCODE NOT FOUND with old IMACPDB.
  TYPE102  17.006  Support for DB2 type 102 subtype 199, Dataset I/O.
  TYPE102  17.020  Typos.  _C012297 should have been _C102297.
  TYPE102  17.044  Typos.  _C102206 should have been _C102106.

  TYPE102  17.056  Support for Index Statistics in T102S022.
  TYPE103  17.270  Support for APAR PQ28258 for SMF 103 record.
  TYPE103  17.304  Enhanced TYPE1032 Web Server eliminates negatives.
  TYPE103  17.314  Deaccum of TYPE1032 for duplicate IPADDRESS.
  TYPE108  17.384  Support for Lotus Domino Server Release 5.02.
  TYPE110  17.096  Support for GLRHTYPE=2 CICS TS 1.2 Journal segment
  TYPE110  17.156  Support for CICS TS 1.3 new field (INCOMPATIBLE)!
  TYPE110  17.279  CICS Statistics EOD record has missing DURATM.
  TYPE115  17.248  Support for MQ Series Version 2.1 (COMPATIBLE).
  TYPE21   17.013  TYPE21/PDB.TAPES variable OPEN is always blank.
  TYPE28   17.018  NPM 2.4. Datasets NPMINSES/NPMEVSAL trashed.
  TYPE28   17.049  Zero obs in dataset NPMSEEND corrected.
  TYPE30   17.009  Support for deaccumulation of TYPE30_6 data.
  TYPE30   17.176  TYPETASK='OMVS' instead of TYPETASK='STC ' for USS.
  TYPE30   17.385  New foreign enclave times and TYPE30MR in OS/390 R29.
  TYPE42   17.042  Type 42 subtype 16 (SMF42Gxx) was out of alignment.
  TYPE42   17.059  Support for APAR OW37708/APAR OW38073 new fields.
  TYPE42   17.124  Support for Type 42 subtypes 7/8 NFS Usage/Users.
  TYPE42   17.278  Support for APAR OW40579/41407 SMF 42 subtype 4.
  TYPE42   17.355  Type 42 subtypes 7/8 NFS caused INVALID NF-CL TRIPLET
  TYPE50   17.007  Variables BSIZE and MXTRSIZE corrected in TYPE50.
  TYPE64   17.032  Extended Format datasets, HIGHRBA now calculated.
  TYPE7072 17.162  Support for APAR OW37565 identifies CP or ICF CPUs.
  TYPE7072 17.299  CECSER wrong if CPUs added or deleted during interval
  TYPE73   17.026  Support for APAR OW15406 (IODF Creation now YYYY).
  TYPE73   17.027  Support for "FICON" channels adds fields compatibly.
  TYPE73   17.286  PCHANBY/PNCHANBY wrong in initial FICON support.
  TYPE74   17.161  Support for APAR OW37816, new 2105 cache TYPE74CA.
  TYPE74   17.180  Support for APAR OW31701 ESS Parallel Access Volumes
  TYPE74   17.182  TYPE74OM (OMVS/USS) had several variables wrong.
  TYPE74   17.269  PCTPNCHA/PCTPNOTH/PCTDVPND/PCTPNDEV revisions.
  TYPE74   17.378  Broken Type 74.4 RMF caused INPUT STATEMENT EXCEEDED.
  TYPE74CF 17.211  Doc. XSYSn variable blank is most observations.
  TYPE79   17.023  CPU time for Pre-emptible SRBs added in TYPE79s.
  TYPE80A  17.012  RACF type 80 with optional RACFTYPE=7 had STOPOVER.
  TYPE80A  17.094  RACF keywords specified/ignored are now decoded.
  TYPE80A  17.158  Top Secret causes many SEGMENT SKIPPED messages.
  TYPE80A  17.199  Support for OW39128, PDS DSNAME for PROGRAM access.
  TYPE80A  17.218  Support for Top Secret Release 5.1 (INCOMPAT)
  TYPE89   17.116  Support for APAR OW37091 Measured Usage SMF 89 change
  TYPE90A  17.287  Replacement for TYPE90 member for SMF type 90 data.
  TYPE91   17.298  Batch Pipes IC/OC counts propagated into 12/13/15.
  TYPE94   17.213  Support for type 94 import/export statistics.
  TYPE94   17.245  ERROR.VMAC94.AUDITLEN INVALID error corrected.
  TYPE97   17.385  New in OS/390 Release 2.9
  TYPEBETA 17.368  Support for Beta91 Balancing Manager SMF record.
  TYPECIMS 17.303  IMF, MVIMF, CIMS:  SQLCALLS not counted, INCOMPAT.
  TYPEDB2  17.090  DB2STATS dataset some QXxxxxxx variables were wrong.
  TYPEDB2  17.338  BPHITRAT, Buffer Pool Hit Ratio, revised.
  TYPEDB2  17.382  DB2 TCB times QWACSPCP/QWACSPTT included in DB2TCBTM.
  TYPEDCOL 17.244  DCOLLECT variables DCACSIZ/DCACACIC were missing.
  TYPEDCOL 17.281  Support for DFSMS/MVS V1R5 - in place, no changes.
  TYPEDCOL 17.307  Support for APAR OW41147 ORGEXPDT=99999 Y2K Critical
  TYPEDCOL 17.347  Year 2000.  IBM APAR OW42559, UCCOLDT in DCOLCAPD.
  TYPEEDGR 17.016  Dataset EDGRDEXT has zero observations.
  TYPEEPIL 17.003  Support for Candle V400 Omegamon for CICS Epilog.
  TYPEEREP 17.339  INPUT STATEMENT EXCEEDED for EREP records.
  TYPEHSM  17.019  HSM _DIFFHSM macro relocated into VMACHSM.
  TYPEHSM  17.021  HSM Julian dates printed as 2E6, format now 7.
  TYPEICE  17.048  Support for IXFP/ICEBERG Subtype 8 and fix for st 6.
  TYPEICE  17.346  INVALID DATA FOR IOSSTIME, Iceberg IXFP subtype 8.
  TYPEIDAP 17.100  Support for i-data afp-software SMF record.
  TYPEIISL 17.321  Support for IIS Log.

  TYPEIMSA 17.011  TYPEIMSA processing is wrong in 16.16.  Use 17.08.
  TYPEIMSA 17.290  More IMS Log revisions correct negative RESPNSTM.
  TYPEIPAC 17.234  Support for Mobius View Direct 6.1.2 (INFOPAC).
  TYPEITRF 17.336  Variables IMSVERS,IMSRELEASE,SMBCLASS numeric now.
  TYPELDMS 17.371  Support for Software Innovation's LDMS product.
  TYPEMIM  17.152  Support for MIM user record enhanced, new dataset.
  TYPEMRKV 17.099  Support for Lexmark MarkVision Job Statistics
  TYPENDM  17.155  Support for Connect Direct R 3.2 'CT' record.
  TYPENOAM 17.122  Support for STK's NearOAM V2.2 (COMPATIBLE).
  TYPENSPY 17.154  Zero obs in NSPYTIC3 (again, due to Change 16.147).
  TYPENSPY 17.367  NETSPY NSPYAPPL dataset had missing response times.
  TYPENTSM 17.055  Support for NTSMF new Quota Server object.
  TYPENTSM 17.101  Support NTSMF Version 2.3 (COMPAT), 21 new objects.
  TYPENTSM 17.165  Protection for Win 2000 Beta 3. IIS, Web changes.
  TYPENTSM 17.209  Support for Lotus Notes, SMPTDS/SMTPRS objects.
  TYPENTSM 17.335  Support for Windows 2000 Build 2195 NTSMF data.
  TYPEORAC 17.308  Support for SQL*NET NIV adds IPADDR/PORTNR to ORACLE.
  TYPEPMTR 17.297  Support for unix PerfMeter Freeware Monitor records.
  TYPEQAPM 17.107  Support for OS/400 V4.3.0, no change, is in 16.16.
  TYPEQAPM 17.235  Support for OS/400 Release 4.4.0 (LRECLs INCOMPAT)
  TYPERACF 17.305  Support for RACF Unload IRRDBU00 Started Task subtype
  TYPESARR 17.306  Support for CA View Metrics SARSMFUX SMF record.
  TYPESARR 17.309  Support for remaining CA-VIEW Metrics validated.
  TYPESFTA 17.092  Support for SOFTAUDIT 6.1.2 (COMPATIBLE).
  TYPESFTA 17.123  Support for SoftAudit Version 7.1 (COMPATIBLE).
  TYPESRMH 17.085  Support for RACAL IT Security's SRM product for HSM.
  TYPESTC  17.040  STC SILO SMF record sometimes short.
  TYPESTC  17.195  Support for STK's VTCS 2.2.0 INCOMPATIBLE VSM SMF.
  TYPESTC  17.230  Variables STC07FPS/TPS now match STK utility report.
  TYPESTC  17.313  Variables STC11CI/CE/TOL were blank.
  TYPESYNC 17.145  SYNCSORT variables COREREQ/COREUSED now 8-byte store.
  TYPESYNC 17.199  Support for 32 (up from 16) sortworks for SYNCSORT.
  TYPESYNC 17.350  Flags CONTIGn,CACHFWn fixed, DYNALOn,UNOPENn added.
  TYPETAND 17.037  Support for TANDEM F40, G04 and G05 INCOMPATIBLE.
  TYPETAND 17.115  TANDEM G05 and later TANDDISK corrected.
  TYPETCP  17.034  Unexpected TCP/IP command of STOU protected.
  TYPETCP  17.349  TELNET LOGF Time field is Duration, not datetime!
  TYPETELE 17.091  Support for TELEVIEW 4.3 (INCOMPATIBLE).
  TYPETELE 17.246  Support for TeleView 4.3B subtype 3 record.
  TYPETMDB 17.280  Support for Landmark DB2 Monitor V 3.2 (INCOMPAT).
  TYPETMNT 17.216  ASMTAPES needed 'ES6' at ASM for Y2K, this protects.
  TYPETMO2 17.169  Landmark TARSPTM contains sum of all conversations.
  TYPETMS5 17.021  TMS Julian dates printed as 2E6, format now 7.
  TYPETMS5 17.151  Undocumented DENX='DE'x TMS records now supported.
  TYPETMS5 17.352  Year 2000.  Variable OUTDATE was still 0cyyddd.
  TYPETMV2 17.259  Support for TMON/MVS V2 PTF TD01655 (COMPAT).
  TYPETMV2 17.333  Support for additional Landmark TMVS subtypes.
  TYPETPF  17.200  Support for IBM's TPF Operating System records.
  TYPETPX  17.036  TPX Start Up record subtype 1 not properly decoded.
  TYPETRMS 17.284  Support for TRMS Version 51A08 (COMPATIBLE).
  TYPEUNIC 17.002  TYPEUNIC support for CA UniCenter is for Open VMS.
  TYPEZARA 17.344  Year 2000.  Support for ZARA Release 1.3 (INCOMPAT).
  UTANDSTR 17.241  Tandem Utility to read "Unstructured" with new LRECLs
  UTILBLDP 17.054  Revised and documented utility to modify BUILDPDB.
  UTILRMFI 17.271  UTILRMFI to show IMACWORK definitions CPU sources.
  VMAC102  17.253  DB2 trace SQL text variables use &SASCHRLN length.
  VMAC110  17.220  SMF type 110 subtype 0 JCRLL=0 error.
  VMAC28   17.018  NPM 2.4, NPMINSES/NPMEVSAL datasets trashed.
  VMAC80A  17.316  WARNING: BIT MASK TOO LONG corrected.
  VMACDB2  17.300  Negative QXSELECT because DB2 overflowed counter!
  VMACIMSA 17.011  MXG ASMIMSLG/L5/L6, STRTTIME is missing due to typo
  VMACIMSA 17.228  SAP IMS 'AE'x log record was NOT Y2K Ready.
  VMACTMDB 17.319  Landmark DB2 Version 3.0 INPUT STATEMENT EXCEEDED.

  VMXGINIT 17.250  MXGVERS specification removed from VMXGINIT.
  VMXGINIT 17.251  USER= option protected, &SASCHRLN= created
  VMXGRMFI 17.142  Enhanced RMFINTRV permits over 100 workloads.
  VMXGRMFI 17.388  Added DROPPGN=,DROPSRV= for easier RMFINTRV tailoring
  VMXGSUM  17.193  Dashed-variable-list now correctly supported.
  VMXGSUM  17.255  New stats, INHERIT exploitation under SAS V8.
  VMXGSUM  17.265  VMXGSUM revisions now implemented in MXG 17.08.
  VMXGVTOF 17.341  Year 2000. CREATED,EXPIRES,LASTUSE wrong.
  WEEKBLDT 17.029  Text in col 72 causes unexpected failure.
  XMXGSUM  17.370  Test version of VMXGSUM using SAS View to save DASD+.
  YEAR2000 17.363  Year 2000.  Julian 0cyyddd values convert to yyyyddd.

Inverse chronological list of all Changes:

Changes 17.398 thru 17.001 are contained in member CHANGESS.

****************NEWSLETTER THIRTY-FIVE**********************************










             MXG NEWSLETTER NUMBER THIRTY-FIVE February 20, 1999

Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE

                         TABLE OF CONTENTS                          Page

I.   MXG Software Version 16.16 was shipped with this newsletter.      2
 1. Major enhancements added in MXG 16.16.                             2
 2. MXG 16.16 contains new "MACKEEP" architecture.                     3

II.   MXG Technical Notes                                              7
 1. Counting tape mounts.

III.  MVS Technical Notes                                              7
 1. APAR OW35684 reports that the BLKSIZE in type 30 may be wrong.     7
 2. APAR OW31700 RMF OS/390 type 74 subtype 5 "short records"          8
 3. SMF type 42 APARS                                                  8
 4. APAR OW35952 corrects large value for IOUNITS in type 30.          8
 5. APAR PQ18797 for MQ Series Release 1.3.0, PTF UQ23424 zeros.       8

IV.   DB2 Technical Notes.                                             8
 1. Boole and Babbage's MainView for DB2 product's THRDHIST VSAM file  8
 2. After installing APAR PN55122, QWHCTOKN wrong for LU6.2 terms      8
 3. APARs PQ10864/PQ06968/PQ10864 excessive numbers of DB2 type 101s.  8

V.    IMS Technical Notes.                                             9

VI.   SAS Technical Notes.                                             9
 1. MXG 16.05 QA stream has executed using the SAS Version 7.          9
 2. RETAIN statement only retains variables in assignment statements.  9
 3. SAS 6.09 TS455 and TS460 on MVS SAS "VM1319" or "NO MKLE" error.   9
 4. SAS 6.09 TS455/TS460 do not free memory for user formats.         10

VII.  CICS Technical Notes.                                           10
 1. There are two CICS summary programs in MXG, ASUMCICS/ASUMCICX.    10
 2. APAR PQ13647 corrects invalid Y2K date in IBM type 110 subtype 2  10

VIII. Windows NT Technical Notes.                                     10

IX.   Incompatibilities and Installation of MXG 16.16.                10

X.    Online Documentation of MXG Software.                           11

XI. Changes Log                                                       11
     Alphabetical list of important changes                           11
     Changes 16.367 thru 16.222                                    14-58

      COPYRIGHT (C) 1999 MERRILL CONSULTANTS DALLAS TEXAS USA

  So what's really important?

  Year 2000 warrantee: 16.09+ is required for all products to be Y2K ok.

  Lots of new product support in MXG 16.16 for OS/390 2.7, CICS TS 1.3,
  DB2 1.6, NT 5.0, plus 360 other enhancements and changes, including:

  The new "MACKEEP" architecture, introduced in MXG 16.04 last summer,
  is inside MXG 16.16 and is in production at several hundred MXG sites.

  The Possible DOWN Side:

  This new design has incompatibilities with previously-valid tailoring,
  if you have changed EXxxxxx or IMACxxxx members that "OUTPUT":
   - Only if your tailored members uses "OUTPUT _Lxxxxxx" syntax.
   - An incompatibility shows up as a syntax error in JCLTEST6/JCLPDB6.
   - Member INSTALL shows error messages and their corrections.
   - Usually, changing the "_L" to "_W" eliminates the incompatibility.
       Before 16.04, MXG output datasets to their "_Lxxxxxx" macro name.
       The new design outputs first to a new "_Wxxxxxx" macro name, that
       defaults to the //WORK file, and then the data is sorted to their
       "_Lxxxxxx" macro name.  If you have tailored MXG and have an exit
       member with "OUTPUT _Lxxxxxx" statement, change the _L to a _W.
     You can scan your EXxxxxxx and IMACxxxx members for "OUTPUT"
     to see which of your exit members (if any) need to be altered.
  if you used TYPExxxx members, you may need to now use TYPSxxxx:
   - The old TYPExxxx members wrote their data, unsorted to //WORK and
     used their _L macroname.  Now, TYPExxxx still write to work, but
     to their _W macroname, and new TYPSxxxx members should be used in
     place of the old TYPExxxx members, because the TYPSxxxx members
     create sorted datasets (written to their _L macroname) so that you
     can use &Pdddddd macros for their output destination without EDITs.

  The UP Side:

    With the new design, you may not need that exit member anymore!
    - If you tailored the EXxxxxxx/IMACxxxx member just to change the
      destination DDNAME of an MXG dataset, you can do that now with the
      new &Pdddddd macro and a %LET statement, in //SYSIN, and no longer
      have to EDIT/SAVE members to change the output.
    - In the old design, IMACxxxx members defined product macros, so
      your tailoring member had my macro with all of its definitions.
      Now, IMACxxxx members define nothing, as all macros are now
      defined in their VMACxxxx.  Only the macros you want to change
      need to be in your IMACxxxx tailoring members. Furthermore, you
      can put all of your changes in the single member, IMACKEEP.
    - And still further, you don't even have to have any EDIT/SAVED
      member to tailor MXG.  Instead, you can pass all of your changes
      "instream", thru //SYSIN, using the new MACKEEP= feature.

  The Bottom Line:

    Dropping in a new MXG Version is usually a "piece-of-cake", and for
    most sites this one will be too, but everyone should plan an extra
    hour for this install, to read the new INSTALL and DOCMXG members.

    In the worst case, any incompatibility problem can be solved by MXG
    Technical Support by emailing your "USERID.SOURCLIB" tailoring
    library.  You can use member JCLZERO to create a single text file in
    IEBUPDTE format that can then be emailed (it will compress nicely)
    so that I can recreate your error.  Out of several hundred sites
    running 16.04+, only three have had to send their tailoring library!

I.   MXG Software Version 16.16 was shipped with this newsletter.

 1. Major enhancements added in MXG 16.16:

    While this newsletter is at the printer, additional changes may
    be made; check member CHANGES of the MXG 16.16 library to confirm
    that these enhancements did in fact occur:

    Member INDEX should exist to index MXG subjects and programs.
    Support for CO:DI(NDM), a unix log file, is planned.
    Support for UNICENTER logs is planned.
    Analysis of Job-Delay (HSM,TMNT,TALO) will have been enhanced.

    Major enhancements added in MXG 16.10:

      OS/390 R2.7, CICS TS 1.3 and DB2 6.1 were supported in MXG 16.09
        and that support is now documented.  See 16.09 enhancements.
      Support for IDMS Version 14 Journal Records.
      Support for Sterling's SOLVE NetMaster TCP/IP SMF.
      Support for BETA93 subtypes 1,2,3,4,20,40,41,42.
      Support for WINDOWS NT 5.0 (INCOMPATIBLE) with NTSMF.
      Support for new NT 4.0 objects.

    Major enhancements added in MXG 16.09 (revised):

      Support for Year 2000 kept Julian date fields input as 0cyyddd.
      Support for CICS TS 1.3 (INCOMPATIBLE):
        Lots of new CICSTRAN data, including Java execution
        and wait times and web statistics, and new statistics data for
        each of the now-eleven CICS TCBs. See Change 16.322.
      Support for DB2 Version 6.1 (COMPATIBLE).
        New header identifies end user's USERID and TERMINAL, more
        wait information, CPU time for Stored Procs and Triggers and
        User Defined Functions (with SQL time separated). Change 16.318.
      Support for OS/390 Release 2.7 (COMPATIBLE)
        New Type 74-6 HFS Global/Buffer/File Statistics, Type 73/79 CPMF
        mode, Type 70 Dec/Shared Processors Changed, new type 74 time of
        Device-Active-Only, and OS/390 Firewall Server Log Messages are
        written in new Type 109 SMF record.  See Change 16.329.

    Major enhancements added in MXG 16.08:

      Support for APAF for more than 8 CPU Engines.
      Support for BETA93 Release 3.1.3 INCOMPATIBLE subtype 0, 20.
      VMXGSUM will use new INHERIT if executed under SAS Version 7.
      IMS 6.1 support corrected for APPC, CPIC driven transactions.
      Support for DOS/VS Power V6.3.0 (COMPATIBLE).
      Revisions to RMM EDGR support - numeric date variables.

    Major enhancements added in MXG 16.07:

      Support for APAF 4.1 and 4.3 (INCOMPATIBLE).
      Support for BETA93 Release 3.1.3 INCOMPATIBLE subtype 21.
      ANALRMFR RMF reports added REPORT=XCF.

    Major enhancements added in MXG 16.06:

      Support for NPM 2.4, unfortunately very INCOMPATIBLY changed!
      PDB.CICINTRV dataset may be real bad; please get this new code!
      Support for CICS TS 1.2 Journal Format, INCOMPATIBLE.
      Support for PSF/MVS Release 3.1.0 (COMPATIBLE).
      Support for subtypes 17-20 (FSRTYPE=) HSM FSR records.
      Support for IXFP / ICEBERG fields added by APAR L170017.
      Support for Boole & Babbage MainView for CICS CMRDETL file.
      Correction for SMF 118 TCP/IP logic to not use length/subtype.
      MXG 16.04-16.05 only. ASUM70PR summarized to SHIFT vice HOUR.

    Major enhancements added in MXG 16.05:

    Fix for TMS5 multi-datasets tapes (was wrong).
    Fix for IMS 6.1 Log Records (TYPEIMSA) if GMT Offset was not zero.
    Support for OAM (Optical Access Method) SMF type 85 record
    Support for DFSORT Release 15 (no change)
    Support for Interlink TCPaccess Version 5.2 (INCOMPAT)
    Support for decompression of MainView history files.
    Support for RACF "installation-defined data field".
    ML-18 of MXG ASMTAPES MXGTMNT monitor fixes DSAB circular queue.

    Major enhancements added in MXG 16.04:

 2. MXG 16.04 is a major internal redesign of MXG, the new "MACKEEP"
    architecture, which makes tailoring of MXG datasets simpler and more
    powerful.  You can change the output DDNAME for a large dataset with
    a simple "%LET Pdddddd=DDNAME;" statement, you can put all of your
    MXG changes in the single member IMACKEEP (instead of having to EDIT
    an IMACxxxx for each product), or you can even tailor MXG instream
    using the new "%LET MACKEEP = ;" logic, and never have to EDIT any
    members into your USERID.SOURCLIB!.  This redesign to externalize
    all attributes of every dataset began in MXG 10.10 with the "_L,_K"
    macros; now that the software is finally done, I can get back to the
    rewrite of MXG documentation (but note that member DOCMXG already
    exists to document the new architecture, with examples!).

    And most, if not all, of your existing MXG tailoring should still
    work without change!

            "MACKEEP" Architecture of MXG-built SAS "Datasets"
                         Highlights

            Everything about the creation of an MXG dataset is now
            fully externalized, and ALL MXG tailoring can now be done
            either by
               EDIT into a single member, IMACKEEP (instead of EDITing
               a separate IMAC for each product)
            or
               all tailoring can be done "instream" using the new syntax
                   %LET MACKEEP=   MACRO _oldname newvalue  %  ;

            All MXG datasets now have an &Pdddddd macro variable as the
            destination DDNAME/LIBREF, so you can use %LET Pdddddd=MYDD;
            in IMACKEEP or with MACKEEP to change the DD to which each
            MXG dataset is written or read from.

            See member DOCMXG, INSTALL, and Change 16.134 for details.

    Major enhancements added in MXG 16.04:

    MXG "MACKEEP" Architecture - see INSTALL, DOCMXG, Change 16.134.
    Support for OS/390 Release 2.6 (COMPATIBLE).
    Support for IMS Log processing for IMS 6.1.
    Support for NTSMF Version 2.2.
    Support for ACF2 Version 6.2 type 'V' (INCOMPATIBLE).
    Support for TCP/IP 3.4 SMF type 118 (INCOMPATIBLE) changes.
    Support for NCR Teradata DBS performance data.
    Support for Landmark's SQL/CAPTURE Products 'D6' record.
    Support for XCOM Release 3.0 (COMPATIBLE).
    Support for Soft Audit's Installed Products File.
    Support for BGS I/O Monitor Version 5.1.0 (COMPAT).
    Support for HSM APAR OW31281 adds RECALL, DSR, FSR statistics.
    Support for DFSMS 1.4.0 added WFSCPUTM for ABARS CPU cost.
    Support for NTSMF CachingManager and Packet Filter objects.
    Support for NT Service Pack 5A SYSTEM/PROCESS fields.
    Major revision of TMS/CA-1 processing logic in TYPETMS5.
    ML-17 of MXGTMNT/ASMTAPES synchronizes automatically.
    Enhanced TPM support reads all possible variables in TYPETPMX.
    Analysis of SMF Write Rates (MEGABYTES at 10/100sec)
    MXG CONFIG value of VMCTLISA=40K raised to 160K.
    VMXGSUM syntax for "DATETIME" now uses real name.
    ABEND/CONDCODE in PDB.JOBS is now valid, has 1st ABEND.
    (MXG 16.03 was only released as a Beta.)

    Major enhancements added in MXG 16.02:

    Support for TYPEIMS7 for IMS 6.1.
    Support for OS/400 Version 4.2.0 COMPATIBLE.
    Support for MQ Series Version 1 Release 2 INCOMPATIBLE.
    Support for Landmark's Monitor for DB2 V 3.1 INCOMPATIBLE.
    Support for Candle Omegamon V400 CANMQ and CANWLMSC.
    Support for Candle Omegamon CICS V400 "255" record.
    Support for Raptor Systems' Eagle Firewall 121 Log.
    Support for TME 10 NetView for OS/390 V1 R1 SMF 38.
    Support for Web Proxy logs Extended Common Log format.
    Support for Magstar tapes in TYPETMS5 INCOMPATIBLE.
    &PDBxxxx and &yyyzzz "Dataset &Macro" naming rules.
    New PDB datasets TYPE74CO/ME/PA/SY/OM/LK added to daily PDB.
    New ANALABND report ABENDs from PDB.STEPS, uses PROC TABULATE.
    Multiple JES3 purge records created duplicate PDB.JOBS obs.
    All MXG variables with format MGBYTES are now stored in 8-bytes.
    New ANAL6264 merges VSAM type 62 and 64 for OPENTIME.

    Major enhancements added in MXG 16.01:

     The major thing in 16.01 is support for Year 2000 products that
     were not Y2K compliant when 15.15 was built, so MXG 16.01 is now
     the minimum level to support all vendor records that provide year
     2000 dates, but there are also a few fixes and several enhancements
     and new products supported.

    Year 2000 issues that require MXG 16.01 or the specific change:
      TYPE6 READTIME was 1900 in 2000 due to MXG error (Change 16.039).
      AS/400 Year 2000 Support was Incorrect (Change 16.035).
      NETVIEW NPM type 28 year Y2K Ready but INCOMPATIBLE record change.
      Landmark TMON for CICS V2 converted to V8.1 Y2K Ready, INCOMPAT.
      IPAC RDS View Direct V 6.1 Y2K Ready, but INCOMPATIBLE change.
      MXG Software now warrants it is "Year 2000 Ready".

    Support for new NTSMF objects (Database, SMTP Server, WEB Service).
    Support for revised NTSMF Active Server Pages and IISG records.
    Support for Software Engineering's SpaceManager data records.
    Support for DECnet/SNA DTF SMF records.
    MXG 15.15 problems reported and fixed:
      Variable MXGVERSN in TYPE70 was blank in 15.15; impacts CPEXPERT.
      Deactivated PR/SM Partition may cause over 100% CPU Busy for CEC.

  All of these enhancements are described in the Change Log, below.

    Availability dates for the IBM products and MXG version required:

                                       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 30  1996        14.05
      OS/390  1.3.0 Compatibility Mode Mar 28  1997        14.14
      OS/390  1.3.0 WLM Goal Mode      Mar 28  1997        15.02
      OS/390  2.4.0                    Sep 28  1997        15.06
      OS/390  2.5.0                    Feb 24  1998        15.06
      OS/390  2.6.0                    Sep 24  1998        16.04
      OS/390  2.7.0                    Mar 26  1999        16.09
      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 aka CICS/TS V1R1    Sep 10, 1996        14.07
      CICS-Transaction Server V1R1     Sep 10, 1996        14.07
      CICS-TS V1R1 with APAR UN98309   Sep 15, 1997        15.06
      CICS-TS V1R2                     Oct 27, 1997        15.06
      CICS-TS V1R3                     Mar ??, 1999        16.09
      CRR 1.6                          Jun 24, 1994.       12.02
      CRR 1.7                          Apr 25, 1996.       14.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           Sep 11, 1996        14.07
      DB2 5.1.0 Tolerate               Jun 27, 1997        14.14
      DB2 5.1.0 Full support           Jun 27, 1997        15.02
      DB2 6.1.0                        Mar ??, 1999        16.09
      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
      DFSMS/MVS 1.4                    Sep 28, 1997.       15.04
      DFSMS/MVS 1.4 HSM                Sep 23, 1998.       16.04
      MQM 1.1.2, 1.1.3, 1.1.4          Apr 25, 1996.       14.02
      MQ Series 1.2.0                  May 26, 1998.       16.02
      NETVIEW 3.1 type 37              ??? ??, 1996.       14.03
      NPM 2.0                          Dec 17, 1993.       12.03
      NPM 2.2                          Aug 29, 1994.       12.05
      NPM 2.3                          ??? ??, 1996.       15.08
      NPM 2.4                          Nov 18, 1998.       16.06
      RMDS 2.1, 2.2                    Dec 12, 1995.       12.12
      TCP/IP 3.1                       Jun 12, 1995.       12.12
      TCP/IP 3.4                       Sep 22, 1998.       16.04

      DOS/VSE POWER V6.3.0             Dec 19, 1998.       16.08
      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
      VM/ESA  2.3                      ??? ??, ????        16.08
      IMS     4.1                      Aug  6, 1994        12.02
      IMS     5.1                      Jun  9, 1996        14.05
      IMS     6.1                      ???  ?, 199?        16.04
      AS400 3.7.0                      Nov  1, 1996        15.01
      AS400 4.1.0                      Dec 30, 1996        15.08
      AS400 4.2.0                      Apr 27, 1998        16.02

    Availability dates for non-IBM products and MXG version required:

                                                        MXG Version
      Product Name                                       Required

      Microsoft
       Windows NT 4.0 and NT 3.51                          14.14
       Windows NT 4.0 Service Pack 2                       15.03
       Windows NT 4.0 Service Pack 5                       16.04
      Demand Technology
       NTSMF Version 1 Beta                                14.11
       NTSMF Version 2.0                                   15.05
       NTSMF Version 2.1                                   15.06
       NTSMF Version 2.2                                   16.04
      Landmark
       The Monitor for DB2 Version 2                       13.06
       The Monitor for DB2 Version 3.0                     16.02
       The Monitor for DB2 Version 3.1                     16.02
       The Monitor for CICS/ESA 1.2 -                      12.12
       The Monitor for CICS/ESA 1.3 -                      15.01
       The Monitor for CICS/ESA 2.0 -                      15.06
       The Monitor for MVS/ESA 1.3  -                      12.05
       The Monitor for MVS/ESA 1.5  -                      12.05
       The Monitor for MVS/ESA 2.0  -                      15.09

      Candle
       Omegamon for CICS V200 User SMF                     12.05
       Omegamon for CICS V300 User SMF                     13.06
       Omegamon for CICS V400 User SMF                     16.02
       Omegamon for CICS V400 type 110 segments            16.02
       Omegamon for IMS V110 (ITRF)                        12.12
       Omegamon for IMS V300 (ITRF)                        14.04
       Omegamon for MVS V300                               13.05
       Omegamon for MVS V400                               13.06
       Omegamon for DB2 Version 2.1/2.2                    13.05
       Omegamon for VTAM V160                              12.04A
       Omegamon for VTAM V400                              15.15
       Omegamon for SMS V100/V110                          12.03
      CA
       ACF2 6.2                                            16.04
       ASTEX 2.1                                           14.04
       NETSPY 4.7                                          14.03
       NETSPY 5.0                                          14.03
       NETSPY 5.2                                          16.05
      Boole & Babbage
       IMF 3.1 (for IMS 5.1)                               12.12
       IMF 3.2 (for IMS 6.1 only)                          15.09
       IMF 3.2 (for IMS 5.1 and 6.1)                       16.04
      Memorex/Telex
       LMS 3.1                                             12.12A

      MXG IMS-Log Not-Officially-Supported
       IMS 6.1  -   ASMIMSL6/TYPEIMSA                      16.06
       IMS 5.1  -   ASMIMSL5/TYPEIMSA                      16.01
      Amdahl
       APAF 4.1, 4.3                                       16.08


II.  MXG Technical Notes

 1. Counting tape mounts.
    Tape mount counts from the MXGTMNT monitor can be compared with the
    tape mount counts (TAPNMNTS+TAPSMNTS) in the step records, and there
    can be differences, mostly due to the difference in time frame of
    the mount records (when they occur) and the step records (when the
    step ended):
    - MXG will count high for Started Tasks that never end (e.g. DFHSM),
      or for any job whose step record had not yet been written in the
      SMF time frame you examined.
    - MXG will count low for steps that ended in the SMF time-frame, but
      whose mounts occurred before the start of that SMF file.
    - MXG counts physical mount events, but the type 30 counts completed
      mounts, so when your tapeape intentionally mounts the wrong VOLSER
      five times
         if they can't find the right tape, they mount any tape, knowing
         MVS label-check will prevent it from being used, but any mount
         terminates the outstanding mount message so the MVS console guy
         can't see how long the real mount has been waiting!
      the MXG count is five mounts, the step record count is one.
    - MXG misses some VTS scratch mounts, when using the default two
      second sampling in MXGTMNT, because scratch mounts to VTS can be
      fast.  In one day MXG missed 200 VTS scratch mounts out of 2000
      total VTS mounts with the two-second sampling, but MXGTMNT saw
      all of the VTS scratch mounts with one-half second sampling.

    Recommendations:

    If you want to compare totals, use the TYPE30_V or PDB.SMFINTRV data
    from type 30 interval records instead of TYPE30_4 or PDB.STEPS data
    to minimize (but not eliminate) time-frame error, since the interval
    records will count the mounts for those long-running jobs and STCs.

    If you do have Virtual Tape Devices, you could change the interval
    constant in member ASMTAPES (INTERVAL DC F'200' to  DC F'050') to
    change the MXG default of 2.00 seconds to 0.50 seconds, and then
    re-assemble to change the MXGTMNT program to sample at half-second
    intervals.  While 2 seconds is still the MXG default, half-second
    was tested and briefly suggested as an alternative, as the CPU cost
    was still small:
      At half-second sampling, it took less than 3 CPU seconds per
      15 minute interval to scan 100 tape devices, and another 1 CPU
      second for every 100 tape mounts, or a few minutes per day with
      2000 mounts.

    However, even with .5 second interval, the mount monitor missed some
    fast VTS mounts, which caused me to create the completely new logic
    in the ASUMTAPE program, which creates the new PDB.ASUMTAPE dataset
    (that should be used in place of PDB.TYPETMNT in tape mount
    analysis).  The new logic is driven by the type 21 dismount record,
    so even if MXGTMNT missed the fast mount, PDB.ASUMTAPE has the tape
    event, albeit with the tape mount duration missing (so you know it
    was less than 2 secs!), so the original 2 second default was kept.

    If you decide to change the sample interval, you can compare the
    number of observations in PDB.ASUMTAPE that have missing TAPMNTTM,
    to see how many more of the fast-scratch-VTS-mounts you actually
    capture at 1/2 second instead of the MXG default of 2 seconds.

    This note was revised for clarity about the MXG default 19Jun2001.

III. MVS Technical Notes.

 1. APAR OW35684 confirms that the BLKSIZE in the DD segments of type 30
    records is correct for tape but incorrect for a DASD dataset that is
    being opened for output DISP=NEW when DADSM allocate did not
    determine a system determined blocksize (SDB) even though BLKSIZE=0
    was specified on the DD statement.  DADSM SDB processing was not
    done because DSORG and/or LRECL were not also specified.  The APAR
    is closed "FIN" - Fixed in Next DF/SMS Release in 18-24 months.

 2. APAR OW31700 RMF OS/390 type 74 subtype 5 describes "short records"
    created when there are more than 153 devices on a cache controller
    (because 153 segments fills the 32756-byte limit of SMF data).  They
    have no impact on MXG, as MXG reads each record and outputs from
    each device data section (but IBM had to add counters so RMF
    could reassemble the large event from these 32K "small" records).
    There may be an error, as I have seen type 74 subtype 5 records with
    only the Product and Control section, with no status nor data and
    with R745CCNT, record sequence, of 2.  Site is talking to IBM.

 3. SMF type 42 APARS:
    APARs OW29633 corrects timestamps in TYPE42DS (type 42 subtype 6)
    SMF records that caused SMF42PTS to be much earlier than the job's
    READTIME.  Reported in OW10694 (closed RET) and OW25624 (closed PER)
    the actual error was a failure to free main between jobs, so you
    would have someone else's READTIME in your record.  This error was
    not fixed to correct SMF, but because someone's system stayed up
    long enough that the memory leak causes a storage shortage ABEND!

    APAR OW32248 discusses type 42 VSAM/RLS counter errors, affecting
    SMF41IAY/IAZ/IBA/IBB/ICY/ICZ/IDA/IDB/IBG/IDG fields.

    APAR OW35762 corrects count of SEQ blocks read and written for PS
    datasets on non-SMS managed volumes.

 4. APAR OW35952 corrects large value for IOUNITS in type 30 records;
    the problem primarily affected DB2 address spaces with very large
    (but legitimate) I/O counts that caused an overflow in IO Servunits.

 5. APAR PQ18797 for MQ Series Release 1.3.0, PTF UQ23424 corrects zero
    values for 'QMSTxxxx' variables in dataset MQMMSGDM from type 115
    SMF record subtype 2.

IV.  DB2 Technical Notes.

 1. Boole and Babbage's MainView for DB2 product's THRDHIST VSAM file is
    used for online access and its keyed record format is not public, so
    MXG cannot support that file.  But Boole recommends you create DB2
    SMF records (their DB2 batch reports use the 100/101/102 records) so
    THRDHIST was never intended to be useful for accounting or trending.

 2. MXG Newsletter 34 reported that after installing APAR PN55122 and
    migrating to CICS/ESA 5.1 (that's /ESA in 1996 not /TS 5.1 in 2012!)
    that LU6.2 terminal's QWHCTOKN no longer had the UOWID token in
    their DB2ACCT record (as a result, MXG's ASUMUOW could not match
    DB2ACCT to CICSTRAN by Unit-of-Work ID).  IBM has now released APAR
    PQ15565 (and PTF UQ18583) to correct their error.

 3. APARs PQ10864/PQ06968/PQ10864 discuss excessive numbers of DB2 type
    101 SMF records that are created with CPU parallelism; if your DB2
    application is running with more than 1 degree of CPU parallelism,
    the child tasks will create SMF 101 accounting records every time
    they are spawned (i.e., every SQL execution).  In cases where an
    application loops thru static SQL frequently or for transaction type
    queries the volume can be a very serious problem.  This problem will
    NOT be fixed until DB2 Version 6, but APAR PQ06968 has been created
    to allow RLF to disable modes of parallelism during static BIND; by
    using RLFFUNC=4 during BIND, you can force problem applications back
    to IOP parallelism (versus CPU parallelism).

V.   IMS Technical Notes.


VI.  SAS Technical Notes.

 1. MXG 16.05 QA stream has executed using the SAS Version 7 Beta, under
    OS/390, Windows 95/98 and Windows NT.  Minor changes were needed in
    MXG code, mostly to circumvent Beta things that SAS will have fixed
    by the Production release this fall.  A complete list will be in a
    future MXG Technical Note when Version 7 is available.
    Initial performance measurements of the MXG QA stream show no change
    in the runtime between Version 6.12 TS045 and Version 7 Beta, so
    it looks like lots of new features at no cost, for a change!

    SAS Version 7 datasets cannot be read by SAS Version 6; the format
    of SAS data libraries on all platforms was changed incompatibly.
    Fortunately, MXG will not exploit on any SAS Version 7 features in
    the near future, and there are no compelling reasons to migrate to
    SAS Version 7 (run times and resources were about the same), but
    when you do migrate to SAS V7, you will either have to drop it in
    all at once, or at least you will need to install from the back end:
    convert your report programs first and then convert the programs
    that build the datasets that the reports use.

 2. RETAIN statement only retains variables in assignment statements.
    You cannot use a RETAIN statement with SET A B  logic to retain the
    value of variable A from dataset A into processing of observations
    from dataset B.  While the A variable will exist in the OUT dataset
    its value will be missing:

       DATA A; A=1;
       DATA B; DO B=1 TO 5; OUTPUT B; END;
       DATA OUT; SET A B;
       RETAIN A;

    To retain the value of variable A, you must assign it to a new name
    (AA) while reading an observation from dataset A, retain that AA
    name, and then when reading an observation from dataset B, assign AA
    back to its original name A (and then DROP variable AA from OUT):

       DATA OUT; SET A (IN=INA) B (IN=INB);
       RETAIN AA;  DROP AA;
       IF INA THEN AA=A;
       IF INB THEN DO; A=AA; OUTPUT; END;

    Fortunately, variable A's attributes (LABEL, FORMAT, etc) are indeed
    propagated into variable A in the OUT dataset.

 3. SAS 6.09 TS455 and TS460 on MVS may encounter SAS "VM1319" or "NO
    MKLEs" ABENDs, due to a memory overlay introduced by TS455.  SAS ZAP
    Z609E449 exists and is flagged as REQUIRED, but is not a true fix.
    That ZAP forces SAS options MVARSIZE=0 and MSYMSIZE=0, which causes
    %MACRO variables and symbol tables to be written/read to/from disk
    instead of from memory. By reducing memory for macros, the overlay
    may be avoided, but depending on how %macros are used, that ZAP
    could impact runtime performance.  The text of ZAP Z609E449 suggests
    that increasing MEMSIZE may circumvent the error, since the overlay
    is less likely with more addressability, so if you encounter the
    error, first increase MEMSIZE by 8MB (and remember to increase your
    REGION size), and then if that doesn't work, then either install the
    ZAP, or install its effect by setting MVARSIZE=0 and MSYMSIZE=0
    yourself.

 4. SAS 6.09 TS455/TS460 do not free memory for user formats, which can
    cause an out of memory error if there are repeated references to a
    user format, e.g., a DO Loop around PUT(variable,format) statement
    where the format is NOT one supplied with SAS (MGxxxxx formats or
    your own build with PROC FORMAT are "user formats").
    SAS ZAP Z609F331 will correct this memory "leak".

VII. CICS Technical Notes.

 1. There are two CICS summary programs in MXG:
     ASUMCICS summarizes the detail CICSTRAN.CICSTRAN transactions, so
              variable NUMTRANS counts the number of transactions.
     ASUMCICX summarizes the already-summarized ASUMUOW unit-of-work
              dataset, so NUMTRANS counts the number of unit's-of-work,
              and variable MROTRANS counts the number of CICSTRAN
              transactions that were executed by that unit-of-work.

 2. APAR PQ13647 corrects invalid Y2K date in IBM type 110 subtype 2
    TS Server records written by CICS TS 1.1 and 1.2.  The dates will
    contain 1AYY instead of 20YY without this fix.



VIII. Windows NT Technical Notes.

   There are no Windows NT Technical Notes in this Newsletter.


IX.   Incompatibilities and Installation of MXG 16.16.

 1. Incompatibilities introduced in MXG 16.16 (since MXG 15.15):

  a- IMACs that were changed (if they exist in your USERID.SOURCLIB, you
     must refit your tailoring, starting with the new IMAC member):

      Almost all IMACxxxx members can be consolidated into "IMACKEEP".

  b- Other incompatibility changes:

     The "MACKEEP" re-design may be incompatible with some previously
     valid user-tailoring.  See instructions in member INSTALL, which
     show examples of the error messages which can result and their fix.

     All MGBYTES formatted variables are now length 8, instead of 4.
     If you use PROC APPEND without FORCE, SAS will ERROR when you try
     to combine new and old datasets with dissimilar length variables.

  c- The products that were incompatibly changed by their vendor are
     listed in the Changes Log, section XI, below.


 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.

X.    Online Documentation of MXG Software.

    MXG Documentation is now described in member DOCUMENT.


XI.   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 is normally
 created after the newsletter is sent to the printer!  Member CHANGES
 on the www.MXG.com homepage are the most timely, as they are updated
 (sometimes) between MXG versions.

 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 15.15 now in MXG 16.16:

  Dataset/
  Member   Change    Description

  Many     16.216  Support for OS/390 Release 2.6 (COMPATIBLE).
  Many     16.078  MXG variables with format MGBYTES are now 8-bytes.
  Many     16.068  &PDBxxxx and &yyyzzz "Dataset &Macro" naming rules.
  ADOCQAPM 16.301  Enhanced documentation for AS/400 processing
  ANAL6264 16.071  Analysis merges VSAM type 62 and 64 for OPENTIME.
  ANALABND 16.082  ABEND stats from PDB.STEPS, uses PROC TABULATE.
  ANALCISH 16.104  MORE THAN 32767, MORE THAN 10 errors corrected.
  ANALPATH 16.006  SUBSCRIPT OUT OF RANGE, report expected 10 LCUs max.
  ANALRMFR 16.295  ANALRMFR RMF reports added REPORT=XCF.
  ANALSRVC 16.098  Report now works for CPU Percent by Service Class.
  ANALUOW  16.075  Enhancements, DB2 Class 3 waits. etc were added.
  ANALVTS  16.162  Analysis combines 30s, TMNT, TALO and 21s for tapes.
  ANANCNCR 16.206  COUNT= option corrected.
  ASMIMSL5 16.058  ASMIMSL5 in MXG 15.15 failed during assembly.
  ASMIMSL6 16.185  Support for IMS Log processing for IMS 6.1.
  ASMMNVW  16.247  Support for decompression of MainView history files.
  ASMTAPES 16.154  ML-17 of MXGTMNT synchronizes automatically.
  ASMTAPES 16.164  MXGTMNT misses too-fast VTS tape mounts.
  ASMTAPES 16.259  ML-18 of ASMTAPES protects DSAB circular queue.
  ASUM42DS 16.046  New summary member for TYPE42DS by dataset.
  ASUM70PR 16.028  Deactivated Partition may cause over 100% CPU Busy.
  ASUM70PR 16.271  16.04-16.05. ASUM70PR summarized at SHIFT vice HOUR.
  ASUMCACH 16.141  DURATM in ASUMCACH revised for accuracy.
  ASUMCICS 16.137  INVALID ARGUMENT TO FUNCTION SQRT when N=1.
  ASUMHSM  16.315  Revision to Support HSM Y2K Julian dates.
  ASUMHSM  16.345  HSM summarization separates HSM active from queued.
  ASUMTALO 16.076  Revised to work with TALO records from old ASMTAPES.

  ASUMTALO 16.169  SPIN.SPINTALO now backed up into PDB library.
  BLDNTPDB 16.180  NTSMF Daily/Weekly/etc BUILD program enhanced.
  BUILDPD3 16.080  JES3 BUILDPDB - Multiple PDB.JOBS obs - multi purges.
  BUILDPDB 16.008  Duplicate TYPE30_V records might not be deleted.
  BUILDPDB 16.107  PDB.TYPE74CO/ME/PA/SY/OM/LK added to day/week PDB.
  BUILDPDB 16.183  ABEND/CONDCODE in PDB.JOBS now valid, has 1st ABEND.
  BUILDPDB 16.230  Duplicate type 30 records caused RESTARTS to be high.
  BUILDPDB 16.231  TYPE6 vars STDUPLEX/FCB/OVLYLOAD/OVLYUSED added.
  BUILDPDB 16.348  BINxxxx variables added to PDB.PRINT.
  CICINTRV 16.253  Revision of CICINTRV auto-determine input location.
  CICINTRV 16.277  PDB.CICINTRV dataset may be real bad; get this code!
  CONFIG   16.066  Option SASAUTOS=(SOURCLIB SASAUTOS) is now used.
  CONFIG   16.117  CODEPCT=150 now set to eliminate SAS message.
  CONFIG   16.157  MXG CONFIG value of VMCTLISA=40K raised to 160K.
  CONFIG   16.209  NOSTIMER now specified, SAS 6.12 TS045 changed.
  DOCGRAF  16.018  Examples of getting graphs from mainframe to your PC.
  DOCMXG   16.134  New &MACKEEP and IMACKEEP MXG architecture changed.
  FORMATS  16.214  Support for DF/SMS 1.4 changes to HSM (COMPAT).
  IMACFILE 16.016  &MACFILE macro added for instream tailoring.
  IMACICDM 16.067  Support for Candle Omegamon V400 CANMQ and CANWLMSC.
  IMACPDB  16.106  Enclave CPU time and count added to PDB.STEPS/JOBS.
  IMACPDB  16.341  IMACPDB documentation, no code was changed.
  MXGSAS   16.081  JCL parameter TAILORNG now spelled TAILOR.
  RMFINTRV 16.288  Sort order of RMF is now BY SYSPLEX SYSTEM STARTIME.
  TRND70   16.021  TRENDing of TYPE70 now supports 16 buckets of CPUs.
  TRND72GO 16.029  Variable R723CIMP in TRND72GO SUMmed vice IDd.
  TRNDTALO 16.221  Overlapped hour could miscount tape allocations.
  TYPE109  16.329  Support for TYPE109 OS390 Firewall Server.
  TYPE110  16.031  CICS UNEXPECTED STID=0 was error in STID=94 segment.
  TYPE110  16.153  GMT offset calculation in CICS off by up to 1.4 secs.
  TYPE110  16.270  Support for CICS TS 1.2 Journal Format, INCOMPATIBLE.
  TYPE110  16.322  Support for CICS TS 1.3 (INCOMPATIBLE).
  TYPE115  16.099  Support for MQ Series Version 1 Release 2 (INCOMPAT).
  TYPE16   16.254  Support for DFSORT Release 15 (No Change).
  TYPE28   16.003  NETVIEW NPM type 28 INCOMPATIBLE year 2000 change.
  TYPE28   16.290  NPMLANOD dataset TIC_UTIL variable was missing.
  TYPE28   16.336  STOPOVER NPM 2.4 NPMSUBTY='DD'x; IBM doc was wrong.
  TYPE30   16.150  TYPETASK='ASCH' or TYPETASK='OMVS' now set in PDB.
  TYPE38   16.101  Support for TME 10 NetView for OS/390 V1 R1 SMF 38.
  TYPE42   16.339  SMF type 42 subtypes 15-19 (VSAM RLS) now validated.
  TYPE57   16.234  JES3 with more than 9999 job numbers INVALID DATA.
  TYPE6    16.039  READTIME in TYPE6 and hence PRINT is 1900 in 2000.
  TYPE6    16.264  Support for PSF/MVS Release 3.1.0 (COMPATIBLE).
  TYPE7072 16.009  Variable MXGVERSN in TYPE70 was blank in 15.15.
  TYPE7072 16.194  Delay Percents now divided by R723CTSA.
  TYPE7072 16.326  TYPE72 Compat Delay variables were incomplete.
  TYPE7072 16.327  PERFINDX sometimes missing for Average Resp Goals.
  TYPE7072 16.328  Variable PCTMETGO added to TYPE72GO for Percentiles.
  TYPE7072 16.342  New variable CECSER with CPU Serial of the CEC.
  TYPE72GO 16.064  Variables AVGRESP, EXETTM, AVGXETTM added/changed.
  TYPE72GO 16.083  Variables R723CQDT/CADT/CCVT/CIQT wrong multiplier.
  TYPE74   16.032  NO STRUCTURE MATCH message understood and eliminated.
  TYPE74   16.095  TYPE74 variable IORATE changed to match IBM's RMF.
  TYPE74   16.329  Support for TYPE746B/F/G datasets in OS/390 R2.7.
  TYPE79   16.213  Type 79 Subtype 15 (IMS Long Lock) corrected.
  TYPE7xxx 16.288  Sort order of RMF is now BY SYSPLEX SYSTEM STARTIME.
  TYPE80A  16.236  Support for RACFEVNT=26 APPCLU Session Establish.
  TYPE80A  16.245  Support for RACF "installation-defined data field".
  TYPE85   16.255  Support for OAM type 85 SMF record, 11 datasets.
  TYPE94   16.135  VTS variables SMF94VBA/VLA were mis-documented by IBM
  TYPE99   16.026  New subtype 6 SMF type 99 INVALID SERVER SECTION.
  TYPEACF2 16.215  Support for ACF2 Ver 6.2 type 'V' (INCOMPATIBLE).
  TYPEAPAF 16.305  Support for more than 8 engines in APAF data.

  TYPEBETA 16.293  BETA93 Version 3.1.3 INCOMPATIBLY changed.
  TYPEBETA 16.351  Support for BETA93 subtypes 1,2,3,4,20,40,41,42.
  TYPEBGSI 16.155  Support for BGS I/O Monitor Version 5.1.0 (COMPAT).
  TYPECIMS 16.030  ABENDUSR in CIMSPROG has never been right.
  TYPECIMS 16.227  IMF 3.2 with IMS 5.1 INPUT STATEMENT EXCEEDED.
  TYPEDB2  16.318  Support for DB2 Version 6.1 (COMPATIBLE).
  TYPEDB2  16.148  Dataset DB2STATR was invalid, duplicate observations.
  TYPEDCOL 16.017  DCOLLECT DSORG field expanded to 3 in MXG (PSU etc).
  TYPEDECS 16.034  Support for DECnet/SNA DTF SMF records.
  TYPEDOS  16.312  Support for DOS/VS Power V6.3.0 (COMPATIBLE).
  TYPEEAGL 16.102  Support for Raptor Systems' Eagle Firewall 121 Log.
  TYPEEDGR 16.308  Revisions to RMM EDGR support - numeric dates.
  TYPEHSM  16.136  DFSMS 1.4.0 added WFSCPUTM for ABARS CPU cost.
  TYPEHSM  16.145  Support for APAR OW31281 adds RECALL, DSR, FSR.
  TYPEHSM  16.149  SHORT ABAR message after Change 16.025 fixed.
  TYPEHSM  16.263  Support for FSRTYPE=17 thru 20 HSM FSR records.
  TYPEHSM  16.315  Revision to Support HSM Y2K Julian dates.
  TYPEICE  16.280  Support for IXFP fields added by APAR L170017.
  TYPEIDMJ 16.361  Support for IDMS Version 14 Journal Records.
  TYPEIDMS 16.002  New TASNxxx variables labels were incorrect.
  TYPEIDMS 16.012  IDMS 10.2.1 caused INPUT STATEMENT EXCEEDED.
  TYPEIDMS 16.033  IDMS 10.2 records were not output.
  TYPEILKA 16.249  Support for Interlink TCPaccess Vers 5.2 (INCOMPAT)
  TYPEIMS7 16.119  Support for TYPEIMS7 for IMS 6.1.
  TYPEIMSA 16.069  ASMIMSL5 process now has _L, _K macros, exit members.
  TYPEIMSA 16.257  IMS 6.1 Support correct only in European Summer Time.
  TYPEIMSA 16.343  Zero observations in IMSFASTP, SUBCODE not kept.
  TYPEIPAC 16.052  Y2K INCOMPATIBLE IPAC RDS 6.1 user SMF record.
  TYPEMON8 16.049  Y2K Support for TMON V2 records converted to 8.1.
  TYPEMON8 16.073  INVALID DATA FOR TMMDMODL message corrected.
  TYPEMON8 16.091  TMON for CICS V2 Converted records MONIRECD='D'.
  TYPEMVCI 16.260  Support for Boole & Babbage MainView CMRDETL file.
  TYPENDM  16.060  Sterling's Connect Direct aka NDM PI=754129 open.
  TYPENSPY 16.147  NETSPY='N' record support was restored for old 4.4.
  TYPENTSM 16.024  Support new "Database" object and EXCHANGE 5.5.
  TYPENTSM 16.045  Support for IISG, Active Server Pages, Web Service.
  TYPENTSM 16.049  New SNA LU, SNA 3270 Response, etc, NTSMF objects.
  TYPENTSM 16.121  Support for NTSMF Cache Mgr & Packet Filter objects.
  TYPENTSM 16.133  Summarization of NETWSEGM into NTINTRV wrong if two.
  TYPENTSM 16.177  Support for NT Service Pack 5A SYSTEM/PROCESS fields.
  TYPENTSM 16.199  NTSMF Object='WidetoMBErr' explained.
  TYPENTSM 16.208  Support for NTSMF internal 0.1 configuration record.
  TYPENTSM 16.217  New objects NetShow Station/Unicast Service support.
  TYPENTSM 16.228  Support for NTSMF V2.2 with Record Header 2.2.1.
  TYPENTSM 16.317  Support for NTSMF 2.2.1 header (or use COMPRESS).
  TYPENTSM 16.337  Support for new NT 4.0 objects.
  TYPENTSM 16.350  Support for WINDOWS NT 5.0 (INCOMPATIBLE) with NTSMF.
  TYPEOMCI 16.116  Support for Candle Omegamon CICS V400 "255" record.
  TYPEOMVT 16.262  Candle Omegamon for VTAM documentation error.
  TYPEQAPM 16.035  Year 2000 Support for AS/400 was corrected.
  TYPEQAPM 16.063  Support for OS/400 Version 4.2.0 (COMPATIBLE).
  TYPESFTA 16.175  Support for Soft Audit's Installed Products File.
  TYPESOLN 16.356  Support for Sterling's SOLVE NetMaster TCP/IP SMF.
  TYPESPMG 16.020  Support for Software Engineering's SpaceManager data.
  TYPETAND 16.118  Tandem variables CnBLKS and CnBLKSAV corrected.
  TYPETCP  16.211  Support for TCP/IP 3.4 (sorta INCOMPATIBLE).
  TYPETCP  16.242  TCP SMF record subtype externalized  _SUBTCP5 macro.
  TYPETDTA 16.170  Support for NCR Teradata DBS performance data.
  TYPETMDB 16.097  Support for Landmark's Monitor for DB2 V 3.1 INCOMPA
  TYPETMDB 16.160  Support for Landmark's SQL/CAPTURE type 'D6' record.
  TYPETMO2 16.122  Variables SYSID,APPLID,SYSPLEX blank in MXG.
  TYPETMS5 16.088  Lost obs in TMS dataset DSNBRECD for Magstar tapes.
  TYPETMS5 16.129  Major revision of TMS/CA-1 processing logic.

  TYPETMS5 16.191  Final revisions to TMS logic changes for FILSEQ.
  TYPETMS5 16.251  TMS support for multi-dataset tapes now correct.
  TYPETMV2 16.212  TMON for MVS V2 variables wrong in TMVSSYS dataset.
  TYPETPMX 16.189  Enhanced TPM support reads all possible variables.
  TYPETPX  16.019  TPXBYTI/BYTO wrong due to CA's documentation error.
  TYPEVLFC 16.089  Zero observations in dataset TYPEVLFC corrected.
  TYPEVMXA 16.310  Support for VM/ESA 2.3 MTRSYS and USEACT segments.
  TYPEWWW  16.105  Support for Web Proxy logs Extended Common Log fmt.
  TYPEXCOM 16.114  XCOM variable REQTYPE renamed REQTYPEX, conflict.
  TYPEXCOM 16.187  Support for XCOM Release 3.0 (COMPATIBLE).
  USMFRATE 16.158  Analysis of SMF Write Rates (MEGABYTES at 10/100sec)
  UTILBHEX 16.070  Utility creates SMF records from hex dump from LIST;.
  UTILCICS 16.061  Incorrect Candle value ERRMQ=64 in CANMQ detected.
  VMAC7072 16.130  Type 70 records have CPU segment after VARY OFF.
  VMACIMSA 16.313  IMS 6.1 type 08 correction for APPC, CPIC driven.
  VMXGSUM  16.120  New ERASEOUT parameter added.
  VMXGSUM  16.131  UNIX forward slashed caused VMXGSUM to fail.
  VMXGSUM  16.146  VMXGSUM syntax for "DATETIME" now uses real name.
  VMXGSUM  16.179  Support for SAS Version 7 (INCOMPATIBLE).
  VMXGSUM  16.306  INHERIT (SAS V7 only) now exploited in VMXGSUM.
  VMXGSUM  16.306  INHERIT parameter used if under SAS Version 7.
  VMXGSUM  16.323  Correction after Change 16.271 &DATETIME=DATETIME;
  VMXGWORL 16.266  Sorted status now validated by SORT flag for _L data.
  WEEKBLDT 16.140  Weekly build of ASUMDB2B fails with wrong sort order.
  XMXGSUM  16.314  New function enhancements for VMXGSUM for testing.
  YEAR2000 16.330  MXG 16.09 now required for 100% YEAR2000 Support.


Inverse chronological list of all Changes:



  Look for additional changes in MXG 16.16 in member CHANGES.
  While this newsletter was being printed, changes may have been made.


Changes 16.222 thru 16.367 were printed in MXG Newsletter THIRTY-FIVE,
and are listed in member CHANGESS.

Changes 16.221 thru 16.001 were printed in MXG Newsletter THIRTY-FOUR,
and are listed in member CHANGESS.

****************NEWSLETTER THIRTY-FOUR**********************************










             MXG NEWSLETTER NUMBER THIRTY-FOUR October 1, 1998

Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE

                         TABLE OF CONTENTS                          Page

I.   MXG Software Version 16.04 is available upon request.             2
 1. MXG 16.04 is a major internal redesign of MXG, the new "MACKEEP"
II.   MXG Technical Notes                                              5
 1. Dropping or Removing variables from MXG datasets.                  5
 2. All variables formatted with MGBYTES are now stored in 8-bytes.    6
 3. OS/390 variable TYPETASK has values 'JOB','STC','TSU', for ....    7
 4. The MXG Tape Mount Monitor, MXGTMNT, does not see all VTS mounts.  7
III.  MVS Technical Notes                                              7
 1. APAR OW17469 corrects a problem with excessive SMF ID=80 records.  7
 2. APAR OW31598 for OS/390 2.4 is needed to correct JES2 type 26 SMF  7
 3. APAR PQ09932 for TCP/IP V3 SMF type 118 record corrects wrong byte 8
 4. APAR OW32140 reports increased CPU time for WLM functions if you   8
 5. Boole and Babbage CMF needs their PTF BPM6782 to correct an error  8
 6. APAR OW32935 (no PTF yet) will correct errors in RMF Reports where 8
 7. Boole & Babbage CMF creates incorrect LCUID values in type 78 data 8
 8. APAR OW32246 corrects subtype 6 Access Method Section variables    8
 9. PTF UW24057 for APAR ??????? was reported (via MXG-L) to have fix  8
10. NETSPY fix number #TM40410 is needed when you go from VTAM 4.3 to  8
11. APAR OW34123 for OS/390 Compatibility Mode corrects problems that  8
12. APAR OW18822 reports that the old 4-byte JESNR field (SMF26JNM)    8
13. APAR OW25609 reports a loss of type 30-2, type 23, and type 89 SMF 8
14. APAR OW33652 corrects the count of tape mounts in type 30 records, 9
15. APAR OW34055 corrects values in TYPE73 variables SMF73PBY/SMF73PTI 9
16. Activity counts of SSCH in TYPE74 for "inactive" devices found     9
17. APAR PQ18797 reports zeros in SMF type 115 MQ Series QMST section  9
18. To increase the maximum SMF Buffer Size from 32MB to 128MB         9
IV.   DB2 Technical Notes.                                             9
 1. APAR PQ15565 reports that after migrating to CICS 5.1.0 and after  9
V.    IMS Technical Notes.                                             9
VI.   SAS Technical Notes.                                             9
 1. Newsletter THIRTY-THREE, suggested using the /b operand on COPY    9
 2. SAS ZAP Z609E526 is required if you are on OS/390 1.2 or later.   10
 3. You can create a GIF file that can be FTP'd to your internet      10
 4. SAS under Windows 95 and 98 and NT earlier than 6.12 at TS045     10
 5. The SAS System Option VMCTLISA defaults to 160K internally        11
 6. SAS exploits multi-processors under Windows NT 4.0.               11
 7. MXG 16.04 QA stream has executed using the SAS Version 7 Beta     11
VII.  CICS Technical Notes.                                           11
 1. CPU increase from CICS Version 3 to Version 4 due to CICS trace.  11
VIII. Windows NT Technical Notes.                                     11
IX.   Incompatibilities and Installation of MXG 15.15.                12
X.    Online Documentation of MXG Software.                           12
XI. Changes Log                                                       12
     Alphabetical list of important changes                           13
     Changes 16.221 thru 16.001                                    14-68

      COPYRIGHT (C) 1998 MERRILL CONSULTANTS DALLAS TEXAS USA

I.   MXG Software Version Status.

     MXG 16.04 is now available, upon request.

 1. MXG 16.04 is a major internal redesign of MXG, the new "MACKEEP"
    architecture, which makes tailoring of MXG datasets simpler and more
    powerful.  You can change the output DDNAME for a large dataset with
    a simple "%LET Pdddddd=DDNAME;" statement, you can put all of your
    MXG changes in the single member IMACKEEP (instead of having to EDIT
    an IMACxxxx for each product), or you can even tailor MXG instream
    using the new "%LET MACKEEP = ;" logic, and never have to EDIT any
    members into your USERID.SOURCLIB!.  This redesign to externalize
    all attributes of every dataset began in MXG 10.10 with the "_L,_K"
    macros; now that the software is finally done, I can get back to the
    rewrite of MXG documentation (but note that member DOCMXG already
    exists to document the new architecture, with examples!).

    And most, if not all, of your existing MXG tailoring should still
    work without change!

            "MACKEEP" Architecture of MXG-built SAS "Datasets"
                         Highlights

            Everything about the creation of an MXG dataset is now
            fully externalized, and ALL MXG tailoring can now be done
            either by
               EDIT into a single member, IMACKEEP (instead of EDITing
               a separate IMAC for each product)
            or
               all tailoring can be done "instream" using the new syntax
                   %LET MACKEEP=   MACRO _oldname newvalue  %  ;

            All MXG datasets now have an &Pdddddd macro variable as the
            destination DDNAME/LIBREF, so you can use %LET Pdddddd=MYDD;
            in IMACKEEP or with MACKEEP to change the DD to which each
            MXG dataset is written or read from.

            See member DOCMXG, INSTALL, and Change 16.134 for details.

    Major enhancements added in MXG 16.04:

    MXG "MACKEEP" Architecture - see INSTALL, DOCMXG, Change 16.134.
    Support for OS/390 Release 2.6 (COMPATIBLE).
    Support for IMS Log processing for IMS 6.1.
    Support for TCP/IP 3.4 SMF type 118 (INCOMPATIBLE) changes.
    Support for NCR Teradata DBS performance data.
    Support for Landmark's SQL/CAPTURE Products 'D6' record.
    Support for XCOM Release 3.0 (COMPATIBLE).
    Support for Soft Audit's Installed Products File.
    Support for BGS I/O Monitor Version 5.1.0 (COMPAT).
    Support for HSM APAR OW31281 adds RECALL, DSR, FSR statistics.
    Support for DFSMS 1.4.0 added WFSCPUTM for ABARS CPU cost.
    Support for NTSMF CachingManager and Packet Filter objects.
    Support for NT Service Pack 5A SYSTEM/PROCESS fields.
    Major revision of TMS/CA-1 processing logic in TYPETMS5.
    ML-17 of MXGTMNT/ASMTAPES synchronizes automatically.
    Enhanced TPM support reads all possible variables in TYPETPMX.
    Analysis of SMF Write Rates (MEGABYTES at 10/100sec)
    MXG CONFIG value of VMCTLISA=40K raised to 160K.
    VMXGSUM syntax for "DATETIME" now uses real name.
    ABEND/CONDCODE in PDB.JOBS is now valid, has 1st ABEND.
    (MXG 16.03 was only released as a Beta.)

    Major enhancements added in MXG 16.02:

    Support for TYPEIMS7 for IMS 6.1.
    Support for OS/400 Version 4.2.0 COMPATIBLE.
    Support for MQ Series Version 1 Release 2 INCOMPATIBLE.
    Support for Landmark's Monitor for DB2 V 3.1 INCOMPATIBLE.
    Support for Candle Omegamon V400 CANMQ and CANWLMSC.
    Support for Candle Omegamon CICS V400 "255" record.
    Support for Raptor Systems' Eagle Firewall 121 Log.
    Support for TME 10 NetView for OS/390 V1 R1 SMF 38.
    Support for Web Proxy logs Extended Common Log fmt.
    Support for Magstar tapes in TYPETMS5 INCOMPATIBLE.
    &PDBxxxx and &yyyzzz "Dataset &Macro" naming rules.
    New PDB datasets TYPE74CO/ME/PA/SY/OM/LK added to daily PDB.
    New ANALABND report ABENDs from PDB.STEPS, uses PROC TABULATE.
    Multiple JES3 purge records created duplicate PDB.JOBS obs.
    All MXG variables with format MGBYTES are now stored in 8-bytes.
    New ANAL6264 merges VSAM type 62 and 64 for OPENTIME.

    Major enhancements added in MXG 16.01:

     The major thing in 16.01 is support for Year 2000 products that
     were not Y2K compliant when 15.15 was built, so MXG 16.01 is now
     the minimum level to support all vendor records that provide year
     2000 dates, but there are also a few fixes and several enhancements
     and new products supported.

    Year 2000 issues that require MXG 16.01 or the specific change:
      TYPE6 READTIME was 1900 in 2000 due to MXG error (Change 16.039).
      AS/400 Year 2000 Support was Incorrect (Change 16.035).
      NETVIEW NPM type 28 year Y2K Ready but INCOMPATIBLE record change.
      Landmark TMON for CICS V2 converted to V8.1 Y2K Ready, INCOMPAT.
      IPAC RDS View Direct V 6.1 Y2K Ready, but INCOMPATIBLE change.
      MXG Software now warrants it is "Year 2000 Ready".
    Support for new NTSMF objects (Database, SMTP Server, WEB Service).
    Support for revised NTSMF Active Server Pages and IISG records.
    Support for Software Engineering's SpaceManager data records.
    Support for DECnet/SNA DTF SMF records.
    MXG 15.15 problems reported and fixed:
      Variable MXGVERSN in TYPE70 was blank in 15.15; impacts CPEXPERT.
      Deactivated PR/SM Partition may cause over 100% CPU Busy for CEC.

  All of these enhancements are described in the Change Log, below.

    Availability dates for the IBM products and MXG version required:

                                       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 30  1996        14.05
      OS/390  1.3.0 Compatibility Mode Mar 28  1997        14.14
      OS/390  1.3.0 WLM Goal Mode      Mar 28  1997        15.02
      OS/390  2.4.0                    Sep 28  1997        15.06
      OS/390  2.5.0                    Feb 24  1998        15.06

      OS/390  2.6.0                    Sep 24  1998        16.04
      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 aka CICS/TS V1R1    Sep 10, 1996        14.07
      CICS-Transaction Server V1R1     Sep 10, 1996        14.07
      CICS-TS V1R1 with APAR UN98309   Sep 15, 1997        15.06
      CICS-TS V1R2                     Oct 27, 1997        15.06
      CRR 1.6                          Jun 24, 1994.       12.02
      CRR 1.7                          Apr 25, 1996.       14.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           Sep 11, 1996        14.07
      DB2 5.1.0 Tolerate               Jun 27, 1997        14.14
      DB2 5.1.0 Full support           Jun 27, 1997        15.02
      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
      DFSMS/MVS 1.4                    Sep 28, 1997.       15.04
      DFSMS/MVS 1.4 HSM                Sep 23, 1998.       16.04
      MQM 1.1.2, 1.1.3, 1.1.4          Apr 25, 1996.       14.02
      MQ Series 1.2.0                  May 26, 1998.       16.02
      NETVIEW 3.1 type 37              ??? ??, 1996.       14.03
      NPM 2.0                          Dec 17, 1993.       12.03
      NPM 2.2                          Aug 29, 1994.       12.05
      NPM 2.3                          ??? ??, 1996.       15.08
      RMDS 2.1, 2.2                    Dec 12, 1995.       12.12
      TCP/IP 3.1                       Jun 12, 1995.       12.12
      TCP/IP 3.4                       Sep 22, 1998.       16.04
      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
      IMS     4.1                      Aug  6, 1994        12.02
      IMS     5.1                      Jun  9, 1996        14.05
      IMS     6.1                      ???  ?, 199?        16.04
      AS400 3.7.0                      Nov  1, 1996        15.01
      AS400 4.1.0                      Dec 30, 1996        15.08
      AS400 4.2.0                      Apr 27, 1998        16.02

    Availability dates for non-IBM products and MXG version required:

                                       Availability     MXG Version
      Product Name                     Date or Change    Required

      Microsoft
       Windows NT 4.0 and NT 3.51                          14.14
       Windows NT 4.0 Service Pack 2                       15.03
       Windows NT 4.0 Service Pack 5                       16.04
      Demand Technology
       NTSMF Version 1 Beta                                14.11
       NTSMF Version 2.0                                   15.05
       NTSMF Version 2.1                                   15.06
      Landmark
       The Monitor for DB2 Version 2                       13.06
       The Monitor for DB2 Version 3.0                     16.02
       The Monitor for DB2 Version 3.1                     16.02
       The Monitor for CICS/ESA 1.2 -                      12.12
       The Monitor for CICS/ESA 1.3 -                      15.01
       The Monitor for CICS/ESA 2.0 -                      15.06
       The Monitor for MVS/ESA 1.3  -                      12.05
       The Monitor for MVS/ESA 1.5  -                      12.05
       The Monitor for MVS/ESA 2.0  -                      15.09

      Candle
       Omegamon for CICS V200 User SMF                     12.05
       Omegamon for CICS V300 User SMF                     13.06
       Omegamon for CICS V400 User SMF                     16.02
       Omegamon for CICS V400 type 110 segments            16.02
       Omegamon for IMS V110 (ITRF)                        12.12
       Omegamon for IMS V300 (ITRF)                        14.04
       Omegamon for MVS V300                               13.05
       Omegamon for MVS V400                               13.06
       Omegamon for DB2 Version 2.1/2.2                    13.05
       Omegamon for VTAM V160                              12.04A
       Omegamon for VTAM V400                              15.15
       Omegamon for SMS V100/V110                          12.03
      CA
       ACF2 6.2                                            16.04
       ASTEX 2.1                                           14.04
       NETSPY 4.7                                          14.03
       NETSPY 5.0                                          14.03
       NETSPY 5.2                                          16.05
      Boole & Babbage
       IMF 3.1 (for IMS 5.1)                               12.12
      Memorex/Telex
       LMS 3.1                                             12.12A


II.  MXG Technical Notes

 1. Dropping or Removing variables from MXG datasets.

    The only safe and the recommended method for removing variables from
    an MXG dataset requires tailoring of the "Keep" macro, _Kxxxyyy, for
    the dataset, which is defined in the IMACxxxx member for the
    product.

    If you define "MACRO _Kxxxyyy  DROP= A B C %"  those variables will
    be removed.  If you are keeping only a few variables from a dataset
    with many variables (like CICSTRAN), the DROP= list can be long, but
    you can mechanically copy the KEEP= list-of-variables from the VMAC
    member for that product into the _Kxxxyyy definition, change the
    KEEP= to DROP=, and then blank out the variables you WANT to keep.

    The use of a KEEP Statement in the EXxxxyyy exit member for the
    dataset is NOT safe, (nor would a DROP Statement be safe),  because
    the KEEP and DROP Statements are global to all data sets that are
    being created in that SAS data step, whereas the _Kxxxyyy macros are
    not KEEP/DROP Statements, but instead are the KEEP/DROP Dataset
    Options, so they apply only to a single dataset.

    The safety issue is that if you have two datasets being created
    that have common variables:
        DATA   CICS  (KEEP=A B C D E )
               IMS   (KEEP=A B C D E );
    and you add in a KEEP statement in the CICS dataset exit:
        KEEP A B C;
    then SAS will do what it is told, and variables D and E will be
    dropped from both the CICS and IMS datasets!

    It is true that if the variable names in your exit KEEP Statement
    are absolutely unique to the one data set in which you want them to
    be kept, you could use the KEEP statement in your EXxxxyyy member,
    but since I tend to use the same variable name for the same measure
    in different datasets, there is a high risk that you could
    inadvertently (and without any message on the log) drop existing or
    future new variables from other datasets.

    If you are dropping lots of variables, as from CICSTRAN, and if a
    new CICS version creates new variables that you want to drop, yes,
    you will have to change the _Kxxxyyy definition with each new
    version of CICS.  However, you do not have to have separate _Kxxxyyy
    definitions for both versions - you can have all of the variables
    that might be dropped in your DROP= list, and SAS will ignore those
    variables that don't exist, because MXG's CONFIG member sets OPTIONS
    DKROCOND=NOWARN; by default.

    While EDITing the IMACxxxx definition of the _Kxxxyyy macro into a
    "USERID.SOURCLIB" tailoring library in the //SOURCLIB concatenation
    is still a recommended technique (and vendors are authorized to
    distribute MXG IMACxxxx and EXxxxyyy tailoring members as part of
    their products), MXG 15.15 introduced the new &MACxxxx tailoring
    macros (as different from tailoring members) that now permit you to
    redefine the _K and _L macros "instream", without having to EDIT
    into a PDS library!

    And in the near future, those &MACxxxx tailoring macros will
    eventually allow you to also override the EXxxxyyy dataset exit
    member and even the default SORT order of every MXG dataset.

    The new &MACxxxx tailoring macros are documented in the text of
    Change 15.356, and because they are defined as macro variables
    instead of the old-style substitution macros, you may be able to use
    macro logic to select between different _Kxxxyyy macros definitions,
    if that were needed!

    There will be more documentation when the enhancements to the
    &MACxxxx tailoring macros is available.

 2. All variables formatted with MGBYTES are now stored in 8-bytes.

    The MGBYTES format converts a byte value into KB, MB, GB, TB, or PB
    (for PetaByte) and prints with the K/M/G/T/P as a suffix, with at
    most four significant digits (so a value of 4,294,967,296 bytes is
    printed as 4096M).  All variables formatted with MGBYTES actually
    still contain the number of bytes; the association of a FORMAT with
    a variable affects only its displayed value, not its internal value,
    and you can override any default format with FORMAT VARIABLE 17. ;
    and PROC PRINT it to see the full integer value.

    MXG stored these byte variables in only 4 bytes, to save DASD space,
    but values larger than 16,777,216 (the largest integer that can be
    exactly represented by SAS in 4 bytes) will be truncated by SAS.
    For example, the largest integer that can be held in 8 bytes is
    72,057,594,037,927,936, but when stored in 4 bytes, it truncates to
    72,057,589,742,960,640, a loss of 4,294,967,496 bytes.

    So with that value of 72x10**15 stored in 8 bytes, the MGBYTES
    format prints 64P (the 72 becomes 64 because of the six divides by
    1024 to convert bytes to 'kilo storage units'), but when stored in 4
    bytes, MGBYTES prints 63P, because the truncation lost 4096MB.

    As a result, and after consultation with users via MXG-L, I have
    decided to change ALL variables with MGBYTES format from 4-byte to
    8-bytes stored size, for the sake of accuracy and consistency.

    How will this impact you?  Some datasets will see a slight increase
    in the DASD needed to store them.  There were 2207 variables that
    were changed in several hundred datasets, but few datasets had more
    than 10 MGBYTES formatted variables, so I expect little real impact.
    However, I will update this note when I have measured the increases
    for both DASD and virtual storage in the BUILDPDB tests.

    If you use PROC APPEND but do not specify the FORCE operand, your
    PROC APPEND will fail when it tries to append datasets that have
    two different lengths for the same variable.  I have always strongly
    recommended that FORCE be specified if you use PROC APPEND just to
    avoid this exposure.  (In general, I don't recommend the use of
    PROC APPEND, because it destroys the sort order.)  I would suggest
    you scan your USERID.SOURCLIB and any report libraries of SAS code
    and add the FORCE operand now to avoid a problem in the future.

    See CHANGE 16.078 for specifics of the implementation.

 3. OS/390 variable TYPETASK has values 'JOB','STC','TSU', for jobs,
    started tasks, and TSO sessions, but both ASCH and OMVS records
    have TYPETASK='A  '.  You can use variable SUBSYS, because when
    TYPETASK='A', SUBSYS='ASCH' or SUBSYS='OMVS'.  Data set PDB.JOBS
    and all of the type 30 datasets contain this SUBSYS value; the
    type 6 and type 26 records contain SUBSYS='JES2' or 'JES3', so I
    cannot set TYPETASK equal to SUBSYS.  But you can PROC SORT by
    both TYPETASK and SUBSYS to separate ASCH from OMVS records.

 4. The MXG Tape Mount Monitor, MXGTMNT, doesn't see all VTS tape mounts
    for VTS (Virtual Tape Server) devices, because the elapsed duration
    of new, scratch mounts (which are satisfied by allocation on the
    "virtual" disk) frequently take much less than the 2 seconds
    sampling rate of MXGTMNT.  In the case studied, MXG missed about
    300 scratch mounts (out of a daily total of 1100 scratch mounts).
    While reducing the sampling rate will capture more of those mounts,
    to capture all VTS mounts would require a significant redesign of
    ASMTAPES: to capture the Mount Message and drive the mount record
    from that event, adding the duration data for those mounts that we
    saw with the two-second sampler but writing out a mount event when
    we see the mount messages even if we did not see the samples because
    the mount was too fast.  This enhancement is under study now but,
    will likely take significant time to implement, if even feasible!
    If you just need to count tape mounts for billing, counts in type 30
    (and hence PDB.JOBS and PDB.STEPS) variables TAPNMNTS/TAPSMNTS do
    include all VTS mounts (and there is a TYPE21 observation as well).

III. MVS Technical Notes.

 1. APAR OW17469 corrects a problem where excessive numbers of SMF ID=80
    RACF records were written.  The error was introduced by APAR OW02564
    and while APAR OW14521 corrects some of the error, this new APAR is
    also required.  The reporting site migrated from MVS 4.3 to 5.1.

 2. APAR OW31598 for OS/390 2.4 is needed to correct JES2 type 26 SMF
    records that have incomplete Accounting Segment.  The APAR seems to
    say this is a problem only if JES2 is running on OS/390 1.3 or below
    but was assembled with the OS/390 2.4 version of IAZSMF26.


 3. APAR PQ09932 for TCP/IP V3 SMF type 118 record corrects wrong byte
    count for Pascal FTP client. The TotalBytes field (MXG variable
    FTPBYTEC in dataset TYPETCPC) is truncated on the left if more than
    1MB in size (IBM reports 6.2 meg of storage transferred would be 0.2
    in the record!).

 4. APAR OW32140 reports increased CPU time for WLM functions if you
    have lots of CICS regions and are managing CICS transaction goals.
    One site with 337 Test CICS regions and 40 Production regions saw
    CPU time in the WLM address space jump to 4% of one box.  There is
    a PTF still in development as of April 8, 1998.  The overhead is
    proportional to the sum of the MAXTASK values across all regions,
    (because that's how many control blocks must be scanned by WLM code
    every 250 milliseconds, even for regions with no service goal).

 5. Boole and Babbage CMF needs their PTF BPM6782 to correct an error
    following a SET ICS command that caused a loss of type 70
    records.  Dec 2003:  The error included CPURCTTM being too high,
    which caused MXG's RMFINTRV  NEGATIVE UNCAPTURED-CPU-TIME message.

 6. APAR OW32935 (no PTF yet) will correct errors in RMF Reports where
    the velocity is wrong in duration reports (i.e., a two-hour report
    from 15 minute data) but is correct in the individual intervals.
    There is no error in the data records nor in MXG's calculation of
    velocity, only in the RMF duration reports for OS/390 1.3 and 2.4.
    This APAR also lists errors:  a.) R744CACH data sections contain
    negative values (which MXG will see as very large positive values),
    b.) Field R744CWMN in 74.4 record may be corrupted, and c.) Field
    SMF73CSC in 73 record contains interval start rather than interval
    end value.

 7. Boole & Babbage CMF creates incorrect LCUID values in type 78 data
    that are corrected by PTFs BPM6766 and BPB1195 for CMF 5.2.3.

 8. APAR OW32246 corrects subtype 6 Access Method Section variables
    S42AMSWB and S42AMSRB (SEQ Writes and SEQ Reads) to reflect the
    number of CI's written or read.

 9. PTF UW24057 for APAR ??????? was reported (via MXG-L) to have fixed
    a problem with very large I/O counts for DB2 address spaces in both
    TYPE30_V and TYPE72 datasets that showed up in occasional interval
    data.

10. NETSPY fix number #TM40410 is needed when you go from VTAM 4.3 to
    VTAM 4.4, something related also to TPX, to correct errors in the
    NETSPY SMF record that creates dataset NSPYLU.  Network counts and
    host and network response times were more often zero than not!

11. APAR OW34123 for OS/390 Compatibility Mode corrects problems that
    can prevent OS/390 from IPLing, if you have a low Maximum MPL set
    for the domain that contains your default STCs.  Some STCs that
    should have been marked Privileged were not (that's what the APAR
    corrects), like SMF, were swappable and with low MPL never came in.

12. APAR OW18822 reports that the old 4-byte JESNR field (SMF26JNM) may
    be non-zero and wrong when it should be zero.  Fortunately, MXG has
    no problem and does not require this APAR, since MXG has used the
    five or seven digit JES number in the JCTJOBID field, whether the
    old field is zero or not, since 99999 JES Number support was added.

13. APAR OW25609 reports a loss of type 30-2, type 23, and type 89 SMF
    records due to an error in serialization error with SMCALATE bits.

14. APAR OW33652 corrects the count of tape mounts in type 30 records,
    variables TAPNMNTS and TAPSMNTS, so that only real tape mounts are
    counted for SMS tapes.  IBM added the count of logical mounts (i.e.,
    when OPEN processing is entered with the tape drive in a ready state
    and with the mounted volume at the loadpoint), but then removed them
    for non-SMS tapes with APAR OW28289, but this new APAR is needed to
    also remove the logical mounts for ATL/MTL SMS tape volumes.

15. APAR OW34055 corrects values in TYPE73 variables SMF73PBY, SMF73PTI,
    and SMF73FG4 that were corrupted by APAR OW32935, which incorrectly
    made PBY and PTI values always zero.   Last note in MXG 16.03B4.

16. Activity counts of SSCH in TYPE74 for "inactive" devices were found
    to be the result of DCOLLECT and EREP; each run of DCOLLECT caused
    SIO74CNT of 11, each EREP run caused 4 I/O operations.

17. APAR PQ18797 reports zeros in SMF type 115 MQ Series QMST section,
    after PTF UQ14936, which is for CSQMLPLM, was installed.  MQ itself
    is working fine, it's just the statistics in the record are zero.

18. To increase the maximum SMF Buffer Size from 32MB to 128MB, and (of
    more significance) to increase the size of each increment from 1MB
    to 8MB, you need to install the PTFs associated with APAR OW12836.
    You get CICS messages "DFHMN0101 CICS COPYNAME SMF RC '0028'X" on
    the CICS log when CICS can't send CICS Monitor (i.e., transaction,
    a/k/a CICSTRAN, subtype 1 records) SMF records to the SMF Address
    Space, or messages "DFHST0103 CICS COPYNAME SMF RC '0028'X" when the
    CICS Statistics (subtype 2 records) cannot be sent to SMF Address
    Space.  This will happen during SMF buffer expansion, which is a
    serialized function under the single SMF TCB.  By increasing in a
    larger increment, there will be fewer buffer expansion lockouts and
    hopefully fewer lost SMF records.  I'll have more to say on the
    SMF Writer and SMF Buffers in a later technical note.


IV.  DB2 Technical Notes.

 1. APAR PQ15565 reports that after migrating to CICS 5.1.0 and after
    installing APAR PN55122, the DB2 type 101 SMF record no longer
    contains QWHCTOKEN, which contains the UOWID value that is decoded
    by MXG to create the NETSNAME and UOWTIME variables in DB2ACCT.
    This causes ASUMUOW to not work, since NETSNAME is blank and UOWTIME
    is missing, there's no UOW for summarization!

V.   IMS Technical Notes.


VI.  SAS Technical Notes.

 1. In Newsletter THIRTY-THREE, I suggested using the /b operand on COPY
    command to eliminate extraneous '3F'x characters, but that does not
    always work, and Dan Squillace and Kevin DeBruhl report why:

    Microsoft couldn't have made this more confusing if they tried.  /a
    and /b don't have anything to do with ASCII or binary per se, but
    instead whether EOF marks should be dropped or included from source
    files, or added to the destination files.  For source files,  the /a
    switch also indicates whether or not the copy operation for that
    file should stop when an EOF is encountered.

    SAS INFILE processing will stop when an EOF mark is encountered (a
    perfectly reasonable behavior!).

    The fix suggested in MXG Newsletter (putting /b on the copy command)
    worked with only one file, but caused EOFs to be inserted between
    concatenated files when copied in an NT 4.0 environment.  Specifying
    "copy /b source dest" can get you in trouble if source files are
    concatenated.  The following form of the copy command will fix the
    MVS problem plus eliminate the possibility of embedded EOFs in the
    concatenated file.

       copy /a f1.smf+f2.smf+f3.smf  bigfile  /b

    The  "/a" will cause the EOF mark to be removed from each of the
    source files "f1.smf through f3.smf" as they are concatenated into
    the destination file "bigfile".  The "/b" following the destination
    file "bigfile" ensures that an EOF mark is not appended to "bigfile"
    and subsequently transmitted to MVS.

    Note that the following syntax also gives the same result:

       copy /a  *.smf bigfile   /b

    Kevin and I have both spent time monkeying with this one.  We can't
    explain why NTSMF files sometimes have EOF marks on them and
    sometimes don't.  We also have observed apparently inconsistent
    behaviors on the part of the copy command.  The only thing we can
    assert with some confidence is that the copy commands given above
    results in no EOF marks and also results in a clean transmission to
    MVS with no embedded or trailing  '3F'x .

 2. SAS ZAP Z609E526 is required if you are on OS/390 Release 2 or later
    to prevent either an 0C4, a wait loop, or a CPU loop, as the error
    that is fixed by that zap can surface in several ways. Put it on!!!
    The error is caused by a subtask not terminating correctly.

 3. You can create a GIF file that can be FTP'd to your internet or your
    intranet for display by your browser from SAS/GRAPH with this code:

      //STEP1  EXEC MXGSASV9
      //GIF1   DD DSN=GIFFILE1,DISP=(,CATLG),SPACE=(CYL,(1,1)),
      //          UNIT=SYSDA,LRECL=132,RECFM=VB,BLKSIZE=26400
      //SYSIN  DD *
       GOPTIONS GSFLEN=128 DEVICE=GIF GSFNAME=GIF1 GSFMODE=REPLACE;
       PROC GPLOT .... ;

    Unfortunately, only one graph can be written to one "GIF" file; if
    the PROC GPLOT has a BY statement, only the first plot will be
    written to the GIF1 file.  For multiple plots, you will need
    multiple //GIFn DDs and a pair of GOPTIONS/PROC GPLOT statements
    with different GSFNAME to create a GIF file for each graph.

 4. SAS under Windows 95 and 98 and NT earlier than 6.12 at TS045 needs
    the FIBERFIX.EXE fix, at http:\www.sas.com/techsupp/download/pc.
    The fix is required if you have USB hardware on your PC, and also
    corrects a "memory leak" when hundreds of macros are executed (this
    error only showed up in my QA Stream, which I broke into four pieces
    to circumvent until I finally called SAS Tech Support.  The MXG QA
    Stream run with no errors under SAS 6.12 TS020 under both Windows
    98 Beta and the June Windows 98 release, once FIBERFIX was put on.
    FIBERFIX is included already in SAS 6.12 at TS045 or lager.

    Real Programmers know a "memory leak" is a "Programming error".


 5. The SAS System Option VMCTLISA defaults to 160K internally, but one
    site that had overridden and specified VMACLISA of only 40K received
    an 0C4 in function VMZGMAE with SAS 6.09/TS405; the 0C4 disappeared
    when VMCTLISA was raised to 60K.  Note that to see the value of the
    VMCTLISA option you must use PROC OPTIONS APF; syntax.  VMCTLISA is
    the "Size of the Initial Storage Area for SAS System Control Blocks"
    and is an MVS-only option.

 6. SAS exploits multi-processors under Windows NT 4.0.  On a Compaq
    Proliant 5000 with two 200 MHz Pentium II processors, a QA stream
    took exactly 100 minutes.  On a single 350MHz clone under Windows 98
    it took 114 minutes.  The ratio of 400 to 350 is 1.14, so it sure
    looks like SAS was using both CPUs in the 2x200 multi-processor!
    (Okay, the Compaq had two SCSI, the 350 had Fast IDE disks, it
    was NT versus 98, so maybe all of the ratio was not just CPUs, but
    it still looks awfully good for SAS's exploitation for this test!)
    (For comparison, the old QA stream with fewer steps used to take
    over 300 minutes on an 3090-400s!, and this QA stream on OS/390
    on a 9672R52 box takes 150 minutes.)

 7. MXG 16.04 QA stream has executed using the SAS Version 7 Beta, under
    OS/390, Windows 95/98 and Windows NT.  Minor changes were needed in
    MXG code, mostly to circumvent Beta things that SAS will have fixed
    by the Production release this fall.  A complete list will be in a
    future MXG Technical Note when Version 7 is available.
    Initial performance measurements of the MXG QA stream show no change
    in the runtime between Version 6.12 TS045 and Version 7 Beta, so
    it looks like lots of new features a no cost, for a change!

    SAS Version 7 datasets cannot be read by SAS Version 6; the format
    of SAS data libraries on all platforms was changed incompatibly.
    Fortunately, MXG will not exploit on any SAS Version 7 features in
    the near future, and there are no compelling reasons to migrate to
    SAS Version 7 (run times and resources were about the same), but
    when you do migrate to SAS V7, you will either have to drop it in
    all at once, or at least you will need to install from the back end:
    convert your report programs first and then convert the programs
    that build the datasets that the reports use.


VII. CICS Technical Notes.

 1. A site running CICS Version 3 that recorded one hour CPU time per
    day in TYPE72 for the region saw that CPU time jump to 6 hours per
    day when they migrated to CICS Version 4, but the CICSTRAN data did
    not show an increase per transaction.  The culprit turned out to be
    that the trace options 1,2, and 3 had been specified for CICS TRACE
    parameters STNTRXM and STNTRAP without observed problem in CICS V3,
    but IBM warns in GC33-1161-02 Page 639 that level 3 is for IBM FE's,
    and in SC33-1176-00 page 219 that there is performance overhead with
    trace levels. (Pubs are Release Guide for CICS 4.1 and CICS Problem
    Determination Guide).  Turning off the TRACE saved the 6 hours!

VIII. Windows NT Technical Notes.

   There are no Windows NT Technical Notes in this Newsletter.


IX.   Incompatibilities and Installation of MXG 16.04.

 1. Incompatibilities introduced in MXG 16.04 (since MXG 15.15):

  a- IMACs that were changed (if they exist in your USERID.SOURCLIB, you
     must refit your tailoring, starting with the new IMAC member):

      IMACPDB - new PDB.STEPS/PDB.JOBS CONDCODE.   Change 16.106

  b- Other incompatibility changes:

     All MGBYTES formatted variables are now length 8, instead of 4.
     If you use PROC APPEND without FORCE, SAS will ERROR when you try
     to combine new and old datasets with dissimilar length variables.

  c- These products were incompatibly changed by their vendor, and they
     require MXG Version 16.01 as indicated:

     MXG Y2K support for AS/400                MXG 16.01  Change 16.035
     CA-1/TMS TYPETMS5 with Magstar drives     MXG 16.02  Change 16.088
     LANDMARK CICS V2 recs convert to V8.1     MXG 16.01  Change 16.049
     LANDMARK DB2 V 3.1                        MXG 16.02  Change 16.097
     MQ Series V1 R2 SMF 115 MQMLOG dataset    MXG 16.02  Change 16.099
     MXG Y2K support for Type 6 SMF record     MXG 16.01  Change 16.039
     NETVIEW NPM (Year 2000 dates)             MXG 16.01  Change 16.003
     NTSMF EXCHANGE 5.5                        MXG 16.01  Change 16.024

 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.


X.    Online Documentation of MXG Software.

    MXG Documentation is now described in member DOCUMENT.


XI.   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 is normally
 created after the newsletter is sent to the printer!  Member CHANGES
 on the www.MXG.com homepage are the most timely, as they are updated
 (sometimes) between MXG versions.

 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 15.15 now in MXG 16.01:

  Dataset/
  Member   Change    Description

  Many     16.078  MXG variables with format MGBYTES are now 8-bytes.
  Many     16.068  &PDBxxxx and &yyyzzz "Dataset &Macro" naming rules.
  ANAL6264 16.071  Analysis merges VSAM type 62 and 64 for OPENTIME.
  ANALABND 16.082  ABEND stats from PDB.STEPS, uses PROC TABULATE.
  ANALCISH 16.104  MORE THAN 32767, MORE THAN 10 errors corrected.
  ANALPATH 16.006  SUBSCRIPT OUT OF RANGE, report expected 10 LCUs max.
  ANALSRVC 16.098  Report now works for CPU Percent by Service Class.
  ANALUOW  16.075  Enhancements, DB2 Class 3 waits. etc were added.
  ANALVTS  16.162  Analysis combines 30s, TMNT, TALO and 21s for tapes.
  ANANCNCR 16.206  COUNT= option corrected.
  ASMIMSL5 16.058  ASMIMSL5 in MXG 15.15 failed during assembly.
  ASMIMSL6 16.185  Support for IMS Log processing for IMS 6.1.
  ASMTAPES 16.154  ML-17 of MXGTMNT synchronizes automatically.
  ASMTAPES 16.164  MXGTMNT misses too-fast VTS tape mounts.
  ASUM42DS 16.046  New summary member for TYPE42DS by dataset.
  ASUM70PR 16.028  Deactivated Partition may cause over 100% CPU Busy.
  ASUMCACH 16.141  DURATM in ASUMCACH revised for accuracy.
  ASUMCICS 16.137  INVALID ARGUMENT TO FUNCTION SQRT when N=1.
  ASUMTALO 16.076  Revised to work with TALO records from old ASMTAPES.
  ASUMTALO 16.169  SPIN.SPINTALO now backed up into PDB library.
  BLDNTPDB 16.180  NTSMF Daily/Weekly/etc BUILD program enhanced.
  BUILDPD3 16.080  JES3 BUILDPDB - Multiple PDB.JOBS obs - multi purges.
  BUILDPDB 16.008  Duplicate TYPE30_V records might not be deleted.
  BUILDPDB 16.107  PDB.TYPE74CO/ME/PA/SY/OM/LK added to day/week PDB.
  BUILDPDB 16.183  ABEND/CONDCODE in PDB.JOBS now valid, has 1st ABEND.
  CONFIG   16.066  Option SASAUTOS=(SOURCLIB SASAUTOS) is now used.
  CONFIG   16.117  CODEPCT=150 now set to eliminate SAS message.
  CONFIG   16.157  MXG CONFIG value of VMCTLISA=40K raised to 160K.
  CONFIG   16.209  NOSTIMER now specified, SAS 6.12 TS045 changed.
  DOCGRAF  16.018  Examples of getting graphs from mainframe to your PC.
  DOCMXG   16.134  New &MACKEEP and IMACKEEP MXG architecture changed.
  IMACFILE 16.016  &MACFILE macro added for instream tailoring.
  IMACICDM 16.067  Support for Candle Omegamon V400 CANMQ and CANWLMSC.
  IMACPDB  16.106  Enclave CPU time and count added to PDB.STEPS/JOBS.
  MXGSAS   16.081  JCL parameter TAILORNG now spelled TAILOR.
  TRND70   16.021  TRENDing of TYPE70 now supports 16 buckets of CPUs.
  TRND72GO 16.029  Variable R723CIMP in TRND72GO SUMmed vice IDd.
  TYPE110  16.031  CICS UNEXPECTED STID=0 was error in STID=94 segment.
  TYPE110  16.153  GMT offset calculation in CICS off by up to 1.4 secs.
  TYPE115  16.099  Support for MQ Series Version 1 Release 2 (INCOMPAT).
  TYPE28   16.003  NETVIEW NPM type 28 INCOMPATIBLE year 2000 change.
  TYPE30   16.150  TYPETASK='ASCH' or TYPETASK='OMVS' now set in PDB.
  TYPE38   16.101  Support for TME 10 NetView for OS/390 V1 R1 SMF 38.
  TYPE6    16.039  READTIME in TYPE6 and hence PRINT is 1900 in 2000.
  TYPE7072 16.009  Variable MXGVERSN in TYPE70 was blank in 15.15.
  TYPE7072 16.194  Delay Percents now divided by R723CTSA.
  TYPE72GO 16.064  Variables AVGRESP, EXETTM, AVGXETTM added/changed.
  TYPE72GO 16.083  Variables R723CQDT/CADT/CCVT/CIQT wrong multiplier.
  TYPE74   16.032  NO STRUCTURE MATCH message understood and eliminated.
  TYPE74   16.095  TYPE74 variable IORATE changed to match IBM's RMF.
  TYPE94   16.135  VTS variables SMF94VBA/VLA were mis-documented by IBM
  TYPE99   16.026  New subtype 6 SMF type 99 INVALID SERVER SECTION.
  TYPEBGSI 16.155  Support for BGS I/O Monitor Version 5.1.0 (COMPAT).
  TYPECIMS 16.030  ABENDUSR in CIMSPROG has never been right.
  TYPEDB2  16.148  Dataset DB2STATR was invalid, duplicate observations.
  TYPEDCOL 16.017  DCOLLECT DSORG field expanded to 3 in MXG (PSU etc).
  TYPEDECS 16.034  Support for DECnet/SNA DTF SMF records.
  TYPEEAGL 16.102  Support for Raptor Systems' Eagle Firewall 121 Log.

  TYPEHSM  16.136  DFSMS 1.4.0 added WFSCPUTM for ABARS CPU cost.
  TYPEHSM  16.145  Support for APAR OW31281 adds RECALL, DSR, FSR.
  TYPEHSM  16.149  SHORT ABAR message after Change 16.025 fixed.
  TYPEIDMS 16.002  New TASNxxx variables labels were incorrect.
  TYPEIDMS 16.012  IDMS 10.2.1 caused INPUT STATEMENT EXCEEDED.
  TYPEIDMS 16.033  IDMS 10.2 records were not output.
  TYPEIMS7 16.119  Support for TYPEIMS7 for IMS 6.1.
  TYPEIMSA 16.069  ASMIMSL5 process now has _L, _K macros, exit members.
  TYPEIPAC 16.052  Y2K INCOMPATIBLE IPAC RDS 6.1 user SMF record.
  TYPEMON8 16.049  Y2K Support for TMON V2 records converted to 8.1.
  TYPEMON8 16.073  INVALID DATA FOR TMMDMODL message corrected.
  TYPEMON8 16.091  TMON for CICS V2 Converted records MONIRECD='D'.
  TYPENDM  16.060  Sterling's Connect Direct aka NDM PI=754129 open.
  TYPENSPY 16.147  NETSPY='N' record support was restored for old 4.4.
  TYPENTSM 16.024  Support new "Database" object and EXCHANGE 5.5.
  TYPENTSM 16.045  Support for IISG, Active Server Pages, Web Service.
  TYPENTSM 16.049  New SNA LU, SNA 3270 Response, etc, NTSMF objects.
  TYPENTSM 16.121  Support for NTSMF Cache Mgr & Packet Filter objects.
  TYPENTSM 16.133  Summarization of NETWSEGM into NTINTRV wrong if two.
  TYPENTSM 16.177  Support for NT Service Pack 5A SYSTEM/PROCESS fields.
  TYPENTSM 16.199  NTSMF Object='WidetoMBErr' explained.
  TYPENTSM 16.208  Support for NTSMF internal 0.1 configuration record.
  TYPEOMCI 16.116  Support for Candle Omegamon CICS V400 "255" record.
  TYPEQAPM 16.035  Year 2000 Support for AS/400 was corrected.
  TYPEQAPM 16.063  Support for OS/400 Version 4.2.0 (COMPATIBLE).
  TYPESFTA 16.175  Support for Soft Audit's Installed Products File.
  TYPESPMG 16.020  Support for Software Engineering's SpaceManager data.
  TYPETAND 16.118  Tandem variables CnBLKS and CnBLKSAV corrected.
  TYPETCP  16.211  Support for TCP/IP 3.4 (sorta INCOMPATIBLE).
  TYPETDTA 16.170  Support for NCR Teradata DBS performance data.
  TYPETMDB 16.097  Support for Landmark's Monitor for DB2 V 3.1 INCOMPA
  TYPETMDB 16.160  Support for Landmark's SQL/CAPTURE type 'D6' record.
  TYPETMO2 16.122  Variables SYSID,APPLID,SYSPLEX blank in MXG.
  TYPETMS5 16.088  Lost obs in TMS dataset DSNBRECD for Magstar tapes.
  TYPETMS5 16.129  Major revision of TMS/CA-1 processing logic.
  TYPETMS5 16.191  Final revisions to TMS logic changes for FILSEQ.
  TYPETPMX 16.189  Enhanced TPM support reads all possible variables.
  TYPETPX  16.019  TPXBYTI/BYTO wrong due to CA's documentation error.
  TYPEVLFC 16.089  Zero observations in dataset TYPEVLFC corrected.
  TYPEWWW  16.105  Support for Web Proxy logs Extended Common Log fmt.
  TYPEXCOM 16.114  XCOM variable REQTYPE renamed REQTYPEX, conflict.
  TYPEXCOM 16.187  Support for XCOM Release 3.0 (COMPATIBLE).
  USMFRATE 16.158  Analysis of SMF Write Rates (MEGABYTES at 10/100sec)
  UTILBHEX 16.070  Utility creates SMF records from hex dump from LIST;.
  UTILCICS 16.061  Incorrect Candle value ERRMQ=64 in CANMQ detected.
  VMAC7072 16.130  Type 70 records have CPU segment after VARY OFF.
  VMXGSUM  16.120  New ERASEOUT parameter added.
  VMXGSUM  16.131  UNIX forward slashed caused VMXGSUM to fail.
  VMXGSUM  16.146  VMXGSUM syntax for "DATETIME" now uses real name.
  VMXGSUM  16.179  Support for SAS Version 7 (INCOMPATIBLE).
  WEEKBLDT 16.140  Weekly build of ASUMDB2B fails with wrong sort order.
  YEAR2000 16.010  MXG Software now warrants it is "Year 2000 Ready".

Inverse chronological list of all Changes:



======Changes thru 16.221 were in MXG 16.04 dated Sep 30, 1998======

Changes 16.221 thru 16.001 were printed in MXG Newsletter THIRTY-FOUR,
and are listed in member CHANGESS.

****************NEWSLETTER THIRTY-THREE*********************************










             MXG NEWSLETTER NUMBER THIRTY-THREE February 23, 1998

Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE

                         TABLE OF CONTENTS                          Page

I.   Annual MXG Software Version 15.15 shipped with this Newsletter.   2
II.   MXG Technical Notes                                              6
 1. Measurement of CPU Utilization in PR/SM,MDF,MLPF environments.     6
 2. FAT32 file system reduces MXG space needed from 139MB to 68MB.    11
III.  MVS Technical Notes.                                            11
 1. APAR OW25609 corrects a stoppage of SMF type 30 interval recs.    11
 2. APAR OW28289 changes counts in type 30 TAPNMNTS/TAPSMNTS vars.    11
 3. APAR OW28613 corrects errors in the JES2 Type 26 Purge record.    12
 4. APAR OW28256 reports invalid CPU times in RMF CPURCTTM.           12
 5. APAR OW26619 for OS/390 V2.4, in Goal Mode corrects WLM errors.   12
 6. APAR OW26421 for OS/390 V1.3 is needed only for ASMTAPES.         12
 7. SYNCSORT 3.6 can ABEND 0C9 in a PROC SORT; SYNCSORT fix SY49930.  12
 8. APAR OW30153 corrects type 30 Measured Usage (MULC) segments.     12
 9. APAR OW30059 (PTF available 12Dec97) reports type 42 errors.      13
10. APAR PQ09396 (Target 26Dec97) for MQSERIES SMF type 116.          13
11. APAR PQ09083 for subtype '51'x of the FTP SMF record (VMACFTP).   13
12. Job Accounting for Started Tasks is available with MVS/ESA 5.1.   13
13. What happens to measurements in a Y2K Test System in an LPAR?     13
14. Almost-Duplicate TYPE74 records, differing only by one second.    14
15. Channel Type variable CHANTYPE in dataset TYPE73 still exists.    14
16. APAR OW27855 corrects PSF/MVS-written type 6 SMF records.         14
17. APAR OW20844 enables JES2 job numbers greater than 32000.         14
IV.   DB2 Technical Notes.                                            14
V.    IMS Technical Notes.                                            14
 1. Support for Boole's IMF 3.2 (for IMS 6.1) added in MXG 15.09.     14
 2. Discussion of IMS Log support in MXG Software.                    14
VI.   SAS Technical Notes.                                            15
 1. There are no MXG problems using Version 6.09 of the SAS System.   15
VII.  CICS Technical Notes.                                           15
 1. You can use USER instead of TERMINAL to bill CICS transactions.   15
VIII. Windows NT Technical Notes.                                     16
 1. Use  /B "Binary" switch on the COPY command to eliminate '3F'x.   16
IX.   Incompatibilities and Installation of MXG 15.15.                16
X.    Online Documentation of MXG Software.                           17
XI. Changes Log                                                       17
     Alphabetical list of important changes                           17
     Changes 15.382 thru 15.207                                    21-64

      COPYRIGHT (C) 1998 MERRILL CONSULTANTS DALLAS TEXAS USA

           =====    What's Really Hot in MXG 15.15    =====

   The really big features in MXG, aside from the hundreds of new
   software product versions that are now supported, PTFs, etc,
   are the externalization of the DDname for each PDB dataset into
   &PDByyyy macro variables, for ease in tailoring BUILDPDB, and the
   &MACxxxx macro variables now defined in each VMACxxxx member that
   permit you to re-define the _L and _K macros that are defined in the
   IMACxxxx members in your USERID.SOURCLIB; now you can change the IMAC
   tailoring library macro definitions on the fly, without an EDIT!
   See the text of Changes 15.356 and 15.320 for full details.

   Not all of the externalization of the IMACxxxx tailoring has been
   delivered in MXG 15.15.  I am still developing _Syyyyyy SORT macros
   for each dataset, and _Eyyyyyy exit macros to override the EXyyyyyy
   dataset exit members, and will then replace the hardcoded PROC SORTs
   in BUILDPDB with their corresponding _Syyyyyy macro, but that's still
   work in progress.

   More ADOCxxxx members exist now, but most new ones have only DOCVER's
   short contents.  However, now I can implement automatic update of new
   variables in each ADOC member, preserving other documentation in each
   member, and will expand the documentation to include the member that
   creates each data set, sort order, etc., as time permits.

   See member CHANGES in MXG 15.15 for any last minute additions after
   the newsletter printing and the software building, or better still,
   see the CHANGES section of our homepage, www.MXG.com, which is always
   the first place to look for MXG Software status.  While you are there
   please subscribe to the MXG-L ListServer; it is my primary method of
   software announcements, and many fine technical discussions among MXG
   users have occurred on MXG-L (you can read them from the archives!).
           ================================================




I.   Annual MXG Software Version 15.15 was shipped to all sites,
     along with the printed copy of MXG Newsletter THIRTY-THREE,
     during the last week of February, 1998, by US Air Mail.

 1. Major enhancements added in MXG 15.15 dated 23Feb1998:

   Support for OS/390 Release 2.5 (no changes, need 15.04 or later).
   Support for AIX commands IOSTAT/PSSTAT/VMSTAT output into SAS.
   Support for StorageTek's VSM SMF records subtypes 9 thru 25.
   Support for IDMS Journal format for IDMS V12.
   Support for Boole's IMF 3.2 (for IMS 6.1) INCOMPATIBLE
   Landmark TMON for CICS V2 variables renamed.
   Landmark for MVS V2 INPUT STATEMENT EXCEEDED.
   New &MACxxxx macro variable added to all VMACs to override IMACs.
   All VMACs for SMF records now start with IF ID=....

    Major enhancements added in MXG 15.08 dated 15Jan1998:

   Support for Netview NPM Version 2.3 and APAR OW17876.
   Support for AS/400 - OS/400 Release 4.1.0 (INCOMPATIBLE).
   Support for IICS SMF type 103 (Internet Connection Secure Server).
   Support for RMF type 79 subtype 15 (IMS IRLM Long Lock) record.
   Hardcoded "PDB." DDname externalized into &PDBxxxx macro variables.
   ASUMUOW option to get real TRANNAME instead of CPMI/CSMI tranname.
   Performance improvements in BUILDPDB (_CDE's ordered, ELSE DOs).
   New _Sxxyyy "PROC SORT" macros defined for PDB datasets in IMACs.

    Major enhancements added in MXG 15.07 dated 18Dec1997:

   Support for DPPX/370 Performance Reporter output.
   Support for MODEL204 Version 3.4 INCOMPATIBLE.
   Support for SAR CA-VIEW SMF exit SARSRQUX.
   Support for Omegamon for VTAM V400 (COMPATIBLE).
   Support for Landmark the Monitor for MVS Version 2 (INCOMPATIBLE).
   Support for SAR CA-VIEW SARSRQUX SMF record.
   Support for Fujitsu's AIM V20 AIM/RDBII SMF type 98 record.
   ASMTAPES ML-15 adds dump suppression, OS/390 1.3 JCT changes.
     (MXG 15.06 said it contained ML-15, but actually still had ML-14).
   VELOCITY variables are now multiplied by 100.

    Major enhancements added in MXG 15.06 dated 24Nov1997:

   Support for CICS Transaction Server 1.2, INCOMPATIBLE.  IBM inserted
      new fields in the middle of CICSTRAN record, so you must install
      MXG 15.06 or later for CICS TS 1.2 processing.  New statistic data
      is also captured; see Change 15.274.
   Support for Landmark's The Monitor for CICS/ESA 2.0, INCOMPATIBLE.
   CICS TS V1.1 APAR UN98309 INCOMPATIBLE,  Must install MXG 15.06.
   Support for NTSMF Version 2.1 (INCOMPATIBLE), install MXG 15.06.
   CICINTRV logic validated, must use this newest revision.
   Duplicate CICS UOWTIME values due to SAS non-resolution of DATETIMEs.
   Support for Subtype 11 Type 88 System Logger.
   Support for Applied Expert Systems Clever TCP/IP.
   Support for HP MeasureWare for Terra Data OS.
   Support for DFSORT APAR PN71137 (COMPATIBLE).
   Support for HP MeasureWare for Terra Data OS in TYPEMWTE.
   Support for Boole & Babbage MQ Series MVMQS VSAM History Records.
   OS/390 R2.4 Goal Mode IBM Doc Error INVALID DATA R723CIDT fixed.
   New IHDR110 exit for CICS record selection by APPLID.
   Utility to recreate VBS from data with no RDW/BDW.
    Major enhancements added in MXG 15.05 dated 02Oct1997:

   Support for JES3 TYPE26 APAR OW26297 adds account fields.
   Support for APPC APAR OW16975 APAR-in-Error (INCOMPATIBLE).
   Support for 255 Structures in a Coupling Facility (INCOMPAT).
   Support for CA's IDMS 14.0 (INCOMPATIBLE).
   Support for BETA93 Release 1.3 (INCOMPATIBLE) (subtype 21 only).
   Support for SMF type 91 new subtype 21 (SmartBatch) data.
   Support for TCP/IP 3.2 API Calls record changes.
   Duplicate MULTIDD='Y' step records may not be deleted in BUILDPDB.
   Catalog SMF Type 65 record INPUT STATEMENT EXCEEDED corrected.
   PDB.ASUMUOW options externalized, zero obs now created by default.
   DB2 Trace 102 subtype 140 INPUT STATEMENT EXCEEDED.
   Iceberg / IXFP subtypes 2,3,4 not output, MXG 15.02-15.04 only.
   TYPE70 variable PCTMVSBY incorrect in MXG 15.01-15.04.

   Major enhancements added in MXG 15.04 dated 01Sep1997:

   MXG 15.04 Software is now over one million lines (1,008,660)!

   MXG now protects ALL date fields for year 2000.
   Support for OS/390 Version 2 Release 4 (COMPATIBLE).
   Support for "Goal Mode SMF" type 99 subtype 6.
   Support for DCOLLECT in DFSMS 1.4 (COMPATIBLE)
   Support for VTAM 4.4 changes to SMF type 50.

   Support for CA-1/TMS Release 5.2 (COMPATIBLE).
   Support for ObjectStar 3.0 (INCOMPATIBLE in MXG).
   Support for Xerox's XPSM Version 2 SMF records.
   Support for HMF SMF Subtype 11 (DS3 Statistics).
   Support for five new NTSMF Objects.
   Support for VM ADSM Account Records in VM/ESA.
   Support for TMON/DB2 record type "DE".
   Support for Boole MainView for CICS stat records.
   Support for Catalog Cell 'E7'(Alias) and invalid '05'x segment.
   Support for RACFEVNT=22 and 59 in TYPE80A.
   Support for Shared Medical CICS Journal OASMON records.
   Support for Peregrine's Service Center SMF record.
   Table of Holidays for SHIFT example added in IMACSHFT.

   Major enhancements added in MXG 15.03 dated 30Jun1997:

   Support for NTSMF Version 2.0 (INCOMPATIBLE; 15.02 was not correct).
   Support for Windows NT 4.0 Service Pack 2 (INCOMPATIBLE also).
   Support for IXFP SMF subtypes 6 and 7 (SNAPSHOT, SPACE UTILIZATION)
   Support for TYPE1415 APAR OW25263 (for 3590s).
   Support for TYPE42 APAR OW26451/OW26543/OW26497 MAXRSPTM added.
   Support for TYPE42 APAR OW20921 adds TYPE42VT VTOC/VVDS counts.
   Support for OMVS RACF data with RACF utility IRRDBU00.
   Support for new fields in TYPEEDGR DFSMSrmm extracts.
   ASMTAPES at ML-14 populates fields, protects 0C4 ABENDs better.
   RMFINTRV now allows Report RPGNs/Classes to be used in IMACWORK.
   Format MGBYTRT (Bytes per Second) can truncate value on the left.
   BUILDPDB enhanced to rename WORK.STEPS for IT Service Vision.
   Leap second support for type 30, 110, and 100-102 "GMT" conversion
   Trending for TYPE72GO into TREND.TRND72GO added.
   ANALCNCR Example counts Avg & Max Logged-ON TSO users from PDB.JOBs.

   Major enhancements added in MXG 15.02:

   Support for DB2 Version 5.1 (MXG 14.14 tolerates, COMPATIBLE!!)
   Support for Filetek's Optical Disk SMF record
   Support for OMVS data in RACF database (IRRDBU00 unload)
   Enhancements to VMXGSUM for OBS=0 processing
   Replacement for MXG 15.01's defective CICINTRV.
   ASMTAPES Technical Note updated - cause of 0C4 is now known.

   Major enhancements added in MXG 15.01:

   Errors in MXG 14.14 that are fixed in MXG 15.01:

   ASMTAPES (ML13) is available, recovers from 0C4s, see MXG Tech Notes.
   WORK.CICINTRV.DATA DOES NOT EXIST.
   OS/390 R3 Goal only: Type 72 INPUT STATEMENT EXCEEDED RECORD LENGTH.
   FILE counts in TYPETMON were incorrect before and after 14.14.

   New Support in MXG 15.01:

   ANALDDCN to analyze impact of DDCONS(NO) on duplicated SMF bytes
   TYPEIMSD for IMS DBCTL transactions from IMS 07/08 log records
   SMFPRM00 with first draft of MXG discussion for SMF parameters
   Support and exploitation of new TALO fields added by ASMTAPES ML-12.
   Support for APAR OW25152 (adds PRINTWAY Queue Name to TYPE6).
   Support for Altai's ZARA Tape Management Release 1.2
   Support for Anacom's Anastack spooler's type 6 SMF
   Support for Boole and Babbage IMF 3.2.
   Support for CA-DISPATCH Version 6 with 5-digit JESNR
   Support for CA-ROSCOE Version 6 SMF record verified.
   Support for COMPAQ hardware NTSMF objects.

   Support for Hitachi 7700 changes to TYPE74CA/CACHET90 (INCOMPAT)
   Support for Landmark's Performance Works/Smart Agents for UNIX 4.0
   Support for MEMO subtype 8 creates new MEMODIST dataset.
   Support for NETSPY Version 5.0 is already in MXG 14.14
   Support for Virtual Tape Server additions to SMF type 94
   Support for World Wide Web Common Log Format records.
   Support for all OS/400 Release 3.7.0 records.
   UDUMPEBC utility for MVS-like LIST; hex dump under ASCII systems.

  All of these enhancements are described in the Change Log, below.

    Availability dates for the IBM products and MXG version required:

                                       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 30  1996        14.05
      OS/390  1.3.0 Compatibility Mode Mar 28  1997        14.14
      OS/390  1.3.0 WLM Goal Mode      Mar 28  1997        15.02
      OS/390  2.4.0                    Sep 28  1997        15.06
      OS/390  2.5.0                    Feb 24  1998        15.06
      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 aka CICS/TS V1R1    Sep 10, 1996        14.07
      CICS-Transaction Server V1R1     Sep 10, 1996        14.07
      CICS-TS V1R1 with APAR UN98309   Sep 15, 1997        15.06
      CICS-TS V1R2                     Oct 27, 1997        15.06
      CRR 1.6                          Jun 24, 1994.       12.02
      CRR 1.7                          Apr 25, 1996.       14.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           Sep 11, 1996        14.07
      DB2 5.1.0 Tolerate               Jun 27, 1997        14.14
      DB2 5.1.0 Full support           Jun 27, 1997        15.02
      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
      DFSMS/MVS 1.4                    Sep 28, 1997.       15.04
      MQM 1.2, 1.3, 1.4                Apr 25, 1996.       14.02
      NETVIEW 3.1 type 37              ??? ??, 1996.       14.03
      NPM 2.0                          Dec 17, 1993.       12.03
      NPM 2.2                          Aug 29, 1994.       12.05
      NPM 2.3                          ??? ??, 1996.       15.08
      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
      IMS     4.1                      Aug  6, 1994        12.02
      IMS     5.1                      Jun  9, 1996        14.05
      AS400 3.7.0                      Nov  1, 1996        15.01
      AS400 4.1.0                      Dec 30, 1996        15.08

    Availability dates for non-IBM products and MXG version required:
                                       Availability     MXG Version
      Product Name                     Date or Change    Required

      Microsoft
       Windows NT 4.0 and NT 3.51                          14.14
       Windows NT 4.0 Service Pack 2                       15.03
      Demand Technology
       NTSMF Version 1 Beta                                14.11
       NTSMF Version 2.0                                   15.03
       NTSMF Version 2.1                                   15.06
      Landmark
       The Monitor for DB2 Version 2                       13.06
       The Monitor for DB2 Version 3                       15.03
       The Monitor for CICS/ESA 1.2 -                      12.12
       The Monitor for CICS/ESA 1.3 -                      15.01
       The Monitor for CICS/ESA 2.0 -                      15.06
       The Monitor for MVS/ESA 1.3  -                      12.05
       The Monitor for MVS/ESA 1.5  -                      12.05
       The Monitor for MVS/ESA 2.0  -                      15.09
      Candle
       Omegamon for CICS V200 User SMF                     12.05
       Omegamon for CICS V300 User SMF                     13.06
       Omegamon for IMS V110 (ITRF)                        12.12
       Omegamon for IMS V300 (ITRF)                        14.04
       Omegamon for MVS V300                               13.05
       Omegamon for MVS V400                               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
      CA
       ASTEX 2.1                                           14.04
       NETSPY 4.7                                          14.03
       NETSPY 5.0                                          14.03
      Boole & Babbage
       IMF 3.1 (for IMS 5.1)                               12.12
      Memorex/Telex
       LMS 3.1                                             12.12A


II.  MXG Technical Notes

 1. Measurement of CPU Utilization in PR/SM,MDF,MLPF environments.

   This note was written for ACHAP10, "Processor Utilization".

   The ASUM70PR dataset is built from the TYPE70PR detail data using
     %INCLUDE SOURLIB(ASUM70PR);   as shown in JCLPDB6 example.  There
   is one observation in ASUM70PR from each MVS SYSTEM for each RMF
   Interval, and that observation describes the utilization of each of
   the LPARS, and their sum, which is the hardware busy of the platform.
      If you have multiple MVS Systems, and if you process their SMF
      data together, then duplicate data will exist in ASUM70PR, since
      SYSA's type 70 record will describe all LPARs, and SYSB's type 70
      will also describe all LPARs, so you must select only one set of
      observations (from SYSA or from SYSB) to avoid duplication.

   For each partition, the Partition Dispatch Time and the Effective
   Dispatch Time (and their difference, the CPU time when this partition
   was dispatched for LPAR management of this partition) are recorded.
   There is also a "pseudo" partition named "PHYSICAL" that exists only
   in the RMF type 70 record that records the LPAR management dispatch
   time that could not be charged to a specific partition.

                  Schematic of ASUM70PR observation

                 Total Partition Dispatch (CPU) Time
      CPUACTTM= LPnUPDTM summed for all real partitions + LPPUPDTM

                              CPUACTTM
    ______________________________________________________________


        LPAR #1         LPAR #2        LPAR # 3       "PHYSICAL"
      LP1UPDTM        LP2UPDTM        LP3UPDTM         LPPUPDTM
      Dispatched      Dispatched      Dispatched       Dispatched
    _______________ _______________ _______________ ______________

         LP1UEDTM        LP2UEDTM        LP3UEDTM
          LPAR1           LPAR2           LPAR3
         Effective       Effective       Effective


    __              __              __              ______________

     1               2               3                "Physical"
   LP1MGTTM        LP2MGTTM        LP3MGTTM           LPPUPDTM
     In-partition LPAR Management Time            Unassigned LPAR time

      Important variables in PDB.ASUM70PR dataset:

      LPnUPDTM  - Partition Dispatch Duration for LPAR n.
      LPnUEDTM  - Partition Effective Dispatch Duration for LPAR n.
      LPnMGTTM  - LPnUPDTM minus LPnUEDTM, this partition management.
      LPPUPDTM  - Physical partition dispatch duration.
      PARTNCPU  - Number of engines in this platform.
      PCTCPUBY  - Percent CPUs were Busy in all LPARS, equal to the sum
                  of all partition's (including PHYSICAL) dispatch time,
                  minus HiperDispatch Parked Time, divided by the Total
                  "capacity" of all ONLINE, NON-PARKED engines:
                  100*CPUACTTM/(NRCPUS*DURATM).  This is the percent
                  of the total capacity of the box that was used.  If
                  the Average NRCPUS is 5.5, and CPUACTTM was 4 hours
                  in a one hour interval, PCTCPUBY would be 72% busy.
      PCTLnBY   - Percent "Physically" Busy in LPAR n, equal to the LPAR
                  Dispatch time divided by the Total "capacity" of all
                  engines in the box:  100*LPnUPDTM/(PARTNCPU*DURATM).
                  If an LPAR was dispatched for 1 hour, and the CEC has
                  5 engines, then PCTLnBY for that LPAR would be 20%,
                  because that LPAR used 20% of the hardware platform.
      PCTLnOV   - Percent "Physically" Busy in "LPAR Overhead" in this
                  LPAR, 100*LPnMGTTM/(PARTNCPU*DURATM).
      LPnNRPRC  - Number of engines available to LPAR n.
      LPnDUR    - LPAR n's "Up time" or "Availability time to execute
                  CPU", the sum of DURATM across all LCPUs in LPAR n,
                  or LPnDUR=LPnNPRC*DURATM.  This is the duration when
                  this LPAR could have been dispatched.  If the LPAR was
                  IPL'd as a 3-engine MVS machine, in one hour, it would
                  have 3 hours of "Up Time" (or 3 hours of "capacity").
      LPCTnBY   - Percent "Logically" Busy in LPAR n, equal to the LPAR
                  Dispatch time for the partition divided by the LPAR's
                  "Up Time", 100*LPnUPDTM/LPnDUR.  If a 3-engine LPAR
                  was dispatched for 60 minutes in one hour, its LPCTnBY
                  would be 33%.  This variable describes the percent of
                  LPAR capacity, in contrast to variable PCTLnBY which
                  describes the percent of Hardware Platform capacity.
                  If that same 3-engine LPAR was executing on a 5-engine
                  CEC, PCTLnBY would be 20%, because that LPAR used 20%

                  of the hardware platform, while LPCTnBY is 33% of the
                  CPU time available to this LPAR.
      LPnCAP    - 'Y' if this partition is capped.
      LPnCHG    - 'Y' if something changed in LPAR n.
      LPnDED    - 'Y' if this partition has all-dedicated-CPUs.
      LPCTnOV   - Percent "Logically" Busy in "LPAR Overhead"
                  100*LPnMGTTM/LPnDUR, describes how much of the
                  Dispatch Duration was for management of this LPAR.

      Important variables in PDB.TYPE70PR dataset:

      LPARNUM   - Logical Partition Number, = PARTISHN in TYPE70 dataset
      LCPUPDTM  - Partition Dispatch Time
      LCPUEDTM  - Partition Effective Dispatch Time

    The following example is real data from a 5-engine CEC (Central
    Electronic Complex, the preferred name for a platform).  This CEC
    has three LPARs: LP1 has two engines (and is lightly used), LP2 has
    five engines, and LP3 has three engines.  All CPUs are shared and
    Wait Completion is No.  One hourly observation in ASUM70PR showed:

             PARTNCPU  5          - Number of real engines in CEC
             DURATM    1:00:00.05 - Duration interval
             CPUACTTM  4:40:35.32 - Total CPU Dispatch, all engines
             CPUOVHTM    15:35.40 - Total CPU Overhead in LPARS
             LPPUPDTM     6:40.28 - Total "Physical" Overhead
             PCTCPUBY  93.53%     - CPUACTTM as a percent of hardware
             PCTOVHD    5.20%     - CPUOVHTM as a percent of hardware
             PCTPOV     2.22%     - LPPUPDTM as a percent of hardware

                          LP1            LP2            LP3
             LPnNRPRC     2              5              3
             LPnDUR       2:00:00.10     5:00:00.25     3:00:00.15
             LPnUPDTM        4:49.67     3:33.06.54       55:58.85
             LPnUEDTM        2:56.63     3:29:16.51       52:46.77
             LPnMGTTM        1:53.03        3:50.02        3:12.07
             LPCT1BY      4.02%          71.04%         31.10%
             LPCT1OV      1.57%           1.28%          1.78%
             PCTL1BY      1.61%          71.04%         18.66%
             PCTL1OV       .63%           1.28%          1.07%

             The LP2 has the same PCTL2BY as LPCT2BY because it can use
             all five engines, and its logical and physical utilization
             are the same.  The LP3, with only three engines available
             to its MVS, shows it is using 18.66% of the five hardware
             engines (PCTL3BY), while LPCT3BY shows that this actually
             is 31.1% of the CPU time possible for those three logical
             CPUs available to LP3.

    The dispatch time measurements in ASUM70PR are always accurate in
    describing the total platform busy and each LPARs use of the total,
    because when an LPAR is dispatched, its processors are not available
    to any other LPAR, and thus ASUM70PR does report platform capacity.

    Furthermore, if all CPUs are shared and Wait Completion is No, the
    ASUM70PR dispatch duration is the actual CPU busy time, so not only
    is the total platform capacity known, but also the utilization of
    individual LPARs is measured in ASUM70PR.


    The problem arises when CPUs are Dedicated to an LPAR, or when Wait
    Complete = Yes is used, because the dispatch time in those cases is
    NOT equal to the CPU executing time.  While a dispatch time of one

    hour does mean that one hour of total platform capacity was used by
    an LPAR, (i.e., not available to other LPARs), the actual CPU time
    used by that LPAR may be a lot less than one hour.  What we need is
    the Wait time measured inside each MVS system, which is in the MVS
    TYPE70 dataset, but each type 70 record only has a single TYPE70
    segment (for the LPAR in which this MVS System executed); we do not
    get a TYPE70 segment for the other LPARs.  But MXG does store the
    MVS Wait Time from the TYPE70 segment into variable ORIGWAIT in the
    TYPE70PR observation for each LCPUADDR, which shows this data:


    Wait Complete = YES example:  System SYSC (LPARCPUS=2 PARTNCPU=4)

                            LPARNUM=PARTISHN=2
                LCPU=0                           LCPU=1
             DURATM=15 min                    DURATM=15 min
     --------------------------------- -------------------------------

          8 min             7 min                15min
     -------------------- ------------ -------------------------------
       Dispatched          LPAR Wait          Dispatched
       LCPUPDTM 70PR         calc             LCPUPDTM 70PR

       5 min      3 min     7 min           11 min             4 min
     ---------- ========= ------------ --------------------- =========
      ORIGWAIT   BUSY      LPAR Wait      ORIGWAIT             BUSY
        70       calc        calc            70                calc


    This LPAR has two LCPUs, Wait Complete=Yes, but due to the other
    LPAR on this platform (that was also using Wait Complete=Yes), the
    LCPU=0 was dispatched for only 8 minutes of the 15 minute interval,
    while LCPU=1 was dispatched for all 15 minutes.  The ORIGWAIT from
    TYPE70 shows that LCPU=0 was actually CPU Busy for only 3 minutes,
    and LCPU=1 was actually CPU Busy for only 4 minutes.

    While there are only two LCPUs for this LPAR, this LPAR is in a
    platform that has four engines, so the ASUM70PR calculation is:
        PCTL2BY = (8 disp +  15 disp )/ (4*15) = 23/60 = 38%
    because 38% of the dispatch capacity of the four engines in the
    hardware platform was consumed by this LPAR in this interval.

    However, RMF in its CPU Activity Report calculates two percentages
    (and MXG replicates in both TYPE70 and TYPE70PR data):

    PCTCPUBY = "LPAR Busy Time" = (3 busy + 4 busy) / (2 * 15)   = 23%

    PCTMVSBY = "MVS Busy Time"  = (10 busy+lparwait + 4 busy)/30 = 48%

    The "LPAR Busy Time" shows that this LPAR was busy for 7 of the 30
    minutes that the two engines in the LPAR could have been executing,
    and thus is a measure of how busy the MVS system might have been.

    However, the "MVS Busy Time" calculated by IBM is at best confusing
    and at worst wrong, for Wait Completion = Yes LPARs, because it
    calculates the MVS busy time as DURATM minus ORIGWAIT, adding the 3
    minutes busy and 7 minutes of LPAR wait from LCPU=0 to the 4 minutes
    busy from LCPU=1 to conclude 14 minutes of "busy time" out of the
    30 minutes that the two engines could have been executing, for 48%!

    But the MVS SRM never saw those possible 30 minutes of execution; it
    was dispatched for only 8 + 15 = 23 minutes, so a far more accurate
    measure is "SRM Busy Time", the busy time over the dispatched time:


    PCTSRMBY = "SRM Busy Time" = (3 busy + 4 busy) / 23 (dispatch) = 30%

    which more accurately reflects what MVS can do with Wait Comp=Yes,
    and it strongly suggests that the IBM "MVS Busy Time" is wrong for
    Wait Comp=Yes.

       (The example used the Partition Dispatch times, but to be
        slightly more precise, using the Effective Dispatch times would
        show what was delivered to MVS.  I am still deciding if I should
        create a new variable for PCTSRMBY, but want to send this
        preliminary note to MXG-L, so I will update this part of this
        note at a later date.)


    Dedicated example:  System SYSA (LPARCPUS=3 PARTNCPU=4)
                        LCPU=0   Dedicated, Wait=No
                        LCPU=1,2 Shared, Wait=No

                            LPARNUM=PARTISHN=5
           LCPU=0
      DURATM=15 min                          DURATM=15 min
     ---------------------         ------------------------------------
                                                 LCPU=1
      14:59.20                      5:48.92         8:25.73   0:45.35
     ---------------------         =============== --------- ----------
      Dispatched                    Dispatched      ORIGWAIT  Non-Disp
      LCPUPDTM 70PR                 LCPUPDTM 70PR     70      Non-Wait
                                     BUSY                      calc

                                                 LCPU=2
      3:11.51    11:48.49           5:49.20         8:25.41   0:45.39
     ---------- ==========         =============== --------- ----------
      ORIGWAIT     BUSY             Dispatched      ORIGWAIT  Non-Disp
        70         calc             LCPUPDTM 70PR      70     Non-Wait
                                     BUSY                       calc


    For all the three LCPUs in this LPAR, MXG calculates in ASUM70PR:
      PCTL5BY = 100* ( 26.5 / 4*15) = 100 * 26.5 /60  = 44.37%
    because the total dispatch time of the three LCPUs was 26.5 minutes
    of the possible 60 minutes of dispatch time in the four engines of
    the platform, and this is this LPAR's use of dispatch capacity.

    But if we have the TYPE70PR observation from the system that has the
    ORIGWAIT measurement from TYPE70 for that dedicated LCPU, we can see
    the LPAR's total CPU busy time was only 11:48 + 5:48 + 5:49, or 22.5
    minutes, since 3 minutes of that dispatch time was in MVS wait time!

    The IBM RMF calculations for each LCPU and the total for all three
    LCPUs in this LPAR show:

        LCPU  PCTCPUBY   (calc)     PCTMVSBY   (calc)       Status
         0     78.72   (11:48/15)    78.72   (11:48/15)    Ded,Wait=No
         1     38.77   ( 5:48/15)    43.81   ( 6:33/15)    Shr,Wait=No
         2     38.80   ( 5:49/15)    43.84   ( 6:34/15)    Shr,Wait=No
        all    52.10   (23:17/45)    55.46   (24:55/45)    Combined

    For the Dedicated LCPU, both PCTCPUBY and PCTMVSBY are calculated
      PCTCPUBY=PCTMVSBY= 100*(DURATM-ORIGWAIT)/DURATM  = 78.7%
      PCTMVSBY=PCTCPUBY= 100*(DURATM-ORIGWAIT)/DURATM  = 78.7%

    For the Shared, Non-Wait LCPUs, the "LPAR Busy Time" is
      PCTCPUBY= 100*LCPUPDTM/DURATM = 38.7%
    but the IBM calculation for the "MVS Busy Time" is
      PCTMVSBY= 100*(DURATM-ORIGWAIT)/DURATM = 43.8%
    because the PCTMVSBY value includes the 45 seconds of non-dispatched
    non-wait time recorded in the MVS Busy Time calculation!

    Again, while PCTCPUBY is legitimate, PCTMVSBY raises more questions
    than it answers.

    To summarize what percentages are printed where by IBM and reported
    where by MXG, on RMF CPU Activity Report, the "LPAR Busy Time Perc"
    is variable PCTCPUBY, and the "MVS Busy Time Perc" is variable
    PCTMVSBY in dataset TYPE70 (and now in TYPE70PR as well).  On RMF's
    Partition Data Report, IBM's "Logical Processors Total" is variable
    LPCTnBY, and IBM's "Physical Processors Total" is PCTLnBY in dataset
    ASUM70PR for each LPAR, and the "Physical Processors Total" is the
    variable PCTCPBUY in ASUM70PR.

    Note:  I intend to revise this note as I learn more, especially for
    Millennium and/or MDF, in the near future.  The purpose of this
    much of the note was to document what is calculated by MXG and by
    IBM when you try to compare RMF reports to MXG datasets, and to
    point out basic problems if you have Dedicated or Wait Comp = YES.
    Not only is there a problem in ASUM70PR in that we do not know the
    true CPU busy time, we also have assumed the "capacity" was the
    DURATM of the interval, but that is not always the case, especially
    when LPAR weighting is taken into account.  No single percentage
    value can be used, as it depends on your perspective.  ASUM70PR
    reports usage percentages of the "dispatch" capacity, while TYPE70
    still must be used to understand what is happening inside each MVS.

 2. FAT32 file system reduces space needed for MXG from 139MB to 68MB.

    On Windows 95 and Windows NT with FAT File Systems, the MXG Source
    Library directory DIR command shows 3549 files totaling 57.7 MB,
    but the files in that directory actually required 139.1 Megabytes
    of disk space!  The 2GB disk drive with 32K cluster size wastes
    space if the file is less than 32KBytes, and as only 272 of MXG's
    source files are over 32K in size, the other 3277 small files waste
    lots of disk space with large cluster size under FAT file systems.

    Well that is a dead problem with the newer FAT32 file system that
    virtually eliminates the space waste problem.  That same source
    library required only 68.23 MegaBytes on a 9GB FAT32 disk drive!


III. MVS Technical Notes.

 1. APAR OW25609 corrects a stoppage of SMF type 30 interval records
    (subtypes 2 & 3) and type 23 records, after a serialization problem.
    The APAR applies to MVS/4.3 thru OS/390 2.4.

 2. APAR OW28289 changes counts in type 30 variables TAPNMNTS/TAPSMNTS
    (SMF30PTM/SMF30TPR).  In DF/SMS 1.2 and earlier, tape mount counts
    were the number of physical mounts (actually, a count of volumes
    that were verified by OPEN/CLOSE/EOV via a loadpoint read of the
    VOL1 tape label).  That was changed by an SPE to DF/SMS 1.2.0 (which
    was included in DF/SMS 1.3.0 and 1.4.0); IBM decided instead to
    count logical volumes (i.e., increment the mount count when OPEN
    processing is entered with the tape drive in a ready state and with
    the mounted volume at loadpoint).  A document change was prepared
    but never distributed, and now IBM is backing out the SPE's effect,

    and with this APAR, the counts revert to physical mount counts.  The
    APAR's text is confusing, because it lists PTFs for DF/SMS releases
    1B0, 1C0, and 1D0, which turn out to be DFSMS 1.2, 1.3, and 1.4,
    respectively.  If you depend on the count of tape mounts in type 30
    records, you will want to apply this PTF.

 3. APAR OW28613 corrects errors in the JES2 Type 26 Purge record in the
    SMF26OAG Accounting Section offset.  I earlier thought MXG would not
    fail, but without that APAR, MXG offset validation was insufficient,
    an INPUT STATEMENT EXCEEDED occurs.  Now, Change 15.330 circumvents
    the wrong value for SMF26OAG, but the ACCOUNTn fields in TYPE26J2
    will be blank until you install to APAR to correct IBM's error.
    Fortunately, MXG only uses the TYPE26J2 ACCOUNTn fields for jobs
    that do not produce type 30s (JCL Errors or Cancel before start).

 4. APAR OW28256 reports invalid CPU times measured (once again!) in RMF
    type 72 field SMF72RCT (MXG Variable CPURCTTM, which is summed into
    variable CPUTM); PTF was available November 14 1997.  This causes
    the total CPU time captured in type 72 records to exceed the total
    CPU busy time, causing the Uncaptured CPU time (misnamed as CPUOVHTM
    and labeled as "Overhead") to be negative in RMFINTRV.  This same
    field was in error in 1992, fixed then by APAR OY51878.  MXG now
    detects the negative value and prints this error message on the log:
      "ERROR. NEGATIVE CPU-UNCAPTURED-TIME (TYPE70-TYPE72)".
    See text of Change 15.238 for more details.

 5. APAR OW26619 for OS/390 V2.4, in Goal Mode corrects WLM errors found
    by IBM during final function test, and corrects SMF values.

 6. APAR OW26421 for OS/390 V1.3 is needed only for ASMTAPES. In OS/390
    IBM created two 4-byte fields for Y2K support to replace the 3-byte
    fields JCTSSD and JCTJMRJD (step and job start/init dates), but I
    missed that change, so ASMTAPES still used the 3-byte fields.  But
    IBM also zeroed the 3-byte fields, which caused INVALID DATA when
    TYPETMNT was executed, and variable INITTIME has missing value.
    This APAR restores the dates in the 3-byte fields, so INITTIME will
    not be missing.  The next maintenance level of the MXG ASMTAPES will
    avoid the exposure by using the 4-byte fields if they are present.

 7. SYNCSORT 3.6 can ABEND 0C9 during a PROC SORT; SYNCSORT fix SY49930
    is the correction.

 8. APAR OW30153 corrects type 30 Measured Usage (MULC) segments.  There
    are multiple occurrences of the same product name and qualifier for
    PRODNAME=CICS PRODQUAL=DFHKETCB in the interval records that should
    have had only a single segment.  There are still other errors that
    are not addressed in creating the subtype 4 and subtype 5 records
    from the interval records.  One CICS job had 39 DHFKETCB segments in
    its interval records (subtype 2 and 3), but had 37 segments in its
    step termination record (subtype 4) and then had only 36 segments in
    its job termination record (subtype 5).  Further, the job had 12
    DFHSIP segments in the interval records but had 16 segments in both
    step and job terminate.  Finally, the job had 2 DFHDUP segments in
    the job term but none in either the interval or step term records.
    A new problem has been opened with IBM on this error.
    Note that old APAR OW16176, which consolidates MULC sections for
    each product, should be installed.  Increasing SMF buffers with
    APAR OW12836 is also recommended to minimize the problems with SMF
    buffers, and especially specification of DDCONS=NO in SMFPRMxx in
    SYS1.PARMLIB is strongly recommended to eliminate the SMF address
    algorithm to consolidate DD segments.

    Note added Dec 30, 1997:
    APAR PN80497 corrects a problem after applying UN84065 with Measured
    Usage (MULC) that can create millions of type 30 subtype 3 records
    with the same product name in the MULC segment.  The problem
    occurred with an IMS BMP that used MQ Series.  The excess records
    could cause IEE979W SMF DATA LOST - NO BUFFER SPACE AVAILABLE.

 9. APAR OW30059 (PTF available 12Dec97) reports type 42 values for
    Direct Write and Direct Read SMF42DWB/SMF42DRB and this APAR is
    likely the fix that was originally described in note 26 in MVS
    Technical Notes in MXG Newsletter THIRTY-TWO for APAR OW20926.
    When the channel program did single CI reads and writes, residual
    data was left in the counter that was not used.

10. APAR PQ09396 (Target 26Dec97) for MQSERIES SMF type 116 reports
    inconsistencies between 115 and 116 record's statistics. The more
    elaborate description (this text added Mar 27, 1998): The numbers
    MQGET and MQPUT (MXG Variables QMACGETx and QMACPUTx in MQMACCT
    dataset from 116 record) are significantly less than the totals
    reported from 115 records, because the data fields containing the
    116 records were incremented outside of latch control, which led
    to the counts being cleared at the same time they were updated,
    causing certain of the counts to be lost.  The PTF for this APAR
    will update the fields containing the totals of MQI requests via a
    CS instruction, hence they will be protected from being cleared
    whilst being updated.

11. APAR PQ09083 is for subtype '51'x of the FTP SMF record (VMACFTP).
    The text mentions SMF Record Type 51, but there is no type 51 SMF
    record (yet).  The APAR corrects missing values in variables
    DVGSETME/DVGSEDTE in dataset FTP51X.

12. Job Accounting for Started Tasks became available with MVS/ESA 5.1,
    because you can now have a JOB card in the JCL for your STC's, and
    can put ACCOUNT parameters in that JOB card that show up in MXG's
    ACCOUNTn variables in PDB.JOBS/PDB.PRINT/PDB.STEPS datasets.  The
    JCL Reference Manual Sections 7.2, 7.3, and 16.7 discuss how.

13. What happens to measurements if I have a Y2K Test System in an LPAR?

    You can use the ASUM70PR dataset and select the observations from
    your production LPAR (SYSTM='PROD') to measure the Y2K Partition's
    resources, since the STARTIME of the records with SYSTEM='PROD'
    will be your local time of day.

    All of the records written on SYSTEM='Y2K' will have the year 2000
    dates (although the READTIME value could be earlier if jobs were
    read into the hold queue before IPLing with year 2000).  Since the
    Y2K system will be re-IPL'd repetitively with the same start value
    (probably 31DEC99:23:45:00), RMF interval data will appear to have
    duplicate data and the jobs/steps from all IPLs will be jumbled
    together, because MXG sorts RMF data by STARTIME and job data by
    READTIME.

    You can extract SYSTEM='Y2K' data for a specific "test run" by
    finding the record number (_N_) of each SMF IPL record, using:
       %INCLUDE SOURCLIB(VMACSMF);
       DATA _NULL_;
       _SMF;
       IF ID=0 THEN PUT 'IPL RECORD FOUND ' _N_= SMFTIME=;
    and then use the record number of the specific IPL to select only
    the SMF records desired.  If you wanted the third run, and the third
    IPL record had _N_=8,000 and the next IPL record had _N_=10,000, you
    would use this logic:
       %INCLUDE SOURCLIB(VMACSMF);
       DATA _NULL_;
       _SMF;
       FILE SMFOUT DCB=SMF;
       IF 8000 LE _N_ LE 9999 THEN PUT _INFILE_;
       IF _N_ EQ 10000 THEN STOP;
    to write to //SMFOUT DD only those records for that test run.

    There is an alternative.  You can use the IPL PROMPT feature to
    require the operator to reply with the (local) time and the reason
    (describe the test run) for each IPL, and there will be a SUBTYPE=8
    observation in dataset TYPE90 with variables DTIME and IPLREASN with
    the operator's reply, so the TYPE90 dataset can be used to identify
    the records in each test run (variable SMFRECNR, equal to _N_, was
    added to the TYPE90 dataset by Change 15.267).
    You must have specified PROMPT(IPLR) or PROMPT(ALL) in member
    SMFPRMxx in SYS1.PARMLIB dataset to prompt the operator for the
    reply at each IPL.

14. Almost-Duplicate TYPE74 records, differing only by one second in the
    STARTIME, can be written by Boole & Babbage's CMF Product, if both
    IPM and CPM modes are enabled.  This has happened recently as sites
    installed OS/390.  In MXG's TYPE7xxx datasets, variable PRODUCT will
    be 'CMF-IPM' in one almost-duplicate record, and 'CMF-CPM' in the
    other observation.  Boole does NOT recommend both modes!

15. Channel Type variable CHANTYPE in dataset TYPE73 still exists, but
    variable SMF73CPD provides a better description as it describes both
    ESCON and Parallel Channel types.  SMF73CPD was new in MVS/ESA 5.1.

16. APAR OW27855 corrects PSF/MVS-written type 6 SMF records so that
    they now contain the node number of the current node in field
    SMF6ROUN, which MXG decodes into variable NODE and RMOTID in TYPE6
    dataset.

17. APAR OW20844 enables JES2 job numbers greater than 32000, but has
    no impact on MXG, since MXG has supported 5-digit JES Numbers thru
    99999 from the JCTJOBID for several years.

IV.  DB2 Technical Notes.

 1. There are no DB2 Technical Notes in this newsletter.

V.   IMS Technical Notes.

 1. Support for Boole's IMF 3.2 (for IMS 6.1) was added in MXG 15.09.
    Candle has not informed me of any changes in their ITRF product.

 2. Discussion of IMS Log support in MXG Software.

    I strongly recommend you use an IMS monitor (was Boole or Candle)
    IMF from BMC, Mainview for IMS from ASG, ITRF from IBM/Candle)
    that creates a transaction record, rather than attempt to use
    IBM's IMS log for transaction response and resource measurement.

    See MXG newsletter TWENTY-FIVE, IMS Technical Notes, for the MXG
    position statement of the technical reasons why you cannot measure
    the response time and resources (CPU, DL/I calls) for transactions
    with only IBM's standard IMS log records.

    However, you CAN use the TYPEIMS7 MXG program to get accurate counts
    of transactions and resources by transaction, because it uses IMS 07
    and IMS 08 log records, written for each deschedule of an IMS
    program, which contains the count of IMS transactions that were run
    during that program schedule (can be 1, usually is at least 5
    transactions per schedule, and be millions for WFIs), the
    transaction name, and the total CPU time and DL/I calls for all
    of those IMS transactions.  But you cannot get accurate resources
    per transaction from the IMS 07/08 records.  At best, you can get
    the "average" of each group of transaction processed if you are
    willing to divide the CPU time by the number of transactions run,
    and you'll get fractional numbers of DL/I calls per transaction!

    MXG Member TYPEIMFL will read the IMS log and will select and create
    all possible datasets from any combination of Boole's IMF log
    records (LCODE=FAx) IBM IMS log records (01,03,07,08,31x,36x,40x,
    plus fastpath 59x subtypes 01,03,36x,37x,38x) and SAP IMS log
    records (LCODE=AEx), and the new statistics subtypes as well.
    Members TYPEIMFL and TYPEIMS7 both use macros that are defined in
    VMACIMS to decode those IMS log records, and which are fully
    supported by MXG.

    It is not the reading of the IMF, IBM, and SAP IMS log records that
    is the problem, but rather it is the construction of the
    many-records-per-transaction-without-a-merge-key into a single
    transaction record with per-transaction resources and response that
    is in principle impossible with IMS log records.

    Nevertheless if you still must try to get IMS response time with
    only IBM's IMS log records, because your management still won't buy
    you an IMS monitor tool, then, at your own risk, you can probably
    get good results with the MXG assembly program ASMIMSL6 (IMS 6+) and
    the JCLIMSL6 example.  The ASM program acts like an IMS MPR and
    reads the log to figure out which records go with which transaction,
    and writes a copy of the IMS log records with an appendage to
    identify the transaction, and then the MXG SAS programs invoked in
    JCLIMSLG read the extended IMS log records to crate dataset IMSTRAN
    with observations on a per-transaction basis.  These transaction
    records will always contain only average CPU and DL/I calls, but the
    response time for each transaction is usually quite accurate,
    although a few transactions may not be perfectly matched and can
    have very large response times (and sometimes the output queue time
    is accurately very large!).  It is not guaranteed that ASMIMSL6 will
    exist, but it is my hope to continue to provide this crutch for IMS
    sites unwilling to purchase an IMS monitor.


VI.  SAS Technical Notes.

 1. There are no MXG problems using the Version 6.09 of the SAS System.
    In fact, there have been no MXG problems with Version 6.08 at TS430
    or later maintenance levels!  Perhaps that is because MXG Software
    is now a standard part of the SAS Quality Assurance test stream?

VII. CICS Technical Notes.

 1. How can you use USER instead of TERMINAL to bill CICS transactions.

    IBM note RTA000013242 Library item Q451666 answers the question,
    "How can you use USER instead of TERMINAL to bill CICS transactions
    in an ISC or MRO CICS environment (i.e., when using transaction
    routing?", by pointing out that when you specify USERSEC=IDENTIFY
    or ATTACHSEC(IDENTIFY) on the SYSTEM entry or CONNECTION definition,
    the USER field is then propagated into the records created in the
    AOR and other regions observations in CICSTRAN.CICSTRAN.

    If you are billing CICS and DB2 by transactions, you really should
    look at the ASUMUOW member that summarizes CICSTRAN and DB2ACCT and
    their CPU times into one record per Unit of Work, reducing the
    number of "things" you have to count.  ASUMUOW keeps both TERMINAL

    and USER as well as both CICS and DB2 CPU times plus CICS response
    buckets in its output dataset PDB.ASUMUOW.  If you were using
    ASUMCICS to create PDB.CICS summary data, you will find ASUMUOW
    preserves the CICS resource and response fields from PDB.CICS and
    adds in the DB2 information.  ASUMUOW replaces the earlier ANALDB2C
    report program that merged DB2ACCT and CICSTRAN records.

VIII. Windows NT Technical Notes.

 1. Use  /B "Binary" switch on the COPY command to eliminate '3F'x.

    Two sites had STOPOVER ABENDS on MVS reading NTSMF data that had
    been COPYed under Windows NT Server before uploading to MVS.  The
    hex dump showed a one-byte physical record containing a '3F'x.
    Another site's TYPENTSM job failed with a 180 abend; the VMACNTSM
    member had been COPYed, and an extra line containing '3F'x had been
    appended to the source file.  It is apparently a documented fact
    that the COPY command can add an ASCII End-of-File Character at
    the end of a copy whenever multiple input files are copied into an
    output file.  That ASCII End-of-File Character then becomes the
    separate physical record on MVS after uploading and translation
    from ASCII to EBCDIC with ftp.  Using the  /B  "Binary" switch on
    the COPY command was found to eliminate the extra character.
    To read the uploaded file with the short record without ABENDing,
    you can change MXG's STOPOVER option to MISSOVER by using:
         MACRO STOPOVER MISSOVER %
    as your first SAS statement, before the %INCLUDEs in your SYSIN.

IX.   Incompatibilities and Installation of MXG 15.15.

 1. Incompatibilities introduced in MXG 15.15 (since MXG 14.14):

  a- IMACs that were changed (if they exist in your USERID.SOURCLIB, you
     must refit your tailoring, starting with the new IMAC member):

     IMACPTF, if you install PTF UN98309 for CICS Transaction Server 1.1

  b- Other incompatibility changes:

     Users of SAS ITSV V1 and V2.0 and SAS/CPE must install the two line
       circumvention described in the text of Change 15.320 to use MXG
       Version 15.08 or later.  SAS ITSV Version 2.1 is compatible and
       the circumvention is not required.


  c- These products were incompatibly changed by their vendor, and they
     require MXG Version 15.xx as indicated:

      Boole's IMF 3.2 (for IMS 6.1)           MXG 15.09  Change 15.372
      CICS TS V1.2                            MXG 15.06  Change 15.274
      CICS TS V1.1 APAR UN98309               MXG 15.06  Change 15.258
      Landmark TMON CICS 2.0                  MXG 15.06  Change 15.281
      Landmark TMON MVS 2.0                   MXG 15.09  Change 15.346
      NTSMF Version 2.1                       MXG 15.06  Change 15.249
      255 Structures in a Coupling Facility   MXG 15.06  Change 15.226
      BETA93 Release 1.3                      MXG 15.06  Change 15.237
      IDMS 14.0                               MXG 15.05  Change 15.218
      Coupling Facility more than 64 Structs  MXG 15.05  Change 15.226
      APPC APAR OW16975 APAR-in-Error         MXG 15.05  Change 15.227
      ObjectStar 3.0                          MXG 15.04  Change 15.195
      NTSMF Version 2.0                       MXG 15.03  Change 15.147
      DB2 Version 5.1.0 two SMF 102 IFCIDs    MXG 15.02  Change 15.095
      Hitachi 7700 Cache R.R. records         MXG 15.01  Change 15.008

 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.


X.    Online Documentation of MXG Software.

    MXG Documentation is now described in member DOCUMENT.


XI.   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 is normally
 created after the newsletter is sent to the printer!  Member CHANGES
 on the www.MXG.com homepage are the most timely, as they are updated
 (sometimes) between MXG versions.

 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 14.14 now in MXG 15.15:

  Dataset/
  Member   Change    Description

  Many     15.167  MXG now protects ALL date fields for year 2000.
  Many     15.169  SAS inconsistencies between MVS and ASCII fixed.
  Many     15.320  Hardcoded PDB. DDname externalized with &PDBxx macro.
  Many     15.354  All VMACs for SMF records start with IF ID=....
  Many     15.356  New &MACxxxx macro variable added to all VMACs.
  Many     15.170  Support for OS/390 Version 2 Release 4 (COMPAT).
  None     15.373  Support for OS/390 Version 2 Release 5 (no changes).
  ADOC1415 15.304  Using 14/15 records to determine dataset size.
  ADOCTAND 15.119  Cannot use Tandem's ftp program to upload Measure.
  AIXPDS   15.337  Support for AIX commands IOSTAT/PSSTAT/VMSTAT.
  ANALAVAL 15.262  Availability analysis example with PROC CALENDAR.
  ANALBATW 15.378  'Batch Window' graphical reports from PDB.JOBS/STEPS.
  ANALCISH 15.365  CICS reports CICNQG, CICSLGS, CICLGR are added.
  ANALCNCR 15.126  New example counts Avg and Max Logged on TSO Users.
  ANALCNCR 15.174  ANALCNCR with large INTERVAL had large WORK space.
  ANALDB2R 15.191  ANALDB2R fails, ERROR 31-185 if no PLAN in SORTBY.
  ANALDB2R 15.223  Some datetimes shifted right two positions, overlay.
  ANALDB2R 15.279  APPARENT MACRO &SORTUOW NOT RESOLVED error.
  ANALDBTR 15.259  Pairing DB2 IFCID 59 & 63 wrong if multiple 63s.
  ANALDBXX 15.173  Merge DB2 102s with DB2ACCT and CICSTRAN example.
  ANALDDCN 15.062  Analysis of impact of DDCONS(NO)'s duplicate bytes.
  ANALMULT 15.367  Corrected values of EXCPNODD/IOTMNODD for MULTIDD=Y.
  ASMIMSLG 15.229  Archaic pre-DFP 3.0 systems retrofit.

  ASMTAPES 15.047  ML-13 of ASMTAPES protects 0C4s, stays up, etc.
  ASMTAPES 15.141  ASMTAPES ML-14 populates fields, protects 0C4s.
  ASMTAPES 15.285  ML-15 adds dump suppression, OS/390 1.3 JCT changes.
  ASMTAPES 15.291  MXG 15.06 did not contain ML-15; MXG 15.07 does.
  ASMVVDS  15.302  Out of Storage eliminated, UCBs above 16MB
  ASUMTALO 15.077  Exploitation of TALO Interval Records added by ML-12
  ASUMTALO 15.301  Starting/Ending Interval counts include SPUN.
  ASUMUOW  15.079  IRESPTM, ENDTIME corrected.
  ASUMUOW  15.221  Specific reference to TEMP01 caused error, removed.
  ASUMUOW  15.307  MROTRAN count included "spun" observation counts.
  ASUMUOW  15.315  ASUMUOW option to get real TRANNAME versus CPMI/CSMI.
  BUILDPD3 15.020  JES3 BUILDPD3 had extra observations created.
  BUILDPD3 15.235  Duplicate step records might not be deleted.
  BUILDPDB 15.235  Duplicate step records might not be deleted.
  BUILDPDB 15.329  _CDExxxx macros reordered, now inside ELSE DOs.
  CICINTRV 15.251  CICINTRV logic corrected, must use this version.
  CLMXGSAS 15.084  Sample CLISTs for MXG and SAS execution under TSO.
  CONFIG   15.194  MXG default for MEMSIZE raised from 48M to 64M
  CONFIG   15.293  YEARCUTOFF=1960 is now MXG default, protects non-Y2K.
  DIFFDB2  15.070  DB2STATS values are negative in startup interval.
  DIFFDB2  15.278  Variables B1HITRAT-B4HITRAT were wrong.
  EXPDB30V 15.142  PDB exit EXPDB30V added for PDB.SMFINTRV.
  FORMATS  15.057  New RACF events decoded by MG080EV.
  FORMATS  15.109  Format MGBYTRT (Byte per second) truncated on left.
  FORMATS  15.152  Formats $MGHEX2H, $MGHEX4H, $MGHEX8H blanks '40'x.
  FORMATS  15.175  CICS formats $MGCICDL,$MGCICDS corrected.
  IHDR110  15.268  CICS Type 110 Header Exit for record selection.
  IMACICBB 15.179  Support for Boole MainView for CICS stat records.
  IMACICSM 15.157  Support for Shared Medical CICS Journal OASMON.
  IMACKEEP 15.123  Member IMACKEEP is documented as archaic.
  IMACPDB  15.002  Variable TERMIND added to PDB.STEPS.
  IMACPDB  15.048  Variables SMF6FDNM/SMF6PDNM (Formdef/PrintDef) kept.
  IMACPDB  15.091  Variables ACTBYTES/ACTPAGES from TYPE26J2 in PDB.
  IMACSHFT 15.151  Table of Holidays for SHIFT example added.
  IMACUOW  15.221  SORT output destination, other options externalized.
  IMACs    15.328  New _Sxxyyy "PROC SORT" macro defined in IMACs.
  INSTALL  15.277  VM/CMS cannot use a MACLIB member for CONFIG option.
  NTINTRV  15.255  Multi-processors properly summarized in NTINTRV.
  RMFINTRV 15.138  Report RPGNs/Classes can be used in IMACWORK!!!
  RMFINTRV 15.238  "ERROR. NEGATIVE CPU OVERHEAD TIME (TYPE70-TYPE72)".
  RMFINTRV 15.250  Test CPUTM NE CPU72TM too strong due to truncation.
  SMFPRM00 15.053  First draft of MXG recommendations for SMF parms.
  TRND72GO 15.135  Trending for TYPE72GO WLM Goal Mode Service Classes.
  TYPE102  15.113  DB2 Trace IFCID=125 logic revised.
  TYPE102  15.121  Negative values for DB2 fields decoded with format.
  TYPE102  15.132  DB2 Trace dataset T102S106 now corrected.
  TYPE102  15.216  DB2 Trace 102 subtype 140 INPUT STATEMENT EXCEEDED.
  TYPE102  15.245  DB2 Type 102 Subtype 140 INPUT STATEMENT EXCEEDED.
  TYPE102  15.245  Invalid Type 102 subtype 140 protection added.
  TYPE103  15.313  Support for ICSS SMF type 103 (Websphere).
  TYPE110  15.133  Leap Seconds support correct "GMT" to local.
  TYPE110  15.258  APAR UN98309 CICS TS V1.1 INCOMPATIBLE
  TYPE110  15.269  UOWTIME duplicate values, UOWIDCHR added to resolve.
  TYPE110  15.274  Support for CICS Transaction Server 1.2 INCOMPATIBLE.
  TYPE116  15.043  TYPE116 variable QWHCTNO remains numeric.
  TYPE116  15.241  MQ Series type 116 blank CICS TASKNR, questions.
  TYPE116  15.241  Type 116 INVALID DATA FOR QWHCTASK message
  TYPE1415 15.124  Support for APAR OW25263 (for 3590s)
  TYPE1415 15.239  New variable LASTVOFL flags if this is Last Volume.
  TYPE16   15.243  Support for DFSORT APAR PN71137 (COMPATIBLE).
  TYPE16   15.243  Support for DFSORT APAR PN71337 added flag fields.
  TYPE26J3 15.228  APAR OW26297 adds job account fields to JES3 type 26.
  TYPE26J3 15.273  JES3 ACCOUNT fields in type 26 were not read.

  TYPE28   15.336  Support for NPM 2.3 and APAR OW17876.
  TYPE28   15.362  NPM type 28 subtype 82 error corrected.
  TYPE30   15.063  TYPE30OM for OMVS discoveries
  TYPE30   15.065  EXCP/IOTM for UCB addresses over '8000'x wrong.
  TYPE30   15.133  Leap Seconds support converts "GMT" to local.
  TYPE30   15.227  APAR OW16975 INCOMPATIBLY in error, APPC type 30.
  TYPE42   15.106  Support for APAR OW20921 creates TYPE42VT (VTOC+).
  TYPE42   15.112  Support for APAR OW26451/OW26453/OW26497 MAXRSPTM+.
  TYPE42   15.358  TYPE42AU dataset was incorrectly built.
  TYPE50   15.185  Support for VTAM 4.4 changes to SMF type 50.
  TYPE6    15.009  Support for APAR OW25152 (PRINTWAY Print Queue Name)
  TYPE6    15.015  Support for Anacom's Anastack spooler type 6 SMF.
  TYPE6    15.016  Support for CA-DISPATCH Version 6 w/5-digit JSENR.
  TYPE6    15.039  Invalid "MVS PSF DOWNLOAD" type 6 records, APAR.
  TYPE6156 15.176  Support for Invalid Catalog Cell '05'x segment.
  TYPE6156 15.193  Another invalid '04' Catalog Cell STOPOVER.
  TYPE6156 15.222  INPUT STATEMENT EXCEEDED, Change 15.166 was wrong.
  TYPE7072 15.004  OS/390 R3 type 72 INPUT STATEMENT EXCEEDED RECORD.
  TYPE7072 15.013  Variable SSTORE72 (Shared Pages Bytes) created.
  TYPE7072 15.023  TYPE70 variable PCTMVSBY wrong in MDF shared CPUs
  TYPE7072 15.026  New variable VELONOIO calculates NO I/O Velocity.
  TYPE7072 15.038  TYPE72GO PERFINDX, R723CIRC and R723CICT wrong.
  TYPE7072 15.182  TYPE72GO VELOCITY wrong for Discretionary/System
  TYPE7072 15.183  TYPE72GO was OUTPUT when NOACTVTY was zero.
  TYPE7072 15.214  TYPE70 PCTMVSBY incorrect MXG 15.01-15.04.
  TYPE7072 15.270  OS/390 R2.4 Goal MODE INVALID DATA FOR R723CIDT/CDQT
  TYPE70PR 15.299  TYPE70PR had no obs for deactivated partition.
  TYPE71   15.064  Variable SLOTUTIL added to TYPE71 - slot usage
  TYPE72GO 15.297  VELOCITY variables are now multiplied by 100.
  TYPE74   15.008  Support for Hitachi 7700 Cache Records (INCOMPAT)
  TYPE74   15.011  Variable SMF744PN added to TYPE74CF to count CPUs.
  TYPE74   15.058  Cache TYPE74CA clean up and new variables added.
  TYPE74   15.226  Support for SMF type 74 CF more than 64 structures.
  TYPE78   15.061  PCTDIRPT/PCTCUBSY in TYPE74CF wrong.
  TYPE80A  15.107  Dataset TYPE8025 now created for RACF Event 25.
  TYPE80A  15.158  Support for RACFEVNT=22 and 59, repeated segments.
  TYPE80A  15.309  RACF RVARY INPUT STATEMENT EXCEEDED 1.0.9.2 release.
  TYPE88   15.257  Support for subtype 11 type 88 System Logger.
  TYPE90   15.267  Variable SMFRECNR is now kept.
  TYPE91   15.213  Support for SMF type 91 subtype 21 SMARTBATCH data.
  TYPE92   15.003  OMVS file GMT datetimestamps now converted to local.
  TYPE94   15.073  Support for Virtual Tape Server additions to SMF 94.
  TYPE94   15.130  TYPE94 variable SMF94ETO restored.
  TYPE99   15.165  Support for "Goal Mode SMF" type 99 subtype 6.
  TYPE99   15.357  Support for APAR OW29790.
  TYPEACF2 15.197  ACF2JR dataset variable ACLFLDVL populated.
  TYPEAIMR 15.311  Support for Fujitsu's AIM V20 AIM/RDBII SMF type 98.
  TYPEBBMQ 15.263  Support for Boole & Babbage MQ Series VSAM file.
  TYPEBETA 15.181  INVALID ARGUMENT in BETA93 SMF record *RELOAD*.
  TYPEBETA 15.237  Support for BETA93 Release 3.1 (INCOMPATIBLE).
  TYPECACH 15.008  Support for Hitachi 7700 Cache Records (INCOMPAT)
  TYPECIMS 15.033  ABENDSYS/ABENDUSR in IMF 1.3+ is corrected.
  TYPECIMS 15.082  Support for Boole and Babbage IMF 3.2 (for IMS 6.1.)
  TYPECIMS 15.372  Support for Boole's IMF 3.2 (for IMS 6.1) INCOMPAT
  TYPECMF  15.187  Variable C279SSI changed from numeric to character.
  TYPECMF  15.376  CMF Subtype 15 now creates CMF16MAP & CMF16LPA.
  TYPECMF  15.377  CMF Cache dataset CMF27CSC now contains CMF27C93.
  TYPECMFV 15.380  Boole & Babbage CMF VSAM History File supported.
  TYPECTCP 15.248  Support for Applied Expert Systems Clever TCP/IP.
  TYPECTLG 15.166  Support for Catalog Cell 'E7' (Alias).
  TYPECTLT 15.276  IOA/Control-T 5.0 variable DSEXPDT changed.
  TYPECTLT 15.306  CONTROL-T vars DSUSECT/DSEXCP wrong, undoc bytes.
  TYPEDB2  14.095  Support for DB2 Version 5.1.0 (COMPATIBLE).

  TYPEDB2  15.133  Leap Seconds support correct "GMT" to local.
  TYPEDB2  15.269  UOWTIME duplicate values, UOWIDCHR added to resolve.
  TYPEDCOL 15.108  High Used RBA can be greater than Allocated Space.
  TYPEDCOL 15.163  Support for DCOLLECT in DFSMS 1.4 (COMPAT).
  TYPEDCOL 15.324  VOLSER added to DCOLLECT DCOLCLUS dataset.
  TYPEDPPX 15.305  Support for DPPX/370 Performance Reporter output.
  TYPEEDGR 15.140  Support for new fields in DFSMSrmm extracts.
  TYPEEDGS 15.021  Variables EDGSADTE,EDGSARSD,EDGSASID, formats value.
  TYPEEREP 15.246  EREP records past logical EOF were read from DASD.
  TYPEFTEK 15.102  Support for Filetek Optical Disk SMF record
  TYPEHMF  15.192  Support for HMF SMF Subtype 11 (DS3 Statistics).
  TYPEHPTE 15.247  Support for HP MeasureWare for Terra Data OS.
  TYPEHURN 15.195  Support for ObjectStar 3.0 (INCOMPATIBLE).
  TYPEICE  15.134  Support for IXFP SMF subtypes 6 and 7
  TYPEICE  15.215  IXFP subtypes 2,3,4 not output, MXG 15.02-15.04 only.
  TYPEIDMJ 15.363  Support for IDMS Journal format for IDMS V12.
  TYPEIDMS 15.218  Support for CA's IDMS 14.0 (INCOMPATIBLE).
  TYPEIDMS 15.264  IDMS 10.02 observations not output.
  TYPEIMFL 15.375  Read IMF + SAP + IBM IMF log records at one time.
  TYPEIMSD 15.081  Support for IMS DBCTL transactions from IMS 07/08s.
  TYPEM204 15.303  Support for MODEL204 Version 3.4 INCOMPATIBLE.
  TYPEMEMO 15.071  Support for MEMO subtype 8, creates MEMODIST dataset
  TYPEMIM  15.059  Segments not output after MIMCNT=0 with MIM V 3.
  TYPEMON2 15.281  Support for Landmark's The Monitor for CICS/ESA 2.0.
  TYPEMWSU 15.068  Revised support for HP's MeasureWare for SUN
  TYPEMWTE 15.247  Support for HP MeasureWare for Terra Data OS.
  TYPEMWUX 15.022  HP-MW and HP-PCS base date now JAN1970 vice JAN70.
  TYPENSPY 15.067  Support for NETSPY Version 5.0 is in MXG 14.14.
  TYPENSPY 15.069  ARSPHOST missing in NSPYLU dataset for NETSPY 4.4
  TYPENSPY 15.168  Zero obs in NSPYTIC3 corrected.
  TYPENTSM 15.012  NTSMF records from NT 3.51 now supported.
  TYPENTSM 15.027  NTSMF new objects created by COMPAQ hardware.
  TYPENTSM 15.147  Support for NTSMF Version 2.0 (INCOMPAT).
  TYPENTSM 15.147  Support for Windows NT 4.0 Service Pack 2 (INCOMPAT)
  TYPENTSM 15.190  Support for five new NTSMF Objects.
  TYPENTSM 15.220  Support for NTSMF Version 2.1 (COMPAT), new objects.
  TYPENTSM 15.249  Support for NTSMF Version 2.1 (INCOMPATIBLE).
  TYPENTSM 15.265  NTSMF Version 2.0.H caused INPUT STATEMENT EXCEEDED.
  TYPEOMVT 15.150  INPUT STATEMENT EXCEEDED Omegamon VTAM 200 IRNUM=12.
  TYPEOMVT 15.296  Support for Omegamon for VTAM V400 (COMPATIBLE).
  TYPEOPC  15.188  OPC 3.1 datasets OPC23, OPC29, OPC31 corrected.
  TYPEOPC  15.256  OPC type 29 INPUT STATEMENT EXCEEDED error.
  TYPEPW   15.010  Support for Landmark's Performance Works/Smart Agent
  TYPEQAPM 15.052  Support for all OS/400 Release 3.7.0 records.
  TYPEQAPM 15.105  Dataset QAPMAPPN has variables wrong.
  TYPEQAPM 15.127  AS/400 variable AS400SYN missing if SYSTEM LT 8.
  TYPEQAPM 15.316  Support for OS/400 Release 4.1.0 (INCOMPATIBLE).
  TYPERACF 15.103  Support for RACF utility IRRDBU00's OMVS RACF data.
  TYPERDS  15.144  Zero observations in TYPERDS1-TYPERDS7 datasets.
  TYPERMFV 15.321  Some RMF III VSAM variables were corrected.
  TYPERMFV 15.355  CSA and SQA values were wrong; should be &RB.4.
  TYPEROSC 15.017  Support for CA-ROSCOE Version 6 SMF is verified.
  TYPESARX 15.300  Support for SAR CA-VIEW SMF exit SARSRQUX.
  TYPESFTA 15.030  SOFTAUDIT collect only at JOB record was deleted.
  TYPESTC  15.186  STK 4400, STCLMU variables decoded.
  TYPESVCC 15.200  Support for Peregrine's Service Center SMF.
  TYPETCP  15.234  Support for TCP/IP 3.2 API Calls record changes.
  TYPETMDB 15.114  TMON/DB2 subtype "DW" now supported.
  TYPETMDB 15.184  Support for TMON/DB2 record type "DE".
  TYPETMNT 15.077  Support for new fields added by ML-12 of ASMTAPES.
  TYPETMNT 15.110  Enhancements in preparation for ASMTAPES ML-14.
  TYPETMO2 15.353  Landmark TMON for CICS V2 variables renamed.
  TYPETMON 15.001  File counts incorrect in TYPETMON datasets.

  TYPETMON 15.054  Variables SYSTEM/SYSID truncated to only one byte.
  TYPETMON 15.139  Landmark CICS fix TT00032 creates one bad record.
  TYPETMON 15.266  MXG 15.04-MXG 15.05 only. CREATIME, other dates wrong
  TYPETMON 15.294  SYSID was length five instead of length four.
  TYPETMS5 15.199  Support for CA-1/TMS Release 5.2 (COMPATIBLE).
  TYPETMV2 15.346  Landmark for MVS V2 INPUT STATEMENT EXCEEDED.
  TYPEVLFC 15.230  Support for VLF Catalog activity from SYSLOG.
  TYPEVM   15.189  Support for VM ADSM Account Records in VM/ESA.
  TYPEWWW  15.086  Support for World Wide Web Common Log Format records
  TYPEXPSM 15.172  Support for Xerox's XPSM Version 2 SMF records.
  TYPEZARA 15.074  Support for Altai's ZARA Tape Management Release 1.2
  TYPEZARA 15.323  Packed Decimals protected, DATELU corrected.
  UDUMPEBC 15.085  Utility to produce MVS-like LIST; hex dump on ASCII.
  UTILCONT 15.056  Now a %MACRO - displays SAS dataset sizes (in MB).
  UTILUOW  15.335  CICS MRO - which CICSTRAN record has real TRANNAME.
  UVBSNRDW 15.242  Utility to re-create SMF VBS with no RDW/BDWs.
  UVBSNRDW 15.242  Utility to recreate VBS from data with no RDW/BDW.
  VMAC80A  15.289  RACF DTP EV44xxxx variables added for RACFEVNT=13.
  VMACIMSA 15.275  SAP IMS timestamp SAPTIMTR is Start of Transaction.
  VMACSTC  15.364  Support for StorageTek's VSM SMF records.
  VMACUCB  15.125  VIO detection conflict with DEVNR='7FFFF'x.
  VMXGCOMP 15.100  %MACRO utility to compare SAS Data Libraries
  VMXGOPTR 15.099  %MACRO to reset (most) SAS Options.
  VMXGSUM  15.098  Enhancement to protect OBS=0, and USER= options.
  WEEKBLDT 15.115  Dataset TYPE77 causes failure, wrong BY list.
  YEAR2000 15.045  DATETIMExx won't display yyyy if truncated.
  YEAR2000 15.167  MXG now protects ALL date fields for year 2000.
  YEAR2000 15.293  MXG cannot protect all non-Y2K-compliant dates.

Inverse chronological list of all Changes:


===Changes thru 15.382 were printed in MXG NEWSLETTER THIRTY-THREE===
===Changes thru 15.206 were included in MXG 15.04 dated Sep 01, 1997===
===Changes thru 15.206 were published in MXG NEWSLETTER THIRTY-TWO=====

 All Changes are in member CHANGESS and all Newsletters are in NEWSLTRS.

****************NEWSLETTER THIRTY-TWO***********************************










             MXG NEWSLETTER NUMBER THIRTY-TWO September 12, 1997

Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE

                         TABLE OF CONTENTS                          Page

I.   MXG Software Version 15.04 is available upon request              3
II.  MXG Technical Notes                                               5
  1. Status of ASMTAPES (Tape Mount and Allocation Monitor) 24Jun97.   5
  2. Using NUM Variables with HEXn. versus CHAR variables with $HEXn.  7
  3. Please subscribe to the MXG-L ListServer broadcast service.       7
III. MVS Technical Notes.                                              8
  1. A big jump in PGPEXCP (and also in IOSERVICE & SERVICE) in TYPE72 8
  2. APAR OW24867 corrects SMF type 60 record SMF60FNC & SMF60NNM      8
  3. APAR OW14759 corrects loss of all RMF records if SMF is switched  8
  4. APAR OW24149 reports negative page counts in variable PAGEESIN    8
  5. APAR OW24002 reports no SMF type 42 subtype 2 records are written 8
  6. APAR OW16728 reports negative values for variable ACTIVETM        8
  7. APAR OW23020 corrects SMF type 21 records that were not written   8
  8. Steps that have NOT CATALOGED 2 or 8 conditions can set a bit     8
  9. APAR OW24166 corrects Netview SMF Session Monitor records         8
 10. APAR OW25371 for VSAM/RLS processing enables creation of type 64  8
 11. CA-DISPATCH can create type 6 SMF records with invalid READTIME.  8
 12. APAR OW25624 corrects SMF type 42 subtype 6 (TYPE42DS) records    8
 13. APAR OW10233 references OZ51286 dealing with TYPE30 (STEPS/JOBS)  8
 14. APAR OW16975 (in OS/390 R3) will not write 80 bytes of zeroes     9
 15. APAR OW26144 reports excessive number of SMF type 118 records     9
 16. PSF APAR OW23493, if you have Cut Sheet Emulation devices         9
 17. Mobius' InfoPac SMF records have incorrect datetimes              9
 18. APAR OW25624 for DF/SMS type 42 SMF records corrects SMF42PTS     9
 19. APAR OW26949 corrects RACF UNLOAD utility so that the RACF Group  9
 20. Documentation of Error in SMF Type 30 Interval Due to LeapSeconds 9
 21. Information APAR II10549 acknowledges that TYPE70PR/ASUM70PR     10
 22. Reports of TYPE74CF observations wherein CFBUSY time exceeded    10
 23. Using Reporting Classes (and RPGNs) for workloads in IMACWORK.   10
 23. APAR OW26609 corrects errors in new fields in type 72 records    11
 24. APAR OW27840 (Opened 24Jun97) acknowledges sporadic instances    11
 25. APAR OW20926 (old) may correct error in TYPE42 variable SMF42DWB 11
 26. This is a preliminary response to the question:                  11
 27. APAR OW27252 reports no I/O queueing data in SMF record 78       12
 28. APAR OW28256 reports OS/390 can have invalid CPURCTTM (SMF72RCT) 12
 29. APAR OW25609 reports SMF interval processing can stop.           12
 30. APAR OW27956 reports that DFSMS/MVS RMM can create RMM SMF       12
 31. The variable MVSLEVEL in type 70 OS/390 1.3 has value VE010300   12
IV.  DB2 Technical Notes.                                             12
  1. With regard to EXCP counts in type 30 records, APAR OW16847      12
  2. IBM Item RTA000099957 answers DB2 Buffer Pool Hit Ratio query.   12
V.   IMS Technical Notes.                                             13
  1. The IMS Technical Note in Newsletter THIRTY-TWO that reported    13

      COPYRIGHT (C) 1997 MERRILL CONSULTANTS DALLAS TEXAS USA

                         TABLE OF CONTENTS, continued               Page

VI.  SAS Technical Notes.                                             13
  1. SAS I/O errors may require SAS maintenance. Revised 20Apr97.     13
  2. SAS data libraries CAN be hardware compressed, (up to 8:1!)      14
  3. An ABEND 0C4 (preceded by a SAS message about an I/O error      14
  4. If you are testing SAS for year 2000 compliance with third-party 14
VII. CICS Technical Notes.                                            15
 1. APAR PN89643 discusses large increase in CPU time when migrating  15
 2. Originally posted on SAS/CPE web by Jim Hein at ERIE, migration   15
 3. CICS Transactions with the same value of UOWTIME were generated   15
 4. APAR PQ03431/PQ06162 correct a never-ending-loop in DFHSTTR that  15
 5. CICS Transaction Server Version 1, abbreviated CICS/TS V1R1,      15
 6. Reducing the cost of CICS type 110 transaction record processing. 15
VIII. Windows NT Technical Notes.                                     16
IX.  Incompatibilities and Installation of MXG 14.14.                 16
X.  Changes Log                                                       16
     Alphabetical list of important changes                           17
     Changes 15.206 thru 15.001                                    19-62

I.   MXG Software Version Status.

 1. MXG Software Version 15.04 is now available, upon request.

 MXG 15.04 Software is now over one million lines (1,008,660)!

   Major enhancements added in MXG 15.04 dated 01Sep1997:

   MXG now protects ALL date fields for year 2000.
   Support for OS/390 Version 2 Release 4 (COMPAT).
   Support for "Goal Mode SMF" type 99 subtype 6.
   Support for DCOLLECT in DFSMS 1.4 (COMPATIBLE)
   Support for VTAM 4.4 changes to SMF type 50.
   Support for CA-1/TMS Release 5.2 (COMPATIBLE).
   Support for ObjectStar 3.0 (INCOMPATIBLE in MXG).
   Support for Xerox's XPSM Version 2 SMF records.
   Support for HMF SMF Subtype 11 (DS3 Statistics).
   Support for five new NTSMF Objects.
   Support for VM ADSM Account Records in VM/ESA.
   Support for TMON/DB2 record type "DE".
   Support for Boole MainView for CICS stat records.
   Support for Catalog Cell 'E7'(Alias) and invalid '05'x segment.
   Support for RACFEVNT=22 and 59 in TYPE80A.
   Support for Shared Medical CICS Journal OASMON records.
   Support for Peregrine's Service Center SMF record.
   Table of Holidays for SHIFT example added in IMACSHFT.

   Major enhancements added in MXG 15.03 dated 30Jun1997:

   Support for NTSMF Version 2.0 (INCOMPATIBLE; 15.02 was not correct).
   Support for Windows NT 4.0 Service Pack 2 (INCOMPATIBLE also).
   Support for IXFP SMF subtypes 6 and 7 (SNAPSHOT, SPACE UTILIZATION)
   Support for TYPE1415 APAR OW25263 (for 3590s).
   Support for TYPE42 APAR OW26451/OW26543/OW26497 MAXRSPTM added.
   Support for TYPE42 APAR OW20921 adds TYPE42VT VTOC/VVDS counts.
   Support for OMVS RACF data with RACF utility IRRDBU00.
   Support for new fields in TYPEEDGR DFSMSrmm extracts.
   ASMTAPES at ML-14 populates fields, protects 0C4 ABENDs better.
   RMFINTRV now allows Report RPGNs/Classes to be used in IMACWORK.
   Format MGBYTRT (Bytes per Second) can truncate value on the left.
   BUILDPDB enhanced to rename WORK.STEPS for IT Service Vision.
   Leap second support for type 30, 110, and 100-102 "GMT" conversion
   Trending for TYPE72GO into TREND.TRND72GO added.
   ANALCNCR Example counts Avg & Max Logged-ON TSO users from PDB.JOBs.

   Major enhancements added in MXG 15.02:

   Support for DB2 Version 5.1 (MXG 14.14 tolerates, COMPATIBLE!!)
   Support for Filetek's Optical Disk SMF record
   Support for OMVS data in RACF database (IRRDBU00 unload)
   Enhancements to VMXGSUM for OBS=0 processing
   Replacement for MXG 15.01's defective CICINTRV.
   ASMTAPES Technical Note updated - cause of 0C4 is now known.

   Major enhancements added in MXG 15.01:

   Errors in MXG 14.14 that are fixed in MXG 15.01:

   ASMTAPES (ML13) is available, recovers from 0C4s, see MXG Tech Notes.
   WORK.CICINTRV.DATA DOES NOT EXIST.
   OS/390 R3 Goal only: Type 72 INPUT STATEMENT EXCEEDED RECORD LENGTH.
   FILE counts in TYPETMON were incorrect before and after 14.14.

   New Support in MXG 15.01:

   ANALDDCN to analyze impact of DDCONS(NO) on duplicated SMF bytes
   TYPEIMSD for IMS DBCTL transactions from IMS 07/08 log records
   SMFPRM00 with first draft of MXG discussion for SMF parameters
   Support and exploitation of new TALO fields added by ASMTAPES ML-12.
   Support for APAR OW25152 (adds PRINTWAY Queue Name to TYPE6).
   Support for Altai's ZARA Tape Management Release 1.2
   Support for Anacom's Anastack spooler's type 6 SMF
   Support for Boole and Babbage IMF 3.2.
   Support for CA-DISPATCH Version 6 with 5-digit JESNR
   Support for CA-ROSCOE Version 6 SMF record verified.
   Support for COMPAQ hardware NTSMF objects.
   Support for Hitachi 7700 changes to TYPE74CA/CACHET90 (INCOMPAT)
   Support for Landmark's Performance Works/Smart Agents for UNIX 4.0
   Support for MEMO subtype 8 creates new MEMODIST dataset.
   Support for NETSPY Version 5.0 is already in MXG 14.14
   Support for Virtual Tape Server additions to SMF type 94
   Support for World Wide Web Common Log Format records.
   Support for all OS/400 Release 3.7.0 records.
   UDUMPEBC utility for MVS-like LIST; hex dump under ASCII systems.

  All of these enhancements are described in the Change Log, below.

    Availability dates for the IBM products and MXG version required:

                                       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 30  1996        14.05
      OS/390  1.3.0 Compatibility Mode Mar 28  1997        14.14
      OS/390  1.3.0 WLM Goal Mode      Mar 28  1997        15.02
      OS/390  2.4.0                    Sep 28  1997        15.04
      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 aka CICS/TS V1R1    Sep 10, 1996        14.07
      CICS-Transaction Server V1R1     Sep 10, 1996        14.07
      CRR 1.6                          Jun 24, 1994.       12.02
      CRR 1.7                          Apr 25, 1996.       14.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           Sep 11, 1996        14.07
      DB2 5.1.0 Tolerate               Jun 30, 1997        14.14
      DB2 5.1.0 Full support           Jun 30, 1997        15.02
      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
      DFSMS/MVS 1.4                    Sep 28, 1997.       15.04
      MQM 1.2, 1.3, 1.4                Apr 25, 1996.       14.02
      NETVIEW 3.1 type 37              ??? ??, 1996.       14.03
      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
      IMS     4.1                      Aug  6, 1994        12.02
      IMS     5.1                      Jun  9, 1996        14.05
      AS400 3.7.0                      Nov  1, 1996        15.01

    Availability dates for non-IBM products and MXG version required:

                                       Availability     MXG Version
      Product Name                     Date or Change    Required

      Microsoft
       Windows NT 4.0 and NT 3.51                          14.14
       Windows NT 4.0 Service Pack 2                       15.03
      Demand Technology
       NTSMF Version 1 Beta                                14.11
       NTSMF Version 2                                     15.03
      Landmark
       The Monitor for DB2 Version 2                       13.06
       The Monitor for DB2 Version 3                       15.03
       The Monitor for CICS/ESA 1.2 -                      12.12
       The Monitor for CICS/ESA 1.3 -                      15.01
       The Monitor for MVS/ESA 1.3  -                      12.05
       The Monitor for MVS/ESA 1.5  -                      12.05
      Candle
       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.05
       Omegamon for MVS V400                               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
      CA
       ASTEX 2.1                                           14.04
       NETSPY 4.7                                          14.03
       NETSPY 5.0                                          14.03
      Boole & Babbage
       IMF 3.1 (for IMS 5.1)                               12.12
      Memorex/Telex
       LMS 3.1                                             12.12A


II.  MXG Technical Notes

   1. Status of ASMTAPES (Tape Mount and Allocation Monitor) 24Jun97.

      ASMTAPES ML-14 is now available upon request, and is in MXG 15.03.

      - The ML-14 level improves interception of the 0C4s ABEND (see the
        discussion, below, for ML-13, and the text of Change 15.14x).
      - ML-14 populates several fields in the Mount Record, but as the
        SMF record's format was not changed, prior MXG versions will not
        fail with ML-14 SMF records. However, MXG 15.03 TYPETMNT code is
        required to properly INPUT and format the new fields and for
        support of 5-digit JESNR in TYPETMNT.

      ASMTAPES ML-13 was available upon request, and was in MXG 15.01.

      - The ML-13 level added an ESTAE to intercept 0C4s ABEND and to
        recover without a restart, so the monitor kept writing records.
      - ML-13 added new optional debugging diagnostics that allowed us
        to find the real cause of the 0C4's and the TMNT008I/TMNT007I
        messages:
         It all boils down to an address space having to be swapped in
         to guarantee access to all of its virtual storage while in AR
         mode.  Periodically in large and very busy data centers, a job
         with a tape drive allocated ends up swapped out.  If the swap
         is physical, ALESERV fails with a return code of '4C'x (which
         was discovered through experimentation and MXG handles, but you
         still get TMNT008I messages with RC of '4C'x printed).  The
         problem arises when the address space is logically swapped.
         ALESERV merrily returns an ALET, and the program continues
         execution.  All virtual storage access into the target address
         space is O.K., as long as it is in real memory, but if the page
         instead is in expanded or auxiliary storage, the page fault is
         not resolved and the S0C4 is passed on to the program.  IBM now
         has an APAR (OW22245) to change the ABEND code in this
         situation to a S0D5 with various reason codes!

         Now that we understand the cause, we will enhance ASMTAPES in
         the next iteration to stop issuing the TMNT007I and TMNT008I
         messages and just continue on to the next UCB.  If we take a
         S0C4 ABEND in any of the AR mode code, we will have our error
         recovery check the swap status of the address space and if it
         is swapped out, recover from the ABEND completely - no error
         messages, symptom dumps, or LOGREC entries.  We will also see
         if we can detect the logical swapped status early and avoid the
         0C4 ABEND, but will keep the error recovery in any event.

      ASMTAPES at ML-12 was shipped in MXG 14.14.

        - has failed with 0E0 and 0C4 ABENDS which took down the MXGTMNT
          address space
        - but ML-12 can be restarted, though one site had to try 4 times
          times in 15 minutes before the monitor stayed up (probably
          because the task that precipitated the 0C4 ABEND was still
          executing).
        - there was a patch for an 0C4 in the Mount monitor, (the patch
          bypassed the acquisition of JESNR and READTIME) but that 0C4
          was due to an ASMTAPES coding error (in handling ASIDs with
          multiple TCBs that do not have a TIOT for the first TCB) that
          patch is now included in ML-13.
      - generates TMNT007I and TMNT008I (ALESERV UNABLE TO ADD ....)
        informational messages.  We now know these notes are related to
        logically swapped ASIDS (see above) and will eliminate these
        now-unneeded MXG diagnostics in ML-15.
      - Only 6 sites have experienced any failures, and they have all
        been large systems and intense exploiters of tape technology.

      - Nevertheless, the ML-12 (from MXG 14.14) can still be used, and
        it is inherently safer than prior levels of ASMTAPES.  But it is
        so easy to install a new version of ASMTAPES and/or MXG Software
        you should just request MXG 15.03 and install ML-14 if you have
        not yet installed ML-12!

      ASMTAPES Management Summary:

        ML-14 is required if you have failures with ML-12 or ML-13, but
        installing ML-14 plus MXG 15.03 is recommended for all, to take
        advantage of both monitor protection and report enhancements,
        even though there still will be an ML-15 in the third quarter.

  2. Using NUM Variables with HEXn. versus CHAR variables with $HEXn.

     Tim VanderHoek observed differences in printing TYPE74CA variables:

        LCU   SSID1  SSID2  SSID3  SSID4             (in TYPE74CA)
        0044  001B   001C   4040   4040

     with that distracting "4040" hex value ('40'x is the MVS blank)
     printed for the non-existent SSIDs, and contrasted to TYPE78:

        CHP1 CHP2 CPH3 CHP4 CHP5 CHP6 CHP7 CHP8      (in TYPE78)
         37   57   77   A7    .    .    .    .

     which clearly shows that CHP5 thru CHP8 are missing.

     The difference is because MXG chose to use Numeric Variables with
     HEX format for the CHPn variables, and numeric variables have a
     unique "missing" value when they were not INPUT or initialized
     that SAS recognizes when HEX format is used, so SAS prints those
     missing values as a period (by default, but the MISSING= option
     lets you change those periods to blanks for cleaner reports),
     while MXG chose to use Character Variables with $HEX format for the
     SSID variables, and SAS has no unique "missing" value for Character
     variables.  Characters are initialized to blanks, so you cannot
     tell whether a character variable is blank because it was not INPUT
     or blank because a '40'x was actually INPUT!

     Why chose Character or Numeric for hex variables?  Using Character
     for hex variables requires only one byte per byte, whereas numeric
     variables require more storage, requiring a minimum of 3 bytes for
     a one-byte field, and requiring 5 bytes for a four-byte field, so
     most MXG hex variables are stored as Character with $HEXn format.
     Most of the time, the fields are always input, so the issue of
     blanks printing due to non-input is usually not an issue, and since
     '4040'x can be a legitimate data value, MXG cannot change.

     So what can you do when you are stuck with MXG's choice and have a
     specific report in which you want to changes those hex blanks to
     print as blanks?  Use the new $MGHEX2H, $MGHEX4H, $MGHEX8H
     formats (Change 15.252) or create the format in your report:
        OPTIONS CHARCODE;
        PROC FORMAT;
        VALUE $MGHEX4H
         '4040'X='    '
         OTHER=?< $HEX4. ?>;
     and then use FORMAT SSID $MGHEX4H. ; with your PROC PRINT to cause
     the hex '4040'x to print as blanks.   2JUL97.

  3. Please subscribe to the MXG-L ListServer broadcast service, simply
     by sending an email to  :    LISTSERV@PEACH.EASE.LSOFT.COM
     with no subject and text:    SUBSCRIBE  MXG-L  firstname lastname
     and you will receive technical discussions by MXG users as well as
     notification of new versions of MXG and any major changes!



III. MVS Technical Notes.

  1. A big jump in PGPEXCP (and also in IOSERVICE & SERVICE) in TYPE72
     occurs between MVS/ESA 4.3 and MVS/ESA 5.2, because the DB2 Media
     Manager EXCP counts are now captured.  28FEB97.

  2. APAR OW24867 corrects SMF type 60 record SMF60FNC & SMF60NNM blank
     values for RENAME event.  8MAR97.

  3. APAR OW14759 corrects loss of all RMF records if SMF is switched
     from NOACTIVE to ACTIVE after an SMF interval has expired. 12MAR97.

  4. APAR OW24149 reports negative page counts in variable PAGEESIN in
     datasets TYPE72GO and TYPE30_4/PDB.STEPS and in variable PGPAGEIN
     in dataset TYPE72GO if the address space was logically swapped
     during the interval. 12MAR97.

  5. APAR OW24002 reports no SMF type 42 subtype 2 records are written
     when parameter SMF_TIME in the IDGSMSxx member of SYS1.PARMLIB is
     set to YES.  Records are written if SMF_TIME=NO and CACHETIME(nnn)
     is specified! 12MAR97.

  6. APAR OW16728 reports negative values for variable ACTIVETM in
     TYPE72GO dataset, and possible lost type 72 subtype 3 records if
     WLM Policy is changed and then activated.  12MAR97.

  7. APAR OW23020 corrects SMF type 21 records that were not written
     due to HSM tape recycles done in "connected sets".  Because HSM
     did not dequeue at the completion of a recycle for each tape volume
     there was no type 21 record written. This amounted to over 2,000
     missed type 21 records at one site.  (Plug: the ASMTAPES MXG Tape
     Mount monitor did correctly record these mounts!). 12MAR97.

  8. Steps that have NOT CATALOGED 2 or 8 conditions can set a bit in
     type 30 TERMIND variable, and MXG will recognize that bit if on
     and will set variable ABEND='NOTCTL', but it turns out that that
     bit in type 30 is enabled ONLY if you have told MVS to fail the
     job on this error condition (in SYS1.PARMLIB member ALOCxx you
     must specify FAILJOB(YES)), so if you want to know which jobs had
     the not cataloged condition, you must first cause them to ABEND!
     This is not new, but was not clearly documented in MXG previously.

  9. APAR OW24166 corrects Netview SMF Session Monitor records for
     multidrop lines (incomplete secondary side configuration info for
     second and subsequent active clusters).

 10. APAR OW25371 for VSAM/RLS processing enables creation of type 64
     and type 42 subtype 15,16,17,18 and 19 records.

 11. CA-DISPATCH can create type 6 SMF records with invalid READTIME.
     Their fix is L012084 ("INVALID SM6JLTIM...).

 12. APAR OW25624 corrects SMF type 42 subtype 6 (TYPE42DS) records so
     the STARTIME (SMF42PTS) is valid. IBM failed to clear the field for
     the first datasets opened, and it contained the open time from an
     earlier job!  25MAR97.

 13. APAR OW10233 references OZ51286 dealing with TYPE30 (STEPS/JOBS)
     variables SWAPS(SMF30NSW), SWPAGINS(SMF30PSI), SWPAGOUT(SMF30PSO),
     counting pages and swaps for both physical and logical swap events,
     but OZ51286 was a 1981 APAR that fixed SWPAGINS and SWPAGOUT, so
     the new APAR only corrects SWAPS (so that only physicals are
     counted).  The APAR is in OS/390 Release 3.  29MAR97.

 14. APAR OW16975 (in OS/390 R3) will not write 80 bytes of zeroes in
     the should-be-nonexistent APPC segments in type 30 SMF records for
     steps that were flushed, but this has no impact on MXG.
     Note revised: 30Sep97.  The APAR has an error, which (until fixed)
     does impact MXG: the APAR creates records without the 80 bytes,
     but the triplets say the data is there, causing MXG to detect the
     bad records, print an MXG error message, a hex dump of the record,
     and all variables for each bad record, and MXG deletes the record!
     MXG Change 15.227 is required to circumvent the APAR error.

 15. APAR OW26144 reports excessive number of SMF type 118 records can
     be created for TCP/IP attached printers by PSF/MVS, because PSF's
     zero default value for CONNINTV (try for ever) will, when PSF finds
     a printer is not available (in use by some other app), then PSF
     loops forever trying to obtain a TCP/IP connection, creating an SMF
     118 record each time!  While IBM decides if they will change their
     default to perhaps 15 minutes, the APAR recommends that YOU code a
     non-zero value for CONNINTV (in the PSF PRINTDEV macro) for each
     TCP/IP attached printer under PSFs control.

 16. PSF APAR OW23493, if you have Cut Sheet Emulation devices (they
     have a switch on the printer that permits 2 pages side by side with
     no change in your print application!), errors (bogus values) in
     fields SMF6IMPS (SHEETPRN), SMF6FEET (DOCLENFT) and SMF6BNCN
     (BINUSED ) in MXG's PDB.PRINT and TYPE6 datasets are now correct.
     15Apr97.

 17. Mobius' InfoPac SMF records have incorrect datetimes for variables
     REQSTART and REQEND after installing InfoPac maintenance (VOLSER
     5767, Nov 96).  Instead of a value '0163514C'x for 16:35:14, their
     error (shift and truncate left!) put '6351490C'x into SMF, which
     SAS read as 635:51:49 hours, and added that to the 08APR97 date to
     create a datetimestamp of 11MAY97:11:14:53!  The error will be
     fixed soon in their "Project Name" ER740210.  21APR97.

 18. APAR OW25624 for DF/SMS type 42 SMF records corrects SMF42PTS, and
     explains some of the logic of how the Data Set Statistics Blocks
     (DSSB) are created, and describes the internal logic used to build
     the type 42 subtype 6 record.

 19. APAR OW26949 corrects RACF UNLOAD utility so that the RACF Group
     ID is populated for both Violations and Successful accesses; it
     was previously filled in only for Violations.  14Jun1997.

 20. Documentation of Error in SMF Type 30 Interval Due to Leap Seconds.

     SMF type 30 subtype 2 (Interval) begin and end timestamps use the
     "Absolute" clock (in GMT and includes leap seconds), but that makes
     the actual local time of the interval start to be 20 seconds sooner
     than requested.  Fifteen-minute intervals start at 13:14:40 local
     instead of the desired start time of 13:15:00.

        SMF       Raw                                        Converted
       Field     Hex Value           Date-time-stamp value   to local

      SMF30ISS  AEC433D280740000'x  05JUN1997:18:15:00.104  13:14:40.10
      SMF30IST  0048C10A0097156F'x  05JUN1997:13:14:40.10   13:14:40.10
      SMF30IET  AEC4372CB5A00000'x  05JUN1997:18:30:00.000  13:29:40.00
      SMF30TME  004A215C0097156F'x  05JUN1997:13:29:42.04   13:29:42.04

     Three clocks can be used to populate SMF record timestamps:
      Absolute - In GMT and includes leap seconds
      GMT      - In GMT equivalent of local (no leap seconds)
      Local    - In Local time zone, no leap seconds.

     Fields SMF30IST (interval start in local) and SMF30TME (record sent
     to SMF buffer in local) show the real interval begin and end, but
     because SMF Synchronization uses ISS/IET instead of IST values, the
     intervals are not synchronized with time of day.

     The error occurs in ANY sysplex, since leap seconds are non-zero in
     the CVTLOS in any system with the sysplex timer.

     I have recommended that IBM change their incorrect design and use
     the true local time of day instead of the absolute time to drive
     synchronization.

     I now understand better that I must use the entire difference from
     ISS to IST as the "GMT Offset" to convert IET to correct local
     time of day.  See MXG Change 15.133 for more on leap seconds.

 21. Information APAR II10549 acknowledges that TYPE70PR/ASUM70PR and
     RMF Reports can show Total Effective Dispatch time greater than
     Total Dispatch time (LCPUEDTM GT LCPUPDTM in TYPE70PR, LPnUEDTM GT
     LPnUPDTM in ASUM70PR), causing negative values for LPAR Management
     Time (LPnMGTTM in ASUM70PR).  IBM has seen this problem most often
     when the LPAR partition is connected to a coupling facility.  This
     APAR indicates this problem needs to be reported to your IBM CE so
     he/she can open a hardware PMH, "as this is most often the result
     of a non-responding or a slow-responding coupling facility". 18JUN.
     Update: 2005: EDT can be greater than PDT because of:
      a. coupling facility hardware when there really is a hardware
         problem, although these are quite rare, or
      b. when an LPAR, instead of hardware ICF, is used, for your
         coupling facility, and/or
      c. when you have defined a pathalogical ICF Sharing configuration;
         for example, having six coupling facility LPARs share a single
         ICF.
      d. Small, fractional differences between CPUEFFTM and CPUACTTM
         (here, CPUACTTM is the same as CPUUPDTM) can be ignored; you
         can also calculate the delta and track it for the last few
         weeks to see if it was significant.
      IBM has provided updated discussions of the negative performance
      impacts of coupling facilities sharing ICFs, in Washington System
      Center Flash W99037.
      Note: 2012.  This is now in the RMF Performance Management Guide:
       Each partition's CPU consumption for LPAR management is
       calculated as the difference between total and effective dispatch
       time.  It is possible that the total dispatch time is smaller
       than the effective dispatch time. This situation occurs when
       partitions get "overruns" in their dispatch intervals caused by
       machine delays.  The most typical form of this is caused by an
       MVS partition trying to talk to a coupling facility but getting
       significant delays or time-outs. It is sometimes symptomatic of
       recovery problems on the machine. In this case, field LPAR MGMT
       is filled with '****'.

 22. Reports of TYPE74CF observations wherein CFBUSY time exceeded the
     RMF Interval Duration (CFBUSYxx GT DURATM) were corrected with a
     microcode fix to the (ailing) Coupling Facility. 18JUN97.

 23. Using Reporting Classes (and RPGNs) for workloads in IMACWORK.

     You can now use Report Performance Groups or Reporting Classes to
     define the MXG Workloads that are created into the PDB.RMFINTRV
     dataset.  Previously, you could only use the Control Performance
     Group or Service Class values for variables PERFGRP or SRVCLASS in
     your definitions of workloads in member IMACWORK.  Revisions to
     RMFINTRV and IMACWORK in MXG 15.03 allow you to use any combination
     of Control Performance Groups and Report Performance Groups
     (Compatibility Mode), or Service Classes and Reporting Classes
     (Goal Mode) to define your work in member IMACWORK.

     RMFINTRV now calculates the true CPU time captured from all of the
     "safe" Control PERFGRP or Service Class observations into variable
     CPUTM (from which Capture Ratio is calculated), and then calculates
     the sum of CPU times from your IMACWORK definitions (stored in new
     variable CPU72TM).  If the sum of your definitions is less that the
     true CPU time (work has been skipped in your definitions), or if
     the sum is greater than the true CPU time (you have overlapped
     definitions), MXG will emit error messages on your SAS log!

     Using Reporting Class to define workloads is primarily needed
     by sites using WLM Goal Mode.  The old Compatibility Mode concern:
        you can't use Report Performance Groups because not only are
        RPGNs double accounted with their Control PGN, but a task can
        be triple, etc., accounted because a task can be in more than
        one Report Performance Group, and
        MXG's design used your definitions to get true CPU time
     has been changed, for with WLM Goal Mode:
        MXG's redesign now lets you use Reporting Classes to define
        workloads, but you must ensure that if you use them, that there
        is no overlap with the Service Class in which their resources
        are also counted.  There cannot be triple or above accounting,
        as WLM will allow a task to be in at most one Reporting Class.
     and even for Compatibility Mode:

        MXG's redesign now lets you use Report Performance Group values
        to define workloads, but you must ensure that if you use them,
        that there is no overlap with the Control Performance Group in
        which their resources are always accounted, and you must be
        aware of the exposure to triple or above accounting, if you
        allow a task to be in more than one Report Performance Group.

     In WLM Goal Mode, by design, you will have a small number of
     Service Classes (perhaps all of your Production CICS Regions are in
     one Service Class), but you should put each individual CICS Region
     (or better still, put each and every long running task) in its own
     unique Reporting Class.  You can have as many Reporting Classes as
     you need, as there is essentially no cost to a Reporting Classes;
     at most the SMF type 72 records will take a few more tracks of DASD
     each interval, even with hundreds of Classes.  In fact, some sites
     have mapped each old Control Performance Group into a new Reporting
     Class.  See comments in member IMACWORK and Change 15.138.

 23. APAR OW26609 corrects errors in new fields in type 72 records that
     were originally reported in Change 15.038.  R723CIRC,R723CIDT,
     R723CIWT and R273CICT record Non-Paging DASD I/O Connect, Wait, and
     Disconnect durations, and SSCH counts; without the APAR SRM could
     double count, most likely for TSO work, but any workload with lots
     of swap activity had bad counts. 26Jun97.

 24. APAR OW27840 (Opened 24Jun97) acknowledges sporadic instances of
     impossibly high values for ENQ contention times SMF77WTM, SMF77WTX,
     and SMF77WTT (MXG TYPE77 variables MAXTM, MINTM, and TOTLTM).

 25. APAR OW20926 (old) may correct errors in TYPE42 variable SMF42DWB
     (Direct Write Blocks) for IMS databases.  SMF42DWB seems valid in
     most cases, but some IMS database activity create unreasonably high
     values.  Site will either install PTF or migrate to OS/390 and I
     will update this note when I know more.  7Jul97.
     See APAR OW30059 (target PTF date 26Sep97).  31Oct97.

 26. This is a preliminary response to the question:
     How do you account for a 20% increase in CPU usage (20% more than
     last month?  Can you attribute it to individual jobs?

     The RMFINTRV data provides interval CPU usage and CPU usage by work
     load (based on your Performance Group/Service Class mappings in
     IMACWORK), so you can see changes not only in total CPU usage, but
     also changes in the amount of Uncaptured CPU, and the CPU time used
     by each workload.  You should begin analysis with RMFINTRV:

     - While PCT CPU busy can be useful in tracking changes, using the
       Total CPU Hours will often put things in better perspective, and
       eliminates the issue of what denominator did you use to calculate
       Percentage.

     - Compare the number of observations in RMFINTRV to see how many
       day's data is being compared.  How many working days were there
       in the two months being compared.  March has 25% more working
       days than February.

     - Compare Shift totals.  If the 20% increase was only in Prime
       shift, perhaps response time improved, more work was done in
       Prime time, so less work was held over to Non-Prime.

     - Compare individual Workloads in RMFINTRV to see if all workloads
       were increased, or only some workloads.  If the increase is in
       online workloads (CICS, TSO, etc.), look at the transaction count
       for those applications to see if they had more work to do, or it

       they did more CPU time per transaction.

     - Once you have isolated an increase to a particular workload in
       RMFINTRV, you can use the TYPE72 or TYPE72GO observations to see
       which Performance Group or Service Class caused the increase.

     - Once you identify the PERFGRP or SRVCLASS causing the increase,
       you use PDB.STEPS to select the jobs by PERFGRP or SRVCLASS to
       see what jobs were executing in that workload.  You could use
       PDB.JOBS, but you get the last step's PERFGRP/SRVCLASS, and you
       will get safer analysis from PDB.STEPS.  Moreover, you can then
       compare usage by PROGRAM to find the cause of the increase.

     - You should also compare a specific job's PDB.STEPS data across
       the two months.  The daily BUILDPDB or daily SMF dump program
       are reasonably consistent day-to-day (perhaps excluding weekend)
       consumers that can be tracked to see if those jobs also saw an
       increase that might suggest an overall increase in recorded CPU
       time (which can happen across hardware/software/microcode change
       in your data center).

 27. APAR OW27252 reports no I/O queueing data in SMF record 78 subtype
     three (dataset TYPE78XX), with SMF fields SMF78DCN/SMF78ASN (MXG
     variables NRCDSLCU/NRASS) zero after CPMF termination/restart.
     APAR OW26350 may also apply.

 28. APAR OW28256 reports OS/390 can have invalid CPURCTTM (SMF72RCT),
     the Region Control Task CPU time; very large values have been seen
     which cause negative values for CPUOVHTM in RMFINTRV.  This error
     previously existed in 1992 and was fixed by APAR OY51878's PTF, but
     seems to have reappeared (although the cause is different now).
     The error can be circumvented by subtracting CPURCTTM from CPUTM
     in member EXTY72GO and EXTY72 until IBM again provides a fix to
     the APAR OW28256 (which is still open) See Changes 10.064/9.184.

 29. APAR OW25609 reports SMF interval processing can stop, causing no
     type 30 subtype 2 or 3 records and no type 23 nor type 89 records.
     The error affects MVS 4.3 thru 5.2 and OS/390 R1 thru R3.

 30. APAR OW27956 reports that DFSMS/MVS RMM can create RMM SMF records
     with ID=0 (i.e., they look like IPLs) with certain combinations of
     parameters specified in SECCLS command in EDGRMMxx PARMLIB member.

 31. The variable MVSLEVEL in type 70 OS/390 1.3 has the value VE010300
     and for OS/390 2.4 it is VE020400.  The value is never used in MXG,
     but may be confusing when printed.  IBM changed the value (it used
     to be SP5.2.2) because some third-party programs failed if it did
     not increase with each release, so IBM could not use OS2.4.0!

IV.   DB2 Technical Notes.

  1. With regard to EXCP counts in type 30 records, APAR OW16847 notes
     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.  13Apr97.

  2. IBM Item RTA000099957 answers DB2 Buffer Pool Hit Ratio questions
     originated with an (unknown) MXG user.  IBM confirmed that his
     calculation:
      BPHITRAT=(QBSTGET-(QBSTSIO+QBSTDPP+QBSTLPP+QBSTSPP))/QBSTGET;
     was correct, and confirmed that negative values can occur, pointing
     to DB2 V3 Admin Guide (SC26-4888) Vol III page 7-81, which states:

        "When the hit ratio is negative, it means that prefetch has
        brought pages into the buffer pool that are not subsequently
        referenced, either because the query stops before it reaches the
        end of the table space, or because the prefetched pages are
        stolen by DB2 for reuse before the query has the chance to
        access them."
     IBM also confirmed the requestor's belief that the only reason for
     this to happen is when a program start 'triggers' sequential
     prefetches and just fetches one or a few rows and then does a close
     cursor, and that this is the only time when the number of Get Page
     Requests can be less than the number of pages read from DASD!
     See Change 15.146, which added BPHITRAT/BnHITRAT variables and
     corrected ANALDB2R's calculation VPOOL hit ratios to use SIO vice
     RIO.  26Jun97.

V.   IMS Technical Notes.

  1. The IMS Technical Note in Newsletter THIRTY-TWO that reported a 10%
     CPU increase with Boole & Babbage's IMF that was circumventable if
     some monitoring was disabled, has now been corrected with two fixes
     BPI7166 and BPI7167.  With the fixes installed, the CPU times now
     look okay.

VI.  SAS Technical Notes.

  1. SAS I/O errors may require SAS maintenance. Revised 20Apr97.
     For SAS 6.08, Level TS430 or later is required (or TS425+Z608A625).
       (Four-digit UCB address support)
     For SAS 6.09, Level TS450 requires zaps Z609D182 and Z609D339.
       (Four-digit UCB support, dynamically added UCBs)
     SAS 6.09, Level TS455 contains zaps Z609D182 and Z609D339.

     Mini-tutorial about UCB's above the line:
       By default, MVS/ESA 5.2 and OS/390 move UCBs above the 16MB line,
       but your site can change that default, and some sites have had to
       not-move their UCBs because of problems with software products.
       If your UCBs have been moved up, using VOLSERs with 3-digit UCB
       address for the SAS data library may circumvent the error, but
       installing the fix is a better solution.  18Apr97

     Open Problem?
     Back in May, four SAS 6.09 TS450 sites reported 0318 ABENDs, but in
     each case the ABEND went away with a rerun!  None of the sites had
     the two zaps listed above installed, and as no further 0318 ABENDs
     have been reported as of 26Jun97, it is likely that the ZAPs listed
     above were the solution!

     However, my original notes may be useful in the event of future
     SAS 0318 ABENDs:

     The symptoms (fails in DATA step or PROC SORT while writing to a
     SAS data library, but a rerun does not fail), and these earlier
     know causes of 0318 ABENDS:
         4-digit UCB addresses with back level SAS System
         High Track Address of SAS data library or input on 3390-9
         STOPX37 (only if STOPX37 installer did not read the manual)
         HSM Migration and Recall of SAS MultiVol (see Newsletter 26)
     made me suspect the error is related to the physical allocation of
     the data library (did it get allocated on a 4-digit or 3-digit UCB
     device, did the library go into extents, and did an extent go to a
     high-numbered track, etc.).  Possible circumventions include
     directing the library to a specific VOLSER with 3-digit UCB, or
     increasing the Primary Allocation so that no extents are needed, or

     re-using an existing permanent data set for //WORK or //PDB (i.e.,
     do not allocate new for each run of BUILDPDB).

     The SAS error message: "LIBRARY PDB APPEARS TO HAVE BEEN TRUNCATED.
     THE INTERNAL LIBRARY REFLECTS A HIGH FORMATTED RELATIVE BLOCK
     NUMBER THAT IS GREATER THAN THE NUMBER OF BLOCKS IN THE LIBRARY"
     also went away with a rerun with only the primary allocation
     changed, from 150 to 200 cylinders; the device was a 3390-9 (fat
     DASD) volume.

     Now, there are several SAS USAGE notes dealing with these errors:
     V6-SYS.SASIO-7929  Discusses possible problems if you backup SAS
                        multi-volume DASD libraries using utilities.
                        The only safe way appears to be to use the
                        PROC COPY to back up multi-volume libraries.
     V6-SYS.SASIO.A345  Discusses possible recovery for "truncated" SAS
                        libraries.
     V6-SYS.SASIO-C141  Documents "appears to have been truncated"
     V6-SYS.SASIO-C142  Lists several reasons why SAS libraries can be
                        "truncated", and what you can do to correct.

  2. SAS data libraries CAN be hardware compressed, (up to 8:1!) in
     spite of my note in Newsletter THIRTY-ONE, if you make the data
     library an "Extended Sequential" or "Extended Format" OS dataset,
     and then tell SAS to create the data library in "Tape" format (by
     specifying LIBNAME CICSTRAN TAPE;, or by starting the name of the
     LIBNAME with TAPE....)!

     However, this is most useful when there is only one SAS dataset to
     be written to the data library, because tape-format libraries do
     not have a directory, and thus to access a second SAS dataset in a
     tape-format library, you must read thru (and hence decompress) the
     entire first SAS dataset to find the start of the second one, just
     like any SAS data set actually on tape.

     Since you must use the new Extended Format data set type to use
     hardware compression, there is an additional virtue; these datasets
     will extend to multiple volumes when you fill the first disk, so
     here is yet another way to create a SAS multi-volume disk data
     library, and this one can be hardware compressed!

  3. An ABEND 0C4 (preceded by a SAS message about an I/O error on
     dataset ASUMDB2A) occurred when a PROC COPY of a weekly PDB library
     had a SELECT statement with dataset ASUMDB2A listed twice.
     Removing the second instance of ASUMDB2A in the SELECT statement
     eliminated the error!  While the user did not intend to copy the
     dataset twice, SAS certainly should be able to handle that without
     ABEND, right?  Yes, right.  The actual error was not in the repeat
     of the name, but because the output DD statement (accidentally)
     specified UNIT=(SYSDA,4), that second copy of the very-large
     ASUMDB2A dataset filled the first volume, and SAS ABENDED when it
     spilled over into the second volume, because you cannot use the
     UNIT=(SYSDA,n) for SAS multi-volume output libraries!

       Note inserted Feb 3, 2000: You CAN use UNIT=(SYSDA,n) with
       SAS Version 8 and later!!!

       (See MXG Newsletter 32 "SAS Technical Note 2" and
            MXG Newsletter 26 "SAS Technical Note 3" and
            MXG Newsletter 23 "SAS Technical Note 4"
            *** OR NOW JUST SEE MEMBER MULTIVOL ***
       for how to create SAS multi-volume libraries.  Jun 3, 1997.

  4. If you are testing SAS for year 2000 compliance with a third-party
     tool that uses SVC 11 timer interception technology, you must be
     running Release 6.09E, and you must request special maintenance
     by having your SAS rep contact a mainframe specialist in SAS's
     Technical Support group for specific details.

VII. CICS Technical Notes.

 1. APAR PN89643 discusses large increase in CPU time when migrating
    to CICS 4.1 due to logging errors even though LOGMESSAGE(NO) was
    specified on the EXEC CICS QUERY SECURITY command. 12MAR97.

 2. Originally posted on SAS/CPE web by Jim Hein at ERIE, migration from
    CICS 3.3 to CICS 4.1 can result in a dramatic drop in the number of
    transactions (observation count in CICSTRAN) if your CICS guru did
    not read the CICS/ESA Migration Guide to note that the old CICS
    parameter CONV=YES must be replaced by MNCONV=YES in CICS 4.1 to
    record each conversational transaction.  CICS 4.1 will disregard the
    old CONV=YES option and writes one record per attach rather than the
    desired one per conversation.  This was observed with SAS/SESSION
    (CICS transaction SASC, which is in conversation with MVS/APPC)
    count dropped from 100,000 to only 2,000 CICSTRAN observations until
    the MNCONV=YES was specified in CICS DFHMCT macro.

 3. CICS Transactions with the same value of UOWTIME were generated by
    an RPG application running in an AS/400 as a batch job.  A series of
    messages each created a CICS transactions, but all transactions from
    the job had the same UOWTIME, so it was impossible to match the CICS
    and DB2 activity.  By redefining the application with multi-session
    and using Free & Release (or modifying the application to use Evoke
    and Commit, which apparently does a pseudo Release/Detach of each
    Conversation), unique UOWTIME values for each transaction appeared.

 4. APAR PQ03431/PQ06162 correct a never-ending-loop in DFHSTTR that
    filled SMF with CICS Statistics (VTAM) records for IRCBATCH.

 5. CICS Transaction Server Version 1, abbreviated CICS/TS V1R1, is the
    official IBM name of new versions of CICS/ESA.  It would have been
    called CICS/ESA 5.1.0 (and SMFPSRVR=51 is in SMF data) but IBM has
    renamed the CICS Product.  The SMF records were INCOMPATIBLY changed
    between 4.1 and CICS/TS V1R1, but MXG 14.07 or later transparently
    provides support for those incompatible changes. See Change 14.209.

 6. Reducing the cost of CICS type 110 transaction record processing.

    These are preliminary notes, to partially answer an MXG-L query.
    This section will be updated with additional suggestions.

   -If you create CICSTRAN and keep only the 9 variables that are needed
    by the ASUMCICS program (to create PDB.CICS dataset), or only the xx
    variables needed by ASUMUOW (to create PDB.ASUMUOW), run times and
    resources needed can be reduced.
      -Using %INCLUDE SOURCLIB(TYPE110,ASUMCICS) to read 1613MB of SMF
       data, creating 2 million CICSTRAN observations and summarizing
       into 225,000 PDB.CICS observations took 14.5 CPU minutes, 1.75
       hours elapsed RESIDTM and 16.5 minutes of IOTM when all 109
       CICSTRAN variables were kept, but only 9.5 CPU minutes, 31
       minutes of RESIDTM, and only 6 minutes of IOTM when only the 9
       variables required by ASUMCICS were kept.
      -Using %INCLUDE SOURCLIB(TYPE110,ASUMUOW) to read 7400MB of SMF
       data, creating 13 million CICSTRAN observations and summarizing
       into 4 million PDB.ASUMUOW observations took 46 CPU minutes, 4.5
       hours elapsed RESIDTM and 1.5 hours of IOTM when only the xx
       variables needed by ASUMUOW were created.  Attempts to run with
       all 109 CICSTRAN variables failed to complete due to insufficient
       SORT work space and/or excessive elapsed time!

    Since the summary datasets PDB.CICS or PDB.ASUMUOW contain the
    summarized transaction resources AND responses, you may not really
    need all of the detail in CICSTRAN every day, and might consider
    using a tailored IMACCICS in your daily job to keep reduced CICSTRAN
    daily, and setup a separate IMACCICS for a separate TYPE110 job that
    will create all CICSTRAN variables when needed for ad hoc analysis.
    Examples of _KCICTRN macro definitions for keeping the 9 ASUMCICS or
    the xx ASUMUOW variables have been added (but are commented out) in
    member IMACCICS by Change 15.178.

   -If you were to use CICS EXCLUDE in CICS's DFMCT macro to only write
    out those 9 fields in the type 110 subtype 1 record (and then tailor
    MXG member IMACEXCL to process those nine fields), you could expect
    further reduction in processing time and in the size of your SMF
    data file.  Unfortunately, once you have excluded fields, you can't
    go back and get them when you need them, but for well behaved
    applications in large volume shops, it might be feasible.  Has
    anyone measured the difference, or is anyone interested in helping
    me to measure this?

   -If you never use the CICS Statistics (subtype 2 record), you can
    skip over them in MXG processing by adding in member IMACFILE:
       IF ID=110 AND SUBTYPE=2 THEN DELETE;


VIII. Windows NT Technical Notes.

 1. There are no new technical notes, but see CHANGES for many new
    objects that are now supported.

IX.   Incompatibilities and Installation of MXG 15.04.

 1. Incompatibilities introduced in MXG 15.04 (since MXG 14.14):

  a- IMACs that were changed (if they exist in your USERID.SOURCLIB, you
     must refit your tailoring, starting with the new IMAC member):

     none

  b- Other incompatibility changes:

     none

  c- These products were incompatibly changed by their vendor, and they
     require MXG 15.xx as indicated:

      NTSMF Version 2.0                       MXG 15.03  Change 15.147
      Hitachi 7700 Cache R.R. records         MXG 15.01  Change 15.008
      DB2 Version 5.1.0 two SMF 102 IFCIDs    MXG 15.02  Change 15.095
      ObjectStar 3.0                          MXG 15.04  Change 15.195

 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.

XI.   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 between MXG 14.14 and MXG 15.04:

  Dataset/
  Member   Change    Description

  Many     15.167  MXG now protects ALL date fields for year 2000.
  Many     15.169  SAS inconsistencies between MVS and ASCII fixed.
  Many     15.170  Support for OS/390 Version 2 Release 4 (COMPAT).
  ADOCTAND 15.119  Cannot use Tandem's ftp program to upload Measure.
  ANALCNCR 15.126  New example counts Avg and Max Logged on TSO Users.
  ANALCNCR 15.174  ANALCNCR with large INTERVAL had large WORK space.
  ANALDB2R 15.191  ANALDB2R fails, ERROR 31-185 if no PLAN in SORTBY.
  ANALDBXX 15.173  Merge DB2 102s with DB2ACCT and CICSTRAN example.
  ANALDDCN 15.062  Analysis of impact of DDCONS(NO)'s duplicate bytes.
  ASMTAPES 15.047  ML-13 of ASMTAPES protects 0C4s, stays up, etc.
  ASMTAPES 15.141  ASMTAPES ML-14 populates fields, protects 0C4s.
  ASUMTALO 15.077  Exploitation of TALO Interval Records added by ML-12
  ASUMUOW  15.079  IRESPTM, ENDTIME corrected.
  BUILDPD3 15.020  JES3 BUILDPD3 had extra observations created.
  CICINTRV 15.006  WORK.CICINTRV.DATA DOES NOT EXIST if IMACCICS changed
  CICINTRV 15.092  Replacement of MXG 15.01's CICINTRV.
  CLMXGSAS 15.084  Sample CLISTs for MXG and SAS execution under TSO.
  CONFIG   15.194  MXG default for MEMSIZE raised from 48M to 64M
  DIFFDB2  15.070  DB2STATS values are negative in startup interval.
  EXPDB30V 15.142  PDB exit EXPDB30V added for PDB.SMFINTRV.
  FORMATS  15.057  New RACF events decoded by MG080EV.
  FORMATS  15.109  Format MGBYTRT (Byte per second) truncated on left.
  FORMATS  15.152  Formats $MGHEX2H, $MGHEX4H, $MGHEX8H blanks '40'x.
  FORMATS  15.175  CICS formats $MGCICDL,$MGCICDS corrected.
  IMACICBB 15.179  Support for Boole MainView for CICS stat records.
  IMACICSM 15.157  Support for Shared Medical CICS Journal OASMON.
  IMACKEEP 15.123  Member IMACKEEP is documented as archaic.
  IMACPDB  15.002  Variable TERMIND added to PDB.STEPS.
  IMACPDB  15.048  Variables SMF6FDNM/SMF6PDNM (Formdef/PrintDef) kept.
  IMACPDB  15.091  Variables ACTBYTES/ACTPAGES from TYPE26J2 in PDB.
  IMACSHFT 15.151  Table of Holidays for SHIFT example added.
  RMFINTRV 15.138  Report RPGNs/Classes can be used in IMACWORK!!!
  SMFPRM00 15.053  First draft of MXG recommendations for SMF parms.
  TRND72GO 15.135  Trending for TYPE72GO WLM Goal Mode Service Classes.
  TYPE102  15.113  DB2 Trace IFCID=125 logic revised.
  TYPE102  15.121  Negative values for DB2 fields decoded with format.
  TYPE102  15.132  DB2 Trace dataset T102S106 now corrected.
  TYPE110  15.133  Leap Seconds support correct "GMT" to local.
  TYPE116  15.043  TYPE116 variable QWHCTNO remains numeric.
  TYPE1415 15.124  Support for APAR OW25263 (for 3590s)

  TYPE30   15.063  TYPE30OM for OMVS discoveries
  TYPE30   15.065  EXCP/IOTM for UCB addresses over '8000'x wrong.
  TYPE30   15.133  Leap Seconds support converts "GMT" to local.
  TYPE42   15.106  Support for APAR OW20921 creates TYPE42VT (VTOC+).
  TYPE42   15.112  Support for APAR OW26451/OW26453/OW26497 MAXRSPTM+.
  TYPE50   15.185  Support for VTAM 4.4 changes to SMF type 50.
  TYPE6    15.009  Support for APAR OW25152 (PRINTWAY Print Queue Name)
  TYPE6    15.015  Support for Anacom's Anastack spooler type 6 SMF.
  TYPE6    15.016  Support for CA-DISPATCH Version 6 w/5-digit JSENR.
  TYPE6    15.039  Invalid "MVS PSF DOWNLOAD" type 6 records, APAR.
  TYPE6156 15.176  Support for Invalid Catalog Cell '05'x segment.
  TYPE6156 15.193  Another invalid '04' Catalog Cell STOPOVER.
  TYPE7072 15.004  OS/390 R3 type 72 INPUT STATEMENT EXCEEDED RECORD.
  TYPE7072 15.013  Variable SSTORE72 (Shared Pages Bytes) created.
  TYPE7072 15.023  TYPE70 variable PCTMVSBY wrong in MDF shared CPUs
  TYPE7072 15.026  New variable VELONOIO calculates NO I/O Velocity.
  TYPE7072 15.038  TYPE72GO PERFINDX, R723CIRC and R723CICT wrong.
  TYPE7072 15.182  TYPE72GO VELOCITY wrong for Discretionary/System
  TYPE7072 15.183  TYPE72GO was OUTPUT when NOACTVTY was zero.
  TYPE71   15.064  Variable SLOTUTIL added to TYPE71 - slot usage
  TYPE74   15.008  Support for Hitachi 7700 Cache Records (INCOMPAT)
  TYPE74   15.011  Variable SMF744PN added to TYPE74CF to count CPUs.
  TYPE74   15.058  Cache TYPE74CA clean up and new variables added.
  TYPE78   15.061  PCTDIRPT/PCTCUBSY in TYPE74CF wrong.
  TYPE80A  15.107  Dataset TYPE8025 now created for RACF Event 25.
  TYPE80A  15.158  Support for RACFEVNT=22 and 59, repeated segments.
  TYPE92   15.003  OMVS file GMT datetimestamps now converted to local.
  TYPE94   15.073  Support for Virtual Tape Server additions to SMF 94.
  TYPE94   15.130  TYPE94 variable SMF94ETO restored.
  TYPE99   15.165  Support for "Goal Mode SMF" type 99 subtype 6.
  TYPEACF2 15.197  ACF2JR dataset variable ACLFLDVL populated.
  TYPEBETA 15.181  INVALID ARGUMENT in BETA93 SMF record *RELOAD*.
  TYPECACH 15.008  Support for Hitachi 7700 Cache Records (INCOMPAT)
  TYPECIMS 15.033  ABENDSYS/ABENDUSR in IMF 1.3+ is corrected.
  TYPECIMS 15.082  Support for Boole and Babbage IMF 3.2 (for IMS 6.1.)
  TYPECMF  15.187  Variable C279SSI changed from numeric to character.
  TYPECTLG 15.166  Support for Catalog Cell 'E7' (Alias).
  TYPEDB2  14.095  Support for DB2 Version 5.1.0 (COMPATIBLE).
  TYPEDB2  15.133  Leap Seconds support correct "GMT" to local.
  TYPEDCOL 15.108  High Used RBA can be greater than Allocated Space.
  TYPEDCOL 15.163  Support for DCOLLECT in DFSMS 1.4 (COMPAT).
  TYPEEDGR 15.140  Support for new fields in DFSMSrmm extracts.
  TYPEEDGS 15.021  Variables EDGSADTE,EDGSARSD,EDGSASID, formats value.
  TYPEFTEK 15.102  Support for Filetek Optical Disk SMF record
  TYPEHMF  15.192  Support for HMF SMF Subtype 11 (DS3 Statistics).
  TYPEHURN 15.195  Support for ObjectStar 3.0 (INCOMPATIBLE).
  TYPEICE  15.134  Support for IXFP SMF subtypes 6 and 7
  TYPEIMSD 15.081  Support for IMS DBCTL transactions from IMS 07/08s.
  TYPEMEMO 15.071  Support for MEMO subtype 8, creates MEMODIST dataset
  TYPEMIM  15.059  Segments not output after MIMCNT=0 with MIM V 3.
  TYPEMWSU 15.068  Revised support for HP's MeasureWare for SUN
  TYPEMWUX 15.022  HP-MW and HP-PCS base date now JAN1970 vice JAN70.
  TYPENSPY 15.067  Support for NETSPY Version 5.0 is in MXG 14.14.
  TYPENSPY 15.069  ARSPHOST missing in NSPYLU dataset for NETSPY 4.4
  TYPENSPY 15.168  Zero obs in NSPYTIC3 corrected.
  TYPENTSM 15.012  NTSMF records from NT 3.51 now supported.
  TYPENTSM 15.027  NTSMF new objects created by COMPAQ hardware.
  TYPENTSM 15.147  Support for NTSMF Version 2.0 (INCOMPAT).
  TYPENTSM 15.147  Support for Windows NT 4.0 Service Pack 2 (INCOMPAT)
  TYPENTSM 15.190  Support for five new NTSMF Objects.
  TYPEOMVT 15.150  INPUT STATEMENT EXCEEDED Omegamon VTAM 200 IRNUM=12.
  TYPEOPC  15.188  OPC 3.1 datasets OPC23, OPC29, OPC31 corrected.
  TYPEPW   15.010  Support for Landmark's Performance Works/Smart Agent

  TYPEQAPM 15.052  Support for all OS/400 Release 3.7.0 records.
  TYPEQAPM 15.105  Dataset QAPMAPPN has variables wrong.
  TYPEQAPM 15.127  AS/400 variable AS400SYN missing if SYSTEM LT 8.
  TYPERACF 15.103  Support for RACF utility IRRDBU00's OMVS RACF data.
  TYPERDS  15.144  Zero observations in TYPERDS1-TYPERDS7 datasets.
  TYPEROSC 15.017  Support for CA-ROSCOE Version 6 SMF is verified.
  TYPESFTA 15.030  SOFTAUDIT collect only at JOB record was deleted.
  TYPESTC  15.186  STK 4400, STCLMU variables decoded.
  TYPESVCC 15.200  Support for Peregrine's Service Center SMF.
  TYPETMDB 15.114  TMON/DB2 subtype "DW" now supported.
  TYPETMDB 15.184  Support for TMON/DB2 record type "DE".
  TYPETMNT 15.077  Support for new fields added by ML-12 of ASMTAPES.
  TYPETMNT 15.110  Enhancements in preparation for ASMTAPES ML-14.
  TYPETMON 15.001  File counts incorrect in TYPETMON datasets.
  TYPETMON 15.054  Variables SYSTEM/SYSID truncated to only one byte.
  TYPETMON 15.139  Landmark CICS fix TT00032 creates one bad record.
  TYPETMS5 15.199  Support for CA-1/TMS Release 5.2 (COMPATIBLE).
  TYPEVM   15.189  Support for VM ADSM Account Records in VM/ESA.
  TYPEWWW  15.086  Support for World Wide Web Common Log Format records
  TYPEXPSM 15.172  Support for Xerox's XPSM Version 2 SMF records.
  TYPEZARA 15.074  Support for Altai's ZARA Tape Management Release 1.2
  UDUMPEBC 15.085  Utility to produce MVS-like LIST; hex dump on ASCII.
  UTILCONT 15.056  Now a %MACRO - displays SAS dataset sizes (in MB).
  VMACUCB  15.125  VIO detection conflict with DEVNR='7FFFF'x.
  VMXGCOMP 15.100  %MACRO utility to compare SAS Data Libraries
  VMXGOPTR 15.099  %MACRO to reset (most) SAS Options.
  VMXGSUM  15.098  Enhancement to protect OBS=0, and USER= options.
  WEEKBLDT 15.115  Dataset TYPE77 causes failure, wrong BY list.
  YEAR2000 15.045  DATETIMExx won't display yyyy if truncated.

Inverse chronological list of all Changes:


===Changes thru 15.206 thru Change 15.001 were included in Newsletter 32
   and are available in CHANGESS member.

****************NEWSLETTER THIRTY-ONE***********************************










             MXG NEWSLETTER NUMBER THIRTY-ONE February 21, 1997

Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE

                         TABLE OF CONTENTS                          Page

I.   MXG Software Version 14.14 was shipped with this newsletter.      2
 1. Announcing email, our www.MXG.com home page and the MXG-L LISTSERV 2
 2. MXG Software Version 14.14, dated Feb 21, 1997, was shipped.       2
II.  MXG Technical Notes                                               7
 1.   MXGTMNT's Tape Allocation Monitor logic at MAINTLEV 9.           7
 2.   If MONTHBLD fails due to NOTSORTED error due to skipped version. 7
III. MVS Technical Notes.                                              7
 1. APAR OW15356 now writes type 21 SMF records                        7
 2. APAR OW10686 corrects errors in counting I/Os in type 30 records   7
 3. MVS/XA type 30 subtype 2, 3, & 4 with hex zeros for JOB.           7
 4. Increased Logical Swaps becoming Physical Swaps with Goal Mode.    7
 5. Type 74 subtype 5 Cache record (TYPE74CA) has duplicates.          7
 6. APAR OW23225 EXCP counts zero in TYPE30 for VSAM RLS datasets.     8
 7. Boole & Babbage CMF 5.2 creates type 72 with STARTIME 1 sec off.   8
 8. APAR OW23872 for 3590 Model A00 Control Unit serial number wrong.  8
 9. APAR OW23814 documents errors in DCOLLECT type A DCAFLAG1.         8
10. Media Manager EXCP counting for DB2 VSAM in 30 and 72s.            8
11. TCP/IP SMF records with invalid data for FTPCLIENT.                8
12. Type 6 CA-DISPATCH non-matching READTIME values.                   8
13. Slow TSO Logon duration due to massive STEPLIBs.                   8
14. Type 42 records were enhanced by APAR OW20866 (DCME enhancements). 9
IV.  DB2 Technical Notes.                                              9
 1. Where have all the DB2 buffer pools data gone?                     9
 2. Number of observations in DB2ACCT no longer counts plans.         10
V.   IMS Technical Notes.                                             10
 1. Boole & Babbage IMF had negative values for RESPTM                10
 2. Boole & Babbage IMF caused 10% increase in CPU time in MVS 5.2.2. 10
VI.  SAS Technical Notes.                                             10
 1. SAS USER ABEND 318 with SAS 6.08 at TS425 with 4-digit UCB.       10
 2. SAS note 8243: SAS data libs cannot be hdw compress or striped.   10
 3. IBM APAR OW14045 causes SYNCSORT to ABEND with 0C4 under SAS.     10
 4. SAS Usage Note 5637 (from 1992) - how to ftp V VB VBS files.      10
 5. If you use the FILE command from a Display Manager Session.       11
 6. Algorithm to count the number of bits that are on in a bit flag.  11
VII. CICS Technical Notes.                                            11
 1.  APAR PN70228 has extensive discussion of Short on Storage.       11
VIII. Windows NT Technical Notes.                                     11
 1. MXG Support for Windows NT with Demand Technology's NTSMF-WHY?    11
 2. So what is NTSMF and what measures do you get from NT registry?   12
IX.  Incompatibilities and Installation of MXG 14.14.                 20
X.   Online Documentation of MXG Software.                            21
XI.  Changes Log                                                      23
     Alphabetical list of important changes                           23
     Changes 14.343 thru 14.210                                    26-48

      COPYRIGHT (C) 1997 MERRILL CONSULTANTS DALLAS TEXAS USA

I. MXG Software Version Status.

 1. Announcing email, our WWW.MXG.COM home page, and the MXG-L LISTSERV.

    My new email address is BARRY@MXG.COM (replacing mxg@e-mail.com), an
    administrative matters can be sent to ADMIN@MXG.COM, or can be faxed

    I have, to some extent, embraced email, especially for receiving SMF
    data and for sending new members to beta sites for new support tests
    and I do try to check my email once a day.  I still find that fax is
    often faster (I check it much more frequently as it is beside the
    coffee pot!) but for hex dumps, the virtues of email over fax are
    both its legibility, and its machine readability for searching.
    If it is really critical, email the information, fax a reminder for
    me to logon, and call me to remind me to look at the fax machine!

    I still prefer to answer technical questions by phone whenever I can

    Our home page has been operational since November 1996, and it has
    the up-to-date status of the current MXG version.  (MXG 14.14 is the
    15th release since MXG 13.13, the last annual version).  On the home
    page you will find these members from the current version: CHANGES
    (status of what MXG version you need for what), YEAR2000 (status of
    other vendor's fixes), CHANGESS (all changes to all MXG versions),
    and NEWSLTRS (text of all MXG newsletters). While the Annual MXG
    Version and Newsletter shipment sent in First Quarter, and a Summer
    Newsletter sent in Third Quarter are still the primary MXG formal
    communications, more current information is always on the home page.

    Instructions on how to subscribe to the MXG-L LISTSERV, an e-mailing
    list, are also on our home page.  When you subscribe, any e-mail
    sent to MXG-L will be rebroadcast to all subscribers.  All MXG-L
    notes are viewable in the MXG-L Archive, and you do not need to be
    a subscriber to view the archive.  MXG-L is intended as a forum for
    technical questions among MXG users.  It is not moderated, but is
    monitored.  It also provides me with an easy way to let you know
    there is something worthwhile that has changed; for example, I email
    to the MXG-L list when there is a new MXG version available.


 2. MXG Software Version 14.14, dated Feb 21, 1997, was shipped to your
    site with this Newsletter.

   Major enhancements added in MXG 14.14 dated Feb 21, 1997:

   MXG is now distributed as an unnumbered dataset.
   MXG now converts DB2 GMT times to Local (Check you Exit Tailoring)
   Support for OS/390 Release 3 (Compatible)
   Support for APAF Version 3.
   Support for NPM APAR OW17875 type 28 new subtype 2Ax.
   Support for Landmark's The Monitor for CICS/ESA 1.5 (easy - no change
   New ASUMUOW to combine CICSTRAN and DB2ACCT by unit of work.
   PROCSRCE member is "Proc Source" for ASCII SAS.
   DB2GBPST dataset is now deaccumulated and usable.

   Major enhancements added in MXG 14.11 dated Feb 3, 1997:

   NTSMF support for 3.51, more data sets verified, record protects.
   Support for new Type 42 subtype 19 and changed subtypes 15-18.
   MXG Tape Mount and Tape Allocation Monitor ML11 in ASMTAPES
   Coupling Facility Structure Data TYPE74ST enhancements.
   DB2 GMT times now converted to local - see INCOMPATIBILTY SECTION.
   MXGSAS JCL Procedure finally corrected!

   Major enhancements added in MXG 14.10 dated Jan 10, 1997:

   Windows NT support using NTSMF significantly enhanced and documented.
    See "Windows NT Technical Notes" or member ADOCNTSM.

   Major enhancements added in MXG 14.09 dated Dec 17, 1996:

   Support for Demand Technology's NTSMF "SMF for Windows NT" product.
   Support for Demand Technology's Stress Test product's SMF record.
   Support for IBM VTAM Session Management Exit's SMF record

   Major enhancements added in MXG 14.08A dated Nov 18, 1996:

   Correction to VMAC74 INVALID DATA message for R744FCTM,FCSQ.

   Major enhancements added in MXG 14.08 dated Nov 13, 1996:

   Support for OS/400,AS/400 Release 3.7.0 and Release 3.6.0.
   Support for CA's ENDEAVOR SMF record.
   Support for APAR OW22209, bytes read/written.
   Support for HP's Measureware for AIX.
   Support for Applied Software's SUPER IND$FILE SMF.
   Support for Oracle Release 7.2.3 SMF record.
   Support for RACF 2.1 IRRDBU00 unload utility.
   PetaByte is now formatted. (1024 Terabytes=1 PetaByte).
   The TAILORNG= JCL parameter causes JCL error.
   Support for RMF type 74 subtype 100 IRLM long locks.
   Support for Interlink's Harbor 4.1 SMF record
   Support for RSD's EOS SMF record (INCOMPATIBLE, not in 14.07).
   Support for Boole and Babbage's PRO/SMS SMF Recovery Record.

   Major enhancements added in MXG 14.07 dated Sep 11, 1996:

   Support for Desktalk's TRENDSNMP IFENTRY SNMP data.
   Support for Candle's Omegamon for SMS V150 (no change!).
   CICS 4.1+ incorrect MCTMNTAD GMT offset circumvented.
   CICINTRV variable A02TTS missing in CICEODRV
   BUILDPDB now asserts SORTEDBY= for PDB.JOBS/STEPS/PRINT/SMFINTRV
   Beta Test of MXG DASD Allocation Monitor in ASMDALO/TYPEDALO.
   New utility UTILCONT (Contents of SAS library, sizes in Megabytes).

   Major enhancements in early MXG 14.07 shown in MXG Newsletter THIRTY:

   Support for CICS/ESA 5.1.0 aka Transaction Server (INCOMPATIBLE)
   Support for TMON/DB2 Version 3 (INCOMPATIBLE).
   Support for Boole and Babbage's PRO/SMS SMF Message Record.

   Major enhancements added in MXG 14.06 dated Aug 20, 1996:

   Support for CONTROL-T from New Dimension Software.
   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:
     DIFFDB2  14.108  BY VARIABLES ARE NOT PROPERLY SORTED DB2STATR
     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.
    NOTSORTED error for PDB.CICS in WEEKBLD, WEEKBLDT, and MONTHBLD.
    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.

    Availability dates for the IBM products and MXG version required:

                                       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 30  1996        14.05
      OS/390  1.3.0                    Mar 28  1997        14.14
      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
      CRR 1.7                          Apr 25, 1996.       14.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
      DB2 5.1.0                        ??? ??, 1997        ??.??
      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
      MQM 1.2, 1.3, 1.4                Apr 25, 1996.       14.02
      NETVIEW 3.1 type 37              ??? ??, 1996.       14.03
      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
      IMS     4.1                      Aug  6, 1994        12.02
      IMS     5.1                      Jun  9, 1996        14.05

    Availability dates for non-IBM products and MXG version required:

                                       Availability     MXG Version
      Product Name                     Date or Change    Required

      Demand Technology
       NTSMF Version 1 Beta                                14.11
      Landmark
       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
       The Monitor for MVS/ESA 1.5  -                      12.05
       The Monitor for MVS/ESA 2.0  -                      15.??
      Candle
       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
      CA
       ASTEX 2.1                                           14.04
      Boole & Babbage
       IMF 3.1 (for IMS 5.1)                               12.12
      Memorex/Telex
       LMS 3.1                                             12.12A

 3.   What products are not yet supported?

   a. Support for Landmark's Performance Works for Unix, a replacement
      for their earlier The Monitor for Unix (that was supported by MXG
      TYPETUX) is not included in MXG 14.14 because Landmark was unable
      to provide documentation in time.  The new product is a complete
      rewrite and no longer modifies the kernel, so some of the unique
      data elements in the earlier product have been lost.  If you are
      interested in this support, send a request and the enhancement
      will be sent to you when available.

   b. Landmark's The Monitor for CICS/ESA Version 2 will be released in
      spring, but the documentation and test data had not yet arrived.

   c. ASMTAPES, ML12, is still in final testing (see Change 14.322).  Al
      sites using ASMTAPES with MVS 5.2.2 or OS/390 should install ML11
      now, and request ML12 when it is available (soon).

 4.   What's planned for the near future?

   a. Documentation revision.  MXG 14.14 has support for just about ever
      new product's version that anyone has asked for, so finally I can
      return to updating the ACHAP and ADOC documentation members!

II.   MXG Technical Notes.

 1.   MXGTMNT's Tape Allocation Monitor logic at MAINTLEV 9 (MXG 14.05
      and later) once put one MVS system in an unrecoverable Spin Loop,
      requiring the site to IPL.  The error is caused by the SRB routine
      in the Allocation side of the monitor, so starting MXGTMNT with
                            ALLOC=NO
      to suppress the allocation monitor while continuing to write SMF
      records for Tape Mounts was recommended until MAINTLEV 11; that
      Mount monitor does not issue SRBs.  MAINTLEV 10 (MXG 14.08) did
      not correct the exposure, but this problem has only been seen by
      one site, which is massive and has horrendous tape activity, and
      appears to have additional glitches (pseudo stalls?) that last for
      tens of seconds that prevents us for getting the response to our
      SRB.  The permanent correction is contained in MAINTLEV 11 (MXG
      14.11) which replaced the SRB routine with cross memory services.
      ALL SITES SHOULD NOW RE-INSTALL MXGTMNT USING MXG 14.14 ASMTAPES!

 2.   If MONTHBLD fails due to NOTSORTED error, because you have skipped
      major MXG versions (like jumping from 11.11 to 14.07), the cause
      is that some of the weekly PDBs had one sort order, while the new
      weekly PDBs have a different sort order.  To get thru the night to
      build the Monthly PDB, you can circumvent the sort order
        Note originally read:
          you can comment out the BY _BYLIST; statement
        but that was inside the definition of MACRO _MNTHBLD, and
        could not be selectively applied without multiple MONTHBLDs.
        Revised note, Feb 10, 1998:
      You can circumvent by changing the list of sort variables in the
       line:   MACRO _BYLIST APPLID OPERATOR ... %  _MNTHBLD
      to contain only the first By variable:
               MACRO _BYLIST APPLID %  _MNTHBLD
      The _BYLIST macro definition to change is the one after the _DSET
      macro definition for the dataset causing the NOTSORTED problem.
      the monthly PDB won't be sorted, but at least the monthly PDB will
      be valid.  If one of your report programs now fails because it
      expected the data set to be sorted, you can insert a PROC SORT in
      that report program for this month's report.  MXG build's PDB
      datasets in sort order so that you can avoid SORTs in your report
      programs, but the removal of the BY statement is the easiest way
      to complete the creation of the Monthly PDB, and then individually
      deal with any repercussions in your report programs.

III.  MVS Technical Notes.

 1. APAR OW15356 now writes type 21 SMF records (Tape Volume Dismount)
    for tape devices with 4-digit (hex) UCB addresses.  Without the APAR
    type 21 are only written for 3-digit addresses.

 2. APAR OW10686 corrects errors in counting I/Os in type 30 records if
    more than 8,000 DDs exist in the step record.

 3. A site still running MVS/XA found type 30 subtype 2, 3, & 4 records
    had hex zeroes for variables JOB,JESNR,READTIME,TYPETASK, JCTJOBID.
    APAR OY38538 (closed, 1991) describes the error introduced by APAR
    UY56157 (DDCONS, 1990!) and provides a Local Zap to fix the problem.

 4. Increased Logical Swaps becoming Physical Swaps with Goal Mode has
    been observed by MVS/ESA sites moving from Compatibility to WLM; IBM
    now reports APARs OW11423 and OW20486 tune the WLM algorithms to
    correct the problems.  More details are in the APAR text.

 5. The new type 74 subtype 5 Cache record (TYPE74CA) may have logically
    duplicated data, if you have multiple systems sharing 3990 control
    units, because each MVS system writes a record with its perspective
    of 3990 usage.  Previously, you typically ran the predecessor Cache
    RMF Reporter on only one system, which produced only one set of data
    for 3990 usage.  These logically duplicate records can take up quite
    a bit of DASD space, so you may need to use the EXTY74CA data set
    exit member to control the OUTPUT of observations in TYPE74CA so as
    to only keep data from the one system that is always there and has
    access to all of your 3990 control units!

 6. APAR OW23225 reports EXCP counts in TYPE30 for VSAM RLS datasets
    are zero.  PTF is in testing.

 7. Boole & Babbage CMF 5.2 will create type 72 records with STARTIME
    one second later than true STARTIME, if you have installed their
    APAR BAM4508.  The correction to that APAR is now APAR BAM5929.

 8. Nov 23, 1996. APAR OW23872 for 3590 Model A00 Control Unit corrects
    the tape drive serial number in HDR2/EOF2/EOV2 Tape Labels on tapes
    created on 3590s behind those CUs, and corrects the value in the
    TYPE21 dataset (variable TAPCUSER, which contains an encoded value
    containing a product identifier, a unique drive serial number, plus
    information on the manufacturer and plant of manufacture of the
    tape drive on which the tape was created).

 9. Nov 23, 1996. APAR OW23814 documents errors in DCOLLECT type A
    (DCOLCLUS dataset) variable DCAFLAG1 with incorrect bits set for
    KSDS datasets.

10. Nov 23, 1996. As discussed in NEWSLETTER THIRTY MVS Technical Note,
    Media Manager EXCP counts for DB2 VSAM are recorded in type 30 EXCP
    buckets, but that note should also point out that those EXCP counts
    are also recorded in the type 72 records for the PERFGRP/SRVCLASS of
    the DBM1 ASID.  Also, to get these counts, you must specify
    SMFIO=YES on the MMSRV CONNECT request, and be at DFSMS 1.1 or
    above, and at DB2 4.1, or if at DB2 3, you need PTF PN76648.
    Support in MXG is automatic.

11. Dec 18, 1996. TCP/IP SMF records with invalid data for FTPCLIENT
    records were corrected by APAR PN96013 PTF UN92936.  Jan 11, 1997,
    see also APAR PN91783 for LOGN/LOGF record errors using USSMSG10
    or the Telnet Solicitor panel.

12. Dec 18, 1996. Type 6 records with non-matching READTIME values were
    found when SYSOUT was sent from one NJE node to another NJE node and
    then processed by CA-DISPATCH product; the type 6 record created by
    CA-DISPATCH has a semi-current time value, but it is not the actual
    READTIME of the other records for the job, but CA's error is fixed
    by CA-DISPATCH maintenance fix T7H0121.

13. Jan 29, 1997. Slow TSO Logon duration due to massive STEPLIBs.
    Walt Kraslawski of the Library of Congress writes:
    Thanks for your help with our TSO response problem.  As you
    requested, here is a recap of the problem and solution.

    Until recently, the Library of Congress has been almost exclusively
    a ROSCOE shop, with only a handful of low priority TSO users.  Long
    TSO response times were never an issue.  However, with the addition
    of a number of new applications, each requiring administration and
    usage via ISPF, response suddenly became a high-to-critical issue.

    A typical LOGON to "READY" would take 35 seconds: 10 seconds to "NO
    Broadcast Messages", 15 seconds to start the "%LOGIN," and 10
    seconds to complete the "%LOGIN," (which included only a few trivial
    commands).  From there it would take another 45-60 seconds to get
    into ISPF!  Analysis of SMF TYPE30_4 records for a LOGON-LOGOFF
    session showed only 3 to 5 seconds from READTIME to LOADTIME (which
    was thought to be the time of "READY").  Looking inside the
    SELAPSTM, the DSPDLYTM showed 30 seconds, and the only other
    significant value was IOTMNODD with 11 seconds I/O time for catalog,
    linklist, and JES2.  So SMF showed that the time to program load was
    small, and that most of the delay to get "READY" occurred after the
    TSO program IKJEFT01 was loaded, with lots of linklist I/O.

    The default TSO LOGON proc is very large, with 135 cataloged
    datasets covering almost every application on site.  These included
    23 load libraries in the STEPLIB, with the rest mostly being ISPF
    libraries, panels, tables, etc.  A simple test showed that deletion
    of the entire STEPLIB concatenation dropped the time to get into
    ISPF to 7 seconds instead of 90!  This revealed that every command,
    internal or otherwise, was being searched in the STEPLIB
    concatenation, and then going to SYS1.CMDLIB in the LINKLIST only
    after being not-found in the STEPLIB.  The desired solution was
    therefore to keep the function and purpose of the STEPLIB without
    the overhead.

    We created a new CSVLLA00 PARMLIB member with "LIBRARIES(...)"
    listing all of the load libraries in the TSO LOGON STEPLIB, followed
    by "FREEZE(...)" listing all the load libraries again.  The LLA
    address space is started at IPL without reference to this list,
    because we did not want to place every application library in the
    master catalog.  After VTAM comes up, an automatic start command is
    issued to "MODIFY LLA,UPDATE=00" to bring the TSO list into the LLA.

    The result is that TSO LOGON response time to get into ISPF is only
    7 seconds, just as if there were no STEPLIB concatenation.  The only
    down side is that we must do an LLA refresh whenever a load library
    in the list is changed.  We will see whether this becomes an issue.
    In the meantime, we are set up to do an automatic refresh every
    twelve hours.

14. Feb 24, 1997. Type 42 records were enhanced by APAR OW20866 (DCME
    enhancements for DFSMS 1.3.0 and above) to improve I/O statistics.
    New TYPE42VT (subtype 5) dataset now measures I/O activity to the
    VTOC, VTOC index, and VVDS at the volume level.  Multi-volume or
    striped datasets now have separate observations in TYPE42DS (subtype
    6) for each volume.  TYPE42DS also now captures I/O to JOBLIB and
    STEPLIB datasets, and block counts and block sizes are reportedly
    now corrected.  The new I/O delay statistics S42AMSRR and S42AMSWR
    contains the total I/O delay (time between wait and post).  Unlike
    total I/O time, the sum of all data set delays are additive and
    cannot sum to greater than the elapsed time of the job, making them
    very useful for job performance analysis.  MXG already supported the
    changes; this PTF populates the fields that were coded earlier.
    Revised: May 27, 1997.  See Change 15.105.

IV.   DB2 Technical Notes.

 1. Nov 25, 1996.  Now that DB2 has more than four buffer pools, where
    are the activity counts?  MXG Change 12.033 described how I chose to
    support the new buffer pools that were added by DB2 Version 3.1, but
    the text of that change was not easily read.  The implementation:

    In the DB2ACCT and DB2STATS datasets, there are still only four sets
    of Buffer Pool variables (QBnCaaa in DB2ACCT, QBnTaaa in DB2STATS,
    where n=1, 2, 3, or 4) but now they contain summarized counts:

      QB1 variables -  Only Buffer Pool   BP0 (4K)
      QB2 variables -  Only Buffer Pool   BP1 (4K)
      QB3 variables -  Buffer Pools sum   BP2 thru BP49 (all other 4K)
      QB4 variables -  Buffer Pools sum   BP80 thru BP89 (all 32K)

   For activity for a specific buffer pool, two other datasets exist:

    DB2ACCTB - One obs for each Buffer Pool used by each Plan.
    DB2STATB - One obs for each Buffer Pool used during the interval.


    However, by default, there will be zero observations in DB2ACCTB
    until you remove the comment block in member EXDB2ACB, the exit
    member for DB2ACCTB.  I chose to comment out that OUTPUT statement,
    because DB2ACCTB could be large (one obs for each buffer pool that
    was used by each plan, although the length is only 294 bytes) so
    why waste space until you need the details!  DB2STATB will always
    have observations, since it has only one obs for each buffer pool
    that was used during each interval.

 2. Dec 3, 1996.  The number of observations in DB2ACCT no longer counts
    the number of plan executions, if DB2 Parallelism is used.  DB2ACCT
    observations with DB2PARTY='P' are parallel tasks within a single
    plan execution, and should not be counted in NUMPLANS.  See member
    ANALDB2P (for an example of DB2 parallelism) and Change 14.287.

V.    IMS Technical Notes.

 1.   Jan 28, 1997.  Boole & Babbage IMF had negative values for RESPTM
      (END time was earlier than both ARRV and STRT) that is now fixed
      by their patch number BPI6881.

 2.   Feb 14, 1997. Boole & Babbage IMF caused a significant increase in
      CPU usage (measured in RMFINTRV and SMFINTRV) on the order of 20%
      moving from MVS 5.1 to MVS 5.2.2 with IMS 4.1.  Boole has a user
      mod (UMODIMS in BOOL9601.BBSAMP) that disables IMS/DC and IMF/EC
      data collection to reduce overhead, but that mod also causes DB2
      calls and DB2 CPU time to be not recorded.  It is alleged that IBM
      is working with Boole for a better solution.
      Jul 28, 1997 update:  Boole PTFs BPI7166 and BPI7167 corrected the
      problem.  See IMS Technical Note in Newsletter THIRY-TWO.


VI.   SAS Technical Notes.

 1. SAS USER ABEND 318 may result with SAS 6.08 at TS425 when a SAS
    data library is allocated to a device with 4-digit UCB address.
    A new problem is currently being opened.

 2. SAS usage note 8243 acknowledges that SAS data libraries cannot use
    "data striping" or "hardware compression", because both of those
    technologies do not support the EXCP access method that SAS uses for
    SAS data libraries on MVS systems.  If you attempt to write a SAS
    data library to one of these "Extended Format" (Extended Sequential)
    datasets, you will be greeted with an ABEND 213-B8 (as was noted in
    Newsletter TWENTY-EIGHT, but only under "hardware compression").

    Added 12Mar97:  Hardware compression can be used if the SAS Data
    Library is in "Tape Engine" format.  See Newsletter THIRTY-TWO.

 3. IBM APAR OW14045 causes SYNCSORT to ABEND with 0C4 and HOST SORT
    CANNOT BE USED message on SAS log.  SYNCSORT Early Warning EW4874-2
    contains the ZAP that will correct the error.  The IBM APAR applies
    to MVS/ESA 4.3, 5.1, and 5.2

 4. Nov 25, 1996.  SAS Usage Note 5637 (from 1992) said that you cannot
    use ftp to transfer V, VB, or VBS files from MVS to unix, but that
    was never true, and that usage note has now been deleted.

    All that you need do is to first create a copy of the original file
    on MVS that has DCB attributes of RECFM=U and BLKSIZE=32760, and
    then download that "RECFMU" copy of the data as a binary file using
    ftp.  You can use the (free) IBM utility program IEBGENER and this
    JCL example to create the required "RECFMU" copy of your data:

        //  EXEC PGM=IEBGENER
        //SYSPRINT DD SYSOUT=*
        //SYSIN    DD DUMMY
        //SYSUT1   DD DSN=MXG.ORIGINAL.VARIABLE,DISP=SHR,
        //            DCB=(RECFM=U,BLKSIZE=32760)
        //SYSUT2   DD DSN=MXG.COPY.RECFMU,DISP=(NEW,CATLG),
        //            UNIT=DASD,VOL=SER=MXGNNN,SPACE=(CYL,(60,5)),
        //            DCB=(RECFM=U,BLKSIZE=32760)

    After the download, you would use the FILENAME statement to tell
    SAS this data is V,VB, or VBS using RECFM=S370V, S370VB, or S370VBS,
    and SAS will have no problem reading the MVS data file.

    This was originally described in Newsletter TWENTY-FIVE, in the
    example "e. Downloading raw SMF, VM/Monitor etc., data" in the
    article "Executing MXG on PCs and Workstations", although that
    example originally did not mention that ftp could also be used.

 5. Dec  3, 1996.  If you use the FILE command from a Display Manager
    Session to SAVE a program, report, etc., without exiting, and you
    are creating a new file, the file will be allocated unblocked, which
    will waste space and time.  To be fixed in SAS Version 7, you can
    circumvent by pre-allocation of the file.  This only applies to a
    SAVE to a new sequential dataset; saving to an existing PDS will
    result in a properly blocked file.

 6. Feb 12, 1997.  To count the number of bits that are on ('1') in a
    two-byte character variable (BITMAP), a hexadecimal bit map, this
    algorithm
       ONESTRNG=PUT(BITMAP,$BINARY16.);
       IF BITMAP='0000'X THEN NRBITSON=0;
       ELSE NRBITSON=LENGTH(COMPRESS(ONESTRNG,'0'));
    was developed.  Note that BITMAP='00'X had to be forced to zero, as
    the LENGTH(COMPRESS(ONESTRNG,'0')) algorithm returns an incorrect
    value of one when BITMAP='00'X.

    Added 12Mar97: Don Friesen showed how to do this in one line:
     NRBITSON=LENGTH(COMPRESS('1'!!PUT(BITMAP,$BINARY16.),'0'))-1;

    I also observed you can use either $BINARY or BINARY as the format
    name for a character variable without error, while using $BINARY
    format name with a numeric variable, gets the correct result, but
    then you also get: "BITMAP HAS ALREADY BEEN DEFINED AS NUMERIC".

VII.  CICS Technical Notes.

 1.  APAR PN70228 has extensive discussion concerning Short on Storage.
     in CICS/ESA 4.1 caused by storage fragmentation, though the primary
     tool IBM suggests using is the examination of a Dump with IPCS!
     Apparently, SOS is again a serious problem in CICS 4.1, and there
     are new SIT overrides (CDSASZE, UDSASZE, SDSASZE and RDSASZE) that
     may be used to resolve critical SOS problems.

VIII. Windows NT Technical Notes.

 1. MXG Support for Windows NT requires Demand Technology's NTSMF. WHY?

    At the 1997 August SHARE meeting, Mark Friedman suggested that we
    collaborate to provide MXG support for the Windows NT platform.
    We recognized the incredible depth of detail available in the NT
    registry, and initially looked at the PERFMON application, but we
    saw a need for a data management tool (akin to the SMF writer's
    function of continuous measurement) with more power and function.
    Right now, most MXG sites want to bring the raw Windows NT data to
    their MVS platform, where they will process the NTSMF data into an
    NT PDB (just like they now process the MVS SMF data into their MVS
    Performance Data Base), but PERFMON log record length can grow
    without limit preventing processing under MVS, and we had observed
    occasional horrific spikes in PERFMON data values that suggested
    their extraction and deaccumulation may be in error.

    We decided to jointly design our own "SMF" record writer, creating a
    format that could be read under MVS or under Windows, with file
    management for continuous recording and file switching without
    having to start and stop the monitor, and taking less disk space
    that does PERFMON for the same data!

    Demand Technology sells the "NTSMF" product that creates the raw
    data records containing counters from all NT objects.  Contact them
    at 941-261-8945 for details.

    MXG Software then processes the NTSMF records into SAS datasets.

    Future enhancements (data filtering, different intervals for
    different records, monitoring of selected processes, accounting
    data, etc.) are planned, and enhancements are certain to be
    suggested by our initial users.  (E.g., Mark intends to provide a
    utility that will convert NTSMF record into Microsoft's LOG format
    in case you ever need to send problem documentation to Microsoft!).

 2. So what is NTSMF and what measures do you get from NT registry?

    NTSMF has a "server" and a "client".  The server is an NT System
    Service currently named DMPERFSS that is started once on the machine
    to be measured; this "server" responds to calls from the "client",
    gets the data from the NT registry, and then sends the data buffers
    to the "client".  The "client" is an NT process named NTSMF that you
    start and control, telling it which records are to be collected and
    at what interval.  The "client" can run on the measured machine or
    on a different machine, and can write the NTSMF records locally
    or send them to another machine's disk.

    There is an NTSMF record created for each Performance "Object", and
    the format is a comma-delimited ASCII file which can be read under
    Windows, or sent to MVS, converted ASCII-EBCDIC during transmission,
    and read there.  For Objects that have multiple instances per
    interval (e.g., Logical Disk object has an instance for each logical
    drive letter, and one for "_Total"), one record per instance is
    written (rather than writing out an ever-growing segmented record).

    The complete documentation of each dataset, each variable, etc., is
    contained in new member ADOCNTSM; the first ten pages of that
    documentation are provided here:

 Contents of this NTSMF documentation:

 Execution Instructions
 Testing Status
 Big Picture Description of NT Datasets ('Objects')
 List of MXG Data Sets created from NTSMF data records
 Common variables in every dataset created from NTSMF records:
 Sort Order for each dataset
 Documentation of Each Dataset and Each Variable

========================================================================
      Execution Instructions
========================================================================

 Execution of MXG to read NTSMF data on your MVS platform:
   Transmit the NTSMF output data file (a series of ASCII data records,
    with comma delimited fields, and CRLF line terminators) from NT to
    MVS into a RECFM=VB,LRECL=32756,BLKSIZE=32760 dataset (and specify
    conversion from ASCII to EBCDIC, CRLF or equivalent).
   Then use     //NTSMF DD DSN=your.ntsmf.data,DISP=SHR in your JCL.

 Execution of MXG to read NTSMF data under SAS FOR WINDOWS (95 or NT):
   Read "Executing MXG on PCs and Workstations", Newsletter TWENTY-FIVE
    (in member NEWSLTRS, or file NEWSLTRS.SAS) for instructions on how
    to download the MXG Software from MVS to your PC (must be unnumbered
    and "member" becomes file "MEMBER.SAS").
   You must copy MXG member AUTOEXEC (which would be the file named
    AUTOEXEC.SAS in the MXG Source Directory) into the AUTOEXEC.SAS in
    your SAS root directory, and add to that list of FILENAMEs:

        FILENAME NTSMF 'C:\wherever\is\your\datafile.NTS';

  Source Program:
  Then under either MVS or PC SAS, run this SAS program:

   %INCLUDE SOURCLIB(TYPENTSM);RUN;

  to create all possible MXG datasets (that I currently know about) from
  your NTSMF data.  The datasets will only have observations for those
  objects that were found in your data records. (Datasets with zero
  observations take essentially no space, so no tailoring is required.)

  The default TYPENTSM program invokes _SRTPRNL and _SRTPRNV macros to
  print the first fifty observations of each dataset.  The table below
  identifies those objects for which I have actually had test records;
  note that I have coded several datasets but have no test data yet.
  In addition, there will be new data sources that I don't know about
  yet - dataset UNKNOWN will contain observations if there are any new
  records at your site - let's talk when there are!

  Make sure you look at these PROC PRINT outputs, and make sure the
  numbers make sense at your installation, as this is all very new and
  very untested across diverse platforms!

========================================================================
      Testing Status
========================================================================

 Testing Status:  Of the 55 datasets created, I have had test data only
 for 28 of those datasets.  Datasets with "none" in the following table
 have not been tested with data, and may be wrong.  If you have obs in
 those untested datasets, lets talk!

Data Status:  Of the datasets created with observations, these data
              values are suspect and under investigation:
            DATASET:     LOGLDISK, PHYSDISK
              Variables: AVGDSKQL, AVGDSKRQL, AVDSKWQL
              Values:    Always missing.
            DATASET:     NWLINKSP
              Variable:  AVGWINSN, MAXWINSN
              Values:    3640M in NWLINKSP, but reasonable in NWLINKN
            DATASET:     SERVWORK
              Variable:  CTXBLKQU
              Values:    218405888 in one instance.
            DATASET:     SQLUSERS
              Variables: USRCPUTM, USRDSKIO
              Values:    Accumulated, rather than interval values.
            DATASET:     THREAD
              Variable:  CNTXTSWT
              Values:    Reasonable in some cases, 789,849,600 in some.
========================================================================
      Big Picture Description of NT Datasets ('Objects')
========================================================================

There are currently 55 "Objects" (NTSMF Record Types) created by NTSMF,
and there are 55 corresponding MXG Datasets created from NTSMF records.

Each "Object" (Record Type) is a set of counters, and a separate record
is created for each instance of an object.  A separate MXG Dataset is
created for each Object (dataset SYSTEM for the System object counters,
dataset PROCESOR for the Processor object counters), and a separate
observation is created in the appropriate MXG Dataset for each record.

Some Datasets contain only one instance per interval (Memory, System).

Other Datasets have multiple instances per interval; dataset LOGLDISK
might have three observations per interval, one each with the value of
"D:", "E:", or "_Total" for "instance" variable LDSKNAME.
For these datasets the "Instance Variable" (a/k/a BY variable) is listed
below.  Detail examples of actual values found for these BY variables is
given in the individual dataset documentation sections, below.

========================================================================
      List of MXG Data Sets created from NTSMF data records
 =======================================================================

Object/
Dataset  Obs  Vars OID  Instances        Full Descriptive Name

BROWSER   18  26   052                        Browser
CACHE     18  33   086                        Cache
FTPSERV   18  23   824                        FTP Server
GOPHER   none 26   ???                        GOPHER
HTTP     none 35   ???  ?                     HTTP
ICMP      18  34   582  ?                     ICMP
IMAGE    none  7   ???  ?                     IMAGE
IISG     none 20   ???  ?          Internet Information Services Global
IP        18  25   546                        IP
LOGLDISK  30  30   236  PDSKNAME,LDKSNAME     Logical Disk
MEMORY    18  34   004                        Memory
MSEXCHDB   1  26  2574  DBNAME                MS Exchange DB ISAM
MSEXCHDS none 19  2198  ?         Microsoft Exchange Directory Services
MSEXCHIS none 25  2536  ?                 MS Exchange Information Store
MSEXCHMC none 14  2286  ENTYNAME              MSExchangeMTA Connections
MSEXCHMS none 13  2610  ?                 MS Mail Connector Interchange
MSEXCHMT none 37  2224  ?                     MSExchangeMTA
MSEXCHPC none 24  2624  ?                     MSExchangePCMTA
MSEXCHPR none 26  2300  ?         MSExchange Information Store (Private)
MSEXCHPU none 28  2418  ?                MS Ex Information Store Public
NBTCONN   90  11   502  CONNNAME              NBT Connection
NETBEUI   54  47   492  DEVNAME               NETBEUI
NETBEUIR 486  12   494  DEVNAME,ADDRNAME      NETBEUI RESOURCE
NETWINTR   1  24   510  INTRNAME              Network Interface
NETWSEGM none 15  1110  ?                     Network Segment
NWLINKIP  18  47   488  DEVNAME               NWLINK IPX
NWLINKNB  18  47   398  DEVNAME               NWLINK NETBIOS
NWLINKSP  18  47   490  DEVNAME               NWLINK SPX
OBJECTS   18  13   260                        Objects
PAGEFILE  72  10   700  PAGEFILE              Paging File
PHYSDISK  72  27   234  PDSKNAME              PhysicalDisk
PENTIUM    1  75  2704  CPUNAME               Pentium
PROCASID none 45   786  PROCESS               Process Address Space
PROCESS  756  26   230  PROCESS               Process
PROCESOR  18  18   238  CPUNAME               Processor
RASPORT   18  26   870  COMNAME               RAS Port
RASTOTAL none 25   906  ?                     RAS Total
REDIRECT  18  44   262                        Redirector

SERVER    18  33   330                        Server
SERVWORK  36  24  1300  QUEUNAME              Server Work Queues
SQLICENS  18  10  2108                        SQLServer-Licensing
SQLLOCKS  18  28  2064                        SQLServer-Locks
SQLLOG   144  11  2170  LOGNAME               SQLServer-Log
SQLPROCA  18  17  2116                        SQLServer-Procedure Cache
SQLREPDB none 10  2190  ?            SQLServer Replication-Published DB
SQLSERVR  18  32  2012                        SQLServer
SQLUSERS 144  12  2160  USRNAME               SQLServer-Users
SQLUSRCT  18  17  2138                  SQLServer User Defined Counters
SYSTEM    18  32   002                        System
TCP       18  16   638                        TCP
TELEPHNY none 15  1150                        Telephony
THREAD  7303  21   232  PROCESS,THRDNAME      Thread
THREADET none 10   816  PROCESS,THRDNAME      Thread Details
UDP       18  12   658                        UDP
UNKNOWN    1  10   ---                        Unknown/New NTSMF Objects
WINSERV  none      920                        WINS Server

========================================================================
    Common variables in every dataset created from NTSMF records:
========================================================================

    DOMAIN   DURATM   SEQNR   SMFTIME   STARTIME   SYSTEM   ZDATE

Variable Type Length  Format       Label

DOMAIN    CHAR  32              DOMAIN*NAME
       Header variable.  Domain in which this computer SYSTEM is
       located.

DURATM    NUM    4 TIME13.3     INTERVAL*DURATION
       Header variable. Duration of this interval. It is used to create
       variable STARTIME=SMFTIME-DURATM; and is a constant value in each
       set of records written at end of interval, but it may vary some,
       and since NTSMF records are synchronized to time of day, the
       DURATM will be less than your chosen recording interval in the
       first and last intervals.  Compares favorably with DELTA(SYSUPTM)
       values, thus validating the accuracy of NTSMF time stamps.

SEQNR     NUM    4              RECORD*SEQUENCE*NUMBER
       Header variable.  All records written at one interval pop will
       have the same record sequence number, and each subsequent
       interval will have SEQNR incremented by 1.  Probably not needed.

SMFTIME   NUM    8 DATETIME22.3 TIMESTAMP*WHEN RECORD*WAS WRITTEN
       Header variable. Date and timestamp (to nearest millisecond)
       of the end of this interval.  This time value is on the local
       clock of the MONITORING system, not the monitored system.


STARTIME  NUM    8 DATETIME22.3 START*DATETIMESTAMP*OF*INTERVAL
       Header variable.  Datetimestamp (to nearest millisecond) of the
       Start of this interval.  Calculated STARTIME=SMFTIME-DURATM.
       This time value is on the local clock of the MONITORING system,
       not the monitored system.

SYSTEM    CHAR  32              SYSTEM*NAME
       Header variable. Name of this Computer System.  Always use in
       Sorting, usually in the second position (BY DOMAIN SYSTEM ...).


=======================================================================
  Sort Order for each dataset is defined in the _B (for "BY) macros:
=======================================================================

Dataset      Macro        BY Variables
             Name

BROWSER      _BNTBROW     DOMAIN SYSTEM
CACHE        _BNTCACH     DOMAIN SYSTEM
FTPSERV      _BNTFTP      DOMAIN SYSTEM
GOPHER       _BNTGOPH     DOMAIN SYSTEM
HTTP         _BNTHTTP     DOMAIN SYSTEM
ICMP         _BNTICMP     DOMAIN SYSTEM
IMAGE        _BNTIISG     DOMAIN SYSTEM
IISG         _BNTIMAG     DOMAIN SYSTEM
IP           _BNTIP       DOMAIN SYSTEM DEVNAME
LOGLDISK     _BNTLDSK     DOMAIN SYSTEM PDSKNAME LDSKNAME
MEMORY       _BNTMEM      DOMAIN SYSTEM
MSEXCHDB     _BNTMSDB     DOMAIN SYSTEM DBNAME
MSEXCHDS     _BNTMSDS     DOMAIN SYSTEM
MSEXCHIS     _BNTMSIS     DOMAIN SYSTEM
MSEXCHMC     _BNTMSMC     DOMAIN SYSTEM ENTYNAME
MSEXCHMS     _BNTMSMS     DOMAIN SYSTEM
MSEXCHMT     _BNTMSMT     DOMAIN SYSTEM
MSEXCHPC     _BNTMSPC     DOMAIN SYSTEM
MSEXCHPR     _BNTMSPR     DOMAIN SYSTEM
MSEXCHPU     _BNTMSPU     DOMAIN SYSTEM
NBTCONN      _BNTNBTC     DOMAIN SYSTEM CONNNAME
NETBEUI      _BNTNBUI     DOMAIN SYSTEM DEVNAME
NETBEUIR     _BNTNETB     DOMAIN SYSTEM DEVNAME  ADDRNAME
NETWINTR     _BNTNETI     DOMAIN SYSTEM
NETWSEGM     _BNTNETS     DOMAIN SYSTEM
NWLINKIP     _BNTNWLI     DOMAIN SYSTEM DEVNAME
NWLINKNB     _BNTNWLN     DOMAIN SYSTEM DEVNAME
NWLINKSP     _BNTNWLS     DOMAIN SYSTEM DEVNAME
OBJECTS      _BNTOBJ      DOMAIN SYSTEM
PAGEFILE     _BNTPAGE     DOMAIN SYSTEM PAGEFILE
PHYSDISK     _BNTPDSK     DOMAIN SYSTEM PDSKNAME
PENTIUM      _BNTPENT     DOMAIN SYSTEM
PROCASID     _BNTPRAS     DOMAIN SYSTEM PROCESS
PROCESS      _BNTPROC     DOMAIN SYSTEM PROCESS
PROCESOR     _BNTPROR     DOMAIN SYSTEM CPUNAME
RASPORT      _BNTRASP     DOMAIN SYSTEM COMNAME
RASTOTAL     _BNTRAST     DOMAIN SYSTEM
REDIRECT     _BNTRDIR     DOMAIN SYSTEM
SERVER       _BNTSERV     DOMAIN SYSTEM
SERVWORK     _BNTSERW     DOMAIN SYSTEM QUEUNAME
SQLICENS     _BNTSQNS     DOMAIN SYSTEM
SQLLOCKS     _BNTSQKS     DOMAIN SYSTEM
SQLLOG       _BNTSQOG     DOMAIN SYSTEM LOGNAME
SQLPROCA     _BNTSQCA     DOMAIN SYSTEM
SQLREPDB     _BNTSQDB     DOMAIN SYSTEM
SQLSERVR     _BNTSQVR     DOMAIN SYSTEM
SQLUSERS     _BNTSQUS     DOMAIN SYSTEM USRNAME
SQLUSRCT     _BNTSQCT     DOMAIN SYSTEM
SYSTEM       _BNTSYST     DOMAIN SYSTEM
TCP          _BNTTCP      DOMAIN SYSTEM
TELEPHNY     _BNTTELE     DOMAIN SYSTEM
THREAD       _BNTTHRD     DOMAIN SYSTEM PROCESS THRDNAME
THREADET     _BNTTHRX     DOMAIN SYSTEM PROCESS THRDNAME
UDP          _BNTUDP      DOMAIN SYSTEM
WINSERVR     _BNTWINS     DOMAIN SYSTEM


========================================================================
       Documentation of Each Dataset and Each Variable
========================================================================

   Alphabetic Documentation of each Dataset, with alphabetical list of
   each MXG variable's name, type (NUM/CHAR), stored length, FORMAT and
   LABEL, along with Microsoft's description of that variable.

   For data-tested datasets, there is an enhanced PROC PRINT output:
   the variable name is printed in lower case under the LABEL as heading
   so you can easily see which MXG variable name is what data.

   While you will need to learn the MXG variable name of each object, to
   use in your SAS analysis programs, the LABEL of each variable is the
   OBJECT NAME of that counter.

   Variables that contain byte counts are formatted with the MGBYTES
   format (the internal value is always the number of bytes, but that
   format prints a value like 200K, 42M, converting and adding the
   suffix).

   Variables that contain byte rates are formatted with the MGBYTRT
   format (the value is bytes per second, but that format prints a value
   like 11KB/SEC OR 518B/SEC, converting and adding the suffix).

   Most of the other variables are rates, as indicated in the LABEL.

   The NTINTRV dataset created by member NTINTRV, (automatically
   included by TYPENTSM) will be your primary source of NTSMF measures
   (much like RMFINTRV was for RMF data for MVS). Please read the
   comments in member NTINTRV to map your PROCESSes to WORKLOADS in the
   NTINTRV dataset.

   One Workload, NTSMF, that measures the cost of our data capture, has
   been created as an example, but you will need to suggest to me how to
   name workloads and identify which processes are grouped into which
   workloads.

   This is the first release of the NTSMF support; I appreciate your
   input as we learn what's important and what's not.  I hope you
   found my variable names understandable, and am ready to fix any
   errors and am open to suggestions for enhancements and hereby
   solicit your report programs as examples for others.



========================================================================
     1.  Dataset BROWSER  (WIN NT BROWSER)
                            26 variables, 168  bytes per observation.

One instance per interval.  Browser Statistics.

Variable Type Length  Format       Label

ANNDOMAI  NUM    4              ANNOUNCEMENTS*DOMAIN/SEC
 (079) Announcements Domain/sec is the rate that a Domain has announced
       itself to the network.

ANNDUPMS  NUM    4              DUPLICATE*MASTER*ANNOUNCEMENTS
 (809) Duplicate Master Announcements indicates the number of times that
       the master browser has detected another master browser on the
       same domain.

ANNSERVR  NUM    4              ANNOUNCEMENTS*SERVER/SEC
 (055) Announcements Server/sec is the rate that the servers in this
       domain have announced themselves to this server.

ANNTOTAL  NUM    4              ANNOUNCEMENTS*TOTAL/SEC
 (813) Announcements Total/sec is the sum of Announcements Server/sec
       and Announcements Domain/sec.

DOMAIN    CHAR  32              DOMAIN*NAME
       Header variable.  Domain in which this computer SYSTEM is
       located.

DTGRILEG  NUM    4              ILLEGAL*DATAGRAMS/SEC
 (811) Illegal Datagrams/sec is the rate of incorrectly formatted
       datagrams that have been received by the workstation.

DTGRMIMA  NUM    4              MISSED*MAILSLOT*DATAGRAMS
 (169) Missed Mailslot Datagrams is the number of Mailslot Datagrams
       that have been discarded due to configuration or allocation
       limits.

DURATM    NUM    4 TIME13.3     INTERVAL*DURATION
       Header variable. Duration of this interval. It is used to create
       variable STARTIME=SMFTIME-DURATM; and is a constant value in each
       set of records written at end of interval, but it may vary some,
       and since NTSMF records are synchronized to time of day, the
       DURATM will be less than your chosen recording interval in the
       first and last intervals.  Compares favorably with DELTA(SYSUPTM)
       values, thus validating the accuracy of NTSMF time stamps.

ELECTION  NUM    4              ELECTION*PACKETS/SEC
 (081) Election Packets/sec is the rate of browser election packets that
       have been received by this workstation.

ENUDOMAI  NUM    4              ENUMERATIONS*DOMAIN/SEC
 (163) Enumerations Domain/sec is the rate of Domain browse requests
       that have been processed by this workstation.

ENUOTHER  NUM    4              ENUMERATIONS*OTHER/SEC
 (165) Enumerations Other/sec is the rate of browse requests processed
       by this workstation that were not domain or server browse
       requests.

ENUSERVR  NUM    4              ENUMERATIONS*SERVER/SEC
 (161) Enumerations Server/sec is the rate of Server browse requests
       that have been processed by this workstation.

ENUTOTAL  NUM    4              ENUMERATIONS*TOTAL/SEC
 (815) Enumerations Total/sec is the rate of browse requests that have
       been processed by this workstation.  This is the sum of
       Enumerations Server, Enumerations Domain, and Enumerations Other.

MISSRVRA  NUM    4              MISSED*SERVER*ANNOUNCEMENTS
 (167) Missed Server Announcements is the number of server announcements
       that have been missed due to configuration or allocation limits.

MISSRVRQ  NUM    4              MISSED*SERVER*LIST*REQUESTS
 (171) Missed Server List Requests is the number of requests to retrieve
       a list of browser servers that were received by this workstation,
       but could not be processed.

MSALLOCF  NUM    4              MAILSLOT*ALLOCATIONS*FAILED
 (383) Mailslot Allocations Failed is the number of times the datagram
       receiver has failed to allocate a buffer to hold a user mailslot
       write.

MSOPENSF  NUM    4              MAILSLOT*OPENS*FAILED/SEC
 (807) Mailslot Opens Failed/sec indicates the rate of mailslot messages
       received by this workstation that were to be delivered to
       mailslots that are not present on this workstation.

MSRECVSF  NUM    4              MAILSLOT*RECEIVES*FAILED
 (385) Mailslot Receives Failed indicates the number of mailslot
       messages that couldn't be received due to transport failures.

MSWRITEF  NUM    4              MAILSLOT*WRITES*FAILED
 (387) Mailslot Writes Failed is the total number of mailslot messages
       that have been successfully received, but that were unable to be
       written to the mailslot.

MSWRITES  NUM    4              MAILSLOT*WRITES/SEC
 (083) Mailslot Writes/sec is the rate of mailslot messages that have
       been successfully received.

SEQNR     NUM    4              RECORD*SEQUENCE*NUMBER
       Header variable.  All records written at one interval pop will
       have the same record sequence number, and each subsequent
       interval will have SEQNR incremented by 1.  Probably not needed.

SMFTIME   NUM    8 DATETIME22.3 TIMESTAMP*WHEN RECORD*WAS WRITTEN
       Header variable. Date and timestamp (to nearest millisecond)
       of the end of this interval.  This time value is on the local
       clock of the MONITORING system, not the monitored system.

SRVANALF  NUM    4              SERVER*ANNOUNCE*ALLOCATIONS*FAILED/SEC
 (381) Server Announce Allocations Failed/sec is the rate of server (or
       domain) announcements that have failed due to lack of memory.

SRVLSTRQ  NUM    4              SERVER*LIST*REQUESTS/SEC
 (085) Server List Requests/sec is the rate of requests to retrieve a
       list of browser servers that have been processed by this
       workstation.

STARTIME  NUM    8 DATETIME22.3 START*DATETIMESTAMP*OF*INTERVAL
       Header variable.  Datetimestamp (to nearest millisecond) of the
       Start of this interval.  Calculated STARTIME=SMFTIME-DURATM.
       This time value is on the local clock of the MONITORING system,
       not the monitored system.

See member ADOCNTSM for rest of NTSMF document (including PROC PRINTs).


IX.   Incompatibilities and Installation of MXG 14.14.

 1. Incompatibilities introduced in MXG 14.14 (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):
       NONE

  b- Other incompatibility changes:
     - Dataset TYPE116 (MQM) variable QWHCATYP replaced by QWHCXTYP.
     - With OS/390 R2, IBM CRR product (dataset CACHE90 from VMACACHE)
        becomes dataset TYPE74CA from VMAC74. See TYPE74CA in MVS Tech
        Notes to prevent duplicate observations in TYPE74CA.
     - MXG now converts DB2 time stamps (like QWACBSC,QWACESC,QWHSSTCK)
       from GMT to local, but if you did that already in EXDB2ACC for
       DB2ACCT, you must remove your conversion code and let MXG do it.

  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, earlier.

 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:
    Summary:
     a. Install member MXGSAS as JCL Procedure MXGSAS in your PROCLIB.
     b. Allocate a 105-cyl PDS: MXG.V1414.MXG.SOURCLIB, and use IEBUPDTE
        to read the MXG tape to create the 3155+ member Source Library.
     c. Allocate a 1-cyl PDS:  MXG.V1414.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 V1414.USERID.SOURCLIB.
     d. Allocate a 1-cyl SAS Data Library:  MXG.V1414.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.V1414.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.V1414.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.V1414.USERID.SOURCLIB, then you must reinstall your site's
        tailoring for that IMAC, starting with the IMAC member from the
        MXG 14.14 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.14 in its own set of libraries. When
     parallel testing is complete and are ready to implement MXG 14.14
     in production, rename your three current MXG Production Libraries
     (MXG.MXG.SOURCLIB, MXG.USERID.SOURCLIB, and MXG.MXG.FORMATS) to
     (MXG.BACK.MXG.SOURCLIB, MXG.BACK.USERID.SOURCLIB, MXG.BACK.MXG....)
     and rename the MXG.V1414.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 "
"UNINITIALIZED", "TRUNCATED", "NEVER BEEN", "NOT FOUND", "CONVERT",
"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.

X.    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.

XI.   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:

  Dataset/
  Member   Change    Description

  many     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!
  many     14.318  Support for OS/390 Release 3 (Compatible).
  many     14.320  MXG is now distributed as a unnumbered dataset.
  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.
  ANALDB2R 14.286  DB2 Buffer statistics, Acct Detail, missed BP 1 & 2.
  ANALDB2R 14.340  DB2PM-like 4.1 reports & each buffer pool and package
  ANALDSET 14.064  Using Tape instead of DASD for ANALDSET fails.
  ANALSMF  14.178  SMF Simulator now tests a CISIZE of 18432 for 3390s.
  ASMDALO  14.222  Beta ASM failed due to careless changes.
  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.
  ASMTAPES 14.322  ML11 of the Tape Mount/Allocation monitor.  No SRB!
  ASMVTOC  14.003  Archaic assembly member was wrong on MXG 13.13
  ASUM70PR 14.319  ASUM70PR LPAR data LPnCAP and LPnSHARE new variables.
  ASUMAPAF 14.062  SORT ORDER error if you increase number of domains.
  ASUMDB2R 14.287  NUMPLANS now counts only DB2PARTY='S', ='O'.
  ASUMUOW  14.343  Combine CICSTRAN and DB2ACCT by Unit of Work
  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.
  BUILDPDB 14.210  SORTEDBY= asserted for PDB.JOBS/STEPS/PRINT/SMFINTRV
  BUILDPDB 14.245  Duplicate data protection for additional datasets.
  CICINTRV 14.188  Old CICINTRV replaced CICINTRZ, fixed for CICS 4.1.
  CICINTRV 14.211  CICS 4.1+ variable A02TTA missing in CICEODRV.
  DIFFDB2  14.167  DB2 4.1 DB2STATS interval missing due to QWHSISEQ.

  DIFFDB2  14.194  Extra obs in DB2STATB/DB2STATR, negative SEQCHECK.
  DIFFDB2  14.231  SEQCHECK logic in Change 14.267 was incorrect.
  FORMATS  14.255  Petabytes now formatted. (1024 Terabytes=1 Petabyte).
  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.
  IMACICOC 14.272  SAP Umbrella Trans Program/Tranname in OMUMBUSR/BPTC.
  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.
  MXGSAS   14.239  The TAILORNG= JCL parameter causes JCL error.
  MXGSAS   14.304  TAILORNG symbolic finally corrected in MXGSAS JCL.
  PROCSRCE 14.332  New member PROCSRCE is "Proc Source" for ASCII SAS.
  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.
  TYPE102  14.311  MXG now converts DB2 GMT time stamps to local.
  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).
  TYPE110  14.212  CICS 4.1+ incorrect MCTMNTAD GMT offset circumvented.
  TYPE116  14.087  Variable QWHCATYP was INCOMPATIBLY renamed QWHCXTYP.
  TYPE16   14.150  Support for DFSORT Release 13 APAR PN71337.
  TYPE21   14.256  Support for APAR OW22209, bytes read/written.
  TYPE26J2 14.303  INREASON wrong for LnnnnJRm syntax for JES2 INDEVICE.
  TYPE28   14.023  Some NPM VVR (VTAM Virtual Route) variables trashed.
  TYPE28   14.065  NPM APARs OW08565 and OW10584 for 3746/900 supported.
  TYPE28   14.335  Support for NPM APAR OW17875 added new subtype 2Ax.
  TYPE30   14.099  Auto Restart section INPUTs were incorrect.
  TYPE30   14.172  Variable EXECTM in TYPE30_V wrong if only subtype 3.
  TYPE37   14.213  Support for NETVIEW 3.1 type 37 changes.
  TYPE42   14.063  DASDMPL 1000 times too large in TYPE42DS.
  TYPE42   14.131  Support for APAR PN78083 required no change to MXG.
  TYPE42   14.309  Support for type 42 new subtype 19 + enhancements.
  TYPE6    14.009  Truncated PSF type 6 record INPUT STATEMENT EXCEEDED
  TYPE6156 14.242  Truncated catalog cell=04 caused STOPOVER.
  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.
  TYPE71   14.302  New Shared Paging variables were still wrong.
  TYPE72   14.085  MVS/ESA 5.2.2 variables overlooked in TYPE72GO.
  TYPE72   14.254  TYPE72GO vars R723CSCR,CSPA,CSPE were still wrong.
  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.
  TYPE74   14.236  Support for RMF type 74 subtype 100 IRLM long locks.
  TYPE74   14.291  Coupling Facility Structure Data PTF UW90312.
  TYPE74   14.328  R744SSIZ is in 4000, not 4096 units.
  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.
  TYPE80A  14.252  Invalid RACFTYPE=03 segment caused STOPOVER.
  TYPE88   14.066  INPUT STATEMENT EXCEEDED corrected.

  TYPE89   14.158  Support for Subtype 2 (Measured Usage Product Sumry).
  TYPE89   14.233  TYPE89 variable MULCURD wrong for Batch Pipes.
  TYPE99   14.069  TYPE99_2 now has obs for each period vice just first.
  TYPEAPAF 14.307  Support for APAF Millennium subtypes 31 and 32.
  TYPEAPAF 14.330  Amdahl APAF Version 3.0 records have been validated.
  TYPEBETA 14.050  INVALID DATA FOR BETASTRT and BETAEND with 1.6.5.
  TYPEBETA 14.084  INPUT STATEMENT EXCEEDED for SUBTYPE=41.
  TYPECACH 14.093  Support for IBM's Cache RMF Reporter CRR 1.7
  TYPECIMS 14.312  IMF flags in DBD section were not reset.
  TYPECMF  14.033  MXG now recognizes 3990 model 6 in CMF user SMF.
  TYPEDALO 14.215  Beta Version of MXG DASD Allocation Monitor
  TYPEDB2  14.011  DB2 4.1 type 101 subtype 1 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.
  TYPEDB2  14.217  DB2ACCT variables QTGA, QBGA trashed.
  TYPEDB2  14.226  DB2 Group Buffer Pool DB2GBPST repeats first segment.
  TYPEDB2  14.310  DB2GBPST dataset now deaccumulated and usable.
  TYPEDB2  14.311  MXG now converts DB2 GMT time stamps to local.
  TYPEDMON 14.125  Support for ASTEX 2.1 (INCOMPATIBLE).
  TYPEEDGS 14.029  DFSMS/rmm type "O" INPUT STATEMENT EXCEEDED RECORD.
  TYPEEDGS 14.289  DF/SMS Rmm records type V caused error.
  TYPEEDGS 14.297  Variables MVxxxx now input from type "V" record.
  TYPEEPMV 14.337  EPILOG for MVS I/O and ENQ data in EPMVEP, reports.
  TYPEEREP 14.021  INPUT STATEMENT EXCEEDED with EREP CLASRC='40'X.
  TYPEF127 14.032  Support for FACOM MSPE/EX PTF 93061 for ID=127 SMF.
  TYPEFTP  14.054  Support for FTP subtype 51x SMF record.
  TYPEHARB 14.229  Support for Interlink's Harbor 4.1 SMF record
  TYPEHIPR 14.015  Hipercache VSAM buffer field wrong in MXG 13.13.
  TYPEHMF  14.316  HMF subtype 5 with 1 segment INPUT EXCEEDED error.
  TYPEHSM  14.052  Short HSM ABARS FSRTYPE=15 INPUT STATEMENT EXCEEDED.
  TYPEHSM  14.232  FRSTVOLS CAN CONTAIN ONLY 30 BYTES written in error.
  TYPEHURN 14.230  No obs in HURN47 if no external segments.
  TYPEIDMS 14.238  Archaic IDMS 10.2.1 caused STOPOVER.
  TYPEIMS  14.030  Early testing IMS log records for IMS 5.1
  TYPEIMSA 14.017  VARIABLE SYSTEM IS UNINITIALIZED with ASMIMSLG.
  TYPEIMSA 14.244  SAP variables SAPTIMTR, SAPCPUT, SAPELTI wrong.
  TYPEIPAC 14.240  INVALID ARGUMENT TO FUNCTION MDY, dates not MMDDYY.
  TYPEM204 14.171  Support for MODEL204 Release 3.2.1 (INCOMPATIBLE).
  TYPEMOVT 14.168  Support for Omegmaon/VTAM V200 (INCOMPATIBLE).
  TYPEMWAI 14.249  Support for HP's Measureware for AIX.
  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.053  LUNETID PCSESSID VILUNAME in dataset NSPYLU trashed.
  TYPENSPY 14.111  Support for NETSPY Release 4.7 (compatible).
  TYPENTSM 14.293  Support for Windows NT measurement with NTSMF.
  TYPENTSM 14.299  Support for Windows NT measurement with NTSMF.
  TYPEOMSM 14.219  Support for Candle's Omegamon for SMS V150 (no chg!).
  TYPEOPC  14.077  INVALID MTD SUBTYPE, observations not output.
  TYPEORAC 14.103  Accounting data input incorrectly for ORACLE.
  TYPEORAC 14.247  Support for Oracle Release 7.2.3 SMF record.
  TYPEQAPM 14.098  Support for AS/400,OS/400 Release 3.6 (INCOMPATIBLE)
  TYPEQAPM 14.271  Support for AS/400,OS/400 Release 3.7 (INCOMPATIBLE)
  TYPERACF 14.243  Support for RACF 2.1 IRRDBU00 unload utility.
  TYPERMDS 14.092  Support for IBM's RMDS Version 2.2 (no change)
  TYPERMDS 14.300  RMDSARN/ARI missing in RMDS 1.3/1.4.
  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!
  TYPESTRS 14.284  Support for Demand Technology's Stress Test SMF.
  TYPESUIN 14.248  Support for Applied Software's SUPER IND$FILE SMF.
  TYPESYNC 14.115  Syncsort variables SORTBEGN/END midnight spanning.
  TYPETAND 14.223  INFILE statements for TANDCTLR/TANDLINE need LRECL.
  TYPETCP  14.276  FTPLOCAL,FTPREMOT not decoded after Change 14.040.
  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.
  TYPETMON 14.336  Support for Landmark The Monitor for CICS 1.5, COMPAT
  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).
  TYPETRSN 14.218  Support for Desktalk's TRENDSNMP SNMP IFENTRY data.
  TYPETSOM 14.334  Segmented TSO/MON recs with only DRU had STRTTIME=.;
  TYPEVM   14.008  INVALID DATA FOR PWCOUNT in VMID=06 VM Accounting.
  TYPEVSME 14.278  Support for VTAM Session Management Exit SMF record.
  TYPEWSF  14.143  Support for RDS's EOS Enterprise Output Solution
  TYPEWSF  14.228  Support for RSD's EOS Product SMF record.
  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.
  UTILCONT 14.216  Utility contents of SAS library, sizes in Megabytes.
  UTILGETM 14.018  Type 110 Subtype 2818 recognized and counted.
  VMXGHSM  14.235  SMS-related Class fields in both MCC and MCD added.
  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'
  YEAR2000 14.305  Format of year 2000 status revised with vendor fixes.

Inverse chronological list of all Changes:


===Changes thru 14.343 were included in MXG 14.14 dated Feb 21, 1997===

Changes 14.210 thru 14.343 were printed in MXG Newsletter THIRTY-ONE and
are listed in member CHANGESS (and member CHANGES of MXG Version 14.14).

Changes 14.001 thru 14.209 were printed in MXG Newsletter THIRTY and are
also listed in member CHANGESS (and member CHANGES of MXG Version 14.14)

****************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




         COPYRIGHT (C) 1996 BY MERRILL CONSULTANTS DALLAS TEXAS

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:
     DIFFDB2  14.108  BY VARIABLES ARE NOT PROPERLY SORTED DB2STATR
     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.
    NOTSORTED error for PDB.CICS in WEEKBLD, WEEKBLDT, and MONTHBLD.
    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

      Landmark
       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
      Candle
       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
      CA
       ASTEX 2.1                                           14.04
      Boole & Babbage
       IMF 3.1 (for IMS 5.1)                               12.12
      Memorex/Telex
       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

                            ABSTRACT

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).

                            Contents

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!"

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;
  IPLTIME=SMFTIME;
  INPUT @15 SMCAJWTM   PIB4.   /*SMF0JWT*/
        @19 SMFBUFF    PIB4.   /*SMF0BUF*/
        @23 VIRTSIZE   PIB4.   /*SMF0VST*/
        @27 SMCAOPT    PIB1.   /*SMF0OPT*/
        @28 REALSIZE   PIB4.   /*SMF0RST*/
  @;
  SMCAJWTM=60*SMCAJWTM;
  OUTPUT TYPE0;
  RETURN;
END;

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'
          KEEP=DOWNTM   IPLTIME  OPTDSETS OPTVOL   REALSIZE REC
               SMCAJWTM SMFBUFF  SYSTEM   VIRTSIZE ZDATE
               /* ADDED BY MVS/ESA 5.1 */
               PRODUCT  SYSNAME   SYSPLEX
               _KTY0
        )
%
MACRO _CDE0
IF ID=0 THEN DO;
 LABEL
  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'
  REALSIZE='REAL*MEMORY*SIZE(KBYTES)'

  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'
  VIRTSIZE='VIRTUAL*MEMORY*SIZE'
 ;
 LENGTH DEFAULT=&MXGLEN IPLTIME 8;
 FORMAT DOWNTM   SMCAJWTM     TIME12.2
        IPLTIME           DATETIME21.2
        ZDATE                  DATE9.
 ;
 IF LENGTH-OFFSMF NE 31 AND LENGTH-OFFSMF NE 56 THEN DO;
   NBAD0+1;
   IF NBAD0 LE 3 THEN
   PUT '***VMAC0.ERROR. INVALID TYPE 0 RECORD DETECTED. ' LENGTH= /
       '   BUT TRUE IPL RECORD SHOULD BE EITHER 31 OR 56 BYTES '
       '                RECORD IS DELETED ' _N_= SYSTEM= /
       +16 SMFTIME=;
   DELETE;
 END;
 IPLTIME=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*/
       @41+OFFSMF SYSNAME  $EBCDIC8. /*SYSNAME*PARAMETER*FROM IEASYSXX*/
       @49+OFFSMF SYSPLEX  $EBCDIC8. /*SYSPLEX*NAME FROM*COUPLEXX*/
 @;
 IF SYSTEM=PREVSYS AND IPLTIME GE PREVTIME THEN DOWNTM=IPLTIME-PREVTIME;
 OPTDSETS='NO ';
 IF SMCAOPT='...1....'B THEN OPTDSETS='YES';
 OPTVOL='NO ';
 IF SMCAOPT='...01...'B THEN OPTVOL='YES';
 REC='PERM';
 IF SMCAOPT='......1.'B THEN REC='ALL';
 SMCAJWTM=60*SMCAJWTM;
 %%INCLUDE SOURCLIB(EXTY0);  /* _LTY0 OUTPUTS TYPE0 */
 RETURN;
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:

       //SOURCLIB DD DSN=MXG.TAILOR.SOURCE.LIBRARY,DISP=SHR
       //         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:
   PROC FREQ DATA=TYPE0; TABLES IPLTIME; FORMAT IPLTIME DATETIME10.;
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
      ;INFILE SMF STOPOVER LENGTH=LENGTH COL=COL START=BEGINCPY
                  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() */
       END;
       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:

DATA
 _VAR0    _VAR0203 _VAR6  _VAR21 _VAR26J2 _VAR30 _VAR7072 _VAR71
 _VAR73   _VAR74   _VAR75 _VAR77 _VAR78   _VAR89 _VAR110  _VARDB2
 _VARTMNT _VARUSER
_SMF
 _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,
TYPE30_D, TYPE30_6, TYPE30OM, TYPE30MU, TYPETMNT, TYPETSWP and TYPETALO
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:
 TYPE70 TYPE70PR TYPE71   TYPE72   TYPE72DL TYPE72GO TYPE72MN TYPE72SC
 TYPE73 TYPE73L  TYPE73P  TYPE74   TYPE74CF TYPE74ST TYPE74TD TYPE75
 TYPE77 TYPE78   TYPE78CF TYPE78CU TYPE78IO TYPE78PA TYPE78SP TYPE78VS
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

VERSION DATE    MEMBERS  LINES    BYTES      MB    PAGES  DATASETS VARS
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
      //*  NOTE: PUT YOUR MODIFIED IMACRMFI MEMBER YOUR.SPECIAL.PDS
      //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
     buffering:

       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
     PN74925.


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)
      cost
      per        =   _____________________________________________
      CICS
      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
    can't.

    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
       transaction."
    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
       transid."
    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):
       NONE

  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:
    Summary:
     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
     (MXG.MXG.SOURCLIB, MXG.USERID.SOURCLIB, and MXG.MXG.FORMATS) to
     (MXG.BACK.MXG.SOURCLIB, MXG.BACK.USERID.SOURCLIB, MXG.BACK.MXG....)
     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 "
"UNINITIALIZED", "TRUNCATED", "NEVER BEEN", "NOT FOUND", "CONVERT",
"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:

  Dataset/
  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.
  TYPEBETA 14.050  INVALID DATA FOR BETASTRT and BETAEND with 1.6.5.
  TYPEBETA 14.084  INPUT STATEMENT EXCEEDED for SUBTYPE=41.
  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).
  TYPEEDGS 14.029  DFSMS/rmm type "O" INPUT STATEMENT EXCEEDED RECORD.
  TYPEEREP 14.021  INPUT STATEMENT EXCEEDED with EREP CLASRC='40'X.
  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.
  TYPEHSM  14.052  Short HSM ABARS FSRTYPE=15 INPUT STATEMENT EXCEEDED.
  TYPEIMS  14.030  Early testing IMS log records for IMS 5.1
  TYPEIMSA 14.017  VARIABLE SYSTEM IS UNINITIALIZED with ASMIMSLG.
  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.053  LUNETID PCSESSID VILUNAME in dataset NSPYLU trashed.
  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.

****************NEWSLETTER TWENTY-NINE**********************************












             MXG NEWSLETTER NUMBER TWENTY-NINE January 20, 1996

Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE

                         TABLE OF CONTENTS                          Page

I.    MXG Software Version Status.                                    3
 1.   MXG Software Version 13.13 dated January 20, 1996 shipped.      3
 2.   Future Plans for MXG Software.                                  7
II.   MXG Technical Notes                                             7
 1.   How do I not process CICS or DB2 data in BUILDPDB?              7
 2.   Year 2000 update                                                8
 3.   MXG Software is running in production on PCs/Workstations.      8
 4.   Printing MXG members NEWSLTRS, CHANGES, ACHAPxxx, etc.          9
 5.   Yes, you can communicate via the Internet.                     10
III.  MVS Technical Notes                                            10
 1.   APAR OW13849, incorrect space in DCOLLECT.                     10
 2.   APAR OW13839, incorrect type 66 SMF records.                   10
 3.   Erratic, very large values in type 72 fixed in OW11733.        10
 4.   APAR OW13536 adds new data to type 74 subtype 4 (TYPE74CF).    10
 5.   Zero obs in TYPE73 when MVS run under VM.                      10
 6.   APAR OW15036 rare SMF record with invalid SMFTIME.             11
 7.   IBM APAR PN72812 disables creation of SMF type 6 NPF records!  11
 8.   IBM APAR OW16847 large EXCPTOTL/EXCPCNT in type 30 VSAM        11
 9.   IBM APAR OW17629 negative ACTIVETM in TYPE72GO                 11
10.   IBM APAR OW13161 reports high PSF font library I/O             11
IV.   DB2 Technical Notes                                            11
V.    IMS Technical Notes                                            11
VI.   SAS Technical Notes                                            11
 1.   Repeated macro invocations (V6-MACRO=A673) fixed in TS425.     11
 2.   SAS Return Code 2096 or 2097 - bad //STEPLIB or multi-volume    11
 3.   Syntax errors if //SOURCLIB datasets blocksize different.      12
 4.   ASCII INFORMAT S370FRBn needs fix for unnormalized values.     12
 5.   SAS return code 318 with INFILE on high address on 3390-9.     12
 6.   PROC SQL easy, but may take more CPU to execute.               12
 7.   SAS ABENC 0C4 with TS410 when TMM allocates DASD to TAPE.      12
 8.   OPTIONS NOBYLINE allows BY-values in TITLE/FOOTNOTEs.          12
VII.  CICS Technical Notes                                           13
 1.   APAR PN71965 SURROGATE=YES/NO for terminal name.               13
 2.   What happened to SHRTSTOR and MAXTASK flags in CICSTRAN?       13
 3.   Disabling CMF might not reduce overhead.                       13
VIII. Incompatibilities and Installation of MXG 13.13.               14
 1.   Members and products incompatibly changed.                     14
 2.   Installation instructions.                                     15
IX.   Online Documentation of MXG Software.                          16
X.    Changes Log                                                    17
      Alphabetical list of important changes                         18
      Changes 13.324 thru 13.166                                  21-54
       (Changes 13.166-13.001 were in Newsletter 28)

         COPYRIGHT (C) 1996 BY MERRILL CONSULTANTS DALLAS TEXAS



  MXG Version Shipment Status

      MXG Version 13.13   is dated Jan 20, 1996, thru Change 13.323

      MXG Version 13.09  was dated Jan 10, 1996, thru Change 13.313

      MXG Version 13.08  was dated Dec 15, 1995, thru Change 13.290

      MXG Version 13.07  was dated Oct 30, 1995, thru Change 13.253

      MXG Version 13.06  was dated Oct 10, 1995, thru Change 13.225

      MXG Version 13.05  was dated Aug 21, 1995, thru Change 13.172

Early MXG Version 13.05  was dated Aug 11, 1995, thru Change 13.162

      Newsletter TWENTY-EIGHT, dtd Aug 21, 1995, thru Change 13.162

      MXG Version 13.04  was dated Jul 31, 1995, thru Change 13.149

      MXG Version 13.03  was dated Jul 19, 1995, thru Change 13.120

      MXG Version 13.02B was dated Jul  6, 1995, thru Change 13.111

      MXG Version 13.02A was dated Jun 28, 1995, thru Change 13.101

First MXG Version 13.02  was dated Jun 19, 1995, thru Change 13.095

Real  MXG Version 13.01  was dated May  3, 1995, thru Change 13.055

PreRe MXG Version 13.01  was dated Apr 26, 1995, thru Change 13.046

Early MXG Version 13.01  was dated Apr  1, 1995, thru Change 13.011

      MXG Version 12.12A was dated Mar 20, 1995, thru Change 12.328

      MXG Version 12.12  was dated Mar  1, 1995, thru Change 12.314

      MXG Newsletter TWENTY-SEVEN, Mar  1, 1995, thru Change 12.306


I. MXG Software Version Status.


 1. MXG Software Version 13.13, dated January 20, 1996, was shipped
    with this newsletter, NEWSLETTER TWENTY-NINE.


   Major enhancements added in MXG 13.13 dated Jan 20, 1996:


    Support for BETA 93 Release 1.06.50 (INCOMPATIBLE)
    MXGVERSN variable added to TYPE70 and RMFINTRV.
    Support for Frye Systems measurement of Netware LANS
    Support for Blue Line Software 4.03 and 4.04 (INCOMPAT) and 4.10.
    Sample conversion of DBaseIII files into SAS datasets.
    Workaround for SAP and IBM CICS 2.1 interleaved records.
    ASCII execution of BUILDPDB and PROC FORMATS now transparent.
    TESTMWX for improved CPU capture in User records.


   Major enhancements added in MXG 13.09 dated Jan 10, 1996:


    Support for DFSMS/MVS 1.3 DCOLLECT records (compatible).
    Support for DFSMS/MVS 1.3 VSAM RLS fields in type 64 (compatible).
    Support for DFSMS/MVS 1.3 VSAM RLS fields in type 42 (compatible).
    Support for MVS/ESA 5.2.2 Open Edition OMVS type 92 (INCOMPATIBLE).
    Support for MVS/ESA 5.2.2 Open Edition OMVS type 30 (compatible).
    Sample HSM reports and analysis suggestions
    TYPE6 INPUT STATEMENT EXCEEDED for PSF type 6 with OW10067.
    CICS/ESA 4.1 corrections (TRANTYPE, ELAPSTM, ENDTIME, IRESPTM)
    CICS/ESA 3.3 UNEXPECTED STATISTICS with STILEN=0 protection.
    MEASUREWARE (old HP-PCS) CPU time error in HPxxGLOB,HPxxAPPL.
    Landmark TMON for UNIX enhancements, corrections and errors.


   Major enhancements added in MXG 13.08 dated Dec 15, 1995:


    Support for MVS Solution's MVS Thruput Manager SMF record.
    Support for VM/ESA SQL/DS Remote User Accounting Record (INCOMPAT)
    Support for Landmark's TMON for UNIX.
    Support for TANDEM D20 and D30 and D40 releases.
    Support for DB2 4.1 IFCIDs 221, 222, and 231.
    Support for IDMS 12.01 (INCOMPATIBLE) was not correct until 13.08.
    Support for TOPSECRET 4.4 and 5.0 (INCOMPATIBLE) added.
    Support for HSM ABARS ABACKUP/ARECOVER FSR segment validated.
    Support for SAP 5.0 INCOMPATIBLE changes to type 110 journal data.
    MAINTLEV 7 of MXG Tape Mount and Allocation Monitor.
    Replacement for CICINTRV available for testing.
    "XMXGSUM" architecture now replaces VMXGSUM.
    SYSNAME and SYSPLEX added to PDB.JOBS/STEPS/PRINT.
    Default ASUMCICS summarization now includes USER.
    JESNR may show only four digits in TYPE26; IBM lied in ESA 5.2
    DEVPLX (duplex volume) address wrong, IBM worrying.

   Major enhancements added in MXG 13.07 dated Oct 30, 1995:

    Support for DB2 4.1.0 type 100 and 101 SMF records.
    Support for STK SILO HSC VIEW Command Subtype 8 SMF record.
    Support for MODEL204 Release 3.0
    CICS/ESA 4.1 CICSTRAN variables STRTTIME/ENDTIME now GMT-corrected.
    New IMACSPCK exit for SPIN decision override.
    New IMACZDAT localizes creation of ZDATE, for ease in reruns.
    Corrections for Landmark Version 2 TMDB support.

   Major enhancements added in MXG 13.06 dated Oct 10, 1995:

    ASMTAPES revision MAINTLEV 6 is now included, resolves errors.
    TYPETMON (TMON CICS 1.3) must now use RECFM=VB instead of RECFM=U.
    Support for Landmark TMON for DB2 Version 2.
    Support for Tandem D20 MEASURE CPU, Disk, and Process data records.
    Support for COM-PLETE Version 4.6 SMF record.
    Support for ISOGON Soft Audit Version 4.1.
    Support for HSM ABARS ABACKUP/ARECOVER FSR segment.
    Support for APAR OW14717 and APAR OW16039 for SMF type 42.
    Support for Omegamon for MVS/ESA V400 adds variables.
    Support for 3590 tape drives now complete.
    Support for APAR OW11142 adds new fields to TYPE64.
    Support for Software Engineering of America's TRMS SMF record.
    MXG 13.01-MXG 13.05, IMACJBCK caused deletion of RACF, ACF2 and DB2
     observations with job name of nulls.  See Change 13.183.
    ANALDB2R may still get FORMAT NOT FOUND, assorted minor DB2 fixes.

   Major enhancements added in MXG 13.05 dated Aug 21, 1995:

   Added after Newsletter TWENTY-EIGHT was printed:
    Support for MVS/ESA 5.2.2.
    Support for Candle Omegamon 300 SMF record (incompatible).
    Support for Landmark's TMON/MVS 1.2/1.3 additional subtypes.
    Preliminary support for 3590 tape drives.
    Correction for VM/ESA INVALID CONTROL RECORD error.
   Announced in Newsletter TWENTY-EIGHT:
    Support for the year 2000 (see MXG Technical note in NEWSLTRS, NL28)
    Support for OpenMVS File System I/O type 92 SMF record.
    Support for MVS/ESA 5.2 System Logger Data type 88 SMF record
    Support for EREP (SYS1.LOGREC) records.
    Deaccumulation of HMF records.
    Final (?) Correction to ANALDB2R Statistics and Audit Reports.
     If you use either the DB2 Statistics reports or DB2 Audit Reports,
     you must request MXG 13.05 for the ANALDB2R corrections to errors
     introduced in MXG 12.12 (Statistics) or MXG 13.01 (Audit) that were
     not fixed until now (I apologize for the careless coding and lack
     of validation of report output that took seven iterations to fix).
     The Audit errors were actually corrected in 13.03, but Statistics
     still had four values that were not corrected until MXG 13.05.
     The more-commonly-used DB2 Accounting Reports had no errors.
    MAINTLEV 6 of ASMTAPES was listed in Newsletter 28, but is not on
     the MXG 13.05 tape; see text of Change 13.163.

   Major enhancements added in MXG 13.04 dated Jul 31, 1995:

    Support for NetCompress SMF records.
    Support for Packet/Main SMF records.
    Support for Kodak AXCIS Optical Disk SMF records.

   Major enhancements added in MXG 13.03 dated Jul 19, 1995:

    More fixes for DB2 Statistics Reports, a fix for DB2 Audit Reports.
    TYPE116 (MQM) validation and correction.

   Major enhancements added in MXG 13.02B dated Jul  6, 1995:

    Correction to DB2 Statistics Summary and Audit Reports
    MXG Position Paper on Support for Year2000 in member YEAR2000.

   Major enhancements added in MXG 13.02A dated Jun 28, 1995:

    Correction to DB2 PMSSTA01/02 Statistics Summary Reports.
    Final (?) revisions to XMXGSUM.

   Major enhancements added in MXG 13.02 dated Jun 19, 1995:

    Support for MVS/ESA 5.2 (compatible) changes 24, 30, and 42 records.
    Support for OPC Release 3.0 (INCOMPATIBLE).
    Support for DFSORT Release 13.0 (INCOMPATIBLE).
    Support for TMS (CA-1) Release 5.1 (compatible).
    Support for Antares' HURON ObjectStar SMF record.
    Support for TYPE32 APARS OW10393 (causes error) and OW12856 (none).
    Support for SAP Release 5.0 CICS accounting in type 110.
    Support for ACS Wylbur Accounting SMF record
    Support for Sterling SAMS Storage Automation SMF record.
    Support for LEGENT's AUTOMATE SMF record.
    DB2 Audit SQL text corrections.
    Support for APAR OW08641 for NPM Version 2.2

   Major enhancements added in MXG 13.01 dated May  3, 1995:

    Support for NETSPY Release 4.6 (compatible), divide by zero fixes.
    Support for HP PCS current version on HPUX, AIX, and SUN unix.
    Support for OS/400 Version 3.1.0 (was wrong in MXG 12.12/12.12A).
    Support for TCP/IP APAR PN69321-PN69322.
    Support for Sterling SOLVE NCL CPU-time accounting user SMF.
    Support for HMF SMF record subtypes 4 and 5.
    Support for APAR OW04653 added variables to TYPE74ST dataset.
    Support for IBM's IRRDBU00 RACF Database Unload.
    ASMRMFV 0C4 correction and enhancements for RMF VSAM processing.
    ANALCNCR enhancements and validation.
    XMXGSUM  enhancements and validation.
    TYPE116 (MQM) validation and correction.

   Major enhancements added in MXG 12.12A dated Mar 20, 1995:

    Twelve MXG 12.12 members had errors that are now fixed:

      ANALCNCR ANALDB2C ANALDB2R ANALPATH ANALTALO IMACICSA
      TRNDTALO VMAC80A  VMAC110  VMACILKA TYPEMON8 TYPETMON

    Support for Memorex/Telex LMS Version 3.1 (INCOMPATIBLE).

  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
      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 4.2                     when G.A.           ??.??
      CRR 1.6                          Jun 24, 1994.       12.02
      DB2 2.2.0                                1990         8.8
      DB2 2.3.0                        Oct 28, 1991.       10.01
      DB2 3.1.0                        Dec 17, 1993.       13.02A
      DB2 4.1.0                        Nov  7, 1995        13.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
      VM/ESA  1.1.1                    Dec 27, 1991.       10.01
      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              Required

      Landmark
       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
      Candle
       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 MVS - last MXG change 1992             12.12
       Omegamon for DB2 Version 2.1/2.2                    13.05
       Omegamon for VTAM V160                              12.04A
       Omegamon for SMS V100/V110                          12.03
      Boole & Babbage
       IMF 3.1 (for IMS 5.1)                               12.12
      Memorex/Telex
       LMS 3.1                                             12.12A


 2. Future Plans for MXG Software.

   a. Support for TREND from Desktalk Systems.

   SNMP support in MXG is in planning and should be available in second
   quarter, 1996.  As I announced at CMG, MXG will support the data from
   SNMP and its RMON extensions that is captured by David Kauffman's new
   "TREND" product; the company is Desktalk Systems, at 310-323-5998).

   SNMP-literate users who have tried alternative products have glowing
   reports for TREND, as it is a truly superior SNMP poller and monitor.
   Trend understands how to deal correctly with missing data (most SNMP
   agents return accumulated counters, and when a poll is missed, the
   poller must be smart enough to recognize that a sample was missed and
   then properly de-accumulate, accounting for the missed sample) and
   TREND understands skewed data (polling 1000 SNMP agents is not done
   in zero time, so building interval data when the time of capture is
   skewed is a non-trivial task!).  Trend stores its data in a SYBASE
   database.  Bernie Davidovich and I have extracted the SYBASE data
   into a flat file for input in a SAS DATA step, but I have reason to
   believe that SAS/ACCESS to SYBASE will be much faster (both to write
   and in execution run time), easier to maintain, and will eliminate
   the extract step and its flat file, so I am redirecting my research
   to create MXG-style (i.e., labeled, formatted, consistently-named)
   SAS datasets from the TREND-captured data.  As this involves learning
   SAS/ACCESS, TCP/IP and SYBASE, I hope that 2nd quarter is realistic.
   If you are interested in MXG support for TREND, please fax/e-mail to
   ask to be put on the interested parties list.

   I used to think that SNMP measured only Routers, Hubs, and Switches,
   but there are now agents that measure Unix hosts, Oracle databases,
   and I hear Windows NT SNMP agents are under development as well, so
   SNMP may be a very attractive network data source for MXG users.

   b. Support for Windows NT monitor data.

   I am aware there is data created by Windows NT, and it is also on
   my schedule to develop support during the first half of 1996.

II.   MXG Technical Notes.

 1.   How do I not process CICS, or DB2 data in BUILDPDB?
    - If you do not create type 110 (CICS) or type 100,101,102 (DB2) SMF
      records, then there is nothing you need to do.  Yes, there will be
      built the PDB.CICxxxxx and PDB.DB2xxxxx datasets, but they will
      have 0 observations, and there is insignificant cost in carrying
      these zero observation data sets along.  If zero observation data
      sets still offend you, you can tailor IMACCICS or IMACDB2 to
      change the default DD names to WORK, and then neither CICxxxxx nor
      DB2xxxxx datasets will exist in your PDB libraries.
    - If there are or might be type 100,101,102, or 110 SMF records in
      your input SMF file, you can delete those unwanted records by
      tailoring member IMACFILE, which is invoked after each SMF record
      header has been read in.  You could insert in that member:
        IF ID=110 THEN DELETE;
      and your CICS records would be discarded.  Note that if you make
      this change in your installation tailoring USERID.SOURCLIB
      dataset, that all MXG programs reading SMF, and not just BUILDPDB,
      will be deleting type 110 records.  To tailor just the BUILDPDB
      execution you may want to put the tailored IMACFILE member in its
      own PDS in only the BUILDPDB job's SOURCLIB concatenation; in that
      way, you could still use TYPE110 to process your CICS data, should
      the need arise.

 2.   Year 2000 update.  What happens to your trend data base when MXG
      changed the FORMAT of date variables from "DATE7." to "DATE9"?  In
      all of the supplied MXG trending members, the SET statement has
      the WEEK.dataset listed first, then the TREND.dataset second, so
      that all variable attributes are acquired from the WEEK dataset
      (i.e., newly created attributes), so the DATE9 format will become
      the TREND format.  If you have your own trending or summarization
      code you will need to verify that the new dataset is listed first;
      if not, then your output dataset will still have the old format.
      As a reminder, member YEAR2000 contains the complete discussion
      of MXG Support for the year 2000, and should be provided to your
      company's year 2000 project team leader.

 3.  MXG Software is running in production on PCs and workstations,
     thanks to 32-bit operating systems and 32-bit versions of SAS!

   a. However, I still strongly recommend that you use SAS on the
      mainframe to create, manage, and warehouse the MXG Performance
      Data Base, because of the industrial strength MVS provides for
      backup, data integrity, security and reliability.  Once you have
      built your SAS data library ("PDBs") with MVS, you can either
      use mainframe SAS for your analysis under TSO or batch, or
      you can selectively download only the PDB data you need to the
      interactive platform of your choice for your analysis and
      reporting.  Some specific advantages of building your SAS data
      libraries under MVS are:
       - The time to download raw data is eliminated.  At one megabyte
         per minute, 500MB of SMF data requires over 8 hours to move!
       - Compressed monitor data (eg., Landmark and Candle) can be read
         and decompressed in one operation with an INFILE exit, but that
         INFILE exit architecture does not exist on ASCII platforms, so
         the raw data would have to be un-compressed on the mainframe
         and then downloaded, requiring more DASD on the mainframe and
         more time to download.  (Even if the INFILE exit were to exist,
         the decompression algorithms exist only in IBM Assembler!).
       - MVS has no fixed limit to the number of concurrent files that
         can be open, so all MXG programs can execute under MVS.  But
         most ASCII platforms have a fixed limit of 255 open files, so
         some MXG programs (for example, TYPE102 to read all of the 250+
         subtypes of the DB2 trace record) cannot be executed at all.
         Furthermore, on MVS, only one file is open per SAS data library
         but on ASCII, each SAS data set (not library) requires a file.
       - For memory-intensive programs (eg., BUILDPDB!), MVS provides
         parameters (REGION, MEMSIZE) by which you can specify more
         virtual storage, and MVS diagnostics (SYSUDUMP) let you analyze
         where virtual storage is consumed.  ASCII systems have no such
         capability, and an "OUT OF MEMORY" error under ASCII is fatal.
       - MVS has a single DD name pointing to a single library (DSN)
         that contains all of the many SAS datasets in a PDB.  ASCII
         systems create individual files for each SAS dataset, so you
         will have to manipulate directory names manually, and without a
         system catalog, requiring more administrative time to manage
         MXG execution under ASCII than under MVS.
       - Most of all, MXG runs reliably under MVS, which is a very well
         understood, well documented, and well supported environment for
         mission critical applications like MXG;  ASCII systems simply
         don't have this heritage and as a result, strange failures may
         be hard to replicate, diagnose or circumvent under ASCII.

   b. But if MXG is the only user of SAS on the mainframe, it may be
      hard to cost-justify that mainframe SAS license.  My benchmarks
      show that it is technically feasible for small to medium sites
      to move their MXG processing from the mainframe to a PC platform
      using either OS/2 or WINDOWS 95, with significant cost savings,
      or to UNIX platforms with somewhat smaller savings (because UNIX
      hardware and software cost more than OS/2 or WINDOWS 95!).
      However, those apparent dollar savings in license fees might be
      absorbed in the additional time you will spend managing the "job
      streams" and data files, archiving from disk to backup tape, etc.!


   c. The BUILDPDB benchmark that reads a 200MB daily SMF file (see MXG
      Newsletter 25) shows that OS/2 WARP 3.0 or WINDOWS 95 running on a
      100MHZ PENTIUM are as fast as MVS/ESA 4.3 running on a 3090-400S!

      My first benchmark had WINDOWS 95 50% slower than OS/2, but that
      was due to the SAS SORTSIZE parameter.  Setting SORTSIZE=4M for
      WINDOWS 95 produced identical run times with OS/2 (although OS/2
      required only SORTSIZE=2M). However, the WINDOWS NT runs took
      twice as long (and as the data step under NT took 46 minutes, it
      is not due to SORTSIZE); NT performance will be examined later!
      The PENTIUM 100 numbers were measured on the CMG benchmark system
      (which was given away to a lucky attendee!) with identical disk
      configurations:

          Hardware       System           SAS       Run Time

          486-33         WIN 3.1          6.08       270 min

          PC SERVER 500  MVS 5.2          6.08       130 min

          PENTIUM 90     WIN 3.1          6.08       101 min

          PENTIUM 100    WINDOWS NT       6.11        62 min
          PENTIUM 100    WINDOWS 95       6.11        35 min
          PENTIUM 100    OS/2 WARP 3.0    6.11        35 min

          3090-400S      MVS/ESA 4.3      6.08        30 min

      The PENTIUM 100 with 32MB RAM and three 1.6MB IDE drives and
      cost less than $5000.00!

   d. An Australian site that never had SAS nor MXG on their mainframe
      installed SAS and MXG under OS/2 on a 100MHZ 486 DX4 machine for
      capacity planning.  The daily download of their 150MB of raw data
      (70MB-DB2, 70MB-Landmark TMVS, 10MB other SMF) takes TCP/IP about
      two hours, and MXG processing takes 30 minutes!


 4.  Printing MXG members NEWSLTRS, CHANGESS, ACHAPxx and ADOCxxxx with
     their imbedded _PAGE_ pagination string can be done with either
     MS WORD or WORDPERFECT with these suggestions from Chuck Hopf:
      - Import the desired MXG member into your word processor.
      - Using the EDIT bar, SELECT ALL.
      - Change the font to COURIER 8PT.
      - Change the margins to 1" all around.
      - Replace all _PAGE_ with a "hard page return".
      - Print on your favorite printer.

 5.  Yes, you can communicate with Merrill Consultants via the Internet;
     our address is
                      BARRY@MXG.COM
       Note: (originally was mxg@e-mail.com, changed Feb 1997)
     However, I only check for E-Mail in the morning, once a day, so you
     will usually get faster response if you telephone or send a fax
     direct (or you can alert me via a fax that E-mail is awaiting).
        In actuality, MXG Technician Bruce Widlund logs on for me each
        morning, prints any mail, and then faxes it across town to me,
        because I work best from a hard copy!
     I really prefer that you telephone when you can, because I think I
     give better technical support with one-on-one interactivty, and it
     is hard for you to give me all of the details via fax or e-mail.
     If I cannot respond via telephone, I strongly prefer to respond via
     fax (since I can hand-write a response offline and without changing
     computer screens, and it takes a lot more type to type a response,
     format it, check the spelling, etc., and then send it!) so I do ask
     you include your fax number if you send E-Mail.
     However, for long prints of error messages (i.e, a hex dump of an
     SMF record from the SAS log), the Internet is excellent, since
     Bruce will upload your file to our MVS host and I can examine the
     dump online, and you can also send SMF binary files via Internet
     so that I can test with your data, so I am not really anti The Net!
     Use whichever method is best for you, and I'll get back to you!



III.  MVS Technical Notes after Newsletter TWENTY-EIGHT.

 1.   APAR OW13849 reports incorrect space in DCOLLECT variable DCDUSESP
      for a PDSE library that was an ISPF data set.  No fix yet.

 2.   APAR OW13839 reports creation of SMF type 66 records that should
      not have been created (event was READ VVR, not UPDATE), and were
      created with incorrect values.  Records will no longer be created.

 3.   Erratic, very large values in type 72 data may be corrected by
      APAR OW11733 (site has OW06770 and OW09814 installed and still had
      occasional bad values), affecting variables ACTIVETM, SERVICE,
      MSOUNITS,IOUNITS,CPUUNITS,SRBUNITS and also CPUTCBTM, CPUSRBTM
      and CPUTM in TYPE72 (which also affects dataset RMFINTRV).
      Records with raw values of '7FFFFFFF'x are symptom of the error.
      These incorrect values may occur with MVS/ESA 4.3, 5.1, or 5.2,
      and resulted from:
      - transactions were started when the initiator started, rather
        than when they ran their first job, or
      - delay samples were not corrected for swapped out ASIDs, or
      - FORCEd ASIDs did not get their workload data rolled up at FORCE,
      - data was not accumulated at MemTerm (Cancel).

 4.   APAR OW13536 adds new data to TYPE74CF (type 74 subtype 4), but
      the record changes are not yet documented.  This note will be
      updated when I have the documentation in hand.

 5.   Zero observations in dataset TYPE73 when MVS was run under VM at
      a disaster recovery site, because SMF73FG4 bit was ON, indicating
      "block entry is not valid".  IBM said the reason could be:
      a) processor does not support the CHSC channel service call instr
      b) CHSC requires RMCHINFO to be specified as a VM option
      c) CHSC is not supported on VM/ESA 2.1

 6.   APAR OW15036 corrects rare occurrence of SMF records with invalid
      date or time value in the SMF time stamp field, because of midnite
      logic exposure that is fixed by that APAR.

 7.   IBM APAR PN72812 disables creation of SMF type 6 records for print
      events from NPF (Network Print Facility).  NPF is a part of
      TCP/IP, and sends print lines to attached printers, replacing
      non-free products like VPS.  While some fields in the NPF record
      are blank or zero, and while the PRINTIME value is not the start
      of print but rather is the start-up time of the NPF FSS, the type
      6 record is still a useful event record, timestamping when print
      completed and counting lines sent to the printer.  I argued
      verbally with the IBM Change Team that it was wrong to turn off a
      useful SMF record, instead of fixing bad fields, and pointed out
      that competing products provide SMF records, but my arguments were
      to no avail, as IBM decided not to change their PTF.  They did
      document a requirement for the record as an enhancement, which was
      then forwarded to their development group, but I fear that a new
      version of TCP/IP that incorporates the PTF (and thus prevents you
      from creating the SMF record) may show up before a version that
      supports the record is created!  Thus if you need to track usage
      of NPF, I suggest that you NOT install the PTF and instead exploit
      the useful information that is in the NPF SMF record!

 8.   IBM APAR OW16847 corrects very large values for EXCPTOTL/SMF30TEP
      and EXCPCNT/SMF30BLK (in the TIOT segment for each DDname, which
      becomes EXCP count by device type).  The APAR says "for DB2" but
      the PTF appears to apply to all VSAM, not just DB2 use of VSAM.

 9.   IBM APAR OW17629 reports negative transaction active time in
      R723CTAT (MXG variable ACTIVETM in TYPE72GO for goal mode) because
      the transaction active time had not yet been updated by IRARMHIT.
      A "negative" value to IBM causes a very large value in MXG, as the
      PIB format treats the sign bit as data (and that way, a small
      negative value that might be missed will not be missed in MXG!).

10.   IBM APAR OW13161 reports high (and unnecessary) I/O activity to
      the PSF font library DASD device for jobs that use both coded font
      names and code page/character set pair (cp/fn pair) names to reuse
      the same font.  PSF/MVS 2.1.0, 2.2.1 and 2.2.0 are affected.

IV.   DB2 Technical Notes.
V.    IMS Technical Notes.
VI.   SAS Technical Notes.

 1.   Repeated macro invocations can generate out of memory errors; this
      SAS error is fixed by V6-MACRO-A673, which is now included in SAS
      6.08 maintenance level TS425.  This has not affected any real MXG
      job, but in running TESTANAL, which invokes all of the ANALxxxx
      members (almost all of which heavily use %MACROs), that test job
      needed MEMSIZE=53M instead of MEMSIZE=46M when XMXGSUM replaced
      VMXGSUM, because XMXGSUM invokes more macros in optimizing itself
      to read-in only what is needed.  Old "XMXGSUM" replaced VMXGSUM in
      MXG 13.08 (see Change 13.276), so there is a very small risk that
      an existing job that uses VMXGSUM might need a larger MEMSIZE and
      REGION parameter; that exposure is mitigated if you are at TS425.

 2.   SAS Return Code 2096 or 2097, with nothing printed on the SAS log
      (with neither the SAS nor the MXG Initialization messages), and
      lots of CPU time used, resulted when incomplete //STEPLIB DD was
      specified.  The //STEPLIB DD contained only the main SAS library,
      and did not include the maintenance library, causing the failure.
      Note added Sep 1997:  Return Code 2096, perhaps accompanied by an
      ABEND 0C4 also results if UNIT=(SYSDA,3) is specified (that is not
      the correct way to create multi-volume SAS libraries - search the
      member NEWSLTRS for "multi-vol" for the correct technique).

 3.   Strange syntax errors that are traced to missing chunks of source
      code (like 56 lines of RMFINTRV that were not printed on the SAS
      log when OPTIONS SOURCE SOURCE2 MACROGEN; was specified) have been
      caused by dissimilar block sizes of the PDS libraries in the job's
      //SOURCLIB DD concatenation.  Using the same value for BLKSIZE
      for all datasets in the concatenation eliminated the error.

 4.   Informat S370FRBn is used under ASCII SAS to input mainframe RBn
      "real binary" or "floating point" numbers, but it produces wrong
      values if the floating point number is not "normalized".  While
      '4E000001'x is a floating point representation of the decimal one,
      that value is "unnormalized" because of the leading zeroes in the
      mantissa; '41100000'x is the normalized value for one.  The RB
      format on the mainframe accidentally worked with unnormalized
      values, because there was an arithmetic operation performed prior
      to conversion, and mainframe floating point operations always
      output normalized values!  The specification for S370FRBn has been
      changed by SAS Institute to also support unnormalized numbers in
      future versions, and SAS has created release-specific fixes (DLLs)
      for OS/2 6.10 and 6.11 that are available now in MXG source (see
      Change 13.239).  Landmark's TMON CICS product is the only product
      (thus far!) that actually creates unnormalized values, but not all
      instances of RB data in all vendor records have been examined.
      SAS Tracking 4118427 confirms that SAS Institute has re-defined
      the S370FRB specification to process all float values in future
      releases on each ASCII platform.

 5.   SAS return code of 318 with SAS 6.08 at TS415 under MVS when an OS
      dataset at the back end (track 100,000) of a 3390-9 ("Fat" DASD)
      was read with an INFILE statement.  When the dataset was copied to
      a 3390-3 volume, the read was successful.  SAS Tracking 4420016.

 6.   PROC SQL is a lot easier to code, but it may take significantly
      more resources than the DATA steps and PROC SORTs used in ANALDSET
      logic to merge of TYPE1415, TYPE64, and TYPE30_4 datasets.  The
      SMF processing phase took 13 CPU minutes and 24 elapsed minutes to
      create the 800,000 TYPE1415, 80,000 TYPE64 and 74,000 TYPE30_4
      observations.  PROC SQL then used 318 CPU seconds and 20 elapsed
      minutes, while DATA/SORTS used only 90 CPU seconds in the same
      elapsed time.  This may not be generalizable, but is shared with
      you as a single data point.  Any other experience like this?

 7.   SAS ABEND 0C4 with TS410 can erratically occur in SMS environment,
      if a SAS data library's DDNAME (for example, CICSTRAN) is changed
      from TAPE to DASD by TMM (Tape-Mount-Management) and the VOLCOUNT
      in TMM is greater than one.  That creates an MVS multi-volume
      sequential-only dataset, which is not supported by SAS (see MXG
      Newsletters 23 and 26 for the correct techniques to allocate a
      multi-volume data library). With the TMM re-direction, the 0C4
      occurs when the first volume allocation was not large enough for
      the entire SAS data library.  SAS may correct in Version 7, but
      your SMS sysprog can show you how to avoid TMM redirection.

 8.   The OPTIONS NOBYLINE statement allows you to place the BY values
      inside the TITLE and FOOTNOTE statements for pretty reports, but
      SAS/GRAPH does not handle the BY groups correctly.  All you will
      get is the last BY group's value on every graph.  There is no fix
      but you can circumvent the problem by adding the NOCACHE parameter
      to the PROC statement, and the expected reports will be printed.

VII.  CICS Technical Notes.

 1.   CICS APAR PN71965 creates new parameter SURROGATE=YES/NO for the
      DFMHCT TYPE=INITIAL macro, that affects the contents of variables
      TERMINAL and LUNAME in CICSTRAN datasets in CICS 4.1 and later.
      Prior to CICS 4.1, TERMINAL/LUNAME contained the surrogate TERMID
      for the AOR record when directly connected to the TOR, but in 4.1,
      TERMINAL/LUNAME for the AOR record were changed to contain the
      MRO Session ID.  This parameter allows installations to choose
      which value is put in the record by CICS.  SURROGATE=NO is the
      default.  See member ADOC110, dataset CICSTRAN, description of
      variables TERMINAL or LUNAME for complete discussion.

 2.   Whatever happened to SHRTSTOR and MAXTASK flags in CICSTRAN data?

      IBM deleted the bits in CICS/ESA 3.1.1, so those flags are always
      blank and cannot be used to identify which transactions were in
      execution during those events.

      In CICS 4.1, IBM did add useful new variables MXTDIOCN,MXTDIOTM to
      the CICSTRAN dataset, and they record the count of times AND the
      duration that the transaction waited for its first dispatch due to
      MAXTASK delay, so at least MAXTASK delays can be measured.

      There are other MAXTASK/SHRTSTOR measures that have been added to
      the Statistics subtype of the type 110 record (but then some of
      these new data was removed from later releases!):

      CICS 3.1.1 added the new CICSDS dataset with MAXTASK/AMAXTASK
      counts, but this data no longer exists in CICS 4.1:
              for:       MAXTASK     AMAXTASK
              defined:   DSGTL       DSGAMXTL
              current:   DSGCNT      DSGAMXTC
              peak cnt:  DSTPNT      DSTAMXTP
              times at:  DSGTAMXT
      CICS 4.1 added the new CICXMG dataset with counts of times and the
      duration at MAXTASK in variables XMGMXT, XMGTAMXT.

      CICS 3.1 added T-Class statistics in the new CICTCLR dataset, with
      Class Number, value, current, peak, and times at max in variables
      A15KTCLS,A15MXT,A15MXTC,A15MXTR,A15MXTM, but this dataset too will
      have zero observations in CICS 4.1

      CICS 3.1 thru CICS 4.1 add the count and duration of times the DSA
      was short on storage in the variables SMSSOS,SMSTSOS in the new
      CICSMDSA dataset, and the count of times that VTAM was short on
      storage is in variable A03VTSOS in dataset CICVT.

 3.   One site decided to turn off type 110 recording to measure the CPU
      cost of CICS monitoring (previously reported to be between 7% and
      11% by IBM).  Upon disabling CMF recording, they found only a 2%
      CPU savings!  It turns out that the cause was Omegamon for CICS;
      even though you turn off CMF, Omegamon still needs to measure the
      CICS system (so it can alert you to problems!) and in the absence
      of CMF, Omegamon itself monitors your CICS system, hence the small
      savings with CMF disabled!


VIII. Incompatibilities and Installation of MXG 13.13.

 1. Incompatibilities introduced in MXG 13.13 (since MXG 12.12):

  a- IMACs that were changed (if they exist in your USERID.SOURCLIB, you
     must refit your tailoring, starting with the new IMAC member):

     IMACPDB  (Change 13.198)
     IMACJBCK (Change 13.183)

  b- Other incompatibility changes:

     Member FORMATS cannot be executed as-is under SAS Version 5.18,
     but can be tailored if you are still running that archaic version.
     See Change 13.127

     User-written invocations of VMXGSUM with OUTCODE= to recalculate
     the DATETIME= variable may be wrong.  See Change 13.152.

  c- These products were incompatibly changed by their vendor, and they
     require MXG 13.xx as indicated:

     Memorex/Telex LMS 3.1     (Change 12.326, MXG 12.12A)
     OPC Release 3.0           (Change 13.092, MXG 13.02)
     DFSORT Release 13         (Change 13.092, MXG 13.02)
     Hipercache 4.1.x          (Change 13.120, MXG 13.03)
     BETA 93 Release 1.06.50   (Change 13.304, MXG 13.09)
     OMEGAMON/MVS Version 300  (Change 13.170, MXG 13.05)
     IDMS 12.01   Maint 9506   (Change 13.223, MXG 13.06)
     TMON/CICS 1.3             (Change 13.204, MXG 13.06)
     SAP 5.0 type 110 journal  (Change 13.261, MXG 13.08)
     TOPSECRET 4.4/5.0         (Change 13.254, MXG 13.08)
     OPEN EDITION MVS 5.2.2    (Change 13.313, MXG 13.13)
     VM/ESA SQL/DS Accounting  (Change 13.xxx, MXG 13.yy)
     IMS 5.1                   (Change 13.265, MXG 13.xx)
     Model204 Release 3.0      (Change 13.249, MXG 13.xx)
     TMON/DB2 Version 2        (Change 13.224, MXG 13.xx)
     TYPE42 APAR OW14717       (Change 13.217, MXG 13.xx)


 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:
    Summary:
     a. Install member MXGSAS as JCL Procedure MXGSAS in your PROCLIB.
     b. Allocate a 105-cyl PDS: MXG.V1313.MXG.SOURCLIB, and use IEBUPDTE
        to read the MXG tape to create the 2937+ member Source Library.
     c. Allocate a 1-cyl PDS:  MXG.V1313.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 V1313.USERID.SOURCLIB.
     d. Allocate a 1-cyl SAS Data Library:  MXG.V1313.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.V1313.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.V1313.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.V1313.USERID.SOURCLIB, then you must reinstall your site's
        tailoring for that IMAC, starting with the IMAC member from the
        MXG 13.13 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 13.13 in its own set of libraries. When
     parallel testing is complete and are ready to implement MXG 13.13
     in production, rename your three current MXG Production Libraries
     (MXG.MXG.SOURCLIB, MXG.USERID.SOURCLIB, and MXG.MXG.FORMATS) to
     (MXG.BACK.MXG.SOURCLIB, MXG.BACK.USERID.SOURCLIB, MXG.BACK.MXG....)
     and rename the MXG.V1313.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 "
"UNINITIALIZED", "TRUNCATED", "NEVER BEEN", "NOT FOUND", "CONVERT",
"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 12.12:

  Dataset/
  Member   Change    Description

  Many     13.190  Format of UOWTIME changed to DATETIME25.6 everywhere.
  Many     13.198  Support for 3590 tape drives.
  ADOCFRYE 13.317  Sample conversion of DBaseIII files into SAS datasets
  ANALALL  13.076  Print of All SMF records from a job was enhanced.
  ANALAPAF 13.014  Semicolon missing in report program.
  ANALCISH 13.046  Report enhancements for CICS Shutdown reports.
  ANALCISH 13.113  CICS Shutdown may cause NOTSORTED error.
  ANALCISH 13.274  Lots of page ejects corrected.
  ANALCNCR 13.036  Validation closed several exposures.
  ANALCNCR 13.047  ANALCNCR failed when invoked by ANALTAPE or ANALMTP.
  ANALCNCR 13.280  Correction of Dataset Not Found condition.
  ANALDB2C 12.318  NO MATCHING IF error because colon vice semicolon.
  ANALDB2R 12.328  Syntax errors with PMACC01 or PMACC02 report.
  ANALDB2R 13.042  DBID/OBID mapping enhanced to include timestamp.
  ANALDB2R 13.058  BY VARIABLE STRTTIME IS NOT ON INPUT DATA error.
  ANALDB2R 13.079  DB2 Statistics Summary PMSTA01, Audit report fixes.
  ANALDB2R 13.106  Statistics Report correction, FORMAT NOT FOUND.
  ANALDB2R 13.118  Final (?) corrections to Statistics and Audit Reports
  ANALDB2R 13.159  More Statistics Report errors, but at field level.
  ANALDB2R 13.191  $DB2DBID FORMAT NOT FOUND may still occur in 13.05.
  ANALDB2R 13.278  Enhancements only!  No errors reported!
  ANALHSM  13.307  Analysis of HSM SMF record HSMFSRST data.
  ANALPATH 12.325  Cross-System DASD Reports cols ran together.
  ANALPATH 13.207  INVALID ARGUMENT error in report program.
  ANALPGNS 13.003  Failed if you changed RMFINTRV duration in IMACRMFI.
  ANALRMFR 13.134  Data/time selection crossing midnight failed.
  ANALTALO 12.327  VARIABLE NOT FOUND error.
  ANALTALO 13.006  Variable SYSTEM NOT FOUND in MXG 12.12A.
  ANALTAPE 13.037  All-systems report was missing.
  ANALTAPE 13.286  ERROR:KEYWORD PARAMETER in MXG 13.06-13.07 only.
  ASMIMSLG 13.265  IMS 5.1 changes, untested.
  ASMRMFV  13.027  0C4 ABEND if no enqueue table, additional records.
  ASMTAPES 13.135  MAINTLEV 4 of MXG Tape Mount and Allocation Monitor
  ASMTAPES 13.163  MAINTLEV 5 of MXG Tape Mount and Allocation Monitor
  ASMTAPES 13.187  MAINTLEV 6 of MXG Tape Mount and Allocation Monitor
  ASMTAPES 13.282  MAINTLEV 7 of MXG Tape Mount and Allocation Monitor.
  ASUMCICS 13.268  Default summarization now includes USER.
  CICINTRZ 13.281  Replacement for CICINTRV available for testing.
  DIFFDB2  13.212  Removed DB2STAT2 from DIFFDB2 create of DB2STATS.
  DIFFDB2  13.269  Variables QBSTHPL/QBSTVPL removed from DIF().
  FORMATS  13.061  All MXG formats for hex values use OTHER= syntax.
  FORMATS  13.127  MXG FORMATS member incompatible with SAS Version 5.
  GRAFLPAR 13.060  MXG 13.01 only.  NAME uninitialized error.
  IMACFILE 13.109  Select CICS records by APPLID/SUBTYPE example.
  IMACICSA 12.324  SAP Journal data times formatted correctly.
  IMACICSA 13.077  CICS SAP variable STCTIMTR may be wrong.
  IMACICSA 13.199  SAP variable STICODE changed from Numeric to Char.
  IMACPDB  13.271  SYSNAME and SYSPLEX added to PDB.JOBS/STEPS/PRINT.
  IMACSPCK 13.241  New BUILDPDB/BUILDPD3 exit for SPIN override.
  IMACZDAT 13.237  ZDATE creation now localized, for ease in reruns.
  JCLDAYDS 12.316  DCOLLECT output LRECL=644 instead of LRECL=264.
  JCLPDB6  13.018  Member ASUMDB2S does not exist error.
  MONTHBLD 13.015  SORT error building monthly TYPE72, wrong BY list.

  REXXDB2  13.284  REXX program to convert DB2 GTF records corrected.
  RMFINTRV 13.213  TSOxxxxx response variables FORMAT now 7.3.
  SASAFIX1 13.239  S370FRBn informat replacement .DLL for ASCII SAS.
  TRNDDB2S 13.031  Variables QTPUBD and QTXAIRL incorrect spellings.
  TRNDTALO 12.327  Syntax error due to missing comma.
  TYPEACF2 13.112  ACF2 subtype "L" logic (ACF2JR dataset) redesigned.
  TYPEACHE 13.005  CRR 1.6 with 3990-6 in Basic Move, values wrong.
  TYPEAUTO 13.091  Support for LEGENT's AUTOMATE SMF record.
  TYPEAUTO 13.102  Corrections to initial support for AUTOMATE.
  TYPEAXC  13.149  Support for Kodak AXCIS Optical Disk SMF records.
  TYPEBETA 13.304  Support for BETA 93 Release 1.06.50 INCOMPATIBLE.
  TYPECACH 13.103  Support for 4-digit UCB in Cache RMF Reporter data.
  TYPECACH 13.262  DEVPLX (duplex volume) address wrong, IBM worrying.
  TYPECOMP 13.222  Support for COM-PLETE Version 4.6 SMF record.
  TYPEDB2  13.212  Dataset DB2STAT2 was incomplete.
  TYPEDB2  13.244  Support for DB2 4.1.0 type 100 and 101 records.
  TYPEDCOL 13.105  INPUT STATEMENT EXCEEDED with SMS 1.2 DCOLLECT.
  TYPEDCOL 13.295  Support for DFSMS/MVS 1.3 DCOLLECT records (COMPAT).
  TYPEEDGS 13.124  IBM RMM SMF record INVALID DATA FOR MDUCDATE.
  TYPEEPMV 13.170  Support for OMEGAMON/MVS Version 300 (INCOMPAT).
  TYPEEPMV 13.201  Support for Omegamon for MVS/ESA V400 adds variables.
  TYPEEREP 13.164  Support for EREP/SYS1.LOGREC records.
  TYPEEREP 13.208  EREP gets INVALID DATA FOR DTL, additional support.
  TYPEEREP 13.270  INPUT STATEMENT EXCEEDED error corrected.
  TYPEFRYE 13.317  Support for Frye Systems LAN measures for Netware.
  TYPEHIPR 13.120  Support for Boole & Babbage HiperCache V1.4.3.
  TYPEHMF  13.038  Support for HMF subtypes 4 and 5.
  TYPEHMF  13.165  Deaccumulation of HMF records.
  TYPEHPAI 13.010  Support for HP-PCS data from AI UNIX.
  TYPEHPSU 13.010  Support for HP-PCS data from SUN UNIX.
  TYPEHPUX 13.010  Support for HP-PCS data from HPUX UNIX.
  TYPEHSM  13.131  Corrections to HSM FSR segment in SMF record.
  TYPEHSM  13.218  Support for HSM ABARS ABACKUP/ARECOVER FSR segment.
  TYPEHSM  13.259  HSM ABARS record now validated.
  TYPEHURN 13.085  Support for Antares' HURON ObjectStar SMF record.
  TYPEHURN 13.243  Zero obs in HURN49 dataset.
  TYPEICE  13.026  ICEBERG subtype 5 extents and TOIOTIME wrong.
  TYPEIDMS 13.223  Support for IDMS 12.01 Maint 9506 (INCOMPATIBLE).
  TYPEIDMS 13.267  Support for IDMS 12.01 INVALID DATA FOR PMHSDATE.
  TYPEILKA 13.130  Internet addresses were not converted to num-point.
  TYPEIMSA 13.013  IMS DEDB and MSDB counts from fastpath type 59.
  TYPELMS  12.326  Support for Memorex/Telex LMS Version 3.1 (INCOMPAT).
  TYPEMON8 12.315  NO MATCHING DO/SELECT error, 'TD' record support.
  TYPENAF  13.094  NAFLOGOF dataset variables incorrect.
  TYPENAF  13.133  Candle's Supersession Release 147 PTF QLV1372
  TYPENDM  13.070  Variable NDMDSDSN (Source DSN) added to NDMCT.
  TYPENDM  13.146  Connect Direct (formerly NDM) minor corrections.
  TYPENSPY 13.021  NETSPY Type N subtype 06/07 support incorrect.
  TYPENSPY 13.022  Support for NETSPY Release 4.6 (compatible).
  TYPENSPY 13.059  INPUT STATEMENT EXCEEDED for NETSPY type X record.
  TYPENTCP 13.144  Support for NetCompress SMF records.
  TYPEOMCI 13.173  INPUT STATEMENT EXCEEDED RECORD Subtype 200.4.
  TYPEOPC  13.092  Support for OPC Release 3.0 (INCOMPATIBLE).
  TYPEPKMN 13.145  Support for Packet/Main SMF records.
  TYPEQAPM 13.051  Support for OS/400 Version 3.1.0 wrong in MXG 12.12.
  TYPEQAPM 13.071  OS/400 Version 3.1, DSARM/DSTYPE reversed.
  TYPERACF 13.030  Support for IBM's IRRDBU00 RACF Database Unload.
  TYPERMDS 13.260  INVALID ARGUMENT TO MDY in RMDS 1.4 records.
  TYPESAMS 13.080  Support for Sterling SAMS Storage Automation SMF.
  TYPESAVR 13.252  New fields added, ZAP required to populate.
  TYPESFTA 13.229  Support for ISOGON Soft Audit Version 4.1.
  TYPESOLV 13.028  Support for Sterling SOLVE NCL CPU-time accounting.
  TYPETAND 13.221  Support for TANDEM D20 MEASURE CPU, DISK and PROCESS.

  TYPETAND 13.283  Support for TANDEM D20 D30 and D40 releases.
  TYPETCP  13.008  Support for TCP/IP APAR PN69321-PN69322.
  TYPETMDB 13.223  Support for Landmark TMON for DB2 Version 2.
  TYPETMNT 13.135  PROGRAM=IEFIIC records are again deleted by TYPETMNT.
  TYPETMON 12.320  Landmark Version 1.3 variables were not INPUT.
  TYPETMON 13.204  TYPETMON (TMON CICS 1.3) INCOMPATIBLY CHANGED BY MXG.
  TYPETMS5 13.083  Support for TMS (CA-1) Release 5.1 (compatible).
  TYPETMS5 13.123  New variables from 5.1 added to final datasets.
  TYPETMS5 13.308  BUFNO=220 on //TMC DD reduces 15 minute run to 4!
  TYPETMVS 13.170  Support for new TMON/MVS subtypes.
  TYPETSOM 13.143  TSO/MON 6.1 only, TRIVTM,NTRIVTM,LONGTM too small.
  TYPETUX  13.288  Support for Landmark TMON for UNIX.
  TYPETUX  13.302  Corrections and Enhancements for Landmark TMON/UNIX.
  TYPEVM   13.287  Support for VM/ESA SQL/DS Remote User Account Record.
  TYPEVMXA 13.126  Sterling's VM/Monitor MONWRITE records cause error.
  TYPEVMXA 13.137  Support for MICS VM Data Transmission Program output.
  TYPEVMXA 13.168  Correction to Change 13.126, applies to IBM too.
  TYPEVMXA 13.318  Alternative VXBYUSER using VXUSELOF vice VXUSEINT.
  TYPEWYLA 13.075  Support for ACS Wylbur Accounting SMF record.
  TYPE102  13.009  T102S145 QWn145OB values wrong.
  TYPE102  13.192  IFCID 21 or 44 INVALID SECOND ARGUMENT error message.
  TYPE110  12.321  CICS Statistics CICDS and CICEODRV datasets wrong.
  TYPE110  13.057  CICSLSRR variables A08BKCTD/A08BKDTD incorrect.
  TYPE110  13.261  Support for SAP 5.0 INCOMPATIBLE type 110 journal.
  TYPE110  13.291  CICSTRAN (MXG 13.07-13.08 only) ENDTIME/ELAPSTM bad.
  TYPE110  13.292  CICS/ESA 3.3 UNEXPECTED STATISTICS with STILEN=0.
  TYPE110  13.296  CICS/ESA 4.1 TRANTYPE was moved by IBM, now correct.
  TYPE116  13.049  Zero observations in dataset TYPE116.
  TYPE1415 13.002  DSNAME='UNKNOWN...' set incorrectly for multi-vol.
  TYPE1415 13.064  Multi-UCB type 1415 SMS fields wrong.
  TYPE16   13.093  Support for DFSORT Release 13 (INCOMPATIBLE).
  TYPE24   13.066  Fields added by MVS/ESA 5.2
  TYPE26J2 13.263  JESNR may show only four digits; IBM lied in ESA 5.2
  TYPE28   13.072  Support for NPM Version 2.2 APAR OW08641.
  TYPE30   13.065  Negative value for EXECTM due to IBM leapseconds.
  TYPE30   13.066  Fields added by MVS/ESA 5.2
  TYPE30   13.073  ABEND value may be wrong in TYPE30_5.
  TYPE32   13.084  Support for APARs OW10393 and OW12856.
  TYPE42   13.066  Fields added by MVS/ESA 5.2
  TYPE42   13.217  Support for APAR OW14717 and OW16039 SMF type 42.
  TYPE42   13.311  Support for DFSMS/MVS 1.3 VSAM RLS new subtypes.
  TYPE50   13.188  Variable WRBUFUSE added to dataset TYPE50.
  TYPE6    13.056  4-Digit remote support incomplete.
  TYPE6    13.309  INPUT STATEMENT EXCEEDED for PSF type 6 with BINS.
  TYPE64   13.312  Support for DFSMS/MVS 1.3 VSAM RLS new variables.
  TYPE72GO 13.236  Delay percentages calculation was incorrect.
  TYPE74   13.004  MVS/ESAs 5.1 TYPE74ST dataset had duplicate/missing.
  TYPE74   13.035  Support for APAR OW04653 added to TYPE74ST dataset.
  TYPE80A  12.323  Invalid SUBSTR function, STOPOVER error corrected.
  TYPE80A  13.254  Support for TOPSECRET 4.4/5.0 (INCOMPATIBLE) records.
  TYPE91   13.189  INVALID DATA FOR AFSTTIME in SMF type 91 fixed.
  TYPE92   13.155  Support for OpenMVS File System I/O SMF type 92.
  TYPE92   13.313  Support for MVS/ESA 5.2.2 Open Edition INCOMPATIBLE.
  VMAC102  13.273  Support for DB2 4.1 IFCIDs 221, 222, and 231.
  VMXGDUR  13.305  Rename internal variables DATE HOUR DAY DAYM etc.
  VMXGHSM  13.108  Dataset DGN corrected for multiple dump copies.
  VMXGINIT 13.033  New macro variable, &MXGDEBUG is now GLOBALed.
  VMXGSUM  13.152  VMXGSUM incompatible for user-written invocations.
  VMXGSUM  13.276  "XMXGSUM" architecture now replaces VMXGSUM.
  XMXGSUM  13.097  Final validation enhancements.
  YEAR2000 13.110  MXG Position Paper on support for the Year2000.
  YEAR2000 13.158  Phase one support for the Year2000.


Inverse chronological list of all Changes:


  Changes 13.324 thru 13.166 were printed in MXG Newsletter TWENTY-NINE
  Changes 13.165 thru 13.001 (and 12.328 thru 12.307) were printed in
   MXG Newsletter TWENTY-EIGHT (and are contained in member CHANGESS).




   This is the last page of MXG Technical Newsletter Number

          TWENTY-NINE

   and it is blank except for this statement and the page number.

****************NEWSLETTER TWENTY-EIGHT*********************************










             MXG NEWSLETTER NUMBER TWENTY-EIGHT August 21, 1995

Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE

                         TABLE OF CONTENTS                          Page

I.    MXG Software Version 13.05 is now available upon request.       2
II.   MXG Technical Notes                                             4
 1.   Support for the Year 2000.                                      4
 2.   Tape activity shows EXCPs without any tape mounts               6
 3.   How can I have 10 digits printed for a variable of length 4?    7
III.  MVS Technical Notes                                             7
 1. APAR OW06770 corrects MVS/ESA 5.1 type 72 fields                  8
 2. Boole & Babbage CMF invalid STARTIME corrected by BMP5061/5322.   8
 3. TYPE42DS does not record activity on all datasets.                8
 4. MVS/ESA 5.1 Goal Mode sites need MXG 13.01 or later               8
 5. My current understanding and research on LEAPSECONDS.             8
 6. MVS RMF APAR OW12017 corrects many RMF problems.                  9
 7. MVS/ESA 5.1 APAR OW11733 corrects trashed type 72 fields.         9
 8. High MVS Uncaptured CPU time caused by GTF trace.                 9
 9. NETVIEW FTP APAR PN71477 corrects SMF record 0 instead of 118.    9
10. APAR OW13375 corrects variable TTRN in TYPE1415.                  9
11. TYPE42AU dataset has invalid MVS volume status, OW11153 fixes.    9
12. Type 6 records invalid data by NFP FSS writer, PN72812 open.      9
13. TYPE6 observations may indicate DUPLEX when you think SIMPLEX.   10
14. EXCP counts in type 30 for VSAM hardware compressed datasets.    10
15. SMF VSAM dataset CISIZE allocation changed by VSAM.              10
IV.   DB2 Technical Notes                                            10
 1. DB2ACCT CPUTCBTM/DB2TCBTM capture for Distributed work.          10
 2. DB2ACCT CPUSRBTM/DB2SRBTM invalid, always.                       10
V.    IMS Technical Notes                                            11
 1. IMS APAR PN45106, CPU time recorded increased by LSO=S.          11
VI.   SAS Technical Notes                                            11
 1. SAS ABENDS out of space in WORK.@Tnnnnnn.UTILITY                 11
 2. MXG FORMATS OTHER= syntax is incompatible with SAS 5.18          12
 3. Character variables assigned $MGxxxxxx formats need LENGTH       12
 4. SAS data libraries cannot be hardware compressed.                12
 5. Out of Memory errors if site restrictions are in effect          12
 6. HEX15. and HEX16. formats produce unexpected (but neat!) output. 13
VII.  CICS Technical Notes                                           13
 1. APAR PN71965 discusses contents of TERMINAL in AOR records       13
 2. APAR PN70771 variable USER is not cleared between tasks          13
VIII. Incompatibilities and Installation of MXG 13.05.               14
 1.   Members and products incompatibly changed.                     14
 2.   Installation instructions.                                     15
IX.   Online Documentation of MXG Software.                          15
X.    Changes Log                                                    17
      Alphabetical list of important changes                         17
      Changes 13.162 thru 13.001, 12.328 thru 12.315              19-56
       (Changes 12.304-12.129 were in Newsletter 27)

         COPYRIGHT (C) 1995 BY MERRILL CONSULTANTS DALLAS TEXAS

I. MXG Software Version 13.05 is now available upon request (it is NOT
   shipped with this newsletter - you must ask for it and it is free!).

   Major enhancements added in MXG 13.05 dated August 21, 1995:

    Support for the year 2000 (see MXG Technical note).
    Support for OpenMVS File System I/O type 92 SMF record.
    Support for MVS/ESA 5.2 System Logger Data type 88 SMF record
    Support for EREP (SYS1.LOGREC) records.
    Deaccumulation of HMF records.
    MAINTLEV 6 of ASMTAPES enhancements for MXG Tape Mount Monitor.
    Final (?) Correction to ANALDB2R Statistics and Audit Reports.
     If you use either the DB2 Statistics reports or DB2 Audit Reports,
     you must request MXG 13.05 for the ANALDB2R corrections to errors
     introduced in MXG 12.12 (Statistics) or MXG 13.01 (Audit) that were
     not fixed until now (I apologize for the careless coding and lack
     of validation of report output that took seven iterations to fix).
     The Audit errors were actually corrected in 13.03, but Statistics
     still had four values that were not corrected until MXG 13.05.
     The more-commonly-used DB2 Accounting Reports had no errors.

   Major enhancements added in MXG 13.04 dated Jul 31, 1995:

    Support for NetCompress SMF records.
    Support for Packet/Main SMF records.
    Support for Kodak AXCIS Optical Disk SMF records.

   Major enhancements added in MXG 13.03 dated Jul 19, 1995:

    More fixes for DB2 Statistics Reports, a fix for DB2 Audit Reports.
    TYPE116 (MQM) validation and correction.

   Major enhancements added in MXG 13.02B dated Jul  6, 1995:

    Correction to DB2 Statistics Summary and Audit Reports
    MXG Position Paper on Support for Year2000 in member YEAR2000.

   Major enhancements added in MXG 13.02A dated Jun 28, 1995:

    Correction to DB2 PMSSTA01/02 Statistics Summary Reports.
    Final (?) revisions to XMXGSUM.

   Major enhancements added in MXG 13.02 dated Jun 19, 1995:

    Support for MVS/ESA 5.2 (compatible) changes 24, 30, and 42 records.
    Support for OPC Release 3.0 (INCOMPATIBLE).
    Support for DFSORT Release 13.0 (INCOMPATIBLE).
    Support for TMS (CA-1) Release 5.1 (compatible).
    Support for Antares' HURON ObjectStar SMF record.
    Support for TYPE32 APARS OW10393 (causes error) and OW12856 (none).
    Support for SAP Release 5.0 CICS accounting in type 110.
    Support for ACS Wylbur Accounting SMF record
    Support for Sterling SAMS Storage Automation SMF record.
    Support for LEGENT's AUTOMATE SMF record.
    DB2 Audit SQL text corrections.
    Support for APAR OW08641 for NPM Version 2.2

   Major enhancements added in MXG 13.01 dated May  3, 1995:

    Support for NETSPY Release 4.6 (compatible), divide by zero fixes.
    Support for HP PCS current version on HPUX, AIX, and SUN unix.
    Support for OS/400 Version 3.1.0 (was wrong in MXG 12.12/12.12A).
    Support for TCP/IP APAR PN69321-PN69322.

    Support for Sterling SOLVE NCL CPU-time accounting user SMF.
    Support for HMF SMF record subtypes 4 and 5.
    Support for APAR OW04653 added variables to TYPE74ST dataset.
    Support for IBM's IRRDBU00 RACF Database Unload.
    ASMRMFV 0C4 correction and enhancements for RMF VSAM processing.
    ANALCNCR enhancements and validation.
    XMXGSUM  enhancements and validation.
    TYPE116 (MQM) validation and correction.

   Major enhancements added in MXG 12.12A dated Mar 20, 1995:

    Twelve MXG 12.12 members had errors that are now fixed:

      ANALCNCR ANALDB2C ANALDB2R ANALPATH ANALTALO IMACICSA
      TRNDTALO VMAC80A  VMAC110  VMACILKA TYPEMON8 TYPETMON

    Support for Memorex/Telex LMS Version 3.1 (INCOMPATIBLE).

  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.02
      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.       12.04
      CICS/ESA 4.2                     when G.A.           13.??
      CRR 1.6                          Jun 24, 1994.       12.02
      DB2 2.2.0                                1990         8.8
      DB2 2.3.0                        Oct 28, 1991.       10.01
      DB2 3.1.0                        Dec 17, 1993.       13.02A
      DB2 4.1.0                        when G.A.           13.??
      DFSMS/MVS 1.1                    Mar 13, 1993.       11.11
      DFSMS/MVS 1.2                    Jun 24, 1994.       12.02
      NPM 2.0                          Dec 17, 1993.       12.03
      NPM 2.2                          Aug 29, 1994.       12.05
      VM/ESA  1.1.1                    Dec 27, 1991.       10.01
      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              Required

      Landmark
       The Monitor for DB2 - See Note 1.                   12.12
       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
      Candle
       Omegamon for CICS V300 User SMF                     12.05
       Omegamon for IMS V110 (ITRF)                        12.12

       Omegamon for MVS - last MXG change 1992             12.12
       Omegamon for DB2 Version 2.1/2.2                    13.05
       Omegamon for VTAM V160                              12.04A
       Omegamon for SMS V100/V110                          12.03
      Boole & Babbage
       IMF 3.1 (for IMS 5.1)                               12.12
      Memorex/Telex
       LMS 3.1                                             12.12A


======================================================================


II.   MXG Technical Notes.
 1. Support for the Year 2000.

   a. Date and date-time variables in MXG-built SAS datasets have always
   internally supported the year 2000:

   Date variables are stored as 4-byte floating-point number-of-days
   since 01Jan1960, and will not overflow for 45,925 years. All date
   variables now have a default format of DATE9, causing them to display
   as 08Aug1995, showing the full four-digit year.

   Datetime variables are stored as 8-byte floating point number-of-
   seconds since 1Jan1960, and will not overflow for 2283 million years.
   Datetime variables now have a default format of DATETIME21.2, so they
   display as 05Jul1995:12:52:59.99, showing the full four-digit year.

   b. However, MXG dates/datetimes will be valid in 2000 only if the
   field in the data records read by MXG actually contain valid Year2000
   dates.  I have examined all date-containing fields read-in by MXG
   Software, and these thirty-six products do not currently have enough
   field width to support the year 2000:

     IBM Products Which do not provide valid Year2000+ dates:

      MVS   CICS             SMF type 110
      MVS   DFP              SMF type  36
      MVS   DFP              VTOC
      MVS   NETVIEW NPM      SMF type 28
      MVS   RMF              SMF type 73, 74, 78
      MVS   SMF              SMF type 14, 15
      MVS   HSM              SMF user records
      MVS   OPC              Log records
      MVS   RMDS             Log records
      MVS   NCCF             Log records
      MVS   SYSLOG           Log records
      OS400 Accounting       All Accounting/Performance Records
      OS400 Trace            Trace Data
      VM    VM ACCOUNT       Accounting Records
      VM    VM/370 Monitor  *Performance Record

      Other Vendor Products which do not provide valid YEAR2000+ dates:

    Boole & Babbage      CICS/Manager
    Boole & Babbage      CONTROL-D
    CA                   SAR
    CA                   NETSPY
    CA                   XCOM
    CA                   VM/EXPLORE
    Fujitsu              PDL Reports
    FUJITSU              Type 127 SMF record

    FUJITSU              Type 234 SMF record
    GOAL SYSTEMS         PDSMAN/XP
    LANDMARK             TMON/CICS
    LANDMARK             TMON FOR DB2
    LANDMARK             TMON FOR MVS
    Mobius               Infopac
    NOMAD                NOMAD
    ODS                  ODS/ODI Optical Disk SMF record
    SAP                  SAP IMS log record type AEx
    STERLING             DMS
    VELOCITY SOFTWARE    ESAMON
    VOLVO (EUROPE)       SESAME
    XEROX                Shared File System Print Accounting

   c. In addition, 59 products use a four-byte packed-decimal julian
   date field, which can support the year 2000, but only WILL support
   it when the vendor has populated the first byte.  The vendor can use
   either a century bit ('0cyyydddF'x, which IBM uses in SMF records),
   or a four-digit year ('yyyydddF'x) can be populated.  Each of those

   PD4 vendor fields must be validated by the vendor that they do
   support the year 2000, and documented as to their format.  Vendors
   using the TIME macro need only verify that fact, as the TIME macro
   returns the century bit, whereas vendors using the STCK macro will
   have to change their code to populate the first byte, which means
   their products won't support the year 2000 until that vendor change
   has been installed on your system.  These products require either
   validation or change for their PD4 date fields:

      Vendor=IBM:
      MVS   APPC           SMF type 33
      MVS   Batch Pipes    SMF type 91
      MVS   BDT            SMF type 59
      MVS   CICS           SMF type 110
      MVS   DFP CATALOG    SMF type 36
      MVS   DFSORT         SMF type 16
      MVS   JES2 NJE       SMF type 57
      MVS   JES2           SMF type 6
      MVS   JES2           SMF type 24
      MVS   JES2           SMF type 26
      MVS   JES3           SMF type 25
      MVS   JES3           SMF type 26
      MVS   JES3           SMF TYPE 84
      MVS   MULC           SMF type 89
      MVS   NETVIEW NPM    SMF type 28
      MVS   NETVIEW NPM    SMF type 37
      MVS   RMF            SMF type 70-79
      MVS   SMF            SMf type 4,5,7,14,15,30,32,34,35,90
      MVS   HSM            SMF USER RECORD
      MVS   DCOLLECT       IDCAMS output
      MVS   RMM EDGS       Extract output
      MVS   FTP            SMF record
      MVS   HSM            SMF RECORDS
      MVS   IMS LOG        Log records
      MVS   OPC            Log records
      MVS   HSM MCD/BCD/   Log records
      MVS   DFP            VTOC
      MVS   NETVIEW        NCCF
      VM    VM ACCOUNT     Accounting

     Vendor                Product

      AION                 AION

      ALTAI                ZARA
      BGS                  BGS I/O MONITOR
      BOOLE                IMF
      CA                   IDMS SMF RECORD
      CA                   ROSCOE
      CA                   SAR
      CA                   NETSPY
      CA                   TMS
      CA                   XCOM
      CA (GOAL SYSTEMS)    PDSMAN/XP
      CANDLE               OMEGAMON AUDIT SMF RECORD
      CANDLE               OMEGAMON FOR VTAM
      CANDLE               ITRF
      CINCOM               SUPRA           LOG RECORD
      COMPUWARE            FILEAID
      LANDMARK             TMON/CICS
      LANDMARK             TMON FOR DB2
      LANDMARK             TMON FOR MVS

      NETWORK SYSTEMS      HMF (HyperChannel or DXE)
      NOMAD                NOMAD
      RSD                  WSF
      SAP                  CICS JOURNAL
      SIMWARE              SIM/XFER
      SOFTWARE AG'S        NET-PASS
      STERLING             DMS           SMF USER RECORD
      STK                  ICEBERG
      SYSTEM CENTER        NDM (NETWORK DATA MOVER)
      SYNCSORT             SYNCSORT
      VOLVO (EUROPE)       SESAME

   d. The SMFSTAMP, and RMFSTAMP input formats do support the century
   bit, but not the four-digit year julian format.  The DATEJUL function
   supports the four-digit year, but not the century bit, and the MDY
   MDY function does not accept YY=100 (i.e., cyy) as a valid year.
   SAS Institute is investigating how to provide both support and
   consistency for its date functions and informats, and I expect that
   a combination of changes, new functions and new input formats may be
   required for all possible date formats to be supported by SAS. But
   because those changes will not be available until SAS version Seven,
   MXG has been modified to protect all of its uses of DATEJUL and MDY
   functions.  The extensive details can be found in Change 13.159.

   e. MXG member YEAR2000 contains the detail list of fields that must
   be changed or validated by their vendors.  That member will be
   updated as vendors make changes and notify Merrill Consultants of
   their changes to support the year 2000.  Feel free to hassle your
   friendly vendor when you see their product on that list.

 2. Analysis of Tape Activity from PDB.JOBS and PDB.STEPS can show tape
    EXCPs without any tape mounts.  How can this be?  Let's first look
    at the tape-related variables in the PDB.STEPS dataset:

      TAPNMNTS   - Scratch and Private Tape Mount count, but this only
      TAPSMNTS     includes the mounts issued by MVS.  In JES3, any
                   mounts managed by MDS will not be counted in the type
                   30 records (although they are counted in the
                   JES3-only TYPE25 dataset); JES3 second-volume mounts
                   and first-mount for non-MDS mounts (including dynamic
                   allocations) will be counted in the type 30 records.

      EXCPTAPE   - Count of EXCP (from TIOT in type 30) to TAPE devices
                   that were allocated to this step.

      TAPEDRVS   - Count of unique tape devices addresses that were
                   allocated by this step, both statically (i.e., in the
                   JCL) and dynamically.
                      However, there is no guarantee that this many tape
                      drives were concurrently allocated; if a task like
                      HSM dynamically allocated a tape 10 times in a run
                      and happened to get 10 different drives, TAPEDRVS
                      would be 10, but if HSM just happened to get the
                      same drive each time, then TAPEDRVS would be only
                      one. Also, we do not know how long the tapes
                      were allocated; for static allocation it is the
                      step EXECTM, but for dynamic allocation or
                      deallocation (eg., FREE=CLOSE) we do not know when
                      the tape device use began nor ended.

    So now how can we have EXCPTAPE with no TAPNMNTS+TAPSMNTS?

      In the STEPS data set, we could have:
        - JES3 MDS mounts are not counted, but EXCP to all tapes are, or
        - First step mounts, second step uses, second step record will
          count EXCPTAPE but no tape mounts, or
        - In all cases, if we have EXCPTAPE non-zero we must also have
          TAPEDRVS non zero.

      In the JOBS data set, since we sum step records to create the
      job resources, we could have:
        - JES3 MDS mounted all tapes for the job, or
        - SPINCNT (defined in IMACSPIN) too small, and a job that was
          still running when SMF was dumped.  If SPINCNT=0, today's
          steps will be summarized into todays PDB.JOBS, while tomorrows
          steps will be in tomorrow's PDB.JOBS, and if all of the mounts
          occurred in today's steps, tomorrows PDB.JOBS would have EXCP
          counts without tape mounts.
        - Extremely unlikely, but if IMACPDB were incorrectly modified
          by the site, many variables in JOBS could be wrong, because
        - We still must have TAPEDRVS non zero for EXCPTAPE non-zero.

 3. How can I have 10 digits printed for a variable of length 4 bytes?
    Maximum integer values that can be stored by SAS.

   A four-byte binary field, INPUT as PIB4., can contain a maximum
   integer value of of 4,294,967,296.  All SAS numeric variables are
   stored as floating point numbers, with one byte for exponent and the
   remainder of the stored length as the mantissa.

   For MVS, these integer values can be represented exactly with these
   stored lengths:
          Length          Largest Integer       Significant Digits
            2                         256              2
            3                      65,536              4
            4                  16,777,216              7
            5               4,294,967,296              9
            6           1,099,511,627,776             12
            7         281,474,946,710,656             14
            8      72,057,594,037,927,936             16

   For PC/Unix, these integer values can be represented exactly with
   these stored lengths:
          Length          Largest Integer       Significant Digits
            2                 Not ALLOWED
            3                       8,192              3
            4                   2,097,152              6
            5                 536,870,912              8
            6             127,438,953,472             11
            7          35,184,372,088,832             13
            8       9,007,199,254,740,992             15

   SAS stores numerics in 8 bytes, but MXG uses LENGTH DEFAULT=4 for
   almost all numerics, saving considerable DASD space, but raising
   the question of accuracy.  Consider this example program:
      DATA; LENGTH X 8 Y 4;
      X=4294967295;Y=X;OUTPUT; PUT X= Y=;
      X=X+1;Y=Y+1;OUTPUT;PUT X= Y=;
      X=X+1;Y=Y+2;OUTPUT;PUT X= Y=;
      PROC PRINT;

   The PUT statements all have Y equal to X exactly, because numeric
   variables are always length 8 when created in a data step; it is not
   until the observation is OUTPUT to a data set that its stored length
   comes in to play, as the output of the PROC PRINT shows:
                      X               Y
                4,294,967,295   4,294,967,040
                4,294,967,296   4,294,967,296
                4,294,967,297   4,294,967,296
   Here we can see that the 4-byte variable Y prints 10 digits, and that
   while its value can be exact for certain powers of 2, the value can
   be smaller by as much as 255 (out of 4 billion) due to truncation.
   For most MXG variables, that is truly insignificant.  However, there
   are classes of MXG variables which are always longer than 4-bytes:
     All Datetimestamp variables - length 8
     Large value accounting (DASD bytes, Service Units)- length 8
     Four byte numerics containing hex values (UCBTYPE) - length 5
     Any variable with value greater than 16777216 that must be exact.

III.  MVS Technical Notes after Newsletter TWENTY-SEVEN.

 1. APAR OW06770 and OW09814 (PTFs UW10049 and UW14370) correct type 72
    wrong values in MVS/ESA 5.1 fields SMF72ACT SMF72SER SMF72MTS
    SMF72ITS SMF72CTS SMF72TAT and SMF72STS.  Bad values occurred in any
    interval in which a CICS region was FORCED or a batch job terminated
    at end of memory.  The bad values were all '7FFFFFFF'x, which in MXG
    (being read as PIB4.) is 2,147,483,647!

 2. Boole & Babbage CMF 5.1 creates RMF records with incorrect STARTIME
    (type 72 STARTIME is 1 second earlier or later than 70 and 71) when
    SYNC is specified, which causes MXG's RMFINTRV dataset to calculate
    incorrect uncaptured CPU times.  Boole's fix is BPM5061 & BPM5322.
    MXG produced "ERROR.RMFINTRV.INCONSISTENT RMF DATA" messages.

 3. TYPE42DS (dataset level I/O monitoring) does not capture activity on
    all datasets.  For Concatenated BPAM, there is only one type 42 SMF
    record written, and it contains only the name of the first dataset
    in the concatenation; there is not even any indication that there
    were other datasets behind this DDNAME.  (Note that type TYPE1415
    has always had part of this problem - there too you only get the
    name of the first dataset in the concatenation, but at least in the
    14/15 records, there is a UCB segment for each dataset with the
    UCB address and EXCP count to each member of the concatenation.)
    Finally, note that "Concatenated BPAM" means that you have PDS data
    sets concatenated without member names in the JCL.  (If there are
    member names in your JCL, then BSAM is used instead of BPAM, and
    you will get a separate 14/15 record for each dataset.)

 4. MVS/ESA 5.1 in Goal Mode sites need MXG 13.01 or later when you
    begin to stress your Coupling Facility, especially with Data Sharing
    applications.  IBM moved structure data (TYPE74ST) incompatibly, and
    added new stats on storage allocation (how much for LISTs, how much
    for CACHE) that seem to be very important in sizing your allocation,
    and MXG had errors (no test data for validation until MXG 13.01).
    The TYPE74CF and TYPE74ST datasets are the focal point of analysis
    if you suspect delays due to the Coupling Facility.

 5. My current understanding and research on LEAPSECONDS:

    LEAPSECONDS only exist in the sysplex timer environment, and the
    current value of leap seconds was 18 seconds in 1995 (and is now
    20 seconds in June, 1997).

    There are two common timestamps output into SMF records:

     TODSTAMP is the 8 byte time-of-day IBM "STCK" clock format.
     SMFSTAMP is the 4-byte time, 4-byte date in packed decimal format.

    There are three clocks which can be used:
     Absolute Clock - time value includes leap seconds and is on GMT
     GMT Clock      - GMT value without leap seconds
     Local Clock    - SMF Time and Console Time stamps.

    There are two macros which supply time to an assembly routine:

     TIME returns a local time value that DOES NOT include leap seconds
          and can return the time in many formats, including SMFSTAMP,
          TODSTAMP, Timer Units, Microsec, or Binary).
     STCK returns the "Absolute" TIME, a GMT value that DOES include
          leap seconds, and only returns the time in TODSTAMP format,
          although macros CONVTOD and STCKCONV can be used to take the
          output of STCK and convert it to other formats.

    But the assembly program could use either macro to get the tod and
    use either format for its output, so you can't tell by the informat
    whether the timestamp includes or excludes leapseconds.

    JES2 APAR OY67004 corrects type 6, 24, and 26 timestamps to include
    leapseconds in its conversion of STCK time from Absolute to local.

    See text of APAR OW12750 for a very detailed explanation of the
    SMF "Midnight Value" calculation.

    MVS/ESA 4.3 Type 42 interval records for CLOSE show SMF42PTE 18
    seconds later than SMFTIME, indicating incorrect direction of
    conversion.  This was thought to be an error, but now (JUN97) it
    is recognized that the "GMT" value in SMF42PTE is actually from
    the "Absolute" clock, which included 18 leap seconds!

    The SAS functions TIME(), DATE(), DATETIME() and &SYSTIME use the
    STCK command and do not include leapseconds when converted to the
    local time you get back from SAS.  SAS Institute has been requested
    to enhance these functions to include leapseconds.

 6. MVS RMF APAR OW12017 corrects many RMF problems, some affecting RMF
    records, while some fixes apply only to the RMF report program.

 7. MVS/ESA 5.1, RMF72 performance group data occasionally trashed (very
    unreasonable values in several variables) is reportedly fixed by IBM
    APAR OW11733 with PTF UW18509 for 5.1.  There apparently is a 4.3
    PTF as well.

 8. High MVS Uncaptured CPU time (CAPTURAT in RMFINTRV dropped from 92%
    to 77%) was the result of running GTF to trace a job, but the job
    name being traced was not in the system during trace.  The requested
    trace was
        TRACE=DSP,USRP,SYS,JOBNAMEP
        TRACE=JOBNAME(XYZ12345)
    It may be that GTF always causes uncaptured CPU time, but certainly
    in this specific case it was quite noticeable!

 9. NETVIEW FTP MVS 221 Server writes SMF record with record ID=0, even
    if FTP SMFREC initialization parameter was not set by installation.
    APAR PN71477 corrects the error.

10. TYPE1415 variable TTRN contains incorrect last track of data set
    after a partial release.  APAR OW13375 corrects this error.

11. TYPE42AU data set contains invalid new MVS volume status during vary
    online/offline of SMS managed volume.  APAR OW11153 corrects.

12. TYPE6 records created by NPF FSS writer may have invalid data in
    variables SMF6DSNM and SMF6PRMD.  APAR PN72812 is still OPEN.

13. TYPE6 observations may indicate DUPLEX when you really think the
    print file was SIMPLEX.  The Banner Page Header and Trailer are
    associated with the first and last datasets printed, and if either
    the Header or Trailer itself are marked as DUPLEX, then the entire
    print dataset is marked DUPLEX, even though it was only the Header
    or Trailer page that was duplexed.

14. EXCP counts in type 30 segments for VSAM hardware-compressed data
    sets initially contained a count of blocks transferred, but since
    non-hardware-compressed VSAM counts I/O operations (SSCHs), IBM has
    changed (APAR OW11649) VSAM counts for hardware compression to now
    count SSCHs to be consistent with other VSAM counts.  For Extended
    Format datasets, the count was the number of blocks per I/O, but now
    Extended Format will show the count of SSCHs, like other VSAMs.

15. A site with SMF data sets on mixed devices (3390, 3380, 9345) chose
    an SMF VSAM data set CISIZE=16K for all three device types, but SMF
    failed because the actual blocksize allocated was not the same for

    all SMF data sets.  It turns out that VSAM allocates the physical
    block size of a dataset based on a table in SC26-4910-00, and not on
    what you ask for. For a CISIZE request of 16K, the 3380 and 9345 got
    an 8192 PHYREC-SIZE, while the 3390 got a 16384 PHYREC-SIZE, but SMF
    requires that the control interval size must match the physical
    record size (the text of IEE984 message).

IV.   DB2 Technical Notes.

 1. DB2ACCT CPUTCBTM capture for Distributed work (DRDA from DDCS).

    Most of the DB2 CPU TCB time is captured in the DB2ACCT records, and
    hence also in the address space (type 30) records for the caller, as
    well as in the performance group/service class (type 72) of caller.
    One day's data showed 346 minutes DB2TCBTM in DB2ACCT with only 7.5
    minutes CPUTCBTM in the RMF 72, or 97.8% of TCB was captured in DB2.
    See note 2 for a discussion of why DB2ACCT SRB time cannot be used.

    For Distributed work (a DRDA Transaction from DDCS running
    in an AIX workstation, for example), its CPU time will be found in
    the DB2ACCT dataset with a plan name of DISTSERV, and also in the
    type 30 records and type 72 records for the DISTSERV address space,
    but there is no other address space involved.  Thus to account for
    the use of Distributed DB2, you must use the DB2ACCT record to
    redistribute the CPU cost.  But it looks like the only field that
    might tie back to which workstation generated the DB2 activity is
    the AUTHID, but that appears constant for all transactions!

    Very high CPU time per transaction (for transactions that have few
    GETPAGES) has been seen (5 CPU hours for 186 transaction!  This may
    simply be the cost of Distributed Architecture (translating each of
    the SQL calls and Results to be sent back for different platforms
    must involve more code than DB2 talking to CICS, since DRDA has to
    manage itself too), or it may be just that the startup and shutdown
    costs of DRDA are significantly higher than for normal threads, or
    it may be that this site has a misset parameter - I am still looking
    into this data and will update this note when I learn more.

 2. DB2ACCT CPUSRBTM/DB2SRBTM is invalid.

    I have previously documented (member ADOCDB2, variable description)
    that the SRB CPU time in DB2 Accounting records was invalid, but I
    did not know how wrong it was, or why it looked ok some times, until
    I read IBM's library item Q576462, repeated here:

  Q: User is doing some DDF testing and has run some accounting reports.
     SRB times (both class 1 and 2) are about 8 times the TCB times.

  A: The SRB times in the accounting records, in general, account for
     SRBs that run in the user address space.  These SRBs are caused
     by the user's processing, unrelated to anything that DB2 does,
     but since the SRBs are asynchronous, they sometimes run while the
     user is processing in DB2.  With two notable exceptions, these SRB
     times while unrelated to DB2 will almost always be insignficant.

     One exception is CICS, where there are multiple subtasks accessing
     DB2 from a single CICS address space.  CICS (not DB2) will often
     do a significant amount of processing via SRBs.  If there are
     several DB2 tasks running concurrently when CICS issues an SRB
     (unrelated to these tasks!) then the time for that SRB will show
     up not once, but once in each of the accounting records for each

     of the tasks.  Thus if you add up the SRB times from the DB2
     accounting records for CICS attachment, it will often greatly
     exceed the actual amount of SRB time used by CICS.

     The other exception is when using DDF.  The requestor times are
     not affected, but the times at the server (or DBAT, using DB2PM
     terminology) will show very very large SRB times.

     When you look at the DB2 ACCOUNTING records, use only the TCB
     CPU time, and never look at the SRB time.  When you look at the
     DB2 STATISTICS records, you should use the TCB and SRB times for
     all three/four address spaces, but remember that much of the SRB
     time reported for the DDF address space may also be reported in
     DB2 accounting records (as TCB time).


V.    IMS Technical Notes.

 1. IMS APAR PN45106 documents that CPU time recorded in the IMS log 07
    record (MXG variable IMSCPUTM, IBM field DLRTIME) increases when
    LSO=S is specified instead of LSO=Y.  With LSO=Y specified, MXG
    variable IMSCPUTM contains only the CPU time in the dependent
    region, and does not include CPU time spend in DL/I processing.
    However, if LSO=S is specified, IMSCPUTM now includes the CPU time
    in DL/I processing, and IBM reported a 30% decrease when LSO=Y
    replaced LSO=S.  The moral is: changing the LSO parameter can
    dramatically change how much CPU time is recorded in IMSTRAN dataset
    (and you cannot tell from the IMS log whether LSO=S or LSO=Y was in
    effect).

VI.   SAS Technical Notes.

 1. SAS ABENDS which point to out of space in WORK.@Tnnnnnn.UTILITY
    are the result of running out of sortwork space when the SAS
    Internal SORT has been invoked.  With the default SORTPGM=BEST
    option, the SAS Internal SORT is used for small datasets, while
    the host sort is used for large datasets, but due to an error in
    SAS, if the dataset size is greater than about 2GB, the size becomes
    a negative number to SAS, and SAS tries to sort your 2GB dataset in
    your WORK file!  SAS Usage note V6-SORT-8334 discusses their error,
    but no fix is currently scheduled.  You can circumvent the error by
    specifying OPTIONS SORTPGM=HOST for large SORTs, forcing SAS to use
    your host sort package instead of its internal sort.
       The SAS usage note also says to specify DYNALOC instead of
       NODYNALOC.  NODYNALOC causes SAS to allocate the sort work space,
       while DYNALOC causes the host sort package to do the allocation,

       but with that negative number and the NODYNALOC default, SAS will
       allocate a very small work space, causing yet another failure!
       However, the DYNALOC/NODYNALOC option has no effect if there are
       //SORTWKnn DDs in the step; the initial allocation is set by the
       JCL, and the host sort packages all extend as needed (based on
       the real size, not the negative number).  Since MXG has always
       recommended real SORTWKnn DDs (and they are in the MXGSAS JCL
       procedure), you do not need to change the DYNALOC/NODYNALOC
       option, as long as there are real //SORTWKnn DDs in the step.

 2. MXG-created FORMATS which decode hexadecimal values now use syntax
    OTHER=(  $HEX2.  ) in the PROC FORMAT so that values that are not in
    the format table will be printed in hex; without the OTHER statement
    the character variable is printed as a character, which for most hex
    values will be an unprintable field.   For numeric formats the

    syntax is OTHER=(  HEX2.  ) to cause hex instead of decimal values
    for fall-thru values.  This is not new, just newly re-discovered!
    But this now makes MXG 13.01 and later incompatible with SAS Version
    5.18 and SAS Version 6.06 because that OTHER= syntax did not exist
    in those archaic SAS versions!  However, you can delete all of the
    occurrences of that OTHER= syntax from member FORMATS, and then the
    member will execute without error.  See Change 13.127.

 3. Character variables that are assigned $MGxxxxx formats must also
    appear in a LENGTH statement to set their stored length; otherwise
    the width of the $MGxxxxx format will be used by SAS to set the
    stored length.  Not only must there be a LENGTH statement, that
    statement must preceed the FORMAT statement in the input stream.
    Accidentally, almost all MXG members just happened to have that
    sequence, but now I know the mandatory sequence of statements in
    creating MXG data sets is
       LABEL   LENGTH   FORMAT    INFORMAT     INPUT

 4. SAS data libraries cannot be hardware compressed; only BSAM and QSAM
    access methods are supported, and SAS uses EXCP access method.  If
    you put SAS data libraries in a Data Class specifying hardware
    data compression, you will get a  213-B8 ABEND that says that EXCP
    access method cannot be used with extended sequential format data
    sets (and hardware compression data uses extended sequential).
    See the MVS Technical notes for other compressed data impacts.

 5. Out of Memory errors can occur if your site has restrictions on
    virtual storage (usually in IEFUSI, IEASYS, or IEFUJV exit).  One
    clear indication of virtual storage constraints are memory values
    in IEF374I message in your JCL log.  For a larger-than-default MXG
    BUILDPDB successful execution, the IEF374I messages showed:
     IEF374I ...   VIRT 4488K   SYS 976K   EXT 32768K   SYS 9352K
    and the sum of the VIRT+EXT values, 4488K+32768K=37256K  shows
    that 36MB of virtual addressability was available for this step.
    On the other hand, the site with out of memory error had only:
     IEF374I ...   VIRT 1684K   SYS 300K   EXT  7048K   SYS 9180K
    and the sum of 1684+7048K=8732K shows the site's virtual storage
    restriction prevented SAS from getting more than 8MB.
   -z/OS 1.12 message IEF032I/33I replaced IEF374I/276I.

    If you get an out of memory error, make sure you have REGION=64M for
    an unmodified BUILDPDB, and larger if you have additional SMF record
    processing added to your PDB:
     SAS V6: Requires the MEMSIZE=64M parameter in your CONFIGV6 member,
             AND your REGION=64M (or REGION=0M, if it permits 64M).
     SAS V8: Requires that there NOT be a MEMSIZE= parameter in CONFIGV8
             BUT instead your REGION=64M on your JOB card controls V8.
          Note that you can not specify REGION= values between the size
          of your Private Area (typically 6-9MB) and 16MB, but
          REGION=32MB or larger can be specified without JCL errors.
    You can always overspecify and look at the SAS Total Memory message
    in the SAS log to see how much virtual storage was required, and by
    which DATA/PROC step, although it is always the "Big DATA" step in
    BUILDPDB that sets the maximum virtual storage required.
    If IEF374I shows the sum of the VIRT+EXT is only 16MB, 32MB or less,
    then either the above installation exits are limiting REGION size,
    or you have installed SAS with its optional restriction member:
      SAS V6:  BAMISC(SASOPTRS) used by job SASCNTL(BAOPT2) creates
               load module named SASOPT73
      SAS V8:  BAMISC(SASOPTRS) used by job SASCNTL(BAOPTS1) creates
               load module named SASOP800
    From TSO "READY", if you type in  SASOPT73 (V6) or SASOP800 (V8) and
    hit Enter Key, you will get "COMMAND NOT FOUND" if there are no SAS
    restrictions in effect, (i.e., that load module was not found in the
    linklist), but if the module SASOPxxx exists, the ABEND (because it
    is not an executable program) proves you have optional restrictions.
    If you find no SAS restrictions but System restrictions, you might
    try REGION=0M; at least one site restricted REGION=56M, but I got
    what I needed with REGION=0M, with MEMSIZE then controlling size.
    This note was revised Apr 27, 2000, and revised again Oct 25, 2001,
    to correct that SAS V8 requires you NOT have a MEMSIZE parameter.
   -z/OS 1.12 message IEF032I/33I replaced IEF374I/276I.

 6. Although documented by SAS Institute, I was unaware that the HEX16.
    and HEX15. format items (for NUMERIC variables only) produce quite
    unexpected (but explainable) output.  A value of '1111111111111111'x
    prints as '5011111111111111'x, and '00000025AFC60562'x prints as
    '4A25AFC605620000'x.  The HEX15. and HEX16. format items don't print
    the hexadecimal representation of the binary number, but instead,
    the hexadecimal representation of the internal floating point (real
    binary) value.  At first glance this might seem serious, but it
    turns out to have little impact on MXG and is actually a quite
    novel use of an otherwise-useless format item.
    -  MXG always creates CHARACTER variables with $HEX format to store
       hexadecimal representations (because there is no possible loss of
       bits, and a 1 byte character variable stores in 1 byte, not 2).
    -  Some NUMERIC variables with HEX format do exist in MXG, but none
       contained 32 bits of data.  Some were stored in length eight, but
       they contain 24-bit addresses which needed only HEX12., and there
       is no error using HEX14-or-less for 7-byte-or-less numerics.
    -  Since only the left 7 bytes of an 8 byte NUMERIC can be exactly
       represented in MVS SAS (at least one byte is always used for the
       floating point exponent), the best SAS could ever print was
       '11111111111100'x!  Hence recognizing that the HEX15 and HEX16
       formats could never be legitimately used for real data, SAS
       developers way back in SAS 82.4 decided and documented that those
       format items would print the float value instead of binary value!
       Why?  Because it gave SAS Technical Support the ability to see
       the actual internal floating point value when a customer had a
       numeric precision issue (while rare in our data, this is often a
       problem for neophyte statisticians calling SAS Support!).
       That first byte is the exponent, the remaining 7 the mantissa!
    Why did this come up? In debugging a problem, I used HEX16 without
    this knowledge, and became quite convinced there was a SAS error.
    Of course, I HAD failed to R.T.F.M. (Read The Fine Manual), and
    now we both know better!


VII.  CICS Technical Notes.

 1. APAR PN71965 points out that in CICS 4.1, the variable TERMINAL
    in the AOR record in an MRO environment will contain the MRO
    Session ID instead of the surrogate TERMID as was seen in previous
    releases.  IBM says this is "working as designed" in 4.1, but IBM
    acknowledges customers desire the surrogate TERMID, and there may
    be a later enhancement to meet that need.

 2. APAR PN70771 (still OPEN) indicates that CICSTRAN variable USER
    is not cleared between transactions in the type 110 record, and
    thus a short userid will contain remnant data of a previous long
    userid.



VIII. Incompatibilities and Installation of MXG 13.05.

 1. Incompatibilities introduced in MXG 13.05 (since MXG 12.12):

  a- IMACs that were changed (if they exist in your USERID.SOURCLIB, you
     must refit your tailoring, starting with the new IMAC member):

     None.

  b- Other incompatibility changes:

     Member FORMATS cannot be executed as-is under SAS Version 5.18,
     but can be tailored if you are still running that archaic version.
     See Change 13.127

     User-written invocations of VMXGSUM with OUTCODE= to recalculate
     the DATETIME= variable may be wrong.  See Change 13.152.

  c- These products were incompatibly changed by their vendor, and they
     require MXG 13.xx as indicated:

     Memorex/Telex LMS 3.1  (Change 12.326)
     OPC Release 3.0        (Change 13.092)
     DFSORT Release 13      (Change 13.092)
     Hipercache 4.1.x       (Change 13.120)


 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:
    Summary:
     a. Install member MXGSAS as JCL Procedure MXGSAS in your PROCLIB.
     b. Allocate a 90-cyl PDS:  MXG.V1305.MXG.SOURCLIB, and use IEBUPDTE
        to read the MXG tape to create the 2500+ member Source Library.
     c. Allocate a 1-cyl PDS:  MXG.V1305.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 V1305.USERID.SOURCLIB.
     d. Allocate a 1-cyl SAS Data Library:  MXG.V1305.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.V1305.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.V1305.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.V1305.USERID.SOURCLIB, then you must reinstall your site's
        tailoring for that IMAC, starting with the IMAC member from the
        MXG 13.05 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 13.05 in its own set of libraries. When
     parallel testing is complete and are ready to implement MXG 13.05
     in production, rename your three current MXG Production Libraries
     (MXG.MXG.SOURCLIB, MXG.USERID.SOURCLIB, and MXG.MXG.FORMATS) to
     (MXG.BACK.MXG.SOURCLIB, MXG.BACK.USERID.SOURCLIB, MXG.BACK.MXG....)
     and rename the MXG.V1305.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 "
"UNINITIALIZED", "TRUNCATED", "NEVER BEEN", "NOT FOUND", "CONVERT",
"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 that described in the change text (which might have printed
 only the critical part of the correction that can be made by paper).

 Scan each source member named in any impacting change for any comments
 at the beginning of the member for additional documentation, since the
 documentation of new datasets, variables, validation status, and notes,
 are often found in comments in the source members.

Alphabetical list of important changes after MXG 12.12:

  Dataset/
  Member   Change    Description

  ANALALL  13.076  Print of All SMF records from a job was enhanced.
  ANALAPAF 13.014  Semicolon missing in report program.
  ANALCISH 13.046  Report enhancements for CICS Shutdown reports.
  ANALCISH 13.113  CICS Shutdown may cause NOTSORTED error.
  ANALCNCR 13.036  Validation closed several exposures.
  ANALCNCR 13.047  ANALCNCR failed when invoked by ANALTAPE or ANALMTP.
  ANALDB2C 12.318  NO MATCHING IF error because colon vice semicolon.
  ANALDB2R 12.328  Syntax errors with PMACC01 or PMACC02 report.
  ANALDB2R 13.042  DBID/OBID mapping enhanced to include timestamp.
  ANALDB2R 13.058  BY VARIABLE STRTTIME IS NOT ON INPUT DATA error.
  ANALDB2R 13.079  DB2 Statistics Summary PMSTA01, Audit report fixes.
  ANALDB2R 13.106  Statistics Report correction, FORMAT NOT FOUND.
  ANALDB2R 13.118  Final (?) corrections to Statistics and Audit Reports
  ANALDB2R 13.159  More Statistics Report errors, but at field level.
  ANALPATH 12.325  Cross-System DASD Reports cols ran together.
  ANALPGNS 13.003  Failed if you changed RMFINTRV duration in IMACRMFI.
  ANALRMFR 13.134  Data/time selection crossing midnight failed.
  ANALTALO 12.327  VARIABLE NOT FOUND error.
  ANALTALO 13.006  Variable SYSTEM NOT FOUND in MXG 12.12A.
  ANALTAPE 13.037  All-systems report was missing.
  ASMRMFV  13.027  0C4 ABEND if no enqueue table, additional records.
  ASMTAPES 13.135  MAINTLEV 4 of MXG Tape Mount and Allocation Monitor
  ASMTAPES 13.162  MAINTLEV 6 of MXG Tape Mount and Allocation Monitor
  FORMATS  13.061  All MXG formats for hex values use OTHER= syntax.
  FORMATS  13.127  MXG FORMATS member incompatible with SAS Version 5.
  GRAFLPAR 13.060  MXG 13.01 only.  NAME uninitialized error.
  IMACFILE 13.109  Select CICS records by APPLID/SUBTYPE example.
  IMACICSA 12.324  SAP Journal data times formatted correctly.
  IMACICSA 13.077  CICS SAP variable STCTIMTR may be wrong.
  JCLDAYDS 12.316  DCOLLECT output LRECL=644 instead of LRECL=264.
  JCLPDB6  13.018  Member ASUMDB2S does not exist error.
  MONTHBLD 13.015  SORT error building monthly TYPE72, wrong BY list.
  TRNDDB2S 13.031  Variables QTPUBD and QTXAIRL incorrect spellings.
  TRNDTALO 12.327  Syntax error due to missing comma.
  TYPEACF2 13.112  ACF2 subtype "L" logic (ACF2JR dataset) redesigned.

  TYPEACHE 13.005  CRR 1.6 with 3990-6 in Basic Move, values wrong.
  TYPEAUTO 13.091  Support for LEGENT's AUTOMATE SMF record.
  TYPEAUTO 13.102  Corrections to initial support for AUTOMATE.
  TYPEAXC  13.149  Support for Kodak AXCIS Optical Disk SMF records.
  TYPECACH 13.103  Support for 4-digit UCB in Cache RMF Reporter data.
  TYPEDCOL 13.105  INPUT STATEMENT EXCEEDED with SMS 1.2 DCOLLECT.
  TYPEEDGS 13.124  IBM RMM SMF record INVALID DATA FOR MDUCDATE.
  TYPEHIPR 13.120  Support for Boole & Babbage HiperCache V1.4.3.
  TYPEHMF  13.038  Support for HMF subtypes 4 and 5.
  TYPEHPAI 13.010  Support for HP-PCS data from HPUX UNIX.
  TYPEHPSU 13.010  Support for HP-PCS data from SUN UNIX.
  TYPEHPUX 13.010  Support for HP-PCS data from AIX UNIX.
  TYPEHSM  13.131  Corrections to HSM FSR segment in SMF record.
  TYPEHURN 13.085  Support for Antares' HURON ObjectStar SMF record.
  TYPEICE  13.026  ICEBERG subtype 5 extents and TOIOTIME wrong.
  TYPEILKA 13.130  Internet addresses were not converted to num-point.
  TYPEIMSA 13.013  IMS DEDB and MSDB counts from fastpath type 59.
  TYPELMS  12.326  Support for Memorex/Telex LMS Version 3.1 (INCOMPAT).
  TYPEMON8 12.315  NO MATCHING DO/SELECT error, 'TD' record support.
  TYPENAF  13.094  NAFLOGOF dataset variables incorrect.
  TYPENAF  13.133  Candle's Supersession Release 147 PTF QLV1372
  TYPENDM  13.070  Variable NDMDSDSN (Source DSN) added to NDMCT.
  TYPENDM  13.146  Connect Direct (formerly NDM) minor corrections.
  TYPENSPY 13.021  NETSPY Type N subtype 06/07 support incorrect.
  TYPENSPY 13.022  Support for NETSPY Release 4.6 (compatible).
  TYPENSPY 13.059  INPUT STATEMENT EXCEEDED for NETSPY type X record.
  TYPENTCP 13.144  Support for NetCompress SMF records.
  TYPEOPC  13.092  Support for OPC Release 3.0 (INCOMPATIBLE).
  TYPEPKMN 13.145  Support for Packet/Main SMF records.
  TYPEQAPM 13.051  Support for OS/400 Version 3.1.0 wrong in MXG 12.12.
  TYPEQAPM 13.071  OS/400 Version 3.1, DSARM/DSTYPE reversed.
  TYPERACF 13.030  Support for IBM's IRRDBU00 RACF Database Unload.
  TYPESAMS 13.080  Support for Sterling SAMS Storage Automation SMF.
  TYPESOLV 13.028  Support for Sterling SOLVE NCL CPU-time accounting.
  TYPETCP  13.008  Support for TCP/IP APAR PN69321-PN69322.
  TYPETMNT 13.135  PROGRAM=IEFIIC records are again deleted by TYPETMNT.
  TYPETMON 12.320  Landmark Version 1.3 variables were not INPUT.
  TYPETMS5 13.083  Support for TMS (CA-1) Release 5.1 (compatible).
  TYPETMS5 13.123  New variables from 5.1 added to final datasets.

  TYPETSOM 13.143  TSO/MON 6.1 only, TRIVTM,NTRIVTM,LONGTM too small.
  TYPEVMXA 13.126  Sterling's VM/Monitor MONWRITE records cause error.
  TYPEVMXA 13.137  Support for MICS VM Data Transmission Program output.
  TYPEWYLA 13.075  Support for ACS Wylbur Accounting SMF record.
  TYPE102  13.009  T102S145 QWn145OB values wrong.
  TYPE110  12.321  CICS Statistics CICDS and CICEODRV datasets wrong.
  TYPE110  13.057  CICSLSRR variables A08BKCTD/A08BKDTD incorrect.
  TYPE116  13.049  Zero observations in dataset TYPE116.
  TYPE1415 13.002  DSNAME='UNKNOWN...' set incorrectly for multi-vol.
  TYPE1415 13.064  Multi-UCB type 1415 SMS fields wrong.
  TYPE16   13.093  Support for DFSORT Release 13 (INCOMPATIBLE).
  TYPE24   13.066  Fields added by MVS/ESA 5.2
  TYPE28   13.072  Support for NPM Version 2.2 APAR OW08641.
  TYPE30   13.065  Negative value for EXECTM due to IBM leapseconds.
  TYPE30   13.066  Fields added by MVS/ESA 5.2
  TYPE30   13.073  ABEND value may be wrong in TYPE30_5.
  TYPE32   13.084  Support for APARs OW10393 and OW12856.
  TYPE42   13.066  Fields added by MVS/ESA 5.2
  TYPE6    13.056  4-Digit remote support incomplete.
  TYPE74   13.004  MVS/ESAS 5.1 TYPE74ST dataset had duplicate/missing.
  TYPE74   13.035  Support for APAR OW04653 added to TYPE74ST dataset.
  TYPE80A  12.323  Invalid SUBSTR function, STOPOVER error corrected.
  TYPE92   13.155  Support for OpenMVS File System I/O SMF type 92.

  VMXGHSM  13.108  Dataset DGN corrected for multiple dump copies.
  VMXGINIT 13.033  New macro variable, <#&SINGLE-WORD SPELLING ERROR.#>
, is now GLOBALed.
  XMXGSUM  13.097  Final validation enhancements.
  YEAR2000 13.110  MXG Position Paper on support for the Year2000.
  YEAR2000 13.158  Phase one support for the Year2000.
  VMXGSUM  13.152  VMXGSUM incompatibity for user-written invocations.

Inverse chronological list of all Changes:



===Changes thru 13.165 thru 13.001 and 12.328 thru 12.315 were printed
   in this newsletter.

===Changes thru 12.314 were included in MXG 12.12 dated Mar  1, 1995===
   (changes thru 12.304 were printed in MXG Newsletter TWENTY-SEVEN)

   ALL changes (both current and for all prior versions of MXG)
   are contained in member CHANGESS.
****************NEWSLETTER TWENTY-SEVEN*********************************










              MXG NEWSLETTER NUMBER TWENTY-SEVEN March 1, 1995

Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE

                         TABLE OF CONTENTS                          Page

I.    MXG Software Version 12.12, Mar 1, 1995, shipped to all sites.  2
II.   MXG Technical Notes                                             5
  1.  Pentium chip defect identification.                             5
  2.  Dealings with holidays.                                         5
  3.  Conversion of GMT timestamps to local time using MXG exits.     5
  4.  MXG Execution under Windows, OS/2, or UNIX                      6
III.  MVS Technical Notes                                             7
  1.  APAR OW07300 type 89 Measured Usage Charges record.             7
  2.  Memory measures in RMF and SMF data at PERFGRP/SRVCLASS/task.   7
  3.  Chuck Hopf's examination of how BLSR helps VSAM performance.    8
  4.  CPU ID 6 missing in 9021-941 machine until PTFs applied         9
  5.  APAR OW08903 corrects wrong SRVCLASS in type 30 SMF             9
  6.  APAR OW08534 incorrect type 80 SMF record created for           9
  7.  APAR OW08302 type 89 records might not be created.              9
  8.  APAR OW07446 required for N_UP support for type 6 SMF.          9
  9.  APAR OW08890 errors in type 61 SMF record after OW03544.        9
 10.  APAR PN61950 for DB2 Release 3.1.0, missing QXST....            9
 11.  APAR OW06510 DCOLLECT errors (only at HDP3320/HDP3330 level)    9
 12.  Type 42 records contain I/O measures not available elsewhere.   9
 13.  Non-zero value for LEAPSECONDS offset causes time differences. 10
 14.  SMF records can be lost without an SMF lost data event.        10
 15.  You cannot measure the time a job spends in the HOLD.          11
 16.  Hardware Data Compression in IBM mainframes.                   11
IV.   DB2 Technical Notes                                            11
  1.  APAR PN63234 corrects DB2 type 101 SMF record subtype error.   11
  2.  Track DB2 I/O activity with TYPE42DS data.                     11
  3.  DB2 Elapsed time in DB2ACCT is not valid.                      12
V.    CICS Technical Notes                                           12
  1.  APAR PN34573 CICS EOD Shutdown Statistics for OPEN files.      12
VI.   SAS Technical Notes                                            12
  1.  CANNOT ACCESS LIBREF ddname NOT VALID FORMAT FOR ACCESS SASEB  12
VII.  IMS Technical Notes                                            13
  1.  ABEND 878-10 running TYPEIMSA with 4 log tapes.                13
  2.  Candle's ITRF errors reported in Newsletter 26 are fixed.      13
VIII. Incompatibilities and Installation of MXG 12.03.               13
  1.  Members IMAC7072 IMAC74 IMACDB2 IMACPDB IMACWORK changed.      13
  2.  Installation instructions.                                     13
IX.   Online Documentation of MXG Software.                          14
X.    Changes Log                                                    16
      Alphabetical list of important changes                         16
      Changes 12.306 thru 12.129                                  19-60
       (Changes 12.128-12.001 were in Newsletter 26)


         COPYRIGHT (C) 1995 BY MERRILL CONSULTANTS DALLAS TEXAS

I. MXG Software Version 12.12, dated Mar 1, 1995, the "Production" MXG,
   was shipped to all sites with this newsletter, containing:

   Major enhancements added in MXG 12.12 dated Mar  1, 1995:

    Support for OS/400 AS/400 Version 3.1.0 INCOMPATIBLE.
    Support for PR/SM APAR OW078986 adds "MVS Wait" to "LPAR Waits"
    Support for Type 99 Subtype 1 added.
    Support for CICSAO availability measurement SMF written by CICSAC.
    Support for Mitchem's ACC/SRS user SMF record.
    Support for LEGENT SAR Cross Memory Session Logoff user SMF record.
    Support for Network Systems DXE channel RDS user SMF.
    Support for Velocity Software XAMAP Version 2.2.
    Support for CICSAO user SMF record for CICS availability.
    Support for Boole & Babbage IMF Version 3.1 (for IMS 5.0).
    Support for VAX Accounting and Performance data.
    Amdahl's MDF now populates TYPE70PR/ASUM70PR with valid CPU time.
    Candle's ITRF product-error corrections have been validated.
    RACF TYPE80A enhanced to decode RACF commands of interest.
    REXX program to convert DB2 GTF records to SMF format for MXG.
    ANALPGNS reports CPU utilization by Performance Group.
    ANALDB2R Support for DB2 Version 3.1 DB2PM-like reports.
    ANALMTP Analysis of Tape Mounts Concurrently Waiting.
    ANALRMFR enhanced, selection by storage class, device, LCU added.
    XMXGSUM replacement for VMXGSUM is ready for full use.

   Major enhancements added in MXG 12.07 dated Feb  6, 1995:

    Support for TCP/IP Version 3.1 (incompatible).
    Support for RMDS Version 2.1 (incompatible).
    Support for TPX 4.0 (compatible with one line edit).
    Support for RMF Monitor III ("ZRB") for MVS/ESA 4.3 - partial.
    Support for Xerox Print Service Manager XPSM SMF record.
    Support for BGS's BEST/1 I/O Monitor SMF record.
    Support for Boole & Babbage CMF VSAM MRR records.
    %ANALCNCR algorithm for concurrency analysis (inits, tapes, etc.)
    Circumvention for CACHE90 zero observations with RAMAC devices.
    New TYPE72DL dataset for MVS/ESA 5.1 Goal Mode

   Major enhancements added in MXG 12.06 dated Jan  9, 1995:

    Support for NETSPY 4.5. Compatible except for LU6.2 NSPYAPPL data.
    Support for Innovation Processing's IAM user SMF record.
    VM/ESA 2.2 Scheduler records supported.
    Invalid DB2 type 101 SMF record workaround (fix is APAR PN63234).
    Revised ANALPATH reporting for MVS I/O Path analysis.
    Final (?) enhancements for VMXGSUM parsing of all dataset options.

   Major enhancements added in MXG 12.05 dated Nov 20, 1994:

    Support for MQM 1.1.2 Performance Statistics type 115 SMF record.
    Support for MQM 1.1.2 Accounting type 116 SMF record.
    Support for Omegamon for CICS V100 and V300 SMF.
    Support for Landmark Monitor for MVS Release 1.3 enhanced.
    Support for InfoAccess Release 5.1 user SMF record.
    Support for HSM APAR OW05988, adds CPU time to FSR!
    Support for Sterling Software's ASM V3.0.0 type 39 records.
    Support for CA/SQL user SMF record (same as IDMS records).
    Support for S/390 Parallel Query Server SPQS SMF 123 started.
    Correction for NPM 2.2 NPMVSaaa datasets.
    CICS Utility UTILCICS now identifies type 110s from Omegamon.
    New dataset PDB.TYPE72SC for Goal Mode Server data.
    Type 42 technical note, removal of GMT offset calculation.

   Major enhancements added in MXG 12.04A  dated Oct 23, 1994:

    Support for Omegamon for VTAM V160 (Incompatible).
    Correction to MXG 12.04-only errors:
      Type 28 Input Statement EXCEEDED error message.
      MXG Tape Unload caused return code 4, extra members unloaded.
      UTILCICS failed with syntax error
    Correction to SAP Accounting under IMS.
    Correction to NETSPY Token-Ring TIC-UTIL in NSPYTR - was too large.
    Correction to TYPE42 STARTIME/ENDTIME - may be on GMT clock.
    Technical note on Memory measurement in MVS Technical Notes.

   Major enhancements added in MXG 12.04  dated Sep 30, 1994:

    All "Chapter 99 CodeSharks" now honored in ACHAP99.
    Support for CICS/ESA 4.1.0 (compatible) adds important new measures.
    Support for NPM 2.2 (compatible, but new subtypes).
    Support for LEGENT's TSO/MON 6.1 (compatible).
    Support for Landmark TMON Monitor for CICS/ESA 1.3 (incompatible).
    Support for Landmark TMON Monitor for DB2.
    Support for STK ICEBERG SMF record subtype 5.
    Support for CA's TELEVIEW user SMF record.
    Support for APARs OW00484/UW06888/others corrupt TYPE1415 variables.
    DB2STATS variables QB3Taaaa/QB4Taaaa corrected.
    TYPE37 Short LAND segment INPUT STATEMENT EXCEEDED corrected.

   Major enhancements added in MXG 12.03A dated Aug 17, 1994:

    Support for APAF 2.2 (incompatible).
    Support for TLMS Release 5.4 (incompatible).
    Support for BETA93 1.6.1 validated (it was incomplete in MXG 12.03).
    Further DB2 3.1 corrections in TYPEDB2 and TYPE102 support.

   Major enhancements added in MXG 12.03 dated Aug 4, 1994:

    Support for MVS/ESA 5.1 Type 99 Subtype 2 record.
    Support for LEGENT's ASTEX Release 2.0.
    Support for UniKix Release 4.1 Binary File
    Support for EMPACT's HIPER-CACHE Version 1.1.1.
    Support for SMF Type 50 VTAM Tuning APAR OW04453.
    Support for RSD's WSF Release 3.5.1.
    Support for Omegamon II for SMS V100/V110.
    Support for BETA93 user SMF record.
    MXG Tape Mount and Tape Allocation Monitor errors now works!
    Correction for NPM Release 2.0 subtypes 214 thru 219.
    Additional DB2 3.1 Trace IFCIDs supported.
    Analysis ANALDB2C matches CICSTRAN observations with DB2ACCT.

   Major enhancements added in MXG 12.02 dated Jul 4, 1994:

    MXG Tape Mount and Allocation Monitor was revised, new reports.
    Support for IBM's CRR 1.6 (3990-3 and 3990-6) (incompatible).
    Support for DFSMS 1.2 changes to DCOLLECT (compatible).
    Support for MEMO subtype 6 record.
    Support for TCP/IP APAR PN34837 new field (compatible).
    Support for MVS APAR OW00884/UW06821 - (no impact, see MVS Notes).
    Support for IMS 4.1 Log Records (see IMS Technical Notes)

   Major enhancements added in MXG 12.01 dated Jun 15, 1994:

    Support for MVS/ESA 5.1 many new datasets (Goal Mode Incompatible).
    Support for Measured Usage SMF Record 89 and changes to type 30.
    DB2 Version 3.1 Buffer Pool statistics were incorrect in MXG 11.11.

  Probable Future Enhancements:

  EXPLORE/VSE - Partial support might just make it into MXG 12.12, full
                support of all records in second quarter 1995.

  TYPE72_4   MVS/ESA Version 5.1 Goal Mode only.  Some of the SUMmed
             fields need to be divided by number of samples, but I need
             test data to validate which variables are summed and which
             are not!  If you are running MVS/ESA 5.1 in Goal Mode and
             want to use this RMF Monitor III data, please send me an
             SMF tape (UNIT=3480,DCB=TRTCH=NOCOMP, please)!

  Following are longer range (maybe's) to be attacked:

  Huron   -  Huron SMF record - no sample SMF data, no machine DSECTS.

  EPIC    -  LEGENT has not provided the format of their tape catalog.

======================================================================

    Table of availability dates for the IBM products and MXG version:

      Product Name                     Availability     MXG Version

      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                    Jun 24  1994        12.02
      MVS/ESA 5.2.0                    ??? ??  ????        13.??
      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.       12.04
      CICS/ESA ?.?                     ??? ??, ????.       13.??
      CRR 1.6                          Jun 24, 1994.       12.02
      DB2 2.2.0                                1990         8.8
      DB2 2.3.0                        Oct 28, 1991.       10.01
      DB2 3.1.0                        Dec 17, 1993.       12.04
      DB2 4.1.0                        ??? ??, ????.       13.??
      DFSMS/MVS 1.1                    Mar 13, 1993.       11.11
      DFSMS/MVS 1.2                    Jun 24, 1994.       12.02
      NPM 2.0                          Dec 17, 1993.       12.03
      NPM 2.2                          Aug 29, 1994.       12.05
      VM/ESA  1.1.1                    Dec 27, 1991.       10.01
      VM/ESA  2.0                      Dec 23, 1992.       10.04
      VM/ESA  2.1                      Jun 27, 1993.       12.02
      VM/ESA  2.2                      ??? ??, 1994.       12.06

    Table MXG support for non-IBM products:

      Product Name                                      MXG Version

      Landmark
       The Monitor for CICS/ESA 1.3                        12.12
       The Monitor for MVS/ESA 1.3                         12.05
      Candle
       OMEGAMON for CICS V300 User SMF Record              12.05
      Boole & Babbage
       IMF 3.1 (for IMS 5.1)                               12.12

II. MXG Technical Notes

 1. You can identify that your Pentium chip is defective by using the
    Windows Calculator (in Accessory Window) and calculating:
       4195835/3145727*3145727
    Good chips return a value of 4195835, bad chips return 4195579.


 2. Dealing with holidays.

    First, I do not think it is necessary to separate holidays into a
    separate value of SHIFT (or to re-classify holiday dates to the
    Weekend shift) for reporting.  Especially for resource data, if you
    plot weekly data rather than monthly, the weeks containing holidays
    will naturally separate from the real weeks so you can clearly see
    the growth in weekly prime capacity, and you do not need to make the
    reporting more complicated with a new SHIFT.  However, if you decide
    (or your boss decides!) that you must separate holidays, you can use
    this example (which may eventually be a formal part of MXG):

    a. Build a format of holiday dates for your site, using:

           PROC FORMATS LIB=LIBRARY;
           VALUE MGHOLID
            '01JAN94'D='Y'
            '04JUL94'D='Y'
            ;

       (If you put your PROC FORMATS code in member IMACFMTS, then when
       you install a new version of MXG and create/update the
       MXG FORMATs library, your code will be executed to create/update
       your MGHOLID format in the MXG format library, or you could put
       this "Installation Format" in its own format library and use the
       new FMTSEARCH= option in an OPTIONS statement to find the format.
         //SYSIN DD *
          OPTIONS FMTSEARCH=(MYLIB LIBRARY);
       Remember to allocate the //LIBRARY DD with DISP=OLD (or DISP=NEW)
       to write to the format library.)

    b. Then use the PUT function with the MGHOLID format to determine if
       the date is a holiday; this logic would be added to MXG member
       IMACSHFT, by adding after the last line:

       IF UPCASE(PUT(DATEPART(DATETIME),MGHOLID.))='Y' THEN SHIFT='H';

       to create a fourth value of the variable SHIFT for holidays.
       The point is that you must create a table of holidays, using a
       PROC FORMAT, and you then use the above PUT function to do the
       table lookup to determine if a specific date value is in the
       list of (holiday) dates in your MGHOLID format.

 3. Conversion of GMT timestamps to local time using MXG exits.

    If you have a non-zero value for TIMEZONE specified in member CLOCKn
    of your SYS1.PARMLIB, some fields in some SMF records (notably, the
    start/end timestamps in DB2ACCT, CICSTRAN, and TYPE42DS datasets)
    use that non-zero value to store GMT time instead of local time.
    At some time in the future, IBM has plans to carry the value of the
    GMT offset into these records so that I can correct GMT back to your
    local time, but until that fix is provided by IBM, you must do it
    yourself, using the MXG "Exit" member for the dataset to be changed:


       Dataset     Exit Member    Variables to be corrected
       CICSTRAN     EXCICTRN       STRTTIME,ENDTIME
       DB2ACCT      EXDB2ACC       QWACESC,QWACBSC
       TYPE42DS     EXTY42DS       STARTIME,ENDTIME

    Notes a-c were revised Aug 23, 1996:
    a. To correct the DB2 timestamps from GMT to USA EST time zone, you
       would insert these two lines:
         QWACESC=QWACESC-HMS(5,0,0);
         QWACBSC=QWACBSC-HMS(5,0,0);
       before the OUTPUT statement in member EXDB2ACC, as this would
       subtract 5 hours from the GMT value.

    b. To correct the CICS timestamps from GMT to USA PDT (-7 GMT), in
       EXCICTRN, insert:
            IF SMFPSRVR LT 41.0 THEN DO;
              STTRTIME=STRTTIME-HMS(7,0,0);
              ENDTIME =ENDTIME-HMS(7,0,0);
            END;
       The test for CICS/ESA 4.1 is needed because Change 13.247 added
       the MXG support for automatic correction of GMT.  When all of
       your systems are at 4.1 or later, you can delete this insertion.

    c. These examples only work six months of the year.  When Daylight
       Savings (or Summer) Time changes, you must change the hours.


 4. MXG Execution under Windows, OS/2, or UNIX.

    As described in MXG Newsletter 25, MXG Software CAN be executed
    under Windows, OS/2 or UNIX versions of the SAS System.  That paper
    also states that "just because you CAN does not mean you SHOULD"!

    I still strongly recommend that MXG be executed under MVS to create
    the MXG datasets on the mainframe, not only because MVS is
    technically superb at handling large volumes of data and providing
    large virtual space for the large MXG programs, but also because the
    job and file management facilities of MVS (i.e., MVS catalog, JCL,
    single DDNAME for an entire PDB library, backup, etc.) are automated
    so that MVS will require much less human time to monitor and manage
    the MXG job stream.  Once you have built your MXG datasets on your
    mainframe, then it does make sense to use SAS on your Workstation
    or PC to graph, report, and/or develop analyses and reports,
    especially when your plotters and graphic presentation devices
    are PC or Workstation based.  You can bring down only the summary
    data you need for today's analysis or testing, keeping the PDB data
    libraries archived on the mainframe you are measuring.

    MXG was enhanced to run on PCs and Workstations, not because it is
    the best place to execute MXG, but because some MXG technicians were
    told they would lose their job if they could not move the SAS work
    off the mainframe (typically, MXG was the only SAS application at
    these sites, and the SAS mainframe license cost can exceed the
    technician's salary!)   As a result, the "vanilla" (unmodified)
    BUILDPDB has been successfully executed under Windows, OS/2, and
    UNIX on several hardware platforms. MVS data records that require
    Assembly routines will not execute on PCs or Workstations;
    compressed records from Landmark, Candle, and IBM require assembly
    routines to decompress on the fly, or the records must first be
    uncompressed on the mainframe before download.  Because Windows and
    OS/2 are limited to 255 open files, large MXG programs (BUILDPDB
    plus many additional user SMF records, TYPE102 transit report) may
    not run at all without user changes (such as splitting the data into
    two runs).  Nevertheless, a dozen or so sites have successfully
    moved their MXG application from their mainframe to UNIX
    workstations, and I will continue to support MXG execution on all
    SAS platforms that I can, in spite of my present preference for MVS!

    There is only one MXG Software product, and it will execute on any
    supported SAS platform.  MXG is shipped on 3480 cartridges, which
    can be unloaded on the mainframe and then downloaded to the PC or
    Workstation; installation instructions are in MXG Newsletter 25,
    "Executing MXG on PCs and Workstations".  If required, MXG can be
    shipped as a PKZIP file on five PC diskettes.

    There is only one MXG Software License, and its price and terms
    apply no matter what operating system or hardware platform you use
    for the execution of MXG Software; MXG is licensed at each physical
    site address at which the data is created or processed, and not by
    the make, model, manufacturer, color, speed or number of engines at
    that site.

III. MVS Technical Notes

 1. APAR OW07300 reports (without PTF) that type 89 Measured Usage MULC
    records report falsely high usage for TSO if the site has an OEM
    multi-user product in use, since these multi-session products
    attach X number of IKJEFT01 sessions in a single address space, and
    since IKJEFT01 registers X times, SMF multiples X times the actual
    usage.

 2. Memory measures in RMF and SMF data for the PERFGRP/SRVCLASS/task:

    Prior to MVS/ESA, RMF provided only the MSOUNITS-based measure of
    the real memory occupied by tasks in each performance-group-period
    in TYPE72 dataset.  From the MSOUNITS variable (which is the product
    of the pages times seconds of TCB time times a constant), MXG
    creates the variable AVGMEMSZ, the number of "K" bytes of memory
    occupied by this performance group period (so a value of
    AVGMEMSZ=250 meant 250K bytes).  The AVGMEMSZ was never really
    accurate (it measures only the pages held while the task was
    executing TCB-only, and any pages held while the address space was
    waiting or executing under SRB, etc., are not included), but it was
    the only measure we had!

    MVS/ESA Version 3 provided the much more useful measure of the total
    number of frame-seconds (CSTORE+ESTORE) when page-frames were
    occupied by tasks that were "resident" in real memory, for each
    performance-group-period ("PGP"), in variable ACTFRMTM in dataset
    TYPE72.  The ACTFRMTM eliminated the TCB-only error in the old
    MSOUNITS-based measures, and are thus much more accurate, since they
    include the pages occupied by each PGP, whether resident tasks are
    executing or waiting.  However, these "ACTFRMTM-based" measures do
    not include the MVS Nucleus pages, nor pages in the LPA (Link Pack
    Area), nor pages in the CSA (Common Storage Area), since those page-
    frames are not "owned" by an address space (although the size of
    each of those areas is available in the TYPE71 dataset).  And of
    special significance, these "ACTFRMTM-based" measures do NOT include
    any page-frames that are occupied by Logically Swapped Address
    Spaces, which can be significant with lots of TSO users!  (One site
    found the total of the TYPE72 and TYPE71 data was 51MB in a machine
    with 64MB of total memory, implying 13MB used by LSWAPs!).

    MVS/ESA Version 4 added the ACTESFTM variable, the frame-seconds of
    ESTORE page-frames occupied, so the CSTORE, ESTORE, and total
    page-frames can now be separately calculated.

    MVS/ESA Version 5 made no changes in memory measurements, but the
    TYPE72 dataset will exist only in "Compatibility Mode"; when MVS is
    in "Goal Mode", these same memory measures exist only in the new
    TYPE72GO dataset (and instead of Performance-Group-Period, the new
    entity is Service-Class-Period).

    The TYPE72GO dataset still contains the archaic MSOUNITS & AVGMEMSZ
    variables; variables ACTFRMTM and ACTESFTM were added with MVS/ESA,
    and MXG 12.04 adds new variables TSTORE72, CSTORE72, and ESTORE72,
    which are the ACTFRMTM-based measures of Total, CSTORE, and ESTORE
    occupied storage.  These new variables contain the number of bytes,
    but are formatted with the special MGBYTES format, which converts
    bytes to KB, MB, GB, etc., and adds that suffix when the variable
    is printed (thus a value of 5,242,880 bytes would print as "5MB").

    In the RMFINTRV dataset, where Performance Groups/Service Classes
    are mapped into workloads (by your IMACWORK member), MXG creates the
    ACTFRMTM-based memory occupied by each individual workload in the
    variables BATMEMR, TSOMEMR, CICSMEMR, ... , and total memory
    occupied by all workloads in variable TOTMEMR.  These xxxxMEMR
    variables are also in bytes and formatted with MGBYTES.

       The RMFINTRV dataset still contains the (now-useless)
       MSOUNITS-based TCB-only memory occupied variables BATWKST,
       TSOWKST, CICSWKST ... and their total in AVGWKSET (note that if
       AVGWKSET was equal to 5MB, it would print as 5120, because it is
       units of K, and 5120*1024=5,242,880, or 5MB).

    I have recently (MXG 12.04) enhanced the TYPE72GO dataset with three
    new variables, TSTORE72, CSTORE72, and ESTORE72, the ACTFRMTM-based
    measures of total, CSTORE, and ESTORE bytes occupied by each PGP.

    Finally, in the TYPE30 datasets, at the job/step/interval level,
    only MSOUNITS-based TCB-only measures exist, with PAGESECS the
    TCB-only frame/page-seconds occupied, from which the AVGWKSET
    variable is calculated for TYPE30_4, TYPE30_5, TYPE30_V datasets,
    but all of these TCB-only-based memory metrics are of very limited
    use because of their inherent inaccuracy.



    The following chart (hopefully) summarizes whats captured where:

                  -----------GOOD STUFF----------------        --BAD--

    TYPE72:
    Framesecs:    ACTFRMTM    ACTESFTM   ACT(FRM-ESF)TM        MSOUNITS
    Per-PGP       TSTORE72    ESTORE72   CSTORE72              AVGMEMSZ

    RMFINTRV:
    Per-Wkload:   BATMEMR        n/c        n/c                BATWKST
                  TSOMEMR        n/c        n/c                TSOWKST
                  CICSMEMR       n/c        n/c                CICSWKST
                    ...                                          ...
                  OTHRMEMR       n/c        n/c                OTHRWKST

    All-Wkloads:  TOTMEMR        n/c        n/c                AVGWKST

    TYPE30:
    Framesecs:      n/c          n/a           n/a             PAGESECS
    Average size:   n/c          n/a           n/a             AVGWKSET

        n/c = not-calculated, but could be
        n/a = not-available, does not exist          (16May2000)

 3. Chuck Hopf's examination of how BLSR helps VSAM performance (see the
    member ADOCBLSR) concentrated on Index Buffers, because usually that
    is where the most benefit can be gained.  However, if your VSAM file
    has significantly more EXCPs to the Data Area than there are records
    in the file, increasing the Data Buffers can also be rewarding.  In
    one case, a batch job accessing a KSDS with 78,000 records recorded
    over 400,000 I/Os and the job ran for over 2.5 hours.  Increasing
    the number of 4K data buffers from 200 to 2,000 dropped the I/Os to

    only 70,000 and the run time to only 70 minutes!  Adding 5,000 more
    4K buffers in Hiperspace dropped the I/Os to 19,000 and the run time
    to 19 minutes!  Note that while buffers increased from 200 to 7,000
    (a factor of 35) the actual memory buffer-minutes used increased
    only by a factor of 4.4 (from 30,000 buffer-minutes with 200 buffers
    for 150 minutes to 133,000 buffer-minutes with 7,000 buffers for 19
    minutes).  Finally, note that the 7,000 buffers allocated are enough
    for about 10% of the entire file to be resident, suggesting the old
    90:10 rule; 90% of the activity hits 10% of the file!  MXG analysis
    program ANALBLSR can identify candidate jobs whose run time can be
    improved by either data or index buffers.            (1Oct94)

 4. Andrew Jeppeal discovered that his 9021-941 machine with CPU IDs of
    0,1,2, and 6 did not contain CPU busy for CPU #6 until his site put
    PTFs UY98489/UW00101/UW00619/UY98312 maintenance on their system!

 5. APAR OW08903 reports PTF correcting wrong SRVCLASS in type 30 SMF
    records for TSO users, and DPRTY (SMF30PTY) contained '09'x instead
    of the expected '00'x value.

 6. APAR OW08534 reports PTF incorrect type 80 SMF record created for
    ALTUSER command with DELCATEGORY keyword.

 7. APAR OW08302 reports (no PTF yet) that type 89 records might not be
    written when the local time is not in synchronization with the GMT;
    that is, sites who input their local time manually or who issue the
    'T CLOCK=hh.mm.ss' command before SMF is started/restarted are most
    likely to experience this situation.

 8. APAR OW07446's PTF is required for N_UP support to cause type 6 SMF
    record variable SHEETPRN (SMF6IMPS) to correctly count the number of
    sheets of paper printed (or impressions).  Without this APAR, if you
    use the new N_UP PSF facility (presumably, to print multiple logical
    pages on a single sheet side), the count in SHEETPRN will be wrong
    (and will be too large, because logical pages printed are counted.)
    With the APAR, SHEETPRN correctly counts the number of sides of
    sheets of paper printed.

 9. APAR OW08890 reports errors in type 61 SMF record after OW03544,
    notably the Entry Name, ENTRNAME, contains garbage.

10. APAR PN61950 for DB2 Release 3.1.0 puts back the missing QXST....
    fields in the DB2ACCT (IFCID 3) type 101 SMF record.

11. APAR OW06510 corrects DCOLLECT errors (only at HDP3320/HDP3330 level
    of DCOLLECT) wherein block sizes were not determined, which caused
    the space calculation in the DCOLLECT record to be wrong.

12. Type 42 records contain powerful I/O measures that are simply not
    available anywhere else in MVS.  Of very specific note, the I/O
    activity to DB2 datasets, interval by interval, and job by job
    are now available at the DB2 table-space level in TYPE42DS (see the
    discussion in DB2 Technical Notes, below), and PTFs now exist that
    will create TYPE42DS data for ANY dataset, not just datasets managed
    by SMS.  The majority of the type 42 data is quite good, but you
    should be aware of these additional type 42 notes:

       In addition to the problems with STARTIME/ENDTIME in the TYPE42SR
       (subtype 5) and TYPE42DS (subtype 6) that are discussed in the
       text of Change 12.180 (revised, Nov 9), these are concerns:


       Subtype 1: Added after NEWSLETTER TWENTY-SEVEN was printed:
                    This was an IBM error in SMF42TNT, that is fixed by
                    APAR OW11254, PTF UW15167.
                  TYPE42SC/TYPE42TO - Storage Class Detail and Totals:
                  The interval duration, DURATM (SMF42TMT), ranges from
                  57:13.00 to 57:27:00, instead of the 60 minutes, but
                  the delta time between successive SMFTIME records is
                  60 minutes.  There appears to be 2-3 minutes in each
                  interval that are not measured.
       Subtype 2: TYPE42CU/TYPE42VL - 3990 CU Counts and Volume Status.
                  The statistics in the Control Unit Cache Section, in
                  TYPE42CU, is extremely suspect.  The LASTTIME is only
                  2.5 minutes before CURRTIME, which is about 2 minutes
                  before SMF time, yet the records are written hourly.
                  Worse, the current count (CCT) and last count (LCT)
                  are independently accumulated (for each SMF42CID), and
                  give very different counts of I/O activity in the
                  successive records:
                     CURRTIME     CCT     LASTTIME     LCT     SMFTIME
                     14:56:12    47258    14:53:42    63121    14:58:37
                     15:56:18    64579    15:53:47    81884    15:58:38
                       The delta-current is 3606 seconds, and delta-last
                       is 3605 seconds, but delta-CCT is 17321 while the
                       delta-LCT is 18763 I/Os for the same hour.
       Subtype 5: Even though this is an interval record, and should not
                  be delayed, we have data showing and ENDTIME 12:00:00
                  and an SMFTIME of 13:01:22 (and the site had a GMTOFF
                  of 1 hour).  This may only indicate that it took 82
                  seconds after the end of the interval for MVS to allow
                  the type 42 logic to access the SMF buffer (i.e., it
                  may be a real measure of real contention for the SMF
                  buffer), but it is still under investigation.
       Subtype 6: In addition to the problem noted in Change 12.180 with
                  INTVCLOS=1 (INTERVAL) SMFTIMEs much later than ENDTIME
                  I have instances for INTVCLOS=0 (CLOSE) records which
                  have SMF42PTE=22:00:27.90 with SMFTIME=17:00:09.88,
                  and the site has a GMT offset of 5 hours, AND THE SITE
                  HAS A LEAP SECOND OFFSET OF 18 SECONDS!, which is why
                  the PTE time is later than SMFTIME.  See next note!

       PTFs in 1994 now cause TYPE42DS (subtype 5) observations for ALL
       datasets, not just SMS managed datasets:  for SMS 1.1 UW06888,
       UW07846,UW08562,UW09726,US09553 and for HSM 1.1 UW08973-74;
       for SMS 1.2 UO08757,US09725 and for HSM 1.2 UW11682.

13. Sites with non-zero value for LEAPSECONDS offset will find that the
    timestamps from STCK macro (i.e., those read in with TODSTAMP8.)
    will include the value of leap seconds, but the SMF time stamp (byte
    3 of all SMF records), and probably all other timestamps in SMF
    format (i.e., those read in with SMFSTAMP8.) do NOT include the
    leapseconds offset.

14. SMF records can be lost without an SMF lost data event.  One site
    has 7.5MB of type 110 CICS statistics records to be written at each
    CICS interval pop.  If the CICS interval pop happens to occur at the
    same instant as a SWITCH SMF command (to switch recording from MANX
    to MANY), the SMF SVC immediately returns a code that "SMF Buffers
    are not available", and CICS discards the statistics records with
    only its own DFHxxxx message on the CICS log to indicate that data
    was not written.  This site never used more than 12MB of SMF buffer
    space, but at the instant of the CICS interval pop, the 7.5MB of
    data filled current buffers until SMF needed to expand its buffer
    space.  However, the SMF SWITCH process is mutually exclusive with
    the buffer expansion, so SMF could not expand buffers and thus SMF
    returned the "no buffers available", and CICS then chose to discard

    the rest of the statistics records.  Minimizing the number of SWITCH
    SMF commands (by increasing the size of your MANX dataset so it can
    hold an entire day's data and is thus dumped only once a day) would
    minimize the exposure.  In addition, scheduling that daily SMF DUMP
    (which SWITCHES at least twice) so that it is not concurrent with
    the interval pop can avoid the data loss.  The exposure is reduced
    significantly in MVS/ESA 5.1, because IBM has increased the minimum
    size of the SMF buffers from 1MB to 8MB (and IBM APAR OY56676 has
    been in existence since 1992 to accomplish that increase).  Both
    CICS and DB2 will discard records and write messages to their log if
    they find buffers are not available, but theoretically, any writer
    of SMF records could discard records in this situation.
    For DB2, its SMF records in DB2STATS count if records were lost; see
    Change 12.279 for the variables to examine if any records were lost,
    and if so, from which IFCID (accounting, statistics, audit, etc.).
    Note that APAR OY56676 indicates that another symptom of this
    problem is the occurrence in SYSLOG of MSG IEE979W (indicating SMF
    data is lost) without any preceding MSGs IEE978E or IEE986E (which
    occur when there are no buffers).

15. It is not possible to measure the time a job spends in the HOLD
    queue.  Jobs that are read into HOLD can be identified by PDB.JOBS
    variable TYPRUN='HOLD', but the time of release of the job is not
    reported in any SMF record.  Furthermore, if the job is read into
    the Execution Queue and then placed in HOLD, there is not even any
    flag that lets you know the job went into HOLD.  If you know what
    are reasonable worst-case durations for the input queue time for
    each job class, you could establish heuristic ceiling values, and
    if a job exceeds that ceiling value, you could "declare" that the
    job must have been in hold during some of its input time, and could
    exclude that job from queue time calculations.  If you use average
    values of input queue time you are really doomed if only a few jobs
    in a class were held; counting the percentage of jobs in a class
    that initiated in some duration is much less affected statistically
    and has always been my recommendation instead of average values.
    Note that Duplicate JobName hold can be detected, as is done in the
    ASUMJOBS algorithms.  There are JES exits from which SMF records
    could be written to timestamp when jobs are released from hold, and
    if you write and test the code, I will share it with MXG users!

16. Hardware Data Compression in IBM mainframes, as I understand it, is
    implemented at the dataset level, and is enabled through the SMS
    Data Class parameter.  Thus to identify which (if any!) datasets are
    compressed, you would examine the DATACLAS variable in the TYPE1415
    (non-VSAM) or TYPE64 (VSAM) MXG data.  To look at CPU costs with and
    without data compression, you would use TYPE1415/TYPE64 to get the
    READTIME JOB and SMFTIME values and select PDB.STEPS with the same
    READTIME & JOB and with INITTIME LE SMFTIME LE TERMTIME to get the
    step resources with and without compression.  Let me know what you
    discover and I will share it!

IV.   DB2 Technical Notes

 1. APAR PN63234 corrects DB2 type 101 SMF record subtype error.  When
    more than 10 package segments occur, a type 101 subtype 1 record is
    supposed to be written, but IBM instead put a zero in the subtype,
    which made MXG think this was a normal DB2ACCT record, causing an
    observation in DB2ACCT with trashed values for many fields!
    This APAR makes the subtype value correct.  See Change 12.220.

 2. It has always been impossible to track DB2 I/O activity (because the
    Media Manager thought itself so fast that it was not necessary to
    count I/Os!), but now, the TYPE42DS dataset (from type 42 SMF data)

   records both interval and close statistics on ALL datasets (not just
   those managed by SMS).  As both the DB2 Database and Tablespace or
    Indexspace names are contained in the DSNAME in TYPE42DS, you can
    analyze DB2 I/O for each table for each DB2 subsystem.  The naming
    pattern for the DB2 VSAM datasets looks like this:
       DSNAME=subsystem.DSNDBD.database.table
    or, written with MXG variable names (from T102S105 dataset):
       DSNAME=QWHSSSID.DSNDBD.QW0105DN.QW0105TN
    as    QWHSSSID is the DB2 subsystem Name (almost always DB2...)
          DSNDBD   is a constant string for the data component
          QW0105DN is the DB2 Database Name, and
          QW0105TN is the DB2 Tablespace or Indexspace Name.

 3. DB2 Elapsed time in DB2ACCT (ELAPSTM=QWHCESC-QWHCBSC) is not a valid
    measure of duration in DB2 when threads do not terminate (such as
    CICS primed threads and IMS wait-for-input-message regions), because
    the QWHCESC ending time stamp is not taken until the next use of the
    thread starts - the ELAPSTM includes time when the thread was
    inactive and waiting to perform work.  This is very obvious if you
    match CICSTRAN with DB2ACCT (using member ANALUOW) and you find the
    DB2END time is greater than the CICSEND time - that portion of the
    DB2 elapsed between CICSEND and DB2END was the amount of time that
    the thread was inactive.  Now that I realize the impact of this DB2
    "feature", ASUMUOW recalculates the DB2ELAPS duration and also now
    creates new variable DB2IDLE so you can see how much of the reported
    Class-one DB2 elapsed time is really thread inactive duration.

V. CICS Technical Notes

 1. APAR PN34573 describes why CICS EOD Shutdown Statistics for OPEN
    files and LSRPOOLs are zero when CICS is shutdown normally (i.e.,
    using CEMT P SHUT.  However, if CICS an immediate shutdown (i.e.,
    using CEMT P SHUT I), the correct values are reported.  The problem
    is that normal shutdown closes the files first, and then shuts down
    the CICS region, hence zero values.  The APAR is closed with "FIN"
    (a new one for me, described as "This closing code indicates that
    this problem will be resolved if there is a next release of CICS
    after CICS/ESA Version 3 Release 3.") - Fixed In Next!


VI. SAS Technical Notes

 1. CANNOT ACCESS LIBREF ddname - NOT VALID FORMAT FOR ACCESS SASEB

    This error occurs when the dataset pointed to by DDNAME does not
    have the correct DCB attributes.  SAS libraries on MVS must be
    DSORG=PS, and the default DCB attributes are RECFM=FS,LRECL=512 (or
    block size), BLKSIZE=Half Track (because MXG's CONFIG forces half
    track to minimize DASD storage).  Especially with SMS allocation,
    your site can establish defaults that might be incorrect for SAS
    data libraries.  Usually, you can solve this error by adding a DCB
    parameter to the DD statement, for example:
        DCB=(DSORG=PS,RECFM=FS,LRECL=23040,BLKSIZE=23040) for 3380s
        DCB=(DSORG=PS,RECFM=FS,LRECL=27648,BLKSIZE=27648) for 3390s
    although you may also need to discuss your sites ACS rules with
    your SMS guru.



VII. IMS Technical Notes

 1. ABEND 878-10 running TYPEIMSA with 4 log tapes can be corrected by
    increasing the REGION parameter to 8MB, or by reducing the number of
    slots parameter from 30,000 to 20,000.

 2. Candle's ITRF errors, reported in Newsletter 26, have been fixed.
    The numeric errors were corrected by Candle PTFs last summer, and
    the blank values are now populated by new PTF QI22910, so MXG now
    fully supports Candle's Omegamon II for IMS Version 110 records.
    Some MXG users who installed ITRF last fall used MXG 11.11 quite
    effectively to analyze their IMS activity, even without the most
    recent PTF.  It appears that the errors I reported occurred during
    ITRF's "Shakedown Cruise" (see page 23 of Newsletter 17 for this
    nautical analogy), and Candle has now repaired ITRF to full service
    as a valid source of accounting and response data for IMS systems.


VIII. Incompatibilities and Installation of MXG 12.12.

 1. Incompatibilities introduced in MXG 12.12 (since MXG 11.11):

  a- IMACs that were changed (if they exist in your USERID.SOURCLIB, you
     must refit your tailoring, starting with the new IMAC member):

       IMAC7072  IMAC74  IMACDB2   IMACPDB   IMACWORK IMACTMNT
       MONTHBLD  WEEKBLD IMACCICS

  b- The JCL for processing the OPC log requires two new DDNAMES so that
     the OPC spanned records can be reconstructed and read by MXG.  See
     comments in member VMACOPC.  Member JCLTEST6 was changed also.

  c- The JCL for AS/400 processing with TYPEQAPM requires //QAPMIOPD DD
     added. See Change 12.292

  d- These products were incompatibly changed by their vendor, and they
     require MXG 12.12 (or at least the MXG 12.xx indicated):

     MVS/ESA 5.1 (Goal Mode)     Change 12.034     MXG 12.02
     OS/400 Version 3.1.0        Change 12.292     MXG 12.12
     TCP/IP Version 3.1          Change 12.257     MXG 12.12
     RMDS Version 2.1            Change 12.264     MXG 12.12
     Omegamon for VTAM V160      Change 12.186     MXG 12.04A
     Landmark CICS Version 1.3   Change 12.151     MXG 12.12
     Landmark MVS Version 1.3    Change 12.191     MXG 12.05
     APAF 2.2                    Change 12.138     MXG 12.12
     TLMS Release 5.4            Change 12.136     MXG 12.03A
     Cache RMF Reporter 1.6      Change 12.070     MXG 12.12


 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); sample JCL is in member JCLINSTL:
     Summary:
     a. Install member MXGSAS as JCL Procedure MXGSAS in your PROCLIB.
     b. Allocate a 90-cyl PDS:  MXG.V1212.MXG.SOURCLIB, and use IEBUPDTE
        to read the MXG tape to create the 2000+ member Source Library.
     c. Allocate a 1-cyl PDS:  MXG.V1212.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 V1212.USERID.SOURCLIB.

     d. Allocate a 1-cyl SAS Data Library:  MXG.V1212.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.V1212.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 reinstalling MXG, copy your existing USERID.SOURCLIB library
        members into the MXG.V1212.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.V1212.USERID.SOURCLIB, then you must reinstall your site's
        tailoring for that IMAC, starting with the IMAC member from the
        MXG 12.12 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 12.12 in its own set of libraries. When
     parallel testing is complete and are ready to implement MXG 12.12
     in production, rename your three current MXG Production Libraries
     (MXG.MXG.SOURCLIB, MXG.USERID.SOURCLIB, and MXG.MXG.FORMATS) to
     (MXG.BACK.MXG.SOURCLIB, MXG.BACK.USERID.SOURCLIB, MXG.BACK.MXG....)
     and rename the MXG.V1212.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 "
"UNINITIALIZED", "TRUNCATED", "NEVER BEEN", "NOT FOUND", "CONVERT",
"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.

Beginning with MXG 11.11, 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 that described in the change text (which might have printed
 only the critical part of the correction that can be made by paper).

 Scan each source member named in any impacting change for any comments
 at the beginning of the member for additional documentation, since the
 documentation of new datasets, variables, validation status, and notes,
 are often found in comments in the source members.

Alphabetical list of important changes after MXG 11.11:

  Dataset/
  Member   Change    Description

  Many     12.034  Support for MVS/ESA 5.1.
  Many     12.030  All instances of MSEC8. were removed from MXG.
  ACHAP99  12.161  "Chapter 99 CodeSharks" honored.
  ANALBLSR 12.001  Batch LSR analysis fails due to errors in ANALDSET.
  ANALBLSR 12.080  Batch LSR analysis enhanced.
  ANALBLSR 12.185  No BLSR candidates detected when there were some.
  ANALCISH 12.035  CICS Shutdown report corrected, design revised.
  ANALCISH 12.163  PDB=PDB,TYPE=ALL,SUMMARY=YES produced no reports.
  ANALCISH 12.235  Additional DFHSTUP-like CICS Shutdown reports.
  ANALCNCR 12.272  Analysis of concurrency - generalized new tool.
  ANALDB2C 12.087  Analysis to match CICSTRAN with DB2ACCT.
  ANALDB2R 12.078  Using ANALDB2R with PDB= tape was inefficient.
  ANALDB2R 12.236  DB2 report PMSQL01 may fail - QWHCTOKN left out.
  ANALDB2R 12.250  DB2 Locking Contention Report fails.
  ANALDB2R 12.251  DB2 Transit Report fails with NOT SORTED.
  ANALDB2R 12.270  PMLOK02 and PMLOK03 now revised.

  ANALDB2R 12.305  Support for DB2 Version 3.1 DB2PM-like reports.
  ANALDSET 12.001  Syntax error (wrong member migrated).
  ANALMTP  12.303  Analysis of Tape Mounts Concurrently Waiting.
  ANALPATH 12.239  Revised analysis of TYPE73, TYPE74, TYPE78CF data.
  ANALPGNS 12.293  CPU Utilization by Performance Group analysis.
  ANALRMFR 12.047  RMF CPU Activity Report CPU time can be zero.
  ANALRMFR 12.276  Report selection by storage class, device, LCU.
  ANALSMF  12.012  SMF Simulator 3380 tracks count wrong if CISIZE=26624
  ASMIMSLG 12.129  ABEND 002 on IMSMPRS with FASTPATH records corrected.
  ASMTAPES 12.024  MXG Tape Allocation and Mount Monitor almost healed.
  ASMTAPES 12.058  New Tape Allocation and Mount Monitor now works!
  ASMTAPES 12.105  MXG Tape Mount and Tape Allocation Monitor Now Works!
  ASMTAPES 12.234  MXG Tape Mount and Tape Allocation Monitor fixes.
  ANALINIT 12.274  Analysis of initiator concurrent usage.
  ASUMPRTR 12.040  KEEPIN=STDUPLEX TMBUPLEX needed to be added
  ASUMTALO 12.273  Revised summarization using %ANALCNCR (incompat).
  ASUM70PR 12.048  INVALID NUMERIC DATA 'SAT' with modified IMACRMFI.
  BUILDPDB 12.013  TYPE77 addition to BUILDPDB/BUILDPD3 causes errors.
  BUILDPDB 12.026  Jobs with ABEND='JCL' are not in PDB.JOBS.
  BUILDPDB 12.200  New dataset PDB.TYPE72SC for Goal Mode Server data.
  BUILDPDB 12.204  TYPETASK added for jobs with only type 6 record.
  DAILYDSN 12.004  Variable UMLEVEL must be added to KEEPIN= list.
  DB2ACCT  12.033  DB2 3.1 Buffer Statistics are wrong.
  DB2STATS 12.033  DB2 3.1 Buffer Statistics are wrong.
  DIFFDB2  12.133  DDF variables QLSTxxxx incorrectly deaccumulated.
  FMXGSID  12.015  Function ABENDs 0C4 with SAS 6.08 at TS407.
  FMXGUCBL 12.015  Function ABENDs 0C4 with SAS 6.08 at TS407.
  INSTALL  12.101  Documentation of common MXG installation errors.
  REXXDB2  12.306  REXX program to convert DB2 GTF to SMF format.
  TESTOTHR 12.153  ABEND 213-04 if VIO used for temporary allocation.
  TRNDRMFI 12.046  Variables TSOnSWAP and TSOnTRAN were not normalized.
  TYPEACC  12.277  Support for ACC/SRS from Mitchem Technologies.
  TYPEACF2 12.063  INVALID data for LIDCDATE/LIDDXPDT/LIDIPDAT/LIDADATE.
  TYPEACF2 12.072  INPUT STATEMENT EXCEEDED for subtype 'V' record.
  TYPEACF2 12.253  ACF2 INPUT STATEMENT EXCEEDED, DO value wrong
  TYPEACHE 12.262  CACHE90 zero observations with RAMAC devices.
  TYPEAPAF 12.138  Support for APAF 2.0 (incompatible).
  TYPEAPAF 12.197  INPUT STATEMENT EXCEEDED ... with backlevel APAF.
  TYPEBETA 12.132  Support for BETA93 1.6.0 user SMF record.
  TYPEBGSI 12.268  Support for BGS's BEST/1 I/O Monitor SMF record.
  TYPECACH 12.194  3990-6 storage variables units were changed by IBM.
  TYPECIAO 12.299  Support for CICSAO user SMF for CICS availability.
  TYPECIAO 12.299  Support for CICSAO SMF record written by CICSAC.
  TYPECIMS 12.265  IMF variables ABENDSYS/ABENDUSR in CIMSPROG wrong.
  TYPECIMS 12.284  Support for IMF 3.1 (for IMS 5.1) - record unchanged.
  TYPECMFV 12.269  Support for Boole & Babbage CMF VSAM MRR records.
  TYPECTLD 12.011  INPUT STATEMENT EXCEEDED for CONTROL-D SMF record.
  TYPEDB2  12.157  Dataset PDB.DB2ACCTB should have zero observations.
  TYPEDB2  12.159  DB2STATS variables QB3Taaaa/QB4Taaaa corrected.
  TYPEDB2  12.220  Invalid DB2 type 101 workaround (fix is APAR PN63234)
  TYPEDCOL 12.051  Variable DCNDMBLK needs to be multiplied by 1024.
  TYPEDCOL 12.057  Support for DFSMS 1.2 added several variables.
  TYPEDMON 12.120  Support for ASTEX 2.0 added several variables.
  TYPEEDGB 12.242  Support for DFSMSrmm Control Backup file
  TYPEEDGR 12.242  INPUT STATEMENT EXCEEDED corrected.
  TYPEHIPR 12.104  Support for EMPACT's HIPER-CACHE Version 1.1.1.
  TYPEHSM  12.206  Support for HSM APAR OW05988, adds CPU time to FSR!
  TYPEIAM  12.226  Support for Innovation Processing's IAM SMF record.
  TYPEICE  12.031  ICEBERG dataset ICEBRGCH is trashed, misalignment.
  TYPEICE  12.160  Support for STK ICEBERG SMF record subtype 5.
  TYPEICE  12.228  ICEBERG variables CAENBCUR,DFWENCUR incorrect.
  TYPEICE  12.243  Support for ICEBERG's PUT9404 (compatible).
  TYPEIDMS 12.212  Support for CA/SQL user SMF record (same as IDMS).

  TYPEIMSA 12.009  IMS Log processing incorrect, misspelled NMSGPROC.
  TYPEIMSA 12.179  SAP Accounting under IMS times wrong.
  TYPEITRF 12.287  Candle's ITRF product errors corrected by Candle.
  TYPELMS  12.007  WARNING LMS SMF RECORD TYPE created in error.
  TYPEMEMO 12.056  Support for MEMO subtype 6 SMF record.
  TYPEMON8 12.291  INVALID OFFSETS IN USER SEGMENTS Landmark CICS.
  TYPENDM  12.014  INPUT STATEMENT EXCEEDED for NDM type FP record.
  TYPENDML 12.146  Reading NDM VSAM log produced zero observations.
  TYPENSPY 12.010  LANSPY dataset NSPYLANS has no/too few observations.
  TYPENSPY 12.184  NETSPY Token-Ring TIC_UTIL in NSPYTR 10 times larger.
  TYPENSPY 12.196  Variables AOUTSZT and ARSPNET now match reports.
  TYPENSPY 12.225  Support for NETSPY 4.5 (partially incompatible).
  TYPEODS  12.198  Support for InfoAccess Release 5.1 user SMF record.
  TYPEOMCI 12.027  OMEGAMON for CICS dataset OMCISYST wrong.
  TYPEOMCI 12.164  Zero observations in OMCIVSAM dataset.
  TYPEOMCI 12.167  INVALID DATA FOR EXMXT1 - EXMXT10 when hex zeroes.
  TYPEOMCI 12.203  Support for Omegamon for CICS V100 and V300 SMF.
  TYPEOMSM 12.123  Support for Omegamon II for SMS V100/V110.
  TYPEOMVT 12.186  Support for Omegamon for VTAM V160 (Incompatible).
  TYPEOPC  12.002  INVALID MT0TYPE, OPC29 too few obs, split support.
  TYPEQAPM 12.292  Support for OS/400 AS/400 Version 3.1.0 INCOMPATIBLE.
  TYPEQTRT 12.037  Support for AS/400 Trace File (QTRTSUM).
  TYPERDS  12.295  Support for Network Systems DXE Channels RDS SMF.
  TYPERMDS 12.264  Support for RMDS Version 2.1 (incompatible)
  TYPERMFV 12.259  RMF Monitor III ("ZRB") support for MVS/ESA 4.3.
  TYPESARS 12.299  Support for LEGENT's SAR Cross Memory Logoff SMF.
  TYPETCP  12.041  Ambiguity between TELNET and FTP resolved.
  TYPETCP  12.049  TCP/IP APAR PN34837 added 8 bytes to TELNET SERVER.
  TYPETCP  12.257  Support for TCP/IP Version 3.1 (incompatible)
  TYPETELE 12.229  Support for CA's TELEVIEW user SMF record.
  TYPETLMS 12.136  Support for TLMS Release 5.4.
  TYPETMDB 12.162  Support for Landmark's The Monitor for DB2.
  TYPETMON 12.151  Support for TMON/CICS Version 1.3 (incompatible).
  TYPETMVS 12.191  Support for TMON/MVS Release 1.3 (incompatible).
  TYPETPX  12.008  UNRECOGNIZED TPX VERSION message.
  TYPETPX  12.263  Support for TPX 4.0 (compatible, new datasets)
  TYPETSOM 12.165  Support for LEGENT's TSO/MON 6.1 added (compatibly).
  TYPEUNIK 12.112  Support for UniKix Release 4.1.
  TYPEVMXA 12.069  UNEXPECTED/INVALID CONTROL RECORD/PROBABLE DATA LOSS.
  TYPEVMXA 12.226  VM/ESA 2.2 Scheduler records cause PROBABLE LOSS.
  TYPEWSF  12.096  Support for RSD's WSF Release 3.5.1.
  TYPEXAM  12.282  Support for Velocity Software XAMAP Version 2.2.
  TYPEXPSM 12.267  Support for Xerox Print Service Manager XPSM SMF.
  TYPE102  12.032  IFCID=196 (Lock Timeout Details) now populated.
  TYPE102  12.088  Additional DB2 Trace IFCIDS new in 3.1 now supported.
  TYPE102  12.103  DB2 Trace IFCID=141 corrected.
  TYPE102  12.135  IFCID 125 created extraneous observations.
  TYPE110  12.023  CICS Statistics in CICLSRR wrong.
  TYPE110  12.068  Boole & Babbage subtype 'BB02'x changed to '0B02'x.
  TYPE110  12.166  Support for CICS/ESA 4.1.0 is added (compatibly).
  TYPE110  12.189  CICS 3.2.1 only. CICDS variables wrong.
  TYPE110  12.278  ERROR.TYPE110.SUBTYPE 2, STID=57, CICS 3.3.0.
  TYPE115  12.208  Support for MQM 1.1.2 Performance Statistics SMF.
  TYPE116  12.209  Support for MQM 1.1.2 Accounting SMF record.
  TYPE123  12.215  Support for S/390 Parallel Query Server SPQS SMF 123.
  TYPE1415 12.036  APAR OW00484 adds open date to type 14,15 SMF record.
  TYPE1415 12.158  APARs OW00484/UW06888/OW08246 corrupt TYPE1415 data.
  TYPE1415 12.245  INVALID DATA FOR OPENDTE corrected.
  TYPE26J2 12.015  IBM truncates type 26 record, caused STOPOVER.
  TYPE28   12.097  NPM Release 2.0 subtypes 214 thru 219 corrected.
  TYPE28   12.145  Support for NPM Release 2.2 added NetWare measures.
  TYPE28   12.188  MXG 12.04 only. Type 28 INPUT STATEMENT EXCEEDED.
  TYPE28   12.201  Support for NPM 2.2 NPMVSaaa datasets corrected.

  TYPE30   12.018  TYPE30_V INTBTIME/INTETIME are GMT in MULTIDD='Y'.
  TYPE37   12.154  Short LAND segment caused INPUT STATEMENT EXCEEDED.
  TYPE39   12.210  Support for Sterling Software's ASM V3.0.0 type 39.
  TYPE42   12.019  INVALID ADSM SECTION TRIPLET and/or bad data values.
  TYPE42   12.045  DFSMS GG66-3252 pub are now variables in TYPE42DS/SR
  TYPE42   12.180  TYPE42 STARTIME/ENDTIME may be on GMT clock.
  TYPE50   12.102  Support for VTAM Tuning APAR OW04453 type 50 SMF.
  TYPE6    12.016  CA-DISPATCH 5.1 PTF T97E056 corrects bad READTIME.
  TYPE6    12.059  Type 6 records from VPS now have SUBSYS='VPS '.
  TYPE6    12.199  INVALID ARGUMENT TO FUNCTION INPUT with CA-DISPATCH.
  TYPE62   12.122  Support for APAR OW00157 adds SMS classes to TYPE62.
  TYPE70   12.288  Support for PR/SM APAR OW078986 adds "MVS Wait".
  TYPE70   12.289  MDF now populates TYPE70PR/ASUM70PR w/valid CPU time
  TYPE70   12.290  Same LPAR number for two LPARs trashes CPU busy.
  TYPE70s  12.006  SYNCTIME wrong in RMF 71,73,74,75,77,78 and 79.
  TYPE72DL 12.252  New TYPE72DL dataset for MVS/ESA 5.1 Goal Mode.
  TYPE80A  12.280  RACF Command events decoded in TYPE80A for RACFRW.
  TYPE89   12.028  Support for Measured Usage License Charges type 89.
  TYPE91   12.038  BatchPipes/MVS APAR PN45846 adds new fields.
  TYPE91   12.254  BatchPipes/MVS INTBTIME/INTETIME values incorrect.
  TYPE99   12.117  Support for ESA 5.1 Workload Manager Trace SMF 99.
  TYPE99   12.285  Support for Type 99 Subtype 1 added.
  UCICSCNT 12.021  Utility report output counts were unclear.
  UTILCICS 12.182  UTILCICS fails with syntax error, mislocated comment.
  UTILCICS 12.202  CICS Utility identifies if type 110s are Omegamon's.
  UTILCVRT 12.022  Non-existent conversion utility now exists.
  VAXPDS   12.301  Support for VAX Accounting and Performance Data.
  VMXGSUM  12.084  New features added transparently to VMXGSUM.
  VMXGSUM  12.233  New VMXGSUM enhancements in XMXGSUM.
  VMXGSUM  12.271  More VMXGSUM enhancements in XMXGSUM.
  VMXGVTOF 12.249  DEVCYL value different for RAMAC than native devices.
  WEEKBLDT 12.195  DATASET TAPEMNTS NOT SORTED.
  XMXGSUM  12.304  XMXGSUM replacement for VMXGSUM ready for use.

Inverse chronological list of all Changes:


===Changes thru 12.306 were included in MXG 12.12 dated Mar  1, 1995===
===Changes thru 12.306 were printed in MXG Newsletter TWENTY-SEVEN  ===

****************NEWSLETTER TWENTY-SIX***********************************










              MXG NEWSLETTER NUMBER TWENTY-SIX August 4, 1994

Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE

                         TABLE OF CONTENTS                          Page

0.    MXG Software is now ten years old!                              2
I.    MXG Software Version 12.03, dated Aug 4, 1994, available.       3
II.   MXG Technical Notes                                             4
III.  MVS Technical Notes                                             5
 1.   IBM Cache RMF Reporter Version (CRR 1.6) does exist.            5
 2.   APAR OW00884 improves SMF performance requires no MXG change.   5
 3.   TYPE71 variable NBLKPAGE may be negative....                    5
 4.   TCP/IP APAR PN48492 corrects zero start/stop times ....         5
 5.   DFSMS/MVS APAR OW05308 corrects track count in TYPE42 st 4.     5
 6.   High MVS Uncaptured CPU time due to RMF and DEFRAG.             6
 7.   How can you identify who issued RESERVEs?                       6
 8.   How can you transfer SMF data from MVS to MVS using TCP/IP?     7
IV.   VM Technical Notes                                              7
V.    CICS Technical Notes                                            7
VI.   SAS Technical Notes                                             7
 1.   ASCII Versions lose AUTOCALL libraries with AUTOEXEC.SAS        7
 2.   HSM recall multi-volume SAS libraries cause USER ABEND 318.     7
 3.   Third technique for creating multi-volume SAS data libraries.   8
 4.   SMS Tape Mount Management USER ABEND 315 circumvention          8
 5.   SASHELP.VTABLE contains description of all LIBREF contents      8
 6.   USER ABEND 2096 occurs with SMS managed SAS data library.       8
 7.   TS410 Alert Note on Base SAS Software warning is incorrect.     8
 8.   Broken VBS records (Usage Note 6810) is repaired in TS410.      8
 9.   Using columns 1-80 in source code produced no report.           8
VII.  IMS Technical Notes                                             9
 1.   MXG's ASMIMSLG does process IMS 4.1 log data                    9
 2.   MXG's recommendation for Candle's ITRF Product placed on hold.  9
VIII. Incompatibilities and Installation of MXG 12.03.                9
 1.   Members IMAC7072 IMAC74 IMACDB2 IMACPDB IMACWORK changed.       9
 2.   Installation instructions.                                     10
IX.   Online Documentation of MXG Software.                          11
X.    Changes Log                                                    12
      Alphabetical list of important changes                         13
      Changes 12.128 thru 12.001                                  14-39










         COPYRIGHT (C) 1994 BY MERRILL CONSULTANTS DALLAS TEXAS



                MXG Software is now TEN Years Old!!!!!


I first wrote SAS code to read SMF data in 1972; in 1974 SAS Institute
added file 13, SAS.MERRILL to their distribution tape with my sample SMF
programs, and in 1980 SAS Institute published my "Merrill's Guide to
Computer Performance Evaluation" (a blue book plus tape for $395!).


But it was in August, 1984, that the "Merrill's Expanded Guide to CPE"
(the red book) and our fully supported MXG Software (Version 1 had 289
members with 22,000 lines!) was first shipped to the 99 sites that had
participated in our Early Shipment program.  Now, ten years later, we
have shipped MXG to 4,379 sites in 59 countries (and Version 12.03 has
2,340 members with 675,182 lines!).


While Judy and I really are the company (we have no employees), we do
have three regular consultants who have ably tested each new release,
who have covered my technical calls while I am out of the office
teaching, and who have personally contributed significantly to MXG, and
to whom we are eternally grateful:

      Chuck Hopf          Bruce Widlund         Freddie Arie

Overseas, where we are represented by your local SAS Office, we are also
grateful to the scores of dedicated SAS technicians who have provided
you with local language and local time of day help with MXG queries.



But our real thanks for our success in these past ten years is to you,
our 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, 488 pages in 26 Newsletters, and
2,217 Changes in 73 Releases to learn how to use MXG Software to measure
and thereby improve the performance of your company's computer systems -

            your diligence has made us all look good!!!



And I must personally thank Judy for putting up with ten years of me in
our office, listening to the constant drone of my (not exactly quiet)
voice, repeating the same answers to the same questions.

Not only is she my partner in Merrill Consultants and in life and my
best friend, but she also gave up her whole life (she was an executive
in the apparel industry) to set up and run the Administrative side of
our company so that I could write code and answer questions.

MXG would not have existed without her.
















I. MXG Software PreRelease Version 12.03, dated Aug 4, 1994, contains
   these major enhancements:

   Major enhancements added in MXG 12.03 dated Aug 4, 1994:

  Support for MVS/ESA 5.1 Type 99 Subtype 2 record.
  Support for LEGENT's ASTEX Release 2.0.
  Support for UniKix Release 4.1 Binary File
  Support for EMPACT's HIPER-CACHE Version 1.1.1.
  Support for SMF Type 50 VTAM Tuning APAR OW04453.
  Support for RSD's WSF Release 3.5.1.
  Support for Omegamon II for SMS V100/V110.
  Support for BETA93 user SMF record.
  MXG Tape Mount and Tape Allocation Monitor final errors corrected!
  Correction for NPM Release 2.0 subtypes 214 thru 219.
  Additional DB2 3.1 Trace IFCIDs supported.
  Analysis ANALDB2C matches CICSTRAN observations with DB2ACCT.

   Major enhancements added in MXG 12.02 dated Jul 4, 1994:

  MXG Tape Mount and Allocation Monitor was revised, new reports.
  Support for IBM's CRR 1.6 (3990-3 and 3990-6) (incompatible).
  Support for DFSMS 1.2 changes to DCOLLECT (compatible).
  Support for MEMO subtype 6 record.
  Support for TCP/IP APAR PN34837 new field (compatible).
  Support for MVS APAR OW00884/UW06821 - no impact, see MVS Notes.
  Support for IMS 4.1 Log Records (see IMS Technical Notes)

   Major enhancements added in MXG 12.01 dated Jun 15, 1994:

  Support for MVS/ESA 5.1 many new datasets (compatible).
  Support for Measured Usage SMF Record 89 and changes to type 30.
  DB2 Version 3.1 Buffer Pool statistics were incorrect in MXG 11.11.
  OPC Version 1.2.0 had INPUT STATEMENT EXCEEDED error with MXG 11.11,
    but change 12.002 corrects, plus adds support for split records!
  Problem with Cache RMF Reporter Records discussed in Newsletter 25
    are actually fixed by MVS APAR OW01787.
  ANALDSET/ANALBLSR routines were corrected in Change 12.001.


  These Versions of MXG have been available as indicated:

     MXG Version 12.03  was dated Aug  4, 1994, thru Change 12.128
     MXG Version 12.02  was dated Aug  6, 1994, thru Change 12.084
     MXG Version 12.01A was dated Jun 15, 1994, thru Change 12.056
     MXG Version 12.01  was dated Jun  1, 1994, thru Change 12.047
     MXG Version 11.11  was dated Mar 26, 1994, thru Change 11.361
     MXG Newsletter TWENTY-FIVE,  Mar 26, 1994, thru Change 11.347

=======================================================================

  OPEN ITEMs still in progress/planning when Newsletter was printed:

=======================================================================

  TLMS Release 5.4 - In progress - request specifically and we will send
                     12.03 plus support for TLMS.

  APAF New Release - In progress - request specifically and we will send
                     12.03 plus support for APAF.

  Huron   -  Huron SMF record is not supported yet; no sample data SMF
             data was provided, and the printed DSECTs were massive and
             needed in machine readable form.  Awaiting data/documents.

  ANALRACF - Problem with PROC TRANSPOSE changes still unresolved (but
             dataset TYPE80A, built by member TYPE80A has provided the
             desired information in much better format for most sites).

  TYPEZRB -  RMF III VSAM file for MVS/ESA 4.2 and 4.3 is not correct;
             this is complicated code and only two sites have expressed
             interest, so it is still low on my priority list.

  EPIC    -  LEGENT has not provided the format of their tape catalog;
             instead, they want you to use the output of their extract
             program, which means double processing and klugy coding.
             Nothing planned until LEGENT supplies needed formats.

======================================================================

    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                    Jun 24  1994        12.03
      CICS/ESA 3.2                     Jun 28, 1991.        9.9
      CICS/ESA 3.3                     Mar 28, 1992.       10.01
      CICS/ESA 4.1                     ??? ??, 1994.       ??.??
      CRR 1.6                          Jun 24, 1994.       12.02
      DB2 2.2.0                                1990         8.8
      DB2 2.3.0                        Oct 28, 1991.       10.01
      DB2 3.1.0                        Dec 17, 1993.       12.03
      DFSMS/MVS 1.1                    Mar 13, 1993.       11.11
      DFSMS/MVS 1.2                    Jun 24, 1994.       12.02
      NPM 2.0                          Dec 17, 1993.       12.03
      VM/ESA  1.1.1                    Dec 27, 1991.       10.1
      VM/ESA  2.0                      Dec 23, 1992.       10.4
      VM/ESA  2.1                      Jun 27, 1993.       11.02

======================================================================

II. MXG Technical Notes

III. MVS Technical Notes

 1.  IBM Cache RMF Reporter Version 1.5 never existed, even though my
     manual SH20-6295-5 shows 'Version 1.5'!   What was to be CRR 1.5
     was only CRR 1.4 with instructions of how to install CRR as a
     started task (instead of as a subtask of RMF)!  IBM found that a
     timing problem between RMF and CRR sometimes was corrected if CRR
     ran as a started task, but there did not correct all errors.  IBM
     MVS APAR OW01787 (to the LISTDATA STATUS command that CRR issues)
     did definitely correct records with CSSSID=0018x at some sites, but
     still there were errors at other sites with that APAR installed.
     Now, it does appear the answer is CRR 1.6 (which really does exist)
     and which appears to have corrected all errors with CRR data.  The
     new release records were incompatibly changes, but are supported in
     MXG 12.02, with several useful new fields to justify the install!

 2.  APAR OW00884 (PTF UW06821 or UW06822) ) solves a performance
     problem (long hold of local lock, resulting in domination of the
     CPU while creating SMF interval and termination records, due to SMF
     copying each DD segment one-at-a-time) by a redesign that now
     copies multiple DD segments at a time, but a side effect of the
     redesign changes how some type 30 records are written.  The change
     affects only the records for tasks that have many DD segments - so
     many that they will not fit in one type 30 record.  When this
     happened in the past, the first record contained all of the other
     resource fields, and then as many DDs as would fit filled out that
     first record, and additional records were written with the
     remaining DD segments (MXG flags these additional records as
     MULTIDD='Y').  Now, when there are many DD segments, there may be a
     first record written with no DD segments, and then all of the DD
     segments are written in one or more MULTIDD='Y' records (in some
     cases, this will cause one extra MULTIDD='Y' record than was
     written before).

     So, what is the real impact of this APAR on MXG?  Very little, for
     most sites, and NO impact on any MXG code.  These MULTIDD records
     are almost always written by long running started tasks; examples
     include SYSOUT handlers (SAR, RMDS, which dynamically allocate one
     DD for each file processed), JES (which dynamically allocates each
     reference to a user PROCLIB), and DB2 (whose media manager may
     dynamically allocate each access to a DB2 database), and most of
     the time that dynamic DD segment contains only the DDNAME, often
     with no EXCP count!  The only exposure for MULTIDD records is
     unchanged; it is possible that MXG will miscount the number of tape
     drives allocated, TAPEDRVS, depending on which of the multiple
     records contained the DD segment for tape devices!

 3.  TYPE71 variable NBLKPAGE, the non-blocked pages paged in, can be
     negative or zero, at small paging rates.  IBM discusses why in
     APAR II06687 (although it mentions a zero value, because the RMF
     report forces negative values to print as zero!).

 4.  TCP/IP APAR PN48492 fixes zero start/stop times in TCP SMF record.

 5.  DFSMS APAR OW05308 corrects track counts in TYPE42 subtype 4.


 6.  MVS Uncaptured CPU Time (misnamed "Overhead", CPUOVHTM/PCTOVHD in
     MXG dataset RMFINTRV & calculated by subtracting TYPE72 CPUTM for
     all control performance groups from TYPE70 CPUACTTM) can be very
     large, and the duration of the RMF interval, DURATM, can be much
     longer than the expected interval, if RMF cannot gather DASD data.
     A site with a 3-way ES9000 Model 831 normally writes 15 minute RMF
     interval records, with CPUOVHTM of 2 minutes 7 seconds.  However,
     a DF/DSS "DEFRAG" running in System B blocked System A from reading
     the DASD data until the DEFRAG job ended; the actual RMF interval
     was 26 minutes (an 11 minute elongation)  The total CPUOVHTM
     recorded jumped to 19 minutes, or an extra 17 CPU minutes!  Thus
     during the 11 minutes when RMF could not get its data, it used 17
     extra minutes of CPU time, or nearly 100% of two of the three
     engines!  This problem occurred frequently, essentially every time
     that DEFRAG ran, and a plot of CPUOVHTM versus DURATM shows clearly
     that the uncaptured CPU time linearly increased as RMF was blocked.
       (In addition, SYSLOG showed an IOS Start Pending every 16 seconds
        during these time when RMF was blocked, suggesting that RMF was
        looping on its internal hardware instruction trying to get the
        access for 16 seconds, and then gave up only to retry again!)

     So what's the real solution?  First, I have asked IBM why RMF sucks
     up so much CPU time during these intervals.  Second, I investigated
     DEFRAG and found that the real culprit was the DEFRAG option
     MAXmove(9999) at the site.  DEFRAG RESERVEs the VOLSER it is
     defragmenting; specifying MAX(9999) causes DEFRAG to attempt to
     assemble up to 9999 free tracks in a contiguous area in a single
     pass.  Instead, if the sites specifies MAX(9999,10), DEFRAG will
     still assemble the 9999 free tracks, but now it will do it in ten
     passes, assembling only 9999/10=1000 tracks per pass, and then will
     un-RESERVE for 1 second to let other systems access the volume,
     before starting the next pass.  If getting 1000 tracks takes on the
     order of 3 minutes, then MAX(9999) would have DEFRAG RESERVE the
     volume for 30 elapsed minutes, but using MAX(9999,10) should then
     let the other systems access the volume every 3 minutes or so.

     Note, however, that changing from MAX(9999) to MAX(9999,10) on a
     test volume that normally took only 3 minutes increased the run
     time of the DEFRAG job to 27 minutes of elapsed time, so there may
     be other tradeoffs - more experimentation is planned and this note
     will be revised as more is learned.

     Storage Management Experts Dr. Rick Olcott, Mark Friedman and Dan
     Kaberon all argue (SHARE, CMG) that if you have size-based storage
     pools (eg., one for small data sets, one for the large data sets),
     that DEFRAGing should never be needed!

 7.   How can you identify which jobs are issuing RESERVEs?  After the
      fact, it can't normally be done, because no SMF record is written
      when a volume is RESERVEd by a job.  However, if you know in
      advance that you need to track RESERVEs, you can enable RMF
      Monitor II SENQR (System Enque Reserve Report) which will create
      type 79 subtype 6 records to snapshot all RESERVEs outstanding at
      the time RMF processes the request for the report (but that will
      not necessarily track ALL reserves that were issued.  Also, if RMF
      Monitor III is enabled in advance, and if the data still exists in
      its wrap around file, you may be able to use its ENQ/ENQR display,
      if there were RESERVE conflicts.  You can examine RESERVEs that
      are outstanding right now by using the DISPLAY GRS console command
      (MVS/ESA 4.3 or later).  D GRS,E,C gives you contention statistics
      for both RESERVEs and ENQs, and D GRS,DEV=uuuu will show which
      jobs have RESERVE requests for that specific device from this
      system at this instant.

 8.   Sending SMF VBS data from one MVS site to another using TCP/IP is
      not straightforward, but Debbie Blackey at Columbia/HCA made it
      work with this JCL:
        //FTPBATCH EXEC PGM=FTP
        //              PARM='SSS.S.SSS.SS (EXIT=8' /*ID OF RECEIVE SYS
        //SYSPRINT DD SYSOUT=*
        //OUTPUT   DD SYSOUT=*
        //INPUT    DD DSN=DDDDD.DDDDD.DDDDD  /*GENERIC TCP LOGID AND PW
        //         DD *
        EBCDIC
        MODE B
        SITE CY LRECL=32760 BLKSIZE=32760 LRECL=VBS PRI=100 SEC=100
        PUT 'XXX.XXX.XXX' 'YYY.YYY.YYY'
        QUIT
        /*

IV. VM Technical Notes

V. CICS Technical Notes

  1. Don't overlook the new ANALDB2C program that merges DB2ACCT and
     CICSTRAN observations to produce a single observation for each
     unit-of-work from its multiple CICS transactions and multiple DB2
     transactions into the ANALDB2C dataset.  That logic can also be
     used to create just the CICSONE dataset to produce a single
     observation from a series of CICS MRO events.

  2. Landmark's The Monitor for CICS Release 8.2 variable TIDYNHWM is
     incorrect; Landmark's PTF to correct is U805990.

VI. SAS Technical Notes

 1. MXG's AUTOEXEC.SAS file specifies MAUTOSOURCE and SASAUTOS=SOURCLIB,
    so that MXG's %MACRO references are resolved, but under the ASCII
    versions of SAS, the SAS-supplied AUTOCALL libraries are removed
    from the search list, so you will not be able to find any of the SAS
    provided %MACROs with MXG's AUTOEXEC.SAS.  MXG itself does not use
    any of the SAS-supplied %MACROs, but if you do, you will need to add
    the AUTOCALL directory entries from your CONFIG.SAS into the
    FILENAME SOURCLIB concatenation in AUTOEXEC.SAS. (SAS Institute is
    looking for a more transparent solution.)


 2. HSM migration and recall of multi-volume SAS data libraries may or
    may not work with SAS Version 6, because HSM recall does not put the
    library back as it was built, and SAS is dependent on the physical
    location.  A PDB library spanned two volumes, was migrated, and HSM
    recall was able to fit the data on one volume, but SAS failed with
    USER ABEND 318 when the recalled library was accessed!  There is no
    fix possible in SAS Version 6, but the design is under investigation
    for possible correction in SAS Version 7 in the future.  If you can
    not prevent HSM migration, you must use PROC COPY to backup the data
    library to tape, so that you can restore from the tape copy if HSM
    migration corrupts the multi-volume data library.

 3. SAS now provides a third technique for creating multi-volume data
    libraries.  In addition to the example in the SAS Companion for MVS,
    or using SMS Guaranteed Space, SAS distribution library BAMISC now
    contains an assembly program SASMULTF.  (Before you assemble that
    program, change the default blocksize from 6144 to half-track).
    Once assembled, you can then
       // EXEC PGM=SASMULTF,PARM='PDB'
       //STEPLIB DD DSN=load library into which you linked SASMULTF
       //PDB     DD DSN=MXG.PDB,UNIT=(SYSDA,4),SPACE=(CYL,(100,100)),
       //           DISP=(,CATLG)
       // EXEC MXGSASV9
       //PDB DD DSN=MXG.PDB,DISP=OLD
        ... rest of JCL and program
    This program will allocate 16 extents on the first volume (if there
    is enough room on the volume), and then on the second and subsequent
    volumes, will allocate 16 extents (using the secondary allocation
    size) if there is sufficient space on each volume, up to the number
    of volumes specified in the UNIT= parameter.  Unfortunately, there
    is no way to know in advance how much space will be allocated on
    each volume.  If you attempt to allocate a multi-volume SAS data
    library with conventional JCL (i.e., if you do not use one of these
    three supported techniques), you may fail with a USER ABEND 318.

 4. The note in MXG Newsletter TWENTY-FIVE on ABEND 315 with SMS Tape
    Mount Management will apparently not be fixed until Version 7 of
    SAS, but in addition to the circumvention of adding a SPACE
    parameter, you can instead tell SMS to bypass Tape Mount Management
    if the program name is "SAS".

 5. I was unaware of the dataset SASHELP.VTABLE until Mike Welch showed
    it to me; for all LIBREFs that exist in a SAS session, that dataset
    contains a description of all datasets in that LIBREF.  Try:
        LIBREF PDB 'MXG.PDB' DISP=SHR;
        DATA PDBCONT;  SET SASHELP.VTABLE;  IF LIBNAME='PDB';
        BYTES=NOBS*OBSLEN;
        PROC SORT; BY DESCENDING BYTES;
        PROC PRINT; VAR LIBNAME MEMNAME BYTES NOBS OBSLEN COMPRESS;
    The VTABLE dataset is also available in SQL:
        PROC SQL;  SELECT * FROM DICTIONARY.TABLES;

 6. USER ABEND 2096 is SMS related; putting PDB, SPIN, etc., libraries
    on non-SMS volumes has circumvented that ABEND.

 7. SAS MVS Maintenance TS410 is accompanied by a printed Alert Note on
    BASE SAS Software that is incorrect.  The note says that an error
    ('when the sum of the lengths of the constants...') has no fix, but
    in actuality, that bug was introduced in TS405 and TS407 and was
    then fixed by zap Z6088203, AND the error was corrected in source in
    TS410.  (Note: If you are still at TS407 you MUST install Z6088203).

 8. SAS Usage Note 6810 (broken VBS record put SAS in WAIT/CPU LOOP)
    noted on page 22 of NEWSLETTER 25 was fixed in TS410 maintenance.

 9.  One user's report program ran under MXG 10.10 but produced no error
     message nor any output under MXG 11.11.  The program used columns 1
     thru 80, and had a comment in line 1.  MXG changed the S2= option
     from S2=0 in MXG 10.10 to S2=72 in MXG 11.11, which caused the
     end of the comment to be truncated, and thus SAS saw no program!
     Because of other error conditions related to source line length,
     all MXG programs use only columns 1 thru 72, and thus I recommend
     that you never use columns 73-80 in your programs.  However, you
     could override the CONFIG option and specify OPTIONS='S2=0' on the
     // EXEC statement if you have report programs using all 80 columns.

VII. IMS Technical Notes

 1. While MXG Newsletter TWENTY-FIVE was somewhat pessimistic about MXG
    support for IMS Version 4.1, further testing has validated that the
    pessimism was unwarranted - ASMIMSLG does process IMS 4.1 log data
    correctly!  My concern was based on early tests in which some IMS
    transactions showed IMSCPUTM greater than their SERVICTM (Start to
    End execution duration), and that seemed to be a clear error.  But
    diligent analysis by Cary Jones of Philip Morris and Jeff Krum of
    Ashland Oil has proven why IMSCPUTM can be greater than SERVICTM:
    because there is only one 07 log record with total CPU time for
    multi-scheduled transactions, the IMSCPUTM that MXG can calculate
    for an individual transaction can only be the average CPU time of
    all of those transactions serviced in that program schedule, but an
    individual transaction can have its true SERVICTM significantly less
    than that average CPU value!  I was also concerned by the larger
    number of transactions with zero SERVICTM, but that was valid; any
    transaction with service time less than 100 milliseconds will be
    recorded as zero because the IMS log clock resolution is 0.1 seconds
    and what we really saw was an improvement in IMS response time with
    IMS 4.1 (it does exploit MVS/ESA), especially for these transactions
    that did no I/O!  Thus I can now officially reinforce the claim that
    MXG 11.11 (with the one line correction in Change 12.009), does
    process IMS 4.1 log records as accurately as is possible!

 2. The same cannot be said for Candle's ITRF Product; I was incorrect
    in listing that product as a valid tool for IMS transaction analysis
    in MXG Newsletter TWENTY-FIVE, because it still has very serious
    errors that have not yet been corrected by Candle.  Even with the
    last 1993 maintenance available from Candle (QI21740 and QI21860),
    a significant number of transactions have blank values for Region
    Name, Logon ID, and even Transaction Name, and numerous transactions
    show input queue times in excess of a million seconds.  Problems
    have been open with Candle ITRF for some time with no resolution.


VIII. Incompatibilities and Installation of MXG 12.03.

 1. Incompatibilities introduced in MXG 12.03 (since MXG 11.11):

  a- IMACs that were changed (if they exist in your USERID.SOURCLIB, you
     must refit your changes, starting with the new IMAC member):

       IMAC7072  IMAC74  IMACDB2   IMACPDB   IMACWORK

  b- The JCL for processing the OPC log requires two new DDNAMES so that
     the OPC spanned records can be reconstructed and read by MXG.  See
     comments in member VMACOPC.  Member JCLTEST6 was changed also.


 2. Installation and re-installation procedures are described in detail:
    in member INSTALL, and sample JCL is in member JCLINSTL.  Summary:
     a. Install member MXGSAS as JCL Procedure MXGSAS in your PROCLIB.
     b. Allocate a 83-cyl PDS: MXG.V1203.MXG.SOURCLIB, and use IEBUPDTE
        to read the MXG tape to create the 2000+ member Source Library.
     c. Allocate a 1-cyl PDS:  MXG.V1203.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 V1203.USERID.SOURCLIB.
     d. Allocate a 1-cyl SAS Data Library:  MXG.V1203.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.V1203.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.V1203.USERID.SOURCLIB. Then compare your
        IMACs with those that were changed (see the INCOMPATIBLE section
        changed members, above).  If any of those members are in your
        MXG.V1203.USERID.SOURCLIB, you must reinstall your site's
        tailoring for that IMAC, starting with the IMAC member from the
        MXG 12.03 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 12.03 in its own set of libraries.  When
     parallel testing is complete and are ready to implement MXG 12.03
     in production, rename your three current MXG Production Libraries
     (MXG.MXG.SOURCLIB, MXG.USERID.SOURCLIB, and MXG.MXG.FORMATS) to
     (MXG.BACK.MXG.SOURCLIB, MXG.BACK.USERID.SOURCLIB, MXG.BACK.MXG....)
     and rename the MXG.V1203.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:" and  "ERROR :"  and
"UNINITIALIZED", "TRUNCATED", "NEVER BEEN", "NOT FOUND", "CONVERT",
"NOT CATLGD" and " NOT ", 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.

Beginning with MXG 11.11, 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 that described in the change text (which might have printed
 only the critical part of the correction that can be made by paper).

 Scan each source member named in any impacting change for any comments
 at the beginning of the member for additional documentation, since the
 documentation of new datasets, variables, validation status, and notes,
 are often found in comments in the source members.

Alphabetical list of important changes after MXG 11.11:

  Dataset/
  Member   Change    Description

  Many     12.034  Support for MVS/ESA 5.1.
  Many     12.030  All instances of MSEC8. were removed from MXG.
  ANALBLSR 12.001  Batch LSR analysis fails due to errors in ANALDSET.
  ANALBLSR 12.080  Batch LSR analysis enhanced.
  ANALCISH 12.035  CICS Shutdown report corrected, design revised.
  ANALDB2C 12.087  Analysis to match CICSTRAN with DB2ACCT.
  ANALDB2R 12.078  Using ANALDB2R with PDB= tape was inefficient.
  ANALDSET 12.001  Syntax error (wrong member migrated).
  ANALRMFR 12.047  RMF CPU Activity Report CPU time can be zero.
  ANALSMF  12.012  SMF Simulator 3380 tracks count wrong if CISIZE=26624
  ASMTAPES 12.024  MXG Tape Allocation and Mount Monitor almost healed.
  ASMTAPES 12.058  New Tape Allocation and Mount Monitor now works!
  ASMTAPES 12.105  MXG Tape Mount and Tape Allocation Monitor Now Works!
  ASUMPRTR 12.040  KEEPIN=STDUPLEX TMBUPLEX needed to be added
  ASUM70PR 12.048  INVALID NUMERIC DATA 'SAT' with modified IMACRMFI.
  BUILDPDB 12.013  TYPE77 addition to BUILDPDB/BUILDPD3 causes errors.
  BUILDPDB 12.026  Jobs with ABEND='JCL' are not in PDB.JOBS.
  DAILYDSN 12.004  Variable UMLEVEL must be added to KEEPIN= list.
  DB2ACCT  12.033  DB2 3.1 Buffer Statistics are wrong.
  DB2STATS 12.033  DB2 3.1 Buffer Statistics are wrong.
  FMXGSID  12.015  Function ABENDs 0C4 with SAS 6.08 at TS407.
  FMXGUCBL 12.015  Function ABENDs 0C4 with SAS 6.08 at TS407.
  INSTALL  12.101  Documentation of common MXG installation errors.
  TRNDRMFI 12.046  Variables TSOnSWAP and TSOnTRAN were not normalized.
  TYPEACF2 12.063  INVALID data for LIDCDATE/LIDDXPDT/LIDIPDAT/LIDADATE.
  TYPEACF2 12.072  INPUT STATEMENT EXCEEDED for subtype 'V' record.
  TYPECTLD 12.011  INPUT STATEMENT EXCEEDED for CONTROL-D SMF record.
  TYPEDCOL 12.051  Variable DCNDMBLK needs to be multiplied by 1024.
  TYPEDCOL 12.057  Support for DFSMS 1.2 added several variables.
  TYPEDMON 12.120  Support for ASTEX 2.0 added several variables.
  TYPEHIPR 12.104  Support for EMPACT's HIPER-CACHE Version 1.1.1.
  TYPEICE  12.031  ICEBERG dataset ICEBRGCH is trashed, misalignment.
  TYPEIMSA 12.009  IMS Log processing incorrect, misspelled NMSGPROC.
  TYPELMS  12.007  WARNING LMS SMF RECORD TYPE created in error.
  TYPEMEMO 12.056  Support for MEMO subtype 6 SMF record.
  TYPENDM  12.014  INPUT STATEMENT EXCEEDED for NDM type FP record.
  TYPENSPY 12.010  LANSPY dataset NSPYLANS has no/too few observations.
  TYPEOMCI 12.027  OMEGAMON for CICS dataset OMCISYST wrong.
  TYPEOMSM 12.123  Support for Omegamon II for SMS V100/V110.
  TYPEOPC  12.002  INVALID MT0TYPE, OPC29 too few obs, split support.
  TYPEQTRT 12.037  Support for AS/400 Trace File (QTRTSUM).
  TYPETCP  12.041  Ambiguity between TELNET and FTP resolved.
  TYPETCP  12.049  TCP/IP APAR PN34837 added 8 bytes to TELNET SERVER.
  TYPETPX  12.008  UNRECOGNIZED TPX VERSION message.
  TYPEUNIK 12.112  Support for UniKix Release 4.1.
  TYPEVMXA 12.069  UNEXPECTED/INVALID CONTROL RECORD/PROBABLE DATA LOSS.
  TYPEWSF  12.096  Support for RSD's WSF Release 3.5.1.
  TYPE102  12.032  IFCID=196 (Lock Timeout Details) now populated.
  TYPE102  12.088  Additional DB2 Trace IFCIDS new in 3.1 now supported.
  TYPE102  12.103  DB2 Trace IFCID=141 corrected.
  TYPE110  12.023  CICS Statistics in CICLSRR wrong.
  TYPE110  12.068  Boole & Babbaage subtype 'BB02'x changed to '0B02'x.
  TYPE1415 12.036  APAR OW00484 adds open date to type 14,15 SMF record.
  TYPE26J2 12.015  IBM truncates type 26 record, caused STOPOVER.
  TYPE28   12.097  NPM Release 2.0 subtypes 214 thru 219 corrected.

  TYPE30   12.018  TYPE30_V INTBTIME/INTETIME are GMT in MULTIDD='Y'.
  TYPE42   12.019  INVALID ADSM SECTION TRIPLET and/or bad data values.
  TYPE42   12.045  DFSMS GG66-3252 pub are now variables in TYPE42DS/SR
  TYPE50   12.102  Support for VTAM Tuning APAR OW04453 type 50 SMF.
  TYPE6    12.016  CA-DISPATCH 5.1 PTF T97E056 corrects bad READTIME.
  TYPE6    12.059  Type 6 records from VPS now have SUBSYS='VPS '.
  TYPE62   12.122  Support for APAR OW00157 adds SMS classes to TYPE62.
  TYPE70s  12.006  SYNCTIME wrong in RMF 71,73,74,75,77,78 and 79.
  TYPE89   12.028  Support for Measured Usage License Charges type 89.
  TYPE99   12.117  Support for ESA 5.1 Workload Manager Trace SMF 99.
  TYPE91   12.038  BatchPipes/MVS APAR PN45846 adds new fields.
  UCICSCNT 12.021  Utility report output counts were unclear.
  UTILCVRT 12.022  Non-existent conversion utility now exists.
  VMXGSUM  12.084  New features added transparently to VMXGSUM.
  TYPEBETA 12.125  Support for BETA93 1.6.0 user SMF record.

****************NEWSLETTER TWENTY-FIVE**********************************










              MXG NEWSLETTER NUMBER TWENTY-FIVE March 26, 1994

Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE
                         TABLE OF CONTENTS                          Page
0.  IBMs MVS Version 5 Workload Manager & Parallel Sysplex Processors  2
I.  MXG Software Production Version 11.11 enhancements                 3
II. MXG Technical Notes                                                6
 1. Executing MXG on PCs and Workstations under WINDOWS,OS2, & UNIX    6
 2. MXG Version 11.11 requires SAS Version 6, but will run with 5.18. 13
 3. Running the MONTHBLD program on a day other than the 1st day.     13
 4. "PHYSICAL FILE DOES NOT EXIST, hlq.SOURCLIB.SAS" message.         13
III. MVS Technical Notes                                              13
 1. Impact of VSAM CI Size on DASD Space and SMF Write Activity       13
 2. An increase in CPU TCB time with MVS/ESA 4.2 and LPARs            18
 3. APAR OY65101 adds a new JES2 option (NEWPAGE=1/ALL)               18
 4. APAR OY61331 corrects wrong/impossible values in type 14 records  19
 5. APAR OY65854 reports errors in RMF STARTIME (SMF7xIST).           19
 6. APAR OY65280 corrects invalid data in TYPE24.                     19
 7. APAR OY66531 corrects erratic values in TYPE74 Disc and Pend      19
 8. APAR OY67681 reports that TYPE62 variable DSNAME may be wrong     19
 9. Boole and Babbage CMF type 70 records under Amdahl's MDF          19
10. MVS/ESA allocates secondary extents differently than MVS/XA       19
11. After installing PUT 9332, invalid type 70 records are created    19
12. Type 6, 24, and 26 SMF records READTIME later than REND time      19
13. PTF UY91040 corrupts the Cache RMF Reporter data                  19
14. APAR OW01141 reports SMF/RMF records are not synchronized         19
15. IBM Washington System Center Flash 94-06, (Internal Use Only),    20
16. APAR PN52658 corrects the wait times in BatchPipes/MVS            20
17. APAR PN49692 corrects type 96 (TIRS) SMF record                   20
18. APAR OW02571 reports invalid DCOLLECT values for 3390-9           20
19. SMF Interval records are not written for swapped out tasks.       20
20. IBM Cache RMF Reporter Version 1.5 required for MVS/ESA 4.3       20
IV. VM Technical Notes                                                20
 1. Testing status of MXG under CMS                                   20
 2. SAS Version 6 libraries cannot be shared between CMS & MVS        20
V.  CICS Technical Notes                                              21
 1. Truncated type 110 Statistics records written by CICS/ESA         21
VI. SAS Technical Notes                                               21
 1. CRITICAL ZAP Z6088203 REQUIRED for MVS sites at TS405 or TS407.   21
 2. Erratic series of SAS errors (NOTSORTED, HEADER LENGTH WRONG)     21
 3. Must use PROC GREPLAY to move SAS Graphics catalogs.              21
 4. SAS 6.08 ABEND 0C4 in Function VG2LD at OFFSET 00009A             22
 5. Invalid VBS segment causes SAS to enter SVC Wait or CPU loop      22
 6. SAS USER ABEND 315 has occurred in an SMS environment for tape    22
 7. SAS ZAP Z6087095 required to use MVS PDSE instead of a PDS        22
 8. 'FORMAT MGxxxxx UNKNOWN' due to insufficient MEMSIZE.             22
VII.  IMS Technical Notes                                             22
 1. MXG position on using IBM IMS log records                         22
VIII. Incompatibilities and Installation of MXG 11.11                 24
IX.   Documentation of MXG Software.                                  25
X.    Changes Log                                                     27
      Alphabetical list of important changes                          27
      Changes 11.347 thru 11.141                                   30-70
         COPYRIGHT (C) 1994 BY MERRILL CONSULTANTS DALLAS TEXAS

0. IBMs MVS Version 5 Workload Manager and Parallel Sysplex Processors

  IBM presentations at the recent SHARE meeting provided early insight
  into the expected announcement of new mainframe hardware using CMOS
  technology, and a new MVS/ESA 5.1 with its Workload Manager component
  that will revolutionize the measurement and management of MVS.

  For the first time in any computer system, the operating system will
  operate in concert with its subsystems to not only measure the service
  objectives, but also to react when those service goals are not being
  met, and MVS will assign resources (for example, dispatching priority)
  so that the service goal is met!

  Previously, only resource consumption was measured, and delivery of
  resources was managed by MVS without regard to response times or
  workloads, but now, workloads are defined (eg., CICS transactions
  starting with PAY*) and their service goals are measured (eg., 90%
  completed in 1 second) so that your business plan controls the
  delivery of computer resources.

  This feedback loop from the application to the operating system in
  terms of business purpose is truly unique, and there is even more
  power to come in this new world, because the Workload Manager's
  measurements and decisions apply not just to a single MVS image, but
  across the sysplex, so that multiple CPUs in multiple boxes can
  operate in concert!

  And the new Parallel Sysplex mainframes are multiple  CPUs in
  multiple boxes!  These new CMOS technology parallel processors
  will be driven by the new MVS component.  Previous MVS hardware used
  BiPolar technology which was fast, but was also expensive, and it
  generated lots of heat that had to be cooled, often with water.  The
  CMOS technology of PCs and workstations has been harnessed into small,
  inexpensive, air cooled CPUs that, while individually a little slower,
  can deliver the same total power as the BiPolar technology because
  they operate in parallel, to dramatically reduce the cost of mainframe
  computing, while providing all of the industrial strength, security,
  management, economy of scale, backup, and control that will always be
  missing in networks of independent workstations and PCs.

  While some of what MVS used to do really does belong on workstations
  or PCs, many workloads were moved off the mainframe only because of
  the disparity between BiPolar and CMOS costs;  the CMOS platforms and
  the workload measurement and management aspects of the new MVS will
  stem the tide of irrational downsizing, and decisions of what platform
  will service what workload will be based on location of data and the
  appropriateness of the technology instead of short term false economy!

  A VP of DP at an oil company was required to supply workstations to
  his petroleum engineers because of only hardware cost savings, but he
  now laments that his engineers spend half of their time looking for
  oil, and the other half of their time looking for disk space on their
  workstations!  Each engineer's productivity was diluted as each became
  half-time engineers and half-time data center managers.

  That is unlikely to occur again with CMOS mainframes and MVS 5.1!

  I am tremendously impressed by IBM's forward thinking design of this
  new world of mainframes in which company business goals direct the use
  of computer technology, and not vice versa.

I. MXG Software Production Version 11.11, dated March 26, 1994, was
   shipped with MXG Newsletter TWENTY-FIVE.

  Critical notes about MXG Version 11.11:

  - Products that require MXG 11.11 because of incompatible records:

    DB2 Version 3.1.0.
    Landmark's CICS/ESA Version 1.1.
    LEGENT's TPX Release 3.5.
    Software AG's COM-PLETE Release 4.5
    Sterling's NDM, now Connect Direct 1.7.01.

  - ANALDB2R users must use MXG 11.11 because of report corrections.

  - You MUST use member CONFIG from this MXG SOURCLIB or you will get
    many strange errors! (If you are still stuck at SAS 6.06, see Change
    11.187 and use CONFIG06).  Member CONFIG executes %VMXGINIT with
    INITSTMT='%INCLUDE SOURCLIB(VMXGINIT); %VMXGINIT;' to initialize the
    internal macro variables introduced in Change 11.150.

  - If any of these members exist in your USERID.SOURCLIB(s) libraries:
               ASUMDBDS ASUMDB2A ASUMDOS  ASUMHPCS ASUM70PR
               DAILYDSN GRAFDB2  GRAFLPAR TRNDDB2A
    or if you use %VMXGSUM in your own report/summarization programs,
    then you MUST read the incompatibility details in Section VIII and
    in Change 11.309 and you will need to re-tailor your changes.

  - MXG 11.11 requires SAS 6.08 at maintenance TS407 plus Zap Z6088203
    to correct all known SAS errors.  See Section VIII.
      (Note: the online NEWSLETTER was revised - the original text also
             listed Z6086442 as required, but later input from SAS
             Institute Tech Support indicated that 6442 was already
             included in Maintenance TS407).

MXG Version 11.11 was shipped along with Newsletter TWENTY-FIVE, and it
should be installed immediately as it provides these major enhancements:

  These major enhancements were added in MXG 11.11 dated Mar 26, 1994

  Support for STK's ICEBERG device user SMF record.
  Support for Boole & Babbage CICS/Manager Type 110 Statistics records.
  Support for Candle's Omegamon II for SMS user SMF record
  Support for ISOGON's SoftAudit product's externalized files.
  CICS/ESA Shutdown Statistics Report (DFHSTUP) now produced by MXG.
  Sterling's NDM, now Connect Direct 1.7.01 incompatible changes.
  Partial support for LEGENT's MIM Release 4.0.
  Enhancements and corrections to ANALDB2R DB2PM-like reports.
  Enhancements to VMXGSUM summarization routine.
  Feedback that ASMIMSLG does not fail with IMS 4.1 log records.

  These major enhancements were added in MXG 11.10 dated Feb 14, 1994

  Support for IBM's OPC/ESA Release 2.1.
  Support for LEGENT's NETSPY Release 4.4.
  Support for CA's ACF2 Releases 6.0 and 6.1.
  Support for Candle's Deltamon SMF record.
  Performance improvements for VMXGSUM (used in most ANALxxxx members).
  The ANALSMF "Simulator" analyzes SMF VSAM CI Size impact on your site.

  These major enhancements were added in MXG 11.09A dated Jan 10, 1994

  Support for Landmark CICS/ESA Version 1.1 (incompatible) records.
  Summarization of Amdahl's APAF in ASUMAPAF.
  Support for ZARA Release 1.1.
  Corrections to ANALDB2R reports.
  Performance enhancements in VMXGSUM execution.

  These major enhancements were added in MXG 11.09 dated Dec 17, 1993

  Support for DB2 Version 3.1.0 incompatible changes to DB2 SMF records.
  Support for NPM Version 2.1.0.
  Support for AS/400 Version 2.3 Performance Data.
  Support for Memorex Telex LMS Version 2.17
  Support for BatchPipes/MVS type 91 SMF record.
  Support for Mobius' INFOPAC-RDS user SMF record.
  Support for Integris UniKix records (both ASCII and Binary format).
  Support for Novell Network Navigator User SMF record.
  Support for Softwork's Performance Solution I/O Plus & Hiperload SMF.
  Support for NETWISE RPC EXEC type 33 SMF record.
  Performance enhancement of VMXGSUM algorithm
  Utility to count type 110 records by application.

  These major enhancements were added in MXG 11.08 dated Nov  1, 1993

  Support for Amdahl APAF Version 2.1
  Support for FOCUS MSO Release 6.8.
  Support for IBM's ADSM subtype 14 type 42 SMF record.
  CICS "Requested Reset Statistics" now processed into PDB.CICRRTRV.

  These major enhancements were added in MXG 11.07 dated Oct  4, 1993

  Support for DFSMSrmm (Removable Media Manager) two SMF records.
  Support for DFSMSrmm Extract Files created by IBMs EDGHSKP utility.
  Support for AS/400 Release 2.2, all records, labels, formats, etc.
  Support for SAP's IMS log record type 'AE' for SAP IMS Accounting.
  Support for AICorp Central Server SMF record.
  Support for Type 42 Subtype 4 Concurrent Copy & Extended Sequential.
  Support for Sterling's NDM, Network Data Mover SMF record.
  Support for 4th Dimension's CONTROL-D Release 3.0.0 SMF record.
  Support for NETVIEW APAR OY66237 change to TYPE37 SMF record.
  Graphics enhancements for consistency, better pictures, in GRAFxxxx.

  These major enhancements were added in MXG 11.06 dated Oct  1, 1993

  Support for TCP/IP 2.2.1 APAR PN40511 (API Calls, FTP/TELNET Client)
  Support for ASTEX Release 1.7 SMF record
  Support for Software AG's COM-PLETE Release 4.54 SMF record
  Support for Laser Access Corp's Optical Disk System's 3 SMF records
  Support for LEGENT's SAR product User SMF record.

  MXG 11.05 was a checkpoint version after Change 11.150.
  MXG 11.04 was a checkpoint version before Change 11.150.

  These major enhancements were added in MXG 11.04 dated Aug 20, 1993

  Support for LEGENT's SAR product's User SMF record.
  Support for Laser Access's Optical Disk System User SMF records.
  Final (?) correction to ASUM70PR.

  These major enhancements were added in MXG 11.03 dated Jul 26, 1993

  Asynchronous Data Mover Facility APAR OY65142 for SMF type 30.
  OMEGAMON/CICS VSAM,DLI,IDMS,ADABAS,SUPRA,DATACOM SPE QOC0553

  These major enhancements were added in MXG 11.02 dated Jul  6, 1993

  Support for VM/ESA Release 2.1.
  Support for Top Secret Release 4.3.
  Support for NPM APAR OY54370.
  Support for RMF APAR OY64585.

  Support for SAP Releases 4.3.J and 5.0.
  Support for DOS/VSE POWER 5.1.
  Support for OMEGAMON 2.60 Audit Record changes.
  Support for APPC Deaccumulation APAR OY63634.

  These major enhancements were added in MXG 11.01 dated May 20, 1993

  Support for ZARA, The Tape Media Manager from Altai.
  Support for SYNCSORT Release 3.5 SMF record.
  Support for HMF, Host Monitoring Facility user SMF record.
  Support for Corporate TIE user SMF record.
  Support for STOPX37 Release 3.5 mis-documentation.
  Enhanced ANALRMFR for RMF look-a-like reports from MXG.
  Validation of Candle's ITRF (Omegamon/IMS Version 110).
  Validation and correction of SMSDATA operand of DCOLLECT

  Each of those 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

      RMF 4.1.2 (for MVS/ESA 3.1.3)    Sep  7, 1990.        8.8
      RMF 4.2   (for MVS/ESA 4.1)      Oct 26, 1990.        8.8
      MVS/ESA 4.1                      Oct 26, 1990.        8.8
      MVS/ESA 4.2                      Mar 29, 1991.        9.9
      RMF 4.2.1 (for MVS/ESA 4.2)      Mar 29, 1991.        9.9
      MVS/ESA 4.2.2                    Aug     1991.        9.9
      RMF 4.2.2 (for MVS/ESA 4.2.2     Aug     1991.        9.9
      MVS/ESA 4.3                      Mar 23  1993.       10.10
      RMF 4.3.0 (for MVS/ESA 4.3)      Mar 23  1993.       10.10
      MVS/ESA 5.1.0                  ??Summer  1994??      12.??
      CICS/ESA 3.2                     Jun 28, 1991.        9.9
      CICS/ESA 3.3                     Mar 28, 1992.       10.01
      DB2 2.2.0                                1990         8.8
      DB2 2.3.0                        Oct 28, 1991.       10.01
      DB2 3.1.0                        Dec 17, 1993.       11.09
      VM/ESA  1.1.1                    Dec 27, 1991.       10.1
      VM/ESA  2.0                      Dec 23, 1992.       10.4
      VM/ESA  2.1                      Jun 27, 1993.       11.02

  These products were not completed in time for MXG 11.11.  Contact us
  if you want to be shipped support when completed (2nd quarter):

  TYPEZRB - RMF III VSAM file for MVS/ESA 4.2 and 4.3 is not correct.

  Huron   - Huron SMF record is not supported yet; no sample data SMF
            data was provided, and the printed DSECTs were massive and
            needed in machine readable form.  Planned for 2nd quarter.

  EPIC    - LEGENT has not provided the format of their tape catalog;
            instead, they want you to use the output of their extract
            program, which means double processing and kludgy coding.
            Nothing planned until LEGENT supplies needed formats.

II.   MXG Technical Notes

 1.  Executing MXG on PCs and Workstations

 a. Non-portability of SAS data libraries with $HEX variables.

SAS data libraries are currently not completely portable between EBCDIC
and ASCII platforms, because SAS Transport Procedures (UPLOAD, DOWNLOAD,
etc.) convert all character values from EBCDIC to ASCII.  Thus character
variables that contain binary data (i.e., those with $HEX format) are
corrupted when moved between platforms.  An MVS '40'X value is changed
to a '20'X under ASCII versions, causing bit tests to fail and wrong
values to be printed.

SAS Institute recognizes the unilateral conversion as a design problem,
and had considered changing the Transport Procedures so they would NOT
translate any variable with the special INFORMAT name of $NOTRAN.  Code
was added to MXG to assign the $NOTRAN informat to all MXG character
variables that contain binary data, in anticipation of the SAS design,
and member FORMATS creates a $NOTRAN informat.  However, SAS Institute
has now decided that the informat attribute is inappropriate for this
usage, and is investigating alternative solutions for SAS Version 7.
  Note: Aug 2, 2004:  See Change 22.192. All INFORMAT xxx $NOTRAN. ;
  statements were removed from MXG source code.

Until SAS Institute resolves this design issue, you must be aware of any
character variables that contain binary ($HEX) data, and convert their
values back to the original value after downloading the SAS Data Sets
on the ASCII platforms, using the new MXG utility UTILCVRT.

 b. Datasets SORTed BY character variables are unsorted after download.

Datasets that were sorted BY character variables under EBCDIC will not
be sorted under ASCII (and vice-versa), because the EBCDIC collating
sequence is different than ASCII.  You will have to re-SORT the data.

 c. SAS Source code changes made so that MXG executes under ASCII SAS:

 - All numeric informats whose interpretation depends on the execution
   platform were replaced with a macro variable whose value is now set
   in VMXGINIT (which is now automatically invoked by the INITSTMT= in
   the CONFIG member).  The numeric informats macro variable names and
   their values under EBCDIC and ASCII platforms are:

     Macro variable       EBCDIC value       ASCII value
        &PIB                 PIB              S370FPIB
        &IB                  IB               S370FIB
        &PD                  PD               S370FPD
        &PK                  PK               PK
        &RB                  RB               S370FRB
        &NUM                 null             S370FF

 - All character variables that contain printable data were changed to
   be INPUT with $EBCDICn. informat instead of $CHARn.

 - All character variables that contain hexadecimal data (i.e., have
   format $HEX) were changed to be input with $CHAR informat, and all
   were also explicitly assigned the informat named $NOTRAN.

 - All date variables input as DDMMYY, MMDDYY, or YYMMDD and all time
   variables input as TIME or HHMMSS were replaced with individual
   inputs of DD MO and YY or HH MM and SS using the &NUM macro variable
   and then dates are created with the MDY function.  All dates are now
   formatted DATE7 (to avoid confusion between USA and European date
   formats).

 - Character variables whose length had been set in a FORMAT statement
   were instead declared in a LENGTH statement for consistency.

 - Use of INPUT(string,format) were examined, and if the format item
   expected EBCDIC representation, the input of the string was $CHAR,
   but if the format item expected printable character/numeric date, the
   string was input with $EBCDIC.

 - Formats that test for hexadecimal data values were identified (in
   member FORMATS) and variables using those formats were changed to be
   INPUT $CHAR with INFORMAT $NOTRAN.

 - Numeric variables minimum LENGTH is 3 under ASCII SASs.  Previously,
   length 2 could be used.

 - Obscure input informats $PHEX and $CHARZB have no exact equivalent
   for processing MVS data under ASCII platforms.  Each case has to be
   modified with unique coding.

 - The algorithm used to identify EBCDIC numerics from alphabetics:
      IF var LT '0' ==> alphabetic      IF var GE ='0' ==> numeric
   is invalid under ASCII.  EBCDIC numbers are 'F0'x->'F9'x, which is
   greater than EBCDIC alphabetics ('81'x->'E9'x), but ASCII numbers are
   '30'x->'39'x, which is smaller than ASCII alphabetics ('41'x->'7A'x).
   Only VMACVMXA's building of the INSTREAM format used this algorithm.

 - Use of $VARYINGnnn must be examined individually.  $VARYINGnnn acts
   like $CHAR instead of $EBCDIC, so strings input with $VARYING that
   are printable characters must be converted with:
         INPUT variable $VARYINGnn. lenvar @;
         variable=INPUT(variable,$EBCDIC.);
         variable=TRANSLATE(variable,' ','80'x);
     Note: the TRANSLATE was required because the INPUT function was
           used.  SAS Institute pointed out that the INPUTC(str,val,len)
           function would have eliminated the need for TRANSLATE().
   For character variables that do not contain printable characters, the
   INPUT and TRANSLATE are not required, but the variable must be FORMAT
   with $HEX, and INFORMAT with $NOTRAN.

 - Statistics about Change 11.150:  The 244 members starting with 'V'
   were PROC SOURCEd into a single text file of 128,144 lines (10MB).
   Three TSO sessions totalling 40 hours across three days issued 11,810
   commands (typical: CHANGE X Y ALL NX across all 128,000 lines) used
   1187 CPU 3090-400S seconds.  A total of 30,167 lines were changed in
   194 members.  Testing found spelling/syntax errors in seven lines.
   PDB.JOBS shows those TSO sessions resources totalled:

        EXECTM  =148,894 sec  PAGEINS =  22,824 ==>  100MB
        ACTIVETM=  4,161 sec  SWPAGINS=  50,645 ==>  200MB
        RESIDTM =  4,065 sec  STOLPAGE= 645,672 ==> 2500MB
        CPUTM   =  1,187 sec  SWAPS   =  11,800
        IOTMTOTL=    625 sec  NRTRANS =  11,810 = 285/hour
                              (line speed 14.4-16.8qwpts)

    This was a fairly intense TSO EDIT session for 40 session hours!


  As a result of these changes, MXG 11.11 Software can now be executed
  on ASCII platforms (i.e., on PCs with WINDOWS or OS/2, or on
  workstations with UNIX) to read raw data records (i.e., SMF,
  VM/Monitor, etc.) that were downloaded, and MXG will create the same
  MXG datasets that you have been using all along on your EBCDIC
  platforms (i.e., MVS or VM)!

 d. Downloading the MXG Source Library from MVS to ASCII PC Platforms.

   This example shows how you can use IND$FILE to convert the MVS PDS
   into one ASCII file per member.

   The MXG members must be unnumbered to execute correctly under the SAS
   ASCII versions, and each ASCII file must be named "member.SAS".

   First, create MXG.IEBUPDTE.NUMBERED, an 80-byte numbered sequential
   file in IEBUPDTE format from your MXG.SOURCLIB PDS. (Since this is
   an exact copy of the MXG IEBUPDTE distribution tape, so you could
   alternatively just copy the tape into MXG.IEBUPDTE.NUMBERED.)
   Sample JCL for these steps is in member JCLDOWNL.

      //IEBUPDTE EXEC SAS608
      //IN     DD DSN=MXG.MXG.SOURCLIB,DISP=SHR
      //OUT    DD DSN=MXG.IEBUPDTE.NUMBERED,
      //          DISP=(NEW,CATLG),SPACE=(CYL,(69,5)),UNIT=DASD,
      //          DCB=(RECFM=FB,LRECL=80,BLKSIZE=32720),VOL=SER=MXGNNN
          PROC SOURCE INDD=IN OUTDD=OUT;

   Second, create MXG.IEBUPDTE.UNUMBERD, a 72-byte unnumbered copy of
   the IEBUPDTE-format sequential dataset, by truncation:

      //TRUNCATE EXEC SAS608
      //IN       DD DSN=MXG.IEBUPDTE.NUMBERED,DISP=SHR
      //OUT      DD DSN=MXG.IEBUPDTE.UNUMBERD,
      //            DISP=(NEW,CATLG),SPACE=(CYL,(65,6)),UNIT=DASD,
      //            DCB=(RECFM=FB,LRECL=72,BLKSIZE=23400),VOL=SER=MXGNNN
          DATA _NULL_; INFILE IN; FILE OUT;
           INPUT @1 CARD $CHAR72.; PUT @1 CARD $CHAR72.;

   (Or you could use SPF 3.3 (COPY) to copy with truncation.)

   Since ASCII versions of SAS require unnumbered source code, we want
   to truncate on the mainframe before we download, as that will reduce
   the download time.  Furthermore, unnumbered files require less space
   on the PC than the same file if numbered, because ASCII source files
   are stored as a variable-length, delimited string, with trailing
   blanks removed.  Note that the DIR command shows the size of the PC
   Source directory as only 25MB, but actually 39MB of disk space is
   needed for that directory, because of space waste at the end of each
   of the 2500+ individual files in that directory!

        Source Library PDS on MVS         54,146,400  51MB
        Numbered IEBUPDTE on MVS          48,520,800  46MB
        Unnumbered IEBUPDTE on MVS        43,598,400  43MB
        Downloaded IEBUPDTE on PC         31,366,594  27MB
        PC Source Directory - DIR size    26,935,736  25MB
        Actual space required on PC       41,804,347  39MB

        PK Zip of PC Source Directory      5,766,824   5MB

        Note that the zipped MXG Source Library now fits on only four
        "stiffie" disks - the Australian nickname for 3-1/2 floppies.

   Third, on the PC, create directories:

     MD \MXG\SOURCLIB       MD \MXG\PDB
     MD \MXG\USERID         MD \MXG\CICSTRAN
     MD \MXG\SMFDATA        MD \MXG\SPIN
     MD \MXG\FORMATS        MD \MXG\DB2ACCT

   Fourth, use IND$FILE to download mainframe's MXG.IEBUPDTE.UNUMBERD
   into the PC's \MXG\SOURCLIB\IEBUPDTE.UNU, specifying ASCII and CRLF
   options for the download.  Depending on line speed, this can take
   from seventeen minutes to seven hours.  The mainframe file is about
   44MB; coax moves at 1 MB/min, a 4 MBit LAN moves at 2.25 MB/min,
   while 19.2KB dial-up can only move about 5-6MB/hour!

   Fifth, download member IEBUPDTE of the MXG SOURCLIB PDS using
   IND$FILE into \MXG\SOURCLIB\IEBUPDTE.BAS, using ASCII CRLF.

   Sixth, use BASIC to execute IEBUPDTE.BAS to read IEBUPDTE.UNU, which
   splits that sequential file and creates a separate PC file for each
   member of the original PDS.  For example:

          CD \MXG\SOURCLIB
          BASICA IEBUPDTE.BAS
          and reply with filename  IEBUPDTE.UNU

   IEBUPDTE.BAS creates each file with the name of "member.SAS", so that
   the %INCLUDE statements in MXG, of the form:
        %INCLUDE SOURCLIB(XXXXXXXX);
   are recognized by the ASCII SAS version.

   The Basic program to split the sequential file into individual PC
   files took about 48 minutes on a 486/33..

 e. Downloading raw SMF, VM/Monitor, etc. data from MVS with IND$FILE,
    or with ftp.

   You can use IBM's IND$FILE under TSO to an SDLC link (Barr Systems
   BARRSNA or Extra's ATTACHMATE), or to an ASYNC link (IBM's INPCS),
   or you can use ftp (binary) to download V, VB, or VBS files.

   First, the data file to be downloaded must have DCB attributes of
   RECFM=U and BLKSIZE=32760.  You can make a copy of the original SMF
   data with the changed DCB using this JCL:

        //  EXEC PGM=IEBGENER
        //SYSPRINT DD SYSOUT=*
        //SYSIN    DD DUMMY
        //SYSUT1   DD DSN=MXG.SMFDATA.ORIGINAL,DISP=SHR,
        //            DCB=(RECFM=U,BLKSIZE=32760)
        //SYSUT2   DD DSN=MXG.SMFDATA.RECFMU,DISP=(NEW,CATLG),
        //            UNIT=DASD,VOL=SER=MXGNNN,SPACE=(CYL,(60,5)),
        //            DCB=(RECFM=U,BLKSIZE=32760)

   and then download MXG.SMFDATA.RECFMU.  If you cannot afford the DASD
   space, and if no other job will try to access the original SMF file
   for the duration of the download, you could simply change its DCB
   attributes, using this JCL:

        //  EXEC PGM=IEBGENER
        //SYSPRINT DD SYSOUT=*
        //SYSIN    DD DUMMY
        //SYSUT1   DD DSN=MXG.SMFDATA.ORIGINAL,DISP=SHR
        //SYSUT2   DD DSN=MXG.SMFDATA.ORIGINAL,DISP=MOD,
        //            DCB=(RECFM=U,BLKSIZE=32760)

   and then download the changed ORIGINAL file (and then reset the DCB).
   We have to either make a copy or change the DCB attributes because we
   cannot override the DCB attributes used by IND$FILE.  If you instead
   use SAS/CONNECT, or any other file transfer protocol that allows you
   to preallocate or respecify the DCB attributes of the file to be
   downloaded, the extra step can be avoided.  The important aspect is
   that the downloader must see its input as RECFM=U,BLKSIZE=32760.

   Second, now that you have copied or reset your SMF raw data in a
   dataset with DCB=(RECFM=U,BLKSIZE=32760), you can then use IND$FILE
   to download the SMF data set into \MXG\SMFDATA\SMFDATA.U on your PC.
   You must have the NOCRLF and NOASCII options in effect (i.e., do not
   specify CRLF nor ASCII) so that NO carriage return/line feed
   ('13'x,'26'x) is inserted in the data, and so that NO conversion from
   EBCDIC to ASCII is done. We want the PC file to be a serial stream of
   unmodified blocks of mainframe data, including BDWs and RDWs.

   You cannot point to a VBS file on the mainframe and bring it down to
   the PC; you MUST have the downloading program see RECFM=U, so that
   the raw SMF data is brought down as a complete block, including both
   the BDW and the RDW.  Nothing else will work!

   If you are direct connected, you can expect a 200MB file to take from
   40 minutes (5MB/min) to 100 minutes (2MB/min), depending on speed and
   contention.  Using dial-in at 19.2KB, it will take 33 hours (6MB/hr)
   to download the 200 MB SMF file!

   This download time for SMF data may be reducible with PKZIP/MVS.  On
   the PC, PKZIP reduced the 200MB SMF file to only 30MB, an actual
   compression factor of nearly 8:1, taking only 65 elapsed minutes to
   compress on the Model 95, so downloading and rebuilding a ZIPed file
   at 19.2KB might take only 6 hours after compression.  PKZIP/MVS uses
   the same algorithms and should be suitable for reduction of download
   time of large SMF files, as well as the MXG Source.  Benchmarks are
   planned.  (PKZIP/MVS is available from Scott Avera at ASI, Dayton,
   OH, 513-222-9012).

 f. Moving the raw data and source libraries from PC to UNIX with ftp.

   You can also use ftp if you have a TCP/IP connection.  This example
   shows the ftp commands to copy the MXG SMF and Source data from a
   PC to UNIX; a similar sequence could be used to download directly
   from MVS with TCP/IP.

   - FTP to the machine that has the data and log on:

        %ftp trinity
        name(trinity,sasaws):mxgdemo
        password:

   - Change directories to where the data is:

        cd SMFDATA
        ls

   - Make sure download is binary

        bin
        get SMFDATA

   - Change directory to source library and mode to ASCII:

        cd SOURCLIB
        ascii
        mget *.SAS
        quit

 g. Environmental options (CONFIG.SYS,AUTOEXEC.SAS,etc) required.

  SAS For Windows 6.08 at TS405 or later maintenance is required.

  Remove any Disk Caching Software, notably Microsoft's SMARTDRV:

     No problems were encountered whatsoever with an 85MB SMF file and
     its BUILDPDB, but when the 200MB file was executed, using a 1700MB
     SCSI disk volume for input, work, swap, and PDB output, that 1700MB
     disk was completely destroyed by SMARTDRV.  ("INVALID MEDIA TYPE"
     and total corruption of data).  I believe the error is encountered
     when the total file size being written exceeds 524MB, the limit for
     an IDE partition; it appears that hardware limit is somehow
     embedded in SMARTDRV in DOS 5.0.

     Removal of SMARTDRV eliminated the overwrite of the SCSI disk, but
     the run time was now increased by 50%!  Disk caching is still under
     investigation!

  CONFIG.SYS requires this additional specification:

          FILES=255

     The FILES parameter is needed to prevent an "OUT OF FILE HANDLES"
     condition.

  AUTOEXEC.BAT requires this additional specification:

          SHARE /L:200 /F:10264

     The SHARE parameters are required if you use SHARE (required with
     some LANs and by SPFPC) to prevent "OPERATING SYSTEM ERROR 36."
     The /F parameter defines how many bytes are available to store
     file names.  Since the full path and file name is stored, if you
     use more sub-directories and/or longer directory names, you may
     still have to increase the /F: value.


   AUTOEXEC.SAS changes required:

      Member AUTOEXEC.SAS was downloaded into your \MXG\SOURCLIB
      directory.  It needs to be copied into your \SAS directory, as it
      sets up both the required file names, and invokes the %VMXGINIT
      member that defines the &PIB and other macros described earlier.

        /* for all environments */
        FILENAME SOURCLIB ('C:\MXG\USERID'
                           'C:\MXG\SOURCLIB');
        LIBNAME  LIBRARY  'C:\MXG\FORMATS';
        FILENAME INSTREAM 'C:\MXG\USERID\INSTREAM.SAS';
        /* for SMF and BUILDPDB processing */
        FILENAME SMF       'C:\MXG\SMFDATA\SMFSMALL.U'
                  RECFM=S370VBS LRECL=32760 BLKSIZE=32760;
        LIBNAME  PDB      'C:\MXG\PDB';
        LIBNAME  CICSTRAN 'C:\MXG\CICSTRAN';
        LIBNAME  SPIN     'C:\MXG\SPIN';
        LIBNAME  DB2ACCT  'C:\MXG\DB2ACCT ';
        /* for VM/ESA processing */
        FILENAME MWINPUT  'C:\MXG\VMDATA\MONWRITE.U'
                  RECFM=S370VBS LRECL=32760 BLKSIZE=32760;
        OPTIONS MAUTOSOURCE SASAUTOS=SOURCLIB;
         %INCLUDE SOURCLIB(VMXGINIT); %VMXGINIT;

        Note: UNIX will not tolerate blanks inside quotes for
        \path\dir\filename, while WINDOWS will.  AUTOEXEC.SAS
        for UNIX requires the UNIX syntax for path and filename.

 h. Performance benchmark results:

BUILDPDB has successfully executed under SAS for Windows, and SAS for
OS/2 on a 486, and under SAS for Unix on a Hewlett Packard 710 & 720.

FIRST TEST:
  Input:                 85MB MVS/ESA SMF file
  MVS/ESA on 3090 400S:         9 min 42 sec
  Windows on 486DX 33:   1 hour 9 min
  Windows on 486DX 50:         52 minutes
  Unix on HP 9000 710:         31 minutes
But this was not a representative daily SMF file.


SECOND (REAL WORLD) TEST:

The Case 1 500MB SMF file was used, but only these SMF records types:
  IDs= 0,2,3,6,21,26,30,70,71,72,73,74,75,78,100,101,102,110
read by the BUILDPDB algorithm were selected, resulting in an SMF file
with 189,239 records, totalling 201MB of data, or 300 Cyl of 3380.

Reading the 201MB SMF file on the 486-33 with the TYPE0 program (which
decodes only the SMF header and created no output observations) took:

           With    SMARTDRV     10 min 36 seconds
           Without SMARTDRV     15 min 45 seconds

The full BUILDPDB for the 201MB SMF file on a 3090/400S showed:

       Space Requirements                        Timings for
                                              four repeated runs:
     DDname    Blocks   MB   3380               CPU  Elapsed
                              cyl              mm:ss   mm:ss
      SMF       9000   201    300              12:25   31:25
      WORK      5178   114    172              12:18   31:00
      PDB       6039   132    201              12:23   31:40
      CICSTRAN  2574    57     88              12:24   31:02
       total space     504    761


A 1700MB SCSI Drive was used for input SMF and output MXG datasets.

The Windows Run on a PS/2 Model 90 (486DX 33MHz)
  took 6 hours 23 minutes (without SMARTDRV) elapsed run time,
  and should take 4 hours 30 minutes (with SMARTDRV) elapsed run time.

The UNIX Run    on an HP 9000 Model 720
  took 48 minutes 13 seconds elapsed run time.


Conclusion:
  Yes, you CAN execute MXG under SAS on ASCII platforms;
   on PCs with much longer run times, on Workstations quite comparably.
  But just because you CAN does not mean you SHOULD!

  Does a corporate resource (the PDB) belong on a single-user platform?
  Backup and Archiving of PDB directories will require manual management
   of tapes, a process which is automated on MVS.
  Large volume transfer will impact other LAN users during prime time.

  Nevertheless, the economic motivation for downsizing may be strong,
   if MXG is the only SAS user on MVS; the HP 720 costs $25,000, the
   PS/2 is a $5,000 box, and SAS is much cheaper on ASCII than EBCDIC!

 2. MXG Release 11.11 requires SAS Version 6, but it is still possible
    to run MXG 11.11 under SAS 5.18, with these considerations:

 a. You need member SASOPTV5 from MXG 11.11, and the first statement of
    your program must be: be %INCLUDE SOURCLIB(SASOPTV5);
    (This now invokes %VMXGINIT and defines the &PIB++ macros.)
 b. You must change all occurrences of $EBCDIC to $CHAR in the entire
    MXG sourclib.  (Version 5 does not recognize $EBCDIC.)
 c. You must change all occurrences of double-exclamation-points "!!",
    ('5A'x) with double-solid-vertical-bars "  " ('4F'X).
 d. If there are any other problems, let me know.  None of my test sites
    still have SAS 5.18, and truly, everyone should be on Version 6 now!

 3. Running the MONTHBLD program on a day other than the 1st day of the
    month requires these modifications in member MONTHBLD:
 a. If the rerun day is within the same week as the first day of the
    month, it is only necessary to change MONTHBLD and rerun:
     In the DATA _NULL_ step, replace  TODAY=TODAY(); with the specific
     date of the first day of the month:  TODAY='01APR94'D;
     This will calculate _BEGIN and _END dates correctly and will avoid
     the USER ABEND 1111 condition.
 b. If the rerun day is in the week after the week of the first day of
    the month, you will need to change both the TODAY= and the DAY=
    statements in the DATA _NULL_ step to read:
      TODAY='01DEC93'D;
      DAY='MON';
    as that will cause none of the Daily PDBs to be read; instead, the
    five previous weekly datasets will be read and selected from to then
    create the monthly dataset.  You will need to point the five DD's in
    your JCL for //WEEK1 - //WEEK5 to the five specific weekly PDBs that
    span the month that you are recreating.
 c. Note added August, 1996.
    If you have to recreate a month PDB well after the fact:  Assume you
    are missing one weekly PDB from FEB.  Yesterday you created the week
    PDB, but its observations have ZDATE=13AUG96 (for example).  You can
    modify the SET statement in the heart of MONTHBLD, below) as shown

     - remove the _D1._DSET  thru _D2._DSET text from the SET statement
       (so the Daily PDBs won't be read)

     - change the test for _BEGIN and _END to the explicit dates to be
       selected from the five WEEKly PDB's being read, remembering that
       the ZDATE selection is from the 2nd of the Month to the 1st of
       the next (because on the 2nd of this Month is when you process
       the work of the 1st, etc.).

     DATA TAPETEMP. _DSET ; /* CREATE IN TAPE FORMAT ON TEMP DISK */
      SET
        WEEK1._DSET    WEEK2._DSET    WEEK3._DSET
        WEEK4._DSET    WEEK5._DSET ;
      BY _BYLIST ;
      IF ('02FEB96'D LE ZDATE LE '01MAR96'D) OR ZDATE='13AUG96'D;




 4. "PHYSICAL FILE DOES NOT EXIST, hlq.SOURCLIB.SAS" following "SAS NOTE
    THE INITIALIZATION PHASE will occur if there is no //SOURCLIB DD
    in the job.


III.  MVS Technical Notes

 1. Impact of VSAM CI Size on DASD Space and SMF Write Activity

    I have recommended setting the CISIZE of SMF VSAM data sets to
    half-track value (26K for 3390), because that should minimize the
    number of physical blocks read or written, and reducing the number
    of blocks always reduces both the CPU and the elapsed time to read
    or write SMF data to/from the VSAM file.  Or so I thought!

    One site increased its CISIZE from 8K to 26K and found that they had
    to double the size of their SMF VSAM data set from 500 to 1000 cyl,
    but the size of the 450 cylinder SMF dump output data set did not
    change!  Lawrence Jermyn and Tim VanderHoek at Fidelity opened a
    problem with IBM.  Kathy McEwen at SMF Support replied in her ETR
    3E902, which provided me with insight into the internal architecture
    of the SMF writer; that ETR precipitated this analysis.

    Because the SMF writer does not write true VBS records, lots of VSAM
    space can be wasted; the amount wasted depends on both the CI Size
    and the number of logical records that are greater than the CI Size.
    This is not really new; SMF has always worked this way since the
    1978 rewrite that introduced VSAM files, but the combination of the
    now-possible larger CI size of 26624 on 3990s, combined with lots of
    CICS/ESA type 110 records (which are typically close to 32760 bytes
    long) can dramatically increase the wasted DASD space.


    The SMF writer uses a "pseudo-VBS" algorithm to write records to the
    VSAM data set.  New variable-length records are put into the current
    CI as long as the new record fits.  If there is not enough room for
    the new record in the current CI, the new record is normally NOT
    spanned; instead, the new record is written into the start of the
    next CI.  Record spanning only occurs when the new record's LRECL is
    greater than the CI size of the VSAM data set.  In that case, the
    new record starts in the next CI and fills as many CIs as are needed
    to span the long record, but then any space remaining in the final
    CI for the long record is never used.  Consider this example with
    records of 1000, 32760, 1000, and 32760 bytes using a 26624 CI size:

            ------track 1------ ------track 2------ ------track 3------
             CI=1      CI=2      CI=3      CI=4      CI=5      CI=6
            AA------- BBBBBBBBB BBB------ CC------- DDDDDDDDD DD-------
      Data: 1000      26624     6136      1000      26624     6136
      Waste:    25624         0     20488     25624         0     20488

    Thus 67,520 data bytes were written, but the 6 CIs (159,744 bytes)
    required THREE full 3390 tracks for the four SMF records.

    If a CI size of 8192 is used, these 4 SMF records are written in 10
    10 CIs (81,920 bytes) on less than TWO tracks, using less space:

            --------------------------track 1--------------------------
             CI=1      CI=2      CI=3      CI=4      CI=5      CI=6
            AA------- BBBBBBBBB BBBBBBBBB BBBBBBBBB BBBBBBBB- CC-------
      Data: 1000      8192      8192      8192      8184      1000
      Waste:     7192         0         0         0         8      7192

            --------------------------track 2--------------------------
             CI=7      CI=8      CI=9      CI=10
            DDDDDDDDD DDDDDDDDD DDDDDDDDD DDDDDDDD- --------- ---------
      Data: 8192      8192      8192      8184      available available
      Waste:        0         0         0         8

    Why does SMF not span all records?  It all goes back to the original
    SMF BSAM architecture introduced in OS/360 in 1969.  The SMF dump
    program would fail with an ABEND 002 when it encountered broken VBS
    records.  If records were always spanned, a system crash would cause
    the SMF dump program to ABEND 002, because the last block written to
    DASD before the crash would have indicated spanning, but the next
    block found would be the new IPL record that was written after the
    crash!  So as to minimize the probability of the 002 abend, the
    original SMF writer only spanned when the LRECL was greater than the
    BLOCKSIZE.  Since records written by BSAM were still truly variable
    records, whether spanned or not, there was no wasted space.  This
    pseudo-VBS algorithm was repeated in the 1978 VSAM- based redesign,
    but that implementation fixed the CI size at 4096, so wastage was
    small.  Now, with many long SMF records and the now-possible larger
    CI sizes, the pseudo-VBS algorithm of the SMF writer not only wastes
    DASD space, it also causes the SMF Writer to issue many more VSAM
    physical writes than would be if ALL records were spanned.

    So what is the right CI size? It depends mostly on how many records
    are greater than the CI size, and also on the order in which records
    are written.  It also depends on whether you want to minimize the
    DASD space required, or whether you want to minimize the number of
    write operations performed by the SMF writer (i.e., the overhead of
    the SMF writer).  Only by reading your SMF file to simulate the VSAM
    write activity of the SMF Writer with different CI Sizes, can you
    determine the CI size inpact on your installation.  MXG's ANALSMF
    program now contains "The SMF Simulator" which reads your input SMF

    file and analyzes the impact of various CI sizes at your site.
    Two case studies show these results:

     Case 1 - Moderate CICS Activity  (125K Trans/day)  Two 3090-200S
      Daily SMF Volume = 500MB (624 Cyl when dumped)

           CISize    CI's     3390
                     Written  Cyls
            4096    142,329     792
            8192     69,373     762
           16384     34,220     761
           22528     25,823     861
           26624     22,277     744<==Min DASD and Min CIs written

    Here, the 26K CI Size minimizes VSAM space, but the 26K savings is
    only 6% less than 4K, so the CI Size impact on DASD is small.
    However, the 26K CI Size reduces the number of SMF Write operations
    to one-sixth the number at 4K; clearly the large CI Size here
    benefits both DASD Space and SMF Writer operations.

     Case 2 - Massive CICS Activity (10000K Trans/day)  Four 9021 941s
      Daily SMF Volume = 12,843MB (15,588 Cyl when dumped)

            CISize    CI's     3390
                     Written   Cyls
            4096  3,451,701  19,179<==Min DASD Space
            8192  1,769,542  19,664
           16384    893,113  19,848
           22528    809,346  26,981
           26624    777,664  25,924<==Min CIs written

    Here, the 4K CI Size minimizes DASD space, using 6745 fewer cyls
    (26% less) than the 26K CI size, but that 4K CI Size maximizes the
    CI writes (over 4 times as many writes than the 26K CI size), so the
    minimization of both DASD space and CIs written here is mutually
    exclusive!  The best compromise here is the 16K CI size, as 16K uses
    only 3% more DASD space than the minimum DASD, and 16K writes only
    15% more CIs than the minimum write activity.

    The IBM ETR recommended a CI Size of 8K (based upon the average SMF
    record length of 28000 reported by the SMF Dump program); while 8K
    does require slightly less DASD space, the Simulator provides better
    basis for optimizing both DASD Space and Writes than average size!

    The SMF development team has been made aware of these results, and
    is investigating the feasibility of spanning all records so as to
    minimize both the size of the VSAM file and the number of writes.

 a. Frequency of SMF Write Activity

The SMF VSAM datasets are NOT high activity in most sites. We can see
in these statistics from the two Case Studies

                         ---Case 1---      -----------Case 2------------
                         --500MB SMF-      ---------13,000MB SMF--------
                          SYS1   SYS2       CPUA   CPUB   CPUC   CPUD

Seconds with writes       6210  11143      67807   79241   28589   56075
Avg Secs between writes     13      7        1.5     1.6     3.1     1.4
Max CIs in one second       10     13        318     184     276     157
Max SMF Buffers Used        42     55        525     135     342     127
SMF record count          376K   676K      1126K   1952K   1686K   1303K
Total SMF data volume    174MB  321MB     1933MB  2853MB  3773MB  4118MB

  Note: As there are 86,400 Seconds in one day, SMF on SYS2 only wrote
  during 1 out of every 8 seconds.  Even on the massive systems, writes
  occur seconds apart (and devices can handle tens of I/Os per second!)

 The peak SMF writer activity always occurs during the second when the
 RMF interval expires.  For the 500MB case 1 site, the ten peak seconds
 of the day show how little activity actually occurs; furthermore, no
 task is waiting while SMF writes asynchronously from its buffers:

 Endtime     Databytes     CIs Written  Seconds since prior record
 13:29:00      215414         13                 3.2
 04:29:00      205606         12                 9.8
 05:44:00      195969         10                20.7
 15:44:00      194901         10                 3.2
 00:44:00      186474         10                 6.9
 21:59:00      185746         10                 1.9
 03:14:00      183893         10                25.4
 13:44:00      183853         10                 3.4
 19:14:00      181112         10                22.4
 00:59:00      174962          9                 6.4

 b. Contents of the input 500MB SMF File from Case 1.

 Record ID  Record Count       Byte Count      Percent of Bytes
    2              12                 168
    3              10                 140
    6             513              57,456
    9               7                 216
   11               5                 120
   14         151,202          45,987,728           8.8
   15          83,888          24,160,720           4.6
   17          13,270           1,273,960            .2
   18             320              44,800
   21           5,757             333,906            .1
   23              46               4,876
   24              23               5,175
   26           7,593           2,870,154            .6
   30         104,823         110,965,648          21.4
   36               3                 630
   37           8,289           1,699,236            .3
   41             185              31,080
   47              31               2,666
   48              31               2,201
   50             154              10,692
   52               6                 348
   53           1,120              90,720
   57           3,897             389,700            .1
   60          96,097          51,806,735          10.0
   61          15,022           4,632,591            .9
   62          38,264           5,697,122           1.1
   64          71,894          28,235,144           5.4
   65          12,421           3,831,009            .7
   66          16,598          13,693,557           2.6
   70             187             216,172
   71             186             188,232
   72          43,524          14,548,176           2.8
   73             187             415,140            .1
   74             558          12,539,748           2.4
   75           1,399             290,992            .1
   78             372           1,478,784            .3
   80          39,391           9,804,727           1.9
   90              13                 928

  100             370             463,240
  101          19,308          18,204,480           3.5
  102             307             626,368            .1
  110           1,775          43,131,798           8.3
  138           9,038          14,292,536           2.8
  175 Local    26,188             916,580            .2
  187 TPX      12,244           1,548,062            .3
  200          16,947           1,425,854            .3
  201             114               9,522
  214          14,987           1,423,765            .3
  217 TSO/MON   1,169           3,804,477            .7
  218 TSO/MON   1,609             739,891            .1
  230 Local         2                 216
  242             180              91,320
  249 IMFprog 107,434          27,288,236           5.3
  250 IMFtran 122,301          68,594,601          13.2
  251 Local       901              38,220
  255             846           1,805,591            .3

Contents of Output Daily PDB built from the 500MB SMF site:

Dataset                              -Number of-    obs  ---Size in---
Name      Description                  obs  vars    len  blocks  MBytes

ASUMDB2A  Summarized DB2ACCT         2,863   225    985     126    2.7
ASUM70PR  Summarized TYPE70PR          186   218    836       8     .2
CICS      Summarized CICSTRAN        3,564    21     89      38     .8
CICSTRAN  CICS Transactions        123,444   110    475    2574   56.6
JOBSKED   Summarized JOBS              133    18     70       1     .0
DB2ACCT   DB2 Transactions          19,305   312   1484    1248   27.4
DB2STAT0  DB2 Intervals                183   320   1298      14     .3
DB2STAT1  DB2 Intervals                183   448   1799      18     .4
JOBS      Job resources              7,857   214   1071     368    8.1
NJEPURGE  NJE Job events             1,242    61    356      20     .4
PRINT     Printer events               513    47    339       8     .2
RMFINTRV  RMF Interval                 186   398   1593      16     .4
STEPS     Step terminations         34,082   187    921    1366   30.0
TAPES     Tape volume dismounts      5,754    28    124      32     .7
TSOMCALL  TSO/MON CALL executions    1,609   101    553      38     .8
TSOMCMND  TSO/MON Commands          29,103     8     45      58    1.3
TSOMDRU   TSO/MON DRU                5,644    13     56      14     .3
TSOMDSNS  TSO/MON DSnames            1,609    26    171      13     .3
TSOMSYST  TSO/MON User Intervals     8,771   168    722     280    6.2
TYPE0203  SMF Dump Starts/Stops         22     5     27       1     .0
TYPE70    RMF CPU interval             186   361   1341      14     .3
TYPE70PR  RMF PR/SM interval         1,860    32    105       9     .2
TYPE71    RMF Paging/Swap interval     186   281   1136      12     .2
TYPE72    RMF Performance Groups    10,856    76    327     156    3.4
TYPE73    RMF Channel interval      17,856    42    180     141    3.1
TYPE74    RMF Device interval       96,886    95    375    1590   34.9
TYPE75    RMF Page Datasets          1,399    38    209      13     .3
TYPE78CF  RMF I/O Configuration     15,499    30    115      79    1.7
TYPE78CU  RMF Control Units          3,897    19     86      15     .3
TYPE78IO  RMF I/O Processors           372    21     91       2     .0
TYPE78VS  RMF Virtual Storage          186   443   2414      22     .0

Total Storage Required:                8613 blocks (@ 23040), or 183 MB.

 2. An increase in recorded CPU TCB time and total CPU Busy time has
    been found when sites have installed Microcode Level SEC 228150 plus
    MVS/ESA 4.2, and are running in an LPAR Environment.  Sites that had
    measured CPU TCB time variability in the range of 0-7% before the
    changes, found the variability range was now from 0-15%.  When these
    sites upgraded to MVS/ESA 4.3, the CPU variability returned to the
    earlier, lower, values.  This turns out to be yet another LUE, or
    Low Utilization Effect, even though the PR/SM hardware was running
    at 100% CPU busy!
    What happens, according to IBM's Gary Hall, at the SHARE 1994 Winter
    Meeting, is that while "SEC150" is best known for giving us EMIF, it
    also revamped the microcode for the LPAR Dispatcher, aiming to
    minimize the LUE, of PR/SM.  However, that microcode level, plus
    changes in the MVS dispatcher (to make it more event driven, so as
    to reduce SIGPs, for example) conspired together, and ole MVS/ESA
    4.2 hammered the LPAR environment, causing the recorded CPU time to
    increase!
       Consider a PR/SM machine with several production LPARs, and with
       a nearly-idle 3090-600 LPAR for SYSPROGs:  even though the rest
       of the LPARs are driving the real engines to 100% busy, and even
       though nary a SYSPROG is logged on to this LPAR (so this LPAR's
       utilization is very low), ole 4.2 in this LPAR frequently wakes
       up each of the 6 CPUs it thinks it's got, to see if there is any
       work for 4.2 to do!  That means each of the 6 Logical CPUs have
       to be dispatched on a real CPU, so LPAR management now has to
       steal a real engine from your online system, and that engine then
       has to invalidate lines in its HSB, the High Speed Buffer (also
       called the CPU cache), to make room for the SYSPROG LPAR's MVS
       instructions, so that that MVS can execute instructions, to find
       out that there is still nobody logged on and nothing to do!  And
       this happens every time MVS wants to enter the wait state, which
       is very frequent in a machine that's waiting most of the time!
       The big difference between MVS waking up in a native machine and
       MVS waking up in an LPAR machine is that the HSB is not shared in
       a native machine, so there is little cost and no contamination
       for the wake up, but in LPAR machines, with their shared HSB, any
       logical machine wake up can contaminate the current contents of
       the HSB, causing additional overhead to reload the replaced line.

    Since LPAR management has to execute each logical engine on a real
    engine, the overhead increases with the total number of logical
    engines that are defined, and the LPAR management time primarily
    contributes to uncaptured CPU time.  The TCB time effects primarily
    result from the changing of lines in the HSB (or CPU cache), which
    cost more CPU time when the production LPAR is re-dispatched, since
    it now has to reload the HSB from real storage.

    MVS/ESA 4.3 makes the problem go away because the MVS Dispatcher was
    redesigned (and uses what is now called Alternate Wait Management);
    MVS now looks at its own utilization, and when utilization is low,
    MVS stops waking up the extra logical CPUs until new work arrives!

    This problem was originally reported by a Gartner Group "FLASH", but
    that alert did not mention that the problem only occurs in LPARs.

 3. APAR OY65101 adds a new JES2 option (NEWPAGE=1/ALL) to choose if a
    new page is counted only for "skip-to-channel-one" (NEWPAGE=1), or
    if a new page is counted for "skip-to-any-channel" (NEWPAGE=ALL, the
    default, and the old way).  This APAR addresses a long standing need
    to make variable PAGECNT more accurate; however, you should read the
    discussion in Newsletter 23, "MVS/ESA Resource Accounting- PRINTERS"
    on page 22, because PAGECNT is still a poor choice for accounting.

 4. APAR OY61331 corrects wrong/impossible values in type 14 SMF records
    for multi-volume datasets in fields (SMF14RIN,SMF14NEX,SMF14NER,
    SMF14NTA,SMF14NTR,SMF14NTU,SMFTIOE4,SMFSRTES) which caused values
    like 168 extents allocated, 1 track allocated, false PDSE flag, etc.
    That APAR went PE, so see also OY63627.

 5. APAR OY65854 reports (without a fix) errors in STARTIME (SMF7xIST)
    in RMF after applying OY59552.  The error is that STARTIME contains
    the interval end time instead of the interval startime!  Also, the
    DURATM (SMF7xINT) may be very small ('0000010F'x = 10 millisec).

 6. APAR OY65280 corrects invalid data in TYPE24 when a multi-destinated
    SYSOUT data set followed by a normal SYSOUT data set are offloaded.

 7. APAR OY66531 corrects erratic values in TYPE74 Disconnect and Pend
    Times.  While the APAR mentions only Monitor II (i.e., type 79 RMF
    record), and only for Serial Channels, installing this APAR did in
    fact correct bad values for both Parallel and Serial channels in the
    type 74 RMF record (i.e., Monitor I).

 8. APAR OY67681 reports (without PTF yet) that TYPE62 variable DSNAME
    is incorrect when the component/cluster being opened is the catalog
    itself.  The first 12 bytes of the name are overlaid in that case.

 9. Boole and Babbage CMF type 70 records under Amdahl's MDF contain
    incorrect CPU utilization that is fixed by their correction BAM3760.

10. MVS/ESA allocates secondary extents differently than MVS/XA.  A site
    running BUILDPDB under SAS Version 5, with //WORK block-allocated
    SPACE=(6144,(100,50)), found the job ran under XA but failed with
    insufficient work space under ESA.  It turns out that under XA the
    secondary allocation of 50 blocks used the DCB blocksize, and not
    the JCL block parameter.  The DCB blocksize after open was 32760,
    and the job got the space it needed in secondaries of 50*32760 per
    secondary.  However, ESA (correctly, I believe) always uses the JCL
    block size for secondaries, and the job only got 50*6144 per
    secondary, and thus failed for insufficient space!

11. After installing PUT 9332, invalid type 70 records are created with
    no PR/SM section (and thus no observations in MXG TYPE70PR dataset),
    and with invalid data for WAIT times in the TYPE70 data set, and
    these invalid type 70 records caused IBM's RMF Report program to
    ABEND 0C9.  These errors are corrected by APAR OY67002 for MVS/ESA
    4.2.0 thru MVS/ESA 4.3.0.

12. Type 6, 24, and 26 SMF records READTIME can be later than REND time
    when using the sysplex timer with a non-zero leap second value until
    APAR OY67004 is installed.  IBM uses STCK instruction for READTIME,
    and the TIME macro for reader end time, but only the TIME macro had
    proper support for leap-seconds.  APAR OY67004 now causes the STCK
    instruction to now factor leap seconds into conversion to local.
    This APAR also indicates that timestamps that used to be all nulls
    are now going to be formatted as a zero-value packed field; this may
    cause problems since SAS has always input all nulls as a missing
    value (i.e., the event did not occur), but a zero-value packed field
    would be input as 01Jan1960:00:00:00!

13. PTF UY91040 corrupts the Cache RMF Reporter data (size of cache is
    wrong).  APAR AW01787 corrects the error.

14. APAR OW01141 reports SMF/RMF records are not synchronized when they
    should be, but no PTF is yet available. (4/12/1994: PTF does exist).

15. IBM Washington System Center Flash 94-06, (Internal Use Only),
    "Release to Release Migration Software Performance Impact" provides
    an excellent, open discussion of how the recorded CPU time was
    changed by upgrading several products at one time.  Get your IBM SE
    to share it with you.

16. APAR PN52658 corrects the wait times in the BatchPipes/MVS Product's
    type 91 SMF record.  Without the APAR, those times are invalid.

17. APAR PN49692 corrects type 96 (TIRS) SMF record; subtype was 36 vice
    2, and CPU times were five times too large.

18. APAR OW02571 reports (no PTF yet) invalid DCOLLECT values for 3390-9
    devices; values in DCVFRESP/DCVALLOC are overreported.

19. Type 30 interval records are not written for swapped out tasks.
    This is not new, but just a reminder of a typical TSO session:
              INTBTIME   INTETIME      SMFTIME
               8:23am      8:30am      8:30am
               8:41am      9:00am     12:14pm
              12:14pm     12:15pm     12:15pm
    This TSO user logged on at 8:23, worked until before 8:30.  At 8:41
    he did a little, but then slept until 12:14, when he logged off.  No
    records were written between 9:00am and 12:14, because the task was
    swapped out, and no task is swapped in to write the type 30 interval
    accounting records; only when the task has come back into memory
    will the SMF interval record be written.  Now that we can
    synchronize type 30s with time of day, summarization of PDB.SMFINTRV
    with workloads defined by job name, account number, etc., becomes
    feasible, and is under development!

20. IBM Cache RMF Reporter Version 1.5 is required with MVS/ESA 4.3; if
    Release 1.4 is used, binary zeros are in configuration data fields.

21. APAR OW03158 implies a new 4-byte Date Opened Field (finally!) will
    be added to type 14/15 records, but there is no PTF yet, and I can't
    write the MXG code change to support it until there is!
    Online only update Aug 24, 1994: APAR OW00484 actually added the new
    field, which was supported by MXG Change 12.036, in MXG 12.01.


IV.   VM Technical Notes

 1. MXG 11.11 has been partially tested under CMS versions of SAS, but
    the standard BUILDPDB may not compile in a 12MB machine.  The
    REXXTES6 example was also revised to supply the VMXGINIT invocation.
    Currently, BUILDPDB with the recommendation of Change 11.067 to
    remove CICS and DB2 processing does successfully execute under CMS
    SAS.  The installation instructions have not been rewritten for CMS.

 2. SAS Version 6 data libraries created by MVS SAS cannot be read
    directly by CMS SAS from a volume shared between MVS and CMS.  CMS
    SAS sites who want to build their PDB under MVS and then access the
    PDB from CMS for reports/graphs must build the PDB in Version 5
    format (by specifying LIBNAME PDB ENGINE=V5).  Alternatively, build
    the PDB under Version 6 in Xport format, (by specifying LIBNAME PDB
    ENGINE=V6SEQ;), and then import the library into CMS, creating a
    separate CMS file for each data set in the library, and obviously
    requires twice the DASD space:
          LIBNAME PDB V6SEQ 'C';
          CMS FD PDB C DSN SYS1.MXG.PDB;
    The only other alternative is to use SAS/SHARE on both MVS and CMS
    to share the PDB.  See SAS Usage Note V6-SYS-SASIO-2172 for details.

V.    CICS Technical Notes
 1. Truncated type 110 Statistics records written by CICS/ESA are now
    corrected by APAR PN39841.  They were detected by MXG and deleted.

VI.   SAS Technical Notes

 1. CRITICAL ZAP Z6088203 REQUIRED for MVS sites at TS405 or TS407.

    Sites with SAS 6.08 at TS405 or TS407 Level (under MVS only) must
    immediately install Critical Zap Z6088203.  Without this ZAP, very
    large Data steps (specifically, BUILDPDB's SMF-reading data step)
    can generate specious MXG ERRORs, such as INVALID OMVS TRIPLET
    messages, and/or INPUT STATEMENT EXCEEDED RECORD LENGTH conditions,
    and/or fractional/wrong values for integers.  In all reported
    occurrences thus far, the job ABENDed, but that is not guaranteed.

    SAS Maintenance installed in TS405/TS407 for MVS did not initialize
    numeric variables correctly, and the text of 8203 reads:
       "when the sum of the lengths of the constants in a DATA step are
       between 32K and 40K and the number of non-retained numeric
       variables exceeds 160, it is possible that the numeric variables
       may contain garbage values when they should be missing."

    Thus far, the error has occurred only when BUILDPDB has been
    "tailored" to read additional SMF records.  My untailored BUILDPDB
    did not produce any error, but adding just one SMF record (albeit
    complicated) increased the program size enough to cause the failure.
    Nevertheless, I strongly recommend installation of this ZAP at all
    MVS sites with TS405/TS407 - the cure is easy, the disease fatal!

*****THIS IS AN ABSOLUTELY CRITICAL ZAP - DO NOT OVERLOOK THIS NOTE****

    The ZAP became available for download from SAS Institute on Feb 2,
    and has corrected the problem at 6 sites, with no induced problems.
    The logic error in the compiler has been fixed in source in time for
    automatic inclusion in SAS Maintenance Level TS410, due out later
    this year, so this ZAP will not be needed when TS410 is available.

 2. The erratic series of SAS errors (NOTSORTED condition when the data
    had just been sorted, HEADER LENGTH wrong, etc.), that ABENDed once,
    and wouldn't fail again, has finally been nailed down by techs at
    SAS Institute, because one user, ???  ???????????, at Iowa State
    University, was finally able to create a repeatable failure!  Zaps
    Z6076442 or Z6086442 are now available for down loading from SAS
    and they were on the "second" maintenance tape, TS407.  The actual
    error was the overlay of bit maps used by SAS to describe where data
    elements were located in the WORK file.

 3. When moving SAS Graphics catalogs, the only way to keep the graphs
    in the same order is to use PROC GREPLAY.  If instead you use PROC
    DOWNLOAD or CPORT, your graphs will be reordered based on the NAME
    of the graph, and we can only partially control the name of a graph.
    While you can specify NAME= parameter on the graphics procedure, the
    name you specify is given only to the first graph produced,  If more
    than one graph is produced, the name of subsequent graphs is your
    NAME suffixed with a number.  PROC DOWNLOAD and CPORT sort graphs in
    collating sequence before moving, so if you have more than 10 graphs
    of the same NAME=, the order becomes NAME NAME1 NAME10 NAME11 NAME2.
    Using PROC GREPLAY to move graphics catalogs is thus recommended!
      We need to be able to control the names of graphs. Left padding of
      the numbers with zeros, and numbering all names would work, but
      the ability to specify a GROUP at the same time as the NAME would
      also help; these suggestions have been made to SAS Institute.

 4. SAS 6.08 ABEND 0C4 in Function VG2LD at OFFSET 00009A has SAS ZAP
    Z6087606 now available that corrects the ABEND.

 5. SAS 6.08 and 6.07 can enter an SVC Wait state if an invalid VBS data
    record is found as the last record at a concatenation boundary.  SAS
    Usage Note 6810 discusses, and suggests to circumvent by  a) making
    the file with the bad record the very last concatenation, or  b)
    processing the individual files separately, or c) specifying on each
    DD statement  DCB=BUFNO=1.  The last circumvention is probably the
    best, as it inhibits the SAS read-ahead which is the real culprit
    here, but you do not want to normally specify only one buffer, as it
    will slow down normal processing.  This SAS error is a high-priority
    item, and a ZAP was to be available soon from SAS Institute.

 6. SAS USER ABEND 315 has occurred in an SMS environment in which Tape
    Mount Management saw a request for UNIT=TAPE, but converted that
    request to a DASD allocation (because the data set was expected to
    be small, and would be copied with many other small data sets from
    DASD to TAPE later by SMS).  A problem is open at SAS Institute, but
    it's not clear to me that this is a SAS problem, because in adding a
    SPACE=(CYL,(XX,YY)) parameter to the UNIT=TAPE DD works, and thus it
    appears that SMS is not properly allocating the data set!  A better
    alternative solution is to specify your Storage Class for tape
    (i.e., the one that will bypass SMS Tape Mount Management).  Still
    another choice is for your SMS guru to exclude program name SAS*
    from Tape Mount Management.  This note will change if more is known.

 7. Using an MVS PDSE library instead of an MVS PDS library for your MXG
    SOURCLIB requires SAS ZAP Z6077095 for 6.07, Z6087095 for 6.08 thru
    TS0405 maintenance; otherwise, you will get ERROR 180s.

 8. One site received a 'FORMAT MGxxxxx UNKNOWN', even though the job
    had the //LIBRARY format library properly built and connected.  It
    turns out the real problem was insufficient memory - increasing the
    MEMSIZE in CONFIG made the error go away!

VII.  IMS Technical Notes - Newsletter TWENTY-FIVE

      MXG Position on using only IBM IMS Log Records, updated 28Oct2010

 1. MXG has always stated that IMS sites must install an IMS monitor to
    accurately capture resources and responses for IMS transactions; the
    IMS log data written by IBM records only program resources and does
    not record transaction data for IMS accounting or capacity planning.

 2. MXG currently supports three IMS monitors: BMC's MVIMS, Mainview for
    IMS, previously Boole's IMS Measurement Facility, "IMF", product
    (supported in MXG member TYPECIMS, from its original name of
    Control/IMS), and ASG-Landmark's The Monitor for IMS, (member
    TYPETIMS), and IBM/Candle's IMS Transaction Reporting Facility,
    "ITRF" product (member TYPEITRF).  These IMS monitors "hook" IMS to
    capture and record both resource and response measurements for each
    transaction that are legitimate for accounting, performance tuning,
    and capacity planning.

 3. To IBM, the IMS log exists only for recovery of databases; it is not
    designed for transaction accounting nor response measurement.  What
    little resource accounting there is (only CPU and DL/I count, no I/O
    counts), exists only in the Program record, written when a program
    is de-scheduled, and each Program record contains totals for all of
    the transactions that were executed by that program schedule.  (IMS
    Wait-for-Input, WFI, programs can stay up all day and execute many
    thousands of transactions in one program record!)

    Some IMS log records are at the transaction level, but only for the
    response time, and as there is no unique token in those records that
    associates records with specific transactions, post-processing to
    assemble transaction events from log records is not guaranteable.
    This is the heart of the exposure in the post-processing-algorithms
    of ASMIMSL6.

       In contrast, in batch and TSO we have the READTIME-JOB token,
       and in CICS and DB2 we have the NETSNAME-UOWID token with which
       to identify all records caused by a specific transaction, but
       no such token is provided in IBM's IMS log records.

 4. In addition to full support for the three IMS monitors' records, MXG
    has also provided algorithms that attempt, successfully so far, to
    reconstruct IMS transactions using only the IBM-provided IMS log
    records, with the ASMIMSL6 Assembly Language program and JCLIMSL6
    multi-step job.

    Only a handful of sites ever reported any discrepancies in ASMIMSL6,
    and they tended to be the sophisticated IMS sites with very complex
    transaction sequences, and they have questioned response measures,
    and not the resource measures. (And without an independent measure
    of response, it's hard to show that ASMIMSL6 is actually at fault!)
    Total CPU time, DL/I calls, and the count of transactions have been
    correct and usable.  These sites simply discard the transactions
    with unrealistic response measures (too large or negative), tracking
    to see that the number of discarded transactions is small.

    Furthermore, IMS SAP accounting and IMS059 Fast Path datasets come
    from independent log records, and are thus independently usable.

    Officially, I do NOT have a legal obligation to modify the existing
    ASMIMSL6 program's post-processing algorithms until IBM provides an
    auditable and unique per-transaction token in each IMS log record
    that eliminates the need for that ASM program.  And, even with a new
    unique transaction token, until IBM also provides per-transaction
    level counts of CPU time, DL/I calls, and physical I/O, even with
    ASMIMSL6/JCLIMSL6, the IBM IMS log records will never be completely
    accurate for billing or response investigations.
    Fortunately, this has not been issue, since JCLIMSL6/ASMIMSL6 have
    worked with every IMS Version, including IMS Version 11 in 2010.


VIII. Incompatibilities and Installation of MXG 11.11.

 1. Incompatibilities

 a. MXG's summarization member, %VMXGSUM was changed incompatibly, but
    it should affect only the very small number of (sophisticated) users
    who have tailored MXG summarization/trending members:

    If any of these members exist in your USERID.SOURCLIB(s) libraries:
          ASUMDBDS ASUMDB2A ASUMDOS  ASUMHPCS ASUM70PR
          DAILYDSN GRAFDB2  GRAFLPAR TRNDDB2A
    or if you use %VMXGSUM in your own report/summarization programs,
    then you MUST read the details in Change 11.309 and you will need to
    re-tailor your changes.

    The incompatibility is somewhat obscure; to reduce CPU time and to
    minimize temporary DASD space used during summarization, %VMXGSUM
    now determines which variables are needed, and keeps only the needed
    variables from the input data set.  The problem arises only if you
    use the INCODE= parameter (it lets you insert SAS code into the
    summarization logic, and is used in those nine members), and even
    then, only if you reference variables in your INCODE= logic that are
    not going to be kept in the output summarized dataset.  In that rare
    case, you must list those un-kept variables in the new KEEPIN= parm.
    The above members in MXG 11.11 contain the needed KEEPIN= statement.
    (If you overlook this note, you still should detect the problem in
    your testing, because you will normally see UNINITIALIZED VARIABLE
    messages on the SAS log to alert you to your error!)

 b. Make sure you are using the CONFIG member from the MXG 11.11 library
    in your JCL, either with the MXGSAS JCL Procedure, or on your EXEC:
        // EXEC SAS,CONFIG='MXG.V1111.SOURCLIB(CONFIG)'
    You will get many, strange syntax errors (ERROR 180 or 200) if you
    do not use the MXG 11.11 CONFIG member.

    If you are migrating to MXG Version 11.11 from MXG Version 9.9 or
    earlier, AND you have tailored your MXG installation (with EX...  or
    IMAC.... members), you must read the MXG 10.10 compatibility section
    in member CHANGESS; find the text "member=CHANGE10" and read on!

 c. MXG Version 11.11 requires SAS Version 6.08 at maintenance TS407,
    plus SAS Zaps Z6088203 and Z6086442 for MVS and CMS.  For WINDOWS,
    SAS 6.08 at TS407 is required.  For all UNIX, except for AIX, SAS
    6.09 is required.  For AIX, the second maintenance to 6.09 will be
    required.  For OS/2, SAS 6.10 will be required.  (Both AIX and OS/2
    do not currently properly support VBS record processing; their fixes
    are due out this summer.)  MXG has been tested error-free with the
    above SAS versions, and I strongly suggest you ensure that your SAS
    System is at the above level of SAS maintenance.  (While most of MXG
    may execute successfully with lower maintenance, you may encounter
    known errors if you are not at the above level.)

 d. Observation counts may change in PDB.JOBS and PDB.NJEPURGE because
    of Change 11.226.  More observations may be seen in PDB.TYPE74 due
    to Change 11.170.

 2. Installation and re-installation procedures are described in detail:
    in member INSTALL, and sample JCL is in member JCLINSTL.  Summary:
     a. Install member MXGSAS as JCL Procedure MXGSAS in your PROCLIB.
     b. Allocate a 78-cyl PDS: MXG.V1111.MXG.SOURCLIB, and use IEBUPDTE
        to read the MXG tape to create the 2000+ member Source Library.
     c. Allocate a 1-cyl PDS:  MXG.V1111.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 V1111.USERID.SOURCLIB.
     d. Allocate a 1-cyl SAS Data Library:  MXG.V1111.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.V1111.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.V1111.USERID.SOURCLIB. Then compare your
        IMACs with those that were changed (see the alphabetical list of
        changed members in member CHANGES).  If any members in your
        MXG.V1111.USERID.SOURCLIB were changed, you must reinstall your
        site's tailoring for that IMAC, starting with the IMAC member
        from the MXG 11.11 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 11.11 in its own set of libraries.  When
     parallel testing is complete and are ready to implement MXG 11.11
     in production, rename your three current MXG Production Libraries
     (MXG.MXG.SOURCLIB, MXG.USERID.SOURCLIB, and MXG.MXG.FORMATS) to
     (MXG.BACK.MXG.SOURCLIB, MXG.BACK.USERID.SOURCLIB, MXG.BACK.MXG....)
     and rename the MXG.V1111.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:" and  "ERROR :"  and
"UNINITIALIZED" and "NOT CATLGD", as they may indicate a serious error.

A PROC PRINT and a PROC MEANS of each new MXG-built SAS dataset can help
you to understand their contents, and should be used to examine any
unusually large, negative, or suspicious values.  Print all variables in
the dataset, and read the variable's descriptions in its ADOC member.

IX.   Documentation of MXG Software.

Member CHANGES identifies the Version and Release of MXG Software, and
describes all changes made in that Release.  The text of each change
names the members that were added or altered by that change.  Member
CHANGES is designed to be read online (with SPF BROWSE), so that you can
search for specific product name references (CICS, MVS/ESA, etc.), or
the MXG member name or product acronyms.

Member CHANGESS contains ALL changes in ALL versions of MXG.

Member NEWSLTRS contains the text of all newsletters.  You can search
NEWSLTRS for product name or acronym to find the technical notes, APARs,

etc., from all MXG newsletters.  Since the Change Log portion of each
newsletter is in member CHANGESS, they are not repeated in NEWSLTRS.
The MXG Technical Newsletter is typically published twice a year, with
one printed copy sent to each licensed site, and it describes changes
and enhancements to the software, provides APARs and PTFs affecting MXG
users, and provides technical papers of interest to MXG users.

Member DOCVER lists alphabetically ALL datasets and variables that are
built by this MXG Software Version.

Members DOCVERnn are the "delta-documentation" between MXG versions, and
list only those datasets and variables that were added/deleted/changed
by version "nn".

Members ACHAPxxx are the text chapters from the 1984 MXG Guide and the
1987 MXG Supplement, to which the text of newsletters and changes has
been added.  At present, these chapters are very rough; in a few cases
the chapter has actually been completed and revised, but most of these
chapters delivered in MXG 11.11 are little more than a concatenation of
the original text, and there are no figures nor tables.  This is clearly
work in progress, but at least the old books are now machine readable!
When all 42 chapters are completely revised and updated in the source
library, I will decide if any will also be made available in printed
form, but the primary source of all future documentation will be the MXG
source library itself, which can now be updated when changes occur!

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 datasets, references to MXG reports that use these
datasets, and the MXG member names that you use to process that product.
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:

  IMACxxxx - Defines record IDs, and "_K,_L" macros for product xxxx.
  ADOCxxxx - "Chapter FORTY" style dataset and variable documentation.
  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 each dataset.  There can be more than one
             dataset per product.  The EX member name suffix yyyzzz is
             the same as the suffix of "_L" and "_K" macros defined in
             IMACxxxx for the product.  See further discussion under
             "Using the MXG Exit Facilities" 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.

Finally, remember that MXG is source code, so you can often find your
answer by BROWSING the source members, especially the VMACxxxx, ANALxxxx
members.  The MXG Variable name is often the DSECT's field name, and if
not, the vendor's field name is often in adjacent comments in the INPUT,
so you can cross reference to the vendor's documentation of their data!

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 that described in the change text (which might have printed
 only the critical part of the correction that can be made by paper).

 Scan each source member named in any impacting change for any comments
 at the beginning of the member for additional documentation, since the
 documentation of new datasets, variables, validation status, and notes,
 are often found in comments in the source members.

Alphabetical list of important changes since MXG 10.10:

  Member    Change   Description

  All      11.150  Rewrite to support execution under ASCII SAS versions
  ANALCISH 11.329  CICS/ESA DFHSTUP Shutdown Statistics Reports added.
  ANALDASD 11.288  Sample prime-time cross-system DASD report.
  ANALDB2R 11.007  Fails with PDB=SMF if account reports suppressed.
  ANALDB2R 11.036  Suspension counts twice actual value.
  ANALDB2R 11.037  Total Read IOs miscalculated on Statistics Summary
  ANALDB2R 11.042  DB2 PMACC02 count of OPENS actually counted FETCHES.
  ANALDB2R 11.043  DB2 PMSTA02 count of SUSPENDS usually zero.
  ANALDB2R 11.143  OVERFLOW HAS OCCURRED, OUT OF MEMORY errors.
  ANALDB2R 11.286  Continued enhancement and error corrections.
  ANALDB2R 11.330  DB2 Audit Detail Report Completion Code still wrong.
  ANALDSET 11.048  ERROR 455-185 for dataset TYPE30OM.
  ANALDSET 11.291  TYPE64 records now sorted consistent with non-VSAM.
  ANALRACF 11.260  UNINITIALIZED variable due to SAS Usage note 6886.
  ANALRMFR 11.024  Report fails with PDB=SMF, works with PDB=PDB.
  ANALRMFR 11.069  Continued enhancement of RMF look-a-like reports.
  ANALRMFR 11.231  Additional RMF report enhancements and corrections.
  ANALRMFR 11.256  Correction of CPU percentages and type 74 reports.
  ANALSMF  11.300  The "Simulator" analyzes SMF VSAM CI Size impact.
  ASMIMSLG 11.157  IMS log processing type 36 changed.
  ASMTMNT  11.154  0C4 abend in MXGTMNT at one site.
  ASMVTOC  11.257  No output records under MVS/ESA 4.2 and earlier.
  ASUM70PR 11.022  PDB.RMFINTRV may be corrupted by ASUM70PR.
  ASUM70PR 11.027  LP0MGTTM not in RETAIN list (affects only MDF)
  ASUM70PR 11.041  ASUM70PR new variables, and mini-tutorial.
  ASUM70PR 11.087  LP0MGTTM (Amdahl MDF only) incorrect.
  ASUM70PR 11.145  ASUM70PR still wrong in MXG 11.03.
  ASUMAPAF 11.290  Summarization of MDF APAF records similar to PR/SM.
  ASUMDB2A 11.038  QTXAIRLM omitted from SUM= list
  BUILD006 11.320  PDB logic enhanced for APPC tasks (no purge record).
  BUILDPDB 18.094  Building your PDB on tape.
  BUILDPDB 11.089  Purge records lost if PRPRTY=4-7 or 12-15.
  BUILDPDB 11.226  JES2 NJE Purge records for JT were mis-recognized.
  BUILDPDB 11.228  Open Edition/MVS (OMVS) TYPE30OM added to PDB.
  BUILDPDB 11.269  PDB.JOBS ACCOUNTn/RESTARTS wrong for MULTIDD jobs.

  BUILDPDB 11.320  PDB logic enhanced for APPC tasks (no purge record).
  CHANGESS 11.074  New member CHANGESS contains ALL changes ALL Versions
  CICINTRV 11.224  CICS "Requested Reset Statistics" now processed.
  CLTIMER  11.035  STOP statement required by SAS Version 6.
  CONFIG   11.306  For MVS, MEMSIZE=32MB now default value.
  CONFIG07 11.129  SAS Error 76-322 with numbered + unnumbered lines.
  DAILYDSN 11.076  Typos misspelled output datasets.
  DIFFDB2  11.282  New dataset PDB.DB2STATS now created for reports.
  DIFFHSM  11.019  Member did not use the "_L" macro names.
  Doc      11.013  Change 10.175 typo, two _KTY0 should be _LTY0
  FMXGUCBL 11.088  Archaic UCBL function corrected.
  GRAFLPAR 11.079  Error "OUT OF MEMORY" due to SAS Error 6719.
  GRAFTRND 11.216  Not all workload data was plotted if workload unused.
  GRAFWORK 11.311  Workload graphs enhanced with memory frames in use.
  GRAFxxxx 11.173  Enhancements, common structure for GRAFxxxx members.
  IMACACCT 11.104  "VARIABLE SACCT1 NOT FOUND" can occur.
  IMACCICS 11.224  "CICRRTRV NOT FOUND" errors using old IMACCICS
  IMACICBB 11.347  Support for Boole & Babbage CICS Manager Statistics.
  IMACICDL 11.268  Omegamon CICS/ESA type 110 may have wrong DL/I counts
  IMACICSA 11.110  Support for SAP Releases 4.3.J and 5.0.
  IMACICSA 11.148  SAP Release 4.3 requires one change to MXG.
  IMACICSA 11.211  CICS SAP variables STCDB1-STCDB5 should be CHAR.
  IMACPDB  11.155  ACCOUNTn variables no longer limited in IMACPDB.
  IMACPDB  11.214  JES3 variable CLASS added to JES3 PDB.JOBS.
  IMACPDB  11.258  Variables ACTDLYTM,DSPDLYTM,RESDLYTM now in PDB.JOBS
  JCLIMSLG 11.109  MXG 10.10 had wrong JCL in this example JCL member.
  JCLTEST  11.012  SAS 5.18 WORK.#DIRMACR is out of space condition.
  JCLTEST6 11.093  0C4 ABEND in SASXKERN if IBM exit IFGOEXOB used.
  MONTHBLD 11.040  Error "DATASET TAPEMNTS NOT SORTED".
  MONTHBLD 11.206  DATA SET TAPEMNTS IS NOT SORTED error.
  Many     11.302  Additional ASCII/EBCDIC differences resolved.
  RMFINTRV 11.008  TYPE74 tape counts in AVGRSPMS, DEVACTTM, etc.
  RMFINTRV 11.264  Variable PGPERBLK in RMFINTRV is incorrect.
  SPIN     11.184  SPIN library can fill if Change 11.060 not installed.
  TRND70   11.240  Trended variables READY12-READY15 have wrong value.
  TRND71   11.222  Variable VIO value incorrect in TRND71.
  TRNDDB2A 11.038  QTXAIRLM omitted from SUM= list
  TRNDVMXA 11.235  VM/ESA Trending had logic errors.
  TRNDxxxx 11.227  Trending now includes the MVS/ESA 4.3 variables.
  TYPE102  11.085  Variables QW0145SC/QW0145LL not input.
  TYPE102  11.107  IFCID 53 and 58 records may have been dropped.
  TYPE110  11.023  Omegamon V550 APAR QOC0451/QOC0534 bad record error.
  TYPE110  11.080  STARTIME in CICINTRV dataset is actually ENDTIME.
  TYPE110  11.138  Skip over SAP Journal Records circumvention.
  TYPE1415 11.266  Variable TEMP in dataset TYPE1415 may be misset.
  TYPE28   11.116  Support for NPM APAR OY54370.
  TYPE28   11.246  Support for NPM Version 2.1.0
  TYPE30   11.002  INVALID OMVS TRIPLET message, no observations.
  TYPE30   11.003  Type 30 Interval INTBTIME/INTETIME wrong in MVS 4.3.
  TYPE30   11.004  Variable DSSIZHWM is incorrect.
  TYPE30   11.033  Small negative values for ACTDLYTM.
  TYPE30   11.060  JELAPSTM and others large (positive or negative).
  TYPE30   11.126  Type 30 APPC fields accumulation corrected OY63634.
  TYPE30   11.140  Asynchronous Data Mover read/writes in APAR OY65142.
  TYPE30   11.199  Variables INTBTIME/INTETIME off by 100 seconds.
  TYPE30   11.229  GMT Offset was still wrong sometimes, by 100 seconds.
  TYPE33   11.243  Support for NETWISE RPC EXEC type 33 SMF record.
  TYPE37   11.001  INPUT STATEMENT EXCEEDED RECORD LENGTH
  TYPE37   11.031  Undocumented LAN variables BRFSMADR BRFSMNAM added.
  TYPE37   11.119  INPUT STATEMENT EXCEEDED RECORD LENGTH.
  TYPE37   11.202  Support for NETVIEW APAR OY66237 (Hardware Log).
  TYPE39   11.280  TYPE39_8 variables all incorrect.
  TYPE42   11.021  New TYPE42DS has GMT values in INTERVAL record.

  TYPE42   11.179  Support for Concurrent Copy & Extended Sequential DS.
  TYPE42   11.235  Support for IBM's ADSM subtype 14 type 42 SMF record.
  TYPE42   11.325  TYPE42 subtype 6 STOPOVERs if VSAM SMF data is read.
  TYPE57   11.215  Type 57 ESS variables non-blank if no ESS installed.
  TYPE60   11.203  Storage and Data Class missing in NVR TYPE60 records.
  TYPE6156 11.223  INVALID DATA for OWNEXPDT corrected.
  TYPE7072 11.016  TYPE72MN dataset contains only one PERFGRP.
  TYPE7072 11.152  TYPE70 dataset now supports CPUIDs of 0 thru 15.
  TYPE7072 11.229  GMT Offset was still wrong sometimes, by 100 seconds.
  TYPE7072 11.265  Boole CMF Type 72 Subtype 2 INPUT STATEMENT EXCEEDED.
  TYPE7072 11.275  IBM APAR OY67002 corrupts TYPE70,TYPE70PR,ASUM70PR
  TYPE72   11.177  SERVICE can be zeroed if it overflows ==> zero obs!
  TYPE72MN 11.171  Zero obs in TYPE72MN for MVS/ESA 4.2 or earlier.
  TYPE73   11.015  TYPE73 contains observations for dummy CHPIDs
  TYPE73   11.102  Zero observations in TYPE73.
  TYPE73   11.114  PNCHANBY (EMIF Partition Channel Busy) added.
  TYPE73   11.195  Variable PNCHANBY propagated into inactive records.
  TYPE74   11.170  TYPE74 not output if only allocated but not used.
  TYPE80   11.117  Support for Top Secret Release 4.3.
  TYPE80   11.207  Support for TOP-SECRET records written to log.
  TYPE80A  11.017  INPUT STATEMENT EXCEEDED error.
  TYPE80A  11.054  TYPE80A fails with INPUT STATEMENT EXCEEDED.
  TYPE90   11.158  TYPE90 variable ACTIVE renamed to ACTIVEMN.
  TYPEACF2 11.315  Support for CA's ACF2 Releases 6.0 and 6.1.
  TYPEAICS 11.180  Support for AICorp Central Server SMF record.
  TYPEAPAF 11.225  Support for Amdahl APAF Version 2.1
  TYPEAPAF 11.267  APAF V2.1 dataset APAFCHAN was trashed.
  TYPECIMS 11.073  INVALID VALUE FOR TH corrected.
  TYPECOMP 11.156  COM-PLETE Release 4.5 SMF record supported.
  TYPECOMP 11.209  Variable ULOGCPUT incorrectly input.
  TYPECTLD 11.174  Support for 4th Dimension's CONTROL-D Release 3.0.0.
  TYPEDB2  11.005  INVALID 3rd ARGUMENT IN SUBSTR, variable JOB blank.
  TYPEDB2  11.006  Variable QDSTQDBT is incorrect.
  TYPEDB2  11.050  DB2ACCT variable NETSNAME incorrectly padded.
  TYPEDB2  11.255  Support for DB2 Version 3.1 incompatible changes.
  TYPEDCOL 11.057  DCOLLECT SMSDATA (SMS constructs) cause STOPOVER.
  TYPEDCOL 11.151  Variables DCUSYSID/DCUTMSTP not kept in constructs.
  TYPEDLMN 11.308  Support for Candle's Deltamon SMF record.
  TYPEDMON 11.162  Support for LEGENT's ASTEX Release 1.7.
  TYPEDOS  11.106  Support for DOS/VSE POWER 5.1.
  TYPEDOS  11.149  Variables STARTIME/STOPTIME may be wrong.
  TYPEEDGR 11.190  Support for DFSMSrmm Extract Files (EDGHSKP utility).
  TYPEEDGS 11.189  Support for DFSMSrmm SMF Audit and Security records.
  TYPEEDGS 11.209  Several MVT... variables incorrectly input.
  TYPEF127 11.210  FACOM pseudo-RACF type 127 FUNCTION CHAN IS UNKNOWN.
  TYPEFOCU 11.219  Support for FOCUS MSO Release 6.8.
  TYPEHMF  11.049  Support for HMF, Host Monitoring Facility product.
  TYPEHSM  11.078  New HSM dataset HSMFSRBO, IMACHSM changed.
  TYPEICE  11.340  Support for STK's ICEBERG SMF record.
  TYPEIMS  11.181  Support for SAP's IMS log record type 'AE'.
  TYPEIPAC 11.252  Support for Mobius' INFOPAC-RDS user SMF record.
  TYPEMEMO 11.032  New variables TRANTIME TRANCOST added.
  TYPEMIM  11.317  Partial support for LEGENT's MIM Release 4.0.
  TYPEMON8 11.230  INVALID ARGUMENT TO FUNCTION MDY  TIESDATE INVALID.
  TYPEMON8 11.270  Support for Landmark CICS/ESA Version 1.1 INVALID DO.
  TYPEMON8 11.278  ERROR3.LANDMARK.MONITOR due to invalid record.
  TYPEMON8 11.327  INVALID DATA FOR TIAPREQ with MXG 11.0x-11.10.
  TYPENDM  11.175  Support for Sterling NDM Network Data Mover 1.4.0.
  TYPENDM  11.326  Sterling's NDM, now Connect Direct 1.7.01, incompat!
  TYPENSPY 11.009  INVALID ARGUMENT TO FUNCTION DATEJUL error.
  TYPENSPY 11.029  Variable SNITIME incorrect.
  TYPENSPY 11.130  LEGENT LANSPY #DGL249 circumvention.
  TYPENSPY 11.159  NETSPY fix changed again by LEGENT.

  TYPENSPY 11.316  Support for LEGENT's NETSPY Release 4.4.
  TYPEODS  11.147  Support for Laser Access Corp's Optical Disk System
  TYPEOMAU 11.092  Omegamon 2.60 Audit Record moved OMSUBSID.
  TYPEOMCI 11.115  OMEGAMON V550 SMF record INPUT STATEMENT EXCEEDED.
  TYPEOMCI 11.136  OMEGAMON/CICS VSAM,DLI,ADABAS,IDMS,SUPRA,DATACOM.
  TYPEOMCI 11.313  OMEGAMON user SMF record INPUT STATEMENT EXCEEDED.
  TYPEOMSM 11.332  Support for Candle's Omegamon II for SMS user record.
  TYPEOPC  11.122  Variables added to OPC24_6 and OPC24D_C datasets.
  TYPEOPC  11.304  Support for OPC/ESA Release 2.1.
  TYPEPOOL 11.141  INPUT STATEMENT EXCEEDED LENGTH with POOL/DASDSMF.
  TYPEPRFS 11.262  Support for Softworks' Performance Solution SMF data.
  TYPEQAPM 11.166  Support for AS/400 Release 2.2, all records now!
  TYPEQAPM 11.254  Support for AS/400 Version 2.3 Performance Data.
  TYPEQAPM 11.319  AS/400 system name AS400SYN was blank.
  TYPESAR  11.146  Support for LEGENT's SAR product SARSRQU3 SMF record.
  TYPESFS  11.250  Xerox SFS accounting record INVALID ARGUMENT error.
  TYPESFTA 11.321  Support for ISOGON's SoftAudit externalized files.
  TYPESTC  11.124  Missing values for several variables corrected.
  TYPESYNC 11.056  Support for SYNCSORT Release 3.5 new variables.
  TYPETAO  11.034  "INVALID DATA FOR TAOSTYP" messages.
  TYPETCP  11.028  TCP/IP addresses reformatted.
  TYPETCP  11.163  Support for TCP/IP 2.2.1 APAR PN40511 new fields.
  TYPETPX  11.167  Support for LEGENT's TPX Release 3.5 (incompatible).
  TYPEVM   11.113  Support for VM/ESA Release 2.1 Accounting record.
  TYPEVMXA 11.047  VM/ESA "UNEXPECTED/INVALID CONTROL RECORD" message.
  TYPEVMXA 11.112  Support for VM/ESA Release 2.1 Monitor records.
  TYPEVMXA 11.142  VM/ESA duration variables could be truncated.
  TYPEVMXA 11.261  VXSYTCPU dataset variable LCUCLPTM not kept.
  TYPEVVDS 11.103  Blank values for SMS Storage, Data, etc., Classes.
  TYPEVVDS 11.204  Variable VVRBSENM can be blank.
  TYPEX37  11.070  STOPX37 Release 3.5 records incorrectly documented.
  TYPEX37  11.091  Variable MESSAGE not decided in STOPX37 Rel 3.5.
  TYPEX37  11.133  STOPX37 undocumented VOLSER,MSGCODE found.
  TYPEZARA 11.059  Support for ZARA, The Tape Media Manager from Altai.
  TYPEZARA 11.276  Support for ZARA Release 1.1 (incompatible)
  UCICSCNT 11.244  Utility to count type 110 records by application.
  VMACDB2H 11.242  DB2 variable NETSNAME can still mismatch CICSTRAN.
  VMXGHSM  11.131  HSM BCDS dataset MCB incomplete, too few obs.
  VMXGHSM  11.194  Not all observations output in dataset DSR.
  VMXGHSM  11.259  HSM BCDS and MCDS data value errors.
  VMXGSUM  11.281  Performance enhancement of MXG summarization
  VMXGSUM  11.309  Execution improved by creating KEEP= for input.
  VMXGSUM  11.309  INCOMPATIBLE exposure if you have tailored members.
  VMXGVTOF 11.030  Variable DS4IVTOC was not kept.
  WEEKBLD  11.040  Error "DATASET TAPEMNTS NOT SORTED".
  WEEKBLD  11.206  DATA SET TAPEMNTS IS NOT SORTED error.
  WEEKBLDT 11.172  WEEKBLD with no rewinds/remounts of WEEK tape.

Inverse chronological list of all Changes:

==Changes 11.347 thru 11.141 were printed in Newsletter TWENTY-FIVE==
==Changes 11.140 thru 11.001 were printed in Newsletter TWENTY-FOUR==

****************NEWSLETTER TWENTY-FOUR**********************************











              MXG NEWSLETTER NUMBER TWENTY-FOUR August 2, 1993

Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE

                         TABLE OF CONTENTS
                                                                    page
I.    MXG PreRelease 11.03 available Upon Request                      2

II.   MXG Technical Notes                                              3

III.  MVS Technical Notes
      1. DFP 3.3 APAR OY59794 adds VSAM free space info to DCOLLECT    3
      2. Type 94 SMF (3495 Tape Library) APAR OY60348                  3
      3. DCOLLECT APAR OY50194 corrects trashed size of large datasets 3
      4. JES2 Type 24 SMF invalid ESS triplet                          3
      5. NETSPY line utilization correction zaps.                      3
      6. CMF type 72 subtype 2 invalid data fixed by BPM4494.          3
      7. PR/SM analysis variables in ASUM70PR mini-tutorial            3

IV.   VM Technical Notes                                               4

V.    CICS Technical Notes
      1. Landmark pseudo type 110 incorrect, APAR U805248.             4
      2. No CPU time TASCPUTM in CICSTRAN                              4

VI.   SAS Technical Notes
      1. OBJECT FILE OUT OF SPACE, Zap Z6076384                        4
      2. USER 315 ABEND if SMS Release Upon Close used.                4
      3. WAIT state if incorrect blocksize specified.                  5
      4. %MACRO compiler error, Usage Note 6719.                       5

VII.  Incompatibilities, Installation, and Space Requirements.
      1. No known incompatibilities in MXG 11.02                       5
      2. Installation instructions.                                    5

VIII. Documentation of MXG Software.                                   6

IX.   Change Log                                                       7
      Alphabetical list of important changes                         8-9
      Changes 11.140 thru 11.001                                    9-31



         COPYRIGHT (C) 1993 BY MERRILL CONSULTANTS DALLAS TEXAS

I.    MXG Software Status and Enhancements:

MXG PreRelease 11.03 is now available, free, upon request.  Note that no
tape was sent with this Newsletter.  MXG 11.03 corrects all known errors
in MXG 10.10-11.03 and has enhancements listed below.  While MXG 10.10
is quite robust, leading edge sites and sites with PR/SM environments
are well advised to replace MXG 10.10 with MXG 11.03.  Likewise, sites
that have not yet installed MXG 10.10 should go directly to MXG 11.03.
The "Production" Version 11 (i.e., the MXG Version that is produced and
shipped automatically to all MXG sites) is not scheduled until 1994.

  These major enhancements were added in MXG 11.03:

    Asynchronous Data Mover Facility APAR OY65142 for SMF type 30.
    OMEGAMON/CICS VSAM,DLI,IDMS,ADABAS,SUPRA,DATACOM SPE QOC0553
    Correction of all reported 11.02 errors.

  These major enhancements were added in MXG 11.02:

    Support for VM/ESA Release 2.1.
    Support for Top Secret Release 4.3.
    Support for NPM APAR OY54370.
    Support for RMF APAR OY64585.
    Support for SAP Releases 4.3.J and 5.0.
    Support for DOS/VSE POWER 5.1.
    Support for OMEGAMON 2.60 Audit Record changes.
    Support for APPC Deaccumulation APAR OY63634.

  These major enhancements were added in MXG 11.01:

    Support for ZARA, The Tape Media Manager from Altai.
    Support for SYNCSORT Release 3.5 SMF record.
    Support for HMF, Host Monitoring Facility user SMF record.
    Support for Corporate TIE user SMF record.
    Support for STOPX37 Release 3.5 mis-documentation.
    Enhanced ANALRMFR for RMF look-a-like reports from MXG.
    Validation of Candle's ITRF (Omegamon/IMS Version 110).
    Validation and correction of SMSDATA operand of DCOLLECT

    Each of those 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

      RMF 4.1.2 (for MVS/ESA 3.1.3)    Sep  7, 1990.        8.8
      RMF 4.2   (for MVS/ESA 4.1)      Oct 26, 1990.        8.8
      MVS/ESA 4.1                      Oct 26, 1990.        8.8
      MVS/ESA 4.2                      Mar 29, 1991.        9.9
      RMF 4.2.1 (for MVS/ESA 4.2)      Mar 29, 1991.        9.9
      MVS/ESA 4.2.2                    Aug     1991.        9.9
      RMF 4.2.2 (for MVS/ESA 4.2.2     Aug     1991.        9.9
      MVS/ESA 4.3                      Mar 23  1993.       10.5
      RMF 4.3.0 (for MVS/ESA 4.3       Mar 23  1993.       10.5
      CICS/ESA 3.2                     Jun 28, 1991.        9.9
      CICS/ESA 3.3                     Mar 28, 1992.       10.1
      DB2 2.2.0                                1990         8.8
      DB2 2.3.0                        Oct 28, 1991.       10.1
      VM/ESA  1.1.1                    Dec 27, 1991.       10.1
      VM/ESA  2.0                      Dec 23, 1992.       10.4
      VM/ESA  2.1                      Jun 27, 1993.       11.02

II.   MXG Technical Notes

III.  MVS Technical Notes

 1. APAR OY59794 for DFP 3.3 will add VSAM free space information to
    DCOLLECT records.  (This information is already in DFSMS 1.0).

 2. APAR OY60348 corrects duplicate type 94 SMF records from the 3495
    Tape Library Dataserver; the 3495 statistics were notified on the
    host on each of the paths, but MVS should have ignored the duplicate
    notifications on multiple paths and only written one record.

 3. APAR OY50194 corrects DCOLLECT data values for large datasets; if
    a dataset was over 72% of the size of a 3390, the value stored by
    DCOLLECT was trashed; the problem was noted first on SPOOL datasets,
    which had irrationally high (4GB) sizes.

 4. JES2 Type 24 SMF record has ESS triplet non-zero, but there is no
    ESS segment at the end of the record. Problem is open at IBM.

 5. Legent's NETSPY Zaps QN42062,QN42074,QN42097,QN42078, and QN42155
    are needed (in that order!) to correct invalid data in NETSPY NCP
    line utilizations from NetSpy-to-NetSpy data for NetSpy 4.2

 6. Boole and Babbage's CMF type 72 subtype 2 record contains invalid
    STARTIME and CYCLE values that are fixed by their change BPM4494.

 7. PR/SM and MLPF environments provide hardware utilization information
    in TYPE70PR dataset, but MXG member ASUM70PR should be executed to
    create dataset ASUM70PR for analysis and reporting, as it summarizes
    and enhances the PR/SM data.  Change 11.041 added new variables to
    ease understanding of the data:

      LPARCHG   - 'Y' if something changed in any LPAR
      LPnCHG    - 'Y' if something changed in LPAR n.
      LPnDUR    - LPAR n's "Up time" or "Availability time to execute
                  CPU", the sum of DURATM across all LCPUs in LPAR n.
                  This is the total seconds during which this LPAR could
                  have been CPU dispatched.  If an LPAR was IPLed as
                  a 3-engine MVS machine, in one hour it would have 3
                  hours of "Up Time".
      LPCTnBY   - Percent "Logically" Busy in LPAR n, equal to
                  100*LPnUPDTM/LPnDUR, the Partition CPU Dispatch
                  divided by the LPAR's "Up Time".  If a 3-engine LPAR
                  was dispatched for 60 minutes, it's LPCTnBY would be
                  33%.  This new variable describes how much the LPAR
                  was logically busy; the existing variable PCTL1BY
                  describes how much the LPAR was physically busy.  If
                  this same 3-engine LPAR was executing on a 5-engine
                  machine, it's PCTL1BY would be 20%, because that LPAR
                  was using 20% of the hardware while it used 33% of the
                  CPU time available to this LPAR.  See the example
                  below.
      LPCTnOV   - Percent "Logically" Busy in "LPAR Overhead"
                  100*LPnMGTTM/LPnDUR, to describe how much of the new
                  LPCTnBY was in LPAR management of this LPAR.

    The following example is real data from a 5-engine CEC (Central
    Electronic Complex, the preferred name for a "machine").  This CEC
    has three LPARs: LP1 has two engines (and is lightly used), LP2 has
    five engines, and LP3 has three engines.  ASUM70PR for one hour has:

             PARTNCPU  5          - Number of real engines in CEC
             DURATM    1:00:00.05 - Duration interval
             CPUACTTM  4:40:35.32 - Total CPU Dispatch, all engines
             CPUOVHTM    15:35.40 - Total CPU Overhead in LPARS
             LPPUPDTM     6:40.28 - Total "Physical" Overhead
             PCTCPUBY  93.53%     - CPUACTTM as a percent of hardware
             PCTOVHD    5.20%     - CPUOVHTM as a percent of hardware
             PCTPOV     2.22%     - LPPUPDTM as a percent of hardware

                          LP1            LP2            LP3
             LPnNRPRC     2              5              3
             LPnDUR       2:00:00.10     5:00:00.25     3:00:00.15
             LPnMGTTM        1:53.03        3:50.02        3:12.07
             LPnUEDTM        2:56.63     3:29:16.51       52:46.77
             LPnUPDTM        4:49.67     3:33.06.54       55:58.85
             LPCT1BY      4.02%          71.04%         31.10%
             LPCT1OV      1.57%           1.28%          1.78%
             PCTL1BY      1.61%          71.04%         18.66%
             PCTL1OV       .63%           1.23%          1.07%

             The LP2 has the same PCTL1BY as LPCT1BY because it can use
             all five engines, and its logical and physical utilization
             are the same.  The LP3, with only three engines available
             to its MVS, shows it is using 18.66% of the five hardware
             engines (PCTL1BY), but the new LPCT1BY also shows that this
             is actually 31.1% of the CPU time possible for those three
             logical CPUs available to LP3.

IV.   VM Technical Notes

V.    CICS Technical Notes

 1. Landmark The Monitor for CICS can optionally create pseudo type 110
    SMF records, but the records contain an incorrect value of zero for
    SMFPSSTY (it should be 1), causing zero observations in CICSTRAN.
    Landmark's open APAR is U805248.  Note that MXG recommends using the
    Landmark records directly (see member TYPEMON8) instead of creating
    the pseudo type 110 records and then using TYPE110, because of the
    double passing of the data, and because their pseudo type 110 does
    not contain all of the data values in their own record.

 2. Zero value for TASCPUTM in CICSTRAN can result for two reasons.
    First, your CICS Systems Programmer has to enable the CPU=YES
    parameter in the DFHMCT (Monitor Control Task) macro to cause IBM
    to record CPU time.  In CICS/ESA 3.3, IBM changed the default to
    CPU=NO, and many MXG sites suddenly found zero CPU time when they
    migrated to 3.3!
    Second, zero TASCPUTM has resulted from MVS STIMER errors that are
    reported in APAR OY55060 and fixed in PTF UY89942.

VI.   SAS Technical Notes

 1. Error "OBJECT FILE OUT OF SPACE, OUT OF MEMORY" or 0C4 ABEND in
    SAS 607 repaired by SAS Zap Z6076384.

 2. Error USER 315 ABEND occurs in System Managed Storage, if //WORK
    (or any DISP=NEW data library) is in a Storage Class that specifies
    "RELEASE UPON CLOSE", because SAS issues multiple OPENs.  SAS has an
    accommodation, or special consideration, ZAP Z6072705, which
    bypasses the multiple opens of the //WORK dataset.  (If you specify
    RLSE in your JCL, SAS detects that environment, and also avoids the
    multiple OPEN, but SAS Institute has not found a way to recognize
    SMS's "RELEASE UPON CLOSE").

 3. Incorrect blocksize (one that is not a multiple of 512) for //WORK
    library can put SAS into a WAIT state.  The specific case was the
    processing of VMXGVTOF; all datasets were built ok in the work file,
    but the PROC COPY went into the WAIT state.

 4. SAS 6.08 %MACRO compiler has a known error, described under SAS
    Usage Note 6719.  Only GRAFLPAR failed, and Change 11.079 provides
    an MXG circumvention until SAS has a ZAP for the problem.

VII.  Incompatibilities, Installation, and Space Requirements.

 1. Migrating to MXG Version 11.03 from MXG Versions 10.2 thru MXG 10.10
    or from MXG 11.01 has no known incompatibilities, and installation
    has been reported to be the easiest yet!

    If you are migrating to MXG Version 11.03 from an MXG Version prior
    to MXG 10.2, and you have tailored your MXG installation (with EX...
    and IMAC.... members), you must read the compatibility section of
    member CHANGE10.

    MXG Version 11.03 has been tested under both SAS 6.07 and SAS 6.08;
    there appears to be no significant performance difference between
    SAS 6.07 and SAS 6.08.

 2. Installation and re-installation procedures are described in detail:
    in member INSTALL, but they are summarized here:

     a. Install member MXGSAS as JCL Procedure MXGSAS in your PROCLIB.
     b. Allocate a 75-cyl PDS: MXG.V1103.MXG.SOURCLIB, and use IEBUPDTE
        to read the MXG tape to create the 2000+ member Source Library.
     c. Allocate a 1-cyl PDS:  MXG.V1103.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 V1103.USERID.SOURCLIB.
     d. Allocate a 1-cyl SAS Data Library:  MXG.V1103.MXG.FORMATS and
        execute SAS to create the library of Formats required by MXG.

        Sample JCL for steps b-d is contained in member JCLINSTL.

     e. If this is the initial install of MXG, tailor these members into
        your MXG.V1103.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.V1103.USERID.SOURCLIB. Then compare your
        IMACs with those that were changed (see the alphabetical list of
        changed members in member CHANGES).  If any members in your
        MXG.V1103.USERID.SOURCLIB were changed, you must reinstall your
        site's tailoring for that IMAC, starting with the IMAC member
        from the MXG 11.03 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 11.03 in its own set of libraries. When
     parallel testing is complete and are ready to implement MXG 11.03
     in production, rename your three current MXG Production Libraries
     (MXG.MXG.SOURCLIB, MXG.USERID.SOURCLIB, and MXG.MXG.FORMATS) to
     (MXG.BACK.MXG.SOURCLIB, MXG.BACK.USERID.SOURCLIB, MXG.BACK.MXG....)
     and rename the MXG.V1103.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:" and  "ERROR :"  and
"UNINITIALIZED" and "NOT CATLGD", as they may indicate a serious error.

A PROC PRINT and a PROC MEANS of each new MXG-built SAS dataset can help
you to understand their contents, and should be used to examine any
unusually large, negative, or suspicious values.  Print all variables in
the dataset, and read the variable's descriptions in its ADOC member.

VIII. Documentation of MXG Software.

Member CHANGES identifies the Version and Release of MXG Software, and
describes all changes made in that Release.  The text of each change
names the members that were added or altered by that change.  Member
CHANGES is designed to be read online (with SPF BROWSE), so that you can
search for specific product name references (CICS, MVS/ESA, etc.), or
the MXG member name or product acronyms.  Member CHANGESS contains all
changes in all MXG versions.  Member CHANGEnn is a copy of the CHANGES
member that was shipped in MXG version nn.

Member NEWSLTRS contains the text of all newsletters.  You can search
NEWSLTRS for product name or acronym to find the technical notes, APARs,
etc., from all MXG newsletters.  The Change Log pages of each Newsletter
are in member CHANGESS and are not repeated in member NEWSLTRS.

Member DOCVER lists alphabetically ALL datasets and variables that can
be build by this MXG Software Version.  "Delta-documentation" between
MXG versions, which lists only those datasets and variables that were
changed by version "nn" is found in DOCVERnn members.

Chapter FORTY in the 1984 MXG Guide and 1987 MXG Supplement books are
still the primary documentation of MXG datasets and their variables.
This should be the first place you look for information about MXG
variables and/or datasets, but as each section of chapter FORTY is
rewritten, it becomes an ADOCxxxx member of MXG.SOURCLIB, providing
online documentation for product xxxx.  ADOCs contain alphabetic
descriptions of datasets and variables, the instructions on how to
enable that product, bibliography to the vendor documentation, sample
PROC PRINT and PROC MEANS of real data, and the MXG member names that
you use to process that product, etc.  Sounds great? It will be when
finished - this is work still in progress!

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:

  IMACxxxx - Defines record IDs, and "_K,_L" macros for product xxxx.
  ADOCxxxx - "Chapter FORTY" style dataset and variable documentation.
  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 each dataset.  There can be more than one
             dataset per product.  The EX member name suffix yyyzzz is
             the same as the suffix of "_L" and "_K" macros defined in
             IMACxxxx for the product.  See further discussion under
             "Using the MXG Exit Facilities".

   Member IMACAAAA is an index of all IMACs, and is the best place to
   begin to find what xxxx suffix Merrill chose for which product!

   You can often find additional documentation by searching members
   NEWSLTRS or CHANGESS for the xxxx suffix.

Finally, remember that MXG is source code, so you can often find your
answer by BROWSE/EDIT of the source member, especially the VMACs that
actually create the data set, or ANALs that analyze the MXG data sets.
In most cases, the MXG Variable name is the IBM or Vendor's field or
DSECT field name. In other cases, the DSECT field name is carried as a
comment beside in the MXG INPUT statement to map field name to MXG's
variable name.  MXG does expect that you will also have access to the
vendor's documentation of the data records you are processing.

The MXG Technical Newsletter is published aperiodically, one copy per
licensed site, and describes changes and enhancements to the software,
provides APARs and PTFs affecting MXG users, and provides tutorial
information of interest to MXG users.

IX.   Change Log

--------------------------Changes Log---------------------------------

 You MUST read each Change description to determine if a Change will
 impact your site. All changes have been made in this MXG Library.

 Member CHANGES of the MXG SOURCLIB will always be more accurate than
 the printed changes in a Newsletter, because the software is created
 after the newsletter is sent to the printer!

 Member CHANGES always identifies the actual version and release of
 MXG Software that is contained in that library.

 The actual code implementation of some changes in MXG SOURCLIB may be
 different that described in the change text (which might have printed
 only the critical part of the correction that can be made by paper).

 Scan each source member named in any impacting change for any comments
 at the beginning of the member for additional documentation, since the
 documentation of new datasets, variables, validation status, and notes,
 are often found in comments in the source members.

Alphabetic INDEX of significant changes after MXG 10.10 was shipped:

  Member    Change   Description

  ANALDB2R 11.007  Fails with PDB=SMF if account reports suppressed.
  ANALDB2R 11.036  Suspension counts twice actual value.
  ANALDB2R 11.037  Total Read IOs miscalculated on Statistics Summary
  ANALDB2R 11.042  DB2 PMACC02 count of OPENS actually counted FETCHES.
  ANALDB2R 11.043  DB2 PMSTA02 count of SUSPENDS usually zero.
  ANALDSET 11.048  ERROR 455-185 for dataset TYPE30OM.
  ANALRMFR 11.024  Report fails with PDB=SMF, works with PDB=PDB.
  ANALRMFR 11.069  Continued enhancement of RMF look-a-like reports.
  ASUMDB2A 11.038  QTXAIRLM omitted from SUM= list
  ASUM70PR 11.022  PDB.RMFINTRV may be corrupted by ASUM70PR.
  ASUM70PR 11.027  LP0MGTTM not in RETAIN list (affects only MDF)
  ASUM70PR 11.041  ASUM70PR new variables, and mini-tutorial.
  ASUM70PR 11.087  LP0MGTTM (Amdahl MDF only) incorrect.
  BUILDPDB 18.094  Building your PDB on tape.
  BUILDPDB 11.089  Purge records lost if PRPRTY=4-7 or 12-15.
  CHANGESS 11.074  New member CHANGESS contains ALL changes ALL Versions
  CLTIMER  11.035  STOP statement required by SAS Version 6.
  CONFIG07 11.129  SAS Error 76-322 with numbered + unnumbered lines.
  Doc      11.013  Change 10.175 typo, two _KTY0 should be _LTY0
  DAILYDSN 11.076  Typos misspelled output datasets.
  DIFFHSM  11.019  Member did not use the "_L" macro names.
  FMXGUCBL 11.088  Archaic UCBL function corrected.
  GRAFLPAR 11.079  Error "OUT OF MEMORY" due to SAS Error 6719.
  IMACACCT 11.104  "VARIABLE SACCT1 NOT FOUND" can occur.
  IMACICSA 11.110  Support for SAP Releases 4.3.J and 5.0.
  JCLIMSLG 11.109  MXG 10.10 had wrong JCL in this example JCL member.
  JCLTEST  11.012  SAS 5.18 WORK.#DIRMACR is out of space condition.
  JCLTEST6 11.093  0C4 ABEND in SASXKERN if IBM exit IFGOEXOB used.
  MONTHBLD 11.040  Error "DATASET TAPEMNTS NOT SORTED".
  RMFINTRV 11.008  TYPE74 tape counts in AVGRSPMS, DEVACTTM, etc.
  TRNDDB2A 11.038  QTXAIRLM omitted from SUM= list
  TYPECIMS 11.073  INVALID VALUE FOR TH corrected.
  TYPEDB2  11.005  INVALID 3rd ARGUMENT IN SUBSTR, variable JOB blank.
  TYPEDB2  11.006  Variable QDSTQDBT is incorrect.
  TYPEDB2  11.050  DB2ACCT variable NETSNAME incorrectly padded.
  TYPEDCOL 11.057  DCOLLECT SMSDATA (SMS constructs) cause STOPOVER.
  TYPEDOS  11.106  Support for DOS/VSE POWER 5.1.
  TYPEHMF  11.049  Support for HMF, Host Monitoring Facility product.
  TYPEHSM  11.078  New HSM dataset HSMFSRBO, IMACHSM changed.
  TYPEMEMO 11.032  New variables TRANTIME TRANCOST added.
  TYPENSPY 11.009  INVALID ARGUMENT TO FUNCTION DATEJUL error.
  TYPENSPY 11.029  Variable SNITIME incorrect.
  TYPEOMAU 11.092  Omegamon 2.60 Audit Record moved OMSUBSID.
  TYPEOMCI 11.115  OMEGAMON V550 SMF record INPUT STATEMENT EXCEEDED.
  TYPEOPC  11.122  Variables added to OPC24_6 and OPC24D_C datasets.
  TYPESTC  11.124  Missing values for several variables corrected.
  TYPESYNC 11.056  Support for SYNCSORT Release 3.5 new variables.
  TYPETAO  11.034  "INVALID DATA FOR TAOSTYP" messages.
  TYPETCP  11.028  TCP/IP addresses reformatted.
  TYPEVM   11.113  Support for VM/ESA Release 2.1 Accounting record.
  TYPEVMXA 11.047  VM/ESA "UNEXPECTED/INVALID CONTROL RECORD" message.
  TYPEVMXA 11.112  Support for VM/ESA Release 2.1 Monitor records.
  TYPEVVDS 11.103  Blank values for SMS Storage, Data, etc., Classes.
  TYPEX37  11.070  STOPX37 Release 3.5 records incorrectly documented.
  TYPEX37  11.091  Variable MESSAGE not decided in STOPX37 Rel 3.5.
  TYPEZARA 11.059  Support for ZARA, The Tape Media Manager from Altai.
  TYPE102  11.085  Variables QW0145SC/QW0145LL not input.
  TYPE102  11.107  IFCID 53 and 58 records may have been dropped.

  TYPE110  11.023  Omegamon V550 APAR QOC0451/QOC0534 bad record error.
  TYPE110  11.080  STARTIME in CICINTRV dataset is actually ENDTIME.
  TYPE28   11.116  Support for NPM APAR OY54370.
  TYPE30   11.002  INVALID OMVS TRIPLET message, no observations.
  TYPE30   11.003  Type 30 Interval INTBTIME/INTETIME wrong in MVS 4.3.
  TYPE30   11.004  Variable DSSIZHWM is incorrect.
  TYPE30   11.033  Small negative values for ACTDLYTM.
  TYPE30   11.060  JELAPSTM and others large (positive or negative).
  TYPE37   11.001  INPUT STATEMENT EXCEEDED RECORD LENGTH
  TYPE37   11.031  Undocumented LAN variables BRFSMADR BRFSMNAM added.
  TYPE37   11.119  INPUT STATEMENT EXCEEDED RECORD LENGTH.
  TYPE42   11.021  New TYPE42DS has GMT values in INTERVAL record.
  TYPE7072 11.016  TYPE72MN dataset contains only one PERFGRP.
  TYPE73   11.015  TYPE73 contains observations for dummy CHPIDs
  TYPE73   11.102  Zero observations in TYPE73.
  TYPE73   11.114  PNCHANBY (EMIF Partition Channel Busy) added.
  TYPE80   11.117  Support for Top Secret Release 4.3.
  TYPE80A  11.017  INPUT STATEMENT EXCEEDED error.
  TYPE80A  11.054  TYPE80A fails with INPUT STATEMENT EXCEEDED.
  VMACNSPY 11.130  Legent LANSPY #DGL249 circumvention.
  VMACOMCI 11.136  OMEGAMON/CICS VSAM,DLI,ADABAS,IDMS,SUPRA,DATACOM.
  VMACX37  11.133  STOPX37 undocumented VOLSER,MSGCODE found.
  VMAC110  11.138  Skip over SAP Journal Records circumvention.
  VMAC30   11.126  Type 30 APPC fields accumulation corrected OY63634.
  VMAC30   11.140  Asynchronous Data Mover read/writes in APAR OY65142.
  VMXGHSM  11.131  HSM BCDS dataset MCB incomplete, too few obs.
  VMXGVTOF 11.030  Variable DS4IVTOC was not kept.
  WEEKBLD  11.040  Error "DATASET TAPEMNTS NOT SORTED".

Inverse chronological list of all Changes:



---Changes 11.140-11.001 were printed in MXG NEWSLETTER TWENTY-FOUR----
     and can be found in member CHANGES of MXG Version 11.03
****************NEWSLETTER TWENTY-THREE*********************************










              MXG NEWSLETTER NUMBER TWENTY-THREE March 15, 1993

Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE

                         TABLE OF CONTENTS
                                                                    page
I.    MXG Version 10.10 Announcement, Status and Enhancements          2

II.   Incompatibilities, Installation, and Space for MXG 10.10         4

III.  Documentation of MXG Software                                    6

IV.   MXG  Technical Notes
      1. MXG Tape Mount Monitor with MIM                               7
      2. MGBYTES format.                                               7

V.    MVS  Technical Notes
      1. APAR OY56235 - JES2 type 26 invalid times fill SPIN library.  7
      2. APAR OY57134 - IFASMFDP Blocksize correction                  7
      3. APAR OY57971 - TYPE 73 two CHPID '00', no CHPID 'FF'x         7
      4. SMF/RMF Enhancements in MVS/ESA 4.3 and DFSMS 1.1             8
      5. ISOGON's TICTOC product Zap PMR0011.                         10
      6. "MVS/ESA Resource Accounting - What's Captured Where"        11
      6. "Z/OS Resource Accounting - What's Captured Where"        11

VI.   VM   Technical Notes
      1. APAR VM52395 corrects invalid VM type 01 account records.    24

VII.  CICS Technical Notes
      1. Correction to IBM Document ID Q504977 "Main Task" CPU time.  24

VIII. SAS Technical Notes
      1. Technical note on BUILDPDB virtual storage usage.            24
      2. MEMSIZE and REGION relationship.                             25
      3. SASOPT73 can restrict your SAS options.                      25
      4. Use SMS Guaranteed Space for multi-volume SAS library.       25
      5. SAS 6.07 CMS requires GLOBAL statement.                      26
      6. SAS 6.07 ZAP Z6074721 corrects 0C4 with double ampersand.    26
      7. PROC COPY zero observation dataset ABENDs.                   26
      8. INVALID HEADER error.                                        26
      9. Nested parenthesis in SUM results in invalid values.         26
     10. PROC GPLOT "SAS SYSTEM STOPPED" error corrected by Z6071258. 27
     11. SAS 6.07 CPU loop or Wait loop if //WORK has UNIT=(SYSDA,3)  27
     12. XSWISS font name changed to SWISS.                           27
     13. 0C4 ABEND in Data Step compiler V6-SYS-DATA-5266             27
     14. SAS V6-SYS-FILE-4673 corrects CRITICAL ERROR IN VTOC         27
     15. MXGSAS sample JCL Procedure provided.                        27

IX.   Change Log                                                      28
      Alphabetical list of important changes                          28
      Changes 10.323 thru 10.105                                   32-80



         COPYRIGHT (C) 1993 BY MERRILL CONSULTANTS DALLAS TEXAS

I.    MXG Software Status and Enhancements:

  MXG 10.10 is the Production Version of MXG 10 (i.e., the version that
  we "Produce" for all sites), dated March 15, 1993, and it was shipped
  to you along with this MXG Technical Newsletter number TWENTY-THREE.

  MXG 10.10 is a major revision, with many latent enhancements, and near
  transparent installation.  Sites with normal MXG tailoring should need
  less than 2 hours to unload, tailor, and submit the test jobstreams.

  Make sure you read the COMPATIBILITY warning in Installation section
  of this Newsletter (repeated, always, in member CHANGES).

  Check member CHANGES in MXG Version 10.10 for last minute additions!

  Versions 10.7-10.9 were skipped to make the Production Version 10.10.
  Versions 4.4 thru 9.9 were truly the n.n release, but I now plan to
  number all future Production releases equal to the version number!

  Major enhancements added in MXG 10.10, that were not in MXG 10.6:
    Support for OpenEdition MVS, OMVS, RMF record enhancements.
    Preliminary RS6000 AIX VMSTAT,IOSTAT,PS command processing
    GMT offset, GMTOFFTM, available in MVS/ESA 4.3 RMF records.
    DCOLLECT options SMSDATA creates nine new SMS construct datasets.
    RMF reports can be produced from MXG TYPE70xx datasets.
    Additional online MXG documentation members (ADOC and ACHAP).

  Major enhancements added in MXG 10.6, that were not in MXG 10.5:
    Support for Empact's Hipercache SMF record.
    Support for IMF Release 2.8.
    Support for Oracle 6.0.33.1.51.
    Support for IBM 3495 Tape Library Dataserver's type 94 SMF record.
    Support for (incompatible) Omegamon/CICS DATACOM SPE PTF QOC0109.
    Support for STOPX37 Release 3.5.
    Support for Empact's POOL-DASD user SMF record.
    Support for Candle's IMS Transaction Reporting Facility, ITRF.
    Support for Landmark for CICS's Release 9 and Release 1.0.
    IBM-like RMF reports can be created with new ANALRMFR.
    Additional HOGAN application fields added in CICSTRAN
    HP's MPE data or HP/UX Unix data are both supported by TYPEHPCS
    SLR-like IMS processing for sites with heavy fast-path in TYPESLRI
    Additional CMF "type 240" subtypes supported in TYPECMF

  Major enhancements added in MXG 10.5, that were not in MXG 10.4:

    Support for MVS/ESA 4.3 and RMF 4.3.
    Support for NPM Release 1.6.
    Support for NETSPY Release 4.3 and LANSPY 1.1.
    Support for IDMS Release 12 PM records confirmed.

  Major enhancements added in MXG 10.4, that were not in MXG 10.3:

    Support for ESCOM Multi-Image Facility (EMIF)
    Support for VM/ESA 2.0
    Validation of support for Velocity Software's XAMAP History files.

  Major enhancements added in MXG 10.3, that were not in MXG 10.2:

    Support for NPM 1.5.1 incompatible changes.
    Correction of MXG-10.2-only error in ASUM70PR
    Support for DFSORT Release 12 new fields.
    Cleanup of all reported errors in prior prereleases.
    Toleration support for VM/ESA 2.0 MONWRITE data.

  Major enhancements added in MXG 10.2:

    Powerful new "_L" and "_K" macro architecture allows full tailoring
      of MXG datasets (variables kept/dropped, compression, blocksize,
      the DDNAME to which the dataset is written, etc.).
    Support for DB2 Trace IFCID 172/ 177 added, Audit/SQL reports fixed.
    Support for FACOM AIM Version 12 type 116 SMF record changes.
    Support for FACOM PDLF Type 127 for MSP/EX.
    Support for HP Unix (HP/UX) PCS Performance Collection System data
    Support for IBM TCP/IP Version 2 Release 2 SMF record.
    Support for IBM TIRS type 96 SMF record coded.
    Support for Network Alert APAR OY49717 in SMF Type 37.
    Support for OMEGAMON II for VTAM V150 user SMF record coded.
    Support for OPC changes.
    Support for SAP Accounting data in CICS type 110 or journal file.
    Support for SIMWARE SIM/XFER VTAM user SMF record.
    Support for TMS Billing-by-dataset using enhanced DSNBRECD dataset.
    Support for VSE DOS POWER Version 4.2
    Support for Xerox Printer's SFS Status File System records.
    Support for XCOM 6.2 Version 2.2.2G SMF record.
    Alert that Legent's MIM can corrupt MXG Tape Mount counting.
    "Appended" IMS Log enhancements; has now been tested with IMS 2.2.
    Continued enhancement of ANALDB2R for DB2 reports.

  Major enhancements added in MXG 10.1 but not listed in Newsletter 22:

    OPC/A log processing major revision, additional datasets created.
    Verstand's product, TTX, is now included in MXG Software.
    Support for AS400 V2R1M0 added, and AS400 support was revised.
    NPM 1.5.1 subtypes 144-150 (NPMEVX25 dataset) errors were corrected.
    Sample IEFU83 exit to filter type 40 records for tape-only added.

  Major enhancements added in MXG 10.1 that were listed in NL 22:

   Required for CICS/ESA 3.3,
   Required for VM/ESA 1.1.1,
   Required for TYPEIMS users; major revision in IMS log processing.
   Strongly recommended for DB2 sites, because it:
      - has significant corrections in ANALDB2R reporting,
      - has speeded up MXG DB2 processing and reduced WORK space needed,
      - allows DB2ACCT direct to tape for sites with large DB2 activity,
      - has new ASUMDB2A to summarize and reduce size of DB2ACCT.
      - has MVS Account fields added to DB2ACCT (DB2 2.3).
   Offers support for these new products or releases:
     Support for AICorp's KBMS user SMF record.
     Support for Amdahl's APAF replacement for MDFTRACK.
     Support for Blue Line's Vital Signs for VTAM type 28.
     Support for Fujitsu's FACOM MSP/EX (incompatible) SMF records.
     Support for MVS/ESA 4.2 Dynamic I/O Reconfig in MXG Tape Monitor.
     Support for NETSPY Release 4.2 added.
     Support for NETSPY Token-Ring records added.
     Support for ROSCOE Release 5.7 changes to SMF data.
     Support for RSD's WSF/WSF2 Release 3.4.1.
     Support for SPMS 1.2.13 incompatible changes.
     Support for STOPX37 Release 3.4.
     Support for Software Ag "Natural Process" SMF record.
     Support for System Center's NETMASTER type 37 SMF records.
     Support for The Network Director North Ridge Software
     Support for UNIX iostat and vmstat commands from ULTRIX.
     ASMVTOC avoids 213/314 abends reading VTOC of TPF or VM  volumes.
     MINTIME=,MAXTIME= parameters added to VMXGSUM.
     MXG Tape Mount Monitor supports MVS/ESA dynamic reconfiguration.
     TAPE3490 (3490s allocated) added to PDB.STEPS/JOBS.


    Each of those enhancements are described in the Change Log, below.

    The following table lists announced availability dates for the IBM
    product, and the corresponding Version of MXG required to support
    that IBM product.
                                       Availability     MXG Version
      Product Name                     Date              Required

      MVS/370, MVS/XA (all)            long ago             8.8
      RMF 4.1.2 (for MVS/ESA 3.1.3)    Sep  7, 1990.        8.8
      RMF 4.2   (for MVS/ESA 4.1)      Oct 26, 1990.        8.8
      MVS/ESA 4.1                      Oct 26, 1990.        8.8
      MVS/ESA 4.2                      Mar 29, 1991.        9.9
      RMF 4.2.1 (for MVS/ESA 4.2)      Mar 29, 1991.        9.9
      MVS/ESA 4.2.2                    Aug     1991.        9.9
      RMF 4.2.2 (for MVS/ESA 4.2.2     Aug     1991.        9.9
      MVS/ESA 4.3                      Mar 23  1993.       10.10
      RMF 4.3.0 (for MVS/ESA 4.3       Mar 23  1993.       10.10
      CICS/ESA 3.1                             1990         8.8
      CICS/ESA 3.2                     Jun 28, 1991.        9.9
      CICS/ESA 3.3                     Mar 28, 1992.       10.1
      DB2 2.2.0                                1990         8.8
      DB2 2.3.0                        Oct 28, 1991.       10.1
      DFSMS 1.1                        Mar 23, 1993        10.10
      VM/ESA  1.1.0 (370 Feature)      Oct 26, 1990.        8.8
      VM/ESA  1.1.0 (ESA Feature)      Mar 29, 1991.        8.8
      VM/ESA  1.1.1                    Dec 27, 1991.       10.1
      VM/ESA  2.0                      Dec 23, 1992.       10.4

II.   Incompatibilities, Installation, and Space Requirements.

 1. Incompatibilities in MXG 10.10 which will cause syntax errors:

      a.  If these members exist in your USERID.SOURCLIB, then you must
          replace them, by re-tailoring your changes starting with the
          new MXG 10.10 member:

               IMACCICS IMACCIMS IMACCMF  IMACDB2  IMACDCOL IMACIMS
               IMACINTV IMACMONI IMACNSPY IMACOPC  IMACPDSM IMACROSC
               IMACSTX  IMACTPX  IMACZRB  IMAC30DD IMAC40DD IMAC434D
          These members defined the DDNAME to which MXG sent certain
          datasets (eg., MACRO _CICTRAN CICSTRAN % set the DDname for
          DATA _CICTRAN.CICSTRAN).  The new "_L" architecture provides
          the same function with different syntax (eg., now the macro
          _LCICTRN defines both the DDNAME (LIBREF) and dataset name).
          Change 10.175 provides specific details of what old-names have
          to be changed to what new-names for these incompatibly changed
          members.

      b.  If you had tailored BUILDPDB/3 to create TYPETMNT (the MXG
          Tape Mount Monitor records), you will need to remove your
          tailoring in members EXPDBINC,EXPDBVAR,EXPDBCDE,EXPDBOUT.
          In MXG 10.10 TYPETMNT is automatically created by BUILDPDB/3.

    Sites migrating to MXG 10.10 from MXG 9.9 or later should find no
    other compatibility issues.

    Sites jumping to 10.10 from an MXG version earlier than 9.9 must
    read the compatibility section of the installation instructions in
    MXG Newsletter TWENTY-ONE pp 37-38 (also in member NEWSLTRS).

 2. Installation and re-installation procedures are described in detail
    in member INSTALL, but they are summarized here:

     a. Allocate a 70-cyl PDS:  MXG.V1010.MXG.SOURCLIB, & use IEBUPDTE
        to read the MXG tape to create the 1800+ member Source Library.
     b. Allocate a 1-cyl PDS:  MXG.V1010.USERID.SOURCLIB for your site
        "Installation Tailoring" Source Library.  Installation specific
        tailoring (like telling MXG your shift hours, which performance
        groups are TSO, CICS, etc.) is done by copying and modifying MXG
        source members into V104.USERID.SOURCLIB.
     c. Allocate a 1-cyl SAS Data Library:  MXG.V1010.MXG.FORMATS and
        execute SAS to create the library of Formats required by MXG.

        Sample JCL for the above three steps is in member JCLINSTL.

     d. If re-installing MXG, copy your existing USERID.SOURCLIB library
        members into the MXG.V1010.USERID.SOURCLIB. Then examine the set
        of IMACs that were changed incompatibly (see member CHANGES).
        If any members in MXG.V1010.USERID.SOURCLIB are in that list,
        you must reinstall your site's tailoring for that IMAC, starting
        with the IMAC member from the MXG 10.10 Source Library.
     d. If this is the initial install of MXG, tailor these members into
        your MXG.V1010.USERID.SOURCLIB tailoring library:
          IMACACCT (Account Length),
          IMACSHFT (Shift Definitions),
          IMACWORK (Performance Group to Workload mapping), and
          IMACSPIN (for BUILDPDB).
        Each IMAC member is self-documenting, and IMACAAAA is the index
        of all of the IMACs.  You should at least scan IMACAAAA to see
        the acronyms MXG uses for the many products MXG supports.
     e. EDIT and submit member JCLTEST6 (JCLTEST if still on SAS 5.18)
        to verify that your tailoring did not create any errors.
     f. EDIT and submit JCLPDB to create a Daily PDB for testing.  Or
        use the TYPE.... members to process specific data sources, use
        the ANAL.... members for report examples, the GRAF.... members
        for SAS/GRAPH reports.

     You have now installed MXG 10.10 in its own set of libraries. When
     parallel testing is complete and are ready to implement MXG 10.10
     in production, rename your three current MXG Production Libraries
     (MXG.MXG.SOURCLIB, MXG.USERID.SOURCLIB, and MXG.MXG.FORMATS) to
     (MXG.BACK.MXG.SOURCLIB, MXG.BACK.USERID.SOURCLIB, MXG.BACK.MXG....)
     and and rename the MXG.V1010.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:" and  "ERROR :"  and
"UNINITIALIZED" and "NOT CATLGD", as they may indicate a serious error.

A PROC PRINT and a PROC MEANS of each new MXG-built SAS dataset can help
you to understand their contents, and should be used to examine any
unusually large, negative, or suspicious values.  Print all variables in
the dataset, and read the variable's descriptions in its ADOC member.

III.  Documentation of MXG Software.
Member CHANGES always contains the version number of MXG Software, and
it lists changes that were installed in that version.  Members named
CHANGEnn are the CHANGES member from MXG Version "nn".   Each change in
MXG software is documented by a Change number and text.  The text of
each Change identifies the member(s) that were added or altered by that
change. Documentation (especially for new product's support) is often
also found in comments at the beginning of those members listed in the
change entry.  The CHANGE member is designed to be read online (with SPF
BROWSE); you can search for specific product name references (CICS,
MVS/ESA, etc.), or the MXG member name.

Member NEWSLTRS contains the text of all newsletters (up through the
newsletter that accompanied that MXG release). You can search NEWSLTRS
for product name or acronym to find the technical notes, APARs, etc.
from all MXG newsletters.  The Change Log pages of each Newsletter are
in member CHANGES or CHANGEnn and are not repeated in member NEWSLTRS.

Member DOCVER lists alphabetically ALL datasets and variables that can
be build by this MXG Software Version.  "Delta-documentation" between
MXG versions, which lists only those datasets and variables that were
changed by version "nn" is found in DOCVERnn members for each version.

Chapter FORTY in the MXG Guide and MXG Supplement books are still the
primary documentation of MXG datasets and their variables (at least for
those data sources that existed in 1987!).  This should be the first
place you look for information about MXG variables and/or datasets.

As each section of chapter FORTY is rewritten, it becomes an ADOCxxxx
member of MXG.SOURCLIB, providing online documentation for product xxxx.
ADOCs contain alphabetic descriptions of datasets and variables, the
instructions on how to enable that product, bibliography to the vendor
documentation, sample PROC PRINT and PROC MEANS of real data, and the
MXG member names that you use to process that product, etc.  Sounds
great? It will be when finished - this is work in progress!

Beginning with MXG 10.3, there has been an IMACxxxx member for every
product supported by MXG.  Once you know the xxxx suffix for a product,
you then know the names of all of the MXG members for that product:

   IMACxxxx - Defines record IDs, and "_K,_L" macros for product xxxx.
   ADOCxxxx - "Chapter FORTY" style dataset and variable documentation.
   VMACxxxx - The "real" code member, often documentation in comments.
   TYPExxxx - Standalone member to test or process product xxxx records.
   ASUMxxxx - Summarization example (only for some products)
   TRNDxxxx - Trending example (only for some products)
   ANALxxxx - Reporting/analysis example (only for some products)
   GRAFxxxx - SAS/GRAPH report example (only for some products)
   EXyyyzzz - OUTPUT exit for each dataset.  There can be more than one
              dataset per product.  The EX member name suffix yyyzzz is
              the same as the suffix of "_L" and "_K" macros defined in
              IMACxxxx for the product.  See further discussion under
              "Using the MXG Exit Facilities".

   Member IMACAAAA is an index of all IMACs, and is the best place to
   begin to find what xxxx suffix Merrill chose for which product!

   You can often find additional documentation by searching members
   NEWSLTRS, CHANGES, and the CHANGEnn members for the xxxx suffix.


Finally, remember that MXG is source code, so you can often find your
answer by BROWSE/EDIT of the source member, especially the VMACs that
actually create the data set, or ANALs that analyze the MXG data sets.
In most cases, the MXG Variable name is the IBM or Vendor's field or
DSECT field name. In other cases, the DSECT field name is carried as a
comment beside in the MXG INPUT statement to map field name to MXG's
variable name.  MXG does expect that you will also have access to the
vendor's documentation of the data records you are processing.

The MXG Technical Newsletter is published aperiodically, one copy per
licensed site, and describes changes and enhancements to the software,
provides APARs and PTFs affecting MXG users, and provides tutorial
information of interest to MXG users.

IV.   MXG Technical Notes

  1.  The MXG Tape Mount Monitor (in member ASMTMNT) seems to be very
      low overhead - Freddie Arie reports that with 35,000 tape mounts
      per month, the MXGTMNT task used only 6 CPU minutes per month!

      MIM and other tape allocators that set Mount Pending can cause
      mount records for non-mount events.  You can delete the non-mount
      events that have TAPMNTTM less than 5 seconds.  See discussion in
      Change 10.200.

  2.  The MXG-built format named MGBYTES does not stand for "megabytes",
      but is a format that prints the value of variables that contain
      bytes in Kilobytes, Megabytes, Gigabytes, suffixing the numeric
      value with KB, MB, GB as necessary.  This conversion does not
      alter the true value of the variable, which always contains bytes.
      If a variable TESTSTOR has format MGBYTES (in member DOCVER or in
      a PROC CONTENTS listing), you could see the exact number of bytes,
      without the KB, MB, etc., suffix, simply by printing the variable
      using FORMAT TESTSTOR; to eliminate the assigned MGBYTES format.
      Note that in many cases, a storage value with format MGBYTES may
      have been stored as "frames" in the SMF record; MXG multiplied the
      number of frames by 4096 to convert the value to bytes, and then
      applied MGBYTES format so it prints pretty!


V.    MVS Technical Notes

  1.  APAR OY56235 PTFs UY85272 (JES 4.1) and UY85272 (JES 4.2) correct
      invalid READTIME, JSTRTIME and JENDTIME values in TYPE26J2 and
      PDB.JOBS. This IBM error can cause your SPIN library to fill, so
      put this fix on!

  2.  APAR OY57134 corrects the IFASMFDP (SMF Dump program) so that it
      no longer creates BLKSIZE=32767 by default.  Actual SMF records
      can be no greater than 32760, and now BLKSIZE=32760 is the default
      set by IFASMFDP, because some utilities had problems with a value
      of 32767.  (You could avoid the problem by explicitly specifying
      the BLKSIZE=32760 in your JCL for the dump job, but this APAR
      corrects the basic problem.)

  3.  APAR OY57971 acknowledges that there are two '00'X CHPID values in
      TYPE73, and no 'FF'X CHPID value.


  4.  SMF AND RMF ENHANCEMENTS ADDED IN MVS/ESA 4.3

SMF Global Recording Interval Synchronization now permits RMF and SMF
interval records to be matched exactly.  You synchronize with the new
SYNCVAL and INTVAL values in the SMFPRMxx member of your SYS1.PARMLIB.
Variable SYNCTIME is added to the TYPE23, TYPE30_V (type 30 subtype 2
and 3 intervals) and TYPE70xx thru TYPE79xx datasets.  SYNCTIME is the
datetime value when the SMF Global Recording Interval ended, but it, and
INTBTIME/INTETIME in TYPE30_V are written from the GMT clock, so if you
have a non-zero value for TIMEZONE in SYS1.PARMLIB(CLOCKxx), the records
contain a GMT value in SYNCTIME, INTBTIME, and INTETIME, but SMFTIME,
STARTIME, ENDTIME, INITTIME, ALOCTIME, LOADTIME and TERMTIME are local!
Fortunately, the GMT offset in type 30 can be determinted from the old
interval begin time, and SYNCTIME in RMF can be compared to SMFTIME to
actually benefit us - with fuzzy logic that delta is now the retained
variable GMTOFFTM, the GMT offset at the end of each RMF interval!

Synchronization also changes the contents of the TYPE30_V interval data.
Formerly, INTETIME was the SMFTIME when the interval record was written,
but now, INTETIME is the time when the synchronized interval ended.  If
the task is swapped out when an interval ends, the SMF record will not
be written until later, when the task is swapped back in, and the begin
time of the next interval record, INTBTIME, will be the time of the swap
swap in, and not set to the ending time of the previous interval.  This
makes the INTBTIME to INTETIME duration the true duration during which
the resources reported in the interval record were consumed, even though
the elapsed interval of execution can be much longer for swapped tasks.
The original SMF30IST interval begin time is still recorded on the local
clock, but the new INTBTIME and INTETIME fields are on the GMT clock.
Fortunatly, the difference between SMF30IST and INTBTIME fields is the
GMT offset in effect, so MXG could correct INTBTIME and INTETIME back to
local, and furthermore, new variable GMTOFFTM is created and retained.

The JES2 type 26 Purge Record was enhanced with these long-wanted data:
  SUBMUSER -  Submitting USERID
  NOTIFYND -  Job end execution notify NODE
  NOTIFYUS -  Job end execution notify USERID
  ACCOUNTn -  Job card accounting fields finally!!!
  NRACCTFL -  Number of accounting fields.
  LENACCTn -  Length of nth accounting field
  DUPJBDLY -  Flag that job was delayed due to Duplicate Job Name Hold
  OFFLPURG -  Flag that this is a Spool Offload purge record.

APPC Accounting in TYPE33_1 now contains JOB READTIME and STEPNAME.
The new TYPE33_2 dataset contains resources at the conversation level,
particularly needed if you use an APPC/MVS Server address space to
process multiple conversations concurrently, since now you can collect
information for each conversation in the server address space.

New DFSMS TYPE42SR dataset provides response statistics for each Storage
Class for each interval, containing:
  AVGCONMS- Average connect time per SSCH
  AVGCUQMS- Average CU queue time per SSCH
  AVGDISMS- Average disconnect time per SSCH
  AVGPNDMS- Average pending time per SSCH
  CACHCAND- Count of cache candidates
  CACHHITS- Count of cache hits
  IOCOUNTS- Total i/o count
  RESPTIME- Average response time per SSCH
  STORCLAS- Average connect time per SSCH
  WRITCAND- Count of write candidates
  WRITHITS- Count of write hits


New DFSMS TYPE42DS dataset provides the above response statistics, but
at the data set level, with additional details.

TYPE70s:  Variable SYNCTIME was added to all RMF datasets for matchup
with SMF records, and new variable INTRVSYN flags if synchronization was
in effect.

TYPE71:  CPUPAGTM, the CPU time spent in page movement in central store.
When a particular type of frame (eg. below 16MB or nonreconfigurable) is
mandated by a request but is not found in the available frames, the real
storage manager uses a process called prefsteal to attempt to find a
correct type of frame and move the contents of that frame elsewhere in
central or expanded storage.  The TCB/SRB timer is stopped during this
process in consideration of the general desire that these times be as
repeatable as possible.  This new variable, CPUPAGTM, is the CPU time
that was not previously captured during this process.

TYPE72MN:  A significant MVS/ESA 4.3 RMF enhancement is the addition of
many new RMF III variables to the TYPE72MN dataset, written for each
performance group for each interval.  New sampled measures for the
percentage of time when each performance group was USING devices or CPU,
or was DELAYed for devices, CPU, storage, ENQ, HSM, JES, MOUNT, message,
XCF will make TYPE72MN a very useful source of delay analysis.
Additional measures of CSTORE and ESTORE usage and "long" logical swaps
are included in these new variables:
  AVGELPTM=AVG ELAPSED*TIME PER*ENDED TRANS
  AVGQUETM=AVG JES/APPC*QUEUE TIME*PER ENDED
  CPUVECTM=VECTOR*CPU USED*DURATION
  LOGCSTOR=CSTORE FOR*LOGICALLY*SWAPPED USERS
  LOGESTOR=ESTORE FOR*LOGICALLY*SWAPPED USERS
  LONGESTO=LONG SWAPS*TO EXPANDED*STORAGE
  LONGLGSW=LONG*LOGICAL*SWAPS
  LONGPHYS=LONG SWAPS*TO PHYSICAL*AUXSTORE
  LSWSAMPS=TOTAL*LOGICAL SWAP*SAMPLES*/
  PCTDLDEV=PCT WHEN*DEVICE*DELAY
  PCTDLENQ=PCT WHEN*ENQ*DELAY
  PCTDLHSM=PCT WHEN*HSM*DELAY
  PCTDLJES=PCT WHEN*JES*DELAY
  PCTDLMNT=PCT WHEN*MOUNT*DELAY
  PCTDLMSG=PCT WHEN*MESSAGE*DELAY
  PCTDLPRO=PCT WHEN*PROCESSOR*DELAY
  PCTDLSTO=PCT WHEN*STORAGE*DELAY
  PCTDLXCF=PCT WHEN*XCF*DELAY
  PCTUNKN =PCT WHEN*UNKNOWN*STATE
  PCTUSDEV=PCT WHEN*DEVICE*USING
  PCTUSPRO=PCT WHEN*PROCESSOR*USING
  PHYESTOR=ESTORE FOR*NON-LOGICAL*SWAPPED  USERS
  PSWSAMPS=TOTAT*NON-LOGICAL*SWAP SAMPLES
  TRANS   =ENDED*TRANSACTION*COUNT
  VALDSAMP=TOTAL*VALID*SAMPLES

TYPE73:  In MVS/ESA 4.2, APAR OY45991 PTF UY77343 now writes a CHPID
segment for all 256 possible paths whether they exist or not, so now MXG
only OUTPUT TYPE73 observations if the CHPID is ONLINE.  This logic was
externalized into member EXTY73 in case you want observations for
OFFLINE channel paths.

TYPE74TD: New "Tape Device" dataset contains the maximum number of tape
devices allocated each interval, recorded if device class TAPE is being
recorded.  This dataset was also added to BUILDPDB/BUILDPD3 and
WEEKBLD/MONTHBLD logic.

TYPE74:  New variable, TAPEMNTS, counts the number of tape mounts
detected during the interval for each tape device.  Variables MTPATBEG
and MTPATEND are "Y" flags if MTP (mount pending) existed at begin or
end of interval.  If MTP does not exist at either begin or end, MXG
calculates the average mount pending per tape mount per device in new
variable AVGMTPTM.  In RMFINTRV AVGMTPTM is calculated for all
devices that had both MTP flags blank.
  (Only when both flags are blank do we know for sure that the mount
   pending time duration and the number of mounts are exactly matched.)

TYPE79C: New variables R79FLAG, R79CPBY and R79CCPTS added.

TYPE90:  Variables MINBUFF and MAXBUFF are now reserved in IPL SMF, SET
SMF, or SETSMF Operator Command event records.  No real loss here, since
the maximum number of buffers each interval is always in TYPE23 dataset.

TYPE94   The type 94 record from the 3495 Tape Library Dataserver has
hourly counts and durations (min/max/avg for counts/durations) of drives
mounted, mount requests pending, demounts, ejects, audit requests, and
the count of insert stores.

TYPE96   The type 96 record from The Integrated Reasoning Shell, TIRS
accounts for TIRS resounce usage.  The SMF Manual title "Cross Memory
Service Provider Charge Back" is certainly pompous for this TIRS record!

Type 118/119:  The TCP/IP SMF record sample used ID=70!  APAR PN34837
now assigns IBM record numbers 118 and 119 for the TCP/IP product.

BUILDPDB Logic was changed to use the type 26 OFFLPURG field to detect
purge records created by the SPOOL Transfer/Offload program.  New
variables SUBMUSER DUPJBDLY OFFLPURG ACCOUNT1-ACCOUNT3 LENACCT1-LENACCT3
and NRACCTFL were added to the list of variables kept from TYPE26J2 (in
member IMACPDB).  The order of datasets in the MERGE for PDB.JOBS was
changed, moving GOOD26J2 to be first so that the TYPE26 ACCOUNTn fields
will be used in PDB.JOBS when they exist.  (Leaving it where it was
could have blanked out valid ACCOUNTn data since the SAS MERGE uses the
values from the last dataset, for sites not yet on MVS/ESA 4.3!)

RMFINTRV The new CPUPAGTM from TYPE71 is kept in RMFINTRV as a separate
variable,  is also added to CPUTM, the sum of all captured CPU time, and
hence the CPUPAGTM is NOT included in CPUOVHTM, the MXG variable for
uncaptured CPU time in RMF.

DCOLLECT has added a new field to the type "A" record with the amount of
space used by a VSAM entry (formerly only allocated size was given).


  5.  The TICTOC product from ISOGON, designed to test applications for
      the year 2000+, can corrupt dates and data in SMF type 4, 5, and
      30 records.  TICTOC establishes a "virtual clock" by trapping SVC
      11, but SMF uses SVC 11.  When the virtual clock was returned to
      SMF, it created invalid job initiation, JINITIME (which is used in
      MXG's SPIN decision logic) and corrupts JELAPSTM, for any job that
      used TICTOC for application testing.  The virtual clock also
      corrupted the CPUTCBTM field, but ISOGON has corrected both errors
      (by only returning a "virtual clock" value if the caller is in
      Problem State and in a User Protect Key), so that now the SMF
      times appear to be valid.  Their zap is PMR0011, and it is
      included in TICTOC Release 2.0, due out later this year.

  6.  MVS/ESA Resource Accounting, Cost Transfer, and Billing Issues
  6.  z/OS Resource Accounting, Cost Transfer, and Billing Issues
       z/OS Resource Accounting, Cost Transfer, and Billing Issues
                     What's Captured Where

                    Herbert W. Barry Merrill
                      President-Programmer
                       Merrill Consultants


                   Originally presented at the
               SHARE Winter 1993 Meeting Session M724
                     Wednesday, March 3, 1993

     This paper is also contained in member ACHAP31 of MXG Software,
     as it is a consolidation and revision of that chapter.


   Computer system accounting is implicitly tied to the effectiveness
   of the DP management.  While your chief executive officers want
   effective cost accounting for their data processing budgets, many
   DP managers drag their feet because they do not want to be held
   accountable, and justify those delays by claiming that resource
   accounting cannot be accomplished.  Successful computer system
   accounting is thus both a technical and a political issue. This
   chapter is a technical tutorial on the excellent resource capture
   mechanisms that do exist in MVS/ESA, and how they can be used to
   distribute the cost of your major hardware components to users.


This material is Copyright (c) 1993 by Merrill Consultants, Dallas, TX.,
and will be published in MXG Technical Newsletter TWENTY-THREE, March
15, 1993.  Permission is hereby granted to SHARE, Inc., and to SHARE
member installations to reproduce this material for their internal use.
All other rights are reserved.

       Topic                                                 Page

   CPU RESOURCE ACCOUNTING                                     2
   USING RMF DATA TO DETERMINE THE CPU CAPTURE RATIOS          2
   USING SMF DATA TO DETERMINE THE CPU CAPTURE RATIOS          4
   SCHEMATIC COMPARISON OF CPU MEASURES IN RMF AND SMF         5
   CPU CAPTURE AT THE SUBSYSTEM LEVEL                          6
   DB2 CPU USAGE CAPTURE                                       7
   CICS CPU CAPTURE                                            8
   MEMORY                                                      9
   CHANNELS AND CONTROL UNITS                                 10
   DISK DRIVES                                                10
   TAPE DRIVES                                                11
   TAPE VOLUMES                                               11
   TAPE MOUNTS                                                12
   PRINTERS                                                   12
   TERMINALS, CONTROL UNITS, AND PORTS                        13


CPU RESOURCE ACCOUNTING

The CPU resource is always the most expensive shareable resource in any
data processing system, and it will always be the primary resource used
for cost recovery and chargeback.  Charges must be based on utilization
in order to equitably distribute the cost of the processor itself.

MVS records the total CPU time consumed in the hardware platform in
TYPE70 dataset variable CPUACTTM, it records the CPU time captured for
each address space in the TYPE30 dataset, and it records the CPU time
for each service class, so the accounting and cost recovery of CPU time
should be relatively straightforward, right?  Ain't nothin' that
straightforward: read on!

A major issue in CPU accounting are the capture ratios, which quantify
how much of the total CPU time caused by a workload is captured in the
accounting records for that workload.  In most instances, uncaptured CPU
time results when MVS simply does not know which task caused the burst
of CPU time.
   An example is the I/O interrupt processing CPU time of the First
   Level Interrupt Handler, FLIH, the module that gets control when an
   I/O interrupt occurs.  Although FLIH knows which device is involved,
   it does not know which task owns that device at the time of the
   interrupt processing, and thus its CPU time cannot be assigned to an
   address space or a service class.  For a long time, even the Second
   Level Interrupt Handler, SLIH, did not record its CPU usage, but
   MVS/ESA added instrumentation to capture SLIH time in CPUIIPTM.

Uncaptured CPU time is still CPU time that the hardware had to deliver,
and you had to buy that hardware, so you must measure the uncaptured CPU
time, and recover it by inflating the recorded CPU time by dividing by
the capture ratio.  So how do we measure how much CPU time is captured?
We can use RMF or SMF data to calculate capture ratios, but they do not
necessarily provide the same answers!

USING RMF DATA TO DETERMINE THE CPU CAPTURE RATIOS

The "RMF Uncaptured CPU time" is the TYPE70 CPU active time minus the
"identifiable" CPU times recorded in RMF; this difference measures how
much CPU time was uncaptured, as measured by RMF, during an interval.

IBM has made major improvements in minimizing the uncaptured CPU time by
improving the instrumentation within MVS; early MVS/370 typically
captured only 70% of the CPU time, MVS/XA improved to 80%, and with the
addition of the new Page Movement CPU time in MVS/ESA 4.3, over 90% of
the total CPU time may be identifiable in the RMF data.

That "RMF Identifiable" CPU time is the sum of the five CPU measures in
TYPE72GO (TCB, SRB, I/O Interrupt, Hiperspace, and Region Control Task)
for all of the Service Classes, plus the CPU measure in TYPE71 for Page
Movement:

 RMF   CPUTM=CPUTCBTM+CPUSRBTM+CPUIIPTM+CPUHPTTM+CPURCTTM+CPUPAGTM;

   Only Service Classes can be used in this calculation because any CPU
   time in a Reporting Class duplicates CPU time in its Service Class.

The RMF Uncaptured CPU time (historically, but inaccurately named
CPUOVHTM in MXG's RMFINTRV dataset) is calculated as:

        CPUOVHTM=CPUACTTM-CPUTM;

and it represents the total CPU time that was consumed but that was not
captured in RMF data.  And we could calculate the RMF capture ratio:

       RMF Capture Ratio= CPUTM/CPUACTTM;  (express as percentage)

So can't we then take the TYPE72GO data for each Service Class, inflate
the measured CPUTM by dividing by the above capture ratio to recover
100% of the CPU time consumed?  Of course not, that would be too easy,
and there's an additional problem.  While RMF "identifies" all of the
CPUTM, only some of the service classes represent directly chargeable
work.  For example, service classes for VTAM, CATALOG, RMF, etc.
represent real work that was consumed, but that work is not attributable
to a specific workload or account number: TSO users, as well as IMS and
CICS transactions cause the CPU time that VTAM used; RMF resources
(while small) are not attributable to any user, and CATALOG resources
are caused by all catalog references!  The new CPUPAGTM is "identified"
CPU time, but it, along with the CPUSRBTM in Service Class SYSSTC,
record the paging subsystem's use of CPU!

We must identify those service classes that map directly to our billable
workloads (for example, the service class(s) in which Batch, TSO, CICS,
IMS, etc., execute) and from them, construct workload specific variables
with the sum of TYPE72GO CPUTM from those workload specific service
classes (for example, variables BATCPU, TSOCPU, CICSCPU, IMSCPU, etc.)
for each RMF interval.  MXG's member IMACWORK is the table which maps
service classes to specific workloads, and it    is used to build the
RMFINTRV dataset from which capture ratios can be calculated.  The RMF
CPU time that is captured in these workload specific variables will be

 Workload Specific CPUTM =  BATCPU + TSOCPU + CICSCPU + IMSCPU;

and there now exists a new "Workload Specific Uncaptured" CPU time:

 W.S. Uncaptured CPU =  CPUACTTM - (BATCPU+TSOCPU+CICSCPU+IMSCPU);

which now includes all of the CPU time that was not recorded in one of
the workload specific service classes.  We can thus now calculate the
Workload Specific Capture Ratio:

 W.S. Capture Ratio =  (BATCPU+TSOCPU+CICSCPU+IMSCPU) / CPUACTTM;

It is this capture ratio that we must use in our chargeback analysis, as
it takes into account not only the MVS uncaptured CPU time, but also the
CPU time consumed in service classes (like VTAM, RMF, etc.) that are not
mappable to specific workloads.

   A note for the serious analyst:  The capture ratio calculated above
   is the average capture ratio across all workloads, which assumes that
   the same amount of uncaptured CPU time is caused by each workload.
   That clearly may not true; interactive workloads (especially TSO) may
   capture significantly less CPU time than does batch, as was shown in
   Chapter 26 of the 1984 MXG Guide, which found MVS/XA captured 80% of
   Batch, 76% of IMS, 66% of CICS, but only 58% of TSO, with the average
   capture ratio of 70%!

   Calculation of individual capture ratios for each workload can be
   done using SAS/STAT linear regression tools:
      PROC GLM DATA=RMFINTRV;
      MODEL CPUACTTM = BATCPU TSOCPU IMSCPU CICSCPU;
   as was described in that chapter.

   There is now an even easier way to get a good estimate of the
   capture ratio of your workloads; the MXG dataset PDB.RMFINTRV
   contains the variable CAPTURAT, which is the total system capture
   ratio.  By plotting the CAPTURAT versus time of day for each of
   your systems:
       PROC PLOT DATA=PDB.RMFINTRV;
        BY SYSPLEX SYSTEM;
        PLOT CAPTURAT*STARTIME;
   you can examine those times of day on a particular system when the
   workload is "all CICS", or "all TSO", and make a very accurate
   estimate of that workload's capture ratio.

   However, when the overall capture ratio was only 70%, measuring the
   individual capture ratio of each workload was much more critical,
   because there was so much more variation between workloads.  But if
   overall capture ratio is over 90%, and with the TSO capture ratio
   improved by CPURCCTM, it may not be so critical to calculate each of
   the workloads individual RMF capture ratio.  Of much more immediate
   concern is the determination of the CPU time captured by the SMF
   accounting records themselves.

USING SMF DATA TO DETERMINE THE CPU CAPTURE RATIOS

Historically, we have used RMF to calculate the RMF Capture Ratio and
the Workload Specific Capture Ratio because there was no other choice;
SMF type 30 data could not be synchronized and thus it was simply not
possible to accurately compare SMF CPU time with RMF CPUACTTM.  Now that
IBM has finally provided SMF interval synchronization (requested in a
SHARE CME requirement that I authored in 1978!), the same analysis
described above for RMF could now be accomplished using the SMF type 30
data.  However, not only are the CPU times recorded in RMF different
than the CPU times recorded in SMF, but also the CPU times in the
TYPE30_4 step termination record are not exactly the same as the CPU
times in the TYPE30_V step interval records!  Let us examine these
differences.

MVS/XA recorded only CPUTCBTM and CPUSRBTM in RMF TYPE72GO, TYPE30_4 and
in the TYPE30_V datasets.  MVS/ESA 3.1.0e added three new CPU times,
(CPUIIPTM,CPUHPTTM,CPURCTTM) to the TYPE30_4 and TYPE30_V data, but
those three CPU times were not added to the RMF TYPE72 data until 4.2

The CPUPAGTM that was added by MVS/ESA 4.3 to the RMF TYPE71 data is not
recorded anywhere in SMF type 30 data; in fact, IBM describes this Page
Movement CPU time as the time when the CPU timer was suspended, and says
that the reason the CPU timer was suspended during page movement was to
make the recorded task CPU time more repeatable (albeit less accurate!).

There are two other CPU measures that exist only in the type 30 step
termination data.  These fields, CPITCBTM and CPISRBTM contain the
"Initiator State" or "Privileged State" CPU time caused by the step, and
they record the CPU time at the beginning of the step and the CPU time
at the ending of the step that is not recorded elsewhere.

So what are the beginning and ending step events that are recorded in
CPITCBTM and CPISRBTM?  The major events recorded at the beginning of
steps appear to be allocation related.  Specifically, the CPU time to
execute the System Managed Storage allocation rules (ACS) is captured in
these times.  This has been both observed and verbally confirmed by IBM
SMS Level Two Support technicians.  Additionally, one site with Boole &
Babbage's IAM Product noted a step increase in these CPU times when that
product was enabled.  There may also be a small amount of CPU time due
to the creation of the address space included in these CPU times.

At the end of step, the CPITCBTM and CPISRBTM times result primarily
from SMF itself!  At step termination, the DD segments are scanned by
the type 30 SMF "DD Consolidation" algorithm in an attempt to minimize
the length of the type 30 record, by consolidating into a single entry
all DD segments with the same DDNAME and Device Address.

In 1987, Diane Eppestine at Southwestern Bell saw that whenever their
SAR job (a SYSOUT processing subsystem) was cancelled, the CPU went to
100% busy for 30-60 minutes.  Instruction traces found the "loop" was in
DD Consolidation.  SAR dynamically allocates a DD for each SYSOUT file
it processes; by the end of the week that step had over 75,000 DD
entries!  DD consolidation reads the first DD segment, scans the
remaining 74,999 segments for a match, reads the second and scans the
remaining 74,998 for a match, etc.  etc., etc., all at DPRTY=FE!  In
response to Diane's discovery, Bill Richardson, IBM SMF Development,
subsequently provided a new SMF option, DDCONS(NO), specified in
SYS1.PARMLIB(SMFPRMxx), so that you can disable this very unwise (in my
opinion) algorithm, and thereby eliminate its wasted CPITCBTM and
CPISRBTM CPU time.
   The time of DDCONS(YES) is measurable because SMFTIME timestamps when
   each record is moved (memory-to-memory) to the SMF ASID.  For step
   events with more than 1635 DD segments, multiple physical type 30
   records are created, each with its own time stamp.  One specific case
   found a subtype 2 interval event created seven type 30 records at
   Time of Day of .19 .19 .19 .22 .32 .36 & .46 TOD seconds (i.e., it
   took only 270 milliseconds to create these seven records, since there
   is no DDCONS in the creation of the subtype 2). These seven records
   contained 9182 DD segments that had been allocated during that
   interval.  The step then terminated at 18.89 TOD seconds, creating
   two subtype 3 records both with that timestamp, containing 1929 DD
   segments.  DDCONS then began, and it then took until 36.50 TOD
   seconds to create the first subtype 4 record, and then the last of
   the eight subtype 4 records was not created until 40.93 TOD seconds.
   These subtype 4s had 11,070 DD segments, while the subtype 2s and 3s
   had 11,111 total DD segments.  Thus this invocation of DDCONS took
   22.04 elapsed seconds (and recorded CPITCBTM of 22.00 CPU seconds!)
   from the end of step until the step actually ended, and this DDCONS
   invocation could remove only 31 DD segments from the step record!
   Examine a day's TYPE30_4 (or PDB.STEPS) data and sum the CPITCBTM and
   CPISRBTM, then specify DDCONS(NO) and show management how many CPU
   seconds you have been wasting due to DD consolidation!
   NOTE: THE SMF DEFAULT IS DDCONS(YES).  YOU MUST CHANGE YOUR
   SMFPRMxx MEMBER TO SPECIFY DDCONS(NO).

SCHEMATIC COMPARISON OF CPU MEASURES IN RMF AND SMF

      Solid = captured   Dashed = calculatable

TYPE 70 (RMF-captured CPU measurement of real or logical CPUs):

    Elapsed Interval (Duration multiplied by number of CPUs)
 _____________________________________________________________________


 ___________________________________________________________ ---------
                      CPU                                       CPU
                    Executing                                 Waiting


 _________ _________ _________ _________ _________ _________
   CPU 1     CPU 2     CPU 3     CPU 4     CPU 5     CPU 6
   Busy      Busy      Busy      Busy      Busy      Busy


 ___________________________________________________________

 Total Hardware CPU Busy Time (from Type 70 "non-wait")


 ___________________________________________________________


 Total Hardware CPU Busy Time (from Type 70 "non-wait")

TYPE72GO (service classes) plus TYPE 71 Paging

 _____ _____ _____ _____ _____ _____ -----------------------
  TCB   SRB   IIP   RCT   HPT   PAG    RMF Uncaptured CPU
  CPU   CPU   CPU   CPU   CPU   CPU

 _____ _____ _____ _____ _____ _____
  RMF   RMF   Captured in      New
  TCB   SRB    RMF 4.2.1,      in
  CPU   CPU    MVS/ESA 4.2+    RMF
                               4.3
 ___________ _____ _____ _____ _____
              Existed,   New,
   TCB+SRB   Moved from  was
             Uncaptured  RMF
                to       TCB
              Captured

 _____ _____ _____ _____ _____ _____   = RMF CPUTM, sum of 6 measures

TYPE 30 step termination:


 _____ _____ _____ _____ _____ ----- _____ _____ -----------
  SMF   SMF   SMF   SMF   SMF         SMF   SMF   Uncaptured
  TCB   SRB   IIP   RCT   HPT         TCB   SRB    SMF step
  CPU   CPU   CPU   CPU   CPU         CPI   CPI      CPU

 _____ _____ _____ _____ _____       _____ _____   = CPUTM, sum of 7.


TYPE 30 interval:


 _____ _____ _____ _____ _____ -----------------------------
  SMF   SMF   SMF   SMF   SMF   Uncaptured SMF interval CPU
  TCB   SRB   IIP   RCT   HPT
  CPU   CPU   CPU   CPU   CPU

 _____ _____ _____ _____ _____                     = CPUTM, sum of 5.


CPU CAPTURE AT THE SUBSYSTEM LEVEL

Thus far, we have only looked at what is captured at the address space
level, and for many applications this is adequate.  For example, if your
CICS regions individually service individual business units, using their
type 30 step termination records may well be adequate for cost recovery.
However, in most instances, a single CICS region services multiple users
from different cost centers, which would require CPU capture at the
transaction level to distribute cost to each department.
   Many multiple user address spaces (VTAM, CATALOG and monitor address
   spaces like NPM, RMF, SMF) do not provide discrete CPU time per user,
   requiring the use of regression techniques described earlier for
   their redistribution.

For subsystems that do provide transaction level accounting, we have yet
another capture ratio: how much of the CPU time that is captured in the
type 30 (or type 72) data is captured in that application's transaction
records.  The answer varies widely, especially if DB2 access from CICS
or IMS is involved.

DB2 CPU USAGE CAPTURE

When DB2 is accessed by Batch, TSO, IMS, and CICS address spaces, almost
all of the DB2 CPU time is recorded in the address space of the caller,
because DB2 access uses MVS cross-memory services.  Thus for those
callers, the DB2 CPU time is recorded in the type 30 records and in the
type 72 records for the service class of the caller.  (Some benchmarks
for these caller's use of DB2 showed that over 96% to the DB2-caused CPU
time was recorded in the caller's service classes, with less than 4%
recorded in the DB2 MAST, DBM1, and IRLM service classes.)     So the
good news is that the usage of DB2 CPU time is already recorded in your
accounting records, as long as you are using type 30 data for your
accounting.  Using the RMF type 72 data for your capacity planning
similarly includes DB2 CPU time in those workload records.

For DB2-under-IMS transaction accounting, the DB2-caused maintask CPU is
included in the CPU time recorded in the IMS log 07 (program scheduled)
record; however, in 2/2005, it was reported that only the maintask CPU
time is included, and that DB2 parallel subtask CPU time is NOT included
IBM has been made aware of the unexpected discovery, but has made no
response as to if, or when, that CPU time will also be captured in IMS.

Unfortunately, there is only one bucket for CPU time in the IMS
log, and it includes not only the DB2-caused CPU time, but also all of
the transaction's CPU time in the IMS Control and IMS Message Processing
Regions. Neither Candle/IBM's ITRF product nor Landmark-ASG TMON for IMS
product capture the portion of CPU time due to DB2 in their IMS
monitors.  However, BMC's IMS Measurement Facility, IMF, (originally
Control/IMS) is implemented as a monitor sitting on top of IMS itself,
so it is able to capture and segregate CPU time into eight separate CPU
buckets, one of which is the DB2 CPU time caused by the transaction.
The key point about DB2 under IMS is that the DB2-caused CPU time is
included in the transaction-level CPU time, no matter which IMS data
source you use.

Such was not the case for DB2-under-CICS transaction accounting!  Before
the "OTE" (Open Transaction Environment) existed, the below indented
paragraphs documented the DB2 CPU capture under CICS:

   While the DB2 CPU time caused by CICS transactions is captured in the
   type 30 records for each region, and while that DB2 CPU time is
   captured in the type 72 service class and reporting class record for
   each CICS region, as well as in the type 110 subtype 2 record's CICS
   Statistics CICDS dataset (so it is included in MXG's CICINTRV
   dataset), prior to "OTE", the DB2 CPU time caused by a CICS
   transaction was NOT recorded in any transaction record from any CICS
   monitor.  Neither the CICSTRAN dataset from IBM's SMF 110 subtype 1
   CICS Monitor facility, nor from Candle's Omegamon for CICS, nor from
   the MONITASK dataset from ASG-Landmark's The Monitor for CICS, could
   capture any DB2 CPU time in the CICS transaction data.  Fortunately,
   there was an accounting solution: DB2 itself creates a type 101 SMF
   accounting record for each DB2 transaction event from any connection
   in dataset DB2ACCT.  The DB2ACCT observations for CICS connections
   had to be selected from the DB2ACCT data (but only CICS Attaches,
   since CPU time in DB2ACCT for Batch, TSO, and IMS connections has
   already been captured in their type 30 and/or IMS log CPU time).
   DB2ACCT variable QWHCATYP identifies the source of the connection; a
   value of 4 indicates CICS attach.  Thus to account CICS at the
   transaction level, you must use both CICSTRAN and the QWHCATYP=4
   subset of DB2ACCT in your chargeback.
      Prior to DB2 2.3, if the DB2 thread was reused, only one DB2ACCT
      record was created (for the thread), and it could represent many
      CICS transactions, which prevented accurate CICS accounting with
      DB2, but now each DB2 transaction causes a CICSTRAN observation,
      even with thread re-use.  Also, QWHCATYP did not exist prior to
      DB2 2.3, which prevented accurate connection identification!
   The DB2ACCT data can be matched with the CICSTRAN data by merging on
   variables NETSNAME (the originating network name) and UOWTIME (which
   is the first six bytes of the UOWID, the Unit-of-Work ID field), and
   the MXG member ASUMUOW combines DB2ACCT and CICSTRAN to create the
   PDB.ASUMUOW dataset that contains both the CICSTRAN CPU time (CPUTM)
   and the DB2 CPU time (DB2TCBTM), and you had to add those variables
   together to properly account for the CICS and DB2 CPU time at the
   transaction level.
      Only the first six bytes of UOWID are used for the same unit of
      work because the last two bytes of UOWID count commits and/or sync
      points, and may not be the same across the same transaction.  Note
      that there can be multiple observations in CICSTRAN with the same
      values of NETSNAME and UOWTIME; in CICS Multiple Region Option,
      MRO, environments, the Terminal Owning Region (TOR), the
      Application Owning Region (AOR), and the File Owning Region (FOR)
      create individual CICSTRAN observations for a single CICS event,
      and all records from the same CICS event/uow will contain the same
      values in NETSNAME and UOWTIME.  In DB2ACCT dataset, MXG created
      variables named NETSNAME and UOWTIME by substringing DB2 variable
      QWHCTOKN (added in DB2 2.3), padding as necessary, to conform
      exactly with the structure of those pre-existing CICS variables,
      so that a SAS MERGE of DB2ACCT and CICSTRAN can be used in the
      ASUMUOW program to match CICS and DB2 transactions.
   While you must select DB2ACCT observations only for CICS in your
   charge-back (to avoid double accounting), the other observations in
   DB2ACCT are completely valid if you want to know how much of your
   Batch, TSO, or IMS CPU time was actually consumed in DB2 access.

Most of the preceding paragraph is still true, even with OTE, except
for this MAJOR change:

   With the Open Transaction Environment, "OTE" (which automatically
   exists when you have CICS/TS 2.2 or later calling DB2 V6 or later,),
   the CICS transaction record's CPU time (e.g., TASCPUTM in CICSTRAN or
   MONITASK datasets) DOES now include the DB2 CPU time! The bottom line
   for CICS accounting with OTE is that you do NOT add the two CPU times
   (CPUTM and DB2TCBTM) in the PDB.ASUMUOW dataset, because CPUTM
   includes DB2TCBTM.

While the PDB.ASUMUOW dataset is no longer required to capture the DB2
CPU time, it is still strongly recommended that it be created and used
for CICS transaction accounting, since it combines the multiple CICSTRAN
observations for MRO environments into a single observation for each
"Unit of Work", so there are many fewer observations to pass into your
billing system, and PDB.ASUMUOW will have the correct TRANNAME of the
unit of work:
  Using only CICSTRAN, you will not see the actual transaction name,
  because the CPU time will usually be in the CICSTRAN observation from
  the "AOR", and that record will have TRANNAME='CSMI' (the mirror
  transaction), so you can't map CPU time to TRANNAME from CICSTRAN in
  an MRO environment, independent of the OTE environment.  Furthermore,
  the TERMINAL/LUNAME in that AOR record won't identify the source of
  the CICS user.  The real TRANNAME/TERMINAL/LUNAME will only be found
  in the "TOR" observation for that unit of work.
Also, PDB.ASUMUOW is useful because of the additional DB2ACCT variables
which are useful for performance and capacity measurement, independent
of its use for accounting; the MXG program ANALUOW analyzes delays in
the PDS.ASUMUOW data.   And finally, in MXG 22.13, the MQ-Series data
from SMF 116 (MQMACCT and MQMACCTQ) data is merged into PDB.ASUMUOW when
you use the ASUMUOW program.

For the accounting of DB2 Distributed work (DRDA from DDCS, for example,
(a DRDA Transaction from DDCS running in an AIX workstation), it is
necessary to directly charge back using the DB2ACCT dataset.  DB2ACCT
distributed work observations have QWHCATYP values of 7 or 8, and a plan
name of DISTSERV, and the only field to tie the transaction back to the
workstation which generated the DB2 activity is the AUTHID, but that may
be constant for all transactions, depending on the software running in
the workstation that created the DB2 activity.

For Distributed work, that CPU time in DB2ACCT is also recorded in the
type 30 records for the DISTSERV address space and in TYPE72GO for the
DISTSERV's service class, but there is no other address space involved.

    Very high CPU time per transaction (for transactions that have few
    GETPAGES) has been seen (5 CPU hours for 186 transaction!  This may
    simply be the cost of Distributed Architecture (translating each of
    the SQL calls and Results to be sent back for different platforms
    must involve more code than DB2 talking to CICS, since DRDA has to
    manage itself too), or it may be just that the startup and shutdown
    costs of DRDA are significantly higher than for normal threads.

The CPUSRBTM/DB2SRBTM in DB2ACCT is now always missing:

    I have previously documented (member ADOCDB2, variable description)
    that the SRB CPU time in DB2 Accounting records was invalid, but I
    did not know how wrong it was, or why it looked ok sometimes, until
    I read IBM's library item Q576462, repeated here:

  Q: User is doing some DDF testing and has run some accounting reports.
     SRB times (both class 1 and 2) are about 8 times the TCB times.

  A: The SRB times in the accounting records, in general, account for
     SRBs that run in the user address space.  These SRBs are caused
     by the user's processing, unrelated to anything that DB2 does,
     but since the SRBs are asynchronous, they sometimes run while the
     user is processing in DB2.  With two notable exceptions, these SRB
     times while unrelated to DB2 will almost always be insignficant.

     One exception is CICS, where there are multiple subtasks accessing
     DB2 from a single CICS address space.  CICS (not DB2) will often
     do a significant amount of processing via SRBs.  If there are
     several DB2 tasks running concurrently when CICS issues an SRB
     (unrelated to these tasks!) then the time for that SRB will show
     up not once, but once in each of the accounting records for each

     of the tasks.  Thus if you add up the SRB times from the DB2
     accounting records for CICS attachment, it will often greatly
     exceed the actual amount of SRB time used by CICS.

     The other exception is when using DDF.  The requestor times are
     not affected, but the times at the server (or DBAT, using DB2PM
     terminology) will show very very large SRB times.

     When you look at the DB2 ACCOUNTING records, use only the TCB
     CPU time, and never look at the SRB time.  When you look at the
     DB2 STATISTICS records, you should use the TCB and SRB times for
     all three/four address spaces, but remember that much of the SRB
     time reported for the DDF address space may also be reported in
     DB2 accounting records (as TCB time).


CICS CPU CAPTURE

Even without the DB2-under-CICS issues raised above, the amount of CPU
time captured in CICS transaction records historically has been much
less than the CPU time recorded for the region in its type 30 or its
type 72 service class records.  The following table, while showing
pre-ESA CICS numbers, demonstrates the observed capture of three CICS
regions executing in the same 3090 model 400 processor in a 900 second
interval:
                        Seconds in          Percentage of CPUTCBTM
                       Region TYPE72GO      in CICSTRAN dataset
            Region       CPUTCBTM                 TASCPUTM

               A          111.72                    41.1
               B          127.06                    37.5
               C          198.76                    66.0

The CICS CPUTCBTM time that is not captured in the CICSTRAN transaction
accounting TASCPUTM is the CPU time to start-up and to shut-down each
transaction.  Until a transaction is attached, CICS monitoring cannot
capture CPU time, and CICS monitoring terminates before the transaction
is detached.  It appears that this CPU cost to start-up and shut-down a
transaction is fixed; it is independent of what a transaction ultimately
does.  Thus there should be a fixed amount of CPU time per transaction
that is not recorded, and we should be able to measure that cost per
CICS transaction and use it, along with the TASCPUTM actually recorded
for the transaction, to improve the recovery of CICS CPU time.

We can determine this "fixed-cost per CICS transaction" by selecting RMF
TYPE72GO for the service class of a CICS region to get that region's
recorded RMF CPUTM for each interval, and by summing CICSTRAN for the
same interval from the same region (APPLID) to create variables NRTRANS
(the number of transactions that ended during each interval), WTFCIOCN
(the number of times that File Control had to wait, indicating that a
physical I/O was performed for a transaction), and TASCPUTM (the CICS
recorded transaction CPU time).  We can then use linear regression:

   PROC GLM;
   MODEL CPUTM=NRTRANS WTFCIOCN TASCPUTM;

to generate the coefficients of the equation relating these independent
variables to the total recorded CPUTM.  The coefficient of NRTRANS is
that "fixed-cost per CICS transaction" (in seconds), and the coefficient
of WTFCIOCN is the CPU cost (in seconds) of each physical I/O!

The coefficients of these three terms can be evaluated as potential
billing factors to reproduce the total CPU time caused by each
transaction.  What has been proposed here is that the real CPU cost to
deliver CICS CPU service results from adding together the following
three cost components:

 a) a cost for the existence of each transaction (NRTRANS), recovering
    the static cost of each ATTACH/DETACH,
 b) a cost for I/O (WTFCIOCN), the CPU cost of doing I/O operations for
    each transaction, and
 c) a cost for the actual CPU seconds (TASCPUTM times it's coefficient)
    for each transaction.

Prior results (not only for CICS and other on-line systems, but even for
batch job steps) suggest that the major component of CPU time recovery
may be the NRTRANS component.  I regret that those studies were
proprietary to the enterprise for which they were done and thus have not
been published, but they showed that the start-up and shutdown costs of
a transaction can often be more significant numerically that the actual
CPU time recorded by the transaction accounting.

With the three coefficients, you can then take the CICSTRAN data and
apply them transaction by transaction to create a billable CPU time for
each interval, which can then be compared with the recorded TYPE72GO
CPUTM for validation.  By examining the sum of the three components of
CICS CPU time, you may discover that the addition of the NRTRANS
component brings the CPU captured to very nearly 100%, and you can also
see how much CPU is recovered from NRTRANS, WTFCIOCN, and TASCPUTM.

Remember that this constructed CPU time per transaction still does not
include the uncaptured MVS CPU time discussed previously.

MEMORY

Although you might like to be able to recover the cost of real memory
(Central and Expanded Storage) by charging memory usage to each task,
that possibility disappeared with the departure of MVT and other "real"
memory systems (in which tasks really did own "K-core" units for which
we could legitimately charge).  With virtual memory operating systems,
all real memory is owned by the operating system, and not by individual
address spaces.  The amount of memory "doled out" to an address space is
thus not under the control of that address space, but rather depends on
the other work that is concurrently requesting services, and (sometimes)
the whims of the memory management algorithms.  Since a task does not
control how much memory it does or does not get, real memory cannot
legitimately be used for chargeback.  In addition, because the amount of
memory allocated varies widely from run to run, attempting to charge for
real memory space-time occupancy would have very serious problems with
repeatability.
   See the paper on I/O Blocksizes in Chapter 42 of the 1984 MXG Guide.
   PAGESECS variation of 30-40% were noted between execution of the same
   program!
You must treat the cost of memory just like the cost of floor space and
air conditioning; they cannot be explicitly allocated to users but must
be recognized as prerequisite resources you must purchase so that you
can deliver CPU cycles to user workloads.

   How do we know we need more air conditioning resources for our CPUs?
   We examine the thermometer and when it gets "too high", we buy more
   air conditioning.  Similarly, when we need more memory, we recognize
   its need by looking at the memory thermometer, the page fault rate!
   When it is "too high", we must buy more memory!

CHANNELS AND CONTROL UNITS

Channels and control units are meant to allow programs in execution to
read and write blocks of data. Channels and control units are shareable
resources, and their charges should be distributed based on usage. If
channels and control units serving tape devices are separate from those
serving disk devices, it is reasonable to sum the cost of tape channels
and control units and divide by the number of tape I/Os in order to
establish a price-per-tape I/O.  Similarly, sum the cost of disk
channels and disk control units and divide by the number of disk I/Os to
establish a cost-per-disk I/O.  Under MVS/ESA using I/O connect time
instead of I/O counts is much wiser, as it eliminates the inequity of
charging the same for a 99 byte I/O as for a 32760 byte I/O, and is
strongly recommended.  In addition, since I/O counts in RMF are the
number of I/O operations, SSCHs (formerly SIOs), but SMF I/O counts can
be either EXCPs (blocks transferred, for sequential access methods) or
SSCHs for all other access methods), additional validation problems will
result if I/O counts are used instead of I/O connect time.

The key issue is to distribute the cost of the shared channels and
control units to the users who use them in moving blocks of data.  Some
channels and control units service only the data center - eg., paging
channels. Their costs must be included in the cost of memory and cannot
be not directly charged to users.

Even this resource recovery is no longer straightforward.  When we use
memory as buffers (CICS LSR, DB2 Buffer Pools, etc.), the recorded I/O
operation will be counted only for the first user that caused the I/O
operation.  If that block of data remains in the buffer all day long,
other users will not count an I/O and thus will not be charged!  Is it
fair, then, to charge the bright user who came to work earliest for his
I/O and give a free ride to the johnny-come-latelies?  Probably not!

And this is not just a problem with program buffers.  Cached controllers
create exactly the same problem with both I/O counts and I/O connect
time: I/O time is much less when the data is already in the cache!

DISK DRIVES

Disk drives are used to store data, and the owner of the data should pay
the storage cost.  If an entire volume is dedicated to an application,
the monthly cost of that volume can be billed to that application.  For
shared disk drives, the VTOC/VVDS can be read and used to identify the
owner of each data set, who can then be charged for the number of bytes
allocated.  One method is to take the total cost of the disk drive,
divide by the number of bytes on the volume, but this only recovers
costs if 100% of the volume is allocated, so the percentage of the DASD
farm's capacity that can be allocated must be determined, and used to
inflate the per byte cost of DASD storage.

DCOLLECT, an SMF IDCAMS facility will read VTOCs and VVDSs to create a
flat file processed by TYPEDCOL to record non-VSAM allocation and usage
and VSAM data space allocations (in DFSMS 1.1).  Alternatively, MXG has
ASMVTOC and ASMVVDS programs to dynamically allocate all DASD devices
and read their VTOCs and VVDSs to provide considerable more detail (for
example, location of each extent for non-VSAM, and VSAM space used for
VSAM), with or without SMS.

TAPE DRIVES

Tape drives are owned for the life of each allocation by a specific job.
It is the duration of allocation that must be used to distribute the
cost of tape drives. The PDB.STEPS contains TAPEDRVS, the number of tape
drives allocated by the step, and EXECTM, the duration of step execution
after drives are allocated, so their product is used to calculate tape
drive hours per job.  You can sum all jobs to get the total tape hours
allocated; divide that sum into the dollar costs of your tape drives to
determine the per-hour tape drive charge. This measure reflects actual
elapsed time of a job step and is a good measure if your installation is
reasonably well tuned, causing job elongation to be constrained.

If you have widely varying execution times, however, it may be unfair to
charge tape drives based on true elapsed time. If the installation wants
to eliminate the variability of tape drive hours due to using the actual
elapsed hours, you can instead estimate the number of hours that the job
would have used the tape drive if it was the only job in the system. You
can execute tape jobs in a controlled run and determine the relationship
between tape drive hours and the tape resource (connect time or EXCPs)
to establish an equation that estimates the billable tape drive hours
from each I/O connect second (or EXCP).  These estimated billable tape
hours can be summed and divided into the cost of tape drives to create a
per unit rate for billable tape drive hours to recover tape drive costs.

However, there remains one serious problem in using step records for the
calculation of tape drive hours: dynamic allocations.  The step record
contains a DD segment for each tape allocation, with the unit address of
the tape drive, but there is no flag to indicate if the tape drive was
allocated for the entire life of the step (statically), or if the tape
drive was deallocated dynamically (using FREE=CLOSE, for example), or
dynamically allocated and then dynamically deallocated for brief periods
of time (as done by both HSM and DB2MSTR).  MXG's variable TAPEDRVS is
the number of unique tape drive addresses found in the step record, but
if DB2MSTR happens to allocate a tape drive 15 times during the day (as
it does to back up the log), and if each allocation happens to get a
different drive address, the step record for DB2MSTR will look like it
had 15 tape drives allocated for the entire life of the step!  The only
safe solution is to identify which jobs use dynamic allocation of tape
devices, and to then exclude those jobs in charging for tape drive
hours!  Only dynamic deallocation is recorded in the type 40, and it can
not be enabled just for tape drives, so enabling type 40 to count tape
dynamic allocations would also create many type 40s from TSO users.  MXG
member ASMIEFU8 is SMF exit IEFU83 code that filters only type 40s for
tape deallocations that will let you enable type 40s to identify which
jobs have to be excluded from tape drive charges.

The MXG Tape Mount Monitor, ASMTMNT, is being modified to also track
tape drive allocation-to-deallocation, and it will write an SMF record
for each tape drive allocation, dynamic or static, which can then be
used directly to account for and measure tape drive allocation hours.

TAPE VOLUMES

Storage of tape volumes requires floor space and racks. The total cost
of storage can be divided by the number of tapes in the library to
establish a monthly cost for a stored volume. The tape management system
catalog can be used to determine ownership of each volume, and a daily
or weekly program can determine the number of days each volume is owned
by its creating user, who can then be charged at one-thirtieth of the
monthly rate for each day of tape storage. The job costs of the tape
management system runs can also be added to the storage costs if they
are significant.

TAPE MOUNTS

Tape mounts require people time. Scratch tape mounts require a great
deal less people time than permanent tape data sets do. Unfortunately,
SMF does not record any durations for tape mount time but provides only
the count of mounts for each step for billing. The TYPE30 step data in
PDB.STEPS can be used to identify scratch requests from specific volume
requests.  A work study analysis could be used to identify the ratio of
time to fetch and mount permanent volumes versus the time to fetch and
mount scratch volumes, and, thus, the relative cost of a permanent mount
to a scratch mount can be established.  The total cost of tape mounter's
salaries can then be distributed by time to mount a scratch or permanent
tape at different rates, and the job steps causing mounts can be charged
appropriately.

Since the duration and nature of each tape mount is recorded in SMF with
the MXG Tape Mount Monitor, ASMTMNT, it is used not only for chargeback,
but also for monitoring the efficiency with which tapes are mounted.

PRINTERS

The TYPE6 record data in the PDB.PRINT data set provides the data needed
to distribute the cost of printing to the end-user.  The method used in
distributing these costs depends on the type(s) of printers used.  What
works for one class might not work for other classes of printers.

For older line printers, charges based on the number of lines printed is
probably the most accurate and equitable method.  For some of the
early laser printers (like the IBM 3800-1) the line count can be
distorted by font changes within lines but counting lines printed is
still the best method.  The PDB.PRINT variable TOTLINES, which is
TOTLINES=SUM(PRINTLNE,PUNCHCRD,EXTWTRLN), must be used to count lines.
Almost all lines printed now are counted in the EXTWTRLN field, because
IBM changed OUTDEVCE (it used to contain the name of the printer or
punch, but it now contains the VTAM node name, so PRint versus PUnch can
not be detected, and EXTWTRLN is the fall-thru bucket!).

PSF printers should be billed based on the number of sheets printed,
SHEETPRN, which is the number of physical page sides that were printed.
SHEETPRN per minute is a good printer throughput measure; the printer
can never produce sheets at more than the rated speed of the printer,
and thus using SHEETPRN recovers the cost of the individual pieces of
paper, and the exclusive use of the printer.  Alternatively for PSF, you
may want to consider the use of DOCLENFT (the length of the paper
printed).  This number is useful because the meter that is read by the
CE each month is measuring the number of feet of paper that passes
beneath the print head and thus your printer maintanence bill is
directly related to DOCLENFT.  There is one small problem with this
number that only applies to continuous form printers like the IBM
3800-3.  DOCLENFT is always measured in the direction of paper flow.  In
the case of a cut sheet printer, this is ALWAYS across the 8.5 inch side
of a standard size sheet of paper.  Continuous forms can be obtained
with the tractor feed on either the 8.5 inch sides or the 11 inch sides
and the same document can be produced on either stock simply by rotating
the text (which may be as simple as changing the form number.)  Thus a
100 page job could potentially reflect 70.8 feet one day and 91.75 on
another simply by changing the paper.  If you are still using the forms
with the feed on the long side, you may want to evaluate the possible
cost savings of using the other orientation of the paper.  What about
PAGECNT?  Don't use it.  To PSF printers, one page is one sheet of paper
whether SIMPLEX or DUPLEX.  Thus a user printing a 100 page document
DUPLEX would be billed for 50 pages while a SIMPLEX user would be billed
100 pages for the same document.

What is in TOTLINES under PSF?  It all depends: line-mode data counts
the number of line images spooled in TOTLINES, and PSF-mode data counts
the number of records spooled, but a record could be single line or a
multi-page graph.  You can tell that PSF created the type 6 data because
variable SUBSYS6='PSF' (others are: JES2,JES3,EXTW,SAR,EXD,CADI,BUND),
but there's nothing in the type 6 to identify the print's data mode.
  Nov 2005 notes:
  1. TOTLINES can be very large when the record has a file transfer
     segment (variable SMF6BYTE will be non missing).

  2. IBM variable SMF6PRMD does identify LINE vs PAGE mode in SMF 6 PSF
     records.

Print workstation printers (Xerox printers like the 4050, 4090, 4135,
and 9700s) present other challenges, because they contain their own
operating systems and disk storage (early Xerox used a PDP 11 inside),
and the PDB.PRINT information represents only what was sent by JES or
PSF to the print workstation.  PRINTIME/PRENTIME are the time print was
transmitted, and not when actually printed.  These printers can store
the SYSOUT, print the SYSOUT, copy it to tape or floppy, or purge the
output prior to printing all without notifying the MVS host of the
action taken!  To further muddy the water, there are commands, called
DJDEs, that can be sent along with the datastream to modify the number
of copies, to set print to SIMPLEX or DUPLEX, to set how many logical
pages are on a physical page, etc.  This all means that any relationship
between the TYPE6 record and what actually happened on these printers is
purely coincidental.  The good news is that there is a Xerox-provided
facility, SFS, that will create a billing record of each
job printed with the print facilities actually used, including the
number of sheets of paper printed and which bins were used.  The
bad news is that SFS does not automatically send these data records to
the mainframe, and that you must modify SFS (see the example in member
ADOCSFS) to add the JOB name and JESNR to the SFS record.

Although special forms are less common than earlier, they still exist
and users should be charged for the use and storage of the special forms
that they use.  All of these data sources provide indications of the
forms that were used and these should be charged based on the operator
time to mount the form (like a tape mount) and the cost of storing the
blank forms (like a tape volume.)

TERMINALS, CONTROL UNITS, AND PORTS

If a terminal is shared across applications (for example, a VTAM
terminal used for CICS, TSO, and CMS), it is difficult to distribute the
cost of that terminal since not all applications provide a connect time
measure.  It is even worse, if a session manager product is used, for
the same terminal may be logged on to multiple systems simultaneously.
If the terminal is exclusively or mostly used by a single application,
say CICS, then the monthly cost of the terminal and its share of the
control unit and 3705 can be distributed directly to that application by
fixed monthly charges.  If TSO terminals are shared by different
departments, the duration of each TSO session and the terminal name are
both contained in the session data in PDB.JOBS, allowing numerous
opportunities for distributing the cost of terminals to individual
departments and identifying which terminals are used by which
departments.  For terminals used by IMS and CICS, there are no connect
time records, and cost accounting of terminal usage must be done
externally.

VI.   VM Technical Notes

  1. IBM APAR VM52395 applies to VM/ESA 1.1.1 and corrects invalid
     values for EXCPPGIN and EXCPPGOU in type 01 VM accounting records.

VII.  CICS Technical Notes

  1. IBM Document ID Q504977 discusses using the "Main Task" CPU TCB
     time to determine the "single engine requirement" for a CICS
     region, but the calculation of "Main Task" CPU TCB in that article
     is wrong, and produces a CPU measure which is not only not the
     Main Task CPU time, but in fact is greater than the total CPUTCBTM!
     The article calculated "Main Task" by subtracting the "Wait Time"
     OSWAITTM (MXG name, OSWTELAT IBM name) from the interval duration.
     Since the calculation produced a value greater than CPUTCBTM (MXG
     name, ADSPTIME IBM name), I conclude that OSWAITTM is not capturing
     all of the wait time in the CICS region and have asked IBM for
     comments.   However, the primary message of that article is good;
     it is the Main Task CPU time that must be used to determine the
     single engine requirement, which is why the CICSYSTM dataset in MXG
     contains variables MAINCPTM and SUBTCPTM with their sum CPUTCBTM!

VIII. SAS Technical Notes

  1. This technical note summarizes my investigation of virtual storage
     use in a very large BUILDPDB, so that I could better understand
     MEMSIZE required, and this note is simply technical information.
     See the subsequent note on MEMSIZE and REGION for recommendations.

     The virtual storage required by BUILDPDB for I/O buffers is set by
     SAS options BLKSIZE=, BUFSIZE, and BUFNO=.  The BLKSIZE= option is
     an attribute of the SAS data library, and it sets the size of the
     physical block that will be moved to and from DASD.  The BUFSIZE=
     option is an attribute of each SAS dataset and each SAS dataset in
     a data library can have a different BUFSIZE.  The BUFSIZE must be
     a multiple of BLKSIZE.  The default BUFSIZE=0 causes SAS to compute
     an "optimum" BUFSIZE based on the record length of an observation.
     The BUFNO= option is the number of buffers of size BUFSIZE that are
     allocated in virtual storage.  Each SAS dataset needs BUFNO times
     BUFSIZE virtual storage.  A very large BUILDPDB (164 datasets vice
     81 in the default BUILDPDB) was tested with BLKSIZE=4096, BUFNO=2,
     and with BUFSIZE=24576 and required TOTAL MEMORY=34269K.  That was
     reduced by 7244K when BUFSIZE=4096 was used; by extrapolation, the
     total buffer virtual memory required with BUFSIZE=24756 is 8451K,
     or 25% of the total virtual storage of this SAS data step.  An
     additional experiment was run to investigate the virtual storage
     impact of %INCLUDE and oldstyle macro processing (by saving the SAS
     log with source code to disk); it showed that the %INCLUDE and old
     style macro processing required 6336K virtual storage.  These tests
     are summarized in the following virtual storage map:

          TOTAL VIRTUAL MEMORY allocated            34269K

             data set buffers                               (8451K)
             macros/include processing                      (6336K)
             generated program size                         (2181K)
             task memory                                    (4842K)

          Unidentified (compiler,spvr,etc)          12459K

     As a final reminder, this 34269K run was a very large BUILDPDB.
     The default BUILDPDB in MXG 10.1 requires only 14857K! These tests
     were run using ENTRY=SASHOST, so that all of the virtual storage

     required came out of the user's address space.  If your site has
     installed SAS in the LPA and you use entry=SASLPA, you will see a
     2M to 4M reduction in the virtual storage used by your ASID.

     While this was informative, it turns out the real value of these
     tests was the confirmation of my long-held belief that the use of
     oldstyle (substitution) macros and %INCLUDEs has no significant
     impact on the cost of execution (save for the 6M virtual storage).
     The CPU time for the full blown BUILDPDB was 106.0 seconds; the
     pure code run with no macros nor %INCLUDES was 94.5 seconds!

       The blocksize used, 4096, IS NOT RECOMMENDED for MXG, but was
       used so BUFSIZE could be iterated.  MXG still strongly recommends
       all of its SAS data libraries be built with half-track blocksize
       (23040 for 3380, 27648 for 3390s), which causes BUFSIZE to also
       be half-track, and with BUFNO=2, SAS will move one track of data
       per physical I/O operation.

  2. MEMSIZE and REGION.  The SAS option MEMSIZE sets the total virtual
     storage above AND below the 16MB line that SAS can use.  The "very
     large" BUILDPDB that needed 34269K total virtual was executed with
     REGION=4M and MEMSIZE=38M, and the job's SYSOUT message IEF374I
     shows VIRT 2072K EXT 32768K for a total of 34840K above and below.
     The EXT 32768K value shows we were limited to 32M above the line,
     which is the IBM default specified in IEFUSI.  If the job actually
     needed 42M, the job would fail because the 32M above plus the 4M
     below total only 36M.  We could have specified a REGION=9M
     to get a total MEMSIZE of 41M, but the size of your private area
     (typically 9M max) limits how much you can get below the line!
     The solution is simple.  Specify a REGION=42M, while overrides the
     IEFUSI default of 32M, and you can get what you need.  (Note that
     you cannot specify a REGION value between the private area and 16M,
     but a value greater than 16M is valid.   Since the default BUILDPDB
     in MXG 10.1 requires only 15M, few sites should have a problem!
    -z/OS 1.12 message IEF032I/33I replaced IEF374I/276I.

  3. SAS options can be restricted by your site's SAS installer. The
     restrictions are in BAMISC(SASOPTRS) used by job BAOPT2(BAOPT2),
     which creates a load module named SASOPT73 (was SASOPTRS in 6.06),
     that must be in a linklist library.  So how do you know that your
     installer created this module?   From TSO "READY", simply type in
     SASOPT73.  If you get a "COMMAND NOT FOUND" message, then there
     are no local restrictions in effect; if you ABEND, you have the
     proof that there are local restrictions placed on SAS options!

  4. Multi-volume SAS datasets can be created as described in the
     "SAS Companion for the MVS Environment", pages 533-534, but that
     implementation requires permanent datasets to be allocated and
     cataloged, and is not well suited for temporary data libraries like
     //WORK that may need multiple volumes!  Sites with System Managed
     Storage, SMS, have what appears to be a superior solution that does
     allow SAS to use multi-volume data libraries for temporary files.
     You need only to have your SMS Storage Administrator create an SMS
     Storage Class with the "Guaranteed Space" attribute. Since a volume
     can be in multiple storage classes, you can put your existing DASD
     temporary workspace volumes in this STOCLASS.  You then need only
     to specify this STOCLASS for your WORK DD, with UNIT=(SYSDA,3), and
     with VOL=SER=(VOL1,VOL2,VOL3) and you are home free!  This works
     because the "Guaranteed Space" attribute does two things.  First,
     it permits you to specify a VOLSER on your DD (normally, only SMS
     itself can be the VOLSER godzilla!).  Second, it allocates one
     primary extent on each VOLSER you specify, thereby creating a DSCB1
     entry with the same DSNAME in each VTOC, which is all that is
     really required for SAS to be able to use the multiple volumes.

     Note that the SMS name "guaranteed space" is a slight misnomer,
     since SMS can't guarantee there will be free space on the volumes,
     but it does guarantee that if the space you allocated is available
     at initial allocation time, it will still be there until the job
     ends.  (In a non-SMS environment, UNIT=(SYSDA,3) allocates only the
     first volume until it needs to go to the next volume, and your job
     could die hours into its run if that third volume was full when you
     finally needed it.)  The IBM SMS manuals advice caution in the use
     of "guaranteed space"; the only rationale I know is concerned with
     archived and then restored by HSM, which requires the same VOLSERs
     to have space for the restore, but that does not apply if your use
     is for a temporary library that goes away at end of job!  Your DASD
     storage administrator may not like it because it takes control away
     from SMS, but I know of no other objection, and this technique has
     been in use by its discoverers, John Astle and Wayne Moray-Hype of
     National Australia Bank for three months with no problems.  By the
     way, you could write ACS routines to select the VOLSERs and would
     then not have to specify them on your DD statement.  Additionally,
     this technique can be used with a temporary or permanent DSNAME.

  5. SAS 6.07 CMS had a problem with %INCLUDES; only the first library
     in a concatenation was examined.  Tracking 248801 is still open,
     but using GLOBAL statement (see REXXTES6 example) circumvents!

  6. SAS 6.07 ZAP Z6074721 corrects 0C4 ABEND in the %MACRO compiler if
     a double ampersand (&&) was encountered.

  7. Usage note 2665 (to be fixed in September 93 Maintenance) discusses
     an ABEND of PROC COPY when a zero-observation dataset that has the
     "Sorted" flag turned on is copied to a tape-format data library.
     This ABEND only hit one MXG site, but since many sites copy their
     Daily and Weekly PDBs to tape with PROC COPY (in fact, that is the
     MXG recommendation for archiving), why did we not see this ABEND in
     MXG testing of SAS 6.07?  Well it turns out there are two different
     kinds of zero-observation datasets, and the ABEND affects only one.
     In SAS 6.07, a dataset now has a "Sorted" flag if that dataset is
     known to be sorted by SAS (a "strong SORT assertion").  But if you
     PROC SORT an input zero-observation dataset to an output dataset,
     the "Sorted" flag is not enabled in the new dataset.  Since all of
     the MXG-built zero-observation datasets are built by PROC SORT from
     zero-observation input datasets, none have the "Sorted" flag on,
     and thus PROC COPY of MXG PDB's to tape did not fail.  How do you
     build a zero-observation dataset with the "Sorted" flag on?  Well,
     here's one way:   OPTIONS OBS=0; PROC COPY IN=MON OUT=SAT; RUN;
     to initialize a PDB library with zero-observation datasets.  While
     the MON.datasets that had zero observations are copied into SAT as
     "NotSorted", all of the MON.datasets that had non-zero observations
     are copied into SAT now as "Sorted", and if you now try to use a
     PROC COPY IN=SAT OUT=TAPE (for example, to backup the SAT library),
     the PROC COPY ABENDed!   As you can see, the exposure to this SAS
     error was extremely limited - in fact, only one MXG site reported
     the error, though the problem did affect other SAS customers!
       Note: the MXG Circumvention without the September maintenance
       is to not backup SAT until you have put data in it!

  8. INVALID HEADER for a dataset in the WORK library has occurred in
     three sites, ABENDing the job, but a re-run has (thus far) always
     been successful.  Since the error has not been repeatable, the SAS
     Institute folks can't work on the problem.  Tracking 256220.

  9. Complex nested parenthesis inside a SUM() function can result in
     invalid values.  This has not occurred in any MXG use of SUM(),
     but was noticed in user report code.  Zaps Z6073413,2570,and 4338

     are required to eliminate the exposure.

 10. PROC GPLOT fails with "THE SAS SYSTEM STOPPED PROCESSING THIS STEP
      BECAUSE OF ERRORS" with no other error condition. The error occurs
      when the input dataset has zero observations, and is corrected by
      SAS Zap Z6071258.

 11. SAS 6.07 may go into a CPU loop if the //WORK DD specifies multiple
     volumes with UNIT=(SYSDA,3).  As described in item 4, above, you
     cannot use that MVS multi-volume specification for SAS libraries.

 12. Although documented by SAS on page 65 of the SAS 6.07 Changes and
     Enhancements, you may have overlooked that the XSWISS font name
     no longer exists, and it must be replaced with SWISS.

 13. SAS 6.07 may fail with an 0C4 ABEND due to an error in the SAS
     Data Step Compiler.  Temporary ZAP V6-SYS-DATA-5266 corrects the
     problem (it will be on the May 1993 SAS Usage Notes tape) and this
     problem appears to be avoided in SAS 6.08, so this is presently a
     6.07-only problem.

 14. SAS 6.07 error in the CCHHR option causes VMXGVTOC to miss extents
     and produce "CRITICAL ERROR IN VTOC PROCESSING" if there are more
     than three extents.  SAS ZAP V6-SYS-FILE-4673 is available on the
     June 1992 SAS Usage Notes Tape.  This error was apparently only in
     the CCHHR option, and not the similar but different CCHHR= option.
     This error did not affect the recommended alternative to VMXGVTOC,
     the ASMVTOC/VMXGVTOF members which are faster, better, and do not
     use either CCHHR or CCHHR= options. This note was in Newsletter 22.

 15. MXG has always shown JCL samples using the SAS or SAS607 procedure,
     adding the CONFIG= parameter, and DDs for //LIBRARY and //SOURCLIB,
     but now there is an MXGSAS JCL Procedure in the MXG Source Library.
     All MXG JCL examples now use // EXEC MXGSAS to minimize JCL errors
     for new users, and member INSTALL expects you to put MXGSAS in your
     Proclib.  However, MXGSAS is also an instream PROC in JCLTEST6 and
     JCLPDB6 members, so you can test before putting it in PROCLIB.
     Since the new install procedure suggests 'MXG.V1010.x.y' as the
     High-Level for your testing of MXG 10.10, and then renaming the
     'MXG.V1010.x.y' libraries to 'MXG.x.y' Production names,  MXGSAS
     defines MXGHLQ= as the MXG Hi-Level Qualifier, and SASHLQ for SAS
     Hi-Level Qualifier, so Testing would use

         //  EXEC MXGSAS,MXGHLQ='MXG.V1010'

     and after you have renamed the test libraries to production, only

         //  EXEC MXGSAS

     is required.  Note that CONFIG=MXG.MXG.SOURCLIB(CONFIG07) is not
     required with MXGSAS, as (CONFIG07) is already inside the PROC.

     For large volumes of input records, you can specify TIME= in CPU
     minutes, WORK= space in cylinders (and in rare cases, SORT= wor
     space in cylinders).

IX.   Change Log

--------------------------Changes Log---------------------------------

 You MUST read each Change description to determine if a Change will
 impact your site. All changes have been made in this MXG Library.

 Member CHANGES of the MXG SOURCLIB will always be more accurate than
 the printed changes in a Newsletter, because the software is created
 after the newsletter is sent to the printer!

 Member CHANGES always identifies the actual version and release of
 MXG Software that is contained in that library.

 The actual code implementation of some changes in MXG SOURCLIB may be
 different that described in the change text (which might have printed
 only the critical part of the correction that can be made by paper).

 Scan each source member named in any impacting change for any comments
 at the beginning of the member for additional documentation, since the
 documentation of new datasets, variables, validation status, and notes,
 are often found in comments in the source members.


Alphabetic INDEX of significant changes in MXG 10.10 (since MXG 9.9):


  Member    Change   Description

  All      10.175  Powerful new "_L" and "_K" macros tailor MXG datasets
  All      10.261  Support for MVS/ESA 4.3.
  ADOCAAAA 10.087  Twenty-Five ADOCs documentation members now exist.
  ANALDB2R 10.001  DB2 Report truncated character values.
  ANALDB2R 10.034  SORTBY= operand parsed only the first SORT variable.
  ANALDB2R 10.046  LIBRARY SMF IS NOT VALID message with PMSQL04 report.
  ANALDB2R 10.047  DBID/OBID hex values printed instead of name.
  ANALDB2R 10.055  Date/time selection in PMSACC01/02 produced no report
  ANALDB2R 10.094  ANALDB2R Accounting report uses ASUMDB2A if exists.
  ANALDB2R 10.135  DB2 Audit report may not be produced.
  ANALDB2R 10.158  DB2 SQL Trace report FORMAT NOT FOUND error.
  ANALDB2R 10.272  Buffer Pool statistics average values wrong.
  ANALDSET 10.097  VSAM data sets may have wrong PROGRAM name.
  ANALMONI 10.066  TMON/CICS sample report filled WORK file.
  ANALRMFR 10.301  IBM's RMF reports produced from MXG datasets.
  ANALRMFR 10.301  IBM-formatted RMF reports are now produced by MXG.
  ASMIMSLG 10.084  Major revision in IMS log processing algorithms.
  ASMIMSLG 10.142  Revision to "Appended" IMS log processing.
  ASMIMSLG 10.191  "Appended" IMS process might miss RACF segment
  ASMISMLG 10.146  New "Appended" IMS log processing works with IMS 2.2.
  ASMTMNT  10.012  MXG Tape Mount Monitor supports Dynamic I/O Reconfig.
  ASMTMNT  10.136  (MXG 10.1 only). ABEND S55F at startup.
  ASMTMNT  10.226  MXG Tape Monitor sets TMNTRTRN=3 for MIM event.
  ASMTMNTO 10.177  MXG Tape Mount Monitor for sites still on MVS/XA.
  ASMVTOC  10.073  Avoid 213/314 abends reading VTOC of VM/TPF volumes
  ASMVTOC  10.157  (MXG 10.1 only). Assembler error MSGAREA.
  ASMVTOC  10.202  Use ASMVTOCO for ASMVTOC under MVS/ESA 3.1.3.
  ASMVVDS  10.156  ASMVVDS fails with User 666 Abend.
  ASUM70PR 10.131  PR/SM,MDF,MLPF summarization now supports 16 LPARs.
  ASUM70PR 10.218  MXG 10.2 only, corrupted Effective/Management times.
  ASUM70PR 10.284  Amdahl MDF LPARNUM=0 now supported.
  ASUMDB2A 10.090  DB2 Account "transactions" summarized into ASUMDB2A.
  BUILDPDB 10.117  BUILDPDB under SAS 6.07 needs changes.
  BUILDPDB 10.129  Execution under CMS requires changes.

  BUILDPDB 10.153  Step account variable SACCT1 now added to PDB.
  BUILDPDB 10.190  JES APAR OY56235 filling SPIN library circumvention.
  BUILDPDB 10.298  TOTLINES added to PDB.PRINT dataset.
  CMS      10.129  SAS 6.07 under CMS has problems for MXG.
  CONFIG07 10.109  Option S=72, s2=72 added to MXG Config members.
  EXCICJRN 10.132  New exit for CICS journal data sent to SMF.
  EXTY72   10.064  CPURCTTM PTF now exists, circumvention removed.
  GRAFDB2  10.151  Not all DB2 graphs were produced.
  GRAFLPAR 10.052  LPAR CPU utilization reports added.
  GRAFTRND 10.049  Graphic trending reports were not always correct.
  GRAFxxxx 10.227  SAS 6.07 replaced XSWISS font name with SWISS.
  IMACACCT 10.119  Invalid type 30 subtype 1 SMF caused INPUT STATEMENT.
  IMACDB2  10.149  CORRNAME/CORRNUM set from QWHCATYP now.
  IMACDOS  10.168  Support for VSE DOS POWER Version 4.2 account records
  IMACFACO 10.100  Fujitsu's FACOM MSP/EX SMF records now supported.
  IMACFMTS 10.173  Member made archaic by SAS 6.07 FMTSEARCH option.
  IMACICSA 10.164  Support for SAP Accounting data in CICS type 110.
  IMACICUS 10.297  Optional HOGAN application variables in CICSTRAN.
  IMACPDB  10.053  New macro _DB2ACCT added. Compatibility exposure.
  IMACPDB  10.068  TAPE3490 (3490s allocated) added to PDB.STEPS/JOBS.
  IMACPDB  10.133  PDB.JOBS can have JELPSTM missing when it should not.
  JCLPDB6  10.127  (MXG 10.1 only) JCLPDB6 fails, TYPETMNT not found.
  JCLTEST6 10.030  INVALID DATA FOR SMFTIME, SAS zap MV313550 required.
  MNTH.... 10.091  Trending with INTERVAL=MONTH members added.
  MONTHBLD 10.206  All JCLPDB6 PDB & ASUM.... datasets are in MONTHBLD.
  READDB2  10.045  TRACECLS= parameter does not select all IFCIDs.
  RMFINTRV 10.299  Additional statistics added to RMFINTRV dataset.
  TRNDDB2A 10.093  TRNDDB2A Account Trending uses ASUMDB2A if exists.
  TTXPDS   10.111  Verstand's TTX product is now included in MXG.
  TYPE102  10.072  DB2 SQLCODE can be negative, MXG read as positive.
  TYPE102  10.170  DB2 Trace IFCID 172 and 177 now tested and supported.
  TYPE102  10.174  DB2 optimizer's cost estimate was incorrect.
  TYPE102  10.183  DB2 Trace statement Numbers now print as decimals.
  TYPE102  10.281  DB2 T102S044 lock fields were incorrect.
  TYPE110  10.017  Invalid type 110 subtype 2 could cause MXG to loop.
  TYPE110  10.038  Omegamon error causes INVALID DATA FOR SMFPSRSN.
  TYPE110  10.059  Type 110 STOPOVER due to bad record eliminated.
  TYPE110  10.061  Support for CICS/ESA 3.3.0 monitor (CICSTRAN) data.
  TYPE110  10.062  Support for CICS/ESA 3.3.0 statistics datasets.
  TYPE110  10.234  Enhanced CICS error messages for EXCLUDE/INCLUDE.
  TYPE110  10.278  OMEGAMON/CICS V550 DATACOM SPE is incompatible.
  TYPE110  10.280  Fourth TCBs CPU time was not included in CICINTRV.
  TYPE24   10.037  Spool off-load type 24 can cause STOPOVER abend.
  TYPE28   10.095  Blue Line's Vital Signs for VTAM type 28 supported.
  TYPE28   10.106  NPM 1.5.1 NPMEVX25 (subtypes 144-150) error fixed.
  TYPE28   10.134  Line PCTBUSY in each direction measured separately.
  TYPE28   10.141  (MXG 10.1 only). INVALID DATA FOR NPMPDUTH.
  TYPE28   10.155  NPM variables LLBSSTIM/LLBSPTIM incorrect.
  TYPE28   10.264  Support for NPM Release 1.6
  TYPE30   10.031  Variables ACTDLYTM, RESDLYTM, DSPDLYTM created.
  TYPE30   10.108  Some APPC variables in TYPE30 have wrong value.
  TYPE33   10.232  Error in processing SMF type 33 (APPC) records.
  TYPE37   10.098  System Center's NETMASTER type 37 SMF record support.
  TYPE37   10.167  Support for Type 37 Network Alert APAR OY49717.
  TYPE39   10.040  INPUT STATEMENT EXCEEDED for subtype 5.
  TYPE40   10.065  New dataset TYPE40_D can be created for tape analysis
  TYPE41   10.015  DIV type 41 SMF record timestamps mis-documented.
  TYPE42   10.005  Type 42 SMF record causes STOPOVER ABEND.
  TYPE6    10.003  PSF type 6 record had FORM truncated.
  TYPE6    10.124  Incompatible change to type 6 SMF record by PSF.
  TYPE6    10.139  PRUWTR type 6 SMF record has incorrect READTIME.
  TYPE6156 10.255  VSAM Data and Index component names & SMS data added.
  TYPE70   10.256  TCP/IP SMF record defaults to type 70!

  TYPE70   10.260  Negative CPUACTTM/PCTCPUBY in TYPE70 with PR/SM/
  TYPE7072 10.010  TYPE70PR variable NRPRCS corrected.
  TYPE7072 10.042  PCTRDYWT variable now created.
  TYPE7072 10.317  GMT Offset, GMTOFFTM, available in MVS/ESA 4.3.
  TYPE70x  10.320  Support for OpenEdition MVS, OMVS, RMF records.
  TYPE71   10.014  SWAP counts corrected.
  TYPE73   10.179  ESCON converter flag variable ESCACVC not set.
  TYPE73   10.247  MVS/ESA 4.2.2 EMIF Feature corrupts TYPE73 data set.
  TYPE73   10.259  Only real channels create TYPE73 observations now.
  TYPE74   10.137  MVS/ESA XCF Type 74 causes INPUT STATEMENT EXCEEDED.
  TYPE75   10.099  MVS/ESA 4.2.0 changed format of DEVNR/UNITADR.
  TYPE78   10.201  CMF Type 78 incorrect R783CPDN value causes 0 obs.
  TYPE79   10.123  Type 79 subtype 1 corrections.
  TYPE79   10.283  RMF 79 records appear to be un-deaccumulatable.
  TYPE80   10.114  CA TOP SECRET caused INPUT STATEMENT EXCEEDED error.
  TYPE80A  10.251  RACF events consolidated in new TYPE80A dataset.
  TYPE84   10.224  JES3 type 84 INPUT STATEMENT EXCEEDED error.
  TYPE94   10.285  Support for IBM 3495 Tape Library Dataserver SMF.
  TYPEAICO 10.048  Support for AICorp's KBMS user SMF record.
  TYPEAIM6 10.161  Support for FACOM's AIM Version 12 type 116 SMF.
  TYPEAPAF 10.078  Support for Amdahl's APAF replacement for MDFTRACK.
  TYPEAPAF 10.143  Variable Balance not kept in APAFDOMA
  TYPEASTX 10.245  Support for Legent's ASTEX Trace Record
  TYPECIMS 10.063  IMF flag variables wrong if multiple bits are on.
  TYPECMF  10.230  Boole's CMF variable R783PT in error.
  TYPECMF  10.292  Support for IMF Release 2.8.
  TYPEDB2  10.024  MVS Account fields added to DB2ACCT!
  TYPEDCOL 10.071  INVALID VALUE FOR FUNCTION DATEJUL message.
  TYPEDCOL 10.148  DCOLBKUP variables UBALLSP,UBUSESP,UBRECSP wrong.
  TYPEDCOL 10.221  DCOLLECT variable UCTOTAL was incorrectly documented.
  TYPEDCOL 10.307  DCOLLECT SMSDATA writes SMF constructs records.
  TYPEF127 10.162  Support for FACOM PDLF Type 127 for MSP/EX Version.
  TYPEFTP  10.176  NETVIEW FTP SMF record timestamps reversed.
  TYPEHIPR 10.300  Support for Empact's HiperCache SMF records.
  TYPEHPCS 10.178  Support for HP Unix (HP/UX) PCS Performance Data.
  TYPEHPCS 10.294  HP's MPE operating system records now supported.
  TYPEHSM  10.080  FSTTRKR/W large values are actually negative values.
  TYPEIDMS 10.219  IDMS variable DBKDBKEY was incorrectly documented.
  TYPEIDMS 10.265  Support for IDMS Release 12 PM records confirmed.
  TYPEILKA 10.121  Invalid data because incorrect offset/documentation.
  TYPEIMSA 10.142  STRTTIME/ENDTIME/INPQUETM/SERVICETM/RESPNSTM wrong.
  TYPEIMSA 10.205  NMSGPROC value wrong. Must use ASMIMSLG for IMS log.
  TYPEIMSA 10.288  Zero service time corrected.
  TYPEITRF 10.273  Support for Candle's IMS Trans Report Facility,ITRF.
  TYPEM204 10.120  MODEL204 variable M24IODEV input, EXM24ACT eliminated
  TYPEMON8 10.020  Landmark CICS "INVALID OFFSETS" message.
  TYPEMON8 10.067  MONITASK variables STRTTIME/CREATIME now equal.
  TYPEMON8 10.145  Landmark CICS variable TAMRCNT input incorrectly.
  TYPEMON8 10.271  Support for Landmark's/CICS Release 9 and Release 1.
  TYPENATP 10.033  Support for Software Ag "Natural Process" SMF record.
  TYPENETP 10.039  NETPACTM was total response, should be average.
  TYPENRS  10.075  Support for The Network Director North Ridge Software
  TYPENSPY 10.015  Support for NETSPY Token-Ring records added.
  TYPENSPY 10.057  Support for NETSPY Release 4.2 added.
  TYPENSPY 10.144  NETSPY type 'N' records cause INPUT STATEMENT EXCEED.
  TYPENSPY 10.262  Support for NETSPY Release 4.3 and LANSPY 1.1
  TYPEOMCI 10.182  Omegamon V550 ESRA (user) SMF "INPUT EXCEEDED".
  TYPEOMVT 10.194  Support for OMEGAMON II for VTAM V150 user SMF.
  TYPEOPC  10.112  Major revision for OPC/A log processing.
  TYPEOPC  10.204  Support for Changes to OPC records.
  TYPEOPC  10.302  RECFM= parameter removed so RECFM=U data can be read.
  TYPEORAC 10.291  Support for Oracle 6.0.33.1.51.
  TYPEPOOL 10.274  Support for Empact's POOL-DASD user SMF record.

  TYPEQAPM 10.110  Support for AS400 V2R1M0 and restructured members.
  TYPERMDS 10.102  RMDS messages INVALID DATA FOR RMDSMXVR eliminated.
  TYPEROSC 10.022  Support for ROSCOE Release 5.7 changes to SMF data.
  TYPEROSC 10.101  ROSCOE ADSFUN.. variables values corrected.
  TYPEROSC 10.138  ROSCOE JCK and Documentview added to ROSCOVPE.
  TYPERSxx 10.319  Support for RS6000 AIX VMSTAT,IOSTAT,PS commands.
  TYPESFS  10.186  Support for XEROX Printer's SFS Status File System.
  TYPESIM  10.180  Support for SIMWARE SIM/XFER VTAM user SMF record.
  TYPESIM  10.222  SIMWARE initial support revised.
  TYPESLRI 10.290  SLR-like IMS log processing for Fast Path.
  TYPESMF  10.019  Header/Trailer messages on log were not always right.
  TYPESPMS 10.011  SPMS R2.1.4 invalid record circumvented.
  TYPESPMS 10.069  SPMS 1.2.13 inserted four byte field, causing errors
  TYPESTC  10.105  STC 4400 decode used wrong bits of STC07TYP.
  TYPESTC  10.116  STC4400 HSC SMF record for Release 1.2 incompatible.
  TYPESTC  10.193  STC 4400 Silo HSC variables formatted.
  TYPESTC  10.229  STC 4400 variables LSBECON1/2 incorrectly documented.
  TYPESYNC 10.115  SYNCSORT variable COREREQ can be negative.
  TYPETCP  10.184  Support for IBM's TCP/IP Version 2 Release 2 SMF.
  TYPETIRS 10.181  Support for IBM type 96 SMF record from TIRS.
  TYPETMNT 10.200  Legent's MIM corrupts MXGTMNT Tape Mount count.
  TYPETMS5 10.060  TMS inactive DSNBs now deleted, caused wrong VOLSER.
  TYPETMS5 10.082  TMS.TMS had DSNB fields, TAPEFEET calculation changed
  TYPETMS5 10.185  DSNBs could have been skipped.
  TYPETMS5 10.196  TMS Billing-by-dataset enhanced in DSNBRECD dataset.
  TYPETMS5 10.289  "Dead" tapes no longer create DSNBRECD observation.
  TYPETMVS 10.058  TMON/MVS "INVALID DATA for WKLCPURF" message.
  TYPETPX  10.007  TPX variable TPXELAP has wrong value.
  TYPEVM   10.233  VMSQLxxx datasets enhanced for SQL/DS under VM.
  TYPEVMXA 10.036  VM/ESA 1.1.1 additions now supported.
  TYPEVMXA 10.071  VM/ESA VXSYTCUP dataset has only 49 observations.
  TYPEVMXA 10.163  Candle's VCOLLECT 5.1.0 still writes invalid "VVBs".
  TYPEVMXA 10.244  Support for VM/ESA Release 2.0.
  TYPEWSF  10.081  Support for RSD's WSF/WSF2 Release 3.4.1.
  TYPEWSF  10.150  WSF 3.3.6 caused error (no problem with 3.4.1).
  TYPEX37  10.013  STOPX37 Release 3.4 is supported.
  TYPEX37  10.276  Support for Empact's STOPX37 Release 3.5.
  TYPEXAM  10.231  Support for Velocity Software's XAMAP History files.
  TYPEXCOM 10.165  Support for XCOM 6.2 Version 2.2.2G SMF record.
  VMXGHSM  10.254  HSM dates TTOCDLR and TTOCXPDT were wrong.
  VMXGSUM  10.089  MINTIME=,MAXTIME= parameters added to VMXGSUM.
  VMXGVTOC 10.018  CRITICAL ERROR IN VTOC if DSORG=PS-SUL data found.
  VMXGVTOC 10.054  ISAM index space not recognized in VTOC.
  VMXGVTOC 10.243  SAS 6.07 ZAP V6-SYS-FILE-4673 required.
  VMXGVTOF 10.125  Variable DS4VTOCE input but not kept.
  VMXGVTOF 10.171  VTOCs with freespace starting in track 1 missed it.
  WEEKBLD  10.008  NOT SORTED when implementing MXG 9.9
  WEEKBLD  10.009  TYPE70PR,DB2ACCT/STAT0/STAT1 added to weekly/monthly.
  WEEKBLD  10.206  All JCLPDB6 PDB & ASUM.... datasets are in WEEKBLD.
  WEEKBLD  10.225  BY list for WEEK.ASUM70PR wrong.
  XMAC7072 10.023  344 Compiler circumvention causes UNINITIALIZED msg.
  XUNIX    10.076  Support for ULTRIX UNIX iostat and vmstat commands.

Inverse chronological list of all Changes:

---Changes 10.323-10.105 were printed in MXG NEWSLETTER TWENTY-THREE---
     and can be found in member CHANGES of MXG Version 10.10
****************NEWSLETTER TWENTY-TWO***********************************










              MXG NEWSLETTER NUMBER TWENTY-TWO July 10, 1992

Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE

                         TABLE OF CONTENTS
                                                                    page
I.    MXG Version Status.

 1. Production Version is still MXG 9.9, dated March 1, 1992.          2
 2. There was no MXG Software tape shipped with this newsletter.       2
 3. MXG PreRelease 10.1, July 10, 1992, is now available on request.   2
 4. Major enhancements and new products supported in MXG 10.1          2
 5. IBM Announcements and their MXG support.                           3
 6. What is planned in future MXG Software releases?                   3
 7. New MXG documentation is slowly being created.                     3

II.   MXG Technical Notes

 1. Can I Execute MXG on a PC or a UNIX workstation?  An MXG Position. 5
 2. Will SAS 6.07's compress option help MXG?                          6
 3. How do I run the PDB if my data center runs only six days a week?  7

III.  MVS Technical Notes

 1.APAR OY51878 (CPURCTTM in TYPE72) is corrected by PTF UY77275.      8
 2.APAR OY51053 (SYSTRNTM in TYPE72) is corrected by PTF UY77634.      8
 3.APAR OY52104 (invalid JOB characters) in 4/5 fixed by PTF UY78154.  8

IV.   CICS Technical Notes

 1.CICS/ESA 3.3.0 was incompatibly changed by IBM.                     8
 2.Omegamon V550 support requires installation tailoring.              9

V.    SAS Technical Notes.

 1.BUILDPDB with SAS 6.07 NOTE: ADDITIONAL INTERNAL PASS message.      9
 2.SAS 6.07 Error 31-185, Format not recognized, occurs if the SAS     9
 3.JCLTEST6 JCL 4MB REGION too small if MEMSIZE is limited by site.    9
 4.SAS 6.07 INFILE processing with END=END may not work as expected.   9
 5.SAS 6.06 & SAS 6.07 require BLKSIZE=23040 override to avoid error. 10
 6.SAS 6.07 error in CCHHR option causes VMXGVTOC to miss extents.    10
 7.SAS 6.07 does not recognize the EPILOGC infile exit name.          10
 8.SAS 6.07 may produce INVALID ALTER PASSWORD error message.         10
 9.SAS 6.07 copy from SMF VSAM file to BSAM VBS creates invalid data. 10
10.SAS 6.07 entry modules SASXA1 and SASXAL may ABEND with 0C4.       11

VI.   Installation, re-installation, and Space Requirements.          11
VII.  Important notes from prior Newsletters:                         13
VIII. Documentation of MXG Software.                                  15
IX.   Change Log -  Changes 10.104-10.001                          16-39



         COPYRIGHT (C) 1992 BY MERRILL CONSULTANTS DALLAS TEXAS

I.    MXG Version Status.

 1. Production Version is still MXG 9.9, dated March 1, 1992.

    The current Production Version, (the Software Version that was sent
    to all customers) is still MXG 9.9, shipped in March, 1992.  We plan
    to ship Production Version 10 on March 26, 1993  (because that is
    when MVS/ESA 4.3 becomes available).

 2. There was no MXG Software tape shipped with this newsletter.

 3. MXG PreRelease 10.1, July 10, 1992, is now available on request.

    MXG PreRelease 10.1 contains many significant enhancments, as shown
    below.  We will be happy to ship that software to you; just send us
    a fax (overseas sites can fax via their local SAS office) requesting
    MXG 10.1.  There is no charge for a PreRelease.

 4. Major enhancements and new products supported in MXG 10.1:

   Required for CICS/ESA 3.3,
   Required for VM/ESA 1.1.1,
   Required for TYPEIMS users; major revision in IMS log processing.
   Strongly recommended for DB2 sites, because it:
      - has significant corrections in ANALDB2R reporting,
      - has speeded up MXG DB2 processing and reduced WORK space needed,
      - allows DB2ACCT direct to tape for sites with large DB2 activity,
      - has new ASUMDB2A to summarize and reduce size of DB2ACCT.
      - has MVS Account fields added to DB2ACCT (DB2 2.3).
   Offers support for these new products or releases:
     Support for AICorp's KBMS user SMF record.
     Support for Amdahl's APAF replacement for MDFTRACK.
     Support for Blue Line's Vital Signs for VTAM type 28.
     Support for Fujitsu's FACOM MSP/EX (incompatible) SMF records.
     Support for MVS/ESA 4.2 Dynamic I/O Reconfig in MXG Tape Monitor.
     Support for NETSPY Release 4.2 added.
     Support for NETSPY Token-Ring records added.
     Support for ROSCOE Release 5.7 changes to SMF data.
     Support for RSD's WSF/WSF2 Release 3.4.1.
     Support for SPMS 1.2.13 incompatible changes.
     Support for STOPX37 Release 3.4.
     Support for Software Ag "Natural Process" SMF record.
     Support for System Center's NETMASTER type 37 SMF records.
     Support for The Network Director North Ridge Software
     Support for UNIX iostat and vmstat commands from ULTRIX.
     ASMVTOC avoids 213/314 abends reading VTOC of TPF or VM  volumes.
     LPAR CPU utilization reports added.
     MINTIME=,MAXTIME= parameters added to VMXGSUM.
     MVS/ESA 4.2.0 changed format of DEVNR/UNITADR in TYPE75.
     MXG Tape Mount Monitor supports MVS/ESA dynamic reconfiguration.
     New dataset TYPE40_D can be created for tape analysis
     TAPE3490 (3490s allocated) added to PDB.STEPS/JOBS.
     Trending with INTERVAL=MONTH members added.

    MXG PreRelease 10.1 replaces MXG 9.9 with minimal effort and usually
    transparently.  Beta sites have been running 10.1 since May.

    Each of these enhancements are described in the Change Log, page 16.

 5. IBM Announcements and their MXG support.

    The following table lists announced availability dates for the IBM
    product, and the corresponding Version of MXG required to support
    that IBM product.

      Product Name                     Availability     MXG Version
                                       Date              Required

      MVS/370, MVS/XA (all)            long ago             8.8
      RMF 4.1.2 (for MVS/ESA 3.1.3)    Sep  7, 1990.        8.8
      RMF 4.2   (for MVS/ESA 4.1)      Oct 26, 1990.        8.8
      MVS/ESA 4.1                      Oct 26, 1990.        8.8
      MVS/ESA 4.2                      Mar 29, 1991.        9.9
      RMF 4.2.1 (for MVS/ESA 4.2)      Mar 29, 1991.        9.9
      MVS/ESA 4.2.2                    Aug     1991.        9.9
      RMF 4.2.2 (for MVS/ESA 4.2.2     Aug     1991.        9.9
      MVS/ESA 4.3                      Mar     1993.       10.?
      RMF 4.3.0 (for MVS/ESA 4.3       Mar     1993.       10.?
      CICS/ESA 3.1                             1990         8.8
      CICS/ESA 3.2                     Jun 28, 1991.        9.9
      CICS/ESA 3.3                     Mar 28, 1992.       10.1
      DB2 2.2.0                                1990         8.8
      DB2 2.3.0                        Oct 28, 1991.       10.1
      VM/ESA  1.1.0 (370 Feature)      Oct 26, 1990.        8.8
      VM/ESA  1.1.0 (ESA Feature)      Mar 29, 1991.        8.8
      VM/ESA  1.1.1                    Dec 27, 1991.       10.1

 6. What is planned in future MXG Software releases?

    Enhancement of AS400 support is planned.
    Several companies have announced plans for VTAM monitors.
    TRIM for ADABAS is in planning; test data did not arrive in time.
    Goal Systems EXPLORE/VM support needs corrections.
    Landmark CICS Version 9 documentation/data has not been provided.
    Landmark TMVS new version documentation/data has not been provided.
    Boole & Babbage CICS/MANAGER is a future consideration.
    JES3 Tape Mount Merge with TYPETMNT is a future consideration.
    Cray UNICOS is a distant future consideration.
    VAX/VMS Account/SPM is a distant future consideration.


 7. New MXG documentation rewrite is in progress.

    Yes, there will be new printed documentation, which will combine
    the 1984 MXG Guide, the 1987 MXG Supplement, and the 700 pages of
    MXG Technical Newsletters, plus the notes and text buried in the
    various members of the MXG library.

    No, the new books will not be completed in 1992. (In last 1991 we
    re-printed both the 1984 MXG Guide and 1987 MXG Supplement to
    ensure we do not run out of print until the new books are done!)

    The complete re-write of MXG documentation began in the fall of 1991
    and is still in progress.  With over 1,000 MXG-built data sets and
    over 40,000 variables, the new Chapter FORTY style documentation
    would total over 4,200 printed pages, the equivalent of 6 books the
    size of the 1984 Guide, just for data set documentation!  This brief
    analysis led to the following plan of attack.

    For each "Product" or "Data Source" supported by MXG, there is a
    VMAC.... member which reads those data records and creates one or
    more MXG data sets.  For each of these VMAC.... code members, there
    will (eventually!) be an ADOC.... member that documents that data
    source.  Each ADOC.... member will not only contain the data set
    and variable descriptions now found in sections of Chapter FORTY,
    but will also document the "Product" itself.  The ADOC.... format
    is still being finalized, but each ADOC...  will contain several
    sections:

    Product Information:  Vendor, vendor's manuals, how to create the
                          data records, releases supported, etc.
    Data Set Information: Contents of each data set created by MXG from
                          this product, like existing Chapter FORTY with
                          alphabetic list of all variables.
    Variable clusters:    Grouping of MXG variables by logical grouping
                          (CPU, I/O, memory, response, owner, etc.). See
                          page 424 in the MXG Supplement for example.
    Report mappings:      For important reports from the vendor (eg. IBM
                          RMF reports), a sample report showing which
                          MXG variable name creates each report value.
                          See page 454 in the Supplement for an example.
    PRINT/MEANS           An edited PROC PRINT of actual observations of
                          each MXG dataset shows the variable name, its
                          label, and actual values, (which I personally
                          think is the best way to understand datasets).
                          A PROC MEANS with minimum and maximum values
                          of all numeric variables is also provided.
    Technical reports:    Technical papers, discussions, or other useful
                          information relating to each product will also
                          be included in that products ADOC.... member.

    Currently, 200+ "Products" have been identified, and thus there will
    be at least that many ADOC.... members.  As evidence of progress in
    the documentation revision, twenty-five ADOCs now exits in MXG 10.1,
    although none yet contain all of the above sections.  As ADOCs are
    completed, they are added to the next MXG PreRelease.

    In addition to revising Chapter FORTY into the ADOC.... members, the
    other 41 chapters will also be revised, combined, and indexed, and
    will be made available initially online in the MXG source library.

    At this time, I envision the future MXG printed documentation will
    consist of three separate (potentially multi-volume) "books":

    a. A "Beginners Guide to MXG Software", subtitled, "What do I do
       now that my boss just told me I am the MXG Technican?".  This
       book will describe how to install, re-install, and use MXG and
       will deal exclusively with MXG architecture, execution, etc.
       The member NEWUSER is a start in this documentation.

    b. A "Documentation of Products Supported by MXG", comprising the
       above mentioned ADOC.... members.  The IMACAAAA member is the
       best index of the product's that are supported by MXG, although
       searching CHANGESS for the product name or abbreviation may be
       needed due to product renames.

    c. A new "Advanced Guide to CPE" text consolidating all of the
       other forty-one chapters, plus additional new information.
       Among my other dreams to be done, maybe, sometime.

    ALL FUTURE MXG DOCUMENTATION WILL ALWAYS BE PROVIDED INITIALLY IN
    MACHINE READABLE FORMAT AS PART OF THE MXG SOFTWARE.  Portions of
    that online documentation will also be available in printed format.

II.   MXG Technical Notes

 1. Can I Execute MXG on a PC or a UNIX workstation?  An MXG Position.

  A. The building of MXG "Performance Data Bases" must be done under a
  mainframe version of SAS, at least for the short-term foreseeable
  future.  There are several factors that inhibit the use of a PC or a
  UNIX workstation to create MXG data sets from raw data records:

   1. The current SAS compiler interprets INPUT statement informats
      based on the execution platform.  On the mainframe, $CHAR expects
      EBCDIC values, but under PC/VAX/UNIX, $CHAR expects ASCII values.
      Similarly, PD4, PIB4, RB4, informats expect the data format of the
      executing environment; different platforms store binary data in
      different formats, and using PIB4 in a PC program to read SMF data
      will produce incorrect numbers. (Some mainframe-specific informats
      like SMFSTAMP and RMFDUR do not yet exist on all SAS platforms.)
      Additionally, sort orders, like input formats, are intrepreted for
      the execution platform; ASCII vs EBCDIC and ascending/descending
      differences could render some MXG algorithms invalid.

      This constraint will exist at least until a SAS Version 7 exists,
      (years, not months) because removing it requires a significant
      change to the design of the SAS System.  I have asked the SAS
      Institute to remove this limitation, by providing an option that
      allows us to specify the environment under which the DATA step
      input formats, sort order, etc., are to be interpreted.  SAS
      designers agree that the limitation should be removed, and are
      evaluating implementation strategies for the future SAS version.

      SAS does provide some mainframe informat names (eg, the S370xxxx
      informats) that do interpret mainframe data values under PC SAS,
      but their use requires source changes to all 400,000 lines of MXG,
      with more than just substitution - algorithms for nonexistent data
      formats require insertions in multiple locations per occurrence.
      A separate MXG source library would be needed for each platform on
      which it would be executed, a maintenance burden for both of us!

   2. A personal computer or departmental mini-computer is the wrong
      place for performance data.  The performance/capacity/accounting
      PDB is a strategic and tactical corporate information source and
      corporate asset used by technicians, managers (operations,
      software, technical support), their directors, company presidents
      and often by corporate executives.  Asking them to walk down the
      hall to your PC to look at the capacity graphs seems less
      appropriate than having the PDB on a mainframe where they can all
      view the single (and hence unambiguous) PDB information at their
      own desk without a download and without bugging you to look over
      your shoulder.

      Shared corporate data belongs on mainframes and personal data
      belongs on personal or departmental machines.

   3. The volumetrics are wrong for personal or departmental computers.
      The daily SMF volume for a mainframe is measured in hundreds of
      megabytes.  500K CICS transactions are 200MB of raw SMF data.  At
      9600 baud, it takes 24 hours to download 100MB! Even channel
      attached PCs take hours per 100MB, and then more hours after the
      download to create the SAS data libraries, which will need disk
      volumes measured in hundreds of megabytes for the temporary
      datasets while building the PDB.  Current mainframes are 40-80
      times faster for "real data processing (i.e., lots of I/O)"
      workloads than are current 486 PCs and UNIX workstations.


      I believe that the MXG application at your site reads more input
      data bytes per day than any other (and probably more than all
      other) business applications on your mainframe processor!  Buying
      a PC or a UNIX box for this kind of business application is a
      misapplication of the present technology.


  B. Building MXG data bases in the future may be different.  Already we
  are testing MXG programs under SAS 6.07 and OS2 Release 2 on a 400MB
  Model 95 PS/2 (soon with a 3480 IDRC tape drive!), not because we
  think that is the way to go, but because we want to make sure that
  when it does become feasible, and when the SAS limitations have been
  removed or circumvented, MXG will be ready!  (Even then, I believe
  mainframe SAS will continue to be the place to build your PDBs!)


  C. Please note carefully that the limitations in preceding paragraphs
  deal only with the BUILDING of large, shared performance data bases.

  Once the "PDB" has been created on the mainframe, it can be completely
  appropriate to use a personal computer for personal analysis or for
  development and testing of reports.  The PDB, consisting of many,
  mostly small, SAS datasets, can be efficiently processed on today's
  PCs.  Most sites with PC devices for color plotters and printers now
  use SAS/GRAPH cooperatively between their mainframes (where they build
  the graph) and their PC (where they PROC GREPLAY the results).

  It is possible to generate the graphs without a mainframe SAS/GRAPH
  license, by downloading PDB datasets to a PC or workstation that then
  does the PROC GPLOT to build graphs on the PC, but this may be a poor
  choice and false economy, since a PROC GPLOT that takes only one
  second on your 3090 can easily take one minute on your PC, not even
  including the time to download the MXG dataset in the first place.
  The savings in your time alone may well justify the costs for the
  second SAS/GRAPH license, and you have the power and storage of a
  mainframe to keep graphs available for replay.  The generation of
  graphics is a CPU-intensive process; there are times when it should be
  executed on the mainframe, and there are times when it can be executed
  on the PC.  The best implementation is to have SAS/GRAPH available on
  both platforms, and (eventually, in future SAS versions) let SAS
  decide what runs where!


 2. Will SAS 6.07's compress option help MXG?

  Because MXG has always used LENGTH DEFAULT=4 to minimize the size of
  its datasets, the COMPRESS option cannot save as much DASD space
  with MXG as it will with other SAS applications which use the SAS
  default length of 8 bytes for numeric variables.  Nevertheless, it is
  appropriate that we investigate the possible use of COMPRESS=YES.

  One benchmark of BUILDPDB with 470MB input SMF data shows the cost to
  compress all datasets: the CPU time increased significantly (65%, from
  535 to 883 seconds) but only reduced the WORK library size by 16% and
  only reduced the PDB library by 20%.

  A second run compressing only CICSTRAN and DB2ACCT datasets showed the
  CPU time increase was less but still appreciable (37%, from 472 to
  645 seconds in the data step alone), but the CICSTRAN dataset was
  reduced by 37% and DB2ACCT was reduced by 44%.  Thus, if you must put
  these two datasets on DASD, compression will, at some CPU cost, save
  appreciable DASD.  However, it has always been MXG's recommendation
  to store large volume transaction datasets (like CICSTRAN and DB2ACCT)
  directly on tape to avoid contamination of DASD space, and SAS 6.07
  does not support compression of tape data libraries!

  Compression does reduce the size of MXG datasets as shown, but the
  CPU cost is appreciable.  These initial benchmarks suggest strongly
  that the COMPRESS option will not likely be used by default in MXG,
  but for sites that have large-volume transaction datasets that must be
  stored on DASD, the CPU cost of compression may be justified by DASD
  savings.  MXG member IMACKEEP can be used to specify COMPRESS=YES for
  specific datasets, and further enhancements to MXG will make it even
  easier to specify individual options, such as COMPRESS, for specific
  MXG datasets.


 3. How do I run the PDB if my data center runs only six days a week?

   Sites which operate six days a week need to make only minor changes
   to the architecture of BUILDPDB/WEEKBLD/MONTHBLD.  The PDB that would
   normally be built on Sunday morning and that would normally be copied
   into the SAT "day-of-week" dataset will not exist if your site does
   not run BUILDPDB on Sunday.

   If SAS would allow it, you could use  //SAT DD DUMMY but SAS Version
   6, unfortunately, does not tolerate DD DUMMY for SAS data libraries.

   You could modify MXG and remove all references to SAT in members
   WEEKBLD and MONTHBLD and your JCL for BUILDPDB, WEEKBLD, and MONTHBLD
   and I once suggested that approach.  But here's Chuck's better way:

   Create the SAS equivalent of DD DUMMY by allocating a one cylinder
   SAS data library for your SAT or SUN PDB (or both, if you're a 5x24
   instead of a 6x24 operations!).  You then execute
        OPTIONS OBS=0; PROC COPY IN=PDB OUT=SAT; RUN; OPTIONS OBS=MAX;
   to build a valid zero-observations SAT or SUN PDB library.  You can
   then use the normal MXG JCLPDB6 JCL, and your MXG tailoring will be
   limited to MONTHBLD, discussed below.   However, there is another
   big advantage of this implementation.  When you do grow up again to
   operate 7x24, you simply create a new and larger dataset for that
   seventh day that is being added, and you keep on trucking!

   However, if you operate only six days a week, you must also alter the
   logic in MONTHBLD and in the logic that submits the MONTHBLD job:

   The logic of MONTHBLD must be changed, because if the 1st day of the
   month is a Sunday, then the monthly job must be executed on Monday
   the 2nd day of the month.  These specific changes must be made:

   MONTHBLD  -  These changes are required:

        a. replace   IF DAY(TODAY) NE 1 THEN DO;
           with
             IF NOT (DAY(TODAY) EQ 1 OR (DAY(TODAY) EQ 2 AND DAY='MON'))
               THEN DO;

        b. insert     IF DAY(TODAY) EQ 2 THEN TODAY=TODAY-1;
           immediately before    LASTDAY=TODAY-1;

    SUBMIT logic.  The example on page 343-4 of the MXG Guide shows how
      to use SAS to submit the monthly jobs from the daily BUILDPDB on
      the first day of the month that is not a Monday using:
        IF DAY=1 AND WDAY NE 'MON' THEN MONTHFLG=1;
      The text points out that if the first day of the month is a Monday
      the monthly job will be submitted by a "similar step attached to
      the weekly job so that the monthly job uses the weekly dataset".
      That "similar step" would contain only the second DATA _NULL_ step
      in the example, and (for seven day operation) it would contain:
        IF DAY=1 AND WDAY EQ 'MON' THEN MONTHFLG=1;

      For six day operation, only that "similar step" tacked on to the
      end of your weekly job needs to be changed to now read:
        IF (DAY=1 OR DAY=2) AND WDAY EQ 'MON' THEN MONTHFLG=1;

    Note that MXG architecture requires that the daily BUILDPDB job
    complete before the WEEKBLD job is submitted on Monday, and that the
    WEEKBLD job complete before MONTHBLD is submitted.  This is easily
    accomplished by letting the BUILDPDB submit WEEKBLD/MONTHBLD and
    letting WEEKBLD submit MONTHBLD when the month starts on Sunday or
    Monday.

    With six day operation, the data for Saturday and Sunday work will
    be put in the SUN library with a ZDATE of Monday's date.  Since the
    selection criteria for a month are the ZDATEs of the 2nd of last
    month thru the 1st of this month (inclusive), the combined weekend
    data will be put in last month's PDB when the month starts on Monday
    and the combined weekend data will be put in next month's PDB when
    the month starts on Sunday.


III.  MVS Technical Notes

 1.APAR OY51878 (CPURCTTM) is corrected by PTF UY77275.  As a result,
   the circumvention for this IBM error (Change 9.184, which removed
   CPURCTTM from CPUTM sum in TYPE72) has been removed (Change 10.064)

 2.APAR OY51053 (SYSTRNTM) is corrected by PTF UY77634.  SYSTRNTM is a
   new concept in TYPE72; it is the execution time plus the input queue
   time (i.e., from READTIME to TERMTIME), and now appears correct.

 3.APAR OY52104 and PTF UY78154 correct problem with invalid characters
   in JOB field in the (archaic) type 4 and 5 SMF records (and in some
   IEF... messages printed on the Job's SYSLOG.



IV.   CICS Technical Notes

 1.CICS/ESA 3.3.0 was incompatibly changed by IBM.  New data fields were
   inserted in the middle of the records!  MXG 9.9 does not ABEND with
   CICS 3.3.0 records (it does print "UNEXPECTED DATA FOUND" notes on
   the SAS log as a warning that something is wrong), but the CICSTRAN
   dataset is essentially trashed; transaction start/stop/response times
   are valid, but all resources (CPU time, File Control counts, etc.)
   are completely wrong.  MXG 10.1 is REQUIRED for CICS/ESA 3.3 records.

 2.Omegamon V550 support requires installation tailoring.
   a. MXG members IMACICOC, IMACICOL, and IMACICOB (for the BSC, DLI,
      and DB2 additions to the transaction record) contains a comment
      block which surrounds that actual code.  That comment block must
      be deleted to enable processing of these three Omegamon segments.
   b. MXG member IMACICDA controls which CICS APPLIDs have Omegamon data
      segments.  If only some CICS APPLIDs have Omegamon data, you must
      add a DO group for those APPLIDs around the three %INCLUDEs for
      the three members above, so they are only included for the correct
      APPLIDs.
   c. For CICS 2.2 or earlier (SMFPSRVR=3) you must tailor member
      IMACEXCL to process the excluded fields in the basic transaction
      segment.  You use macro _CICXLTR to name the APPLIDs writing the
      Omegamon records, and you use macro _CICXCTR to specify _CICXCOM
      so that the Omegamon exclude structure is used for those APPLIDs.
      This step is not required under CICS/ESA, because Omegamon does
      not exclude transaction fields under CICS/ESA.
   d. If MCTSSDRL=496 in the MXG VMAC110 error message, you must also
      update member IMACPTF and in therein enable macro QOC0109.  This
      note was added to the online member Aug 24, 1994.

V.    SAS Technical Notes.

 1.BUILDPDB (with additional SMF record processing) under SAS 6.07 has
   produced "NOTE: ADDITIONAL INTERNAL PASS WAS REQUIRED TO COMPUTE
   CORRECT CODE SIZE. SPECIFYING OPTION CODEPCT=102 MAY REDUCE EXECUTION
   TIME.", but MXG's CONFIG07 member specifies CODEPCT=120! This appears
   to be a very minor SAS bug that is under investigation, that has no
   effect on the MXG execution of BUILDPDB.  However, this note caused
   me to benchmark a related compiler option, CODEPASS.  In theory,
   specifying CODEPASS=2 for large programs should be faster, since SAS
   is committed to a two-pass compile, instead of starting to one-pass
   compile and finding a second pass necessary, but it did not have that
   effect on MXG's BUILDPDB with SASENTRY=SASHOST.   With CODEPASS=2,
   the CPU time (exactly repeatable) increased by 1.04 seconds (from
   49.15 to 50.19), or 2% increase, and the elapsed time was a wash
   (down .63, 91.85 to 91.22 in one pair, up .36, 95.54 to 96.30 in the
   second pair).  Since CODEPASS=1 is slightly cheaper, CODEPASS=2 is
   not recommended for BUILDPDB.

 2.SAS 6.06 Error 31-185, Format not recognized, occurs if the SAS
   installer was sloppy and tried to create a Version 6 JCL Procedure by
   modifying your existing Version 5 procedure.  The Version 5 PROC has
   a //LIBRARY DD DSN=&LIBRARY,DISP=(MOD,DELETE) statement that does not
   belong in Version 6.  Have your SAS Installer correct your problem by
   installing the Version 6 JCL Procedure provided by SAS Institute.

 3.JCLTEST6 JCL 4MB REGION too small if MEMSIZE is limited by site.
   Two sites have reported they could not successfully execute TESTIBM3
   step of JCLTEST6 in a 4MB Region with MXG's CONFIG member default of
   24MB; they had to increase the REGION JCL parameter to 6MB to run.
   At least one of the sites had limited the amount of virtual storage
   above the line to 16MB, and thus SAS could not get the 24MB MEMSIZE
   MXG expected.  Increasing the REGION size is the only alternative if
   you cannot get enough MEMSIZE above the line!

 4.SAS 6.07 INFILE processing of concatenated files is not perfect if
   END=END is specified.  The JCFB= variable is incorrect and contains
   the 2nd concatenation's DSNAME while still on the last record of the
   1st concatenation.  Additionally, the SAS NOTE: describing the next
   data set is printed too early on the SAS log (before messages from
   the last record in the 1st concatenation).  Tracking 238735.  Only if
   you use the JFCB= variable (to capture DSNAME?) are you at risk.  MXG
   only uses the JFCB= variable initially to discern if the input data
   is VSAM or BSAM, and thus this error poses no risk to MXG code.

 5.SAS 6.06 and SAS 6.07 require BLKSIZE=23040 override to avoid error.
   SAS 6.06 may still ABEND with the erroneous error message "DATA SET
   IS NOT SORTED", indicating bit overlays in the WORK DDname.  These
   errors have nothing to do with the SORT program, but were thought to
   be mostly fixed by SAS Oct 1991 Maintenance.  There were still some
   known exposures that could not be fixed by zap, that were thought to
   have been fixed in SAS 6.07 (remember, 6.07 allowed SAS to corect at
   source level, instead of by ZAP).  A circumvention for SAS 6.06 sites
   until they install SAS 6.07 has been to follow MXG's performance
   recommendation of BLKSIZE=23040 for WORK DD because it appears that
   the bit overlay error is eliminated by the larger block size (instead
   of the 6144 SAS default)!.  See page 35, MXG Newsletter TWENTY-ONE,
   for the JCL example to override WORK DD.  One SAS 6.07 site reported,
   without confirmation, a similar failure that was seemingly also
   eliminated by large blocksize for WORK DD.

 6.SAS 6.07 error in the CCHHR option causes VMXGVTOC to miss extents
   and produce "CRITICAL ERROR IN VTOC PROCESSING" if there are more
   than three extents.  SAS ZAP V6-SYS-FILE-4673 is available on the
   June 1992 SAS Usage Notes Tape.  This error was apparently only in
   the CCHHR option, and not the similar but different CCHHR= option.
   This error did not affect the recommended alternative to VMXGVTOC,
   the ASMVTOC/VMXGVTOF members which are faster, better, and do not use
   either CCHHR or CCHHR= options.

 7.SAS 6.07 does not recognize the EPILOGC infile exit name, used to
   processing Candle's (archaic) EPILOG compressed records, while SAS
   6.06 did.  Fortunately, the current EPILOG V550 product writes data
   to SMF records without compression, so few sites should encounter
   this SAS error.

 8.SAS 6.07 may produce INVALID ALTER PASSWORD error message.  Two SAS
   usage notes, V6-SYS-SASIO-4267 and -4147, discuss separate problems
   related to the PROTECT option and Version 5 or 6.06 datasets.

   One site had a SPIN library that had been originally created by SAS
   5.18.  Their SAS 6.07 BUILDPDB failed when it started to write out
   the new day's SPIN data sets, because that Version 5 SPIN library had
   been built with PROTECT enabled.  (PROTECT was removed in 6.06 but
   apparently causes SAS 6.07 to unexpectedly fail!).  By creating a
   6.07 SPIN library and using PROC COPY to copy the SPIN datasets to
   the 6.07 SPIN library, this site's problem was circumvented with no
   loss of data:

      //SPIN607  EXEC SAS607,CONFIG=MXG.SOURCLIB(CONFIG07)
      //SPIN  DD DSN=OLD.SPIN.LIBRARY,DISP=OLD
      //NEWSPIN DD DSN=NEW.SPIN.LIBRARY,DISP=(,CATLG),...
         PROC COPY IN=SPIN OUT=NEWSPIN

   One site failed in WEEKBLD when it went to overwrite the WEEKly
   library.  The PROC CONTENTS showed the ENGINE=TAPE, indicating the
   library had been created with SAS 6.06's Tape engine, and usage note
   4147 indicates that cannot be done without error under 6.07.  In this
   case, simply by scratching and re-allocating the WEEKly library
   (since the weekly data had already been copied to tape) circumvented
   the problem.

 9.SAS 6.07 copy from SMF VSAM file to BSAM VBS file creates invalid SMF
   records; error is fixed by SAS ZAP MV313550.  See Change 10.030.

10.SAS 6.07 entry modules SASXA1 and SASXAL may ABEND with 0C4 at SAS
   initialization.  The culprit appears to be IBM's IEBCOPY option
   COPYMOD, used to build and re-block these "bundled" programs.  The
   COPYMOD option seems to create double RLD entries (they can be seen
   in an AMBLIST of the ABENDing module).  Using IEBCOPY option COPY
   instead of COPYMOD did not create double RLDs and SAS did not ABEND.
   The COPYMOD statement which needs to be changed is found in member
   CPYBA2 of the SAS install library; see step BACOPY2 in SASUPDTE job.
   This has hit two sites, and research is still in progress. The ABEND
   only occurs in batch execution. Tracking 244913, still open.

VI.   Installation, re-installation, and Space Requirements.

    Over 20 Beta sites have been running MXG 10.1, some since mid May,
    with no reported problems, either in execution or migration from
    9.9.  There are no changes in the external (JCL) environment for MXG
    10.1, and the installation instructions are unchanged from MXG 9.9.

    Sites migrating to 10.1 from an MXG version earlier than 9.9 must
    read the compatiblity section of the installation instructions in
    MXG Newsletter TWENTY-ONE.

Always read comments in the CHANGES member for compatibility issues, as
well as for any last minute changes added after Newsletter composition.

The MXG Installation instructions are found in Chapter 32 of the MXG
Supplement for both new installation and for version replacement, and
those instructions, as modified herein, are still valid.

The MXG tape is distributed as a Non-Labelled (NL) tape containing a
single file with DCB=RECFM=FB,LRECL=80,BLKSIZE=32720.  The MXG tape is
an unloaded Partitioned Dataset in IEBUPDTE format.  Note that the tape
blocksize was changed to 32720 (it had been 6160 in prior versions). You
will receive I/O errors if you specify the incorrect blocksize.

Under MVS use IEBUPDTE utility to build the MXG.SOURCLIB PDS library.
Under CMS use TAPPDS   command to build the SOURCLIB MACLIB library.

Allocate MXG.SOURCLIB for MXG 10.1 with SPACE=(CYL,(54,1,299)), using
  DCB=(RECFM=FB,LRECL=80,BLKSIZE=23440) on 3380 devices, or
  DCB=(RECFM=FB,LRECL=80,BLKSIZE=27600) on 3390 devices.

Under CMS, approximately the same space (54 cylinders) will ultimately
be required by the MXG SOURCLIB MACLIB, but during the CMS installation
process you will need at least 108 free cylinders on your minidisk.

MXG is tailored and extended by "Installation Macro" members (members
beginning with IMAC....), and by "MXG Exit Facility" members (members
beginning with EX....) that are copied and edited into the installation
"USERID.SOURCLIB", the name of the "MXG Tailoring" library, that you
create and concatenate ahead of MXG.SOURCLIB to the SOURCLIB DDNAME:

  //SOURCLIB DD DSN=USERID.SOURCLIB,DISP=SHR --> site tailoring (yours)
  //         DD DSN=MXG.SOURCLIB,DISP=SHR    --> never changed  (mine)

If this is an MXG re-install, there should already be a USERID.SOURCLIB.
If not, then allocate one using the same attributes as the MXG.SOURCLIB,
with SPACE=(CYL,(1,1,99)).  Under CMS create an equivalent MACLIB.

Tailor by editing members that you copy from my library to your library.

IMAC.... members are self-documenting, and member IMACAAAA indexes all
IMAC members.  Most MXG sites have only a few tailoring members in their
USERID.SOURCLIB (typically, IMACACCT, IMACSHFT, IMACWORK).

VMAC.... members contain the actual processing code, and normally should
not exist in your USERID.SOURCLIB, and should always be removed when you
install a new version of MXG.  However, if you have installed printed
changes from an MXG Newsletter, you might have copied VMAC member(s)
from MXG.SOURCLIB into your site's USERID.SOURCLIB and then modified the
VMAC member.  (Alternatively, you could have created an MXG.CHANGLIB in
which you put those in-between-version changes.)  In either case, if
you made temporary changes, they must be removed now.  Delete all of the
VMACs members from your USERID.SOURCLIB (or delete the MXG.CHANGLIB).
Otherwise, your modified VMAC member would be used instead of MXG's.

You should record all tailoring changes in your USERID.SOURCLIB so the
next MXG technician will know what you have done.  You should create a
member named CHANGES in your USERID.SOURCLIB, similar to member CHANGES
in the MXG.SOURCLIB which documents all MXG changes.

If there are IMAC.... members in your USERID.SOURCLIB, you must look at
the alphabetic list of changed IMACs in the Change Log, below, and must
retrofit your tailoring on the new member in this library.  MXG 10.1
changed IMACPDB to add TAPE3490 device count.

Whenever you install changes or test a new version of MXG (or even your
own reports), be extra careful to look on the SAS log for any real error
conditions. Search for all occurrences of "ERROR:" and  "ERROR :"  and
"UNINITIALIZED" and "NOT CATLGD", as they may indicate a serious error.

A PROC PRINT and a PROC MEANS of each new MXG-built SAS dataset can help
you to understand their contents, and should be used to examine any
unusually large, negative, or suspicious values.  Print all variables in
the dataset, and read the variable's descriptions in Chapter FORTY.


 Summary of critical actions to be taken in installing new version:

     a. All VMAC.... members in your USERID.SOURCLIB must be examined
        and, in general, must be deleted.

     b. All IMAC.... members in your USERID.SOURCLIB must be compared
        with the IMAC.... members that have been changed in this MXG
        version (see alphabetic list at beginning of Change Log).  You
        MUST start with the IMAC in this version and retrofit your
        installation's tailoring. Member IMACAAAA indexes all IMAC's.

     c. It is always wisest to PROC PRINT the first 50 observations of
        important datasets, especially PDB.JOBS, which can be affected
        by user tailoring in IMACPDB. A visual scan of that PROC PRINT
        serves as an excellent validation of correct installation, and
        will almost always detect any serious problems BEFORE you begin
        your production MXG runs!  See also the MXG utility UTILPRAL.




VII.  Important notes from prior Newsletters:

 1. SAS OPTIONS REQUIRED under version 5.18, 6.06, or 6.07.

    Please read this section carefully.  MXG execution will fail if you
    do not pay attention to these (potentially incompatible) changes:

    SAS options that are MANDATORY with all SAS Versions:

      NOIMPLMAC MAUTOSOURCE SASAUTOS=SOURCLIB ERRORABEND MACRO DQUOTE

        NOIMPLMAC should ALWAYS be used; never use IMPLMAC.
        MAUTOSOURCE and SASAUTOS=SOURCLIB are required by MXG to
         resolve %MACRO references without extra I/O by using autocall.
        ERRORABEND ensures SAS stops on any error condition.
        MACRO enables SAS to recognize %MACROs.
        DQUOTE is needed to extract values of certain string %MACROs.

    SAS options MANDATORY under SAS Version 5.18 (do not exist in V6):

      MWORK=28000 GEN=0

        MWORK was needed in large %MACROs (like %ANALDB2R).
        GEN=0 was needed to eliminate unnecessary I/O and CPU time, and
        is discussed in the 1984 Guide (see Index).

    SAS options MANDATORY under SAS Version 6 (did not exist in 5.18):

      MEMSIZE=24M

        Previously, MXG recommended MEMSIZE=12M, but programs that build
        many datasets concurrently (like BUILDPDB, VMACVMXA, etc.) will
        need more of this virtual storage above the line, because of the
        new MXG recommended value for BLKSIZE='half-track'. The MEMSIZE
        option only works under MVS/XA and MVS/ESA, and since it is not
        a real resource, and only used when needed during the "building"
        phase in MXG processing, the new default of MEMSIZE=24M should
        not cause any problem, and will avoid unnecessary ABENDs.

        If you are using MXG and SAS 6.07 under MVS/370 or CMS/370, you
        will have to reduce this MEMSIZE= parameter to no more than 6M,
        and must reduce the BLKSIZE (try 4096, or the minimum 1024).
        Small BLKSIZE will allow your program to compile, but the DASD
        work space you will need will significantly increase, as will
        the run-time, IOs, and CPU requirements for the same job.

    SAS options STRONGLY RECOMMENDED for SAS 6.06/6.07 performance:

      BLKSIZE=23040 BUFNO=2   -- for 3380's
      BLKSIZE=27648 BUFNO=2   -- for 3390's

      MXG now uses BLKSIZE(DASD)=HALF in CONFIG/CONFIG07 members to set
      the blocksize for new permanent data sets, but that option will
      not work if the BLKSIZE was specified in the JCL.  The //WORK DD
      contains an explicit BLKSIZE=6144 parameter, which must either be
      changed in your SAS procedure or overridden in your JCL, using:

           //    EXEC MXGSASV9
           //WORK DD DCB=BLKSIZE=23040

      See "SAS Benchmarks" in Newsletter TWENTY for resource savings.

    SAS options recommended with either SAS Version 5.18, 6.06 or 6.07:

        FIRSTOBS=1 OBS=MAX
        ERRORS=2
        NOSOURCE NOSOURCE2 NOMACROGEN NOMPRINT NOMLOGIC

    So how do you specify these recommended/required MXG options?

    In Version 5.18, MACRO and MWORK=28000 must be specified on the EXEC
    statement, but all other options could be specified on an OPTIONS
    statement right after your SYSIN DD * statement.  However, so you do
    not have to remember them nor type them, MXG member SASOPTV5 has all
    of the recommended options in an OPTIONS statement, so you need only
    %INCLUDE SOURCLIB(SASOPTV5);  as your first SAS statement:


         //stepname EXEC SAS518,OPTIONS='MACRO MWORK=28000'
         //SYSIN     DD *
            %INCLUDE SOURCLIB(SASOPTV5);
             ... the rest of your program ...

    For SAS Version 6, options can be set with an OPTIONS statement, or
    with the OPTIONS= JCL parameter, or (as is MXG's recommendation) via
    the CONFIG= JCL parameter on the EXEC statement.  MXG member CONFIG
    contains the MXG required and recommended options for SAS 6.06, and
    member CONFIG07 contains the SAS 6.07 recommendations.  The BLKSIZE
    and MEMSIZE options were increased in MXG 9.9, and the new CONFIG07
    member was added with new SAS 6.07 options.  (You could also supply
    options by overriding the CONFIG DD in the SAS JCL procedure, but
    using the CONFIG= parameter is safer and simpler.).

         // EXEC SAS606,TIME=10,
         //            CONFIG='MXG.SOURCLIB(CONFIG)'


         // EXEC SAS607,TIME=10,
         //            CONFIG='MXG.SOURCLIB(CONFIG07)'

    IF YOU DON'T HAVE THE RIGHT OPTIONS IN EFFECT, YOU WILL RECEIVE
    RUDE AND INSULTING SAS ERROR MESSAGES, INCLUDING 180 ERRORssss!


 2. Format libraries are different in MVS SAS Version 6 and Version 5.

    The MXG-built "SASLIB" formats are built by the first step of either
    JCLTEST (for SAS 5.18) or JCLTEST6 (for SAS 6.06).

    Under SAS Version 5.18, formats are members of a PDS load library
    which must be allocated as SPACE=(CYL,(3,1,99)).  SAS 5.18 formats
    are always referenced using the DDNAME of SASLIB.

    Under SAS Version 6 formats are members of a SAS data library, which
    must be allocated as SPACE=(CYL,(1,1)). Note there is NO third SPACE
    parameter (for PDS directory blocks), because data libraries in SAS
    Version 6 are physical sequential files.  SAS Version 6 format
    libraries are always referenced using the DDNAME of LIBRARY.

    In either version of SAS, the blocksize is set by the PROC FORMAT.

    MXG always requires the appropriate DDNAME (SASLIB or LIBRARY).

    You will fail with SAS 170 FORMAT NOT FOUND errors if you do not
    have the correct format library pointed to by the correct DDNAME.

VIII. Documentation of MXG Software.


Member CHANGES always contains the version number of MXG Software, and
it lists changes that were installed in that version.  The members named
CHANGEnn have the contents of CHANGES when that "nn" MXG version was
created.  Description of enhancements will be found in the text of the
Change description that made the enhancement (in those CHANGES and
CHANGEnn members).  The CHANGE  members can be scanned online (with SPF
BROWSE) to search for specific product name references (CICS, MVS/ESA,
etc.).  The text of each Change identifies the member(s) that were added
or altered by that change. Documentation (especially for new product's
support) is usually also found in comments at the beginning of those
members listed in the change entry.

Member NEWSLTRS contains the text of all newsletters (up through the
newsletter that accompanied that MXG release). You can search NEWSLTRS
for product name or acronym to find the technical notes, APARs, etc.
from all MXG newsletters.  (The Change Log of each Newsletter is not
replicated in member NEWSLTRS, since that text will be in CHANGES).

Member DOCVERnn is the "delta-documentation" (in abbreviated Chapter
FORTY style) of only those variables and datasets that were changed
between successive MXG Versions. There is a DOCVERnn "delta" member in
the MXG library for each version.

Penultimately, member DOCVER contains abbreviated Chapter FORTY format
that documents all of the variables names in all of the MXG data sets
that are created by that MXG Software Version (alphabetically by data
set name and variable name).

Finally, MXG is a source distributed system, so you can often find your
answer by BROWSE/EDIT of the source member, especially the VMACs that
actually create the data set, or ANALs that analyze the MXG data sets.
In many instance, the MXG Variable name is the IBM or Vendor's field or
DSECT field name. In other cases, the DSECT field name is carried as a
comment beside in the MXG INPUT statement to map field name to MXG's
variable name.  MXG expects you to also have access to the vendor's
documentation of particular data records you are using for analysis.

IX.   Change Log

--------------------------Changes Log---------------------------------

 You MUST read each Change description to determine if a Change will
 impact your site. All changes have been made in this MXG Library.

 Member CHANGES of the MXG SOURCLIB will always be more accurate than
 the printed changes in a Newsletter, because the software is created
 after the newsletter is sent to the printer!

 Member CHANGES always identifies the actual version and release of
 MXG Software that is contained in that library.

 The actual code implementation of some changes in MXG SOURCLIB may be
 different that described in the change text (which might have printed
 only the easily installed, critical part of the correction).

 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.

 Changes thru 10.104 were contained in MXG Beta       10.1 Jul 10, 1992.
 Changes thru  9.229 were contained in MXG Version     9.9 Mar  1, 1992.


Alphabetic INDEX of significant changes in MXG 10.1 (after MXG 9.9):

  Member    Change   Description

  ADOCAAAA 10.087  Twenty-Five ADOCs documentation members now exist.
  ANALDB2R 10.001  DB2 Report truncated character values.
  ANALDB2R 10.034  SORTBY= operand parsed only the first SORT variable.
  ANALDB2R 10.046  LIBRARY SMF IS NOT VALID message with PMSQL04 report.
  ANALDB2R 10.047  DBID/OBID hex values printed instead of name.
  ANALDB2R 10.055  Date/time selection in PMSACC01/02 produced no report
  ANALDB2R 10.094  ANALDB2R Accounting report uses ASUMDB2A if exists.
  ANALDSET 10.097  VSAM data sets may have wrong PROGRAM name.
  ANALMONI 10.066  TMON/CICS sample report filled WORK file.
  ASMIMSLG 10.084  Major revision in IMS log processing algorithms.
  ASMTMNT  10.012  MXG Tape Mount Monitor supports Dynamic I/O Reconfig.
  ASMVTOC  10.073  Avoid 213/314 abends reading VTOC of VM/TPF volumes
  ASUMDB2A 10.090  DB2 Account "transactions" summarized into ASUMDB2A.
  EXTY72   10.064  CPURCTTM now valid, circumvention removed.
  GRAFLPAR 10.052  LPAR CPU utilization reports added.
  GRAFTRND 10.049  Graphic trending reports were not always correct.
  IMACFACO 10.100  Fujitsu's FACOM MSP/EX SMF records now supported.
  IMACPDB  10.053  New macro _DB2ACCT added. Compatibility exposure.
  IMACPDB  10.068  TAPE3490 (3490s allocated) added to PDB.STEPS/JOBS.
  JCLTEST6 10.030  INVALID DATA FOR SMFTIME, SAS zap MV313550 required.
  MNTH.... 10.091  Trending with INTERVAL=MONTH members added.
  READDB2  10.045  TRACECLS= parameter does not select all IFCIDs.
  TRNDDB2A 10.093  TRNDDB2A Account Trending uses ASUMDB2A if exists.
  TYPEMON8 10.020  Landmark CICS "INVALID OFFSETS" message.
  TYPEMON8 10.067  MONITASK variables STRTTIME/CREATIME now equal.
  TYPETMS5 10.082  TMS.TMS had DSNB fields, TAPEFEET calculation changed
  VMAC102  10.072  DB2 SQLCODE can be negative, MXG read as positive.
  VMAC110  10.017  Invalid type 110 subtype 2 could cause MXG to loop.
  VMAC110  10.038  Omegamon error causes INVALID DATA FOR SMFPSRSN.
  VMAC110  10.059  Type 110 STOPOVER due to bad record eliminated.
  VMAC110  10.061  Support for CICS/ESA 3.3.0 monitor (CICSTRAN) data.
  VMAC110  10.062  Support for CICS/ESA 3.3.0 statistics datasets.

  VMAC24   10.037  Spool off-load type 24 can cause STOPOVER abend.
  VMAC28   10.095  Blue Line's Vital Signs for VTAM type 28 supported.
  VMAC30   10.031  Variables ACTDLYTM, RESDLYTM, DSPDLYTM created.
  VMAC37   10.098  System Center's NETMASTER type 37 SMF record support.
  VMAC39   10.040  INPUT STATEMENT EXCEEDED for subtype 5.
  VMAC40   10.065  New dataset TYPE40_D can be created for tape analysis
  VMAC41   10.015  DIV type 41 SMF record timestamps mis-documented.
  VMAC42   10.005  Type 42 SMF record causes STOPOVER ABEND.
  VMAC6    10.003  PSF type 6 record had FORM truncated.
  VMAC7072 10.010  TYPE70PR variable NRPRCS corrected.
  VMAC7072 10.042  PCTRDYWT variable now created.
  VMAC71   10.014  SWAP counts corrected.
  VMAC75   10.099  MVS/ESA 4.2.0 changed format of DEVNR/UNITADR.
  VMACAPAF 10.078  Support for Amdahl's APAF replacement for MDFTRACK.
  VMACAICO 10.048  Support for AICorp's KBMS user SMF record.
  VMACCIMS 10.063  IMF flag variables wrong if multiple bits are on.
  VMACDB2  10.024  MVS Account fields added to DB2ACCT!
  VMACDCOL 10.071  INVALID VALUE FOR FUNCTION DATEJUL message.
  VMACHSM  10.080  FSTTRKR/W large values are actually negative values.
  VMACNATP 10.033  Support for Software Ag "Natural Process" SMF record.
  VMACNETP 10.039  NETPACTM was total response, should be average.
  VMACNRS  10.075  Support for The Network Director North Ridge Software
  VMACNSPY 10.015  Support for NETSPY Token-Ring records added.
  VMACNSPY 10.057  Support for NETSPY Release 4.2 added.
  VMACRMDS 10.102  RMDS messages INVALID DATA FOR RMDSMXVR eliminated.
  VMACROSC 10.022  Support for ROSCOE Release 5.7 changes to SMF data.
  VMACROSC 10.101  ROSCOE ADSFUN.. variables values corrected.
  VMACSMF  10.019  Header/Trailer messages on log were not always right.
  VMACSPMS 10.011  SPMS R2.1.4 invalid record circumvented.
  VMACSPMS 10.069  SPMS 1.2.13 inserted four byte field, causing errors
  VMACTMS5 10.060  TMS inactive DSNBs now deleted, caused wrong VOLSER.
  VMACTMVS 10.058  TMON/MVS "INVALID DATA for WKLCPURF" message.
  VMACTPX  10.007  TPX variable TPXELAP has wrong value.
  VMACVMXA 10.036  VM/ESA 1.1.1 additions now supported.
  VMACVMXA 10.071  VM/ESA VXSYTCUP dataset has only 49 observations.
  VMACWSF  10.081  Support for RSD's WSF/WSF2 Release 3.4.1.
  VMACX37  10.013  STOPX37 Release 3.4 is supported.
  VMXGSUM  10.089  MINTIME=,MAXTIME= parameters added to VMXGSUM.
  VMXGVTOC 10.018  CRITICAL ERROR IN VTOC if DSORG=PS-SUL data found.
  VMXGVTOC 10.054  ISAM index space not recognized in VTOC.
  WEEKBLD  10.008  NOT SORTED when implementing MXG 9.9
  WEEKBLD  10.009  TYPE70PR,DB2ACCT/STAT0/STAT1 added to weekly/monthly.
  XMAC7072 10.023  344 Compiler circumvention causes UNINITIALIZED msg.
  XUNIX    10.076  Support for UNIX iostat and vmstat commands.

Inverse chronological list of all Changes:


  Changes 10.104-10.001 were printed here in Newsletter TWENTY-TWO

  See member CHANGE10 for actual change text.

End of Changes Log in Newsletter TWENTY-TWO.
****************NEWSLETTER TWENTY-ONE***********************************










              MXG NEWSLETTER NUMBER TWENTY-ONE March 1, 1992

Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE

                         TABLE OF CONTENTS
                                                                    page
I.    MXG Version Status.

 1. Announcement of Production Version MXG 9.9 dated March 1, 1992     2
 2. Major enhancements and new products supported in MXG 9.9.          2
 3. IBM Announcements and their MXG support.                           3
 4. What is planned in future MXG Software releases?                   3
 5. New MXG documentation is planned.                                  3

II.   MVS Technical Notes

 1. Type 60 SMF Records filling SMF now fixed by IBM APAR OY43935.     5
 2. Type 0 SMF records (IPL) are also created if SMF is RESTARTED!     5
 3. MVS/ESA 4.2 TYPE72 CPURCTTM wrong, APAR OY51878 has no PTF yet.    5
 4. MVS/ESA 4.2 TYPE72 SYSTRNTM wrong, APAR OY51053 has no PTF yet.    5
 5. MVS/ESA 4.2 type 30 records for MASTRJCL with INITTIME wrong.      5
 6. ESCON channel utilization probably wrong.                          5
 7. MVS/ESA 4.2 non-swap block paging may be double counted.           5
 8. MVS/ESA 4.2 blocked pages and unblocked pages count questionable.  6
 9. TYPE64 VSAM fields wrong values now fixed by IBM APAR OY48286.     6
10. TYPE30 EXCP counts for multi-volume datasets affected by STOPX37.  6
11. A Look at Cache Performance Data for the Amdahl 6100               6

III.  CICS Technical Notes

 1. CICS user segments and Exclude/Include logic fully supported.     11

IV.   DB2 Technical Notes

 1. Summary of DB2 2.3 data and measurement changes.                  12
 2. Using MXG DB2 members ANALDB2R, ANALDBTR and READDB2.             21

V.    SAS Technical Notes.

 1. MXG STRONGLY RECOMMENDS IMMEDIATE INSTALLATION OF SAS 6.07.       33
 2. PROC CONTENTS option DETAILS added in SAS 6.07.                   33
 3. %MACRO compiler performance improved in SAS 6.07.                 33
 4. Running out of WORK space produces strange error messages         33
 5. Strange errors if MEMSIZE is insufficient.                        33
 6. SAS 6.06 has been repaired, and can now be installed and used.    33
 7. Execution of MXG under SAS Versions 5.18, 6.06, or 6.07           34

VI.   MXG Version 9.9 Installation, Space, Compatibility, etc.        37

VII.  Documentation of MXG Software.                                  39

VIII. Change Log - Changes 9.105-9.232                             40-72

         COPYRIGHT (C) 1992 BY MERRILL CONSULTANTS DALLAS TEXAS

I.    MXG Version Status.

 1. Production Version is now MXG 9.9, dated March 1, 1992.

    MXG Version 9.9 accompanied this Newsletter.

    All Changes in this newsletter have been installed in MXG 9.9.

    The MXG 9.9 library contains 1,589 members, 383,962 lines of code,
    and builds 1030 datasets with 39,435 variables that are documented
    in member DOCVER.  Datasets changed between MXG 8.8 and MXG 9.9
    are documented in member DOCVER09.


 2. Major enhancements and new products supported in MXG 9.9.

        Support for SAS 6.07 (new options).

        Support for Amdahl's SPMS Release 1.2 SMF record.
        Support for 4th Dimension Software's CONTROL-D SMF record.
        Support for CA-1 (TMS) Release 5 complete rewrite.
        Support for CADAM's Statistics Data File.
        Support for CICS/ESA 3.2.1 product.
        Support for Codework Software's SNAPAD-MVS user SMF record.
        Support for Database 2 Release 2.3.
        Support for DCOLLECT APAR OY36364 change in track capacity.
        Support for Fischer's Totally Automated Office TAO.
        Support for HSM 2.6 SMF record.
        Support for Interlink's SNS/SNA Gateway SMF record.
        Support for Interlink's SNS/TCPaccess SMF record.
        Support for Interlink's SNS/TCPvt  SMF record.
        Support for LEGENT's MIM Multi-Image Manager
        Support for LEGENT's LANSPY component of NETSPY (4.1).
        Support for LEGENT's BUNDL product modified type 6 SMF record.
        Support for MVS/ESA 4.2.2 (RMF 4.2.2) changes.
        Support for NetView NPM 1.5 release.
        Support for NetView FTP SMF record.
        Support for Omegamon for CICS/ESA Version 550 ESRA user SMF.
        Support for Omegamon V550 SMF 110 EMPs (Basic, DB2, DL/I).
        Support for SCA's CMA-SPOOL user SMF record.
        Support for Shared Medical Systems CICS exclude logic.
        Support for Softtool Corporations's CCC (Change and Control).
        Support for Software AG's NET-PASS user SMF record.
        Support for Type 30 APARs OY33312 and OY25606 (no changes).
        Support for 3490E (Serpentine) tape device.
        Support for 9345E DASD device.
        Addition of DB2ACCT,STAT0,STAT1 datasets to your PDB.
        Error in VMXGVTOF/VMXGVTOF (only 3 extents kept) corrected.
        Revision of BUILDPDB to eliminate SAS 5.18 Compiler Error 344.
        Cache RMF Reporter support enhanced, decoded, and documented.
        DB2 Reports corrections and enhancements in ANALDB2R.
        Fujitsu FACOM MSP and FSP supported in XPDLPDA.
        IMS Input Queue time, resources, CONDCODE  corrections.
        PR/SM Trend Data Base implemented.
        VM/XA Trend Data Base implemented.

    Each of these enhancements are described in the Change Log, below.
    alphabetical list of the most important changes precedes the
    changes.

 3. IBM Announcements and their MXG support.
    IBM has made many major announcements relating to the System/390,
    the ES/9000 family, and ESCON capabilities.  The following table
    lists announced availability dates for the IBM product, and the
    corresponding Version of MXG required to support that IBM product.

      Product Name                     Availability     MXG Version
                                       Date              Required

      MVS/370, MVS/XA (all)            long ago             8.8
      RMF 4.1.2 (for MVS/ESA 3.1.3)    Sep  7, 1990.        8.8
      RMF 4.2   (for MVS/ESA 4.1)      Oct 26, 1990.        8.8
      MVS/ESA 4.1                      Oct 26, 1990.        8.8
      MVS/ESA 4.2                      Mar 29, 1991.        9.9
      RMF 4.2.1 (for MVS/ESA 4.2)      Mar 29, 1991.        9.9
      MVS/ESA 4.2.2                    Aug     1991.        9.9
      RMF 4.2.2 (for MVS/ESA 4.2.2     Aug     1991.        9.9
      CICS/ESA 3.1                             1990         8.8
      CICS/ESA 3.2                     Jun 28, 1991.        9.9
      DB2 2.2.0                                1990         8.8
      DB2 2.3.0                        Oct 28, 1991.        9.9
      VM/ESA  1.1.0 (370 Feature)      Oct 26, 1990.        8.8
      VM/ESA  1.1.0 (ESA Feature)      Mar 29, 1991.        8.8
      VM/ESA  1.1.1                    Dec 27, 1991.        9.9

 4. What is planned in future MXG Software releases?

    New release of CICS will be supported upon availability.
    Enhancement of AS400 support is planned.
    Boole & Babbage CICS/MANAGER will be supported.
    Several companies have announced plans for VTAM monitors.
    TRIM for ADABAS is in planning; test data did not arrive in time.
    Goal Systems EXPLORE/VM support needs corrections.
    VM/ESA 1.1.1 has not been tested for all records.
    Landmark CICS Version 9 documentation/data was not provided.
    Landmark TMVS new version documentation/data was not provided.
    JES3 Tape Mount Merge with TYPETMNT is a future consideration.
    Cray UNICOS is a distant future consideration.
    VAX/VMS Account/SPM is a very distant future consideration.


 5. New MXG documentation is planned.

    Yes, there will be new printed documentation, which will combine
    the 1984 MXG Guide, the 1987 MXG Supplement, and the 700 pages of
    MXG Technical Newsletters, plus the notes and text buried in the
    various members of the MXG library.

    No, the new books will not be completed in 1992. (In fact, we have
    just re-printed both the 1984 MXG Guide and 1987 MXG Supplement to
    ensure we do not run out of print until the new books are done!)

    The complete re-write of MXG documentation began in the fall of 1991
    and is still in progress.  With over 1,000 MXG-built datasets and
    over 40,000 variables, the new Chapter FORTY style documentation
    would total over 4,200 printed pages, the equivalent of 6 books the
    size of the 1984 Guide, just for dataset documentation!  This brief
    analysis led to the following plan of attack.

    For each "Product" or "Data Source" supported by MXG, there is a
    VMAC.... member which reads those data records and creates one or
    more MXG datasets.  For each of these VMAC.... code members, there
    will (eventually!) be an ADOC.... member which documents that data
    source.  Each ADOC.... member will not only contain the dataset
    and variable descriptions now found in sections of Chapter FORTY,
    but will also document the "Product" itself.  The final format
    of each ADOC.... member is still being developed, but each ADOC...
    will contain several sections:

    Product Information:  Vendor, vendor's manuals, how to create the
                          data records, releases supported, etc.
    Dataset Information:  Contents of each dataset created by MXG from
                          this product, like existing Chapter FORTY with
                          alphabetic list of all variables.
    Variable clusters:    Grouping of MXG variables by logical grouping
                          (CPU, I/O, memory, response, owner, etc.). See
                          page 424 in the MXG Supplement for example.
    Report mappings:      For important reports from the vendor (eg. IBM
                          RMF reports), a sample report showing which
                          MXG variable name creates each report value.
                          See page 454 in the Supplement for an example.
    PRINT/MEANS           An edited PROC PRINT of actual observations of
                          each MXG dataset shows the variable name, its
                          label, and actual values, which I personally
                          think is the best way to understand datasets.
                          A PROC MEANS with minimum and maximum of all
                          numeric values will be provided also.
    Technical reports:    Technical papers, discussions, or other useful
                          information relating to each product will also
                          be included in that products ADOC.... member.

    Currently, 205 "Products" have been identified, and ADOC.... members
    will eventually exist for each product.  MXG 9.9 contains these new
    ADOC members (although none yet contain all of the above sections):

     ADOCACHE  ADOCDB2  ADOCDB2R  ADOCLMS  ADOCSPMS  ADOCVPD  ADOC102

    As ADOCs are completed, they will be added to the MXG PreReleases.

    In addition to revising Chapter FORTY into the 205 ADOC members, the
    other 41 chapters will also be revised, combined, and indexed, and
    will be made available online initially and printed subsequently.

    At this time, I envision the future MXG printed documentation will
    consist of three separate (potentially multi-volume) "books":

    a. A "Beginners Guide to MXG Software", subtitled, "What do I do now
       that my boss just told me I am the MXG Technican?".  This book
       will describe how to install, re-install, and use MXG and will
       deal exclusively with MXG architecture, execution, etc.

    b. A "Documentation of Products Supported by MXG", comprising the
       above mentioned ADOC members.

    c. A new "Advanced Guide" text comprising the consolidation of the
       other forty-one chapters, plus new information.

    ALL FUTURE MXG DOCUMENTATION WILL ALWAYS BE PROVIDED INITIALLY IN
    MACHINE READABLE FORMAT AS PART OF THE MXG SOFTWARE.  Portions of
    that online documentation will also be available in printed format.

II.   MVS Technical Notes

1.  The previously reported problem with Type 60 SMF Records filling
    SMF (See Newsletter NINETEEN article on MVS/ESA), has now been
    acknowledged by IBM under APAR OY43935, and PTFs now exist to
    correct the error.  The excess data was created when sites share
    systems with DFP 2.4.0 and DFP 3.2.0.  DFP V3 added a 'catalog
    sharing subcell' to ICFCATALOG's VVR, and a 'large record' was
    written that was not needed and not used for catalog recovery,
    and the PTF now no longer writes the record when only the catalog's
    VVR sharing subcell was updated.

2.  Type 0 SMF records (IPL) are also created if SMF is RESTARTED!
    The only way to tell that this type 0 is a "bogus" IPL event is to
    look for a type 90 SMF record with SUBTYPE=14 (SETSMF RESTART SMF)
    event code that was written at the same time as the type 0 record.
    It's not clear if this is a bug or a feature, but the unexpected
    IPL record when no IPL occurred confused Dan Kaberon!  Alternatively
    you could use the TYPE90 with SUBTYPE=9 and SUBSYS='SYS' to identify
    only actual IPLs (and exclude RESTART SMF events).

3.  MVS/ESA 4.2 CPURCTTM (Region Control Task CPU time) in TYPE72 is
    enormously wrong (TYPE30 data is fine).  While some RMF intervals
    have reasonable data, there are intervals with impossible values
    (30 minutes in RCT alone in a 30 minute interval!), and comparison
    of RCT in the type 72 shows significantly more time than in the type
    30 record.  This problem has been seen by sites with RMF and CMF;
    the error is in SRM calculation of WAMPRCT.  This problem was opened
    at the IBM support center in July, 1991, but APAR OY51878 was not
    issued until Feb 6, 1992, and no PTF yet exists for that APAR.
    MXG 9.9 circumvents the error's impact on TYPE72 variable CPUTM by
    subtracting CPURCTTM from CPUTM in MXG exit EXTY72, but when you
    have installed the PTF for this APAR, you will need to remove the
    circumvention from member EXTY72.

4.  MVS/ESA 4.2 TYPE72 field SYSTRNTM (SMF72TST) is also erratically
    wrong, but as this is a new measure of "transaction duration",
    this is not quite as critical as CPU time.  This problem was at the
    IBM Support Center since July 1991, and was finally accepted as
    APAR OY51053 in January, 1992 (although no PTF yet exists!).

5.  MVS/ESA 4.2 has type 30 records for MASTRJCL with Initiate Timestamp
    greater than ALOCTIME and LOADTIME.  APAR OY49418 accepts the error,
    and PTF UY74921 now exists.

6.  Boris Ginis, BGS, has noted that with ESCON channels, the channel
    path utilization is about 10% greater than the utilization that is
    inferred by summing the connect time of the LCUs using that channel.
    Prior to ESCON channels, the delta was only about 1%.  In both cases
    the channel utilization was on the order of 50% busy.  Another site
    noticed similar values, and were informed that IBM thinks there is
    probably an error in the sampled percent channel busy measurement
    with ESCON, but that the ESCON connect time is accurate.  This does
    does seem reasonable to me; can anyone else confirm these as fact?

7.  Boris also suspects that non-swap block paging may be double counted
    in RMF 4.2.1.  The type 71 record's sum of page ins and page outs
    for swap, non swap, blocked and unblocked pages shows about 16-17
    pages per second higher than the paging rate calculated from the
    type 75 total pages transferred, and the non-swap block paging rate
    in the same interval is just about 16-17 pages per second.  Non-swap
    block paging is BLKSAUIN+PGBKAUIN (SMF71BLK+SMF71BLP).  See below.

8.  Diane Epstein noted that the blocked pages and unblocked pages count
    in TYPE71 did not seem to match the values reported by IBM on their
    RMF Paging Activity report. It turns out that PVTNPIN (SMF71PIN)
    includes the number of blocks-paged-in, BLKSAUIN (SMF71BLK), because
    when the first page in a blocked-page-in-request is requested, the
    system does not know it is part of a block of pages.  This means
    that the number of non-blocked non-swap page-ins must be calculated
    as PVTNPIN-PVTCAIN-BLKSAUIN,and the number of blocked non-swap
    page-ins is calculated as PGBKAUIN+BLKSAUIN, and pages per block
    is calculated as (PGBKAUIN+BLKSAUIN)/BLKSAUIN.

9.  Gross errors in TYPE64 VSAM fields have been reported by several
    sites that appear to be corrected with APAR OY48286.  Values in the
    actual SMF type 64 record were FFFFFF06, indicating a negative value
    in IBM's terms, but reading that EXCP count with SAS as PIB4. gives
    a value on the order of 4,294,000,000!  The errors were not only in
    EXCP fields, but also DELETES, INSERTS, UPDATES, CISPLITS, CASPLITS,
    and RETRVALS.

10. EXCP counts in type 30 records for multi-volume datasets with the
    STOPX37 product are not correctly assigned to the correct DDNAME.
    The EXCP counts are captured in the DD segment, but when STOPX37
    goes to multiple volumes, it dynamically allocates the device with
    system-assigned DD names (SYS00001, SYS00002, etc., for each volume)
    and the EXCP count is put in the segment for the dynamic DD name
    instead of the real DD name for the multi-volume dataset.  STOPX37
    is aware of this condition, and are investigating.

11. A Look at Cache Performance Data for the Amdahl 6100

           Dick Sziede, PRC Inc., 703 883-8551

 Abstract

 Instrumentation is a key component of any performance oriented product.
 Cache memory in the Amdahl 6100 DASD controller is instrumented by its
 controlling software, Storage Products Management Services (SPMS).  The
 performance data recorded by SPMS Release 1.2.11 is much improved over
 data recorded by prior versions.  These data do not contain sufficient
 information to permit performance or capacity management.

 Background

 Storage Products Management Services is the external interface between
 Amdahl storage controllers and the systems programmer.  SPMS reports
 performance data in two ways: a spun-off SYSOUT report, and through SMF
 records.  Samples of SYSOUT and SMF data are contained in ADOCSPMS.

 Poor documentation of the data recorded by SPMS R.1.0.92 caused the
 author considerable concern.  Many of these concerns have been
 addressed in R.1.2.11.  The first section of this paper covers fixed
 problems.  It is included to allay fears of anyone who might have seen
 the (unpublished and somewhat acerbic) version of this paper that dealt
 with R.1.0.92 of SPMS.

 The second section covers problems that are new, or have not been
 fixed.

 The last section reiterates the author's principal concern:  it remains
 impossible to develop a complete picture of what is going on in the
 6100 cache.  It is not possible from the data recorded to tell if the
 cache is over committed, or thrashing.

 Section 1. The Good News

 Whole bunches of stuff have been fixed.

 Documentation of the prior release of SPMS' SMF record consisted of an
 80-80 list of the DSECT that mapped it.  Period.

 With R.1.2.11, the DSECT is provided machine-readable, as is a SAS
 routine to decode it.  Clear explanations of most of the fields appear
 in the -006 version of the SPMS User Guide.  The new records are
 supported by Release 9.3 of MXG.  At this writing, there is no
 supported MICS component.  The PRINTS in ADOCSPMS are from MXG R.9.3.

 The whole dataset name of datasets cached by name now appears in
 reports and in the SMF record.  Thank goodness!  An occasional dataset
 name is truncated when the continuation line is lost, but who quibbles?
 See ADOCSPMS for the SYSOUT report.

 The extent ranges bug is now fixed.  SMF and the SYSOUT reports now
 agree on which extents are being cached.

 Controller ID is now recorded.  However, the size of the cache and of
 the NVS in the controller is not recorded.  Amdahl says to do this
 would require an engineering change.  This is hard to understand,
 because these very data appear in start-up and status messages:

     SPMS840I SPMS Version 1.2.1.1 Task Status Information
     SPMS847I CTL 30 A(Yes),VOLS(10),EXTS(14),NVS(Installed
                    and Enabled),CACHE(Ready)
     SPMS835I Cache(64 MB,0 Deg Blks),NVS(8 MB,0 Deg Blks)
     SPMS847I CTL 40 A(Yes),VOLS(10),EXTS(16),NVS(Installed
                    and Enabled),CACHE(Ready)
     SPMS835I Cache(64 MB,0 Deg Blks),NVS(8 MB,0 Deg Blks)

 The sequential-detect fields are now documented, and the workings of
 the sequential-detect algorithm are in the user guide.  6100 R3
 firmware uses access history to detect sequential I/O.  The alternative
 would have been from the Define Extent CCW, but at this time, the 6100
 does not implement ECKD commands such as Define Extent.  (The recently
 announced Amdahl 6390 disks will require ECKD).

 Interval Start Time and Interval End Time are now in the SMF record.
 This means the first record cut after an SPMS start-up, or after the
 operator diddles with the LOGGER, is no longer useless.

 SPMS Release ID is now in the SMF record.

 The full dataset name, the serial number, the device number, and
 controller ID are now in the SMF record.  Now SPMS records can be
 correlated with RMF, at least over long periods.  SPMS still doesn't
 sync with the RMF interval.

 We now know what is meant by SUBSYSTEM-ID.  This is the  actual
 subsystem name for SPMS, coded in IEFSSN.  Alas, the string SPMS is
 hard-coded.  This does not allow for multiple versions, or conformity
 with a local naming convention.

 SPMS now remembers the parameters specified when the LOGGER was cold-
 started.  It no longer falls back to defaults if one closes and
 restarts the LOGGER.  In fact, warm-start rather than cold-start is now
 the recommended way of starting SPMS.

 Section 2. The Not So Good News

 The following problems have been reported to Amdahl, and are being
 tracked under Service Order 513270.

 What is ALLOCATED-TRACK-BLOCK-COUNT?  Why do I sometimes get a negative
 number in this field?    This bug is still with us from previous
 releases.  My Amdahl rep thought that the sum of all ATBCs over an
 interval would make sense: that ATBC is a running tally that'd
 aggregate to the sum of the "working sets" for the extents.  This
 didn't work with my numbers.  ATBC varies by orders of magnitude from
 the highest possible number for my controllers.

 I know from the @STATUS command that my two 6100 controllers are named
 30 and 40.  How did they get these names?  Can I change them to Spot
 and Rover?  Amdahl: No.  The controller names are numeric.  The FE can
 change them, but with difficulty.

 There is a new bug.  SPMS appears to loose track of time.  The interval
 that spans midnight ends before it began.  Downstream code sees this as
 an interval with negative duration.

 There are two reasons for SPMS to cut an SMF record: MONITOR activity,
 and LOGGER intervals.  The LOGGER creates SMF records at specified
 intervals.  The MONITOR makes records at event boundaries.

 The relationship between records cut at LOGGER intervals and at MONITOR
 intervals is unclear.  MONITOR and LOGGER not only do not sync to RMF,
 but don't sync to each other.  LOGGER records all have the same SMF
 timestamp.  One hopes this means that the records constitute a
 "snapshot" of the controller stats at that point in time.

 It would be ideal were the LOGGER to slave its interval to that of RMF.
 Amdahl points out that the automatic commands in the next release can
 be used to sync recording to a standard time and interval.  This almost
 works.  It would not be much more difficult to go the rest of the way.
 RMF interval parameters are available in virtual memory, or if one is
 shy about prowling through control blocks, in SYS1.PARMLIB.  SPMS is a
 subsystem: it gets a look-see at all console traffic.  It can slave
 itself to RMF even if the operator changes the RMF interval.  Look for:

     F RMF,F ZZ,INTERVAL(...

 MONITOR records are supposed to be cut when something changes: a
 dataset is added, deleted, or goes into extents.  They also appear at
 intervals.  What is the relationship of the counts in MONITOR and
 LOGGER?  Are they independent statistics?  Or, are the MONITOR counts
 INTERVAL-to-date?  If the latter, what happens if I set the MONITOR
 interval higher than the LOGGER?

 Member ADOCSPMS prints the MONITOR and LOGGER data for one volume.  The
 timestamps and counts for these records suggest that the LOGGER and
 MONITOR data are not independent.  Rather, it looks like either MONITOR
 or LOGGER, when they cut a record, reset the 6100 counters to zero.  If
 this is so, why do we have both?

 MONITOR should cut records for Extent Changed, or for Extent Deleted:
 reason codes 1 & 2. But, only when these events occur.  Producing a
 MONITOR Stopped record, reason code=3, at every MONITOR interval is a
 bug, that will be fixed in R.1.2.12.

 The SMF record contains segments for Cache Extent Definition (CED) and
 for each real extent (EXT).  It is necessary to collect statistics for
 both extents and extent definitions, because the relationship between
 these entities need not be isomorphic.  For example, an extent
 definition could be a dataset.  That dataset could have multiple
 physical extents, even spanning volumes.  Similarly, the controller
 will merge extents from contiguous extent definitions, and manage the
 merged extent as a unit.

 The statistics in the Cache Extent Definition part of the SPMS record
 are always zero.  MXG deals with this by summing the extent stats into
 the extent definition stats, but I'm not sure this is what was intended
 by Amdahl.  Amdahl considers this a bug, to be fixed in R.1.2.12.

 The SAS sample code provided with SPMS has an implicit assumption that
 there will be only one EXT segment per CED segment.  This is not the
 way the doc reads.  This is not what the supplied mapping macro
 implies.  (MXG is written to allow tuples of the EXT segment.  One
 believes that this is what was intended).

 Section 3. The Bad News

 Some data just aren't there.

 Rich Olcott has said that each layer in the storage hierarchy is a
 cache for the layer below it.  One can draw a strong analogy between
 the disk/cache relationship, and that of real memory to virtual memory.
 With this analogy, one can imagine the sorts of data one would need to
 manage performance and capacity for a caching controller.

 Consider the RMF data collected on behalf of the ASM and RSM in MVS.
 What is needed is stats similar to those collected for real and virtual
 memory management in MVS.  The paging statistics, workload MSO, and
 memory allocation statistics collected by RMF provide the example.  In
 particular, we need the parameters of the 6100's LRU algorithm just as
 we know the parameters of working-set and page- stealing in MVS' memory
 management.

 There has to be some analog to UIC, and Available Frame Count that will
 tell how much the cache resource is stressed.  There should be a
 measure analogous to working-set, taken by cache extent definition,
 that tells how much cache is absorbed by each dataset put behind it.

 We need data to answer the questions, "Am I thrashing my cache?" and
 "How close am I to thrashing my cache?"

 The statistics that may correspond to UIC and AFC in RMF are average,
 high, and low cache occupancy.  There should be a working-set measure.
 Cache occupancy is the integral of working-set over time.  A field
 called Allocated-Track-Block-Count may well be the working-set analog,
 but since it shows up negative as recorded by my 6100's, it is a trifle
 hard to interpret.  Alas, cache occupancy is not being recorded at all.

 Amdahl has suggested that the flawed ATBC will be removed in future
 releases.  This is a step backward.  Let this paper serve as a request
 to Amdahl that ATBC be corrected, and some form of the other needed
 statistics be recorded.

 The number of pinned tracks isn't recorded.  As my datacenter moves to
 a 24/7 service schedule, I may have to run with pinned tracks for quite
 a while before I can get a service window.  Pinned tracks may well be a
 performance datum, rather than an event to be fixed immediately.  It
 needs to be recorded.

 Amdahl offers an event simulation model for cache tuning.  CSIM is
 calibrated with GTF CCW trace data.  It will generate a detailed
 picture of cache activity given a variety of configurations.  This is a
 valuable and important tool, but not a substitute for the measurements
 this paper requests.  An analogy may illustrate why.

 It is possible, with some engineering knowledge, a stopwatch, and a
 measured mile, to make measurements to calibrate a computer model of
 automobile performance.  With such a model, one could predict the
 velocity of an automobile from how far the gas pedal is pushed down.
 With careful selection of input measures, such a model could be made
 arbitrarily accurate.  But would you choose such a model over a
 speedometer?

 Conclusions

 The 6100 is a superior product.  SPMS, although it has come a long way
 since the last release, isn't.  The 6100 is an expensive product.  SPMS
 should be the management tool that enables users to get their money's
 worth out of the 6100 cache.  The performance data recorded by SPMS are
 less than adequate.  Capacity planning data are almost non- existent.

 Capacity planning data look like this:

         C                    Cache Installed
         A                 +----------------------
         C                                     o
         H                                 o
         E                               o   o

         D      -----------+      o  o  o
         E                   o
         M               o      o
         A                  o
         N              o
         D          o
                 o     o


              +----------------------------------------------------
                           WORKLOAD

 What is missing, is something to plot on the Y-axis.

 The points in the graph must be measurements, not estimates.  In the
 scenario implied by the figure, the capacity manager uses the 6100
 capacity data asked for in this paper to forecast cache demand as a
 function of workload.  He then schedules a cache upgrade before
 capacity is exceeded.  This is what is meant by the jog in the "Cache
 Installed" line: the customer buys more stuff from Amdahl.

 As SPMS is now, this scenario is impossible.  The data graphed on the
 Y-axis don't exist.  In a real-life scenario, the capacity manager
 cannot know cache capacity is over-committed until it happens.   He
 will find out from declining hit ratios, and degraded service times.
 When this happens, it is too late.  Under these circumstances, without
 measurements to show the true problem, management may be inclined to
 replace the 6100 with other technology, rather than upgrade a failing
 device.

 Performance of the Automated Patent System hardware, depends heavily on
 getting maximum benefit from the cache on the 6100 controllers.  We
 have no choice but to do exactly that.

III.  CICS Technical Notes

1. CICS user segments and Exclude/Include logic fully supported

   User segment for vendor products added/enhanced

   User clocks/counters/characters segments can be added to CICS type
   110 transaction records; now their order of processing can be set
   by new member IMACICDA, based on the actual order in your CICS MCT.
   IMACICDA also can be used to tell MXG which APPLIDs (CICS regions)
   have which data segments.  Note that while the order of segment
   processing is now set by IMACICDA, it is still necessary for you to
   actually enable segment processing by removing a comment block in
   each of the user segment members you wish to enable.  MXG 9.9 knows
   about the following user segments:

            IMACICDL    IBM Local DL/I counters.
            IMACICDU    Other user data (length still set in IMACICUS).
            IMACICDB    IBM DBCTL counters, CICS/ESA only.
            IMACICOC    Omegamon OMEGBSC (Basic) segment, CICS/ESA only.
            IMACICOL    Omegamon OMEGDLI (DL/I) segment, CICS/ESA only.
            IMACICOB    Omegamon OMEGDB2 (DB2) segment, CICS/ESA only.

   How do you know what user segments exist?  Run MXG's UTILCICS and
   look at the columns CMODNAME and CMODHEAD.  CMODNAME is the module
   that creates the data, and CMODHEAD is the "variable" name created.
   If you look at the end of the transaction record (usually the last
   IBM field is the 72nd, with CMODNAME=DFHDEST and CMODHEAD=TDIOWTT).
   Following that field you may see these optional segments:

    MXG member    CMODNAME     CMONHEAD          length

     IMACICDL      ????????     ????????           68
     IMACICDU      USER-CHOICE  USER-CHOICE        ??
     IMACICDB      DBCTL        RMIDATA           256
     IMACICOC      OMEGBSC      OMEGAMON EMP      116
     IMACICOL      OMEGDLI      OMEGAMON DLI EMP   92
     IMACICOB      OMEGDB2      OMEGAMON DB2 EMP  100

      (The base CICS 3.1 record is 380 bytes, 3.2.1 is 388).

   CICS Include/Exclude logic is now fully supported.

   New member IMACEXCL supports CICS transaction records that have been
   modified by the use of Exclude/Include logic in the CICS MCT.  There
   are two specific vendor products are explicitly supported, and you
   can also define your own modifications in this record.  These macros
   are defined in IMACEXCL for you to change to meet your needs:

     _CICXLTR  - "Enabling" macro selection which controls whether the
                  exclude processing applies for all regions, or only
                  for certain specified CICS APPLIDs.

     _CICXCTR  -  "Code" macro selection which specifies which of the
                  following "Exclude code" macros will be used:

                    _CICXCOM   -  for OMEGAMON for CICS Version 2
                    _CICXCSM   -  for Shared Medical Systems
                    _CICXCUS   -  for "user" defined excludes.

   Instructions for both of these enhancements are contained in comments
   in each of the above IMAC.... members.

IV.   DB2 Technical Notes

 1. Summary of DB2 2.3 data and measurement changes.

   Type 101 accounting records are compatible and previous versions of
   MXG will not fail with DB2 2.3 records, but processing SMF type 100
   or 102 records will cause prior versions of MXG to fail, because
   some fields were expanded in place and other new fields inserted.
   However, the new, important, and needed information that IBM added
   more than makes up for the minor inconvenience of a new MXG version.

                           Contents

   a. Matching DB2 transaction to CICS transactions is now possible.
   b. The new concept of a "Package".
   c. IFCIDs 147 and 148 triplets multiple header pointers.
   d. What's not completed in MXG Version 9.9.
   e. Detail SMF Record structure and control block names.
   f. Header Changes that apply to all records.
   g. DB2STAT0 - Type 100 Subtype 0 SMF Record changes.
   h. DB2STAT1 - Type 100 Subtype 1 SMF Record changes.
   i. DB2ACCT  - Type 101 Subtype 0 SMF Record changes.
   j. T102Snnn - Type 102 IFCIDs SMF Record changes.


   a. Matching DB2 transaction to CICS transactions is now possible.

   DB2 2.3 allows matching DB2 transactions with their CICS counterpart,
   because the DB2 record now contains the CICS Logical Unit of Work ID
   information.  However, there are several "LUWID" fields in DB2, and
   none exactly match field-for-field their CICS counterparts.  Read on:

   In the standard header, QWHS, the QWHSLWID is a 24 byte field that
   identifies the source of the DB2 transaction. However, this LUWID
   does NOT change when thread reuse is used, and thus the QWHS LUWID
   CANNOT be used to match to each CICS transaction record.


               24    QWHSLWID   Logical Unit of Work ID
       ---------------------------------------------------------
            8            8               6               2
       ------------ ------------ ----------------- -------------
        Network ID   LU Name      Instance Number   Commit Count
         QWHSNID      QWHSLUNM        QWHSLUUV        QWHSLUUC

   To solve the thread reuse problem, you must specify the TOKENE=YES
   parameter in your CICS RCT so that a DB2 accounting record will be
   created for every CICS transaction, and the unique LUWID for each
   CICS transaction will be in your DB2 data.  The QWHS LUWID fields
   will not change with thread reuse, but the new QWHCTOKN field, added
   to the correlation header, contains the DB2 LUWID that DOES change
   for each CICS transaction, even when thread reuse occurs.  However,
   the QWHCTOKN is only 22-bytes long; 16-bytes for the Network name,
   and 6 bytes for the unique instance number.

               22    QWHCTOKN
       -------------------------------------------


   Prior to DB2 2.3, the distributed header formerly contained the DB2
   LUWID, but these fields no longer exist (and are listed here just for
   completeness in case you had previously used them), having been now
   replaced by the QWHS and QWHC fields.

               24    QWHDLUWI   Logical Unit of Work ID
       ---------------------------------------------------------
            8            8               6               2
       ------------ ------------ ----------------- -------------
        Network ID   LU Name      Instance Number   Commit Count
         QWHDNETI     QWHDLUNM       QWHDUNIQ         QWHDCCNT

   The QWAC DSECT also previously held parts of the DB2 LUWID, which are
   now redundant with the QWHS/QWHC fields, but for completeness:

                16                                       4
       -------------------------                   -------------
        Network ID + LU Name                        Commit Count
             QWACNID                                  QWACCOMM

   If re-signon has occurred with an identical authorization-id, the
   value of QWACRINV (the field which indicates why accounting was
   invoked) will be set to 6.


   So the bottom line of the DB2 side of the match is to use QWHCTOKN.
   But now, let's look at the CICS equivalents, which have preceded
   their addition to DB2 by several years.  The CICS NETSNAME and UOWID
   fields are used to match all parts of CICS MRO transaction, and these
   same two CICS fields are logical contained in the new QWHCTOKN, but
   it is not straightforward!  First, looking at the CICS fields, the
   CICS NETSNAME is a 20-byte field, and

       NETSNAME contains:          if the originating terminal is:

       netname                       local terminal, from TCT
       networkid.Luname              VTAM ISC LUTYPE6.2 or IRC link
       networkid.generic_applid      non-VTAM or ISC LUTYPE6.1
       jobname.stepname.procname     DL/I batch session

   and NETSNAME is padded by three bytes which may or may not be nulls.
   The periods (EBCDIC hex 4B) shown above are actually in the first 17
   bytes of NETSNAME!  Unfortunately, the new DB2 QWHCTOKN variable has
   only 16 bytes for the NETSNAME part of the match, and those 16 bytes
   do not contain periods.  QWHCTOKN does contain the network name in
   the first 8 bytes (padded with blanks), and the LU name is contained
   in the second 8 bytes (also padded with blanks).  (IBM has not stated
   what QWHCTOKN will contain for DL/I batch source.)

   The remaining 6 bytes of QWHCTOKN are the DB2 "Instance Number"
   or "Uniqueness Value", which is actually a timestamp value, although
   IBM states "though this field may appear to be a timestamp, it is
   not to be processed as one."   This timestamp is passed into DB2
   from CICS, and in MXG CICS data this has been stored as the UOWTIME,
   the first 6 bytes of CICS's 8-byte UOWID (Unit of Work ID).  The last
   two bytes of CICS's UOWID is the count of sync points, just like the
   final two bytes of DB2's LUWID is the number of commits, and cannot
   be used for matching, because it is not constant across transactions.

   MXG thus creates two variables, NETSNAME and UOWTIME from the new DB2
   QWHCTOKN in the DB2ACCT dataset so that DB2 transactions in DB2ACCT
   can be exactly matched to CICS transactions in CICSTRAN.

   b. The new concept of a "Package", which is a lower granularity than
   a PLAN, is captured in a number of type 102 IFCID's records:


   In IFCIDs 29,30,31,53,58-66,124,145, and 148, a new 60-byte area
   overlays a collection of some-old, some-new, and some-expanded
   fields. This 60-byte "Current Package Name" consists of:


           0CL60       "Current Package Name"          CP
        --------------------------------------------------------------

            16           0CL44  "Package Name"         PK
        ---------- ---------------------------------------------------
         Location
         Name          18                18                8
                   ----------------- -------------- ------------------
                    Collection Name   Package ID     Consistency Token
                         or              or                or
                    Collection ID     Program Name      Timestamp

                                     (Program Name was 8-bytes)


   but in IFCIDs 108, 110, and 177 IFCIDs, a 126-byte "superset" field
   is defined that uses the same "Package Name" and PK suffix as the
   above 44-byte part of the 60-byte "Current Package Name"!  MXG has
   labelled the 126-byte variables "Current Package and Version Name".


           0CL126      "Current Package and Version Name"      PK
        --------------------------------------------------------------


          16        18        18       8         0CL66          VR
        -------- ---------- ------- ----------- ----------------------
        Location Collection Package Consistency   2 VL    64    VN
        Name     ID         ID      Token       ------- --------------
                                                Version Version
                                                Length  Name


    Unfortunately, the IBM field names of the sub-components are
    somewhat inconsistent, both vertically and horizontally:

                 IFCID:     29-31 53  58-66 64 108 110 124 145 148 177

  16-byte Location Name      LN   LN   LN   LN  NL  PL  LN  LN  LN  LO
  18-byte Collection Name    CI   PC   PC   CI  NC  PC  CI  PC  CI  CO
  18-byte Package ID         PI   PN   PN   PN  NI  PI  PI  PN  PN  PI
   8-byte Consistency Token  CT   TS   TS   TS  NT  PT  CT  TS  CN  CT
   2-byte    Version Length                     VL  VL              VL
  64-byte    Version Name                       VN  VN              VN


   c. IFCIDs 147 and 148 triplets R5O and R7O point to headers QWHC and
   QWHD that appeared to be redundant to those in the product section,
   but these two sets in these IFI data relate to the agent doing the
   monitoring in the product section, while the agent described in the
   R5O and R7O sections is the agent actually being monitored (e.g.,
   the product agent is the online monitor, the R5O/R7O pair describe
   your TSO session that is using DB2).  MXG keeps the identification
   of the latter agent, the one being monitored, for these IFCIDs.


   d. The following new IFCIDs are not yet decoded by MXG, because no
   sample data records have been created (perhaps too obscure?):

    126  IFI    127  TC4   128  TC4   129  IFI  (130-139 do not exist)
    172  ST3    177  TC3   180  GC9   181  GC9
    182  GC9                                    (184,185 do not exist)
    186  UC                                     (187,188,189 d.n.e.)
    190  GC5    192  ST4   193  ST4   194  ST4
    195  ST4

   e. DB2 2.3 SMF Record Changes - Details and more details!

   DB2 SMF/GTF Records are documented in a multitude of DSECTS in the
   DB2 Macro Library that comes with the IBM Product.  You should ask
   your DB2 person the name of the library, and view the members online
   if you need additional information.  The important members are:

   Member DSNWMSGS - documents the individual fields in the DSECTS by
   field name (which of course is the MXG Variable name).  This member
   is quite extensive in its detail, often containing performance
   discussions for large or small values of particularly critical
   fields.  Simply search for the MXG Variable name of interest. (Note
   that MXG expands the QBS...  buffer fields into four variables QB1...
   QB2... QB3... and QB4... for each of the four buffers).  Eventually
   these descriptions will be in MXG's "Chapter 40" section for DB2
   datasets, when completed.

   The three records (100, 101, 102) are combinations of individual
   DSECTS in the IBM Macro Library that start with DSND.... and end with
   suffixes:

   Record Header (all):          SMF  = QWSP         GTF  = QWGT

   Record Type-Subtype:          100-0    100-1    101     102

   IFCIDs:                       0001     0002     0003    0004-0195

   Structure Defined:            QWST     QWST     QWAS
   Self Defining:                QWS0     QWS1     QWA0    QWT0

   DB2 Headers:  Standard        QWHS     QWHS     QWHS    QWHS
                 Correlation     QWHC     QWHC     QWHC    QWHC
                 Trace           QWHT     QWHT     QWHT    QWHT
                 CPU             QWHU     QWHU     QWHU    QWHU
                 Distributed     QWHD     QWHD     QWHD    QWHD

   Data sections:                QWSA     QXST     QWAC    QW00
                                 QWSB     QTST     QXST    QW01
                                 QWSC     QBST     QBAC    QWPZ
                                 Q3ST     QIST     QTXA    QW02
                                 Q9ST     QTXA     QLAC
                                 QWSD     QISE
                                 QVLS
                                 QVAS
                                 QSST
                                 QLST
                                 QJST
                                 QDST


   f. Type 100/101/102 Header Changes:

   QWS0 - Offsets
       Reserved triplets QWHSRSV3 now OFFQDST (RCO/RCL/RCN) for
       Type 100 Subtype 1.
         Note: Error in IBM Documentation.  DSNDMSGS line 364-366 has
               RCO/RCL reserved instead of DSNDQDST just for RCN.

   QWHS - Standard Header
       LU 6.2 variables, long needed to match DB2 activity directly to
       the CICS/IMS transaction, were formerly only in the Distributed
       Header, but have now been moved to the Standard Header:

        Description       Standard      CICS             Distributed
                          Header Name   Name             Header Name
        NETWORK*ID         QWHSNID      NETNAME  (part)   QWHDNETI
        LUNAME             QWHSLUNM     NETNAME  (part)   QWHDLUNM
        INSTANCE*NUMBER    QWHSLUUV     UOWID    (part)   QWHDUNIQ
        COMMIT*COUNT       QWHSLUCC     UOWID    (part)   QWHDCCNT

       The Logical Unit Of Work ID (called LUWID in DB2, called UOWID in
       CICS) defined for the LU 6.2 interface can now be used to match
       a DB2 instance to its CICS or IMS counterpart.  The DB2 LUWID
       uniquely identifies the thread within the network and consists of
        a. The fully qualified network identification, consisting of
           QWHSNID and QWHSLUNM (two 8-byte fields).
        b. An Instance Number QWHSLUUV,a 6-byte hex datetimestamp.
           (IBM goes out of their way to tell you not to treat this as a
           timestamp, in my opinion, because they want to be free to
           change its value, and they don't want to have define/support
           the event when the timestamp is taken.)
        c. an LUW Sequence Number QWHSLUCC that is used to uniquely
           identify the last COMMIT scope in which the logical unit
           participated in. IBM notes that the -DISPLAY THREAD command
           does not display the COMMIT count, and QWHSLUCC only reflects
           an accurate count when DB2 is acting as a server of another
           DB2, and for a remote unit of work QWHSLUCC is set to one
           before any commits have occurred and thus does not record
           commit activity.
   QWHC - Correlation Header
       One long-needed variable, QWHCATYP, was added to uniquely define
       where this DB2 transaction came from:
           QWHCATYP='CONNECTING*SYSTEM TYPE*CODE'
              1='1:TSO'
              2='2:DB2 CALL ATTACH'
              3='3:DL/I BATCH'
              4='4:CICS ATTACH'
              5='5:IMS ATTACH BMP'
              6='6:IMS ATTACH MPP'
              7='7:DISTRIBUTED UOW'
              8='8:REMOTE UOW'
              9='9:IMS CONTROL REGION'
       One additional, quite significant new field was also added:
           QWHCTOKN='ACCOUNTING*TOKEN'
   QWHD - Distributed Header
       New variables (3) added to Distributed Header:
           QWHDPRID='APPLICATION*REQUESTOR*PRODUCT ID'
           QWHDSVNM='SRVNAM*PARAMETER*OF DRDA EXCSAT'
           QWHDTSTP='DBAT TRACE*RECORD*TIMESTAMP'
       Old variables (4) that were in Distributed Header were removed
       (and renamed into the Standard Header as described previously.

   g. DB2STAT0 - Type 100 Subtype 0 SMF Record changes:

   QWSA - No change.
       The order of the (up to) four QWSA sections, one for each of the
       "Resource Manager and Control Address Spaces" CPU times are:
         1st- Master
         2nd- DBM1
         3rd- IRLM if there are only 3 segments.
         If there are 4 segments, the 3rd is DDF and the 4th is IRLM,
         and there are 4 segments only in a DDF environment.
   QWSB - No change.
   QWSC - No change.
   Q3ST - No change.
   Q9ST - New variable (compatibly added):
          Q9STCTRM='ARCHIVE*LOG*COMMANDS'
   QWSD - No Change.
   QVLS - No Change.
   QVAS - No Change.
   QSST - No Change.
   QLST - New variables (5):
          QLSTCBLB='SWITCHES FROM*CONT BLOCK TO*LIMITED BLOCK MODE'
          QLSTRBND='SQL STATEMENTS*BOUND FOR*REMOTE ACCESS'
          QLSTBROW='MESSAGE*BUFFER ROWS*IF BLOCK FETCH USED'
          QLSTBTBF='BLOCKS*TRANSMITTED*USING BLOCK FETCH'
          QLSTBRBF='BLOCKS RECEIVED USING BLOCK FETCH'
   QJST - No Change.
   QDST - New Control Block.
          Only one new variable:
          QDSTQDBT='DBAT QUEUED*DUE TO MAX*RMT CONCUR THREADS'

   h. DB2STAT1 - Type 100 Subtype 1 SMF Record changes:

   QXST - New Variables (4):
       QXSETHV ='SET*HOST-VARIABLE*STATEMENTS'
       QXALDAB ='ALTER*DATABASE*STATEMENTS'
       QXDRPPKG='DROP*PACKAGE*STATEMENTS'
       QXDSCRTB='DESCRIBE*TABLE*STATEMENTS'
   QTST - New Variables (25):
       QTAUPUB  ='SUCCESSFUL*AUTH CHECKS*EXEC AUTHORITY'
       QTAUTOBA ='ATTEMPTS*TO AUTOBIND*A PACKAGE'
       QTBINDPA ='BIND (ADD)*PACKAGE*SUB-COMMANDS'
       QTBINDPR ='BIND (REP)*PACKAGE*SUB-COMMANDS'
       QTCURPB  ='PB COUNT*CURRENTLY ON*FREE PB CHAIN'
       QTDSDRN  ='DDS THAT*DRAIN HAS*PRODUCED '
       QTEXDRN  ='TIMES THAT*DRAIN PROCESSING*COMPLETED'
       QTFREEAP ='ATTEMPTS*TO FREE*A PACKAGE'
       QTFREEP  ='FREE*PACKAGE*SUB-COMMANDS'
       QTMAXPB  ='MAXIMUM PB*COUNT ON*FREE PB CHAIN'
       QTOPNNO  ='OPEN FAILURE*USING*DRAIN PROCESS'
       QTOPNOK  ='OPEN SUCCESSES*USING*DRAIN PROCESS'
       QTPKABND ='PACKAGES*AUTOBOUND'
       QTPKALL  ='PACKAGES*ALLOCATED'
       QTPKALLA ='ATTEMPTS*TO ALLOCATE*A PACKAGE'
       QTPKGBD  ='PACKAGES*BOUND'
       QTPKGFRD ='PACKAGES*FREED'
       QTPKGRBD ='PACKAGES*REBOUND'
       QTPUBDD  ='DDS USED*FOR CLOSE(NO)*TS'
       QTRBINDP ='REBIND*PACKAGE*SUB-COMMANDS'
       QTRBNDPA ='ATTEMPTS*TO REBIND*A PACKAGE'
       QTREOPN  ='REQUESTED PB*FOUND ON FREE Q*DURING OPEN'
       QTSLWDD  ='DDS USED*FOR SLOW CLOSE*TS'
       QTSTDRN  ='DRAIN DISABLED*NO TRIGGER*REQUIREMENT MET'
       QTTTDRN  ='TIMES THAT*DRAIN HAS BEEN*TRIGGERED'

   QBST - INCOMPATIBLE CHANGES:
       Previous variables deleted and overlaid:
       (IBM Field Names QBSTWMAX QBSTPFDC for each buffer pool)
       QB1TPFDC='1ST TIMES*PREFETCH DISABLED*CONCURRENT'
       QB1TWMAX='1ST WK FILE*NOT CREATE*INSUF BUFFERS'
       QB2TPFDC='2ND TIMES*PREFETCH DISABLED*CONCURRENT'
       QB2TWMAX='2ND WK FILE*NOT CREATE*INSUF BUFFERS'
       QB3TPFDC='3RD TIMES*PREFETCH DISABLED*CONCURRENT'
       QB3TWMAX='3RD WK FILE*NOT CREATE*INSUF BUFFERS'
       QB4TPFDC='4TH TIMES*PREFETCH DISABLED*CONCURRENT'
       QB4TWMAX='4TH WK FILE*NOT CREATE*INSUF BUFFERS'
       New Variables (7 for each buffer pool):
       QB1TLPF ='1ST LIST*PREFETCHES*REQUESTED'
       QB1TMAX ='1ST BUFFERPOOL*NOT SUPPORT*CONCURR WORKFILES'
       QB1TWBVQ='1ST PAGES*DEQUEUED FOR*DESTRUCT READ'
       QB1TWDRP='1ST PAGES FOR*DESTRUCTIVE*READ REQUESTED'
       QB1TWFD ='1ST WORKFILES*DENIED*DURING SORT/MERGE'
       QB1TWFF ='1ST SORT/MERGE*INEFFICIENT*(BUFFER SHORTAGE)'
       QB1TWFM ='1ST MAX WORKFILES*ALLOCATED*DURING SORT/MERGE'
       QB1TWFR ='1ST REQUESTS TO*QUERY FOR WORKFILES*IN SORT/MERGE'
       QB1TWFT ='1ST WORKFILES*REQUESTED*DURING SORT/MERGE'
       QB2TLPF ='2ND LIST*PREFETCHES*REQUESTED'
       QB2TMAX ='2ND BUFFERPOOL*NOT SUPPORT*CONCURR WORKFILES'
       QB2TWBVQ='2ND PAGES*DEQUEUED FOR*DESTRUCT READ'
       QB2TWDRP='2ND PAGES FOR*DESTRUCTIVE*READ REQUESTED'
       QB2TWFD ='2ND WORKFILES*DENIED*DURING SORT/MERGE'
       QB2TWFF ='2ND SORT/MERGE*INEFFICIENT*(BUFFER SHORTAGE)'
       QB2TWFM ='2ND MAX WORKFILES*ALLOCATED*DURING SORT/MERGE'
       QB2TWFR ='2ND REQUESTS TO*QUERY FOR WORKFILES*IN SORT/MERGE'
       QB2TWFT ='2ND WORKFILES*REQUESTED*DURING SORT/MERGE'
       QB3TLPF ='3RD LIST*PREFETCHES*REQUESTED'
       QB3TMAX ='3RD BUFFERPOOL*NOT SUPPORT*CONCURR WORKFILES'
       QB3TWBVQ='3RD PAGES*DEQUEUED FOR*DESTRUCT READ'
       QB3TWDRP='3RD PAGES FOR*DESTRUCTIVE*READ REQUESTED'
       QB3TWFD ='3RD WORKFILES*DENIED*DURING SORT/MERGE'
       QB3TWFF ='3RD SORT/MERGE*INEFFICIENT*(BUFFER SHORTAGE)'
       QB3TWFM ='3RD MAX WORKFILES*ALLOCATED*DURING SORT/MERGE'
       QB3TWFR ='3RD REQUESTS TO*QUERY FOR WORKFILES*IN SORT/MERGE'
       QB3TWFT ='3RD WORKFILES*REQUESTED*DURING SORT/MERGE'
       QB4TLPF ='4TH LIST*PREFETCHES*REQUESTED'
       QB4TMAX ='4TH BUFFERPOOL*NOT SUPPORT*CONCURR WORKFILES'
       QB4TWBVQ='4TH PAGES*DEQUEUED FOR*DESTRUCT READ'
       QB4TWDRP='4TH PAGES FOR*DESTRUCTIVE*READ REQUESTED'
       QB4TWFD ='4TH WORKFILES*DENIED*DURING SORT/MERGE'
       QB4TWFF ='4TH SORT/MERGE*INEFFICIENT*(BUFFER SHORTAGE)'
       QB4TWFM ='4TH MAX WORKFILES*ALLOCATED*DURING SORT/MERGE'
       QB4TWFR ='4TH REQUESTS TO*QUERY FOR WORKFILES*IN SORT/MERGE'
       QB4TWFT ='4TH WORKFILES*REQUESTED*DURING SORT/MERGE'
   QIST - No Change.
   QTXA - No Change.
   EDM  - New Variables (4):
       QISEKTG ='REQ*FOR PT*SECTIONS'
       QISEKTL ='LOAD PT*SECT FROM DASD'
       QISEKT  ='PAGES*USED FOR PT'
       QISESKPT='PAGES*USED FOR SKPT'

   i. DB2ACCT  - Type 101 SMF Record changes:

   See previous discussion on matching DB2 transactions to CICSTRAN
   transactions.  The new QWHCTOKN variable is used to create
       NETSNAME='ORIGINATING*SYSTEM*NET-NAME'
       UOWTIME ='UNIT-OF-WORK*INTERNAL*TIME STAMP'
   which are used to match CICS and DB2 transactions.

   QWAC - New Variables(9):
       QWACALCT='ARCHIVES*LOG MODE*(QUIESCE)'
       QWACAWTR='WAIT TIME FOR READ I/O UNDER ANOTHER THREAD'
       QWACAWTW='WAIT TIME FOR WRITE I/O UNDER ANOTHER THREAD'
       QWACAWTE='WAIT TIME DUE TO SYNCHRONOUS EXEC UNIT SWITCH'
       QWACALOG='WAIT TIME DUE TO PROCESSING OF ARCHIVE LOG'
       QWACARNL='WAITS FOR LOCK/LATCH'
       QWACARNR='WAITS FOR READ I/O UNDER ANOTHER THREAD'
       QWACARNW='WAITS FOR WRITE I/O UNDER ANOTHER THREAD'
       QWACARNS='WAIT TRACE EVENTS PROCESSED FOR SYNC EXEC UNIT SW'
   QXST - New Variables (4):
       QXSETHV ='SET*HOST-VARIABLE*STATEMENTS'
       QXALDAB ='ALTER*DATABASE*STATEMENTS'
       QXDRPPKG='DROP*PACKAGE*STATEMENTS'
       QXDSCRTB='DESCRIBE*TABLE*STATEMENTS'
   QBAC - New Variables(4):
       QB1CLPF ='1ST LIST*PREFETCHES*REQUESTED'
       QB2CLPF ='2ND LIST*PREFETCHES*REQUESTED'
       QB3CLPF ='3RD LIST*PREFETCHES*REQUESTED'
       QB4CLPF ='4TH LIST*PREFETCHES*REQUESTED'
   QTXA - No Change.
   QLAC - New Variables(10):
       QLACBRBF='BLOCKS RECEIVED USING BLOCK FETCH'
       QLACBROW='ROWS IN MSG BUFFER IF BLOCK FETCH'
       QLACBTBF='BLOCKS TRANSMITTED USING BLOCK FETCH'
       QLACCBLB='SWITCHES*FROM CONT BLK MODE TO LIM BLK'
       QLACCIEL='LARGEST*(QLACCNVA-QLACCNVT)*VALUE'
       QLACCNVA='NUMBER OF SUCCESSFUL ALLOCATIONS'
       QLACCNVT='CONVERSATIONS*TERMINATED'
       QLACFLG1='PRIVATE*PROTOCOLS*USED?'
       QLACFLG2='DRDA*PROTOCOLS*USED?'
       QLACRBND='SQL STMTS*BOUND FOR*REMOTE ACCESS'

   j. T102Snnn - Type 102 IFCID nnn SMF Record changes:

    IFCID 29 New Variables:
       QW0029CI='COLLECTION*ID'
       QW0029CT='CONSISTENCY*TOKEN'
       QW0029GL='LENGTH*OF THE PT*SECTION'
       QW0029GN='SEQ NR*WITHINRDS*SECTION'
       QW0029KN='RDS*IDENTIFICATION*NUMBER'
       QW0029LN='LOCATION*NAME'
       QW0029PI='PACKAGE*ID'
       QW0029RS='RESERVED*QW0029RS'
       QW0029SV='SERVICEABILITY*QW0029SV'
    IFCID 30 New Variables:
       QW0030CI='COLLECTION*ID'
       QW0030CT='CONSISTENCY*TOKEN'
       QW0030GL='CALLS TO*DATA MANAGER*FOR THE PT'
       QW0030GN='SEQ NR*WITHINRDS*SECTION'
       QW0030KN='RDS*IDENTIFICATION*NUMBER'
       QW0030LN='LOCATION*NAME'
       QW0030PI='PACKAGE*ID'
       QW0030SV='SERVICEABILITY*QW0030SV'

    IFCID 31 New Variables:
       QW0031CI='COLLECTION*ID'
       QW0031CT='CONSISTENCY*TOKEN'
       QW0031GL='LENGTH*OF THE PT*SECTION'
       QW0031GN='SEQ NR*WITHINRDS*SECTION'
       QW0031KN='RDS*IDENTIFICATION*NUMBER'
       QW0031LN='LOCATION*NAME'
       QW0031PI='PACKAGE*ID'
       QW0031SV='SERVICEABILITY*QW0031SV'
    IFCIDs 53, 58-61, 64-66:
      Package Name (described previously) was added, and program name
      was changed from 8 to 18 bytes.
    IFCIDs 81, QW0081RQ was increased from $1 to @2 bytes.
    IFCIDs 93, QW0081RB was increased from $40 to $48 bytes.
    IFCID 106 New variables:
       QWP1FLAG='FLAG*BITS'
       QWP3MQP ='MAXIMUM*QUIESCE*PERIOD'
       QWP4CNTL='CONTROL*PARAMETER'
       QWP4KSIZ='CONTROL*PACKAGE*HASH TABLE5'
       QWP4MDDN='MAX NR*OF DDS*WITH HOLD'
       QWP4REGA='DDL REG*ART*NAME'
       QWP4REGC='DDL REG*TABLE*OWNER'
       QWP4REGF='DDL REGISTRATION*FACILITY*FLAG'
       QWP4REGN='DDL REG*DATABASE*NAME'
       QWP4REGO='DDL REG*ORT*NAME'
       QWP4SIT ='SITE*TYPE*FLAG'
       QWP4TDDN='VALUE FOR*TRIGGER*DRAIN'
    IFCID 108 New variables:
       QW0108OW='SPECIFIED OWNER*OF PLAN*OR PACKAGE'
       QW0108TY='TYPE OF*OBJECT BOUND*OR REBOUND'
       QW0108QL='QUALIFIER FOR*UNQUALIFIED*OBJECTS'
       QW0108CA='AUTHORIZATION*CACHESIZE'
       QW0108NL='LOCATION*OF*PACKAGE'
       QW0108NC='COLLECTION*ID OF*PACKAGE'
       QW0108NI='PACKAGE*ID'
       QW0108NT='CONSISTENCY*TOKEN*OF PACKAGE'
       QW0108VL='VERSION*LENGTH'
       QW0108VN='VERSION*NAME'
    IFCID 110 New variables:
       QW0110TY='TYPE OF*OBJECT*FREED'
       QW0110PL='LOCATION*OF*PACKAGE'
       QW0110PC='COLLECTION*ID'
       QW0110PI='PACKAGE*ID'
       QW0110PT='CONSISTENCY*TOKEN'
       QW0110VL='VERSION*LENGTH'
       QW0110VN='VERSION*NAME'
    IFCID 124 new variables:
       QW0124CI='COLLECTION*NAME'
       QW0124PN='PACKAGE*ID'
       QW0124CN='CONSISTENCY*TOKEN'
       QW0124NI='NETWORK*ID'
       QW0124LM='LUNAME'
       QW0124UV='UNIQUENESS*VALUE'
       QW0124CC='COMMIT*COUNT'
    IFCID 145 new variables:
       QW0145LN='LOCATION*NAME'
       QW0145PC='PACKAGE*COLLECTION*ID'
       QW0145PN='PROGRAM*NAME'
    IFCID 141  QW0141CO increased from 2 to 4 bytes.

    IFCID 147, 148 new variables:
       QW0148LN='LOCATION*NAME'
       QW0148CI='COLLECTION*NAME'
       QW0148PN='PACKAGE*ID'
       QW0148CN='CONSISTENCY*TOKEN'
       QW0148NI='NETWORK*ID'
       QW0148LM='LUNAME'
       QW0148UV='UNIQUENESS*VALUE'
       QW0148CC='COMMIT*COUNT'
       QW0148EB='WAIT FOR DB2 SERVICE TASK BEGIN'
       QW0148EE='WAIT FOR DB2 SERVICE TASK END'
       QW0148RB='WAIT FOR ARCHIVE LOG MODE(QUIESCE) BEGIN'
       QW0148RE='WAIT FOR ARCHIVE LOG MODE(QUIESCE) END'
       QW0148CT='CONVERSATION*TYPE*INDICATOR'

 2. Using MXG DB2 members ANALDB2R, ANALDBTR, and READDB2

     Chuck Hopf, Hopf Consulting, (214) 327-0881

  Extracting  and  reporting  on  the performance  data  recorded  by
  DB2   can  be  accomplished  quickly  and   easily  using  SAS  and
  Merrill's Expanded  Guide (MXG.)  This paper documents  the use  of
  these  software  packages  in  analyzing  the  performance  of  DB2
  systems.

INTRODUCTION
Since the introduction of DB2, SMF data has been available to assist the
Performance Analyst and the DB2 DBA (Data Base Administrator) in problem
determination and planning for the use of DB2.  MXG has supported DB2
SMF data since availability, and provides a reporting facility that
produces reports similar to IBM's DB2PM Performance Monitor product.

This facility has the capacity to extract data from live SMF datasets
(SYS1.MANx), SMF dump datasets, or in some instances, GTF datasets.  DB2
data should always be directed to SMF instead of GTF for several
reasons.  First and foremost, the "write" of DB2 data to GTF requires an
actual physical I/O, managed by DB2, which can interfere with that which
is being measured, whereas the "write" of DB2 data to SMF is not a
physical write, but rather is a data movement at memory speed from the
DB2 address space to the SMF address space, which increases the accuracy
of DB2 timestamps.  Second, SMF records are 32760 bytes long, whereas
GTF is limited to 256 bytes in each physical record, which means that
not only is the overhead of creation significantly less with SMF than
with GTF, but also your processing programs will be more efficient using
SMF data.  Finally, if the logical data length exceeds 256 bytes to GTF,
a very non-standard spanning format is used, in which actual data fields
can be split across records, and this format is not supported by SAS;
thus some DB2 GTF records cannot be read with SAS!

MXG processes DB2 records and will also store DB2 data as SAS datasets
for future reference or for additional reporting without reprocessing
SMF data.  The stored detail data can also be TRENDed for developing
long term capacity trends and plans of DB2 performance and resources.

MXG uses the "old style, substitution" MACRO definitions as shorthand
for the processing of all SMF data, and uses the "new" %MACRO facility
for report generation and selection.  The primary reporting %MACRO in
MXG is %ANALDB2R, which itself invokes the %MACRO named %READDB2 (if
raw SMF data is to be read), which then dynamically constructs a SAS
program of old style _VAR and _CDE macro definitions (that are defined
in ANALDBTR) to create the needed SAS datasets for DB2 reporting.

DB2 Statistics records cannot be used directly, because they contain the
cumulative total in their counters, rather than delta values for the
interval.  This requires the SAS datasets to be created, then sorted,
and then de-accumulated; member DIFFDB2 uses the powerful DIF() function
to accomplish this deaccumulation.

In the case of many types of TRACE data, such as a READ event, a record
is written at the beginning of an event and a second record is written
at the end of the event.  These records must be paired to measure the
true results of the operation.  The first record contains information on
what was requested while the second the records the activity counts.
Member ANALDBTR provides the "PAIRing" logic for DB2 Trace records.


READING SMF DATA
Several options are available for reading the SMF or GTF data using MXG.

With three SMF records and over 200 subtypes, processing all possible
DB2 records can require appreciable virtual storage.  Under SAS 5.18 it
is not possible to process all DB2 2.3 records in a single pass, but the
SAS Version 6 implementation eliminated this constraint, although it may
require a MEMSIZE=28M option in your CONFIG member.

A normal MXG program to process SMF data will %INCLUDE a member of the
MXG source library, named TYPExxxx, to build a SAS dataset TYPExxxx.
The TYPExxxx member invokes three MXG substitution style macros named
_SMF, _VARxxxx, and CDExxxx that are defined in member VMACxxxx.  (All
MXG old style macros begin with an underscore as a naming convention.)
Figure 1 is an example for the SMF type zero (IPL) record processing.

     //SASJOB JOB ACCOUNTING-INFO
     //SAS EXEC SAS606,CONFIG='MXG.SOURCLIB(CONFIG)'
     //SOURCLIB DD  DSN=USERID.SOURCLIB,DISP=SHR
     //         DD  DSN=MXG.SOURCLIB,DISP=SHR
     //LIBRARY  DD  DSN=MXG.FMTS606,DISP=SHR
     //SMF DD DSN=MY.SMFDATA,DISP=SHR
     //SYSIN DD *
     %INCLUDE SOURCLIB(TYPE0);

     Member TYPE0 of the MXG SOURCLIB would contain:

     %INCLUDE SOURCLIB(VMACSMF,VMAC0);
     DATA
     _VAR0
     _SMF
     _CDE0
     ;

     Figure 1. Example of typical MXG job.


MXG's TYPEDB2 member is similar to the above example, but it processes
SMF type 100 records (subtypes 0 and 1) and SMF type 101 records, using
the _VARDB2 and _CDEDB2 macros defined in VMACDB2 to simultaneously
creates the three DB2 datasets DB2ACCT, DB2STAT0, and DB2STAT1.  It also
then invokes member DIFFDB2 to deaccumulate DB2STAT0 and DB2STAT1.

The _VARxxxx and _CDExxxx "record-level" macros process one or more SMF
records, but for DB2 trace data, additional "subtype-level" macros are
defined in VMAC102 that permit subtype selectivity for each IFCID
(subtype) that can be created.  Defined in member VMAC102, they have
names of the form _V102nnn and _C102nnn, where nnn is the IFCID to be
processed.  Just as _VARxxxx and _CDExxxx macros can be combined to

create multiple datasets from multiple records simultaneously, the
_V102nnn and _C102nnn macros can be used for multiple subtype processing
in a single run.  Macros _VAR102 and _CDE102 are defined in VMAC102, and
combine all possible "subtype-level" _V102nnn/_C102nnn macros to
simultaneously build all 125 possible trace datasets, and member
TYPE102 looks just like TYPE0 example in Figure 1.

Let's examine the wrong and the right way to use MXG for DB2.

One way to read the DB2 Accounting, Statistics, and Trace Data is shown
in Figure 2, complete with sample JCL for SAS 6.06.

     //SASJOB JOB WHAT_WORKS
     //SAS EXEC SAS606,CONFIG='MXG.SOURCLIB(CONFIG)'
     //SOURCLIB DD  DSN=USERID.SOURCLIB,DISP=SHR
     //         DD  DSN=MXG.SOURCLIB,DISP=SHR
     //LIBRARY  DD DSN=MXG.FMTS606,DISP=SHR
     //SMF DD DSN=MY.SMFDATA,DISP=SHR
     //SYSIN DD *
     %INCLUDE SOURCLIB(TYPEDB2,TYPE102);

     Figure 2: One way to READ DB2 SMF DATA

THIS IS THE WRONG WAY.  Concatenation of the two TYPExxxx members will
build all possible datasets, but each TYPExxxx member will read the
SMF dataset one time.  In addition, all of the datasets built will have
been written to the work file (a temporary dataset), and nothing will be
stored!  You could add a permanent DD (perhaps //PDB DD ...) and then
PROC COPY IN=WORK OUT=PDB to store the datasets, but it would still need
two passes of the entire SMF file for your DB2 data, and do you really
want all 195 subtypes of the 102 record?

A better way is to tell MXG what specific datasets/subtypes you want by
%INCLUDEing the macro definitions, and then specifying what you want:

     //SYSIN DD *
     %INCLUDE SOURCLIB(VMACDB2,VMAC102,VMACSMF,IMACKEEP);
     DATA
      _VARDB2
      _V102106
      _V102038
      _SMF
      _CDEDB2
      _HDR102
      _C102106
      _C102038
      _END102
     %INCLUDE SOURCLIB(DIFFDB2);

     Figure 3: Reading Specific IFCIDs

As many IFCIDs as desired may be specified in a single program when
running SAS version 6.06.  Under SAS version 5.18, multiple IFCIDs may
be read, but the number is limited based on the number of iterative DO
loops contained in the code to read each IFCID. Since this number varies
from one IFCID to another, it is not possible to predict how many IFCIDs
can be read with SAS 5.18.  The SAS program in figure 3 will read the
DB2 accounting, statistics, system parameter (IFCID 106) and the IFCID
38 records.  DIFFDB2 is then invoked to finish the process by sorting
the accounting records and deaccumulating the statistics records, but it
still does not store any datasets nor produce any reports.  Read on!

DB2 traces can also be invoked at the Trace Class level by the type of
Trace Class (Accounting, Audit, Performance, Statistics, etc.) and the
Trace Class Number.  Thus MXG also provides Trace Class macros.

MXG supports the ACcounting, AUdit, GLobal, MOnitor, and PErformance
trace classes.  For each class, there is a _VTRccmm and a _CTRccmm macro
corresponding to the "subtype-level" but creating all possible datasets
from a trace class instead of one subtype.  The "cc" is the trace class,
the first two characters of the trace name ("AC" for ACcounting, "AU"
for AUdit, etc.), and the "mm" is the trace class number.  PErformance
Trace Class 3 macros are named _VTRPE03 and _CTRPE03. See Figure 4.

     //SYSIN DD *
     %INCLUDE SOURCLIB(VMACDB2,VMAC102,VMACSMF);
     DATA
     _VARDB2
     _VTRPE03
     _VTRMO01
     _SMF
     _CTRDB2
     _HDR102
     _CTRPE03
     _CTRMO01
     _END102
     %INCLUDE SOURCLIB(DIFFDB2);

     Figure 4: Reading Specific Trace Classes

This is still not the best way, because when using this technique, it is
your responsibility to ensure that no duplicate IFCIDS are generated by
the multiple trace classes specified.  For example, Monitor Trace Class
3 and Performance Trace Class 2 both generate IFCIDs 174 and 175. If you
used _VTRMO03 and _VTRPE02 in the same program, a syntax error occurs.

To assist the user in resolving this problem and simplify the process of
reading DB2 trace data, a %MACRO was constructed to perform the tasks
of determining the IFCIDs needed for any trace class and to generate the
code while preventing the possibility of duplicate IFCID code.  The new
macro is called %READDB2, and it IS the best way to process DB2 data.

%READDB2 lets you enter lists of IFCIDs and/or Trace Classes, and it
generates the SAS code, eliminating any duplicate IFCID processing you
might have requested.  There are four macro arguments defined which let
you modify the %READDB2 processing.  They are listed below in Table I,
and are more completely defined in the member READDB2 itself.

Table I: READDB2 Parameters and Meanings


   Parameter    Default/Meaning

   INFILE       SMF -   May be either SMF or GTF depending on the source
                        of the DB2 data records to be read.
   PDBOUT       PDB -   Default DDNAME describing the SAS data library
                        into which the DB2 datasets will be written.
                        WORK DDNAME is used if PDBOUT is blank.
   IFCIDS       blank - The list of IFCIDS to be read.  May be any
                        combination of the words  ACCOUNTS, STATISTICS,
                        ALL, or any number from 0 to 199.
   TRACECLS     blank - The DB2 Trace class(es) to be read. A list of
                        previously described trace class names.
   INVOKEBY     Used for communication with ANALDB2R. DO NOT MODIFY.


The invocation of %READDB2 to read the Accounting and Statistics records
and the System Parameter Record (IFCID 106) is shown in Figure 5.

     //SYSIN DD *
     %READDB2(INFILE=SMF,IFCID=ACCOUNT 106);

     Figure 5: Invoking %READDB2

This invocation of %READDB2 would read all of the accounting, statistics
and IFCID 106 records in the input SMF file, invoke DIFFDB2 to sort the
accounting records and deaccumulate the statistics records, and copy all
of the resulting datasets to the ddname PDB.

Much more complex invocations of READDB2 are possible.  When running
Version 6 of SAS, it is possible to read all DB2 created records in a
single pass of the SMF data using READDB2 as illustrated in figure 6.

     //SYSIN DD *
     %READDB2(INFILE=SMF,IFCIDS=ALL);

     Figure 6: Reading ALL DB2 Record Types

Selection of multiple IFCIDS and TRACE classes is also possible.  Figure
7 illustrates the invocation to read IFCIDS, 34 35 37 38 and the Audit
class 1 and 2 data in a single pass.  READDB2 dynamically determines if
duplicate IFCIDs are called for in a request and eliminates the
duplicate requests prior to generating the SAS program to read the data.

     //SYSIN DD *
     %READDB2(
     %READDB2(IFCIDS=34 35 37 38,TRACECLS=AU01 AU02);

     Figure 7: Reading Multiple IFCIDs and Trace Classes with READDB2

%READDB2 will execute under both version 5 and 6 of SAS.  Under Version
5 a region size of 6M is recommended, but a message is generated that a
344 ERROR is possible if too many IFCIDs were requested. If this does
occur, reduce the number of IFCIDs or trace classes requested and rerun
the job.  If ALL is specified as the IFCID when running version 5 of
SAS, the program is automatically aborted since it is not possible to
run (or even compile) a program with ALL IFCIDs under Version 5 of SAS>

For version 6 users, a MEMSIZE of 28M is required to process ALL records
in a single pass. In most other instances the default MXG MEMSIZE of 24M
is adequate.

"DIFFing and PAIRing" DB2 Data

As mentioned earlier, some types of DB2 data require further processing
before reports can be generated.

The Statistics data is maintained as running counters in the SMF data
and any given record reflects the sum of all activity for that
particular execution of a DB2 subsystem up to the point in time at which
the SMF record was written. For this reason, any time that TYPEDB2 is
invoked, in BUILDPDB processing, or READDB2 processing, member DIFFDB2
is included to perform the DIFFing of the statistics and to sort the
accounting data into a somewhat meaningful sequence.


The DB2 Trace records do not suffer from this particular problem, but do
require preprocessing before reporting.  In many instances, the data
required to report on any specific DB2 event (READ, BUFFER GET, SQL
Statements, etc.) are contained in two records.  The first record
typically contains information describing the event such as the Database
accessed, the PAGESET, the SQL statement type to be executed, etc.  The
second record contains the information about how the request was
processed. Was it successful, how much I/O was performed, how many rows
were read, etc. Since many other events (including others of the same
type) may intervene between the start and end of a particular event,
putting these records back together so that a report can be generated is
not exactly straightforward.

Member ANALDBTR contains the SAS code in the form of substitution macros
needed to "PAIR" the current DB2 record pairs. Figure 8 is the SAS code
needed to read the DB2 trace record subtypes 6 and 7 (Begin and End Read
IO) using READDB2 to read the data and then invoking the statement style
_006PAIR macro to perform the "PAIRing."  Each of these macros creates
one or more datasets where the dataset name is SxxxSyyy where xxx is the
Begin Event subtype and yyy is the End Event subtype.  (The subtype 183
is paired with itself, and creates I183R183, the only naming exception).

     //SYSIN DD *
     %READDB2(IFCIDS=6 7);
     %INCLUDE SOURCLIB(ANALDBTR);
     _006PAIR
     Figure 8: Reading and Pairing DB2 Trace Records

Multiple _xxxPAIR macros can be invoked in a single pass. Figure 9
illustrates the same technique to create the PAIRs for  Read (S006S007)
Write (S008S009 S010S009) and SQL statements (S059S058 S060S058 S061S058
S062S058 S063S058 S064S058 S065S058 S066S058).  Notice that in the case
of both the write and SQL activity that there are multiple pairs that
share a common end record (9 for write and 58 for SQL.)

     //SYSIN DD *
     %READDB2(IFCIDS=6 7 8 9 10 58 59 60 61 62 63 64 65 66);
     %INCLUDE SOURCLIB(ANALDBTR);
     _006PAIR
     _008PAIR
     _058PAIR

     Figure 9: Processing Multiple Pairs

Another method of creating multiple record pairs is with the ANALDBTR
new style macro.  This macro will generate the calls to the requested
_xxxPAIR macros based on parameter driven input.  The parameters for
ANALDBTR with their default values are contained in table II.

Figure 10 illustrates the use of ANALDBTR to create the same paired data
(Read, Write, and SQL) as figure 9.

     //SYSIN DD *
     %READDB2(IFCIDS=6 7 8 9 10 58 59 60 61 62 63 64 65 66);
     %ANALDBTR(PAIRS=6 8 58);

     Figure 10: Using ANALDBTR to Pair DB2 Trace Records

ANALDBTR could be used to produce simple reports of I/O activity from
the PDB (assuming that the appropriate data is in the PDB DDNAME) simply
by pairing the I/O related records and PROC PRINTing the resulting
datasets as illustrated by Figure 11.  _PAGE_ 27

     %READDB2(IFCIDS=6 7 8 9 10);
     %ANALDBTR(PAIRS=6 8);
     PROC PRINT DATA=S006S007 SPLIT='*'; TITLE 'DB2 READ I/O';
     PROC PRINT DATA=S008S009 SPLIT='*'; TITLE 'DB2 SYNC WRITE I/O';
     PROC PRINT DATA=S010S009 SPLIT='*'; TITLE 'DB2 ASYNC WRITE I/O';

     Figure 11. Simple I/O Reports if data is in your PDB

These would be very simplistic reports but might be very useful and
quick.  For more sophisticated DB2 reporting requirements, MXG provides
a more robust set of reports.


Producing DB2 Performance Reports

Production of DB2 performance reports under MXG is accomplished by the
%ANALDB2R macro defined in member ANALDB2R.  This member of the MXG
SOURCLIB contains many SAS MACROs (both %MACROs and substitution style)
that work together to allow dynamic selection of the types and sort
sequences of many of the DB2 reports.  The MXG implementation requires
certain SAS options to be specified.  Under Version 5, these required
options are set by %INCLUDE SOURCLIB(SASOPTV5); as the first statement
of your program, with OPTIONS='MWORK=28K' specified on your // EXEC SAS
statement.  Under SAS Version 6, the CONFIG= JCL parameter points to the
CONFIG member which specifies these required options.
By default, ANALDB2R produces the Accounting Summary, Accounting Detail,
Statistics Summary, and the System Parameter reports.  As with all DB2
reports using MXG, the report is only produced if the data required for
the report is available.  The data required for each class of DB2 report
was contained in Table I (see page 27, above).  In many cases, not all
of the listed data is mandatory to produce the report.

Refer to the DB2PM Reference Manual SH20-6858-02 for report contents.

%READDB2 is used by %ANALDB2R to read the raw SMF data if the data is
not already contained in the PDB.  Additionally, raw SMF data and data
from one or more PDB datasets can be combined for reporting so that both
old and current measurements may be combined on a single report.  The
only restriction on this is that SMF (or GTF) must be the first entry in
the PDB= list.

PDBOUT can be used to store the resulting SAS datasets in any desired
SAS data library simply by specifying PDBOUT=DDNAME, where DDNAME is the
DDNAME describing the SAS data library.

Figure 12 is an example of JCL to read the DB2 data using ANALDB2R
including performance trace classes 1 and 2 and audit class 1 and place
the resulting data in the PDB before creating the default reports.

    //SYSIN DD *
    %ANALDB2R(PDB=SMF,PDBOUT=PDB,TRACECLS=PE01 PE02 AU01);


    Figure 12: JCL to read data with ANALDB2R

When the TRACECLS or IFCID options of %ANALDB2R are used, those datasets
are added to the list of IFCIDs processed by default.  Thus this example
also produces the accounting, statistics, and system parameter datasets
because they are enabled by default in ANALDB2R.

Figure 13 is an example of creating only the Accounting Summary report
while reading raw SMF data and combining the results with data from a
PDB and a TREND database. The specification to eliminate a default
report is PMxxxnn=NO where xxx is the report type and nn is the report
number.

     //SYSIN DD *
     %ANALDB2R(PDB=SMF PDB TREND,PMACC02=NO,PMSTA02=NO,PMSPR01=NO);

     Figure 13: Accounting Summary Report from SMF, PDB, and TREND

OTHER REPORTS and FEATURES

A %MACRO variable exists for each report defined in %ANALDB2R, which has
an initial value of either blank or YES.  To enable a report which has
default NO, it is only necessary to specify the  MACRO variable name
with a "YES" in the form MACRO Variable = YES at the time ANALDB2R is
begun. Table IV identifies all of the reports available the MACRO
variable name, and the default value used, Table III the IFCIDs required
to produce each report, and Table II, the Trace Classes which should be
enabled by the DBA to produce the data for a specific report.  Figure 14
is an example requesting the reading of raw SMF data from the SYS1.MAN1
dataset, suppressing the default reports, and creating the Lock
Suspension Summary report.

     //SYSIN DD *
     %ANALDB2R(
     PDB=SMF,
     PMACC01=NO,   /* NO ACCOUNTING SUMMARY */
     PMACC02=NO,   /* NO ACCOUNTING DETAIL  */
     PMAUD01=YES,  /* PRINT LOCK SUSPENSION SUMMARY */
     PMSTA02=NO,   /* NO STATISTICS SUMMARY REPORT */
     PMSPR01=NO);  /* NO SYSTEM PARAMETER REPORT */

     Figure 14: Read SMF and Produce Only the Lock Suspension Report

To reduce the volume of data and reports that must be processed by the
analysts, many variables are also supplied for data selection.  In each
case, a MACRO variable name must be supplied followed by the "= string "
where the string is the value(s) desired. The length of the string
supplied as the MACRO value is also used to determine the length of the
comparison. Thus, if PLAN=MXG were specified, all plans beginning with
the string MXG would be selected.

To further simplify the analysis process, accounting and audit reports
may be sorted by up to three different variables and the statistics
report can be summarized to intervals other than the intervals at which
the data was written.

For example, if a DB2 plan that was known to have a performance problem
was being executed in a production system while the "new improved
version" of the same plan was being executed in a test system, the
Accounting Summary report could be run specifying "SORTBY=PLAN DB2".
This would result in the data for the two subsystems appearing on two
consecutive lines of the same report simplifying the task of comparing
the performance results.

As another example, the Statistics Detail Report can be a very valuable
tool, but the volume of the report can be quite large.  Each interval

can generate up to nine pages, depending on the number of buffer pools
in use.  With four buffer pools, each hour could potentially result in
36 pages of SYSOUT for the analyst to digest.  Specification of
"INTERVAL=HOUR" would summarize the data at the hourly level while
"INTERVAL=DATE" would result in summarization at a daily level.

The Audit Detail and Trace reports also may generate large volumes of
data. To reduce this volume, the AUDIT= parameter is provided.  From one
to seven of the Audit classes may be specified separated by blanks and
terminated by either a comma or a left parenthesis (the parenthesis
used if it is the last parameter and the comma in all other cases.) Thus
the specification of "AUDIT=AUTHFAIL AUTHCNTL" used with either PMAUD02
or PMAUD03 would result in the creation of the Audit reports for
Authorization Failures or Authorization Control events.

Data may also be reduced through the selection of a time range for the
report.  This is accomplished with the BEGTIME and ENDTIME parameters.
Either or both of these parameters may be used employing the SAS
DATETIME format to describe the desired date and time. To select all
data beginning with August 8, 1990, specify "BEGTIME=08AUG90:00:00:00".
Note that quotation marks around the DATETIME literal are not required.

A complete list of the %ANALDB2R parameters and their meanings is
contained in Table V, (page 32, below), and in member ANALDB2R itself.

EXAMPLES OF USE
The following examples all make the assumption that the required data
for the reports has been gathered and placed in the MXG PDB. Figure 15
presents the JCL required to execute these examples.  For example
purposes, SAS version 6.06 and MXG version 9 are assumed.

     //SASJOB JOB ACOUNTING-INFO
     //SAS EXEC SAS606,REGION=4M,
     // CONFIG='MXG.SOURCLIB(CONFIG)'
     //SOURCLIB DD DSN=USERID.SOURCLIB,DISP=SHR
     //         DD DSN=MXG.SOURCLIB,DISP=SHR
     //LIBRARY  DD DSN=MXG.FMTS606,DISP=SHR
     //PDB DD DSN=MXG.PDB,DISP=SHR
     //SYSIN DD *

     Figure 15 Example JCL

Example 1:
Produce the Accounting Detail and Accounting Summary reports sorted by
DB2 subsystem and plan.  Also produce the Statistics Detail report
summarized at one hour intervals.  The SYSIN required is contained in
Figure 16.

Notice that the default reports that are not desired must be specified
with a "NO" to suppress the printing of the reports.

     //SYSIN DD *
      %ANALDB2R(PMACC01=YES,PMACC02=YES,PMSTA01=YES,PMSTA02=NO,
                PMSPR01=NO,SORTBY=DB2 PLAN,INTERVAL=HOUR);

     Figure 16: Example 1

Example 2:
Produce all default reports in the default sequences and also produce
the Accounting Summary Report sorted by plan, connection, and subsystem.


     %ANALDB2R;
     %ANALDB2R(PMACC01=NO,PMACC02=YES,PMSTA02=NO,PMSPR01=NO,
               SORTBY=PLAN CONNID DB2);

     Figure 17: Example 2

In this example it was necessary to execute ANALDB2R twice since only a
single combination of SORTBY values may be specified. Also notice that
the parameters may be placed on a single line so long as the parameters
(not their values) are separated by commas.

Example 3:
Produce all default reports and produce the Audit Detail Report for
authorization failures and audited DDL accesses. Also produce the Lock
Suspension Summary and the Buffer Pool Manager Summary.

In this example, the entire command sequence is entered as a continuous
string.  Notice that the parameters may be specified in any order and
that the number of spaces is not significant.

     %ANALDB2R(PMAUD02=YES,AUDIT=AUTHFAIL DDL,PMLOK01=YES,PMIOS01=YES);

     Figure 18: Example 3

EXECUTION NOTES ON THE SAS LOG
ANALDB2R prints a list of the parameters entered when executed.

MXGNOTES and MXGWARN messages may be produced by ANALDB2R.  The most
important are those indicating that either datasets could not be found
or that although the datasets exist, no data could be found that met the
selection criteria specified by the user.  For example, the Lock
Suspension Report requires the S044S045 and the T102S054 datasets. If
none of the datasets exist in the PDB DDNAME, or they all contain zero
observations, a MXGWARN is produced.

If a CLIST has been installed with the necessary libraries defined
(SOURCLIB, SASLIB, and PDB), ANALDB2R can also be executed from a SAS
TSO session. This is not recommended unless a 132 character screen is
available and all of the data required has already been placed in SAS
datasets. All of the reports generated by ANALDB2R are more than 80
characters wide and the CPU time to reduce the SMF data may be
prohibitive for a TSO session (because of higher overhead vs batch).

   Table II: Trace Classes Required to Produce Reports

   Type of Report         Trace Type            Trace Class

   Accounting             Accounting            1 2 3
   Audit                  Audit                 1 2 3 4 5 6 7 8 9
   IO Subsystem           Performance           4 5
   Locking                Performance           6
   SQL Trace              Accounting            1 2 3
   SQL Trace              Performance           1 2 3 4 6 8 13
   Statistics             Statistics            1
   System Parameter       System Parameter      Any
   Record Trace           ALL                   ALL
   Transit Time           Performance           ALL

   Table III: IFCIDs Required for Reports

   Report Type     IFCIDs
   Accounting      3
   Audit           23 24 25 55 83 87 105 107 140-146
   IO Subsystem    6-10 29-30 34-41 105 107 114-116 119-120
   Locking         44 45 54 105 107
   SQL Trace       3 6-9 11-12 15-20 22 44-45 53 55 58-66 68-71 73-75
                   86-89 95-96 105 107 124-125 183
   Statistics      1 2
   System Parms    106
   Record Trace    ALL
   Transit Time    4-12 19-20 22-25 44-45 53 55 58-66 68-79 84-92 95-97
                   105 107-111

     Table IV - Available Reports and Defaults

     DB2 Report Name                             MACRO     DEFAULT
     Accounting Summary Report                   PMACC01    YES
     Accounting Detail Report                    PMACC02    YES
     Accounting Trace Short Form                 PMACC03
     Accounting Trace Long Form                  PMACC04
     Audit Summary Report                        PMAUD01
     Audit Detail Report                         PMAUD02
     Audit Trace Report                          PMAUD03
     Buffer Pool Manager Summary                 PMIOS01
     EDM Pool Manager Summary                    PMIOS02
     LOG Active LOG Report                       PMIOS03
     ARCHIVE LOG/BSDS Report                     PMIOS04
     Lock Suspension Summary                     PMLOK01
     Lock Contention Summary                     PMLOK02
     Lock Contention Trace                       PMLOK03
     SQL Trace Summary                           PMSQL01
     SQL Short Trace Report                      PMSQL02
     SQL Long Trace Report                       PMSQL03
     SQL DML Trace Report                        PMSQL04
     Statistics Detail Report                    PMSTA01
     Statistics Summary Report                   PMSTA02    YES
     Statistics Trace Long Form                  PMSTA03
     Statistics Trace Short Form                 PMSTA04
     System Parameter Report                     PMSPR01    YES
     Record Trace Short Form                     PMTRC01
     Record Trace Long Form                      PMTRC02
     Transit Time Report                         PMTRN01

                     Table V - Selection Parameters

       Parameter   Description
        DB2         A list of full or partial DB2 subsystems to
                    be selected.
        PLAN        A list of full or partial DB2 Plans to be
                    selected.
        CONNID      A list of full or partial CONNECTION IDs to
                    be selected.
        CORRID      A list of full or partial CORRELATION IDs to
                    be selected. (See MXG member IMACDB2)
        AUTHID      A list of full or partial Authorization IDs
                    to be selected.
        DATABASE    A list of database IDs (HEX string) to be
                    selected.
        PAGESET     A list of pageset IDs (HEX string) to be
                    selected.
        DB2LOCAL    A list of the LOCAL DB2 systems in a DDR
                    environment to be selected.
        DB2REMOT    A list of the REMOTE DB2 systems in a DDR
                    environment to be selected.
        TRACENUM    A list of the DB2 TRACE numbers to be selected
        NETSNAME    A list of the NETSNAMEs to be selected. *
        NETID       A list of the QWHSNIDs to be selected. *
        LUNAME      A list of the QWHSLUNMs to be selected. *
        INSTANCE    A list of the QWHSLUUVs to be selected. *
        TOKEN       A list of the QWHCTOKNs to be selected. *
        CNETID      A list of the QWACNIDs to be selected. *
        DNETID      A list of the QWHDNETIs to be selected. *
        DLUNAME     A list of the QWHDLUNMs to be selected. *
        DINSTNCE    A list of the QWHDUNIQs to be selected. *
        SORTBY      A list of up to three variables from the
                    above by which the data should be sorted.+
        BEGTIME     The earliest DATETIME that will be selected
                    from the specified input data source.
        ENDTIME     The latest DATETIME that will be selected
                    from the specified input data source.
        AUDIT       Up to seven AUDIT classes to be selected.
                    Valid values are:
                    AUTHFAIL - Authorization Failure
                    AUTHCNTL - Authorization Control
                    DDL      - Audited DDL Access
                    DML      - Audited DML Access
                    BIND     - DML at BIND
                    AUTHCHG  - Authorization BIND
                    UTILITY  - Utility Access
        INTERVAL    Summarize the data to the specified interval.
                    (See VMXGSUM for documentation)
        MYTIME      User specification of time interval. See
                    VMXGSUM for details.

               * version 2.3 of DB2 only

               +  Valid only for the PMACC01, PMACC02, PMAUD01, and
                  PMAUD02 reports.

V.    SAS Technical Notes.

 1. CALL YOUR SAS SALESPERSON AND REQUEST EARLY SHIPMENT OF SAS 6.07!!!

    SAS 6.07 has begun shipping to all their customers, but it will take
    some time to build and ship their individualized tapes to all sites.
    They will be pleased to move you to the top of the shipment list, if
    you simply contact your SAS Salesperson and request early shipment.

    Merrill Consultants STRONGLY RECOMMENDS IMMEDIATE INSTALLATION OF
    SAS 6.07 as full replacement for SAS version 5.  It's REALLY THAT
    GOOD, and it's even better than the benchmarks in Newsletter TWENTY!

 2. PROC CONTENTS DATA=PDB._ALL_ DETAILS; under SAS 6.07 now provides
    the number of observations and number of variables, one per line,
    similar to the SAS 5.18 contents.  It is said that SAS 6.08 will
    add the dataset size to the DETAILS option information.

 3. SAS 6.07 has cleaned up their %MACRO compiler significantly. The
    compile CPU time for ANALDB2R with and without input data:

                       0-obs              75-acct,34-stat
        SAS 5.18        27.7                    29.7
            6.06       261.4                   267.9
            6.07        58.1                    61.4


    (Note that these are the SAS Session CPU times, and do include the
    CPU time for the %MACRO compile.  The individual Data and Proc step
    CPU times DO NOT INCLUDE the compile time. In one ANALDB2R run with
    the default reports plus Statistics Detail, and only a few hundred
    records, the %MACRO compile time was 47% of the step total!)

 4. If you run out of disk space in your WORK file while processing
    %MACRO definitions, you may get SAS messages:

      THE SAS SYSTEM IS UNABLE TO OPEN A MACRO SYMBOL TABLE. and/or
      UNABLE TO WRITE HEADER INFORMATION FOR CATALOG WORK.SYSST3.

    indicating you need to increase the WORK space allocation.

 5. If you experience strange error messages under SAS 6.06/6.07,
    especially with a BUILDPDB that has been tailored to process many
    additional SMF records, increase the value of MEMSIZE (some sites
    have raised it to 24MB, one site raised it to 32MB, and one of my
    own stress test programs that compiles every SMF record on the face
    of the earth required 56MB!).  When SAS runs out of virtual memory
    in its compile phase, it may produce unrelated messages concerning
    a SAS VIEW, or Not Enough MFEs, etc., etc.
    Added in 1999:  The default MXG MEMSIZE has been 48MB for some time;
    make sure your REGION=48MB is specified to let SAS get all 48MB.
    Some very old MXG examples show REGION=4M which no longer works!
    The Not Enough MFEs can happen with 6.08 and 6.09, too.

 6. SAS 6.06 has been repaired, and can now be installed and used.

    SAS 6.06 has been repaired, as long as you have installed the
    October, 1991, or later, SAS Usage Notes tape maintenance, which
    contains an IEBCOPY load library with ALL SAS ZAPs pre-applied for
    all SAS products.  The following resolved problems should be noted:

    One site reported that they received an OC1 when reading an SMF file
    but by removing Z6062909 (on the December SAS tape), the OC1 went
    away.  Unfortunately, Z6062909 was created to force the OC1 ABEND,
    so that you would know you had had an I/O error when SAS discovered
    that some I/O errors occurred that returned a zero condition code!
    SAS is still working on a real fix to the I/O error problem.

    SAS Z6063476 (on SAS October tape).  Unable to read a SAS dataset
    that was built by Version 5.18 using Tape format (i.e., built with a
    DDNAME of TAPE..., as MXG's MONTHBLD does to eliminate tape mounts).
    The job fails with "VARIABLES NOT FOUND" error, then 0C4 ABENDs.
    The ZAP corrects the error, but a circumvention which allowed you to
    read the dataset was to specify "LIBNAME TAPE V5SEQ;" and use the
    DDNAME of TAPE to point to the disk dataset in tape format.  As an
    aside, specifying "LIBNAME TAPETEMP TAPE;" (used in MONTHBLD for
    SAS 6.06 compatibility) causes the disk dataset in tape format to
    be created with a BLKSIZE of 32760, which requires more disk space
    than does half-track blocksize.  Unfortunately, it does not appear
    possible to change this blocksize, but this has only minor impact,
    since TAPETEMP is only temporary SYSDA space.

    There are still occasional 6.06 ABENDs in WORK dataset processing.
    Three additional SAS ZAPs on their OCTOBER 1991 SAS USAGE NOTES tape
    seem to have corrected most remaining problems.  The critical zaps
    are Z6063169, Z6063214, and Z6063409.   One site experienced without
    these zaps reported its strange ABENDs went away when BUFNO=2 was
    changed to BUFNO=3 on their WORK DD!


 7. The following important notes are repeated from prior Newsletters:


 a. SAS OPTIONS REQUIRED under version 5.18, 6.06, or 6.07.

    Please read this section carefully.  MXG execution will fail if you
    do not pay attention to these (potentially incompatible) changes:

    SAS options that are MANDATORY with all SAS Versions:

      NOIMPLMAC MAUTOSOURCE SASAUTOS=SOURCLIB ERRORABEND MACRO DQUOTE

        NOIMPLMAC should ALWAYS be used in ANY program.
        MAUTOSOURCE and SASAUTOS=SOURCLIB are required by MXG to
         resolve %MACRO references without extra I/O by using autocall.
        ERRORABEND ensures SAS stops on any error condition.
        MACRO enables SAS to recognize %MACROs.
        DQUOTE is needed to extract values of certain string %MACROs.

    SAS options MANDATORY under SAS Version 5.18 (do not exist in V6):

      MWORK=28000 GEN=0

        MWORK was needed in large %MACROs (like %ANALDB2R).
        GEN=0 was needed to eliminate unnecessary I/O and CPU time, and
        is discussed in the 1984 Guide (see Index).

    SAS options MANDATORY under SAS Version 6 (did not exist in 5.18):

      MEMSIZE=24M

        Previously, MXG recommended MEMSIZE=12M, but programs that build
        many datasets concurrently (like BUILDPDB, VMACVMXA, etc.) will
        need more of this virtual storage above the line, because of the
        new MXG recommended value for BLKSIZE='half-track'. The MEMSIZE
        option only works under MVS/XA and MVS/ESA, and since it is not
        a real resource, and only used when needed during the "building"
        phase in MXG processing, the new default of MEMSIZE=24M should
        not cause any problem, and will avoid unnecessary ABENDs.
        If you are using MXG and SAS 6.06 under MVS/370 or CMS/370, you
        will have to reduce this MEMSIZE= parameter to no more than 6M,
        and must reduce the BLKSIZE (try 4096, or the minimum 1024).
        Small BLKSIZE will allow your program to compile, but the DASD
        work space you will need will significantly increase, as will
        the run-time, IOs, and CPU requirements for the same job.

    SAS options STRONGLY RECOMMENDED for SAS 6.06 performance:

      BLKSIZE=23040 BUFNO=2   -- for 3380's
      BLKSIZE=27648 BUFNO=2   -- for 3390's

      Both are now automatically set by MXG's use of BLKSIZE(DASD)=HALF
      in MXG's CONFIG/CONFIG07 members for permanent datasets, but
      note that the WORK DD in the default SAS JCL procedure contains
      a BLKSIZE=6144 parameter which MUST be overridden or changed for
      optimum execution performance:

           //    EXEC MXGSASV9
           //WORK DD DCB=BLKSIZE=23040

      The BLKSIZE option in the CONFIG member will have no effect if a
      DCB=BLKSIZE value is specified on the JCL DD statement.

      See "SAS Benchmarks" in Newsletter TWENTY for resource savings.


    SAS options recommended with either SAS Version 5.18, 6.06 or 6.07:

        FIRSTOBS=1 OBS=MAX
        ERRORS=2
        NOSOURCE NOSOURCE2 NOMACROGEN NOMPRINT NOMLOGIC

    So how do you specify these recommended/required MXG options?

    In Version 5.18, MACRO and MWORK=28000 must be specified on the EXEC
    statement, but all other options could be specified on an OPTIONS
    statement right after your SYSIN DD * statement.  However, so you do
    not have to remember them nor type them, MXG member SASOPTV5 has all
    of the recommended options in an OPTIONS statement, so you need only
    %INCLUDE SOURCLIB(SASOPTV5);  as your first SAS statement:

         //stepname EXEC SAS518,OPTIONS='MACRO MWORK=28000'
         //SYSIN     DD *
            %INCLUDE SOURCLIB(SASOPTV5);
             ... the rest of your program ...

    For SAS Version 6, options can be set with an OPTIONS statement, or
    with the OPTIONS= JCL parameter, or (as is MXG's recommendation) via
    the CONFIG= JCL parameter on the EXEC statement.  MXG member CONFIG
    contains the MXG required and recommended options for SAS 6.06, and
    member CONFIG07 contains the SAS 6.07 recommendations.  The BLKSIZE
    and MEMSIZE options were increased in MXG 9.9, and the new CONFIG07
    member was added with new SAS 6.07 options.  (You could also supply
    options by overriding the CONFIG DD in the SAS JCL procedure, but
    using the CONFIG= parameter is safer and simpler.).

         // EXEC SAS606,TIME=10,
         //            CONFIG='MXG.SOURCLIB(CONFIG)'


         // EXEC SAS607,TIME=10,
         //            CONFIG='MXG.SOURCLIB(CONFIG07)'
    IF YOU DON'T HAVE THE RIGHT OPTIONS IN EFFECT, YOU WILL RECEIVE
    RUDE AND INSULTING SAS ERROR MESSAGES, INCLUDING 180 ERRORssss!


 b. Format libraries are different in MVS SAS Version 6 and Version 5.

    The MXG-built "SASLIB" formats are built by the first step of either
    JCLTEST (for SAS 5.18) or JCLTEST6 (for SAS 6.06).

    Under SAS Version 5.18, formats are members of a PDS load library
    which must be allocated as SPACE=(CYL,(3,1,99)).  SAS 5.18 formats
    are always referenced using the DDNAME of SASLIB.

    Under SAS Version 6 formats are members of a SAS data library, which
    must be allocated as SPACE=(CYL,(1,1)). Note there is NO third SPACE
    parameter (for PDS directory blocks), because data libraries in SAS
    Version 6 are physical sequential files.  SAS Version 6 format
    libraries are always referenced using the DDNAME of LIBRARY.

    In either version of SAS, the blocksize is set by the PROC FORMAT.

    MXG always requires the appropriate DDNAME (SASLIB or LIBRARY).

    You will fail with SAS 170 FORMAT NOT FOUND errors if you do not
    have the correct format library pointed to by the correct DDNAME.

VI.   Installation Instructions for MXG Version 9.9.

    Over 800 sites have installed a PreRelease of Version 9, with almost
    no reported problems.  Sites migrating from MXG Version 8.8 or later
    have found installation of MXG 9.9 was smooth and easy.  The only
    known incompatibilities are listed below, before the instructions.

    Under ALL SAS Versions:

    BUILDPDB/3 sites who have added DB2 processing to their PDB must now
    "back-out" their exit code as described in Change 9.175; MXG now has
    added DB2ACCT/DB2STAT0-1 datasets automatically to your PDB, and
    a syntax error in BUILDPDB will occur if you fail to heed this note.

    Only under SAS Version 6.07:

    Use new member CONFIG07 instead of CONFIG.  No error will occur, but
    several unnecessary WARNING messages will be eliminated by use of
    the new CONFIG07 member for 6.07.

    Only under SAS Version 5.18:

    BUILDPDB/3 under SAS 5.18 ONLY (not required with SAS 6.06/SAS 6.07)
    sites must add a new temporary DD card in their JCL for BUILDPDB:
       //SMFTEMP  DD UNIT=SYSDA,SPACE=(CYL,(20,20))
    This inconvenience may help eliminate SAS 5.18 compiler 344 errors.
    If you encounter SAS 5.18 errors 344 or 160 see Change 9.175.
    A syntax error in BUILDPDB will occur if you fail to heed this note.


    However, if you have NOT installed MXG 8.8, you MUST note:

    a. See SAS Notes section of this newsletter.  The SAS options that
       are required by MXG were changed between MXG 7.7 and MXG 8.8.
    b. Execution under SAS 6.06 is different than under SAS 5.18. See
       SAS Notes section of newsletters 17-21.
    e. To write your PDB directly to tape, IMACCICS must be changed as
       described in comments in the member.  Although MXG does support
       creation of the PDB directly to tape, most sites find it better
       (especially elapsed time) to create the PDB on temporary disk and
       then use PROC COPY to copy from disk to tape.  (BUILDPDB re-reads
       PDB datasets to build RMFINTRV, and this can cause lots of tape
       spinning when the PDB DDname points directly to tape.)

Always read comments in the CHANGES member for compatibility issues, as
well as for any last minute changes added after Newsletter composition.

 1. Installation, re-installation, and Space Requirements.

The MXG Installation instructions are found in Chapter 32 of the MXG
Supplement for both new installation and for version replacement, and
those instructions, as modified herein, are still valid.

The MXG tape is distributed as a Non-Labelled (NL) tape containing a
single file with DCB=RECFM=FB,LRECL=80,BLKSIZE=32720.  The MXG tape is
an unloaded Partitioned Dataset in IEBUPDTE format.  Note that the tape
blocksize was changed to 32720 (it had been 6160 in prior versions). You
will receive I/O errors if you specify the incorrect blocksize.

Under MVS use IEBUPDTE utility to build the MXG.SOURCLIB PDS library.
Under CMS use TAPPDS   command to build the SOURCLIB MACLIB library.

Allocate the MXG.SOURCLIB for MXG 9.9 with SPACE=(CYL,(50,1,299)), using
  DCB=(RECFM=FB,LRECL=80,BLKSIZE=23440) on 3380 devices, or
  DCB=(RECFM=FB,LRECL=80,BLKSIZE=27600) on 3390 devices.

Under CMS, approximately the same space (50 cylinders) will ultimately
be required by the MXG SOURCLIB MACLIB, but during the CMS installation
process you will need at least 100 free cylinders on your minidisk.

MXG is tailored and extended by "Installation Macro" members (members
beginning with IMAC....), and by "MXG Exit Facility" members (members
beginning with EX....) that are copied and edited into the installation
"USERID.SOURCLIB", the name of the "MXG Tailoring" library, that you
create and concatenate ahead of MXG.SOURCLIB to the SOURCLIB DDNAME:

  //SOURCLIB DD DSN=USERID.SOURCLIB,DISP=SHR --> site tailoring (yours)
  //         DD DSN=MXG.SOURCLIB,DISP=SHR    --> never changed  (mine)

If this is an MXG re-install, there should already be a USERID.SOURCLIB.
If not, then allocate one using the same attributes as the MXG.SOURCLIB,
with SPACE=(CYL,(1,1,99)).  Under CMS create an equivalent MACLIB.

Tailor by editing members that you copy from my library to your library.

IMAC.... members are self-documenting, and member IMACAAAA indexes all
IMAC members.  Most MXG sites have only a few tailoring members in their
USERID.SOURCLIB (typically, IMACACCT, IMACSHFT, IMACWORK).

VMAC.... members contain the actual processing code, and normally should
not exist in your USERID.SOURCLIB, and should always be removed when you
install a new version of MXG.  However, if you have installed printed
changes from an MXG Newsletter, you might have copied VMAC member(s)
from MXG.SOURCLIB into your site's USERID.SOURCLIB and then modified the
VMAC member.  (Alternatively, you could have created an MXG.CHANGLIB in
which you put those in-between-version changes.)  In either case, if
you made temporary changes, they must be removed now.  Delete all of the
VMACs members from your USERID.SOURCLIB (or delete the MXG.CHANGLIB).
Otherwise, your modified VMAC member would be used instead of MXG's.

You should record all tailoring changes in your USERID.SOURCLIB so the
next MXG technician will know what you have done.  You should create a
member named CHANGES in your USERID.SOURCLIB, similar to member CHANGES
in the MXG.SOURCLIB which documents all MXG changes.

If there are IMAC.... members in your USERID.SOURCLIB, you must look at
the alphabetic list of changed IMACs in the Change Log, below, and must
retrofit your tailoring on the new member in this library.  In MXG 9.9,
only IMACACCT was changed (Change 8.290, in member CHANGES).

Whenever you install changes or test a new version of MXG (or even your
own reports), be extra careful to look on the SAS log for any real error
conditions. Search for all occurrences of "ERROR:" and  "ERROR :"  and
"UNINITIALIZED" and "NOT CATLGD", as they may indicate a serious error.

A PROC PRINT and a PROC MEANS of each new MXG-built SAS dataset can help
you to understand their contents, and should be used to examine any
unusually large, negative, or suspicious values.  Print all variables in
the dataset, and read the variable's descriptions in Chapter FORTY.



 Summary of critical actions to be taken in installing new version:

     a. All VMAC.... members in your USERID.SOURCLIB must be examined
        and, in general, must be deleted.

     b. All IMAC.... members in your USERID.SOURCLIB must be compared
        with the IMAC.... members that have been changed in this MXG
        version (see alphabetic list at beginning of Change Log).  You
        you MUST start with the IMAC in this version and retrofit your
        installation's tailoring. Member IMACAAAA indexes all IMAC's.

     c. It is always wisest to PROC PRINT the first 50 observations of
        important datasets, especially PDB.JOBS, which can be affected
        by user tailoring in IMACPDB. A visual scan of that PROC PRINT
        serves as an excellent validation of correct installation, and
        will almost always detect any serious problems BEFORE you begin
        your production MXG runs!  See also the MXG utility UTILPRAL.


VII.  Documentation of MXG Software.


Member CHANGES always contains the version number of MXG Software, and
it lists changes that were installed in that version.  The members named
CHANGEnn have the contents of CHANGES when that "nn" MXG version was
created.  Description of enhancements will be found in the text of the
Change description that made the enhancement (in those CHANGES and
CHANGEnn members).  The CHANGE  members can be scanned online (with SPF
BROWSE) to search for specific product name references (CICS, MVS/ESA,
etc.).  The text of each Change identifies the member(s) that were added
or altered by that change. Documentation (especially for new product's
support) is usually also found in comments at the beginning of those
members listed in the change entry.

Member NEWSLTRS contains the text of all newsletters (up through the
newsletter that accompanied that MXG release). You can search NEWSLTRS
for product name or acronym to find the technical notes, APARs, etc.
from all MXG newsletters.  (The Change Log of each Newsletter is not
replicated in member NEWSLTRS, since that text will be in CHANGES).

Member DOCVERnn is the "delta-documentation" (in abbreviated Chapter
FORTY style) of only those variables and datasets that were changed
between successive MXG Versions. There is a DOCVERnn "delta" member in
the MXG library for each version.

Penultimately, member DOCVER contains abbreviated Chapter FORTY format
that documents all of the variables names in all of the MXG datasets
that are created by that MXG Software Version (alphabetically by data
set name and variable name).

Finally, MXG is a source distributed system, so you can often find your
answer by BROWSE/EDIT of the source member, especially the VMACs that
actually create the dataset, or ANALs that analyze the MXG datasets.
In many instance, the MXG Variable name is the IBM or Vendor's field or
DSECT field name. In other cases, the DSECT field name is carried as a
comment beside in the MXG INPUT statement to map field name to MXG's
variable name.  MXG expects you to also have access to the vendor's
documentation of particular data records you are using for analysis.

VIII. Change Log

--------------------------Changes Log---------------------------------

 You MUST read each Change description to determine if a Change will
 impact your site. All changes have been made in this MXG Library.

 Member CHANGES of the MXG SOURCLIB will always be more accurate than
 the printed changes in a Newsletter, because the software is created
 after the newsletter is sent to the printer!

 Member CHANGES always identifies the actual version and release of
 MXG Software that is contained in that library.

 The actual code implementation of some changes in MXG SOURCLIB may be
 different that described in the change text (which might have printed
 only the easily installed, critical part of the correction).

 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.

 Changes thru 9.229  are contained in MXG Version    9.9  Mar  1, 1992.
 Changes thru 9.218 were contained in MXG PreRelease 9.8  Feb  3, 1992.
 Changes thru 9.212 were contained in MXG PreRelease 9.7  Jan 27, 1992.
 Changes thru 9.205 were contained in MXG PreRelease 9.6  Jan 14, 1992.
 Changes thru 9.184 were contained in MXG PreRelease 9.5  Dec  1, 1991.
 Changes thru 9.175 were contained in MXG PreRelease 9.4  Nov 15, 1991.
 Changes thru 9.107 were contained in MXG PreRelease 9.3, Aug  1, 1991.
 Changes thru 9.104 were printed in NEWSLETTER TWENTY     Aug  1, 1991.
 Changes thru 9.069 were contained in MXG PreRelease 9.2, July 1, 1991.
 Changes thru 9.038 were contained in MXG PreRelease 9.1, June 3, 1991.
 Changes thru 8.305 were contained in MXG Production 8.9, May  1, 1991.
 Changes thru 8.285 were contained in MXG Production 8.8, Apr  8, 1991.
 Changes thru 8.283 were printed in NEWSLETTER NINETEEN,  Apr  8, 1991.

Alphabetic INDEX of significant changes in MXG 9.9 (after MXG 8.8):

  Member    Change   Description

  many      9.151  DASD Device 3345 ("Serpentine") data recognized.
  many      9.152  Tape Device 3490E ("Serpentine") data recognized.
  ANALACHE  8.293  Cache RMF Reporter analysis uses 3990 records now.
  ANALDBTR  9.135  DATASET S064058 NOT SORTED error corrected.
  ANALDB2R  8.299  Variable Not Found if only Acct Trace Long requested.
  ANALDB2R  9.030  DB2 Reports have incorrect values for some fields.
  ANALDB2R  9.032  DB2 Audit Reports not created if PDB=SMF specified.
  ANALDB2R  9.104  DB2 Trace TRANSIT report causes DATA IS NOT SORTED.
  ANALDB2R  9.210  DB2PM-like SQL trace reports added.
  ANALRACF  9.064  RACF Analysis of OPERATOR,SPECIAL activity.
  ANALTMS   9.059  PROC SUMMARY out of memory condition.
  ANALVVDS  9.031  PERM should be changed to MXGVVDS.
  ANALVVDS  9.053  MXG 9.1 only, VMXGVVDS should have been MXGVVDS.
  APAR/PTF  9.141  OY33312/UY52529 has no impact on MXG processing
  ASUMDBDS  9.012  TMON/CICS trending fails with Release 7 data.
  ASUMJOBS  8.291  EXCPTOTL, IOTMTOTL were not kept in BATCHJOB.
  ASUM70PR  9.091  TYPE70PR data summarized into PDB.ASUM70PR
  ASUM70PR  9.179  ASUM70PR data wrong if NRPRCS not equal to PARTNCPU.
  AS400PDS  8.286  AS400PDS contains no records.

  BLKSIZE   9.109  MXG distribution tape block size changed to 32720.
  BUILDPDB  9.049  SAS 6.06 and MXG 8.8 under MVS/370 options.
  BUILDPDB  9.095  Dataset TYPE0203 added to default datasets built
  BUILDPDB  9.175  DB2ACCT,STAT0/1 automatically created by BUILDPDB.
  CASORT66  8.295  SAS datasets destroyed by CASORT release 6.6.
  CHANGE08  9.073  Example to create _DAY in 8.213 was wrong
  CONFIG    9.022  Option VERSIONLONG specified to display SAS version.
  CONFIG    9.131  Default CONFIG for 6.06 updated.
  CONFIG07  9.131  Default CONFIG for 6.07 updated.
  DIFFDB2   9.080  Not all DB2STAT0/1 variables were deaccumulated
  DIFFDB2   9.128  DB2STAT0/1 variables improperly deaccumulated.
  EXPDB304  9.034  BUILDPDB/3 steps data creation exit.
  EXPDB6    9.034  BUILDPDB/3 steps data creation exit.
  EXTY72    9.184  CPURCTTM invalid in TYPE72, not included in CPUTM.
  IEBUPDTE  8.286  Unload of MXG 8.8 set condition code 4.
  IMACACCT  8.290  ACCOUNT FIELD n LENGTH WRONG corrected.
  IMACCICS  9.005  PDB cannot be built on tape unless IMACCICS changed.
  IMACDB2   9.121  DB2 Correlation ID decoding corrected.
  IMACEXCL  9.051  Support for CICS type 110 EXCLUDE statement.
  IMACEXCL  9.145  CICS EXCLUDE/INCLUDE logic externalized
  IMACFMTS  9.066  New IMAC for user formats for SAS 6.06.
  IMACICDA  9.146  CICS EMP data control externalized
  IMACICDB  9.181  Support for APAR PL83370 in DBCTL data with CICS/ESA
  IMACICOx  9.146  Omegamon V550 User EMPs added to type 110
  IMACKEEP  9.017  A better way to drop MXG variables not using IMACKEEP
  JCLDASD   9.031  MXGDASD,PERM DDNAMEs should be DISK,MXGDASD
  JCLMNTH   9.225  MONTHBLD require only one tape drive, runs faster!
  JCLTEST6  9.108  FORMAT not found error in step SMFSMALL.
  READDB2   9.164  List processing %MACRO for DB2 IFCIDs added.
  RMFINTRV  9.184  Enhanced, MVS/ESA CPU times and PR/SM data added.
  RMFINTRV  9.204  RMF72D NOT SORTED condition corrected.
  SPUNJOBS  9.005  PDB.SPUNJOBS on tape caused 207 error.
  SPUNJOBS  9.013  SPUNJOBS timestamps not 8 bytes, truncating values.
  TLMS      9.041  TLMS causes 713-04 ABEND if DBLTIME=0.
  TRNDDB2A  8.301  DB2 Acct trending failed in 2nd week of execution.
  TRNDDB2A  9.209  DB2 Trending errors corrected.
  TRNDDB2S  8.301  DB2 Stats trending failed in 2nd week of execution.
  TRNDVMXA  9.028  VM/XA Trend Data Base implemented.
  TRNDVMXA  9.089  VM/XA Trended PFXUTIME and PCTCPUBY incorrectly
  TRND70PR  9.091  TYPE70PR data creates new TREND.TRND70PR
  TRND70PR  9.179  TRND70PR data wrong if NRPRCS not equal to PARTNCPU.
  TRND71    9.092  TYPE71 data creates new TREND.TRND71
  TRND72    9.093  MVS/ESA 4.2 variables added to TREND.TRND72
  TYPEAPAF  9.218  Support for Amdahl's APAF.
  TYPECIMS  9.122  IMF Chained Transactions response time corrected.
  TYPECIMS  9.235  Support for IMF 1.7 log records.
  TYPEIMS   9.106  IMS Multi-trans resources wrong.
  TYPEIMS   9.182  Multi-trans corrections, CONDCODE no longer blank.
  TYPEIMS   9.216  IMS 3.1 resources wrong for Quick Reschedule trans.
  TYPEMON8  9.011  TMON/CICS Release 9.0 supported via conversion only.
  TYPEMON8  9.015  TMON/CICS Version 8 History file cause MXG failure.
  TYPEMON8  9.168  STOPOVER with bad record in Landmarks Monitor
  TYPEPDL   8.297  Fujitsu FACOM MSP and FSP support replaced XPDLPDA.
  TYPE84    9.202  JES3 JMF type 84 SMF record partial support.
  UTILCICS  9.019  Not Sorted error corrected for CICS/ESA dictionary.
  VDOCACHE  9.027  Documentation re-write has begun.
  VMACACF2  8.289  ACF 5.2 new variables not kept.
  VMACACF2  9.086  ACF2 REC=L CN=3 records were not output
  VMACACHE  8.293  Cache RMF Reporter support enhanced and decoded.
  VMACAIM2  8.298  Fujitsu AIM database manager records corrected.
  VMACCADM  9.021  Support for CADAM's Statistics Data File.

  VMACCCC   9.172  Softtool Corporation's CCC (Change Control) user SMF
  VMACCMA   9.143  Support for CMA-SPOOL user SMF record
  VMACCMF   9.126  CMF User SMF record STOPOVER corrected.
  VMACCTLD  9.038  Support for 4th Dimension Sofware's CONTROL-D record.
  VMACDB2   9.138  Support for DB2 2.3.0
  VMACDCOL  8.285  IBM DASD measures use MB for million, not megabytes.
  VMACDCOL  9.144  DCOLLECT values incorrect after IBM APAR OY36364
  VMACDCOL  9.157  DCOLLECT variables changed from character to numeric
  VMACDCOL  9.180  Capacity values off by 120 bytes.
  VMACDMON  9.196  Support for ASTEC 1.5.
  VMACEPIL  8.284  Support for EPILOG/CICS 451 added, and enhanced.
  VMACEPIL  8.287  Invalid member on MXG 8.8 replaced.
  VMACFOCU  9.223  Support for Information Builder's FOCUS MSO SMF.
  VMACFTP   9.056  Support for NetView FTP User SMF record.
  VMACFTP   9.170  FTP records produce no observations
  VMACHSM   9.097  Support for HSM 2.6 SMF record
  VMACILKA  9.020  Support for Interlink's SNS/TCPaccess SMF record.
  VMACILKG  9.020  Support for Interlink's SNS/SNA Gateway SMF record.
  VMACILKV  9.020  Support for Interlink's SNS/TCPvt  SMF record.
  VMACIMS   9.063  TYPEIMS Input Queue time correction.
  VMACLMS   9.229  Support for Memorex Telex LMS/PM SMF record.
  VMACMIM   9.173  LEGENT's Multi-Image Manager (MIM) user SMF record
  VMACMIM   9.173  Support for LEGENT's Multi-Image Manager MIM record.
  VMACNETP  9.116  NPM 1.4.1 support was not complete in MXG 9.3.
  VMACNETP  9.118  Support for NET-PASS user SMF record.
  VMACNSM   9.194  Support for NOMAD's Session Manager record.
  VMACNSPY  9.033  STOPOVER protection for invalid records.
  VMACNSPY  9.044  STOPOVER with NETSPY Accounting record.
  VMACNSPY  9.045  NETSPY Accounting subtype caused STOPOVER.
  VMACNSPY  9.165  LEGENT's LANSPY component of NETSPY additions.
  VMACOMCI  9.147  Omegamon V550 User SMF record
  VMACOPCA  9.224  IBM's OPC/A Job Tracking and Audit Trail Log.
  VMACRMDS  9.139  RMDS records RMDSORG='D' STOPOVER corrected.
  VMACSMF   9.094  New message at end of SMF processing on log
  VMACSNAP  9.167  Codework Software's SNAPAD-MVS user SMF record
  VMACSPMS  9.088  Support for Amdahl's SPMS Release 1.2 SMF record
  VMACTAO   9.018  Support for Fischer's Totally Automated Office TAO.
  VMACTAO   9.200  Support for Emc2/TAO Release 3.3.0.
  VMACTMS5  9.016  Support for CA-1 (TMS) Release 5 complete rewrite.
  VMACTMS5  9.057  Missing semicolons.
  VMACTMVS  9.142  TMON/MVS spanned record STOPOVER circumvented
  VMACUCB   9.002  3490E cartridge tape now recognized.
  VMACVMXA  8.296  VM/XA used more work space than really required.
  VMACVMXA  9.096  LOGICAL RECORD SPANS message corrected
  VMAC102   9.178  IBM incompatible change to IFCID 140, 141 in 2.3
  VMAC110   8.292  Unexpected Statistics Subtype due to Boole CICSMGR.
  VMAC110   9.051  Support for Shared Medical Systems CICS modifications
  VMAC110   9.062  Support for CICS/ESA 3.2.1.
  VMAC110   9.084  CICS PCLOADCN has different meaning.
  VMAC23    9.134  New fields were not input.
  VMAC28    9.061  Support for NetView Performance Monitor NPM 1.4.1.
  VMAC28    9.214  Support for NPM Release 1.5.
  VMAC30    9.001  INVALID DATA FOR SMF30ASO with MVS/ESA 4.2 eliminated
  VMAC30    9.085  STCs starting with A confused APPC logic.
  VMAC30    9.134  Support for MVS/ESA 4.2.2.
  VMAC42    9.048  Circumvention of IBM DFP 3990 Cache type 42 errors.
  VMAC57    9.010  Invalid ESS Section message due to IBM error.
  VMAC6     9.083  OUTDEVCE changes affect PRINTLNE, EXTWTRLN
  VMAC6     9.154  LEGENT's Bundle product caused type 6 stopover
  VMAC6156  9.046  TYPE6156 variables ACTION, FUNCTION not valid.
  VMAC7072  9.001  INVALID DATA FOR IOCRFC with MVS/ESA 4.2 eliminated.

  VMAC7072  9.054  MXG 9.1 only, Change 9.001 incompletely installed.
  VMAC7072  9.070  TYPE72 CPUHPTTM,CPUIIPTM,CPURCTTM wrong in MVS 4.2
  VMAC7072  9.072  TYPE70PR LCPUADDRs 2 and 3 wrong if DEDICATED CPU
  VMAC7072  9.119  ACF2 STOPOVER due to bad record length corrected.
  VMAC7072  9.120  ESA CPU times HPT/IIP/RCT wrong by 2%.
  VMAC73    9.001  INVALID DATA FOR IODFDATE in MVS/ESA 4.2 eliminated.
  VMAC74    9.001  First STOPOVER with MVS/ESA 4.2 data corrected.
  VMAC74    9.039  Second STOPOVER with MVS/ESA 4.2 data corrected.
  VMAC78    9.055  STOPOVER with MVS/ESA 4.2 data corrected.
  VMAC78CU  9.047  Missing fields due to IBM microcode errors.
  VMAC79    9.007  Support for (archaic?) RMF 3.5.1 type 79 records.
  VMAC90    9.134  Support for MVS/ESA 4.2.2 added new subtypes.
  VMXGHSM   9.009  HSM MCD data can cause STOPOVER.
  VMXGVPD   9.158  STOPOVER with VPD record type "E".
  VMXGVTOC  9.159  VTOC data beyond 3rd extent lost since MXG 7.2.
  VMXGVTOF  9.035  SAS 5.18 only, did not read all extents.
  VMXGVTOF  9.040  First Extent on each volume lost.      .
  VMXGVTOF  9.159  VTOC data beyond 3rd extent lost since MXG 7.2.
  WEEKBLD   9.050  Submitting job may need DCB on INTRDR DDNAME.
  XMAC74    9.054  MXG 9.1 only, Change 9.001 incompletely installed

Inverse chronological list of all Changes:

  Note that the newsletter went to the printer on Feb 14.  There may
  well be additional changes before the tapes are built the weekend
  of February 23.  Please read member CHANGES of the MXG 9.9 library
  to see if any additional enhancements or changes were made while
  the newsletter was at the printer.

  Changes 9.235-9.105 were printed here in Newsletter TWENTY-ONE

  See member CHANGE09 for actual change text.

End of Changes Log in Newsletter TWENTY-ONE.
****************NEWSLETTER TWENTY***************************************








              MXG NEWSLETTER NUMBER TWENTY August 1, 1991



Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE



                         TABLE OF CONTENTS

                                                                    page
I.  MXG Version Status.

 1. Production Version is still MXG 8.8, dated April 8, 1991.          1
 2. Announcement of PreRelease MXG 9.3, dated August 1, 1991.          1

II. MVS Technical Notes

 1. VLF Type 41 APAR UY58027.
 2. PR/SM LPAR Effective Dispatch APAR OY36668 PTF UY61907             4
 3. Type 30 Interval Records for Early Address Spaces (JES2, CATLG)    4
 4. CPITCBTM/CPISRBTM measure end of step CPU times, not "initiation". 4
 5. DSSIZHWM is only contained in type 30 subtype 4, and is not reset. 4
 6. MVS/XA APAR OY31613 caused 0 observations in PDB.STEPS, TYPE30_4.  4
 7. Amdahl MDF Level 3 populates TYPE70PR observations.                5
 8. Media Manager captures I/O for DFP 3.3.0 functions.                5
 9. SMF-related APARS for types 6, 30, 41, 42, 78 SMF record's data.   5
10. Impact of SMFPRM default DDCONS(YES).                              5

III. SAS Technical Notes.

 1. SAS 6.06 has been repaired, and should now be installed and used.  6
 2. SAS OPTIONS REQUIRED by MXG 8.8-9.3 for SAS versions 5.18 or 6.06. 6
 3. Format library differences between MVS SAS 6.06-5.18.              8
 4. MXG-under-CMS/SAS Installation and Execution Considerations.       8
 5. SAS 6.06 "Data Set is Not Sorted" errors now fixed.                9
 6. SAS 6.06 "VARIABLE VOLSER NOT FOUND" error now fixed.              9
 7. SAS 6.06 0C4 ABENDs with SMS-managed datasets.                     9
 8. SAS 6.06 180-322 ERROR if CONFIG= is not specified.                9
 9. SAS 6.06 013-14 ABEND if DCB does not contain RECFM=FS.           10
10. SAS 6.06 VERSIONLONG option identifies maintenance library level. 10
11. SAS 6.06 Physical I/O Errors with UNKNOWN caused now fixed.       10
12. SAS ABENDs with SAS ERROR: CPU TIME EXCEEDED.                     10
13. Protection of SAS date decoding for the next millennium.          11
14. Benchmarks of SAS 5.18, 6.06, and Experimental 6.07.              11

IV. Documentation of MXG Software.                                    13
V. MXG Version 9.3 Installation, Space, Compatibility, etc.           14

VI. Change Log - Changes 8.248-8.305, 9.001-9.104                  16-48

         COPYRIGHT (C) 1991 BY MERRILL CONSULTANTS DALLAS TEXAS


          MXG IS A REGISTERED TRADEMARK OF MERRILL CONSULTANTS
          SAS IS A REGISTERED TRADEMARK OF SAS INSTITUTE

I.  MXG Version Status.

 1. Production Version is still MXG 8.8, dated April 8, 1991.

    No MXG Software is shipped with this Newsletter.

    The Production Version (i.e., the version that was shipped to all
    sites) is still MXG 8.8.  We do not plan a new Production Version
    until 1992.

    MXG PreReleases are made available between Production Versions to
    either fix critical problems or to offer support for new products
    or other enhancements. PreReleases are ONLY sent upon request.

    Most MXG sites will not need to replace their MXG 8.8 Software,
    but critical errors in these products have been found and fixed:

      MVS/ESA 4.2 sites need MXG 9.2 plus Change 9.040 or MXG 9.3.
      VMXGVTOF sites need MXG 9.1 or later.
      VMACEPIL sites need MXG 8.9 or later.

    All sites must review the alphabetical list of critical changes,
    below, in the Change Log to determine if any of the other changes
    or enhancements affect their site.

    MXG 8.8 was shipped to all sites April 8, 1991.  Member VMACEPIL
    was overlaid by member CHANGES, and Replacement MXG 8.9 dated May
    1, 1991 was created.  MXG PreRelease 9.1 became available June 1,
    with additional changes and enhancements.  MXG PreRelease 9.2 was
    built July 1, 1991.

 2. Announcement of PreRelease MXG 9.3, dated August 1, 1991.

    You can now request (phone, fax, or via your local SAS Office) your
    copy of MXG PreRelease 9.3, dated August 1, 1991, which not only
    corrects all know problems, but also contains these enhancements,
    which are described further in the Change Log, below.

        Support for Amdahl's SPMS Release 1.2 SMF record.
        Support for 4th Dimension's CONTROL-D SMF record.
        Support for CA-1 (TMS) Release 5 complete rewrite.
        Support for CADAM's Statistics Data File.
        Support for CICS/ESA 3.2.1 product.
        Support for EPILOG/CICS thru 451 added, and enhanced.
        Support for Fischer's Totally Automated Office TAO.
        Support for HSM 2.6 SMF record.
        Support for Interlink's SNS/SNA Gateway SMF record.
        Support for Interlink's SNS/TCPaccess SMF record.
        Support for Interlink's SNS/TCPvt  SMF record.
        Support for MVS/ESA 4.2 type 42, 72, and 74 records validated.
        Support for NPM 4.1.1 product.
        Support for NetView FTP SMF record.
        Support for Shared Medical Systems CICS exclude logic.
        BUILDPDB exits EXPDB304 and EXPDB6 externalize tailoring.
        Cache RMF Reporter support enhanced, decoded, and documented.
        DB2 Reports incorrect values corrected.
        DB2 Audit Reports not created if PDB=SMF specified.
        DB2 Acct/Stat Trend Data Base implemented.
        Fujitsu FACOM MSP and FSP supported in XPDLPDA.
        IMS Input Queue time correction.
        TMON/CICS Release 9.0 supported via conversion only.
        VM/XA Trend Data Base implemented.
        3490E cartridge tape now recognized.

    Sites that have installed MXG 8.8 should find no compatibility
    issues in replacing 8.8 (or 8.9 - 9.2) with MXG 9.3.  However, if
    you are replacing a version of MXG earlier than 8.8 with MXG 9.3
    you must be aware of these compatibility issues and exposures:

    a. Use the installation notes for MXG 8.8, below, for MXG 9.3.
    b. The SAS OPTIONS required by MXG were changed between MXG 7.7 and
       MXG 8.8, but no new required OPTIONS were introduced in MXG 9.3.
       See Section III, "SAS Notes", below.
    c. Execution under SAS 6.06 is different than under SAS 5.18 and is
       discussed in the "SAS Notes", Newsletter NINETEEN Section IV.
    d. To create your PDB directly on tape, IMACCICS must be changed.
    e. If you have added additional SMF record processing to BUILDPDB,
       and you still execute MXG under SAS 5.18, you may encounter a
       SAS Version 5.18 Compiler Limit "344" error. BUILDPDB is larger.
       See Change 7.038 in member CHANGE07 for 344 error circumvention.

    All Changes described in the Change Log are installed in MXG 9.3.

    The MXG 9.3 library contains 1,444 members, 322,585 lines of code,
    and builds 911 datasets with 32,393 variables documented in DOCVER!

    MXG 9.3 should replace your production version MXG 8.8. We always
    ship the newest PreRelease to any new customer, because each new
    PreRelease has always been better and safer than its predecessor.

 3. MXG Software possible future (subject to change) enhancements:

    DB2 2.3 will be supported when available, late in October, 1991.
    Landmark CICS Version 9.1 will be developed later this year.
    MIM writes an SMF record that will be supported later this year.
    NETSPY LAN records will be supported later this year.
    JES3 Tape Mount Merge with TYPETMNT is a future consideration.
    Cray UNICOS is a future consideration.
    VAX/VMS Account/SPM is a distant future consideration.
    Candle's Omegamon for CICS ESA is a future consideration.
    Several companies have announced plans for VTAM monitors.
    Validation of EXPLORE/VM & AS400 support is a future consideration.

 4. IBM Announcements and their MXG support.

    IBM has made many major announcements relating to the System/390,
    the ES/9000 family, and ESCON capabilities.  The following table
    identifies announced availability dates for the IBM product, and the
    corresponding Version of MXG required to support that IBM product.

      Product Name                     Availability     MXG Version
                                       Date              Required

      MVS/370, MVS/XA (all)            long ago             8.8
      RMF 4.1.2 (for MVS/ESA 3.1.3)    Sep  7, 1990.        8.8
      RMF 4.2   (for MVS/ESA 4.1)      Oct 26, 1990.        8.8
      MVS/ESA 4.1                      Oct 26, 1990.        8.8
      MVS/ESA 4.2                      Mar 29, 1991.        9.3
      RMF 4.2.1 (for MVS/ESA 4.2)      Mar 29, 1991.        9.3
      CICS/ESA 3.1                             1990         8.8
      CICS/ESA 3.2                     Jun 28, 1991.        9.2
      DB2 2.2.0                                1990         8.8
      DB2 2.3.0                        Oct 28, 1991.        9.?
      VM/ESA  1.1.0 (370 Feature)      Oct 26, 1990.        8.8
      VM/ESA  1.1.0 (ESA Feature)      Mar 29, 1991.        8.8
      VM/ESA  1.1.1                    Dec 27, 1991.        9.?

II. MVS Technical Notes


 1. VLF Type 41 APAR UY58027.

    VLF PTF UY58027 solves problems both with the measurement of VLF
    (Type 41 record) and the performance - without the PTF the Percent
    Hit in VLF kept dropping over time.

 2. PR/SM LPAR Effective Dispatch APAR OY36668 PTF UY61907

    PR/SM LPAR Management Time PTF UY61907 now exists for the APAR
    OY36668 described in Newsletter 19.

 3. Type 30 Interval Records for Early Address Spaces (JES2, CATLG)

    Subtype 2 and 3 type 30 SMF records are not normally written for
    "Early Address Spaces" (ASIDs that are created before SMF is fully
    up, like JES2, Catalog Address Space, etc.), but the IBM Information
    APAR II04729 tells you how to ZAP one IF statement (added to fix an
    error that only happened when someone unwisely issued the SET SMF
    command before SMF initialization had completed) so that these SMF
    interval 30 records will be created.  Don't let operators issue the
    SET SMF command until SMF is up, install the ZAP, and get records!

 4. CPITCBTM/CPISRBTM measure end of step CPU times, not "initiation".

    The two "Initiator/Privileged State" CPU measures in type 30
    records, MXG variables CPITCBTM and CPISRBTM have had nothing to do
    with "Initiation" since about 1984; either MVS 1.3.3 or MVS 2.1.3
    changed their meaning, and they have since that time measured the
    TCB and SRB CPU used by a step between the "end of program execute"
    until "the end of the merge of the step's subtype 3 (last interval)
    DD statistics into the subtype 4 (the step termination) record".
    This interval usually is quite small, but before the DDCONS=NO
    option existed in SMF, these times were actually explicit measures
    of how much CPU time it took to do the DD consolidation!  The 1984
    MXG Guide showed these times to be not captured in RMF type 72 data,
    but it appears now that the two CPI times may be in TYPE72 too.
    Benchmark analysis to confirm this belief is in progress.
    Note: 24APR97.  See ADOC30 variable description for more accurate
    and up-to-date discussion of what is measured in CPITCBTM/CPISRBTM.

 5. DSSIZHWM is only contained in type 30 subtype 4, and is not reset.

    The DSSIZHWM (Data Space Size high water mark) in type 30 data is
    only contained in the subtype 4 records, and is not reset at each
    step; it reflects the highest value for the life of the job, and if
    it goes down, you won't know it from the 30's!  IBM is aware of this
    and looking into possibly changing what is put in which record.

 6. MVS/XA APAR OY31613 caused 0 observations in PDB.STEPS and TYPE30_4.

    Newsletter NINETEEN mentioned MVS/XA-only OY31613/UY56157 were in
    error and caused corruption of Job name in SMF.  It turns out that
    installation of that PTF also corrupts the subtype value, causing
    MXG to not recognize type 30 subtype 4 records which led to 0
    observations in PDB.STEPS and 0 resources in PDB.JOBS!  IBM APAR
    OY38538 which describes the PE now has a PTF, UY57938, which
    corrects their error.

 7. Amdahl MDF Level 3 populates TYPE70PR observations.

    Amdahl's MDF Level 3 changes make use of the RMF type 70 PR/SM
    sections, and sites with MDF Level 3 will now see observations in
    MXG dataset TYPE70PR.  However, Amdahl's MDF uses the WAITCOMP=YES
    design (albeit with much smaller timeslices than IBM's
    implementation), and this causes the LCPUPDTM Partition Dispatch
    duration under MDF to be quite different than under PR/SM.  The
    LCPUPDTM under MDF is the total time the domain was dispatched,
    including idle time, and thus it CANNOT be used to measure processor
    utilization under MDF.  It is useable only to compare the domain
    dispatch time to their MDF targets.  To measure capacity (processor
    utilization) under MDF, you must use the data from each domain
    (e.g., TYPE70 for MVS domains, VMXAINTV for VM/XA); there is no
    central source for capacity measurement when WAITCOMP=YES is
    specified, since the dispatch time measurement says nothing about
    how much of that time was actually being used by the engines. Amdahl
    Memorandum 4610-034-91 by Douglas A. Smucker provides more details
    on how to intrepret RMF data under MDF, and is very well written.

 8. Media Manager captures I/O for DFP 3.3.0 functions.

    A major problem in current MVS measurement is the absence of I/O
    counts (EXCPs or SSCH) if the "Media Manager" is involved; there was
    earlier cited an IBM note in which it was explicitly stated that
    counts were not kept because the Media Manager was so fast it was
    not needed!  Apparently, this is changing, as DFP 3.3.0 is now
    rumored to capture Media Manager I/O for its functions, but the
    details are sketchy.  Maybe we'll get counts of DB2's I/Os through
    the Media Manager too in the future?  Stay tuned!

 9. SMF-related APARS for types 6, 30, 41, 42, 78 SMF record's data.

     OY40625 - Vector Affinity CPU times wrong
     OY36517 - Type 78 Subtype 3 truncated
     OY36035 - Type 42 Subtype 3 errors
     OY36043 - Type 42 Subtype 3 errors
     OY29986 - Type  6 JES2 3.1.3 truncated
     OY31406 - Cache RMF Reporter causes all RMF records lost
     OY34829 -   Ditto (originally mis-printed as OY34295)
     OY29801 - VLF Type 41 Subtype 3 data errors
     OY32368 -   Ditto
     OY49794 -   Ditto
     OY51970 -   Ditto
     OY36879 - Type 30 DD segments lost

10. Impact of SMFPRM default DDCONS(YES).

    The impact of DDCONS(YES) is measurable because SMFTIME timestamps
    when each record is moved (memory-to-memory) to the SMF task. One
    subtype 2 event created seven 30s at .19 .19 .19 .22 .32 .36 & .46
    TOD seconds, with 9182 DDs.  The subtype 3 event created two records
    both at TOD of 18.89 seconds, with 1929 DDs, and then processing for
    the subtype 4 took until 36.50 TOD to create the first of eight
    subtype 4 records, with the last created at 40.93 TOD. The subtype 4
    had 11,070 DDs, while there were 11,111 DDs in the 2s and 3s. The DD
    consolidation took 22 elapsed seconds (and recorded CPITCBTM of 22
    CPU seconds!) from the end of step until the step actually ended!
    And consolidation only removed 31 DD segments from the step record!
    The time to consolidate grows exponentially with the number of DDs
    to be scanned, and DDCONS(NO) was created by IBM so you could avoid
    its cost, but in keeping with IBM practices, the default value was
    left at DDCONS(YES), so you must change PARMLIB(SMFPRMxx) yourself.

III. SAS Technical Notes.


    Notes 1 thru 4 are revised from Newsletter NINETEEN, but the rest
    of these notes are new.

 1. SAS 6.06 has been repaired, and should now be installed and used.

    SAS 6.06 has been repaired, as long as you have installed at least
    the March, 1991, or later, SAS Usage Notes tape maintenance, which
    contains an IEBCOPY load library with ALL SAS ZAPs pre-applied for
    all SAS products.  SAS 6.07 will be available later this year, but
    THERE IS NO LONGER ANY REASON TO DELAY INSTALLING SAS VERSION 6.
    All MXG-critical error conditions have been fixed, and SAS 6.06 has
    eliminated the SAS 5.18 Compiler Error 344 which has plagued sites
    that have extended BUILDPDB to process additional SMF records.

        MXG NOW RECOMMENDS MIGRATION TO SAS 6.06.

 2. SAS OPTIONS REQUIRED by MXG 8.8 or later, for version 5.18 or 6.06.

    Please read this section carefully.  MXG execution will fail if you
    do not pay attention to these (potentially incompatible) changes:

    Options that are MANDATORY with either SAS Version 5.18 or 6.06:

      NOIMPLMAC MAUTOSOURCE SASAUTOS=SOURCLIB ERRORABEND MACRO DQUOTE

        IMPLMAC should never be used in ANY program.
        MAUTOSOURCE and SASAUTOS=SOURCLIB are required by MXG to
        resolve %MACRO references without extra I/O by using autocall.
        ERRORABEND ensures SAS stops on any error condition.
        MACRO enables SAS to recognize %MACROs.
        DQUOTE is needed to extract values of certain string %MACROs.

    Options MANDATORY with SAS Version 5.18 (do NOT exist in 6.06):

      MWORK=28000 GEN=0

        MWORK was needed in large %MACROs (like %ANALDB2R).
        GEN=0 was needed to eliminate unnecessary I/O and CPU time, and
        is discussed in the 1984 Guide (see Index).

    Options MANDATORY with SAS Version 6.06 (did not exist in 5.18):

      MEMSIZE=24M

        Previously, MXG recommended MEMSIZE=12M, but programs that build
        many datasets concurrently (like BUILDPDB, VMACVMXA, etc.) will
        need more of this virtual storage above the line, because of the
        new MXG recommended value for BLKSIZE='half-track'. The MEMSIZE
        option only works under MVS/XA and MVS/ESA, and since it is not
        a real resource, and only used when needed during the "building"
        phase in MXG processing, the new default of MEMSIZE=24M should
        not cause any problem, and will avoid unnecessary ABENDs.

        If you are using MXG and SAS 6.06 under MVS/370 or CMS/370, you
        will have to reduce this MEMSIZE= parameter to no more than 6M,
        and must reduce the BLKSIZE (try 4096, or the minimum 1024).
        Small BLKSIZE will allow your program to compile, but the DASD
        work space you will need will significantly increase, as will
        the run-time, IOs, and CPU requirements for the same job.
        See the SAS Benchmarks, below, for actual numbers.

    Options STRONGLY RECOMMENDED for SAS 6.06 performance:

      BLKSIZE=23040 BUFNO=2   -- for 3380's
      BLKSIZE=27648 BUFNO=2   -- for 3390's

        See "SAS Benchmarks" below to see resource savings.

        Note that the SAS Procedure supplied by SAS Institute contains
        a default value of BLKSIZE=6144 on the WORK DD statement; you
        must override that WORK DD and provide the correct BLKSIZE:

           //    EXEC MXGSASV9
           //WORK DD DCB=BLKSIZE=23040

        The BLKSIZE option in the CONFIG member cannot override if a
         DCB=BLKSIZE value was specified in the JCL.


    Options recommended with either SAS Version 5.18 or 6.06:

        FIRSTOBS=1 OBS=MAX
        ERRORS=2
        NOSOURCE NOSOURCE2 NOMACROGEN NOMPRINT NOMLOGIC


    So how do you specify these recommended/required MXG options?

    In Version 5.18, MACRO and MWORK=28000 must be specified on the EXEC
    statement, but all other options could be specified on an OPTIONS
    statement right after your SYSIN DD * statement.  However, so you do
    not have to remember them nor type them, MXG member SASOPTV5 has all
    of the recommended options in an OPTIONS statement, so you need only
    %INCLUDE SOURCLIB(SASOPTV5);  as your first SAS statement:

         //stepname EXEC SAS518,OPTIONS='MACRO MWORK=28000'
         //SYSIN     DD *
            %INCLUDE SOURCLIB(SASOPTV5);
             ... the rest of your program ...

    For SAS Version 6.06+, options can be via an OPTIONS statement, via
    the CONFIG DDNAME, or (as is MXG's recommendation), via the CONFIG=
    JCL parameter on the EXEC statement.  MXG member CONFIG contains the
    MXG-required and recommended options, and was changed in MXG 9.3 to
    increase BLKSIZE and MEMSIZE).  The CONFIG= parameter is much safer
    than the CONFIG DD statement, since overriding DDs in PROCs must be
    EXACTLY in the right order:

         // EXEC SAS606,TIME=10,
         //            CONFIG='MXG.SOURCLIB(CONFIG)'

    IF YOU DON'T HAVE THE RIGHT OPTIONS IN EFFECT, YOU WILL RECEIVE
    RUDE AND INSULTING SAS ERROR MESSAGES, INCLUDING 180 ERRORssss!


 3. Format library differences between MVS SAS 6.06-5.18.

    The MXG-built "SASLIB" formats are built by the first step of either
    JCLTEST (for SAS 5.18) or JCLTEST6 (for SAS 6.06).

    Under SAS Version 5.18, formats are members of a PDS load library
    which must be allocated as SPACE=(CYL,(3,1,99)).  SAS 5.18 formats
    are always referenced using the DDNAME of SASLIB.

    Under SAS Version 6.06, formats are members of a SAS data library,
    which must be allocated as SPACE=(CYL,(1,1)). Note there is NOT a
    third parameter in SPACE (for PDS directory blocks) because data
    libraries in SAS 6.06 are physical sequential files.  SAS 6.06
    formats are always referenced using the DDNAME of LIBRARY.

    In either version of SAS, the blocksize is set by the PROC FORMAT.

    MXG always requires the appropriate DDNAME (SASLIB or LIBRARY).

    You will fail with SAS 170 FORMAT NOT FOUND errors if you do not
    have the correct format library pointed to by the correct DDNAME.

 4. MXG-under-CMS/SAS Installation and Execution Considerations.

    a. CMS Format libraries are different.

    MXG Formats are created under SAS 6.06 by executing member FORMATS,
    which creates a SAS Catalog that is named 0FORMATS LIBRARY (yes, the
    first character is a numeric zero and the third an alphabetic
    "oh").  Since this catalog contains all of the MXG Formats, the
    installation instructions on page 120 of the MXG Supplement ("iv.
    Optionally copy TEXT into TXTLIB") no longer apply. Also the SASLIB
    SASLIB option in the example is not used to access SAS 6.06 Formats
    (although SASLIB SASLIB is still valid in SAS 6.06 to access SAS
    5.18-built formats).  As long as the 0FORMATS LIBRARY file built by
    member FORMATS is on your first disk, SAS 6.06 will automatically
    find MXG formats there.

    b. Virtual Storage requirement for MXG and SAS 6.06 with VM/370.

    Executing under VM/370, MXG needed a 10MB machine for BUILDPDB, and
    the BLKSIZE=1024 was specified to make sure it fit!  It was also
    necessary to use the NOSSEG option to disable the "SAS Saved
    Segment" so that addresses above 7MB could be use, because the SAS
    Saved segment begins at address 7MB!  The NOSSEG only applies to
    your machine, and is needed only for the big virtual memory programs
    that build lots of MXG datasets simultaneously (BUILDPDB, VMACVMXA,
    VMACVMON, etc.).  The rest of MXG needs only a 4MB machine under
    VM/370.  The BLKSIZE is set small in the REXXTES6 exec, so that the
    virtual storage required for the biggest MXG programs (BUILDPDB)
    would fit in the 10 meg I could get under VM/370, but you should
    experiment to use the largest BLKSIZE you can (and still compile the
    data step!). Small block size reduces only the virtual storage size;
    a large block size will reduce CPU time, elapsed time, I/O
    interrupts, and will actually reduce the real memory required
    (always true for sequential access).

    Executing under VM/XA, MXG was tested in a 16MB machine.

    c. CMS SAS 6.06 ZAPs required.

    SAS ZAPS Z6062068 (add) and Z6060508 (remove) appear to solve the
    only serious CMS SAS 6.06 problem. Without the zap, CMS MACLIB
    CONCAT concatenation fails, and you cannot read members from the
    second concatenation.

    CMS has also caused strange syntax errors, partial execution, etc.,
    if your SYSIN is unnumbered and you did not use SAS OPTION S=72 (to
    restrict SAS to use only the first 72 positions). Because all of
    MXG source is numbered, the REXX examples now have added S=72 as a
    default options.

    d. CMS Testing Notes.

    The REXX exec that was used for MXG testing under CMS SAS 6.06 is in
    member REXXTST6.  Before the exec is invoked, you must first issue
    the DEFINE STOR 10M command, followed by the IPL CMS command.  All
    datasets are sent to your "T" disk, a temporary disk (199 cylinders
    in the exec) that will go away at logoff, unless you use the USER=
    SAS option, or PROC COPY.

 5. SAS 6.06 "Data Set is Not Sorted" errors now fixed.

    "Data Set is Not Sorted" and other errors thought to be fixed by
    Z6062141 (which was on the March 1991 SAS Usage Notes Tape) can
    still crop up, if BUILDPDB is used with a data library that had been
    built before Z6062141 was installed.  Apparently the root problem
    not only corrupted the WORK file, causing failure, but also in some
    instances actually created a permanent SAS data set which had an
    invalid record length in it.  If you have Z6062141 installed and
    still encounter these errors, you should scratch and reallocate your
    SPIN and PDB data libraries.  The actual error occurs on a dataset
    in your WORK library, often on WORK.GOOD30_4, and the error may not
    mention SPIN or PDB names.  Scratching and reallocation your SPIN
    library means that the data for jobs which are incomplete (i.e., in
    your SPIN library) will be lost.  Additional work space errors were
    also repaired by Z6062026, available on the current SAS Usage tape.

 6. SAS 6.06 "VARIABLE VOLSER NOT FOUND" error now fixed.

    ZAPs Z6061834 or Z6062315 will cause "VARIABLE VOLSER NOT FOUND"
    with VMXGVTOC (but not VMXGVTOF) because the ZAPs are in error.
    Z6062674 corrects the error, but read Change 8.294 first.

 7. SAS 6.06 0C4 ABENDs with SMS-managed datasets.

    SAS 6.06 ABENDs with 0C4 during initialization if the datasets in
    the CONFIG concatenation are SMS-managed datasets. SAS ZAP Z6062264
    is required for SMS-managed datasets. See Change 8.294.

 8. SAS 6.06 180-322 ERROR if CONFIG= is not specified.

    SAS 6.06 ABENDs with 180-322 ERROR message if you do not have in the
    CONFIG= parameter pointing to the MXG member CONFIG.  The error text
    "Expecting Variable Here" made it sound like a syntax error in MXG
    type 110 processing!


 9. SAS 6.06 013-14 ABEND if DCB does not contain RECFM=FS.

    SAS 6.06 may ABEND with 013-14 "Error outside SAS System" when PROC
    FORMAT tries to open the LIBRARY DD, or with USER 999 error "LIBRARY
    xxx IS NOT IN A VALID FORMAT FOR ACCESS METHOD SASEB" for a data
    library, if the DDNAME being opened has only DSORG=PS specified.
    SAS detects a version 6.06 library by RECFM=FS, and if only DSORG=PS
    is found, SAS say's it's not a SAS 6.06 dataset.  Adding RECFM=FS to
    the DD statement for all SAS data libraries will circumvent either
    ABEND, but the SAS error has been fixed in SAS 6.07.  The 013-14
    failure of PROC FORMAT was precipitated by the absence of RECFM=FS,
    but enhanced by another error in FORMAT; it did not properly handle
    the return code from OPEN properly, and thought you were trying to
    open a 5.18 format library, and tried to set the DSORG to PO!
    Specifying RECFM=FS corrects both.  Why did OPEN see only DSORG=PS
    on a new dataset? Because the site was SMS-managed, and had used SMS
    to circumvent an HSM 2.5 error!  Because HSM 2.5 would not migrate a
    dataset that had not been opened, the site used SMS to always fill
    in a DSORG=PS if nothing had been specified on the DD statement,
    and the HSM error (fixed in HSM 2.6) was circumvented.  Although
    SAS will be smarter and not fail in the future when just DSORG=PS
    is found, MXG now specifies RECFM=FS in all 6.06 JCL examples.

10. SAS 6.06 VERSIONLONG option identifies maintenance library level.

    "But how do I know that my SAS installer has really installed the
    current maintenance library from SAS" can now be answered.  The SAS
    6.06 options "VERSIONLONG" will print the date of the maintenance
    library in effect, on the SAS log, right after the SAS version
    number (6.06.01.01Feb91P for example).  MXG has added VERSIONLONG to
    the default options in member CONFIG.

11. SAS 6.06 Physical I/O Errors with UNKNOWN caused now fixed.

    SAS 6.06 Physical I/O Errors with UNKNOWN cause occur with SAS multi
    volume libraries, and are fixed by Z6062241.  Read Appendix 2 of the
    SAS Companion for the MVS Environment if you need multi-volumes.

12. SAS ABENDs with SAS ERROR: CPU TIME EXCEEDED.

    ABENDs with "CPU TIME EXCEEDED" messages can occur erratically in
    either SAS 5.18 or 6.06+, if some task outside SAS issues a STIMER
    macro. SAS itself issues a STIMER to capture and record the CPU time
    of each DATA/PROC step, but a second STIMER can confuse SAS into
    thinking you have used lots of CPU time when you really didn't!  For
    some time, using FREE=CLOSE on a DD statement has been known to
    cause this ABEND.  Now there is another source of STIMER conflict.
    A site with TMS and Tape Silos found that if non-scratch tapes (to
    TMS) were put in the Silo by operations (incorrectly) as scratch
    tapes, the silo mounted the tape, but then TMS rejected the tape as
    non-scratch, caused a second silo mount, and the job then (later)
    ABENDs!  While I still don't know for sure why STIMERs are issued in
    either of these two cases, my guess is that Allocation is somehow
    involved.  In any event, the solution is to specify the SAS option
    NOSTIMER (it must be on the EXEC statement), which disables SAS
    recording of CPU times on the log and in the SAS user SMF record,
    but avoids the erratic ABEND.

13. Protection of SAS date decoding for the next millennium.

    Validation that dates into the next millennium are supported, or
    creating an algorithm for decoding all dates has begun.  This is
    an initial list of the input date formats and data functions:

    a. SMF/RMF format input with SMFSTAMP8. and RMFSTAMP8. values:

    These input formats were designed long ago to use the century bit,
    even before IBM defined the c in 'tttttttt0cyydddF'x format, and
    were properly converted in SAS 5.18. They fail (INVALID ARGUMENT)
    in SAS 6.06, but are now corrected in Experimental 6.07.

    b. DATEJUL(YYYYDDD), e.g. 1999365 or 2000001, INPUT YYYYDDD PD4.:

    The DATEJUL function properly converts values in this format.

    c. DATEJUL(0CYYDDD), e.g. 0099365 or 0100001), INPUT CYYDDD PD4.:

    The DATEJUL function does not currently support the century bit,
    but SAS has been asked to extend the function.  However, you can
    convert the 0cyyddd value to a SAS date using:
         DATE=DATEJUL(1900000+CYYDDD);
    until the DATEJUL supports the century bit.

    d. C YY DDD in separate variables.

    The correct algorithm to convert to SAS dates is:

         DATE=DATEJUL(1900000+C*100000+YY*1000+DDD);

    e. DDD and YYYY in separate variables.

    The correct algorithm to convert to SAS dates is:

         DATE=DATEJUL(YYYY*1000+DDD);

14. Benchmarks of SAS 5.18, 6.06, and Experimental 6.07.

    Test runs of MXG's JCLTEST6 stream has shown remarkable improvement.
    Whereas SAS 5.18 took 116 minutes elapsed time, SAS 6.06 reduced
    that to 91 minutes, but SAS 6.07 needed only 40 elapsed minutes!
    SAS 6.07 has also significantly reduced the CPU increase we saw with
    SAS 6.06.  JCLTEST6 used 8 CPU minutes under SAS 5.18, used 30 CPU
    minutes under SAS 6.06, and 6.07 needed only 11 CPU minutes!

    JCLTEST6 may not be typical of a daily PDB run, but it exercises SAS
    by building every possible MXG data set, one at a time, creating
    lots of small data sets, and then PROC PRINT and PROC MEANSing them.


    The real benchmark job of interest is the daily BUILDPDB, which was
    executed with an input SMF file of 10,000 steps, 3800 jobs, and 18
    hours of RMF data, from 32MB of SMF data.  The results of several
    experiments show consistent improvement in 6.07:


                  ---Read SMF Infile---    --Job Total--  Work     PDB

     Experiment   CPU   Elapsed  Virtual   CPU   Elapsed  Tracks  Tracks
                  m:ss   m:ss              m:ss   mm:ss


     6.07-OBS=0    :40   1:28    17194K     :59    2:42    354     104

     6.07-23040   2:12   5:31    15764K    2:58   10:48    578     474

     6.07- 6144   2:11   6:03    15556K    2:58   12:00   1396     517

     6.06-23040   2:34   7:40    12440K    3:28   15:07    803     494

     5.18-23040   1:25    ?       4000K    2:08   14:25    691     438


    The first Experiment was an execution with SMF DD DUMMY so no real
    records were processed; this test exercised the SAS compiler and
    actually created every data set in the PDB, but all had zero obs.
    This run shows the minimum cost of a daily BUILDPDB is 59 CPU secs
    and 2:42 elapsed minutes, and that 2/3 of that CPU and 1/2 of the
    elapsed time is spent in the INFILE processing step of BUILDPDB.
    This BUILDPDB was tailored to also process DB2 100 and 101 records,
    so it is not exactly the overhead of the following four runs, which
    did not include the DB2 processing.

    The other four Experiments all read the 32MB SMF file and created
    a representative PDB.

    The 6.07-23040 and 6.07-6144 compare the impact, especially in the
    size of the work file, of the BLKSIZE option.  The default 6144 run
    required 1396 tracks of work space, but the half-track recommended
    blocksize needed only 578 tracks.  The PDB dropped from 517 tracks
    with 6144 to only 474 tracks with half-track blocking.  It should be
    quite clear why you want half-track blocksize on your MXG database.
    Note CPU times were the same, testifying to improvements in the SAS
    I/O engine, but the elapsed time is also improved by the half-track
    blocksize, dropping from 12 to less than 11 minutes.

    The 6.06-23040 experiment compared with the 6.07-23040 runs shows
    the decrease in CPU (3:28 down to 2:58) and Elapsed (15 minutes down
    to less than 11) and reduced work space (803 down to 578) and PDB
    size (494 down to 474) with the 6.07 improvements.

    The final 5.18-23040 experiment shows the 6.07 CPU did not quite get
    back to the old 5.18 value, but the run time improvement of 6.07 is
    appreciable, and 6.07 used less work space than 5.18 too!

    It was the analysis of these experiments that convinced me to change
    the CONFIG options for SAS 6.06+ to BLKSIZE=23040, BUFNO=2.

    SAS gets a big ATTABOY for their improvements coming in SAS 6.07!

IV. Documentation of MXG Software.


Member CHANGES always contains the version number of MXG Software, and
it lists changes that were installed in that version.  The members named
CHANGEnn have the contents of CHANGES when that "nn" MXG version was
created.  Description of enhancements will be found in the text of the
Change description that made the enhancement (in those CHANGES and
CHANGEnn members).  The CHANGE  members can be scanned online (with SPF
BROWSE) to search for specific product name references (CICS, MVS/ESA,
etc.).  The text of each Change identifies the member(s) that were added
or altered by that change. Documentation (especially for new product's
support) is usually also found in comments at the beginning of those
members listed in the change entry.

Member NEWSLTRS contains the text of all newsletters (up through the
newsletter that accompanied that MXG release). You can search NEWSLTRS
for product name or acronym to find the technical notes, APARs, etc.
from all MXG newsletters.  (The Change Log of each Newsletter is not
replicated in member NEWSLTRS, since that text will be in CHANGES).

Member DOCVERnn is the "delta-documentation" (in abbreviated Chapter
FORTY style) of only those variables and datasets that were changed
between successive MXG Versions. There is a DOCVERnn "delta" member in
the MXG library for each version.

Penultimately, member DOCVER contains abbreviated Chapter FORTY format
that documents all of the variables names in all of the MXG data sets
that are created by that MXG Software Version (alphabetically by data
set name and variable name).

Finally, MXG is a source distributed system, so you can often find your
answer by BROWSE/EDIT of the source member, especially the VMACs that
actually create the data set, or ANALs that analyze the MXG data sets.
In many instance, the MXG Variable name is the IBM or Vendor's field or
DSECT field name. In other cases, the DSECT field name is carried as a
comment beside in the MXG INPUT statement to map field name to MXG's
variable name.  MXG expects you to also have access to the vendor's
documentation of particular data records you are using for analysis.


V. MXG Version 9.3 Installation, Space, Compatibility, etc.

   MXG Compatibility Exposures in MXG Version 9.3 for Existing Users:

   a.  The SAS options required by MXG for execution have changed since
       MXG 7.7 (but not since MXG 8.8).
   b.  Execution under SAS 6.06 is different than under SAS 5.18.
   c.  To create your PDB directly on tape, IMACCICS must be changed.
   d.  If you have added additional SMF record processing to BUILDPDB,
       and you still execute MXG under SAS 5.18, you may encounter a
       SAS Version 5.18 Compiler Limit "344" error. BUILDPDB is larger.
       See Change 7.038 in member CHANGE07 for 344 error circumvention.

Always read comments in the CHANGES member for compatibility issues, as
well as for any last minute changes added after Newsletter composition.

 1. Installation, re-installation, and Space Requirements.

The MXG Installation instructions were found in Chapter 32 of the MXG
Supplement for both new installation and for version replacement, and
those instructions, plus this discussion, is still usable. MXG SOURCLIB
member INSTALL will be a complete rewrite of Installation Instructions
for MXG, consolidating both Chapter 32s and these notes.  After you have
unloaded the MXG SOURCLIB and read these notes, read member INSTALL.

The MXG tape is distributed as a Non-Labelled (NL) tape with a single
file, DCB=RECFM=FB,LRECL=80,BLKSIZE=32720, that is actually an unloaded
Partitioned Data Set containing 1446 members (and about 322,585 source
lines) in IEBUPDTE format.

Under MVS use the IEBUPDTE utility to build the MXG.SOURCLIB library.
Under CMS use the TAPPDS   command to build the SOURCLIB MACLIB library.

Under MVS, MXG Version 9.3 MXG.SOURCLIB requires SPACE=(CYL,(42,1,299))
and DCB=(RECFM=FB,LRECL=80,BLKSIZE=32720) on DASD.

Under CMS, approximately the same space (45 cylinders) will eventually
required by the MXG SOURCLIB MACLIB, but during the CMS installation
process you should have at least 100 free cylinders on your minidisk.

MXG is tailored and extended by "Installation Macro" members (begin with
IMAC) and the "MXG Exit Facility" members (begin with EX) that are put
in the installation's "USERID.SOURCLIB", the "MXG Tailoring" library,
that is concatenated ahead of MXG.SOURCLIB in your SOURCLIB DDNAME:

  //SOURCLIB DD DSN=USERID.SOURCLIB,DISP=SHR --> site tailoring (yours)
  //         DD DSN=MXG.SOURCLIB,DISP=SHR    --> never changed  (mine)

If this is an MXG re-install, there should already be a USERID.SOURCLIB.
If not, then allocate one using the same attributes as the MXG.SOURCLIB,
with SPACE=(CYL,(1,1,99)); for CMS create an equivalent MACLIB.

Tailor by copying the member from my library to your library.

IMAC.... members are self-documenting. IMACAAAA indexes all IMACs.

You should create a member CHANGES in your USERID.SOURCLIB and record
therein chronologically your MXG tailoring and installation history,
just like the member CHANGES in our MXG.SOURCLIB tracks MXG itself.
You must also browse the members in USERID.SOURCLIB. If there are VMACs
members in your library, they will override the new MXG VMAC member, and
thus you should remove all VMACs that override MXG when you install a
new verison of MXG. However, it is normal to have IMACs members there.

   If you have installed printed changes from an MXG Newsletter, you
   might-have copied VMAC member(s) from MXG.SOURCLIB into your site's
   USERID.SOURCLIB and then made the changes therein, or alternatively,
   you could have made a new PDS (we suggested the name MXG.CHANGLIB)
   into which you put those in-between-version changes, concatenating
   it between USERID.SOURCLIB and MXG.SOURCLIB until you receive this
   new MXG Version.  In either case, if you made temporary changes,
   now is the time to remove them.  Delete the changed VMACs members
   from your USERID.SOURCLIB,  or remove the MXG.CHANGLIB from your
   SOURCLIB concatenation.

   If you have tailored IMAC.... members in your USERID.SOURCLIB, and
   that member was changed by the new MXG Version, you must compare your
   member with the new MXG member, and retrofit your tailoring on the
   new member.  These IMACs are of particular importance, if they exist:

   IMACPDB (options for BUILDPDB) has changed and must be retrofit.

   IMACKEEP can cause syntax errors when MXG creates a new dataset from
            an existing record. For example, in 8.8, CICS/ESA added new
            CIC.... datasets in TYPE110/VMAC110 processing.  If IMACKEEP
            had been used to tailor the variables kept in CICSTRAN by
            redefining the  _VAR110 macro (an appropriate use of this
            tailoring exit), the new dataset will cause "Dataset not in
            DATA statement" SAS error condition), until you retrofit
            your IMACKEEP changes using _VAR110 from the current MXG.

Whenever you install changes or test a new version of MXG (or even your
own reports), be extra careful to look on the SAS log for any real error
conditions. Search for all occurrences of "ERROR:" and  "ERROR :"  and
"UNINITIALIZED" and "NOT CATLGD", as they may indicate a serious error.

A PROC PRINT and a PROC MEANS of each new MXG-built SAS dataset can help
you to understand their contents, and should be used to examine any
unusually large, negative, or suspicious values.  Print all variables in
the data set, and read the variable's descriptions in Chapter FORTY.


 Summary of critical actions to be taken in installing new version:

     a. All VMAC.... members in your USERID.SOURCLIB must be examined
        and, in general, must be deleted.

     b. All IMAC.... members in your USERID.SOURCLIB must be compared
        with the new IMAC.... members, and if there is a difference,
        you MUST start with this version's IMAC and retrofit your
        installation's tailoring. Member IMACAAAA indexes IMAC's.

     c. It is always wisest to PROC PRINT the first 50 observations of
        important datasets, especially PDB.JOBS, which can be affected
        by user tailoring in IMACPDB. A visual scan of that PROC PRINT
        serves as an excellent validation of correct installation, and
        will almost always detect any serious problems BEFORE you begin
        your production MXG runs!  See also the MXG utility UTILPRAL.


VI. Change Log

--------------------------Changes Log---------------------------------

 You MUST read each Change description to determine if a Change will
 impact your site. All changes have been made in this MXG Library.

 Member CHANGES of the MXG SOURCLIB will always be more accurate than
 the printed changes in a Newsletter, because the software is created
 after the newsletter is sent to the printer!

 Member CHANGES always identifies the actual version and release of
 MXG Software that is contained in that library.

 The actual code implementation of some changes in MXG SOURCLIB may be
 different that described in the printed NEWSLETTER (which might have
 printed only the easily installed, critical part of the correction).

 Always read the comments at the beginning of each source member named
 under the Change Number for impacting changes.

 Documentation of new datasets and variables, validation status, notes,
 etc., are usually in comments in the source members.

 Changes thru 9.104 are  contained in MXG PreRelease 9.3, Aug  1, 1991.
 Changes thru 9.069 were contained in MXG PreRelease 9.2, July 1, 1991.
 Changes thru 9.038 were contained in MXG PreRelease 9.1, June 3, 1991.
 Changes thru 8.305 were contained in MXG Production 8.9, May 1, 1991.
 Changes thru 8.285 were contained in MXG Production 8.8, Apr 8, 1991.
 Changes thru 8.283 were printed in NEWSLETTER NINETEEN,  Apr 8, 1991.

Alphabetic INDEX of significant changes in MXG 9.3 (all after MXG 8.8):

  Member    Change   Description

  ANALACHE  8.293  Cache RMF Reporter analysis uses 3990 records now.
  ANALDB2R  8.299  Variable Not Found if only Acct Trace Long requested.
  ANALDB2R  9.030  DB2 Reports have incorrect values for some fields.
  ANALDB2R  9.032  DB2 Audit Reports not created if PDB=SMF specified.
  ANALDB2R  9.104  DB2 Trace TRANSIT report causes DATA IS NOT SORTED.
  ANALRACF  9.064  RACF Analysis of OPERATOR,SPECIAL activity.
  ANALTMS   9.059  PROC SUMMARY out of memory condition.
  ANALVVDS  9.031  PERM should be changed to MXGVVDS.
  ANALVVDS  9.053  MXG 9.1 only, VMXGVVDS should have been MXGVVDS.
  AS400PDS  8.286  AS400PDS contains no records.
  ASUM70PR  9.091  TYPE70PR data summarized into PDB.ASUM70PR
  ASUMDBDS  9.012  TMON/CICS trending fails with Release 7 data.
  ASUMJOBS  8.291  EXCPTOTL, IOTMTOTL were not kept in BATCHJOB.
  BUILDPDB  9.049  SAS 6.06 and MXG 8.8 under MVS/370 options.
  BUILDPDB  9.095  Dataset TYPE0203 added to default datasets built
  CASORT66  8.295  SAS datasets destroyed by CASORT release 6.6.
  CHANGE08  9.073  Example to create _DAY in 8.213 was wrong
  CONFIG    9.022  Option VERSIONLONG specified to display SAS version.
  DIFFDB2   9.080  Not all DB2STAT0/1 variables were deaccumulated
  EXPDB304  9.034  BUILDPDB/3 steps data creation exit.
  EXPDB6    9.034  BUILDPDB/3 steps data creation exit.
  IEBUPDTE  8.286  Unload of MXG 8.8 set condition code 4.
  IMACACCT  8.290  ACCOUNT FIELD n LENGTH WRONG corrected.
  IMACCICS  9.005  PDB cannot be built on tape unless IMACCICS changed.
  IMACEXCL  9.051  Support for CICS type 110 EXCLUDE statement.
  IMACFMTS  9.066  New IMAC for user formats for SAS 6.06.
  IMACKEEP  9.017  A better way to drop MXG variables not using IMACKEEP
  JCLDASD   9.031  MXGDASD,PERM DDNAMEs should be DISK,MXGDASD

  SPUNJOBS  9.005  PDB.SPUNJOBS on tape caused 207 error.
  SPUNJOBS  9.013  SPUNJOBS timestamps not 8 bytes, truncating values.
  TLMS      9.041  TLMS causes 713-04 ABEND if DBLTIME=0.
  TRND70PR  9.091  TYPE70PR data creates new TREND.TRND70PR
  TRND71    9.092  TYPE71 data creates new TREND.TRND71
  TRND72    9.093  MVS/ESA 4.2 variables added to TREND.TRND72
  TRNDDB2A  8.301  DB2 Acct trending failed in 2nd week of execution.
  TRNDDB2S  8.301  DB2 Stats trending failed in 2nd week of execution.
  TRNDVMXA  9.028  VM/XA Trend Data Base implemented.
  TRNDVMXA  9.089  VM/XA Trended PFXUTIME and PCTCPUBY incorrectly
  TYPEMON8  9.011  TMON/CICS Release 9.0 supported via conversion only.
  TYPEMON8  9.015  TMON/CICS Version 8 History file cause MXG failure.
  TYPEPDL   8.297  Fujitsu FACOM MSP and FSP support replaced XPDLPDA.
  UTILCICS  9.019  Not Sorted error corrected for CICS/ESA dictionary.
  VDOCACHE  9.027  Documentation re-write has begun.
  VMAC110   8.292  Unexpected Statistics Subtype due to Boole CICSMGR.
  VMAC110   9.051  Support for Shared Medical Systems CICS modifications
  VMAC110   9.062  Support for CICS/ESA 3.2.1.
  VMAC110   9.084  CICS PCLOADCN has different meaning.
  VMAC110M  9.008  SAS 5.18 344 circumvention caused BUILDPDB failure.
  VMAC28    9.061  Support for NetView Performance Monitor NPM 4.1.1.
  VMAC30    9.001  INVALID DATA FOR SMF30ASO with MVS/ESA 4.2 eliminated
  VMAC30    9.085  STCs starting with A confused APPC logic.
  VMAC42    9.048  Circumvention of IBM DFP 3990 Cache type 42 errors.
  VMAC57    9.010  Invalid ESS Section message due to IBM error.
  VMAC6     9.083  OUTDEVCE changes affect PRINTLNE, EXTWTRLN
  VMAC6156  9.046  TYPE6156 variables ACTION, FUNCTION not valid.
  VMAC7072  9.001  INVALID DATA FOR IOCRFC with MVS/ESA 4.2 eliminated.
  VMAC7072  9.054  MXG 9.1 only, Change 9.001 incompletely installed.
  VMAC7072  9.070  TYPE72 CPUHPTTM,CPUIIPTM,CPURCTTM wrong in MVS 4.2
  VMAC7072  9.072  TYPE70PR LCPUADDRs 2 and 3 wrong if DEDICATED CPU
  VMAC73    9.001  INVALID DATA FOR IODFDATE in MVS/ESA 4.2 eliminated.
  VMAC74    9.001  First STOPOVER with MVS/ESA 4.2 data corrected.
  VMAC74    9.039  Second STOPOVER with MVS/ESA 4.2 data corrected.
  VMAC78    9.055  STOPOVER with MVS/ESA 4.2 data corrected.
  VMAC78CU  9.047  Missing fields due to IBM microcode errors.
  VMAC79    9.007  Support for (archaic?) RMF 3.5.1 type 79 records.
  VMACACF2  8.289  ACF 5.2 new variables not kept.
  VMACACF2  9.086  ACF2 REC=L CN=3 records were not output
  VMACACHE  8.293  Cache RMF Reporter support enhanced and decoded.
  VMACAIM2  8.298  Fujitsu AIM database manager records corrected.
  VMACCADM  9.021  Support for CADAM's Statistics Data File.
  VMACCTLD  9.038  Support for 4th Dimension's CONTROL-D SMF record.
  VMACDCOL  8.285  IBM DASD measures use MB for million, not megabytes.
  VMACDMON  9.065  ASTEC RLDCNT,RDLCNT incorrect
  VMACEPIL  8.284  Support for EPILOG/CICS 451 added, and enhanced.
  VMACEPIL  8.287  Invalid member on MXG 8.8 replaced.
  VMACFTP   9.056  Support for NetView FTP User SMF record.
  VMACHSM   9.097  Support for HSM 2.6 SMF record
  VMACILKA  9.020  Support for Interlink's SNS/TCPaccess SMF record.
  VMACILKG  9.020  Support for Interlink's SNS/SNA Gateway SMF record.
  VMACILKV  9.020  Support for Interlink's SNS/TCPvt  SMF record.
  VMACIMS   9.063  TYPEIMS Input Queue time correction.
  VMACNSPY  9.033  STOPOVER protection for invalid records.
  VMACNSPY  9.044  STOPOVER with NETSPY Accounting record.
  VMACNSPY  9.045  NETSPY Accounting subtype caused STOPOVER.
  VMACSMF   9.094  New message at end of SMF processing on log
  VMACSPMS  9.088  Support for Amdahl's SPMS Release 1.2 SMF record
  VMACTAO   9.018  Support for Fischer's Totally Automated Office TAO.
  VMACTMS5  9.016  Support for CA-1 (TMS) Release 5 complete rewrite.
  VMACTMS5  9.057  Missing semicolons.
  VMACUCB   9.002  3490E cartridge tape now recognized.
  VMACVMXA  8.296  VM/XA used more work space than really required.

  VMACVMXA  9.096  'LOGICAL RECORD SPANS" message corrected
  VMXGHSM   9.009  HSM MCD data can cause STOPOVER.
  VMXGVTOF  9.035  SAS 5.18 only, did not read all extents.
  VMXGVTOF  9.040  First Extent on each volume lost.      .
  WEEKBLD   9.050  Submitting job may need DCB on INTRDR DDNAME.
  XMAC74    9.054  MXG 9.1 only, Change 9.001 incompletely installed

Inverse chronological list of all Changes:

 Changes 9.104-9.001 and 8.305-8.284 were printed here in Newsletter 20

  See member CHANGE09 for actual change text.

End of Changes Log in Newsletter TWENTY.
****************NEWSLETTER NINETEEN*************************************










             MXG NEWSLETTER NUMBER NINETEEN April 8, 1991



Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE



                         TABLE OF CONTENTS



I.   MXG SOFTWARE Version status.
  1. Production MXG Version is MXG 8.8, shipped April 8.        page   2
  2. Recent IBM Announcements and their MXG support.            page   3
II.  MVS Technical Notes.                                       page   3
  1. SMF CI Size should be 22K/26K for 3380/3390 devices.       page   3
  2. Timestamps in CICS and DB2 records may have wrong hour.    page   3
  3. PSF Printer utilization analysis.                          page   4
  4. Use PDB.STEPS for ABEND analysis.                          page   4
  5. Duplicate-Job-Name-HOLD delay detection.                   page   5
  6. APAR OY40625 for Vector Processors.                        page   5
  7. APAR OY36668 captures PR/SM LPAR "overhead".               page   5
  8. OPPSI, Operator Single System Image in a SYSPLEX.          page   5
  9. APAR OY31613, PTF UY56157 in error, lost jobname.          page   5
 10. DFSORT Release 10 invalid type 16 SMF Sort record          page   5
 11. SHARE 76 Paper "MVS/ESA Performance and Accounting Data"   page   6
III. VM  Technical Notes.
  1. SHARE 76 Paper "VM/ESA Measurement Facilities"             page  28
IV.  SAS Notes.
  1. SAS 6.06 has been repaired, and can be safely used.        page  37
  2. SAS 6.06 and 5.18 options now REQUIRED by MXG 8.8.         page  37
  3. Format libraries differences between MVS SAS 6.06-5.18.    page  38
  4. CMS-MXG Installation and Execution Considerations.         page  39
  5. SAS Input formats for times and timestamps.                page  40
  6. "Close" of data libraries was changed by SAS 6.06.         page  40
V.   Documentation of MXG Software.                             page  41
VI.  Installation, Space, Compatibility, for MXG 8.8.           page  41
VII. Change Log  Changes 8.283 to 8.187.                        page  44
      (Alphabetic INDEX of Significant Changes on page 44)      thru  72



         COPYRIGHT (C) 1991 BY MERRILL CONSULTANTS DALLAS TEXAS
          MXG IS A REGISTERED TRADEMARK OF MERRILL CONSULTANTS
          SAS IS A REGISTERED TRADEMARK OF SAS INSTITUTE

I.   MXG SOFTWARE Version status.

  1. Production MXG Version is now MXG 8.8, dated April 8, 1991.

 MXG Version 8.8 is shipped with NEWSLETTER NINETEEN to all sites, and
 should be installed as soon as possible.  MXG 8.8 is mandatory for MXG
 execution under SAS 6.06 or later, has MANY major enhancements, and has
 been testing at over 500 MXG sites.  MXG 8.8 WILL SAVE YOU TIME LATER,
 SO PLEASE INSTALL IT AS SOON AS POSSIBLE. Major enhancements in MXG 8.8

        Support for Amdahl MDF Performance Tool "MPT" SMF record.
        Support for Amdahl MDFTRACK record.
        Support for Amdahl SPMS Cache DASD Controller SMF record.
        Support for Boole IMF 2.6 (for IMS 3.1).
        Support for Cray COS 1.16 Operating System Data.
        Support for DASD Space management with fast VTOC read program.
        Support for DASD VTOCs and VVDSs for SMS variables.
        Support for Hitachi processors MLPF.
        Support for IBM CICS/ESA 3.1.1 Monitor and Statistics Data.
        Support for IBM DCOLLECT data records.
        Support for IBM DCOLLECT data records.
        Support for IBM HSM user SMF records, including deaccumulation.
        Support for IBM HiperBatch statistics in SMF type 14, 15, & 64.
        Support for IBM IMS/ESA 3.1.
        Support for IBM MVS/ESA 4.1.
        Support for IBM MVS/ESA 4.2.
        Support for IBM NETVIEW/NPM 1.4
        Support for IBM RMF 4.1.2 (APAR OY29112, PTF UY90666).
        Support for IBM RMF 4.2.0
        Support for IBM RMF 4.2.1
        Support for IBM SMS records (HSM, VVR, VVDS, SMS/DFP) enhanced.
        Support for IBM VLF subtype 3 in SMF type 41.
        Support for IBM VM/ESA Version 1 Release 1.0 (ESA Feature).
        Support for Landmark's Monitor for CICS Version 8.
        Support for Landmark's TMON/MVS Version 1.1 and spanned records.
        Support for Oracle SMF record.
        Support for RSD WSF2 version 3.3.4.
        Support for Tangram Arbiter Version 2.1.1.
        SPIN library fills due to JES2 maintenance circumvented.
        CICS Shutdown Statistics no longer printed, only in SMF or MXG.
        Documentation of Trend Data Base processing.
        Documentation of DB2 analysis.
        Documentation of IMAC.... installation tailoring members.
        Corrections in IMS Log measurement of INPQUETM/RESPNSTM.
        NPM records from VM can be processed.
        Testing of MXG Version 8.8 under SAS 6.06 Version 6.06.
        DB2 trace SQL reporting.
        DB2 trace Transit Time reporting.
        BUILDPDB/3 Enhancements.
        - SPIN library copied into PDB for backup and recovery
        - ACCOUNTn and SACCTn added to SMFINTRV.
        - TYPE25 processing added for JES3.
        - PDB.SPUNJOBS allows reporting on jobs still in SPIN library.

  MXG Software next-release agenda (subject to change):
        Validation of EXPLORE/VM, EPILOG/CICS, and restructure of the
          AS400 support was not complete as this was written.
        DB2 2.3 will be supported when available, late this year.
        CICS 3.2 will be supported when available, later this year.
        Landmark CICS Version 9 will be developed later this year.
        Cray UNICOS is a future consideraton.
        VAX/VMS Account/SPM is a future consideration.
        JES3 Tape Mount Merge with TYPETMNT is a future consideration.

  2. Recent IBM Announcements and their MXG support.

 IBM has made many major announcements relating to the System/390, the
 ES/9000 family, and ESCON capabilities.  The following table identifies
 announced availability dates for the IBM product, and the corresponding
 Version/PreRelease of MXG required to support that IBM product.

   Product Name                     Availability     MXG Version
                                    Date              Required

   VM/ESA  1.1.0 (370 Feature)      Oct 26, 1990.        7.7
   RMF 4.1.2 (for MVS/ESA 3.1.3)    Sep  7, 1990.        8.8
   RMF 4.2   (for MVS/ESA 4.1)      Oct 26, 1990.        8.8
   MVS/ESA 4.1                      Oct 26, 1990.        8.8

   MVS/ESA 4.2                      Mar 29, 1991.        8.8
   RMF 4.2.1 (for MVS/ESA 4.2)      Mar 29, 1991.        8.8

   VM/ESA  1.1.0 (ESA Feature)      Mar 29, 1991.        8.8
   VM/ESA  1.1.1                    Dec 27, 1991.        ???



II.  MVS Technical Notes.

  1. SMF CI Size should be 22K/26K for 3380/3390 devices.

  SMF VSAM data sets should use a CI size of 26K for 3390's and a CI
  size of 22K for 3380's, to reduce physical I/Os to the VSAM file and
  to optimize disk storage space for SYS1.MANs. The DCB for the output
  data set created by the IFASMFDP program MUST specify:

           DCB=(RECFM=VBS,LRECL=32760,BLKSIZE=32760)      on tape

           DCB=(RECFM=VBS,LRECL=32760,BLKSIZE=23476)      on 3380

           DCB=(RECFM=VBS,LRECL=32760,BLKSIZE=27998)      on 3390

  to avoid potential SMF data loss.  Yes, the IFASMFDP utility defaults
  to BLKSIZE=32767, but off-the-shelf packages have failed with that
  irrational and inappropriate value, often corrupting data. The BLKSIZE
  should always be 32760 for sequential data on tape, and should be the
  half-track-value if you dump to DASD devices. Since the record format
  is VBS, there is no required relationship between BLKSIZE and LRECL
  (if RECFM is V or VB, there IS the requirement that BLKSIZE be 4-bytes
  larger than LRECL, but is not true for VBS). Since the actual maximum
  LRECL that can be written by SMF writer is 32760 (including the RDW)
  does actually occur (a subtype 1 type 79 record with over 330 active)
  the LRECL MUST be 32760. If you specify a smaller LRECL on your dump
  output AND a real 32760 RDW LRECL record occurs, it will be truncated!

  2. Timestamps in CICS and DB2 records may have the "wrong" hour of the
   day, if the sites PARMLIB member PARMTZ (370) or TIMECLOCK (XA,ESA)
   is non-zero.  While ALL other SMF records reflect the site's true
   "Time-of-Day", and while the SMFTIME value in the DB2 and CICS SMF
   records is "true", only DB2 and CICS use TIMECLOCK internally which
   causes DB2 variables QWACBSC, QWACESC, QWHSSTCK, and CICS variables
   STRTTIME, ENDTIME to contain the "Time-of-Day" Plus or Minus the site
   TIMECLOCK value.  This is true no matter which vendor writes the data
   records for CICS and/or DB2.  Sure makes analysis harder!  While the
   MXG exit facility can be used to correct these times, it sure would
   be better if DB2 and CICS would conform to the rest of the SMF data!


3. PSF Printer utilization analysis in ANALPRTR and associated members
    solve several long-term analysis problems.  This is a brief summary
    of that implementation.

   The IBM 3800-3 Printer running under PSF has several unfortunate
   characteristics that make it difficult to measure directly with TYPE6
   (PDB.PRINT) data for predictions of performance and print throughput.
   First, each time that a set of banner pages is encountered, a printer
    pauses for about 9.5 seconds.  This does not occur when the printer
    is running in 3800-1 emulation mode, (i.e., as a JES printer), but
   only when the printer is running under PSF.
   Second, the NPRO value set for PSF (in JES JOBPARMS or in the PSF JCL
    Procedure) affects how long a job's output will sit in the transfer
    station before it is mechanically moved through the fuser and into
    the output stacker.  Since there is 9 feet of paper in the path, if
    each job were pushed into the output stacker immediately upon its
    print completion, paper would be wasted.  Instead, thejob's SYSOUT
    is left at the transfer until:
    a) Another JOB begins printing and pushes the job to the stacker, or
    b) The operator mashes the NPRO button, or
    c) The amount of time specified in NPRO parameter expires.
   The SMF type 6 record will not be timestamped until the SYSOUT has
    reached the output stacker and (this may be important) also when the
    printer is ready to print the next job.  If an operator presses NPRO
    (to eject) but then fails to press READY button, the type 6 will not
    be timestamped until (much?) later.  For PSF printers throughput in
    ANALPRTR, an NPRO is said to have occurred whenever there were NPRO
    minutes between the end of one and the start of the next event, and
    the NPRO value is subtracted from the previous print duration, which
    more accurately reflects true printer utilization.  Note that this
    approximation cannot estimate printer utilization due to paper jams,
    out of paper, out of toner, or other operator intervention.
   One site found 215 ppm printers actually ran at only 90 ppm because
    the average print job was much less than 25 pages!

4. Use PDB.STEPS for ABEND analysis.  Steps ABEND, jobs don't.

   ABEND Analysis should always be done with the PDB.STEPS (or TYPE30_4)
   data set). The PDB.JOBS (or TYPE30_5) is not valid for ABEND data.
   Programs ABEND, jobs don't!  And multi-step jobs can have multiple
   ABENDs.  In addition, the ABEND and CONDCODE variables in PDB.JOBS
   are taken from TYPE30_5, but it turns out that the 30_5 may not be
   valid. Flushed steps following an ABEND can create a job termination
   record with SYSTEM abend flagged, but with a zero CONDCODE value!

   You really want to use the step level data for ABEND analysis anyhow,
   because you can then identify which PROGRAMS are causing failures.
   You may have fifteen jobs which ABENDed because of the same program;
   using PROGRAM name will show the culprit, whereas using JOB wouldn't.
   The first few characters of PROGRAM will identify the "group" that
   wrote the program (eg., IBM utilities, vendor software, in-house
   written COBOL programs, etc.). You can provide management with a
   clearer picture of what failures occur, for example, by using:
           DATA ABENDS;
            SET PDB.STEPS;
            IF ABEND GT " ";      /*select only failing programs*/
            LENGTH GROUP $3.;     /*use 1st 3 characters for group*/
            GROUP=PROGRAM;
            KEEP GROUP PROGRAM ABEND CONDCODE;
           PROC SORT DATA=ABENDS; BY GROUP;
           PROC FREQ DATA=ABENDS; BY GROUP;
            TABLES CONDCODE*ABEND/NOROW NOCOL NOPERCENT;
            TITLE 'MXG ABEND ANALYSIS BY PROGRAMMING GROUP';

  5. Duplicate-Job-Name-HOLD delay detection.

   JES2 users frequently submit series of jobs with identical job names,
   because they want the jobs to sequence themselves one at a time. The
   input wait time (IWT is READTIME to INITTIME) will be wrong, as it
   includes the time waiting in "HOLD". (Note this is not a problem with
   TYPRUN=HOLD jobs, because variable TYPRUN identifies them).  Freddie
   Arie at Lone Star Gas saw that the key condition to identify a
   Duplicate-Name-Held-Job delay is when the "end of execution" of the
   preceding job is LATER than the read-in time of this job. For these
   jobs, the previous job's "end time" must be used for this job's start
   of "read-in". For a job that was NOT delayed due to duplicate name
   hold, we use variable JRDRTIME as the "read-in" instead of READTIME
   for two reasons. First, JRDRTIME is the "end of read-in event", and
   more appropriate than the READTIME, the "start of read-in event".
   Second, for jobs submitted via NJE, READTIME is on the clock of the
   submitting node (e.g., EST), while JRDRTIME is on the clock zone of
   the receiving (executing) node, so its use eliminates the NJE clock
   differences.  For jobs which are delayed due to duplicate job name
   hold, the "end of execution" time to be used for the next job depends
   on whether this job was also restarted.  For a job that was NOT
   restarted (i.e., RESTART=1), the JTRMTIME is the "end" to be used.
   Consider, however, a job restarted due to data set name enque.  That
   single job could sit in hold for hours, while the other duplicate
   jobs continued to execute.  For restarted jobs, then, we use JRSTTIME
   (the actual time the operator first restarted the job) for "end" time
   in the IWT calculation of the subsequent duplicate name job.

   This algorithm is not perfect.  If a sequence of duplicate jobs spans
   two PDB's, the first job in the second PDB will not be recognized as
   a part of a duplicate jobname hold family, and the IWT time for that
   first job will be incorrectly calculated from JRDRTIME instead of the
   real "end time".  Using a weekly or monthly PDB as input reduces this
   probability, but it cannot be completely eliminated.

   This algorithm is now implemented in the ASUMJOBS member, summarizing
   and reporting batch job service from the PDB.JOBS, which is also used
   as the input to create the PDB.JOBSKED for batch service objectives.
   With the new implementation, the IWT reported by ASUMJOBS output no
   longer includes delay due to duplicate job name hold condition.

  6. APAR OY40625 is mandatory if you use Vector Processors. Without it
     fix, the Vector Processor Affinity CPU times are wrong. The fix is
     needed for MVS/ESA 3.1.3 thru 4.1.0.

  7. APAR OY36668 captures PR/SM LPAR management time and LPAR overhead.

  8. OPPSI, Operator Single System Image in a SYSPLEX, RMF support
     consists of six new traceable fields (with TYPE76).

  9. MVS/XA Only, APAR OY31613, PTF UY56157 is in error and can lose the
     Job name in SMF records. The APAR recognizing the PE (PTF in Error)
     is OY38538 and a SUPERZAP fix existed 12/11/90.

 10. DFSORT Release 10 occasionally produces a type 16 SMF Sort record
     with exactly 24 hours CPU TCB time. The problem goes away in Rel 11

 11. SHARE 76 Paper "MVS/ESA Performance and Accounting Data"
          that is now captured in MVS/ESA Version 4.2

                    H.  W.  Barry Merrill, PhD
                       President-Programmer
                       Merrill Consultants
                       Dallas, Texas 75229

     Portions of this paper were presented/published at/in:

            UKCMG 90 Glasgow, Scotland May 21, 1990
            SWCMG    Austin, Texas     Jun 21, 1990
            MXG Newsletter SEVENTEEN   Jul 10, 1990.
            SHARE 76 San Francicso, CA Feb 26, 1991.
            MXG Newsletter NINETEEN    Apr  8, 1991.

This  paper  identifies  the  significant changes in data elements that
are now captured by MVS/ESA 4.2.  PR/SM CPU "overhead" is now measured.
Three new CPU measures captured in SMF type 30 and type 72 data affect
billing and capacity measures.  Step level use of HIPERSPACE DataSpace
resources (like CPU time) are captured.  "Resident Frame Seconds" of
Central AND Expanded memory are separated for each performance group.
Print is identified to the step. Blocked paging exists.  New APPC/MVS
has resource accounting SMF data.  The SMF writer itself is enhanced.
This paper includes all changes in these releases:

    MVS/ESA 3.1.0e  MVS/ESA 3.1.3   MVS/ESA 4.1   MVS/ESA 4.2
    MVS RMF 4.1.1       RMF 4.1.2       RMF 4.2       RMF 4.2.1



a. New MVS/ESA CPU measures, two old, one new, have been added.

  "RCT"  - Region Control Task (Quiesce/Restore/Swap), caused
CPURCTTM   by TSO swapping.  This time has always existed,
           (as uncaptured CPU), and was the major contributor
           to poor TSO capture ratios.

  "IIP"  - I/O Interrupt Processing (Second Level Interrupt
CPUIIPTM   Handler, SLIH).  This time has always existed,
           (as uncaptured CPU), and affected all workload's.
           capture ratios.

  "HPT"  - Hiperspace processing CPU time. Hiperspace CPU time
CPUHPTTM   displaces functions which formerly were measured under
           TCB (or SRB). For example, a SORT using Hiperspace will
           significantly REDUCE the recorded TCB CPU time, because
           function moved from TCB to HPT.  DFSORT benchmarks show
           TCB reduced from 100 to 50 seconds, but HPT recorded 25
           seconds; thus actual CPU reduction was only 100 to 75!
           Billing/Capacity measures based on only TCB+SRB time are
           very inaccurate in a Hiperspace environment.
             Hiperspace CPU time is only recorded for tasks that
             execute in a User Protect Key, and only User Key Data
             Spaces are under control of the IEFUSI exit for size.
             Most IBM uses of dataspaces (HiperBatch, VLF, DFP, CATALOG)
             use Key Zero to avoid IEFUSI virtual storage limitations,
             and thus will not record HPT CPU time (nor DSSIZHWM, see
             below).
Moral:
         You MUST use all seven CPU measures in billing/capacity:

 CPUTM = TCB + SRB + ITCB + ISRB + RCT + IIP + HPT

b. PR/SM "overhead" is captured with APAR OY36668 in ES/9000 or 3090J's.

   The "Effective Dispatch", LCPUEDTM, is recorded for each partition in
   TYPE70PR.

   The difference between the Partition Dispatch LCPUPDTM and this new
   Effective Dispatch LCPUEDTM is the CPU time that this partition was
   dispatched for the LPAR management of this partition.

   In addition to this LPAR management time for each partition, there is
   a new "psedo" partition named "PHYSICAL" that exists only in the RMF
   type 70 record and which creates a separate observation in TYPE70PR.
   This observation with LPARNAME='PHYSICAL' contains only LCPUPDTM,
   which records the additional LPAR management CPU time that could not
   be charged to a specific partition.



               Total Partition Dispatch (CPU) Time
         (LCPUPDTM summed for all real partitions + PHYSICAL)


    ______________________________________________________________





        LPAR #1         LPAR #2        LPAR # 2       "PHYSICAL"
      LCPUPDTM        LCPUPDTM        LCPUPDTM         LCPUPDTM
    _______________ _______________ _______________ ______________

         LCPUEDTM        LCPUEDTM        LCPUEDTM
          LPAR1           LPAR2           LPAR3
         Effective       Effective       Effective




    __              __              __              ______________

     1               2               3                "Physical"

     In-partition LPAR Management Time               Other LPAR time




 The PR/SM "low utilization" affect has now been measured with these
 new fields.  While the LPAR management time may be 6-10% when the
 total LCPUPDTM busy is 60-70%, when the total busy is 95%+, the LPAR
 management decreases into the 2-3% range.  (Note, however, that the
 LPAR management time for a CAPPED partition is substantially higher).
 Most of all, now you can finally measure the LPAR management time!

 IBM's RMF reports will use the "Effective" dispatch time as the 100%
 CPU busy denominator (because then the LPAR numbers can be compared
 with non-PR/SM utilization numbers).

 Unrelated but included in this APAR, LCPUCAP identifies if
 Hard Capping is in effect, and LCPUCAPC identifies if there
 were any changes in the Hard Capping status.

c. Three new CPU times were added to SMF type 30 in MVS 3.1.0e, but were
   NOT added to RMF type 72 until MVS/ESA 4.2 (RMF 4.2.1).  RMF capture
   ratios decrease when you migrate from MVS/370 to MVS/ESA 3.1.0e, and
   then increase when you install MVS/ESA 4.2, but now they're right!

TYPE 70 (RMF-captured CPU measurement of real or logical CPUs):


    Elapsed Interval (Duration multiplied by number of CPUs)
 ________________________________________________________________


 ______________________________________________________ ---------
                      CPU                                  CPU
                    Executing                            Waiting


 ________ ________ _________ ________ ________ ________
  CPU 1    CPU 2    CPU 3     CPU 4    CPU 5    CPU 6
   Busy     Busy     Busy      Busy     Busy     Busy


 ______________________________________________________

 Total Hardware CPU Busy Time (from Type 70 "non-wait")


        (solid=captured      dashed=uncaptured)


 ______________________________________________________

 Total Hardware CPU Busy Time (from Type 70 "non-wait")

TYPE 72 (use only the control performance groups):

 ___________ ----- ----- _________________ ------------
  TCB   SRB   TCB   SRB   IIP   RCT   HPT  Uncapturable
  CPU   CPU   CPI   CPI   CPU   CPU   CPU      CPU

 _____ _____ ----- ----- _____ _____ _____ ------------
  RMF   RMF   Uncaptured  Captured in      Uncapturable
  TCB   SRB   Initiator    RMF 4.2.1         RMF CPU
  CPU   CPU   Privileged  Uncaptured in
                           RMF 4.1.2-4.2
 ___________ ------------_____ _____ _____ ------------
              Existed,    Existed,   New,  Uncapturable
   TCB+SRB    Uncaptured Moved from  was     RMF CPU
              by RMF but Uncaptured  RMF
              is in SMF.    to       TCB
                          Captured

 _____ _____     +       _____ _____ _____   = CPUTM, sum of 5.

TYPE 30 (all work started and ended):


 _____ _____ _____ _____ _____ _____ _____ ------------
  SMF   SMF   SMF   SMF   SMF   SMF   SMF  Uncapturable
  TCB   SRB   TCB   SRB   IIP   RCT   HPT      SMF
  CPU   CPU   CPI   CPI   CPU   CPU   CPU      CPU

 _____ _____ _____ _____ _____ _____ _____   = CPUTM, sum of 7.

d. Type 30 SMF record Step Hiperspace/Data Space Activity
   added several measures:

    HIPAGINS - Hiper Page Ins
    HIPAGOUT - Hiper Page Outs
    DSSIZHWM - Data Space/Hiperspace High Water Mark, Megabytes
               (if non-zero, identifies Data Space/Hiperspace user)
    CREADMIS - CREADS Missed in Hiperspace
    DIVRREAD - Address Space total Reread Count
    ABNDRSNC - ABEND reason code
    TERMNAME - Terminal Identification


e. Type 72 Performance Group CPU/paging/memory measures

 BLKSAUIN - Blocks paged in from Auxiliary DASD
 BLKSESIN - Blocks paged in from ESTORE
 HIPPGINS - Hiperspace Page Ins from Aux DASD
 HIPRDMIS - Hiperspace Read Misses (CREADS in 30s)
 PGPAGEIN - Page Ins from Auxiliary DASD
 PAGEESIN - Page Ins from Expanded Storage
 PGBKESIN - Blocked pages paged in from ESTORE
 PGBKTOIN - Blocked pages paged in total (ESTORE+AUX)

 CPUHPTTM - Hiperspace CPU time               Actual times
 CPUIIPTM - I/O interrupt processing CPU      and not
 CPURCTTM - Region control task CPU time      service units!

 SYSTRNTM   System transaction time           point of entry
                                              until termination

 ACTFRMTM - Frame-seconds of CS+ES memory occupancy while tasks in
            this performance group period were "SRM Resident".
            This includes both Central Store and Expanded Store
            frames, but does not include Nucleus or Common Area
            (since they are not in an address space), and does
            NOT include frames of Logically Swapped ASIDs.

 ACTESFTM - Frame-seconds of ES memory occupancy while tasks in
            this performance group period were "SRM Resident".
            This is the ES part of ACTFRMTM.

 MSOUNITS - Represents frame-seconds of Central Store memory
            occupancy, but only while executing TCB.

 For example, assume:

     DURATM   = Duration of Interval           100 seconds
     RESIDTM  = Accumulated Residency Time     800 seconds
     ACTFRMTM = Central+ESTORE              80,000 frame-seconds
     ACTESFTM = ESTORE                      30,000 frame-seconds

 Then

     MPL  = (800/100) = 8 users are resident, on average.

     ES Frames = (30,000/100)        = 300 ES Frames (1.2 MB) used

     CS Frames = (80,000-30,000)/100 = 500 CS Frames (2 MB) used

Because
          ACTFRMTM
       (-------------)      = CS + ES frames used by perf group period
          DURATM


          ACTESFTM
       (-------------)      = ES frames used per user
          RESIDTM


          MSOUNITS
    (--------------------)  = TCB-only CS frames used per user
     50*MSOCOEFF*CPUTCBTM




f. New TYPE71 counts of blocked pages paged in, blocks in, PWSS size
   (primary working set size), pages migrated, and the number of
   ESTORE frames that were freed without migration:

         BLKSAUIN - Blocks paged in from AUX
         PGBKAUIN - Blocked pages paged in from AUX
         ESPGFRNO - ESTORE frames freed without migration
         PWSSMIIN - PWSS pages migrated from ESTORE

    TYPE71 contains four new swap reason codes, because MVS now has
    four additional reasons for swapping an address space:

      AW - APPC Wait swap, awaiting a Transactio Program.

      IC - Improve Central Storage usage swap, by recognizing
           page thrashing.

      IP - Improve System Paging Rate swap, identifies that
           your PTR controls are causing swaps.

      MR - Make Room to swap in a user who has been swapped
           out too long. When an Exchange Swap should have
           occurred, SRM starts a clock, defaults to 30 sec
           for TSO, 10 min for non-TSO, and will bring that
           task back in if it stays out that long.

  For each swap reason, there are five new variables for the swap rate
  of each possible transition (EXTAUX.., LOGAUX.., LOGEXT.., PHYAUX..,
  and PHYEXT..). The sum of all transitions for each swap reason,
  (i.e., the total swap rate for that reason code) is in the new
  variables SWAPIC, SWAPIP, and SWAPMR.

g. TYPE 71: Overall System Memory measurement in MVS/ESA:


 Area      Expanded Frames     Central ("Real") Frames
           Avg, Min, Max       Avg, Min, Max
           Measures            Measures

 CSA       CSAEXAV,MN,MX         n/a
 Hiper     HIPEXAV,MN,MX         n/a
 LPA       LPAEXAV,MN,MX         n/a
 LSQA      LSQAEXAV,MN,MX      LSQAREAV,MN,MX
 REG+SQA   REGSEXAV,MN,MX        n/a
 SQA       SQAEXAV,MN,MX       SQAREAV,MN,MX
 VIO       VIOEXAV,MN,MX         n/a


 Type      Pages           Pages             Pages
           Read            Written           Migrated
           From ESTORE     To ESTORE         To Aux

 Hiper     HIPREADS        HIPWRITS          HIPMIGRS
 VIO       VIOREADS        VIOWRITS          VIOMIGRS

 Total     EXTREADS

 Hiper page ins    HIPAGINS
 Hiper page outs   HIPAGOUT


h. Blocked/Unblocked Paging/Blocks summary.

Sequential I/O is always better (less CPU, less real memory, less
elapsed time) with blocks of logical records than unblocked records.
MVS/ESA 4.2 introduces "Blocking" (multiple pages in a block).  What we
knew as "pages" are now counted as "unblocked pages". The following
schematic tabulates the SMF suffix of measured/calculated counts in the
type 30  record:


 Type 30 IBM           Pages    Blocked    Blocks
                      (Unblkd)  Pages

   In
      from AUX         pia       BIA        KIA
      from ESTORE      PIE       BIE        KIE

   Out
      to   AUX         poa       BOA        KOA
      to   ESTORE      POE       BOE        KOE


 Type 30 MXG           Pages    Blocked    Blocks
                      (Unblkd)  Pages

   In
      from AUX         PAGEINS   PGBKAUIN   BLKSAUIN
      from ESTORE      PAGEESIN  PGBKESIN   BLKSESIN

   Out
      to   AUX         PAGEOUTS  PGBKAUOU   BLKSAUOU
      to   ESTORE      PAGEESOU  PGBKESOU   BLKSESOU

This next table shows the fields in the type 72, and as might be
expected, they contain only inbound paging activity.

 Type 72 MXG                         Pages    Blocked    Blocks
                                     (Unblkd)  Pages

   In from AUX                       pgpagein  PGBKAUIN   BLKSAUIN
   In from ESTORE                    PAGEESIN  PGBKESIN   BLKSESIN

The type 71, global paging, surprisingly contains only these new fields:

 Type 71 MXG                          Pages    Blocked    Blocks
                                     (Unblkd)  Pages

   In from AUX         total                   PGBKAUIN   BLKSAUIN
                       Hiperspace     hipagins
   In from ESTORE      Hiperspace     hipreads
   In from ESTORE      VIO            vioreads
   In from ESTORE      total          extreads

   Out to  AUX         Hiperspace     hipagout
   Out to  ESTORE      Hiperspace     hipwrits
   Out to  ESTORE      VIO            viowrits

   Migrates to AUX     Hiperspace     HIPMIGRS
   Migrates to AUX     VIO            VIOMIGRS


i. TYPE70PR  - PR/SM Processor Partition Data

Durations of partition

 DURATM     Duration of interval
 LCPUEDTM   Effective logical processor dispatch time
 LCPUPDTM   Logical processor dispatch time
 PRSMSLIC   Dispatch interval timeslice

Identification of partition

 LCPUADDR   Logical processor CPUID address
 LPARNAME   Logical partition name
 LPARNUM    Logical partition number

Status flags and numbers

 DIAG204F   Diagnose X204 failure?
 LCPUDED    Logical processor dedicated?
 LCPUWAIT   LPAR Wait Completion (Yes/No)?
 NRPRCHGD   Was the number of CPUs changed?
 PARTFLG    Was the Partition deactivated?
 SLICCHGD   PRSMSLIC Time-slice was changed?
 LCPUSHAR   Processor relative share
 LPARCPUS   Number of CPUs in this LPAR
 NRCPUS     Number of CPUs
 NRPRCS     Number of logical partitions
 PARTISHN   Partition number of this MVS
 PARTNCPU   Nr of CPUs available to this partition

Read ZZ05-0453-01 "PR/SM Performance in LPAR Mode" (IBM Internal, from
your IBM SE) for additional important PR/SM information.

j. TYPE72MN - RMF III Monitor subtype of type 72 record

MVS/ESA creates an RMF record from RMF Monitor III,
but only a small part of the data captured by RMF III
is written to SMF, for each Performance Group:

  User Statistics                Frame Statistics

  AVGUSER  - Logged On           FRAMEACT - Active Frames
  AVGACTS  - Active Users        FRAMEDIV - DIV Frames
  AVGACTV  - Active Not OUTR     FRAMEFIX - Fixed Frames
  AVGDIVS  - D-I-V Users         FRAMEIDL - Idle Frames
  AVGIDLS  - Idle Users

  Delayed Users Statistics       Miscellaneous

  AVGOUTR  - Out and Ready       FRAMEASM - Slots Used
  AVGPAGDL - Delayed Paging      PGINRATE - Page Ins
  AVGSWPDL - Delayed Swap        DOMAIN   - Domain
                                 PERFGRP  - Perf Group
  Averages of Averages

  WSETACT  - Avg working set per active user
  WSETASM  - Avg ASM slots used per user
  WSETDIV  - Avg working set per DIV user
  WSETFIX  - Avg fixed frames per user
  WSETIDL  - Avg working set per idle user


k. I/O Activity measurement, non-VSAM, VSAM, DASD, TAPE:

TYPE1415 Non-VSAM File, for each open of each file:

 DSSNO      Dataset serial number
 IDRC       3480 IDRC compaction used?
 NULLSEG    null segment encountered?
 PDSE       PDSE (formerly ILIB) managed data set?
 SMFCHITS   HiperBatch successful searches
 SMFCIOS    HiperBatch DASD I/Os copied into buffers
 SMFIOREQ   HiperBatch total searches
 SMFNMWTS   HiperBatch conflict suspends
 SMFPHIOS   HiperBatch searchs that caused DASD I/O
 TRUNC      TRUNC MACRO issued?

TYPE64 VSAM File, for each open of each file:

 ACBBUFND   BUFND - Number of Data Buffers
 ACBBUFNI   BUFNI - Number of Index Buffers
 ACBBUFSP   BUFSP - Buffer Space
 ACBMACR    MACRF flag bytes (Random, Seq, Input, Output, etc.)
 ACBSTRNO   STRNO - String number
 BUFDRNO    Actual number of buffers
 JCFBDSNM   Cluster Name
 PLHCNT     Actual number of concurrent strings
 SMF64HIT   HiperBatch successful searches
 SMF64IOS   HiperBatch DASD I/Os copied into buffers
 SMF64MIS   HiperBatch searches that caused DASD I/Os
 SMF64SIO   HiperBatch total searches
 SMF64WTS   HiperBatch conflict suspends

TYPE 21 Tape Volume Dismount

 BYTEREAD  Bytes read
 BYTEWRIT  Bytes written
 DCBOFLG   DCBOFLG control byte
 DEVICE    Device type
 OPEN      Type of OPEN
 TAPCUSER  Tape unit serial of creation device
 TAPUNSER  Tape unit serial of this device
 TEMPRBER  Temporary read backward errors
 TEMPRFER  Temporary read forware errors
 TEMPWRER  Temporary write (buffered) errors


TYPE74 DASD Volume Activity

 DASDRCFG - Number/Storage Group Options
 STORGRUP - Storage Group Name
 CUNAME   - Control unit name
 DEVMODEL - Device model name
 AVGPNDIR - Avg ms per I/O delay due to director port busy
 DLYDIRTM - Total seconds  delay due to director port busy
 PCTPNDIR - Percent of time when delayed due to director port busy.


l. RMF Monitor III Cross-System Coupling Facility (XCF) reports
 on message traffic between local system (where RMF executes)
 and remote systems creates four new TYPE74xx datasets:

TYPE74CO - control data

 R742MNXT - Member data sections in next records
 R742MTOT - Member data sections in all records
 R742PNXT - Path data sections in next record
 R742PTOT - Path data sections in all records
 R742SNXT - System data sections in next records
 R742STOT - System data sections in all records
 R742TSR  - Subtype 2 records in interval

TYPE74ME - member data

 R742MGRP - Group name
 R742MMEM - Member name
 R742MRCV - Signals received by member
 R742MSNT - Signals sent by member
 R742MSTF - Status flags
 R742MSYS - System name where member resides

TYPE74SY - system data

 R742SBIG - Number of "big message" conditions
 R742SBSY - Number of "no buffer" conditions
 R742SDIR - Direction of the message traffic
 R742SFIT - Number of "message fit" conditions
 R742SMXB - Maximum message buffer space
 R742SNME - System name
 R742SNOP - Number of "no path" conditions
 R742SOVR - Big messages that exceeded OPT message length
 R742SPTH - Signaling paths currently in service
 R742SSML - Number of "small message" condiions
 R742SSTF - Status flags
 R742STCL - Message length for transport class
 R742STCN - Transport class name

TYPE74PA - path data

 R742PAPP - Path was busy when selected to transfer
 R742PDEV - Device number
 R742PDIR - Direction path
 R742PIBR - Inbound signals refused due to max message limit
 R742PMXM - Maximum message buffer space
 R742PNME - System name
 R742PODV - Device number on other end
 R742PONA - Name of system on other end
 R742PQLN - Outbound signals pending transfer on path
 R742PRET - Path retry limit
 R742PRST - Number of restarts
 R742PSIG - Out/In bound signals sent/received over path
 R742PSTA - Path status
 R742PSTF - Status flags
 R742PSUS - Path not busy when slected to transfer '
 R742PTCN - Transport class name




m. DFP 3.2 Statistics and Configuration

TYPE 42 record contains 3 new subtypes that create five new datasets:

TYPE42AU "Audit" VARY SMS, ACTIVATE SMS, or ENF event occurrence, but
  is relatively unimportant:

 CURRTIME   Current update timestamp
 SMF42EAC   Activate, ENF, or VARY SMS?
 SMF42EAD   Active control dataset name
 SMF42ENS   New MVS volume status
 SMF42EOS   Old MVS volume status
 SMF42ERC   Return code
 SMF42ERS   Reason code
 SMF42ESD   Source control dataset name
 SMF42ESN   Name of storage group
 SMF42EST   Resulting status after action
 SMF42ESY   "ALL", or first 8 system names
 SMF42EUA   UCB address for the device
 SMF42EVL   Volume serial number


TYPE42CU Model 3990-3 Cache Control Unit Statistics,
 for each cache controller having an SMS volume attached.

 Identification and timestamps

 SMF42CID   Subsystem identifier
 CURRTIME   Current update timestamp
 LASTTIME   Last update timestamp

 Statistics during interval

 SMF42AFW   Average fast-write waits per minute
 SMF42AHR   Average hit ratio
 SMF42CCT   Current I/O count for the subsystem
 SMF42LCT   Last    I/O count for the subsystem
 SMF42CFW   Current fast write wait count
 SMF42LFW   Last    fast write wait count
 SMF42CRH   Current cache normal read hit percent
 SMF42LRH   Last    cache normal read hit percent
 SMF42CWM   Current fast write waits per minute
 SMF42LWM   Last    fast write waits per minute

 Storage capacity/availability

 SMF42CSS   Subsystem storage capacity
 SMF42NCS   Subsystem non-volatile storage status
 SMF42NSZ   Non-volatile cache capacity
 SMF42SAP   Storage allocated for PINNED data
 SMF42SCS   Storage director caching status
 SMF42SPR   Non-volatile storage allocated for PINNED
 SMF42SSA   Storage available for allocation as CACHE
 SMF42SSU   Storage unavailable due to failures

TYPE42VL Status for each SMS volume behind 3990-3

 CURRTIME   Current update timestamp
 SMF42CID   Subsystem identifier
 SMF42DB1   Device status flags one
 SMF42DB2   Device status flags two
 SMF42DEV   Device number
 SMF42VOL   Volume Serial Number

TYPE42SC Storage Class Buffer Manager Facility (BMF) Statistics
 for each Storage Class. (Interval set in IGDSMSxx).

 DURATM     Interval duration
 SMF42PNN   Storage Class Name
 SMF42SDH   Directory data page read hits
 SMF42SDT   Directory data page reads
 SMF42SRH   Member data page read hits
 SMF42SRT   Member data page reads
 STARTIME   Start timestamp of the interval

TYPE42TO Buffer Manager Facility (BMF) Totals for all Classes.

 DURATM     Interval duration
 SMF42LGE   Largest size of storage
 SMF42TDH   Directory data page read hits
 SMF42TDT   Directory data page reads
 SMF42TNA   Number of storage classes
 SMF42TRH   Member data page read hits
 SMF42TRT   Member data page reads
 STARTIME   Start timestamp of the interval

n. TYPE6 JES Printer Record Enhancements

Step identification of source of print

 SMF6DDNM   DDNAME that created printing
 SMF6DSNM   JES assigned temporary DSNAME of the print dataset
 SMF6PRNM   PROCSTEP that created printing
 SMF6STNM   STEPNAME that created printing
 SMF6USID   USERID that created printing
 SUBSYS6    Printing Subsystem (JES/PSF) used.
 SMF6PRMD   Processing mode (PAGE/LINE) of print.
 SMF6FDNM   FORMDEF name used
 SMF6PDNM   PAGEDEF name used
 SMF6PTDV   PRINTDEF name used

Print security identification

 SMF6NPS    Security page segments used
 SMF6NSFO   Security fonts used
 SMF6NSOL   Security overlays used
 SMF6OTOK   Output user security token
 SMF6SECS   Security label of print dataset

Enhanced SYSOUT Support, ESS. JES2 only, not PSF.
  (fields also added to type 24 and 57 SMF records).

 SMF6IND    ESS segment indicator
 SMF6JDVT   JCL definition table name in JDTV
 SMF6SGID   Segment identifier
 SMF6TU     Text unit (SWBTU) data area
 SMF6TUL    Text unit (SWBTU) data area langth

Yes/No Print Activity flags

 BINnUSED   BIN Number n was used?
 CONTRIN0   SPIN data set?
 CONTRIN1   Operator terminated print?
 CONTRIN2   Operator restarted print?
 CONTRIN3   Print intrepreted?
 CONTRIN4   Operator interrupted print?
 CONTRIN5   Print continuation?
 CONTRIN6   Operator overrode?
 CONTRIN7   Restart with destination?
 CONTRIN8   Received operator restart?
 CONTRIN9   Operator started single space?
 DIADPLWS   Data page labelling suppressed?
 DIAJHWP    Job trailer page printed?
 DIASLIG    Job header page printed?
 DIAUPAWS   User print are suppressed?
 DPAGELBL   Keyword DPAGELBL=YES?
 ERROVRUN   Image overrun error?
 ERRSECOV   Error in security overlay?
 INTEGRTY   Security label integrity?
 PRSUCCES   Print operation successful?
 SPAGELBL   Keyword SPAGELBL=YES?
 STDUPLEX   Standard duplex used?
 SYSAREA    Keyword SYSAREA=YES?
 TMBUPLEX   Tumble duplex used?

o. Data-In-Virtual (DIV) and Virtual Lookaside Facility (VLF):

TYPE41AC (DIV Accessed) and TYPE41UN (DIV Unaccessed)

Common to both Access and Unaccess

 ACCSTIME   Time when object was accessed
 DDNAME     DDNAME used
 JOB        Job name or TSO user accessing
 OBJMODE    Access mode (Read/Update)
 OBJSIZEA   Object size (blocks) when accessed
 OBJTYPE    Object type (DA)

Additional data at Unaccess in TYPE41UN

 IOCALREA   Total I/O calls for read
 IOCALWRT   Total I/O calls for write
 OBJSIZEU   Object size (blocks) when unaccessed
 TOTREADS   Total blocks read (including rereads)
 TOTRREAD   Total blocks re-read
 TOTWRITE   Total blocks written
 UACCTIME   Time when object was unaccessed

TYPE41VF Virtual Lookaside Facility (VLF) statistics

APARs OY28799 and OY288800 for MVS/ESA create a
 type 41 subtype 3 interval (15 min) record for
 each class in the COFVLFxx PARMLIB member.


 SMF41CLS   Class name
 SMF41SRC   Times cache was searched
 VLFHITPC   Percent of searches found in VLF

 SMF41ADD   Objects added to cache during interval
 SMF41DEL   Objects deleted from cache
 SMF41FND   Objects found in cache
 SMF41TRM   Objects trimmed from cache

 SMF41LRG   Largest object ever attempted
 SMF41MVT   MAXVIRT specified
 SMF41USD   Amound of storage used


 R. Shannon of Aetna pointed out that the LLA's use of VLF causes
 type 41 data to report LLA's utilization near 100%, but LLA still
 adds modules, because LLA only calls VLF for modules that LLA had
 previously cached.  Additionally, the storage used reported by
 VLF is not the high-watermark, but is the end of interval value.

 SMF records can be created from the CSVLLIX1 exit to provide the
 detail fetch statistics, but (too?) many records are created.

p. Structural changes in SMF writer recording and SMF management.

   Control Interval of SMF VSAM data set can be 22K (finally!!!). This
   change is in ESA 3.1.3.  SMF initially now gets 259 buffers (CIs) at
   startup. If CIsize is 4K, thats only 1MB, but with recommended 22K
   CIsize, 22K*259=6MB and thus SMF address space must be 6MB. If SMF
   needs more buffers, they are above the line to a maximum of 32MB.

   SMF internal buffers can be reclaimed from a SYSMDUMP, SVCDUMP or a
   Standalone dump with IPCS SMFDATA command into a VSAM dataset.

   Buffer shortage msg at 80% redisplayed if increases, deleted at 70%.
    Gets 200 more buffers (CIs) up to 4000 buffers (=32MB)
    The percentage number does not decrease as buffers are freed.
   SMF Exits can use 31-bit addressing AMODE(31). Callers in Cross mem
   can now call SMF (MODE=XMEM on SMFEWTM). New IEFU85 exit exists.
   LASTDS options in SMF PARMLIB controls SMF when last SMF dataset full
    MSG  - send message, start buffering data (default)
    HALT - put system in restartable WAIT STATE ('D0D-01')
   NOBUFFS options in SMF PARMLIB when internal buffers fill
    MSG  - send message and enter data lost mode (default)
    HALT - put system in restartable WAIT STATE ('D0D-00')
   Type 4, 5, 34, and 35s are dead.
    Flags are set when data is not in thes records and 30s must be used:
      CPUWRONG to "Y" if TCB time has overflowed
      EXCPLOST to "Y" if over 1635 DD statements
      IBM's ESA SMF manual now states:
       "Only the type 30 record should be considered valid."
   MSS (Mass Storage System) device is no longer.

 What happens when SMF records suddenly fill SMF?

 A site had 450 CYL of 3380 for all SMF data sets, enough for their
 full day's data.  When they migrated to MVS/ESA 4.1.0, SMF datasets
 filled at 3:15pm.  Ninety minutes later, the SMF buffers filled and
 recording stopped.  (ESA buffering gave the operator 1.5 hours)!

 An increased number of SMF type 60 for Non-VSAM Record "NVR" updates
 (added by SMS/DFP 3.2, because now ALL data sets, VSAM and non-VSAM
 must be in the VVDS) is thought to be the cause, but because the site
 lost all SMF data it's not proven.  The site did turn off the type 60s
 and the problem has not recurred.  The only use of the 60s data that I
 know of are third-party products to re-build a broken VVDS.  No IBM
 utility uses type 60s.  If you do not have such a product, it is my
 suggestion that you not record type 60 SMF records, because I have not
 found them needed for analysis, nor do I know of anyone who has used
 them.  If anyone has ever found the type 60s useful, please contact me.
 If no one replies, I will change my suggestion to a recommendation.

 In 90 minutes the site filled the 32MB (fixed maximum) ESA buffers, or
 only 6213 bytes per second were being moved from your address space to
 the SMF address space for eventual (asynchronous) writing to DASD. With
 an SMF CI size of 22K, this is a physical write to DASD every 4 seconds

    or only about 15 I/Os per MINUTE !!!!!!!!!!!!

    to a device capable of 40 I/Os per SECOND !!!!

 Again, this should prove that the SMF writer and SMF data sets are NOT
 stressed, that the SMF data sets do NOT require special treatment, and
 SMF data volume does not cause performance degredation.

q. System Managed Storage, SMS, extensions.

  System  Managed  Storage  (SMS)  now uses formerly reserved bits
  located at offset '4E'x  in  the  DSCB1  in  your  VTOCs.   DASD
  products  like  DMS/OS  and ASM2 have used these bits, and local
  modifications (to CSECTS IFG0196W and IFG0194E) have also caused
  this  "DSCB  Contamination".IBM published "Clean up VTOCs Before
  Implementing DFP V3"(as WSC Flash 9009, Hone Entry  G022345)  to
  advise you of the exposure.  If DSCB contamination is found, you
  must not only clean the VTOCs of your online data sets, but  you
  will need to also clean all migrated datasets, since their DSCBs
  were also migrated and your  migration  software  will  need  to
  correct the contamination when datasets are recalled.

  These new SMS variables are contained in DASD VTOCs:

  DS1CRSDB  DADSM Create originated blocksize?
  DS1PDSE   PDSE Managed Dataset?
  DS1REBLK  Data set may be reblocked?
  DS1SCCPF  Secondary is compacted by factor of 1, 256, 65536?
  DS1SECUN  units of allocation (avblk,bytes,kilo,mbytes A/B/K/M)
  DS1SCXTV  Secondary space extension value
  DS1SMSDS  System managed dataset?
  DS1SMSUC  No BCS entry exists for data set?
  OFFSET4E  Offset 4E into DSCB1 (used by SMS)

DCOLLECT is a new IDCAMS facility, that creates a flat file with
seven different records containing VTOC, VVDS, and HSM measures.
While DCOLLECT does not include 100% of the raw records, it can
avoid reading the VVDSs and VTOCs, which are now defined by IBM
as "product-sensitive programming interfaces", meaning that the
format and content of data records can change from release to
release.

  Eg., a VVDS cannot be casually allocated, and an authorized
  ASM program is required to capture VVDS data into SMF).

DCOLLECT records are part of the SAA preferred type of data that IBM
now calls a "general-use  programming interface".

IBM documentation for the records produced by DCOLLECT is spread across
several manuals. GC24-3540-00, "DFSMS Planning and Reporting" overviews.

Three datasets, DCOLDSNS (data sets), DCOLVOLS (volumes) and
DCOLCLUS (VVDS), are built from VTOC/VVDS information, and their
contents are described in Appendix E of DFP 3.2 "Access Method
Services for Integrated Catalog Facility", SC26-4562-1.

Four datasets, DCOLMIGS (migrations), DCOLBKUP (backup), DCOLCAPD
and DCOLCAPT (HSM tapes) are HSM-related and they are described
(poorly, DCOLLECT is not even cited in the table of contents nor
in the index) in Chapter 17 (User Application Interfaces) of
SH35-0084-4, "DFHSM 2.5.0 Installation and Customization Guide".



DCOLBKUP

   Variable Type Length  Format       Label

   DCUSYSID  CHAR   4              SYSTEM*ID
   DCUTMSTP  NUM    8 DATETIME21.2 DCOLLECT*RECORD*TIME STAMP
   UBDATCL   CHAR  30              DATA CLASS NAME
   UBDCLNG   NUM    4              DATA CLASS LENGTH
   UBDEVCL   CHAR   1              DASD*OR*TAPE?
   UBDSIZE   NUM    4              MIGRATED COPY*DATA SET SIZE
   UBDSNAM   CHAR  44              USER*DATASET*NAME
   UBMCLNG   NUM    4              MANAGEMENT CLASS LENGTH
   UBMGTCL   CHAR  30              MANAGEMENT CLASS NAME
   UBSCLNG   NUM    4              STORAGE CLASS LENGTH
   UBSTGCL   CHAR  30              STORAGE CLASS NAME
   UBTIME    NUM    8 DATETIME21.2 MIGRATED*DATETIME*STAMP

DCOLCAPD

   DCUSYSID  CHAR   4              SYSTEM*ID
   DCUTMSTP  NUM    8 DATETIME21.2 DCOLLECT*RECORD*TIME STAMP
   UCAFOCC   NUM    4              OCCUPANCY OF*VOLUME AFTER*PROCESSING
   UCBFOCC   NUM    4              OCCUPANCY OF*VOLUME BEFORE*PROCESSING
   UCCOLDT   NUM    4              JULIAN DATE*WHEN DATA*WAS COLLECTED
   UCINTVM   NUM    4              TARGET OCCUPANCY*WAS MET*FOR VOLUME
   UCLEVEL   NUM    4              LEVEL*OF*VOLUME
   UCNINTV   NUM    4              INTERVAL*MIGRATIONS*RUN AGAINST VOLUM
   UCNOMIG   NUM    4              PCT NOT MIGRATED*BUT ELIGIBLE*TO MIGR
   UCTGOCC   NUM    4              SPECIFIED TARGET*OCCUPANCY*OF VOLUME
   UCTOTAL   NUM    4              TOTAL*CAPACITY*OF VOLUME
   UCTROCC   NUM    4              SPECIFIED TRIGGER*OCCUPANCY*OF VOLUME
   UCVOLSR   CHAR   6              VOLUME*SERIAL

DCOLCAPT

   Variable Type Length  Format       Label

   DCUSYSID  CHAR   4              SYSTEM*ID
   DCUTMSTP  NUM    8 DATETIME21.2 DCOLLECT*RECORD*TIME STAMP
   UCEMPTY   NUM    4              NUMBER OF*EMPTY TAPE*VOLUMES
   UTFULL    NUM    4              NUMBER OF*FULL TAPE*VOLUMES
   UTPART    NUM    4              NUMBER OF*PARTIALLY FILLED*VOLUMES
   UTSTYPE   CHAR   1              TYPE OF*TAPE CAPACITY*PLANNING RECORD


DCOLCLUS

   DCAASSOC  CHAR  44              CLUSTER*NAME
   DCACMPNT  CHAR   1              DATA OR*INDEX*COMPONENT?
   DCADSNAM  CHAR  44              DATASET*NAME
   DCAFLAG1  CHAR   1 HEX2.0       TYPE*FLAG
   DCAFLAG2  CHAR   1 HEX2.0       STATUS*FLAG
   DCAIXUPG  CHAR   1              ALTERNATE*INDEX WITH*UPGRADE?
   DCAKR1ST  CHAR   1              1ST SEGMENT*OF KR*DATA SET?
   DCATYPE   CHAR   4              ENTRY*TYPE
   DCUSYSID  CHAR   4              SYSTEM*ID
   DCUTMSTP  NUM    8 DATETIME21.2 DCOLLECT*RECORD*TIME STAMP

DCOLDSET

   DCDALLSP  NUM    4 MGBYTES5.0   ALLOCATED*SPACE*(MGBYTES)
   DCDBKLNG  NUM    4              BLOCK*SIZE
   DCDCHIND  CHAR   1              CHANGE*INDICATOR?
   DCDCREDT  NUM    4 DATE9.0      CREATE*DATE*(SAS DATE)
   DCDDATCL  CHAR  30              DATA*CLASS
   DCDDCLNG  NUM    4              DATA*CLASS*LENGTH
   DCDDSNAM  CHAR  44              DATASET*NAME
   DCDDSORG  CHAR   2              DSORG
   DCDDSSER  CHAR   6              DATASET*SERIAL*NUMBER
   DCDEMNGD  CHAR   1              SMS*MANAGED*INCONSISTENCY?
   DCDERROR  CHAR   1 HEX2.0       ERROR*FLAG
   DCDEXPDT  NUM    4 DATE9.0      EXPIRE*DATE*(SAS DATE)
   DCDFLAG1  CHAR   1 HEX2.0       STATUS*FLAG
   DCDFLAG2  CHAR   1 HEX2.0       CATLG*FLAG
   DCDGDS    CHAR   1              GDG*DATA*SET?
   DCDINICF  CHAR   1              DATA SET*IS CATALOGED*IN ICF?
   DCDINTCG  CHAR   1              DATA SET*IS AN ICF*CATALOG?
   DCDLBKDT  CHAR   8              LAST*BACKUP*DATE
   DCDLRECL  NUM    4              RECORD*SIZE
   DCDLSTRF  NUM    4 DATE9.0      LAST*REFERENCED*DATE (SAS DATE)
   DCDMCLNG  NUM    4              MANAGEMENT*CLASS*LENGTH
   DCDMGTCL  CHAR  30              MANAGEMENT*CLASS*NAME
   DCDNMBLK  NUM    4 MGBYTES5.0   UNUSEABLE*SPACE IN*BLOCKS(MGBYTES)
   DCDNMEXT  NUM    4              NUMBER*OF*EXTENTS
   DCDNOFM1  CHAR   1              NO FMT 1*DSCB FOR*THIS DATASET?
   DCDNOSPC  CHAR   1              NO SPACE*INFORMATION*PROVIDED?
   DCDNOVVR  CHAR   1              NO VVR*FOR THIS*DATA SET?
   DCDPDSE   CHAR   1              PDSE*EXTENDED?
   DCDRACFD  CHAR   1              DATA SET*IS RACF*DEFINED?
   DCDREBLK  CHAR   1              DATA SET*MAY BE*REBLOCKED?
   DCDRECFA  CHAR   1              ANSI*CONTROL*CHARACTER?
   DCDRECFB  CHAR   1              BLOCKED*RECORDS?
   DCDRECFC  CHAR   1              MACINE CONTROL*CHARACTER?
   DCDRECFF  CHAR   1              FIXED*LENGTH*RECORDS?
   DCDRECFS  CHAR   1              STANDARD*BLOCKS(F) OR*SPANNED(V)?
   DCDRECFT  CHAR   1              TRACK*OVERFLOW?
   DCDRECFU  CHAR   1              UNDEFINED*LENGTH*RECORDS?
   DCDRECFV  CHAR   1              VARIABLE*LENGTH*RECORDS?
   DCDSCALL  NUM    4 MGBYTES5.0   SECONDARY*ALLOCATION*(MGBYTES)
   DCDSCLNG  NUM    4              STORAGE*CLASS*LENGTH
   DCDSGLNG  NUM    4              STORAGE*GROUP*LENGTH
   DCDSMSM   CHAR   1              SMS-MANAGED*DATA*SET?
   DCDSTGCL  CHAR  30              STORAGE*CLASS
   DCDSTGRP  CHAR  30              STORAGE*GROUP*NAME
   DCDTEMP   CHAR   1              TEMPORARY*DATA*SET?
   DCDUSESP  NUM    4 MGBYTES5.0   USED*SPACE*(MGBYTES)
   DCDVOLSQ  NUM    4              VOLUME*SEQ
   DCDVOLSR  CHAR   6              VOLSER
   DCDVSAMI  CHAR   1              VSAM*INDICATORS*INCONSISTENT?
   DCUSYSID  CHAR   4              SYSTEM*ID
   DCUTMSTP  NUM    8 DATETIME21.2 DCOLLECT*RECORD*TIME STAMP
   ORGEXPDT  NUM    4              ORIGINAL*JULIAN*EXPDT


DCOLMIGS

   DCUSYSID  CHAR   4              SYSTEM*ID
   DCUTMSTP  NUM    8 DATETIME21.2 DCOLLECT*RECORD*TIME STAMP
   UMDATCL   CHAR  30              DATA CLASS NAME
   UMDCLNG   NUM    4              DATA CLASS LENGTH
   UMDEVCL   CHAR   1              DASD*OR*TAPE?
   UMDSIZE   NUM    4 MGBYTES5.0   MIGRATED COPY*DATA SET SIZE*(MGBYTES)
   UMDSNAM   CHAR  44              USER*DATASET*NAME
   UMLEVEL   NUM    4              CURRENTLY*MIGRATED*LEVEL
   UMMCLNG   NUM    4              MANAGEMENT CLASS LENGTH
   UMMGTCL   CHAR  30              MANAGEMENT CLASS NAME
   UMSCLNG   NUM    4              STORAGE CLASS LENGTH
   UMSTGCL   CHAR  30              STORAGE CLASS NAME
   UMTIME    NUM    8 DATETIME21.2 MIGRATED*DATETIME*STAMP

DCOLVOLS

   DCUSYSID  CHAR   4              SYSTEM*ID
   DCUTMSTP  NUM    8 DATETIME21.2 DCOLLECT*RECORD*TIME STAMP
   DCVALLOC  NUM    4 MGBYTES5.0   ALLOCATED*SPACE*(MGBYTES)
   DCVDVNUM  NUM    4 HEX3.0       DEVICE*NUMBER
   DCVDVTYP  CHAR   8              DEVICE*TYPE
   DCVEBYTK  CHAR   1              ERROR*CALCULATING*BYTES/TRACK?
   DCVELSPC  CHAR   1              ERROR*DURING LSPACE*PROCESSING?
   DCVERROR  CHAR   1 HEX2.0       ERROR*FLAG
   DCVEVLCP  CHAR   1              ERROR*CALCULATING*VOL CAPACITY?
   DCVFDSCB  NUM    4              FREE*DSCBS
   DCVFLAG1  CHAR   1 HEX2.0       VOLUME*STATUS
   DCVFRAG1  NUM    4              FRAG*INDEX
   DCVFRESP  NUM    4 MGBYTES5.0   FREE*SPACE*(MGBYTES)
   DCVFREXT  NUM    4              FREE*EXTENTS
   DCVFVIRS  NUM    4              FREE*VIRS
   DCVINITL  CHAR   1              IN CONVERSION TO SMS?
   DCVINXEN  CHAR   1              INDEXED VTOC ENABLED?
   DCVINXEX  CHAR   1              INDEXED VTOC EXISTS?
   DCVLGEXT  NUM    4 MGBYTES5.0   LARGEST*EXTENT*(MGBYTES)
   DCVMANGD  CHAR   1              VOLUME IS MANAGED BY SMS?
   DCVNMNGD  CHAR   1              NON-SMS MANAGED VOLUME?
   DCVPERCT  NUM    4              PERCENT*FREE*SPACE
   DCVSGLNG  NUM    4              STORGRUP*LENGTH
   DCVSGTCL  CHAR  30              STORGRUP
   DCVSHRDS  CHAR   1              DEVICE*IS*SHAREABLE?
   DCVUSPUB  CHAR   1              USE*ATTRIB*PUBLIC?
   DCVUSPVT  CHAR   1              USE*ATTRIB*PRIVATE?
   DCVUSSTO  CHAR   1              USE*ATTRIB*STORAGE?
   DCVVLCAP  NUM    4 MGBYTES5.0   TOTAL SPACE*ON VOLUME*(MGBYTES)
   DCVVOLSR  CHAR   6              VOLSER

r. APPC Accounting and Capacity Planning

  i.   OVERVIEW of APPC

  Advanced Program-to-Program Communications/MVS (APPC/MVS) is the
  MVS support for cooperative processing.

  Two "peers" communicate using APPC/MVS services called "TP"s, or
  transaction programs. Each MVS TP executes in its own ASID.

  The interaction between two TPs (eg., a host TP and an OS/2 TP)
  is called a conversation.

  Each "peer" is called a partner in the conversation.

  Once a conversation is established, the actual work consists of
  sending or receiving data to or from the other partner.

  The partner identification is the LUNAME (the VTAM "port" name
  thru which communications flow). The requesting partner may be
  "remote" to MVS (an OS/2 program), or "local" (TSO user or job).
  The "partner" LU name is for the REQUESTOR of the TP, while the
  "local" LU name is for the TP itself.

  Two new address spaces execute for  APPC/MVS:
   "ASCH" the APPC Scheduler, and "APPC", the VTAM interface.


  ii.  APPC resources captured in type 30 (ASID) record.

  Type 30 records contain eight new variables that capture the APPC
  activity by any address space that is an APPC TP:

     APPCATR   Transactions scheduled by ASCH
     APPCCN    Total conversations (active plus deallocated)
     APPCCNA   Number of all conversation allocated
     APPCDAR   Bytes of data received by the TP
     APPCDAT   Bytes of data sent by the TP
     APPCREC   Receive calls issued by TP
     APPCSEN   Send calls issued by TP
     APPCTAC   Number of active conversations

  SMF type 30 records will be written for the TP Address space,
  the ASCH and APPC address spaces, and the MVS partner address
  space (for step/job CPU, I/O, etc.). As the ASCH and APPC ASIDs
  do not actually "use" APPC, their APPC.... variables are zero.

  iii. New SMF type 33 APPC/MVS TP Accounting record.

    Each APPC event is recorded in a type 33 accounting record with
    contains the same APPC counters that are summarized in type
    30s.  Additional timestamps of the receipt, scheduling and
    execution of the TP are provided, as are CPU times (only TCB and
    SRB), I/O connect time and EXCP counts are captured:

   ACCOUNTn - Accounting field (nth)
   APPCCN   - Number of conversations for this TP'
   APPCCNA  - Conversations allocated by this TP'
   APPCDARS - Bytes received by this TP '
   APPCDATS - Bytes sent by this TP '
   APPCRECV - Received issued by this TP'
   APPCSEND - Sends issued by this TP '
   CPUSRBTM - CPU SRB duration
   CPUTCBTM - CPU TCB duration
   ELAPSTM  - Elapsed duration
   EXCPTOTL - EXCPS for this TP'
   INPREQTM - Input request duration
   IOTMTOTL - Device connect duration
   LENACCTn - Length of nth accounting field
   LOCLLUNM - Local LU name for this TP
   NRACCTFL - Number of accounting fields
   PARTLUNM - Nodename LU Name of partner
   QUEUETM  - SCHEDULER*QUEUE*DURATION'
   RACFGRUP - RACF group identification       <---- requestor
   RACFUSER - RACF user identification        <----    "
   REQDTIME - Request recognized by FMH-5
   SKEDTIME - Request placed on scheduler queue
   SMFTIME  - Datetimestamp when SMF record was buffered
   SYSTEM   - SMF system ID
   TPCLASS  - TP class
   TPNAME   - TP name
   TPNDTIME - TP execution ended datetimestamp
   TPROFILE - TP profile name
   TPSKEDTY - TP scheduler type (standard/multi-trans)
   TPSTTIME - TP execution started datetimestamp
   TPUSECNT - Uses of this TP by this user
   TPUSRTYP - TP user type (shell/user)
   ZDATE    - Zee date Zee obs was put in Zee PDB.

  iv.  The intervals between the four scheduling timestamps give this
       picture of the events in the lifetime of an APPC task.


           INPREQTM      QUEUETM         ELAPSTM

           Waiting on    Waiting on      Executing
           Scheduler     TP queue
         _____________ _______________ ____________

     REQDTIME      SKEDTIME       TPSTTIME      TPENTIME

     Request       Placed on      Execution     Execution
     Received      TP's queue     Started       Ended

 A  "Standard"  TP  is  initialized  for each inbound conversation
 request and terminated at end of its processing.   Resources  are
 allocated and deallocated for each inbound conversation request.

 A "Multi-trans" TP remains active  between  inbound  conversation
 requests,  with  its  resources  already  allocated.   Subsequent
 requests  avoid  the  overhead   of   repeated   allocation   and
 deallocation.

 Initialization and termination processing for a multi-trans TP is
 typically performed by the "Multi-trans Shell", surrounding the
 part of the TP that holds conversations.

 Separate type 33 records are written for "Shell" and "User".

 The scheduler timestamps do not exist in the "Shell" record, but
 CPU time and resources are captured in the type 33 shell data.

 If  the  "Type  of  User"  flag  is  'shell' (the other choice is
 'regular'), then this is the 'shell' record, and  the  "user  id"
 field is the ID if the "generic" user.

 The  "requestor"  of the APPC work is identified by the "user ID"
 and "group ID" pair of fields.  Most APPC work will  likely  come
 from a PC or a network, and not a TSO user or Batch job.

 APPC transaction programs can bypass the IEFUAV accounting exit
 by specifying TAILOR_ACCOUNT(NO) or by NOT specifying (YES).
 Watch this integrity exposure that would allow a TP program to
 disable its account validation!   Read  "The  Cuckoo's Egg"!


  v.   Schematic representation of type 30 / 33 SMF records and their
       subtypes for a multi-trans TP with shell:

 -->  Start     GET     GET    GET    RET    GET    GET   RET  End
       __________________________________________________________


       __________________________________________________________
SMF 30
for   -1                           -2                           -3
TP    init                       interval                       -4
                                                                -5
                                                              term

SMF 33  _________                       ______              _____
for
shell           -1                           -1                 -1

SMF 33            _______ _______ _____        ______ ______
for
user                    -1      -1    -1            -1     -1
                                            /         \
                                           /           \
                                          /             \
                                         /               \
              Waiting on    Waiting on       Executing
Type 33       Scheduler     TP queue
Scheduling   ____________ ______________ _________________
Timestamps
          Request      Placed on      Execution         Execution
          Received     TP's queue      Started           Ended

 This shows the three type 33's due to shell and the five type 33s
 due to user  GET  activity. The final RET in the schematic can be
 a real RET, but if the TP depends on the expiration of the "wait"
 time for the GETTRANS, then there is a "logical" RETTRANS done on
 its behalf.

   When a multi-trans TP is ready to run a user request, it issues
   a "GET-Transaction" GETTRANS to ASCH scheduler.

   When a multi-trans TP shell does processing not directly related
   to a user request it issues a "RETURN-Transaction" RETTRANS.

APPC conversation counts in SMF 30 and 33 are categorized:

 APPCCN  - Total conversations for this TP, both currently active
           and deallocated. Count of all conversations that this
           TP is involved in (both OUTbound and INbound).

 APPCCNA - Total conversations ALLOCATED by this TP. The number of
           OUTbound conversations that this TP has requested.

 APPCTAC - Total active conversations that are still "open" when
           the record was created.  Will always be zero in step
           or job termination record, wince by the end of step,
           all conversations are closed.

 APPCATR - Total transactions scheduled by ASCH (type 30 only).
           This equals the total count of type 33 records that
           will/could have been written.


  vi.  APPC Changes to TYPETASK, JESNR, & JCTJOBID may affect analysis.

  SMF type 6,30,32,26, and 57 records contain the JCTJOBID field,
  (named SMFnnJNM) that decodes into TYPETASK (JOB,STC,TSU) and
  the five digit JESNR of the address space.

  For APPC address spaces, the JCTJOBID contains an "A" followed
  by a seven digit "JESNR", creating a TYPETASK of "A  ".

  This could cause your reporting programs to fail, if they use
  TYPETASK for selection and did not protect for new values or
  for seven-digit JES numbers.

  This could also impact any "banner page" statistics written to
  a job's SYSLOG from your IEFU83, IEFU84, and IEFU85 SMF exists.

  vii. APPC support added APPC address space statistics to TYPE70.

       APPC address spaces active (i.e., in initiation) are in
       APPCMIN, APPCMAX, and APPCAVG, and with twelve buckets
       APPC00-APPC11 that contain the percentage of time when 0,
       1-3, 4-6, ... >36 APPC ASIDs were active, just like the
       existing statistics and buckets for BAT, TSU, and STC
       address spaces.

III. VM  Technical Notes.

  1. SHARE 76 Paper "VM/ESA Measurement Facilities"


                    H.  W.  Barry Merrill, PhD
                       President-Programmer
                       Merrill Consultants
                       Dallas, Texas 75229

     Portions of this paper were presented/published at/in:

            SHARE 76 San Francicso, CA Feb 27, 1991.
            MXG Newsletter NINETEEN    Apr  8, 1991.


   VM/ESA changed the output data records from MONWRITE with new data
   fields and new records, but because the changes were implemented
   by IBM in a fully compatible manner, previous versions of your VM/XA
   analysis software will not fail when they process the VM/ESA 1.1.0
   (ESA Feature) records. This paper discusses the new measures, the
   new file server measures captured in the new MONWRITE Application
   Interface record, and snapshots a benchmark of a VM/ESA (ESA Feature)
   MONWRITE interval on a 3090/600 with 4,800 logged on CMS users.

a.   Fifteen existing datasets (records) that have new data values:

VM/ESA (ESA Feature) Monitor data is an enhanced version of VM/XA data,
with the same names for datasets, variables and IBM fields, so you will
have nothing to change in your reports until you want the new data.


VXSYTXSP    New variables PLSPGMRD,PLSPGMRX,PLSPGXRD,PLSPGXWT added with
            page reads/writes to/from ESTORE/AUX due to page. This is
            translations/migrations. This is an interval record.

VXSYTASG    SALPRFAV,SALPRFIU are now reserved (were Preferred Paging),
            new variables for page/spool average/total MLOAD value:
            CALTOTM1,M2, CALAVGM1,M2). Interval.

VXSYTCOM    New variable count IUCVs (good to/from, and bad to the
            services: SYSTEM, CRM ACCOUNT,LOGREC,IDENT,CONFIG, and SPL.
            Twenty-one counters:  PLSIS+{E,T,U}+{SY,CR,AC,LO,ID,CF,SP}.

VXMTREPR    New flag if Application Domain Event is active, and CONFIG
            time limit variable.

VXMTRPAG    DDIPREF now reserved (Pref. Paging Flag) DDIPPCYL renamed
            RDCPCYL, and RDEVSID, Host Subchannel ID was added.

VXMTRSPR    New flag if Application Domain Sample is active, and CONFIG
            time limit variable.

VXMTRSCH    New SRMWSSMP for SET SRM MAXWSS value.

VXSCHDDL    New VMDLRGST if user prempted for storage.

VXSCLSRM    New SRMWSSMP for SET SRM MAXWSS value, New SRMWSSMP for SET
            SRM MAXWSS value, and VMDSCDF1 was replaced with VMCQDSPU.

VXSTORSG    New CALASCRT,CALASCFT,CALASCUT for paging virtual segment
            control (reorgs, unused and used pages).

VXSTORSP    New PLSPGDRD,PLSPGDWT for page tables paged to/from
            auxiliary storage.

VXSTOASP    New EXPDEVST,EXPMLOAD,CPVLOKAT,CPVALOCD with paging device
            service time, MLOAD, scans for allocations, actual
            allocations, and twenty EXPCON01-EXPCON20 tabulating how
            many times that many contiguous slots were available.

VXSTOATC    DDIPREF now reserved, CALPAGCY renamed to RDCPCYL, and
            RDEVSID added.

VXUSEACT    VMDCTPPS (Pref Page Slots) deleted.

VXIODCAD    New CALPSF data for 3990-3 status bytes.

b.  Five new records create these new datasets:

VXSTOASS    Auxiliary Shared Storage Sample Data record describing
            resources from the CP-owining a shared volume (PAGE/SPOOL
            READs/WRITES, queue length, and SSCH+RSCH counts).

VXIODATS    Attach Shared Device Event Data record, which contains
            exactly the same data as the existing VXIODATD Attach
            (non-shared) Device dataset.

VXAPLEDT    Application Event Data record, with a variable length string
            of installation/application created event data, domain 10
            record 1.  No IBM application currently uses this new event
            data interface.

VXAPLSDT    Application Sample Data record with a variable length string
            of installation/application created interval data, domain 10
            record 2.  IBM applications do now use this new interface
            but they are recognized by MXG and create the new VXAPLSRV
            dataset described below.

VXAPLSRV    IBM's use of Application Sample Data to record "Server
            Monitor Records". Both SFS file pool servers and CRR
            recovery servers use the APPLDATA class call to provide 123
            counters or clocks that are listed below. MXG converts all
            counters to rates per second (which are, by an MXG
            convention, formatted 7.1 to so indicate that they are
            rates), but the clocks are kept in units of seconds during
            the sample interval (and formated TIME12.2 to so indicate).
            The VMDUSER (VM User ID) must be used to identify which
            server created the application data:

              Server-ID     Observation contains

              VMSERVR       CRR (Counters 103-116 are only
                                 for CRR, and 114 will be
                                 always non-zero if CRR).
              VMSERVS       SFS (System owned file pool)
              VMSERVU       User (User owned file pool)

            The following list of variables created from
            these servers using the new application data
            interface clearly is a major enhancment in
            the measurement and management of the shared
            file system and other future file servers:

DEDMTFLG Dedicated maintenance mode   SRVCN061 Logical u-o-work rollback
FIRSTR   1st record since diage dc    SRVCN062 SAC calls
MDGPROD  Application release          SRVCN063 Stor group explicit lock
SRVCN001 Active agents highest value  SRVCN064 File space explicit lock
SRVCN002 Virtual storage highest      SRVCN065 Lock conflict, dir. exp.
SRVCN003 Virtual storage requests     SRVCN066 ", File explicit
SRVCN004 Checkpoints taken            SRVCN067 ", Storage group logical
SRVCN005 Checkpoint time              SRVCN068 ", File space logical
SRVCN006 Security manager exit calls  SRVCN069 ", Directory logogical
SRVCN007 Security manager exit time   SRVCN070 ", File logical
SRVCN008 Ext.  security mgr exit call SRVCN071 ", Catalog
SRVCN009 Ext. security mgr exit time  SRVCN072 Lock wait time
SRVCN010 Add storage requests         SRVCN073 Deadlocks
SRVCN011 Cache release requests       SRVCN074 QSAM requests
SRVCN012 Change threshold requests    SRVCN075 QSAM time
SRVCN013 Close directory requests     SRVCN076 File blocks read
SRVCN014 Close file requests          SRVCN077 File blocks written
SRVCN015 Commit requests              SRVCN078 Catalog blocks read
SRVCN016 Connect requests             SRVCN079 Catalog blks written
SRVCN017 Create alias requests        SRVCN080 Cntl minidisk blks read
SRVCN018 Create directory requests    SRVCN081 Cntl minidisk blks writ
SRVCN019 Delete directory requests    SRVCN082 Log blks read
SRVCN020 Delete file requests         SRVCN083 Log blks written
SRVCN021 Delete storage requests      SRVCN084 BIO req to read file blks
SRVCN022 File copy requests           SRVCN085 BIO req to write file blk
SRVCN023 Get directory requests       SRVCN086 BIO req to read cat blks
SRVCN024 Get directory entry req      SRVCN087 BIO req to write cat blk
SRVCN025 Grant administrator auth     SRVCN088 BIO req to read cntl mdsk
SRVCN026 Grant authorization req      SRVCN089 BIO req to write cntl
SRVCN027 Grant user connect req       SRVCN090 Total BIO request time
SRVCN028 Lock requests                SRVCN091 I/O req to read file blk
SRVCN029 Open directory requests      SRVCN092 I/O req to write file blk
SRVCN030 Open file new requests       SRVCN093 I/O req to read cat blks
SRVCN031 Open file read requests      SRVCN094 I/O req to write catalog
SRVCN032 Open file replace requests   SRVCN095 I/O req to read cntl mdks
SRVCN033 Open file write requests     SRVCN096 I/O req to write cntl
SRVCN034 Query administrator req      SRVCN097 Release blks requests
SRVCN035 Query connected users req    SRVCN098 Temporary close requests
SRVCN036 Query enrolled users req     SRVCN099 SFS send user data reques
SRVCN037 Query lock conflict req      SRVCN100 Prepare requests
SRVCN038 Query file pool requests     SRVCN101 Change file attribute
SRVCN039 Query user space requests    SRVCN102 Highest maxconn user
SRVCN040 Read file requests           SRVCN103 Get capability requests
SRVCN041 Recovery close catalog req   SRVCN104 Get log name requests
SRVCN042 Recovery get catalog req     SRVCN105 CRR get LUWID requests
SRVCN043 Recovery open catalog req    SRVCN106 Resync initial requests
SRVCN044 Recovery put catalog req     SRVCN107 Resync protocol viol reqs
SRVCN045 Refresh directory req        SRVCN108 Resync query dir requests
SRVCN046 Relocate requests            SRVCN109 CRR write log requests
SRVCN047 Rename requests              SRVCN110 CRR request service time
SRVCN048 Revoke administrator auth    SRVCN111 Number of sync points
SRVCN049 Revoke authorization req     SRVCN112 SYNC point time
SRVCN050 Revoke user requests         SRVCN113 Partresc CRR write log rq
SRVCN051 Rollback requests            SRVCN114 CRR log checkpoints taken
SRVCN052 Unlock requests              SRVCN115 CRR log i/o requests
SRVCN053 Write accounting requests    SRVCN116 CRR bio request time
SRVCN054 Write file requests          SRVCN118 DIRATTR requests
SRVCN055 Filepool request srvc time   SRVCN119 Query accessors requests
SRVCN056 Remote file pool requests    SRVCN122 Dir cntl res lock confl
SRVCN057 Alias definitions examined   SRVCN123 Deadlocks caused rollback
SRVCN058 Alias definitions updated    SVMSTAT  Option svmstat in dir?
SRVCN059 Begin logical units of work  VMDUSER  Server identification
SRVCN060 Agent holding time

  32 c.     Rate Per Second Perspective

The following table compares the rate at which "things" happen in the
real world, and the rate at which some man-made objects function in that
real world.  I have found insight when I look at the rate at which
things happen!



                                        Rate per    Duration between
    Activity:                           Second          Events

                                         (Hz)       milli micro nano
                                                     sec   sec   sec

    Build MXG tapes (at 400 per hour)       .111     9000
    VM/ESA HF Sample taken every 2 sec      .5       2000
    Send 3270 screen at 9600 baud           .666     1500
    Sub-second response event               1        1000
    Eyeblinks                               8         125
    MVS/ESA RMF/SRM Sample taken           20          50
    Movie Frames Per Second                30          33
    Maximum ful-track I/Os to 3380         56          17
    CRT Flicker Visible                    57          17
    DASD rotation (at 3600 rpm)            60          16
    CRT Flicker Disappears                 72          13
    VM/ESA Trivial+NoTrivials Trans       224           4
    VM/ESA Slot Searches                  318           3
    VM/ESA PG Moves                     1,700                588
    VM/ESA Simulated Instructions       6,800                147
    VM/ESA Instructions from SIE       10,000                100
    Software Timer Units (TUs)         38,400                 26
    CICS Clock Ticks                   62,500                 16
    TOD Clock Ticks                 1,000,000                  1

    30 MIPs Engine instruction     30,000,000                      33





  Thanks to Judy for a comment about persistence of movie film that
  caused me to put this tabulation together.

d.  VM/ESA (ESA Feature) Benchmark Data

This analysis of data is from VM/ESA (ESA Feature) MONWRITE output using
MXG 8.8 and only PROC PRINTs and PROC MEANs of the VMXAINTV & VXAPLSRV
data sets.  The hardware platform, a 3090-600 class machine under stress
has 4,800 logged on (simulated) CMS users.  Note how few pages of output
is need to characterise this system.

Output from     PROC MEANS DATA=VXAPLSRV MAX SUM MEAN;
                 217 obs for 30 intervals   7 servers
                                          max      sum      mean
-----------------------------------------------------------------
005 CHECKPOINT*TIME                       0.20    18.53     0.08
014 CLOSE*FILE*REQUESTS                  22.03  2056.48     9.47
016 CONNECT*REQUESTS                      0.41    32.75     0.15
020 DELETE*FILE*REQUESTS                  5.21   491.86     2.26
028 LOCK*REQUESTS                         1.30   127.59     0.58
030 OPEN FILE*NEW REQUESTS                0.16     8.06     0.03
031 OPEN FILE*READ*REQUESTS              13.86  1178.29     5.42
032 OPEN FILE*REPLACE*REQUESTS            8.62   750.30     3.45
033 OPEN FILE*WRITE*REQUESTS              1.34   119.70     0.55
039 QUERY*USER SPACE*REQUESTS             1.30   110.31     0.50
040 READ*FILE*REQUESTS                   13.19  1187.22     5.47
045 REFRESH*DIRECTORY*REQUESTS            0.84    65.28     0.30
047 RENAME*REQUESTS                       0.36    25.42     0.11
052 UNLOCK*REQUESTS                       1.38   128.13     0.59
054 WRITE*FILE*REQUESTS                   7.77   663.34     3.05
055 FILE POOL*REQUEST*SERVICE TIME       10.50   774.54     3.56
059 BEGIN*LOGICAL*UNITS OF WORK          26.83  2626.28    12.10
060 AGENT*HOLDING*TIME                   12.76   968.83     4.46
062 SAC*CALLS                           323.21 32332.62   148.99
071 CATALOG*LOCK*CONFLICTS                1.59    42.24     0.19
072 LOCK*WAIT*TIME                        0.18     3.21     0.01
076 FILE*BLOCKS*READ                     52.99  4912.81    22.63
077 FILE*BLOCKS*WRITTEN                  34.15  3032.45    13.97
078 CATALOG*BLOCKS*READ                  23.09  2251.14    10.37
079 CATALOG*BLOCKS*WRITTEN               16.96  1455.10     6.70
081 cntl*MINIDISK*BLOCKS WRITTEN          6.14   583.24     2.68
083 LOG*BLOCKS*WRITTEN                   21.01  2291.50    10.55
084 BIO REQ TO*READ FILE*BLOCKS          27.47  2620.48    12.07
085 BIO REQ TO*WRITE FILE*BLOCKS         16.86  1512.56     6.97
086 BIO REQ TO*READ CATALOG*BLOCKS       23.09  2251.14    10.37
087 BIO REQ TO*WRITE CATALOG*BLOCKS      16.96  1455.10     6.70
089 BIO REQ TO*WRITE CONTROL*MDISK blk    0.20    20.00     0.09
090 TOTAL*BIO REQUEST*TIME                2.88   234.32     1.07
091 I/O REQ TO*READ FILE*BLOCKS          29.59  2674.68    12.32
092 I/O REQ TO*WRITE FILE*BLOCKS         21.55  1968.02     9.06
093 I/O REQ TO*READ CATALOG*BLOCKS       23.09  2251.14    10.37
094 I/O REQ TO*WRITE CATALOG*BLOCKS      16.96  1455.10     6.70
096 I/O REQ TO*WRITE CONTROL*MDISK BLK    0.38    37.09     0.17

          Statistic               Event             Total    Rate
                                  Count    Percent  Seconds  Per
                                                             Second
          Duration of Interval                        60
          Users Logged On          4,807
          Active Users               819
          Quickdisp                   80
          UP Trivials              6,330
          UP Non-Trivials          7,143
          CPU (6) Busy                       91.3    328
                  System Code                 8.0     29
                  User Code                  83.2    300
                  Emulation Mode                     184
                  TTIME                              299
                  VTIME                              182
          Resume Subchannels                                  99.8
          Solicited Interrupts                               487.7
          Start Subchannels                                  384.9
          VIO Requests to DASD                               285.4
          Read Operations for Sys Paging                     237.4
          Write Operations for Sys Paging                    188.4
          Page Faults on Host from Guest                      51.4
          Page Faults on Guest Pages                          50.9
          Read Pages                                         184.7
          Write Pages                                        114.2
          Users Logged On          4,807
          Active Users               819
          Max in PLDV                 84
          Users in Dispatch          171 ---> close to 177, sampled.
           "  Console Wait        2
           "  Running on Real     3
           "  In Real CPU Wait   94
           "  In I/O Wait        18
           "  Quickdisp           7
           "  Simulate Wait      26
           "  Test IDLE          27
           "  Sub Total         177      ---> close to 171, sampled.
          Users Loading                2
          Users Dorm in Dorm       4,636
          Users Dorm in Elig           0
          Q1+Q2+Q3 in Dispatch       162
          Q2+Q3    in Dispatch        45
          Q3       in Dispatch        18
          Prempts from Q0 for E1                             108.4
          Diagnose X98 Issued                                 57.3
          Pages Migrated ESTORE to DASD                      236.7
          Pages Written to ESTORE                           1671.7
          Pages Read in from ESTORE                         1436.8
          VMDBKs In PLDV When Not Empty                       14.9
          Times PLDV Had No VMDBKs                           436.7
          VMDBKs Moved to Master                           1,074.6
          Long Paths Thru Dispatcher                       8,137.2
          Interceptions from SIE                           8,667.1
          Instructions from SIE                           10,289.9
          Unsolicited Interrupts                              23.5
          External Interrupts Received                     1,931.7
          IBM Supplied Diagnose Issued                     2,576.6
          Simulated Instructions                           6,815.1
          Frame List Reorders                                 41.7
          VMDBKs Stolen  total-->                          2,194.6
            "     " ->in CPU#   0    1    2    3    4    5
                         Rate 462. 448. 418. 385. 394.  56.

  VM/ESA Memory measures (Virtual, Expanded and Central, and Auxiliary)

                                          GB        MB        KB
          Slots Allocated for Paging      10G
          Slots In Use for Paging                 1060M
          Slots Alloc for Spool                   4143M
          Slots in Use by Spool                    168M

          Free Storage Extend Frames                47M
          Free Storage Available                            9124K
          Free Storage In Use                               7995K
          Frames In Use for Saveareas                        888K
          Resident Shared Frames                            4432K

          Size of Dynamic Area DPA                 420M
          Frames on Available List                          2320K
          Times Avail List Became Empty  3
          Avail List High Threshold                         3608K
          Avail List Low Threshold                           408K

          Non Pageable Frames                       80M
          Pageable Frames                          501M
          Pages Locked in 31-bit Mode                        540K
          XSTORE Blocks in CP Partition           2048M
          Estore Blocks Released w/o I/O            12M
          Avail XSTORE Note In Use                          6192K

                                            Rate/sec

          Migrate Invocations                  0.8
          Migrate Unreferenced Blocked Pages  51.9
          Stolen Unreferenced Blocked Pages   33.6
          Single Reads for a Guest            10.7
          Single Reads for the System         26.6
          XSTORE Allocations               1,787.2
          XSTORE Deallocations             1,854.0
          IUCV Receive Queue                  31.3
          IUCV Send    Queue                    .1
          Device SSCH+RSCH                   485.0
          RDEV Locks Deferred                   .2
          RDEV Locks Granted Immed           902.7
          Solicited Interrupts               488.1
          Unsolicited Interrupts              23.4


         DASD statistics               Seconds    MPL    msec per I/O

          Device Connect Duration       163.97   2.73       5
          Device Disconnect Duration    370.76   6.18      13
          Device Pending Duration        15.10    .25


          IUCV activity            From          To        Bad
           (rate per second)
           BLOCKIO                 320.4        344.4
           MSG
           MSGALL                    8.0
           MONITOR
           RPI
           CP System Service      1,241.9     1,209.6      83.7
           CCS                      361.6       377.9
           SIGNAL                   123.8       123.8
           Virtual Machine        1,239.2     1,207.7      83.7

                   File Pool Statistics in VXAPLSRV data


                                       -------User File Pool Servers----
                                         SRV2     SRV4    SRV7     SRV8

       005 CHECKPOINT*TIME                .190     .191    .188     .174
       014 CLOSE*FILE*REQUESTS          22.0     15.1    15.6     16.8
       016 CONNECT*REQUESTS               .2       .1      .1       .1
       020 DELETE*FILE*REQUESTS          4.3      3.6     3.2      5.1
       028 LOCK*REQUESTS                  .9      1.2     1.1      1.1
       030 OPEN FILE*NEW REQUESTS         .1       .1      .1       .1
       031 OPEN FILE*READ*REQUESTS      13.9      8.8     9.3      7.7
       032 OPEN FILE*REPLACE*REQUESTS    6.7      5.1     5.6      7.9
       033 OPEN FILE*WRITE*REQUESTS      1.2      1.0      .9       .9
       039 QUERY*USER SPACE*REQUESTS      .5       .8      .9       .7
       040 READ*FILE*REQUESTS           10.8      9.5    10.0     11.7
       045 REFRESH*DIRECTORY*REQUESTS     .6       .4      .4       .2
       047 RENAME*REQUESTS                .2       .1      .2       .2
       052 UNLOCK*REQUESTS               1.0      1.2     1.2      1.2
       054 WRITE*FILE*REQUESTS           5.6      5.5     5.9      6.9
       055 FILE POOL*REQ*SERVICE TIME    7.437    8.003   7.466    8.024
       059 BEGIN*LOGICAL*UNITS OF WORK  26.8     19.1    20.0     19.8
       060 AGENT*HOLDING*TIME            9.037    9.412   8.742   10.066
       062 SAC*CALLS                   320.2    242.0   243.4    283.3
       071 CATALOG*LOCK*CONFLICTS         .1       .6      .5       .5
       072 LOCK*WAIT*TIME                 .007     .026    .027     .057
       076 FILE*BLOCKS*READ             47.1     38.5    41.5     45.6
       077 FILE*BLOCKS*WRITTEN          26.2     24.4    24.6     31.5
       078 CATALOG*BLOCKS*READ          19.6     18.0    19.9     18.5
       079 CATALOG*BLOCKS*WRITTEN        8.0     13.0    16.4     12.2
       081 CONTROL*MDISK*BLKS WRITTEN    3.6      6.1     5.9      5.9
       083 LOG*BLOCKS*WRITTEN           20.8     17.0    16.7     19.7
       084 BIO REQ TO*READ FILE*BLKS    27.3     19.3    22.1     21.8
       085 BIO REQ TO*WRITE FILE*BLKS   13.4     11.5    12.2     16.0
       086 BIO REQ TO*READ CTLG*BLKS    19.6     18.0    19.9     18.5
       087 BIO REQ TO*WRITE CTLG*BLKS    8.0     13.0    16.4     12.2
       089 BIO REQ*WRT CNTL*MDISK BLKS    .2       .2      .2       .2
       090 TOTAL*BIO REQUEST*TIME        2.213    1.903   2.139    2.259
       091 I/O REQ TO*READ FILE*BLKS    28.0     18.9    21.5     23.1
       092 I/O REQ TO*WRITE FILE*BLKS   17.8     13.9    14.9     21.4
       093 I/O REQ TO*READ CTLG*BLKS    19.6     18.0    19.9     18.5
       094 I/O REQ TO*WRITE CTLG*BLKS    8.0     13.0    16.4     12.2
       096 I/O REQ*WRT CNTL*MDISK BLKS    .4       .4      .4       .4


The  documentation  of  the  VM/ESA Monitor records will  now  be  only
in  "softcopy",  and  will  be unloaded  at  install  into  a  file
named MONITOR LIST1403 on your base CP object  disk  (194).   The new
documentation contains an excellent table that details changes made to
the content and  format  of the  monitor records, including the many
APARs that are a part of VM/XA.  But the file I got, offloaded to tape
was not readable with any MVS utility I had ever seen. Any ideas?

A big thanks to IBM for making documentation available so early; it's
nice to not have to play "catch-up".


IV.  SAS Notes.

  1. SAS 6.06 has been repaired, and can be safely used.

   SAS 6.06 has finished its shakedown cruise, and shipyard repairs have
   been made, and the SAS Usage Note tape for March (or later) can now
   be safely and easily installed.  (Starting in February, SAS now ships
   a load library on that tape which contains 100% pre-applied SAS ZAPs
   for all SAS products. A SAS 6.07 will likely exist by year end, but
   THERE IS NO LONGER ANY REASON TO WAIT.  ALL MXG-critical problems are
   fixed by the March tape.  Furthermore, SAS 5.18 sites that have made
   extensions to BUILDPDB may find that their program is now too large
   for the SAS 5.18 compiler (Error 344) which can only be eliminated
   by execution under SAS 6.06 or later.
   See Change 7.038 in member CHANGE07 for 344 error circumvention.

   MXG NOW RECOMMENDS MIGRATION TO SAS 6.06 WITH SAS's MARCH 6.06 TAPE.

  2. SAS 6.06 and 5.18 options now REQUIRED by MXG 8.8.

     Please read this section carefully.  MXG execution will fail if you
     do not pay attention to these (potentially incompatible) changes:

     MANDATORY OPTIONS with either SAS Version 5.18 or 6.06:

        NOIMPLMAC MAUTOSOURCE SASAUTOS=SOURCLIB ERRORABEND MACRO DQUOTE

     MANDATORY OPTIONS with SAS Version 5.18 that do not exist in 6.06:

        MWORK=28000 GEN=0

     MANDATORY OPTION with SAS Version 6.06 that does not exist in 5.18:

        MEMSIZE=12M

     RECOMMENDED Options with either SAS Version 5.18 or 6.06:

        FIRSTOBS=1 OBS=MAX
        NOSOURCE NOSOURCE2 NOMACROGEN NOMPRINT NOMLOGIC

 SAS Version 5.18 requires the MACRO and MWORK=28000 options to be on
 the EXEC statement, but all other mandatory/recommended options can be
 specified in a SAS OPTIONS statement before your %INCLUDE statements:

    a.)   //stepname EXEC SAS,OPTIONS='MACRO MWORK=28000'
          //SYSIN     DD *
           OPTIONS
              NOIMPLMAC MAUTOSOURCE SASAUTOS=SOURCLIB
              DQUOTE ERRORABEND
              GEN=0
              FIRSTOBS=1 OBS=MAX
              NOSOURCE NOSOURCE2 NOMACROGEN NOMPRINT NOMLOGIC;

 However, so you (and I) don't have to type all those options each time
 we run an MXG 8.8 program under SAS 5.18, member SASOPTV5 was built and
 it MUST be %INCLUDEd each time you execute under SAS 5.18:

    b.)   //stepname EXEC SAS,OPTIONS='MACRO MWORK=28000'
          //SYSIN     DD *
            %INCLUDE SOURCLIB(SASOPTV5);
             ... the rest of your program ...

 IF YOU DON'T HAVE THE RIGHT OPTIONS IN EFFECT, YOU WILL RECEIVE
 RUDE AND INSULTING SAS ERROR MESSAGES, INCLUDING 180 ERRORssss!

 For SAS Version 6.06+, options are supplied via an OPTIONS statement,
 via the CONFIG DDname, or (as is now MXG's recommendation), via the
 CONFIG= JCL parameter on the EXEC statement.  MXG 8.8 member CONFIG
 contains the MXG-required options (CONFIG is a changed copy of BATCHXA
 config member on the SAS distribution tape).  In previous Newsletters
 and sample JCL, MXG had used the CONFIG DDname, but because different
 sites have their JCL procedure DD statements in different sequences,
 and since overrides have to be EXACTLY in the right order, it is now
 clear that specifying CONFIG='MXG.SOURCLIB(CONFIG)' on your EXEC
 statement is far safer to ensure the correct options are in effect:

     // EXEC SAS606,TIME=10,
     //             CONFIG='MXG.SOURCLIB(CONFIG)'

 These are the required options added to BATCHXA to create CONFIG:

   NOIMPLMAC MAUTOSOURCE SASAUTOS=SOURCLIB MEMSIZE=12M
   FULLSTATS STIMER

 The MEMSIZE=12M parameter only works with MVS/XA and MVS/ESA. In almost
 all of my tests, 12M was sufficient.  The exceptions were when BUILDPDB
 was "tailored" and many additional SMF records were added to BUILDPDB
 using the EXPDB... exit facility.  One large site with heavy user SMF
 record additions to BUILDPDB reported they needed 24MB.  Since this is
 all virtual storage, and above the line, and only during the "build"
 phase in MXG processing, it should not cause a problem.  If you really
 are limited in virtual storage (or are trying to execute MXG 8.8 with
 SAS 6.06 under MVS/370) you can significantly reduce the virtual memory
 requirement by specifying BLKSIZE=4096 or even 1024. Small blocks will
 reduce the virtual memory size, but can significantly increase the real
 CPU time, run time, I/O interrupts, and the amount of real memory used.
 See the paper on blocksize in Chapter 42 of the MXG Guide.

  3. Format library differences between MVS SAS 6.06-5.18.

   The MXG-built "SASLIB" formats are built by the first step of either
   JCLTEST (for SAS 5.18) or JCLTEST6 (for SAS 6.06).

   Under SAS Version 5.18, formats are members of a PDS load library
   which must be allocated as SPACE=(CYL,(3,1,99)).
   SAS 5.18 formats are always referenced using the DDname of SASLIB.

   Under SAS Version 6.06, formats are members of a SAS data library,
   which must be allocated as SPACE=(CYL,(1,1)). Note there is NOT
   a third parameter in SPACE (for PDS directory blocks) because data
   libraries in SAS 6.06 are physical sequential files.
   SAS 6.06 formats are always referenced using the DDname of LIBRARY.

   In either version of SAS, the blocksize is set by the PROC FORMAT.

   MXG always requires the appropriate DDname (SASLIB or LIBRARY).

   You will fail with SAS 170 FORMAT NOT FOUND errors if you do not
   have the correct format library pointed to by the correct DDname.


  4. CMS-MXG Installation and Execution Considerations.

   a. CMS Format libraries are different.

   MXG Formats are created under SAS 6.06 by executing member FORMATS,
   which creates a SAS Catalog that is named 0FORMATS LIBRARY (yes, the
   first character is a numeric zero and the third an alphabetic "oh").
   Since this catalog contains all of the MXG Formats, the installation
   instructions on page 120 of the MXG Supplement ("iv. Optionally copy
   TEXT into TXTLIB") no longer apply. Also the SASLIB SASLIB option in
   the example is not used to access SAS 6.06 Formats (although SASLIB
   SASLIB is still valid in SAS 6.06 to access SAS 5.18-built formats).
   As long as the 0FORMATS LIBRARY file built by member FORMATS is on
   your first disk, SAS 6.06 will automatically find MXG formats there.

   b. Virtual Storage requirement for MXG and SAS 6.06 with VM/370.

   Executing under VM/370, MXG 8.8 needed a 10MB machine for BUILDPDB.
   It is necessary to use the NOSSEG option to disable the "SAS Saved
   Segment" to use addresses above 7MB, because the SAS Saved segment
   begins at address 7MB!  The NOSSEG only applies to this machine,
   and is needed only for the big virtual memory programs that build
   lots of MXG datasets simultaneously (like VMACVMXA, VMACVMON, etc.).
   The rest of MXG needs only a 4MB machine under VM/360.
   The BLKSIZE is set small in the REXXTES6 exec, so that the virtual
   storage required for the biggest MXG programs (BUILDPDB) would fit in
   the 10 meg I could get under VM/370, but you should experiment to use
   the largest BLKSIZE you can (and still compile the data step!). Small
   block size reduces only the virtual storage size; a large block size
   will reduce CPU time, elapsed time, I/O interrupts, and will actually
   reduce the real memory required (always true for sequential access,
   and building SAS datasets with MXG is a sequential process)!
   Executing under VM/XA, MXG 8.8 was tested in a 16MB machine.

   c. CMS SAS 6.06 ZAPs required.

   SAS ZAPS Z6062068 (add) and Z6060508 (remove) appear to solve the
   only serious CMS SAS 6.06 problem. Without the zap, CMS MACLIB
   CONCAT concatenation fails, and you cannot read members from the
   second concatenation.

   d. CMS Testing Notes.

   The REXX exec that was used for MXG testing with CMS SAS was printed
   in MXG Newsleter EIGHTEEN and is contained in member REXXTST6.
   Before the exec is invoked, you must first issue the DEFINE STOR 10M
   command, followed by the IPL CMS command.  All datasets are sent to
   your "T" disk, a temporary disk (199 cylinders in the exec) that will
   go away at logoff, unless you use the USER= SAS option, or PROC COPY.

   One Irritating problem in my testing of MXG with CMS is IBM's fault:
   There is no CMS equivalent for "DD DUMMY" or NULLFILE.  Under MVS,
   NULLFILE lets me syntax check all MXG code by dummying input files.
   Under CMS I had to create pseudo records (but with RECFM=VB, instead
   of RECFM=VBS) because of Another Irritating IBM feature:
     CMS only partially supports the VBS record format:
        CMS only reads, and can not create/write/copy VBS files, and
        CMS ABENDs if it gets an SMF record with LRECL=32760.
   All this, to verify that ALL of MXG executes under SAS/CMS, for those
   sites who have only a SAS/CMS license and use MXG to process both the
   VM and SMF data under CMS.

  5. SAS Input formats for times and timestamps.

  A problem with CICS time stamps caused me to tabulate my experiences
  and explain those funny calculations in MXG for timestamp values.


  Time/Timestamp         Format            Clock Tick Statistics
                                         Counts per    Pulse duration
                                         Second        (microsec)

  Store Clock, STCK      TODSTAMP8.      1,000,000         1
  -eight bytes           MSEC8.
  -bit 51=microsec       PIB8.6/4096
  -bit 63=244 picosec
  -bit 31=1.048576 secs

    IBM says "SHIFT RIGHT 12 BITS" which is exactly that divide by 4096,
    and MXG's .6 in PIB8.6 is the "divide by 100000" to get seconds from
    the microseconds.

  Store Clock, STCK      IB4.*1.048576  .953674316         1.048576
  -high order four
   bytes as duration


  Timer Units, TU        TU4.                38400         26
                         PIB4. /38400


  CICS Clock 4 bytes     16*PIB4.6           62500         16
                         PIB4. /62500
      Note: these are the four MMMM bytes in hhMMMMll eight bytes.


  CICS Clock 8 bytes     16*PIB8.3/65536     62500         16
                         PIB8.3/4096


  SMF Timestamp          SMFSTAMP8.            100      10,000


  RMF Duration           RMFDUR4.             1000     100,000


    SAS Version 5.18 does not support all possible values of some of its
    time formats.  The MSEC8. input format is set missing for a value of
    2**49 or greater. The TODSTAMP8. format is zero for values less than
    2**25. The difference between a TODSTAMP8. and '01JAN1960:00:00'DT
    (the literal for the number of seconds between the IBM 1900 clock
    and the SAS 1960 clock) should exactly match the TODSTAMP8. field if
    had been INPUTed as MSEC8., but it doesn't; the difference remains a
    zero until the field value is 2**12 or greater. The TU4. format is
    correct for all values except 'FF...FF'X, which is set missing!

    SAS Version 6.06 does better, but is still not perfect. The MSEC8.
    input format is no longer missing for large values. However, a value
    of 'FF...FF'X cause TODSTAMP, TODELTA, MSEC8, and even PIB8. to now
    have a value of zero (which prints Jan 1, 1960 for a SAS timestamp!)
    whereas SAS 5.18 correctly handled this maximum binary value!

    Because SAS formats are not perfect, the only truly safe algorithm
    is to use the PIBy.x input format with the appropriate arithmetic
    operation, which more reliably produces the correct values.

  6. "Close" of data libraries was changed by SAS 6.06.

    SAS 6.06 has changed when SAS data libraries are "closed", and this
    change can cause PROC RELEASE DDNAME=XYZ to fail under SAS 6.06.
    This redesign will also change how many type 14/15 SMF records are
    written for a SAS job, since they are only written at "close" time.

    Under SAS 5.18, all SAS data libraries were closed at the end of
    each SAS data step or PROC step.  This caused a type 14/15 SMF data
    record to be written, and even without enabling the SAS User SMF
    record, you could examine those close records and determine which
    part of a complex SAS program took how much elapsed time.  In SAS
    6.06, work data sets are NO LONGER closed between data/PROC steps.
    This reduces the overhead associated with OPEN/CLOSE, and may be
    wise, but it does change what happens!  There is an undocumented
    option, $LIBCLEAR, that will make SAS 6.06 act like SAS 5.18 and
    cause datasets to be closed as before, but it is suggested that
    you DO NOT use that option, as it clearly will increase SAS 6.06
    execution costs.

    The only real incompatibility seen so far occurs with PROC RELEASE.
    In SAS 6.06, you must preceed each PROC RELEASE DDNAME=XYZ; with a
    LIBNAME XYZ CLEAR; statement, to close the XYZ fileref (and, if
    XYZ was dynamically allocated, the CLEAR also deallocates the XYZ
    fileref), because PROC RELEASE cannot release space if the dataset
    is still open.  Instead of the LIBNAME XYZ CLEAR; statement (which
    requires a change to your source program), you can alternatively
    execute the PROC RELEASE in a separate MVS JCL step.


V.  Documentation of MXG Software.
Member CHANGES always contains the version number of MXG Software, and
it lists changes that were installed in that version.  Several members
named CHANGEnn are the contents of changes when that "nn" MXG version
was created.  Details on enhancements will be found in the text of the
Change description that made the enhancement (in those CHANGES and
CHANGEnn members).  The CHANGE  members can also be scanned online (with
SPF BROWSE) to search for specific product name references (CICS,
MVS/ESA, etc.).  The text of each Change identifies the member(s) that
were altered or added by that change, and documentation (especially for
new product support) is often found in comments at the beginning of
those named members.

Member NEWSLTRS contains the text of all newsletters (up through the
newsletter that accompanied that MXG release). You can search NEWSLTRS
for product name or acronym to find the technical notes, APARs, etc.
from all MXG newsletters.  (The Change Log of each Newsletter is not
replicated in member NEWSLTRS, since that text will be in CHANGES).

Member DOCVERnn is the "delta-documentation" (in abbreviated Chapter
FORTY style) of only those variables and datasets that were changed
between successive MXG Versions. There is a DOCVERnn "delta" member in
the MXG library for each version.

Penultimately, member DOCVER contains abbreviated Chapter FORTY format
that documents all of the 26,355 variables from the 791 MXG data sets
that can be created by that MXG Software Version (alphabetically by data
set name and variable name).

Finally, MXG is a source distributed system, so you can often find your
answer by BROWSE/EDIT of the source member, especially the VMAC...'s
that actually create the data set, or ANAL....'s that analyze the MXG
datasets. In many instance, the MXG Variable is the IBM or Vendor's
documented field name. In other cases, the IBM field name is carried as
a comment beside the MXG variable that contains that information.  In
all cases, you should also have the Vendor's documentation of the
particular data record you are using for analysis.


VI.  MXG Version 8.8 Installation, Space, Compatibility, etc.


   MXG Compatibility Exposures in MXG Version 8 for Existing Users:

   a.  The SAS options required by MXG for execution have changed.
   b.  Execution under SAS 6.06 is different than under SAS 5.18.
   c.  To create your PDB directly on tape, IMACCICS must be changed.
   d.  If you have added additional SMF record processing to BUILDPDB,
       and you still execute MXG under SAS 5.18, you may encounter a
       SAS Version 5.18 Compiler Limit "344" error. BUILDPDB is larger.
       See Change 7.038 in member CHANGE07 for 344 error circumvention.

Always read comments in the CHANGES member for compatibility issues, as
well as for any last minute changes added after Newsletter composition.

 1. Installation, re-installation,  and Space Requirements.

The MXG Installation instructions were found in Chapter 32 of the MXG
Supplement for both new installation and for version replacement, and
those instructions, plus this discussion, is still usable. MXG SOURCLIB
member INSTALL will be a complete rewrite of Installation Instructions
for MXG, consolidating both Chapter 32s and these notes.  After you have
unloaded MXG 8.8 SOURCLIB and read these notes, read member INSTALL.

This MXG tape is distributed as a Non-Labelled (NL) tape with a single
file, DCB=RECFM=FB,LRECL=80,BLKSIZE=6160, that is actually an unloaded
Partitioned Data Set containing 1360 members (and about 296,242 source
lines) in IEBUPDTE format.

Under MVS use the IEBUPDTE utility to build the MXG.SOURCLIB library.
Under CMS use the TAPPDS   command to build the SOURCLIB MACLIB library.

Under MVS, MXG Version 8.8 MXG.SOURCLIB requires SPACE=(CYL,(40,1,299))
and DCB=(RECFM=FB,LRECL=80,BLKSIZE=23440) on DASD.

Under CMS, approximately the same space (40 cylinders) will eventually
required by the MXG SOURCLIB MACLIB, but during the CMS installation
process you should have at least 100 free cylinders on your minidisk.

MXG is tailored and extended by "Installation Macro" members (begin with
IMAC) and the "MXG Exit Facility" members (begin with EX) that are put
in the installation's "USERID.SOURCLIB", the "MXG Tailoring" library,
that is concatenated ahead of MXG.SOURCLIB in your SOURCLIB DDname:

  //SOURCLIB DD DSN=USERID.SOURCLIB,DISP=SHR --> site tailoring (yours)
  //         DD DSN=MXG.SOURCLIB,DISP=SHR    --> never changed  (mine)

If this is an MXG re-install, there should already be a USERID.SOURCLIB.
If not, then allocate one using the same attributes as the MXG.SOURCLIB,
with SPACE=(CYL,(1,1,99)); for CMS create an equivalent MACLIB.

Changes are made by copying the member from my library to your library.

IMAC.... members are self-documenting. IMACAAAA indexes all IMACs.

You should create a member CHANGES in your USERID.SOURCLIB and record
therein chronologically the MXG tailoring and installation history,
just like the member CHANGES in MXG.SOURCLIB tracks MXG itself.


You must now browse the members in USERID.SOURCLIB. If there are VMACs
members, they will override the new MXG code, and should be removed now.
However, the real purpose of USERID.SOURCLIB is for normal tailoring of
MXG for your site.  It is completely normal to have some members there:

   If you have installed printed changes from an MXG Newsletter, you
   would have copied member(s) from MXG.SOURCLIB into your site's
   USERID.SOURCLIB and then made the changes therein, or alternatively,
   you would have made a new PDS (we suggested the name MXG.CHANGLIB)
   into which you put those in-between-version changes, concatenating
   it between USERID.SOURCLIB and MXG.SOURCLIB until you receive this
   new MXG Release.  In either case, if you made temporary changes,
   now is the time to remove them.  Delete the changed VMACs members
   from your USERID.SOURCLIB,  or remove the MXG.CHANGLIB from your
   SOURCLIB concatenation.

   If you have tailored IMAC.... members in your USERID.SOURCLIB, and
   that member was changed by the new MXG Version, you must compare your
   member with the new MXG member, and retrofit your tailoring on the
   new member.  These IMACs are of particular importance, if they exist:

   IMACPDB (options for BUILDPDB) has changed and must be retrofit.

   IMACKEEP can cause syntax errors when MXG creates a new dataset from
            an existing record. MXG 8.8 support for CICS/ESA adds new
            CIC.... datasets in TYPE110/VMAC110 processing.  If IMACKEEP
            had been used to tailor the variables kept in CICSTRAN by
            redefining the  _VAR110 macro (an appropriate use of this
            tailoring exit), the new dataset will cause "Dataset not in
            DATA statement" SAS error condition), unless you retrofit
            your _VAR110 changes starting with MXG 8.8.

Whenever you install changes or test a new version of MXG (or even your
own reports), be extra careful to look on the SAS log for any real error
conditions. Search for all occurrences of "ERROR:" and  "ERROR :"  and
"UNINITIALIZED" and "NOT CATLGD", as they may indicate a serious error.

A PROC PRINT and a PROC MEANS of each new MXG-built SAS dataset can help
you to understand their contents, and should be used to examine any
unusually large, negative, or suspicious values.  Print all variables in
the data set, and read the variable's descriptions in Chapter FORTY.


 Summary of critical actions to be taken in installing new version:

     a. All VMAC.... members in your USERID.SOURCLIB must be examined
        and, in general, must be deleted.

     b. All IMAC.... members in your USERID.SOURCLIB must be compared
        with the new IMAC.... members, and if there is a difference,
        you MUST start with this version's IMAC and retrofit your
        installation's tailoring.

     c. It is always wisest to PROC PRINT the first 50 observations of
        important datasets, especially PDB.JOBS, which can be affected
        by user tailoring in IMACPDB. A visual scan of that PROC PRINT
        serves as an excellent validation of correct installation, and
        will almost always detect any serious problems BEFORE you begin
        your production MXG runs!  See the MXG utility UTILPRAL.

VII. Change Log
--------------------------Changes Log---------------------------------

 You MUST read each Change description below to determine if a Change
 will impact your installation.  All of these changes have been made
 to this MXG Source Library.

 Member CHANGES of the MXG SOURCLIB will always be more accurate than
 the printed changes in a Newsletter, because the software is created
 after the newsletter is sent to the printer!

 Member CHANGES always identifies the actual version and release of
 MXG Software that is contained in that library.

 The actual code implementation of some changes in MXG SOURCLIB may be
 different that described in the printed NEWSLETTER (which might have
 printed only the easily installed, critical part of the correction).

 Always read the comments at the beginning of each source member named
 under the Change Number for impacting changes.

 Documentation of new datasets and variables, validation status, notes,
 etc., are usually in comments in the source members.


Alphabetic INDEX of the most significant changes in MXG 8.8.

  Member    Change   Description

  ANALDB2R  8.030  DB2 Reporting from GTF data failed.
  ANALDB2R  8.031  DB2 Report PMLOK03 fails with 170 format error.
  ANALDB2R  8.067  Report selection by time frame incorrect, minor.
  ANALDB2R  8.084  DB2 Trace reporting with PDB=SMF avoids IMAC102.
  ANALDB2R  8.121  PMAUD02/PMAUD03 request caused SAS 145/170 error.
  ANALDB2R  8.280  Transit time and SQL reports added.
  ANALDBTR  8.249  DB2 Trace record pairing (SnnnSnnn) datasets built.
  ANALDSET  8.077  ACCESS variable was not created, report failed.
  ANALDSET  8.223  EXCP count deaccumulation from SMF 14/15 corrected.
  ANALPRTR  8.146  New printer capacity analysis system.
  AS400PDS  8.278  AS400 Records processing.
  ASMTMNT   8.070  MXG Tape Mount Monitor on 7.7 does support MVS/ESA.
  ASMVTOC   8.117  Assembly program for Fast reading of DASD VTOCs.
  ASUMCICS  8.023  Variable LENGTHs caused trunction.
  ASUMJOBS  8.230  Duplicate-Job-Name-Hold delay time estimated.
  BUILDPDB  8.069  ACCOUNT/SACCT in SMFINTRV, SPIN in PDB, TYPE25 added.
  CICINTRV  8.182  New CICINTRV (CICS/ESA Interval Statistics) dataset.
  CICINTRV  8.251  New CICEODRV (CICS/ESA Shutdown Statistics) dataset.
  CONFIG    8.068  SAS 6.06 options member added to MXG library.
  DIFFHSM   8.260  HSM User SMF Record de-accumulation.
  DOCDB2PM  8.112  Documentation of DB2PM-like reports in ANALDB2R.
  DOCGRAF   8.274  SAS/GRAPH device support and MXG standards.
  DOCTREND  8.113  Incompatible changes in MXG Trending implemented.
  EXACFJR   8.047  ACF2 dataset ACF2JR may have deleted observations.
  EXIDMTAS  8.105  IDMS Batch ACCOUNT1-3 fields decoded.
  FMXGUCBL  8.009  Returns wrong value under SAS 5.18.
  GRAFDB2   8.275  SAS/GRAPH analysis of DB2 data.
  GRAFWORK  8.140  New graphic report of RMFINTRV workloads by hour.
  IMACAAAA  8.281  Install aid describing which tailoring IMACs do what.
  IMACACCT  8.133  Safer/Easier user tailoring of kept Account fields.
  IMACICDB  8.177  CICS/ESA 3.1 Transaction DBCTL counters/clocks.
  IMACPDB   8.048  Variables ABNDRSNC DIVRREAD DSSIZHWM TERMNAME added.
  JCLDASD   8.264  MXG DASD (VTOC,VVDS) Space Management example.
  JCLTEST   8.001  Options MACRO DQUOTE MWORK=28K required by MXG 7.7.

  JCLTEST   8.025  WORK.DIRMACR REQUIRES MORE SPACE error condition.
  JCLTREND  8.058  PROC SORT added to avoid not-sorted condition.
  MONTHBLD  8.095  Syntax error under SAS 6.06 circumvented.
  MVS 4.1   8.167  Support for MVS/ESA SP Version 4.1 and RMF 4.2.
  MVS 4.2   8.224  Support for MVS/ESA SP Version 4.2 and RMF 4.2.1
  NPM       8.038  NPM records from VM can be processed.
  PRODUCTS  8.282  Documents MXG support by "product name/acronym"
  RMFINTRV  8.216  SIO counts in RMFINTRV missing.
  SAS 6.06  8.283  "Dataset is not sorted" SAS Error fixed by Z6062141.
  SPIN      8.158  SPIN library fills when MVS/ESA replaces MVS/XA.
  SPIN      8.172  SPIN library fills when MVS/ESA replaces MVS/XA.
  SPUNJOBS  8.258  New PDB.SPUNJOBS dataset for SPIN reporting.
  TRND72    8.143  Critical error, but only in PreRelease 8.3
  TRNDDB2A  8.276  TRENDing for DB2ACCT into MXG Trend database.
  TRNDDB2S  8.279  TRENDing for DB2STAT0 and DB2STAT1.
  TRNDRMFI  8.143  Critical error, but only in PreRelease 8.3.
  UTILGETM  8.206  %MACRO on FILE statement CPU loop in SAS 6.06.
  VMAC110   8.065  Support for new CICS 3.1.1 major changes.
  VMAC1415  8.017  New HiperBatch counts added to SMF type 1415.
  VMAC1415  8.137  HiperBatch values non-zero when they should be zero.
  VMAC23    8.208  SMF writer memory usage added (OY27449).
  VMAC28    8.111  INPUT function error in NPM subtype 82.
  VMAC28    8.148  Support for NPM Release 4 (NPM 1.4), SMF Type 28.
  VMAC30    8.081  Support for APAR adding DDCONS() option.
  VMAC30    8.082  Support for APAR adding PROCSTEP to type 30s.
  VMAC30    8.208  NOT CATLG 2 or 7 now added (APAR OY24857) to 30s.
  VMAC37    8.022  Variable KEEP, FORMATs.
  VMAC39    8.022  TYPE39EL conditionally created. ZDATE kept.
  VMAC39    8.245  Support for NETMASTER V2.1.0 subtype 255.
  VMAC41    8.015  New VLF counts in new subtype 3 SMF type 41.
  VMAC42    8.136  STOPOVER on subtype 3 due to IBM error.
  VMAC57    8.184  STOPOVER on type 57 (MVS 4.1 and MXG 8.5 only).
  VMAC6     8.057  STOPOVER due to invalid external writer record.
  VMAC60    8.128  STOPOVER on SMS NVR segment in type 60.
  VMAC6156  8.027  STOPOVER error with ICF catalog record section.
  VMAC6156  8.039  TYPE6156 VOLSER may be wrong for GDGs.
  VMAC6156  8.214  "Invalid Third Argument to Function SUBSTR."
  VMAC64    8.134  ACBMACRF fields individually decoded into variables.
  VMAC64    8.219  TYPE64 HiperBatch variables missing.
  VMAC64    8.234  VSAM HiperBatch counters corrected.
  VMAC7072  8.066  Support for new "SRCL" field in RMF Product section.
  VMAC7072  8.187  Support for new Hitachi processors with MLPF.
  VMAC7072  8.233  "Invalid data for MSOCOEFF..." correction.
  VMAC7072  8.250  Support for PR/SM "overhead" measures APAR OY36668.
  VMAC76    8.254  Support for OPPSI in SYSPLEX is traceable.
  VMAC78    8.049  TYPE78CF only output if CHPID is online.
  VMAC78    8.132  STOPOVER on type 78 subtype 3 with ES/9000 CPUs.
  VMAC79    8.012  STOPOVER correction, support validation.
  VMAC79    8.055  Formats and units corrections.
  VMACACF2  8.002  ACF2 SMF record caused STOPOVER.
  VMACACF2  8.090  Further validation of ACF2 SMF record.
  VMACARB   8.190  Support for Arbiter Version 2.1.1 SMF records.
  VMACCIMS  8.064  Support for IMF 2.6 (for IMS 3.1).
  VMACCMF   8.247  Support for Boole & Babbage CMF SMF record 240.
  VMACCRAY  8.044  Support for CRAY COS operating system
  VMACDB2   8.102  Distributed DB2 header added to DB2ACCT.
  VMACDB2   8.225  Support for Landmark's The Monitor for DB2.
  VMACDCOL  8.130  DCOLLECT enhancement for all seven records.
  VMACDCOL  8.210  DCOLLECT migration/backup tape dates correction.
  VMACDCOL  8.252  Support for DCOLLECT APAR OY37378.
  VMACDCOL  8.074  Support for SMS DCOLLECT data records.
  VMACDMON  8.003  Uninitialized variable in ANALDMON caused.
  VMACDMON  8.236  Support for LEGENT ASTEX replacement for DASDMON.

  VMACEPMV  8.217  Support for Candle's EPILOG for MVS SMF Type 180.
  VMACHSM   8.138  Preliminary support for HSM User SMF records.
  VMACIDMS  8.005  IDMS SMF record variables format incorrect.
  VMACIMS   8.006  IMS crashes required duplicate DTOKEN protection.
  VMACIMS   8.098  Support for IMS/ESA 3.1 log records.
  VMACIMS   8.118  IMS Cold start support and logic changes.
  VMACIMS   8.119  Correction of IMS Input Queue time.
  VMACIMS   8.176  IMS 3.1 DBCTL Thread Transactions Deleted.
  VMACIMS   8.256  Support for IMS Wait-for-Input from IMS log.
  VMACMDF   8.091  Amdahl's MDFTRACH SMF records corrected.
  VMACMEMO  8.227  Support for MEMO European Electronic Mail SMF record.
  VMACMON8  8.161  Support for Landmark's Monitor for CICS Version 8.0
  VMACMONI  8.036  CREATIME in MONITASK may have wrong date.
  VMACMPT   8.173  Support for Amdahl's MDF Performance Tool
  VMACNSPY  8.010  NETSPY 3.2 support was incomplete.
  VMACNSPY  8.043  Netspy 3.1 STOPOVER.
  VMACNSPY  8.265  Support for NETSPY Release 4.0.
  VMACORAC  8.080  Support for Oracle SMF record.
  VMACROSC  8.028  ROSCOAUD contained zero observations always.
  VMACSASU  8.157  SAS User Record changed under SAS 6.06.
  VMACSESA  8.228  Support for Volvo's SESAME VTAM Monitor.
  VMACSMF   8.013  DB2 read from GTF. Minor.
  VMACSPMS  8.149  Support for Amdahl's SPMS SMF (Cache DASD CU).
  VMACSTC   8.092  STC 4400 Silo SMF record new subtype.
  VMACSTC   8.194  STC 4400 Silo SMF record new subtype STOPOVER!
  VMACSYNC  8.020  Invalid CPUTCBTM value detected.
  VMACSYNC  8.056  SIRECFM,SORECFM contain invalid data value.
  VMACSYNC  8.123  Error (only in PreRelease 8.2) in TYPESYNC data.
  VMACSYNC  8.211  SYNCSORT EW2903 detects SAS invoked Sort.
  VMACSYNC  8.253  Support for SYNCSORT SCZ 33038 (Hiperspace stats).
  VMACTMNT  8.033  Minor. Formats for DEVFROM/DEVTO.
  VMACTMVS  8.173  Protection for TMON/MVS Spanned Records
  VMACTPNS  8.269  Support for TPNS log.
  VMACTPX   8.016  No observations in TPXINTRV.
  VMACTSOM  8.007  Missing STRTTIME in TSOMCMND.
  VMACTSOM  8.104  Invalid READTIME due to CA7 in TSO/MON record.
  VMACTSOM  8.262  Support for LEGENT TSO/MON Release 5.3.0.
  VMACVMON  8.037  Divide by zero.
  VMACVMON  8.045  24APR90 became 02OCT89 when 202 day clock wrapped.
  VMACVMON  8.106  VM Start Time off by 43 minutes on Aug 4, 1990.
  VMACVMXA  8.004  OMEGAMON/VM creates invalid VM/XA VB records.
  VMACVMXA  8.099  Many VM/XA PTFs altered Monitor records.
  VMACVMXP  8.041  Minor EXPLORE/VM processing changes.
  VMACVPD   8.234  Support for NETVIEW's VPD aka NAM type 37 SMF data.
  VMACVVDS  8.073  Validation of VVDS record created by ASMVVDS.
  VMACWSF   8.100  Support for WSF archive product SMF.
  VMACX37   8.024  STOPX37, minor.
  VMACZRB   8.054  RMF 4.1.1 caused STOPOVER.
  VMACZRB   8.079  Further validation of RMF III VSAM data.
  VMACZRB   8.156  Further validation and reports.
  VMXGDOWN  8.273  Download to PC all datasets in a SAS library.
  VMXGSUM   8.021  Missing variable initialization protection.
  VMXGVTOC  8.018  OFFSET4E and SMS variables added.
  VMXGVTOC  8.032  Minor. RECFM should be $4.
  VMXGVTOC  8.075  Did not capture free space at beginning of volume.
  VMXGVTOF  8.193  Build VMXGVTOC datasets from ASMVTOC records.
  VMXGVTOR  8.009  Incorrect on 7.7, changes not propagated.
  XMAC7072  8.014  ZDATE not kept in TYPE70PR and TYPE72MN
  ZZZZZZZZ  8.011  Final member of MXG Library is named.

Inverse chronological list of all Changes:

  Changes thru 8.283-8.187 were printed here in Newsleter NINETEEN

  See member CHANGE08 for actual change text.

End of Changes Log in Newsletter NINETEEN.
****************NEWSLETTER EIGHTEEN*************************************










             MXG NEWSLETTER NUMBER EIGHTEEN December 3, 1990



Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE



                         TABLE OF CONTENTS



I.   MXG SOFTWARE Version status.                               page   2

  1. Production MXG Version is still 7.7.

  2. Recent IBM Announcements and their MXG support.

  3. PreRelease MXG Version 8.7 now available upon request.

  4. Enhancements in PreRelease 8.7 (in addition to those in MXG 8.2).

  5. Enhancements that are still in development or under consideration.

  6. Plans for Production MXG Version 8 shipment in 1991.

II.  MVS Technical Notes.                                       page   4

III. SAS Notes.                                                 page   6

  1. SAS 6.06 (MVS) has been repaired, and can be safely used.

  2. SAS options that are now required for MXG execution.

  3. Format libraries under MVS SAS 6.06 or 5.18.

  4. SAS 5.18 Conflict with PDSMAN.

  5. CMS Execution of MXG under SAS 6.06.

IV. Documentation of MXG Software.                              page  12

V.  CHANGE LOG, Changes 8.186 to 8.079.                         page  12
      (Alphabetic INDEX of Significant Changes on page 13)      thru  50




         COPYRIGHT (C) 1990 BY MERRILL CONSULTANTS DALLAS TEXAS
          MXG IS A REGISTERED TRADEMARK OF MERRILL CONSULTANTS
          SAS IS A REGISTERED TRADEMARK OF SAS INSTITUTE







I.   MXG SOFTWARE Version status.


  1. Production MXG Version is still 7.7.

 There is no new software automatically shipped with this newsletter.
 MXG Version 7.7 (shipped in February, 1990) is still the production
 version. MXG 7.7 supports most of MVS/ESA 3.1.3, the 3390 DASD devices,
 3490 Tape Drives, IDRC, and everything else that was available in Feb.
 Most non-leading edge sites will not require a PreRelease of MXG.


  2. Recent IBM Announcements and their MXG support.

 IBM has made many major announcements relating to the System/390, the
 ES/9000 family, and ESCON capabilities.  The following table identifies
 announced availability dates for the IBM product, and the corresponding
 Version/PreRelease of MXG required to support that IBM product.

   Product Name                     Availability     MXG Version
                                    Date              Required

   VM/ESA  1.1.0 (370 Feature)      Oct 26, 1990.        7.7
   RMF 4.1.2 (for MVS/ESA 3.1.3)    Sep  7, 1990.        8.4
   RMF 4.2   (for MVS/ESA 4.1)      Oct 26, 1990.        8.4
   MVS/ESA 4.1                      Oct 26, 1990.        8.4

   MVS/ESA 4.2                      Mar 29, 1991.        ???
   RMF 4.2.1 (for MVS/ESA 4.2)      Mar 29, 1991.        ???

   VM/ESA  1.1.0 (ESA Feature)      Mar 29, 1991.        ???
   VM/ESA  1.1.1                    Dec 27, 1991.        ???

   Critical note for leading edge MVS sites:

     Sites installing APAR OY29112 (required for ES/9000 CPUs) or using
     MVS/ESA 4.1 (RMF 4.2) will require either the circumvention fix
     in Change 8.132, or must have MXG PreRelease 8.4 or later, because
     RMF type 78 record was changed.  See also MVS Technical Notes.


  3. PreRelease MXG Version 8.7 now available upon request.

 MXG PreRelease 8.2 was announced available in Newsletter SEVENTEEN,
 and that Newsletter documents the enhancements available at that time.
 Since July, many IBM announcements have added new data sources, and
 additional new products are now supported by MXG.  Each major iteration
 increments the PreRelease number, and thus this newsletter announces
 the current availability of MXG PreRelease 8.7.  All of the changes in
 Newsletter SEVENTEEN and the additional changes listed in Newsletter
 EIGHTEEN (this one!) are included in MXG PreRelease 8.7.  The major
 enhancements between PreRelease 8.2 and PreRelease 8.7 are listed below
 and described in detail in the corresponding CHANGE description in the
 Change Log section of this newsletter.

 There is no cost for the PreRelease.  Simply contact us by phone, fax,
 or letter (overseas, your local SAS office will relay your request),
 and we will be pleased to send you your copy of MXG PreRelease 8.7.



  4. Enhancements in PreRelease 8.7 (in addition to those in MXG 8.2).

     a. Support for RMF 4.1.2 (APAR OY29112, PTF UY90666).
     b. Support for MVS 4.1.
     c. Support for RMF 4.2.
     d. Support for CICS 3.1 DBCTL DL/I transaction activity.
     e. Support for DCOLLECT's data records from HSM, and other SMS
        related records (HSM, VVRs, VVDSs, SMS/DFP) were enhanced.
     f. Support for IMS/ESA 3.1.
     g. Support for NPM 1.4
     h. Support for Landmark's Monitor for CICS Version 8.
     i. Support for Landmark's TMON/MVS Version 1.1 and spanned records.
     j. Support for Amdahl's SPMS Cache DASD Controller SMF record
     k. Support for Amdhal's MDF Performance Tool SMF record
     l. Support for WSF2 SMF record.
     m. Circumvention for SPIN library filling due to JES2 maintenance.
     n. Corrections to MXG support of Amdhal's MDFTRACK record.
     o. Creation of CICINTRV data set from CICS 3.1 Statistics datasets.
     p. Documentation of Trend Data Base processing.
     q. Documentation (preliminary) of DB2 analysis using ANALDB2R.
     r. Major improvement in IMS Log measurement of INPQUETM/RESPNSTM.

     Several hundred sites are now executing a PreRelease of Version 8,
     and new supported sites who would otherwise receive MXG 7.7 (i.e.,
     those who tardily signed their support contract!) now receive the
     PreRelease from Merrill Consultants, because it is more robust and
     corrects many minor problems.  We call it a PreRelease just to let
     you know that there is still more on the way in the future!


  5. Enhancements that are still in development or under consideration.

     a. Testing of all of PreRelease 8.7 under the CMS Version of SAS
        6.06 has not been completed. See SAS notes.
     b. Investigation of RMF III VSAM error condition (one site).
     c. DB2 SQL trace support has not been completed.
     d. Arbiter V 2.1.1 records have changed.
     e. VM/EXPLORE Version 3.1 is reportedly changed.
     f. Support for the two HSM user SMF records that was added has not
         been validated, and de-accumulation that may be needed for the
         interval records has not yet been investigated.
     g. Support for Cray UNICOS is planned for first quarter 1991.
     h. Support for VAX/VMS Account/SPM planned for second quarter 1991.
     i. LLA SMF Record is a future consideration.
     j. JES3 Tape Mount Merge with TYPETMNT is a future consideration.
     k. NETVIEW FTP support is a future consideration.



  6. Plans for Production MXG Version 8 shipment in 1991.

     a. VM/ESA (XA feature) will be available March 29, 1991. The IBM
        announcement indicates there will be no incompatibility with the
        existing VM/XA monitor support, but new data fields will exist.
     b. MVS/ESA 4.2 will be available March 29, 1991. The announcement
        indicates there will be significant new data in new subtypes of
        the type 72 and 79 RMF records, new I/O reconfiguration data in
        the type 74 RMF record, new type 30 data for APPC, and new
        working set and block paging function statistics in existing
        SMF and RMF records.
     c. DOS/ESA will likely require changes, but enhancements won't be
        scheduled until test site is identified. Volunteer is needed!


   Because of the preceding three items, the Production MXG Version 8,
   and the next MXG Newsletter, is now planned for shipment to all MXG
   supported sites not later than March 29, 1991.

   If IBM chooses to make the documentation of these new accounting and
   performance data records available sooner, and if IBM also allows
   support for those changes to be shipped sooner, MXG Version 8 will be
   shipped as originally planned, in mid-February, 1991.


II. MVS Technical Notes.

1. OY31183, SMS only, mentioned in Newsletter SEVENTEEN, now has PTFs
   to correct the invalid DEVTYPE=FF and DEVNR=0FFF in type 30 records
   for multi-volume SMS data sets.
2. OY26719 replaces the incorrect JOB name of IEESYSAS with the real
   name of the started task that went thru full function start up.
3. OY34035 (PTF UY52690) repairs loss of type 14/15 records after PTFs
   UY90568/UY90560 were installed.
4. PTFs associated with APAR OY25436 erroneously sets the "Blocksize
   changed" bit in each DD section of type 30 records. Problem is open.
5. With DFP 3.2 and Cache DASD Reporter can cause complete loss of RMF
   data records, with no footprint. APARs OY31406 and OY34829 address
   the problem, which results when the Cache RMF Reporter subtask hangs
   up, preventing RMF main task from ever writing records until RMF is
   taken down and restarted. Only non-existent type 70-79 records give
   you a clue that you had the problem!
6. APARs OY29801, OY32368, OY49794, and OY51970 all relate to VLF
   data corrections in SMF type 41 subtype 3 records.
7. The SPE (Small Programming Enhancement) APAR OY29112, PTF UY90666
   is required for MVS to execute on an ES/9000 CPU, is itself in error,
   and will create invalid type 78 subtype 3 records. The correction
   APAR is OY36517 and PTF UY55476 fixed the error Oct 31, 1990.
8. OY36035/OY36043 APARs now have PTF UY55307 to correct the corrupted
   type 42 subtype 3 DFP 3.2 record (the real culprit was the same IBM
   change to the PL/S compiler, which caused UY90666's problem!)
   R. Shannon of Aetna pointed out that the LLA's use of VLF causes the
   type 41 data to report LLA's utilization near 100%, but LLA still
   adds modules, because LLA only calls VLF for modules that LLA had
   previously cached.  The SMF records which can be created from the
   CSVLLIX1 exit can provide fetch statistics, but also will create lots
   of data records. Additionally, the storage used reported by VLF is
   not the high-watermark, but rather the storage in use at the end of
   the interval.

9. Problems with HiperBatch information in type 14/15 are fixed by
   applying PTFs UY50465,UY51181,UY51182,UY54424 on top of APARs
   OY30300,OY32039 and OY34754.
10.APAR OY36879, PTF UY55480 corrects a type 30 problem wherein EXCP
   sections are completely missing for dynamically unallocated DD's!!
   This was first noted by a tremendous drop in the EXCP counts after
   maintenance, but only for TYPETASK of TSU.
11.APAR OY26507 for MVS/ESA corrects I/O connect time for VIO datasets
   (by setting the value to zero, as it should have been all along!).
   MXG's IOTMTODD was extremely large, and IOTMNODD was negative because
   of the IBM error.
12.OY26842 (MVS/ESA only) increases the number of concurrent DDs that
   can be simultaneously opened from 3723 to 10,000.
13.OY29434 (MVS/XA 2.2.0 and above) deals with destage of 3990 cache
   controller data when HALT EOD command is issued.
14.OY24606 (MVS/XA 2.2.0 and above) ensures TSO SMF type 32 record is
   written after TSO user is cancelled; previously last commands data
   was lost.
15.OY21749 now causes the SMF dump program, IFASMFDP, to put a message
   in the SYSPRINT data set if the dump program ABENDED. (Some sites
   throw away their JCL and kept only the SYSPRINT, and never knew the
   dump program had abended! Isn't it amazing what IBM has to do to
   meet the needs of it's customers!)
16.OY32670 now causes the SMF dump program, IFASMFDP, to put a message
   in the SYSPRINT data set that you tried to dump an empty SMF dataset.
17.OY32638 adds PROCSTEP to the type 30 SMF record.
18.OY25606 expands the Extra-dd field in type 30s to four bytes.
19.Newsletter NINE discussed the impact of a non-zero value for the
   timezone delta, PARMTZ in SYS1.PARMLIB(PARMTZ). In MVS/ESA the delta
   is set by TIMEZONE= in SYS1.PARMLIB(CLOCK00). In either case, if the
   delta is non-zero, the CICS internal timestamps (STRTTIME,ENDTIME)
   and DB2 internal timestamps (QWHSSTCK,QBACCBSC,QWACCESC) will be on
   GMT but the SMF timestamps will be local.
20.IDRC (data compaction) on 3480 tape cartridges can be specified by
   the TRTCH=COMP/NOCOMP subparameter of the DCB parameter, or can be
   set by default in the DEVSUPyy member of SYS1.PARMLIB (IBM defaults
   to NOCOMP).  MXG 3480 tapes are always DCB=TRTCH=NOCOMP, because
   IDRC is an optional hardware feature on your tape control units.
   Reading an IDRC tape built with compaction on a control unit without
   the IDRC hardware feature produces an I/O error with these messages:
   IOS000I 410,10,NCA,02,0600,,**,,jobname
    0049602E000000200080(70D7000000000000)0078(00000000)F7820F7168860000
21.SYNCSORT release 3.3 truncates a VBS record with LRECL=RDW=32760!
   The problem is fixed by zap EW3178-0 for that release. Without the
   fix, records greater than 32756 bytes LRECL are truncated on output.
   The specific occurrence of an SMF record of exactly 32760 bytes was a
   type 79 subtype 1 (over 330 ASIDs active). Specifying LRECL=32760 in
   the JCL of the sort did not correct the problem.
22.Some unverified comments about MVS/ESA CPU timings of Hiperspace
   activity suggest that creation of a hiperspace causes CPUHPTTM to be
   non-zero, but reading of data in that hiperspace causes both CPUHPTTM
   and CPUTCBTM time to be recorded, because the MOVEPAGE instruction
   (which is good, fast, etc., and new, and only on some hardware) does
   record CPUTCBTM.  Without MOVEPAGE, there will be more real CPU time
   and it will be recorded in CPUHPTTM, and not in CPUTCBTM.  The cost
   of MOVEPAGE is on the order of one half of the cost of a page-in in
   expanded memory (which has been quoted as 75 microsec for one page
   but approaches 30 microsecs per page when several pages are blocked
   together).

III. SAS Notes.

  1. SAS 6.06 (MVS) has been repaired, and can be safely used.

   SAS 6.06 has finished its shakedown cruise, the shipyard repairs
   have been made, and the October SAS Notes tape now contains a load
   library with most critical, required, and recommended zaps already
   installed.  Sites should now request the October or later SAS Notes
   Tape from SAS Technical Support and begin their testing and
   migration to the new version.  While there will be a SAS 6.07
   version in mid-1991 with ESA exploitation, additional performance
   improvements and bug fixes, there is no reason to wait. In fact, SAS
   6.06 has removed constraints on program size which limited many large
   site's SMF processing. With the new SMF records now created by
   MVS/ESA 4.1 and the new records announced in MVS/ESA 4.2, SAS 6.06
   may actually be required for BUILDPDB with MVS/ESA 4.2 next spring!
   MXG now recommends testing for migration to SAS 6.06.

   A PreRelease of MXG Version 8.x has NEVER BEEN REQUIRED for Execution
   of MXG under MVS SAS 6.06.  MXG 7.7 will execute under SAS 6.06.

   What is REQUIRED is the installation of many critical ZAPS to the SAS
   System.  MXG Newsletter SEVENTEEN (July) listed the then-known ZAPs,
   and identified several open problems.  As problems were fixed, that
   list grew to the following list of SAS ZAPs that are required for MXG
   execution under SAS 6.06 under MVS:

   Z6060135  Z6060288  Z6060529  Z6060611  Z6060640  Z6060653  Z6060872
   Z6060892  Z6060916  Z6060938  Z6060946  Z6061149  Z6061220
    and Z6060969 (which replaced Z6060571)
    and Z6061258 (which replaced Z6060703)
    and Z6061738 (which replaces Z6060652)

   MXG also STRONGLY recommends that ALL ZAPs that are idenfified by SAS
   as Critical, Highly Recommended, and Recommended also be installed.
   Prior to the October SAS Usage Notes Tape, installing all ZAPs could
   take two days, as the ZAP stream failed each time a module's IDRCOUNT
   filled, requiring a link-edit of that module and a restart of the ZAP
   stream. (IBM limits IDRCOUNT to 19, and SAS uses IDRs to identify the
   ZAPs that have been applied to a module).

   However, beginning with the October SAS Notes library, the tape now
   contains the "SAS Maintenance files", which includes a load library
   containing selected SAS modules with pre-applied maintenance, i.e.,
   the important ZAPS have already been applied!.  See Section 3.11 of
   the document "MVS Version 6 SAS Notes, ZAP Libraries and Maintenance
   Files", Document Number MVS6-US-1090.02, which accompanies the tape.
   The following MXG-required ZAPs were not on the October SAS Notes
   "Maintenance library" and will need to be applied:

      Z6060916 Z6060969 Z6061258 Z6061738

   While we have many sites with MXG 7.7 who are successfully executing
   MXG under MVS SAS 6.06, there were seven members of MXG that had to
   be changed to avoid syntax errors, and many additional members were
   also changed to provide complete forward and backward compatibility
   with both SAS 5.18 and SAS 6.06.  We do recommend that you request
   and install an MXG Version 8 PreRelease, but it is not required. The
   few problems encountered using MXG 7.7 under the ZAPed SAS 6.06 have
   been fixed by telephone (or by reading the Newsletter). The critical
   parts of MXG 7.7 (those that build the data sets) do work under 6.06.

   The biggest problem area, once these ZAPs are installed, is that when
   SAS runs out of memory or disk space, strange error messages occur,
   (like "no more MFEs", "data set is not sorted", "record too large").
   These errors can be avoided by always executing in a 4MB or larger
   region, specifying MEMSIZE=12MB (automatic, if you use MXG's CONFIG
   member), and (initially) overallocate your disk space. (The 6.06 WORK
   default is only CYL,(5,2)!). Overallocate, and add the SAS statement
     PROC CONTENTS DATA=WORK._ALL_ NODS;
   at the end to determine how much disk space is actually required.

   Does anything work well under SAS 6.06?  Actually, quite a lot!
   For many non-MXG applications that are not especially data or
   memory intensive (the info center, and non-programmers), there
   is a lot of SAS 6.06 that does work real well, especially the
   SAS/ASSIST and the display manager. These new tools that make SAS
   efficient in the hands of non-programmers have received positive
   feedback, especially from sites that had never used SAS before.
   The portions of SAS 6.06 that had already been sailing in the PC
   versions 6.02 and 6.03 did port over to MVS with fewer problems.
   It was only the processing of large files with large MXG programs
   with large memory requirements that caused most of the repairs.

   The following ZAPs are included in the preceding list, but they  have
   not been described in previous MXG newsletters.

   a. ZAPs Z6060135,  Z6061149 and Z6061220 are required, and may
      resolve Usage Note 1000 errors, which include "Data is not
      Sorted", "Record in buffer is too long", User 0016 ABENDs from
      SORT program, and/or E15 or E35 SORT exit error, depending on
      SORT program used.  The real cause of most (perhaps all) of these
      error messages was that the SAS library being created (WORK, PDB,
      etc.) ran out of space, but SAS 6.06 mis-recognized the condition
      and produced an incorrect error message.
      Note added 1996:  The E35 SORT exit error message was not fixed
      until SAS 6.08 at TS410 (or ZAP Z6088203 for TS407 was applied).

   b. ZAP Z6060916 is absolutely required.  Without this zap, the
      %VMXGSUM macro (used in ASUM.... and TRND.... members for
      trending/summaries) will generate incorrect (but error-free) SAS
      code and data sets built with %VMXGSUM will be wrong.

   c. ZAP Z6060892 is required if you have a DASD Cache Controller 3880
      or 3990 device.  Formatting a 500 Cyl work file was done with a
      single CCW chain which took an enormous amount of SQA storage,
      and the "Missing Interrupt Handler" time delta was not long
      enough to handle the transmission of the CCW chain TO the Cache
      Controller, let alone to wait for it to complete.  This ZAP
      breaks down the formatting of SAS 6.06 data libraries into 5
      cylinder chunks to avoid the problem.

   d. SAS ZAP Z6061465 corrects SAS failure to handle broken VBS
      segment if the bad segment is the last record on a data set.
      Instead of deleting the bad VBS segment, SAS failed, either with
      a OC1 or by permanently entering the wait state.  This ZAP
      correctly deletes the defective VBS segment, and continues
      processing the input data set.

   e. PROC CHART against a data set with zero observations erroneously
      sets a condition code of 8 and a scurrilous error message that
      won't be corrected until SAS 6.07, according to Usage Note
      V6-CHART-0952.

   f. Overriding JCL DD statements must be in exactly the same order
      that those DD statements appear in the SAS 6.06 JCL procedure.
      The SAS606 order is
      STEPLIB,CONFIG,SASAUTOS,SASHELP,SASMSG,WORK,SASLOG,SASLIST.

   g. DATETIME21.2 of '06NOV90:07:30:50' prints '06NOV90:07:30.491.0',
      and 30:51 prints as 30:501.0. SAS Usage Note 793 discusses this
      generic problem with fractional time values, but no ZAP exists.

   h. PROC MEANS was changed in 6.06, and now operates only on a
      maximum of 400 variables. If a new data set is to be built from a
      data set of over 400 variables with PROC MEANS OUTPUT, the
      created dataset will be corrupted, as it will contain only the
      first 400 variables, and NO ERROR MESSAGE OR CONDITION CODE is
      set by SAS 6.06!  MXG does not have a PROC MEANS with OUTPUT on
      any data set of over 400 variables, but this new design "feature"
      is disconcerting, considering SAS's pre 6.06 philosophy to not
      restrict users with capricious limitations!  SAS Compatibility
      Note Number 779 discusses this restriction, which will be removed
      in SAS 6.07.

  2. SAS options that are now required for MXG execution.

Some Options are now MANDATORY for successful MXG execution which might
 have been optional in the past.

 MANDATORY OPTIONS under both SAS Versions:

      NOIMPLMAC MAUTOSOURCE SASAUTOS=SOURCLIB ERRORABEND MACRO DQUOTE

 MANDATORY OPTIONS under SAS Version 5.18:

      MWORK=28000 GEN=0

 MANDATORY OPTIONS under SAS Version 6.06:

      MEMSIZE=12M

 RECOMMENDED Options under either SAS Version:

      FIRSTOBS=1 OBS=MAX
      NOSOURCE NOSOURCE2 NOMACROGEN NOMPRINT NOMLOGIC

 For SAS Version 5.18, MACRO and MWORK=28000 must be specified on the
  EXEC statement, while all other mandatory/recommended options can be
  specified on an OPTIONS statement before your %INCLUDE statements:

    a.)   //stepname EXEC SAS,OPTIONS='MACRO MWORK=28000'
          //SYSIN     DD *
           OPTIONS
              NOIMPLMAC MAUTOSOURCE SASAUTOS=SOURCLIB
              DQUOTE ERRORABEND
              GEN=0
              FIRSTOBS=1 OBS=MAX
              NOSOURCE NOSOURCE2 NOMACROGEN NOMPRINT NOMLOGIC;

    b.)   New member SASOPTV5 has been added to eliminate the need for
          typing all the above options, and can be used instead each
          time you execute MXG under SAS 5.18:

          //stepname EXEC SAS,OPTIONS='MACRO MWORK=28000'
          //SYSIN     DD *
            %INCLUDE SOURCLIB(SASOPTV5);
             ... the rest of your program ...


 For SAS Version 6.06+, options can be supplied via the CONFIG DDname in
  your JCL, or with an OPTIONS statement. PreRelease member CONFIG is a
  changed copy of the SAS-supplied BATCHXA config member, with these new
  options specified for MXG execution. (Note MWORK= and GEN= don't exist
  in SAS 6.06):

           NOIMPLMAC
           MAUTOSOURCE
           SASAUTOS=SOURCLIB
           MEMSIZE=12M
           FULLSTATS
           STIMER

  3. Format libraries under MVS SAS 6.06 or 5.18.

   The MXG-built "SASLIB" formats are built by the first step of
   JCLTEST (for SAS 5.18) or by the first step of JCLTEST6 (for SAS
   6.06).  Under SAS Version 5.18, formats are members of a PDS and
   referenced by the SASLIB DDname, and require SPACE=(CYL,(3,1,99)).
   Under SAS Version 6.06, formats are members of a SAS data library,
   referenced by the LIBRARY DDname, and require SPACE=(CYL,(1,1)).
   Note the absence of the third (PDS directory blocks) for SAS 6.06.
   In either version of SAS, the blocksize is set by the PROC FORMAT.
   MXG always requires the appropriate DDname (SASLIB or LIBRARY).


  4. SAS 5.18 Conflict with PDSMAN.

   PDSMAN product installation documentation specifically identifies a
   problem with SAS Version 5 format libraries and tells the PDSMAN
   installer to exclude such libraries from PDSMAN control. If your
   installer overlooks that warning, you will receive SAS Error 175
   when you try to access version 5 format libraries from either SAS
   version 5.18 or 6.06. (PDSMAN updates the directory with last use
   date in a fashion which is incompatible with SAS load libraries).


  5. CMS Execution of MXG under 6.06:

 a.Status of testing under CMS.

   The CMS product group at SAS has used MXG Software in its regression
   testing, and we do have real users with only a CMS SAS 6.06 license
   that are using MXG.  In testing MXG under CMS 6.06, some language and
   option inconsistencies have been found, but testing of all parts of
   MXG has not yet been completed.  Most of the ZAPs listed above for
   MVS 6.06 SAS do not apply to the CMS 6.06 system.  Please regard this
   discussion a preliminary, as it will be expanded in the next MXG
   Newsletter.


 b.Preliminary CMS 6.06 MXG Installation notes:

   MXG Formats are created under SAS 6.06 by executing member FORMATS,
   which creates a SAS Catalog that is named 0FORMATS LIBRARY (yes, the
   first character is a numeric zero and the third an alphabetic "oh").
   Since this catalog contains all of the MXG Formats, the installation
   instructions on page 120 of the MXG Supplement ("iv. Optionally copy
   TEXT into TXTLIB") no longer apply. Also the SASLIB SASLIB option in
   the example is not used to access SAS 6.06 Formats (although SASLIB
   SASLIB is still valid in SAS 6.06 to access SAS 5.18-built formats).

   As long as the 0FORMATS LIBRARY file built by member FORMATS is on
   your first disk, SAS 6.06 will automatically find MXG formats there.

 c.Virtual Storage requirement for MXG and SAS 6.06.

   Executing under VM/370, I have needed to execute in a 10MB machine,
   and also needed to disable "SAS Saved Segments", because when SAS is
   placed in Saved Segments, it begins at 7MB. The SAS Option NOSSEG is
   used to disable save segments.   Execution under VM/XA has not yet
   been successful.


 d.Standard options used in testing PreRelease 8.7 under CMS SAS.

   The following REXX exec has been used for testing under CMS SAS. It
   is functional, if not elegant!  It is printed here primarily so that
   you can see the default options and technique used that does allow
   MXG to execute under CMS SAS 6.06.  preceding the invocation of
   the exec, the  DEFINE STOR 10M command was issued, followed by the
   IPL CMS command.  Note that all data sets are directed to the "T"
   disk, a temporary disk of 199 cylinders which will disappear at
   logoff.  Also note that if SMF data is to be processed under CMS, the
   VMACSMF member's DCB attributes will need to be changed as discussed
   in Change 8.174.  A bigger generalized problem in my testing is the
   non-existence of an equivalent for DD DUMMY or a NULLFILE under CMS.
   Since I can't use a NULLFILE to syntax check each MXG member, I have
   to tediously create a sample record for each possible input source.
   There were problems with the CONCAT of the two source libraries under
   CMS that still have not been resolved; thus all testing was with only
   the MXG master source library (modified where necessary, ugh!) as the
   SOURCLIB filedef.  The MOD operand does not work properly for the SAS
   log without a SAS CMS ZAP.  But these are problems that can be
   circumvented so that MXG can be executed under CMS SAS 6.06 with the
   following exec.


        'CP SP CONS START TO * '
        TRACE ALL
        STD_OPTIONS=,
        'NODMS LOG=MODLOG PRINT=DISK VIOBUF=0 PS=60 LS=132 ERRORABEND',
           'NOSSEG BLKSIZE=1024 BUFSIZE=2048 MEMRPT STATS STIMER',
           'FULLSTIMER MAUTOSOURCE SASAUTOS=SOURCLIB DQUOTE SIODISK=T',
           'NOSOURCE NOSOURCE2 NOMACROGEN NOMPRINT NOMLOGIC'

        SETUP:
        'DEFINE T3380 AS 199 CYL 199'
        'FORMAT 199 T (BLKSIZE 4096'

        TESTVM:
        'FILEDEF SOURCLIB DISK SOURCLIB MACLIB * '
        'FILEDEF VMACCT   DISK TESTDATA VB A'
        'FILEDEF MONITOR  DISK TESTDATA VB A'
        'FILEDEF MWINPUT  DISK TESTDATA VB A'
        'FILEDEF EXPLORE  DISK TESTDATA VB A'
        'FILEDEF INSTREAM DISK INSTREAM TEMP * '
        DROPBUF
        MAKEBUF
        QUEUE 'OPTIONS ERRORABEND FIRSTOBS=1 OBS=2;'
        QUEUE 'LIBNAME VMPDB  ''T'';'
        QUEUE '%INCLUDE SOURCLIB(TESTVM); RUN;'
        QUEUE '/*'
        'SASMXG (' STD_OPTIONS
           IF RC>4 THEN DO
            SAY 'ERROR: RETURN CODE FROM SAS: ' RC
            SAY 'FIX ERROR AND RERUN TESTVM.'
            EXIT
           END
        DROPBUF


        TESTPDB:
        'FILEDEF SOURCLIB DISK SOURCLIB MACLIB * '
        'FILEDEF SMF      DISK SMFSMALL MXG A'
        DROPBUF
        MAKEBUF
        QUEUE 'OPTIONS ERRORABEND FIRSTOBS=1 OBS=2;'
        QUEUE 'LIBNAME PDB    ''T'';'
        QUEUE 'LIBNAME SPIN   ''T'';'
        QUEUE '%INCLUDE SOURCLIB(BUILDPDB); RUN;'
        QUEUE '%INCLUDE SOURCLIB(ANALCONT);'
        QUEUE '%INCLUDE SOURCLIB(ASUMJOBS);'
        QUEUE '%INCLUDE SOURCLIB(ASUMCICS);'
        QUEUE '/*'
        'SASMXG (' STD_OPTIONS
           IF RC>4 THEN DO
            SAY 'ERROR: RETURN CODE FROM SAS: ' RC
            SAY 'FIX ERROR AND RERUN TESTPDB:'
            EXIT
           END
        DROPBUF

IV. Documentation of MXG Software.

Member CHANGES always contains the version number of MXG Software, and
it lists changes that were installed in that version.  Several members
named CHANGEnn are the contents of changes when that "nn" MXG version
was created.  Details on enhancements will be found in the text of the
Change description that made the enhancement (in those CHANGES and
CHANGEnn members).  The CHANGE  members can also be scanned online (with
SPF BROWSE) to search for specific product name references (CICS,
MVS/ESA, etc.).  The text of each Change identifies the member(s) that
were altered or added by that change, and documentation (especially for
new product support) is often found in comments at the beginning of
those named members.

Member NEWSLTRS contains the text of all newsletters (up through the
newsletter that accompanied that MXG release). You can search NEWSLTRS
for product name or acronym to find the technical notes, APARs, etc.
from all MXG newsletters.  (The Change Log of each Newsletter is not
replicated in member NEWSLTRS, since that text will be in CHANGES).

Member DOCVERnn is the "delta-documentation" (in abbreviated Chapter
FORTY style) of only those variables and datasets that were changed
between successive MXG Versions. There is a DOCVERnn "delta" member in
the MXG library for each version.

Penultimately, member DOCVER contains abbreviated Chapter FORTY format
that documents all of the 26,355 variables from the 791 MXG data sets
that can be created by that MXG Software Version (alphabetically by data
set name and variable name).

Finally, MXG is a source distributed system, so you can often find your
answer by BROWSE/EDIT of the source member, especially the VMAC...'s
that actually create the data set, or ANAL....'s that analyze the MXG
datasets. In many instance, the MXG Variable is the IBM or Vendor's
documented field name. In other cases, the IBM field name is carried as
a comment beside the MXG variable that contains that information.  In
all cases, you should also have the Vendor's documentation of the
particular data record you are using for analysis.


V.  CHANGE LOG
--------------------------Changes Log---------------------------------

 You MUST read each Change description below to determine if a Change
 will impact your installation.  All of these changes have been made
 to this MXG Source Library.

 Member CHANGES of the MXG SOURCLIB will always be more accurate than
 the printed changes in a Newsletter, because the software is created
 after the newsletter is sent to the printer!

 Member CHANGES always identifies the actual version and release of
 MXG Software that is contained in that library.

 The actual code implementation of some changes in MXG SOURCLIB may be
 different that described in the printed NEWSLETTER (which might have
 printed only the easily installed, critical part of the correction).

 Always read the comments at the beginning of each source member named
 under the Change Number for impacting changes.

 Documentation of new datasets and variables, validation status, notes,
 etc., are usually in comments in the source members.



 While the earlier documentation of what's new in PreRelease 8.7
 described only the changes added after PreRelease 8.2, the following
 list of "Significant Changes" covers ALL changes made since MXG 7.7.

 Following the list of Significant Changes, the complete text of Changes
 Change 8.186 thru Change 8.079 are printed; prior Changes' text was
 printed in Newsletter SEVENTEEN.

 Changes thru 8.078 were printed in NEWSLETTER SEVENTEEN.
 Changes thru 8.087 were contained in PreRelease 8.2, Jul 20, 1990.
 Changes thru 8.119 were contained in PreRelease 8.3, Aug 26, 1990.
 Changes thru 8.157 were contained in PreRelease 8.4, Oct  9, 1990.
 Changes thru 8.168 were contained in PreRelease 8.5, Oct 27, 1990.
 Changes thru 8.169 were contained in ESPRelease 8.6, Oct 27, 1990.
 Changes thru 8.186 were printed in NEWSLETTER EIGHTEEN.


Alphabetic INDEX of significant changes:

  Member    Change   Description

  ANALDB2R  8.030  DB2 Reporting from GTF data fails.
  ANALDB2R  8.031  DB2 Report PMLOK03 fails with 170 format error.
  ANALDB2R  8.067  Report selection by time frame incorrect, minor.
  ANALDB2R  8.084  DB2 Trace reporting with PDB=SMF avoids IMAC102.
  ANALDB2R  8.121  PMAUD02/PMAUD03 request caused SAS 145/170 error.
  ANALDSET  8.077  ACCESS variable was not created, report failed.
  ANALPRTR  8.146  New printer capacity analysis system.
  ASMTMNT   8.070  MXG Tape Mount Monitor on 7.7 does support MVS/ESA.
  ASMVTOC   8.117  Assembly program for Fast reading of DASD VTOCs.
  ASUMCICS  8.023  Variable LENGTHs caused trunction.
  ASUMCICS  8.076  Response buckets off by one.
  ASUMJOBS  8.076  Response buckets off by one.
  ASUMTMNT  8.076  Response buckets off by one.
  BUILDPDB  8.069  ACCOUNT/SACCT in SMFINTRV, SPIN in PDB, TYPE25 added.
  CICINTRV  8.182  CICINTRV data set created from statistics datasets.
  CONFIG    8.068  SAS 6.06 options member added to MXG library.
  DOCDB2PM  8.112  Documentation of DB2PM-like reports in ANALDB2R.
  DOCTREND  8.113  Incompatible changes in MXG Trending implemented.
  EXACFJR   8.047  ACF2 dataset ACF2JR may have deleted observations.
  EXIDMTAS  8.105  IDMS Batch ACCOUNT1-3 fields decoded.
  FMXGUCBL  8.009  Returns wrong value under SAS 5.18.
  GRAFWORK  8.140  New graphic report of RMFINTRV workloads by hour.
  IMACACCT  8.133  Safer/Easier user definition of Account fields.
  IMACICDB  8.177  CICS/ESA 3.1 Transaction DBCTL counters/clocks.
  IMACPDB   8.048  Variables ABNDRSNC DIVRREAD DSSIZHWM TERMNAME added.
  JCLTEST   8.001  Options MACRO DQUOTE MWORK=28K required by MXG.
  JCLTEST   8.025  WORK.DIRMACR REQUIRES MORE SPACE error condition.
  JCLTREND  8.058  PROC SORT added to avoid not-sorted condition.
  MONTHBLD  8.095  Syntax error under SAS 6.06 circumvented.
  MVS 4.1   8.167  Support for MVS/ESA SP Version 4.1 and RMF 4.2.
  NPM       8.038  NPM records from VM can be processed.
  SPIN      8.158  SPIN library fills when MVS/ESA replaces MVS/XA.
  SPIN      8.172  SPIN library fills when MVS/ESA replaces MVS/XA.
  TRNDRMFI  8.143  Critical error, but only in PreRelease 8.3.
  TRND72    8.143  Critical error, but only in PreRelease 8.3
  TYPEDCOL  8.074  Support for SMS DCOLLECT data records.
  TYPEIMS   8.006  IMS crashes caused duplicate DTOKEN.
  TYPEIMS   8.119  Significant correction of IMS Input Queue time.

  TYPEMONI  8.036  CREATIME in MONITASK may have wrong date.
  TYPEMON8  8.161  Support for Landmark's Monitor for CICS Version 8.0
  TYPEORAC  8.080  Support for Oracle SMF record.
  TYPETSOM  8.007  Missing STRTTIME in TSOMCMND.
  TYPE110   8.065  Support for new CICS 3.1.1 major changes.
  VMACACF2  8.002  ACF2 SMF record caused STOPOVER.
  VMACACF2  8.090  Further validation of ACF2 SMF record.
  VMACCIMS  8.064  Support for IMF 2.6 (for IMS 3.1).
  VMACCRAY  8.044  New code. Support for CRAY COS operating system
  VMACDB2   8.102  Distributed DB2 header added to DB2ACCT.
  VMACDCOL  8.130  DCOLLECT enhancement for all seven records.
  VMACDMON  8.003  Uninitialized variable in ANALDMON caused.
  VMACHSM   8.138  Preliminary support for HSM User SMF records.
  VMACIDMS  8.005  IDMS SMF record variables format incorrect.
  VMACIMS   8.042  Minor IMS log processing changes.
  VMACIMS   8.098  Support for IMS/ESA 3.1 log records.
  VMACIMS   8.118  IMS Cold start support and logic changes.
  VMACIMS   8.176  IMS 3.1 DBCTL Thread Transactions Deleted.
  VMACMDF   8.091  Amdahl's MDFTRACH SMF records corrected.
  VMACMPT   8.173  Support for Amdahl's MDF Performance Tool
  VMACNSPY  8.010  NETSPY 3.2 support was incomplete.
  VMACNSPY  8.043  Netspy 3.1 STOPOVER.
  VMACROSC  8.028  ROSCOAUD contained zero observations always.
  VMACSASU  8.157  SAS User Record changed under SAS 6.06.
  VMACSMF   8.013  DB2 read from GTF. Minor.
  VMACSPMS  8.149  Support for Amdahl's SPMS SMF (Cache DASD CU).
  VMACSTC   8.092  STC 4400 Silo SMF record new subtype.
  VMACSYNC  8.020  Invalid CPUTCBTM value detected.
  VMACSYNC  8.056  SIRECFM,SORECFM contain invalid data value.
  VMACSYNC  8.123  Error (only in PreRelease 8.2) in TYPESYNC data.
  VMACTMNT  8.033  Minor. Formats for DEVFROM/DEVTO.
  VMACTMVS  8.173  Protection for TMON/MVS Spanned Records
  VMACTPX   8.016  No observations in TPXINTRV.
  VMACTSOM  8.104  Invalid READTIME due to CA7 in TSO/MON record.
  VMACVMON  8.037  Divide by zero.
  VMACVMON  8.045  24APR90 became 02OCT89 when 202 day clock wrapped.
  VMACVMON  8.106  VM Start Time off by 43 minutes on Aug 4, 1990.
  VMACVMXA  8.004  OMEGAMON/VM creates invalid VM/XA VB records.
  VMACVMXA  8.099  Many VM/XA PTFs altered Monitor records.
  VMACVMXP  8.041  Minor EXPLORE/VM processing changes.
  VMACVVDS  8.073  Validation of VVDS record created by ASMVVDS.
  VMACWSF   8.100  Support for WSF archive product SMF.
  VMACX37   8.024  STOPX37, minor.
  VMACZRB   8.054  RMF 4.1.1 caused STOPOVER.
  VMACZRB   8.079  Further validation of RMF III VSAM data.
  VMACZRB   8.156  Further validation and reports.
  VMAC110   8.040  CICSTRAN may have 0 observations with CICS 1.7.
  VMAC1415  8.017  New HiperBatch counts added to SMF type 1415.
  VMAC1415  8.137  HiperBatch values non-zero when they should be zero.
  VMAC28    8.111  INPUT function error in NPM subtype 82.
  VMAC28    8.148  Support for NPM Release 4 (NPM 1.4), SMF Type 28.
  VMAC30    8.081  Support for APAR adding DDCONS() option.
  VMAC30    8.082  Support for APAR adding PROCSTEP to type 30s.
  VMAC37    8.022  Variable KEEP, FORMATs.
  VMAC39    8.022  TYPE39EL conditionally created. ZDATE kept.
  VMAC41    8.015  New VLF counts in new subtype 3 SMF type 41.
  VMAC42    8.136  STOPOVER on subtype 3 due to IBM error.
  VMAC6     8.057  STOPOVER due to invalid external writer record.
  VMAC57    8.184  STOPOVER on type 57 (MVS 4.1 and MXG 8.5 only).
  VMAC60    8.128  STOPOVER on SMS NVR segment in type 60.

  VMAC6156  8.027  STOPOVER error with ICF catalog record section.
  VMAC6156  8.034  Minor. Variable FUNCTION more values decoded.
  VMAC6156  8.039  TYPE6156 VOLSER may be wrong for GDGs.
  VMAC64    8.134  ACBMACRF fields individually decoded into variables.
  VMAC7072  8.066  Support for new "SRCL" field in RMF Product section.
  VMAC78    8.049  TYPE78CF only output if CHPID is online.
  VMAC78    8.132  STOPOVER on type 78 subtype 3 with ES/9000 CPUs.
  VMAC79    8.012  STOPOVER correction, support validation.
  VMAC79    8.055  Formats and units corrections.
  VMXGSUM   8.021  Missing variable initialization protection.
  VMXGVTOC  8.018  OFFSET4E and SMS variables added.
  VMXGVTOC  8.032  Minor. RECFM should be $4.
  VMXGVTOC  8.075  Did not capture free space at beginning of volume.
  VMXGVTOR  8.009  Incorrect on 7.7, changes not propagated.
  XMACEPIL  8.019  Plus sign missing. Don't use VMACEPIL or XXACEPIL.
  XMAC7072  8.014  ZDATE not kept in TYPE70PR and TYPE72MN
  XMAC71    8.014  Extraneous period.
  ZZZZZZZZ  8.011  Final member of MXG Library is named.

Inverse chronological list of all Changes:

  Changes 8.186 thru 8.079, and 8.008 were printed here.

  See member CHANGE08 for actual change text.

End of Changes Log in Newsletter EIGHTEEN.
****************NEWSLETTER SEVENTEEN************************************










             MXG NEWSLETTER NUMBER SEVENTEEN July 10, 1990

Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE

                         TABLE OF CONTENTS

I.   MXG SOFTWARE Version status.                               page   2
  1. Production MXG Version is still 7.7.                              2
  2. PreRelease MXG Version 8.2 available upon request.
  3. Enhancements completed in PreRelease 8.2.
  4. Enhancements that didn't make it.
II.  TECHNICAL NOTES                                            page   3
  1. "SMF and RMF Data Enhancements in MVS/ESA"                        3
     a. New MVS/ESA CPU measurements in type 30 record.                3
     b. Absence of these new CPU measures in type 72 record.           4
     c. Additional new MVS/ESA workload measurement data               5
     d. TYPE 71 Overall System Memory measurements in MVS/ESA.         5
     e. TYPE72MN - RMF III Monitor subtype of type 72 record           6
     f. I/O Activity measurement, non-VSAM, VSAM, DASD, TAPE.          6
     g. Improved capture of JES Printing activity                      7
     h. TYPE70PR  - PR/SM Processor Partition Data                     8
     i. Data-In-Virtual (DIV) and Virtual Lookaside Facility (VLF).    9
     j. DFP 3.2 Statistics and Configuration                          10
     k. Structural changes in SMF writer recording and its functions. 12
     l. Additional SMS information in DASD VTOCs.                     13
  2. MVS PTFs and/or APARs.                                           13
  3. MVS Technical Notes.                                             15
     a. ACTFRMTM notes.                                               14
     b. No DB2 I/O counts in SMF data.                                14
     c. Identify lost Index in Indexed VTOCs.                         15
     d. Instantaneous 4.5 MB/sec channel speed versus sustainable.    15
     e. Long Channel Programs affect Channel Measurements.            15
     f. Erase on Delete can be set accidentally by RACF.              15
     g. SPF EDIT subcommand COPY renumbers line numbers.              15
  4. VM PTFs and/or APARs.                                            16
  5. CICS Technical Notes.                                            16
     a. Major structural changes in CICS 3.1.1 measurement data.      16
     b. Changes to MXG Data Set CICSEXCE in CICS 3.1.1                17
     c. Changes to MXG Data Set CICSTRAN in CICS 3.1.1                18
     d. New CICS 3.1.1 Statistics Data Sets descriptions.             21
     e. Observed errors in CICS 2.1 CICSYSTM and MONITASK CPU time.   22
  6. SAS 6.06.01 Issues and MXG recommendations.                      23
     a. SAS 6.06 ERROR Conditions requiring ZAPS to be installed.     24
     b. SAS 6.06 Incompatibilities which required MXG Source Changes. 26
     c. Additional SAS 6.06 compatibility items.                      28
     d. Performance measurement comparisons and performance zaps.     31
     e. Summary of MXG required or recommended SAS ZAPs for 6.06.     31
III. Documentation of MXG Software.                                   32
IV.  CHANGE LOG, Changes 8.072 to 8.001.                        page  33
      (Alphabetic INDEX of Significant Changes on page 34)      thru  56

         COPYRIGHT (C) 1990 BY MERRILL CONSULTANTS DALLAS TEXAS
          MXG IS A REGISTERED TRADEMARK OF MERRILL CONSULTANTS
          SAS IS A REGISTERED TRADEMARK OF SAS INSTITUTE






I.   MXG SOFTWARE Version status.

  1. Production MXG Version is still 7.7.

 There is no new software automatically shipped with this newsletter.
 MXG Version 7.7 (which shipped in February, 1990) is the production
 version. MXG 7.7 already supports MVS/ESA 3.1.1, new 3390 DASD devices,
 3490 Tape Drives, IDRC, and everything else that was available in Feb.
 All reported errors are described and fixed in this Newsletter, and
 most sites will probably not require the PreRelease of MXG 8.2.
 We do not expect to ship the production Version 8 until early 1991.

  2. PreRelease MXG Version 8.2 available upon request.

 MXG PreRelease 8.2 is now available upon request to supported sites.
 All of the Changes listed in the newsletter are included in MXG 8.2.
 The major enhancements in PreRelease MXG 8.2 are listed below, and the
 Changes section of this newsletter describes all of the enhancements.
 There is no cost for the PreRelease.  Simply contact us by phone, fax,
 or letter (overseas, your local SAS office will relay your request),
 and we will be pleased to send you your copy of MXG PreRelease 8.2.

  3. Enhancements completed in PreRelease 8.2.

     a. Support for new CICS/ESA 3.1.1 Monitor and Statistics Data.
     b. Support for new Cray hardware COS 1.16 Operating System Data.
     c. Support for new VLF subtype 3 in SMF type 41.
     d. Support for new HiperBatch stats in SMF type 14, 15, and 64.
     e. Support for new SMS utility DCOLLECT data records.
     f. Support for new Oracle SMF record.
     g. Source changes required for SAS 6.06 compatibility.
     h. Support for IMF 2.6 (for IMS 3.1).
     i. VTOC support enhanced with OFFSET4E and SMS variables added.
     j. BUILDPDB/3 Enhancements.
        - SPIN library copied into PDB for backup and recovery
        - ACCOUNTn and SACCTn added to SMFINTRV.
        - TYPE25 processing added for JES3.
     k. NPM records from VM can be processed.
     l. Note: MXG 7.7 requires MACRO DQUOTE MWORK=28K options for 5.18.
     m. Corrections to all reported errors in MXG 7.7.

  4. Enhancements that didn't make it.

     a. LLA (User coded exit) SMF record.
     b. WSF2 SMF record.
     c. Cray COS 1.17
     d. Cray UNICOS.
     e. VAX/VMX Accounting and SPM data.
     f. Landmark CICS Release 8.
     g. HSM SMF record completion.
     h. JES3 Tape Mount Merge with TYPETMNT.
     i. Corrections to MXG support of Amdhal's MDFTRACK record.
     j. Change 8.008 for VMACVMON errors.


II.  Technical Notes.

  1. "SMF and RMF Data Enhancements in MVS/ESA"

  This paper has been presented at:

       UKCMG 90  Glasgow, Scotland  May 21, 1990
       SWCMG     Austin, Texas      Jun 21, 1990

This paper identifies the significant changes in data elements that are
captured (and those that are NOT captured) in MVS/ESA. New CPU times
that are captured in SMF type 30 records (but not captured in RMF type
72 records) dramatically affect billing and capacity measurement.  Steps
usage of HIPERSPACE/Data Spaces resources (such as invoked sorts) are
captured.  "Active frame time", captured by each performance group, may
be an accurate measure of central+expanded memory occupancy. Printer
activity can be identified to the step which caused the printing. The
SMF VSAM data set (finally) will use a half-track CI size.  These
highlights and other details will update the changes between MVS/XA and
MVS/ESA, including ESA 3.1.3.



     a. New MVS/ESA CPU measurements in type 30 record.

Three New MVS/ESA CPU measures, two old, one new, have been added to the
SMF type 30 records, which is the source of job accounting and job-level
capacity measurement.


  "RCT"  - Region Control Task (Quiesce/Restore/Swap), caused by TSO and
CPURCTTM   Batch swapping.  This time has always existed, (in uncaptured
           CPU), and is the major contributor to low TSO capture ratios.

  "IIP"  - I/O Interrupt Processing (Second Level Interrupt Handler, the
CPUIIPTM   SLIH CPU time).  This time has always existed, (in uncaptured
           CPU), and affected all workload's capture ratios.

  "HPT"  - Hiperspace processing CPU time. This time is new. Hiperspace
CPUHPTTM   CPU time displaces functions which formerly were measured in
           TCB or SRB. Using Hiperspace for SORT processing will reduce
           the step TCB CPU time, because function was moved from TCB to
           Hiperspace.  IBM's DFSORT 11 announcement showed a sort that
           reduced TCB from 100 to 50 seconds, but the new HPT CPU time
           bucket contained 25 CPU seconds. The true reduction was only
           from 100 to 75 seconds!  Using TCB and SRB only for Billing
           and Capacity will be wrong with Hiperspace processing. Note
           that Hiperspace CPU time is only recorded for tasks executing
           in User Protect Keys, and only User Key Data Spaces are under
           control of the IEFUSI exit for size. Most IBM uses of Data
           Spaces (HiperBatch, VLF, DFP, CATALOG) use KEY Zero just so
           they can avoid IEFUSI virtual storage limitations, and thus
           they do not record HPT CPU time (nor DSSIZHWM, see below).


Moral: You must use all seven of the CPU measures in the type 30 record:
       (MXG's variable CPUTM has always been the sum of ALL CPU values).

 CPUTM=CPUTCBTM+CPUSRBTM+CPITCBTM+CPISRBTM+CPURCTTM+CPUIIPTM+CPUHPTTM.

     b. Absence of these new CPU measures in type 72 record.

Of greater concern to capacity planning is the absence of these new CPU
measures in the type 72 RMF performance group data:


TYPE 70 (RMF-captured CPU measurement of real or logical CPUs)



      Elapsed Interval (Duration multiplied by number of CPUs)
   __________________________________________________________________


   ________________________________________________________ ---------
                        CPU                                    CPU
                      Executing                              Waiting


   __________ ________ _________ ________ ________ ________
    CPU 1      CPU 2    CPU 3     CPU 4    CPU 5    CPU 6
     Busy       Busy     Busy      Busy     Busy     Busy


   ________________________________________________________

    Total Hardware CPU Busy Time (from Type 70 "non-wait")


  TYPE 72 (use only the control performance groups)


   _____ _____ --------------------------------------------
    RMF   RMF                  Uncaptured
    TCB   SRB                  RMF CPU Busy
    CPU   CPU

   ___________ ----------------------------- --------------
      CPUTM     Existed,   Moved from  New,   Uncapturable
    =TCB+SRB    Never has  Uncaptured  was      RMF CPU
                been in    to IIP/RCT  RMF
                RMF        in 30's     TCB


  TYPE 30 (all work started and ended):


   _____ _____ _____ _____ _____ _____ _____ --------------
    SMF   SMF   SMF   SMF   SMF   SMF   SMF   Uncapturable
    TCB   SRB   TCB   SRB   IIP   RCT   HPT     SMF CPU
    CPU   CPU   CPI   CPI   CPU   CPU   CPU
   _________________________________________

    CPUTM=Sum of all 7 CPU times in TYPE30

     c. Additional new MVS/ESA workload measurement data


TYPE 30 Step Hiperspace/Data Space Activity

    HIPAGINS - Hiper Page Ins (from Auxiliary DASD)
    HIPAGOUT - Hiper Page Outs (to Auxiliary DASD)
    DSSIZHWM - Data Space/Hiperspace High Water Mark, Megabytes, but
               is recorded only if task is in a User Protect Key. Tasks
               in Protect Key 0 do not record DSSIZHWM.  A nonzero value
               of DSSIZHWM identifies a Data Space or Hiperspace user.
    CREADMIS - Hiperspace Read Misses (also called CREADS by IBM)
    DIVRREAD - Address Space total Reread Count
    ABNDRSNC - ABEND reason code
    TERMNAME - Terminal Identification

TYPE 72 Performance Group paging/memory measures

    HIPPGINS - Hiperspace Page Ins (from Auxiliary DASD)
    HIPRDMIS - Hiperspace Read Misses (CREADMIS in TYPE 30s)
    PGPAGEIN - Page Ins (from Auxiliary DASD)
    ACTFRMTM - Frame-seconds of memory occupancy while tasks in
               this performance group period were "SRM Resident".
               This includes both Central Store and Expanded Store
               frames, but does not include Nucleus or Common Area
               (since they are not in an address space), and does
               NOT include frames of Logically Swapped ASIDs.
    MSOUNITS - Represents frame-seconds of Central Store memory
               occupancy, but only while executing TCB.

                                ACTFRMTM               MSOUNITS
    Estimated ESTORE Frames = (-----------)  -  (--------------------)
                                RESIDTM          50*MSOCOEFF*CPUTCBTM


     d. TYPE 71 Overall System Memory measurements in MVS/ESA


       Area      Expanded Frames     Central ("Real") Frames
                 Avg, Min, Max       Avg, Min, Max
                 Measures            Measures

       CSA       CSAEXAV,MN,MX         n/a
       Hiper     HIPEXAV,MN,MX         n/a
       LPA       LPAEXAV,MN,MX         n/a
       LSQA      LSQAEXAV,MN,MX      LSQAREAV,MN,MX
       REG+SQA   REGSEXAV,MN,MX        n/a
       SQA       SQAEXAV,MN,MX       SQAREAV,MN,MX
       VIO       VIOEXAV,MN,MX         n/a


       Type      Pages           Pages             Pages
                 Read            Written           Migrated
                 From ESTORE     To ESTORE         To Aux

       Hiper     HIPREADS        HIPWRITS          HIPMIGRS
       VIO       VIOREADS        VIOWRITS          VIOMIGRS

       Total     EXTREADS

       Hiper page ins    HIPAGINS
       Hiper page outs   HIPAGOUT

     e. TYPE72MN - RMF III Monitor subtype of type 72 record


MVS/ESA creates an RMF record from RMF Monitor III, but only a small
part of the data captured by RMF III is written to SMF, for each
Performance Group

  User Statistics                Frame Statistics

  AVGUSER  - Logged On           FRAMEACT - Active Frames
  AVGACTS  - Active Users        FRAMEDIV - DIV Frames
  AVGACTV  - Active Not OUTR     FRAMEFIX - Fixed Frames
  AVGDIVS  - D-I-V Users         FRAMEIDL - Idle Frames
  AVGIDLS  - Idle Users

  Delayed Users Statistics       Miscellaneous

  AVGOUTR  - Out and Ready       FRAMEASM - Slots Used
  AVGPAGDL - Delayed Paging      PGINRATE - Page Ins
  AVGSWPDL - Delayed Swap        DOMAIN   - Domain
                                 PERFGRP  - Perf Group
  Averages of Averages

  WSETACT  - Avg working set per active user
  WSETASM  - Avg ASM slots used per user
  WSETDIV  - Avg working set per DIV user
  WSETFIX  - Avg fixed frames per user
  WSETIDL  - Avg working set per idle user


     f. I/O Activity measurement, non-VSAM, VSAM, DASD, TAPE.


TYPE1415 Non-VSAM File, for each open of each file.

 DSSNO      Dataset serial number
 IDRC       3480 IDRC compaction used?
 NULLSEG    null segment encountered?
 PDSE       PDSE (formerly ILIB) managed data set?
 SMFCHITS   HiperBatch successful searches
 SMFCIOS    HiperBatch DASD I/Os copied into buffers
 SMFIOREQ   HiperBatch total searches
 SMFNMWTS   HiperBatch conflict suspends
 SMFPHIOS   HiperBatch searchs that caused DASD I/O
 TRUNC      TRUNC MACRO issued?

TYPE64 VSAM File, for each open of each file.

 ACBBUFND   BUFND - Number of Data Buffers
 ACBBUFNI   BUFNI - Number of Index Buffers
 ACBBUFSP   BUFSP - Buffer Space
 ACBMACR    MACRF flag bytes (Random, Seq, Input, Output, etc.)
 ACBSTRNO   STRNO - String number
 BUFDRNO    Actual number of buffers
 JCFBDSNM   Cluster Name
 PLHCNT     Actual number of concurrent strings
 SMF64HIT   HiperBatch successful searches
 SMF64IOS   HiperBatch DASD I/Os copied into buffers
 SMF64MIS   HiperBatch searches that caused DASD I/Os
 SMF64SIO   HiperBatch total searches
 SMF64WTS   HiperBatch conflict suspends

TYPE74 DASD Volume Activity

 DASDRCFG - Number/Storage Group Options

TYPE 21 Tape Volume Dismount

 BYTEREAD  Bytes read
 BYTEWRIT  Bytes written
 DCBOFLG   DCBOFLG control byte
 DEVICE    Device type
 OPEN      Type of OPEN
 TAPCUSER  Tape unit serial of creation device
 TAPUNSER  Tape unit serial of this device
 TEMPRBER  Temporary read backward errors
 TEMPRFER  Temporary read forward errors
 TEMPWRER  Temporary write (buffered) errors


     g. Improved capture of JES Printing activity


TYPE6 JES Printer Record Enhancements

Step identification of source of print

 SMF6DDNM   DDNAME that created printing
 SMF6DSNM   JES assigned temporary DSNAME of the print dataset
 SMF6PRNM   PROCSTEP that created printing
 SMF6STNM   STEPNAME that created printing
 SMF6USID   USERID that created printing
 SUBSYS6    Printing Subsystem (JES/PSF) used.
 SMF6PRMD   Processing mode (PAGE/LINE) of print.
 SMF6FDNM   FORMDEF name used
 SMF6PDNM   PAGEDEF name used
 SMF6PTDV   PRINTDEF name used

Print security identification

 SMF6NPS    Security page segments used
 SMF6NSFO   Security fonts used
 SMF6NSOL   Security overlays used
 SMF6OTOK   Output user security token
 SMF6SECS   Security label of print dataset

Available only with MXG modification to JES2 (see 7.7 member CHANGES).

 RLSETIME   Time SYSOUT was released for printing

Yes/No Flags.

 BINnUSED   BIN Number n was used?
 CONTRIN0   SPIN data set?
 CONTRIN1   Operator terminated print?
 CONTRIN2   Operator restarted print?
 CONTRIN3   Print intrepreted?
 CONTRIN4   Operator interrupted print?
 CONTRIN5   Print continuation?
 CONTRIN6   Operator overrode?
 CONTRIN7   Restart with destination?
 CONTRIN8   Received operator restart?
 CONTRIN9   Operator started single space?
 DIADPLWS   Data page labelling suppressed?
 DIAJHWP    Job trailer page printed?
 DIASLIG    Job header page printed?
 DIAUPAWS   User print are suppressed?
 DPAGELBL   Keyword DPAGELBL=YES?
 ERROVRUN   Image overrun error?
 ERRSECOV   Error in security overlay?
 INTEGRTY   Security label integrity?
 PRSUCCES   Print operation successful?
 SPAGELBL   Keyword SPAGELBL=YES?
 STDUPLEX   Standard duplex used?
 SYSAREA    Keyword SYSAREA=YES?
 TMBUPLEX   Tumble duplex used?


     h. TYPE70PR  - PR/SM Processor Partition Data


Durations of partition

 DURATM     Duration of interval
 LCPUPDTM   Logical processor dispatch time
 PRSMSLIC   Dispatch interval timeslice

Identification of partition

 LCPUADDR   Logical processor CPUID address
 LPARNAME   Logical partition name
 LPARNUM    Logical partition number

Status flags and numbers

 DIAG204F   Diagnose X204 failure?
 LCPUDED    Logical processor dedicated?
 LCPUWAIT   LPAR Wait Completion (Yes/No)?
 NRPRCHGD   Was the number of CPUs changed?
 PARTFLG    Was the Partition deactivated?
 SLICCHGD   PRSMSLIC Time-slice was changed?
 LCPUSHAR   Processor relative share
 LPARCPUS   Number of CPUs in this LPAR
 NRCPUS     Number of CPUs
 NRPRCS     Number of logical partitions
 PARTISHN   Partition number of this MVS
 PARTNCPU   Nr of CPUs available to this partition

 Do not use PR/SM CPU measures without reading ZZ05-0453-01 (Jan, 1990),
 "PR/SM Performance in LPAR Mode", WSC Technical Bulletin, which shows
 that PR/SM has a "Low Utilization Effect" making PR/SM look like it
 uses more CPU time than it really does. (This ZZ publication is labeled
 "IBM Internal Use Only", but your IBM SE will let you see it).

     i. Data-In-Virtual (DIV) and Virtual Lookaside Facility (VLF).


TYPE41AC (DIV Accessed) and TYPE41UN (DIV Unaccessed)

Common to both Access and Unaccess

 ACCSTIME   Time when object was accessed
 DDNAME     DDNAME used
 JOB        Job name or TSO user accessing object
 OBJMODE    Access mode (Read/Update)
 OBJSIZEA   Object size (blocks) when accessed
 OBJTYPE    Object type (DA)

Additional data at Unaccess only in TYPE41UN

 IOCALREA   Total I/O calls for read
 IOCALWRT   Total I/O calls for write
 OBJSIZEU   Object size (blocks) when unaccessed
 TOTREADS   Total blocks read (including rereads)
 TOTRREAD   Total blocks re-read
 TOTWRITE   Total blocks written
 UACCTIME   Time when object was unaccessed

TYPE41VF Virtual Lookaside Facility (VLF) statistics

APARs OY28799 and OY28800 for MVS/ESA create a type 41 new subtype 3
interval (15 min) record for each class in the COFVLFnn PARMLIB member.

 SMF41CLS   Class name
 SMF41SRC   Times cache was searched
 VLFHITPC   Percent of searches found in VLF

 SMF41ADD   Objects added to cache during interval
 SMF41DEL   Objects deleted from cache
 SMF41FND   Objects found in cache
 SMF41TRM   Objects trimmed from cache

 SMF41LRG   Largest object ever attempted
 SMF41MVT   MAXVIRT specified
 SMF41USD   Amound of storage used


     j. DFP 3.2 Statistics and Configuration


TYPE 42 record contains 3 subtypes and MXG creates 5 datasets.

TYPE42AU "Audit" VARY SMS, ACTIVATE SMS, or ENF events when they occur.

 CURRTIME   Current update timestamp
 SMF42EAC   Activate, ENF, or VARY SMS?
 SMF42EAD   Active control dataset name
 SMF42ENS   New MVS volume status
 SMF42EOS   Old MVS volume status
 SMF42ERC   Return code
 SMF42ERS   Reason code
 SMF42ESD   Source control dataset name
 SMF42ESN   Name of storage group
 SMF42EST   Resulting status after action
 SMF42ESY   "ALL", or first 8 system names
 SMF42EUA   UCB address for the device
 SMF42EVL   Volume serial number

TYPE42CU Model 3990-3 Cache Control Unit Statistics, for each cache
controller having an SMS volume attached.

 Identification and timestamps

 SMF42CID   Subsystem identifier
 CURRTIME   Current update timestamp
 LASTTIME   Last update timestamp

 Statistics during interval

 SMF42AFW   Average fast-write waits per minute
 SMF42AHR   Average hit ratio
 SMF42CCT   Current I/O count for the subsystem
 SMF42LCT   Last I/O count for the subsystem
 SMF42CFW   Current fast write wait count
 SMF42LFW   Last fast write wait count
 SMF42CRH   Current cache normal read hit percent
 SMF42LRH   Last cache normal read hit percent
 SMF42CWM   Current fast write waits per minute
 SMF42LWM   Last fast write waits per minute

 Storage capacity/availability

 SMF42CSS   Subsystem storage capacity
 SMF42NCS   Subsystem non-volatile storage status
 SMF42NSZ   Non-volatile cache capacity
 SMF42SAP   Storage allocated for PINNED data
 SMF42SCS   Storage director caching status
 SMF42SPR   Non-volatile storage allocated for PINNED
 SMF42SSA   Storage available for allocation as CACHE
 SMF42SSU   Storage unavailable due to failures

TYPE42VL Status for each SMS volume behind 3990-3

 CURRTIME   Current update timestamp
 SMF42CID   Subsystem identifier
 SMF42DB1   Device status flags one
 SMF42DB2   Device status flags two
 SMF42DEV   Device number
 SMF42VOL   Volume Serial Number

TYPE42SC Storage Class Buffer Manager Facility (BMF) Statistics for each
Storage Class. (Interval set in IGDSMSnn).

 DURATM     Interval duration
 ENDTIME    End timestamp of the interval
 SMF42PNN   Storage Class Name
 SMF42SDH   Directory data page read hits
 SMF42SDT   Directory data page reads
 SMF42SRH   Member data page read hits
 SMF42SRT   Member data page reads
 STARTIME   Start timestamp of the interval

TYPE42TO Buffer Manager Facility (BMF) Totals for all Classes.

 DURATM     Interval duration
 ENDTIME    End timestamp of the interval
 SMF42LGE   Largest size of storage
 SMF42TDH   Directory data page read hits
 SMF42TDT   Directory data page reads
 SMF42TNA   Number of storage classes
 SMF42TRH   Member data page read hits
 SMF42TRT   Member data page reads
 STARTIME   Start timestamp of the interval

     k. Structural changes in SMF writer recording and its functions.


Control Interval size of SMF VSAM data set can be 22K (finally!!). Large
CI size is desired because it significantly reduces all costs of writing
and reading SMF records. The support for Large CI size is in ESA 3.1.3,
or in MVS/XA PTF OY19862.  SMF always gets 259 buffers (CIs) at startup.
With 4K CI size, SMF needed 1 MB virtual (4096*259=1MB), but with a 22K
CI size, SMF now requires a 6 MB address space (22K*259=6MB).

SMF Exits can now use 31-bit addressing AMODE(31)

Callers in Cross Memory can call SMF (MODE=XMEM on SMFEWTM) and a new
SMF exit (IEFU85) exists for records to be written by these callers in
cross memory.

Internal buffers are now in 31 bit storage (i.e., no longer below the
16MB line).

A fixed maximum of 32MB can be used for SMF buffers.

If over 80% of the current buffers are in use (i.e., un-written), the
Buffer Shortage message is displayed, and will be redisplayed if the
number of buffers increases. SMF will get 200 more buffers (CIs) at a
time, up to a maximum of 4000 (=32MB).  As buffers are freed, the
percentage in the message does not decrease. When the percentage is
below 70% the Buffer Shortage message is deleted.

A new NOBUFFS option in SMF PARMLIB controls SMF action when the last
SMF buffer fills.
    MSG  - send message and enter data lost mode (default)
    HALT - put system in restartable WAIT STATE ('D0D-00')

A new LASTDS option in SMF PARMLIB controls SMF action when the last SMF
dataset fills.
    MSG  - send message, start buffering data (default)
    HALT - put system in restartable WAIT STATE ('D0D-01')

SMF internal buffers can be recovered from a dump after a system crash.
The new IPCS SMFDATA command can read a SYSMDUMP, SVCDUMP, or Standalone
dump data set and will reclaim the SMF buffers as they stood at crash
into a VSAM data set; the VSAM data set must be empty and have the same
CI size as the original SMF dataset.

     l. Additional SMS information in DASD VTOCs.


System Managed Storage (SMS) now uses formerly reserved bits located at
offset '4E'x in the DSCB1 in your VTOCs. DASD products like DMS/OS and
ASM2 have used these bits, and local modifications (to CSECTS IFG0196W
and IFG0194E) have also caused this "DSCB Contamination".IBM published
"Clean up VTOCs Before Implementing DFP V3" (as WSC Flash 9009, Hone
Entry G022345) to advise you of the exposure. If DSCB contamination is
found, you must not only clean the VTOCs of your online data sets, but
you will need to also clean all migrated datasets, since their DSCBs
were also migrated and your migration software will need to correct the
contamination when datasets are recalled. Vendors of the above products
have fixes to their products to deal with this "DSCB Contamination"

  These new SMS variables are contained in DASD VTOCs.

  DS1CRSDB  DADSM Create originated blocksize?
  DS1PDSE   PDSE Managed Dataset?
  DS1REBLK  Data set may be reblocked?
  DS1SCCPF  Secondary is compacted factor value of 1, 256, or 65536.
  DS1SECUN  DS1SECUN units avg block, bytes, kilo or mbytes (A/B/K/M)?
  DS1SCXTV  Secondary space extension value
  DS1SMSDS  System managed (i.e., SMS) dataset?
  DS1SMSUC  No BCS entry exists for data set?
  OFFSET4E  Offset 4E into DSCB1 (used by SMS)

There is a new SMS Utility, DCOLLECT, that creates a flat file from VTOC
and VVDS records that is supported in MXG PreRelease 8.2 Change 8.07x.
an There wil be an evaluation and comparison of DCOLLECT output with
MXG's VMXGVTOC, ASMVVDS and VMACVVDS in the next Newsletter.


  2. MVS PTFs and/or APARs.


APAR OY29986/PTF UY49159 is required to correct a JES 2 3.1.3 error that
creates a truncated type 6 SMF record (which caused MXG to STOPOVER).

APAR OY28449/PTF UY40902 adds new "SRCL" field to RMF Product section,
but the new field is always zero, causing NO impact on MXG. See Change
8.065, below.

APAR OY31183, SMS only, creates DEVTYPE=FF and DEVNR=0FFF in the type 30
DD segments for DDs with more than one device allocated, causing an MXG
note "Invalid Device Type" (but does not cause MXG to fail).  IBM has
not yet issued a PTF to fix their problem.

APAR OY28328, PTF UY46699 corrects TYPE79 External Storage Frame Count
field R791ES.

APAR OY30300, and OY32039 correct the UCB length segment in type 14/15
SMF record so that HiperBatch statistics which were added in MVS 3.1.3
can be recognized as present in the record. The fields were added, but
the UCB length field was not updated to reflect the added data.

The SMF algorithm which consolidates like DD segments (have same DDNAME
and same unit address) in building the type 30 records is now optional.
A new SMFPRMnn parameter, DDCONS=YES/NO, default YES (i.e., no change)
are added by APAR OY25606 PTF UY48312. The consolidation algorithm has
been found to consume inordinate CPU time after step termination for
long running jobs (SAR, 3890XP, etc.) that have many DD segments because
they stay up for days.  These products dynamically allocate a new DD for
each function, each with a different DDNAME, and type 30 records with
25,000 to 50,000 DD segments may be written. The consolidation algorithm
searches each of these thousands of entries (sequentially) for exact
match on ddname and unit address, to consolidate like entries, which
never happens with the unique dynamic DDNAMEs!  Sites with these long
running dynamic allocating jobs should specify DDCONS=NO to avoid the
consolidation expense.  The consolidation algorithm only really impacts
the subtypes 4 and 5, written at step and job termination, since they
contain all DDs for these long-running step and the job.  The subtype 2
and 3 (interval) records only contain the DD segments allocated during
the interval and thus are inherently much shorter, with concomitantly
less impact.  One 3890XP (Check Processing) site only wrote interval
records for their STCs just to avoid the consolidation algorithm delay.
Not only was there a high CPU cost, it literally took hours for the task
to end after the operator canceled it!  Writing only interval records
for STCs has a negative impact on MXG's PDB.JOBS and PDB.STEPS datasets,
since MXG uses only the type 30 subtype 4 record for resources. Using
DDCONS=NO should avoid these problems.

DB2 APAR PL48307 (PTF UL58797 for 2.1, UL58796 for 2.2) corrupts the
sequence number (QWHSISEQ in MXG) and can causes 0 observations in
DB2STAT0 and DB2STAT1 datasets.


  3. MVS Technical Notes.


     a. ACTFRMTM notes.

Variable ACTFRMTM (Resident-Frame-Seconds) in your TYPE72 Performance
Group data will be garbage (only for the TSO Perf Groups), if your site
has the TSO/MON Product, and has not yet installed the year-old Legent
fix "Immediate Action #28". Legent detected their error and sent that
flash out last year, but we still find sites that did not install that
critical fix on their TSO/MON product.

As noted in Newsletter 13, ACTFRMTM measures Central Store plus Expanded
Store residency time frame-seconds, while MSOUNITS measures only Central
Store CPU TCB time frame-seconds.  You calculate CS-only-frame-seconds
as MSOFRMTM=MSOUNITS/(50*MSOCOEFF), to compare with CS+ES-frame seconds
in ACTFRMTM. Dividing MSOFRMTM by CPUTCBTM to get CS-only frames, and
dividing ACTFRMTM by RESIDTM to get CS+ES frames, and then subtracting
estimates ES frame count. Small denominator values (RESIDTM or CPUTCBTM)
can generate inaccurate values; calculate frames only if the denominator
is more than 1 second in the performance group period record.

                                ACTFRMTM               MSOUNITS
    Estimated ESTORE Frames = (-----------)  -  (--------------------)
                                RESIDTM          50*MSOCOEFF*CPUTCBTM

     b. No DB2 I/O counts in SMF data.

INFO/SYS entry Q426001 "explains" why there are no DB2 I/O counts in SMF
data. The Media Manager bypasses the call to SMF EXCP counting!

     c. Identify lost Index in Indexed VTOCs.

Indexed VTOCs sometimes lose their index. After this has happened, the
TYPE19 dataset variable VTOCERRO will be equal to 'Y', detecting that
the index has been lost.

     d. Instantaneous 4.5 MB/sec channel speed versus sustainable.

The 4.5MB/sec channel speed is only an instantaneous speed. For actual
data transfer the rate is at best 2.2MB/sec to 2.5MB/sec on 3480s with
IDRC.  INFO/SYS entry Q411444 estimates 6 hours elapsed time to dump 100
GB from 3380s to 3480s (four concurrent dumps to two A22s with sixteen
drives).  IDRC reduced the elapsed time to 5.5 hours.  The path between
the A22 and the 3480 is still a 3MB/sec path, and was the constraint.
The faster 4.5MB/sec channel served only to reduce the channel busy from
90-95% before to about 75% utilization after.

     e. Long Channel Programs affect Channel Measurements.

Long Channel Programs can cause the Channel Measurement Block data (the
source of Connect, Disconnect, and Pending) to be potentially wrong. The
CMB is updated at the end of each Channel Program, but if the interval
monitor (both MVS RMF and VM/XA Monitors use CMB) has a duration shorter
than the duration of the channel program, the monitor data will show
many intervals of 0 connect time, and then the total connect time for
the channel program will appear in one interval (often recording more
connect time in that record than the duration of the interval).  PSF in
particular has caused "errors" when a 1 minute interval is specified.
The connect time, etc., is zero for 9 intervals and then the accumulated
connect time is recorded in the tenth 1-minute interval record. The real
problem is not PSF, but rather long running channel programs.

     f. Erase on Delete can be set accidentally by RACF.

RACF "Erase on deletion" option may be needed for security, but it can
significantly increasd Disconnect time on DASD volumes. Dan Kaberon at
Hewitt discovered that the RACF SETROPTS description says that ERASE
specifies that scratched datasets will be erased if the data set profile
so dictates, but the actual ERASE option values are YES, NO or ALL.
"ALL" specifies that all scratched data sets will be erased REGARDLESS
of the ERASE indicator in the data set profile! "ALL" had been specified
unintentionally, causing public volume response of 500 ms per I/O
(because temporary data sets residing on public volumes were also being
ERASEd on delete)!  Watch out for this RACF option!  An elaboration of
Dan's discovery will be in a future Candle Report.

     g. SPF EDIT subcommand COPY renumbers line numbers.

TSO SPF EDIT subcommand COPY should NOT be used to copy a source member
into your USERID.SOURCLIB library from the  MXG.SOURCLIB, because  the
COPY  subcommand  of EDIT will renumber the lines!  Always use SPF  COPY
Command  (3.3)  instead  to  copy  members without renumbering, so that
numbering will be preserved.  (It's not clear when this began to happen,
nor  whether  it's  an  IBM design change or an error;  if you know more
let me know!)

  4. VM PTFs and/or APARs.


APAR VM40478 and VM41591 (when PTF'd) will fix a VM/XA problem with
Timeslice value.  VM/XA internal logic hardcoded an expected timeslice
of 25ms, and sites that changed their timeslice had serious Dispatcher
problems.

VM/SP Release 5.0 during unload of MXG tape with TAPPDS failed with the
DMSTPD105S ERROR 2 Writing, Virtual Storage Address zero message, but
VM/SP Release 5.1 executed TAPPDS without error. TAPPDS maintenance for
VM/SP 5.0 is probable, but the 5.1 circumvention ended investigation.


  5. CICS Technical Notes.


     a. Major structural changes in CICS 3.1.1 measurement data.

The type 110 record for CICS 3.1.1 contains two new subtypes.  Subtype 1
is the CICS Monitor Facility data record, while the new subtype 2 is the
new CICS Statistics data record.  Type 110 data records now must be
written to an SMF file; journal destination is not offered in 3.1.1.

The subtype 1 is similar to the previous type 110 subtype 0 CMF record,
but only the CICSEXCE ("Exceptions") and CICSTRAN ("Transactions") data
sets exist in CICS 3.1.1.  The previous CICSACCT ("Account") data set
is no longer created (it has always been redundant with CICSTRAN data).
The CICSYSTM ("System Interval") is not created in CICS 3.1.1, but most
of its data (plus a whole lot more new stuff) will be found in one of
the forty-seven(!) new CICS Statistics STIDs in subtype 2 records.

CICS 3.1.1 type 110 records are incompatible with previous 110 records.

MXG 8.2 supports ALL type 110 records from any CICS (1.5 thru 3.1.1)!

MXG 6.6 or earlier will fail when it encounters CICS 3.1.1 records.

MXG 7.7 recognizes and deletes CICS 3.1.1 records (they have a nonzero
subtype value), but could not support records not available until July!
However the subtype test added in MXG 7.7 has inadvertently deleted
CICS 1.7 records at two sites, because that supposedly reserved field
was used by CICS 1.7! If MXG 7.7 does delete your CICS 1.7 records, the
logic in 7.7 can be corrected as described in Change 8.040, although
installing MXG 8.2 PreRelease would be far wiser!

The new CICS Monitor fields are documented in IBM's new "CICS/ESA 3.1
Customization Guide".

The new CICS Statistics records and fields are extremely well documented
in IBM's new "CICS/ESA 3.1 Performance Guide". MXG's forty-seven CIC....
data sets built from CICS Statistics records use the IBM DFHSTUP field
names as variable names and the IBM symbolic names as the MXG data set
names, so the IBM Performance Guide is also the MXG documentation!  In
addition to the CICS 3.1.1 specifics in the Performance Guide, it also
contains many superb discussions of all CICS tuning parameters, most of
which apply to CICS 1.7 and CICS 2.1.  The Performance Guide is required
CICS reading!

     b. Changes to MXG Data Set CICSEXCE in CICS 3.1.1.

Exception records are produced after each of the following conditions
encountered by a transaction have been resolved.

    . Wait for storage in the DSA or in the EDSA
    . Wait for temporary storage (MAIN)
    . Wait for file string
    . Wait for file buffer
    . LSRPOOL string waits.

The duration of the exception is EXWAITTM, calculated as ENDTIME minus
STRTTIME, and the cause of the exception is described by EXCMNTYP. The
name and type of resource causing wait is described by EXCMNRTY and
EXCMNRID. This CICSEXCE observation can be matched to its CICSTRAN obs
by matching values of TASKNR in both datasets. Multiple observations
(counted by TASEXCNR) can occur in CICSEXCE for a single transaction.

MXG Sort Order for MXG Data Set CICSEXCE:
  TRANNAME TERMINAL USER OPERATOR STRTTIME ENDTIME TASEXCNR


CICSEXCE Fields deleted by CICS 3.1.1.

  CMODNAME  MXG Variable

  PCOMPRTM  PGMCMPTM                     Program Compression
  PCOMPRTM  PGMCMPCN
  SCWTETIM  SCWTETM                      Suspend time storage not avail
  SCWTETIM  SCWTECN


CICSEXCE Fields changed by CICS 3.1.1.

  CMODNAME  MXG Variable

  EXCMNTST  TRANTYPE
            Transaction start type. The field values now decoded by
            the $MG110TT. format now are:

              'A'        ='A:AUTO INITIATED'
              'C'        ='C:CONVERSATIONAL'
              'D'        ='D:TRANSIENT DATA'
              'T'        ='T:NORMAL TERMINAL STARTED'
              'S'        ='S:SYSTEM INTERNAL TASK'
              'Z'        ='Z:PSEUDO CONVERSATIONAL'
              '00000000'X='X00:FROM TERMINAL INPUT'
              '00000001'X='X01:BY ATI WITHOUT DATA'
              '00000002'X='X02:BY ATI WITH DATA'
              '00000003'X='X03:BY TRANSIENT DATA TRIGGER LEVEL'
              '00000004'X='X04:BY USER REQUEST'
              '00000005'X='X05:FROM TERMINAL TCTTE TRANID'

  SCWTSTG   MSREQWT  becomes MSWAITCN/TM Getmain Waits
  TSWTSTG   TSREQWT  becomes TSWAITCN/TM Temp Storage Waits

CICSEXCE Fields added by CICS 3.1.1.

  MXG Variable

  EXCMNRID='EXCEPTION*RESOURCE*IDENTIFICATION'
            Exception resource identification.

  EXCMNRTY='EXCEPTION*RESOURCE*TYPE'
            Exception resource type.

  EXCMNTYP='EXCEPTION*TYPE'
            Exception type. Values are:
            (See Format $MG110EX. in member FORMATS)

  EXWAITTM='DURATION*OF THE*EXCEPTION'
            Duration from STRTTIME to ENDTIME of this exception.

  LUNAME  ='LOGICAL*UNIT*NAME'
            Logical unit name. VTAM logical unit name (if available) of
            the terminal associated with this transation. This field is
            nulls if the task is not associated with a terminal.

  TCLASS  ='TRANSACTION*CLASS*AT CREATE'
            Transaction priority at task creation (rightmost byte of
            this four-byte variable).

  TRANPRI ='TRANSACTION*PRIORITY*AT CREATE'
            Transaction priority at task creation (rightmost byte of
            this four-byte variable).

     c. Changes to MXG Data Set CICSTRAN in CICS 3.1.1.

One observation is created in CICSTRAN for each performance class
monitoring record segment. Each observation represents the whole of a
TCA-lifetime (a user-task is a lifetime of a TCA) from CICS attach to
detach, unless the MCT option DELIVER or the MCT parameter CONV=YES have
been selected, in which case each observation represents a part of a
TCA-lifetime, i.e., a conversation, and in which case there will be
multiple observations in CICSTRAN for a single user-task.

MXG Sort Order for MXG Data Set CICSTRAN:
  TRANNAME TERMINAL USER OPERATOR STRTTIME ENDTIME


CICSTRAN Fields deleted by CICS 3.1.1.

  CMODNAME  MXG Variable

  PAGINCT   PAGEINS      61       Page ins (during user task dispatch)
  MNEXCCT   TASEXRN      32       Number of Exception records generated
  BMSOTHCN  BMSOTHCN     53       BMS other count
  FCOTHCN   FCOTHCN      72       File Control other count
  bit 22    MAXTASK      64       Maximum Task condition delay
  bit 23    SHRTSTOR     64       Short on Storage condition delay

  Comment: By deleting PAGEINS from CICS Transaction records, IBM has
  substantially reduced the cost of running the CICS Monitor Facility,
  since capture of paging activity was a significant contributor to
  of overhead of monitoring CICS.  IBM now suggests that overhead due
  to the CICS monitor is on the order of 5-7%, but that has not yet
  been verified by an MXG user.

CICSTRAN Fields changed by CICS 3.1.1.

  Labels for STORHWMK, SCGETCNT, and PAGESECS now include "Below 16MB"
  and PROGSTOR includes "Above & Below 16MB" to contrast with the new
  storage variables added below.

CICSTRAN Fields changed by CICS 3.1.1.

  MXG Variable                                        /* CMODNAME */

  LUNAME  ='LOGICAL*UNIT*NAME'
            Logical unit name. VTAM logical unit name (if available) of
            the terminal associated with this transation. This field is
            nulls if the task is not associated with a terminal.

  PAGESECH='MEMORY*PAGESECS*(PER TCB) ABOVE 16MB'     /* SCUSRSTGH*/

            Storage occupancy pageseconds of the user-task above the
            16MB line.

  PC24BHWM='PROGRAM*STORAGE*BELOW 16MB          '     /* PC24BHWM */

            Maximum amount (high-water-mark) of program storage in use
            by the user task below the 16MB line. This variable is the
            subset of PROGSTOR that resides below the 16MB line. The
            program storage currently in use below the 16MB line is
            incremented at LOAD, LINK, and XCTL events by the size
            (in bytes) of the referenced program, and is decremented at
            RELEASE, or RETURN events, provided that the referenced
            program resides below the line.  Note: On an XCTL event the
            program storage currently in use below the 16MB line can be
            additionally decremented by the size of the program issuing
            the XCTL, provided that this program resided below the line.

  RTYPE   ='RECORD*TYPE                         '     /* RTYPE */
            Performance record type (rightmost bytes), decoded by
            the $MG110RT. format. Values are:

              '   C'='C:TERMINAL CONVERSE'
              '   D'='D:USER EMP DELIVER REQUEST'
              '   T'='T:TASK TERMINATION'
              '  MT'='MT:SEMI-PERMANENT MIRROR SUSPEND'

  SCGETCNH='USER STORAGE*GM REQUESTS*ABOVE 16MB '     /* SCUGETCTH*/

            Count of the number of user storage GETMAIN requests
            issued by the user task for storage above the 16MB line.

  STORHWMH='USER STORAGE*MAX (HWM)*ABOVE 16MB   '     /* SCUSRHWMH*/

            Maximum amount (high water mark) of user-storage allocated
            to the user task above the 16MB line.

  TCLASS  ='TRANSACTION*CLASS*AT CREATE'
            Transaction priority at task creation (rightmost byte of
            this four-byte variable).

  TCSTG   ='AMOUNT OF*TERMINAL*STORAGE          '     /* TCSTG */

            Amount of terminal storage (TIOA) allocated to the terminal
            associsted with this user task, if applicable. This value
            is set at task attach and after a terminal session converse.

  TRANPRI ='TRANSACTION*PRIORITY*AT CREATE'
            Transaction priority at task creation (rightmost byte of
            this four-byte variable).

  WTDISPCN='USERTASK*RE-DISPATCHES              '     /*DISPWTT */

            Count of number of times when the user-task waited for
            re-dispatch.

  WTDISPTM='USERTASK*RE-DISPATCH*WAIT TIME      '

            Elapsed time for which the user-task waited for re-dispatch.
            This is the aggregate of the wait times between each event
            completion and the user-task re-dispatch. Note: This does
            not include the time spent waiting for first dispatch.

  WTEXWTCN='EXCEPTION*CONDITIONS                '

            Count of the number of exceptional conditions that have
            occurred for this task.

  WTEXWTTM='EXCEPTION*CONDITION*WAIT TIME       '    /*EXWTTIME */

            Total elapsed time for which the user waited on exceptional
            conditions. Will be null if EXCEPTION CLASS=OFF specified.

  WTTDIOCN='VSAM TRANSIENT*DATA IO*WAITS        '

            Count of the number of times when the user waited for
            VSAM transient data I/O.

  WTTDIOTM='VSAM TRANSIENT*DATA IO*WAIT TIME    '    /*TDIOWTT  */
            Total elapsed time for which the user waited for VSAM
            transient data I/O.

     d. New CICS 3.1.1 Statistics Data Sets descriptions.

There are 47 new CIC..... data sets created from the new subtype 2 data.
Those 47 new data sets contain 1465 new variables, which would take 32
pages just to list their names!  That list is contained in DOCVER08 and
DOCVER in the MXG 8.2 PreRelease, and field descriptions are found in
IBM's "CICS/ESA 3.1 Performance Guide".  The forty seven data sets are:

MXG     STID  DFH    Description of Data Set             Symbolic   MXG
Dataset       ...                                        IBM        Exit
Name         DSECT                                       Name       Name

CICAUSS   22  AUS    Autoinstalled Terminal Unsolicited  STIAUSS    AUS
CICAUTO   24  A04    Autoinstall Global                  STIAUTO    AUT
CICBTAM   82  A06    Terminal Control BTAM               STIBTAM    BTA
CICCONMR  76  A20    ISC/IRC Mode Entry Specific         STICONMR   CO3
CICCONMT  77  A20    ISC/IRC Mode Entry Totals           STICONMT   CO4
CICCONSR  52  A14    ISC/IRC System Entry Specific       STICONSR   CO1
CICCONST  53  A14    ISC/IRC System Entry Totals         STICONST   CO2
CICDBUSS  28  DBU    DBCTL Global Unsolicited            STIDBUSS   DBU
CICDLIR   70  A18    DL/I Specific                       STIDLIR    DL1
CICDLIT   71  A18    DL/I Totals                         STIDLIT    DL2
CICDMG    15  DMG    Domain Manager Global               STIDMG     DMG
CICDMR    13  DMR    Domain Manager Specific             STIDMR     DMR
CICDQG    45  A11    TDQUEUE Transient Data Global       STITDQG    DQG
CICDQR    43  A10    TDQUEUE Transient Data Specific     STITDQR    DQR
CICDQT    44  A10    TDQUEUE Transient Data Totals       STITDQT    DQT
CICDS     57  DSG    Dispatcher Domain, CPU each TCB     STIDS      DS
CICDTB    33  A05    Dynamic Transaction Backout Global  STIDTB     DTB
CICFCR    67  A17    File Control Specific               STIFCR     FCR
CICFCT    68  A17    File Control Totals                 STIFCT     FCT
CICIRCB   75  A19    IRC Batch Global                    STIIRCB    IRC
CICJCR    49  A13    Journal Control Specific            STIJCR     JCR
CICLDG    27  LDG    Loader Domain for Program Global    STILDG     LDG
CICLDR    25  LDR    Loader Domain for Program Specific  STILDR     LDR
CICLDT    26  LDR    Loader Domain for Program Totals    STILDT     LDT
CICLSRFR  40  A09    LSRPOOL File stats each File        STILSRFR   LS3
CICLSRFT  41  A09    LSRPOOL File stats Totals           STILSRFT   LS4
CICLSRR   37  A08    LSRPOOL Pool stats each LSR pool    STILSRR    LS1
CICLSRT   38  A08    LSRPOOL Pool stats Totals           STILSRT    LS2
CICM      81  MNG    Monitor Domain Global               STIM       M
CICSDG    90  SDG    System Dump Global                  STISDG     SDG
CICSDR    88  SDR    System Dump Specific                STISDR     SDR
CICSMD     7  SMD    Storage Manager Domain Subpool      STISMD     SMD
CICSMSDA   9  SMS    Storage Manager DSA and EDSA        STISMDSA   SMS
CICSMT     8  SMT    Storage Manager Task Subpool        STISMT     SMT
CICST     66  STG    Statistics Domain Global            STIST      ST
CICTC      3  A01    Task Control Global                 STITC      TC
CICTCLR   58  A15    TCLASS Transaction Class Specific   STITCLR    TC1
CICTCLT   59  A15    TCLASS Transaction Class Totals     STITCLT    TC2
CICTCR    34  A06    Terminal Control Specific           STITCR     TCR
CICTCT    35  A06    Terminal Control Totals             STITCT     TCT
CICTDG    87  TDG    Transaction Dump Global             STIDTG     TDG
CICTDR    85  TDR    Transaction Dump Specific           STITDR     TDR
CICTM     63  A16    Table Manager Global                STITM      TM
CICTSQ    48  A12    TSQUEUE Temporary Storage Global    STITSQ     TSQ
CICTSR     4  A02    Transaction Statistics Specific     STITSR     TSR
CICTST     5  A02    Transaction Statistics Totals       STITST     TST
CICVT     21  A03    VTAM Global                         STIVT      VT

     e. Observed CICS 2.1 CICSYSTM and MONITASK datasets CPU timings.

This CICS note applies to CICS 2.1 and earlier, and not the new CICS 3.1
described above (which does not contain the CICSYSTM data set). The CPU
measures in IBM's CICSYSTM dataset should match this schematic:


                        CPUTCBTM=ADSPTIME                     SRB
            -----------------------------------------------   ---

                        MAINCPTM                   SUBTCPTM
            -------------------------------------- --------

            KCCPUTM             USRCPUTM           OSWTCPTM
            ------- ------------------------------ --------
                     JCCPUTM   TCCPUTM   TASKCPTM
                    --------- --------- ----------

                       "CICS"             "APPL"
            --------------------------- ----------


The CICSYSTM fields contained in IBM's record are the ADSPTIME, KCCPUTM,
USRCPUTM (and its JCCPUTM and TCCPUTM components), and the SRBCPUTM.
MXG stores ADSPTIME in CPUTCBTM, and calculates SUBTCPTM, the subtask
CPU time, (which is also stored in OSWTCPTM, its older name).

One site found numerous negative values for SUBTCPTM, with the largest
value of -1.47 seconds. That 900 second interval had ADSPTIME of 426.72,
but the MAINCPTM sum of KCCPUTM (37.18) and USRCPUTM (391.01) of 428.19
was 1.47 seconds greater than ADSPTIME!  Both the ADSPTIME and the sum
of MAINCPTM are suspect, because the CICS region's RMF TCB was 414.32,
or CICS recorded 14 seconds more than RMF recorded! (The type 110 SRB
CPU of 25.82 was slightly less than the RMF SRB time of 27.82.) CICSYSTM
data from a second unrelated site showed the same pattern; the CICS
recorded ADSPTIME was less than the sum of KCCPUTM and USRCPUTM, causing
SUBTCPTM to be negative, and RMF CPUTCTBM was also less than the
ADSPTIME.  Investigation is still open.

Landmark sites MONISYST noted a different problem with Landmark 7.1, but
rather than a data error, the problem was MXG's lack of understanding of
what's captured.  Landmark fields KCCPUTM, JCCPUTM, TCCPUTM, TASKCPTM,
and OSWTCPTM include both TCB and SRB time. Landmark also captures two
other TCB+SRB CPU measures, IRCPUTM and VSCPUTM.  Landmark's schematic:


                        CPUTCBTM                               SRB
   --------------------------------------------------------- + ---

   KCCPUTM  JCCPUTM   TCCPUTM   TASKCPTM  OSWTCPTM IRCPUTM VSCPUTM
   ------- --------- --------- ---------- -------- ------- -------


Validation of any CICS monitor's CPU time is non trivial, since CPU time
for startup/shutdown of the region is recorded in the first and last RMF
interval CPU time and in the type 30 step termination CPU time, but it
is not capturable in the CICS monitor's CICSYSTM/MONITASK records. It is
possible the CICSYSTM measures noted above are not real errors; perhaps
the CPU time occurred but was simply being assigned to a wrong interval?
Further investigation is under consideration, and ideas are welcome!

  6. SAS 6.06.01 Issues and MXG recommendations.

************************************************************************
*                                                                      *
*  MXG's Official Position with regard to SAS 6.06.01, July 10, 1990:  *
*                                                                      *
*  A new ship's keel is laid 3 years before the ship is launched into  *
*  the water.  Two years later, the ship is commissioned and is sent   *
*  out on its "shakedown cruise".  The ship floats, makes way under    *
*  its own power, and gets you there, but imperfections are discovered.*
*  After the shakedown cruise, the shipyard fixes the things that are  *
*  broken, and a year or so later the ship is placed in full service.  *
*                                                                      *
*  SAS 6.06.01 is currently on its "shake-down cruise".                *
*                                                                      *
*  SAS Institute ZAPs are required before MXG can be safely executed   *
*  under SAS 6.06. Additional problems that cannot be fixed by zap     *
*  will not be available until SAS 6.08 is released (in mid-1991).     *
*                                                                      *
*  In addition, source modifications to MXG Version 7.7 may be needed  *
*  to circumvent some incompatibilities between 5.18 and 6.06.         *
*  MXG 8.2 contains these source changes, which are identified below.  *
*                                                                      *
*  Initial performance measurements for MXG execution under SAS 6.06   *
*  show significantly more CPU time is required than under SAS 5.18.   *
*  Both data-intensive sequential processing and compiler-intensive    *
*  processing recorded more CPU time, although in some cases the I/O   *
*  counts and elapsed run time were slightly reduced.  Further testing *
*  of new SAS options and investigation by SAS Institute is ongoing.   *
*                                                                      *
*  Some MXG sites may actually require SAS 6.06.                       *
*                                                                      *
*  Sites which have encountered the SAS "344 Compiler Limit Exceeded"  *
*  condition will find that that limit (as well as other constraints)  *
*  have been eliminated in SAS 6.06.                                   *
*  The new support for the Cray COS operating system requires the new  *
*  $ASCII. format, and the planned new support for DEC VMS data will   *
*  require both $ASCII. and VAXRB. formats that are only in SAS 6.06.  *
*                                                                      *
*  The ZAPs listed below are required because MXG fails without them.  *
*  Additional 6.06 problems have been reported and fixed by SAS ZAPs.  *
*  These ZAPs can be downloaded from the Institute's "Online Customer  *
*  Support Facility".  Alternatively, SAS Institute will make available*
*  (in mid-July), the "July SAS 6.06 Usage Notes Tape". That tape will *
*  contain these Required, Highly Recommended, Recommended, and Special*
*  Consideration categories of ZAPs to be installed on SAS 6.06.       *
*                                                                      *
*  SAS Institute asks that you request the "July Usage Notes Tape" in  *
*  writing, addressed to their SAS Distribution Center, and that you   *
*  indicate the operating system (OS or CMS) and tape (reel/cart) type.*
*  The procedures for downloading ZAPs and installing maintenance are  *
*  discussed in SAS Technical Bulletin U-112, packaged with SAS 6.06.  *
*                                                                      *
*  In summary, get and install the "July Usage Notes Tape" before you  *
*  begin testing MXG under SAS 6.06.                                   *
*                                                                      *
*  SAS Version 6 is a major re-design, and will require planning and   *
*  testing of your critical SAS applications before their migration.   *
*                                                                      *
*  There are many new features and benefits in SAS 6.06 that do work.  *
*  Before too long, all will be smooth sailing with following seas!    *
*                                                                      *
************************************************************************

     a. SAS 6.06 ERROR Conditions requiring ZAPS to be installed.

  1. ZAP Z6060611 required.
     Fixes a SAS logic error that caused the MVS Initiator to ABEND
     because LSQA had filled because SAS had opened SOURCLIB over 2000
     times and filled LSQA with DEBs! This error was uncovered only
     because IMPLMAC was (incorrectly) enabled when BUILDPDB ran!

  2. ZAP Z6060640 required.
     A STOPOVER condition executed when INPUT STATEMENT EXCEEDED RECORD
     did not set condition code, and hence ERRORABEND was not invoked!
     This ZAP sets a condition code of 8 for STOPOVER so that ERRORABEND
     will be invoked. MXG requires ERRORABEND for protection of the PDB.

  3. ZAP Z6060653 recommended.
     PROC SOURCE (used by MXG to build the shipment dataset) begins to
     print source lines on SAS log, erratically, which can cause System
     722 ABEND. This problem was already known when MXG hit it.

  4. ZAP Z6060703 required.
     PROC GPLOT against a data set with 0 observations shuts down the
     SAS execution with no error message. GRAFRMFI exposed this error.

  5. ZAP Z6060288 required.
     Using real SORTWORK DDs has always been recommended by MXG, because
     their existence supresses dynamic allocation of sort work areas.
     Dynamically allocated sort work areas have caused frequent failures
     because they free allocation after every sort and do not always
     clean up properly in applications (like MXG) where many sorts of
     varying sizes are invoked in a single execution.
     This ZAP is required by SAS 6.06 so that real SORTWORK DDs can be
     used. Existing jobs that have real SORTWKnn DDs will fail if this
     ZAP is not installed.

  6. ZAP Z6060938 required.
     Option ERRORABEND did not cause a USER 999 ABEND when it should.
     A condition code 8 occurred (in specific case, a SET without DATA
     statement, but the problem was generic) but no ABEND resulted.

       In SAS 6.06 these Condition Codes can occur:

        Condition         Meaning
            0        Successful execution.
            4        Warning message issued.
            8        Error message issued, or PROC abend was recovered.
           12        Severe Internal Error.
           16        ABORT; issued.
           20        ABORT RETURN; issued.
           24        ABORT ABEND; issued.

  7. Special Consideration ZAP Z6060874 available.
     The SAS Initialization Note identifies all CPUs as being IBM.  An
     Amdahl 5990 is shown as an IBM 5990.  The hardcoded name "IBM"
     can be changed to your vendor's name by installing this ZAP.
     Because not all sites will need this ZAP, it is a "Special
     Consideration" ZAP, and is not on the SAS Online Support System.

  8. ZAP Z6060872 required.
     POINT operand with zero observations fails with a syntax error.
     Usage note V6-SYS.DATA-0872.  This caused ASUMCICS to fail because
     POINT was used to detect whether the CICS data to be summarized
     was from IBM's CICS Monitor Facility or Landmark's TMON Monitor.

  9. ZAP Z6060571 required for 6.06 to act like 5.18.
     "ERROR: Data set subsetted using FIRSTOBS or OBS options or a WHERE
     clause cannot be sorted in place unless the FORCE option is used."
     SAS 6.06 created a new PROC SORT option, FORCE, which must be used
     if you want SAS to sort a data set when OPTIONS OBS= has been set.
      The intent of the new FORCE option was to protect naive users from
      accidentally wiping out a data set. If a user naively set OBS=100
      and then PROC SORT DATA=PDB.JOBS (and had also naively set the JCL
      DISP=OLD for the PDB DDNAME), SAS would have sorted PDB.JOBS and
      then written back only the first 100 (sorted) observations.
     MXG users frequently use OPTIONS OBS=100 for testing, and this new
     6.06 "feature" would have required MXG to add "FORCE" to every one
     of the 555 "PROC SORT" lines (in 79 MXG members) so that MXG would
     work under 6.06 as it did under 5.18.
       The new FORCE option is only needed on PROC SORTs when the input
       and output datasets are the same. PROC SORTs with different input
       and output datasets will sort without FORCE even when OBS= is on.
       The FORCE option could not actually have been added to MXG source
       code, because MXG then would fail (unknown option!) under 5.18.
       The source change would have required that an OUT=NEWNAME option
       be added to all PROC SORTS that did not have an OUT= option, and
       and then a new source line PROC DATASETS;RENAME NEWNAME=ORIGINAL;
       added after each PROC SORT so that OPTIONS OBS=nn could be used
       under either SAS 5.18 or SAS 6.06 transparently to MXG users.
     That source circumvention was scheduled for MXG, but SAS responded
     with this ZAP (that makes FORCE the default for PROC SORT in 6.06),
     thereby making SAS 6.06 work just like it did under SAS 5.18.
     Usage note V6-SYS.SYS-0571 discusses this Special Consideration.

 10. ZAP Z6060946 in development. Usage Note V6-MACRO-0946.
     Invoking %VMXGGOPT using AUTOCALL created a syntax error, but if
     the invocation is preceeded by %INCLUDE SOURCLIB(VMXGGOPT); (which
     defines the macro without using AUTOCALL) there is no error. The
     error occurs for AUTOCALLed members that are numbered and that have
     a non-blank character in column 72 of the first line of the member!
     A ZAP is in SAS development, but it is not expected to be on their
     July Usage Notes Tapes.  MXG Change 7.072 shortened the MXG Notice
     of Copyright to 71 positions in the first line of members ANALDB2R,
     VMXGGOPT, VMXGHSM, VMXGINIT, and VMXGVTOR that can be AUTOCALLed.

 11. ZAP in development. Usage Note V6-MACRO-0752.
     When an error occurs in a line defined inside an old-style macro,
     and option MACROGEN was specified to show each line of the actual
     resolved macro substitution, SAS 6.06 does not list the real line
     number of each line. The error message only lists the line number
     on which the macro was invoked, making error diagnosis difficult.
     This ZAP is not expected to be on the July Usage Notes Tape.

 12. ZAP investigation in progress. Usage Note 1000.
     Three of nine weekly input files failed during sorting data sets.
     After several successful sorts of varying sizes, SYNCSORT failed
     "WER133A E15 User Exit Return Code Terminate". Using instead option
     SORTPGM=SAS still failed with ERROR: RECORD IN FILE WORK.X.DATA
     IS TOO LONG FOR BUFFER.  Attempted using real SORTWKnn DDs, setting
     MEMSIZE=12M, using USER=USER to isolate data from WORK file. One
     failure went away when USER=USER was used, but next week's data
     failed. One failure went away when NODUP was removed from the SORTs
     and one failure went away with entry SASXA1 instead of SASXAL.
     ZAP Z6060529 was suggested, but did not correct the failure. SAS
     coded a special diagnostic ZAP, and its 4200 page dump is enroute
     to Cary.  Obviously, this problem is still open. This Usage Note
     was assigned by SAS so you could follow up on its status when the
     problem is identified/fixed/circumvented after this newsletter.


     b. SAS 6.06 Incompatibilities which required MXG Source Changes.

  1. The validation of variables in DROP= and KEEP= statement/options
     depends on statement/option/usage. Validation checking means that
     SAS raises an error condition for a non-existent variable. The
     KEEP/DROP option in a PROC statement was not validated in 5.18 but
     is checked in 6.06. SAS 6.06 restored the original SAS 82.4 design
     in which input variables are checked and output variables are not.
     (SAS 5.08 had incorrectly changed validation, but only in a PROC
     statement, and 5.16 and 5.18 propagated that change):
      Statement               Usage            5.18 action   6.06 action
       DROP/KEEP statement:   (Input/Output)   Checked       Checked
       DROP= or KEEP= option:
        in DATA statement     (Output)         Not Checked   Not Checked
        in PROC statement     (Input)          Not Checked   Checked
        in SET statement      (Input)          Checked       Checked
     Usage Note V6-SYS.SYS-0666 discusses this issue, and the Institute
     is now investigating a new option to allow user control of when and
     if validity checking occurs.
     The change in action between 5.18 and 6.06 for the PROC statement
     (Input) required MXG circumvention implemented in Change 8.060.

  2. MXG member GRAFRMFI failed with CC 8 and ERRORABENDed due to "FILE
     WORK. RMF4GRA5S WAS NOT FOUND .." because PROC COPY's option GCAT
     (which worked under 5.18) no longer is supported in 6.06. The new
     CATALOG option of PROC COPY could be used in SAS 6.06, but CATALOG
     is not valid under 5.18 for graphics catalogs!  The source change
     which does work under both 5.18 and 6.06 was to replace the use
     of PROC COPY for copying graphics catalogs with the PROC GREPLAY
     command COPY.  This was implemented in Change 8.061.

  3. PROC MEANS in SAS 6.06 now invokes PROC SUMMARY, and every OUT=
     dataset now contains two additional variables, _TYPE_ and _FREQ_
     (and they are length 8!). This adds 16 unwanted bytes to each
     observation built by PROC MEANS, and creates an inconsistency in
     the number of variables created by the same MXG member under SAS
     5.18 and 6.06. This was implemented in Change 8.062.

  4. GRAFRMFI technique of executing PROC GREPLAY in batch and building
     GROUP and MODIFY statements (because MXG knows how many systems,
     how many shifts, and can count which graph numbers in the graphics
     catalog were produced) fails in SAS 6.06 (with MEMBER NOT FOUND)
     because GREPLAY cannot find the catalog entry. In SAS 6.06, if
     graphs 1-5 are GROUPed, they are moved to the end of the catalog,
     and when we try to find graphs 6-10 for the next group, they are
     now new graphs 1-6!  Grouping isn't really supported for batch use,
     but is designed for interactive SAS/GRAPH where a person ticks off
     the groupings for later GREPLAY. We made it work in batch, but the
     implementation was not in the design.  Possible circumventions:
     a) after grouping graphs 1-5, don't look for 6 next, but recognize
        that what was 6 is now 1, (use this in 6.06, old code in 5.18),
     b) exploit Version 6 requirement that each graph have a unique
        name (GPLOT, GPLOT1, GPLOT2, ... GPLOT99, GPLO100, ....) and
        use the name for grouping.
     What is really needed is the ability to specify GROUP when the
     graphic catalog entry is created, which would eliminate the need
     for the slick MXG manipulation that used to work. SAS is looking at
     a better way for a future release.  The actual circumvention that
     is in MXG 8.2 (implemented in Change 8.061) was to give up the
     grouping logic under SAS 6.06 and await future developments.

  5. MXG member GRAFTRND required PROC GLM, and hence SAS/STAT product.
     It is not (yet) possible to detect if SAS/STAT is installed, so we
     have had to (reluctantly) change the source member GRAFTRND to add
     a new parameter to tell MXG if SAS/STAT is installed, and added new
     logic to invoke PROC GLM only if you tell GRAFTRND it is installed.
     Circumvention implemented in Change 8.063.

  6. Usage Note V6-SYSPROC.0927.
     PROC SORT DATA=WORK. CICSTRAN or DATA=_CICTRAN. CICSTRAN fails with
     201 (invalid options) because the grammar pre-processor parsing in
     all PROCs thinks WORK. is a format instead of a libref. The problem
     only exists in PROCs (not in DATA, SET. etc. statements) and if the
     period delimiter has blanks on both sides, had no blank or either
     side, or has a blank before but not after, the parser works okay.
     Because the grammar pre-processor is unique to each PROC, this
     problem cannot be zapped, and will not be repaired until 6.08.
     Fortunately, only one occurrence of this syntax has thus far been
     found in MXG source, but this could be a problem in your own code.
     MXG circumvention in Change 8.059.

     c. Additional SAS 6.06 compatibility items.

  1. ALL SAS Institute supplied ZAPS for 6.06 should be installed,
     even those described as "Special Consideration" if they apply
     to your site's use of SAS.

  2. Do not EVER specify option IMPLMAC.

  3. Default MEMSIZE=8M is insufficient with ANALDB2R(PDB=SMF). Error
     1313 "Cannot get any MFEs" results. With MEMSIZE=10M, ANALDB2R
     reports can be executed directly from SMF data. Most MXG programs
     worked with the default MEMSIZE=8M, but MEMSIZE=12M is specified
     in MXG's CONFIG member just to provide further cushion.

  4. You can use either Version 5.18 built or Version 6.06 built format
     libraries under SAS 6.06 execution.  If SAS 6.06 sees the ddname
     of SASLIB pointing to a SAS 5.18 built PDS format library, it will
     use those formats.  If SAS 6.06 does not find a SASLIB ddname, it
     will then look for the LIBRARY ddname, which it expects to point
     to a Version 6.06 built format library, which is now a SAS library.
     and not a PDS library.  MXG's member FORMATS (invoked in the first
     step of JCLTEST or under TSO as described in Chapter 32 Install
     Notes) will build MXG's format library consistent with the version
     of SAS under which FORMATS is executed. When executed under SAS
     6.06, Version 6 formats will be created in the LIBRARY ddname, a
     SAS data library.  If instead, FORMATS is executed under SAS 5.18,
     Version formats will be created in SASLIB ddname, a loadlib PDS.

     MXG's Version 5 format library requires SPACE=(CYL,(3,1,99)).
     In Version 6 format, the SAS data library requires SPACE=(CYL,9,1),
     using the SAS 6.06 default blocksize of 6144 bytes.

  5. Do NOT specify third space parameter (SPACE=(CYL,(1,2,3)) on the
     LIBRARY DD for Version 6.06 format library. The existence of the
     third parameter (the number of directory blocks) confuses SAS 6.06.
     The PROC FORMAT goes ahead and builds the SAS 6.06 format FORMAT
     library (which is a SAS data library and not a PDS), but then when
     SAS 6.06 tries to reference this incorrectly allocated library, it
     reports a "170:FORMAT NOT FOUND" error. Removing the third space
     parameter when allocating a Version 6.06 format library makes the
     problem go away.

  6. The GEN=0 options is mandatory for MXG execution with SAS Version 5
     (because of severe performance degredation with any larger value,
     see page 317 of the MXG Guide).  GEN= is not an option in SAS 6.06,
     and its use causes a "WARNING:OPTION DOES NOT EXIT" and the step
     terminates with a condition code 4, characteristic of warnings.
     GEN= may return in a future version of SAS, but it will never be
     advisable with the MXG application.

  7. All of the SAS 6.06 problems reported in this newsletter were found
     using the MVS (OS) Version of SAS 6.06.  Some important members of
     MXG 7.7 (JCLTEST, BUILDPDB, VMACVMXA, VMACVMON) have been executed
     using the CMS Version of SAS 6.06 with no error messages, but MXG
     has not really been fully exercised under the CMS Version.  Several
     ZAPs reported in this newsletter will not be available on the July
     Usage Notes Tape for the CMS Version, although they should be on a
     later Usage Notes Tape.  (Remember, the Institute first must find
     and "fix the problem in the language it broke in" and then develop
     a C-language source fix, and then each execution platform group has
     to engineer a machine-specific ZAP in the machine language of that
     machine, and that ain't easy!)

  8. The free SAS-provided "CPE Starter Set" fails under SAS 6.06, and
     it is being re-written. That example of SAS/AF menus for reporting
     from MXG databases will be available for MVS 6.06 this summer and
     for CMS 6.06 early this fall. Call your SAS sales representative to
     request your free copy; call early and you can become a beta site)!

  9. PROC CONTENTS DATA=PDB._ALL_ NODS; does not give a picture of the
     directory of a SAS data library. Instead of the single page list of
     data set names, number of observations, and their size in tracks,
     (that was so useful in verifing the contents of each day's PDB),
     the NODS option provides only a list of data set names and type!
     (PROC DATASETS option CONTENTS produces the same meagre list).
     You can remove the NODS option and thereby print the detail on each
     data set, which does contain size in blocks and observation count,
     but that also prints all variables, which can take many pages!
     Usage note V6-CONTENTS-0713 says future objective, maybe 6.08?

 10. The hex dump listing of a defective record (STOPOVER or LIST;) that
     is essential for debugging critical data errors does not contain:
     (a) the record number of bad record, (b) the length of bad record,
     or, (c) the byte number of each line of dump (CHAR is printed on
     each line instead!  Fix not likely until SAS 6.08.

 11. The GO option of SAS 6.06 loses data in the WORK file and re-sets
     the prompt line number back to 1. Usage note 1240 says that this
     feature is working as designed!

 12. SPF 3.3 COPY failed when trying to create a copy of the SAS 6.06
     load library for ZAP testing, with a "Cannot move or copy planned
     overlay load modules".  It was necessary instead to use IEBCOPY.

 13. PROC PRINT of a DATETIME21.2 variable which has all values missing
     still prints 21 positions wide, because in 6.06 a FORMAT with a
     numeric specification causes the PRINT procedure to uniformly use
     that width, even when all data values on a page are missing. If you
     use a format with no numeric specification (eg. DATETIME. instead
     of DATETIME19.), with the PROC PRINT, it will look like SAS 5.18.
     (Previous SAS logic examined all values on a page and set the width
     of each print field based on that page's values, but that algorithm
     was eliminated in Version 6. Some users complained because it made
     pages inconsistent, and it did require additional CPU time for each
     page's analysis.)

 14. PROC PRINT of values 4.123E18 and 4.1234E18 are not aligned on the
     decimal point (shorter shifted right), when SAS choses exponential
     printing format for an un-formatted field. Usage note V6-PRINT-0660
     says that using an explicit FORMAT statement will cause alignment.

 15. The MACROGEN option (which is used to expand old style macro's SAS
     source code for debugging) now takes up the first ten print columns
     on the SAS log, destroys the actual physical layout of the SAS code
     (because individual lines are joined together as strings), but then
     wraps back to the first print position any multiline SAS statement!
     While still functional, it is much harder to read than was 5.18.

 16. New WARNING "Input data set is empty" for PROC SORT of a dataset
     with zero observations may be printed on the log.

 17. New WARNING "No datasets qualify for FIRSTOBS and OBS processing"
     may be printed on the log.

 18. The second occurrence of a LENGTH statement for a char variable
     (even if the length was NOT changed in that 2nd occurrence) causes
     an unnecessary warning message.  (If the length had been changed,
     a warning would be welcome!)  Usage note V6-SYS.SYS-0923 discusses
     the intention to eventually eliminate the unwanted warning and to
     provide a warning if a change is requreste in the length.  This had
     been fixed in 5.18, but was not retrofitted into 6.06.

 19. The infile exit that decompresses Landmark's compressed CICS data
     records and was provided by MXG in member EXITMONI for SAS 5.18,
     was re-written for SAS 6.06 by the Institute and is provided in
     the 6.06 distribution library member SAS606.BAMISC(TMONEXIT).  That
     member contains the JCL and ASM source code to assemble and link
     edited a load module (named TMONEXIT for 6.06) into a load library
     that is then concatenated to your STEPLIB. Since the load module in
     6.06 (TMONEXIT) is different than the two load modules in SAS 5.18
     (SASTMNP and SASTMNX), the same load library could be used for both
     SAS Versions.  Under either SAS 6.06 or 5.18, the MXG invocation of
     the decompression infile exit is identical. Edit member IMACMONI to
     add the keyword TMON to the INFILE statement (see comments therein)
     and the infile exit will then be invoked to process both compressed
     or and uncompressed records automatically.

 20. SAS 6.06 no longer uses the FT11F001 or FT12F001 DDNAMES for the
     SASLOG or SASPRINT output files.

 21. The options in effect for SAS 6.06 execution are controlled by the
     CONFIG ddname in your JCL.  The options that have been used in the
     MXG testing under SAS 6.06 in MVS/XA batch are contained in member
     CONFIG of the 8.2 library, and are printed below in Change 8.068.
     These are not necessarily the correct or final set of options that
     MXG will recommend after more is known, but they are provided so
     that at least you know what was used in MXG testing.

 22. SAS 6.06 changed the way the ID statement works with procedures.
     The ID statement is used to carry variables from the input data set
     to the output data set. Under 5.18 the values were taken from the
     first observation in each BY group.  In SAS 6.06 the values are now
     taken from the input observation which has the maximum (optionally,
     the minimum) value of the string built by concatenation of values
     of the ID variables. As long as all values are the same for a BY
     group, it does not matter which observation is chosen, but if the
     value of an ID variable is not constant within the BY group, you
     could see different output values between 5.18 and 6.06. It has not
     yet caused a problem with MXG, because it is believed that in all
     cases where an ID statement is used, the values will be the same
     for each BY group, but there could be a difference.

     d. Performance measurement comparisons and performance zaps.

  1. ZAP Z6060652 recommended.
     The compile CPU time for %MACROs is excessive when large parameters
     are used. In SAS 5.18, option MWORK=28K was necessary for %ANALDB2R
     (DB2 reporting) because of the large size of character parameters,
     but MWORK is not a 6.06 option. This ZAP re-designed the allocation
     of parameter workspace in 6.06. The before-zap CPU TCB 3090-200E of
     311 seconds was reduced to 84 seconds after this zap, but even with
     this zap 6.06 is 3 times higher than the 28 seconds 5.18 required.

                       MVS/XA After Zap comparisons
                 5.18 TCB sec     6.06 TCB sec    Ratio 6.06 to 5.18
      3081K         64.96           174.58            2.68 times
      3090-200E     28.16            84.24            2.99 times
      3090-200S     34.00            73.60            2.16 times

  2. PROC SOURCE of MXG.SOURCLIB, 3090-200E MVS/XA CPU measurements.

      Ver       EXCPs    SRM Active    CPUTCB Time   CPUSRB Time
      5.18      6015      50.37 sec     2.25 sec       .60 sec
      6.06      5076      71.72 sec     5.78 sec       .79 sec

      TCB CPU is 2.5 times higher with 6.60.

  3. TESTIBM step (builds 150 data sets, with zero obs, then printed
     250+ pages of PROC CONTENTS), on 3090-200 under MVS/XA:

      Version   EXCPs    SRM Active    CPUTCB Time   CPUSRB Time
      5.18     75,048    935.81 sec    61.62 sec      6.61 sec
      6.06     17,131    576.29 sec   151.38 sec      2.56 sec
      6.06*    16,364    646.94 sec   149.20 sec      2.47 sec
      6.06**   11,908    630.46 sec   290.01 sec      4.07 sec

          * - specified BLKSIZE=23040 as OPTIONS, but PROC CONTENTS
              still showed 6144 byte blocksize of WORK data sets. Why?

         ** - specified DCB LRECL and BLKSIZE as 23040 on WORK DD.

     TCB CPU (at 6144) is 2.43 times higher, 4.75 times higher at 23040.
     Must investigate and understand BLKSIZE and BUFNO impact in 6.06.

  4. BUILDPDB with a day's data, SAS blksize 6144, 3081-K under MVS/XA:

      Ver       EXCPs    SRM Active    CPUTCB Time   CPUSRB Time
      5.18     27900    1075.61 sec   303.49 sec      7.08 sec
      6.06     17550    1003.43 sec   432.97 sec      5.94 sec

     TCB CPU is 1.42 times higher with 6.06 than with 5.18.

  5. Under CMS SAS 6.06, processing VM/Monitor data used more virtual
     memory (from 900K to 3500K), more CPU (from 142 to 208, or 1.46
     times more), and the elapsed time increased from 18 to 22 minutes.



     e. Summary of MXG required or recommended SAS ZAPs for 6.06.

          Z6060288   Z6060529   Z6060571   Z6060611
          Z6060640   Z6060652   Z6060653   Z6060703
          Z6060872   Z6060874   Z6060938   Z6060946

III. Documentation and Installation of MXG Software Source Library.

Member CHANGES contains the current MXG version status and changes that
have been installed in that library. Member CHANGEnn is a copy of the
member CHANGES as it was when MXG version nn was created.  Details on
enhancements will be found in the text of the Change description that
made the enhancment (in the CHANGES and CHANGEnn members).  The text of
all changes is printed in MXG Newsletters. The CHANGES members can also
be scanned online (with SPF BROWSE) to search for specific product name
references (CICS, MVS/ESA, etc.). The CHANGES member in a library is
always more accurate and timely than the text printed in newsletters.
The text of each Change identifies the member(s) affected by each change
and additional documentation (especially for new product support) often
is contained in comments at the beginning of those affected members.

Member NEWSLTRS contains the text of all newsletters (up through the
newsletter that accompanied that MXG release). You can search NEWSLTRS
for product name or acronym to find the technical notes, APARs, etc.
from all MXG newsletters.  (The Change Log of each Newsletter is not
replicated in member NEWSLTRS, since that text will be in CHANGES).

Member DOCVERnn is the "delta-documentation" (in abbreviated Chapter
FORTY style) of only those variables and datasets that were changed
between successive MXG Versions. There is a DOCVERnn "delta" member in
the MXG library for each version.

Penultimately, member DOCVER contains abbreviated Chapter FORTY format
that documents all of the 24,690 variables from the 759 MXG data sets
that can be created by that MXG Software Version (alphabetically by data
set name and variable name).

Finally, MXG is a source distributed system, so you can often find your
answer by BROWSE/EDIT of the source member, especially the VMAC...'s
that actually create the data set, or ANAL....'s that analyze the MXG
datasets. In many instance, the MXG Variable is the IBM or Vendor's
documented field name. In other cases, the IBM field name is carried as
a comment beside the MXG variable that contains that information.  In
all cases, you should also have the Vendor's documentation of the
particular data record you are using for analysis.



The MXG Installation instructions are found in Chapter 32 of the MXG
Supplement for both new installation and for version replacement.

The MXG tape is distributed as a Non-Labelled (NL) tape with a single
file, DCB=RECFM=FB,LRECL=80,BLKSIZE=6160, that is actually an unloaded
Partitioned Data Set containing 1100+ members (and about 250,000 source
lines) in IEBUPDTE format. Under CMS, this format is read with the CMS
TAPPDS command, under MVS the IEBUPDTE utility program is used.

The PreRelease 8.2 SOURCLIB requires SPACE=(CYL,(30,1,199)) using a DCB
attribute of DCB=RECFM=FB,LRECL=80,BLKSIZE=23440.

The PreRelease 8.2 SASLIB format library for SAS Version 5.18 (built by
the first step of JCLTEST) requires SPACE=(CYL,(3,1,99)) and its
blocksize is set by PROC FORMAT under SAS 5.18.  If you are executing
PreRelease 8.2 under SAS Version 6.06, the LIBRARY DD is used in the
first step of JCLTEST and will need SPACE=(CYL,(10,1)). See Newsletter
SEVENTEEN for a discussion of Format libraries under SAS 6.06.
       Sep 1, 1990 addendum: Excess space required by format library was
         a problem only in 6.06 beta and was fixed in April 6.06.01. The
         SAS 6.06 format library for MXG need only be CYL,(1,1).

Always read comments in the CHANGES member for any compatibility issues,
as well as for any last minute changes added after Newsletter printing.

IV.  CHANGE LOG
--------------------------Changes Log---------------------------------

 You MUST read each Change description below to determine if a Change
 will impact your installation.  All of these changes have been made
 to this MXG Source Library.

 Member CHANGES of the MXG SOURCLIB will always be more accurate than
 the printed changes in a Newsletter, because the software is created
 after the newsletter is sent to the printer!

 Member CHANGES always identifies the actual version and release of
 MXG Software that is contained in that library.

 The actual code implementation of some changes in MXG SOURCLIB may be
 different that described in the printed NEWSLETTER (which might have
 printed only the easily installed, critical part of the correction).

 Always read the comments at the beginning of each source member named
 under the Change Number when you receive a new Version of MXG.

 Documentation of new datasets and variables, validation status, notes,
 etc., are usually in comments in the source members.

 If you have to install printed changes from an MXG Newsletter, you
 could copy the affected member(s) from MXG.SOURCLIB into your existing
 USERID.SOURCLIB and then make these changes therein.  Use SPF 3.3
 COPY command instead of the COPY subcommand of EDIT to avoid renumber.

 Or alternately, you might create a new PDS, named MXG.CHANGLIB, and put
 these in-between-version changes in that PDS, concatenating it between
 USERID.SOURCLIB and MXG.SOURCLIB until you get the next MXG version.
 When you do, you then delete this MXG.CHANGLIB library, as the changes
 will have been installed for you in the new MXG version.  It is wise to
 record your changes in a member named CHANGES in the installation's
 USERID.SOURCLIB as a permanent log of tailoring, etc.

 Whenever you install changes or test a new version of MXG (or even for
 your own reports), be extra careful to look on the SAS log for any real
 error conditions. Search for all occurrences of "ERROR:"  "ERROR :"
 "UNINITIALIZED" "NOT CATLGD", as they usually indicate a serious error.

 PROC PRINT and PROC MEANS of each new MXG-built SAS dataset will go
 a long way in explaining their contents, and can be examined to detect
 unusually large, negative, or suspicious values.

 Summary of critical actions to be taken in installing new version:

     a. All IMAC.... members in your USERID.SOURCLIB must be compared
        with the new IMAC.... members, and if there is a difference,
        you MUST start with this version's IMAC and retrofit your
        installation changes.

     b. It is always wisest to PROC PRINT the first 50 observations of
        important datasets, especially PDB.JOBS, which can be affected
        by user tailoring in IMACPDB. A visual scan will often alert you
        to unexpected results.

Alphabetic INDEX of significant changes:

  Member    Change   Description

  ANALDB2R  8.030  DB2 Reporting from GTF data fails.
  ANALDB2R  8.031  DB2 Report PMLOK03 fails with 170 format error.
  ANALDB2R  8.067  Report selection by time frame incorrect, minor.
  ANALDSET  8.077  ACCESS variable was not created, report failed.
  ASMTMNT   8.070  MXG Tape Mount Monitor on 7.7 does support MVS/ESA.
  ASUMCICS  8.023  Variable LENGTHs caused trunction.
  ASUMCICS  8.076  Response buckets off by one.
  ASUMJOBS  8.076  Response buckets off by one.
  ASUMTMNT  8.076  Response buckets off by one.
  BUILDPDB  8.069  ACCOUNT/SACCT in SMFINTRV, SPIN in PDB, TYPE25 added.
  CONFIG    8.068  SAS 6.06 options member added to MXG library.
  EXACFJR   8.047  ACF2 dataset ACF2JR may have deleted observations.
  FMXGUCBL  8.009  Returns wrong value under SAS 5.18.
  IMACPDB   8.048  Variables ABNDRSNC DIVRREAD DSSIZHWM TERMNAME added.
  JCLTEST   8.001  Options MACRO DQUOTE MWORK=28K required by MXG.
  JCLTEST   8.025  WORK.DIRMACR REQUIRES MORE SPACE error condition.
  JCLTREND  8.058  PROC SORT added to avoid not-sorted condition.
  NPM       8.038  NPM records from VM can be processed.
  TYPE110   8.065  Support for new CICS 3.1.1 major changes.
  TYPEDCOL  8.074  Support for SMS DCOLLECT data records.
  TYPEIMS   8.006  IMS crashes caused duplicate DTOKEN.
  TYPEMONI  8.036  CREATIME in MONITASK may have wrong date.
  TYPEORAC  8.080  Support for Oracle SMF record.
  TYPETSOM  8.007  Missing STRTTIME in TSOMCMND.
  VMAC110   8.040  CICSTRAN may have 0 observations with CICS 1.7.
  VMAC1415  8.017  New HiperBatch counts added to SMF type 1415.
  VMAC37    8.022  Variable KEEP, FORMATs.
  VMAC39    8.022  TYPE39EL conditionally created. ZDATE kept.
  VMAC41    8.015  New VLF counts in new subtype 3 SMF type 41.
  VMAC6     8.057  STOPOVER due to invalid external writer record.
  VMAC6156  8.027  STOPOVER error with ICF catalog record section.
  VMAC6156  8.034  Minor. Variable FUNCTION more values decoded.
  VMAC6156  8.039  TYPE6156 VOLSER may be wrong for GDGs.
  VMAC7072  8.066  Support for new "SRCL" field in RMF Product section.
  VMAC78    8.049  TYPE78CF only output if CHPID is online.
  VMAC79    8.012  STOPOVER correction, support validation.
  VMAC79    8.055  Formats and units corrections.
  VMACACF2  8.002  ACF2 SMF record caused STOPOVER.
  VMACCIMS  8.064  Support for IMF 2.6 (for IMS 3.1).
  VMACCRAY  8.044  New code. Support for CRAY COS operating system
  VMACDMON  8.003  Uninitialized variable in ANALDMON caused.
  VMACIDMS  8.005  IDMS SMF record variables format incorrect.
  VMACIMS   8.042  Minor IMS log processing changes.
  VMACNSPY  8.010  NETSPY 3.2 support was incomplete.
  VMACNSPY  8.043  Netspy 3.1 STOPOVER.
  VMACROSC  8.028  ROSCOAUD contained zero observations always.
  VMACSMF   8.013  DB2 read from GTF. Minor.
  VMACSYNC  8.020  Invalid CPUTCBTM value detected.
  VMACSYNC  8.056  SIRECFM,SORECFM contain invalid data value.
  VMACTMNT  8.033  Minor. Formats for DEVFROM/DEVTO.
  VMACTPX   8.016  No observations in TPXINTRV.
  VMACVMON  8.037  Divide by zero.
  VMACVMON  8.045  24APR90 became 02OCT89 when 202 day clock wrapped.
  VMACVMXA  8.004  OMEGAMON/VM creates invalid VM/XA VB records.
  VMACVMXP  8.041  Minor EXPLORE/VM processing changes.
  VMACVVDS  8.073  Validation of VVDS record created by ASMVVDS.
  VMACX37   8.024  STOPX37, minor.
  VMACZRB   8.054  RMF 4.1.1 caused STOPOVER.
  VMACZRB   8.079  Further validation, release independent RMF III.


Alphabetic INDEX of significant changes (continued):

  Member    Change   Description

  VMXGSUM   8.021  Missing variable initialization protection.
  VMXGVTOC  8.018  OFFSET4E and SMS variables added.
  VMXGVTOC  8.032  Minor. RECFM should be $4.
  VMXGVTOC  8.075  Did not capture free space at beginning of volume.
  VMXGVTOR  8.009  Incorrect on 7.7, changes not propagated.
  XMAC7072  8.014  ZDATE not kept in TYPE70PR and TYPE72MN
  XMAC71    8.014  Extraneous period.
  XMACEPIL  8.019  Plus sign missing. Don't use VMACEPIL or XXACEPIL.
  ZZZZZZZZ  8.011  Final member of MXG Library is named.








Inverse chronological list of all Changes 8.080 thru 8.001
****************NEWSLETTER SIXTEEN**************************************










             MXG NEWSLETTER NUMBER SIXTEEN  February 14, 1990

Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE

                         TABLE OF CONTENTS

I.   MXG SOFTWARE VERSION 7.7 ANNOUNCEMENT.           pages   2 thru   8

  1. Production MXG Version 7.7 enhancements.                   page   2
  2. Installation sizing and instructions for MXG 7.7.          page   6
  3. Enhancements planned for the next version of MXG.          page   7
  4. Future considerations for MXG enhancements.                page   8

II.  TECHNICAL NOTES                                  pages   9 thru  18

  1. MVS/ESA changes to RMF CPU Capture Ratio decreases.        page   9
  2. MVS PTFs                                                   page  10
  3. MVS Technical Notes                                        page  10
     a. CPU cost of page movement to/from ESTORE.
     b. Additional notes on TYPE72 variable ACTFRMTM.
     c. Impact on BUILDPDB of the PROC SYNCSORT product.
     d. SRM control in LPAR PR/SM environment.
     e. Conjecture on PR/SM Dedicated Partition timings.
     f. Memory measurement reference.
     g. No EXCP data for type 30 subtypes 4 and 5 from STCs.
     h. PR/SM and LPAR considerations.
     i. ESTORE and MAXMPL notes.
     j. Sequencing of task startup for RESOLVE and RMF.
     k. Upper limit on QSAM/BSAM buffers.
     l. Parallel mount impact on MXGTMNT measured duration.
     m. 3480 tape cartridge statistics.
     n. Cost of initializing MXG Trend data base
  4. VM/XA Performance Note on DSPSLICE value.                  page  15
  5. SAS System Technical Notes                                 page  16
     a. SAS technique to locate data value location in INPUT.
     b. MXG Compatibility with SAS Version 6.06+.
     c. Timestamp trunction with incorrect LENGTH value.

III. CHANGE LOG                                       pages  19 thru  42

     Changes through Change 7.243 to 7.166

 IV. SRM CPU parameters for MPL Control In LPAR       pages  43 thru  45

     Reprint (with permission of IBM Corporation) of this
      fine article by Richard Armstrong, originally made
      available as Washington Systems Center FLASH 8923,
      June, 1989.



         COPYRIGHT (C) 1990 BY MERRILL CONSULTANTS DALLAS TEXAS
          MXG IS A REGISTERED TRADEMARK OF MERRILL CONSULTANTS
          SAS IS A REGISTERED TRADEMARK OF SAS INSTITUTE






I.   MXG SOFTWARE VERSION 7.7 ANNOUNCEMENT.

  1. Production MXG Version 7.7 enhancements.

 The Production Version 7.7 of MXG was shipped during the last week of
 February, 1990, to all supported MXG sites.

  MXG Version 7.7       dated February  14, 1990, thru Change 7.243).
  (Newsletter SIXTEEN   dated February  14, 1990, thru Change 7.243).
  (PRERELEASE MXG 7.6   dated January   29, 1990, thru Change 7.228).
  (PRERELEASE MXG 7.5   dated December  22, 1989, thru Change 7.207).
  (PRERELEASE MXG 7.4   dated November  25, 1989, only for an ESP).
  (PRERELEASE MXG 7.3   dated November  25, 1989, thru Change 7.190).
  (Newsletter FIFTEEN   dated November  11, 1989, thru Change 7.165).
  (PRERELEASE MXG 7.2   dated October   19, 1989, thru Change 7.161).
  (BETA test  MXG 7.1   dated September 14, 1989, thru Change 7.140).
  (BETA test  MXG 7.0   dated May       31, 1989  thru Change 7.098).
  (Newsletter FOURTEEN  dated April      1, 1989, thru Change 7.035).
   Previous Version 6.6 dated January   20, 1989, had 206 changes.


 Operating System and Subsystem Version.Releases supported in MXG 7.7:

  MVS/ESA thru 3.1.3 and DFP thru 3.2.
  CICS thru 2.1.
  DB2 thru 2.2.0.
  RACF thru 1.9.
  VM/370 thru Release 6 and HPO thru Release 5 (no known problems).
  VM/XA SP thru 2.1 plus later PTFs.
  IMS 2.1 and IMS 2.2 (see special note for 1.3).

 New Devices Recognized and/or supported in MXG 7.7:

  3490 and 9348 tape drives (cart and reel respectively) recognized.
  3480/3490 Tape Compression (IDRC) recognized.
  3390 DASD devices recognized and counted in EXCP3390/IOTM3390.









 Most important new enhancement in MXG Version 7.7:


  MXGTMNT, the long awaited MXG Tape Mount Monitor, captures how long
   operators take to mount tapes, and identifies which job mounted what
   tape on which tape drive when, with no system modifications. The
   monitor wakes up every 2 seconds to scan the UCB chain, and writes
   a User SMF record when each tape mount is satisfied.








 Alphabetic (by acronym, of course) list of major changes, enhancements,
 and new products/versions now included and supported in MXG 7.7:

  ACF2 'ARE' data sets captured.
  AION Development System SMF record from AION.
  VSAM activity included with non-VSAM in ANALDSET I/O analysis by job.
  ARBITER SMF records from Tangram product.
  CMF and RMF records can now be differentiated.
  CPU Serials added to RMFINTRV.
  DB2 Audit Class trace type 102 records.
  DB2 SQL text ("what he typed in") is captured.
  DB2PM-like reporting enhancements for DB2 2.2 in ANALDB2R.
  DFP 3.2 TYPE42 SMF record.
  DOS/VSE Power 3.1.2.
  FILEAID SMF record from COMPUWARE product.
  GTF format DB2 trace data supported.
  ICF TYPE6156 VOLSER capture and enhancement.
  IDRC (Improved Data Recording Compression) for 3480/3490 tapes.
  IMS 1.3 transaction processing: see Change 7.075.
  IMS 2.0 and IMS 2.1 response measurement corrections.
  JES2 mods to capture SYSOUT release timestamp in type 6 SMF record.
  MDFTRACK SMF record from Amdahl MDF environment.
  MVS/ESA 3.1.3 SMF and RMF records.
  MVS/ESA CPU timings in step records.
  NAF SMF record from Candle's Network Accounting Facility.
  NETSPY Release 3.2 SMF record.
  NETVIEW TYPE37 Release 2 Hardware Monitor External Log Record.
  NETVIEW TYPE39 Release 2 Session Monitor External Log Record.
  OMEGAMON Command Audit SMF record from Candle.
  PDB.STEPS contains STEP accounting fields (if any).
  PDSMAN/XP Release 6 SMF record.
  RACF 1.9 (based on SMF 3.1.3 manual) SMF records.
  RMF Monitor II Type 79 SMF record (fourteen subtypes).
  RMF Monitor III VSAM data set records and TYPE72MN enhancement.
  ROSCOE 5.6 support for variable number of complexity levels.
  STOPX37 Release 3.3 SMF record from Empact product.
  STX Release 1.0+ supported.
  TLMS (Tape Library Management System) catalog records.
  TMON/MVS data records (non-SMF) from Landmark's Monitor for MVS.
  TMS (Tape Management System) catalog records.
  TPX Release 2.0.0 SMF supported.
  TREND data base validation and enhanced report examples.
  TSO/MON Version 5.2 SMF record from Legent product.
  VM/XA SP 2.1 plus PTFs, and protection for VCOLLECT environment.
  VMXGVTOC enhanced for VSAM with 128 extents and DASD VTOC data.
  VSAM TYPE64 PTF to add important data for HiperBatch aid.

  Validation and cleanup of all reported MXG 6.6 errors.












 Pre-release by pre-release delta of changes (for testers, thanks!):

  Significant changes added in 7.7 that were not in 7.6:

   Support for Release 3.3 of Empact's STOPX37 product.
   IMS 2.2 algorithm enhancements improve IMS log response captured.
   ANALDB2R updated for DB2 2.2 (most reports, except DDF).
   Lots of final cleanup from pre-release testing.

  Significant changes added in 7.6 that were not in 7.5:

   Support for all 14 subtypes of the type 79 RMF Monitor II record.
   Support for VM/XA SP 2.1 plus new PTFs, and integrity enhancements.
   Enhanced decoding of TYPE6156 ICF Catalog record to add VOLSER(s).
   Support for Candle's Network Accounting Facility SMF records.
   Support for Legent's TSO/MON Version 5.2 added.
   Support for Landmark's TMON/MVS product.

  Significant changes added in 7.5 that were not in 7.3:

   Support for MVS/ESA 3.1.3, including the major enhancements in type
    6 SMF record and a new type 42 DFP and 83 RACF SMF records.
   Support for the VSAM PTF changing SMF 64 record (for HiperBatch Aid)
   Support for DB2 Release 2.2.0 changes to 100, 101, and 102 records.
   Support for Netspy Release 3.2.
   Support for PDSMAN/XP Release 6.
   Validation of NETVIEW type 37 SMF record modem section.
   Correction of JES3 type 6 (prerelease only) error.

  Significant changes added in 7.3 that were not in 7.2 or Newsletter 15

   DB2 I/O, Locking, and Record Trace reports added to ANALDB2R.
   MVS/XA & ESA Pathing configuration and activity report in ANALPATH.
   3390 DASD device support is official (support is already in 7.2).
   RMDS pagecounts are fixed.
   D3330DRV (mountable drive count) eliminated from 30s and PDB.
   GTF format DB2 type 102 trace data now correct.
   VMXGVTOC cleanup (deletes to clean WORK, last track counting, etc.)
   TPX Release 2.0.0 new release supported,
   STX Release 1.0+ new product supported.

 Prior changes added in 7.2 and earlier are listed in Newsletter 15.


 Documentation of enhancements in MXG Version 7.7.


 Details on enhancements, and their impact will usually be found in the
 text of the actual Change description itself.

 While Changes can and should be read in the printed Newsletter, it is
 very helpful to use SPF BROWSE/EDIT to scan the online documentation
 available in member CHANGES of the MXG Source Library interactively.

 Member CHANGES contains the current MXG version status and changes that
 have been installed in that software. Member(s) CHANGEnn are copies of
 member CHANGES as it stood when MXG version nn was created.

 In addition, the Change Number lists the member(s) affected by that
 change. Browse those members, especially the ANAL...., IMAC...., and
 VMAC.... members for further documentation and usage notes.

 Member NEWSLTRS contains the text of all newsletters (including the
 newsletter that accompanied that MXG release). You can usually search
 on product name or acronym to find the MXG acronym and member names
 that document, support, and process that product's data records.

 Member DOCVER07 contains abbreviated Chapter FORTY style documentation
 of just those variables and datasets that were added by MXG Version 7.7
 since MXG Version 6.6, the "delta-documentation".  For example, you
 could browsing DOCVER07 for the TYPE70 thru TYPE79 (RMF) dataset
 descriptions, to learn what new information IBM has added to RMF data
 records. There is a DOCVERnn member in the library for each version.

 Penultimately, member DOCVER contains abbreviated Chapter FORTY format
 documentation of ALL 22,058 or so variables from the 679 or so MXG data
 sets that can be created by MXG Software Version 7.7 (alphabetically by
 data set name and variable name).

 Finally, MXG is a source distributed system, so you can often find your
 answer by BROWSE/EDIT of the source member, especially the VMAC...'s
 that actually create the data set, or ANAL....'s that create the MXG
 report.  In many instance, the MXG Variable is the IBM or Vendor's
 documented field name. In other cases, the IBM field name is carried
 as a comment beside the MXG variable that contains that information.

   In looking thru MXG library members online, try these SPF techniques:

     Make a COPY of member CHANGES (don't use the actual member, because
     you will use an EDIT command, which can delete/change data
     accidentally).
     For example:
     EDIT a non-existent new member and COPY in (for example) CHANGES.
     On the command line, enter EXCLUDE ALL.
     On the command line, enter FIND "VM/XA" ALL , for example.
      which will result in your display containing only those
      lines that contain VM/XA.
     You can then un-exclude the lines before and after each occurrence
      by typing L5 or F3 on the line number of the excluded lines to now
      display or un-exclude the Last 5 or First 3 lines.
     When done, CANCEL from the command line & nothing will be written.
     The use of SPF commands EXCLUDE ALL and FIND ALL is a major tool in
      creating and maintaining MXG software.  It's especially useful is
      scanning through a large number of lines of text, like MXG CHANGES
      and NEWSLTRS members. Unfortunately, it is only available as a
      subcommand of EDIT; you cannot EXCLUDE under BROWSE.


  2. Installation sizing and instructions for MXG 7.7.

  The MXG Installation instructions are found in Chapter 32 of the MXG
  Supplement for version replacement as well as new install.

  The MXG tape still is distributed as a Non-Labelled (NL) tape with a
  single file, DCB=RECFM=FB,LRECL=80,BLKSIZE=6160, containing an
  unloaded Partitioned Data Set containing 1100 members (and about
  220,000 lines of source) in IEBUPDTE format. Under CMS/SAS this format
  is known to the TAPPDS command instead of the MVS IEBUPDTE program.

  At 303 feet of 6250BPI tape, MXG no longer fits on those little
  half-full minireels with 300 feet of tape. (They were only $6.50 each
  when a full 600 foot reel was $11.75, and in 1984 MXG Version 1 was
  only 99 feet long.)  Now, for those of you who are still in those dark
  ages and require MXG on 3420 tape reels, MXG arrives on that same 7
  inch mini reel, but now it's full (and 600 feet now costs $6.50!).

    If you received a mini-reel instead of a 3480 cartridge, please
     let us know as soon as you can accept 3480 tape cartridges.
    We can create about 250-300 cartridges per hour, but only about 100
     of the reels per hour, and they have more errors!  And cartridges
     are only $5.75!

    Judy still holds the world land speed record of 11 seconds per 3420
     tape mount building MXG Version 4.

  The MXG Version 7.7 SOURCLIB requires SPACE=(CYL,(30,1,199)) with
  a DCB attribute of DCB=RECFM=FB,LRECL=80,BLKSIZE=23440.

  The MXG Version 7.7 SASLIB format library (built by the first step
  of JCLTEST) requires SPACE=(CYL,(2,1,99)) and the blocksize is
  set when JCLTEST's first step is run.

  See the comments below in the Changes log (or in member CHANGES)
  for compatibility issues with installation tailoring IMAC....
  members.

  Pre-releases of MXG 7.7 have been installed by over 400 sites this
  year, and no real problems in installation have been encountered.
  The major portions of all the important code have been running in a
  production status at many sites for months.  MXG 7.7 has been better
  tested than any of the preceding 28 releases, but as it must always
  be, it's up to you to validate with your own data.






  3. Enhancements planned for the next version(s) of MXG.

  These items were under consideration but did not get completed in time
  for MXG Version 7.7.  We anticipate a pre-release by mid-summer 1990
  (for Landmark's Release 8 and IBM's CICS/ESA 3.1 Version) by product
  availability. The next newsletter will be in June or July, 1990.

     IBM's CICS/ESA 3.1 promises major changes in CICS monitoring, with
     announced availability in June of 1990.

     Landmark's Monitor for CICS Release 8. Data was not available for
     testing (the product is not yet available), but will be soon.

     VMACHSM SMF record is incomplete (Change 7.096).

     Oracle product SMF Record.

     WSF product SMF Record.

     LLA IBM-documented, User SMF Record.

     VAX/VMS Accounting and Performance data processing. This support
     will require mainframe SAS Version 6.06 or later, and will be
     supported for execution only in MVS, CMS or DOS versions of SAS,
     operating on VAX/VMS data that has been ported to an IBM system.

     Cray COS (and eventually UNICOS) accounting and performance data
     processing. To be implemented as discussed for VAX, with the Cray
     data to be ported to an IBM system.

     JES3 TYPE25 mounts merge with MXGTMNT mounts.

     Amdahl CPUID of 'C05157' (Character) instead of expected PK3.

     BUILDPDB enhancement to add ACCOUNTn to TYPE30_V Interval data.

     AIM enhancements.

     EPILOG CICS CL1000 Versions 430, 440, and 450 have not been
       personally verified, but several users report that XXACEPIL does
       not fail with either 440 or 450. (For 430, one site suggested to
       set the offset to -4 and MXG processed the records.)  I simply
       did not have time to install the Candle decompression algorithm
       so that I could test the compressed data I received!

     IMS/ESA 3.1 Validation.

     IBM incorrect storage of values in  TYPEVM VM/ACCOUNT variable
       PWCOUNT (hex values are F0F8 F0F9 F0C1 or EBCDIC 08 09 0A for
       actual data counts of 8, 9, and 10!) has not been circumvented.


  4. Future considerations for MXG enhancements.

     EPILOG/MVS product records code, documentation, etc, that was to be
       provided by Candle hasn't been.

     IMACACCT to control TASBFLDn variable's (rename to ACCOUNTn) and
      the JES3 type 26 ACCOUNT1 lengths.

     Spool Transfer interaction (still) with BUILDPDB.

     ACCOUNTn added in ANALDSET analysis.

     TYPE30_6 deaccumulation.

     VVDS analysis.

     Operational Product

     Control (OPC) data.

     Problem Change Management.

     JES3 JMF JES Measurement Facility SMF type 84 record.

     VM/XA VMPRF product reports may be replicated in MXG.

     NETVIEW File Transfer Program Release 1.0 "User" SMF Record.

     FACOM PDL record processing.

     TPNS activity log.

     IMS Fastpath records.

     Circumvent CMS limitation on VBS blocksize.

     FACOM PDL (not PDLF, which is supported) enhancement.

     DAILY/WEEKLY/MONTHLY/TRENDING PDB sample JCL and code.

     ASUMTSO for TSO/MON like ASUMCICS for CICS.

     LENGTH= protect for broken RMF Record.

     MXGMENU macro variable names.

II.  TECHNICAL NOTES

  1. MVS/ESA changes to RMF CPU Capture Ratio decreases.

    a. The following chart was published in MXG NEWSLETTER FIFTEEN, but
       the phrase "Reportedly to be captured in ESA 3.1.3" turns out to
       be incorrect. The actual CPU captured in TYPE72 records with
       MVS/ESA 3.1.3 looks like this:


TYPE 70 (RMF-captured CPU measurement of real or logical CPUs):

        Elapsed Interval (Duration multiplied by number of CPUs)
     ________________________________________________________________


     ______________________________________________________ ---------
                          CPU                                  CPU
                        Executing                            Waiting


     ________ ________ _________ ________ ________ ________
      CPU 1    CPU 2    CPU 3     CPU 4    CPU 5    CPU 6
       Busy     Busy     Busy      Busy     Busy     Busy


     ______________________________________________________
     Total Hardware CPU Busy Time (from Type 70 "non-wait")


TYPE 72 (summing only the control performance group's data) contains:


     _____ _____ ------------------------------------------
      RMF   RMF                  Uncaptured
      TCB   SRB                  RMF CPU Busy
      CPU   CPU                  pre-ESA 3.1.3
                                    Busy
     ___________ _____________________________ ------------
        CPUTM       Not yet captured in         Uncaptured
      pre 3.1.3     RMF under ESA 3.1.3          RMF CPU
                    but will be (some day).     with 3.1.3



TYPE 30 (if all work started and ended in the interval) contains:

                              Never captured
                              before (IIP,RCT)
                              or new (HPT).

     _____ _____ _____ _____ _____ _____ _____ ------------
      SMF   SMF   SMF   SMF   SMF   SMF   SMF   Uncaptured
      TCB   SRB   TCB   SRB   IIP   RCT   HPT      SMF
      CPU   CPU   CPI   CPI   CPU   CPU   CPU      CPU

     _________________________________________
      CPUTM = Sum of all CPU times in TYPE30

      The fact's are, CPU capture ratio has significantly declined in
      MVS/ESA 3.1.3 because Hiperspace CPU, Second Level Interrupt
      Handler CPU, and Region Control Task CPU time (all of which
      ARE captured in type 30 data) are not captured in type 72 data.



  2. MVS PTFs which may affect what IBM puts in your data records:


    APAR PL31497 (PTF UL37077) corrects error in DB2 IMS transactions
    that are executed under threads having 'reuse' option (and that
       exactly what is captured where:

    APAR OY26208 (PTF UY44574,575,576,757,758) correct invalid CPU
    Time values in step records after 913 ABEND (an other 9xx abends).

    APAR OY2m372 (no PTF as yet) reports invalid JOB and READTIME in
    type 6 records under MVS/ESA 3.1.1 with JES 2.

    APAR OY21221 (PTF UY37733) corrects timestamps in the JES2 Type
    26 SMF Purge record when Spool Transferred jobs are re-loaded.

    APAR OY19327 (PTF UY33328) corrected a bug in RSM without ESTORE.
    AFQ kept growing, no page steal, system go boom.

    APAR OY21181 is an open problem with no PCU in RMF I/O Report and
    zeroes in many fields in type 78 records.

    APAR OY24606 corrects problem with type 32 SMF record.

    APAR OY16896 corrects SMF6OUT/OUTDEVCE to now contain the ACF
    VTAM LUNAME.

    APAR OY20265 discusses SMF6PGE/PAGECNT not correct approximate
    page count for an interrupted or restarted printer.

    APAR OY12804 discusses SMF6ROUT/ROUTE is wrong if $TJ to multiple
    destinations is issued.

    APAR OX31370 SMF6LNR/NRLINES is wrong if 3800 is forward spaced.

    APAR OY21704 PSF does not update SMF6CPS/COPIES.


  3. MVS Technical notes.


    a. CPU cost of page movement to/from ESTORE.

    Bill Mullen has presented some measurements of CPU costs of movement
    of pages in/out of HIPERSPACE. The CPU time per page moved is
    clearly a function of the number of pages moved in each move
    operation. At one page per move, 80 microsecs (usec) were measured,
    but by five pages per move the cost per page is down to 45 usec per
    page, and above 10 pages per move the cost per page moved decreases
    from about 38 usec (at 10 ppm) to about 35 usec (at 200 ppm).  This
    is significantly less than the typical value of 75 usec per page
    move which has been used in some analysis of expanded storage
    movement costs!



    b. Additional notes on TYPE72 ACTFRMTM.

    Newsletter THIRTEEN discussed the Active Frame Time variable
    ACTFRMTM, measured at the performance group period level in TYPE72,
    which is the Residency Duration times the sum of the memory frames
    in Central Store plus Expanded Store that were allocated to ASIDs in
    each performance group.  (Two counters are maintained by the SRM,
    but only their sum is multiplied by residency and written in the
    TYPE72 record.  Not included in these frame counts are frames in the
    Nucleus, Common Area (since they are not in the address space), and
    of especial importance, logically swapped frames are NOT included in
    the Active Frame count of ACTFRMTM (and that can be a large amount
    of memory, especially for a TSO performance group with many
    logically swapped ASIDs!).

     c. Impact on BUILDPDB of the PROC SYNCSORT product.

    Dan Kaberon compared CPU timings of BUILDPDB executed with both the
    Syncsort standard PROC SORT and with their PROC SYNCSORT product.
    BUILDPDB invokes a sort 24 times, and in this case built a PDB of
    over 70 MB. Individual sort executions with PROC SYNCSORT do show
    reduced CPU TCB timings (TYPE74=24 MB, from 4.68 to 1.46 sec., and
    TYPE30_4=18MB, from 3.48 to 1.71 sec). But sorting itself is a very
    small part of BUILDPDB.  The total CPU (TCB+SRB) to build this large
    PDB (with 41,436 TYPE30_4 steps, 77,477 TYPE74 device records) was
    reduced by only 16.44 seconds, from 492.78 to 476.34 seconds, using
    PROC SYNCSORT, a savings of only 3.3% of the total CPU TCB+SRB
    time.  In the original PROC SORT run of BUILDPDB, log messages
    reported CPU TCB time for all sorts totaled only 19.29 seconds, or
    4% of all TCB!  Even a big savings in sort costs will have only a
    small savings if sorting is only a small part of the total.  (The
    elapsed time with PROC SYNCSORT dropped from 27:51 to 25:11 mm:ss,
    but the variability of elapsed time due to paging, swapping, tape
    mount, contention for device and dispatch make a single comparision
    questionable.)

    Is BUILDPDB representative of your other workloads' use of sorting?
    One prime time (11 hours) snapshot at a site with both a 3090-200
    and a 3090-300 showed 3,550 sorts were issued that used 19 CPU hours
    while their step records totaled 47 CPU hours, showing that over 40%
    of their processor time was consumed in sorting!  Other claims of
    25% to 33% of total CPU hours have been seen in the literature.

    I'd like to think it is the elegant design of the BUILDPDB algorithm
    which exploits the power of SAS to perform complex data merges, that
    causes only 4% of BUILDPDB processing to be in sorting!



     d. SRM control in LPAR PR/SM environment.

    Richard Armstrong's excellent article, printed by permission of
    IBM at the end of this newsletter, discusses a workflow reduction
    because default SRM values for MVS/XA 2.2 and later may be (in an
    LPAR PR/SM environment) inappropriate. The article is also a fine
    tutorial on how LPAR PR/SM data is captured. It recommends that
    RCCCPUP and RCCCPUT both have values of  (100+E),120  with E being
    the number of engines available to this MVS.

    Previous IBM supplied defaults were (IBM supplied defaults 95,98 and
    98,100.9, which tell the SRM to reduce MPL at a CPU busy of 100.9%.

    An SRM control value of (100+E) means that a 3090-600 is NOT
    overcommited for the CPU resource until the SRM measures a CPU busy
    of over 106%.

    SRM records a CPU busy of 106% when the CPU was not only actually
    100% hardware busy, but also that six IN-READY-QUEUE users were not
    dispatched during the previous SRM interval.

    IBMs recommendations simply affirm that your Central Electronic
    Complex is NOT overcommitted until MORE THAN one IN-READY user PER
    CPU is being delayed for CPU dispatch.  One Hundred Percent Hardware
    busy, PLUS one waiting user per engine, IS THE DESIGN POINT of MVS!

    That does not mean you can run your critical workload at 100%
    hardware busy, but it most certainly does mean that your hardware
    platform can and should operate at 100% busy during your peak
    period. Your site MUST segregate critical workloads into domains,
    and then tell the SRM what's important and what's not, so that in
    these otherwise lull moments during your peak period, the SRM can
    find one of these lesser important (to you) workloads to dispatch
    and thereby soak up what would have been wasted wait time. If your
    peak hourly processor utilization never exceeds 90% of a $6,000,000
    machine, you are throwing away $600,000!  To quote Armstrong,
    "Fundamentally, the MPL is too high if and only if the page fault
    rate is too high".

     e. Conjecture on PR/SM Dedicated Partion timings.

    For PR/SM partitions that are Dedicated, a 30 minute elapsed
    interval with four engines showed RMF DURATM*4 was 7200.016 seconds,
    but PR/SM PDT Partition Dispatch Time was 7191.958 leaving 8.058
    seconds unaccounted time. Is this the "overhead" for PR/SM
    management of a dedicated partition? If so, it is only 0.44 percent
    (less than one half of one percent) of the 30 minute interval.
    (Shared partitions do not offer any similar instrumentation). This
    site is conducing more research on this.

     f. Memory measurement reference.

    Measurement of real memory requirements by task, workload, etc., is
    not easy in MVS.  The best discussion of how complicated it can get,
    and how to put the various pieces together from the may RMF/SMF
    records is the presentation by Gary King that was published in SHARE
    Proceedings (Volume I) from the SHARE 72 meeting (February, 1989),
    Session O262, pages 448-482.



     g. No EXCP data for type 30 subtypes 4 and 5 from STCs.

    SMF Type 30 subtypes 4 and 5 for STCs (Started Tasks) do not contain
    an EXCP segment when INTERVAL and NODETAIL is specified in SMFPRMnn
    member of SYS1.PARMLIB, even though the EXCP segment does exist in
    subtypes 2 and 3 (the interval records). This is documented under
    the DETAIL parameter in Initialization and Tuning (but not mentioned
    in SMF Manual).  What is not documented is that the default options
    NOINTERVAL and NODETAIL DO create EXCP segments for STCs in subtypes
    4 and 5, the step and job termination records! Thus a site which had
    not specified INTERVAL and had NODETAIL by default, did have EXCP
    counts in STC step and job termination records, but when the site
    enabled INTERVAL data, the EXCP counts for all STCs became zero in
    PDB.JOBS and PDB.STEPS.  The moral: ALWAYS specify DETAIL for STCs
    IF YOU NEED EXCP COUNTS from subtype 4 and 5 records in PDB.JOBS and
    PDB.STEPS, no matter what INTERVAL/NOINTERVAL parameters specify.
    But, there ARE also good reasons to specify NODETAIL and use only
    the PDB.SMFINTRV data, instead of PDB.JOBS/PDB.STEPS for EXCP data:

    26Apr02 revision to the preceding "ALWAYS specify DETAIL":
    - IBM Information APAR II07124 discusses why you might need to
      specify NODETAIL for your STC's:  When DETAIL is specified, the DD
      and EXCP information will be stored in 32K memory blocks in SP230,
      and those blocks (in virtual storage) are kept for the entire life
      of the address space.  For an STC like DBM1, which can have 10,000
      DDs, its SP230 can grow and run out of private area storage, both
      high and low, requiring a restart of the DB2 system to clear the
      Sub Pool.  Instead, with NODETAIL, the DD information is only kept
      for each interval record, i.e., in PDB.SMFINTRV, so the data is
      available in SMF, and DBM1's SubPool 230 does not grow over time,
      so you don't have to stop and restart your DB2 subsystem.
    - That APAR also recommends DDCONS=NO, a parameter that was created
      by IBM as a result of an MXG user's discovery of the problem it
      corrects, so MXG has always recommended DDCONS=NO be specified.
    - Specifying NODETAIL for STCs has no direct impact on MXG logic.
      Your STC observations in PDB.JOBS/PDB.STEPS will have zero for the
      EXCP/IOTM variables, which might affect your chargeback for STCs,
      but STCs are usually an internal charge; furthermore, only those
      STCs that are terminated normally (created subtype 4/5) could have
      been billed for STC EXCP counts.  But the EXCP/IOTM variables for
      STCs will exist the PDB.SMFINTRV dataset for each interval, even
      with NODETAIL, as long as INTERVAL is enabled to write subtype 2/3
      records, (and MXG member IMACINTV was enabled to populate TYPE30_V
      and PDB.SMFINTRV datasets).  And with a large value for SPINCNT in
      your MXG member IMACSPIN, dataset PDB.SMFINTRV will contain the
      ACCOUNTn and SACCTn accounting fields for the STC, so those EXCP
      counts for your STCs can still be charged back with PDB.SMFINTRV.
    12May03 addition:
    - To keep DB2 "up forever", you do NOT have to turn off SMF interval
      recording, which is a mis-reading of that APAR.  As long as both
      NODETAIL and DDCONS=NO are specified, the NODETAIL eliminates the
      SP230 growth issue, and DDCONS=NO eliminates the CPU spike, so you
      can continue to write SMF type 30 interval records for your DB2
      that is designed to "never end".


     h. PR/SM and LPAR considerations.

    PR/SM and LPAR considerations are extremely well described in the
    WSC FLASH 8923 in this newsletter.  In addition, these other entries
    in IBM's INFO/SYS will be of interest to sites executing in these
    "Multi-Image" environments (either MVS with PR/SM, or VM/XA).
    Examine these entries if you are in these environments:


          Q399071         Q423087          Q399108
          Q458004         Q424130          Q395069
          Q410851         Q433673

     i. ESTORE and MAXMPL notes.

    I have a scratch pad note of collected facts from somewhere, but I
    can't remember whose presentation or where!  I hesitated to print
    them, but they sound too authoritative to be wrong and too useful
    to not be shared:


    For a 3090 ESTORE machine when UIC is below 5 to 10:
     - MAXMPL control is not dynamic enough,
     - CPU control is not particularly important since the real concern
       is memory, and thus CPU is a second order effect,
     - UIC=(2,4) was suggested because it
       -- Prevents Thrashing
       -- Is insensitive to page movement in/out of ESTORE
          (Movement does not hurt response, but movement costs
           CPU time, and logic to decide to lower MPL itself
           "costs" CPU time to execute.)
     - When this happens, RMF can show very high Master address space
       SRB CPU Time (MXG variable CPUSRBTM in TYPE30_V for the jobname
       of the Master ASID's interval record). You can probably estimate
       high master address space SRB time by looking at RMF Performance
       Group 0 SRB time, since only Master and a few other tasks execute
       in PERFGRP=0.
     - MASTER SRB plus UNCAPTURED CPU are the main places for ESTORE
       page movement CPU time to actually be recorded.
     - Storage Isolation PWSS controls the sum of Real plus ESTORE.
     - There is no support for period switching by the SRM for tasks
       which are non-swappable.

       If the author recognizes his work, I'll acknowledge the source.



     j. Sequencing of task startup for RESOLVE and RMF.

    Boole and Babbage's RESOLVE product caused RMF date to be
    "clobbered" when RESLOVE was started before RMF. Apparently at
    RESOLVE startup time, the MONITOR CSA function grabs the IOCDS
    (I/O control data set, which contains all the static I/O mapping
    information needed by RMF). Then when RMF started second, it
    could not get at the IOCDS, and type 78 data in RMF records was
    invalid.  As long as RMF is started first, there is no problem.
    However, there is no way during startup to actually guarantee that
    a task has completed startup before another task starts! (I had
    assumed there was some standard "WAIT UNTIL DONE" command to
    sequence task startup).  This site ultimately solved their
    problem by inserting the startup of their large Network between
    RMF startup and RESOLVE startup.

     k. Upper limit on QSAM/BSAM buffers.

   Brian Bowman of SAS Institute has pointed out that the upper limit
   of 30 buffers for BUFNO in SAM access methods is a constant in MAP
   Defined limit IGGSAMB, but the actual number of buffers that can
   be used is a function of the block size of the access. The real
   storage channel program must fit in a 4K SAMB to pass to EXCPVR.
   For example, at a blocksize of 18K, only 11 blocks can fit in the
   single SAMB (which contains the IOBs, DEVADDR, and IDAWs).  Even
   if you requested BUFNO=30,BLKSIZE=18000, you only get 11 x 18000
   bytes of data per I/O operation, or 198,000 bytes per SSCH!

   This limit only applies to SAM access methods; if the programmer
   writes his own EXCP access, there is no such limit on the length
   of data transferred in a single I/O operation.


     l. Parallel mount impact on MXGTMNT measured duration.

   Parallel mounting occurs when two or more units are allocated to
   a DD. (This is rarely used now, but was very important when IMS
   logs were written to tape; two tape drives had to be allocated to
   that single DDNAME in the IMS job so that when one tape filled
   IMS could immediately continue writing its log. Before we allocated
   the second tape drive for the IMS log, IMS would WAIT all terminals
   while the log tape rewound, and the operator got the new scratch
   tape on as quick as he/she could. In fact, we located both tape
   drives well away from the tape area, immediately beside the IMS
   Master Terminal Operator's console!)

   The mount verification of the second tape mount is delayed until
   EOV (end of volume) on the first tape volume is complete, even
   though the second tape had been physically mounted a long time
   ago (in the case encountered, it took 6 minutes to read each of
   the 128 3480 cartridges in the multi-volume tape data set!)

   The MXGTMNT Tape Mount monitor sees the second mount complete after
   the first mount has been read and after the second device was
   actually opened, according to Guy Caron, whose similar VERSTAND
   mount monitor apparently protects for parallel mounting.




     m. 3480 tape cartridge statistics.

   A 3480 tape cartridge must contain at least 505 actual feet of
   magnetic tape, although there is usually 541 actual feet of tape
   on the cartridge.  The inter-record-gap IRG is 0.08 inches
   (a hardware-required space between each physical block on the tape)
   plus the equivalent of 0.009 inches of tape with overhead bytes
   for an effective IRG of 0.089 inches.  A density of 37871 was
   reported by Bill Dines and Brad Cahill at CMG.

   Some specific numbers from actual 3480 (non-IDRC) volumes show
   that at 32760 byte blocks about 6,576 blocks fit per volume (for
   215MB per volume) and that at 4096 byte blocks 30,427 blocks fit
   (for only 124MB per volume, another reason why large blocksize
   for sequential files makes real good sense).

     n. Cost of initializing MXG Trend data base

    One site initialized their MXG Trend data base with the past two
    years SMF data. Their pair of 3090-200 machines produced a weekly
    SMF tape on 11 cartridges (that's 2200MB of SMF data weekly).
    Each week's BUILDPDB plus trending required between 63 and 66
    minutes of CPU time to process the eleven tape cartridges, and
    needed only 525 cylinders (400 MB) of work space for each run.


  4. VM/XA Performance Note on DSPSLICE value.


    The default VM/XA Dispatcher Time Slice, DSPSLICE, has been 3
    milliseconds, but IBM reportedly will issue a PTF to change the
    value to 25 ms, because a heavy guest machine can monopolize the
    CPU with that small a value. Furthermore, SET SHARE does not
    work properly with the 3 ms value, because elsewhere in the
    Dispatcher it was assumed that DSPSLICE was 25 milliseconds!




  5. SAS System Technical Notes

     a. SAS technique to locate data value location in INPUT.

    This SAS technique is useful for finding the location in a record
    from which a variable is INPUT, and/or to force a hex dump of the
    data record to examine the actual hex value at that location in a
    record. This technique is especially handy if you are deep inside
    relocated sections (like in a SMF 102) record, and are not sure of
    the actual physical location of the data.  Simply change the format
    of the variable in its INPUT statement to a packed decimal format
    (eg., change OFFSQLS PIB4. to OFFSQLS PD4.).  Unless the data value
    just accidentally happens to be a valid packed decimal value, SAS
    will detect an invalid data value, print a note to that effect, and
    produce the SAS vertical hex dump of the record.  Bob Olah, Dun and
    Bradstreet reported this slick technique.

    The NOTE and hex dump of the record look like this on the SAS log:


      NOTE: INVALID DATA FOR OFFSQLS  IN LINE 53  33-36.  245:56

      RULE:     ----+----1----+----2----+----3----+----4----+----5----+
      53  CHAR  ....8.....SYSBPRD2.................<.@.................
          ZONE  0600F80828EEECDDCF000000000C05000004070000010900000A0200
          NUMR  E5088B097F2822794200000000100401000C0C010010000100100001


    The location of the data value is immediately reported in the NOTE.
    The text of the NOTE says that in the 53rd input record, OFFSQLS was
    read from bytes 33-36 of that record.  Further, the NOTE indicates
    that the INPUT statement that was executing is located at program
    line number line number 245, column 56. (You will see that line
    printed in your SAS log if you had enabled SAS options SOURCE
    SOURCE2 MACROGEN and MPRINT to cause source to print on your log.)

    The hex dump (provided automatically when invalid data is detected)
    dumps the logical record, the 53rd, providing the RULE to demark
    columns (bytes) of the record.  If the byte contains an EBCDIC
    printable character, it will be printed on the line marked CHAR,
    directly above the vertical hex ZONE and NUMERIC nybbles of each
    byte of the record.

    Eg:  - the  2nd byte is the record id, hex 65, decimal 101.
         - the 11th byte is the EBCDIC letter S, hex value 'E2'X.
         - bytes 33-36 are hex value '0000004C' (which is the decimal
             value of 76 when input into OFFSQLS as a PIB4.). Because
             '4C'x is also the EBCDIC value for the printed "less-than"
             symbol, that symbol is above the 36th byte on CHAR line.

    This hex dump of an input record can be created at any time by the
    LIST; statement.  The LIST; statement actually prints hex only if a
    print line of a record contains any non-printable characters.  If
    the entire print line (usually 100 bytes on hardcopy, 60 for
    terminals) is all printable characters, the ZONE and NUMR lines of
    the hex dump format are not printed.


     b. MXG Compatibility with SAS Version 6.06+.

    I have been working closely with SAS Institute in validating that
    MXG and SAS 6.06 will be mutually compatible when it ships this
    Spring.  While many MXG members executed without error under their
    November 6.06 Beta test, I  still found nine critical errors
    which preclude the execution of MXG under that Beta test version.
    All of these reported errors have been corrected by SAS Institute in
    the advanced beta version at the Institute.  Unfortunately, only the
    base SAS system has been tested; none of the GRAF.... member which
    invoke SAS/GRAPH could be tested.

    Very little language incompatibility has been found, but for these:

    -  VMXGVTOC END=EOF in MERGE statement had to be moved to the end of
       the statement. END= is not documented as being positional, but
       SAS 6.06 requires MERGE statement options to follow all dataset
       names.

    -  CCHHR as an option on an INFILE statement to extract the pointers
       needed to read DASD VTOCs has been used in MXG since before there
       was an MXG. When specified as an OPTION (in my definition,
       OPTIONS are switches and PARAMETERS have arguments), the CCHHR
       returns a CCHHR value in the first 5 bytes of the record, ahead
       of the first byte of the actual VTOC record. In the SAS Version 5
       documentation, the CCHHR option is not described (but it workx
       exactly as described above in SAS 5.16 and 5.18). Instead, SAS
       Version 5 documents a CCHHR=XYZ "Parameter" which returns the
       value of the CCHHR in the variable XYZ, and makes no mention of
       inserting the CCHHR into the first 5 bytes. However, Version
       5.08+ CCHHR=XYZ has never worked as described.  CCHHR=XYZ under
       Version 5 works exactly as the CCHHR option described above, and
       does put the CCHHR value in the first 5 bytes of the record!  Why
       is all this important? Because the designer of this component of
       SAS Version 6.06 based the design on the documentation and not on
       how the component actually worked. Beta Version 6.06 testing
       uncovered this incompatibility, and now BOTH the CCHHR option and
       the CCHHR=XYZ option will be supported in SAS Version 6.06, and
       both will now work as to be documented - CCHHR inserts five
       bytes, and CCHHR=XYZ doesn't!

    -  FMXGUCBL did not normalize the value returned by the function.
       SAS 5.18 accidentally handled and corrected the returned value,
       but the function was not written in compliance with SAS function
       specifications. This correction changed line 017500 from LD to
       AD, and inserted new line before that changed line:
                         SD  FR0,FR0
       It will be necessary to re-assemble FMXGUCBL before use under SAS
       6.06, but the new module will execute correctly under either SAS
       5.18 or SAS 6.06+

    -  Member FORMATS was revised write formats to SASLIB DDNAME,
       expecting an OS Partitioned Data Set (Load) Library under SAS
       5.18, or to LIBRARY DDNAME, a SAS data library, if executing
       under SAS 6.06+.  The size of the SAS 6.06+ Format Library
       appears to require SPACE=(CYL,(10,2)), with no third operand
       since it is NOT a PDS, whereas 5.18 was only
       SPACE=(CYL,(1,1,99)).
       Sep 1, 1990 addendum: Excess space required by format library was
         a problem only in 6.06 beta and was fixed in April 6.06.01. The
         SAS 6.06 format library for MXG need only be CYL,(1,1).
    -  Under SAS 6.06+, the LIBRARY DDNAME is required to point to the
       SAS Version 6 Format library, where the SAS 5.18 execution
       required the SASLIB DDNAME.

    SAS Version 6.06 is known to be the planned initial offering of SAS
    Version 6 for mainframes, and there are parts of that major SAS
    enhancements that will not be delivered by SAS Institute until the
    follow-on SAS Version 6.08 and later enhancements, but there are so
    very many new, functional, useful features of SAS Version 6, that I
    plan to begin to exploit those capabilities in future MXG versions.
    (SAS Version 6.06 can decode both $ASCII and VAXRB reversed binary
    fields. MXG support for VAX/VMS data will be in a prerelease of MXG
    Version 8 later this year and will require SAS 6.06.)

    With the separation of SAS Statistics routines into the SAS/STAT
    product, the question has been asked, does MXG require SAS/STAT?
    The answer is NO, in that MXG does not require SAS/STAT procedures
    in the creation of MXG-built SAS data sets. Some of these STAT
    routines (notable PROC GLM and PROC FASTCLUS) are used in sample
    MXG reports, and I personally would want to have this powerful suite
    of tools for data analysis at my site, but it is not a requirement
    for MXG that the site have SAS/STAT. Similarly, SAS/GRAPH, while
    recommended and used in examples, is not required by MXG Software.

     c. Timestamp trunction with incorrect LENGTH value.

    MXG variables which are SAS timestamps are all specifically made
    LENGTH 8 in length statements (all default numeric variables are
    stored in on 4 bytes to save on DASD storage requirement of MXG
    data libraries).  If you should inadvertently store an eight-byte
    timestamp value into a four-byte numeric variable, the actual
    value of the timestamp will be truncated by as much as 4.25 minutes
    (255 seconds).  The actual truncation stores the value of the
    previous modulo 255 second timestamp since the SAS epoch value.

 IV. SRM CPU parameters for MPL Control In LPAR





Sincere thanks to IBM Corporation for permission to reprint the
 following article printed originally as the Washington Systems
 Center Flash 8923 in June 1989.



            SRM CPU PARAMETERS FOR MPL CONTROL IN LPAR ENVIRONMENT

                     Richard M. Armstrong
                     Senior Marketing Support Representative
                     IBM
                     Washington Systems Center





The  SRM is designed to maintain the flow of work through an MVS system.
SRM parameters and default values are described in the Initialization
and  Tuning Guide.  Recently  some customers have experienced a
reduction in workflow for an MVS production partition in an event driven
LPAR  environment.    The  SRM function  of interest is that of holding
back additional work (more MPL) when there is enough work to keep the
CPU near 100% busy.    Additional  work  may cause other problems (such
as holding a lock) and we are not going to process more than 100% CPU
anyway.  The object is to process the right 100%.  Specifically,  the
SRM reacts to zero wait time rather than 100% utilization, so we need to
think in terms of wait time.  There are two kinds of waiting: (1) the
old fashioned kind due to issuing a WAIT (this is  now  called  a
voluntary WAIT)  and  (2)  an involuntary wait caused by the LPAR
dispatcher.  The LPAR dispatcher must allocate dispatch time to logical
processors to  achieve  the desired  distribution  of activity.   The
only wait that the SRM sees is the voluntary WAIT. In an event driven
environment  there can be  less  and  less voluntary  WAIT.  For several
customers the (voluntary) WAIT time went to zero.  This means the SRM
WAIT time is zero.  The SRM CPU utilization parameters were set to
reduce MPL under this condition.   The lower  MPL  caused  a workflow
reduction. The resulting workflow was less than the amount specified
with  the  LPAR partition WEIGHTS. We need to review the SRM parameter
values for this new environment.

This Flash discusses some relations of workload quantities with
parameters in the PARMLIB member IEAOPT. Customers may set these
parameters to values of their choice. No customer-written programs or
programming interfaces are involved.

Conclusion:  For MVS/SP2.2 and later releases an  appropriate  default
for RCCCPUP and RCCCPUT is (100+E),120, where E is the number of
engines.  These CPU MPL parameters are not a substitute for setting MIN
TMPLs (Target MPLs) and other Domain management controls properly.  They
do let you get the most out of the system, particularly in an LPAR
environment. For an MVS/SP2.1.7 or 2.1.3 environment use RCCCPUP and
RCCCPUT values of 101,101, and depend on the paging rate parameters for
restricting the MPL. This case is different because the maximum values
of these parameters are different for the earlier releases.  The
following description highlights the reasoning behind the conclusion.

Discussion:   The discussion primarily applies to MVS/SP2.2 and later
releases. The MVS/SP2.1.3 and 2.1.7 solution is a best can do subset.
There are several variables that have a vote in changing the system MPL.
Any vote to lower will cause a lowering. A vote to raise must be
unanimous. The SRM CPU utilization parameters in IEAOPT for controlling
system MPL are RCCCPUP and RCCCPUT. The SRM defaults for RCCCPUP and
RCCCPUT are (95,98) and (98,100.9), respectively. When a utilization of
100% (zero WAIT) is found, the SRM adds the in-ready queue value to the
utilization value, up to a maximum of 128.  (The maximum in MVS/SP2.1.3
and 2.1.7 is 101.) There are other variables for system MPL control that
relate to other resources. The combined effect of all these MPL control
variables (together with their MIN/MAX constants in IEAOPT) determines
if an adjustment will be made.

Unless there are other bottlenecks, getting the most work through the
system means running the CPU at 100%.  RCCCPUT is used independently
while RCCCPUP is used in conjunction with other variables. Therefore
RCCCPUT is potentially the more sensitive of the two. Each one
represents the view of the CPU and they can be treated equally.
Fundamentally, the MPL is too high if and only if the page fault rate is
too high. (Note that the page fault rate and demand page rate are
essentially the same statistically.)  While storage capacity is the main
criteria for MPL adjustment, there is no benefit to adding MPL after the
CPU is at 100% utilization.  Of course, make sure the Domain controls
cause the right ASIDs to be in storage. There can be disadvantages with
having more work in storage than can be dispatched by the CPU -- such as
holding resources.  If your system has expanded storage (ES), the
balance between central storage (CS) and ES is important as well as the
amount of total storage. The general guideline here is less than 500
pages per second per engine total traffic between CS and ES. Also if
your system has ES, a "reasonable" amount of paging to DASD is much much
smaller than what was "reasonable" before ES. With ES, the life history
of a page fault is CS to ES to CS to DASD.

While CPU utilization considerations apply to the MPL management of any
MVS system, the situation is particularly important in an event driven
(WAIT Complete = NO) LPAR environment.  In this case a production
partition with a lot of work may constantly exceed its LPAR dispatch
time and be pre-empted by the LPAR dispatcher -- rather than continue
and issue a WAIT. If the logical processors for the partition never
issue a WAIT, WAIT time goes to zero.  (The involuntary wait does not
count.) Even though the WAIT time is zero, we do not want to reduce MPL.
Reducing MPL causes the production partition to do less work. In some
cases the LPAR WEIGHTS will be designed to run several partitions with
each partition at zero WAIT (i.e., 100% busy during the dispatch time).
In the LPAR environment we need to pay special attention to what happens
as WAIT goes to zero.

As a general point of view, allow the system to reach 100% utilization
with interactive and batch workloads plus allow for one background
grinder per engine. This means we want to increase MPL if the SRM CPU
utilization is equal to or less than 101 or (100+E) where E is the
number of engines.  Then TMPL (Target MPL) would not be increased beyond
an SRM CPU utilization of 101 for a uniprocessor or (100 + E) where E is
the number of engines. Queueing theory shows that 101 is not enough. For
example, in queueing theory for exponential distributions, a single
server at 90% utilization has a queue of 9.  After reaching 101 (or
100+E), the utilization will periodically dip below this threshold
allowing MPL increases until there is enough queue to support 100%
utilization. The TMPL should not be decreased because of SRM CPU
utilization values in the immediate range above 101 or this process of
supporting 100% actual utilization will be defeated.

With the objective of running at 100% CPU (again, assuming no other
bottlenecks), the upper limit can be an SRM CPU utilization of 128.
However, there should be some CPU mechanism to lower TMPLs. Ideally, and
assuming there is enough work to saturate the CPU, we do not want the
IN-READY queue to be any larger than it needs to be to support 100% CPU
utilization. And we want to accommodate the interactive work in the
process. This means a high upper limit but less than 128. This means a
number like 120 for a heavy TSO system. The upper limit can be smaller
in a system dominated by a few ASIDs such as some CICS systems and where
there is little TSO.

Again for MVS/SP2.1.3 and 2.1.7 we do not have these choices and fall
back to the values 101,101.

  Figure:  CPU WAIT in an LPAR Environment.

  DEDICATED:

  this partition, each processor:

            ------Busy----------- ---WAIT----
              TCB+SRB     Uncapt
            ---- Dispatch time --------------
            ------ Interval -----------------
  ______________________________________________________________________

  SHARED,  WAIT Complete = YES:

  this partition, 'average processor':

            ------Busy----------- ---WAIT-- ------non-dispatch------
              TCB+SRB     Uncapt
            ------- Dispatch time ---------
            --------- Interval -------------------------------------
  ______________________________________________________________________

  SHARED,  WAIT Complete = NO:

  this partition, 'average processor':

                                  ---WAIT*----
            ------Busy----------- ----non-dispatch------
              TCB+SRB     Uncapt
            --- Dispatch time ---   <== dynamic
            ------- Interval ---------------------------

        * From initial WAIT, includes any contiguous non-dispatch time.
          Additional non-dispatch time occurs when this partition loses
          control during Busy.
  ______________________________________________________________________






------------End of reprint of IBM WSC FLASH 8923------------------------

   It had been my intention to reproduce the above figure, overlaying
   Dick's tabulation with MXG variable names from TYPE70 and TYPE70PR,
   for each bucket, but I don't have the time to verify it and still
   meet the printer's deadline for this Newsletter. Stay tuned.
****************NEWSLETTER FIFTEEN**************************************










             MXG NEWSLETTER NUMBER FIFTEEN  November 11, 1989

Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE


                         TABLE OF CONTENTS


I.   MXG SOFTWARE VERSION 7 ANNOUNCEMENTS             pages   2 thru   7

  1. Prerelease MXG 7.2 now available upon request.             page   2
  2. Production MXG VERSION 7 planned for early 1990.           page   2
  3. Summary of new products and enhancements in MXG Version 7. page   2
  4. Summary of critical changes described in Change Log.       page   3
  5. Enhancements still under development for MXG Version 7.    page   4


II.  TECHNICAL NOTES                                  pages   7 thru   9

  1. MVS/ESA changes to SMF Accounting AND RMF capture ratio.   page   7
  2. MVS SMF Type 30 Subtype 3 TCB/SRB times after 922 ABEND.   page   9
  3. MVS SMF Type 26 Time stamps after JES2 Spool Transfer.     page   9
  4. MVS execution under VM, VM/XA, or PR/SM publication.       page   9
  5. MVS SMF Type 30 interval records missing for early ASIDs.  page   9
  6. MVS SMF Type 26 record corrupted.                          page   9


III. CHANGE LOG                                       pages  10 thru  44

     Changes through Change 7.165 to 7.036


IV.  "The History of SMF"                             pages  45 thru  76

      Paper presented at the 20th anniversary
      of the Availability of the IBM SMF Product
      at SHARE 73, Orlando, August, 1989.







         COPYRIGHT (C) 1989 BY MERRILL CONSULTANTS DALLAS TEXAS

          MXG IS A REGISTERED TRADEMARK OF MERRILL CONSULTANTS
          SAS IS A REGISTERED TRADEMARK OF SAS INSTITUTE

I.   MXG SOFTWARE VERSION 7 ANNOUNCEMENTS

  1. Prerelease MXG 7.2 now available upon request.

 The Prerelease of MXG Version 7.2 is now available upon request from
 Merrill Consultants (or through your "MXG Representative" outside USA).
 Request by phone (214-351-1966) or fax (214-350-3694) if you would like
 the prerelease sent to you (at no cost).  MXG is sent on 3480 cartridge
 tape media, unless you specifically requested MXG on a 3420 tape reel.

 The Beta MXG 7.0 was installed at 130 sites, and their feedback was
 incorporated in the Beta MXG 7.1 sent to a small number of additional
 sites.  The MXG 7.2 is called a Prerelease now to indicate that it has
 been validated sufficiently to replace MXG 6.6 at sites that need its
 new product support, its enhancements or its corrections.

   (Prerelease   MXG 7.2 was created 10/19/89 thru Change 7.161).
   (Beta test of MXG 7.1 was created  9/14/89 thru Change 7.140).
   (Beta test of MXG 7.0 was created  5/31/89 thru Change 7.098).

  2. Production MXG Version 7 planned for early 1990.

 We still intend to ship the Production Version of MXG 7 in early 1990,
 probably in early February.  Unlike the prerelease, which is sent only
 if you request it, the "Production Version" of MXG is automatically
 sent to all supported sites, accompanied by an MXG Newsletter.

 See below for the enhancements that are not yet available in 7.2, but
 that should be available in the Production Version 7 when shipped.

  3. Summary of new products and enhancements in MXG Version 7.2.

 The following major enhancements are available in MXG 7.2. Details
 are in the actual Change Description (below) and documentation is
 also found in comments in the members that are cited in the change
 and in DOCVER and DOCVERnn members of the actual MXG 7.2 source.

 New Products supported:

  1. MXGTMNT, the long awaited MVS/XA or MVS/ESA MXG Tape Mount Monitor.
  2. 3490 and 9348 tape drives (cart and reel respectively) recognized.
  3. ARBITER SMF records from Tangram product.
  4. NETVIEW Release 2 Hardware/Session Monitor External Log Record.
  5. 3480/3490 Tape Compression (IDRC) recognized.
  6. JES2 mods to capture SYSOUT release timestamp in type 6 SMF record.
  7. FILEAID SMF record from COMPUWARE product.
  8. OMEGAMON Command Audit SMF record from Candle.
  9. AION Development System SMF record from AION.
 10. MDFTRACK SMF record from Amdahl MDF environment.
 11. TLMS (Tape Library Management System) catalog records.
 12. TMS (Tape Management System) catalog records.
 13. RMF Monitor III VSAM data set records.
 14. Numerous additional DB2PM-like reporting in ANALDB2R.
 15. DB2 Audit Class trace type 102 records.

 Enhancements to previously supported products:

  1. Identification of IBM RMF from Boole and Babbage RMF records.
  2. DB2 SQL text of user inquires captured.
  3. ACF2 'ARE' data sets captured.
  4. Additonal trending summaries and report examples.
  5. CPU Serials added to RMFINTRV.
  6. ROSCOE 5.6 support for variable number of complexity levels.
  7. ANALDSET enhancement to include VSAM type 64 records.
  8. VMXGVTOC enhanced to expect up to 128 extents (for VSAM).
  9. NETVIEW Release 2 Hardware Monitor External Log SMF record.
 10. NETVIEW Release 2 Session Monitor External Log SMF record.
 11. VM/XA new fields introduced by PTF VM35971.
 12. IMS 2.0 and IMS 2.1 response measurement corrections.
 13. Step accounting fields added to PDB.STEPS.
 14. New MVS/ESA CPU timings in step records.
 15. Support for DOS/VSE Power 3.1.2.
 16. Support for RACF 1.8
 17. Validation and cleanup of the Trend Data Base and related macros.
 18. Non-support of IMS 1.3 transaction processing. See Change 7.075.
 19. Validation and cleanup of all reported MXG 6.6 errors.


  4. Summary of critical changes described in  the Change Log (below).


 Critical changes (i.e., those that correct error conditions) include
 these:

  Change      Member        Description

  7.142       VMAC7072      TYPE70 CPU under PR/SM may be wrong.
  7.139       VMACSYNC      SYNCSORT record formats decoded wrong.
  7.123       VMACDB2       DB2STAT0 wrong after PL29461.
  7.115       VMACACF2      ACF2 datasets contain zero observations.
  7.108       TYPEMONI      MONITASK "OVHD" transaction record short.
  7.105       VMAC6         PSF FORM variable wrong.
  7.103       VMXG....      MWORK=28K option required for %MACROs.
  7.098       BUILDPDB      PROTECT= option considerations.
  7.083       RMFINTRV      RMFINTRV to count DASD I/O only.
  7.082       VMAC110       CICSTRAN MAXTASK/SHRTSTOR.
  7.081       VMAC7072      TYPE72MN trashed under MVS/ESA.
  7.078       VMAC77        TYPE77 trashed under MVS/ESA.
  7.076       TYPEMONI      MONISYST trashed.
  7.065       VMAC102       STOPOVER on type 102 for several subtypes
  7.054       VMAC28        STOPOVER on type 28 for subtype 5C.
  7.050       VMACVMON      Concatenated VM/Monitor wrong.
  7.047       ANALAUDT      Audit report corrections.
  7.044       VMACIDMS      IDMS 10.2 cleanup of retained values.
  7.039       VMAC22        STOPOVER on type 22 for MVS/370.
  7.038       XMAC7xxx      Circumvention for SAS Error 344.
  7.036       BUILDPDB      JPURTIME not found in some circumstances.

  (The following changes were previously reported in MXG Newsletter
   FOURTEEN and their text is printed therein):

  7.035       WEEKBLD       Implementation considerations.
  7.023       TYPEIDMJ      IDMS Journal correction.
  7.022       CMS SAS       CMS DMSSOP3633 Code 04 OPEN error.
  7.009       VMACVMXA      Concatenated VM/XA Monitor files
  7.008       BUILDPDB      JES2 Spool Transfer Purge Records
  7.007       MONTHBLD      Syntax error
  7.006       BUILDPDB      PRENTIME inadvertently in DROP list
    "         WEEKBLD       PRENTIME not in BY list
  7.005       VMAC102       DB2 Trace 102 STOPOVER on subtype 58 or 87
  7.004       VMAC28        NPM type 28 "Unexpected subtype" message
  7.003       JCLHSM        HSM included nonexistent XMXGHSM member
  7.002       VMACCIMS      IMF CPUTM calculation incomplete
  7.001       TRND...,etc.  Trend Data Base finger faults



  5. Enhancements still under development for MXG Version 7.

The following New 7.xxx (new products) and Change 7.xxx (corrections)
 are anticipated to be completed in the Production Version 7 of MXG.

New    7.xxx   MXG Version 7 will support SAS Version 6.06 (now in beta,
Unknown        expected to be available in the first half of 1990). The
XXX xx, 1989   MXG Newsletter accompanying Version 7 will discuss.

New    7.xxx   DB2 Version 2 Release 2 (DB2 2.2) is now available, but
VMACDB2        documentation has not yet arrived to permit detail look
VMAC102        at the IBM changes. It is known that new IFCIDs and new
XXX xx, 1989   fields in existing IFCIDs are created in DB2 2.2.

New    7.xxx   Landmark's TMON/MVS development is not yet started, but
unnamed        documentation and test data has been received from the
XXX xx, 1989   vendor.

New    7.xxx   EPILOG/MVS product records will be supported in the
Unnamed        Production Version.
XXX xx, 1989

New    7.xxx   HSM SMF record is partially decoded (Change 7.096) but
VMACHSM        not all segments have been decoded yet.
XXX xx, 1989

New    7.xxx   RMF Type 79 records subtypes 1 and 2 processing is not
VMAC79         completed and will not execute successfully yet.
XXX xx, 1989
   Thanks to Tom Skasa, GE Medical Systems.
   Thanks to Sterling Green, GE Capital.

New    7.xxx   In a JES3 environment, the MXGTMNT Tape Mount Monitor
Unnamed        does not create a record for the mounts issued by JES3
XXX xx, 1989   Main Device Setup, MDS. Those mounts are recorded by JES3
               in TYPE25 observations.  Further research in TYPE25 shows
               there is only one TYPE25 record per job, and it contains
               the number of mounts actually issued by JES3, but only a
               single mount duration, from MNTTIME to VERFTIME of the
               final mount completion.  This new member will combine the
               TYPETMNT (MVS Issued tape mounts) with TYPE25 extracts to
               create one observation for every actual tape mount. For
               multiple mounts by JES3, the second and subsequent mount
               observation will only count that a mount occurred at the
               MNTTIME; the duration and end of mount timestamps will be
               set missing (since you have no idea of how long it really
               took). It also deletes TYPE25 observations with TAPEMNTS
               zero (happens when UNIT=,,,DEFER is specified, no real
               mount occurs, but a type 25 is written by JES3). This
               program does not yet exits (its in telephone alpha!) and
               this change will be updated when it exists.
   Thanks to Mark Hutchinson, Atlantic States Bankcard.

Change 7.xxx   %INCLUDE SOURCLIB(IMACACCT) logic needs to be added to
VMAC26J3       control JES3-only type 26 ACCOUNT1 variable's length.
XXX xx, 1989
   Thanks to Dick Clarke, British Airways, Heathrow.

Change 7.xxx   %INCLUDE SOURCLIB(IMACACCT) logic needs to be added to
VMACIDMS       IDMS TASBFLDn accounting variables (to be renamed to
XXX xx, 1989   ACCOUNT1-ACCOUNTn, with lengths defined in IMACACCT, as
               for all other MVS accounting fields.
   Thanks to Dick Clarke, British Airways, Heathrow.

Change 7.xxx   IBM incorrectly stores values in PWCOUNT (hex values are
TYPEVM         F0F8 F0F9 F0C1 or EBCDIC 08 09 0A for actual data counts
XXX xx, 1989   of 8, 9, and 10!)  MXG will circumvent IBMs error.

Chnage 7.xxx   RMDS records have reported counts in errors for some of
TYPERMDS       the page count variables, but have not completed the
XXX xx, 1989   investigation.

Change 7.xxx   EPILOG CICS CL1000 Versions 430 and 440 support is still
TYPEEPIL       incomplete (Change 7.094). Test data and documentation
XXACEPIL       have been received from the vendor. One site has reported
XXX xx, 1989   that the offset needed to be set to -4 to process the
               Version 430 data, but I have not yet even validated that
               possibility.

Change 7.xxx   VM/370 USER Class data can have erratic large negative
VMACVMON       values because one of the two-byte IBM counters overflow
XXX xx, 1989   (typically DRPCANUS) which causes MXG to falsely think a
               LOGON event occurred. (Because IBM does not flag LOGON
               event in the USER data, MXG must attempt to infer that it
               happened.)  MXG will be revised to use only four-byte IBM
               counters in its LOGON event detection (inference engine?)

 Other products which may be added to MXG in the future that have been
  requested by users include these candidates:

   Likely to be in MXG Version 7:

      MVS/ESA 3.1.3 (hopefully to be in MXG Version 7)
      MXGMENU Selection Macro Variable definitions.

   When product becomes generally available:

      CICS 3.1
      IMS 3.1
      New Devices

   After SAS Version 6.06 is generally available on the Mainframe:

      MXGMENU Menu Architecture (needs SCL, Screen Control Language)

   Not likely in MXG Version 7:

      JES3 Jes Measurement Facility SMF type 84 record.
      VM/XA VMPRF product reports may be replicated in MXG.
      NETVIEW File Transfer Program Release 1.0 "User" SMF Record.
      FACOM PDL record processing.
      TPNS activity log.
      IMS Fastpath

II.  TECHNICAL NOTES

  1. MVS/ESA CHANGES TO SMF ACCOUNTING AND RMF CAPTURE

    a. CPU Time measurements have changed with MVS/ESA as this schematic
       (aligned vertically, but not scaled horizontally) drawing shows
       exactly what is captured where:

TYPE 70 (RMF-captured CPU measurement of real or logical CPUs):

        Elapsed Interval (Duration multiplied by number of CPUs)
     ________________________________________________________________


     ______________________________________________________ ---------
                          CPU                                  CPU
                        Executing                            Waiting


     ________ ________ _________ ________ ________ ________
      CPU 1    CPU 2    CPU 3     CPU 4    CPU 5    CPU 6
       Busy     Busy     Busy      Busy     Busy     Busy


     ______________________________________________________
     Total Hardware CPU Busy Time (from Type 70 "non-wait")


TYPE 72 (summing only the control performance group's data) contains:


     _____ _____ ------------------------------------------
      RMF   RMF                  Uncaptured
      TCB   SRB                  RMF CPU Busy
      CPU   CPU                  pre-ESA 3.1.3
                                    Busy
     ___________ _____________________________ ------------
        CPUTM       Reportedly to be            Uncaptured
      pre 3.1.3     captured in ESA 3.1.3        RMF CPU
                                                with 3.1.3



TYPE 30 (if all work started and ended in the interval) contains:



     _____ _____ _____ _____ _____ _____ _____ ------------
      SMF   SMF   SMF   SMF   SMF   SMF   SMF   Uncaptured
      TCB   SRB   TCB   SRB   IIP   RCT   HPT      SMF
      CPU   CPU   CPI   CPI   CPU   CPU   CPU      CPU

     _________________________________________
      CPUTM = Sum of all CPU times in TYPE30


       Three new CPU time durations (in addition to the existing four)
       have been added to the SMF type 30 record, which is the source of
       job accounting (and PDB.JOBS, STEPS, SMFINTRV, TYPE30_V, etc.):

       CPURCTTM - Region Control Task (Quiesce/Restore/Swap), caused
                   by this TSO user's swapping.

       CPUIIPTM - I/O Interrupt Processing (Second Level Interrupt
                   Handler, SLIH)

       and one brand new CPU measurement:

       CPUHPTTM - Hiperspace processing CPU time. HPT CPU time is NOT in
                  captured in existing CPU TCB or SRB fields. When SORT,
                  for example, begins using Hiperspace processing, the
                  TCB CPU time will be significantly reduced, because
                  function was moved from TCB to the new HPT facility.
                  DFSORT benchmarks showed examples of TCB reduced from
                  100 seconds, but that reduction required 25 seconds of
                  HPT time, so the true reduction was from 100 to 75. If
                  your billing system is using the CPUTM variable in MXG
                  (which has always contained the absolute total of ALL
                  CPU times found in the type 30 record, even though the
                  original 1984 book said it was only CPUTCBTM+CPUSRBTM)
                  you were wise and will have no immediate CPU billing
                  problems, but if you charge only for CPUTCBTM, you are
                  unwise and extremely vulernable to incorrect billing.

       Of great concern to capacity planning in the preceding  schematic
       is the absence of these three new CPU measures in the Performance
       Group measures in TYPE72 data.  These CPU measures will be in the
       RMF data for the newly announced MVS/ESA 3.1.3.

    b. Additional MVS/ESA measurement data (already in MXG 6.6) included

       TYPE 30: Step Hiperspace/Data Space Activity
                   HIPAGINS - Hiper Page Ins
                   HIPAGOUT - Hiper Page Outs
                   DSSIZHWM - Data Space High Water Mark, Megabytes
                   CREADMIS - CREADS Missed in Hiperspace
                   DIVRREAD - Address Space total Reread Count

       TYPE 72: Performance Group paging/memory measures
                   PGPAGEIN - Page Ins (from Auxiliary DASD)
                   ACTFRMTM - Frame-seconds of memory occupancy
                              while task in this performance group
                              period were "SRM Resident"; includes
                              both Central Store and Expanded Store.
                   HIPPGINS - Hiperspace Page Ins (from Aux DASD)
                   HIPRDMIS - Hiperspace Read Misses (CREADS in 30s)


    c. MVS/ESA also creates an RMF record from RMF Monitor III screens,
       in a new subtype of Type 72 records, but only a small part of
       the RMF III screen data is written to SMF. MXG's member JCLZRB
       will process the screen data in the RMF III VSAM file, but the
       TYPE72MN dataset is still valuable for a quick look, containing:

         User Statistics                      Frame Statistics

         AVGUSERS - Logged On                 MONACTV - Active Frames
         AVGACTV  - Active Users              MONIDLE - Idle Frames
         MONDUTR  - Users Out and Ready       MONDIV  - DIV Frames
         MONPAGE  - Users Delayed Paging      MONFIX  - Fixed Frames
         MONSWAP  - Users Delayed Swap        MONSLOT - Slots Used
                                              MONPGIN - Page Ins


  2. MVS SMF Type 30 Subtype 3 TCB/SRB times after 922 ABEND

 MVS SMF Type 30 Subtype 3 TCB/SRB times after 922 ABEND contain trash,
 but because first bit is on, the number is seen by IBM as a negative
 value and by MXG as a very large value (because MXG uses PIB4. instead
 of IB4. for these fields). Now, IBM zeroes the TCB/SRB fields in the
 record, with PTF UY24926. Thanks to Diane Epstein, SW Bell.

  3. MVS SMF Type 26 Time stamps after JES2 Spool Transfer.

 MVS SMF Type 26 Time stamps are wrong after reload of SYSOUT that was
 previously offloaded with JES2 Spool Transfer program. APAR OY21221.

  4. MVS execution under VM, VM/XA, or PR/SM publication.

 The MVS under VM paper formerly available to your SE under PROFS that
 was referenced in previous MXG newsletters, is now published in IBM's
 "Operating MVS/XA in Multi-Image Environments", GG24-3274-01. This pub
 has a number of additional topics. Must reading for PR/SM users as well
 well as MVS under any form of VM!

  5. MVS SMF Type 30 interval records missing for early address spaces.

 Type 30 interval records are not created on tasks which are created
 prior to the completion of SMF initialization. OZ96676 discusses this
 design "feature". You may miss records on the catalog address space, as
 it usually starts right after SMF, but before SMF has completed its own
 initialization. There appears to be no fix at present, however the PLM
 for Master Scheduler, LY28-1200-4 page 5-567 discusses why the SMF task
 must WAIT before other address spaces! We've re-opened the problem with
 IBM to see how to relocate the SMF and its WAIT ahead of Catalog ASID.

  6. MVS SMF Type 26 record corrupted.

 Type 26 JES2 records (ONLY for HJE3311 Rel C11) are invalid beginning
 in the programmer name field, causing trashed variables in TYPE26. The
 IBM fix is PTF OY21719.


III. CHANGE LOG

--------------------------Changes Log---------------------------------

 You MUST read each Change description below to determine if a Change
 will impact your installation.  You can then either make the change
 from the Change Description text, or you may wish to call Merrill at
 214-351-1966 to request the prerelease of MXG 7.2, which already has
 all of these changes installed and tested. Member CHANGES of the MXG
 SOURCLIB will always be more accurate than the printed changes in a
 Newsletter, and always identifies the MXG Version and creation date.

 Printed changes may actually be implemented more comprehensively in the
 actual MXG Software. Always read the comments at the beginning of each
 source member named under the Change Number when you receive a new
 Version of MXG. Documentation of new datasets and variables, validation
 status, notes, etc., are usually in comments in the source members.

 If you choose to install printed changes, you could copy the affected
 member(s) from MXG.SOURCLIB into your existing USERID.SOURCLIB and then
 make these changes therein. Alternatively, you can copy into a new PDS,
 MXG.CHANGLIB, to hold these in-between-version changes, concatenating
 MXG.CHANGLIB between USERID.SOURCLIB and MXG.SOURCLIB until you install
 the next MXG replacement library. Then when you do install the next
 version, you must then delete all of the members in the MXG.CHANGLIB
 (if you used that technique), or you must individually remove only the
 changed members from your USERID.SOURCLIB.  It is always wisest to
 document all of your changes in a member CHANGES in the USERID.SOURCLIB
 or MXG.CHANGLIB library.

 Whenever you install changes or test a new version of MXG (or even for
 your own reports), be extra careful to look on the SAS log for any real
 error conditions. Search for all occurrences of "ERROR:"  "ERROR :"
 "UNINITIALIZED" "NOT CATLGD", as they usually indicate a serious error.

 PROC PRINT and PROC MEANS of each new MXG-built SAS dataset will go
 a long way in explaining their contents, and can be examined to detect
 unusually large, negative, or suspicious values.

 If you are not having any problems reported herein (and many of these
 changes only correct enhancements added in 7.0 or 7.1 or for leading
 edge software), you can simply wait until the Production Version 7 is
 automatically sent to your site next February.

Completed changes:


  Change text is in member CHANGES or CHANGEnn, and not kept here to
  save space. The text was actually printed in the physical newsletter.

--------Changes thru 7.165 were printed in NEWSLETTER FIFTEEN-----------
--------Changes thru 7.035 were printed in NEWSLETTER FOURTEEN----------
          and are in member CHANGES of MXG Version 7 Library, which
          becomes member CHANGE07 in the subsequent MXG version.
------------------------------------------------------------------------
------------------------------------------------------------------------

End of Changes Log, but how's this for page filler, printed verbatim
 from an entry in IBM's INFO/SYS (SMF6CPS is COPIES in TYPE6):





                                        E343725 (HIT LIST 000003/000013)
---------------------------------------------LINES:   1 THRU   15  OF
H E343725 S=TOOLS C=GY4 D=JUL89 E=JUL91                          L=00015
TITLE:  PSF NOT UPDATING SMF6CPS FIELD IN TYPE 6 SMF
        RECORDS.
                           F   -SUGG -OY21704--5665-27-501--IN-INCORR OU

REPORTED RELEASE    R220
ERROR DESCRIPTION:
SMF6CPS IS NOT UPDATED CORRECTLY.
COMMENTS:
THIS APAR IS BEING CLOSED SUG (SUGGESTION). THE SUGGESTED
CHANGE WILL NOT BE IMPLEMENTED.
89/07/19,CHICAGO FS

$EOM


                     CME 20/20:  The History of SMF
                              Session M710
                            August 21, 1989

                       H.  W.  Barry Merrill, PhD
                          Merrill Consultants
                             Dallas, Texas
                         SHARE Installation CM4


                                ABSTRACT

SMF  became available 20 years ago with OS/360 Release 18.  SHARE's 1964
SORC report was part of the input to  IBM's  1966  SMF  design  document
(authored  by  an  IBMer who had been a SHARE board member).  The design
objective was two-fold:  the stated SHARE requirements for  control  and
evaluation  of  the  installation,  and  the  unstated  need  for IBM to
understand how its OS and its program products were  being  used  (which
and  how  much).   That  1966  design  document,  when compared with the
current SMF implementation, will be shown to be remarkably  accurate  to
the  needs  of users even today!  The presentation will also discuss the
never-announced  and  never-released  IEHMAN   report   package!    This
presentation is based on recently de-classified IBM design documents and
interviews with  the  original  designers  and  developers  of  the  SMF
product.


                                CONTENTS

         A. Jun 15, 1964 SORC Report             46-47
         B. 1964-1967 Brockish Interview Notes   48-49
         C. Aug 25, 1967 Task Force Report          50
         D. Nov  1, 1967 IBM Memo                   51
         E. Nov  1, 1966 Objectives              52-57
         F. Mar 13, 1967 Addendum I Subset 2     58-59
         G. Mar 14, 1967 Addendum II                60
         H. Jul 27, 1967 Proposal Memo              60
         I. 1967-1969 Schiffman Interview Notes  61-62
         J. Oct 16, 1968 Subset I Final             62
         K. Jan 31, 1969 Subset II Final         63-66
         L. Jun 25, 1969 Subset II Final Final      67
         M. IEHMAN                                  68
         N. Jul, 1969 Release 18                    69
         O. Oct, 1969 Release 18.6                  70
         P. Jun, 1970 Release 19                    71
         Q. Feb, 1971 Release 20                    72
         R. Aug, 1972 Release 21.6                  72
         S. 1972-1974 Merrill Notes              73-74
         T. 1975-1977 Hankison Interview            74
         U. Aug  1, 1977 Objectives                 75
         V. Author's summary                        76
         W. Contributors to this paper              76



Copyright  (C) 1989 Merrill Consultants, Dallas, Texas.  This paper will
be published in a 1989 issue of the "Technical Newsletter for  Users  of
MXG".   Permission  is  hereby  granted  to SHARE, Inc.  to publish this
presentation in SHARE  Proceedings.   Merrill  Consultants  retains  its
right to distribute copies of this presentation to whomever it chooses.

On April 7, 1964, IBM Announced OS/360. Were you computer literate then?

The  IBM  Design  of SMF Was The Direct Result Of The 1964 SHARE Systems
Objectives and Requirements  Committee  "SORC".   The  SORC  Report  was
produced only two months after OS/360 announcement!

            ------------------------------------------------
                               APPENDIX F
                        Report of SHARE Systems
                 Objectives and Requirements Committee
                             June 15, 1964
            ------------------------------------------------
                    G.E. Bryan, Chairman      L.   Cohn
                    P.A. Cramer               R.   Gillespie
                    G.H. Mealy                C.H. Weisert

"IV.  JOB ACCOUNTING AND SYSTEM PERFORMANCE MEASUREMENT

The    advent    of   multi-programmed   and   multi-processor   machine
configurations  has  re-emphasized  the  always  present  need  for  job
accounting  and  made  even  more  important  the much neglected area of
machine and program  performance  measurement.   Operating  systems  for
System/360  must  provide  as a standard feature a job accounting system
which retains records  useful  for  both  ordinary  cost  allocation  of
machine   component  time  and  measurement  of  hardware  and  software
performance.

Accounting and statistical information should be carried in the  system
on  a  job basis and identified by the following information supplied by
the submitter of the job:

1. A job number.
2. A programmer identification number.
3. An identification specific to the run.
4. Priority.
5. Other information as deemed necessary by
   the individual installation.

In addition, in order to facilitate automatic  scheduling  of  jobs  for
optimum  performance, the following should be supplied either by the job
submitter or, for "normal cases," be defined  by  installation  standard
parameters.

6. Expected execution time, cutoff time.
7. Expected output volume (lines, records, cards) by data set, with an
   installation standard limit provided in the absence  of  specifically
   supplied data.

An  installation standard factor should be applied to these numbers for
the definition of cut-off limits.  The programmer  should  have  dynamic
access  to the limits for examination and modification during execution.
In certain installations there is a need to specify 'due'  time  --  the
time  before which the job should be completed -- and 'drop' time -- the
time at which the job should be deleted if its execution  has  not  been
started."


"The system should  normally  add  to  the  job  accounting  record  the
following information:

8. Date, and beginning clock time of the run.
9. Processor identification.

It  should  also  add to the accounting record information for each task
performed in the job's execution:

10. Task Type (FORTRAN,COBOL,SYSTEM,EXECUTION,MESSAGE).
11. Mainframe time.
12. Equipment used (tapes,drums,data lines)
13. Output volumes (print lines, cards)
14. Core used for code.
15. Core used for data.
16. Operator intervention time (waiting for operator action).

At job completion time, all of the accumulated  information  should  be
summarized  and  totaled  for the user, should be added to a daily total
record, and should be output in some permanent form for later accounting
and statistical analysis.

Accounting   for  message  switching  should  be  done  using  the  same
accounting mechanism with each message transmission treated as a  single
task.   The  descriptive parameters in 1-5 are supplied by the system on
the basis of the called and calling parties.  The task type (item 10) is
"message".

Flexibility  should be included for the expansion of the kind and number
of  statistics  retained  at  installation  or  IBM   option.    Special
installation  requirements  and  special  IBM  performance  measurements
should be readily accomplised  by  addition  of  code  and/or  parameter
changes."

In June, 1966, Bob Brockish joined IBM.

Bob  had  been on the SHARE Executive Board 1963-64, and had taken Share
Systems Division job when George Mealy resigned to join IBM.   Had  been
at  Martin-Marietta  (1959)  and was now data center manager at Thiokol,
Utah.

In 1966, OS/360 SYS1.ACCT accounting consisted of only an IEFACTRT  Exit
which was taken only at Step Initiation (=8), Step Termination (=12), or
Job Termination (=16).

When the exit was taken, there were pointers provided to:

     Job Name              Step Name
     Programmer Name       Account Fields
     Job Running Time      Step Running Time
     Step Number           Cancel Bit

but the user would then have to format and write the data  to  SYS1.ACCT
using ASM code in IEFWAD.  SYS1.ACCT was supported under OS/360:

     PCP - 18K, 44K, and 100K Scheduler
     MFT - 30K and 44K Scheduler
     MVT - Scheduler

Clearly, this approach to accounting was inadequate.


Notes from my 1989 visit with Bob Brockish:
IBM'S MOTIVATION FOR DESIGNING SMF:

1. User need to account time and resource usage.

2. IBM's  need to know about how the system was being used, especially
   about which IBM Programs were used how much/often.

A "SYSOUT Project" had already been started inside IBM.  Originally  the
idea  was  to  solicit  customers  to submit their SYSOUT on tape, which
would then be analyzed after  the  fact  (for  compiler  messages,  link
editor, etc.) to count program usage!

Ken  Brownell  was  the  manager  with  one other when Bob joined group.
Bob's task was to look at OS to see how data could be collected  in  the
operating  system.   IBM  Programming  Systems  Division at Pok had just
formalized "Programming Objectives"  in  January.   SMF  was  the  first
project to comply!  Bob began to develop SMF objectives from SORC.

The  name,  System  Management  Facility,  was picked in a brainstorming
session July 6, 1966.

PROPOSED PHILOSOPHY:

IBM would provide a way to collect data, the customer must  process  and
report.   IBM  could  not  see  a general way to report on the collected
data.  Based on the SORC Report, Bob began to  define  the  data  to  be
collected.   The  initial  design  was  reviewed with the non-disclosure
signers at the Aug, 1966 SHARE in Toronto (but Bob could not  go  -  Ken
Brownell wanted to see Toronto!)

People at that August, 1966 meeting:
 Lora Steele, IBM SDD Share Liason
 Arnold Smith, IBM Overall Liason to SHARE.
 Omar Smith, Rocketdyne?
 Phil Kramer, SDC                            Bill Thunderbirkk, ?
 Roy Dickson, Okla,  Phillips Petroleum      Harvey Siegel, ?
 Joseph E. Kelly, SOCONY Mobile              Irv Lester, North American
 John Noerr, Sinclair Oil

Follow up copy of the objectives was sent to:
   Channing Jackson (SHARE)
   Earl Althoff, VP Guide
   Leroy J. Rodgers, Chair Guide COBOL project

IBM'ers also involved along the way:
 Neil Lewis - primary planner at Pok       Don Ludlow - SUPERZAP author
 Harry Reinstein                           Ira Heiney
 Hank Coon                                 Bob Levy

SMF ultimately hit 160 OS modules!

The  design  had  planned  for  "packages"  of  information, selectable,
perhaps incrementally delivered  by  IBM.   As  there  was  concern  for
potential  impact of SMF on the system, packages must allow installation
to specify only what it needed.  The first package  proposed,  presented
at   SHARE  non-disclosure  meeting  in  August,  1966,  was  the  Basic
Accounting information (Start/Stop Times).  This first package was  then
reviewed  at  Feb  1967  non-disclosure  meeting,  and Bob then gave the
presentation of the revised package.     End of interview notes.

Throughout  much  of  1967,  a  joint  SHARE/GUIDE   System   Management
Facilities  Study Group met under non-disclosure.  At the Monday May 22,
1967, meeting in New York City at the Americana Hotel included:

   Edward Boback (GUIDE) Logistics Research
   T. Todd Brown (GUIDE) Iowa State University
   Joseph C. Kelly (SHARE) Mobil Oil Corp.
   Edward G. Laski (GUIDE) Aetna Life
   John M. Noerr (SHARE) Sinclair Oil
   David R. Paul (GUIDE) Iowa State University
   Harvey Sigal (SHARE) Union Carbide

IBM:  Paul Bouche, Poughkeepsie
      Ken Brownnell, Boulder
      Arnold P. Smith, White Plains
      Don Miles
            ------------------------------------------------
               This task force reported their conclusions
                   in the August 25, 1967 SHARE SSD:
            ------------------------------------------------

"Attached is a report for SSD describing user requirements  for  systems
management   facilities   under   OS/360.    This  report  contains  the
information that was gathered by the Systems Management Facilities  Task
Force  in conjunction with GUIDE and IBM.  The Task Force is now working
on further definition and input to help provide guidance to  IBM  as  to
the  OS/360  users  requirements  for  System  Management.   Among other
things, the group would like input from users on  what  kind  of  system
management  facilities  they  are currently supporting and what level of
degradation (core, time, DASD, space, devices) they consider  acceptable
for  each  functional  feature  required  in advanced system management.
This input should be sent to both:

    C. Channing Jackson (Task Force)
    R. Cleveland (IBM Poughkeepsie)

User members of the task force included

    J.M. Noerr (SHARE, signer of report)
    E.G. Laski (GUIDE)
    C. Weisert (SHARE Sys. Division)
    J.J. Jones (OS/360 Proj.)
    J. Kelly (MCB)

A final comment on the task  force  itself.   IBM  has  appeared  quite
interested in this work and has done considerable leg work for us and we
feel  that  these  people  deserve  recognition  and  thanks  for  their
exceptional  devotion  to  getting  a  job done despite the task force's
sometimes apathetic reaction to their questions.  These people are  (all
SDD):

   Paul Bouche
   Bob Brockish
   Ken Brownell
   Don Miles
   and others to a lesser degree."


            ------------------------------------------------
              An IBM memo from Lora Steele, IBM User Group
             Liason Poughkeepsie November 1, 1967 requests
             IBM to make a commitment to announce SMF, and
             details the history of user group involvement:
            ------------------------------------------------

"There has been long and consistent pressure from user groups for IBM to
provide System Management Facilities.  It has become a ritual for  SHARE
to  request  an  IBM  presentation  on this topic every general meeting.
Although IBM has been unable to  comply  to  date,  we  should  plan  to
provide  such  a  presentation  for the SHARE and GUIDE general meetings
following IBM announcement.

The first disclosure of IBM Confidential Information relating to SMF was
made  to  user  group  officials  in  August  1966  and  consisted  of a
preliminary version of IBM's internal objectives.  These objectives were
a  result  of  considerable  effort  by  Messrs.   Ken  Brownell and Bob
Brockish  of  Boulder  to  obtain  and  organize  the  many  and  varied
requirements of user group members.

Mr.   Brownell  was assigned SDD responsibility for these objectives by
the OS Architecture and Planning management.  Messrs.   Don  Warren  and
Ward  Lambert  of  DP were present at the first IBM Confidential meeting
held in Toronto on August 2, 1966.  A revised version of the  objectives
was mailed to user group officials on January 6, 1967.

In  February  and  March,  1967  there  was  little activity.  In April,
however, a new joint SHARE/GUIDE committee was formed  to  again  review
the   user  group  requirements.   IBM's  internal  specifications  were
disclosed to the committee in order to verify that their  specifications
did  in  fact meet stated user requirements.  On September 15, 1967, the
User Group Nondisclosure Agreements for committee members expired....

If  IBM  could  make  any  kind  of  commitment  for  Systems  Mangement
Facilities  in  the near future, the user groups would be mollified.  If
dates and technical details are included in the announcement, they would
be  pleased.   If  no technical details are provided, I suspect that the
committee will be revitalized and  members  will  insist  that  they  be
allowed  to  monitor IBM's implementation phase to make certain that the
considerable user group efforts have not been wasted."


IBM's earliest SMF objectives were specified in:

            ------------------------------------------------
               From S/360-OP-001-01-Pok dtd Nov 4, 1966:
                         Programming Objectives
                             IBM System/360
                 System Management Facilities in OS/360
                        Dated:  November 1, 1966
            ------------------------------------------------
"1.1 Purpose
1.1.2 The  operating  information  has  two  primary  purposes.   First,
      information  is required to determine and equitably distribute the
      costs  associated  with  each  program's  use  of  the  equipment.
      Second,  the  installation manager requires certain information to
      evaluate the performance of his installation both  in  regards  to
      his  own  standards  as  well  as in comparison with other similar
      computer operations in order to increase the effficiency of use of
      his  current  equipment,  improve  the  service  provided  by  his
      installation and plan future equipment,  programming  systems  and
      personnel requirements.

1.1.3 The  dynamic  control  capability is required by computer center
      management to monitor the work load of the  System/360  as  it  is
      being  processed  to  verify  that  work  to  be  accomplished  is
      appropriately submitted with  proper  identifying  data  and  that
      processing is carried out in accordance with accepted installation
      practices.

1.1.5 For purposes of these objectives  the  term  "user"  refers  to  a
      computer installation manager rather than to individuals using the
      computer.  The latter are referred to as problem programs.

1.2   Scope
1.2.1 The  scope  of  a  Systems  Management  Facility encompasses four
      categories of support.

       a. Systems Management Data Set
       b. Data Collection Packages
       c. Dynamic Control Entries
       d. System Management Utilities Programs

1.2.2 The System Management Data Set is a permanently opened data set
      specifically  designed  for  the  recording  of Systems Management
      Data.

1.2.3 Data Collection Packages include the gathering and retention of
      data elements required for control, evaluation and cost allocation
      of system usage.  Items such as CPU time, storage utilization, I/O
      device allocation and software components used are  indicative  of
      the type of data required.

1.2.4 Dynamic Control Entries allow the user timely assurance of
      efficient  systems  utilization  by transferring control to a user
      routine at appropriate times and places.  These  Entries  transfer
      control  to  user supplied coding which performs specific auditing
      functions unique to each user."

"3.1.1 The required data elements are stratified into five packages as
      follows:

       1. Basic Job Data
       2. Basic Step Data
       3. Additional Job and Step Data
       4. Periodic Job and Step Data
       5. Sampled System Data

3.1.2 Package 1. Basic Job Data.

       1. Job Log Number
       2. //JOB Statement after validation
       3. Entry Time of Day
       4. Exit Time of Day
       5. Effective Priority
       6. Output Quantities - Sysout Lines/cards
       7. Job Time
       8. Job Termination Status

      Two messages to be added to SYSOUT:
        Sign on
        Sign off

3.1.3 Package 2.  Basic Step Data.

       1. //EXEC Statement after validation
       2. Step Time
       3. Unit Addresses by Type of Device
       4. Output Quantities (Lines/Cards)
       5. Input Quantity (Card images only)
       6. Step Log Number
       7. Step Termination Status

      One message to be added to SYSOUT:
       Step Termination, Program, Time, etc.

3.1.4 Package 3. Additional Job and Step Data

      Additional  data elements for use in performing more sophisticated
      costing and in managing data libraries.

       1. Job Log Number
       2. SYSIN Reader Identification
       3. Reader/Intrepreter Time
       4. SYSOUT Writer Class
       5. Output/Writer Time

      Additional per step data

       6. Kept Data Set Identification
       7. Deleted Data Set Identification
       8. Created Private Data Volume Id (Released Private Data Volume
          ID may be supported via Data Set Accounting)
       9. Actual Maximum Core Used (Not the Region Parameter)."

"3.1.5 Package 4. Periodic Job and Step Data

      Includes  those  additional   items   which   are   required   for
      configuration planning, software evaluation and system performance
      appraisal.

       1. Job Input Queue Time
       2. Job Output Queue Time

      Additional per step data

       3. Step Start Time
       4. Program Time
       5. Data Set Descriptions
       6. DD Statements
       7. Number of Devices Used by type/step
       8. Device Use Time by Type
       9. Rolled Out Time
      10. Storage Rolled Out
      11. Number of Roll Outs.

      Controlled by Operator Command.

3.1.6 Package 5. Sampled System Data

      Provides the elements necessary to develop a  statistical  profile
      of an installation's system use characteristics.  After the option
      is exercises at system generation time this set of  data  elements
      is  collected  on  a  time  based  sampling  interval  (delta  t).
      Whenever delta t  is  satisfied  the  data  will  be  recorded  on
      SYS1.MAN.

       1. Time of day
       2. Total Memory in Use
       3. Number of Active Jobs
       4. Number of Passive Jobs
       5. Number of Devices in Use by type/chan
       6. Number of Readers in Use.
       7. Systems Work space in Use
       8. Work Input Queue Lengths
       9. Work Output Queue Lengths
      10. Channel Queue Lengths
      11. Seek Queue Lengths
      12. Number of Active Tasks
      13. Timer Queue Length
      14. Number of Writers in Use"

"3.2 Systems Management Data Set

3.2.4 Systems Management Data will be recorded sequentially on SYS1.MAN
      as  the  data is acquired.  This method of collecting will require
      the following considerations.

      1.  SYS1.MAN data may have to be sorted by  Log  Number  prior  to
          input to analysis programs.

      2.  Each dumping of SYS1.MAN will be an incomplete segment of the
          Systems Management Data Set.

      3.  A complete Systems Management Data Set contains  all  segments
          collected  between  an  IPL  and the subsequent "drying up" of
          the system.

      4.  In the event of an abnormal  system  termination  contents  of
          SYS1.MAN shall be preserved. "



3.4 Dynamic Control Provisions.

3.4.1 Dynamic Control facilitiesj shall be provided in the form of
      entries to a user routine taken at ....


3.4.2 JOB, STEP, and DD CONTROL CARD VALIDATION ENTRY ....

3.4.3 JOB INITIATION ENTRY ....

3.4.4 STEP INITIATION ENTRY ....

3.4.5 STEP TERMINATION ENTRY ....

3.4.6 JOB TERMINATION ENTRY ....

3.4.7 TIME LIMIT ENTRY ....

3.4.8 OUTPUT LIMIT ENTRY .... "

"3.6 Systems Management Utility Programs

Two  Types  of  utility  programs  required  in conjunction with Systems
Management Facilities are analysis programs and a list program.

3.6.1 Systems Management Analysis Programs

      The purpose of these utility programs is to produce reports  based
      upon  data contained in the SYS1.MAN data set.  These reports will
      provide management with the information  necessary  to  understand
      system usage and plan future improvements.

      The  analysis  programs  will yield information that describes the
      workload and system utilization from several points of view.

      One class of information should  pertain  to  the  overall  system
      usage  and status independent of particular programs or job types.
      Such information constitutes a "System Profile".

      The "Job Stream Profile" on the other hand should describe  system
      utilization   in   terms  of  the  characteristics  of  the  input
      workload."

      A further classification of  information  should  provide  a  "Job
      Profile"  devoted to revealing the nature of both the workload and
      systems utilization in terms of the characteristics of  individual
      job types.

      At  the lowest level of detail, a "Job Step Profile" describes the
      charateristics of individual job steps and their  contribution  to
      systems resources utilization.

3.6.2 System Management List Programs

      In  addition  to the programs to analyse System Management Data, a
      utility  program  for  listing  System  Management  Data  Sets  is
      required.   The utility's function is to provide a printout of raw
      Systems Management Data in either its natural order or in Job/Step
      Log  Number  sequence.  Operating under OS/360 this utility uses a
      input either a disk or tape dump of a SYS1.MAN data set.  It shall
      have  the  ability  to concatenate multiple SYS1.MAN data sets and
      print out a composite listing.   Information  from  the  data  set
      labels will be printed at the beginning of the listing."

"4. Performance Objectives

4.1 The ultimate purpose for Systems Management Facilities is to supply
      information  from  which  installation  management  can  know  and
      improve  computing  systems  performance.   Through   the   proper
      utilization  of  good  systems management data the user can reduce
      operating costs.  On this basis users  are  willing  to  sacrifice
      some  amount  of  performance for the ability to gather this data.
      The system performance  degradation  however,  cannot  exceed  the
      reasonable  value  of  the  facilities.   To guide in implementing
      System Management Facilities in OS/360 the  following  performance
      objectives are set forth.

4.2 There is to be no performance degredation when none of the Systems
      Management Facilities are employed."

4.3 The performance of the operating system should not be degraded more
      than  3%  when the SYS1.MAN data set, Dynamic Control Entries, and
      Packages 1, 2, and 3 are activated.  In addition,  the  collection
      of  data in Package 4 should not decrease performance more than 4%
      during those periods when it is active.  Package 4 should cause no
      degradation  when it has been selected at system generation but is
      not in use.  Since the collection of Package 5  is  based  on  the
      value  of  a time interval.  measurement of its performance should
      be aimed at a time per sample basis.  Each occurrence of  sampling
      of  Package  5  data  should  not require more than 500ms on a 360
      Model 50."

4.4 These performance objectives for OS/360 are summarized below:


    Facility Enabled              Timing Target          Additional core
                                                         Requirements,
                                                         Maximum Bytes

    none                              0                      0

    SYS1.MAN +Dynamic Control     200ms/Job                256 + 128/Job

    Package 1                     500ms/Job               1024

    Package 2                     250ms/Step               512

    Package 3                     250ms/Job                512
                                 +250ms/Step
                                 +250ms/Data Set

    Package 4                     200ms/Job               1024
                                 +300ms/Step
                                 +500ms/Data Set

    Package 5                     500ms/Sample            1024

      Based on jobs averaging 3.5 min and containing an average of 3 job
      steps each having 5 data sets.

      Based  on  CPU  Model  50H with 2311 disk for system, SYS1.MAN and
      SYSOUT residence."



               Four months later, SMF Subset 2 was specified:

               ------------------------------------------------
                       Externally dated April 18, 1967
                                  Addendum I
                            S/360-OP-0001-02-Bldr
                            Programming Objectives
                           IBM Operating System/360
                  Data Set Management & DA Space Accounting
                      Dated Internally:  March 13, 1967
               ------------------------------------------------

"This addendum extends the scope of the System Management Facilities  to
supply the user with the tools required to manage data set libraries and
to control and account for space usage on direct  access  devices.   The
facilities  to furnish this capability include the recording of data set
records on SYS1.MAN and a utility  routine  to  retrieve  the  data  set
records,  put  them  in  a  data set management file, produce a data set
inventory and maintain the data set management file.

New data will be recorded when Package 3 is selected:"

A. NEW, Non-temporary Data Sets

   1. Identify as NEW
   2. Data Set Name (including GOOOVOO)
   3. Creation Date
   4. Expiration Date
   5. Device Type
   6. Number of Volumes
   7. Volume Serial Numbers
   8. Public or Private
   9. Shared or Exclusive
  10. Number of accesses to read
  11. Number of accesses to write

     for direct access              for tape

  12. File organization       Data set sequence Nr
  13. Amount of space         Type of labels
  14. Unit of Space           Recording density
  15. Number of extents       7 or 9 track recording

B. OLD Data sets - similar to NEW

C. Temporary Data Sets

   1. Identify as Temporary
   2. Device Type
   3. Number of temporary data sets
   4. Total number of volumes involved
   5. Total number of accesses/records.
   6. Total amount of space in bytes"

                And then, amazingly, Subset 2 described the:

"IV. Data Set Management Utility

The Data Set Management Utility is intended to run daily or periodically
as  required  by  the  installation  to provide information to guide the
operations staff in purging the data set library  and  to  maintain  the
circulation of data volumes.

A. Functions of the Routine
  1. Extract data set records  from concatenated SYS1.MAN dumps and use
     them  to  build  and  maintain  the Data Set Management File.  This
     Utility does not physically remove data set records from  the  Data
     Set Management file on this basis.  Instead it "deletes" by setting
     a flag and inserting a deletion data  in  the  appropriate  record.
     Actual  removal  of  data set entries will be made via punched card
     input after the information has been used for billing, etc., by the
     user.

  2. Produce a report by device type and volume serial number of data
     sets whose expiration date has elapsed.  This listing includes Data
     Set Name, Programmer's  Name,  Accounting  Fields,  Creation  Date,
     Expiration Date, Date Last Written and Date Last Read."

  3. Produce data set inventory report by device type showing activity.
     This  listing includes Data Set Name, Programmer's Name, Accounting
     Fields, etc....

  4. Accept, as input, punched cards with deletions and changes to data
     set records in the Data Set Management File.  These cards  will  be
     prepared  by  the  user's  data  librarian  and input into the file
     maintenance  run.   Through  these  cards,  data  set  entries  can
     actually  be  removed  from  the  file and revisions can be made to
     accounting fields, responsible programmer's name, etc.

  5. Provide exits for user supplied coding to perform other functions
     desired by the installation."


                     Addendum II was dated a day later:

              ------------------------------------------------
                            S/360-OP-0001-03-Bldr
                           Programming Objectives
                          IBM Operating System/360
                             Job and Step Timing
                              Space Accounting
                      Internally Dated:  March 14, 1967
              ------------------------------------------------

"This addendum replaces "Job Time" in the  original  specification  with
"Job CPU Time", and adds a new element:

      7b. Job Unoverlapped I/O Time

Job  Unoverlapped I/O Time is the accumulation of time during which both
of the following conditions are satisfied:

  a) input and/or output activities are being carried on by or for a job

  b) and that job is not using the central processing unit.

Job CPU Time plus Job Unoverlapped Time equals  the  time  a  job  would
require if it was the sole inhabitant of the computer system.  It is the
summation of these two time measurements that ...   should  be  compared
with when determining if the job is exceeding its maximum running time."






            ------------------------------------------------
               Dated 7/27/67 is a Proposal for Extensions
                               to OS/360
            ------------------------------------------------

  Proposing:

   - Maintenance of the DA Volume Inventory
   - A New Volume Reorganization Utility
   - A New PDS reorg-needed status message
   - A New PDS reorganization utility!

It appears this document was not accepted, but it contains a tantalizing
bit of data:

"3. Market Requirements

 3.1  The problem of DA space deterioration potentially affects each of
      the   estimated  550  installations  using  OS  as  their  primary
      operating system.  Also to be considered are the  additional  1596
      forecasted future users of the system."


       550+1596 = 2146 Future OS Customers!!!

Initial specifications were completed in Summer, 1967 and SMF  moved  to
Poughkeepsie  (Pok)  for  implementation  under Saul S.  Schiffman, with
Lynn Weisenreider in his group.  Notes from 89 Saul Schiffman interview:

Biggest implementation difficulties:

  to convince Supervisor in IOS to put in lines  of  code  in  Operating
  System - they were very conservative on instructions in path.

  Testing together to see that it worked was new, OS was the first large
  scale software project.

  Had to firmly make rules how to access SMF.  Some developers  did  not
  want user records - could garbage up the collection, but they lost.

  MANX/MANY had to be handled by the system

  Very hard at the beginning, everybody had their own ideas.

  "Hundreds" of pieces of information.

  Rule:  Unless you can show me how you will use it, I won't add it.

  That reduced hundreds to 30-40 items.

  Complaint  of expected SMF overhead of 5% was answered by jury rigging
  SYS1.ACCT for all of the same data.  Discovered that it too  took  5%,
  and showed in-line capture no worse than exits.

  This  convinced  IBM that measurement could be an integral part of the
  operating system, and also showed that SMF data was not optional  -  a
  site simply could not run without this data.

  Was the customer Measurement or Accounting?

   Accountants - look at this data
   Performance Measurement - look at that data

   Picked common ground between the two.


  Made  attempt to convince users to use only the repeatable fields, and
  make data more repeatable - MFT easier than MVT.

  Wanted one project for billing and  for  measurement  and  evaluation.
  When  conflicts  arose,  measurement  &  evaluation  guys  gave  up on
  additional data fields.

  Accounting - some things are outside of control (eg  paging)  -  could
  not  predict  branching  impact,  thus cannot charge for it.  Began to
  look at counting from application.

  IBM could not answer "How do you account?"

    "We were not going to write accounting and
     billing routines at IBM.

     Instead, we will document and provide data"


SMF Implementation began at the start of 1968.  PCP, Fortran, MFT I, MFT
II  development  were  at Kingston, while MVT, IOS, SVS, MVM were all at
Poughkeepsie.  MVM (Multiple Virtual Memories) became MVS.

SMF Implementation Options now considered:

  1. Have a program in the system dynamically sample and adjust the
     system based on the actual measurements.

    - heuristic approach
    - radical (remember, this WAS 1968!)
    - major proponent of this option was
      Bart Page -"Brain behind the SRM.
                  Mind beyond others.
                  Ahead of his time, but
                  Not a good salesman."

  or, what we actually ended up with:

  2. Extension of traditional SMF design
       Not much on analysis
       Minimal reporting

  End of 1989 Interview notes.





On October 16, 1968, Saul's group distributed their Final Specifications
on Subset 1:
            ------------------------------------------------
                System Management Facilities (Subset 1)
              Final Functional Programming Specifications
                                 (MVT)
                         OS/360-OS-0043-05-POK
            ------------------------------------------------

Unfortunately,  I  have  not  see a copy of that document.  Based on the
final implementation,  however,  Subset  1  created  the  following  SMF
records:

  Type  0 - IPL Record
  Type  1 - Wait Time Record
  Type  2 - Dump Header Record
  Type  3 - Dump Trailer Record
  Type  4 - Step Termination Record
  Type  5 - Job Termination Record
  Type  6 - Output Writer Record
  Type  7 - Data Lost
  Type  8 - I/O Configuration
  Type  9 - VARY ONLINE Record
  Type 10 - Allocation Recovery Record
  Type 11 - VARY OFFLINE Record
  Type 12 - End-of-Day Record


              Earlier, on February 7, 1968 there had been:

            ------------------------------------------------
                 Data Set Management and D.  A.  Space
                       Accounting (SMF Subset 2)
                     Initial Programming Functional
                             Specifications
                          S/360-OS-0068-00-POK
            ------------------------------------------------

which I have not seen either.  However, in January 31, 1969, the "Final"
for Subset 2 was published:



            ------------------------------------------------
                          S/360-OS-1010-00-Pok
              Final Programming Functional Specifications
                               IBM OS/360
                  Data Set Management and D.A.  Space
                         Accounting (Subset 2)
                        Dated January 31, 1969.
            ------------------------------------------------

This identified the new SMF records that would be added by (Subset 2):

"2.1.4.2 Record Types

  Type 14 & 15 - Non-Temporary User Data Set

  Type 16      - Temporary User Data Set

  Type 17 & 18 - Data Set Status SCRATCH/RENAME

  Type 19      - Direct Access Volume Dismount

  Type 20      - Job Commencement"

This  "Final"  Document  also  described  three  new  specifications  in
significant detail:

  Direct Access Inventory

  Tape Inventory

  Resource Management Utility


Highlights from this IBM analysis package description then go on:

"2.1.5 The Resource Management Utility

The Resource Management Utility collects volume and data set information
from  the  SMF  data set.  This consolidated data is available in report
form.  The main functions of the utility are as follows:

A.  It uses volume and data set information from the  SMF  data  set  to
create  and  update  records  in  the inventory data sets.  There is one
inventory for direct access resources and one for tape.

B.  From volume information in the  inventories  it  produces  a  volume
inventory report and SCRATCH volume reports.

C.   From data set information in the inventory it produces a variety of
data set reports.  The data  set  inventory  records  are  selected  and
arranged   according  to  such  parameters  as  data  set  name,  volume
indentification, account number, expiration date and last usage date.

D.  It creates control cards for IEHPROGM to  SCRATCH  data  sets  which
have expired.

E.   It  creates  control  cards  for the Resource Management Utility to
REMOVE data set inventory records from the  inventories  for  data  sets
which have been SCRATCHed or DELETEd."

"F.   It accepts control cards to remove volume and data set information
from the inventories.

G.  It can compress the inventories.

Each inventory is a partitioned data set (PDS).  Each directory entry in
the PDS reflects  a  particular  volume.   The  member  itself  contains
information about data sets on that volume.

This was followed  by  twelve  pages  identifying  each  field  in  each
inventory record and its source SMF record (5,14,15,17,18,19, or 20)."

and then the JCL:

"2.1.5.6 Job Control Language and Control Statements Used by the Utility

The Resource Management Utility can be  invoked  by  the  following  job
control language


//jobname  JOB   positional parameters and
                  keywords
//stepname EXEC  PGM=utility name
//SYSPRINT DD    parameters describing
                  SYSOUT device
//SYSDATIN DD    parameters describing direct
                  access inventory PDS
//SYSTAINV DD    parameters describing tape
                  inventory PDS
//SYSMAN   DD    parameters describing the
                  SMF data set
//SYSREPRT DD    parameters describing report
                  device
//SYSPUNCH DD    parameters describing punch
                  data set
//SYSIN    DD    parameters describing control
                  statement data set "


"The  control  statement  data set (described on the SYSIN DD statement)
contains one or more of the following operations:

  A. UPDATE
  B. REPORT
  C. REMOVE
  D. COMPRESS"

Then followed twelve pages  detail  the  syntax  and  use  of  the  many
operands for each operation.

The  sixteen  error messages produced by the Resource Managment Utility,
IEH901E through IEH916I are then documented, and give the first clue  as
to  the planned name for the Resource Management Utility program name of

                                IEHMAN!




"2.3.2.2 Resource Management Utility Requirements

The utility program is designed to be in  a  planned  overlay  structure
with  a  minimum  of  15K  required for executable code at one time.  In
addition, core storage is required for buffers.   The  number  of  bytes
needed for buffers is device dependent.  Maximum buffer sizes (in bytes)
are shown in the table below:

   Device     Type       Maximum buffer size

    2301      Drum              21,000
    2302      Drum               5,400
    2303      Drum               5,300
    2311      Disk               4,000
    2314      Disk               7,900
    2321      Data Cell          2,400"

And even a performance evaluation of the utility:

"The direct access inventory has entries for ten volumes, each with nine
extensions, giving a total of 100 members in the directory.  Each member
is 3500 bytes long and contains 15 data set inventory records, giving  a
total of 1500 data set entries.

An UPDATE is estimated to take 9 seconds.

A  REPORT VOLID operation, which produces a list of direct access volume
inventory information is estimated to take 1 second.

A REPORT DS operation, which produces an unordered list of all data sets
on  the printer, is estimated to take 82 seconds.  Further time would be
required to produce a sorted list.

A prototype of the utility was coded and  tested  in  several  different
versions.   MVTTRACE  was  used  to  obtain timings of the final version
described below.

SYS1.MAN data set resided on a 9-track 2400 tape drive, model 3, and was
recorded  at  800  bpi.   The  direct access inventory resided on a 2311
device with a member blocksize of 3200 bytes.  The printer  was  a  1403
device  with  120  print  positions.  The CPU was a model 50, the system
MVT, Release 14."

"The first UPDATE run  required  12.2  minutes.   This  initialized  the
inventory data sets.

A.   The  input  stream  from  SYS1.MAN  contained the following records
arranged as if coming from an MVT environment:

    60 job commencement              (type 20)
    60 job termination               (type 5)
  1500 old non-temporary             (type 14)
  1500 new non-temporary             (type 15)
    60 temporary                     (type 16)
    60 SCRATCH                       (type 17)
    20 RENAME                        (type 18)
    80 direct access volume dismount (type 19)

The resulting direct access inventory contained information  about  1862
data  sets,  of  which  39 had been SCRATCHed.  There were 197 directory
names in the directory, of which 148  were  base  members  and  49  were
extension members.  The average number of data sets per volume was 12.6.
The average length of data set inventory records was 208 bytes.

B.  The second UPDATE required 19.7 minutes."

In a separate section of the Final Specification the error  expectations
of SMF were predicted:

"6.4.2.1 APAR records for IEBPRTPCH, a utility program estimated to be
         of a  similar size (13,000 bytes) were used to project expected
         errors and severity.

6.4.2.3 All Severity 1 errors should be resolved before integration.
        Only two OS utility  programs  have  ever  received  Severity  1
        APAR's after release.

 and the accompanying table showed

                         After Customer Ship
 Expected:                6 months   18 months

 Severity 2, 3, 4 errors     7          15
 Man hours to correct       40          40
 Machine hours to correct    5           5"



                     And then along came the Final "Final":

                 ---------------------------------------------
                              S/360-OS-1010-01-Pok
                  Final Programming Functional Specifications
                            IBM Operating System/360
                      Data Set Management and D.A.  Space
                             Accounting (Subset 2)
                        Internally Dated June 25, 1969.
                 ---------------------------------------------

This  document  was much thinner than its predecessor, and states on its
cover letter:


"This revision of the referenced specification contains modifications in
the following major areas.

1. The Resource Management Utility program description has been deleted.


          THUS DIED SMF Reporting.

This  final  specification  also  eliminated the type 16 (temporary data
set) by redesigning the type 14 and 15 records to what we now have.

In addition, design specifications that have departed from  the  initial
specifications were identified:

"1.3.2  From  Initial  Specifications:  These specifications depart from
the Objectives and Initial Specifications in the following respects:

 a. No I/O device timing will be performed.

 c. The TCT of Subset 1 will be expanded to include information
    previously  intended  for a new control block (the IOCT).  This will
    eliminate the need to modify the DEB."

The final error table was now modified

"                             After Customer Ship
 Expected:                  6 months       18 months

Severity 2, 3, 4 errors     5 (was 7)      20 (was 15)
Man hours required          4 (was 40)     10 (was 40)
Machine hours required      4 (was 5)      10 (was 5)"





                 "Systems Management Utility - IEHMAN"

The  IEHMAN  Planning  Guide  describes  the  same  features  that  were
specified  in  the  SMF  design  for  Subset  2,  called  the  "Resource
Management Utility"!

Not  only did the IEHMAN Planning Guide exist within IBM, but through an
error,  a  small  number  of   copies   were   actually   shipped   from
Mechanicsburg, Pa., to some IBM customer sites!

Once the error was discovered, IBM immediately recalled all copies!

Ken Plambeck was the author of the IEHMAN package.

The project had 10-12 people 12 hrs/day, but the product was killed when
the manager could not get sponsors.

Even though IEHMAN was never announced nor ever released, it showed that
IBM  designers,  even  in  1966-1967,  knew that analysis tools would be
needed to exploit the SMF data.



              ------------------------------------------------
                In May, 1969, C28-6712-0, Planning for System
                 Mangement Facilities (62 pages) described
                the version of SMF planned for Release 18.
              ------------------------------------------------
               but the real announcement of availability was:
              ------------------------------------------------
                      IBM System 360/Operating System
                              Release 18 Guide
                                GC28-6718-1
                                 July, 1969
              ------------------------------------------------

"System Management Facilities

    SMF is a new feature of the operating system, selectable  at  system
    generation  in  conjunction with the MVT configuration.  SMF may not
    be specified in conjunction with Model 65 Multiprocessing.

SMF provides two basic functions:

  Collecting and recording system-, job-, and step-related data for each
  job processed by the system.

  Monitoring  job  processing  via  exits  from  the  control program to
  installation-provided  routines  at   specific   points   during   the
  processing of each job."

Data  Collection:  SMF writes 13 types of records to a data set resident
on either tape or direct access.  The records contain  such  information
as:   system  configuration,  job  and job step identification, CPU wait
time, CPU usage by each job and job step, and I/O device usage and  main
storage  usage  by  each  job  step.   The writing of SMF records may be
supressed at IPL.  An  installation-provided  routine  can  periodically
analyze  the SMF dataset to evaluate system efficiency, performance, and
usage.

Job Monitoring:  SMF provides five exits within the control  program  to
installation routines:

  From  the  reader/interpreter  of the job just before each job control
  statement is interpreted.

  From the initiator/terminator when a job is selected for initiation.

  From the initiator/terminator when a step is selected for  initiation.

  From the intiator/terminator when a step and/or job is terminated.

  From the timer second level interruption handler (SLIH) if a specified
  CPU or wait time limit for a job or step is exceeded."

  If no wait time limit is specified, the default value provided by  IBM
  is 15 minutes;  in previous releases the default value was 30 minutes.


A new macro instruction (SMFWTM) may be used in exit routines  to  write
records to the SMF data set.  A test procedure (TESTEXIT) is provided in
SYS1.SAMPLIB to facilitate routine testing.

You must also provide analysis and report routines to  process  the  SMF
data set."


            ------------------------------------------------
                    IBM System/360 Operating System
                         Consolidated Document
                               Release 18
                              GY28-6681-2
                     Third Edition (October, 1969)
            ------------------------------------------------

"Updated Version of Release 18, designated as Release 18.6, may  now  be
ordered from PID.

Approximately 40 PTFs have been applied to the  distribution  libraries,
correcting more than 80 APARs.

(Release 18.0 text:)

A second release of SMF will support MFT, M65 Multiprocessing and Remote
Job Entry.

Graphics Job Processing (originally planned for the  second  release  of
SMF) is supported in this initial release of SMF.

Primary Control Program (PCP) and Conversational Remote Job Entry (CRJE)
are not supported.

Performance

If SMF is chosen at System Generation, performance will be reduced.

The performance reduction will be dependent upon the installation's  use
of the following:

   . SMF buffer size
   . Device used for the SMF data set
   . SMF data set allocation size
   . Number of jobs run per day
   . Execution time of the installation exits

The  performance  reduction  to  the  system  when all System Management
Facilities are functioning can be less than 5%.

Storage Requirements

A fixed amount of main storage is required when SMF is chosen at  System
Generation.   In  MVT  a  maximum  of  1500  bytes  is added to the main
resident storage.  Supervisor Queue Space is used  for  data  collection
tables,  new  job  queue  entries, and the user defined SMF buffer.  The
variable storage depends on the number of active jobs in the system  and
the SMF options chosen."


            ------------------------------------------------
                   IBM System/360 Operating System:
                            Release 19 Guide
                              GC28-6733-1
                               June 1970
            ------------------------------------------------

Announced  Subset  2 of SMF and support for MFT and M65 Multiprogramming
and RJE with all  twenty-one  SMF  records  (0-15,17-20)  with  one  new
record,

  Type 13 - MFT Partitions

and one new Exit

 (IEFUSO) for SYSOUT data set limit exceeded






            ------------------------------------------------
                  System Programming Guide Release 19
            ------------------------------------------------

"Example of SYS1.MANX Space Requirements
                                  ID    bytes
 1  IPL per day                    0
20  Devices online              8,19
 2  Vary Onlines per Hour          9
 2  Vary Offlines per Hour        11
 1  Device Allocation per Hour    10
 1  Scratch Dataset per 4 Hours   17
 1  Rename Dataset per 4 Hours    18
24  Accumulated Wait Time          1
        Total for these records           2,025
Job Processing
 1  Start of Job                  20
 1  End of Job                     5
 1  Dismount 2 Volumes per job    19
 3  Steps per job                  4
Step Processing
 3  DD statements per step         4
 2  Input datasets per step       14
 2  Output datasets per step      15
 2  Output writers per step        6
 Total for one job                        6,303
 Total for 48 jobs in 4 hours           302,688
SMF headers
  Record Descriptor Words                 5,044
  Block Descriptor Words                  1,684

TOTAL SMF DATA FOR 4 HOURS:             311,411"

            ------------------------------------------------
                   IBM System/360 Operating System:
                            Release 20 Guide
                              GC28-6730-0
                              January 1971
            ------------------------------------------------

Announced 20.0 with support for S/360 and new S/370 155 processor (S/370
165 in April) and indicates to expect 20.6 in 6-8 months.

            ------------------------------------------------
                    IBM System/360 Operating System
                      System Management Facilities
                              GC28-6712-4
                    (Fourth Edition, February 1971)
            ------------------------------------------------

Applied to Release 20.1  and  identifies  the  eleven  new  SMF  records
created with Release 20 (now totaling 31 record types):

 Type 21 - ESV Record
 Type 30 - Start TSO Record
 Type 31 - TIOC Initialization Record
 Type 32 - Driver Record
 Type 33 - Driver Modify Record
 Type 34 - TSO Step Termination
 Type 35 - TSO Logoff Record
 Type 38 - Initial TSO Configuration Record
 Type 40 - Dynamic Allocation Record (not documented!)
 Type 41 - Modify TSO Record
 Type 42 - Stop TSO Record





            ------------------------------------------------
                   IBM System/360 Operating System:
                            Release 21 Guide
                              GC28-6730-2
                       March, 1972 (Release 21.0)
            ------------------------------------------------

Announced  the  REC parameter and minor change in format of SMF records,
and indicated that 21.6 would be along in 4-6 months.

            ------------------------------------------------
                   IBM System/360 Operating System:
                            Release 21 Guide
                              GC28-6730-04
                      August, 1972 (Release 21.6)
            ------------------------------------------------

was announced, with no SMF enhancements.

In October, 1972, I first used the Statistical Analysis System, SAS,  to
read  SMF  records from OS/360 Release 20.6 at State Farm Insurance.  At
that time, SAS cost $100!  By early  1973,  I  reported  our  successful
results  to  user groups (SAM, TESDATA) and ACM (SIGSIM, Chicago).  John
Chapman demanded that I present at SHARE.

In March, 1974 (SHARE XLII, Houston), in the CME  project,  I  presented
SMF/SAS;  CME scheduled an open session for the Chicago SHARE.

That summer, IBM announced  SGP,  their  Statistics  Gathering  Package,
written  by  Bill Tetzloff.  The open session at the August, 1974, SHARE
meeting in Chicago began with Bill's SGP product description followed by
State  Farm  Auto's presentation of their use of SAS and SMF data.  Over
750 people (half of SHARE attendance) were present!  While SGP was truly
a valiant IBM effort to provide reporting from an extract of a fixed set
of SMF fields, it was not easily tailored, was  cast  in  concrete,  and
appeared  inflexible.   This  audience then saw the SAS language for the
first time, and saw SAS actually used for productive SMF  analysis.   At
the  end, one attendee pointedly asked IBM, "Now that you have seen SAS,
is there any reason why we should still consider SGP?"


This discovery that the SAS language was highly suited for  analysis  of
SMF  and  RMF data led to many SHARE sessions that demonstrated that SMF
data  analysis  really  did  save  money  and   answered   data   center
management's questions (response, capacity, service objectives, etc.).
SAS was the tool that made SMF analysis practical, in 1974.



The early releases of MVS became available:

 VS/2   Announced August 1972

 ?/73?  MVS 2.2 MF-1 Type 70-77,79
 ?/75?  MVS 3.0
 5/76   MVS 3.7
 8/76   SU7 Supervisor 2
 8/76   SU20 RMF
 9/76   SU11 TSO CMD. Package
 9/76   SU13 TSO/VTAM
 3/78   SU58 TSO/VTAM Level 2
 3/78   SU50 MVS SE1 (for 3.7)
 7/78   SU78 TSO Session Manager Rel. 2
 3/79   SU65 MVS SE1.1 (for 3.7)
 3/79   MVS 3.8 (SCP2)
 8/79   SU74 MVS SE2 (for 3.8)
         Type 23, 30, 32, 90
 1/85   NPDA V3 R2 (Type 37)
 2/85   DFSORT R7 (Type 16)
 3/85   NLDM R3 370 (Type 39)
 7/86   DB2 (Type 100,101,102)


By the mid 1970s, large TSO shops (several hundred concurrent logged  on
users) began noting degredation due to the BSAM SMF writer:

 - ENQ/DEQ was used by all SMF records, a very slow, serialized server
           for every logical record written.

 - TCLOSE  to update VTOC after every block was written moved the disk
           drive arm - the drive shook like a washing machine!

 - WRITE VERIFY doubled the I/O time

In  addition,  the 1975 SHARE-IBM meeting in New York was called because
users were  not  migrating  from  MVT  to  MVS,  and  were  blaming  SMF
accounting  issues, technical issues about actual numbers in the records
(eg., more absolute CPU time, the loss of  "storage  measurement"  a  la
"K-Core  Hours"  from  MVT,  the  inclusion  of PCI counts into SMF EXCP
buckets) caused, Ron Hankison,  then IBM  Representative  to  SHARE  MVS
Group, to become the local SMF expert within IBM.



From Ron Hankison 1989 interview:

Accounting  requirements  from SHARE and GUIDE had built up, and nothing
had changed since the original OS implementation (VS 2.2 and VS 1.6  had
only added a few fields regarding paging and Virtual storage).

TCLOSE  was  out of control, the constraint was apparent and there was a
backlog of user requirements.

Project goals were to:

   Fix the performance constraint
   Add functionality
   Restructure after 5-10 years experience

Estimated project by doubling the then-known size of SMF  (Source  Lines
of  Code)  and  used  that  (and  IBM internal estimates) for the actual
estimated man-hours.

The final implementation took  four  times  as  much  as  the  estimate,
requiring 12 people 1.5 to 2 years for SE2 SMF Writer redesign.

Because  no  one  else in VS 2 cared much about SMF, the development was
independent, which allowed many things to be considered and many went in
and out of the final SMF enhancements.

Primary developers were:

   Barb Butler
   Bill McTiernan
   Steve Rosengarn
   Joe Winterton


            ------------------------------------------------
                       Programming Objectives and
              Initial Programming Functional Specifications
                        MVS Accounting Facility
                             August 1, 1977
            ------------------------------------------------

"1.4 Summary of Specifications

The  rewrite  of SMF will resolve the numerous, known problems with SMF.
The  performance  of  SMF  will  be  much improved by the elimination of
bottlenecks during the collection and writing of the  data.   Additional
data  will  be  available  for  recording  that  fills  in several known
exposures for resource utilization and system  activities.   Flexibility
will  be built in that allows the installation improved control over the
recording and make tradeoffs between the integrity of the data collected
and   the  performance  impact.   Complexity  will  be  reduced  by  the
capability of establishing a common file to contain  all  the  pertinent
information  needed  to  manage the installation.  Additional useability
items will make this package very appealing to DP installations."

1.5 Summary of RAS Characteristics

Due to the critical nature of the data  being  handled,  minimizing  the
opssibility  of  loss  of  data  will  be stressed in the design of this
package.  The improvements described in this document will be covered by
either  an FRR or ESTAE routine to ensure that loss of data is held to a
minimum in the event of  a  failure  in  the  SMF  component.   Optional
facilities  will  be  provided  to  minimize  loss of data due to system
failures.  Programming techniques known to  have  demonstrated  improved
quality will be used during implementation and test."

2. User Requirements Addressed
       Started Task Reporting
       Interval Reporting
       Performance/Overhead of Data Collection
       Recording Selectivity
       Proliferation of Data and Records
       Installation Tracking Completeness
       Accounting Direction
       Proliferation of Tools

7. Performance

The  overall  reduction of SMF overhead and its impact on system thruput
will be significant in those environments that have  a  high  volume  of
data  that  is  recorded  to  SMF.   The  performance improvement of the
collection routine and its branch entry capability will provide  a  much
improved  interface for those components that should be recording to SMF
but were concerned about the SMF bottlenecks.

The path length for a Write to the SMF data set is approximately  60,000
instructions.  The frequency of that event is installation dependent but
probably averages about once every 13 logical  records.   The  size  and
frequency  of  record  receipts  will be increasing rapidly as processor
speeds increase.  The revised path length by using the VSAM ICIP in  SRB
mode  is  approximately  2500  instructions, resulting in a reduction of
57,500 instructions per Write."


       Summary of the author's opinions:

1. SHARE was instrumental in the creation of SMF.

2. Users had a fair idea of what data was needed.

3.  IBM designers in 1966 knew more than users of the range of data that
we would ultimately need.

4.   The  iterative process between IBM designers and IBM users provided
realistic validation of the design before implementation.

5.  Designer's specifications and wants exceeded the  funding  and  time
for implementation.

6.   The  1966-1969  IBM  design  and  implementation process was better
structured, managed, and documented  than  your  company's  most  recent
managed software project in 1989.

7.   Based  on this example of IBM design practices of twenty years ago,
imagine the detail we would find in today's IBM design documents!

8.  SMF made IBM pre-eminent in the business of real data processing  by
giving  DP  management  actual  measures  of  the resource usage and the
service (response) for each user.  DP could then "manage by  objectives"
and  prove  to  the  president  the  value  and costs of the services DP
provided the company.  No other vendor  of  hardware  and  software  has
provided the accurate measurements that IBM has given its customers.

9. As good as it is, it still isn't perfect:

   MVS/ESA added three important CPU measures to
   the type 30 (task level) record,
       RCT  - Region Control Task CPU
       SLIH - Second Level Interrupt Handler CPU
       HPT  - Hiperspace CPU
   but we do not have these same CPU measures
   in the type 72 (performance group) record.

   SHARE REQUIREMENT, ANY ONE?



Contributors:

With  sincere thanks for the dedicated developers designers and users of
SMF data, I especially salute these contributors to this research:

 Bob Brockish, (retired) IBM         Tom Bell, Rivendel Consultants
 Lynn Weissenreider, IBM Boulder     Brian Currah, BDC Computer Services
 Saul Schiffman, IBM Japan           Aron Eisenpress, CUNY
 Ron Hankison, IBM Kingston          Mario Morino, Morino Associates
 Dick Armstrong, IBM Gaithersburg
 Jim Doyle, IBM Poughkeepsie
 Jack Higgins, IBM Publications

especially  for   their   treasure-trove   of   original   IBM   project
documentation   as  well  as  their  time  in  reminiscing  on  personal
remembrances.

****************NEWSLETTER FOURTEEN*************************************










             MXG NEWSLETTER NUMBER FOURTEEN  April 1, 1989

Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE



I.   MXG SOFTWARE VERSION 6.6 "CRITICAL CHANGES"                 page  2



II.  ENHANCEMENTS TO MXG WHICH ARE UNDER CONSIDERATION:          page  2



III. CHANGE LOG                                        pages  3 thru  14

     Changes through Change 7.035 to 7.001



IV.  "MVS Performance Management Legends"             pages L1 thru L-26

    This outstanding article by Steve Sampson is full
    of good information about MVS, and especially
    about the history of MVS measurement. We are
    pleased to be able to share his work with you.
    Thanks too to Candle Corporation for permission.








         COPYRIGHT (C) 1989 BY MERRILL CONSULTANTS DALLAS TEXAS

          MXG IS A REGISTERED TRADEMARK OF MERRILL CONSULTANTS



I.  MXG SOFTWARE VERSION 6.6 "CRITICAL CHANGES".

  MXG Version 6.6, shipped Jan 21, 1989, has several errors which may
  require your immediate attention.  At the beginning of the Change Log
  section of this newsletter are listed the known "Critical Changes".
  YOU MUST READ THAT SECTION IMMEDIATELY.

  MXG IMS log processing (TYPEIMS) has been in production at a number of
  sites with no problems, yet other users have definitely encountered a
  host of problems, and have provided us with their fixes. We are still
  validating their discoveries (which are too extensive to distribute in
  this newsletter).  We know that IMS 1.3 data is not correctly handled
  by MXG 6.6, and it appears that some variables are missing and some
  time stamps are wrong for some transactions in IMS systems which have
  Wait-For-Input and similar environments.  Transaction counts and the
  CPU and DL/I resources seem to be always correct, but response time
  measurements are occasionally wrong, LTERM is sometimes blank, etc.
  We will provide these IMS fixes when validated via a pre-release of
  MXG that will be available (only upon request) in second quarter 1989.
  If you use TYPEIMS for log processing, write us, call (214-351-1966),
  fax (214-350-3694), (or overseas contact your local SAS office), and
  request to be placed on the "IMS FIX LIST".



II.  ENHANCEMENTS TO MXG WHICH ARE UNDER CONSIDERATION:


  JES3 Jes Measurement Facility SMF type 84 record.

  VM/XA VMPRF product reports may be replicated in MXG.

  NETVIEW File Transfer Program Release 1.0 "User" SMF Record.

  RMF type 79 SMF record (subtypes 1 and 2 at least).

  TMS Catalog full support (upgrade XMACUCC1 to TYPEUCC1).

  TLMS Catalog support.


--------------------------Changes Log----------------------------------

   You MUST read each Change description below to determine if a Change
   will impact your installation. For each impacting change, you should
   also read any comments in the beginning of the source members that
   are listed under the change number. Notes, comments, and last minute
   documentation are sometimes found in comments in the source members.

--------------------------------------------------------------------

 Critical changes (i.e., those that avoid error conditions) are marked
 by  FIX:  following the discussion.   If you use the member listed in
 a critical change, you must install the FIX.

  The following changes are critical:

  Change      Member        Description
  7.035       IMAC30IO      PDB.JOBS numeric variables wrong.
  7.009       VMACVMXA      Concatenated VM/XA Monitor files
  7.008       BUILDPDB      JES2 Spool Transfer Purge Records
  7.007       MONTHBLD      Syntax error
  7.006       BUILDPDB      PRENTIME inadvertently in DROP list
    "         WEEKBLD       PRENTIME not in BY list
  7.005       VMAC102       DB2 Trace 102 STOPOVER on subtype 58 or 87
  7.004       VMAC28        NPM type 28 "Unexpected subtype" message
  7.003       JCLHSM        HSM included nonexistent XMXGHSM member
  7.002       VMACCIMS      IMF CPUTM calculation incomplete
  7.001       TRND...,etc.  Trend Data Base finger faults

 You can make these changes directly in the MXG.SOURCLIB library.

 Alternatively, you may wish to create a new MXG.CHANGLIB library to
 hold any changes distributed (as are these) in printed form. You would
 store the changed members in MXG.CHANGLIB (which would be concatenated
 between your MXG.USERID library and our MXG.SOURCLIB library) until
 you receive a replacement version of MXG, at which time you must then
 delete all members in the MXG.CHANGLIB library.



****************NEWSLETTER THIRTEEN*************************************














             MXG NEWSLETTER NUMBER THIRTEEN  JAN 20, 1989

Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE

 This Newsletter accompanies the production shipment of MXG Version 6.6.

I.  MXG SOFTWARE VERSION 6.6

    1. The thirty-seven major enhancements in MXG Version 6.     page  2
    2. Installation instructions.                                page  3
    3. Compatibility considerations.                             page  4
    4. Documentation.                                            page  5

II. ADMINISTRATIVE ANNOUNCEMENTS

    1. "CPE Reporting System" tape to be sent to you by SAS.     page  6
    2. MXG Software default media.                               page  6
    3. MXG Newsletters are now "online".                         page  6
    4. 1989 Planning.                                            page  7

III.TECHNICAL NOTES

    1. HOT PTFs: MVS                                             page  8
    2. HOT PTFs: VM                                              page  8
    3. Technical Notes, IBM                                      page  8
    4. Technical Notes, MVS                                      page  9
    5. Technical Notes, VM                                       page 12
    6. Technical Notes, SAS                                      page 15

IV. Change log.                                                  page 16

     Changes through Change 6.206 - 6.058                   thru page 46



         COPYRIGHT (C) 1989 BY MERRILL CONSULTANTS DALLAS TEXAS

          MXG IS A REGISTERED TRADEMARK OF MERRILL CONSULTANTS



I.  MXG SOFTWARE VERSION 6.6

The Production release of MXG Version 6 is MXG 6.6, January 15, 1989.
The library is at Change 6.206, and MXG 6.6 produces 552 datasets with
18048 variables from its 911 members, and creates 151 SASLIB formats.

 1. The major enhancements in MXG Version 6.

 a. Support for the documented MVS/ESA changes in SMF and RMF records.
    SMF changes include JESNR changes in SMF 6, 26, and 30 records now
    that up to 99999 JES numbers are allowed.  This caused several
    changes in SMF data.  The change was needed by IBM because lots of
    sites found the 9999 job limit was eaten up by jobs left on spool!
    The old 4-byte JESNR field will be zero and the JESNR will be in the
    JCTJOBID field instead, which could affect your installation's JES
    mods, if they used the old 4-byte JESNR instead of JCTJOBID.  The
    MVS/ESA support includes RMF 3.5, RMF 4.1.0 and RMF 4.1.1 changes.
 b. Support for PR/SM changes to TYPE70 CPU measures.  First,there is a
    new TYPE70PR data set created by MVS 2.2's partition which describes
    the processor utilization of all partitions (not just this MVS
    2.2).  Second, the TYPE70 CPU busy now uses the PDT partition
    dispatch time to correct the MVS CPUBUSY and CPUWAIT variables.
    (PR/SM puts zeroes in the old CPUWAIT field and stores partition
    busy time in a new data segment). Third, read IBM's disclaimers in
    the RMF User's Guide on what is and is not measured. Fourth, under
    PR/SM you cannot know the actual hardware CPU busy of individual CPU
    engines, but do get the overall activity of all engines. (If you
    have Vector Processors this could be a problem, since you will no
    longer know CPUBUSY for the CPU engine to which the VP is attached.)
 c. VM/XA SP1 and SP2 Monitor support and reports (35 reports so far).
    See extensive discussion below under Technical Notes, VM.
 d. Support for DB2 Version 1 type 102 trace data records. Many DB2
    reports similar in format to DB2PM are now produced by ANALDB2R.
 e. Support for NPM 1.3 new type 28 SMF record. This record replaces the
    type 38 (NPA/NPM), type 39 (NLDM) and VSAM VTAM Session statistics
    (MXG's XNPMSESS) data sources. Twenty eight data sets are created
    from TYPE28, all now start with NPM..... and a number of variable
    names were changed. Member VMAC28 cross-references these changes for
    your reports.  Support includes Network Gateway Accounting too!!!
 f. IMS log record processing was completely re-written (in MXG 6.4) to
    capture individual transaction response, even for Message Switches
    WFI (Wait for Input) programs. Prior MXG logic captured only program
    schedule events (07 record), like IBM's DFSILTA0 utility. Separate
    responses are measured for each transaction event, and TYPEIMS now
    supports the IMS 2.2 log record format changes made by IBM.
 g. Support for IDMS-R 10.2.1 Performance Monitor SMF records.
 h. Support for IMF Version 2.5 has been added.
 i. Support for NETSPY Release 3.1.
 j. Support for EPILOG 1000 (CICS) Release 4.30.
 k. VM/SP Release 4 and 5 Monitor validation corrections were made and
    enhanced summary reports match VM MAP numbers better.
 l. Goal Systems EXPLORE/VM records are now supported.
 m. VPS (a SYSOUT handler) support in TYPE6 data set.
 n. EXD (a SYSOUT handler) support in TYPE6 data set.

 o. CA-DISPATCH (a SYSOUT handler) support in TYPE6 data set.
 p. $AVRS (a SYSOUT handler) support in TYPESAVR data set.
 q. Landmark Version 7.1 support.
 r. CICS 1.7 UOWTIME variable decoded for the (undocumented) third data
    format for both CMF and Landmark records.
 s. Building MONTHLY PDBs using only one tape drive now always works.
 t. Support for RMDS Release 3.0 SMF record.
 u. ASMVMCOPY (assembly source) and REXXCOPY (an exec) permits a VM/SP
    site to "dump" their VM/Monitor spool records to a CMS file. Without
    this program, you either used VM MAPs MONTAPE/MONDISK command or you
    used the SAS MONITOR INFILE exit to "dump" the VM/SP Monitor data.
 v. Support for AIM database manager records from FUJITSU's FACOM OS.
 w. Support for type 1, 127, and 234 records from FACOM OSIV/F4.
 x. Support for SAS user SMF record (PROC/DATA step resources).
 y. Support for CA-ROSCOE Release 5.6
 z. Support for 3990-3 Cache DASD RMF Reporter (user) SMF records.
aa. Support for Duquesne's DASDMON SMF record.
bb. IDMS 10.2 exits 05 and 13 ASM code for TYPE200-203 MXG datasets.
cc. Support for Duquesne's TPX Session Manager SMF record.
dd. Support for SQL/DS VM/Account records.
ee. Support for STC 4400 Tape Silo SMF record.
ff. Support for HSM data records.
gg. Support for COM-PLETE SMF records.
hh. VSAM DASD measurement with ASMVVDS program to read VVDS and
    create SMF data record for DASD management and chargeback.
ii. MXG Newsletters online in member NEWSLTRS.
ii. Initial implementation of the "fabled" MXG Trend Data Base
    with examples of CICS, RMF, etc. weekly/monthly/etc trending.

  All reported 5.5 problems have been fixed in this release.

  See the Change log and read the comments in the  referenced  MXG
  source member for complete details of these enhancements and changes.


 2. Installation instructions.

  Installation instructions are in Chapter 32 of the MXG Supplement.
  (which are also contained in member INSTALL of the source library.)
  However, since those instructions were written, MXG has expanded!
  The SASLIB MXG format library must be re-allocated with the SPACE
  parameter of CYL(1,1,99), because there are now 151 formats in this
  library, and the original MXG Guide showed only 10 directory blocks!
  The MXG formats are then created in the SASLIB PDS by the first step
  of JCLTEST, which executes a PROC FORMAT. Unfortunately, if there is
  not enough directory space, PROC FORMAT only prints a cryptic message
  ("STOW FAILURE") on the SAS log, and does not set a return code. You
  will discover the actual error only later when you get SAS error 170
  FORMAT NOT FOUND, when you run an MXG job that now needs one of the
  MXG formats expected in SASLIB!  (Actually, only 26 directory blocks
  are currently required, but why not plan for the future with 99!)

  Similarly, the allocation for SOURCLIB needs to be increased to the
  present recommendation of CYL,(25,5,199) with the DCB parameter set
  to RECFM=FB,LRECL=80,BLKSIZE=23440, (with 130 directory blocks used).

 3. Compatibility considerations.

  This library is a complete replacement for the Version 5.5 (or prior)
  MXG.SOURCLIB data set. It is forward and backward compatible with all
  data sources (eg., it still processes MVS/370 as well as new MVS/ESA
  changed records.)  The sooner you install it, the less likely you are
  encounter an error condition which is fixed in this Version!

  These are the known exposures which you must protect when you install
  this (or any) new version of MXG. (Users report it takes a half-day.)

  First, there MUST be no VMAC.... members left in your USERID. library
  when you install a new MXG version. Since MXG uses %INCLUDE to pickup
  its macro definitions, if you have a VMAC.... member in your library
  concatenated ahead of MXG, you will not pickup the new MXG macro and
  instead will execute a (probably modified) macro from a prior version
  of MXG.  In the past, some leading edge sites found it necessary to
  make "emergency" changes to a VMAC.... member and had copied it into
  their USERID library.  Those VMAC.... members in your USERID.SOURCLIB
  library MUST be removed when the new version of MXG is installed.
  YOU SHOULD NEVER EVER HAVE TO MODIFY A VMAC.... MEMBER TO TAILOR MXG
  TO YOUR SITE. The IMAC.... & EX...... members are designed to allow
  ALL installation tailoring to be external to the VMAC.... members.
  See the MXG supplement pages 134ff or call for help, but please avoid
  storing VMAC.... members in your USERID.SOURCLIB library.

  Second, BUILDPDB and BUILDPD3 must not be in your USERID.SOURCLIB, for
  the same reasons as the VMACs. MXG Supplement pages 137ff show how you
  can add new data sets or change their contents with the EXPDB... and
  IMACKEEP exits.

  Third, we create an unavoidable compatibility exposure to your MXG
  system whenever we change an IMAC.... member that you have already
  modified into your USERID.SOURCLIB library.  YOU MUST compare the
  following list of changed IMAC.... members with the members of your
  USERID.SOURCLIB, and if the member exists in your library, you must
  retro-fit your tailoring into a copy of our new IMAC.... member. The
  change number(s) describing what we changed, as well as comments in
  each member itself, should aid in your tailoring.


        IMACs in MXG 5.5              Read Change Number
        that were changed

          IMACACCT                       6.131
          IMACCICS                       6.148
          IMACEPIL                       6.091, 6.013
          IMACICDL                       6.044
          IMACIMS                        6.116, 6.053
          IMACMONI                       6.096
          IMACPDB                        6.129, 6.105
          IMACRMDS                       6.042
          IMACSHFT                       6.206


        IMACs new in prerelease       Read Change Number
        that were changed.

          IMACDB2T                       6.103, 6.079
          IMACEXD                        6.084, 6.037
          IMAC102                        6.201

        IMAC that might need          Read Change Number
       to be changes by you

           IMACKEEP                       6.148

        New IMAC which should         Read Change Number
         be noted for impact.

          IMAC30IO                       6.129

  You could see more observations in TYPE74 with MXG 6.6 than with 5.5.
  Observations are now output only for non-zero values of the SIOCOUNT,
  PCTDVUSE, or MOUNT variables; prior versions did not test MOUNT. The
  addition of MOUNT captures tape devices which had mount pending but
  no other activity during an RMF interval.

  VM/XA processing now requires a new FILEDEF/DDNAME of INSTREAM, a
  3-track temporary file, into which MXG creates SAS code which is
  then %INCLUDEd to create the look-up table of device attributes for
  VXIODDEV and related data sets from VXMTRDEV. The INSTREAM DD is
  referenced only during building the VXIODDEV data set(s).


 4. Documentation.

  It was hoped that the Chapter FORTY style documentation of each of the
  new data sets and their variables would be available coincident with
  MXG 6.6.  However, the choice was made to ship the software now and to
  send the documentation as a (very large!) Newsletter later this year.

  Member DOCVER06 alphabetically lists all NEW data sets and all NEW
  variables which did not exist in MXG Version 5.5.  Member DOCVER is a
  complete list of ALL variables in ALL data sets built by Version 6.
  Both members give the complete label, which is usually adequate for
  initial use of the data.  Since in most cases the field names of the
  data source are used as the MXG variable names, the vendor's manuals
  should not be overlooked for additional descriptions.  Best of all,
  build the new data sets with the TYPE.... member for a day's data, and
  then PROC PRINT the first 50 observations, examining what values your
  installation's data creates. PROC MEANS and PROC FREQ can also be very
  useful tools in understanding the range of values and the frequency of
  occurrence of the new data.

  Finally, use member CHANGES to find all of the member names that are
  associated with a change of interest, and then examine each listed
  member for comments at the beginning of the member.  Most of the new
  data sets are initially described in their VMAC.... member, and the
  associated IMAC.... may also contain specific comments on how to set
  up MXG to process a particular data.  When none of this helps, call!



II. ADMINISTRATIVE ANNOUNCEMENTS


1. "CPE Reporting System" tape to be sent to you by SAS Institute.

  The CPE Reporting System (originally called the CPE Starter Set)  is
  a SAS/AF  application which has been available free upon request from
  SAS Institute.  It was developed (primarily by  Allan  Russell, SAS
  Technical Manager of SAS Institute's European subsidiary) in
  Heidelberg.

  SAS/AF  gives  end  users  (for  example,  your  manager) the ability
  to analyze, select, plot, and to apply the power of the SAS System  to
  SAS data  sets  through  a  series  of  screens  and  menus which
  require no knowledge of the SAS language.

  The CPE Reporting System is both an example of how to use SAS/AF  and
  a fine  set  of  hourly, daily, and weekly reports of interest to
  managers and CPE technicians alike.  It contains  a  tutorial  on  its
  use,  and generates  a wide range of reports from the MXG data sets
  built from MVS (PDB.IPLS,  PDB.JOBS,  PDB.STEPS,  and  PDB.RMFINTRV).
  It  is   easily extended to provide SAS/AF services for the analysis
  of any data.

  We  are  providing  SAS Institute with our mailing list of supported
  MXG sites, and shortly after you receive MXG Version 6.6 from us in
  Dallas, you will receive your free copy of the CPE Reporting System
  directly from the SAS Institute (or from your local SAS office).


2. MXG Software default media.

  We announced our intention to change tape media default from 3420s to
  3480s in Newsletter TWELVE, and included a return postcard if your
  site could not accept 3480 cartridges, since the vast majority of USA
  sites do have 3480s. However, at the request of our overseas offices,
  we will continue to ship 3420 mini-reels to overseas sites, and will
  send 3480 cartridges overseas only to sites who so request. The MXG
  default media for the USA and Canada will remain 3480s.


3. MXG Newsletters are now "online".

  The new member NEWSLTRS now contains the text of this and all prior
  Newsletters.  Not only will this (hopefully) eliminate your requests
  for multiple printed copies of our Newsletters, but also it permits
  you to BROWSE and search for technical information by computer!  The
  change log portion of each newsletter has always been contained in the
  members CHANGEnn for prior MXG version nn, and in member CHANGES for
  the current MXG version.



4. 1989 Planing.

   a. The 3-day CPE class taught by Dr. Merrill will be offered in the
      USA in February (preceding SHARE in Los Angeles), in October at
      SAS in Cary, and in December (preceding CMG in Reno). SAS Cary
      makes the arrangements for these courses.  The course will also
      taught in Paris in July (the 200th anniversary of Bastile Day!)
      and also in England in late July.  An Australian class is also
      being planned adjacent to CMGA in September in Melbourne.

  b. Things that did not get completed in time for Version 6:
    - VM/SP Release 6 Shared File System Account Record.
    - IMS Fastpath log record analysis.
    - Tape mount monitor for MVS/XA.
    - Chapter 40-style documentation for everything new.

  c. MXGMENU - a statement of direction.

  MXGMENU will be the interactive facility for the installation and
  tailoring of MXG, for report selection and generation, and for the
  management of the MXG environment.  MXGMENU will be delivered after
  SAS Institute releases a full function mainframe Version 6 of the SAS
  System, probably in 1990.  MXGMENU will take as its starting the
  previously described "CPE Reporting System".   MXGMENU will execute
  PROC DISPLAY and will not require the site to have SAS/AF, but may
  well motivate its acquisition.  MXGMENU will exclusively use Version
  6 SAS/AF features and Screen Contorl Language, and will execute on
  the mainframe or the microframe.

  For reporting, MXGMENU will publish and use a standard set of macro
  names as tokens for selection and control, such as for Dates, Times,
  Shifts, Jobnames, Transaction Names, User names, etc.  Unlike the
  present "CPE Reporting System", which carries most of its reporting
  code inside the SAS/AF catalog, all of the report code used by the
  MXGMENU will be in the MXG Source library.  This will allow reports
  to be produced directly in batch, TSO, or CMS, or from the MXGMENU.
  (Standardization of MXG report tokens will also make it easier for
  users to share and contribute reports!)

  For installation tailoring, MXGMENU will interactively interrogate
  the installer and then create appropriate definitions in IMAC....
  members in the user's tailoring USERID.SOURCLIB library to override
  MXG defaults.  For example, you will be able to specify "MVS/ESA"
  and thereby create only MVS/ESA (or only MVS/370, etc.) relevant
  variables in MXG data sets. MXGMENU will also set up the sources
  and summary levels of the data to be kept in the MXG Trend Database.

  MXGMENU will be a free, intrinsic component of MXG Software.



III. TECHNICAL NOTES


1. HOT PTFs: MVS

MVS:
   OY13794   NPM type 28 data invalid.
   OY01945   SMF Buffer errors causing IEE979W message and data loss.
   OY12066   SMF Buffer errors corrected. On 8805.
   OZ97236   ACTJTIME only 3-byte storage for step CPU, can wrap if task
              uses lots of CPU (this is an old problem, still unfixed).
   OY06621   Type 41 JOB, PTF UY22185, UY20659, may need SYSGEN.
   OY09186   VIO paging into ESTORE (RMF 3.5 and later).
   OY15663   TYPE 64 VSAM EXCP counts are now accurate for shared VSAM.

CICS:
   PL20996   CICS Clock gets ahead of MVS clock!


2. HOT PTFs: VM

VM:
   VM27244   TAPPDS fails with virtual storage error message DMSTPD105S.
   VM35321   VM/XA Monitor Scheduler record needs CPU address in record.


3. Technical Notes: IBM

  The IBM Internal document titled "RMF Accuracy and Capacity Assessment
  Under VM/XA" is currently available to your IBM SE thru PROFS under
  the VM/XA SP Forum, but is supposed to become a real publication
  soon.  It is the best discussion of what happens to RMF data when you
  execute MVS under VM I have ever read. It was written by Robert Youngs
  of the IBM UK Chiswick Center.

  The MVS/ESA SMF Manual is a new publication, GC28-1819-0. The EXCP
  counting is clarified somewhat in Chapter 8, but it still fails to
  discuss connect time measurements. Also, Chapter 9 expands CPU timing
  discussion to include Vector Facility timing and adds more reasons why
  CPU-time measures may vary from run-to-run.


4. Technical Notes: MVS

  a. VSAM EXCP counting.
  In October 1988, APAR OY15663 became available, which corrected the
  VSAM EXCP counting problem in TYPE 64 SMF records. The following is
  the problem corrected by that APAR, and thus will no longer be true.
  The EXCPS variable in TYPE64 contains the change in EXCPs since the
  VSAM file was opened by this job, but (some, none, all) of the change
  may not be caused by this job. If the same VSAM file is concurrently
  opened by four jobs that issue 9000 EXCPs each, their four type 64
  records contain 9000, 18000, 27000 and 36000 EXCPS respectively, even
  though 9000 EXCPs are properly recorded in the type 30 step data. It
  does not even appear possible to write a de-accumulation algorithm for
  type 64 records that will always be correct, and the counting problem
  for multiple-opened VSAM files applies to the other variables (INSERTS
  DELETES, etc.) which are calculated from changes in catalog counts.
  Again, the preceding problem is eliminated with APAR OY15663.

  b. DB2 Account data.
  DB2 Account data sometimes contains a 0 value for beginning CPU time
  and 23:59 hh:mm for the EJST ending CPU time when a plan abends, which
  results in a large "measured" CPU time. Two sites have noted this flaw
  but it has not been repeatable enough to get IBM attention.

  c. NETVIEW 2.1.
  NETVIEW 2.1 created type 39 (NLDM RTM data) records will have missing
  data unless LOG=YES, SAW=YES, SETSTATS=YES (even though documentation
  says NO) are specified in AAUPRMLP member of NETVIEW library.

  d. ACTFRMTM in TYPE72.
  The new TYPE72 variable ACTFRMTM, Active Frame Time is the number of
  page-seconds of pages of Central Store (CS) and Expanded Store (ES)
  that were owned by resident tasks in each performance group period.
  The new TYPE72 variable PGPAGEIN, Pageins for this perfgrp period, can
  be directly compared with Storage Isolation parameter PWSS which
  controls the sum of CS and ES frames.  The number of ES pages owned by
  a performance group can be estimated by comparing ACTFRMTM (CS+ES)
  with PAGESECS (CS only, calculated from MSOUNITS). However at the task
  level in type 30, we can only get the count of CS pages from MSOUNITS.
  In summary, type 72 contains CS and ES pages, type 30 has CS only.

  e. IO Counting in TYPE70.
  I had previously noted that IO's counted in TYPE70 are higher than the
  count of IO's in TYPE78IO, but did not know why. LY17-5550 explains
  the difference (typically 12-14% higher in TYPE70) is because the 70
  counts SSCH's and Resumes (like 78), but the 70 includes PCI counts,
  Device End following Channel End, and Unsolicited Interrupts.


  f. CICS 1.7 EXCLUDE option.
  One CICS 1.7 CICS Monitor Facility (type 110 data) user reported that
  he tried to EXCLUDE ALL followed by INCLUDE specific transaction data
  fields, but the unexpected result was that not only were CICSTRAN data
  fields excluded, but also CICSYSTM global fields were also excluded
  (except for fields 1-9 which appear to be always kept!). MXG supports
  the use of EXCLUDE, but requires you to EDIT VMAC110 into your USERID.
  SOURCLIB. (Find "EXCLUDE" in VMAC110 and follow the instructions.) IBM
  has suggested most of the CPU overhead of CMF is in the capture of CPU
  timings and Paging activity, which are usually important fields.  If
  your aim is to save space, make sure you calculate how much you can
  save before you go to all this effort. A CICS 1.7 transaction is 336
  bytes (CICS 1.6.1 was 186 bytes).With 1,500,000 transactions per week
  CICS 1.7 would write 504MB of data per week, which would only require
  a total IO transfer time (at 3MB per sec) of 168 seconds per week!
  Remember that you can put the CICSTRAN data directly to tape with MXG
  and keep all CICS detail data. When you read CICSTRAN to summarize and
  measure response time, remember to use (KEEP= ... ) on both the DATA
  and the SET statements to minimize SAS CPU costs and bytes moved.

  g. SMF dump sample program.
  The IBM sample program SMFDUMP, which automatically detects the active
  SMF data set, dumps, switches, etc., without operator action, can be
  found (currently!) in IPO1.SAMPLIB or with CBIPO in MVS Process Aids,
  (T00616.SAMPLIB). See also member IEFU29 which will automatically
  submit SMFDUMP when a MAN data set fills.

  h. MXG execution and storage costs.
  Analysis of CPU time to process SMF data into a SAS dataset suggests
  that MXG requires 100 seconds to read each 400 MB of input SMF data,
  and requires an additional 100 seconds for each 40 MB of output SAS
  data libraries.  Times are TCB+SRB on a 3090-400.  One site with two
  3081's and heavy workload reported that its total DASD requirements
  for MXG online data sets (eight dailies, one weekly, 5 years RMFINTRV,
  all MXG source libraries, etc.) was 350 CYL (250 MB) of 3380 DASD.
  Triple density 3380AKs purchase for $25,000 per 1873 MB means their
  250 MB was purchased for only $3216. They keep 3-years PDB (156
  weekly, 36 monthly) on 192 3480 tape cartridges ($6.50 each) for
  $1248. Total MXG storage cost is a one time $4464!

  i. 922 Abend.
  An MVS 922 ABEND can cause TYPE30 CPU times to be irrationally high,
  and the record may be missing the IO, PROC, EXCP and STOR segments.

  j. Large blocksize is good.
  Yet another reminder why large blocksize for sequential data sets is
  good. At 32760 blocksize a 3480 tape holds 215 MB, while at 4096 the
  same tape can only hold 124 MB.

  k. Sorting.
  How much do we sort? One site with a 3090-300 and 3090-200 supporting
  TSO (200 concurrent of 600 total user ids) issued 3550 sorts that took
  19 hours of CPU time. SMF recorded 47 CPU hours in type 30s, TYPE70
  recorded 55 CPU hours available. SORTs were 40% of the TSO load.


  l. IMS log processing.
  IMS log records can be separated (database recovery or performance) by
  the DFSUARCO program control card COPY statement to write selected IMS
  log records (see TYPEIMS) to a user defined DD.  To print the DSECTS
  of IMS log records, assemble   ILOGREC TYPE=DSEC,RECID=ALL

  Re-constructing an IMS transaction from the many different IMS log
  records is complicated because there is no unique field which ties all
  records together.  The MXG algorithms were re-designed (largely by
  Pete Shepherd) and then compared with Boole and Babbage's IMF data
  records. Resources (CPU, DL/I calls) are always correct, and response
  times are extremely close.  If multiple transactions are processed by
  a program schedule (eg., Wait-For-Input), there is only a single 07
  log record written, with total CPU and DL/I calls. MXG divides these
  resources across all of the transactions processed. As a result, you
  might find fractional DL/I counts recorded for a transaction! The new
  algorithms have been validated with IMS 2.1 and IMS 2.2 data and seem
  robust, (as long as all of the records for a transaction are on the
  IMSLOG tape presented to MXG). For IMS 1.3 data, however, it has been
  reported that sometimes variables MLOGONID, ODEST, MODNAME, MTYPE,
  LTERM, DEST, and/or LOGONID may be blank.  If IMS is really the bread
  and butter of your installation, you probably should not depend on us
  to always be able to recognize transactions, and should lobby IBM to
  enhance the IMS log records (like CICS's Unit-Of-Work ID field), or
  should consider an IMS monitor that creates individual transaction
  records, like IMF.

  m. NJE impact on job time stamps for Batch Service measurement.
  NJE sites tracking job service times note that the READTIME variable
  is the time (at the originating node) when the JOB card was first
  read, but the JRDRTIME (in each type 26 purge record) is the time (at
  each node) when the job completed read-in at that node. The MXG
  PDB.NJEPURGE data set may be useful in tracking job times. In the
  PDB.JOBS data set, since MXG keeps only the purge record from the
  actual execution node, the variable JRDRTIME will be the actual time
  when the job arrived at its execution node, and thus the delta between
  JRDRTIME to JSTRTIME will be the initiation wait time at the execution
  node. (However, that wait will also include time the job spent in
  hold, if any).

  n. Clarification of contents of MXG variable CPUTM.
  The variable CPUTM (in type 30 data sets, as well as in PDB.STEPS &
  PDB.JOBS) is the sum of all four CPU measures captured at the step
  level: CPUTCBTM, CPITCBTM, CPUSRBTM, and CPISRBTM. The equation has
  never changed, but Chapter 40 in the MXG Guide incorrectly documents
  CPUTM as the sum of only CPUTCBTM and CPUSRBTM.  The MXG Supplement
  correctly described CPUTM on page 366.  Note that these CPI...TM
  values (CPU time in the "initiator" or "privileged state") are not
  captured in the type 72 RMF record (they are in the uncaptured CPU
  time, see MXG Guide page 82 Fig 10.1 and MXG Supplement page 34).  The
  magnitude of these CPI "initiator" times is not typically very large
  (eg. 13 hours out of a total type 30 CPUTM of 683 hours, 2%), but the
  CPI time is directly attributable to the step and thus is included in
  the CPUTM variable which should be used for both the chargeback and
  the capacity measurement of processor utilization.


  o. An important date: When DATETIME clocks wrap:

  A date for your grandchildren. At 23:53:48 on Sep 17, 2042, the IBM
  8-byte hardware clock will fill and reset to Jan 1, 1900.

  With regard to the IBM clock date, it must be corrected by year 2011,
  as the retention period for a cataloged tape volume can be as long as
  30 years.

  And it turns out the Open Systems wrap earlier:

  The year 2038 problem ("Unix Millennium bug"), is UNIX result of
  storing its system time as a 32-bit signed integer with the number of
  seconds after the Unix/POSIX epoch time of midnight, January 1, 1970.
  This value will roll over on February 19, 2038.

5. Technical Notes: VM

  a. VM/XA Monitor description.
  VM/XA Monitor creates many new data records in brand new format. The
  CP MONITOR Command determines which domains, records, and which data
  will be created in a DCSS. The new MONWRITE CMS command extracts the
  data from the DCSS and writes the data to a CMS file which is read
  directly by MXG to create the 75 VX...... detail datasets and 1300+
  variables. The sample classes are sorted and build dataset VMXAINTV,
  the primary interval analysis data set, and VXBYUSR, the machine by
  machine interval analysis data set. The IBM documentation for the
  records are in the Appendix of SC23-0370-1. The IBM field names for
  monitor data are of the form of dddrrr_ffffffff; ddd is the name of
  the Domain and rrr is the name of the record type in that domain and
  ffffffff is the field name. MXG creates data sets named VXdddrrr and
  whose variables are named ffffffff, so that (finally) there will be no
  transformation between IBM and MXG nomenclature!  This is a major new
  addition to MXG which has been validated by a number of users.
  Additional IBM documentation will be found in:
      LY27-8058 - Features Summary, pp 478-482
      SC23-0353 - Administration, pp 137-145.
      SC23-0370 - CP Programming Services, pp 145-149, pp 237-421.
      SC23-0354 - CMS Command Reference, pp 371-373.
      SC23-0358 - CP  Command Reference, pp 271-288.
      LY27-8054 - CP Diagnostic Reference.
    The current documentation of this major MXG enhancement is in the
    comments in member VMACVMXA, CHANGES, and DOCVMXAF.

  b. VM/XA Monitor known problems.
  The following information was presented at SHARE in August and at the
  Confederate CMG in October.  The following problems have been observed
  in VM/XA Monitor data:
    1. Interval end time and interval duration are inconsistent.
       a. 30 second interval request generates 30.1 second data.
       b. MTREND data does not accurately represent collection interval.
          Writing user data extended 6 second interval to 9 seconds in
          MTREND, but actual delta varied by record from 6 to 9 seconds.
       c. Must use individual record-to-record DELTATM for rates of data
          in that record, but then a logic interval has many slightly
          different durations.
       d. ENDTIME should represent end of collection of interval but
          each MRHDRTOD is slightly different.
       e. MXG algorithm: Set ENDTIME as timestamp of first 0.1 (SYTSYP)
          record, but use DELTATM of 0.2 (SYTPRP) as common DURATM of
          interval, since SYTPRP contains CPU busy data. However, rates
          from other records are built using individual record
          DELTATMs.

    2. CPU measurement is inconsistent or incorrectly documented
       a. The sum of "user" PFXUTIME and "system" PFXTMSYS from SYTPRP
          (0.2) is greater than "TTIME" from USEACT (4.3) data.
          PFXTMSYS is not captured at the user level:

                             DWR1     DWR2     IBM1    HNET1    HNET2
       SYSTEM:  Total CPU:  873.94 12552.51  2700.70  874.00   125.18
                PFXTMSYS:    92.38  2832.56   369.43   92.00    73.62
                PFXUTIME:   781.56  9719.95  2331.27  782.00    51.56

         USER:  VMDTTIME:   773.94  9771.93  2341.12  774.00    51.56
                VMDVTIME:   433.56  7483.90  1667.81  434.00    31.93
                their diff: 340.38  2288.03   673.31  340.00    20.63

                %captured
                 by user:    88.5%    77.4%    67.4%   88.5%    41.2%

       b. In SYTPRP (0.2) the sum of PFXTMSYS+PFXTOTWT+PFXUTIME should
          match DELTATM between records, but is as much as 24 seconds
          short in a 900 second interval!  LOSTTM variable in VMXAINTV
          calculates the unaccounted time.
       c. A small amount of user CPU time is always lost in the USER
          data. CPU time used prior to the first interval record is lost
          and CPU time used between the final interval record and the
          user's logoff is not recorded.
    3. Response time validation is erratic.
       a. Controlled single-user experiment with one transaction in each
          30 second interval with two long transactions (Copy 1MB file
          from 2K "Q" to 1K "A" on same volume) clocked 51.99 and 52.20
          at terminal and were measured as 51.96 and 52.12 by VM,
          showing very good agreement for these two non-trivial
          transactions.
       b. However, the response time is recorded not in when the
          transaction ended, but when the next transaction start is
          recognized (two intervals later in this case!)
       c. Logon and IPL CMS seemed to take 7.28 seconds but VM recorded
          33.91 seconds.
       d. Unexpected trivial transactions were counted because SMART was
          also running. Assuming SMART response was near zero the
          product of number*duration matches the measured trivial
          response quite well.
       e. The biggest problem with response measurements in VM/XA is the
          actual definition of trivial itself. The Scheduler desires
          that 85% of all transactions count as trivial. To make this
          happen, the SRME1ETS elapsed time slice is adjusted from .5 to
          5 seconds to ensure that (if possible) 85% are classified as
          trivial! As a result, the CALMPTRV and CALUPTRV "Average
          Trivial" response value is meaningless unless you also look at
          the value of SRME1ETS. (MP and UP counts are intended to
          separate Guests (MP) from CMS (UP) responses). Thus the value
          of CALMPTRV and CALUPTRV are best described as "the average
          response of those 85% of transactions that completed in the
          elapsed time given by SRME1ETS".  In fact, the value of
          SRME1ETS may itself be a better measure of interactive
          response, as long as it is less than its upper bound of 5
          seconds! Detail comparison:

                                        --Monitor Reported--
          Action            Stopwatch   Non-trivial   Trivial
                                sec      avg   nr     avg  nr

          FILELIST              .86                  .44   2
          XEDIT                 .74                  .71   2
          SAVE                  .74                  .49   2
          SCROLL                .50                  .48   2
          END                   .72                  .39   2
          UNKNOWN CMD           .72      1.12  1     .48   2
          DISCONNECT            .66                  .35   4
          LOGON                 .79                   0    1
          IPL                  5.54      1.14  1     .72   4
          FINISH CMS INIT      1.74     33.91  1     .49   1
          EXEC DISK ACCESS     3.37      1.13  1     .51   1
          FILELIST             1.26      2.51  1     .50   1
          SORT                  .54      1.15  1     .53   1
          COPY 1031 BLK                              .48   2
          COPY completed      51.99                  .49   1
          no action                                  .55   1
          ERASE FILE              .50   51.96  1     .47   1
          COPY same 26391 rec                        .46   2
          COPY completed        52.20                .48   1
          no action                                  .63   1
          END                     .88   52.12  1     .51   1
          QUERY DISK              .80                .50   2
    4. Scheduler records cannot be used for CPU measurement of Guests
       which allocate more than one CPU (i.e., MVS). CPU time is
       accumulated by CPU Address, but CPUAD is not in the SCHEDULE
       domain records.
    5. Some USER domain USEACT records show small VTIME with no TTIME.
    6. Many fields are only two bytes, which wraps at 65536. An hourly
       interval would lose data on any field with a rate greater than 36
       per second, with no indication that data values were lost.  Use
       15 minutes or less for interval.
    7. One accumulated field is not monotonic: :VMDVCSCT, the Virtual
       Console Requests. This might result from a user who disconnects
       (count reset to zero at disconnect?)
    8. It was thought that (SYSUSRS-SRMCDORM) could be used as a count
       of "Active" users but it failed (and the difference is now named
       NONDORM) because SYSUSRS counts virtual machines while SRMCDORM
       counts VMDBLKS (one for each CPU defined by each machine.)  The
       variable ACTIVE is now calculated from user records (non-zero
       VTIME during the interval) but itself suffers because the
       interval size affects the definition, and because it counts
       VMDBLKS, not machines.
    9. IODDEV HFRDEVCNT is wrong. It accumulates an accumulation!
   10. SEEK data is wrong. The record indicates a seek did occur, but
       the serialization of data and the data in the record itself is
       not always valid.
   11. HFUSERC in VXPRCPRP and VMXAINTV (VMDBKS in PLDV is not valid -
       it appears to be accumulation of accumulation.  data is new to
       everyone (especially IBM!).
   12. Additional problems have been reported by IBM by MXG and other
       vendors and are under investigation. Unfortunately, the list of
       known problems has not been made available, and is not in IBM's
       Support Center as of this writing. I can only give you my list!


6. Technical Notes: SAS

   Z516.2120 Allows 3380-K's to contain SAS data sets with over 32000
             tracks. (This was never possible before 3380-K's so it
             is required only if you want to create a very large SAS
             data set.) Note that this zap is a very big one and is
             to be on the SAS 5.18 maintenance release and thus it is
             recommended that you wait until then.

   Z516.4669 Makes PROC CONTENTS aware of 3380-K's. See above zap.

   Z518.5694 Makes PROC GPLOT not set CC 12. (See Change 6.106).

   Z518.5779 Makes GROUP statement in PROC GREPLAY work correcty.

   The mainframe SAS/PC Device Driver (GRLINK) under 5.18 will not work
   when you are trying to create SAS/GRAPHs with a batch job.  This
   device driver expects the PC to be online and will not generate the
   graphs when the PC is offline (as it is to a batch job).  To
   circumvent this problem, specify
     GOPTIONS DEVICE=TCX4107 GOUTTYPE=INDEPENDENT NOCHARACTERS NOCELLS
              GSFMODE=NONE HPOS=80 VPOS=43;
    or use the %VMXGGOPT invocation of
     %VMXGGOPT(DEVICE=PCBATCH,DISPLAY=N);
   This will allow you to build a graphics catalog in a batch job and
   then replay the graphs with SAS/PC AND have graphs that look right!

   To execute MXG code under SAS/PC, you must first download the MXG
   member FORMATS and build the formats on the PC. You must create a
   directory and establish LIBREFS of SASLIB and LIBRARY pointing to
   that directory.  Member FORMATS will execute under SAS/PC and the
   resulting 150+ formats requires only 250K.  Members ANALDB2R,
   ANALDMON, and ANALNPMR have been tested on a PC. ANALDB2R took over
   35 elapsed minutes on an AT, compared with less than one minute on a
   3090 mainframe.

   The SAS ERROR: WORK.DIRMACR/SYSTEM REQUIRES MORE SPACE THAN IS
   ALLOCATED TO THE LIBRARY, followed by a NOTE:  DATA SET WORK.DIRMACR
   WAS AT OBSERVATION 16744450 has occurred at two sites during
   execution of the JCLTEST program.  This error results from a design
   limit in SAS. The DIRMACR dataset is where old-style macro
   definitions are stored, and it (unlike real SAS datasets) has a fixed
   limit in its size.  Both sites had (correctly!) made use of MXG
   member IMACKEEP to keep only desired variables. But because JCLTEST
   repetitively re-includes IMACKEEP, and because SAS does not reuse the
   space in DIRMACR (even though the same macro names are being
   re-defined with each include), DIRMACR filled!  Removing IMACKEEP
   temporarily from USERID.SOURCLIB allowed JCLTEST to complete
   successfully. THERE IS NO REAL PROBLEM HERE, since your normal MXG
   jobs do not re-include IMACKEEP hundreds of times!



IV. CHANGE LOG.
****************NEWSLETTER TWELVE***************************************










             MXG NEWSLETTER NUMBER TWELVE MAY 1, 1988

Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE


I.  MXG SOFTWARE                                                 page  2

    1. MXG Software Planning for 1988.
    2. MXG Software default media will be 3480 cartridge.
    3. Site licensing of MXG Software.

II. ANNOUNCEMENT OF MXG 6.2 PRERELEASE NOW AVAILABLE             page  3

    1.-18. Major enhancements in 6.2

III.TECHNICAL NOTES

    1. HOT PTFs: MVS                                             page  4
    2. HOT PTFs: VM
    3. Technical Notes, MVS
       a. Merging TYPE21 and TYPE74 for Tape Mount duration
    4. Technical Notes, VM                                       page  5
    5. Technical Notes, SAS
       a. Eliminating tape mounts for SAS tape data libraries.
       b. SAS ZAPS for 3380-K DASD Devices.






         COPYRIGHT (C) 1988 BY MERRILL CONSULTANTS DALLAS TEXAS

          MXG IS A REGISTERED TRADEMARK OF MERRILL CONSULTANTS



I. MXG SOFTWARE

1. Planning for 1988.

The MXG 6.2 prerelease announced below will be shipped upon request.  We
plan to ship MXG Production Version 6 to all customers in January, 1989.
We anticipate a 6.3 prerelease in the fall, supporting the DB2 type  102
SMF  record  and  the FACOM operating system records.  IBM has announced
ESA/370 and PR/SM in third and fourth quarter, and VM Release 6 as  well
as  VM/XA  SP2  in the fourth quarter.  Additional newsletters this year
will keep you informed of specific availabilities of prereleases.

2. MXG Software default media will be 3480 cartridge.

We are changing the default media on which we ship MXG Software from the
3420 (round) tapes to 3480 (square) cartridge tapes.  If you have 3480's
you need do nothing.  If you do not yet have 3480s, you  MUST  fill  out
the  enclosed postcard to get our software on round tapes.  Not only are
the 3480s more reliable, much faster to build, easier to load, and  hold
more  data  (200MB  versus 13MB for 300 foot reels, 6.2 needs 173 feet),
they are actually cheaper too!

3. Site licensing of MXG Software.

The MXG software is licensed by physical site (eg.,  data  center  at  a
single  physical  address).   We charge one fee per site, independent of
the number of CPUs at that site.  We do not check for CPU serials.

Additionally, you accepted these terms when you opened the software:

  The MXG software in this package is to be used for analysis of data
  CREATED  only  at  the installation address at which licensed.  The
  use of this product at multiple sites, or for consulting, or as  an
  execution  service  (processing  data  created at a different site)
  requires a special agreement with Merrill Consultants.

There is a discount on the MXG software for a second site license.

We included these definitions because in a very few sites, the people in
administration do not always keep you technicans informed  of  the  site
licensing  terms,  and  this might save you an extra phone call.  If you
now realize you need a special agreement, please discuss with us. There
is usually no fee involved for these special agreements.



II. MXG VERSION 6.2 PRERELEASE NOW AVAILABLE

Prerelease  6.2 of MXG Software Version 6 is now available upon request.
Call us (or your local SAS office if outside North America) and we  will
be  happy  to send this prerelease.  The primary enhancements are these:

 1. Support for VM/XA SP1 Monitor data. IBM has no VM MAP product; this
    MXG support provides that function for VM/XA data records. This new
    VM/XA Monitor creates many new data records in brand new format. The
    CP MONITOR Command determines which domains, records, and which data
    will be created in a DCSS. The new MONWRITE CMS command extracts the
    data from the DCSS and writes the data to a CMS file which is read
    directly by MXG to create the 75 VX...... data sets and their 1300+
    variables from the 75 different Monitor records. IBM describes these
    data records in the Appendix of SC23-0370-0. The IBM field names for
    monitor data are of the form of dddrrr_ffffffff; ddd is the name of
    the Domain and rrr is the name of the record type in that domain and
    ffffffff is the field name. MXG creates data sets named VXdddrrr and
    whose variables are named ffffffff, so that (finally) there will be
    no transformation between IBM and MXG nomenclature!  This is a major
    new addition to MXG which has been validated at the data set level,
    but which will have additional reporting and summarization added in
    the near future. IBM's documentation will be found in:
      LY27-8058 - Features Summary, pp 478-482
      SC23-0353 - Administration, pp 137-145.
      SC23-0370 - CP Programming Services, pp 145-149, pp 237-421.
      LY27-8054 - CP Diagnostic Reference.
      SC23-0354 - CMS Command Reference, pp 371-373.
      SC23-0358 - CP  Command Reference, pp 271-288.
    The preliminary documentation of this major MXG enhancement is in
    the comments in member VMACVMXA; new data sets, variables and their
    lables are in member DOCVER. Complete Chapter 40-style documentation
    be available with the production Version 6 shipment later.
 2. Support for NPM 1.3 new type 28 SMF record. This record replaces the
    type 38 (NPA/NPM), type 39 (NLDM) and VSAM VTAM Session statistics
    (MXG's XNPMSESS) data sources. Twenty four new data sets are created
    from TYPE28. All data sets now start with NPM..... and many variable
    names were changed. Member VMAC28 cross-references these changes for
    your reports.
 3. IDMS 10.1 Performance Monitor enhancements.
 4. IMS Log processing is validated and matches DFSILTA0 counting.
 5. ANALDB2R DB2 reports now match DB2PM reports.
 6. VM/Monitor validation with corrected state variable calculations and
    enhanced summary reports that now match VM MAP numbers exactly.
 7. MVS 2.2 cleanups and PTF support.
 8. VPS (a SYSOUT handler) support in TYPE6 data set.
 9. EXD (a SYSOUT handler) support in TYPE6 data set.
10. CA-DISPATCH (a SYSOUT handler) support in TYPE6 data set.
11. $AVRS (a SYSOUT handler) support in TYPESAVR data set.
12. Landmark Version 7.1 support.


13. CICS 1.7 UOWTIME variable decoded for the (undocumented) third data
    format for both CMF and Landmark records.
14. EPILOG 1000 for CICS data records code now works.
15. Build of MONTHLY PDB with only one tape drive logic corrected.
16. Analysis of tape mount time from TYPE74 and TYPE21 data discussed.
17. Support for RMDS Release 3.0 SMF record.
18. ASMVMCOPY (assembly source) and REXXCOPY (an exec) permits a VM/SP
    site to "dump" their VM/Monitor spool records to a CMS file. Without
    this program, you either used VM MAPs MONTAPE/MONDISK command or you
    used the SAS MONITOR INFILE exit to "dump" the VM/SP Monitor data.

All reported 5.5 problems have been fixed in this pre-release.

See the Change log and read the comments in the  referenced  MXG  source
member for complete details of these enhancements and changes.


III. TECHNICAL NOTES


1. HOT PTFs: MVS

2. HOT PTFs: VM

3. Technical Notes: MVS

a. Merging TYPE21 and TYPE74 for Tape Mount duration.

TYPE74   contains  total  mount  outstanding  duration  during  the  RMF
interval,  and  TYPE21  contains  a  record  for  each  dismount  event.
However,  TYPE21  does  not tell when the tape was actually mounted.  We
can assign the dismount time as the mount time, then sum the mounts to a
reasonable  time  interval  (an  hour)  and calculate an estimate of the
average mount time, AVGMNTTM, for each tape device for each  system  for
each hour (BY SYSTEM DEVNR HOUR).

New  MXG  member  ANALMNTS  (in MXG 6.2) estimates AVGMNTTM from 21s and
74s.  Analysis shows that if the  dismount  counts  from  the  21  occur
exactly  in  the  same RMF interval as the mount actually occurred, then
AVGMNTTM is exactly the mount time from MOUNT request to  DEVICE  READY.
While   95%  of  the  hourly  intervals  AVGMNTTM  showed  nearly  exact
comparisons (average mount times within  fractions  of  a  second),  the
other  5%  of  hourly  observations showed averages different by several
minutes!  This is because you never know whether the dismount count  was
in  the  same  interval  as  the  mount duration.  Statistically, if the
number of dismounts during the interval is large, the  average  is  more
likely  to  be  correct,  but  it  is still a very unpredictable average
value.  If IBM adds mount count to the type 74 record, ANALMNTS would be
and exact measure of tape mount time.


AVGMNTTM was validated with the MXG ASMONTAP tape mount monitor program,
which creates a record for each mount event, tracking both the  time  of
mount, its duration, and the JOB READTIME causing that tape mount.

  Unfortunately,  while  the  ASMONTAP  source  code  is  on  the MXG
  library, it has not yet been modified to  execute  outside  of  its
  home,  where  it exploits other local modifications at that site to
  capture the JOB and READTIME information.

If you have TELEGENIX devices (a display unit on each  tape  drive  that
displays  VOLSER, etc.) it puts "RESET cuu" messages (one per SYSTEM) on
SYSLOG at the precise time of the DEVICE  READY  event.   It  should  be
possible  to  match the correct RESET with the MOUNT message and measure
tape time from tape mount time from SYSLOG until ASMONTAP  is  modified.
(By  the  way, these multiple RESET messages, issued at one instant, but
time stamped on each SYSTEM, show the  time  of  day  clock  differences
between CPUs!)

One  analysis of tape mounts compared RMF, ASMONTAP, and SYSLOG for 3480
autoloaded scratch tapes.  The minimum  mount  time  was  20-30  seconds
(mount  to  ready)  just for the autoload mechanical operations, with no
additional human delay.  Furthermore, there were frequent  mounts  which
recorded  an additional 20-30 seconds elapsed time after READY until the
IEC705 event (DISP=NEW  tape  label  verification)  was  timestamped  on
SYSLOG.   This  is  an  additional delay time to the job that can not be
measured in mount duration because the mount has already been satisfied.

4. Technical Notes: VM

5. Technical Notes: SAS

a. Correction to Newsletter ELEVEN elimination of tape mounts.

The algorighm in MONTHBLD and on page 10 of Newsletter ELEVEN which uses
the FILE MONTH statement requires the additon of DCB=TAPETEMP:

    FILE MONTH MOD CLOSE=LEAVE DCB=TAPETEMP;

Without it, the tape is build using SAS' default DCB attributes for tape
data sets, which is RECFM=FB,LRECL=80,BLKSIZE=6400.

b. SAS ZAPS for 3380-K DASD Devices.

   Z516.2120 Allows 3380-K's to contain SAS data sets with over 32000
             tracks. (This was never possible before 3380-K's so it
             is required only if you want to create a very large SAS
             data set.) Note that this zap is a very big one and is
             to be on the SAS 5.18 maintenance release and thus it is
             recommended that you wait until then.

   Z516.4669 Makes PROC CONTENTS aware of 3380-K's. See above.



****************NEWSLETTER ELEVEN***************************************










             MXG NEWSLETTER NUMBER ELEVEN DECBMBER 15, 1987

Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE

 This newletter accompanies the production shipment of MXG Version 5.5.

The  MXG  Newsletter is available only to supported customers of Merrill
Consultants.  An "MXG Newsletter" binder, similar to the binder for  the
MXG  Supplement,  will  be  sent to your site early in 1988 to hold your
site's newsletters.

  We thought that 100 pages of MXG Newsletters would fit with the 500
  planned pages of the Supplement in its binder. The Supplement's 630
  actual pages absorbed our planned excess capacity!


I.  MXG SOFTWARE VERSION 5.5                                     page  2

II. 1988 ANNOUNCEMENTS                                           page  3

III.TECHNICAL NOTES

    1. HOT PTFs: MVS                                             page  4
    2. HOT PTFs: VM
    3. Technical Notes, MVS                                      page  5
       a. Counting allocated tape drives.
       b. I/O Counts in TYPE70 and TYPE78IO.
       c. SMF TYPE64 (VSAM I/O) counts.
       d. CPU and I/O measurements when writing tapes.
       e. More EXCPs in 30's than in 4's and 34's.
       f. More CPUTCBTM in SMF than in RMF for a step.
       g. MVS 2.1.7 page data set allocation size.
       h. Use STEP data for job ABEND analysis.
    4. Technical Notes, VM                                       page  8
    5. Technical Notes, SAS                                      page  9
       a. Eliminating tape mounts for SAS tape data libraries.
       b. SAS ZAPs which you should install.






         COPYRIGHT (C) 1987 BY MERRILL CONSULTANTS DALLAS TEXAS

          MXG IS A REGISTERED TRADEMARK OF MERRILL CONSULTANTS



I. MXG VERSION 5

   This  newsletter  accompanies  the  shipment  of MXG Version 5.5, the
   Production MXG Version 5, which contains the  following enhancements:

  1. MVS 2.2 support.
     - New type 36 ICF Export/Import SMF record.
     - New type 41 Data-In-Virtual SMF record.
     - Changes in existing SMF/RMF records.
  2. VM/SP Release 5 support.
  3. SAR Accounting record support.
  4. SAR Type 6 record support.
  5. DASD storage measurement system (dynamically read all VTOCs).
  6. IDMS 10.1 Performance Monitor record (new data sets) support.
  7. ACF2 user SMF record support.
  8. DB2PM validation and reports.
  9. IMS log processing re-designed and supported for IMS 2.1.
 10. STOPX37 user SMF record support.
 11. RMF Cache Reporter validation and enhancement.
 12. CICS 1.7 cleanups, enhancements, and more decoding.
 13. DFSORT Release 9 support.
 14. VM/Monitor summarization.
 15. Vector Processor measurement.
 16. TYPE64X data set for VSAM extents.
 17. SYSLOG JES3 processing and JES2 SYSLOG example.
 18. EDP Auditor Reports from RACF type 80 data.
 19. Eight CPU engine (3090-800?) C.E.C. Support.
 20. Online Business Systems WYLBUR Accounting SMF record support.
 21. TSO/MON Version 5.1 support.
 22. Extended Storage measurement enhanced.
 23. 3480 tape drive error counting in TYPE21 added.
 24. Separate counts of 3420 and 3480 tape drives in type 30 and PDB.
 25. VSAM VVR Type 60 record decoded.
 26. NETVIEW modifications to NLDM record supported.
 27. RMDS support.
 28. SYNCSORT user SMF record support.
 29. CINCOM SUPRA log record support.
 30. VM Account LOGOFF record support.
 31. ROSCOE 5.5 SMF Account record support.
 32. IMF 2.3 support for DDNAME level I/O counting.
 33. NETSPY support.
 34. OMEGAMON EPILOG 1000 support.
 35. Externalized BUILDPDB macro definitions in IMACPDB.
 36. HOGAN FPS transaction function code data support.
 37. CICS 1.7 EXCLUDE option "support".
 38. IDMS Performance monitor from IDMS journal file supported.
 39. Landmark's SPECIAL 78 zap (adds CICS 1.7 MRO fields) support.
 40. Naming conventions established for MXG's use of "New style" macros.
 41. Elimination of excess tape mounts for monthly and weekly jobs.

   Four MXG Version 5 pre-releases, in  July,  August,  October  and
   November,  were tested by more than 150 sites; their feedback was
   invaluable in the quality assurance of the production release.



   POTENTIAL COMPATIBILITY EXPOSURES BETWEEN MXG 4.4 AND MXG 5.5:


 1. The aggregation interval of RMFINTRV data set was relocated in the
    new member IMACRMFI, instead of being defined inline.

 2. VM/Monitor users must read Change 5.133. The meaning of VMONDEV data
    set variable CNTVIOCT was altered. A new macro, _INTRVL, defined  in
    IMACVMON, sets the expected record interval of your VM/Monitor.  The
    MXG default of one minute is now used to detect user logon events.

 3. BUILDPDB/3 users who wish to tailor the PDB data sets will no longer
    have to make internal changes; all PDB macros which control the PDB
    data sets were externalized into member IMACPDB.



II. 1988 EXPECTATIONS


 IBM  announced  plans for operating system changes next year which will
 likely require changes to MXG software.  IBM dates given below are  the
 availabilty  date  in  the IBM announcement.  We always hope to provide
 MXG support by availability date, if we can get both documentation  and
 test  data in time.  We will likely repeat the strategy of the past two
 years:  a spring newsletter to announce when  the  pre-release  of  the
 next  MXG version is available, and a production MXG version shipped to
 all customers in the fall.


 a. March, 1988. Expected availability of VM/XA SP1, with a complete
    new set of monitor records, new format, and zero compatibility with
    current VM/SP VM/Monitor data.  IBM says there will be no VM MAP for
    this new VM/XA monitor, but MXG will be there.

 b. May, 1988. PTF to MVS 2.2 which adds VIO activity fields to TYPE71
    data (this PTF permits VIO to be directed to Extended Storatge).

 c. Unknown. PTF to add JOB and READTIME which IBM  left out of the new
    MVS 2.2 Type 41 (Data In Virtual) SMF record.

 d. December, 1988. Expected availability of VM/SP Release 6, with many
    new data elements added to existing VM/SP VM/Monitor. This release
    includes the new VM Shared File System, which creates new data.

 e. Unknown. We expect to enhance MXG to support the PDL data written by
    the FACOM OSIV/F4 MSP operating system.

 f. Unknown. Other rumored impacting events may be CICS 2.1, a new DB2
    release, and DOS/VSE Power record changes.



III. TECHNICAL NOTES


 Note:   The PTF or APAR numbers were provided by some system programmer
 who has actually installed this fix, but sometimes the number  will  no
 longer  be valid;  IBM supersedes and replaces PTFs, and one APAR often
 has several PTFs for the same logical problem.   Use  this  information
 only to search INFO/MVS for more information and exact status.


1. HOT PTFs: MVS:


 MVS  2.1.7  PTFs  OZ44728  and OZ92196 appear to finally solve the long
 outstanding constraint that the SMF interval (for type 30s and 32s) had
 to  be greater than JWT.  These PTFs apparently are already in MVS 2.2,
 and the documentation still recommends that the  Interval  duration  be
 greater than JWT, but experimental system programers have reported that
 that recommendation is no longer a requirement.  Don't take my word  on
 this, but I think it's probably true.

 A  new  PTF  (only for MVS 2.2 and later) finally allows you to specify
 BLKSIZE of the SMF data.  Requested through SHARE in the CME project in
 1973,  it has finally been acknowledged in APAR OY07209 and implemented
 in PTF UY12002.

 MVS 2.1.3 and 2.1.7 do not write type 7 records when SMF  recording  is
 lost!  Fix is PTF UY12608.

 For 3090-400s, 300s, and 600s with 128MB real memory, there are lots of
 performance problems if you do not install  OY01085.   Your  CE  should
 have caught this one for you.  MXG NL TEN misprinted this PTF number.

2.HOT PTFs: VM:


 Concatenated MACLIBs on different mini-disks will fail;  only the first
 MACLIB in the concatenation will  be  searched  until  PTF  VM24283  is
 installed.   As long as the MACLIBs are on the same mini-disk, there is
 no problem with concatenation (as suggested for the  MXG  SOURCLIB  and
 USERID SOURCLIB libraries).



3.TECHNICAL NOTES, MVS:

 a. Counting allocated tape drives.
 The following is a revision of a note originally in MXG Newsletter TEN:
 Counting of tape drives  (TYPE30_4  or  PDB.STEPS  variables  TAPEDRVS,
 TAPE3420  and/or  TAPE3480)  is  affected  if  the job step dynamically
 allocates tape drives.  For example, DB2MSTR  dynamically  allocates  a
 drive  every  time  the recovery data is backed up.  If each allocation
 happens to get a different tape drive,  the  step  record  for  DB2MSTR
 would  contain a different DEVNR (old UCB address) for each tape, which
 MXG would count as a large number of tape  drives.   Only  a  few  jobs
 actually  use  dynamic allocation (thank goodness), but they tend to be
 long running DBMS, which wreak havoc  on  the  number  of  tape  drives
 perceived  by ANALTAPE to be in use.  You must use the type 40 (Dynamic
 Allocation) record to find those jobs that  dynamically  allocate  tape
 drives, and exclude their step records before processing STEPS with the
 MXG ANALTAPE program.  Otherwise, it will appear the job step  had  all
 those tapes for the entire time the step executed.
    You can use the MXG Exit Facility to add type 40 processing, and  in
    the exit (EXTY40) and use:
        IF DEVICE='3420' or DEVICE='3480' THEN OUTPUT TYPE40;
    to only create observations for tape devices.
       VMAC40 reads in a 40 and calls VMACEXC1, which decodes  DEVCLASS,
       DEVTYPE,  and  DEVNR  for  each UCB segment.  VMACEXC1 then calls
       VMACUCB to decode DEVCLASS and DEVTYPE (hex) into DEVICE  (char);
       the value '3420' or '3480' is set for tape devices.
    Since  SMF  offers  no option to create type 40's just for tape, you
    still have to create all type 40 records, but this use of the EXTY40
    exit allows you to keep only tape observations in TYPE40.

 b. I/O Counts in TYPE70 and TYPE78IO.
 The MXG Supplement noted that the I/O Interrupt Counts in  TYPE70  were
 observed  to be greater than the 3090 IOP I/O Activity in TYPE78IO.  It
 was pointed out that IBM notes (in LY17-5500) that  both  TYPE78IO  and
 TYPE70   count   SSCH   (i.e.   SIOs)  and  RESUMES,  but  that  TYPE70
 additionally  counts  PCIs,  Device  End  following  Channel  End,  and
 Unsolicited Interrupts.  The difference has been seen as 12-14% more in
 TYPE70.  Is this a useful indicator of anything?

 c. SMF TYPE64 (VSAM I/O) counts.
 VSAM counts (EXCPs, SPLITS, etc.) in type 64 records are wrong  if  the
 VSAM  file  is concurrently opened.  These counts are the "change since
 open".  Four jobs which concurrently opened the same VSAM file and then
 read  9000  blocks, showed 9000, 18000, 27000, and 36000 EXCPs in their
 type 64 records.  The type 30 SMF record EXCP counts are correct.   The
 type  64  record  has  always  been this way;  only recently did a user
 investigate the data.  MXG will be  enhanced  to  de-accumulate  TYPE64
 data,  as ANALDSET does to de-accumulate TYPE1415 data.  You could find
 a CASPLIT count in a type 64, but the actual split may have been caused
 by a separate job.  You must sort all accesses to the same VSAM file by
 open time and examine the end time for potential  overlap  and  perform
 you own de-accumulation.



 d. CPU and I/O measurements when writing tapes.
 In  creating  tape  copies of MXG Version 4.4, we used SYNCSORT's free,
 fast BETRGENR replacement for  IEBGENER.   Since  BETRGENR  copies  one
 cylinder  at a time, the 833 blocks of 6160 bytes each required only 11
 Start IO's, each SIO transferred 550KB of data in .44 seconds (you  can
 hear  the  voice  coil  humm  that long), but there was then a delay of
 about .6 seconds for the next SIO to commence (again, heard at the tape
 drive).   As  a result, while the channel capacity is 1.25 MB/sec, even
 with the transfer of 550KB per SIO, the effective channel capacity  was
 only  550KB/sec,  or  only  44% of IBMs stated capacity.  This was in a
 dedicated processor with no other work in progress.

 Furthermore, this was for a single copy of the MXG library.  The actual
 data transfer took 11 seconds for the 11 SIOs, but the physical loading
 of the tape, the swap in to reply (tapes are NL) and the rewind and the
 unload  time total just about one minute elapsed time.  Because we were
 waiting on the computer (THE definition of bad response)  we  allocated
 more  tape drives and found that with two tape apes (us), and four tape
 drives, we could create 100 tapes per hour.  Increasing the tape  drive
 count  to  six  drives  increased our production to 163 tapes per hour.
 Note at this rate of 163 5.5MB tapes written per hour, the tape channel
 was  still  only  utilized at 250KB per second, or only 20% of the peak
 transfer capacity.  The peak-to-sustainable rate here was 5 to 1.

 This should point up the fallacy of using the peak  transfer  rate  (or
 any peak rate) as a measure of capacity, without determining the actual
 sustainable transfer rate.  IEEE Computer magazine recently had a  good
 discussion  with  regard  to  the ratio between peak mega-flop rate and
 achievable mega-flop rate on super computers, reporting typical  ratios
 also in the 5 to 20 range.

 Each job executes 255 copy steps.  All steps except the first  recorded
 .40  or  .41 TCB seconds and .03 SRB seconds on a 3090-200.  With 5.5MB
 of data per step, this 13 MIPS (speed) processor is moving data at 13.4
 MB per second.  This is quite close to the one byte per one instruction
 rate first noted on page 842 of the MXG book!

 The first step of each job, however, required 1.06 TCB seconds and  .06
 SRB  seconds, or 1.12 total CPU seconds apparently because the CPU time
 for operator response to allocation recovery is captured in  the  step.
 Each job enters allocation recovery because its specific UCB address is
 offline at job initiation.  The IEF244I - "Unable to allocate"  message
 set  up  the  IEF238D  -  "Reply  Device  Name  or Cancel" WTOR and the
 R,99,181 reply apparently records .68 CPU seconds in the step record.

 (The job which specifies VOLSER=MXG181 allocates UCB 181.  NL tapes are
 built so only one mount is needed, but require a reply to  confirm  the
 VOLSER.   With the UCB in VOLSER, the reply is fast and accurate.)



 e. More EXCPs in 30's than in 4's and 34's.
 Several  sites have noticed approximately 10% more EXCPs are counted in
 the type 30 subtype 4 (TYPE30_4 data set) record than the EXCPs in  the
 step  type  4  (or type 34) for the same step.  The type 30 is correct,
 and the additional count in type 30 is due to the EXCP count to dynamic
 allocations, which are captured in 30s but never were captured in the 4
 or 34 records.  As described on page 628 of the MXG book, if  you  used
 4s  or  34s, you had to use the 40s also.  This is only one more reason
 why the type 30 SMF record has (since 1978) always and  all  ways  been
 better  than the type 4/34 records.  It's even worse for the 4s and 34s
 now.  In MVS 2.2, IBM turns on a new flag bit in 4s and 34s to tell you
 that  the  EXCP  data on this step is incomplete in the 4/34 record and
 you must use the type 30 for this step.  (This  happens  for  any  step
 with  more  than  1651  DD  cards).   STOP  USING 4's and 34's!  (MXG's
 BUILDPDB has always used only type 30s.)

 f. More CPUTCBTM in SMF than in RMF for a step.
 Step termination data shows that the SMF CPU TCB time in the  SMF  type
 30  can  be  slightly  greater than the RMF CPU TCB time in RMF service
 units in both the SMF type 30 and the RMF type 72 record for that step.
 The  step  recorded  8.13 CPUTCBTM seconds in TYPE30_4, but CPUUNITS in
 the step record (converted to CPU seconds) showed  only  8.08  seconds.
 This  step  executed  in  a  unique  performance  group, and the TYPE72
 CPUTCBTM was also 8.08 seconds for  the  interval  in  which  the  step
 executed.   This  is  not  statistically significant, but an IBM expert
 suggests  this  occurs  because  RMF  gets  it  service   unit   values
 (CPUUNITS,SRBUNITS) from the job data during step termination.  This is
 why the CPUUNITS in the type  72  data  matched.   However,  after  the
 service  units have been passed to RMF, the job is still in termination
 and the SMF clock is still accumulating true CPU  time  for  the  step.
 The  extra  CPU  time recorded in the SMF step record may be due to SMB
 processing (putting those termination messages on your SYSLOG  listing)
 or  it  could  be  installation code executing in SMF exits (perhaps to
 print the job costs on the "banner page" in SMF exit IEFU83 or IEFU84).
 At  this  site, there appears to be a fixed cost of .05 TCB seconds per
 step termination which is not recorded  in  the  TYPE72  CPUTCBTM,  but
 which  is  recorded  in  the  TYPE30  CPUTCBTM.   Even  at  1000  steps
 terminating each hour, this would be only  50  additional  TCB  seconds
 for each 3600 seconds, or only about one percent.

 g. MVS 2.1.7 page data set allocation size.
 The  Contiguous  Slot  Allocation  algorithm, the very efficient way of
 transferring up to 30 page frames contiguously with one  SIO  and  with
 minimal arm movement, was introduced for page data set I/O with MVS/370
 SP 1.3 in the late 70's.  Recently, several authors have concluded that
 the  algorithm will perform well only if the maximum number of slots in
 use is less than 25% of the slots allocated.  When the page data set is
 full,  the  algorithm  can  not  perform  well, because it can not find
 contiguous free slots.  This greatly increases the search  time,  which
 can  negate  the  positive  performance  of the algorithm.  For MVS/370
 VSCR, IBM had recommended minimizing the number of slots  allocated  to
 relieve  MVS/370  VSCR  because  a small amount of CSA is used for each
 slot allocated.  With only 50K-60K virtual storage saved,  real  paging



 is  likely  a  more  serious  problem,  and thus a larger page data set
 allocation may still be advised.  In early MVS/XA there also was a real
 problem  with  large  page  data sets causing excessive seek times, but
 that design error was fixed in MVS 2.1.2.  You can use the MAXUSED  and
 SLOTS variables in TYPE75 to see if you might have a problem, and could
 plot the percent used versus the service time  (AVGRSPMS  from  TYPE74)
 for each paging volume to confirm its real impact.  It is clear that an
 insufficient number of allocated slots will degrade the contiguous slot
 algorithm;   the  exact  percentage  at  which  you encounter increased
 service time may not be 25%, and you should construct your own data for
 analysis.

 h. Use STEP data for job ABEND analysis.
 Analysis  of  "Job" abends really must be done from the PDB.STEPS (from
 TYPE30_4  step  termination),  rather  than  from  the  PDB.JOBS  (from
 TYPE30_5  job termination).  The CONDCODE and ABEND variables (Page 578
 in the MXG Book, page 266 in the MXG Supplement) describe the value and
 the  type  of  termination.   ABEND  values  of SYSTEM or USER indicate
 abends and CONDCODE identifies the abend code, such as  SYSTEM  322  or
 USER  999.  An ABEND value of RETURN indicates that CONDCODE contains a
 return code value.  While both variables exist  in  both  PDB.JOBS  and
 PDB.STEPS,  the  ABEND  value  in  PDB.JOBS is from the job termination
 record, and can show an ABEND of SYSTEM for the job with a CONDCODE  of
 zero  if  the  step which ABENDed was not the last step!  The PDB.STEPS
 data is thus not only more accurate, but since many abends  result  are
 due  to  defective programs rather than defective jobs, using the STEPS
 data allows you not only to identify which JOB  abended,  but  also  to
 identify  the  name of the PROGRAM which abended.  You may even be able
 to  recognize  (by  your  program  naming  convention)  which  of  your
 development groups wrote the frequently-abending programs!).  PDB.STEPS
 data also identifies which step actually abended first when  there  are
 multiple abends (and when there are COND=EVEN and COND=ONLY steps).


4. TECHNICAL NOTES, VM:


 There are two ways to hold SPOOL data in VM so that it exists after the
 spool data is read:
    SPOOL READER HOLD             holds the reader, while
    CHANGE READER nnn HOLD        holds the file
 Hold only the reader, never hold the file, if you want the data to be
 read. The CMS Diagnose 14 Subtype 1C command which is used to read the
 monitor data in the spool, skips over held files.



5. TECHNICAL NOTES, SAS:

a. Eliminating tape mounts for SAS tape data libraries.

 Many users have found that the weekly and monthly PDB jobs (described
 in Chapter Thirty-Five with examples in MONTHBLD and WEEKBLD) can cause
 lots of tape mounts and rewinds.  Some sites have resorted to the
 parallel allocation of as many tape drives as there are tape volumes to
 avoid mounts.  This problem is not unique to MXG, but results from the
 protective instincts of SAS when tape data sets are involved.  As you
 will see, we now have a sucessful circumvention which minimizes the
 amount of temporary DASD needed by WEEKBLD and MONTHBLD, and completely
 eliminates the multiple rewinds and mounts for the output library.

 The Present SAS Design:
 SAS data libraries on tape volumes have no directory of what SAS data
 sets are where on the tape.

 When a SAS SET statement needs to read a SAS data set from tape data
 library, SAS rewinds to the beginning of the tape, and searches for the
 desired data set name to be read.

 When a SAS DATA step writes a SAS data set to a tape data library, the
 tape is first rewound to the beginning of the OS tape dataset, and SAS
 begins searching for the data set name to be written:
   i.e., if currently on vol 4 of a multi-volume tape data library, SAS
   will rewind and dismount vol 4, mount vol 1, read and dismount it,
   mount vol 2, read and dismount, etc, until it gets back to where it
   physically was, and then SAS writes the SAS dataset at the end of the
   existing tape, if no matching SAS dataset was found in the library.
     If a match is found, SAS starts writing the new data set where
     the old one was found, ERASING ALL OTHER DATA SETS physically after
     that point on the tape!

 The Source of the Problem:
 The required rewind spins the tapes a lot.  If the SAS data library
 fits on a single volume, there is not too much of a problem.  But if
 the output tape library expands to multi-volume, the above problem of
 mounts, dismounts and rewinds will elongate run times, whenever SAS
 DATA steps are used to create the tape data library.

 Past Circumventions:
 One solution was to build all of the desired SAS data sets on disk, and
 then use PROC COPY from disk to tape.  The PROC COPY knows it does not
 need to rewind before each data set.  While this avoids the mount
 problem, it requires as much temporary DASD space as the size of the
 entire SAS data library, which is why it was not recommended.

 The New Solution:
 Each new SAS data set is first built on temporary DASD in "tape
 format", and then is copied to the output tape using FILE/INFILE logic,
 exploiting the SAS CLOSE=LEAVE option to hold the output tape in place.
 The temporary DASD data set is then erased, so that the job needs only
 as much DASD space as the size of the single largest SAS data set to be
 created.  The SAS "tape format" originally was created just by using a
 DDNAME that started with "TAPE....", but now LIBNAME TAPETEMP V6SEQ;
 syntax is used to create the Sequential Format, which is required so
 that the SAS data set can be copied with the FILE/INFILE logic.  The
 following partial example shows how this is done (see member MONTHBLD
 for complete implementation):


  // EXEC    SAS,OPTIONS='TAPECLOSE=LEAVE,ERRORABEND'
  //MONTH    DD DSN=MXG.MONTHLY(+1),DISP=(NEW,CATLG),UNIT=TAPE,
  //            DSCB=SYS1.MODEL,LABEL=EXPDT=99000
  //TAPETEMP DD DSN=&TEMP,UNIT=SYSDA,SPACE=(CYL,(10,10))
      LIBNAME TAPETEMP V6SEQ;
      DATA TAPETEMP._DSET;                      create _DSET in TAPETEMP
        SET WEEK1._DSET WEEK2._DSET ...   ;     input data sets
        BY _BYLIST:                             sort order variables
        IF date selection logic;                selection criteria
      RUN:
      DATA _NULL_;                              copy _DSET to MONTH
        INFILE TAPETEMP;
        FILE MONTH MOD CLOSE=LEAVE;
        INPUT;
        PUT _INFILE_;
      DATA _NULL_;                              write EOF to TAPETEMP to
        FILE TAPETEMP;                           "scratch" _DSET

 These three DATA steps are then repeated for each data set to be built,
 by invoking the _MNTHBLD macro as shown in member MONTHBLD.  Our thanks
 to Susan Marshall, SAS Institute, for  this  circumvention.   The  only
 additional  cost  is  the  extra copying of each output data set.  This
 solution only eliminates mounts for the output SAS  data  library.   If
 the  input  data  sets  are  on multiple volumes, each new data set may
 causes the same rewind and dismount/mount sequence.  These input mounts
 can  only be eliminated (at present) by specifying multiple units where
 necessary, eg., with UNIT=(TAPE,2) for a  two-volume  input  tape  data
 library.
    SAS  Institute  is  investigating a new SAS option which might allow
    you to override that "rewind and search" algorithm  for  both  input
    and  output tape data libraries.  Provided the order of building new
    data sets is the same as their order on the  input  data  libraries,
    such an option could completely eliminate the unnecessary mounts and
    unnecessary copy steps.  No commitment has been made by SAS yet.
 However, early experience with  this  circumvention  is  overwhelmingly
 positive  - fewer tape drives, fewer tape mounts, significant reduction
 in elapsed time, all for a few seconds of  I/O  time!


 b. SAS ZAPs which you should install.

  ZAP 516.2525     Corrects (erratic) error condition in PROC PLOT if
                   data set has zero observations.

  ZAP 516.4592     PROC FORMAT can cause a "STOW failure" message on the
                   SAS log (no error condition, no abend) if the PDS to
                   which the formats are being written does not have
                   enough directory blocks defined. Some formats will be
                   missing, with no notification. This ZAP tells you.


****************NEWSLETTER TEN******************************************










                (3XMXG NEWSLETTER NUMBER TEN JUNE 30, 1987

Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE


 Contents:                                                          Page

  I.   Availability of the MXG Supplement

  II.  Availability of pre-release of MXG Software Version 5.1

  III. Availability of the CPE Starter Set SAS/AF Application         3

  IV.  Technical Notes

       1. HOT PTFs: MVS                                               4
       2. HOT PTFs: VM                                                4
       3. Technical Notes, MVS                                        4
       4. Technical Notes, VM                                         6
       5. Technical Notes, SAS                                        6


 -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -

We are delighted to send this newsletter.  We hope that the  600+  pages
of  the  Supplement  compensates  for  the  long time since our last MXG
Newsletter.  As you can see  from  the  enclosed  list  of  changes  and
enhancements,  MXG is continuing to grow in scope and quality, thanks to
the many of you who supply us with requests, suggestions, and with  code
and/or test data.  We thank you all for your contributions.  See Chapter
99 in the MXG Supplement.



We are children of the sixties, who know that just because we  have  the
keys to the kingdom, we do not have to charge what they are worth.


                                 Barry and Judy Merrill




         COPYRIGHT (C) 1987 BY MERRILL CONSULTANTS DALLAS TEXAS
          MXG IS A REGISTERED TRADEMARK OF MERRILL CONSULTANTS



(3XI.   Availability of the MXG Supplement

MXG customers who were in good standing as of June 1, 1987, will receive
a free site copy of the MXG     Supplement     accompanying  this
newsletter.  (All  such  sites  have  previously received the three-ring
binder which holds the Supplement and our Newsletters).

The  MXG     Supplement     is described on page 28 of the Second
Quarter 1987 issue of SAS Communications.  The MXG Supplement is
over 600 pages,  and preserves  the  42-chapter  structure  of  the
original  guide for easy cross-reference.  The Supplement describes all
the additional sources of data  which  have  been added to MXG since the
MXG Book was published in 1984:

    New Data Supported                          Enhancements

 Bulk Data Transfer                     CICS 1.7 support and discussion
 Cache RMF Reporter                     TSO/MON Release 5
 DB2 Accounting and Statistics          3480 Tape counting
 DISOSS Accounting                      Vector Facility Measurement
 IDMS MXG Monitor SMF Records           3090 CPU Measures
 IDMS (RTE) Performance Monitor       Expanded Memory Tutorial
 IMS Log Records                        MVS/XA IO measures (connect,
 JES2 Spool Transfer Program              disconnect, pending, etc.)
 Landmark's The Monitor for CICS        LCU queueing measures
 MODEL204 Accounting and Response       3090 IOP measures
 NPDA Type 37 SMF Record                DOS/VSE Release 2 enhancements
 NLDM Type 38 SMF Record                PDB data sets documentation
 RACF Type 80 SMF Record                CMS installation instructions
 ROSCOE Accounting and Response
 VTAM Application Session Record
 VM/Monitor


Additional copies of the MXG Supplement are now available for purchase
from the SAS Publications Department, or from your local SAS office.  It
is our recommendation that each person who uses the MXG Software should
have both a copy of the MXG Book and the MXG Supplement.



(3XII. Availability of pre-release of MXG Software Version 5.1


We will send the production MXG Version 5 to every supported site in the
fall  of this year.  We cannot ship Version 5 until after MVS 2.2 and VM
Release 5 HPO are released by IBM and have been tested.   Both  products
have an announced planned availability of Third Quarter, 1987.

The  enclosed list of changes permits you to update your MXG Version 4.4
prior to receipt of MXG Version 5.  Read the change log carefully to see
if any of the impacting changes are required at your site.

We plan to make available a pre-release copy of MXG Version 5.1 in early
July, 1987, which contains all of these listed changes.  We are still in
development of MXG Version 5, so you can expect  significant  additional
enhancements between this pre-release and the production version.

If you would like to install the pre-release of MXG Version 5.1,  please
call  (overseas  sites must call their local office) and it will be sent
to you (at no cost) when it is available.


(3XIII. Availability of the CPE Starter Set SAS/AF Application


The CPE Starter Set is a SAS/AF application which is available FREE from
SAS Institute, Cary, N.C., or from your local  SAS  representative.   It
was developed by Allan Russell of SAS Institute GmbH in Heidelberg.

SAS/AF  gives end users (for example, your manager) the ability to plot,
analyze, select and apply the power of the SAS System to SAS  data  sets
through screens and menus which require no knowledge of the language.

The CPE Starter Set is both an example of how to use SAS/AF and a superb
set of hourly, daily and weekly reports of interest to managers and  CPE
technicians  alike.   It contains a tutorial on its use, and generates a
wide range of reports from MXG data sets built from MVS (PDB  data  sets
JOBS, STEPS, RMFINTRV), and from VM (VMONPERF) data.

If you have the SAS/AF product installed, call and request the FREE copy
of the CPE Starter Set from your SAS sales representative, and tell them
you read about it in the MXG Newsletter.




(3XIV. TECHNICAL NOTES

1. HOT PTFs: MVS:

Overlay  and  loss of SMF records - many strange symptoms - fixed by PTF
UZ46460 and UZ48888-UZ48891.  Critical, must be installed ASAP.

Incorrect SMF EXCP data, especially  30s,  introduced  by  bad  UZ45011,
fixed  with  UZ47837  (pre-reqs  UZ47834-UZ47837  and  UZ50314-UZ50316).
Noted loss of VSAM counts in type 30, was fixed by UZ47837.

Originally reported by MMA, complete loss of SMF data  will  occur  with
DFP  Versions  1.1.1,  1.1.2,  or 2.1 if you have installed the PTFs for
APAR OZ96798, and you have  NOT  corrected  the  PTF-in-error  condition
described  by  APAR  OY02500.  The SMF data loss condition is cause by a
problem in VSAM introduced by OZ96798 PTFs.  Message IEE978E:   SMF  NOW
HAS nnnnn BUFFERS will be issued after the initial number of SMF buffers
are used up, but there is no other  external  indication  that  all  SMF
records have been permanently lost.

Incorrect  counting  of  some tape mounts in type 30 records.  After the
installation of UZ50959, tape mounts issued with message  IEC501E  (Look
ahead  mount  message) are not counted.  Mounts with messages IEC501A or
IEC233A continue to be correctly counted.  APAR  OZ97886  describes  the
problem,  accepted  by  APAR  OZ97617  which  has  the fix.  The problem
primarily affected multiple volume mounts;  only the first volume  mount
was counted in the type 30.

For  3090-400s, 300s, and 600s with 128MB real memory, there are lots of
performance problems if you do not install OY0185.  Your CE should  have
caught this one for you.

2. HOT PTFs: VM:

Concatenated  MACLIBs on different mini-disks will fail;  only the first
MACLIB in the concatenation  will  be  searched  until  PTF  VM24283  is
installed.   As  long as the MACLIBs are on the same mini-disk, there is
no problem with concatenation (as suggested for  the  MXG  SOURCLIB  and
USERID SOURCLIB libraries).

3. Technical Notes, MVS:

CICS  CMF  record  blocksize  is  set  by the JCT BUFSIZE parameter, and
typically is only 6000, which should be increased to half-track on 3380s
to reduce IO counts and CPU overhead in building CMF records.

NPM  may  produce  negative  square  root  when   calculating   standard
deviation, since the SSQ field can wrap in the NCP.



Counting of tape  drives  (TYPE30_4  or  PDB.STEPS  variables  TAPEDRVS,
TAPE3420  and/or  TAPE3480)  is  affected  if  the  job step dynamically
allocates tape drives.  For example,  DB2MSTR  dynamically  allocates  a
drive every time the recovery data is backed up.  This can create a step
record for DB2MSTR  with  a  different  UCB  address  for  each  dynamic
allocation,  which  MXG  would  sum  as  a  large number of tape drives.
DMS/OS has similar jobs which  dynamically  allocate  tape  drives  too.
There  is no fix, but before processing PDB.STEPS with ANALTAPE, examine
step with large value for TAPEDRVS and if you  recognize  that  the  job
step  dynamically  allocates  tapes, exclude that job step (by job name,
step name, and program name) from  the  analysis.   Otherwise,  it  will
appear  the  job  step  had all those tapes for the entire time the step
executed.

Tape mounts in TYPE30_4 and PDB.STEPS does not include mounts issued  by
JES3 for MDS mounts;  they are counted in the JES3 Type 25 record.

Steps which mount a tape, and then RETAIN, will show zero mounts for the
subsequent step.  If you want to identify steps which actually use  tape
in  any  step,  the  EXCPTAPE and IOTMTAPE are much better indicators of
actual usage.

It is observed that the IO interrupt count reported in the  TYPE70  (and
on  the  RMF  CPU report) is always greater than the IO activity rate in
the TYPE78IO (and on the RMF LCU report), typically by 5-7%.   This  may
be a useful measure, if we knew what causes I/O interrupts to exceed I/O
activity.  Any thoughts?

UCC7 can cause invalid READTIME error messages.  There are  two  options
for  UCC7 to identify jobs which are under its control.  By default, the
eighth byte of JMRUSEID (the 'User identification field',  MXG  variable
LOCLINFO)  is used.  The UCC7 installer can choose any other byte of the
JMRUSEID if other products use the eighth.  If all eight bytes are  used
by other products, UCC7 will optionally store its flag in the first byte
of the Job Reader Date field.  The normal value stored is a  'EE'X,  but
if  NCF is also installed, the field can take on almost any value.  When
the Job Reader Date field is used, UCC7 traps each  SMF  record  as  its
being  written  and  clears out the high order byte.  Unfortunately, the
trap uses a table of SMF record IDs, and records  which  UCC7  does  not
know about (such as the type 60, 61, 65, 66, 78, 80 and all user records
such as ACF2) are passed into the SMF file with an invalid reader  date.
The result is a missing value for READTIME for these UCC7 controlled job
records.  Pages 2 and 9 of the UCC7  Installation  Guide  discuss  these
options,  and  UCCEL  technical  support has the fix for the 60's and 80
records, as well as advice for handling user SMF records.  If the record
has the Reader Date in the "standard" location (bytes 27-30), the fix is
simply to add the record ID to ICMDSECT.  For records  with  relocatable
format  (like  the  type  78  record  which  can record a specific job's
virtual storage),  more  complicated  instructions  are  available  from
UCCEL.   Since  MVS  2.2  will  use the first byte of the date field for
dates  in  the  next  millenium,  UCC7  designers  are  looking  for  an
alternative.



4. Technical Notes, VM:

VM  will  not  create VBS records.  If you install MXG under CMS to read
SMF data, you cannot build  the  SMFSMALL  data  set  described  in  the
installation instructions.  Change the Filedef and the FILE statement in
UTILGETM to build  the  SMFSMALL  file  with  RECFM=VB,LRECL=32756,  and
BLKSIZE=32760  on  a  3380 disk and the program will work.  Yes, it will
not make efficient use of the disk space, but SMFSMALL is only  a  small
test file of SMF data.  VM is capable of reading VBS input tapes, so you
should have no problem processing SMF under CMS.

There are two ways to hold SPOOL data in VM so that it exists after  the
spool data is read:
    SPOOL READER HOLD             holds the reader
    CHANGE READER nnn HOLD        holds the file
Hold  only  the  reader, never hold the file, if you want the data to be
read.  The CMS Diagnose 14 Subtype 1C command which is used to read  the
monitor data in the spool skips over held files.

5. Technical Notes, SAS:

 SAS Options which you should be aware of.

  TAPECLOSE=LEAVE  should be specified on the EXEC card for MONTHBLD.
                   It leaves the input tapes as they are, and prevents
                   lots of rewinds (and mounts, for multi-volume input).
                   The SAS default is REWIND.

  FREE=CLOSE       either as a SAS option or on a DD card in a SAS job
                   interferes with the IBM STIMER routine, which is used
                   to measure SAS step CPU time. FREE=CLOSE has caused
                   unpredictable USER 999 ABENDs with the SAS error
                   message CPU TIME EXCEEDED and a large value of CPU
                   time shown on the SAS log. The value on the log is
                   wrong (see the Step Termination message to confirm)
                   but the STIMER poped and SAS shut the step down.
                   Either do not use FREE=CLOSE, or use the SAS NOSTIMER
                   option, which eliminates the problem, but will also
                   eliminate the CPU used message on the SAS log.

  NOMEMFILL        Should always be specified, MEMFILL is a SAS debug
                   developers option which should never be used, as it
                   causes a seven-fold increase in CPU time.



(3XV. CHANGES INSTALLED TO VERSION 4.4


The following changes have been made to the MXG  4.4  Library.   All  of
these changes will already be in MXG Version 5 when you receive it.

Some  of  the changes provide the code with line numbers so that you can
install the change.  Lines to be inserted have a period after  the  line
number  they  are to be inserted after.  Existing lines which need to be
changed have no period in their line number.

****************NEWSLETTER NINE*****************************************



             MXG NEWSLETTER NUMBER NINE SEPTEMBER 30, 1986

Technical Newsletter for Users of MXG :  Merrill's Expanded Guide to CPE

 This newletter accompanies the production shipment of MXG Version 4.4.

The  MXG  Newsletter is available only to supported customers of Merrill
Consultants.  Beginning with this issue, the newsletter will be  printed
in this reduced size to fit in the MXG Supplement binder.  All supported
customers will receive one copy of the binder when it is available.   At
a later time, the actual MXG Supplement itself will also be sent to each
supported site.


I. DESCRIPTION OF ENHANCEMENTS IN MXG VERSION 4.

II. TECHNICAL NOTES

          1. Considerations on where to execute MXG.
          2. Affect of PARMTZ on CICS Monitor timestamps.
          3. Use of the following colon operand.
          4. Lower bound on uncaptured MVS CPU time?
          5. Affect of increased RMF sampling rate.
          6. 3800 print start and end can overlap.
          7. TPX and PIE multiple session managers.
          8. 3090 Expanded Storage access times.
          9. Various impacting APARs and PTFs.

III. INSTALLATION INSTRUCTIONS FOR MXG

     (See included table of contents)



         COPYRIGHT (C) 1986 BY MERRILL CONSULTANTS DALLAS TEXTA

          MXG IS A REGISTERED TRADEMARK OF MERRILL CONSULTANTS




I. ENHANCEMENTS AND CHANGES TO PREVIOUSLY EXISTING PRODUCTS:


 1. Full Support for SAS Version 5 graphics and syntax.
 2. BUILDPDB/3 will delete duplicate SMF data with NODUP option.
 3. IMACPTF member handles three CICS 1.6 PTFs.
 4. RMF 3.4 & MVS 2.1.7 support (Vector Processor and 3090 Architecture)
 5. CICS 1.7 support for CMF type 110 SMF or CICS journal record.
 6. DOS/POWER Version 2 expansion and new record types.
 7. DISOSS Version 3 Release 3 Account record.
 8. DB2 Release 2 Type 100-102 records.
 9. VTAM SNA Type 50 SMF record.
10. RACF 1.7 Type 80 SMF record.
11. 3480 Tape statistics Type 21 SMF record.
12. ICF Catalog entries in Type 61,65, and 66 SMF records.


NEW PRODUCTS SUPPORTED:


 1. New installation instructions for execution under CMS.
 2. VM Monitor PERFORM, USER, and DASTAP records.
 3. IMS Log processing and analysis into transaction record.
 4. Landmark The Monitor for CICS VSAM record.
 5. INFILE exit to process Landmark's compressed record format.
 6. Cullinet IDMS Performance Monitor (formerly BST RTE) SMF record.
 7. IDMS DC Log record analysis program.
 8. ASM code to enable IDMS exit to write "MXG IDMS SMF" records.
 9. NJE BDT Type 59 SMF record.
10. ROSCOE Response time monitor records.
11. RMF System Availability Management records.
12. JES2 Spool Offload Type 24 SMF record.
13. NPDA type 37 SMF record.


The  CHANGES  section of this Newsletter provides some discussion of the
enhancements listed here, and identify the members of the  MXG  SOURCLIB
data   set  which  operate  on  the  listed  data  records.   Additional
discussion  will  be  found  in  comments  in  those  members.   Further
information on these new data sources will also be provided when the MXG
SUPPLEMENT is printed.

II. TECHNICAL NOTES

1. Considerations on where to execute MXG.

In principle, MXG code has always been executable under either CMS or OS
versions of the SAS System.  Heretofore, our support/documentation  only
instructed  the user how to install MXG under OS SAS.  In spite of that,
many sites with a system programmer who understood MVS, CMS and SAS have
had  no  appreciable  problems  installing MXG under CMS.  Version 4 now
contains installation instructions for MXG under either version of  SAS.
Once  installed,  MXG will process whatever data presented to it.

In MVS, IBM provides a utility program (the SMF dump  program)  to  copy
VSAM  SMF  data  to  a  BSAM  file  which  can be transported to any SAS
program.  SAS can also read the undumpded (VSAM) SMF file and  could  be
used to create the transportable file as well.

In  VM,  the  user had to write their own specialized "VM dump" program,
(or purchases IBM's VM MAP program), to create a transportable  file  of
VM  monitor  records to be processed by SAS.  Beginning with SAS version
5.12, the new INFILE exit named MONITOR (added by SAS Institute  at  our
request), allows SAS to similarly create a transportable file.

With MXG Version 4 and SAS 5.15, either MVS or CMS data can be processed
under either the CMS or VMS versions of SAS.  The real question becomes:
is one more appropriate than the other?

Without sounding like an MVS bigot, MVS is significantly better than CMS
in managing job streams to build and maintain SAS data bases, especially
in the areas external  to  SAS  (catalog  management,  tape  management,
physical data set location, data center operations, interfaces for ABEND
conditions, etc.).  Preliminary benchmarks  also  show  that  processing
large volumes of data under CMS is significantly more CPU-expensive than
creating SAS data bases under MVS.  CMS was never  designed  to  process
the  80 million bytes of SMF data each day from a 3081 - that is clearly
a "batch" process, and MVS batch  processing  will  always,  always,  be
cheaper and more efficient than any other processing mode.  However, the
SAS runs are made in the late hours when the processor normally is idle,
these added CPU costs may be of no concern.  Once the SAS data libraries
have been built, however, accessing SAS  data  bases  under  CMS  is  as
suitable as accessing them under TSO.

The real choice of where to execute MXG becomes an installation  choice,
which  is  likely  to be influenced by personnel preference, by the ease
with which data can be transported, etc.  I think most sites  with  both
CMS  and  MVS  will find it cost justified to maintain a SAS license for
both operating systems, to decode the raw data in the creating host, and
then  transprort SAS data (rather than raw data) to a common performance
library for both MVS and VM systems.  The cost of the second SAS license
may well be balanced by the elimination of VM MAP monthly charges.

2. Affect of PARMTZ on CICS Monitor timestamps.

The internal  time  stamps  (STRTTIME,  ENDTIME)  in  the  CICS  Monitor
Facility  record  type  110 are directly affected by the value of PARMTZ
(in SYS1.PARMLIB member PARMTZ), which sets the delta time  between  GMT
and  LOCAL  time zones.  Syntax of W,00.00.00 sets both clocks to LOCAL.
CMF uses the  GMT  clock,  so  that  if  PARMTZ  is  non-zero,  the  CMF
timestamps  will be hours different from SMFTIME.  The difference can be
even worse if console operators change clocks;  the SET GMT  clock  also
changes  the  LOCAL  clock,  but SET LOCAL clock does not change the GMT
clock.  MORAL:  PARMTZ should be W,00.00.00

3. Use of the following colon operand.

In dealing with data sets with many variables (like DB2 and VMON), don't
forget the SAS syntax to easily select some variables for printing using
the  colon  operand.   PROC PRINT DATA=DB2STAT0;  VAR QB:  ;  will cause
only variables starting with QB to be printed.

4. Lower bound on uncaptured MVS CPU time?

One site has noted that the PCTOVHTM  in  RMFINTRV  is  about  27%  when
MVS/XA  is  well tuned, but that higher values indicate either a lack of
tuning, or that excess capacity exists (i.e.,  low  utilization  effects
cause  the  higher  uncaptured  CPU time.  After each new release of MVS
over the past 8 years, the PCTOVHTM jumps up  to  33-38%  in  the  early
weeks,  and  as  the  release settles down, the PCTOVHTM settles down to
27%, and was never less.

5. Affect of increased RMF sampling rate.

One  site  decreased  the  RMF  interval  so  that the record write rate
increased from 1 per hour to 12 per hour and inadvertently increased the
sample  rate.   PCTOVHTM (uncaptured CPU) increased from 27% to 33%, and
PCTCPUBY increased from 93%  to  99.9%.   When  the  sampling  rate  was
decreased  back  to the original rate of 1 per second, overhead returned
to the 27-28% range, even though 12 times as  many  records  were  being
written.

6. 3800 print start and end can overlap.

The PRINTIME and PRENTIME variables in TYPE6 can overlap on 3800's.  The
Print  Endtime  (PRENTIME)  is  not  timestamped until the print file is
moved to the stacker, but the next file printed on the same 3800 printer
shows  a  Print Startime (PRINTIME) earlier than the end of the previous
print file.  A JES Display command will often show  2-3  different  jobs
active on the same 3800 printer!

7. TPX and PIE multiple session managers.

Sites with multiple session managers TPX and PIE have observed that

   TPX - Requires multiple TSO IDs to multi-task. (You log on to TPX
         ASID which then passes you to APPLID). Since it is an extra
         ASID, a page fault in the TPX address space WAITS all users.
         TPX, therefore, probably should be Storage Isolated.

   PIE - Is its own TMP, attaches TSO, and can thus multi-task TSO
         functions. A pass thru to CICS will cost two swaps, a
         Detected Wait Out, then In.

8. 3090 Expanded Storage access times.

Some  measurements  of the 3090 Expanded Storage show the average access
time is 30-35 microsec, 60 microsec worst case with  lots  of  activity,
and a 10 microsec minimum access per 4K block.

9. Various APARs and PTFs you may want to look up:

   OZ78130 - DISP=MOD with IFASMFDP (SMF Dump program) sometimes does
   OZ96195   not catalog 2nd or 3rd tape volume serial. You get an SVC
             dump with the IFASMFDP execution, and the next MOD run
             gives you an A13 abend.

   OZ97886 - DFP 2.1 on 8603 counts only Demand Mounts in type 30

   OZ97997 - RMF reports for virtual storage show time before start of
             RMF interval. (This was one we found).

   OZ83743 - 0C4 in SMF writer after 8603, records all wrong. PTFs are
             UZ48891 (JBB2214), UZ48888 (JBB2110) or UZ48890 (JBB2133).

   WSC Flash 8633-1 discusses DB2 CPU accounting changes in Release 2.

****************NEWSLETTER ONE*TWO*THREE*FOUR*FIVE*SIX*SEVEN*EIGHT******

   CONSOLIDATION OF IMPORTANT INFORMATION IN MXG NEWSLETTERS 1 THRU 8

This consolidation for new MXG supported customers will be replaced by
the MXG Supplement, to be printed in early 1987.  Only the portions of
newsletters ONE thru EIGHT which are still relevant are included herein.
Newsletter Nine  was either received with Version 4.4 when MXG was
purchased from SAS Institute, or is included in the separate package
from Merrill Consultants with the  (empty) 3-ring  binder for the
Supplement.  Complete version-by-version changes are in the MXG
software, members CHANGEnn, and in members DOC....  BWM:3Feb87.


               MXG NEWSLETTER VOLUME I NUMBER THREE OCT 1, 1984


2. Technical Information

a.  3800-3 Printer:  A number of new variables were added to data set
TYPE6 to support the 3800-3 printer.  Most welcome is DOCLENFT, the
length (in feet) of the document printed.  This value has been requested
since 3800's  were  first announced,  and  it  should  permit accurate
cost recovery of 3800 paper.  The form number was also expanded to eight
bytes (in TYPE6  FORM,  and  in  TYPE26 OUTFORM).  The 3800-3 is
supported in Version ONE of MXG.

b.   CICS  1.6.1:  Changes in transaction data (CICSTRAN) now provide
separate counts of message characters input and  output,  separately
for  primary  and secondary  sources,  which  will  improve  the
measurement data for modelers.  Status bits were added to identify
transactions which were active when  either short  on  storage
(SHRTSTOR) or maximum task (MAXTASK) conditions occurred so that these
potentially delayed transactions can be excluded from response time
analysis.   Program  storage  used  was  also  added, and now the CICS
Monitor Facility (CMF) data completely maps all data which was formerly
available  in the  Performance  Analyzer II product for transaction
analysis.  In the global system data (CICSYSTM) the amount of storage
deleted  by  dynamic  compression each  interval (PROGCOMP) is provided.
The shock of 1.6.1 was massive, as the CMF version number was not
changed between 1.6.0  and  1.6.1.   The  MXG  Code determines  the
release  by  the order and number of variables in the record.  MXG
Version ONE supported CICS 1.6.1.





    Copyright (c) 1984,1985,1986,1987 Merrill Consultants, Dallas Texas
             MXG is a registered trademark of Merrill Consultants


c.   MVS/XA  Version 1.2:  The region requested was increased from two
to four bytes, and is now in variable REGREQST.  Its predecessor,
PVTAREA, will  still exist  but will have zero value.  MXG Version ONE
supports MVS/XA Version 1.2.



3. IBM APARs/PTFs Affecting Performance or Data


APAR  0Z75374  AND  PTF  UZ70647 - under MVS/XA at Release 2.1.2,
artificially high EXCP counts will be stored in Type 14 and 15 SMF
records.  The PTF is  on PUT tape 8404.

APAR OZ77211 and PTF UZ72177 - Causes invalid data in type 30.  When
more than about 1407 DD segments occur, a second Type 30  record  is
written  with  the additional  DD  segments.   This second record seems
to have the device class, device type, and sometimes device number
invalid,  frequently  containing  hex zeros.   (An  MXG  message  on the
log occurs if a DD segment contains nonzero EXCP count.)

APAR AZ74030 and AP97757 - problems with CICS CMF Type 110 SMF records
at  two sites  were  reported  to have gone away when these APARS were
installed.  The first APAR deals with CMF problems when MRO is active,
and apparently required the second APAR as a prereq.

PTF  PP11730  - CICS Monitor Facility (CMF) records have invalid second
header whenever the data in a series of Account Class segments exceeded
2048  bytes.  This invalid segment is recognized and skipped in the MXG
Software.

APAR PP26559 and PTF UP43991 - CICS Monitor Facility under CICS 1.6.1
response times are all believed to be invalid without this PTF  which
fixes  incorrect values for terminal control wait time (WTTCIOTM).  The
fix is on 8405.

PTF  PP34408 - CICS Monitor Facility under CICS 1.6.1 with this PTF
reportedly causes bad data values.


4. MXG Software Information

a.  Conversion Differences Between the Original Merrill's Guide and MXG

Considerable effort was taken to preserve the names of variables and
data sets in  MXG  so  that  users  of  the original Guide would not
have to alter their report programs.  There are only a few areas  in
which  these  changes  might require recoding of your original report
programs.

   i.  TYPE71 RMF paging variables originally  contained  the  total
   page counts  for  the  interval.  As a result, report programs had to
   divide the paging values by DURATM to calculate paging rates.   MXG
   corrected this original design error and calculates paging and
   swapping variables as rates (pages per second).

   ii.   JOBS  data  set originally used variable JOB_TSO to
   differentiate between jobs and TSO sessions.  Now, with SMF data  for
   started  tasks TYPETASK  replaces  JOB_TSO, and provides more
   complete classification.  TYPETASK exists in the STEPS, JOBS and
   TYPE30_x data sets.

   iii.   For  multi-processors,  TYPE70   originally   created
   multiple observations  for  each  Type  70 record, one observation
   per "engine".  MXG simplifies the data by  creating  a  single
   observation  for  each interval,  which  contains overall CPU busy
   for all processors, as well as PCTCPBY0, 1, 2, and 3 for each
   possible processor.

   iv.   Type 30 records originally created a single data set, TYPE30.
   To reduce the disk space required by having all SAS  variables  for
   every observation,   MXG  builds  separate  data  sets  (TYPE30_1,
   TYPE30_4, TYPE30_5, etc.), keeping only the appropriate variables.

b.  Specify SYNC in PARMLIB for RMF Synchronization

The RMFINTRV data set summarizes RMF  data  into  a  user-specified
interval.  Records  written  at short intervals can be combined into
longer intervals for analysis.  RMFINTRV requires that SYNC was
specified (the default  is  NOSYNC) in  SYS1.PARMLIB.   SYNC  causes
RMF records to be synchronized with the wall clock, and must be
specified.



   iv. Typographic corrections to the Book

   p. 217. In code, replace RPTCICS (twice) with ANALCICS.
   p. 309. In code, replace MGX (twice) with MXG.
   p. 316. In 2nd paragraph of text, JCLTEXT should be JCLTEST.
   p. 316. In last example, SOURCELIB should be SOURCLIB (twice).
   p. 322. In 3rd line from bottom, TEXT DD should be TEST DD.
   p. 371. Under SMF manual third line, the TNL is GN28 vice GN25
   p. 373. 2nd entry, change Henning to Hemming.
   p. 496. TIOESTTA bit 7 DASD, change dtaa to data.
   p. 597. Penultimate line, change IMACINTY to IMACINTV.
   p. 808. Text under CMD, change MG080CM to MG090CM.
   p. 815. Remove line referring to JCLDBANL.


              MXG NEWSLETTER VOLUME I NUMBER FOUR APRIL 1, 1985


Many  users  have  directly  contributed  to  these  enhancements,
either  by reporting  problems,  making  suggestions,  supplying raw SMF
records for code validation, or even by  providing  SAS  code  for
inclusion.   These  friends receive  our  sincere  thanks,  and  their
contributions are identified in the member CHANGES. Additional
documentation often can be found in the comments at the beginning of the
module.

              MXG NEWSLETTER VOLUME I NUMBER FIVE JULY 5, 1985



2. IBM APARs/PTFs affecting performance or data.

  a. High CPU utilization by CICS noted after installing CICS 1.6.1  can
     result  from  two  options.  The VTAM High Performance Option (HPO)
     defaults to off (NOHPO), which does cause excess  CPU  consumption.
     Additionally,  the  FETRACE option always comes up active.  FETRACE
     can be temporarily disabled by the console command CSFE FETRACE,OFF
     or  permanently by APAR PP20143.  This is probably common knowledge
     among experienced CICS tuners.

  b. SMF data destroyed at IPL.  The SMF writer locates the  last  block
     in  the active SMF data set, but then overwrites it with the type 0
     record.  See APAR OZ85729.

  c. SMF task ABENDs with 0C4 due to incorrect handling of a cross memor
     post.  PTF UZ79645.

  d. DB2 data invalid.  Three fields are overlaid.  APAR is PP42547, the
     fix is PTF UP59374.


3. Technical Information

  a. The type 78 data on virtual storage usage in TYPE78VS and  TYPE78PA
     data  sets is sampled at one tenth of the normal RMF sampling rate.
     This is why variable NRSAMPLE in these data sets is  one-tenth that
     in other RMF data sets.

  b. The  Global  Resource  Serialization (GRS) address space requires a
     significant amount of real memory unless GRS is placed in a control
     performance  group (by specifying it either in SYS1.PARMLIB or with
     the PERFORM keyword).


              MXG NEWSLETTER VOLUME I NUMBER SIX OCTOBER 25, 1985


I.  MXG SOFTWARE INFORMATION

    A.  OVERVIEW OF ENHANCEMENTS IN MXG VERSION 3.


 An enhancement to RMF required by MVS 2.1.3 or 3090's.  Major items:

 SWAP  counts  by  type (SWAPUS, SWAPDW, etc) are now expanded with five
 added variables (use of Extended Storage) for each swap type in TYPE71.

 SU_SEC constant is now in the TYPE72 record, eliminating table lookup
 in MXG.

 IO  measurement  is different.  The TYPE78CF data set, formerly only a
 static tabulation of the configuration, now contains  IO
 utilization/queueing  data for  the  CHPID.   Two  new data sets,
 TYPE78CU and TYPE78IO now describe the utilization/queueing for the
 CUHDR and  IOP  initiative  queues.   TYPE74  now contains three
 components of DEVPNDTM.  We plan a future enhancement to merge this IO
 data for better analysis.  The documentation for both type 71 and  78
 records is seriously wrong in the SMF manual.

    D.  DOCUMENTATION OF CHANGES AND ENHANCEMENTS.

 Changes and enhancements are documented in the Version  3  SOURCLIB
 library.  Member  CHANGES  of  the  library  describes  the changes and
 enhancements in between the present  and  prior  versions.   Member
 CHANGE02  describes  the changes  between  Version  1 and Version 2.
 Similarly, DOCVER02 and DOCVER03 members of the library contain the
 documentation of the  variables  and  data sets  new  with that
 version.  We plan to continue this philosophy and naming convention.
 See section 4, below.

3.  TECHNICAL NOTES

    A.  EXECUTION OF MVS UNDER VM CAUSES TYPE78 DATA TO BE MISSING.

 To construct the configuration and recording of TYPE78 data,  RMF  must
 read the  IOCDS  data  set.  Under VM, IOCDS is not available to MVS
 and thus some type 78 records will not exist when MXG executes under
 VM.

    B.  FIELD SIZES EXPANDED IN RMF.

 MVS 2.1.3 shows some foresight for the future.   Several  formerly  one
 byte counters  have  been expanded to two bytes, suggesting that IBM
 sees the need for more than 16 of them.  Fields noted  are  number  of
 LCU's,  LCUID,  and several   workload   variables   such   as   the
 minimum  and  maximum  MPL, Multi-Programming Level, and SRM values for
 WEIGHT, AOBJ, DOBJ, and DFWK.

    C.  CONCATENATED %INCLUDED LIBRARIES.

 If your source libraries have different blocksizes, you may  create
 trouble.  SAS  currently  requires  that  concatenated source libraries
 with dissimilar blocksizes which are read with %INCLUDE, must specify
 DCB=BLKSIZE=largest  on the  first  DD  of  the  concatenation.  If the
 blocksize increases above the blocksize of the first DD, a loss  of
 source  lines  will  occur,  hopefully causing a syntax error.

    E.  TYPE74 VARIABLES CHANGED BETWEEN MVS/370 AND MVS/XA

 Because device usage under MVS/XA is recorded differently, more
 accurately, and by built-in hardware monitors, the MVS/370 variable
 DEVBUSY in TYPE74 is missing under MVS/XA and the new variable PCTDVUSE
 should be used. It provides a better measure of utilization - the
 percentage of the interval when the volume was not available to another
 task.

    A.  ENHANCEMENTS TO EXISTING MXG DATA SETS

        1.  TYPE6

 Support for the new restructured type 6 record from both JES2 and JES3.
 See Washington  Systems Center Flash bulletin WSCF-8518 for the PTFs
 which create these new formats.  New variables BINUSED, DUPLXUSE, and
 SHEETPRN  added  for 3820 printer were added.

        2. TYPE71

 RMF 3.3 expanded storage adds several new variables:

                     PGMVTOEX PGMIEXAU  dealing with page movement
                     AVLEXTMN,MX,AV     for available extended storage
                     HIUICMN,MX,AV      for HIUIC value
                     MIGAGEMN,MX,AV     for Migration Age
                     EXTFRMIN, EXTFRMON for installed and online frames

 There  are  now  five  new  variables  for  each  of  the  swap  reason
 codes (TO,TI,WT,AS,RS,DW,VR,NQ,EX,US,NS):

                     PHYAUXxx      Physical to Auxiliary
                     LOGEXTxx      Logical to Extended
                     LOGAUXxx      Logical to Auxiliary
                     PHYEXTxx      Physical to Extended
                     EXTAUXxx      Extended to Auxiliary

 where xx is one of the SWAP reason codes.

        3.  TYPE72

 Variables RESPAVG and RESPSTD, average and  standard  deviation  of
 response time  per  ended  transaction were added stored by IBM in the
 type 72 record, eliminating the table lookup, and more important,
 eliminating  the  need  for table maintenance every time you install a
 new CPU.

        4.  TYPE74

 Changes due to RMF 3.3 and enhancements

 Three  components  of  pending  time, PCTDVPND, are now measured in
 three new variables, PCTPNCUB PCTPNDEV PCTPNOTH are the percent of
 pending  time  which is attributable to the Control Unit, Device, or
 remainder.

 MXG variable OVERFLOW was split into two variables, OVFLOCON and
 OVFLODIS for 308x.   (Hardware  counters  in  309x  and  4381  are
 4-bytes,   essentially eliminating the problem of overflow).

        5.  TYPE76

 Omissions corrected and new variables AVG and INTRVAVG are created.

        6.  TYPE78CF

 Enhancements due to RMF 3.3:  This  data  set  formerly  contained
 only  the static data describing the physical configuration.  With RMF
 3.3, the rate at which this channel path (CHPID) was taken and the
 percent  when  the  Control Unit was busy and CHPID path busy are
 recorded.  As a result, TYPE78CF is now created by BUILDPDB.  Variables
 CHPIDTKN, PCTCUBSY and PCTPTHBY were created.

        7.  TYPEDB2

 DB2  type  100  and  101  records introduced in Version 2 had logic
 errors in processing IFCID and ASID segments of the type 100  subtype
 0  (MXG  dataset DB2STAT0) fixed.  New variable QBACRIO, read requests,
 found in DB2ACCT.  See DOCVER03 for details.

        8.  TYPETSOM

 Support for Release 4.3 of the TSO/MON Product.  TSOMCALL variable
 PANELCNT, SPF  panel count was added.  Seven new TSOMSYST variables
 added, included the new estimated Network Delay Time per transaction,
 NETDLYTM.


   B. NEW MXG DATA SETS

        1.  TYPE22_9      Extended  Storage  Configuration.

 Like  all type 22's, it describes the configuration.  The subtype 9
 describes how much extended storage is installed.

        2.  TYPE39        Network Logical Data Manager Release 3

 Support for the Network Logical Data Manager, NLDM Release 3,  which
 creates type  39  SMF  records  is provided in the several TYPE39 data
 sets described below.  More information is described in  NLDM
 Operation,  SC30-3165-2.   Of particular  interest is the capture by
 NLDM of the response times captured by the 3274 control units.

                  TYPE39_1 - RTM Collection Record
                  TYPE39_2 - Session End Record
                  TYPE39_3 - Session Start Record
                  TYPE39_4 - Accounting and Availability Data Record
                  TYPE39_5 - Combined Record
                  TYPE39_6 - Bind Failure Record
                  TYPE39EL - Route Element Table

        3.  TYPE78CU      RMF  3.3 Control Unit - Header Queue, CUHDR

 Describes the Control Unit - Header Queue, CUHDR, with queue length and
 rate.  When  all  paths to the subchannel are busy for an LCU, and at
 least one path to the control unit is busy, IOP places an IO on the
 CU-HDR queue.

        4.  TYPE78IO      RMF 3.3 IOP Initiative Queue.

 Describes the Input/Output Processor, IOP, initiative queue statistics.

        5.  TYPEDISO      DISOSS Accounting Log Record.

 Data  set  DISOACCT (name not TYPE....  because it is not created from
 an SMF record) is created from the  DISOSS  log.   See  technical
 note,  above,  or DOCVER03.

    D.  ADDITIONAL COMMENTS

        1.  BUILDPDB and BUILDPD3

 Several enhancements made to BUILDPDB/BUILDPD3.

 a.   ABEND and CONDCODE in the JOBS data set is now the job completion
 status for the last job termination (subtype 5) record.  Formerly, it
 was  the  last step  termination  and was misleading (i.e., ABEND would
 be FLUSH in PDB.JOBS for a job whose last step was flushed due to the
 ABEND in a prior step).

 b.  EXCP and IOTM for tapes 3420 and 3480 added.

 c.  Data sets TYPE78CF, TYPE78CU, and TYPE78IO are now created  in  the
 PDB.  All three are physically small.

        2.  FORMATS

 New format, MG078CV.  converts byte values to Kilo or Mega bytes, with
 K or M suffix.  Makes the data in TYPE78VS (virtual storage) easily
 read.   Try  it with any variable in our data sets.  We also use it in
 TYPE30 data sets.

        4.  RMFINTRV

 LABELS  were  enhanced  to  reflect that many variables are rates per
 second.  Labels for variables ending with SWAP, TRAN, EXCP, IOTM, ACTV,
 RESD, and SERV now have "per second" in their label.

        6.  TYPE30_4

 The calculation of ALOCTIME and LOADTIME in TYPE30_4 were corrected
 (as  had been done in TYPE434) to add a day if the job allocation/load
 time of day was less than the initiate time of day, i.e., for jobs
 which initiated today  and allocated/loaded after midnight.

        7. TYPE30_4, TYPE30_5, and  TYPE434

 Return  code  values  are  limited by IBM to 4096, but with a two byte
 field, some accounting packages use the upper bits for  their  own
 purposes.   This caused return codes greater than 4096.  The MOD
 function now returns only the real return code set by the programmer.

        8.  VMAC7072

 The  _VAR70  ARRAY  in  processing  type  70 records was replaced with
 direct assignment after a European customer first noted a  significant
 increase  in CPU  time  of  MXG  (140  seconds)  when  compared  to
 the original code (84 seconds).  The ARRAY was more CPU costly than
 direct  assignments,  and  had been used only as shorthand.

        9.  X-named members

 All MXG modules beginning with  the  letter  X  are  "extra's".   Their
 only documentation  is  the  member itself, and these members are not
 supported at the present time.  They may not necessarily work.  Some
 might  eventually  be upgraded to supported.

       10.  XTYPEVS1

 This module partially decodes SMF record types 0, 1, 4, 5, 7, 12, 20,
 34, and 35 from the OS/VS1 operating system.  It now executes, after
 removal  of  an unnecessary  %INCLUDE  and  proper calculation of NUMDD
 to make it usable for VS1 data records.  If there is enough demand, we
 will upgrade it with labels, re-structure  it  and  enhance  it  into
 a  supported member.  The variables created are already described in
 the corresponding sections of Chapter 40.

      *****************************************************************
      *                                                               *
      * This  product  could not exist as it is without the wonderful *
      * user community with whom we work.  Your  calls  and  letters, *
      * sometimes  with  dumps and sometimes with data tapes, provide *
      * us with opportunities to detect our errors and to protect our *
      * code (and your sleep!) from interruptions.                    *
      *                                                               *
      *****************************************************************

              MXG NEWSLETTER VOLUME I NUMBER EIGHT MAY 23, 1986

    Major items in Version 4.1, available upon request.

    1.New module IMACPTF. Presently used only for CICS SMF records,
      this new maintenance feature makes it easier when you install
      IBM PTFs. If we knew about the PTF at shipment time, it will be
      in this module, and by enabling the PTF MACRO in this module, you
      enable MXG code to process the changes.
      ALWAYS BROWSE IMACPTF with each new tape.
    2.Support for CICS 1.7 has been added to VMAC110 code. Note that
      new program UTILCICS is usable for either 1.6 and 1.7 to help
      decifer what PTFs are installed, so you can update IMACPTF.
    3.MVS 2.1.5/RMF 3.4 support. This includes all changes in the MXG
      Newsletter number 7 and later. This also corrects several minor
      errors in data sets new with RMF 3.3.
    4.PRE-RELEASE MXG IMSLOG CODE enhancement (TYPEIMS). See member.
    5.Revised ANALTAPE routine.
    6.MODEL204 accounting information defaults on (EXM24ACT).
    7.New member INSTALL with instructions for installation of MXG,
      both new and replacement, as well as under MVS or VM. Please
      use this member to install this version, and advise if the
      instructions are not clear.
    8.PRE-RELEASE processing of VM Monitor records directly with SAS
      CMS Maintenance Release - not completely validated (TYPEVMON).
    9.NODUP option implemented in BUILDPDB/3 to remove duplicate SMF
      input data from PDB data sets. (Requires enabling after you have
      installed the pre-requisite SAS maintenance release).
   10.Too much more to list here. Read member CHANGES.

       The MXG SUPPLEMENT will be automatically sent to supported sites,
       as a special edition of the MXG Newsletter.  Future Newsletters
       will be in the same font and size to be inserted in binder for
       the MXG SUPPLEMENT.
====THIS IS THE LAST LINE OF MEMBER NEWSLETTERS=================