 |
ITCAM for SOA: WebSphere Message Broker Data Collector - Potential Upgrade / Uninstall Issues
|
| | | Abstract |
In ITCAM for SOA environments that use the WebSphere Message Broker data collector, there are several issues that you might encounter in upgrade or uninstall scenarios if the procedures in the ITCAM for SOA publications are not closely followed. | | | | | | Content |
Overview
This document provides detailed information on some of the problems that customers using ITCAM for SOA to monitor WebSphere Message Broker (WMB) might experience when upgrading from WMB 6.0 to WMB 6.1 or from ITCAM for SOA 6.1.1 or 7.1 to ITCAM for SOA 7.1.1. It contains information on some of the changes made in WMB from 6.0 to 6.1 and the changes that were necessary in ITCAM for SOA 7.1.1 to support monitoring both WMB 6.0 and WMB 6.1 in as many runtime environments as possible.
To avoid running into these upgrade problems, the basic rule of thumb is: On any given machine, always disable all WMB data collection (for all message flows in all execution groups of all brokers) before upgrading from ITCAM for SOA 6.1.1 or 7.1 to ITCAM for SOA 7.1.1, and then enable all WMB data collection again after the upgrade is complete. The ITCAM for SOA documentation has always stated this as a necessary step during the upgrade process, but it can easily be forgotten. Similarly, to avoid problems when uninstalling, the basic rule of thumb is: On any given machine, always disable all WMB data collection (for all message flows in all execution groups of all brokers) before uninstalling ITCAM for SOA 6.1.1, 7.1 or 7.1.1.
The remainder of this document describes some of the problems that might occur if this process is not followed, and how you can recover from those problems. It also describes what you might see when upgrading from WMB 6.0 to WMB 6.1 without first disabling all WMB data collection, and the enabling again after the upgrade is complete.
WebSphere Message Broker Changes from 6.0 to 6.1
WebSphere Message Broker has made several changes from 6.0 to 6.1 that you need to understand, because they are the reason for many of the changes in ITCAM for SOA 7.1.1.
User Exit API Changes
WMB has added a new user exit callout method in WMB 6.1 to allow a user exit to obtain the correct message identifier for output MQ messages. ITCAM for SOA exploits this new user exit callout to track message identifiers and to more accurately correlate request and response messages. But this means the ITCAM for SOA user exit compiled for WMB 6.0 cannot exploit the new callout API provided in WMB 6.1, and the ITCAM for SOA user exit compiled for WMB 6.1 cannot be used in WMB 6.0 environments where this callout does not exist. As a result, ITCAM for SOA must ship separate versions of the user exit (LEL) file for WMB 6.0 and WMB 6.1.
Default Execution Group Bit-Mode
The default bit-mode for WMB 6.0 execution groups (message flow engines) was 32bit on most platforms and 64bit on those platforms where only 64bit execution groups were supported (e.g. HP-UX Itanium). In WMB 6.1 the default bit-mode for execution groups is 64bit for platforms that support 64bit execution groups and 32bit for other platforms (e.g. Windows and zOS). ITCAM for SOA 7.1.1 continues to support the same WMB 6.0 execution groups as in earlier releases and has been enhanced to support WMB 6.1 64bit execution groups, as well as WMB 6.1 32bit execution groups for some platforms. In the following table, the X's show the execution groups supported by ITCAM for SOA 7.1.1.
| Platform | WMB 6.0 / 32-bit | WMB 6.0 / 64-bit | WMB 6.1 / 32-bit | WMB 6.1 / 64-bit | | AIX | X |  | X | X | | HPUX-Itanium | | X | | X | | Linux-ix86 | X | | X | X | | Linux-PPC | X | | | X | | Linux-s390 | X | | | X | | Solaris SPARC | X | | X | X | | Windows | X | | X | | | zOS | X | | X | |
User Exit Path Extensions
WMB supports two methods of extending the user exit path with additional directories that contain user exit library (LEL) files. The first method is to issue the mqsichangebroker command with the -x parameter to define the full user exit path. When this method is used, WMB records the specified user exit path under the specified broker in its "registry". On Windows, the registry is actually the Windows registry, and this command creates a UserExitPath key under the specified broker whose value is the specified path string. On Unix platforms, the registry is a directory under the MQSI_WORKPATH (normally /var/mqsi/registry), and this command creates a UserExitPath file under the specified broker whose content includes the specified path string. This method of changing the user exit path is only supported for 32bit execution groups; the mqsichangebroker command cannot be used to change the value of UserExitPath64, which is used by 64bit execution groups.
Important: The user exit path is maintained separately for each broker.
The second method is to create a script in the common/profiles directory under the MQSI_WORKPATH that extends the MQSI_USER_EXIT_PATH and MQSI_USER_EXIT_PATH64 environment variables to include new directories that hold user exit (LEL) files. (The MQSI_USER_EXIT_PATH is used by 32bit execution groups, while the MQSI_USER_EXIT_PATH64 environment variable is used by 64bit execution groups.) The mqsiprofile script of WMB (which runs each time a WMB command console window is opened) automatically sources all of the scripts in the common/profiles directory, giving each script in this directory an opportunity to modify the WMB command environment. But since the MQSI_WORKPATH is shared by all brokers on a machine (even if multiple instances of WMB are installed on the same machine), the common/profiles directory and all the scripts in it are also shared by all brokers on the machine.
Important: Directories added to the user exit path in this manner are not specific to a single broker, but are shared across all brokers on the machine.
ITCAM for SOA changes from 6.1.1 and 7.1 to 7.1.1
ITCAM for SOA 7.1.1 includes several changes to its WMB data collector support to accommodate the changes in WMB from 6.0 to 6.1.
LEL Filename Changes
ITCAM for SOA 7.1.1 now supports both WMB 6.0 and WMB 6.1, and on some platforms supports both 32bit and 64bit execution groups. Unfortunately, it is not possible to build a single user exit (LEL) file that can be used for all these combinations, because the APIs changed between WMB 6.0 and 6.1 and because the loader requires different formats of the LEL file for 32bit and 64bit processes. In ITCAM for SOA 6.1.1 and 7.1, a single LEL file, mqsisoauserexit.lel, is shipped on each platform, but for v7.1.1 several versions of the LEL file are shipped for each platform. As a result, the name of the LEL file is now in the form mqsisoauserexit_wmbXX_YYbit.lel, where "wmbXX" is either "wmb60" or "wmb61", and "YYbit" is either "32bit" or "64bit".
For example, on Linux-ix86, AIX and Solaris-SPARC platforms, three versions of the LEL file are provided, named mqsisoauserexit_wmb60_32bit.lel, mqsisoauserexit_wmb61_32bit.lel, and mqsisoauserexit_wmb61_64bit.lel.
User Exit Path Changes
In ITCAM for SOA 6.1.1 and 7.1, the KD4configDC and ConfigDC tools used the mqsichangebroker method of updating the user exit path. But because this method is not supported for 64bit execution groups, ITCAM for SOA 7.1.1 had to change to use the common/profiles script method of updating the MQSI_USER_EXIT_PATH(64) environment variables. (This was really only required for 64bit execution groups, but it was decided to make this change for both 32bit/64bit execution groups for the sake of consistency.)
This change in the way the user exit path is updated is subtle, but it actually necessitates a number of design changes in ITCAM for SOA 7.1.1. The old method (mqsichangebroker) allowed us to define a different runtime library directory for each broker (KD4/config/wmb/lib/<broker>), but with the new method all brokers share the same common/profiles scripts and therefore the same user exit path string. If ITCAM for SOA continued to use per-broker runtime library directories, it would have to add all of the directories (for all brokers) to the user exit path; but at runtime, every broker instance would load the ITCAM for SOA user exit (LEL) file from the runtime library directory that appears FIRST in the user exit path. Continuing to use per-broker runtime library directories might be misleading to you, because it would imply a broker was loading its LEL file from its own directory, when in fact it might be loading it from a different directory. For this reason, in ITCAM for SOA 7.1.1, all brokers share a single, common runtime library directory. This directory is KD4/config/wmb/lib for WMB 6.0 environments, and KD4/config/wmb61/lib for WMB 6.1 environments. (It was necessary to use two different directories for WMB 6.0 and WMB 6.1 because ITCAM for SOA ships different LEL files for each of these environments.)
To add the appropriate runtime library directory to the user exit path, ITCAM for SOA 7.1.1 creates a script in the WMB common/profiles directory (KD4setupSOAUserExitPath.cmd/.sh) when the very first Message Broker flow is enabled for monitoring. (The script contains logic to check the WMB release (MQSI_VERSION_R environment variable) and add either the KD4/config/wmb/lib or KD4/config/wmb61/lib directory to MQSI_USER_EXIT_PATH and MQSI_USER_EXIT_PATH64 environment variables.) At the same time, the LEL files are copied from the ITCAM for SOA install directory (KD4/lib) to these runtime library directories. Where applicable, both the 32bit and 64bit versions of the LEL files are copied into the directory, because the loader can find and load the LEL file whose bit-mode matches the execution group. Similarly, ITCAM for SOA 7.1.1 deletes the KD4setupSOAUserExitPath.cmd/.sh script from common/profiles and attempts to delete the LEL files from the runtime library directories when the last Message Broker flow is disabled for monitoring. (It might not be possible to delete the LEL files in multi-broker configurations, since the file might be loaded and locked by another broker instance. In this case, you must stop all brokers and manually delete the LEL files.)
Upgrade Implications
Because of the user exit (LEL) filename and runtime library directory name changes that were implemented for the WMB data collector in ITCAM for SOA 7.1.1, it would have been very difficult to rewrite and maintain the data collector configuration scripts (KD4configDC.bat/.sh and configMBDC.bat/.sh) to recognize and support both the old and new conventions. So the ITCAM for SOA 7.1.1 configuration scripts recognize and support only the new convention. This is why it is very important that you disable ALL Message Broker data collection in ITCAM for SOA 6.1.1 and 7.1 before upgrading to ITCAM for SOA 7.1.1. The scripts provided in those previous releases clean up all the old files and directories. After all Message Broker data collection is disabled, ITCAM for SOA can be upgraded to 7.1.1 and the scripts in this new release can be used to enabled data collection again with the new filename and directory conventions. To prevent a mixture of the two environments, the ITCAM for SOA 7.1.1 configuration scripts check to see if any back-level Message Broker data collector configuration information exists, and inform you that all back-level configuration information must be cleaned up before any new configuration information can be accepted.
Potential Upgrade and Uninstall Problem Scenarios
If you follow the documented procedures for upgrading to ITCAM for SOA 7.1.1, you disable all data collection (for all environments) before the upgrade, and enable data collection again after the upgrade. In this scenario, there should be no problems with the Message Broker environment, because all the "old" data collector configuration (user exit files, directories, etc.) should be cleaned up before the new configuration is created. But because it is easy to forget to do this, you might encounter problems in several scenarios. The following sections describe each of these scenarios and discuss how you can recover from an improper upgrade.
Upgrading from WMB 6.0 to WMB 6.1 without Disabling and then Enabling WMB Data Collection
If you upgrade your WebSphere Message Broker 6.0 environment to 6.1 without disabling all Message Broker data collection before the upgrade and enable it again after the upgrade, the resulting environment will consist of brokers running at the WMB 6.1 level, but with ITCAM for SOA user exit (LEL) files that might still be at the WMB 6.0 level. (Note that even though the default bit-mode for WMB 6.1 execution groups is 64bit on most platforms, Message Broker will not convert any existing 32bit execution groups to 64bit execution groups during this upgrade process.) If you have ITCAM for SOA 6.1.1 or 7.1 installed, this configuration is perfectly fine, because these versions of ITCAM for SOA had only one level of the user exit (LEL) file. But if you have ITCAM for SOA 7.1.1 installed, you might be using a back-level (WMB 6.0) user exit (LEL) file. Though this is a supported configuration, you are not taking advantage of the WMB 6.1 support that was added to the user exit in ITCAM for SOA 7.1.1.
ITCAM for SOA 7.1.1 always sets up Message Broker data collection for both WMB 6.0 and WMB 6.1 environments when the first flow is enabled. The KD4setupSOAUserExitPath script created in the common/profiles directory is designed to detect the version of WMB and add the appropriate runtime library directories to the user exit path environment variables, and the user exit (LEL) files for both WMB 6.0 and WMB 6.1 are copied to their respective runtime library directories. To ensure all WMB 6.1 brokers are using the new WMB 6.1 level of the ITCAM for SOA 7.1.1 user exit (LEL) file, you should stop each broker and restart it from a freshly opened WMB 6.1 command console.
Opening a new WMB 6.1 command console will rerun the scripts in the common/profiles directory, including the KD4setupSOAUserExitPath script. This script detects that the environment is now WMB 6.1, and add the KD4/config/wmb61/lib directory to the user exit path environment variables, instead of the KD4/config/wmb/lib directory used for WMB 6.0. Restarting the brokers from this command console ensures that the execution groups pick up the correct level of the ITCAM for SOA 7.1.1 user exit (LEL) file.
Upgrading from ITCAM for SOA 6.1.1 or 7.1 to ITCAM for SOA 7.1.1 without Disabling and then Enabling WMB Data Collection
If you upgrade ITCAM for SOA 6.1.1 or 7.1 to 7.1.1 on a system where WebSphere Message Broker is being monitored without disabling all Message Broker data collection before the upgrade and enabling it again after the upgrade, the resulting environment will consist of brokers running with the old level of the ITCAM for SOA user exit (LEL) file, which were loaded from the old (per-broker) runtime library directories, because the user exit path is still defined using the mqsichangebroker command. If you try to use the ITCAM for SOA 7.1.1 tools (KD4configDC or ConfigDC) to enable or disable Message Broker data collection while in this configuration, the tools report an error indicating that back-level Message Broker configuration must be disabled first, and will advise you that KD4disableMBDC-71 script should be used to disable the back-level configuration data.
The KD4disableMBDC-71 script recognizes the LEL filename, directory structure and user exit path extensions employed in ITCAM for SOA 6.1.1 and 7.1. If you have migrated to ITCAM for SOA 7.1.1 without first disabling all Message Broker data collection, you can use this script to disable the data collection and clean up all the old LEL files, directories and user exit path definitions. The syntax of the KD4disableMBDC-71 script is the same as the KD4configDC script, except that it only allows "-disable" (not "-enable") and only for "-env 10" (WebSphere Message Broker). Use this script to disable data collection for all Message Broker flows, to insure all back-level configuration information is cleaned up. From this point on, you should not need to use the KD4disableMBDC-71 script anymore.
Note: One way to determine whether ITCAM for SOA will detect outstanding message flows that are enabled for data collection is to look under the KD4/config/wmb/config directory for any files with a .runflow extension. These files are created to help ITCAM for SOA keep track of which flows are enabled for data collection (that is, which files have the MqsiSOAExit added to their active user exit list). For ITCAM for SOA 6.1.1 and 7.1, these runflow files are normally found under a broker-specific subdirectory (for example, KD4/config/wmb/config/<broker>), and the name of these runflow files are in the form <broker>.<exec-group>.<msg-flow>.runflow. If any runflow files exist, you should be able to determine the broker, execution group and message flow name of the enabled flow.
Once data collection for all the Message Broker flows is disabled, the KD4configDC or ConfigDC tools can be used to enable and disable data collection. These tools should be used to enable data collection for all the Message Broker flows that were disabled with the KD4disableMBDC-71 script, to ensure the previous level of monitoring is re-established, but at the updated level of the ITCAM for SOA 7.1.1 user exit (LEL) file. If the KD4configDC or ConfigDC tools still report that back-level configuration information exists, refer to the Manually Cleaning up Back-Level Configuration Information section below.
Manually Cleaning up Back-Level Configuration Information
If after disabling all data collection for Message Broker flows using the KDdisableMBDC-71 script, the KD4configDC or ConfigDC tools still report that back-level configuration data exists, you can manually remove the back-level configuration information.
Verify that there are no *.runflow files under the KD4/config/wmb/config directory. Normally, these files are found under one or more broker-specific directories (e.g. KD4/config/wmb/config/<broker>). If you find any of these files, check again to be sure that all data collection for the message flows on the <broker> has been disabled. (The name of these runflow files are in the form <broker>.<exec-group>.<msg-flow>.runflow. So if any runflow files exist, it should be fairly easy to determine the broker, execution group and message flow name of the enabled flow.) If you are sure that all data collection has been disabled for all flows, you should delete any remaining *.runflow files.
Verify that there are no files named mqsisoauserexit.lel anywhere under the KD4/config/wmb/lib directory. Normally this file is found under one or more broker-specific directories (e.g. KD4/config/wmb/lib/<broker>). If you find any of these files, check again to be sure that all data collection for the message flows on the <broker> has been disabled, and then delete the mqsisoauserexit.lel file along with the <broker> directory it was in.
Verify that there are no UserExitPath entries in the WMB registry that still contain an ITCAM for SOA runtime library directory (e.g. KD4/config/wmb/lib/<broker>) in the path:
On Windows Platforms: WMB uses the Windows registry. Open the Windows registry editor (regedit.exe) and search for keys named UserExitPath. Examine the value of these keys to see if there is an ITCAM for SOA runtime library directory in the path string. If there is, edit the value of the UserExitPath key and remove the ITCAM for SOA runtime library directory from the path string, being careful not to alter any other entries on the path string.
On Unix Platforms: WMB uses a registry directory under the MQSI_WORKPATH directory (normally /var/mqsi/registry). Search under this directory for any files named UserExitPath. Examine the contents of these files to see if there is an ITCAM for SOA runtime library directory in the path string. If there is, edit the UserExitPath file and remove the ITCAM for SOA runtime library directory from the path string, being careful not to alter any other entries on the path string.
Uninstalling ITCAM for SOA 6.1.1 or 7.1 without Disabling WMB Data Collection
If you uninstall ITCAM for SOA 6.1.1 or 7.1 without first disabling data collection for all Message Broker flows, any flows enabled for data collection might not be started when the broker is restarted. Specifically, if the mqsisoauserexit.lel file is deleted from the runtime library directory that is in the broker's user exit path (e.g. KD4/config/wmb/lib/<broker.), it will not be loaded when the broker is restarted. And since the MqsiSOAExit that is registered by this user exit file will not exist, any message flows with MqsiSOAExit in their active user exit list will not be started.
On WMB 6.0, when a flow is in this state (deployed, but missing one or more user exits from its active user exist list), the flow is not seen when the mqsilist command is issued, and the flow's user exits cannot be queried or changed using the mqsireportflowuserexits or mqsichangeflowuserexits commands. These commands act as though the flow does not exist, as long as one or more of the exits in the active user exit list are missing. However, WMB 6.1 will allow these commands to be issued against flows that are in this state, which makes the recovery of the flow a little simpler for WMB 6.1 than for WMB 6.0. (Note that the recovery process for WMB 6.0 will also work for WMB 6.1.)
In WMB 6.0 environments, perform the following steps to recover the message flow from this state:
- Reinstall the ITCAM for SOA 6.1.1 or 7.1 TEMA (agent) on the machine
- Create the directory <soa-install>/KD4/config/wmb/lib/<broker> (where <broker> is the broker of the execution group to which the flow is deployed)
- Copy the <soa-install>/KD4/lib/mqsisoauserexit.lel file to the <soa-install>/KD4/config/wmb/lib/<broker> directory
- Make sure the <soa-install>/KD4/config/wmb/lib/<broker> directory is in the UserExitPath for the <broker>. (Refer to the section User Exit Path Extensions under WebSphere Message Broker Changes from 6.0 to 6.1 above for information on how to locate the UserExitPath for a broker.) If this directory is not in the path, either modify the UserExitPath manually to add this directory or use this command to change the path:
mqsichangebroker <broker> -x <new-exit-path>
where <new-exit-path> is the concatenation of the current user exit path and this directory (with the appropriate separator character).
- Restart the broker to pick up the new UserExitPath setting
- Check to see if the <broker>.<execGroup>.<msgFlow>.runflow file exists in the <soa-install>/KD4/config/wmb/config/<broker> directory. If it does not exist, issue the KD4configDC script to enable the flow. (This command will result in a message saying the flow is already enabled and will give RC=197, but it will recreate the .runflow file.)
- At this point, you should be able to issue the KD4configDC script to disable data collection for the message flow, which will remove the MqsiSOAExit from the flow's active user exit list.
In WMB 6.1 environments, you can use the same technique described above for WMB 6.0 to recover the flow. But a simpler way to recover the flow is as follows:
- Issue this command to insure the message flow to be recovered is visible to the broker/execution group:
mqsilist <broker> -e <execGroup>
If the flow is not visible, you should stop here and perform the steps described above for WMB 6.0.
- Issue this command to view the current active user exit list for the flow:
mqsireportflowuserexits <broker> -e <execGroup> -f <msgFlow>
The first time you issue this command, you might see a very detailed error message. Try issuing the command a second time. If the command fails again with an error, you should stop here and perform the steps described above for WMB 6.0.
- If the above command succeeds, it might show you the list of active user exits that are configured for the message flow. If the active user exit list is not shown, and you are not sure whether any other user exits are configured for the message flow, you should stop here and perform the steps described above for WMB 6.0.
- If the active user exit list is shown, or if it is not shown but you know what other user exits (if any) are defined for the flow, you can issue the following command to change the user exit list and remove the MqsiSOAExit from the list:
mqsichangeflowuserexits <broker> -e <execGroup> -f <msgFlow> -a <new-user-exit-list>
where <new-user-exit-list> is the current list of user exits, but WITHOUT the MqsiSOAExit included.
- Restart the broker. The message flow should be loaded and started, since the missing MqsiSOAExit is no longer in the flow's active user exit list.
After you have recovered all the message flows by removing the MqsiSOAExit from their active user exit list, you should remove the ITCAM for SOA runtime library directory from the UserExitPath for the broker, as described in the Manually Cleaning up Back-Level Configuration Information section above.
When data collection for all message broker flows is disabled, you can uninstall the ITCAM for SOA TEMA (agent) code again.
Uninstalling ITCAM for SOA 7.1.1 without Disabling WMB Data Collection
If you uninstall ITCAM for SOA 7.1.1 without disabling data collection for all Message Broker flows, any flows enabled for data collection might not be started when the broker is restarted. Specifically, if the mqsisoauserexit_wmbXX_YYbit.lel files are deleted from the runtime library directory that is in the broker's user exit path (e.g. KD4/config/wmb/lib or KD4/config/wmb61/lib), it will not be loaded when the broker is restarted. And since the MqsiSOAExit that is registered by this user exit file will not exist, any message flows with MqsiSOAExit in their active user exit list will not be started.
On WMB 6.0, when a flow is in this state (deployed, but missing one or more user exits from its active user exist list), the flow is not seen when the mqsilist command is issued, and the flow's user exits cannot be queried or changed using the mqsireportflowuserexits or mqsichangeflowuserexits commands. These commands act as though the flow does not exist, as long as one or more of the exits in the active user exit list are missing. However, WMB 6.1 will allow these commands to be issued against flows that are in this state, which makes the recovery of the flow a little simpler for WMB 6.1 than for WMB 6.0. (Note that the recovery process for WMB 6.0 will also work for WMB 6.1.)
In WMB 6.0 environments, perform the following steps to recover the message flow from this state:
- Reinstall the ITCAM for SOA 7.1.1 TEMA (agent) on the machine
- Create the directories <soa-install>/KD4/config/wmb/lib and <soa-install>/KD4/config/wmb61/lib
- Copy the <soa-install>/KD4/lib/mqsisoauserexit_wmb60*.lel files to the <soa-install>/KD4/config/wmb/lib directory
- Copy the <soa-install>/KD4/lib/mqsisoauserexit_wmb61*.lel files to the <soa-install>/KD4/config/wmb61/lib directory.
- Open a WMB command console window and make sure the <soa-install>/KD4/config/wmb/lib directory (for WMB6.0) or the <soa-install>/KD4/config/wmb61/lib directory (for WMB6.1) is in the MQSI_USER_EXIT_PATH and MQSI_USER_EXIT_PATH64 environment variables. If the directory is not in these environment variables, you should:
- Create a KD4setupSOAUserExitPath script (.bat or .cmd) in the $MQSI_WORKPATH/common/profiles directory that looks like this (make sure the ITCAM for SOA path is correct for the target <platform>):
KD4setupSOAUserExitPath.sh
#!/usr/bin/sh
# Extend the user exit path with the ITCAM for SOA library directories
# that are appropriate for each version of WebSphere Message Broker.
if [ "$MQSI_VERSION_R" = "0" ]
then
export MQSI_USER_EXIT_PATH64=$MQSI_USER_EXIT_PATH64:/opt/IBM/ITM/<platform>/d4/KD4/config/wmb/lib:
export MQSI_USER_EXIT_PATH=$MQSI_USER_EXIT_PATH:/opt/IBM/ITM/<platform>/d4/KD4/config/wmb/lib:
else
export MQSI_USER_EXIT_PATH64=$MQSI_USER_EXIT_PATH64:/opt/IBM/ITM/<platform>/d4/KD4/config/wmb61/lib:
export MQSI_USER_EXIT_PATH=$MQSI_USER_EXIT_PATH:/opt/IBM/ITM/<platform>/d4/KD4/config/wmb61/lib:
fi KD4setupSOAUserExitPath.cmd
@REM Extend the user exit path with the ITCAM for SOA library directories
@REM that are appropriate for each version of WebSphere Message Broker.
if "%MQSI_VERSION_R%"=="0" (
set MQSI_USER_EXIT_PATH64=%MQSI_USER_EXIT_PATH64%;C:\IBM\ITM\TMAITM6\KD4\config\wmb\lib;
set MQSI_USER_EXIT_PATH=%MQSI_USER_EXIT_PATH%;C:\IBM\ITM\TMAITM6\KD4\config\wmb\lib;
) else (
set MQSI_USER_EXIT_PATH64=%MQSI_USER_EXIT_PATH64%;C:\IBM\ITM\TMAITM6\KD4\config\wmb61\lib;
set MQSI_USER_EXIT_PATH=%MQSI_USER_EXIT_PATH%;C:\IBM\ITM\TMAITM6\KD4\config\wmb61\lib;
)
- Open a new WMB command console window and check the environment variables again. Use this new command window for the remaining steps.
- Restart the broker to pick up the new MQSI_USER_EXIT_PATH and MQSI_USER_EXIT_PATH64 settings.
- Check to see if the <broker>.<execGroup>.<msgFlow>.runflow file exists in the <soa-install>/KD4/config/wmb/config directory. If it does not exist, issue the KD4configDC script to enable the flow. (This command will result in a message saying the flow is already enabled and will give RC=197, but it will recreate the .runflow file.)
- At this point, you should be able to issue the KD4configDC script to disable data collection for the message flow, which will remove the MqsiSOAExit from the flow's active user exit list.
In WMB 6.1 environments, you can use the same technique described above for WMB 6.0 to recover the flow. But a simpler way to recover the flow is as follows:
- Issue the following command to ensure the message flow to be recovered is visible to the broker/execution group:
mqsilist <broker> -e <execGroup>
If the flow is not visible, you should stop here and perform the steps described above for WMB 6.0.
- Issue the following command to view the current active user exit list for the flow:
mqsireportflowuserexits <broker> -e <execGroup> -f <msgFlow>
The first time you issue this command, you might see a very detailed error message. Try issuing the command a second time. If the command fails again with an error, you should stop here and perform the steps described above for WMB 6.0.
- If the above command succeeds, it might show you the list of active user exits that are configured for the message flow. If the active user exit list is not shown, and you are not sure whether any other user exits are configured for the message flow, you should stop here and perform the steps described above for WMB 6.0.
- If the active user exit list is shown, or if it is not shown but you know what other user exits (if any) are defined for the flow, you can issue the following command to change the user exit list and remove the MqsiSOAExit from the list:
mqsichangeflowuserexits <broker> -e <execGroup> -f <msgFlow> -a <new-user-exit-list>
where <new-user-exit-list> is the current list of user exits, but WITHOUT the MqsiSOAExit included.
- Restart the broker. The message flow should be loaded and started, since the missing MqsiSOAExit is no longer in the flow's active user exit list.
After you have recovered all the message flows by removing the MqsiSOAExit from their active user exit list, you should delete the KD4setupSOAUserExitPath script (.bat or .cmd) file from the $MQSI_WORKPATH/common/profiles directory, so that the ITCAM for SOA runtime library directory is removed from the MQSI_USER_EXIT_PATH and MQSI_USER_EXIT_PATH64 environment variables.
When data collection for all message broker flows is disabled, you can uninstall the ITCAM for SOA TEMA (agent) code again. | | | | | | | | Product Alias/Synonym | | ITCAMfSOA | | |
| | |
|
|
| IBM, the IBM logo and ibm.com are trademarks of International Business Machines Corp., registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at "Copyright and trademark information" at www.ibm.com/legal/copytrade.shtml. |
|
|
|
|
| Please take a moment to complete this form to help us better serve you. |
|
 |
|
|
|
|
|
|
| Product categories: |
|
| | Software | |
| | Systems and Asset Management | |
| | Application Performance & Availability | |
| | IBM Tivoli Composite Application Manager for SOA | |
| | ITCAM for SOA (Dist) | |
|
| Operating system(s): |
| |
AIX, HP-UX, Linux, Solaris, Windows, z/OS
|
|
| Software version: |
| |
6.1, 7.1, 7.1.1
|
|
| Reference #: |
| |
1308392
|
|
| IBM Group: |
| | Software Group |
|
| Modified date: |
| | 2009-06-17 |
|
|
