Re: Report API and Catalog

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.