94 lines
6.5 KiB
HTML
94 lines
6.5 KiB
HTML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!DOCTYPE html
|
|
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
|
<html lang="en-us" xml:lang="en-us">
|
|
<head>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
|
<meta name="security" content="public" />
|
|
<meta name="Robots" content="index,follow" />
|
|
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
|
|
<meta name="DC.Type" content="reference" />
|
|
<meta name="DC.Title" content="Scenario: A normal IPL and dual-connectivity configurations with take over enabled" />
|
|
<meta name="abstract" content="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." />
|
|
<meta name="description" content="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." />
|
|
<meta name="DC.Relation" scheme="URI" content="rzajrconsolescenarios.htm" />
|
|
<meta name="copyright" content="(C) Copyright IBM Corporation 2000, 2006" />
|
|
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 2000, 2006" />
|
|
<meta name="DC.Format" content="XHTML" />
|
|
<meta name="DC.Identifier" content="scenariotakeover2" />
|
|
<meta name="DC.Language" content="en-us" />
|
|
<!-- All rights reserved. Licensed Materials Property of IBM -->
|
|
<!-- US Government Users Restricted Rights -->
|
|
<!-- Use, duplication or disclosure restricted by -->
|
|
<!-- GSA ADP Schedule Contract with IBM Corp. -->
|
|
<link rel="stylesheet" type="text/css" href="./ibmdita.css" />
|
|
<link rel="stylesheet" type="text/css" href="./ic.css" />
|
|
<title>Scenario: A normal IPL and dual-connectivity configurations with take
|
|
over enabled</title>
|
|
</head>
|
|
<body id="scenariotakeover2"><a name="scenariotakeover2"><!-- --></a>
|
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
|
<h1 class="topictitle1">Scenario: A normal IPL and dual-connectivity configurations with take
|
|
over enabled</h1>
|
|
<div><p>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. </p>
|
|
<div class="section"><p>The console mode 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.</p>
|
|
</div>
|
|
<div class="section"><p>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.</p>
|
|
</div>
|
|
<div class="section"><p>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 <span class="keyword">i5/OS™</span> 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 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 mode 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.</p>
|
|
</div>
|
|
<div class="section"><p>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 <span class="keyword">i5/OS</span> 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).</p>
|
|
</div>
|
|
</div>
|
|
<div>
|
|
<div class="familylinks">
|
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzajrconsolescenarios.htm" title="The following scenarios will help you understand the take over and recovery options.">Scenarios</a></div>
|
|
</div>
|
|
</div>
|
|
</body>
|
|
</html> |