"<Elbert E Silbaugh>" <[log in to unmask]> wrote:
 
>It appeared to me that there is/was confusion (at least in my mind) about
>multiples of blocking factors, and incremental capacities, so I reread
>the threads again and again and came up with the following summary:
>
>Old info:
>(1) Detail DS cap must always be multiples of Block Factor.
>
>New info:
>(2) On DDX sets, Incremental capacity must be multiples of Block
>    Factor (my DB verified OK). This agrees with rule 1.
>(3) CurrentCap and MaxCap are therefore and obviously multiples of
>    Block Factor. This agrees with rule 1.
>(4) The ((MaxCap - CurrentCap) / IncrementCap) does not have to be
>    a full (even/ integer) number i.e. 45.567 is legit
>(5) When ImageSQL does the FINAL expansion (to MaxCap) and that expansion
>    is not a full increment, then things go haywire - even though the
>    standard increment is a multiple of the Blocking Factor AND the partial
>    (remaining) increment is a multiple of the Blocking Factor.
>
>Please advise.
>
>Whew! Where is that fuzzy logic algorithm? If the computer is smart enough
>to know what is wrong, then why doesn't it fix it?
>
>Elbert
 
 
I'll address this in a LIFO fashion:
 
"The computer" is not smart (much less "smart enough").  Some poor
suffering programmer MUST toil away, crafting potential responses to
potential SNAFUs (to use a military term).  This applied in the days of raw
pre-assembler programming and, contrary to popular opinion, applies even
more in these modern days of sophisticated software engineering,
object-oriented programming, etc.  Tools are necessary, but not sufficient.
 
So, the answer to your "Whew!... why doesn't [the computer] fix it?"
question is: Because some poor suffering programmer has NOT YET done the
necessary work.
 
As I mentioned recently, I have been toiling away at plugging more and more
of these DDX cases in Adager's pre-process certification.  The flip side of
all of this effort is that, as soon as I incorporate a more stringent test,
we get calls from people who thought that their database was "ok" and now
Adager began complaining and etc.  Our stock answer is: You might as well
learn NOW and not later; why kill the messenger who unearths the bad news?
Etc. etc.  (As expected, most of these calls are from people who have just
gotten a demo tape of Adager :-)
 
HP is working hard on (5).
 
The whole issue involved in (4) might be a bit excessive (depending on how
paranoid you are) and subject to discussion.  Hopefully, resolving (5) will
take care of (4).
 
(3), (2) and (1) are correct conclusions.
 
 
Good sleuthing job, Elbert!
 
 
 
+---------------+
|               |
|            r  |  Alfredo                     [log in to unmask]
|          e    |                           http://www.adager.com
|        g      |  F. Alfredo Rego               Tel 208 726-9100
|      a        |  Manager, Theoretical Group    Fax 208 726-2822
|    d          |  Adager Corporation
|  A            |  Sun Valley, Idaho 83353-3000            U.S.A.
|               |
+---------------+