[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

139.0. "Class wildcarding for MCC$CALL" by TENERE::LAVILLAT () Wed May 30 1990 13:27

I'm trying to perform MCC$CALL using class wildcarding. 

I read in SRM (Chapter 5, Class Wildcarding) :
	"A wildcard can also be specified in place of the entity class."

So I tried the following :

MCC> show member toto * all char

And got:

%MCC-W-ATTRSYNTAX, Syntax error in attribute *
MCC>

I have in my dispatch table :

	mcc$dispatch_entry - 
		SHOW,-
		<MCC$ENTITY <MEMBER,* >,<*,*>>,-  
 		CHAR,-
		ENOP_SHOW

So, is it a problem of dispatch table, syntax , or something else ?

					Pierre.

T.R Title User Personal
Name Date Lines

139.1 PM doesn't support this GOSTE::CALLANDER Wed May 30 1990 15:50 21

T.R	Title	User	Personal Name	Date	Lines
139.1	PM doesn't support this	GOSTE::CALLANDER		`Wed May 30 1990 15:50`	21
	No it is a limitation of the PM. The TRM does NOT support class wildcarding. There are still open issues regarding how it should be supported by a PM. Some ideas we have talked about are: o go to the dictionary to determine all possible classes, and make one call per class o pass the wildcard down and leave it to some one to enroll the wildcard in the dispatch table, it is then up to the receiving module to enumerate all classes An item to remember is that the SRM doesn't same that only ONE module can work an entity. Therefore you might have one module whichs supports the global entity, while having other modules for the each of the child entities. An example of this might we the Domain FM and then potential other FMs for supporting child entities under domain (like an Alarm subentity for all alarm rules that apply to a specific domain).

    
    No it is a limitation of the PM. The TRM does NOT support class
    wildcarding. There are still open issues regarding how it should
    be supported by a PM. Some ideas we have talked about are:
    
    	o  go to the dictionary to determine all possible classes,
           and make one call per class
    
    	o  pass the wildcard down and leave it to some one to enroll
           the wildcard in the dispatch table, it is then up to the
           receiving module to enumerate all classes
    
    An item to remember is that the SRM doesn't same that only ONE module
    can work an entity. Therefore you might have one module whichs supports
    the global entity, while having other modules for the each of the
    child entities. An example of this might we the Domain FM and then
    potential other FMs for supporting child entities under domain (like
    an Alarm subentity for all alarm rules that apply to a specific
    domain).