Digital PDFs

MAINDEC-11-DXCBC-B-D

January 1977

19 pages

Original

1.5MB

Document:	DECnet DEC X11 Users Guide
Order Number:	MAINDEC-11-DXCBC-B-D
Revision:	0
Pages:	19
Original Filename:	http://bitsavers.org/pdf/dec/pdp11/xxdp/MAINDEC-11-DXCBC-B-D_DECnet_DEC_X11_Users_Guide_Jan77.pdf

OCR Text

IDENTIFICATION
PRODUCT CODE!

MAINDEC-I1-DXQBC-B-D

PRODUCT NAME:

DECNET DEC/Xli USER'S GUIDE

DATE:

JANUARY 1977

MAINTAINER:

DEC/Xl1 DIAGNOSTIC GRODP

THE INFORMATION IN THIS DCCUMENT IS SUBJECT TO CHANGE WITHOUT
NOTICE AND SHOULD NOT BE CONSTRUED AS A COMMITMENT BY DIGITAL
EQUIPMENT CORPORATION. DIGITAL EQUIPMENT CORPORATION ASSUMES NO
RESPCNSIBILITY FOR ANY ERRORS tHAT MAY APPEAR WITHIN.
THE SOFTWARE DESCRIBED IN THIS DOCUMENT IS FURNISHED UNDER A
LICENSE AND MAY ONLY PE USED OR COPIED IN ACCORDANCE WITH THE
TERMS OF SUCH LICENSE.
DIGITAL EQUIPMENT CORPOPATION ASSUMES NO RESPONSIBILITY FOR THE
USE OR RELIABILITY OF ITS SOFTWARE ON EQUIPMENT THAT IS NOT
SUPPLIED BY DIGITAL.
COPYRIGHT

(e)

1976, 1971 DIGITAL EQUIPMENT CORPORATION, MAYNARD, MASS.

Page 2

How to use DEeNET DEC/Xli Modules

IJO

INTRODUCTION
Every installation has one particular
configuration
of
communications equipment and it would be nice if this product,
DECNET DEC/Xli {D.O.}, would match your installation perfectly
with no modifications. However, since we are required to test
many installations, you, the user, must custom tailor your
D.O.
eXerciSer to match your equipment.
The number of
variations possible with communications equipment is almost
endless,
and if you match 99% of the D~D.
exerciser
characteristics to your installation characteristics it is
still not good enou~h.
You must specify a D.O. exerciser
that EXACTLY matches your equipment to avoid wasted hours of
chasing
nnon-bugs".
I f you successfully build a D.D.
exerciser you will have a very useful product.
The D.O.
exerciser cap now do complete DEC/Xi1 system exercising whiie
simultaneously exercising all your communications lines, using
the exact same data paths and data links as the operatinq
system normally run on your system. Every attempt has been
made such that a user of D.D. can build and use an exerciser
without requiring any documentation on hand, if, and this is a
big if, he has a complete knowledge cf normal DEC/XlI building
and running and he has read and understood this entire
document.
If you corre across any instance where this is not
true, please notify the DEC/XlI group in Maynard and the
situation will be remedied. If you are completely unfamiliar
with communication equipment, I suggest you get and read
IntrodUction to Data Communication by Murphy and Kallis, and
Introduction to Miniconputer Networks by Stelmach. These are
both small, easy reading paperbacks available from DEC.

240

BUILDING A DEeNET DEC/XI1 EXERCISER
******************************************
You must be familiar with building a
norrral DEC/XII exerciser. If you are not,
please read, and then build and run some
exercisers before continuing on with this
section.
******************************************

2~1

Modules Required
There is a one-to-one correspondence hetween communications
options which D.O.
supports and D.D. modules used to test
these options. The v.v.
modules have a ~ letter name,
NXO?OEJ, where, NX is formed by replacing the D in a
communications option name with an N, the 0 is an option
selection, and?
is the revision letter. (Throughout the
rest of this document, a 7 as the last charcater in a module
naroe
indicates the latest revision available.) For example,

Page 3
the first D.O. module written to test the DLI1-E option was
called NLAA.CBJ. NL comes from changing DL to NL, the next A
indicates which ontion type. (In the case of the DL, there
are no others to confuse it with, but if a DLXll module was
ever manufactured, the module name for it would be NLBA.OBJ.)
modules will, in general, support 16 lines per module.
D.D.
In the case of a single line device, such as the DUll, the
NUA?
module will handle up to 16 devices, in the case of
multiplexor devices ~ith 16 lines, only one device
is
supported per module.
So if your system had 2 OHll's, you
would have to configure 2 NHA? modules to drive all 32 lines.
The exception to this rule will be the DZ module, NZA?, which
only supports 1 device, eight lines.
In addition to these device dependent modules, 2 extra utility
modules must be configured to support any D.O. module. The
first, NlA?OPJ, contains a message buffer used by all D.O.
modules to tr2nsmit from.
In addition, it contains many
coromon subroutines which all D.D. modules use.
This helps
keep down the size of the D.O. modules. The second module,
N2A?CBJ, serves as a "synchronization" module, it gives all
systems beinq exercised in the network a "pause" point, to
enable all data links to be established. It also services any
DNl1·s (auto-call devices) which a system might have. Lastly,
a clock module must be configured, either KWA?
or KWH?
These modules keep a system time for the DEC/X11 monitor.
D.D. modules h?ve many time out loops which are implem~nted
by using this system clock.

******************************************
In the future, a fake clock module, K.X?,
will be written, this will be a background
module which will up the system time, but
in an extremely inaccurate manner. This
will zllow D.D.
modules to be run on
systems without a KW11-L or KW11-P clock.
The time-out loops in the D.O.
modules
will likely become undesirably long; but
this cannot be avoidec.
******************************************
For any given communication option, there will likely be two
DEC/XI1 modules, the normal one whose fjrst letter of the name
is a D (e.g., DLA?), and a DEeNET CEC/Xll one, whose name
starts with an N (e.g., NLA?). They are mutallv exclusive.
You should not configure t~o modules to test the same device.
It is ok to, for example, configure DLAF to test one DLll-E
and NLA? to test a second, but extreme care must be taken not
to have 2 modules trying to test the same device. In the case
of a multiplexor, such as the DJ1!, it is impossible to test,
say, 4 line~ in ilECNET DEC/XII mode, and the 12 in normal
DEC/Xl1 maintenance moce, at the same time.

Page 4
2~2

The order of ~odules
In normal DEC/XII, there are no ordering constraints with
regards to modules. They can be configured in any order you
desire, with the possible exception of the clock modules.
They should be configured directly after the monitor to insure
the run time is not made inaccurate by any delay in the clock
module being initiated, but this is not a requirement. When
bUilding a D.D. exerciser, there are some very definate rules
about ordering of modules. In particular, directly after the
monitor, the NIl? mod~le must be configured.
FollOWing it,
in any order, ALL C.D. modules must come, followed by the
N2A? module. Next the clock module should come, followed by
all the rest of the normal DEC/XlI modules in any order. This
results in a exerciser that looks like:
Monitor (normal DEC/Xl1 or 11/10 monitor)
NIA?
N?A?
!lny and all
!D.D.

type

!mocules
N?A?
N2A?

KW??
XXXX

xxxx

Clock module
IAny normal
IDEC/Xl1 modules
lin any oreer.

This results in a "sandwich" of all D.O.
modules with NIA?
on top and N2A?
on
bottom~
If these ordering rules are
violated many different errors will result.
If no clock
module is included in the configuration, the exerciser will
halt itself after typing a message, and will therefore be
useless. The library file which contains all these D.O. type
modules has Nil? as the first module and N2A? as the last,
so when using the ~AKE command to build an exerciser, this
library should be specified after the monitor library and this
will guarantee the correct order of modules.
2J3

Module Parameters at Configuration Time
When building a D.O. exerciser, OVA, VCT, BRI, BR2, DVC, and
SRI can all be specified, exactly as is done in normal
DEC/Xl1. DVA and veT should be the lowest addreSS of the
devices which anyone module is intended to exercise. BRl and
BR2 should he the highest of the devices receiver and
transmitter
bus
request levels, respectively.
DVe, at
configuration time, is the number of lines to be tested for
that module. It is converted into a bit map in the resulting
exerciser. SPl should be set to a bit map, with bits=1 for
lines which should act as Master and 0 for lines to act as
Slaves. ~aster and Slave are defined in section 3.
For
example, if your system had 3 DU11#s, with the following
hardware parameters:

Page 5
#1

OUll , at 175610 and vector at 400, receiver priority of 5
and transmitter priority of 5, to be tested as a Master.

DUll, at 175620 and vector at 410, receiver priority of
and transmitter priority of 5, to be tested as a Slave.

DUll, at 115630 and vector at 42C, receiver priority of 6,
and transwitter priority of 5, to be tested as a Master.

You would configure the NUl? module, specifying DVA of 175610
(the lowest of the 3), vector of 400 (the lo.est of the 3).
BRI as 6 (the highest of the receivers) and BR2 of 5 (the
highest of the transmitters)~
Dve should be 3, meaning 3
lines to be tested, however, if you examimed location 14 in
the header of NUA? in the resulting run time exerciser, you
would find it was a 7, being 3 binary bits on, one for each
line. SPl should be a 5, being bit C on, bit 1 off, and bit 2
on, corresponding to the Master, Slave, Master testing modes
which we wanted for line 0, 1 and 2. All of these parameters
may be altered when running the exerciser, but remember the
ditferent method of representing Dve at configuration and run
time. If the bit for a line is not set in DVe, this means the
line will not be accessed at all, so the corresponding bit in
S~l will have no meani~g.
None of these 6 parameters have any meaning for the N1A?
module.
For the N2A? module SRI should be zero unless you
have 1 or more DN-11·s, in which bit 0 should be set to a one.
NOTE , this ON-11 option is unsupported so
hardware has been available to test it on.

far

because

Set DVA for the N2A? roodule to the lowest device address of
your DN-l1·s, VeT to the lowest vector of your ON-ll's, and
BRl to the interupt level.
3.0

TESTING THE NFTWORK NOCE
After successfully building a D.D. run time
are now ready to test your Network Node.

3Jl

exerciser,

you

Which Tests to Run
To assure correct identification of any problems, I would
strongly recommend running stand-alone diagnostics on all
devices first. If they all pass, you should run a normal
DEC/XlI exerciser which exerCises all deVices, including the
communication equipment. If this passes, then continue on and
attempt to run DEeNET DEC/XII.
Of course there are many
exceptional cases where this "bottom up" testing is impossible
for time or other reasons. If you are positive a problem is
in some specific communication device, then you might skip
running diagnostic on all the other equipment and just run the
stand-alone on that one communications device, if that passes
you should then run regular DEC/Xl1 to all the devices, and

Page 6

only then, run DEeNET DEC/Xll. If yeu do not think there are
any problems with the system and only want to run a confidence
test on the system or the quality of the communication links,
yOU
might go directly with OECHET DEC/Xll, but if problems
deveiop you should fall back to the simplest test which will
fail, either normal DEC/Xll, or preferably, a stand-alone
diagnostic.
3J2

Running DEeNET DEC/XI1, Overview
NOTE
Reference is made to "multi-drop" testing and Dtili
auto-call
units
throughout
thi~
document
and
individual DECNET DEC/Xll module documents.
Both
these
features are "designed in" but completely
untested and will not be supported until some future
unknown date.
First boot the system, load and start the D.O. exerciser. It
will look exactly like normal DEC/Xll~ You can use the MAP
command to find out which and where the modules are. You can
use the MOD corrmand to rrodify any Parameters or options. you
can use the SFL and DES commands to turn on and off modules.
******************************************
WARNING
The N1AA, N2AA, clock, and at least 1
DECNET
DEC/XII
module
must be left
selected j f any D.O. module is selected.
You should not select N1AA without N2AA
and at least I DEeNET module, etc. It is
perfectly all right to deselect NIA?, N2A?
and ALL D.O. type modules, and just run
nor~al
modules, or deselect all normal
modules and run just N1A?, N2A?, clock,
and one or more D.O. modules, but any
D.D.
type module which
is
selected
positively requires NIl?, N2A?, and the
clock, to be selected, and they in turn,
if
selected, expect at least 1 D.O.
module to be running.
******************************************

The first time an exerciser is run, it will type out a table
of error codes and their me2nings for D.D, modules. This is
further explained in the section on errors. (Leaving bit 0 up
in the switch register will inhibit this typing)
First deselect NIA?, NLA?, and ALL D.D.
modules and select
all other modules, Pun this for 10 minutes, or long enough tor
every module to make 2 passes, whichever is longer.
Next,

Page 7
deselect 211 woou1es and select NIA?, N2A?, and all D.D. type
modules, and the clock module. Run this, It will not begin
running all modules yet.
It will ask you to select which
message you want to use for Network testing.
You have a
choice of all zeros, all ones, alternating 1 and O~s, a digit
count pattern, or a precanned ASCII message, (called the
standard message). These are all 501 character long messages,
plus 11 characters which get added as a header and CRe's. You
can also type in any message you choose which will also have
11 characters added to it. Lastly, ~ou can specify to use the
message
Which
was previously specified.
(This is for
re-starting the exercising when you have not re-booted.) This
message which you specify is the only message which the D.O.
modules will use. It is very important that any node which
you are connected to, must use the EXACT same message,
otherwise, you ~ill have false errors reported.
At this
point, the NIl?
module will do an end of pass call and,
because it is a special NBKMOD, it will not run any more
passes.
More about this will be mentioned later in this
document.
Next, each one . f the DECNET DEC/XII modules will be started,
in turn. When started, they will check to see which lines you
have selected to test (by the DVe co~mand when configuring or
by MCD'ing location 14 in the module's header). For each line
selected, the module will ask if the line is to be tested in
full duplex or not (not means half duplex). Remember that
although most of Oigit21's communicatio~ equipment is capable
of running full duplex, many ~odems are not. If the modem for
that line is not, you reust run halt duplex. Next it will ask
for each line selected, if that line is to be tested in
Multi-drop mode or not (not means point-to-point).
If the
answer is yes, it ~ill ask for the station address of that
multi-drop line, or if that line has been selected as a Master
in SR1, it ~ill ask for station addresses to be tested
repeatedly until either 15 addresses have been entered or a
(minus Sign) iF typed. By far and away the most common lines
are half-duplex and point-to-point. When the module has this
information, it then sets the Data Terminal Ready line to the
mocem. A modem can not make and maintain a connection to
another modew unless both modems have their Data Terminal
~eady lines selected.
The module will then EXIT to the
monitor and wait for a Global location called WAIT in the N2AA
module to be cleared, indicating that ell phone connections
have been made.
This sequence is repeated by each D.O.
module selected until they have all been started.
By
modifying location 164 in module N1A?
to a 000001, the
questions about lines will not be asked each time the
exerciser is started.
If the line parameters need to be
changed, this location must be cleared. While answering line
questions about a particular module, the "@t1 character will
skiP the rest of the questions for that module and leave the
remaining ?arameters unchanged.
Next the N2AA module is started.

It, if SRl has

bit

set,

Page 8

will ask for a phone number to supply to a DN11 auto call
option. It will then ~ttempt to make the phone call, if it
fails, it will type out;
DN ERROR X
where X is;
o when present next digit bit is not set
1 ~hen power in the auto-call unit failed or abandoned call
and retry bit was set
2 when the software timed out while waiting for a call to
complete
~ _hen power is not on in auto-call unit
After it makes that call it returns for another number until
only a carriage return is typed, indicating no more DN11's.
Next, or first if SRI ~as 0 indicating no DRIl's, the module
will type a message requesting the operator to dial all manual
connections, and type a carriage return when complete.
It is important that all nodes in the Network being tested
have this message (or the 'PI' message if DN11's are selected)
typed out before any prone connections are attempted. This is
the only way you can guarantee that all modems have had their
Data Terminal Ready line set. When ALL nodes have had the
message for manual phone connections or the DN11 prompt for
the first ohone number (P#) typed, the operators at each node
should
make
the
required
automatic and manual phone
connections, typing the carriage ret~rn when done. This last
carriage return is really the start of DEeNET DEC/XII testing.
Immediately after it is typed, the global location WAIT is
cleared, allowing all D.D.
modules to begin attempting to
transmit and receive the message specifierl~ Also, all normal
D~C/Xll
modules (if selected) .ill be started. The N2A?
module will then drop itself because it is no longer needed.
If this groun of modules runs successfullY for at least 8
passes each, you should then select all modules and attempt to
run again. Locetion lf4 in module N1A? can be MOD'ed to a
000001 if yeu want to skip the question and answer dialogue
regarding multi-drop or not and full-duplex or not.
If you
later want to change these parameters, this location should be
set back to zero before running~ Also, when answering these
questions for multi-drop and half-duplex, a u@" and carriage
return indicates you do not wish to modify any wore of these
types of parameters for this module.
3~3

Legal Network Node Configurations and Modes
Anyone line of a co~rnunications option may be connected to
many different "ends" and this line may be run in many
an
different moc~~.
Furthermore, anyone node running
exercIser \..cp have nany such lines and each line can be
running in different moaes and connected to different type
"ends".
As you can see, this can become quite complicated.
To make it any simpler envolves taking away features and
options, which is not desirable. I strongly recommend that a
Network map be drawn showing each Node, ~hat it is connected

Page 9
to eacb other node by (device type, address, vector, modem
type, data link type, baud rate, and half or full duplex), and
what software the Nodes will be running. If this is done
carefully, many problems, such as connecting asynchronous
devices to synchronous modems or connecting devices with
unlike baud rates, can be avoided.
343.1

Wh'at Can aLine be Connected To?

Any O'ne line from a cODmunication device can be connected to:
a.

lay simple "loop back" device which turns the transmit
51_a15 around to the receive side. Synchronous devices

sue.

do ROt have a clock to strobe the data bits out

with, so
a loop back device must have a clocking mechainism
for syacncGnous devices. If this loopback device does
contain a buffer to allow an entire messaqe to be captured
ana ""EN echoed back to the cOJllmunications device, the
comtlntDication device can be run in half or full duplex.
If the loopback device does not buffer the message, but
rather, just ties the transmitted data line directly to
the receive data line, then the communication device must
be run in full duplex, Master mode. Below is a list of
known loopb?ck devices which will work:
None Yet
This list will be added to as
tested and confirmed.

new

loopback

devices

are

AnothEr line on the same system sub)ect to 1 restriction.
If the 2 lines involved are being controlled by seperate
D.O. modules, there is no problem, but if theY are both
being run by one D.O. module, then you must insure that
both lines are being being run by the module at the same
time.
Later sections of this oocument will explain more
about what this means and how to properly connect and
select the ~oftware options to assure this. Although any
one D.D. module generally handles IF lines, it only
maintains actiVe I/O on 2 of these lines at anyone
instant.
It
does
one
send/receive
iteration
si.ultaneously on 2 lines, then does the same on the next
2 different lines, and so on, until it has done all 16
lines (if selected), then it Goes the first pair again,
etc. If you want to tie one line back on another line in
the same system and both lines are being controlled by the
same module, you must make sure these 2 lines are one of
the "pairs" that get run together. For more on this, read
the section on "2 Lines at a Time Considerations".

Another computer system (Node). This other node can be
another PDP-11 running DECNET DEC/XII or it can be ANY
type of processor by any company running any software
(including its normal operating system) subject to 2
restrictiooE. First the other end of this line must be a

Page 10
compatible modem and communications device and second, the
software must be using the DDeMP protocol (In particular,
the Maintenance "loop back" message) or else be capable of
accepting a mess2ge and echoing it back exactly as
received.
This other side must not send unsolicitated
messages to our node. So, some typical nodes which can be
connected to our node would be:

A PDP-I1 running RSX-I1M (if it supports DDCMP)
A PDP-I1 also runni~g DEeNET DEC/XI1
A PDP-IO running an operating system supporting DDCMP
A brand X computer running any software that will
e~actly
3~3.2

echo messages which we send to it.

What Modes Can a Line Ee Run In?
A line can be run:
a.

Run or not run as selected by the bit map in
of the module. Bit 0 on means test line o.

Master or Slave as selected by the bit map in location 16
of the mo~ule. Eit 0 on means, if testing line 0, treat
it as the Master~ The only difference between Master and
Slave is which side of the line expects to transmit first
(Master) and ~hich Sloe expects to receive a message
(Slave)
before
it transmits.
Both sides transmit,
receive, transmit, ·receive, etc., 9ver and over, but one
line (the Slave) waits to receive the first message before
it starts the test sequence. One side of a line must be
Master and the other Slave~ It is purely arbitrary which
side is which, as long as they are not both the same.
If
a line is connected to itself through some loop back
device, it must be set to be Master. Likewise, if a line
is connected to another line any~here which is not running
DECNE! DEC/Xl1, it must also be set to Master.

Half or Full Duplex. By answering the questions which are
asked when the run corrmand is typed, any line can be set
to either, provided the hardware and the modem can do
either, otherwise, you must set the line what the hardware
and modem dictate.

Point-to-Point or Multi-Drop.
Again,
this
is
set
according to how you answer the questions at rUn time.
There is a seperate section d@allng ~ith Multi-drop.
Point-to-Point is the normal case of 1 device connected to
1 and only 1 other device.

One way orly.
If you have isolated a problem to a
particular device, you may want to verify if the receiver
or transmitter, or both are bad~
For this reason,
one-way-receive
and
one-way-transmit (OWR, OWT) are
provided. To use this mode, in general, all other devices
both communication and other would be deselected, and

location

Page 11
within the D.D. moule which is controlling the line in
question, all lines but one would be deselected.COf
course, Nll?, N2A?, and the clock module must stay
selected to support this DAD~
module.) This would be
mainly for simplicity of operation, and other modules Can
be left running if desired, within the module which
controls the line to be tested, location 116 contains an
address (absolute, not relative to the module start as the
176 is) which contains a 401.
If the location which 116
points to is patched from 401 to a 240 (a NOP), and the
line being tested is set
up
to
be
half-duplex,
point-to-point, Slave, then that linp will only receive
messages, and never attempt to transmit.
It will check
the received message for correct data. The other end of
this line, be it another system, or another module within
the same ~ystem, or even another line under the same
module, should then be set to OWT.
This is done by
patching the absolute address pointed to by location 200
of the module from a 401 to 240, selecting the line to
half-duplex, point-to-point, and Master. This line will
now transmit only, never waiting to receive. Now if these
2 lines are run, one will transmit over and over,
regardless of what the receiving side does, while the
receive ~ide, will attempt to receive and check only. If
both sides of the link run error free, the same patches
and line specifications shoulc be reversed, allowing
verification of the opposite path. Some points to have in
mind .hen running CWR or OW1:

If either locations pointed to by 176 (OWR pointer) or
200 (O~T pointer) in a module is patched from 401 to
240, and then the line is to be tested back in normal
2 way mode,
these locations ~ust be patched back to
their original value (401).
When a line is selected for OW!, that line is in
effect "running free",
i.e., it has to wait for
nothirg, and sco~ing can be done with no other
considerations.
However, when running OWR, this line
will do nothing (except complain of the TIME-OUT
errors) unJess it is connected to another line which
is doing OWT. So, it makes good sense to run a line
OWT all by itself, but no sense to run a line QWP
unless it is connected to a transmitting line.

If other modules are selected while trying O~T or OWR
on another line, it will ~ork but the module ~ill not
have the complete system to itself, so it,
on
occasion, will have to wait for monitor service and
queing, so seoping would be inconvenient.

It is legal to run one line OWT and another OWR out of
the ~ame module, either looped to each other or to 2
other lines.

Page 12

3J4

It is even legal to run 3 to 16 lines out of a module
with some of them set for OWT and/or DWH, but the
resulting testing mode is complicated to understand or
interpute. This method is not recommended for any but
~ne expert user
of D.D.
FQr those that want to
attempt this, read the following. Once the patch for
OWT is made, all lines selected to run within that
D~D.
module as half-duplex, point-to-point, Master,
will be run as OW!. If the patch is made for GWR, all
lines selected to run within that D.O. module as
half-duplex, point-to-point, Slave, will run as OWR.
Any lines selected as multi~drop or fOIl-duplex are
unaffected by other lines in the same module running
O~T
or
Half-duplex, point-to-point lines
OWR.
selected as Slave --a-re--tina-!-fected-uby patches made to
run a OW! line, as are half-duplex, point-to-point
lines selected as Master unaffected by patches made to
run a OWR line. Also, with multiple lines running (3
or more) all lines ere not running at exactly the same
instant, while 2 are running, the others are waiting
their turn, so scoping is difficult and care must be
taken not to connect a line of a module to another
line of the sarre module if the 2 do not get run
together as a pair.
(See section on 112 Lines at a
Time Considerations".)

Running Options
Besides the various modes of running (Section 3.3.2) and the
various ter~inations (Section 3.3.1) there are other options
Within each D.D. module. These options are made by patching
locations within the module before running. The addresses for
any of these option patches are standard in every D.D.
type
module. The options include:
a.

Location 164 is a switch which indicates whether or not
all errors should be reported as they happen. If location
164 is non-zero (equal to n), then receiver errors are
totalled (on a line by line basis); (rather than being
typed out as they tappen) every n passes this total number
of errors fer the previous n passes will be reported. The
value of n is the value of location 164.
The maximum
number of errors that can be talleyed is 256 per line.
Therefore if a line is not kno~n to be of very good
quality, the value of location 164 times the value of
location 16E should be less than 128.
(location 166 is
defined next.) This means the number of messages per pass
times the number of passes per summary report should be
less than 128.
In this way, if every message attempted
!-.. ~..=

HO';:)

.=.,;=;-.

all

;;;':-~6-r;.=-"

~LI..VL

:-e.1:!"':;.

VlJ

'h~'o!-h
UV'-II

+-=-~~~.;;N";+

"'LO~IO;)IUL"

~'l:!"':;.A

all\.;

~;";,.:-=~":"':!' ...--..

LC,",C~VC,

+k~
t..U'I:

~;=:.=.:"W.'=-"

~LLVI.

fr=w'~":'':
.. 0.&..&..1

will not overflow. If the line is of known good quality,
this restriction re~y be relaxed. The default value is to
report all errors, and not give error summary reports~
b.

Location 166 indicates how many iterations per line should

Page 13
be done before an end of pass is celled. An iteration is
normally one trans~it and one receive, in either order.
The default value is B.
C.

Location 170 is a time scaling tactor.
There are many
time out loops in the modules, some should logically be
longer than others. The value in location 170 is the
number of seconds to wait for the smallest time outs.
Some time outs will be a multiple of this factor. Default
is 30 seconds.

Location 112 is an error toleration level, on a single
messaqe basis.
So if in an attempt to do one iteration
(usually a transmit then recieve or vice-versa) the number
of errors reaches the value in location 112, that line is
dropped from testing~ If before this level is reached, an
iteration is correctly completed, then the error count
which is compared to location 172 is re~et to zero.
The
defaul t is 10.

Location 174 contains 2 identical bytes for use as sync
characters.
The default is 113226 which is 2 bytes of
226. If this is changed, both b~tes must be identical to
each
other.
This
location
is a don't care for
asynchronou£ devices, because they "sync" on the first
byte of the actual message, not on precedinq characters as
synchronous devices do.

NOTE
The NCA? module and the NVA?
module, if both
configured in one exerciser, reauire that the same
sync chzracter be used even if they are not
connected to each other.
Since the OV-11 sync
character is set by hardware, this location must
be patc~ed to [atch the DV-l1 hard~are. If you do
have a LV-Il and a DQ-l1, then the DV and DQ'3
~ync
characters must both be patched to match the
DV-l1 hard.are (even if they are not connected to
each other)
f.

l.ocation 176
3.3.2, e.

for

One-.ay-receive.

See

Section

Location 2('0
3.3.2, e.

for

One-way-trar.smit.

See

Section

Locations 322 through 341, the Baud Rate Byte Table,
contain a coded b2Ud rate byte for each correspondinq bit
in the DVe, location 14. This table is only present for
asychronous device modules with programable baud rates.
Refer to the individual module listing for what code
correspones to which baud rate.

Page 14
3...15

Modems
Modems, or at least modern simulators, are always required for
synchronous communications devices. Asynchronous devices do
not for short cable distances. All D.O. modules are written
expecting modems and modem control lines connected to the
devices being tested. For asynchronous devices, the listing
for individual D.O. module types may contain information on
how lines can be tested without modems. The following modems
have run D.O. modules successfully:
Synchronous
Bell 201A
Bell 208E
Com L ink----rr--

3~6

Asynchronous
Bell lOLA

Multi-drop (Not Yet Tested, so Unsupported)
******************************************
Multi-drop is complicated and unless your
configuration
requires
it,
I
would
recommend not reading this section, as it
may just add unneccessary confusion to the
understanding of DEeNEr DEC!Xl1~
*********~********************************

Multi-drop, or ~ulti-point, is a hard~are configuration in
~hich
more than 2 communication devices are connected to a
single line. In the wore common moce, point-to-point, 1
device has its transmitter connected to 1 other device·s
receiver and that device's transmitter is connected to the
first's receiver.
In Multi-drop there is one device (called
Master Stations) connected to 2 or more devices (called Slave
Stations);
The slave stations can never "speak" (transmit)
until "spoken to" by the ~1aster. The D.O. exerciser which is
running as Master will transmit one messaqe on the line which
is exactly like the message used in all point-te-point cases
exc~pt
the header's 6th byte (and the 7th and 8th which are
the eRe-lf char~cters for the header). This 6th byte is the
"address" byte.
Every slave device on this multi-drop line
receives this mes~age and compares its own unique station
address with this 6th byte. If they do not match, the message
is ignored. If they do match, then the slave station is
allowed to transmit one message 00 the line. This message is
exactly what it received, and since the address byte is set
for this transmitting slave, all other slaves must ignore this
message also. The'Master, which started this ?rocess, will be
e:xpecting this "echo". If it gets it ok, it will select the
next slave station and send the message .ith a new unique
address byte.
If the Master aoes not get the echo, it will
retry, up to the limit specified ty location 112 of the
module. (See section 3.4, d.)
When the D.D. exerciser is started, for every line selected
to test, the onerator is asked if this line is ~ulti-drop or

Page 15

not. If the answer is yes, (Y(cr» then he will be asked for
a station address for this line if it was selected to be a
Slave (by bit map in SRI, location 1f of the module). If this
line was selected to be Master and Multi-drop, then the
operator will be asked for a series of addresses, one for each
slsve on the Multi-drop line. This table of Slave·s addresses
has room for 15 Slaves. If there are less, typing a "_"
(minus sign<cr» will terminate the que~tioning for addresses.
These addresses should be any octal number from 0 to 177. Any
one module can only run 1 line as ~ulti-drop Master. If you
attempt to ans~er Y(cr) for a second time for a line which is
Master, 2n error will be reported, and you will be asked the
questions over.
3J7

Errors
There are 3 classes of errors reported by D.O.

modules.

Set-up Errors

specifying parameters or run time conditions, operator
errors can be made.
If detected because of incorrect or
contradictory responses, the operator will be notified.
This
error conditions will be self explcnatory.

~hen

3"7.2

Data Errors

When a message is received by a D.D.
module, a common
subroutine located in the NIA? module is called to check the
data in the mes~age. All DECNET DEC/XII module data comPare
errors look like the standard DEC/Xll data compare error
message except:
a.

The module name typed is FFXX, where FF is fille~ in to be
the name of the DECNET DEC/XII module which called the
N1A? module to do the compare.
In other words FF
represents the module that nhad" the error.

The error number is a count of the data compare errors in
the current message being checked, it is therefore reset
to zero every time a new message is to be checked.

ACSR contains the address of the DeeNET DEC/Xll module
which called this routine to have its message checked~

SBADR contains the line # of the device which had the data

error.
e.

~ASADR

cOGtains the count (in octal) of which character in
the message this bad character was.

The "should be" and tlwas" items are normal.
NOTE, because the N1A?

module

keeps

having

its

named

Page 16
changed by D.D. modules doing data compares, you cannot
expect to know what name it is using at anyone time.
When first loaded, it is called NIXX, but it often gets
changed while running. So do not be alarmed if in run
summarys and maps, the name has changed to NQXXO, NLXXO,
or whatever. If you want to deselect it or use the MOD
command on it, use the name which last appeared in a run
summary or MAP command.

Running Errors
Other running errors are reported ~sing the normal error call
in DEC/Xll CSRA and ACSR are stand2rd. STATe contains a coded
error number, with the code being consistent in all DEeNET
DEC/X11 modules.
The low order 2 digits of STATe contain
which line had the error the other digits contain this code:

0010XX
0020XX
0030XX
0040XX
0050XX
0060XX
0070XX
OlOOXX
0110XX
012CXX
0200XX
0400XX

ree time out
tmt clock 105s
header eRe error
msg eRe error
tmt time out
tmt non-existent memory
tmt latency
rec data parity error
ree non-existent memory
rec clock loss
ree framing error
rec overrun or latencY error

The first time the run time exerciser is run after loading,
the NET1 mocule will type this error code list out to the
system console far the operators subsequent use.
(Unless
switch 0 is UP on the switch register)
3~8

Altering the order of Line Testing
The module contains a table of bytes frOID location 212 to 231.
Location 212 corresponds with bit 0 of DVC (location 14 in
module), location 213 .ith bit 1, etc, up to location 231 with
bit 15.
These bytes contain the line number to test in the
lo~ order 4 bits.
The upper 4 bits are unimportant.
Modules
as shipped, contain ~ 0 in location 212, 1 in 213, 2 in 214,
etc., UP to a 17 in location 213. This table in conjunction
with the ave location, tell the module which lines to run and
in which order. The module takes DVe, starting with bit C,
and for each bit set to a 1, runs the line number specified by
the corresponding byte, 212 to 231. Given the default values
in 212 to 231 and DVC set to 171177, the module ~ould test
line 0, then lire 1, then 2, etc~ up to line 17~ If for any
reason, you would want to rUfi the lines in any different
order, just reodify *BYTES* 212 thru ~31 to the order you want,
making sure that every nu~ber from 0 to 17 (octal) appears
only once, in this byte table.
For example, the default
values of this table leok like:

Page

Location

Value

----_ .... _-

-----

212

000400
001402

214
216
220
222

002404

226

003406
OC4410
005412
006414

230

00141f

224

In Bytes

-----.---001
003
005
007

000
002
004

011

010
012
014
016

013
015

C17

006

DVC
---.~

3
5
7
11
13
15

hit

... -- ... -....
0

2
4
6

10
12

14
16

This will test lines 0 thru 17 in ascending order.
(Provided
the corresponding bit in DVe indicates the line is to be
tested.) If you wanted to test the lines in the following
progres-sion, 3, 11, 2, 17, 1, 7, 16, 6 1 14, 0, 4, Ie, 5, 12,
13, 15, you should modify the module to the following!
Location

Value

ave

bit

003
002

1
3

001

016
014
004

7
11
13
15
17

In Bytes

----- .. _-

--------

-----

212

004403
007402
003401
003016
000014
004004

011
017

226

OC5Q05

012

005

230

006413

015

013

214

216
220

222
224

CO']

006
000
010

------_ ..... _2
4
6

10
12
14
16

If ~hen you go to modify these locatioil~ the upper 4 bits are
non-zero, do not bother writing these bits, they are set up at
run time, just patch the lower 4 bits to what you want.
Make
sure no two bytes contain the same line number and remember
that no mztter ~hat is done to this table, DVC, location 14,
has the hit map of which lines will run. If a bit is not on
in eve, then no matter ~hat is in the corresponding byte in
this table, tt:e li~c ~il1 not be run.
3~9

2 Lines at a Time Considerations

Due to program size constraints, D.O.
modules will only
maintain active message flows on 2 lines at anyone instant.
The program ~ill, according to the lowest order bit which is
on in DVC, location 14, take the first line to be tested, get
it started, and then start the secon~ line.
These 2 lines
will be doing simultaneous message transfers until either has
done the required number of iterations (per location 166).
Then that line that just finished will be dormant and the 3rd
line (as selected by the 3rd lowest order bit in DVC) will
become active.
One of the original 2 lines may still be
active with this 3rd line. Next this list line of the first 2
will finish and go dormant and the 4th line ~ill be started.
It will be running simultaneously with the 3rd lin@.
This
process repeats until the last line selected is complete.

Page 18
Then an End-af-Pass call is made and the whole process starts
avera
If all lines were running in the same test mode and at
the same baud rate, then lines 0 and 1 would run and finish,
lines 2 and 3 would then run, etc. up the line 16 and 17
(octal). If ho~ever, line 0 was running 20 times slower than
the other 15 lines (say because of different baud rates) then
line 0 would start, and each line 1 thru 17, would be started
and finished in turn,. and still line 0 would not have
finished~
Why do you care about this?
Because it is both
possible and easy, to connect lines to lines such that a
running line cannot finish because it must wait on another
line which will not even get started till the first is
finished. For example, suppose your system has 4 DLII-E's all
at 9600 baud and you run all 4 using 1 D.D~ module, NLA?
If
you wanted to just loop your lines on each other for a
standalone test you have 3 choices of connections. Two of
them will not work. If you connect line 0 to line 1 and line
2 to line 3, it will run fine, when started, the module will
run line 0 anc 1 to completion, then lines 2 and 3, and then
do an Enc-oi-P2SS. If you instead, connect line C to line 2,
and line 1 to line 3, it will not ~o[k. The module will start
line 0 and line 1, but the lines they are connected to are
"asleepn~
Line 0 .ill transmit over and over and get no
response from line 2 because line 2 is not actively running,
it will not be started till line 0 is cone!
If you really
.~nted
to test line C to 2 and lines 1 to 3, you have?
choices, either confiqure 2 NLA? modules and let each run 2
lines at a time, in which case you will truly have 4 lines
running at once, or else, using only 1 module, you can modify
the order in which lines are tested (See section 3.8). By
doing this, line 0 and line 2 will be selected for testing
first, and then 1 and 3.
The same type of problems can occur between systems. Consider
2 systems, call them A and H, each .ith 4 DLll-E's. If lines
AC is connected to B2, ~1 to 83, A3 to BO, and A4 to Bl, the
same type problem ~ill happen. System A will make lines 0 and
1 active but they will get no action from B's line 2 and 3,
because they wor't get st2rted until lires BO and B1 are done.
In this case, as in most interprocessor configurations, these
mismatched situations will usually straighten themselves out
after a Hrocky" start. Either SYsten A or B would likely have
both its lines I1time out" and give up, and qo on to the next
pair of lines. These would then run smoothly, and from then
on, Sy~tem A would be in the middle of a pass while System B
would be at the end of a pass. There would, however, be a
long time and about 30 time out error messages (8 on each of 2
lines on one ~ystem, and 7 on each of 2 lines on the other
system) betore the systems run. (

So, to avoid these problems, always connect line O's to line
0'5, 1's to 1's, etc. BETWEEN modules whether the modules are
running both on 1 system or on 2 seperate systems.
If the
lines are looped back onto lines from the same module, connect
adjacent (0 to I, 2 to 3, etc.) pairs together, evenly from

Page 19
the first line.
In both cases, I mean line 0 to be the 1st
line selected by the lo~est order bit in DVe, the 2nd line
would be the 2nd lowest order bit in DVe, etc.. For example,
if you had a DVe of 010450, meaning lines 14, 10, 5 and 3
shoulrl be tested, connect 3 to 5 and 10 to 14.

you can connect 3, 5 or 25 processors together in rings or
stars or whatever pattern you like. In all cases it will be
possible to configure D.O.
exerciser to get the entire
network to play, but care must be used not to connect lines to
lines such that line·s other end cannot get started until this
side is done.

tJO The Future of DECNET DEC/XII
Modules were cone for the DL, DU, DQ, and the DUP devices, but
it does not appear that other devices will be supported at
thi~ time.
current thinking is that standard DEC/XII testing
along with individual line testing with ITEP ~ill detect all
errors.