Skip to main content

Execution

Where a Job runs, and how JAMS decides how much is allowed to run at once.

Once a Job has been submitted and its prerequisites are met, what remains is which machine runs it and whether there is room for it right now.

The Scheduler​

The Scheduler is the component that manages and submits Jobs, tracks their status and reports back to the Client. It is the thing that is actually running your work.

By default a Job runs on the Scheduler itself. That is fine for a small environment and becomes a bottleneck in a large one, which is what Agents are for.

Agents​

An Agent lets a Job run on a machine other than the Scheduler, locally or remotely across the JAMS network. There is an Agent for each supported platform: Windows, Linux and UNIX, IBM i.

An Agent is a property like any other, so it can be set on the Job, inherited from the Folder, or supplied by the Queue. If none of those provides one, the Job runs on the Scheduler. An Agent named on the Job overrides one named on the Queue, but the Job still belongs to that Queue and still counts against its limit.

Every Agent definition carries a platform and a type. The platform is the operating system. The type describes how the Agent and the Scheduler communicate, which matters because it decides which end opens the connection:

  • Local: the Scheduler acting as its own Agent.
  • Outgoing: the Scheduler opens the connection. This is the most common type. A Windows Agent can hold the connection open between Jobs and run several at once.
  • Incoming: the Agent opens the connection. Stopping it means disabling the connection at the Agent rather than at the Scheduler.
  • SSH: a remote system reached over the SSH protocol, one command at a time.
  • Passive: the Execution Method handles the communication. Used mainly for z/OS.

Not every combination of type and platform is supported, and the Client rejects the ones that are not.

An Agent also has its own Job Limit, which caps how many Jobs it will run at once whatever a Queue would otherwise allow.

Queues​

A Queue limits how many Jobs are allowed to start at once, and can distribute them across several Agents.

Queues are optional. A Job that names no Queue runs when its other conditions are met.

A Queue can be stopped and started. Stopping one pauses everything that has not already begun, without canceling anything. When it starts again, waiting Jobs go in order of scheduling priority.

A Queue can also name several Agents, and Jobs are then distributed between them. That is load balancing, and it is the usual reason to point a Job at a Queue rather than at an Agent directly. The Scheduler starts each new Job on the Agent currently running the fewest. An Agent that becomes unavailable drops out of the pool and rejoins it when it comes back.

Every Job counts as one against the Queue limit, whatever kind of Job it is, and a Job can name only one Queue.

Resources​

JAMS Resources are powerful tools that can help you allocate how batch Jobs are run. Resources let you define the necessary requirements for all Jobs, allowing JAMS to determine which Jobs can or cannot run concurrently. You can also use Resources to create maintenance windows that will prevent Jobs from running for a specified time. This is helpful during upgrades or maintenance activities, such as moving the JAMS Scheduler or backing up the database.

Resources can be assigned to Folders and Jobs. The Resource is defined by setting a specific quantity. Jobs will then use a portion of this quantity when they run. If you assign the Resource at the Folder level, all Jobs within the Folder will inherit the Resource setting.

Requirements defined at the Folder level and at the Job level are added together. The total is what must be available before the Job can begin.

A Job whose share is not available waits, and its Entry shows Waiting for Resources in the Monitor. That is how you tell a Job held for contention from one that is simply late.

A Resource can also be tied to a particular Agent, giving that Agent its own share of the pool. That is how you let a larger machine take more work than a smaller one.

Queues and Resources solve different problems:

  • A Queue limits how many Jobs run, by count.
  • A Resource limits which Jobs run together, by what they compete for.

Use a Queue when the constraint is throughput. Use a Resource when the constraint is a shared thing, a database that tolerates two concurrent loads, or an application that cannot have two Jobs touching it at once.