This scenario describes the cases where you must change the console connectivity to recover from a console error. An example of this might be the loss of your network during normal operations.
The recommended method for immediate change when another workstation is available is to use the OPSCONSOLE native macro. You can use the macro to change the console type value and then perform the function OPSCONSOLE RESET to force the system to use the new console type. For more information on using the Operations Console native macro, see Troubleshooting using the OPSCONSOLE macro.
The recommended method for immediate change when another workstation is not available is the console service functions (65+21). If you are attempting to install, for example, and the console fails, then the only method available to you is the console service functions (65+21). For more information, see Using the console service functions (65+21).
The other methods previously mentioned might require manual steps to activate the appropriate resources for the new console type. These changes also require that the associated resources are available in a state where they can be used. Changes made using these methods take effect the next time you activate the server, in which case a newly tagged IOA allows the local console directly attached to connect.
In this scenario, we are attempting to change the console's connectivity and use another device immediately. You are using a local console on a network (LAN) and the network fails. The console is in use by your logical partition and you have an asynchronous communications adapter available to be tagged for the console. You decide to change the tag to the asynchronous communications IOA to allow a local console that is directly attached to work. You use the alternate procedure (dynamic tagging) to make the tag changes for both the console and Operations Console tags. You also invoke a 65, 21, 21 from the HMC command line to force the system to find and use the new console type.
After the change is successfully performed, the user must sign on again. Because this scenario is from a local console on a network (LAN) to a local console directly attached, the new console does not receive the special DST Sign-on window or the Console Information Status window since it is the only valid console after the console type value change. When the network problem is fixed, the LAN-connected device goes directly to the Console Information Status window and is not able to take control of the console without changing the console type value back to Operations Console (LAN). Takeover is not available when a device is directly connected because only one connection of this type is allowed by the server.