Hi, Louis.  Thanks for your note.

I have FrameMaker 5, but when I point it at these files, it tells me an
earlier version is needed to open them.  The header in the file (from
1989, for instance) says that the version is <MakerFile 1.03>.  I'm on
the track of a version of Maker 3.

> The side-topic question I have (given that we're in the middle of trying
> > find the best "passive" solution for long-term *reliable* storage of data)
> > is how were these files stored? Optical media? (If so, what flavor?)
> > Harddrives? Tape? (What flavor?)

Hard drives.  PARC has been big on network file systems since the 70's,
of course.  In the early 90's, we were experimenting with the idea of an
"eternal infinite" network file system.  As part of this, we invested in
some optical archive technology systems, and put a lot of stuff on them
which had previously been stored on tape and disk pack.  Those bits have
been brought forward systematically to successive generations of storage
technology.  (If you're curious, the future we're looking towards today
is content-centric networking ( -- data matters,
not where it lives.)

> > One possibility I recall. Frame binary files must end at a 1K boundary. When
> > they were sent via email, they often got a CR/LF added to the end, and then
> > Frame would no longer touch them. We wrote a little utility that trimmed off
> > anything after the last 1K boundary that fixed this. So if the file was 2050
> > bytes, it truncated it to 2048. If the exact byte sizes are not a multiple
> > of 1024, let me know and I'll see if I can find that utility someplace. Or
> > you could do it with a binary editor.

Ah, good tip.  I'll look into that.

> Last three quotes from:
> So while it may not relate to the original question of making older,
> archived files available in modern formats, I suppose we could definitively
> say that so long as the data isn't in a proprietary format, or if it is, so
> long as the software is still in production, you've a good chance at opening
> older data -- as long as it's not corrupt.

I still like the older PARC document formats, tedit and Tioga.  They
stored the plain text at the front of the file, a marker (typically a
run of two zero bytes), and then the binary markup directives, which
referenced byte positions in the plain text.  So, you could visit any
document as a plain-text file and get some sense of what was in it.