Re: imbedded CL in RPG -- RPG400-L

Your example was clear and will answer the problem in many instances.  
However, on the return a variable option usage, writing a generic one 
gets a little trickier when you want to do a RTVJOBA and which item you 
wish to see may vary from time to time.





infosys@klements.com on 08/09/99 08:03:29 PM
Please respond to RPG400-L@midrange.com@Internet
To:     RPG400-L@midrange.com@Internet
cc:      
Fax to: 
Subject:        Re: imbedded CL in RPG

"Roll your own" seems a bit strong for simply writing a prototype!

Try this:

D RunCmd          PR                  ExtPgm('QCMDEXC')
D   command                    500A   CONST
D   Length                      15P 5 CONST
C                   CALLP     RunCmd('SNDMSG MSG(''Neato'') -
C                               TOUSR(WHOMEVER)': 500)

At one point, I wrote a somewhat better one than this that was an
actual sub-procedure, used operational descriptors to get the length
of the command, and called QCAPCMD instead of QCMDEXC so it could
actually return the MsgID of an error (as a return value) or blanks
for success.

However, due to the extra hassle of binding to that sub-proc every
time, I tend to ususally just use a simple prototype like in the
example above :)

This example does NOT address the idea of passing variables by
reference in order to get a return value.

ANOTHER IDEA:   (and this one DOES address the variable issue)

How about having seperate sub-procedures for your CL commands, in
other words, each subprocedure would need to be labelled as either
RPG or CL.

Then, a simple program... a "preprocessor" if you will...  could be
written to do the following:

          1) Seperate each CL "sub-procedure" into its own source
                  member in a file in QTEMP.
          2) Seperate the RPG source into its own source member
                   in a file in QTEMP.
          3) Compile each RPG & CL module (using CRTRPGMOD and
                   CRTCLMOD) individually in QTEMP.
          4) Finally, bind them all into a program.

This would, effectively, allow you to run CL stuff in the same source
member as your RPG program...  Since you can bind modules written in
CL to modules written in RPG, this would give you very nearly the same
performance and benefits of having the CL embedded.

Without losing the convienience of having it all in one source member.

Just an idea!

Scott Klement
Information Systems Manager
Klement's Sausage Co, Inc.


Rob Berendt <rob@dekko.com> wrote:
>
> No, you have to roll your own.
>
> And they never did get back to me as to whether or not the following
>  will
> be supported, or is doable:
>
> C    Eval   JobUser = *blanks
> C    CALLP  Runcmd(RTVJOBA USER(&JobUser) )
> C    DSPLY  JobUser
>
> dbale@genfast.com on 08/09/99 12:57:06 PM
> Please respond to RPG400-L@midrange.com@Internet
> To: RPG400-L@midrange.com@Internet
> cc:
> Fax to:
> Subject: RE: imbedded CL in RPG
>
> Hans, Bob, et al:
>
> >>C    CALLP  Runcmd('OVRPRTF QPRINT OUTQ(' + variablename + ')')<<
>
> Uh, is this Runcmd procedure available to us already, in the compile
>   Or do we
> have to build this ourselves?  I scanned for Runcmd in the softcopy
>  but came up
> with zilch.  We're at V4R2.
>
> - Dan Bale
>
+---
| 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
+---END



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