0% found this document useful (0 votes)
2K views3 pages

Process Scheduler Trouble Shooting

The process stays in 'Initiated' or 'Processing' status due to the PSAESRV that runs the Application Engine going into a "ChkAeStatus" flag. This can be caused by long database locks, excessive process logging, or Java errors. To resolve it, identify the problematic PSAESRV and kill it using the tmshutdown command, which will free up the scheduler. It is also important to keep the PSPRCSRQST, PSPRCSQUE, and PSPRCSPARMS tables in sync by deleting orphaned records.

Uploaded by

Raj
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
2K views3 pages

Process Scheduler Trouble Shooting

The process stays in 'Initiated' or 'Processing' status due to the PSAESRV that runs the Application Engine going into a "ChkAeStatus" flag. This can be caused by long database locks, excessive process logging, or Java errors. To resolve it, identify the problematic PSAESRV and kill it using the tmshutdown command, which will free up the scheduler. It is also important to keep the PSPRCSRQST, PSPRCSQUE, and PSPRCSPARMS tables in sync by deleting orphaned records.

Uploaded by

Raj
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 3

0

Process Request shows status of


'INITIATED' or 'PROCESSING' but no
longer running

The error you indicate that the process stays in a status of 'Initiated' through my experience can
be due to varios causes. You will not that when this occurs the PSAESRV running the
Application Engine will have a status of ChkAeStatus. This is basically a flag status which can
occur for varios reasons which I will list in a moment. When any PSAESRV goes into
ChkAeStatus the process scheduler is blocked and will not initiate any further requests. This
block can be released by doing the following.
Set the TUXCONFIG environment variable.
TUXCONFIG=$PS_HOME/appserv/prcs/<SchedulerN ame>/PSTUXCFG
Then note the PSAESRV id in the Scheduler monitor through the psadmin menu and run the
following command
tmshutdown -g AESRV -i <ID> -k -y
This command will kill the PSAESRV causing the ChkAeStatus freeing the Scheduler up for
further requests. Your process will however terminate in Error. When all processes are
terminated it is advisable in order to avoid further problems to shutdown all Master Schedulers
and the individual scheduler which had the PSAESRV in ChkAeStatus. You will notice that the
Status of the process is updated from Error to Incorrect.
Known Causes for ChkAeStatus
The ChkAeStatus flag is merely a way that the process scheduler indicates that a process has
been a long time in a single state. There can be many causes for this, below I list some that are
known to me.
1. Locks (updates, inserts etc) in the database which cause a process to wait for an excessive
period of time for another process or online transaction to free the lock. For instance is a process
massively updates the PSOPRDEFN table and a user attempts a logon, a lock will be caused,
which will either block the user from logging on, or possible cause the PSAESRV to go into
ChkAeStatus.
2. Process Logs and Traces. Each process can be configured to generate a log and timings file.
-TRACE 384 for instance will create a .trc indicating the steps run through the Application
Engine and a .AET indicating the timings for each Section and Step. If the log that is set creates
an excessive amount of data then the PSAESRV may enter ChkAeStatus due to I/O waits while
writing to disk.
3. Java errors causing the PSAESRV to dump. This has happened infrqeuently but can be caused
due to improper coding, often by asigning improper values to variables. A PSAESRV.12345
directory will be created under the Server log directory which will contain dump information
from when the error ocurred.
PSPRCSRQST, PSPRCSQUE and PSPRCSPARMS
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
where R.PRCSINSTANCE=Q.PRCSINSTANCE 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.

You might also like