c0d3lib@[EMAIL PROTECTED]
wrote:
<snip>
>
> Thanks for the reply, Larry. Yes, The scenario you described is what
> I'm trying to achieve. The tables will reside on the DB/2 for Linux
> host, and need to be accessible to the iSeries RPG/CL programs. As
> for your question about migrating the code, this would play into a
> larger strategy that allows us to migrate some of the more interesting
> processes of a legacy iSeries application. The application is way too
> large to try migrating the entire thing.
>
> Have you ever tried or seen a similar implementation using the iSeries
> as a client to any non-iSeries system? Do you know of any issues I
> should be expecting, such as the differences in security
> implementations, etc? Performance is already a concern, but all I can
> do there is measure the differences once I have at least a basic
> configuration established.
DDM provides a different level of function than DRDA. DDM allows fairly
transparent trans****t of "file I/O" requests from the System i running
the RPG application, to a remote System i (for example) that can perform
these file I/O requests. The RPG program will typically do I/O requests
such as read by key (SETLL?), read next key equal, read by relative
record no., etc. As Larry mentioned, these are not SQL operations and
DB2 for LUW does not sup****t "files", nor this type of file I/O (because
it is not, and does not map to, SQL).
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=/ddm/rbae5intrdf.htm
DRDA on the other hand allows trans****t of SQL requests between systems.
But since your RPG programs do file I/O and not SQL, DRDA would not
sup****t your proposal. In other words, there is no function to
automatically convert file I/O requests to SQL requests, as part of
either DDM or DRDA. As you correctly surmised, in order to use DRDA
(SQL), the RPG file I/O would need to be appropriately replaced with
embedded SQL, or the equivalent.
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=/ddp/rbal1intro.htm
If the business logic to maintain the data currently resides on System
i, what is the motivation to move the data to DB2 on Linux? If Linux
access to data on System i is the goal, could facilities like ODBC or
JDBC (ie on a Linux client) provide that, w/o migrating the data?
--
Karl Hanson
|
