× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Thanks for the warning... I read that on IBM's site.

The interface that populates this string ensures that
1. It is completely filled out with dates
2. They are actual dates
3. They are ascending

This is a file that controls the operation of our Accounting System.
So unless I have data corruption - I should be good. The index of the array corresponds to beginning date of the fiscal period.

I'll file this piece of information for future use.

-----Original Message-----
From: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxxxxxxxx] On Behalf Of John Yeung
Sent: Thursday, May 02, 2019 4:43 PM
To: RPG programming on IBM i <rpg400-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: Looking for free format equivalent

On Thu, May 2, 2019 at 3:51 PM Greg Wilburn <gwilburn@xxxxxxxxxxxxxxxxxxxxxxx> wrote:

My problem was twofold
1. I was using SQL to retrieve the string - you can't do that
directly into RA0094 2. The array needs ASCEND or DESCEND to use
%lookuple

Since you said you're converting from the old LOOKUP opcode, you should be aware of another difference between it and the BIFs: The opcode searches sequentially; the BIFs use binary search. Which means you have to make sure of two things when using the BIFs: First, the data needs to ACTUALLY be sorted (not just *declared* sorted). Second, which is actually just a stricter expression of the first, if your array isn't "full" then you have to be sure to specify the "startindex" and "numelems" parameters when you do the lookup, or you have to fill any trailing array elements with *HIVAL beforehand. Or just sort the whole array with SORTA.

This has bitten me more than once. One common efficient-seeming pattern for building an array is by reading in sorted values. Figuring that the data going in is already sorted, there's no need to use SORTA afterwards; that would just be redundant. But it wouldn't, if you don't have enough values to fill the array. You can get away with this bit of sloppiness with the opcode, because it searches sequentially.
But binary search will be screwed up by this. (If you take the time to work out why this is, with pencil and paper if necessary, you will etch it into your brain and be much less likely to be caught out by
this.)

John Y.
--
This is the RPG programming on IBM i (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: https://amazon.midrange.com

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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

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

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.