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



On 24 Oct 2012 09:52, Tim Bronski wrote:

On 10/24/2012 4:16 PM, CRPence wrote:
<<SNIP>> 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.

Well, if I understand you correctly, you're expecting features in a
file transfer protocol that just aren't part of FTP.

Actually, the quoted *no expectation* better reflects my opinion; as I wrote in the quoted 16:16 post [moved\quoted above]. Since homogeneous FTP on IBM i already can transport some described database data with success, I was merely expressing that IMO there is some reasonableness in expectations that the FTP should be able to /function/ just as well with BLOB as with BINARY. In effect, playing the role of "Devil's advocate".

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.

The reference to homogeneous for this case is a reference to an effective 'trick' of the FTP. The trick is about encoding; meaning non-image transport. When the two systems are EBCDIC, then "text" can be an effective equivalent to binary, and as peers the connection might legitimately [for this 'trick'] be called homogeneous.

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

I have composed many past messages describing how FTP is an incorrect tool for transporting database data, regardless that the FTP often seems able to effect that properly when using TYPE=EBCDIC and MODE=BLOCK. I provided a link [with other links available indirectly] in another message in this thread, where I describe actual and potential caveats with the presumption that the database data can transport correctly with FTP.

Perhaps you're saying that if a bit stream that corresponds to a
file's 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.

Effectively. Two fixed-length record files should read and write the identical binary data with no difficulty, just as two binary streams would read and write identically.

You'd still have to define how that bit stream was constructed given
that the blob isn't necessarily contiguous in storage.

As database row data treated as fixed-length records, the data would be read as a buffer of data in which contiguous storage is implicit. However without a conceptual enhancement for a record format that can represent greater than 32K fixed-length records, any LOB that could not be treated as effectively CAST data to a more simple character string constructed inline to the buffer, then the implication of inability to transport is more obvious.

However my example purposely chose a "short" BLOB for which an equivalent representation as a string of BINARY was possible; alluding that differences in the support for the two given scenarios were not inherently justifiable. That, even though I understand more generally all of the players and all of the potential and actual difficulties.

Again. Although I alluded to the reasonableness for expectation of some specific scenario(s) to be able to send database data, I have been consistent with my emphasis that FTP is *not* a direct database data transport mechanism; that a database transport mechanism, e.g. DRDA, should be used if database data is to be transmitted directly. Indirectly, after the database data has been transposed into either purely binary or purely text data, then FTP is perfectly suited for data transmission... but on both ends, the sending and receiving sides, transformation is required into and out of the intermediate form that was utilized to enable that more generic transport. My preferred form for homogeneous systems within "target release" limitations backwards, and presuming any later release will be able to "restore" my data, is a Save File [though virtual tape may have eclipsed that choice over time].

Didn't we have SNADs for this sort of thing?
(did snads support blobs?)

SNA/DS is also not a database data transport utility, and would suffer some similar limitations to the FTP. However because the SNA/DS feature had support [¿only?] for data with a "record length", some of the problems that FTP might exhibit for the same data are preventable; i.e. problems the IBM i FTP intends to minimize using BLOCK and EBCDIC.

Regards, Chuck

As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.