Jorgen,
   
   What Tim has told you is completely right. However, I want to make some
additional comments.
   You write:
>If I did a "sh dev" in VMS it listed (among other things) SPEKTR$DUB4:
>and
>SPEKTR$DUB5:. And if I did a "sh dev dub4: /full" it says it's a RA81
>device.
>So I guess that the disks that I want to connect to the Vax is two RA81
>disks.
   These are NOT RA81s! RA81 is a 19-inch rackmount unit with a DEC-
proprietary interface called SDI (sounds confusingly close to ESDI but has
absolutely nothing to do with it). RAxx disks are connected to a MicroVAX
via a KDA50 controller. The reason why VMS thinks your disks are RA81s has
to do with the MSCP abstraction.
   Here is a brief history lesson. On classical PDP-11s DEC used small
disks (RKs, RLs, 8" floppies, etc.) with a few megabytes at most. Their
interfaces were probably primitive and purely physical (probably of the
same type as SA400/SA450, SA1000, and ST-506/ST-412). The host-side
interfaces of their respectively controllers were probably very interface-
specific, and each type of disks was supported by a different driver. The
same was true for tapes. When classical VAX-11s came along, these a-few-
megabytes-at-most disks were considered too small and slow, and DEC had
switched to MASSBUS disks. These worked well until MASSBUS started to go
away. On the MASSBUS-less VAX-11/730 DEC had used a temporary quick and
dirty solution to incorporate the disk controller into the CPU. However,
DEC's more long-term solution was Mass Storage Control Protocol (MSCP) for
disks and Tape MSCP (TMSCP) for tapes.
   MSCP is an interface between the host system and the disk controller. It
says absolutely nothing about the interface between the controller and the
drive. MSCP controllers can be on both UNIBUS and Q-bus. I think the first
MSCP controller was UDA50. It was for UNIBUS, so it could be used in
classical VAX-11s, although the standard for those is MASSBUS. Its drive-
side interface is SDI for RAxx disks, and as a result of that some people
incorrectly associate MSCP with RAxx disks (that's why the MSCP driver is
called uda/ra in both Berkeley UNIX(R) and NetBSD). When Q-bus systems
appeared on the horizon, DEC offered two MSCP controllers: KDA50 for SDI
(RAxx) and RQDXn for ST-506/ST-412 Winchester disk drives and 5.25" floppy
disk drives. This was a proof that MSCP is not only for RAxx disks.
Actually, by inventing MSCP DEC has done a great service to third parties,
since they immediately started making MSCP controllers. Third-party
(primarily Emulex and Dilog) MSCP controllers are very popular, as they
support interfaces that DEC doesn't, including ESDI, SMD, and even SCSI. As
far as TMSCP is concerned, I think that there has never been a TMSCP
controller for UNIBUS. There are a lot of TMSCP controllers for Q-bus, the
most classical one being TQK50 for the TK50 tape drive.
   However, there is one more thing to it. Since before MSCP every type of
disks required a separate driver, VMS could call each disk by its physical
name like RMxx or RPxx. On the other hand, the whole point of MSCP is
hardware-independence, so that you don't have to know the physical nature
of the disk in order to use it. However, for some strange reason, quite
possibly political (I know nothing about VMS, so I can't be sure), VMS
wants to know the physical name of the disk (like RAxx or RDxx) even if
it's MSCP. To allow this, DEC has included a special hack into MSCP called
MSCP ID. An MSCP ID is a 32-bit number that encodes two letters and two
digits and thus can be interpreted as a DEC disk model number. Since MSCP
is in its nature hardware-independent, you don't need to know the MSCP ID
in order to use the disk, it's only for stupid VMS identification purposes.
Prejudice-free operating systems like Berkeley UNIX(R) and NetBSD don't use
it at all.
   Where does the MSCP ID come from? VMS gets it from the MSCP controller.
The latter can get it from anywhere, depending on how its designer has
chosen to do it. UDA50 and KDA50 probably obtain it from the drive over the
SDI interface. Since all SDI drives are DEC-made, DEC has no problem with
sticking the drive's model number aka MSCP ID into the drive's firmware.
Controllers like RQDXn that use standard Winchester disk drives are more
tricky. RQDXn stores the MSCP ID on the disk. When DEC sells an RDxx disk,
they preformat it and write its model number on it. When you use a non-DEC
disk, during low-level formatting you will be asked for its model number
aka MSCP ID. Then you have to either use the model number for some
completely different disk, even if its absolutely misleading, or invent
your own non-existent DEC-looking "model number". Your case with an SMD
disk claiming to be an RA81 is an example of the former approach. Also note
that the above description is for RQDXn. I don't know whether ESDI and SMD
controllers made by Dilog and Emulex ask you for the MSCP ID during
formatting or always pretend to be RA81s.
   You write:
>The disks has a sticker labeled "9720-368 EMD drive" and "NSOMPI" and
>manufactured
>by "Magnetic Peripherals Inc".
   These are actually CDC drives. First there was a company called Control
Data Corporation (CDC). They had two manufacturing facilities. The one in
Oklahoma City was making 5,25" drives, and the one in Twin Cities was
making 8" drives. Then CDC decided to call the former Imprimis and the
latter Magnetic Peripherals. Imprimis has later been purchased by Seagate.
I don't know what has happened to Magnetic Peripherals, but I think they
also ended up in Seagate's claws. All CDC model numbers start with either
94 or 97. 94 identifies the Oklahoma City facility and 97 identifies the
Twin Cities facility. 94 is followed by a two-digit number identifying the
drive "class" (Wren III, Wren III half-height, Wren V, Wren VI, etc.) and a
one-digit number identifying the interface (1=SCSI, 5=ST506/ST-412, 6=ESDI,
etc.). The only 97-series drives I have seen were SMD drives, and all of
those were called 9720 Sabre or 97200 Sabre, which is the name of the
series. This model number (9720[0]) doesn't say anything about the capacity
of the drive, even though different members of this series vary in capacity
almost by an order of magnitude. Usually though, the capacity in megabytes
(unformatted, I guess) is written after the model number, separated by a
hyphen. In your case its 368 MB. You have to realize that it's pretty small
for such a huge drive. In fact, I think this is the smallest 9720[0] Sabre
drive. In this case RA81 is actually an overestimate (RA81 is 450 MB
formatted).
   As it happens, I also plan to use some 8" SMD Winchesters. I have got a
total of 7 of them, although I don't know whether all of them actually work
(but I know that at least some do). There is one Fujitsu M2392K and two CDC
9720-1230s. There are two more 9720s, but I don't know the capacity.
Finally, there are two drives completely unknown. The two 9720s of unknown
capacity and the two completely unknown drives are mounted in cabinets and
I haven't taken them out yet, so there still may be a sticker that I
haven't seen yet. Anyway, I don't have any documentation for any of them,
and I need it, so if anyone has any documentation for any 8" SMD
Winchesters, I would greatly appreciate a copy.
   Tim Shoppa writes:
>These are ESD drives, a faster version of the popular SMD interface.
           ^^^
   EMD, not ESD. ESD sounds way too close to ESDI.
>Is your Emulex
>controller a QD32, QD33, QD35, or something similar?  These are common
>SMD to MSCP adapters and ought to work just fine.
   By the way, does anyone know whether can I get one of those? One can buy
Dilog DQ256 (quad-height form factor, supports 4 drives) brand new for
$1825, but that's too expensive. I'm sure one can buy an old SMD controller
for much cheaper.
   
   Sincerely,
   Michael Sokolov
   Phone: 440-646-1864
   ARPA Internet SMTP mail: mxs46@po.cwru.edu