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


  • Subject: Re: dynamic program CALLS
  • From: John Carr <74711.77@xxxxxxxxxxxxxx>
  • Date: Sat, 6 Dec 1997 22:35:01 -0500



Date:   12/6/97  8:17 PM

RE:     Re: dynamic program CALLS

>>on 12/06/97at 12:07 PM, the Great and Grand  Wazir John Carr
>><74711.77@compuserve.com> said:
>The RETURN CL command just ends the program and returns to its caller.
>Just like Setting on *INLR and doing a Return opcode in RPG.   

Booth said;
>I am still unclear then.  I'd felt that setting on *INLR and also doing a
>RETURN was redundant.  I'd felt that a programmer would plan on one, the
>other, or neither.
>


Booth;
The RETURN opcode in RPG Returns immediately to its caller upon being 
executed.  I mean "Where ever it is executed".   I personally use 
a subroutine I call EXIT in everyone of my programs.  It does the 
RETURN opcode.  Where ever I am in the program, If the user wants to
leave,  I EXSR EXIT. I don't "Bubble up" through various DOU loops(ha ha)
to the mainline calc's just to leave.  (I have always found the effort 
to "Bubble up" through the loops to be confusing and/or convoluted to say
the least compared to just EXSR EXIT)

(And I'm not even gonna get into that esoteric indicator *INRT)

What happens to the program's invocation(files, variables, etc.) is 
dependant upon whether *INLR was seton or not. 

 If it was not seton,  the next time it is called the program starts 
"At the Top of the Calc's"  *INZSR is not done, etc. all variables & 
file ODP pointers will be "Like you never left".  (Just as they were)

If it was seton, It's a completely new invocation of the program.
"Cold Start"

Now,  If you don't use the RETURN opcode,  You must somehow get back to
the mainline calc's and "Hit the bottom"(last line of calc's before the
first SUBR)  with *INLR being on to leave/exit from the program.  

You can, as a matter of fact,  seton *INLR at the start of the program
and "run the whole program" with *INLR *ON.  It won't be checked until 
one of two things happen(in the average program) 1. You hit the last 
mainline calc.(before the first BEGSR) 2. You hit the RETURN opcode.

(I'm ignoring the *PSSR and RT indicator and a couple of other events 
out side the normal running of the program)



>Also, is there anything wrong with RETURNing from a program and relying
>upon the closing of upstream programs to close the downstream programs?

Only if the Gal/Guy who wrote the "Upstream Program" knows you're down 
there!  They won't do anything to close your program if they don't know 
it's running.  That's why I said "The shop should have a standard" about
lower level programs that don't set on *INLR.  When do they (By design) 
get closed??  We have been using a variable in the calling program to say
"I called this lower level program"  so that when the Calling program ends
its says  PGMA_OPEN  IFEQ   YES   -> Call PGMA (with parm to say 
'shut down'.

Some of our utility programs "By design" don't get closed down period. 
until the entire job ends.  

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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.