VMS Jobs

This subtype of the JOBS object defines VMS-specific processing steps to be carried out in a target system. Like all other job objects (JOBS), VMS jobs can run independently or they can be added to a group (JOBG) or to a workflow. For more information about the integration between the Automation Engine and VMS, see AE and VMS.

Defining VMS Jobs

A VMS Job definition is made up of the following pages:

• Standard pages that are always available, no matter what type of object you are defining:
  • General Page
  • Version Management Page
  • Documentation Page
• Additional pages that are always available for executable objects:
  • Process Pages
  • Attributes Page
  • Output Pages
  • Variables Page
  • Prompt Sets Page
  • Rollback Page
• The VMS page described here.

Start Parameter Section

• Priority

  The priority with which the job should be executed. It is a value between 1 and 999, where 1 is the highest and 999 the lowest priority.

  Note: The priority does not affect the processing order of tasks, it only serves to define their starting order. The task with the higher priority is started first. For tasks with the same priority, the Fist In/First Out (FIFO) principle applies.

• Job Name

  The name under which the job will be executed.

  Maximum length: 39 characters.

• Queue Name

  The name of the queue where the job will be activated.

  Maximum length: 31 characters.

Job Report Section

For information on the Job Report section, see Job Reports.

Return Codes of VMS Jobs

Return codes in VMS differ from those in AWI. Value 1 in VMS signals that a job has successfully been processed, 0 stands for warnings. In AWI it is the opposite; 0 stands for a successful execution whereas any value other than 0 indicate errors.

Important! If the agent returns 0 to AWI this means code 1 in AWI.

Warnings and successful job executions are not differentiated. Analyze the variable $severity whenever a VMS command has been processed. It contains the return code of the last command. Further job processing can then be handled via script.

Tip: Use an Include object for analyzing the variable $severity. In doing so, the relevant script lines must only be maintained in one object and can be included in any job.

Example for an Include Object

$ RETCODE = $severity

$ if  (RETCODE .EQ. 0)

$ then

$   RETCODE = 3

$   goto RETURN

$ endif

The system checks whether the returned code is a warning. If so, job execution is continued in the Trailer. "goto RETURN" leads to the Include object "TRAILER.VMS" which is processed when a job has ended.

See also:

Jobs (JOBS)