T.R | Title | User | Personal Name | Date | Lines |
---|
2418.1 | Some questions | IOSG::TALLETT | Gimmee an Alpha colour notebook... | Mon Mar 15 1993 23:02 | 17 |
|
What version of ALL-IN-1 are you running? What language? Is this
a multilingual system? Has the language changed from the old
system to the new system? What happens if you do an index of all
folders? Is there anything in the INBOX? Can you send a mail to
this account to make sure that there is some newmail, and then
see what II does? WHen you say "It tells the user there is new
mail" do you mean you get a newmail broadcast or do you mean
the main screens have "(n mail messages)" at the top?
I think the error was #EMIPH not in library, not #ENIPH, which
would tend to indicate that the BIND is failing, but I'm not sure
why. I'm not sure this problem is related to the fact that the
mail isn't getting delivered, but it might be.
Regards,
Paul
|
2418.2 | Does this pointer help? | AIMTEC::WICKS_A | Oscar the Grouch is an Optimist! | Mon Mar 15 1993 23:13 | 10 |
| Ricardo,
What is the user's Initial form? The only match STARS gave me on this
was the article entitled.
Index Inbox (EM$INDEX$INBOX) Form Does Not Display Users Open Tasks
regards,
Andrew.D.Wicks
|
2418.3 | Problem solved ! | KAOFS::R_OBAS | | Tue Mar 16 1993 00:54 | 12 |
| The problem was solved by creating 4 more mail areas. I thought when
you move a user, documents are unshared. THe user in question still has
some documents pointing to an old mail area. In his profile he is in
oa$sharE (the only mail area in the new system.) We created
oa$sharA,B,C and D and the the problem went away.
This is V2.4, English only, SFCP asset and with customization.
(ALLIN1/NOCUSTOM) did not help.
thank you,
ricardo
|
2418.4 | Fixed in V3.0 | IOSG::TALLETT | Gimmee an Alpha colour notebook... | Tue Mar 16 1993 11:24 | 24 |
|
Glad you could work around the problem!
This is a known problem, which has been fixed in V3.0 of
ALL-IN-1. I also have vague recollections that it was also
available as a V2.4 patch, but I'm not certain.
Note that this problem only happens if the file cabinet that you
are transferring has some corrupted documents (eg no bodyparts)
which were in a shared area on the source system that doesn't exist
on the target system (eg on source system a document pointing to
OA$SHARA:Zmumble.TXT and the file doesn't exist, and on the target
system OA$SHARA: is not a valid shared area). V2.4 Transfer User
incorrectly leaves the bad pointers in the DOCDB, which causes the
target system to barf on the bad shared area reference. In V3.0
both Transfer User was fixed to not leave the pointers, and the
cabinet handling fixed to not barf on bad pointers.
The documentation recommends you run the file cabinet repair
utility before running transfer user, which would have fixed up
the filecab before this problem could happen.
Regards,
Paul
|