If you don't like reading about what goes on at large companies or more specifically what goes on at TCIDNN (The Company I Dare Not Name) you might want to skip today's post. Some people actually enjoy reading about my trials and tribulations at TCIDNN.
Today was a fun day at TCIDNN. We outsourced our Help Desk to save money. I got three calls from them this morning where the dipsticks gave me information on problems that did not make any sense.
Me: What did the user say?
Them: Incomprehensible bullshit that makes no sense.
Me: I'm sorry but that's incomprehensible bullshit that makes no sense.
Them: That's what the user said.
Me: Have the user call me at this number xxx.xxx.xxxx.
What do you think the Help Desk did? They called another support person in another area that had nothing to do with Host Systems and tried to get them to fix the problem. Then they opened a record on our SPTS (Stupid Problem Tracking System) and routed it to me. They didn't put any contact information in it so I did not know how to get in touch with the user. Oh yes. This is gonna work just great.
We've been supporting Canada for a while now. When we took over their systems we put them on their own processor. It's an obsolete processor, but they run obsolete systems so that works out OK. We're in the process of moving their applications to one of our up to date systems, but it's a slow process so we still have to keep their systems active.
To prepare for our new processor, my team lead asked me to move their systems off the old box and onto one of our processors so we could move the obsolete processor off the floor, thus creating space for the new processor. This was actually a fairly easy project since these systems run under VM (Don't ask. It's a mainframe operating system) so I could move the systems to another VM system by copying their directory entries over with some minor changes. Then, I would have the VM guy clean up the directories and update their profiles to couple some virtual CTC's (Channel to channel connections. It's a way that mainframe processors and systems can communicate with each other.) I also had to have the network guy update some OSA (Open System Architecture) adaptor definitions to get the TCPIP stuff working.
I did this project last week. The VM guy did his stuff except for the virtual CTC's. I set up some real CTC's to another processor and mapped them to one set of the old virtual CTC's on the Canada system responsible for controlling the communications. So we had one working path. We could take care of the other connection later. I did this on Wednesday.
I came in Thurdsay morning and my team lead was on the phone with the network guy and the VM guy. I guess I should say sumpin' about the network guy before I go any further.
We used to have a real good network guy but he retired last fall. For over a year our current network guy was told that he would be replacing him and he better start getting his skills up. This guy knew absolutely nothing about SNA/VTAM networks. He knew nothing about MVS or VM. He was given a year to start building those skills. He waited until two months before the old network guy retired. The only reason he even started then is because after my team lead telling our CDSMŽ (Clueless Dipshit Manager) over and over about how this guy was not gonna be ready to take over the network, my CDSMŽ finally told him to start learning, or else.
So, here it is Thursday morning and the network guy has screwed up the OSA adaptor. Not really. He just thought he had. He actually did it right and was up until 3:00 AM working on it. He didn't understand why it wasn't working. It was working. It just needed to be attached to the system using the virtual address of the OSA adaptor it used to use. I had been very specific about that in my note. Five minutes into the door I had everything working. Then he wanted us to explain the concept of virtual I/O versus real I/O on VM systems. Can't do it with the knowledge that he had. It would be like trying to explain color to a blind man or logic to a liberal.
So the systems are now moved and everything is working except one minor problem that we hope to have fixed this week.
My phone rang around noon Saturday and it was my team lead. IBM had come out to run diagnostics on an OSA adaptor and work on one of our DASD boxes. To be on the safe side, my team lead shut everything down. When he brought everything back up. the Canada systems and one of the Atlanta systems didn't connect up. Whom do you think he called? Not the network guy. As he told me today, he wanted to get home in time for supper. I knew the CTC's for the Atlanta system so I told him to display them. They did not display the right status so I had him enter some VTAM commands and got that working.
I don't have the Canada connections memorized so I had him call up the diagram I updated on Friday. Lucky for me I did. I needed to know both the virtual and real addresses and I had added them to the diagram. One set of addresses hadn't attached properly so I had him attach 'em and recycle the PU's and, bingo, everything worked.
So why aren't I the network guy? Because I got enough stuff to do. And anyway I still do a lot of the network stuff. I'll do most of the design and implementation when we get the new processor in. I can just see the network guy trying to gen an NCP. Ouch!
As if enough stuff wasn't going on today, my team lead went out to lunch and went home. The network guy called him and couldn't reach him so he called me. It's bad news when you talk to the network guy. He asks a lot of questions which is good, but some of them are not answerable because he does not have the knowledge yet. A phone call from him lasts an eternity. Two weeks ago my team lead and I had been on the phone with him for an hour and all of a sudden some systems went down. We had to terminate the call to handle the problem. This was one of the few times we were actually glad sumpin' went down. Fixing a problem was preferable to trying to explain sumpin' to the network guy.
One of the things the network guy wanted me to explain to him today was CTC channels, CNC channels, and FICON channels. Try and explain that to someone who has no mainframe knowledge.
One good thing with all the bullshit that went on at work today: The day sure went by quickly but the Help Desk sucks and there are probably some pissed off users.
Oh well. Tomorrow is another day.
Posted by denny at May 3, 2004 07:27 PM