A Deleted Object Is Redisplayed When Two Hot Standby (Fto) Hubs Reconnect; Troubleshooting Monitoring Server Problems On Z/Os Systems; Receive Program Kdfcinit And Program Faxcmon Messages - IBM E027SLL-H - Tivoli Monitoring - PC Troubleshooting Manual

A deleted object is redisplayed when two hot standby (FTO)
hubs reconnect
You might notice that a deleted object, such as a situation or policy, is redisplayed
when two FTO hub Tivoli Enterprise Monitoring Servers reconnect. This behavior
occurs when the mirror hub has been promoted to serve as the acting hub before
reconnecting.
An example of a deleted object is a situation, policy, SDA option, override, or
calendar. Either of the following scenarios demonstrates this behavior:
Role switch
Temporary disconnect

Troubleshooting monitoring server problems on z/OS systems

Review the problems you might experience with Tivoli Enterprise Monitoring
Server on z/OS and the provided resolutions.
These are problems that occur during runtime that you can resolve with the z/OS
Configuration Tools (PARMGEN Workflow User Interface and ICAT Configuration
Tool).
For more information about configuring the monitoring server on z/OS, see
Configuring the Tivoli Enterprise Monitoring Server on z/OS (http://
publib.boulder.ibm.com/infocenter/tivihelp/v15r1/topic/
com.ibm.itm.doc_6.2.3fp1/itm623fp1_zconfigtems.htm).
Receive Program KDFCINIT and Program FAXCMON
messages
"Program KDFCINIT with task id 8 ended" and "Program FAXCMON with task id
7 ended" messages are generated in the IBM Tivoli Monitoring z/OS Tivoli
Enterprise Monitoring Server RKLVLOG if either or both IBM Tivoli OMEGAMON
XE on z/OS and OMEGAMON XE for Storage on z/OS are running in the
monitoring server address space. These are informational messages that report on
internal task terminations which in turn help identify non-terminating internal
tasks. These messages are benign.
166
IBM Tivoli Monitoring: Troubleshooting Guide
The acting hub and mirror were connected initially, and the hub is
stopped. The mirror becomes the new acting hub. An object is deleted
from the new hub. The original hub is started and becomes the new
mirror. Shortly after reconnection, the deleted object reappears on the new
hub.
The hub and mirror were connected initially and then lost connection. The
disruption lasts long enough for the mirror to promote itself to the role of
acting hub. While still disconnected, an object is deleted from the original
hub. When the connection is restored, the object reappears on the original
hub. The object does not reappear if the mirror had not promoted itself.