To help you write your own program, Figure 10 shows an example of a COBOL program that demonstrates how to refresh a UMT while it is still open, to match the source data set.
If updates are applied frequently to the source data set, and could be applied while the refresh program is running, this could mean that the source data set is never exactly reflected by the UMT, because the record being processed or records already processed could be changed. This means that the program has to be tolerant to the possibility of the records changing. The program is also written to allow for the possibility that the UMT itself is updated by other programs, although you are not recommended to operate in this way (that is, the only program that updates the UMT should be the refresh program).
Edit the program, according to the comments in the example, to match the format of the records being updated. 'UMTNAME' and 'SOURCEDS' should be renamed to match your file definitions.
Translate, compile and link the program using a COBOL compiler.
Define the program to CICS®, and define a transaction to the program. Define the file (UMTNAME) to point to the UMT, and give it a source data set from which to load when first opened. Define the other file (SOURCEDS) to point directly to the source data set the UMT is defined to load from.
Each sysplex should have one CICS region where the UMT that is to be refreshed resides. In these regions, the definitions needed to run the refresh transaction must be installed. In all other regions in the sysplex, the UMT should be defined as a remote file, pointing to the UMT in the UMT-owning region. It is not necessary to run the refresh transaction on the regions that have the UMT defined as remote.
The update strategy used will depend on the way the source data set is set up. If the source data set is set up as RLS, all UMTs can be refreshed at the same time. Any updates to the source data set could also be applied. If the data set has the SHAREOPTIONS set so that it can be read by multiple systems at any one time, then, as with RLS, a simultaneous refresh can also occur. Otherwise, when the source data set is updated, the file that is used to read the source data set for refreshing would need to be closed and disabled on each system for the duration of the update. If all the UMTs are refreshed serially, the source data set could be opened and closed to each UMT-owning region in turn when needed for update.
First, the environment is initialized. A check is made that the UMT file is local and is already open. If the UMT file is remote, the program issues a message and ends. If the UMT file is not open, the program opens it and ends (because opening the UMT will load the latest data from the source data set without the need to perform any more processing). A check is also made that the source file is local; if it is remote, the program issues a message and ends. The file that directly accesses the UMT's source data set is opened. Start browse operations are then performed on both files to allow the program to step through them both sequentially.
If the environment is set up without error, the update of the UMT starts. This involves the retrieval and comparison of pairs of records, one from the UMT and one from the base data set.
The records retrieved are compared:
If a record must be added to the UMT, a write operation is performed.
If a record must be deleted from the UMT, a delete operation is performed.
If a record must be updated in the UMT, a read for update operation is performed, to get a lock on the record.
When the end of both files has been reached, and there are no more records left to process, the program performs end browses on both the data set and the UMT and returns. Note that the example does not close the file that directly accesses the data set. If the data set cannot operate for update in a shared environment, the file that accesses it should be set to CLOSED DISABLED to allow it to be updated.
The program traps any unexpected errors and issues an error message on the screen. Only the first operation on the UMT is checked (either the delete, write or read/rewrite operations). If that fails with a return code that could be caused by a record being changed after it was originally read, one final attempt is made to correct the record, but this attempt is not checked. This is to prevent the program entering a loop state.
There are further comments in the code.