Conference iosg::all-in-1_v30

    Nicholas,
            I'm not too sure about the size of the temporary file, but
    depending on the last time your OA$DAF_E.DAT was converted..if it
    has been a while (couple of months) since then I would imagine
    it would be considerably smaller than 800,000 blocks. Which should
    fit on your disk. However to be on the safe side I would convert
    it manually outputting the new (converted) file to another disk
    hence
    
    $ CONVERT/NOSORT/STAT/FDL=OA$LIB:SDAF.FDL OA$SHARE:OA$DAF_E.DAT-
    otherdiskname:[000000]OA$DAF_E.DAT
    
    Ensure you make a backup of the OA$DAF_E.DAT before converting.
    
    Having converted the file, delete the original OA$DAF_E.DAT then
    BACKUP the "otherdiskname:[000000]OA$DAF_E.DAT" to OA$SHARE:
    
    Doing it this way will at least give you some extra diskspace 
    to enable you to do a proper RSF next time.
    
    Hope this helps
    
    Tim 
    
    

    Tim,
    
    Thanks for your reply. I do know how to do the manual conversion 
    but I do not have the extra disk and the time to do it on another disk.
    So, my question question remains simple and all I need is a streight
    forward answer to the following question:
    
    Given a file OA$SHARE:OA$DAF_E.DAT file with 800,000  blocks, and 400,000
    free blocks on the same disk, then can RSF work correctly and safely?
    
    Regards
    
    Nicholas
    
    

>                    <<< Note 2316.2 by EVOCDG::DEC_HELLAS >>>
>                      -< Question is still not answered >-

>    Given a file OA$SHARE:OA$DAF_E.DAT file with 800,000  blocks, and 400,000
>    free blocks on the same disk, then can RSF work correctly and safely?
    
Hi Nicholas,

I think what people are trying to tell you is that there is no yes/no answer 
to this. To put it simply (the only way I can!), you want a guarantee that the 
new DAF will be less than 400k blocks. You can not get that guarantee - it 
will depend on how many messages have been deleted, how many addresses they 
had, how long the addresses were, and so on, since the last time that the file 
was converted.    
    
You've got nothing to lose by trying the RSF!

g

    The DCL file oa$lib:smreorg.com is the one that does the work.
    
    A few lines below label Reorganise_files: you'll find:
    
    $       convert/nosort/fdl='fdl_nam' 'file_nam' 'temp_file'
    
    Where fdl_nam is, for the DAFs, OA$LIB:SDAF.FDL
    
    /nosort is supposed to stop the Convert utility using huge amounts of
    disk space for scratch files.
    
    So, as Grahame says, it all depends on how much "junk" (mostly, deleted
    records) RMS Convert manages to get rid of. If you converted the file 5
    minutes ago, there would be almost no reduction and the output file
    would need 800,000 blocks. If it had 10 years' worth of rubbish in it,
    it might shrink by a lot more than half. There's really no way to tell.
    
    Sorry,
    D.

    Thanks guys,
    
    I took a look in the .com file that does the actual job and I found out
    that it is a staight forward DCL CONVERT command. Momentarily, I
    thought to modify it and assign the .TMP file into a disk with sufficient 
    disk space (condition: if and only if the processed OA$DAF*.DAT file).
    Then I gave it a try (unmodified) overnight and the 800,000 blocks were
    reduced to an new file with 250,000 blocks. The last time I run RSF
    with V2.4 about 11 months ago my file was 1,600,000 blocks and the
    end-result a file with 450,000 blocks! Now, I am running DEFRAG to
    reduce the disk fragmentation.
    
    Again, thanks all of you for your responses! A tele-dialogues is always
    fruitful, helpful and educating!
    
    Cheers
    
    Nicholas
    
    

    ALl-IN-1 3.0-1, VMS 5.5-2
    
    my cutomer is running into the same basic problem as in .0 - but we
    have multiple DAF's. We would have been able to run RSF on more than 1
    DAF, but there is a PURGE/KEEP=2 line in SMREORG.COM.
    
    i have thought to change this to /KEEP=1, but someone told me that if
    the CONVERT fails then a partially converted file is created and if
    PURGE/KEEP=1 is done, then the partially converted file is kept and the
    good one is purged. 
    
    does SMREORG.COM have some error checking in it so that the above
    doesn't happen?  is it allright to change the PURGE/KEEP=2 to /KEEP=1?
    
    	thanks -  ann