9 Dec
2013
9 Dec
'13
12:47 p.m.
On Dec 9, 2013, at 12:48 PM, John Wilson <wilson at dbit.com> wrote:
On Mon, Dec 09, 2013 at 10:51:38AM -0500, Paul Koning
wrote:
I don't know if I've even seen the MSCP spec, but I wonder. It would make sense
for the MSCP spec to describe unit number rules for the address space it talks about,
which is one instance of the MSCP protocol machinery (one controller). The rules for
multiple controllers should be out of scope. And DEC, unlike some other standard
organizations, was pretty good about keeping standards clean.
RSTS requires unique unit numbers because it doesn't have controller letters in its
device names (well, not except as a later aliasing hack). But VMS does. So RSTS
can't represent "device foo, controller 1, unit 1" along with "device
foo, controller 2, unit 1" while VMS can.
paul
On Dec 8, 2013, at 9:22 PM, Charles Dickman
<chd at chdickman.com> wrote:
> [...] The MSCP
> disk unit numbers are unique across all controllers and need to be set on
> each controller.
That depends on the OS. What you say is true for
RSTS, which refers to all
MSCP disks as "DU" and wants the unit number to be unique among all the
controllers. VMS refers to disks by type, controller, and unit, e.g., DUA2:
so (I would assume) it can handle duplicate unit numbers as DUA2: and DUB2:.
I'm 99% sure the "units are unique on a system" rule is from the MSCP
spec,
so it certainly makes sense that RSTS follows it. It seems like kind of a
silly rule though since it's not true of anything but (T)MSCP, so any OS will
already have to have a plan for dealing with dupes (or officially refusing
to -- like the way RSTS rejects duplicate slave #s on Massbus tapes).