Path: utzoo!attcan!uunet!decwrl!ucbvax!VM.UOGUELPH.CA!SOFPJF
From: SOFPJF@VM.UOGUELPH.CA (Peter Jaspers-Fayer)
Newsgroups: comp.sys.sgi
Subject: ansitape and VMS
Message-ID: <9010020905.aa10735@VGR.BRL.MIL>
Date: 2 Oct 90 13:48:19 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 28

My opinion only:
SGI really should look into providing a tool for (at least) reading VMS
tapes.  This could allow SGI to sell more irises to DEC shops. (Besides,
I keep getting bugged by people who want their FORTRAN source moved to
our new 380 ;-)

Solutions:
`vmsbakup` (usually distributed as read_vmsbackup.tar.Z) is old, and
buggy (it "snarks" on many block types), and unsupported.  It can be
picked up from various sites (uunet, for instance).

   SGI already supplies `ansitape`. ansitape does the file I/O ok, but
most VMS tapes are in VMS BACKUP format (their answer to tar). VMS BACKUP
save-sets are just files-11 files.  This means that all we REALLY need is
a method to read/write savesets on disk.  This should simplify the
program a lot.  It should be usable as a filter, thus

read:  ansitape -read_options | vmsbackup -extract_options
write: vmsbackup -gather_options | ansitape -write_options

This could also get around media incompatabilities, if you move the VMS
saveset (disk) to/from an iris via FTP (or even kermit!).

Does anyone else think this is reasonable?  Has anyone done it?

/PJ                                                SofPJF@VM.UoGuelph.Ca
(Probably also reachable (until ?) at             SOFPJF@UOGUELPH.BITNET)
It is impossible to make anything foolproof because fools are so ingenious.