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



Thanks Chuck.

This gives me another thing to try (whether LOCSITE is being used) as soon
as I get in touch with the person sending the data (he seems to have
vanished :-)).

The other thing I found out was that they are creating the data on a Windows
server and then FTPing it to a Unix server and then sending it to the AS400.
Now if they are using a binary transfer between Windows and Unix (as he was
trying to use to the AS400, before I told him not to), it will put X'0D' as
data on the Unix server (I think), effectively corrupting the data as you
pointed out.

So, 2 things to verify when he comes back....

On Thu, Mar 4, 2010 at 3:22 PM, CRPence <CRPbottle@xxxxxxxxx> wrote:

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
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.



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.