On Sun, 21 Jan 1996 16:26:21 -0500 Denys Beauchemin said:
>In a message dated 96-01-21 15:50:29 EST, [log in to unmask] (Jeff Kell)
>writes:
>
>>Now, given all of the calls made to dbinfo mode 202, what percentage of
>>those calls satisfy the criteria above?  Probably non-zero, but definitely
>>a small number.  By having 202 return current capacity versus the somewhat
>>more intuitive (IMHO) maximum capacity, we are penalizing all existing code
>>utilizing 202 to insure the integrity of the borderline cases above.  I
>>would therefore respectfully suggest that dbinfo mode 202 return the maximum
>>capacity, and those critical and/or paranoid programs that absolutely and
>>positively must have a successful dbput be changed to examine dbinfo 205.
>>And perhaps add a new dbcontrol() option to attempt a DDX expansion without
>>a put to determine if it is "safe" to proceed or not.
>
>Jeff, I think I must respectfully disagree.  I believe things are as they
>should be now.  If an application program is now using 202 and the
>environment changes to include DMX/DDX, then as part of the implementation,
>the user should change the program to 205, or contact the vendor to do it.
> BTW, it is also a good opportunity to review other things in the program at
>the same time.
 
Denys, I must respectfully continue to argue my point.  Conceptually the idea
of DDX in the first place was to avoid the dreaded "DATASET FULL" conditions
that render an application helpless.  Even if you have 3rd party products to
dynamically expand the capacity you must run everyone out of the database as
this requires exclusive access.  I thought, perhaps incorrectly, that DDX was
to avoid this problem without the necessity of pre-allocating huge datasets
and wasting disc space.  A great deal of HP's resources were expended to make
DDX a reality (it was no trivial task).  Applications that never bothered to
check capacity gained a benefit.  But those which do gained absolutely nil
unless you retrofit them to mode 205 (but then, what about the applications
that run across releases or on classics; you can't just change the mode and
logic, now you have to check your operating environment).
 
>I hate to change what is already established and look forward to building on
>what is there.
 
I thought DDX was intended to change what was already established, not to
continue the status quo.  OpenDesk gained nothing.  Query gained nothing.
Our old DBLOADNG gained nothing.  This can get to be a lengthy list.
 
Let me make an analogy - you can :BUILD a file with an astronomical limit of
records.  This file will be allocated extent by extent.  If you call any of
the file intrinsics or CI finfo() to ask for the limit, you are returned this
pie-in-the-sky limit.  You don't get the limit of the currently allocated
extent (in fact you can't get that value easily).  This doesn't seem to
bother anyone.  Why should Image differ now that we have DDX?  The number of
applications that would suffer from changing 202's behavior are minimal, and
the ones using it now are penalized by gaining nothing from DDX unless you
go back and rework them.  This doesn't make sense Denys.  Do you want Win95
to enforce the previous restrictions on legacy applications, or let it try
to make the new capabilities available where they are possible?
 
>Finally, I am not sanguine about this issue, but I do hate to see precious
>resources used to correct a problem that is really non-existant. And the
>documentation would have to be changed also and testing and. . .
 
This is almost a no-brainer coding change; it's a philosophic issue.  The
effort to change dbinfo 202 behavior is trivial.  My suggested dbcontrol
simply needs to invoke the DDX expansion built-in to dbput.  You want to
talk about allocation of "precious resources" yet you advocate that every
application using dbinfo 202 be re-engineered for the new 205.  It is a
much better allocation of resources to fix the applications dependent on
202's behavior to protect critical dbputs when DDX is enabled AND the
expansion would fail.
 
I understand your concern for "compatibility" which HP has been an industry
leader.  But in this case, I feel very strongly that emulating the previous
behavior negates the intent of DDX to begin with.  HP hasn't changed their
own applications to accomodate 205, how can we expect everyone else to?
Almost everything DDX was supposed to "fix" is negated by leaving 202 as is.
 
Respectfully submitted for your consideration,
Jeff Kell <[log in to unmask]>