Thanks for the info ... I feel I have a better understanding. Some points:
"If we select the
node symbol or one of its child submap symbols and then select
acknowledge all of the symbols go green - it does not go dark green."
-- Are you saying if you 'Ack' node then all of the lower level Symbols
change status to 'ovwNormalStatus', ie green? When we acknowledge (last I
checked) our 'node' the statuses of the symbols below do not change. Am I
making correct statements here?
"We want to provide an acknowledge equivalent so the operator can
acknowledge a problem for the node and the top level symbol for our
submap will go back to green. This would allow the operator to monitor
the top level symbol for problems."
-- Is it your preference to Ack the lower level (monitor, portA, portB, etc)
or node? Last time I checked I say 'wierdness' with Acking IP symbols that
had 'connection symbols' attached to them. I use the term 'wierdness'
because Acking the IP Symbol changes the status of connecting symbols ... I
could not figure out how it worked 'all the time' so I went away from that
route and had our operators ack the 'node' level.
// Now to the good stuff. Through my research I found that what 'did'
remove an upper level 'Ack' is when the lover level is set to
ovwNormalStatus. Here is a code snippet (reformatted a bit, taken some
things out). Code explanation below -- (I actually sent this code out
earlier this week):
------------------------------------------------
symbol_status_cbCB (char *userdata,
OVwEventType type,
OVwMapInfo *map,
OVwSymbolList *symbol_list)
{
OVwStatusType new_object_status;
OVwSubmapId ack_submap_id;
int i;
int ret = 0;
char *cleared_symbol_label;
char *original_symbol_label;
if (symbol_list == NULL) {
printf("symbol_status_cbCB - symbol_list passed is NULL\n");
} else {
if (symbol_list->count > 0) {
for (i = 0; i < symbol_list->count; i++) {
// Is the Status being set Marginal or Critical
if (symbol_list->symbols[i].symbol_status == ovwMarginalStatus ||
symbol_list->symbols[i].symbol_status == ovwCriticalStatus) {
// Is this a symbol on the Ack Submap
ack_submap_id = get_ack_submap_id(map);
if (ack_submap_id != symbol_list->symbols[i].submap_id) {
// Is this symbol attmepting to be cleared
if (strstr(symbol_list->symbols[i].symbol_label,
CLEARED_SYMBOL_STRING)
== NULL) {
// Save off new_symbol_status
new_object_status = symbol_list->symbols[i].symbol_status;
// Change the Symbol Name while the clear Ack is occuring
// so we know not to attempt to change statuses when
// setting the final status
original_symbol_label =
strdup(symbol_list->symbols[i].symbol_label);
cleared_symbol_label =
(char *)
malloc(strlen(symbol_list->symbols[i].symbol_label) +
1 + strlen(CLEARED_SYMBOL_STRING));
strcpy(cleared_symbol_label,
symbol_list->symbols[i].symbol_label);
strcat(cleared_symbol_label, CLEARED_SYMBOL_STRING);
ret = OVwSetSymbolLabel(map,
symbol_list->symbols[i].symbol_id,
cleared_symbol_label);
if (ret != 0) {
printf("symbol_status_cbCB - OVwSetSymbolLabel failed:
%s\n",
OVwErrorMsg(OVwError()));
}
// Set the Status of this Symbols Object to ovwNormalStatus
to clear
// the Acked Status above, if any.
ret = OVwSetStatusOnSymbol(map,
symbol_list->symbols[i].symbol_id,
ovwNormalStatus);
if (ret != 0) {
printf("symbol_status_cbCB - OVwSetStatusOnObject 1
failed: %s\n",
OVwErrorMsg(OVwError()));
}
// Set the status of this Symbols Object to the original
status
ret = OVwSetStatusOnSymbol(map,
symbol_list->symbols[i].symbol_id,
new_object_status);
if (ret != 0) {
printf("symbol_status_cb - OVwSetStatusOnObject 2 failed:
%s\n",
OVwErrorMsg(OVwError()));
}
// Set the Symbol Label back by removing the cleared
// symbol string
ret = OVwSetSymbolLabel(map,
symbol_list->symbols[i].symbol_id,
original_symbol_label);
if (ret != 0) {
printf("symbol_status_cbCB - OVwSetSymbolLabel failed:
%s\n",
OVwErrorMsg(OVwError()));
}
} // End of if Cleared Symbol string
} // End of Ack Supmap if
} // End Symbol Status if
} // End Symbol for loop
} // End Symbol list count if
} // End symbol_list is NULL
}
-- From the main app:
// Init OVw
ret = OVwInit();
// Check OVw status
if (ret != 0) {
printf ("OVwInit failed: %s\n", OVwErrorMsg(OVwError()));
exit(1);
}
ret = OVwAddCallback (ovwConfirmSymbolStatusChange, NULL,
(OVwCallbackProc)symbol_status_cbCB,
NULL);
if (ret != 0) {
printf("main - OVwAddCallback failed: %s\n",
OVwErrorMsg(OVwError()));
}
------------------------------------------------
So whats going on here?
Mostly straight forward until I found the 'Christmas Light' callback fun.
1. Register an app to 'Confirm' a Symbol Status change. I always thought
it was funny they used the word 'confirm' since I do not have a documented
way to 'Just say No' to the Status Change. This means when -any- Symbol
Status changes, this callback will be run.
2. Inside the callback, verify everything you want to make sure of before
taking action. You can add any number of 'checks' to make sure you are
working with a symbol you want to work with.
3. When you have found a symbol you want to 'work with', save off its
current status (which is the new status), set the symbol status to
'ovwNormalStatus' then set its status to what it came in to the callback as.
Thus you have 'inserted' a ovwNormalStatus which will remove the Ack status
from above, then change its status to what it came in as. I have not found
any 'race' conditions with this and the setting to ovwNormal is 99%
transparent, ie operator cant see it. I think if I added a 1 second delay
you can watch it, but I removed it due to not finding any reason to have it.
-- All done right? Wrong ... in comes the Christmas Light (more like strobe
light)
If you implement the sudo code above, insert the ovwNormalStatus, insert its
original, eg ovwCriticalStatus, using the OVwSetStatusOnSymbol. Calling
OVwSetStatusOnSymbol causes you to hit this same callback. If you follow
the logic, you get Normal->Critical->Normal->Critical->etc, etc. Never
ending.
Solution:
Use something to maintain state information. I chose the Symbol Label. You
see where I set OVwSetSymbolLabel. What my code actually does is add a "-C"
to the symbol label for the duration of the SetSymbolStatus. Note this 'if'
in the beginning of the callback:
// Is this symbol attmepting to be cleared
if (strstr(symbol_list->symbols[i].symbol_label,
CLEARED_SYMBOL_STRING)
== NULL) {
I make sure the Symbol label does not contain "-C", if it does I skip it.
At the end of my callback I issue:
// Set the Symbol Label back by removing the cleared
// symbol string
ret = OVwSetSymbolLabel(map,
symbol_list->symbols[i].symbol_id,
original_symbol_label);
This sets the label back to what it was originally.
Please let me know if you have any questions or concerns, I will do my best
to answer,
Jason Allison
Principal Engineer
ARINC Incorporated
Office: (410) 266-2006
FAX: (410) 573-3026
-----Original Message-----
From: Robin James [mailto:robin.james@thalesatm.com]
Sent: Tuesday, November 12, 2002 8:51 AM
To: NetView Discussion
Subject: [Fwd: [nv-l] adding events to Netview]
Jason,
Thanks for the reply. We have a customised submap for our computer
rooms. A low level part of our submap would look something like:
node
|
|
-----------+-------------------
| | | | |
monitor portA portB printer proc1
node is the parent symbol for a submap containing symbols for the status
of the monitor, the FDDI ports, a printer and various processes. Other
equipment types have different submap contents. The object for these
symbols is not created via netmon it is created by our application.
Hence acknowledge/unacknowledge does not work for us. If we select the
node symbol or one of its child submap symbols and then select
acknowledge all of the symbols go green - it does not go dark green.
The status source for node1 is compound and it uses the default compound
propogation scheme.
We want to provide an acknowledge equivalent so the operator can
acknowledge a problem for the node and the top level symbol for our
submap will go back to green. This would allow the operator to monitor
the top level symbol for problems.
Like you we would also want the "acknowledge" to be removed if one of
the child submap symbol status changes.
--
Robin
email: robin.james@thalesatm.com
tel: +44 (0) 1633-862020
fax: +44 (0) 1633-868313
|