IBM Support

IV36415: NAVIGATOR STATUS INDICATOR NOT MATCH LOWER LEVELS

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • Over time, status indicators on higher level navigator nodes
    become inconsistent with lower level node indicators. A
    ClassCast exception appears in the ras1 log some time before
    the inconsistency is observed.
    
    RECREATE INSTRUCTIONS:
    The exact cause of this problem has still not been identified.
    Before resolution can be completed, an additional diagnostic
    build must be run in the customer environment to gather more
    details on the the exception believed to underly the reported
    problem
    

Local fix

  • None identified to date
    

Problem summary

  • Over time, status indicators on higher level navigator nodes
    become inconsistent with lower level node indicators.  A
    classCast exception may appear in the RAS1 log some time before
    the inconsistency is observed.
    
    
    Navigator node state augmentation anomalies may appear when
    navigator nodes are affected by high severity acknowledged
    events combined with lower severity events.  The problems appear
    when event state changes occur after the portal client is
    started but before affected nodes are expanded.  A classCast
    exception may appear in the client RAS1 log some time before the
    inconsistency is observed although this may not be directly
    related to the problem.
    

Problem conclusion

  • lthough the external symptoms are the same, internally there are
    two different problems.  In the first case, the lower severity
    event becomes true, while in the second case it becomes false
    (is removed), after the portal client is started.
    
    For the first case, the logic was changed to ensure accumulated
    events and acknowledgements are always processed in
    chronological order.  The classCast exception was eliminated by
    changing the event handling logic to ensure all events are
    processed appropriately.
    
    For the second case, the logic was changed to ensure state
    removal events are saved for propagation to lower level nodes
    during node expansion.  However, because of performance
    implications, this second part of the fix must be explicitly
    enabled via the "tep.save.removed.events" run-time parameter.
    This parameter controls how removed events are saved for
    propagation to expanding nodes.  It may be set to one of the
    following case-insensitive values (if not specified, it is
    assumed to be NONE):
    
      NONE   - disables the option.  Removal events are not saved
    and the second part of the problem is not corrected.  This
    setting has no adverse performance impact.
      ALL    - causes all removal events to be saved for the
    duration of the portal client execution.  Each portal client
    instance maintains its own record of removal events.  This
    option should prevent all state anomalies but, in an active
    environment, these events may eventually consume an excessive
    amount of memory.  Any resulting performance problems must be
    corrected by restarting the affected portal client instance.
      NEEDED - saves removal events until all impacted nodes have
    been fully expanded.  This option should prevent all state
    anomalies and will release memory as nodes are expanded so there
    should be a lower chance of performance problems.  However, if
    navigator nodes are never fully expanded, saved removal events
    will accumulate in the same way as for the ALL option and could
    consume excessive memory.  Any resulting performance problems
    must be corrected by restarting the affected portal client
    instance.
    
    The NONE option is recommended for customers who have not
    encountered navigator state inconsistencies.  The NEEDED option
    is recommended for customers who still see anomalies when using
    the NONE option.  The ALL option is a last resort choice and is
    not recommended unless anomalies are seen with the NEEDED option
    and the customer is able to tolerate any memory consumption
    issues that may arise.
    
    The Manage Tivoli Monitoring Services application can be used to
    configure the setting.  According to your environment, set the
    desired value as follows:
    
    For desktop clients: Select Advanced | Edit Variables...  from
    the context menu, double-click the "tep.save.removed.events"
    symbol, enter "NEEDED" in the input field and select the "In
    use" checkbox.
    
    For browser clients: Perform the same steps as for the desktop
    clients or select Advanced | Edit ENV File...  and insert the
    following line:
        document.writeln( '<PARAM NAME="tep.save.removed.events"
    VALUE="NEEDED">' );
    before the following line:
        <!--END OF PARAMS-->
    
    For Java Web Start clients: On the portal server, edit the
    $CANDLEHOME\Config\tep.jnlpt file and insert the following line:
        <property name="tep.save.removed.events" value="NEEDED"/>
    before the following line:
        <!--$COOKIES$-->
    and reconfigure the portal server.  To avoid the reconfigure
    step, the same change can be applied to both the
    $CANDLEHOME\CNB\tep.jnlp and $CANDLEHOME\Config\tep.jnlpt files.
    Adjust the file locations as needed for Linux or UNIX portal
    servers.  In either case, use the Internet Explorer Internet
    Options function to delete the browser temporary files to ensure
    the modified tep.jnlp file is reloaded.
    
    
    The fix for this APAR is contained in the following maintenance
    packages:
    
      | fix pack | 6.2.3-TIV-ITM-FP0004
      | fix pack | 6.3.0-TIV-ITM-FP0002
    

Temporary fix

Comments

APAR Information

  • APAR number

    IV36415

  • Reported component name

    TEP

  • Reported component ID

    5724C04EP

  • Reported release

    622

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2013-02-06

  • Closed date

    2013-06-28

  • Last modified date

    2013-10-14

  • 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

    TEP

  • Fixed component ID

    5724C04EP

Applicable component levels

  • R623 PSY

       UP

[{"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSCTLMK","label":"ITM Tivoli Enterprise Portal V6"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"622","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
14 October 2013