RE: Ending a program from within a procedure

Thanks everyone for the responses.
I was hoping I was completely missing something obvious, but
unfortunately that's not the case.

I personally believe that a subprocedure that does not control the flow
of the program should be able to end the program normally upon
encountering an error (hence my question in the first place, right?)  

Ok, *InLR is a bad choice for an error indicator.  Then again,
procedureCall() is a bad procedure name.  Semantics.

Because I'm curious though, how would you prototype a procedure that is
returning a variable (and now you want to include an error indicator
along with it)?  Make the return variable a data structure, or pass the
error indicator as a parameter, or something else?

Kurt Anderson
Application Developer
Highsmith Inc

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Monday, July 25, 2005 11:22 AM
To: RPG programming on the AS400 / iSeries
Subject: Re: Ending a program from within a procedure


> I have a situation where I Monitor for an error.  When the error 
> occurs, I want to send a message and then terminate the program.
> But... how do I terminate the program from within a sub-procedure?

You can't end a program (normally) from a subprocedure. You can end it
abnormally by issuing an escape message when an error occurs, though.

Personally, I've found that it's better not to try to end the program
from a subprocedure.  A subprocedure should have one job -- it should do
one thing, and return the results to the caller.  If it ends the
program, then it's doing two things, both it's original purpose, AND
controlling the flow of the program.

I've found that it works better when the main procedure's only job is to
control the flow of the program, and the subprocedure's jobs are to
carry out steps that the program takes, and then return the results to
the main procedure.

> *InLR = *On;
> Return;
> from the main procedure.  But doing that in a subprocedure simply 
> returns control to the caller.

You think this is futile from the perspective of a subprocedure?  Try it
in a separate module or service program.  In that case, you won't even
set on *INLR, since there's a separate one in each module.

Instead, your subprocedure should return an error saying it can't do
whatever it was intending to do.  It should not be in charge of ending
the program.

> Do I need to code an exit path in?
> ie.
> procedureCall( parm );
> If not *InLR;
>  continue normal code.
> EndIf;

Yes, but using a global variable (in this case, *INLR) to indicate that
the program should end is just stupid.  Return an error value of some
sort. Either make the return value from procedureCall() indicate success
or failure, or have a parameter that indicates it.

I like to use an indicator as a return value, and have constants that
indicate success or failure. For example:

      D SUCCESS         c                   '1'
      D FAIL            c                   '0'

      D procedureCall   PR             1N
      D    parm                       10A   const

       /free
               *inlr = *on;

               .
               .

               if ProcedureCall(parm) = FAIL;
                  return;
               endif;

               .
               .

               return;

       /end-free

Note that I also set on *INLR at the very start of my program. You
aren't using the cycle, are you?  If not, then why bother ever having
*INLR turned off?  By setting it on at the top of my calcs, I can end
the program with one line of code -- just the RETURN statement.


> I'd hate to have to do this after every procedure call that has a 
> Monitor in it.

It's really not that big of a deal... The routines are much more
reusable when you let the caller decide the flow, rather than the
subprocedure. The extra line or two of code isn't a big deal.

But, like I said, if you're really want to end the program from a
subprocedure, send an escape message -- or, since you're monitoring for
one already, re-send that one.

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