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



Just from the description of the presumably fixed-record expectation, and that the received data was outside of the expected /pattern/ sounds exactly like an FTP of packed data using Text versus Binary. Although EBCDIC makes the source and destination somewhat homogeneous, special consideration for the fact that FTP is /either binary or text/ means that trying to transport non-text data using text-mode transport can be problematic. It has been awhile since I have dealt with such issues, but given Stream versus Block, then one might expect that the Packed signed BCD (Binary Coded Decimal) values for the following two decimal values might be interpreted as CRLF [two consecutive P(5,0) fields, internally 3-bytes of contiguous storage]:

Decimal Storage-Hex
-01500 0x00150D
25771 0x25771F
Contiguous, in hex: 0x00150D25771F

Note: The 0x00 is a C null string terminator.
The 0x0D25 is the EBCDIC *CRLF
-- either of those might be problematic to an interface
-- that believes it is transporting /text/ data, if it
-- does not also understand that it is transporting
-- fixed-length records; thus ignoring any control bytes

I just tried to put the above data as text in block mode from one non-i5/OS EBCDIC system using EBCDIC and Block transport. The i5/OS program described file that was pre-created with RCDLEN(6), received the two records:
x'004040404040'
x'0D25771F4040'

Such results would be *very* problematic for an assumption that the data was in an appropriate fixed-format where the first three bytes and next three bytes of each row both represent signed P(5,0) values. The effect would be that rows might look unaligned due to seemingly random dropping of transport of data for a row and starting a new row with data in the remaining row being transported [in the above case, a character was even dropped].

A PUT to the i5/OS with binary did not work, but a GET from i5/OS with binary did work, to get that data as one row.

FWiW I simply do not trust FTP to understand a mix of /binary/ and /text/ data, except when using binary transport; i.e. I consider the text transport Type EBCDIC Mode Blocked to be a /trick/ that I would not depend on, because the data is quite obviously not /text/. Given what I long ago learned about FTP, it has no design to enable handling such data, same as it would not handle interspersed ASCII and EBCDIC in the same /file/. That is really why the source system should be doing is transporting database data using a database transport like DRDA, or by creating and sending an /exported-to-text/ copy of the data using the multi-step process of:
1. export into text [stream]
2. transport text [stream]
3. create (or clear\reset) for import
4. import [with replace-data option] at destination

Regards, Chuck

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.