7-Track to 9-Track Copying Procedure Log an alter ego (HUMPTY, uname5) into the MX system console, so that your deeds will be recorded. It is strongly recommended that you stay near the machine while copying is progressing, to deal with any problems, so take advantage of the VT52 to read your mail or whatever. Load the first tape of the dump to be copied (henceforth the input tape) onto MX's drive. If vacuum fails to suck tape into esthetic round curves, do not put online; instead UNLOAD, reposition tape end correctly and try again. Load the first blank tape (henceforth the output tape) onto the Pygmalion et al drive; make sure HEP button on top is depressed. Door has mechanical catch at top; slide handle to right until orange dot disappears to open -- when you push LOAD, the door will close automatically. Use DENSITY SELECT to cycle density to GCR, which means 6250; make sure that SOFTWARE SELECT is -not- lighted. Put ONLINE when tape has loaded. On MX, do (user input is lowercase, system response is capital): dump$^k ; start :DUMP and load symbols. :DUMP prompt is _. _remote REMOTE TAPE HOST=hep DRIVE=0 READ-ONLY?n ; type space after each input for sys response, at end REMOTE TAPE REWOUND _ ; this response means :DUMP has successfully opened a channel to ; the Pyggy drive. For other responses, see below. ^z ; jump out of :DUMP to DDT. tcopy$g ; It will say to mount the tapes you have already mounted and ; type OK when ready to go ok Both tapes will now spin. If everything is on your side, nothing relevant will occur until about 10 minutes later, when the sysconsole will print a msg about PHYSICAL END OF INPUT TAPE and the MX drive will automatically rewind and unload its contents. Then it will say COPY ANOTHER TAPE ONTO SAME OUTPUT TAPE? ; Program requires full word response. If input dump includes more ; tapes: yes MOUNT NEXT INPUT TAPE ON LOCAL DRIVE TYPE OK WHEN READY ; do that, and away you go again. ; If tape just copied was last one of that input dump: no ; It will rewind and unload output tape -- Pyggy drive door will ; automagically open unless you latched it. :DUMP will reprint ; previous msg about loading tapes on both drives and typing OK. ; Do not do so. Instead: ^z :kill Then start again from DUMP$^K. Reusing the same :DUMP job for further output tapes after the first is theoretically supposed to work, but in practice only gets errors. This could theoretically be fixed, but this software has been kludged together for a limited purpose and no one has or is interested in making the time for such a relatively minor fix. If input tape does not fit onto remainder of output tape, you will get the msg: PHYSICAL END OF TAPE ? _rewind ; your response _unload _quit At this point, push RESET on the MX drive to get its attention, LOAD to rewind to load point, then put it back online. If output tape has not submitted to your unloading commands, RESET, then UNLOAD, and it will. When the output tape is unloaded, replace it with another blank tape, and start again from DUMP$^K above, thus starting the new output tape from the beginning of the input tape which was only partially copied. In general, 4+ input tapes will fill one output tape, but sometimes the fifth input tape will fit completely, so it's always worth the trial; I have never seen more than 5 input tapes fit on an output tape. Logging, Labelling, & Storing Tapes Follow established procedures. Use thin black ring binder for logging; binder lives in Alan's office, along with all the old ITS dump logs. Each day copying is done, write date in DATE column. Indicate each output tape made in REEL NO. column with name of machine dump was made on and first input tape number, e.g. "ML1032". For each input tape, write its number and first dir before the dash, and last dir (if known) after the dash, in FIRST & LAST USER column; for an input tape only partially copied onto an output tape, do not presume to indicate last dir. In DATE column give date original tapes were written. In DUMPED BY column give your name. For COMMENTS column, see below. If you run out of these form pages, get more from Ty or Alan. Sometimes the person who made the original dump forgot to note the first and last dirs dumped. You should try to discover at least the first dirs dumped on all tapes. Assemble the tapes in question for the dump you wish to copy, load the first one onto the MX drive, and log into the VT52. Then: :dump _list ; lists the files on the tape DEVICE=tty It will print a header indicating the tape number and when the dump was made, followed by lines like this: a FOO BAR 17 b date time Here, a= the ath file since :DUMP started winding the tape forward (be warned that partially rewinding the tape screws up this number), which happens to be the file FOO;BAR 17, which was resident on disk pack #b when it was dumped to this tape, and had last been written before the dump on "date" at "time". After a few of these, type ^g ; stops the listing and returns to :DUMP prompt. Now write down ; on a handy piece of paper the tape number, the dumped date, and ; FOO, the first dir dumped _rewind _unload ; replace tape with next consecutive one and start from LIST as ; above. By following this procedure for every tape in the dump, you create a list of dumped dates and first dirs which can then be transferred to the log when you do the copying. Note that this data can't be written directly into the log, as some input tapes are copied onto two output tapes. Labels and pen live in the disk cabinet amid MX, top shelf, the corner nearest the sysconsole. Use 1+1/2"x3" labels on output tapes: its Arch. c of d ; its= AI KA, ML KA, or MC KL, c= which ; tape in output set, d= total tapes in ; output set e - f, partial g ; e= first input tape, f= last input tape ; tape fully copied. g= input tape partially ; copied; omit this if not applicable. If some tape number in the ; consecutive set is missing (this can happen for a number of ; reasons) write "e - h, i - f" with h and i the tapes surrounding ; the missing one, and give fuller ; explanation in log. date(s) ; date or range of dates input tapes were ; written 9 track, 6250 bpi For tape edges, use labels supplied with the tapes, and same definitions as above: its Arch. c of d e - j ; j= g if g exists, else f date(s) When output tape is fully written, ease little plastic pane in over edge label, and remove write ring from back. Tapes are stored on an AI Lab rack in the southwest corner of the ninth floor -- the aisle closest the wall, the last rack on the left. Store tapes chronologically by date of original dumps; if dump dates overlap, do the best you can to be sensible. More tapes and labels come from the sotckroom; get Ty to get you some. Cleaning the Drive General drive cleaning involves: spraying all glass surfaces with Windex, wiping dry with Kimwipes; using Texpads to clean all vacuum column surfaces and everywhere else tape touches that they can reach; and using cotton swabs and alcohol to clean drive heads and EOT/BOT sensors. If Texpads are unavailable, find a DEC-supplied tape drive cleaning kit and use the "lint-free cloths" and the "solvent cleaner" instead. But these do an inferior job; pester Ty to obtain the right thing if you run out. Open Texpads carefully; if drive is not utterly filthy, it may be cleanable with only one side of pad, which can then be refolded and returned to its foil envelope (fold the end over tightly to seal) for later reuse. For copying, if tapes claim no errors, clean just heads and sensors every 4 input tapes, and clean drive fully every 100 input tapes, more or less. Errors Non-Recoverable Data Errors: These are the least dangerous errors, found during the copying process by the MX drive on the input tape: something was wrong with the copy of the file on the input tape such that :DUMP could not read it. Sometimes these include the name of the file so cursed, sometimes not. There is little you can do about these. Count the number that occur for each input tape, and note that as "k data errs" (if there were k errors) under the COMMENTS column in the log. If more than 2 such errors occur for a single tape, clean the MX drive heads and restart your count of how many input tapes before they should be cleaned again. If the cumulative error total since last cleaning is 4 or more, even if fewer than 4 tapes have been copied, clean the heads and restart your count. Remote Mount Failed: This error occurs instead of the REMOTE TAPE REWOUND msg. Check that the output tape is online, has a write ring, and that you spelled everything right in the REMOTE command. If that all looks OK, and if you had to switch the Pyg tape drive multi-port to HEP from some other host, especially if you switched from WH, suspect Unix braindamage: Vulcan (that's Hephaestus for short, or HEP for long) has not noticed that it can reach the drive again. The only way to fix it is to reboot Vulcan; in courtesy, check first to see whether anyone is using it before you do. To boot Vulcan, log into the system console (terminal to the right of the drive) as "root", pw "hewlett-packard", and do /etc/fastboot After about 5 minutes it will have booted. Premature EOT: This usually occurs within the first 1" depth of the input tape, and is often an indication of water damage (see below). What happens is the MX drive reads 2 consecutive end-of-file marks with nothing in between them, which is what constitutes an ITS logical end-of-tape mark, and assumes (quite reasonably for a machine) that the mark -does- indicate the end of the written tape; then :DUMP in its copying mode rewinds the input tape and asks whether you want to copy another input tape to the same output tape. The problem, of course, is when you believe that the EOT mark is an error and that more files exist on the tape after it. Do not touch the output tape or the job running on the sysconsole. Load the same tape on the MX drive. Log into the VT52. :dump _ ; Here you have a choice. If the tape generated a non-recoverable ; error on file number l sometime before it claimed to see an EOT, ; then _space l ; But if no such errors have occurred, or after the SPACE cmd ; returns if you gave it _list DEVICE=tty ; Eventually it will produce an error msg indicating EOT. ; At that point, note the number m of the last file before the EOT ; msg. Then _rewind ; the alternative would be to use SPACE, either just forward or ; backward and then forward, but this often gets tripped up by the ; false EOT mark. _space m+1 _lspace ; this cmd prints lines like LIST, but requires a after ; each to proceed to the next, or a to cease. If you can now seem file names again rather than EOT, then rewind again, space forward m+1, and quit out of the VT52 DUMP job. Turn to the sysconsole, which should still be waiting for your decision as to whether to copy another input tape, and tell it "yes". After you type "ok", it will ask the additional question: REWIND INPUT TAPE? ; the answer is no, of course -- you've just gone ; to all this trouble to position the tape exactly ; where you want it. Hope that you only have to do this once on that tape. Remain aware that you may have to do it several times. If an input tape copied to the first output tape produces more than one such error, the dump may be water damaged. Other signs of water damage include yellow on the tape or edge strip, or paint marks. If you suspect water damage, it is worth your while to take the time to check all the tapes of that dump before you try to copy it. Assemble the tapes, mount each one in turn, and list the first hundred files to the tty; for non-recoverable data errors, go ahead with copying, but if you find more than a few premature EOTs, consider punting on that dump, and instead copying the one done before it for that machine. If you do move back to the one before, check the appropriate dump log and put together an altered schedule of tapes to copy for that machine, so that they will be spaced yearly after the one you just chose. Current schedule lives in AI:CENT;TAPES SAVE -- if you edit it, do not delete anything, rather add and sign your changes. Broken Connection: If you get an error mentioning something to the effect of LOST RMT CHNL 17, then you have lost the connection between your DUMP job and the Vulcan tape drive. Quit out of that DUMP. If you were copying the first input tape for that output tape, rewind both tapes, and start again as if the first try never happened. If not, take the MX drive offline and rewind its tape, then put it online again. Meanwhile, log into the VT52 and run DUMP there, using REMOTE to connect to HEP. Look at the appropriate log book to figure out what was the first dir dumped to the input tape you were copying when the error occurred. Use either SPACE with a negative argument, or REWIND followed by SPACE forward, to position the tape just before any sign of this dir; use LSPACE to check, and SPACE forward until you're alphabetically close to that dir. Warning: using SPACE with a negative argument to a remote tape invariably breaks the connection. So whenever you do this, immediately give the REMOTE cmd again. The first time thereafter that you LSPACE (probably LIST would do this also), DUMP will claim you have hit EOT; ignore this lie and give the same cmd again, and it will behave properly -- until the next time you space backwards over the net. Once you are close to that first dir, use LSPACE to move forward until you see the first file of that dir; note that file's name. Continue to LSPACE forward until you see that file again -- that is the point where the current input tape started. Note down the name of the file just before that, which is the last file on the previous input tape. Now space a few files backwards, re-establish your connection, and LSPACE forward carefully. When the file listed is the one you noted as the last file of the previous dump, do -not- type again; instead, type so the LSPACE cmd is aborted and you are return to DUMP cmd level. The output tape is now positioned right where it was when the current input tape was started. Quit out of the DUMP on the VT52, and start again with DUMP$^K. This procedure causes the name of the first file on the current input tape to be scrambled on the output tape. However, the data is all there; also, that first file had already been copied from the previous input tape (with a few rare exceptions), so usually nothing is lost. Machine Dies: Treat this like a broken connection, except that you must revive MX before you can play with the tapes. Sysconsole dies: The KL lights are blinking, but the sysconsole isn't typing, and the tapes have stopped moving. This probably means the console 11 (part of the KL) has died. If you are not logged into the VT52, it may not let you log in, in which case you may not be able to follow the directions below; that probably means you will have to reboot MX, and proceed as if it had died. If you are provident enough to have logged into the VT52, try starting a job, say :P. If that doesn't work, then the SYS job has become a little scrambled, and you must fix it. Incant the following: sys^H upc/ ; it will type some gibberish ; more gibberish ^ ; hat rather than ctrl -- this should produce something ; about PUSHJ P,UFLS ^ ; again, hat -- this should say 170457/ SKIPL foo(I) for ; some value of foo ; gibberish again $$^R -1 Now the SYS job is fixed. However, your copying DUMP is still lost. On the VT52, do pty^H ; this will produce an inferior HACTRN for you to log into ; again. However, rather than logging in, do: :reatta uname/k ; with UNAME being the uname you had logged into the ; sysconsole as. Now the copying dump is talking to the VT52. But since there is no paper record, you must sit there and count the non-recoverable data errors. It's most prudent at this point to continue running the copy from the VT52 until the end of the current output tape. Then bring MX down and reboot it to reset things, and start copying again from the sysconsole. While the copy is running from the VT52, you may need to take some of the steps recommended above that involve running DUMP on the VT52 to examine things. If this occurs, ^Z out of the copying DUMP, and start a -second- DUMP job to do the examining. When you're ready to copy again, kill the second DUMP and return to the copying one.