Wanted: SIMH VMS quick test

On 12/16/2014 10:39 AM, Chuck Guzis wrote: 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