Planning for distributed mode

There are things that you need to consider before migrating to distributed mode.

Note: The following discussion regarding console attributes applies only to MCS, SMCS, and subsystem consoles; it does not apply to EMCS consoles (except as noted).

In distributed mode, changes to the attributes of a console persist only while the console is active. When a console is deactivated, its attributes revert to their original values. The original values for consoles in distributed mode are established either when the console is first defined or when the sysplex enters distributed mode with the SETCON MODE=DISTRIBUTED command. More specifically:

For MCS and subsystem consoles, the original attributes are:
- The values specified in CONSOLxx.
- The values that were in effect when the sysplex most recently entered distributed mode.
SMCS console definitions are shared across the sysplex. The original attributes of SMCS consoles are:
- The values specified in CONSOLxx of the first system to define the console (subsequent definitions of the same console are ignored).
- The values that were in effect when the sysplex most recently entered distributed mode.

There are a few exceptions to the rule. The following console attributes persist when a console is deactivated:

The last system on which the console was active overrides the SYSTEM attributed specified in CONSOLxx.
The LUNAME attribute for SMCS consoles.
The LOGON attribute for SMCS consoles.

If you want to change the original attributes of a console, you must redefine the console.

For MCS and subsystem consoles, update CONSOLxx to reflect the desired attributes and re-IPL the system. The original attributes of the console will be updated only on the system that is IPLed.
For SMCS consoles:
- Ensure that the console is not active. Use the IEARELCN sample program to delete the console definition.
- Update CONSOLxx to reflect the desired attributes and re-IPL any system in the sysplex. The original attributes of the console will be updated on all systems in the sysplex.

An alternate method for changing the original attributes of an MCS, subsystem, or SMCS console is:

Migrate backwards to shared mode.
Update the attributes of the consoles as desired.
Migrate forward to distributed mode.

Note: This is potentially disruptive to your operations and should only be used if you have not exploited the ability to define more than 99 MCS, subsystem, or SMCS consoles. See Migration and fallback considerations.

In distributed mode, you cannot alter the attributes of inactive consoles (including EMCS consoles) with the following exceptions:

The LUNAME attribute for SMCS consoles.
The LOGON attribute for SMCS consoles.

In distributed mode, you cannot alter the type of a console. The console name retains the console type until the console is deleted using IEARELCN or IEARELEC.

In distributed mode, the health checker will only report on inactive MCS and SMCS consoles that are defined on the system on which the health checker is running.

In distributed mode, console IDs for MCS, SMCS and subsystem consoles no longer have to be in the range of 1-99. Therefore, the use of console names and the CNZCONV service are recommended when trying to find information pertaining to consoles.

If you have any local program that examines the console UCME array, you must use the CNZMXURF service to access the array and your program must obtain the local and CMS locks before invoking the CNZMXURF service. To obtain the CMS lock, your program must be authorized. Your programming must also be able to tolerate console IDs that are not the same as a console’s array index. Also, the UCME array will contain only information about MCS, SMCS and subsystem consoles that are active on this system. The tracking facility will identify users of the CNZMXURF service that are not holding the CMS lock. IBM® recommends using the CNZCONV service for obtaining information about consoles or parsing the response to the DISPLAY CONSOLE command.

In distributed mode, if a console is already active on another system and you attempt to issue certain VARY commands from this system, you will see different messages from what you receive in shared mode. For example, an MCS console named STEVE is both defined on SYS1 and SYS2 in the sysplex. The console STEVE is already active on SYS1. The table below lists the commands issued from SYS2 and the messages in response when the console services support is in distributed mode and shared mode.

VARY command issued from SYS2	Message in response, distributed mode	Message in response, shared mode
VARY STEVE,ONLINE	CNZ0005I CONSOLE STEVE ON DEVICE device1 ALREADY ACTIVE ON SYSTEM SY1 ON DEVICE device2	IEE302I STEVE ONLINE
VARY STEVE,OFFLINE	CNZ0005I CONSOLE STEVE ON DEVICE device1 ALREADY ACTIVE ON SYSTEM SY1 ON DEVICE device2	IEE303I STEVE OFFLINE
VARY STEVE,OFFLINE,FORCE	CNZ0005I CONSOLE STEVE ON DEVICE device1 ALREADY ACTIVE ON SYSTEM SY1 ON DEVICE device2	IEE793I STEVE OFFLINE AND BOXED
VARY STEVE,AS,ON	IEE313I STEVE UNIT REF. INVALID	IEE462I UNIT STEVE IS NOT A VALID DEVICE TYPE FOR THE AUTOSWITCH ATTRIBUTE
VARY STEVE,UNAVAIL	IEE313I STEVE UNIT REF. INVALID	CNZ6001I DEVICE device1 NOT PROCESSED: DEVICE IS NOT A TAPE DEVICE

Note that different messages are issued only when you specify a console name (in the example, STEVE) on those VARY commands. If you issue a device number, like VARY 3D0,ONLINE or VARY 3D0,AS,ON, you will get the same responses as in shared mode.