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