On 2/8/2013 9:39 AM, Horn, Jim wrote:
Yes, this is what I meant. I have heard some very good techniques here for
keeping binding under control, but so far for me, the 1 module/1 pgm
approach has been easy to keep straight. Don't call Java or C here.
Java is the odd duck here; you wouldn't be creating a Java service
program, you'd probably be creating an RPG service program that does the
calls out to the Java methods. Please forgive the lax description of an
RPG source member that compiles into an RPG module that gets bound into
a service program. 'RPG service program' seems easier to say.
C is more like RPG in that one has a C source member and a C module that
goes into a service program. I myself have made a separate, one module
service program out of my C functions, but I can understand the case for
binding the C module into a service program with an RPG module.
One thing we did, don't know if everyone does this or not, is create a
service program that can call all the old programs we used to use call/parm
for - part number searches etc. It acts like a container. We call the
procedure and the svc pgm does the call/parm of the old programs. Seems to
work great. Poor mans cleanup and keeps the service pgms a reasonable
size. Any serious downside to this?
Wrappering call/parm code like this is a very valuable way to leverage
the existing code base. This doesn't inherently lead to bad
performance; the overhead of the sub-procedure is not that significant
in my experience.
One thing I'd like to point out is that all too often, the PR for the
older program exactly matches the *ENTRY PLIST of the program.
Sub-procedures offer some very cool functionality that lets us break
free of some of the restrictions inherent in that. Let's use QCMDEXC as
an example. Here's one *ENTRY to PR translation:
D QCMDEXC PR ExtPgm('QCMDEXC')
D command 32702a const options(*varsize)
D len 15p 5 const
D igc 3a const options(*nopass)
Seems straightforward enough. When we want to execute an OS command, we
do this:
QCMDEXC(cmd:%len(cmd));
But why does each and every caller need to pass %len(cmd)? Why can't
out sub-procedure do that for us? It can!
D QCMDEXC PR ExtPgm('QCMDEXC')
D command 32702a const options(*varsize)
D len 15p 5 const
D igc 3a const options(*nopass)
Now, to use it all I need to do is this:
os_command('sndmsg ''hi!'' tomsgq(buck)');
Which I like for several reasons.
1) The caller no longer needs to set up a dummy variable just to be able
to calculate the length parameter - I can use a constant!
2) If I want to add the IGC parameter to the wrapper, I can make it a
*NOPASS and let the wrapper deal with it.
3) Instead of every caller having to handle errors, I can centralise
that in the wrapper.
4) If I decide I want to use system() instead of CALL QCMDEXC, none of
the callers need to change.
5) If I decide to remove these commands from the job log, I can to that
in the wrapper. Optionally, if I add another *NOPASS parameter!
Wrappers are a great idea, but I rarely export the simple PR for the
CALL/PARM. Instead, I put that inside a wrapper which can do some
rudimentary work to make the life of every caller easier.
--buck
midrange.com
