Operating System - OpenVMS
Showing results for 
Search instead for 
Did you mean: 

Open VMS system log requirement.

David Phelps
Occasional Advisor

Re: Open VMS system log requirement.

Anjan, When your system rebooted after 18:30, VMS would likely have started a new generation of your OPCOM log (sys$manager:operator.log). A good place to start is to identify the prior version of your OPCOM log, and type out the last 100 or 200 line of it.
DIRECTORY/DATE/SIZE=ALL sys$manager:operator.log
Identify the OPCOM log that was recording up to the time of the system hang.
type/tail=200 sys$manager:operator.log;-1 (for example, for one generation prior to the current OPCOM log)
Spend more time working toward your dreams then preserving memories.
Anjan Ganguly
Frequent Advisor

Re: Open VMS system log requirement.

Dear David

In my system I can see only last 2 versons of Operator.log in sys$manager directory.
So I was not able to make out form the latest one as I do not get any clue for what the system goes down.I have only the messages when the system started after reboot.
Is there any way to increase this no. of files of OPERATOR.log to store.Does the system decide any way that how many files of Operator.log it should keep !!!!!!!!!!!
Jan van den Ende
Honored Contributor

Re: Open VMS system log requirement.


by default the system keeps ALL of them.

Somewhere/somehow YOU (or your system) does the PURGing.
The most likely place would be during bootstrap.
Carefully check your bootstrap procedure (and the things called from it) for
(be aware of command abbreviations and LogicalNames!!).

A BACKUP of shortly after 11-feb might well still contain that version. Obviously you have rebooted once again since then, OR, you have a Logfile refresh-and-purgr procedure active. (if so, then THAT should also be modified to retain more logfiles)



Have one on me.

Don't rust yours pelled jacker to fine doll missed aches.
Jon Pinkley
Honored Contributor

Re: Open VMS system log requirement.


It is also possible the file is set to autopurge to two versions. Since it is easy to check for this possibility, I would check that before searching for something that is using the purge command.

Do a directory/full sys$manager:operator.log and look at the end of the line that begins with "File attributes: "

If it does not say "No version limit", then something has done a set file/version=x on the file. This version limit is not really an attribute of the file itself, but of the directory entry for the file name.

Use set file/version=x to set a higher limit, or set to 0 for "No version limit"

it depends