×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
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.
As an Amazon Associate we earn from qualifying purchases.