RE: GUI alternative to IBM Query

I think Vern alluded to stored procedures in another post, Dave, and that's
certainly one option.  Stored procedures are a specific example of a more
generalized idea: identify and define specific transactions, or messages,
that are allowed between the server (i.e., the iSeries) and the client
(anybody else).  Only these messages are allowed.  The messages are further
limited by things like user ID, IP address, time of day and so on.

HOW you invoke the server is of less consideration.  Stored procedures, web
services, XML-RPC, direct program calls, queued messages are all viable
options.  The point is that you are NOT allowing unfettered access to raw
rows and columns, but instead are only providing data that you see fit.

It's not only good from a security standpoint, but more importantly it's
more flexible from a maintenance standpoint.  With messages as the interface
between the two tiers, you can change the layout of the database without
having to change all the client software.  You can design a version number
into the message and you can even allow older clients to talk to newer
versions of the server.

This decoupling of the application logic from the database is fundamental to
robust n-tier design.  It amazes me how many people talk about OO design and
modularity but then immediately implement it using ODBC.

Joe

From: Dave Odom

Now to the serious part...   what sort of server programs are you
speaking about?   Can you point me in the right direction so I can get
educated.