Specifying a Job Name - Parallel Transporter

Teradata® Parallel Transporter User Guide

Product
Parallel Transporter
Release Number
17.00
Published
August 31, 2020
Language
English (United States)
Last Update
2020-08-27
dita:mapPath
zae1544831938751.ditamap
dita:ditavalPath
tvt1507315030722.ditaval
dita:id
B035-2445
lifecycle
previous
Product Category
Teradata Tools and Utilities

Specification of a job name differs depending on operating system.

On UNIX or Windows Systems

Although it is not required, Teradata recommends that all jobs specify a job name on the tbuild command line. Lack of a specified job name complicates later access to other job-related features, such as checkpoint files.

A common practice is to use the name of the job as specified in the DEFINE JOB statement of the script, followed by some form of sequence number (possibly a date stamp) that uniquely identifies the particular run of the job.

If you do not name the job in the tbuild command on UNIX and Windows systems, Teradata PT uses the logon userid followed by the hyphen and a Teradata PT-generated job sequence number.

On z/OS

Job scripts running on z/OS are executed via JCL, and require a JOB statement, which in turn requires specification of a jobname. Many users employ the TSO userid with a unique character appended.

Special Considerations for Running Unnamed Jobs

If you do not uniquely name your jobs on UNIX or Windows systems, or you do not supply a unique high-level qualifier for your z/OS jobs, Teradata recommends that you do the following:

  • Run Teradata PT jobs only one at a time.
  • Restart any interrupted job before running any other jobs. If you need to complete the interrupted job first, or if it is unable to complete successfully upon restart, then you must manually delete the checkpoint files from the checkpoint directory or from the z/OS catalog.

Effect of Unspecified Jobname on Checkpoint Files

Naming a Teradata PT job using the jobname option in the tbuild command is strongly recommended so that each job can have unique checkpoint file names.

If a jobname is not specified in the tbuild command, Teradata PT uses a default jobname to name the checkpoint files. The checkpoint files for all jobs executed under that userid will have the same name. The result for any job that follows a failed job will be for it to try to restart using the failed job checkpoint files, which are automatically retained by Teradata PT for all failed jobs. Whenever this happens, this newer job will not be successful.

For information on checkpoints, see Setting Checkpoint Options.

Jobname Syntax

The syntax to specify a job name is:

   tbuild -f <filename> -j <jobname>

If the job name is omitted, the job will be given a default name:

   <user name>-<Teradata PT job sequence number>

The default name consists of the symbolic username followed by a hyphen (“-”) and a sequence number that the Teradata PT increments for each job submitted.

Example 1

A valid tbuild command is shown below, if you are logged on to the system “labmachine” as user1, and you enter the tbuild command without a job name:

   tbuild -f fivetableload

The resulting job ID would be user1-<sequence number>. Your user ID is the job name, and the “-<sequence number>” (say, “-38”) would be a sequential number that is incremented each time a Teradata PT job is run.

When a job is run using tbuild, a statement displays on the console to show the job ID and the system name. For example:

   job id is user1-38 running on labmachine

Example 2

On the same system, if you specify a job name of week7 as shown below:

   tbuild -f fivetableload week7

The specified job name overrides the default, and the job ID is week7-<sequence number>.

The specified job name is used, and the sequential number is incremented to -39 assuming that this is the next job run on this system.

The length of the jobname parameter is influenced by several factors. It is used to generate a job ID, which is then used to create a job log file in the logs directory. Most of these factors are operating-system related, such as limitations on path size, tbuild command size, file name size, etc. Because the <sequence number> is also part of the job ID, the length of the <sequence number> also affects the length of the jobname parameter. Specifying very long job names could result in unexpected behavior, which can vary from one operating system to another.