[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

5391.0. "Global Classes depending on agent versions..." by AEOENG::BOMMART (WaveWalker 887-4108) Mon Jul 26 1993 13:05

Another note for a completly different question (although it is for the same
customer...)

Imagine you have to manage a global class FOO which has an attribute "version".

The sub-classes and attributes defined under this class depend on the VALUE
of the "version" attribute: this means that we could have to do:

	- first a "SHOW FOO foo-instance version" to know the exact version of
	  the agent of the network element 

	- and afterwards, depending on the value returned we could know the
	  exact structure (sub-classes, attributes) supported by the agent of
	  this entity.

Which is the best approach to manage these kinds of entities with DEcmcc ?

Have I to create a separate global class for each possible version of the
agent software running in the entity. In this case I could have the three
classes FOO_V1, FOO_V2, FOO_V3 predefined in my dictionary but in this case
the operator which is in charge to register the global entity HAS to know
which version of the software agent is running in the entity FOO...

Have I to create a generic class DUMMY_FOO just to retrieve the version number
(no need for this class to contain sub-classes... its only use is to provide
us with the entity agent version...) and afterwards use FOO_V1, FOO_V2, FOO_V3.

Has somebody a more clever idea to get as much as possible transparent the
management of these entities... Is there a mean with MCC to hide this
complexity to a final user (Iconic Map user) ?

I thank you (once again...) in advance,
best regards,
Damien.

T.R Title User Personal
Name Date Lines

5391.1 An idea... TAEC::LAVILLAT Wed Aug 04 1993 05:37 26

T.R	Title	User	Personal Name	Date	Lines
5391.1	An idea...	TAEC::LAVILLAT		`Wed Aug 04 1993 05:37`	26
	Damien, Just a quick idea : why not doing like the TeMIP Event Log FM that uses a generic dummy class LOG_RECORD instanciated into different specific subclasses ? You could have a mechanism, that take in input your class FOO and return in output the correct class by changing the out_entity AES class i.e. show foo bar would return foo_v1 bar In this case you could define for class foo the common attributes and directive, directive arguments, and define in addition for each specific class specific attributes, directives, directives arguements,... You may need to check what result is obtained when doing "register foo bar" that return "foo_v1 bar" during the show all ids... I do not know if this does not violate the EMA principles, nor if it fits your requirements, but it may "faire avancer le shmilblik"... Regards. Pierre.

Damien,

  Just a quick idea : why not doing like the TeMIP Event Log FM that uses
  a generic dummy class LOG_RECORD instanciated into different specific
  subclasses ?

  You could have a mechanism, that take in input your class FOO and return
  in output the correct class by changing the out_entity AES class i.e.
  show foo bar would return foo_v1 bar

  In this case you could define for class foo the common attributes and
  directive, directive arguments, and define in addition for each specific 
  class specific attributes, directives, directives arguements,...

  You may need to check what result is obtained when doing "register foo bar"
  that return "foo_v1 bar" during the show all ids...

  I do not know if this does not violate the EMA principles, nor if it fits
  your requirements, but it may "faire avancer le shmilblik"...

  Regards.

  Pierre.