How to refresh replicated user-maintained data tables

The following steps describe how to set up an environment to refresh replicated UMTs. In practice, you may already have some of this in place. For example, you may already have files defined as data tables. The steps described here assume that you already have a sysplex environment.

Select a file that is appropriate.
As an illustration, consider an application that checks credit card numbers against a list of stolen credit cards, and requires rapid access to this list. The list is updated periodically with new batches of numbers of stolen cards. The application accesses records in a VSAM KSDS data set named PRODN.SOURCEDS using a filename UMTNAME. The application runs in a sysplex consisting of two MVS™ images. CICS® regions CICS1A, CICS1B, and CICS1C run in the first image, and CICS2A, CICS2B and CICS2C run in the second.
Set up file definitions:
- In each MVS in the sysplex, select a CICS region to be the shared data table server for this file. Within this region, define the filename by which your applications read the data as a user-maintained data table, with the data set name as that containing the source data.
  In this illustration, CICS1A and CICS2A are set up as the server regions, and files are defined to them called UMTNAME. The file definitions specify DSNAME as PRODN.SOURCEDS, TABLE as USER, and allowed operations of YES for READ, BROWSE, ADD, DELETE and UPDATE (because this file definition is used both for reading the data and for updating the UMT when it is refreshed).
- For all the other regions in the sysplex, define the filename by which the applications read the data as a remote file with the REMOTESYSTEM as the shared data table server region in the same MVS, and the REMOTENAME as the name of the UMT in that region.
  So, in this illustration, files called UMTNAME would be defined in CICS1B and CICS1C with the REMOTESYSTEM as the sysid for CICS1A and the REMOTENAME as UMTNAME, this time with READ and BROWSE as the only allowed operations, because there is no need for the UMT to be updated through these remote definitions. Similar file definitions are set up in CICS2B and CICS2C, but for these CICS2A is the remote system.
- In each shared data table server region, set up a file definition that can be used to read the source data set when the UMTs are refreshed.
  In this illustration, files named SOURCEDS are defined to CICS1A and CICS2A, with the DSNAME as PRODN.SOURCEDS, TABLE as NO, and allowing only READ and BROWSE operations.
- In one region in the sysplex (which has access to the source data set), define a file that is used to apply updates to the source. The file definition could be the same as that used by the refresh program to read the source data set, but in this case it would need to allow both reading and updating operations. You might, if you prefer, decide to update the data set using a batch program, in which case this CICS file definition would not be needed.
  This illustration uses the same file definition as is used in refreshing the UMTs. In this case, one of the regions would need to define SOURCEDS as allowing all file operations.
Set up the source data set so that it can be accessed by all applications that need to read or update it.
If you have DFSMS/MVSversion 1 release 3, you can access the data set from any CICS region for reading or updating by specifying RLSACCESS(Yes) in the file definitions. Note that, if you use RLS access mode, unless the data set is non-recoverable, you cannot apply the updates to it from a batch program (because only CICS can open a recoverable data set for update in RLS mode).

If you are at an earlier release of DFSMS/MVS, you can set up the data set SHAREOPTIONS so that it can be updated by the program that applies updates to the source, and read by all others. Alternatively, you can set up the data set so that it can be updated only when it is not being read, and ensure that its opening is serialized. For the shareoptions to operate throughout the sysplex, you must use GRS (Global Resource Serialization).
In this illustration, if RLS is not available, define PRODN.SOURCEDS either with:
- SHR(2), so that it can be updated by the region that runs the program that applies changes to the data set and at the same time read by all the refresh programs,
or
- SHR(1), and normally have it open to the program that applies changes; then, when it is to be refreshed, close that access to it, and, on each server region in turn, open it, run the refresh program, and close disable it to allow the next region to open it.
Modify the example program so that it names your files for the UMT and the source data set, and so that the data definitions match the layout of your records. Define the program and transaction in your server regions.
The file names in the illustration are the same as those in the program (UMTNAME and SOURCEDS). Define the program and a transaction to run it in CICS1A and CICS2A.
You should now be ready to start using the replicated UMTs.
Prime the source data set with its initial contents.
Open the UMTs in the shared data table server regions, to cause the contents of the source data set to be loaded into each one.
Start the applications in all regions in the sysplex. They will all be able to access the data using data table sharing.
The applications running in MVS 1 will access the data through the UMT in CICS1A, and those running in MVS 2 will access it through the UMT in CICS2A.
When new data arrives, update the source data set.
In this illustration, the data is updated by file SOURCEDS.
When you want the applications to access the new data, run the transactions in each server region that will read the source data set and the UMT, and refresh the latter to be in step with the former. Providing your applications are not invalidated if the data seen on one MVS is slightly different from that seen on another, you do not have to stop them running while you do the refresh.