Conference iosg::all-in-1_v30

    
    
    Are the target users drawer and the main drawer on the same node?
    If so are they on the same disk?
    
    Theoretically there is no limit to what the server can handle in terms
    of number of requests, realistically you are bound to hit limits, each
    request would get its own thread of execution. Depends on how the
    request was "worded", if the FCS is told to copy this folder and all
    its contents, in one call then this is one thread of execution, if the
    documents are done 1 at a time then it is n threads (n = num of docs)
    
    >What I want to know is to save all this hassle, can we BACKUP 
    >the users OA [...] directory as its her MAIN drawer over to the 
    >target directory's ZK.... sub-directory which doesn't have any
    >.WPL files in there at present, replace all the DOC*.dir's in 
    >there with the original OA directory's DOC*.dir's, DOCDB, DAF etc, 
    >change the ownership etc.
    
    Sounds scary to me, all the DAF records would need to be updated since 
    the filename is the key to the DAF. I will leave the specifics to 
    someone more versed in IOS internals, but it sounds scary.
    
    Can you post the FCS log, you say it is another problem, well it is
    one that needs to be addressed. THe FCS was designed to handle this
    type of thing, also if you turn on FCS tracing it may help, but be 
    warned, if the copy is being done 1 doc at a time (as opposed to
    copying the folder), the trace log will be VERY LARGE.
    
    --Bob
    

    
    >Are the target users drawer and the main drawer on the same node?
    > If so are they on the same disk?

    The original MAIN drawer and target shared drawer is on the same
    node and disk.  The user wrote this UDP to refile all the folders
    in the shared drawer but it started failing when it reached the 
    letter i.  So the user then changed the UDP to refile the documents
    individually.  This still failed intermittently.  The server when 
    compute bound and gobbled cpu so they had to stop/id it and 
    recreate it.  Users then started getting RMS errors (which they 
    did not make a note of) when saving documents.  Rebooting solved 
    the RMS errors.

    They are back to stage one now as they went from backup (not a 
    simple task with 2000 documents!) and unless I can come up with
    an alternative method of moving them, they will have to do the 
    RFF again.

    The server characteristics are the default ones.  Can these be
    upped at all?
    
    Log file below.

    Comments, helpful guesses?

    julia




    This is an edited copy of SYS$MANAGER:OAFC$SERVER.LOG.  
    SYS$MANAGER:OAFC$SERVER_ERROR.LOG contains no records.

                                        
    22-NOV-1992 06:07:03.32  Server: V6310::"73="  
    Message: Startup for File Cabinet Server V1.0 complete

    24-NOV-1992 12:07:18.77  Server: V6310::"73="  
    Error: %MCC-E-IN_USE_ERROR, in use error  Message: 
    CsiCacheFlushDrawerAccess; Error from mcc_mutex_try_lock
                                       
    28-NOV-1992 09:38:07.95  Server: V6310::"73="  
    Message: Startup for File Cabinet Server V1.0 complete

    3-DEC-1992 13:17:34.08  Server: V6310::"73="  Error: 
    %OAFC-E-INTERR, Internal error in File Cabinet Server  
    Message: FCS has access violated, please submit an SPR.

    3-DEC-1992 13:17:38.67  Server: V6310::"73="  Error: 
    %OAFC-E-INTERR, Internal error in File Cabinet Server  
    Message: FCS has access violated, please submit an SPR.
 
    3-DEC-1992 15:25:47.03  Server: V6310::"73="  Error: 
    %OAFC-E-INTERR, Internal error in File Cabinet Server  
    Message: FCS has access violated, please submit an SPR.
 
 .          14724 lines of the above error repeated many times removed
 

    3-DEC-1992 15:25:57.17  Server: V6310::"73="  
    Error: %OAFC-E-INTERR, Internal error in File Cabinet Server  
    Message: FCS has access violated, please submit an SPR.

    3-DEC-1992 16:00:03.99  Server: V6310::"73="  
    Error: %OAFC-E-INTERR, Internal error in File Cabinet Server  
    Message: Insufficient memory

    3-DEC-1992 16:00:04.25  Server: V6310::"73="  
    Error: %OAFC-E-INTERR, Internal error in File Cabinet Server  
    Message: FCS has access violated, please submit an SPR.
                                   
    

    
    From what you say, I would GUESS that the fact that you are doing the 
    copy 1 doc at a time caused the insuff mem. Each copy would create 
    a thread and thus context for the thread, all of which requires 
    FCS data structures which take mem. The copies would be done 
    asynch so the could all, or alot of them at least, be active at
    one time.
    
    The best way would be to copy the folders and contents in one call.
    You say you had a problem with this also once you reached 'i'. Is 
    there anything different about this folder?
    
    --bob
    

    Thanks Bob
    
    What does RFF do then - does it call a document at a time or does
    it do it in one go?  If RFF does do it one at a time, how can the
    customer do the RFF in one go?
    
    As far as I know there was nothing wrong with the folder 'i'.  
    I'm making a guess that the memory ran out at this point and caused
    the failure.
    
    julia

    
    I took this a step further.  I created a new drawer on another 
    account and copied my DOC*.DIRs, DOCDB.DAT, DAF.DAT, ACCESS.DAT, 
    RESERVATIONS.DAT, and RESERVE_LIST.DAT plus all my .WPL files 
    to this ZUH......DIR.  I then changed the ownership to match the
    owner of the drawer and I could see my files.
    
    Because I was changing between nopriv's and privs, I accidently
    went in to ALL-IN-1 without any privs (not even TMPMBX or NETMBX).
    I could read the documents but any modification I made would be 
    saved OK, but gave the error (Gold W):
    
    %OAFC-I-DSLERROR Communication error has occurred.  Refer to 
     extended status for network error code
    
    Where is the extended status and how could I have found out a 
    decent error?  Putting tracing on the filecab did not show any
    errors and returned a normal completion status.  There were
    no errors in the filecab logs either.
    
    Thanks
    julia

    
    Your network error probably revolves around not having any privs, 
    whenever you want to talk to the FCS, DASL is used. I would bet that
    you need some minimal priv to use dasl, since it is a network product
    netmbx may do it.
    
    as for how to get the extended status, I don't believe you can.
    IOS is not displaying it. OafcDaslError should work the same as
    OafcRmsError for the user. Whenever one of these errors is returned
    from the FCS, the secondary status (status2 field in the status block)
    holds the underlying error. In most cases (if not all) when the status
    is oafcRmsError, IOS displays the secondary status as well. THis is
    a case of IOS not displaying it.
    
    From the UI you can't get to it.
    
    --Bob