At 10:59 AM 12/31/97 -0700, Lee Gunter wrote:
>DBGeneral apparently doesn't maintain the DDX increment as an even divisor
>of the difference between max and initial capacities.

Allow me to clarify the product issues Lee raised:

In late '95 or early '96 some users experienced a problem which was termed
as a 'DDX-Stall'.  HP Labs (with the help of others if I recall)
determined that there was a problem in IMAGE whereby if the amount of
space added during the last increment of a set to its configured maximum
was not equal to the full increment, IMAGE basically would hang (SR
5003-286369).
The labs worked quickly to repair the defect. In the mean time, it was
communicated to the 3rd parties that during a capacity change which involved
DDX, if the delta between the current capacity and the max capacity was
full increments the user would not encounter the DDX-stall.

I have checked our internal logs and confirmed that DBGENERAL was enhanced
per
this information on 3/6/96, in release 7.1.17.  The actual DDX-stall defect
no longer exists in the current release of IMAGE (C.07.04 or greater).

This is not the same issue which Gary Jackson encountered.

The b-tree features in Express-3 have been written in anticipation of
HP's announced efforts to also provide dynamic expansion for master
datasets.  (Gee...nobody noticed the error msg text given by Stan and the
fact that it was a master set.... ;-)

As such, during the creation of a b-tree, the 'maximum capacity' of
a master set is used to size the index file.  In conjunction with this,
when creating a new rootfile with DBSCHEMA, the initial and maximum
capacity values are set to the current capacity when creating a
non-ddx set.

So a possible scenario is this: the user had previously performed a
structural change with DBGENERAL.  As most of you know, DBGENERAL utilizes
DBSCHEMA to (re)build a rootfile.  This new rootfile has the max-capacity
for the master set as the current capacity.  Up until b-trees, these DDX
fields were not interpreted by any existing IMAGE processing, as there was
no feature that utilized them. (Furthermore, there was no available
information from HP as to if/how these fields may be used in the future,
as DDX:M was not yet a project.)

Now, the user conducts a capacity change on a master using DBGENERAL. In
turn DBGENERAL updates the current capacity information in the DSCB area
of the rootfile.  Unfortunately, older versions of DBG, even those which
were dynamic detail set expansion aware, were not knowledgable as to
how the future DDX:M feature of IMAGE would be expecting these fields
for master sets.  So until this was known, the fields were left unchanged
as a part of capacity change.

Along comes b-trees which is positioned for the DDX:M feature which HP
is working on and the non-zero DDX capacity fields for the master are
expected to be in a particular relationship, and if not....

Somewhat fortunately is that this was uncovered last August during the
final stages of testing with the b-tree BETA and our 7.2 release just prior
to demonstrating it with IMAGE b-trees at HPWorld.  As such, when customers
begin using the b-tree and obtain the b-tree aware version of DBGENERAL
(7.2+) this scenario will automatically be corrected when the database is
checked given what we now know from HP concerning DDX:M setting expectations.



/jf
                              _\\///_
                             (' o-o ')
___________________________ooOo_( )_OOoo____________________________________

                        Wednesday, December 31st

             Today, in 1946 - President Truman proclaimed the official
                              end of WWII.

___________________________________Oooo_____________________________________
                            oooO  (    )
                           (    )  )  /
                            \  (   (_/
                             \_)