Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

%DECnet-W-NOREAD Error for NET$CONFIG.DAT on Reboot and huge file-allocation-size (275 blocks)

SOLVED
Go to solution

%DECnet-W-NOREAD Error for NET$CONFIG.DAT on Reboot and huge file-allocation-size (275 blocks)

The system comes up with the warning
%DECnet-W-NOREAD, could not read SYS$SYSROOT:[SYSEXE]NET$CONFIG.DAT

This appears on a DS10 with a COMPAQ BD14685A26 (146Gb) as system disk; OpenVMS V7.3 with all currently available public patches and DECnetPlus V7.3 ECO04.

I have the vague suspicion that the "EXEC_INIT" process in that early boot-phase has difficulties with the huge file-allocation-size of NET$CONFIG.DAT.

Does anyone know or is able to confirm such a relationship?

What is a suitable disk-cluster-size (which have impact for the smallest file-allocation-size) for a 146 Gb disk to avoid that problem?

Or is there any other possibility to solve that problem?

many TIA
Thomas
8 REPLIES
Volker Halle
Honored Contributor

Re: %DECnet-W-NOREAD Error for NET$CONFIG.DAT on Reboot and huge file-allocation-size (275 blocks)

Thomas,

there is an article in Ask Compaq for the same symptom/error message:

http://h18000.www1.hp.com/support/asktima/communications/CTI_SRC020108001109.html

Unfortunately, it does not explain the background or the real solution.

Does DECnet-Plus work despite this error message ?

Volker.
Volker Halle
Honored Contributor
Solution

Re: %DECnet-W-NOREAD Error for NET$CONFIG.DAT on Reboot and huge file-allocation-size (275 blocks)

This does not look like a problem related to file allocation size of NET$CONFIG.DAT:

$ copy/alloc=276 NET$CONFIG.DAT;1 NET$CONFIG.DAT;0/log
%COPY-S-COPIED, SYS$SPECIFIC:NET$CONFIG.DAT;1 copied to SYS$SPECIFIC:NET$CONFIG.DAT;2 (2 blocks)

$ dir/siz=all net$config.dat

Directory SYS$SPECIFIC:

NET$CONFIG.DAT;2 2/276
...

>>> boot -fl 0,20000

%EXECINIT-I-LOADING, loading SYS$UTC_SERVICES.EXE
%EXECINIT-I-LOADING, loading SYS$NETWORK_SERVICES.EXE
%DECnet-I-LOADED, network base image loaded, version = 05.0E.04
%EXECINIT-I-LOADING, loading SYS$XFCACHE.EXE
...

Volker.

(tested on V7.3-1)

Re: %DECnet-W-NOREAD Error for NET$CONFIG.DAT on Reboot and huge file-allocation-size (275 blocks)

yes, I found that with ASK but I have other "inconveniences" too (TP_SERVER). And that brought me back too the first warning.

I guessed that EXEC_INIT accesses NET$CONFIG.DAT not only to read the equivalents and defines SYS$NODE and SYS$NODE_NAME.


Okay your test demonstrate that there is obviously no relationship between the file-allocation-size and that NET$CONFIG.DAT read pb.

My idea came up because a couple of months ago I had a pb with excessive fragmentation above 64 extends for the ACRTL. And I recognised that the INIT/BOOT/LOADER process in the early boot phase is very limited.

Thanks Volker for your input.
John Gillings
Honored Contributor

Re: %DECnet-W-NOREAD Error for NET$CONFIG.DAT on Reboot and huge file-allocation-size (275 blocks)

Thomas,

You are correct in assuming it's the cluster size, (not the allocation) that causes this error. It's not related the the CRTL issue (that was too much fragmentation for the primitive file system).

This error will occur when the cluster size of the disk exceeds a magic threshold. It's a "sanity limit" to prevent overallocation of pool. The number has increased over different versions - 25, 50, 125 & most recently 145.

So if you reorganise your disk to have a cluster factor below 145, that should eliminate the error. Check the distribution of file sizes on the disk to choose a better value - I'd guess that the wastage from having a 275 block cluster size would be horrendous.

On the other hand, you could define SYS$NODE and SYS$NODE_NAME yourself - DECnet will work correctly.
A crucible of informative mistakes
Jan van den Ende
Honored Contributor

Re: %DECnet-W-NOREAD Error for NET$CONFIG.DAT on Reboot and huge file-allocation-size (275 blocks)

Thomas,

your huge clustersize suggests that you allow INITIALIZE to calculate your disk cluster size.
While very reasonable for most purposes in the past, with current disk (and RAIDset!!) sizes, it leads to this kind of clustersizes, which are for most purposes much too big.
But.. VMS allows you (since way back when) to tailor this to your needs with INITIALIZE/CLUSTER_SIZE=...
Up until VMS 7.2 there was a limitation on the number of clusters per disk, forcing the minimum ever higher with growing disk sizes, and that is precisely why this limitation has been expanded (well, effectively lifted).
The only price you pay for a smaller cluster size is a bigger INDEXFILE.SYS to hold all the pointers, but that is WAY less "wasted" space as would result from allocating the next cluster multiple for every file.

hth

Jan
Don't rust yours pelled jacker to fine doll missed aches.
Antoniov.
Honored Contributor

Re: %DECnet-W-NOREAD Error for NET$CONFIG.DAT on Reboot and huge file-allocation-size (275 blocks)

Thomas,
in past i read a thread about calculation of best cluster size http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=638027
May help you?

Antonio Vigliotti
Antonio Maria Vigliotti

Re: %DECnet-W-NOREAD Error for NET$CONFIG.DAT on Reboot and huge file-allocation-size (275 blocks)

yes this helped, the DECnet-W-NOREAD warning occurs no more.

should be mentioned as WORKAROUND 3: in http://h18000.www1.hp.com/support/asktima/communications/CTI_SRC020108001109.html

I had some difficulties with the file-allocation-size which was restored in the original allocation-size of 275 byte (Volkers note $copy fn1 fn2 /allo=2 solved that)

Antonio
thanks, but too late
Volker Halle
Honored Contributor

Re: %DECnet-W-NOREAD Error for NET$CONFIG.DAT on Reboot and huge file-allocation-size (275 blocks)

Thomas,

this problem has been finally fixed in DECnet-Plus for OpenVMS Alpha V7.3-2 ECO 3 (AXP_DNVOSIECO03-V732)

ECO03:

- Corrected to prevent the occurrence of "%DECnet-W-NOREAD, could not read SYS$SYSROOT:[SYSEXE]NET$CONFIG.DAT" warning message while attempting to read the NET$CONFIG.DAT file during a system reboot. This problem occurs with larger disks where the cluster_size parameter is set to a value greater than 512.

Volker.