-l exceeded

[Vaalen]

Situation:

Server machine: windows2003, containing databases
Clients: windows xp.

Progress version 9.1E, latest patch.

On the server runs a program (jobrun.p), continuously. No batch, started directly with -p parameter.
This programs runs, according to intervals defined in the db, programs and does this in a neverending loop. These programs are NOT persistent.

Soon after starting jobrun.p we find messages in the lg file saying
10:59:20 SRV 3: WARNING: -l exceeded. Automatically increasing from 25300 to 25310. (5408)
10:59:20 SRV 3: Previous message sent on behalf of user 21. (5512)
10:59:21 SRV 3: WARNING: -l exceeded. Automatically increasing from 25310 to 25320. (5408)
10:59:21 SRV 3: Previous message sent on behalf of user 21. (5512)
11:00:18 SRV 3: WARNING: -l exceeded. Automatically increasing from 25320 to 25330. (5408)
11:00:18 SRV 3: Previous message sent on behalf of user 21. (5512)
11:00:20 SRV 3: SYSTEM ERROR: Attempt to define too many indices. (40)


We found out that the definition of NEW SHARED variables was the most likely cause. At first jobrun.p had NEW SHARED variables, and some called programs also (same variables). After correcting this, there were a lot less messages.
But there still are.

There are a few programs who define NEW SHARED variables (which do NOT exist in jobrun.p). These programs seem to be responsible for the messages still in the logfile.

Is anyone familiar with this problem? Are there any solutions?

Progress Nederland cannot help me. They cannot reproduce the problem (using 10.2A).

 

[AndrewSmith]

Best solution - remove all shared variables. They are evil, and should be done away with at the earliest opportunity. There are many alternatives to their use, for example a session-level super procedure with a temp-table, get and set functions.

Rubbish solution one - increase -l to something HUGE. At least the -l won't have to be incrementally increased as you go.

Rubbish solution two - use GLOBAL shared vars instead of shared vars. They should then use an existing memory space, rather than allocating new memory every time a procedure is run. This may require some thought as to the implications of the change, of course.

 

[Casper]

Do you have simple code to reproduce this with?

I just tried it. It is easy to get the 40 error. But I don't succeed in getting the 5408 errors. (I tried it with new shared and new global shared in infite loops, but with no succes).

The 40 error comes from bad cleanup of dynamic temp-tables.

Casper.

 

[Vaalen]

Oh, oké. There are no dynamic temp-tables in any program. A lot of static ones though.

I do not have a simple program, can send you the actual programs though, to see for yourself.

 

[Vaalen]

Jobrun.p is the calling program. The called program does nothing except defining variables (a few NEW SHARED) and write to different flat files.