z/OS MVS Planning: Operations
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


Considerations using consoles to display synchronous messages

z/OS MVS Planning: Operations
SA23-1390-00

If you do not specify a console group on SYNCHDEST or none of the consoles on SYNCHDEST are active, the system that issues the message tries to display the message on the system console.

For a sysplex environment, you should understand and plan where your synchronous messages will be displayed.

Synchronous messages can be displayed only on the system where they originated.

The SYNCHDEST console group is an ordered list of consoles where MVS™ is to attempt to display synchronous messages. The system console can be specified in the list. If an MCS console in the list is not attached to the system where the message is issued, it is skipped. So, the same SYNCHDEST group can be used for all systems, if you wish. If a console in the list is an SMCS console, it is skipped.

If the system attempts to use a console for a synchronous message and fails, the next console in the SYNCHDEST group, which is attached to this system, will be used. The system console can be specified in the group, and will also be used as a last resort, if all other console attempts have failed.

If MCS consoles share a control unit and an operator tries to respond to a synchronous message on one of the consoles, interruptions from the other consoles can make it impossible for the operator to reply to a synchronous message. When you plan your sysplex recovery, you should attach the MCS console that is to display synchronous messages to its own control unit without any other attached console. If it shares a control unit, there is a higher probability of failure on the console; the message will then be attempted on the next suitable console in the SYNCHDEST group, or on the system console.

Important: You must respond to synchronous WTOR messages promptly. Synchronous WTOR messages (such as IOS115I and IEA367A) prevent the system from updating its status on the sysplex couple data set. This, in turn, can lead to Sysplex Failure Management (SFM) deciding that the system is not responding normally, and removing it from the sysplex.

If you have a standard response to synchronous WTOR messages such as these, you may want to automate the reply to these messages to avoid delay and avoid SFM partitioning the system out of the sysplex.

Note that MPF and typical automation products are unable to automate a response to these messages. However, Auto-reply is able to automate these messages.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014