Conference azur::mcc

I personally have not seen this one, but I have passed it along
to the appropriate people to look into.

>%Internal error: cma__open_general: unexpected fstat error

Without more information, I don't think we can isolate why
CMA is generating an error.  But it probably kills the thread,
which explains the later RPC errors.  What is executing
when you see this error?  Have you noticed if an MM is terminated
when this happens, and if so, which?

>dcethreads: Error opening message catalog "dcethreads.cat"
>dcethreads: Error closing message catalog "dcethreads.cat"

This may be because the NLSPATH variable is not set to point
to the internationalized message file.  It must be set to
/usr/mcc/mcc_system/%N

This is set in mcc_login.csh.  Could you check your environmental variables
with printenv, and also look in the /usr/mcc/mcc_system/mcc_login.csh?

-- Erik

By the way, you could check to see if there is a file
/usr/mcc/mcc_system/dcethreads.cat present on your system.

Thank you for your reply Erick.

	It is not that obvious for me to know EXACTLY where the problem is:

	1. This problem happens some times to times.
	2. It appears in a background module that I have not written and that I
	   spawn via a mcc_lib_detach in the PROBE routine of my FM.

	But I know, of course roughly what does this background module:
	- It creates a Thread which does an mcc_event_get
	- it creates a dummy thread which writes some !@#$% infos in a file

	The problem appears when I do severall times an ENROLL which means
	that severall background processes are running at the same time the same
	image (i.e. all the detached backgounds have a thread waiting
	for an mcc_event_get to fire)

	I have defined the correct environment variable (NLSPATH) in my 
	.login and now the following (correct) messages are displayed:

MCC> %Internal error: cma__open_general: unexpected fstat error
Thread Exception: Internal error detected in thread library

Note that in the production version of our FM, we will test first if our
background server exists, if yes we will kill it and we will recreate a new one.
(a little bit like when MCC enrolls a module, but I'm not trying to teach you
 how MCC works :-) :-)

Therefore we hope that with our production version, we will not meat this error
any longer.... but, but, but ...

I hope these informations can help you to find the exact problem...
Try to keep me informed (via this note or by mail)
Regards,
Damien.

We are working to isolate why this message is appearing, but
it may take a while, since the message is pretty generic.

BTW, why did you have to add NLSPATH to your .login?
It should be in mcc_login.csh, which you should be sourcing
in your .cshrc (or mcc_locain.sh, from .profile for sh users)

-- Erik

>>It should be in mcc_login.csh, which you should be sourcing
>>in your .cshrc (or mcc_locain.sh, from .profile for sh users)
	Done.

This time the same error appeared with only ONE background process in the
system. But just before re-enrolling my module and therefore before creating
this new background I did some KILL -9 commands to kill the existing
backgrounds.

Can the event manager be confused if somebody does a "wild kill" of one (or
severall processes..) which were waiting for an mcc_event_get to fire ???

Regards,
Damien.

    Maybe.   This one is driving us crazy.  No one has managed to create 
    even a poorly reproducible scenario.
    
    The error in question is occuring in one of the CMA I/O intercepts
    (socket, open, close, read, etc).  We can't tell which one. It's doing
    an fstat(2) on the file  to get information on how to further process
    it.  According to the man page, the only errors which can occur that
    CMA is not already handling are impossible (and I've looked at this
    code a dozen times).
    
    All we know is that it has something to do with starting up processes
    (we see it most often here during installations where we do a zillion
    enrolls),  but it is not limited to enroll, and I am not even sure if
    it is limited to starting MCC management modules because we also do
    fork/exec for other reasons (starting detached daemons, handling the
    SPAWN command, etc).
    
    I am guessing that there is a race somewhere between process startup
    and a CMA I/O operation which is bumping into an unsynchronized data
    structure, but this is pure speculation.
    
    There are no other users of CMA seeing this problem.
    
    If you are seeing this problem with some regularity, we need your help
    to isolate the problem as much as possible, given the information
    above.

	Also seen in t1.2.4 on Ultrix 4.2A.

	Fresh install of Ultrix and DECmcc produced the following error
	sequence.

	the following is a copy of the installation.....

	enrolling mcc_exporter_fm...DECmcc (T1.2.4)

	enrolling mcc_historian_fm...DECmcc (T1.2.4)

	enrolling mcc_notification_fm...DECmcc (T1.2.4)

Waiting: MM mcc_notification_fm has not completed startup
	enrolling mcc_pa_fm...DECmcc (T1.2.4)

	enrolling mcc_registration_fm...DECmcc (T1.2.4)

	enrolling mcc_sample_am...DECmcc (T1.2.4)

%Internal error: cma_open_general: unexpected fstat error
Thread Exception: Internal error detected in thread library
	enrolling mcc_tcpip_am...DECmcc (T1.2.4)


Now Initializing DECmcc databases...



	The IVP passes and I can create a top level domain. If I then
	try to create a subdomain from the toolkit the following error 
	occurs....


	a create entity window opens up..

	The requested operation cannot be completed

	%MCC-E-IO_ERROR, error was returned by I/O facility


	The decterm where DECmcc was started has the following message...

	Fatal MIR I/O error, repository=mcc_dns_ent, errno=1


I will investigate further.

>%Internal error: cma_open_general: unexpected fstat error
>Thread Exception: Internal error detected in thread library

This is a know problem (documented in the release notes) that will be
corrected by a future release of the CMA threads package.
It is harmless.

>	%MCC-E-IO_ERROR, error was returned by I/O facility
>	Fatal MIR I/O error, repository=mcc_dns_ent, errno=1

This is telling you that you have not changed the access to the
repository files in /var/mcc.  Please see the installation guide.