16 February 2001
Last year: The next thing I knew, Matt was turning on the light, waking me up.
I am happy and content in my well-paying job. I am happy and content in my well-paying job. I am happy and content in my well-paying job. I am...
Oh, who am I kidding?
So yesterday, the job of the day was to get the issuing station up and mostly running. We're having some trouble with the section of code that creates the data we put on the smartcard. It's not an issue with my software, and my manager knows it. But his manager is going to be in the office today, and they want to show him something - if only it's the card being printed with the name and ID from the database.
So. The workstation was set up and connected to the LAN. I copy all the files to a transfer folder on the LAN, check with several people about their availability in case I need help, and collect a handful of CDs with drivers for various pieces of hardware, then head over to the issuing station.
Understand, my office is spread out over several suites. The general shape of my suite is a ring, with offices on both the inside and outside. My office is just about the furthest away from the front door that you can get. The issuing station is in a different suite. It's not the furthest from the door, but it's not the closest to it, either.
I arrive at the issuing station and prepare to log on, only to discover that neither the mouse nor the keyboard are working.
I wander around a bit, looking for the guy who was in charge of setting up the hardware. I don't find him, so I head back to my desk to write an e-mail and wait. Eventually, someone comes to report to me that a bad keyboard was replaced, and the station is now working. (Why a bad keyboard affected the mouse, I don't know, but I'm not terribly surprised, either.)
I head back over and log in. I install the drivers and status monitor for the extraordinarily expensive card printer. I power up the printer. It starts beeping at me, which means it isn't happy. I look it over, and realize the cover isn't closed. I close it and hit the printer's reset button. It cycles and beeps and cycles and then stops beeping, but now the status lights are orange. I reopen and reclose the cover. Same results. I try turning the printer off and then back on. Success! Two happy green lights.
I turn back to the computer monitor and the printer status monitor, which says: Printer not responding. What do you mean, not responding??? It's right there, isn't it? I suppose maybe the status monitor has been confused by my monkeying with the cover. I hit the button that reads, "Resume" and hope. It thinks about it, then tells me Printer not responding. I shut down the status monitor and restart it. No dice.
I decide to check the connection of the cables - they do sometimes come loose. I stand up and move around so I can see the back of the computer, mentally sorting the myriad cables. Monitor... power... keyboard... mouse... serial... Hey. Where's the printer cable?
Then it occurs to me that there's no reader attached to this computer - what's a serial cable doing here? An awful suspicion strikes, and I follow the serial cable back to the printer. Yep. I look for other cables coming out of the printer. Power cord... That's it.
Now, this printer actually does use a serial cable, because it's got a smart card reader/writer built in to it. Unfortunately, they forgot to give us the manual for that part of the printer, so we can't use it. So we haven't bothered with plugging in the serial cable. But the printer does also have a printer cable. It plugs into a standard printer port on the computer end, but has a special plug on the printer end, which means I can't just swipe any old printer cable. I've got to find the single, specific cable that came with the printer.
I find the guy who's in charge of setting up the machine and explain the problem. He admits he thought it was a little funny, having a serial printer, but he hadn't seen any other cables. Since the printer was just moved from my old office a week or so ago, and stuck in a random empty office for storage, I get a sinking feeling in my gut. That cable could be anywhere.
Eventually, we find it, where it had fallen behind another computer in the same storage room. Whew! I plug the cable into the printer and the computer, hit that "Reset" button on the status monitor, and sigh in relief as the printer comes online.
If you've been paying attention, you'll have noted that all this was just to get the printer up and running.
I went to the warehouse and requested a smart card reader. While I was waiting for that to arrive, I got Random (my office-mate who's in charge of the project's installation CD) to show me where he was keeping the installations for the drivers for the readers and cards. I took the reader and a test card over to the install station.
The installation for the card drivers is extremely confusing, especially since it contains drivers for some readers as well - but not the reader we're using. But eventually I get both sets of drivers installed, hook up the reader, and reboot. I flinchingly run the quick-test application. The light on the reader comes on. The card sends back a message. Hallelujah!
I run my test application. Missing DLL. Damn it.
I walk back to my desk, put the missing DLL on the LAN, walk all the way back to the issuing station, and run my test app. It works. Hallelujah!
Now, the hard part.
You think I'm kidding?
I have to set up an ODBC connection to the Oracle database the project uses. I know, those of you out there who know anything about computers are weeping for me already.
Ah, but I had planned ahead. I had secured a promise of help from the office's Oracle project manager, Heather. I go back to my office and call Heather to let her know I'm ready for her assistance. She collects a couple of CDs and comes with me over to the issuing station. It takes maybe half an hour just to install the Oracle client. She sets things up, and runs a test connection... No connection. She fiddles with a few things. No connection.
We try creating the ODBC connection anyway, and test it... No connection. We fiddle with a few more things. No connection.
Eventually, we go back to our offices, muttering imprecations against Oracle. Heather says she's going to try to create some accounts on the Oracle server.
A while later, she comes back with a new list of things to try, and we head back to the issuing station. She tries about three things at once. One of them works, though we're not entirely sure which one. We do some nervous testing to make sure the connection really is working. I thank her, and she leaves.
There's only one thing left to do: Run a preliminary test on my software. It's been working for months on my development computer, so I expect this to work.
I am an idiot.
Not only does it not work, it crashes my program. This is what we in the computer business call a "failure to fail gracefully." (Which is to say, it's actually OK if something doesn't work - but the program is expected to be nice about it. Give meaningful error messages, options to retry if possible... That kind of thing.)
Thinking perhaps it's a memory error (this is a Windows NT workstation, after all) I reboot and try again. Same crash.
Come to think of it, that crash looks a little familiar. It looks awfully similar to the crash I got when I was first developing the database portion of the project. I head back to my office to add some logging to my code.
Now, since everything works fine on my development machine, this is my process: I go to my office and make a few changes to the code. I rebuild the project, and put the new files up on the LAN. Then I walk back to the issuing station and copy the files back off the LAN. I run the program, which doesn't take long because it crashes almost the instant after I hit the "Go" button. Then I look at the logfiles, which tell me how far things actually got before they crashed. Then I go back to my office to refine the search a little more.
I repeat this process about eight times over a couple of hours, taking a break to call home and say I'm going to be a bit late. Eventually, I narrow things down to the point where I figure out the problem.
Boy, is it a stupid problem. And it's not my fault. The original code should have worked. Ready?
On my development machine, I'm using Microsoft's Oracle ODBC driver, and on the issuing station, I'm using Oracle's Oracle ODBC driver. That shouldn't make any difference once the connection has been established, but in practice, here's what happens:
Say the database has two columns. The first column is the customer's first name, and the second column is the customer's last name. My database function goes to the database and says, in essence, "Give me the last name. Now give me the first name." This works fine on my development machine. But on the issuing station, it barfs. Oracle's driver refuses to move backwards along the columns.
So I painstakingly go through every field and make sure it's in the correct database order, then go back to the issuing station and try it again.
Success! And it only took ten hours!
Then I got a Dr. Watson error (for you non-techies, that's Bad) on the next step.
But by then, I didn't care. I packed up my things and went home.
That was my work day yesterday. And that's why I don't have an interesting story about the non-work part of my day.
I am so ready for Monday's holiday.
Word of the Day:
Croesus - a very rich person
Currently Reading:
- The Macintosh Bible by Sharon Aker
Current Projects:
- Kris' afghan
- placemats