Process Scheduler

• 1: Recurring Processes Schedule Comparison
• 2: Export Recurring Processes
• 3: Process Run Check

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 “Export Recurring Processes” 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 “Export Recurring Processes” 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 “Export Recurring Processes” 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

To find the Run ID, go to the Reports page and look at the report history for a previous “Export Recurring Processes” run.

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 (“Export Recurring Processes”) 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 - Export Recurring Processes

Export Recurring Processes Report

Report ID: recurring-processes Category: Process Scheduler

Purpose

This report exports all currently queued recurring batch processes from the PeopleSoft Process Scheduler. 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