Conference iosg::all-in-1_v30

    Charly,
    
    Amongst other matches STARS shows me note 453 - it seems like the
    same question.
    
    Regards,
    
    Andrew.D.Wicks

Dear Andrew,

I've looked in STARS and here in this conference before I wrote this one, 
but with no success. The only note I've found is 436, which gives you an 
info about RESERVATIONS.DAT and RESERVE_LIST. Note 453 has nothing to do 
with my 'challenge'.

Again, maybe my explanation is not the best, so I try it once more.

The CIB of WP for my document:

[USERA]MAIN
TEST
Testdocument
Karl Ehrlich
01.Jun.1993
000001		RESERVED

USERB is doing an E or RSV and gets the message:
Already reserved by Karl Ehrlich on node VNADC on 02-Jun-1993 09:59am

Then I unreseve this document with URV.

So, now my question again, is there any possibility to find out, who has
done the last reservation of this document. (It is really neccessary because
the customer would like to see who has done the last modification of this
document!!!)

And AFTER an unreservation the entry in RESERVE_LIST and RESERVATION.DAT is
deleted and there happens no change to DOCDB.DAT. Therefore you never can
find this info. 

I hope it's now clear and easy to understand what I (and the customer)
really want to know. 

Best regards
Charly_from_CSC_Vienna

    Hi,
    
    After the UNRESERVE the information about who last reserved the
    document is deleted. To provide the information you want, and possibly
    extending to allow full auditing, would require a significant
    unplanned development to the File Cabinet Server. 
    
    No workround is going to be satisfactory. If your users are WPS-PLUS
    users then they can keep their own audit trail within a document by use
    of a COMMENT control block. A UDP could be done to make this a bit
    easier.
    
    Cheers
    
    Stuart

    Hi Stuart,
    
    	thank you very much for taking advice of this. Yes, that's what
    I've thought when I was looking for reservation in Tonys Book.
    
    It will also be a hard work NOT to delete the records in RESERVE_LIST
    only setting the TYPE to soemthing like F (for free again). Then you
    can get the info 'who was the last reservator'. This was in my mind
    yesterday night.
    
    But will this ever work, I don't know.
    
    Best regards
    Charly
    
    Ps: I've built a new menu option to get the owner of a reserved
    document and it works fine. So you need not do an Edit or RSV to
    get the message.
     

    Hi Charly,
    
    Changing RESERVE_LIST.DAT would not help, since that is a list of
    documents that a user has reserved. In this case it's who reserved the
    document, and this is held in RESERVATIONS.DAT. This file is
    exclusively accessed by the File Cabinet Server.
    
>    Ps: I've built a new menu option to get the owner of a reserved
>    document and it works fine. So you need not do an Edit or RSV to
>    get the message.
    
    GOLD V already does this!
    
    Cheers
    
    Stuart

    Stuart,
    
    	oh, what a good feature. It's really nice!
    
    Best regards
    Charly
    
    
    

    Hi Stuart,
    
    	yesterday I was looking for an easy solution for this 'challange'.
    Well, if customer will pay for it, why not.
    
    I will save the the entry from RESERVE_LIST (but not all values, only
    docnum,owner,maybe date) in an other file. This will happen, if the
    user is doing the UNRESERVE menuoption, before all info in
    RESERVE_LIST and RESERVATIONS.dat is going to be deleted.
    
    And of course it's nice to have an own ENTRY&INDEX form for this file
    where the user can have a info who has ever reserved documents.
    
    Hopefully I haven't forgotten something, have I ??
    
    Best regards
    Charly

    Hi Charly,
    
    The information about who reserved, unreserved, or replaced a document
    will need to be recorded on the system where the document lives. You
    may have a scenario where a remote user edits a document and then it's
    no good recording this information on the remote system, since the
    local users would not be able to access it.
    
    Ideally there would be an audit file per drawer and a drawer attribute
    asking for auditing. But who would have the privilege to write to a file
    in another user's directory, perhaps on another system? Answer - the
    File Cabinet Server. For this reason I believe that the problem can
    only really be solved by an extension to the File Cabinet Server.
    
    If you want to provide a local-only solution then you are slighly
    better off. You could provide an audit file, either per drawer or per
    system, that would be written to local users. But you would need to
    worry about file protections, since you will not want to provide world
    write files. This may lead you into the world of code level
    integrations, where you can use ALL-IN-1's installed privileges to get
    round the problem.
    
    Cheers
    
    Stuart

    Dear Stuart,
    
    	my thoughts were so easy, but after reading your reply, I'm
    'voiceless' and great surprised now.
    
    Well, the best will be, that I join to you (IOSG).
    
    Stuart, it was very very kind to bring me some light in my darkness.
    In most cases, easy wishes can be very difficult to implement, when you
    don't know what's exactly behind the scene.
    
    CLI is another story!
    
    Bye for now
    Charly_the_darkside... 

    
    
    and don't forget TeamLinks. Any solution you do that does not
    involve the FCS runs the risk of TeamLinks not working with it.
    
    --Bob