Purge system files in [SYSEXE]

[Barry Alford]

I have multiple versions of these files in [SYSEXE]:

PAGEFILE.SYS;2 139300 3-APR-2000 10:31:44.12
PAGEFILE.SYS;1 532500 4-AUG-1999 13:54:57.46
SWAPFILE.SYS;2 9700 3-APR-2000 10:31:56.82
SWAPFILE.SYS;1 26600 4-AUG-1999 13:54:58.55
SYSDUMP.DMP;2 83649 3-APR-2000 10:31:57.89
SYSDUMP.DMP;1 121294 4-AUG-1999 14:25:12.78

Can I safely purge them?
Can I delete SYSDUMP.DMP;* completely?
Why would these files have multiple versions?

[Barry Alford]

(Sorry, posted in wrong thread!)

[Jan van den Ende]

Barry,

If you look at
$ Sho sys/files
and you see the lower versions there, you CAN NOT.
By default they are not, but there are several ways to get them active.
Else, you can purge.

You can PURGE DUMPFILE.SYS, but deleting is a little more complicated.
If you want that, you must first enable dumping to the pagefile (see system management manual for exact instructions).
Next, you must REMAME the dumpfile, so that it still keeps its blocks allocated, but under another name.
Then --REBOOT-- that node, and ONLY THEN delete the (renamed) file.
-- and you better have a DUMPFILE.SYS of some blocks (last I remember was 60 blocks, IIRC) for saving errorlogbuffers in case of system failure.

Proost.

Have one on me.

jpe

[Barry Alford]

$ Sho sys/files
%DCL-W-IVQUAL, unrecognized qualifier - check validity, spelling, and placement
\FILES\

$ sho sys
OpenVMS V8.3 on node ...

[Richard Brodie_1]

Given that the latest versions were created over a decade ago, I would be surprised if they weren't the ones in use. As Jan says, you can do a show memory/files to be sure.

If you run AUTOGEN to tune the system it tends to tinker with the file sizes. If the current pagefile & swapfile sizes are adequate, you can lose the earlier ones.

SYSDUMP.DMP is mapped at boot time; this is to simplify the dump process. The system doesn't hunt around looking for space and creating a file during a crash, just blasts the dump to the blocks it already has mapped. Unless you're really tight on space, best left.

[Barry Alford]

SYSEXE> sh mem /files
System Memory Resources on 25-FEB-2011 12:22:25.48

Paging File Usage (blocks): Free Reservable Total
DISK$ALPHA:[SYS0.SYSEXE]SWAPFILE.SYS
9600 9600 9600
DISK$ALPHA:[SYS0.SYSEXE]PAGEFILE.SYS
106448 -28288 139264

Does not show versions but I could tentatively match the Total size with the blocksizes of the version 2 files...

But, this is where the magic happens!
Repeating the directory listing:

$ dir/siz/dat *.sys;*,*.dmp;*

Directory SYS$SYSROOT:[SYSEXE]

PAGEFILE.SYS;2 139300 3-APR-2000 10:31:44.12
SWAPFILE.SYS;2 9700 3-APR-2000 10:31:56.82
SYS$ERRLOG.DMP;1 34 4-AUG-1999 14:10:06.02
SYSDUMP.DMP;2 83649 3-APR-2000 10:31:57.89

Total of 4 files, 232683 blocks.

...my version 1 files have gone!!!
I swear I did not purge them!

Has the SHOW MEMORY/FILES command done some tidying up???

[tsgdavid]

I am pretty sure that there are NO "SHOW" commands that would delete files on your system.

If the files are gone, someone (or some command procedure or program) must have either purged or deleted those files.

If you rebooted your system, there could be something in your startup procedures that does this (However, you probably have rebooted sometime in the last 10 years and nothing in the startup procedures has changed?)

Dave

[Barry Alford]

I did not believe that SHOW would do that either!

On investigation, someone else had issued a:

$ PURGE [000000...]*.*

in order to gain some disk space on this machine which had filled the system disk (which was why I was searching and discovered these files in the first place).

Well, the Alpha is still running so I guess the answer *in this case* was that it was safe to purge these files.

10 points to anyone who can explain why the version 2 files would have been created (back in the year 2000 when I did not work here!)

[Jan van den Ende · Accepted solution]

Barry,

>>>
explain why the version 2 files would have been created
<<<

Well, certainly one way to achieve that is running AUTOGEN (without explicitly blocking it in MODPARAMS!)

Proost.

Have one on me.

jpe

[Richard Brodie_1]

...when it wants to shrink the files it can't easily do that in place, so it makes new, smaller ones. (Other way round is easier).

[Duncan Morris]

Barry,

as Richard pointed out, AUTOGEN is the likely source of these extra files.

If you run

@sys$update:autogen getdata testfiles

and then look at the end of sys$system:agen$params.report you will find that AUTOGEN suggests sizes for these 3 files.

Unless your MODAPRAMS.DAT contains explicit PAGEFILE=, SWAPFILE=, or DUMPFILE= commands, then a full autogen to setparams stage might make changes to the file sizes.

If AUTOGEN wants to increase the file sizes, then it simply extends the file. However, if the result of AUTOGEN's calculations (or the inclusion of specific file sizes in modparams) is to reduce the size of the file, then it will create a new version of smaller size. This is why your version 1 files were all larger than the current versions.

Duncan

[Hein van den Heuvel]

>>> On investigation, someone else had issued a:
>>> $ PURGE [000000...]*.*

Wild West! Shoot first, ask later :-)

>>> in order to gain some disk space on this machine which had filled the system disk
>>> (which was why I was searching and discovered these files in the first place).

Just curious. What tools did you use?
I like DFU for this a lot.

To look for a few big file for quick pressure relieve:
$ DFU SEARC/SIZE=MINI=500000 sys$sysdevice:

To look for a place with potentially many files that can be purged
$ DFU SEARC/VERS=MINI=5000 sys$sysdevice:
Now a high version number does not guarantee many live versions, but at least the inverse is true.

To catch lots of file being created with unique names (perhaps a PID or TIME in there), is trickier. For those yo many want to scan for somewhat large directory files.
Typically system disk do not have large directories, from a VMS perspective. (Add Oracle and the picture changes :-).

$ DFU SEA/SIZE=MIN=50/FILE="*.DIR" sys$sysdevice:

Good luck!
Hein




>> Well, the Alpha is still running so I guess the answer *in this case* was that it was safe to purge these files.

VMS wouldn't delete files which are open (in use).

>> 10 points to anyone who can explain why the version 2 files would have been created (back in the year 2000 when I did not work here!)

I suspect a simple AUTOGEN ... FEEDBACK ... REBOOT.
The versions were created close enough in time for it to have been an automated process, the time difference just being the time to create the files.

free advice...

Those page and swap files seem tiny, but we haven't seen how much memory there is, and apparently it worked for you so far!
Maybe add a large pagefile on a disk with a good amount of free space?

[Barry Alford]

OK, I'd better close now as I'm running out of points!

This Alpha is an old (obviously) development warhorse that nobody looks after until things go wrong (e.g. disk full!).

We certainly don't do AUTOGENS anymore...

=============================================

Hein - I use DIR/SELECT=SIZE=MIN=
There is also a /SELECT=VERSION= too

[Barry Alford]

A disk full on the development Alphas is normally caused by a chap inserting debugging print lines in his code and running interactively, then running it as continuous process on the batch queue which creates huge .LOG files!

When the disk is absolutely full it seems that the Audit service will not allow anything to happen (e.g. login) which it cannot audit, so the only way in is through the console.

[Barry Alford]

Thanks for all who contributed