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 you use IMS nodes

Advice for dealing with common problems that can arise when you develop message flows that contain IMS™ nodes.

Before you start:

Read about IMS in IBM Information Management System (IMS).
Ensure that you have set up the broker runtime environment correctly, as described in Preparing the environment for IMS nodes.

If you experience problems when you use IMS nodes in message flows, follow the instructions for the following scenarios to diagnose and solve the problem.

How can I tell if my broker is connected to IMS Connect?
How can I discover the correct settings for Hostname, Portnumber, and DataStoreName?
What should I do when my transaction times out?
How many physical connections should I expect in IMS Connect?

How can I tell if my broker is connected to IMS Connect?

Scenario: You need to check if your broker is connected to IMS Connect.
Explanation: You can use SDSF on z/OS to issue a command to see which ports have clients connected to them.

Solution: Using SDSF, enter the following QUERY MEMBER command, where IM0ACONN is the name of your IMS Connect job:

/F IM0ACONN,QRY MEMBER TYPE(IMSCON)

The output is in the following format:

/F IM0ACONN,QRY MEMBER TYPE(IMSCON)                                                      
HWSC0001I   HWS ID=IM0ACONN RACF=Y  PSWDMC=N                                            
HWSC0001I      MAXSOC=50  TIMEOUT=0                                                     
HWSC0001I      RRS=N   STATUS=REGISTERED                                                
HWSC0001I      VERSION=V10 IP-ADDRESS=009.017.252.024                                   
HWSC0001I      SUPER MEMBER NAME=                                                       
HWSC0001I    ADAPTER=N                                                                  
HWSC0001I    DATASTORE=IM0A     STATUS=ACTIVE                                           
HWSC0001I      GROUP=IM0AGRNM MEMBER=IM0ACONN                                           
HWSC0001I      TARGET MEMBER=IM0A                                                       
HWSC0001I      DEFAULT REROUTE NAME=HWS£DEF                                             
HWSC0001I      RACF APPL NAME=                                                          
HWSC0001I      OTMA ACEE AGING VALUE=2147483647                                         
HWSC0001I      OTMA ACK TIMEOUT VALUE=120                                               
HWSC0001I      OTMA MAX INPUT MESSAGE=5000                                              
HWSC0001I    NO ACTIVE IMSPLEX                                                          
HWSC0001I    PORT=1080     STATUS=ACTIVE                                                
HWSC0001I      CLIENTID USERID   TRANCODE STATUS       SECOND  CLNTPORT  IP-ADDRESS                                                                              
HWSC0001I      HWSEHYMO JDOE   IVTNO    RECV             21      1109  009.017.137.11                                                                         
HWSC0001I      TOTAL CLIENTS=1  RECV=1 CONN=0 XMIT=0 OTHER=0

This example shows that one client is connected on TCP port 1109, and that the client is connecting from the IP address 9.17.137.11.

You can run netstat on that system to find out in which process that client is running.

Use the following IMS command to view the TPIPEs that are created for those connections:

/DISPLAY TMEMBER IMSConnect_Name TPIPE ALL

For transactions that have a commit mode of 1, the TPIPE name is the port number that is used for that interaction (for example, 1080 in the previous example).
For transactions that have a commit mode of 0, the TPIPE name is the same as the client ID (for example, HWSEHYMO in the previous example). The client ID is generated automatically in the IMSRequest node.

How can I discover the correct settings for Hostname, Portnumber, and DataStoreName?

Scenario: Your broker fails to connect to IMS and you want to verify your settings.
Explanation: You can use SDSF on z/OS to issue a command to see members of the XCF group to which your IMS control region belongs. One of these members should be IMS Connect. You can then run a command against IMS Connect to discover these properties.

Solution: Use SDSF to enter the following command:

/xx/display OTMA

where xx is the reply ID for your IMS control region job.

For example, if you see ....... *26 DFS996I *IMS READY* IM0A in S.log, run the command /26/DISPLAY OTMA.

The output from that command shows the name of the IMS Connect that is in the same XCF group as this IMS control region:

DFS000I     GROUP/MEMBER      XCF-STATUS   USER-STATUS    SECURITY  TIBINPT SMEM   IM0A          
DFS000I                         DRUEXIT  T/O                                       IM0A          
DFS000I     IM0AGRNM                                                               IM0A          
DFS000I     -IM0A             ACTIVE       SERVER         CHECK                    IM0A          
DFS000I     -IM0A               N/A        0                                       IM0A          
DFS000I     -IM0ACONN         ACTIVE       ACCEPT TRAFFIC CHECK       05000        IM0A    
DFS000I     *08350/175112*   IM0A

Use SDSF to enter the following QUERY MEMBER command, where IM0ACONN is the name of your IMS Connect job that was reported by the previous command:

/F IM0ACONN,QRY MEMBER TYPE(IMSCON)

The output is in the following format:

/F IM0ACONN,QRY MEMBER TYPE(IMSCON)                                                     
HWSC0001I   HWS ID=IM0ACONN RACF=Y  PSWDMC=N                                            
HWSC0001I      MAXSOC=50  TIMEOUT=0                                                     
HWSC0001I      RRS=N   STATUS=REGISTERED                                                
HWSC0001I      VERSION=V10 IP-ADDRESS=009.017.252.024                             
HWSC0001I      SUPER MEMBER NAME=                                                       
HWSC0001I    ADAPTER=N                                                                  
HWSC0001I    DATASTORE=IM0A     STATUS=ACTIVE                                     
HWSC0001I      GROUP=IM0AGRNM MEMBER=IM0ACONN                                           
HWSC0001I      TARGET MEMBER=IM0A                                                       
HWSC0001I      DEFAULT REROUTE NAME=HWS£DEF                                             
HWSC0001I      RACF APPL NAME=                                                          
HWSC0001I      OTMA ACEE AGING VALUE=2147483647                                         
HWSC0001I      OTMA ACK TIMEOUT VALUE=120                                               
HWSC0001I      OTMA MAX INPUT MESSAGE=5000                                              
HWSC0001I    NO ACTIVE IMSPLEX                                                          
HWSC0001I    PORT=1080     STATUS=ACTIVE                                          
HWSC0001I      CLIENTID USERID   TRANCODE STATUS       SECOND  CLNTPORT  IP-ADDRESS     
HWSC0001I      HWSEHYMO JDOE   IVTNO    RECV             21      1109  009.017.137.11   
HWSC0001I      TOTAL CLIENTS=1  RECV=1 CONN=0 XMIT=0 OTHER=0

What should I do when my transaction times out?

Scenario: The transaction times out and the message is sent to the Timeout terminal, or an exception is issued.
Explanation: Your transaction is taking longer than the values that are set for the execution or socket timeouts, therefore the node stops waiting for a response, and issues an exception or sends the message to the Timeout terminal.
If the transaction subsequently completes successfully, the result depends on the commit mode that is set on the IMSRequest node:
- If the Commit mode property is set to 0: COMMIT_THEN_SEND, the unit of work is committed and the response is discarded.
- If the Commit mode property is set to 1: SEND_THEN_COMMIT, the response is not sent and the unit of work is rolled back.
Solution: Increase the execution or socket timeout values to give enough time for the transaction to complete.
- Configure the execution timeout by using the Timeout waiting for a transaction to be executed property on the IMSRequest node.
- Configure the socket timeout on the configurable service.

How many physical connections should I expect in IMS Connect?

Scenario: You need to set the values for the number of connections that are required by clients that are connecting to IMS Connect.
Explanation: The number of physical connections that can be opened in IMS Connect is limited. The limit depends on the MAXSOC and MAXFEILEPROC settings.
- The MAXSOC setting in IMS Connect determines the number of sockets that can be opened in IMS, which is the number of ports on which IMS listens for connections, plus the number of physical connections.
- MAXFILEPROC is a UNIX System Services (USS) setting, which must be greater than or equal to MAXSOC, otherwise IMS reaches this limit before it reaches its own MAXSOC limit.
If the IMS Connect process is granted superuser authority in USS, it sets MAXFILEPROC automatically.
If the MAXSOC value is reached, IMS Connect issues warning message HWSS0771W, and refuses new requests for connections from clients. This behavior continues until the number of open sockets is below the limit (for example, after some clients have disconnected).

If the MAXFILEPROC value is reached, USS issues information message BPXI040I.
Solution: When you set values for MAXSOC and MAXFILEPROC, consider how many clients are likely to connect concurrently to IMS Connect, and how many connections those clients will require.
IBM® Integration Bus acts as a client to IMS Connect, and opens connections to IMS Connect. Therefore, find out how many connections are required by IBM Integration Bus by gathering the following information:
- The number of message flows with IMS nodes that are deployed
- For those message flows, the values of the Additional instances property
The maximum number of connections required for each broker is determined by the number of threads that can be running concurrently in the IMS nodes. In the following example, three message flows with IMS nodes exist:
- Message flow A has 0 additional instances, therefore one thread is running.
- Message flow B has 3 additional instances, therefore four threads can be running concurrently.
- Message flow C has 4 additional instances, therefore five threads can be running concurrently.
In this example, the maximum number of connections required by the broker is 10 (1+4+5). If you have four other similar brokers, all connecting to the same instance of IMS Connect, which has five ports configured, you would set the maximum number of sockets (MAXSOC) to at least 55 (the maximum number of connections for five brokers plus the number of ports: 10x5+5).

au66280_.htm |

Last updated Friday, 21 July 2017