× 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: Call or Bound Call
  • From: "Scott Klement" <infosys@xxxxxxxxxxxx>
  • Date: 18 Aug 1999 00:35:39 -0500

Hi Buzz,

<SNIP>
>
> 0353.00      C           *IN06     IFEQ '1'
> 0354.00      C                     CALL 'QCAEXEC'
> 0355.00      C                     PARM 'DSPMSG'  CMD     6
> 0356.00      C                     PARM 6         LENGTH 155
> 0357.00      C                     ELSE

You can use both methods (CALL and CALLP) in RPG IV.
When you use the ExtPgm keyword on the prototype, its a dynamic
call and is basically equivalent to the RPG III code that you
included.   Unless the program you're calling is in the same
activation group -- or a named activation group -- you won't see
any performance gain in calling it from an ILE program.

In any case, you won't see any difference between the CALL op-code
in RPG IV and the CALLP op-code to an EXTPGM prototype.

> 0059.00 D*
> 0060.00 DRunCmd           pr                  extpgm('QCMDEXC')
> 0061.00 D command                       80a   const
> 0062.00 D length                        15p 5 const
> 0063.00 D*
>
> bunch of code, etc.
>
> 0231.00 C*
> 0232.00 C     *in06         ifeq      *on
> 0233.00 C                   callp     RunCmd('DSPMSG':6)
> 0234.00 C                   else

I'm unsure why you called QCAEXEC in one example and QCMDEXC in
the other, since both would work in both scenarios, why not be
consistent?  Both QCAEXEC and QCMDEXC are OPM programs running
in the default activation group.  Doesn't matter what you do to
them, they'll perform just like they did in RPG III.

But if you called a procedure in a service program or a bound
module, you'd see a huge performance improvement.

However, rarely do I find static binding (because its a pain to
maintain) to be worth the performance improvement.  I usually use
a service program for routines that I want to reuse from program
to program, instead.  Its "the best of both worlds", IMHO.


So whats the advantage of using CALLP vs CALL in RPG IV?
C                   callp     RunCmd('OVRDBF FILE(CUSTMAS) TOFILE('
C                               %trim(libname) +'/'+ %trim(filename) +
C                               ') SHARE(*YES)': 80)

 *  Is a little easier to code and read than:
C                   eval      Cmd = 'OVRDBF FILE(CUSTMAS) TOFILE(' +
c                               %trim(libname) +'/'+ %trim(filename) +
c                               ') SHARE(*YES)'
C                   call      'QCMDEXC'
c                   parm                    Cmd
c                   parm      80            Len

 * and a heck of a lot easier to code and read than:
C                     MOVEL'OVRDBF'  CMD    80 P
C                     CAT  'FILE(':1 CMD
C                     CAT  'CUSTMA':0CMD
C                     CAT  'S) TOF':0CMD
C                     CAT  'ILE(':0  CMD
C                     CAT  LIB:0     CMD
C                     CAT  '/':0     CMD
C                     CAT  FILE:0    CMD
C                     CAT  ') SHAR':0CMD
C                     CAT  'E(*YES':0CMD
C                     CAT  ')':0     CMD
C                     CALL 'QCMDEXC'
C                     PARM           CMD
C                     PARM 80        LEN    15 5

Frankly, I go crazy if I have to work in RPG III these days|
(Even more crazy if I have to use RPG II)

and thats just string manipulation, thats not even talking about
the added advantages of bound procedures, service programs and
activation groups||

HTH,

Scott Klement
Information Systems Manager
Klement's Sausage Co, Inc.
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-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 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.