[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

237.0. "BUGCHECK exception won't work without arg" by COOKIE::KITTELL (Richard - Architected Info Mgmt) Mon Aug 06 1990 19:47

The SRM, in the standards exceptions chapter, indicates that the bug check
exception can be returned with an argument indicating 

	1. an MCC error
	2. a VMS error
	3. a services error
	4. no argument, when the problem is an internal error of the called
           module.

Option #4 doesn't seem to work. If the exception is returned without an 
argument,the FCL_PM displays no exception at all and simply re-prompts.
T.RTitleUserPersonal
Name
DateLines
237.1not even the text came outGOSTE::CALLANDERMon Aug 06 1990 22:559
    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
    
237.2TOOK::STRUTTColin StruttTue Aug 07 1990 01:5626
    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
237.3Since you mentioned it...TOOK::PLOUFFEJerryTue Aug 07 1990 19:1244
    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  

237.4oooooooooops!COOKIE::KITTELLRichard - Architected Info MgmtWed Aug 08 1990 02:2020
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.