[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

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

5310.0. "Child entities" by COMICS::MISTRY () Wed Jul 07 1993 07:18

Hi,

Just a quick query about child entites. If i register a snmp global entity and
then sometime later add a MIB and then register the corresponding child entity.
Where in DNS does Decmcc place this information.

Have registered a decmux called rbm380 as an snmp entity and enrolled a the dec
mib. I then register the mib

mcc> register snmp rbm380 dec


which runs through without any problems. If i then do

mcc>dir snmp rbm380 dec

it comes back with 

SNMP rbm380 dec
AT  7-JUL-1993 10:32:46

Directory successful.

so its found dec under rbm380 but where is it in DNS....

The reason i'm asking is because i have a customer who has just enrolled the
SINTROM_BRIDGE_MIBDEF.TXT and he does have sintrom bridges. Yet he is getting a
partial registration message, even though he can use the mib.

Bipin.

T.R	Title	User	Date	Lines
5310.1		MOLAR::YAHEY::BOSE	`Wed Jul 07 1993 16:37`	9
	Bipin, Just ignore the partial registraion message. The issue of SNMP entities and partial registration has been discussed elsewhere in this notes conference. In short, partial registration is normal for SNMP entities and any error messages regarding that should be ignored. Rahul.
5310.2	thanks	COMICS::MISTRY	`Thu Jul 08 1993 06:22`	6
	Thanks Raul, Any ideas about the second part, ie where in DNS the child entity info is kept. Bipin.
5310.3	stored as an attribute of the global parent	KAJUN::NELSON	`Thu Jul 08 1993 11:14`	15
	If you are using DECdns as your instance repository, child entity data is kept in an MCC-created DNS attribute of the global parent. The DNS attribute has an unpublished hex name and the value is ILV-encoded by the Registration FM. Information kept in the instance database is meant to be used by the Registration FM and other MMs using the mcc_dns_* routines. We don't publish the formats because this gives us the freedom to change the storage mechanisms/formats in the future. For example, none of the current MMs had to be recoded when we ported to ULTRIX and introduced the option of the local MIR, as the interface to the instance database stayed the same even though the underlying storage format changed. ...kjn
5310.4	Thanks	COMICS::MISTRY	`Fri Jul 09 1993 11:57`	6
	Hi, Thanks for the answer.. Bipin