Moving tables between an iSeries and DB2 for Linux

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • c0d3lib@gmail.com

    Moving tables between an iSeries and DB2 for Linux

    I am attempting to implement, what I believe to be, an unusual
    scenario, and am hoping to find someone that has experience with
    something similar. I currently have a series of physical and logical
    files on an iSeries (AS/400, System i5, or whatever IBM calls it
    today), version v5r4, and would like to permanently migrate them to a
    DB2 UDB for Linux v8 system. All of these files are used by native
    iSeries programs (written mostly in CL and RPG), and some are used by
    SQL programs, as well. The goal is to make the migration as
    transparent as possible, so the programs operate as if the files were
    still local.

    My first thought was to configure the two systems to communicate via
    Distributed Relational Data Architecture (DRDA) facilities, since both
    support it. Then I could create a DDM file on the iSeries that linked
    to the remote table on DB2 for Linux database.

    I still have several questions/concerns about this approach, and if
    anyone can provide advice or hints, it would be greatly appreciated.

    1.) Can the native RPG/CL programs perform all of their normal
    functions on a remote DDM file, including locking a row, read or
    position by a key value, update, delete, etc.

    2.) How would I configure tables/views/indexes on the DB2 for Linux so
    that they are equivalent to the physical and logical files on the
    iSeries. For example, a physical file seems equivalent to a SQL
    table, but has an optional index as part of the same object. Does this
    mean I create a SQL table with an index, and point the DDM file to the
    index, and not the table?

    3.) Finally, is there another approach that I am not considering that
    would meet my requirements? I've looked at the possibility of using
    Websphere Federation Server and DB2 Connect, but they seem to only
    work via an SQL interface, so the native programs would all have to be
    modified to use embedded SQL. This is not really an option because of
    the large number of programs in question.

    Again, I'd appreciate any advice from someone that has tried something
    like this, or even remotely similar.

Working...