10. MODIFICATION › 10.1 Parameter Modification › 10.1.2 Incremental Update Considerations

10.1.2 Incremental Update Considerations

If you are using the TAPEfff option or USRXfff exits to
collect detail level data, and incremental update is active,
you may need to make a few simple but very important
adjustments to your exits or options to accommodate the way
that incremental update processes data.

This section discusses the following:

USRXfff exit considerations with incremental update:

o  DETAIL tape files created in USRXfff exits
o  DASD files created in USRXfff exits


USRXfff EXIT CONSIDERATIONS WITH INCREMENTAL UPDATE

  The USRXfff exits allow client supplied code to force the
  creation of SAS files containing DETAIL level data.  These
  exits were provided for specific high volume transaction
  based data that are populated at the DAYS and higher
  timespans in a summarized form in CA MICS.  Due to the high
  volume of data involved, these exits may be used to create
  tape files, although nothing other than space
  considerations precludes creation of files on DASD with
  these exits.

  Many of the products that provide USRXfff exits have
  implemented standardized approaches to collect DETAIL level
  data, thus removing the need for USRXfff exit coding.  Any
  user code employed in USRXfff exits should be examined to
  ensure that the data and the approach are still required.
  Generally, transaction data at this level is employed for
  specific tuning projects or special studies centered on
  subsystem or application related issues and is needed only
  for occasional and isolated time periods.

  If you are using incremental update and find that the
  USRXfff exits you have coded are still required for your
  operation, be sure to review the considerations below.

  DETAIL TAPE FILES CREATED IN USRXfff EXITS

    When using the exits to write to tape without incremental
    update activated, a single tape file is created from the
    user written code in each activated USRXfff exit.  The
    general practice is to use generation data groups (GDGs)
    to retain history.  In this case, it is assumed that
    CA MICS units are updated once a day with yesterday's
    data.  Without incremental update the generation 0 (+0)
    tape data set would contain data from the previous
    CA MICS update (yesterday), (-1) contains the prior run
    (two days ago), and so on.

    With incremental update, a tape file is again created
    from the user written code in each activated USRXfff exit
    with each execution of an update.  However, rather than
    running CA MICS updates once per day, incremental update
    implies multiple update runs daily.  For example, three
    incremental updates followed by a final daily update run
    result in a total of four tapes in one day, one created
    from each activated USRXfff exit.  Each tape contains
    only the detail data encountered during the individual
    incremental update or daily run.  If you are employing
    GDGs you will want to evaluate increasing the number of
    generations to encompass the desired time range of
    history.  For example, if previously 7 "daily"
    generations were maintained and you ran 4 increments per
    day, you may wish to expand the generations kept to 28 (7
    times 4 updates per day).

    The use of fewer tapes in a single update under the
    incremental feature expedites processing.  In addition,
    in keeping with the "special study" nature of the data,
    separation of the data into multiple pieces representing
    the narrower period slices should simplify usage.  That
    is, the data is already subset to the period contained
    within the update.

    You also may consider creating a standalone job to
    consolidate these individual tapes into a single one
    after the DAILY job completes if you prefer to have a
    single tape data set contain all transactions for the
    time range.

  DASD FILES CREATED IN USRXfff EXITS

    Either of two basic approaches may be employed when using
    the exits to write to DASD files.  Data can be written to
    detail data set(s) of CA MICS units.   Or it can be
    written to data sets allocated externally to the CA MICS
    units (such as a user data set that has been added to the
    Daily JCL stream).  In either scenario the SAS file
    written by the exit will be replaced by new data with
    each execution of the update step.

    If the exit is writing to the CA MICS Detail data set and
    the recommended approach has been taken with the exit
    then no change to outputs will occur under incremental
    update.  The recommended approach employs indirect coding
    to reference the database (uses "&iiit" not "DETAIL" in
    the data step) and an active detail status (file status
    of "Y" at the detail timespan in cccGENIN and cccCGEN has
    been executed).  When these conditions are in place the
    file created by the exit will be treated as other CA MICS
    files in incremental update mode and at the conclusion of
    the Daily job stream a single file containing data from
    all increments will be available in the detail unit
    database.  If the file status is not active, only data
    from the last incremental execution will be present.

    An alternative to selective exit coding is to employ a
    generation data set (GDG) structure for the external DASD
    file. In this scenario GDG entries to cover the
    incremental updates would be defined and each incremental
    run would write to a new GDG entry which would contain
    data for the increment.  Each series of incremental runs
    followed by a DAILY job execution would create a new
    series of GDG data sets.  While this approach allows you
    to capture all data on an ongoing basis, use of the unit
    detail data set as described above is more efficient and
    is the recommended approach.