T.R | Title | User | Personal Name | Date | Lines |
---|
2162.1 | DNS_IDENT = NOT_USED for attributes not for lookup | TOOK::TAN | Ed Tan | Thu Jan 23 1992 12:29 | 44 |
| I believe you are running DECmcc V1.1, because the
REGISTRATION FM in V1.2 EFT no longer returns the DUP_IDENTIFIER message.
You have one fullname identifier Equipement defined as DNS_IDENT =
PRIMARY_NAME and that is fine. The attribute Identification is defined
as DNS_IDENT = ALTERNATE_NAME and that is fine too.
Since you are not using the attributes Domaine, Zone, Type and
Reference in the Identifier list
IDENTIFIER = (Equipement,Identification)
you probably do not want to identify an entity instance using
either one of them. And you probably can't since they are not unique
among your potential entity instances.
Since you did not specify DNS_IDENT for Domaine, Zone, Type and
Reference, the default is DNS_IDENT = ALTERNATE_NAME. This causes
problem with registration as follows.
For each alternate identifer (DNS_IDENT = ALTERNATE_NAME),
REGISTRATION FM (Config FM in V1.1) will call a kernel routine to
create a backtranslation link for it in the namespace. And these
backtranslation links for your entity class must be unique in the
namespace.
So say the first time you register one SARE entity instance with
TYPE = FOO, that is fine and registration will be successful as you
observed. The second time you register another SARE entity instance
with difference fullname but with same TYPE = FOO, the DUP_IDENTIFIER
error will be returned by the kernel routine because a backtranslation
link with that name is already in the namespace.
So, to make a long story short and solve your problem, you should
define DNS_IDENT = NOT_USED for each of the four attributes Domaine,
Zone, Type, Reference. This way, all six attributes will be created
during registration (as long as you returned them in your SHOW AM
IDENTIFIER entry point), but backtranslation link created only for the
Identification attribute.
/Ed
|
2162.2 | DUP_IDENTIFIER with V1.2.3 | BALZAC::MARKOWSKI | | Tue Jan 28 1992 04:04 | 11 |
|
Hello Ed,
Thank's a lot for explanation and solution. Now it works perfectly.
May be this indication will interest you, I am running DECmcc
V1.2.3.
Regards,
sylviane.
|
2162.3 | Does not return DUP_IDENTIFIER in latest kit | TOOK::TAN | Ed Tan | Tue Jan 28 1992 09:54 | 7 |
| You say you are running a version called V1.2.3. When is the kit
produced and when is it installed on your system? Maybe I am confused.
Are you using the latest kit? Anyway, in the latest kit, which is the
V1.2 external field test, REGISTRATION FM does not return
DUP_IDENTIFIER error.
/Ed
|
2162.4 | V1.2.3 must be a typo | TOOK::MINTZ | Erik Mintz, DECmcc Development | Tue Jan 28 1992 10:14 | 5 |
| > You say you are running a version called V1.2.3. When is the kit
V1.2.3 does not exist. T1.2.3 would be the internal field test kit.
T1.2.4 is the latest (supported) EFT kit.
|
2162.5 | Identifiers are alternate names | BLUMON::SYLOR | Architect = Buzzword Generator | Tue Jan 28 1992 20:55 | 10 |
| Ah - perhaps I misunderstood, but .0 seemed to say that all 4
attributes were required to uniquely identify a SARE. Sorry, that's not
allowed. *Each* identifier must uniquely identify the entity. They are
*alternative* names for an entity.
For cases where 4 "values" or "keys" are needed to identify an
instance, the normal solution is to construct a RECORD out of the
fields as a new type, and define an identifier of that data type.
Mark
|
2162.6 | DECmcc BMS and TK T1.2.3.(IFT) | BALZAC::MARKOWSKI | | Thu Jan 30 1992 04:06 | 16 |
|
RE:.3
RE:.4
We have installed the DECmcc BMS and TK T1.2.3 (IFT) announced in note
3.117.
RE:.5
Thank's for your solution. As I said in .1, Ed's answer has fixed my
problem but I'll try your solution too.
Regards,
sylviane.
|
2162.7 | Need more info on multiple identifier attributes | STAR::ALLISON | | Fri Feb 21 1992 13:11 | 41 |
| I'm running T1.2.4 and have the following partial MSL with multiple
identifier attributes. If I enter CREATE NODE 0 MOMGEN TEST 1234 at
the FCL prompt, the data is still interpreted as a Simplename.
How can I specify an Integer32 as an identifier attribute? Or is this
documented somewhere that I haven't found yet?
Thanks,
Gary
MANAGEMENT SPECIFICATION example;
VERSION = X0.0.1;
SYMBOL-PREFIX = MGT_;
CHILD ENTITY MOMGEN TEST = 9990 :
PARENT = (NODE),
IDENTIFIER = (Name, Number),
SYMBOL = CLASS_MOMGENTEST,
IDENTIFIER ATTRIBUTES
ATTRIBUTE Name = 1 : Simplename
ACCESS = NONSETABLE,
DISPLAY = TRUE,
CATEGORIES = (CONFIGURATION)
END ATTRIBUTE Name;
ATTRIBUTE UID = 2 : UID
ACCESS = NONSETABLE,
DISPLAY = TRUE,
CATEGORIES = (CONFIGURATION)
END ATTRIBUTE UID;
ATTRIBUTE Number = 3 : Integer32
ACCESS = NONSETABLE,
DISPLAY = TRUE,
CATEGORIES = (CONFIGURATION)
END ATTRIBUTE Number;
END ATTRIBUTES; (* IDENTIFIER *)
|
2162.8 | Try this... | CHRISB::BRIENEN | DECmcc Bridge|Station|SNMP Management. | Fri Feb 21 1992 15:15 | 7 |
| Change the line:
IDENTIFIER = (Name, Number),
to:
IDENTIFIER = (Number, Name),
|
2162.9 | | STAR::ALLISON | | Fri Feb 21 1992 15:42 | 4 |
| Ok, but will that still allow me to specify the name as well? I need
to be able to specify both...
THanks.
|
2162.10 | Yes. | CHRISB::BRIENEN | DECmcc Bridge|Station|SNMP Management. | Fri Feb 21 1992 16:55 | 3 |
| With the change, any identifier that doesn't satify the
syntactic requirements for Integer32 (i.e. characters '0' thru '9')
should be interpreted as Name.
|