1
0
mirror of https://github.com/PDP-10/its.git synced 2026-02-27 01:09:49 +00:00

Documentation about how to handle magtapes.

- Old AI-KA and OZ Tapes and What to Do with Them
- How to copy 7 track tapes to remote 9 track tapes
- ITS Tape-Saving Project
This commit is contained in:
Lars Brinkhoff
2019-06-14 08:04:10 +02:00
parent 80bdb40d41
commit 110460c262
5 changed files with 1406 additions and 1 deletions

View File

@@ -34,7 +34,7 @@ DOC = info _info_ sysdoc sysnet syshst kshack _teco_ emacs emacs1 c kcc \
xfont maxout ucode moon acount alan channa fonts games graphs humor \
kldcp libdoc lisp _mail_ midas quux scheme manual wp chess ms macdoc \
aplogo _klfe_ pdp11 chsncp cbf rug bawden llogo eak clib teach pcnet \
combat pdl minits mits_s chaos hal -pics- imlac maint
combat pdl minits mits_s chaos hal -pics- imlac maint cent
BIN = sys sys1 sys2 emacs _teco_ lisp liblsp alan inquir sail comlap \
c decsys graphs draw datdrw fonts fonts1 fonts2 games macsym \
maint imlac _www_ gt40 llogo bawden sysbin -pics- lmman r

79
doc/cent/tapes.flush Executable file
View File

@@ -0,0 +1,79 @@
Old AI-KA and OZ Tapes and What to Do with Them
Boxes 1-7 contain old AI incremental tapes. These should be thrown out
without question; they are too used to be reliable. In Box 8, tapes
AI336-AI350 are also incremental and should also be tossed.
Boxes 8-110 contain old AI full dumps, AI600-AI3085. I would not re-use
any from before tape AI2558 (Feb. 1980); the earlier ones are too old to be
reliable. In these boxes the following tapes are GFR tapes (like ARCH or
MIGR tapes from Twenex):
1264, 1265, 1301, 1334, 1335, 1367, 1407, 140
and should be treated however the explicitly-labeled GFR tapes are.
Boxes 110-111 contain GFR tapes GFR1-GFR32. It would be kind of nice to
preserve these, just in case anyone ever wants the info enough to pay for
IPS to read it, or something. They should not be re-used; they are too
worn to be reliable.
Boxes 111-112 contain a number of random personal tapes; as far as I am
concerned they are re-usable, modulo age and wear.
Boxes 112-158 contain old OZ full dump tapes. These are no older than
1982, and are the best candidates for re-use after those on the racks (see
below). Boxes 133, 150, and 151 do not exist; I emptied them while
choosing OZ full dumps to save.
Boxes 158-159 contain some blank and recopied OZ MIGR dumps. Do not re-use
any which have already been used; throw them out.
Consider the racks by the wall to be numbered as follows:
1 2 3 4 window
9 8 7 6 5 wall
--------------------wall----------------
Rack 1 contains the OZ full dumps Laurel desinated for re-use. I have no
quarrels with these.
Rack 2 is now empty.
Rack 3 contains the newer OZ tapes now being saved (June 86-June 88), while
Rack 4 contains the older ones (July 82-May 86). We are currently saving
the following from before 1985:
full dumps from July 82, July 83, and June 84
SRC and TINMAN dumps of Jan84 (last dumps before merger into PS)
first KANSAS dump (Nov 84)
last extant VISION dump (also Nov 84)
i wish laurel had asked me about which tapes to save before she started
re-using them, since the last VISION dump should have been saved, but done
is done. the principle is that while SRC, TINMAN, and VISION no longer
existed when the machine died, they were valid structures when they did
exist, and so contained real files that people might care about.
When you decide to compress the OZ tapes further, the following dumps
should be preserved:
those mentioned above, which i saved from the boxes
Aug 85 dumps (PS F00031 #1-35, SS F00029 #1-4, KANSAS F00005 #1-13)
June 86 dumps (PS OF0040-49, KANSAS OK0013-17, SS OS0003)
June 87 dumps (PS OF0114-124, SS OS0010, KANSAS OK0041-44)
June 88 dumps (KANSAS OK0069-72, SS OS0016, PS OF0203-213)
Rack 5 contains another set of AI-KA incremental dumps (AI200-AI350 or so)
which should be tossed without question, and some more AI full dumps
(AI500-AI599), which should be treated like the AI full dumps in the boxes.
Rack 6 contains HTJR dumps and old AI-KA personal tapes. The HTJR tapes
are candidates for re-use, though you should first try asking GSB whether
there is anything useful on them -- HTJR was being used for VMS NIL
development during this period. The AI tapes are too old to be re-usable.
Rack 7 contains dumps from RMS's Lispm file system, which can be re-used or
trashed as you please. There are also lots of personal and system tapes
there, most of which are labeled. For the ITS and Lispm board tapes, I
suggest that you have TK look at them before you decide to trash them --
they should not be re-used, they are too old. For the other random system
tapes, do what you please.
Racks 8 and 9 contain dumps from various Vaxen; you can probably figure out
better than I what do do with these.

582
doc/cent/tapes.howcpy Executable file
View File

@@ -0,0 +1,582 @@
MX ITS.1578. DDT.1518.
TTY 47
5. Lusers, Fair Share = 82%
alan5$u--Init--
ttp?
MX 21:40 80% 5. 101.
dump^K!
DUMP .403
_remote TAPE SERVER HOST=hep DRIVE=0 READ-ONLY? n
REMOTE TAPE REWOUND
_^Z
MX 21:41 81% 5. 100. (DUMP 0.2)
$^K
MX 21:41 79% 5. 100. (DUMP 0.2)
tcopy$g'DUMPER$:
Mount input tape on local drive and blank output tape on remote drive.
Type OK when ready. ok
End of tape.
Copy another tape onto same output tape? yes
Mount next input tape on local drive.
Type OK when ready. ok
PHYSICAL END OF TAPE ?
_flap
Remote tape status=System error: 6
_flap
^Z
MX 22:25 88% 7. 93. (DUMP 2:28.2)
$^X.
MX 22:25 86% 7. 94.
dump^K!
DUMP .403
_rewind
_^Z
MX 22:29 86% 7. 93. (DUMP 0.1)
dump^K--Clobber Existing Job--
DUMP .403
_remote TAPE SERVER HOST=hep DRIVE=0 READ-ONLY? n
REMOTE TAPE REWOUND
_
MX 22:30 81% 7. 93. (DUMP 0.2)
$^K
MX 22:30 81% 7. 93. (DUMP 0.2)
tcopy$g'DUMPER$:
Mount input tape on local drive and blank output tape on remote drive.
Type OK when ready. ok
MAG TAPE STATUS NO-OP 800BPI EVEN PAR
WRITE-LOCK 39 THE TMP 2 DATA ERROR TAPE IN ..FILE BEING SKIPPED..
NON-RECOVERABLE DATA ERROR
End of tape.
Copy another tape onto same output tape? no
Mount input tape on local drive and blank output tape on remote drive.
Type OK when ready. ^Z
MX 22:47 89% 5. 96. (DUMP 1:15.6)
dump^K--Clobber Existing Job--
DUMP .403
_remote TAPE SERVER HOST=hep DRIVE=0 READ-ONLY? n
REMOTE TAPE REWOUND
_
MX 22:47 84% 5. 96. (DUMP 0.2)
$^K
MX 22:47 83% 5. 96. (DUMP 0.2)
tcopy$g'DUMPER$:
Mount input tape on local drive and blank output tape on remote drive.
Type OK when ready. ok
MAG TAPE STATUS NO-OP 800BPI EVEN PAR
WRITE-LOCK 5 DATA ERROR TAPE IN ..FILE BEING SKIPPED..
NON-RECOVERABLE DATA ERROR
End of tape.
Copy another tape onto same output tape? yes
Mount next input tape on local drive.
Type OK when ready. ok
PHYSICAL END OF TAPE ?
_flap
_quit
:KILL
MX 23:10 85% 5. 101.
dump^K!
DUMP .403
_rewind
_quit
:KILL
MX 23:14 85% 5. 101.
dump ^H!
DUMP .403
_remote TAPE SERVER HOST=hep DRIVE=0 READ-ONLY? n
REMOTE TAPE REWOUND
_
MX 23:18 81% 5. 100. (DUMP 0.2)
$^K
MX 23:18 81% 5. 100. (DUMP 0.2)
tcopy$g'DUMPER$:
Mount input tape on local drive and blank output tape on remote drive.
Type OK when ready. ok
End of tape.
Copy another tape onto same output tape? no
Mount input tape on local drive and blank output tape on remote drive.
Type OK when ready. ^Z
MX 23:29 73% 8. 93. (DUMP 1:13.8)
$^X.
MX 23:29 76% 8. 94.
dssump ^H!
DUMP .403
_remote TAPE SERVER HOST=hep DRIVE=0 READ-ONLY? n
REMOTE TAPE REWOUND
_^Z
MX 23:32 78% 7. 95. (DUMP 0.2)
$^K
MX 23:32 78% 7. 95. (DUMP 0.2)
tcopy$g'DUMPER$:
Mount input tape on local drive and blank output tape on remote drive.
Type OK when ready. ok
MAG TAPE STATUS NO-OP 800BPI EVEN PAR
WRITE-LOCK 1 BAK MUPRO 10 DATA ERROR TAPE IN ..FILE BEING SKIPPED..
NON-RECOVERABLE DATA ERROR
End of tape.
Copy another tape onto same output tape? yes
Mount next input tape on local drive.
Type OK when ready. ok
MAG TAPE STATUS NO-OP 800BPI EVEN PAR
WRITE-LOCK 10 DATA ERROR TAPE IN ..FILE BEING SKIPPED..
NON-RECOVERABLE DATA ERROR
MAG TAPE STATUS NO-OP 800BPI EVEN PAR
WRITE-LOCK 29 AP NSF 1 DATA ERROR TAPE IN ..FILE BEING SKIPPED..
NON-RECOVERABLE DATA ERROR
PHYSICAL END OF TAPE ?
_flap
Remote tape status=System error: 6
_flap
^Z
MX 00:26 86% 4. 103. (DUMP 2:32.1)
dump^K--Clobber Existing Job--
DUMP .403
_rewind
_quit
:KILL
MX 00:27 86% 4. 104.
^L
dump^K!
DUMP .403
_remote TAPE SERVER HOST=hep DRIVE=0 READ-ONLY? n
REMOTE TAPE REWOUND
_
MX 00:30 86% 4. 103. (DUMP 0.2)
$^K
MX 00:30 86% 4. 103. (DUMP 0.2)
tcopy$g'DUMPER$:
Mount input tape on local drive and blank output tape on remote drive.
Type OK when ready. ok
MAG TAPE STATUS NO-OP 800BPI EVEN PAR
WRITE-LOCK 29 AP NSF 1 DATA ERROR TAPE IN ..FILE BEING SKIPPED..
NON-RECOVERABLE DATA ERROR
End of tape.
Copy another tape onto same output tape? no
Mount input tape on local drive and blank output tape on remote drive.
Type OK when ready.
MX 00:41 91% 3. 105. (DUMP 1:13.7)
dump^K--Clobber Existing Job--
DUMP .403
_remote TAPE SERVER HOST=milo DRIVE=3 READ-ONLY? n
Remote mount failed: Host not found in host table
_
MX 00:48 88% 3. 105. (DUMP 0.2)
$p
remote TAPE SERVER HOST=opus DRIVE=3 READ-ONLY? n
Remote mount failed: Host not found in host table
_rem ?
_remote TAPE SERVER HOST=milo DRIVE=0 READ-ONLY? n
Remote mount failed: Host not found in host table
_remote TAPE SERVER HOST=milo.lcs.mit.edu DRIVE=0 READ-ONLY? n
Remote mount failed: Host not found in host table
_REMOTE TAPE SERVER HOST=MILO.LCS.MIT.EDU DRIVE=3 READ-ONLY? N
Remote mount failed: Host not found in host table
_REMOTE TAPE SERVER HOST=OPUS DRIVE=0 READ-ONLY? N
Remote mount failed: Host not found in host table
_
MX 00:50 89% 3. 105. (DUMP 1.0)
DUMP^K--Clobber Existing Job--
DUMP .403
_REMOTE TAPE SERVER HOST=MILO.LCS.MIT.EDU DRIVE=3 READ-ONLY? N
Remote mount failed: Host not found in host table
_
MX 00:50 90% 3. 105. (DUMP 0.2)
:HOST MILO
MILO.LCS.MIT.EDU (MILO, MIT-MILO, MIT-MILO.ARPA) "SERVER"
System: UNIX CPU: VAX-11/750
MIT-TEMP = 18.10.0.86 (12/126) 2202,,400126
(no services listed)
:KILL DUMP$J
MX 00:50 87% 3. 105. (DUMP 0.2)
:HOST OPUS
OPUS.LCS.MIT.EDU (MIT-OPUS, MIT-OPUS.ARPA, OPUS) "SERVER"
System: UNIX CPU: VAX-11/750
MIT-TEMP = 18.10.0.87 (12/127) 2202,,400127
(no services listed)
:KILL DUMP$J
MX 00:51 90% 3. 105. (DUMP 0.2)
DUMP^K--Clobber Existing Job--
DUMP .403
_REMOTE TAPE SERVER HOST=HERMES DRIVE=0 READ-ONLY? N
REMOTE TAPE REWOUND
_
MX 00:54 90% 3. 105. (DUMP 0.2)
$^K
MX 00:54 90% 3. 105. (DUMP 0.2)
TCOPY$G'DUMPER$:
Mount input tape on local drive and blank output tape on remote drive.
Type OK when ready. OK
End of tape.
Copy another tape onto same output tape? yes
Mount next input tape on local drive.
Type OK when ready. ok
MAG TAPE STATUS NO-OP 800BPI EVEN PAR
WRITE-LOCK 114 DATA ERROR TAPE IN ..FILE BEING SKIPPED..
NON-RECOVERABLE DATA ERROR
End of tape.
Copy another tape onto same output tape? no
Mount input tape on local drive and blank output tape on remote drive.
Type OK when ready.
MX 01:31 89% 3. 104. (DUMP 1:34.0)
dump^K--Clobber Existing Job--
DUMP .403
_remote TAPE SERVER HOST=hermes DRIVE=0 READ-ONLY? n
REMOTE TAPE REWOUND
_
MX 01:32 90% 3. 104. (DUMP 0.2)
$^K
MX 01:32 89% 3. 104. (DUMP 0.2)
tcopy$g'DUMPER$:
Mount input tape on local drive and blank output tape on remote drive.
Type OK when ready. ok
End of tape.
Copy another tape onto same output tape? yes
Mount next input tape on local drive.
Type OK when ready. ok
End of tape.
Copy another tape onto same output tape? no
Mount input tape on local drive and blank output tape on remote drive.
Type OK when ready. ^Z
MX 02:15 88% 6. 97. (DUMP 2:31.9)
dump^K--Clobber Existing Job--
DUMP .403
_remote TAPE SERVER HOST=hermes DRIVE=0 READ-ONLY? n
REMOTE TAPE REWOUND
_
MX 02:21 86% 6. 97. (DUMP 0.2)
$^K
MX 02:22 86% 6. 97. (DUMP 0.2)
tcopy$g'DUMPER$:
Mount input tape on local drive and blank output tape on remote drive.
Type OK when ready. ok
MAG TAPE STATUS NO-OP 800BPI EVEN PAR
WRITE-LOCK 633 MAXDEV SYNEX 9 DATA ERROR TAPE IN ..FILE BEING SKIPPED..
NON-RECOVERABLE DATA ERROR
End of tape.
Copy another tape onto same output tape? yes
Mount next input tape on local drive.
Type OK when ready. ok
End of tape.
Copy another tape onto same output tape? no
Mount input tape on local drive and blank output tape on remote drive.
Type OK when ready.
MX 02:53 89% 5. 99. (DUMP 2:30.9)
$^X.
MX 02:53 89% 5. 100.
$$v
MX 04:04 84% 5. 102.
dump^K!
DUMP .403
_remote TAPE SERVER HOST=hermes DRIVE=0 READ-ONLY? n
REMOTE TAPE REWOUND
_
MX 04:04 88% 5. 101. (DUMP 0.2)
$^K
MX 04:04 89% 5. 101. (DUMP 0.2)
tcopy$g'DUMPER$:
Mount input tape on local drive and blank output tape on remote drive.
Type OK when ready. ok
MAG TAPE STATUS NO-OP 800BPI EVEN PAR
WRITE-LOCK 0 DATA ERROR TAPE IN ..FILE BEING SKIPPED..
NON-RECOVERABLE DATA ERROR
MAG TAPE STATUS NO-OP 800BPI EVEN PAR
WRITE-LOCK 2 EAK ^MAIL 42 DATA ERROR TAPE IN ..FILE BEING SKIPPED..
NON-RECOVERABLE DATA ERROR
MAG TAPE STATUS NO-OP 800BPI EVEN PAR
WRITE-LOCK 2 DATA ERROR TAPE IN ..FILE BEING SKIPPED..
NON-RECOVERABLE DATA ERROR
MAG TAPE STATUS NO-OP 800BPI EVEN PAR
WRITE-LOCK 7 FJW BABYL M10110DATA ERROR TAPE IN ..FILE BEING SKIPPED..
NON-RECOVERABLE DATA ERROR
MAG TAPE STATUS NO-OP 800BPI EVEN PAR
WRITE-LOCK 96 GARBER TMP1 EDG DATA ERROR TAPE IN ..FILE BEING SKIPPED..
NON-RECOVERABLE DATA ERROR
MAG TAPE STATUS NO-OP 800BPI EVEN PAR
WRITE-LOCK READ-COMPARE-ERROR TAPE-PARITY-ERROR 98 GARBER WORK EDG DATA ERROR TAPE IN ..FILE BEING SKIPPED..
NON-RECOVERABLE DATA ERROR
MAG TAPE STATUS NO-OP 800BPI EVEN PAR
WRITE-LOCK 118 JLK% RAYSIM FUDGE DATA ERROR TAPE IN ..FILE BEING SKIPPED..
NON-RECOVERABLE DATA ERROR
MAG TAPE STATUS NO-OP 800BPI EVEN PAR
WRITE-LOCK 139 DATA ERROR TAPE IN ..FILE BEING SKIPPED..
NON-RECOVERABLE DATA ERROR
End of tape.
Copy another tape onto same output tape? yes
Mount next input tape on local drive.
Type OK when ready. ok
MX 04:21 86% 5. 100. (DUMP 1:24.2)
^P
MX 04:21 88% 5. 100. (DUMP Running 1:24.2)
^Z?? ^X
RSXSND+5) .CALL 33267 (PKTIOT) $p
End of tape.
Copy another tape onto same output tape? no
Mount input tape on local drive and blank output tape on remote drive.
Type OK when ready.
MX 04:34 91% 5. 100. (DUMP 1:56.3)
^Zdump^K--Clobber Existing Job--
DUMP .403
_remote TAPE SERVER HOST=hermes DRIVE=0 READ-ONLY? n
REMOTE TAPE REWOUND
_
MX 04:35 87% 5. 100. (DUMP 0.2)
$^K
MX 04:35 87% 5. 100. (DUMP 0.2)
tcopy$g'DUMPER$:
Mount input tape on local drive and blank output tape on remote drive.
Type OK when ready. ok
End of tape.
Copy another tape onto same output tape? yes
Mount next input tape on local drive.
Type OK when ready. ok
End of tape.
Copy another tape onto same output tape? no
Mount input tape on local drive and blank output tape on remote drive.
Type OK when ready.
MX 05:04 90% 5. 100. (DUMP 2:20.6)
dump^K--Clobber Existing Job--
DUMP .403
_remote TAPE SERVER HOST=hermes DRIVE=0 READ-ONLY? n
REMOTE TAPE REWOUND
_
MX 05:07 85% 5. 100. (DUMP 0.2)
$^K
MX 05:07 86% 5. 100. (DUMP 0.2)
tcopy$g'DUMPER$:
Mount input tape on local drive and blank output tape on remote drive.
Type OK when ready. ok
End of tape.
Copy another tape onto same output tape? yes
Mount next input tape on local drive.
Type OK when ready. ok
End of tape.
Copy another tape onto same output tape? no
Mount input tape on local drive and blank output tape on remote drive.
Type OK when ready.
MX 05:35 89% 5. 100. (DUMP 2:24.4)
dump^K--Clobber Existing Job--
DUMP .403
_remote TAPE SERVER HOST=hermes DRIVE=0 READ-ONLY? n
REMOTE TAPE REWOUND
_
MX 05:39 89% 5. 100. (DUMP 0.2)
$^K
MX 05:39 89% 5. 100. (DUMP 0.2)
tcopy$g'DUMPER$:
Mount input tape on local drive and blank output tape on remote drive.
Type OK when ready. ok
MAG TAPE STATUS NO-OP 800BPI EVEN PAR
WRITE-LOCK 7 RHB% FOO 181 DATA ERROR TAPE IN ..FILE BEING SKIPPED..
NON-RECOVERABLE DATA ERROR
MAG TAPE STATUS NO-OP 800BPI EVEN PAR
WRITE-LOCK 165 BGK AR7 1 DATA ERROR TAPE IN ..FILE BEING SKIPPED..
NON-RECOVERABLE DATA ERROR
MAG TAPE STATUS NO-OP 800BPI EVEN PAR
WRITE-LOCK 217 DATA ERROR TAPE IN ..FILE BEING SKIPPED..
NON-RECOVERABLE DATA ERROR
MAG TAPE STATUS NO-OP 800BPI EVEN PAR
WRITE-LOCK 219 DATA ERROR TAPE IN ..FILE BEING SKIPPED..
NON-RECOVERABLE DATA ERROR
MAG TAPE STATUS NO-OP 800BPI EVEN PAR
WRITE-LOCK 221 DATA ERROR TAPE IN ..FILE BEING SKIPPED..
NON-RECOVERABLE DATA ERROR
MAG TAPE STATUS NO-OP 800BPI EVEN PAR
WRITE-LOCK 228 DATA ERROR TAPE IN ..FILE BEING SKIPPED..
NON-RECOVERABLE DATA ERROR
End of tape.
Copy another tape onto same output tape? yes
Mount next input tape on local drive.
Type OK when ready. ok
End of tape.
Copy another tape onto same output tape? no
Mount input tape on local drive and blank output tape on remote drive.
Type OK when ready.
MX 06:06 86% 7. 98. (DUMP 2:08.8)
dump^K--Clobber Existing Job--
DUMP .403
_remote TAPE SERVER HOST=hermes DRIVE=0 READ-ONLY? n
REMOTE TAPE REWOUND
_
MX 06:10 83% 7. 97. (DUMP 0.2)
$^K
MX 06:10 83% 7. 97. (DUMP 0.2)
tcopy$g'DUMPER$:
Mount input tape on local drive and blank output tape on remote drive.
Type OK when ready. ok
MAG TAPE STATUS NO-OP 800BPI EVEN PAR
WRITE-LOCK 0 DATA ERROR TAPE IN ..FILE BEING SKIPPED..
NON-RECOVERABLE DATA ERROR
End of tape.
Copy another tape onto same output tape?
MX 06:10 86% 7. 97. (DUMP 0.4)
dump^K--Clobber Existing Job--
DUMP .403
_reER??
_??
_list
LIST DEV =tty
MAG TAPE STATUS NO-OP 800BPI EVEN PAR
WRITE-LOCK 1 DATA ERROR TAPE IN ..FILE BEING SKIPPED..
NON-RECOVERABLE DATA ERROR
E-O-T
REEL = 262143
_rewind
_
MX 06:11 90% 7. 97. (DUMP 0.2)
^R (Print File) $
DSK: ALAN; > > mt0:
MT0: ALAN; - NON-RECOVERABLE DATA ERROR
a^F
MX ALAN
FREE BLOCKS #0=880 - #1=2206 #15=2356 #14=1732 -
15 AI MOVE 1 12/12/85 01:46:18
15 MOVED TO AI 4 4/15/86 02:41:08
14 . .. 1 12/16/86 19:56:33
0 . MTERR 1 $9/27/86 00:35:36
1 . NOTGFR 4 $3/9/86 22:17:09
1 . TCOPY 1 $5/27/86 14:16:57
15 ..NEW. M.F.D. 2 1/23/86 17:53:01
14 .GFR 72 1 10/20/86 14:35:48
14 .GFR 73 1 10/20/86 14:35:30
* 0 .PHOTO 1 2 ! 2/12/87 21:40:48
14 @ SALV 13 5/10/86 36:20:16
16 AIMOVE 13 1 2/1/86 09:40:53
14 AIMOVE 14 1 2/15/86 15:48:27
14 AIMOVE BABYL 4 4/12/86 10:26:07
0 ALAN (CMDS) 1 9/28/86 20:05:57
14 ALAN COMPLR 1 10/5/86 04:04:19
1 ALAN EMACS 9 10/28/86 19:58:10
1 ALAN LISP 1 $3/13/83 03:26:17
1 ALAN LOGIN 1 9/8/86 20:36:08
14 ALAN XMAIL 6 4/12/86 10:23:10
14 ALAN _X 1 10/28/86 22:00:40
0 BACKUP LIST 1 $11/3/85 15:22:35
15 BINDA 46 2 $4/3/83 02:10:46
0 BINDA FASL 2 $4/3/83 02:26:03
16 CHAMAP BIN 1 1/23/86 10:42:29
15 CMORD 131 5 3/24/86 19:26:16
15 COPY BIN 1 5/20/86 11:32:06
14 CRAWL 18 1 $2/6/84 05:55:43
0 CRAWL FASL 1 $2/6/84 05:55:46
1 CRD BABYL 1 $7/25/82 12:21:47
1 CRD LOGIN 1 $7/11/84 23:56:44
14 CRD MAIL 29 9/22/86 11:55:45

342
doc/cent/tapes.method Executable file
View File

@@ -0,0 +1,342 @@
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.

402
doc/cent/tapes.save Executable file
View File

@@ -0,0 +1,402 @@
ITS Tape-Saving Project
Project MAC, whence descended the AI Lab and LCS, developed a highly
unusual operating system called ITS (Incompatible Timesharing System). For
many years it was the only, or the chief, OS used at the labs, so most of
the seminal work done here was done on machines running ITS. Full ITS
first ran on the AI PDP6, and was ported to the DM PDP6. Later, PDP10s
became available, and the labs acquired some of the earliest ones -- the
AI-KA10 (AI Lab's machine), the ML KA-10 (used by the MathLab, Theory of
Computation, Automatic Programming, and certain other LCS groups), and the
DMS KA-10 (Dynamic Modeling Systems, also used by certain other LCS
groups); these replaced the PDP-6s, which were slowly phased out. The
well-known MACSYMA program was started on the AI-KA, moved to the ML-KA
when that machine came online and there underwent much development, and
finally needed some space to really run. At that point the Macsyma
Consortium was established and bought MC, the first KL-10A installed
outside DEC. MACSYMA continued to be upgraded on MC, as well as used by
the many Macsyma Consortium customers, who often stored their data and
special applications on the KL.
After many years of overuse and under-maintenance, the latter generally
performed by a small cadre of lab members who stole time from their other
responsibilities to keep the machines going, the old ITS machines have
slowly surrendered to the ravages of time, and gone the way of all silicon.
The KAs were disposed of about four years ago. The KL, renamed MX in 1986,
is reeling; while it was recently revived, its disk drives and memory boxes
are in very bad shape, and we expect to dispose of it soon. The old ITS
machines have been replaced by new, physically smaller, much more easily
maintainable KS-10s (DEC-2020s), which sustain the ITS operating system
(which, like the recently lamented Multics, contains many system features
that are just now being discovered by the outside world), its atmosphere of
cooperation in research, and what (after fifteen years) is still one of the
best mail-delivery systems on the Internet.
Why, when the old machines have been replaced by new hardware, is any
comment needed? Because the AIKA, the MLKA, and the KL all had 7-track,
800bpi (bits per inch) tape drives, and all their backup tapes were written
on these drives. Even as early as the mid-1970s, 7-track drives were being
superseded by 9-track drive technology; by now, 7-track drives are
impossible to find. So the labs now possess a couple rooms full of backup
tapes written at 7 tracks -- the tapes contain the labs' history, but due
to the track difference, are unreadable on any hardware the labs now own or
are likely to be able to get. Moreover, since the tapes were written at
800bpi, they fill two rooms' worth of space, which the labs would prefer to
put to more productive use.
We want to preserve the labs' history, and free that space, by copying
a certain subset of those tapes to modern format. For that reason, LCS has
had the KL repaired one last time, so the old tapes can be read on its
drive, and using available software, copied to the more modern format of 9
tracks, 6250bpi. We propose to copy approximately one full dump per year
per ITS, as well as all the GFR tapes (Grim File Reaper -- a rough
equivalent of Twenex archiving); this should include on the order of 900
old tapes, which will be copied onto 175-200 new tapes. When this project
has been accomplished, the new tapes will contain most of the work done on
the old ITS machines, and all the old 7-track tapes can then be disposed
of. We realize that not everything will be saved, but this method of
copying snapshots and GFRs should preserve most of the labs' important
work.
Concerning DM: for some reason, the DM-KA had a 9-track, 800bpi drive,
so all its backup tapes were written in that format. As long as LCS
maintains a similar format drive (suitable drives are now in use on XX),
the DM tapes will be readable; a small program would need to be written to
translate the data, but the ITS tape format is simple and well-documented,
so such a project should be trivial for any competent systems programmer.
Of course, when the labs consider disposing of their last drives which read
9-track, 800bpi tapes, or when LCS wants to free the space currently used
by the DM-KA tapes, a project like this one should be undertaken to
preserve the DM history.
Requirements:
Time: Each tape takes about 10 minutes to copy, if everything goes
well. However, due to tape age and in some cases frequent use, as well as
machine and network trouble, problems do occur, so a safer estimate would
be 15 minutes per tape. For 900 tapes, that translates as 225 hours of
copying, or approximately 5 weeks' work for one person (at standard 40hr.
weeks). With some competent assistance during hours when I am not
available, this period might be halved. These estimates are based on Alan
Bawden's work copying some of the MX GFR tapes to 1600bpi; since GFR tapes
are by far the most abused ITS backups, the full dump tapes might not
produce as many problems, but it is prudent to assume they will.
Material: We need about 200 new 2400' tapes, of quality suitable for
having data written at 6250bpi. A moderate quantity of documenting
paraphernalia will be needed to label them all.
Hardware: The MX-KL must keep running in at least as good shape as it
currently does; it has the only available 7-track drive. The Chaosnet,
specifically Subnet 6, the piece on which the ITS machines reside, must
bear traffic well; it is the only way for the KL to send the tape data out.
At least one of the AI Lab machines with 6250bpi tape drives (HERMES,
VULCAN) must be usable, because they are the only sites the new tapes can
be written. The LCS machine MILO has a 6250bpi drive but is not on the
Chaosnet, and so is unusable for this purpose.
Software: Already available; written by Dave Moon of Symbolics.
People: Me, at full time or so for 3-4 weeks. Some effort from Ty and
his crew when they are here but I'm not. Assistance at troubleshooting
from Alan Bawden (AIL), John Wroclawski (LCS), and if necessary Dave Moon
(Symbolics), to keep the hardware functional and solve any remaining
software bugs.
Possible other expenses: Tom Knight (AIL) has suggested that the new
tapes, once written, should be copied (thus providing us 2 complete set of
the snapshots and GFRs), and that one of these sets should be stored
somewhere other than in NE43. Such copying can be done, he says, by
outside firms for a relatively modest price. There is precedent for
storing lab tapes offsite; for several years, many of the ITS backup tapes
were stored in the old wind tunnel building; they were returned here when
IPS (now IS) took over that space for its main computer facility.
Magic fix for MX sysconsole going west:
sys^H
upc/
^I
^ -> PUSHJ P,UFLS
^ -> SKIPL foo(I) ; inst. # 170457
^I
$$^R
-1<return>
pty^H
:reatta CENT5/k
12654
print: 40685
A prospective set of old ITS tapes to be copied
Note that not all input tapes are full, and some may be unreadable. If a
particular dump provides an excess of problems, we will have to use another
nearby chronologically, and adjust the remainder accordingly. Any output
tape used to finish copying a full dump will end up only partially full.
Prefer using "Archive" dumps to "Full" dumps; on the other hand, prefer
using tapes not marked as having been hit by the basement flood to those
marked as so doused.
The software does not allow splitting of input tapes onto output tapes;
in other words, any input tape which runs off the end of the output tape
it's being copied onto must be started again on a new output tape. We know
that due to differences in inter-record gaps, 2 800bpi tapes sometimes fit
onto one 1600bpi tape, and sometimes run over (requiring a second 1600bpi
tape). We don't know what the 800-6250 ratio will be; division suggests
that 7 old tapes will fit onto 1 new tape, but Dave Moon suspects that the
inter-record gap diffence will allow only 5-6 old tapes per new one. The
conservative ratio of 1:5 has been used in the table below; we might be
able to do better, but should not count on it.
To retain coherency among the new tapes, each full dump will be copied
to a separate set; thus for each full dump, there will be one new tape only
partially full, containing its last files. Tape is not expensive enough to
subject future users of these tapes to the confusion that would result from
jamming all tapes full without leaving these gaps. GFR tapes, however, can
be copied as many as fit per tape.
In the tables below, an input dump date preceded by * indicates an
alternate to the previous dump. I use the most conservative number of
output tapes needed for all sets of possible alternates. Note that ITS
archive dumps are pretty much regular full dumps; originally there was an
intent to save them longer or treat them as more sacred than ordinary full
dumps, but this seems to have been washed away in the basement flood (in
which many of the arch dump tapes were caught) if not earlier.
Addendum: All tapes actually copied have been recorded in the copy logbook.
The prospective lists below have also been altered to indicate tapes
actually copied, up to the dashed lines; everything below them is still
prospective and subject to change.
Also, the old to new tape ratio is proving to be more like 4:1 than
5:1. This varies depending on file size; also, some tapes are not full,
and thus throw off this standard ratio.
Also, all tapes marked ! are part of the time compromise. All such
tapes are figured for a 4:1 compression ratio, although some will fit 5:1.
AI-KA10 tapes
input dump # output
date tapes #s # tapes type tapes
Apr 71 1000-1003 4 first arch 1 ; may have been missing
; last tape
Apr 72 1037-1044 8 arch 2
Mar 73 1062-1070 9 arch 2
Dec 73 1087-1094 8 arch 2
Dec 74 1108-1120 13 arch 3
Dec 75 1172-1188 17 arch 4
Dec 76 1210-1235 26 arch 6
Dec 77 1266-1300 34 arch 7 ; there is no tape 1280
!Aug 79 2459-2492 34 full 8
!May/Jun 81
2804-2846 43 full 9
Aug 82 3046-3085 40 last full 9
---------------------------------------- total 53 tapes actually made
Dec 78 1336-1366 31 arch
*Jan 79 2320-2349 30 full 7
Dec 79 1409-1448 40 arch
*Feb-Mar 80
2558-2595 38 full 8
Nov 80-Jan 81 ; incomplete dump
2767-2803 38 full 8
; perhaps move back to summer/fall '80 dump
GFRs: 1264, 1265, 1301, 1334, 1335, 1367, 1407, 140, GFR1-GFR11, GFR13-GFR27
GFR30-GFR32
yearly full or archive dumps 269 input tapes 58 output tapes
first and last fulls 57 12
GFR tapes 36 8
--- --
total 362 78
ML-KA10 tapes
input dump # output
date tapes #s # tapes type tapes
Jun 73 1032-1036 5 arch 1
Jun 74 1050-1055 6 arch 2
Jul 75 1074-1079 6 arch 2
Apr 76 585-593 8 full 2
Apr 77 678-688 11 full 3
!Jan 79 851-865 15 full 4
!May 80 2040-2053 14 full 4
!Jan 82 2202-2217 16 full 4
Sep 83 2435-2450 16 last full 4
---------------------------------------- total 26 tapes actually made
Apr 78 770-781 12 full 3
Apr 79 894-907 16 full 4
Apr 80 2025-2039 15 full 4
Apr 81 2131-2144 14 full 4
Apr 82 2231-2246 16 full 4
Mar 83 2385-2402 18 full 5
GFRs: 154, 163, 165, 167-169, 171, 174-177, GFR180-190, GFR192-199,
GFR1-13, GFR15-29
yearly full or archive dumps 129 input tapes 28 output tapes
last full 16 4
GFR tapes 58 12
--- --
total 203 44
MC-KL10 tapes
input dump # output
date tapes #s # tapes type tapes
Jan 76 500-510 11 full 3
Dec 76 603-618 16 full 4
Dec 77 1029-1048 20 arch 4
!Jun 79 2013-2029 17 full 5
!Oct-Dec 80
2405-2447 43 full 10
Aug 82 2870-2927 58 full 13
; Last Whole Macsyma Dump
---------------------------------------- total 39 tapes actually made
!Jul 84 3367-3421 55 full 14
----------------------------------------
Dec 78 1067-1084 18 arch 4
*Jan 79 944-961 18 full 4
Dec 79 1085-1114 30 arch 6
*Jan 80 2131-2159 29 full 6
Oct 80 2405-2447 43 full 9
*Mar 81 2448-2490 43 full 9
Nov 81 2662-2706 45 full 9
*Jan-Feb 82
1153-1204 52 last arch 11
Aug 83 3144-3196 53 full 11
*Nov 83 3197-3259 63 full 13
Aug 85 3821-3874 54 full 11
*Oct 85 3875-3927 53 full 11
[Oct 86 4100-4122, last full dump, was run at 9-track, 1600 bpi, so does
not need to be copied, merely saved.]
GFRs: 175-199, GFR1-68, GFR70-88
yearly full or archive dumps 411 input tapes 85 output tapes
first and last archives 64 14
GFR tapes 102 26
--- --
total 577 125
GFR tape schedule
AI
1264 -- 22aug77 GFR6 -- 29oct80 GFR19 --
1265 -- 16nov77 GFR7 -- 3nov80 GFR20 --
1301 -- 2apr78 GFR8 -- 26nov80 GFR21 --
1334 -- 8aug78 GFR9 -- 12dec80 GFR22 -- 13feb82
1335 -- 24nov78 GFR10 -- 28jan81 GFR23 --
1367 -- 14feb79 GFR11 -- 24may81 GFR24 --
1407 -- 12oct79 GFR13 -- 25aug81 GFR25 --
140 -- 3dec79 ? GFR14 -- 4oct81 GFR26 --
GFR1 -- 15jul80 GFR15 -- 18oct81 GFR27 -- 28jan83
GFR2 -- 26aug80 GFR16 -- 15nov81 GFR30 -- 28jan83
GFR3 -- 26aug80 GFR17 -- 6jan82 GFR31 -- 28jan83
GFR4 -- 26sep80 GFR18 -- 6jan82 GFR32 -- 28jan83
GFR5 -- 13oct80
ML
154 -- 23dec73 GFR189 -- GFR10 --
163 -- 28oct74 GFR190 -- GFR11 --
165 -- 21dec74 GFR192 -- GFR12 --
167 -- 13mar75 GFR193 -- GFR13 --
168 -- 24jun75 GFR194 -- GFR15 --
169 -- 25sep75 GFR195 -- GFR16 --
171 -- 13oct75 GFR196 -- GFR17 --
174 -- 2jun76 GFR197 -- GFR18 --
175 -- 20jul76 GFR198 -- GFR19 --
176 -- 15aug76 GFR199 -- GFR20 --
177 -- 30aug75 GFR1 -- GFR21 --
GFR180 -- GFR2 -- GFR22 --
GFR181 -- GFR3 -- GFR23 --
GFR182 -- GFR4 -- GFR24 --
GFR183 -- GFR5 -- GFR25 --
GFR184 -- GFR6 -- GFR26 --
GFR185 -- GFR7 -- GFR27 --
GFR186 -- GFR8 -- GFR28 --
GFR187 -- GFR9 -- GFR29 --
GFR188 --
MC
175 -- 23may77 GFR14 -- 18mar80 GFR51 -- 17mar83
176 -- 7sep77 GFR15 -- 2apr80 GFR52 -- 2may83
177 -- 28oct77 GFR16 -- 20apr80 GFR53 -- 24jun83
178 -- 27nov77 GFR17 -- 2may80 GFR54 -- 28jul83
179 -- 25jan78 GFR18 -- 14may80 GFR55 -- 18aug83
180 -- 14mar78 GFR19 -- 22may80 GFR56 -- 18nov83
181 -- 6apr78 GFR20 -- 23oct80 GFR57 -- 28dec83
182 -- 11may78 GFR21 -- 6nov80 GFR58 -- 11feb84
183 -- 8jun78 GFR22 -- 11dec80 GFR59 --
184 -- 11jul78 GFR23 -- 1jun81 GFR60 --
185 -- 20jul78 GFR24 -- 29jan81 GFR61 --
186 -- 17aug78 GFR25 -- 12feb81 GFR62 -- 11mar84
187 -- 8sep78 GFR26 -- 12mar81 GFR63 -- apr84
188 -- 18sep78 GFR27 -- 31mar81 GFR64 -- may84
189 -- 25sep78 GFR28 -- 9may81 GFR65 -- 28may84
190 -- 16oct78 GFR29 -- 2jun81 GFR66 --
191 -- 28oct78 GFR30 -- 15jun81 GFR67 --
192 -- 11nov78 GFR31 -- 17jul81 GFR68 --
193 -- 27nov78 GFR32 -- 3aug81 GFR70 --
194 -- 9dec78 GFR33 -- 13aug81 GFR71 --
195 -- 20dec78 GFR34 -- 21aug81 GFR72 --
196 -- 5jan79 GFR35 -- 3sep81 GFR73 --
197 -- 31jan79 GFR36 -- 3oct81 GFR74 --
198 -- 18feb79 GFR37 -- 18oct81 GFR75 --
199 -- 23mar79 GFR38 -- 11mar82 GFR76 --
GFR1 -- 10apr79 GFR39 -- 3apr82 GFR77 --
GFR2 -- 26apr79 GFR40 -- 15may82 GFR78 --
GFR3 -- 4may79 GFR41 -- 19may82 GFR79 --
GFR4 -- 7jun79 GFR42 -- 9jul82 GFR80 --
GFR5 -- 2jul79 GFR43 -- 3aug82 GFR81 --
GFR6 -- 21jul79 GFR44 -- 8sep82 GFR82 --
GFR7 -- 31jul79 GFR45 -- 5oct82 GFR83 --
GFR8 -- 11aug79 GFR46 -- 30oct82 GFR84 --
GFR9 -- 23aug79 GFR47 -- 15dec82 GFR85 --
GFR10 -- 10sep79 GFR48 -- 23dec82 GFR86 --
GFR11 -- 18jan80 GFR49 -- 3jun83 GFR87 --
GFR12 -- 10feb80 GFR50 -- 6feb83 GFR88 --
GFR13 -- 22feb80