80 Achieving the Highest Levels of Parallel Sysplex Availability
been fixed—it now provides an unlocked command entry area; previously you had to open
a command window every time you wanted to issue a command.
The Console Availability Feature, available as a non priced feature for z/OS 1.4 and
integrated into z/OS 1.5, will further improve system console support by providing an
automatic means for enabling and disabling the flow of messages to the system console. The
consoles specified in the new AUTOACT console group can be used to control when
messages flow to the system console: If none of the consoles in the group are active, the
system console will automatically be put into problem determination (PD) mode. (PD mode is
discussed in z/OS MVS Planning: Operations, SA22-7601.) If any console in the group is
active, the console will be taken out of PD mode, if it had previously been automatically put
into PD mode. The consoles specified in the group can be of any type (MCS, SMCS, or
EMCS) and may be attached to any system in the sysplex. For installations using SMCS
consoles, this support will ensure that messages will be sent to the system console when
VTAM (required by SMCS) is not available.
If only SMCS consoles are used, the system console plays an important role in
availability—NIP messages and SYNCHDEST messages will be displayed on the system
console. If the VTAM fails and all SMCS consoles become unavailable, the system console
becomes the “console of last resort” and must be used to re-establish system availability.
Even though we do not in general recommend the use of the HMC as a console, there is a
situation where it can provide valuable benefits. An advantage of using the HMC is that you
can scroll back and see messages issued earlier in the NIP (IPL) process, whereas with a
channel-attached NIP device, once the messages roll off the screen, they cannot be viewed
until the system is fully up and running. This can be very helpful when trying to diagnose
problems early in the IPL process.
3.2.4 Hardware consoles
Certain sysplex-related hardware devices have their own consoles, specifically, ESCON
Directors and Sysplex Timers. The consoles for both these devices are LAN-attached, and
both devices support more than one console.
q We recommend having at least one console for each device type (it may be acceptable to
use a single PC to fulfill both console functions) in the Operators area, and at least one
other console close to the hardware for the service representative to use during
maintenance or repair.
3.2.5 Console setup recommendations
When the console component of MVS was originally designed, 1 MIPS was a large system.
As the size of CPCs has grown, and the console component has grown to include all systems
in a sysplex, the console component must handle volumes of messages hundreds or
thousands of times higher than it was designed for. As a result, it is possible to encounter
console-related problems that in some cases can impact availability.
The Console Restructure, initially delivered as a separate feature on z/OS 1.4, is intended to
change the way the console works, bearing in mind these new loads. Until the Console
Restructure code is installed, there are things that can be done to reduce your chances of
having a console-related problem. This section contains an extensive list of things you should
or should not do to minimize the risk of encountering a console problem.
q Ensure that there are a minimum of two MCS or SMCS consoles configured in the
sysplex, and that there are no single points of failure related to these consoles. While it is
possible to use the HMC as an operating system console, we strongly recommend against
this. The HMC is the primary mechanism for alerting operators to hardware problems, and