Lights on Burroughs machines
Jeremy J. Epstein
"Burroughs B" on its banks of lights when it was in idle state.
I never saw it though...
--
Jeremy Epstein
TRW Systems Division
703-876-4202
j...@virtech.uu.net
John Stewart
>Rumor had it that the Burroughs B7700 would display the giant
>"Burroughs B" on its banks of lights when it was in idle state.
>I never saw it though...
The B5700's and 6700's that I programmed on at University had the front
pannel where the students could see it.
Yes, it would display a "B" when idle, but it would also display
DE
AD
if some part of the system was down!
Other burroughs trivia:
One old disk had a signal called "HFML", that showed a digital true when
the disk was spun up. HFML? Heads Flying Mighty Low, of course.
The operating system was written such that one needed a good
understanding of US history. For instance, the kill a process function
was called something like "lincoln". (Maybe someone can remember for
sure.)
Messages "Death in Family" and "Infanticide"happened occasionally,
and I know one first year student who got real upset one day...
It was a stack based machine, so thus did not have an assembler. It
executed what some people called P-code.
The interactive "shell" CANDE (Command and Edit) was very user friendly,
that had the concept of history, and kept track of what the latest "work
file" was. One needed to type "r" after editing your program to compile
and run it.
The operator consoles (SPO's) were writable by anyone. Yes, I almost
got kicked out by faking operator displays.
the vector processor allowed one to romp all over memory, should one
program in Fortran. Kind of fun, actually.
the Fortran compiler would optimize a program out of existence, given the
chance.
Burroughs had developed "virtual memory" many years before IBM invented
it.
Some of the displays we had used a digital display spiral to hold a
raster screenfull.
I miss the old Burroughs, it was certainly a let down to have to program
on PDP-11's when leaving University.
John Stewart.
Ken Yap
|chance.
Speaking of the Burroughs Fortran compiler, many years ago I happened
to glance at a Burroughs Tech Bulletin (or whatever) and there was a
bug warning stating (something like):
"If the 25th variable in the 25th common block is named ZZXYZ then the
compiler dies with a spurious error."
It still boggles my mind how anybody would ever stumble upon a bug like
that.
Paul Campbell
>The operating system was written such that one needed a good
>understanding of US history. For instance, the kill a process function
>was called something like "lincoln". (Maybe someone can remember for
>sure.)
That one I don't remember .... but system security was checked by the
routine JEDGARHOOVER
Paul
--
Paul Campbell UUCP: ..!mtxinu!taniwha!paul AppleLink: CAMPBELL.P
"Why is it that the US can invade Panama but not the Vatican Embassy?"
"1995 - The leader of the free-world? That would be Gorbachev ..."
Brian L. Stuart
>"Burroughs B" on its banks of lights when it was in idle state.
>I never saw it though...
Sure did. I had a chance to see it when I was goofing around on
one one evening. I was (now get this) doing some BASIC on punched
cards. It didn't spell out Burroughs; it just displayed a "B" and
not a perfect one at that. I suppose it wasn't completely idle
though.
Brian L. Stuart
Department of Computer Science
Purdue University
Henry Spencer
>>Rumor had it that the Burroughs B7700 would display the giant
>>"Burroughs B" on its banks of lights when it was in idle state.
>
>
> DE
> AD
>
>if some part of the system was down!
I have heard it said -- I've never seen it -- that the front-panel lights
on a B1700 displayed a smile when idle and a frown when crashed.
--
1972: Saturn V #15 flight-ready| Henry Spencer at U of Toronto Zoology
1990: birds nesting in engines | uunet!attcan!utzoo!henry he...@zoo.toronto.edu
Howard Chu
%|the Fortran compiler would optimize a program out of existence, given the
%|chance.
%
%Speaking of the Burroughs Fortran compiler, many years ago I happened
%to glance at a Burroughs Tech Bulletin (or whatever) and there was a
%bug warning stating (something like):
%
%"If the 25th variable in the 25th common block is named ZZXYZ then the
%compiler dies with a spurious error."
%
%It still boggles my mind how anybody would ever stumble upon a bug like
%that.
Better yet, think of the fun they must have had until they finally
decided it was repeatable/worth documenting!
--
-=- PrayerMail: Send 100Mbits to holy...@father.son[127.0.0.1]
and You Too can have a Personal Electronic Relationship with God!
The Polymath
}
} DE
} AD
}
}if some part of the system was down!
IBM 370's and their descendants do the same thing (though they display
DEAD).
--
The Polymath (aka: Jerry Hollombe, holl...@ttidca.tti.com) Illegitimis non
Citicorp(+)TTI Carborundum
3100 Ocean Park Blvd. (213) 450-9111, x2483
Santa Monica, CA 90405 {csun | philabs | psivax}!ttidca!hollombe
D.S. Cartwright
I and my friends have developed many mini-theories about these items:
1. The speed of any machine is inversely proportional to the number of
flashing lights.
2. The cost of any machine is proportional to the cube of the number of
flashing lights.
3. The first item to malfunction on any piece of machinery is the flashing
lights.
4. Any fault detection system which uses flashing lights is incapable of
detecting faults in the flashing lights.
5. Any flashing light which detects the presence of mains power will fail to
go off when the power is turned off.
6. Any light intended as any sort of 'Disk In Use' indicator will be rendered
unnecessary by the very loud grinding noise of the disk drive; people will
hear the drive being used and will never look at the flashing light.
7. Though machines are designed with the intention of avoiding redundancy in
all circumstances, this practice does not extend to redundancy of flashing
lights.
8. Problems will be encountered when trying to expand machines with extra disk
drives, etc, as the front panel is full of flashing lights.
9. The peripheral support industry of the 1990's will me in the maintenance of
flashing lights.
10. Flashing lights are a pain in the bum.
Dave C, UEA, Norwich, ENGLAND.
Brian Kantor
but the procedure that split off new tasks ("forks") was called
MOTHERFORKER until some administrative type happened to see a listing
and complained; it was rechristened ROSEACACIA as that was much
sweeter smelling.
BTW, we still have our 7800 in the next room, with a bunch of PDP-11/04s
and 11/23s as terminal multiplexers. None of them spell anything
interesting in the lights anymore. Perhaps they're just never idle.
- Brian
Pinhead@Spikes
~In article <7...@ncs.dnd.ca> jste...@ncs.dnd.ca (John Stewart) writes:
~}... it would also display
~} DE
~} AD
~}if some part of the system was down!
Add then holl...@ttidcb.tti.com (The Polymath) babbles...
~IBM 370's and their descendants do the same thing (though they display
~DEAD).
Can't remember what machine it was, but if it crashed...
the console would print:
P
L
O
P.......
And then give the kernal debug prompt.
aBp.
--
Andy Pippin -*- api...@polyslo.CalPoly.EDU -*- Conserve water, drink beir.
"Write Only?!? Must be talking about FORTH. Nobody can read that."-samlb
Ken Yap
|~DEAD).
|
| Can't remember what machine it was, but if it crashed...
| the console would print:
|
| P
| L
| O
| P.......
|
| And then give the kernal debug prompt.
I had fun with this program when I was learning about signals and in
particular signal 15 a.k.a. SIGTERM.
catch()
{
int fd;
fd = open("/dev/tty8", 2);
write(fd, "Arrggh, you dirty rat!\n\n\n\n", 26);
}
main()
{
signal(15, catch);
sleep(100000);
}
(Please, no nitpicks about small errors and bad style, I'm just trying
to give the idea. Besides, I was a bad programmer then. :-))
The next time the system manager did a graceful shutdown of the 11/40,
it printed on the console
Arrggh, you dirty rat!
much to his chagrin.
PS: And yes, the console was /dev/tty8 in those days. Ask an old-timer.
The Grey Wolf
>g...@mentor.cc.purdue.edu (Brian L. Stuart) writes about flashing lights;
>
>I and my friends have developed many mini-theories about these items:
>
>1. The speed of any machine is inversely proportional to the number of
> flashing lights.
> .
> .
>
>10. Flashing lights are a pain in the bum.
>
> Dave C, UEA, Norwich, ENGLAND.
11. A malfunctioning item is a sure bet that there's a flashing light
somewhere.
--
"You guys are NUTS! En-Vee-Tee-Ess, NUTS!" -- History of the World, part I.
Scott Schwartz
> the console would print:
> P
> L
> O
> P.......
> And then give the kernal debug prompt.
Back in the old days, when psuvax1 really was a vax,
someone altered the kernel panic routine to print
"Take her down Scotty, she's sucking mud!"
on the console just before handling the crash.
Mike Morris
>>Rumor had it that the Burroughs B7700 would display the giant
>>"Burroughs B" on its banks of lights when it was in idle state.
>>I never saw it though...
>
>The B5700's and 6700's that I programmed on at University had the front
>pannel where the students could see it.
>
>Yes, it would display a "B" when idle, but it would also display
> DE
> AD
>if some part of the system was down!
>
>Other burroughs trivia:
>
>One old disk had a signal called "HFML", that showed a digital true when
>the disk was spun up. HFML? Heads Flying Mighty Low, of course.
If it was a "storage module" drive, it was also pretty BIG - the cabinet
was about 6' by 8' by 6', and had individual platter chambers that were
about 6' in diameter, mounted vertically. I saw one in the back room of
a electronic surplus place one time, and the main shaft was over 2" in
diameter. It took one _h#$%&ofa_ good twist to get it moving (inertia
is a bitch, no?), but once moving the fact it was still moving 20 _minutes_
later showed that the designers knew their bearings...
>The operator consoles (SPO's) were writable by anyone. Yes, I almost
>got kicked out by faking operator displays.
The B3500 that I programmed in Fortran 4, COBOL and COBOLL used a ASR-33
for an operator console. The console handler was swapped out most of the
time - there was a "INPUT" pushbutton on the front of the ASR that
interrupted the system, which loaded the handler, which then typed a prompt.
>the Fortran compiler would optimize a program out of existence, given the
>chance.
>
>Burroughs had developed "virtual memory" many years before IBM invented
>it.
MCP had a bug though - it didn't know how big the swap space on the disk
was. I once wrote a program in fortran that _relied_ on the virtual
memory (memory is fuzzy, but I think it was:
DIMENSION A(1000000,1000000,10)
A=0
The above two lines wiped the system disk.
The conversation with the Department Chairman went something like:
Him: "Mike, you wiped the system disk with 2 lines of fortran code.
The operators had to reload it from 20 boxes of cards. Then
they had to figure out what did it. Four system reloads later..."
Me: "What's a system disk?".
I was a 1st year programming student, what can I say...
A two-drive mag tape system was installed at the end of the semester.
Wonder why...
>I miss the old Burroughs, it was certainly a let down to have to program
>on PDP-11's when leaving University.
Yeah - only it was 360-30 assembler for me (still with an 029 for an
input device, however), then DG Nova 800s, 840s, and 1200s. Then
Nova 2s, 3s and 4s and various flavors of MVs...
I have yet to log on to a IBM mainframe for any other purpose than PROFS mail.
Oh well... maybe I haven't missed much.
But DG sure had a versatile assembler on RDOS. Even did a Z80 CP/M BIOS
with it... How many assemblers have a pseudo-op that erases all the
instruction definitions (".XPNG"), and others that define new ones (".DEFN")?
Now if the Nova 4 in the garage just had a comm chassis, a tape drive,
and more that 12.5mb of disk in it, and didn't cost so much on the
electric bill to run, maybe I could run a multi-line news feed...
Shouldn't be to hard to port uucp/m to RDOS...
Mike Morris Internet: Mor...@Jade.JPL.NASA.gov
Misslenet: 34.12 N, 118.02 W
#Include quote.cute.standard Bellnet: 818-447-7052
#Include disclaimer.standard Radionet: WA6ILQ
Mark Brown
>
>Back in the old days, when psuvax1 really was a vax,
>someone altered the kernel panic routine to print
> "Take her down Scotty, she's sucking mud!"
>on the console just before handling the crash.
Actually, this came from an old TI 990 'if all else fails' error message,
(straight from the Oilfield -- 990 were used by geologists):
"Shut'er down Clancy,
She's a-pumpin' mud!"
ERROR
One was never, NEVER supposed to see this message, but of course, someone did
and sent it in to Field Support....
Mark Brown IBM AWD / OSF | If a train station is where
The Good mbr...@osf.org | a train stops,
The Bad uunet!osf!mbrown| What happens at
The Ugly (617) 621-8981 | a work station?
Peter da Silva
> detecting faults in the flashing lights.
Ever hear of "Lamp Test"? *You're* the fault detection system for the flashing
lights.
--
Peter "Have you hugged your wolf today" da Silva <pe...@sugar.hackercorp.com>
`-_-'
'U` "I haven't lost my mind, it's backed up on tape somewhere"
Brian L. Stuart
for me) light story.
Back when I was an undergrad at Rose-Hulman, I had an interest in analog
computing. Well TI unloaded an EAI 690 at us. (I may have the numbers
wrong.) This was a hybrid machine with a 680 analog computer and a
small 16-bit machine labled the 640. Well since nobody else had any
desire to touch the thing, it became my toy, and its lab my lab/office.
(One of the professors even asked me if he could use the lab for another
student once.) But I digress. While trying to get the 680 up and running
I had noticed that some of the lights on the control panel were burned
out, but those could wait until it was running (or so I thought). I had
gotten it to the point that it would work except for switching from initialize
mode to operate mode. Studying the engineering drawings led me to the
following sort of a reaction:
Oh NO!
They couldn't have...
The DID!!!
No wonder it doesn't work.
It seems that they had used the voltage drop across the mode indicator
light bulb to pull an idle line down. With the bulb burned out, and no
signal driving the line, (open collector or some such, as I remember)
the receiving gate saw the line as high, and this active signal overrode
the signal to switch into operate mode. I replace the light bulb and
the machine worked.
No kidding; this was literally a case of the computer not working because
a light bulb was burned out.
Brian L. Stuart
Department of Computer Sience
Purdue University
Pete Soper
> "Take her down Scotty, she's sucking mud!"
> on the console just before handling the crash.
About 10 years ago Texas Instruments DX10 OS had a similar
panic message: "Shut her down, Clancy, she's pumping mud". I always
figured this was because DX10 was developed in oil country :-)
----------------------------------------------------------------------
Pete Soper +1 919 481 3730
internet: so...@encore.com uucp: {bu-cs,decvax,gould}!encore!soper
Encore Computer Corp, 901 Kildaire Farm Rd, bldg D, Cary, NC 27511 USA
Bob Bickford
> (various discussions about the Burroughs FORTRAN compiler)
Since I'd learned FORTRAN in high school, when I got to college (UOP)
and was introduced to their B6700, the first thing I did was to try
out my high-school FORTRAN programs. The TAs in the computer center
were no help; they all looked down their noses at anything that wasn't
written in ALGOL (which I eventually learned in self-defense).
They (the TAs) had a game among themselves in which they would try
to devise ways of preventing each other from getting any work done,
almost always by totally tying up the victim's terminal. All of their
efforts were written in ALGOL, of course.
Under CANDE (Command-And-Edit, the Burroughs "user interface"), any
command prefaced with a '?' was intercepted by the CANDE program
itself and effectively invisible to a program. A little perusal of
the system documentation, plus the appropriate experimentation,
revealed that the command ?DENY would kill the TA's "bomber"
programs (curiously, they were mystified as to why I was never
disturbed by their efforts after that).
Since I didn't know ALGOL at the time (and was suspicious of this
strange-looking BASIC thing -- too similar to FORTRAN), but did know
FORTRAN, I decided to try writing a "bomber" program of my own.
Opening the victim's terminal was easy. Spewing output to it, and
gobbling the input, was also easy. But what could I do about "?DENY" ?
Well, after a *lot* of experimentation, I discovered two things: I
could detect the error condition if I used a really bizarre (to me)
version of the WRITE statement; and the condition was the same as that
for "end-of-file". At that point I had an "Aha!" insight, and looked
in the section of the manual about tape commands: sure enough, there
was a REWIND function which said it would "clear end-of-file".
To my everlasting surprise, it worked: typing ?DENY to my program
would cause it to branch to the error-handler I'd written, which
did a "REWIND" on the ___terminal___ (!), and print out a message
that said "Hey! -- Don't do that!", and return to the main code.
(I later heard that somebody working for Burroughs on their FORTRAN
compiler for the B6700 didn't know what to do with the REWIND function
in the case of a terminal, and so just connected it to the code that
reset all error conditions --- including the end-of-file condition
set by ?DENY)
After compiling my program one final time, I deleted the source and
discreetly waited a week before using it on anybody. The TAs simply
could not figure out what I'd done; but after that I got a lot more
respect. They even let me hack on our copy of ADVENTURE when we
finally got it (this was 1976-77).
(This was all freshman year at college, which is so long ago that I
may have garbled some of the details......)
--
Robert Bickford {apple,pacbell,hplabs,ucbvax}!well!rab
r...@well.sf.ca.us /-------------------------------------\
| Don't Blame Me: I Voted Libertarian |
\-------------------------------------/
Paul Sutcliffe Jr.
Soper) writes:
+---------
| From article <C5n!6...@cs.psu.edu>, by schw...@cs.psu.edu (Scott Schwartz):
| > "Take her down Scotty, she's sucking mud!"
| > on the console just before handling the crash.
|
| About 10 years ago Texas Instruments DX10 OS had a similar
| panic message: "Shut her down, Clancy, she's pumping mud".
The Tandy 6000 is a dual-processor (68000/Z80) system running Xenix.
The Z80 does all I/O work for the 68K. It (the Z80) runs a loop
something like this:
start: save the Stack Pointer
do this
do that
do something
do something else
[...]
compare current SP to saved value
if okay, go to start
If the compare fails, it is assumed that something went wrong and
the console gets the message:
Bughlt: SckMud
and the system is promptly halted. An older version of the Z80 code
is said (I never saw it) to have also displayed the message "Shut 'er
down Scotty..."
- paul
INTERNET: pa...@devon.lns.pa.us | If life's a bitch, then
UUCP: ...!rutgers!devon!paul | we must be her puppies.
Robin Fairbairns
In article <7...@ncs.dnd.ca>, jste...@ncs.dnd.ca (John Stewart) writes:
>Other burroughs trivia:
>
>One old disk had a signal called "HFML", that showed a digital true when
>the disk was spun up. HFML? Heads Flying Mighty Low, of course.
I worked, as an undergraduate on long (summer) vacation, in the local
telephone exchange (read: central office). In those days, even the trunk
(read: long-distance) calls were switched by massive banks of relays
and uniselectors. (And no, I'm not that old: this is the UK, and it was the
60s.)
Anyway, coinboxes (public telephones) were controlled by a massive thing
called the CFC (Coin and Fee Check) relay set. These things counted the
charge pulses coming from the switching centre, and debited them against
the 3d, 6d and 1s coins the customer had fed in (1s=12d=(approx) 3c US
today).
To the point of the story: there was a relay TBF (Too Bloody Fast) that
triggered if a charge pulse came in less than 2 secs after the previous most
recent one. Fine: the longest-distance call charged about once every 10 secs
then.
But then they introduced International Dialling (sadly not where I was,
in Bristol) and you could dial the States. And the admin failed to notice
that the charge rate implied one pulse every 1.2secs.
So for a while, you could make unlimited duration calls to the USA from (e.g.)
a London call box for the 3d that would be consumed by the first charge
pulse, as the thing locked up after the second one.
This went on long enough that the National press got hold of it. The Post
Office (it was the days before a separate telecom authority) must have lost
masses before they sorted out barring international service to coin boxes.
Robin Fairbairns
Laser-Scan Ltd, but a guest of the site mentioned above.
Roger Ivie
> From article <C5n!6...@cs.psu.edu>, by schw...@cs.psu.edu (Scott Schwartz):
>> "Take her down Scotty, she's sucking mud!"
>> on the console just before handling the crash.
>
> About 10 years ago Texas Instruments DX10 OS had a similar
> panic message: "Shut her down, Clancy, she's pumping mud". I always
> figured this was because DX10 was developed in oil country :-)
My favorite error messages were on the TRS-80 Model I using Level I BASIC.
That version of BASIC had only three error messages: "What?", "How?",
and "Sorry."
===============================================================================
Roger Ivie
35 S 300 W
Logan, Ut. 84321
(801) 752-8633
===============================================================================
leftandrigh...@gmail.com
(FYI, I heard this term in undergrad when I lived w/ a computer science guy. Yours is the only post I found on googles that mentioned it)
Quadibloc
> Speaking of the Burroughs Fortran compiler, many years ago I happened
> to glance at a Burroughs Tech Bulletin (or whatever) and there was a
> bug warning stating (something like):
>
> "If the 25th variable in the 25th common block is named ZZXYZ then the
> compiler dies with a spurious error."
>
> It still boggles my mind how anybody would ever stumble upon a bug like
> that.
John Savard
Quadibloc
> that.
the code, without actually experiencing the bug?
John Savard
Charlie Gibbs
> On Monday, January 15, 1990 at 2:14:17 PM UTC-7, Ken Yap wrote:
>
>> Speaking of the Burroughs Fortran compiler, many years ago I happened
>> to glance at a Burroughs Tech Bulletin (or whatever) and there was a
>> bug warning stating (something like):
>>
>> "If the 25th variable in the 25th common block is named ZZXYZ then the
>> compiler dies with a spurious error."
>>
>> It still boggles my mind how anybody would ever stumble upon a bug like
>> that.
I learned two things early in my career:
1. Magic cookies are Evil.
2. "Never" (as in "Oh, that'll never happen") is usually about 6 months.
> And presumably that is the origin of XYZZY in Colossal Cave Adventure!
Whenever you ran it, it said, "Nothing happens."
--
/~\ cgi...@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!
Scott Lurndal
https://en.wikipedia.org/wiki/Zzyzx,_California
Which I suspect was the origin of the name in the Fortran compiler.
Everyone driving to vegas from la sees the zzyzx rd sign.
Charles Richmond
news:0056fdea-825e-47cc...@googlegroups.com...
http://rickadams.org/adventure/c_xyzzy.html
--
numerist at aquaporin4 dot com
Charles Richmond
news:nbth2...@news4.newsguy.com...
>
> [snip...] [snip...]
> [snip...]
>> And presumably that is the origin of XYZZY in Colossal Cave Adventure!
>
> I once came across a little executable called XYZZY.
> Whenever you ran it, it said, "Nothing happens."
>
"Hello-Sailor" says???
Nigel Williams
> Rumor had it that the Burroughs B7700 would display the giant
> "Burroughs B" on its banks of lights when it was in idle state.
> I never saw it though...
https://www.youtube.com/watch?v=lpv6pXlwEjY
This is the B6700 MDL (Maintenance Diagnostics Logic) display. On the left-side is a direct view of the A/B and X/Y registers where the bit-pattern was placed to display the idle-loop "B". There is more detail on my web-page here (although that page has not been updated in a long while; I have considerably more detail I will add to those pages at some stage):
http://www.retrocomputingtasmania.com/home/projects/burroughs-b6700-mainframe
If anyone is interested I can post Paul Kimpel's detailed explanation of how the idle bit pattern display is done and the variants that were done at the time (like the time-of-day clock display - world's most expensive digital clock).
On a related matter, I would very much like to find more pictures or even better video footage of the equivalent display for the Burroughs B5500(B5700), you can see what it looks like here (scroll down halfway):
http://www.retrocomputingtasmania.com/home/projects/burroughs-b5500/b5000_b5500_gallery
For reasons unknown it is the most under-photographed part of the B5500; after years of looking we have found only the two pictures (one oblique angle marketing picture, and the cropped picture) shown on this page.
Scott Lurndal
>On Tuesday, January 16, 1990 at 4:34:34 AM UTC+11, Jeremy J. Epstein wrote:
>etter video footage of the equivalent display for the Burroughs B5500(B5700=
>
>5500_gallery
Interesting picture of the fishbowl. It wasn't, however, "glass lined", but
rather one wall (the wall facing the lobby on Sierra Madre Villa) was glass
(with drapes that could be pulled). Cronkite did one of the elections from
that room (and the gas station in the movie 'The Jerk' was right across the
street from the plant).
It was fun to watch the B4800 boot with the lights out in that room - the
regular skins had been replaced with smoked acrylic panels and each of
the boards had a series of LED's on the end (and there were hundreds of those
boards).
G.
<n...@retrocomputingtasmania.com> wrote:
> If anyone is interested I can post Paul Kimpel's detailed explanation of
> how the idle bit pattern display is done and the variants that were done
> at the time (like the time-of-day clock display - world's most expensive
> digital clock).
Thanks,
G.
tracym...@gmail.com
>
> I once came across a little executable called XYZZY.
> Whenever you ran it, it said, "Nothing happens."
alias xyzzy="echo Nothing happens."
alias plugh="echo You'''re at end of road again."
Charles Richmond
news:4611e712-c4d2-46ab...@googlegroups.com...
of the road. "Plugh" moves you between the well house and Y2.