[Simh] Limits on MSCP controllers

[Timothe Litt]

On 23-Jun-19 13:30, Bob Supnik wrote:
> The four ports is not arbitrary. SimH simulates actual hardware. 

> DEC never built a backplane MSCP controller with more than four ports.
>
I think that's true for the U/Qbuses.  However, the KDM70 (XMI, last I
knew not emulated by SimH) has eight universal ports - any mix of
SDI/STI (disk/tape) that you can plug in.  Officially, max of 2 STI, 8
SDI.  Note that what plugs into STI is a formatter - each of which might
have 4 drives behind it.   Unit numbers are assigned by the drive - IIRC
12 bits for disk, 4 decimal digits for tape (due to bcd encoding of the
unit select switches).  This is slightly simplified - SSDs have
different rules, and some tapes formatters support less than 4 drives.

Those are KDM70 architectural limits - MSCP might be up to 16 bits, but
I don't have a spec handy.  There might be some flag bits in the field.

(I was somewhat involved in the KDM70 development.)

> If you want to extend the current RQ simulator to include third party
> boards (either SMD-based emulators or SCSI-based emulators), feel free
> to add an appropriate mode switch. I don't know what controller ID
> these third party boards returned, though, nor do I know how VMS
> determined the number of ports per controller.
>
(T)MSCP doesn't deal with ports; it deals with (logical) units.[1]  I
don't remember an efficient mechanism to enumerate the units; IIRC, you
simply wait for an attention message with "Unit Available".   You could
also try a "get unit status" for each possible LUN - but that's a very
large number, especially in a large configuration -- e.g. a CI with lots
of HSC controllers, or even lots of NI workstations with MSCP-served
disks.  STAR had over 200 NI satellites at one point.

As noted, the LUNs are arbitrary - for the larger disks, set by a plug
on the drive.  No requirement for starting at zero, or sequential
numbers.  (Of course, you can't use the same LUN on the same controller
more than once.)

VMS enumerates controllers to assign a letter, and uses the LUN from the
attention message to build the UDB[2] and record the unit number. 
(Allocation classes, used to link dual-ported drives) would be a
prefix).  So, if the 4th controller has a single RA81 with a unit plug
of 251, the device name would be _DUD251:.    If in allocation class 18,
_$18$DUD251:.  Units can come/go/morph if, for example, the unit plug is
removed or swapped, which is why "mount verification" exists.

I don't remember whether VMS will try to set a unit on-line if it hasn't
received a unit available first.  But I believe that it won't try
anything if it hasn't found the controller.  The controllers (except for
the boot device) are found by running sysgen autoconfig all in one of
the DEC-supplied startup scripts.   This is towards the middle of the
process - it takes quite a while in large configs, so the startup
initiates a bunch of other stuff that can overlap it first.  There are
several callouts in the startup scripts - it's important that disk
mounts be after sysgen is run.  sylogicals(-v5).com would be too soon.

> I think it would be better to understand why VMS is waiting to mount
> additional discs. Alternately, just create bigger discs and have fewer
> of them.
>
One thing to check is that the unit available (attention) messages are
sent at the right times. 

The other is where in the startup the mounts are placed.  The
site-specific startup - systartup(_v5).com, or something called by it
should be OK.  [the _v5 suffix was introduced with VMS V5 because things
like device naming changed, it was removed many releases later].

[1] This caused some pain with devices that shared a resource across
units - e.g. the RC25 that shared one motor/spindle between a fixed
platter and a removable cartridge... "Clever" hardware design that
ignored the software architecture...

[2] Unit Data Block - VMS's drive context.  They materialize when a unit
is discovered.

> /Bob
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20190623/ef0edef6/attachment.html>