|
That is exactly what I would want CL and RPG in the same source member (Calling QCMDEXC does not provide all the functionality of a CL program) >>> -----Original Message----- >>> From: Scott Klement [mailto:infosys@klements.com] >>> Sent: Tuesday, August 10, 1999 12:28 AM >>> To: RPG400-L@midrange.com >>> 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
As an Amazon Associate we earn from qualifying purchases.
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.