HCL Workload Automation workstation processes

The management of communication between workstations and local job processing, together with the notification of state updates, are performed on each HCL Workload Automation 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 infrastructure. This infrastructure is automatically installed with the workstation and allows HCL Workload Automation to:

• Communicate across the HCL Workload Automation 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 infrastructure and the HCL Workload Automation processes on a workstation refer to Starting and stopping processes on a workstation. Except for manually starting and stopping the WebSphere Application Server and managing connection parameters when communicating across the HCL Workload Automation network, the WebSphere Application Server infrastructure is transparent when using HCL Workload Automation.

In this guide HCL Workload Automation 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 HCL Workload Automation 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 HCL Workload Automation 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 "HCL Workload Automation 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 HCL Workload Automation 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.

Figure 1 shows the process tree on HCL Workload Automation workstations, other than standard agents, installed on UNIX:

Figure 2 shows the process tree on HCL Workload Automation workstations, other than standard agents, installed on Windows: On Windows platforms there is an additional service, the Tivoli Token Service, which enables HCL Workload Automation processes to be launched as if they were issued by the HCL Workload Automation user.