Denise Wallace’s issue:
Baan case 421575:
During session tfgld1111s000. Company 901. Batch 8627, Finalization run 4736
Also Batches 8660 8662 8663 8664 8665 8666 8667 8668 8669, Fin run 4737- data is properly moved from tfgld102 to tfgld106
- tfgld100 is correct
- tfgld101 is correct
- tfgld109 still shows In Use.
The transaction does not complete and does not provide the user with any errors.workaround fix - change the tfgld109 in GTM to Finalized and print the journal report to verify accuracy of batch. This has occurred 8 times so far - so we need to report the bug. I attached the $BSE/log/log.bshell and log.informix for the two errors.
The abort presents 80% of the time like below. Other times it aborts during financial entries of various types - many times the user just has to log back in. We run HPUX 11.23 and Informix 9.40 and spak 20. We don’t use any extensions and we have NOT customized this program at all - it’s std Baan.
-User is running select batches for finalization, tfgld1110m000.
-The user is aborted out of Baan, generally with no error message screen at all. They never reach the point where the journal report prints.
-User notifies IT and we find:
-The data has already moved from the tfgld102 to the tfgld106 successfully
-The status on the tfgld100 and tfgld101 show Finalized
-The status on the tfgld109 table shows Finalization in progress.
Once we verify the data has moved to the 106, we use gtm to fix the tfgld109 table and ask the user to rerun the journal report to verify the totals and that’s it. Happens on small batches with two entries and large ones - no pattern. Happens more often at beginning of the month - but more people are finalizing transactions then, so no pattern. Tried to determine if two people were finalizing at the same time? No pattern either.
In the $BSE/log/log.bshell, there is a generic database disconnect error that looks like this
2008-01-10[14:02:47]:E:vlt1: ******* S T A R T of Error message *******
2008-01-10[14:02:47]:E:vlt1: Log message called from /view/port.6.1c.07.11/vobs/tt/mir/mir/bdb_fun.c: #1127 keyword: DB error
2008-01-10[14:02:47]:E:vlt1: Pid 21198 Uid 139 Euid 139 Gid 125 Egid 125
2008-01-10[14:02:47]:E:vlt1: user_type N language 2 user_name vlt1 tty ote locale ISO88591/NULL
2008-01-10[14:02:47]:E:vlt1: Errno 0 bdb_errno 304 (General SQL error)
2008-01-10[14:02:47]:E:vlt1: Log_mesg: Error 304 (General SQL error) on SELECT
2008-01-10[14:02:47]:E:vlt1: ******* E N D of Error message *******
2008-01-10[14:02:48]:E:vlt1:
2008-01-10[14:02:48]:E:vlt1: ******* S T A R T of Error message *******
2008-01-10[14:02:48]:E:vlt1: Log message called from /view/port.6.1c.07.11/vobs/tt/mir/mir/main.c: #1670 keyword: signal handler
2008-01-10[14:02:48]:E:vlt1: Pid 21198 Uid 139 Euid 139 Gid 125 Egid 125
2008-01-10[14:02:48]:E:vlt1: user_type N language 2 user_name vlt1 tty ote locale ISO88591/NULL
2008-01-10[14:02:48]:E:vlt1: Errno 0 bdb_errno 0
2008-01-10[14:02:48]:E:vlt1: Log_mesg: Detected database server termination
2008-01-10[14:02:48]:E:vlt1: ******* E N D of Error message *******
2008-01-10[14:02:53]:E:vlt1:
2008-01-10[14:02:53]:E:vlt1: ******* S T A R T of Error message *******
2008-01-10[14:02:53]:E:vlt1: Log message called from /view/port.6.1c.07.11/vobs/tt/lib/nw_1/ipc_fdio.c: #226 keyword: IPC
2008-01-10[14:02:53]:E:vlt1: Pid 21198 Uid 139 Euid 139 Gid 125 Egid 125
2008-01-10[14:02:53]:E:vlt1: user_type N language 2 user_name vlt1 tty ote locale ISO88591/NULL
2008-01-10[14:02:53]:E:vlt1: Errno 32 (Broken pipe) bdb_errno 0
2008-01-10[14:02:53]:E:vlt1: Log_mesg: Connection to server lost: fd_write 8: num_bytes -1 errno 32
2008-01-10[14:02:53]:E:vlt1: ******* E N D of Error message *******
2008-01-10[14:02:53]:E:vlt1:
2008-01-10[14:02:53]:E:vlt1: ******* S T A R T of Error message *******
2008-01-10[14:02:53]:E:vlt1: Log message called from /view/port.6.1c.07.11/vobs/tt/lib/al_1/al_log.c: #1193 keyword: stack trace
2008-01-10[14:02:53]:E:vlt1: Pid 21198 Uid 139 Euid 139 Gid 125 Egid 125
2008-01-10[14:02:53]:E:vlt1: user_type N language 2 user_name vlt1 tty ote locale ISO88591/NULL
2008-01-10[14:02:53]:E:vlt1: Errno 12 (Not enough space) bdb_errno 0
2008-01-10[14:02:53]:E:vlt1: Out of memory while reading in symbol table of /bmnt2/baan4/bse/custbin/bshella
2008-01-10[14:02:53]:E:vlt1: ( 0) 0×000c4b44 [/bmnt2/baan4/bse/custbin/bshella]
2008-01-10[14:02:53]:E:vlt1: ( 1) 0×000c495c [/bmnt2/baan4/bse/custbin/bshella]
2008-01-10[14:02:53]:E:vlt1: ( 2) 0×000c4ce0 [/bmnt2/baan4/bse/custbin/bshella]
2008-01-10[14:02:53]:E:vlt1: ( 3) 0×000d8c84 [/bmnt2/baan4/bse/custbin/bshella]
2008-01-10[14:02:53]:E:vlt1: ( 4) 0×0016e9e8 [/bmnt2/baan4/bse/custbin/bshella]
2008-01-10[14:02:53]:E:vlt1: ( 5) 0×0016df84 [/bmnt2/baan4/bse/custbin/bshella]
2008-01-10[14:02:53]:E:vlt1: ( 6) 0×000d380c [/bmnt2/baan4/bse/custbin/bshella]
2008-01-10[14:02:53]:E:vlt1: ( 7) 0×00107998 [/bmnt2/baan4/bse/custbin/bshella]
2008-01-10[14:02:53]:E:vlt1: ( 
0×001070c4 [/bmnt2/baan4/bse/custbin/bshella]
2008-01-10[14:02:53]:E:vlt1: ( 9) 0×0010cf44 [/bmnt2/baan4/bse/custbin/bshella]
2008-01-10[14:02:53]:E:vlt1: (10) 0×0004d3e0 [/bmnt2/baan4/bse/custbin/bshella]
2008-01-10[14:02:53]:E:vlt1: (11) 0×00043650 [/bmnt2/baan4/bse/custbin/bshella]
2008-01-10[14:02:53]:E:vlt1: (12) 0×00043578 [/bmnt2/baan4/bse/custbin/bshella]
2008-01-10[14:02:53]:E:vlt1: (13) 0×000fa1b0 [/bmnt2/baan4/bse/custbin/bshella]
2008-01-10[14:02:53]:E:vlt1: (14) 0×000430d0 [/bmnt2/baan4/bse/custbin/bshella]
2008-01-10[14:02:53]:E:vlt1: (15) 0×0003c0ec [/bmnt2/baan4/bse/custbin/bshella]
2008-01-10[14:02:53]:E:vlt1: (16) 0×0003cf64 [/bmnt2/baan4/bse/custbin/bshella]
2008-01-10[14:02:53]:E:vlt1: (17) 0×0016e9b8 [/bmnt2/baan4/bse/custbin/bshella]
2008-01-10[14:02:53]:E:vlt1: (18) 0×0016de44 [/bmnt2/baan4/bse/custbin/bshella]
2008-01-10[14:02:53]:E:vlt1: (19) 0×000d43a8 [/bmnt2/baan4/bse/custbin/bshella]
2008-01-10[14:02:53]:E:vlt1: (20) 0×000d6238 [/bmnt2/baan4/bse/custbin/bshella]
2008-01-10[14:02:53]:E:vlt1: (21) 0×00114d98 [/bmnt2/baan4/bse/custbin/bshella]
2008-01-10[14:02:53]:E:vlt1: (22) 0×001079c0 [/bmnt2/baan4/bse/custbin/bshella]
2008-01-10[14:02:53]:E:vlt1: (23) 0×001070c4 [/bmnt2/baan4/bse/custbin/bshella]
2008-01-10[14:02:53]:E:vlt1: (24) 0×0010cf44 [/bmnt2/baan4/bse/custbin/bshella]
2008-01-10[14:02:53]:E:vlt1: (25) 0×0004d428 [/bmnt2/baan4/bse/custbin/bshella]
2008-01-10[14:02:53]:E:vlt1: (26) 0×00043650 [/bmnt2/baan4/bse/custbin/bshella]
2008-01-10[14:02:53]:E:vlt1: (27) 0×00043330 [/bmnt2/baan4/bse/custbin/bshella]
2008-01-10[14:02:53]:E:vlt1: (28) 0×0003db84 [/bmnt2/baan4/bse/custbin/bshella]
2008-01-10[14:02:53]:E:vlt1: (29) 0×0004e050 [/bmnt2/baan4/bse/custbin/bshella]
2008-01-10[14:02:53]:E:vlt1: (30) 0×0004dcd8 [/bmnt2/baan4/bse/custbin/bshella]
2008-01-10[14:02:53]:E:vlt1: (31) 0×0004e5a8 [/bmnt2/baan4/bse/custbin/bshella]
2008-01-10[14:02:53]:E:vlt1: (32) 0×000520dc [/bmnt2/baan4/bse/custbin/bshella]
2008-01-10[14:02:53]:E:vlt1: (33) 0×0002e1a0 [/bmnt2/baan4/bse/custbin/bshella]
2008-01-10[14:02:53]:E:vlt1: (34) 0×0003ba58 [/bmnt2/baan4/bse/custbin/bshella]
2008-01-10[14:02:53]:E:vlt1: (35) 0xc0145c50 _start + 0xc0 [/usr/lib/libc.2]
2008-01-10[14:02:53]:E:vlt1: (36) 0×00020ed8 [/bmnt2/baan4/bse/custbin/bshella]
2008-01-10[14:02:53]:E:vlt1:
2008-01-10[14:02:53]:E:vlt1: ******* E N D of Error message *******
2008-01-10[14:02:53]:E:vlt1:
2008-01-10[14:02:53]:E:vlt1: ******* S T A R T of Error message *******
2008-01-10[14:02:53]:E:vlt1: Log message called from /view/port.6.1c.07.11/vobs/tt/lib/nw_1/ipc_fdio.c: #226 keyword: IPC
2008-01-10[14:02:53]:E:vlt1: Pid 21198 Uid 139 Euid 139 Gid 125 Egid 125
2008-01-10[14:02:53]:E:vlt1: user_type N language 2 user_name vlt1 tty ote locale ISO88591/NULL
2008-01-10[14:02:53]:E:vlt1: Errno 32 (Broken pipe) bdb_errno 0
2008-01-10[14:02:53]:E:vlt1: Log_mesg: Connection to server lost: fd_write 8: num_bytes -1 errno 32
2008-01-10[14:02:53]:E:vlt1: ******* E N D of Error message *******
Resolution:
This issue doesn’t look familiar to me, but the line below from the log.bshell makes me wonder if they’re hitting the per-process memory limit set by one of the HP kernel parameters (e.g. maxssiz)?
2008-01-10[14:02:53]:E:vlt1: Out of memory while reading in symbol table of /bmnt2/baan4/bse/custbin/bshella
Could you have her check the output from “ulimit -a”. This isn’t the first error in the log though, so there’s a good chance that it’s just a symptom of the initial problem rather than the root cause itself, but it’s worth checking.
Also, have they checked the log.informix for any errors at the same time as the log.bshell entries? If they could provide that along with their db_resource file, it might be helpful too.
Although it is very likely that you are experiencing a bug in the way the bshell is handling the shared memory, we will not know for sure, until you install a newer portingset 6.1c.07.14 or higher. The problem seems that is not related to the amount of memory per process.
Probably the problem is related to overwriting a valid memory address. That is why the problem it might be happening only once in a while, and not all the time.
From the description of the fix in portingset 6.1c.07.14, the problem is caused by a memory buffer overflow error.
It can appear when more then 32 logical companies are available.
In your case, several of the finance tables have more than 32 logical companies.
The problem seems that is happening after updating the tables tfgld100, tfgld101 and tfgld106, and does not update the table tfgld109.
Although in the compnr6.1 file there is no specific entries for those tables, looks like some other “tf” tables have 39 logical companies, and some others even more than that.
As I understand, the session is working with a specific batch and completes moving data from tfgld102 to tfgld106, tfgld100 and tfgld101, but when it is updating the tfgld109 the update fails.
So, is possible that before trying to update tfgld109, is trying to read/update one of the tables that have more than 32 logical companies linked, and then fails.
We will only know if you have faced that problem, after installing a newer portingset.
Progress:
The Andersons: Since we are an agricultural company and we’re entering our busy season, we cannot apply the new porting set until June (test) and July (production). It is our understanding that the new porting set still may not solve the issues, but we will have “live” support from infor debugging the porting set in our production enivronment. It’s our understanding that this is related to our extreme multi-company environment (46 comps) and the way memory is allocated.
We are running HPUX 11.23 and Informix 9.40 and Baan IVc4, spak 20 and porting set 6.1c.07.11
