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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Summary of Contents for System i
Page 1: ...System i Connecting to System i Operations Console Version 5 Release 4 ...
Page 2: ......
Page 3: ...System i Connecting to System i Operations Console Version 5 Release 4 ...
Page 8: ...vi System i Connecting to System i Operations Console ...
Page 120: ...112 System i Connecting to System i Operations Console ...
Page 124: ...116 System i Connecting to System i Operations Console ...
Page 125: ......
Page 126: ... Printed in USA ...