Conference iosg::all-in-1_v30

    Hi,
    
    Some questions:
    
    1. Does it consistently fail on user SCHUSTER, or will it fail
       somewhere else if you run it again? If no then go to question 4.
    
    2. Run TRU for this user and see if there any errors.
    
    3. Does you customer use the Department field in the profile? If not 
       then you could temporarily put all other users in DEPTA and 
       SCHUSTER in DEPTB, and run ADS for DEPTA, and see if it
       completes. Then try DEPTB.
    
    4. The actual error message %OA-W-NOARCAREA comes from the
       ARCHIVE_DOCUMENT function and usually means there is something wrong
       with the archive area. Can the user SCHUSTER use ADN to archive the
       documents successfully? 
    
    5. Type SM MAR and inspect the open archive area. Check the archive
       area logical is OK.
    
    6. Do a $DIR OA$LIB:ARC* and $DIR OA$DO:ARC*.SCP and see if there any
       customisations. 
    
    7. I hope you are fully recovered!
    
    Cheers
    
    Stuart

    Stuart,
    
    	... what a great reponse.
    
    I've also looked for the errormessage and found that the problem must
    be in OA$DO:ARC_PROCESS_FOLDER.SCP
    
    .if #arc_sts eq #not_enough_diskquota then -
      .goto get_next_document

    oa$fao OA$_ARC_ARCHIVE_DOC, "#message", #adkey:6:30, #arc_title
    .text #message

    archive_document  #arc_name
    .if oa$status eq 0 then -
      do arc_signal_error \-
      get #arc_sts = #archive_error -
    else -
      increment #arc_count 

    Hhmmm, well, customer will run ADS only for SCHUSTER account tonight,
    to see if there's a problem only with that particular account.
    
    I'll do what you've suggested.
    
    Stuart, yes my recoveryphase (shadowcopy or updatebrain) is done. I'm
    really happy to be back here. Thank you much!
    
    Cheers
    Charly
    

Stuart,

here're my answers to your queries:

>    1. Does it consistently fail on user SCHUSTER, or will it fail
>       somewhere else if you run it again? If no then go to question 4.

It fails with other accounts, too. Customer has done a test with his 
account only, just the same result. NOARCAREA!!! But no LIB$GET_VM errors.
    
*** Protokoll f�r Archiv-Wartungsprozeduren 03.Nov.1993 ***
*** Beginn: 10.00 ***
******
Bearbeitetes Fach - [ERTL]STANDARD
Abteilung         - ARCHIVTEST
------
Bearbeiteter Ordner - TEST
Das Dokument 000368 KOPF BMGSK wird archiviert.
%OA-W-NOARCAREA, In der Kommandozeile wurde kein Dateiname f�r die Archivierung
angegeben.
Das Dokument 000296 dusek2 wird archiviert.
%OA-W-NOARCAREA, In der Kommandozeile wurde kein Dateiname f�r die Archivierung
angegeben.
Das Dokument 000294 dusek wird archiviert.
 Buf
%OA-W-NOARCAREA, In der Kommandozeile wurde kein Dateiname f�r die Archivierung
angegeben.
Das Dokument 000293 test wird archiviert.
%OA-W-NOARCAREA, In der Kommandozeile wurde kein Dateiname f�r die Archivierung
angegeben.
Das Dokument 000201 Zeichensatz-FAX wird archiviert.
%OA-W-NOARCAREA, In der Kommandozeile wurde kein Dateiname f�r die Archivierung
angegeben.
Das Dokument 000200 Testfax - vorl.endg�lt.Version wird archiviert.
%OA-W-NOARCAREA, In der Kommandozeile wurde kein Dateiname f�r die Archivierung
angegeben.
TEST : 6 zur Archivierung markierte Dokumente - 0 archivierte Dokumente
***  1 bearbeitete F�cher - 1 bearbeitete Ordner ***
*** 0 archivierte Dokumente - 0 archivierte Bl�cke ***
*** Ende: 10.03 ***
*** Ende des Protokolls f�r Archiv-Wartungsprozeduren ***
 
>    4. The actual error message %OA-W-NOARCAREA comes from the
>       ARCHIVE_DOCUMENT function and usually means there is something wrong
>       with the archive area. Can the user SCHUSTER use ADN to archive the
>       documents successfully? 

Yes, ADN (in German SOA) works fine. Documents are archived. 

>      5. Type SM MAR and inspect the open archive area. Check the archive
>       area logical is OK.

It should be ok, there are 5 documents in it and approx. 600000 (!!!) Blocks
free.

But which logical do you mean ? 
    
>    6. Do a $DIR OA$LIB:ARC* and $DIR OA$DO:ARC*.SCP and see if there any
>       customisations. 
    
HHmmm, there're NO customisations for archving. 

The doesn't archive with ADN (german:SOA) or ADL (german:DSA). No! The 
manager uses only Enforced Archiving with 180 days delay.

What else can I check now, it doesn't seem to be so easy to find the problem. 

Best regards
Charly

    Hi Charly,
    please check if the devices specified for the archive areas
    are by any chance rooted logicals.
    Cheers,
    	helmut

    Hi,
    
    Helmut may well be on the right track.
    
    The script ARC_CHECK_AREA.SCP defines a logical for the archive area,
    of the form  ARCHIVE$AREA_nnnnnn where nnnnnn is the archive area
    number. 
    
    In the archive_document function it opens the data set
    ARCHIVE_SETS_DATA and gets the DIRECTORY field. It checks that the
    contents of this is the same as the same as the translation of the
    logical defined above. If the result is different then you get the
    error you got.
    
    It's interesting to note that this script (ARC_CHECK_AREA.SCP) is
    called by the ADS housekeeping procedure, but *not* by the interactive
    ADN (archive document now function). 
    
    So what I recommend you do next is to exit and re-enter ALL-IN-1 and
    run the following script:
    
        get #success = 1
        get #no_run_key = 10
        get #archive_area_full = 12
        get #no_active_areas = 14
        get #blank_folder = 16
        get #not_enough_diskquota = 18
        get #cannot_select_doc = 22
        get #archive_error = 24
        get #file_not_found = 26
        get #no_run_rec = 28
        get #bad_drawer = 30
    
    get #arc_dir_lim="1000"
    get #manager="MANAGER"
    do ARC_CHECK_AREA
    
    When this has run type <SPA and then $SHOW LOG ARC*
    
    This will show the translation of the archive logical. Now back to
    ALL-IN-1 and type <FORM ARCHIVE_SETS_DATA and bring up the record for
    the arcive area. The DIRECTORY field should have the same value as the
    logical, but does it?
    
    Cheers
    
    Stuart

    Helmut&Stuart,
    
    	>please check if the devices specified for the archive areas
        >are by any chance rooted logicals.
    
    That was a good idea. I logged into customers system to check
    everything. I've looked at the archive_areas and didn't see anything
    wrong. 
    
    It was simple DUA5:[AIOV30_ARCHIV1].
    BUT ...
    DUA5 was not a device name it was a logical pointing to $1$DUA5:
    AND
    it was NOT defined /system/exec/trans=(conc,term)
    it was defined only /system/exec.
    After correcting this logical everything's fine - I've done a quick
    test to see if it's really working.
    
    Thank y'all for your good ideas!
    
    Best regards
    Charly