|
>From: Joe Lee [mailto:LeeJD@ah.org] >...when the program ends the 400 will clean up all the memory it was using. I may be mistaken (wouldn't be the first time) but I don't believe that is a true statement. When the jobs ends, maybe, but not when the program ends. If you have a program that is used in a long running job that may be a problem. Regardless of what cleans up memory when it's still always a good idea for the programmer to release memory when it's no longer needed, it tells programmers that follow, "Hey, I'm done with this, I don't use it somewhere else" -Walden ------------ Walden H Leverich III President Tech Software (516) 627-3800 x11 (208) 692-3308 eFax WaldenL@TechSoftInc.com http://www.TechSoftInc.com Quiquid latine dictum sit altum viditur. (Whatever is said in Latin seems profound.) -----Original Message----- From: Joe Lee [mailto:LeeJD@ah.org] Sent: Friday, July 26, 2002 13:47 To: rpg400-l@midrange.com Subject: RE: Reason for allocating memory I don't believe that will cause a problem since when the program ends the 400 will clean up all the memory it was using. The deallocating of the memory is more important while the program is running. For instance in my program I am creating and destroying the data structures fairly regularly, when I get rid of a data structure I need to be sure that all the memory that was allocated for it is deallocated. Failure to deallocate the memory probably wouldn't be a problem for a program that only runs for a short period of time, but if the program runs for an extended period, in my case it is a CGI service program that returns with LR off and stays in memory as until the web server job is ended, then the memory leaks could become significant. Hans or Barbara could probably give a more detailed answer about what happens when memory isn't deallocated. >>> justin@RELIATEK.COM 07/26/2002 10:22:32 >>> >>> 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.