| Title: | DECmcc user notes file. Does not replace IPMT. |
| Notice: | Use IPMT for problems. Newsletter location in note 6187 |
| Moderator: | TAEC::BEROUD |
| Created: | Mon Aug 21 1989 |
| Last Modified: | Wed Jun 04 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 6497 |
| Total number of notes: | 27359 |
Hello,
Context: PNM200 V1.3 on Ultrix
Local Namespace
Developer's toolkit
Customer developped AM which talks to a proxy agent
Problem:
In MSL, we have a secondary identifer which is used to identify the
proxy agent we want to talk to. When we modelled the object, we
specified a unique object identifier as a primary ident, and we model the
agent's name (datatype: Latin1 string) as an identifier attribute, but
with DNS_IDENT = NOT_USED so as to (theoretically) allow duplicates, as
several objects will be accessed through the same agent. This was done
so as to have the "real" objects as global entities on the map. The
agent's name is passed as an argument of the REGISTER directive, and
the REGISTER entry point stores it in the local namespace using the
mcc_dns_write_attribute_data routine.
When we register two objects of the same class, with different primary
idents, but with the same agent name, our code (register entry point +
show all ident entry point) runs ok, but the registration fails with a
DUPLICATE IDENTIFIER error message.
We guess that it's the agent's name which is stored in the local
namespace, despite the "NOT_USED" clause... Is this a bug?
As a workaround, I suggested to the customer that we move the agent's
name to the Characteristics partition. He will try this out, but I
don't find this satisfactory.
Has anyone else used the DNS_IDENT=NOT_USED clause and experienced
problems with it?
Regards,
Philippe.
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 5571.1 | Known behavior | TAEC::LAVILLAT | Tue Sep 07 1993 08:03 | 60 | |
Philippe,
A few answers, hope this helps...
>
> In MSL, we have a secondary identifer which is used to identify the
> proxy agent we want to talk to. When we modelled the object, we
> specified a unique object identifier as a primary ident, and we model the
> agent's name (datatype: Latin1 string) as an identifier attribute, but
> with DNS_IDENT = NOT_USED so as to (theoretically) allow duplicates, as
> several objects will be accessed through the same agent. This was done
> so as to have the "real" objects as global entities on the map. The
> agent's name is passed as an argument of the REGISTER directive, and
> the REGISTER entry point stores it in the local namespace using the
> mcc_dns_write_attribute_data routine.
>
It seems that your agent name is more a characteristic attribute than
an identifier. Do you plan to identify an object via its agent name ?
> When we register two objects of the same class, with different primary
> idents, but with the same agent name, our code (register entry point +
> show all ident entry point) runs ok, but the registration fails with a
> DUPLICATE IDENTIFIER error message.
>
> We guess that it's the agent's name which is stored in the local
> namespace, despite the "NOT_USED" clause... Is this a bug?
>
Bug or feature ?
> As a workaround, I suggested to the customer that we move the agent's
> name to the Characteristics partition. He will try this out, but I
> don't find this satisfactory.
>
I do not see any inconvenient for this. Do you plan to use dns
routines calls to retrieve remotely the agent name ?
> Has anyone else used the DNS_IDENT=NOT_USED clause and experienced
> problems with it?
>
Yes. We had the same problem.
In fact we had this problem twice : the first time we *had* to use the
identifier partition since we wanted to allow remote access for our
objects.
This was for the Trouble Ticket Context object. We have implemented a
patch consisting in building a unique identifier by concatenation of the
object name and the node name (node name being the equivalent here of your
agent name) so we have : "<nodename>::<object_name>" which is unique.
The second time, we realized that in fact what was needed was a
characteristic attribute.
Regards.
Pierre.
| |||||
| 5571.2 | EVTIS9::ROGGEBAND | Unplugged | Tue Sep 07 1993 10:16 | 8 | |
Thanks Pierre,
Moving the attribute to the char partition worked, so the customer is
(fairly) happy.
Amicalement,
Philippe
| |||||