Conference azur::mcc

5338.0. "V1.3 framework known pbs or AM pbs ??" by TOSKI::HAYES (Keep trying ! C.Hayes ALF 385-2988) Wed Jul 14 1993 11:45

	Hi,

	Here are some complaints from a partner on DECmcc V1.3.0
	framework.
	I do not think this is related to TeMIP as just normal
	framework operations are reported. 

	Could someone in the framework team take some time
	to help define what problems come from their AM
	and what problems are known problems in DECmcc V1.3.0 ?

	It would help more than you can imagine.	

		Thanks in advance


			Catherine	


Summary of problems with FCLPM/IMPM using DECmcc V1.3.0 / TeMIP T1.1.0

  Following is a summary of the problems that we are having with the
Presentation Modules on DECmcc / TeMIP. In one of these cases, we
aren't really sure that it's a PM problem as opposed to something amok
with the AM. We would be happy to be told it's our problem, or at
least some things to look at.

Iconic Map PM:


1. Variant records are still not supported as directive arguments. The
command entry box appears in outline and then disappears; an error box
appears with the message:

  Software error: an internal error has occurred in the Iconic Map PM.

These used to at least appear to work. In the previous version of
DECmcc, the form accepted the record. It just made you enter all of
the fields.

Non-variant records are supported, however, as of V1.3.0, there is no
enforcement of any element of the record being entered. This behaviour
is dangerous!  Not only that, if forces the AM to have to do a bunch
of parameter checking and report a variety of status codes for
potentially missing values. IMHO, if a field is required, all of it
should be required. If that isn't sufficient functionality, then
optional fields within records should be supported.  Also, this sort
of thing could also be more properly supported using variant records.
Isn't the idea of the PM being violated by allowing incomplete records
to be entered?

2. Wildcarded SHOW directives are still not handled properly when the
returned attributes vary between instances (e.g. a variant class
definition using DEPENDS ON).  For example, when the returned
attributes vary in subsequent entities from those of the first entity
displayed, as in our varient Route class, error boxes appear with the
message:

  Extra information was returned for NEAX61MTS LOCAL_NS:.nnn Route *:
    attribute aaa

Where nnn is the parent instance, and aaa is Incoming Index or
Outgoing Index (in the case of the Route child entity). The Index
attribute is then displayed as --NOT RETURNED--.

3. As before, creating variant classes using DEPENDS ON for
characteristic attributes is ineffective. All attributes are required
by the PM regardless of instance type. This is really a pain.

4. Child entities are still displayed oddly on the domain map. At
first each non-dynamic child class (control, subsystem, common) gets
two boxes labelled "<class>..." and "<class>". (This changed slightly
from V1.2.3 to V1.3.0. Formerly, the "<class>..." box wasn't
displayed.)  The first time you click on the former box, the latter
box disappears, and on the next try displays boxes for the correct
number of entity instances, all labelled simply "<class>".  However,
all are simply aliases for a wilcarded specification of the child
class, as can be seen when executing a show.

The AM successfully returns entities for show all identifier. Nothing
appears to be incorrect in its behaviour. Any ideas on this? The child
entity display doesn't appear to exhibit this behaviour for other
classes (i.e., SNMP). I'm willing to accept that this is our problem,
but nothing seems to be wrong. Would an ILV dump of the response tell
if the problem was in the AM??

FCL PM:

1. As before, the PM does not recognise emumerated types when prompted
for a directive. It does recognise them (also as before), when they
are included on the initial command line.

2. Attempts to execute a directive with a variant record as an
argument result in the error message:

  %MCC-E-DATATYPE_NOT_SUPPORTED, data type is not supported

3. As before, creating Route entities using DEPENDS ON for
characteristic attributes is ineffective. All attributes are required
by the PM regardless of instance type. What is the use of DEPENDS ON
if the PMs ignore it?

I'm really ticked off about these features. They are in the
documentation and they are necessary. It is really frustrating to find
out that they don't work as advertised. The user interface for the AM
will look bad and be less usable without them. I need to know what's
happening with these features. (Again, I'm willing to be convinced
that the problem displaying child entities is our problem.)