Every now and then I find that I am battling permission issues in the unix environment and it usually turns out to be the permissions that are set on the directory or file.  Unix has an interesting way of handling permissions.  If you do a list command “ls -l” you will see a box of information on the left that looks like:

———- (10 dashes) If you see this, the file has NO rights (pretty rare).

The first position you will commonly see a “d” or “l”, the “d” is for directory, and “l” is for a link.

Position 2 to 4 are the owner permissions “rwx”, where “r” is read, “w” is write, “x” is execute

Position 5 to 7 are the group permissions “rwx”, where “r” is read, “w” is write, “x” is execute

Position 8 to 10 are the world permissions “rwx”, where “r” is read, “w” is write, “x” is execute

You can change the permissions using the command: “chmod”

To grant the read permission you give a value of 4, write permission is 2, and execute is 1.  So if you want to grant read+write, you would do 4+2 = 6.  And when you issue the chmod you give it a number for each permission (owner, group and world), so if you wanted to give the owner, group and world read and write access to a file you would issue the command:

chmod 666 filenametochangepermissionsto

Another useful function is the chown function, which changes the owner and/or group permission.

chown user:group filenametochangeownershipto
chown -R user:group directorytochangeownershiptorecursivelyto

When configuring the Report Repository using the Scheduler Transfer tool you will want to configure the node using the http/https settings:

Home > PeopleTools > Process Scheduler > Report Nodes

The URL will be the same as it always is, this variable is primarily used for the link in process monitor to view the reports/logs.  The URI host is usually set to the web server name, however, if you are using a load balancer you might wish to use one web server to handle the traffic or configure it to go to an internal site that can handle the balancing.  URI Port will be the port of the webserver, typically the regular access port, but if you are using a balancer and it is redirecting the port may need to setup with the internal port number.  URI Resource is the class that handles the transfers, it should be:

SchedulerTransfer/<piasite>

Be very careful of case here.  See picture as an example.  Lastly, you will want to make sure that the user that is handling the process scheduler in question has the Role: ProcessSchedulerAdmin, and that the default Local Node has been configured to have a password associated with it (Home>PeopleTools>Integration Broker>Nodes).

When doing the initial installation for most PeopleSoft environemnts you need to do several installations one of them being Cobol Server Express if you are running Cobol on a Unix environment.  Most PeopleSoft 9.1 applications support using version 5.1.

After you get the license installed, you need to ensure that the license manager is running.  Three commands will come in handy here:

1. Stopping License Manager, you need to be root to do this:

cd $COBDIR/lmf
lmfgetpv k

2. Show Status of License Manager: (If running it will return the version, if stopped it will report it is stopped)

cd $COBDIR/lmf
lmfgetpv

3. Staring License Manager, you need to be root to do this:

cd $COBDIR/lmf
sh ./mflmman

You can change the directory to {COBDIR}/aslmf and then run ./apptrack If this is the first time it will ask you to set a password or enter in 6 blank spaces to set the password to null. Once the password is set, you can select from the list of options to show a license summary. This should show your license you have installed, and if it doesn’t you can install your license from this menu.

If you are using a LMF Development License, you can install it by going to {COBDIR} and running the command:

sh mflmcmd

Enter I to install a license, enter in your Serial and License numbers you received from Oracle. You should now be able to go back into apptrack and see the installed license.

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.

Peoplesoft has an interesting authentication process, and basically it goes something like this.

When you attempt to login in a 2-tier mode, for example in HR trying to log into application designer using the user “PS”, what will end up happening is it will lookup the connect id and password that is assigned in the Configuration Manager setup (pscfg). This user is a database user typically called “people”. This database user is granted select access by the grant.sql script when the system is built on the tables: psstatus, psoprdefn, psaccessprfl. In Oracle there is another table that this user can access and that is PS.PSDBOWNER (there is a public synonym so you can just look for PSDBOWNER).

The PSSTATUS table needs to have the OWNERID field set the main owner of the database. In Oracle it is by default “sysadm”, in SQL Server the default was typically “sa”, but that changed with the introduction of the access id profile, and so it would be the access id that you setup that should be in this field for SQL Server.

The PSOPRDEFN table needs to have the OPRID you are trying to log into with, and the OPERPSWD needs to be set correctly, this field is encrypted, but if you need to change it, go into SQL and update the password, and make sure you change the ENCRYPTED field to “0” zero. Then you can re-encrypt the password by running datamover in bootstrap mode and executing the command: ENCRYPT_PASSWORD *;. Also note the field SYMBOLICID, it needs to match the SYMBOLICID in the psaccessprfl table.

The PSACCESSPRFL has the fields SYMBOLICID, ACCESSID and ACCESSPSWD. The SYMBOLICID needs to match the symbolicid of the psoprdefn table entries. You can have multiple SYMBOLICID’s however, make sure they are all valid. PeopleSoft can throw errors if this table has invalid entries, or if the ACCESSID has limited access (but that is another story). The ACCESSID and ACCESSPSWD should be set to same user as the OWNERID in PSSTATUS. If you need to change these values do so in SQL, make sure you change the ENCRYPTED field to “0” zero, and then in datamover bootstrap mode execute the command: ENCRYPT_PASSWORD *;

Lastly, in Oracle, make sure that the PSDBOWNER table has one row that contains the database name, and the OWNERID as mentioned above. I always make these fields UPPERCASE as well.

If all of these entries are set correctly, you should have no trouble logging into PeopleSoft.

Note: The reason bootstrap works with a database user is that it skips over the PeopleSoft authentication and simply authenticates using the database security, however, bootstrap should be used with CAUTION.