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. 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.). 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.
From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Clem Cole Sent: Thursday, January 25, 2018 1:31 PM To: Larry Baker <ba...@usgs.gov>; SIMH <simh@trailing-edge.com> Subject: Re: [Simh] VAX Tape Emulation? On Thu, Jan 25, 2018 at 4:14 PM, Larry Baker <ba...@usgs.gov<mailto:ba...@usgs.gov>> wrote: Because UNIX tapes and tape drivers cannot write variable-length blocks and do not allow skipping forward over records between read operations That's not a correct statement. UNIX does it great - I've used it (and rmt) for years. UNIX's tape driver is the most flexible of any OS I have ever used (and I have done tapes on probably greater than 25 different OS's over the last 40 years). That's why I suggest it. I wonder what the issue for VMS is? Hmm.. thinking about it, TCP sockets will remove the record orientation (TCP creates an stream of octets without any records), so if you are doing the funky RMS like stuff, its TCP that dropping those boundaries not the UNIX tape driver. If you want same then it need to be set as meta-data. But the UNIX tape drive works as expected. The 'block' size is the size of the write, although I think the TM11 requires a minimum of 512 bytes. Records passed with the MTIO ioctl' which mt/rmt all support.. That said, I agree if he can get DECnet to work, that is likely to better integrated into the utilities. Clem [cid:~WRD161.jpg]ᐧ [cid:~WRD161.jpg]ᐧ
_______________________________________________ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
