DFG:Constraints and Triggers

Constraints and Triggers save & restore

TD/OMS provides Action functions and procedures for handling file triggers and constraints. Triggers take care of calling a function when a certain change is processed on the database and constraints provide additional referential integrity on top of what can be implemented with the use of logical files (views or indexes).

The Actions guide contains information on how to set up the automatic procedure for controlling triggers and constraints. When this mechanism is setup TD/OMS will store, remove and apply the constraints and triggers on the database without your intervention.

However, occasionally this process can fail. That will leave you with a damaged database that has been stripped of its constraint and trigger specifications. You may start recovering to its original situation by using the archive files containing all previous database information, that OMS has stored during the process. You can use that in combination with the TD/OMS command CSTTRGOMS.

Check the STRSD command to see in which library the constraint and trigger information has been stored. If this library definition contains QTEMP, you will find the archive files in the fall-back library.

The file names have the following format:

nnnnnn stands for the transfer number

LLL stands for the rank number of the library list(sub-environment) that is determined during the last transfer and is based on the actual definition sequence of the lists within the environment definitions at that moment.

BVnnnnnn

This contains the triggers of the original database in the from location as they have been before the transfer.

DNnnnnnn

This contains the triggers of the original database altered in such way to how they would be applied on the target database if the transfer had been completed successfully.

DnnnnnnLLL

This contains the triggers of the target database per target library list(sub-environment) as they have been before the transfer

FBnnnnnn

This contains the constraints of the original database in the from location as they have been before the transfer.

TAnnnnnn

This contains the constraints of the original database altered in such way to how they would be applied on the target database if the transfer had been completed was successfully.

TnnnnnnLLL

This contains the contraints of the target database per target library list(sub-environment) as they have been before the transfer.

So, if you are left without triggers and constraints, you have to apply the files BVnnnnnn and DnnnnnnLLL for triggers and the files FBnnnnnn and TnnnnnnLLL for constraints to return to the previous situation.

 Note: file TnnnnnnLLL is not for triggers even if the files start with a T.  

The command CSTTRGOMS can be used to apply the constraint and trigger information back to the database. Assume your constraints save library is OMSCSTTRG and the transfer that failed is transfer 000267. If you may wish to apply the constraints as they were before transfer 000267 started in the database of the first target library list, you would apply the following command:

CSTTRGOMS OPTI(3) CTRI(1) OUTF(T000267001) OUTL(OMSCSTTRG)

Assume your trigger save library is OMSTRIG and the transfer that failed is transfer 000270. If you wish to apply the triggers as they were before transfer 000270 started in the database of the second target library list, you would apply the following command.

CSTTRGOMS OPTI(3) CTRI(2) OUTF(D000270002) OUTL(OMSTRIG)