Hi,
I know this is been discussed several times in the past but I am no sure what’s happing in this particular situation I am having with the performance boosters.

I’d been trying to implement the performance boosters using session “Maintain use of performance Boosters (tcmcs0197m000)”. I have setup performance boosters for session Process Delivered Sales Orders (tdsls4223m000) in this session with Display interval set to 60, Number of servers set to 2 and Booster valid set to Manual & Job Process. After setting this up when I run the process delivered sales orders session manually I get these two error messages and session just terminates:

1. “Error in starting server 1; error 0”
2. “Couldn't create process. File=BW.EXE, Parameters=tdsls4224s000 1 2 1 1 0 100 tmp088769392 tmp088769393, Verb=NULL, Error=2”

When I run the same session in a job, the following error message is logged in log.ba6.1 file and the job just hangs:
________________________________________________________________
2004-08-13[15:02:24]:E:bsp: ******* S T A R T of Error message *******
2004-08-13[15:02:24]:E:bsp: Log message called from /view/port.6.1c.07.04/vobs/tt/ba/ba/baerrhand.c: #100 keyword: bshell message
2004-08-13[15:02:24]:E:bsp: Pid 7580 Uid 125 Euid 125 Gid 125 Egid 125
2004-08-13[15:02:24]:E:bsp: user_type S language 2 user_name bsp tty 4 locale ISO88591/NULL
2004-08-13[15:02:24]:E:bsp: Errno 0 bdb_errno 0
2004-08-13[15:02:24]:E:bsp: Log_mesg: Fatal error: Use of NULL pointer on ''
2004-08-13[15:02:24]:E:bsp: ******* E N D of Error message *******
2004-08-13[15:02:24]:E:bsp:
2004-08-13[15:02:24]:E:bsp: ******* S T A R T of Error message *******
2004-08-13[15:02:24]:E:bsp: Log message called from view/port.6.1c.07.04/vobs/tt/ba/ba/baerrhand.c: #100 keyword: bshell message
2004-08-13[15:02:24]:E:bsp: Pid 7580 Uid 125 Euid 125 Gid 125 Egid 125
2004-08-13[15:02:24]:E:bsp: user_type S language 2 user_name bsp tty 4 locale ISO88591/NULL
2004-08-13[15:02:24]:E:bsp: Errno 0 bdb_errno 0
2004-08-13[15:02:24]:E:bsp: Log_mesg: Fatal error: Can not continue in tdsls4224s000 in DLL: otfglddll4011 (get.company)
2004-08-13[15:02:24]:E:bsp: ******* E N D of Error message *******
2004-08-13[15:02:24]:E:bsp:
2004-08-13[15:02:24]:E:bsp: ******* S T A R T of Error message *******
2004-08-13[15:02:24]:E:bsp: Log message called from /view/port.6.1c.07.04/vobs/tt/ba/ba/baerrhand.c: #100 keyword: bshell message
2004-08-13[15:02:24]:E:bsp: Pid 7580 Uid 125 Euid 125 Gid 125 Egid 125
2004-08-13[15:02:24]:E:bsp: user_type S language 2 user_name bsp tty 4 locale ISO88591/NULL
2004-08-13[15:02:24]:E:bsp: Errno 0 bdb_errno 0
2004-08-13[15:02:24]:E:bsp: Log_mesg: Error: tdsls4224s000: A not terminated transaction is aborted
2004-08-13[15:02:24]:E:bsp: ******* E N D of Error message *******
________________________________________________________________
I am not sure what step I am missing. We are on portingset 6.1c.07.04.

Please let me know what you guys think.

Appreciate your help,
NS

Do you have your password saved in your default BW configuration? that's required...

but the error 2 makes me think maybe you do not have enough message queues configured.

Check out Dikki Dick's Performance guide (sticky) down in the Performance Forum, it's got some info on what needs to be setup for these.

also make sure you have the absolute latest tccomdll0200

Dave

Dave,
Yes, i have the password saved. I will look at the tccomdll0200.

Thanks,
NS

Also make sure that the BECS configuration is defauleted and that if you start BW from the DOS prompt, you start the correct Baan environment.

Dave/Dikkie,
Thanks for your help. After I setup the PATH variable to point to where the BW.EXE file is, I was able to start bw from the dos prompt just by typing bw. Now, the performance boosters are working with out any errors but only when I run the session manually even though I have the “Booster Valid” field set to Manual & Job Process. When run the same session in a job, I am still getting the same error messages I mentioned in my earlier post. Is it because we have BaaN running on a UNIX machine and there is not bw client there?

Thanks for your help,
NS

If you start a job daemon, the BSE/bin should be in the path of the jobdaemon script to start a new bshell.

As you discovered, a new BW will be started when starting from a PC, when startin a job daemon or job on UNIX level, this is not used, instead of the GUI interface (BW) interface, the ASCII interface (BA) is used.

BTW. From 5.2 an onwards, the server processes will run without interface by default.

Hope this helps,
Dick

Dick,
I checked the path on the Unix machine and it does have the $BSE/bin.
_________________________________________________________________
baan02:/local/home/bsp $ echo $PATH
/baanc/bse/bin:/baan/informix/bin:/baanx/oracle/product/8.0.5/bin:/baanx/oracle/product/8.0.5/bin:/baanc/bse/bin:/usr/bin::/opt/hpnpl/
bin:/usr/ccs/bin:/baan_daids
_________________________________________________________________

I can also start BaaN by just typing ba6.1.

I know Dave mentioned something about message queue configuration. Not sure how that works. Does anyone have a guide on this?

Thanks for you help,
NS

Weird about the error. Anyway, the document can be found at Kernel doc (http://www.baanboard.com/baanboard/showthread.php?t=7696).

Hope this helps,
Dick

I just looked up the Kernel parameters on our system and I can see that the msgmax and msgmnb is already set.
______________________________________________
*BAAN CONFIG
* set test_module:debug = 0x13

set rlim_fd_cur=1024
set max_nprocs=1024
set maxusers=256
set shmsys:shminfo_shmmni=1024
set msgsys:msginfo_msgmax=32768
set msgsys:msginfo_msgmnb=32768
set shmsys:shminfo_shmmax=131072000
set shmsys:shminfo_shmmin=100
set shmsys:shminfo_shmmni=100
set shmsys:shminfo_shmseg=100
set semsys:seminfo_semmap=64
set semsys:seminfo_semmni=4096
set semsys:seminfo_semmns=4096
set semsys:seminfo_semmnu=4096
set semsys:seminfo_semume=64
______________________________________________
Are the values specified in the Kernel are high enough to handle the multiple bshells? Am I missing any other settings in the Kernel as far as the message queues go?

Thanks for your help,
NS

did you get a chance to check comdll0200? if there's going to be a problem with mutli bshell its usually with that..

Dave

Dave,
Yes, I looked at the tccomdll0200 and the object I have is as of 02-03-2000. I know it is an old object but unfortunately we don’t have BaaN support and can’t get the new one. But, if the performance boosters are working when the session is run manually shouldn’t the same apply to job? May be not.

Thanks,
NS

No, becuase of what you've seen with the BW.. In job mode it does not
use the BW.. In 2003 major fixes were made which allowed it to basically "Work" for the first time since i've been using Baan..

Dave

Thanks Dave. I guess I am going to have to try and get the latest dll.

Thanks,
NS

I think so.. I remember trying to get multibshell to work back in 2000, it was not fun, it just didn't work...

Dave

I wonder if log.comdll0200 says something interesting.

Dave/Dick,
Thanks for your help. I got the performance boosters working now. Both for manual and job process. It turned out that I was not setting up the boosters properly which caused the job to crash.
I got one more quick question. About the number of servers, I am not sure what is the ideal number. We have 4 cpu’s on our server and I tend to think that we should use 3 as number of servers. I am trying to find out how to determine the number servers.

Thanks again,
NS

Glad you made it.

Regarding your question: it depends. It depens on:
- other users/ processes. If there are other processes that need CPU, you should lower the number of CPU's.
- if CPU's is the bottleneck. If you have another bottlneck like disk or memory, you can maybe better lower the number of CPU's
- if you face locking contention.

If no of these applies and you run in host mode (2-tier), you can use upto the number of CPU's of your system.

When running in 3-tier, you can even use more.

For all situations counts: only when you measure, you are sure.

Hope it helps,
Dick

Way to go, I'm impressed you can get it running with such an old comdll!

I agree with Dick above.. never higher than # of CPUs and lower if you need CPUs for other things (even though the process won't take 100% of the cpu...)

Dave