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 <tsho...@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 <heal...@avanthar.com> wrote: >> >> >>> On Feb 20, 2018, at 8:56 PM, Mark Pizzolato <m...@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@trailing-edge.com >> http://mailman.trailing-edge.com/mailman/listinfo/simh _______________________________________________ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
