Removing page and swap files

[John A. Beard]

Hi folks,

I currently have secondary page and swap files mapped to a local scsi drive. I need the disk for other purposes (image restore from another disk).

Is there any way of removing them without eventually going through the process of rebooting, or are they active as long as the system remains up.

Process name PID File name
00000000 [000000]INDEXF.SYS;1
00000000 [PAGE_SWAP]PAGEFILE2.SYS;1
00000000 [PAGE_SWAP]SWAPFILE2.SYS;1

[Ian Miller. · Accepted solution]

SYSGEN DEINSTALL will prevent any new use and when all the processes that are using the files have gone they should be closed.

[John A. Beard]

Thanks Ian...

What method can I use to verify when activity on those files has ceased.

I'm assuming once verified I can just use sysgen to create them on another volume of choice.

[John A. Beard]

Sorry Ian...should have mentioned that I only want to remove the secondary files, not the primary ones (which is probably obvious)

[John A. Beard]

reference by index?

[Hoff]

Your OpenVMS uptime requirements seem to conflict with your available hardware.

Order up some (used) storage hardware while you're fixing this with the deinstallation and with rolling processes into other files.

Roll any dinky SCSI disks (eg: anything smaller than 72 GB) to larger spindles, and/or add a SCSI disk shelf. Or add a shelf on the SAN, if you have one of those.

[John A. Beard]

Hi Hoff...

I know I should have explained a few additional points beforehand. We are upgrading our EVA soon and I was asked to make a copy of the boot disk (on the SAN) to the local drive DKA0:

This was deemed appropriate because in the event of a SAN upgrade catastophic failure at the disk level we would need to access our backup data which is held on TSM.

[Hoff]

If the consistency of the system disk device contents are a consideration and an issue for your organization, then you'll want to boot and create the copy standalone; by booting another disk and using BACKUP from a quiescent device.

The online stuff is good for creating the impression of a recovery path. I've patched together online BACKUPs and gotten the results to boot, but the online approach and the recovery process can sometimes be problematic; there can be data loss with the approach.

The backing storage assignment for a process page is visible via SDA> SHOW PROCESS /PAGE and the "Bak" column, if you're into brute-force.

[John A. Beard]

Appreciate the advice....

Maybe we have just got a little too complacent with having got away with it on all the VMS boxes here at some point in the past.

[Hoff]

>Maybe we have just got a little too complacent with having got away with it on all the VMS boxes here at some point in the past.

When recovering from online backups and my "favorite" /IGNORE=INTERLOCK switch (my previous rants, err, comments on this switch are easy to locate), the most common case tends to be a gronked queue database; entries tend to get lost or stuck.

Whether and what other stuff tends to gets slammed depends on what you're doing on the particular disk; look for stuff with open files and moderate application-level caching or with frequent and multi-part I/O writes and for transactional stuff, as a start.

If the applications happen to be quiescent or can be convinced to be quiescent, you're good to go.

If not, well...