Just to drive the system administrator nuts, for some reason Redhat sysctl parameters by default are not robust enough to handle starting up even a small application server. There are several cases on My Oracle Support that explain how to set the variables but at a minimum I found this to a good starting point:

fs.file-max = 65536
kernel.msgmni = 512
kernel.msgmax = 1048576
kernel.msgmnb = 1048576
kernel.shmmni = 4096
kernel.shmmax = 33554432
kernel.sem = 250 256000 64 1024

You can add/modify these entries in the sysctl.conf file (/etc/sysctl.conf). Once they are modified you can put them into effect by issuing sysctl -p. If you want to do a change temporarily you can issue: sysctl -w parameter=value.

I just started working for a new client, and they have a very long domain name, and then the new servers they created for their new HR 9.1 environment were on a subdomain as well.  So the server name (LMID – logical machine ID) exceeds 30 characters in length, which happens to cause Tuxedo to get very angry.  I found the easy way to resolve this issue is by doing the following:

Step: 1
Add a new environment variable called PMID (physical machine id). The value I set to simply the machine name (without the domain).
export PMID=psappmachine1

Step: 2
Verify that there is a psappmachine1 reference in the hosts file so that the IP can resolve
more /etc/hosts

Step: 3
Change the psappsrv.ubx file that is in the $PS_HOME/appserv directory. Change all references to {MACH} to the value of PMID, making sure that the case matches exactly.
vi psappsrv.ubx
:%s/{MACH}/psappmachine1/g

Step: 4
Build a new domain for the application server and there should be no CMDTUX_CAT:122 or 868 errors.

This is a super awesome Red Paper from Peoplesoft (Oracle), on clusering and high availability.  Should be in every system administrators handbag.  Tools Clustering

It really amazes me how many times I find at client sites Application Servers that randomly won’t start. There are a combination of issues that can cause the problem, but typically I find the problem to be related to this group of tables.

PSSTATUS – this table has a field called OWNERID, which needs to make the schema owner in Oracle, and should match the ACCESSID in SQL Server.

PSACCESSPRFL – this table has the fields SYMBOLICID, VERSION, ACCESSID, ACCESSPSWD, ENCRYPTED. The accessid should match the OWNERID from PSSTATUS table, and the password would be the password at the database level for the schema/accessid user. If you change this to an unencrypted value you will want to change the accesspswd to an unencrypted value and set the encrypted field to 0, and then run datamover and do the encrypt_password *; statement to reencrypt the passwords. You will also notice the SYMBOLICID field, this is associated to the SYMBOLICID field on the PSOPRDEFN table. VERSION can be reset using the VERSION Application Engine. I recommend that there only be one entry in this table, sometimes having multiple entries can cause problems if the accessid/password are invalid for the environment, because PeopleSoft has a tendency to expect only one entry in this table.

PSOPRDEFN – this is your primary parent information table for security. Make sure that the password is set correctly, if you reset it to a clear text entry, you can reencrypt it using the encrypt_password *; command in datamover. Make sure you set the encrypted field to 0 (zero) before running datamover. You will also want to make sure that the SYMBOLICID matches that of the PSACCESSPRFL table. Lastly, make sure that the ACCTLOCK is set to 0 for the user trying to start the Application Server. You will also want to make sure it has a Permission List that allows it to start the application server.

PS.PSDBOWNER – In Oracle there is another table in the PS schema that contains the Database Name and Owner, make sure these are set correctly.

Make sure that the connect id user often known as “people” is setup in your database and it has been granted select access to the tables: PSACCESSPRFL, PSSTATUS, PSOPRDEFN.

Lastly, make sure that the USERID matches your user that you want to start the Application Server from PSOPRDEFN, and that the password is set correctly, and make sure that the CONNECT ID user / password is correct in the configuration files of the application server.

The typical 2-tier connect takes the userid and authenticates it against the PSOPRDEFN table using the connect id user, which in turn allows a connection to be made to the database using the symbolicid associated with the PSOPRDEFN table, which is tied to the accessid on the PSACCESSPRFL table. So once authenticated that system is actually running the session as “accessid” but controlled by the PeopleSoft security assigned to the user.