RE: Multi- Occurrence Data Structure

Hi guys,

This thread seems to keep on going, and I've now been drawn in again. :-)

Joe, Tom, James,

Your points are all valid. But the thing that gets me about the cycle is
that it is "always there" running behind the scenes even when you don't
think you are using it. It "does things" and "works in mysterious ways", I
have to be aware of it - always. This is where the obfuscation comes from,
IMHO.

OK, I have a subprocedure in a RPG program, and this was called from the
main procedure in the same module. The subprocedure has a runtime error
(substring out of range error) and the error is caught by the *PSSR
subroutine in the subprocedure. I can't set a return point in factor 2 of
the ENDSR because the subprocedure is not part of the cycle (at this point).
I can handle the error and return but I can't ignore it and continue unless
I code a GOTO in the *PSSR subroutine! Yes you read right, I can only return
to processing within the subprocedure by using a GOTO within the *PSSR
subroutine! This is because subprocedures don't have a default exception
handler, which main procedures do have.

If I have no *PSSR and no other error trapping in my subprocedure, but I do
have a *PSSR in my main procedure then this subroutine will get called after
the error has percolated (error on call to subprocedure, RNX9001) and the
subprocedure has ended abnormally. If I leave the main procedure *PSSR
subroutine I can now set a return point in factor 2 of the ENDSR (because
now we ARE in the cycle). What would happen if I set the return point to
'*TOTC' here? Does this help me handle my error in the subprocedure any
better than if I set the return point to '*GETIN', '*TOTL' or '*DETC'? What
advantage do I get when parsing my xml by going to total calculations from
my main procedure when I have an error in a subprocedure?

In this scenario using the error handling mechanism provided by the cycle is
of no use to me and only adds confusion because the *PSSR subroutine acts
differently when used in "cycle code" and "non cycle code". Both are called
by the system in the same way but they behave differently if they are within
a subprocedure or a main procedure, and we have to code accordingly. For me
it is an uneccesary complication of my code. I should be able to just trap
my errors and process accordingly. That is why I use direct monitors and
condition handlers now. Such things as INFSR and *PSSR do not belong in my
code.

I'm happy to concede that it is just me. I'm also happy to concede that this
is all part of RPG and I have to live with it, and I do every day - happily.
As I said, RPG is very expansive and we all have our own little ecosystems
within it. :-)

I'm off to bed. I have to teach editable subfiles tomorrow.

Larry Ducie