OA29268: TEMS STORAGE LEAK AFTER AGENT SWITCHING

Obtain the fix for this APAR.

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

• ****************************************************************
  * USERS AFFECTED: All TEMS users.                              *
  ****************************************************************
  * PROBLEM DESCRIPTION: Memory creep in TEMS                    *
  ****************************************************************
  * RECOMMENDATION: Apply the PTF.                               *
  ****************************************************************
  Memory leaks in TEMS when attached RTEMS are running on
  slow performing machines, especially under VMWare. The
  memory growth is most likely to occur when the HUB loses
  communication with an RTEMS in a slow performing environment
  and the agents belonging to the RTEMS switch to another
  TEMS. A large number of agents attached to the RTEMS along
  with a large number of situations exacerbates the problem.
  

Problem conclusion

• The HUB expects an RTEMS to pull all queued records resulting
  from an SQL request within a two minute time frame. 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.
  

Temporary fix

Comments

APAR Information

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

  IZ45193

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

Modules/Macros

• KFACOM
  

Fix information

• Fixed component name

  MGMT SERVER DS

• Fixed component ID

  5608A2800

Applicable component levels

• R621 PSY UA47841

     UP09/06/15 P F906

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.