---
** [tickets:#1064] IMM: OiRtObject operations whith no implementer set should
return BAD_OPERATION**
**Status:** unassigned
**Milestone:** 4.6.FC
**Created:** Thu Sep 11, 2014 10:40 AM UTC by Anders Bjornerstedt
**Last Updated:** Thu Sep 11, 2014 10:40 AM UTC
**Owner:** nobody
It is currently the case that if a process:
1) Initializes an IMM-OI handle.
2) Has not set any implementer-name, i.e. has not yet (?) become any
identifiable OI.
3) Tries to use the oi-handle to create/delete/update runtime data.
Then the resulting error code returned will be ERR_BAD_HANDLE.
This is actually according to the SAF spec. But I claim this is both
inconvenient and a spec error.
Why is it a spec error ?
Well ERR_BAD_HANDLE should at least mean that the handle as such is bad,
i.e. unusable for whatever reason. That is the literal meaning of that error
code.
But in *this* error case discussed here the handle is actually not bad and
can even be used after this happens for e.g. saImmOiImplementerSet, i.e. to
associate an implementer-name with the handle, the lack of which was the cause
of this particlar problem.
The correct error code for this case I claim is ERR_BAD_OPERATION.
ERR_BAD_OPERATION -
The targeted object is not implemented by the invoking process
In contrast for ERR_BAD_HANDLE the SAF text is here self contradicting:
The handle immOiHandle is invalid, since it is corrupted, uninitialized,
has already been finalized, or is not associated with an implementer name.
The last clause 'not associated with an implementer-name' is a VALID state
for an OI handle that has been initialized but not associated with an
implementer-name! That is in fact the state of the handle demanded by
saImmOiImplementerSet. So it is not the handle that is invalid, but the
state of the (valid) handle that is not (yet) appropriate for RT operations.
The error code BAD_OPERATION (on the other hand) is defined for
saImOiRtObjectUpdate and saImmOiRtObjectDelete. Unfortunately SAF did not
specify that error code for saImmOiRtObjectCreate.
So this will be a *new* error code for saImmOiRtObjectCreate.
Fortunately there is not really any backwards compatibility issue for this
change of error code. The error case is an interface-vilolation, by definition
a surprise for the user/application. So it is actually acceptable, even
desirable (fail fast) for the client process to crash when this happens.
The client process has a bug.
An addition will be made to the "non compliance" section of the IMMSV_PR
and the IMMSV README to make this clear.
This new behavior is benign and better than the current behavior.
Yes it may be an unexpected error code for the application/user. But since
this is an interface violation (user/programmer error) the error case itself
is unexpected.
---
Sent from sourceforge.net because [email protected] is
subscribed to https://sourceforge.net/p/opensaf/tickets/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list.------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Opensaf-tickets mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
