Control-M作业调度核心：AJF生命周期与条件依赖避坑指南

简介：《Control-M 作业配置手册》是一份面向初学者的作业定义指南，也适合有经验的调度管理员作为参考手册。内容从 CONTROL-M/EM 与 SERVER 的协同工作讲起，涵盖作业生命周期、Smart Table/Sub Table 定义、作业类型与依赖关系、调度策略、监控告警等核心模块，并结合三个实际案例讲解常见配置要点。全手册以单个 doc 文档形式提供，约 3.05MB，便于离线阅读与按需检索。目前已有 74529 人浏览学习，资源还整理了包括时间依赖、作业依赖、事件触发、失败重试与最佳实践在内的高频知识点，能帮助读者快速理解作业定义机制、减少排错时间，并在企业中规范落地批处理调度流程。

1. 调度器不是定时器：Control-M 作业生命周期与 AJF 到底管了什么事

很多人第一次接触 Control-M（简称 CTM）时，会下意识拿它和 crontab 类比：写个时间、挂个脚本、到点执行，完事。真到了现场就会发现，批处理环境远没这么简单——作业之间有先后依赖、有跨天日历、有失败重试和后置清理，而这些逻辑的核心并不在“到点执行”这一步，而在一张叫 AJF（Active Jobs File）的当天活动作业清单里。这份作业配置手册讲的就是从定义到跑通的完整链路：表怎么建、作业怎么挂、条件怎么配、实例怎么查，适合第一次接触 CTM 的运维和调度岗，也适合老手把它当参数速查手册来用。

真正让批处理稳定的，不是脚本本身，而是你把作业“放进当天调度”的方式，以及条件依赖有没有成对管理。下面从组件链路开始拆。

2. 组件链路与作业落盘：EM、Server、Agent 在每次 Order 里各自干了什么

2.1 一次作业调度走完的完整链路

Control-M 的架构在手册里讲得很清楚，但实际排障时，很多人只盯着一个组件看不出来问题。拆开看，一次调度是三层配合：

• Control-M/EM（Enterprise Manager）：集中管理入口，负责定义作业、监控运行、管理整个环境。一个 EM 可以连多个 Server。
• Control-M/Server：排程引擎，管调度、调起、作业流和状态更新。它不直接跑业务脚本。
• Control-M/Agent：安装在业务机上的执行器，接收 Server 下发的命令，真正拉起作业，需要超级用户权限。

我一般会在脑子里画一条线：Desktop 里定义作业 → 保存到 EM 数据库 → 上传到 Server 的定义库 → Order 或 Force 把作业放进 AJF → Server 根据 AJF 调起 Agent → Agent 执行业务脚本 → 状态回写 AJF 和 EM。

这条链路上，多数“到点没跑”的问题不是出在脚本本身，而是作业根本没进 AJF，或者进了 AJF 但前置条件没满足。先确认作业当天是否在 AJF 里，永远比翻脚本日志快。

2.2 AJF 的生成、同步和 New Day 清账

AJF 是当天活动作业的运行环境，维护一个工作日内所有准备运行的作业。理解 AJF 的关键是理解 New Day 这个动作：每天服务器根据作业运行周期重建 AJF，清除昨天执行完成的作业，放入今天要跑的，清理旧日志，然后把新 AJF 同步到 EM。

作业从定义库进入 AJF 的动作叫 Order 或者 Force。两者的区别通常在手册里没有展开讲，我的经验是：Order 是按计划把作业排入当天调度，Force 是忽略计划直接强制放入。日常排障时，Force 是手动救急的后悔药，但它不会改变第二天的正常调度，因为第二天 New Day 会把 AJF 重建一遍。

这里有一个很容易忽略的细节：作业生命周期是从 Order/Force 开始，到完成后处理（ENDED-OK 之后的 Post-Processing）结束。New Day 只清理已经完成生命周期的作业，如果你手动干预过作业状态，跨天后的表现可能和预期不一样，后面避坑章会说。

2.3 作业的两种组织方式：物理表和逻辑分组

作业在 CTM 里有两种组织方式，新手经常混淆。

数据组织方式指的是物理存储：Control-M/Server → Scheduling Table → Job。所有作业定义都归属到某张调度表，一般把相关作业放同一张表。调度表分两类：普通 Scheduling Table 和 Group Scheduling Table，后者自带排程计划功能。

逻辑组织方式是监控界面的三层展示：Control-M/Server → Application → Group → Job。也就是手册里常说的应用、组、作业三级目录。这里的 Application 和 Group 只是逻辑归类，不决定作业存到哪张表。

我踩过一个坑：把逻辑分组当物理存储，在 Desktop 里找不到作业就去翻数据库表，结果作业其实在另一张表里，只是 Application 名相同。记住一个原则：物理上作业属于某张 Table，逻辑上作业挂在某个 Application/Group 下，两者可以不一致，但日常维护尽量保持一致，否则操作的人会蒙。

3. 定义一张 SMART Table：五张 Tab 的参数对照与 PostProc 条件管理

3.1 SMART Table 和 Sub Table 的选型

定义作业的第一步不是建作业，而是建表。手册里把表分成 SMART Table 和 Sub Table 两层，我理解为一套复杂的批处理不可能全塞在一张平铺的表里，需要按业务模块拆层级。

SMART Table 是根表，自带排程和日历信息；Sub Table 挂在 SMART Table 或更上层的 Sub Table 下面，继承父表的 Application 和 Group 设置。选择逻辑很简单：如果一组作业共享同一套日历和并发窗口，就收到一张 SMART Table 下；如果同一张 SMART Table 内部还要按场景拆批次，就在下面拆 Sub Table。

举例来说，日终批处理是一张 SMART Table，里面的“账务核对批次”和“报表生成批次”分别建 Sub Table，每个 Sub Table 有自己的前置条件和提交时间。这样监控的时候按逻辑组看，不会几百个作业挤在一张表里。

3.2 General 与 Scheduling：把作业放进正确的日历

新建 SMART Table 时，第一个要填的 Tab 是 General。我逐个参数说明：

Scheduling Tab 里重点看三个值：RBC Name 一般与表名一致即可；Days 和 Months 决定表在哪些日子执行。这里最容易出错的是“只填了月份没勾日期”，或者反过来，结果表在预期时间完全不动。我填完日历的习惯是回去看 Days 的摘要，确认勾选范围符合业务日历再保存。

3.3 Execution 与 Condition：提交窗口和条件依赖

Execution Tab 的 Submit 字段设定表的开始执行时间。注意手册里那个 “>” 符号——它表示无限延长，也就是不限定提交时刻，让表内的作业在条件满足后尽早上场。如果业务上没有硬性时间窗口，我建议直接用 “>”，把时间约束下沉到具体作业或依赖条件上，避免表级时间卡死导致整批延迟。

Condition Tab 分 IN Condition 和 OUT Condition。IN 是这张表开始前必须满足的前置条件；OUT 是这张表跑完后对外释放的条件。条件没配好，最常见的现象就是“上游跑完了，下游就是不动”，查状态全是 Wait Condition。

3.4 PostProc：条件成对管理的关键一环

PostProc 是很多人会跳过不填的 Tab，但它恰恰决定了条件体系能不能长期稳定。图中最常用的场景是：SMART 表执行成功后，删除自己的 IN Condition，并生成自己的 OUT Condition。

为什么删 IN Condition 很关键？因为 CTM 的条件是累积的。如果一张表每天跑完都生成条件，但没人消费和删除，条件就会越积越多。后续再改调度逻辑时，旧条件可能命中新的作业，让你误以为逻辑是对的——这是批处理里最常见的“黑匣子”。

我建表时给自己定了一条规矩：每建一个 IN Condition，就必须在 PostProc 里写一个对应删除；每建一个 OUT Condition，就必须确认下游有作业消费它，或者有 PostProc 清理它。做不到成对，宁可不写条件，靠作业级的依赖也能跑。

4. 从表到作业：Command 类作业的参数拆解与 Desktop 登录检查清单

4.1 登录 Desktop 之前先核对三件事

手册里 4.2 讲了怎么登录 Desktop，但实际工作中登录失败的原因通常是环境层面的。登录界面三层信息：User Name、Password、Server。常见做法是，先确认 Server 名填的是不是 EM 所管理的那台；再看账号有没有 Desktop 定义作业的权限；最后确认本机到 EM 的网络端口通不通。

我一般会在登录前做一次最小检查：先开 EM/GUI 监控界面，如果监控能登录而 Desktop 不能，多半是权限问题而不是连接问题；两个都登不上，再去查 EM 服务和端口。

4.2 四种作业类型：Command、Job、Detached、Dummy 怎么选

手册里提到作业类型有四种，绝大多数场景下你只需要记住第一种和最后一种。

Command 是最常用的，核心参数是“在哪个 Agent 上、用什么用户、跑什么命令”。这里容易翻车的是运行用户：脚本写的是相对路径，Agent 拉起来时工作目录和手工执行时不一样，文件就找不到了。定义命令时尽量写绝对路径，并在命令前显式 cd 到工作目录。

Job 类型适合做模板复用：同一个数据抽取脚本，不同时间段跑，参数不同，可以定义一个基础作业，再建几个引用它的 Job。Dummy 作业的价值很多人低估了——当某张表的条件依赖特别复杂时，用 Dummy 作业做“条件桥”，比直接跨表挂条件更直观，后期调组顺序也不容易断链。

Detached 作业我很少用，因为它的状态回写依赖外部系统主动通知 CTM，配置成本高；能用 Command 包一层脚本解决的，就别用 Detached。

4.3 定义 Command 作业的完整步骤与命令行备用方案

图形化定义是主路径：进入 Desktop，右键到要挂的 Table 或 Sub Table，新建作业，选 Command，填作业名、命令、Agent、运行用户，再配条件和日历。保存后先不要急着 Order，在 Desktop 里检查几个关键参数是否落到位。

图形界面不可用时，CTM 提供了命令行工具作为备用方案，定义作业、Order 作业都可以在命令行完成。不同版本的工具命令名有差异，下面是占位形态，具体以你环境的 EM Utility Guide 为准：

# 用命令行方式创建 Command 作业（示意，命令名因版本而异） ctm_jobdef -table "DAILY_CLOSE" \ -job "JOB_ACCOUNT_SUM" \ -command "/home/sched/bin/account_sum.sh" \ -agent "PROD_APP_AGENT" \ -user "sched" \ -condition-in "DAILY_CLOSE.JOB_PREP.OK"

这段命令的逻辑是：在 DAILY_CLOSE 表里创建名为 JOB_ACCOUNT_SUM 的 Command 作业，在 PROD_APP_AGENT 这台 Agent 上用 sched 用户执行指定脚本，并且要求 DAILY_CLOSE 表里的上游作业 JOB_PREP 成功结束（状态 OK）后才允许运行。参数说明：

• -table：作业要挂的调度表名，不存在时先建表。
• -command：拉起的实际命令，建议写成绝对路径的脚本。
• -agent：目标执行机，Agent 必须在这台机器上已安装并注册。
• -condition-in：前置条件，格式通常是“表名.作业名.状态”。

命令行方式的好处是方便批量维护，比如几十个同构作业改 Agent 或改命令，写个循环脚本就能处理。坏处是参数没有图形界面那样直观，填错了要等运行结果才能发现。所以我一般把命令行当批处理脚本用，日常单作业定义还是走 Desktop。

4.4 作业状态的观察窗口

作业进入 AJF 后，在 EM/GUI 能看到状态变化。常见的几个状态点：Wait Condition（等条件）、Wait Schedule（等时间）、Running（运行中）、ENDED-OK（正常结束）、ENDED-NOTOK（异常结束）。

我排查时习惯先看“卡在哪个状态”，而不是直接查脚本日志。卡在 Wait Condition 是条件问题，卡在 Wait Schedule 是时间问题，Running 之后才变红才是脚本问题。这个顺序能省下大量翻日志的时间。

5. 避坑：作业既没跑也没告警时，按这五条排查

5.1 表建好了却不跑：Submit 时间与日历互相打架

现象：Smart Table 定义完整，日历也选了，到点就是不动，监控里看作业一直是 Wait Schedule。

原因：Execution Tab 里的 Submit 写死了一个具体时刻，而 Scheduling 里的日期范围只在某一个跨天窗口才匹配；或者 Submit 时间精确到了“零点前后”，导致 New Day 重建 AJF 时，作业被归到前一天或后一天。

解决：先看作业当天的计划时间（Scheduled Time）是什么；再看 Submit 是否用了 “>” 无限延长；最后确认日历的日期范围和 Agent 所在时区一致。我实际处理过一个“每周五 23:55 跑，但表日历按月勾选”的情况，改掉日历后立即恢复。

5.2 条件永远等不到：上游作业根本没生成对应的 OUT Condition

现象：下游作业长时间停在 Wait Condition，上游明确已经 ENDED-OK，但条件就是不来。

原因：上游表或作业没有配置生成 OUT Condition；或者生成了，但条件名和下游 IN Condition 写的名字对不上。

解决：在 EM/GUI 里查条件列表，看上游运行完后是否产生了这条条件。如果没有，去上游作业的 Condition Tab 补 OUT Condition；如果条件名不对，统一命名规范。这里要特别提醒：条件名是精确匹配的，多一个空格都等不到。

5.3 手动 Force 后第二天又跑了一次

现象：昨天发现作业漏跑，手动 Force 让它补跑完成。结果今天 New Day 后，作业又被正常调起来了，同一批数据跑了两遍。

原因：Force 只是把作业放进了当天的 AJF，第二天 New Day 会按正常的顺序周期重新生成 AJF，作业该跑还是跑。

解决：Force 补跑后，如果业务上今天不需要再跑，需要手动把作业状态置为成功或删除当天实例；或者直接在日历里确认今天的计划确实存在再决定是否需要干预。记住一个原则：Force 是当天救急，不是长期改计划的工具。

5.4 User Daily 和 Application 不一致，Order 作业时找不到表

现象：运维同事批量 Order 作业时，在自动提交列表里看不到某张 SMART Table，明明表存在且有空作业。

原因：User Daily 填了一个值，Application 填了另一个值，每日批量 Order 按 User Daily 维度过滤时，这张表被分到了另一个业务域里。

解决：新建表时保持 User Daily、Application、Group 三者命名一致。已经有历史表的，在 General Tab 里统一改掉，改完重新 load 一次让 Server 同步定义库。

5.5 作业量多时，在 Desktop 里找不到目标作业

现象：搜索作业名，结果列表里没有它；但相同作业在监控里能看到。

原因：搜索时没有限定表或 Application，Desktop 默认按当前选中的 Table 过滤；或者作业被定义在了另一张表里，只是逻辑 Group 看起来和当前一致。

解决：先确认作业在监控界面的路径——它挂在哪个 Application 和 Group 下；再到 Desktop 按这个路径展开；还是找不到，用 EM 的作业搜索功能按名字全局搜一次，搜索结果里会显示它所属的物理 Table。物理表和逻辑分组的区分，前端看不出来，必须靠这个归属关系定位。

6. 定义完不着急上线：先手动 Order 一次跑通三条链

新建的 Smart Table 或作业，不要直接等计划时间自动触发，我会先手动 Order 一次，验证三个链路：表路径对不对、条件链条通不通、命令本身能不能跑通。

先说表路径。在 Desktop 里定位到新建的作业，右键 Order，确认它进入 AJF 后出现在正确的 Server 和 Table 下。这一步验证的是物理归属，如果发现作业进了别的表，后面所有基于表名挂的条件关系都会错位。

再说条件链条。新建作业如果带了 IN Condition，手动 Order 后应观察它是否停在 Wait Condition。如果在没有任何上游释放条件的情况下直接运行了，先检查条件是不是写错了；如果一直等不到，去上游作业确认 OUT Condition 是否存在。手动验证时可以把上下游一起 Order，观察条件是否按预期释放和消费。

最后说命令本身。确认作业从 Running 变到 ENDED-OK，然后去 Agent 所在机器看脚本输出和退出码。这里有一个经常被跳过但很值得做的动作：新建作业第一次跑通后，主动去消费一次这个作业的 OUT Condition，或者确认 PostProc 里的删除逻辑生效，避免条件在 AJF 里残留。

我把这个验证动作固化成了一张检查清单：路径对得上、条件成对出、脚本退出码为 0。从那以后，每次建完新表或新作业，我都强制先手动 Order 一遍，不点完这三个确认不放心。关键是，这条习惯救过我很多次——有一次新表里一个脚本用了相对路径，Agent 拉起来工作目录不对，脚本退出码非 0，如果不是先手动 Order 验证，第二天早上就是整批任务挂着不动。希望帮到你。

本文还有配套的精品资源，点击获取