Because the sysplex affects the way you use consoles to receive messages or send commands, you need to consider how sysplex functions can affect automation. Consider the following in a sysplex:

Console definitions

Console names for MCS, SMCS, and extended MCS consoles allow automation products like NetView® to reference consoles throughout the sysplex regardless of their system attachment. The names must be unique for each console in the sysplex. (See Using console names.)

You can define extended MCS consoles to handle message and command processing as part of your automation in a sysplex. In a system or sysplex, defining extended MCS consoles allows you to exceed the 99-console limit for MCS and SMCS consoles. (See Extended MCS consoles.)

Logging activity

Because the impact on hardcopy logging for systems in a sysplex is increased, analyzing the results of message and command logging for a sysplex becomes more complex than for a single system. For example, a message received on one system might have originated on another system where it has already been logged. How a system issues a command in a sysplex can affect how other systems log command responses. See Message and command flow in a sysplex.

Understand that defining more consoles in a system or sysplex means that more hardcopy logging can occur. For extended MCS consoles in a sysplex, you can specify LOGCMDRESP=NO through RACF® OPERPARM or on the MCSOPER macro to control logging for the console. As a result, command responses are not logged for the extended MCS console, and you can reduce the impact of hardcopy logging in the sysplex.

Parmlib

Because CONSOLxx and MPFLSTxx are crucial to control message and command processing, you must define these parmlib members so that they work together for all systems in a sysplex. For example, console attributes defined in CONSOLxx have either system or sysplex scope. As a result, these differences can affect console operations in the sysplex. MPFLSTxx has system scope so you must consider how differences in MPFLSTxx for each system might affect overall operations in the sysplex. (See Using CONSOLxx and MPF and MVS operations planning.)

Message and command processing

In a sysplex, you need to consider the scope of your message and command processing. Messages and commands can flow from system to system. In order to coordinate automation functions for the entire sysplex, automation products on different MVS™ systems need to take this message and command flow into account. (See Message and command flow in a sysplex.)

Installation exits for messages and commands must also take into account message and command routing in a sysplex. Although messages and commands can be routed to different systems in a sysplex, you must take into account where the message or command is issued, the systems that receive the message or command, how and when the exits get control, and when automation programs receive the message or command. These considerations can have an impact on how an automation program like NetView processes messages and commands that first pass through installation exits. (See Installation exits for messages and commands and Message and command flow in a sysplex.)