AWS Transform for mainframe refactor

Control-M

Control-M is an enterprise workload automation and job scheduling platform developed by BMC Software that serves as a centralized orchestration hub for managing complex batch processing workflows across heterogeneous IT environments.

Throughout this documentation, the term "task" refers to a scheduled task defined in the scheduler, to avoid confusion with JCL jobs.

The extracted Control-M scheduler follows XML syntax with a structured layout like the following example.

<?xml version="1.0" encoding="utf-8"?>
<DEFTABLE xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="Folder.xsd">
    <FOLDER FOLDER_NAME="F1">
        <JOB JOBNAME="JOB1" PARENT_FOLDER="F1" JOBISN="1" TASKTYPE="JOB" MEMNAME="JCLNAME1">
            <OUTCOND NAME="CONDITION1" SIGN="+"/>
            <ON STMT="*" CODE="COMPSTAT EQ 4">
                <DOCOND NAME="COND_WARN" SIGN="+"/>
            </ON>
            <ON STMT="*" CODE="COMPSTAT NE 0">
                <DOFORCEJOB TABLE_NAME="F1" NAME="CLEANUP"/>
            </ON>
        </JOB>
        <JOB JOBNAME="JOB11" PARENT_FOLDER="F1" JOBISN="2" TASKTYPE="JOB" MEMNAME="JCLNAME2">
            <INCOND NAME="CONDITION1" AND_OR="A"/>
            <OUTCOND NAME="CONDITION1" SIGN="-"/>
            <OUTCOND NAME="CONDITION2" SIGN="+"/>
        </JOB>
        <JOB JOBNAME="JOB_PARTIAL" PARENT_FOLDER="F1" JOBISN="3" TASKTYPE="JOB" MEMNAME="JCLPART">
            <INCOND NAME="COND_WARN" AND_OR="A"/>
        </JOB>
        <JOB JOBNAME="CLEANUP" PARENT_FOLDER="F1" JOBISN="4" TASKTYPE="JOB" MEMNAME="JCLCLEAN">
        </JOB>
    </FOLDER>
    <SMART_FOLDER SMART_FOLDER_NAME="SF1" PARENT_FOLDER="F1">
        <JOB JOBNAME="JOB2" PARENT_FOLDER="SF1" JOBISN="1" TASKTYPE="JOB" MEMNAME="%%VAR">
            <INCOND NAME="CONDITION2" AND_OR="A"/>
            <OUTCOND NAME="CONDITION2" SIGN="-"/>
            <VARIABLE NAME="%%VAR" VALUE="JCLNAME3" />
        </JOB>
    </SMART_FOLDER>
</DEFTABLE>

Based on the example above, job dependencies are as following:

layout-xml-tags.png

Tasks organization

  • DEFTABLE: Tag DEFTABLE is the root element to indicate the beginning and end of a set of folder and task definitions.
  • SMART_FOLDER & FOLDER: Tag SMART_FOLDER and tag FOLDER are organizational structures for managing tasks, where they contain individual task definitions. They can be considered as the task groups.

Task definition

Tag JOB can imply the task to be triggered. Inside JOB tag, variety of attributes can be configured, such as the task name, member name, task type, etc.

VARIABLE

Tag VARIABLE is the dynamic placeholder that stores values and can be used throughout task definitions for flexible automation and parameterization.

INCOND/OUTCOND

Tag INCOND and tag OUTCOND configure the control task mechanism based on external events or states. Dependencies created form OUTCOND/INCOND condition matching are classified as UNCONDITIONAL.

  • INCOND provides requirements for triggering current job.
    • Attribute NAME states the required event name. In the example below, CONDITION1 is required for triggering current task, which was defined in the OUTCOND tag in the first task JOB1.
    • Attribute AND_OR states the relationships of the requirements. It functions as logical operators. Both AND and OR relations will consider the event to be the predecessor.
  • OUTCOND provides event outcome.
    • Attribute NAME stats the name of the outcome. This name could be used in INCOND tag in other tasks.
    • Attribute SIGN stats the action of the name. A positive sign (+) adds the event name and a negative sign (-) removes the event name. When the event name is removed, the next jobs will not be able to use the event as a predecessor. i.e. been configured in INCOND.
  • Both INCOND and OUTCOND works together to build the links among tasks.
<INCOND NAME="CONDITION1" AND_OR="A"/>
<OUTCOND NAME="CONDITION1" SIGN="-"/>
<OUTCOND NAME="CONDITION2" SIGN="+"/>

In the main example above, JOB1 defines OUTCOND NAME="CONDITION1" SIGN="+" and JOB11 defines INCOND NAME="CONDITION1" AND_OR="A". This creates an unconditional "Exec Next Scheduled Task" edge from JOB1 to JOB11.

The JSON output for an unconditional dependency includes the property schedulerDependencyType set to "UNCONDITIONAL".

{
    "dependencyType": "Exec Next Scheduled Task",
    "name": "F1-2-JOB11-example.controlm",
    "path": "Global:SCHEDULED_TASK:F1-2-JOB11-example.controlm",
    "properties": {
        "schedulerDependencyType": "UNCONDITIONAL"
    },
    "type": "SCHEDULED_TASK"
}

Missing OUTCOND or INCOND

When an OUTCOND SIGN="+" condition has no matching INCOND consumer, a missing dependency is created with the property schedulerDependencyType set to "UNCONDITIONAL" and missing category Missing Task Output Condition.

When an INCOND condition has no matching OUTCOND producer (and no DOCOND producer), a missing dependency is created with the property schedulerDependencyType set to "UNCONDITIONAL" and missing category Missing Task Output Condition.

Control-M supports conditional task execution through ON/DO blocks, which allow tasks to trigger different actions based on runtime conditions such as return codes (COMPSTAT). Dependencies created from ON/DO blocks are classified as CONDITIONAL.

DOCOND

DOCOND appears inside ON/DO blocks in the Control-M XML. When SIGN="+", it adds a condition that can be consumed by another task's INCOND, creating a conditional dependency chain.

<ON STMT="*" CODE="COMPSTAT EQ 4">
    <DOCOND NAME="COND_WARN" SIGN="+"/>
</ON>

In the main example above, the ON block fires only when COMPSTAT equals 4. When it fires, the condition COND_WARN is added. Task JOB_PARTIAL consumes this condition via INCOND NAME="COND_WARN", so the dependency JOB1 → JOB_PARTIAL is classified as CONDITIONAL with description DOCOND:COND_WARN.           
When SIGN="-", DOCOND removes a condition. This does not create a dependency edge.           
The JSON output for a DOCOND conditional dependency includes the properties schedulerDependencyType set to "CONDITIONAL" and schedulerDependencyDescription set to "DOCOND:condition_name".

{
    "dependencyType": "Exec Next Scheduled Task",
    "name": "F1-3-JOB_PARTIAL-example.controlm",
    "path": "Global:SCHEDULED_TASK:F1-3-JOB_PARTIAL-example.controlm",
    "properties": {
        "schedulerDependencyDescription": "DOCOND:COND_WARN",
        "schedulerDependencyType": "CONDITIONAL"
    },
    "type": "SCHEDULED_TASK"
}

DOFORCEJOB

DOFORCEJOB appears inside ON/DO blocks and forces the execution of a specific target task when the ON statement's runtime condition is met. It creates a direct CONDITIONAL dependency to the target task.

<ON STMT="*" CODE="COMPSTAT NE 0">
    <DOFORCEJOB TABLE_NAME="F1" NAME="CLEANUP"/>
</ON>

In the main example above, the ON block fires only when COMPSTAT is not equal to 0. When it fires, task CLEANUP is forced to execute. The dependency JOB1 → CLEANUP is classified as CONDITIONAL with description DOFORCEJOB:CLEANUP.

The JSON output for a DOFORCEJOB conditional dependency includes the properties schedulerDependencyType set to "CONDITIONAL" and schedulerDependencyDescription set to "DOFORCEJOB:target_job_name".

{
    "dependencyType": "Exec Next Scheduled Task",
    "name": "F1-4-CLEANUP-example.controlm",
    "path": "Global:SCHEDULED_TASK:F1-4-CLEANUP-example.controlm",
    "properties": {
        "schedulerDependencyDescription": "DOFORCEJOB:CLEANUP",
        "schedulerDependencyType": "CONDITIONAL"
    },
    "type": "SCHEDULED_TASK"
}

Missing conditional dependencies

When a DOCOND SIGN="+" condition has no matching INCOND consumer in any task, a missing dependency is created. The missing dependency retains the properties schedulerDependencyType set to "CONDITIONAL" schedulerDependencyDescription set to "DOCOND:condition_name".

When the target task referenced by DOFORCEJOB is not found in the inventory, a missing dependency is created. The missing dependency retains the properties schedulerDependencyType set to "CONDITIONAL" and schedulerDependencyDescription set to "DOFORCEJOB:target_job_name".

Attributes

JOBNAME

Attribute JOBNAME implies the unique identifier assigned to each task definition within a folder.

JOBNAME="JOB1"

JOBISN

Attribute JOBISN (Job Internal Sequence Number) implies the unique numeric identifier automatically assigned to each task execution instance.

JOBISN="1"

TASKTYPE

Attribute TASKTYPE implies the category or type of task being executed, determining how Control-M processes and handles the task

TASKTYPE="Job"
TASKTYPE="Command"
TASKTYPE="SMART Table"

Task type "SMART Table" exists in SMART_FOLDER tag.         
Task type "Job" and "Command" exist in JOB tag, which executes scheduled tasks by running batch job (JCL) and through command line, respectively.

MEMNAME (MEMBER_NAME)

Attribute MEMNAME or MEMBER_NAME implies the triggered batch job (JCL).

MEMNAME="JCLNAME"

CMDLINE

Attribute CMDLINE implies the field that contains the actual executable command, script, or program that the task will run when executed.

CMDLINE="/path/to/utility %%JOBNAME"
  • Command line syntax

    • Partially supported         
      Depending on how many arguments required by the utility, only specific utilities are supported.

      "/path/to/utility %%JOBNAME"
    • Fully supported

      • Call JCL (default) / PROC / program. Supports PARM and multi-calls.

        CALL PGM(PGM_NAME) PARM('');
CALL PGM(C405HFIFA);
CALL (C409E0266);CALL (C409E0267);
CALL PGM(C409QENDMS) PARM('1');CALL PGM(C409QENDMS) PARM('2');CALL PGM(C409QENDMS) PARM('3');CALL PGM(C409OSTOEM);CALL PGM(C409OSTODM) PARM('prod');

      • Submit job

        SBMJOB CMD(CALL PGM(DAILYPROC)) JOB(DAILYRUN) JOBQ(QBATCH) USER(QPGMR);
SBMNETJOB FILE(L910/QRJESRC) TOUSRID((E469JOB COP)) MBR(D4690M86);

PARENT_FOLDER

Attribute PARENT_FOLDER implies the hierarchical folder structure where a task or subfolder is contained, establishing organizational relationships and inheritance properties.

PARENT_FOLDER="FOLDER_NAME"