Now it's coming together. I recall hearing about these handlers quite a long time ago, I guess at the time I never saw a need since we were already monitoring and passing errors up the procedure chain in our new development. I'm going to have quick read up on these handlers and see how we can make use of them here.
Thanks, Chuck.
Kurt Anderson
Sr. Programmer/Analyst - Application Development, Service Delivery Platform
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Saturday, April 26, 2014 6:08 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: RPG Main + Debugging a hard error
On 25-Apr-2014 17:15 -0500, Kurt Anderson wrote:
We're at 7.1. We recently started using the RPG control option of MAIN
to point the program to a procedure to process instead of using the
cycle and mainline code.
Today we had such a program, being called by a CL, get a hard error in
the main procedure. When we go in to debug it, it takes us to the CL
as being the current line, which means if we go into the actual
program to see the variables they're all out of scope. Is there a way
to get the error to halt the program in the procedure so we can debug
the active/MSGW job?
The RPG program\procedure is no longer on the stack, for the lack of one of an [RPG specific or ILE] exception handler, an ILE condition handler, or an ILE cancel handler, having been coded. The job will not go into Message Wait (MSGW) status due to the RPG Default Handler inquiry, because the RPG compiler would not have generated such a handler to be invoked at run-time in response to an error. The onus is on the programmer to code whatever they want done in the event of an error or any other [unexpected] condition that needs to be handled.
That error handling could be code that is designed to act effectively identically to the RPG default handler to send an inquiry and await a reply message; although there is effectively no support for the ability to effect [easily the] retry of the failing statement.
<
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/rzasc/sc092507328.htm#hexsub>
IBM i 7.1 Information Center -> Programming -> Programming languages -> RPG -> ILE RPG Programmer's Guide -> Debugging and Exception Handling -> Handling Exceptions -> Exception Handling Overview -> ILE RPG Exception Handling _Exception Handling within Subprocedures_ "Exception handling within a subprocedure, including one designated as a linear-main procedure, differs from exception handling within a cycle-main procedure in the following ways:
* If you are using a global file, then because you cannot code an INFSR subroutine for that file, you should handle file errors using error indicators, the 'E' operation code extender, or a MONITOR group.
* There is no default handler; in other words, users will never see an inquiry message.
Exception handling within a subprocedure differs from a cycle-main procedure primarily because there is no RPG cycle code generated for subprocedures. As a result there is no default exception handler for subprocedures and so situations where the default handler would be called for a cycle-main procedure correspond to abnormal end of the subprocedure. ..."
That and the other topics under the following section of the ILE RPG Programmer's Gd should be helpful:
<
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/rzasc/sc092507324.htm#hexcp>
--
Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
