× 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.



Jon:

It's been over 10 years since I last looked at an IRP listing of a CL program. 
I recall that it was unlike COBOL (or RPG, etc.), but never took time to grasp 
the difference since it never was important to what I was doing. Now, your 
comment raises curiosity.

First, I have to comment that the IRP certainly makes it _appear_ to be 
compiled. And certainly in specific cases (e.g., CHGVAR &X (&X + 1)) it most 
definitely is compiled/converted/'whatever the proper term is' to an MI 
equivalent. However, CHGVAR isn't allowed via QCMDEXC/QCAPCMD anyway, so it's 
perhaps irrelevant.

Commands that do not directly compile/etc., seem commonly converted into forms 
of CALLX to SEPT 277 which apparently corresponds to the QCADRV API. I assume 
that's some entry into a command analyzer function that does the stuff 
necessary to check what's supplied against the command definition object and/or 
pass parms properly to the command-processing program. Conjecture on my part, 
but I don't need to really know. I can imagine enough possibilities after 
thinking about it to see various ways it could work and to see that this could 
be very similar to QCAPCMD -- after all the basic parsing and preliminary stuff 
is out of the way that is. In that sense, it sure seems you're right.

Second, it only takes a couple small CL programs to compare such things as 
running ADDLIBLE/RMVLIBLE pairs or other test cases a few thousand times as 
compiled statements vs. as *CHAR parms to QCMDEXC for example. The compiled 
statements consistently run significantly faster. I haven't gone on to see if 
ILE CL does better or worse though I've been very pleased with performance of a 
number of (properly written) CLLE modules lately. Clearly there's _some_ 
advantage to compilation.

But, regardless, I was thinking more in terms of using the language that was 
designed for the purpose. CL is the control language; RPG is the application 
logic language.

By using compiled CL (or CLLE), more control functions are lifted out of the 
application logic. The application programming can then generally ignore that 
and focus on its area of expertise. If tomorrow I so happen to decide to 
rewrite an application piece from RPG to C or perhaps even COBOL or even a 
rewritten RPG, the CL might not even need to be touched. The application piece 
can be rewritten with less significant concern for what's happening outside of 
it (ymmv). It's a smaller piece of code that performs fewer functions. Why 
should I need to take the time to handle functions that didn't need to be there 
in the first place?

It's nearly impossible to grasp that the CL compiler will go away much before 
the RPG compiler. To me, it seems a waste of effort for IBM to add 
functionality to RPG that already exists in CL. Why should money be spent to 
add keywords to RPG such as EXTFILE() when an OVRDBF can be used and 
particularly when an OVRDBF will override EXTFILE() anyway? Seems to me there 
are plenty of other things that could be added to RPG that don't duplicate 
functionality from elsewhere. (Of course, Rob's pointed out that once a feature 
is added to the language, might as well use it. Makes some sense as he usually 
does.)

Tom Liotta

midrange-l-request@xxxxxxxxxxxx wrote:

>   3. RE: Commands inside RPG (was RE: authority question....)
>      (Jon Paris)
>
> >> One of my dislikes about using QCMDEXC or QCAPCMD regularly has been the
>interpreted nature of the CL rather than compiled. Procedures in ILE CL have
>removed that minor personal irritation.
>
>Hate to disillusion you Tom - but "compiled" CL really isn't.  The command
>strings are pretty much processed the same way they are with QCMDEXC.  If
>you want to check it out write a simple CL program (not CLLE) that includes
>a couple of commands and use GENOPT(*LIST) to produce the MI listing and
>you'll see that they are still "interpreted".  Very little in CL is really
>compiled in the sense that RPG is.

-- 
Tom Liotta
The PowerTech Group, Inc.
19426 68th Avenue South
Kent, WA 98032
Phone  253-872-7788 x313
Fax    253-872-7904
http://www.powertech.com


__________________________________________________________________
McAfee VirusScan Online from the Netscape Network.
Comprehensive protection for your entire computer. Get your free trial today!
http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397

Get AOL Instant Messenger 5.1 free of charge.  Download Now!
http://aim.aol.com/aimnew/Aim/register.adp?promo=380455

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.