[Simh] VAX Tape Emulation?

[Clem Cole]

On Thu, Jan 25, 2018 at 4:57 PM, Mark Pizzolato <Mark at infocomm.com> wrote:

> I think the documentation comment “cannot write variable-length blocks
> and do not allow skipping forward over records between read operations”
> was written when talking about the common cartridge tapes that were
> available on 80s and 90s Unix workstations.  I don’t recall the name.
>
That was not UNIX, that was the QIC standard.   Yes, those were blocked at
512 bytes.   Apollo's domain systems had a b*tch of time with them because
their standard disk block was 1056 bytes​



>   These things only supported fixed block size operations and not variable
> record lengths (i.e. 80 byte tape labels, then different sized data
> records, etc.).
>
​Right the 80 byte ANSI label, then different length data records.  UNIX
handles that fine, even with RMT.​  FYI: My grad school housemate, Tom
Quarles (of SPICE3 fame) wrote the ANSI tape and bunch of
other tape support that most UNIX systems used, explicitly so he could
read/write VMS tapes for the DEC guys who were doing some of the funding of
the USB CAD lab.   Leffler (who wrote rmt) used Tom's tape stuff for the
original debug of rmt.




>   Given that the remote tape drive was a drive which could do variable
> length record activities, I think MultiNet’s rmt support actually worked
> well.  I don’t remember testing it though.  Whether someone should try to
> do that now to backup simulated VMS systems is another subject I may write
> about a little later.
>

​Understood.   I was just suggest​ing trying to keep another emulated
system out of the scheme and going directly to the remote device either
through DECnet or rmt or maybe even using a NAS as virtual tape files.   It
just seemed running a Linux with a tape and then running an emulated VAX on
top of that seemed like an extra layer of indirection if there was an
easier path.


​
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20180125/b5e9b64b/attachment-0001.html>