Our client is receiving this error in their CHUI application. After spending some time Googling and looking at the Progress Knowledgebase, I can't find anything that matches the error we are getting precisely.
The closest I can find is:
SYSTEM ERROR: strent request for more than 64K. (9874)
SYSTEM ERROR: strent request for more than 32K. (893)
with the knowledgebase saying:
"When there are too many queries left open on the remote server, the remote server crashes because there is no more memory available to handle additional requests and hit the strent limit. This happens because queries on the client application are not closed properly on the client side."
My question is, what is the "strent" limit and does anyone know why we would get this on a Progress V6 based CHUI app that has no appserver.
The OS is HP-UX and the current Progress version is 10.2A.05.
do the clients get a core dump when the error occurs?
Oh and just found this that implicates persistent procedures as an alternative cause:
Yeah, but TBH I'm not sure what I'm looking for...
Would you be able to share a core dump for others to look at? Might help identify the issue.
Think I've got it. I tied in the error in the server .lg file with the last entry in the procore file. See below:
02/11/15 15:04:41 
Progress Recent Message(s):
*** ABL Call Stack ***
Last action: RUN (47)
3069: sendStockUpdate bo.Stock (/bo/Stock.r)
1836: p430723b.p (p430723b.r)
273: p430703.p (p430703.r)
759: p430702.p (p430702.r)
532: p430701.p (p430701.r)
3204: p460113.p (p460113.r)
171: p460103.p (p460103.r)
2395: p460181.p (p460181.r)
608: p460101.p (p460101.r)
181: p460100.p (p460100.r)
358: strfnk00.p (strfnk00.r)
591: strmnu10.p (strmnu10.r)
565: strmnu10.p (strmnu10.r)
414: strmnu00.p (strmnu00.r)
I've attached a .png with some screenshots sent by our client of the .lg file.
This is a fatal message, meaning you should also have a protrace file, not just a procore. The C stack trace in that would be of more value in determining the problem, although the correct channel to have that reviewed would be logging a call with Tech Support. Given that this is such an old version, this might have been addressed in newer versions, but there is no way to know without being able to identify the issue, which would start with the stack trace.