[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

2613.0. "Testing the Requester" by BONNET::DENIS (michel Denis) Mon Mar 23 1992 12:09

    Hello..
    
    This is a strange question and personaly I feel it is in opposition to
    good object-oriented practices, but .. as customer asks it, I'd like to
    be sure of the answer:
    
    One is developing an AM that is supporting a given directive (V,E,P).
    More than one FM will be able to call this entry point. The customer
    wants to be able to test within the AM who is the FM resquester, 
    and execute a different piece of code depending on the "FM" that calls
    the service.
    
    Is it possible ? Is it reasonable ?
    
    Thanks for the response,
    
    michel
T.RTitleUserPersonal
Name		DateLines
2613.1you can' ask who called me.GOSTE::J_CALLANDERMon Mar 23 1992 12:219
    currently there is no way of knowing who is doing the calling. The
    call interface does not provide a mechnism for saying, I called
    you, nor does it have a documented routine for asking the kernel
    who it was.
    
    Sorry, was there a reason they needed this? There are always
    alternatives to most ideas, maybe if you post the problem they are
    trying to solve we might be able to help with an alternative solution.
2613.2an additional argument as one of the possible solutionsTOOK::SHMUYLOVICHMon Mar 23 1992 17:268
    
    One of the possible solutions is to use an additional argument in this
    directive (assuming that the directive is an "action" directive).
    
    Depending on the value of this additional argument your AM can decide
    who the caller is.
    
    Sam
2613.3TOOK::STRUTTManagement - the one word oxymoronTue Mar 24 1992 17:0815
    THe design of MCC intermodule calling presumed that there was no need
    for a called module to understand who (ie. which module) requested the
    service, nor from which system the request originated.
    
    Assuming that you have a reason that the service requested should vary
    based on the identity of the requestor then:
    	1/ as Jill says in .1 - please let us know why - either we made
    	   a wrong assumption and perhaps we should consider fixing it or
    	   there might be another solution to the problem
    	2/ assuming you have a valid need, I would suggest that you have
    	   and additional request argument to the service that indicates
    	   which variant of the service is being requested (which is
    	   tantamount to indicating where the request came from)
    
    Colin
2613.4OK-- thanksBONNET::DENISmichel DenisWed Mar 25 1992 02:0011
    
    Thank you for your answers-- they should satisfy the customer.
    
    What he wanted to do is to write an AM that offers the traditional
    (SHOW, entity, partition) service, and, based on the caller, to go
    either to the Agent or to go and find the info in the MIR (supposing it
    was put there by another service..)
    
    Thanks again,
    michel