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
midrange.com
