Can someone explain to me how a tape drive works? :P
Daniel Seagraves
I just figured out I have no real idea how a tape drive (As in 9-track
tapes) work. I assumed it worked somewhat like a disk, but I guess not.
Like, what happens if you read just the first 512 bytes of a 10240 byte
tape block? Do you have to rewind and try again to get the rest, or does
it stop where you stop reading? What about writing in the middle of a
tape? I just know how disks work, I've never dealt with a tape other than
mounting them on the PDP11 and having a fit when they don't work. :P
"Confuse, annoy, and DEE-STROY!" -- Jet Wolf | "Nothing Happens." -- ADVENT
"You'd be surprised what you can live through..." -- Anonymous
"...A man can pass his family and his name down through his sons, but it's
his honour that gets passed through his daughters. He can see the best
and worst of life in his girls. A daughter is something far too precious,
and he'll do anything to protect her."
-- Reichsfuehrer Siegfried Koenig, _Matrose_Mond_, David Oliver
Sarr J. Blumson
Daniel Seagraves <ro...@bony.umtec.com> wrote:
>
>I just figured out I have no real idea how a tape drive (As in 9-track
>tapes) work. I assumed it worked somewhat like a disk, but I guess not.
>
>Like, what happens if you read just the first 512 bytes of a 10240 byte
>tape block? Do you have to rewind and try again to get the rest, or does
>it stop where you stop reading? What about writing in the middle of a
>tape? I just know how disks work, I've never dealt with a tape other than
>mounting them on the PDP11 and having a fit when they don't work. :P
Real tapes (DECtape is different):
The tape is written in physical blocks, of variable length, with a gap (1/4"
on reel tapes; less on some of the descendants, I think) in between. The
tape can stop only in that gap, which exists so the drive can stop and
restart and still be at reading speed by the time the next record starts.
So you _have_ to read the whole thing. And whatever you write becomes a
new physical record.
Writing in the middle _might_ work if you know that the tape is fixed sized
records and that's what you're writing, but it also might not since there's
a fair amount of physical slack. In general, you only write after any data
that you want to keep.
The drives can write and detect a funny short record that's otherwise illegal,
usually called an "end of file" mark.
Ask more questions.
--
--------
Sarr Blumson sa...@umich.edu
voice: +1 734 764 0253 home: +1 734 665 9591
ITD, University of Michigan http://www-personal.umich.edu/~sarr/
519 W William, Ann Arbor, MI 48103-4943
Tim Shoppa
>
> I just figured out I have no real idea how a tape drive (As in 9-track
> tapes) work. I assumed it worked somewhat like a disk, but I guess not.
>
> Like, what happens if you read just the first 512 bytes of a 10240 byte
> tape block?
Most (all?) DEC tape controllers will give you an error indication
if the tape block is longer than the number of characters (don't
forget 7-tracks!) than the read command
was issued for. The number of bytes that you wanted to read
are generally transferred succesfully into the specified buffer.
The exact details depend on the tape controller you're using and
how the OS/driver interprets the error/status bits.
Things don't get much more complicated on a PDP-10 if a
bit fiddler is packing/unpacking the 36-bit words into tape
characters on the fly. The requested number of words are transferred,
an error/status bit is set, and the drive stops in the next gap.
Things *do* get more complicated when doing a read reverse. Do the
PDP-10's tape formatter bit fiddlers even do read reverse, or do they
just back up and read forward?
> Do you have to rewind and try again to get the rest, or does
> it stop where you stop reading?
You have to backspace, read reverse, or rewind to try again,
because you stop after the block you tried to read.
All tape formatters I've ever met insist on stopping in the
inter-record gap.
Note that the TPC tape image format that I prefer isn't the
easiest to backspace or read reverse from in an emulator. John
Wilson's tape image format - where the record length is stored both
before and after the record - is much more convenient for an emulator.
I have several decades worth of tape analysis and conversion tools
that use the TPC format, that's why the images at
http://pdp-10.trailing-edge.com/
are in that format. (Call me an old fogey, but I have literally
hundreds of gigabytes of tape images in TPC format and I'm not going
to convert them all *and* my tools.) If you want to convert from TPC
format to John's format, Bob Supnik's emulator package comes with
"mtcvtv23" to do the conversion in that direction. It's just as easy to
write a little bit of code to go the other direction.
> What about writing in the middle of a
> tape?
If you start in a gap, not a problem.
If you want to learn the basics of tape manipulation at a low level
with DEC's tape controllers, I think the best way to start (because
that's how I learned it many years ago!) is the magtape .SPFUN section
in the RT-11 manuals. If you're more hardware-minded, starting with
the TM11 printset may be more comfortable for you.
Note that many OS's don't give you very direct access to all possible
tape functions. Lots of OS's don't allow you any way to issue a
read reverse, some will even be rude enough to put a tape offline if
you get a buffer overflow.
--
Tim Shoppa Email: sho...@trailing-edge.com
Trailing-Edge WWW: http://www.trailing-edge.com/
7328 Bradley Blvd Voice: 301-767-5917
Bethesda, MD, USA 20817 Fax: 301-767-5927
Johnny Billquist
>
> Daniel Seagraves wrote:
> >
> > I just figured out I have no real idea how a tape drive (As in 9-track
> > tapes) work. I assumed it worked somewhat like a disk, but I guess not.
> >
> > Like, what happens if you read just the first 512 bytes of a 10240 byte
> > tape block?
>
> Most (all?) DEC tape controllers will give you an error indication
> if the tape block is longer than the number of characters (don't
> forget 7-tracks!) than the read command
> was issued for. The number of bytes that you wanted to read
> are generally transferred succesfully into the specified buffer.
> The exact details depend on the tape controller you're using and
> how the OS/driver interprets the error/status bits.
The error indication is also usually something like
record truncated or so. Indicating that there was
more data in the record, but you didn't get it.
It's not neccesarily a fatal error. You decide. You might
be happy with the part you did get.
If the buffer is larger than the block read, you'll just
get back the actual size of the record. Next read will
always give you the next record.
> > What about writing in the middle of a
> > tape?
>
> If you start in a gap, not a problem.
And note that anything after your write can be connsidered gone.
(That is, physically after on the tape). You write tapes
sequentially, and where you wrote last is the logical end of tape.
It is permissible to read or skip data to some place on the
tape, and then start writing.
> Note that many OS's don't give you very direct access to all possible
> tape functions. Lots of OS's don't allow you any way to issue a
> read reverse, some will even be rude enough to put a tape offline if
> you get a buffer overflow.
That is rude.
Note also, that a zero length block is a tape mark. Two tape marks
usually indicate the logical end of tape. One tape mark is usually
used to indicate the end of a file.
Johnny
--
Johnny Billquist | johnny.b...@netinsight.net
Net Insight AB | phone: +46 8 685 04 88
Västberga Allé 9 | fax: +46 8 685 04 20
Box 42093 |
SE-126 30 STOCKHOLM, Sweden | http://www.netinsight.net
Daniel Seagraves
> Most (all?) DEC tape controllers will give you an error indication
> if the tape block is longer than the number of characters (don't
> forget 7-tracks!) than the read command
> was issued for. The number of bytes that you wanted to read
> are generally transferred succesfully into the specified buffer.
> The exact details depend on the tape controller you're using and
> how the OS/driver interprets the error/status bits.
OK, that makes sense. What about the other way - what if you want to read
1024 bytes and the record is 512 long? Does it just read the extra
blocks, or is there an error that way too?
> Things *do* get more complicated when doing a read reverse. Do the
> PDP-10's tape formatter bit fiddlers even do read reverse, or do they
> just back up and read forward?
I don't plan on implementing that. :P I'm just going to backspace and read
forward. :P
> You have to backspace, read reverse, or rewind to try again,
> because you stop after the block you tried to read.
> All tape formatters I've ever met insist on stopping in the
> inter-record gap.
tapeio.h does that, so I will too. :P
> Note that the TPC tape image format that I prefer isn't the
> easiest to backspace or read reverse from in an emulator. John
> Wilson's tape image format - where the record length is stored both
> before and after the record - is much more convenient for an emulator.
Eww! I thought TPC format WAS John's format! No wonder I've been having
so much trouble with TPC files!
Speaking of which, would you happen to have a version of t10backup that
can read a binary file from a saveset and NOT mess it up? The version I
have eats binaries.
> are in that format. (Call me an old fogey, but I have literally
> hundreds of gigabytes of tape images in TPC format and I'm not going
> to convert them all *and* my tools.) If you want to convert from TPC
> format to John's format, Bob Supnik's emulator package comes with
> "mtcvtv23" to do the conversion in that direction. It's just as easy to
> write a little bit of code to go the other direction.
>
Oh, OK. I'll run the TPCs I have thru that and see what happens. :P
> If you want to learn the basics of tape manipulation at a low level
> with DEC's tape controllers, I think the best way to start (because
> that's how I learned it many years ago!) is the magtape .SPFUN section
> in the RT-11 manuals. If you're more hardware-minded, starting with
> the TM11 printset may be more comfortable for you.
I'll have to see if I can find that somewhere. I'm definetely not good at
reading printsets, so I'll look for the RT11 manuals. :P
> Note that many OS's don't give you very direct access to all possible
> tape functions. Lots of OS's don't allow you any way to issue a
> read reverse, some will even be rude enough to put a tape offline if
> you get a buffer overflow.
tapeio called exit() by default, I had to hack a little to make it return
an error instead. :P It would be a bad thing if someone's user-mode
program overflowed a buffer and it caused the machine to disappear. :P
Tim Shoppa
> Note also, that a zero length block is a tape mark. Two tape marks
> usually indicate the logical end of tape. One tape mark is usually
> used to indicate the end of a file.
Note the use of "usually" :-). Even some rather standard tape
formats - most notably many interpretations of ANSI labeled tapes -
allow for double tape marks in the middle of a tape. Robust
tape image manipulation facilities know about this, and allow you to
image all of such a tapes without running past the logical end (or much
past the end) of the tape. DECUS TPC implementations, for example,
have
an /ANSI switch for such tapes. Some other tape imager implementations
attempt (note I said _attempt_) to auto-detect such tapes. Some
don't even try - for example, RSX-11M+ "VCP COPY/DEVICE" truncates
a tape after the first double tape mark. Too bad, it could be useful
otherwise. (It'd help if Mentec would document the VCP tape image
format, too!)
Question for John Wilson: Does your "ST.EXE" work in both
directions if there are double tape marks in the middle? Is there
a switch for enabling/disabling this feature? Unlike
many of your other fine tools, I can't browse the source code to this
one to determine the answer! I ask because ST.EXE is the closest
thing I know of to tape imaging software for a non-DEC OS.
The "double tape-mark in middle of tape" is a pretty rude feature
of ANSI tapes, but one that we've lived with for long enough that
I don't think it's going to ever change.
--
Tim Shoppa Email: sho...@trailing-edge.com
Trailing Edge Technology WWW: http://www.trailing-edge.com/
Jay Maynard
wrote:
>I ask because ST.EXE is the closest
>thing I know of to tape imaging software for a non-DEC OS.
The Hercules system as a program that will drop down a whole tape - double
tapemarks and all - to a file under Linux. The format it creates is one
defined by IBM, called AWSTAPE, but it could probably be hacked into
providing the output format you use as well. It reads the whole tape until
the tape drive itself signals end of media. I've used it to suck down an
ooooold tape I created, with a Qualstar 3412S on my Linux box; the tape had
pretty severe problems reading, and the Qualstar reported that as many
0-block files, but Hercules' tapecopy faithfully created the file with all
of those tapemarks in it. I don't believe tapecopy will read backwards, but
that shouldn't be too hard to add...
(To those who wonder how you can have double tapemarks in the middle of a
tape, consider an IBM standard-labeled tape. The volume header is a block
with a following tapemark. The first file header is another block with a
following tapemark. Then comes the file itself, with a following tapemark.
The next thing on the tape is the EOF block, with a following tapemark. Now,
what happens when the file itself is 0 blocks long? You guessed it, two
tapemarks in a row.)
Tim Shoppa
>
> On Mon, 15 May 2000, Tim Shoppa wrote:
>
> > Most (all?) DEC tape controllers will give you an error indication
> > if the tape block is longer than the number of characters (don't
> > forget 7-tracks!) than the read command
> > was issued for. The number of bytes that you wanted to read
> > are generally transferred succesfully into the specified buffer.
> > The exact details depend on the tape controller you're using and
> > how the OS/driver interprets the error/status bits.
>
> OK, that makes sense. What about the other way - what if you want to read
> 1024 bytes and the record is 512 long? Does it just read the extra
> blocks, or is there an error that way too?
It's not necessarily an error - note that whether you regard a
record-length mismatch as an error or as a status thingy is a
decision that's usually enforced at the driver or OS level. (Though
the fact that it sometimes appears in the error summary bit of
the CSR will tell you whether the hardware designers thought it was
an error or a status thingy.)
Most DEC tape controllers will, if you issue a read for more bytes
than present in a tape block, read one block, stop in the gap, and
return to you the number of bytes actually read. (Or the residual
of bytes requested but not read, in the hardware registers!)
> > Note that the TPC tape image format that I prefer isn't the
> > easiest to backspace or read reverse from in an emulator. John
> > Wilson's tape image format - where the record length is stored both
> > before and after the record - is much more convenient for an emulator.
>
> Eww! I thought TPC format WAS John's format! No wonder I've been having
> so much trouble with TPC files!
Pre-2.3 Supnik emulators use TPC. I don't know if any older versions
of John's emulator used TPC format, he saw the disadvantages of that
format for emulator backspacing pretty early on I think. TPC format
wasn't really designed for emulators, it was designed for archiving.
> Speaking of which, would you happen to have a version of t10backup that
> can read a binary file from a saveset and NOT mess it up? The version I
> have eats binaries.
Define "not mess it up" for a 36-bit binary file - or even the issue of
how to conclusively differentiate a binary from a text file - and
you're 99% of the way to your answer. Note that just looking at
the TOPS-20 filesystem recorded byte size isn't necessarily enough - for
example, on XKLETEN.PAULALLEN.COM:
XKLeTen@ vdir ps:<decus.lib20.0050>
PS:<DECUS.LIB20.0050>
DACOMP.FOR.1;P525252 2 778(36) 30-Oct-71 17:00:00 DECUS
DATAST.FOR.1;P525252 6 2612(36) 11-Oct-71 17:00:00 DECUS
ITB.FOR.1;P525252 1 390(36) 5-Jun-72 17:00:00 DECUS
ITBMAC..1;P525252 1 102(36) 25-Feb-72 16:00:00 DECUS
TBL.CMD.1;P525252 1 106(7) 30-Jun-80 14:16:13 DECUS
[...]
yet the *.FOR's are most assuredly 7-bit ascii text files:
XKLeTen@ type ps:<decus.lib20.0050>DACOMP.FOR
SUBROUTINE DACOMP(KOMPAR,ILPT,IARRAY,ILOW,IHIGH,
1JARRAY,JLOW,JHIGH)
C
C SUBROUTINE TO REPORT DIFFERENCES BETWEEN 2 ARRAYS
C
C KOMPAR = 0, RETURNED IF ARRAYS DIFFER
C = 1, RETURNED IF ARRAYS IDENTICAL
C ILPT = UNIT ON WHICH OUTPUT IS WRITTEN
C IARRAY = FIRST ARRAY TO BE TESTED
C ILOW = SUBSCRIPT OF START OF IARRAY
[...]
Daniel Seagraves
> > OK, that makes sense. What about the other way - what if you want to read
> > 1024 bytes and the record is 512 long? Does it just read the extra
> > blocks, or is there an error that way too?
>
> It's not necessarily an error - note that whether you regard a
> record-length mismatch as an error or as a status thingy is a
> decision that's usually enforced at the driver or OS level. (Though
> the fact that it sometimes appears in the error summary bit of
> the CSR will tell you whether the hardware designers thought it was
> an error or a status thingy.)
>
> Most DEC tape controllers will, if you issue a read for more bytes
> than present in a tape block, read one block, stop in the gap, and
> return to you the number of bytes actually read. (Or the residual
> of bytes requested but not read, in the hardware registers!)
OK. I'm trying to see how my emulated tape should be behaving...
> Pre-2.3 Supnik emulators use TPC. I don't know if any older versions
> of John's emulator used TPC format, he saw the disadvantages of that
> format for emulator backspacing pretty early on I think. TPC format
> wasn't really designed for emulators, it was designed for archiving.
Ah.
> > Speaking of which, would you happen to have a version of t10backup that
> > can read a binary file from a saveset and NOT mess it up? The version I
> > have eats binaries.
>
> Define "not mess it up" for a 36-bit binary file - or even the issue of
> how to conclusively differentiate a binary from a text file - and
> you're 99% of the way to your answer. Note that just looking at
> the TOPS-20 filesystem recorded byte size isn't necessarily enough - for
> example, on XKLETEN.PAULALLEN.COM:
Uhh, putting it in core dump format would be nice... ^_^ That's 8-bit
frames, and easily readable. (You know, like magtapes used.)
I'd just like to be able to pull the 7.03 monitor out of a saveset and
feed it to the emulator, that's all. But it doesn't work, so I have to
make BOOTM go first...
Stephen H. Westin
> Daniel Seagraves wrote:
> >
> > I just figured out I have no real idea how a tape drive (As in 9-track
> > tapes) work. I assumed it worked somewhat like a disk, but I guess not.
> >
> > Like, what happens if you read just the first 512 bytes of a 10240 byte
> > tape block?
>
> Most (all?) DEC tape controllers will give you an error indication
> if the tape block is longer than the number of characters (don't
> forget 7-tracks!) than the read command
> was issued for. The number of bytes that you wanted to read
> are generally transferred succesfully into the specified buffer.
> The exact details depend on the tape controller you're using and
> how the OS/driver interprets the error/status bits.
And that's complicated by the fact that a checksum is for the whole
tape block, so there's no way to confirm if the read was successful (as
far as it went) or not.
<snip>
> > What about writing in the middle of a
> > tape?
>
> If you start in a gap, not a problem.
Except that, in the definition of tape, you have erased everything to
the end of the tape. Practically speaking, you will write the
inter-record gap (a segment of erased tape nominally 0.6" long, as I
recall) over the start of the next record, even when replacing a
record with a record of exactly the same length. At least, that will
happen as often as not.
<snip>
--
-Stephen H. Westin
Any information or opinions in this message are mine: they do not
represent the position of Cornell University or any of its sponsors.
Tim Shoppa
>
> Tim Shoppa <sho...@trailing-edge.com> writes:
>
> > Daniel Seagraves wrote:
> > > What about writing in the middle of a
> > > tape?
> >
> > If you start in a gap, not a problem.
>
> Except that, in the definition of tape, you have erased everything to
> the end of the tape.
Well, yeah, I kind-of assumed that he knew that was generally
true.
> Practically speaking, you will write the
> inter-record gap (a segment of erased tape nominally 0.6" long, as I
> recall) over the start of the next record, even when replacing a
> record with a record of exactly the same length. At least, that will
> happen as often as not.
There are ways to trick some tape drives into writing really long
gaps and then using the gaps as "buffer zones" for doing random-access
writes, but I don't want to go there again :-).
Luckily most emulator tape formats effectively truncate the tape
image after a write into the middle of the tape image. (Any
exceptions?)
Tim.
John Wilson
Daniel Seagraves <ro...@bony.umtec.com> wrote:
>OK, that makes sense. What about the other way - what if you want to read
>1024 bytes and the record is 512 long? Does it just read the extra
>blocks, or is there an error that way too?
That's an error (well, sort of) too, you always get just one record when you
read from tape. The details depend on the particular controller, but basically
you get as much data as will fit in your buffer, and somewhere there is an
indication of the actual length of the record (FC register in the TM03's case).
>> Things *do* get more complicated when doing a read reverse. Do the
>> PDP-10's tape formatter bit fiddlers even do read reverse, or do they
>> just back up and read forward?
>
>I don't plan on implementing that. :P I'm just going to backspace and read
>forward. :P
Note that this *isn't* the same thing, because the TM03 comes from the days
when RAM was expensive so it has no buffering at all. It has to spit the
words somewhere while they're coming in, rather than buffering the whole
record and then coughing it up the right way around, so the record will be
beamed into memory *backwards*. I don't even want to think about what the
universal bit fiddler does in this case (especially if the record turns out
to not be a word multiple) but it certainly must do *something*.
But anyway it's pretty rare to see read-reverse operations. On magtape
that is, on DECtape it was pretty common.
John Wilson
D Bit
John Wilson
Tim Shoppa <sho...@trailing-edge.com> wrote:
>Question for John Wilson: Does your "ST.EXE" work in both
>directions if there are double tape marks in the middle? Is there
>a switch for enabling/disabling this feature?
No, but there should be. When writing an image file to tape, ST.EXE does
exactly what it's told so there can be TMs anywhere. When reading, it stops
at the first LEOT. The horrible TU.COM kludge that ST.EXE is descended from
didn't include the automatic rewinds so you were free to issue another IGET
command after LEOT to see if there's more stuff, but ST.EXE tries to be
more automatic (I got tired of having to type up a sample session every
time I sent TU.COM to someone), making it go all the way until it hits blank
media would be a good option (or even, a good default?) to add. ST isn't
intended to make any assumptions about tape formats so I'd feel funny about
trying to add heuristics to make it "know" whether it's within a file when
it hits LEOT, but I guess that would be OK under a switch or something.
Just in case anyone cares: ST.EXE is a simple SCSI tape manipulation tool for
DOS, you can get it from ftp.dbit.com. It does simple "mt" style operations,
but it can also copy between SCSI tapes, and image files in E11's image format
(with ".long length" at both ends of each record, and a single ".long 0"
for tape marks).
John Wilson
D Bit
John Wilson
Stephen H. Westin <westin*nos...@graphics.cornell.edu> wrote:
>Except that, in the definition of tape, you have erased everything to
>inter-record gap (a segment of erased tape nominally 0.6" long, as I
>recall) over the start of the next record, even when replacing a
>record with a record of exactly the same length. At least, that will
>happen as often as not.
Many tape drives have a command to erase a 3" gap, which can be abused to
avoid this problem. Some drives even have a way to make them turn off the
write current gradually after writing a record, to avoid a glitch at the
splice point, just for this purpose.
But, if what you really want is DECtape, use DECtape!!!
John Wilson
D Bit
John Ferrell
Tim Shoppa wrote:
> Johnny Billquist wrote:
> > Note also, that a zero length block is a tape mark. Two tape marks
> > usually indicate the logical end of tape. One tape mark is usually
> > used to indicate the end of a file.
>
> Note the use of "usually" :-). Even some rather standard tape
> formats - most notably many interpretations of ANSI labeled tapes -
> allow for double tape marks in the middle of a tape. Robust
> tape image manipulation facilities know about this, and allow you to
> image all of such a tapes without running past the logical end (or much
> past the end) of the tape. DECUS TPC implementations, for example,
> have
> an /ANSI switch for such tapes. Some other tape imager implementations
> attempt (note I said _attempt_) to auto-detect such tapes. Some
> don't even try - for example, RSX-11M+ "VCP COPY/DEVICE" truncates
> a tape after the first double tape mark. Too bad, it could be useful
> otherwise. (It'd help if Mentec would document the VCP tape image
> format, too!)
>
> Question for John Wilson: Does your "ST.EXE" work in both
> directions if there are double tape marks in the middle? Is there
> a switch for enabling/disabling this feature? Unlike
> many of your other fine tools, I can't browse the source code to this
> one to determine the answer! I ask because ST.EXE is the closest
> thing I know of to tape imaging software for a non-DEC OS.
>
> The "double tape-mark in middle of tape" is a pretty rude feature
> of ANSI tapes, but one that we've lived with for long enough that
> I don't think it's going to ever change.
>
> --
> Tim Shoppa Email: sho...@trailing-edge.com
> Trailing Edge Technology WWW: http://www.trailing-edge.com/
> 7328 Bradley Blvd Voice: 301-767-5917
> Bethesda, MD, USA 20817 Fax: 301-767-5927
--
John Ferrell in Julian NC, de W8CCW
Dixie Competition Products
6241 Phillippi Rd
Julian NC 27283
Phone: (336)685-9606 Fax: (336)685-9771
NSRCA 479 AMA 4190
"My Competition is Not My Enemy"
Joel C. Ewing
Jay Maynard wrote:
...
> (To those who wonder how you can have double tapemarks in the middle of a
> tape, consider an IBM standard-labeled tape. The volume header is a block
> with a following tapemark. The first file header is another block with a
> following tapemark. Then comes the file itself, with a following tapemark.
> The next thing on the tape is the EOF block, with a following tapemark. Now,
> what happens when the file itself is 0 blocks long? You guessed it, two
> tapemarks in a row.)
You have misinterpreted something in the manuals (possibly confusing the
80-byte EOFn label records with a physical end-of file or tapemark).
Each logical file on IBM standard-labeled tape corresponds to exactly 3
physical files, each ending with a tapemark. Only the middle physical
file of each set (the actual application data) can ever be null. The
first physical file of the set contains either two 80-byte records (HDR1
& HDR2) or three 80-byte records if this is the first file on the tape
(VOL1, HDR1, & HDR2) followed by a tapemark. The third physical file of
the set contains two 80 byte records followed by a tapemark, either EOF1
& EOF2 (end of file), or EOV1 & EOV2 (end of volume with file continued
on next volume). The only place you could legitimately find two
tapemarks together on a standard-labeled tape is at the logical end of
the tape volume with an extra trailing tapemark following the final
EOF1/EOF2 or EOV1/EOV2 label records. The only time you will ever find
the VOL1 record set off in a physical file by itself with no HDRn
records is on a freshly initialized tape that contains no files.
--
Joel C. Ewing, Fort Smith, AR jce...@acm.org
Jay Maynard
>The only place you could legitimately find two
>tapemarks together on a standard-labeled tape is at the logical end of
>the tape volume with an extra trailing tapemark following the final
>EOF1/EOF2 or EOV1/EOV2 label records. The only time you will ever find
>the VOL1 record set off in a physical file by itself with no HDRn
>records is on a freshly initialized tape that contains no files.
You're right about my screwing up the VOL1, but my point still stands: if
you have a null file, in between the two file label blocks, then you'll have
HDR1/HDR2, tapemark, tapemark, EOF1/EOF2, tapemark.
Geoffrey G. Rochat
Daniel Seagraves wrote in message ...
>
>I just figured out I have no real idea how a tape drive (As in 9-track
>tapes) work. I assumed it worked somewhat like a disk, but I guess
not.
Actually DECtape did work rather like a disk. DECtape was marked with a
format track that was not overwritten in normal use, and was blocked
into fixed-length segments. The blocks were analogous to
cylindar/head/sector addressing on disks, and you could think of DECtape
as disks, with disk-like file structures, but with VERY long and
variable seek times.
Another flavor of tape, found in instrumentation systems and telco
billing systems, was incremental tape. The magnetic tape was moved
across the pole pieces of the write head by a stepper motor, and writing
was done one byte at a time. One could use this same scheme to write
gaps and tape marks for compatibility with normal 9-track tape (see
below), so upon readback at a data center the tape would appear to have
been written by a conventional tape drive. I don't know if anyone
managed to put blocking and file systems on incremental tape, but would
be interested in hearing from The Wider World if anyone had.
>
>Like, what happens if you read just the first 512 bytes of a 10240 byte
>tape block? Do you have to rewind and try again to get the rest, or
does
>it stop where you stop reading? What about writing in the middle of a
>tape? I just know how disks work, I've never dealt with a tape other
than
>mounting them on the PDP11 and having a fit when they don't work. :P
Conventional 9-track (and before that, 7-track) magtape systems are not
like disks at all. Give up on the notion of addressable sectors of
fixed lengths, and picture strings of bytes whose structure depends on
context. (To paraphrase George Harrison, "Give up all thought,
surrender to the void. It is believing, it is believing.") At the
beginning of a reel of tape is a (supposedly, although they often fall
off) permanent reflective marker that denotes the beginning of the tape.
After that comes an erased gap that reads as "nothing". After that come
strings of bytes called records. (Some computer manufacturers call what
I'm referring to as records tape blocks. For the purposes of this
discussion I'll keep the term "block" for the fixed unit of storage
found on a DECtape, and refer to the variable-length thingies on
magtapes as records.) Between records are erased inter-record gaps.
Also between records are tape marks, which are special single byte
patterns surrounded by appropriate gaps. Often a double tape mark is
placed after the last record on a tape and is called the end-of-file
mark. At the physical end of the tape is another reflective marker to
(if you're lucky) keep the tape system from walking the tape off the
supply reel (sometimes known as "flapping" the tape).
Typically you'd command a magtape system to rewind the tape, and it
would position the tape such that the first reflective marker would be
under it's sensor. You'd then command the tape system to write one or a
series of records (generally of whatever reasonable length you want),
perhaps interspersed with tape marks, to the tape, and the magtape
system would start the tape moving, write what you commanded with
appropriate intervening gaps, then when done write a gap as the tape
slowed down. If you commanded subsequent writes the magtape system
would back the tape up until it found the last record or tape mark
written, slow down, reverse the tape, and once the last record ended or
the tape mark was seen would write the appropriate gap followed by your
new data. The trick to tape, unlike disks, is that tape motion starts
and stops and tape inertia takes a while, hence the need for gaps, and
results in a certain rather large amount of positional uncertainty.
Therefore, in a conventional magtape system all data on the tape
subsequent to the last record you just wrote is considered invalid -
even if you assiduously attempt to re-write over exactly the same record
on exactly the same piece of tape your most recent writing may just have
sufferred gap creep, and you may have partially written over a
subsequent record or tape mark, or have left a gap too small to
accomodate the inertia of the tape system. Read are non-destructive,
and you can back a tape up or advance it by N records or tape marks
without concern. Due to these constraints, magtapes are
sequential-access, not random-access. Note that due to its fixed
formatting and blocking, these limitations do not occur with DECtape.
You could indeed read 512 bytes of a a 10240 byte record, but then the
magtape system might become "lost", and you might have to command the
magtape system to find the next (or last) record by seaching for the
appearance of data (or tape mark) after a gap. Writing in the middle of
a tape is, as explained above, verboten.
Often, in large mainframe shops, tapes are "staged" onto disks: Tapes
are dumped to disks, their data is manipulated in the addressable,
file-oriented, random-access world of disks, then dumped back to tape
when the job is done. It's often easier to treat magtape as "one big
glomb of data", and pick that data to pieces elsewhere, rather than to
try to do it with magtape itself.
Magtape is funky stuff. Actually, it's clunky stuff, and although I did
extensive work with magtape some 20 years ago, I'm quite happy that I
haven't felt the need to work with it any time recently.
Richard M. Alderson III
Daniel Seagraves <ro...@bony.umtec.com> writes:
> On Mon, 15 May 2000, Tim Shoppa wrote:
>>> Speaking of which, would you happen to have a version of t10backup that can
>>> read a binary file from a saveset and NOT mess it up? The version I have
>>> eats binaries.
>> Define "not mess it up" for a 36-bit binary file - or even the issue of how
>> to conclusively differentiate a binary from a text file - and you're 99% of
>> the way to your answer. Note that just looking at the TOPS-20 filesystem
>> recorded byte size isn't necessarily enough - for example, on
>> XKLETEN.PAULALLEN.COM:
> Uhh, putting it in core dump format would be nice... ^_^ That's 8-bit frames,
> and easily readable. (You know, like magtapes used.)
Core-dump mode is 36 bits packed into 5 8-bit tape frames, as
TRACKS FRAMES
9 8 7 6 5 4 3 2 1
B0 B1 B2 B3 B4 B5 B6 B7 P 1
B8 B9 B10 B11 B12 B13 B14 B15 P 2
B16 B17 B18 B19 B20 B21 B22 B23 P 3
B24 B25 B26 B27 B28 B29 B30 B31 P 4
B32 B33 B34 B35 0 0 0 0 P 5
(NB: This is the logical layout--physical has the parity track (P) at the
center, for example.)
There are three other modes possible on a 9-track tape on Tops-10 or Tops-20,
high density (two words in 9 frames), "industry compatible" (4 8-bit bytes in 4
frames, ignore/zero-fill bits 32-35), and "ANSI-ASCII" (pack 5 7-bit bytes in
5 8-bit frames, store bit 35 in the last frame), but you can ignore them for
now, since both Tops-10 BACKUP and Tops-20 DUMPER write all data in core-dump
mode.
Rich Alderson Last LOTS Tops-20 Systems Programmer, 1984-1991
Current maintainer, MIT TECO EMACS (v. 170)
Customer Advocacy, XKL LLC, 1993-2000
last name @ XKL dot COM Chief systems administrator, XKL LLC, 1998-now
John Wilson
Richard M. Alderson III <alde...@netcom.com> wrote:
>Core-dump mode is 36 bits packed into 5 8-bit tape frames, as
>
> TRACKS FRAMES
>
> 9 8 7 6 5 4 3 2 1
>
> B0 B1 B2 B3 B4 B5 B6 B7 P 1
> B8 B9 B10 B11 B12 B13 B14 B15 P 2
> B16 B17 B18 B19 B20 B21 B22 B23 P 3
> B24 B25 B26 B27 B28 B29 B30 B31 P 4
> B32 B33 B34 B35 0 0 0 0 P 5
Nitpick -- shouldn't bits 32 through 35 be *right* justified in the 5th
tape frame? On TM03-based drives at least...
How does the bit fiddler feel about "read reverse" commands (77) in this mode?
John Wilson
D Bit
Johnny Billquist
>
> Tim Shoppa <sho...@trailing-edge.com> writes:
>
> > Daniel Seagraves wrote:
> > >
> > > tapes) work. I assumed it worked somewhat like a disk, but I guess not.
> > >
> > > tape block?
> >
> > if the tape block is longer than the number of characters (don't
> > forget 7-tracks!) than the read command
> > was issued for. The number of bytes that you wanted to read
> > are generally transferred succesfully into the specified buffer.
> > The exact details depend on the tape controller you're using and
> > how the OS/driver interprets the error/status bits.
>
> And that's complicated by the fact that a checksum is for the whole
> tape block, so there's no way to confirm if the read was successful (as
> far as it went) or not.
Um. Actually, the tape formatter will probably read the whole block
and verify that the checksum is correct. It's just the DMA transfer
that shorthands you.
So, yes. If the tape block has a bad checksum, you'll get the
status bits telling so. (Atleast that's what I think)
Johnny Billquist
Well, "pretty common" might be a strong word. If you read backwards,
not only do you get data in the wrong order. All bits are inversed
as well. And on DECtape, each "row" only have three bits, which means
that these groupings in three also gets reversed.
The block mark and tape mark words on DECtape were choosen carefully
so that they'd come out correct either way you were reading.
BOT and EOT are each others inverses, while block marks always
look the same.
Don Stokes
[Labelled tapes and stray double tape marks]
BTW: I found myself faced with a 1600 bpi EBCDIC labelled tape again
today, after believing I was rid of them forever. But this one had
the VOL1, HDR1 and HDR2 labels in one 240 byte block (followed by a
tape mark), not three 80 byte blocks as I'm used to.
Is this common? The tape allegedly came from a Unisys system of
some sort. (The application just skipped the labels and peeled the
tape contents apart itself, so the contents of the label was only of
interest to ensure that we were getting what we thought we should
be getting off the tape.)
-- don
Johnny Billquist
Never heard of it done that way.
I think that according to the RSX manuals, ANSI tapes are not supposed
to look that way. Maybe Unisys had a different view, or perhaps
EBCDIC-labelled are not really the same as ANSI-labelled...
jmfb...@aol.com
jmay...@thebrain.conmicro.cx (Jay Maynard) wrote:
>On Mon, 15 May 2000 10:47:54 -0400, Tim Shoppa <sho...@trailing-edge.com>
>wrote:
>>thing I know of to tape imaging software for a non-DEC OS.
>
>tapemarks and all - to a file under Linux. The format it creates is one
>defined by IBM, called AWSTAPE, but it could probably be hacked into
>providing the output format you use as well. It reads the whole tape until
>the tape drive itself signals end of media. I've used it to suck down an
>ooooold tape I created, with a Qualstar 3412S on my Linux box; the tape
had
>pretty severe problems reading, and the Qualstar reported that as many
>0-block files, but Hercules' tapecopy faithfully created the file with all
>of those tapemarks in it. I don't believe tapecopy will read backwards,
but
>that shouldn't be too hard to add...
>
>tape, consider an IBM standard-labeled tape. The volume header is a block
>with a following tapemark. The first file header is another block with a
>following tapemark. Then comes the file itself, with a following tapemark.
>The next thing on the tape is the EOF block, with a following tapemark.
Now,
>what happens when the file itself is 0 blocks long? You guessed it, two
>tapemarks in a row.)
Note that he's talking about standard _tape labels_. I
remember when these standards were getting implemented in
36-bit land. It was not a pretty sight.
/BAH
Subtract a hundred and four for e-mail.
jmfb...@aol.com
Tim Shoppa <sho...@trailing-edge.com> wrote:
>Stephen H. Westin wrote:
>>
>> Tim Shoppa <sho...@trailing-edge.com> writes:
>>
>> > Daniel Seagraves wrote:
>> > > tape?
>> >
>> > If you start in a gap, not a problem.
>>
>> the end of the tape.
>
>true.
>
>> inter-record gap (a segment of erased tape nominally 0.6" long, as I
>> recall) over the start of the next record, even when replacing a
>> record with a record of exactly the same length. At least, that will
>> happen as often as not.
>
>gaps and then using the gaps as "buffer zones" for doing random-access
>writes, but I don't want to go there again :-).
I wish you hadn't said that [stern emoticon here with a twinkle
to those who know better].
jmfb...@aol.com
alde...@netcom2.netcom.com (Richard M. Alderson III) wrote:
>In article <Pine.LNX.4.10.100051...@bony.umtec.com>
>Daniel Seagraves <ro...@bony.umtec.com> writes:
>
>> On Mon, 15 May 2000, Tim Shoppa wrote:
>
>>>> Speaking of which, would you happen to have a version of t10backup
that can
>>>> read a binary file from a saveset and NOT mess it up? The version I
have
>>>> eats binaries.
>
>>> Define "not mess it up" for a 36-bit binary file - or even the issue of
how
>>> to conclusively differentiate a binary from a text file - and you're
99% of
>>> the way to your answer. Note that just looking at the TOPS-20
filesystem
>>> recorded byte size isn't necessarily enough - for example, on
>>> XKLETEN.PAULALLEN.COM:
>
>> Uhh, putting it in core dump format would be nice... ^_^ That's 8-bit
frames,
>> and easily readable. (You know, like magtapes used.)
>
<snip layout>
>There are three other modes possible on a 9-track tape
>on Tops-10 or Tops-20,
>high density (two words in 9 frames), "industry compatible"
>(4 8-bit bytes in 4
>frames, ignore/zero-fill bits 32-35), and "ANSI-ASCII"
>(pack 5 7-bit bytes in
>5 8-bit frames, store bit 35 in the last frame), but
>you can ignore them for now, since both Tops-10 BACKUP
>and Tops-20 DUMPER write all data in core-dump mode.
<snip>
I did???!!!??? I'm not arguing...well sorta not :-). I just don't
remember that. I used buffered mode for sure. And for those
who are trying to read BACKUP/DUMPER tapes. They had their
own data layouts that had nothing to do with _how_ the tapes
were physically written. So you guys really need to specify
exactly what formats you are talking about. :-)
Hint: Think about the INTERCHANGE command to BACKUP which
allowed it to read DUMPER tapes, BACKUP tapes, and FAILSA
tapes.
Joe Morris
>Rude? Rude is two load point stickers!
...or none at all. This could occur if an operator decided that the
leader on a scratch tape was getting to be too wrinkled, and therefore
cut it off (after pulling off enough tape to ensure that the BOT
reflective sticker was part of the discarded leader) -- and then
was interrupted by a user and forgot to put a new BOT sticker on
the tape.
H'mmm ... now you've got me wondering if my kinesthetic memory is still
good enough to grab a tape, pull the hanger ring off, pull down the
door on a 729, toss the tape onto the supply (left) hub, pull the end
of the tape enough to let inertia unspool *exactly* the right amount
of leader, thread that leader through the head and onto the takeup
spool, spin the takeup spool the usual 10-12 turns to get past the
BOT sticker, raise the door, spin the unit number dial, and hit the
REWIND and READY buttons...all in one smooth, continuous operation.
At one time there would have been no question about this, but it's
been more than a few years since I last did it...
Joe Morris
Joe Morris
> The
>first physical file of the set contains either two 80-byte records (HDR1
>& HDR2) or three 80-byte records if this is the first file on the tape
>(VOL1, HDR1, & HDR2) followed by a tapemark. The third physical file of
>the set contains two 80 byte records followed by a tapemark, either EOF1
>& EOF2 (end of file), or EOV1 & EOV2 (end of volume with file continued
>on next volume).
One minor nitpick: there could be additional records if the installation
implements additional volume labels (VOL2, VOL3...) and/or user file
labels (UHL1, UHL2, ... and UTL1, UTL2, ...). In any case these "user
label" records would follow the standard label records on the tape.
Joe Morris
Joe Morris
for EBCDIC tape labels isn't quite the same as for ANSI standard tape
labels, but both specs require that each label, header, and trailer
be in a separate record.
My guess (aka "wild speculation") would be that the volume started life
as a properly-labeled tape, but at some point it was copied and reblocked
by a program that didn't know anything about tape labels. Especially if
the data on the tape is in 80-byte images, I could see how a mildly
retarded (not quite brain-dead, but close) tape copy program might see
the three, 80-byte record in the first "file" on the tape, and decide
to convert the file to FB (fixed/blocked) format by merging the three,
80-byte records into one 240-byte block.
Are the trailing (EOF1/EOF2) records blocked into a 160-byte record?
Joe Morris
d...@news.daedalus.co.nz (Don Stokes) writes:
>In article <39207146...@acm.org>, Joel C. Ewing <jce...@acm.org> wrote:
>[Labelled tapes and stray double tape marks]
>BTW: I found myself faced with a 1600 bpi EBCDIC labelled tape again
>today, after believing I was rid of them forever. But this one had
>the VOL1, HDR1 and HDR2 labels in one 240 byte block (followed by a
>tape mark), not three 80 byte blocks as I'm used to.
>Is this common? The tape allegedly came from a Unisys system of
>some sort. (The application just skipped the labels and peeled the
>tape contents apart itself, so the contents of the label was only of
>interest to ensure that we were getting what we thought we should
>be getting off the tape.)
>-- don
John Wilson
Johnny Billquist <Johnny.B...@netinsight.se> wrote:
>> that is, on DECtape it was pretty common.
>
>Well, "pretty common" might be a strong word.
Well in emulating DECtapes in E11, I found that DOS/BATCH and RSTS/E both
regularly do I/O in reverse. And TSS/8 certainly did too... Its DECtape
driver was an absolute work of art!!!
>If you read backwards,
>not only do you get data in the wrong order. All bits are inversed
>as well. And on DECtape, each "row" only have three bits, which means
>that these groupings in three also gets reversed.
>
>The block mark and tape mark words on DECtape were choosen carefully
>so that they'd come out correct either way you were reading.
>BOT and EOT are each others inverses, while block marks always
>look the same.
All true, but whether the obverse complement stuff is visible to the host
depends on the controller model. IIRC, the TC01 and TC08 do expose this
stuff to the PDP-8, but on the TC11, the PDP-11 sees normal data, the only
difference is that the 16-bit words in the buffer are in the reverse order.
That and, IIRC a short reverse write is effectively padded with ones instead
of zeros. I wouldn't know about the PDP-10 controllers but they're usually
fancier than the PDP-11 equivalents...
John Wilson
D Bit
Jay Maynard
>H'mmm ... now you've got me wondering if my kinesthetic memory is still
>good enough to grab a tape, pull the hanger ring off, pull down the
>door on a 729, toss the tape onto the supply (left) hub, pull the end
>of the tape enough to let inertia unspool *exactly* the right amount
>of leader, thread that leader through the head and onto the takeup
>spool, spin the takeup spool the usual 10-12 turns to get past the
>BOT sticker, raise the door, spin the unit number dial, and hit the
>REWIND and READY buttons...all in one smooth, continuous operation.
>At one time there would have been no question about this, but it's
>been more than a few years since I last did it...
I'm glad I wasn't qaround during those days.
I'm pretty sure I can do the 3420 equivalent, even today, though: thumb the
door safety strip to open the door, slap the autoloading reel (with a cover
the drive can open automagically) in place, hit RESET/LOAD/READY (which were
in a right/left/right sequence), walk away...
...and, occasionally, walk back when the autoload fails.
Johnny Billquist
>
> In article <3920FF05...@netinsight.se>,
> Johnny Billquist <Johnny.B...@netinsight.se> wrote:
> >If you read backwards,
> >not only do you get data in the wrong order. All bits are inversed
> >as well. And on DECtape, each "row" only have three bits, which means
> >that these groupings in three also gets reversed.
> >
> >The block mark and tape mark words on DECtape were choosen carefully
> >so that they'd come out correct either way you were reading.
> >BOT and EOT are each others inverses, while block marks always
> >look the same.
>
> All true, but whether the obverse complement stuff is visible to the host
> depends on the controller model. IIRC, the TC01 and TC08 do expose this
> stuff to the PDP-8, but on the TC11, the PDP-11 sees normal data, the only
> difference is that the 16-bit words in the buffer are in the reverse order.
Hey. That's cheating. :-)
I've only used the TC08 and TD8E. Both of them exposed me to all the
hard realities of reading and writing backwards.
OS/8 will only write and read in one direction...
> That and, IIRC a short reverse write is effectively padded with ones instead
> of zeros. I wouldn't know about the PDP-10 controllers but they're usually
> fancier than the PDP-11 equivalents...
The padding probably comes natural because of the bit inversions. Write
zeros backwards, and they are ones. Padding is probably done after
the nifty controller bit-reversal at reverse working.
(My guess)
Johnny Billquist
>
> I'm pretty sure I can do the 3420 equivalent, even today, though: thumb the
> door safety strip to open the door, slap the autoloading reel (with a cover
> the drive can open automagically) in place, hit RESET/LOAD/READY (which were
> in a right/left/right sequence), walk away...
>
> ...and, occasionally, walk back when the autoload fails.
Wow. That autoloader must be much better than the one on the TU77...
Jay Maynard
<Johnny.B...@netinsight.se> wrote:
>> ...and, occasionally, walk back when the autoload fails.
>Wow. That autoloader must be much better than the one on the TU77...
<smile type="IBM salesdroid">Why, of course it is. It's made by a REAL
computer company, not one of those minicomputer johnny-come-latelys.
</smile>
(Sorry...couldn't resist.)
I can't speak to the TU77, but a busy mainframe shop with a couple of rows
of 3420s, using tapes with the 3420 seal, would only experience a load
failure a couple of times a shift. The secret was the seal: it was designed
so that, when the little pin on the 3420 rotated to open the seal, what
opened was 1) a little window opposite a source of high-pressure air, and 2)
another little window with a ramp next to it. The blower would push the
leader away from the body of the tape, then the loose end would be drawn
across the window, guided into the proper angle by the ramp; when the drive
sensed the presence of the leader there, it would reverse direction and
thread the tape. Once you start in a known position, the rest is pretty
simple.
Another thing that helped was the little tool IBM specified to trim the end
of the tape. It was operator-proof: you stuck the tape in the tool and
squeezed, and you got a nice round cut and a couple of little crimped
wrinkles in the end that made it easier to separate from the tape during
loading. Made things go a lot more smoothly. (I wish I had one of those
right now, and some BOT markers, as I've got a coupld of 9-track tapes that
need new front ends...)
Al Kossow
(Joe Morris) wrote:
> H'mmm ... now you've got me wondering if my kinesthetic memory is still
> good enough to grab a tape, pull the hanger ring off, pull down the
> door on a 729, toss the tape onto the supply (left) hub, pull the end
> of the tape enough to let inertia unspool *exactly* the right amount
> of leader, thread that leader through the head and onto the takeup
> spool, spin the takeup spool the usual 10-12 turns to get past the
> BOT sticker, raise the door, spin the unit number dial, and hit the
> REWIND and READY buttons...all in one smooth, continuous operation.
> At one time there would have been no question about this, but it's
> been more than a few years since I last did it...
>
Reminds me of operators loading DECtapes with one finger on TSS/8.
You load the tape, let enough tape down to wrap a bit around your
right index finger, and in one motion loop it over the head and spin
it onto the other hub with just enough tape to secure it to the takeup
hub.
Last time I saw someone do that was in 1974 :-<
--
The eBay Curse:
"May you find everything you're looking for.."
Terry Kennedy
> I can't speak to the TU77, but a busy mainframe shop with a couple of rows
> of 3420s, using tapes with the 3420 seal, would only experience a load
> failure a couple of times a shift. The secret was the seal: it was designed
> so that, when the little pin on the 3420 rotated to open the seal, what
> opened was 1) a little window opposite a source of high-pressure air, and 2)
> another little window with a ramp next to it. The blower would push the
> leader away from the body of the tape, then the loose end would be drawn
> across the window, guided into the proper angle by the ramp; when the drive
> sensed the presence of the leader there, it would reverse direction and
> thread the tape. Once you start in a known position, the rest is pretty
> simple.
A little-known fact is that the [no-longer-available] loader ECO kit for
the TU78 also worked on the TU77. I had a row of 6 TU78's and 2 TU77's and
load failures were a rarity.
> Another thing that helped was the little tool IBM specified to trim the end
> of the tape. It was operator-proof: you stuck the tape in the tool and
> squeezed, and you got a nice round cut and a couple of little crimped
> wrinkles in the end that made it easier to separate from the tape during
> loading. Made things go a lot more smoothly. (I wish I had one of those
> right now, and some BOT markers, as I've got a coupld of 9-track tapes that
> need new front ends...)
I have a crimper from Misco. A quick web look shows no Misco, and INMAC
seems to be part of *Warehouse these days, so I don't know where you could
get them.
Terry Kennedy http://www.tmk.com
te...@tmk.com Jersey City, NJ USA
Adrian Lumsden
load a tape and couldn't get it to load.
The operator went along and found, in the end, that the tape was inside
out on the spool!
Turns out the user had threaded the tape with a half twist and hit LOAD.
The drive spaced down the whole length of the tape looking for the BOT
flash and never found it, ending up with the whole tape on the take up
spool. The user proceeded to rewind the tape **by hand** back on to the
original spool, minus the twist.
I don't remember what sort of drive it was but it obviously didn't have
the smarts to give up looking for the BOT flash if it didn't find it
within a certain length.
Adrian
--
Adrian Lumsden, XDT Computer Systems, UK
A dot Lumsden at xdt dot co dot uk
Al Kossow <a...@spies.com> wrote in message
news:aek-160500...@haxrus.apple.com...
<snip>
jchausler
Al Kossow wrote:
> In article <8frghf$7r6$1...@top.mitre.org>, jcmo...@jmorris-pc.MITRE.ORG
> (Joe Morris) wrote:
>
> > H'mmm ... now you've got me wondering if my kinesthetic memory is still
> > good enough to grab a tape, pull the hanger ring off, pull down the
> > door on a 729, toss the tape onto the supply (left) hub, pull the end
> > of the tape enough to let inertia unspool *exactly* the right amount
> > of leader, thread that leader through the head and onto the takeup
> > spool, spin the takeup spool the usual 10-12 turns to get past the
> > BOT sticker, raise the door, spin the unit number dial, and hit the
> > REWIND and READY buttons...all in one smooth, continuous operation.
> > At one time there would have been no question about this, but it's
> > been more than a few years since I last did it...
> >
Ah yes, don't think I could anymore. Never did it to a 729 but I did on
7330's as well as the 729 follow-on which came with the 360's in the
mid 60's. What was the part number for that??
With UNIVAC and the UNISERVO VIII's is was a little easier, but first
you had to splice a little "clip" onto the beginning of the tape. Then to
mount the tape you would just "punch" it on the hub, hook the male end
of the drives leader into the female "clip", release the little restraining
bracket which held the drives leader, close the door and push the usual
buttons. Because you didn't have to wind the tape manually in beyond
the load point BOT sticker (and I'm one of those folks who used to put
his load point stickers further in the tape than was normal :-) This was
a little quicker than with the IBM drives even though you had to manually
raise the door. I still have an old spool of load point (BOT) stickers from
IBM, but I don't have anymore UNIVAC "clips" (although I do have
many tapes with the clip spliced on). Although the clips were sturdier
than the tape occasionally as an operator I would find a tape without one,
either it had fallen off or the tape had come from an IBM shop and I
was unable to find any "clips" laying about. One could make one by
folding over about 1/2 inch of tape and splicing the end back to itself.
Then you would cut a small V shaped notch on the folded over end
into which the drives leader could be hooked. This worked fine for a
while but would eventually break after a dozen or so mountings.
> Reminds me of operators loading DECtapes with one finger on TSS/8.
> You load the tape, let enough tape down to wrap a bit around your
> right index finger, and in one motion loop it over the head and spin
> it onto the other hub with just enough tape to secure it to the takeup
> hub.
I had a number of these (still do) and that's not how I did it. I would use
all four fingers on my right hand to hold the tape against the hub of the
take up spool, feed a little extra tape from the source spool and then in
one motion spin the take up spool and remove my fingers. This would
always catch the end without folding back over on itself. I would then
with a finger wind a couple turns on the take up spool and about half
way through this create back tension on the feed spool with a finger
of the other hand. This doesn't sound fluid but with a little practice,
it was.
> Last time I saw someone do that was in 1974 :-<
Last time I did any of this was about 1970.
Chris
AN GETTO$;DUMP;RUN,ALGOL,TAPE
$$
Paul Hardy
>> Note also, that a zero length block is a tape mark. Two tape marks
>> usually indicate the logical end of tape. One tape mark is usually
>> used to indicate the end of a file.
A tape mark isn't a zero length block. If I remember rightly, on 9-track PE
tapes it's a 14-byte block of wrong-parity lowercase 's's.
--
Paul Hardy.
Don Stokes
Joe Morris <jcmo...@jmorris-pc.MITRE.ORG> wrote:
>My guess (aka "wild speculation") would be that the volume started life
>as a properly-labeled tape, but at some point it was copied and reblocked
>by a program that didn't know anything about tape labels. Especially if
>the data on the tape is in 80-byte images, I could see how a mildly
>retarded (not quite brain-dead, but close) tape copy program might see
>the three, 80-byte record in the first "file" on the tape, and decide
>to convert the file to FB (fixed/blocked) format by merging the three,
>80-byte records into one 240-byte block.
That possibility certainly crossed my mind. I'd been called in to deal
with this thing after someone else had given up on it, so I'm not
totally convinced that the tape hadn't been rewritten. But I don't
think it had. Similarly, I have no idea what had happened to the tape
before leaving the Unisys site.
>Are the trailing (EOF1/EOF2) records blocked into a 160-byte record?
No idea. I was getting a unix application to read the thing, which having
no concept of labelled tapes had no conceivable reason to read past the
second "file" on the tape...
-- don
Don Stokes
Terry Kennedy <te...@gate.tmk.com> wrote:
>In alt.sys.pdp11 Jay Maynard <jmay...@thebrain.conmicro.cx> wrote:
>> I can't speak to the TU77, but a busy mainframe shop with a couple of rows
>> of 3420s, using tapes with the 3420 seal, would only experience a load
>> failure a couple of times a shift. The secret was the seal: it was designed
>> so that, when the little pin on the 3420 rotated to open the seal, what
>> opened was 1) a little window opposite a source of high-pressure air, and 2)
>> another little window with a ramp next to it. The blower would push the
>> leader away from the body of the tape, then the loose end would be drawn
>> across the window, guided into the proper angle by the ramp; when the drive
>> sensed the presence of the leader there, it would reverse direction and
>> thread the tape. Once you start in a known position, the rest is pretty
>> simple.
>
> A little-known fact is that the [no-longer-available] loader ECO kit for
>the TU78 also worked on the TU77. I had a row of 6 TU78's and 2 TU77's and
>load failures were a rarity.
Was that ECO applied as standard on the '79? We put 3420 sealed tapes
on the thing a couple of times as an experiment and came rapidly to the
conclusion that it was *far* less likely to load the tape with the seal
than without, so decided not to tell the operators about that
capability...
(We had a VAX 11/730 at a client site, hiding in the corner of a machine
room, utterly dwarfed by a big blue dinosaur. The VAX was right by the
row of IBM tape drives, so while waiting for the thing to do stuff we
got to watch the IBM drives with their autoloaders and self-opening
doors. So of course we had to know if our shiny new TA79 could pull at
least the load-through-the-seal trick, even if the door had to be
opened manually...)
-- don
glen herrmannsfeldt
(snip)
>I don't remember what sort of drive it was but it obviously didn't have
>the smarts to give up looking for the BOT flash if it didn't find it
>within a certain length.
I don't know about BOT, but as far as I remember IBM drives, they only
look for the EOT strip on write. It will then finish the block being
written before signalling EOT, probably writing the trailer labels, too.
Mounting a blank tape when the machine expects either SL or NL
(standard label or no label) results in tape off the end of the reel.
When asked to read, it will read until it finds data, ignoring the EOT
strip.
-- glen
Terry Kennedy
> Was that ECO applied as standard on the '79? We put 3420 sealed tapes
> on the thing a couple of times as an experiment and came rapidly to the
> conclusion that it was *far* less likely to load the tape with the seal
> than without, so decided not to tell the operators about that
> capability...
As far as I know, it was standard on the TU/TA79. If the drive had the
brown sponge gasket over the air hole at the bottom of the supply reel
well, you had it (actually, there are various-colored plugs that go into
the vacuum column guts, but if you have one you have the other, unless
some FS tech got lazy).
Note that this drive has a specific requirement for EZ-Load II type
reels with IBM 3-crimp tape ends.
I've seen (and actually received from distributors) tapes in EZ-II
reels with v-notch fold-over ends. Apparently these are used in some
robotic 9-track library, but they *don't* work with the TU7x.
Jim Thomas
> H'mmm ... now you've got me wondering if my kinesthetic memory is still
> good enough to grab a tape, pull the hanger ring off, pull down the
> door on a 729, toss the tape onto the supply (left) hub, pull the end
> of the tape enough to let inertia unspool *exactly* the right amount
> of leader, thread that leader through the head and onto the takeup
> spool, spin the takeup spool the usual 10-12 turns to get past the
> BOT sticker, raise the door, spin the unit number dial, and hit the
> REWIND and READY buttons...all in one smooth, continuous operation.
> At one time there would have been no question about this, but it's
> been more than a few years since I last did it...
Well... I spun the tape first. But then I learned on 7330's (729
predecessor) :-)
Maybe the hub locked differently? And the unit number was not changable.
Nothead
Dave
d...@news.daedalus.co.nz (Don Stokes) wrote:
> In article <39207146...@acm.org>, Joel C. Ewing <jce...@acm.org>
> wrote:
> [Labelled tapes and stray double tape marks]
>
> BTW: I found myself faced with a 1600 bpi EBCDIC labelled tape again
> today, after believing I was rid of them forever. But this one had
> the VOL1, HDR1 and HDR2 labels in one 240 byte block (followed by a
> tape mark), not three 80 byte blocks as I'm used to.
Ah tapes!
I spent about 10 years reading/writing/deblocking/converting tapes from
one format to another in a previous life/job.
I once had to take an IBM POWER VSE format tape (1600 BPI, EBCDIC,
variable length blocks and records), read it onto a PC, convert the data
into fixed length records, add some control records to the data (to
control a XEROX 9700 laser printer), and write the data back out to
tape. The control records had to be added in EBCDIC. This was all done
in compiled BASIC, on a late 80's vintage PC! What fun!
I saw *all kinds* of strange tape formats in those days. Burroughs
(shudder) UNIVAC (double shudder), tapes with fixed length records *and*
record marks! How about a tape where the labels were in EBCDIC but the
data was in ASCII!
I still have a 9 track, 1600/800 BPI Qualstar drive hooked up to a PC.
I used to make a nice chunk of change doing tape/disk conversions, but
it's been a couple of years since I've actually used it.
Dave
Don Stokes
Terry Kennedy <te...@gate.tmk.com> wrote:
>In alt.folklore.computers Don Stokes <d...@news.daedalus.co.nz> wrote:
>> Was that ECO applied as standard on the '79? We put 3420 sealed tapes
>> on the thing a couple of times as an experiment and came rapidly to the
>> conclusion that it was *far* less likely to load the tape with the seal
>> than without, so decided not to tell the operators about that
>> capability...
>
> As far as I know, it was standard on the TU/TA79. If the drive had the
>brown sponge gasket over the air hole at the bottom of the supply reel
>well, you had it (actually, there are various-colored plugs that go into
>the vacuum column guts, but if you have one you have the other, unless
>some FS tech got lazy).
>
> Note that this drive has a specific requirement for EZ-Load II type
>reels with IBM 3-crimp tape ends.
I don't recall tapes in EZ-Load seals having the crimps, but that may
just be faulty memory. Either that, or our operators thought it was
damage and clipped 'em. After all, the (manual load) TA81s
The TA79 certainly handled those reels. Just very badly. The autoload
was temperamental at the best of times and the IBM seals reduced the
chances of the tape loading correctly by an order of magnitude.
I'm afraid the '79 just couldn't match the IBM drives, with their self-
opening doors and EZ-Load carts, for their coolness and bad 1960s SF
movie atmosphere... 8-)
-- don
Johnny Billquist
>
> On Tue, 16 May 2000 14:23:22 GMT, Johnny Billquist
> <Johnny.B...@netinsight.se> wrote:
> >> ...and, occasionally, walk back when the autoload fails.
> >Wow. That autoloader must be much better than the one on the TU77...
>
> <smile type="IBM salesdroid">Why, of course it is. It's made by a REAL
> computer company, not one of those minicomputer johnny-come-latelys.
> </smile>
>
> (Sorry...couldn't resist.)
>
> of 3420s, using tapes with the 3420 seal, would only experience a load
> failure a couple of times a shift. The secret was the seal: it was designed
> so that, when the little pin on the 3420 rotated to open the seal, what
> opened was 1) a little window opposite a source of high-pressure air, and 2)
> another little window with a ramp next to it. The blower would push the
> leader away from the body of the tape, then the loose end would be drawn
> across the window, guided into the proper angle by the ramp; when the drive
> sensed the presence of the leader there, it would reverse direction and
> thread the tape. Once you start in a known position, the rest is pretty
> simple.
>
> of the tape. It was operator-proof: you stuck the tape in the tool and
> squeezed, and you got a nice round cut and a couple of little crimped
> wrinkles in the end that made it easier to separate from the tape during
> loading. Made things go a lot more smoothly. (I wish I had one of those
> right now, and some BOT markers, as I've got a coupld of 9-track tapes that
> need new front ends...)
Believe me, the TU77 worked the same way, and I got a tape trimmer
with the |d|i|g|i|t|a|l| logo on it.
John Atkinson
<g...@ugcs.caltech.edu> writes
As a CE Trying to explain this to customers especially with input tapes
from an unknown source sometimes became a real problem. As far as
operators were concerned and there managers if it had en EOT mark on it
then the the tape should stop and rewind.
john
John Atkinson
Webseen Ltd
e.mail:jo...@webseen.co.uk
Please visit our on line Computer Museum
http://www.punch-card.co.uk
Joe Morris
>Joe Morris wrote:
The 729 had lever-action locks, and my memory says that the 7330 had
the same design...at least I don't recall that there was any difference
between the two hub designs.
Both the 729 and 7330 had rotary switches to set the unit number. (Readers
not familiar with this should think of a SCSI bus, where each device
has a switch or jumpers to specify what address it will use.) The
7330 used a dial with a horizontal shaft (the operator turned the knob
until the desired unit number (0-9, or "offline") was under the index
mark at the top; the 729 dial had a vertical shaft and a large (6"
diameter?) dial that would show one back-lit unit number in a window
at the top of the drive, or a blacked-out sector for "offline". The
729 dial had lots of inertia and little drag, so you could give it
enough of a push that it would continue moving for one or two unit
numbers after you removed your finger from the dial.
I'm not sure that I would call the 7330 a predecessor of the
729; there were many 729 models dating back to the 1950s. I can't
say, however, that the 7330 isn't an earlier machine type; can
anyone here comment? (The 7330 had miniscule, horizontal vacuum
columns, max recording density of 556 bpi, a blazing 15 inches/second
tape speed, and no ability to do a high-speed rewind except when
given a rewind/unload command. The later 729 units had long
vertical columns, 800 bpi density, 200 ips tape motion, and used
a photocell to detect the amount of tape on the takeup spool, which
allowed it to automagically pull the tape from the columns and do a
reel-to-reel rewind until near the front of the tape, at which point
the tape would be reloaded into the columns and moved backwards to
the BOT point at 200 ips.)
Joe Morris
Alexandre Pechtchanski
[ snip ]
>How about a tape where the labels were in EBCDIC but the
>data was in ASCII!
I believe this was a standard IBM format for OS/360 when ASCII flag was set.
--
[ When replying, remove *'s from address ]
Alexandre Pechtchanski, Systems Manager, RUH, NY
Joe Morris
>I don't recall tapes in EZ-Load seals having the crimps, but that may
>just be faulty memory. Either that, or our operators thought it was
>damage and clipped 'em. After all, the (manual load) TA81s
The crimper would cut the end of the tape in an arc, with short (maybe
1/4"?) crimps that (I always assumed) were there to prevent the tape
from adhering to the guide blocks. My memory says that the crimps
were very light and could easily be overlooked by someone not expecting
them.
Joe Morris
Joe Morris
>As a CE Trying to explain this to customers especially with input tapes
>from an unknown source sometimes became a real problem. As far as
>operators were concerned and there managers if it had en EOT mark on it
>then the the tape should stop and rewind.
...to which the response should have been "RTFM". At least for the
IBM gear this was explicitly covered in the documentation: if the
drive detected the EOT marker during a write operation the drive
would signal that event to the system, but on read operations there
was no notification. The assumption was that the OS should respond
to the signal by writing the appropriate EOT records and close the
tape; since these records would (by definition) exist beyond the EOT
marker the drive cannot be designed to abort read operations when the
drive sees the marker. On read, the OS was responsible for recognizing
the EOT records and not issuing additional read commands that would
pull the tape off the supply reel.
Of course, this doesn't explain why the designers couldn't have put
a deadman timer into the logic to detect a runaway tape, but that's
a slightly different question. IBM's Hypertape drive (7340?) used
cartridges, and had not only BOT and EOT reflective strips, but
also EOR (End of Reel) strips that when detected immediately stopped
the drive regardless of what operation was in progress.
Joe Morris
Terry Kennedy
> ...to which the response should have been "RTFM". At least for the
> IBM gear this was explicitly covered in the documentation: if the
> drive detected the EOT marker during a write operation the drive
> would signal that event to the system, but on read operations there
> was no notification. The assumption was that the OS should respond
> to the signal by writing the appropriate EOT records and close the
> tape; since these records would (by definition) exist beyond the EOT
> marker the drive cannot be designed to abort read operations when the
> drive sees the marker. On read, the OS was responsible for recognizing
> the EOT records and not issuing additional read commands that would
> pull the tape off the supply reel.
That's all fine. But there should have been a validity check signaled if
no recoverable data was found within about 50' of the load point, which
would fix both the "reading a blank tape" and "reading a tape written in
an incompatible density/mode" problems.
> Of course, this doesn't explain why the designers couldn't have put
> a deadman timer into the logic to detect a runaway tape, but that's
> a slightly different question.
Indeed. But actual runaways (aside from the blank/incompatible tape
ones) were quite rare, and when they happened, it was usually some sort
of hardware problem in the transport and a timer might not have been
able to stop them anyway.
John W Hall
Morris) wrote:
>I'm not sure that I would call the 7330 a predecessor of the
>729; there were many 729 models dating back to the 1950s. I can't
>say, however, that the 7330 isn't an earlier machine type; can
>anyone here comment?
IIRC the 7330 was introduced about 1962 or 3
It wasn't a predecessor of anything, thank goodness. It's main,
probably only, claim to fame was CHEAP! When moving tape backwards,
the capstan pushed the tape back over the head, relying on the left
vacuum column to pull it across. Setting tape skew (aka azimuth
alignment) was a bugger on those.
Didn't the reel hubs have screw-up tightening knobs? Some tape drive
models did but not sure it was these. Anyway they occasionally got
over-enthusiastically tightened and stripped the threads.
Julian Thomas
>I'm not sure that I would call the 7330 a predecessor of the 729; there
>were many 729 models dating back to the 1950s.
Er - I think that the 50's drives were for the most part 727's [seen on
70x and 650] - the 729's may have come in very late in that decade with
the transistorized machines [14xx, 709x, 708x, 707x, ...].
And the 7330 almost certainly postdated the 729 - on the basis of the 4
digit number if nothing else!
--
Julian Thomas: jt . epix @ net http://home.epix.net/~jt
remove letter a for email (or switch . and @)
In the beautiful Finger Lakes Wine Country of New York State!
Boardmember of POSSI.org - Phoenix OS/2 Society, Inc http://www.possi.org
WarpTech 2000: May 26-28 in Phoenix - plan NOW to attend! www.warptech.org
-- --
Headline: Energizer Bunny arrested, charged with battery.
Charlie Gibbs
(Adrian Lumsden) writes:
>That reminds me of a story that I heard about a user who had tried to
>load a tape and couldn't get it to load.
>
>The operator went along and found, in the end, that the tape was inside
>out on the spool!
[story snipped]
Who remembers back-coated tapes? Some tapes had a coating of oxide
on the back side as well as the active, data-recording side. This
was believed to improve the magnetic characteristics of the tape,
or something like that. Since the back coating never came in contact
with the heads, it didn't have to be polished like the active coating,
and therefore was a lot duller.
This led to an interesting story. On normal (i.e. non-back-coated)
tapes, the back side of the tape - being bare Mylar - is shinier than
the oxide side. This can provide a quick way of identifying which
side of the tape is which: the drive reads and writes the dull side.
With back-coated tape, on the other hand, the opposite is true.
We once prepared a tape for an unfriendly customer. I think he
was leaving our service bureau and we were giving him back his
data. The tape to which we wrote his data happened to be back-coated.
Apparently the customer looked at the tape and saw that the outside
of the tape on the reel was dull. I don't know what he was thinking -
maybe he suspected that we were out for revenge - but somehow he came
to the conclusion that we had deliberately rewound the tape inside-out
on the reel. So he painstakingly wound the tape by hand and flipped
it - and then gave us an irate phone call when he couldn't read it.
--
cgi...@sky.bus.com (Charlie Gibbs)
Remove the first period after the "at" sign to reply.
Charlie Gibbs
(glen herrmannsfeldt) writes:
>Mounting a blank tape when the machine expects either SL or NL
>(standard label or no label) results in tape off the end of the reel.
>When asked to read, it will read until it finds data, ignoring the EOT
>strip.
The opposite case can be interesting too - when the photocell is
misadjusted so that it's so sensitive that it gets a reflection
off the shiny Mylar backing of the tape and thinks it's detected
an EOT marker. (This won't happen on back-coated tapes - see my
previous message.)
Charlie Gibbs
jmay...@thebrain.conmicro.cx (Jay Maynard) writes:
>I'm pretty sure I can do the 3420 equivalent, even today, though:
>thumb the door safety strip to open the door, slap the autoloading
>reel (with a cover the drive can open automagically) in place, hit
>RESET/LOAD/READY (which were in a right/left/right sequence), walk
>away...
The 1980-vintage Uniservo 10s and 14s were even easier: mount the
reel and hit LOAD. And they could even do it with bare reels.
>...and, occasionally, walk back when the autoload fails.
Well, um, yes...
David Scheidt
: The 1980-vintage Uniservo 10s and 14s were even easier: mount the
: reel and hit LOAD. And they could even do it with bare reels.
Some late-80's[1] 9 track drive that I had to use a couple years
ago was drawer loading, with no removable take-up reel. You yanked
the drawer open, stuck the tape on the right way, and closed the
drawer. I don't know what you'd do with a load failure: I didn't
have one in a hundred or two tapes.
[1] Judging by the machine that the drive was attached to, an early HP
9000/800. It wasn't an HP drive, but I don't remember what it said.
--
dsch...@enteract.com
You could look at our current gun laws as a way of ensuring that
British armed criminals are really *motivated*.
-- Phil Edwards
Jim Thomas
Joe> Of course, this doesn't explain why the designers couldn't have
Joe> put a deadman timer into the logic to detect a runaway tape, but
Joe> that's a slightly different question.
'cause it was a software problem :-) If the OS insisted on trying to read
blank tapes .... :-) :-)
(yes, I know why :-)
Nothead
Jim Thomas
David> Some late-80's[1] 9 track drive that I had to use a couple years
David> ago was drawer loading, with no removable take-up reel. You
David> yanked the drawer open, stuck the tape on the right way, and
David> closed the drawer. I don't know what you'd do with a load
David> failure: I didn't have one in a hundred or two tapes.
David> [1] Judging by the machine that the drive was attached to, an
David> early HP 9000/800. It wasn't an HP drive, but I don't remember
David> what it said.
HP had one called the 7980. On a failure one pulled out the drawer, pried
loose the clear plastic cover, and undid the damage. (I just went to the
back and checked the model number :-)
Nothead
David Scheidt
:>>>>> "David" == David Scheidt <dsch...@enteract.com> writes:
: David> early HP 9000/800. It wasn't an HP drive, but I don't remember
: David> what it said.
: HP had one called the 7980. On a failure one pulled out the drawer, pried
: loose the clear plastic cover, and undid the damage. (I just went to the
: back and checked the model number :-)
We had some of those here until recently. There were a couple models, with
different densities supported. This was a different machine, but similiar.
It was faster than the HP drives that shop had, though.
--
dsch...@enteract.com
That's why I use emacs. I'm a lisp freak. There's no lisp interpreter in vi,
that's why it's fast, small and not a memory hog.-- Ingvar the Grey in the SDM
Charlie Gibbs
(Joe Morris) writes:
When I was in a shop that didn't have a crimper, I could still cut a
very nice arc with the nail clipper that I still have on my key ring.
I only came across a couple of cases where the drive really wanted
the end of the tape to be crimped, and I think I just crumpled it
in my fingers a bit to get the desired result.
Don Stokes
>d...@news.daedalus.co.nz (Don Stokes) writes:
>
>>I don't recall tapes in EZ-Load seals having the crimps, but that may
>>just be faulty memory. Either that, or our operators thought it was
>>damage and clipped 'em. After all, the (manual load) TA81s
>
>The crimper would cut the end of the tape in an arc, with short (maybe
>1/4"?) crimps that (I always assumed) were there to prevent the tape
>from adhering to the guide blocks. My memory says that the crimps
>were very light and could easily be overlooked by someone not expecting
>them.
We had tape cutters that did the arc cut, but I can't for the life of me
recall if they did anything else to the tape. I dimly recall folding
tapes a certain way to convince them to load, but that may just be my
overactive imagination too. Hey, I was a sysprog, not a tape ape.
(Sysprogs got to play in the machine room and load our own tapes, being
careful to check with the operators first (unless it was an emergency
of course). Ordinary programmers, like other lower forms of life, had
to grovel to the operators to get their tapes mounted. The difference
of course being that operators were unlikely to need to ring Little
Joey Programmer at 3am with a problem.)
-- don
Jay Maynard
> The difference
> of course being that operators were unlikely to need to ring Little
> Joey Programmer at 3am with a problem.)
Your shop didn't do much, did it?
Our applications types got more 3 AM phone calls than the systems types did.
I worked very, very hard to keep it that way...and no, not by sabotaging
applications, either. :-)
Don Stokes
>On Thu, 18 May 2000 01:12:28 GMT, Don Stokes <d...@news.daedalus.co.nz> wrote:
>> The difference
>> of course being that operators were unlikely to need to ring Little
>> Joey Programmer at 3am with a problem.)
>Your shop didn't do much, did it?
>Our applications types got more 3 AM phone calls than the systems types did.
Oh, the *users* might ring the programmers. Just not the operators.
We did have a night shift, although they tended to be more independantly
minded than the day workers, and rather inclined to hack stuff
themselves. This was a printing shop (a Government Printing Office, not
some back street printery), and there is no way on earth to stop
printers from fiddling with stuff. 8-) Programmers just learned to
live with this.
-- don
Jay Maynard
>>Our applications types got more 3 AM phone calls than the systems types did.
>Oh, the *users* might ring the programmers. Just not the operators.
As I said...
The shops I worked at tended to have fairly heavy batch applications loads
on second shift, and running well into third shift; when things blew up, the
first thing the operators would do would be to call the on-call programmer.
I got the operators trained well enough that they didn't accept the
programmer's demand to bring the systems folks in on the problem unless it
really did look like a systems problem.
Joe Morris
>(Sysprogs got to play in the machine room and load our own tapes, being
> careful to check with the operators first (unless it was an emergency
> of course). Ordinary programmers, like other lower forms of life, had
> to grovel to the operators to get their tapes mounted. The difference
> of course being that operators were unlikely to need to ring Little
> Joey Programmer at 3am with a problem.)
<chuckle>
That's actually a quite accurate observation but doesn't go far enough:
the sysprogs were the only people who could legitimately come in and
run their own (sometimes stand-alone) programs. With the hideously
high cost to run the old mainframe computers it just wasn't financially
possible for any but the best-funded users to justify the cost of
dedicated time. I'll admit that it was fun but there was the distinct
advantage to the computer center in having the sysprogs act as their
own operators: they had a chance to see the system from the operators'
viewpoint and sometimes rewrite parts of the system to improve the
opertor interface.
It was also useful in that the sysprogs were often in a good position
to work with the better Field Circus types when trying to figure out
the solution for problems that couldn't immediately be identified as
coming from software or hardware.
Joe Morris
Joe Morris
> Indeed. But actual runaways (aside from the blank/incompatible tape
>ones) were quite rare, and when they happened, it was usually some sort
>of hardware problem in the transport and a timer might not have been
>able to stop them anyway.
There was one application (task, not program) where you could be assured
of a runaway if you were lucky: copying an unlabeled tape where you
had no idea of how many files it contained. You started a raw tape-to-tape
copy utility, then waited until the source drive went into runaway mode
and then hit the RESET button.
There was always the possibility that the source tape was completely
full (meaning that the EOT strip had been detected when it was being
written). In this case the "TAPE INDICATE" lamp would light up as
the reflective strip was detected (but as noted in a previous posting,
the CPU would not receive an indication of this); an experienced
operator would have noted that the source tape was nearing its end
and would have a couple of seconds to hit RESET before the end of
the tape came off the supply spool. In practice the copy task was
successful in this case because the last of the source tape data
would have already passed under the read head before the operator
could press RESET even if a finger was already resting on the button.
Joe Morris
Joe Morris
>jmay...@thebrain.conmicro.cx (Jay Maynard) writes:
>>I'm pretty sure I can do the 3420 equivalent, even today, though:
>>thumb the door safety strip to open the door, slap the autoloading
>>reel (with a cover the drive can open automagically) in place, hit
>>RESET/LOAD/READY (which were in a right/left/right sequence), walk
>>away...
>The 1980-vintage Uniservo 10s and 14s were even easier: mount the
>reel and hit LOAD. And they could even do it with bare reels.
The 3420 would do an autoload quite happily (usually) with or without
an autoload ring; the advantage of the special ring was that the
operator never had to take the time to remove or reinstall the ring.
With a normal ring the operator had to unclip the ring, put it somewhere
out of the way (supply companies sold clips that could be glued to the
front of the tape drive cabinet), put the reel on the hub, and then spin
the tape to position the end of the tape at about 5:00 to 6:00; with
autoload rings the operator just put the tape on the hub.
Joe Morris
Tim Shoppa
You assume that the reels of tape are exactly the same in length - this
is pretty true, the major tape manufacturers rarely give you much more
than required. But you also assume that the tape drives are adjusted
precisely to the correct density, which isn't always true. It's not
uncommon to find a few percent variation in data density between drives
- this is well within the tolerance of the data separators, but
if you're copying one truly full input tape to a same-length output
tape, you may well find that it doesn't all fit.
When this happens, I just interchange the input and output drives,
and viola!, it fits with a few feet leftover :-).
Tim.
Stephen H. Westin
<snip>
> Who remembers back-coated tapes? Some tapes had a coating of oxide
> on the back side as well as the active, data-recording side. This
> was believed to improve the magnetic characteristics of the tape,
> or something like that.
I think it was supposed to improve winding behavior, preventing
bunching and crinkling. With audio tapes, I think it also reduced
print-through, the transfer of the magnetic field from one later of
tape to the next.
<snip>
--
-Stephen H. Westin
Any information or opinions in this message are mine: they do not
represent the position of Cornell University or any of its sponsors.
Tim Shoppa
> Who remembers back-coated tapes? Some tapes had a coating of oxide
> on the back side as well as the active, data-recording side.
Remember? Lots of places still use 'em! Scotch/3M/Imation 700
Blackwatch 1/2" tape is the best of them all, and still manufactured
and sold today.
> This
> was believed to improve the magnetic characteristics of the tape,
> or something like that.
700 Blackwatch is the most expensive tape on the market, but also the
best. I've run several tens of thousands of customer's tapes through
here, some of them up to 40 years old, and far and away 700 Blackwatch
is the best. It never ever gums up, unlike other manufacturer's
premium brands.
(I don't think Blackwatch actually became backcoated until the
mid-Lasnerian-70's, before that it was just 3M's top-of-the-line tape).
Note that some particularly cheap tape transports supposedly have
problems with backcoated tapes. I've never had any problems, in
fact they are far and away my favorite tapes.
--
Tim Shoppa Email: sho...@trailing-edge.com
Trailing-Edge Technology WWW: http://www.trailing-edge.com/
7328 Bradley Blvd Voice: 301-767-5917
Bethesda, MD, USA 20817 Fax: 301-767-5927
Kevin Handy
David Scheidt wrote:
>
> In alt.sys.pdp10 Charlie Gibbs <cgi...@sky.bus.com> wrote:
>
> : The 1980-vintage Uniservo 10s and 14s were even easier: mount the
> : reel and hit LOAD. And they could even do it with bare reels.
>
> Some late-80's[1] 9 track drive that I had to use a couple years
> ago was drawer loading, with no removable take-up reel. You yanked
> the drawer open, stuck the tape on the right way, and closed the
> drawer. I don't know what you'd do with a load failure: I didn't
> have one in a hundred or two tapes.
>
> [1] Judging by the machine that the drive was attached to, an early HP
> 9000/800. It wasn't an HP drive, but I don't remember what it said.
Sounds like Digital's TS05 (a cyber?) tape drive. Also saw an almost
identical drive on a MicroData. Usually when it fails to load a tape,
you clip off a couple of inches of the end of the tape (if it's
thrashed)
and try again.
I have had some nasty failures on mine. On the internal take up reel
there is an arm that holds a small roller against the take up reel
(to hold the tape in place and add some tension I'd guess).
One time it loaded the tape around the back side of the tension
roller, then around the take up spool. Several layers of tape on
the reel, and it was jammed up extremely tight.
Bob Schor
the door, lay the tape in, and push LOAD. It is fun to open them up and
watch how the load procedure works -- first it locks down the tape reel
(by turning backwards, I think, with a solenoid activated to catch a
"lock-down" tab that squeezes on an O-ring to expand it to grab the reel
from the inside of the hub), then turns the tape forward several turns,
while blowing air to get the end of the tape flapping in the breeze. It
then starts turning the tape backwards, now sucking tape towards the
take-up reel (which is also spinning). Once it has captured the tape on
the takeup reel and has a really solid grip (several turns of tape), the
tension arms come down, tape is moved foward for a while (to get past the
load point), then finally a rewind is initiated to position the tape.
When I've seen it fail, it has always been in Step 1, locking the
tape onto the drive hub.
Bob Schor
David Scheidt wrote:
> In alt.sys.pdp10 Charlie Gibbs <cgi...@sky.bus.com> wrote:
>
> : The 1980-vintage Uniservo 10s and 14s were even easier: mount the
> : reel and hit LOAD. And they could even do it with bare reels.
>
> Some late-80's[1] 9 track drive that I had to use a couple years
> ago was drawer loading, with no removable take-up reel. You yanked
> the drawer open, stuck the tape on the right way, and closed the
> drawer. I don't know what you'd do with a load failure: I didn't
> have one in a hundred or two tapes.
>
> [1] Judging by the machine that the drive was attached to, an early HP
> 9000/800. It wasn't an HP drive, but I don't remember what it said.
>
jchausler
"Stephen H. Westin" wrote:
> "Charlie Gibbs" <cgi...@sky.bus.com> writes:
>
> <snip>
>
> > Who remembers back-coated tapes? Some tapes had a coating of oxide
> > on the back side as well as the active, data-recording side. This
> > was believed to improve the magnetic characteristics of the tape,
> > or something like that.
>
> I think it was supposed to improve winding behavior, preventing
> bunching and crinkling. With audio tapes, I think it also reduced
> print-through, the transfer of the magnetic field from one later of
> tape to the next.
How about "sandwich" tape, where there is a thin coating of mylar
on the oxide side of the tape. Used for instrumentation environments
were there were many passes on the tape. I had a free source of this
stuff in college and many of my tapes were made this way. I had no
problems with it on all half inch drives I used (IBM, UNIVAC, DEC)
but I also used some 1 inch stuff and there I had to "select" the drive
(or quietly turn up the write currents, something to be done shortly
after the CE's "tuned up" the drive :-)
Chris
AN GETTO$;DUMP;RUN,ALGOL,TAPE
$$
Charlie Gibbs
tho...@atlas.cfht.hawaii.edu (Jim Thomas) writes:
>>>>>> "David" == David Scheidt <dsch...@enteract.com> writes:
>
>David> Some late-80's[1] 9 track drive that I had to use a couple years
>David> ago was drawer loading, with no removable take-up reel. You
>David> yanked the drawer open, stuck the tape on the right way, and
>David> closed the drawer. I don't know what you'd do with a load
>David> failure: I didn't have one in a hundred or two tapes.
>David>
>David> [1] Judging by the machine that the drive was attached to, an
>David> early HP 9000/800. It wasn't an HP drive, but I don't remember
>David> what it said.
>
>HP had one called the 7980. On a failure one pulled out the drawer,
>pried loose the clear plastic cover, and undid the damage. (I just
>went to the back and checked the model number :-)
Unisys offered a rebadged Cipher streaming tape unit on their systems.
It sounds similar; you'd stuff a reel into the slot in the front and
hit the load button and away it'd go (usually). It ran at about 100
inches per second in streaming mode - which made it a great backup
device - and something like 12.5 ips in start-stop mode, which meant
that you could read and write standard 1600-bpi 9-track tapes, albeit
slowly.
Peter da Silva
David Scheidt <dsch...@enteract.com> wrote:
>Some late-80's[1] 9 track drive that I had to use a couple years
>the drawer open, stuck the tape on the right way, and closed the
>drawer. I don't know what you'd do with a load failure: I didn't
>have one in a hundred or two tapes.
Sounds like an ancestor of the single-reel cartridge tapes like the TK[57]0
and IBM's one that looked like a melted TK50.
Or maybe a collateral descendant.
--
Rev. Peter da Silva, ULC.
"The only thing worse than X is every other GUI in common usage today."
-- Chris Rovers
Mel Wilson
Tim Shoppa <sho...@trailing-edge.com> wrote:
>Note that some particularly cheap tape transports supposedly have
>problems with backcoated tapes. I've never had any problems, in
>fact they are far and away my favorite tapes.
Not only cheap ones. The standard tape drives I saw on GE-425's had
no pinch rollers: the tape was held against the large rubberized capstan
by tension from the vacuum bins. This was not enough to give the
capstan a grip on back-coated tapes. One customer got one batch of
Black Watch. You could sense the drive's frustration as it spun and
spun, and nothing moved. (Actually, I lie. Tape moved, but not
predictably enough. Lots of read-after-write failures.)
Regards. Mel.
Jay Maynard
>Sounds like an ancestor of the single-reel cartridge tapes like the TK[57]0
>and IBM's one that looked like a melted TK50.
The 3480 and 3490.
>Or maybe a collateral descendant.
Probably a collateral descendant; the 3480 was developed in the early 80s or
so, with first customer ship in 1983 (IIRC). The 3480 uses the same kind of
loading as the TK50, except that instead of a hook-the-hole arrangement, it
had a clip on the end of the tape that was pulled in and around by a pin,
and so didn't have the problems the TK50 occasionally did with load failure
because the hook was out of place. I don't recall a load failure, ever, on a
3480 that didn't have worse problems as well.
The 3480 also didn't use the serpentine recording of the TK50 and
descendants. It had 18 tracks (the 3490 has 36), and made at most two passes
over the tape (one forward, one backward) (I'm fuzzy if it did that, or
simply wrote all n tracks at once).
Simo Tuominen
<johnf...@sprintmail.com> wrote:
>Rude? Rude is two load point stickers!
Rude is also quoting the whole article, and adding one line of your
own text. There's also no reason to put your text *before* the quoted
text in this age, *especially* when you put a non-McQ-compliant
signature *after* the quoted text. 7 lines with text and two blanks?
Reformat and cram that in four.
Dave
Pechtchanski <alex*@*rockvax.rockefeller.edu> wrote:
> On 16 May 2000 21:22:43 -0500, Dave <Nu...@Business.net> wrote:
> [ snip ]
>
> >How about a tape where the labels were in EBCDIC but the
> >data was in ASCII!
>
> I believe this was a standard IBM format for OS/360 when ASCII flag was
> set.
Perhaps it was. I just remember seeing it only once and thinking "OK,
now I've seen everything!" :-)
Dave
Tony Yule
><johnf...@sprintmail.com> wrote:
>
>>Rude? Rude is two load point stickers!
>
inch tapes with two load point stickers. This was before the days of
tape labels and the local software had been modified to include a tape
label between the two stickers.
An alternative magnetic tape horror story was when I took a tape of
programs to America from Europe and gave it in to the operator for batch
processing. On the back of the tape there was a large yellow label with
the instructions that this tape was not to be overwritten. I was told
to place it in this position as the operator would see the message if an
attempt was made to place a write ring in the tape.
After a number of failures in reading the tape I got a system programmer
to inspect the tape from the console and he told me that the data at the
start had been overwritten. When I mentioned the yellow label he
laughed and said that if some program wanted to write to a write
protected tape the operator would just slip a punched card behind the
tape to trip the write protect sensor. After that I placed labels on
the front and rear of the tape.
--
Tony Yule
e-mail: apyule@b_c_s.org.uk (Remove _ if replying by e-mail)
God made the integers, man made the rest. (Leopold Kronecker)
John Santos
says...
> Rude? Rude is two load point stickers!
>
From bitter experience - Jeez, that's hard to debug!
> --
> John Ferrell in Julian NC, de W8CCW
--
John Santos
Jim Thomas
All of the following is gleaned from "Early IBM Computers".
"introduced" may mean designed, announced, or delivered.
726: introduced 1953 with the 701. Used pinch rollers. Ran 75ips, 100bpi,
NRZI. Had read backwards - no following tape did until 7340.
727: introduced Sep 1953 with 702. Ran 200bpi. First with LRC.
729: introduced Jan 1957 with 709. Had two gap head with read after write
and 2 level read.
729-II: introduced 1960. Ran 556bpi.
729-III: introduced 1960. Ran 112.5ips.
729-IV: introduced 1960. Ran 200/556bpi - -II and -III were 556 only.
729-V,VI: introduced Sep 1961. Ran 200/556/800bpi.
7330: introduced mid 1960 a year after the 1401 for the 1401. IIRC ran
75ips and 200/556bpi. The book says "smaller, less expensive, and slower
than the 729."
TRACTOR: introduced 1962 with the Harvest (a Stretch 7030 for NSA). Used
1 3/4" tapes, 22 tracks, 2 8-bit bytes per "position", hamming codes,
demarcation track, 2 capstan rollers, cartridges, 3000bpi, deskew buffer.
7340 (HyperTape): introduced Aug 1961. Based on TRACTOR technology. Used
1" tapes, 1500bpi PE, 10 tracks, 8-bit bytes with 2 error bits, 112.5 ips.
First tape since 726 to do read reverse. First single capstan drive.
--------------
Tapes on the 701 and 704 used odd parity so they could to binary more
easily. Tapes on the 702 and 705 used even parity because there would
always be at least 2 bits on in each character, and error detection was
better. The 702 and 705 were commercial, byte oriented systems and did not
need to record binary data.
Did anyone remember what character got written for a blank on an even
parity tape? Does anyone remember what character got used for a word mark
on load mode tape writes?
Nothead
David Thompson
...
> Actually DECtape did work rather like a disk. DECtape was marked with a
> format track that was not overwritten in normal use, and was blocked
> into fixed-length segments. The blocks were analogous to
> cylindar/head/sector addressing on disks, and you could think of DECtape
> as disks, with disk-like file structures, but with VERY long and
> variable seek times.
>
I actually put a Unix (6ed) filesystem on a PDP-11 DECtape once,
having run completely out of space on the 2x RK05 = 2.5MB disk.
I could watch it seek to the i-list, read inode 1, seek to the root dir
and read it, seek back to the i-list and read, seek to data and read,
or seek to a free block and write, then seek back to update the
free list in the superblock, etc., etc. This got old real quick.
> Another flavor of tape, found in instrumentation systems and telco
> billing systems, was incremental tape. The magnetic tape was moved
> across the pole pieces of the write head by a stepper motor, and writing
> was done one byte at a time. One could use this same scheme to write
> gaps and tape marks for compatibility with normal 9-track tape (see
> below), so upon readback at a data center the tape would appear to have
> been written by a conventional tape drive. I don't know if anyone
> managed to put blocking and file systems on incremental tape, but would
> be interested in hearing from The Wider World if anyone had.
>
Not quite the same thing, but the first(?) wordprocessing system
from IBM around 1970 was an amazing thing called the Magnetic
Tape / Selectric Typewriter, built around (as you would expect)
a Selectric(undoubtedly tm), one of the nicest typewriters ever.
You could record keystrokes while typing, then play them back,
or play them back and re-record a new copy with changes,
rather like paper-tape on an ASR-model Teletype(tm).
The storage medium was a cartridge of transparent plastic
maybe 4 inches square by 1 inch containing a spool,
not too unlike a 3480/3490 except the inside was open and
fit over a drive hub like a standard 1/2" tape (or DECtape I).
The tape itself had sprocket holes like (and may actually
have been made from) 16mm movie film, which were used
to drive it one step at a time past the write and/or read station,
where an EM head mounted on a slider was driven laterally
across the tape once for each character transferred; I think
it was done by a clutched cam, but might have been a crank.
It sounded, and worked, like an industrial sewing machine,
and just kept up with the 15cps limit of the Selectric itself.
Like more modern devices, the tape had an eye on the end
which was autoloaded through the mechanism to a takeup reel
inside the drive, but you could easily pull it out manually.
After a few uses, you could see each character frame clearly
worn in the oxide; they were spaced about 2mm and I think
each tape was 50 or 100m giving 25 to 50kc -- maybe
a dozen pages of text. Probably 6bits/c but I don't know.
As far as I know there was never any compatibility between
this monster and any computer, although the Selectric
mechanism was used in the 2741 terminal and others.
--
- David.Thompson 1 now at worldnet.att.net
jmfb...@aol.com
Nope. They weren't. And because of this fact, our Release Engineering
people _always_ made their masters on "short tapes". The way they
did it was to pull many, many feet of tape off the tape that was
doomed to be a master and attach a new silver BOT.
> But you also assume that the tape drives are adjusted
>precisely to the correct density, which isn't always true. It's not
>uncommon to find a few percent variation in data density between drives
>- this is well within the tolerance of the data separators, but
>if you're copying one truly full input tape to a same-length output
>tape, you may well find that it doesn't all fit.
That's one of the computing laws of Murphy. It's guaranteed that
the one tape you pick for a master will be the longest tape
in the building.
>
>When this happens, I just interchange the input and output drives,
>and viola!, it fits with a few feet leftover :-).
Not a good procedure. :-)
/BAH
Ian Stirling
>In alt.sys.pdp11 Jay Maynard <jmay...@thebrain.conmicro.cx> wrote:
>> I can't speak to the TU77, but a busy mainframe shop with a couple of rows
>> of 3420s, using tapes with the 3420 seal, would only experience a load
>> failure a couple of times a shift. The secret was the seal: it was designed
<snip>
> A little-known fact is that the [no-longer-available] loader ECO kit for
>the TU78 also worked on the TU77. I had a row of 6 TU78's and 2 TU77's and
>load failures were a rarity.
>> Another thing that helped was the little tool IBM specified to trim the end
>> of the tape. It was operator-proof: you stuck the tape in the tool and
>> squeezed, and you got a nice round cut and a couple of little crimped
>> wrinkles in the end that made it easier to separate from the tape during
<snip>
> I have a crimper from Misco. A quick web look shows no Misco, and INMAC
>seems to be part of *Warehouse these days, so I don't know where you could
>get them.
Might http://www.misco.co.uk/ be part of the same outfit?
> te...@tmk.com Jersey City, NJ USA
--
http://inquisitor.i.am/ | mailto:inqui...@i.am | Ian Stirling.
---------------------------+-------------------------+--------------------------
Among a mans many good possessions, A good command of speech has no equal.
Terry Kennedy
> Might http://www.misco.co.uk/ be part of the same outfit?
Same logo, but their "Media" section doesn't even list 1/2" tape, so I
don't know if they'd have the crimper.
Terry Kennedy http://www.tmk.com