9 Jan
2021
9 Jan
'21
4:20 p.m.
Folks,
I've now seen two Burroughs tapes where some of the expected file marks
between labels and file data were apparently missing.
I think a reasonable description of these is "Burroughs/Unisys B6x00
'Library/Maintenance' tapes with ANSI-69 labels"
Reading drive is a Cipher GCR Cachetape with SCSI interface
The one I read yesterday read in streaming mode and reported no read
errors. I tried re-reading it today, and it read in start-stop mode,
but still didn't have the missing file marks. (It also encountered a
few errors, and eventually ended up sticking to the head, this time.
Guess that bake cycle was a one-shot, which isn't a surprise.)
This tape is a "Burroughs Series 7 / 100% Tested / 3200 FCI" 1200 foot
reel written at 1600 BPI in 1986.
Here's the beginning of the tape:
file 1 record 1 size 80
00000000: e5 d6 d3 f1 f0 f3 f6 f1 f3 f0 40 d7 d9 d6 c7 d9 VOL1036130 PROGR
00000010: c1 d4 40 40 40 40 40 40 40 40 40 40 f6 f5 f3 f0 AM 6530
00000020: f3 f0 f5 f0 f3 40 40 40 40 40 40 40 40 40 40 40 30503
00000030: 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40
00000040: 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 f1 1
file 1 record 2 size 80
00000000: c8 c4 d9 f1 c6 c9 d3 c5 f0 f0 f0 40 40 40 40 40 HDR1FILE000
00000010: 40 40 40 40 40 d7 d9 d6 c7 d9 c1 f0 f0 f0 f1 f0 PROGRA00010
00000020: f0 f0 f1 f0 f0 f0 f1 f0 f0 40 f8 f6 f2 f0 f2 40 001000100 86202
00000030: f8 f6 f2 f3 f2 40 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 86232 0000000000
00000040: f0 f0 f0 40 c1 f9 40 40 40 40 40 40 40 40 40 40 000 A9
file 1 record 3 size 80
00000000: c8 c4 d9 f2 e4 f0 f1 f0 f2 f4 f0 f1 f0 f2 f4 f3 HDR2U01024010243
00000010: f0 f1 f0 f1 f0 f0 f0 f0 f3 f0 f0 f0 f0 f0 f0 f0 0101000030000000
00000020: f0 f0 f0 f0 f0 f6 f4 f0 f0 f1 f3 40 f0 f0 f6 f4 00000640013 0064
00000030: 40 40 f0 f6 40 40 40 40 40 40 40 40 40 40 40 40 06
00000040: 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40
file 1 record 4 size 2070
00000000: 40 00 00 00 00 01 00 00 00 00 00 00 12 03 03 04 ...............
...etc.
Is oddness with file marks something others have seen with Burroughs
tapes? Something the Cipher drive is known for? Moon phase? Incorrect
fifth digit of my SSN? I've not had this missing file mark problem with
tapes written on other vendors systems - Prime, IBM, DEC.
Cluebats appreciated.
De
9 Jan
9 Jan
5:51 p.m.
On 01/09/2021 03:20 PM, Dennis Boone via cctalk wrote:
Folks,
I've now seen two Burroughs tapes where some of the expected file marks
between labels and file data were apparently missing.
NRZI file marks are only a couple flux changes, drives that
have squelch logic to suppress unstable read amps could
easily miss them. PE file marks have preamble and postamble
clock data, and it should be quite hard for them to just
disappear.
Now, one little detail is not all formatters followed the
specs for interrecord gaps. The NRZI spec required insanely
huge gaps, likely designed for very early capstan and pinch
roller drives. The gaps were several times the size of
common data records. Many later formatters cheated on this
and used much smaller gaps. Some formatters might miss a
file mark due to incompatibility of the gaps. But, that
seems less
likely at 1600 BPI, I think the required gap was reduced in
the standard.
Your tape dump looks very much like a classic ANSI tape
label format, except for the missing file mark after the
HDR2 record. Are ALL those file marks after HDR2 missing,
or just some of them?
I can see it being quite reasonable for there to be no file
mark after HDR2, if you were going to write
your own format. That specific FM is just not actually
needed if you KNOW the first data record follows HDR2. So,
the format could be :
VOL1
HDR1
HDR2
data
data
FM
HDR1
HDR2
data
data
FM
etc.
I can't say I have actually encountered such a tape before,
but I wouldn't be surprised. But, of course,
that would not be fully ANSI compatible.
Jon
5:59 p.m.
Jon,
Thanks for your thoughts.
Your tape dump looks very much like a classic ANSI
tape label format,
except for the missing file mark after the HDR2 record. Are ALL
those file marks after HDR2 missing, or just some of them?
Right, and they're supposed to be ANSI69ish, though they are in EBCDIC.
No, not all of them are missing, not even if one "compresses" out some
of the "obvious" ones along the lines of your example.
I can see it being quite reasonable for there to be no
file mark
after HDR2, if you were going to write your own format. That
specific FM is just not actually needed if you KNOW the first data
record follows HDR2. So, the format could be :
Yes, you could. The Burroughs doc seems to say the FM is supposed to be
there between every group of labels and the preceding or following data,
though.
De
7:23 p.m.
On 01/09/2021 04:59 PM, Dennis Boone via cctalk wrote:
Jon,
Yes, you could. The Burroughs doc seems to say the FM is supposed to be
there between every group of labels and the preceding or following data,
though.
Well, then the only thing you can do is Magna-See or one of
the dry magnetic viewers.
Jon
11:18 p.m.
On 1/9/21 4:23 PM, Jon Elson via cctalk wrote:
On 01/09/2021 04:59 PM, Dennis Boone via cctalk
wrote:
I can't say that I've ever observed that, but then, I probably never
looked for it either. 80 bytes starting with HDRx, etc. is a pretty
good indicator of the nature of the block. I've seen lots of tapes with
81-character records, however. (Univac 36 bit systems for example).
--Chuck
Jon,
Yes, you could.? The Burroughs doc seems to say the FM is supposed to be
there between every group of labels and the preceding or following data,
though.
Well, then the only thing you can do is Magna-See or one of the dry
magnetic viewers.
10 Jan
10 Jan
12:06 a.m.
I can't say that I've ever observed that, but
then, I probably never
looked for it either. 80 bytes starting with HDRx, etc. is a pretty
good indicator of the nature of the block. I've seen lots of tapes
with 81-character records, however. (Univac 36 bit systems for
example).
Drat. I was hoping you'd have this answer. ;)
Looking for filemark-less transitions either way between 80-byte records
with known label names, and other kinds of records, is what my detector
script for this does.
De
1362
days inactive
1363
days old
5 comments
3 participants
participants (3)
-
cclist＠sydex.com -
drb＠msu.edu -
elson＠pico-systems.com