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.

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