Conference azur::mcc

    Do you have an environment variable called MCC_SAMPLE_AM_HOST
    set by accident?
    
    What is happening is that the kernel is trying to get the IP address
    of the system that the sample AM is running on.  Since distributed
    MCC is not supported yet, this should simply return the IP address
    of the local system.   The system call that is failing is
    "gethostbyname" - you could look in the man pages to see if any of
    the failure conditions apply to your system.   I would also check to
    make sure your TCP/IP setup is OK - try pinging yourself, etc.
    

    
    I have a question about inheritance of enrironment variables with
    ENROLL.
    
    I have tests that run.  Our AM needs to have an environment variable
    set up prior to its execution. After enrollment (when there is not
    already an instance of the AM running) the AM seems to inherit this
    value correctly.
    
    But when the following test is run, it first sets the environment
    variable to a NEW value, then ENROLL's again (causing the first instance
    of the AM to be killed).  Yet, it appears that the environment variable
    still has the value from the previous instance of the ENROLL.  Is this 
    true?
    
    In my test, I need to restart the AM in such a way that it inherits a
    new value.  Must I first "kill" the AM, or is ENROLL supposed to allow
    this?
    
    Marc
     

Starting an MM on ULTRIX involves creating a process.
That process inherits its environmental variables from its parent
process.  In the case of enrollment, that means it takes whatever
environmental variables are active in the PM process that enrolls it.

However, if a module is started some other time, it may be started by
another MM (for example, the alarms FM might start an AM), then the
environmental variables will be inherited from that parent.

If what you do is:

  1) Exit from the PM (NOT spawn)
  2) Change a variable
  3) Enter the PM
  4) Enroll your AM

That should do what you want.  I think you intended to include a log in
your base note, but since it is not there, we can't tell what you have
done so far.

    
    Pardon my ingorance, but how is the PM spawned?  Is "manage" the PM? 
    Or is the PM a separate MM?
    
    When I run manage, a "ps" does not show any other processes started as
    a result.  Only after running "manage enroll my_am" do I see "my_am"
    running.  Am I to assume that the "my_am" process started from the
    enroll command will enherit the env vars that were active at the time
    the "manage enroll" command executed?  
    
    

    
    
    PS, here is the sequence and what my suspicion is as to the results.
    
    setenv TEST_ENV foo
    manage enroll my_am
    setenv TEST_ENV bar
    manage enroll my_am
    
    My tests suggest that the above sequence causes the second "enroll" to
    still have the value "foo" for the environment variable TEST_ENV.
    
    

    setenv MCC_LOG 0x10000 and repeat the above 4 commands.  Post the
    output.
    

    
    maces.tay1.dec.com!sevigny> setenv MCC_MMEXE_LOCATION
    /pdir/ptpmresults/cd5a_debug
    maces.tay1.dec.com!sevigny> setenv ACMS_CONFIG foo
    maces.tay1.dec.com!sevigny> setenv  MCC_LOG 0x10000
    maces.tay1.dec.com!sevigny> manage enroll mcc_tps_am
    %MCC-I-LOG, MCC_LOG = 10000
    
    DECmcc (T1.2.7)
    
    %MCC-I-LOG, MCC_LOG = 10000
    
    RPC_LOG: CONN-FAIL: frm id=2, to id=1
    RPC_LOG: DISCONN-OK, id=2
    RPC_LOG: REG DISCONN: frm id=2, to id=1
    Starting MM mcc_tps_am (enroll ID 1) from MM enroll id 2
    RPC_LOG: CONN-FAIL: frm id=2, to id=1
    RPC_LOG: DISCONN-OK, id=2
    RPC_LOG: REG DISCONN: frm id=2, to id=1
    %MCC-I-LOG, MCC_LOG = 10000
    
    RPC_LOG: CONN-FAIL: frm id=2, to id=1
    RPC_LOG: DISCONN-OK, id=2
    RPC_LOG: REG DISCONN: frm id=2, to id=1
     %MCC-I-ENRDUPLENTRY,  enrollment successful; duplicate entries found
    and replaced
    RPC_LOG: CONN-FAIL: frm id=2, to id=1
    RPC_LOG: DISCONN-OK, id=2
    RPC_LOG: REG DISCONN: frm id=2, to id=1
    %MCC-I-LOG, MCC_LOG = 10000
    
    RPC_LOG: SERVER ENTRY: id=1
    RPC_LOG: SERVER MAIN LOOP: id=1
    RPC_LOG: ACCEPT CONN: id=1
    RPC_LOG: REG CONN-OK: frm id=2, to id=1
    RPC_LOG: SEND: frm id=2, to id=1
    RPC_LOG: DISCONN-OK, id=2
    RPC_LOG: REG DISCONN: frm id=2, to id=1
     RPC_LOG: RECV: frm id=1, to id=1
    RPC_LOG: RECV REG CMD: id=1
    RPC_LOG: SERVER MAIN LOOP: id=1
    RPC_LOG: SERVER SLAVE THREAD STARTUP, id=1, thread=10008
    RPC_LOG: SERVER SLAVE THREAD EXIT, stat=52875490, id=1, thread=10008
    RPC_LOG: DISCONN-OK, id=1
    maces.tay1.dec.com!sevigny> setenv ACMS_CONFIG bar
    maces.tay1.dec.com!sevigny> manage enroll mcc_tps_am
    %MCC-I-LOG, MCC_LOG = 10000
    
    DECmcc (T1.2.7)
    
    %MCC-I-LOG, MCC_LOG = 10000
    
    RPC_LOG: EVENT RECV: id=2
    RPC_LOG: EVENT RECV: id=1
    Killing existing MM mcc_tps_am (pid 6081)
    Kill succeeded
    RPC_LOG: CONN-FAIL: frm id=2, to id=1
    RPC_LOG: DISCONN-OK, id=2
    RPC_LOG: REG DISCONN: frm id=2, to id=1
    Starting MM mcc_tps_am (enroll ID 1) from MM enroll id 2
    %MCC-I-LOG, MCC_LOG = 10000
    
    %MCC-I-LOG, MCC_LOG = 10000
    
    RPC_LOG: CONN-FAIL: frm id=2, to id=1
    RPC_LOG: DISCONN-OK, id=2
    RPC_LOG: REG DISCONN: frm id=2, to id=1
     %MCC-I-ENRDUPLENTRY, enrollment successful; duplicate entries found
    and replaced
    RPC_LOG: SERVER ENTRY: id=1
    RPC_LOG: SERVER MAIN LOOP: id=1
    RPC_LOG: EVENT RECV: id=1
    RPC_LOG: ACCEPT CONN: id=1
    RPC_LOG: REG CONN-OK: frm id=2, to id=1
    RPC_LOG: SEND: frm id=2, to id=1
    RPC_LOG: DISCONN-OK, id=2
    RPC_LOG: REG DISCONN: frm id=2, to id=1
    RPC_LOG: RECV: frm id=1, to id=1
    RPC_LOG: RECV REG CMD: id=1
    RPC_LOG: SERVER MAIN LOOP: id=1
    RPC_LOG: SERVER SLAVE THREAD STARTUP, id=1, thread=10008
    RPC_LOG: SERVER SLAVE THREAD EXIT, stat=52875490, id=1, thread=10008
    RPC_LOG: DISCONN-OK, id=1
    RPC_LOG: EVENT RECV: id=1
    RPC_LOG: EVENT RECV: id=1
    RPC_LOG: EVENT RECV: id=1
    RPC_LOG: EVENT RECV: id=1
    RPC_LOG: EVENT RECV: id=1
                             

Meanwhile:

>    Pardon my ingorance, but how is the PM spawned?  Is "manage" the PM? 
>    Or is the PM a separate MM?

PM == Presentation module
the "manage" command invokes mcc_fcl_pm, the command line interface.
    
>    When I run manage, a "ps" does not show any other processes started as

Process are started:

1) When a pm is invoked by a user (eg "manage", "mcc_iconic_map")
2) When you enroll another module
3) When one module requires the services of another
   (for example, issue "show snmp nameofsomesystem" and watch the
    tcp/ip AM process start)

>    enroll command will enherit the env vars that were active at the time
>    the "manage enroll" command executed?  
    
That is what we would expect.

    Looks OK to be, your MM is restarting and should pick up the new value
    of the env variable.
    
    Arrrgggh  I just noticed  1.2.7??????????   I think there was a bug where
    we didn't pass the environment to an exec'd image.  Try v1.2 to see if
    the results are the same.
    
      

    
    Thanks, Jim.  I'll give that a shot.