Student Fails To Hack Into Computer, Sets It On Fire Instead

[gnoitall]

@LSLGuy

Back in Ye Olden Dayes I recall getting an n[sup]th[/sup]-generation photocopy of a joke quick-reference pocket card of System 370 opcodes including such winners as

“POD” -> Pound On Drum.
“CFBU” -> Catch Fire and Blow Up.

**Emphasis added.
**

This is one that wouldn’t make sense to anyone other than us Olden Dayes computer types.

Drum storage. Kinda like disk, in that it was rotating-surface magnetic storage. Unlike disk, in that you recorded and read from the outside surface of a drum, rather than the top and bottom surfaces of a disk. Faster, because you didn’t have to seek to a particular track to get the data you needed, and seek time was a huge part of data access latency. Low-density, because you were only using the outermost surface of a big ol’ cylinder, so all that internal volume was wasted.

/hijack

I always like the Unix standard error message for printer ports: “lp0 on fire”. Although I’ve never seen a printer actually catch fire, the error message was certainly enough to get the system operator up to check the thing with a quickness.

[Voyager]

@Senegoid

We felt sure that the machine could tell if the programmer was present, and was programmed to behave differently if so.

This could only happen by the use of the BPP op-code: Branch if Programmer Present.

I liked RPM - Read Programmer’s Mind. “But this is the way it was supposed to work!” Though around here people think I have access to a RUM instruction (Read User’s Mind) since they usually don’t bother saying what they really want.

Here is a list I just found. Not the one I remember which was long before microwaves, but a start.

ETA: A more complete list.

[Rysto]

@Senegoid

We felt sure that the machine could tell if the programmer was present, and was programmed to behave differently if so.

This could only happen by the use of the BPP op-code: Branch if Programmer Present.

There’s a related “Branch if Manager Present” opcode that causes bugs to appear only when demoing the software to management.

[Tim_T-Bonham.net]

@Voyager

The HCF command on old Motorola processors put the CPU in a loop where it incremented the program counter. It didn’t actually make the CPU catch fire, and had nothing to do with the things mentioned in the article.

I know of a case where the cpu actually did catch fire, or more accurately, melted down. The old version of a certain test tool would shift date through just about every flip-flop on the design at full speed. The cooling system was not designed for this really worst case. The first time they tried it, the cpu melted right through the very expensive prototype board. I know both the test person and the tool vendor, and they were still pissed about this situation (and blamed the other) years later.

The opposite happened one time. The early Cray supercomputers required massive electrical power, both for the machine and more for the associated cooling system, Ofthen 2 separate power feeds were required for this. But designer Seymore Cray had designed in an interlock, so that the computer shut down rather than burning up if power to the cooling system failed.

But at one customer site, the power went out one night to the computer, but power came back on for the cooling system. So when the staff arrived the next morning, they found their multi-million dollar supercomputer encased in a multi-ton block of ice! (But once they melted the ice and dried off the computer, it continued to work fine for several years.)