On Wed, 25 Jan 2006, Peter W. Draper wrote:
> On Wed, 25 Jan 2006, David Berry wrote:
>>>> This API is limited to returning global information about HDS. If it had
>>>> an HdsLoc argument it could be expanded at some point in the future if
>>>> necessary to also return information about a specific locator. That would
>>>> make it even more like grpInfoI.
>>> Just wondering what extra information, about a locator, you might like to
>>> see. The full name and path can be obtained by DAT_MSG, and that's about
>>> all I can imagine would be useful (in addition to the proposed info). The
>>> internals of the various structures look less useful. (or also can be
>>> gotten though queries on a locator, name, dimensionality etc.).
>> The suggestion was mainly because including a locator parameter would
>> provide for future expansion. Off the top of my head, what about enquiring
>> the number of primary locators associated with the container file?
> I see, in fact that does look essential for "FILES" to have any useful
> meaning. A reference count without a locator instance wouldn't mean much.
As a first stab, something for hdsInfoI is now in place. It still only has
the 3 arguments (not a locator), but it's a start.
LOCATORS: Number of active locators
FILES: Number of open container files
I don't really know enough about HDS to know what to do with a locator
but I can add it as a placeholder if that's the API-of-the-future.
Just tried it out on an ADAM task (to see about leaks) and it's
essentially useless because on exit from the action the locator count
invariably goes up because the parameter system does not annul its
locators. So you simply find out that you got 3 new parameter locators
during the action...my enthusiasm is waning.