关于 Autosys 条件的问题
Questions on Autosys conditions
所以我定义了以下 3 个作业...
/* ----------------- JOB_A ----------------- */
insert_job: JOB_A job_type: CMD
command: ${BatchScripts}/JOB_A.ksh
machine: xyz
owner: abc@xyz
permission: mx
date_conditions: 1
run_calendar: 13BUSDAY
start_times: "00:10"
std_out_file: /autotmp/JOB_A.std
std_err_file: /autotmp/JOB_A.err
alarm_if_fail: 1
profile: /export/home/abc/.profile_autosys
/* ----------------- JOB_B ----------------- */
insert_job: JOB_B job_type: CMD
command: ${BatchScripts}/JOB_B.ksh
machine: xyz
owner: abc@xyz
permission: mx
date_conditions: 1
run_calendar: 13BUSDAY
start_times: "00:15"
condition: s(JOB_A)
std_out_file: /autotmp/JOB_B.std
std_err_file: /autotmp/JOB_B.err
alarm_if_fail: 1
profile: /export/home/abc/.profile_autosys
/* ----------------- JOB_C ----------------- */
insert_job: JOB_C job_type: CMD
command: ${BatchScripts}/JOB_C.ksh
machine: xyz
owner: abc@xyz
permission: mx
date_conditions: 1
run_calendar: 13BUSDAY
start_times: "00:45"
condition: s(JOB_B)
std_out_file: /autotmp/JOB_C.std
std_err_file: /autotmp/JOB_C.err
alarm_if_fail: 1
profile: /export/home/abc/.profile_autosys
他们运行,查看他们的状态,我看到了这个。
Job Name Last Start Last End ST Run/Ntry Pri/Xit
___________________ ____________________ ____________________ __ ________ _______
JOB_A 05/18/2016 00:10:03 05/18/2016 00:46:22 SU 76659457/1 0
Job Name Last Start Last End ST Run/Ntry Pri/Xit
___________________ ____________________ ____________________ __ ________ _______
JOB_B 05/18/2016 00:46:24 05/18/2016 00:48:19 SU 76660708/1 0
Job Name Last Start Last End ST Run/Ntry Pri/Xit
___________________ ____________________ ____________________ __ ________ _______
JOB_C 05/18/2016 00:45:03 05/18/2016 00:45:07 SU 76660477/1 0
现在,我们在 JOB_C 上遇到了问题 .. 它不是 运行ning "properly" ......我们设法追溯到它是 运行宁早于它应该。
换句话说,正如您在 JOB_C 的 START/END 时间看到的那样,它甚至在 JOB_B 开始之前就开始了(并结束了)。
我对此感到困惑,因为我们在 JOB_C 上有一个条件 "s(JOB_B)" ...
是什么导致了这种行为? JOB_B 等待 JOB_A 应该的, 运行 很好,但是 JOB_C 似乎有点 "impatient".
这已经发生了几个晚上,但似乎不是每晚都发生(可能 3 次中有 1 次以上述方式失败)。
我唯一猜测的是,因为 JOB_B 还没有 "started" @:45 分钟...它从之前的 运行 看到了 SU?
然而,这没有意义,因为JOB_B 设置为开始@:15 .. 它不应该先更改为 AC 状态吗?然后根据条件等待JOB_A??
[编辑]
版本是:
CA Workload Automation 代理
用于 LINUX(英特尔)32 位
版本 R11.3,Service Pack 2,维护级别 0,内部版本 508
[/编辑]
你说作业 C 提前开始是正确的,因为在 00:45 作业 B 仍处于其之前 运行 的 SU 状态。作业 B 等待作业 A,因为当作业 B 的 运行 时间在 00:15 触发时作业 A 的状态为 RU。
作业 B 没有更改为 AC 状态,因为它不在可以激活它的框内。
我的建议是将作业 A、B 和 C 放置在计划于 00:10 开始的框中,并删除作业 A 的 start_times。这应该会导致作业 A 在 00:10 立即开始,作业 B 和 C 将更改为 AC 状态并防止您遇到的问题。
所以我定义了以下 3 个作业...
/* ----------------- JOB_A ----------------- */
insert_job: JOB_A job_type: CMD
command: ${BatchScripts}/JOB_A.ksh
machine: xyz
owner: abc@xyz
permission: mx
date_conditions: 1
run_calendar: 13BUSDAY
start_times: "00:10"
std_out_file: /autotmp/JOB_A.std
std_err_file: /autotmp/JOB_A.err
alarm_if_fail: 1
profile: /export/home/abc/.profile_autosys
/* ----------------- JOB_B ----------------- */
insert_job: JOB_B job_type: CMD
command: ${BatchScripts}/JOB_B.ksh
machine: xyz
owner: abc@xyz
permission: mx
date_conditions: 1
run_calendar: 13BUSDAY
start_times: "00:15"
condition: s(JOB_A)
std_out_file: /autotmp/JOB_B.std
std_err_file: /autotmp/JOB_B.err
alarm_if_fail: 1
profile: /export/home/abc/.profile_autosys
/* ----------------- JOB_C ----------------- */
insert_job: JOB_C job_type: CMD
command: ${BatchScripts}/JOB_C.ksh
machine: xyz
owner: abc@xyz
permission: mx
date_conditions: 1
run_calendar: 13BUSDAY
start_times: "00:45"
condition: s(JOB_B)
std_out_file: /autotmp/JOB_C.std
std_err_file: /autotmp/JOB_C.err
alarm_if_fail: 1
profile: /export/home/abc/.profile_autosys
他们运行,查看他们的状态,我看到了这个。
Job Name Last Start Last End ST Run/Ntry Pri/Xit
___________________ ____________________ ____________________ __ ________ _______
JOB_A 05/18/2016 00:10:03 05/18/2016 00:46:22 SU 76659457/1 0
Job Name Last Start Last End ST Run/Ntry Pri/Xit
___________________ ____________________ ____________________ __ ________ _______
JOB_B 05/18/2016 00:46:24 05/18/2016 00:48:19 SU 76660708/1 0
Job Name Last Start Last End ST Run/Ntry Pri/Xit
___________________ ____________________ ____________________ __ ________ _______
JOB_C 05/18/2016 00:45:03 05/18/2016 00:45:07 SU 76660477/1 0
现在,我们在 JOB_C 上遇到了问题 .. 它不是 运行ning "properly" ......我们设法追溯到它是 运行宁早于它应该。 换句话说,正如您在 JOB_C 的 START/END 时间看到的那样,它甚至在 JOB_B 开始之前就开始了(并结束了)。
我对此感到困惑,因为我们在 JOB_C 上有一个条件 "s(JOB_B)" ...
是什么导致了这种行为? JOB_B 等待 JOB_A 应该的, 运行 很好,但是 JOB_C 似乎有点 "impatient".
这已经发生了几个晚上,但似乎不是每晚都发生(可能 3 次中有 1 次以上述方式失败)。
我唯一猜测的是,因为 JOB_B 还没有 "started" @:45 分钟...它从之前的 运行 看到了 SU?
然而,这没有意义,因为JOB_B 设置为开始@:15 .. 它不应该先更改为 AC 状态吗?然后根据条件等待JOB_A??
[编辑] 版本是: CA Workload Automation 代理
用于 LINUX(英特尔)32 位
版本 R11.3,Service Pack 2,维护级别 0,内部版本 508 [/编辑]
你说作业 C 提前开始是正确的,因为在 00:45 作业 B 仍处于其之前 运行 的 SU 状态。作业 B 等待作业 A,因为当作业 B 的 运行 时间在 00:15 触发时作业 A 的状态为 RU。
作业 B 没有更改为 AC 状态,因为它不在可以激活它的框内。
我的建议是将作业 A、B 和 C 放置在计划于 00:10 开始的框中,并删除作业 A 的 start_times。这应该会导致作业 A 在 00:10 立即开始,作业 B 和 C 将更改为 AC 状态并防止您遇到的问题。