| 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 |
I do not understand the usefullness of REGISTER directive for Bridge
protocols. The only thing different that I noticed is that you are able
to take a directory of protocol(s) after registering the protocol(s),
regardless if the bridge is available or not. Is there some hidden benefit
that I am missing? I believe that it would be usefull if it also stored
the filtering information. That way I wouldn't have to keep bridge
configuration files in case the hardware failures.
Mike
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 3616.1 | No hidden benefits. | CHRISB::BRIENEN | DECmcc LAN and SNMP Stuff... | Thu Aug 27 1992 21:05 | 17 |
I believe the REGISTER directive is provided for all of the child entities of a Bridge. There is no hidden benefit (other than support for display of children on a MAP), while the cost of implementation was low (Registration FM provides the function automatically if you define REGISTER in the dictionary). Registering of manager-created Forwarding (and Protocol) entries does provide a (clumsy) means of storing this information - visible with the DIRECTORY command when the Bridge is "unreachable". Storing the filtering information is a great idea! The ability to store a bridge's settable characteristics plus user created forwarding entries and protocol entries, and use these to set up a new bridge, would be a nice function to add to the AM. Short term workaround is (argh) manual creation of command files with SET and CREATE directives. Chris | |||||