×
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.
But *PSSR is there to handle things that are unexpected. If an error is
possibly expected, definitely use MONITOR. I also don't see the problem
with *INZSR, why get rid of a subroutine, just because it s a subroutine?
I agree there are times when *INZSR should not be used but just to replace
it with a named procedure, just so you don't have a subroutine, I don't
see the point. procedures and subroutines both have their uses.
my opinion of course.
"Steve Richter" <stephenrichter@xxxxxxxxx>
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
03/31/2008 11:04 AM
Please respond to
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>
To
"RPG programming on the AS400 / iSeries" <rpg400-l@xxxxxxxxxxxx>
cc
Subject
Re: Classic Traps -- I need your input!
On Mon, Mar 31, 2008 at 11:53 AM, Francis Lapeyre <flapeyre@xxxxxxxxx>
wrote:
Nothing wrong with subroutines. If you have *INZSR or *PSSR, you can't
convert those to procedures.
good. get rid of them. replace *INZSR with a procedure that is passed a
control block type data struct or series of main procedure variables you
intend to pass from procedure to procedure.
*PSSR. I dont think I have ever coded one. Use MONITOR instead.
Also, any subroutines with a RETURN in them
will only exit the subprocedure when they are converted, and not return
to
the calling program, as was intended, meaning you'll have to rewrite the
logic.
or return a parm telling the caller to end the program.
-Steve
midrange.com
