Batch processing & scheduling

The basic job scheduler supports entries such as those created with ADDJOBSCDE and managed with WRKJOBSCDE. A schedule specifies when to submit a command and relevant job settings. More complex dependency management may use another scheduler.

Confirm the system’s time settings, calendar expectations, missed-run behavior, and job environment. A schedule firing is not the same as a completed batch. Define how operations sees success, failure, and overdue work.

Persistent state identifies the business work completed and the work remaining. Commit units should align with an explicit restart checkpoint so a failure does not force a guess about partially processed records.

Use stable business keys and a run identifier rather than relying on an in-memory cursor or QTEMP table. Test a forced failure before, during, and after a commit. On restart, reconcile committed work and avoid repeating external side effects.

An idempotent operation produces the intended effect once even when a request or work item is delivered repeatedly. A unique business operation key and transactional status check can prevent duplicate posting.

A simple check-then-insert without protection is vulnerable to concurrent workers. Use a uniqueness constraint or an atomic claim/update strategy and return the existing outcome for duplicates. Define what should happen if the earlier attempt is still running or ended ambiguously.

Decide whether overlap is allowed. If not, use a supported scheduler constraint or an application-level claim with a clear owner and expiry/recovery policy. The claim must be atomic; two jobs reading the same unlocked flag can both decide they may run.

A stale flag after a crash must not block work forever. Record job/run identity and timestamps, verify the previous owner’s status, and provide a controlled recovery procedure. Avoid interpreting a duplicate process name as sufficient proof of ownership.

Balance business atomicity with lock duration, recovery effort, and throughput. One commit for an entire huge run may hold resources too long; committing every row may impose unnecessary overhead and break a multirow business invariant.

Choose a coherent unit such as one order or a bounded group of independent items. Save its checkpoint consistently with the business changes. If external actions are involved, coordinate through durable intent and idempotency rather than assuming COMMIT spans every system.

Dependency should be based on an explicit successful business outcome, not a fixed sleep or the fact that a predecessor was submitted. Store a run status or use scheduler dependencies that distinguish success, failure, and cancellation.

Pass the run identifier and relevant input version to downstream work. Define retry policy and how operators resume the chain after a partial failure. Prevent a late completion from yesterday’s run from incorrectly unlocking today’s dependent processing.