Scott,
Thanks a bunch. That was exactly the problem. I was assigning the
whole data structure instead of just the data itself. The sad part is
that I read the docs about CLOBs, and it completely escaped me. Since
the stored procedure is returning CLOB data, I should assign the data
and lengths to the resulting data structures as well, correct?
Thanks for the kudos on my methods. I originally designed the process
to accept and return single documents. I soon realized that one of the
elements could potentially be so large that nesting it into a single
qualified data structure was impossible. Handler methods for each
element would have been required to accomplish the same task that
xml-into already accomplishes. Considering the number of varying
elements, it seemed like "reinventing the wheel" so to speak. Instead,
I separated the inputs and outputs into three distinct documents that
would utilize the existing functionality of RPG ILE to reduce the
overhead and maintenance.
BTW. I just installed your HTTPAPI package. Very cool. I'm developing
our new product offerings for both telnet emulation and Java. The IFS
features alone have saved me a ton of research and programming effort.
Tom Armbruster
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Wednesday, December 19, 2007 11:21 AM
To: RPG programming on the AS400 / iSeries
Subject: Re: XML CLOB Parsing Problems
Hi Tom,
When I pass the values as CLOB to the xml parser via xml-into, I'm
receiving xml parser errors. If I convert the CLOB values to native
varying length strings, the strings include extra characters at the
beginning which also cause parser problems.
When you define a field as SQLTYPE(CLOB) the SQL precompiler converts it
into a data structure containing a 4-byte unsigned integer containing
the length of the data, and an alphanumeric field containing the actual
data.
For example, if I wrote the following code:
D parm1 S SQLTYPE(CLOB:65530)
The SQL precompiler would actually generate code like this (and this is
the actual RPG code that gets compiled into a *PGM):
D parm1 DS
D parm1_len 10U 0
D parm1_data 65530A
Now... you say that you are assigning this to an internal RPG varying
field in order to pass it to XML-INTO (Which I think is a good idea,
BTW). But you say you're getting "extra characters" at the beginning.
From that description, I suspect you're doing the following (which is
incorrect):
D tempvar s 65530a varying
/free
tempvar = parm1;
Why is that incorrect? Because you're treating the whole data structure
as one big string instead of looking at the subfields. So you're going
to set the length of the VARYING field to 65534, unconditionally,
because that's the total length of the data structure. The first 4 bytes
will be the hex value of the length (i.e., your "extra characters")
because you're not treating it as the length -- instead, you're treating
it as a part of the data in the field.
Instead, I suggest writing your code like this:
tempvar = %subst(parm1_data:1:parm1_len);
This way, you're explicitly telling it that parm1_len contains the
length of data you want to extract from parm1. and parm1_data contains
the data to be extracted.
I guess the thing to keep in mind when using an SQLTYPE field is that
it's not a "real" variable. The SQL precompiler will convert it into
something else that's legal RPG code -- you need to be mindful of what
it'll be converted into.
midrange.com
