HCL Workload Automation, Version 9.4

Operational considerations for the EEWSERVE gateway task

The following considerations apply:
EEWSERVE not running
If the EEWSERVE task on the mainframe is not running, and an HCL Workload Automation job with no follows dependency is submitted from the extended agent, the job will show an error status and will fail, that is, the job will not run after the EEWSERVE task is started. However, if an HCL Workload Automation job has a follows dependency for an external (non-HCL Workload Automation) job which runs under JES or Access method for z/OS, the internal check job (CJ) command is reissued after EEWSERVE is started. The extended agent workstation still shows its status as linked even if EEWSERVE is not running.

For this reason, if a z/OS automation product such as NetView® is available on the mainframe, write a rule to detect any outages of the EEWSERVE task.

Instance limitations in LPARs
Due to the ENQ/DEQ mechanism in use, only one instance of the EEWTCP02 task (default name EEWSPACE) can be run on a z/OS LPAR. If a second instance is started, it fails with RC=04. So even if you use different started task names and PORT numbers, only one instance of EEWSPACE or EEWSERVE can exist concurrently on a z/OS LPAR.