Conference azur::mcc

If I understand you correctly, if you

	open domain
	double click into decnet IV
	show on subclass of decnet IV (ie line, circuit...) hangs

whereas if you

	open domain
	show on decnet IV
	double click int decnet IV
	show on subclass of decnet IV is okay

Where does it hang? Can you select the show operation? Do you see a management
window at all?	

Thanks,
Verna

I got exactly the same problem.

When you : 

	enter IM PM
	open domain
	double click a global entity
	expand the childs of some subclass
	click on a child instance
	pop down the operation menu
	select *any* verb
	release the mouse button

The IM PM hangs.

	No management window is created.
	No mcc_call is issued to the AM.


BTW: I observed that once the iconic_map was started, it was eating up 100 % of
the CPU even if you do nothing with it ! 
It seems its priority is low (I see a N when doing ps meaning it has been 
"niced") but I am afraid it does not seem clean to have an idle application 
using so much CPU...

Here is a ps output with an iconic_map iconified for 30 minutes :

noemi> ps aux | head -3
USER       PID %CPU %MEM   SZ  RSS TT STAT   TIME COMMAND
lavillat  4622 81.8 25.9 6544 5060 p0 R N   17:36 /usr/bin/mcc_iconic_map
lavillat  4648 25.0  2.8  624  544 p3 R      0:00 ps aux
noemi>

Regards.

Pierre.

    I remember testing this case at least once and didn't see a hang.  But
    I'm not sure I tried it on ut1.2.1.  Verna?
    
    With regard to CPU usage - the event manager (and possibly the MCC X
    dispatcher also) have to poll various resources (like ipc semaphores)
    because of a bad fit between the way CMA works and the way the op sys
    function works.   This makes all Ultrix MMs consume CPU time while
    idle.   While this does not really hurt anything, as you say it is not
    clean - we should not be forcing the Ultrix dispatcher to consider idle
    MCC processes as dispatch candidates.  It also keeps Ultrix from
    swapping out MCC processes as early as it should since the give a false
    indication of being active.
    
    This problem cannot be solved by MCC alone and is part of our
    continuing battle with the NAS folks to get the subsystems that we
    depend on to be better integrated with each other.  We are continuing
    to press these issues.
    

Does this happen in all cases, ie double-clicking into any global entity
and the expanding, etc. OR is it just in a specific case.

How did you determine that non mcc_call is issued to the AM?

Try the same operation from FCL just to make sure it works there.

Verna

Re -1 :
>
>Does this happen in all cases, ie double-clicking into any global entity
>and the expanding, etc. OR is it just in a specific case.
>
NO !!! 
I do not have this problem with DNA4 AM nor with MCC subentities (all
the AM/FM entities). It seems to happen only with own-brewed AMs(/FMs ?).
What is strange is that I get blocked on *any* directive issued for *any*
sub-class entity in this context.

Another hint : the mouse cursor does not react (it is not changing from arrow to
watch).

>How did you determine that non mcc_call is issued to the AM?

I simply run my AM with dbx, setting breakpoints on my SHOW entry, which is
not called in this case.

>Try the same operation from FCL just to make sure it works there.

Done. It works.

Re -2:

I know this problem, but what seems strange is that FMs and AMs are consuming
*some* CPU, preventing them to be swap out, but the IM PM is *really* eating
100 % of CPU (or what is left...) as the FCL PM is not using any CPU when
not used. 

I know the IMPM does a lot of background processing, but I still think it
should not use as much CPU, just to "stay tuned".

My remark was just intended to signal you what may be a problem/bug with IM PM.

Thanks for your help.

Pierre.

    Another hint.
    
    setenv MCC_LOG 0x10000  (or the VMS equivalent)
    
    will trace all RPC traffic between MMs.   Easier than setting
    breakpoints (which can be notoriously misleading - one guy swore to
    me once that his MM wasn't being called, but he forgot what his
    dispatch table looked like and in fact the MM was being called at
    a different entry point!).
    

Re: -1
>
>    Another hint.
>    
>    setenv MCC_LOG 0x10000  (or the VMS equivalent)
>    

The RPC log does not react when it hangs.

Here is the end of the log (just before I killed the IM PM) :
(The call was for testobj_am (id=9))

%MCC-I-LOG, MCC_LOG = 10000

RPC_LOG: ACCEPT CONN: id=5
RPC_LOG: RECV: frm id=5, to id=5
RPC_LOG: RECV REG CMD: id=5
RPC_LOG: SERVER MAIN LOOP: id=5
RPC_LOG: SERVER SLAVE THREAD STARTUP, id=5, thread=10008
RPC_LOG: RECV: frm id=5, to id=5
RPC_LOG: SEND: frm id=5, to id=5
RPC_LOG: RECV: frm id=5, to id=-1
RPC_LOG: RECV: frm id=5, to id=5
RPC_LOG: SEND: frm id=-1, to id=5
RPC_LOG: SEND: frm id=5, to id=5
RPC_LOG: RECV: frm id=5, to id=-1
RPC_LOG: RECV: frm id=5, to id=5
RPC_LOG: SEND: frm id=-1, to id=5
RPC_LOG: SEND: frm id=5, to id=5
RPC_LOG: RECV: frm id=5, to id=-1
RPC_LOG: REG CONN-OK: frm id=-1, to id=9
RPC_LOG: SEND: frm id=-1, to id=9
RPC_LOG: SEND: frm id=-1, to id=9
RPC_LOG: RECV: frm id=9, to id=-1
RPC_LOG: SEND: frm id=-1, to id=9
RPC_LOG: RECV: frm id=9, to id=-1
RPC_LOG: SEND: frm id=-1, to id=9
RPC_LOG: RECV: frm id=9, to id=-1
RPC_LOG: DISCONN-OK, id=-1
RPC_LOG: REG DISCONN: frm id=-1, to id=9
RPC_LOG: SERVER SLAVE THREAD EXIT, stat=52875490, id=5, thread=10008
RPC_LOG: DISCONN-OK, id=5
RPC_LOG: SERVER SLAVE THREAD EXIT, stat=52875490, id=6, thread=10008
RPC_LOG: SERVER SLAVE THREAD EXIT, stat=52875490, id=1, thread=10008
RPC_LOG: DISCONN-OK, id=6
RPC_LOG: REG DISCONN: frm id=6, to id=1
RPC_LOG: DISCONN-OK, id=6
RPC_LOG: DISCONN-OK, id=1
Terminated
noemi> mcc_list
lavillat   168  0.0  8.0 2068 1564 ?  S      0:01 mcc_domain_fm 5 N
lavillat   167  0.0  7.9 2592 1544 ?  S      0:01 mcc_alarms_fm 1 N
lavillat   166  0.0  7.3 2236 1412 ?  S      0:01 mcc_notification_fm 6 N
lavillat   152  0.0  5.6 2108 1088 ?  S      0:03 mcc_testobj_am 9 N
lavillat   151  0.0  3.4 1936  648 ?  S      0:03 mcc_osi_system_am 7 N
noemi>


Regards.

Pierre.