Re: Condition handlers

["Barbara Morris/Toronto/IBM" <bmorris@xxxxxxxxxx>]

>Date: Mon, 18 Sep 2000 20:54:35 -0400
>From: "M. Lazarus" <mlazarus@ttec.com>
>
>1)  After a CH fires, can it fix up the data in the field in order to
>allow the program to continue properly?  If yes how?  I assume it can be
done
>via pointers.
>
>2)  How would you identify in the CH which field contains the error?  This
>is an issue, since the record contains many numeric fields that can
>potentially have an error.  Also, the idea is to avoid putting all the
>extra error checking in the mainline program after each calc.
>
>   I'm aware of the performance implications of allowing a CH for this,
but
>if the data is 99.9% clean, then I *think* it will be more costly for all
>the testing required for each field.
>
>3)  Once control is returned to the program, does the CH need to be
>registered again?  Or is it still active in order to trap the next error?

Mark,

The easy question first: the condition handler is "activation scoped".
It remains active until the procedure that enabled it returns (or CEEUTX
is called to disable it).

While it might be possible to use condition handlers the way you want,
the amount of coding required would be huge.  There's no way to identify
which field has the problem, but worse, sometimes the fields having the
problem are I/O buffers or other compiler internal fields.  If your handler
"handles" the error and continues execution, it will be at the next MI
instruction, not the next RPG instruction.  If the next instruction is
a store instruction, you will get invalid data written to the target field.

The condition handler is passed a "communication area".  This can be
anything
you want, but you decide what it is when you enable the handler.  Say you
know that an EVAL tgt = src will cause overflow.  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.

You CAN set up your handler to inform you that an error occurred.  After
every suspect operation, you can check whether an error occurred, and
set the EVAL target to say zero.  But I don't think it's worth it.  The
code to control the handler becomes much worse than the code to check
whether the field will overflow.

Another method is to write subprocedures to handle the suspect
calculations.
The subprocedure can just return your default value from its *PSSR.

C       eval   total = calcTotal (pay : overtime)

P calcTotal    B

D calcTotal    PI               9p 3
D   pay                         9p 3
D   overtime                    5p 3

C          return   pay + overtime

C  *pssr   begsr
C          if       %status = overflow
C          return   *hival
C          endif

 * Procedure crashes if it's not an overflow error
C          endsr

P              E

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
+---