NET$SERVER.LOG & High Image Activations

[Manny DeAssis]

Greetings,

Recently we had a problem whereby we ran out of disk space for a non-boot disk. This was due to one/more overblown net$server.log files. After we corrected the problem we kept getting the message 'file access was terminated with no bits to close'. Not to mention that the processes that were writing to the net$server.log had very high image activations (we're talking well over 150,000). The system is running with OpenVMS V7.2-3 DECnet over TCP/IP. Our disks are available via an EMC SAN (DMX). No recent significant system changes were made. Would/could a network problem cause this behavior?

[Volker Halle]

Manny,

the message you've provided is probably not exactly correct. Do you refer to the following message at the end of the NET$SERVER.LOG file ?

File access was terminated with no bits set on close

This message would be normal and indicate DECnet remote file access (through FAL server object) to a file on your system. The file was closed with no specific file disposition bits set - this is normal. For an explanation, please see ATW note 8558:

http://h71000.www7.hp.com/wizard/wiz_8558.html

Do your big NET$SERVER.LOG files contain many file accesses and FAL image activations ? Every time a file is accessed via DECnet, FAL is started on the local node. You should see appropriate entries in the NET$SERVER.LOG file, indicating the remote node and process, from which the file access has been made.

If you define the FAL$LOG system-logical (e.g. DEF/SYS FAL$LOG 1), you can also see additional information about the files accessed etc.

There is an optimization in DECnet, which will reduce the no. of process creations. Once a FAL connection is terminated, the process will start the NET$SERVER image and change it's name to Server_nnnn. It will accept another DECnet-connection for the same user without having to create a new process. Once such a Server_nnnn process remains idle for NETSERVER$TIMEOUT seconds, it will exit and close the NET$SERVER.LOG file.

Please try to find out, which operations are being logged in those NET$SERVER.LOG files and whether they seem to be caused by normal application behaviour.

Volker.

[Robert_Boyd]

Manny,

Was the disk space consumed primarily by one huge log file, or were there a number of log files that accumulated over time?

You may want to look at dcl.openvms.org and pick up a copy of BATCH_LOG_FILE_CLEANUP.COM.
If you make sure that the account the problem occurred in accesses this procedure under at least NETWORK mode you can make sure that there wont be a large number of log files building up.

Another question -- do you have netserver$timeout defined either system wide or group wide or for the username the network process is executing under? If so, what is it set to? Perhaps if it is set to a very large time interval you might want to set it to less than 1/2 of what it is now.

Robert

[Manny DeAssis]

I want to thank the individuals who responded to my post.