This scenario describes what happens during the process of starting the server when console takeover is enabled and more than one Operations Console connectivity is being used. That is, a local console directly attached device, of which there can only be one, is connected and three Operations Console LAN devices are connected.
Setting: The console type is set to Operations Console (LAN). The directly attached PC is called CABLED, and the LAN PCs are called LAN1, LAN2, and LAN3. The mode is unattended (normal mode) and the server is IPLing. At the point in the IPL when the console device is being determined, the first device to connect, of the type specified by the console setting (LAN, in our example), becomes the console and is presented with the usual window a console receives for the type and circumstances in which the server was started. Each additional device that connects is presented with one of two windows.
In this example, LAN1 is the first device connected. During the process of starting the server, this device displays the status changes like any other console and eventually the i5/OS® Sign-on window. LAN2 and LAN3 display a special DST Sign-on window with a new line of data stating, ATTENTION: This device can become the console. The rest of the window is the same as the DST Sign-on window. The device called CABLED does not initially connect because it does not meet the console type of Operations Console (LAN). However, if the asynchronous communications adapter is activated with a function 66, it is taken directly to the Console Information Status window where the user can see data related to the current console. The Take over the console field displays NO since it is not of the correct type, which is Operations Console (LAN). At LAN2, a user with the privilege to take over the console signs on. This user is now presented with the same Console Information Status window and the Take over the console field displays YES, indicating that takeover is possible. At LAN3, a user without console takeover privilege signs on. The Take over the console field displays NO because here the user does not have the correct authority for takeover.
At this point, only one device has met all the conditions for a console takeover. At the bottom of the screen is F10=Take over console connection. Pressing F10 presents the user with the Take over Console Connection From Another User window. This is a confirmation window that gives the user a last chance to cancel the takeover. Selecting 1 and then pressing Enter at this point causes the takeover to occur. Almost immediately, LAN1 receives the special DST Sign-on window and LAN2, the device that initiated the takeover, receives the exact same window LAN1 received when the transfer took place. The job, if something was running, is not aware this action is taking place. In fact, the original console can be installing Licensed Internal Code or i5/OS, or even running a complete system save in the restricted state, and the server is unaware of it. You can even disconnect the console connection, reconnect, get the current job's screen data, and the job is unaffected. If a large amount of screen data is sent by the job and cannot be delivered, the data is stored until later. When a console reconnects, by an authorized user from an eligible device, the user might see fast screen refreshes until all of the stored data is delivered. Actually, doing a disconnect and a reconnect is considered a recovery (not a takeover).