Re: Report API and Catalog

["Aaron Bartell" <aaronbartell@xxxxxxxxx>]

So here's my question:

If the memory is being allocated in rptOpen() for the pointer being passed
back, wont that pointer's data be "free for the taking" being that the call
stack entry that allocated it has been "removed"?

I have always been of the mind that the calling program needed to
pre-reserve memory when pointers are involved?  I just ran into this last
week with a customer who was communicating with MQSeries and didn't %alloc
before call MQ_GET(spelling).  When the call returned everything looked fine
until he executed some more code and those lines of execution starting
stepping into that pointers space because he didn't %alloc before calling
MQSeries.

Aaron Bartell
http://mowyourlawn.com

On Tue, Jun 3, 2008 at 3:10 PM, Nathan Andelin <nandelin@xxxxxxxxxxxx>
wrote:

> > Roger Harman wrote:
> > I'd really like to see an article or other info on those OO
> > techniques.
>
> Briefly consider a statement like:
>
> report.object = rptOpen('XCD500');
>
> Behind the scenes, rptOpen() creates a new instance of a report object
> and returns a pointer to it.  The object has a bunch of properties (an
> integer for storing the number of pages, a string for storing the name
> of the output stream file that's created, and so forth).  One or more
> HTML files associated with the report ID are loaded into memory, and
> parsed into records and fields.
>
> Since you never know how many records or fields there may be in an HTML
> file, rptOpen() allocates memory dynamically for each, and links them
> together in a chain (linked lists).
>
> The pointer returned by rptOpen() becomes a basis for referencing every
> other object in the chain.
>
> In a program that generates multiple reports, you can call rptOpen()
> multiple times.  New report objects are dynamically instantiated with
> each call.
>
> rptClose() destroys all objects created by rptOpen() and frees related
> memory.
>
> The thought process may be somewhat non-traditional, but RPG is still
> well suited for it.
>
> Nathan.
> --
> This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
> To post a message email: WEB400@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/web400
> or email: WEB400-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/web400.