Dan,

I think you need to establish exactly what you have in your VAX and exactly
where the boards are.

From the console try
	>>> SHOW QBUS
and 
	>>> SHOW DEVICE

Then you need to take a look inside and report exactly which card lives in
which slot and which slots are empty. If you have a real MicroVAX 3800 this
will be pretty easy since all the covers come off very easily and most modules
will have an easily visible number stamped on them (M7164 and M7165 for the two
KDA50 modules). You should be able to see this without removing the card.

You also need to know which KDA50 your drives are plugged into (assuming you
have more than one KDA50). It doesn't matter which port  of the KDA50 your
drives are connected to - the unit number comes from a plug on the front (RA8x)
or from the OCP (RA9x).

OpenVMS will quite happily play with DUB0 but the device/bus naming scheme used
by OpenVMS can differ from that used by the console. However, since SAB told
you you had DUB0 and then couldn't access it, it suggests that something else
is wrong. Obviously it can talk to the KDA50 enough to query it but presumably
not enough for any data transfers to work.

To test the KDA50, get to the console and powr cycle the CPU (I'm sure there is
a better way, but I cannot remeber it right now - this will do). The KDA50 will
now go through its ROM based diagnostics. If all goes well the LEDs on the
M7164 and M7165 will follow "blink" from top to bottom every five or ten
seconds or so. It looks like it's strobing from top to bottom, very quickly.
Once the system is booted the pattern changes.

Describe the pattern (both modules, top to bottom) once the self-test has
finished and that will hopefully pinpoint your problem.

The most likely display for a problem is M7164: on-on-off-off M7165: all off
The easiest way I recall of getting this is to mess up the grant-passing.

If you dig out the above info it should help pinpoint your problem.

Antonio