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



Have you enable "detect field lengths" option? Do you have latest HTTP
group PTF?

FYI, the article was written prior to varchar[1] support. varchar would
also work in this case as well.

[1]
https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/dW%20IBM%20Integrated%20Web%20Services%20for%20i/page/Support%20variable%20length%20fields

"WEB400" <web400-bounces@xxxxxxxxxxxxxxxxxx> wrote on 08/09/2019 07:42:43
AM:

From: Ric Turner <rturner@xxxxxxxxxxxxxxx>
To: "WEB400@xxxxxxxxxxxxxxxxxx" <WEB400@xxxxxxxxxxxxxxxxxx>
Date: 08/09/2019 07:42 AM
Subject: [EXTERNAL] Re: [WEB400] IWS Large Character output support
Sent by: "WEB400" <web400-bounces@xxxxxxxxxxxxxxxxxx>


Hi All,

We have found an article that addresses speeding up the SOAP web
service when large character fields are used to return data to the
consumer (titled: Integrated web services server for IBM i updates
at website: https://www.ibm.com/developerworks/ibmi/library/i-
integrated-web-services-server/index.html ).

Below is an excerpt from the article:

Enable improved processing of very large output character fields
Length field support has been extended to character fields. Output
character fields that are very large (I am talking about 1000s of
bytes) take time to process because the determination of the size of
the string to return is done by traversing the field a byte at a
time, from right to left, looking for the first non-blank character.
To improve the processing of these large character fields, you can
specify an integer (int) field length that immediately precedes the
character field with the same name as the character field appended
with _LENGTH (similar to what is done when processing output arrays
with field lengths). If the field length exists and Detect length
fields is selected, the traversing of the field to determine the
size is not performed, improving performance. In addition, the
length field is hidden from the client and is not returned in the
client response.




My question to the group is - Has anyone tried using this approach?

I have coded my SOAP web service (I am the provider) using this
approach only to find that it does not work as outlined in the
article. I am running this on a v7.2 machine and it is written in
RPGLE as a program (not a service program).

When I perform the redeploy of the service all 3 parameters are
displayed (including the _LENGTH parm), but I was expecting only 2
parameters to appear (excluding the _LENGTH parm).


Here is the RPGLE code from my program:

D WSCASEINQ PR ExtPgm('WSCASEINQ')
D CASE# 13A
D courtcase_LENGTH...
D 10i 0
D courtcase 500000a
D WSCASEINQ PI
D CASE# 13A
D courtcase_LENGTH...
D 10i 0
D courtcase 500000a


The whole idea is to not return the _LENGTH parm to the consumer.
There is no example in the article, it just states that this
approach works like the approach used for the array.66

Does anyone know what I am doing wrong to not be able to take
advantage of this approach? Any assistance is greatly appreciated.





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.