AW: Changing a called sqlrpgle program to return a value

Why not simply adding an (optinal --> OPTIONS(*NOPASS)) parameter at the end
of the parameter list.
Another way may be to send an escape message in error situations from
COMMPGM to the previous call stack. In the caller program you can trap and
handle the error with a monitor group.

Mit freundlichen Grüßen / Best regards

Birgitta Hauser

"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them
and keeping them!"

-----Ursprüngliche Nachricht-----
Von: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] Im
Auftrag von Koester, Michael
Gesendet: Thursday, 29. September 2011 00:01
An: RPG400-L@xxxxxxxxxxxx
Betreff: Changing a called sqlrpgle program to return a value

I'm trying to get my head around this, but failing...
I have a driver program (DRIVERA) that does a bunch of stuff, runs a bunch
of private subprocedures, calls some service programs, and calls another
program (COMMPGM) that handles some communications with another platform,
calls other relevant service programs, runs private subprocedures, etc.
Both DRIVERA and COMMPGM are *PGMs (created from SQLRPGLE source), with
*INLR and all that. COMMPGM is something of a driver program itself,
handling sockets connections, throwing lots of transactions to the other
platform, receiving results, writing records to a logfile, etc. Its only
caller is DRIVERA.

Now I have a need to return a value from COMMPGM, back to DRIVERA, so
DRIVERA can deal appropriately with abnormal situations encountered in
COMMPGM. Since I'd set COMMPGM up with a Prototype instead of a *entry
PLIST, I figured I'd just adjust that prototype and Procedure Interface to
include the return value definition and I'd be well on my way... until the
source editor reminded me that extpgm was not compatible with a return
value. Apparently I need to use extproc instead? I expect that means other
things will need to change, but I don't know exactly what, and that's where
I need help.

Essentially the process should look like this:
DRIVERA:
...Do some stuff...
DOU done;
If not done;
...Do more stuff...
If COMMPGM(a : b : c) = 'TYPE-A BAD STUFF HAPPENED';
...Do failure stuff...
ITER;
else;
...Do other stuff...
endif;
endif;
enddo;
...Do cleanup stuff...
INLR = *on;

I'd really rather not go back to the PLIST approach, but I don't get to
spend a week figuring out how to get a compiled object, and another week
finding & fixing the run-time issues brought on by my naiveté. Is there
hope? Should be simple, right? We're running v6.1

Thanks.
Michael