martin@essex.ac.uk (Colley M) (06/16/89)
We had a similar problem here of wanting to transfer large files from our apollos to suns. Our apollo people said it could be done but we had to change one of the cartridge tape attributes. They suggested the aegis command: edmtdesc /dev/rct8 -s reo no Which changes the attribute "reo" to "no" (dont forget to set it back to "yes" as rbak/wbak wont work properly). Then use tar as normal. This worked for us under aegis (Domain/IX) 9.5/9.7. I haven't tried it at 10.1 yet. Hope this is helpful. Martin Colley
achille@cernvax.UUCP (achille petrilli) (07/22/89)
In article <1130@servax0.essex.ac.uk> martin@essex.ac.uk (Colley M) writes: >............ They suggested the aegis >command: > > edmtdesc /dev/rct8 -s reo no > >Which changes the attribute "reo" to "no" (dont forget to set it back to >"yes" as rbak/wbak wont work properly). Then use tar as normal. This >worked for us under aegis (Domain/IX) 9.5/9.7. I haven't tried it at 10.1 >yet. > >Hope this is helpful. > >Martin Colley This story of wbak/rbak not working properly if you change /dev/rct8 is just plain wrong. W/Rbak use /lib/tfp to access the tape/cartridge. /dev/rct? is just an additional layer on top of, I guess, /lib/tfp to make it possible to access the device the "Unix way", i.e. as a file. Wbak, rbak, rwmt do not use the /dev files in any way, that is the reason why they are much faster than any user-written program that accesses the devices via /dev/rct?. On a, more or less, related argument, I'd like to know if somebody has tested/used the new backup facility from Apollo, NBS Omniback. I'm interested in hearing any quirks/problems you had and about its performance. Also, we have a few Exabytes from Workstation Solutions and whatever is written on the Apollo is unreadable both on Sun and VMS (Viking controller, TK50 driver), but both Sun and VMS written cassettes are readable on Apollo. The message I get is 'illegal block length' (that's the semantic content of it :-). Anyone can help ? Achille Petrilli Cray & PWS operations
krowitz@RICHTER.MIT.EDU (David Krowitz) (08/14/89)
From talking to some Sun users who have Exabyte drives, I've gotten the impression that the SCSI specs are kind of loose. Apparently even various implementations of the Exabyte drive for the Sun-3 and Sun-4 systems can not always talk to each other due to variations in the SCSI driver. Maximum block lengths and the use of "short" vs. "long" file marks seem to be the problem in most cases. Given your error message, I'd guess that Workstation Solutions' SCSI driver is writting longer physical records on the tape than the Sun and Vax implementations can handle. Terri Long of Wrokstation Solutions told me that their driver can be coerced into using the same parameters as the other SCSI drivers by twiddling with the DDF file in some manner (I think they may have some flags set in the user-info block which can be changed with the /com/crddf command). Try calling W.S. to see if you can change the maximum block size of the driver. == Dave