| Title: | *OLD* ALL-IN-1 (tm) Support Conference |
| Notice: | Closed - See Note 4331.l to move to IOSG::ALL-IN-1 |
| Moderator: | IOSG::PYE |
| Created: | Thu Jan 30 1992 |
| Last Modified: | Tue Jan 23 1996 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 4343 |
| Total number of notes: | 18308 |
It is understood that DECwrite is not supported as running under ALL-IN-1 3.0.
The customer -
STATE OF INDIANA Contact: DAVE SCHOLZ Phone : (317)232-1900
had DECwrite running under ALL-IN-1 2.4 and has done customization to allow
their users under ALL-IN-1 3.0 to still have access to DECwrite where the file
cabinent keeps track of the documents.
The typical ALL-IN-1 user sees typical ALL-IN-1 type screens that allow
them to select/edit and create documents with DECwrite. The documents can
be either DOTS or DECWRITE format.
The following odd FILE CABINET behavior has been observed:
A user will CREATE a DECwrite document. After typing and saving this
document they note that their INDEX shows 2 entries for the document just
created. Both entries are under the same FOLDER and both entries have the
same TITLE. The DATE and NUMBER show different and doing a FULLDB shows that
each entry does reference a different physical file.
Either entry can be selected, edited, and saved with no ill effect. Both
entries contain the same content at all times.
If the user now goes and creates a NEW DECwrite document, save it, and look
at the INDEX they see the new document also has this 2 entry behavior. The
earlier document now however shows only 1 entry (the earlier time-dated one).
This behavior pattern continues so that only the newly created DECwrite
document has the 2 Index entry behavior, and each time a new document is
created the last created document pares down to one entry listing.
Selecting, editing older DECwrite documents (that show under INDEX as 1
entry) all works fine and the 2 entry behavior never reoccurs.
Usage wise there is no physical problem with this. There is concern though
about the stability of the file cabinet around this behavior.
Repeat - the customer realizes their configuration is an unsupported one.
======
What the customer is looking/hoping for is some insight as to why this
behavior occurs and maybe an indication of HOW or IF this can be corrected.
Even if this behavior cannot be changed perhaps an explanation or theory as
to what causes this can be found to reassure them that their file cabinet
will not self destruct or lose documents.
I have discussed this with some others here at the Atlanta Customer Support
Center and so far have no explanation to offer the customer.
My intent is to list this in the ALL-IN-1 Notes conference so those with
knowledge and experience may offer advice/opinion which even though may be
UNOFFICIAL and not SUPPORTABLE may offer insight. Comments people add to
the Notes conference has in the past shown to have great value and depth.
Gary Matthews
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 3432.1 | Need to see the scripts | FORTY2::ASH | Mail Interchange Group, Reading | Fri Oct 22 1993 10:50 | 7 |
Assuming this is a private customisation, then we could only hazard a (probably inaccurate) guess. But if you can post (pointers to, if they're long) the scripts which 'manage the documents in the FileCab', then we should be able to see what the problem is. It does rather sound as if CAB CREATE is being called twice for some reason. grahame | |||||
| 3432.3 | Thanks, and a little more detail | OAMATE::MATTHEWS_G | It's not the years, it's the milage. | Fri Oct 22 1993 17:55 | 29 |
Thanks for the feedback. From my involvement the call is now closed but I will try to not make too many mistakes when I describe the progress the customer made. Dave tells me he had the ALL-IN-1 Services for DECwindows on his system. He copied over the 2 scripts used to handle the document integration into the file cabinet for DECwrite from the MICA piece. Invoking the CREATE or EDIT, the scripts finds out which file to CREATE or EDIT, then depending on whether a CREATE or EDIT was done the script will upon the finish of the edit - check the version number of the file and will delete the old entry if the version has incremented. The 2nd of the 2 scripts seems t be a tidying up procedure. The idea is that now under ALL-IN-1 3.0 these same steps aren't doing the same thing as it did under ALL-IN-1 2.4. Once Dave traces done just WHERE what step is being done he may call our ALL-IN-1 support team to better follow some of the differences in how 3.0 does things compared to how 2.4 did it. A part was purposely left out of the original description (because Dave wasn't sure WHEN or IF it was really happening and if it related to this). That part is that a document would sometimes REALLY just disappear. The current guess is that the DELETE CAB being done on OLD_CURRENT (I think) is somehow getting its signals (or symbols) crossed and deletes the wrong document. Gary Matthews | |||||