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.

  1. 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.

  2. Set up file definitions:
  3. 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:

    or

  4. 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.

  5. You should now be ready to start using the replicated UMTs.
  6. Prime the source data set with its initial contents.
  7. Open the UMTs in the SDT server regions, to cause the contents of the source data set to be loaded into each one.
  8. Start up the applications in all regions in the sysplex. They will all be able to access the data using SDT 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.

  9. When new data arrives, update the source data set.

    In this illustration, the data is updated by file SOURCEDS.

  10. 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.

Related concepts
Using shared data tables support in a sysplex
Overview of shared data tables support in a sysplex
Example program for refreshing a user-maintained data table
Source code for the example program to refresh a replicated user-maintained data table
[[ Contents Previous Page | Next Page Index ]]