| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 4796.1 | anybody? | CTHQ::WOODCOCK | | Wed Apr 07 1993 18:12 | 7 |
| Hi again,
If I wildcard (NODE * x25 prot....) then the NOTIFY takes and I receive the
event from FCL. But the iconic map and targets still aren't lighting up my
life. A brain teaser for Notification Experts. Any takers?
brad...
|
| 4796.2 | | TOOK::R_SPENCE | Nets don't fail me now... | Fri Apr 09 1993 12:44 | 8 |
| Just for curiosity, what process did you use to move from DEC: to
LOCAL_NS:?
If you used the MCC_DUMP_NS procedure and eddited the Register commands
to change the node names did you also edit the Create Domain Member
commands as well?
s/rob
|
| 4796.3 | didn't move from DEC: | CTHQ::WOODCOCK | | Fri Apr 09 1993 14:02 | 13 |
|
> Just for curiosity, what process did you use to move from DEC: to
> LOCAL_NS:?
Rob,
I didn't move from DEC:. The NODE in question is in DEC: and advertises
(from RENANE) as such. I was originally on a private NS (LUVBOT_NS) then
moved to LOCAL_NS using the dump_ns procedure (good stuff to have around).
Is this clearer?
brad...
|
| 4796.4 | please do a diretory target | TOOK::CALLANDER | MCC = My Constant Companion | Tue Apr 27 1993 15:22 | 7 |
| could you please print the output from the DIRECTORY TARGET command.
I have a feeling that the way the fullnames were stored, that
the target entity is stored incorrectly named for your current needs.
You will most likely have to delete and recreate the assignments.
jill
|
| 4796.5 | target info | CTHQ::WOODCOCK | | Tue Apr 27 1993 17:57 | 41 |
| Jill, thanks for the reply. This I believe will become a critical issue
internally for event mngmt if not resolved. Here is the info you requested. At
this point I cannot remember whether these targets were already in the MIR or
if I had reassigned them. How do they look?
kind regards,
brad...
---------------------------------------------------------------------------
MCC> dir target domain .watn.watn
Domain LOCAL_NS:.watn.watn
AT 27-APR-1993 16:49:53
Target Assignment:
Event Source = Node * X25 Protocol DTE dte-0 ,
Managed Object = "node DEC:.lkg.everdy x25 prot dte
dte-0",
Event Name = "dte up",
Target Entity = "node .everdy x25 prot dte dte-0",
Target Severity = clear
Domain LOCAL_NS:.watn.watn
AT 27-APR-1993 16:49:53
Target Assignment:
Event Source = Node * X25 Protocol DTE dte-0 ,
Managed Object = "node DEC:.lkg.everdy x25 prot dte
dte-0",
Event Name = "dte down",
Target Entity = "node .everdy x25 prot dte dte-0",
Target Severity = critical
MCC> show node .everdy name
Node LOCAL_NS:.everdy
AT 27-APR-1993 16:54:40 Identifiers
Name = DEC:.lkg.everdy
|
| 4796.6 | .everdy implies DNS location | TOOK::CALLANDER | MCC = My Constant Companion | Wed Apr 28 1993 10:33 | 24 |
|
Brad,
Your target entities seem to be of the format:
Target Entity = "node .everdy x25 prot dte dte-0",
The . before everdy makes .everdy a fullname. When you moved to
the DEC: namespace everdy is probably not defined in the root directory
of the namespace (DEC:.everdy), but in a subdirectory. Because of this
the target entity DEC:.everdy will never be found in the domain and the
retargetting will not occur. If the target entity had been entered
without the . you wouldn't have to change anything.
The target entity is actually stored in the database as a string.
Because it is stored as a string and not evaluated until it is needed
"node everdy" would have been read as a simplename and not as a
fullname (implying location in the namespace).
Does this help?
Simply convert the directory target output into assign target commands
and you should be all set to create the new ones.
|
| 4796.7 | clarification for more help | CTHQ::WOODCOCK | | Wed Apr 28 1993 15:52 | 50 |
| Hi Jill,
> Your target entities seem to be of the format:
>
> Target Entity = "node .everdy x25 prot dte dte-0",
>
> The . before everdy makes .everdy a fullname. When you moved to
> the DEC: namespace everdy is probably not defined in the root directory
> of the namespace (DEC:.everdy), but in a subdirectory. Because of this
> the target entity DEC:.everdy will never be found in the domain and the
> retargetting will not occur. If the target entity had been entered
> without the . you wouldn't have to change anything.
>
> The target entity is actually stored in the database as a string.
> Because it is stored as a string and not evaluated until it is needed
> "node everdy" would have been read as a simplename and not as a
> fullname (implying location in the namespace).
> Does this help?
> Simply convert the directory target output into assign target commands
> and you should be all set to create the new ones.
The environment is a bit more complex. Let me re-explain. The node everdy is
a member of the DEC: NS. Its name is DEC:.lkg.everdy and the node has been
'renamed' as such. When events are sent from this node, mcc sees them coming
from "DEC:.lkg.everdy".
MCC however is using LOCAL_NS!! The node is registered as LOCAL_NS:.everdy.
With LOCAL_NS used I cannot specify a NOTIFY command for "NODE DEC:.lkg.everdy"
because it complains it doesn't know the entity and it is not in the domain.
If I issue a NOTIFY against LOCAL_NS:.everdy the event will never be seen
because it comes in as "DEC:.lkg.everdy". If I issue a wildcarded notify
the request works but I get no color changes with the TARGETs specified in
the previous note, but I am receiving them as witnessed by an fcl notify
request.
In V1.2 I had this same setup with a PRIVATE NS (LUVBOT_NS). The notify request
did not complain about not having the DEC: node in the domain and the TARGETs
were successful in hitting the map. This is what led to .0. Could this be a
problem with case sensitivity (haven't looked into that yet)? Multi-NS's as
described here will definitely come back to bite mcc sooner or later if it
can't be worked.
any ideas??
cheers,
brad...
|