Re: REXX AND ADDRESS EXECSQL

[CRPence <CRPbottle@xxxxxxxxx>]

Simon Coulter wrote:
> On 07/04/2010, at 1:00 AM, CRPence wrote:
>
> > Thus there would appear to be a defect [at least at that
> > release & unknown PTF level];
>
> This problem is apparent (for RENAME and ALIAS) on VRM510 too
> therefore it's probably been broken for a very long time. Just
> because no customer has reported it doesn't mean it shouldn't be
> fixed once it is known (i.e., reported in the Lab). Leaving known
> defects in code is simply sloppy.
>
> Does seem odd though. There is nothing particularly different
> about a RENAME or CREATE ALIAS versus any other SQL DDL statement
> so why should these fail when others, such as CREATE TABLE,
> CREATE INDEX, etc. work OK?
>
> Interestingly these statements run successfully via a QM Query 
> object--even a dynamic one.

  From what I recall about the SQL for REXX, many statements have 
their own procedure in a program to process that specific [type of] 
statement.  For example, what I recall of how I /corrected/ the CALL 
statement to enable INOUT parameters [within the lab, using my own 
personal copy of the ?QSQREXX? program], I found the procedure for 
the CALL statement processing, and updated it to perform some 
additional work which would effect the update to the parameters. 
Other interfaces are typically utilities which would just use the 
SQL CLI or some other entry to purely dynamic; the interface with 
REXX and its feedback as part of the EXECSQL language environment 
interface is a much tighter integration.

  The dev chose not to correct the defects that I reported, more or 
less, because I was not an external customer when I reported them; 
choosing instead to work on new function, performance, and defects 
with more ?strategic? interfaces.

Regards, Chuck