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



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


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.