IBM System i Manual page 72

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 type 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
takeover 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 takeover.
At this point, only one device has met all the conditions for a console takeover. At the bottom of the
window 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 gets the special DST sign-on window and LAN2, the device that initiated the
takeover, has the exact same window that LAN1 had when the transfer took place. The job, if something
was running, does not know that this action took place. In fact, the original console could have been
installing Licensed Internal Code or the i5/OS operating system, or it could have been running a
complete system save in restricted state and the system does not know it. You can even disconnect the
console connection and come back later, reconnect, and you can still get the current job's window data. If
a large amount of window data was sent by the job and could not be delivered, the data will be stored
until later. When a console is reconnected by an authorized user (has the takeover console privilege) from
an eligible device, the user might see fast window refreshes until all the stored data has been delivered.
Actually, doing a disconnection and a reconnection is considered a recovery (not a takeover).
The data present at LAN3 will not change after the takeover. 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.
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
|
64
System i: Connecting to System i Operations Console