Conference azur::mcc

In your first problem, the FCL parser correctly told you that your input
was wrong. It's not CSMA-CD, it's CSMACD (like you did in the second example.)


1.)  What type of node is sending the events?  [VMS, Ultrix, WANrouter]
     (If VMS, is it WaveI or WaveII?)


2.)  If ( VMS .or. Ultrix )
	both the Sink Node .and. Sink End User Name must be specified.

     If Wanrouter, the Sink Address must be specified.


If you think you've set everything up correctly, do a Show of all Status and
all Characteristics for the outbound stream and post the output.

The problem I described has to do with mismatch between events and the getevent
directive.

As I described in .0, when I'm executing the command

GETEVENT NODE .NWO.NWOMCC CSMA-CD STATION CSMACD-0 any events

I receive an error message about syntax error. The syntax in NCL and in the event
is CSMA-CD, not CSMACD, as DECmcc seems to believe.

I mean, if an event is logged on my node, as for example

NODE NORWAY_MCC:.NWO.NWOMCC CSMA-CD STATION CSMACD-0, 
Unrecognized Multicast Destination PDU

I want to do a getevent'on this, but DECmcc won't accept CSMA-CD, but CSMACD.

Re .1

1) The type of node who is sending is a Wave2 node, sending the event to it's
own sink, i.e. DECmcc is running on the same node who is generating the event, 
sending it to MCC_EVL_SINK on the same node.

2) The sink node was not specified. But when I specify it, I now receive an
event telling me Access Control Violation

Here's the output from the SHOW E D O S MCC_STREAM ALL


Node 0 Event Dispatcher Outbound Stream mcc_stream
at 1992-09-01-09:38:39.897+02:00Iinf

Identifiers

    Name                              = mcc_stream

Status

    UID                               = 8B9091F0-7D8F-11CB-8009-AA00040095CA
    State                             = On Connected
    Buffer Size                       = 16384

Characteristics

    Template                          = <Default value>
    Connect Retry Timer               = 120
    Disconnect Timer                  = 0
    Specific Filter                   = 
       {
          [
          EventCode = (Node NORWAY_MCC:.NWO.NWOMCC , All) ,
          Filter Action = Pass
          ] ,
          [
          EventCode = (Node NORWAY_MCC:.NWO.NWOMCC Event Dispatcher, All) ,
          Filter Action = Pass
          ] ,
          [
          EventCode = (Node NORWAY_MCC:.NWO.NWOMCC CSMA-CD, All) ,
          Filter Action = Pass
          ] ,
          [
          EventCode = (Node NORWAY_MCC:.NWO.NWOMCC Event Dispatcher Outbound 
Stream mcc_stream, All) ,
          Filter Action = Pass
          ] ,
          [
          EventCode = (Node NORWAY_MCC:.NWO.NWOMCC CSMA-CD Station CSMACD-0, 
Unrecognized Multicast Destination PDU) ,
          Filter Action = Pass
          ] ,
          [
          EventCode = (Node NORWAY_MCC:.NWO.NWOMCC CSMA-CD Station CSMACD-0, 
Unrecognized Individual Destination PDU) ,
          Filter Action = Block
          ] ,
          [
          EventCode = (Node NORWAY_MCC:.NWO.NWOMCC CSMA-CD Station CSMACD-0, All) ,
          Filter Action = Pass
          ]
       }
    Global Filter                     = 
       {
          [
          EventCode = ((Node), All) ,
          Filter Action = Pass
          ] ,
          [
          EventCode = ((Node, Event Dispatcher), All) ,
          Filter Action = Pass
          ] ,
          [
          EventCode = ((Node, Routing), All) ,
          Filter Action = Pass
          ] ,
          [
          EventCode = ((Node, DTSS), Synchronization Completed) ,
          Filter Action = Pass
          ] ,
          [
          EventCode = ((Node, DTSS), All) ,
          Filter Action = Pass
          ] ,
          [
          EventCode = ((Node, Event Dispatcher, SINK), All) ,
          Filter Action = Pass
          ] ,
          [
          EventCode = ((Node, Event Dispatcher, Outbound Stream), All) ,
          Filter Action = Pass
          ] ,
          [
          EventCode = ((Node, Event Dispatcher, SINK, Inbound Stream), All) ,
          Filter Action = Pass
          ]
       }
    Catch All Filter                  = Pass
    Connect Timer Enabled             = True
    Sink Object                       = <Default value>
    Sink Node                         = NORWAY_MCC:.nwo.nwomcc
    Sink End User                     = name = mcc_evl_sink
    Sink Address                      = 
       {
       }

Counters

    Creation Time                     = 1992-08-19-08:49:38.549+02:00Iinf
    Events Lost                       = 98006
    Enabled                           = 1
    Disabled                          = 0
    Connect Requests                  = 9378
    Connections Accepted              = 2
    Shutdowns                         = 0
    Confidence Changes                = 3
    Filter Changes                    = 23

re: command syntax

CSMACD is the MCC name for this child entity.  I can try and
find out why it's different from what OPCOM is using, but it should
not prevent you from doing what you are trying to do.

Looking at the characteristic information you provided I noticed that
the sink end user name was specified in lowercase.  It appears to work
fine on VMS, but be aware that the registered name is in upper case
and on Ultrix at least, it's necessary to adhear to the case sensitivity.

I did some testing on my WaveII machine and reproduced the privilege
violation.  I'm at loss why and will have to contact the VMS group to
get more info.  My process was fully privileged when I made the request
so I see no reason why the request is being kicked back.  I suspect a
VMS bug here.  What you can try in the meantime is to set up a session
control proxy for yourself (if that feature is supported yet in VMS).
I do that on my Ultrix PhaseV systems.

I also got *lots* of messages like this from OPCOM when testing:

%%%%%%%%%%%  OPCOM  20-JUL-1992 14:23:49.58  %%%%%%%%%%%
Message from user PURRETTA on LAKE
%EVD-I-EVENTLOST, event lost, first longword of UID %X427E58B3

%%%%%%%%%%%  OPCOM  20-JUL-1992 14:23:49.59  %%%%%%%%%%%
Message from user PURRETTA on LAKE
-EVD-E-CMLBUILDFAIL, Event discarded due to CML build failure, status returned w
as %X04628158

and the sink didn't receive many events at all.  This is certainly a problem
on the VMS side (we can't report what we don't get).


Now, if your OPCOM is successfully reporting events and you can't get MCC
to display them, there's one more thing for you to check.  Either wildcard
the nodename, or make absolutely sure that the nodename you used in the
getevent command matches what the node is reporting itself as.  I'd either
do a MCC> show node .NWO.NWOMCC name, or compare the name in the opcom
message with what you specified.

It's unclear from your last note if now that you've specified the sink node
if you are seeing events now (is the Access control problem the only problem
now?)

Ok, this is what's happening.

On each implementation of DECnetV there is a CML listener to accept requests
which has it's own internal format.  In VMS it's called itemlist.  Ultrix
has something else.  When NCL detects you are making a request for the node
you are on (either by specifying NODE 0, or leaving off the nodename
altogether) it *does not* send the request over DECnet.  It formats the
request into a form which can be used by CML directly (Itemlist)and hands it
off to it.  In this case, it can do the privilege checking.  Once you give it
a node name, that forces it to send the request out over DECnet (even if
the request is to the same node.)  In this case, the priv checks are for
the Task you are trying to modify, and it doesn't make a difference what
privs you have turned on from the process that made the request.

A good way to way to see this difference in behavior is to issue the requests:

NCL> enable event dispatcher outbound stream xxx
	This will succeed if your privs are on.


NCL> enable NODE <local nodename> event dispatcher outbound stream xxx
	This would fail.


In MCC, *all* management requests are delivered via the network.  We can't
expect the DNA5 access module to understand all the different internal
formats of the listener we could be talking to.  So, when you issued the
request to enable the outbound stream, you got the same behavior as NCL
gave in example 2 above.

The good news.  DECnet PhaseV allows proxy to be set up which would allow
specific users on specific nodes to act as if they made the request as
someone on the local node (presumably from a prived account).  However
I don't think WaveII has implemented that yet (least that's what it says
when I try to set it).  Ultrix does, and as I mentioned in my previous message
that's how I set up my Ultrix PhaseV node.  I created a cml_proxy and allowed
specific users full access to prived management requests.  I would read
the PhaseV documentation on Session Control Proxy for more information on this.

The other option MCC gives you is to make the request with the
by user=xxx, by password=yyy  qualifiers.

> CSMACD is the MCC name for this child entity.  I can try and
> find out why it's different from what OPCOM is using, but it should
> not prevent you from doing what you are trying to do.

The MCC  MSL's  are wrong.  This name changed quite a while ago.  Why aren't
MCC MSLs keeping up with the changes being registered by DSSR?

Graham

RE.4:  I really don't understand the answers I've got. What is meant by privilege 
checking?

Could anyone comment on my guess about how the events are reported?

On PhaseV node NWOMCC I'm running MCC and have enabled the DNA5_AM SINK, which
as a result starts a VMS process called MCC_DNA5_EVL, and creates a PhaseV 
SESSION CONTROL APPLICATION called MCC_EVL_SINK.

On the same node I created an Event Dispatcher Outbound Stream named MCC_STREAM,
which specifies SINK NODE as the local node NWOMCC and SINK END USER as 
NAME=MCC_EVL_SINK. 

When an event is detected by teh NET$ACP process, my outbound stream MCC_STREAM
reports this event to SINK NODE NWOMCC and specifies that the SESSION CONTROL
APPLICATION MCC_EVL_SINK should receive the event report. The MCC_EVL_SINK is in
this case a process declared as a network process, which acts as an EVD/EVL.
Is this correct?

And now comes the big question about access control. Who is receiving the request
for End User = NAME = MCC_EVL_SINK? Is it CML? Or is it NET$ACP who is responding
and pass over the control to MCC_DNA5_EVL? Which process doesn't have access to
WHAT?

Bj�rn Olav

In .2 you made the comment:

> 2) The sink node was not specified. But when I specify it, I now receive an
> event telling me Access Control Violation

I assumed from this statement that you got the priv violation trying to SET
the outbound stream characteristics.  That's what I reproduced.
Note 274.2 in the DECNET-OSI_FOR_VMS notes file explains how to set up proxy
on a VMS system using Authorize.  They have no plans to support Session Control
Proxy by the way.

To address your last question, Access control shouldn't be an issue for EVD to
post events to an outbound stream once it's been.  Your description of how the
system should work is essentially correct.

I've been experimenting some more and have found that as soon as the outbound
stream is Enabled on a WaveII system, the *only* events which are actually
delivered to the sink are under the EVent dispatcher outbound stream child
entity.  I can see the CSMACD events you speak of in my OPCOM window,
but they are being dropped.  OPCOM is reporting this as an event discarded
due to CML build failure.  I'm running the EVL in debug mode and indeed I
don't receive the event.

I'll post a note in the DECNET-OSI_FOR_VMS conference to see if this is a
known problem.

John

John, as you've seen in the DECnet-OSI conference, I now receives events
on my PhaseV node fraom my PhaseV node in MCC_EVL_SINK. I'm understanding a
lot more now of how this works.

There's still one or two more problems with this. 

The first one has to do with PhaseIV RELAYed events. How do I pick these up
in MCC_EVL_SINK? 

The event is formatted this way

Event: Event Relayed from: Node NORWAY_MCC:.NWO.NWOMCC Event Dispatcher RELAY
LOGGING Monitor,
	at 1992-09-11-09:59...........
	Formatted NICE Data=
DECnet event 4.14, node reachability change
From node 50.152 (OSL10), 11-sep-1992................
Node 50.736 (STKFSO), Unreachable

The event is not BLOCKED in the E D O S MCC_STREAM, so it should be reported in 
Notification services. 

The other problem is that a lot of events are generated reporting REJECT
and REJECT with Reason=No Resources, or Reason=21.

These events show up in Notification with no details.

Bj�rn Olav

>The first one has to do with PhaseIV RELAYed events. How do I pick these up
>in MCC_EVL_SINK? 

Unfortunately, PhaseIV Relay is not yet supported in the MCC PhaseV Sink.
We are aware of this need but have other higher priority tasks which
neeed to be addressed.  If you feel that the priority of this task should
be raised I would send mail to Gail (DELNI::) Ferreira and
Wally (TOOK::) Matthews.


>The other problem is that a lot of events are generated reporting REJECT
>and REJECT with Reason=No Resources, or Reason=21.
>These events show up in Notification with no details.

Please post an example of such an event, and I'll do some checking.


John

> Unfortunately, PhaseIV Relay is not yet supported in the MCC PhaseV Sink.
> We are aware of this need but have other higher priority tasks which
> neeed to be addressed.  If you feel that the priority of this task should
> be raised I would send mail to Gail (DELNI::) Ferreira and
> Wally (TOOK::) Matthews.

Well, none of our customers has migrated to PhaseV for their whole network.
The one who will start this FY, is the biggest customer of ours, and they
are the only ones who has DECmcc. The transition will take time, perhaps more
than a year after they start. This means they will have PhaseV nodes and
PhaseIV nodes in the network for a long period of time. It's also natural that
they upgrade the DECmcc station to PhaseV, so that the network manager can get
familiar with management of PhaseV. If they won't be able to receive PhaseIV
Relayed Logging events in DECmcc, this means they won't have the ability
to manage their network! How can this be a non-priority area? 


Now to the other problem, REJECTS.

I've included the events that occurs in the same stream, and I've found that
the process that is failing is TASK, see output from NCL at the bottom.

I receive a breakin detection for Username ILLEGAL, which is the Session
Control Application TASK, which is created with an illegal username of ILLEGAL.
This results in two security alarms, because the account does not exist.

MCC_EVL_SINK generates an event, Access Control Violation, to report this
problem. After that I receive one Reject Sent and one Reject Received.

So the question is, why is MCC_EVL_SINK accessing TASK (nullobject in PhaseIV)?

Bj�rn Olav


Here's the output.

$
%%%%%%%%%%%  OPCOM  14-SEP-1992 08:44:34.10  %%%%%%%%%%%
Message from user AUDIT$SERVER on NWOMCC
Security alarm (SECURITY) and security audit (SECURITY) on NWOMCC, system id: 51
861
Auditable event:        Network breakin detection
Event time:             14-SEP-1992 08:44:34.08
PID:                    0000004F
Username:               ILLEGAL
Remote nodename:        NWOMCC          Remote node id:         51861
Remote username:        SYSTEM

$
%%%%%%%%%%%  OPCOM  14-SEP-1992 08:44:34.23  %%%%%%%%%%%
Message from user AUDIT$SERVER on NWOMCC
Security alarm (SECURITY) and security audit (SECURITY) on NWOMCC, system id: 51
861
Auditable event:        Network login failure
Event time:             14-SEP-1992 08:44:34.21
PID:                    0000004F
Username:               ILLEGAL
Remote nodename:        NWOMCC          Remote node id:         51861
Remote username:        SYSTEM
Status:                 %LOGIN-F-NOSUCHUSER, no such user

$
%%%%%%%%%%%  OPCOM  14-SEP-1992 08:44:34.48  %%%%%%%%%%%
Message from user SYSTEM on NWOMCC
Event: Access Control Violation from: Node NORWAY_MCC:.NWO.NWOMCC Session Contro
l,
        at: 1992-09-14-08:44:34.470+02:00I0.760
        NSAP Address=49::00-32:AA-00-04-00-95-CA:20,
        Source=name = MCC_EVL_SINK,
        Destination=UIC = [0,0]SYSTEM,
        Destination User="",
        Destination Account="",
        Node Name=NORWAY_MCC:.NWO.NWOMCC
        eventUid   250F3490-91FD-11CB-8022-AA00040095CA
        entityUid  DF9AC2A0-8E3A-11CB-8001-AA00040095CA
        streamUid  56A18900-8E3C-11CB-8007-AA00040095CA


$
%%%%%%%%%%%  OPCOM  14-SEP-1992 08:44:34.61  %%%%%%%%%%%
Message from user SYSTEM on NWOMCC
Event: Reject Sent from: Node NORWAY_MCC:.NWO.NWOMCC NSP Local NSAP 490032AA0004
0095CA20 Remote NSAP 490032AA00040095CA20,
        at: 1992-09-14-08:44:34.580+02:00I0.760
        Reason=21,
        Additional Information='38CE00CF00220000'H
        eventUid   251FFD70-91FD-11CB-8022-AA00040095CA
        entityUid  6C17B9E0-8E3B-11CB-8005-AA00040095CA
        streamUid  56A18900-8E3C-11CB-8007-AA00040095CA


$
%%%%%%%%%%%  OPCOM  14-SEP-1992 08:44:34.66  %%%%%%%%%%%
Message from user SYSTEM on NWOMCC
Event: Reject Received from: Node NORWAY_MCC:.NWO.NWOMCC NSP Local NSAP 490032AA
00040095CA20 Remote NSAP 490032AA00040095CA20,
        at: 1992-09-14-08:44:34.580+02:00I0.760
        Reason=34,
        Additional Information='38'H
        eventUid   251FFD71-91FD-11CB-8022-AA00040095CA
        entityUid  6C17B9E0-8E3B-11CB-8005-AA00040095CA
        streamUid  56A18900-8E3C-11CB-8007-AA00040095CA




Node 0 Session Control Application TASK
at 1992-09-14-08:53:00.430+02:00I0.815
 with User Name = "ILLEGAL"

Identifiers

    Name                              = TASK

> Well, none of our customers has migrated to PhaseV for their whole network.
> The one who will start this FY, is the biggest customer of ours, and they
> are the only ones who has DECmcc. The transition will take time, perhaps more
> than a year after they start. This means they will have PhaseV nodes and
> PhaseIV nodes in the network for a long period of time. It's also natural that
> they upgrade the DECmcc station to PhaseV, so that the network manager can get
> familiar with management of PhaseV. If they won't be able to receive PhaseIV
> Relayed Logging events in DECmcc, this means they won't have the ability
> to manage their network! How can this be a non-priority area? 

Why can't  they receive the Phase IV events directly at MCC, using the Phase
IV AM?

The Relay  stuff  is  there  for  one  reason only: to allow a Phase V Event
Dispatcher  to  display  events  received from a Phase IV node.  MCC doesn't
need  that  because  both  the  Phase IV and Phase V AMs can run on either a
Phase IV or Phase V node (isn't that right, John?).

Graham

>> Why can't  they receive the Phase IV events directly at MCC, using the Phase
>> IV AM?
>>
>> The Relay  stuff  is  there  for  one  reason only: to allow a Phase V Event
>> Dispatcher  to  display  events  received from a Phase IV node.  MCC doesn't
>> need  that  because  both  the  Phase IV and Phase V AMs can run on either a
>> Phase IV or Phase V node (isn't that right, John?).
>>

Is this possible? I've used the DNA4_AM to correctly set up remote logging of 
events on two of my PhaseIV system to my PhaseV system. But how do I set up my
PhaseIV system to receive the PhaseIV events in DECmcc? I can't use the startup
file provided for setting up a PhaseIV MCC EVL, MCC_STARTUP_DNA4_EVL.COM, 
because it refers to my local node as NODE4, not NODE.

Anyone like to give this a chance?

Bj�rn Olav

Is it good enough to replace the MCC commands with NCP commands?

I haven't tried it but something like the following might work:

$PURGE MCC_DNA4_EVL.LOG/keep=10
$ run sys$system:ncp
!
!	Get rid of TASK object and recreate it.
!	Not required for VMS V5.4 or later systems.
!
clear object task all
!
set object task number 0
!
!	the state of local sink must be off before clearing up the sink 
!
set logging MONITOR state off
! 
!	before create the local sink, clear it first
!
clear logging MONITOR all
!
!
!	the name of the sink monitor must be MCC_DNA4_EVL for DECmcc.
!
SET logging MONITOR name MCC_DNA4_EVL
!
!  Make sure no old Remote Sinks are lying around.
!
!DELETE node4 <os_node> outbound stream <OS_NODE> remote sink MONITOR 
!	set up the event filter:  os_node => should be the local node.
!				  os_node => is where events will be received.
!
!  Set up to sink local events of class 0 to the Local Sink Monitor.
!
set logging monitor known events
!CREATE node4 <OS_NODE> outbound stream <OS_NODE> remote sink MONITOR class = 0,-
!	event type = {0,1,2,3,4,5,6,7,8,9}
!
!  Set up to sink local events of class 2 to the Local Sink Monitor.
!
!PASS node4 <OS_NODE> outbound stream <OS_NODE> remote sink MONITOR class = 2, -
!	event type = {0,1}
!
!  Set up to sink local events of class 3 to the Local Sink Monitor.
!
!PASS node4 <OS_NODE> outbound stream <OS_NODE> remote sink MONITOR class = 3, -
!	event type = {0,1,2}
!
!  Set up to sink local events of class 4 to the Local Sink Monitor.
!
!PASS node4 <OS_NODE> outbound stream <OS_NODE> remote sink MONITOR class = 4, -
!	event type = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19}
!
!  Set up to sink local events from class 5 to the Local Sink Monitor.
!
!PASS node4 <OS_NODE> outbound stream <OS_NODE> remote sink MONITOR class = 5, -
!	event type = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21}
!
!  Set up to sink local events of from class 6 to the Local Sink Monitor.
!
!PASS node4 <OS_NODE> outbound stream <OS_NODE> remote sink MONITOR class = 6, -
!	event type = {0,1,2,3,4,5}
!
!  Set up to sink local events of from class 7 to the Local Sink Monitor.
!
!PASS node4 <OS_NODE> outbound stream <OS_NODE> remote sink MONITOR class = 7, -
!	event type = {0,1,2,3,4,5,6,7,8,9,10,11}
!
!	start the sink -- set it to state on and create the MCC_DNA4_EVL
!	process to receive the events and make them available to DECmcc.
!
set logging monitor state on
$!
$EXIT

    re:.11, .12
    
    Yes, both the phaseIV and PhaseV access modules can run on either
    platform.  I'm not familiar enough with the PhaseIV event logging
    sink to say if it will also run on a PhaseV system.  I know the
    way it receives events is very different from the PhaseV sink.
    I'll try to find someone who knows more about it.
    
    re.10
    I don't understand why you're getting these security alarms; I can't
    reproduce it here.  I've placed a note in the decnet notes file to
    see if someone over there has a clue.
    
    I'm also working with VMS DECnet engineering about some of the problems
    I mentioned earlier (the CML build failure for CSMACD events).
    
    John
    

The way I understand it the phaseIV event sink is very tied to the
workings of DECnet phaseIV and will not function properly on a phaseV
node.

An option for you if you need to manage a mixed phaseIV/phaseV environment
is to run DECmcc on one of the phaseIV nodes.  The phaseV sink will work
on either platform.  This should solve your problem as both sinks will be
able to field, translate and post the events.



The phaseV sink will report phaseIV relayed events by the way, but the
data is not formatted so it's only useful to detect that a phaseIV node
is sinking events to it (unless you can read NICE events in hex :^)
Here's an example of what you would get today.  This event happens to be
what you would get by zeroing a counter.



MCC> getevent node * event disp rel log * any event

Node DEC:.LKG.LAKE Event Dispatcher Relay Logging Monitor
AT 15-SEP-1992 15:12:20 Any Event

Successfully received events:
Event: Event Relayed

                              NICE Data = %X01040900D12C092C64008212064A41535049
                                          45008130044C414B4500C0410058E204000000
                                          59E24A00000062E20500000063E2060000006C
                                          C200006DC2010076C2000080C20000

John is  quite  right,  of  course, my idea doesn't work on a Phase V system
because it is tied to the Phase IV EVL process.

By the  way,  I  believe  it does work on a Wave 1 system (because Wave 1 is
really  a Phase IV system and, as John pointed out, it all works nicely on a
Phase  IV  system).  That is not a long term solution of course but maybe it
would solve the problem until relayed events can be handled better.

Graham

    Nice try though Graham!  Thanks for taking the time to help out
    with this problem.  I think you're right about waveI.  Seeing how
    it's really a phaseIV node with phaseV extensions, I see no reason
    why both sinks couldn't run together there.
    
    Re: .10
    About the Security Alarms... I have received some indication that
    this is a setup problem.  Please read the DECNET-OSI_FOR_VMS notes
    file, note 327 for more info.
    
    John

Well, so I'm stuck with my PhaseV system here in Oslo, running DECmcc. I can no
longer demo Alarms or Notification from PhaseIV entity events from my
workstation. 

Do I REALLY have to go back to PhaseIV to get this done? And when can I go to
PhaseV? Never? Because there will be a long time before all the nodes on our
internal network will migrate to PhaseV. 

This situation is hopeless. In some earlier notes, questions have been raised 
if DECmcc would run on PhaseV nodes. Some people in engineering answered
positively to this, but what did they really answer? Yes, it runs, but you'll
not be able to monitor PhaseIV nodes? I didn't see any warnings about this when
I looked through the notes conference.

YES, it is high priority, because I don't want to tell our customers that, YES
we have backwards compatibility between PhaseIV and PhaseV, but NO, DECmcc
doesn't have the ability to catch up events from PhaseIV nodes.

Bj�rn Olav (disappointed)