RE: FW: [OFF TOPIC] Using Expat with RPGLE part 2.

["Nicolas Machado" <nicolas.machado@xxxxxxxxxxxxxxxxxxxx>]

Sender: "Nicolas Machado" <nicolas.machado@xxxxxxxxxxxxxxxxxxxx>

Hi everybody and Scott.

I found the problem.
The length of the variable "val" to hold character data is 132 bytes but in
my exercise "len" is 6865
I mean that I receive more data that the variable can contain

So, first I think that the problem was with the call to QDCXLATE, and I
create a variable with a length of 32767 ;

	xlatebuff = %subst(string:1:len)

because we area reading in blocks of 8192, there will be no problems with
reading more than the api can receive.

The problem then was triggered by the for .. to because "len" is greater
than the length of "val".

   184           newval = '';                                 
   185           for x = 1 to len;                            
   186              if ( %subst(val:x:1) >= x'40' );          
   187                  newval = newval + %subst(val:x:1);    
   188              endif;                                    
   189           endfor;                                      

It's interesting that the error raises to the XML_Parse function, even that
the error was in a subprocedure of the caller of XML_Parse.
Yes, that's because of %PADDR.

I'll change variable val and newval to 8192 bytes and see what happend.

Please, If I'm wrong, let me know :). 


Best Regards.




-----Original Message-----
From: owner-ftpapi@xxxxxxxxxxxxx [mailto:owner-ftpapi@xxxxxxxxxxxxx] On
Behalf Of Scott Klement
Sent: Thursday, March 31, 2005 9:06 PM
To: ftpapi@xxxxxxxxxxxxx
Subject: Re: FW: [OFF TOPIC] Using Expat with RPGLE part 2.


Sender: Scott Klement <sk@xxxxxxxxxxxxxxxx>

Hi Nicolas,

> I found with your XPATH program wich one is the last element that the
> program read correctly, the next element is the data for a base64 
> encoded of a jpg image, let's say that that's not the problem, the issue 
> is that the element data is 37kb long, ok?

Expat may call your character data handler many times in order to give you 
all of the base64 encoded information.  Since it gets called many times, 
there's no real limit to how large the field can be.

Here's what I'd do:

a) have the start element handler open a stream file in the IFS.

b) in the character data handler, receive the data from the document, 
translate it to EBCDIC (with iconv API) and base64 decode it. Write the 
results to the stream file.  Note that the data needs to be an even 
multiple of 4 characters long, or you won't be able to base64 decode it. 
Decode as much of the data as you can, and save any extra characters 
for next time -- expat will call this routine over and over again until it 
has send you all of the character data.

c) In the end element handler, close the stream file.

> I mean betwen <tag> and </tag> are more than 37Kbytes, no CRLF, only 
> base64 caracters... Is there any restriction for that ?? in XML? or 
> anywhere else ?

Since Expat will call your character data handler as many times as it 
needs to, there's no limit to how large the data can be.  Well, except the 
limit of how big a file can be in the filesystem, or the amount of disk 
space you have...

Good luck!

-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubsribe from the list send mail to
majordomo@xxxxxxxxxxxxx with the body: unsubscribe ftpapi mymailaddr
-----------------------------------------------------------------------

-- 
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.8.6 - Release Date: 30/03/2005
 

-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubsribe from the list send mail
to majordomo@xxxxxxxxxxxxx with the body: unsubscribe ftpapi mymailaddr
-----------------------------------------------------------------------