× 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.



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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.