This is a description of what happens during an IPL when console take over is enabled and more than one LAN-connected device is available.
The LAN devices will be called LAN1, LAN2, and LAN3. The IPL is being performed in unattended (Normal) mode.
At the point in an IPL when the console device is being determined, it is more or less a race condition if more than one device is connecting at a time. The first device to connect, of the type specified by the console mode setting (LAN in our example), becomes the console and will be presented with the usual console screens.
For our example let's say LAN1 is the first device connected. During the IPL this device will show the IPL status changes just like any other console and eventually the i5/OS™ sign on window. LAN2 and LAN3 will show a special DST signon screen with a new line of data stating ATTENTION: This device can become the console. The rest of the window will be the same as any other DST signon window. At LAN2 a user with the user privilege of take over console signs on. This user will now be presented the same Console Information Status screen and the take over the console field will show a YES indicating that take over is possible. At LAN3 a user without the take over console privilege signs on. The take over the console field will show as NO since the user does not have the correct authority for take over.
At this point only one device has met all the conditions for a console take over. At the bottom of the screen is F10=Take over console connection. Pressing F10 will present the user with the Take over Console Connection From Another User screen. This is a confirmation screen that gives the user a last chance to cancel the take over. Selecting 1 and then pressing Enter at this point will cause the take over to occur. Almost immediately, LAN1 will get the special DST signon screen and LAN2, the device that initiated the take over, will have the exact same screen LAN1 had when the transfer took place. The job, if something was running, doesn't even know this action took place. In fact, the original console could have been installing Licensed Internal Code or i5/OS or even running a complete system save in restricted state and the server would not know it. You could even disconnect the console connection and come back later, reconnect, and you will get the current job's screen data and the job would never miss a beat. If a large amount of screen data was sent by the job and could not be delivered, the data will be stored until later. When a console reconnects, by an authorized user (has the take over console privilege) from an eligible device, the user may see fast screen refreshes until all the stored data has been delivered. Actually, doing a disconnect and a reconnect is considered a recovery (not a take over).
The data present at LAN3 will not change after the take over. Currently, there is no method to automatically refresh the data. However, if the user at LAN3 pressed Enter, a manual refresh of all fields except the Take over the console field would occur. The user would have to exit this screen and sign on again to see the change to that field.