Re:

Neil writes:
> I had a quick look at the root files of various databases.
> The number of records seems to vary (from 7 to 47).
> Perhaps it has something to do with the number of datasets and items in the
> database ?
> I don't know, but I know who does :)
>
> Anyway, my point is that the root file already has a variable number of
> records, so maybe H-P can just allow more records, each type vendor
> specific, and get away without a major change to the rot file structure.

Neil's correct...there is no "size" for a root file for HP to increase.

The enchilada subcomittee was presented with a number of viable, and
not so viable, alternatives.  They didn't come to any conclusions.

Asking HP to "change the size of the root file" isn't a useful approach to take.

Instead, it would probably be better to recap what kind of changes were
proposed, and the storage suggestions/requirements/implications thereof.

For example, we know that there are two basic kinds of additional
information we'd like to store with a database:  small amounts, and
bigger amounts.

For small amounts, it's quite feasible to simply append data to the
end of the root file.  For this, HP *already* has an ideal solution.  They have
code to locate/access variable size data chunks, this code is part of the
jumbo dataset code.  (HP hint: look at ccui_find_chunkset, and imagine
it starting not at byte 0, but at a byte whose address is found in a previously
unused word in the current root file header, and that it searches not for
eh_id_jumbo, but for some passed-in-parameter id).

For large amounts, the question becomes more of a philosophical one:
do we want to hide the data from existing programs?

If we added large chunks of data to the root file, that would be largely
invisible to existing utilities (e.g., file copiers, database purge/rename tools,
backup utilities).  If we create a new file (or set of files) that has a *major*
impact on such utilities.

My contention is that for *large* amounts, using the root file
is inappropriate *and* using an HP-defined new file is also inappropriate.
Rather, I suggest that large amounts of data (say, vendor-implemented
BLOBs?) be stored in a separate file(s), and that the expanded root file be
used to simply record the *names* of those files ...in a manner clearly
documented for use by utility authors.  (E.g., you really want backup
products to backup associated files!)

What kind of data do I want to see in the root file?   (Via the
expandable header mechanism that jumbo already uses)

        - list of associated filenames

        - tool memory area (e.g., ADAGER would record history of modifications
        made by the user)

        - enhanced data dictionary (e.g., "set X field CDATE, I2 is actually
        date intrinsic date type number 4", or "set Y field FOO, default value
        is "NONE"")

        - performance measurement/control information

Stan

Stan Sieler                                           [log in to unmask]
www.allegro.com/sieler/wanted/index.html          www.allegro.com/sieler