Conference azur::mcc

Hello Mathilde,
	In fact, the new version of MCC_EVC_SINK.EXE is expecting connection
	from port 5064 instead of 1630. This modification is due to 
	a correction of a CLD (CFS.6829).

	However, if you want to make MCC_EVC_SINK.EXE listen on port 1630,
	you must define a logical for a VMS system and an environment 
	variable for a ULTRIX system.

	on VMS system, to redefine the mcc_evc_sink.exe udp port number
	you must:
		- stop mcc_evc_sink process
		- define MCC_EVC_UDP_PORT 1630 /system	
		- enable collector sink udpip

	On Ultrix system, to redefine the mcc_evc_sink.exe udp port number
	you must:
		- kill mcc_evc_sink process,
		- setenv mcc_evc_sink 1630 
		- enable collector sink udpip

	Hope that it helps,

	Regards,
	- F. AMRANI -
		
	

    Hello,
    
    I have tried it and it worked.
    
    Many thanks,
    
    Mathilde.

Changing the port that MCC_EVC_SINK uses may not be all that great an 
Idea, unless you also let the folks that are working on POLYCENTER DECnet 
Manager know, because they also use MCC_EVC_SEND and SINK code.

They (PDM developers) have a goal of providing compatibility, 
which the folks in VBE have just
broken because they changed the port number they use by default. (And didnt
bother to let anybody know, in the process.)

This is what we call "working together".

As a sine note, are the folks in VBE going to replace
all the MCC_EVC_SEND stubs that are currently in place
and using TCP/IP,

	I know of people who are using:

	SUNOS
	HP/UX
	AIX
	DOS
	VMS
	ULTRIX
	OSF
	
There might be others.

So the message is  " Go ye forward, and rebuild all your code,
		because we have made a change!"

Dave,

I know that sounds like a killer but... the documentation states that
anyone can change MCC_EVC_SEND.C and MCC_EVC_SINK.C at his own discretion.
The 2 programs are given as WORKING EXAMPLES, not as "a comitted piece of
upwards compatible software". So make sure You are aware of this before
recompiling.

Apart from this, here some background information that induced
the port number change:

On Internet port numbers 1-1023 are reserved, and port number 1024-5000
are automatically assigned bys system. So we choos a number that is
bigger then 5000.

All this is very well explained in "UNIX Network Programming" by
W. Richard Stevens, Prentice Hall Software Series.


As Fay�al Amrani mentioned in a previous reply, there was indeed a port 
number clash as some customer site, with as consequence the port number
change. That is the reason why he clearly explained the issue.


On the other hand, as the source code shipped in the kit reads, 5064 is only
the DEFAULT port number when no logical name on OpenVMS or environment
variable on Ultrix exists to supersede that default.


So my recommendation to the outside world would be "make sure
that the correct portnumber is accessed by using the logical name or 
environment variable technique". DECmcc implemented these techniques to
make sure we can overcome clashes in port numbers at a customer's site.

It only takes a cut-n-paste to reuse the technique in whatsoever stub
is provided on other platforms. And, by-the-way if port 1630 is free on 
Your system, feel free use it to override the default.


Last thing, port numbers that need to be reserved need to be registered.
I am not aware of this one being registered at DSSR. So we might change 
it in the future.

This is the unfortunate result of copying source code to modify it to suit 
one's propoer needs. One has to be prepared to follow up all modifications
to the original source code and include them in the modified version as well.


Dirk

While the programs are provided as EXAMPLES,
they are also defacto documentation of the API, which is what is
being changed.  The fact that you also have to change
the program to reflect the change in default behavior
in MCC_EVC_SINK is not related.  You (we, digital)
has made changes to MCC_EVC_SINK, which we do not ship
sources for.

The real issue is how to have migration from one platform
to another, when PDM (The new platform) is expecting
the events to arrive at 1630, while MCC (now) uses somthing else.
The system being managed needs to be able to send to both,
and with this change its not clear how to do that other
than have two copies of MCC_EVC_SEND each of which
uses a different default.  So when I want to move from one
platform to the other as my managment platform, I will, of course
need to have:

$ MCC_EVC_SEND_1630 FRED .....

shortly followed by

$ MCC_EVC_SEND_5000-something FRED2 ....

BTW:  The part of changing the address has always been documented
in the manuals, and IMHO, the original CLD should have been
answered with a 'RTFM', not a code change.