Hi,
I have held off replying to this post whilst we finished our engagement with JDE Response line and Oracle critical accounts for a similar issue that you are having with 8.97 and a customers system locking up.
We noticed substantial differences between 8.96 and 8.97
Our customer is on OAS rather than WebSphere, but we also temporarily installed WebSphere to do web server comparisons.
The settings that you mention for HTTP and also the registry settings were done and did help a bit, but the final solution was more than that.
1. Open regedit.exe
2. Navigate to [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings]
3. Add a new DWORD entry named "MaxConnectionsPerServer"
4. Set the value of this new key to Decimal "10" or Hexadecimal "a"
5. Add a new DWORD entry named "MaxConnectionsPer1_0Server"
6. Set the value of this new key to Decimal "10" or Hexadecimal "a"
7. Close "regedit.exe" and restart the browser
NOTE: Since this registry setting change is to HKCU, make sure it is being for the USER that will be running E1 on this particular machine.
8. Open Internet Explorer
9. Select "Internet Options" from the "Tools" menu
10. Navigate to the “Advanced” tab
11. Find the entry for "Use HTTP 1.1 through proxy connections" and ensure that it is checked.
12. Press OK
NOTE: Make sure that your Internet Explorer 6 or 7 is patched to the latest version or these settings may not resolve the issue.
The other parts of the final solution for us were:-
No JDE PC should have less than 1Gb RAM and 1.5GB of swap space (this alongside the http and registry changes) made a vast diference to some users. 8.97 is more demanding on resources than 8.96.
Upgrade of OS (again for some users) from Windows 2000 to Windows XP (minimum) again we gained another boost to performance for these users.
We also needed to download 2 OAS patches (6880880 & 6390846) which gave us a big boost to WAN users in countries other than UK (where the system resides). This may not be the case for you as your sig block indicates you are on WebSphere. The one thing we did find was that when WebSphere "locked up" it just left our users with a blank screen, when OAS "locked up" it would eventually return (anywhere between 5 and 55+ minutes later) the screen to the user with no loss of data or position in the transaction.
The last piece of our puzzle was using network sniffing tools and database utilities to investigate sql statements from customised applications that showed long delays in the system and then applying new indexes to the "offending tables". 8.97 appeared to be less tolerant of "incomplete code".