add a comment
Set this to something unique for e.g. dayoff and fireoff this url to refresh the cache
To view configuration.properties
To Reset Timeout
add a comment
Normally, you would shut down the application server, delete the physical cache directories and restart the application server.
From PeopleTools 8.48, each Application server process can only use one dedicated set of physical cache files that is in a directory whose name includes the name and ID number of the server, (previously the server process could use any unlock set cache directories). This allowed PeopleSoft to add an option to the psadmin utility to trigger each PSAPPSRV process to clear out its own physical cache (my thanks to the anonymous question asked after the original version of this posting that reminded me). This option also causes each server process to recycle. It is the recommended and supported way to clear the physical cache files.
This can also be invoked from the command line
psadmin -c purge -d <domain> [-noarch | -arch <archive_directory>] [-log <"log_comments">] where 'domain' specifies domain name in PS_HOME and 'archive_directory' specifies location to which to quarantine the purged cache, 'log_comments' specifies any comments to be added to the purge cache log entry
However, even in previous versions, there has always been a way to invalidate all physical cache files. Any cached object older than the value of LASTREFRESHDTTM on the table PSSTATUS (it was on a different table prior to PeopleTools 8) is purged from the cache when the process that references that cache starts. Therefore, if that value is updated to the current time, the entire cache will be purged.
UPDATE PSSTATUS SET LASTREFRESHDTTM = SYSDATE / COMMIT /
Sometimes, developers also have to clear the physical cache on their clients used by Application Designer. Updating PSSTATUS also clears two-tier client caches. In fact, this behaviour is left over from the days when PeopleTools was a two-tier application, and it was necessary to clear cache files on users’ desktop computers.
- If you have multiple Application Servers on a single database, then you can shut each one down in turn without any loss of server. The users will fail over to the surviving servers. However, this can result in the load being unevenly distributed and could overload one server.
- In small environments, and this includes most development and test systems, there is only a single application server. Shutting down an application server requires downtime and can be disruptive.
If an application server has at least two instances of a server process then each process can be recycled one by one, and there is no loss of service because the other processes can handle incoming requests. You could do this manually by entering the stop and boot commands in tmadmin (I discussed this in Chapter 13 of PeopleSoft for the Oracle DBA, but didn’t combine it with the idea of clearing the Application Server cache).
I have produced a script, tuxcycle.sh (available from the Go-Faster website) that uses the Tuxedo command line interface utility, tmadmin, to find out which PSAPPSRV processes are running, and then sequentially recycles each of them. I don’t think I would completely automate these two operations into a single process, nor would I run them unattended, but you can now clear cache files without taking a system away from users or developers.
Remember, that users will experience a reduction in performance after clearing the cache because it needs to be rebuilt by querying the PeopleTools table.
The Process Scheduler, Master Process Scheduler, Distribution Server, and Application Engine processes also have physical caches. These are also cleared when LASTREFRESHDTTM is updated and the processes restarted. However, you should not shut down the Process Scheduler while processes are executing. The server process will shutdown and the Application Engine will be killed if using an Application Engine server process (PSAESRV). Any stand-alone processes, including psae, will be killed by the Process Scheduler when it is restarted.
add a comment
Manually Booting Tuxedo Application Server Processes in Parallel
Normally when an Application Server is booted, initialisation of each process completes before the next one is started. The ability to boot Application Server processes in parallel was added to the psadmin utility in PeopleTools 8.48. However, psadmin is merely a wrapper for the BEA Tuxedo tmadmin command line utility, and it has always been possible to do this manually in previous versions of PeopleTools via the tmadmin utility as follows.
1. Boot the Tuxedo Bulletin Board Liaison process.
#boot the Tuxedo administrative processes
2. Boot the PeopleSoft Application Server processes and but specify the -w parameter so that they don’t wait as they start
boot -g APPSRV -w
If you are running PUBSUB or other servers in other groups then you would also boot them here.
3. Boot the JREPSRV process (which maps Java Classes to Tuxedo Services).
boot -g JREPGRP
4. List the servers with print server so you know that the PeopleSoft servers are booted.
5. When all the other processes have booted, boot the WSL and JSL processes.
boot -g BASE
boot -g JSLGRP
add a comment
PSPRCSRQST, PSPRCSQUE and PSPRCSPARMS Synch
In order to avoid various process scheduler related issues, three Process Scheduler tables PSPRCSRQST, PSPRCSQUE and PSPRCSPARMS must be in sync.
Execute below queries:
select count(*) from PSPRCSRQST;
select count(*) from PSPRCSQUE;
select count(*) from PSPRCSPARMS;
If these queries give different results, you should bring them in sync by executing below statements:
DELETE FROM PSPRCSQUE QUE
WHERE NOT EXISTS (SELECT ‘X’ FROM PSPRCSRQST RQST WHERE RQST.PRCSINSTANCE = QUE.PRCSINSTANCE);
DELETE FROM PSPRCSPARMS PARMS
WHERE NOT EXISTS (SELECT ‘X’ FROM PSPRCSQUE QUE WHERE QUE.PRCSINSTANCE = PARMS.PRCSINSTANCE);
Also, Column RUNSTATUS of any process instance in table PSPRCSRQST must have same value in table PSPRCSQUE for that process instance… below query will show check for it.
select R.PRCSINSTANCE, R.RUNSTATUS, Q.PRCSINSTANCE, Q.RUNSTATUS from PSPRCSRQST R, PSPRCSQUE Q
and R.RUNSTATUS != Q.RUNSTATUS
*** Also, it is a good practise to delete the processes with delete, error or cancelled status from the PeopleSoft tables:
DELETE FROM PSPRCSRQST where RUNSTATUS = ‘2’ –> 2 is the run status for delelted process.
DELETE FROM PSPRCSQUE where RUNSTATUS = ‘2’
*** Key Point: Data in PSPRCSRQST, PSPRCSQUE and PSPRCSPARMS tables must be in sync.