RE: how to populate the field when the field name

Hi Lim,
 
<snip>
Actuallythere are lot more fields
Haven't had a chance to read the whole article. Seems like the method is
similar.
If the field is a pack decimal and the data is in xml file. How do you
convert the string data in the xml into a pack format?
</snip>
 
We use two main ways of converting XML data into database data. These ways
may be of use as they can allow parsing of data into program variables as
part of the process. 
 
1) We use the XML Toolkit SAX C++ parser to parse the XML and then use RPG
IV call-back procedures to populate a locally defined DS with the data. This
is really simple and you can parse data really, really quickly.
 
2) We use Java transform stylesheets to transform the XML data into SQL
inserts. You can then execute the statements over the database. This is more
flexible, but a little slower.
 
Now, the net result is the same in both cases above. But, using option 1
allows you to parse the data into RPG program variables - so it can be used
without any database interaction at all. In option 2 you never parse data
into RPG program variables, but this is a perceived benefit to us, as there
is no dependence upon program described structures that will need updating
if the XML is changed - there's fewer moving parts.
 
 
Below is some sample XML for the options to process. It is in simple row/col
format, with the field names used as the tags.
 
<?xml version="1.0" encoding="UTF-8" ?>
<root>
<file1>
 <field1>value of field1</field1>
 <field2>value of field1</field2>
 <field3>value of field1</field3>
 <field4>value of field1</field4>
</file1>
<file1>
 <field1>value of field1</field1>
 <field2>value of field1</field2>
 <field3>value of field1</field3>
 <field4>value of field1</field4>
</file1>
</root>  
 
Option 1 would simply clear (or reset) a DS over myFile each time the
openElement call-back procedure is called for tag file1. It would then
populate each field as each corresponding character data is encountered.
Each time the closeElement call-back procedure is called for file1 then the
now-populated DS is used to write to the file. This works really well, and
we use if for talking to a remote SAP order entry system using MQ.
(Obviously, the XML much more complicated in reality, but the process is the
same - even when using several files)
 
The other benefit is that you can use this process to populate arrays (or
even subfile rows) - there doesn't need to be any interaction with the
database.
 
Option 2 would use Java to parse and transform the data and place it into an
IFS file. You then open the file and process the data within. On our systems
the transformation is into SQL insert statements. The simplicity of this
system is unbelievable. You simply create a stylesheet to map an XML doc to
your tables. That's it! The downside is that you can't easily get hold of
the data within your RPG program.
 
However, you can transform the XML into a HTTP query string and parse that
into a DS of your choice. The DS doesn't need to be defined in your program
- you just need a pointer pointing to some memory. You just pass that.
 
To do this you use the QtmhCvtDB API. This API will parse a query string and
look for name=value pairs. You can pass it a DB file name, a pointer to a DS
(or just some memory) and for any name that matches a field in the file it
will place the corresponding value in the correct position within the DS -
foramtted as the correct data type! Very slick.
 
So, if you convert the children of each row to a string like: "field1=value
of field1&fields2=value of field2&field3=value of field3&field4=value of
field4" then the API will parse and format the data into the DS for you. You
can do what you want then.
 
Below is the info in this API.
 
Now, as for going the other way... :-)
 
Cheers
 
Larry Ducie

Convert to DB (QtmhCvtDB) API

Important: Information for this topic supports the latest PTF levels for
HTTP Server for iSeries . It is recommended that you install the latest PTFs
to upgrade to the latest level of the HTTP Server for iSeries. Some of the
topics documented here are not available prior to this update. See
http://www.ibm.com/servers/eserver/iseries/software/http/services/serviceht
m  Link outside Information Center
<http://publib.boulder.ibm.com/iseries/v5r2/ic2924/info/rzaie/www.gif> for
more information. 
Required Parameter Group:       
1        Qualified database file name    Input   Char(20)       
2        Input string    Input   Char(*)        
3        Length of input string  Input   Binary(4)      
4        Response variable       Output  Char(*)        
5        Length of response variable     Input   Binary(4)      
6        Length of response available    Output  Binary(4)      
7        Response code   Output  Binary(4)      
8        Error Code      I/O     Char(*)        

The QtmhCvtDB API provides an interface for CGI programs to parse CGI input,
defined as a series of keywords and their values, into a buffer which is
formatted according to a DDS file specification. CGI input data, which comes
to the CGI program as character data, will be converted by the QtmhCvtDB API
to the data type defined for the keyword by the corresponding field name in
the input DDS file. Language statements, such as the ILE C #pragma mapinc
statement, provide the ability to map the returned structure with field
names defined in the DDS file. See the appropriate language user's guide for
details. 

Note: QtmhCvtDB API is not allowed in CGI mode %%BINARY%%. 

The following DDS field types are handled:

*       A - Alphanumeric (see note 1 below) 

*       P - Packed Decimal (see note 2 below) 

*       S - Zoned Decimal 

*       F - Floating Point 

*       T - Time 

*       L - Date 

*       Z - Timestamp 

*       B - Binary (see note 3 below) 

*       O - DBCS 

The following DDS field types are not handled:

*       H - Hexadecimal (see note 4 below) 

*       G - Graphic 

*       J - DBCS 

*       E - DBCS 

Notes: 

1.      The VARLEN keyword is not supported. 

2.      When using a packed decimal field, the #pragma mapinc() must use _P
the option, to create a packed structure. 

3.      Input to Binary fields is converted to integer. The DDS file
specification must declare zero decimal positions (for example, "xB 0",
where x is 1-9). 

4.      ILE C converts hex DDS field data to character fields. Since the
input stream to QtmhCvtDB() is a text string, the "hex" data would be
converted from text to character fields. Therefore, using the A
(Alphanumeric) field type to obtain the same conversion. 


Required parameter group


Qualified database file name 

Input:CHAR(20) 


The input variable containing the name of the database file defining field
names and data types for the keywords anticipated in the input to the CGI
program. Typically, the database file is generated using DDS to define the
fields corresponding to the keywords anticipated in the CGI inputs. The
first 10 characters contain the database file name, and the second 10
characters contain the library name.

Input string 

INPUT:CHAR(*) 


The input variable containing the string of CGI input parameters to be
parsed. When the environment variable REQUEST_METHOD indicates that the
method is GET, characters up to the first ? are ignored. The string must
meet the format requirements for CGI input keyword strings.

Length of input string 

INPUT:BINARY(4) 


The input variable containing the length of the character string that
contains the CGI input parameters to be parsed. The length of the string
must be greater than 0.

Response variable 

OUTPUT:CHAR(*) 


The output variable which is to contain the structure mapped according to
the database file describing the input parameters anticipated by the CGI
program.

Length of response available 

INPUT:BINARY(4) 


The input variable containing the total length of the buffer into which the
CGI input parameters will be parsed.

Length of response 

OUTPUT:BINARY(4) 


The output variable that contains the length of the response. If the
response variable is too small to contain the entire response, this
parameter will be set to the size that is required to contain the entire
response.

Response code 

OUTPUT:BINARY(4) 


A code that indicates the status of the request.

*       0 - All keywords have been translated according the database file. 

*       -1 - The database file contains definitions for structure fields for
which the CGI input has no corresponding keyword. 

*       -2 - The CGI input contains one or more keywords for which the
database file contains no corresponding field. 

*       -3 - A combination of the condition for response codes -1 and -2 has
been detected. 

*       -4 - An error occurred while converting the CGI input string to the
DDS defined data types. The data may or may not be usable. 

*       -5 - This API is not valid when a program is not called by HTTP
Server. No data parsing is done. 

*       -6 - This API is not valid when operating in %%BINARY%% mode. No
data parsing is done. 

Error Code 

I/O CHAR(*) 


The structure in which to return error information. For the format of the
structure and for details on how to process API errors, see the API error
reporting topic in the iSeries Information Center.


Error messages


CPF24B4 E 

Severe Error while addressing parameter list. 

CPF3C17 E 

Error occurred with input data parameter. 

CPF3C19 E 

Error occurred with receiver variable specified. 

CPF3CF1 E 

Error code parameter not valid. 

CPF9810 E 

Library &1 not found. 

CPF9812 E 

File &1 in library &2 not found. 

CPF9822 E 

Not authorized to file &1 in library &2