<snip>
May be true, but I'd argue that if the OP could take the time to learn it
they would not see it as throw away knowledge for this one project and would
soon be using it on a host of other stuff.
</snip>
Which is often the case with me. I am so used to use RLA to access files
that oftentimes, after I get a program in production, I wind up smacking
myself upside the head, "Wow, I coulda done that with SQL; and probably
better." I wasn't all that great with RLA either until I kept digging.
Too often we (meaning "I") use the tools which we are used to whether it's
RLA, OPNQRYF, Query or whatever, because there's always time crunch. I've
got to get out of that mode; it's mostly self-imposed, anyway.
Jerry C. Adams
IBM i Programmer/Analyst
Luck is the residue of design. -Branch Rickey
--
A&K Wholesale
Murfreesboro, TN
615-867-5070
Rob Berendt
--
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
From: CRPence <CRPbottle@xxxxxxxxx>
To: midrange-l@xxxxxxxxxxxx,
Date: 02/20/2012 12:55 PM
Subject: Re: Must I use OPNQRYF
Sent by: midrange-l-bounces@xxxxxxxxxxxx
On 20-Feb-2012 02:46 , Dave wrote:
I have an RPG called by a CLP. It just reads a file and prints a
report. The file existed in several different libraries, now all
the files are fusioned to make one big one with a product code
field added to be able to distinguish between the different
records. I will probably just add an OPNQRYF to select the
records with the right product code.
Difficult to beat the simplicity of inserting an OPNQRYF to perform
the necessary selection via QRYSLT, and share that query ODP with the
unchanged RPG program in that very simple scenario. While an
effectively identical CPYF could be just about as easy, that involves
making a temporary copy of the data which is generally undesirable.
Some other fairly simple alternatives would be if the report both can
be generated and replaced easily by a utility having eliminated any HLL
beyond the CLP, or if collation was moot such that a dynamically created
VIEW could be used instead of the dynamic query ODP, or if the RPG were
changed to choose the specific format of a MFLF which defines each of
the hard-coded product code selection [with DYNSLT to have just one
keyed AccPth]. The latter could be accomplished similarly by separate
single-format logical files, and any LF could be created dynamically
from source into QTEMP or duplicated from a /model/ file to persist only
during run-time if the permanent logical files were not desirable.
I don't think I could easily use SQL here, but am I wrong?
Almost surely the SQL can easily be used in such a scenario...
however, that the question was even asked, seems to imply not so simply
or easily for the OP. To be clear, there is no OPNSQLF :-( While this
scenario would probably make for a good SQL learning experience for a
beginner, if there is any urgency in getting the change implemented,
then the very simple OPNQRYF might be the best first-approach to resolve.
Regards, Chuck
midrange.com
