none
HIS / CICS Issues RRS feed

  • Question

  • Hi, 

    I'm using BizTalk Server 2009.

    I have an application that use a send port CICS, using the BizTalk Adapters for Host Systems 2.0 pack.

    I always have the error message : HISETBG0001 Application Integrator has intercepted an exception in method <MethodName>.  Following is the exception description: HISMTTW0025 The TRMTransport received a socket error while attempting to peek at data for performance reporting when processing method <MethodName>. IP Address: <IPAddress>, port: <Port>, program name:<MethodName>, Error description: TimedOut..

    Can anyone help me please ?

    Monday, March 19, 2012 2:00 PM

Answers

  • Hi,

    Can you please check the event log on the BizTalk Server for more events at this time frame ?

    Please also check your CICS Logs on the Mainframe side, it could be possible that the CICS / COBOL Program took to long to execute the Transaction because of a loss of SyncPoint or a bad written :-) DB2 Query !

    Best Regards,


    Steve Melan - BCEE My Blog : http://stevemelan.wordpress.com

    Wednesday, April 4, 2012 6:17 AM

All replies

  • It is hard to say for sure what the exact cause of the problem is, but it appears that the BzTalk Adapter for Host Applications (Transaction Integrator) is timing out while waiting for a response from the mainframe application that it is communicating with.

    Is it possible that you configured a Timeout in the Assembly that you are using to specify the connection information for the HostApps adapter?

    You can also do a network trace to capture the TCP/IP traffic that is being sent between the BizTalk Server and the IBM mainframe to see if there is any data being exchanged.

    If you need more detailed troubleshooting assistance, you can open a support case so that we can take a look at this in more detail.

    Thanks...


    Stephen Jackson - MSFT

    Monday, March 19, 2012 10:15 PM
  • Hi,

    Can you please check the event log on the BizTalk Server for more events at this time frame ?

    Please also check your CICS Logs on the Mainframe side, it could be possible that the CICS / COBOL Program took to long to execute the Transaction because of a loss of SyncPoint or a bad written :-) DB2 Query !

    Best Regards,


    Steve Melan - BCEE My Blog : http://stevemelan.wordpress.com

    Wednesday, April 4, 2012 6:17 AM
  • Hello Steve,

    I am having the same problem, I checked CICS Logs and the transaction took to long around 5, 6 minutes. This exception is always throwed after 2 minutes. I would like to know if there is some configuration in HIS 2009 to increase the time to wait a response from the Mainframe or the only way to solve it is check DB2 Query?

    Best Regards,


    André Rentes

    Thursday, December 13, 2012 3:05 PM
  • Andre,

    I suspect that the TCP/IP socket is being timed out and closed based on the default TCP/IP setting for TcpTimedWaitDelay:

    TcpTimedWaitDelay

    Key: Tcpip\Parameters

    Value Type: REG_DWORD—time in seconds

    Valid Range: 30-300 (decimal)

    Default: 0x78 (120 decimal)

    Description: This value determines the length of time that a connection stays in the TIME_WAIT state when being closed. While a connection is in the TIME_WAIT state, the socket pair cannot be reused. This is also known as the 2MSL state because the value should be twice the maximum segment lifetime on the network. For more information, see RFC 793.

    This parameter and many other TCP/IP settings are discussed in a paper that can be downloaded from http://www.microsoft.com/en-us/download/details.aspx?id=9152 .

    To test this theory, you could change this value to a higher value just to see if it changes the behavior. Note that this is a global setting and will impact all TCP/IP connections on the server. The suggested change is just to see if increasing this timeout to 4 minutes (for example) changes the BAHA error to occur after 4 minutes instead of 2 minutes.

    Once we know if this is the cause, then some decisions can be made to see if another solution is possible.

    One other thing you can try is to set a timeout in the BAHA Send Port configuration (in the connection string properties) or in the TI Remote Environment (RE) if you are using an RE instead of a connection string.  

    Thanks...


    Stephen Jackson - MSFT

    Friday, December 14, 2012 3:17 PM
  • In doing some further investigation, you might want to change the following default setting instead of the TcpTimedWaitDelay:

    TcpFinWait2Delay

    Key: Tcpip\Parameters

    Value Type: REG_DWORD—number

    Valid Range: 30–294,967,295

    Default: 120

    Description: This value controls the maximum number of seconds that a TCP connection will remain in the FIN_WAIT_2 state. For more information, see RFC 793.

    The scenario that you are seeing appears similar to the following problem that we investigated several years ago.

    823183 BUG: Long running COMTI transactions are unsuccessful and you receive an event 102 (2150) error message
    http://support.microsoft.com/kb/823183/EN-US

    By increasing the TcpFinWait2Delay setting, the underlying TCP/IP socket will be left in a FIN_WAIT_2 state longer (for the time specified in the manually added registry entry) which should allow for the connection to remain open until the mainframe transaction responds.

    Thanks...


    Stephen Jackson - MSFT

    Friday, December 14, 2012 4:34 PM