Re: Dictionary page sizes

Discussion created by ca.portal.admin on Nov 14, 2006
I think the comments about the ""run time"" DDLDCLOD area are probably
quite valid - if you only load a dictionary load module once a day does
it matter how many IO's it takes? Probably not. My concern is for the
development dictionary - where a small page size results in lots of IO's
to load the 50k to 200k behemoths that our developers consider to be
reasonably sized dialogs. The issue isn't just loading - but the number
of pages that get written and the number of page level locks that get
placed when writing out the load modules. You would not be happy with an
application database that had a VIA set that extended across 10 to 50
pages - and that was highly volatile whereby the entire set gets erased
and rewritten many times a day. This would be the case if we used a 4k
page size for the size of load modules we end up with. If you wouldn't
like it in an application database why would you be happy with that in
the load area?

We use a page size of 23476 for our load area - also to minimise
deadlocking in development we have ""activity logging NO"" in the ADSO
statement. We have YES in our QA environment so that when dialogs are
migrated we get the useful documentation that is created when this
compile option is turned on. BTW - the load module ""object"" records are
stored as LOADTEXT-157 records, stored VIA the LOADHDR-156 records.

We also had trouble understanding why our development dictionary load
area was so much more full than our QA load area. We checked the space
reports and the answer (should have been obvious) was the number of
SYMTEXT-175 records in development - ""symbol tables"" is turned OFF when
we migrate our dialogs to QA - but of course in development a great many
dialogs are compiled with symbol tables ON. Our development dictionary
is now at least 30% larger than QA and Production for this reason -
whereas in the past we used to try to keep all our dictionaries the same
size (for historical reasons rather than for any well thought out

HTH - cheers - Gary