Recurring Processes Schedule Comparison

Tailored Operational Context
  • 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:

StatusMeaning
+ AddedProcess exists in current schedule but not in baseline
- RemovedProcess was in baseline but is no longer queued
~ ChangedProcess exists in both but the server assignment has changed

Table Queried

PSPRCSRQST — Process Request Table

Fetched via GetQueuedRecurringProcesses (batches of 300).

FieldDescription
PRCSNAMEProcess name
PRCSTYPEProcess type (e.g., SQR, Application Engine)
OPRIDOperator ID that owns the schedule
RUNCNTLIDRun control ID
RECURNAMERecurrence name/schedule
SERVERNAMERUNAssigned process scheduler server
RUNDTTMScheduled 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

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

ParameterRequiredDescription
baseline_run_idYesThe 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