Mirroring the z/OS current plan to enable the Orchestration Monitor

You can mirror (replicate) a z/OS current plan to the database referenced by the Federator to enable the monitoring of your jobs, job streams, and workstations from both the Orchestration Monitor and REST APIs V2. In this way you run your queries on the database through the Federator without affecting the Z controller, which results in a performance enhancement of the product.

Registering a z/OS engine to the Federator

Before you begin

Ensure that you:

Are using HCL Workload Automation for Z V10.2, or later.
Have configured the Federator, as explained in Configuring the Federator to mirror data on a database.

About this task

To add your z/OS engine to the list of discovered engines that are available from the Orchestration Monitor, register the engine to the Federator by performing the following steps:

On the Z controller:
1. Define the required parameters of the MIRROPTS statement.
2. Set the CODEPAGE and TIMEZONE parameters of the OPCOPTS statement, to set the Z controller code page and time zone respectively.
On the z/OS server started task:
1. In the TCPOPTS statement, set the following parameters:
  - SSLKEYSTORETYPE(SAF)
  - SSLKEYSTORE(MDMCSTMRING)
  - SSLLEVEL(FORCE)
2. In the connectionFactory.xml file, set useSsl="true".

Note: Modifying the Federator by adding, deleting, or editing an engine might take up to five minutes to be shown in the list of discovered engines.

Upon registration completion, the Federator generates the authentication token to secure communications with the Z controller. Before expiration time, the token is automatically renewed by the Federator and sent to the controller: in this way, theoretically, the token never expires. The only exception occurs if the connection between the Federator and controller is not established for a long period of time; to resolve this issue see Troubleshooting.

When a z/OS engine is registered to the Federator, data is mirrored to the configured database from the DB Filler subtask through the Federator, as shown in Mirroring data onto the database.

Figure 1. Mirroring data onto the database

When any job, job stream or workstation is created, updated, or deleted (either dynamically or by a daily planning EXTEND or REPLAN), the Z controller sends the related events to the Federator, which stores the information on the configured database. (The supported databases are those supported by the Dynamic Workload Console, )

Enabling the usage of the Orchestration Monitor

Before you begin

Ensure that you are connected to a Dynamic Workload Console V10.2.3 or later.

About this task

By registering a z/OS engine to the Federator, it is added to the list of discovered engines in the Dynamic Workload Console. You can then monitor your objects from both the following interfaces:

Orchestration Monitor page of the Dynamic Workload Console (for details, see Orchestration Monitor overview).
REST APIs V2, with which you can also run OQL queries. For details, see Using Orchestration Query Language from command line.

Note: You can monitor only the objects for which you are granted permission by RACF.

You monitor the objects on the configured database from the Dynamic Workload Console through the Federator, as shown in Mirroring data onto the database.

Figure 2. Monitoring data from the Orchestration Monitor

Data flow to perform actions on the monitored objects shows the communication flow to perform actions on the objects monitored from the Orchestration Monitor.

Figure 3. Data flow to perform actions on the monitored objects

Troubleshooting

About this task

This section describes how troubleshoot possible issues.

The Z controller cannot connect to the Federator because the authentication token has expired

Before expiration time, the authentication token is automatically renewed by the Federator and sent to the controller to prevent communication interruptions. If, for connection problems, the Federator cannot send the renewed token the following scenarios might occur:

The secret key string that is set in MIRROPTS(SECRET) is still coincident with the value set in the federator.secret property of the Federator: When the connection is established again, the Federator generates a new token and sends it to the controller to be stored locally.
The secret key string that is set in MIRROPTS(SECRET) is no longer coincident with the value set in the federator.secret property of the Federator: When the controller tries to connect to the Federator, the communication is not established. You are required to modify the SECRET parameter of the MIRROPTS to be coincident with the value set in the federator.secret property. Then restart the controller to be registered again on the Federator.