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


  1.  Home
  2. WEB400
  3. February 2017

Re: QtmhWrStout

So, you haven't tried debugging?

I have use and do use the YAJL port as well. I use it with my own toolset
(ERPGSDK). Works great.

I think the YAJL also has it's own built in options to read/translate
write/translate JSON data without having to do that manually.

Bradley V. Stone
www.bvstools.com
Native IBM i e-Mail solutions for Microsoft Office 365, Gmail, or any Cloud
Provider!

On Mon, Feb 20, 2017 at 1:01 PM, Henrik Rützou <hr@xxxxxxxxxxxx> wrote:

Bradley,

no I don't use CGIDEV2 EBCDIC buffer anymore since I in powerEXT Core has
started to detach any current dependency to CGIDEV2.

I discovered the problem under a test of my new mixed CCSid buffer
subprocedures
that by nature also suppports DBCS CCSid's where I in the test started
handcoding
the calls to QttmhWrStout internally.

So the old CGIDEV2 buffer structure as well as my old JSON generation
subprocedures
are deprecated and know uses the C addon YAJL for JSON generation that
generates
data in UTF-8 and my new buffer subprocedures that is able to receive raw
UTF-8
encoded data without the need to iconv the data first back to EBCDIC and
the forth
to UTF-8 again before the data is send with e.g. content-type:
application/json or
text/json where Apache does the iconv of the EBCDIC buffer.

The overall processing time has hereby improved vith 80% mainly achived by
removing
RPGLE stringhandling and using YAJL in C and avoiding unnecessary iconv's.

A bonus is that you are able to setup the body to be UTF-8 and append data
in any CCSid
to the buffer where the subprocedures then automatically converts the
data's CCSid (including
DBCS data) to buffers CCSid.




On Mon, Feb 20, 2017 at 7:22 PM, Bradley Stone <bvstone@xxxxxxxxx> wrote:

Have you tried debugging the CGI app to see if it's the program or the
network that is the issue?

I would think stepping through any resource intensive spots in the
program
may lend a clue.

Since you mention you're using QtmhWrStout I am assuming that you're not
using a toolkit like CGIDEV2 or ERPGSDK. Just wanted to make sure.

Here's a link to an article I wrote on debugging CGI as it's a little
different (it is similar but not as bad as debugging batch programs).
http://www.fieldexit.com/forum/display?threadid=48


Bradley V. Stone
www.bvstools.com
Native IBM i e-Mail solutions for Microsoft Office 365, Gmail, or any
Cloud
Provider!

On Mon, Feb 20, 2017 at 12:09 PM, Henrik Rützou <hr@xxxxxxxxxxxx> wrote:

Call it what you want ;-)

I have a CGI-program that writes a buffer out via qtmhWrStout, i may
call
qtmhWrStout one or several times
for the same transaction and it still works. There is no way to signal
to
QtmhWrStout that the last call is the
last call so there is no way the HTTP header knows the length of the
data
that follows.

Since qtmhWrStout dosn't know when the stream end my program isn't
ending
(*lr = on) there is no way
Apache can know when data tream ends.

The whole transaction takes about 1.5ms in the cgi program running an
SQL
and generating a JSON object.

I can btw build in a delay of 50ms between calls to qtmhWrStout it
dosn't
matter if the CGI program runs
for 151.1ms instead of 1.5ms the time in the other end just takes
around
180ms.

When I call it from my browser the entire call takes around 35ms so
about
33ms is lost in transfering the
about 4K of data somewhere.

If I do the same from a node.js program running in the machine calling
the
service over port 127.0.0.1 where
there are no network latency it takes excactly the same time - 35ms so
somewhere 33ms is lost in unaccouted
time.


On Mon, Feb 20, 2017 at 4:36 PM, Kevin Bucknum <
Kevin@xxxxxxxxxxxxxxxxxxx>
wrote:

What we call ajax is actually an XMLHttpRequest. There are messages
that
set different states. Along with the states it sends byte counts for
various stages of the process. When it gets to the state that
indicates
that it's done, it checks the bytes received against what it was told
to
expect, and if it matches, starts processing the response.
https://xhr.spec.whatwg.org/





Kevin Bucknum
Senior Programmer Analyst
MEDDATA/MEDTRON
Tel: 985-893-2550

-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of
Henrik Rützou
Sent: Saturday, February 18, 2017 2:15 AM
To: Web Enabling the IBM i (AS/400 and iSeries)
Subject: Re: [WEB400] QtmhWrStout

Tanks,

but how does AJAX call know when e.g. a JSON file send is finish so
the
AJAX
starts to process the data it receives?

On Sat, Feb 18, 2017 at 9:03 AM, Stefan Tageson
<Stefan.Tageson@xxxxxxxx>
wrote:

since you may call QtmhWrStout repeatly to flush the total data
to
a
browser through StdOut how do you tell it that it is *EOD so it
close
the connection?

Hi Henrik,

As the browser established the connection, it will be in charge
for
closing it as well. If your server does not reply in due time
then
a
timeout will occur.
Normally the browser "knows" when to close the connection based
on
the
data you sent.

Best regards

stefan.tageson@xxxxxxxx
M +46 732 369934


--
This is the Web Enabling the IBM i (AS/400 and 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.




--
Regards,
Henrik Rützou

http://powerEXT.com <http://powerext.com/>
--
This is the Web Enabling the IBM i (AS/400 and 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.

--
This is the Web Enabling the IBM i (AS/400 and 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.




--
Regards,
Henrik Rützou

http://powerEXT.com <http://powerext.com/>
--
This is the Web Enabling the IBM i (AS/400 and 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.


--
This is the Web Enabling the IBM i (AS/400 and 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.




--
Regards,
Henrik Rützou

http://powerEXT.com <http://powerext.com/>
--
This is the Web Enabling the IBM i (AS/400 and 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 [javascript protected email address].

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