Chuck,

I'm leaning heavily toward the file not being FTP'd properly from the
vendor. I did learn that I can transfer the file directly from the
vendor to the iSeries so that will be my next step. The DW resource has
been pulled to something else for the moment so I'm waiting to get the
information for the FTP.

Rick

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Wednesday, March 05, 2008 4:20 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Replacing packed fields in record

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
--
All comments provided "as is" with no warranties of any kind
whatsoever and may not represent positions, strategies, nor views of my
employer

Privileged and Confidential. This e-mail, and any attachments there to, is intended only for use by the addressee(s) named herein and may contain privileged or confidential information. If you have received this e-mail in error, please notify me immediately by a return e-mail and delete this e-mail. You are hereby notified that any dissemination, distribution or copying of this e-mail and/or any attachments thereto, is strictly prohibited.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 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].