WARNING: -l exceeded. Automatically increasing from <old

Posted by jbijker on 14-Jun-2016 08:43

Does anyone know how to reproduce the following message?

WARNING: -l exceeded. Automatically increasing from <old value> to <new value>. (5408)

I've tried to create lots of dynamic buffers & queries and finding records inside the queries, but no luck. I've also defined a workfile and added lots of records to it.

All Replies

Posted by jbijker on 14-Jun-2016 08:46

Forgot to mention: OE11.3.3, 32-bit Windows & 64-bit Unix

Posted by Marco Mendoza on 14-Jun-2016 08:54

From KB:

The 5408 warning message refers to the -l (local buffer size) startup parameter that administers how much memory Progress will use for the client's local buffer pool. It is merely indicating that this limit has been exceeded and Progress is automatically increasing the -l setting as needed in the current client session.

First, ensure that there is no application logic issue causing large amounts of memory to be consumed. In checking the application, consider that:

Local buffer size, -l parameter is used for variables, work files, records that are currently in a buffer in use at a particular moment in time by the user session and any information on currently active objects (handles, attribute values and internal pointers) such as temp-tables, query objects, widget pools and GUI widgets. While WORKFILES (not temp-tables) are entirely stored in -l memory, all other program variable records and database/temp-table records take space in -l only when the record is in an active 4GL/ABL buffer. Any record cache (used with a query) will therefore also affect the -l memory usage.

For example:

1. Define variables as NO-UNDO

2. Define temp tables as NO-UNDO

3. If using workfiles or a lot of persistent variables raise the -l (local buffer size) parameter to say 400 and gauge the impact.

4. Reduce the size of transactions and subtransactions.

Posted by ChUIMonster on 14-Jun-2016 08:58

This does it quite reliably for oe10 -- but not oe11:

define workfile myWorkfile

 field x as character


define variable i as integer no-undo.

do while true:

 i = i + 1.

 create myWorkfile.

 x = fill( "x", 1024 ).

 if i modulo 1000 = 0 then message i.


I've no idea why it doesn't generate the message for oe11.

Posted by jbijker on 15-Jun-2016 04:14

OK this is proving to be very confusing on OE11.

This is my code to generate lots of buffers to let OE increase the local buffer size:







DO iLoop =  1 TO 50:




    WHERE _file._tbl-type = "T":U:

   CREATE ttHandle.

   CREATE BUFFER ttHandle.hBuffer FOR TABLE _file._file-name.

   CREATE QUERY ttHandle.hQuery.


   ttHandle.hQuery:QUERY-PREPARE("FOR EACH " + _file._file-name + " NO-LOCK").


   DO iRecord = 1 TO iLoop:


     IF ttHandle.hQuery:QUERY-OFF-END THEN






 FOR EACH ttHandle:

   IF VALID-HANDLE(ttHandle.hQuery) THEN

     DELETE OBJECT ttHandle.hQuery.

   IF VALID-HANDLE(ttHandle.hBuffer) THEN

     DELETE OBJECT ttHandle.hBuffer.




As you see I'm using the SHOW-STATS command (need the -y startup parameter for this) to write statistics to client.mon in the working directory. From there I can see the local buffer size is steadily increasing:

Local buffer usage:          128480      168608

Local buffer usage:          165600      168608

Local buffer usage:          200256      200256


Local buffer usage:         1402176     1402176

Local buffer usage:         1423392     1423392

Local buffer usage:            5280     1423392

But funny enough nowhere in the log file (webspeed agent) I can see the WARNING: -l exceeded. Automatically increasing from <old value> to <new value>. (5408) message.

If I set a -hardlimit with -l set to 500 (i.e. 500kb) I get the following error message:

Resource limit reached. Raising untrappable STOP condition. (5411)

The reason why I want to reproduce is because we're running into situations where we execute code inside a DO ON STOP block, and use the undocumented _msg(1) function to get an error number back which we can translate back to a proper error message. It seems the STOP condition gets raised and _msg(1) returns 5408, but I think the number is misleading. However I see no other error messages in the log file, so at this point I'm clueless of what caused the STOP condition. It's definitely not a hard limit because a hard limit causes an untrappable STOP.

Posted by Brian K. Maher on 15-Jun-2016 05:54

Why don’t you try logging 4GL messages using –clientlog client.log –logginglevel 4 –logentrytypes 4GLMessages and see if that gives you what you want?  You can do this at runtime via the LOG-MANAGER handle too then close the log file and parse it to see what you get.

Posted by Frank Meulblok on 15-Jun-2016 06:12

[quote user="ChUIMonster"]

This does it quite reliably for oe10 -- but not oe11:


I've no idea why it doesn't generate the message for oe11.


Using -noincrwarn, -swl startup parameters  or session:suppress-warnings in the OE 11 environemt perhaps ?

Would be the simplest explanation.

And if I run your sample in an 11.6.2 environment where I make sure those aren't used, I do see the messages.

Posted by Fernando Souza on 15-Jun-2016 09:33

As Frank pointed out, make sure you don't have anything set that would suppress the messages from being logged.

_msg() will return the message that was last issued, but there is no context so it could had been issued before you ran the code (just fyi). But the fact that you do see the error number means that it did get issued, but if you don't see the message in the log file, that indicates that there is something probably suppressing it.

With all that said, that message will not cause a STOP condition. Generally, the STOP condition comes with an error message, but sometimes it might not, which is not desired. Since you don't know where it is coming from, you may want to turn on the 4GLTrace log entry with logging level 3. That will record the return from any procedure/function and will have a STOP tag at the end of the entry when a STOP condition is being raised which can help you narrow down the piece of code where the STOP is being raised.

You would see something like this in the log file:

<...> 3 4GL 4GLTRACE       Return from i-proc [prog1.p] STOP

Posted by jbijker on 22-Jun-2016 08:41

Hi Frank

I've tested Tom's program on the following versions

OE10.1C04 WIN 32-bit: giving the warning messages

OE11.3.3 WIN 32-bit: no warnings

OE11.6 WIN 32-bit: no warnings

OE11.6.1 WIN 32-bit: giving the warning messages

So it seems somewhere between 10.1C04 and 11.6 something changed and got fixed in 11.6.1.

This thread is closed