DB2 administrative task scheduler

What the scheduler is

Think of the administrative task scheduler as a Db2-aware cron that runs as its own z/OS started task. It reads a task list, waits until a schedule or event says “go,” then either CALLs a stored procedure or submits JCL. Activity can be limited with earliest/latest timestamps and a maximum number of invocations.

This is not a replacement for every enterprise scheduler (Control-M, TWS, and friends), but it is tightly integrated with Db2: task definitions and status live where DBAs already work, and procedures can run under Db2 authority models and WLM environments.

Scheduler setup and configuration

Setup usually happens during Db2 install or migration: create the scheduler objects, configure the started task procedure (often named along the lines of admtproc), associate the scheduler with a Db2 subsystem, and grant execute on the administrative routines. Configuration includes which Db2 SSID the scheduler serves, security IDs, tracing, and how it connects (the administrative procedures themselves commonly run in WLM-established address spaces using RRSAF).

Scheduler tables and related objects hold the task list and execution metadata. You normally do not UPDATE those tables by hand—use the provided ADD/REMOVE procedures and list/status functions so the scheduler's in-memory view stays consistent. When documentation refers to task registration, it means those APIs.

Scheduled tasks: time-based and event-based

Time-based scheduling uses an interval or a point-in-time expression so work lands at 02:00, every 15 minutes, or similar. Optional begin and end timestamps fence the window; max-invocations caps how many times the task may fire.

Event-based scheduling ties a task to the completion of another task name. You can further require a condition and code (for example only run the cleanup task if the load task returned success). Reserved names DB2START and DB2STOP represent subsystem start and stop events for the associated scheduler—useful for warm-up or quiesce automation.

Stored procedure scheduling versus JCL scheduling

Stored procedure scheduling is ideal when the work is already a Db2 routine: collect stats wrappers, administrative procs, or shop-written maintenance CALLs. On ADMIN_TASK_ADD you supply procedure schema/name and optional procedure-input that produces parameter values.

JCL scheduling points at a library and member. The scheduler submits the job and can wait or not wait according to options such as job-wait. Status fields for JCL tasks include job id and completion codes; for procedure tasks those JCL fields are null and SQLCODE/SQLSTATE carry the Db2 result instead.

1
2
3
4
5
6
7
8
9
10
11
-- Conceptual registration (parameter lists are long; see IBM ADMIN_TASK_ADD)
CALL SYSPROC.ADMIN_TASK_ADD(
  /* user/password or NULL as your security model requires */,
  /* begin-timestamp, end-timestamp, max-invocations */,
  /* interval OR point-in-time OR trigger-task-* group */,
  /* db2-ssid if needed */,
  /* procedure-schema, procedure-name, procedure-input */
  /* OR JCL-library, JCL-member, job-wait */,
  /* task-name, description */,
  /* OUT return-code, message */
);

Task registration, execution, and history

Task registration assigns a unique task-name and the schedule plus action. Duplicate names are rejected—treat task names like production object names. Task execution happens when the scheduler decides the schedule is due; it then calls Db2 or submits JCL under the configured identity.

Task history / status is queried with functions such as ADMIN_TASK_STATUS (last execution per task) and related list interfaces for the current task list. After a failure, read SQLCODE for procedure tasks or MAXRC / abend codes for JCL tasks before re-running manually.

• Prefer small, restartable procedures over giant all-or-nothing jobs
• Chain tasks with triggers instead of embedding long waits inside one proc
• Document task-name conventions (APP, ENV, ACTION) for operators
• Alert on repeated non-zero status the same way you alert batch abends

Scheduler security

Scheduler security has two layers: who may change the task list, and what the scheduler may do when a task fires. Restrict EXECUTE on ADMIN_TASK_ADD and remove/update routines to DBA automation IDs. The scheduler's runtime ID needs enough Db2 privilege to CALL the scheduled procedures and, for JCL, authority to submit jobs into the right classes. Never store clear passwords in shared scripts if your shop supports safer AUTH mechanisms—follow current IBM parameter guidance for user-ID and password arguments (often NULL when using the caller's identity model).

START, STOP, and MODIFY admtproc

1
2
3
4
5
6
START admtproc
STOP admtproc
MODIFY admtproc,APPL=SHUTDOWN
MODIFY admtproc,APPL=TRACE
 
/* PROC name may differ: ADMTDB2A, etc. Match your PROCLIB */

Use SHUTDOWN when you want an orderly stop. Use TRACE when IBM support or your runbook asks for scheduler diagnostic output. Coordinate stops with any tasks that must not be skipped—either drain windows or accept that a down scheduler will miss interval firings until it is started again.

Designing reliable task chains

Real maintenance is rarely one step. A useful pattern is a time-based driver task that calls a stored procedure to decide what work is due, then triggered follow-on tasks for JCL utilities or cleanup procedures. Keep each task small enough to restart. If a REORG-related job fails, you want status history that names that task—not a single mega-procedure that hides which step broke.

Use begin and end timestamps to protect production windows. A task that is safe at 01:00 may be hostile at 09:00; fence it. max-invocations helps for one-shot migrations (“run at most three times while we cut over”). For recurring work, leave max-invocations unlimited but alert on consecutive failures so a quietly dying scheduler task does not go unnoticed for weeks.

Operations: windows, IPL, and missed intervals

When the scheduler is down for IPL or maintenance, interval tasks do not magically catch up unless you design catch-up logic inside the procedures themselves. Decide explicitly: skip missed runs, or detect “last success was too long ago” and run a catch-up path. Document that choice in the runbook next to START admtproc so operators know whether to launch a manual job after bringing the scheduler back.

Coordinate SHUTDOWN with long-running JCL tasks. If job-wait is in use, understand whether shutdown waits or abandons waiters. TRACE should be off in normal production unless you are actively diagnosing; leaving verbose trace on forever adds noise and can add cost.

Comparing the scheduler to enterprise job schedulers

Enterprise schedulers shine at cross-platform calendars, technician workflows, and heterogeneous job networks. The Db2 administrative task scheduler shines when the trigger is inherently Db2-centered: react to DB2START, call a Db2 administrative procedure, or keep the task list next to the database it serves. Many shops use both: Control-M (or similar) for the big board, and the Db2 scheduler for a handful of database-native chores.

Do not duplicate the same REORG in both tools without a clear owner. Double scheduling is a classic way to create utility conflicts and -904 style resource busy conditions. Pick one orchestrator per job and let the other tool monitor or stay out.

Naming standards and handoffs

Task names should encode application, environment, and purpose—for example PAY_PROD_RUNSTATS_NIGHT—so operators reading ADMIN_TASK_STATUS immediately know what broke. Store the owner and pager rotation in the description field. When development hands a new procedure to operations, the handoff package should include the ADMIN_TASK_ADD parameter choices, the WLM environment the procedure needs, expected runtime, and which triggered tasks depend on success.

Include a delete/remove procedure step in decommission checklists. Abandoned tasks that call retired procedures generate nightly noise and train people to ignore scheduler failures. A quiet, clean task list is a reliability feature.

Finally, practice recovery: stop the scheduler in a test subsystem, start it again, and confirm tasks resume as designed. Verify that DB2STOP/DB2START triggered tasks do what you think during a planned bounce. Untested automation is fiction.

When something fails at 03:00, operators need a short path: DISPLAY or status function for the task name, read SQLCODE or JCL MAXRC, decide retry versus skip, and page the owner listed in the description. Put that path in the same document as the START admtproc commands. Scheduler value collapses if only one DBA knows how ADMIN_TASK_ADD was invoked last year.

Also plan for dual data sharing members or multiple Db2 subsystems: each may have its own associated scheduler. A task registered against the wrong SSID never runs where you are watching. Confirm db2-ssid parameters during registration reviews, especially after subsystem renames or group attach changes.

Capacity-wise, remember that scheduled procedures still consume WLM TCBs, Db2 threads, and utility slots. Stagger heavy tasks so the scheduler does not start five REORG-class jobs at once simply because five intervals aligned. Trigger chains help you serialize; pure wall-clock schedules can accidentally parallelize.

Security reviews should ask who can insert tasks that submit arbitrary JCL. A compromised ID with ADMIN_TASK_ADD is an automated job submitter. Restrict the procedure, monitor task-list changes, and prefer stored-procedure tasks with narrow GRANTs when JCL submission is unnecessary. For JCL tasks, lock down the library members the scheduler is allowed to point at so task registration cannot aim at unreviewed PROCs.

If you use the scheduler in non-production first, clone a representative subset of tasks—not only the happy-path nightly job. Include a failing trigger path and a DB2START smoke task so promotion to production is based on evidence. That small investment prevents the first production week from becoming the real test environment. Keep screenshots or saved status output from the test run with the change ticket so auditors and future DBAs can see what “good” looked like before go-live in production.

Explain It Like I'm Five

The administrative task scheduler is an alarm clock for Db2 chores. You write a note (task) that says “at bedtime, brush the tables” (call a procedure) or “after dinner, put the dishes in the machine” (run JCL when another task finishes). ADMIN_TASK_ADD is how you stick the note on the fridge. admtproc is the robot that reads the fridge and does the chores. MODIFY ... SHUTDOWN tells the robot to finish and go to sleep. History is the checklist that shows whether last night's chores worked.

Exercises

1. Design a task pair: nightly procedure plus a triggered JCL job that runs only on success.
2. When would you use DB2START as a trigger instead of a pure time interval?
3. List privileges you would grant to (a) the person who registers tasks and (b) the scheduler runtime ID.
4. What status fields would you inspect after a failed stored-procedure task versus a failed JCL task?
5. Write the console commands you would use to start tracing and then shut the scheduler down.