Gary, I guess my question about all this is why are messing with this. As I
understand this, you are opening a text file, parsing the data and writing
to a DB file.

Why not just do in an RPG program where you have full control and error

I would be happy to send you example code showing you opening a directory,
reading the directory, processing a file, parsing the file and writing to

On Fri, Dec 26, 2014 at 1:44 PM, CRPence <CRPbottle@xxxxxxxxx> wrote:

On 26-Dec-2014 09:21 -0600, rob@xxxxxxxxx wrote:

You are trying to convert from an IFS file to a DB file.

So perhaps just use Copy From Import File (CPYFRMIMPF); i.e. use the
Import utility, to _import_ the [likely previously exported] text data into
a pre-created database file member.?

Therefore the IFS file (by that I assume you mean a stream file
outside of the QSYS.LIB file system) already has its "number of
records" determined. <<SNIP>> And stream files have no
concept of 'records'. <<SNIP>>

A text stream [a STMF of text data] has the concept of records; only a
binary stream would not support the record concept, except perhaps a
logical fixed-length representation. The problem however is much like with
any /flat-file/, what defines the data determines also what defines the
/records/ of the file; that could be a logical record length, an
End-Of-Record (EOR) delimiter [of some number of bytes\characters], or
whatever the programmer might dream up. The /convention/ however, is that
the /record/ is what is delimited by the conventional *EOR; typically that
is the <CRLF> or <LF> and according to the convention of the OS wherein the
program /wrote/ the text file.

<<SNIP setup for test.txt with three ['3'] records>>

So now I see you are looking to retrieve that '3'.
So, when I run
qsh cmd('cat /rob/test.txt | wc -l')
in an interactive session the following displays on the screen:
Press ENTER to end terminal session.

When I run
qsh cmd('cat /rob/test.txt | wc -l')
in a batch session.
SBMJOB CMD(QSH CMD('cat /rob/test.txt | wc -l'))
Job 420557/ROB/QDFTJOBD submitted to job queue QBATCH
wrkJob 420557/ROB/QDFTJOBD
4. Work with spooled files
I get a spool file with one row displaying 3 in it.

Run interactively, with a prior override to Standard Output (STDOUT), is
discussed in other replies. The override of the StdOut could be to either
a database file [Override With Database File (OVRDBF)] to cause the output
to be directed to a row of a database file or a printer file [Override With
Printer File (OVRPRTF)] to cause the output to be directed to a record of a
spool file.

I tried a few things
qsh cmd('cat /rob/test.txt | wc -l > /qsys.lib/qtemp.lib/mydtaara.
Command ended normally with exit status 2.

The previously discussed _datarea_ utility [in other replies] would be
used to write to a *DTAARA object. And although the stream file read\write
capabilities do not directly support the Data Area object [thus why the
datarea utility would be used to effect that], there is support for the
User Space (USRSPC) object type. Properly identifying a *USRSPC object
with IFS naming and the use of a permanent library name could succeed
without errors; a side bonus, is that the automatic creation of the User
Space object occurs, so there is no requirement to pre-create the object as
with a DBF member. So for example:

'cat test.txt | wc -l > /qsys.lib/rob.lib/myusrspc.usrspc'

qsh cmd('cat /rob/test.txt | wc -l > /qsys.lib/qtemp.lib/mytable.file')
Command ended normally with exit status 2.

Nothing wrong with the above, at least conceptually. The issues with
what was tried however, are with each of: the use of QTEMP, the failure to
identify a "file" [in the non-/QSYS.LIB sense; i.e. distinct from the
*FILE] as target for the data rather than a directory [must specify a
member as target, not a file], and the database *FILE object must be
pre-created. The database *FILE [object type of the /QSYS.LIB],
functionally serves as a directory within the IFS nomenclature, not as a

qsh cmd('cat /rob/test.txt | wc -l > /rob/RecordCount.txt')
Command ended normally with exit status 0.

So directing the output to a data area or a db2 file wasn't going to
happen. Directing it to a stream file was OK though.

Which leaves you a couple of choices.

Hopefully my prior comments help elucidate, so as to suggest the choices
are not so narrow as might have been implied by the quoted text.

Regards, Chuck

This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives

This thread ...


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

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