Thursday, March 23, 2006

 

Success and disaster

I finally got the production MQ cluster reformatted. It took it almost three full days and the recreation of one queue manager (which I probably didn't have to do). It helps if you read the manual thoroughly. I now know more about refreshing clusters than I should really have to know.

Then I found out only in passing that I would have to participate in the disaster recovery test for three different applications next weekend. I had only been expecting to work on recovering the cluster. Two of the applications are Windows-based which will require installs from the scratch, and the one includes MQSI which I haven't worked with. There is no documentation on MQ configuration for any of the applications! The other application and the cluster we should be able to restore via TSM, but I'm not looking forward to this.

I have an insurance exam to write on the Monday morning after the test and I'm not completely prepared yet.

D.

Saturday, March 18, 2006

 

Bureaucratic tempest in a teapot

I made the mistake of asking for a timetracking code for a project I have been assigned to.

I sent the request through the solution architect who had invited me to participate in a meeting to discuss the MQ setup. He forwarded the request to the Project Manager who calls me up and asks how I am involved in the project. Quoi! The PM then calls the department Project Office liaison person, and I have to find out what kind of resource I am (type 2 which means both projects and Business As Usual). Then he goes to my boss and says this work should be done as Business As Usual. As far as I can understand, my time would then not be billable to the project. I've spent more time discussing this issue than I have actually working on the project so far.

I am getting hung up on being categorized as BAU resource, but should know better. It doesn't matter what your category is-when you're gone, you're gone.

D.

Thursday, March 16, 2006

 

Technical difficulties

I've seen more MQ reason codes in four months at the new place than I did in four years at CLA.

I've been working the QA MQ cluster, getting it operational. This past week has been spent doing failover testing. I tried doing it manually (don't ask) and ended up screwing both servers. After the sysadmins fixed them up (I don't think they're too happy with me right now), I did shutdowns and reboots, and everything was fine. Shutting down one server caused all the queue managers to failover to the other as they should. "Knockdown" testing on the other hand only works on the one side of the cluster, the server with the heartbeat.pid file. I looked at the report from the IBM proof-of-concept, and it looks like they consistently used only the one queue manager for knockdown testing.

The production cluster had been set up with queue manager names and a repository name that aren't consistent with the existing convention. I'm trying to change them but so far they have resisted my efforts. I may have to delete and recreate.

D.

Saturday, March 04, 2006

 

All "good" things come to an end

The IBM project has come to an end. We're still waiting for their final report, but I think they have some usable recommendations to allow the app to scale to 12000 users. I still have some cleanup work to do since they changed the infrastructure architecture midstream. The PM told me that MQ checked out OK. Tell me something I don't already know. You have to mess with it pretty good to make it not work, and I haven't seen any evidence of that. Best practices have not been followed though.

We finally repatriated that recalcitrant website late Monday afternoon. At first, the first page wouldn't come up. We were thinking DNS propagation delay. I got a connection outside the firewall, and it displayed. The team leader who refuses to give me admin access to my laptop was quite helpful with this, and with getting one of his guys to go back into the office and fix up an internal DNS entry we weren't aware of at the BA's location. By that time, the backend was down. We stayed the course until the next morning, and everything tested out fine. I never want to go through another project like this again. I ended up being PM by default, and it was hell in our non-service oriented culture. Of course as Harvey Silver would say, a lack of planning on my part does not constitute an emergency on their part. We were charged 14 hr @ $165/hr for the MQ guy at CGI. I'm working for the wrong company.

My sister's contract was rescinded after her PM spent the weekend thinking about it, and now I'm low on work myself.

D.

Friday, March 03, 2006

 

What a boner!

I tried to set up a mail agent to forward my work mail to my Yahoo account. I still don't have access to my work email from home even though I requested it mid December.

What I ended up doing was sending quite a bit of my mail database to everyone I had corresponded with or anyone who was copied in any email I received including external. I created my own virus. People complaining about it created a mini-storm after the fact. The one VP just laughed and told me I was now infamous. Some people actually the email seriously and responded accordingly.

D.

Thursday, March 02, 2006

 

New and old

Since joining my new company, I have administered MQ on two new platforms, Linux and Windows. I've created clusters, queue aliases and queue manager aliases which I hadn't done before. I almost forgot MQSI-I've done a couple of deployments.

Another ex-CLAer (Denis G.) joined the company this week. He was a solution architect before (we fought over the webMethods operational readiness strategy at the old place), and he's a member of the architecture group at the new place. He dropped by my desk today, and we chatted for a few minutes. He's already picking up on the vibe here-there is a superficial layer of process.

D.

This page is powered by Blogger. Isn't yours?