Event Monitoring Service Version A.04.20.11.03, A.04.20.23.03, and A.04.20.31.03 Release Notes (March 2009)

Fixes in this Version
The following defects are fixed in this release:
• QXCR1000839941 - The EMS API rm_query_resource fails when running in a loop after
65535 iterations. This occurred due to a problem in the way request IDs are generated for
requests received by EMS. The request ID of a monitoring request is a 32 bit number. The
current PID of the monitor forms the first 16 bits and the other 16 bits denote a decimal serial
number. The decimal number loops from 0 to 65535 and then wraps around. If a persistent
request is registered with a monitor and in the same lifetime of the monitor the number of
non-persistent requests wraps around the 65535 mark there is a possibility that two requests
would have same ID. This causes the notifications from the second request to be directed
to the target defined by the first request. The RM_QUERY_RESOURCE() API would time out
waiting for a notification and return TIMEOUT error. This would continue until the monitor
was killed and restarted.
This problem is resolved to ensure that no two requests have the same ID, and if all the IDs
are used up, EMS rejects new requests.
Known Problems and Workarounds
The following are the known problems and workarounds:
• JAGaf19567 - EMS does not handle registering of persistent requests during boot time
correctly. This results in certain requests getting lost. Persistence files are set to zero if a user
tries to register the persistent requests during the boot phase.
This problem is resolved for emsgui and emscli client. However, this problem will continue
to exist for other clients.
• JAGag19389 - WBEM supports the feature of specifying the severity of an event. The severity
level can be critical, major, minor, warning, information, normal, and so on. However, when
emsgui or emscli is used to submit a wbem request, the ems client program does not allow
the user to specify the severity of the notification. By default the program sets the severity
to "Warning".
• QXCR1000814468 – EMSHAProvider registration fails if the WBEMServices version is earlier
than A.02.05. The registration of EMSHAProvider module fails during the configure phase,
when installing/updating EMS, if the version of WBEMServices product installed on the
system is earlier than A.02.05.
You can follow any of the following workarounds:
— Update the WBEMServices product to version A.02.05 or later before updating/installing
EMS.
— If EMS is already installed, user can update the WBEMServices product to version
A.02.05 or later and execute the following command:
# /opt/wbem/bin/cimmof -w -n root/PG_InterOp
/etc/opt/resmon/mof/EMSHAProviderR.mof
For more information on major changes in WBEM version A.02.05, see the HP-UX 11i Version
3 Release Notes: HP 9000 and HP Integrity Servers document on the HP Technical
Documentation website at http://docs.hp.com
Fixes in this Version 13