Conference azur::mcc

>    1) What is the impact of the directive type (Examine, Deposit,
>    action...) in the MSL spec ? Does it affect the way the directive
>    dispatching takes place, or the arguments it can take ?
    
     The impact on dispatching is that an action directive is dispatched
     based only on <v,e>  and not <v,e,p>
    
     An action directive takes arguments.  An examine/modify directive
     takes attributes or attribute partitions.  This affects the parsing
     of the verb.
    
     Arguments are sent to the service provider in in_p.
     Partitions are sent via the partition (3rd) parameter.
    
    
    
    
>    2) Is there a limit on the number of threads running simultaneously?
>    We've worked out that we're alikely to have as many as 2000 threads
>    active at any one time...
    
     The thread	max is based on the resource consumption per thread.  Memory
     is the main culprit, with stack pages being the biggest contributor
     in most MMs.  Each thread between MMs in separate processes also eats
     up an open socket in each process.
    
     If you have enough swapfile and file table slots you could get up to
     2000, but with more typical MCC configurations 2000 is unlikely. 200
     is a more realistic limit.
    
    
    
>    3) on DECmcc-Ultrix, if we use the local namespace, how do we go about
>    creating BackTranslation directories ? Or do we *have* to use DNS if we
>    want to implement full registration support ?
    
     Why do you need backtranslation directories.  The local MIR uses
     MIR alternate identifiers to achieve the same thing.   What do you
     mean by "full registration support"?

    
    Jim,
    
    here a some clarifications :
    
>     If you have enough swapfile and file table slots you could get up to
>     2000, but with more typical MCC configurations 2000 is unlikely. 200
>     is a more realistic limit.
    
    If I'm managing 1000 entities and I have an alarm rule running on each
    entity, surely that means 1 thread per entity in the alarm rule driver
    + 1 thread in the AM to handle each GETEVENT directive ???
    
>     Why do you need backtranslation directories.  The local MIR uses
>     MIR alternate identifiers to achieve the same thing.   What do you
>     mean by "full registration support"?

    Fukll registration FM support means that my entities have a DNS
    fullname as primary identifier and a "real" address as an alternate
    identifier. (See the end of the MM Developper's guide for more info).
    In V1.1 , this meant that you *had* to create a
    .MCC_<class>_BackTranslation directory to store soft links to the
    primary identifer.
    
    My question is : how are backtranslations worked out if the Local
    Namespace is used ? Is there the equivalent of Backtranslation
    directories when new entities are added to MCC, and if so, how are they
    created ?
    
    Regards,
    
    Philippe.
    
    
    

    1) There is one thread in the alarm FM per enabled rule.  No way around
    this one until we implement rule wildcarding.  We are, however, working
    on making these threads as "lightweight" as possible so you can have a
    lot of them.
    
    2) The threads in the AM are only needed for the polling operation
    itself.  We have made a change to the Ultrix RPC to delete any idle
    server threads after one minute.  So the AM threads are much more
    dynamic - in general you will have much less than 1000 if you have
    1000 enabled rules.
    
    3) You only need backtranslation directories in DNS because DNS is
    only capable of locating an object by a single identifier.  The MCC
    MIR is capable of retrieving an object by either primary or
    secondary identifier, without the user creating any special
    "directories" or anything else.  In otherwords
    
                     dir snmp 16.20.144.69
                     dir snmp LOCAL_NS:.my_snmp_fullname
    
    Take the exact byte-for-byte code paths through the MIR whereas in DNS
    they are very different things.
    

    Thanks for the answers Jim.
    
    Just one more point : I don't understand how you can delete pending
    threads handling the GETEVENT directive, as this is the thread which
    has to pick up events when the event sink passes them on to the event
    manager.....
    
    Regards,
    
    Philippe.

    Good observation Philippe, those threads don't delete since they never
    return to the rpc server idle point.  Coming up with optimizations
    to threads doing getevent operations is difficult without some major
    rework of event handling.  We are thinking about this one.