This is a quick handy guide to PeopleSoft Application Designer Project Definition References and their key tables.  In the document PeopleSoft Object Reference you will find a more extensive break down of the common objects and their table references.

This error is caused by the process scheduler (PSUNX) not being able to execute the “lp” program. Typically it is located in the /usr/bin directory. The easiest solution is to simply add this path to the addtopath variable in the process scheduler configuration setup. Typically the cblbin is already there so to append another path simply add it with a “:” colon separator.

AddToPath=/usr/bin:%PS_HOME%/cblbin

Another helpful tip is to make sure the print queues are setup which can be done by entering:

lpstat -t

After installing the incorrect version of Tuxedo for Windows, you may encounter an error trying to install the correct version, complaining that the tuxdirkey is already set.

Run the registry editor (regedit) and delete the keyset:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ORACLE\TUXEDO\

Warning: Changing anything in the registry could cause major system issues, be very careful.

This error is just one that drives you crazy. PeopleSoft has been making the move from a 32bit application to a 64bit application. Almost everywhere you will find the that the application runs in 64bit mode, except for in windows. The client application is still a 32-bit client. So if you are using Oracle for example, you need to ensure that the Oracle client software on the windows machine is 32-bit. This is also true with the tuxedo service, when downloading patches make sure that you download the 32-bit patches.

So if you encounter this error, make sure that the 32-bit libraries are installed and are being referred to for the client. DBBIN variable specifically, and if necessary you may need to add the binary path to the add to path variable in the configuration.

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.