| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 6249.1 | Oh, the pain ... | SPANKY::WALSH | | Wed Mar 08 1995 20:40 | 17 |
| Hello,
I have had very similar experience with MCC-E-RECEIVEerror error
message. This caused a few months of pain on the MCI/NASDAQ project
with MCC on Ultrix. Also the Notification FM would abort i.e. Target
management module thread has aborted. Caused even more pain, sleepless
nights .... However, these problems are very difficult to trap.
Fortunately, due to very hard work from MCC engineering in Valbonne,
France, the problems were corrected on Ultrix with MCC V1.4. Great job
engineers!
So the question is were these problems addressed on VMS with MCC V1.4?
Regards,
Mike Walsh
DTN 227-3894
|
| 6249.2 | Rather an AM issue | TAEC::PLENARD | | Wed Mar 08 1995 21:10 | 10 |
| Conrad
From the few things reported, it seems that the Access Module
supporting the entities from which you were expecting notifications
crashed... or reported something nasty.
So, you should rather investigate what happened to the AM.
Rgds
Jean-Louis (one of this team mentionned in re -.1)
|
| 6249.3 | Hmm, this could be tricky | COMICS::PRICEC | I had a life, then I joined the CSC | Thu Mar 09 1995 13:26 | 14 |
| Aaah,
here lies a bit of the problem. The customer has been advised to
upgrade to MCC 1.4, however they store all their MCC attributes in DNS,
and since upgrading their MCC test environment to MCC 1.4 , DNU_OSI
5.1A , their DNS server keeps crashing. The DNS issue is being pursued
by DNS engineering, but this stops them from going to MCC 1.4 .
I shall see what I can extract from the AM for the time being.
Thanks for the replies.
Conrad
|
| 6249.4 | Logging Flags ? | COMICS::PRICEC | I had a life, then I joined the CSC | Thu Mar 09 1995 16:34 | 23 |
|
I've now done some more research, and found that the customer is using
the data collector AM , with several collectors , one in each domain,
as different users have different default domains. The events are sent
from remote collectors , based on remote alarm rules.
I found a reference to logging flags for the mcc_evc_sink process, to
extract more info from the collector log file. My VMS collector log
file already contains some information , but the customer's Ultrix log
file appears to be pretty thin on information even though events are
being received, via UDP (for 2 hours, after which the notification stops).
My question is , what flags can I set to enable fulll logging of the
daemon, to give me some clues as to the cause.
Regards, Conrad
|
| 6249.5 | I nead some help | COMICS::PRICEC | I had a life, then I joined the CSC | Fri Mar 10 1995 21:54 | 34 |
|
The customer has managed to keep the Collection AM running for a longer
period of time if they start the mcc_evc_sink interactively after the
machine has been rebooted. But if they allow the mcc_evc_sink to start
at system startup time , as per note 4127.8 , then the notifications
are disabled with error within 2 hours.
They are using remote collectors to collate information , then pass the
events to the local collecter using UDP .
They have several domains, each with a collector , each is opened as
the default domain by a different userid. One of the users
receives the popup window indicating that the MCC-E-MMABORT , taregt
manageemnt module thread has aborted , but the notify requests window
shows the notification to remain enabled.
The other user receives the popup window MCC-E-RECEIVEERROR , error
trying to receive packet , and the notify requests window shows the
notification to be disabled with error.
I'm unable to reproduce this at the CSC, as our MCC test system is
already broken with another MCC problem for this customer. No info on
flags for the log file has been forthcoming, so I've IPMT the call to
try to make some headway.
Conrad
|