×
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.
On 17-Jul-2014 10:13 -0500, Richard Reeve wrote:
I need to build an extract file from the I that will end up being a
pipe delimited text file. My issues are as follows;
Given this is the RPG list, perhaps the question is directly only,
for how to accomplish the task using RPG [file I\O]? If so, then the
rest of my reply is probably not of interest.
1. There are multiple record types (with unique formats per record
type).
Is that defined as multiple Record Formats of a DDS Logical File
(LF), or perhaps of separate LFs? Or does that describe what is
effectively a Multiple-Format Physical File (MFPF), a file that could be
defined with the Interactive Data Definition Utility (IDDU) using
"Record Id Codes" but not with PF Data Description Specifications; a
definition of record data that often is restricted to being described
only by the program(s), due to the inability of the underlying database
support being so flexible?
2. The delimited file needs to be ordered by employee and record
type
The database export utility, the Copy To Import File (CPYTOIMPF)
command, added the capability to specify an ORDER BY clause.
While such data of varying formats\layouts probably could be exported
into _one_ text file, the import of that data from one text stream may
be somewhat problematic if the variability of the formats can not be
represented generically across the records of delimited data. The Copy
From Import File (CPYFRMIMPF) utility would certainly be challenged to
import the data from one Stream File (STMF) without multiple passes or
with use of an INSTEAD OF trigger on a VIEW.
I am struggling to come up with an efficient way of doing this. Any
thoughts or suggestions would be much appreciated.
Given the physical descriptions, both of the file [possibly
program-described, defined with only a Record Length (RCDLEN) attribute
to define the Record Format (RCDFMT)?] and of the data layout for each
"record type", plus any existing logical file [DDS LF or VIEW]
definitions over the data, then a reviewer might be able to offer some
specific ideas rather than either very high-level suggestions or
possibly even recommendations that are incompatible with the situation
due to their lack of understanding the scenario. I am for example,
firstly not entirely sure I understand what is implied about the data
layout, and secondly unsure if\how that data is defined to the system
_outside of a program_ such that the database [and various utilities]
would even have any clue about accessing the columnar data by [field] name.
midrange.com
