|
Completely agree with your "don't try to save a few cycles at the expense of readable code". My main concern was using this in a web app where the app will open, fill in the structure, send the results and then close and could be doing that a lot if it gets used as I hope. If it was an app that ran once or twice a day I would not even consider it. If it gets a couple of hits a minute that might be a different story. And doesn't OS/400 have to load the entire app when it is started even if some code pages might later get swapped out if not used? Static storage size is 5,206,080 and Program size is 1,806,336 for this app and I was concerned about the load time. And in this particular app I actually have an array and a MODS. I load the array because I then sort the data before loading it into the MODS. Then send the MODS as the results set. I do already keep track of the number of elements and set the result set size to the actual number of elements.
rpg400-l@xxxxxxxxxxxxxxxx 12/15/2006 2:45:41 PM >>>
Hi Mike,
Is there any trick available to create a multiple occurrence data structure and define the size at run time?
[SNIP]
my application is used as a stored procedure that returns a result
set
and so I can't use arrays.
The "SET RESULT SET" SQL statement can specify the number of rows to return. For example C/exec sql Set Result Sets Array :MYMODS for :COUNT Rows C/end-exec Your program will have to keep track of how many elements you've loaded into the MODS and set the number of rows (in the COUNT variable in my example, above) appropriately. As far as how many occurrences exist in your MODS, I strongly recommend that you allocate all 1000 of them as a normal MODS. The unusused occurrences won't matter. The amount of memory they occupy won't have any significant impact on the system. It's possible to base your MODS on a pointer, and allocate only as many as you need -- exactly the same way you do it with an array -- but there's really no value to doing so (either with a MODS or an array!) if you only have 1000 elements. You can hurt the performance of your program, and make a program that's very difficult to maintain, using techniques like this. Sure, you may save a few kilobytes or even megabytes of memory, but who the heck cares about that? The iSeries will store unused portions of your program on disk, only loading it into memory if nothing else needs the memory. So the amount of memory you use really doesn't have a sigificant impact. Certainly nothing worth the cost of making your program hard to maintain!! Even if the memory usage is a problem, big deal. Buy another 512mb memory module for your system. What does that cost? $300 or something? By comparison to the extra days it'll take you to write and debug yoru program, and by comparison to the years of extra time maintaining your program, the cost of an extra memory module is extremely cheap. Don't create a maintenance nightmare over a couple of kilobytes!
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.