On 09 Mar 2013 08:41, Eric Lehti wrote:
<<SNIP>>
The base code I am working from is :
http://www.itjungle.com/tfh/tfh070703-story04.html
<<SNIP>>
  FWiW: The article at that link describes a non-text file being sent 
homogeneously with the EBCDIC type established, but fails to also 
establish the MODE B [BLOCK] for the FTP session.  The file used in the 
example can be transported, but only because its numeric data is zoned 
decimal [which all representations are /printable/ characters] and all 
of the character data is non-control /printable/ characters.  With the 
default MODE S [STREAM], binary data that might /look like/ an EOR [End 
of Record] will cause a record break so the data at the target will not 
match the data on the source, and may cause errors; i.e. the EOR would 
be dropped, and the remainder of the record would become a new row in 
the database file.  My preference is to avoid using FTP to transport 
externally described [non-source] database file data, and instead use a 
database-specific transport such as DRDA; or export the database data 
into text, and then transport that text data to be imported as the 
target database.
  For reference:
http://archive.midrange.com/midrange-l/200803/msg00225.html
  Apparently [I had forgotten that] the TRIM option is or may be also, 
a potential issue for described database files vs purely text DB files:
http://archive.midrange.com/midrange-l/200806/msg01128.html
As an Amazon Associate we earn from qualifying purchases.
	
 
This mailing list archive is Copyright 1997-2025 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.