Stan Sieler wrote:
>
<< snipped>>

> 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
>
I think Stan and I or on the same track here, just approaching it from
different ends.

Some of the confusion is because i (and others) do not know the exact
structure of the root file.   Please note:

1.  I don't think that the root file can have additional data tacked on
the
    end without impacting many program as well as Image itself.

2.  Ergo, the FIRST thing that has to be done is expanding the root file
AND
   modifying all necessary programs to handle this expansion.

3.  The program should include a contraction utility so that a data base
    that employed this feature could be ported to a 3000 that had not
yet
    been updated to encompass this facility.

4.  Whether the extra space is used for file names, for for pointers,
    or for actual data will depend on the function added.

The above represent a concept, the ERS produced by HP would obviously be
more detailed and the details might be different.  The point is, though,
that HP must be willing to expand the root file, modify the related
programs and provide a conversion utility.  Otherwise any talk of future
Image enhancements go back to the onesy approach which usually means an
addition to the root file.  It is my understanding the the idea of the
Enchilada was to get away from this approach and lay a plan for the
future.

I repeat - to do this requires an expansion in some way of the root file
and if HP is unwilling to step up to this any more discussion of the
Enchilada is just an intellectual exercise.

Nick D.


    or