Re: Must I use OPNQRYF

On 20-Feb-2012 04:12 , Vern Hamberg wrote:

Anywhere you can use OPNQRYF, you can easily use SQL. <<SNIP>>

You could also create a general-purpose SQL statement processor to
use in CL that'd create an OUTFILE with the selected records. That
processor would use QM queries - query management queries (QMQRY
object type). <<SNIP>>

Yes, not as pretty, <<SNIP>>

If an output file as a temporary copy of all the selected rows is acceptable, versus just using a query ODP, then a CPYF to select the rows in the CLP before the HLL is much simpler than the snipped and far-from-"pretty" QMQRY stuff. A custom QMQRY with just the specific [product code] value to be selected, as specified on the SETVAR, would be much clearer. The report might better be accomplished using a QM report instead of RPG; i.e. just eliminate the RPG from the scenario of the OP.

<<SNIP>>

Oh yeah, why stop using OPNQRYF? Things like the JOINFLD parameter
allow only an INNER JOIN - that's one example of how OPNQRYF doesn't
have the flexibility of SQL - just like Query for i has limitations.
They are both excellent methods with limits as chosen by the product
designers and developers at IBM.

Logical files and OPNQRYF both enable OUTER join with "join default" specifications; see the help text on OPNQRYF:

"
Join with default values (JDFTVAL) - Help

Specifies whether the query file should include join records
that use default values for any of the fields from a join
secondary file that does not contain a record with correct
field values that satisfy the join connections specified
on the Join field specifications (JFLD) parameter.
"

IMO the "stop using OPNQRYF" arguments are little better than "stop using RPG" arguments. In either case, the best argument in support, is generally the effect of learning something new\different. The scenario of the OP almost screams for the use of OPNQRYF to minimize the amount of [re]work; i.e. the RPG can remain unchanged. Suggesting to avoid the OPNQRYF in that scenario seems a redirection away from the obvious, though detailed intentions by the OP were lacking.

Regards, Chuck