23 Jun
2020
23 Jun
'20
6:57 p.m.
I've been processing some PDP-11 9 track (800 NRZI) tapes and run across
something that I don't recognize.
Every file on the tape consists of a number of 512 byte blocks (okay,
that's normal) but at the head of each file, there's a short block of 14
bytes.
Usually, a short record like this is discarded as "noise" on many
mainframe tape systems, but here it's consistently present. Here's what
one of the records looks like:
15 34 fe 51 fe 76 01 01 00 00 01 80 10 00
Doesn't seem like a file name in RAD50 format, so I'm puzzled.
Inquiring minds want to know...
Thanks,
Chuck
23 Jun
23 Jun
7:09 p.m.
We had a 12.5 IPS drive on a Microdata 1600.? Once you gave the "go"
command to the controller, you could actually drive it with byte / byte
programmed I/O.? We had to enforce the blocksize on tapes which went
anywhere else.? But we could write from one byte to an entire tape as a
single record.? The latter would (at the time we first did it) crash the
campus 360/50 by the way.
But we enforced 14 bytes as the minimum.
We had a fellow who did his masters project implement a formal library
to write 100% compatible tapes with different organizations, and all
labels, etc.? I don't recall any record shorter than 14 bytes if any
there either.? Of course labels were 80 bytes.
Main comment here is 14 bytes seems okay.
Thanks
Jim
Short story of crashing the 360 MVT system.? We had IBM reels we reused
which IBM used for patches called DTRs.? they had 50 or 100' max length
tape.? We had a guy muck up a program to send a file off our system to
the mainframe, and he forgot to break up the file into records.? So he
ended up with an entire tape with one big physical record.
what happened was our code didn't? properly terminate, so when the IBM
job was run with the tape as input it read the entire tape and got a
tape error.? then printed a spew on the console.? repeat 10 times.
Problem, tape drive and console was on the same channel.? With normal
size records even up to 64k long the tape didn't busy the channel up for
very long.
Second part of problem, if you busy out the channel to the console(s) on
MVT when the buffers fill, the system crashes.? So with the tape
retrying and spewing messages along with other crap onto the console
from other operations, cratered the system in about 30
seconds.
Console by the way was a KSR 1052, similar to the 2741 Selectric
terminals, but faster.
On 6/23/2020 6:57 PM, Chuck Guzis via cctalk wrote:
I've been processing some PDP-11 9 track (800
NRZI) tapes and run across
something that I don't recognize.
Every file on the tape consists of a number of 512 byte blocks (okay,
that's normal) but at the head of each file, there's a short block of 14
bytes.
Usually, a short record like this is discarded as "noise" on many
mainframe tape systems, but here it's consistently present. Here's what
one of the records looks like:
15 34 fe 51 fe 76 01 01 00 00 01 80 10 00
Doesn't seem like a file name in RAD50 format, so I'm puzzled.
Inquiring minds want to know...
Thanks,
Chuck
24 Jun
24 Jun
1:23 p.m.
On 06/23/2020 09:09 PM, jim stephens via cctalk wrote:
Short story of crashing the 360 MVT system. We had IBM
reels we reused which IBM used for patches called DTRs.
they had 50 or 100' max length tape. We had a guy muck up
a program to send a file off our system to the mainframe,
and he forgot to break up the file into records. So he
ended up with an entire tape with one big physical record.
what happened was our code didn't properly terminate, so
when the IBM job was run with the tape as input it read
the entire tape and got a tape error. then printed a spew
on the console. repeat 10 times.
Problem, tape drive and console was on the same channel.
With normal size records even up to 64k long the tape
didn't busy the channel up for very long.
The 1052 Selectric console on the 360's were not on a
channel, but driven via direct I/O directly from the CPU
microcode. (Yes, the console has a pseudo channel address
that made you THINK it was on a channel, but it actually
wasn't.)
I'm kind of surprised, as the tape controller had a record
length count, and should just terminate with an error if the
record was longer than the count specified. You HAD to do
that, as otherwise you could overrun the user's buffer and
write tape data onto system control blocks or even another
user's partition.
Exactly how the tape controller handled these insanely long
records, however, is another matter, and I can imagine the
controller might try to reach the end of the record before
turning around to backspace over it so it didn't run over to
another record. And, that could tie up the channel for a
minute or more.
Sharing devices, control units and channels on the 360 was
NOT a really well thought-out mechanism.
Searching a data set of several cylinders for a specific key
on a 2314 drive could bring the whole system to a halt for
many seconds.
Jon
2:12 p.m.
On 6/24/20 1:23 PM, Jon Elson via cctalk wrote:
The 1052 Selectric console on the 360's were not
on a channel, but
driven via direct I/O directly from the CPU microcode.? (Yes, the
console has a pseudo channel address that made you THINK it was on a
channel, but it actually wasn't.)
One prank to pull on an operator was to write a CCW chain to ring the
1052 bell and then to a TIC back to the bell ring CCW.
At least on DOS/360, pretty much impossible to kill without doing an
IPL, as the keyboard would be locked.
Fun from my younger days.
--Chuck
2:19 p.m.
Sometimes I had only lunch hour to do PMs, and one office worker always
ate into my time because she had to 'finish something'.
Pretty soon I found that <esc> [ 2 ; 9 y would put all ANSI terminals
into continuous self-test, and that solved the problem:-)
Those were the days!
cheers,
Nigel
On 24/06/2020 17:12, Chuck Guzis via cctalk wrote:
On 6/24/20 1:23 PM, Jon Elson via cctalk wrote:
--
Nigel Johnson, Sc., MIEEE, VE3ID/G4AJQ/VA3MCU
Amateur Radio, the origin of the open-source concept!
Skype: TILBURY2591 nw.johnson at ieee.org
The 1052 Selectric console on the 360's were
not on a channel, but
driven via direct I/O directly from the CPU microcode.? (Yes, the
console has a pseudo channel address that made you THINK it was on a
channel, but it actually wasn't.)
One prank to pull on an operator was to
write a CCW chain to ring the
1052 bell and then to a TIC back to the bell ring CCW.
At least on DOS/360, pretty much impossible to kill without doing an
IPL, as the keyboard would be locked.
Fun from my younger days.
--Chuck
3:37 p.m.
On 06/24/2020 04:12 PM, Chuck Guzis via cctalk wrote:
On 6/24/20 1:23 PM, Jon Elson via cctalk wrote:
Yup, the only way to stop that would be to do a halt IO
instruction or press system reset.
Jon
The 1052 Selectric console on the 360's were
not on a channel, but
driven via direct I/O directly from the CPU microcode. (Yes, the
console has a pseudo channel address that made you THINK it was on a
channel, but it actually wasn't.)
One prank to pull on an operator was to
write a CCW chain to ring the
1052 bell and then to a TIC back to the bell ring CCW.
At least on DOS/360, pretty much impossible to kill without doing an
IPL, as the keyboard would be locked.
4:26 p.m.
On 6/24/2020 2:12 PM, Chuck Guzis via cctalk wrote:
On 6/24/20 1:23 PM, Jon Elson via cctalk wrote:
One of my buddies had a football game, sort of like the logic of basic
games that came along, but was written in Cobol.? was about 3 or 4
inches of cards and a nice game.
The thing was written to use WTO and WTOR which isn't that big a deal in
a lot of shops.
However when you've got a lot of jobs running and need the console,
having to play a game of football to get back access to the console
wasn't amusing.? We (students, users) all looked at each other, and
figured they'd have a way around that, wouldn't they, and he ran it.
Also regardless the retries and the tape channel were intertwined and
when the tape was retrying the console I/O was locked up. Channel attach
or not.
The other useless bit (going way off the subject of tape) the system
used HASP for a lot of the job scheduling on the site with a lot of mods
to HASP and the system initiator code.
Relative to the cobol football game, i discovered from reading the
initiator code that one could issue console commands from any reader
attached to an initiator by putting a / in front of the command and
having it be valid.? I was nice and told the operators and the system
programmer guys it was active.? I got to do a couple of simple display
commands and kept it to myself while they fixed the initiators to not
accept commands.
The bad news was that was a couple weeks before my other friend decided
to run football.
thanks
Jim
The 1052 Selectric console on the 360's were
not on a channel, but
driven via direct I/O directly from the CPU microcode.? (Yes, the
console has a pseudo channel address that made you THINK it was on a
channel, but it actually wasn't.)
One prank to pull on an operator was to
write a CCW chain to ring the
1052 bell and then to a TIC back to the bell ring CCW.
At least on DOS/360, pretty much impossible to kill without doing an
IPL, as the keyboard would be locked.
Fun from my younger days.
--Chuck
23 Jun
23 Jun
8:18 p.m.
On Jun 23, 2020, at 9:57 PM, Chuck Guzis via cctalk <cctalk at classiccmp.org>
wrote:
I've been processing some PDP-11 9 track (800 NRZI) tapes and run across
something that I don't recognize.
Every file on the tape consists of a number of 512 byte blocks (okay,
that's normal) but at the head of each file, there's a short block of 14
bytes.
Usually, a short record like this is discarded as "noise" on many
mainframe tape systems, but here it's consistently present. Here's what
one of the records looks like:
15 34 fe 51 fe 76 01 01 00 00 01 80 10 00
Doesn't seem like a file name in RAD50 format, so I'm puzzled.
Inquiring minds want to know...
Thanks,
Chuck
Looks like a standard DOS/BATCH-11 tape file header. The first 6 bytes and the last 2
bytes are the file name in rad50 - ?HMMMD0P.SAV?.
Depending on where/when it was written the header can be either 12 or 14 bytes:
Format of DOS-11 magnetic tape header records:
.rad50 /fn1fn2/ ;1st 6 letters of filename
.rad50 /ext/ ;3-letter extension
.byte proj,prog ;ppn (display it in octal)
.word prot ;protection code, usually <233> octal
.word date ;date: (year-1970.)*1000.+(day within year)
.rad50 /fn3/ ;[optional] letters 7::9 of filename
Length=14. bytes (or 12. if no fn3, like in actual DOS/BATCH)
John.
10:50 p.m.
On 6/23/20 8:18 PM, John Forecast wrote:
Looks like a standard DOS/BATCH-11 tape file header.
The first 6 bytes and the last 2 bytes are the file name in rad50 - ?HMMMD0P.SAV?.
Depending on where/when it was written the header can be either 12 or 14 bytes:
Format of DOS-11 magnetic tape header records:
.rad50 /fn1fn2/ ;1st 6 letters of filename
.rad50 /ext/ ;3-letter extension
.byte proj,prog ;ppn (display it in octal)
.word prot ;protection code, usually <233> octal
.word date ;date: (year-1970.)*1000.+(day within year)
.rad50 /fn3/ ;[optional] letters 7::9 of filename
Length=14. bytes (or 12. if no fn3, like in actual DOS/BATCH)
Thanks for straightening that out--all I know is that the tapes are from
an 11/70, which isn't much information, admittedly.
--Chuck
24 Jun
24 Jun
4:47 a.m.
At 12:50 AM 6/24/2020, Chuck Guzis via cctalk wrote:
Thanks for straightening that out--all I know is that
the tapes are from
an 11/70, which isn't much information, admittedly.
A few months ago, I was re-rescuing some files that a friend had
once read from a RSTS tape. He gave two sets of files.
I'm not sure what tool or system he was using, but it
probably was newer than the RSTS.
One grabbed the files with the 14 bytes prepended to every file
but without correct filenames, the other rescued the files
with the filenames but without the correct dates.
Once I figured out the nameless files had the 14 byte DOS-11
tape header, I wrote a little C tool that gave the files their
proper filename and date. You're welcome to it. For Windows
at least and probably Unix.
My deeper goal was to rescue the files well enough to
get them running again under SIMH and/or one of the
JavaScript-based in-browser emulators. The programs wanted
the FORTRAN compiler environment and BASIC-PLUS, and
finding all those installers of the right version and combination,
learning how to get it all right... whew, I wasn't sysop-level
back then, and so much time has passed, it's quite a puzzle.
- John
6:27 a.m.
On Jun 23, 2020, at 9:57 PM, Chuck Guzis via cctalk
<cctalk at classiccmp.org> wrote:
I've been processing some PDP-11 9 track (800 NRZI) tapes and run across
something that I don't recognize.
Every file on the tape consists of a number of 512 byte blocks (okay,
that's normal) but at the head of each file, there's a short block of 14
bytes.
Usually, a short record like this is discarded as "noise" on many
mainframe tape systems, but here it's consistently present. Here's what
one of the records looks like:
15 34 fe 51 fe 76 01 01 00 00 01 80 10 00
Doesn't seem like a file name in RAD50 format, so I'm puzzled.
Inquiring minds want to know...
Thanks,
Chuck
As others have answered, that's a DOS file label, used in PDP-11 magtapes since the
beginning. Most PDP-11 operating systems also support ANSI labels, but DOS labels are the
most common on RSTS (except for V9 and later backup tapes which are always ANSI).
Bootable tapes are DOS labeled.
I remember that OS/360 documentation stated < 18 bytes would be treated as noise but
that's not precisely true. The accurate description is that a record encountering a
read error but < 18 bytes long would be silently discarded as noise rather than being
reported as a real block with a read error. But error free 14 byte blocks can be read
just fine. I wrote an OS/360 utility (now long lost unfortunately) that would read DOS-11
format tapes so we could print large files (our RSTS/E system didn't have a line
printer but the 360/44 did). No problem there. It used EXCP to allow reading across tape
marks, and possibly that made handling the 14 byte records easier but I don't remember
that it was required for that purpose.
paul
1420
days inactive
1420
days old
10 comments
7 participants
participants (7)
-
cclist＠sydex.com -
elson＠pico-systems.com -
jfoust＠threedee.com -
john＠forecast.name -
jwsmail＠jwsss.com -
nw.johnson＠ieee.org -
paulkoning＠comcast.net