19 Oct
2006
19 Oct
'06
12:58 p.m.
Hi all,
I must be missing something, but I have not found a good way to
preserve a bunch of vax/vms files. I've looked at VMSZip, Gzip, VMSTar,
etc, and I must be missing something.
Here is what I am trying to do:
Before my vax finally dies, I want to take the hundred or so TK50s I
have and restore them to the hard drive and then move them to PC-land
for long term storage. This is halfway done with the tapes that are
easily readable. I now have a bunch of directories, one for each tape,
with files in them on the VAX. So the tree is only two levels deep on
the vax. The files are pretty mixed: backup files, savesets,
distributions, text files, etc. Right now the files amount to about 2Gb.
Now, the environment is: VAX 3100-30 with SCSI external. THis is where
I hooked up the TK70 (TZ30?) to read the tapes. I have network access
and can get to it via FTP and TELNET from elsewhere, namely my PC. I
also have a bunch of different SCSI tape drives, 8mm, 4mm, 9 track, etc.
So, I could transfer all the files if I could containerize (zip) them.
Do I try to Zip them somehow (what program) and FTP them, or do I just
write them to duplicate disks/tapes and throw them on a shelf, hoping I
have a machine to read them in the future?
I'm usually pretty good with this stuff, having been around the VMS
world for a few decades, but I just have this memory block, or the
blinders are on.
Any suggestions?
Thanks
Joe Heck
19 Oct
19 Oct
1:19 p.m.
Joe,
At 3:58 PM -0400 10/19/06, Joe Heck wrote:
Hi all,
I must be missing something, but I have not found a good way to
preserve a bunch of vax/vms files. I've looked at VMSZip, Gzip, VMSTar,
etc, and I must be missing something.
Do you need to preserve them as individual files or would tape images
suffice? If tape images are OK, use an appropriate program to create
.tap files from the tapes themselves. This allows easy (later)
recreation of the tapes as well as use within the various simulators.
If on the other hand the files are more important (than being able to
recreate the tape exactly), unloading into separate directories is
fine. Then create a backup image of the whole directory structure
and archive the saveset. If space is an issue, gzip the saveset.
Just how I would likely approach it.
Good luck,
John
2:13 p.m.
In article <a06230902c15d8d43781e(a)[131.215.234.40]>0]>,
"John A. Dundas III" <dundas at caltech.edu> writes:
If on the other hand the files are more important
(than being able to
recreate the tape exactly), [...]
What would require an exact tape image, as opposed to files and their
contents?
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>
2:23 p.m.
On Thursday 19 October 2006 17:13, Richard wrote:
In article
<a06230902c15d8d43781e(a)[131.215.234.40]>0]>,
"John A. Dundas III" <dundas at caltech.edu> writes:
Booting an OS tape is one instance.... There are plenty more, for
example when the block (record) size of the tape is significant for
delimiting different parts of data.
Pat
--
Purdue University Research Computing --- http://www.rcac.purdue.edu/
The Computer Refuge --- http://computer-refuge.org
If on the other hand the files are more important
(than being able
to recreate the tape exactly), [...]
What would require an exact tape image, as opposed to files and their
contents?
3:19 p.m.
At 3:13 PM -0600 10/19/06, Richard wrote:
In article
<a06230902c15d8d43781e(a)[131.215.234.40]>0]>,
"John A. Dundas III" <dundas at caltech.edu> writes:
Tapes where retention of attributes, block sizes, placement, etc.,
are just as important as (maybe more so than) the file contents. Two
things come to mind:
1) a simulator (SIMH, Charon, etc.) where you wanted to work with a
(virtual) tape device. Pat mentioned booting an OS tape; absolutely.
2) the ability to recreate the tape (either on the same media, TK50 I
think was this case, or other media 9-track, TK70, etc.).
If I copy files from tape to disk, I lose all blocking information
(there might be different block sizes on the tape for different
files). I won't be able to recreate the tape from the files
themselves without additional meta information. Boot tapes often
(sometimes?) contain boot data/code outside of recognizable file
headers or marks on the tape. I believe the early PDP-11 tapes were
this way. I can tell you that later PDP-11 (RSTS) tapes are
multi-format, i.e., the first few (maybe dozen) files are DOS-11
format, including the boot file, then the rest of the tape is written
in ANSI format. IIRC, DEC's Unix-11 V7m contained boot information
at the front of the tape, then several tar images separated by tape
marks on the remainder. A tape image is able to capture this sort of
information in addition to the file data itself.
John
If on the other hand the files are more
important (than being able to
recreate the tape exactly), [...]
What would require an exact tape image, as opposed to files and their
contents? 
1:50 p.m.
Joe Heck wrote:
Do I try to Zip them somehow (what program) and FTP
them, or do I just
write them to duplicate disks/tapes and throw them on a shelf, hoping
I have a machine to read them in the future?
I'm usually pretty good with this stuff, having been around the VMS
world for a few decades, but I just have this memory block, or the
blinders are on.
The way to save OpenVMS data and guarantee being able to restore it
in the future (assuming access to OpenVMS ... ) is as a backup
saveset.
So if your tapes are OpenVMS software distributions then copy the
savesets from each tape into a directory per tape (with an appropriate
directory name and maybe a README.TXT describing the tape, part number
etc.).
If the data is stuff you have created yourself then I would get it
into BACKUP format. That way all the attributes are sure to be
preserved.
If it is a bootable tape then you can certainly copy off the savesets
but you will lose the ability to boot the recreated tape. So here you
need a tape imaging program.
Now you have a set of raw data to play with. I would now use LDDRIVER
to create a 650(ish)MB LD disk and then copy the data onto that.
Dismount the disk, FTP the container file (in binary mode) to somewhere
with a CD writer and burn to CD in "image" format. I've done this with
Nero before now, but I don't remember the exact details. The way you
know
you have it right is to take the CD and mount it on any OpenVMS box.
Then run ANALYZE/DISK against it and also BACKUP/COMPARE against the
original.
The final result is an ISO9660 CD that VMS will be able to mount
natively
(with all protection attributes etc. preserved). Burn everything twice:
CDs are cheap and your time probably is not). If I were doing this now
I'd probably burn the images (as files) to DVDs ... less to store ...
and
only then burn individual CDs for the things I really wanted to access
under VMS right now.
Once you get into the swing of things, you'll find that the most time
consuming part is amassing the data ready to write. In which case you
might wish to unpack the BACKUP savesets, ZIP up the various trees
and FTP the zip files over to be burnt as ordinary ISO9660 files. This
is obviously only really applicable where the files make sense off-VMS.
Obviously the savesets that make up say OpenVMS V7.1 VAX are not going
to
be of much use anywhere other than on an OpenVMS box.
If you have data that makes sense both under VMS and elsewhere, you can
burn a hybrid ISO9660/ODS-2 CD where the data is stored once but
available
under both "personalities". This takes a little more effort and an
Alpha.
It really only makes sense for common-format binaries (e.g. PDF) and
text
(e.g. HTML). I did this a few years ago for some manuals and such that
I wanted to access both on an Alpha and a PC.
As you'll now have a bunch of disk images lying around on a PC, you
could fire up SIMH VAX (with VMS) and mount them to check them out
there too. This way you can get at your data even after you've forgotten
where your uVAX 3100 has been stored.
Antonio
6640
days inactive
6640
days old
5 comments
5 participants
participants (5)
-
arcarlini＠iee.org -
dundas＠caltech.edu -
legalize＠xmission.com -
pat＠computer-refuge.org -
trash3＠splab.cas.neu.edu