Ref: 99980087
Title: IVECS Troubleshooting
Date: 8/1/87

Copyright 3Com Corporation, 1991.  All rights reserved.

Installing multiple IVECS into a VAX can be very tricky.  Bridge
recommends having our specially trained field engineers do the
installation.  If you are ever on your own, however, here is what
to do.

As more IVECS are being installed, we are finding customers for
whom 80 ports is not enough.  This is the maximum number of ports
that can be configured using the autoconfigure facility of the
VMS operating system.  However, up to 192 ports can be configured
in a Unibus using the manual connect command.

As Bridge Communications recommends, manual connection of the
devices under VMS is not a trivial task and should be performed
only by people who TRULY understand both VAX architecture and the
VMS operating system.  When this procedure is absolutely
required, solutions are always site specific and often impact
more than just the IVECS boards.  Bridge Communications
recommends this procedure to be done by Bridge-trained
technicians whenever possible.

However, when you are purchasing several IVECS for one VAX and
supporting configuring, you need to know how to configure your
system.  To this end, we spend a day configuring one of our local
VMS systems for 136 ports (128 IVECS ports, 8 real DMF32 ports).
Bridge Communications believes this configuration is the most
straightforward, is the least site specific, and does not affect
any other boards that use the autoconfigure procedure.  However,
it may conflict with other manually configured Unibus boards.  If
you have other manually configured boards, be sure of existing
configurations before installing multiple IVECS.  Remember, this
method is very tedious.  A thorough understanding of both VAX
architecture and the VMS operating system is absolutely
necessary.

The autoconfigure program starts in the floating CSR range and
checks every (octal) 20 bytes for devices.  When a device is
encountered an appropriate number of interrupt vectors are
assigned starting at (octal) 300 and proceeding through 777.  The
following manual configurations puts the IVECS boards at the
highest possible CSR addresses, so that the IVECS will not
interfere with the autoconfigure.  It also assigns the highest
possible interrupt vectors, and packs them as close as possible
so as not to interfere with the autoconfigure.  The goal is that
after the IVECS boards are manually configured the customer will
be able to add and subtract other boards, using the
autoconfigure, as it the IVECS were not there.  This avoids what
could be a very painful re-configuration whenever the customer
decides to add or subtract a Unibus device.

A little background material for general understanding is in
order.  VMS, like most sophisticated operating systems, allows
the users to create files or operating system commands that can
be executed with a single line command.  For VMS, these files are
written in DCL (Digital Command Language).  During the boot
procedure, these command files are particularly useful for
allowing customization of the system without manually have to
type in a list of commands every time the system boots.  DCL
files must have a "$" at the begining of each DCL command.  A "!"
(bang) character indicates that the line is a comment.  The "@"
character is used to execute a DCL file.  During the boot phase
VMS executes [000000.sysexe] startup.com, which contains a
sequence like this:

$!  Allow the user to specify configurations
$ @sys$sysroon:[sysmgr]sysconfig.com
$!
$!  Do the Autoconfigure operation
$!run sys$system:sysgen autoconfigure/all
$!
$!  Allow the user to initialize terminals
$!  start processes, create queues etc.
$@sys$sysroot:[sysmgr]systartup.com

$!

To manually configure the IVECS boards the user must put a series
of commands into SYCONFIG.COM.  These commands should not be in
SYSTARTUP.COM since the autoconfigure program has already run.
Once the devices are configured, STSTARTUP.COM is run which can
do things like "$set term/perm/hostsync/modem/hangup/dma txa0:".
SYCONFIG.COM should look like this:

Skeleton SYCONFIG.COM
$!   This is a site-specific device
$!    configuration procedure.
$!
$!
$write sys$output "Executing Sys$manager;sysconfig.com"
$run sys$system:sysgen
 connect TX?0 /adapter=ub0/csr=%oCSRADD/csr_offset=%014-
 /drivername=ycdriver-
     /numvec=2/vector=%oVECTOR/vector_offset=%o20/maxunits=8
connect TX?1 /adapter=ub0
connect TX?2 /adapter=ub0
connect TX?3 /adapter=ub0
connect TX?4 /adapter=ub0
connect TX?4 /adapter=ub0
connect TX?5 /adapter=ub0
connect TX?6 /adapter=ub0
connect TX?7 /adapter-ub0
*****Repeat the above 10 lines for each DMF32 board
*****to be emulated.  See the table below to fill in
*****the correct TX?, CSRADD, and VECTOR.  Replace ub0
*****with the adapter name of the correct unibus if
*****needed.  Do not include these ***'d lines in the file
*****The first connect can fit in two lines without margins.
exit
$write sys$output "Finished Sys$manager:syconfig.com"
$exit

SYCONFIG.COM CONFIGURATION TABLE

IVECS    TX?     CSRADD     VECTOR     VECTOR
desig.   base    address    number
                 (octal)    (octal)    (hex)
-----    ----    ------     -------    ------
 C0       txC    760740     450        5A
 C1       txD    761000     460        5C
 C2       txE    761040     470        5E
 C3       txF    761100     500        60
 C4       txG    761140     510        62
 C5       txH    761200     520        64
 C6       txI    761240     530        66
 C7       txJ    761300     540        68

 B0       txK    761340     550        5A
 B1       txL    761400     560        5C
 B2       txM    761440     570        5E
 B3       txN    761500     600        60
 B4       txO    761540     610        62
 B5       txP    761600     620        64
 B6       txQ    761640     630        66
 B7       txR    761700     640        68

 A0       txS    761740     650        6A
 A1       txT    762000     660        6C
 A2       txU    762040     670        6E
 A3       txV    762100     700        70
 A4       txW    762140     710        72
 A5       txX    762200     720        74
 A6       txY    762240     730        76
 A7       txZ    762300     740        78

This configuration scheme is constructed such that anyone can use
the above configuration by selecting the correct entries from the
table and plugging them into the format given for the
SYCONFIG.COM file.  It is intended that the last entries of the
table be used when less than 24 DMF32 boards are being emulated.
For instance, if only one IVECS is being installed, it would be
IVECS A and should be configured for a base CSR of 761740.  If
two IVECS are being installed with 64 ports each then they would
be IVECS A and B, and would be configured for base CSR addresses
of 761740, and 761340.  Notice that the IVECS need not be
configured for 8 DMF 32 boards.  For performance reasons, you may
only emulate 6 DMF 32 boards on two IVECS A starts at TXU and CSR
address 762040, and IVECS B starts at TXO and CSR address 761540.
Alternatively, the customer could assign the same addresses as if
64 ports were being used, but some CSR and Vector addresses are
lost.

The device specifications do not have to follow the above table.
They were chosen so that the installer could simply take the
table as it for the last X entries that apply to that
installation.  The customer may not like device names starting at
TXK.  If there are other TX devices in the system it is advisable
to leave a gap between those devices and the IVECS devices to
ease future reconfiguration problems.  In that case the ones
given may be quite acceptable.  However, the customer may want
these devices starting at TXA.  If there are no other TX devices
then there is no problem.  If there are one or more TX devices
being autoconfigured and TXA is used as the starting device name,
autoconfig will not configure the other devices.  The installer
can always allocate just enough TX devices to allow for the other
devices being TXA, TXB, etc.  This is not easily reconfigurable
though, as noted.  In any case the only real constraints on the
TX? assignments are that they be unique, and that SYSTARTUP.COM
contain eight "set term/...TX??" statements that use the same
designation.

After creating the correct SYSCONFIG.COM file, the installer
should edit the SYSTARTUP.COM file to add the terminal
initialization statements, one per port, of the form:

.br;$set term/perm/hostsync/modem/hangup/
.br;dma txa0:"

A note here concerning ease of use and flexibility.  The
installer should consider separating out the commands for each
IVECS into separate files.  The purpose is to ease the
reconfiguration problem if the customer has to remove and IVECS
for a few days or weeks.  For example, the IVECS could (at least
theoretically) fail, the Unibus Power Supply may fail, the board
might be needed more in another system, the customer may want to
use the slot to test some other product, and so forth.

To ease the problem of having many error message generated if one
IVECS is removed, the installer can arrange to have one file like
the SYCONFIG.COM file above for each IVECS.  They might have
names like confivecsa.com and confivecsb.com.  The SYCONFIG.COM
file then has simple:

.br;$@confivecsa.com
.br;$@confivescb.com

Now if IVECS B is removed, the operator has only to inset a
single "!" in front of the "@confivecsb.com" command.  No fancy
editing is required.  The same can be done with the "set term/
perm..." commands in SYSTSARTUP.COM.  They can be grouped with 64
set commands in files called something like startivecsa.com, and
startivecsb.com.  Again only one "!" need be inserted in the
statement "$!@startivecsb.com" contained in the SYSTARTUP.COM
file.

Now back to installing the IVECS boards.  After creating both
files and re-booting the system, the installer can verify that
the vectors are where they belong by interrogating the IVECS.
First remote to IVECS from a Bridge Communications Server (e.g.,
CS/1).  Then enter "su dm 501100 100".  The resulting display
will look like this:

501100: 80 VV xx xx  xx xx xx xx  xx xx xx xx  xx xx xx xx
501110: xx xx xx xx  xx xx xx xx  xx xx xx xx  xx xx xx xx
501120: 80 VV xx xx  xx xx xx xx  xx xx xx xx  xx xx xx xx
501130: xx xx xx xx  xx xx xx xx  xx xx xx xx  xx xx xx xx

The first two lines are the direct registers for the first DMF32.
The first word "80 VV' is the same as CSR0 and will appear on the
Unibus at the location programmed in the CSR Address jumpers.
The 80 indicates that this is a DMF32 with 8 asynchronous ports
(no sync or line printer).  The VV is a hex value indicating the
vector number.  In the table above, the last column labeled
"Vector Number (hex)" is the number to expect.  The second to
last column, labeled "Vector Address (octal)", is the Vector
number shifted left 2 bits (long word address) and converted to
octal for use in the connect command.   If VV is zero, then VMS
has not initialized this board.  This fact is useful whether you
are using the connect command or autoconfigure.  The vector
number will range from 30 to 78 for a VMS system.  The xx's are
not of particular interest.

If the boards have correct vectors then the connects worked
correctly.  If you wish you may enter the IVECS commands "su dm
501400 100" and "su dm 501500 100" and look at the indirect
registers.

In this display, four word values for each port are arrange
vertically.  This means that each group of four lines holds the
registers for eight ports.  The first command gives the first
four boards, and the second the last four boards.  A sample would
look something like this (the port numbers are added):

Port     0     1       2     3     4      5     6     7
        ----- -----  ----- -----  ----- -----  ----- -----
501400: B0 00 B0 00  B0 00 00 00  00 00 00 00  00 00 B0 00
501410: 12 25 12 25  12 25 12 25  12 25 12 25  00 25 12 25
501400: 03 28 01 00  B6 80 00 00  00 00 00 00  00 00 00 00
501430: 00 00 00 52  00 00 00 00  00 00 00 00  00 00 00 00

The first word shows whether there is a connection to the port,
"B0 00" indicates that a user is connected.  In the example,
ports 0,1,2, and 7 are connected.  The second word shows whether
VMS has the port enabled.  All ports are enabled "1225" except
port 6.  This port was either just disconnected (hung up, lasts 2
seconds) or there is not a valid "$set term/perm/modem tx?6:" in
the SYSTARTUP.COM file.  If these entries are "12 27", then
TTY_DEFPORT has not been set to 1.  The third entry is the DMA
address of the last requested DMA transmission.  Notice that port
7 has a connection but no DMA address.  This is either an early
login, or the port is not set up for DMA.  The last work is the
DMA count.  It is zero when no DMA is outstanding (port 0), and
non-zero when a DMA has been requested but not completed (port
1).

We would like to warn everyone at this time about setting the
"UseDtr" parameter to ignore.  This can result in a very
inefficient use of processing power on both the IVECS and the VAX
if any input characters are received.  The following combination
is very dangerous:

.br;B0 00
.br;00 25
.br;XX XX
.br;XX XX

The terminal was not set to / modem and the user set
"UseDtr=Ignore" in order to be able to connect.  This may seem
acceptable for a printer that is not expected to send any data,
but some pritners will send an "out of paper" messages, and other
fault indicators.  Be extremely careful about this; IVECS
versions 10030 and later will drop input data in this situation
to avoid severe problems.

Also, be very careful about setting "UseDcDout = AlwaysAssert".
The problem here is two fold.  If the port is used as an
interactive terminal, VMS will not know when a user disconnects
and will not log off the user, in which case another use may get
his session.  The second problem comes about when the VAX is
sending data across a connection and the connection fails (for
any reason).  The VAX gets no indications of this and continues
outputting, and the IVECS has no place to send the data.  So the
IVECS drops it.  The IVECS becomes a data sink and will take the
data as fast as the VAX can generate it.  This is critical if the
program is infinite in nature (not likely but possible).

In case these directions have been less than clear, the exact
SYCONFIG.COM file created in order to configure two IVECS with 64
ports each in our VAX 750 follows.

SYCONFIG.COM for two IVECS, 64 ports each

$!  This is an empty site-specific device configuration
$!  procedure.  If you have specific device configuration
$!  requirements at your site, you should place the required
$!  commands in this procedure.
$!write sys$output "Executing Sys$manager:syconfig.com"
$!mcr sysgen
connect txk0/adapter=UB0/csr=%o761340/csr_offset=%o14/drivername=YCDRIVER-
/numvec=2/vector=%o550/vector_offset=%o20/maxunits=8
connect txk1 /adapter=UB0
connect txk2 /adapter=UB0
connect txk3 /adapter=UB0
connect txk4 /adapter=UB0
connect txk5 /adapter=UB0
connect txk6 /adapter=UB0
connect txk7 /adapter=UB0
connect txl0 /adapter=UB0/csr=%o761400/csr_offset=%14/drivername=YCDRIVER-
/numvec=2/vector=%o560/vector_offset=%o20
connect txl1 /adapter=UB0
connect txl2 /adapter=UB0
connect txl3 /adapter=UB0
connect txl4 /adapter=UB0
connect txl5 /adapter=UB0
connect txl6 /adapter=UB0
connect txl7 /adapter=UB0
connect txm  /adapter=UB0/csr=%o761440/csr_offset=%o14/drivername=YCDRIVER-
/numvec=2/vector=%o570/vector_offset=%o20
connect txm1 /adapter=UB0
connect txm2 /adapter=UB0
connect txm3 /adapter=UB0
connect txm4 /adapter=UB0
connect txm5 /adapter=UB0
connect txm6 /adapter=UB0
connect txm7 /adapter=UB0
connect txn /adapter=UB0/csr=%o761500/csr_offset=%o14/drivername=YCDRIVER-
/numvec=2/vector=%o600/vector_offset=%o20
connect txn1 /adapter=UB0
connect txn2 /adapter=UB0
connect txn3 /adapter=UB0
connect txn4 /adapter=UB0
connect txn5 /adapter=UB0
connect txn6 /adapter=UB0
connect txn7 /adapter=UB0
connect txo /adapter=UB0/csr=%o761540/csr_offset=%o14/drivername=UCDRIVER-
/numvec=2/vector=%o610/vector_offset=%o20
connect txo1 /adapter=UB0
connect txo2 /adapter=UB0
connect txo3 /adapter=UB0
connect txo4 /adapter=UB0
connect txo5 /adapter=UB0
connect txo6 /adapter=UB0
connect txo7 /adapter-UB0
connect txp /adapter=UB0/sr=%o761600/csr_offset=%o14/drivername=YCDRIVER-
/numvec=2/vector=%o620/vector_offset=%o20
connect txp1 /adapter=UB0
connect txp2 /adapter=UB0
connect txp3 /adapter=UB0
connect txp4 /adapter=UB0
connect txp5 /adapter=UB0
connect txp6 /adapter=UB0
connect txp7 /adapter=UB0
connect txq /adapter=UB0/csr=%o761640/csr_offset=%o14/drivername=YCDRIVER-
/numvec=2/vector=%o630/vector_offset=%o20
connect txq1 /adapter=UB0
connect txq2 /adapter=UB0
connect txq3 /adapter=UB0
connect txq4 /adapter=UB0
connect txq5 /adapter=UB0
connect txq6 /adapter=UB0
connect txq7 /adapter-UB0
connect txr /adapter=UB0/csr=%o761700/csr offset=%014/drivername=YCDRIVER-
/numvec=2/vector=%o640/vector_offset=%o20
connect txr1 /adapter=UB0
connect txr2 /adapter=UB0
connect txr3 /adapter=UB0
connect txr4 /adapter=UB0
connect txr5 /adapter=UB0
connect txr6 /adapter=UB0
connect txr7 /adapter=UB0
connect txs /adapter=UB0/csr=%o761740/csr_offset=%o14/drivername=YCDRIVER0
/numvec=2/vector=%o750/vector_offset=%o20
connect txs1 /adapter=UB0
connect txs2 /adapter=UB0
connect txs3 /adapter=UB0
connect txs4 /adapter=UB0
connect txs5 /adapter=UB0
connect txs6 /adapter=UB0
connect txs7 /adapter=UB0
connect txt /adapter=UB0/csr=%o762000/csr_offset=%o14/drivername=YCDRIVER-
/numvec=2/vector=%o660/vector_offset=%o20
connect txt1 /adapter=UB0
connect txt2 /adapter=UB0
connect txt3 /adapter=UB0
connect txt4 /adapter=UB0
connect txt5 /adapter=UB0
connect txt6 /adapter=UB0
connect txt7 /adapter=UB0
connect txu /adapter=UB0/csr=%o762040/csr_offset=%o14/drivername=YCDRIVER-
/numvec=2/vector=%o670/vector_offset=%o20
connect txu1 /adapter=UB0
connect txu2 /adapter=UB0
connect txu3 /adapter=UB0
connect txu4 /adapter=UB0
connect txu5 /adapter=UB0
connect txu6 /adapter=UB0
connect txu7 /adapter=UB0
connect txv /adapter=UB0/csr=%o762100/csr_offset=%o14/drivername=YCDRIVER-
/numvec=2/vector=%o700/vector_offset=%o20
connect txv1 /adapter=UB0
connect txv2 /adapter=UB0
connect txv3 /adapter=UB0
connect txv4 /adapter=UB0
connect txv5 /adapter=UB0
connect txv6 /adapter=UB0
connect txv7 /adapter=UB0
connect txw /adapter=UB0/csr=%o762140/csr_offset=%o14/drivername=YCDRIVER-
/numvec=2/vector=%o0710/vector_offset%o20
connect txw1 /adapter=UB0
connect txw2 /adapter=UB0
connect txw3 /adapter=UB0
connect txw4 /adapter=UB0
connect txw5 /adapter=UB0
connect txw6 /adapter=UB0
connect txw7 /adapter=UB0
connect txx /adapter=UB0/csr=%o762200/csr_offset=%o14/drivername=YCDRIVER-
/numvec=2/vector=%o720/vector_offset=%o20
connect txx1 /adapter=UB0
connect txx2 /adapter=UB0
connect txx3 /adapter=UB0
connect txx4 /adapter=UB0
connect txx5 /adapter=UB0
connect txx6 /adapter=UB0
connect txx7 /adapter=UB0
connect txy /adapter=UB0/csr=%o762240/csr_offset=%o14/drivername=YCDRIVER-
/numvec=2/vector=%o730/vector_offset=%o20
connect txy1 /adapter=UB0
connect txy2 /adapter=UB0
connect txy3 /adapter=UB0
connect txy4 /adapter=UB0
connect txy5 /adapter=UB0
connect txy6 /adapter=UB0
connect txy7 /adapter=UB0
connect txy /adapter=UB0/csr=%o762300/csr_offset=%o14/drivername=YCDRIVER-
/numvec=2/vector=%o740/vector_offset=%o20/maxunits=8
connect txz1 /adapter=UB0
connect txz2 /adapter=UB0
connect txz3 /adapter=UB0
connect txz4 /adapter=UB0
connect txz5 /adapter=UB0
connect txz6 /adapter=UB0
connect txz7 /adapter=UB0
exit
$write sys$output "Finished Sys$manager:syconfig.com"$!

As we've said before, manual connection of these devices under
VMS is a very difficult task.  When this procedure is absolutely
required, solutions are always site specific and often impact
more than just the IVECS boards.  Bridge recommends this
procedure be done by Bridge-traininged technicians.  A thorough
understanding of both VAX architecture and the VMS operating
system is absolutely necessary.

