Re: REXX SQL usage -- Fit it?

Comments inline.

Regards, Chuck

Tom Liotta wrote:

I uploaded some REXX code <<SNIP>> a simple proc that I sent to
IBM to find out why it wasn't working.

<<SNIP>> In the past, I had usually used a SELECT from SYSDUMMY1;
but this time I tried to use VALUES INTO, just because I hadn't
used it in REXX before and because the SQL docs said VALUES INTO
was valid in REXX.

But it simply would not return anything. No error, but no value.

Have you ever gotten an SQL CALL to work with INOUT, to return an updated value to a REXX variable? I had the same results; no error, but no value. I /corrected/ an OS SQL program [QSQ?????; I do not recall its name] to make INOUT parameters work; at least appear to. It seemed that the lack of code to set the value into the return variable was just an oversight. I never moved those changes into the OS because it was not my code.

<<SNIP>> not judged to be a trivial fix. And since not many people use REXX, the current decision is to change the
documentation, if possible for 6.1 (on-line, apparently) but
definitely for [next release].

I said that my immediate reaction was that many people don't use
REXX because IBM has seemed to abandon it. And that I'd think
about it before giving a final reply.

I see things have not changed.

The REXX SQL ability (on i) is unique. It's really quite handy, especially on systems that don't have the SQL Dev Kit. And the interpreted nature of REXX makes it (on i) uniquely well suited
for a lot of rapid testing of concepts.

AFaIK the REXX on z, and probably on L/U/W also, has DB2 SQL support. If they do have VALUES INTO support [web search for docs; DB2 LUW is 9.5 I believe], that is more ammunition to insist the clause works on i also. Since REXX is cross-platform, so likely the SQL support should be similarly compatible as the SQL across the DB2s.

Personally, I'm irritated at the thought that the IBM default
position is "This looks hard. Let's not do it." Bluntly
paraphrased, but maybe still accurate.

Might be better than suggesting it might get fixed [i.e. accept an APAR and UR1], when they know it never will. Perhaps send a message to Kent Milligan; a public name responding to DB2 SQL messages.

But I can also see how decisions on resources have to be made. Is
it worth a developer being allocated if it takes away some
feature of [next release] that the majority of the community
would rather have?

So, I figured I'd just rant about it here in case anyone else
wanted to say anything. I'm wavering between letting it go on one
hand and demanding "Fix it!" on the other.

Regardless of what your decision is, *insist* they open and close an externally visible APAR with a /closing code/ which reflects their decision. Two reasons... first to ensure anyone else that encounters the problem can search on and find the problem [in the IBM support search, not a web search and having to sift messages somewhere like here on the midrange archives], and to ensure there is a document which IBM provides to document their stated intention in case they do not follow through someone can use that as motivation to do so.

Regards, Chuck