Conference iosg::all-in-1_v30

Just a bit more info.
    
PRR for archive area 3 on MUA4: gives a better error of :-
    
%OA-I-LASTLINE, Restoring document from - ARCHIVE$AREA_000003:CARDWELL16290
02863.ARCHIVE for user - CARDWELL_RM
%OA-I-CAB_CANT_FIND, The current File Cabinet document cannot be found
%OA-W-ARCNOTARGET, Target document cannot be found DOCNUM="000000"
%OA-I-LASTLINE, Failed to restored document ARCHIVE$AREA_000003:CARDWELL162
9002863.ARCHIVE
%OA-I-LASTLINE, Selected users' files restored
    

For this document there was no entry in the ARCHIVED DOCUMENTS folder but I 
don't think that matters does it ? I removed the .archive and .archive_body 
from disk and tried again after crossfiling the document into the
ARCHIVED DOCUMENTS folder but the same happened - it restored to the disk but
not to the users's file cabinet.
I also removed an old version of ARCHIVE_RESTORE_USER_DOCUMENTS (which I 
assume is used) and recompiled the CMTXL.

Any ideas ?
    
Thanks,
    
Clive

RE .0,.1

In the data set archive_docs_pending_recovery what is the value for field 
.DOCNUM for the document that is being restored and can you select this for 
the target drawer. A blank value for drawer indicates the users default 
drawer 'main'.

If this docnum value cannot be selected then this is probably your problem.

Also if there are any versions of archive_restore_user_request.scp that are 
prior to version 3.0 you should get rid of them since the only similarity 
between the 3.0 version and the 2.3/2.4 versions is the name of the file.

-Paul

Hi Paul,


	I had the customer add {username]MAIN in the 
archive_docs_pending_recovery and re-try. This time it
worked! Shouldn't the PRR option add this prior to
restore so 2.4 documents are able to be restored? or is 
it likely that a postinstall function failed etc??

-Trev

Hi,

	I have just located a script that gets run during
the latter stages of installation:

oa$lib:arc_pend_conv.scp

	This is responsible for updating the drawer
field. I got the customer to take the For loop near the
bottom into a new script and run that, this changed the
drawer field and the customer should now be able to 
process the rest of the outstanding requests without
too much trouble.

	However, this run of the script is only going to
be useful on the current outstanding requests, it will
need to be run on all future requests as well!! at least
this beats him manually changing the records, which he
was planning to do!!

	Perhaps a /pre function on the PRR option to run 
this new script may help...for the future requests and
to reduce manual involvement.

-Trev

    My customer has also successfully recovered his archived documents by
    running the FOR loop to update ARCHIVE_DOCS_PENDING_RECOVERY dataset.
    He would now like to know (if possible) why some of his 2.4 documents
    do have the drawer field already (in ARCHIVE_DOCS_PENDING_RECOVERY) and 
    some don't ?!
    
    Any ideas ?
    
    Thanks,
    
    Clive 

Hi,

Please can someone explain why some v2.4 documents that are archived and then
restored under v3.0 get the drawer field filled and yet others do not! My
checks have covered analysis/comparisons of user profile records and partition
entries - nothing different has  showed up so far.

Comments on this problem are welcome as we now have 4 sites (all the same
customer!) with the problem.

-Trev

    Hi,
    
    I've searched the archive scripts and only found one that writes new
    records to ARCHIVE_DOCS_PENDING_RECOVERY, which is
    ARCHIVE_RESTORE_USER_DOCUMENTS.SCP. Even here there is only one place,
    and I can't see how it could go wrong.
    
    What I recommend you do is the same, and see whether you have some
    customisation writing to this file and not adding the drawer field.
    
    Failing that turn tracing on the restore request and see if any error
    messages are reported.
    
    Cheers
    
    Stuart

    I have the same problem with one of my customers; a large number (231) of
    documents in ARCHIVE_DOCS_PENDING_RECOVERY with no value in the DRAWER
    field.
    
    When the PRR option is run the documents fail to be restored
    and each one gets a "ARCNOTARGET" error.  It appears that the PRR code
    is looking in the MANAGER's MAIN drawer (because the CAB SET_DRAWER is
    called with a null parameter) and does not find the DOCNUM it's looking
    for with the CAB SELECT function (but this doesn't get checked very
    well does it?).  The script charges on regardless and tries the restore
    the document to a non-existant target and thus spits the dummy with the
    ARCTOTARGET error message. 
    
    These requests seem to have originated from about half a dozen
    different users some of whom seem to have subsequently done succesful
    requests.  The documents in question have all been created AFTER the V3.0
    upgrade. (Version of ALL-IN-1 used currently is V3.0-1)
    
    Nothing appears out of the ordinary with these user accounts or their
    drawers.
    
    SO the question is... WHY does this happen?  I've looked at the script
    that adds the record into ARCHIVE_DOCS_PENDING_RECOVERY and it would
    appear to get the value for the DRAWER field from the
    OA$CURDWR_LOCATION symbol - under what circumstances could this be
    blank?
    
    The customer is currently evaluating ALL-IN-1 archiving and needless to
    say are not very impressed at the moment!
    
    I've fixed the current 231 blank drawers  by cannabalising the
    OA$LIB:ARC_PEND_CONV.SCP script as suggested in .4 but the problem with
    that is that it assumes that the document originated in the MAIN drawer
    of the person requesting it back (which in V3 may not be so).
    
    One other thing occurs to me; what if the DOCNUM it was looking for had
    existed (but was a different document obviously) in the MANAGER's MAIN
    drawer?  Would the archived document have been restored in it's place
    in the MANAGER's account? Ouch.
    
    And another thing...  if a user requests a document back from OFFLINE
    then deletes both references to it from their file cabinet (i.e. from
    ARCHIVED DOCUMENTS and the original folder) and empties the WASTEBASKET
    - the entry is not removed from ARCHIVE_DOCS_PENDING_RECOVERY and so a
    similar error will occur when the PRR option is run.
    
    Good eh ?
    
    Andy

    Hi,
    
    The OA$CURDWR_LOCATION symbol is set by the CABINET SET-DRAWER
    function, and is set to the key in the PARTITION file.
    
    Can you run the following checks please:
    
    A) Run the PT (pre-test) housekeeping utility. This will check whether
       there is a blank record in the PARTITION file. A key value of spaces 
       would cause confusion here.
    
    B) Enter ALL-IN-1 from the account of one of the user's whose restore
       request has failed. Go to the WP menu with the user's drawer current 
       and type <get oa$curdwr_location. 
    
    C) From the same account ask to restore an offline document, and then
       examine the new record in ARCHIVE_DOCS_PENDING_RECOVERY, and see if
       the drawer field has been filled in.
    
    Thanks
    
    Stuart

    The customer now informs me that the accounts in question have all be
    transferred and renamed a number of times and has suggested that he try
    testing some new accounts that haven't been b*gg*r*d about with.  I'm
    not sure that this is the cause of the problem but...
    
    In the meantime, the customer tested the value of the
    OA$CURDWR_LOCATION symbol and it was okay (i.e. [2ARCH]MAIN).
    
    Just a thought, there's not a problem with usernames starting with a
    digit is there ? Something rings a bell...