[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

560.0. "mcc_entity dispatch table instance parameter" by TENERE::MCDONALD () Mon Dec 17 1990 07:16

    On page 177 of the SRM v1.1 section 7.7 , for mcc_entity
    -specify a dispatch entry entity, it says that for the instance
    parameter an instance can be a text string of zero or more characters,
    ... or *.  However when I try to use a text string as the instance
    parameter, I get an access violation during enrollment of my AM.
    I tried the text string with and without quotes. Am I doing something
    wrong , or is this really supported? Can someone give an example of how
    it would work? (My AM works fine when I use the * for this parameter).
    Thanks,
    Carol 
T.RTitleUserPersonal
Name
DateLines
560.1needs investigationGOSTE::CALLANDERMon Dec 17 1990 18:154
    could you give us the exact syntax that you used?
    
    thanks
    
560.2Seems to work okay for usTOOK::GUERTINE = mccMon Dec 17 1990 19:0918
    We have tested dispatching on strings and it seems to work okay for us.
    
	MCC_DISPATCH_ENTRY - 
	SHOW,-
	<MCC_ENTITY <MCC><myclasscodegoeshere,THESTRING>>,-
	CHAR,-
	myshowroutineforthestring
    
    It would be helpful to know what exactly does not work so we can try
    to duplicate the behavior (and add it to our regression tests).
    
    Note that having strings as instances to dispatch on is not useful, so
    no one talks about it much.  You cannot really dispatch very easily on
    just an ASCII string.  Maybe you have a Latin1String for an instance
    datatype?  In any case, it is supported (until someone asks us to get
    rid of it).
    
    -Matt.
560.3Ex of what I triedTENERE::MCDONALDTue Dec 18 1990 07:2212
    Here is what I tried:
    
            mcc_dispatch_entry -
                    CREATE,-
                    <mcc_entity  <CMEAGT, *>,<CMEAGT_TESTOBJ,CAROL>>,-
                    NULL,-
                    mcc_TESTOBJ__create_TESTOBJ
     
    Yes the instance datatype is Latin1String.
    I realize this is not usually so important, but I wanted to try
    something where one instance of a class is dispatched to one
    AM the other instances are dispatched to another AM (remote). 
560.4Still confusedTENERE::MCDONALDThu Dec 20 1990 13:4520
    I still do not understand why this does not work for me, does the
    instance need to be a certain datatype? I tried it with the YOURMM
    example:
    
              mcc_dispatch_entry -
                    SHOW,-
                    <mcc_entity <YOURMM,TESTSTRING>>,-
                    CHAR,-
                    mcc_yourmm__show_char
       
    I got the result:
     
    MCC> ENROLL MCC_YOURMM
    %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual
    address=00000019, PC
    =00012119, PSL=03C00000
    %SYSTEM-E-ACCVIO, access violation, reason mask=00, virtual
    address=0000000A, PC
    =0000000A, PSL=0000000F
    
560.5hum...GOSTE::CALLANDERThu Dec 20 1990 14:265
    I gave it a quick try, my didn't access violate but I couldn't
    get the dispatcher to do the checking either.
    
    Matt, I think some one should probably check into this a bit.
    
560.6TOOK::SWISTJim Swist LKG2-2/T2 DTN 226-7102Thu Dec 20 1990 17:1515
    Compile time dispatch by instance is broken since there is no way to
    tell the macro what the datatype of the instance is - nor is there
    any way to specify identifiers other than strings.  It may be that
    certain combinations work but don't bet on it.
    
    There has been no incentive to fix this since compiletime specification
    of per-instance dispatch is pretty useless. However, when we go
    distributed, *run time* specification of per-instance dispatch (e.g
    I want instance X of the bridge AM to service bridge Y) will be an
    absolute necessity.   We were going to clean up the compiletime case
    when we implemented the runtime case.
    
    This should probably be QARed against the SRM.