Re: XMLSERVICE and losing Wildcard from SQL LIKE

On 16-Dec-2015 11:06 -0600, Richard Schoen wrote:

On 16-Dec-2015 08:06 -0600, Richard Schoen wrote:

<<SNIP>>

The following SQL query works:

select * from qiws/qcustcdt where lstnam like 'Henning'

Only if the result of "No rows" defines "works"; LSTNAM being CHAR(8) vs VARCHAR(8), means the last blank has significance.

When using a wildcard with a LIKE statement, XMLCGI seems to drop
the pct sign %

select * from qiws/qcustcdt where lstnam like 'Hen%'

I have tried the request both encoded and decoded and it appears
the percent sign from the query string always gets dropped.

You can see below that the XML response shows the pct sign was
dropped from the wildcard.

<prepare conn='myconn' stmt='stmt1'>
<success> +++ success select * from qiws/qcustcdt where lstnam
like 'Hen'</success>
</prepare>

I wasn't sure exactly where in the source to look for debugging
this issue, but was curious if anyone else has run into the
wildcard LIKE issue with XMLSERVICE/XMLCGI.

I was going to check to see where the percent gets stripped off
and possibly code a workaround. (No, don't make me do it !!)

This seems pretty basic so either I'm confused or there is a basic
flaw when using wildcard SQL.

Any thoughts appreciated.

Surely the issue has nothing to do with SQL, and is just the fact that the percent sign is in the string; i.e. for a like issue [pun intended], do not limit solicitation\search solely with regard to the SQL and the LIKE predicate of SQL.?

I would really love to be able to recommend using XMLSERVICE for
production use, but still not there yet.

OK, through some debugging I have the issue narrowed down to the
percent sign getting posted correctly as %6C and then getting
converted somehow to %25 in XMLCGI.

I saw an old post from Aaron on this, but I'm not sure if that's
relevant since the %6C is present in the input buffer.

Just gets turned magically to a space along the way.

Aaron pointed me to CGIConvMode setting but that doesn't seem to be
helping so far.

Any additional insight appreciated.

The EBCDIC Percent Sign [GCID SM020000 at code point 0x6C of CP00037] would be correctly translated into ASCII as code point 0x25. And as John alludes, the 0x25 in EBCDIC encoding is a control character Line Feed (LF), but that should not be relevant, unless something had gone horribly wrong; a flawed processor that blindly converted all 0x25 to 0xA0, but issued against the ASCII data, would qualify as something horribly wrong.