David writes:

>
> ***** ERROR *****  NUMBER OF BLOCKS EXCEEDS TURBOIMAGE MAXIMUM
>
> Blocks needed = 17333333, but Maximum TurboIMAGE Blocks = 8388607.
>
> With $CONTROL BLOCKMAX = 2560, and a blocking factor of 50,
> the number of blocks would fit (1040000 blocks of 2554 words).
>
> A blocking factor can be specified in parentheses after the capacity, as
> in:
>    ... capacity : 52000000 (50) ...
>
> Is this a database limit to the number of blocks or a dataset limit?  I
> doubt that it is a dataset limit since it successfully processed an
> identically structured dataset with a capacity of 55,000,000 earlier in
> the schema.  I have $CONTROL BLOCKMAX = 2048, a record length of 102
> bytes, and a blocking factor of 40.  Any ideas what the problem might
> be?

If your capacity is 52000000, and DBSCHEMA says 17333333 blocks
are needed, that looks like a blocking factor of 3 was in effect for
that dataset.  So, 52000000 records / 3 records-per-block = 1733333 blocks,
which is  $1087C55 in hex.
The maximum block number IMAGE can support is $7fffff (which is 8388607).
If you want a capacity of  52000000, you have to increase the blocking factor
to at least (52000000 / $7fffff ... rounded up to nearest integer), which
would be 7 (resulting in 7428572 blocks).  However, that's only one possible
solution to the capacity & blocking-factor & blocks equation.  It would result
in rather small blocks (102 * 7 bytes + overhead).  Rather than compute every
possible solution, DBSCHEMA simply said "hey, if you used the largest possible
block size (2560), you could fit 50 records per block, which would result
in 52000000 / 50 blocks (1040000 blocks)".

In the past, IMAGE would have simply said:
   ***** ERROR *****  NUMBER OF BLOCKS EXCEEDS TURBOIMAGE MAXIMUM
and let you figure out the rest yourself.


--
Stan Sieler                                          [log in to unmask]
                                     http://www.allegro.com/sieler.html