Conference azur::mcc

    I can't respond to your datatype questions but with regard to the
    routing of stdout when an MM is started, there is no way to change
    this with automatic startup; however, you can start the MM yourself
    with a command such as...
    
         mcc_foobar_fm <id> N >& <device> &
    
    where <id> is the enroll id assigned (do a ps -aux when the MM is
    running to see its enroll ID), and <device> is wherever you want stdout
    and stderr to go.   You can change the "N" to a "Y" to force the MM
    to re-enroll.
    
    The only restriction is that this method cannot be used the first time
    the MM is enrolled (i.e., the module is new to the dispatch table).
    

Re .1:


>    
>    The only restriction is that this method cannot be used the first time
>    the MM is enrolled (i.e., the module is new to the dispatch table).
>    
	Curious again...

	Why this restriction ? Is this because you are not supposed to
	guess the <id> value or for some other obscure reason (like tty 
	inode number or something like that) ?

	Regards.

	Pierre.

    Re .0 3)
    
    I succeeded to use an enumerated datatype for a subclass attribute
    identifier.
    
    The commands SHOW CLASS x SUBCLASS * all id and 
    SHOW CLASS x SUBCLASS <instance> all id are both working fine.
    
    Fausse alerte...
    
    
    	Catherine
    
     

    Ugly details for the curious....
    
    There are two parts to the dispatch table - (1) the enrollment table,
    which is a list of each known MM and its assigned enroll ID, and (2) 
    the dispatch table, which is the <v,e,p, routine> entries supplied by
    the MM at its INIT entry point.
    
    Under Ultrix, the enroller (i.e. the PM which fields the user's ENROLL
    command ) is the component which updates part (1).  The enrolled MM
    updates part (2) after it is started (during its INIT entry point
    processing).
    
    Modules are never deleted from the enrollment table, nor are enroll IDs
    reassigned.   So this means that you only have to do a PM-initiated
    enroll once.   After that time, repeated ENROLL commands effectively do
    nothing with regard to updating table part (1) - all that happens is
    that the MM is started with a "Y" as the second argument, which tells
    it to call the INIT entry point to update part (2).
    
    So if you do "mcc_xxx_mm 37 Y &" you are doing exactly what the PM does
    on the 2nd and subsequent enroll.
    
    NOTE THE ABOVE IS AN ARTIFACT OF THE CURRENT ULTRIX IMPLEMENTATION, IT
    MAY NOT WORK THAT WAY ON OTHER PLATFORMS.  IT MIGHT NOT EVEN ALWAYS
    WORK THAT WAY UNDER FUTURE RELEASES OF MCC/ULTRIX. CAVEAT EMPTOR.

Re .4:

Thanks !

Pierre.

    
    Re .0 1)
    
    
    Again...
    
    I succeeded to use a MCC_K_DT_SUBRANGE datatype as an input argument
    of a directive, it works fine.
    
    At least .0 served to lighten some DECmcc mysteries
    
    	Have a good week-end
    
    
    		Catherine