Hi ,

Any suggestion to suppress/ remove the number overflow in ln report like below .
2023-09-02[14:58:38(UTC-05:30)]:I:rupeshk: ******* S T A R T of Information message *******
2023-09-02[14:58:38(UTC-05:30)]:I:rupeshk: Log message called from \logic\mir\mir\mir_prtf.c: #992 keyword: rtdjwx0427110142
2023-09-02[14:58:38(UTC-05:30)]:I:rupeshk: Pid 5072 OSUser jwxad Pset rupesh.kudalkar@192.168.104.186:54574
2023-09-02[14:58:38(UTC-05:30)]:I:rupeshk: user_type N language 2 user_name rupeshk locale ISO88591/NULL package_comb b61cjwx
2023-09-02[14:58:38(UTC-05:30)]:I:rupeshk: session: "rtdjwx0427110142";object: "rtdjwx0427110142"; function: "r_sprintf$" vsprintf$; company number: 80
2023-09-02[14:58:38(UTC-05:30)]:I:rupeshk: Errno 0 bdb_errno 0
2023-09-02[14:58:38(UTC-05:30)]:I:rupeshk: Windows error 0 (The operation completed successfully.)
2023-09-02[14:58:38(UTC-05:30)]:I:rupeshk: Log_mesg: [MR_OVERFLOW] Overflow: format='1' value='1693837260'
2023-09-02[14:58:38(UTC-05:30)]:I:rupeshk: ******* E N D of Information message *******
2023-09-02[14:58:38(UTC-05:30)]:I:rupeshk:
2023-09-02[14:58:38(UTC-05:30)]:I:rupeshk: ******* S T A R T of Information message *******
2023-09-02[14:58:38(UTC-05:30)]:I:rupeshk: Log message called from \logic\mir\mir\mir_prtf.c: #992 keyword: rtdjwx0427110142
2023-09-02[14:58:38(UTC-05:30)]:I:rupeshk: Pid 5072 OSUser jwxad Pset rupesh.kudalkar@192.168.104.186:54574
2023-09-02[14:58:38(UTC-05:30)]:I:rupeshk: user_type N language 2 user_name rupeshk locale ISO88591/NULL package_comb b61cjwx
2023-09-02[14:58:38(UTC-05:30)]:I:rupeshk: session: "rtdjwx0427110142";object: "rtdjwx0427110142"; function: "r_sprintf$" vsprintf$; company number: 80
2023-09-02[14:58:38(UTC-05:30)]:I:rupeshk: Errno 0 bdb_errno 0
2023-09-02[14:58:38(UTC-05:30)]:I:rupeshk: Windows error 0 (The operation completed successfully.)
2023-09-02[14:58:38(UTC-05:30)]:I:rupeshk: Log_mesg: [MR_OVERFLOW] Overflow: format='1' value='1695148200'
2023-09-02[14:58:38(UTC-05:30)]:I:rupeshk: ******* E N D of Information message *******
2023-09-02[14:58:38(UTC-05:30)]:I:rupeshk:

These messages are flooded in our logs and is an process overhead .

Hi Hitesh,

Is the obvious solution of fixing the number formatting overflow problem in the report not an option?

Yours,
Stephan

Hi Hitesh,

Is the obvious solution of fixing the number formatting overflow problem in the report not an option?

Yours,
StephanOr maybe the data needs correction ... Most obvious is (you can debug report to pinpoint the exact location of the error) indeed fix the error by changing the format of the numeric field.

Hi Hitesh,

Is the obvious solution of fixing the number formatting overflow problem in the report not an option?

Yours,
Stephan

It's certainly not an option in the sense that there are 1000s of places it may be there and users really dont use Ln reports per se in such cases as their data in such report is converted to excel and they use these XL reports for operational planning and execution. Such reports many a times are very big in width which simply can not fit in a line . So the output variables on reports are mere placeholder to get data for excel extractor .

Recently after a path installation reports started coming slow . We did revert the patch, yet the it's speed could not be improved. We have checked A/v and Ln application and folders are excluded from the A/v scans . We see system resources . There are no bottlenecks on cpu/ram/network/hdd io . We checked db server too . That too has quite free resources on regular basis . On careful study we find that Ln reports spooler is very slow . Simple 400 page report takes about 20-25 mins . And that's where my question above. Reports in study does not have any complex report scripts also.

Further I see the number of logs in the system is 5 only whereas i believe i can increase it to 999 . On increasing that , i suppose as least bottleneck to find log file name may be reduced resulting in speed improvement. The problems of logs getting flooded with these entries is such acute that we can not examine the genuine error logs also as it gets over-written with other log entries . We are working on this and will share how we can improve it.

PS - We have one para USE_LOGFILE . We are turning off this and I think that should stop the logging of such errors .That should eventually speed up our reports . I will update on this further.

Or maybe the data needs correction ... Most obvious is (you can debug report to pinpoint the exact location of the error) indeed fix the error by changing the format of the numeric field.

Yes it can be an opportunity for data correction . But in our case its not the same as explained to stephan.

Hi ,

Turning off this has shown drastic improvement in throughput . Still will monitor overall response times . At the peak of system usage these log files are a crucial bottleneck .

In the meantime if anyone has any ideas to have more better control on log files (like number of log files , the overall kind of data which is written in log file besides the number overflow ,dd errors ,fatal errors) . I checked for float exception error . It did not log in the error log .

Of course we can and will use the logfiles whenever required but at the individual level and NOT at company level .

Thanks in advance for your help in this matter.

Man I agree - it sure would be nice if we could control what went in the log files so we could only investigate the important issues. Even after 23 years we still get overflow errors from standard reports (and the users don't complain). At least here our baan 4 is considered a legacy system.