Conference azur::mcc

2462.0. "mcc_notification_fm dies after enrolment" by TAEC::WEBER () Mon Mar 02 1992 13:52

    The problem concerning mcc_notification_fm posted in note 2324
    has not been solved at the customer's site, and this is becoming
    critical to them (and us by the way).

    The customer is working with the EFT DECmcc T1.2.4, and the file
    protections havee been verified as indicated in the previous note.
    I tried the suggestion:
	% setenv MCC_FCL_PM_LOG 0x8000
	% setenv MCC_NOTIFICATION_FM_LOG 0x88
    And then
    /usr/mcc/mmexe/mcc_notification_fm 11 Y

    What happens is that the message is displayed :
	%MCC-I-ENRDUPLENTRY, enrollment successful; duplicate entries found
	and replaced;
   followed by	
	%MCC-W-ENRDUPLENTRY, enrollment successful; duplicate entries found
	and replaced;
	
    - At the customer's site, two messages are displayed (one is
    Informational, the other one is Warning) and then the process
    EXITS (without notifying anything else).
    - If the same is run in SU, the process also hangs up.
    
    The ps -uax command shows no mcc_notification_fm.
    No core is generated.
    So, the problem is not that the mm does not start in the FCL expected
    timeframe, it is that the process hangs up (complete).
    
    Now, on my system, the notification fm runs properly.
    
    Question 1:
    What is the meaning of bitmasks, and what values could lead me to 
    accurate informational messages, in order to give me directions for
    investigation. Any documents on that ?
    
    Question 2: 
    What are the most probable parameters that could make the process fail.
    Any suggestion ?

    Thanks to answer

    Florence-and-all-people-concerned-by-this-customer
            

    
    Okay, lets start with the first item:
    
    1) do the mcc_target*.dat files exist in the /var/mcc directory? 
    there should be two files, if they are not there then your protection
    problem may be with creating these new files. 
    
    2) Have you tried removing the targetting database files and restarting
    the enroll to see if you have corrupt data files?
    
    The logbits:
    	mcc_fcl_pm_log x8 means to dump all call parameters
        mcc_fcl_pm_log x20 means to dump the handle state between calls
                           (usefull in debugging WITH and wildcarded cmds)
        mcc_fcl_pm_log x8000 means dump all of the call parameters on the
                             NOTIFY commands
    
    
        mcc_notification_fm_log x8 dumps the call information on the
                                   request/receive end of things
        mcc_notification_fm_log x80 means to dump the data on the
                                    getevent end of things
    
    As to probable parameters as to why this fails, the only additional
    idea I have is the targetting database, could you just make sure that
    there aren't two copies of the image around? And, if you are still
    having problems it is time we get in direct communications and figure
    out what is up.
    
    Jill
    (notification PL)