|
>>> 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. What do I need to do if my programs errors out before the DEALLOC statement? I just had this happen. -----Original Message----- From: rpg400-l-admin@midrange.com [mailto:rpg400-l-admin@midrange.com] On Behalf Of Joe Lee Sent: Friday, July 26, 2002 11:56 AM To: rpg400-l@midrange.com Subject: Re: Reason for allocating memory 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.
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.