- Stop and restart the ConsoleWorks server - Generate a Console Logging report for each affected console - (OpenVMS:) Edit the primary log area logical name to something different that points to the primary log area for each console
The first method is the easiest but with the attendant small downtime while the ConsoleWorks server is recycling. The second method flushes and closes the log file for each console being reported, pulls the information from the log file(s) then reopens the log, primary location first, secondary location if that fails. The third method closes the current log file for each console then opens/re-opens the console's log file in the "new" directory.
The following information is OpenVMS-Specific:
Before you attempt to do this, you will need to determine what caused
ConsoleWorks to switch to the alternate logging directory in the first
place. ConsoleWorks will switch to the alternate logging area if it gets
a failure to write a log entry for ANY reason. Lack of disk space is
certainly something that would cause it to switch; having 17M free
blocks says this is probably not the cause. Having a directory file too
fragmented is a more likely cause. If you have been running hundreds of
system log files to the same directory for months, you will likely have
thousands of log files pointed to by that directory file. If that
directory file gets too fragmented, you may be unable to create new
files in it. I suggest you use the DFU utility to check the directory
for fragmentation. See the DFU DIRECTORY command for help on checking
directory fragmentation. You will likely be interested in the /COMPRESS
option if you find your directory file too fragmented.
Another possible cause would be that the disk has used up all of its file headers. My experience has been that the INIT command tends to be somewhat shy on the maximum number of headers it allocates, particularly if you create a lot of small files. If you've exhausted all your file headers on the primary logging disk drive, ConsoleWorks will be unable to create additional files. This would cause it to switch to the alternate logging directory. You can use the DFU REPORT command to check this. Pay attention to the INDEXF.SYS fragments, maximum # of files and free headers. If your INDEXF.SYS file is too fragmented, you may not be able to expand it even if you have enough headers left. Also consider that files with extension headers use 1 (or more) file headers to keep track of all the mapping pointers to the files. Volume defragmentation would help if this is the case.
These are just suggestions for things to look at. I suspect something along these lines is what caused ConsoleWorks to move the logs to the alternate disk.