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

Obtain the fix for this APAR.

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 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.