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



Vinay Gavankar wrote:

One of our partners is FTPing data from a Unix FTP server to the
AS400. I get a Hex '0D' at the end.

When the data being sent was matching in length (AS400 file
record length was 368 characters and partner claimed that he was
sending 368 characters), the last character (which was a blank)
was replaced by X'0D'. When he sent another file with varying
data lengths (to a different AS400 file), on the AS400 I get the
X'0D' was after the last character, followed by blanks.

<<SNIP>>

Per "record length" being noted, the "AS400 file" as target of the PUT subcommand was apparently a database physical file. And although in one case the records coming from a Unix stream file may have been "varying length", the database file is still accepting only "fixed length" records, so each record would correctly be padded with the blanks.

Even so, the FTP client likely should be transmitting "records", which means the x'0D' as part of a record delimiter should not be sent for each record, unless the data is being transmitted as binary versus text data; i.e. binary is a non-record stream, whereas text is record-oriented stream with a particular EOR delimiter.

However as I understand, it is the LF character [of the CRLF or ASCII x'0D0A'] x'0A' on *nix, which should be the [single byte] EOR delimiter; the CR character x'0D' being the same in both ASCII & EBCDIC. Thus it would seem most likely the stream data on the Unix client is effectively *corrupted*; i.e. the x'0D' should not be there.

Doubtful, but perhaps the Unix client has a LOCSITE subcommand option which defines that the record delimiter of the file being sent should be the x'0D0A' instead of the normal x'0A'. If so, then set that site specific option before transmitting the records. Otherwise correcting the stream to replace the 0x0D0A with 0x0A will probably have the transmittal of the records without the 0x0D being _properly_ sent as part of the record; i.e. from the perspective of 0x0A as the valid\expected EOR, whereby a preceding 0x0D would actually be considered part of the record data rather than as a delimiter.

Regards, Chuck

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.