[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

5353.0. "MCC_CALL_ACCESS & MCC_CALL_FUNCTION" by AEOENG::BOMMART (WaveWalker 887-4108) Mon Jul 19 1993 12:36

Hello from France.

Can somebody from MCC validate this proposal ?

An existing AM provides access to a specific class of objects (let say CLASS
FOO)

We have no access to the sources of this AM. Therefore we can't change its
behavior. A "SHOW FOO foo-instance" is directly handled by this AM via the
DECmcc dispatch table.

Now we would like to implement a FM which provides the following service:

- intercept the "SHOW FOO foo-instance"
- looks in the FM own  database to see if the values are already stored in this 
  database.
- if the value is in the database, return directly the value to the caller.
- if the value is not in the database, call the AM (with a mcc_call_access 
  function), store the value in the database and return the value to the caller.

Is it still possible for another FM to:
	- either choose to go directly to the AM (by issuing a mcc_call_access)
	- or choose to use the services of my new FM (by issuing a
          mcc_call_function)

Is there restrictions for the vector.mar file which prevent this kind of 
design ?

Will a "SHOW FOO foo-instance" issued by a standard PM (Iconic Map or FCL)
be sent to my new FM or to the old AM ?

Is there a constraint about the way to enroll the AM and the new FM (have I
to enroll first the AM and afterwards the FM) ?

I thank you in advance,
Regards,
Damien.
T.RTitleUserPersonal
Name
DateLines
5353.1just enroll the FM into the function dispatch tableKAJUN::NELSONMon Jul 19 1993 15:0258
Hello from France.

Can somebody from MCC validate this proposal ?

An existing AM provides access to a specific class of objects (let say CLASS
FOO)

We have no access to the sources of this AM. Therefore we can't change its
behavior. A "SHOW FOO foo-instance" is directly handled by this AM via the
DECmcc dispatch table.

Now we would like to implement a FM which provides the following service:

- intercept the "SHOW FOO foo-instance"
- looks in the FM own  database to see if the values are already stored in this 
  database.
- if the value is in the database, return directly the value to the caller.
- if the value is not in the database, call the AM (with a mcc_call_access 
  function), store the value in the database and return the value to the caller.

kjn>> OK, its quite possible

Is it still possible for another FM to:
	- either choose to go directly to the AM (by issuing a mcc_call_access)
	- or choose to use the services of my new FM (by issuing a
          mcc_call_function)

kjn>> yup!!

Is there restrictions for the vector.mar file which prevent this kind of 
design ?

kjn>>  No, as a matter of fact, the dispatch tables are set up so that 
kjn>>  exactly this behaviour is possible.

kjn>>  Enroll your FM in the FM dispatch table (see example in 
kjn>>  MCC_EXAMPLE_FM).  The mcc_call_function called the the PM searches 
kjn>>  the function dispatch table first.  Thus the FM intercepts the 
kjn>>  SHOW FOO foo-instance call

kjn>>  Since the AM is enrolled into the access function table, any FM 
kjn>>  can choose to call mcc_call_function and get the FM or use
kjn>>  mcc_call_access to get the AM

Will a "SHOW FOO foo-instance" issued by a standard PM (Iconic Map or FCL)
be sent to my new FM or to the old AM ?

kjn>> new FM

Is there a constraint about the way to enroll the AM and the new FM (have I
to enroll first the AM and afterwards the FM) ?

kjn>> Enrollment order doesn't matter, only which table you enroll into.

I thank you in advance,
Regards,
Damien.

5353.2a restriction...TAEC::LAVILLATTue Jul 20 1993 04:4714
Damien,

Just a little restriction you should be aware of :

You cannot use this for V,E,A tuples that are already executed at FUNCTION
level : for example REGISTER, and EXPORTER or HISTORIAN verbs.

Apart from that it should work fine and demonstrate a powerful feature of 
MCC !

Regards.

Pierre.
5353.3Salut Pierre. Merci pour le conseil (un de plus... :-) Ciao. DamienAEOENG::BOMMARTWaveWalker 887-4108Wed Jul 21 1993 04:170