Financials, Disk-space leak!

Env: HP-UX 9.04, Financials 9.4.2, DB 7.0.13.murmer

When a user goes into Journals. Enter, selects a batch, selects a journal entry, then the lower zone (Journal Entry) returns the first of the many rows available.

Pressing [next row] repeatedly, displays a number of rows, as one might expect.

HOWEVER, something has opened a temp file in /usr/tmp, and unlinked it while open. This file grows rapidly, and is huge. Scrolling thru the first 3000 rows (as described above) produces a file of ~27M. Here is the kicker: since it unlinked, you can't see it using ls. The only way to detect it is to watch as 'df' reports 0 free space in /usr. If you then run 'du' against /usr, you'll find that the amount of space du thinks is in use is considerably less than what 'df' thinks. The only way to reclaim the space is to end the process writing the "mystery file". So far our users have decided to take matters into their own hands with the [BREAK] key, then logging out of Financials. When they exit Financials, and not before, the disk space is reclaimed.

Q1) Is this documented behaviour?
Q2) Can the path to /usr/tmp be respecified? If so, where? (Yes, I have considered creating a separate filesystem to be mounted over /usr/tmp, but who has those kind of resources sitting around?!?)

Observation: While unlinking open files assures that they will be deleted when the process that created them ends (regardless of how process terminates)  it is very poor practice to have something consuming large amounts of system resources that cannot be easily tracked and monitored.

--
Lynn Osburn 
losburn_at_omcssi.com 
REAL men don't use porn.