Conference azur::mcc

As far as the Design Framework goes, it should always be using:

	mcc_calloc  &  mcc_free

If it is using only 'calloc', then it's a bug.  I'll look over the code to
make sure - and QAR the Toolkit if I find any problems.

The 'mcc_free' routine does not return any status.  8(

If you are developing on VMS, you can use 'LIB$SHOW_VM' to determine
the amount of memory allocated at any given time -- but you can get odd
results when threads are running (because memory can be allocated/freed
by other threads of execution).

Are you deleting you threads?  If you forget this, the thread context blocks
and the thread stacks are left around; the stacks can be hugh!

I think the 'Alarms internal error (Rule Driver)...' has been corrected
for the next release of Alarms.

Keith
DECmcc Toolkit

    Thanks for the quick response, Keith,
    
    I did have a loose thread hanging around. My understanding was that
    threads were deleted when they terminated ? Adding in a systematic
    mcc_thread_delete solved the problem.
    
    I have also replaced the "calloc" calls with mcc_calloc for esthetic
    purposes.
    
    I still have occasional problem with notifications, it seems notif
    services run into some kind of data overrun if too many rules keep
    firing at short intervals (~ 60 - 90 per minute on a single entity).
    The message is quite clear and says that notification is aborted and
    terminated for my domain. 
    
    Is there a known limit to the number of notifications which can be
    handled in a given time on a suitably configured VS3100 ?
    
    Philippe.

I don't know any hard-and-fast rules for the number of events per minute
on a vs3100 - but the Event Manager Pool is a fixed size and can become full.

The size of the Event Reports can limit the number of events which fit into
the Event Pool.  When I was working on the Alarms Team, I found I got Event
Lost messages at about 300 - 400 Events 'put' but not 'got'.  This was 6
months ago - and things could have changed.

With regards to deleting threads - there are a few rules.

>>> If you have a child thread with no parent (ie, a detached thread) - the
    thread must delete it self when it is done.  It must get it's own thread
    id with 'mcc_thread_get_self' then call 'mcc_thread_delete'.

>>> When a parent thread is joining with a child thread, the child thread must
    not delete itself - the parent must delete the child when the join
    completes.

    If the child deleted itself then returned, the parent would receive an
    'existence' error for the thread-status argument of the join routine.

Keith Roberts
DECmcc Toolkit Team

We recently found a bug in the notification FM/system et.al. The notification
FM was expecting the no_more response to be one code, while most of the other 
modules used a different code -- therefore the bad error message and fatal
handling, the code we got back was unexpected.

We also found another problem where we were returning the wrong CVR in an
overrun condition (exception instead of resposne), and that also caused a
bad error message  and notification to abort. These will both be fixed in
the first 1.2 release.

jill

    Thanks for the responses, Jill & Keith,
    
    Keith, you mention something about the alarms rule driver being fixed
    in the next release : 
    
    �Alarms internal error (Rule Driver): Could not delete callargs->p_hand
    �le :  52876210
    
    Can you tell me what it's due to, as it seems to resurface... Is there
    a workaround ? Or is it something in my code ?
    
    �hR.

The 'Alarms Internal Error (Rule Driver)' has something to do with Events
(I think) - I'll ask the Alarms PL to answer this one.

Keith

  Hi �hili��e, 

  RE:

�Alarms internal error (Rule Driver): Could not delete calorics->p_handle :  52876210
  	
 If you look in to MCC_MSG.H you will find that the number 52876210 translates to
 MCC_S_INV_HANDLE_STATE.  In rule driver I had some printfs that will write the 
 above 	 message to the screen when rule driver detects a bug. What this means 
 is that you are witnessing a bug. Ed Hronik, who was working on alarms for a short
 time was able to trace this bug to event manager. 
  
 When a thread term alert is issued as a side effect of issuing EXIT command 
 event manager would delete its data structure without waiting for Alarms to 
 send a handle cancel request. Alarms would then try to send the request to cancel 
 the call, event manager would indicate that the handle is not valid any more!
 
	
 Now from Alarms perspective the handle is valid! We found the source of this bug
 after V1.1 shipped. Next release will have the bug fix.

 Yes, it was my mistake not to put the printf statements under debug logical 
 control. I don't have any work around for this problem. Other than seeing
 the above error message, are you experiencing any other side effects?

 Thanks,

 - Anil Navkal