File allocated space growing out of control!

[Erik Ahrendt]

I have a log file with zero used blocks, but the allocated space is growing at a rate of over 30000 blocks per day which reduces my available disk space accordingly. How is this possible?

System is running VMS7.1 on a VAX400-108

[Robert_Boyd]

This is easily possible if a process is keeping the file open and never writing an End Of File.

In order to find out what process(es) have the file open use the SHOW DEVICE/FILE command for the volume that the file is on. Look for all the processes that have their fingers into the file you're concerned about -- there will be your culprit. If you have a cluster, you should do this on each node of the cluster that mounts the same volume.

Cheers,
Robert

[Jan van den Ende]

Erik,

WELCOME TO VMS!!

Might I ask WHAT logfile(s) this is about?
Many VMS utilities have nice ways to get this under control, automated if so desired.

Proost.

Have one on me.

Jan

[Antoniov.]

Erik,
welcome to vms from me too :-)
Your situation is absolutely normal in vms. If you use DIR/SIZE=ALL you can see either used blocks either allocated blocks.

Antonio Vigliotti

[Willem Grooters]

For ANY system, not just VMS, writing to a file increases it size. That's normal. But in your case, I'd say that the application that writes to this file should be thouroughly examined. As a personal note: I consider this "VERY BAD design", and certainly if this is a real log file. It should be closed regularily, for several reasons.

What you _could_ do, if size really matters, is to enable diskquota on that volume and limit that particular user to an allowance low enough to prevent problems with other disk users. The program _may_ crash, you _may_ loose data in case this happens, but at least you save your other user's room - and will force the developer of the program to change it so you are able to move the file elsewhere on a regular basis.

(Just to prevent the "obvious" answer: being a low(= no)-budget user I'd say that buying extra disk space is NO option. ANY disk is too small if a program is badly written and behaving as bad as this.)

Willem

[Lawrence Czlapinski]

Erik,
1. Logfiles that stay open and grow have to be closed periodically and managed. Depending on available space, you may be able to use a simple purge of the old logfiles. You may be able to use a PURGE_DAILY.COM. If you need to purge more frequently you will probably need to write a DCL to handle it.
2. Are they system or application logfiles? 3. For our systems I notify the applications person for that system that based on current usage you run out of space in xx days on disk y. So our applications people handle a lot of the application logfile management.
You may have to implement disk quotas.
Lawrence

[Peter Quodling]

Erik,

Treat the Cause not the symptom. The Sympton is a 30000 block per day write. The cause is....

Well that depends on what is writing the log file. Is this an application log, a batchfile log, a system log. The most likely cause of this is an error condition which is being reported in the log file, and then restarted, and is reoccuring (ad nauseum). That, or if it is a System Log, you have set some parameters that make it so large (Is there a recent change that you have made).

As mentioned elsewhere, find the name of the log file, what is creating it, and report.

A set file/truncate may also force a flush of the buffers of this file (if it's application specific and you are uncertain about stop the process causing it.)

More detail needed.

[Erik Ahrendt]

User has corrected his applications error logging to correct the problem. Thank you for all your replies.