OA42476: EVENT PUMP UN-REGISTERS RMF EXCEPTIONS AFTER A WLM POLICY CHANGE

A fix is available

Subscribe

You can track all active APARs for this component.

APAR status

  • Closed as program error.

Error description

  • After a WLM Policy change takes place, RMF exceptions will no
    longer be monitored by Event Pump.
    
    Event Pump - RMF Interface - F37=ERROR event ends
    
    I've checked the process. Almost all RMF messages (except a few
    new messages) are Informative. So we don't  have a good way to
    separate temporal and permanent problems.
    
    E.g for WLM change you have 'GPM0504I  The data retrieved by DDS
    may be inconsistent due to a change of the WLM service policy'.
    But in previous PMR (where Pump used incorrect metric) RMF
    returned 'GPM0626I
    
    The metric 008D0050 is not defined for resource type
    CENTRAL_STORAGE and work scope 'G''. As you see both messages
    are 'I'. Meanwhile in second case we definitely don't need to
    keep exception ctive... So I don't see a good way to make
    decision about keeping or removing of exception based on message
    itself.
    
    The solution which I see now is removing of exceptions only when
    RMF sequentially returns same message for it more than once (or
    more than twice, etc). Now we remove exception after first
    unsuccessful execution.
    
    E.g. in your case we will remove exceptions only after  second
    or third consequential GPM0504I. Will it work for you?
    
    Additional info requested by Guido to be added;
    
    I've found another F37=ERROR situation on our testing LPAR that
    I think
    may need some thinking...
    
    10:38:20.064 EIF0301 : TEC EVENT DATA FOLLOWS
    TEC_
    10:38:20.064
    TEC_GENERIC;source=MANULIFE.MANUMKMT;name_value_paTEC_
    10:38:20.064
    irs=■'_FORMAT=02','_ACTION=21','_F00=2013061310:38TEC_
    10:38:20.064
    :20.042820','_F01=SYST183','_F37=ERROR','_F36=HXCFTEC_
    10:38:20.064
    DLY','_F02=OS','_F04=0000120006','_F42=E','_F38=0.TEC_
    10:38:20.064 0','_F39=;SYSPLEX(TESTPLX1) TIME(20130613103800)
    RTEC_
    10:38:20.064 ESOURCE(SYST,*,XCF);% delay','_F40=03 GPM0511I
    DatTEC_
    10:38:20.064 a gatherer has just been started and can not yet
    rTEC_
    10:38:20.064 eturn data'~;END
    TEC_
    10:38:20.064 EIF0302 : END OF TEC EVENT DATA
    TEC_
    10:38:20.064 EIF0303 : CALLING EIF TO SEND EVENT TO TEC
    TEC_
    10:38:20.065 EIF0304 : EIF RC=00000000
    TEC_
    
    This particular case, is when the RMF Gatherer and Event Pump
    STCs are started close enough, RMF Gatherer needs some time to
    collect data.
    Thus the "error" GPM0511I.
    Event Pump then unregisters the RMF exceptions, all of them.
    If I immediately manually re-register them, everything is ok.
    I think this scenario is similar to the WLM policy change;
    something expected that is taken as a fatal error by Event Pump
    thus unregistering the RMF feed. I do not think it should
    unregister the exceptions.
    

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All Tivoli Event Pump RMF event feed users.  *
    ****************************************************************
    * PROBLEM DESCRIPTION: Event Pump might process some temporal  *
    *                      RMF errors as a fatal errors and        *
    *                      un-register the RMF feed, e.g.          *
    *                                                              *
    *                      1. After a WLM Policy change occurred   *
    *                      and RMF returns GPM0504I to Event Pump, *
    *                      RMF exceptions will no longer be        *
    *                      monitored by Event Pump.                *
    *                                                              *
    *                      2. When the RMF Gatherer and Event Pump *
    *                      STCs are started close enough, RMF      *
    *                      Gatherer needs some time to collect     *
    *                      data. Thus the message GPM0511I is      *
    *                      issued. Event Pump then un-registers    *
    *                      the RMF exceptions.                     *
    ****************************************************************
    * RECOMMENDATION: Apply the PTF.                               *
    ****************************************************************
    Event Pump uses DDS to communicate with RMF.
    In case of error RMF returns one of GPM messages. The message
    is always Informative and Event Pump can not make a meaningful
    decision whether it is temporal or permanent problem.
    

Problem conclusion

  • Event Pump process has been modified to remove exceptions only
    when RMF sequentially returns the same message for it more than
    twice. E.g. in case of WLM change exceptions will be removed
    only after third consequential GPM0504I.
    

Temporary fix

Comments

APAR Information

  • APAR number

    OA42476

  • Reported component name

    EVENT PUMP FOR

  • Reported component ID

    5698B3400

  • Reported release

    422

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2013-06-06

  • Closed date

    2013-08-05

  • Last modified date

    2013-11-04

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

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

    UA70199

Modules/Macros

  • GPZRMFDE GTMAOPG2 GTMRX038
    

Fix information

  • Fixed component name

    EVENT PUMP FOR

  • Fixed component ID

    5698B3400

Applicable component levels

  • R422 PSY UA70199

       UP13/10/15 P F310

Fix is available

  • Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.



Rate this page:

(0 users)Average rating

Document information


More support for:

Tivoli Event Pump for z/OS

Software version:

422

Reference #:

OA42476

Modified date:

2013-11-04

Translate my page

Machine Translation

Content navigation