This wiki page is dedicated to the PeopleSoft process scheduler - the server process(es) that are responsible for running and managing batch processes including SQR, Application Engine, Crystal Reports and Winword.
There are a number of reasons why a process might be stuck at queued. The most obvious is that the process scheduler is down (check the Servers tab in the process monitor). Beyond this, there are some useful troubleshooting that apply:
Check the following tables:
The row count should be the same in both tables. If one is out of sync with the other, then it can help to remove orphaned instances in of the tables. Restarting the process scheduler and clearing the process scheduler cache will also fix a number of issues.
In the PeopleTools 8.4x look at the translates on the field RUNSTATUS or use the query.
select FIELDVALUE, XLATLONGNAME from PSXLATITEM where FIELDNAME = 'RUNSTATUS'
Here's a summary of the run status translates (from PeopleTools 8.49). Note that not all of these are active.
Value | Status |
---|---|
1 | Cancel |
2 | Delete |
3 | Error |
4 | Hold |
5 | Queued |
6 | Initiated |
7 | Processing |
8 | Cancelled |
9 | Success |
10 | Not Successful |
11 | Posted |
12 | Unable to Post |
13 | resend |
14 | Posting |
15 | Content Generated |
16 | Pending |
17 | Success with Warning |
18 | Blocked |
19 | Restart |
The following query will give you a summary of the process run statuses in your process request table:
select RUNSTATUS, ( select XLATSHORTNAME from PSXLATITEM where FIELDNAME = 'RUNSTATUS' and FIELDVALUE = RUNSTATUS ) as RUNSTATUS_DESCR, count(PRCSINSTANCE) from PSPRCSRQST group by RUNSTATUS order by RUNSTATUS;
I once wrote an application engine to extract photographs from the PeopleSoft database (BLOBs) and to put the photos into a common location on the application server. This was an application engine program. However, the only problem was that the photos being outputted (in .jpg format) were also going to the report repository. This was a hard one to pick up as the .JPG extension had never been configured in the Process Scheduler system settings under distribution file options.
PeopleTools > Process Scheduler > Process Scheduler > System Settings > Distribution File Options
This meant that to the end user, the links were never created to the files on the report repository but they were indeed going there. It was only when the application engine batch processed a lot of photos and the report repository came to a grinding halt that this became apparent.
The fix required suppresing output to the report repository. Here's how:
PeopleTools > Process Scheduler > Processes > [Your Process Name] > Destination
On the destination page, change the output destination options from the default to:
Not sure if the destination source has any impact. User specified is apparently the default (PeopleSoft Process Scheduler PeopleBooks) and means that the output destination is determined by the process run control designation. SQRs apparently must use this as their setting and I believe any application engine programs that output files.
You may find that only application engine programs are stuck at queued while other processes (SQRs, crystals etc) run to success. This typically happens due to processes blocking the process scheduler queue. Check the process scheduler/master process scheduler logs. You might see something like this:
Checking Process cancels...
(NET.113): Client ChkAeStatus3 service request succeeded
Process 2319373 is still running as Session ID 19955
(NET.113): Client ChkAeStatus1 service request succeeded
Process 2319395 is still running as Session ID 19946
(NET.113): Client ChkAeStatus2 service request succeeded
Process 2319404 is still running as Session ID 19950
Application Engine : 3:3
Requests found in Process Request table 3
This indicates that the three process instances, 2319373, 2319395 and 2319404 are all running. As there is a maximum of 3 application engine programs that can run at any one time and there are currently 3 running, all other application engine programs requested will remained at queued. However, the three process instances may not actually be running. If this is the case, these will need to be manually stopped, for example with a process scheduler restart and perhaps by manually killing the processes on the process scheduler server if required.
Ever wondered where the active processes value on the server list tab comes from? Well it actually uses a view - PS_PMN_PRCSACTV_VW. This view uses the underlying records PS_SERVERMONITOR and PS_SERVERCLASS. It is the ITEMCOUNT field from PS_SERVERMONITOR that gives you the active processes count by process type (SQR, COBOL, Application engine etc).
The following query will give you a summary of the requested processes by process status.
select RQST.RUNSTATUS, RQST.PRCSTYPE, ( select XLAT.XLATLONGNAME from PSXLATITEM XLAT where XLAT.EFFDT = ( select max(XLAT_ED.EFFDT) from PSXLATITEM XLAT_ED where XLAT_ED.FIELDNAME = XLAT.FIELDNAME and XLAT_ED.FIELDVALUE = XLAT.FIELDVALUE ) and XLAT.FIELDNAME = 'RUNSTATUS' and XLAT.FIELDVALUE = RQST.RUNSTATUS ) as RUNSTATUS_XLAT, count(RQST.PRCSINSTANCE) as TOTAL_PROCESSES, min(RUNDTTM) as FIRST_OCCURRED, max(RUNDTTM) as LAST_OCCURRED from PSPRCSRQST RQST group by RQST.RUNSTATUS, RQST.PRCSTYPE order by RUNSTATUS_XLAT, RQST.PRCSTYPE
The following tables store information about the distribution of process scheduler output to users or roles.
PS_PRCSDEFNCNTDIST
Distribution settings for process definitions.
PS_PRCSJOBCNTDIST
Distribution settings for jobs.
PS_PRCSRQSTDIST
Distribution settings by process instance. Join to PS_CDM_FILE_LIST on the process instance to get the file names.
PS_PRCSRUNCNTLDIST
Distribution by operator ID and run control.