HP3000-L Archives

January 1996, Week 4

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Jeff Kell <[log in to unmask]>
Reply To:
Jeff Kell <[log in to unmask]>
Date:
Sun, 21 Jan 1996 15:31:11 EST
Content-Type:
text/plain
Parts/Attachments:
text/plain (32 lines)
On Sun, 21 Jan 1996 12:34:56 -0700 Alfredo Rego said:
>Denys, the always-perceptive Denys, wisely says:
>
>>In light of this, I would respectfully suggest that a request to the QUERY
>>lab be made to make use of  Mode 205 in their call to capacity and expand on
>>the listing thus produced.
>
>I agree.
 
I agree as well, but not only Query.  OpenDesk, DBLOADNG/HowMessy/etc (if
not already changed), and plenty of other things that I don't have source
for to make the changes.  It seems that we are overstating the borderline
case of:
    * program is checking capacity prior to a critical put,
AND * DDX is enabled,
AND * allocation of the new extent fails due to lack of space/whatever.
 
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.
 
Would this not satisfy the vast majority of cases with a minimum of effort?
 
Jeff Kell <[log in to unmask]>

ATOM RSS1 RSS2