Chuck,
I was having similar thoughts about the FTP process late yesterday. We
use a third party tool for our FTP and I'm wondering if that may be part
of the issue. I'm also going to try and get the data directly from the
vendor and see if that helps anything.
Thanks for the links to the FTP threads.
Rick
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Tuesday, March 04, 2008 10:48 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Replacing packed fields in record
If the *nix OS can not do it, or they have chosen not to do it
because it is a PITA on that OS, that would explain why they want you to
use your more modern i5/OS to do it :-) Very likely I could give an
easy solution, but this medium is not conducive to obtaining a good
/picture/ of the scenario. I would really require even minutia about
the /files/ and data from the source and at the i5/OS, and then what
limitations or requirements for the eventual pull initiated from the DW
system.
That data was placed in a "flat file" [I infer, into a
program-described physical file of record-length-n] in /fixed-format/ or
an undetermined format? The comment that throughout the records, some
do not /fit the pattern/ seems to suggest that although the data should
be /fixed-format/ data, it is not.? That seems already to be a problem.
If the /file/ does not come from another i5/OS, then it is not a
*FILE, just data. Thus the question becomes, how does the data get into
a database *FILE on i5/OS? Tape, comm, ???
The data will in many cases be able to be dropped directly into a
described database file, and then a logical view of the data used for
transport; replacing the packed data in a variety of ways, but as
required by the recipient. That is, no copy nor massaging of the
physical data that was transported [assuming the transport itself is not
currently flawed].
If transport is *not* by FTP from the unstated EBCDIC system, then
probably skip the rest...
FTP of EBCDIC data which combines binary and text may be just as
problematic between encodings as within, and just as problematic as
mixed-CCSID data irrespective of binary or text record transport. If
the transport mechanism is FTP in text instead of binary mode, then to
enable non-text characters to move properly requires the mode to be
block & fixed without trim; I do not recall exactly the what\how, but
the requirements have been discussed in this group and others. And I
surely have some document around to remind me -- if I could find it.
The FTP thread has a post that may have the attributes I am thinking
of; then the same response in another thread:
http://archive.midrange.com/midrange-l/200612/threads.html#01144
http://archive.midrange.com/midrange-l/200612/msg01170.html
http://archive.midrange.com/midrange-l/200608/msg00908.html
Because packed data is binary versus text, well-defined rules for
treating rows as unmodified data and immutable record length would need
to be enforced, to avoid any possible misinterpretation of non-text data
as some type of control information. If both the source and destination
understand clearly that there is an established record length, then pure
binary transport is probably preferred for compatible\homogeneous
systems.
Another msg thread & msgs:
http://archive.midrange.com/midrange-l/199902/threads.html#01402
http://archive.midrange.com/midrange-l/199902/msg01396.html
http://archive.midrange.com/midrange-l/199902/msg01354.html
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.
midrange.com
