PDP-10.its/doc/cent/tapes.method

                   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, <return> 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 <return> after
	; each to proceed to the next, or a <rubout> 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 <space> again; instead, type <rubout> 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
<tab>		; 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

<tab>		; gibberish again
$$^R
-1<return>

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.