HP3000-L Archives

February 1996, Week 5

HP3000-L@RAVEN.UTC.EDU

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

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

Print Reply
Sender:
HP-3000 Systems Discussion <[log in to unmask]>
Subject:
From:
"<Elbert E Silbaugh>" <[log in to unmask]>
Date:
Wed, 28 Feb 1996 16:43:34 -0800
Comments:
Resent-From: [log in to unmask] Originally-From: SIL9306E SGHP01 <[log in to unmask]>
Reply-To:
Parts/Attachments:
text/plain (26 lines)
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

ATOM RSS1 RSS2