Hitachi

JP1 Version 12 JP1/Automatic Job Management System 3 Overview


10.5.1 Overview and feature description of queueless jobs

This subsection provides an overview of queueless jobs and describes their features.

Organization of this subsection

(1) Execution environment for queueless jobs

Concurrent execution and other aspects of queueless job control are managed by the agent's JP1/AJS3 Queueless Agent service. The service must be started on the agent host before queueless jobs can be executed.

The following figure provides an overview of executing queueless jobs.

Figure 10‒25: Processing flow when executing queueless jobs

[Figure]

Queueless jobs in a jobnet are sent directly from the scheduler to the agent (queueless agent). This is a particular advantage as regards job execution performance when multiple scheduler services are configured in the system.

To execute a queueless job, the name of the JP1 user who issued the job execution request, and the host name of the manager, must be mapped to the OS user of the agent host. To execute a queueless job using a specified OS user, that OS user must be mapped to a JP1 user.

During execution of a queueless job, the communication line between the manager and agent is kept alive to reduce the number of connections and disconnections. Unlike queued jobs, whose status is polled at regular intervals, queueless jobs are not polled. An error in a queueless job is discovered through detection of a disconnection during its execution.

(2) Status transition of queueless jobs

Because they bypass the queue, queueless jobs skip the Now queuing stage. Whereas queued jobs move from Waiting to execute, to Now queuing, and then to Now running (or Failed to start) status, queueless jobs move directly from Waiting to execute to Now running (or Failed to start) status.

(3) Restricting the number of concurrent queueless jobs

You can restrict the number of queueless jobs that can be executed concurrently by an agent host. To do so, set the maximum number of concurrent jobs in that agent's Queueless Agent service. To distribute the processing load in line with your system operation, you can create classes within the Queueless Agent service and set a different concurrent execution limit for each class.

When the limit is reached, subsequent jobs are managed in the Queueless Agent service memory and continue to wait for execution, up to the maximum number of waiting jobs set for the Queueless Agent service or for the specified class. Once this maximum number is exceeded, the next waiting job is placed in Failed to start status.

(a) Setting the maximum number of concurrent queueless jobs

To specify the maximum number of concurrent jobs and waiting jobs in the Queueless Agent service, set the environment setting parameters AJSQL_JOBMAX and AJSQL_JOBWAITMAX, respectively. Use the jajs_config command to set these parameters. For details about the parameters, see 20.10 Setting up the queueless job execution environment in the JP1/Automatic Job Management System 3 Configuration Guide.

Using the ajsqlalter command, you can change the maximum number of concurrent jobs and waiting jobs while the Queueless Agent service is active. When the maximum number of concurrent jobs is set to zero, queueless jobs are not executed but are managed in the Queueless Agent service memory. They continue waiting to be executed until the maximum number of waiting jobs is exceeded. Change the maximum concurrent jobs and maximum waiting jobs to suit your particular system. For details about the ajsqlalter command, see ajsqlalter in 4. Commands Used for Special Operation in the manual JP1/Automatic Job Management System 3 Command Reference.

(b) Distributing queueless jobs based on class-specific concurrent execution limits

When you register a queueless job, you can assign it to a particular class that has a preset limit on the maximum number of jobs that the agent can execute concurrently. Class specification enables lock control of queueless jobs and the setting of time restrictions when particular jobs take precedence, helping to distribute the processing load in line with your system operation.

For details on setting the maximum concurrent jobs and maximum wait jobs per class, see 6.4.1 Executing jobs with a class specified in a queueless job environment in the JP1/Automatic Job Management System 3 Configuration Guide (Windows) or see 15.4.1 Executing jobs with a class specified in a queueless job environment in the JP1/Automatic Job Management System 3 Configuration Guide (UNIX).

For example, suppose that you want to execute a particular job on its own because it uses an execution-locked resource. You can do this by defining a class and setting the maximum number of concurrent jobs in that class to 1. Then register the job in that class. As another example, let's say you want certain jobs to be executed during a particular time period. To do so, increase the concurrent execution limit for the class in which the jobs are to be registered, and reduce the limit for other classes. This allows targeted jobs to be executed preferentially.

(c) Relationship between the maximum number of concurrent execution jobs specified per class or specified for the Queueless Agent service as a whole

When the maximum number of concurrent jobs set for the Queueless Agent service is exceeded, the job is placed in wait state even if the maximum number of concurrent jobs set for the class in which the queueless job is registered has not been reached. Also, if the maximum number of waiting jobs set for the queueless agent is exceeded, the next waiting job enters Failed to start status even if the maximum number of waiting jobs set for the class has not been reached.

(4) OS user when queueless jobs are executed

In the same way as for the jobs for which Standard is specified in Exec. Service, the OS user who corresponds to the JP1 user by user mapping at agent host executes the queueless jobs. When a file is transferred by using a queueless job, user mapping is performed on the manager host. Therefore, you must ensure that the JP1 user was mapped by an OS user via user mapping on the manager host.

Cautionary notes:
  1. For server host name of the user mapping definitions, you must specify the manager host name resolved by the agent host.

  2. The user mapping is cashed when the queueless jobs are executed. After you change the user mapping or the information about the OS user, you must clear the user mapping cache. The cache can be cleared by one of the following operations.

    - Restart the queueless agent service and queueless file transfer service.

    - Execute the ajsqlalter command with the -r option specified.