Datacom DBUTLTY TYPE=H report not showing information about BACKUP or EXTRACT jobs
book
Article ID: 48975
calendar_today
Updated On:
Products
DatacomDatacom/ADDatacom/DB
Issue/Introduction
When using the Datacom DBUTLTY program TYPE=H report (Utility Function History Report) to keep track of activity against a database, the BACKUP or EXTRACT job information is not correct.
DBUTLTY jobs to BACKUP the Datacom databases are executed daily, but the report does not show these jobs. Why does this happen, and are there alternatives to this report?
Resolution
According to the Datacom/DB Utility Function Summary section for version 15.1, "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 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.
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:
issuing a command to the application to suspend its processing, or
issuing a command to the 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.
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.
BACKUP/EXTRACT jobs can be tracked using SMF data (z/OS clients only). There is an option with 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 chapter "Customizing the Datacom/DB Environment" and the section called "DBMSTLST Macro" for the SMFRTY setting. Also see the 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 Broadcom support for Datacom.