[Simh] MSCP device swappage ( was: Certainly a silly question)

[Stephen Hoffman]

On Fri, 4 May 2012 18:26:54 -0400, Thomas Pfau <tfpfau at gmail.com> posited:

> That's an interesting idea.  I had a different idea.
> 
> The OS can't use the volume until it sets the PACKACK bit in the CSR.  Simh
> could use this as a signal to open the file attached to the device.  On
> dismount and unload, the file would get closed.  The user could then use
> another host OS session to move another file into place for the next volume.

Thomas undountedly knows this, but here's some background on MSCP...

IO$_PACKACK would be typical for completing a volume swap on VMS.  That's how VMS implements bringing a new disk online.  

The DISMOUNT volume dismount (invoked from VMS) would initiate release of the backing storage file from within the emulator; that's the first part of the volume swap sequence, and that disconnects from the device.  As part of the MSCP dismount, the A-B port light will be extinguished and the device will be offline.  With physical hardware, the DISMOUNT /UNLOAD command would spin down the disk, though that's not something that the emulation cares about - and with physical hardware, the operator can also request the spin-down using the buttons.  (Which would also provide a path for the emulator to initiate the swap, if that's deemed necessary.)

To bring the volume online, the PACKACK reads off some configuration settings from the MSCP server in the controller (type, capacity, etc) and sends the spin-up and the volume online request(s) (this sequence eventually engaging both the white READY indicator on successful disk spin-up and lighting the A-B port light to indicate to the operator that the disk is on-line), so this will all be easily visible within the MSCP server emulation. 

WRITELOCK could be implemented here by the emulation, too; should the backing storage file or the CD or DVD disk (or whatever the data source might be) be protected against write access.

VMS is perfectly happy to have an MSCP disk swapped underneath it (after a dismount), and that includes swapping to a completely different type of disk with the same unit number as the volume that was dismounted (such as moving the SDI cable from an RA60 to an RA92 disk), and VMS can have dozens or hundreds of RA-class devices connected in parallel, too.  

I don't know enough about ULTRIX/VAX or RSX-11M to be certain of this MSCP-swappage handling with those operating systems, but I'd expect that those would.

As for the numbers of disks, there are only four SDI ports on a KDA50 or UDA50 controller, but those aren't the only paths to RA devices available under VMS; MSCP-served and HSC controllers can support more than four SDI connections, and various VMS boxes have had more than one UDA50 configured.  (The usual limit there was Unibus or Q-bus bandwidth, and that's not an issue with an emulation.)  If more than four disks are needed, then bringing additional UDA50 or KDA50 controllers online at secondary or tertiary addresses would be typical.  VMS would show these as separate MSCP ports; what VMS traditionally refers to as a PU device; PUA, PUB, PUC, etc.

The KDB50 was the BI version, and the KDM70 was the XMI.  Officially, up to 23 KDM70s were permitted on some boxes, and each KDM70 had eight SDI/STI connections.

It's also possible for the emulator to initiate this and take the device offline underneath VMS (think "disk failure" or "disk spindown" or...), which would then be reflected by VMS with its mount verification state.  Anything VMS post-RC25-or-so will handle the mount verification just fine.

If this spin-down and offline processing is implemented in the MSCP server emulation behind the UQSSP bits, it should work across any MSCP-based (UQSSP-aware) operating system, too.  (UQSSP is one of the MSCP SCA disk interfaces that were architected, and UQSSP is the one used with the KDA50 and UDA50 Q-bus and Unibus controllers, and basically also what ended up used as the device interface with the KDB50 and KDM70, too.)

---

And for another thread that's going here on the list, there's a built-in RAM disk in VMS embedded in the STABACKIT.COM procedure.  Pull out the Macro32 code using an editor, build it, and you'll have a RAM disk.  Or, yes, load old of the older VAX-compatible LD kits.