[Simh] VAX Tape Emulation?

[Zane Healy]

Tim,
Somewhere you misunderstood me.   The only 2GB limit I’ve found is that the documentation says the TQ emulation only supports tapes up to 2GB.

I have a 50GB drive, and I’ve created 27GB tapes.

My problem is with reading the SIMH tapes, over the cluster, from the Alpha.  I can read them just fine with SIMH.

Zane



> On Feb 21, 2018, at 4:03 AM, Tim Shoppa <tshoppa at gmail.com> wrote:
> 
> Is this possibly a host compiler switch or host OS or host file system issue? The way Zane is hitting some limit at 2Gbytes for both emulated disks and tapes sounds like the limits of 32 bit operating systems or file systems using signed ints.
> 
> Tim
> 
>> On Feb 21, 2018, at 12:29 AM, Zane Healy <healyzh at avanthar.com> 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 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.
>> 
>> Zane
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Simh mailing list
>> Simh at trailing-edge.com
>> http://mailman.trailing-edge.com/mailman/listinfo/simh