I used to work for a computer company, and one of our customers in Jacksonville called to say our computer couldn't communicate with any of the other computers on base. The company dutifully flew me down there to troubleshoot in person. I did some tests on our computer, and everything checked out, but sure enough, it couldn't talk to any of the other computers. I asked the folks there if the other computers could talk to each other. Nope, nobody was talking to anybody. Was it possible the other computers were all broken? I asked if I could get access to the other computers. They said it was okay, and I logged in to one of them to investigate. It was misconfigured, so I reconfigured it. Sure enough, it could then talk to our computer.

I proceeded to go through the rest of the other vendors' computers, fixing them one at a time. When I was done, all of the computers could talk to all of the other computers, which caused the customer to believe that I had been right all along and the other computers had indeed been the broken ones - the ones whose own vendors had been unable to fix. Our company came off looking really good, fixing all the other vendors' computers after the other vendors had been there and simply blamed everybody else (as I too had, originally - but I had been right!).

The customer said to let them know any time I felt like a trip to Jacksonville, they'd be glad to invent a problem and request to have me come down to "fix" it.

At one point, I had set up a web server on my home machine in order to test something out. I had the internet link up, and was chatting with folks on IRC, when a friend of mine asked "who is cat9?" I didn't understand the question, and he explained that he had seen my server up, and had been browsing, and wondered who the girl in cat9.jpg was. I eventually figured out he had connected to my home machine instead of my public web server, and had found this image on it. So I explained that it was Christina Ricci, in a publicity still from the remake of That Darn Cat. Then he asked "do you know her?" No, I don't know her, I'm just a fan.

After that, I put it out of my mind and did other stuff. But then he came back. "You're sooooo busted! I found this picture of you and Erin Murphy! You're hugging, you obviously know her!"

He had convinced himself, from one pic I had from a meet-and-greet, that I was close personal friends with all sorts of stars. Yeah, right. I should have shut down the web server when I realized it was externally accessible. But there's nothing I can do about peoples' wild flights of fancy.

I was working on a contract where we were going to sell SCSI connected floppy disk drives. We got a drive in, but it didn't work, so they assigned it to me. I added in some debugging code, and it looked like the drive was wonky. The computer would send a "read" command, and the device would respond "OK". This confused the computer deeply, as it expected the drive to either return a block of data and "OK", or an error. Just responding "OK" didn't make sense. All the other devices on the bus worked just fine.

The hardware engineer on the project rented a SCSI analyzer, which also insisted the drive was misbehaving. It clearly showed the read command going out, and the "OK" status coming back. So we ordered another drive, and when it arrived, it did exactly the same thing. Monitoring other devices showed the expected behaviour: send a read command, get data, then get the OK status.

I, however, did not trust the SCSI analyzer. It operated on the assumption that everything was operating according to specifications, and was designed to show what data was going back and forth, not investigate weird protocol violations.

Accordingly, I went and rounded up a logic analyzer, which just shows the raw signals, and does not interpret them at all. It is more effort to figure out what's going on from the raw logic levels, but the logic analyzer doesn't hide anything either. And sure enough, when I puzzled out what the logic analyzer was telling me, it became clear what was happening. The computer would put the read command on the bus, one byte at a time, assert the strobe signal to indicate that the command byte was ready to read, take away the byte, and wait for the "ack" (acknowledge) signal back from the target device. And this is wrong. What it should do is leave the byte on the bus until it gets the ack back. The SCSI control chip in the computer was very simple, and did not do the signal sequencing itself, depending on its device driver to do so. And, looking at the device driver source code (fortunately, we had access to it), it showed the same sequence of events: put data on bus, assert strobe, take data away, wait for ack. So I swapped two lines in the driver, so it would put the data on the bus, assert strobe, wait for ack, and then take the data away.

And lo, the SCSI floppy disk drive started to work perfectly! The remaining question was, why did the other devices work? My theory is that the other, fancier, devices had hardware SCSI interfaces that latched the incoming command bytes immediately upon strobe, so they didn't care that the data went away immediately afterward. Whereas the floppy drive implemented its SCSI interface with a microcontroller. The strobe signal would send an interrupt to the microcontroller, which would then go read the data byte off the SCSI bus. Unfortunately, by the time it got around to it, the data was gone, and the bus terminators had pulled the data lines back to their idle state of zero. And, sure enough, a SCSI command block of all zeroes is a valid command: "test unit ready", for which the correct response is simply "OK".

When I was in high school, I'd write silly programs that would attempt to do crude animations by playing with the text characters on the screens. There was one that drew a "diving board" made of underscores, and the cursor would bounce up and down on it, and then fall through. Another made a boxy plane, labeled "747", shudder across the screen. All of these were available to the other students using the county's computer system. And all of them would proudly proclaim that they had been written by me.

A few years later, I was signing up for classes, and the woman at the registration desk paused in her task of busily keying in my information. She looked up at me, and asked "Are you THE John Rehwinkel?" This caught me off guard, as I was unaware of being famous at all, or anyone else with my name for that matter. So I asked her what she meant, and she explained that she remembered the name from the silly animations she'd seen on the computer at high school. It was a good feeling.

When I had my first computer capable of video games, an Atari 800, I wrote a very simple game, which I dubbed "Kill the Cities". It laid out a three by three arrangement of red and green rectangles, which were the cities. To destroy a city, you had to shoot it. The cities were in plain view, did not move, did not have shields, and did not shoot back. You had unlimited shots. The only tricky part was the aiming cursor code was rudimentary, and erased anything under it. So if you took your time and scrubbed over a city, you could eventually render it invisible. Given this immense degree of difficulty, if you somehow managed to destroy all nine cities, the game would produce a hissing sound, and the text:

You win! You hear that? They're cheering for you!

This was actually one of my more popular games.

A while back, my company was subcontracting to another company on a government contract. One day they called in a panic, saying the system wasn't working and I had to drop everything and get out there NOW. It was a couple of hours through DC Beltway traffic to get there, so I wasn't enthusiastic, but I didn't really have a choice.

So I showed up, found the guys with the problem, and they sat me down at a computer. This was running their test version of the system without our debug passwords installed. So I asked for the system password, only to be told it would take a couple of hours to find out whether I was even allowed to have it. "Ah, got it!", I crowed, hammering the keyboard like a maniac. "What's the database password?" Again, they said it would be a while before I could get that. A few seconds later, I chirped "Ah, I figured it out" and kept going. "What's your encryption key?" And so forth.

It turned out the problem was that the software, just sitting there doing nothing, would absorb 72 database connections, and each user session took six more. It didn't take many users before they'd hit the limit of 100 simultaneous connections. They asked me how to fix it, and I explained that they had two choices - rewrite the software to not be so profligate with database connections, or increase the number of allowed simultaneous connections. "How do we do that?", they bleated. I explained that the proper way to increase the number of database connections was to write a large check to the database vendor. They didn't like either answer.

I later heard that their security manager had been aghast at my "hacking" their system to obtain the passwords needed to do the job they insisted I come do instantly, and I was no longer allowed in their data center. Which was fine with me.

When I was studying computers in school, the early courses were packed, and used as weed-out courses to reduce the student load in the higher courses to a smaller set of theoretically more appropriate students. However, I took issue with the courses that weeded people out by being taught poorly. Since there was no mechanism to test out of these, I had to go and take them too, even though I pretty much knew all the material.

I noticed that the lecture hall for my ForTran class was vacant after the class ended, so I'd stick around, and re-teach each day's lesson in my style to whoever felt like hanging around. I got a huge benefit from this, as teaching something is a great way to find out what I really understood and where I was on thin ice. The stuff I realized I didn't quite get either, we'd work through together. A win all around.

When I attended the University of Maryland, our computer science courses were taught using a Univac 1104, fed batch-mode by punch cards. There was a room available with IBM Model 29 keypunches modified to produce the Fieldata format used by the Univac, but there weren't enough of them, so there was always a wait to use a keypunch machine. However, for last-minute quick fixes, there was one "express" machine, for five cards or less. There was always a line for it too, which moved slowly as people would hunt and peck in slow motion, then reject the card and start over. People would take ten minutes to punch a few cards!

So I acquired the habit of just going to the front of the line, and keying peoples' cards for them. I could blast through the entire line in a few minutes. As I was doing so, I'd point out errors for people, to save them the time of waiting in line again, or worse yet, submitting their botched job and waiting a couple of hours for it to fun.

Happily, people rapidly got used to my habit, and realized I really wasn't going to try to steal their homework.

Like many programmers, when I'm developing code, I'll put in amusing error messages for when the code does something I don't expect. However, sometimes this code will get shipped before it's ready. Which leads to querulous calls from the customers. We've had the United States Navy ask us about some of these, which must have caused some consternation out at sea when they popped up. Seriously, folks, ASK me before you ship my software!

One time, I was writing a driver while the hardware engineer (his nickname was "Hoppy") was simultaneously debugging the hardware. I kept getting a particular error condition, only to find out it was because Hoppy had been screwing with something. After a few iterations of this, I simply put a printout at that point in the code that said "Hoppy's playing with the wires!" Sure enough, I forgot to remove it, and that message popped up in the field.

"Shut 'er down, Slim, she's sucking mud!" (a favourite of my friend, Ron Eirtle)

And my personal favourite: "I can't get a buffer to save my ass!"

I've long had a habit of naming computers I administrate after women I know. Once upon a time, the company I worked for decided to put us in our own division, "Telos Information Technologies". Yup, my servers were then named things like debbie.tit.telos.com, shelley.tit.telos.com, etc. That didn't last long.
We were getting ready for a fancy demo to a customer, including showing off our fancy new parallel data link. But, at the last minute, one of the wires came loose, so when we sent "Hello, world!" across it, it arrived at the other end as "Jello, world!"

Profile

mystories

November 2013

S M T W T F S
     12
3456789
10 111213141516
17181920212223
24252627282930

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Aug. 20th, 2017 09:06 pm
Powered by Dreamwidth Studios