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

midrange-l-request@xxxxxxxxxxxx wrote:

>   7. Re: Re: TV Ad (I'm the man) (Steve Richter)
>
>On 10/18/05, qsrvbas@xxxxxxxxxxxx <qsrvbas@xxxxxxxxxxxx> wrote:
>>
>> Without knowing something about why you were told CL was preferred, it's 
>> hard >to say a lot.
>
>75% of the work is done in very portable sql procedures.  Some of the
>crazy Russian emigres in the shop modified the RUNSQLSTM command to
>run an sql statement as a variable passed to a CL command.  So they
>run a lot of SQL from CL.  They dont know RPG, esp RPG FREE and there
>is no good reason for them to learn it.

Steve:

Given this as a fundamental element of the app, I'd have to disagree and say 
that this is a very specific and good reason for them to learn RPG. Or C or 
COBOL, whatever. This is essentially equivalent to saying that there's no good 
reason to learn anything but Windows command language and SQL on a PC or the 
command/scripting language and SQL on a Unix system or any single lenguage and 
SQL.

>> 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.
>
>your calling the "qsn" ile procedures from CL? how do you handle the
>api error structure?

Commonly via escape message handling by passing in x'00000000', but handling 
the return structure itself is no big deal if needed. MONMSG and basic message 
handling just is a personal preference in CL for me in my own utilities.


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

>correct me if I am wrong, but CALLPRC does not map the CL variables to
>the data type of the ILE procedure.  It just passes the value from the
>CL program by address.  Even pass by value does not map the value.  If
>so, that is a data overflow bug waiting to happen.

True, there is no prototyping. And it seems _possible_ for IBM to adapt *CMDs 
to provide a form of prototyping, perhaps by extension of the mechanism that 
allows the developer to name a REXX procedure as the CPP for example; i.e., 
name an ILE procedure and create a special *CMD object that works only in ILE 
CL programs perhaps. That'd certainly be nice. I won't argue against it. 
Prototyping isn't a requirement though I'd like it.

And AFAIK, callp doesn't map the variables to the type needed by the proc in 
RPG either, at least not by itself. (That's an attempt to be practically 
accurate.) The mapping is done by combining that with the coding of a procedure 
prototype to define the mapping rules. If you code the prototype wrong, you'll 
get just as a big a mistake as if you pass a *DEC (5 0) where a *DEC (3 0) is 
needed in CL. Either way -- coding the prototype or coding the CL variable -- 
the error is possible.

And that touches another area where CL could be improved -- /*COPY members.

Tom Liotta