Hi Steve,
We are still investigating this subject and will document this topics, in the meantime I would like to share these information with some confirming Steve's entries.
1) The internal limit for directory pages is 32767.
2) For INIT, the above limit should be adhered to.
For BC1PNLIB 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 and we will document it.
The doc says, for 4KB pages, one directory page can hold 48 members.
But it also adds, that optimally, dir pages are only half full.
So to calculate the optimal # of dir pages you will divide expected maximum number of members with number 24 (=48/2).
The dir pages can play in performances.
If you have too few dir pages, you get more overflows and more I/O.
On the other hand, if you have too many dir 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.
5) 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 dir pages is generous enough and I believe you will be comfortable for while with that value.
But number around 1,536,000 seems to be the limit for overflow-free directory, since directory page can store up to 48 directory members.
However, this limit is not a wall you cannot go through. You can have more members with directory overflows and your ELIB will work just fine. You should worry only in case there is very high number of directory overflows. Roughly speaking, you can see measurable performance dropdown at about 2,000,000 members and you should start worrying about performance beyond 4,000,000 members.
I'm not aware of ELIB storing such huge number of members and it would be interesting if the communities share their own situation regarding ELIBs. The BC1PNLIB INQUIRE will help you to get a status.
BC1PNLIB OPTIONs
None
-- If you omit this clause, CA Endevor SCM prints only data set header information.
DIRECTORY
--Tells CA Endevor SCM to print information about target directory page utilization.
MEMBERS
--Tells CA Endevor SCM to print footprint information plus member size in pages,
records, and bytes.
ANALYZE
--Tells CA Endevor SCM to print an analysis of data set integrity.
Also, we have already created some knowledge document(an other are coming soon), go directly to https://support.ca.com/us/search.html?q=ELIB or search for ELIB from https://support.ca.com to read them.
Don't hesitate to evaluate and comment our knowledge document, your experience is important for us and we will review them if necessary.
I hope this help.
Regards,
Ollivier