"Capacity exceeded: DISPATTR page table entries" error.

[BobSpangenburg]

Hi,

Does anyone know how to resolve a "Capacity exceeded: DISPATTR page table entries"?

I've hunted everywhere I can think of, including the code. I've found where the message comes from, but now how to set it or resolve it. I'm assuming because it's not set in any configuration that it's using its default value. I apparently have to increase that value, but can't figure out where or how.

On a side note, what is causing it appears to be when I use too many entities within a FOSI stylesheet. Even when I flatten the stylesheet, thereby removing the entities, I still get the error, so I don't think it's the entities themselves, but rather the amount of coding.

Thanks in advance,

Bob

[GarethOakes]

Hi Bob, I hope all is well. Definitely something fishy going on with your FOSI. I found some related error messages which show the kind of problem area you are in. If I had to hazard a guess it would be something related to the processing of attributes. I've pasted the list of related error messages below in case it helps you see what it could be (and what it isn't).

capacity exceeded: ATTRCHAR page table entries
capacity exceeded: Att/Subchars/Charfill page table entries
capacity exceeded: CompChar page table entries
capacity exceeded: DISPATTR page table entries
capacity exceeded: DispChar page table entries
capacity exceeded: DocFrag page table entries
capacity exceeded: Eic page table entries
capacity exceeded: EicLink/FosiVar page table entries
capacity exceeded: EicLink/SecEic/OidDa/PTag/Float page table entries
capacity exceeded: Handle page table entries
capacity exceeded: Pagedef page table entries
capacity exceeded: Pageset page table entries
capacity exceeded: SpecFill/Att page table entries
capacity exceeded: SpecFill/Fgrent/SecVal page table entries
capacity exceeded: StyleData page table entries
capacity exceeded: Unknown page table entries
capacity exceeded: string block page table entries
capacity exceeded: text fragment page table entries

[BobSpangenburg]

Gareth,

Thanks for the reply, however I know about the error messages that are sent. My problem is trying to find a method by which these "capacities" can be increased. I've found nothing on the subject.

Thanks,

Bob

[GarethOakes]

I'm pretty confident those capacities are built-in to the source code of Arbortext. If you need them increased then you might need to file a PTC support ticket and see if they can bump them up in a future release. From memory though, I think you are stuck on an older version of Arbortext, right? If so you may have to find a creative way around this one, they won't be able to fix unsupported versions. In fact, even if you were on a supported version you may have trouble here as they are no longer officially supported FOSI. I wish I had a smart idea here for you.

[GarethOakes]

Here is why I think it is deep in the source code: https://en.wikipedia.org/wiki/Page_table

Not suggesting that this is related to the O/S page tables but the use of programmer terminology in the error message is what makes me suspect DISPATTR is stored in a similar fashion.

[BobSpangenburg · Accepted solution]

Hi Gareth,

Thank you for all the research you did on this. I've found that if I go over 14,631 <att> tests within my FOSI, it bombs with this error. so... I'm in the process of reducing that number by getting rid of superfluous attribute tests within the stylesheet. Most of the ones I can delete deal with testing the "status" or "deltype" attributes, which we don't use, short of deltype="delete". That is reducing the number considerably.

Again, nice chatting and thanks for the info.

All the best,

Bob

[GarethOakes]

14631 tests! Wow! I wonder if that is also slowing down your FOSI processing due to all the checks the computer has to do? Thanks for reporting back - this will be very helpful information in future if someone encounters the same error message.

[BobSpangenburg]

Hi Gareth,

I don't know about slowing down the FOSI. They still seem to do quite well. At any rate, I've gone through the entire FOSI and removed everything that involved checking the "status" attribute, which is based on some sort of change markup tracking. We don't use the "status" attribute, as well as we only use "deleted" for the "deltype" attribute. So by cleaning out all of them, I've reduced the number of these tests by a couple of thousand. It works now, so I'm good.

I need to create another question about diagnostic types. You'll see it soon.

Thanks for all your input,

Bob