Conference iosg::all-in-1_v30

> ...  so it should be possible to to do the copy back automatically.
    
    That's the way it should work. The next time you go in and edit, it
    sees you already have it reserved and suspects that something is amiss.
    Therefore it presents you with the copy to continue editing on. When
    you complete the edit the edited copy will be written back to the
    remote document.
    
    So you shouldn't need to GOLD-GET. Let me know if this doesn't work for
    you in BL123.
    
    Dick
    

Dick,

I tried the following with 2 BL123A systems...

Create a document in a shared drawer on NODEA and grant access to a user on 
NODEB (via a proxy on NODEA).

Edit that document from NODEA. A copy is made and placed in the 
RECOVERED DOCUMENTS folder of the user's MAIN drawer.

Abort the edit session using Ctrl-Y

Go back into ALL-IN-1.

The local copy is there as expected.

Try to edit the remote document again (which has a RESERVED status) and I
get the error message I would expect if some-one else had edited it. i.e.

Already reserved by PORTER_T on node NODEA on 08-Apr-1992 05:20pm

I am PORTER_T on NODEA.

I tried using the PRC option but I then get the message 

System reservation, use URV to unreserve

Is this a bug, or am I doing something wrong?

Terry

    I got a bit confused with the NODEA and NODEB. Is there a typo? If you
    edit from NODEA then it's a local edit. Also which editor is it?
    
    I just tried WPS-PLUS editing a remote document with BL123a, killing
    the ALL-IN-1 session, restarting ALL-IN-1 and re-editing and it seemed
    to be ok.
    
    The only problem I know is for WPS-PLUS editing a remote .TXT document.
    In this case you have unfortunately lost any edits before the crash (I
    don't look for the .WPL conversion).
    
    In your example are you logging in from different systems, in which
    case you will look like two different people?
    
    Dick

Dick,

Yep there was a typo I was editing the document from NODEB.

However I went back and re-tested it again and it works OK now ???????? I even
re-edited the document that was failing yesterday and that worked. I think I 
will find a nice dark room and lie down for a while ;^}

Is FAL involved in this process? There was a problem with FAL not working when
I first did the testing (mis-matched passwords in NCP and SYSUAF) but I ignored
this as I thought ALL-IN-1 used the FCS for remote document access.

I have since learned that ALL-IN-1 uses FAL to read a remote document if that 
document is not in a mail area so maybe some of the checking that is done here 
relies on FAL working?

Regards,

Terry

    Starting with a version following closely after Diamond (is that
    obscure enough?) we are using FAL much less and switching to functions
    like put_data and get_data which use the FC Server's internal protocol.
    Also remote reservation will copy to a document rather than use a
    FAL-based file export.
    
    Having said that, it doesn't look like a FAL problem in this case,
    perhaps it was just being on different systems (user naming has a long
    way to go).
    
    Dick

Dick,

Now that I have got the recovery to work it seems to be over enthusiastic ...

I reserved a document in a remote drawer with a copy (RSC) putting the copy
in my local MAIN drawer. I can now happily edit the local copy. If I try to
edit the remote copy (I forgot I had a local one) instad of telling me to
edit my local copy (as it does if the reserved document was in a local drawer)
the edit works and I end up in the editor, but with the content of the local 
copy. When I exit the editor the original is updated and the local copy deleted
but the original remains RESERVED (it is now as if it had been reserved
without a copy).

It seems like ALL-IN-1 does not distinguish between an implicit reserve 
with copy of a remote document that has failed to replace the original, and
an explicit reserve with copy on a remote document.

And now for the twist in the tail (or tale ?). If when I do the reserve with
copy I put the copy in the remote drawer (which is the default) then when I
try to edit the original document I get into the editor but with a blank
document (no error messages). When I exit from the editor anything I have
entered in the edit session is lost and the content of the copy is put back
into the original and the copy is deleted.

What is the intended behaviour? The above behaviour is going to confuse and
upset a lot of customers if we do not change it before Distributed Sharing
is sold.

Terry

Anyone have any comments on .-1 or should I just QAR it?

Terry

    Hi Terry,
    
    Just got back from holiday and caught up with this conference. This one
    is a known problem and has been fixed for a pfr/pfp. You should of
    course be told to edit the copy in all cases.
    
    There has been a gradual transition in the way remote editing is
    handled and unfortunately this problem slipped in as a result.
    
    Dick

    Terry,
    
    A STARS article yes but please no more QARs
    
    regards,
    
    Andrew.D.Wicks