Conference azur::mcc

4484.0. "Entity Existence Cannot Be Determined - fixed problem but don't know what happened" by MDCRAB::STUART (Scott Stuart - MARVA Network Sales Support DTN 341-3132 - MARVA District) Tue Feb 02 1993 08:58

I was getting an Entity Existence Error as documented below.  
I hvae fixed the problem (with help from teh CSC) but do not understand
what caused it, or exactly why it was fixed.

The problem was:

I can see the entity and its subentities but cannot perform an export operation.
I have tried from the command line and from the iconic map.
I am running ULTRIX 4.3 and MCC 1.2.3


MCC> show snmp  nyusp-inp1 , in domain nyusp
Using default ALL IDENTIFIERS

SNMP nyusp-inp1
AT 1993-02-01-14:19:34.193 Identifiers

Examination of attributes shows:
                        Registered Name = LOCAL_NS:.nyusp-inp1
                                Address = 128.1.32.60
                                   Name = nyusp-inp1

MCC> show domain nyusp all char

Domain LOCAL_NS:.nyusp
AT 1993-02-01-14:14:47.824 Characteristics

Examination of attributes shows
                               Owner ID = "root"
                              Directory = /usr/mcc/nasdaq

MCC> export snmp  nyusp-inp1 , in domain nyusp

SNMP nyusp-inp1
AT 1993-02-01-14:22:44.581

The requested operation cannot be completed
                      MCC Routine Error = %MCC-F-FATAL, fatal DECmcc error ,
                  Entity Existence Info = Entity Existence Cannot Be Determined




I fixed it by taking all the files in /var/mcc/*exp* and moving them somewhere else.
I thne stopped and restarted MCC and it created new files and I can now
export.

The files I moved are:

-rw-r--r--  1 root  1024 Dec  3 10:30 mcc_00.mcc_exp_attr012_pms
-rw-r--r--  1 root     0 Dec  3 10:26 mcc_00.mcc_exp_attr012_pms.dir
-rw-r--r--  1 root  1024 Jan 20 18:13 mcc_00.mcc_exp_inst012_pms
-rw-r--r--  1 root     0 Dec  3 10:26 mcc_00.mcc_exp_inst012_pms.dir
-rw-r--r--  1 roo 256000 Feb  1 12:00 mcc_0478000400aa000001cbf70babb1e484.mcc_exp_attr012_p
-rw-r--r--  1 root  4096 Feb  1 11:59 mcc_0478000400aa000001cbf70babb1e484.mcc_exp_attr012_p.dir
-rw-r--r--  1 root  1024 Jan 20 18:13 mcc_0478000400aa000001cbf70babb1e484.mcc_exp_attr012_ph
-rw-r--r--  1 root     0 Jan 20 18:13 mcc_0478000400aa000001cbf70babb1e484.mcc_exp_attr012_ph.dir
-rw-r--r--  1 root 16384 Feb  1 09:49 mcc_0478000400aa000001cbf70babb1e484.mcc_exp_inst012_p
-rw-r--r--  1 root  4096 Jan 29 13:44 mcc_0478000400aa000001cbf70babb1e484.mcc_exp_inst012_p.dir
-rw-r--r--  1 root 13312 Jan 29 13:40 mcc_0478000400aa000001cbf70babb1e484.mcc_exp_inst012_ph
-rw-r--r--  1 root  4096 Jan 29 13:39 mcc_0478000400aa000001cbf70babb1e484.mcc_exp_inst012_ph.dir


the new files created by MCC are:

-rw-r--r--  1 root  1024 Feb  1 17:49 mcc_00.mcc_exp_attr012_pms
-rw-r--r--  1 root     0 Feb  1 17:49 mcc_00.mcc_exp_attr012_pms.dir
-rw-r--r--  1 root  1024 Feb  1 17:49 mcc_00.mcc_exp_inst012_pms
-rw-r--r--  1 root     0 Feb  1 17:49 mcc_00.mcc_exp_inst012_pms.dir
-rw-r--r--  1 root  9632 Feb  1 18:12 mcc_0478000400aa000001cc007663eb7740.mcc_exp_attr012_p
-rw-r--r--  1 root  4096 Feb  1 18:11 mcc_0478000400aa000001cc007663eb7740.mcc_exp_attr012_p.dir
-rw-r--r--  1 root   1024 Feb 1 17:50 mcc_0478000400aa000001cc007663eb7740.mcc_exp_attr012_ph
-rw-r--r--  1 root    0 Feb   1 17:49 mcc_0478000400aa000001cc007663eb7740.mcc_exp_attr012_ph.dir
-rw-r--r--  1 root32768 Feb   1 18:12 mcc_0478000400aa000001cc007663eb7740.mcc_exp_inst012_p
-rw-r--r--  1 root  4096 Feb  1 18:11 mcc_0478000400aa000001cc007663eb7740.mcc_exp_inst012_p.dir
-rw-r--r--  1 root 32768 Feb  1 18:12 mcc_0478000400aa000001cc007663eb7740.mcc_exp_inst012_ph
-rw-r--r--  1 root  4096 Feb  1 18:11 mcc_0478000400aa000001cc007663eb7740.mcc_exp_inst012_ph.dir


My questions are:

1. What is the correct way to fix this problem?

2.  What is the purpose of each of these file?  Did I have to copy them
all or was there just one that was corrupted?  (I still have the old
files).

3.  Is there a document which indicate the purpose of eac file in /var/mcc?

I do not feel very comfortable letting this go to the customer in this
state.  This is a pilot network with very little actitivy.  What is going
to happnen when we scale this up 10-20 times?

thanks ... scott

>I hvae fixed the problem (with help from teh CSC) but do not understand
>what caused it, or exactly why it was fixed.

	You had corrupted one of the Exporter's private repository.
	Usually it happens when the MCC Exporter process is killed 
	during the first export operation for a given database name.

>1. What is the correct way to fix this problem?

	The correct way is what you did.
        In addition to this you could try to use a new database name 
	in the export command. It should work with old files.

2.  What is the purpose of each of these file?  Did I have to copy them
all or was there just one that was corrupted?  (I still have the old
files).

	These files are Exporter's private repositories where information
	about databases and exporting requests are stored.
	I would not recommend you to restore only one of this files. 


>I do not feel very comfortable letting this go to the customer in this
>state.  This is a pilot network with very little actitivy.  What is going
>to happnen when we scale this up 10-20 times?

	I do not understand how this problem is related to the network 
	activity. 


By the way, you do not need to specify "in domain" qualifier in the 
following command:

>	MCC> export snmp  nyusp-inp1 , in domain nyusp



	SAm
    

Thanks.  I have a few comments and another question.

>	You had corrupted one of the Exporter's private repository.
>	Usually it happens when the MCC Exporter process is killed 
>	during the first export operation for a given database name.


If by database name you mean mcc_expport_rdb then this was not the first
export operation.  I was creating and deleting exporing on mulitple
entities.


>	I do not understand how this problem is related to the network 
>	activity. 

Creating canned reports shold be a relatively simple procdure.
This is one of many problems I have encountered for this and other
'simple' operatons. Many of these problems were operator error,
but too many were MCC idiosyncrasies.  

I know that I need a different design for the production network 
(1500+ entities) than I am using for the pilot, but I am wondering how 
scalable MCC (and MCC ULTRIX) really is.  
I am also hoping that v1.3 will fix some of these problems
But enough of my soapbox.


3.  Is there a document which indicates the purpose of each file in /var/mcc?
 

thanks ... scott