Never mind. I got my answer from
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/books/c0925074.pdf.
See below for a clip of the answer.
In general, when an exception occurs, the handlers associated with the
call stack
entry are given a chance to handle the exception. If the exception is
not handled by
any of the handlers on the list then it is considered to be unhandled,
at which
point the following default actions are taken for the unhandled
exception:
1. If the exception is a function check, the call stack entry is removed
from the
stack.
2. The exception is moved (percolated) to the previous call stack entry.
3. The exception handling process is restarted for this call stack
entry.
The action of allowing the previous call stack entry to handle an
exception is
referred to as percolation. Percolation continues until the exception is
handled, or
until the control boundary is reached. A control boundary is a call
stack entry for
which the immediately preceding call stack entry is in a different
activation group
or is an OPM program. In Figure 124 on page 241 Procedure P1 is the
control
boundary.
Exception Handling Overview
240 ILE RPG Programmer's Guide
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Lim Hock-Chai
Sent: Friday, August 03, 2007 11:42 AM
To: RPG programming on the AS400 / iSeries
Subject: Percolation of Exception Message
Does any one know if exception message's percolation process only
percolates message up to the activation group boundary or it always goes
up the call stack without considering activation group boundary?
Reason for asking:
I got a strange problem occurred to me this morning and it appears to be
cause by exception message only percolate up to the activation group
boundary. Below is what happened:
1) I recompiled/recreated a service program and during this
recompile/recreated I changed the active group of this exist service
program from *caller to be the name of the service program (Our shop
standard, not sure why).
2) A few application that uses one of the export procedure in this
service program started to fail after #1.
Those applications basically doing the callp(e) to the export procedure.
In the joblog, I notice that the service program is getting error out
when activation group is not *caller. If I change the activation group
to *caller, the service program seems to not error out due to callp(e).
thanks
--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing
list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.
midrange.com
