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


  1.  Home
  2. RPG400-L
  3. January 2006

Re: Passing a pointer-based array as a parameter



Would that affect your recommendation?  If it doesn't, I'd still like to
know why you advise using dynamic memory allocation.  Is it *that* messy?
Okay, 20000 elements of 30 bytes each, times 50 users, times 2 (figuring that's the average number of times it'll be loaded by each user?) would be around 58mb. Remember, the iSeries will store the stuff that doesn't get much use on disk, and the stuff that's heavily used will be in RAM. Do you think that 58mb where the vast majority is on disk will be a problem on your system?
The only reason I advise against the dynamic allocation is because it's extra work, it's easy to make mistakes that are difficult to debug (especially for someone who's new to it) and it's usually unnecessary when working with so few elements. How much does 64mb of memory cost in comparison to the time you'll spend writing, debugging or maintaining this code?
If you think it's necessary because so many people will be running this program, then go ahead and do it... however, I'd suggest that you hide the pointer logic in a srvpgm or module so that at least the programs that use it don't need to understand the pointer logic. In other words, don't pass an array to the srvpgm, instead call a getElement() subprocedure to get element #56 from the array. Or call a getElementByName() subprocedure that does a lookup based on a value in the array. The calling routines shouldn't know or care that you used a dynamic array, pointer logic, etc to implement it. That's not their problem, it's your service program's problem.

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.