On 3 December 2010 13:55, David Berry <[log in to unmask]> wrote:
> On 3 December 2010 12:07, Brian McIlwrath <[log in to unmask]> wrote:
>> I have been looking at a problem that Malcolm has with looping monoliths
>> growing the HDS temporary file into the Gb territory. While there is
>> likely to be a problem somewhere deep in the system the obvious thing to
>> do, in the short term, seemed to be to recreate the temporary file at each
>> run of the monolith.
>>
>> This has hit a snag in the way people are using top level temporary file
>> locators! The first call to DAT_TEMP creates the file and a structure TEMP_1
>> to create the structures under. Subsequent calls use the same file but
>> create structures TEMP_2, TEMP_3 etc. etc.
>>
>> When an example monolith (COLLAPSE - KAPPA_MON) completes its first
>> iteration there are 58 HDS locators left active!
>>
>> These break down into
>>
>> 8 related to the parameter file and connected to kappa_mon.sdf
>> 1 related to ARY (ARY_TEMP)
>> 49 of type STARLINK_PROV
>>
>> The last 50 locators refer to the temorary file.
>>
>> If I annul these "top-level" locators FROM HDS then higher level software
>> gets upset. I have traced where ARY creates ARY_TEMP and I think I could
>> solve this one myself - if necessary!
>>
>> Any thoughts on how to get rid of the STARLINK_PROV locators??
>
> Hi Brian,
> I've fixed a bug in the NDG library that caused
> STARLINK_PROV structures to be leaked. Could you check it out and see
> if the problem goes away?
>
> Meanwhile, I'll look at the ARY problem.
Hi Brian,
Can you give me a command line and a data set that
demonstrates the ARY problem? Trying collapse out on a random data set
doesn't show any problem (i.e. all locators issued by dat_temp are
annulled before exit).
David
|