I was reading case notes earlier today and found this note:  638613.1 which explains how PeopleSoft gets datetime.

Prior to PeopleTools 8.46 we had an issue with the way %DateTime retrieved the datetime value. The information below is not a direct solution to the behavior described above. This is an explanation of how the
%DateTime function worked prior to PeopleTools 8.46, and how/why it was changed.

When the Process Scheduler or Application Server is started, the host server’s system time and the time from the database is retrieved.  The difference between the server’s system time and the time from the database is stored as permanent value.  From this moment forward, whenever the Date/Time/or DateTime is requested we get the system time from the host server, and apply the difference that was originally calculated between the system time and the database time. The was done to avoid the overhead of going to the database for every request. The problem with this approach was that over time the clocks on the database and the process scheduler/appserver might not be ticking at the exact same rate.  If your process scheduler and/or appserver have not been rebooted for a long time, you could possibly see a difference of up to 5 minutes or more between the database time and the server’s system time.

The change that was made in PeopleTools 8.46 was to call a function that will retrieve and save the time from the database. When the function is called (it is called whenever someone logs on through PIA or a new batch process starts), and it has not issued the SQL to get the time from the database for over 20 minutes, the process scheduler and/or appserver will issue the SQL to retrieve the time from the database. If it has been less than 20 minutes, then a calculation similar to the one described above is used.

When creating a windows server that is going to run application and process servers for PeopleSoft I find a great way to automate the starting and stopping of services.  PeopleSoft delivers a method of installing a service to stop/start the services, which I have seen many people use, but I personally think it is a little buggy. I have experienced weird issues with the services not stopping properly, or if you have multiples and one has a problem you either effect all of them or you have to manually go to psadmin to administer the problem domain. I have also found that having non-administers trying to use the service/psadmin to be tricky.

As a solution to this problem, I have always liked using Windows Scheduled Tasks.  Scheduled tasks can be setup in advanced and you can run either a batch program (script) or the psadmin.exe utility.  When you scheduled a task you also set what user it will run as regardless of who runs it thus allowing a developer to run the script without being the administrator.

The only problem I have had with this is with the introduction of ps_cfg_home and ps_app_home variables.  Typically these can vary for every environment in which case I will create a batch program that sets the variables and then call psadmin in the script.  Then I schedule the task to run the batch program.  In order to run psadmin correctly after 8.50 you have to make sure the ps_cfg_home is set before running psadmin, otherwise it won’t know where the domains are.

For example on my environment I have an environment variable for the ps_cfg_home=c:\oracle\psoft\pt852cfg and my scheduled task is setup to run c:\oracle\psoft\pt852\appserv\psadmin.exe -p stop -d HRDEMO.  This basically tells the system where the HRDEMO domain is stored and to stop the process scheduler.

Other commands:

Application Server Start:  psadmin.exe -c boot -d {Domain}

Application Server Stop: psadmin.exe -c shutdown -d {Domain}   (to “force” down use shutdown! <-note exclamation point)

Process Server Start: psadmin.exe -p start -d {Domain}

Process Server Stop: psadmin.exe -p stop -d {Domain}

The other day I had to install an old 8.1 version of Tuxedo on a RHEL 4 machine and I ran into a problem after I tried to run the install.sh script.  It was reporting that the included VM could not be uncompressed.

Since this machine was brand new it turned out the the /usr/bin/uncompress utility was not there.  The Tuxedo installer needs this utility to uncompress the setup files.  It typically is located in the /usr/bin directory, and this path should be included in your PATH variables.

In my case there was no /usr/bin in the path and there was no uncompress utility.  There are various RPMs that will install an uncompress utility, however it is actually pretty old now and has been replaced with gzip.  So I added the path to my path variable and since I actually had gunzip already on the machine in /usr/bin, I created a symbolic link to gunzip for uncompress:

ln -s gunzip uncompress

I re-executed the install.sh script again and the install worked without a problem.

The other day I was stuck trying to cleanup a license manager for Cobol on a new virtual machine that was cloned from another machine. There was a series of licenses in the database that could not be removed.  In the end I decided that the easiest way to solve this problem was to delete the database and install a new clean database.

These instructions are for a linux based system, when dealing with peoplesoft, you will have a COBDIR where the server express software is installed.

On Unix based system (Linux, Solaris ..), only super user (root) can start any process on port <= 1024 . From security reasons its is not desirable to run WebLogic server as root user. Solution is to start WebLogic process as root (bind on port 80, 443) and then switch process to non privileged user like oraweblogic or nobody. This is done by setting four properties in WebLogic - weblogic.system.enableSetUID (Set User ID) weblogic.system.enableSetGID (Set Group ID) weblogic.system.nonPrivUser(Non privledged user) weblogic.system.nonPrivGroup(Non privledged Group) 1. By setting value of enableSetUID to true; you are instructing weblogic server to switch from ROOT(after starting weblogic server on port 80, 443 or <=1024) to lower privileged user. 2. Value assigned to nonPrivUser will be used to own weblogic server process, once its been started by superuser in port <= 1024 3. Ensure that lower privileged user should have proper access (read, write or both depending on type of type) on files (log, classes..) required by weblogic server. 4. If you wish to start and access weblogic server on both SSL (443) and non SSL (80); you need to define two Listen Port.