Re: How to Find what module a procedure is located in -- MIDRANGE-L

Better way to do executing a system command. Only need one parameter, the
command. Converts to a C string which is what the system api is expecting.
This is designed as a copy block. Include in d specs and at end of
procedure.

* ---------------------------------------------------------------
* Code...: CB_EXECCMD Project.....:
* Author.: A. Campin Date written: 02/06/2009
* Purpose: Copy block for execute system command. This function
* execute a CL command from inside an RPG program.
*
* This function must be compiled into the program
* for it to work so instead of putting into a service
* program it is made into a copy block that can be
* included in a program.
* ---------------------------------------------------------------
* Revision history:
* Project # Pgmr Date Desc
*
* End Revision History
* ---------------------------------------------------------------
/If Defined(EXECCMD_Prototype)
d ExecuteSystemCommand...
d pr
d PR_InCommand...
d Like(StdPtr)
d Value
d Options(*String)
/EndIf

/If Defined(EXECCMD_Code)
* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
* ExecuteSystemCommand
* This function executes a system command.
* Input - Command to execute.
* Output - None.
* Returns - None.
* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
p ExecuteSystemCommand...
p b
d pi
d InCommand...
d Like(StdPtr)
d Value
d Options(*String)

d ExecuteCommandAPI...
d pr ExtProc('system')
d Like(StdInt)
d PR_CMD...
d Like(StdPtr)
d Value

d cNormalEnd...
d c 0
d cNullPointerPassed...
d c -1
d cCommandFailed...
d c 1

d Result...
d s Like(StdInt)
/Free

Monitor;
Result = ExecuteCommandAPI(InCommand);
On-Error;
EndMon;

Select;
When Result = cNormalEnd;
When Result = cCommandFailed;
ERRH_Throw('CPF9898' :
cCPFMessageFileName :
'Command ' + %Str(InCommand) + ' failed');
When Result = cNullPointerPassed;
ERRH_Throw('CPF9898' :
cCPFMessageFileName :
'ExecuteSystemCommand received a empty string');
EndSl;

Return;

/End-Free
p e
/EndIf

On Fri, Feb 8, 2013 at 9:17 AM, Buck Calabro <kc2hiz@xxxxxxxxx> wrote:

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
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.