[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

Title:	DECmcc user notes file. Does not replace IPMT.
Notice:	Use IPMT for problems. Newsletter location in note 6187
Moderator:	TAEC::BEROUD

Created:	Mon Aug 21 1989
Last Modified:	Wed Jun 04 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	6497
Total number of notes:	27359

2854.0. "problem enrolling on first dispatch" by MICROW::LANG () Sat Apr 25 1992 18:12

    
    Sometimes when the AM is not enrolled, and I use the "first dispatch"
    technique to enroll it, I get the following.  The dispatch fails, but
    then enrollment in same directory with same ultrix environment 
    variable works:
       (	MCC_MMEXE_LOCATION is the same)
    
    
    MCC> create tpcontroller x server  y  executable
    file=int_task_server_a,-
    _MCC>  descriptor file =add_group_1_0.idb , via path
    Enroll: Failed to execute MM image: : No such file or directory
    
    Waiting: MM mcc_tps_am has not completed startup
    Waiting: MM mcc_tps_am has not completed startup
    Waiting: MM mcc_tps_am has not completed startup
    Waiting: MM mcc_tps_am has not completed startup
    Waiting: MM mcc_tps_am has not completed startup
    Waiting: MM mcc_tps_am has not completed startup
    Will try again on next dispatch to MM:
    %MCC-E-TRANSMITERROR, error trying to transmit a packet
    MCC> exit
    
    MCC> enroll mcc_tps_am
     %MCC-I-ENRDUPLENTRY, etc...

T.R	Title	User	Personal Name	Date	Lines
2854.1	Developers beware	TOOK::MINTZ	Erik Mintz, DECmcc Development, dtn 226-5033	`Sat Apr 25 1992 20:14`	26
	This note is only useful to people developing MMs on ULTRIX. There is no such thing as "first dispatch" method of enrollment. If an enroll command fails, then the enrollment is completed on the next dispatch. But every time you want to use an new management module (or a new executable of the same management module) you must explicitely issue an enroll command. Also, as of T1.2.7, the path specification for a management module is no longer stored in the dispatch table. This means if you use MCC_MMEXE_LOCATION to point to a module outside of /usr/mcc/mmexe when you enroll, you must have MCC_MMEXE_LOCATION defined every time you try to use that module. It sounds to me as though you enrolled a module with MCC_MMEXE_LOCATION set to some directory, and then at a later time attempted to re-start it by dispatching (is that what you mean by "first dispatch"?). Since MCC_MMEXE_LOCATION was not set at the time, the dispatcher looked in /usr/mcc/mmexe, and didn't find the module. For the record, we realize that this change to dispatching makes it easier for developers to get their dispatch tables out of sink with their modules. However, it was necessary to support DMS. Since DMS is important to the customers, developers will have to live with a slight inconvenience.
2854.2	first dispatch	MICROW::LANG		`Tue Apr 28 1992 18:46`	27
	>It sounds to me as though you enrolled a module with MCC_MMEXE_LOCATION >set to some directory, and then at a later time attempted to re-start >it by dispatching (is that what you mean by "first dispatch"?). >Since MCC_MMEXE_LOCATION was not set at the time, the dispatcher looked >in /usr/mcc/mmexe, and didn't find the module. What I mean by "first dispatch" is... I did a ps aux \|grep mcc and there was no AM running. Then I executed a command, which returned an error from the AM. After getting out of MCC, I did the ps again, and the AM is there. So I never did an explicit 'enroll'. As for the exampel in 2854.0, I really thought the MCC MCC_MMEXE_LOCATION was set, bu(Because the commands were executed in the order of the note 2854.) I'll have to see if it happens again.. >For the record, we realize that this change to dispatching makes it >easier for developers to get their dispatch tables out of sink with >their modules. However, it was necessary to support DMS. >Since DMS is important to the customers, developers will have to >live with a slight inconvenience. Actually, I've always used MCC_MMEXE_LOCATION, so I don't think I'll notice the difference.
2854.3	Startup != Enroll	TOOK::MINTZ	Erik Mintz, DECmcc Development, dtn 226-5033	`Tue Apr 28 1992 19:41`	16
	This may be a repeat, but I want to be sure... When you try to dispatch to a module that has ALREADY been enrolled, then if the module is not running, the dispatcher will start the module. It does not automatically enroll. What this means is that if you change an executable (say by re-linking), and you start it up this way without re-enrolling explicitely, then you will be using old dispatch table entries with the new executables, resulting in completely unpredictable behavior. If you try to dispatch to a module that has never been enrolled, then you will get an error from the dispatcher. -- Erik