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
midrange.com
