Scenario: A Normal Ipl And Dual-Connectivity Configurations With Take Over Enabled - IBM i Series Handbook

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.
When the console device is being determined in an IPL operation, more than one device might be
|
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. Each additional
device that connects will be presented with one of two screens.
|
| For this example, suppose LAN1 is the first device connected. During the IPL, this device shows the IPL
status changes just like any other console. LAN2 and LAN3 present a special DST sign-on with data
|
stating "ATTENTION: This device can become the console". The rest of the window is the same as any
|
| other DST sign-on window. The device known as CABLED does not initially connect because it is not a
console type of LAN. If the asynchronous communications line were to be activated with a function 66
|
however, the user would see the Console Information Status display showing data related to the current
|
| console. The field Take over the console shows no because 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 is now
|
presented with the same Console Information Status display but the Take over the console field shows 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 shows as no because the user does not have the correct authority for
|
| take over.
44
System i: Connecting to System i Operations Console