Re: calling a program v using a SRVPGM

"Next step looks to me to be consuming that same information with 5250.
I'm not liking what I am seeing so far."

Why? HTTPAPI is pretty easy to use and the examples cover most of the
scenarios you're likely to encounter.

And the SQL approach is increasingly well documented.

Both of these approaches can be embedded in RPG and are therefore usable
in 5250 programs.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Dec 31, 2018, at 10:52 PM, Buck Calabro <kc2hiz@xxxxxxxxx> wrote:

On Mon, 31 Dec 2018 at 20:50, Booth Martin <booth@xxxxxxxxxxxx> wrote:

Next step looks to me to be consuming that same information with 5250.
I'm not liking what I am seeing so far.

Is there something specific that you're thinking of?

And yes, I know I can use RPG to get the data directly from the files in
my development library. But that's not the point, is it? I want to be
able to enforce business rules and what is and what isn't available,
within the i-series environment and yet provide useful data for various
superusers who have their own specific needs.

Superusers, hm. I tend to give them tailored views so that they can
roll their own. As for the rest, well that's an interesting thing to
ponder. I myself am an IBM i programmer so my first answer is to use
the full power of the platform. If my web server is on the same IBM i
that my database is on, then... yeah, I'm going to use regular old ILE
RPG to get that data, to update that data, to deal with my business
rules. I can write way more readable / understandable triggers in RPG
than in SQL, and I can do it faster because of RDi and SEP. If I need
to move rules into the database, I can register those rules as UDFs
and stored procedures. My preferred architecture looks like this:

Browser -> web server -> RPGLE program -> CHAIN/READE/etc

If I had a distributed database, I'd seriously consider ARDGATE /
Appserver4RPG http://sourceforge.net/projects/appserver4rpg/ to
connect across all the systems from a single RPG program. I've used
Scott's JDBC wrapper and it works great, but if you think web services
have oddities, wait until you deal with the 'one JVM per job'
restriction. There have been lots of 'why does this not work' posts on
this topic here in this list.

Squinting at it from a different angle, why would I add a layer of web
service client/server pairs on top of native access if I controlled
both sides (client and server) and it was all on IBM i? I would create
a web service on my IBM i to let /other/ platforms get my data, but
for i-to-i applications, I'm not sure I see why that's desirable.
--buck
--