× 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.



John,

I do care about repeated I/O ten million times - I mean I think this is quite an expense to the performance of a program.
I don't care about loading 30k records at initialization of a batch program because that many records would load very quickly on our box.
I don't like storing all the contents of a file in an array when I only need certain fields - to reduce questions like "why is this field loaded if it's not used?" - which is a question I would ask.
In service programs I'm not a fan of the pre-runtime array. This is a style thing, but in our shop we issue a call to an Open...() procedure for the service program to perform any initialization tasks we've coded. That way if there is an error in a job, we can fix the issue (data or otherwise) and force a Retry and the service program, while still active, will "re-initialize."

I don't mean to be confusing. I guess I opened up the world when I said, "or is there a better idea?" I really only wanted to whine about the lack of complete functionality of data structure arrays. That is to say, I'm a huge fan and use data structure arrays a lot now, but it's a bummer that I can't use the binary search functionality of %lookup with them. I was really hoping someone would say, "Oh, what you need to do to get that to work is [this]" and I would slap my head and say "D'oh!" Unfortunately that doesn't seem to be the case in this situation.

-Kurt
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of John Yeung
Sent: Thursday, November 10, 2011 5:20 PM
To: RPG programming on the IBM i / System i
Subject: Re: %lookup on a Data Structure Array

On Thu, Nov 10, 2011 at 5:13 PM, Kurt Anderson <kurt.anderson@xxxxxxxxxxxxxx> wrote:
I know we have programs that use [table files].  But it has to then
load the entire table, when I only want two fields. Honestly I'm not
concerned about the speed here.

Well, if you're not concerned about the speed, why are you bothering with ANY of this? Why not just chain to the file every time you need it?

If you mean you are concerned about repeated disk I/O but you're not concerned about the *initial load* speed, then what's the harm in reading the whole file? You only have to do it the one time right at the beginning, and from that point on it's in memory.

OK, so it takes more memory than it has to, but then in another message, you say you're not concerned about the memory usage (because you're perfectly fine with allocating 100K array elements to store 10K or 20K, and typically much fewer than that).

So I'm having a hard time figuring out what exactly you don't like about the table file technique. I'm not saying it's the best technique in your situation, and you are free to reject the idea on any grounds whatsoever. You could even say "I don't like table files because they are too old-school" or "Bob in the next cubicle loves table files, and he's a total moron with an attitude and I hate his guts, so I wouldn't be caught dead using his pet technique". Those things, while not exactly rational, I can actually understand. I don't understand "I won't use table files because I don't care about speed and I don't care about memory, except when I do care about memory".

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


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.