Control-M Job Stuck in Wait Condition: Fix Condition Dates & ODAT

Your job's been sitting in Wait Condition for six hours, and the upstream job finished successfully. You've checked the logs, the dependencies, the agent—everything looks fine. But it's not. The condition date is wrong, and you're about to learn why.

This is the silent killer of Control-M schedules: condition dates and ODAT. They don't throw errors. They don't alert. They just make your job wait forever, and you only find out when the SLA is blown. I've seen a payments batch stuck for 12 hours because someone manually added a condition with today's date instead of the job's ODAT.

By the end of this, you'll know exactly how to diagnose a stuck job in under two minutes, fix condition date mismatches, and design your flows so this never happens again. No fluff—just the production patterns that work.

Why Condition Dates Exist: The Problem They Solve

Before condition dates, Control-M conditions were global and date-agnostic. If a job added FILE_READY, any job waiting for FILE_READY would trigger—even if it was from a different day's run. This caused chaos in daily batches: a job from Monday would trigger Tuesday's downstream jobs, leading to duplicate processing and data corruption.

Condition dates solve this by scoping conditions to a specific date (usually the ODAT). When a job adds a condition, it stamps it with its ODAT. When a job waits for a condition, it only accepts conditions with a matching date. This ensures that Monday's conditions only trigger Monday's jobs.

The trade-off? If dates don't match—due to manual reruns, timezone issues, or misconfiguration—jobs wait forever. There's no error, no warning. Just silence.

// io.thecodeforge — DevOps tutorial

// Job A (upstream) adds condition with its ODAT
// In Control-M job definition:
// On Do Notify: Add Condition PAYMENTS_READY
// (Control-M automatically appends ODAT to condition name)

// Job B (downstream) waits for condition with its ODAT
// In Control-M job definition:
// Wait For: PAYMENTS_READY
// (Control-M automatically appends ODAT to condition name)

// If Job A ODAT = 0101, condition becomes PAYMENTS_READY-0101
// If Job B ODAT = 0102, it waits for PAYMENTS_READY-0102
// Mismatch = Job B waits forever

ODAT: The Anchor for All Condition Dates

ODAT (Order Date) is the scheduled date of a job order. It's not the actual run date—it's the date the job is supposed to run for. When you schedule a job daily, each day's order gets an ODAT. All conditions added or waited for by that job use its ODAT.

Why does this matter? Because reruns and manual orders can have different ODATs. If you manually order a job for yesterday's date, its ODAT is yesterday, and it will add/wait for conditions with yesterday's date. If the upstream job ran today, its conditions have today's date—mismatch.

This is the #1 cause of stuck jobs after a rerun. The fix is to ensure all jobs in a flow share the same ODAT, or to manually adjust conditions.

// io.thecodeforge — DevOps tutorial

// Scenario: Daily batch scheduled for 2024-01-02
// Upstream job UPSTREAM_JOB has ODAT 20240102
// Downstream job DOWNSTREAM_JOB has ODAT 20240102

// Upstream adds condition: FILE_READY-0102
// Downstream waits for: FILE_READY-0102
// Match! Downstream runs.

// Now, operator manually reruns DOWNSTREAM_JOB for 2024-01-01 (ODAT 20240101)
// Downstream now waits for: FILE_READY-0101
// But upstream only added FILE_READY-0102
// Downstream stuck.

// Fix: Manually add condition with correct date:
// ctmcontb -ADD FILE_READY 0101

How to Diagnose a Stuck Job in Under 2 Minutes

Forget digging through logs. The fastest way is to compare what the job waits for with what conditions exist. Use the Control-M CLI or GUI.

Step 1: Get the job's wait-for conditions and ODAT. Step 2: List all conditions and their dates. Step 3: Spot the mismatch. That's it.

Here's the exact command sequence I use in production.

#!/bin/bash
# io.thecodeforge — DevOps tutorial

# Step 1: Get job details including ODAT and wait-for conditions
# Replace JOB_NAME with your stuck job
ctmwhy JOB_NAME | grep -E 'ODAT|Wait For'

# Example output:
# ODAT: 0102
# Wait For: PAYMENTS_READY

# Step 2: List all conditions matching the name
ctmcontb -LIST PAYMENTS_READY "*"

# Example output:
# PAYMENTS_READY-0101  Added by UPSTREAM_JOB

# Step 3: Compare dates
# Job expects PAYMENTS_READY-0102 but only PAYMENTS_READY-0101 exists
# Fix: Add condition with correct date
ctmcontb -ADD PAYMENTS_READY 0102

The Manual Condition Trap: Why Adding Conditions Often Fails

You see the job waiting, you add the condition manually, and... nothing. The job still waits. Why? Because you added the condition with today's date, not the job's ODAT.

Control-M's ctmcontb -ADD <cond> <date> takes the date explicitly (MMDD), so if you pass today's date instead of the job's ODAT, your condition is useless. If the job's ODAT is yesterday (due to a rerun), always specify the date explicitly.

This is the mistake that cost one team 6 hours of debugging. Don't be them.

#!/bin/bash
# io.thecodeforge — DevOps tutorial

# WRONG: Adds condition with today's date
ctmcontb -ADD PAYMENTS_READY $(date +%m%d)

# RIGHT: Add condition with job's ODAT
# First, read the job's order date (ODAT) from its Job Properties in the Monitoring domain, e.g. 0102
ODAT=0102
# Then add condition with that date
ctmcontb -ADD PAYMENTS_READY $ODAT

# Verify condition was added
ctmcontb -LIST PAYMENTS_READY "*"

Designing Flows That Don't Get Stuck: Best Practices

The best fix is prevention. Design your flows so condition dates always align. Use these patterns:

1. Use relative dates in conditions: Instead of hardcoding dates, use Control-M's built-in date variables (e.g., %%ODAT) so conditions automatically match the job's ODAT.
2. Avoid manual condition additions: Automate condition management via the API or scripts that pull the correct ODAT.
3. Monitor condition mismatches: Set up alerts for jobs in Wait Condition longer than expected. Use Control-M's SLA management.
4. Standardize ODAT across flows: When rerunning, rerun the entire flow with the same ODAT, not individual jobs.

// io.thecodeforge — DevOps tutorial

// In Control-M job definition, use %%ODAT in condition names
// Upstream job: Add Condition FILE_READY-%%ODAT
// Downstream job: Wait For FILE_READY-%%ODAT

// This ensures both use the same ODAT automatically.
// No manual date management needed.

When to Use ODAT Override (And When It Bites You)

ODAT override lets you force a job to use a specific date, regardless of schedule. It's powerful for backfills and reruns, but it's also a common source of stuck jobs.

Use it when: you need to reprocess data for a specific date, or when recovering from a failure that requires a different date context.

Don't use it when: you're just trying to 'make the job run now'—that's what manual ordering is for. ODAT override changes the condition dates, which can break downstream dependencies if not coordinated.

Always communicate ODAT overrides to the team. A silent override can cause hours of confusion.

#!/bin/bash
# io.thecodeforge — DevOps tutorial

# Force job to run with ODAT 0102 (MMDD)
ctmorder -FOLDER FOLDER_NAME -NAME JOB_NAME -ODATE 0102 -FORCE y

# This job will now add/wait for conditions with date 0102
# Ensure upstream jobs also use 0102, or manually add conditions

Real-World Pattern: Handling Late-Arriving Files with Condition Dates

A common scenario: a file arrives late, and you need to trigger a job that's already past its scheduled time. If you just add the condition with today's date, it might not match the job's ODAT (which could be yesterday if the job was scheduled for yesterday but hasn't run yet).

The pattern: use a condition with a relative date that matches the job's ODAT. Or, use a file watcher job that adds the condition with the correct ODAT.

Here's how a media company handles late video files: they have a file watcher job that runs every hour, checks for files, and adds a condition with the current ODAT. The downstream processing job waits for that condition. If the file arrives late, the watcher adds the condition with the correct date, and the job triggers.

#!/bin/bash
# io.thecodeforge — DevOps tutorial

# File watcher job: runs hourly, checks for new files
# If file exists, add condition with current ODAT

FILE_PATH="/data/incoming/video_$(date +%Y%m%d).mp4"
if [ -f "$FILE_PATH" ]; then
  # Get current ODAT from Control-M environment
  # In a real job, ODAT is available as %%ODAT
  ODAT=$(date +%m%d)  # Simplified for example
  ctmcontb -ADD VIDEO_READY $ODAT
  echo "Added condition VIDEO_READY-$ODAT"
else
  echo "File not found: $FILE_PATH"
fi

The Dark Side: When Condition Dates Cause Silent Failures

Condition dates are great for isolation, but they can also cause silent failures that are hard to debug. For example, if a job adds a condition with a date that no downstream job expects, the condition sits there forever, consuming resources and confusing operators.

Another issue: conditions with dates in the past can accumulate. Control-M doesn't automatically clean them up unless you configure retention. Over time, the Conditions manager becomes cluttered, and finding the right condition becomes a nightmare.

Mitigation: Set up regular cleanup of old conditions. Use Control-M's condition retention policies or a scheduled job that deletes conditions older than X days.

#!/bin/bash
# io.thecodeforge — DevOps tutorial

# Delete conditions older than 7 days
# Use with caution: ensure no jobs are waiting for these conditions

CUTOFF_DATE=$(date -d '7 days ago' +%m%d)
ctmcontb -LIST "*" "*" | while read line; do
  COND_NAME=$(echo $line | awk '{print $1}')
  COND_DATE=$(echo $line | awk '{print $2}')
  if [ ! -z "$COND_DATE" ] && [ "$COND_DATE" -lt "$CUTOFF_DATE" ]; then
    ctmcontb -DELETE $COND_NAME $COND_DATE
    echo "Deleted $COND_NAME $COND_DATE"
  fi
done