Thursday, January 26, 2006
Busy three weeks at work
I have been working on setting up a performance and capacity testing environment. IBM has "given" us a program to emulate a mainframe so we can run tests without affecting any other applications. At first, the P&C environment was to co-reside with QA so it needed to have both mainframe and emulation backends. Then it wasn't so it didn't. Then the WAS admin needed to verify the application server set up so it did. Every time we switch it back and forth, something breaks. I've also got a channel initiation problem that I can't figure out but have circumvented. I finally got everything stablized this past Monday. I'm really starting to like the Windows platform for MQ. The MQ Explorer GUI has a lot of useful features.
I've also been parachuted into a project to repatriate a website for an application that is being sunset. The previous MQ resource stalled it long enough that he threw it in my lap with the handoff of support. We scheduled a cutover test on Wednesday night. I assumed that people (myself included) knew what to do. The MQ guy at CGI took 25 minutes to flip over the channels from the other outsourcer to ours when it should have only take 10 or 15 minutes tops. We start testing, and it doesn't work. I go over to the WAS admin. In the WAS error log, we see a code that says the queue manager isn't available which it is. I've seen this before when there are DNS issues. We check the application properties file, and it is set up with the right IP address. We decided to pull the plug on the test since the problem couldn't be resolved that night thinking that it was an architectural issue. We didn't check the WAS stdout log. Then we had problems accessing the production site to check that the swing back went OK.
Thursday morning, I did a postmortem. I also set up our infrastructure to match the other outsourcer's (WAS and MQ co-reside) creating another queue manager. I was able to do some partial testing without a backend, and it worked. Friday morning, I started planning all the changes I would have to do to link the two queue managers (the one tested and the one I created). The WAS admin asked me if I had checked the transmission queue from Wednesday's test. I did, and there was one message there although we had done a number of tests. I didn't understand why at first. I went back to the WAS stdout log, and I can see the IP address flipping back and forth. I ask to WAS admin to swing back to the address we used in the test. The original setup now works! This time, he restarted the application server. All we have to do now is retest. No changes are required. The one message is from a swingback test we accidently ran on the testing URL.
I'm also working on getting the MQ clusters operational. Projects are being told to use the cluster but only the development environment is ready for primetime.
I don't have any time right now to take on JBoss or WebSphere responsibilities.
D.
I've also been parachuted into a project to repatriate a website for an application that is being sunset. The previous MQ resource stalled it long enough that he threw it in my lap with the handoff of support. We scheduled a cutover test on Wednesday night. I assumed that people (myself included) knew what to do. The MQ guy at CGI took 25 minutes to flip over the channels from the other outsourcer to ours when it should have only take 10 or 15 minutes tops. We start testing, and it doesn't work. I go over to the WAS admin. In the WAS error log, we see a code that says the queue manager isn't available which it is. I've seen this before when there are DNS issues. We check the application properties file, and it is set up with the right IP address. We decided to pull the plug on the test since the problem couldn't be resolved that night thinking that it was an architectural issue. We didn't check the WAS stdout log. Then we had problems accessing the production site to check that the swing back went OK.
Thursday morning, I did a postmortem. I also set up our infrastructure to match the other outsourcer's (WAS and MQ co-reside) creating another queue manager. I was able to do some partial testing without a backend, and it worked. Friday morning, I started planning all the changes I would have to do to link the two queue managers (the one tested and the one I created). The WAS admin asked me if I had checked the transmission queue from Wednesday's test. I did, and there was one message there although we had done a number of tests. I didn't understand why at first. I went back to the WAS stdout log, and I can see the IP address flipping back and forth. I ask to WAS admin to swing back to the address we used in the test. The original setup now works! This time, he restarted the application server. All we have to do now is retest. No changes are required. The one message is from a swingback test we accidently ran on the testing URL.
I'm also working on getting the MQ clusters operational. Projects are being told to use the cluster but only the development environment is ready for primetime.
I don't have any time right now to take on JBoss or WebSphere responsibilities.
D.
