Conference iosg::all-in-1_v30

    
    re .0
    
    Yup, all is fine.
    
    >KAOT01$SRV73    206054A0  [ALLIN1.DATA_SHARE]KAOT01$SERVER73.DAT;1
    >KAOT01$SRV73    206054A0  [ALLIN1.DATA_SHARE]PARTITION_MASTER.DAT;1
    >KAOT01$SRV73    206054A0  [ALLIN1.DATA_SHARE]PARTITION.DAT;2
    >KAOT01$SRV73    206054A0  [ALLIN1.DATA_SHARE]OA$SHARED_DAF_MASTER.DAT;2
    >KAOT01$SRV73    206054A0  [ALLIN1.SHARED_E]OA$DAF_E.DAT;2
    >KAOT01$SRV73    206054A0  [ALLIN1.DATA_SHARE]OA$SCRIPT_COMPLETION.DAT;1
    
    THese are all system files and will always be open when the FCS is
    open. You should also have seen SYSUAF and NETPROXY.
    
    >KAOT01$SRV73    206054A0  [LAYERED.R_OBAS.A1]DOCDB.DAT;6
    >KAOT01$SRV73    206054A0  [LAYERED.R_OBAS.A1]DAF.DAT;6
    >KAOT01$SRV73    206054A0  [LAYERED.R_OBAS.A1]RESERVATIONS.DAT;1
    >KAOT01$SRV73    206054A0  [LAYERED.M_BARNEY.A1.ZUQZFGEVE]DOCDB.DAT;1
    >KAOT01$SRV73    206054A0  [LAYERED.M_BARNEY.A1.ZUQZFGEVE]DAF.DAT;1
    >KAOT01$SRV73    206054A0  [LAYERED.M_BARNEY.A1.ZUQZFGEVE]RESERVATIONS.DAT;1
    >
    
    These are the files related to two drawers. The FCS does not maintain
    context of who has what drawer open. It keeps drawers open until they
    are flushed from teh cache. Opening files is an expensive routine, so
    once open, it stays open. The FCS does not know that userx has drawery
    open, so when userx leaves, drawery stays open.
    
    --Bob
    

    
    Bob,
     When and how are they flushed from the cache ? My customer apparently
     is having difficulty to transfer users because of the scenario in .o.

    
    re .2
    
    have him shutdown and re-start the server, this will close all the 
    files.
    
    --Bob
    

    
     That was my first suggestion. Shutdown FCS, do PAt and do same thing
    when doing daily backups but they won't take it. Oh well, they're
    customers and they have all the right to complain and we are here
    to listen.
    
    Thanks Bob.

    Hi All,
    
    A customer here has reported a problem with actual documents being left
    open by the FCS.  The document status is blank (not RESERVED) when the
    user goes to edit or read the document a message is displayed "Document
    in use", doing a show device/files shows the document being open by the
    FCS.
    
    So far we have not seen any error messages in the logfiles.  The
    customer has had to shutdown the FCS and restart it, which is very
    inconvient and disrupts service to their users.
    
    One way around the problem of shuting down the FCS to release the
    document is to do a $convert/share zwhatever.wpl temp.wpl.  Than gold
    get the OpenVMS file into another document but this does not guarantee
    the consistency of the output file on the other hand it saves you from
    shuting down the server.  A suggestion made by Hong.
    
    So the question is, what would cause the FCS to not close the file and
    ALL-IN-1 to update the document status to blank ?  I asked the usual
    question did they exit out of ALL-IN-1 abnormally etc.  and the answer
    was no.  Is there anything people in FCSland would like us to get for
    them to pin point the cause of the problem ?
    
    Regards,
    
    Sunil

    
    re .5
    
    Is the document in a shared drawer? Could another user be accessing
    the document also?
    
    Are there any thread access violations in teh server log file?
    (Ok, so this one is a wild guess)
    
    --Bob
    

    
    Bob & all,
    
    I have seen this problem a few times here in IOSG, and sometimes it
    does correspond to a thread accvio being logged. However, I haven't as
    yet found a way of being able to reproduce it reliably. I also know
    that there are cases when this happens and nothing is logged, so it's
    not easy to track down. If anyone has been getting this, and can
    reproduce it at will, I'd be very interested to know.
    
    We're looking into it.
    
    Kevin.
    
    

    G'day Bob, Kevin and All of you,
    
    Bob the customer does not get any error messages in the logfile as
    reported in .5.  What Kevin has said is exactly what is happening at
    the customer site and we have not been able to reproduce the problem it
    happens randomly to different users. This site has VAX 7000's installed
    in a cluster and have 5000 users registered and typically they will
    have about 500 to 300 users per node.
    
    As Kevin has said it's going to be hard to tack down this problem
    because it happens randomly to different users and there is nothing in
    the logfiles.  I have asked the customer to enable tracing and the
    trace files are purged at the end of the day due to the size of the
    files.  If any other tools or tricks of the trade can help let me know.
    By the way the customer has not had any problems for two weeks.
    
    Regards,
    
    Sunil
    
    PS - My winter holiday was great it was only 25C and the water was not
    too warm around 20C or above, it was sunny :-).