Friday, January 20, 2006

Techi-dumb

I have a customer.  One of many.  This particular customer is having a problem with their server this week.  Server; as in, “Computer Server”. Not, as in, “food-server”.  Although as this post reveals, I’m not really sure their “hardware” support “technician” understands this concept.

For some reason, at this customer’s location, the server isn’t releasing session files when a workstation closes out of a program.  Our software has a problem with this.  It likes exclusive use of files when it’s writing data to them.  (Go figure.)  So the customer calls me and tells me our software is giving them a warning, “Cannot get exclusive use of X-file” when they try to perform certain functions.  I tell them, “This is not a software problem … this is a hardware problem. Call your hardware technician and get him to find out why the server isn’t releasing the session files”.

I hate this particular technician.  Unfortunately, I have to deal with him far to often. He calls me, “to get a clearer understanding of the problem”.

Techi-dumb:     “Customer X tells me you said, “The server isn’t releasing session files when a workstation closes out our program.  Can you tell me what’s going on?”
Me:     “The server isn’t releasing session files when a workstation closes out our program.”
Techi-dumb:     “What do you think might be causing this?” HE ASKS ME!  
Me:     “I don’t know.  I don’t do hardware support.”
Techi-dumb: “Have you seen this happen at other locations?”
Me:      “Yes”.
Techi-dumb:      “How’d you fix it?”  
Me:      I don’t do hardware support, I didn’t fix it.  They called their HARDWARE people.”
Techi-dumb:       “Oh, well do you know they fixed it?”
Me:     “No, I don’t know how they fixed it.  I didn’t talk to them.”  In my mind I am screaming. “No, I sure don’t …. BECAUSE I DON’T DO HARDWARE.  IF IT’S BEYOND PLUGING IN A CORD, I DON’T KNOW!”

Then techi-dumb asks me where the sessions file is located and the naming convention for the files.  I tell him.

Techi-dumb: “So you think it’s the server, huh?”
Me:     “Ummm, yep.  They even got the error after they re-booted the workstation and downed the server.”
Techi-dumb: “So the files are still there after re-booting?”
Me:      “Yes” (That’s why their getting the error!)
Techi-dumb:      “And they shouldn’t be?”
Me:     “Umm, once again, I’M NOT A HARDWARE PERSON, but it seems to me that there should be NO SESSION FILES if the computers aren’t running and the client ISN’T IN THE PROGRAM”.
Techi-dumb:     “Hmm, well since we know the name of the files, maybe I should just write a batch file to delete them when the server or workstations are re-booted”, he tells me.

Okay, call me silly – but isn’t that like saying, “Gee, your finger hurts? Well, let’s not waste time trying to figure out what’s causing the pain.  We’ll just cut it off, you’ve got 9 others.”  

And besides?  Just for the record?  The problem isn’t that the session files exist. The problem is still that the HARDWARE isn’t RELEASING the file when someone CLOSES OUT OF THE PROGRAM.  Call me silly, but I don’t think a “HARDWARE solution” involves writing a batch file.

My job … I just LOVE IT!

1 comment:

Anonymous said...

This is a programming error, not a hardware issue.

There is a reason your program is not deleting the files, most likely because they are in use by other sessions.

If they are no longer in use that is when the program should delete them.

If it is not able to delete the file it should go into an exception programmed into the software which tells itself to delete the file upon next startup of the server (create a run once batch is pretty simple)

"But restarting the server which closed out any software locks on the files would have solved it then!"

One of two things exist, if not both:

1.) Most likely the startup function is based upon a "if exists('temp fileXXX') then produce error" instead of just trying to open the file.

2.) There is another "This file is locked" file that keeps track of which files are locked and isn't being updated.

Ultimately it boils down to a software problem.

For the record I am a software and hardware person ^_^.

If you can delete the file by hand, (or batch file like you suggested) then your program should be able to as well, if you cannot delete the file by hand then you are right, it's a hardware issue...if the program isn't running.

Because if the "HARDWARE" is keeping the file from being released, you wouldn't be able to delete it by hand either.

And not to be mean or anything, but if you claim to not know anything (though I believe you are overstating your lack of knowledge), about hardware then how can you say for sure that the problem is hardware?

Perhaps the "HARDWARE" technicians simply suggested that they start using another program due to the lack of service? That's what I would do.