Writing Monitors for the Event Monitoring Service (December 1999)

30 Chapter2
The EMS Application Programming Interface (API)
Functions
One of the first tasks a resource monitor developer has is to decide what
type of resource the resource monitor will be written to monitor. For
RM_NOT_READY RM_NOT_READY has been implemented for the
subclass reply and the monitor reply. This means that
RM_NOT_READY can be specified as either of the
following in order to indicate that the monitor is
temporarily unable to satisfy this request:
• a valid ResourceType in the subclass reply
object
• a valid RmMonitorReply in the monitor reply
object
In these cases, the monitor could return
RM_NOT_READY, back to the client via an
rm_send_reply. This would signal to the client that
the monitor is temporarily unable to complete the
request; the client might now decide to terminate,
possibly retry the request, or go on to the next
resource. Cases where this might be useful include
situations where there are large numbers of instances
below a subclass, such as discovering all disk devices
under a given volume group, or all files under a given
directory; the discovery is proceeding normally but it
may take longer than expected, in which case,
RM_NOT_READY is returned.
RM_RESOURCE_
CLASS_TYPE
The resource is a resource class, which is used to hold
other resource classes and/or resource instances.
RM_SBIT32_TYPE The resource is a signed 32-bit integer.
RM_SBIT64_TYPE Reserved for future use.
RM_STRING_TYPE The resource is a string of characters with a
terminating NULL byte.
RM_UBIT32_TYPE The resource is an unsigned 32-bit integer.
RM_UBIT64_TYPE Reserved for future use.
Table 2-3 Resource Types
Type Description