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

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

Re: The True Aficionado?

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: The True Aficionado? jmfbahciv <See.above@aol.com> - 2016-02-21 15:48 +0000
    Re: The True Aficionado? mentificium@gmail.com - 2016-02-21 13:43 -0800
      Re: The True Aficionado? jmfbahciv <See.above@aol.com> - 2016-02-23 13:13 +0000
        Re: The True Aficionado? mentificium@gmail.com - 2016-02-23 06:06 -0800
        Re: The True Aficionado? "hgww" <hgww@gmail.com> - 2016-02-24 04:40 +1100
          Re: The True Aficionado? Quadibloc <jsavard@ecn.ab.ca> - 2016-02-23 09:50 -0800
          Re: The True Aficionado? jmfbahciv <See.above@aol.com> - 2016-02-24 13:40 +0000
            Re: The True Aficionado? "hgww" <hgww@gmail.com> - 2016-02-25 03:14 +1100
              Re: The True Aficionado? jmfbahciv <See.above@aol.com> - 2016-03-01 13:55 +0000
                Re: The True Aficionado? "Rod Speed" <rod.speed.aaa@gmail.com> - 2016-03-02 01:30 +1100
                  Re: The True Aficionado? jmfbahciv <See.above@aol.com> - 2016-03-02 14:19 +0000
                    Re: The True Aficionado? "Rod Speed" <rod.speed.aaa@gmail.com> - 2016-03-03 03:51 +1100
                      Re: The True Aficionado? jmfbahciv <See.above@aol.com> - 2016-03-03 13:39 +0000
                        Re: The True Aficionado? Morten Reistad <first@last.name.invalid> - 2016-03-03 16:18 +0100
                          Re: The True Aficionado? "Rod Speed" <rod.speed.aaa@gmail.com> - 2016-03-04 03:52 +1100
                          Re: The True Aficionado? jmfbahciv <See.above@aol.com> - 2016-03-04 13:22 +0000
                            Re: The True Aficionado? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-03-04 16:33 +0000
                              Re: The True Aficionado? "Charles Richmond" <numerist@aquaporin4.com> - 2016-03-04 15:47 -0600
                                Re: The True Aficionado? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-03-05 01:04 +0000
                              Re: The True Aficionado? jmfbahciv <See.above@aol.com> - 2016-03-05 13:57 +0000
                              Re: The True Aficionado? hancock4@bbs.cpcn.com - 2016-03-06 11:40 -0800
                                Re: The True Aficionado? "Osmium" <r124c4u102@comcast.net> - 2016-03-06 23:18 -0600
                            Re: The True Aficionado? Morten Reistad <first@last.name.invalid> - 2016-03-04 17:18 +0100
                              Re: The True Aficionado? Dan Espen <despen@verizon.net> - 2016-03-04 22:09 -0500
                              Re: The True Aficionado? jmfbahciv <See.above@aol.com> - 2016-03-05 13:57 +0000
                                Re: The True Aficionado? Huge <Huge@nowhere.much.invalid> - 2016-03-05 14:36 +0000
                                  Re: The True Aficionado? jmfbahciv <See.above@aol.com> - 2016-03-06 14:08 +0000
                                    Re: The True Aficionado? "Sangmo" <ju410@gmail.com> - 2016-03-07 02:03 +1100
                                    Re: The True Aficionado? Morten Reistad <first@last.name.invalid> - 2016-03-06 17:28 +0100
                                      Re: The True Aficionado? hancock4@bbs.cpcn.com - 2016-03-06 11:54 -0800
                                        Re: The True Aficionado? "Sangmo" <ju410@gmail.com> - 2016-03-07 07:39 +1100
                                        Re: The True Aficionado? Peter Flass <peter_flass@yahoo.com> - 2016-03-06 17:24 -0700
                                Re: The True Aficionado? Morten Reistad <first@last.name.invalid> - 2016-03-05 18:43 +0100
                                Re: The True Aficionado? hancock4@bbs.cpcn.com - 2016-03-06 11:34 -0800
                              Re: The True Aficionado? Jon Elson <jmelson@wustl.edu> - 2016-03-07 16:24 -0600
                        Re: The True Aficionado? "Rod Speed" <rod.speed.aaa@gmail.com> - 2016-03-04 03:45 +1100
                        Re: The True Aficionado? "Charles Richmond" <numerist@aquaporin4.com> - 2016-03-03 16:01 -0600

Page 2 of 2 — ← Prev page 1 [2]

#160617

On Friday, March 4, 2016 at 11:32:08 AM UTC-5, Charlie Gibbs wrote:

> On 2016-03-04, JMF wrote:
> 
> > I know anthromorphizing a system isn't accurate but I could never
> > figure out a qualitative description.  You can feel when something
> > is going wrong, too.
> 
> "You shouldn't anthropomorphize computers.  They don't like it."

Steam locomotives were known to have individual characteristics, and 
engineers had to learn them to best operate them.  However, I don't
believe diesel engines were the same; they were more mass produced
(which was part of their advantage; they were easier to maintain).

They used to say that it would take a minute to debug a steam engine
but an hour to repair, while it would take an hour to debug a diesel
but a minute to repair.  Diesel power often ran as multiple units.
Sometimes on the road, one of the units would fail, but the other units
would keep the train moving.  The fireman had to go back into the engine
room and try to identify and fix the problem.  It was not a fun job.
I believe today's units are far more reliable.

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

#160645

<hancock4@bbs.cpcn.com> wrote:

> Steam locomotives were known to have individual characteristics, and
> engineers had to learn them to best operate them.  However, I don't
> believe diesel engines were the same; they were more mass produced
> (which was part of their advantage; they were easier to maintain).
>
> They used to say that it would take a minute to debug a steam engine
> but an hour to repair, while it would take an hour to debug a diesel
> but a minute to repair.  Diesel power often ran as multiple units.
> Sometimes on the road, one of the units would fail, but the other units
> would keep the train moving.  The fireman had to go back into the engine
> room and try to identify and fix the problem.  It was not a fun job.
> I believe today's units are far more reliable.

Your mention of repairing diesel engines in service reminded me of doing the 
same thing with airplanes.  I poked around and found this article in an old 
Popular Mechanics magazine from 1930.  The Dornier DO-X had tunnels in the 
wings so the mechanic could crawl out to one of the 12 engines and do minor 
repairs.  I think there were 288 spark plugs on those engines, two per 
cylinder.  There are lot of pictures of the plane itself on your favorite 
picture search engine.

https://books.google.com/books?id=qOIDAAAAMBAJ&pg=PA906&lpg=PA906&dq=dornier+do-x+engine+repair&source=bl&ots=bA-AFVxY9B&sig=lTAVunLt5GVc61HLxT7VKRx3hDY&hl=en&sa=X&ved=0ahUKEwjG9LTD4K3LAhVIn4MKHdAJBssQ6AEIVTAM#v=onepage&q=dornier%20do-x%20engine%20repair&f=false 

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

#160568

In article <PM00052D38F4E28E9A@aca41c7c.ipt.aol.com>,
jmfbahciv  <See.above@aol.com> wrote:
>Morten Reistad wrote:
>> In article <PM00052D2521DCF4E4@aca40c8f.ipt.aol.com>,
>> jmfbahciv  <See.above@aol.com> wrote:
>>>Rod Speed wrote:
>>>>
>>>>
>>>>> Every machine had its own "personality".
>>>>
>>>> They still do. BUT that has nothing to do with
>>>> stuff like the machines used to make the machine.
>>>> And so when we had humans who were JUST doing
>>>> what machines did later, the wire wrapping, THOSE
>>>> people contributed nothing to the personality.
>>>
>>>Of course they did.  Every wire-wrapped machine had it
>>>quirks.  Fixing hardware bugs could cause more quirks.
>>
>> Yes, I have accounts on around 200 machines around the
>> world. Most are just another collection of computing
>> power, like the SIP and web farms we load balance calls
>> to.
[snip, kirov summary]
>> It has a different personality, though.
>
>Oh, good. You understand what I'm trying to describe.
>I know anthromorphizing a system isn't accurate but I could never
>figure out a qualitative description.  You can feel when something
>is going wrong, too.
>

>> -- mrr
>>
>> [1] historical reference. The building did assassinate the
>> machine by letting a steel pipe come loose and dissect it.
>>
>
><grin>  Yesterday, I recalled the time a pail of water crashed
>through the ceiling behind KL1026.  Apparently, that was
>maintenance's "fix" for a leak.  Our operations supervisor
>was 2 feet away when it fell.

I have told the story of the RP07 going terrorist?

The RP07 had the heads enter the platters in a different direction
from most other drives. Mostly, head crashes just drag the heads along
the oxide. The RP07 had a failure mode where the heads buried 
instantly deep into the platter when they crashed. This made
significant havoc to the surroundings when the momentum of the
rotating platters were more or less instantly transferred to the
cabinet.

This happened one day at my old college. The cabinet was part of
a DEC2065 and was right next to one of the 6 strong steel supports
that held up the 9-story building. It was at the 2nd floor.

This day emacs froze and around 1 second later there was a *really*
loud bang in the building. Instant bomb alarm and full evacuation.
We all thought someone had bombed the computer facility, right below
the deans office.

But it was just an RP07 that had had this type of head crash and 
hit the steel support on it's way around the computer room.

It was found above the CPU cabinet; entangled in the cabling that
still mostly held. The CPU was still operating, but was not too happy
about a bit of swap space that was missing. The CPU cabinet had
a visible dent; but nothing except the cable attachments inside 
was damaged.

-- mrr

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

#160572

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

> In article <PM00052D38F4E28E9A@aca41c7c.ipt.aol.com>,
> jmfbahciv  <See.above@aol.com> wrote:
>>Morten Reistad wrote:
>>> In article <PM00052D2521DCF4E4@aca40c8f.ipt.aol.com>,
>>> jmfbahciv  <See.above@aol.com> wrote:
>>>>Rod Speed wrote:
>>>>>
>>>>>
>>>>>> Every machine had its own "personality".
>>>>>
>>>>> They still do. BUT that has nothing to do with
>>>>> stuff like the machines used to make the machine.
>>>>> And so when we had humans who were JUST doing
>>>>> what machines did later, the wire wrapping, THOSE
>>>>> people contributed nothing to the personality.
>>>>
>>>>Of course they did.  Every wire-wrapped machine had it
>>>>quirks.  Fixing hardware bugs could cause more quirks.
>>>
>>> Yes, I have accounts on around 200 machines around the
>>> world. Most are just another collection of computing
>>> power, like the SIP and web farms we load balance calls
>>> to.
> [snip, kirov summary]
>>> It has a different personality, though.
>>
>>Oh, good. You understand what I'm trying to describe.
>>I know anthromorphizing a system isn't accurate but I could never
>>figure out a qualitative description.  You can feel when something
>>is going wrong, too.
>>
>
>>> -- mrr
>>>
>>> [1] historical reference. The building did assassinate the
>>> machine by letting a steel pipe come loose and dissect it.
>>>
>>
>><grin>  Yesterday, I recalled the time a pail of water crashed
>>through the ceiling behind KL1026.  Apparently, that was
>>maintenance's "fix" for a leak.  Our operations supervisor
>>was 2 feet away when it fell.
>
> I have told the story of the RP07 going terrorist?
>
> The RP07 had the heads enter the platters in a different direction
> from most other drives. Mostly, head crashes just drag the heads along
> the oxide. The RP07 had a failure mode where the heads buried 
> instantly deep into the platter when they crashed. This made
> significant havoc to the surroundings when the momentum of the
> rotating platters were more or less instantly transferred to the
> cabinet.
>
> This happened one day at my old college. The cabinet was part of
> a DEC2065 and was right next to one of the 6 strong steel supports
> that held up the 9-story building. It was at the 2nd floor.
>
> This day emacs froze and around 1 second later there was a *really*
> loud bang in the building. Instant bomb alarm and full evacuation.
> We all thought someone had bombed the computer facility, right below
> the deans office.
>
> But it was just an RP07 that had had this type of head crash and 
> hit the steel support on it's way around the computer room.
>
> It was found above the CPU cabinet; entangled in the cabling that
> still mostly held. The CPU was still operating, but was not too happy
> about a bit of swap space that was missing. The CPU cabinet had
> a visible dent; but nothing except the cable attachments inside 
> was damaged.

Confirmed by similar stories at Columbia and Bell Labs:

http://www.columbia.edu/cu/computinghistory/rp06.html

But I looked at the Service Manual:

http://bitsavers.trailing-edge.com/pdf/dec/disc/rp07/ER-ORP07-SV_RP07_ServiceMan_Oct80.pdf

I see the platters and head on page 1-15, but I still don't see how the
arm grabs hold of the spindle.

I don't think I'd want to go in the same room with one.
Maybe not the same building.  I wonder if they could chain react.

-- 
Dan Espen

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

#160579

Morten Reistad wrote:
> In article <PM00052D38F4E28E9A@aca41c7c.ipt.aol.com>,
> jmfbahciv  <See.above@aol.com> wrote:
>>Morten Reistad wrote:
>>> In article <PM00052D2521DCF4E4@aca40c8f.ipt.aol.com>,
>>> jmfbahciv  <See.above@aol.com> wrote:
>>>>Rod Speed wrote:
>>>>>
>>>>>
>>>>>> Every machine had its own "personality".
>>>>>
>>>>> They still do. BUT that has nothing to do with
>>>>> stuff like the machines used to make the machine.
>>>>> And so when we had humans who were JUST doing
>>>>> what machines did later, the wire wrapping, THOSE
>>>>> people contributed nothing to the personality.
>>>>
>>>>Of course they did.  Every wire-wrapped machine had it
>>>>quirks.  Fixing hardware bugs could cause more quirks.
>>>
>>> Yes, I have accounts on around 200 machines around the
>>> world. Most are just another collection of computing
>>> power, like the SIP and web farms we load balance calls
>>> to.
> [snip, kirov summary]
>>> It has a different personality, though.
>>
>>Oh, good. You understand what I'm trying to describe.
>>I know anthromorphizing a system isn't accurate but I could never
>>figure out a qualitative description.  You can feel when something
>>is going wrong, too.
>>
>
>>> -- mrr
>>>
>>> [1] historical reference. The building did assassinate the
>>> machine by letting a steel pipe come loose and dissect it.
>>>
>>
>><grin>  Yesterday, I recalled the time a pail of water crashed
>>through the ceiling behind KL1026.  Apparently, that was
>>maintenance's "fix" for a leak.  Our operations supervisor
>>was 2 feet away when it fell.
>
> I have told the story of the RP07 going terrorist?
>
> The RP07 had the heads enter the platters in a different direction
> from most other drives. Mostly, head crashes just drag the heads along
> the oxide. The RP07 had a failure mode where the heads buried
> instantly deep into the platter when they crashed. This made
> significant havoc to the surroundings when the momentum of the
> rotating platters were more or less instantly transferred to the
> cabinet.
>
> This happened one day at my old college. The cabinet was part of
> a DEC2065 and was right next to one of the 6 strong steel supports
> that held up the 9-story building. It was at the 2nd floor.
>
> This day emacs froze and around 1 second later there was a *really*
> loud bang in the building. Instant bomb alarm and full evacuation.
> We all thought someone had bombed the computer facility, right below
> the deans office.
>
> But it was just an RP07 that had had this type of head crash and
> hit the steel support on it's way around the computer room.
>
> It was found above the CPU cabinet; entangled in the cabling that
> still mostly held. The CPU was still operating, but was not too happy
> about a bit of swap space that was missing. The CPU cabinet had
> a visible dent; but nothing except the cable attachments inside
> was damaged.

I don't remember that story.  I'm glad I never heard of it when
I was working.  I didn't like RP07s; if I had heard this story,
I would also be afraid of them.

Was the whole RP07 really above the CPU?  How in the world
did FS clean that out?

DEC's CPUs were hardy beasts.  One survived getting shot
when a frurstrated developer had a bad stand alone time.

/BAH

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

#160581

On 2016-03-05, jmfbahciv <See.above@aol.com> wrote:

[78 lines snipped]

> DEC's CPUs were hardy beasts.  One survived getting shot
> when a frurstrated developer had a bad stand alone time.

Troo dat.

I spent some time installing 11/34's in crisp (US: chip) factories
to run our process control stuff. Some of the installations were ...
sub-optimal (an un-airconditioned plywood shed in a corner of the 
factory, in one case). There was also a lot of grease & dirt about
as well as high temperatures. I don't ever recall their being a
hardware failure, although Field Circus raised an eyebrow or two.


-- 
Today is Prickle-Prickle, the 64th day of Chaos in the YOLD 3182
                  I don't have an attitude problem.
    If you have a problem with my attitude, that's your problem.

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

#160607

Huge wrote:
> On 2016-03-05, jmfbahciv <See.above@aol.com> wrote:
>
> [78 lines snipped]
>
>> DEC's CPUs were hardy beasts.  One survived getting shot
>> when a frurstrated developer had a bad stand alone time.
>
> Troo dat.
>
> I spent some time installing 11/34's in crisp (US: chip) factories
> to run our process control stuff. Some of the installations were ...
> sub-optimal (an un-airconditioned plywood shed in a corner of the
> factory, in one case). There was also a lot of grease & dirt about
> as well as high temperatures. I don't ever recall their being a
> hardware failure, although Field Circus raised an eyebrow or two.
>
>
PDP-8s (e.g. the 8/Is) seemed to be able to run in the filthiest
shops.

/BAH

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

#160611

"jmfbahciv" <See.above@aol.com> wrote in message 
news:PM00052D61E239EDA3@aca4072c.ipt.aol.com...
> Huge wrote:
>> On 2016-03-05, jmfbahciv <See.above@aol.com> wrote:
>>
>> [78 lines snipped]
>>
>>> DEC's CPUs were hardy beasts.  One survived getting shot
>>> when a frurstrated developer had a bad stand alone time.
>>
>> Troo dat.
>>
>> I spent some time installing 11/34's in crisp (US: chip) factories
>> to run our process control stuff. Some of the installations were ...
>> sub-optimal (an un-airconditioned plywood shed in a corner of the
>> factory, in one case). There was also a lot of grease & dirt about
>> as well as high temperatures. I don't ever recall their being a
>> hardware failure, although Field Circus raised an eyebrow or two.
>>
>>
> PDP-8s (e.g. the 8/Is) seemed to be able to run in the filthiest shops.

Yeah, the largest chicken producing operation in the southern
hemisphere is just down the road from where I used to work and
at one time their 8s were notorious for having a layer of chickens
shit dust right thru them, in the very early 70s. They improved things
considerably later as far as the chicken shit problem was concerned. 

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

#160612

In article <PM00052D61E239EDA3@aca4072c.ipt.aol.com>,
jmfbahciv  <See.above@aol.com> wrote:
>Huge wrote:
>> On 2016-03-05, jmfbahciv <See.above@aol.com> wrote:
>>
>> [78 lines snipped]
>>
>>> DEC's CPUs were hardy beasts.  One survived getting shot
>>> when a frurstrated developer had a bad stand alone time.
>>
>> Troo dat.
>>
>> I spent some time installing 11/34's in crisp (US: chip) factories
>> to run our process control stuff. Some of the installations were ...
>> sub-optimal (an un-airconditioned plywood shed in a corner of the
>> factory, in one case). There was also a lot of grease & dirt about
>> as well as high temperatures. I don't ever recall their being a
>> hardware failure, although Field Circus raised an eyebrow or two.
>>
>>
>PDP-8s (e.g. the 8/Is) seemed to be able to run in the filthiest
>shops.

I worked with PDP11s (/34's mostly) controlling welding and
steel stamping presses (bending 6mm steel like you fold up a
paper). They had extra filters installed in front of the intakes, 
but otherwise lived in a VERY compromised environment.

They worked just fine.

-- mrr

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

#160618

On Sunday, March 6, 2016 at 11:28:18 AM UTC-5, Morten Reistad wrote:

> I worked with PDP11s (/34's mostly) controlling welding and
> steel stamping presses (bending 6mm steel like you fold up a
> paper). They had extra filters installed in front of the intakes, 
> but otherwise lived in a VERY compromised environment.
> They worked just fine.

The IBM history talks about developing IBM's various process controllers,
e.g. the 1710, 1800, and System/7.  Given their applications, very high
reliability was a must.  However, given their applications, their work
environment wasn't so great.  It was a challenge.  IIRC, the IBM S/7 was
priced too expensive for its market and thus wasn't a big success.  I
think the 1800 (based on the 1130) was more successful.

bitsavers has a much of stuff on process control.  Admittedly, I don't 
understand a lot of it, but it makes for fascinating reading.  There
is one magazine reprint of a process controller for ancillary processes
of an oil refinery that's generally in layman's terms.  The setup,
programming, and testing effort must have been enormous since any bug
could ruin the output product or even be dangerous.  But I suspect
that even developing and debugging a manually operated process was also
quite a challenge.

A nearby chemical plant had an open house.  It was fascinating to see 
the control panels.  They seemed high tech, although they told us they
were actually rather old.  Operators would control the feed, 
temperature, and other factors in the "kettles" to make product.
(Too bad photography was strictly forbidden, lots of neat stuff).

I was surprised to learn that this huge plant only made intermediate
raw materials, not finished products.  For instance, they made red
pellets which were later used to be turned into auto tail lights;
carloads and carloads of pellets.  Another major product was the
lining material for cans of paint.  I had just assumed paint was
merely placed in a metal can, that there was no lining.  But there is,
and this company made it.

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

#160621

<hancock4@bbs.cpcn.com> wrote in message 
news:57684584-e9a6-43d6-b773-67e7caf0574c@googlegroups.com...
> On Sunday, March 6, 2016 at 11:28:18 AM UTC-5, Morten Reistad wrote:
>
>> I worked with PDP11s (/34's mostly) controlling welding and
>> steel stamping presses (bending 6mm steel like you fold up a
>> paper). They had extra filters installed in front of the intakes,
>> but otherwise lived in a VERY compromised environment.
>> They worked just fine.
>
> The IBM history talks about developing IBM's various process controllers,
> e.g. the 1710, 1800, and System/7.  Given their applications, very high
> reliability was a must.  However, given their applications, their work
> environment wasn't so great.  It was a challenge.  IIRC, the IBM S/7 was
> priced too expensive for its market and thus wasn't a big success.  I
> think the 1800 (based on the 1130) was more successful.
>
> bitsavers has a much of stuff on process control.  Admittedly, I don't
> understand a lot of it, but it makes for fascinating reading.  There
> is one magazine reprint of a process controller for ancillary processes
> of an oil refinery that's generally in layman's terms.  The setup,
> programming, and testing effort must have been enormous since any bug
> could ruin the output product or even be dangerous.  But I suspect
> that even developing and debugging a manually operated process was also
> quite a challenge.

Yeah, I was talking to one fella involved in doing that with a steel
rolling mill. Get it wrong and they had to get people in with oxy
equipment to cut up the abortion to get it out of the mill.

> A nearby chemical plant had an open house.  It was fascinating to see
> the control panels.  They seemed high tech, although they told us they
> were actually rather old.  Operators would control the feed,
> temperature, and other factors in the "kettles" to make product.
> (Too bad photography was strictly forbidden, lots of neat stuff).
>
> I was surprised to learn that this huge plant only made intermediate
> raw materials, not finished products.  For instance, they made red
> pellets which were later used to be turned into auto tail lights;
> carloads and carloads of pellets.  Another major product was the
> lining material for cans of paint.  I had just assumed paint was
> merely placed in a metal can, that there was no lining.  But there is,
> and this company made it.
> 

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

#160627

<hancock4@bbs.cpcn.com> wrote:
> On Sunday, March 6, 2016 at 11:28:18 AM UTC-5, Morten Reistad wrote:
> 
>> I worked with PDP11s (/34's mostly) controlling welding and
>> steel stamping presses (bending 6mm steel like you fold up a
>> paper). They had extra filters installed in front of the intakes, 
>> but otherwise lived in a VERY compromised environment.
>> They worked just fine.
> 
> The IBM history talks about developing IBM's various process controllers,
> e.g. the 1710, 1800, and System/7.  Given their applications, very high
> reliability was a must.  However, given their applications, their work
> environment wasn't so great.  It was a challenge.  IIRC, the IBM S/7 was
> priced too expensive for its market and thus wasn't a big success.  I
> think the 1800 (based on the 1130) was more successful.
> 
> bitsavers has a much of stuff on process control.  Admittedly, I don't 
> understand a lot of it, but it makes for fascinating reading.  There
> is one magazine reprint of a process controller for ancillary processes
> of an oil refinery that's generally in layman's terms.  The setup,
> programming, and testing effort must have been enormous since any bug
> could ruin the output product or even be dangerous.  But I suspect
> that even developing and debugging a manually operated process was also
> quite a challenge.
> 
> A nearby chemical plant had an open house.  It was fascinating to see 
> the control panels.  They seemed high tech, although they told us they
> were actually rather old.  Operators would control the feed, 
> temperature, and other factors in the "kettles" to make product.
> (Too bad photography was strictly forbidden, lots of neat stuff).
> 
> I was surprised to learn that this huge plant only made intermediate
> raw materials, not finished products.  For instance, they made red
> pellets which were later used to be turned into auto tail lights;
> carloads and carloads of pellets.  Another major product was the
> lining material for cans of paint.  I had just assumed paint was
> merely placed in a metal can, that there was no lining.  But there is,
> and this company made it.
> 
> 

Like the Koch  ads: "we don't make the foo, we make the stuff that makes
the foo". ( or something similar)

-- 
Pete

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

#160590

In article <PM00052D4D9E68D518@aca446c9.ipt.aol.com>,
jmfbahciv  <See.above@aol.com> wrote:
>Morten Reistad wrote:
>> In article <PM00052D38F4E28E9A@aca41c7c.ipt.aol.com>,
>> jmfbahciv  <See.above@aol.com> wrote:

>>><grin>  Yesterday, I recalled the time a pail of water crashed
>>>through the ceiling behind KL1026.  Apparently, that was
>>>maintenance's "fix" for a leak.  Our operations supervisor
>>>was 2 feet away when it fell.
>>
>> I have told the story of the RP07 going terrorist?
>>
>> The RP07 had the heads enter the platters in a different direction
>> from most other drives. Mostly, head crashes just drag the heads along
>> the oxide. The RP07 had a failure mode where the heads buried
>> instantly deep into the platter when they crashed. This made
>> significant havoc to the surroundings when the momentum of the
>> rotating platters were more or less instantly transferred to the
>> cabinet.
>>
>> This happened one day at my old college. The cabinet was part of
>> a DEC2065 and was right next to one of the 6 strong steel supports
>> that held up the 9-story building. It was at the 2nd floor.
>>
>> This day emacs froze and around 1 second later there was a *really*
>> loud bang in the building. Instant bomb alarm and full evacuation.
>> We all thought someone had bombed the computer facility, right below
>> the deans office.
>>
>> But it was just an RP07 that had had this type of head crash and
>> hit the steel support on it's way around the computer room.
>>
>> It was found above the CPU cabinet; entangled in the cabling that
>> still mostly held. The CPU was still operating, but was not too happy
>> about a bit of swap space that was missing. The CPU cabinet had
>> a visible dent; but nothing except the cable attachments inside
>> was damaged.
>
>I don't remember that story.  I'm glad I never heard of it when
>I was working.  I didn't like RP07s; if I had heard this story,
>I would also be afraid of them.
>
>Was the whole RP07 really above the CPU?  How in the world
>did FS clean that out?

It wound itself up along the cabling (it rotated quite fast
and furiously) tearing up floor tiles as needed, but was forced
up by the RP06'es and comms rack that was between it and the
KL10 CPU. It came to rest on top of one of the CPU cabinets.

It made a huge mess of everything; but the other hardware
got some bulks and bumps, and some cabling was torn up; but generally
FS managed to square things up pretty well. There was a need for
new floor tiles in a significant area, and lots of cabling
needed to be changed. But the other hardware just had to go
through a normal service and worked just fine.

>DEC's CPUs were hardy beasts.  One survived getting shot
>when a frurstrated developer had a bad stand alone time.

They had one big, weak spot though. The backplane. Whenever
there was a bad contact there they started misbehaving badly
until someone that could operate the comb came along.

-- mrr

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

#160616

On Saturday, March 5, 2016 at 8:58:29 AM UTC-5, jmfbahciv wrote:

> DEC's CPUs were hardy beasts.  One survived getting shot
> when a frurstrated developer had a bad stand alone time.

The Bell System loved them.

IIRC, Bell used an IBM System/7 for toll call recording, replacing an
electro-mechanical paper tape process.  But then they replaced that 
with a DEC.

AT&T was kind of slow in converting to mag tape and electronic recording
of toll calls.  Their history says they wanted to be sure mag tape would
be reliable, since obviously they didn't want to lose toll charges.  It
was true that in the early 1950s mag tape had some limitations, and Bell's
position made sense.  But I think by 1960 mag tape was pretty reliable,
yet Bell stuck with paper tape.  I suspect Bell had a "not invented here"
attitude about some technology.

Indeed, Bell apparently didn't like whatever operating system was
supplied with DEC machines, since they developed their own.  Unix 
came out of that effort.

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

#160675

Morten Reistad wrote:


> 
> I have told the story of the RP07 going terrorist?
> 
> The RP07 had the heads enter the platters in a different direction
> from most other drives. Mostly, head crashes just drag the heads along
> the oxide. The RP07 had a failure mode where the heads buried
> instantly deep into the platter when they crashed. This made
> significant havoc to the surroundings when the momentum of the
> rotating platters were more or less instantly transferred to the
> cabinet.
> 
> This happened one day at my old college. The cabinet was part of
> a DEC2065 and was right next to one of the 6 strong steel supports
> that held up the 9-story building. It was at the 2nd floor.
> 
> This day emacs froze and around 1 second later there was a *really*
> loud bang in the building. Instant bomb alarm and full evacuation.
> We all thought someone had bombed the computer facility, right below
> the deans office.
> 
Is this the same drive as the RM07, made by Burroughs?  We had one on our 
VAX 11/780.  Glad we never had one of these super-catastrophic events with 
ours!  We did have a lot of trouble with ours, it must have been a very 
early unit.  One major mod required replacement of the HDA, and they put an 
absolute filter on the air coming OUT of the HDA, so that full stroke inward 
seeks could not draw dirty air in through the voice coil.  But, we still had 
firmware trouble with it.  They fixed some of it, but it would still 
occasionally mangle a track descriptor record.  The next time the drive 
needed to transfer a sector off that track, the drive would completely 
freeze.  The only way to clear it was to open the back of the drive and 
power it off by the circuit breaker.  Eventually, they came up with a fix 
that eliminated damaging the TDRs.  Then, the DEC CE came in and ran a 
program that would rewrite all the TDRs.  He promised that it would not 
affect user data at all.  He was MOSTLY correct, but it initialized the 
master file system header!  I spent a tense morning writing a program to 
find the spare header and copy it to the master header while converting the 
various pointers and checksums.  I tried it first on a floppy and then ran 
it on the RM07.  Great relief when it worked.

Jon

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

#160525

"jmfbahciv" <See.above@aol.com> wrote in message 
news:PM00052D2521DCF4E4@aca40c8f.ipt.aol.com...
> Rod Speed wrote:
>>
>>
>> "jmfbahciv" <See.above@aol.com> wrote in message
>> news:PM00052D115027C687@aca43c61.ipt.aol.com...
>>> Rod Speed wrote:
>>>>
>>>>
>>>> "jmfbahciv" <See.above@aol.com> wrote in message
>>>> news:PM00052C976DF0A4D2@aca2d6f2.ipt.aol.com...
>>>>> hgww wrote:
>>>>>>
>>>>>>
>>>>>> "jmfbahciv" <See.above@aol.com> wrote in message
>>>>>> news:PM00052C8429A98276@aca2d65f.ipt.aol.com...
>>>>>>> hgww wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> "jmfbahciv" <See.above@aol.com> wrote in message
>>>>>>>> news:PM00052C5C2FA4288E@aca40f57.ipt.aol.com...
>>>>>>>>> mentificium@gmail.com wrote:
>>>>>>>>>>
>>>>> <snip>
>>>>>
>>>>>>>>>> Btw (by the way) I hope to provide an orignal
>>>>>>>>>> "prior art" AI that leads to a kind of
>>>>>>>>>> "pre-Cambrian explosion" of AI life-forms.
>>>>>>>>>>
>>>>>>>>>> By calling the Perl AI "Ghost", I hint at
>>>>>>>>>> the idea of "The Ghost in the Machine" and
>>>>>>>>>> at "The Soul of a New Machine" by T. Kidder.
>>>>>>>>>
>>>>>>>>> I can tell you that the soul of a machine is a conglomerate
>>>>>>>>> of the developers and other workers who did the work
>>>>>>>>> to produce the hard/software.
>>>>>>>>
>>>>>>>> That's not really true of those who do the donkey
>>>>>>>> work like say wire wrapping the backplane with
>>>>>>>> stuff of your generation.
>>>>>>>
>>>>>>> It's especially true in this case.
>>>>>>
>>>>>> Bullshit. Those are no different to the machines that replaced them
>>>>>> later.
>>>>>>
>>>>> I don't think you would recognize a machine soul.
>>>>
>>>> There is no such animal and even if there was,
>>>> those human robots are no part of it anyway.
>>>
>>> Every machine had its own "personality".
>>
>> They still do. BUT that has nothing to do with
>> stuff like the machines used to make the machine.
>> And so when we had humans who were JUST doing
>> what machines did later, the wire wrapping, THOSE
>> people contributed nothing to the personality.
>
> Of course they did.  Every wire-wrapped machine had it
> quirks.  Fixing hardware bugs could cause more quirks.

That is a completely separate question to whether that
machine had any part in the personality of the machine
it was doing the wire wrapping of.

I can see where you have gone wrong now, you assumed
I was talking about the personality of the wire wrapping
machine. I wasn’t. I was making the point that the wire
wrapping machine does not contribute to the personality
of the machine it is making.

>>> I have never figured out how to describe this other
>>> than using human attributes.  Merging two machines
>>> together created a different personality.
>>
>> Using a machine to do part of the manufacture of
>> a machine like with wire wrapping does not create
>> a different machine and doing it with robot humans
>> doesn’t either.
>
> When I talked about merging two machines, I meant going
> from a single-CPU system to a dual-CPU or triple-CPU system.

That isnt merging two machines, that is changing the design
of one machine.

>>> When they were split into two systems,
>>> they reverted back to their old personality.
>>
>> Not when one of them is used for manufacture.
>>
>>> Each customer's machine was also different.
>>
>> That mangles the real story too, particularly
>> when the customer has lots of the one machine.

> Not really.

Yes, really.

> Each machine had its own user population.

No they do no, most obviously with server farms.

> Those users did different things at different times.

Utterly mangled all over again with server farms.

>>> Some of that had to do with the kind of
>>> care of the center and usage of the users.
>>
>>> When one was sent to work on site, one of the first
>>> things a person did was learn about that personality.
>>
>> BULLSHIT. In spades with modern smartphones.
>
> I'm NOT talking about todays machines.

You claim has to be valid for all machines.

> They have the personalities of a slug
> after it's been run over by a steam roller.

Even sillier than you usually manage with smartphones alone.

They do in fact have much more personality because
some of them are much more limited resource wise.

>> And that is all completely irrelevant to your original
>> silly claim that the machine used in the manufacture
>> of the machine is part of the personality of the
>> machine that it is used in the manufacture of.

> Boy, when you go off the deep end of misreading what I wrote,

You are the one that did that when you assumed I was talking
about the personality of the wire wrapping machine. I wasn’t.

> you create a Grand Canyon.

More of your wild exaggeration, even sillier than the
claim above about the personality of smartphones. 

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

#160536

"jmfbahciv" <See.above@aol.com> wrote in message 
news:PM00052D2521DCF4E4@aca40c8f.ipt.aol.com...
> Rod Speed wrote:
>>
>>    [snip...]              [snip...]                [snip...]
>>
>> And that is all completely irrelevant to your original
>> silly claim that the machine used in the manufacture
>> of the machine is part of the personality of the
>> machine that it is used in the manufacture of.
>>
> Boy, when you go off the deep end of misreading what I wrote,
> you create a Grand Canyon.
>

BAH, this is to be expected when you exchanges messages with Speedo!!! 
Speedo is a classic case for why the Kill File was invented.

-- 

numerist at aquaporin4 dot com

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web