Conference help::decnet-osi_for_vms

    $ mc cdi_cache_dump
    
     CDI Cache Checkpoint file dumper
    
    [Checkpoint filename = "SYS$SYSTEM:DECNET$CDI_CACHE.DAT;1"]
    Reading file...
    136192 bytes (of 4) loaded from checkpoint file
    Computing checksum...
    cache size (except checksum) (in words): 34048
    Checksum correct
    Cache checksum: file: E7D0E247, computed: E7D0E247
    CDI cache successfully loaded from ckpt file...
      Cache id = 950022
      Cache version = 2.2
      cache_init_flag = 1
      cache_size = 128
      MRU pointer = 125
    
    *********************** Cache Entries (MRU order) *********************
        - ptr - Dir s.name
    Ent Bck Fwd Svc off len Input name               Synonym Fullname
    
    125 124 127   1   7   5 ALPHA                    ALPHA   LOCAL:.alpha
      | tower 1: "DNA_NODE"/"SC2"/"TP4=DEC0"/NS+49+0001AA000400020421
      | tower 2: "DNA_NODE"/"SC2"/"NSP"/NS+49+0001AA000400020420
      | created: Tue Mar 25 15:02:04 1997
    
    127 125 126   1   7   5 LOCAL:.ALPHA             ALPHA   LOCAL:.alpha
      | tower 1: "DNA_NODE"/"SC2"/"TP4=DEC0"/NS+49+0001AA000400020421
      | tower 2: "DNA_NODE"/"SC2"/"NSP"/NS+49+0001AA000400020420
      | created: Tue Mar 25 15:01:01 1997
    
    126 127   0   1   7   5 NET$490001AA0004000204   ALPHA   LOCAL:.alpha
      | tower 1: "DNA_NODE"/"SC2"/"TP4=DEC0"/NS+49+0001AA000400020421
      | tower 2: "DNA_NODE"/"SC2"/"NSP"/NS+49+0001AA000400020420
      | created: Tue Mar 25 15:01:26 1997
    
    
    **************************  3 entries listed  *************************
    

Peter:

Try dumping sys$system:net$config.dat...

This sounds like the problem I reported in note 3881.0 I still do not know 
what's wrong with that particular system.

						Mike Sheldon
						CSC/CS Network Support

    
Re: .0

Maybe there is an old NET$STARTUP_RENAME.COM on SYS$STARTUP,
containing incorrect information ? This command-procedure is
executed (if it exists) by NET$STARTUP during the bootstrap and
it updates the NET$CONFIG.DAT file.

If there is an old version of the NET$STARTUP_RENAME.COM, delete
it, rerun option 2 of NET$CONFIGURE and see what happens after
the next reboot.

/\Pim.

    re: .3
    
    Pim, no there isn't an NET$STARTUP_RENAME.COM. I've seen this one.
    After a NET$CONFIGURE Menu option 2 (change name) there is one
    containing
    the correct information.
    After the first reboot this file is deleted (the name and logicals are
    then
    still set, since NET$STARTUP_RENAME.COM. executes "RENAME NEW NAME" )
    
    
    But since your mentioning NET$CONFIG.DAT ....
    
    
    This file doesn't seem to contain any information (I check with $DUMP)
    On system with no problem I can recognice at least something like
    nodename
    etc. But this system just has some repeating hex code in it.
    
    Question:
            What should NET$CONFIG.DAT contain and how is it structured ?
    
    
    Regards, Peter
    

    since I suspectedt the NET$CONFIG.DAT to be corrupt I deleted it
    and run NET$CONFIGURE again to create a new one.
    But this new one contains still the same rubish 
    it contains all  %xC339 (repeating)
    
    But during NET$CONFIGURE I noticed an error message
    
    ....
    %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.
    
    Clearing old local namespace entries prior to loading new entries
    Loading new local namespace node name entries
    
    >>>> %LOCREG-E-CACHE, cannot add timestamp attribute to node name object
    >>>>    Node name:  .ALPHA
    >>>>    Reason:     Access denied
    
    
    >>>> %LOCREG-E-LOAD, unable to copy node entries into the local namespace
    >>>> %DNS-E-NOCONFIG, DECdns is not configured. 
    
    
    Peter

    
    
    
      The errors you listed in the previous reply would not cause 
    a problem in the config.dat file.  There is something very strange 
    ocurring on your system.  The config.dat file is a text file that 
    you can simply look at with the type command.  Is the system disk 
    nearly full ?  any thirdparty disk utilities running on the system disk
    
    
    

	Hi,

	We have just had two or three Customers with two or three systems
	each, with all systems exhibiting the same problem, viz: apparently
	corrupt NET$CONFIG.DAT files, and losing the nodename on reboot.

	These calls are not in my queue, so someone else in our Unit has
	all the details, but ...

	The systems have Factory Installed Software, and it appears that the
	supplied configuration has insuffient NPAGEDYN. In any case, when
	DECnet-Plus was exhibiting the problem, the NPAGEDYN on the system
	showed an initial value of about 2Meg, which had expanded to about
	3� Meg. The NPAGEDYN sysgen parameter was increased to 4 Meg and the
	system AUTOGENned and rebooted and after NET$CONFIGURE option 2 and
	a further reboot it appeared to operate correctly.

	Assuming that increasing NPAGEDYN also resolves the problem on other
	systems, this would seem to imply:

		a) FIS systems are shipped configured with insufficient
		   NPAGEDYN for DECnet-Plus to even start properly.

		b) SYS$NETWORK_SERVICES (which handles NET$CONFIG.DAT) has to
		   allocate pool for the configuration, but if the pool
		   allocation fails then SYS$NETWORK_SERVICES does not detect
		   it or does not recover from it...

		c) SYS$NETWORK_SERVICES is loaded very early in the boot
		   sequence -- I don't know, but perhaps it is so early in
		   the boot sequence that NPAGEDYN expansion does not work,
		   so if you don't have enough NPAGEDYN at boot time it will
		   just not recover.

	If the above is correct, it would be good if this could be fixed,
	or at least as a minimum, if an error message could be displayed on
	the console.

	Regards,

		John

    re: .6
    the net$config.dat isn't a "type"-able file at least not
    on the systems I've seen. but with $DUMP there is at least something
    you can recognize. 
    The system I've problem with doesn't have any third party
    diskutilities and the net$config.dat is still corrupt even after
    recreation.
    
    re: .7
    John, thanks for your input. I've tried them but to no success.
    I've doubled the NPAGEDYN from 2840000 to 5670000 (on a 64MB system)
    but the NET$CONFIG still does contain rubish. 
    
    I recreated the NET$CONFIG.DAT by deleting it and then run
    NET$CONFIGURE option 1.
    
    
    Peter

    Hi,
    
    Regarding the reply from John Weir, the calls are in my queue. There
    are two customers whose systems have this problem. One has dial-in and
    this customer has the same problem on three machines all bought with
    DECnet Plus factory installed.
    
    However, the other customer, (who doesn't have dial-in) reckons that out
    of four VMS V7.1, decnet plus systems:
    
    4000 Alpha 1G memory
    4000 Alpha .5G memory (x2)
    1000 Alpha .5G memory
    
    Only the Alpha 1000 has the mentioned problems. To make things
    interesting, he believes that it was only on the Alpha 1000 that he
    orginally ran the quick config; on the others the first config was
    advanced. (I don't think this would make a difference, but I'm sure
    someone could prove me wrong.) 
    
    My money would be on a possible difference between 4000's and 1000's
    alpha architecturally that could influence the amount of resources for
    writing net$config.dat. 
    Has anyone else noticed this?
    
    Thanks
    
    Dave Vernon
    
    Comms Support,
    Digital CSC

    Talking this problem over with Pat Taylor, it occurs to me that if the
    thing gets written wrong once, it'll probably stay corrupt, even if you
    try to delete NET$CONFIG.DAT out from under it (mainly 'cause it'll
    just rewrite it).
    
    Have you tried:
    
    Booting P1="MINIMUM" - DO NOT start DECnet
    Deleting NET$CONFIG.DAT
    Booting normally, and reruning the config
    
    Note that although NET$CONFIG.DAT contains some (but not much)
    information from the configure process (in our case, mostly the node
    name), it is not related in any way to NET$CONFIGURE, as much as the
    names might seem to imply this.  It's mainly a repository for
    information that the system has to keep track of, mainly because the
    startup scripts either can't specify it, or because they're too late to
    specify it.
    
    It gets read at system boot time, and is periodically rewritten by
    NET$ACP.  This is the problem: If you have NET$ACP running, deleting
    the file has virtually no effect, since NET$ACP is liable to just
    rewrite it, anyway.

    re :.10
    
    I defined NET$IGNORE_DECNET and rebooted.
    checked NET$ACP is not running and then deleted SYS$SYSTEM:NET$CONFIG.DAT
    
    deassigned the logical NET$IGNORE_DECNET
    then did a new configruation @NET$CONFIGURE ADVANCED (option 1)
    this starts the network 
    	right now the logical SYS$NODE is set and a new NET$CONFIG.DAT
        is created.
    BUT this new NET$CONFIG.DAT contains the same (bad) data as the old
    one.
    
    After a new reboot the logicals SYS$NODE is not set anymore.
    
    So this didn't help either.
    
    Peter
    
    PS I did not boot with P1=MINIMUM , because I would have lost also my
    LAT connection to the system. But I guess I doesn't make any
    difference. NET$ACP was not running. 

        One esy to way to maintain LAT connectivity is to have something
        like
        
        $ arch= f$getsyi("ARCH_NAME")
        $ if arch .eqs. "VAX" then mc sysgen auto all
        $ if arch .eqs. "Alpha" then mc sysman io auto all
        $ @sys$startup:lat$Startup.com
        
        in say SYLOGICALS.COM.
        
        Did there exist a NET$*RENAME*.COm after the NET$CONFIGURE
        /before reboot?
        
        _veli

How to fix it:

1. Boot MINIMUM (NET$IGNORE_DECNET is not enough) in order to prevent
   DECnet starting
2. Delete SYS$SYSTEM:NET$CONFIG.DAT;* 
   (and evtl. SYS$SYSROOT:[SYSMGR]NET$STARTUP_RENAME.COM )
3. Boot FULL 
	(there is an error message early during boot after the message 
         telling about the network images loading
	 there is the message
	 %DECnet-W-NOOPEN, could not open SYS$SYSROOT:[SYSEXE]NET$CONFIG.DAT )
   DECnet is now starting
	"NET$STARTUP_STATUS" = "RUNNING-ALL"

   the logicals SYS$NODE and SYS$NODE_FULLNAME are still not defined

   *** BUT *** SYS$SYSTEM:NET$CONFIG.DAT contains some real data

4. MC NCL RENAME NEW NAME LOCAL:.ALPHA
   creates the logicals and the NCL node name identifiers
   and update SYS$SYSTEM:NET$CONFIG.DAT 
   (a NET$CONFIGURE option 2 would probably do as well)


	!!! Now the system keeps it nodename (SYS$NODE etc.) 
            for all reboots 




The question, which still remains is:

How does the corruption to the NET$CONFIG.DAT come in the first
place ???


This corruption has been seen on

Alphaserver 400, Alpha 2100, Alphaserver 4000, Alpha 3000 Model 300
with Memory size varying from (64Mb - 132 Mb)
System disks are SCSI drives

an probably most important these are all Factory Installed Systems (FIS).

An installation from CD distribution did not create this corruption.
	 	 

Don't know where the corruption came from in the first place, but once it's
there, it'll stay there until you do what you did in .13.