Re: XMLSERVICE

I have now been testing XMLSERVICE on a CCSID 277 (danish) system and here
are some general comments:


Installation:

The installation procedure runs but it creates program that runs in CCSID
37 and that
is bound to cause trouble since many XML special characters has different
hex
EBCDIC values in different CCSid's.

One way to avoid this problem is to run all programs in the same CCSID by
making
an installation procedure that starts with creating new empty source files
and then
copy the source in the delivery into the new source files before compiling
the package.


However in XMLSERVICE this creates a new problem because the extensive use
of
@ in field names- @$ etc. are invalid characters in field names in CCSID
277.

The only way to avoid this is to use only A-Z, 0-9 and _ in all source
naming.


And other problem occurs in PLUGXML_H because the <![CDATA[ is created
in field YCDATAx/zCDATAx as a const(x'4C5AADC3C4C1E3C1AD'). Since XMLCGI
uses Apache to convert EBCDIC to ASCII/UTF-8 and Apache uses the job's
EBCDIC
CCSID and not the programs CCSID the conversion returns <¤¬CDATA¬ ... ||>

One way to avoid this is to use const('<![CDATA[') instead hex and the
above
method of copying source that will change the underlying hex value of the
characters
when the source is copied.


some XML suggestions:

XML has special characters such as <>"&' etc. that has to be encoded in the
data
part of the XML element - XMLSERVICE dosn't encode these and the XML fails.

The most common way is to encode these characters into &lt; &gt; etc. and
IMO
packing the data into CDATA should be avoided.


Data comming from DB2 may also (especially if data comes from web systems)
contain invalid XML characters such as CRLF - such data should be passed in
XML
elements that wraps the data into <![CDATA[ ... ]]> sections.

Since such characters normally are below x'40' in ebcdic it should be faily
easy to
test and add the CDATA tag automatically.

If data is packed in CDATA the above mentioned special characters shouldn't
be
encoded.


DB2 has a very nice feature and that is the RRN, why not include the RRN in
the output:

<file id="PXXLTBL">
<record rrn="1">
<XLLNGC>da</XLLNGC>
<XLHEAD>Danish</XLHEAD>
<XLLNGD>d.m.Y</XLLNGD>
<XLLNGE>H.i.s</XLLNGE>
<XLLNGP>,</XLLNGP>
<XLRCST>A</XLRCST>
<XLRCDC>D</XLRCDC>
<XLRCUD>1</XLRCUD>
</record>


Another nice feature would be the total number of rows in the scope
requested:

,{
"name":"XLRCUD"
,"type":"float"
}
]
}
,"totalRows":9
,"rows":[
{
"RRN":1
,"XLLNGC":"da"
,"XLHEAD":"Danish"
,"XLLNGD":"d.m.Y"
,"XLLNGE":"H.i.s"


UPS, I switched to JSON.

but as I read your generated responce in XML, it would be a peace of cake to
implement JSON as a response format.


Compatibility to other Open Source projects ....

Last but not least there should be a CGIDEV2 based implementation, where
input received in a CGIDEV2 program could be merged with a
CGIDEV2/XMLSERVICE
script template, then passed passed and the result then passed to the
CGIDEV2
output buffer or in other words a mechanism to pass XMLSERVICE script by
storage
ADDR/SIZE and then get ADDR/SIZE of the result back.