|
If you are at V5R1 you can use the free form bif %lookup with a dynamically allocated array to locate elements if you wish. On Fri, 26 Jul 2002 09:56:15 -0700 "Joe Lee" <LeeJD@ah.org> wrote: >Well, your scenario may not be as exaggerated as you >think. I have a >program that has a dynamically allocated array of >pointers to data >structures containing a "name" variable, a pointer to a >null terminated >string, and a couple of pointers to linked lists of data >structures >containing pointers to null terminated strings. > >A dynamically allocated array where the array has the >potential to have >a large number of elements or where the elements are very >large is the >perfect example of when to use allocated memory. Of >course you can't >use LOOKUP with a dynamic array, but if you have an array >large enough >to need dynamic allocation you probably don't want to use >something as >slow as LOOKUP anyway. > >There are only twp problems with using allocated memory >that I see. One >is that a large portion if not most RPG programmers are >not familiar >with it. And if you use it you have to be careful to >deallocate it when >you are done with it. > > >Joe > >>>> acassidy@pioneermetals.com 07/26/2002 09:20:04 >>> >Wait. If you have a much-used program, that uses an >array, for example, >say >len(5000) (to match, say a record format, yes, we've got >'em, you too >probably), and depending on selections this can go >anywhere from zero >or one >to maybe a 2 thousand, go dim(2000), now you're using 10 >meg of CPU. >Say >you're getting twenty users signed on at once. Wouldn't >this be a >reason? Or >why not? > >I know the scenario is an exaggerated stretch, but please >humor me, as >I >remember thinking sometimes in a case like this I might >want to >allocate >memory this way.. This is not to detract from the thrust >of your >point, >which seems to be that they trying to duplicate >C-functionality into >RPG. > >Come to think of it, why is it in C? > >--Alan > > > > >----- Original Message ----- >From: "Justin Houchin" <justin@RELIATEK.COM> >To: <rpg400-l@midrange.com> >Sent: Friday, July 26, 2002 11:56 AM >Subject: RE: Reason for allocating memory > > >> So if I understood you correctly, allocating memory is >>related to >the >> "C" programming language? >> >> -----Original Message----- >> From: rpg400-l-admin@midrange.com >[mailto:rpg400-l-admin@midrange.com] >> On Behalf Of Jon Paris >> Sent: Friday, July 26, 2002 10:50 AM >> To: rpg400-l@midrange.com >> Subject: Reason for allocating memory >> >> >> Could someone tell me the reason they would >>dynamically allocate >> memory. >> >> Because while at least trying to produce a working >>example in RPG, >the >> people who wrote it were completely clueless about the >>language and >> effectively translated C logic into RPG wherever they >>found a >matching >> function. >> >> I hate to say this because they are on of the few groups >>in the whole >of >> IBM >> that realize that we don't all program in C but .... >> >> There is no reason why a regular RPG variable 256 long >>could not be >used >> instead of the method they used. Same applies to a >>whole bunch of >other >> allocations and similar silliness. >> >> Jon Paris >> Partner400 >> >> > >_______________________________________________ >This is the RPG programming on the AS400 / iSeries >(RPG400-L) mailing list >To post a message email: RPG400-L@midrange.com >To subscribe, unsubscribe, or change list options, >visit: >http://lists.midrange.com/cgi-bin/listinfo/rpg400-l >or email: RPG400-L-request@midrange.com >Before posting, please take a moment to review the >archives >at http://archive.midrange.com/rpg400-l. > <TEXTAREA NAME="Signature" ROWS="4" COLS="60"><TEXTAREA NAME="Signature" ROWS="4" COLS="60">
As an Amazon Associate we earn from qualifying purchases.
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.