| 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 |
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.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 2997.1 | some questions | TOOK::PURRETTA | Fri May 15 1992 10:57 | 64 | |
>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.2 | Taken off-line | MARVIN::COBB | Graham R. Cobb (Wide Area Comms.), REO2-G/H9, 830-3917 | Tue May 19 1992 16:43 | 0 |