IBM Workload Scheduler workstation processes

The management of communication between workstations and local job processing, together with the notification of state updates, are performed on each IBM Workload Scheduler workstation by a series of management processes that are active while the engine is running. On fault-tolerant agents and domain managers these processes are based on the WebSphere Application Server Liberty infrastructure. This infrastructure is automatically installed with the workstation and allows IBM Workload Scheduler to:
  • Communicate across the IBM Workload Scheduler network.
  • Manage authentication mechanisms for remote clients, such as command-line programs, connecting to the master domain manager using the HTTP or HTTPS protocols.
For information on how to start and stop both the WebSphere Application Server Liberty infrastructure and the IBM Workload Scheduler processes on a workstation refer to Starting and stopping processes on a workstation. Except for manually starting and stopping the WebSphere Application Server Liberty and managing connection parameters when communicating across the IBM Workload Scheduler network, the WebSphere Application Server Liberty infrastructure is transparent when using IBM Workload Scheduler.

In this guide IBM Workload Scheduler processes or workstation processes are used to identify the following processes:

netman
monman
writer
mailman
batchman
jobman

With the exception of standard agents, these processes are started in the following order on the IBM Workload Scheduler workstations:
netman
Netman is the Network Management process. It is started by the Startup command and it behaves like a network listener program which receives start, stop, link, or unlink requests from the network. Netman examines each incoming request and creates a local IBM Workload Scheduler process.
monman
Monman is a process started by netman and is used in event management. It starts monitoring and ssmagent services that have the task of detecting the events defined in the event rules deployed and activated on the specific workstation. When these services catch any such events, after a preliminary filtering action, they send them to the event processing server that runs usually in the master domain manager. If no event rule configurations are downloaded to the workstation, the monitoring services stay idle.

Ssmagent services are used only for file monitoring event types. For more information, see paragraph "File monitoring events" in the section "Event management" in chapter "IBM Workload Scheduler Concepts" of the Dynamic Workload Console User's Guide.

The communication process between the monitoring agents and the event processing server is independent of the IBM Workload Scheduler network topology. It is based directly on the EIF port number of the event processor and the event information flows directly from the monitoring agents without passing through intermediate domain managers. A degree of fault-tolerance is guaranteed by local cache memories that temporarily store the event occurrences on the agents in case communication with the event processor is down.

writer
Writer is a process started by netman to pass incoming messages to the local mailman process. The writer processes (there might be more than one on a domain manager workstation) are started by link requests (see link) and are stopped by unlink requests (see unlink) or when the communicating mailman ends.
mailman
Mailman is the Mail Management process. It routes messages to either local or remote workstations. On a domain manager, additional mailman processes can be created to divide the load on mailman due to the initialization of agents and to improve the timeliness of messages. When the domain manager starts, it creates a separate mailman process instance for each ServerID specified in the workstation definitions of the fault-tolerant agents and standard agents it manages. Each workstation is contacted by its own ServerID on the domain manager. For additional information, refer to Workstation definition.
batchman
Batchman is the Production Control process. It interacts directly with the copy of the Symphony file distributed to the workstations at the beginning of the production period and updates it. Batchman performs several functions:
  • Manages locally plan processing and updating.
  • Resolves dependencies of jobs and job streams.
  • Selects jobs to be run.
  • Updates the plan with the results of job processing.
Batchman is the only process that can update the Symphony file.
jobman
Jobman is the Job Management process. It launches jobs under the direction of batchman and reports job status back to mailman. It is responsible for tracking job states and for setting the environment as defined in the jobmanrc and .jobmanrc scripts when requesting to launch jobs. For information about these scripts, see Configuring the job environment. When the jobman process receives a launch job message from batchman, it creates a job monitor process. The maximum number of job monitor processes that can be created on a workstation is set by using the limit cpu command from the conman command line prompt (see limit cpu).
job monitor (jobman on UNIX®, JOBMON.exe and joblnch.exe on Windows® operating system)
The job monitor process first performs a set of actions that set the environment before the job is launched, and then launches the job by running the script file or command specified in the job definition. For additional details on how to specify the script file or the command launched with the job, refer to Job.

The setup activities consist of launching the standard configuration file (TWS_home/jobmanrc in UNIX and TWS_home/jobmanrc.cmd in Windows) which contains settings that apply to all jobs running on the workstation. In addition, on UNIX workstations a local configuration script TWS_user/.jobmanrc is launched, if it exists in the home directory of the user launching the job. This local configuration file contains settings that apply only to jobs launched by the specific user.

If any of these steps fails, the job ends in the FAIL state.
Attention: If, on Windows systems, a system variable called TEMP exists, user TWS_user must be authorized to create files in the directory to which the variable is set. If this requirement is not met, the JOBMON.exe binary file fails to start successfully.
All processes, except jobman, run as the TWS_user. Jobman runs as root.

On standard agent workstations, the batchman process is not launched because this type of workstation does not manage job scheduling. These workstations only launch jobs under the direction of their domain manager. Locally on the workstation the management processes wait for a request to launch a job from the domain manager in LISTEN mode. When the request is received the job is launched locally and the result is sent back to the domain manager. For additional information on standard agent workstations refer to IBM Workload Scheduler: Planning and Installation Guide.

Figure 1 shows the process tree on IBM Workload Scheduler workstations, other than standard agents, installed on UNIX:
Figure 1. Process tree in UNIX

This picture displays the IBM Workload Scheduler process tree in UNIX workstations.
Figure 2 shows the process tree on IBM Workload Scheduler workstations, other than standard agents, installed on Windows:
Figure 2. Process tree in Windows

This picture displays the IBM Workload Scheduler process tree in Windows workstations.
On Windows platforms there is an additional service, the Tivoli Token Service, which enables IBM Workload Scheduler processes to be launched as if they were issued by the IBM Workload Scheduler user.