Re: Condition handlers

Barbara,

At 9/19/00 12:20 PM -0400, you wrote:
>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).

  Can you be more specific?  What if it returns w/ LR *Off and is 
subsequently called.  Is it still active?

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

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

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

  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?

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

  Is this a case of condition handlers being a "good effort, but didn't 
make it good enough for practical implementation"?

>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

  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.

  -mark

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