Tuesday, September 18, 2007

When You've Got Nothing to Lose

I don't do politics here but I can't pass on this one. Lt. Col. Dr. Robert M. Bowman, (USAF, ret.) has a rather "conservative" site over at thepatriots.us. His open letter to US military commanders left me wondering just one thing: what the fuck took someone so long to write this?!

We find out early on. Dr. Bowman has terminal cancer. At the end of the two-page letter he writes how he remained silent before the US went into Iraq and that he "must not make that mistake again." Fair dinkum, but why did he remain silent? It looks like for the same reason everyone in the Pentagon who might read it has: make waves and lose your pension as well as your position on the board of a contractor once you retire. The only time for action is when you have nothing left to lose. A looming deadline, for example, and terminal cancer sure as hell gives you one of those.

Satish doesn't have terminal cancer as far as I know, but he, too, was running out of options. It started simply enough.
Did install one app server on one windows machine and fileserver got installed in c:\appz\filesrvr

Installed new server on another windows m/c in the same system but then when this server tries to access the filesystem it gives following error message . To facilitate this changed the following parameters pointing to the shared filesystem path for all the components of server 2
OK, maybe that's not so easy, but being able to decode whatever the hell he's on about makes my degree relevant to my job. Satish sent me a list of errors (or "erros).

The path 'T:\uprefs' does not exist or is not a directory. If the problem persists, please contact your systems administrator.

Over and over again for every single component of the system. Pages of these, something like two dozen per user access attempt. If you work in any remotely related field (which you probably do or you wouldn't be reading this), you're probably thinking, "He didn't map the file system properly." That's what I thought.
Hey, Satish. Check the permissions and accessibility of the T: drive for the second server. The errors you're receiving indicate a missing path/directory or incorrect permissions. See KB doc 1AT9003 for all the gory details and bits to double-check.

And that should've been the end of it.
It is all set correctly.. I can map the T:\ drive from m/c 2 and access all the directories, the installation on both the m/c has been done using the same id, also the sharing and security has been given as full control
No, it hasn't. I know it hasn't. If it had been you couldn't possibly see a attmod.cpp(901) error. It's simply impossible. I'd sooner believe that Lyndon Larouche isn't a crackpot thief than I would believe that you set up the system correctly. There is only one way you can get $OurBigApp to throw a mgdir.cpp (097) error: delete/remap/fail to map the fucking path.

Which is more or less what I told him. Less. Much less. And in much nicer and simpler words. Not quite as simple as this explanation of relativity, but certainly something that my cow-orkers' kids could understand and follow.

Satish came back again, his English getting even choppier.
I tell you It all is set correctly..! Our administrator is out of station and I am mapping correctly. drive T:\ is mapping from m/c 2 with all directories access , We are now ask a third once for the solution for this problem that the T:\ is not to be reached from m/c 2.
In case you're wondering, "out of station" is Indian slang for "out of town", meaning I'm dealing with a scared PFY n00b. Worse, his company has entrusted the very expensive process of setting up $our_(very expensive)_BigApp to... him.

I fired up Paint.NET, drew a quick diagram and sent him not only explicit instructions but a load of documentation page references. Bangaloreans seem to love that (more on that in a later entry this week). You give 'em written documentation of an 87-step process and they'll take that over the easy, three-step way you tell 'em every fucking time.

Since I could see that he was having a conniption fit thinking that I wasn't taking him seriously, I also asked him to send me the server logs. All of them. Within two hours I had a 25MB zip of half a year's logs and his acknowledgment that he would continue reading through the docs I'd cited and would get back to me.

I waited. And waited. And waited. Two weeks later Vera was harping on about my huge backlog of no response tickets. I told her I preferred to give customers extra time when it appeared they need it. "It's very good for customer satisfaction." She can't touch me when I say that. It's not just my Get out of Jail Free card, it's my motherfucking Get Off Death Row and Go Straight To Paradise Island card. She can try to get around it but that phrase is golden.

Still, it doesn't behoove me to piss her off so I set to work closing out tickets, first sending a personal note asking about the subject one last time. If it's sorted they'll usually ignore it but sometimes they write back. $Telco was more than a week past the go-live date. The problem had to have been sorted by now. Satish wrote back.

Resolved this issue, by setting the UNC path for the filesystem

Uh-huh. Back up against the wall he finally gave in and did what I initially told him: check the fucking path. I can't help wondering if I'd included a "please do the needful" in my original answer that he might've actually done it. This only makes me wonder more about what the hell he was doing each time I sent an update.

Root Cause: 17-Fuckwit.

Labels: , , ,


Post a Comment

Links to this post:

Create a Link

<< Home

In compliance with $MegaCorp's general policies as well as my desire to
continue living under a roof and not the sky or a bus shelter, I add this:

The views expressed on this blog are my own and
do not necessarily reflect the views of $MegaCorp, even if every
single one of my cow-orkers who has discovered this blog agrees with me
and would also like to see the implementation of Root Cause: 17-Fuckwit.