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



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??

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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

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

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.