Re: Condition handlers

>Date: Tue, 19 Sep 2000 23:25:24 -0400
>From: "M. Lazarus" <mlazarus@ttec.com>

>>It remains active until the procedure that enabled it returns (or CEEUTX
>>is called to disable it).
>
>  Can you be more specific?  What if it returns w/ LR *Off and is
>subsequently called.  Is it still active?

No, it gets deactivated with the return.  You have to re-enable it on
every call.

>>While it might be possible to use condition handlers the way you want,
>> ...

>  Then what is the "proper" use of a condition handler?

I personally don't think there IS a proper use for a
condition handler that "handles" the exception.  However, a
condition handler can be used very well to do error reporting and
then percolate the error.  It can also be used to transform an
error into your own error message (this is called "promoting"
an exception).

>> ...Even if you pass your
>>handler the addresses of tgt and src, your handler is powerless.  If it
>>tries to set src to zero, it will be too late, because the "too large"
>>value has already been "loaded" and tgt will still get "something"
assigned to
>>it. If it tries to set tgt to zero, it will be too soon.

>  Why would it be "too soon"?  Since the instruction executed and I
replace
>it w/ a new value and it continues @ the next instruction, why wouldn't
>this work?

It's the next machine instruction that gets executed next.  The error
may happen on the calculation of the result, but before the answer
is stored to the left-hand-side of the EVAL.  After your handler returns,
the next MI instruction may be to store [who knows what] to your variable.

Say you determine that nothing bad seems to happen when you handle a
particular exception, so you decide to go ahead and use the condition
handler.  The trouble is that the behaviour can't be guaranteed to
stay the same.  The "next MI instruction" may change as either the
compiler or the translator change how they handle your code.  This
change may happen across releases or even across PTFs.  Even across
compiles depending on the optimization level.

>>Another method is to write subprocedures to handle the suspect
calculations.
>>The subprocedure can just return your default value from its *PSSR.
>>...
>  Since this can just as easily be done inline (and there are no numeric
>operational descriptors), and there are quite a few numerical fields
>involved, I don't see much of an advantage to separating this routine into
>a procedure.

The expression can't be done inline because it might overflow and then go
to your "main" *PSSR.  But I agree that it would probably be better to code
the checks in the main code (or change the calculations so they don't
overflow).

Barbara Morris


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---