Conference azur::mcc

    you don't even get the text message, something like software error
    detected? Could you do me a favor and do the following:
    
    $ define mcc_fcl_pm_log 28
    $ manage/enter
    MCC> <enter your command>
    
    and either send me the dump or post it here. thanks
    

    Also, please note that there is confusion in the usage of MCC Reply.
    It was intended to be used to report a bug - ie. one MM, in performing
    the service requested by another, found an error that it could not
    handle. MCC Reply can, therefore, be used to pass back an encapsulated
    error report, which MUST be passed back up through all MMs until it
    reaches the user - where the user should be exhorted to submit an
    SPR, cos, after all, it's a bug.
    
    Recently, we've been asked to add an additional capability - that of
    being able to return an error indication, not due to a bug but due to
    a condition that the MM programmer did not (bother to) translate into
    an exception. Probably this is in order to pass up an unusual error,
    such as a wierd return from a system routine, or MCC routine or an
    mcc_call that is not likely to happen very often.
    
    This new capability is known as MCC Message - there is proposed to be
    a new datatype and a new ILV PUT routine to match.  There is an eco
    in the process of being reviewed right now that would add this to the
    SRM.
    
    Maybe you are looking for MCC Message, rather than MCC Reply?
    
    I know this has absolutely nothing to do with your question, but it
    seemed at least partially relevant.
    
    Colin

    RE: <<< Note 237.2 by TOOK::STRUTT "Colin Strutt" >>>

    While we're on this topic...

>    Recently, we've been asked to add an additional capability - that of
>    being able to return an error indication, not due to a bug but due to
>    a condition that the MM programmer did not (bother to) translate into
>    an exception. Probably this is in order to pass up an unusual error,
>    such as a wierd return from a system routine, or MCC routine or an
>    mcc_call that is not likely to happen very often.

    Clarification:  MM developers do (indeed, they *must*) "translate" the 
    error condition into some exception, else, how else does it get returned.
    MMs are not allowed to pass up CVRs or exceptions directly!  The real 
    problem is that some MMs (Alarms included) "translate" the error into 
    generic exceptions such as "Database error" and pass back the MIR
    routine CVR as an argument to this exception.  MMs also encapsulate 
    exceptions that they receive under their own exceptions.  For example, 
    Alarms does this to capture exception returned by MMs when it is gathering
    the data needed to evaluate an alarm exception.

    Both of these methods are allowed by the MCC SRM!  Colin, I think that
    you are saying that the generic exceptions (like "Database error") are not
    very user friendly.  After all, sometimes it is not appropriate to expose
    low level errors to users.  I agree, these top level exception should be
    clearer to our users.  This does not imply that the low(er) level error
    messages should not be returned (by arguments of datatype: MCC_error,
    MCC_MSG, MCC_Reply, VMS_error, etc.).  This information is sometimes 
    crucial to fix the problem.  Comments?  
    
>    This new capability is known as MCC Message - there is proposed to be
>    a new datatype and a new ILV PUT routine to match.  There is an eco
>    in the process of being reviewed right now that would add this to the
>    SRM.

    I hope that the ECO includes an ILV GET for this datatype also?
    The Alarms FM as well as PMs require the ability to DECODE this datatype.
    We made the mistake of not supplying a GET for MCC_Reply.  This caused a
    couple of teams to write their own (you can't imagine the kinds of problems
    that this caused!).  Please do not allow the same mistake to re-occur with
    this new datatype!
  
                                                                      - Jerry  

Regarding the matter I reported in the base note, I seem to have a short
*between* my headphones. It was user error, the desframe reply index wasn't
getting set in the case I reported. When I turned on the FCL dump per
Jil's request I could see something was amiss.

With that repaired, I get "Software logic error detected" before the
re-prompt, as expected. Sorry.

Regarding some of the other replies, what I am doing with the argument-less
form of bugcheck is defensive programming, the line with the comment "should
never get here", such as the default case on a switch statement. If you're
considering an ECO what is really needed is the ability to pass a
Latin1String. Then it could say "Unexpected attr val in PBD SHOW" in
addition to "Software logic error detected". These never fire in production
code of course, but make QARs during field test more meaningful. ;-)

In lieu of passing a string through the bugcheck I pass it to the routine
that sets up the exception. The routine does a printf of the string if
the right bit in the logical name is set.