Re: Problem with an SQL View that has selects/omits

James H. H. Lampert wrote:

I've now got an MI implementation of the "iteratively SETLL until
a record (or EOF) is found" in the initial testing stage, but
I've got a problem.

The concept works just fine if I know the read is going to fail,
and go straight to the iterative SETLL gambit before attempting
to read a record, but when I actually let the READ operation fail
(whether in RPG or in MI), the first SETLL operation throws a
CPF5129 ("I/O is not allowed because the program device or member
. . . is in error")

Anybody know how, short of closing and reopening the file, to
reset that state?

Since the msgCPF5129 is really just an indication that the LIC temporary cursor [the LIC portion of what is the ODP] was already deactivated\destroyed due to the error. There is no recovery other than to open the file again; of course after closing the current open to remove the CPF [i.e. non-LIC] activation\open; i.e. to null its pointer in the UFCB and IIRC to also reclaim the entry from the list of open files and remove the locks of the file & data.

Or does anybody know of a flag in the FIB, or the Open Feedback,
or someplace similar, that will tell me it's an SQL VIEW instead
of a DDS LF? It's been a few years since I was in those
structures last (I think it was when I figured out how to do RLA
reads of files containing SQL-only fields without crashing).

I do not recall what is where, and I have no access to any systems where I could find out even if I were so inclined.

Since the Data Management enables POSITION(*START) on the open, there is surely that option available in the UFCB.?

Regards, Chuck