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.

Return to Archive home page | Return to MIDRANGE.COM home page