We finally got a solution to our problem, and from the JDE Helpdesk not less. Apparently, we needed to adjust two default parameters on our HP Unix server (it doesn't appear to be listed anywhere on the KG though):
semume (maximum undo structures per process)
semmnu (maximum undo structures in the system)
Our default values were 10 and 30. JDE advised that we change them to 256 and 8192. This fixed the problem with our UBEs erroring, and everything runs fine now. JDE also recommended some other changes as well that we haven't implemented yet but are going to look at.
Besides changing semume and semmnu, you might want to look at the following kernel parameters. None of these suggestions are related to your UBE problem, but just things to think about.
dbc_max_pct - This parameter is currently set to 50, which means up to 50% of you system memory can be used as buffer cache. Using a high percentage of buffer cache can speed up disk/file accesses. This might be OK if you have a bunch of unused memory, but I have seen cases where people have had memory usage issues because this was set too high. If your system has very high memory usage, you might consider lowering this value.
max_thread_proc - Maximum threads per process, currently set to 64. I don't know if you guys are running OneWorld JAS / WebSphere, but if you are (or will be), this parameter is probably too low. If you do want to run JAS, I would recommend something like 256 for this parameter.
msgssz - Size of a message segment, currently set to 8. This won't cause any errors, but it might be slightly more efficient to have it set higher (like maybe 32). Most OneWorld kernel messages are 15 to 20 bytes, and this would make it so that messages are not broken up as often when sent from process to process. You don't want to set this too high though, because then you are just wasting kernel memory. While you're at it, you can probably reduce msgseg to 16384, or even 8192 - this parameter along with msgssz determines the amount of memory the kernel reserves for IPC message queues. I know your tuning guide (which I have not seen) said something about 80400, but this is clearly wrong... and since you are raising the size of each segment (msgssz), you could theorhetically reduce the total number of segments allowed (msgseg) because you'll be using less.
semmni - This can be lowered from the current value of 15320. OneWorld now uses basically a single semaphore array, which consists of 1 identifier containing an array of size "maxNumberOfSemaphores" from the JDE.INI file. This is another case where you are using memory for the kernel that does not need to be used.
semmsl_override - I think semmsl is a Solaris specific parameter. It doesn't look like SAM recognizes what it is. I recommend taking this out of the /stand/system file.
timeslice - Currently set to 10 (default). This is one parameter you might want to look at for performance reasons, but really only if you are running OneWorld and Oracle on the same box. Oracle performs better with a smaller timeslice, but OneWorld performs really badly if you set this too low. If you ARE running both OneWorld and Oracle on the same box, we've found that a value of 7 or 8 can help your DB performance without hurting OneWorld too much, but this is a very touchy parameter, so do some baseline performance testing before you change it, and then compare what happens after the change.
rb
OneWorld XE SP15, Oracale 8.1.6, HP-Unix 11.0, Citrix Metaframe 1.8, IBM Websphere 3.5
