Re: dynamic program CALLS

[John Carr <74711.77@xxxxxxxxxxxxxx>]

RE:     Re: dynamic program CALLS

>>RETURN (RETRN) is required for an RPG to end when *INLR is not turned on.
>>Turning *INLR *ON is sufficient to end a program RETRN is not needed
>>here.
>

>uh oh...  Is this the way it is?  I'd thought that RETURN did exactly, and
>only, what it says; it returned. The job isn't ended, files aren't closed,
>nothing like e-o-j processing happens. The only way that the job can now
>be closed is by calling the program again and turning on LR in it.   If
>you don't do it in your program then the call stack will when a program
>higher in the stack receives an LR instruction.


I must, as usual, ask 'what are your shop standards?'   Do you have a 
standard approach to 'kill' a sub-program that returns without setting
on *INLR?   It has been this way since 1983.  When you design a system
that will have programs that return without *INLR being set on, you must 
at the same time develop a means of shuting them down.   

One way is to keep a flag in the calling program saying 'Yes I have called
the lower program'.  So when you leave the higher program it should call
the lower program one more time instructing it to 'Shut Down'.  

Another way is to use the ILE Activation Groups and do a 'STOP' function.
(Jon, when are we going to get a native RPG opcode to do the equivalent
of a COBOL 'Stop Run' ? That is without having to use a stupid API.)

I would strongly suggest moving away from using the RCLRSC command.
Especially the RCLRSC *CALLER.  This shotgun will kill you when 
you do finally move into ILE Activation Groups.  It's primarily a 
'I don't know what's down there,  but this will kill it'  approach.
Kinda like fishing with dynamite.

You may be using 3rd party software that expects its sub-programs to be
intact (still active, ie *INLR *OFF), Well, You just blew them out of the 
water too, and they don't even know it. 

We should design our systems with these common application system design
functions thought up first. And have a 'Shop Standard' approach of how
to handle them.

Sorry, End of Soap box.

John Carr
EdgeTech

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@midrange.com".
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---