How to turn on Logging and Recovery for CA Datacom/DB Database tables.

Products

• Datacom
• DATACOM - AD
• Ideal
• CIS
• COMMON SERVICES FOR Z/OS
• 90S SERVICES
• DATABASE MANAGEMENT SOLUTIONS FOR DB2 FOR Z/OS
• COMMON PRODUCT SERVICES COMPONENT
• Common Services
• CA ECOMETER SERVER COMPONENT FOC
• Easytrieve Report Generator for Common Services
• INFOCAI MAINTENANCE
• IPC
• UNICENTER JCLCHECK COMMON COMPONENT
• Mainframe VM Product Manager
• CHORUS SOFTWARE MANAGER
• CA ON DEMAND PORTAL
• CA Service Desk Manager - Unified Self Service
• PAM CLIENT FOR LINUX ON MAINFRAME
• MAINFRAME CONNECTOR FOR LINUX ON MAINFRAME
• GRAPHICAL MANAGEMENT INTERFACE
• WEB ADMINISTRATOR FOR TOP SECRET
• Xpertware

Issue/Introduction

Description:

I have some CA Datacom/DB database tables that have not been using logging or recovery functions, and due to some recent changes, we need to now enablethis capability on the tables. How do I turn on this function?

Solution:

To turn on logging and recovery for application database tables, there are several steps involved. The process is complicated somewhat by having multi-table areas versus single table areas. Both will be covered in this document.

1. Close all URTs in CICS or other applications, close the database in the Multi-User Facility (called MUF), and turn off ACCESS, so that you have exclusive control. Here is a sample of the DBUTLTY input:
   //SYSIN DD *
   ACCESS DBID=143,STATUS=OFF,USERS=FAIL
   CLOSE DBID=143
   /*
   
   
2. Take a precautionary DBUTLTY BACKUP of the entire database so that you can fallback if needed.
   
   
3. Use DBUTLTY to EXTRACT all tables that need to be changed.
   
   
4. Use DBUTLTY to BACKUP the rest of the database:
   
   
   1. If all areas are single-table areas, use BACKUP at the database level and exclude the tables extracted in Step 3, above.
      
      
   2. If any tables to be changed are in a multi-table area, it would be better to use BACKUP for each area, and then exclude the tables extracted in Step 3, above.
      
      
   3. If in doubt, you can extract every table in the database and then MASSADD them all later.
      
      
5. Using DDUPDATE, change the logging/recovery attribute of the PROD version tables you want to change. Also note that any test version tables will need to be RESTORED or changed as well. Here is a sample of the DDUPDATE input for each table:
   //SYSIN DD *
   +USR DATACOM-INSTALL,NEWUSER
   -UPD TABLE,xxxxxxx(PROD)
   1500 LOGGING,Y
   1500 RECOVERY,Y
   -END
   /*
   
   
6. When done, catalog the PROD version database to the CXX.
   
   
7. Init the index (IXX) and any data areas.
   
   
8. Use DBUTLTY to LOAD the database backup(s) taken in step 4, above, using FORMAT=BACKUP.
   
   
9. Use DBUTLTY to load the data back into the tables that were altered:
   
   
   1. If single-table areas, then LOAD the data for each table using FORMAT=EXTRACT, using the files created with EXTRACT in step 3, above.
      
      
   2. If multi-table areas, then first turn on access to the database using DBUTLTY:
      //SYSIN DD *
      ACCESS DBID=143,STATUS=WRITE
      /*
      Then use MASSADD to reload the data for each of the tables in these areas using the files created with EXTRACT in step 3, above.
      
      
10. If you have not already done so, turn on access to the database again using input like that in Step 9b, above.

For more information about the DBUTLTY ACCESS, CLOSE, BACKUP, EXTRACT, LOAD, MASSADD commands, please refer to the CA Datacom/DB DBUTLTY Reference Guide.

For more information about using DDUPDATE, please refer to the CA Datacom Datadictionary Batch Reference Guide.

As always, please contact CA Technologies support for CA Datacom if you have further questions.

Environment

Release: DATABB00200-14-Datacom/AD
Component: