[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

1059.0. "Depend On for Create arguments (IMPM)" by LEVERS::LEVENSON () Tue May 28 1991 10:55

	The Depend On for the arguments of the Create directive for a child
	entity is currently meaningless, since the dependency is on the 
	characteristic attributes of the same entity, and the entity does not 
	exist yet, before the invokation of the Create.

	As a result, IMPM displays ALL the arguments of the Create directive,
	whether they do or do not have a DependOn clause. If the argument set
	is different, e.g., depends on the device hardware type, seeing
	all arguments together, instead of just the ones for a particular 
	device, may be quite confusing to the user. We see this problem
	in case of Bridge AM, where Create has the same args as Set.

	For now, the only way to avoid this problem seems to define a different
	child entity for a different device type, which is logically a wrong
	solution.

	It seems that a change is needed, so that in the arguments of the
	Create directive for a child entity the DependOn defines a dependency
	on a characteristic of the PARENT entity. This would avoid a vicious
	circle and would solve our IMPM display problem.

Herman

T.R	Title	User	Personal Name	Date	Lines
1059.1	Should this be fixed for v1.2?	POLE::LEMMON		`Mon Jul 15 1991 13:44`	11
	Yup. You found one area where variant entity support is weak on. Having the create directive arguments depend on the parent's attributes makes sense. This change (bug?), however, isn't scheduled for the v1.2 kit. How many people think that this MUST be fixed for v1.2. I need to see how important it is, otherwise it will not get fixed. It affects many components (MS Compiler, SRM, IMPM) and requires an ECO. Thanks /Jim
1059.2	Simple but potentially dangerous	BIKINI::KRAUSE	CSC Network Management/Hubs	`Fri May 20 1994 08:29`	16
	>It might be worth the time to query the DECmcc folks, to see if the >request for a DUA entity can be supressed when the director tickles >the DECnet/OSI system. If this can be pulled off, then you'd have >a short term workaround. This is simple, but be careful because it will erase DUA completely from the dictionary: $ manage/tool/dict DAP> delete class node subclass dua DAP> exit Remember to save your dictionary first, in case you need DUA later... The files to save are MCC_COMMON:MCC_FDICTIONARY.* *Robert
1059.3		WELTM1::CRIDDLE	Graham Criddle, MCS Tech Consultant, 853-4015	`Fri May 20 1994 09:49`	7
	Robert, Many thanks for the speedy reply. I shall experiment!! Rgds, Graham
1059.4	Not a great solution	SCCA::dave	Ahh, but fortunately, I have the key to escape reality.	`Fri May 20 1994 15:07`	4
	Note that if you have another system that correctly supports DUA, then you are hosed, as you must keep it there to access it on the other system.