Make the file size to 0

[jess_14]

Hi all,

I have this file in my system disk: TCPIP$FTP_RUN.LOG which is extremely large. When i try to delete, it gives me this error:
-RMS-E-FLK, file currently locked by another user

I was thinking instead of deleting it, how can i make this file to 0 bytes. Which is similiar to unix command /dev/null. Any ideas?

Thanks in advance!

[Shriniketan Bhagwat · Accepted solution]

Hi,

In OpenVMS null device is represented as NLA0: Execute the command $ show dev NLA0: to see the null device in VMS. Any reads from NLA0: return an immediate EOF (end of file) status. All writes to NLA0: return success status.

Regards,
Ketan

[Robert Gezelter]

Jess,

If the file is locked, it is most likely in use by a process.

The first step would be to identify what process is using the file. Try SHOW DEVICE/FILES to identify the Process ID that is holding the file.

If it is a daemon of some kind, shut down the daemon and restart it. That will likely create a new version of the file. The old version may be archived, compressed, or deleted at your discretion.

- Bob Gezelter, http://www.rlgsc.com

[Karl Rohwedder]

This seems to be the logfile from the FTP masterprocess. Try a

$ @sys$manager:tcpip$ftp_shutdown
$ @sys$manager:tcpip$ftp_startup

This will stop/start the process and will result in a new logfile. You may then purge the old one.

Note: The stop/start kills all FTP processes, so be sure noone actively used FTP (show sys/pro=*FTP*)

regards Kalle

[jess_14]

Hi, i'd identified the processing locking the files:
TCPIP$FTP_1 2D400222 [TCPIP$FTP]TCPIP$FTP_RUN.LOG;1

but we r not able to restart the ftp process right now. As this is a 24/7 production system.

Is there any other ways to purge this logfile than shutting down the daemons? :(

[Hein van den Heuvel]

I looked around some (ANAL/SYS) and see no alternative.
This is a DCL output file, unshared.
So you can not for example $open, $get and $truncate.

You'll have to stop and restart, but as Kalle warns, that will take down the slaves :-( so you need to find a moment without (important :-) users.

Any live session will see "Connection closed by remote host." on stop/id or shutdown, but they'll just blame the network right?

Just curious... how big a problem are we taking about here? a few 100 MB?

Hein

[Steven Schweda]

> [...] this is a 24/7 production system.

You can do all kinds of reconfiguration
(like, say, moving a big log file out of the
way), and then, when you're ready to put the
changes into effect, do these:

tcpip disable service ftp
tcpip enable service ftp

which probably takes less than one second to
complete. Do you actually have FTP sessions
running at _all_ times?


Note: 24/7 = 3.429.

[John Gillings]

jess,

This is another missing piece of TCPIP - proper 24x7 logfile management.

Unfortunately there isn't any mechanism to close down FTP for new connections, while allowing existing connections to complete. Nor is there a mechanism to send the running process a "cycle logfiles" command. Those are just two fairly simple ways which would do what you need without interruption of service.

If you have a service contract, please log a case asking for this to be implemented (add it to the pile of similar requests submitted over the decades :-(

The quickest way to cycle the log file is as Steven suggested:

$ tcpip disable service ftp
$ tcpip enable service ftp

HP support will probably say it's better to do:

$ @sys$manager:tcpip$ftp_shutdown
$ @sys$manager:tcpip$ftp_startup

but the difference is the shutdown procedure clears logical names and tidies up a bit. Given you're just about to redefine them all immediately, the disable/enable is less work.

If you're paranoid about interrupting production transfers, here's a round about way to (possibly) protect yourself.

determine the connection limit for the service:

$ tcpip show service ftp/full

Find a node which won't be doing "real" transfers and set its network interface to 10MB. Choose a large junk file 100's of MB and start enough FTP transfers from that node to consume all the transfer slots. Confirm that all your current FTP transfers are from that node:

$ tcpip show device/port=21

Now bounce your FTP server, knowing that the only transfers you will break are the large junk file.

Clean up any mess.

This assumes that anything which does legitimate FTP transfers will retry if it fails to connect.

[John McL]

I notice that the file in question is at version 1. Is this the first time you've run the ftp server or have you renamed old log files? If the answer to both questions is "no" then maybe it's using the same log file every time the process is started and it just keeps appending.

To avoid this you may need to rename the file so that the next time it starts up a new file is created.

By the way, do you Backup this file given that it's open what seems to be 24 x 7 ?