|
Agreed about "and remove trailing blanks repeatedly" but don't forget it
also forces the addition of trailing blanks repeatedly after the new data
has been added. You have to add them so you can strip them off again next
time and ...
Also be interesting to see how the length of the CLOB field is being
determined - that's probably wasting cycles too but ... I still think the
RPG -> Temp CLOB - > Stored procedure is a rather slow way of handling it.
I have to believe a some CGI REST service would be a heck of a lot faster.
On 2013-10-02, at 4:47 PM, "Briggs, Trevor (TBriggs2)" <
TBriggs2@xxxxxxxxxxx> wrote:
Are you doing the:and remove trailing blanks repeatedly. Instead, make @Xml a variable-length
@Xml = %Trim(@Xml) + ...
multiple times on each build?
If so, this is forcing the program to determine the length of the field
field and all you need to do is:
rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Tim Wright
@Xml = @Xml + ...
Much less overhead.
Trevor Briggs
Analyst/Programmer
Lincare, Inc.
(727) 431-1246
TBriggs2@xxxxxxxxxxx
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:
Sent: Wednesday, October 02, 2013 4:37 PMpretty fast, but dealership based users were getting 0.1s response time
To: RPG programming on the IBM i (AS/400 and iSeries)
Subject: Re: Pushing XML out to a browser request
Here's more detailed info about what we are doing. Agree that 1s seems
with direct SQL hits so they will notice - and according to the web team -
complain. So we are trying to speed things up as much as possible. What
the end users are not understanding is that we are sending more data back
now than we were with the direct SQL. Plus - I do NOT want to continue to
direct SQL. It makes the applications too tightly coupled.
to an indented bill of material, where many records may be nested within a
This is how we generate the XML.
First, this is the relationships of the tables involved. It’s similar
parent.
this.
Basically, we read the Header and begin building a string of text like
@Xml = %Trim(@Xml)string as above.
+'<Claim>'
+'<Header>'
+'<ClaimNo>' + %Editc(Cmclm:'X') + '</ClaimNo>'
+'<ProdPlant><![CDATA[' + %Trim(Cmplnt) + ']]></ProdPlant>'
+'<ClaimType><![CDATA[' + %Trim(@ClaimType) + ']]></ClaimType>'
+'<ProcPlant><![CDATA[' + %Trim(Cmpplt) + ']]></ProcPlant>'
+'<RecStatus><![CDATA[' + %Trim(Cmrcst) + ']]></RecStatus>'
We continue processing all the “child” records and continue building the
After the XML “string” is complete we insert it into a work file as aCLOB data type that is returned to a stored procedure.
seconds on the server, the roundtrip on the external internet browser is
From: Henrik Rützou <hr@xxxxxxxxxxxx>
To: "RPG programming on the IBM i (AS/400 and iSeries)"
<rpg400-l@xxxxxxxxxxxx>,
Date: 10/02/2013 04:00 PM
Subject: Re: Pushing XML out to a browser request
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
It all depends ...
I have SQL REST based CGI services that generates XML in 0.02-0.04
about 71 ms
mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe,
On Wed, Oct 2, 2013 at 9:36 PM, Richard Schoen
<richard@xxxxxxxxxxxxxxx>wrote:
One second doesn't seem to be bad for response time.response
If you're writing to a DB and they are reading it maybe all the
channels are slowing it down a little.
Would have to know more about the plumbing sequence but it sounds like
you're writing to a DB entry and then they are reading it ?
Why not create an RPG based XML URL requestor instead so the XML
is immediate to the java app from the HTTP call to the RPG app. No DBsounds
or clob interaction needed.
Then again I don't know the app architecture and 1 second response
good to me :-)interface
Regards,
Richard Schoen
RJS Software Systems Inc.
Where Information Meets Innovation
Document Management, Workflow, Report Delivery, Forms and Business
Intelligence
Email: richard@xxxxxxxxxxxxxxx
Web Site: http://www.rjssoftware.com
Tel: (952) 736-5800
Fax: (952) 736-5801
Toll Free: (888) RJSSOFT
------------------------------
message: 4
date: Wed, 2 Oct 2013 14:44:20 -0400
from: Tim Wright <Tim.Wright@xxxxxxxxxxxxxxxxxxxxxx>
subject: Pushing XML out to a browser request
In a nutshell, we have a back end home grown RPG ERP system with a
J2EE based dealer extranet on top. Part of the function of the dealer
is the management of warranty claims. The browser requests claimin
information from the back end and the back end produces an XML
document
return. This works great - except - our web comrades complain that ittakes
over a full second to get the XML back. They do direct SQL hits to theDB
and get results in a tenth of the time - so they complain. Do you knowof
anyone who has struggled with response time related to creating XMLRPG
via
and passing it back to a web interface? We don't know where thebottleneck
is. It might be on the browser side, but we can't seem to isolate it.If
If anyone has insight about this, I can provide more details to help
you answer.
Many thanks!
**************************
This e-mail message may contain confidential or privileged information.
you are not the intended recipient, please delete the message and anyretain,
attachments and notify the sender by return e-mail. You should not
distribute, disclose or use any of the information in this message.
**************************
--
This is the RPG programming on the IBM i (AS/400 and iSeries)
(RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/rpg400-l.
--
Regards,
Henrik Rützou
http://powerEXT.com <http://powerext.com/>
--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-lhttp://archive.midrange.com/rpg400-l.
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
If you are not the intended recipient, please delete the message and any
**************************
This e-mail message may contain confidential or privileged information.
attachments and notify the sender by return e-mail. You should not retain,
distribute, disclose or use any of the information in this message.
**************************************************************************************************************************************************************************************************************************************
This message originates from Lincare Holdings Inc. It containsinformation which may be confidential or privileged and is intended only
for the individual or entity named above.
It is prohibited for anyone else to disclose, copy, distribute or usethe contents of this message.
All personal messages express views solely of the sender, which are notto be attributed to Lincare Holdings Inc., and may not be copied or
distributed without this disclaimer.
If you received this message in error, please notify us immediately atMailAdmin@xxxxxxxxxxx or (800) 284-2006.
************************************************************************************************************************************************************************************************************
--mailing list
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.
Jon Paris
www.partner400.com
www.SystemiDeveloper.com
--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.
As an Amazon Associate we earn from qualifying purchases.
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.