EMS Manual

Standard Events
EMS Manual—426909-005
9-28
Object Unavailable Event Tokens
Symptom
String
ZEMS-TKN-SYMPTOM-STRING (ZSPI-TYP-STRING,C)
Identifies where in the subsystem code the fault occurred. The information
should point to a specific subsystem code location, and the information
should remain unchanged for the same symptom from release to release of
the program code. The purpose is to use this symptom string to help
determine if a problem with similar symptoms has been reported previously.
The string is defined by the subsystem. It should be an ASCII string with this
information:

Release version update of the subsystem including version date and ID
that will uniquely identify a given piece of software.

Module name like the name of a procedure call where the fault occurred.
The module name should be unique within the subsystem.

Some identifier within the module name, like code statement label, where
the fault occurred.
Provide this token if the change reason (ZEMS-VAL-INTERNAL-FAILED)
indicates the error was encountered inside the subsystem.
Underlying
Object
Name
ZEMS-TKN-UNDERLYING-OBJ-NAME (ZSPI-TYP-STRING,C)
Indicates the name of the underlying object whose failure caused the object
reported in the subject of this event to go out of service. It should be a fully
qualified file name.
If the change reason is ZEMS-VAL-UNDERLYING-FAILED, this token must
be present to indicate the name of the underlying object. Otherwise this token
must not be present.
The name of the underlying object is the operating system object name—like
process name, file name, or subdevice name—that the subject of this event
communicates with. In most cases, this name alone is sufficient to identify
uniquely the underlying object name that the subject of this event depended
on. If not, the subsystem should provide additional tokens to uniquely identify
the underlying object and describe how a management application can isolate
the actual cause of the problem in these events.
Private
Tokens
Additional event-specific tokens should be provided by subsystems that could
help the operator diagnose the problem (for example, system procedure error
code, network disconnect reason code, error information from underlying
subsystem, and so on).