Conference azur::mcc

>    MCC> enroll mcc_tps_am
>    %MCC-W-ENRDSPTBLNOTUPD, enrollment successful; dispatch table file not
>    updated

This warning is probably telling you that you do not have write
access to the dispatch table.  By default, only root can update the
dispatch table.

>
>This warning is probably telling you that you do not have write
>access to the dispatch table.  By default, only root can update the
>dispatch table.
>
>
My 2 � :

a side effect of this is that the MM process is not started
at enrollment time, but at the first directive issued to it.

I you modify your MM you need to re-enroll it at each modification (link)
to have things working correctly (this is not the case on VMS with shareable
images), and so you definitely need write access to the dispatch table (do
chmod +w /usr/mcc/*disp*.dat ).

Regards.

Pierre.

>a side effect of this is that the MM process is not started
>at enrollment time, but at the first directive issued to it.

I'm not sure what you mean.  If the enrollment succeeds, then the MM
will be started at enrollment time.  If it then terminates, it will
be restarted as needed at dispatch time.

If the enrollment fails, then the module will no start at all
(at dispatch time, results will be unpredicatable, since entry
points in the dispatch table probably won't match the executable).

>I you modify your MM you need to re-enroll it at each modification (link)
>to have things working correctly

This is correct.

>and so you definitely need write access to the dispatch table (do
>chmod +w /usr/mcc/*disp*.dat ).

Or create a group (say, mccdispatch), add users who need access to
that group, and "chgrp mccdispatch /usr/mcc/*disp*.dat"

-- Erik

>================================================================================
>Note 1941.3                   Starting AM on Utrix                        3 of 3
>TOOK::MINTZ "Erik Mintz"                             26 lines  16-DEC-1991 08:44
>--------------------------------------------------------------------------------
>
>>a side effect of this is that the MM process is not started
>>at enrollment time, but at the first directive issued to it.
>
>I'm not sure what you mean.  If the enrollment succeeds, then the MM
>will be started at enrollment time.  If it then terminates, it will
>be restarted as needed at dispatch time.
>
>If the enrollment fails, then the module will no start at all
>(at dispatch time, results will be unpredicatable, since entry
>points in the dispatch table probably won't match the executable).
>

What I noticed is a bit more subtle : since the message says "Enrollment 
successful... " and has only a warning (or information) severity, you can say it
is successful, *but* in fact the MM process is not created, and so you can say
it is not successful !

So maybe is it a bug ?

Here is a log of the behavior :

noemi> ls -l $MCC_SYS_LOCATION/*disp*
-r--r--r--  1 lavillat   229964 Dec 16 15:02 /usr/users/lavillat/mcc_system/mcc_
dispatch_table.dat
noemi> ps aux | grep mcc
lavillat  9625  0.0  0.2   40   32 p1 S      0:00 grep mcc
noemi> manage
DECmcc (T1.2.1)

MCC> enroll mcc_testobj_am
%MCC-W-ENRDSPTBLNOTUPD, enrollment successful; dispatch table file not updated
MCC> exit

noemi> ps aux | grep mcc
lavillat  9628  0.0  0.2   40   32 p1 S      0:00 grep mcc
noemi>

No MM is running, so no enrollment was made.

Regards.

Pierre.

    This is a bug in the port of the enrollment code from VMS to Ultrix.
    
    The code to do in-memory only dispatch table update was simply moved to
    Ultrix but no one (me :-) noticed that although it works it isn't
    particularly useful under the Ultrix execution model for the reasons
    cited earlier, as well as the fact that there is a dispatch table in
    every process under Ultrix and the "in-memory" enrollment will only
    update the table in the PM doing the enrollment.  If you try, for
    example to enroll an AM accessed through a chain of other MMs, there
    is no way to ever get this method to work.
    
    It would appear that most people debug private MMs by redefining the
    system directory logicals/env variables and copy the system dispatch
    table to a private, writable version in their own directories.  This
    works on both platforms and it seems to me we should probably not allow
    the case of letting an enrollment "succeed" if the dispatch table as
    currently defined is not writable.
    
    Comments?