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



Vernon,

do you think that Nathat is "speculating" - he is the only on that actually
runs test -
all others are just "speculating"!

On Sun, Aug 5, 2012 at 5:14 PM, Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>wrote:

Gentle folk!

Speculate all you want - better to run tests.

Brian was very closely involved with this whole thing from early on -
I'll take his word on things before that of people who've never used it.

Cheers - and off to go canoeing on our lovely lakes in Minneapolis!
Vern

On 8/5/2012 12:07 AM, Nathan Andelin wrote:
From: Joe Pluta
Nathan seems to think (and I would agree) that you can skip the stored
procedure entirely and just call the program that the stored procedure
calls.
Thanks for getting my back, Joe. This thread motivated me to download
the source code for XMLSERVICE, which is a library of several source files
and members. I reviewed the code for the XMLCGI and XMLSERVICE programs,
and several others.

It looks like XMLCGI uses an SQL CLI interface for calling the stored
procedures rather than calling the procedures directly. But I'd bet that
QZDASOINIT also uses some sort of SQL interface for calling the stored
procedures too.

At any rate, we end up comparing:

.Net App <==> DB Driver <==> QZDASOINIT <==> SQL Interface <==> Stored
Procedures

.Net App <==> REST Web Service <==> Apache Server <==> XMLCGI <==> SQL
Interface <==> Stored Procedures

-----

Since the 2nd interface includes an HTTP Server in the middle, should we
ASS-U-ME that it carries more overhead on the server? I don't think so!

For starters, I added all the CPU time consumed by the HTTP Server Jobs
and my RPG program which also uses an SQL CLI interface to generate SQL
result sets, reads them, and generates a CSV formatted response.

Then I used Visual Foxpro and an IBM i Access 7.1 DB Driver to download
the same files, and tracked the CPU time consumed by the QZDASOINIT Job.

Guess which interface consumed more CPU?

The QZDASOINIT Job actually consumed 32% more CPU time. It evidently has
MORE overhead.

Notwithstanding, we're only talking about 88 milliseconds (CGI
Interface) vs. 116 milliseconds (QZDASOINIT) to generate and output a
formatted stream of 2,249 records, for example.

-Nathan.

--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.





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 copyright@midrange.com.

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.