Re: Unable to FTP an SQL table containing LOBs between two System I servers.

Well, if I understand you correctly, you're expecting features in a file transfer protocol that just aren't part of ftp. There's no mechanism in ftp to identify a server os or release level save for the unspecified helo type response so difficult to tell if it's a homogenous request. Nor does ftp handle ANY data types at all, never mind blobs. Strictly speaking ftp doesn't even recognize character set differences (ascii/binary modes are only "hints" to the server). Perhaps you're saying that if a bit stream that corresponds to a files' contents on system A were transferred to system B then it should be possible to overlay this bit stream with the exact same file definition and be aok. You'd still have to define how that bit stream was constructed given that the blob isn't necessarily contiguous in storage. Didn't we have SNADs for this sort of thing? (did snads support blobs?)

On 10/24/2012 4:16 PM, CRPence wrote:

But the scenario describes a homogeneous request; i.e. only IBM i
systems involved. There reasonably should be little reason the client
and server could not handle BLOB data just as it would be able to handle
other data types; e.g. BINARY, DATE, PACKED, etc. Why would there be
any difference, between the way the described scenario should handle
transport of the data for the two examples shown here, each a TABLE with
the same row of data?:

create table qtemp/ABLOB (c char, b blob (200)) ;
create table qtemp/ABINARY (c char, b binary(200)) ;
insert into qtemp/ABLOB values
('1', cast('text as *binary* data' as binary(200)) ) ;
insert into qtemp/ABINARY values
('1', cast('text as *binary* data' as binary(200)) ) ;

Though I asked the question, I have no expectation nor hope that the
FTP would handle either "properly", just as I have no expectation that
the FTP would know what to do if there were NULL values. That is
because the FTP is *not* a generic database data transport mechanism. I
am merely alluding to the potential for consistency; that, as a binary
stream, the data could be handled consistently for both sending and
receiving, of both examples. I would even expect that the CPYF utility
using FMTOPT(*CVTSRC) or FMTOPT(*NOCHK) could enable copying the data as
well, consistently for each TABLE above. However the BLOB data appears
as the string '*POINTER' instead of the inserted data; I understand the
design and the effect as implemented, though again [like with the FTP],
the effect could be handled consistently for the Copy File data requests
of the two files.