> Have tried to use "Menu commands =" to list menu commands available as per:
> "Menu commands = List, Back, New, Edit, Delete, Find, Config, HELP, Logout"
> 
> but it does not seem to work; with command above I get default menu 
> structure.
> 
> Using:
> "Find Menu commands = List, Back, New, Edit, Find, Delete, Config, Logout, 
> HELP"
> 
> I get the menu I want.
> Q what's the difference?????

"Find menu commands" apply to the LIST of entries, while "Menu commands" apply
to the page where a SINGLE entry is shown. I know that "Find menu commands" is
a misleading name, but it's historical, I should change it to "Menu commands"
and change the other to "Entry menu commands", does that make more sense?

ELOG has been carefully designed not to contain memory leaks. The server for this forum for example runs for months without problem:

[ritt@midas ~]$ ps aux | grep elogd

elog      1958  0.4  3.1  39412 32940 ?        Ss   May09 178:16 /usr/local/sbin/elogd -D -c /usr/local/elog/elogd.cfg

So if you have a problem, it must be specific to your installation. You should note that if you up- or download big attachents, memory gets allocated for some network buffers to contain these attachments. The buffer is kept to contain the largest attachment, it will never shrink. But once established, it will also not grow. If you see however a constant increase in memory consumption, I would appreciate if you tell me how you do this. Like which configuration you use, if you just read entries or also upload them, etc. etc. Once I can reproduce exactly your problem, I can try to fix it. 

 No quick fix, sorry. It is also limited by a fixed number of characters per line in the configuration file and many more. I will try to increase it, but it will take time. Can you maybe set-up a mailing list at your email server? This way you send only email to one destination and it gets distributed to many people.

You would have to change the elogd.c code and recompile. At some point you wlll however get crash of elogd with a stack overflow. If you need more than 100 attributes, it becomes anyhow hard to manage, so I would suggest other ways, like adding iformation to the text body etc.

Best,
Stefan

Dear Stefan,

 Thansk for the super fast response! To keep the stability of the system we will look for a different solution then. 

Best,

Marta

In my case, I had a number of attributes which had a varied prefix.  For example, "progressed" , which could have no prefix, or prefix "I", "To be", "Strongly", "Seriously"... and that was true (the same prefixes, or at least many of them) for a number of attributes.  Splitting them into two groups, the prefixes and the action, allowed me to gain more actual attributes without having to recompile.  Suitable change in the elog config file will also make this easy to follow in how the entries are shown in threaded or full display modes.  In your case suffixes may be better, but I hope you get the point.

Although I have done a (linux) recompile in the past, v2.9 something, 120 attributes seemed not to affect things.