Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.folklore.computers > #162948 > unrolled thread

Re: IBM's 96 column punch card (was System/3)?

Back to article view | Back to alt.folklore.computers

Contents

  Re: IBM's 96 column punch card (was System/3)? jmfbahciv <See.above@aol.com> - 2016-04-26 11:42 +0000
    Re: IBM's 96 column punch card (was System/3)? Jon Elson <jmelson@wustl.edu> - 2016-04-26 14:36 -0500
      Re: IBM's 96 column punch card (was System/3)? Morten Reistad <first@last.name.invalid> - 2016-04-27 00:42 +0200
        Re: IBM's 96 column punch card (was System/3)? scott@slp53.sl.home (Scott Lurndal) - 2016-04-27 13:48 +0000
          Re: IBM's 96 column punch card (was System/3)? Morten Reistad <first@last.name.invalid> - 2016-04-28 08:41 +0200
      Re: IBM's 96 column punch card (was System/3)? jmfbahciv <See.above@aol.com> - 2016-04-27 12:40 +0000
        Re: IBM's 96 column punch card (was System/3)? Andy Burns <feb2017-usenet@adslpipe.co.uk> - 2016-04-27 14:51 +0100
          Re: IBM's 96 column punch card (was System/3)? Jon Elson <elson@pico-systems.com> - 2016-04-27 22:27 -0500
            Re: IBM's 96 column punch card (was System/3)? jmfbahciv <See.above@aol.com> - 2016-04-28 12:06 +0000
              Re: IBM's 96 column punch card (was System/3)? Quadibloc <jsavard@ecn.ab.ca> - 2016-04-28 07:49 -0700
                Re: IBM's 96 column punch card (was System/3)? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-04-28 17:03 +0000
                  Re: IBM's 96 column punch card (was System/3)? "Osmium" <r124c4u102@comcast.net> - 2016-04-28 12:18 -0500
                    Re: IBM's 96 column punch card (was System/3)? Anne & Lynn Wheeler <lynn@garlic.com> - 2016-04-28 11:19 -0700
                      Re: IBM's 96 column punch card (was System/3)? hancock4@bbs.cpcn.com - 2016-04-28 14:19 -0700
                  Re: IBM's 96 column punch card (was System/3)? "Charles Richmond" <numerist@aquaporin4.com> - 2016-04-29 16:47 -0500
                Re: IBM's 96 column punch card (was System/3)? jmfbahciv <See.above@aol.com> - 2016-04-29 12:18 +0000
              Re: IBM's 96 column punch card (was System/3)? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-04-28 17:03 +0000
                Re: IBM's 96 column punch card (was System/3)? jmfbahciv <See.above@aol.com> - 2016-04-29 12:18 +0000
                  Re: IBM's 96 column punch card (was System/3)? Morten Reistad <first@last.name.invalid> - 2016-04-29 15:14 +0200
              Re: IBM's 96 column punch card (was System/3)? pechter@pechter.net (William Pechter) - 2016-05-03 14:09 +0000
        Re: IBM's 96 column punch card (was System/3)? Jon Elson <elson@pico-systems.com> - 2016-04-27 22:19 -0500
          Re: IBM's 96 column punch card (was System/3)? pechter@pechter.net (William Pechter) - 2016-05-03 14:21 +0000
        Re: IBM's 96 column punch card (was System/3)? pechter@pechter.net (William Pechter) - 2016-05-03 14:03 +0000
          Re: IBM's 96 column punch card (was System/3)? Jon Elson <jmelson@wustl.edu> - 2016-05-03 13:58 -0500
          Re: IBM's 96 column punch card (was System/3)? Jon Elson <jmelson@wustl.edu> - 2016-05-03 14:22 -0500
            Re: IBM's 96 column punch card (was System/3)? pechter@pechter.net (William Pechter) - 2016-05-04 20:21 +0000
          tape drives [was Re: IBM's 96 column punch card (was System/3)?] Rich Alderson <news@alderson.users.panix.com> - 2016-05-03 15:39 -0400
          Re: IBM's 96 column punch card (was System/3)? jmfbahciv <See.above@aol.com> - 2016-05-04 13:02 +0000
            Re: IBM's 96 column punch card (was System/3)? Jon Elson <elson@pico-systems.com> - 2016-05-04 11:45 -0500
              Re: IBM's 96 column punch card (was System/3)? Morten Reistad <first@last.name.invalid> - 2016-05-05 01:13 +0200
                Re: IBM's 96 column punch card (was System/3)? Jon Elson <jmelson@wustl.edu> - 2016-05-05 14:25 -0500
                  Re: IBM's 96 column punch card (was System/3)? scott@slp53.sl.home (Scott Lurndal) - 2016-05-05 19:34 +0000
                    Re: IBM's 96 column punch card (was System/3)? jmfbahciv <See.above@aol.com> - 2016-05-06 13:28 +0000
                      Re: IBM's 96 column punch card (was System/3)? scott@slp53.sl.home (Scott Lurndal) - 2016-05-06 14:39 +0000
                      Re: IBM's 96 column punch card (was System/3)? scott@slp53.sl.home (Scott Lurndal) - 2016-05-06 14:41 +0000
                        Re: IBM's 96 column punch card (was System/3)? jmfbahciv <See.above@aol.com> - 2016-05-07 13:14 +0000
                          Re: IBM's 96 column punch card (was System/3)? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-05-07 16:47 +0000
                            Re: IBM's 96 column punch card (was System/3)? Andrew Swallow <am.swallow@btopenworld.com> - 2016-05-07 23:30 +0100
                              Re: IBM's 96 column punch card (was System/3)? jmfbahciv <See.above@aol.com> - 2016-05-08 13:08 +0000
                          Re: IBM's 96 column punch card (was System/3)? Jon Elson <elson@pico-systems.com> - 2016-05-07 16:07 -0500
                          Re: IBM's 96 column punch card (was System/3)? scott@slp53.sl.home (Scott Lurndal) - 2016-05-07 21:23 +0000
                            Re: IBM's 96 column punch card (was System/3)? jmfbahciv <See.above@aol.com> - 2016-05-08 13:08 +0000
                              Re: IBM's 96 column punch card (was System/3)? scott@slp53.sl.home (Scott Lurndal) - 2016-05-09 15:13 +0000
                                Re: IBM's 96 column punch card (was System/3)? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-05-09 17:05 +0000
                                  Re: IBM's 96 column punch card (was System/3)? pechter@pechter.net (William Pechter) - 2016-05-09 22:41 +0000
                                    Re: IBM's 96 column punch card (was System/3)? Morten Reistad <first@last.name.invalid> - 2016-05-10 12:01 +0200
                                      Re: IBM's 96 column punch card (was System/3)? Peter Flass <peter_flass@yahoo.com> - 2016-05-10 06:42 -0400
                                    Re: IBM's 96 column punch card (was System/3)? jmfbahciv <See.above@aol.com> - 2016-05-10 12:34 +0000
                                      Re: IBM's 96 column punch card (was System/3)? scott@slp53.sl.home (Scott Lurndal) - 2016-05-10 13:05 +0000
                                        Re: IBM's 96 column punch card (was System/3)? jmfbahciv <See.above@aol.com> - 2016-05-11 12:18 +0000
                                          Re: IBM's 96 column punch card (was System/3)? scott@slp53.sl.home (Scott Lurndal) - 2016-05-11 13:27 +0000
                                      Re: IBM's 96 column punch card (was System/3)? Morten Reistad <first@last.name.invalid> - 2016-05-10 15:53 +0200
                                        Re: IBM's 96 column punch card (was System/3)? jmfbahciv <See.above@aol.com> - 2016-05-11 12:18 +0000
                                Re: IBM's 96 column punch card (was System/3)? "Simo" <dhy287@gmail.com> - 2016-05-10 04:56 +1000

Page 1 of 3  [1] 2 3  Next page →

#162948 — Re: IBM's 96 column punch card (was System/3)?

Dan Espen wrote:
> hancock4@bbs.cpcn.com writes:
>
>> On Saturday, April 23, 2016 at 6:07:27 PM UTC-4, D_J_E wrote:
>>
>>> That does not change the fact that a IBM 14xx with a 1311 drive
>>> could and did operate for years without ever reporting a disk
>>> error.
>>
>> Some examples...
>>
>> Our 2314 locked up and our entire S/360 was dead until the C/E
>> could come to reset it.  Lost a morning's production.
>>
>> Our 3705 locked up after a momentary power surge.  Took forever
>> to restart; in the meantime, the entire 3270 network was down.
>>
>> Our I/O controller locked up for a few days until they fixed it.
>>
>>> I started before S/360.
>>> The machines I worked with were way more reliable than the old
>>> EAM stuff.
>>
>> Ok, but with EAM stuff you could pull out the offending card,
>> visually examine it, and restart things relatively easily.
>
> A mangled card is easy to fix.  An actual broken EAM machine
> was just as hard to fix as a computer.
>
>> Not as easily done with electronic computers.  People here have reported
>> using a special fluid and ironing filings to view mag tape contents.
>
> I've read that iron filings story a couple of times here.
> Never heard the story anywhere else, even a second hand recounting.
> That kind of action should not be necessary.  That's what
> backups are for.
>
> I once had to guide a site through backup restore and the first
> generation backups were no good.  Took quite a while but we
> got the data back by going back another generation.

The guy who wrote the software for the TU78 had to resort to using
iron filing fluid debug the hard/software for a while.  I hated that
controller.

/BAH

[toc] | [next] | [standalone]

#162962

jmfbahciv wrote:


> The guy who wrote the software for the TU78 had to resort to using
> iron filing fluid debug the hard/software for a while.  I hated that
> controller.
You could view an 800 BPI tape very easily with magna-see, and even read the 
data out.

1600 BPI was a lot harder to see, as the data was encoded in the location of 
the flux changes, and there was a flux change every bit time in the track.

6250 BPI would be impossible to actually read anything.  You could verify 
the size of the data blocks and the gaps, but not much else.  Most GCR 
formatters did not allow you to see much of what was in the raw data, 
either, so they either read the data with some errors, or they gave you 
nothing at all.  So, if the format was more than a little off, it could be 
quite hard to tell what was wrong.  I suppose you could hook a logic 
analyzer to the read amps and then you'd be able to pick it apart.


Our first 780 had a TU77, and it had a LOT of problems, mostly related to 
heat buildup almost melting the tape.  There were several phases of mod kits 
put on, the last one was a huge radiator for the bearing air and a row of 
boxer fans to cool it.  I always WISHED we had a TU78 as the backups took 13 
tapes per drive at 1600.

Our 2nd 780 had Storage Tek 6250 drives.  They were very reliable, but the 
formatter was bigger than a PDP-11/44.


Jon

[toc] | [prev] | [next] | [standalone]

#162968

In article <I4udnfRhIayzXoLKnZ2dnUU7-UXNnZ2d@giganews.com>,
Jon Elson  <jmelson@wustl.edu> wrote:
>jmfbahciv wrote:
>
>
>> The guy who wrote the software for the TU78 had to resort to using
>> iron filing fluid debug the hard/software for a while.  I hated that
>> controller.
>You could view an 800 BPI tape very easily with magna-see, and even read the 
>data out.
>
>1600 BPI was a lot harder to see, as the data was encoded in the location of 
>the flux changes, and there was a flux change every bit time in the track.
>
>6250 BPI would be impossible to actually read anything.  You could verify 
>the size of the data blocks and the gaps, but not much else.  Most GCR 
>formatters did not allow you to see much of what was in the raw data, 
>either, so they either read the data with some errors, or they gave you 
>nothing at all.  So, if the format was more than a little off, it could be 
>quite hard to tell what was wrong.  I suppose you could hook a logic 
>analyzer to the read amps and then you'd be able to pick it apart.
>
>
>Our first 780 had a TU77, and it had a LOT of problems, mostly related to 
>heat buildup almost melting the tape.  There were several phases of mod kits 
>put on, the last one was a huge radiator for the bearing air and a row of 
>boxer fans to cool it.  I always WISHED we had a TU78 as the backups took 13 
>tapes per drive at 1600.

When it came to 9" tapes there were IBM, Kennedy and everyone else. Many
BUNCH drives were Kennedy OEMs, as were the top end ND, Siemens and Prime.
But only on the larger, more expensive, commercial models.

They had impressive reliability. And they had a unique, quite violent feel.
The condenser bank for the vacuum and servos were 6F @ 120V. Yep. 6 Farads.
No prefix. They went from standstill to streaming in ~20 ms with a 10kg++
moving moment.

My PPOE got hold of 6 of these. 3 connected to a Tandem and 3 to Primes.

We used to scare newbies by loading a tape without the protective cover
on, holding a finger over the sensor. It made an impressive "chooff" sound
as the air was sucked out in a few hundred ms.

>Our 2nd 780 had Storage Tek 6250 drives.  They were very reliable, but the 
>formatter was bigger than a PDP-11/44.

The Kennedys each took 22U in a 19" rack.

-- mrr

[toc] | [prev] | [next] | [standalone]

#162994

Morten Reistad <first@last.name.invalid> writes:

>When it came to 9" tapes there were IBM, Kennedy and everyone else. Many

                 9 track?

>BUNCH drives were Kennedy OEMs, as were the top end ND, Siemens and Prime.
>But only on the larger, more expensive, commercial models.

  UNCH, perhaps.   The Burroughs 7- and 9-track drives were designed and built by
burroughs until the early 80s, and later were either STC, Memorex or Fujitsu
drives (by the late 80s).  They did offer a couple of rebadged kennedy table-top
streamers in the early 90's.

[toc] | [prev] | [next] | [standalone]

#163022

In article <Bq3Uy.48339$9E1.12096@fx43.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
>Morten Reistad <first@last.name.invalid> writes:
>
>>When it came to 9" tapes there were IBM, Kennedy and everyone else. Many
>
>                 9 track?

Yep, half inch, 9 track. Mea culpa.

>>BUNCH drives were Kennedy OEMs, as were the top end ND, Siemens and Prime.
>>But only on the larger, more expensive, commercial models.
>
>  UNCH, perhaps.   The Burroughs 7- and 9-track drives were designed and built by
>burroughs until the early 80s, and later were either STC, Memorex or Fujitsu
>drives (by the late 80s).  They did offer a couple of rebadged kennedy table-top
>streamers in the early 90's.

The Kennedy table top units were good, but sloooooww.

They arrived pretty late in the product range too.

-- mrr

[toc] | [prev] | [next] | [standalone]

#162991

Jon Elson wrote:
> jmfbahciv wrote:
>
>
>> The guy who wrote the software for the TU78 had to resort to using
>> iron filing fluid debug the hard/software for a while.  I hated that
>> controller.
> You could view an 800 BPI tape very easily with magna-see, and even read the
> data out.
>
> 1600 BPI was a lot harder to see, as the data was encoded in the location of
> the flux changes, and there was a flux change every bit time in the track.
>
> 6250 BPI would be impossible to actually read anything.  You could verify
> the size of the data blocks and the gaps, but not much else.  Most GCR
> formatters did not allow you to see much of what was in the raw data,
> either, so they either read the data with some errors, or they gave you
> nothing at all.  So, if the format was more than a little off, it could be
> quite hard to tell what was wrong.  I suppose you could hook a logic
> analyzer to the read amps and then you'd be able to pick it apart.
>
>
> Our first 780 had a TU77, and it had a LOT of problems, mostly related to
> heat buildup almost melting the tape.  There were several phases of mod kits
> put on, the last one was a huge radiator for the bearing air and a row of
> boxer fans to cool it.  I always WISHED we had a TU78 as the backups took 13
> tapes per drive at 1600.

DEC never managed to manufacture a good tape drive.  My favorite was the
TU70s followed by TU40s.  Everything else hung a PDP-10 was crap.  I always
wondered why we couldn't make a good tape drive since we did make the
best tape mechanism called DECtapes (the real DECtapes, not those others
they called DECtapes to make them look good).

>
> Our 2nd 780 had Storage Tek 6250 drives.  They were very reliable, but the
> formatter was bigger than a PDP-11/44.

If you wanted reliable magtapes, it required lots of good, working gear.

/BAH

[toc] | [prev] | [next] | [standalone]

#162995

jmfbahciv wrote:

> DEC never managed to manufacture a good tape drive.  My favorite was the
> TU70s followed by TU40s.

We had a table-top Cipher F880 that had been retrofitted with a SCSI 
interface and hung off a uVAX 3100 to send updates out to customers who 
couldn't take TK50s.  The number of times I had to prop the "bonnet" 
open on it and persuade the tape leader to go in because the vacuum 
wasn't strong enough to suck it in ... weighed a ton too.

[toc] | [prev] | [next] | [standalone]

#163020

Andy Burns wrote:

> jmfbahciv wrote:
> 
>> DEC never managed to manufacture a good tape drive.  My favorite was the
>> TU70s followed by TU40s.
> 
> We had a table-top Cipher F880 that had been retrofitted with a SCSI
> interface and hung off a uVAX 3100 to send updates out to customers who
> couldn't take TK50s.  The number of times I had to prop the "bonnet"
> open on it and persuade the tape leader to go in because the vacuum
> wasn't strong enough to suck it in ... weighed a ton too.
Yes, the stuff a half-inch tape in a slot and push a button streamer drives 
had all sorts of Rube Goldberg schemes for autothreading, I never saw one 
that worked very reliably.

We bought a SCSI-adapted Cipher 990 (same mechanism, but 1600/6250) and it 
was a complete pile of junk.  It had to stay on all the time or it would 
crash the SCSI bus.  And, if you left it on all the time, about once a 
month, one of the read channel chips would die.  These cost something like 
$60.  I kept it running for about half a year, and then just gave up.

I bought some used CDC Keystone drives (92185 - 1600/6250 density) with 
Pertec formatted interface.  One of them still runs, and I read in a tape 
every once in a while.  These things must be 30 years old for sure!

Jon

[toc] | [prev] | [next] | [standalone]

#163028

Jon Elson wrote:
> Andy Burns wrote:
>
>> jmfbahciv wrote:
>>
>>> DEC never managed to manufacture a good tape drive.  My favorite was the
>>> TU70s followed by TU40s.
>>
>> We had a table-top Cipher F880 that had been retrofitted with a SCSI
>> interface and hung off a uVAX 3100 to send updates out to customers who
>> couldn't take TK50s.  The number of times I had to prop the "bonnet"
>> open on it and persuade the tape leader to go in because the vacuum
>> wasn't strong enough to suck it in ... weighed a ton too.
> Yes, the stuff a half-inch tape in a slot and push a button streamer drives
> had all sorts of Rube Goldberg schemes for autothreading, I never saw one
> that worked very reliably.
>
> We bought a SCSI-adapted Cipher 990 (same mechanism, but 1600/6250) and it
> was a complete pile of junk.  It had to stay on all the time or it would
> crash the SCSI bus.  And, if you left it on all the time, about once a
> month, one of the read channel chips would die.  These cost something like
> $60.  I kept it running for about half a year, and then just gave up.
>
> I bought some used CDC Keystone drives (92185 - 1600/6250 density) with
> Pertec formatted interface.  One of them still runs, and I read in a tape
> every once in a while.  These things must be 30 years old for sure!

I never understood why it was so difficult to design a magtape drive
but I didn't investigate the problems.  It just seemed like the
latest device was based on NIH mentalities, never using the aspects
which worked.  Of course, none of the hardware developers ever
had to work 8 hours/day using the drives they designed.  I always
wanted them to be operators for at least a month; the same was true
for the disk drive designers.

/BAH

[toc] | [prev] | [next] | [standalone]

#163030

On Thursday, April 28, 2016 at 6:07:08 AM UTC-6, jmfbahciv wrote:
> It just seemed like the
> latest device was based on NIH mentalities, never using the aspects
> which worked.

Given that IBM invented the vacuum column, maybe the other companies couldn't 
afford what IBM was asking for cross-licensing?

John Savard

[toc] | [prev] | [next] | [standalone]

#163032

On 2016-04-28, Quadibloc <jsavard@ecn.ab.ca> wrote:

> On Thursday, April 28, 2016 at 6:07:08 AM UTC-6, jmfbahciv wrote:
>
>> It just seemed like the
>> latest device was based on NIH mentalities, never using the aspects
>> which worked.
>
> Given that IBM invented the vacuum column, maybe the other companies couldn't 
> afford what IBM was asking for cross-licensing?

If so, Univac and Honeywell (two that I used) didn't seem to have a problem;
their drives had vacuum columns.  But maybe pennies were tighter at DEC.

-- 
/~\  cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ /  I'm really at ac.dekanfrus if you read it the right way.
 X   Top-posted messages will probably be ignored.  See RFC1855.
/ \  HTML will DEFINITELY be ignored.  Join the ASCII ribbon campaign!

[toc] | [prev] | [next] | [standalone]

#163033

"Charlie Gibbs" wrote:

> On 2016-04-28, Quadibloc <jsavard@ecn.ab.ca> wrote:
>
>> On Thursday, April 28, 2016 at 6:07:08 AM UTC-6, jmfbahciv wrote:
>>
>>> It just seemed like the
>>> latest device was based on NIH mentalities, never using the aspects
>>> which worked.
>>
>> Given that IBM invented the vacuum column, maybe the other companies 
>> couldn't
>> afford what IBM was asking for cross-licensing?
>
> If so, Univac and Honeywell (two that I used) didn't seem to have a 
> problem;
> their drives had vacuum columns.  But maybe pennies were tighter at DEC.

Univac had a cross-licensing agreement with IBM so that wouldn't be an 
impediment.  This is the first time I heard that IBM had such a patent.

In the late 50's I thought the main tape problem was that many of the tape 
drives were designed for telemetry and someone in their marketing department 
said "Hey, these would be great on computers, too".  They weren't great at 
all. 

[toc] | [prev] | [next] | [standalone]

#163034

"Osmium" <r124c4u102@comcast.net> writes:
> In the late 50's I thought the main tape problem was that many of the
> tape drives were designed for telemetry and someone in their marketing
> department said "Hey, these would be great on computers, too".  They
> weren't great at all. 

Fifty years of storage innovation; Magnetic tape and beyond 
https://www-03.ibm.com/ibm/history/exhibits/storage/storage_fifty.html

The Setting

June 1949: Recorded music was on 78 rpm platters and "wire recorders"
were the mainstay of radio. Magnetic tape had only recently emerged from
the laboratory into a few broadcasts. A room full of vacuum tubes and
miles of wire accomplished what a handheld calculator would be able to
do faster by the 1980s. Information storage meant books, filing cabinets
or -- to those at the leading edge of data processing technology --
paper punch cards. Reels of tape, tape cartridges and programmable
computers were the stuff of science fiction.

IBM was about to change all that.

The Challenge

A more compact means of storing data permanently had to be developed.
The U.S. Social Security Administration was pressing IBM to solve this
record storage problem -- acres of filing cabinets filled with punch
cards containing social security data about every working American.

... 

Byron Phelps, patent holder and principal figure in developing magnetic
tape, recalled, "We had tried more dense paper cards for data storage,
but the improvement was only a few times better. Punched paper tape
offered no great advantage either. Magnetic tape had just come into its
own in audio and offered the most promise."

... snip ...

IBM 701 Tape Drive; The First Magnetic Tape Drive for Computer Data
Storage
http://www.columbia.edu/cu/computinghistory/701-tape.html

In 1949, IBM began to plan for a new storage and i/o medium to take the
place of punched cards. The new medium would be more compact, faster,
cheaper, and reusable. Magnetic tape technology had been used for audio
recording and playback since World War II, and it was adapted for
computer use -- initially in a prototype called the Tape Processing
Machine (TPM), 1950-51. Of course computer data storage and retrieval is
different from audio recording and playback, requiring accurate
positioning (both forwards and backwards) to arbitrary spots and
therefore much fancier motors, not to mention stress relief for the tape
itself, accomplished with vacuum columns (invented by IBM). New digital
recording techniques were developed allowing mapping of computer memory
to tape with error detection, coding of records and boundaries, and so
forth.

... snip ...

-- 
virtualization experience starting Jan1968, online at home since Mar1970

[toc] | [prev] | [next] | [standalone]

#163042

On Thursday, April 28, 2016 at 2:19:27 PM UTC-4, Anne & Lynn Wheeler wrote:
> In 1949, IBM began to plan for a new storage and i/o medium to take the
> place of punched cards. The new medium would be more compact, faster,
> cheaper, and reusable. Magnetic tape technology had been used for audio
> recording and playback since World War II, and it was adapted for
> computer use -- initially in a prototype called the Tape Processing
> Machine (TPM), 1950-51. Of course computer data storage and retrieval is
> different from audio recording and playback, requiring accurate
> positioning (both forwards and backwards) to arbitrary spots and
> therefore much fancier motors, not to mention stress relief for the tape
> itself, accomplished with vacuum columns (invented by IBM). New digital
> recording techniques were developed allowing mapping of computer memory
> to tape with error detection, coding of records and boundaries, and so
> forth.

People today take for granted all the technical innovation to make
things work as fast and reliably as they do. But it took a heck of
a lot of research and trial/error back in the 1950s to make it all
work out.  The early IBM history has a lot on this, plus there is
stuff on bitsavers.  They had to try a lot of techniques before
finding ones that would work as desired and be cost effective.

IBM also had to work with the raw tape manufacturers to develop
both a tape base strong enough to be handled, a magnetic coating 
that was stable and not flake off, and had the desired magnetic
properties (hard to do initially).  I don't know how many "9s" 
the reliability percentage had, but it had to be damned high
in order to convince businesses that they could trust their
records and processing to magnetic tape.  While some
businesses were desperate for better storage (smaller footprint),
others were quite nervous to switch over to an "unseen" medium.

In the early 1960s, Computers & Automation is loaded with ads
from various mag tape manufacturers touting their particular
tape.

[toc] | [prev] | [next] | [standalone]

#163062

"Charlie Gibbs" <cgibbs@kltpzyxm.invalid> wrote in message 
news:nftfpu02n8q@news7.newsguy.com...
> On 2016-04-28, Quadibloc <jsavard@ecn.ab.ca> wrote:
>
>> On Thursday, April 28, 2016 at 6:07:08 AM UTC-6, jmfbahciv wrote:
>>
>>> It just seemed like the
>>> latest device was based on NIH mentalities, never using the aspects
>>> which worked.
>>
>> Given that IBM invented the vacuum column, maybe the other companies 
>> couldn't
>> afford what IBM was asking for cross-licensing?
>
> If so, Univac and Honeywell (two that I used) didn't seem to have a 
> problem;
> their drives had vacuum columns.  But maybe pennies were tighter at DEC.
>

At Harris Computers back in the 80s, *everything* was OEM except the 
computer and IO boards... and perhaps the cabinets.  Disk drives came from 
Control Data or Fujitsu, terminals came from Beehive and Wyse, I don't know 
who made the mag tape drives, and the lineprinter came from Printronics.  Of 
course, everything was re-labeled as Harris.  Certainly Harris had some 
great compiler writers and system programmers that worked for them.  Harris' 
FORTRAN77 compiler was a wonder at optimization!!!

-- 

numerist at aquaporin4 dot com

[toc] | [prev] | [next] | [standalone]

#163049

Quadibloc wrote:
> On Thursday, April 28, 2016 at 6:07:08 AM UTC-6, jmfbahciv wrote:
>> It just seemed like the
>> latest device was based on NIH mentalities, never using the aspects
>> which worked.
>
> Given that IBM invented the vacuum column, maybe the other companies
couldn't
> afford what IBM was asking for cross-licensing?


Oh, it wasn't just the vacuum loading cycle which sucked.

/BAH

[toc] | [prev] | [next] | [standalone]

#163031

On 2016-04-28, jmfbahciv <See.above@aol.com> wrote:

> I never understood why it was so difficult to design a magtape drive
> but I didn't investigate the problems.  It just seemed like the
> latest device was based on NIH mentalities, never using the aspects
> which worked.  Of course, none of the hardware developers ever
> had to work 8 hours/day using the drives they designed.  I always
> wanted them to be operators for at least a month; the same was true
> for the disk drive designers.

Not to mention software developers.

I always loved that phrase "eat your own dog food".

-- 
/~\  cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ /  I'm really at ac.dekanfrus if you read it the right way.
 X   Top-posted messages will probably be ignored.  See RFC1855.
/ \  HTML will DEFINITELY be ignored.  Join the ASCII ribbon campaign!

[toc] | [prev] | [next] | [standalone]

#163050

Charlie Gibbs wrote:
> On 2016-04-28, jmfbahciv <See.above@aol.com> wrote:
>
>> I never understood why it was so difficult to design a magtape drive
>> but I didn't investigate the problems.  It just seemed like the
>> latest device was based on NIH mentalities, never using the aspects
>> which worked.  Of course, none of the hardware developers ever
>> had to work 8 hours/day using the drives they designed.  I always
>> wanted them to be operators for at least a month; the same was true
>> for the disk drive designers.
>
> Not to mention software developers.
>
> I always loved that phrase "eat your own dog food".
>
After a disasterous ship of TOPS-10, we started to run the week's
monitor edit.  The monitor edit was Tuesday and JMF/TW spent
Wednesday morning's stand alone time getting the edit to run.
then operations asked that we invoke a rule; so we agreed
to allow operations to drop back to a previous edit after
three crashes.  Someone would figure out a patch to prevent
the crashes and produce another monitor which would be
loaded after the next crash.  (During a monitor development
cycle, there were always crashes; the number of crashes/day
would diminish as time went on.

/BAH

[toc] | [prev] | [next] | [standalone]

#163052

In article <PM0005319EA3DA0AAC@aca416fa.ipt.aol.com>,
jmfbahciv  <See.above@aol.com> wrote:
>Charlie Gibbs wrote:
>> On 2016-04-28, jmfbahciv <See.above@aol.com> wrote:
>>
>>> I never understood why it was so difficult to design a magtape drive
>>> but I didn't investigate the problems.  It just seemed like the
>>> latest device was based on NIH mentalities, never using the aspects
>>> which worked.  Of course, none of the hardware developers ever
>>> had to work 8 hours/day using the drives they designed.  I always
>>> wanted them to be operators for at least a month; the same was true
>>> for the disk drive designers.
>>
>> Not to mention software developers.
>>
>> I always loved that phrase "eat your own dog food".
>>
>After a disasterous ship of TOPS-10, we started to run the week's
>monitor edit.  The monitor edit was Tuesday and JMF/TW spent
>Wednesday morning's stand alone time getting the edit to run.
>then operations asked that we invoke a rule; so we agreed
>to allow operations to drop back to a previous edit after
>three crashes.  Someone would figure out a patch to prevent
>the crashes and produce another monitor which would be
>loaded after the next crash.  (During a monitor development
>cycle, there were always crashes; the number of crashes/day
>would diminish as time went on.

This is something you should write more extensively about, because
it is from a time long gone. Now we have lots and lots of test
hardware, and the development does not have to worry about having
stand alone time on hardware anymore, except for some very rare
ultra large servers and supercomputers.  These largely use
99.5% of the software built for smaller machines, with only some
very small adaptions.

I have done three stints of driver implementation on Linux. Every
time I used at least 4 different machines, two for the actual
testing, and at least two for source storage, editing and builds.

I would guess I am one to two orders of magnitude more productive
in the number of edit/compile/build/run/evaluate/crash cycles, I could
do hundreds of these in a week; and I could edit and build while the
test machines were rebooting.

Not so when hardware was scarce. I remember this time very vividly.
At a PPOE we had production time 0700-1900 on weekdays; and 
emergency recovery tests every first saturday in the month.

Development was either relegated to 5-year-old and very flaky and
slow previous generation machines, or to the off-production time.
It took 3 hours to do a backup, and 4-5 to do a restore of the
production system; so when we could run virtualised we saved an
enourmous amount of time.

-- mrr

[toc] | [prev] | [next] | [standalone]

#163138

In article <PM0005318A62FF5FAD@aca41083.ipt.aol.com>,
jmfbahciv  <See.above@aol.com> wrote:
>I never understood why it was so difficult to design a magtape drive
>but I didn't investigate the problems.  It just seemed like the
>latest device was based on NIH mentalities, never using the aspects
>which worked.  Of course, none of the hardware developers ever
>had to work 8 hours/day using the drives they designed.  I always
>wanted them to be operators for at least a month; the same was true
>for the disk drive designers.
>
>/BAH


Story I heard from (wish I remember his first name) Arcenault in Ed Services
training on the TU45 (I think he taught me that one and the RP05/6)...
DEC didn't have any tape engineers so they used the guy who did the RK05
to work on the TU16. 

One problem they designed into the drive was centering the head between the
Supply and Takeup reels.

Why is that a problem.  On a tape drive with taught tape where's the most
vibration -- on the center of the tape between the two aligning bearing points.
So the most wobble is right over the head.  And on an NRZI 800bpi tape it
was a pretty crappy idea.

This is one of the reasons they came out with the TE10/TE16 as a replacement
for the TU10/TU16...

The other dumb idea is the split vacuum on the TU45 which would drop vacuum
so quickly on slightly scalloped tape edges since a loss of top or bottom seal
took out both loops at the same time made it harder to isolate.

Bill
-- 
-- 
Digital had it then.  Don't you wish you could buy it now!
pechter-at-gmail.com  http://xkcd.com/705/

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | alt.folklore.computers

csiph-web