Linux uses an utility called uncompress to decompress *.Z files, however, it is not always installed by default.  It should appear in the /usr/bin folder as uncompress.  If it is not there, you can install the uncompress RPM, or you can use the gunzip program to uncompress the files by make a symbolic link.

ln -s gunzip uncompress

You might also want to make sure you have enough temporary space to uncompress the files.

In working with a new site, I was installing a new certificate into the system and everything appeared fine until I tried to install the actual certificate.  I received the error:

keytool error: java.security.cert.CertificateException: java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big.

As it turned out, I had an extra blank line at the end of the import file. These extra characters at the end of the certificate file causes the “parser” to interpret as the start of another certificate. So make sure that there is nothing after the “—–END” line.

Commonly when setting up a new system, you will attempt to post a report and it will stay in posting status for a long time and eventually return a Not Posted status.  If you review the details on the message log you will find something similar to:

Error: The XML file returned by the webserver is invalid, xml document object creation failed.

When setting up a report node (Home>PeopleTools>Process Scheduler>Report Node) and you use the SchedulerTransfer as the transfer tool, you must ensure that two things are in place.

1. Make sure that the Default Local Node, has a password assigned to it.  Without a password it will always fail.

2. Make sure the user that started the Process Scheduler has the Role: ProcessSchedulerAdmin assigned to their profile.

This should resolve the problem.

After many years of working with PeopleSoft I try not to get to worried about the little things, because so much changes every day that you could lose your mind trying to keep track of it all.

I was doing an install of the Oracle Database software on a new RHEL 5.8 server the other day and I could not get my X11 forwarding working.  Now I don’t claim to be an expert in SSH and never will be, but I use the Bitvise Tunnelier and then use XMing for the SSH/X11 client software.  On this server I had setup the SSH Daemon to run X11 forward on using the default off-set 10.  This basically means that the communication for X11 will be on port 6010 instead of 6000. This means that your display variable will need to be set differently.  This is the export command I used:

export DISPLAY=localhost:10.0

In a lot of cases it will just show you 0.0, but because of the offset you need to change to 10.0 when using the off-set of 10. When setting up my SSH connection in Tunnelier, under the terminal tab, you need to enable X11 forwarding, and you will need to change your Display variable appropriately, in my case I was using the offset: 10, so I entered:

127.0.0.1:10.0

Lastly, I found that the XMing client defaults to NO offset, so when I launched XMING launch, on the first page it asks what the offset should be be.  Once I changed that to 10, everything started working great.

It should also be noted that if you are using a firewall (in my case iptables) you will want to make sure port 6010 is open correctly if using the ssh-offset 10.

The common error I got with this configuration being wrong as: Windows TCP error code 10061.

When creating a new server the other day, I was attempting to start the application server and a ran into an odd error message that did not seem to have any solution from PeopleSoft’s support or even google for that matter. This error was found in the stderr output file for the application server:

ERROR: dlopen in libpscompat failed for ‘libpsora.so’: libclntsh.so.10.1: wrong ELF class: ELFCLASS32

I couldn’t find anything specifically wrong with the symbolic links in the library directories for Oracle as the sites were suggesting.  The weird thing that kept the red flag waving was ELFCLASS32.  After some more review of the environment I had just created, I found that I had installed the Oracle Database software using a 32bit Linux version instead of the Linux_x86_64 bit version.  This was caused by simply not paying attention when I was downloading the software.  When downloading the software if you try to download from the main site they only let you download 11.2.0.1, but for PeopleTools 8.52.xx you want to be at 11.2.0.3.  After logging into support and search for patchset 11.2.0.3 the page that comes up has a drop down, and there is a Linux version and a Linux_x86_64 bit version (much further down).  After I installed the correct version and recreated the database, the application server started without any issues.