| I would answer part of the question on how registration process works.
The following is true for DECmcc V1.1. If anything fails during the
registration process, things that are done successfully before the failure
will be rolled back to the initial state.
In V1.2, the registration algorithm will be changed to allow for
registering unreachable/no-existent/... entities.
The algorithm below is true for registering any global entity in
general. Since each AM can optionally have a REGISTER entry point (which will
be called during the registration of global entity), what each AM does when
it is called varies. Since the AM SHOW ALL CHARACTERISTICS and SHOW ALL
IDENTIFIER entry points are called during registration, the resources used and
traffic generated depends on what the AM manages and how it communicate with
the managed object.
When user register a global entity, and I take a node4 entity for
example,
REGISTER NODE4 .BEDTIM SYNONYM BEDTIM
the following things happen:
1. Some checking and validation (which I won't go into details, unless you
would like to know)
2. Call kernel routine mcc_dns_create_instance to create an entry in the DNS
namespace. In this case, the object .BEDTIM in it.
DNS> show object .bedtim
Attribute (Set) ______ DNS$ACS
Attribute (Single) ___ DNS$Class
Attribute (Single) ___ DNS$ClassVersion
Attribute (Single) ___ DNS$UID
Attribute (Single) ___ DNS$UTS
Attribute (Set) ______ MCC_Class
Attribute (Single) ___ MCC_UID
Attribute (Set) ______ MCC_Version
3. Call the AM REGISTER entry point (if any, it is optional) to allow the AM
to do whatever it needs.
For node4, it creates the attribute DNA$NodeSynonym in object .bedtim in DNS
and create a backtranslation link in .dna_nodesynonym to point to .bedtim
DNS> show object .bedtim
Attribute (Single) ___ DNA$NodeSynonym
Attribute (Set) ______ DNS$ACS
Attribute (Single) ___ DNS$Class
Attribute (Single) ___ DNS$ClassVersion
Attribute (Single) ___ DNS$UID
Attribute (Single) ___ DNS$UTS
Attribute (Set) ______ MCC_Class
Attribute (Single) ___ MCC_UID
Attribute (Set) ______ MCC_Version
DNS> show object .bedtim attribute DNA$NodeSynonym
Member _ 0
(Hexadecimal):
01 06 62 65 64 74 69 6d
(ASCII and Hexadecimal):
01 06 b e d t i m
Timestamp _ 27-JUN-1991 15:21:46.91 aa-00-04-00-07-13
DNS> show link .dna_nodesynonym.bedtim
Attribute (Set) ______ DNS$ACS
Attribute (Single) ___ DNS$LinkTarget
Attribute (Single) ___ DNS$LinkTimeout
Attribute (Single) ___ DNS$UID
Attribute (Single) ___ DNS$UTS
DNS> show link .dna_nodesynonym.bedtim attribute DNS$LinkTarget
Target __________________ MCC1_NS:.bedtim
Timestamp _ 27-JUN-1991 15:21:46.74 aa-00-04-00-07-13
4. Call the AM SHOW ALL IDENTIFIER entry point to get all the
identifiers of that global entity. For node4, we get back the DECnet IV
name (bedtim) and DECnet IV address (4.436).
5. For each identifier which is not the same as the identifier used in step 2
to create an entry in DNS, call kernel routine mcc_dns_add_identifier to
add it to DNS. For node4 DECnet IV name (bedtim), since it is already added
by the AM in step 3, mcc_dns_add_identifier returns success. For DECnet IV
address, the attribute DNA$TOWERS is created in object .bedtim and a
backtranslation link is created in .dna_backtranslation.%X49.%X0004 to point
to .bedtim
DNS> show object .bedtim
Attribute (Single) ___ DNA$NodeSynonym
Attribute (Set) ______ DNA$TOWERS
Attribute (Set) ______ DNS$ACS
Attribute (Single) ___ DNS$Class
Attribute (Single) ___ DNS$ClassVersion
Attribute (Single) ___ DNS$UID
Attribute (Single) ___ DNS$UTS
Attribute (Set) ______ MCC_Class
Attribute (Single) ___ MCC_UID
Attribute (Set) ______ MCC_Version
DNS> show object .bedtim attribute DNA$TOWERS
Member _ 0
(Hexadecimal):
04 00 02 00 01 13 00 00 01 00 02 02 00 00 13 01 00 04 00 00 01 00 06 0a 00 49 0
0 04 aa 00 04 00 b4 11 20
(ASCII and Hexadecimal):
04 00 02 00 01 13 00 00 01 00 02 02 00 00 13 01 00 04 00 00 01 00 06 0a 00 I 00
04 � 00 04 00 11
Timestamp _ 27-JUN-1991 15:43:01.14 aa-00-04-00-07-13
DNS> show link .dna_backtranslation.%X49.%X0004.%XAA000400B411 attribute DNS$Lin
kTarget
Target __________________ MCC1_NS:.bedtim
Timestamp _ 27-JUN-1991 15:43:00.65 aa-00-04-00-07-13
6. If the global entity class has variant selector(s) defined, call the AM
SHOW ALL CHARACTERISTICS entry point and get all the characteristic
attributes. For each of the characteristic attribute which is defined to be
a variant selector, call kernel routine mcc_dns_write_attr_data to write
it to DNS.
7. For each of the global entity's subentity class which is marked for
auto-registration (with DYNAMIC = FALSE in the subentity's management
specification), register all the instances of this subentity class. (this
auto-registration is then done recursively, in that the subentity classes,
if any, of this auto-registered subentity are checked if they should be
auto-registered as well, and so on...)
The registration process for the auto-registered subentities is:
- Call AM SHOW ALL IDENTIFIER entry point to get all the instances
of this subentity one at a time using wildcard
- For each instance, call kernel routine mcc_dns_create_instance to
create an entry in DNS
- Call kernel routine mcc_dns_add_identifier to add all alternate
identifiers of this instance if any to DNS
- If there are variant selector(s) defined for this subentity class,
call AM SHOW ALL CHARACTERISTICS entry point and get all
characteristic attributes. For each characteristic attribute that
is a variant selector, call kernel routine mcc_dns_write_attr_data to
add it to DNS.
|