Conference iosg::all-in-1_v30

Peter,

you don't actually need COMDIR to compress a directory. Close ALL-IN-1
down, rename the directory file to a temporary name, eg

RENAME SHARE123.DIR SHARETEMP.DIR

create a new, empty, directory

CREATE/DIR [.SHARE123]

(checking the ownerships, ACLs etc)

then rename the files from the old to the new, eg

RENAME [.SHARETEMP]*.*.* [.SHARE123]*.*.*

Which should improve the internal structure, and most probably reduce
the size.

Best to write a command file to do the work if you have many directories
to compress,

cheers,

mb

    Dear Martin,
    
    I grovel in mortification!  I really ought to have thought of that
    myself - sometimes the simple solution eludes you just for fun!
    
    Thanks for that.
    
    Cheers Peter.

    
    You can look at VMSDEV::VMSTUNING note 1101 (KP7 to add) for a
    discussion on the effect of directory size on performance. The general
    conclusion is that directory size will normally only affect performance
    when you are doing wild card operations. Moreover it only when a file
    is opened that the directory is accessed and not for subsequent reads.
    So that PENDING.DAT will only be opened once during a session. Other
    data files such as PROFILE.DAT may be opened a few times depending on
    whether they fall out of cache but not frequently.
    
    				Mark
    
    				
    
    

    re -.few
    
    
    COMDIR was fast, RENAME or BACKUP on fragmented directorys takes
    forever. Plus, when you start seeing fraged dirs I'm sure the disk
    indexf itself ain't to far behind.
    -Mike Z.

Peter,

	as .4 says, i suppose i should have added the fact that if you have
large directory files, then there is a strong possibility that the disk is
fragmented anyway, so you would have to backup and restore to sort things
out properly.

If you do get a copy of COMDIR, make sure that it is one of the later
versions that does the re-create in one pass, as earlier versions _could_
corrupt the directory file if it took more than one I/O (or something like
that).

mb

    If anyone's got a copy hanging around please let me know and I'll give
    you a destination to copy it to.
    
    I looked in the VMSTUNING conf and got a lot of folks back in 1991
    having an argument!  Not very helpful...
    
    Thanks for the replies so far...
    
    Peter.

    We had a similar piece of code to the revised COMDIR in the original
    version of the ALL-IN-1 directory compression program, but since we got
    very bad vibes from VMS engineering about it, we removed it.
    
    FWIW, COMDIR is in the Toolshed (METOO::SW_TOOLS_CATALOG) note 1263,
    although it's a V4.5 tested kit as a previous respondent said. Perhaps
    the MAYDAY::COMDIR (Press KP7 etc.) conference has a later version.
    
    RE .6
    
    <<< I looked in the VMSTUNING conf and got a lot of folks back in 1991
    <<< having an argument!  Not very helpful...
    
    If 1991 was when the directory caching algorithm was last updated, then
    perhaps it is helpful....
    
    Maybe the online disc defragmentors make this sort of activity
    unnecessary?
    
    Graham

    Especially see note 27 of the COMDIR conference if you are on a version
    of VMS earlier than V5.5.
    
    Since COMDIR is written/supported by someone who is on the node used by
    RMS engineering, I presume it must be OK to use.
    
    Graham

A few comments:

Whatver method you use to compress the directory, make sure ALL-IN-1 is shut
down while you do it.  Otherwise you could get directory entries being deleted
when they shouldn't be, directory entries still there when they should have
been deleted, etc.

From my experience of talking to VMS engineering about COMDIR-type programs,
they do not support that method of directory compression for use at customer
sites.  Maybe the rules have changed, but make sure you get official approval
before using internal tools on a customer's disk!  Basically (from what little I
remember), the risk is that the code compresses the directory in situ; if
anything goes wrong (eg the system crashes) part way through, the directory is
corrupted.  It could well be that things have changed now, you'd have to check.

If $RENAME is too slow, you may be able to get better performance using
$SET FILE/ENTER (You'd have to experiment, I can't remembe the relative
performance of the two methods)

Scott