PQ06092: HPNS ENABLED NON-BLOCKING APPLICATION HANGS WHEN SENDING DATA

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• HPNS enabled applications that send data using a non-blocking
  socket may hang.  The outgoing push value is not being updated
  correctly when HPNS sends the data over to the TCP/IP address
  space.  This results in data being left on the outgoing segment
  queue.  The remote side of the connection may not respond at the
  application level to the send since all the data is not
  delivered.  If the local socket application follows the send
  with a select for read, it may hang.
  This problem has been seen to cause PSF to hang.
  ADDITIONAL SYMPTOMS:
  Non-blocking send type socket calls may actually perform like a
  blocking call and fail to return control to the application
  until all the data has been sent to TCP/IP.
  VERIFICATION STEPS:
  1) Ensure that UQ03848 is applied as this corrects a more common
  flavor of this problem.
  2) The application must be issuing write requests with a data
  length greater than the databuffer size specified in the
  profile.
  3) A socket trace can be used to verify the application is
  using a non-blocking socket and is going through HPNS.
  4) The socket trace must have an ACB queued from HPNS that
  "does" not have the PENDMINITIALWRITE flag on.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All users of TCP/IP for MVS; V3R2.           *
  ****************************************************************
  * PROBLEM DESCRIPTION: HPNS enabled application data may not   *
  *                      be delivered.                           *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  Assuming the following value in the TCPIP Profile,
  
  DATABUFFERPOOLSIZE    100   10k
  
  A socket application issues a nonblocking send type socket call
  for 50k bytes of data. HPNS determines the minimum/maximum
  buffers required and attempts to provide them.  On this call, 5
  buffers are allocated and filled with data.  Then, Send_Data
  builds an ACB to queue the request over to the engine with the
  PendMInitialWrite bit turned on. Control is passed back to
  Process_Part1 which then calls Process_Part2. Process_Part2
  determines all the data has been sent and returns control to
  the application.
  
  The engine code processes the ACB and sets OutgoingPushNumber
  because the socket is nonblocking.  Since all the data was
  passed to the engine in the 5 buffers, the effective write
  length is the same as the write length. The data is all queued
  to the outgoing segment queue for this connection and TcpDown
  starts sending it out.
  
  The application gets control back and issues a select for write
  to determine when there is buffer space available. The select
  will pop as soon as the engine has sent 10K of the data, thus
  freeing up 1 buffer.
  
  The application then issues a nonblocking send type socket call
  for 20K of data. We will follow the same processing flow as
  above until we reach GetTcpStor which only gets 1 buffer since
  the application still has 4 in use. The first 10K of data is
  moved into the acquired buffer and Send_Data is called since
  a buffer was acquired. Send_Data again builds an ACB to queue
  the request to the engine with PendMInitialWrite on, but the
  write length will be 20K and the effective write length will be
  10K. Control is passed back to Process_Part1 which then calls
  Process_Part2.  Process_Part2 turns off PendMIinitialWrite and
  determines all the data has not been sent, so data buffers are
  re-allocated and Send_Data is called again.
  
  Send_Data will build an ACB to queue the request to the engine,
  but the PendMInitialWrite bit is not on this time. Control
  returns back to Process_Part2 which determines all the data has
  now been sent and returns control to the application.
  
  The engine processes the ACB with the first 10K and
  PendMInitialWrite, setting OutGoingPushNumber = ClientSndNxt +
  EffectiveWriteLength -1. This means that the outgoing push value
  is only incremented by the 10K instead of the 20K. When the ACB
  with the second 10K is processed, the outgoing push value is not
  updated since PendMInitialWrite is not on.
  
  The problem is that the second nonblocking write() call acts
  like a blocking call, and the outgoing push value is only
  incremented to 60K but 70K of data is queued to the outgoing
  segment.  Since TcpDown only sends out entire segments unless
  the data is pushed, the last 10K will not be shipped out until
  there is enough data to fill a segment.  This residual data will
  remain in the outgoing segment until the outgoing push is
  updated past its sequence number or enough data is queued to
  fill a network segment.
  
  Additional Keywords: PSF
  

Problem conclusion

• TCPREQU has been amended to increment the OutgoingPushNumber for
  a nonblocking socket for subsequent writes other than the
  initial write.
  
  * Cross Reference between External and Internal Names
  EZABB035 (TCPREQU )
  

Temporary fix

Comments

APAR Information

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

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

  UQ07907

Modules/Macros

• EZABB035
  

Fix information

• Fixed component name

  TCP/IP V3 MVS

• Fixed component ID

  5655HAL00

Applicable component levels

• R320 PSY UQ07907

     UP97/08/11 P F708

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.