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

On 10/19/05, qsrvbas@xxxxxxxxxxxx <qsrvbas@xxxxxxxxxxxx> wrote:
> 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.

it is a mixed shop.  a few RPG programmers, a few COBOL programmers,
then analysts who code to one degree or another in SQL procedures.
What we all have in common is we have been instructed to code in SQL
whenever possible.  And SQL procedure code, the kind that is compiled
as a specific by the C compiler, functions with few restrictions as a
HLL.  The terrific advantage of SQL procedures is the code is portable
to any SQL platform - Oracle, SQL Server, DB2, MySQL.

I have been impressed by what I have seen this shop doing with SQL. 
There is so much work that has to be done and so many other factors
having to do with a large shop ( adhering to @#$ turnover for 
instance ) that it works well for them to limit their use of
languages.

-Steve

>
> >> 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
>
> --
> 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
>
>
>
> __________________________________________________________________
> Switch to Netscape Internet Service.
> As low as $9.95 a month -- Sign up today at http://isp.netscape.com/register
>
> Netscape. Just the Net You Need.
>
> New! Netscape Toolbar for Internet Explorer
> Search from anywhere on the Web and block those annoying pop-ups.
> Download now at http://channels.netscape.com/ns/search/install.jsp
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>
>