Script Definition
During the execution of a Block backup job, DPX checks for the existence of a script information file called scrinfo.txt located in the bin directory in the directory where DPX is installed. If this file does not exist, you can create it.
scrinfo.txt tells the job which scripts to run. The scripts themselves must be located in the directory SCHED\SCRIPTS in the directory where DPX is installed.
Each script may be a batch file, a Perl file, a single system command, or any other executable file that runs from the Windows command line in text mode. A script may call another script.
Scripts for use during a Block backup job follow the same general rules as pre-scripts and post-scripts described in Job Definition Scripting Fields in the Reference Guide.
Format of the Script Information File
The format of scrinfo.txt is:
= and <> are used as delimiters, and they can not be used in the actual fields.
Blank lines and lines starting with # are ignored.
Script lines are of the format:
name1=arg1<>name2=arg2<>name3=arg3...
The following describes the name fields arguments:
cmd
This argument is the script to execute. The script may be a batch file, a Perl file, a single system command, or anything executable from the Windows command line that runs in text mode. A script may call another script.
node
If specified, this argument is the node where the script is run. The default is the current node.
type
This argument is the type of script to be run. The script types are:
• presnap scripts are executed before snapshots are taken.
• postsnap scripts are executed after snapshots are taken.
• postxfer scripts are executed after data transfer is done.
postsnap and postxfer scripts are executed even if snapshot and/or data transfer operations fail. DPX always appends two command line parameters at the end of the cmd. The first one is "operation status" where 0 indicates failure and 1 indicates success. For postsnap and postxfer scripts, this field signifies the status of snapshotting and data transfer respectively. For presnap scripts, this parameter has no meaning and is always 1. The second command line parameter appended is the job id.
jobname
If specified, this script applies only to the backup job specified by the argument. Otherwise, it applies to all Block backup jobs.
abort_on_fail
By default, the job continues even if a script fails (return status nonzero). If you want the job to fail if the script being executed fails, set the argument of abort_on_fail to 1. This option is effective only for presnap and postsnap scripts.
Case 1
This is an example script info file for Block backup jobs
This file calls the scripts “test1”, “test2”, and “test3” that are found in SCHED\SCRIPTS.
Case 2
In this example, dbshutdown.bat performs a shutdown of a database service, and dbstartup.bat performs a start of that service:
Shutdown the database on the node NodeA prior to the snapshot being taken for the job xNodeA and restart it after the snapshot is taken. If you can not shut down the database, prevent the job from continuing and fail the job immediately. The contents of the scrinfo.txt file may appear as
After the job xNodeA completes, notice the message:
In this example, the pre-script for snapshots ends with a successful completion rc=0 and the job can continue.
Last updated