Conference iosg::all-in-1_v30

    Hi Banquo,
    
    Firstly to answer the question about missing pointers in PDAF and
    DOCDB.  The correct way to address this problem is to run the TRU
    housekeeping utility.
    
    Now going on to the next point.  Files starting with "Z" the name is
    generated by the ALL-IN-1 IOS process OA$FCV and files starting with
    "I" are generated by the FCS, in other words for shared documents.
    
    Regards,
    
    Sunil

    Hello
    
    The management guide seems to say that the Test and Repair housekeeping
    procedure will clean up un-reference RMS in share directories but not
    private user directories.  Is there any way to configure the TRU to
    perform this task as well?
    
    If the I... files are for share directories, why are there so many such
    files in private user directories?
    
    Thanks
    Banquo

The 'share' directories which TRM is talking about are the OA$SHAREnnn 
directories - used by mail send and delivery. Since V2.3 we've been trying to 
call these 'mail areas'.

The 'share' directories used by FCS are private/shared directories created by 
users wanting to share documents.

grahame

    Hello
    
??? So ..... Does it mean that there is no housekeeping procedure to
    cleanup un-referenced RMS files in private user directories?
    
??? And is it safe to delete those files?
    
    The I... files, which supposed to be generated by FCS and shared,
    were found in user MAIN drawers and they are not shared drawers.
    How comes the I.. files could be found in those directories?
    
    Thanks
    Banquo

Hi Banquo,

>??? So ..... Does it mean that there is no housekeeping procedure to
>    cleanup un-referenced RMS files in private user directories?

Sorry, there is no housekeeping procedure.  However, during V3.0 development
I wrote a script to cleanup unreferenced files - I'll post it as the next
reply.

>??? And is it safe to delete those files?

Yes.
    
>    The I... files, which supposed to be generated by FCS and shared,
                                                           ^^^^^^^^^^
Why shared?  Just because the FCS created the files, DOES NOT mean the
files are shared.

>    were found in user MAIN drawers and they are not shared drawers.
>    How comes the I.. files could be found in those directories?
    
Because the FCS was used to create the files.  Most likely, they are the
result of copying documents from other drawers into the MAIN drawer.

Cheers,
    Paul.

After the formfeed is the script.  You'll have to edit it, before you can
use it (look for comments that start with !!!! at the beginning of the
script.)

Enjoy!
    Paul.


! RECOVER.SCP - create filecab entries for unreferenced files in the [.DOCn]
!               and [.MSG] directories.
!
! See end of script for more details
!

.if OA$SMB_PARAMETER_1 nes "" then .goto do_recover

!!!! EDIT this to be the location and name of THIS script; e.g.:
!!!!      user1:[marchant.a1]recover.scp
!!!!
get #tidy$script = "disk:[dir]recover.scp"
!!!!
!!!! and remove these two lines.
display Please edit the script before running it.
.exit
!!!!

submit_script( script=#tidy$script, p1=oa$curdwr )
.exit

.label do_recover
cab set_drawer OA$SMB_PARAMETER_1
get #tidy$dwr = LOG$OA$CURDWR_DIRECT
get #tidy$rlen = fn$length(#tidy$dwr)
get oa$dcl = '$set default ' #tidy$dwr

! Let's get a list of all the files currently in the [.DOCn] & [.MSG]
! directories.
get #tidy$srcs = "OA$TEMP:TIDY$FILES.TMP"
text_file open/write docs #tidy$srcs

for file$ with .spec == "[.doc%]*.*;" do -
    get #tidy$spec = "[" fn$right(.all_but_version, #tidy$rlen)\\-
    text_file write docs #tidy$spec

for file$ with .spec == "[.msg]*.*;" do -
    get #tidy$spec = "[" fn$right(.all_but_version, #tidy$rlen)\\-
    text_file write docs #tidy$spec

! Rewind file...
text_file close docs
text_file open/read docs #tidy$srcs

! This little command procedure enables us to determine whether the file
! has a DAF record or not.
get #tidy$comf = "OA$TEMP:TIDY$READ.COM"
text_file open/write comf #tidy$comf
text_file write comf '$on error then goto w'
text_file write comf '$read/nolock/key=&p1 tidy$daf daf_rec'
text_file write comf -
         '$w: write oamailbox "oa get #tidy$sts = ",f$extract(9,1,$status)'
text_file write comf '$@dclmailbox:'
text_file close comf

get oa$dcl = '$open/read/share tidy$daf daf.dat'

.label mainloop
text_file read docs #tidy$full
.if oa$status == "0" then .goto done

get oa$function = 'command ' #tidy$comf ' "' #tidy$full '"'
.if #tidy$sts == "1" then .goto mainloop

! We have an orphan file...
get #tidy$size = file$.allocation[#tidy$full]
.if #tidy$size nes "0" then .goto create_cab_entry

get oa$function = "delete " #tidy$full
.goto mainloop

! Create a filecab entry for this orphan file.  We give it a title that
! says how big the file is, and an indication of what the file is (.WPL,
! .PS, .TXT etc.)
.label create_cab_entry
cab create "RECOVERED DOCUMENTS", #tidy$full, @#CURDOC
.if oa$status ne 1 then .goto mainloop
get #tidy$title = #tidy$size " block " file$.type[#tidy$full] " file"
cab begin
cab add_attr ,"title",#tidy$title
cab add_attr ,"type",oa$docu_type
cab add_attr ,"author", "Paul's recovery script"
cab end
.goto mainloop

.label done
get oa$dcl = '$close tidy$daf'
text_file close docs
get oa$dcl = '$set default oauser'
get oa$function = "delete " #tidy$comf
get oa$function = "delete " #tidy$srcs
get oa$status = '1'
.exit

!
! RECOVER.SCP
!
! USAGE:
!	SDR to the drawer you wish to process, then <DO this script.
!	Use Job Services to see if the script is running or finished.
!	When the script is complete, check the RECOVERED DOCUMENTS
!	folder to see if any orphans were found.  What you do with
!	them is up to you!
!
! WHAT IT DOES:
!	This script looks to see if the files in the [.DOCn] and [.MSG]
!	directories have DAF records.  If there isn't a DAF record the
!	file is an orphan, and a FileCab entry is created for the file
!	in the RECOVERED DOCUMENTS folder (folder name is hard coded.)
!	Note, however, that orphan files that have no content are not
!	put into the filecabinet and are deleted instead (they weren't
!	much use anyway!)

    Hello
    
    Guess what?  We found 12000 unreferenced files occupied 400000 blocks!
    The node has around 40 user in the peak hours of the day and it has
    only been upgraded to V3.0-1 for 5 months.
    
    I should have guessed where did all those files come from.  When I
    tried to fix a S2020 problem before, I found that
    FILECAB DELETE_DOCUMENT seemed to delete the most current version of
??? VMS file only.  Is this true in other system ?
??? Is there any solution?
    
    In WordPerfect or other editors, the file will get save to the disk
    every preset period of time.  What I have done to alleviate this
    problem is to global setup in WordPerfect to allow user to have one
    version of their files only.
    
    But it will be better to find a solution within ALL-IN-1.
??? Is it only that particular system I am looking at has this
    FILECAB DELETE_DOCUMENT problem?
    
    Thanks
    Banquo

I think you control the number of files left in user directories by setting 
the Editor purge count in the Format master file - see the entry for 2020 in 
your case.

grahame

    Re the last two:
    
    FILECAB DELETE_DOCUMENT currently deletes all versions of the VMS file.
    What vintage of File Cab Server gave you the problem you mentioned
    Banquo?
    
    I'm still puzzled a  bit by what you say about WordPerfect. As Grahame
    says editors, if they choose to, look in the Format Master file to
    decide how many versions to keep. WPS-PLUS, which is an in-place editor
    (like WordPerfect?) ignores the Format Master and resolutely maintains
    one version only, even when doing its timed write-aways. Can't
    WordPerfect do the same?
    
    The situation is more complicated when editing in shared drawers. The
    editor is given a copy to work on, and then the File Cabinet Server
    replaces it. At one time the Server used to let versions build up, but
    that has been corrected. Obviously it would be inappropriate to require
    the Server to look at the Format Master, so a universal algorithm is
    used. Does this help explain what you are seeing?
    
    As for 2020, I vaguely remember seeing a problem that manifested itself
    if the node/cluster name was less than 6 characters. Could this have
    allowed versions to build up?
    
    Dick

    Hello
    
    I have tested the FILECAB DELETE_DOCUMENT, it only delete the most
    current version of the RMS file, so does this mean something wrong
    in the system?  How can I find out what's wrong?
    
    Is there a parameter to instruct FILECAB DELETE_DOCUMENT to delete
    all version of RMS file?
    
    Thanks
    Banquo