× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.