Why does the CA Datacom DBUTLTY TYPE=H report not show information about my BACKUP or EXTRACT job?

Products

• Compress Data Compression for MVS
• Compress Data Compression for Fujitsu
• Datacom
• DATACOM - AD
• Disk Backup and Restore - MVS
• DISK BACKUP AND RESTORE- ADD-ON OPTIO
• DISK BACKUP AND RESTORE
• 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:

When using the CA Datacom DBUTLTY program TYPE=H report (Utility Function History Report) to keep track of activity against a database, we see that the BACKUP or EXTRACT job information is not correct. We run a DBUTLTY job to BACKUP our databases daily, but the report does not show these jobs. Why does this happen, and are there alternatives to this report?

Solution:

According to the CA Datacom/DB DBUTLTY Reference Guide for version 14.0, "History does not include physical backups or EXTRACTs without UPDATE=YES (running without UPDATE=YES does not have the database open and so may not issue a write to the data area control block to reflect that it occurred)."

Consequently, if running a DBUTLTY BACKUP or EXTRACT command with SEQ=PHYSICAL and UPDATE=NO (or with no UPDATE clause, which defaults to NO), the job run information is not kept for the History report. This is a very common scenario for taking backups while other processing continues against the database, called a Continuous Operation Backup. In this case, there is no method within the CA Datacom environment to track the running of these BACKUP or EXTRACT jobs.

However, there are several ways to track these jobs, and each has special considerations.

1. The BACKUP/EXTRACT job can be changed to use UPDATE=YES.
   To change to UPDATE=YES, you would need to ensure that this job has exclusive control of the database - so that nothing else would update it. This can be accomplished by (1) issuing a command to the application to suspend its processing, or (2) issuing a command to the CA Datacom Multi-User Facility (MUF) to QUIESCE processing. Once either of these has occurred, you could then run the SEQ=PHYSICAL BACKUP/EXTRACT with UPDATE=YES, followed by the necessary commands to resume normal processing.
   
   For more information about DBUTLTY QUIESCE processing, or about BACKUP/EXTRACT processing, please refer to the CA Datacom/DB DBUTLTY Reference Guide , and/or these TEC documents:
   TEC512106 , titled "Supplemental Information on the QUIESCE of the MUF"
   TEC571603 , titled "How to check the QUIESCE state in Multi-User (MUF)?"
   TEC510189 , titled "How can I be sure that a DBUTLTY physical sequence BACKUP or EXTRACT has all current data without shutting down the Multi-User Facility (MUF)?"
   
   
2. The BACKUP/EXTRACT job can be changed to use SEQ=NATIVE.
   Whereas a SEQ=PHYSICAL backup/extract retrieves data as it exists on the physical file irrespective of its sequence, a SEQ=NATIVE backup/extract is created by reading the records in key sequence through the index. The advantage to a SEQ=NATIVE backup is that when reloaded, the tables will be loaded in key sequence, optimizing the space utilization and making subsequent sequential retrieval somewhat quicker. Note that if the preponderance of application data access is random, the sequence of the raw data being reloaded after a backup is not highly significant.
   
   Note that the SEQ=NATIVE backup also requires exclusive control of the database (as explained above with UPDATE=YES), so the same considerations for suspending and resuming update access apply.
   
   
3. BACKUP/EXTRACT jobs can be tracked using SMF data (z/OS clients only).
   There is an option with CA Datacom to turn on SMF reporting of some of the DBUTLTY program functions, including BACKUP using SEQ=PHYSICAL and UPDATE=NO. This requires identification of an available SMF record ID and a process to extract these records from your SMF fileset. In order to turn on this feature, you would need to change and reassemble your Master List module (load module DBMSTLST). For more information about this, please refer to the CA Datacom/DB Database and System Administration Guide, in the chapter "Customizing the CA Datacom/DB Environment" and the section called "DBMSTLST Syntax" for the SMFRTY setting. Also see the Appendix section " SMF Record Formats."
   
   Note that the SMF data creation only applies to a few particular functions - including BACKUP and EXTRACT - and will not replace all of the functions found on the DBUTLTY TYPE=H report.

In summary, if you are running a DBUTLTY command to BACKUP/EXTRACT a database with SEQ=PHYSICAL and UPDATE=NO, the History information about the job execution will not be maintained. However, there are several alternatives available to be able to track BACKUP/EXTRACT jobs. For more information or assistance, please contact CA Technologies support for CA Datacom.

Environment

Release:
Component: CA90S