IBM Support

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

Direct link to fix

Subscribe

You can track all active APARs for this component.

 

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 number

    IT05181

  • Reported component name

    STR B2B INTEGRA

  • Reported component ID

    5725D0600

  • Reported release

    510

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2014-10-27

  • Closed date

    2015-10-14

  • Last modified date

    2017-11-15

  • 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

  • R526 PSY

       UP

[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SS3JSW","label":"IBM Sterling B2B Integrator"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"5.1","Edition":"","Line of Business":{"code":"LOB02","label":"AI Applications"}}]

Document Information

Modified date:
15 November 2017