Conference azur::mcc

3681.0. "QUESTION: DECmcc V1.2 - DECdns vs. Local Instance Repository" by BIS1::COLLEYE () Thu Sep 03 1992 05:04

Greetings,

We are using DECmcc V1.2 and we have a question regarding
the use a local instance repository vs. DECdns.

I did not find a lot of information in the Installation Guide, but
found some information in the Release Notes that I have extracted
and attached below.

I shall now explain which entities we intend to register
in our configuration and the underlying question is:

"IS WHAT WE INTEND TO DO POSSIBLE WITH A LOCAL INSTANCE
REPOSITORY ? "

- we intend to register domain entities with instance name
  .<directory>.<sub_directory>.<domain_name>

- we intend to register reference entities with instance
  name
  .<directory>.<sub_directory>.<reference_name>

- we intend to register collector entities with instance
  name
  .<directory>.<sub_directory>.<collector_name>

- we intend to register the node 4 entity where 
  DECmcc is installed. This node 4 entity
  will have the instance name
  .<directory>.<node_name>
  This node 4 entity will have as a child entity 
  (class object) the mcc event sink (MCC_EVC_SINK)
  that we need to create
  (MCC> CREATE NODE4 <node4_intance_name> OBJECT MCC_EVC_SINK ...)
  or to control
  (MCC> SHOW CREATE NODE4 <node4_intance_name> OBJECT MCC_EVC_SINK ALL ATTR)
  We also intend to use this node4 entity to collect some
  attributes at regular pooling interval.
  Finally, it is used to start up the event logger
  (procedure MCC_STARTUP_DNA4_EVL.COM)

- we intend to register one MCC entity to represent the
  current director (only one DECmcc installation).
  This MCC entity will have the instance name
  .<directory>.<sub_directory>.<mcc_name>
  We intend to use this entity to enable/disabe
  the mcc event sink (MCC_EVC_SINK).
  Once enabled, the event sink should collect
  events from entitites through the network.


We are currently using this configuration with
DECmcc storing the instance information in DECdns.

Despite I could not find any evidence in the attached documentation 
that what we intend to do (including the instance names format we are
using) is not possible using a local instance repository
as an alternative to DECdns, taking into account the
criticality of the application this above configuration
is set-up for, before making the step to install DECmcc
without DECdns, I would like to be *sure* that I have not missed
any potential issue.

In advance, thank you for your answer.

Best regards,

Maurice.



E X T R A C T    O F    R E L E A S E    N O T E S

[...]
     1.2.2  Multiple DECmcc Instance Repositories

     Under DECmcc V1.1 the only supported instance repository for
     DECmcc instance information was DECdns, the Digital Naming
     Service.


     In DECmcc V1.2 DECdns is still supported, but local instance
     repositories are now available to manage environments where
     DECdns is not available or appropriate.

     Both forms of instance repository (local and DECdns based) are
     available on both DECmcc platforms.

     Digital recommends that you use DECdns for the DECmcc Instance
     Repository if you will be managing DECnet/OSI nodes using DECmcc.
     DECdns may also be the best choice if you intend to manage the
     same network from several DECmcc installations.

     On ULTRIX, the local instance repository is not suitable for
     large numbers of entities (greater than 1000).  Digital
     recommends that you use the DECdns based instance repository if
     you expect large numbers of entities on your installation.

[...]
     2.2  DECMCC INSTANCE REPOSITORY

     DECmcc requires the use of a Name Service for the storage and
     retrieval of entity information.  It is recommended that DECdns
     be used for this purpose.

     When DECdns is selected (the default), DECmcc requires Version
     1.1 or later of DECdns.  The DECdns Server must be installed on a
     node in the network and the DECdns Client software must be
     running on the node on which DECmcc is installed.

     When you select the Local Instance Repository, the DECmcc users
     may need read/write privileges to the following repository files:

      o  MCC_COMMON:MCC_DNS_ENT.DAT

      o  MCC_COMMON:MCC_DNS_ATT.DAT

     When DECmcc software is first installed, the MIR file protections
     are set for system, owner, and group to have full access, and for
     world to have READ-ONLY access.  A nonprivileged DECmcc user can
     obtain required accesses by adding ACL as follows:

         $ SET FILE MCC_COMMON:MCC_DNS_ENT.DAT -
          /ACL=(IDENTIFIER=[NETMAN,JAMES]),ACCESS=READ+WRITE)

         $ SET FILE MCC_COMMON:MCC_DNS_ATT.DAT -
           /ACL=(IDENTIFIER=[NETMAN,JAMES]),ACCESS=READ+WRITE)

     Please note that the user may choose only one Name Service at the
     installation time.  Changing from one Name Service to another at
     a later time may require manual procedures for re-entering entity
     data, and this is not recommended.

[...]

     4.4  REGISTRATION FUNCTION MODULE

     The Registration FM uses the Digital Distributed Name Service
     (DECdns) or a local instance repository to maintain a current
     instance repository.  To program the Registration FM to work
     properly refer to the "DECmcc Installation" manuals and the
     DECdns Considerations section of these release notes.



     4.4.1  New Features

     DECmcc now supports partial registration.  Instead of failing a
     registration if it can't be completed, DECmcc will now allow the
     registration to proceed as far as possible, record the degree to
     which it was completed, and report a successful partial
     registration.



[...]
     4.12.2  Clarifications


     1.  The Node and Node4 global entities must be registered in the
         DECmcc Instance Repository (DECdns or local).

[...]

     4.15  DECnet/OSI ACCESS MODULE (DECnet PHASE V)

     The following are known restrictions:

[...]

     5.  The DECnet PhaseV AM Sink listens for PhaseV events on End
         User Name MCC_EVL_SINK.  In most cases, an outbound stream
         may be set up to deliver events to the sink by setting the
         Sink Node and Sink End User fields to define the destination.
         However, some routers which are not configured to use DNS
         must have the destination defined in terms of a towerset.  If
         this is the case, you must use NCL to set the Sink Address
         field of the outbound stream as MCC V1.2 does not support the
         input of a towerset.  The following is an example of such a
         definition.  Please refer to the documentation provided with
         your router for more information on this subject.

          NCL> SET NODE decnis EVENT DISPATCHER -
          _NCL> OUTBOUND STREAM stream-name SINK ADDRESS -
          _NCL> {([DNA_CMIP-MEN], -
          _NCL> [DNA_SESSIONCONTROLV3, NAME = MCC_EVL_SINK], -
          _NCL> [DNA_NSP], -
          _NCL> [DNA_OSINETWORK, 37:12345:02-00:AA-02-14-78-66-11:20]), -
          _NCL> ([DNA_CMIP-MEN], -
          _NCL> [DNA_SESSIONCONTROLV3, NAME = MCC_EVL_SINK], -
          _NCL> [DNA_NSP], -
          _NCL> [DNA_OSINETWORK, 37:12345:02-00:AA-02-14-78-66-10:20])}

    The local repository does everything DECdns does except provide
    visibility to the rest of the network.  While there are no
    directories in the local repository per se, the user may structure the
    fullnames as he wishes, so names like    a.b.c   are just fine.  What
    you can't do is go into an external utility like dns$control and
    manipulate/list directories.   But directory functionality is
    completely external to MCC, even in the DECdns case.
    

Jim,

Many thanks for your fast answer.

One item of your answer kept my attention.
To be sure, let's try to clarify it:

>   What you can't do is go into an external utility like dns$control and
>   manipulate/list directories.   

Are you speaking about DNS directories ?
More specifically, will it still be possible to issue the
following commands:

MCC> DIRECTORY DOMAIN .dir.subdir.<domain_name> MEMBER *    

Maurice.

    Yes, I was speaking of DECdns directories.  The MCC DIRECTORY command
    is not affected by choice of nameservice.