Re: REXX AND ADDRESS EXECSQL

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