Conference iosg::all-in-1_v30

    Hi Jeff,
    
    This is a known problem the RESERVE_LIST.DAT has probably been created
    in the wrong directory it should be in OAUSER (OAUSER is the
    [.<ALL-IN-1 sub-directory name>]).
    
    The user needs this to reserve any documents, ie when using documents
    in the shared drawers.
    
    Regards,
    
    Sunil

    Sunil
    
    Could you tell me what the known problem is please? This file is
    created "on-the-fly" and I wondered what causes it to be created in the
    wrong directory.
    
    Dick

Hmm..I didn't find RESERVE_LIST.DAT in ANY of the user's directories.
We're checking old backup tapes now, hoping to find it.

I still don't understand why she needs that file and I don't in order
to create new docs.

    Re .2 (dick)
    
    I assume that the known problem Sunil refers to is the one in the
    STARS article entitled 
    *User Cannot Reserve Any Documents; 'file not found'        
    It may be known to you as THR-16019
    The problem outlined there is listed as fixed in v3.0-1
    
    Regards,
    
    Andrew.D.wicks

This problem gets a little more interesting....

Every time the user tries to create a document and gets the error
"file not found", a new empty document does get created!
This document cannot be edited, it cannot be deleted because
it is marked "RESERVED", and it cannot be Unreserved.
Trying to do a URV generates the error:
Error opening SCRIPT file "FC_RESERVE_LIST_CREATE"
The document has not been unreserved

Again, she has no RESERVE_LIST.DAT file.  We checked the backup
tapes from 5 weeks ago until today and there was no RESERVE_LIST.DAT
file in any of her directories.

Still looking for help.  Thanks.

    Hi,  
    
    I have come across another problem that was very similar.  What we
    found for the hand full of users who had the problem after the upgrade
    to 3.0, was the dreaded rooted logical (also know as virtual disk).
    
    Please check the directory specification in PROFILE and ensure that
    it's not using rooted logicals.
    
    Regards,
    
    Sunil

    (.0 and .5)
    
    Jeffrey (is that right?)
    
    We have an optimisation that says if you are editing in a drawer that
    hasn't been shared then its not necessary to reserve the document and
    therefore we don't need a RESERVE_LIST. This particular customer must
    have shared their drawer which is why they get the problem and you
    don't. I wonder if you could trace the whole document creation and give
    me a pointer to the output. (Graham will never forgive me if I
    encourage you to post it as a reply, it'll be fairly long :-)
    
    (.6)
    
    Sunil
    
    You could very well be right. I am fixing another concealed logical
    problem at the moment and if this is another then I'll try and fix this
    one as well. Can you remember any more details from when you had a
    failure like this? Given your clue I should be able to see what's going
    wrong but the brain is still suffering from Monday inertia. Perhaps the
    trace will help.
    
    Dick

Well, it's not a problem with a rooted logical.  She uses a
straightforward disk logical that points to a physical drive
(like the others on the system).

I believe I may have fixed the problem by taking an empty
RESERVE_LIST.DAT from another user and putting it in her
[.OA] subdirectory.  Now she has both RESERVATIONS.DAT (which
was always there and has lots of data in it) and RESERVE_LIST.DAT 
(which is empty).  

She can now create new documents (and they don't automatically 
get created with Status of RESERVED).  Also, she can unreserve the empty
reserved documents that were created when she had the problem and delete them.
She's probably OK now, but if anyone can confirm that I didn't really screw 
up then I'd feel better.

Thanks for offering to look at the A1TRACE.LOG, Dick.  If it still makes
sense to look at it then it is open to world access at:
USCTR1::DISK$USER9:[000000]A1TRACE.LOG;1

    Hi Dick,
    
    Re .7,
    
    Hopefully you have overcome your Monday morning inertia by now and the
    brain is speeding along !!!
    
    Well what we found for a few users on the system was that if a logical
    was defined with the concealed attribute the user got an error message
    of "Document file already exists", from what I can remember.
    
    As soon as we changed the directory specification to
    <disk>:[department.user.a1], the users were able to create documents. 
    This happened in the MAIN drawer on an upgraded system.  Please note
    that <disk> is defined as define/system/exec disk $1$duan:.
    
    Regards,
    
    Sunil

    OK it looks as if Jeffrey's problem is the one mentioned in .1 and .4
    by Sunil and Andrew.
    (We used to create this file in the subprocess and if an application
    changed the default directory in the subprocess then it would end up in
    the wrong place).
    
    When I get a chance I'll chase the problem you mentioned in .9 Sunil.
    
    Dick
    
    

    Hi,
    
    I am having the same problem with a user receiving the 'file not found'
    error. The unusual thing here is that they are using ALL-IN-1 V3.0 in a
    two node cluster. They can create mails on one node but not the other
    and there is no reserve_list.dat in the the user's account.
    
    We have just upgraded to V3.0 and as yet I have no idea why the error
    does not occur on both nodes. I have advised the user to connect to the
    node that works as a short-term workaround. 
    
    regards,
    
    Gary.
    

Most 'only on one node' problems can be fixed by running A1V3START.COM

    Hi,
    
    This problem occurs when you forget to install the TXL
    on the second node after installing patch 3.0-1.
    
    3.0 invokes FC_RESERVE_LIST_CREATE.COM to create RESERVE_LIST.DAT.
    The script that invokes FC_RESERVE_LIST_CREATE.COM is in the TXL.
    
    3.0-1 does not use FC_RESERVE_LIST_CREATE.COM (file has a size of 0 blocks).
    
    Regards,
    
    Jan