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

[Thomas Schick]

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

[Volker Halle]

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 · Accepted solution]

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)

[Thomas Schick]

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]

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.

[Jan van den Ende]

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

[Antoniov.]

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

[Thomas Schick]

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]

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.