Too Fast Too Furious (or instantaneous program run time)

There was this time when a user called me up for help. I recognised the application she needed help on, which I’m maintaining but not very familiar with. For reasons that will be too tedious for me to explain, I couldn’t solve the problem without going to the one computer, which happened to be near my user, that’s running that program. And my user was conveniently located a few floors below mine… I mouthed a silent sigh, and told her I’d be down in a few minutes.

Man in relay race
[image by photosbyjim]

A bit of information on that program first. It’s run once a month, and its purpose is to send a few hundred emails each with an attachment (which is unique to the recipient).

I took my notepad and a pen in case I needed to take down notes, and left for the user’s office. When I arrived, she showed me what she mentioned on the phone. The program ran, but some attachments (and correspondingly some emails) weren’t sent out.

I checked the log file, but there were no error messages, which suggested that the program ran fine. Now the program used a third party DLL to talk to Microsoft Outlook (the email application used), and sends out emails using Outlook. Since the program ran fine (no errors), the only error left would be with that third party DLL or Outlook.

It would be difficult to debug the DLL, so I checked Outlook first. My instincts told me to try sending a test email. It failed. Aha! The error message said something to the effect of “Mailbox full”. I asked the user to archive some of the emails, and she said she didn’t know how. After sighing in my mind, I put on my computer helpdesk hat and proceeded to archive the emails for her.

Then I told her to run the application. She proceeded to go to “Task Scheduler” and I was perplexed, and asked what she’s doing. Turns out that the program was scheduled to run every month on a certain day, and she’s going to reschedule the program to run a few minutes later. The scheduler would run the program a few minutes later, and she would reschedule the program to run at its original schedule. Ai-ya-yai-ya-yai…

Nearing a mental meltdown, I told her as calmly as I could, that she could just double-click on the program to run it.

“Oh really! That should save some time,” she held her hand to her mouth. She went to double-click on the program. And nothing happened. Or so it seemed…

“Nothing happened!” she looked at me.

I went back to Microsoft Outlook, and checked the sent mail folder. Sure enough, the emails to be sent were there. I asked the user to confirm, and she nodded.

“But it’s so fast!” she pointed at the computer screen.

Too slow, and I get complaints. Too fast, and I get complaints. Sometimes, I just can’t win…

  1. Tom Tedder

    Hi Vincent;
    Read your speed blurb with a grin on my face, I am 71 and have worked with computers since late 70’s

    Have you heard of this one?? I recently upgraded from win2000 pro to XP pro because my daughter and I have been playing adventure and puzzle games together for years (we talk and compare notes by telephone as we play)

    I upgraded because some of the games we wanted to play would not run in 2000.

    Since I started running XP now all games that use a count down clock or timer, are having their clocks run about 4X too fast, making some areas of the game (timed puzzles) near impossible!

    My local computer guru is scratching his head so far on this problem.

    Tom

  2. Vincent Tan

    Hello Tom! I’ve never heard of your specific case before. I do have a similar one.

    Back when I was in university, I wrote a computer graphics program about a paper aeroplane. It relied on the computer clock to determine speed too. The problem was, the aeroplane flew at different speeds when I ran it on my computer, and when my professor ran it on his.

    Your story is more awesome than mine. Great that your daughter and you are playing games together. Adventure and puzzle games no less.

Comments are closed.