DB2 Version 10.1 for Linux, UNIX, and Windows

DB2 Advanced Copy Services (ACS) protocol file

The DB2® Advanced Copy Services (ACS) protocol files are created by the library for DB2 ACS and contain information that is needed by scripts for snapshot operations.

The protocol files are located in the protocol file repository. You should create a directory for this repository before performing your snapshot operation. You specify the repository by using the options parameter with the relevant command. If you do not create a directory, the protocol file repository will be the same directory that the script is located.

The protocol files serve two purposes:

They show the progress of the running operation. In the case of failed operations, they also contain some information that you can use for debugging.
They contain information and options provided from the library for DB2 ACS to the script. Some of the information, such as the metadata string, is also needed by the library for DB2 ACS or DB2 to restore the snapshot.

A protocol file is divided into different sections, each of which shows the progress and options of each function call. The output in each section contains the following information:

Function name. For example db2ACSInitialize
For a list of functions see DB2 Advanced Copy Services (ACS) API functions
Beginning and ending timestamp for the function call

Commands that were used to invoke the script, in the following format

 cmd: path_to_script -a action
    -c protocol_file_reposity/protocol_file_name.cfg

Options that were given in the function calls. See Table 1 for a list and description of the options.

Table 1. Options written by the library for DB2 ACS
Key name	Description
ACTION	Action that is being performed: DB2ACS_ACTION_READ_BY_GROUP during restore of parts of the database, in particular restore excluding log files DB2ACS_ACTION_READ_BY_OBJECT during restore of the whole database, DB2ACS_ACTION_WRITE during snapshot
APP_OPTIONS	Hex value that combines the DB2BACKUP_*
DATAPATH_AUTOSTORAGE	Key for each storage path that is configured in the database
DATAPATH_DB	Database paths configured in the database
DATAPATH_GENERIC	Additional paths configured in the database Placeholder for future types
DATAPATH_LOCAL_DB	Local database paths configured in the database
DATAPATH_TBSP_CONTAINER	Key for each DMS container that is configured in the database
DATAPATH_TBSP_DEVICE	Key for each raw device that is configured in the database
DATAPATH_TBSP_DIR	Key for each SMS storage path that is configured in the database
DB_NAME	Name of the database for that the operation is done
DBPARTNUM	Database partition number to be operated on
DB2BACKUP_MODE	Whether the backup is offline or online
DB2BACKUP_LOGS	Whether log files are included in or excluded from the backup. If logs are excluded, LOG_DIR and MIRRORLOG_DIR are not contained in the protocol file.
DELETE_OBJ_ID	Object ID of the object to be deleted
EXTERNAL_OPTIONS	Lists any options that you specify in the backup and restore command and are automatically copied into to the custom script.
EXTERNAL_SCRIPT	Name of the script for the snapshot operation
FIRST_ACTIVE_LOG_CHAIN	The log chain of the first active log
FIRST_ACTIVE_LOG_ID	Number of first active log of the database during the time the snapshot was taken
INSTANCE	Name of the instance for the database
LOGPATH_MIRROR	Mirror log directory
LOGPATH_PRIMARY	Log directory of the database
METADATA	String that represents the Base64 encoded meta data memory block
METADATA_CHECKSUM	Checksum of the Base64 metadata string
METADATA_SIZE	Size of the encoded metadata string
METADATA_DECODED_SIZE	Size of the decoded metadata block
OBJ_DB2ID_LEVEL	Fix pack level that was used during the backup
OBJ_DB2ID_RELEASE	Release level of the DB2 product that was used during the backup
OBJ_DB2ID_VERSION	Version of the DB2 product that was used during backup
OBJ_HOST	Host server where the database partition resides
OBJ_ID	Unique identifier for each stored object
OBJ_OWNER	Owner of the object
OBJ_TYPE	Snapshot
OPERATION	Operation identifier: Delete Restore Snapshot
QUERY_DB	Name of the database that is queried for
QUERY_HOST	Name in the host in the object
QUERY_INSTANCE	Name of the instance of the database that is contained in the backup image
QUERY_OWNER	Owner of the object
QUERY_DBPARTNUM	Number of the database partition backed up to the object -1 for the generic case
QUERY_TIMESTAMP	Timestamp queried for
QUERY_TYPE	Type of the object to be queried, snapshot or hex code representing the type
RC_DELETE	Return code of the deletion operation. A non-zero value indicates that an error happened in the section.
RC_OPERATION	Return code of the complete backup operation. A non-zero value indicates that an error happened in the section.
RC_PREPARE	Return code of the prepare action. A non-zero value indicates that an error happened in the section.
RC_RESTORE	Return code of the complete restore operation. A non-zero value indicates that an error happened in the section.
RC_SNAPSHOT	Return code of the snapshot action. A non-zero value indicates that an error happened in the section.
RC_STORE_METADATA	Return code of store_metadata operation. A non-zero value indicates that an error happened in the section.
RC_VERIFY	Return code of the verify action. A non-zero value indicates that an error happened in the section.
RESULT_`n`_FILE	The name of the `n`th file during query, delete and restore
SIGNATURE	Software level of the DB2 version being used

Example protocol file for a snapshot backup

This section contains an example protocol file written for a snapshot backup operation invoking the sample script. For illustrative purposes, it has been broken up into sections for each DB2 ACS API function that is a part of the operation.

db2ACSInitialize

The flags that are of most interest for monitoring purposes are:

EXTERNAL_SCRIPT: the name and path of the script
DB_NAME: the database name
INSTANCE: the DB2 instance name
DBPARTNUM: the database partition number

# ==============================================
# db2ACSInitialize(): BEGIN [2012-11-30 08:15:45]
EXTERNAL_SCRIPT=/home/hotellnx99/jklauke/libacssc.sh
HANDLE=1354281345
START_TIME=1354281345
DB_NAME=SAMPLE
INSTANCE=jklauke
DBPARTNUM=0
SIGNATURE=SQL10020
EXTERNAL_OPTIONS=/home/hotellnx99/jklauke/repository 2ndoption
# db2ACSInitialize(): END
# ==============================================

db2ACSBeginOperation

The database manager calls db2ACSBeginOperation() to begin the specified operation (indicated in the OPERATION flag).

# ==============================================
# db2ACSBeginOperation(): BEGIN [2012-11-30 08:15:45]
OPERATION=snapshot
# db2ACSBeginOperation(): END
# ==============================================

db2ACSPartition

The database manager calls db2ACSPartition(), which associates a group identifier with each of the paths listed by the database manager as belonging to a database partition. The library for DB2 ACS groups database path information for a single database partition together, so the partition ID is unique for every path. This makes it possible to take a snapshot at the file-set, file-system, and volume-group level. The path-related flags that are of interest in this section are:

LOG_DIR, MIRRORLOG_DIR: the log paths
DB_PATH, LOCAL_DB_PATH: the database paths
STORAGE_PATH, CONT_PATH, TBSP_DIR

The SYSIBMADM.DBPATHS administrative view provides these same path types.

A number of flags provide information about the settings for the current operation:

DB2BACKUP_MODE: Offline or online backup
DB2BACKUP_LOGS: Exclude or include logs. In this example, the logs are included, so the sample customer script compresses the log files but in a different file than the other database files.

# ==============================================
# db2ACSPartition(): BEGIN [2012-11-30 08:15:06]
OBJ_HOST=hotellnx99
OBJ_OWNER=
OBJ_TYPE=snapshot
OBJ_DB2ID_LEVEL=0
OBJ_DB2ID_RELEASE=2
OBJ_DB2ID_VERSION=10
APP_OPTIONS=0x1000
DB2BACKUP_MODE=OFFLINE
DB2BACKUP_LOGS=INCLUDE
LOGPATH_PRIMARY=/home/hotellnx99/jklauke/jklauke/NODE0000/SQL00001/LOGSTREAM0000/
DATAPATH_DB=/home/hotellnx99/jklauke/jklauke/NODE0000/SQL00001/MEMBER0000/
DATAPATH_LOCAL_DB=/home/hotellnx99/jklauke/jklauke/NODE0000/sqldbdir/
DATAPATH_DB=/home/hotellnx99/jklauke/jklauke/NODE0000/SQL00001/
DATAPATH_AUTOSTORAGE=/home/hotellnx99/jklauke/jklauke/NODE0000/SAMPLE/
# db2ACSPartition(): END
# ==============================================

db2ACSPrepare

The database manager calls db2ACSPrepare() to prepare to perform the snapshot. In the protocol file, the prepare section shows the command with which the script was invoked and the return code of the preparation.

# ==============================================
# db2ACSPrepare(): BEGIN [2012-11-30 08:15:45]
# cmd: /home/hotellnx99/jklauke/libacssc.sh -a prepare
   -c /home/hotellnx99/jklauke/repository/db2acs.SAMPLE.0.jklauke.1353420068.cfg
   /home/hotellnx99/jklauke/repository 2ndoption
RC_PREPARE=0
# db2ACSPrepare(): END
# ==============================================

If this step completes successfully, the database manager puts the database in SET WRITE SUSPEND state (assuming the snapshot backup is online).

db2ACSSnapshot

The database manager calls db2ACSSnapshot() to perform the snapshot. The protocol file shows the command used during the snapshot and the return code of the snapshot operation. This part of the protocol file shows the point at which the real snapshot is taken and the vendor tools are triggered that run the operations on the storage boxes.

Note that the content between ACTION=DB2ACS_ACTION_WRITE and RC_SNAPSHOT is specific to the sample script, which compresses all of the paths shown in the db2ACSPartition section of the protocol file into one tar file and all log files (primary and mirror log files) to a second tar file.

# ============================================================================
# db2ACSSnapshot(): BEGIN [2013-01-15 10:18:23]
OBJ_ID=0
ACTION=DB2ACS_ACTION_WRITE
# cmd:/home/hotellnx99/jklauke/sqllib/samples/BARVendor/libacssc.sh -a snapshot
   -c /home/hotellnx99/jklauke/repository/db2acs.SAMPLE.0.jklauke.1358263103.cfg
BACKUP_FILE=/home/hotellnx99/jklauke/repository/SAMPLE.0.jklauke.0.20130115101824.001.tar
# cmd: awk -F= '/^DATAPATH/
   { print $2; }' /home/hotellnx99/jklauke/repository/db2acs.SAMPLE.0.jklauke.1358263103.cfg
   | tar -Pcf /home/hotellnx99/jklauke/repository/SAMPLE.0.jklauke.0.20130115101824.001.tar
   -T - 2>/dev/null && echo 0 || echo 1
# backup tar created, rc=0
# Logs to be included
BACKUP_LOGS=/home/hotellnx99/jklauke/repository/SAMPLE.0.jklauke.0.20130115101824.log.tar
# cmd: awk -F= '/^LOGPATH/ { print $2; }'
   /home/hotellnx99/jklauke/repository/db2acs.SAMPLE.0.jklauke.1358263103.cfg
   | tar -Pcf /home/hotellnx99/jklauke/repository/SAMPLE.0.jklauke.0.20130115101824.log.tar
   -T - 2>/dev/null && echo 0 || echo 1
# tar for logs created, rc=0
RC_SNAPSHOT=0
# db2ACSSnapshot(): END [2013-01-15 10:18:24]
# ============================================================================

After this step completes, the database manager puts the database in WRITE RESUME state.

db2ACSVerify

The database manager calls db2ACSVerify() to verify that the snapshot backup succeeded. If your script contains a verify action, the library for DB2 ACS invokes your script. In the example script, the verify step only checks for the existence of the two tar files (if EXCLUDE LOGS were specified it would not checks for the existence of the tar file for the logs).

# ==============================================
# db2ACSVerify(): BEGIN [2012-11-30 08:15:08]
FIRST_ACTIVE_LOG_ID=2
FIRST_ACTIVE_LOG_CHAIN=3
# cmd: /home/hotellnx99/jklauke/libacssc.sh -a verify -c /home/hotellnx99/jklauke/repository/db2acs_SAMPLE_1354281306_0.cfg 
	/home/hotellnx99/jklauke/repository 2ndoption
# Backup '/home/hotellnx99/jklauke/repository/SAMPLE.0.jklauke.0.1354281306.001.tar' checked: looks okay
# Logs '/home/hotellnx99/jklauke/repository/SAMPLE.0.jklauke.0.1354281306.log.tar' checked: looks okay
RC_VERIFY=0
# db2ACSVerify(): END
# ==============================================

If the script returns a non-zero return code, the following db2ACSStoreMetaData() call is skipped and db2ACSEndOperation is called instead. In the case of the example script, the library for DB2 ACS invokes the script with the rollback action. For an example of this, see this section.

db2ACSStoreMetaData

The database manager calls db2ACSStoreMetaData() to store metadata about the recovery object created by the operation. If your script contains a store_metadata action, the library for DB2 ACS invokes your script to perform actions such as:

backing up the protocol file (it has to exist for a snapshot to be restored, queried, or deleted)
renaming the backup

# ============================================================================
# db2ACSStoreMetaData(): BEGIN [2013-01-15 10:18:24]
START_TIME=1358263104
METADATA_SIZE=12024
METADATA=U1FMV...
METADATA_CHECKSUM=16941
# cmd: /home/hotellnx99/jklauke/sqllib/samples/BARVendor/libacssc.sh -a store_metadata
   -c /home/hotellnx99/jklauke/repository/db2acs.SAMPLE.0.jklauke.1358263103.cfg
RC_STORE_METADATA=0
# db2ACSStoreMetaData(): END [2013-01-15 10:18:24]
# ============================================================================

db2ACSEndOperation

The database manager calls db2ACSEndOperation() to end the operation.

Successful operations

The return code of 0 indicates that the snapshot operation was successful.

# ==============================================
# db2ACSEndOperation(): BEGIN [2012-11-30 08:15:08]
RC_OPERATION=0
# db2ACSEndOperation(): END

Failed operations

If the snapshot operation failed--that is, a call to the customer script had a non-zero return code or there was an internal error in the library for DB2 ACS--the db2ACSEndOperation section of the protocol file has a non-zero return code. If you specify a rollback action in your script, the script is called at this point. In the case of the sample script, the protocol file contains the following output:

# ============================================================================
# db2ACSEndOperation(): BEGIN [2013-01-18 05:26:06]
RC_OPERATION=1
# cmd:/home/hotellnx99/jklauke/sqllib/samples/BARVendor/libacssc.sh -a rollback
   -c /home/hotellnx99/jklauke/repository/db2acs.SAMPLE.0.jklauke.1358504766.cfg
# Delete old backup file :
   /home/hotellnx99/jklauke/repository/SAMPLE.0.jklauke.0.20130118052606.001.tar
# Delete old backup file :
   /home/hotellnx99/jklauke/repository/SAMPLE.0.jklauke.0.20130118052606.log.tar
RC_ROLLBACK=0
# db2ACSEndOperation(): END [2013-01-18 05:26:06]
# ============================================================================

db2ACSTerminate

The database manager calls db2ACSTerminate() to terminate the session.

# ==============================================
# db2ACSTerminate(): BEGIN [2012-11-30 08:15:08]
# db2ACSTerminate(): END
# ==============================================

Example protocol file for a snapshot restore

This section contains an example protocol file written for a snapshot restore operation invoking the sample script. A snapshot restore reads the protocol file for the snapshot backup, while at the same time writing new protocol files for the restore operation. If the restore is successful, those protocol files are deleted. For illustrative purposes, the following protocol file for a snapshot restore has been broken up into sections for each DB2 ACS API function that is a part of the operation.

db2ACSInitialize

The flags that are of most interest for monitoring purposes are:

EXTERNAL_SCRIPT: the name and path of the script
DB_NAME: the database name
INSTANCE: the DB2 instance name
DBPARTNUM: the database partition number

# ==============================================
# db2ACSInitialize(): BEGIN [2012-11-30 08:27:38]
REPOSITORY_PATH=/home/hotellnx99/jklauke/repository/
EXTERNAL_SCRIPT=/home/hotellnx99/jklauke/libacssc.sh
HANDLE=1354282058
START_TIME=1354282058
DB_NAME=SAMPLE
INSTANCE=jklauke
DBPARTNUM=0
SIGNATURE=SQL10020
EXTERNAL_OPTIONS=/home/hotellnx99/jklauke/repository
# db2ACSInitialize(): END
# ==============================================

db2ACSBeginOperation

The database manager calls db2ACSBeginOperation() to begin the specified operation (indicated in the OPERATION flag).

# db2ACSBeginOperation(): BEGIN [2012-11-30 08:27:38]
OPERATION=restore
# db2ACSBeginOperation(): END
# ==============================================

db2ACSBeginQuery

The database manager calls db2ACSBeginQuery() to determine which snapshot backup objects are available to be used for the restore operation and to prepare the restore. The protocol file also shows the command with which the script was invoked for the prepare action and the return code of the preparation.

# ==============================================
# db2ACSBeginQuery(): BEGIN [2012-11-30 08:27:38]
QUERY_TYPE=snapshot
QUERY_PARTNUM=0
QUERY_DB=SAMPLE
QUERY_INSTANCE=*
QUERY_HOST=*
QUERY_OWNER=*
QUERY_TIMESTAMP=20121130082717
# cmd: /home/hotellnx99/jklauke/libacssc.sh -a prepare
  -c/home/hotellnx99/jklauke/db2acs.SAMPLE.0.jklauke.1353421208.cfg
  /home/hotellnx99/jklauke/repository
RC_PREPARE=0
# db2ACSBeginQuery(): END
# ==============================================

db2ACSGetNextObject

The database manager calls db2ACSGetNextObject() to find an appropriate backup image for the given timestamp. The function is called iteratively and loops over the available files, giving information about each backup image to the database manager. The following output shows the looping over three protocol files:

# ============================================================================
# db2ACSGetNextObject(): BEGIN [2012-12-13 08:01:39]
RESULT_0_FILE=/home/hotellnx99/jklauke/repository/db2acs.SAMPLE.0.jklauke.1355341475.cfg
# read result object with timestamp 20121212144436
# db2ACSGetNextObject(): END [2012-12-13 08:01:39]
# ============================================================================
# db2ACSGetNextObject(): BEGIN [2012-12-13 08:01:39]
RESULT_1_FILE=/home/hotellnx99/jklauke/repository/db2acs.SAMPLE.0.jklauke.1355341690.cfg
# read result object with timestamp 20121212144811
# db2ACSGetNextObject(): END [2012-12-13 08:01:39]
# ============================================================================
# db2ACSGetNextObject(): BEGIN [2012-12-13 08:01:39]
RESULT_2_FILE=/home/hotellnx99/jklauke/repository/db2acs.SAMPLE.0.jklauke.1355341892.cfg
# read result object with timestamp 20121212145133
# db2ACSGetNextObject(): END [2012-12-13 08:01:39]
# ============================================================================

db2ACSRetrieveMetaData

The database manager calls db2ACSRetrieveMetaData() to retrieve all metadata about the backup image.

# ==============================================
# db2ACSRetrieveMetaData(): BEGIN [2012-11-30 08:27:39]
GET_META_OBJ_ID=3
METADATA_DECODED_SIZE=9004
METADATA_CHECKSUM=14583
# db2ACSRetrieveMetaData(): END
# ==============================================

db2ACSSnapshot

The database manager calls db2ACSSnapshot() to perform the restore. The protocol file shows the commands and actions used by the script and the return code of the snapshot operation. The action can be one of two options:

DB2ACS_ACTION_READ_BY_OBJECT. This indicates that the LOGTARGET INCLUDE FORCE options were specified with the RESTORE DATABASE command. The script uncompresses both tar files (one for the data and one for the logs). You also need to copy the disks used for the log files.
DB2ACS_ACTION_READ_BY_GROUP. This indicates that the LOGTARGET EXCLUDE FORCE options were specified with the RESTORE DATABASE command. This shows the groups, or IDs of the file systems, for the groups that have to be restored. You must not copy the disks used for the log files.

# ==============================================
# db2ACSSnapshot(): BEGIN [2012-11-30 08:27:40]
OBJ_ID=3
ACTION=DB2ACS_ACTION_READ_BY_OBJECT
# cmd:/home/hotellnx99/jklauke/libacssc.sh -a restore
   -c /home/hotellnx99/jklauke/repository/db2acs_SAMPLE_1354282058_0.cfg
   /home/hotellnx99/jklauke/repository
# cmd: tar -xf /home/hotellnx99/jklauke/repository/SAMPLE.0.jklauke.0.20121130082717.001.tar
   && echo 0 || echo 1
# tar extracted, rc=0
# cmd: tar -xf /home/hotellnx99/jklauke/repository/SAMPLE.0.jklauke.0.20121130082717.log.tar
   && echo 0 || echo 1
# logs extracted, rc=0
RC_RESTORE=0
# db2ACSSnapshot(): END
# ==============================================

If an appropriate backup image is found, the meta data is read from the protocol file and the restore is started by invoking the customer library.

db2ACSEndOperation

The database manager calls db2ACSEndOperation() to end the operation. The return code of 0 indicates that the restore operation was successful.

# ==============================================
# db2ACSEndOperation(): BEGIN [2012-11-30 08:27:41]
END_ACTION=0
# db2ACSEndOperation(): END
# ==============================================

db2ACSTerminate

The database manager calls db2ACSTerminate() to terminate the session.

# ==============================================
# db2ACSTerminate(): BEGIN [2012-11-30 08:27:41]
# db2ACSTerminate(): END
# ==============================================

Example protocol file for a snapshot deletion

This section contains an example protocol file written for a deletion of a snapshot image which invokes the sample script. During a deletion, the protocol file for the snapshot backup is read, while at the same time new protocol files are written for the delete operation. If the deletion is successful, those protocol files are removed. For illustrative purposes, the following protocol file for the deletion of the snapshot has been broken up into sections for each DB2 ACS API function that is a part of the operation.

db2ACSInitialize

After loading the library for DB2 ACS and querying the version of the DB2 ACS API, the database manager establishes a DB2 ACS session by calling db2ACSInitialize(). This step is required for all operations. Take care that you do not accidentally delete any images by either specifying the database name or using a unique protocol file repository for each snapshot operation. In the following output, for example, all backups contained in the /home/hotellnx99/jklauke/ directory are deleted.

# db2ACSInitialize(): BEGIN [2012-11-20 09:10:17]
REPOSITORY_PATH=/home/hotellnx99/jklauke/
EXTERNAL_SCRIPT=/home/hotellnx99/jklauke/libacssc.sh
HANDLE=1353420617
DB_NAME=*
INSTANCE=*
DBPARTNUM=0
SIGNATURE=SQL10020
EXTERNAL_OPTIONS=/home/hotellnx99/jklauke/
# db2ACSInitialize(): END
# ==============================================
# db2ACSBeginOperation(): BEGIN [2012-11-20 09:10:17]
OPERATION=delete
# db2ACSBeginOperation(): END
# ==============================================

db2ACSBeginOperation

The database manager calls db2ACSBeginOperation() to begin the specified operation (indicated in the OPERATION flag).

# db2ACSBeginOperation(): BEGIN [2012-11-30 08:27:38]
OPERATION=restore
# db2ACSBeginOperation(): END
# ==============================================

db2ACSBeginQuery

The database manager calls db2ACSBeginQuery() to determine which snapshot backup objects are available to be deleted and to prepare the restore. The protocol file also shows the command with which the script was invoked for the prepare action and the return code of the preparation.

# ============================================================================
# db2ACSBeginQuery(): BEGIN [2012-12-13 08:24:42]
QUERY_TYPE=0x0
QUERY_DBPARTNUM=-1
QUERY_DB=*
QUERY_INSTANCE=*
QUERY_HOST=*
QUERY_OWNER=*
# cmd: /home/hotellnx99/jklauke/sqllib/samples/BARVendor/libacssc.sh -a prepare
   -c /home/hotellnx99/jklauke/repository/db2acs.0.1355405082.cfg
RC_PREPARE=0
# db2ACSBeginQuery(): END [2012-12-13 08:24:42]
# ============================================================================

db2ACSGetNextObject

# ==============================================
# db2ACSGetNextObject(): BEGIN [2012-11-20 09:10:17]
RESULT_0_FILE=/home/hotellnx99/jklauke/db2acs.SAMPLE.0.jklauke.1353420375.cfg
# read result object with timestamp 20121120090616
# db2ACSGetNextObject(): END
# ==============================================
# db2ACSGetNextObject(): BEGIN [2012-11-20 09:10:17]
# db2ACSGetNextObject(): END
# ==============================================

db2ACSDelete

The database manager calls db2ACSDelete() to delete recovery objects. For every backup image that matches the timestamp (retrieved during the db2ACSGetNextObject() call), the API and the script are called sequentially to delete the backup images and any dependent files.

# ============================================================================
# db2ACSDelete(): BEGIN [2012-12-13 08:24:44]
DELETE_OBJ_ID=5
# cmd: /home/hotellnx99/jklauke/sqllib/samples/BARVendor/libacssc.sh -a delete
   -o 5 -t 20121213051805
   -c /home/hotellnx99/jklauke/repository/db2acs.0.1355405082.cfg
# Delete old backup file and logs:
   /home/hotellnx99/jklauke/repository/SAMPLE.0.jklauke.0.20121213051805.001.tar
# Delete old configuration file:
   /home/hotellnx99/jklauke/repository/db2acs.SAMPLE.0.jklauke.1355393884.cfg
RC_DELETE=0
# db2ACSDelete(): END [2012-12-13 08:24:44]
# ============================================================================

db2ACSEndQuery

The database manager calls db2ACSEndQuery() to terminate the query session for backup images.

# ==============================================
# db2ACSEndQuery(): BEGIN [2012-11-20 09:10:19]
# db2ACSEndQuery(): END
# ==============================================

db2ACSEndOperation

The database manager calls db2ACSEndOperation() to end the operation. The return code of 0 indicates that the deletion was successful.

# ==============================================
# db2ACSEndOperation(): BEGIN [2012-11-20 09:10:19]
END_ACTION=0
# db2ACSEndOperation(): END
# ==============================================

db2ACSTerminate

The database manager calls db2ACSTerminate() to terminate the session.

# ==============================================
# db2ACSTerminate(): BEGIN [2012-11-20 09:10:19]
# db2ACSTerminate(): END
# ==============================================