PK79820: RECEIVING REPEATED DFHPI0002 A SEVERE ERROR (CODE X'0507') HAS OCCURRED IN MODULE DFHPITH. DUE TO INVALID_CHUNKING.

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• Receiving repeated DFHPI0002 messages that appears as the
  following:
  .
  DFHPI0002 CICSNAME A severe error (code X'0507') has occurred
  in module DFHPITH.
  .
  The following Trace Entries will appear:
  .
  WB 0701 WBCL  EXIT - FUNCTION(READ_RESPONSE) RESPONSE(EXCEPTION)
                       REASON(INVALID_CHUNK)
                       SET_BUFFER(00000000 , 00000000)
                       STATUS_CODE(C8)
                       STATUS_TEXT(37F53870 , 00000002 , 00000100)
                       MEDIATYPE(text/xml)
                       CHARSET(utf-8)
  .
  Followed by:
  .
  X'303030300D0A0D0A'
  .
  However, this gets split up through the network and arrives in
  2 parts.
  .
  The first part is X'30'.
  .
  The second part is: X'3030300D0A0D0A'.
  .
  DFHWBCL routine peek_chunk_header issues a PEEK socket RECEIVE.
  Sockets domain copies all the data it has available - X'30'
  into DFHWBCL's PEEK buffer.  As this is a PEEK, sockets domain
  retains this X'30' value in its own internal buffer.
  DFHWBCL scans to the end of this data, concludes that a further
  socket PEEK RECEIVE is required and issues one.  However,
  DFHWBCL bumps past the initial X'30' in its PEEK buffer before
  issuing the second receive.  By the time of the second socket
  RECEIVE, the rest of the data has arrived. Sockets domain has
  the full X'303030300D0A0D0A' so returns all 8-bytes to DFHWBCL.
  DFHWBCL now has the initial peeked X'30' followed by the full
  8-byte chunk header returned by sockets domain. This is 9-bytes
  in total.  DFHWBCL now issues a non-PEEK receive for 9-bytes.
  Sockets domain only has 8-bytes in its internal buffer so calls
  TCPIP asking for another byte of sockets data which will never
  arrive.  This receive hangs until the remote server closes the
  socket connection.
  .
  DFHWBCL peek_chunk_header is at fault here. If it needs to do
  more than 1 PEEK then it should always receive the PEEKED data
  into the beginning of the PEEK buffer.
  Additional Symptom(s) Search Keyword(s):
  DFHSM0133 CICS is under stress (short on storage above 16MB).
  Can occur when receiving a Chunked soap header response.
  The header does not contain a content-length but instead
  specifies transfer-encoding: chunked.
  In the failing scenarios CICS does a PEEK receive and
  only receives 4 bytes- which is the length. We remember this and
  do another PEEK, which now passes us more data, including the
  length.  We are able to locate the CRLF, but now our buffer
  contains llllnnncrlf, where llll is the length and nnnn is a
  copy of the length.
  In one case this length was in ascii
  34393230  or x'4320' bytes
  WBCL's buffer would contain
  34393230343932300D0A
  This caused WBCL to think the length of this chunk was
  x'42904290', causing a short on storage condition when
  trying to obtain a buffer for it.
  APPEND_THIS_CHUNK  DETERMINE_CHUNK_SIZE
  DFHSM0133 MSGDFHSM0133 SOS
  KIXREVDAM MSGDFHPI0002 MSGDFHPI0403 SOCKET TIMED OUT
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All                                          *
  ****************************************************************
  * PROBLEM DESCRIPTION: MSGDFHPI0002 receiving a webservice     *
  *                      response which arrives in HTTP          *
  *                      CHUNKED format.                         *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  A CICS webservice requester application sends a request to a
  remote webservice provider. The response arrives in HTTP CHUNKED
  format. All the HTTP chunks containing the HTTP body are
  successfully received by DFHWBCL. DFHWBCL then calls
  peek_chunk_header to peek the final zero length chunk header.
  This header has been split up over the network. When DFHWBCL
  issues the first PEEK SOCKET RECEIVE, 1 byte is returned.
  This byte is retained by sockets domain as the RECEIVE type
  is PEEK. When DFHWBCL issues the second PEEK RECEIVE, the
  remaining 7 bytes of chunk header have arrived. Sockets domain
  returns all 8 bytes of chunk header to DFHWBCL. However, DFHWBCL
  concludes there are 9 bytes as it received first 1 byte then a
  further 8. DFHWBCL now issues a non-PEEK receive for 9 bytes of
  data. Sockets domain only has 8 retained bytes of socket data so
  issues a further socket receive. This hangs until the remote
  server closes the socket connection. After the timeout, DFHWBCL
  returns an INVALID_CHUNK to DFHPITH. This causes a DFHPI0002
  message and PI0002 dump.
  

Problem conclusion

• DFHWBCL peek_chunk_header has been changed to correctly
  determine the length of a chunk header.
  

Temporary fix

• FIX AVAILABLE BY PTF ONLY
  

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

  UK44092

Modules/Macros

•    DESWBCL  DFHWBCL
  

Fix information

• Fixed component name

  CICSTS V3 Z/OS

• Fixed component ID

  5655M1500

Applicable component levels

• R500 PSY UK44092

     UP09/02/19 P F902

Fix is available

• Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.