| Title: | DECmcc user notes file. Does not replace IPMT. |
| Notice: | Use IPMT for problems. Newsletter location in note 6187 |
| Moderator: | TAEC::BEROUD |
| Created: | Mon Aug 21 1989 |
| Last Modified: | Wed Jun 04 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 6497 |
| Total number of notes: | 27359 |
I am trying the integrate unsolicited events from a user writte access
module. Therefore I did test the events with the GETEVENT directive,
and from an OCCURS rule with the notification services. Everything
seems to work fine in the FCL_PM and I can have notification as many
times as expected. ( I found a strange implementation in the sense
that the PM posts a getevent for notification until the year 9123 or
alike, where as the notification fm only posts a getevent for up to
a duration of 200 days for OCCURS rules).
However, notification on the ICONIC MAP fails with the error
%MCC-E-DNS_INVIDENT - ...
and then disables the notification services.
Both notifications were issued for the same domain, and the rule was
the same. Is there any explanation for this?
e.g.
MCC> NOTIFY DOMAIN DECtown
MCC> ENABLE DOMAIN brsadv RULE GAB_card_kept
works fine for an unlimited number of events, but doing the equivalent
thing from the iconic map fails from the first time a event fires.
Thanks for input.
Dominique.
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 1866.1 | Tracing within the ALARMS FM ? | KETJE::PACCO | To manage you have to be a (manag..) skilled person! | Wed Dec 04 1991 18:20 | 8 |
ref #.0 I would like to put as many tracing as possible for the
behaviour of the ALARMS FM related to an unsolicited event triggering
one of its rules. Can somebody help in specifying which trace bits
should be put in the MCC_ALARMS_FM_LOG mask ? Or whichever other way
shoul be followed to pinpoint the problem ?
Regards,
Dominique.
| |||||
| 1866.2 | Log bits for tracking notif | TOOK::CALLANDER | MCC = My Constant Companion | Tue Jan 14 1992 08:39 | 19 |
the map failing most likely has to do with the targetting that
is done. Targetting is where we take the entity from the occurs
function and use it to figure out what entity on the map to
turn a color. My guess is that your entity is either not registered,
or registered incorrectly, OR the name you are returning is not
your name (ex: Bridge NS:.fullnamefoo and Node4 NS:.fullnamefoo
will cause problems because they can nOT share the same fullname).
As to the log gis there are many to choose from, do NOT ever turn them
all on!!!!! Many modules have log bits for doing things like
distructive testing (an example is the IM log bits that do destructive
dispatch table testing). You may want to define the mcc_im_log to
a value of 60000000, this will dump all calls that go across the
access and functional mcc_call boundaries. It will allow you to
track the calls and responses as they are made. In the FCL the
mcc_fcL_pm_log value of 8000 will allow you to trace the notify
command processing within the FCL as well. I am sorry I don't know
what the alarms FM bits are.
| |||||