OpenVMS Fundamentals

Batch Jobs

Commands can be executed even when you are not physically at a terminal, or even logged on the system. This is known as batch processing. Batch processing is the best way to run time-consuming programs because you do not have to wait at the terminal for output, and the system can more efficiently schedule the program's execution.

Write the commands to be executed in a file called a command procedure. Commands in this file mimic the commands that you would normally type interactively. Because you may not necessarily be on the system when the batch job is executed, the system relies on the command procedure for any information needed to complete the task. The command procedure must contain the necessary DCL commands, specialized program or package commands, and any data needed for the task.

A sample command procedure called AREA.COM is listed below:

$ fortran area 
$ link area 
$ run area 
$ exit

Type the following command to submit the batch job for processing:

$ SUBMIT/NOPRINT AREA

The SUBMIT command assumes a file type of .COM. If you use a different file type , you must specify the entire file name.

When your job is entered in the system batch stream, the following sequence occurs:

The job is placed in the waiting queue of batch jobs, SYS$BATCH. You can see the position of your job in the queue by using the following command:

    $ SHOW QUEUE/ALL SYS$BATCH

When the system begins to process the job, it creates a log file in your root directory, i.e., your default directory when you login. The log file goes in the root directory regardless of the directory from which the job is submitted. The log file has the same root name as the command procedure, unless specified otherwise with the /LOG option (the /LOG option can also specify another disk or directory in which to store the log file). At the start of processing, the log file will be empty. The log file can document all commands executed during the batch job and, thus, increases in size as the job is processed. To document each command in the log file, include the SET VERIFY command at the beginning of your command procedure.
Since a batch job logs in under your username, your LOGIN.COM file will be executed before the batch command procedure (see "Defining Your Environment" on page 35 for information about setting up your LOGIN.COM file).
When the job is finished, the log file is automatically queued to the SYS$PRINT printer (unless the /NOPRINT or /NOLOG qualifier is used).
After the log file is printed, it is automatically deleted. You are strongly encouraged to use the /NOPRINT qualifier on the SUBMIT command.

There are other options available for the simple SUBMIT command. Some of these are shown in Table 2.6. Use the help facility by typing:

$ HELP SUBMIT

Table 2.6: Qualifiers Used with the SUBMIT Command

Restarting a Batch Job

Normally, if the system fails while your batch job is executing, your job is aborted and you must resubmit it when the system reboots. Also, when you resubmit it, execution of the command file begins at the start of the file, possibly repeating already completed commands. This can be prevented by using checkpoints in your command file and by submitting your job with the /RESTART qualifier. The following two steps need to be taken:

First create a command file with checkpoints (the listing in Figure 2.7 shows such a file).

Figure 2.7: Command Procedure with Checkpoints

Then submit the job with the /RESTART qualifier. This will cause the job to be submitted to the queue. If the system fails while running your job, the job will be resubmitted automatically when the system restarts and will start executing at the last checkpoint set.

    $ SUBMIT/RESTART MYBATCH.COM

Table 2.6: - Qualifiers Used with the SUBMIT Command
Restarting a Batch Job
Figure 2.7: - Command Procedure with Checkpoints

Generated with CERN WebMaker