Re: FTP between LPARs doesn't produce the same row numbers

Dave Odom wrote:

Thanks much for the info. Now... what's the best way to skin this
cat and I'm not "set" on FTP. I need to use REXX to automate a
"copy" of a set of tables between two i5 LPARs; from Production to a
Data Warehouse. The table/file format will be the same (created
from DDS)... for now. I'm looking for the fastest way to make the
move, automate the move using REXX, be assured there will be no
surprise additions or deletions, etc. Heck, if I could do a cross
partition INSERT ... SELECT and it would run fast, I'd do that.

If the best way turns out to be FTP, what's involved in doing the
BINARY "conversion" on either end; not sure that sounds good or easy
if that has to be done outside of FTP but maybe I'm wrong. Do I
understand you all to say that TEXT mode with BLOCK would accomplish
what I'm looking for? I guess there is a lot about FTP I don't
understand, especially on the i5; educate me.

Simplest resolution is likely effected simply by adding MODE BLOCK to your current script. I expect with that alone, that the currently broken\failing transports will henceforth be functional [see my TRIM warning below]. Beyond that...

In either of the following choices for use of the FTP, the transport of data in a database file.member that has a combination of TEXT and BINARY data, should be able to function as intended. That is, the homogeneous FTP transport should /do the right thing/ without requiring user-effected "conversion" of text [not the binary] data on one end.

So if you are content with using a non-database transport that has no support for isolation, then FTP with TYPE I (BINARY) or FTP with both TYPE E (EBCDIC) and transmission MODE BLOCK should probably suffice. I would be hesitant to use FTP with TYPE EBCDIC for any table that had either a BINARY or a FOR BIT DATA field as the last column, until I understood for sure what the SITE TRIM needs to be, to ensure prevention of data change\loss.

The links provided in my prior message should provide what should be expected for those two choices: TYPE EBCDIC with MODE BLOCK and TYPE I

Since the transport is homogeneous, and *if* it is also sending all data every time, I would tend to prefer to use: SAVOBJ, binary transport of the save file, and then RSTOBJ. Of course then save while active is required, to minimize impact to the production data.

A blocked fetch from one connection and a block insert in another connection, for example with SQL CLI or embedded SQL, should be able to move the data relatively fast. In this manner, at least the program can access the data with an isolation level, to prevent dirty reads.

Note: Some /newer/ data types will not be supported for use by FTP, so deferral to save\restore, database transport, or export\transport\import would be the logical choice if a restricted data type is encountered.

Regards, Chuck