CICS Incremental Update Considerations

If you are using the TAPEfff option or USRXfff exits to collect detail level data, and incremental update is active, several adjustments can be required to your exits or options to accommodate the way that incremental update processes data.
rm
This section discusses the following concepts:
TAPEfff option considerations with incremental update
The TAPEfff option allows the creation of DETAIL timespan tape files for certain high volume files.
Without an incremental update, a single DETAIL timespan tape file is created for TAPEfff activated files during the DAILY run. The general practice is to use GDGs so that the (+0) tape volume contains yesterday data, (-1) contains the prior daily data, and so on.
With incremental update activated, a tape is created with each execution of an incremental update and a final tape during the DAILY update run. For example, three incremental updates followed by a final daily update run, result in a total of four tapes created, one for each TAPEfff activated file. Each tape contains only the detail data that were encountered during the individual incremental update or daily run. If you are employing GDGs, consider increasing the number of generations to encompass the desired time range of history. For example, if previously 7 "daily" generations were maintained and you run 4 increments per day, 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, due to the "special study" nature of the data, separation into multiple pieces representing period time slices should allow usage to be more direct. That is, the data are already subset to the period contained within the update.
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.
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
MICS
. Due to the high volume of data involved, these exits may be used to create tape files, although only space considerations preclude 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 following considerations.
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
MICS
units are updated once a day with yesterday data. Without incremental update the generation 0 (+0) tape data set would contain data from the previous
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
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 that are encountered during the individual incremental update or daily run. If you are employing GDGs, 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, 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 are already subset to the period contained within the update.
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 can be employed when using the exits to write to DASD files. Data can be written to detail data set(s) of
MICS
units. Or it can be written to data sets allocated externally to the
MICS
units (such as a user data set that has been added to the Daily JCL stream). In either scenario, the SAS file that is written by the exit is replaced by new data with each execution of the update step.
If the exit is writing to the
MICS
Detail data set, and the recommended approach was taken with the exit, then no change to outputs occurs 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 is treated as other
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 are defined and each incremental run writes to a new GDG entry which contains 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.