Scenario: A normal IPL and dual-connectivity configurations with take over enabled
This is a description of what happens during an IPL when console take over is enabled and more than one Operations Console connectivity is being used. That is, a directly attached console device, of which there can only be one, is connected and three Operations Console LAN devices are connected.
The console type is set to Operations Console LAN (3). The directly attached PC will be known as CABLED and the LAN PCs will be labeled LAN1, LAN2, and LAN3. The IPL is being performed in unattended 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. Each additional device that connects will be presented with one of two 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 present a special DST sign-on 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 sign-on window. The device known as CABLED will not initially connect because it doesn't meet the console mode of LAN. If the asynchronous communications line were to be activated with a function 66 however, it would be taken directly to the new Console Information Status screen where the user can see data related to the current console. The field Take over the console will show NO since it is not of the correct type (the console type is set to LAN). 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 but 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 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, does not 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 couldn't be delivered the data will be stored until later. When a console reconnects, by an authorized user and 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).
Parent topic:
Scenarios: Takeover and recovery