Call Object Kernel Question on an AS400/iSeries

We have an IBM iSeries (AS400) 520 LPAR'd:

LPAR 1 – 16GB 1.5 Processing Units
LPAR 2 – 6 GB 0.5 Processing Units

Everything we read on the number of Call Object Kernels that should be started is 1 Call Object Kernel for every 6-10 per users.

We have about 30 Users (average use is probably 15-20) and 15 DSI (Handheld) users.

Using this figure, in theory, we can get by with 8 Call Object (45/6) Kernels being started.

Well currently throughout many upgrades from World/XE/E811 our Call Object Kernels are sitting at 25 with and Autostart of 5. Multithreaded is turned on. When we

look in Server Manager, each Call Object Kernel only has 1 user attached to it most of the time. Sometimes, a few will have 2 attached to it when the 25 threshhold

is met.

The other day we decided to cut this back to 10 to see if we could cut down the memory being used by the Call Object Kernels.

The system came to a standstill when users logged in the next morning. A few users got in, when I got into the office, users would get the signon screen and IE

would just keep spinning. The handheld devices were getting communication timeouts. I ended up shutting things down, reverting back to 25, and everything worked

again.

I have attached some screenshots of the AS400 and Server Manager activity including some configuration settings.


What are the Call Object Kernel recommendations for an iSeries (AS400)? Are we missing something here? Any AS400 users seeing anything different or can provide

their Call Object User settings and the number of users at their organization.

Thanks.

With the amount of users you have connecting to COB kernels with multithreading turned on you have way more COB kernels than you need. Without looking into it further my guess is you need to increase the number of max threads in the memory pool that the JDE kernels are running in, which looks to be *BASE in your case, to prevent the lock up you had and also make sure that the max number of processes in you JDE.INI is not lower than the number of max kernels that can run.

When the multi threaded kernels just came out I ran into an issue where JDE would continually lock up and it was because they were dead locking because the memory pool they were in was set way too low for the max active threads and the OS was not allowing the threads to do their thing becase of the low limit. You can easily see how may active threads there are in a memory pool and the current active threads via iSeries Navigator.

Setting the COB kernels to 10 in your case should be more than sufficient. My guess is there's another setting somewhere else in the INI or AS400 that was causing the lock up. Did you happen to notice if the kernels were in MTXW when the issue was occurring?

Thanks cjcjunior,

Here's what I found:

>>to prevent the lock up you had and also make sure that the max number of processes in you JDE.INI is not lower than the number of max kernels that can run.

I'm not exactly sure what you mean by "max number of processes". This is what Server Manager (JDE.INI) says:

Maximum Network Processes - 2
Maximum Network Connections - 800
Maximum Kernel Processes - 69
Number of Kernel Definitions - 32

>>When the multi threaded kernels just came out I ran into an issue where JDE would continually lock up and it was because they were dead locking because the memory pool they were in was set way too low for the max active threads and the OS was not allowing the threads to do their thing becase of the low limit. You can easily see how may active threads there are in a memory pool and the current active threads via iSeries Navigator.

See the attached document:

Our Base Memory pool had Maximum Eligible Threads = 290, Current threads were 1523. The Thread count in the JDEE900 Subsystem was 325 at the time.

We changed 290 to 2000.

Should the Maximum Eligible Threads be greater than the JDEE900 subsystems total thread count?
What does your OpsNav Memory Pool look like?

>>Setting the COB kernels to 10 in your case should be more than sufficient. My guess is there's
>>another setting somewhere else in the INI or AS400 that was causing the lock up. Did you happen
>>to notice if the kernels were in MTXW when the issue was occurring?

I didn't happen to check. Since we knew what the issue was, we just reverted the setting and restarted stuff as fast as we could since the users were hung.


Grant

Well, your max eligible threads were set too low. Being that everything is in *BASE for your setup, which is where part of the OS runs also, you will want to make sure you don't have any threads going into an ineligable status, so keep this max active higher or very close to the current active thread count. For the best results you will want to separate your JDE subsystem and UBE subsytem into different pools but that can be done at any time.

I just sent you a private message so we can talk in some more detail offline.