Diagnosing service provider runtime errors

If you are having problems receiving or processing inbound messages in a provider mode pipeline, there could be a problem with the transport or a specific SOAP message.

• You receive a DFHPI0401, DFHPI0502, or similar message, indicating that an HTTP or WebSphere® MQ transport error has occurred.
  If the transport is HTTP, the client receives a 500 Server Internal Error message. If the transport is WebSphere MQ, the message is written to the dead letter queue (DLQ). A SOAP fault is not returned to the web service requester, because CICS® cannot determine what type of message was received.
• You receive a DFHxx message and a 404 Not Found error message.
  1. If you are not using the web services assistant, you must create a URIMAP resource.
     If you are using the web services assistant, the URIMAP is created automatically for you when you run the PIPELINE SCAN command. The system log provides information on any errors that occurred as a result of running this command.
  2. Check that the WEBSERVICE resource is enabled and that the URIMAP it is associated with is what you expected.
     If your WEBSERVICE resource is in an UNUSABLE state, see Diagnosing deployment errors.
  3. Check that you have correctly specified the URI and port number.
     In particular, check the case, because the attribute PATH on the URIMAP resource is case sensitive.
• If there are unexpected errors being reported, consider using CEDX to debug the web service application.
  1. Check the system log to see what error messages are being reported by CICS.
     This could indicate what type of error is occurring. If CICS is not reporting any errors, ensure that the request is reaching CICS through the network.
  2. Run CEDX against CPIH for the HTTP transport, CPIQ for the WebSphere MQ transport, or the transaction that you specified in the URIMAP if this is different.

     If a task switch occurs during the pipeline processing before the application handler, unless the DFHWS-TRANID container is populated, the new task runs under the same transaction id as the first one. This can interfere with running CEDX, because the first task has a lock on the CEDX session. You can avoid this problem by using DFHWS-TRANID to change the transaction id when the task switches, allowing you to use CEDX on both the pipeline and application tasks separately.

     For more information about CEDX, see Using the CEDX transaction.
  3. If CEDX does not activate or allow you solve the problem, consider running auxiliary trace with the PI, SO, AP, EI, and XS domains active.
     This could indicate whether there is a security problem, TCP/IP problem, application program problem or pipeline problem in your CICS region. Look for any exception trace points or abends.
• If you are receiving conversion errors, see Diagnosing data conversion errors.
• If you think your problem is related to MTOM messages, see Diagnosing MTOM/XOP errors.
• If a persistent HTTP connection is periodically closed:
  1. Check whether performance tuning for HTTP connections is enabled. For more information, see SOTUNING
  2. If performance tuning is enabled, CICS will periodically close persistent HTTP connections to allow connections to be redistributed among regions that are listening on shared IP endpoints.
• If connection attempts are refused when your CICS region is at maximum capacity.
  1. Check whether performance tuning for HTTP connections is enabled. For more information, see SOTUNING
  2. If performance tuning is enabled, when CICS is at maximum capacity all inbound HTTP connection open requests will queue outside of CICS in the TCPIPSERVICE's listening connection's backlog queue in TCP/IP. The region's TCP/IP Global statistics SOG_PAUSING_HTTP_LISTENING field reflects whether it is currently the case, and the SOG_TIMES_AT_ACCEPT_LIMIT/SOG_TIME_LAST_PAUSED_HTTP_LISTENING fields contain more information on past occurrences.
  3. Use NETSTAT ALL to obtain the ConnectionsDropped statistics for the TCPIPSERVICE's listening connection. This is the number of connection requests received and dropped because the number of connection requests waiting in the backlog queue has reached the maximum limit.
     For more information, see Netstat in z/OS Communications Server: IP System Administrator's Commands.

     Statistics about connections dropped are also available from the following fields in the TCP/IP services: Resource statistics:

     • Connections dropped (SOR_CONNS_DROPPED)
     • Time connection last dropped (SOR_CONN_LAST_DROPPED)
  4. If the ConnectionsDropped value is too high, consider increasing the TCPIPSERVICE's backlog attribute's value.