Hi David,
Right now, when I get to the EOF, I am closing (CLOF) the file, and
reopening it... When I do my next read, it says that the file is
still at EOF and I drop out of the program.
CLOF and POSDBF are positioning shared open streams... you know, the
ones produced by OPNDBF or OPNQRYF. They do not work with files opened
and used normally in a CL program. They are only for the "shared open"
thinggy.
The idea behind OPNDBF is that you can pre-open a file with all of the
needed attributes, and keep it open. Programs can then open the file
with SHARE(*YES) and they'll share the same access path, which reduces
memory and improves performance. (It's a technique that's not really
needed on today's faster computers...)
OPNQRYF works on the same principles, except that it manipulates the
access path somewhat by sorting the data in it, or filtering the output,
etc. But otherwise, it's like OPNDBF, it creates a shared open that
other programs can share. Ever wonder why you have to do OVRDBF
SHARE(*YES) before using OPNQRYF? Or why OPNQRYF doesn't work when you
dont' have SHARE(*YES)? It's because without that SHARE(*YES), your
program doesn't try to share the ODP, and therefore uses it's own ODP --
a separate one from the one OPNQRYF has manipulated.
Anyway...
CLOF and POSDBF only work on those shared open files. They don't work
on a normal CL open or close of the file.
CL programs automatically open a file when you first access them. They
automatically close the file when you read past the EOF. There's no
provision in CL to re-open the same file once it's closed. (I feel like
I've said this 30 million times).
Here's an idea for a workaround:
a) Create the *OUTFILE.
b) Use RTVMBRD to determine how many records are in the outfile.
c) Use OPNDBF to create a shared open of the file.
d) Use OVRDBF SHARE(*YES) so your CL program will share the ODP
e) Read the file in CL using RCVF -- as normal -- but be very careful
NOT to ever hit EOF. Instead, use the record count from RTVMBRD to
determine when you've read all the records. As long as you never read
beyond that, the file will remain open.
f) Use POSDBF to position the ODP you created with OPNDBF. Since your
CL program opened the file with SHARE(*YES), this will also position
your CL program's ODP.
g) Read the file again.
h) When you're done, use POSDBF to position to the end of the file,
then deliberately read past the last record of the file to close it.
i) Use CLOF to close the shared open you created with OPNDBF.
Kinda complicated, but it works -- provided that the number of records
in the file is static and predictable.
Another solution is to use CL's support for multiple files (V5R3).
Technically, CL can read up to 5 files. They have the same limits as
the single file support -- but you can potentially declare the same file
on two separate DCLF statements. CL will think of it as two separate
files, but if they refer to the same underlying database table, you'll
effectively read the same file twice.
Alternately, you can separate the logic that reads the file into a
separate program, and call the program twice. Since the program is
unloaded and reloaded with each call, it should have no trouble reading
the file twice that way.
Or, you can simply use an HLL to read the file.
Or if you're looking for a more sophisticated solution... you can use
SQL in Qshell and pipe the output to a data queue, then read the data
queue from CL... that has no limit to how many times you can read it. I
wrote an article about this -- I can look it up if you like.
Or, if you're at V5R4 or later, you can use the ILE C _ROpen(),
_RReadn(), etc APIs to read the file. These are accessible to ILE CL
programs in V5R4 and later.
Or, if you're at least at V5R3, you can use the SQL CLI API from ILE CL.
There are also various utilities out there to solve this problem. They
provide a generic *CMD interface that can read/write files. Basically,
in the end, it's a CL command calling an HLL to do the file access, but
some are very nicely written and are generic enough to work with any
file. I can look up an article presenting one of them if you like...
I've now presented you with 8 different ways to solve the problem... can
you tell I've answered this question many times??
midrange.com
