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 > >
_______________________________________________ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh