EMS Manual

Standard Events
EMS Manual—426909-005
9-15
Object Name for Underlying Object
Object Name for Underlying Object
When an object that a subsystem communicates with directly, but that is defined and
controlled in another subsystem, goes out of service, an Object Unavailable event is
reported. If the object went out of service because another object that this object
depended on has became unavailable, the name of the other object should be in the
event message. Management applications use this name to locate the Object
Unavailable events reported by other subsystems and applications that contain the
actual cause of the problem.
For example, subsystems A, B, and C have objects a1, b1, and c1, respectively; and
the availability of c1 depends on the availability of b1, which in turn depends on a1:
When object a1 becomes unavailable because of some internal error, object b1 is
taken out of service because its underlying object a1 is not available. Likewise, object
c1 is taken out of service because its underlying object b1 is not available. These
Object Unavailable events are reported to EMS:
Subsystem A: subject=a1 cause=internal error
Subsystem B: subject=b1 cause=underlying obj failed
underlying object name=a1
Subsystem C: subject=c1 cause=underlying obj failed
underlying object name=b1
The Object Unavailable event for c1 is linked to the Object Unavailable event for b1
because the underlying object name in event c1 is the same as the subject name for
event b1. Likewise, event b1 is linked to the Object Unavailable event for a1. Because
event a1 contains the actual cause of the problem, further linking of related events is
no longer necessary.
For a subsystem or application using the service of an underlying object, the name of
the underlying object reported in the Object Unavailable event must be the name used
to establish communication between itself and the provider of the underlying object:

If File System FILE_OPEN_ alone is needed to establish communication with the
underlying object, the name used in the FILE_OPEN_ should be the name for the
underlying object.

If File System FILE_OPEN_ plus other mechanisms are needed to establish
communication with the underlying object (for example, a multithread server might
require an additional internal name to identify the thread of communication), the
name used in the FILE_OPEN_ procedure, plus any internal names, should be the
name for the underlying object. One or more tokens in the event can represent the
internal names.
002
subsystem C
object c1
subsystem B
object b1
subsystem A
object a1