Multi-threading on AS/400

Has anyone had any experience with implementing multithreaded call object kernels on the AS/400 platform? I'm thinking about enabling it but don't know if there's any "gotchas" to look out for, like required PTFs, etc, and haven't found many who have done it yet. I figured if it was stable enough Oracle would have enabled it automatically by default like all the other platforms, but they haven't yet. My thinking is "If it ain't broke don't fix it", which is mainly why I haven't enable it yet. Using 8.12, TR 8.96.2.2.

Thanks.

I have multi-threaded kernels enabled at 6 live 812 customers and 4 who are preparing to go live (3 of these are 8.97.0.2, one is 8.96.2.2 and the rest are 8.96.1.1). 3 of the live customers are on V5R4, 2 preparing to go live are on V5R4 - the rest are SQL/Windows.

I also have multi-threaded kernels turned on at 2 811 SP1 clients running on V5R3.

Colin

I have two sites running on V5R4 that have multi-threading enabled. There have been no issues attributed to it and in fact they have enjoyed more consistent performance for web users. I have multi-threaded sites on Windows and Unix as well and the results have been similar.

I can think of two reasons that Oracle would not enable it out of the box: 1) not everybody taking 8.96 is on 8.11SP1 or higher. If you are on a pre-8.11SP1 release your business functions are not thread safe. 2) Multi-threading increases system throughput for business function execution. The result of this could be increase CPU utilization. You need to consider this when switching multi-threading on.

I agree with your "ain't broke, don't fix it stance". However I wouldn't assume that the current state of your system isn't broken. Depending on your particular use of the system the performance of web transactions experienced by your users may be inconsistent. Being attached to a single-threaded call object kernel is like getting in line at the supermarket. You may be behind a line of people who are just buying a gallon/liter of milk and moving on or you might get stuck behind someone who has 50 items, makes chit-chat and fumbles with their money. Even if you are only buying 1 item you are stuck waiting on those in front of you. Multi-threading is like standing in line where an infinite number of cashiers pop out of nowhere and call the next person. You always get served immediately.

The issue I have with the way Oracle has implement multi-threading is that they do not enforce a hard limit on the number of threads a kernel can spawn. You can set a threshold value where if exceeded a message will be logged into your kernel logs. It is only a warning and more threads will be spawned above that threshold. What I would have liked to see was multi-threading up to the threshold and then queuing after that. This would allow you to set a hard limit on the number of concurrent business functions executing at any one time.

I have done a comparative stress test between the single-thread and multi-thread modes and I was able to completely overload a server under multi-threading to the point that it became unresponsive and had to be restarted. This was not an iSeries which would have hopefully been en a bit more resilient when overloaded. My results were under an extreme volume of requests. Most of my sites running multi-threading have seen an increase in CPU utilization but have not exceeded CPU capacity. I would recommend you try to gauge how consistent your end-user's performance experience is. If you suspect they are getting held up by long running business functions I suggest you try multi-threading first in non-production and see how things go.

A final note: It appears that there are issues with DSI against multi-threaded call objects kernels. I have found on two sites that under multi-threading there are intermittent business function failures in DSI NER's. I have had discussions with both DSI and Oracle and the consensus was that DSI seemed to be more reliable against single-threaded kernels. We don't have any hard evidence as to why. We just know that putting things back to multi-threading made things 100% reliable versus 95% reliable. Those two sites are therefore running a dedicated logic server for DSI BSFN's. If you don't use DSI then you don't have to worry about it.