Conference azur::mcc

Both PMs (FCL and Iconic Map) see DISPLAY correctly; it is the handling of ECHO
which is handled differently.  In fact, the only time in the FCL where 
ECHO=false causes the field entered by the user NOT to be displayed is in
command completion (for required arguments).  A user could enter the following:

MCC>set <entity class> <entity instance> localhost superuser password=xyz 

and the entire command is echoed at the terminal.

For V1.1, in the Iconic Map, a field is not echoed if it is part of a reply 
and the argument in outp has ECHO=false.  All arguments which have ECHO=false
are echoed to the user as text is entered because there is no validation done 
(ie type the password a second time to make sure the two match).

Hope that helps.
Verna

    I disagree with your interpretation of ECHO (and apparently so does the
    SRM).
    
    It seems more intuitive to me for ECHO to be interpreted on input and
    DISPLAY to be interpreted on output.  Although, SRM states (by
    omission) that DISPLAY can be interpreted on input AND output.
    Nevertheless, it DOES state:
    
    ECHO  "The management module developer can have the argument value of
           a directive request echoed to the screen.  Not echoing the value
           to the screen is similar to entering your password on a VAX/VMS
           system in response to the '$ SET PASSWORD' command.
          "If set to TRUE, the value entered by a user is displayed on the
           screen.  If set to FALSE, the value entered by a user is not
           displayed to the screen."
    
    I think you misinterpreted the phrase "is similar to" as "is the same as".
    For example, when I log into a VMS system, the password is not echoed.
    But, I do not have to type it in twice to validate it, either.  Echo and
    and echo with validation are two different things.
    
    What concern me more is that their seems to a contradiction when ECHO is
    FALSE and DISPLAY is TRUE, according to the letter of the SRM.
    
    -Matt.

    Matt,
    
    you must note that in each of your examples you are actually entering
    into an application (like login or set password) and being prompted
    for a piece of information. You will note things like set password
    do NOT let you enter the passwords on the command line, but you
    must be prompt for them.
    
    We know that there are a number of things "unusual" about
    echo/display... but we are working on it. One more item taken into
    consideration when allowing a user to enter an item is the settable
    field. A while back Jim Lemmon drew up a complete cross reference
    chart (at least I believe it was he) that went through all possible
    combinations. Right now for the AM developers the hardest part is
    that the PMs internals are not overly well documented.
    
    	if an item is settable = you will see it in a form/command
	prompting	
    
    	if an item is displayable you will always see it on examines,
    	but if it not settable you won't see it on modifies
    
    	and as verna pointed out we only use echo on cmd prompting for
    	required arguments, in which case you will only be prompt it is
	is displayable, required, and no default supplied
    
A bit convoluted and more easily described in a conversation....
    

> A while back Jim Lemmon drew up a complete cross reference
> chart (at least I believe it was he) that went through all possible
> combinations.

  I think it would be useful to find and publish this table as a reply to this 
  note.  Jim?

> Right now for the AM developers the hardest part is that the PMs internals
> are not overly well documented.

  I AGREE!  There is a big gap in the (written) knowledge base concerning how
  PMs affect the construction of AMs (and FMs).

  A few examples:

    The FCL PM (and IMPM?) automatically process the WITH clause freeing the AM 
    developer from this responsibility.  I realize that this make LESS work for
    AM developers, but NOT knowing this might result in the AM actually coding
    up this functionality only to discover this fact later.

    The FCL PM automatically enumerates global entity wildcards.  This may be 
    fine for many AMs, but is not necessarily good for FMs who want to use
    the wildcarded specification in a different way.  FM developers have to find
    a way to design around this capability.
 
    The IMPM requires that all entites be REGISTERed in order that they be
    managed via the iconic map.  This means that AM must support the 
    REGISTRATION FM Service Requirements (e.g., the MSL and SHOW ALL IDENT 
    directive).

    The FCL abbreviation rules require that names of classes/attributes/etc.
    be unique to 3 (or 4) characters or else awkward conflicts will result.

    The IMPM always operates in a domain context, so an FM must provide other
    ways for users to indicate that the operations is to be done on the whole
    configuration (vs. just a part of it).

  Some of these may be just restrictions of our current PMs, but that doesn't
  make the job of our current MM developers any easier.  They must integrate
  their functionality with our CURRENT products (somehow).

  What I am saying is that we must increase our PM documentation somehow.  
  Chapter 7 of the SRM (MSL sections) may not be enough.  The MM programming
  guide may not be a good place, because if new PMs get developed, they may
  have their own requirements/restrictions.  We don't want to have to re-publish
  the Guide every time a new PM becomes available.  May I suggest that the MRM 
  chapters for the PMs would be a good place to start...  

                                                                      - Jerry

    So let me see if I have this correct:
    
    The order of precedence is:
    
     1) If it is settable, the user can set the value, and if it is
        non-settable, the user can never set the value.
    
     2) If ECHO=TRUE then you will echo the value when prompted for on
        the screen (i.e., display device), if ECHO=FALSE, you will NOT
        echo the value when prompted for on the the screen.
    
     3) If DISPLAY=FALSE you will never display the value (or the
        presentation name for the attribute, I assume), and if DISPLAY=TRUE
        then you will always display the value.  (Noting that #2 will
        supercede this rule on input, when ECHO=FALSE.)
    
    That sounds fine, but that is not what the Iconic Map does. 
    Apparently, if ECHO=FALSE and DISPLAY=TRUE, they still echo it.
    Also, they evaluate echo on output(!).  I'm just saying that I
    disagree with this latter behavior.
    
    -Matt.

  The table that Jill mentioned described the relation ship between
the REQUIRED and DEFAULT default definitions.   There isn't one for ECHO.

  The ECHO definition is supposed to work as described in the SRM.  It only
applies to user input (read REQUEST ARGUMENTS). The expected behavior for 
the PMs was defined to be:

  Iconic Map - User types in value and does not see what s/he is
		     typing.  There is no verification  by the PM.
		(we need to make the Iconic Map comply with the SRM)

  FCL - If the user types the command all in one line,
       (e.g., MCC> SET class-instance LOCALHOST SUPERUSER PASSWORD=XXX)
	the user will see what was typed on the screen.


	For command completion, (e.g., 
		MCC> SET class-instance LOCALHOST SUPERUSER <CR>
		PASSWORD =    )

	the user will not see what is typed on the screen.  There is no
	verification. (The FCL also needs to comply with the SRM.
   
  Now the question seems to be "should we verify what the user types in
if it can't be seen?"  At the time the SRM was written it was decided not to.
We should probably add a verification mechanism in the future.  Is it a high
priority?  probably not.

/Jim

The ECHO definition only applies if DISPLAY = TRUE.  If DISPLAY=FALSE,
the directives, attributes and or arguments (both input and output) are
not visible to the user.

The DISPLAY allows the MM writer to have directives, attributes, and arguments 
that can only be issued by a MCC_CALL_xxx(), not by the user.

/Jim 

 
>    The IMPM requires that all entites be REGISTERed in order that they be
>    managed via the iconic map.  This means that AM must support the 
>    REGISTRATION FM Service Requirements (e.g., the MSL and SHOW ALL IDENT 
>    directive).

  The Iconic Map requires that only global entities be REGISTERed.
It doesn't issue the REGISTER directive for child entities if they do not
have the directive.   This requirement is because you can't add an entity
to a domain if it is not registered.  

As I understand it, all global entities must support the register directive, 
hence the Iconic Map/Domain FM doesn't make additional work for the mm writers.

/Jim

re: .6 and .7 

Great, that's pretty much what I'd thought it was supposed to do. :-)  Also 
clarifies what the DISPLAY value could be used for on input (thanks - I'd missed
that part!) 

Should I (or someone?) enter a QAR against IMPM and/or FCL on this?  

		Helen

 I qared it for the Iconic Map and sent mail to Jill
Callander (FCL project lead).

/Jim