执行计划控制
执行计划控制策略在调度应用中非常普遍，是调度控制策略中最重要的策略之一。执行计划指作业的运行周期，简单说，指一个作业什么时候需要运行，比如：每周一、每月初、每月底以及季末等。
在 TASKCTL中，执行计划非常灵活，几乎可以定义任意周期，同时，TASKCTL可以分别支持自然日期执行计划与逻辑日期执行计划。技术上，主要通过 datetype 与 period 两个属性结合使用来完成灵活的执行计划。
datetype-日期类型
datetype 日期类型主要分自然日期与逻辑日期
- 自然日期：自然日期即系统日期，用 msystime 表示，datetype 缺省就为msystime，此时通常不需要用户再修改。
- 逻辑日期：一个流程中可以存在多个逻辑日期，它主要通过私有参数中以类型为 date 参数进行定义，比如：一般常用的 workdate 参数。如果我们以逻辑日期确定执行计划时，datetype 设置为相应 date 类型的私有变量参数名称即可。
period-计划表达式
period 计划表达式主要是在 unix 系统的 Crontab 设计思想基础上进行改造，但从5.1 版本开始，TASKCTL为了简化用户对 period 的使用难度，精简了时间窗口特征， 仅仅保留 [日] [月] [周]。
执行计划表达式格式与说明：
[日] [月] [周] 整个表达式由三个字段组成，字段间通过空格分隔。
- 日：*表示每日；0 表示月末；-1 表示不按日判断，而是由周决定
- 月：*表示每月
- 周：*表示每天；0-6 分别代码礼拜天到礼拜六 在对日月周设置时，多个数字用’,’隔开，但不能有空格，如果是一段连续数字，可以按如下表达： 比如：日字段：1，3-15：表示 1 号，3 至 15 号。
表达式例子
- “* * *”: 表示每天可执行，缺省就是 * * *
- “0 6,12 *”: 表示每年 6 月月末、12 月月末可执行
- “-1 * 1,4”: 表示每周一、四可执行
- “2,4-10 1,2 *”: 表示 1,2 月的 2 号以及 4 到 10 号可执行
执行计划应用案例以下通过代码举例说明执行计划的应用
例子1以上计划按自然日期确定。表示每年 1、4、7、9 月，每 1、15 日可以执行。
例子2以上计划按逻辑日期workdate 参数日期确定。表示每年 1、4、7、9 月，每 1、15 日可以执行。
容错控制
容错策略主要表示流程调度运行过程中，作业运行错误后的后续处理机制。容错机制主要有两种方式：错误重做机制与错误忽略机制。
错误重做
错误重做机制指作业执行错误后可以根据用户 maxnum 属性设置次数反复重试，直到最大次数为止。如果达到最大次数，该作业还未成功，确定该作业失败， 所有依赖该作业的作业都不会执行。
以下通过一段代码说明：
错误忽略
错误重做忽略机制指作业执行错误后可以根据 maxnum 属性设置次数反复重试，直到最大次数为止，如果达到最大次数，该作业还未成功，那么通过 ignoreer 属性确定是否忽略错误，上图没有设置，默认为 N，不忽略，当此时显示设置属性值为 Y 时，错误被忽略，所有依赖该作业的作业继续往下执行。
以下通过一段代码说明：
循环控制
对于一些作业或模块希望循环执行，可以通过设置节点的循环属性来实现。
- cyclecount（v7.0 ） -- 循环次数， v7.0之前版本为 cycle
- cyclebreak（v7.0 ） -- 循环退出条件，满足条件则退回循环模块
- cycleinterval（v7.0 ） -- 每次循环结束后的等待间隔时间
返回信息策略
作业的回信息用来判断该作业调用成功与否。用数字来匹配作业程序的退出码。可使用连串数据：成功返回值 0-10，警告返回值 11-30 等。注意：用户自定义的返回值只能是在 0-100 之间。 v 7.0 新增支持返回信息匹配作业程序的输出信息。
- successv -- 作业成功状态返回信息
- errorv -- 作业错误状态返回信息
- failedv -- 作业失败状态返回信息
- warnningv -- 作业警告状态返回信息
返回信息判断支持两种规则：
- 作业程序退出码值规则
- 作业程序日志输出信息匹配规则
如果 successv 、errorv 、failedv 、warnningv 其中任一返回信息属性应用了“日志输出信息规则”，那么其它返回信息属性应用的“退出码值”规则就无效。
分片作业
在一些分布式计算的作业中，通常会用到分片技术，可以通过设置作业的分片执行属性来实现。
- issplit（v7.0 ） -- 是否应用分片执行策略
- splitcount（v7.0 ） -- 分片的个数或分片个数表达式
自动执行
默认情况下，作业只要满足调度条件后就会自动执行。如果需要对作业进行人为的确认后再执行，那么可以设置 autorun 为“N”。当流程运行到该作业时会暂停。直到进行确认执行后，流程才会继续运行。
优先级
作业 priority 属性用于控制并发的优先执行顺序。值越小表示优先级越高。
添加图片注释，不超过 140 字（可选）
取值范围为 1 ~ 100，在代码里面预设的 priority 值可以在 Monitor 客户端运行时环境动态调整优先级值。另外，在待执行队列中（作业状态为等待），可以对优先级进行置顶操作。
超时失败
作业 timeout 属性用于控制作业最大运行时间，单位为秒。当作业超时后，状态为失败，流程将暂停执行。当值为 0 时，表示不应用该属性。
远程调度与负载均衡
运程调度指当作业程序未部署在相应调度服务上时，调度服务器需要通过执行代理控制相应程序。
TASKCTL 远程调度比较简单，可以通过作业的 agentid 属性完成，只需通过该属性设置远程程序主机节点所部署的 CTL 执行代理的名称即可。如下图所示：
上图表明调度服务控制 agent3 部署 test2.sh 程序。
对于负载均衡应用，实际上与代码设计无关，只与部署相关。就拿以上调度示例为例，只需在 agent3 下级联从代理并与上级代理做相同的作业程序部署即可完成负载均衡调度。
如下图所示：
利用 hostuser 实现远程调度
从 v6.0 开始，TASKCTL 为用户提供统一的无代理远程调度机制。相对于代理模式来讲，无代理由于无需在受控目标机器部署相应的软件，即可调度控制相应的作业程序。这种变化，让调度控制空间格局，得到彻底的延展变化，极大拓展了调度的应用场景。这种场景适合运维管理自动化。
请注意：该方式需要配合 ssh 协议来实现。
sip 表示远程主机 IP，suser 表示远程主机执行用户，如下图所示：
自定义控制
核心调度控制策略的技术本质，就是确定一个作业的执行条件，比如：依赖并发等就是属于执行条件之一。其实，调度核心对作业的执行条件远非只有依赖并发这些条件，根据实际经验，我们可以总结出各种执行条件，
比如：执行计划、互斥、容错处理等均属于作业的执行条件，但是总结归纳是有限的，变化是无限的，在一些复杂情况下，总会存在一些不可确定的执行条件。
为此，我们在众多可总结的条件基础上，增加了用户自定义条件接口，以满足不可确定的调度需求， 从而也使 CIR 核心调度体系得以完善。
TASKCTL 自定义控制通过节点 condition 属性完成。该属性功能强大，可以完成各种复杂的调度应用需求，前面所讲的条件分支就是一个具体例子。
技术方面，condition 主要通过条件表达式来实现，以下通过一段代码来认识
condition 属性的应用
以上代码中，作业 SubModul0_JobNode0 在 job1 作业处理返回结果为 2 时处理，否则，该作业不处理。
condition 条件表达式说明
表达式基本结构 Condition 表达式结构主要是条件表达式结构，其结构如下：
由上可知，condition 表达式主要以 if-else 结构为基础，通过布尔运算表达式运算结构决定处理动作，布尔表达式运算结果为真，执行‘处理动作 1’；反之， 执行‘处理动作 2’。
布尔运算表达式
表达式局限范围 conditon 中，布尔运算表达式存在一定的限制范围，该表达式只支持 TASKCTL提供的内置函数运算，“==”、“!=”、“>=”、“>”、“<”、“<=”、“ ”、“-”、“*”、“/”以及“and”、“or”等有限的运算。
内置函数
内置函数主要在运算表达式中使用，所有函数运算结果都返回整数，以便参加布尔运算。主要函数如下表：
getjstate – 作业处理状态表 当前流程指定作业的处理状态值。处理状态值参见下表：
处理动作 处理动作，表示当前作业根据布尔表达式的结果进行的处理行为。
该处理行为有三种：
- CTL_DOIT：表示作业执行
- CTL_IGN：表示作业忽略，不作任何处理
- CTL_WAIT：表示作业不处理，还继续等待
condition 属性应用
例子1说明：在例子中，我们使用了缺省 else 结构，以及代码变量使用。该例表明如果当前流程变量 para1 的值为 100 时，执行当前作业，否则不执行并忽略通过
例子2说明：在例子中，我们使用 if-else 完整结构。该例表明如果 job1 的执行结果是 10 时，执行当前作业，否则不做并忽略通过。
例子3说明：该例表明如果自定义程序 myexe（并带两个参数 1 与 2）的执行结果是 5 时， 执行当前作业，否则继续等待。
虚拟资源控制
面对各式各样的调度控制需求，只要利用好上面的控制策略，从逻辑上来说是没有问题的。然而在大量并行作业组，这种实际应用场景中，有些作业仅仅需要几秒钟就能完成，有些作业则可能要花上几个小时时间。不同的作业对系统资源的需求也就不一样。
若分配给作业的资源都采用同样的方式，势必会造成资源的浪费。那么要怎样去平衡这样的资源消耗呢？TASKCTL 引入了虚拟资源的概念，通过设置作业的虚拟资源消耗权值，来达到这一目的。
在建立 CTL 代理控制节点的时候，TASKCTL 会为每个代理控制节点默认分配“1000”数值的虚拟资源，最大作业并发数为 100。调度服务端则默认分配“1000”数值的虚拟资源，最大作业并发数为 1000。如下图所示：
假如所有作业都采用系统默认资源消耗值“10”。容许同时并行 10 个作业，第 11 个并行作业则需要等待。
只有等这 10 个并行作业中，有作业运行完毕释放部分资源，并满足第 11 个并行作业的资源消耗需求条件，这个作业才会运行(其它控制策略都满足的情况下)。
VirResource 属性的应用
说明：设置作业的 virresource 属性，即可调整该作业的虚拟资源消耗值。请注意它只是一个权值，并没有具体的计量单位。且必须小于当前 CTL 控制节点的虚拟资源总值。通常情况下，我们并不需要调整该属性。
只有在大规模并行应用的条件下，可通过监控作业一段时期的耗时情况，才根据实际情况对其进行优化调整。
定时控制
从技术角度来说，定时控制策略和结构化控制策略中的串行、循环、依赖、互斥是对立的概念。在定时容器中，各个作业的关系都是并列且无序的，这意味着设置作业之间的关系都是无效的。
只需要按照一定的时间间隔执行即可。
定时控制策略只在定时控制容器中有效。因此，我们需要新建定时器控制容器。
建立好后查看模块代码如下：
Timingplan 定时表达式格式与说明
[*|hhmiss] [d|h|m|s] [num]
整个表达式由三部分组成，每部分用空格隔开。
- 第二部分的 d|h|m|s 表示时间间隔单位，分别是日，小时，分，秒。只能是其中之一。
- 第三部分的 num 表示时间间隔的整数值。
- 第一部分的* 和 hhmiss 是可选项，其中*表示控制器启动后立即开始定时控制。“hhmiss”表示开始定时控制的相对时间点。只有通过第二部分和第三部分计算出来的时间间隔，与当前系统时间正负差值的倍数，恰好能满足这个时间点才开始执行。
定时表达式例子
- * m 10 表示控制器启动后每隔 10 分钟执行一次
- 230101 s 30 表示控制器启动后，当前系统时间的秒部分为 31 或 01 开始，每隔 30 秒钟执行一次
- 230101 m 12 表示控制器启动后，若 (当前系统时间 /- 230101) % 12m= 0s，即当前系统时间与 230101 的正负差值跟 12 分钟的取余结果等于0 秒，则开始每隔 12 分钟执行一次
Timingplan属性也支持继承和缺省，若不设置该属性或该属性值为空，则不会定时执行（可以手动执行）。
