Re: receiving POST encoded in JSON

@Bradley

Maybe I have another approach - programmers do not need to understand
why a service sub-procedure is build as it is build - middleware takes that
understanding out of the equation and the programmer can concentrate
on what the sub-procedure does.

Have you looked at CGIDEV2 sub-procedures and how they interact? I
will guarantee that we are less that 10 programmers of the 15.000+
that uses CGIDEV2 that fully understand it.


the $, #, and @ is only a problem in EBCDIC and in native source files
but other constants may also be a problem like { [ ] }. This has been
discussed
from time to time during many years.

For internationalized EBCDIC source code we should stick to the 'shared'
characters that has the same hex positions in all EBCDIC CCSID's.

As Kevin pointed out many of the RPG examples can't be copy/pasted into
any CCSID source member but needs conversion. In denmark you code
will look like

Æstartup();
inContLen = Æst_CtoN(ÆGetEnv('CONTENT_LENGTH')); ÆwriteTemplate(
'stdhtmlheader.erpg'); ÆloadTemplate('readbig.erpg':'top'); ÆreplaceData(
'/%length%/':%char(inContLen)); ÆwriteSection(); if (inContLen > 0); dataØ
= %alloc(inContLen);

etc.


In ASCII based source files they don't represent a problem since all these
characters are within x'00'-x'7F' that btw are shared with UTF-8.


My refering to how Apache converts data has nothing to do with the server
setup since the client solely controls the MIME header that are send to
the server and in public web-services we often do not control the client.


I will of course post the examples when I'm done implementing a complete
YAJL example both generating and receiving JSON using HTTPAPI as client
and powerEXT as the web-service and it will support data and storage up to
2GB.


On Mon, Aug 3, 2015 at 7:28 PM, Bradley Stone <bvstone@xxxxxxxxx> wrote:

Henrick,

The post I made was not meant to be an all inclusive answer that one can
just implement.

It was showing the concepts required to solve the problem. I prefer to
take the "teach them to fish" route as learning is more valuable than just
pasting code. If someone wants a full application I'm happy to help and
bill for that. :)

As for the special characters (at least #), that's easily fixed. And,
actually they will work fine on CCSID 277 and 280. I hope they don't have
to twitter if that # is no good. :)

As for "answering back" I'm not sure what you mean by that.

And, the QtmhRdStin comment, yes... but I'm not going to guess on the setup
of the server for each case. YMMV.

It's great to hear you've worked with the OP to solve the issue. Why not
post your solution to the problem here (or somewhere else) for others to
see? That would be much more beneficial to everyone.

Brad
www.bvstools.com

On Mon, Aug 3, 2015 at 12:18 PM, Henrik Rützou <hr@xxxxxxxxxxxx> wrote:

@Bradley


First of all, Pat runs on a machine with Italien EBCDIC CCSID so your
sub-procedures
will not work since # in US is x'7B' and in Italian is x'B1' where x'7B'

is

£.

In general if you use $, # or @ and any of these characters are moved
elsewhere
in the CCSID you may be in trouble.

here you have an overview of EBCDIC code pages ...

http://www.easymarketplace.de/codepages.php


Secondly your example will probably hang up some clients or throw an HTTP
error back since you don't answer back.


Thirdly the example has another missing bit ...

When you receive data through QtmhRdStin the data you will receive will
either be in EBCDIC or in ASCII/UTF-8 depending on the MIME Content-type
the client choses to use:

If the content-type is text/... Apache automatically converts from
ASCII/UTF-8 to EBCDIC

if any other content-type is received the data passed by qtmhRdStin is in
the original
received CSSID typical either ASCII or UTF-8.

The QtmhWrStout functions the same way with a twist ...

if you write out a content type: text/...; charset=xxxxx no conversion is
done of data by
Apache.


PS.

I have worked with Pat during the weekend to establish a HTTPAPI client

and

a
receiving powerEXT program using a combination of both and YAJL.

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