Conference azur::mcc

    The getevent directive is very specific.  What you asked for wasn't
    x25 events, you asked only for events which fall under NODE (you didn't
    specify the child entity).  Try fully specifying the child entity
    you want to get events from, or read the notification services manual
    which allows receiving any and all events under a particular node.

>    The getevent directive is very specific.  What you asked for wasn't
>    x25 events, you asked only for events which fall under NODE (you didn't
>    specify the child entity).  Try fully specifying the child entity
>    you want to get events from, or read the notification services manual
>    which allows receiving any and all events under a particular node.

Thanks for the reply. Actually at this point I didn't care what kind of event
I got, anything as a test would do. I did try fully specifying the dispatcher
in a getevent afterwards:

mcc>getevent node .lkg.everdy event dispatcher

then issued the test message

mcc>test node .lkg.everdy event dispatcher

and I received nothing. I'm not sure where the problem lies with the test 
message (myself, mcc, or gateway) so I tried a different test. I bounced
the DTE (something I didn't want to do, but gave in) and I did get the events.
Will there be a patch for the DTE DOWN event problem mentioned in 3528??

cheers,
brad...

Brad,
    
Well, you *almost* got it right :^)

Look at the node identifier you specified; you left off the namespace.
What the PM does in this case is prepend the default namespace to the
nodename before sending the request to the AM.  So, if you were using
the local mir, the AM would get the equivalent nodename of

	LOCAL_NS:.lkg.everdy

which will certainly not match what the actual node calls itself in
the event.  I believe what you wanted to do here is either wildcard the
nodename with a *, or use what the node has registered itself as, which
would probably be DEC:.  To find out for sure, make a show request to
the node and see what it returns as the NAME attribute.  That's what it's
identifying itself as.  As for the patch, I'll ask if it's thought
necessary.  Fixing it directly using DAP is pretty easy if you need to.

John

John, I guess *almost* with MCC and OSI isn't equivalent to hand grenades
and H-bombs :-). It wasn't until I wildcarded NODE that I got anything, I
needed the RENAME. Speaking of rename, it didn't seem to work using MCC, only
NCL:

rename node .lkg.everdy new name=DEC:.lkg.everdy

Node DEC:.lkg.everdy
AT 25-SEP-1992 11:07:56

The requested operation cannot be completed
                      MCC Routine Error = %MCC-E-NOATTRIB, no such DNS attribute


>    or read the notification services manual
>    which allows receiving any and all events under a particular node.

I read the manual/release notes and I still have been unable to find this. The
statement above implies a single GETEVENT command will give any and all events
from an entity. Am I misreading or do I still need a command for each entity
LEVEL (module) of that particular global entity to which I wildcard the
instances??? This is what I have always thought and would appreciate knowing
I'm wrong and there is a better way.

Also if the fix for the DTE events isn't too involved (read: risky... which it
doesn't appear to be) I'd very much appreciate the details.

thanks much,
brad...

>    or read the notification services manual
>    which allows receiving any and all events under a particular node.

>>I read the manual/release notes and I still have been unable to find this. The
>>statement above implies a single GETEVENT command will give any and all events
>>from an entity. Am I misreading or do I still need a command for each entity
>>LEVEL (module) of that particular global entity to which I wildcard the
>>instances??? This is what I have always thought and would appreciate knowing
>>I'm wrong and there is a better way.

I did not mean to imply that GETEVENT will do what you want to do.
GETEVENT _is_ restricted to one entity class.

The NOTIFY directive (from FCL) or "DECmcc Notification Services" under the
Applications pulldown in the map is what you want to use.  This is a new
Functional Module introduced in V1.2 and is very powerful in the area of
event reporting.  I'd strongly suggest reading the documentation on it
and trying it out.  I think you'll like it a lot.

>>Also if the fix for the DTE events isn't too involved (read: risky... which it
>>doesn't appear to be) I'd very much appreciate the details.

I'll take this off-line with you via mail.

Also, when I get a chance I'll look into the rename problem you mentioned.


John

On a notify request, if you specify a global entity
(specific or wildcarded) you will receive events for the
global entity and *all* of its children.

You can qualify which events by using the "Events" argument,
the default value for which is "any notification events".

>On a notify request, if you specify a global entity
>(specific or wildcarded) you will receive events for the
>global entity and *all* of its children.

>You can qualify which events by using the "Events" argument,
>the default value for which is "any notification events".

It's the missing link. Sometimes I'm so close I can't see it, being influenced
by past functions sometimes not quite seeing the new. I have been under the
impression that specifying GETEVENT and NOTIFY were essentially the same as
far as how they interpret and display child entity events...WRONG. Thanks for
the info, (RE:-2) and yes I agree that V1.2 Notification Services is a major
win for the customer. The rewards have been worth the efforts.

thanks for the help,
brad...