Wanted: SIMH VAX VMS tape image tester, take 2
cclist at sydex.com
Sat Dec 20 16:51:45 CST 2014
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
Personally, I've found it surprising with what knowledge gets lost in 20
More information about the cctech