Conference azur::mcc

I'm getting the customer to set up a trace with the MCC_FCL_PM_LOG.

Still waiting for the results...................

Cheers,

Phil.

	Does the user have SYSPRV turned on in the process running DECmcc? 
	Also, are there any other process running on the system which
	binds to port 162 ? You can also trying running the sink by hand
	and see if it stays up. ($ RUN SYS$SYSTEM:MCC_TCPIP_SINK.EXE).
	If it stays up, issue the following DECmcc command to see if the
	SNMP AM can communicate with the sink :

	MCC> SHOW MCC 0 TCPIP_AM SINK ALL COUNTERS

	Rahul.

	Hi,

	Sorry about the delay in responding.

	The customer is logged in as system and has all privs.  If we manually
	run MCC_TCPIP_SINK.EXE it stays up ok and the traps are processed.
	
	I am shipping the MCC 1.2.3 Mup to the customer and he's also going to 
	install UCX V2.0.

	I'll keep you posted as to the outcome.

	Thanks for your help.

	Phil.

	Hi all,

	My customer has upgraded his system to MCC BMS V1.2.3 and UCX V2.0
	and he still has the same problem where TRAPS are not being processed.

	Again, if he hand cranks the tcpip sink process all is ok.

	Any help greatly appreciated..........

	Regards,

	Phil.

	What is the duration he is specifying in his getevent directive?
	If he is still specifying 10 seconds (00:10) he cannot expect
	the sink to stay up for too long (or get any traps out of DECmcc).

	Ask him to try the command without the duration qualifier.

	rb.

	Hi,

	The syntax used in the getevent command is posted in the base note
	(4271).  The duration is 10 minutes.

	Any other ideas anyone?

	Phil.

	Ooops! The duration is indeed 10 minutes and not 10 seconds.
	The only explanation I can think of is that the event pool
	may be corrupt. But rebooting the system should have got rid
	of the problem.

	Rahul.

    what happened with the fcl log?
    

Hi,

        I opened a new topic because this has become an emergency
	a customer of ours has the same problem of note 4271
	MCC_TCPIP_SINK dies after receiving the first trap.
	Also in my case the only infos I get from accounting
	is a "Final status code: 03268009", the mcc_tcpip_sink.err
    	file is always empty.
	
	I defined the MCC_FCL_PM_LOG to 8 and these're  the results.

        Trying to reproduce the problem in our mcc system here ,we now
        have the the same behaviour !!!
    
    	for anyone who can help i can give complete access to my
    	system.
    
	Are there any news about this problem, is there an open QAR ???
    
        

				Thanks in advance for any help,

				Ciao    Andrea Lasagna.		

Gundam > DEFINE MCC_FCL_PM_LOG 8
Gundam > MANA/ENTER
DECmcc (V1.2.0)

MCC> GETEVENT SNMP * ANY EVENT


*****************************************************
*     FCL PM Arguments before call_function:        *
*****************************************************

VERB code:      65
PARTITION code: 15
AES dump of ENTITY IN:

Depth=0  Class = 18 Instance =  No curlen  Id = 0 Dt = 0


ILV dump of IN_P: in_p is NULL
ILV dump of IN_Q: in_q is NULL
TIME SPEC is: 0, NOW

**********************************************
FCL PM Arguments on return from call_function:

CVR returned:
%MCC-S-RESPONSE, success with response reply

ILV dump of OUT_P:

[  1 ] (
    [  1 ] (
        [  0 ] (
            [  1 ]             31 2e 33 2e 36 2e 31 2e 34 2e 31 2e 33 36 2e 31  -- 1.3.6.1.4.1.36.1
            [  2 ]             10 c0 10 0d
            [  3 ]             00
            [  4 ]             00
            [  5 ]             01 99 e8 b8
            )
        )
    )
AES dump of ENTITY OUT:

Depth=0  Class = 18 Instance = GUNDAM_NS:.ip.lasa Id = 97 Dt = 5



SNMP GUNDAM_NS:.ip.lasa
AT 25-FEB-1993 15:34:56 Any Event

Successfully received event(s):
Event: coldStart
A coldStart trap was received:
                             enterprise = "1.3.6.1.4.1.36.1"
                             agent-addr = 16.192.16.13
                           generic-trap = coldStart
                          specific-trap = 0
                             time-stamp = 26863800
MCC> SPAWN
Gundam > SH PROC MCC_TCPIP_SINK  <--- The process is died
%SYSTEM-W-NONEXPR, nonexistent process

    
    

    Andrea,
    
    The MCC_TCPIP_SINK process is only active when there are outstanding
    getevent requests. Once the last getevent request completes, the sink 
    terminates normally.
    
    In your particular example, the getevent was issued without a duration.
    Therefore, the first event you received caused your getevent to complete.
    Since there weren't any other getevents outstanding, the MCC_TCPIP_SINK
    terminated (normally). The next getevent you issue will cause the
    MCC_TCPIP_SINK process to be started again.
    
    If you want you receive multiple events per getevent request, then
    provide a duration.
    
    Hope this helps.
    
    Jim
    
    
    

    Greetings, all,
    
    Before I QAR this, I just want to be sure I haven't done anything
    wrong.
    
    MCC> GETEVENT SNMP * hp any configuration event, for duration 00:01:00
    or
    MCC> GETEVENT SNMP * ANY CONFIGURATION EVENT, for duration 00:01:00
    
    Both yeild the following error:
    
    "The Event Sink was started successfully, but is not currently
    communicating."
    MCC>
    
    Any traps I generate are not received.  Every once in a while, through
    persistence, I can get it to work.  If I do have a corrupted event
    pool, what has caused this, and what are the best ways to prevent such
    and occurrence in the future?
    
    -Dan

    Is anyone aware of a problem with the MCC_TCPIP_SINK process and
    the MCC_EVC_SINK process running at the same time?  I ran into a
    problem where the TCPIP traps would not be received (intermittently) if
    the MCC_EVC_SINK process was running at the same time.  If we did not
    start the MCC_EVC_SINK, then the TCPIP traps were always received
    correctly.
    
    Thanks,
    Walt

    BTW, the previous note is pertaining to DECmcc-BMS V1.3 on a VMS V5.5-2
    system.
    
    Walt

Its documented in the release notes, I believe.  Change the EVC socket number.
The manual describes exactly how.

re: .14

>Its documented in the release notes, I believe.  Change the EVC socket number.
>The manual describes exactly how.

Hi Dave,

I looked in the release notes for Polycenter Network Manager 200 and 
couldn't find anything about the EVC sink and the TCPIP sink working 
together.  I also looked in the Alarms manual under the collector_am
section but there isn't any detail about changing or selecting the 
port number for UDPIP for a VMS operating system.  It refers you to
the TCP/IP Services for VMS software but that isn't very straight
forward either.

I went ahead and setup my node to get TCPIP traps and also started up
the collection_am udpip sink.  When I went into UCX and showed the 
device sockets, I found that the EVC sink process for UDPIP did use
port 1630 as the manual states.  The TCPIP sink process was using port
162.  I don't understand the conflict here.  Could you please provide
some more detail as to why I need to change the port for the collector
UDPIP sink and also how to do this under VMS?

Thanks,
Walt

    I've got another dying sink problem.  If I do a getevent directive
    out of the FCL, the sink process gets created, then dies with a
    final status code of 03268009.  You don't get the MCC prompt back
    after the process dies.  When you run this through the
    f$message lexical, you get an ADA-S-NOMSG, Message Number 0031dda9. 
    Anyways, I'm looking at this from a "UCX must be mis-configured"
    point of view, but I can't see where.  I've increased my device
    sockets to 80, but still no go.
    
    I'm running VMS6.1, MCC T1.4, UCX 3.2, Hubwatch 3.1, all on a 32
    Mbyte VAXstation 3100/76.
    
    Any Ideas?
    -Craig