Disk File Optimizer

[Jefferson Humber]

Am looking to install DFO v.2.8.

From reading the installation manual it states you have to run SYS$SYSTEM:SETFILENOMOVE.COM to mark certain files as non-moveable.

I assume you should run this against all VMS volumes on your system, since it marks 000000.DIR as well? Also I assume you should change the attribute on any secondary page/files you have as well. The command procedure marks the primary ones, but looks like it would fail to mark any others you have on your system.

More importantly if in the future I apply ECO patches to my system that replace files that have previously had the 'MoveFile disabled' attribute set, should I re-run the SETFILENOMOVE.COM program again ?

I am fairly new to this product, but was hoping there are some seasoned veterans of DFO out there that can answer these questions.

Thanks is advance,

Jeff

[Veli Körkkö]

Most VAX/VMS patch kits appear to invoke
sys$system:setfilenomove.com automagically anyway. When installing large number of patch kits one after one, I occasionally edit TEMPORARILY said set...nomove procedure to have
$EXIT at top to speed up things...
and execute after last patch kit manually after undoing my change.

Cannot say w.r.t Alpha patch kits. I would tend
to suspect that Alpha patch kits do not execute
SET...NOMOVE.

And where on VAX even open files appear to marked succesfully NOMOVE, same procedure on ALPHA does not (did not in ) mark open files as NOMOVE. So, on ALPha one needs to boot say CD or another disk and execute stuff againts
original system disk.

_veli

[John Gillings · Accepted solution]

Jeff,

The files modified by SETFILENOMOVE.COM should be "MoveFile disabled" out-of-the-box, and from any ECO kit. (Please report any cases to the contrary!)

Running the procedure against any disk shouldn't be necessary, but it can't hurt.
Secondary page files shouldn't be a problem as they will be open, so DFO won't touch them (and if they aren't open then moving won't hurt).

The prudent system manager will run the procedure, as instructed, even though it is superfluous (the truly paranoid system manager will run it from the nightly houskeeping job! :-)

DFO is a good product, BUT there are often misconceptions about WHY one would use a defragmenter, particularly under OpenVMS. Before actually defragging any disks, make sure you undertstand the problem you're trying to solve. Is fragmentation REALLY an issue? OpenVMS file systems are designed to cope with moderate levels. It's also much better to AVOID fragmentation with very simple file tuning than to spend resources fixing it up after it's done.

Blindly running DFO over all your disks on a regular basis can cover up application issues that can be solved in more appropriate ways.

Note that the most useful feature of DFO is SHOW. SHOW can (legally! :-) be used without a PAK. Just install DFO, say "yes" you have a PAK and "no" you don't want to run the IVP.

[Eberhard Wacker]

First: in real life a VMS system manager sometimes must be paranoid (as all the
other system managers too ;-).

Second: better to run DFO and cover up application issues than not, in most
cases application redesign will not be done due to the costs. This is the case
at least at our side where we do have 3rd party applications.

Third: we experienced files on the system disk with missing attribute
movefile-disabled all over the years. Simpliest way is to reapply the
setfilenomove (procedure on Alpha) after having done patch installations.

But what if there are already system files in access but having the wrong
attribute ?
a) as described before: shutdown, boot vms cd or another system disk, mount system disk (/over=shadow is necessary in case of a shadowset), execute setfilenomove.com, shutdown, boot
b) if you have a system disk shadowset: dismount primary boot member, mount it private (best way is again with /over=shadow), execute setfilenomove on it, reboot, take second member back into the system disk shadowset

Cheers
Eberhard

[Ian Miller.]

Re DFO SHOW command. An alternative is to use DFU REPORT. You do have DFU installed don't you?

[John Gillings]

re: Eberhard,

>better to run DFO and cover up application issues than not, in most cases application redesign will not be done due to the costs.

If it were a case of "application redesign" I'd agree with you. BUT in so many cases it's simply a matter of choosing better extend quantities. It might come down to:

$ SET FILE/EXTEND=1000

or even:

$ SET RMS/SYSTEM/EXTEND=1000

Worst case you may need to CONVERT a few files and adjust the FDL to more realistic allocation/bucket size/extend quantity.

New disks can be initialised with larger cluster sizes (disk is cheap enough now that you don't need to be as concerned about "wasted space" as we did in years past).

Consider files that extending in tiny little chunks. You spend cycles all day shuffling extents as you add to the file, then you spend cycles all night shuffling the same extents consolidating them with DEFRAG. Work out the daily, weekly or monthly growth (to the nearest order of magnitude), set it on the file, and eliminate all that unnecessary work. No changes to applications at all!

From an HP perspective, you're very welcome to pay us for extra processing capacity, but if it's not necessary, why not be a hero and save your company some money? ;-)