× 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.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.