The IE security updates that just rolled out last week are having a bad effect on numerous websites, including PeopleSoft applications. By bad effect, I mean completely crashing Internet Explorer (IE 6 SP1 specifically).

The crash comes fairly quickly when using websites that are served with HTTP 1.1 and using compression. These have been the default settings for PeopleSoft applications for quite awhile now, so

Microsoft has a page up that details this and provides both a workaround and a hotfix. You'll need to contact Microsoft directly for the hotfix - there isn't a direct link to download it.

The workaround, turning off HTTP 1.1, actually causes problems because IE then gets confused by the compressed data coming out of PeopleSoft. This shows up when you start navigating through the PeopleSoft portal and instead of seeing pages, you are asked to save a file. If you look inside the file, you'll see the compressed data that PeopleSoft was sending out.

What you'll need to do instead is to turn off compression temporarily for your PeopleSoft applications. You can do this by going to PeopleTools -> Web Profile -> General and turning off the checkboxes for Compress Response, Compress Response References, and Compress Query. This will require restarting the web server though.

This will definitely hurt network performance for your remote users though, so if you have only internal users with known browser configurations and have not rolled out these IE patches, then you'll have to weigh the pros and cons of waiting on the patches versus the network performance.

Labels: Microsoft, User

A common headache for DBAs managing PeopleSoft applications is not knowing which user a particular piece of SQL is being executed for. This happen because the SQL is being executed by the application server under a privileged user account and not the PeopleSoft user (who probably doesn't even have a database login).

The DBA can go ahead and kill the connection at the database, but they can't explain to the user what happened. Of course, the end user just sees it as a PeopleSoft error (PeopleSoft does not handle killed connections very gracefully) and they try it again. Which just annoys the DBA even further. A vicious circle indeed.

At the Mid-Atlantic RUG last week, this topic came up in a few different discussions. Some of the DBAs there weren't familiar with the EnableDBMonitoring option for PeopleSoft application server domains.

When this is turned on (and it's on by default in PeopleTools 8.43 and up), then each time the application server begins doing work on behalf of a different user than it was previously doing work for, it will set a variable in the database session with information on that user.

Platform Support.

• Oracle. You can see the information in the CLIENT_INFO field of the V$SESSION Oracle system view.
  
• SQL Server. The information is available in the context_info field of the sysprocesses system view in the master database. This is a varbinary field, so you'll need to cast it as varchar to view the data. There is also a PeopleSoft version of the sp_who stored procedure (called sp_pswho) that will return this information. Unfortunately this stored procedure does not get installed automatically when you install PeopleSoft. You'll need to do it manually. A script to install this can be found in appendix B of the SQL Server for PeopleSoft Performance Tuning Red Paper.
  
• DB2/zOS. The DISPLAY THREAD command will display the PeopleSoft user ID in addition to it's regular information. Other DB2 platforms (Windows, Unix, Linux) do not support this command.
  
• Sybase. Later versions of Sybase support this feature, but I'm not sure about how to access the information in the database. I would assume that an additional column was added to the sysprocesses view (similar to SQL Server), but I don't have access to a Sybase installation to verify that at the moment.
  
• Informix. Informix does not support this feature.
  

Labels: Database, Performance