Re: XMLSERVICE and losing Wildcard from SQL LIKE

Oops. put a TRIM(LSTNAM) and it works.

Not sure if that's a DB2 feature or bug when using padded char fields.

The XMLIN data buffer in the XMLCGI RPG app does contain the EBCDIC %6C coming in, but there's a routine in XMLCGI appropriately called apaHack that is messing it up and converting it to EBCDIC %25

There's no docs on what specifically it's doing and it uses a bunch of pointer stuff.

Looks like there was some change made in XMLSERVICE V1.8.0 that does a check on 6C that might be the culprit.

Regards,

Richard Schoen | Director of Document Management Technologies, HelpSystems
T: + 1 952-486-6802
RJS Software Systems | A Division of HelpSystems
richard.schoen@xxxxxxxxxxxxxxx
www.rjssoftware.com
Visit me on: Twitter | LinkedIn

------------------------------

message: 4
date: Wed, 16 Dec 2015 13:12:18 -0600
from: CRPence <crpbottle@xxxxxxxxx>
subject: 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.