[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

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

6243.0. "SINKing Phase IV events to MCC" by SALUD::ORTIZ () Tue Feb 28 1995 22:27

    I have a phase v system running MCC. I believe I understand the setups
    for other phase v nodes and devices like a DECnis to outbound stream
    its events to MCC with also doing an "MCC>ENABLE MCC 0 dna5_am sink". 
    However, I am not sure what you need to do for phase iv nodes to sink 
    to the MCC phase v host. I understand EVENT RELAY setup for the OSI
    side, but how does MCC capture the same event? Do you need to run 
    MCC_DNA4_EVL or does MCC_EVL_SINK pick up the event automatically?
    
    Any help would be appreciated..
    
    Richard
T.RTitleUserPersonal
Name
DateLines
6243.1PRSSOS::BONNAFEGuy BONNAFE - CSC FranceWed Mar 15 1995 14:2439

	The main difference between sinking phase4 and phase5 events is that
	with phase5 events you should specify both target node AND target
	object ( formally "session control application" ) but with phase4
	events only target node is specified. So you need additional work
	on the MCC station to indicate what's to be done with phase4 events.

	Assuming your sys$manager:net$event_startup.ncl script is correctly 
	set up, it looks like :
                CREATE NODE 0 EVENT DISPATCHER SINK local_sink
                ENABLE NODE 0 EVENT DISPATCHER SINK local_sink
                CREATE NODE 0 EVENT DISPATCHER OUTBOUND STREAM local_stream
                ENABLE NODE 0 EVENT DISPATCHER OUTBOUND STREAM local_stream
                CREATE NODE 0 EVENT DISPATCHER RELAY
                ENABLE NODE 0 EVENT DISPATCHER RELAY
	and you're ready to receive phase5 and phase4 events in your OPCOM 
	session.
	
	By enabling DNA5_AM SINK, both MCC_DNA5_EVL process and MCC_EVL_SINK
	session control application are created. You're now ready to handle
	phase5 events with DECmcc ( notifications or alarms ).

	Then you only need to tell to your phase4 relay to send	phase4 events 
	to MCC_EVL_SINK session control application :

           CREATE EVENT DISPATCHER OUTBOUND STREAM <whatyouwant>
           SET EVENT DISPATCHER OUTBOUND STREAM <whatyouwant> SINK NODE xxxx
                        ( where xxxx = DECmcc station's fullname )
           SET EVENT DISPATCHER OUTBOUND STREAM <whatyouwant> -
				 SINK END USER=MCC_EVL_SINK
           ENABLE EVENT DISPATCHER OUTBOUND STREAM <whatyouwant>

           SHOW EVENT DISPATCHER OUTBOUND STREAM <whatyouwant> STATE
                --->    State = On Connected

	and you're now ready to handle phase4 events with DECmcc.

	Guy.
6243.2good info-but more problems SALUD::ORTIZThu Mar 16 1995 16:5920
    Guy,
    
    	Thanks for the information. It looks pretty straight forward to do.
    
        Unfortunately, I am experiecing a problem that I have seen before that
    I believe is a bug between MCC and DECnet OSI local namespace setups.
    DECnis can only setup a local namespace to be LOCAL:. while DECmcc
    using the MIR database, uses a LOCAL_NS:. for its local database
    (namespace). When we outbound stream the DECnis events to the MCC host,
    the MCC_EVL_SINK will see LOCAL:. which is not the correct naming for
    the registered DECnis Phase V NODE in MCC. We can use a "NODE *" wildcard 
    and it will pick up the event, but the specific DECnis phase v icon will
    not change color. 
    
    Was this an oversight by both DECnet OSI developers and Polycenter 
    Framework developers? If there is a workaround, I would appreciate
    knowing it..
    
    Thanks again,
    Richard
6243.3PRSSOS::BONNAFEGuy BONNAFE - CSC FranceFri Mar 17 1995 11:4517

	Richard,

	I haven't played with a DECnis for a long time, but as far as 
	I remember I was able to receive notifications from a DECnis by using 
	both LNO and Local MIR options. 

	The only known problem in this area ( not yet solved, even in 1.4 )
	deals with a lowercase/uppercase problem in naming entities into 
	DECmcc. The symptom looks like the one you describe : event is
	received by a GETEVENT directive but doesn't generate a notification
	and doesn't change the icon's color. See note 4673.* in this
	conference for details.

	Guy.

6243.4maybe 2 bugs here??SALUD::ORTIZMon Mar 20 1995 18:3217
    Guy,
    
      Thanks for the pointer and I will look into the lower case issue 
    with my customer's setup. However, I did fail to mention that the top
    domain icon WILL change color when the notification is generated using
    the NODE * wildcard. It is the specific node that will not change color. 
    If we do not use a wildcard and give the specific phase v node name we
    will not see ANY icon change color, nor will the notification occur.
      I could be seeing 2 issues here. The first issue being the 
    lowercase/uppercase bug and the second issue being the fullname 
    difference LOCAL_NS: vs. LOCAL:.
    
    Any feedback would be appreciated...
    
    Thanks,
    Richard
    
6243.5AZUR::DURIFFri Mar 24 1995 09:3828
Richard,

A simple check can be done by issuing a "show node xxx all ident"

If the answer looks like :

MCC> show node .dsvb19 all ident

Node sudest_ns:.dsvb19
AT Fri Mar 24 08:19:25 Identifiers

Examination of attributes shows:
                                   Name = xxxxxx_ns:.DSVB19
                                Address = {([DNA_CMIP-MICE,
                                             <stuff deleted here>
                                             49::00-3F:AA-00-04-00-00-00:20])}


In this case the phase V node identifies itself in uppercase : sudest_ns:.DSVB19

A getevent node * will work ok but notifcations services will not see the event
because of case sensitivity.

Try to reconfigure your phase V node to get xxxxxx_ns:.dsvb19 in lower case.

Hope this helps,

Benoit