RE: Re: TV Ad (I'm the man)

midrange-l-request@xxxxxxxxxxxx wrote:

>   8. Re: TV Ad (I'm the man) (Steve Richter)
>
>I have been writing a lot of code lately that goes to vendor FTP
>sites, determines what is at the site, receives the files, calculates
>where to archive the received file to, use CPYFRMIMPF to copy the feed
>to database files, then call sql procedures to process the data.  The
>LOGCLPGM aspect of CL is a great help to keeping track of what has run
>and what failed.   RPG is not the tool for this. and besides, I was
>told SQL and CL were the prefered languages.

Steve:

Without knowing something about why you were told CL was preferred, it's hard 
to say a lot. On my personal system, e.g., CL is definitely preferred because I 
don't have a license for the other compilers. I have a CL program that builds a 
nice looking list of the records in a physical file and lets you scroll through 
them, using DSM APIs. I have another that creates DSM windows that can be moved 
_and_ sized by the user via DSM APIs. CL is surprisingly flexible.

But that hardly seems appropriate for the vast majority of business sites. In 
those cases, I'd say someone has steered you in the wrong direction. Note, 
however, that even when RPG is the driver, CL itself still is often involved. 
It just isn't "compiled" CL -- it's CL executed through QCMDEXC (or 
alternatives).

>which reinforces my point that IBM is neglecting the software side of
>the platform. You advise against using CL because of its limitations. 
>If CL could call ILE procedures in a better way it would be much
>improved.

As for a "better way", most often it's only for specific types of APIs that a 
difficulty comes up. E.g., if you write the procedure yourself and expect that 
it might be called from CL on a release below V5R3, you won't code requirements 
to pass by value unless it's a pointer and CL can simply pass the variable by 
reference. Likewise, you won't code requirements for data structures that 
include embedded packed fields. (At worst, you can code an additional procedure 
interface that CL _can_ call and that wrappers the parameters for another 
procedure in the module.)

In short, CL can easily call procedures.

OTOH, I needed to convert a C struct into RPG a while back. Buried in the 
middle of it was a kind of function declaration. Trying to figure out what in 
the world the memory layout was for that struct was a real challenge for me. I 
didn't even realize that that kind of struct could be defined before I saw it.

With that in mind, one might as well say that C shouldn't be used because it 
can do esoteric things that make no sense in other languages or that C should 
be the _only_ language used. The point is that every language has it's 
extensions and limitations. You can't expect them all to do what every other 
language does.

CL can be both an excellent driver language as well as an excellent language 
for specific kinds of functional procedures. It just needs to be used where 
appropriate.

(BTW, would I like data structures and pointer variables in CL? YES.)

Tom Liotta