| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 3540.1 | | IOSG::CARLIN | Dick Carlin IOSG, Reading, England | Tue Nov 16 1993 16:05 | 13 |
| Charly
The decision to copy is based on drawer type / editor type / document
type / full moon etc. It's an IOS client decision, rather than the
FCS's.
You say you have traced it. How does the trace differ from that for a
document that doesn't result in a copy?
Alternatively give me a pointer to the trace and I'll be happy to look
at it.
Dick
|
| 3540.2 | My honest opinion... | VNABRW::EHRLICH_K | I know what I want... | Wed Nov 17 1993 08:10 | 24 |
| Good morning Dick,
sorry for the short (&dirty) topic. I was at customer's site
yesterday to update (patch) his ALL-IN-1 V3.0-1 system.
Normaly, when you're editing a document from a shared folder, you'll
get into the document very fast. You don't see any messages before.
BUt in this case - and it happens random but very often - it seems that
the document is COPIED in the maindrawer of the user - This explains the
'COPYING_DOCUMENT' message. Then you can edit it and after finishing
(F10) it'll be copied back in the drawer.
The document was not reserved by another user before.
Sorry, I've traced it only with trace to terminal. And after rebooting
the system yesterday (better today morning) everything is ok now.
It is very interesting to know why this happend.
Have a nice day
Charly_from_CSC_Vienna_Now_Very_sleepy!
|
| 3540.3 | Try this on a large document | IOSG::CARLIN | Dick Carlin IOSG, Reading, England | Wed Nov 17 1993 10:27 | 20 |
| Charly
I think I know what it might be (and you can check this fairly easily).
I didn't mention it before because I didn't realise the relevant change
had got into V3.0-1.
Since WPS-PLUS takes out an exclusive lock on the document file it
would be prevented from editing if someone else was reading it (because
of the dsab mechanism this only shows up for larger documents).
So what we do is check if someone has an rms lock on the file, and if so
we make a copy for the editor to work on.
This means that the reader is looking at a version that is about to be
obsoleted, but this is a necessary consequence of sharing drawers. We
could warn the reader but it is only marginally different to the case
where the reader reads and, microseconds later, the updater updates.
So we don't :-)
Dick
|
| 3540.4 | Yeah! You're right... | VNABRW::EHRLICH_K | R.J.DIO live in Vienna(4.12.)! | Wed Nov 17 1993 11:25 | 15 |
| Dick,
many thanks for the details. Yes that's the point. I've seen
in the trace (sorry, i'Ve forgotten it) the LOCK = EXCLUSIVE will
be checked first.
I've reproduced this here on our cluster, you're right!
A warning would be nice. (:==:)
Thank you very much again, brilliant!
Dick, have a nice day!
Cheers
Charly
|
| 3540.5 | Not READ only -> CIB ! | VNABRW::EHRLICH_K | R.J.DIO live in Vienna(4.12.)! | Wed Nov 17 1993 11:41 | 7 |
| Hi Dick,
Another user needs not reading the document, you'll see this 'behaviour'
when it's selected in the CIB, too.
Cheers
Charly
|
| 3540.6 | | IOSG::CARLIN | Dick Carlin IOSG, Reading, England | Wed Nov 17 1993 14:30 | 8 |
| Charly
All I can say in my defense is that the situation was worse before
V3.0-1. The edit would not have been able to go ahead.
Cheers
Dick
|
| 3540.7 | The CIB answer | IOSG::CARLIN | Dick Carlin IOSG, Reading, England | Wed Nov 17 1993 14:52 | 11 |
| Re .5
Aha. I've just worked out what the CIB is :-) We've handled this
separately in that we no longer lock what is in the context block
(until you start doing an operation on it of course). So, if someone
else has a document just sitting in their context block, you will be
able to delete/refile/edit it etc, and the edit won't copy.
Unfortunately that one didn't make it into V3.0-1.
Dick
|