Conference iosg::all-in-1_v30

830.0. "ARCHIVE problems" by WOTVAX::DORANA (Mr Ken Shabby) Mon Jun 08 1992 18:38

    Hello all,
    
    I have recently been out to a customer who has a problem with ALL-IN-1
    archiving. The set up is :-
    
    VMS 5.4
    ALL-IN-1 2.4 (no patches, but the archiving fixes are applied)
    
    The site sets up users so that their VMS account is on one device, and
    the ALL-IN-1 account is on another device, ie for user BLOGGS:-
    
    VMS account --->  DISK1:[VMS.BLOGGS]
    ALL-IN-1 account ---> DISK2:[A1.BLOGGS]
    
    This has caused problems for MDK, but this is known. (the problem was
    that MDK couldn't handle separate devices and attempted to move all
    files below the top level [ALLIN1] directory...).
    
    The archiving problems are:-
    
    1) On some users (one in particular), the archiving process (ADS) was
    unable to process a large number of documents (ie more than 1000). The
    error was 
    
    **** Unable to process archive document
    
    (or similar - I am not with the printed report currently). reading
    through the relevant script, this message is given when the call to
    ARCHIVE_DOCUMENT returns OA$STATUS of 0.
    
    Having tried to archive the document manually, there was no
    problem...(tried with a few of the 1000s).
    
    Users before and after this user were processed ok.
    
    In addition, each time the ARCHIVE_DOCUMENT function failed, a .ARCHIVE
    file was created and left in the user's default (ALL-IN-1) directory.
    This took over 26,000 blocks of disk space.
    
    What could be causing ARCHIVE_DOCUMENT to fail (all documents were in
    the folder ARCHIVE).
    
    2) It is my understanding that when a document is restored (using RAD),
    the x-reference (in folder ARCHIVED DOCUMENTS) is removed. This is not
    always happening (ie on some occasions, the x-reference remains). This
    is happening to a number of users.
    
    3) One user appears to have multiple x-references created for archived
    documents - up to 60. He cannot recover the document until he does an
    RAD on each of the x-referenced documents...what is happening here?
    
    4) This one is a question on the way archiving works rather than a
    problem...
    
    
    If a user has a mail message in the shared area and it is archived and
    subsequently restored, the restored copy is placed in the private area.
    
    Thus if multiple users go through this process, what was originally one
    file on the system is duplicated for each user - taking up more space.
    
    As the .ARCHIVE file for each document appears to contain the original
    disk location of the document file, why does the restore process not
    check for the original file (ie recreate in the shared area if the
    original is not there, don't bother if it is...).
    
    Any help/comments appreciated
    
    Andy
    
    

    Hi!
    
    1) The ADS procedure in V2.4 was vulnerable to the NEWDIR problem where 
       the process runs out of memory if there are Global Buffers on the
       SDAF files. This problem is fixed in V3.0 by changing ADS not to use
       NEWDIR any more, though the underlying NEWDIR problem remains.
    
       Another change for the better in V3.0 is that the .ARCHIVE files are
       not created in the user's area, but directly in the archive areas. 
       I don't think either of these changes are in V2.4 patches.
    
    2) The problem of the X-ref not going is explained in 712.8. This is 
       another problem fixed in V3.0, but not in the V2.4 patches.
    
    3) I've not heard of the multiple x-references syndrome. Does the user
       have 60 x-refs for each archived document!? What are the 60 folder
       names - is there a pattern? Does this user run some special program
       the other users do not?
    
    4) The idea of restoring a shared document back into its original
       location sounds good. It will hopefully be considered for a future
       release.
    
    Cheers
    
    Stuart