paul@taniwha.UUCP (Paul Campbell) (01/17/90)
In article <729@ncs.dnd.ca> jstewart@ncs.dnd.ca (John Stewart) writes: >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 ..."
gis@mentor.cc.purdue.edu (Brian L. Stuart) (01/17/90)
In article <1990Jan15.173434.5792@virtech.uucp> jje@virtech.uucp (Jeremy J. Epstein) writes: >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... 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
hyc@math.lsa.umich.edu (Howard Chu) (01/17/90)
In article <1990Jan15.211417.17833@cs.rochester.edu> ken@cs.rochester.edu writes:
%|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 holyghost@father.son[127.0.0.1]
and You Too can have a Personal Electronic Relationship with God!hollombe@ttidca.TTI.COM (The Polymath) (01/17/90)
In article <729@ncs.dnd.ca> jstewart@ncs.dnd.ca (John Stewart) writes: }... it would also display } } 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, hollombe@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
cmp8118@sys.uea.ac.uk (D.S. Cartwright) (01/17/90)
gis@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. 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@ucsd.Edu (Brian Kantor) (01/18/90)
Not only was system file security enforced by subroutine JEDGARHOOVER,
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.
- Brianapippin@polyslo.CalPoly.EDU (Pinhead@Spikes) (01/20/90)
~In article <729@ncs.dnd.ca> jstewart@ncs.dnd.ca (John Stewart) writes:
~}... it would also display
~} DE
~} AD
~}if some part of the system was down!
Add then hollombe@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 -*- apippin@polyslo.CalPoly.EDU -*- Conserve water, drink beir.
"Write Only?!? Must be talking about FORTH. Nobody can read that."-samlbken@cs.rochester.edu (Ken Yap) (01/20/90)
|~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. 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.
greywolf@unisoft.UUCP (The Grey Wolf) (01/20/90)
In article <1065@sys.uea.ac.uk> cmp8118@sys.uea.ac.uk (D.S. Cartwright) writes: >gis@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.
schwartz@cs.psu.edu (Scott Schwartz) (01/20/90)
> 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. 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.