Application Server

Could Not Create Shared Cache

One of the causes of the error Could not create shared cache. (0,0) on the signon screen is if the application server is running low or has run out of disk space.


Large log files from traces are a common cause of this error, particularly if you are using application server tracing, so once you clear up some space, check that you don't have any unnecessary tracing turned on. Freeing up some disk space seems to resolve the error without the need for any server restarts.

WebLogic PIA Java Home

While setting up the PIA for Oracle WebLogic, I was getting the following message (this is on Windows servers but has similar implications on Linux):

The JRE was not found in directory C:\Oracle\JRockit. (JAVA_HOME)
Please edit your environment and set the JAVA_HOME
variable to point to the root directory of your Java installation.
Press any key to continue . . .

Weird, since JAVA_HOME was set up correctly in environment variables and did not equal the value in the message shown (should be C:\Oracle\JRockit\JRE). Turns out, Weblogic reads this from the script commEnv.cmd (or for Linux). Open this script and look for JAVA_HOME and adjust accordingly.

Note in my case, this script is located under the WebLogic installation directory and then common\bin.

Monitor Sessions through WebLogic Console

The weblogic console allows you to monitor the number of sessions on your PeopleSoft application.

First, login to the console using the following URL format:


You will need to login with the appropriate credentials which were set when installing WebLogic.

From here, click on the OK link in your system status (bottom-left):


Expand the server/subsystem name (e.g. PIA) and click on the PeopleSoft application:


Next, find and click on the root of the PeopleSoft site:


In the settings click on Monitoring and you will see information about sessions related to your PeopleSoft site as shown:


Tuxedo Message Catalogs Error

I was playing around with getting the PeopleTools client (application designer, configuration manager, data mover etc) when I tried logging in through the application server and received the follow error: (I've dummied values to protect the innocent :)

Could not connect to application server YOUR_PS_DB (// 
Make sure the Tuxedo message catalogs (CMDTUX_CAT, etc.) are in C:\ORACLE\PEOPLESOFT\Tuxedo. 
Contact your system administrator or check the Tuxedo log for more information.

I love how they still tell you to contact your system administrator...

Anyway, this message tells you exactly what is wrong - you don't have the tuxedo folder where it is trying to find it - in this example C:\ORACLE\PEOPLESOFT. So copy the tuxedo folder including the subfolders locale and udataobj.

NOTE: if you are missing the locale folder you will get the same message.

If you are missing the udataobj folder you will get the following message:

Could not connect to application server YOUR_PS_DB. 
Make sure the PeopleTools authentication server (PSAUTH) is booted

Application Tracing

Firstly PeopleSoft gives you the option to set trace flags from the sign on screen:


It is particularly useful for tracing sign on (e.g. SSO), however it is too cumbersome to trace a particular component or page. If you need to do that, I recommend logging in normally and then using the tracing options available from:

PeopleTools > Utilities > Debug

Once you click the signon trace link, you're given a myriad of tracing options:


Its up to you to decide what you need, but remember, with tracing, less is often more, don't get carried away. After all, you're looking for a needle in a haystack, no need to make that haystack bigger than it needs to be!

NOTE: the signon tracing link can be disabled through web profile settings. However, there's a way around this. If you notice your URL when you click the hyperlink it changes and includes a trace directive:

Regular signon URL is something like this:


With tracing, the signon URL includes the trace directive:


So, regardless of whether you can see the hyperlink, you can still turn on signon tracing using the trace directive.

The Connect ID

The connect ID is used from PeopleTools 8+ and was implemented to replace the need for PeopleSoft to create users in the database.

The connect ID is a valid database user that is used during two-tier (database) signon. So it applies to tools such as application designer and data mover.

If you don't have a connect ID configured in configuration manager or you have the wrong connect password then you will get an invalid access ID and password for signon error EVEN if you use a valid PeopleSoft login (user name and password).


Invalid Access ID and password for signon -- see your security administrator.

Use configuration manager to set the correct Connect ID in the Startup tab:


NOTE: that you can't get the connect password from the configuration file easily as it is encrypted.

Redirect To Login Page

When you access the root level of your PeopleSoft site, you normally get a web server message that allows you to click on a link that will take you to the login page.

Here's a screenshot example of what I'm referring to with Weblogic:


For various reasons (e.g. security, user-friendliness) you might want to instead do a redirect directly to the PeopleSoft login page. You can achieve this with a meta tag redirect on the HTML page.

First, navigate to your web server directory, and under PORTAL or PORTAL.WAR find the file {{index.html}. This is the page you see by default.

At the top of this file, just below the first tag, add the following:

<html><head><meta http-equiv="Content-Type" content="text/html;CHARSET=iso-8859-1">
<meta http-equiv="refresh" content="0; URL=../ps/signon.html"> 
<!-- Start of Oracle comments ...

The line to you want to add is <meta http-equiv="refresh" content="0; URL=../ps/signon.html">.

NOTE: the 0 indicates no timeout - i.e. automatic redirect. If you set this to a value greater than 0 it will wait that many seconds before performing the redirect.

For a brief second you do see the web server page (and also if the signon page takes a while to load), so if you like, change the heading, e.g.:

<h1>Welcome to Weblogic Application Server 10.3&#153;</h1>

To something that tells the user it is redirecting:


I like this because you no longer need to remember the exact path to the signon page or have to do that one extra click to get there. Instead you can just type server:port into your browser address bar and you'll be at the signon page.

The Structure of PS_HOME

Here's an overview of the structure of the PS_HOME directory on a typical PeopleSoft file server. Note yours may be slightly different!



dlopen in libpqscompat failed

If you get the following error:

dlopen in libpqscompat failed for '':

Try appending:


(adjust for the relevant JRE location) to your $LD_LIBRARY_PATH environment variable.

CMDTUX_CAT Fatal error encountered

If you get the error:

CMDTUX_CAT:827: ERROR: Fatal error encountered; initiating user error handler

It indicates that the IPC resource settings are not sufficient. This involves modifying the system control settings under /etc/sysctl.conf in particular things like the following (although there might be others and this is just an example):

kernel.sem 250 32000 100 128
kernel.msgmni = 8192
kernel.msgmax = 1048576
kernel.msgmnb = 1048576

This needs to be changed as the root user and reloaded using sysctl -p.

LIBTUX_CAT Failure to create message queue

If you get the error:

LIBTUX_CAT:681: ERROR: Failure to create message queue
LIBTUX_CAT:248: ERROR: System init function failed, Uunixerr = : msgget: No such file or directory
ERROR: Process PSRENSRV at server.domain failed with /T tperrno (TPEOS - operating system error)

Make sure that after changing the /etc/sysctl.conf you do a reload with sysctl -p before attempting to start an application server domain.

Error Setting Sign on PeopleCode context for User

The first sign you might have this error is if you see the following message on the sign on screen:

bea.jolt.ApplicationException: TPESVCFAIL - application level service failure.

You can usually still login and use the application. What tweaked me to a deeper problem was that the web profile I expected (DEV) was not being used, and so the CTRL+J option was not available. On checking the application server logs, I found the following messages (formatted for readability):

Error Setting Sign on PeopleCode context for User @MACHINE: Sign on PeopleCode was not executed
PeopleSoft ID and Password authentication failed. Invalid user {V1.1}JP9ukEkTssmYrzsK1yvXFg==@MACHINE.
{V1.1}JP9ukEkTssmYrzsK1yvXFg==@MACHINE is an Invalid User ID, or you typed the wrong password.  
User ID and Password are required and case-sensitive. Make sure you're typing in the correct upper and lower case.  
Failed to execute GetCertificate request

First I checked there was nothing wrong with the encrypted user PTWEBSERVER, ensuring the correct password and encrypted password in, the account was unlocked, and they had the role PeopleTools Web Server. In fact nothing had changed at all in terms of web server configuration.

Eventually, I found that the windows firewall might have been blocking the java process for the web server. Since the web server was being started by a service, this was not evident. I only realised the problem after stopping the service and then trying to manually start it with the startPIA.bat file under PS_HOME\webserv\{DOMAIN}\bin\startPIA.bat. When I did this, it brought up the windows firewall dialog asking to allow private/public network access for Java which I accepted.

I then stopped the PIA with the stopPIA.bat file (in the same folder), and then started the PIA using the service. However the problem came back. So I uninstalled the service using PS_HOME\webserv\{DOMAIN}\bin\uninstallNTServicePIA.cmd and then installed it again using PS_HOME\webserv\{DOMAIN}\bin\installNTServicePIA.cmd.

This fixed the issue. Perhaps it was an issue with the service all along? If that's the case, then simply uninstalling and re-installing the service might be all that you need to do to fix this.

Site Booted With Internal Default Settings

If the following error message appears on the login page:

BECAUSE OF: bea.jolt.ApplicationException: TPESVCFAIL - application level service failure

The first thing to do is to check your application server logs as stated!

There may be an issue with the PTWEBSERVER user or which ever user is used to start the web server.

You can check this by looking at the file which lives on the web server under portal\web-inf\psftdocs\ps\ in the home folder of your PeopleSoft application.

Note that both the WebUserID and WebPassword in this file are encrypted. You can check these are correct using the PSCipher utility:

Encrypted text: {V1.1}JP9ukEkTssmYrzsK1yvXFg==

If the PTWEBSERVER account has been locked, or if the password has been changed, you will need to update the WebPassword accordingly using PSCipher.

The user specified to start the web server is specified when you install the PIA.

The other thing to check is that the user PTWEBSERVER has access to the PTPT1500 permission list:

select * 
and OPRCLASS = 'PTPT1500';

Check your application server log file, you'll see messages like this if for example the PTWEBSERVER password has been changed but not update everywhere:

PeopleSoft ID and Password authentication failed. 
Invalid password for user PTWEBSERVER@SERVER.
PTWEBSERVER@SERVER is an Invalid User ID, or you typed the wrong password.  
User ID and Password are required and case-sensitive.  
Make sure you're typing in the correct upper and lower case.

If you see a line like this in your application server logs after a PeopleTools upgrade:

PeopleTools release (8.49) for web server '' is not the same as 
Application Server PeopleTools release (8.49.23).  Access denied.

It means that you need to reinstall the PIA. To do this in Oracle Application server:

If the following message appears on the login page:

BECAUSE OF: bea.jolt.ServiceException: Invalid Session

Check your file which lives in the WEB-INF\psoftdocs\<site> folder.

For example on PeopleTools 8.50 with Weblogic the path might be:


The problem might be the hostname/port specified for psserver or psservername E.g.:


Check that you have the correct server name and port here. Also make sure you use a host name and not an IP address. If this is incorrect. Stop the web server, fix the values and then start it back up again. This might have changed after you applied a PeopleTools patch - so make sure you backup before you apply a patch. Also check that the PTWEBSERVER user account is not locked.