Conference azur::mcc

6414.0. "EVL / MCC_DNA4_EVL" by BALZAC::MARKOWSKI () Thu Dec 07 1995 18:16

	Hello,

	We have some trouble with the process MCC_DNA4_EVL.
	Because we have to update every day the DECmcc database
	(local MIR) it is necessary to stop and restart our DECmcc 
	environment. It is donne at 6:00. Very often MCC_DNA4_EVL 
	doesn't connect to EVL (they are both on the same node). We 
	need to stop and restart MCC_DNA4_EVL many times before to get 
	a successful connection.

	Today we have reboot the system around 9:00 but the DECmcc
	environment has been started only around 11:30. MCC_DNA_EVL 
	doesn't connect to EVL until we stopped and restarted it at
	16:55 and this time it has established a successful connection.

	System configuration :
	VAX 7610
	256 MB memory
	VMS 5.5-2
	DECmcc  2.4

	Any help would be appreciated.

	Best regards,
	sylviane.

	Today log of EVL and MCC_DNA4_EVL.



------------------- EVL.LOG ----------------------------------------------------

$ 	ON CONTROL_Y THEN CONTINUE
$	SET NOON
 7-DEC-1995 09:00:25.60 Cr�ation process
%EVL-E-OPENMON, error creating logical link to monitor process ACGR01::"TASK=MCC
_DNA4_EVL"
-SYSTEM-F-LINKEXIT, network partner exited
%EVL-E-WRITEMON, error writing event record to monitor process MCC_DNA4_EVL
-SYSTEM-F-FILNOTACC, file not accessed on channel
%EVL-E-OPENMON, error creating logical link to monitor process ACGR01::"TASK=MCC
_DNA4_EVL"
-SYSTEM-F-NOSUCHOBJ, network object is unknown at remote node
%EVL-E-WRITEMON, error writing event record to monitor process MCC_DNA4_EVL
-SYSTEM-F-FILNOTACC, file not accessed on channel
%EVL-E-OPENMON, error creating logical link to monitor process ACGR01::"TASK=MCC
_DNA4_EVL"
-SYSTEM-F-NOSUCHOBJ, network object is unknown at remote node
%EVL-E-WRITEMON, error writing event record to monitor process MCC_DNA4_EVL
-SYSTEM-F-FILNOTACC, file not accessed on channel
%EVL-E-READEVT, error reading processed event record
-SYSTEM-F-PATHLOST, path to network partner node lost

------------------- MCC_DNA4_EVL.LOG -----------------------------------------

$ 	ON CONTROL_Y THEN CONTINUE
$	SET NOON

	****************************************
		Environnement Production
	****************************************

Declared network object MCC_DNA4_EVL, 7-DEC-1995 11:36:06.60
Wait for EVL link, 7-DEC-1995 11:36:06.60
Received a request to stop the EVL sink, 7-DEC-1995 16:51:43.60
Terminated STOP_SINK_MONITOR thread, thread id = 65538,status=52854793, 7-DEC-1995 16:51:47.15
>>Error receiving EVL link, status = 44, 7-DEC-1995 16:51:49.29
Terminated mcc_dna4_evl_main, 7-DEC-1995 16:51:49.43
  SYS_PNM      job terminated at  7-DEC-1995 16:51:51.42

  Accounting information:
  Buffered I/O count:             141         Peak working set size:    4152
  Direct I/O count:               131         Peak page file size:     20287
  Page faults:                   6621         Mounted volumes:             0
  Charged CPU time:           0 00:00:15.97   Elapsed time:     0 05:15:48.90

------------------- MCC_DNA4_EVL.LOG -----------------------------------------

$ 	ON CONTROL_Y THEN CONTINUE
$	SET NOON

	****************************************
		Environnement Production
	****************************************

Declared network object MCC_DNA4_EVL, 7-DEC-1995 16:55:16.28
Wait for EVL link, 7-DEC-1995 16:55:16.29
Connected to EVL, 7-DEC-1995 16:55:29.27

    The only piece I can offer for review is the network partner exited
    bit...  wouldn't that point to an overloaded system?  I realize you
    said that you have the sink on the same node as the MCC platform...
    that *might* point to something in the way things get started...?
    
    When don't you try and produce a script that goes out and uses MCC and
    enables MCC_DNA4_EVL with a LOOP type of statement on it... in
    otherwords, keep trying after the MCC network platform is up and
    running.
    
    I'm assuming that you are using MCC_DNA4_EVL for rules, possibly
    tracking network events?  You might want to have a looksee at the
    product DETmcc as well... there's a pointer in this conference... you
    might be seeing a sequence issue...  Also, couple of things you might
    check is the way you have DECnet setup... do you use any NETACP
    logicals, ie:  NETACP$PAGEFILE, etc. to boost your parameters a bit?
    You haven't described the environment you're managing... PATHworks? Any
    PClan activity that might be hogging your bandwidth?
    
    Finally, why VMS 5.5-2?  Lots of enhancements in V6.  You might take
    advantage of them... and if you really want to make things better
    update to OSI...smile.
    
    good luck,
    
    /Mic