Process Scheduler

• 1: Recurring Processes Schedule Comparison
• 2: Recurring Schedule & Drift Monitoring
• 3: Process Run Check
• 4: Stalled Recurrences

1 - Recurring Processes Schedule Comparison

Recurring Processes Schedule Comparison Report

Report ID: recurring-processes-compare Category: Process Scheduler

Purpose

This report compares the current batch schedule against a previously exported baseline from the “Recurring Schedule & Drift Monitoring” report. It identifies processes that have been added, removed, or changed since the baseline was captured, helping you detect unintended schedule modifications after migrations, upgrades, or configuration changes.

How It Works

The report requires a baseline — a previously run “Recurring Schedule & Drift Monitoring” report. It parses the baseline report’s markdown table to extract the saved schedule, then fetches the current recurring processes from the database and compares the two sets.

Comparison Logic

Processes are matched by a composite key of:

• Process Name (PRCSNAME)
• Process Type (PRCSTYPE)
• Operator ID (OPRID)
• Recurrence Name (RECURNAME)

The report detects three types of differences:

Table Queried

PSPRCSRQST — Process Request Table

Fetched via GetQueuedRecurringProcesses (batches of 300).

The baseline data is parsed from the markdown table in the previous “Recurring Schedule & Drift Monitoring” report output — no additional database query is needed for the baseline.

Data Flow

1. Load baseline report output by Run ID
   -> Parse markdown table to extract baseline processes
        |
        v
2. Fetch current recurring processes from PSPRCSRQST
   via GetQueuedRecurringProcesses (batches of 300)
        |
        v
3. Build lookup maps for both baseline and current sets
   using composite key: PrcsName|PrcsType|OpRid|RecurName
        |
        v
4. Compare sets to find:
   - Removed: in baseline but not in current
   - Added: in current but not in baseline
   - Changed: in both but server assignment differs
        |
        v
5. Generate comparison report with summary and diff table

Parameters

Select the baseline from the dropdown list. If no baseline runs are found, you must first run the “Recurring Schedule & Drift Monitoring” report.

Report Output

The generated report contains:

• Header with database name, generation timestamp, and baseline Run ID
• Summary with baseline process count, current process count, and total differences found
• Difference breakdown with counts of added, removed, and changed processes
• Differences table (if any) with: Status, Process Name, Type, OPRID, Recurrence, Server, Detail
• Recommendations for handling each type of difference

If no differences are found, the report confirms that the current schedule matches the baseline.

Interpreting Results

• Removed processes may indicate an intentional change or an accidental deletion during a migration. Verify with the batch schedule owner before dismissing.
• Added processes should be documented and reviewed to ensure they follow naming and scheduling standards.
• Changed processes (server assignment changes) are common after environment migrations and should be verified to ensure processes are running on the correct scheduler server.
• A clean comparison (no differences) confirms that the batch schedule survived a migration or change window intact.

Recommendations

1. Export a baseline (“Recurring Schedule & Drift Monitoring”) before any major environment change (migration, refresh, upgrade)
2. Run this comparison report immediately after the change to verify the schedule
3. Investigate all removed processes — they may need to be re-created manually
4. For added processes, verify they were intentionally scheduled and follow your naming conventions
5. For server assignment changes, confirm the target scheduler server is appropriate for the process workload

2 - Recurring Schedule & Drift Monitoring

Recurring Schedule & Drift Monitoring Report

Report ID: recurring-processes Category: Process Scheduler

Purpose

This report lists all currently queued recurring batch processes from the PeopleSoft Process Scheduler and acts as the source for schedule drift monitoring. When scheduled with the On Change (on_change) notification mode, it automatically alerts on changes (added, removed, or server assignment changes) compared to a baseline run.

It captures the batch schedule configuration so it can be preserved for disaster recovery, environment migrations, or operational documentation.

The report answers: “What recurring processes are currently scheduled, who set them up, with what run control, on what recurrence, and on which server?”

What It Captures

For each queued process with a recurrence assigned:

• OPRID. The operator who scheduled the process
• RUNCNTLID. The run control ID used
• RECURNAME. The recurrence definition controlling the schedule
• SERVERNAMERUN. The Process Scheduler server assigned to run it
• Process Name and Type. The process definition being executed

Additionally, the report fetches and displays the schedule details for each unique recurrence found (type, days, time window, repeat interval).

Tables Queried

PSPRCSRQST — Process Request Instances

The primary table for process scheduler requests.

PRCSRECUR — Recurrence Definitions

Looked up for each unique recurrence found to display schedule details.

Data Flow

1. Query PSPRCSRQST where RECURNAME <> ' ' AND RUNSTATUS = 5
   Paginate through all results (batches of 300)
        |
        v
2. Collect unique RECURNAME values
   For each, fetch PRCSRECUR via GetRecurrenceByName
        |
        v
3. Generate Markdown report:
   - Summary counts
   - Main table of all queued recurring processes
   - Recurrence schedule details section

Report Output

The generated report contains:

• Header with database name and generation timestamp
• Summary with total process count, unique recurrences, unique operators, unique servers
• Process Table with Process Name, Type, OPRID, Run Control ID, Recurrence, Server, Run Date/Time
• Recurrence Details for each unique recurrence: type, scheduled days, start/end dates, repeat interval, duration

Parameters

This report has no configurable parameters.

Interpreting Results

• Each row represents a process request that is currently queued with a recurring schedule
• The same process may appear multiple times if scheduled by different operators or with different run controls
• If a server column shows “(any)”, the process can run on any available Process Scheduler server
• The Recurrence Details section shows how often each schedule runs

Use Cases

1. Disaster Recovery. Document the batch schedule before a system outage so it can be recreated
2. Environment Migration. Capture batch schedules before refreshing or migrating an environment
3. Audit. Review who has scheduled recurring processes and on which servers
4. Operational Documentation. Maintain a record of the production batch schedule

3 - Process Run Check

Process Run Check Report

Report ID: process-run-check Category: Process Scheduler

Purpose

This report verifies that a set of critical batch processes have run successfully within a configurable time window. It checks each process for a recent successful completion and flags any that are missing or have not completed successfully.

The report answers: “Have my critical processes run successfully in the last N hours?”

Parameters

Tables Queried

PSPRCSRQST — Process Request Instances

Queried twice per process name:

Data Flow

1. Parse process names from comma-separated parameter
   Calculate cutoff time (now - hours)
        |
        v
2. For each process name:
   a. Query PSPRCSRQST for most recent run (any status)
   b. Query PSPRCSRQST for most recent successful run (status=9) since cutoff
        |
        v
3. Sort results: failures first, then passes
        |
        v
4. Generate Markdown report:
   - Summary with pass/fail counts
   - Results table
   - Recommendations for failures

Report Output

The generated report contains:

• Header with database name, generation timestamp, and time window
• Summary showing how many processes passed vs. failed
• Results Table with columns: Status (PASS/FAIL), Process Name, Last Run Time, Last Run Status, Successful Run in Window
• Recommendations section for any failing processes with details about their last run

Interpreting Results

• PASS. The process had at least one successful run (RUNSTATUS=9) within the time window
• FAIL. No successful run was found within the time window. This could mean:
  • The process ran but ended in error or another non-success status
  • The process has not run at all within the window
  • The process has never run (no history in PSPRCSRQST)
• The “Last Run Time” and “Last Run Status” columns show the most recent run regardless of status, so you can see if it ran but failed

Use Cases

1. Morning Operations Check. Verify that overnight batch processes completed successfully before the business day starts
2. Critical Process Monitoring. Confirm that essential processes (search index builds, security syncs, integration processes) are running on schedule
3. Post-Maintenance Verification. After system maintenance, verify that all scheduled processes have resumed and are completing successfully
4. SLA Compliance. Document that required processes are running within expected timeframes

4 - Stalled Recurrences

Stalled Recurrences Report

Report ID: stalled-recurrences Category: Process Scheduler

Purpose

This report identifies scheduled recurring processes that have completed a run recently but do not have a subsequent scheduled instance.

In PeopleSoft, recurring batch schedules are kept active by the Process Scheduler, which automatically schedules the next run when the current run starts or completes. However, issues like database refreshes, scheduler outages, cancellations, or errors can cause a schedule to stall without generating a future instance. This report lists all such stalled recurring processes to ensure they can be resumed.

The report answers: “Which of my recurring batch processes have stopped scheduling?”

Parameters

Tables Queried

PSPRCSRQST — Process Request Instances

The report queries PSPRCSRQST to fetch historical and future instances that have a recurrence name assigned:

SELECT PRCSINSTANCE, PRCSNAME, RUNCNTLID, OPRID, RECURNAME, RUNSTATUS, BEGINDTTM, ENDDTTM, RUNDTTM
FROM PSPRCSRQST
WHERE RECURNAME <> ' '
  AND COALESCE(BEGINDTTM, RUNDTTM) >= TO_DATE('{cutoff}', 'YYYY-MM-DD')

Data Flow

1. Calculate the lookback cutoff date based on 'lookback_days'
        |
        v
2. Query PSPRCSRQST for all requests with a recurrence name since the cutoff date
        |
        v
3. Group requests by (PRCSNAME, RUNCNTLID, OPRID, RECURNAME)
        |
        v
4. For each group:
   - Identify active/pending instances (Queued, Blocked, Hold, Pending, Initiated, Processing, Posting, Restart)
   - Identify completed instances (Success, Error, Cancelled, etc.)
   - If there is at least one completed run, but ZERO active/pending runs:
     - Mark the recurrence as stalled
     - Find the latest completed instance
        |
        v
5. Generate the Markdown report:
   - Summary count of stalled recurrences
   - Table of stalled recurrences with last run status and links
   - Troubleshooting recommendations

Report Output

The generated report contains:

• Header displaying the database name, run ID, and lookback window.
• Summary showing the count of stalled recurrences detected.
• Results Table with columns: Process Name, Recurrence, User, Run Control, Last Instance, Last Status, and Last Run Date/Time.
• Recommendations detailing the resolution steps.

Interpreting Results

If a recurrence is listed in the report, it has stopped running. Check the Last Status column:

• Error / Not Successful / Unable to Post: The schedule stopped due to a process failure. The scheduler may not have been able to queue the next run, or the recurrence was stopped.
• Success / Success with Warning / Cancelled: The process ran or was cancelled but did not reschedule. This could happen if the recurrence ended naturally (reached its end date), or if it was manually cancelled and not rescheduled.