IBM Support

IV30360: WHEN AN ENDPOINT IS UNAVAILABLE, ONE MORE DISTRIBUTION IS ATTEMPTED.

Subscribe to this APAR

By subscribing, you receive periodic emails alerting you to the status of the APAR, along with a link to the fix after it becomes available. You can track this item individually or track all items by product.

Notify me when this APAR changes.

Notify me when an APAR for this component changes.

 

APAR status

  • Closed as program error.

Error description

  • When an endpoint status is UNAVILABLE or INTERRUPTED, one more
    retry distribution is made.
    <configuration>
    retry_ep_cutoff = 180
    conn_retry_interval = 60
    
    <current behavior :incorrect>
    1.start distribution
    2.Endpoint becomes unavailable
    (60sec elapsed)
    3.unavailable time(60) < retry_ep_cutoff(180)-->1st retry start
    4.Endpoint becomes unavailable
    (60sec elapsed)
    5.unavailable time(120) < retry_ep_cutoff(180)-->2nd retry start
    6.Endpoint becomes unavailable
    (60sec elapsed)
    7.unavailable time(180) = retry_ep_cutoff(180)-->3rd retry start
    ** this attempt should not be done **
    8.Endpoint becomes unavailable
    
    <correct behavior>
    1.start distribution
    2.Endpoint becomes unavailable
    (60sec elapsed)
    3.unavailable time(60) < retry_ep_cutoff(180)-->1st retry start
    4.Endpoint becomes unavailable
    (60sec elapsed)
    5.unavailable time(120) < retry_ep_cutoff(180)-->2nd retry start
    6.Endpoint becomes unavailable
    (60sec elapsed)
    

Local fix

Problem summary

  • When an endpoint status is UNAVILABLE or INTERRUPTED, MDist2
    repeater retries the distribution after conn_retry_interval.
    When conn_retry_interval elapsed, if the total down time is
    equal to or greater than retry_ep_cutoff, MDist2 repeater should
    stop the retrial of the distribution.
    When conn_retry_interval elapsed, MDist2 compares the total down
    time with retry_ep_cutoff to determine whether or not to start
    the retrial of the distribution. But the total downtime is not
    updated just before it is compared. It is updated after MDist2
    starts the retial. So, the total down time becomes less than the
    correct value. That causes the Mdist2 to make one more retrial
    even though the correct down time exceeds retry_ep_cutoff.
    

Problem conclusion

  • The gateway has been fixed. This fix will be included in the
    next Tivoli Management Framework 4.1.1 and 4.3.1 patch for
    TMR/MN/GW.
    

Temporary fix

Comments

APAR Information

  • APAR number

    IV30360

  • Reported component name

    MGMT. FRAMEWORK

  • Reported component ID

    5698FRA00

  • Reported release

    431

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2012-10-15

  • Closed date

    2012-10-31

  • Last modified date

    2012-10-31

  • 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

    MGMT. FRAMEWORK

  • Fixed component ID

    5698FRA00

Applicable component levels

  • R411 PSY

       UP

  • R431 PSY

       UP

[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SSXLSW","label":"Tivoli Management Framework"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"431","Edition":"","Line of Business":{"code":"LOB35","label":"Mainframe SW"}}]

Document Information

Modified date:
31 October 2012