Considerations for CA Datacom/DB Native Access › BACKOUT Statement Considerations

BACKOUT Statement Considerations

The following is a list of requirements that must exist to ensure that a table can successfully back out any changes that were made to the data. These are CA Datacom/DB requirements.

• User-coded ERROR PROCEDURE must explicitly code the BACKOUT statement for situations where backing out any updates is required.
• TXNUNDO URT parameter. If TXNUNDO=YES for a given URT CA Datacom/DB file and the other requirements for transaction backout were satisfied, the BACKOUT statement functions as described. If TXNUNDO=NO, the BACKOUT statement has no effect and no error message is issued.
• Specify the RECOVERY attribute of the TABLE entity-occurrence in the dictionary as Y (yes), indicating that CA Datacom/DB recovery facilities are used. You can print a CXX report to verify that this attribute was specified correctly. If so, the CXX report indicates RECOVER - YES.
• Specify the LOGGING attribute of the TABLE entity-occurrence in the dictionary as Y (yes), indicating that CA Datacom/DB logging is used. You can print a CXX report to verify that this attribute was specified correctly. If so, the CXX report indicates LOGGING - YES.
• CA Datacom/DB logging must not be turned off. DBUTILTY allows logging to be dynamically turned off and on, using the CXXMAINT ALTER LOGGING option. (You must specify RECOVERY as Y for this option to be honored.) You can print a CXX report to verify that logging is currently turned on.
• CA Datacom/DB master list must specify all options that enable logging and recovery. CA Ideal requires these capabilities. CA Ideal uses logging and transaction backout internally, and the CHECKPOINT and BACKOUT commands.

The CA Datacom/DB Database and System Administrator Guide contains a chapter on using the logging facility. It describes the log file in detail and how to set up the logging facility, which is required for the CHECKPOINT and BACKOUT.