Conference iosg::all-in-1_v30

    Hi Ricardo,                                                       
    
    >"An error has occured, submit an SPR"
    
    Can the user do a GOLD W to get more information ?
    
    Have you checked the logfiles in SYS$MANAGER, namely the
    OAFC$SERVER_ERROR.LOG ?  If you can search through this file for the
    date and time this problem occured there might be more information to
    help point to the cause.  By the way if this logfile is quite large you
    can roll it over by renaming it to *.OLD and a new one will be created
    by the FCS.  We also have the tracing option but we can leave that
    aside for the moment.
    
    >So they will kill the FCS process and re-start and the problem goes away 
    >and may not happen again for another week.
    
    What version of ALL-IN-1 IOS do they have ? Is it 3.0-1 ?  I am
    guessing that the cache get's trashed for some reason.  I have had
    similar problems at customer sites and we have had to stop and restart
    the server.  
    
    If you find that you are having to stop/restart the server every week
    during core or prime time than there are two options that will cause
    less distruption.  These are:
    
    1. Stop and restart the server after hours some of my customers are
       doing this.
    
    2. Have multiple servers running useful at large sites and assign users
       to the server as required.  You will need to define the logical
       OAFC$SRV_OBJ nnn, to point the user to the server of choice.  See
       topic 3137 for more details.
    
    I am sure Uncle Bob will have alot more to say and my remarks are there
    to help you trace the problem and narrow down the possiblities.
    
    Regards,
    
    Sunil

    
    The only thing I have to say is:
    
    Check sys$manager:oafc$server.log as well as oafc$server_error.log.
    
    If you feel you can reproduce this (you imply you can with the GMA),
    then turn on FCS tracing and reproduce, format the trace file and 
    include it in the spr and/or put it in here. Please try to keep the
    amount of time the trace is on minimized as the trace file will get
    very big, very fast.
    
    --Bob
    

     Sorry I was not very clear in .o.
    
      Te problem occurs when a user with shared drawer (gma to another
    user...but the granter is the one creating a message, not the user
    granted.) Unfortunately after the re-start, the problem can
    longer be reproduced, it will work for a period of time @3 weeks. So he 
    does'nt want put a trace. We will wait for another occurence unless 
    anybody is interested in the previous logs.
    

    G'day,
    
    Re .3.
    
    I think that you should still search the logfile for the date and time
    of the occurance of the problem, than give us a pointer to the logfile
    or copy a small portion of it in a reply.  We may have enough
    information to work on if not we maybe able to give you further trouble
    shooting hints and tips.  So in short I would say it's a good idea to
    examin the old logfiles and what would be really helpful is a sequence
    of events, leading upto the problem.
    
    The only reason why I am interested in the logfiles is to get some idea
    of why this problem has occured.  The sooner we get a clue as to why
    this is happening the sooner we will get a fix in a PFR.  Yes be
    selfish and post the information :-).
    
    Regards,
    
    Sunil

    
    We are talking about two files here, the one sunil is talking about
    is always a good idea to look at when problems occur. The FCS should
    be writing unexpected things to that file, it theoretically would be
    empty at all times for a perfect FCS.
    
    The one I want is the FCS trace output. I agree, don't run with it on
    all the time. Next time the problem occurs, turn trace on and do the
    steps to get the problem, then turn trace off. Post that file here.
    
    --Bob