Resolving problems when deploying message flows or message sets

  1. To debug problems when deploying, check the logs:

    These logs might be on separate computers, and must be used in conjunction with the workbench output to ensure that the deployment was successful.

    Use the mqsilist command to check that the deployment was successful, or look in the Windows Event or broker domain Event log.

  2. Use this checklist when you have deployment problems:
    • Make sure that the remote queue manager is running.
    • Make sure that channels are running.
    • Display the channel status to see if the number of system messages sent increases.
    • Check the channel from the remote end.
    • Check the queue manager name.
    • Determine whether the channel is a cluster channel.

This topic contains advice for dealing with some common problems that can arise when deploying message flows or message sets.
Preparing to deploy:
During deployment:
Canceling deployment:
After deployment:

Migrated message flows are not available to add to a broker archive file

An error is issued when you add a dictionary to a broker archive file

You cannot drag a broker archive file to a broker

You cannot deploy a message flow that uses a plug-in message flow

The compiled message flow (.cmf) file has not been generated

The message flow deploys on the test system, but not elsewhere

Your deployment indicates that the broker does not exist

The Configuration Manager is trying to deploy to a broker that does not exist

The Configuration Manager reports that it is out of memory

A correlation name error is issued when you deploy to a Version 2.1 broker

Error messages are issued when you deploy on z/OS

Expected serialization of input is not occurring for a shared queue that serves multiple instances of a message flow on z/OS

MQe nodes do not work as expected after deployment to a Version 6.0 broker

Error messages are issued when you deploy

The error messages that might be generated during a deployment are listed below with an explanation:

Message BIP1106 with WebSphere MQ reason code 2030
  • Scenario: Error message BIP1106 is issued with reason code 2030 when you are deploying a large message set.
  • Explanation: The size of the message exceeds the maximum message length of the transmission queue to the broker queue manager.
  • Solution: Increase the maximum message length for the transmission queue using the WebSphere MQ alter qlocal command, where the maximum message length is in bytes:
    alter ql(transmit_queue_name) maxmsgl(104857600) 
    See the WebSphere MQ System Administration Guide for more information on this command.
Message BIP1106 with WebSphere MQ error AMQ7463
  • Scenario: Error message BIP1106 is issued with reason code 2102 when you are deploying a large message set to a broker that shares the queue manager with the Configuration Manager. WebSphere MQ error message AMQ7463 is also issued with the text: The log for queue manager <queue manager> is full.
  • Solution:
    1. Stop the Configuration Manager using the mqsistop command.
    2. Stop the broker using the mqsistop command.
    3. Stop the queue manager using the WebSphere MQ amqmdain command:
      amqmdain end <queue manager>
    4. If you have WebSphere MQ Version 5 installed, click Start > Programs > IBM WebSphere MQ > WebSphere MQ Services to start WebSphere MQ Services.
    5. Start of changeIf you have WebSphere MQ Version 6 installed, click Start > Programs > IBM WebSphere MQ > WebSphere MQ Explorer to start WebSphere MQ Explorer.End of change
    6. Start of changeRight-click the queue manager, and click Properties. In WebSphere MQ Services click the Log tab, in WebSphere MQ Explorer, select the Log entry in the left pane.End of change
    7. Increase the number of log primary and secondary files so that the total size is larger than the deploy message.
    8. Restart the Configuration Manager using the mqsistart command.
    9. Restart the broker using the mqsistart command.
    10. Restart the queue manager using the WebSphere MQ amqmdain command:
      amqmdain start <queue manager>
      .
Message BIP1538 with reason code 2218
  • Scenario: Error message BIP1538 is issued with reason code 2218 when you are deploying a large message set.
  • Explanation: The size of the message exceeds the maximum message size on the channel.
  • Solution: Increase the channel maxmsgl parameter on both channel pairs, at both ends:
    1. On the Configuration Manager queue manager, issue the WebSphere MQ alter channel command:
      alter chl(CM_to_BRK) chltype(sdr) MAXMSGL(104857600) 
      alter chl(BRK_to_CM) chltype(rcvr) MAXMSGL(104857600) 
    2. On the broker queue manager, issue the WebSphere MQ alter channel command:
       alter chl(BRK_to_CM) chltype(sdr) MAXMSGL(104857600) 
       alter chl(CM_to_BRK) chltype(rcvr) MAXMSGL(104857600)
    3. Stop and restart each of the channels.
Message BIP1536
  • Scenario: You have defined a Configuration Manager to run with one user ID and you have defined a broker to run on a different computer with a different user ID. Deployment is successful but error message BIP1536 is issued when you deploy message flows and message sets to the broker.
  • Explanation: The Configuration Manager is unable to register for internal subscriptions with the broker because the broker is running under one ID and the Configuration Manager is running under another ID. The broker and the Configuration Manager relay internal messages back and forth via publish/subscribe. These messages are carried through WebSphere MQ, which requires certain authorizations.
  • Solution:
    • Ensure that the broker's user ID is a member of the mqm and mqbrkrs groups.
    • Define the broker's user ID on the computer where the Configuration Manager is running.
    • Define the Configuration Manager's user ID on the computer where the broker is running.
    • Ensure that all IDs are in lowercase so that they are compatible between computers.
Messages BIP1536 and BIP7017
  • Scenario: Error messages BIP1536 and BIP7017 are displayed.
  • Explanation: The Configuration Manager has a problem registering its internal subscriptions on topics to do with broker status change, which it tries to do each time that you deploy a complete configuration. The cause of the problem is given by the message BIP7017, which indicates that you are running with a User Name Server configured, but that the broker to which you are deploying does not have the Configuration Manager service user ID in its user cache.
  • Solution: Make the following checks. When you identify and correct the problem, the subscriptions will be registered correctly the next time you deploy:
    • Ensure that the User Name Server is started.
    • Ensure that the WebSphere MQ channels between the User Name Server and the broker are started.
    • Ensure that the user ID is present in the User Name Server's domain.
Message BIP1835
  • Scenario: Error message BIP1835 is displayed.
  • Explanation: The message set that you are deploying produces a message set dictionary that is larger than the internal limit of 4MB. This could be because you have many large message definitions defined to the same message set.

    The size of an exported message set is not a good indication of the size of the message set dictionary that is generated at the time of deployment because the exported message set is stored as XML. This can be very verbose, but the dictionary has a much more compact internal format.

  • Solution: Split the message definitions into several smaller message sets.
Start of changeMessage BIP2045
  • Scenario: Error message BIP2045 is displayed in the Message Brokers Toolkit after deployment.
  • Explanation: Each broker is identified by a universally unique identifier (UUID), which is stored in the Configuration Manager when the broker is defined. The UUID is also stored in the broker when it receives its first deployment message. If the broker receives a deployment message that contains a different UUID, it rejects the deployment message and issues error message BIP2045. This can happen in the following circumstances:
    • you try to deploy from a second Configuration Manager; this scenario is not supported.
    • you re-create the Configuration Manager but not the broker
    • you experience problems with the WebSphere MQ channel while you are deleting and re-creating the broker
  • Solution: Ensure that you are not using more than one Configuration Manager to control a single broker. If this is not the problem, follow the instructions in the BIP2045 error message to regain control of the broker by rebuilding the broker and redeploying your message flow applications.
End of change
Message BIP2066
  • Scenario: Error message BIP2066 is displayed.
  • Explanation: The deployment request was not acknowledged by the execution group before the broker timeout ConfigurationTimeout plus the ConfigurationDelayTimeout (default 60 seconds) expired.
  • Solution: Change these timeouts using the -g and -k parameters of the mqsicreatebroker and mqsichangebroker commands.
Message BIP2242
  • Scenario: Error message BIP2242 is displayed.
  • Explanation: The deploy (configuration change) request was not accepted before the broker timeout ConfigurationTimeout (default 300 seconds) expired. The timeout needs to be long enough for the message flow to complete processing its current message and then accept the deploy request.
  • Solution: Set these timeouts using the -g and -k parameters of the mqsicreatebroker and mqsichangebroker commands.
  • Scenario: When you deploy to a broker, error message BIP7053S is displayed.
  • Explanation: This error occurs in a multi TCP/IP stack environment and indicates that the UNIX System Services (USS) TCP/IP environment has not been set up correctly.
    WebSphere Message Broker uses USS functions to obtain the hostname for a particular system. The following error message is displayed if the default hostname is not set up correctly in the USS environment:
    BIP7053S: Broker $SYS_mqsi 0 unexpected Java exception java.lang.Error: -2103399272!java.net.UnknownHostException :
    Hostname: Hostname
    The hostname that is reported in the error message is the one that has been returned to the broker as a result of the gethostname call.
  • Solution: Ensure that the TCP/IP environment is configured correctly in USS.
Tagged/Delimited String (TDS) Validator error
  • Scenario: You try to deploy a message set with a TDS wire format that has an error.
  • Explanation: The following extract from an error log illustrates what you might see for a TDS Validator error. In this case, the cause of the problem is that the element Town does not have a tag defined.
    TDS Extractor Trace File
    ========================
    
    Beginning Extract..
    
    Extracting Identification Info
    Extracting Project Info
    Extracting Messages
    Extracting Elements
    Extracting Compound Types
    Extracting Type Members
    Extracting Type Members
    Extracting Type Members
    Extracting Type Members
    Extracting Type Members
    Beginning Indexing..
    
    Creating Member IDs to Tags Index Table.
    
    Beginning Validation..
    
    Validating Project
    Validating Types
    ERROR: TDSValidator::ValidateTypeMemberSimpleElement:
      Simple elements in a type with Data Element Separation attribute = Tagged 
      Delimited must have the following attribute set:
      Element Level - Tag
    (Element ID: Town)
    (Type ID: AddressType)
    Return Code: -80
    
    Validating Messages
    
    Trace Info
    ===========
    EXCEPTION: TDSValidator::Validate:
      TDS Validation failed.
        1 errors
        0 warnings
    Return Code: -1
  • Solution: Use the information in the error log to rectify the problem.

Error message BIP2432 is issued when you deploy from a Version 6.0 Configuration Manager to a Version 2.1 broker

When canceling a deployment, mqsilist shows a message flow in an execution group but the tooling does not

You are not notified of the result of a deploy

You do not receive confirmation that the deployment was successful

You cannot see any deployed message flows or message sets

A deleted broker remains in the domains navigator

Your XMLTransformation node does not work after deployment

There are two scenarios that explain why your XMLTransformation node might not work after deployment:

Error messages are displayed indicating that the style sheets were not found

You get unexpected transformation results.

  • Scenario: You get unexpected transformation results.
  • Explanation: For complex message flows, incompatibility might arise among style sheets and XML files after a deployment. There are two likely reasons for this:
    • Only part of the cooperating style sheets or XML files are deployed and updated (this might be caused by a file system failure).
    • Multiple XMLT nodes that are running inside the same execution group are supposed to use compatible style sheets, but are using different versions to process the same incoming message.
  • Solution: If only part of the cooperating style sheets or XML files are deployed and updated, resolve any incompatibility by redeploying the compatible versions. To avoid multiple XMLT nodes using different versions of the style sheet, pause relevant message flows in the target execution group before performing the deployment, then restart the flows.
Related concepts
Deployment overview