Ah yes - I think these might be more efficient but I don't have any performance statistics. They use the same routines in data management at the lowest level.

It might be more efficient if _Rlocate is not a full read - if it reads only the index and not the physical file, as well. It looks like it is similar to SETLL with more and repeatable options. SQL can do this, too, where RPG doesn't have this option, as I recall.

Someone wrote once that there are 3 rules of optimization - Don't! Don't! Don't! His reason was, that optimization usually means using "cute" techniques - special tricks - that are not well-known and make maintenance more difficult, for very little benefit as a result.

Kent Milligan, of IBM, would say, I think, that SQL is faster than RPG for this kind of thing, especially if you have the right index - and here you have the exact index. In this case, SQL may use ONLY that index to get the count.

So I might change my thinking - but I still tend toward simpler code, rather than more complex code with very little benefit. Maybe you can do a test - to make it fair, be sure to CLRPOOL of the PF and the LF or index.

Good luck!
Vern

On 3/23/2012 8:20 AM, Vinay Gavankar wrote:
The reason I asked about these functions was I am trying to modify an
existing program, which is written in free format and is using these
functions. I "assumed" that these functions were more efficient than
regular RPG commands. If that is not the case, I would rather use RPG or
SQL, if that is more efficient. It might look "funny" having a block of
code written in a different style in middle of a program, but it should not
be an issue.

Thanks

On Fri, Mar 23, 2012 at 8:12 AM, Vern Hamberg<vhamberg@xxxxxxxxxxx> wrote:

Hi Mike

Nice sample code - but it is C/C++. Vinay is working in RPG already -
for HIM there is no reason to go through the extra work required when
using these function - _Ropen, _Rformat, _Rclose, at least, right? (If
those are not needed, well, it's been a long time since I used these
functions.)

The _R* functions give you RLA in C/C++ - and there are even some
operations supported there that are not in the RPG panoply.

Using these functions IN RPG source would not look so simple as your
example - DOW/ENDDO is going to have more code to it - and Vinay might
just as well use READE and recordCount += 1;

RLA in C/C++ does have its place - obviously, if you don't know RPG and
are a C/C++ shop. One other place is when you need to work with the
buffers. Another is working in some generic sense with null-capability,
where RPG has some restrictions.

But in general, in my experience, support for RLA in C/C++ is an
accommodation, not really amenable. JMHO!

Bottom line - use RPG (or SQL here) for what it is really good at - and
the same with C/C++ - shoehorning one into the other is an exercise in
frustration.

Vern

On 3/23/2012 2:07 AM, Mike Bardin wrote:
On Wed, 21 Mar 2012 19:26:18 -0400
Vinay Gavankar<vinaygav@xxxxxxxxx> wrote:
Hi,

Where can I find any documentation about what procedures are
available in
QC2LE directory, and maybe how to use them?

I came across a program, which was using prototype called _RLocate
to get
the RRN of a record based on a key from a keyed logical file.

I wanted to get the total number of records in that file which have
Key
equal to a particular value.

Any information would be helpful.

Thanks
Vinay
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L)
mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

/*
variables: filePointer, keyValue,keyLength,recordCount
*/

recordCount=0;
_Rlocate(filePointer,NULL,0,__START);
while
((_Rlocate(filePointer,&keyValue,keyLength,__KEY_EQ))->num_bytes)
recordCount++;
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.



This thread ...

Replies:

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

This mailing list archive is Copyright 1997-2019 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].