9 track data storage???????????????
Benn L. Lewis
Has anyone ever heard of a "9track tape" as data storage? we are
using TK50 here and want to get some database information from
the National Center for Health Statistics and that is all they can give us.
I was thinking that they are for IBM mainframes?????
thanks in advance...
-b...@fisher.psycha
ble...@eniac.seas
Daan Sandee
|>
|> Has anyone ever heard of a "9track tape" as data storage? we are
|> using TK50 here and want to get some database information from
|> the National Center for Health Statistics and that is all they can give us.
|> I was thinking that they are for IBM mainframes?????
Sigh. Not just for IBM mainframes. Nine-track tape was *the* standard
medium for inter-computer data interchange from the late sixties (when
IBM introduced it ; before that, 7 tracks were standard) until the early
eighties. I'm sure there are still PLENTY of mainframes around that use
it daily. Last time I've used such a tape was in 1989, on a system
(not by IBM) which as far as I know is still daily *writing* them.
How the world is changing ... there must be *millions* of reels of 9-track
tape still lying around, especially with seismic data, but maybe also plain
old archiving in the DP business, and here we get people on the net who
have never even heard of it. Have you ever heard of punched cards ? It's
a medium that became obsolete much longer ago.
(On the other hand, I don't know what "TK50" is, although I can guess.)
Daan Sandee san...@think.com
Thinking Machines Corporation
Cambridge, Mass 02142 (617) 234-5044
Douglas W. Jones,201H MLH,3193350740,3193382879
>
> Has anyone ever heard of a "9track tape" as data storage?
I knew that someday, the day would come! 9-track magnetic tape is an
industry standard that dates back to the mid 1960's and has been widely
used since then. I've used 9 track tapes on IBM, DEC, Modcomp, HP and
Sun machines. Our CS department here at Iowa has a 9 track drive on our
Sun server.
A 9-track tape is 1/2 inch wide, stored on reels that are up to about a
foot in diameter, with thousands of feet of tape per reel. Typically,
data is recorded at 400, 800, 1600 or 6250 bits per inch (you can guess
the age of a system by the lowest density it can deal with). The 9
tracks are used to record one byte plus parity, so bits per inch along
one track is also bytes per inch along the tape.
Essentially all large computer centers at universities will have at least
one tape drive that can read these things, and once you read it into your
mainframe, you can move it by local net to the machine you have.
Doug Jones
jo...@cs.uiowa.edu
Charles Lasner
>From article <83...@netnews.upenn.edu>, by ble...@eniac.seas.upenn.edu (Benn L. Lewis):
>>
>> Has anyone ever heard of a "9track tape" as data storage?
>
>I knew that someday, the day would come! 9-track magnetic tape is an
>industry standard that dates back to the mid 1960's and has been widely
>used since then. I've used 9 track tapes on IBM, DEC, Modcomp, HP and
>Sun machines. Our CS department here at Iowa has a 9 track drive on our
>Sun server.
>
>A 9-track tape is 1/2 inch wide, stored on reels that are up to about a
>foot in diameter, with thousands of feet of tape per reel. Typically,
>data is recorded at 400, 800, 1600 or 6250 bits per inch (you can guess
>the age of a system by the lowest density it can deal with). The 9
>tracks are used to record one byte plus parity, so bits per inch along
>one track is also bytes per inch along the tape.
I don't know about 400, but there are a lot of newer drives that can do
3200 bpi. They are 1600 PE only the motors are at 1/2 speed. Rumor
has it that 6250 happened because 6400 was too fast for IBM's then
best 370-class model, so they slowed it down.
7-track drives can usually do 800, 552, and 200. These are six-bit bytes
with a parity.
There is also something about the lower-speed formatting that can get confused
if you write even-parity data zeroes, because it can't tell the data's there.
Perhaps someone can point out which formats are prone to this, because I think
some don't have the problem.
Many DEC systems support using all nine bits as data, since they are 18 or
36 bits wide.
cjl
Charlie Gibbs
las...@watsun.cc.columbia.edu (Charles Lasner) writes:
> Rumor
>has it that 6250 happened because 6400 was too fast for IBM's then
>best 370-class model, so they slowed it down.
Interesting. I always wondered whether IBM anticipated
further increases in density. That 6250 number looks suspicious;
try doubling it a few times. Maybe they foresaw densities of
100,000 bits per inch.
Charli...@mindlink.bc.ca
"I'm cursed with hair from HELL!" -- Night Court
Alan Greenberg
>>A 9-track tape is 1/2 inch wide, stored on reels that are up to about a
>>foot in diameter, with thousands of feet of tape per reel. Typically,
>>data is recorded at 400, 800, 1600 or 6250 bits per inch (you can guess
>>the age of a system by the lowest density it can deal with).
>7-track drives can usually do 800, 552, and 200. These are six-bit bytes
>with a parity.
Peter da Silva
>How the world is changing ... there must be *millions* of reels of 9-track
>tape still lying around,
We were using it for regular backups until fairly recently, and we've still
got a few tape drives for data transfer. I got some hot software on 9-track
as recently as 1989 (the Software Tools virtual operating system: sort of a
UNIX programming environment written in portable Fortran to run on
mainframes).
>(On the other hand, I don't know what "TK50" is, although I can guess.)
You don't want to know what a TK50 is. Probably the worst cartridge design
for tape transport ever.
--
`-_-'
Have you hugged your wolf today? 'U`
Peter da Silva, Taronga Park BBS, Houston, TX +1 713 568 0480/1032
zcoo...@cc.curtin.edu.au
> using TK50 here and want to get some database information from
> the National Center for Health Statistics and that is all they can give us.
> I was thinking that they are for IBM mainframes?????
>
>
>
9 Track probably still is the most common tape media around. I use it just about
every day on my '11. If you wish to port somthing to another site, it's pretty
likely that there's a 9 track close by - other media is just too likely to be
wrong.
And it's a hell of a lot less likely to eat the tape the way a TK50 would.
I one Put the bootable BRUSYS tape from DEC straight into a brand new TK50,
which promptly ate it. The DEC failed circus tech simply swapped the drive
over, and gave me a new tape - seems they keep a few around for just thoses
occasions.
Your best bet for a 9 track tape is a local UNI or maybe a large VAX site.
If you're in DECUS there'll be someone who will have one. If your not in
DECUS call your local DEC office and get a contact.
...BRU
Terry Kennedy, Operations Mgr.
> You don't want to know what a TK50 is. Probably the worst cartridge design
> for tape transport ever.
No, it's the drive that's brain-dead, the cartridges are fine 8-). Seriously,
the later implementations aren't bad. Consider the TZ30, which is a 1/2 height
5.25" drive that read/writes TK50's. It seems to be a lot faster, is certainly
a better mechanism, and doesn't self-destruct if you try to do things out of
sequence.
You'll be glad to know that there _is_ a CompacTape design that's worse than
the TK50, though - the TK50 prototype! On the production TK50 you at least have
the green LED that tels you something is happening. On the prototypes, that LED
doesn't exist, so all you have is the red button.
We had one of the first MVII/BA123/TK50 systems delivered. We got the tape
jammed in the TK50 on the very first try. We called Field Service, who came out
and refused to clear it on the basis that "it couldn't be a DEC product - DEC
wouldn't make a piece of junk like that". Uh-huh.
Terry Kennedy Operations Manager, Academic Computing
te...@spcvxa.bitnet St. Peter's College, Jersey City, NJ USA
te...@spcvxa.spc.edu +1 201 915 9381
Don Stokes
> You don't want to know what a TK50 is. Probably the worst cartridge design
> for tape transport ever.
You mean only a bit more reliable than 8mm?
I've used TK50s for years, admittedly not beating them up for the main
backups (we used 9track), but I'm yet to see a TK50 fail, or even fail to
load. I've seen *lots* of 9tracks fail to load, or crap out in various
interesting ways.
For low-speed, low volume storage, TK50s aren't too bad.
Now, the TU58 is something that should never have happened.....
--
Don Stokes, ZL2TNM (DS555) d...@zl2tnm.gen.nz (home)
Network Manager, Computing Services Centre d...@vuw.ac.nz (work)
Victoria University of Wellington, New Zealand +64-4-495-5052
Sarr J. Blumson
>
>if you write even-parity data zeroes, because it can't tell the data's there.
>Perhaps someone can point out which formats are prone to this, because I think
>some don't have the problem.
>
phase encoding) use a Non Return to Zero scheme where a one bit is a
flux change and a zero bit is nothing. Since there is no independent
timing information on the tape a long string of zeros can cause loss
of synchronization. I may have the details fuzzy but this is the idea
anyway.
Run Length Limited disk controllers are run length limited for a
similar reason.
Returning briefly to the original questionon, 9 track drives for just
about anything ("ISA" machines even) are easilt found in the small
adds in the back of glossy mags like Byte.
(Sarr Blumson)
Gregory R. Travis
>A 9-track tape is 1/2 inch wide, stored on reels that are up to about a
>foot in diameter, with thousands of feet of tape per reel. Typically,
>data is recorded at 400, 800, 1600 or 6250 bits per inch (you can guess
>the age of a system by the lowest density it can deal with).
Ahh, yessssss... I don't remember any 400BPI 9-tracks, but I certainly
remember 200 and 552 (or was it 556? My memory fades...)BPI 7-tracks!
Ahh, almost 6MB on a 2400 foot reel.
Ahh, ahh, ahh. Back when men were men and disk drives were electro-hydraulic.
I remember, as a young kid, forgetting to clamp down the hub lock on a
7/9 track tape on a CDC tape drive (forgot the model, but it was one of the
old ones with a manual door and loading procedure). That tape spun around
in there and took out quite a bit of hardware with it. I never forgot
the hub lock after that.
I still have a bunch of 9-tracks in the back of my car...
greg
--
Gregory Reed Travis D P S I
Data Parallel Systems Incorporated gr...@dpsi.com (For MX mailers only!)
Bloomington, IN gr...@indiana.edu (For the others)
Don Stokes
> No, it's the drive that's brain-dead, the cartridges are fine 8-). Seriously,
> the later implementations aren't bad. Consider the TZ30, which is a 1/2 height
> 5.25" drive that read/writes TK50's. It seems to be a lot faster, is certainly
> a better mechanism, and doesn't self-destruct if you try to do things out of
> sequence.
You noticed that too, huh? The spex say that the TZ30 and TK50 are the
same performance wise, but the SCSI/TZ30 "feels" a *lot* faster than
the TQK50/TK50 combo. Maybe loading a tape is faster (it's dreadfully
slow on a TK50), maybe the overall read-data-pass-to-controller-stuff-
into-memory process is faster ("inches per second" doesn't tell the
whole story) or maybe it's just that the TZ30 makes different noises in
a quieter box, so just sounds faster (although the DECmate IIIplus chassis
my TK50 s mounted inside is even quieter than the average VAXstation).
I felt that the TK50-Z (TK50 drive with SCSI interface in an external
box) was just as slow as a normal TK50.
Ever tried booting Standalone Backup off TK50? You get time not only
to eat dinner, but to cook it as well. But it's still not as bad as
doing anything with a TU58....
Don Stokes
> And it's a hell of a lot less likely to eat the tape the way a TK50 would.
I dunno. I saw a lot of imaginatively munched tapes in 9-track drives.
I used a TA79 a lot -- it was much more reliable than the two TA81s it
superseded put together, but when it decided to fail it would do so properly.
for example, it would fold the tape over on the take-up spool and jam.
The operator would try to rewind the tape, at which point it would spin
the reels in such a way that the tape was pulled in opposite directions,
whipping out of the vacuum columns and finally going taut at about the
stage where both reels had got to full speed. The tape would of course
snap, leaving the operator to undo the resulting mess, untangle the tape
from the take-up spool and manually re-thread the snapped tape onto the
reel to be rewound. The drive was very choosey about what it ate in this
fashion, preferring archive tapes and operating system releases over the
common old backup tapes....
Another fun failure mode was to wrap tape several times around an air
bearing in such a way that the roller type bearing was jammed tight and
the tape had to be hacked out with a knife. It wasn't obvious how this
had occurred.
At a different site I once saw an operator stagger back from a TA78 drive,
totally covered in tape. I'm not sure quite what happened there....
An IBM 9track drive we had on a System/38 (that I fortunately had nothing
to do with) would actually flip the tape over on its way from one reel
to the other.
Joe Morris
[the subject is 9-track industry-standard tape drives]
> Rumor
>has it that 6250 happened because 6400 was too fast for IBM's then
>best 370-class model, so they slowed it down.
You're confusing tape density with data transmission rate. Density (6250
fci in this case) represents the number of bytes which can be stored in one
linear unit (inch) of tape. Transmission speed (which is the limiting
factor in the channel or CPU architecture) is density times tape speed.
You can have an incredibly dense recording density combined with an
incredibly slow transport speed.
The most common tape speeds are 75, 150, and 200 inches/second for
mainframe drives. (I'm talking about current, 9-track 1/2" drives
here, used on middle-sized and larger systems. Older units, and
boxes on small systems, are slower (I've worked with 15 ips drives...ugh)
and there are surely other speeds available if you want them.)
>There is also something about the lower-speed formatting that can get confused
>if you write even-parity data zeroes, because it can't tell the data's there.
>Perhaps someone can point out which formats are prone to this, because I think
>some don't have the problem.
That's one of the reasons that when you wrote binary data on a 7-track
drive you were expected to use odd parity. (9-track drives are always
odd parity; on 7-track drives you had a choice.) With NRZI encoding
this means that each character position on the tape includes at least
one flux change which can be used to recover the sync clock.
>Many DEC systems support using all nine bits as data, since they are 18 or
>36 bits wide.
Is this true for industry-standard 9-track tape? I can't say it isn't
since DEC occasionally designed products even more odd than usual, but
I never heard of it.
On a DECsystem-10 I used to be acquainted with we had a pair of 9-track
tape drives which were used to exchange data with the IBM systems. I don't
recall the DEC nomenclature for them (TU40??), but in real life they were
STC tape drives for an IBM system (including both the drives and the
associated control units -- functionally identical to IBM 3420's). A
special DEC interface (DX10??) converted Massbus signals into an IBM
selector channel which was then connected to the STC controller.
Joe Morris
Steve McKinty - Sun ICNC
>
> At a different site I once saw an operator stagger back from a TA78 drive,
> totally covered in tape. I'm not sure quite what happened there....
>
Maybe he opened the door while the tape was running flat out in mid-rewind?
(yes, I did. Once. That was enough...)
Steve
SCOTT I CHASE
>pe...@taronga.com (Peter da Silva) writes:
>> You don't want to know what a TK50 is. Probably the worst cartridge design
>> for tape transport ever.
>
>You mean only a bit more reliable than 8mm?
>
>I've used TK50s for years, admittedly not beating them up for the main
>backups (we used 9track), but I'm yet to see a TK50 fail, or even fail to
>load. I've seen *lots* of 9tracks fail to load, or crap out in various
>interesting ways.
>
>For low-speed, low volume storage, TK50s aren't too bad.
Sure. But who wants low-speed low-volume storage? Personally, I want
high-speed high-volume storage with very compact media. That's exactly
what 8mm drives give you. I can't image what life would be like with my
two 600 Meg hard drives if I had to back them up to TK50 like I did in
the old days when my only disk was a 60 Meg system disk.
And TK50 is far too slow for data aquisition. If you want to use your
VaxStation to collect data from an experiment (I'm a physics grad student),
TK50 is just a dog. Exabytes are the way to go. And they're much more
reliable than just a few years ago when the product first hit the market.
-Scott
--------------------
Scott I. Chase "The question seems to be of such a character
SIC...@CSA2.LBL.GOV that if I should come to life after my death
and some mathematician were to tell me that it
had been definitely settled, I think I would
immediately drop dead again." - Vandiver
Vadim Antonov
>A 9-track tape is 1/2 inch wide, stored on reels that are up to about a
>foot in diameter, with thousands of feet of tape per reel. Typically,
>data is recorded at 400, 800, 1600 or 6250 bits per inch (you can guess
>the age of a system by the lowest density it can deal with). The 9
>tracks are used to record one byte plus parity, so bits per inch along
>one track is also bytes per inch along the tape.
How strange. I always used the *highest* supported density to get
the idea of the device's age. I remember when 8 and 16 "impulses per
millimeter" tapes (about 200 and 400 bpi) were actually used. 32 ipm was
a big progress :-)
As for TK50 - it's a brain-dead DEC console cartridge tape (btw, it's
contoller can be switched to emulate the TS-11 9-track tape controller :-)
I guess it usually is. Unix tape interface is heavily infuenced by
pecularities of 9-track tape format (say, impossibility to write safely in the
middle of tape files or double tape mark as end-of-tape indicator) and
looks, hm, strange when applied to modern streaming tapes.
--vadim
Charles Lasner
>las...@watsun.cc.columbia.edu (Charles Lasner) writes:
>
> [the subject is 9-track industry-standard tape drives]
>
>> Rumor
>>has it that 6250 happened because 6400 was too fast for IBM's then
>>best 370-class model, so they slowed it down.
>
>You're confusing tape density with data transmission rate. Density (6250
>fci in this case) represents the number of bytes which can be stored in one
>linear unit (inch) of tape. Transmission speed (which is the limiting
>factor in the channel or CPU architecture) is density times tape speed.
>You can have an incredibly dense recording density combined with an
>incredibly slow transport speed.
No, the statement stands. At the time, IBM's fastest available drives were
rated for use with the new format when the appropriate controller was released.
6400 BPI was too fast for the channel. They would've had to disallow their
best drives from their best format, so they chose instead to deoptimize the
format so it would work with the existing drives and existing channel
processors and CPU's.
>
>>Many DEC systems support using all nine bits as data, since they are 18 or
>>36 bits wide.
>
>Is this true for industry-standard 9-track tape? I can't say it isn't
>since DEC occasionally designed products even more odd than usual, but
>I never heard of it.
DEC systems write a "private" image-mode format that takes advantage of all
bits. This format exists on the PDP-10, 15, and 8 at least. Can't say
about the -11, but I wouldn't be surprised. If you can access all 9 bits, you
can still write a tape for a wimpy 360 using 8-bit bytes with parity. But
only DEC machines could exchange the image-written data.
cjl
Robert Davis
>>
>> Has anyone ever heard of a "9track tape" as data storage?
>
would like any free samples, I have several dozen (probably more) in my
garage awaiting the day that I purchase a 9-track tape drive that will
work with one of my computers. However, their main purpose in life now
seems to be to collect dust, perhaps even some mildew. Their previous
purpose was to act as weight in my car's trunk during a heavy snow-storm
a few years ago; my previous employer had discarded them as unneeded surplus.
If anyone wants them, I'll consider letting them go, free, to a good home;
that is if you're willing to come and get them.... or pay all costs
pertaining to shipping, including my time to ship them out :-)
BTW, they make very good frisbees. Other uses include using them as
wrapping ribbons for Christmas packages, streamers, wall decorations,
adjustable-height (stackable) foot-rests, etc. The uses for these tapes
are unlimited! ...they're also useful for storing computer data.
--
============================================================================
Robert D. Davis |
rda...@jhunix.hcf.jhu.edu ! HELP! Martians have landed on
uunet!mystica!rdd | /dev/rfp021 and they're getting dizzy!
Charles Lasner
>
>As for TK50 - it's a brain-dead DEC console cartridge tape (btw, it's
>contoller can be switched to emulate the TS-11 9-track tape controller :-)
>I guess it usually is. Unix tape interface is heavily infuenced by
>pecularities of 9-track tape format (say, impossibility to write safely in the
>middle of tape files or double tape mark as end-of-tape indicator) and
>looks, hm, strange when applied to modern streaming tapes.
>
what it is, not "wrapped" by some standard access method or somesuch.
Except for overall performance I see little change in the basic premise of
magnetic tape devices. You can create block-replaceable areas using wide
gaps and are willing to have performance problems attempting to use it
as such. The most performance demands strictly sequential access which in
turn means that the data can't be random acess.
Tape streamers such as QIC-80 work the same way. A directory area is
reserved near the beginning which is rewritable due to the gap. The rest of
the data should be written in sequential fashion, and you have to stream
to get access to it, or suffer a turnaround penalty. In a sense, the
original 9-tracks were better because they didn't demand streaming if
used in start-stop mode. There are 9-track streamers that do all the
obligatory turn-arounds automatically if necessary, to ensure the data
gets written correctly, but the performance suffers if the streaming can't
continue.
cjl
Philip L. Gravel
On a related topic, did you hear that Paul McCartney was in another band
before "Wings"???? My, how time flies....
Pretty soon we'll hear question like:
Has anyone heard of a paper tape?
" " " " a punch card?
" " " " core memory?
Name your favorite artifact of a by-gone era....
Phil
-----
Philip L. Gravel Internet: pgr...@nap.amoco.com
Amoco Corporation, Chicago, IL Phone: (312)856-3553
----------
These opinions aren't worth the paper they're written on and
certainly don't reflect those of my employer.
Mac Horn
[... stuff deleted ...]
>At a different site I once saw an operator stagger back from a TA78 drive,
>totally covered in tape. I'm not sure quite what happened there....
I once saw a possible explanation - an operator at one of those
movie-style rows of IBM tape units, madly changing 2400 ft reels.
Operator dashes from one drive to the next, whips off old reel, loads on
new reel, dashes to next drive ... Unfortunate co-ordination error -
operator fails to undo hub lock before grasping reel by both rims and
pulling hard. Result - rims fall off hubs, and 2400 feet of half inch
tape cascades to the floor - and I mean cascades - it just flowed like a
bucket of water, leaving the operator ankle deep in tape, and the
machine room waist deep in rude language. I wonder what happened to
that particular credit union's transaction logs that day ??? ;-)
Now those boring robotic cartridge changers have taken all the fun out
of watching operators at work ...
--
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Mac Horn Phone : (09) 380 2327
Acting Mathematics and Fax : (09) 380 1012
Physical Sciences Librarian
Terry Kennedy, Operations Mgr.
> Ever tried booting Standalone Backup off TK50? You get time not only
> to eat dinner, but to cook it as well. But it's still not as bad as
> doing anything with a TU58....
No, you could also supervise your dinner from when it began life through
the processing and delivery to the market while waiting. This amazes me -
it's slower than TU58's (really! I have both a 750 w/ TU58's and a MVII w/
TK50). Booting from RX33's is _lots_ faster. Most peculiar.
Terry Kennedy, Operations Mgr.
> On a DECsystem-10 I used to be acquainted with we had a pair of 9-track
> tape drives which were used to exchange data with the IBM systems. I don't
> recall the DEC nomenclature for them (TU40??), but in real life they were
> STC tape drives for an IBM system (including both the drives and the
> associated control units -- functionally identical to IBM 3420's). A
> special DEC interface (DX10??) converted Massbus signals into an IBM
> selector channel which was then connected to the STC controller.
I had this odd impression that the TU72 was actually an IBM 2420/3420. I
could be wrong, though.
Did you ever wonder why DEC changed the TU78 to the TU79? Well, if you
look at the door of a TU79 you'll see 3 almost-square rectangular depress-
ions. Think about sticking decals that say things like "280" in there and
you'll get the idea - DEC was buying less of the units than another Pertec
customer who was putting them on IBM systems (competing with the 3422), so
the door got redesigned. DEC used the change to change the name, since the
TU78 had developed such a reputation for reliability problems.
Terry Kennedy, Operations Mgr.
> I dunno. I saw a lot of imaginatively munched tapes in 9-track drives.
> I used a TA79 a lot -- it was much more reliable than the two TA81s it
> superseded put together, but when it decided to fail it would do so properly.
Well, the TU77/78/79 are all built by TA/Pertec. I happen to think that
they are marvelous drives, the end result of years of evolution, which
nothing can surpass. Of course, once microprocessors and better reel servo
motors became widely available, drives like the CDC Keystone (TU8x) came
out at _vastly_ lower prices.
The thing to remember on the TU7x drives is that there are a large number
of adjustments which need to be touched up. Unfortunately, your average ser-
vice tech is terrified of making them (they are rather complicated) and thus
doesn't want to get involved. [Part of this fear is from installing the DEC
reliability FCO in the TU78, probably]. If you want to see a tech tremble,
tell him "I think the Interconnect F1 board is bad" 8-)
Anyway, all the problems you describe with the backwrap on the takeup reel
are from improper adjustment of the reel rotation rate. On a load/unload, the
reels turn at rates set by trimpots in the logic cage (as opposed to when the
tape is loaded, when they are controlled by the capstan and pressure trans-
ducers.
Thomas Farmer
>> Has anyone ever heard of a "9track tape" as data storage?
>
>Pretty soon we'll hear question like:
>
> Has anyone heard of a paper tape?
> " " " " a punch card?
> " " " " core memory?
Has anyone heard of MS-Dos?
Has anyone heard of Unix?
Has anyone heard of main-frames?
Has anyone heard of IBM?
:-) :-) :-) * 20
--
Thomas Farmer | tfa...@datamark.co.nz or | I use and like:
Datamark Intl Ltd | tfa...@cavebbs.welly.gen.nz | AIX 3.1, OS/2 2.0,
Technical Writer | | Windows 3.1 &
& PC Wrangler | You can't beat a beagle. | AmigaOS 2.04.
Ian Phillipps
>You don't want to know what a TK50 is. Probably the worst cartridge design
>for tape transport ever.
I agree, but worst ever - there's hot competition! I remember the
old-style DEC tapes. 3" diameter open-reel jobs; no capstan motors. The
drive just span the reel motors. I had to use a Fortran compiler which
used them as backing store. Coffee while compiling? No - lunch!
OK, they weren't "cartridge" drives, but they were close. ish.
Ian
--
Ian Phillipps, Unipalm Ltd, 216 Science Park, Phone +44 223 420002
Milton Road, Cambridge, CB4 4WA, England. Phax +44 223 426868
The road to hell is paved with melting snowballs - Larry Wall
Daniel Zev Sands
on a Teletype connected to my high school's PDP-8. There was no
storage available so you HAD to store your program on paper tape. I
remember arguing about whether it was better to FOLD the tape (so you
could store it in a notebook) or to ROLL it (so you could rubber band
it or TRY to stuff it into a film canister). The tape was encoded
with holes--seven or eight across, I believe--each row representing
one character. If the tape ripped (go forbid) you'd lose only a few
characters but it could really screw up the program you were trying to
load. Just to make things even riskier, the electromechanical reader
frequently misread. But the din of that noisy reader and the puncher
was nothing compared with the racket of the teletypes themselves.
All things considered, I'll take my PC any day.
- Danny
--
-- Daniel Z. Sands, MD Beth Israel Hospital
dsa...@binoc.bih.harvard.edu Center for Clinical Computing
Voice: (617) 732-5925 350 Longwood Ave.
FAX: (617) 277-9792 Boston, MA 02115
Charles Lasner
>In article <1992Jul21.2...@nap.amoco.com> pgr...@nap.amoco.com (Philip L. Gravel) writes:
>
>>> Has anyone ever heard of a "9track tape" as data storage?
>>
>>Pretty soon we'll hear question like:
>>
>> Has anyone heard of a paper tape?
>> " " " " a punch card?
>> " " " " core memory?
>
>Has anyone heard of MS-Dos?
>
>Has anyone heard of Unix?
>
>Has anyone heard of main-frames?
>
>Has anyone heard of IBM?
>
>:-) :-) :-) * 20
Has anyone heard of usenet?
Happynet? (Kibo listening?)
cjl
Charles Lasner
>Paper tape. Ahh the sweet memories. I remember programming in BASIC
>on a Teletype connected to my high school's PDP-8. There was no
>storage available so you HAD to store your program on paper tape. I
>remember arguing about whether it was better to FOLD the tape (so you
>could store it in a notebook) or to ROLL it (so you could rubber band
>it or TRY to stuff it into a film canister). The tape was encoded
>with holes--seven or eight across, I believe--each row representing
>one character. If the tape ripped (go forbid) you'd lose only a few
>characters but it could really screw up the program you were trying to
>load. Just to make things even riskier, the electromechanical reader
>frequently misread. But the din of that noisy reader and the puncher
>was nothing compared with the racket of the teletypes themselves.
>
>All things considered, I'll take my PC any day.
I use my PDP-8 (and my PC) a lot. The PDP-8 has a PC04 high-speed reader
which I rarely use, and also a CR8E punched card reader which I virtually
never use. (And now have disconnected and in a closet to save space.)
This machine did indeed have a teletype on it at one time. The console
device for it has changed many time, and is currently a DECmate III running
Kermit-12. (Yes, I have a PDP-8 on my PDP-8 :-).)
BTW, my PC has been used as the console terminal for the PDP-8, but the
DECmate has a better keyboard.
cjl
Charles Lasner
>pe...@taronga.com (Peter da Silva) writes:
>
>>You don't want to know what a TK50 is. Probably the worst cartridge design
>>for tape transport ever.
>
>I agree, but worst ever - there's hot competition! I remember the
>old-style DEC tapes. 3" diameter open-reel jobs; no capstan motors. The
>drive just span the reel motors. I had to use a Fortran compiler which
>used them as backing store. Coffee while compiling? No - lunch!
>
>OK, they weren't "cartridge" drives, but they were close. ish.
[Flamethrower On]
That's about the worst maligning of DECtape I have heard this year!
For starters:
You are talking about a random access device that is serially implemented,
yet totally block-replaceable, and has no additional penalties for passing
the data as in streamers, and can even transfer data backwards if the
software supports it. (Not all systems did that, but the hardware does.)
In all probability you were using an underpowered system where the disk
device was the DECtape, and are blaming software that needs a real disk
for something as inefficient as you attempted. When used as a backup
device or just serially, would it really be that slow?
Moreover, you misunderstand the basic principle of storage on this medium.
The tape rides on an air bearing so it never touches the head. The data
is recorded with Manchester phase-encoding timed against a dedicated
timing track written only when formatting, so tape speed is not a factor
in reading or writing the data. Indeed there have been postings about
using the device with hand cranking of the reels when the motors died, etc.
All data is recorded redundantly on pairs of tracks; a 1/4" hole can be
punched in the tape and it will likely still be readable due to the
redundancy.
The medium is sandwich tape, meaning the oxide is coated like audio lab
tape with a clear non-oxide layer, which dramatically lowers tape wear.
Besides the timing track there is a so-called mark track, which allows for
unique detailed information everywhere along the media. All blocks are
numbered on both ends so searching can be both rapid and accurate. There
are checksums at both ends of the block to allow the data to be read in
the direction reverse to how it was written.
PDP-10 support of the DECtape controller allowed for up to all 8 drives to
be spinning at once, by allowing "dead reckoning" on 7 of the drives.
Periodically, each tape can be selected to determine position relative to
desired block, until one achieved the exact position desired and then the
data is transferred.
This is perhaps the most reliable device in the entire industry for
magnetic storage of data. Only fire or extreme magnetism can kill it.
I have DECtapes formatted in 1969 that read reliably today.
LINCtape is DECtapes forerunner; the same tape system except for a simpler
format that can't transfer backwards. (It can search backwards.) I have
read tapes formatted in 1962 on it without problems whatsoever.
cjl
Keith Baccki
.
.
>Has anyone heard of Unix?
Yeah, isn't that a word processor?
Just curious,
Keith
Douglas W. Jones,201H MLH,3193350740,3193382879
by las...@watsun.cc.columbia.edu (Charles Lasner):
>
> In all probability you were using an underpowered system where the disk
> device was the DECtape, and are blaming software that needs a real disk
> for something as inefficient as you attempted.
But DECtape was so good at emulating disks that this happened all the time.
There's a great story about one of the DEC PDP-10 machines at Carnegie
Mellon University that had a disk failure on its fixed head swapping disk,
to the operating system automatically fell back on the DECtape drive for
swapping. It asked the operator to mount a scratch DECtape, then, when
that was full, it asked for another scratch tape. The operator is supposed
to have ended up swapping scratch tapes back and forth, not knowing what
was going on, until the users began to complain about slow response times.
> Indeed there have been postings about
> using the device with hand cranking of the reels when the motors died, etc.
A friend of mine, Tom Roberts, once mounted a DECtape backwards, pushed
the load button, and dumped the entire load of tape on the ground, at high
speed. He removed the reels, turned them right, and pushed load again,
sucking the tape back onto the reels with a number of folds and wrinkles.
He couldn't get the tape to read (surprise) even after he ran it forward
and backward a few times to get the folds and kinks out of the tape, so
he used his finger to press the tape against the heads. This caused so
much friction that the drive motors couldn't move the tape, so he used a
pencil to crank the hubs around. The DECtape recording format was
resiliant enough that he actually managed to read the entire tape this
way.
Doug Jones
jo...@cs.uiowa.edu
(PS: I used to have a single reel of DECtape sitting somewhere around my
office, but I can't find it. What I really want is a DECtape drive and
a carton of tapes for my PDP-8/E.)
Charlie Gibbs
(Douglas W. Jones,201H) writes:
>He couldn't get the tape to read (surprise) even after he ran it forward
>and backward a few times to get the folds and kinks out of the tape, so
>he used his finger to press the tape against the heads.
I remember seeing an operator in a Univac shop, pressing tape
against the head of an old Uniservo VI C (that's pronounced Six See)
to get it to read.
Actually, when shops switched from the VI C to newer drives,
they often had to throw away a lot of tapes. The edges of the tapes
had become wrinkled, but the old drives put enough tension on them
that they'd stretch out flat as they passed over the heads. The
newer (kinder, gentler?) drives couldn't read them.
Charli...@mindlink.bc.ca
If your nose runs and your feet smell, you're built upside-down.
Don Stokes
> the processing and delivery to the market while waiting. This amazes me -
> it's slower than TU58's (really! I have both a 750 w/ TU58's and a MVII w/
> TK50). Booting from RX33's is _lots_ faster. Most peculiar.
*Building* Standalone Backup is a different story. It takes hours with
TU58s, if it works at all. A TK50 takes just a few minutes -- one of the
few cases I know where reading something takes significantly longer than
writing it. Don't get me started about the TU58 -- it's one of the most
brain damaged cartridge tape subsystems in the known universe.
Maybe I should put an RX50 drive or something on my VAXstation (he says,
endangering the life of yet another DECmate's chassis... 8-) just for booting
Standalone....
Thayne Forbes
> In article <83...@netnews.upenn.edu>, ble...@eniac.seas.upenn.edu (Benn L.
> Lewis) writes:
>
>> Has anyone ever heard of a "9track tape" as data storage?
>
> On a related topic, did you hear that Paul McCartney was in another band
> before "Wings"???? My, how time flies....
Really? What was it called?
> Pretty soon we'll hear question like:
>
> Has anyone heard of a paper tape?
> " " " " a punch card?
> " " " " core memory?
>
> Name your favorite artifact of a by-gone era....
Lets make it more challenging. Who still has any of these on a system
running today. How about any two? Anybody want to go for three? I
have 9-track and paper tape concurrently as late as 1982 (although I
will concede that this use was infrequent). I have never used core
memory, but Sperry used to give away little PCBs containing about 1K
of memory to 'Visiting Dignitaries (tm)'.
--
"If we don't succeed, we run the risk of failure."
-U.S. Vice President J. Danforth Quayl[e]
Thayne Forbes
tha...@unislc.slc.unisys.com
Charles Lasner
>
>Lets make it more challenging. Who still has any of these on a system
>running today. How about any two? Anybody want to go for three? I
>have 9-track and paper tape concurrently as late as 1982 (although I
>will concede that this use was infrequent). I have never used core
>memory, but Sperry used to give away little PCBs containing about 1K
>of memory to 'Visiting Dignitaries (tm)'.
OK, no problem whatsoever:
PDP-8/e with PDP-8/a 20-slot chassis for hex cards.
32K implemented from 2 MM8AB 16K x 12 core planes
PC04 papertape reader/punch
CR8E card reader interface with Documation 400 CPM card reader; 029 keypunch
M4/Thorn/EMI Magtape drive
RK05 x 2 and RK8E
TC08 DECtape controller with 4 drives (TU56 dual x 2)
RX02/RX8E and/or DSD-210 RX01-superset 8" floppy
InterProcessorBuffer to LINC-8 providing LINCtape support on 2 drives
CIS console breakpoint debugger
8/e front panel
8/a front panel
FP8A ASCII terminal front panel and battery-backup clock
MDC8 SCSI adaptor with OMTI 5400 controller to 1.2 Meg HD floppy, QIC-02
tape streamer, 80 Megabyte Hard disk x 2, SyQuest 555 45 Megabyte removable
cartridge hard disk
DECmate III as console terminal
LA-180 parallel printer
LA-120 serial printer
Various additional terminals and printers (some DEC, some others)
VT8E DMA terminal-like device
LAB-8/e peripherals and RM-602 oscilloscope
Most of the equipment is in 3 H-960 full-height racks. The LINC-8 stands
next to it in its outsized cabinet.
BTW, there are bigger, older -8 systems around, but you wanted one with
those particulars, etc., so I am showing you how they fit into the overall
scheme of things.
cjl
Lupe Christoph
>Unix tape interface is heavily infuenced by
>pecularities of 9-track tape format (say, impossibility to write safely in the
>middle of tape files or double tape mark as end-of-tape indicator) and
>looks, hm, strange when applied to modern streaming tapes.
If you are referring to the impossibility to write in the middle
of a QIC tape, that has a better reason than just backwards
crampability. QIC tapes have an erase head that covers the
entire tape. Hence you cannot write to a QIC tape, except after
the EOM (or anywhere on the first track).
At least on SunOS, QIC tapes do not have a double file mark
as EOM. There is a HW EOM indicator. In fact I have just seen
a bugfix that allows you to space *beyond* a double TM with
the SunOS st driver. There must be a couple of special tapes
out there that are recorded this way.
BTW, I believe I recall that a very early rev of
this driver wrote a double TM on close. If you used the
non-rewinding device, it let the tape stay there, so that
you continued to write *after* the double TM!
--
| ...!unido!ukw!lupe (German EUNet, "bang") | Disclaimer: |
| lu...@ukw.UUCP (German EUNet, domain) | As I am self-employed, |
| suninfo!alanya!lupe (Sun Germany) | this *is* the opinion |
| Res non sunt complicanda praeter necessitatem. | of my employer. |
Don Stokes
> they are marvelous drives, the end result of years of evolution, which
> nothing can surpass.
I do too. The TA79 did most of the backups, replacing two TA81s. The TA81s
would have _both_ been down about as often as the single TA79, which was
amazing considering the relative complexity of the drives. (The TA79 being
an auto-loading vacuum column job, the TA81s are flat bed, lower speed,
manual load.) It's also an indictment of the TA81s' reliability.
The operators greeted this new monster with a certain amount of fear, having
previously dealt with a TU77; also a Pertec drive, but that one had been
a real problem child.
> Anyway, all the problems you describe with the backwrap on the takeup reel
> are from improper adjustment of the reel rotation rate. On a load/unload, the
I saw that happen three or four times in the three years I dealt with the
beast, probably mainly due to dud tapes or Murphy's Law. The latter theory
seems to me to be more likely, since it was usually something important that
got eaten, like the VMS V5.2 upgrade tape (and therein lies another story).
I think the backwrap occurred at least once when the system had given up
on a tape and the operators had tried to manually initiate a rewind, but I
only got to scrape the entrails out of the thing and wasn't around when
it actually happened.
Those drives, with their vaccuum tubes and wirewrap backplanes really seemed
like living breathing things. The 3.5" form factor DAT drive on the 3100
just isn't the same....
Steve McKinty - Sun ICNC
> Those drives, with their vaccuum tubes and wirewrap backplanes really seemed
> like living breathing things. The 3.5" form factor DAT drive on the 3100
> just isn't the same....
True, but at least you don't get the problem with DAT tapes that I once
had with 9tr: a whole boxful wound the wrong way on the reels! It seemed so
unlikely that it took a while to convince myself that that really was
the problem.
Took even longer to convince the local DEC office on the phone!
Steve
Liam Greenwood
>before "Wings"???? My, how time flies....
>
--
Liam Greenwood ------ li...@durie.amigans.gen.nz ------ Wanganui, N.Z.
Don't tell my Mother I'm a programmer,
she thinks I'm a piano player in a brothel
James Kibo Parry
>In article <1992Jul22.0...@datamark.co.nz> tfa...@datamark.co.nz (Thomas Farmer) writes:
>>In article <1992Jul21.2...@nap.amoco.com> pgr...@nap.amoco.com (Philip L. Gravel) writes:
>>>> Has anyone ever heard of a "9track tape" as data storage?
>>>
>>>Pretty soon we'll hear question like:
>>>
>>
>
>Happynet? (Kibo listening?)
Believe it or not, the earliest days of Kibology were
archived on a 9-track tape (on an IBM 3090.) I think the tape is
somewhere under Troy NY gathering mold, unless they've erased it to make
room for a backup of *COINFLIP.
-- K.
Thayne Forbes
WE HAVE A WINNER!!!!
Phillip M. Hallam-Baker
(Thayne Forbes) writes:
|>From article <1992Jul21.2...@nap.amoco.com>, by
|>pgr...@nap.amoco.com (Philip L. Gravel):
|>> In article <83...@netnews.upenn.edu>, ble...@eniac.seas.upenn.edu
|>(Benn L.
|>> Lewis) writes:
|>>
|>>> Has anyone ever heard of a "9track tape" as data storage?
|>>
|>> On a related topic, did you hear that Paul McCartney was in another
|>band
|>> before "Wings"???? My, how time flies....
|>
|>Really? What was it called?
|>
|>> Pretty soon we'll hear question like:
|>>
|>> Has anyone heard of a paper tape?
|>> " " " " a punch card?
|>> " " " " core memory?
|>>
|>> Name your favorite artifact of a by-gone era....
|>
|>Lets make it more challenging. Who still has any of these on a
|>system
|>running today. How about any two? Anybody want to go for three? I
|>have 9-track and paper tape concurrently as late as 1982 (although I
|>will concede that this use was infrequent). I have never used core
|>memory, but Sperry used to give away little PCBs containing about 1K
|>of memory to 'Visiting Dignitaries (tm)'.
We are using our 9 track drive at the moment to do a backup. The Exabyte
is a bit faster, but the 9 track is on maintenance contract.
Hell, I know someone who bought a new 9 track not too long ago, they
were selling their old ones and needed something to read exisitng
tapes.
Phill Hallam-Baker
Doug Urner
>pe...@taronga.com (Peter da Silva) writes:
>>You don't want to know what a TK50 is. Probably the worst cartridge
>>design for tape transport ever.
>I agree, but worst ever - there's hot competition! I remember the
>old-style DEC tapes. 3" diameter open-reel jobs; no capstan motors.
DECtapes! I've still got one around here somewhere, found memories of
the PDP-10 return every time I stumble across it.
But a DECtape can't hold a candle to the TU58. I think they retired
the award after the DEC released the 750 with the console TU58
(otherwise the award would belong to Colorado Memory Systems for their
Jumbo drives -- after all you only used the console TU58 ocassionally,
CMS expects you to do *backups* on the Jumbo).
--
Doug Urner, dlu@wobble "They tear down our comrades like leaves from a tree,
1613 Moore Street leaves from a tree, leaves from a tree, but the
Bellingham, WA 98226 tree still stands, its roots locked to the land."
206/676-5759 -- Song of the Exile, Barry Guilder
Dik T. Winter
> Hell, I know someone who bought a new 9 track not too long ago, they
> were selling their old ones and needed something to read exisitng
> tapes.
>
incremental backups. I am still using them. Now, it they come up
with a device where I can do 'tar r' which can hold more data, I
would switch immediately. There is no substitute.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland
home: bovenover 215, 1025 jn amsterdam, nederland
d...@cwi.nl
Dave Olson
| In article <1992Jul23.2...@dscomsf.desy.de> hal...@zeus02.desy.de writes:
| > Hell, I know someone who bought a new 9 track not too long ago, they
| > were selling their old ones and needed something to read exisitng
| > tapes.
| >
| Why not? On 9 track tape it is at least possible for the user to do
| incremental backups. I am still using them. Now, it they come up
| with a device where I can do 'tar r' which can hold more data, I
| would switch immediately. There is no substitute.
DAT will do it; a lot easier to transport also!
--
Let no one tell me that silence gives consent, | Dave Olson
because whoever is silent dissents. | Silicon Graphics, Inc.
Maria Isabel Barreno | ol...@sgi.com
Terry Kennedy, Operations Mgr.
> running today. How about any two? Anybody want to go for three? I
> have 9-track and paper tape concurrently as late as 1982 (although I
> will concede that this use was infrequent). I have never used core
> memory, but Sperry used to give away little PCBs containing about 1K
> of memory to 'Visiting Dignitaries (tm)'.
How about a PDP-11/70 with TU77 9-track tape, RX02 floppies, and CR11
card reader? Overall, we have 8 9-track drives, 4 TK50's, a TZ30, the
above-mentioned RX02's and CR11.
The card reader is an odd story - we had to buy it recently (in geolog-
ical terms 8-). In the mid-80's we got rid of our remaining card equipment.
One faculty member took about 200000 blank cards and 2 keypunch machines.
We though nothing of this until he reappeared about 2 years later with a
150000-card job to run on our (long-departed) IBM 370 (actually, it was a
4300). So, we had to run around and buy a card reader so we could read
this guy's cards, convert them to tape, and run his job. Whimper.
Terry Kennedy, Operations Mgr.
> previously dealt with a TU77; also a Pertec drive, but that one had been
> a real problem child.
Yup - one bad tech can maladjust one of these "for life". Almost all of the
adjustments interact with others (that's why the factory puts sealant on the
screw heads - so they can see which ones have been fooled with). There is a
DEC PDP-11 diagnostic which you can use as a go/no go test - it does all sorts
of _terrible_ things to the drive and if the drive is the least mal-adjusted
you'll get an emergency unload. I amazed some visiting DEC types who wanted
to "run some tests to accept the system for maintenance" and they said they
would run this test until it failed. They also said that would take about 5
minutes. They stopped it manually after about an hour 8-)
Robert Bernecky
>In <13...@ns-mx.uiowa.edu> jo...@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) writes:
>
>>A 9-track tape is 1/2 inch wide, stored on reels that are up to about a
>>foot in diameter, with thousands of feet of tape per reel. Typically,
>>data is recorded at 400, 800, 1600 or 6250 bits per inch (you can guess
>>the age of a system by the lowest density it can deal with).
>
>Ahh, yessssss... I don't remember any 400BPI 9-tracks, but I certainly
>remember 200 and 552 (or was it 556? My memory fades...)BPI 7-tracks!
>Ahh, almost 6MB on a 2400 foot reel.
From the IBM 705 Data Procesing System, General Information Manual:
{This for historical interest only}
The history of magnetic recording dates back to 1898 when the Danish
scientist, Valdemar Poulsen, experimented with recording sound on a steel
wire. At that time, the performance of his machine was severely
handicapped for lack of proper amplifiers and a uniform grade of wire.
The design of magnetic recorders was greatly advanced in Germany during
World War II where equipment capable of a high degree of fidelity was
discovered during the American occupation. Further developments led to
the use of magnetic tape, rather than wire, for nearly all professional
and commercial sound recording equipment.
...
Tape units are available in 3 models... The 729 III is transistorized.
... The 727 and 729 I write at a density of 200 characters to one inch
of tape... The maximum rate of reading or writing is therefore 15000
characters per second or 67 microseconds per character.
The 729 III writes at a density of 556 characters per inch.
...
This is Copyright 1959 by IBM, as form # D22-6509-0.
My apologies for introducing fact into .folklore... Bob
>
>Ahh, ahh, ahh. Back when men were men and disk drives were electro-hydraulic.
>I remember, as a young kid, forgetting to clamp down the hub lock on a
>7/9 track tape on a CDC tape drive (forgot the model, but it was one of the
>old ones with a manual door and loading procedure). That tape spun around
>in there and took out quite a bit of hardware with it. I never forgot
>the hub lock after that.
>
>I still have a bunch of 9-tracks in the back of my car...
>
>greg
>--
>Gregory Reed Travis D P S I
>Data Parallel Systems Incorporated gr...@dpsi.com (For MX mailers only!)
>Bloomington, IN gr...@indiana.edu (For the others)
Robert Bernecky r...@yrloc.ipsa.reuter.com bern...@itrchq.itrc.on.ca
Snake Island Research Inc (416) 368-6944 FAX: (416) 360-4694
18 Fifth Street, Ward's Island
Toronto, Ontario M5J 2B9
Canada
Robert Bernecky
>> In article <83...@netnews.upenn.edu>, ble...@eniac.seas.upenn.edu (Benn L. Lewis) writes:
>
>I dunno. I saw a lot of imaginatively munched tapes in 9-track drives.
The old 729 and 2400 style IBM 9-track drives were a bit scary to watch
in high-speed rewind: There was this ~~one-horsepower motor making this
several kilogram (sorry for mixing units...) reel of tape spin at VERY
High Speed.
One day, I was in the machine room when I heard a crash at the same
time a reel of tape went tearing past my head at warp speed.
The hub grabber had broken during high-speed rewind, and the tape
reel had somehow smashed through the glass door of the tape drive
and headed across the room at a very healthy clip. Luckily,
nobody was in its trajectory, as it did considerable damage to the
wall it eventually hit...
Gerrit Visser
: In article <83...@netnews.upenn.edu>, ble...@eniac.seas.upenn.edu (Benn L.
: Lewis) writes:
:
: Has anyone heard of a paper tape?
: " " " " a punch card?
: " " " " core memory?
:
: Name your favorite artifact of a by-gone era....
: Phil
:
In that case, how about :
Metal 1/2" tape used on Uniservo I and Uniservo II (1950's).
--
Gerrit Visser Phone: (416) 672-2100
ISG Technologies Fax: (416) 672-2307
3030 Orlando Drive Net: ger...@isgtec.com
Mississagua, Ontario, Canada, L4V-1S8
John G Dobnick
Short lesson on "compatible tapes" (think "open-reel audio tape deck"):
1/2 inch wide tape, on 10 inch reels. Typically, 2400 feet of
tape per reel.
Data recording modes:
7-track (6 data bits + parity), at 200, 556, and 800 bits/inch.
9-track (8 data bits + parity) at 800 and 1600 bpi. (Mutant
systems used 3200 bpi. This was _not_ standard.)
9-track (8 data bits + parity + "ecc" encoding) at 6250 bpi.
7-track, even parity tapes used a character set called "BCD" (Binary
Coded Decimal), a 6-bit character encoding scheme. Writing a
binary zero (all 0 bits) served to "truncate" a tape record -- it
was interpreted by the tapedrive system as an "end of datablock"
indicator. Bad news for writing arbitrary binary data, as many
"experienced" users will attest. (Writing in odd parity would
work fine, but it was _even_ parity that was the *standard* for
data interchange between computer systems.)
Along with the introduction of 9-track tapes, there was this
new character set -- _Extended_ Binary Coded Decimal Interchange Code
(EBCDIC), which S/360 mavins all know and love.
Half-inch tape was (and probably still is) _THE_ data archiving medium.
There are millions upon millions of reels of that stuff in use.
[Disclaimer: The above is a _very_ terse summary of Things As They Were]
[Obligatory folklore? In one of our terminal rooms, we had this data
transcription device -- an 029. It was most amusing to watch
current-day students enter the room, look at that machine, and
adopt this "What the heck is *that*? look.
Ah, for the good ol' days. Sigh.]
--
John G Dobnick ATTnet: (414) 229-5727
Computing Services Division INTERNET: j...@uwm.edu
University of Wisconsin - Milwaukee UUCP: uunet!uwm!jgd
"Knowing how things work is the basis for appreciation,
and is thus a source of civilized delight." -- William Safire
John G Dobnick
> In article <1992Jul21.0...@news.columbia.edu> las...@watsun.cc.columbia.edu (Charles Lasner) writes:
>>
>>There is also something about the lower-speed formatting that can get confused
>>if you write even-parity data zeroes, because it can't tell the data's there.
>>Perhaps someone can point out which formats are prone to this, because I think
>>some don't have the problem.
>>
> 200 and 556 bpi 7 track tapes (I believe 800s and all 9 tracks went to
> phase encoding) use a Non Return to Zero scheme where a one bit is a
> flux change and a zero bit is nothing. Since there is no independent
> timing information on the tape a long string of zeros can cause loss
> of synchronization. I may have the details fuzzy but this is the idea
> anyway.
Phase encoding was only at 1600 9-track. 800 9-track was still NRZI.
The problem with NRZI is that long strings of zeros (zeroes? :-) ) could
cause data de-syncronization, since there were no timing pulses to
clock the data characters. (Only the "1"s were recorded, by a flux
reversal.) Phase encoding was the solution to that -- each and _every_
character had a flux reversal, and hence the data was "self clocking".
In reading my old manuals on *real* tape drives :-), I noticed something
I was unaware of before. At 6250, the data is actully recorded in
NRZI mode! You learn something new every day. (Of course, the
data is recorded in "groups" of characters, hence the name -- Group
Coded Recording mode, with all sorts of fancy ECC-like encoding done
to allow for data recovery "on the fly" in the face of dropped bits.)
> Returning briefly to the original questionon, 9 track drives for just
> about anything ("ISA" machines even) are easilt found in the small
> adds in the back of glossy mags like Byte.
9-track tape still seems to be the best way to transfer data. My
personal preference is labelled tapes (so we have the block size and
blocking factors -- which _always_ seem to get lost otherwise).
Strict ASCII encoding (none of that "binary" stuff) seems best.
Lacking anything else, IBM labelled tapes, in EBCDIC yet, are better
than "arbitrary" format, by far.
Anders Andersson
> load. Just to make things even riskier, the electromechanical reader
> frequently misread. But the din of that noisy reader and the puncher
> was nothing compared with the racket of the teletypes themselves.
A few days ago I visited a textile factory with plenty of Jacquard
looms in active use. How about that for card reader noise?
>POW< >POW< >CHI-KA< >CHI-KA< >POW< >POW< >CHI-KA< >CHI-KA<...
--
Anders Andersson, Dept. of Computer Systems, Uppsala University
Paper Mail: Box 520, S-751 20 UPPSALA, Sweden
Phone: +46 18 183170 EMail: and...@DoCS.UU.SE
John G Dobnick
> In article <13...@ns-mx.uiowa.edu> jo...@pyrite.cs.uiowa.edu
> (Douglas W. Jones,201H) writes:
>
>>He couldn't get the tape to read (surprise) even after he ran it forward
>>and backward a few times to get the folds and kinks out of the tape, so
>>he used his finger to press the tape against the heads.
>
> I remember seeing an operator in a Univac shop, pressing tape
> against the head of an old Uniservo VI C (that's pronounced Six See)
> to get it to read.
I've not only seen that done, I've _done_ it myself! (Used a piece
of facial tissue* as a pad, though, and you had to get the "wrap angle"
right. :-)] Saved a number of _long_ file backup runs that way. I
always told the operators to *not* do this, however! :-) :-)
[Yeah, yeah -- do what I say, not what I do. I know, I know. :-) ]
We had Uniservo 12C drives (same thing as an VIII-C, but with a
byte-channel (MSA) interface instead of a word-channel interface).
The real pain with those things, aside from having to manually
thread the tape through the machine and wrap the leader around the
takeup reel, was remembering to close the noise shield on the
r/w heads. Forget that when writing a tape, and you "hashed" the
label. (The "noise" on the write basically wiped out the label
area, so the tape had to be re-labelled. Particularly annoying
when doing a long file-maintenance run, using all the drives.)
It always amazed me how one could design r/w heads with that much
signal "spillover". We finally got all the r/w heads replaced
with newer (and more expensive!) heads that didn't require the
noise shields. Happy day that was!
Mitch Davis
>BTW, they make very good frisbees. Other uses include using them as
>wrapping ribbons for Christmas packages, streamers, wall decorations,
>adjustable-height (stackable) foot-rests, etc. The uses for these tapes
>are unlimited! ...they're also useful for storing computer data.
Davis to Davis, will you collect the call?
I use old 1/2" for a number of uses:
o I fitted my kite with new tails
o I (just today!) roped off an area of our open-plan[tm] garden so the
kiddies in the neighborhood wouldn't walk all over my new seedlings
Two uses I'm strongly considering:
o Typing one end to the side of a train...
o A portable braille printer.
Any other uses?
Mitch.
Mitch Davis
>In article <83...@netnews.upenn.edu>, ble...@eniac.seas.upenn.edu (Benn L.
>Lewis) writes:
>
>
Knowing what a "puffer train" was would get me an extra point on the
hacker quotient, thus promoting me a grade. I have "forced" every
question I could and I still need one more point.
Mitch.
Charles Lasner
>i...@unipalm.co.uk (Ian Phillipps) writes:
>
>>pe...@taronga.com (Peter da Silva) writes:
>
>>>You don't want to know what a TK50 is. Probably the worst cartridge
>>>design for tape transport ever.
>
>>I agree, but worst ever - there's hot competition! I remember the
>>old-style DEC tapes. 3" diameter open-reel jobs; no capstan motors.
>
>DECtapes! I've still got one around here somewhere, found memories of
>the PDP-10 return every time I stumble across it.
Doesn't address the issue: the DECtape is an elegant device. The issue is
flakey design, and the DECtape design is far from flakey: it eliminates the
need for capstan motors and in the process adds additional reliability over
every fore-runner device that depended on capstan motors as part of its
overall operation. Your fond memories will still be available to you virtually
as long as you need them if they are stored on DECtape. This is not a
media that will flake old either because it was used for a few thousand
passes or is lying around for years; pressing into service a DECtape that
was formatted 15 years ago with no special considerations is a normal
operation.
>
>But a DECtape can't hold a candle to the TU58. I think they retired
>the award after the DEC released the 750 with the console TU58
>(otherwise the award would belong to Colorado Memory Systems for their
>Jumbo drives -- after all you only used the console TU58 ocassionally,
>CMS expects you to do *backups* on the Jumbo).
I don't know what specific gripe you have against the CMS tapes, but all of
these cartridge tape systems wear out and rather quickly. Used expressly
as backup devices, the user is willing to have to throw the media away
after several thousand passes. That's about 5-10 years of daily backups,
and well worth the cost of time saved in the process. But this *is*
disposable media, unlike DECtape. In any case, the CMS DJ-20 properly
configured is a reasonable compromise for a PC environment to cheaply
backup a hundred megs or so at a reasonable rate for a reasonable price.
Perhaps your experience with the CMS drive isn't a current typical norm.
One problem with them is that so many are configured in the rock-bottom
cost mode. For a list price of $95 (usually discounted anywhere other
than catalog operations) the 1 MHz interface board eliminates the
floppy controller kludge for the DJ-20 and ups the speed. On a typical
386 system the tape usually streams. I can backup a 45 Meg SyQuest
removable cartridge onto a DJ-20 tape in about 7 minutes.
cjl
Charles Lasner
>time a reel of tape went tearing past my head at warp speed.
>
>The hub grabber had broken during high-speed rewind, and the tape
>reel had somehow smashed through the glass door of the tape drive
>and headed across the room at a very healthy clip. Luckily,
>nobody was in its trajectory, as it did considerable damage to the
>wall it eventually hit...
I have heard of apocryphal stories about FastRand drums getting loose while
spinning and mowing down whatever was in its path. Anyone out there
can relate to a specific story?
cjl
Felix Finch
> (Robert Davis) writes:
>>BTW, they make very good frisbees. Other uses include using them as
>>wrapping ribbons for Christmas packages, streamers, wall decorations,
>>adjustable-height (stackable) foot-rests, etc. The uses for these tapes
>>are unlimited! ...they're also useful for storing computer data.
> o I fitted my kite with new tails
> o I (just today!) roped off an area of our open-plan[tm] garden so the
> kiddies in the neighborhood wouldn't walk all over my new seedlings
> o Typing one end to the side of a train...
> o A portable braille printer.
When in the Navy, 73-76, I used to dump tapes into the ocean
from the fantail of my carrier (Navy recycling method :-). One way
was to launch it like a frisbee, but holding on to the tape. When it
hit the water, if you'd given it enough pre-immersion spin, it would
sometimes unwind all the way without snapping. I always figured the
tape I wa sleft holding was as close as I'd ever get to seeing a
homeward bound pennant.
Another way was to unwind a couple of hundred feet, enough to
catch the wind (at 20 knots behind a carrier, there's plenty of
turbulence). Then mount the reel on a mop (er, swab) handle, hold the
swab with both hands, and let 'er rip! Just be reeeeel careful to
keep the reel well centered and away from each hand. Once the tape
ran off the reel, dismount the reel. The tape floated in the air for
longer than you might expect.
--
... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._.
Felix Finch, scarecrow repairer / fe...@crowfix.com / uunet!crowfix!felix
Preston F. Crow
>Any other uses?
>Mitch.
Just over a year ago at Northwest Nazarene College in Nampa, Idaho, one
computer science professor gave us a bunch of computer tape to use in
decorating the house of the other c.s. professor--it's much better than
T.P. since it doesn't tear if you stretch it tight and the reels seem to
run forever. We found that if each person started with one reel, we
could usually do two or three houses before running out. (As in the
Academic Dean's and the President's houses--both people who happened to
retire this year. :-( and :-) respectively.)
--PC
Bryan J. Jensen
> i...@unipalm.co.uk (Ian Phillipps) writes:
>
>>pe...@taronga.com (Peter da Silva) writes:
>
>>>You don't want to know what a TK50 is. Probably the worst cartridge
>>>design for tape transport ever.
>
>>I agree, but worst ever - there's hot competition! I remember the
>>old-style DEC tapes. 3" diameter open-reel jobs; no capstan motors.
>
> DECtapes! I've still got one around here somewhere, found memories of
> the PDP-10 return every time I stumble across it.
Our PDP-10 (DEC10.PSU.Edu) has 8 DECtape drives. They've had no maintenance
whatsoever since we dropped our contract 10+ years ago. Three still
work. Recently, I read 40+ tapes which were written 20 years ago on
some other system. One or two were unreadable.
Doug Siebert
>in high-speed rewind: There was this ~~one-horsepower motor making this
>several kilogram (sorry for mixing units...) reel of tape spin at VERY
>High Speed.
>
>One day, I was in the machine room when I heard a crash at the same
>time a reel of tape went tearing past my head at warp speed.
>
>The hub grabber had broken during high-speed rewind, and the tape
>reel had somehow smashed through the glass door of the tape drive
>and headed across the room at a very healthy clip. Luckily,
>nobody was in its trajectory, as it did considerable damage to the
>wall it eventually hit...
After reading this an idle thought crossed my mind, wondering that if the
author had been hit in the head by the tape reel, would he have been remembered
as the first person ever to be killed by a computer? Then I got to wondering
if ANYONE had ever been killed by computer. I suppose it depends on how you
define it, surely people have been electrocuted while working on a computer in
the past. But tossing out the electrocution possibility and the certainty that
many people have been killed by computer/programmer error before (i.e., the
type of thing we read about in comp.risks) I wonder if anyone has ever been
killed by a computer?
Kind of a gruesome topic, I suppose (sorry, Mr. Bernecky :-) ) but it is late
and it has got me to wondering...
--
/-----------------------------------------------------------------------------\
| Doug Siebert | "I don't have to take this abuse |
| Internet: dsie...@icaen.uiowa.edu | from you - I've got hundreds of |
| NeXTMail: dsie...@chop.isca.uiowa.edu | people waiting in line to abuse |
| ICBM: 41d 39m 55s N, 91d 30m 43s W | me!" Bill Murray, Ghostbusters |
\-----------------------------------------------------------------------------/
Hi, I'm a .signature worm. I've already copied myself into your .signature.
Joe Morris
>Phase encoding was only at 1600 9-track. 800 9-track was still NRZI.
>The problem with NRZI is that long strings of zeros (zeroes? :-) ) could
>cause data de-syncronization, since there were no timing pulses to
>clock the data characters. (Only the "1"s were recorded, by a flux
>reversal.) Phase encoding was the solution to that -- each and _every_
>character had a flux reversal, and hence the data was "self clocking".
This isn't really an issue for 9-track recording at any density, because
by definition the standard 9-track tape is recorded using odd parity.
This assures that every character will have at least one 1-bit (and thus
at least one flux reversal) to generate a pulse on the tape, and thus
provide the necessary clocking information.
Joe Morris / MITRE
John G Dobnick
But... what this _does_ give you is the ability to "de-skew" your
data, since each _track_ is self-clocked. (Just imagine what happens
is your tape is slightly skewed. Depending upon how bad the skew is,
you could wind up clocking data from three different data frames. This
is clearly un-good.) A single parity track won't save you from this;
_independent_ self-clocking in each data track will.
sys...@iowasp.physics.uiowa.edu
>
> Short lesson on "compatible tapes" (think "open-reel audio tape deck"):
>
>
> Coded Decimal), a 6-bit character encoding scheme. Writing a
> binary zero (all 0 bits) served to "truncate" a tape record -- it
> was interpreted by the tapedrive system as an "end of datablock"
> indicator. Bad news for writing arbitrary binary data, as many
> "experienced" users will attest. (Writing in odd parity would
> work fine, but it was _even_ parity that was the *standard* for
> data interchange between computer systems.)
>
with even parity, of course) to identify the data (written in odd
partiy).
Really drive the 'device driver' nuts on the VAX/VMS system...
(You don't have 7-track drives on your VAX! Gee, that seems rather
strange...)
Willy
Tom Van Vleck
>I have heard of apocryphal stories about FastRand drums getting loose while
>spinning and mowing down whatever was in its path. Anyone out there
>can relate to a specific story?
I think this may be an urban legend.
I first heard it from a Bryant salesman in 1959 thus: An experimental
drum, half a ton of machined aluminum in a vacuum box at 14K rpm.
Somebody opened the door & the drum hopped its bearings and began
wandering like a top through the lab, smashing everything.
(I suspect that anytime there's a big piece of rotating machinery,
people wonder about its gyroscope nature.. wonder if that guy on the
bike has trouble cornering when his hard disk is spinning?)
-- Tom Van Vleck <vanvle...@tandem.com>
sys...@iowasp.physics.uiowa.edu
>
> I have heard of apocryphal stories about FastRand drums getting loose while
> spinning and mowing down whatever was in its path. Anyone out there
> can relate to a specific story?
>
like that), head/track spinning at 7200 RPM...
Willy
John-Marc Chandonia, , ,
> After reading this an idle thought crossed my mind, wondering that if the
> author had been hit in the head by the tape reel, would he have been remembered
> as the first person ever to be killed by a computer? Then I got to wondering
> if ANYONE had ever been killed by computer. I suppose it depends on how you
> define it, surely people have been electrocuted while working on a computer in
> the past. But tossing out the electrocution possibility and the certainty that
> many people have been killed by computer/programmer error before (i.e., the
> type of thing we read about in comp.risks) I wonder if anyone has ever been
> killed by a computer?
Here's an escape sequence for VT1000 terminals: ^]]HastaLaVista
(a great way to kill people remotely)
JMC
--
chan...@husc9.harvard.edu | I will not yell fire in a crowded classroom
John-Marc Chandonia | I will not yell fire in a crowded classroom
Graduate Biophysics Program | I will not yell fire in a crowded classroom
Harvard University | I will not yell fire ...
Tony Duell
Well, My Philips P850 has 2 K words of Core Memory, and boots from paper
tape. (One day at Cambridge, after carrying the CPU back from a friend's
room, where I had been demonstrating it, one of the 4 Core memory units
fell out, and bounced about 4 times on the concrete path. Not only di it
still work, but the data was still there)
My PDP11/10's have core memory, and last year at the Bristol University
Socieies fair, I booted one of them from paper tape (I borrowed the bord
from my 11/45)
My 11/45 has paper tape, a card reader (I don't have a computer-controlled
punch - I have one of those hand things, 12 buttons - 1 for each row) ,
and could have core memory if I could be bothered to fit it in (I have
loads of DEC core in my spares box). It also has a couple of 9-track
magtapes, which is where we started.
Talking of old storage, how many still use 8" floppies (I have them on my
PDP11/45 (DEC RX02), CASU super C CP/M machine, FTS-88 CPM/86 machine, and
I have a couple linked up to my IBM XT - I intend to link a paper tape
reader to that box soon - ever seen a PC with 6 floppies and paper tape
?!?!?)
-tony 'PDP11 Hacker' Duell
a...@siva.bris.ac.uk
Joe Morris
> And how's 'bout the 7 track tapes with BCD header records (written
>with even parity, of course) to identify the data (written in odd
>partiy).
> Really drive the 'device driver' nuts on the VAX/VMS system...
I can't get too upset about that. The practice of recording all tape label
records in even parity (regardless of the parity used to record the data)
has been around longer than the VAX. The label records are character
files, and common practice for 7-track tapes was to use even parity for
character files.
The issue of how even parity became the standard for such files is a
different question. I haven't ever heard even rumors on the subject;
can anyone offer useful info or speculation?
I'll agree that mixed-parity tapes are a royal pain. The old IBSYS
Type 3 record format used variable-length records with a green word;
each record also had a lookahead bit to tell the reading program what
parity to use when reading the following record.
One of the first application packages I wrote for the S/360 was a tape
copy program. The hell I went through for error recovery included
trying every combination of density {200,556,800} and parity {odd,even}
before giving up and declaring a block unreadable. And I recall
the joy I felt when I found that the new 3803 tape control unit could
not support both 6250 and 7-track drives. I was able to use this to
leverage the computer center into dropping support for 7-track tapes;
thankfully nobody told management that an engineering change to the
3803 had obsoleted the restriction...
Joe Morris
Joe Morris
>Charles Lasner writes:
>>I have heard of apocryphal stories about FastRand drums getting loose while
>>spinning and mowing down whatever was in its path. Anyone out there
>>can relate to a specific story?
>I think this may be an urban legend.
>I first heard it from a Bryant salesman in 1959 thus: An experimental
>drum, half a ton of machined aluminum in a vacuum box at 14K rpm.
>Somebody opened the door & the drum hopped its bearings and began
>wandering like a top through the lab, smashing everything.
It's documented history that while the experimental disk drive which became
IBM's RAMAC was being developed, one day the hub disintegrated and a flying
platter grazed one of the engineers. I can't recall just where I saw this
most recently; possibly in Spectrum, or maybe in IBM Systems Journal.
And no, I can't claim any direct knowledge of the incident.
Joe Morris
Charles Lasner
>
>Our PDP-10 (DEC10.PSU.Edu) has 8 DECtape drives. They've had no maintenance
>whatsoever since we dropped our contract 10+ years ago. Three still
>work. Recently, I read 40+ tapes which were written 20 years ago on
>some other system. One or two were unreadable.
One of the worst forms of failure of DECtape is attributable to field circus.
Other than cleaning the guides and rear plates, the best DECtape maintenance
is no maintenance at all.
Probably the tapes were abused on a "maintained" system. If you still have
problems with the tapes, send them to me; I probably can recover the data
for you.
cjl
Paul Tomblin
>as the first person ever to be killed by a computer? Then I got to wondering
>if ANYONE had ever been killed by computer. I suppose it depends on how you
Well, I don't have the references, although any regular reader of comp.risks
could tell you about the radiation treatment machine (for treating cancer
patients) that killed several people due to a software bug.
It turned out that the programmers hadn't considered the case were the
operator might push one button before another operation was finished, as so
the shield that limits the amount of radiation could be completely out of
the path, allowing a fatal dose of radiation to hit the patient.
--
Paul Tomblin, p...@geovision.gvc.com or {uunet,revcan}!geovision!pt
(This is not an official opinion of GeoVision Systems Inc.)
"Usenet is like Tetris for people who still remember how to read"
-- Joshua Heller (hel...@husc.harvard.edu) on rec.humor.funny
Paul Tomblin
>I think this may be an urban legend.
An urban legend in a folklore group? Surely you jest!
>I first heard it from a Bryant salesman in 1959 thus: An experimental
>drum, half a ton of machined aluminum in a vacuum box at 14K rpm.
>Somebody opened the door & the drum hopped its bearings and began
>wandering like a top through the lab, smashing everything.
I heard a story about a drum memory on a warship that went crashing thourgh
the side when they tried a 'man overboard' turn.
(My brother the sailor told me that one - along with the one about putting a
hole in the hull when chipping paint in the bilges.)
--
Paul Tomblin, p...@geovision.gvc.com (Not an official spokesman, blah, blah...)
------------------------------------------------------------------------------
"Engineers aren't as smart as they like to be told they are." - told to me
by Heather Killam the co-op. (It sounded funnier after a lot of beer!)
Mark Brader
> Well, I don't have the references, although any regular reader of comp.risks
> could tell you about the radiation treatment machine (for treating cancer
> patients) that killed several people due to a software bug.
mean. But now that it's been mentioned...
> It turned out that the programmers hadn't considered the case were the
> operator might push one button before another operation was finished, as so
> the shield that limits the amount of radiation could be completely out of
> the path, allowing a fatal dose of radiation to hit the patient.
This is only approximately right. Here's the relevant part of the Boston
Globe article excerpted by Karen Sollins in comp.risks issue 3.09.
The Globe printed it on June 20, 1986.
# The Therac 25 is designed so that the operator selects either X-ray or
# electron-beam treatment, as well as a series of other items, by typing on a
# keyboard and watching a video display screen for verification of the
# orders.
#
# It was revealed that if an extremely fast-typing operater inadvertently
# selected the X-ray mode, then used an editing key to correct the command
# and select the electron mode instead, it was possible for the computer to
# lag behind the orders. The result was that the device appeared to have
# made the correct adjustment but in fact had an improper setting so it
# focussed electrons at full power to a tiny spot on the body.
In comp.risks issue 3.11, Jon Jacky cites a story the following day in
the New York Times, and his commentary includes this clarification of
how the error could be physically possible.
| The New York Times story did not mention the x-ray/electron confusion,
| and that is the key to this accident. A modern radiation therapy machine
| is based on a linear accelerator that produces an electron beam with an
| energy of 25 MeV or so. You may direct the electrons directly into the
| patient (at this energy electrons are ionizing radiation), or, to produce
| X-rays, you put a heavy metal target in the electron beam, and when the
| electrons hit the target X-rays come out the other side. The target is
| moved in and out of the beam automatically. Here is my speculation of
| what happened: I suspect that the current in the electron beam is
| probably much greater in X-ray mode (because you want similar dose rates
| in both modes, and the production of X-rays is more indirect). So when
| you select X-rays, I'll bet the target drops into place and the beam
| current is boosted. I suspect in this case, the current was boosted
| before the target could move into position, and a very high current
| electron beam went into the patient.
(Obviously there should have been some form or another of interlock
to prevent this combination of modes.)
--
Mark Brader "'You wanted it to WORK? That costs EXTRA!'
SoftQuad Inc., Toronto is probably the second-place security hole
utzoo!sq!msb, m...@sq.com after simple carelessness." -- John Woods
Terry Kennedy, Operations Mgr.
> I think this may be an urban legend.
When I was in high school, we bought timesharing services from a nearby
school system. The systems were HP2000's (2000C' and 2000F). As I recall,
the C' had a drum, as well as a 23Mb disk pack. Well, one day we couldn't
get in, and when the teacher called up, she was told that the drum had
come loose and ripped things up pretty good.
About a year later, I got to visit the computer facility and asked if this
was true or not. Well, they still had the old drum cabinet and drum there
(this was when HP made everything in battleship grey). Well, there were some
pretty hefty scratch marks on the enclosure. Apparently the drum bearing(s)
failed and it tipped.
Later on in life I got to work on an LGP-30 (yes, I believe that's Mel's
machine and no, I'm not living my life in reverse chronological order 8-).
The '30 had a smaller drum, but having picked it up and watched the motor
try to start it, I can believe these stories.
Terry Kennedy Operations Manager, Academic Computing
te...@spcvxa.bitnet St. Peter's College, Jersey City, NJ USA
te...@spcvxa.spc.edu +1 201 915 9381
Sarr J. Blumson
>
>After reading this an idle thought crossed my mind, wondering that if the
>author had been hit in the head by the tape reel, would he have been remembered
>as the first person ever to be killed by a computer? Then I got to wondering
>if ANYONE had ever been killed by computer. I suppose it depends on how you
>define it, surely people have been electrocuted while working on a computer in
>the past. But tossing out the electrocution possibility and the certainty that
>many people have been killed by computer/programmer error before (i.e., the
>type of thing we read about in comp.risks) I wonder if anyone has ever been
>killed by a computer?
>
>Kind of a gruesome topic, I suppose (sorry, Mr. Bernecky :-) ) but it is late
>and it has got me to wondering...
>
It is also onlt third hand or so, so it might be true:
Mel's favorite machine, the IBM 650, had a grounding strap on the drum
to drain static. On at least one occassion this broke, turning the
machine into a fairly large van de Graf generator, with predictable
(from the subject line anyway) consequences for the next person who
touched the colsole.
(Sarr Blumson)
Jim Ellignsen
I worked for UNIVAC we used to use FASTRANDs as a unit of measure as "in
the house had a 6 FASTRAND basement". How could something so big hold
so little data?
Is it true or folklore that FASTRANDs, 432s,
and 1782s were made from sewer pipes?
Jim Ellingsen elling...@tandem.com
Ric Werme
>From article <1992Jul22.1...@news.columbia.edu>,
>by las...@watsun.cc.columbia.edu (Charles Lasner):
>>
>> In all probability you were using an underpowered system where the disk
>> device was the DECtape, and are blaming software that needs a real disk
>> for something as inefficient as you attempted.
>
>But DECtape was so good at emulating disks that this happened all the time.
>There's a great story about one of the DEC PDP-10 machines at Carnegie
>Mellon University that had a disk failure on its fixed head swapping disk,
>to the operating system automatically fell back on the DECtape drive for
>swapping. It asked the operator to mount a scratch DECtape, then, when
>that was full, it asked for another scratch tape. The operator is supposed
>to have ended up swapping scratch tapes back and forth, not knowing what
>was going on, until the users began to complain about slow response times.
This may be a great story, but I don't believe it:
1) I was at CMU from 1968-1974, and was one of the first operators for the
first PDP-10 (it had 5 DECtape drives and no disks) when it arrived in 1969.
2) I never would have configured the machine to swap to tape. I don't
remember if it was possible. (May well have been, though.)
3) I don't recall any messages anywhere in the OS that would have
prompted for a new scratch tape. I did source merges for new OSes and
a lot of development for ARPAnet and AI lab devices, so I knew the
code pretty well.
4) Bryant drum and Burroughs disk failures generally resulted in I/O errors.
(Sometimes they were not reported and I hated runing diagnostics because
they'd wipe out the filesystem.) It would be tough for the operator to
miss it.
One thing that *did* impress me on the DECtape only system was that sometimes
when I ran TECO I would get the '*' prompt immediately and the DECtape
wouldn't spin. Only TECO, never anything else. It wasn't until I started
digging into OS source that I understood why.
--
| A pride of lions | Eric J Werme |
| A gaggle of geese | 77 Tater St |
| An odd lot of programmers | Mont Vernon NH 03057 |
| A Constitution of Libertarians | Phone: 603-673-3993 |
Frank - Hardware Hacker - Borger
>| I suspect that the current in the electron beam is
>| probably much greater in X-ray mode (because you want similar dose rates
>| in both modes, and the production of X-rays is more indirect). So when
>| you select X-rays, I'll bet the target drops into place and the beam
>| current is boosted. I suspect in this case, the current was boosted
>| before the target could move into position, and a very high current
>| electron beam went into the patient.
>
>(Obviously there should have been some form or another of interlock
>to prevent this combination of modes.)
>--
mode, the electron beam is scanned just like the electron beam in
the CRT tube you are reading this on. Note that larger tv's have
shutdown circuits that turn off the beam if scanning stops since you
don't want to blow your CRT tube.
The software bug also did not turn on the electron beam scanning, so
the unscanned beam with an intensity about 100 times normal, was not
scanned, resulting in another 100 times or so intensity factor.
The predecessor to the Therac 25, the Therac 20 also has electron beam
scanning, but it is simple sawtooth type scanning. Separate electronic
circuits continuously monitor this pattern to make sure the scanning
is running, TOTALLY INDEPENDANT OF THE COMPUTER.
The newer, fancier machine, allowed fancy scanning on a point by point
basis, with a look up table determining each and every point in the
scan. Unfortunately, when they designed this, they dropped the older
monitoring circuits. (ooops.)
Things then got even worse. Basically because this was a brand new
machine, (first or second one produced by Atomic Energy of Canada, ltd,)
installed in a brand spanking new department, with hospital adminis-
trators very interested in starting to get income from a ballpark $10
million investment. As a result, the machine was pressed into use before
proper shakedown was done, in a department still coping with the work
of getting everything going at once.
1/ The operator turns on the machine, and it immediately delivers dose
about 5 to 10k times greater than normal. Circuits in the machine do
detect the problem, and shut down the machine, but the computer dis-
plays the cryptic error message, "Malfunction 54." (Stupid
programming error #43, not having clear error messages.)
2/ The operator didn't know what malfunction 54 was, (and had not been
properly instructed as to what to do when things go wrong,) so
she kept trying to run the machine again and again, zapping the
patient several times.
3/ Because the closed circuit tv system wasn't working, (even though
cameras are mandated by all states,) the tech didn't see the patient
jump when they essentially received a 25 million volt electric shock.
4/ Because the intercom system was also not working, the tech didn't
hear the patient yelling, and only knew something was wrong when she
heard the patient pounding on the door trying to get out.
Moral of the story.
1/ Don't rely on the computer too much.
2/ Be very careful of what your error messages say.
3/ Don't install brand new machine number 1 in a brand spanking new
radiation therapy department.
4/ Train your people well in what to do if something goes wrong.
5/ Never run in a mode where ANY monitoring cameras, intercoms, etc
are not working. (Any unit I spec, I always specify redundant
CCTV systems. Another $400 bucks added on to a $2-million machine
does nothing to the bottom line.)
6/ If anything happens that you do NOT UNDERSTAND, STOP IMMEDITELY
UNTIL YOU FIGURE OUT WHAT IS GOING ON.
Frank R. Borger - Physicist __ Internet: Fr...@rover.uchicago.edu
Michael Reese - Univ. of Chicago |___ Phone : 312-791-8075 fax : 567-7455
Center for Radiation Therapy | |_) _ Last night I discovered a new form
2929 South Ellis Avenue | \|_) of oral contraceptive. I asked a girl
Chicago, Illinois 60616 |_) to go to bed and she said no. W Allen
Greg Lehey
>Charles Lasner writes:
>>I have heard of apocryphal stories about FastRand drums getting loose while
>>spinning and mowing down whatever was in its path. Anyone out there
>>can relate to a specific story?
>
>drum, half a ton of machined aluminum in a vacuum box at 14K rpm.
>Somebody opened the door & the drum hopped its bearings and began
>wandering like a top through the lab, smashing everything.
This obviously wasn't related to a Fastrand. The Fastrand contained 2
drums, each about 15" in diameter, about 9 feet long, and rotating at
880 rpm. I've heard plenty of stories about installation, and most of
them had scratches from head crashes on the drum surface (there was a
window where you could watch the positioners move laterally across the
drum. I seem to recall 192 heads and 64 positions, but could be
wrong). In any case, the scratches did not seem to impair the storage
capability. The drums themselves were made of gas piping of some kind
or another, and appeared then to have been chromium plated.
--
Greg Lehey | Tel: +49-6637-1488
LEMIS | Fax: +49-6637-1489
Schellnhausen 2, W-6324 Feldatal, Germany
*** NOTE ***: Headers are mangled - reply to grog%le...@Germany.EU.net
Nolan Hinshaw
In article <1992Jul21.2...@nap.amoco.com>, pgr...@nap.amoco.com (Philip L. Gravel) writes:
|>Name your favorite artifact of a by-gone era....
Plugboards!
--
Nolan "Tinkertoys(tm) is good enuf fer me" Hinshaw
Internet: no...@twg.com Dingalingnet: (415)962-7197
"... necrophilia doesn't really hurt anybody." Rick Gordon
sys...@iowasp.physics.uiowa.edu
the high-class disks of today look slow (averag access was a little
over 4ms, and worst case was a little over 8ms)
Ah the good old days...
(Back when men were men and sheep ran scared...
Willy
Bill Marcum
>
>I use old 1/2" for a number of uses:
>
> o I fitted my kite with new tails
> o I (just today!) roped off an area of our open-plan[tm] garden so the
> kiddies in the neighborhood wouldn't walk all over my new seedlings
>
>Two uses I'm strongly considering:
>
> o Typing one end to the side of a train...
> o A portable braille printer.
>
>Any other uses?
>
>Mitch.
How about uses for those plastic write-enable rings? B|-) (bifocals)
Bill Marcum bma...@world.std.com
Douglas W. Jones,201H MLH,3193350740,3193382879
by we...@alliant.com (Ric Werme):
> This may be a great story, but I don't believe it:
>
> 1) I was at CMU from 1968-1974, and was one of the first operators for the
> first PDP-10 (it had 5 DECtape drives and no disks) when it arrived in
> 1969.
That's curious, I was there from 1969 to 1973, as an undergrad, and that's
when I heard the story about swapping to DECtape! There was quite a bit of
folklore about DECtape even back then!
Doug Jones
jo...@cs.uiowa.edu
Steve McKinty - Sun ICNC
>
> (I suspect that anytime there's a big piece of rotating machinery,
> people wonder about its gyroscope nature.. wonder if that guy on the
> bike has trouble cornering when his hard disk is spinning?)
>
Reminds me of a story told by Prof Eric Laithwaite on one of the Royal
Institution's Christmas Lectures some years ago. He was a gyroscope
enthusiast, and told of a time he'd got a large rigid suitcase and put a
hefty flywheel in it. He then arrived at a posh hotel, got the flywheel up to
speed (with a portable drill or something) & walked straight up the steps
into the hotel. A porter immediately came over to carry his bag, which all
went well until he tried to turn a corner...
Joe Morris
>How about uses for those plastic write-enable rings? B|-) (bifocals)
Easy: just sell them to gullible new computer operations supervisors.
Believe it or not, the most recent UARCO catalog I have still carries
them; catalog part number CC244145, 60 cents *each* for quantities 1-24;
down to $.49 each for 100 or more.
Joe Morris
Bill Thater
In a previous article, p...@geovision.gvc.com (Paul Tomblin) says:
>t...@tandem.com (Tom Van Vleck) writes:
>
>>I think this may be an urban legend.
>
>An urban legend in a folklore group? Surely you jest!
>
Sorry to destroy the illusion but I've seen one come "unglued". A
Bryant one at that. I don't realy remember the model number, it's been a
long time and it was on a system at the other end of a long room. But I do
remember the noise and watching the drum come flying out of the drive and
thru a wall and down a hall, ending up against the elevators. Scared the
living HELL outta me!
--
================HCF - HALT AND CATCH FIRE ==============================
Bill Thater aq...@Freenet.Cleveland.edu
"Bit Pusher" tha...@vax.cs.hscsyr.edu
****If all else fails - read the instructions!!**************************
Gerrit Visser
: I've not only seen that done, I've _done_ it myself! (Used a piece
: of facial tissue* as a pad, though, and you had to get the "wrap angle"
: right. :-)] Saved a number of _long_ file backup runs that way. I
: always told the operators to *not* do this, however! :-) :-)
: [Yeah, yeah -- do what I say, not what I do. I know, I know. :-) ]
:
: We had Uniservo 12C drives (same thing as an VIII-C, but with a
: byte-channel (MSA) interface instead of a word-channel interface).
: The real pain with those things, aside from having to manually
: thread the tape through the machine and wrap the leader around the
: takeup reel, was remembering to close the noise shield on the
: r/w heads. Forget that when writing a tape, and you "hashed" the
: label. (The "noise" on the write basically wiped out the label
: area, so the tape had to be re-labelled. Particularly annoying
: when doing a long file-maintenance run, using all the drives.)
: It always amazed me how one could design r/w heads with that much
: signal "spillover". We finally got all the r/w heads replaced
: with newer (and more expensive!) heads that didn't require the
: noise shields. Happy day that was!
:
: --
Well, to be perfectly correct john , the 12C was a phase capable
version of the VIC. Pinch rollers and all.
The VIIIC (and its phase version 16C) did not have to be manually
threaded, they had tape leaders. The leader was in threaded through
the loop boxes and tape path and left that way. The operator only had
to clip the end of tape onto the leader and push the load point switch.
--
Gerrit Visser Phone: (416) 672-2100
ISG Technologies Fax: (416) 672-2307
3030 Orlando Drive Net: ger...@isgtec.com
Mississagua, Ontario, Canada, L4V-1S8
Gerrit Visser
: I have heard of apocryphal stories about FastRand drums getting loose while
: spinning and mowing down whatever was in its path. Anyone out there
: can relate to a specific story?
: cjl
The FastRand story I recall is from a site in Germany. A Fastrand had
been hoisted to a floor several stories up. The unit was being wheeled
down a corridor when the CE's lost control of it. The thing went out
the end wall and crashed into (not just onto) the sidewalk. There were
no reported human injuries.
The drums turned at 330 RPM (or was it 300 RPM). It took about 1/2
hour to get them up to speed. Each drum (there were 2 one above the
other) had a 3 phase direct drive motor.
The Polymath
}many people have been killed by computer/programmer error before (i.e., the
}type of thing we read about in comp.risks) I wonder if anyone has ever been
}killed by a computer?
Do robots and their controllers count? I think the current count of
people done in by industrial robots is around half a dozen or so. The
usual cause is some idiot entering a robot's work cell without proper
safety precautions.
"Think of it as evolution in action." -- L. Niven
The Polymath (aka: Jerry Hollombe, M.A., CDP, aka: holl...@polymath.tti.com)
Head Robot Wrangler at Citicorp Turn the rascals out!
3100 Ocean Park Blvd. (310) 450-9111, x2483 No incumbents in '92!
Santa Monica, CA 90405 {rutgers|pyramid|philabs|psivax}!ttidca!hollombe
Lupe Christoph
>After reading this an idle thought crossed my mind, wondering that if the
>author had been hit in the head by the tape reel, would he have been remembered
>as the first person ever to be killed by a computer? Then I got to wondering
>if ANYONE had ever been killed by computer. I suppose it depends on how you
>define it, surely people have been electrocuted while working on a computer in
>the past. But tossing out the electrocution possibility and the certainty that
>many people have been killed by computer/programmer error before (i.e., the
>type of thing we read about in comp.risks) I wonder if anyone has ever been
>killed by a computer?
>
>Kind of a gruesome topic, I suppose (sorry, Mr. Bernecky :-) ) but it is late
>and it has got me to wondering...
Not exactly at the point, but the jargon file entry {scratch monkey}
applied here:
:scratch monkey: n. As in "Before testing or reconfiguring, always
mount a {scratch monkey}", a proverb used to advise caution
when dealing with irreplaceable data or devices. Used to refer to
any scratch volume hooked to a computer during any risky operation
as a replacement for some precious resource or data that might
otherwise get trashed.
This term preserves the memory of Mabel, the Swimming Wonder
Monkey, star of a biological research program at the University of
Toronto ca. 1986. Mabel was not (so the legend goes) your ordinary
monkey; the university had spent years teaching her how to swim,
breathing through a regulator, in order to study the effects of
different gas mixtures on her physiology. Mabel suffered an
untimely demise one day when DEC {PM}ed the PDP-11 controlling
her regulator (see also {provocative maintenance}).
It is recorded that, after calming down an understandably irate
customer sufficiently to ascertain the facts of the matter, a DEC
troubleshooter called up the {field circus} manager responsible
and asked him sweetly, "Can you swim?"
Not all the consequences to humans were so amusing; the sysop of
the machine in question was nearly thrown in jail at the behest of
certain clueless droids at the local `humane' society. The moral
is clear: When in doubt, always mount a scratch monkey.
--
| ...!unido!ukw!lupe (German EUNet, "bang") | Disclaimer: |
| lu...@ukw.UUCP (German EUNet, domain) | As I am self-employed, |
| suninfo!alanya!lupe (Sun Germany) | this *is* the opinion |
| Res non sunt complicanda praeter necessitatem. | of my employer. |
Doug McNaught
> One thing that *did* impress me on the DECtape only system was
>that sometimes when I ran TECO I would get the '*' prompt immediately
>and the DECtape wouldn't spin. Only TECO, never anything else. It
>wasn't until I started digging into OS source that I understood why.
Ok, I'll bite--why?
-doug
--
Doug McNaught |"Sadder still to watch it die/ Then never to have
do...@cns.caltech.edu | known it/ For you, the blind who once could see/
do...@midget.towson.edu | The bell tolls for thee..." --Neil Peart
Nobody approves my opinions! Not even me, sometimes. Read at your own risk.
Bob Montante
Thaddeus P. Floryan
>In <67...@charon.cwi.nl> d...@cwi.nl (Dik T. Winter) writes:
>
>| In article <1992Jul23.2...@dscomsf.desy.de> hal...@zeus02.desy.de writes:
>| > Hell, I know someone who bought a new 9 track not too long ago, they
>| > [...]
>| Why not? On 9 track tape it is at least possible for the user to do
>| [...]
>
>DAT will do it; a lot easier to transport also!
Yeah, but what about the eleventy-seven bazillion 9-track TAPES which
presently exist in the world? :-)
I'm actually thinking of getting a new Qualstor with SCSI interface to
be able to read my existing archives of 1000s of 800, 1600 and 6250 BPI tapes
from our PDP-10, DEC-20, VAXen and customer machines.
Though we're still running two DEC-20 and four VAXen, we're probably going
to retire them this (or next) year, and a 9-track drive will still be
needed for compatibility. I'll bet those TU-78 drives won't connect to
an SGI Crimson! :-)
And, most importantly, I still have Zork, Dungeon, HAUNT, Fisk, and LUGI
archived on 9-track; wouldn't want to lose THOSE programs! :-)
Thad Floryan [ th...@btr.com (OR) {decwrl, mips, fernwood}!btr!thad ]
Thaddeus P. Floryan
>In article <1992Jul23.0...@unislc.uucp>, tha...@unislc.uucp (Thayne Forbes) writes:
>> Lets make it more challenging. Who still has any of these on a system
>> running today. How about any two? Anybody want to go for three? I
>> have 9-track and paper tape concurrently as late as 1982 (although I
>> [...]
I obviously got into this thread late; just "discovered" alt.folklore.computer
when I wondered where one of my articles in sci.electronics disappeared to
(due to a "Followup-to:").
In any event, paper tape isn't as archaic as you make think: though many of
the old Cintimatic (sp?) milling machines and Behrens punch presses long
since went to direct digital control, the garment industry still uses paper
for things like stitching names on jackets, etc.
I discovered this when a buddy wanted to produce some computer jackets and
placed a plea for help on the net (about 5 years ago). Luckily, I just
happened to have paper tape handling equipment on one of my systems; the
reason I had the PT stuff was because I discovered some "old" programs I
archived back some 30 years ago and I wanted to run them on some of my
home machines. Neat programs, like satellite orbit tracking stuff and
stripline and microstrip design programs (they work fine, BTW (they were
in Fortran, so I just used f2c from research.att.com to compile)). I
found the paper tape equipment at Weird Stuff Warehouse in Silicon Valley.
9-track is still in common use. In fact, the US Postal Service will send
the ZIP code data for EVERY single address in the USA on a set of 9-track
tapes, and the data is updated (I believe) every 3 months (for four sets
a year); this service costs $$$, but is important to bulk mailers and
the like.
If you wanna talk old tape stuff, then let's go back even before the
DECtapes and talk 7 track. Yeah, at 220, 556 and 800 BPI! And two formats,
one whose tracks were wider than the other. I can relate horror stories
such as attempting to read tapes from an RCA 3301 onto a PDP-10 and
re-writing them for a Burroughs B3500. What I had to do was read each tape
15 times (on 15 different PDP-10 systems (I was at Tymshare at the time,
back in the 1960s)) and do a "best-fit" merge to form one good data set.
And this was the complete (and ONLY) parts list for a US Navy aircraft! :-)
And there was something else also that used hanging tape strips (forget
what it was called, but I believe it was developed by Sperry in the late
1950s; I only saw it in operation once and said "This'll never fly"), such
that when a strip was "addressed", it would get sucked onto a drum and then
be processed something like the old Dictaphone machines of the early 1950s;
I don't recall how the strips were returned to their racks (maybe this is
why the idea never caught on! :-).
Thaddeus P. Floryan
>many people have been killed by computer/programmer error before (i.e., the
>type of thing we read about in comp.risks) I wonder if anyone has ever been
>killed by a computer?
We had a close call in 1989 during the Loma Prieta earthquake (in Silicon
Valley). A DEC TU78 tape drive on a DEC-20 fell over just missing one of
our operators by inches. Our Tymnet engine fell over and destroyed the
LA36 console on a VAX; only the door broke on the Tymnet box (and hasn't
been repaired to date).
In another incident, a floppy drive on a Mac II ejected "parts" that flew
out and poked one of our documentation writers in the eye causing a medical
insurance claim. I believe the part was a spring that had somehow become
dislodged.
And I've heard "stories" of old-time washing-machine-sized disk drives
waltzing around computer room floors and trapping operators against walls.
And what about the old story concerning the etymology of the word "bug"
as applied to computers, when Cmdr. Grace Hopper is alleged to have found
an electrocuted moth in the innards of one of the Navy's computers? :-)