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