WARNING: -l exceeded. Automatically increasing from <old

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

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.

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.

end.

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

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:

-----

DEFINE TEMP-TABLE ttHandle

 FIELD hBuffer AS HANDLE

 FIELD hQuery  AS HANDLE.

DEFINE VARIABLE iLoop   AS INTEGER     NO-UNDO.

DEFINE VARIABLE iRecord AS INTEGER     NO-UNDO.

DO iLoop =  1 TO 50:

 MESSAGE iLoop.

 SHOW-STATS.

 FOR EACH _file NO-LOCK

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

   CREATE ttHandle.

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

   CREATE QUERY ttHandle.hQuery.

   ttHandle.hQuery:SET-BUFFERS(ttHandle.hBuffer).

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

   ttHandle.hQuery:QUERY-OPEN().

   DO iRecord = 1 TO iLoop:

     ttHandle.hQuery:GET-NEXT().

     IF ttHandle.hQuery:QUERY-OFF-END THEN

       LEAVE.

   END.

 END.

END.

FINALLY:

 FOR EACH ttHandle:

   IF VALID-HANDLE(ttHandle.hQuery) THEN

     DELETE OBJECT ttHandle.hQuery.

   IF VALID-HANDLE(ttHandle.hBuffer) THEN

     DELETE OBJECT ttHandle.hBuffer.

 END.

END.

-----

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.

[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.

[/quote]

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.

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

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.