IT05181: ODETTE FTP ENTRIES WITH RETRY_PENDING STATUS IN CAPI MODE ARE NOT PROCESSED AS EXPECTED DURING OUTBOUND CONNECTION

5.2.6.0

APAR status

• Closed as program error.

Error description

• Original outbound connection/session is terminated by "98
  emergency shutdown" error from receiver post SFID delivery. So,
  this SCHEDULED entry moves to RETRY_PENDING status.
  A. Session gets restarted per Physical Profile's "Session Retry
  Intervals" configuration but it doesn't hold file/resource.
  Hence Receiver reports "0 - resource unavailable".
  B. RETRY_PENDING entry is not picked up by OFTP scheduler
  C. Trying to pull the file by receiver from the Remote system
  via OFTP. The session was successful but there was no data /
  file picked up.
  

Local fix

Problem summary

• USERS AFFECTED:
  OFTP users
  
  PROBLEM DESCRIPTION:
  
  In OFTP ISDN mode, RETRY functionality is not working as
  expected when compared to IP Mode. There are two retry
  operations present in IBM Sterling B2B Integrator OFTP adapter,
  First one is Session retry.
  During session establishment, which is during SSID exchange,
  any failures that occur, there is a parameter of session retry
  which can be enabled and it helps for re-establishment of the
  session.
  
  Second one is File retry:
  During SFID exchange or, which is during file transfer, any
  failure makes the File to move to retry/RETRY_PENDING file with
  the next session established.
  
  PLATFORMS AFFECTED:
  All
  

Problem conclusion

• ======================
  RESOLUTION SUMMARY:
  
  Fixed the code to solve this mismatch of IP and ISDN behavior.
  File retry always goes with next subsequent session
  establishment, where as Session retry happen with the same
  session. Our OFTP product behaves and tries session retry even
  after FILE transfer failure, which is wrong in the product. Due
  to this, ISDN resources are getting wasted and BP simply put
  onto Waiting on IO and it causes delay of next transfer of file
  through ISDN mode.
  We also have a parameter "OFTP.Global.ForceRetryForAll=Yes"
  which makes the force session retry to happen for all reason
  codes/failures, But atleast it should stop for the valid SFID
  failures for which RETRY option is always set as NO in the OFTP
  system.
  
  In the EOS code, even though the retry is retrySameNum, we will
  check the ESID code whether it is one of SFID failure code, then
  we will not allow for session retry.
  
  This log message will come only when RetryForAll is set and for
  valid SFID failure: Immediate end of session. Disconnect
  communication layer.
  
  Along with 98 error code, we have to stop going for session
  retry for these error codes. All these ESID codes are not meant
  to go for session retry:
  ESIDREAS_EMERGENCY_CLOSE -05
  EXTREASON_EMERGENCY_CLOSE -98
  
  DELIVERED IN:
  5020600
  5105
  5020500_16
  5020601_8
  5020603_3
  

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:

Fix information

• Fixed component name

  STR B2B INTEGRA

• Fixed component ID

  5725D0600

Applicable component levels