3.1.2 Jobs

Any request to start the job controller from a JP1/AJS or Windows command prompt or a UNIX shell is accepted as a job. A general user who will be using the job passes the job definition script containing a collection of instructions to the job controller.

The job controller analyzes the instructions to determine what is being requested by the user and executes the job in a manner that makes efficient use of system resources.

Organization of this subsection

(1) Root jobs and child jobs
(2) Job input modes
(3) Relationship between jobs
(4) Relationship between jobs and environment files
(5) Temporary files and regular files
(6) Asynchronously executed processes

(1) Root jobs and child jobs

In general, a job is the unit in which the system is requested to perform a single integrated task prepared by a general user. Individual tasks that are requested are treated as being mutually independent.

A job consists of a series of processing programs. To execute these processing programs, you must define their execution order, execution conditions, and the files that will be required for them to execute.

Jobs are classified into root jobs and child jobs.

Root job

Of the jobs to be executed from programs, such as JP1/AJS and login shell, all jobs other than child jobs are root jobs.
Child job

In job definition scripts that are run as descendant processes of root jobs, the jobs that are executed by using one of the parameters listed below or its default definition are child jobs:
- CHILDJOB_EXT parameter
- CHILDJOB_PGM parameter
- CHILDJOB_SHEBANG parameter

The following figure shows an example procedure for starting root jobs and child jobs.

[Figure]

To Page Top

(2) Job input modes

Jobs are executed in one of the following modes according to the status of the standard input:

Terminal input mode

If the standard input is associated with the terminal when a job starts, the job is executed in this mode. The following is an example of starting a job in this mode:
- In the login shell, executing the adshexec command with the standard input associated with the terminal
Non-terminal input mode

If the standard input is not associated with the terminal when a job starts, the job is executed in this mode.

The following are examples of starting a job in this mode:
- Starting a job from JP1/AJS
- In the login shell, executing the adshexec command by redirecting the standard input from a file
- In the login shell, executing the adshexec command in a middle of or at the end of a pipe

When a job starts, the KNAX7902-I message indicating the mode used to execute the job is displayed.

In UNIX, how a job is forcibly terminated depends on the job input mode. For details, see 3.11 Forcibly terminating jobs.

In Windows, the job input mode has no effect on the job processing.

To Page Top

(3) Relationship between jobs

Root jobs are mutually independent. This means that jobs processed concurrently do not influence each other, nor can an executed root job influence root jobs that are executed later. Also, information cannot be inherited from one root job to another (except for the information in files).

However, there might be relationships between jobs, such as the following:

Depending on the scheduling by JP1/AJS, root jobs are associated with each other in terms of their execution order.
If multiple jobs use the same regular file concurrently, those jobs are associated with each other. A schedule must be designed in JP1/AJS so that the jobs are executed in the appropriate order.
There might be a relationship between a root job and child jobs and between child jobs.

To Page Top

(4) Relationship between jobs and environment files

Both root and child jobs load the system environment file and a job environment file when the jobs start. Therefore, a root job and its child jobs use parameters in different environment files in the following cases:

After a root job loaded the environment files at the start, the value of the ADSH_ENV environment variable is changed to a different job environment file path before a child job loads the environment files when it starts.
After a root job loaded the environment files at the start, the contents of the system environment file or job environment file is changed before a child job loads the environment files when it starts.

If you want to run a root job and its child jobs using the same environment file parameters, do not change the value of the ADSH_ENV environment variable or the contents of the environment files while the jobs are executing.

If the export parameter is defined in the environment files, its value takes precedence over the value of the environment variable that the job inherits from its parent process. The following shows an example.

Root job root.ash

export ENV1=SCRIPTFILE
childjob.ash  #start the child job

Child job childjob.ash
```
echo $ENV1
```
Contents of environment file adshrc.ase that are loaded by root job root.ash and child job childjob.ash
```
export ENV1=ENVFILE
```
echo output results of child job childjob.ash
```
export ENV1=ENVFILE
```

In this example, the jobs are run in the following procedure:

Root job root.ash starts and ENVFILE is set in ENV1 by the export parameter in environment file adshrc.ase.
Root job root.ash sets SCRIPTFILE in environment variable ENV1 before its child job childjob.ash starts.
Child job childjob.ash starts and inherits environment variable ENV1 from root job root.ash. Immediately after the process of child job childjob.ash started, the value of ENV1 was SCRIPTFILE.
Child job childjob.ash loads environment file adshrc.ase at the start. ENVFILE is set in ENV1 by the export parameter.
The result of echo by child job childjob.ash is ENVFILE, which was set in step 4.

To Page Top

(5) Temporary files and regular files

Batch jobs perform processing by referencing data, such as the information provided by open base products, as temporary files or regular files.

(a) Temporary files

Temporary files are used temporarily during job execution. They are created automatically by jobs and job steps and deleted automatically when the jobs terminate. Temporary files are created in a directory defined in the environment files.

We recommend that you manage the temporary files for batch jobs separately from the temporary files for applications. The directory for storing temporary files in the job controller of JP1/Advanced Shell is specified in the TEMP_FILE_DIR parameter. Normally, the temporary files are deleted, but they might remain if a failure occurs. For this reason, make sure that you delete temporary files periodically.

(b) Regular files

Regular files are used to input and output job definition scripts and can be placed in any directory. These files are retained as job results after jobs have terminated, but you can delete them during job execution.

To Page Top

(6) Asynchronously executed processes

The job controller of JP1/Advanced Shell does not terminate a job until all the related root jobs, child jobs, and commands have terminated.

(a) Asynchronous execution by using & and |&

A job is not terminated until all the processes executed with & and |& specified are completed.

Note that if an asynchronously executed process is terminated due to receipt of a signal such as SIGSTOP at the time the job terminates, the job might be terminated without waiting for that process to terminate. If you want to terminate a job without waiting for termination of asynchronously executed processes, create the job definition script in such a manner that the OS shell is used only for the parts that you want to execute asynchronously.

The following shows an example.

Example for the UNIX edition
Example of a job definition script waiting for the termination of an asynchronously executed process
```
#!/opt/jp1as/bin/adshexec
mycommand A &
```
If you execute this script in the job controller, the job waits for mycommand to complete before terminating. If you want to terminate this job without waiting for the completion of mycommand, prepare the job definition script as shown below. This example uses /bin/ksh as the OS shell.
Example of a job definition script that ends without waiting for an asynchronously executed process to finish
```
#!/opt/jp1as/bin/adshexec
/bin/ksh exec_cmdA.sh
```
Message of exec_cmdA.sh
```
mycommand A &
```

Example for the Windows edition
Example of a job definition script waiting for the termination of an asynchronously executed process
```
mycommand A &
```
If you execute this script in the job controller, the job waits for mycommand to complete before terminating. If you want to terminate this job without waiting for the completion of mycommand, prepare the job definition script as shown below.
Example of a job definition script that ends without waiting for an asynchronously executed process to finish
```
cmd.exe "/c start exec_cmdA.bat"
```
Contents of exec_cmdA.bat
```
mycommand A
```

(b) Using the exec command to execute external commands

If an external command is specified in the argument of the exec command, the adshexec command executes the external command as a child process and waits for its completion. When the external command is completed, no commands following the exec command will be executed. In such a case, the return code of the completed external command becomes the return code of the job definition script.

(c) Message notifying that the command is to wait for completion of asynchronously executed process

When the adshexec command starts, it outputs the KNAX7901-I message notifying that the command is to wait for completion of asynchronously executed process when the job terminates. This message is normally output to the job execution logs, system execution logs, and standard error. During debugging, this message is output to the standard error output.

(d) Job processing when an asynchronously executed process is stopped (UNIX only)

If an asynchronously executed process is stopped due to receipt of a signal such as SIGSTOP, JP1/Advanced Shell sends SIGHUP and SIGCONT to child processes or descendant processes when the job terminates. When this transmission is completed, JP1/Advanced Shell waits for one second and then performs job postprocessing.

How SIGHUP and SIGCONT are transmitted depends on the job input mode, as described in the following:

Terminal input mode

SIGHUP and SIGCONT are sent only to the child processes of the adshexec command. SIGHUP and SIGCONT are not sent to any of the descendant processes of the adshexec command, including grandchild processes. If grandchild processes remain, use the ps command to obtain the process IDs of the remaining processes, and then manually terminate them with the kill command.
Non-terminal input mode

SIGHUP and SIGCONT are sent to the descendant processes of the adshexec command.

To Page Top