IBM Support

IC97267: MANAGING 2 SESSIONS IN TPC-R SHARING THE SAME LSS; A HYPERSWAP SESSION CAN GET STUCK IN STATE WITH NO OPTIONS AFTER SUSPEND

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • If 2 or more session share the same LSS pairings and have TPC-R
    managing the freeze for all of them, then all sessions sharing
    the lss-lss pairing will be frozen during a suspend command
    initiated by any of the sessions. For a HyperSwap session type
    this is especially problematic due to the fact that an
    unexpected
    freeze will cause the HyperSwap session to go into an undefined
    state and thus has no available options. To avoid this issue
    ensure that your sessions do not share lss-lss pairings.
    

Local fix

  • Possible workarounds:
    - Start the session copysets via dscli
    - Issue refresh states command to the affected Session.
    

Problem summary

  • | fix pack | 5.1.1-TIV-TPC-FP0004 - target 2Q 2014 |
    | release  | 5.2.1-TIV-TPC-FP0000 - target 1Q 2014 |
    
    http://www-01.ibm.com/support/docview.wss?&uid=swg21320822
    
    The target dates for future fix packs do not represent a formal
    commitment by IBM. The dates are subject to change without
    notice.
    
    
    This fix will address the internal error caused by the session
    getting into an invalid state/mode and allow commands to
    be issued to the session. The internal error is caused by
    the next operation after a freeze which would change the
    session state and update its info. This passed in the new
    "state" defined in the copy rules from the first session to
    initiate the freeze.  The problem with that is that other
    sessions affected might actually be in a different state/mode
    (in this case the other was in HyperSwap mode) and then lead to
    an invalid state/mode.
    

Problem conclusion

  • Ideally the customer shouldn't have sessions that share the same
    LSS pairings because it defeats the purpose of putting them in
    separate sessions. If TPC-R is managing the freeze
    for all of the sessions then there is not concern about a data
    consistency issue because there is the logic to do all the
    freezes before the thaws.  IOS doesn't have this logic yet and
    thus could thaw things before everything is frozen.  And the
    freeze/thaw process doesn't span both IOS and TPC-R processing.
    

Temporary fix

Comments

APAR Information

  • APAR number

    IC97267

  • Reported component name

    TPC

  • Reported component ID

    5608TPC00

  • Reported release

    510

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2013-10-28

  • Closed date

    2013-12-20

  • Last modified date

    2013-12-20

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

    PM99624

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

Fix information

  • Fixed component name

    TPC

  • Fixed component ID

    5608TPC00

Applicable component levels

  • R511 PSY

       UP

  • R520 PSY

       UP

[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SS5R93","label":"IBM Spectrum Control"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"510","Line of Business":{"code":"LOB26","label":"Storage"}}]

Document Information

Modified date:
23 March 2022