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.