[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Buffer size?
Thanks for responding, Alan and Scott,
No, I wish it were so simple as my misunderstanding of the tags...
Taking the very first tag as an example, it has a bunch of properties embededded into it, which are displayable on the value variable (which I described earlier as being truncated to 1024 when I display it in debug). I understand that part now, but I need to parse the individual details out of this large string to extract the field detail.
The total stream has a bunch of different named tags, all with potentially large strings of embedded properties such as this. There may be a case for not needing a pointer if all of these elements are less than 65535, but I will need to research more to find out. In the event that pointers are needed, how to access that data is a bit of a challenge. Would you say it's unlikely that an element would be this kind of size?
Thanks again !!
-----Original Message-----
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Alan Campin
Sent: Wednesday, February 01, 2012 3:41 PM
To: HTTPAPI and FTPAPI Projects
Subject: Re: Buffer size?
If I am understanding correctly what you are saying you are completely misunderstanding what this function does. It gets called when each tag ends. For example.
<customer>
<name>Joe Brown</name>
<address>123 Elm Street</address>
</customer>
This function is going to get called when the parser sees /name and the value will be "Joe Brown", then gets called when /address is seen and "123 Elm Street" the value and when it sees /customer and value will be blank.
It does not send through the whole XML string. Just each end tag and the value assigned to that end tag.
The only issue that comes up is if a single value is greater than
65524 (like a embedded document). Other wise no problem.
This how I defined one of my functions.
p EndTagGetMessage...
p b
d pi
d InOutMessageResult...
d LikeDs(TD_MessageResult)
d InDepth...
d Like(StdInt)
d Value
d InTagName...
d 1024a Varying
d Const
d InPath...
d 24567a Varying
d Const
d InTagValue...
d 65535a Varying
d Const
d InAttributeArray...
d Like(StdPtr)
d Dim(32767)
d Const
d Options(*Varsize)
So from this, InTagName = 'Name", InPath = '/Customer' and InTagValue = 'Joe Brown'
On Wed, Feb 1, 2012 at 4:15 PM, David Baugh <davidb@xxxxxxxxxxxxxx> wrote:
>
> Hi Scott, thanks so much for the reply,
>
> Two things:
>
> 1. I'm an old hand on the AS/400 but an acolyte in RPG and learning as I go. Apologies for any obvious no-no's. Thanks solely to the bank of functions you've supplied with HTTPAPI,etc., I've been able to provide my company with tools they thought were inaccessible from the AS/400. Thanks so much for all that.
>
> 2. The length of the XML stream that I'm accepting is potentially large. I found some old references to examples where a pointer has been used in cases where this was so, thus thought using a pointer might facilitate easier handling. I used the %str function just to ensure that I'm getting some data (and in the correct format) and was surprised to see it truncated to 1024 chars where the length was showing much larger values.
>
> I am using that debugger, so now understand about the truncation.
>
> Regarding the length, since I may need to parse a large stream , what approach would you recommend ? From the log, I see the stream being cut into chunks of size 8192, however without experimentation, I'm unsure if this means this is going to be handled through multiple submissions to my 'incoming ' routine of if the stream will appear seamless within the RPG, in which case, how to access the data.
>
> Thanks so much for any help.
>
> -David
>
>
> -----Original Message-----
> From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
> [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Scott
> Klement
> Sent: Wednesday, February 01, 2012 1:40 PM
> To: HTTPAPI and FTPAPI Projects
> Subject: Re: Buffer size?
>
> Hi David,
>
> HTTPAPI does not null-terminate the strings. It makes absolutely no sense to use %STR() to read them.
>
> The worst part of this is that you could end up with a working application some of the time, because the spot in memory that just happens to be adjacent to your string just might (by luck) contain a null. So you could end up with code that works in test, and fails in production, etc. Yuck.
>
> Why did you decide to use %STR? Seems a little random to me.
>
> As for the question (limit of 1024) there is no such limit. You are probably using the green screen debugger to view your variable, which will only display the first 1024 characters by default.
>
> Since you're assigning the output to a 32k variable, I find myself wondering why on earth you're asking HTTPAPI to return a pointer??
> ReturnPtr() support was added to HTTPAPI because RPG at the time only supported 64k in a single string, so we needed a way to handle XML elements longer than that. But, in your case, your own code is limiting it to 32k (half of RPG's limit) so why make things more complicated by using ReturnPtr()?
>
> -SK
>
>
> On 2/1/2012 2:59 PM, David Baugh wrote:
> >
> > if path = 'xxxxxxxxxxxx'
> >
> > if (name = 'xxxxxxx');
> >
> >
> > val = %str(value.buf);
> >
> >
> > etc, etc.
> >
> ----------------------------------------------------------------------
> - This is the FTPAPI mailing list. To unsubscribe, please go to:
> http://www.scottklement.com/mailman/listinfo/ftpapi
> ----------------------------------------------------------------------
> -
> ----------------------------------------------------------------------
> - This is the FTPAPI mailing list. To unsubscribe, please go to:
> http://www.scottklement.com/mailman/listinfo/ftpapi
> ----------------------------------------------------------------------
> -
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------