Conference azur::mcc

Charles, since you are writing a product *to be managed*, you should
probably start with the EMA folklore and entity model documents. If you
follow those guidelines, and use support tools like the common agent, you
should not have to write an AM. You *generally* should not have to
write a PM or FM either, unless you plan on writing some sort of "added value"
management application tailored specifically to managing EDI.

Mark

			  However when looking at 'DECmcc Management Module
			  Programming' it only talks about Access Modules...
			  are there examples of how to implement my own PM's 
			  and FM's in some other doc ? Or should it be self 
			  evident from the spercification of the DECmcc_call
			  services ?

JLL>
JLL> There isn't any documentation on writing a PM because it isn't offically
JLL> supported.   
JLL>
			  Presumably if I only write the AM, its enrollment
		 	  generates enough tables to drive the default DEC
			  mcc PM's....giving me free DECmcc style CLI and Iconic
			  UI ?
JLL>
JLL> Yes, if you provide the "enrollment" information, you will be able to 
JLL> execute your MMs command through the FCL and Iconic Map.
JLL>


			o Can a single management module itself by 
			  multi-threaded ? Is DECmcc Muti-threaded environment
			  CMA.THREADS (POSIX) ?
JLL> 
JLL> DECmcc is multi-threaded.
JLL> 

			o If I design and write my DECmcc Management modules
			  (using standard  portability guidlines) for DECmcc
			  on VMS will they run on DECmcc ULTRIX ? i.e. is the
			  mcc_call_xxx interface and thread envirnoment uniform
			  across DECmcc VMS and DECmcc ULTRIX ?
JLL>
JLL> Yes to both questions.  There are some differeces between the patforms,
JLL> though, that may affect your design.  On the VAX/VMS platform, all 
JLL> management modules are shareable libraries and are mapped into the same 
JLL> process space.  On ULTRIX, each  management module runs as a seperate
JLL> process.
JLL>

            <<< NOTED::DISK$NOTES4:[NOTES$LIBRARY_4OF5]MCC.NOTE;1 >>>
            -< DECmcc Product Family; Introductions 6; Kits 3 & 40 >-
================================================================================
Note 976.3                   Some general questions                       3 of 3
SIEVAX::FOX                                          22 lines  20-MAY-1991 06:18
                                 -< EMAA /mcc >-
--------------------------------------------------------------------------------
    
    Thanks for the answers in .1 and .2.
    
    It looks like my simplest option is to define my Entities as sub
    Entities of Phase V node and simply use the existing MCC Phase V
    access method. As I undertand it this will imply my Entities will
    be limited to nodes with wave 1 of DECnet Phase V.
    
    I am not clear where the 'common agent' fits in with Mcc. Presumably
    this is 'EMMA the common agent for VMS Entities' ? Is it simply another
    mcc access agent...but one that extends the management to any VMS
    Entity wether on a DECnet Phase IV or Phase V node ?  Presumably it
    would mean defining my Entities as sub Entities of  VMS  node ? Since
    I want my distributed application to be portable..I think that means
    I should stick with being sub-entity of Phase V node and take the hit
    of wave 1 Phase V as a prerequisite...does that seem reasonable ?
    
    Last dumb question, is the full MCC director needed on the node of a
    remotely managed Entity or just some sub set i.e. CMIP listner CML ?
    
    Charles
    

    Re: .-1, last question:  You only need CML & CMIP (and ability to send
    events via CMIP to remote director.  Talk to router implementations
    for more details.
    
    There is a common agent notes file in decwet::common-agent.notes,
    which contains a pointer to kits, specs, etc.
    
    

Charles,

I would  recommend  that  you  wander  round  to  REO2-G/H9 and talk to Dave
Rusling.  He can explain a lot of these issues and provide some suggestions.
But don't tell him I sent you :-)

Graham

    Re : .4 :
    
    I get a "file not found" when I try to access the DECWET::COMMON-AGENT
    notefiles. is there another pointer ? Spelling mistake ? 
    
    Thanks for your help,
    
    Philippe.

I had this problem.  The reason is that the file extension is .NOTES and not the
default which is .NOTE.  Use DECWET::COMMON-AGENT.NOTES and you should be OK.

Chris.