IBM WebSphere MQ Workflow

Migrating a WebSphere MQ Workflow 3.6 System Group on AIX, using DB2, from WebSphere MQ 5.3 to WebSphere MQ 6.0
January 22, 2008

IBM WebSphere MQ Workflow Competence Center SWSD Bblingen, Germany Address: Schnaicher Str. 220 D-71032 Bblingen, Germany

Contents
Contents......................................................................................................................................2 About this document...................................................................................................................3 Migration Roadmap....................................................................................................................4 Before you migrate......................................................................................................................5 Backup your MQ Workflow systems......................................................................................5 Collect authorization information...........................................................................................5 Consider the migration sequence for an MQ Workflow System Group ................................5 Think about third-party applications.......................................................................................6 Consider the significant changes.............................................................................................6 Read the WebSphere MQ migration information...................................................................6 Read the DB2 instance migration information.......................................................................6 Migrating an MQ Workflow server ...........................................................................................7 1.Install MQ Workflow 3.6 SP6 and the queue manager migration tool fmczqmig .............7 2.Stop MQ Workflow.............................................................................................................7 3.Update the DB2 instance to be a 64-bit instance.................................................................7 4.Migrate to WebSphere MQ 6.0............................................................................................8 5.Update the user environments..............................................................................................8 6.Create links for the DB2 libraries......................................................................................10 7.Remove links in /usr/lib.....................................................................................................10 8.Copy the channel table from earlier migrated systems......................................................11 9.Migrate the queue manager for MQ Workflow.................................................................11 10.Start the MQ Workflow system.......................................................................................12 10.1 Start the queue manager............................................................................................12 10.2 Start MQ Workflow .................................................................................................12 Migrating an MQ Workflow client ..........................................................................................13 Migrating a client with queue manager or client concentrator.............................................13 1.Install MQ Workflow 3.6 SP6.......................................................................................13 2.Stop all clients connecting to the queue manager..........................................................13 3.Migrate to WebSphere MQ 6.0......................................................................................13 4.Update the channel table ...............................................................................................14 5.Refresh the templates in the channel table.....................................................................14 6.Start the queue manager and clients...............................................................................14 Migrating a client that connects via the client channel table................................................15 Appendix...................................................................................................................................16 Appendix A. Updating the environment manually...............................................................16 Refreshing the templates in the channel table...................................................................16 Updating the qm.ini file....................................................................................................16 Running fmczinsx to create 64-bit switch file links.........................................................17 Appendix B. Errors and solutions.........................................................................................18 Appendix C. References.......................................................................................................21 Appendix D. Used product versions.....................................................................................21

About this document

This document is intended for WebSphere MQ Workflow 3.6 customers who want to migrate an MQ Workflow System Group that uses DB2 as database system, from WebSphere MQ Version 5.3 to WebSphere MQ Version 6.0 on the AIX platform. Starting with Version 6, WebSphere MQ introduced or removed some features that have an impact on an MQ Workflow installation: On AIX, the 32-bit distributions is dropped. The template objects in the channel table were updated.

If you perform the initial setup of MQ Workflow using WebSphere MQ 6.0, all the new features are configured correctly. However, if the initial setup was done using a WebSphere MQ 5.3 installation, the MQ Workflow setup utilities used the old procedures to setup the queue manager. If you migrate the queue manager to WebSphere MQ 6, staring MQ Workflow will typically fail. This document provides a step-by-step description on how to successfully migrate the queue manager for any MQ Workflow installation.

Migration Roadmap
To migrate an MQ Workflow System Group you must migrate the queue manager on each MQ Workflow system. The following sequence is recommended: 1. Start by migrating MQ Workflows "First" system in the System Group. 2. Migrate any additional MQ Workflow systems where the queue manager holds a full repository. 3. Migrate all other MQ Workflow systems. 4. Migrate any client installations. To migrate an MQ Workflow system to WebSphere MQ 6.0 you must perform the following steps: 1. Bring the MQ Workflow installation to the latest service level. 2. Stop your MQ Workflow system group (all Workflow servers, queue managers, and the database). 3. Migrate to WebSphere MQ 6.0 4. Update the database environment to work with the new WebSphere MQ install. 5. Modify the WebSphere MQ environment to work with 64-bit databases. 6. Modify the MQ Workflow setup to deal with WebSphere MQ 6.0 and 64-bit databases. 7. Refresh the objects in the channel table. 8. Start your MQ Workflow system. 9. Verify the system.

Before you migrate

To prepare for migrating your setup, perform the steps described below for a seamless migration with the option to fall-back to a backup in case of any problems.

Backup your MQ Workflow systems

As a precaution against the migration failing, create a backup of your MQ Workflow system. The backup should include at least the following: MQ Workflow databases (Runtime or Buildtime). Queue managers. MQ Workflow configurations. Optionally the operating system itself.

See the product documentation for details on how to backup your system.

Collect authorization information

The most parts of the migration require administrator permission for the operating system. In detail, the following authorities are required: Operating system administrator to install the new WebSphere MQ packages. WebSphere MQ administrator to modify the queue manager settings. Database administrator to modify the database installation. WebSphere MQ Workflow administrator to update the MQ Workflow configuration.

Consider the migration sequence for an MQ Workflow System Group

When migrating a System Group, you must first migrate the queue managers that have a full repository. If you have multiple full repositories, start with the repository for your first MQ Workflow system. It is recommended to migrate the systems step-by-step instead of migrating them all at once. WebSphere MQ supports having a mixed cluster of version 5.3 and 6.0 queue managers, and for the MQ Workflow servers the version of WebSphere MQ being used is transparent. This helps to minimize the downtime of your System Group.

Think about third-party applications

During the migration, you must do significant changes to the items listed in Consider the significant changes below. These changes might break any third party applications that also use the queue manager, the database, or the workflow user ID. Before you migrate, ensure that your other applications will also work on this new setup.

Consider the significant changes

There are the significant changes to be done to the system. Check with your system administrators if and how these changes impact other parts of the system. The major changes are: Update the environment of the WebSphere MQ user (default mqm) that starts the queue manager to remove references to the 32-bit libraries in the library path. Remove links for 32-bit WebSphere MQ libraries from /usr/lib. Update the environment of the WebSphere MQ Workflow user (default fmc) that starts the Workflow servers to remove the 32-bit DB2 libraries in the library path. Change the word length used by the DB2 instance to 64 bits.

Read the WebSphere MQ migration information

Read the migration chapters in the MQ documentation before starting the migration. You can find information about migration in the following manuals: WebSphere MQ for AIX Quick Beginnings GC34-6478-01 WebSphere MQ for HP-UX Quick Beginnings GC34-6479-03 WebSphere MQ for Solaris Quick Beginnings GC34-6477-02 Migration Information Some issues affecting migration to IBM WebSphere MQ, Version 6.0 SC34-6604-01

Read the DB2 instance migration information

During the migration you might need to switch the DB2 instance to be a 64-bit instance. Detailed information about the possible impacts of doing this can be found in the following DB2 manual: Administration Guide: Implementation SC09-4820-01 Chapter 5. Altering a database, Altering an instance

Migrating an MQ Workflow server

This chapter contains a step-by-step description of how to migrate a single MQ Workflow system from WebSphere MQ 5.3 to WebSphere MQ 6.0. In a System Group with multiple systems, you must follow the instructions in this chapter once for each machine in the system group, with the following sequence: 1. Start with MQ Workflows "First" system of the System Group. 2. Migrate any additional MQ Workflow systems where the queue manager holds a full repository. 3. Migrate all other MQ Workflow systems in the system group.

1. Install MQ Workflow 3.6 SP6 and the queue manager migration tool fmczqmig
During this procedure you must use the tool fmczqmig to update several queue manager objects. This tool has been changed to allow you to update the migrated queue manager. The new version of fmczqmig is attached to the TechDoc and requires Service Pack 6. It will be part of later Service Packs. Therefore, if you have not already installed MQ Workflow Service Pack 6, you must install it as described in the product documentation, and then replace the file MQ Workflow installation dir/bin/fmczqmig with the version that is attached to this TechDoc. If you have already a later Service pack available, just install the service pack.

2. Stop MQ Workflow
Before you can migrate the queue manager, you must stop all running MQ Workflow processes on the machine to ensure that there are no connections on the queue manager. To do this 1. Stop all MQ Workflow servers using the administration utility fmcautil. 2. Make sure that there are no processes left. To do this, enter the command:
ps -ef | grep fmc

3. Make sure that there are no process communications left. Enter the command: ipcs | grep fmc. Cleanup any leftovers using ipcrm. (requires root authority). 4. On AIX, run slibclean as root user to unload the MQ Workflow libraries from the cache.

3. Update the DB2 instance to be a 64-bit instance

After the queue manager is migrated, it can no longer deal with a 32-bit DB2 instance. Thus, you first need to change your DB2 instance serving the MQ Workflow database to be a 64-bit instance. In a setup with a remote database, the client instance that MQ Workflow connects to must be a 64-bit instance. Follow the steps below to change your instance to a 64-bit instance: 7

1. If the instance to be migrated holds any databases, perform a backup. 2. Log on with the instance user ID (e.g. db2inst1) 3. Stop the instance using the db2stop command to ensure that all applications are disconnected. 4. Log on as root user 5. change to db2_install_dir/instance, e.g. on AIX to
/usr/opt/db2_08_01/instance

6. Run db2iupdt to change the instance to 64-bits. For example, enter: and db2fenc1 is the fenced user ID for this instance. Refer to the DB2 product manuals for details about db2iupdt. 7. Again, log on as the instance user and verify the change with the db2level command. 8. Start the instance using the db2start command.
db2iupdt -w 64 -u db2fenc1 db2inst1 where db2inst1 is the name of the instance

4. Migrate to WebSphere MQ 6.0

Migrate the WebSphere MQ installation as described in the WebSphere MQ documentation. Also install the latest WebSphere MQ fix packs. After you completed the installation, do not start the queue manager even if the manual tells you to do so. Note: If you do not perform all the tasks in this document before you start the queue manager directly after migration, it might fail. Only restart the queue manager when this document explicitly instructs you to start the queue. For the normal WebSphere MQ migration, refer to the following manuals: WebSphere MQ Migration Information Some issues affecting migration to IBM WebSphere MQ, Version 6.0 SC34-6604-01, Oct. 2005 WebSphere MQ for AIX Quick Beginnings GC34-6478-01 WebSphere MQ for HP-UX Quick Beginnings GC34-6479-03 WebSphere MQ for Solaris Quick Beginnings GC34-6477-02

5. Update the user environments

After you have migrated the DB2 instance to 64-bits, you must change the environment settings for: The user ID that starts the queue manager. The user ID that starts the MQ workflow server fmcamain.

WebSphere MQ runs in 64-bit mode, it also uses the 64-bit DB2 API. However, because MQ Workflow runs in 32-bit mode, it needs the 32-bit DB2 API. 8

Both MQ Workflow and WebSphere MQ can load the correct DB2 API libraries using the built-in paths. However, the library loader searches the libraries in the following order: 1. All directories listed in the LIBPATH environment variable. 2. All directories listed in the LD_LIBRARY_PATH environment variable. 3. All directories listed in the built-in search path of the module. Because of this, to allow the loader to find the DB2 API libraries using built-in search path, the LIBPATH and LD_LIBRARY_PATH must not contain any DB2 libraries. Since both MQ Workflow and WebSphere MQ deal with DB2, the user that starts them must have a call to the db2profile shell script in her .profile (or somewhere else during the environment setup). The db2profile shell script sets the library path to contain the 32-bit DB2 libraries, even your instance is now a 64-bit instance. Because of the 32-bit DB2 libraries, the startup of the queue manager will fail loading the correct (64-bit) DB2 libraries. The MQ Workflow servers need the 32-bit DB2 libraries. The DB2 libraries however reload 64-bit libraries since the DB2 instance is a 64 bit instance. If the LIBPATH is set, there is a mixture of 32 and 64-bit libraries, and the loading fails. To overcome this, you must undo the settings for the LIBPATH done by the db2profile script. Below is an example how to do it. Do this twice if the starter of the queue manager is not also the starter of the MQ Workflow servers. If the solution given below does not fit your needs, read the section Implications of a 64-bit queue manager" in the WebSphere MQ Quick Beginnings book. Modify the .profile as follows: 1. 2. 3. 4. Log on as the user who starts the queue manager or the MQ Workflow server. Open the logon profile (for example .profile) in any editor. Locate the line where db2profile is called. Before this line, depending on your platform, save the values of the following environment variables in other variables: On AIX: LIBPATH and LD_LIBRARY_PATH On HP_UX: SHLIB_PATH On Solaris: LD_LIBRARY_PATH 5. After the line containing the call to db2profile, restore the saved variables. Example of a modified profile (AIX):
if [ -s "$MAIL" ] then echo "$MAILMSG" fi # This is at Shell startup. In normal # operation, the Shell checks # periodically.

# Save the LIBPATHs to avoid a mixture of 32 and 64 libraries for # the MQ Workflow libs SAVE_LIBPATH=$LIBPATH SAVE_LD_LIBRARY_PATH=$LD_LIBRARY_PATH

. /home/db2inst1/sqllib/db2profile # undo the modifications db2profile did to the LIBPATHs LIBPATH=$SAVE_LIBPATH LD_LIBRARY_PATH=$SAVE_LD_LIBRARY_PATH To completely remove a LIBPATH value you can also use the unset command. For example, on AIX enter: unset LIBPATH unset LD_LIBRARY_PATH

After your changes to the environment, ensure that the changes get activated by closing and reopening all command line sessions.

6. Create links for the DB2 libraries

As described in Update the user environments, to ensure the correct loading of the 32- and 64-bit libraries, the built-in paths are used. If your DB2 is not installed in the default location /usr/opt/db2_08_01 or /opt/IBM/db2/V9.1, you must provide additional links for MQ Workflow. All MQ Workflow libraries have /usr/lpp/fmc/lib/workflow in the built-in path to allow this. The 64-bit switch file has /usr/lpp/fmc/lib/workflow64 instead in its built-in path. Thus, to enable the MQ Workflow binaries to find the correct DB2 libraries: 1. Log on with a user ID that has permissions to create directories and links in the MQ Workflow installation directory. 2. Change to the MQ Workflow installation directory/lib directory. 3. Create the directory workflow for the 32-bit libraries by entering
mkdir workflow.

4. Create the directory workflow64 for the 64-bit libraries by entering

mkdir workflow64.

5. Set the correct permissions for the newly created directories by entering
chmod 755 workflow workflow64.

6. Create links for the 32-bit DB2 libraries in the workflow directory by entering

7.

ln -s DB2 installation directory/lib_dir/* ./workflow where DB2 installation directory is the directory where the DB2 product is installed and lib_dir is the directory of the 32-bit DB2 libraries. When using DB2 v8, use lib as lib_dir, when using DB2 v9, use lib32. Create links for the 64-bit DB2 libraries in the workflow directory by entering ln -s DB2 installation directory/lib64/* ./workflow where DB2 installation directory is the directory where the DB2 product is

installed.

7. Remove links in /usr/lib

If you need to include /usr/lib in your LIBPATH, then to avoid errors running 64-bit WebSphere MQ applications or WebSphere MQ commands, consider removing the symbolic links from /usr/lib to the 32-bit WebSphere MQ libraries using the dltmqlnk command .

8. Copy the channel table from earlier migrated systems

If you are migrating an additional MQ Workflow system in your System Group, and your clients connect using a WebSphere MQ client channel table, copy the channel table from the already migrated queue manager to the system you are currently migrating. If you have multiple systems, copy the channel table from the last migrated system. This ensures that all objects for all MQ Workflow servers in the channel tables are refreshed. After all systems are migrated, distribute the updated channel table to the clients.

9. Migrate the queue manager for MQ Workflow

To migrate the WebSphere MQ workflow settings for the queue manager, you can invoke the MQ Workflow queue manager migration utility fmczqmig. fmczqmig was enhanced to support the WebSphere MQ 5.3 to 6.0 migration in several ways. When invoked, fmczqmig performs the following: Checks the availability of the different WebSphere MQ exit paths under /var/mqm and creates them if necessary. Reruns fmczinsx to create new links for the 64-bit switch files within
/var/mqm/exits64

Updates the qm.ini file to refer to the exit path for 64-bit libraries (key ExitsDefaultPath64) Updates the qm.ini to contain a relative path to the MQ Workflow switch file instead of a fully qualified path. Refreshes the server channel table (using strmqm -c). Recreates all MQ Workflow objects on the queue manager using the replace option. Note: This will overwrite any modifications to the MQ Workflow objects you did after the initial MQ Workflow configuration.

Because these changes modify system resources, root authority is required. Note: If your security guidelines do not allow a tool to make such changes to your system, you can do them manually as described in Appendix A. Updating the environment manually. To indicate that fmczqmig should migrate the queue manager for a configuration from WebSphere MQ 5.3 to 6.0, you must specify the newly added command line flag -q. fmczqmig can update all configurations that have an associated queue manager (i.e. MQ Workflow server and client configurations). 10. To migrate all queue managers for all MQ Workflow configurations, issue the command below. fmczqmig iterates then through all MQ Workflow configurations and migrates all associated queue managers. As root user, enter
fmczqmig -q

11. To migrate only the queue manager of a specific MQ Workflow configuration, issue the following command while logged on as root user:
fmczqmig -q -y config_id

where config_id is the ID of the MQ Workflow configuration that owns the queue manager.
fmczqmig

logs messages and informations in the following folders and files:

12. General information is stored in the general log file fmczkcfg.log, located in configuration root directory/log, where configuration root directory is typically /var/fmc. 13. While updating a specific configuration, the information is written into the different log files of the configuration, located in configuration root directory/config_id/log, where configuration root directory is the directory where the MQ Workflow configurations are stored and config_id is the name of the updated MQ Workflow configuration.

10.Start the MQ Workflow system

After fmczqmig completed successfully, the migration of the MQ Workflow system is complete. You can now start the system again:

10.1 Start the queue manager

To be able to find any errors quickly, clean up the error log files for your queue manager, located under qmgr_home/errors, where qmgr_home is the location of the queue manager files, typically /var/mqm/qmgrs/qmgrname. If you want to keep the old log files, copy them to a different directory. Then delete all files in the errors directory. Now start the queue manager using the strmqm command for your queue manager. After the queue manager has started, check the error log files of the queue manager for any errors. You must resolve any errors, before you can start the MQ Workflow server. If you see any errors, use Appendix B. Errors and solutions to resolve them. Also the WebSphere MQ documentation might be helpful. If no errors are logged, start the trigger monitor for the queue manager using
runmqtrm -m qmgrname -q FMCTRIGGER &

Then proceed with starting the MQ Workflow server.

10.2 Start MQ Workflow

For information about how to start and verify the MQ Workflow system refer to the IBM WebSphere MQ Workflow Installation Guide, Chapter 8. Installing and configuring an MQ Workflow server on UNIX, Verifying the MQ Workflow server on UNIX.

Migrating an MQ Workflow client

If your System Group contains any MQ Workflow client concentrator or Client with Queue Manager setups, for each of these clients, perform the steps described in Migrating a client with queue manager or client concentrator. If your System Group has MQ Workflow clients that use a client channel table to connect to the MQ Workflow servers, for each of these clients, perform the steps described in Migrating a client that connects via the client channel table.

Migrating a client with queue manager or client concentrator

1. Install MQ Workflow 3.6 SP6
Even though it is not required to install the MQ Workflow Service Pack 6 before migrating a client queue manager, it is recommended to do so.

2. Stop all clients connecting to the queue manager

Before you can migrate the client queue manager to WebSphere MQ 6.0, stop all running MQ Workflow clients that connect to the queue manager.

3. Migrate to WebSphere MQ 6.0

Migrate the WebSphere MQ installation as described in the WebSphere MQ documentation. Install the latest WebSphere MQ fix packs. For the normal WebSphere MQ migration, refer to the following manuals: WebSphere MQ Migration Information Some issues affecting migration to IBM WebSphere MQ, Version 6.0 SC34-6604-01, Oct. 2005 WebSphere MQ for AIX Quick Beginnings GC34-6478-01 WebSphere MQ for HP-UX Quick Beginnings GC34-6479-03 WebSphere MQ for Solaris Quick Beginnings GC34-6477-02

4. Update the channel table

In a setup where the client channel table accessed by the clients contains information about one or more MQ Workflow server queue managers, copy the updated server channel table to the clients. Even though this is not mandatory, it is recommended because the updated channel table contains the new templates.

5. Refresh the templates in the channel table

In a client concentrator setup where the client channel table accessed by the clients only contains information about the client concentrator queue manager (and not the MQ Workflow server queue managers), update the channel table to contain the new templates. To do this, 1. Check the location of the channel table for your MQ Workflow client. This is the file named in the key FMLClientChannelTable of your Workflow configuration (file fmcrc). 2. Log on as a WebSphere MQ administrator, for example mqm. 3. Set the environment variables MQCHLTAB and MQCHLLIB to point to your channel table. For example, if your channel table file is /var/fmc/chltabs/MQWFCHL.TAB, issue the following commands:
export MQCHLTAB=MQWFCHL.TAB export MQCHLLIB=/var/fmc/chltabs

4. Recreate the templates using the strmqm -c command. For example, enter
strmqm -c qmgrName where qmgrName is the

name of your queue manager.

6. Start the queue manager and clients

To be able to find any errors quickly, clean up the error log files for your queue manager, located under qmgr_home/errors, where qmgr_home is the location of the queue manager files, typically /var/mqm/qmgrs/qmgrname. If you want to keep the old log files, copy them to a different directory. Then delete all files in the errors directory. Now start the queue manager using the strmqm command for your queue manager. After the queue manager has started, check the error log files for the queue manager for any errors. You must resolve any errors, before you can start the MQ Workflow server. If you see any errors, use Appendix B. Errors and solutions to resolve them. Also the WebSphere MQ documentation might be helpful. If no errors logged, start the clients. When all clients have been started successfully, the migration of the client queue manager is complete.

Migrating a client that connects via the client channel table

How to migrate an MQ Workflow client that connects via a client channel table is completely covered by the normal WebSphere MQ migration description. The only thing while migrating an MQ Workflow client from WebSphere MQ 5.3 to 6.0 is to think about the updated channel tables on the queue manager. It is recommended to replace the client channel table accessed by the clients with the updated channel table from the migrated queue managers. This is to get the new templates in the channel table which prevents errors during further configuration actions on the table. For more information refer to Migrating an MQ Workflow client, Refresh the templates in the channel table and Update the channel table.

Appendix
Appendix A. Updating the environment manually
If you don't want the fmczqmig utility to modify your system, you can make the modifications manually as described in this appendix.

Refreshing the templates in the channel table

There are some changes in the templates of the WebSphere MQ channel table from WebSphere MQ 5.3 to 6.0. You must refresh the channel table to allow the MQ Workflow utilities to update the channels. To do this: 1. Check the location of the channel table for your MQ Workflow server. This is the file named in the key FMLServerChannelTable of your Workflow configuration (file fmcrc) 2. Log on as an WebSphere MQ administrator, for example mqm 3. Set the environment variables MQCHLTAB and MQCHLLIB to point to your channel table. For example, if your channel table file is /var/fmc/chltabs/MQWFCHL.TAB, issue the following commands:
export MQCHLTAB=MQWFCHL.TAB export MQCHLLIB=/var/fmc/chltabs

4. Recreate the templates using the strmqm c command:

strmqm -c qmgrName where qmgrName is the

name of your queue manager

Updating the qm.ini file

The qm.ini must be changed to allow WebSphere MQ to work with 64-bit switch file as follows: Create an entry "ExitsDefaultPath64" in the section ExitPath The specified path must be /var/mqm/exits64. After updating the section, is should read as follows:
ExitPath: ExitsDefaultPath=/var/mqm/exits/ ExitsDefaultPath64=/var/mqm/exits64/

Make the path to the switch file to be a relative path The MQ Workflow utilities configure WebSphere MQ 5.3 queue managers with absolute paths. Because you migrated to WebSphere MQ 6.0, the switch file is resolved using the ExitPath section. To change the path, locate the key SwitchFile in the XAResourceManager section for your runtime database, then cut off any paths except for the file name. After updating the section, is should read as follows:
XAResourceManager: Name=db2inst1 FMCDB SwitchFile=db2swit XAOpenString=DB=FMCDB, toc=t, UID=db2inst1, PWD=***** ThreadOfControl=THREAD

Running fmczinsx to create 64-bit switch file links

While installing MQ Workflow, fmczinsx was run to create links for the correct database switch file. Due to the change to 64-bits, you need to rerun fmczinsx as root user. Depending on your database type, invoke one of the following commands:
fmczinsx -o db2 fmczinsx -o oracle9 or fmczinsx -o oracle10

This creates an additional link in /var/mqm/exits64 to the MQ Workflow 64-bit switch file.

Appendix B. Errors and solutions

This appendix contains a collection of errors that occurred while writing this document and their possible causes and solutions. -------------------------Error: When using command strmqm to start the queue manager, you see:
exec(): 0509-036 Cannot load program strmqm because of the following errors: 0509-150 Dependent module /usr/lib/libmqmcs_r.a(shr.o) could not be loaded. 0509-103 The module has an invalid magic number.

Reason: The LIBPATH (or LD_LIBRARY_PATH / SHLIB_PATH) variable contains links to /usr/lib, and /usr/lib contains links to 32bit WebSphere MQ libraries. Display the LIBPATH to check this:
echo $LIBPATH /usr/lib:/lib:/home/db2inst1/sqllib/lib

Solution: Unset the LIBPATH (or LD_LIBRARY_PATH / SHLIB_PATH) variable or remove the links from /usr/lib using dltmqlnk. See Migrating an MQ Workflow server, Update the user environments and Remove links in /usr/lib for details. -------------------------Error: During startup of the queue manager, you see message AMQ7626, and the queue manager does not start. You see the following messages:
WebSphere MQ queue manager 'FMCQM' starting. AMQ7626: XA resource manager initialization failure. Refer to the error log for more information.

Reason: DB2 instance might be a 32-bit instance. To check this, log on as the instance user and issue "db2level". Solution: Change the DB2 instance to be a 64-bit instance as described in Migrating an MQ Workflow server, Update the DB2 instance to be a 64-bit instance. -------------------------Error: After starting the queue manager, you see message AMQ6175 in the queue manager log file but the queue manager started:
----- amqtrmca.c : 256 -------------------------------------------11/29/07 15:32:02 - Process(507992.1) User(mqm) Program(amqzxma0_nd) AMQ6175: The system could not dynamically load the shared library

'/usr/lpp/fmc/db2swit/db2swit'. The system returned error number '8' and error message '0509-022 Cannot load module usr/lpp/fmc/db2swit/db2swit. 0509-103 The module has an invalid magic number.' The queue manager will continue without this module.

Reason 1: There are no links to the MQ Workflow switch file in /var/mqm/exits64 Solution 1: Logged on as root, rerun fmczinsx -o db2 to create the links to the 64-bit switch files. See also Appendix A. Updating the environment manually, Running fmczinsx to create 64bit switch file links. Reason 2: In the qm.ini file of the queue manager, the reference to exits64 is missing. Solution 2: In the qm.ini file of the queue manager, add the line
ExitsDefaultPath64=/var/mqm/exits64/

to the section ExitPaths. See also Appendix A. Updating the environment manually, Updating the qm.ini file. Reason 3: In the qm.ini file of the queue manager, the MQ Workflow switch file is specified fully qualified instead of relative. Solution 3: In the qm.ini of the queue manager, locate the key SwitchFile in the XAResourceManager section for your runtime database, then cut off any paths except for the file name. See Appendix A. Updating the environment manually, Updating the qm.ini file for details. -------------------------Error: During startup of the MQ Workflow server fmcamain, you see an exec() error:

fmcamain -y FMC & exec(): 0509-036 Cannot load program fmcamain because of the following errors: 0509-022 Cannot load module /home/db2inst1/sqllib/lib/libdb2.a(shr.o). 0509-150 Dependent module /home/db2inst1/sqllib/lib/libdb2trcapi.a(shr.o) could not be loaded. 0509-152 Member [1] 479332

Reason : There are 32-bit libs in LIBPATH/LD_LIBRARY_PATH/SHLIB_PATH. Solution : Unset the LIBPATH (or LD_LIBRARY_PATH / SHLIB_PATH) variable or remove the links from /usr/lib using dltmqlnk. See Migrating an MQ Workflow server, Update the user environments and Remove links in /usr/lib for details. --------------------------

Error: During the update of a queue manager or when creating a new one, you see the following error in the MQ Workflow configuration log files:
DEFINE CHANNEL('FMCQM3.CL.TCP') CHLTYPE(CLNTCONN) CONNAME('tambo7(14005)') AMQ8147: WebSphere MQ object not found.

Reason: There are some changes in the templates of the MQ channel table from MQ 5.3 to 6.0. Solution: Refresh the channel table to allow the MQ Workflow utilities to update the channels. This is described in Appendix A. Updating the environment manually, Refreshing the templates in the channel table. --------------------------

Appendix C. References
WebSphere MQ documentation: WebSphere MQ Migration Information Some issues affecting migration to IBM WebSphere MQ, Version 6.0 SC34-6604-01, Oct. 2005 WebSphere MQ for AIX Quick Beginnings GC34-6478-01 WebSphere MQ for HP-UX Quick Beginnings GC34-6479-03 WebSphere MQ for Solaris Quick Beginnings GC34-6477-02 WebSphere MQ for Windows Quick Beginnings GC34-6476-01

DB2 documentation: Administration Guide: Implementation SC09-4820-01

WebSphere MQ Workflow documentation: For troubleshooting and general MQ Workflow installation and configuration issues refer to IBM WebSphere MQ Workflow Installation Guide Version 3.6 SH12-6288-11

Appendix D. Used product versions

This document is based on systems that had the following versions installed: WebSphere MQ Workflow Version 3.6.0.6 WebSphere MQ 5.3 and 6.0 DB2 Version 8.2