IBM Integration Bus, Version 9.0.0.8 Operating Systems: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

See information about the latest product version

Resolving problems when running samples

Use the advice given here to help you to resolve common problems that can arise when you run or remove samples.

Use the following instructions to diagnose the problem.

Use WebSphere® MQ Explorer to determine which queue the input message is on:
1. Start WebSphere MQ Explorer.
2. Expand the folders to display the broker queue manager, IB9QMGR.
3. Click the Queues folder in the queue manager to display its queues.
4. Check the current depth column to identify the queue that is holding the input message. If several messages are stored on one queue, right-click the queue, then click Browse Messages to determine if the message that you are interested in is on the queue.
Use the following table to identify the problem, and a suggested solution to overcome it. If the sample that you are running does not use a database, ignore the database-related problems listed in the table.
If the table did not help you solve the problem, return to the IBM® Integration Toolkit and check the Problems view for error messages. Use this information to solve the problem.
If you created the sample yourself, you must check that all the objects in the sample have been named and configured correctly.

Problem	Reason	Suggested solution
The input message stays on the IN queue.	The broker, the queue manager, the listener, or the message flow itself has stopped.	Check that all the components are running and that the listener for the queue manager is listening on the port for the queue manager. Start any components that are not running.
The input message stays on the IN queue.	An unidentifiable message already on the IN queue cannot be processed by the message flow.	In WebSphere MQ Explorer, right-click the IN queue, then click All tasks > Clear Messages.
The input message goes to the FAIL queue.	The MQInput node cannot identify which parser it must use to parse the message.	If you are using the Enqueue facility in the workbench or the RfhUtil tool that is supplied in SupportPac IH03, you must type all the necessary message header information in the fields in the tool. If you are using the mqsiput.exe tool, you must add the header information to the message file itself.
The input message goes to the SYSTEM.DEAD.LETTER.QUEUE	The queue on which the input message was supposed to be put does not exist.	Ensure that you have created all the queues required for the sample.
You cannot find the input message on any queue.	You have not refreshed the display in WebSphere MQ Explorer, or you have refreshed only some of the queues.	To refresh all the queues in WebSphere MQ Explorer, right-click the Queues folder, then click Refresh. All the queues in the folder are refreshed.
You cannot find the input message on any queue.	The input message was passed to a terminal that was not connected to another node, and the message was discarded.	Ensure that all the nodes are connected to each other as required by the sample.
When using a DB2® database, the input message goes to the FAIL queue or the Event Log contains a message saying that the database was not found, or both.	DB2 is not running.	In a DB2 Command Window, enter the following command: `db2 start` If DB2 is already running, you receive the following message: `The database manager is already active.`
	The message flow is trying to access a database table that is not in the default schema. The name of the default schema is determined by, and is the same as, the user name that is used to access the database. If the table is not in the default schema, and no other schema is specified in the ESQL for the message flow, the message flow looks for the table in the default schema.	In a DB2 Command Window, enter the following commands: `DB2 "CONNECT TO database user username" DB2 "CREATE VIEW tablename AS SELECT * FROM tableschema.tablename"` where: `username` is the user name of the broker `tableschema` is the schema that contains the table that the message flow is accessing `tablename` is the table that the message flow is accessing
You receive the following error messages when you try to remove a DB2 database on Windows: `BIP9830I: Deleting the DB2 Database Your_database_name.` `BIP9835E: The DB2 batch command failed with the error code SQLSTATE=57019. The database could not be created/deleted. The error code SQLSTATE=57019 was returned from the DB2 batch command.`	If you use the DB2 Control Center to perform a query, a connection is opened to the database. This connection stays open until the DB2 Control Center is closed, when the connection is ended.	Close the DB2 Control Center application. To try to remove the sample again, click Yes.
You run a web services sample by using the prebuilt Test Client scenario and it hangs, then times out.	The problem occurs when you have a SOAPInput node that is being called by a SOAPRequest node. The default port that web services use is 7800, and the SOAPRequest nodes are set up to use this port. However, if this port is already in use, for example, by another sample, the port number is automatically incremented by one. Therefore, the default port must also be changed to match.	Issue the following mqsireportproperties command on one line, to check which port your provider integration server is using: `mqsireportproperties IB9NODE -e sampleIntegrationServer -o HTTPConnector -n port` where `sampleIntegrationServer` is the appropriate integration server for the sample that is being run. To verify that the port that the SOAPRequest node is using is the correct port to call the provider flow, change the port of the SOAPRequest nodes to the port that the provider integration server is using by completing the following steps: Open the message flow located in the message set project. (Perform this step for all of your SOAPRequest nodes). Open the HTTP Transport tab in the Properties view. If the port is not correct, change the port in the Web service URL property to the correct port for your web services provider or TCP/IP Monitor. Save the message flow. Rebuild and redeploy the broker archive (BAR) file. If you have set up a TCP/IP Monitor, you have already checked which port the web services provider is using, but you must still configure the consumer to send the messages to your TCP/IP Monitor, then rebuild and redeploy the BAR file. Alternatively, you can remove one of the samples that is using the same port, so that only one sample is deployed at a time.
In some samples, the format of the XML output in the Test Client might be displayed in a different format to the format that is shown in the documentation.	In all cases the output data is identical, it is the format that is different.	You can change the format of the output by selecting either View as Source or View as XML Structure from the menu in the Test Client.

bu43950_.htm |

Last updated Friday, 21 July 2017