Wanted: SIMH VMS quick test

[Chuck Guzis]

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:
:IMAGE DATE:
:LABEL DESCRIPTION:
:DENSITY:
:TRACKS:
:READ DEVICE:
:SYSTEM:

...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?

--Chuck