× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Sorry to flood you both with this but I thought this was a rather excellent response. ----- Original Message ----- From: "Scott Klement" <rpg400-l@xxxxxxxxxxxxxxxx>
To: "RPG programming on the AS400 / iSeries" <rpg400-l@xxxxxxxxxxxx>
Sent: Monday, July 25, 2005 12:21 PM
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.




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.