[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

2997.0. "Phase 5 Event Logging problem" by MARVIN::COBB (Graham R. Cobb (Wide Area Comms.), REO2-G/H9, 830-3917) Thu May 14 1992 17:21

There is  a  problem  with  the release note that describes how to set up an
Event  Dispatcher  Outbound Stream to connect to MCC.  The release note says
to  just  change  the  Sink End User attribute (to Name=MCC_EVL_SINK).  This
only works if the sink has been specified using the Sink Node, not if either
Sink  Object  or  Sink  Address  has  been  used.   Note that the WANrouter,
X25gateway  and  DECNIS configurators all set up Sink Address so the release
note doesn't work for those systems.

Please see  the  QAR  answer  I  enclose  below  and  fix  the release notes
accordingly.  The information in the answer (regarding the three ways to set
up  an  OBS)  is  from  the  architecture:  it  should  be  correct  for any
implementation.  Please mail me if you need more information.

Graham

Thank you for your QAR.

I believe the DECNIS behaviour is correct in this case because specification
of  a TowerSet (Sink Address) over-rides the Sink End User.  The MCC release
note  is  wrong -- we need to get them to correct it.  We will make sure the
DECNIS  documentation  and release notes are updated as necessary to include
the following information:

There are  three  ways  to  specify  the destination for an Event Dispatcher
Outbound Stream:

o By Object name

o By Node name and end user specification

o By Address

If more  than  one  attribute  is set up the following rule is applied.  The
Sink  Object  attribute  is checked.  If it is non-null then the object name
will  be  looked  up  (in the Session Control Known Towers database) and the
corresponding  towerset  will be used.  If the Sink Object is null, the Sink
Node  attribute  is checked.  If the Sink Node is non-null then it is looked
up   (in   the   Session  Control  Known  Towers  database),  the  end  user
specification  is replaced with the value of the Sink End User attribute and
that  is  used as the towerset.  If neither the Sink Object or Sink Node are
specified then the Sink Address attribute is used to supply the towerset.

This means that the Sink End User attribute is not used unless the Sink Node
attribute  is  also  used.   The configurator sets up event sinks using Sink
Address,  not  Sink  Node.   This  means  that if a different object must be
specified (e.g. DECmcc) the Sink Address must be modified.

In particular,  to  modify the Sink Address to allow use of DECmcc, find the
field  in the address that specifies "Number=82".  Replace that with "Name =
MCC_EVL_SINK".
T.RTitleUserPersonal
Name
DateLines
2997.1some questionsTOOK::PURRETTAFri May 15 1992 13:5764
>There is  a  problem  with  the release note that describes how to set up an
>Event  Dispatcher  Outbound Stream to connect to MCC.  The release note says
>to  just  change  the  Sink End User attribute (to Name=MCC_EVL_SINK).  This
>only works if the sink has been specified using the Sink Node, not if either
>Sink  Object  or  Sink  Address  has  been  used.   Note that the WANrouter,
>X25gateway  and  DECNIS configurators all set up Sink Address so the release
>note doesn't work for those systems.

	My apologies to those who were confused by the release note
	entry.  What I was trying to communicate was that only the
	value for _that field_ had changed between fieldtest releases.

	In the previous fieldtest the sink was binding to 
	"Sink End User Number = 99".  Since then, our registration
	request was approved for the sink, but they did not assign us
	number 99, they assigned us "Sink End User Name = MCC_EVL_SINK".
	I had assumed that since the other fields which need to be set up
	had not changed that I didn't need to elaborate on their setup.
	Our release notes are long enough :^)

Graham,
	Thank you for describing the algorithm used in the routers for
	determining how to connect to an event sink.  However I'm confused.
	After we sent out the last FT, I had heard that the routers
	_could not_ use the Sink Node field to describe where on the
	network a sink resided because they didn't have DNS or something.
	I had heard that you _must_ provide a towerset in the Sink Address
	field.  That surprised me.  But if I read your QAR answer correctly
	it sounds like they do support this type of specification.
	I've looked at the setup of several routers friends over in England
	have setup for testing the MCC sink and they all use towersets.
	Seems to me that if the Sink Name fullname was supported that that
	would be a much easier setup and they would be using it.

	Let me describe how I've been setting up Outbound streams here for
	my own testing (my testing has been on VMS and ULtrix systems).

	> create event dispatcher outbound stream target_stream

	> set event dispatcher outbound stream target_stream -
	_>	sink node DEC:.lkg.target

	> set event dispatcher outbound stream target_stream -
	_>	sink end user name = MCC_EVL_SINK

	> enable event dispatcher outbound stream target_stream


If you would be so kind to answer the following questions with respect to
the setup of outbound streams on routers, I'll make sure the correct text
is supplied in the release notes for MCC V1.2.  I only have next week left
to get my final release notes ready as I'm on vacation following that and
V1.2 will probably be submitted while I'm away.

1.)  Will the above setup example work with routers?

2.)  If not, could you supply an equivalent example of how a user would
     setup a stream on a router and I'll include that in my release notes.


                                                                          
Thanks again for your help Graham,

John
2997.2Taken off-lineMARVIN::COBBGraham R. Cobb (Wide Area Comms.), REO2-G/H9, 830-3917Tue May 19 1992 19:430