IMM returns success for deletion of an attribute value even if the value does not exist in the attribute.

[suresh]

IMM returns success for deletion of an attribute value even if the value does not exist in the attribute. This was observed for both single-valued and multi-valued attributes in PLM objects.

SA_IMM_CCB_REGISTERED_OI flag was not set in ccbflags during saImmOmCcbInitialize(), so that IMM Service accepts changes on objects with no registered implementer which was PLM service. The attribute "saPlmHEDeactivationPolicy" of SaPlmDomain? object initially has the value 2. PLM service was stopped and invoked the OM API saImmOmCcbObjectModify_2() with modType set to SA_IMM_ATTR_VALUES_DELETE and attrValue to be deleted set to 1 for this attribute. As the registered object-implementer PLM service was not running, IMM processed the modify request and returned success/SA_AIS_OK to saImmOmCcbObjectModify_2() even though the value to be deleted in the attribute is not present. However the immlist command on this object displayed the attribute having its value as 2.

Similar behavior was observed with a multi-valued attribute "saPlmHetIdr" in SaPlmHEType object.

Is it not expected that IMM should check the presence of the given value in the attribute.?

Following are the definitions of the attributes in PLM classes in both UML and IMM.xml.

Single-valued-attribute
=======================
saPlmHEDeactivationPolicy : SaPlmHEDeactivationPolicyT [0..1] = 2 (SA_PLM_DP_VALIDATE){CONFIG, WRITABLE, SAUINT32T}

<attr>

<name>saPlmHEDeactivationPolicy</name>
<type>SA_UINT32_T</type>
<category>SA_CONFIG</category>
<flag>SA_WRITABLE</flag>

</attr>

Multi-valued-attribute
=======================
saPlmHetIdr : SaStringT [0..*]{CONFIG, WRITABLE}

<attr>

<name>saPlmHetIdr</name>
<type>SA_STRING_T</type>
<category>SA_CONFIG</category>
<flag>SA_WRITABLE</flag>
<flag>SA_MULTI_VALUE</flag>

</attr>

[anders]

The IMM spec (A.02.01) is not totally clear on this but the current behavior is my
interpretation of what SAFintended and also what I believe is the "simplest" semantics
for the user.

The description for SA_IMM_ATTR_DELETE (botom of page 29 of IMM spec A.02.01) describes
the intention as "remove one or several specified values from an attribute of an object".
The "one or several" here referes to the input structure (not the attribute in the object).
So this paragraph does not clearly state what should happen if one or more of the input
values do not match any value in the attrbute. But my interpretation is: Remove all/any
occurences that match any of the input values. If some of the input values match none, then
that is ok.

We can also look at the error codes specified for saImmOmCcbObjectModify_2() page 79-81.
There is no errro code with a desscription matching what you describe.
The most likely candidatea would have been SA_AIS_ERR_NOT_EXIST or SA_AIS_ERR_INVALID_PARAM.

I also think the current interpretation of the spec is the most reasonable and convenient for
the user. The reply of SA_AIS_OK means the IMMSv has ensured that none of the input values
exist as values in the attribute. The fact that none may have existed even before the
operation was invoked should not mater.

I checked the latest IMMA.03.01 version on these points and it has not changed or made
any clarification.

Another completely separate issue is that you mention that SA_IMM_CCB_REGISTERED_OI was set
to false. This has no bearing on the semantics of the SA_IMM_ATTR_DELETE of the modify.
My general advice is for all OM users to always set the SA_IMM_CCB_REGISTERD_OI to true as
that gives the safest behavior. The only exception would be very special cases doubt that
your case was that special (or ?).
The semantics with the flag set to false is that if there is an implementer registered, it
will receive the relevant ccb-related-upcalls. If there is no implementer registerd, the
ccb proceeds anyway, which is unsafe and should be avoided.