Keeping the IMS catalog in sync with the active ACB library

In IMS systems that use an ACB library, you must ensure that the IMS catalog includes metadata that matches the members in the active ACB library.

In IMS systems that manage ACBs, the IMS catalog stores the active ACBs, so it always contains the matching metadata.

Each time you update the metadata for a DBD or PSB in the IMS catalog, IMS preserves the previous copy of the metadata, so a record in the IMS catalog can contain many different copies of the metadata for the DBD or PSB. Only the copy of the metadata that matches either the active ACB member or, in some cases, the DBD member, is the current metadata.

The metadata in the IMS catalog is usually accessed by directly or indirectly issuing the DL/I GUR call, which determines which copy of the metadata is current by checking the timestamp of the ACB member that is in the active ACB library. Only the copy of the DBD or PSB metadata with the matching timestamp is returned.

For databases that have metadata that is not stored in the ACB library, such as a GSAM or logically related database, the GUR call checks the scheduled PSB for the timestamp of the DBD member. If the PSB does not reference the database then no metadata is returned and the GUR call fails with a non-zero return code and a reason code in the AIB.

Recommendation: Only the GUR call checks the timestamps. Do not use any other DL/I call to directly access the metadata in the IMS catalog.

Determining which copy of the metadata is current is critical because the most recent copy of the metadata in the IMS catalog is frequently not the copy that matches the active ACB library members that application programs are currently using.

For example, if you generate your ACB members into an inactive ACB library and update the corresponding metadata in the IMS catalog before activating the ACB members, the most recent copy of the metadata in the IMS catalog is not the current metadata. The most recent metadata in the IMS catalog will not be current until you activate the ACB members.

The following figure shows an example of the scenario described in the preceding paragraph. In the figure, DB1, DB2®, and DB3 are the names of DBDs. TS0 and TS1 represent timestamps. The ACB member for DB3 was regenerated into the inactive ACB library and now has a new timestamp, TS1. The metadata in the IMS catalog was also updated, so the most recent version of the metadata in the IMS catalog also has a timestamp of TS1. Online Change (OLC) has not been performed yet, so the DB3 member in the ACB library and the DB3 DMB still have a timestamp of TS0.

The ACB and metadata for DBD DB3 were updated. The IMS catalog now contains two versions of the metadata for DBD DB3, a version with timestamp TS0 and one with TS1. The active ACB library and the DMB pool contain only timestamp TS0. Only the inactive library contains the ACB member with TS1.

In the following figure, OLC was performed. The ACB library that contains the ACB member with timestamp TS1 is now active and the timestamp on the DB3 DMB is now also TS1. The metadata in the IMS catalog is now current with the ACB member that is being used in the online IMS system.

The ACB member with timestamp TS1 is now in the active ACB library. The DB3 DMB in the DMB pool and the latest version of the DB3 metadata in the IMS catalog also have timestamp TS1.

Another scenario in which the metadata in the IMS catalog might not match the corresponding ACB members in the active ACB library is if the ACB members are generated and activated, but the corresponding metadata was not updated in the IMS catalog. In this case, IMS returns an AIB return and reason code to inform the application program that the metadata for the active ACB member was not found in the IMS catalog.