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
