Conference help::decnet-osi_for_vms

Making DECdns optional is probably much lower on the ToDo list then putting
in the alternatives.  Initially, DECnet had a significant dependency on DECdns
and it has been hard to remove that dependency.  A LOCAL directory is feasible
only if you continue to use manually assigned addresses globally AND continue
to base the assigned addresses on the physical topology.

Granted this is the same as IPv4, but this is considered unmanageable and so
the IPng is grappling with how much of the OSI capability they are going to
accept as requirements for IPv6.  There are some who are not convinced that
it is feasible to build what is in DECnet Plus.  (I just happen to be reading
the February minutes that discussed proposals to have the end system assign
a unique ID which was qualified by a dynamic address segment that could change
when network topology was changed.  DECnet has it yesterday.)

Likewise, DECdts was inherent in the architecture because its integral to
creating globally unique IDs.  Plus, most people want the computer to maintain
the correct time.  DECdts, again, has capability that is still not incorporated
into the Internet Protocol requirements.  One feature in particular being
automatic configuration.  In the non-LAN case, this is handled by using DECdns
to locate time servers.

The cleanest way to free up the memory is to add code to your SYSTARTUP.COM
which determine the PIDs of DNS$ADVER and DTSS$CLERK and then just stops them.
The alternative for DTSS$CLERK is the following NCL:
    $mcr ncl disable dtss
    $mcr ncl delete dtss

    I'm not saying the functionality provided by these components is 
    not useful, just that they seemed superfulous in my case. Thanks 
    for confirming that there aren't config settings to disable them.
    
    Dave

    Follow-on question prompted by playing with my new install...
    
    What's the difference between
    
    	session control naming search path 
    		directory = decdns
    and
    		directory = decdns_synonym
    
    Dave 

    A couple follow-on question prompted by playing with my new install...
    
    What's the difference between
    
    	session control naming search path ([directory service = decdns
    and
    	session control naming search path ([directory service = decdns_synonym
    
    During net$config, there was the following text
    
    	If you are running a DNS Clerk on this system, or plan to run a DNS 
    	Clerk on this system, DECdns *must* be the first service in the list.
    
    Why must DECdns be first? Is this a change from previous releases?
    
    Thanks,
    	Dave 

    A couple follow-on question prompted by playing with my new install...
    
    What's the difference between
    
    	session control naming search path ([directory service = decdns
    and
    	session control naming search path ([directory service = decdns_synonym
    
    During net$config, there was the following text
    
    	If you are running a DNS Clerk on this system, or plan to run a DNS 
    	Clerk on this system, DECdns *must* be the first service in the list.
    
    Why must DECdns be first? Is this a change from previous releases?
    
    Thanks,
    	Dave 
    

That's a typo.

It should say that if you're running a DNS SERVER, DNS must be first.

As far as running the DNS clerk:

NCL can't hope to interpret simplenames and fullnames without the aid of a
DNS Clerk, as it's the only thing that knows how they're encoded and/or
displayed.  As it's virtually impossible to construct a DNS command without
a simplename or fullname, management of the network would get... difficult
without a DNS clerk laying around, even if you don't actually have any DNS
namespace to manage.

Not a good answer, but an answer.

    I just did a NET$CONFIGURE ADVANCED to add an application to my system.
    When it got to this point, what followed was a bit surprising to me:
    
    * Do you want to generate NCL configuration scripts?   [YES] :
    %NET$CONFIGURE-I-MODCHECKSUM, checksumming NCL management scripts
    modified by NET$CONFIGURE
    
    sys$manager:net$dns_clerk_startup.ncl changed to use the new default namespace.
    
    Your default namespace nickname is LOCAL.
    
    Your default namespace NSCTS is 08-00-2B-0D-C0-9D-5F-FA-A9-88-43-46-95-00.
    
    %LOCREG-W-TOOMANY, the local name file contains more names than will fit in
                       the local namespace
    
    Maximum number of node names that can be loaded:  190
    Number of node names in the local name file:      35423
    
    	SHO DEV/FIL revealed:
    _VTA8:          00000445  [VMS$COMMON.SYSMGR]DNS$CONFIGURE.COM;1
    _VTA8:          00000445  [VMS$COMMON.SYSEXE]DECNET_LOC_REGISTER.EXE;1
    _VTA8:          00000445  [SYS0.SYSEXE]DECNET_LOC_NODE_DEFINITIONS.TXT_TMP;1
    _VTA8:          00000445  [VMS$COMMON.SYSEXE]NETNODE_REMOTE.DAT;46
    	and later
    _VTA8:          00000445  [VMS$COMMON.SYSMGR]DNS$CONFIGURE.COM;1
    _VTA8:          00000445  [VMS$COMMON.SYSEXE]DECNET_LOC_REGISTER.EXE;1
    _VTA8:          00000445  [SYS0.SYSEXE]DECNET_LOC_NODE_DEFINITIONS.TXT;1
    _VTA8:          00000445  [SYS0.SYSEXE]DECNET_LOC_NODE_DEFINITIONS.TXT_TMP;1
    	It sat there consuming CPU and IO for a while, then:
    
    Clearing old local namespace entries prior to loading new entries
    Loading new local namespace node name entries
    Saving the new local namespace contents
    
    %LOCREG-E-TOOMANY, there are too many names to fit in the local namespace
        Error occurred when loading name ".NIXO2"
        All names previous to this one in the local name file have been loaded
    
    Maximum number of node names that can be loaded:  190
    Number of node names that are currently loaded:   190
    
    %NET$CONFIGURE-I-CONFIGCOMPLETED, DECnet-Plus for OpenVMS configuration
    completed
    
    
    FYI - a week or two ago I copied a NETNODE_REMOTE file to my system
    and had used DECNET_REGISTER to populate NET$LOCAL_NAME_DATABASE with
    a few entries. Note that I am only using the LOCAL directory service.
    
    Comments?
    	Dave

Take a look at note 3695 and see if it helps.
--Scott

    3695 does look like it might be related (I'll review it in detail
    later), however note that I was executing option 7, not option 2.
    
    Dave