HP WBEM Services Version A.02.09.14 Release Notes HP-UX 11i v2

Table 3 Defects fixed in HP WBEM Services Version A.02.09.xx (continued)
ResolutionDescriptionIdentifier
opt/wbem changed to root:sys then for next
cimserver start up, cimservermain will fall into
etc/opt/wbem and /etc/opt/wbem/
cimserver_start.conf is changed
to root:sys.
a deadlock loop resulting in 100 percent cpu
consumption. This is because the file /etc/
opt/wbem/cimserver_start.conf
becomes inaccessible.
Defects fixed in A.02.09.10
This defect is fixed in the current release.
The WBEM configure script is modified
When the swverify(1M) command is
executed with the (-x fix=true) option,
QXCR1001105601
to ensure that when the swverify
CIM Server becomes unstable. Subsequent
CIM Server start up fails.
command is executed with any options,
it does not change any file permissions
or affect CIM Server start up.
Defects fixed in A.02.09.08
This defect is fixed in the current release.
The cimauth command and the internal
According to the DMTF standards, the WBEM
namespaces are not case sensitive, but the
cimauth command processes namespaces
as case sensitive.
QXCR1001089629
WBEM data structures are modified to
ensure that the namespace case sensitive
error does not occur.
This defect is fixed in the current release.
A mutex has been added to ensure that
the race condition does not occur.
The StorageNative Provider module
hangs when it is continuously enabled and
disabled for one process, while
QXCR1001103470
EnumerateInstances is running for
StorageNative Provider in another
process. There is a race condition during the
provider shutdown.
This defect is fixed in the current release.
The destruction sequence is modified to
ensure that this defect does not occur.
The Pegaus core dump error occurs when the
StorageNative Provider module is
continuously enabled and disabled in one
QXCR1001106183
process, while EnumerateInstances is
running for StorageNative Provider in
another process. The core dump occurs due to
an incorrect destruction sequence in one of the
cimprovagt objects.
This defect is fixed in the current release.
The destruction sequence has been
Multiple instances of the cimprovagt
processes are created for one provider. This
QXCR1001095699
modified to ensure that cimprovagt
defect occurs when the StorageNative
waits for all provider threads to go down
Provider module is continuously enabled
before sending a success message to
cimservermain.
and disabled in one process, while
EnumerateInstances is running for
StorageNative Provider in another
process. When a 'disable' request is sent to a
provider, it hangs. The cimprovagt process
incorrectly assumes that the provider threads
are down and sends a successfully disabled
message to cimservermain. This causes
cimservermain to start a new cimprovagt
process for a new request.
This defect is fixed in the current release.
The response pointer is ensured to built
in all scenarios.
When disabling a provider module, WBEM
Services core dump occurs. The response
pointer to a client request is accessed beforeQXCR1001104350
building a response in certain scenarios, which
results in a core dump.
Defects fixed in A.02.09.06.01
Patches and fixes in this version 15