Conference iosg::all-in-1_v30

       Hi Sau Ha,

       Yes you're right RESERVE_LIST.DAT is per user and
       RESERVATIONS.DAT is per drawer. RESERVE_LIST contains an entry
       for each document reserved by the user in any drawer.
       RESERVE_LIST is not documented with the data sets as it has a
       corresponding entry form RESERVE_LIST. We only document data
       sets that don't have a corresponding entry form.
   
       RESERVATIONS.DAT stores information about any documents from
       that drawer, which have been reserved.

       Note that RESERVE_LIST stores the ALL-IN-1 user name and not a proxy
       names, as in RESERVATIONS.DAT, so RESERVE_LIST makes it easier
       to see who has reserved what.

       The FULLPATH fields on the RESERVE_LIST form refer to the
       identifier (in DNS readable format) of the drawer containing
       the reserved document. The other fields should be fairly
       clear.


       Catrin.

    Hello Catrin,
    
    Thank you for your reply. 
    
    What about the fields for RESERVATION.DAT? I didn't find it in the list
    of dsabs. From what I can see in the management guide, there isn't much 
    info on the data files. Does that mean we should try not to 'touch' the 
    data?
     
    
    regards, 
    Sau Ha

    
    Nope, you should not try to 'touch' the data in reservations.dat, it
    is used by the FCS to keep who has what reserved and what can be
    unreserved etc.
    
    --Bob
    

    Well, Catrin and Bob have explained things fine but I'd just like to
    emphasise the distinction between the two.
    
    RESERVATIONS.DAT belongs to, and is maintained by, the server. Clients
    like IOS don't directly read it or write to it**. What I mean by that
    cryptic statement is that the FILECAB GET_ATTRIBUTES function may
    request some attribute values, through OafcList, that can't be found in
    the DOCDB and have to be extracted from the corresponding
    RESERVATIONS.DAT entry by the server. Also the identity of the reserver
    ( node/ALL-IN-1username for the IOS client) which is passed via the
    RESERVED_COMMENT field in reservation functions is maintained by the
    server in RESERVATIONS.DAT. By the way Catrin, that's the only thing I
    want to pick up on your explanation - the ALL-IN-1 user name ends up in
    RESERVATIONS.DAT, there is no need for it in RESERVE_LIST.DAT if you
    think about it.
    
    [** Like all good rules this one is broken. The IOS client has extended
    filecab mending to include reconciliation of MAIL_STATUS and
    RESERVATIONS.DAT which may necessitate directly writing to the latter.]
    
    RESERVE_LIST.DAT belongs to, and is maintained by, the IOS client and
    implements the reservation model (explicit/implicit reservation, error
    recovery etc) so it is hoped that other clients will adopt a similar
    model. Also it is a useful aide-memoire that enables a user to find
    everything they have reserved, without trolling round the planet
    checking drawers everywhere.
    
    With reservation information stored in 2 different places (well 3 if
    you count the MAIL_STATUS field in the DOCDB) there is scope for things
    getting out of sync. The golden rule is that RESERVATIONS.DAT is
    considered the fount of all true knowledge. For example if the IOS
    client is asked to unreserve a document it doesn't bother to look in
    RESERVE_LIST.DAT to see if there is an entry; it just goes ahead and
    requests the server to do it. Obviously it then deletes the
    RESERVE_LIST.DAT entry if all goes well.
    
    Dick