Tertiary Loader

The tertiary loader is loaded by the secondary in a multi-block load starting at location 10000(octal). It will run with memory management on if it exists on the system. The tertiary loader moves itself to the top of physical memory and assigns its stack and buffer space just below itself. It is, therefore, capable of multi-block loads from location 0 up to its buffer ad-

dress, usually the last 1–2K words of physical memory. It requests the operating system to be loaded. The current tertiary loaders do not specify any specific operating system. The choice of

129

Appendix D

LAN Loop Test Examples

The following examples address the application of the Loop Test functions. They are in-

tended as examples of how a higher level process can use the facilities. They are intended nei-

ther as a specification for how they must be used nor as an exhaustive test script.

In the examples, no account is taken of the fact that the Loop Test functions make only one attempt to transmit a message. To increase the reliability of the tests, each interface function that fails due to a communication error should be retried enough times to lessen the probability that an intermittent error occurred.

D.1 Local Control Test Example

In this case, a node finds itself unable tocommunicate with some other node that it believes is on the network and operational. The following test script can be used by the node tocheck

out the problem.

First, LoopDirect is invoked with remoteAddress set at the correct address of the specific re-

mote node, the suspect node. This results in a simplest, two hop frame consisting of:

1. a Forward Data message which specifies the testing node’s address as the forwarding address, containing

2. a Reply message.

This frame is transmitted to the suspect node. If this test succeeds, the communication is possible and the problem may have been either intermittent, the remote node is down, or there is a problem with message length or data pattern. Different message lengths and/or data pat-

terns could then be tried.

If the above test, LoopDirect, results in a return indicating failure, next invoke LoopAs-

sisted, using some other node as assistantAddress. This will construct a loop test datagram as

follows:

1. a Forward Data message which specifies the suspect node’s address as the forwarding address, containing:

2. a Forward Data message which specifies the assistant’s node address as the forwarding address, containing:

3. a Forward Data message which specifies the testing node’s address as the forwarding address, containing:

4. a Reply message.

This frame is transmitted to the assistant node. This four-part datagram obtains the full assistance of the loopback assistant.

If no assistant address is known, invoke LoopDirect with no remoteAddress parameter to

send a simple, two hop loop test datagram to the Loopback Assistance Multicast Address. Use the source address of any responding node as an assistant address. If nocommunication with the Loopback Multicast Assistance group is possible, then the last resort is toobtain a list of

nodes on the network. The list can be obtained by either listening to the Remote Console Multicast Address for the Remote Console System ID messages or obtaining such information

from the network manager. From the list of nodes, select a node for loopback assistant by re-

peating the above procedure. If this fails then repeat the process with other nodes on the list. If this fails with all the nodes on the list, then either noone else is turned on or the local node is broken.

If some loopback assistant node can communicate with the remote node but the local node

cannot, the local node can then test for the direction in which communication does not work. The LoopAssisted function, using the assistant node that responded previously as the assistant,

can be used to detect either transmit or receive problems. This is accomplished using various assistance level, transmit or receive or full, supported by the loopAssisted function. By repeat-

ing the above test with different remote nodes, it can be determined whether the local node or the remote node is at fault, thus isolating the problem to a particular transmitter or receiver.

When a node finds itself unable to communicate, it can report this in whatever high level way is available. An operator or control center can then respond by attempting to isolate and repair the problem.