IV08011: MIRROR TEMS CONNECTS TO RTEMS.

IBM Tivoli Monitoring 6.2.2 Fix Pack 8 (6.2.2-TIV-ITM-FP0008)
IBM Tivoli Monitoring 6.2.2 Fix Pack 9 (6.2.2-TIV-ITM-FP0009)

APAR status

• Closed as program error.

Error description

• If a Mirror TEMS is started, it makes connections to RTEMS
  as part of Remote Deploy initialization processing. Those
  connections are redundant and need not exist since only
  when a TEMS is active and acting as the HUB are status
  updates to the KDYDYSTS table necesary.
  
  We have an environment with 2 Hubs in FTO mode at ITM622 FP5
  
  First the Backup Hub is stopped and the Rtems are connected
  to the Primary hub (h03 n1.n1.17.15).
  
  Then the Backup Hub (h04 n1.n1.17.16) is started.
  We can see in netstat that the Backup hub opens a connection
  to each of four Rtems (n2.n2.13.13 - n2.n2.13.16).
  
  
  [root@h04 bin]# netstat -anp | grep kdsmain | grep n2.n2.13
  tcp        0      0 n1.n1.17.16:xxxxx          n2.n2.13.14:
  1918           ESTABLISHED 9037/kdsmain
  tcp        0      0 n1.n1.17.16:xxxxx          n2.n2.13.16:
  1918           ESTABLISHED 9037/kdsmain
  tcp        0      0 n1.n1.17.16:xxxxx          n2.n2.13.13:
  1918           ESTABLISHED 9037/kdsmain
  tcp        0      0 n1.n1.17.16:xxxxx          n2.n2.13.15:
  1918           ESTABLISHED 9037/kdsmain
  RECREATE:
  Install 2 Hubs in FTO mode at ITM622 FP5
  
  First the Backup Hub is stopped and the Rtems are connected to
  
  the Primary hub (h03 n1.n1.17.15).
  Then the Backup Hub (h04 n1.n1.17.16) is started.
  We can see in netstat that the Backup hub opens a connection to
  each of four Rtems (n2.n2.13.13 - n2.n2.13.16) as shown in
  above description.
  

Local fix

Problem summary

• When the switch is made from a MIRROR management server back to
  the HUB management server, Remote Deploy maintains connections
  and interacts with all the remote management servers that were
  connected to the MIRROR management server after the MIRROR is no
  longer processing Deployment requests.
  
  Remote Deploy does not make distinctions in its processing
  whether it is running on a HUB or MIRROR management server.  As
  a result, Remote Deploy persists connections to the enterprise's
  remote management server from the MIRROR management server even
  if the MIRROR is no longer acting as the HUB.  Additionally
  Remote Deploy on the MIRROR continues to use the connections to
  update its tables, even though the HUB management server is
  supposed to be the controller of Deployment status table
  (KDYDYST) contents.
  

Problem conclusion

• Make Remote Deploy aware if it is running on the MIRROR or HUB
  management server.  If it is acting as the MIRROR, then it will
  communicate with the HUB management server to keeps its KDYDYST
  table in parity with the HUB table's contents.
  
  
  The fix for this APAR is contained in the following maintenance
  packages:
    | fix pack | 6.2.2-TIV-ITM-FP0008
    | fix pack | 6.2.3-TIV-ITM-FP0002
  

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:

Fix information

• Fixed component name

  TEMS

• Fixed component ID

  5724C04MS

Applicable component levels

• R622 PSY

     UP