HCL Workload Automation workstation processes
- 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.
In this guide HCL Workload Automation processes or workstation processes are used to identify the following processes:
netman
monman
writer
mailman
batchman
jobman
- 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
Symphonyfile 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.
Symphonyfile. - 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
jobmanrcand.jobmanrcscripts 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 (
If any of these steps fails, the job ends in the FAIL state.TWS_home/jobmanrcin UNIX® andTWS_home/jobmanrc.cmdin Windows®) which contains settings that apply to all jobs running on the workstation. In addition, on UNIX® workstations a local configuration scriptTWS_user/.jobmanrcis 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.Attention: If, on Windows systems, a system variable calledTEMPexists, 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.
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 HCL Workload Automation: Planning and Installation Guide.
Tivoli Token Service, which
enables HCL Workload Automation processes
to be launched as if they were issued by the HCL Workload Automation user.