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:

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:

Regards, Chuck

This thread ...


Return to Archive home page | Return to MIDRANGE.COM home page