>>> Should it be kept in vacuum sealed bags or out of the light?
>>
>>*I'd* prefer to see - first - the information preserved, by copying
>>to new paper or mylar tape or some other long-lived medium. The
>>information is what counts, not any particular piece of paper that
>>it's recorded on.
>Tim, you have experience with archiving software.. I have 3 high speed paper
>tape readers, 10 RX02s, 8 dectape drives, and many other DEC TU/TE tape
>drives and Disk drives. What software do you use?? It's sounds like I might
>(and others) have to write some software(or use yours) to pool all the code
>coming in through the above devices to a large NT server.
There's no magic - you just have to have an extreme dedication to
storing the original information - in its entirety - in an archivable
form.
This means, usually, reducing every piece of input medium into a
"stream of bytes" file that will be portable through operating systems
(such as Unix) which don't have an innate concept of "records".
For 9-track and 7-track tapes, I prefer "TPC images", as made by
many of the TPC archiving programs available for DEC OS's. A TPC
image of a tape allows you to exactly reproduce the tape again later
from the image, including boot blocks and any variable-size data
records in the file. See
http://pdp-10.trailing-edge.com/ to see
how I applied this to the PDP-10 software archives, and for pointers
on the web to the many TPC tools available.
After you make a TPC file, it's important to preserve the record lengths
in the file before you transfer the file to a machine that doesn't
know about records. For this, my preferred method is ZIP "-V" on VMS,
where the "-V" qualifier makes sure that the file attributes and record
lengths are all stored in the Zip file. Then you can move the file to
Unix's and PC's which don't know anything about record lengths, because
the Zip file *is* a stream of bytes.
For block-oriented disk (and block-oriented tapes, like DECtape I and II)
devices, the preferred archival method is a block-by-block image of everything
on the original. This is easily done by, for example, COPY/DEV/FILE
DEV: FILE.NAM under RT-11, or by doing a MOUNT/FOR of the disk device
under VMS and then COPY DEV: FILE.NAM. Under recent versions of RSX-11M
you can use the VCP (Virtual configuration program) and the VD: drivers
to make block-by-block copies of disks into container files.
Whenever possible, do COPY/VERIFY operations followed by a DIFF/BIN
to make sure your copy is exactly the same as the original (and that it's
readable, too!)
>I'll be pulling out a bunch of 11/23 systems on my next trip with some
>11/34,35s. An idea I have is to line 8 or more systems up, fill them with
>every possible media drive, and 3 of the list members and myself could feed
>software to the devices as fast as quickly as the data could be read in. All
>information sent somehow to a central server with terminals to title the
>data dumped. Looks like "Digital Direct" can handle the microfiche scanning.
>I hope many of the systems could be networked together through DECNET. (My
>DECNET background was really strong at one point in time but when I saw DEC
>dumping I ran to NT like everyone else...)
DECNET is fine, if the machine's you're putting together support it nicely.
Don't discount the effort it takes to get a PDP-11 properly configured and
the peripherals running - sometimes I'm sure you'll get lucky and it'll
just work when you plug it in, but when stuff is coming in "unknown" or
"not used for many years" condition, it can take time to get everything
going happily.
Finally, it's really quite easy to get a PDP-11 running RT-11 hooked up
and running TCP/IP, so don't waste too much time dinking around with
DECNET.
>I really don't want this to turn out into a year long project..
Just for some perspective, I've been building the PDP-11 DECUS and freeware
archives for over a decade now. It's not that reading any particular medium is
slow (I can image several gigabytes of 9-tracks a day while doing other
"real" work), but tracking down the material, getting it into my hands
(even when I supply my Fedex account number to get it here at no cost
to the donator) and indexing and organizing the results is *not* a quick
process.
If you've any doubts about the mechanical condition of any of your drives,
by all means play it slow and don't risk one-of-a-kind media in a drive with
questionable heads. And for paper tapes, if you're concerned about
mechanical fragility of the tape, find yourself a gentle slow optical
reader (like the DEC PR/S01) and don't risk the tape to some insanely
high-speed reader (which *will* occasionally jam up and crinkle your tape,
even if you keep it properly adjusted.)
The name of the game is to preserve and archive for the next 100 years or
so, not to rush to get something that isn't as good as the original!
If you're going to be archiving DEC OS distributions, you might want
to ask me to get you a list of what I've got archived here already.
The archive here doesn't go back forever, but I have copies of most
versions from the early-mid-80's onward. (i.e. RSTS/E V7 and on, RT-11 V4
and forward with some earlier V3 And V2 distributions, RSX-11M 3.0 forward,
and RSX-11M+ V2.0 and forward, with many of the layered product kits
thrown in for good measure.)
--
Tim Shoppa Email: shoppa_at_trailing-edge.com
Trailing Edge Technology WWW: http://www.trailing-edge.com/
7328 Bradley Blvd Voice: 301-767-5917
Bethesda, MD, USA 20817 Fax: 301-767-5927
Received on Wed Dec 29 1999 - 20:04:24 GMT