Well, if you only want it to die, add a *PSSR with the code to do what you
want it do when it "dies". Then any un trapped err will get handled by the
*PSSR.
In a message dated 4/21/2009 6:13:10 P.M. Jerusalem Daylight Time,
amarino@xxxxxxxxxxxx writes:
I was aware of this 'percolation' business but the issue, for me, anyway,
is that I WANT the subprocedure to fail when it encounters an unexpected
error. In this case, it was an attempt to write a duplicate key (BTW, I can't
see any reason for it, the program chains with all 4 keys, then several
lines of code that do NOT alter any key field, then the write/update based on
'not-found/found'. And there are no logicals on the file in question.)
Even if I handled an error I have no reason to suspect will occur, there's
nothing good for me to do.
If the answer is that there's no way for me to get the proc to just die
where it is (so I can find out what happened), then so be it. But I had to
ask.
Arthur J. Marino
RockTenn Corporation
(631) 297-2276
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Charles Wilt
Sent: Tuesday, April 21, 2009 10:35 AM
To: RPG programming on the IBM i / System i
Subject: Re: The ILE Question I Forgot to Ask
Arthur,
With ILE, exceptions are percolated up the stack till a handler is
encountered.
I recommend a couple of resources:
ILE Concepts manual
Who knew you could do that with RPG IV?
http://www.redbooks.ibm.com/abstracts/redp4321.html?Open
RPG: Exceptions and Error handling Redpaper
http://www.redbooks.ibm.com/abstracts/redp4321.html?Open
From the redpaper above:
"An overview of percolation is provided in the previous IBM Redbooks
publication (section
4.2.7.1 Call stack and error handling and section 4.2.7.2 Error
handling in ILE) but here we
give a brief explanation from the point of view of handling
exception/errors in an application.
In an OPM environment, a program that is well down the call stack receives
an
exception/error. If the program does not have any exception/error
handling, the RPG default
handler will issue a function check message.
In an ILE environment, a subprocedure or a program that is well down
the call stack receives
an exception/error. If the subprocedure or program does not have any
exception/error
handling specified, the message is sent back up the call stack to the
calling procedure. If the
calling procedure does not have any exception/error handling defined,
the message is again
sent back up the call stack to the calling procedure and so on until
the AG control boundary is
reached.
It is important to note that messages are percolated to an AG control
boundary that may or
may not be the program that originally initiated the AG. Refer to the
section on Control
Boundaries Chapter 3 (ILE Advanced Concepts) of the in ILE Concepts manual.
If none of the subprocedures or programs in the call stack have
exception/error handling
defined, the message is re-signaled as an exception and control
returns to the subprocedure
or program that originally received the message and an attempt is made
to call the RPG
default handler. But subprocedures do not have a default RPG handler,
which means that the
call to the subprocedure causes an exception/error which, in turn, is
percolated up the call
stack. This process continues until a default handler can be called.
This means that a function
check may not be issued until an entry in the call stack is a mainline
program (which will have
a default error handler)."
HTH,
Charles Wilt
On Tue, Apr 21, 2009 at 9:34 AM, Arthur Marino <amarino@xxxxxxxxxxxx>
wrote:
Just got back from the RPG/DB2 Summit in Orlando. Scott, Jon, Susan,
Paul, et al were all great.
But I forgot to ask how I should handle unexpected errors in a
prototyped procedure. The proc attempted to write a duplicate key and
auto-cancelled. It returned to the caller and halted there, allowing me
to dump, but that was too late, of course.
Do I have to anticipate every possible error in the proc? Can't it be
made to halt at the point of failure so I can get a dump at a point
where it'll do me some good?
Thanks,
Arthur Marino
This message, including its attachments, constitutes an electronic
communication within the meaning of the Electronic Communications Privacy Act,
18 U.S.C. Section 2510. This message is the confidential property of
RockTenn, and disclosure is strictly limited to recipients intended by the
sender. Unless previously authorized in writing, this message does not
constitute an offer, acceptance, or agreement of any kind. This message may contain
confidential attorney-client privileged information and attorney work
product. If you are not the intended recipient, or responsible for delivering
e-mail to the intended recipient, you are advised that use, dissemination,
forwarding, printing, or copying of this message is STRICTLY PROHIBITED.
If you receive this message in error, please notify the sender immediately
by return e-mail and delete the message entirely from your system. Sender
is not liable for damage caused by viruses transmitted with this message,
or errors or omis!
si!
ons in content caused by transmission.
(c) RockTenn, Norcross, GA.
--
This is the RPG programming on the IBM i / System i (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.
--
This is the RPG programming on the IBM i / System i (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.
This message, including its attachments, constitutes an electronic
communication within the meaning of the Electronic Communications Privacy Act, 18
U.S.C. Section 2510. This message is the confidential property of
RockTenn, and disclosure is strictly limited to recipients intended by the sender.
Unless previously authorized in writing, this message does not constitute
an offer, acceptance, or agreement of any kind. This message may contain
confidential attorney-client privileged information and attorney work
product. If you are not the intended recipient, or responsible for delivering
e-mail to the intended recipient, you are advised that use, dissemination,
forwarding, printing, or copying of this message is STRICTLY PROHIBITED. If
you receive this message in error, please notify the sender immediately by
return e-mail and delete the message entirely from your system. Sender is
not liable for damage caused by viruses transmitted with this message, or
errors or omissi!
ons in content caused by transmission.
(c) RockTenn, Norcross, GA.
midrange.com
