Thinking about upgrading, migrating, applying maintenance on UNIX?
ErikKirk 2000005NXT Visits (2847)
Thinking about upgrading, migrating, applying maintenance on UNIXtm? How about 1 minute sanity check of your environment?
Problems often occur during or after an upgrade, migration, or application of maintenance. If you have bad luck, there's a good chance everyone will become aware of that little thing you left out in your planning. It's just one of those things... you succeed in private, but fail in public. I can't change that fact, but what I can do is to help you avoid many issues with a simple, one-sentence tip.
Here's the tip:
Ensure the .mqsiprofile is the last .profile that runs when setting up your environment to use broker commands.
It's really that simple. For those of you who like the short and sweet version, you're done here.
Need to know What? When? Where? How? and Why? ...then see below:
The .mqsiprofile is the little shell script that sets up all the environment variables for you to run the message broker commands. It sets up the environment for the broker executables to find their dependent libraries and resources.
The mqsiprofile should be run before you run any of the WebSphere Message Broker (WMB) commands like the ones described. And, it should be the last environment settings made before the WMB commands are to be issued. Certainly, this is the last environment setting that should be allowed to take place before the mqsistart command is used to start the broker. Here are some WMB commands in the information center:
The .mqsiprofile is in the WMB installation /bin directory.
My personal favorite way to setup the broker environment is to:
The .mqsiprofile inserts WMB values into the system environment variables rather than appending to the existing values. We thereby make better use of the left-to-right search algorithm the OS performs when attempting to locate dependencies or resources of our executables that launch our processes. If you run the .mqsiprofile first and then make calls to other .profiles of other products, then you'll likely find those .profiles have taken a similar approach to WMB.
Why does this matter?
In the land of Application Integration and Middleware, there’s a lot of overlap. Typically, components are originally designed to serve a niche market and with limited scope, but later grow to accommodate other features. Growth leads to overlapping of functionality. Similar functionality is most often implemented by similar code. This similar code winds up in similar libraries. Quite often, these similar libraries have the same name. However, the libraries are most often slightly different. Unfortunately, those differences may not be found until later.
You like examples better?
exec(): 0509-036 Cannot load program mqsistart.bin because of the following errors:
0509-130 Symbol resolution failed for /opt/IBM/mqsi/6. 1/xm
0509-136 Symbol XML4
0509-192 Examine .loader section symbols with the 'dump -Tv' command.
Here's an easier way to think of the messages above:
The broker cannot start because...
mqsistart.bin can't be loaded because...
This symbol </opt/IBM/mqsi/6. 1/xm
This symbol XML4
So, what is obvious in the error message?
The location of the files. libX
Here's what happened:
So, how to fix it?
If you ask support teams, or forums how to fix a problem like this, the common approach would be to tell you to change the LIBPATH so the WMB library is located before the MQ library. And that is technically correct. However, that should leave you with the question, "Why did this happen in the first place?" The answer should lead you to the fact that some environment settings were executed after the .mqsiprofile was executed. Left alone, the next problem will likely be more mysterious.