herb@blender.uucp (Herb Peyerl) (12/10/90)
Recently I've been charged with the task of converting approximately 100 1600BPI magtapes to cartidge format. The tapes were all written in various formats (ie:previously, the naive sys_admin would write them all with absolute pathnames to nodes that no longer exist). So rather than go through all the trouble of figuring out which file sections were absolute, and which were relative, I figured it'd be just a lot easier on all of us if I wrote a TCP client that would read from mts_$mt, shove the data through the socket to a remote server that would receive the data and write it to mts_$ct. The problem is, after I get the data onto the remote cartridge and try to index it, only the first few files are index-able and then I get a UID-Mismatch. I've now determined that the size of the block or file headers are different from magtape to cartridge. So, now I've gotta figure out how to convert the headers once I've got them to a format readable by the cartridge driver. The hardware involved is a DSP-90 with multi-bus magtape controller and cipher 1600BPI drive. The remote node is a DN3500 with SCSI cartridge. My methodology is as follows: mts_$open_desc on the dsp, set file section to 1, read BLOCKSIZE of data, swap_bytes(buf), write(sockfd, buf, BLOCKSIZE). [NOTE: the multibus requires a byte swap] On the dn3500, I mts_$create_default_desc, set file section to 1, read(sockfd, buf, BLOCKSIZE), and ios_$put() buf onto the cartridge device. I've even tried reading from the magtape, into a disk file and them writing the disk file to cartridge which has the same effect. My questions are: Has anyone done this? Is anyone willing to throw any code my way? Can someone give me hints? Is anyone at HPollo willing to send me a .h file that describes the structure of the headers? Can someone verify that this is an impossible feat? Is this just a pipe (pun not intended) dream? Does anyone want the code I have so far? Is anyone else interested in doing this? If anyone can answer any of the above questions in an intelligible manner, feel free to call me at (403) 295-4711. I'm getting desperate. -------------------------------------------------------------------------- UUCP: herb@blender.UUCP || #define Janitor Administrator ICBM: 51 03 N / 114 05 W || Apollo System_Janitor, Novatel Communications "I spilled spot remover on my dog and now he's gone..." <Steven Wright>
herb@blender.uucp (Herb Peyerl) (12/13/90)
krowitz@RICHTER.MIT.EDU (David Krowitz) writes: >It would be much easier to simply use "rbak //old_node/directory -as /new_directory" >to read back the old 9-track tapes into whatever directory structure you wish >before re-writing the tapes back out on your ctape drive. But this requires indexing each file section before restoring it because some file sections have absolute pathnames, and some have relative pathnames. The tapes have 10 file-sections each on average and on over 100 tapes, that adds up to a heck of a lot of operator time. Although, it looks as though we're going to have to resort to this method... Yech... -- -------------------------------------------------------------------------- UUCP: herb@blender.UUCP || #define Janitor Administrator ICBM: 51 03 N / 114 05 W || Apollo System_Janitor, Novatel Communications "I spilled spot remover on my dog and now he's gone..." <Steven Wright>
krowitz@RICHTER.MIT.EDU (David Krowitz) (12/17/90)
The real problem you are having is that wbak encodes some UID data into the blocks of the data that differs depending on whether the tape is a 9-track tape or a cartridge tape. You'd have to get a full description of Apollo's wbak/rbak format in order to write the tape converter. It would be much easier to simply use "rbak //old_node/directory -as /new_directory" to read back the old 9-track tapes into whatever directory structure you wish before re-writing the tapes back out on your ctape drive. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference)