Wanted: SIMH VAX VMS tape image tester, take 2

[Chuck Guzis]

On 12/20/2014 01:33 PM, Fred Cisin wrote:
> There is always an off chance that some of the software that uses those
> files may expect a fixed length, and will freak out if the length isn't
> what it had expected.

The SIMH format provides for an EOM record, so things are pretty safe in 
the respect of trying to read past EOM (end of media).  That's the great 
thing about tape--you have so many feet of tape (imprecisely specified) 
and that's it.  You can't write on air, nor read it.

> Therefore, there is some risk involved in appending anything
> to the file(s).

So not much of a difficulty with that.

> Could you create a separate file that is associated with each file?
> filename.DAT  and filename.INF
> That way, the .DAT file can be an "UNCORRUPTED" exact image of the
> original data.
> filename.INF could be a simple text description, maybe even in complete
> sentences, containing whatever is known about the file, such as record
> structure(s), etc.  (and editable if/when more is learned!)
> If there is an expectation of an extreme quantity of data files,
> then the .INF file should have a fixed machine parseable format,
> followed by a freeform text component at its end.

Of course, there's an issue there.  What's a file?  If there's only one 
lump of information, you know.  But if there are several, then you get 
into the issue of file names, record formats, etc.

For example, how do you represent a Mac resource fork on DOS?

What I'm trying to do is to think not only 40+ years back, but 40+ years 
ahead.  I know that that's a tall order, but you can't blame one for 
trying...

Personally, I've found it surprising with what knowledge gets lost in 20 
years...

--Chuck