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.
