This is expected behaviour, the threaded binary dump is working as designed.

The multi-threaded binary dump feature was introduced in OpenEdge 10.1A  

• A binary dump uses threaded options by default: The default -threadnum value is the number of operational system CPUs. 
• The number of threads can otherwise be specified with: -thread 1 -threadnum <n>
• When a binary dump is run without threading (-thread 0) or when the threaded binary dump algorithm determines to use single thread mode for the binary dump, the table will dumped using only one thread.

Just because a threaded dump is instructed, does not mean a threaded dump will occur and when this 14777 message is written, it is simply informing you precisely that the binary dump will continue without using threads: The reason it cannot use threads is because the records that will be found by the index used to dump need to be divided up. For example, when there's only one level entry in the root block, the index tree cannot be broken into key ranges for each thread to work on, therefore a non-threaded (regular one thread) dump will be used to dump the entire table's record content. The 14777 message is not an indication of failure or concern. It is always important to verify that the number of records that were dumped are the expected number of records. Parsing the record counts from a proutil -C tabanalys report pre-dump and post-load is one of the quickest ways to do this. A different index can be used to perform the binary dump, by finding out if the root index contains more than one entry, but the number of threads the dump will use cannot be accurately predicted. Further information is provided in Article:  

• How to estimate the number of binary dump threads?   

The threaded dump algorithm is based on the index tree, not on the number of records. It verifies the following before permitting a multi-threaded binary dump:

• The index used for the binary dump is the Primary index by default or that specified by the -index parameter. 
• The threaded-dump algorithm splits the root block logically for each thread, based on the number of entries in the root block. This breaks the index tree according to the keys in the root block into in different ranges where each thread works on a range.

This means that when the table is binary dumped:

• The -threadnum value is the maximum threads available to the binary dump and therefore while more threads are available, not all threads will be used.
• When running in multi-threaded mode, each thread will not dump the same number of records resulting in different sized binary dump files.
• When there is only one entry in the root block, it cannot be split so a non-threaded (regular) dump will be used and the 14777 message is written.

d.) A special case that affects the number of threads used is if there are duplicate keys in the root block, the duplicate keys are ignored when building the brackets for the number of threads to be used.

Known issues with the Threaded Binary Dump feature:

There used to be a problem with threaded binary dumps in earlier versions, when the binary dump algorithm determines to use single thread mode, which is no longer the case:

• OpenEdge 10.A, 10.1B, 10.1B01: Binary dump fails on 64-bit OpenEdge versions, Multi-threaded binary dump cores on 64-bit platforms   
• OpenEdge 11.2.1, 11.3.0: Binary dump fails to dump the binary data (.bd), Binary Dump does not dump data when non-thread mode is initiated   
• Prior OpenEdge 11.5: The dumplist file is not produced when one thread produces only one .bd dump file, Dumplist file was not created after binary dump with -dumplist option   

Progress Articles:

How to find the Number of an index its Storage Area and Root Block   
What determines the number of entries in the root index block?  
How to estimate the number of binary dump threads?