Thanks Jason, that was a lot of useful info.
-- 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?
Yes. Let me explain the behaviour a little more because there is
something I did not mention before. The submap hierarchy above some of
the nodes combines two nodes to form an element. So the element submap
contains two symbols (node1 and node2) and the node2 submap contains
similar symbols to node1:
element
|
|
---------------+----------------
| |
node1 node2
| |
| |
-----------+-------------------
| | | | |
monitor portA portB printer proc1
Acknowledge on node1 or one of its submap symbols (e.g. printer) causes
all symbols for the object (node1 and below) to go green. Same happens
for node2. Acknowledge on element works as expected, i.e. element goes
dark green and nothing below changes.
The object associated with the element symbol is a "dummy" object just
to create the symbol for the submap containing node1 and node2. The
object for element never gets updated by our code.
The element, node1 and node2 symbols use the default compound status
scheme.
All our objects are independent of netmon created objects.
Other parts of our submap hierarchy do not have an element above two
nodes and a node appears at the top level of our submap.
-- Is it your preference to Ack the lower level (monitor, portA, portB,
-- etc) or node?
One object is associated with the node1, monitor, portA, etc, symbols.
So selecting any selects the same object. Selecting monitor causes all
symbols on the node1 submap to be highlighted as selected because they
all belong to the same object.
My preference would be to Ack node1.
-- Christmas Light
What we tried to do was handle the ack callback. We also noticed the
never ending callback sequence. We would set the ack status and the
callback was called again.
-- Your code extract
Is the ack submap something your code maintains?
-- Our proposed approach
We're trying a different solution by generating our own event on
selecting node1 with a new "own-ack" menu option. We will set the status
source to symbol and set the colour to user1status - if we set it to
acknowledge everything will go green because ipmap jumps in and does
what it has to when acknowledge is used.
On our new "own-unack" menu option we will set the node1 status source
back
to compound.
Hopefully this strategy will work.
The tricky thing looks to be how to find out the symbol id for node1
when netview just tells you the object that has been selected.
--
Robin
email: robin.james@thalesatm.com
tel: +44 (0) 1633-862020
fax: +44 (0) 1633-868313--- Begin Message ---
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
---------------------------------------------------------------------
To unsubscribe, e-mail: nv-l-unsubscribe@lists.tivoli.com
For additional commands, e-mail: nv-l-help@lists.tivoli.com
*NOTE*
This is not an Offical Tivoli Support forum. If you need immediate
assistance from Tivoli please call the IBM Tivoli Software Group
help line at 1-800-TIVOLI8(848-6548)
--- End Message ---
|