# Recurring Processes Schedule Comparison
LLMS index: [llms.txt](/llms.txt)
---
-
Target Database:
—
-
Context Type:
—
-
Alert Severity:
—
-
Triggered Time:
—
-
Firing Context:
—
## 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:
| Status | Meaning |
| ------------- | ------------------------------------------------------------ |
| **+ Added** | Process exists in current schedule but not in baseline |
| **- Removed** | Process was in baseline but is no longer queued |
| **~ Changed** | Process exists in both but the server assignment has changed |
## Table Queried
### PSPRCSRQST — Process Request Table
Fetched via `GetQueuedRecurringProcesses` (batches of 300).
| Field | Description |
| ------------- | -------------------------------------------- |
| PRCSNAME | Process name |
| PRCSTYPE | Process type (e.g., SQR, Application Engine) |
| OPRID | Operator ID that owns the schedule |
| RUNCNTLID | Run control ID |
| RECURNAME | Recurrence name/schedule |
| SERVERNAMERUN | Assigned process scheduler server |
| RUNDTTM | Scheduled run date/time |
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
```text
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
| Parameter | Required | Description |
| ----------------- | -------- | ----------------------------------------------------------------------------------------------- |
| `baseline_run_id` | Yes | The Run ID of a previously completed "Export Recurring Processes" report to use as the baseline |
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