[Simh] VAX Tape Emulation?

[Mark Pizzolato]

On Tuesday, February 20, 2018 at 9:29 PM, Zane Healy wrote:
> > On Feb 20, 2018, at 8:56 PM, Mark Pizzolato <Mark at infocomm.com> wrote:
> >
> > TQ limited to 2000GB means a limit of 2TB.  Do you have disks on the
> > AXP system that big?
> 
> Unfortunately the 2000GB is a typo on my part.  A 2GB “tape" is too small for
> me, and has been for a long time.  From the documentation:
> "User-specified capacity must be between 50 and 2000 MB. The TQK50 does
> not support the BOOT command.”

What documentation are you talking about?  Ahh... the vax_doc.doc TQK50 section.

The:

      SET TQ TKUSER{=n} 

command.  This section of the document was copied from the PDP11 simulator and on that simulator the TQK50 is indeed not bootable.  Additionally, the 2000MB limit is only true if your host environment doesn't have the ability to read/write files larger than 2GB.  All reasonable host systems today can handle files larger than 2GB, so then the limit for n in the TKUSER{=n} command is 2000000000 MB instead of 2000 MB.

Meanwhile if you read a couple of lines further in the document it says:

Regardless of the controller type, individual units can be set to a specific reel capacity in MB, or to unlimited capacity:

     SET TQn CAPAC=m                                  set unit n capacity to m MB (0 = unlimited)
     SHOW TQn CAPAC                                   show unit n capacity in MB

On the VAX (MicroVAX 3900) simulator, the TQ device is indeed bootable.  

You can use:

      $ @sys$update:stabackit MUA0: 

to put standalone backup on a tape.  From the VAX console ROM ">>>" 
you can BOOT MUA0:

> > What happens if you merely backup a few hundred MB to the tape with
> > /VERIFY?
> 
> I’m not sure, I’d thought about giving that a try.  Right now I’m going to focus
> on getting the data moved.
> 
> > The simh tape will have very different timing characteristics when
> > reading as compared to a real physical tape.  I would still recommend
> > the TQ device since that I/O is asynch and isn't delaying instruction
> > execution (and cluster timing activities) during data transfers.  The
> > cluster exit may merely be due to timing on SCS messages.
> 
> I’ll see about testing that later.  While it’s not that practical to backup to 2GB
> tapes, it would be interesting to see if the problem exists in the TQ emulation.
> 
> >> End Result, I think I’m going to have to resort to the disk solution.
> >
> > The disk solution has effectively similar limits (something just under
> > 2TB) is the maximum RQ disk size.
> 
> In this case, that’s not a problem.  I’m creating 36GB “disks".
> 
> > Meanwhile, you needn't worry about ODS-5 vs ODS-2.  You're driving the
> > backup from the AXP side, and the VAX is merely serving access to disk
> > blocks (not files).  The VAX can address the full capacity of the
> > disk.  Doing a BACKUP/IMAGE your target disk will be mounted /FOREIGN
> > on the AXP side.  No problem there.  When you want to access the
> > contents of one of these target disks, once again you merely let the
> > VAX serve up access to disk blocks and on the AXP side, you DON'T do a
> > MOUNT/CLUSTER, but instead merely do a MOUNT and you'll be able to see
> > the file system naturally on the AXP side.
> 
> This I’m going to have to try.  I wouldn’t have thought of trying it, and it would
> definitely fulfill one of my goals with this project.

Without regard to tape capacity, I believe that the backup to disk will be the far 
superior (and faster) approach.

- Mark