Using Pre-Scripts and Post-Scripts on UNIX or Windows

DPX allows you to automatically run scripts on UNIX, Linux, OES Linux, or Windows nodes before or after a job. Scripts on Unix may be shell scripts (Bourne, csh, or Korn shell), Perl scripts, or a boolean return from another program on your system. On Windows, the script may be a batch file, a Perl file, a single system command, a program you have written, or anything else you would be able to execute from the DOS command line that runs in text mode.

DPX does not parse the script to ensure that the syntax is correct. DPX merely passes it to the operating system. You can use scripts to change the state of a database, gather information at the time of a job, or perform manual tasks. Following are some common situations in which a script can be useful:

  • To keep a number of jobs from running simultaneously.

  • To retrieve the return code of the job.

  • To launch a second job only if the first job succeeded.

Scripts may be located on either the master server or on any of your client nodes. However, the default is the master server. If you want to use a client node, use the format scriptname@hostname. Following are three separate examples of acceptable specifications for scripts on remote nodes:

downdb.sh@sundb
envget.pl@192.0.2.24
report.bat@node7.hq.uncle.gov

The hostname of the client node is either the name by which the node is known (perhaps through a DNS server) or the IP address, not necessarily the name assigned to the node during configuration of your Enterprise.

The ownership and permissions of the script must be appropriate for the account under which DPX runs. In other words, if you are logged in as that account, you should be able to execute the script successfully from the command line.

You can pass arguments to a script at the time you set the Source Options. The following examples pass the parameters disk1 and 5 to the unmount.sh script:

unmount.sh disk1 5 (on master server)
unmount.sh@sundb disk1 5 (on client node sundb)

All valid forms for pre- and post-job script definitions are as follows:

  • <script> – run it on local node

  • <script> <argument_list> – run it on local node with arguments

  • <script>@<local_node> – run it on local node

  • <script>@<local_node> <argument_list> – run it on local node with arguments

  • <script>@<remote_node> – run it on remote node

  • <script>@<remote_node> <argument_list> – run in on remote node with arguments

A script may call another script. This may be useful in a number of circumstances:

  • You may need to execute script commands under a different userid than the one under which DPX is running on the node. On UNIX, the su or rsh commands are ways to do this.

  • You may want to use a modular structure with common elements in different job scripts.

  • You may want to run a script with parameters assigned dynamically by a calling script.

When a script initiates a process in the background that continues after the script completes, you must direct any output from the background process away from the script. If you do not, the job waits for the output, causing a hang condition. For example, the following pre-job script on UNIX keeps the job from executing:

#!/bin/sh
# Example of a script which does not redirect output properly
tail -f /etc/passwd &
exit 0

There are two ways to fix this problem:

  1. You can use the standard file descriptors to redirect all output.

    Example:

    #!/bin/sh
# Example of a script which does redirect output properly
tail -f /etc/passwd >/opt/bex/logs/tempfile 2>&1 &
exit 0

  2. You can use the at or batch commands to queue the command.

    Example:

    #!/bin/sh
# Example of a script which does redirect output properly
echo 'tail -f /etc/passwd' | batch
exit 0

In both examples, the output from the tail command will be held until the process is terminated later. The script will exit, and the job will start normally.

If a script hangs, kill the script process manually outside the management console (through the operating system).

If a pre-job script ends with a nonzero exit code (ERRORLEVEL, for Windows), DPX considers the script to have failed. The If Pre-Script Fails option determines what action DPX takes. You can either direct DPX to run the job anyway or to skip the job.

If a post-job script ends with a nonzero exit code this will not affect the completion status of the job. If you need to trap these kinds of error conditions, you should incorporate them into the script itself (for example, sending an email to the administrator).

Warning! A post-job script that fails (i.e. returns non-zero code) will pass its failure code down and the job will fail with the same return code. For important additional information about post-job script return codes, read the knowledge base article 42352.

Last updated