Table of Contents
Advertisement
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 OS/400 sign on window. LAN2 and
|
LAN3 will present a special DST signon 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. The
|
device known as CABLED will not initially connect because it doesn't meet the console mode of LAN. If
|
|
the asynchronous 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 mode is set to
|
LAN). At LAN2 a user with the user privilege of service tool security 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 Service Tool Security 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 OS/400, 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).
|
|
Scenario: Recovery of a console requiring a new console mode setting: There may be cases in which you may
have to change the console mode in order to recover from a console error. An example of this might be
|
|
the loss of your network during normal operations. The console mode could be changed using one of
several methods, which include:
|
v DST or SST menus (delayed)
|
v Native macros (delayed)
|
v Console Service Functions (65+21) (Immediate)
|
Only the console service functions (65+21) method will automatically take down the old connection and
|
|
activate all the resources for the new choice. The other two methods may require manual steps to activate
|
the appropriate resources for the new console. These changes also require that the associated resources be
available in a state where they can be used. For example, you are using Operations Console LAN and the
|
|
network fails, the console was in use by your logical partition and you do not have an asynchronous
communications card on the IOP tagged for the console. You would have to either move a card or change
|
the IOP tagging to allow a directly attached console to work. If the change is not required immediately,
|
|
you could also wait for the change to take affect during the next IPL in which case a newly tagged IOP
would allow the directly attached console to connect. In this example, however, we are attempting to
|
change the console's connectivity and use another device right now. The recommended method for
|
|
immediate change is the console service functions (65+21) method. Once that has been successfully
performed, the user must sign on again. Since this scenario is from LAN to directly attached console the
|
new console would not get the special signon screen or the Console Information Status screen since it is
|
64
iSeries: iSeries Access for Windows Operations Console
Advertisement
Table of Contents
