ASG-Enterprise Automation Services (herein called Zeke Services) facilitates your distributed job processing by enabling any Zeke server in the Zekeplex to receive (via TCP/IP) a remote Zeke job or command, or a remote Enterprise Orchestrator command task, store it in the Zeke database as a dynamically-created event, execute the job or command, and return status information to the originating Zeke or Enterprise Orchestrator system.
If you use Enterprise Orchestrator, Enterprise Orchestrator's own communication protocol enables Zeke to dispatch task events to remote Platform Agents for execution.
This section describes the main aspects of an Zeke Services environment including the entities involved and their relationships. For an overview of Zeke's distributed job processing options, see Distributed Processing.
Zeke Services Agent. In an Zeke Services implementation, Zeke Services are provided by Zeke through its Zeke server, which runs in the Zeke started task.
Each Zeke in a Zekeplex (which share the same database) must be configured through its own Zeke server as an agent, known as a Zeke Services agent. These agents receive work requests from an originating remote Zeke or Enterprise Orchestrator system and return status information and results back to the originating system.
The Zekeplex is identified by this name:
plexid.database_ID
Qualifying Agent. A Zeke Services agent is eligible to process remote work or trigger requests only through Zeke Services. Zeke Services agents in the Zekeplex are qualified based on the Netregids defined in the Zeke database along with the plex ID for the Zekeplex. When a remote event specifies in its target destination or WHEN condition any of the Netregids defined for the Zekeplex, then any available, qualified Zeke Services agent can accept the request.
A specific remote Platform agent is qualified based on its Netregid, which is specified as the job event's target in the EMR in Zeke. Any Enterprise Orchestrator remote agent is qualified to process requests through the target designation *ANYAGNT in the event's EMR.
A specific remote Zeke system or agent that receives requests through OASIS/DMS is qualified based on its Netregid, which is specified as the job event's target in the EMR.
Originator. A Zeke or Enterprise Orchestrator service that sends work and requests to a remote agent via a TCP/IP connection is referred to as the originating system, or originator.:
|
•
|
Zeke can function as the originator of a Enterprise Orchestrator job service (defined as a task event type on Zeke) and can dispatch the event to be run on a remote Platform agent. |
|
•
|
Enterprise Orchestrator can function as the originator of a Zeke job task or a z/OS job task (including triggers) and send the work request to Zeke via its Zeke Services agent.
|
Remote Event. A remote event refers to a Zeke job event that is submitted to a remote system or agent for processing through OASIS/DMS (instead of through JES), or through Zeke Services, or to a Platform agent.
Depending on the Target value, these are the possible types of remote job events:
|
•
|
Local job for which the JCL is submitted to JES locally. |
|
•
|
Remote job for which the JCL submitted to JES. |
|
•
|
Remote job to be submitted through OASIS/DMS to a remote Zeke system or agent that has a specified Netregid. |
|
•
|
Remote job to be downloaded to a remote agent for dispatching and tracking. |
|
•
|
Remote task event to be submitted to a qualifying Platform agent through the Enterprise Orchestrator (TCP/IP) protocol.
|
|
•
|
Remote z/OS job submitted to a qualifying Zeke services agent using the Enterprise Orchestrator (TCP/IP) protocol. |
Under Zeke Services, the Target field in the EMR is used to designate the event for remote processing, specify the destination, and determine how the Zeke submits the job's JCL when it dispatches the event. Remote jobs traditionally processed via OASIS/DMS do not require changes to the event definition in the Zeke database in order to be processed through Zeke Services. Zeke considers only the event's target designation to determine the protocol and destination for a remote job; therefore, you can simply redefine the Netregid for a remote system or agent in order to reroute many existing jobs to that destination.
Remote Dependency. A remote dependency (or remote trigger) refers to a prerequisite that must be satisfied by a remote scheduler (that is, Zeke or Enterprise Orchestrator) or agent (that is, Zeke Services or Enterprise Orchestrator). Which specific remote dependencies are supported depends on whether your remote processing is enabled through Zeke Services or OASIS/DMS
Once Zeke and OASIS have been installed successfully, these are the general steps required in order to configure Zeke Services. See the User's Documentation for more information on Zeke's remote processing functions.
To configure Zeke Services
|
1.
|
Obtain the required license to enable Zeke Services. See Zeke Operating License Key for instructions on configuring the Zeke Services product license option. |
|
2.
|
Install and configure the RI Server component. Version 3.0 is required. Zeke and the Platform agent locate each other by registering with the RI server. |
|
–
|
Customize the ASG_RS_name variables in the ENVIRON member in the RIS.SAMPLIB dataset for your primary RI Server, as necessary. (Additionally, if you have installed a backup RI Server, you customize these variables in the ENVIRON member for your backup RI Server.) See the Installing ASG-RI Server™ for details. |
|
–
|
Configure these required Zeke server options for communication with RI Server: |
|
–
|
ASG_RS_FPORT and ASG_RS_LPORT - Defines the range of ports used by Zeke to communicate with the RI Server. |
|
–
|
ASG_RS_IP - The RI Server's listening IP address and port. |
|
–
|
ASG_RS_KEYFILE - The key used to encrypt messages of Zeke and the RI Server. |
Review the optional ASG_RS_option variables in ZENVIRN (see Configuring the Zeke Server) and make sure all values are set appropriately.
|
3.
|
Configure the Zekeplex:
|
|
a.
|
Each Zeke system in the Zekeplex must be configured to run the Zeke server in order to support Zeke Services (see Configuring the Zeke Server).
|
|
–
|
Be sure these required environment variables are set in the ZENVIRN file: |
ZEKE_AGENT_PORT - The port used by Zeke services to listen for incoming requests.
ZEKE_AGENT_SYSOUT_HOST - Specifies the host passed to Enterprise Orchestrator servers if Zeke process job request that has SYSOUT.
|
b.
|
Each Zeke system in the Zekeplex must set the global genopt GUIServ to Yes. |
|
5.
|
Optional. Install and configure the Enterprise Orchestrator components. If you plan to use Enterprise Orchestrator, be sure the Enterprise Orchestrator components are installed, including the Enterprise Orchestrator controller, and Enterprise Orchestrator server, and the appropriate Platform agents. Enterprise Orchestrator Version 4.0 is required. See the Installing ASG-Enterprise Orchestrator for details. |
If you plan to use Enterprise Orchestrator to send Zeke or z/OS job tasks to a Zeke Services agent, see Using ASG-Enterprise Orchestrator for additional configuration information.
If you plan to send Zeke task events to remote Platform agents:
|
•
|
Configure the Netregid for the agent along with the RI Server host name and port in the config.foreign.NETREGID option in the ris.properties file in the \config installation directory for each Platform Agent, along with any optional settings. See the Installing ASG-Enterprise Orchestrator for details.
|
|
6.
|
Optional. Set up the remote agent Web interface. If you plan to implement Zeke and/or Enterprise Orchestrator remote agents, you can enable the remote agent Web interface for monitoring the states of the agents. Configure the appropriate settings in ZENVIRN as described in Configuring the Zeke Server. |
Review all remaining optional variables in ZENVIRN (see Configuring the Zeke Server) and make sure all values are set appropriately for your configuration.
