Re: Must I use OPNQRYF

I had some big level break programs I didn't want to change. I used a
"special file" to use sql to return the records to the main program. works
great for me. Only needed to change 1 line in the program, the file spec,
and build a little rpg program to do what the opnqryf (or gsort or #gsort)
did before.

------------------------------

message: 2
date: Mon, 20 Feb 2012 14:01:11 -0600
from: Scott Klement <midrange-l@xxxxxxxxxxxxxxxx>
subject: Re: Must I use OPNQRYF

Hi Dave,

I don't see why an SQL statement wouldn't work?

Is your concern that you don't want to change the RPG program? That's
about the only area where OPNQRYF has any advantage over SQL. OPNQRYF
can be completely transparent to the RPG program, whereas to do SQL
"right", you'd have to rewrite the RPG program to read the records via
SQL instead of native I/O.

Of course, one workaround might be to use SQL to write the data to a
temp file in QTEMP, and then make the RPG read that temp file. But, that
less elegant than OPNQRYF.

To me, SQL should be used when you want an (arguably 'better')
alternative to native I/O. Whereas, OPNQRYF is used to supplement
native I/O. If I were rewriting the RPG program, I'd definitely use SQL
instead of native I/O. But, if I'm not rewriting the RPG, and just
rewriting the front-end, SQL seems like a kludge.

Hope that makes sense.