We migrated our Baan IV c4 Servers a few weeks ago to linux, without big problems. The only issue we have at the moment is that some people sometimes get error messages (in different sessions doesn't matter if view - print - maintain).
Here you see a part of log.bshell (sorry the error is in german):

2005-08-30[10:39:50]:E:rkreuzpa: ******* S T A R T of Error message *******
2005-08-30[10:39:50]:E:rkreuzpa: Log message called from /view/port.6.1c.07.07/vobs/tt/mir/mir/mat_fun.c: #94 keyword: ttstpsplclose
2005-08-30[10:39:50]:E:rkreuzpa: Pid 31899 Uid 548 Euid 548 Gid 500 Egid 500
2005-08-30[10:39:50]:E:rkreuzpa: user_type N language 3 user_name rkreuzpa tty ote locale ISO88591/NULL
2005-08-30[10:39:50]:E:rkreuzpa: Errno 0 bdb_errno 0
2005-08-30[10:39:50]:E:rkreuzpa: Log_mesg: Überlauf: Format='99999' Wert='989212883'
2005-08-30[10:39:50]:E:rkreuzpa: ******* E N D of Error message *******

The last time we had it in the session tdpur4531m000 after searching a record. The second time we searched for the same record we got no error.

After confirming the error message you can go on as normal.

Hopefully someone knows a solution.

Alex Preyer

/view/port.6.1c.07.07/vobs/tt/mir/mir/mat_fun.c: #94 keyword: ttstpsplclose
2005-08-30[10:39:50]:E:rkreuzpa: Log_mesg: Überlauf: Format='99999' Wert='989212883'

This indicates a possible format bug (value 989212883 when the format expected is only 5 digits) in ttstpsplclose or the calling session(s) that may need an update.

Not sure if you have the fix in your Baan version release.
From one of the porting set release notes -

MaintCorelli: # 17575 (BDNT11034): Control logging of get_format_entry errors
Date: Thu, 13 Mar 2003 16:21:41 +0100
Created on: MaintCorelli
Type: bugfix

Problem Description (Customer terms)
The error logs are filled up with a lot of get_format_entry error messages. This is request for that the get_format_entry errors are not to be logged when at least a generic format is found for the format code.

If the format code & unit combination is not found (eg. Q13/FT but the generic format code does exist (eg Q13) then no error message should be written to the log.bshell file?

This would help us tremendously in many ways:
1 - being our log files will not roll over so fast that we miss real error messages.
2 - performance will improve for batch jobs which end up writing thousands of these messages.
3 - we will not need to continously update the datecurr file.

Problem Description (Technical terms)
Function get_format_entry searches datecurr file for the format specifier.

For example:

C|001USD|USD|ZZZZ9|

Here:

C: Means this line specifies a currency format
001USD: Format Code 001, and currency (Generic Unit) USD
ZZZZ9: Format specifier.

The input is a pattern, which is a combination of the Format Code and the Generic Unit (in this case this represents a Currency).
In case the format specified cannot be found for this pattern, an error is logged.
Now the request is to make it possible to log only an error in case the Format Code is not available at all.


Workaround
No workaround

Test Procedure
The following 3GL script, is used for testing:

function main()
{
string result(80)

| default currency of testcompany used is USD |the datecurr file contains the following entry: A|902|USD|001|001|
|so, this defines default currency = USD for company 902. The default format code is 001.

result = sprintf$("%A001", 1234.56) | no error, because the following entry exists in the datecurr file: C|001USD|USD|ZZZZ9|

result = sprintf$("%A001,hfl", 1234.56) | Format Code 001 exists, but Generic Unit (currency) hfl does not exist
| (the following line should be in datecurr: C|001hfl|hfl|ZZZZ9| ,but is not there)
| in case hide_format_errors = 1, no error should be logged, because format code 001 itself exists
| in case hide_format_errors = 0, error should be logged (old behaviour)

result = sprintf$("%A999,HFL", 1234.56) | Format Code 999 does not exists
| (the following line should be in datecurr: C|999USD|USD|ZZZZ9| ,but is not there)
| in case hide_format_errors = 1, error should be logged (error specifies also the missing format code)
| in case hide_format_errors = 0, error should be logged (old behaviour)
}

Resource hide_format_errors set to 0 ($BSE\lib\defaults\all)
============================================================
So, now the old behavior applies.
When running the testscript the following errors are logged (this example shows the errors which would be logged on a Windows platform, but similair error messages will be logged in the ${BSE}/log/log.bshell file in case of Unix systems):

Env Baan5c (C:\baan\baan5c)
Prog bshell file \general\lib\al_1\AL_ENV.C # 933
Keyword get_format_entry
Username kvddool type S language 2
Process 0xca4
ProcessSet kvddool@CNL09659:3196
Lasterror 0
Errno 0
bdberrno 213 (Transaction is started but not updated)
Message get_format_entry pattern '001hfl' index 3 entry 0 not found

Env Baan5c (C:\baan\baan5c)
Prog bshell file \general\lib\al_1\AL_ENV.C # 933
Keyword get_format_entry
Username kvddool type S language 2
Process 0xca4
ProcessSet kvddool@CNL09659:3196
Lasterror 997 (Overlapped I/O operation is in progress.)
Errno 0
bdberrno 213 (Transaction is started but not updated)
Message get_format_entry pattern '999HFL' index 3 entry 0 not found

Resource hide_format_errors set to 1 ($BSE\lib\defaults\all)
============================================================
So, now the modified behavior applies, and only errors are logged in case the format code does not exists at all.
When running the testscript the following errors are logged:

Env Baan5c (C:\baan\baan5c)
Prog bshell file \general\lib\al_1\AL_ENV.C # 941
Keyword get_format_entry
Username kvddool type S language 2
Process 0xc94
ProcessSet kvddool@CNL09659:3248
Lasterror 0
Errno 0
bdberrno 213 (Transaction is started but not updated)
Message get_format_entry pattern '999HFL' index 3 entry 0, format code 999 not found

Like you see now, only an error is logged in case the Format Code at all cannot be found. The error message mentiones no also explicitly "format code xxx not found".

Motive source
DF:212983