Managing multiple z/OS sysplexes

For example, suppose your enterprise has three sysplexes and nine systems that are configured as depicted in Figure 1. To enable the z/OSMF instance in sysplex A to manage sysplexes B and C, your enterprise must also deploy a z/OSMF instance in sysplexes B and C.

Figure 1. Example sysplex and system configuration

Although your enterprise can have multiple active z/OSMF instances, it is recommended that you make one instance the primary. The primary z/OSMF instance is the instance to which your web browser is connected, and it is the instance used to perform all the z/OS system management tasks in your enterprise. The remaining z/OSMF instances are referred to as secondary z/OSMF instances.

To manage multiple z/OS sysplexes, the primary z/OSMF instance sends HTTPS requests to each secondary z/OSMF instance, receives the HTTPS responses from the secondary instances, and displays the appropriate information. For this communication process to work correctly, the primary z/OSMF instance must be at least z/OSMF V2R1 and the secondary instances must be at least z/OSMF V2R1 with APAR PI32148. The level of the primary z/OSMF instance must be higher than or equivalent to the level of the secondary z/OSMF instances.

Identifying tasks that you can use to manage multiple z/OS sysplexes

For z/OSMF tasks that allow you to manage multiple z/OS sysplexes from a single z/OSMF instance, the target chooser () menu follows the task name in the z/OSMF navigation area. Click the target chooser menu to select the target to which to connect the corresponding z/OSMF task. The menu lists the systems, sysplexes, CPCs, and groups that are defined in the Systems task in the primary z/OSMF instance.

Working with tasks that can manage multiple z/OS sysplexes

After you select a target, z/OSMF opens the task in a tab in the z/OSMF work area and includes the selected target in the tab header. A separate task tab is created for each unique task and target combination, and each tab displays a consolidated view of the data collected from the selected target.

If you select a sysplex, CPC, or group as the target, a multiple system () icon follows the page title within the tab. Place your cursor over the icon to display a list of the systems and sysplexes for which data is shown. Because data is consolidated from multiple systems, the persisted table settings specified for the primary z/OSMF instance are used and all other persisted table settings are ignored.

If you select a single system as the target, a single system () icon follows the page title within the tab. No hover information is provided for this icon because the system to which you are connected is identified in the tab title in the format sysplex-name.system-name. Because the data shown in the tab is from a single system, any persisted table settings specified for that system are used and all other persisted table settings are ignored.

Using application links between tasks that provide multi-sysplex support

Some z/OSMF tasks provide user interface elements, such as actions, buttons, or links, that launch another z/OSMF task or external application when you interact with that element. The feature that provides this capability is called application linking.

In the application linking process, the task from which you made the request is called the event requestor, and the task that processes the request and is launched is called the event handler. If the event requestor supports multi-sysplex scope, the event handler must also support multi-sysplex scope. Otherwise, the application link will fail.

When the application link is successful, the event handler is opened using the same target as the event requestor.