When you want to allocate the directory pages for an ELIB, you need to know that:
1) The internal limit for directory pages is 32767.
2) For INIT, the above limit should be adhered to. For reorg, the limit is slightly lower, depending on the number of map pages. Value 32500 should be always safe.
3) We plan to document a new limit of 32500 and enforce it during parsing.
4) So you can simply run reorg with correct value, with 32500 as recommended.
Also, it is interesting to know that any number of directory pages will work for ELIB.
One should not see any errors neither corruptions with whatever value of directory pages.
The only thing where directory pages matter is performance. If you have too few directory pages, you get more overflows and more I/O. On the other hand, if you have too many directory pages, your performance will not grow beyond some point and you just waste space. The formula (constant 24 for 4k pages) is documented to be optimal.
The new limit will be set to 32500 - is this too limiting?
The number of members for which this value is optimal is 32500*24 = 780,000. But even if you store 3 million members in your ELIB your average performance for reading a member will go down only ~30%.
ELIB processing is just a fraction of action processing so overall performance will probably drop roughly to single digit percentage.
As you can see, the performance impact is low even for very high number of members, so the limit of 32k directory pages is generous enough.
If you expect to need more, please submit your question to CA Endevor Technical support.