An explanation to mproblem with long reports with ReportWriter and &SQL

From: <jaakola_at_cc.helsinki.fi>
Date: 24 May 92 12:20:20 GMT
Message-ID: <1992May24.142020.1_at_cc.helsinki.fi>


A while ago I posted my experiences with SQL*ReportWriter 1.1.8 on RDBMS 6.0.27 on Unisys UNIX 3.00 12.15: if I output a very long report having fields with source &SQL, the memory image of the runrep process grows by 1 MB for every 100 K I output.

Mike Kavanaugh from Oracle New Zealand emailed me (thanks, mike!) about a "feature" in the malloc() and free() functions of AT&T's SVR3 unix: when you allocate small pieces of memory with malloc() and try to free() them later, the memory space won't be available for reuse! This bug exists in some AT&T-based UNIX ports; Unisys fixed it in version 3.00.13 and I just happen to have an earlier version. Nowadays AT&T (or USL or whatever name their labs now have) distributes version SVR4 - I hope they have fixed the "feature".

I have experienced similar memory image growth with the cron daemon. I had an application which used cron (via the at and batch commands) extensively and the memory image of the cron process grew without bounds. The work-around then was to kill cron every night...

Also mike reminds me of the fact that the 6.0.27 was not ported by Oracle for the Unisys platform. The newer versions are ported by Oracle.

We will upgrade the OS and Oracle in near future.

But no one has replied to my question whether anyone has run successfully long reports with &SQL-fields. I have successfully run a report using (few) &SQL fields producing a 450 K output file on a 4 MB RAM PC with ReportWriter 1.1.12 with remote database.

--
Juhani Jaakola, jaakola_at_cc.helsinki.fi
Received on Sun May 24 1992 - 14:20:20 CEST

Original text of this message