IZ45193: TEMS STORAGE LEAK AFTER AGENT SWITCHING

APAR status

• Closed as program error.

Error description

• Environment:
  TEMS ITM 6.2 FP1, Windows. No IF patches applied
    latest maintenacne is not involved
  
  Problem Description:
    When a hub TEMS is doing remote SQL to a remote TEMS, and that
  SQL request times out, the pending data is never freed up.
  
    This occured most often when the client caused a mass agent
  switch by stopping the primary remote TEMS, then starting the
  primary, and then stopping the secondary remote TEMS and
  restarting the secondary remote TEMS. The goal was to get all
  the agents connected to the primary. This always led to a
  storage increase at the hub TEMS and several times it   was
  dramatic - for example rising from 500meg to 1380meg in a few
  minutes.
  
    This environment had roughly 3400 agents and 38000 active
  situation instances.
  
  
  Detailed Recreation Procedure:
     See above
  
  Related Files and Output:
    There are many logs/dumps/etc in the ecurep for PMR
  70910,082,000.
  
  Note: R&D enginer CF noted during the discussion
  
  The /* @ctfd26560 */ change needs to be applied to kfaiblod that
  is present in kfaixlod
  
  and a fuller briefing will be emailed to L3.
  

Local fix

• avoid mass agent switching
  

Problem summary

• Memory leaks were uncovered in the hub TEMS when attached remote
  TEMS are running on slow performing machines, especially under
  VMWare.  The memory growth is most likely to occur when the hub
  TEMS loses communication with an remote TEMS in a slow
  performing environment and the agents belonging to the
  remote TEMS switch to another TEMS.  A large number of agents
  attached to the remote TEMS along with a large number of
  situations and distributions is usually involved.
  
  This problem appears to more easily occur on the IBM Tivoli
  Monitoring 6.2.0 release.  It appears less likely on the 6.2.1
  release.
  

Problem conclusion

• The hub TEMS expects a remote TEMS to pull all queued records
  resulting from an SQL request within a two minute timeframe.  If
  this did not occur, the SQL request would timeout, but queued
  records were not being released.  The code has been modified to
  release queued records when a timeout occurs.
  
  
  The fix for this APAR is contained in the following maintenance
  packages:
  
     | fix pack | 6.2.0-TIV-ITM-FP0003
  

Temporary fix

• Recycle the HUB to release the allocated storage.
  

Comments

APAR Information

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

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

  OA28781 OA29268

Fix information

• Fixed component name

  TEMS

• Fixed component ID

  5724C04MS

Applicable component levels

• R620 PSY

     UP