Wanted: SIMH VMS quick test
cclist at sydex.com
Tue Dec 16 13:28:09 CST 2014
On 12/16/2014 10:39 AM, Chuck Guzis wrote:
> On 12/16/2014 09:58 AM, Al Kossow wrote:
>> John Bordynuik defined bad block information in the tape images he
>> created. Too bad it was never documented.
> I'd probably add a field to the header for each record for a CRC for the
> record data. Should a file become corrupted, I'd think that people
> would want to know.
The optional 1-byte padding, as I understand things, is not included in
the data record byte count. So it's pretty easy to determine if the
record format is padded or not, since you've still got an odd byte
count--you need only look at the trailing information--either the
trailing byte count field will be offset by one byte or it won't.
But, in general, I agree with the padding issue--there isn't any good
reason to pad a record, but for being SIMH compatible.
I'll flesh out the diagnostic error stuff a bit more. Another thing that
doesn't appear to be in the SIMH spec is whether or not the EOT marker
occurred during the writing of the last record. That might be useful to
some. Indeed, many systems will allow writing of an extra record or two
beyond the EOT marker and EOM. Additionally there's no way to indicate
the presence of extra BOT markers on a tape. (One technique used in the
old manual-load drives was to record a set, then, manually add a BOT
strip for another data set. One could space forward to the subsequent
BOTs simply by hitting the "LOAD" button on the drive.) Very handy for
keeping several deadstart systems on a single tape; but that's probably
considered to be an aberration these days.
So after the FFFFFFFF EOM record, I propose placing an extra record
whose content is entirely ASCII. The first 8 characters will be
"TAPEINFO". Lines terminated by an LF. If a line starts with a colon,
it signifies a keyword field, which is terminated by a colon, followed
by the value of that field, which may extend for as many lines as
needed, provided that none begins with with a colon.
Some possible keywords might be, but are not restricted to:
:IMAGE CREATED BY:
...and so forth...
The record itself will be in SIMH format--i.e, with 32-bit header and
trailer record length.
That should retain SIMH compatibility.
What do ye think?
More information about the cctalk