Run Service

The Run service enables you to run jobs and track their status, as well as manage several other types of objects for jobs.

Job Management

The following API commands enable you to manage your jobs, perform various job actions, track job status, and view job output and logs:

run

The run command enables you to run jobs on the Control-M environment. The command returns a runId, which you can use to check job status with the run status command.

The following example shows a typical command and response. The build action takes place as part of the run.

Copy
> ctm run examples/AutomationAPISampleFlow.json
{
   "runId": "2d4af716-e31d-48ef-a434-16575303752d",
   "statusURI": "https://ec2-54-187-1-168.us-west-2.compute.amazonaws.com:8443/run/status/2d4af716-e31d-48ef-a434-16575303752d"
}

To get the job status using the statusURI endpoint, you must specify a valid token in the request header, as described in Authentication Tokens.

CLI Syntax

The following shows the CLI syntax for the run command:

ctm run <jobDefinitionsFile> [deployDescriptorFile]

The following table describes the run command parameters.

Parameter

Description

jobDefinitionsFile

Defines the file or archive that contains code for jobs. Files must be in JSON format.

deployDescriptorFile

(Optional) Defines the file that includes the rules to apply to the original definitions file. The rules enable transforming Control-M JSON code properties. For detailed information, see Deploy Descriptor.

If annotation is enabled for the Scheduling definitions category in Control-M, you must also provide an annotation to justify your action. For more information, see Annotation Input.

REST API Syntax

The following example shows the REST API syntax for the run command in cURL:

Copy
AuthHeader="x-api-key: $token"
# AuthHeader="Authentication: Bearer $token"  #for a session token
curl -H "$AuthHeader" -X POST  -F "jobDefinitionsFile=@examples/AutomationAPISampleFlow.json" -F "deployDescriptorFile=@examples/deployDescriptor.json" "$endpoint/run"

To select the AuthHeader value ("Authentication: Bearer $token" or "x-api-key: $token"), see Authentication Tokens.

run order

The run order command enables you to run deployed jobs on the Control-M environment. The command returns a runId, which you can use to check job status with the run status command.

The following example shows a typical command and response.

Copy
> ctm run order controlm AutomationAPISampleFlow
{
"runId": "e0ddf056-4497-49f7-9d8b-25758b132bd6",
"statusURI": "https://ec2-54-201-124-17.us-west-2.compute.amazonaws.com:8443/automation-api/run/status/e0ddf056-4497-49f7-9d8b-25758b132bd6"
}

To get the job status using the statusURI endpoint, you must specify a valid token in the request header, as described in Authentication Tokens.

CLI Syntax

The following shows the CLI syntax for the run order command:

ctm run order <ctm> <folder> [jobs] [z/OS library] [-f <configuration file>]

The following table describes the run order command parameters.

Parameter

Description

ctm

Defines Control-M/Server name.

folder

Defines the folder name that is ordered.

jobs

(Optional) Defines the jobs that you want to run:

  • For most types of jobs, this parameter is optional. If the parameter is not defined, the default is all jobs in the specified folder. You can define a single job or use the * wildcard to specify multiple jobs.

  • For a z/OS job, specify either a single job or * for all jobs in the folder.

z/OS library

Defines the name of the z/OS library that contains the jobs.

Example: CTMP.V900.SCHEDULE

configuration file

(Optional) Defines the JSON file that contains additional parameters.

If annotation is enabled for the Active network category, you must also provide an annotation to justify your action. For more information, see Annotation Input.

The following table describes the parameters that you can specify in the configuration file:

Parameter

Description

variables

Defines variables for the job run, expressed as name:value pairs.

The variables that you specify can be local, global, or folder variables. Named pool variables are not supported.

For more information, see Variables.

hold

Determines whether to make changes to a job before it starts running.

Valid Values:

  • true

  • false

Default: false

ignoreCriteria

Determines whether to run a job when it is ordered and ignore the scheduling criteria.

Valid Values:

  • true

  • false

Default: true

independentFlow

Determines whether a flow in a folder is ordered uniquely.

This parameter is not applicable to sub-folders.

Valid Values:

  • true

  • false

Default: true

orderDate

Determines the current or future workday to schedule the job. The format is YYYYMMDD.

Default: current

waitForOrderDate

Determines whether to wait for the defined order date to run a job.

Valid Values:

  • true

  • false

Default: false

createDuplicate

Determines whether jobs or sub-folders with the same name that already exist in the folder are added to the SMART folder.

This is relevant when the placeInFolder parameter is set to Recent or to a specific Order ID.

Valid Values:

  • true

  • false

Default: true

placeInFolder

Determines how to order jobs or sub-folders that belong to a SMART Folder. This is a mandatory parameter.

Jobs and sub-folders are added to a SMART Folder according to the Order Into Folder options.

Valid Values:

  • New: Inserts jobs into a new folder.

  • Recent: Inserts jobs into a recent folder.

  • <Folder Order ID>: Inserts jobs into a selected folder.

  • Alone: Inserts jobs into a regular folder.

    The createDuplicate parameter is not relevant for this value.

Default: New

If the job or sub-folder is inserted into an existing folder or sub-folder that is already complete, the status of all parent folders is set to Executing. If it is not possible due to scheduling criteria, the job remains in WAIT_SCHEDULING status.

This parameter is ignored if the folder that is ordered is not a SMART Folder.

The following is an example of a configuration file:

Copy
{
    "variables": [
        {"arg": "1234"},
        {"arg2": "abcd"},
        {"arg3": "0000"}
    ],
    "ignoreCriteria": "true",
    "placeInFolder": "Recent",
    "orderDate": "20170903",
    "waitForOrderDate": "false",
    "hold": "true"
}

REST API Syntax

The following example shows the REST API syntax for the run order command in cURL:

Copy
endpoint=
token=
ctm=
folderName=
AuthHeader="x-api-key: $token"
# AuthHeader="Authentication: Bearer $token"  #for a session token
 
curl -X POST -H "$AuthHeader" --header "Content-Type: application/json" --header "Accept: application/json" -d "{
    \"ctm\": \"$ctm\",
    \"folder\": \"$folderName\",
    \"hold\": \"true\",
    \"ignoreCriteria\": \"true\",
    \"orderDate\": \"20170903\",
    \"waitForOrderDate\": \"false\",
    \"placeInFolder\": \"Recent\",
    \"variables\": [{\"arg\":\"12345\"}]
}" "$endpoint/run/order"

To select the AuthHeader value ("Authentication: Bearer $token" or "x-api-key: $token"), see Authentication Tokens.

The following shows an example for ordering a z/OS job using cURL:

Copy
endpoint=
token=
ctm=M90CTM
folderName=
jobName=IOATEST
library=CTMP.V900.SCHEDULE
AuthHeader="x-api-key: $token"
# AuthHeader="Authentication: Bearer $token"  #for a session token
 
curl -X POST -H "$AuthHeader" --header "Content-Type: application/json" --header "Accept: application/json" -d "{
    \"ctm\": \"$ctm\",
    \"folder\": \"$folderName\",
    \"jobs\": \"$jobName\",
    \"library\": \"$library\",
    \"hold\": \"true\",
    \"ignoreCriteria\": \"true\",
    \"orderDate\": \"20170903\",
    \"waitForOrderDate\": \"false\",
    \"placeInFolder\": \"Recent\",
    \"variables\": [{\"arg\":\"12345\"}]
}" "$endpoint/run/order"

run userDaily:missing::list

The run userDaily:missing::list command enables you to generate a list of jobs that were not ordered because a specific Order Method (a specific User Daily job) was interrupted for various reasons, such as an operating system crash.

This command requires Control-M/EM version 9.0.21.200 or later.

The command returns a poll ID to view the list with the run userDaily:missing::poll command.

The following is an example of a typical command and response:

Copy
> ctm run userDaily:missing::list myUserDaily controlm
{
  "pollId": "f9f9667e-8037-45c9-bd00-36eaa4b812c8",
  "statusURI": "http://localhost:32080/run/orderMethod/myUserDaily/missing/listf9f9667e-8037-45c9-bd00-36eaa4b812c8"
}

You must specify a valid token in the request header to view the list with the statusURI endpoint, as described in Authentication Tokens.

CLI Syntax

The following shows the CLI syntax for the run userDaily:missing::list command:

ctm run userDaily:missing::list <userDaily> <server>

The following table describes the run userDaily:missing::list command parameters.

Parameter

Description

userDaily

Defines the name of the User Daily job.

server

Defines the Control-M/Server name.

REST API Syntax

The following example shows the REST API syntax for the run userDaily:missing::list command in cURL:

Copy
server=controlm
userDaily=myUserDaily
AuthHeader="x-api-key: $token"
# AuthHeader="Authentication: Bearer $token"  #for a session token
curl -H "$AuthHeader" "$endpoint/run/userDaily/$userDaily/missing/list/$server"

To select the AuthHeader value ("Authentication: Bearer $token" or "x-api-key: $token"), see Authentication Tokens.

run userDaily:missing::poll

The run userDaily:missing::poll command enables you to view a previously generated list of jobs that were not ordered because a specific Order Method (a specific User Daily job) was interrupted for various reasons, such as an operating system crash.

This command requires Control-M/EM version 9.0.21.200 or later.

CLI Syntax

The following shows the CLI syntax for the run userDaily:missing::poll command:

ctm run userDaily:missing::poll <pollId>

where <pollID> is the poll ID returned by the run userDaily:missing::list command.

REST API Syntax

The following example shows the REST API syntax for the run userDaily:missing::poll command in cURL:

Copy
AuthHeader="x-api-key: $token"
# AuthHeader="Authentication: Bearer $token"  #for a session token
curl -H "$AuthHeader" "$endpoint/run/userDaily/missing/poll/$pollId"

To select the AuthHeader value ("Authentication: Bearer $token" or "x-api-key: $token"), see Authentication Tokens.

Response

The following example shows a response that lists two unordered jobs and another two unordered jobs that changed after the User Daily job ran:

Copy
{
    "jobs": [
        {
           "folderName": "Folder_1",
           "jobName": "Job_1"
        },
        {
           "folderName": "Folder_2",
           "jobName": "Job_2"
        }
    ],
    "jobsChangedAfterUserDailyRun": [
        {
           "folderName": "Folder_3",
           "jobName": "Job_3"
        },
        {
           "folderName": "Folder_4",
           "jobName": "Job_4"
        }
    ]
}

You can reorder the pending jobs with the run userDaily:missing::poll command.

run userDaily:missing::run

The run userDaily:missing::run command enables you to reorder the jobs that did not run because a specific Order Method (a specific User Daily job) was interrupted for various reasons, such as an operating system crash.

This command requires Control-M/EM version 9.0.21.200 or later.

The command returns a runId to check the job status with the run status command.

The following example is a typical command and response:

> ctm run userDaily:missing::run myUserDaily { "runId": "2143811-e253-4c3f-8c21-72bd7957bb53", "statusURI": "http://localhost:32080/run/status/2143811-e253-4c3f-8c21-72bd7957bb53" }

You must specify a valid token in the request header to get the job status with the statusURI endpoint, as described in Authentication Tokens.

CLI Syntax

The following shows the CLI syntax for the run userDaily:missing::run command:

ctm run userDaily:missing::run <orderMethod>

where <userDaily> is the name of the User Daily job.

If annotation is enabled for the Active network category in Control-M, you must also provide an annotation to justify your action. For more information, see Annotation Input.

REST API Syntax

The following example shows the REST API syntax for the run userDaily:missing::run command in cURL:

Copy
userDaily=myUserDaily
AuthHeader="x-api-key: $token"
# AuthHeader="Authentication: Bearer $token"  #for a session token
curl -X POST -H "$AuthHeader" "$endpoint/run/userDaily/$userDaily/missing/run"

To select the AuthHeader value ("Authentication: Bearer $token" or "x-api-key: $token"), see Authentication Tokens.

run ondemand

The run ondemand command enables you to execute jobs immediately. You do not need to deploy the jobs to the Control-M/EM database and the User Daily job does not need to trigger them. This command is useful for event-driven job executions.

This command requires Control-M/EM version 9.0.21.200 or later.

  • You cannot use the deploy jobs::get command to retrieve details for these jobs since they are not deployed to the database.

  • You cannot schedule these jobs because the User Daily job does not trigger them. The system ignores the scheduling information.

A build process takes place as part of the run.

The response returns a runID and statusURI like the run and run order commands. The runId enables you to check the job status with the run status command.

You must specify a valid token in the request header to get the job status with the statusURI endpoint, as described in Authentication Tokens.

CLI Syntax

The following shows the CLI syntax for the run ondemand command:

ctm run ondemand <definitionsFile> [deployDescriptorFile]

The following table describes the run ondemand command parameters.

Parameter

Description

jobDefinitionsFile

Defines the file or archive that contains code for folders and jobs. Files must be in JSON format.

The system only processes Job, Folder, and Defaults objects in the definitions file. The system ignores other object types, such as connection profiles or Site Standards, and scheduling properties.

deployDescriptorFile

(Optional) Defines the file that includes the rules applied to the original definitions file. The rules enable you to transform Control-M JSON code properties. For detailed information, see Deploy Descriptor.

REST API Syntax

The following example shows the REST API syntax for the run ondemand command in cURL:

Copy
AuthHeader="x-api-key: $token"
# AuthHeader="Authentication: Bearer $token"  #for a session token
curl -H "$AuthHeader" -X POST  -F "definitionsFile=@definitions.json" -F "deployDescriptorFile=@deployDescriptor.json" "$endpoint/run/ondemand"

To select the AuthHeader value ("Authentication: Bearer $token" or "x-api-key: $token"), see Authentication Tokens.

run status

The run status command enables you to track the status of running jobs. The command shows how to check the job status with the runId.

CLI Syntax

The following shows the CLI syntax for the run status command:

ctm run status <runId> [startIndex]

The following table describes the run status command parameters.

Parameter

Description

runId

Defines the value returned in a run invocation. It enables job tracking during a specific run invoked by the same user.

startIndex

(Optional) Defines iterations over every status. The result includes itemsPerPage: 25 items from this index.

Default: 0

REST API Syntax

The following example shows the REST API syntax for the run status command in cURL:

Copy
AuthHeader="x-api-key: $token"
# AuthHeader="Authentication: Bearer $token"  #for a session token
 
curl -H "$AuthHeader" "$endpoint/run/status/$runId"

To select the AuthHeader value ("Authentication: Bearer $token" or "x-api-key: $token"), see Authentication Tokens.

Response

The following example shows the parameters in the run status response.

The system checks and returns the status of each job when there is more than one job in the flow.

Copy
> ctm run status "2d4af716-e31d-48ef-a434-16575303752d"
{
    "completion": "Completed",
    "statuses": [
        {
            "jobId": "controlm:00fhb",
            "folderId": "controlm:005gy",
            "numberOfRuns": 3,
            "name": "AutomationAPISampleFlow",
            "type": "Folder",
            "status": "Executing",
            "held": "false",
            "deleted": "false",
            "cyclic": "false",
            "startTime": "May 18, 2018 11:57:26 AM",
            "endTime": "",
            "estimatedStartTime": [
                "20180518121500,",
                "20180518123000,"],
            "estimatedEndTime": [
                "20180518121502,",
                "20180518123005,"],
            "outputURI": "Folder has no output"
        },
        {
            "jobId": "controlm:00fhc",
            "folderId": "controlm:005gy",
            "numberOfRuns": 3,
            "name": "AutomationAPISampleFlow/CommandJob",
            "type": "Command",
            "status": "Wait Host",
            "held": "false",
            "deleted": "false",
            "cyclic": "false",
            "startTime": "",
            "endTime": "",
            "estimatedStartTime": [],
            "estimatedEndTime": [],
            "outputURI": "Job didn't run, it has no output"
        },
        {
            "jobId": "controlm:00fhd",
            "folderId": "controlm:005gy",
            "numberOfRuns": 3,
            "name": "AutomationAPISampleFlow/ScriptJob",
            "type": "Job",
            "status": "Wait Condition",
            "held": "false",
            "deleted": "false",
            "cyclic": "false",
            "startTime": "",
            "endTime": "",
            "estimatedStartTime": [],
            "estimatedEndTime": [],
            "outputURI": "Job didn't run, it has no output"
        }
    ],
    "startIndex": 0,
    "itemsPerPage": 25
}

The following table describes additional run status command parameters.

Parameter

Description

completion

Determines whether the job ran.

Valid Values:

  • Completed

  • Pending

If the value is Pending, you can run the run status command again until the value changes to Completed.

jobId

Defines a unique identifier to reference a specific job. The jobId is returned by the following command:

ctm run status

Format: <server>:<orderId>

folderId

Defines the folderId to reference a specific folder.

numberOfRuns

Determines the number of job runs.

name

Defines the name of a job.

type

Determines the job type.

status

Defines the job status.

held

Determines whether the job was held.

Valid Values:

  • true

  • false

deleted

Determines whether the job was deleted.

Valid Values:

  • true

  • false

cyclic

Determines whether the job is defined as a cyclic job.

Valid Values:

  • true

  • false

startTime

Defines the time when the job started.

endTime

Defines the time when the job ended.

estimatedStartTime

Defines the estimated date and time when the next job runs are expected to begin. The estimates are based on the run times of previous jobs.

The maximum number of job runs is 50.

You must have SLA Management installed in your environment.

estimatedEndTime

Defines the estimated date and time when the next job runs are expected to end. The estimates are based on the run times of previous job runs.

The maximum number of job runs is 50.

You must have SLA Management installed in your environment.

outputURI

Defines the URI for the job output.

You must specify a valid token in the request header to get the job output with the outputURI endpoint, as described in Authentication Tokens.

run jobs:status::get

The run jobs:status::get command enables you to track running jobs that match a search query.

CLI Syntax

The following shows the CLI syntax for the run jobs:status::get command:

ctm run jobs:status::get [limit] -s "<query string>"

where -s is used to run a search with the query string format "field1=criteria1&field2=criteria2".

The following table describes the run jobs:status::get command parameters.

Parameter

Description

limit

Determines the maximum number of job statuses to return.

Valid values: 1–10000

Default: 1000

The following table describes the query fields that you can use with -s.

Field

Criteria

Query Examples

  • jobname

  • jobid (Format: <server>:<orderId>)

  • folder

  • folderLibrary

  • server (previously named ctm (deprecated name))

  • application

  • subApplication

  • host

  • hostGroup

  • description

  • runAs

  • command

  • filePath

  • fileName

  • workloadPolicy

  • ruleBasedCalender

  • resourceLock

  • resourcePool

  • Supported wildcards are *and ?.

  • Multiple criteria are separated with a comma.

  • Wildcards are not supported for jobid.

jobname=job1122

jobname=job11*

jobname=job11*,job77*

description=*a job that*

jobid=controlm:005gy

 

  • orderDateFrom

  • orderDateTo

  • fromTime

  • toTime

  • For orderDateFrom and orderDateTo: YYMMDD.

  • For fromTime and toTime: YYYYMMDDhhmmss.

orderDateFrom=180123

fromTime=20180123184500

historyRunDate

  • A single date when jobs started running in one of the following formats:

    • YYMMDD

    • YYYYMMDD

  • Yesterday

historyRunDate=231127

historyRunDate=Yesterday

status

  • Ended OK.

  • Ended Not OK.

  • Wait User.

  • Wait Resource.

  • Wait Host.

  • Wait Workload.

  • Wait Condition.

  • Executing

  • Status Unknown.

To use multiple criteria, separate criteria with commas.

status=Ended OK

status=Ended OK, Ended Not OK,Executing

  • held

  • (MVS only) folderHeld

  • cyclic

  • deleted

true | false

"held=true&folderHeld=true
&cyclic=false&deleted=false"

neighborhood

Returns the status according to the dependencies between jobs. The Flow object enables you to create dependencies between jobs.

  • direction: The following list describes the possible values:

    • depend: The jobs that depend on the specified job.

    • predecessor: The jobs that the specified job depends on.

    • radial: The jobs from both directions.

  • depth: The number of job levels from the specified job.

"neighborhood&jobid=ctm:0a98
&depth=1&direction=predecessor"

The following example shows a command to get job statuses with a search query:

Copy
ctm run jobs:status::get -s "jobname=Finance*&application=app1,app2&status=Ended OK,Ended Not OK,Executing

The following example shows a command to get job statuses of a job that has linked jobs:

Copy
ctm run jobs:status::get -s "neighborhood&jobid=controlm:0a98&depth=1&direction=predecessor"

REST API Syntax

The following example shows the REST API syntax for the run jobs:status::get command that includes a limit in cURL:

Copy
AuthHeader="x-api-key: $token"
# AuthHeader="Authentication: Bearer $token"  #for a session token

curl -H "$AuthHeader" "$endpoint/run/jobs/status?jobname=jobA&status=Ended%20OK&application=A*&limit=5000"

To select the AuthHeader value ("Authentication: Bearer $token" or "x-api-key: $token"), see Authentication Tokens.

Response

The following example shows the parameters for one of the jobs returned in the response to the run jobs:status::get command.

Copy
{
    "jobId": "LocalControlM:00008",
    "folderId": "LocalControlM:00007",
    "numberOfRuns": 0,
    "name": "job1",
    "folder": "SanityCommandOk",
    "type": "Command",
    "status": "Wait Condition",
    "held": true,
    "deleted": false,
    "cyclic": "false",
    "startTime": "20231126065554",
    "endTime": "20231126065555",
    "estimatedStartTime": ["20231126123810"],
    "estimatedEndTime": ["20231126124310"],
    "orderDate": "231125",
    "ctm": "LocalControlM",
    "description": "",
    "host": "",
    "application": "OsApp",
    "subApplication": "",
    "outputURI": "Job did not run, it has no output",
    "logURI": "http://localhost:48080/run/job/LocalControlM:00008/log"
}

The following table describes the parameters in this sample response:

Parameter

Description

jobId

Defines a unique identifier to reference a specific job. The jobId is returned by the following command:

ctm run status

Format: <server>:<orderId>

folderId

Defines a unique identifier of the folder with the job.

Format: <server>:<orderId>

numberOfRuns

Defines the number of job runs.

name

Defines the name of the job.

folder

Defines the name of the folder with the job.

type

Defines a job type.

status

Determines the job status.

Valid Values:

  • Ended OK.

  • Ended Not OK.

  • Wait User.

  • Wait Resource.

  • Wait Host.

  • Wait Workload.

  • Wait Condition.

  • Executing

  • Status Unknown.

held

Determines whether the job was held.

Valid Values:

  • true

  • false

deleted

Determines whether the job was deleted.

Valid Values:

  • true

  • false

cyclic

Determines whether the job is defined as a cyclic job.

Valid Values:

  • true

  • false

startTime

Defines the time when the job started.

endTime

Defines the time when the job ended.

estimatedStartTime

Defines the estimated date and time when the next job runs are expected to begin. The estimates are based on the run times of previous jobs.

The maximum number of job runs is 50.

You must have SLA Management installed in your environment.

estimatedEndTime

Defines the estimated date and time when the next job runs are expected to end. The estimates are based on the run times of previous jobs.

The maximum number of job runs is 50.

You must have SLA Management installed in your environment.

orderDate

Defines the scheduled workday for the job in YYMMDD format.

ctm

Defines the Control-M/Server name.

description

Defines a text-based description of the job, as defined during job creation.

host

Defines the host of the Agent where the job is running.

application

Defines the name of an application associated with the job. An application is a logical set of related jobs.

subApplication

Defines the name of a sub-application associated with the job. A sub-application is a logical sub-category of an application.

A group of payroll-related jobs are logically grouped together in a sub-application named Payroll, within an application named Finances.

outputURI

Defines the URI to the job output.

You must specify a valid token in the request header to get the job output with the outputURI endpoint, as described in Authentication Tokens.

logURI

Defines the URI to the job log.

You must specify a valid token in the request header to get the job log with the logURI endpoint, as described in Authentication Tokens.

run job:output::get

The run jobs:output::get command enables you to view the output from job runs.

CLI Syntax

The following shows the CLI syntax for the run jobs:output::get command:

ctm run job:output::get <jobId> [runNo]

The following table describes the run job:output::get command parameters.

Parameter

Description

jobId

Defines a unique identifier to reference a specific job. The jobId is returned by the following command:

ctm run status

Format: <server>:<orderId>.

runNo

(Optional) Defines the run number of the job to get the output.

If the run number is not defined, the default is the last run.

If annotation is enabled for the AJF get job information category in Control-M, you must also provide an annotation to justify your action. For more information, see Annotation Input.

REST API Syntax

The following example shows the REST API syntax for the run jobs:output::get command in cURL:

Copy
AuthHeader="x-api-key: $token"
# AuthHeader="Authentication: Bearer $token"  #for a session token

curl -H "$AuthHeader" "$endpoint/run/job/$jobId/output?runNo=0"

To select the AuthHeader value ("Authentication: Bearer $token" or "x-api-key: $token"), see Authentication Tokens.

run job:log::get

The run job:log::get command enables you to access the job log.

CLI Syntax

The following shows the CLI syntax for the run job:log::get command:

ctm run job:log::get <jobId>

where <jobId> is a unique identifier to reference the specific job. The jobId is returned by the following command:

ctm run status

The format of this ID is <server>:<orderId>.

If annotation is enabled for the AJF get job information category in Control-M, you must also provide an annotation to justify your action. For more information, see Annotation Input.

REST API Syntax

The following example shows the REST API syntax for the run job:log::get command in cURL:

Copy
AuthHeader="x-api-key: $token"
# AuthHeader="Authentication: Bearer $token"  #for a session token

curl -H "$AuthHeader" "$endpoint/run/job/$jobId/log"

To select the AuthHeader value ("Authentication: Bearer $token" or "x-api-key: $token"), see Authentication Tokens.

run job:status::get

The run job:status::get command enables you to view a specific job run status.

CLI Syntax

The following shows the CLI syntax for the run job:status::getcommand:

ctm run job:status::get <jobId>

where <jobId> is a unique identifier to reference the specific job. The jobId is returned by the following command:

ctm run status

The format of this ID is <server>:<orderId>.

For information about the response to this API command and descriptions of the job properties in this response, see the description of the run jobs:status::get response.

REST API Syntax

The following example shows the REST API syntax for the run job:status::get command in cURL:

Copy
AuthHeader="x-api-key: $token"
# AuthHeader="Authentication: Bearer $token"  #for a session token

curl -H "$AuthHeader" "$endpoint/run/job/$jobId/status"

To select the AuthHeader value ("Authentication: Bearer $token" or "x-api-key: $token"), see Authentication Tokens.

run job:statistics::get

The run job:statistics::get command enables you to get time statistics for the recent runs of a job.

CLI Syntax

The following shows the CLI syntax for the run job:statistics::get command:

ctm run job:statistics::get <jobId>

where <jobId> is a unique identifier to reference the specific job. The jobId is returned by the following command:

ctm run status

The format of this ID is <server>:<orderId>.

Response

The response provides the following time statistics for each job run:

  • Order date

  • Start and end time

  • Run time

  • CPU time

  • Average of the key time statistics from all runs

If the system collects periodic statistics for this job, it presents job run statistics separately for each period.

The jobId returned for each job run is a unique serial number assigned to the job run by the Control-M/Server. It differs from the jobId specified in the input.

The following is a response example with data from two job runs. There are no periods defined for data collection from the job in this example.

Copy
{
  "periods": [
    {
      "runInfo": {
        "averageInfo": {
          "startTime": "07:35:53",
          "cpuTime": "00:00:00",
          "runTime": "00:00:01"
        },
        "runs": [
          {
            "startTime": "06/02/2020 07:39:00",
            "endTime": "06/02/2020 07:39:00",
            "cpuTime": "00:00:00",
            "runTime": "00:00:01",
            "jobId": "75",
            "orderDate": "06/02/2020"
          },
          {
            "startTime": "06/02/2020 07:38:00",
            "endTime": "06/02/2020 07:38:00",
            "cpuTime": "00:00:00",
            "runTime": "00:00:01",
            "jobId": "2",
            "orderDate": "06/02/2020"
          }
        ]
      }
    }
  ]
}

REST API Syntax

The following example shows the REST API syntax for the run job:statistics::get command in cURL:

Copy
AuthHeader="x-api-key: $token"
# AuthHeader="Authentication: Bearer $token"  #for a session token

curl -H "$AuthHeader" "$endpoint/run/job/$jobId/statistics"

To select the AuthHeader value ("Authentication: Bearer $token" or "x-api-key: $token"), see Authentication Tokens.

run job::kill

The run job::kill command enables you to terminate the job.

CLI Syntax

The following shows the CLI syntax for the run job::kill command:

ctm run job::kill <jobId>

where <jobId> is a unique identifier to reference the specific job. The jobId is returned by the following command:

ctm run status

The format of this ID is <server>:<orderId>.

If annotation is enabled for the Active network category in Control-M, you must also provide an annotation to justify your action. For more information, see Annotation Input.

REST API Syntax

The following example shows the REST API syntax for the run job::kill command in cURL:

Copy
AuthHeader="x-api-key: $token"
# AuthHeader="Authentication: Bearer $token"  #for a session token

curl -H "$AuthHeader" -X POST "$endpoint/run/job/$jobId/kill"

To select the AuthHeader value ("Authentication: Bearer $token" or "x-api-key: $token"), see Authentication Tokens.

run job::runNow

The run job::runNow command enables you to immediately start the job. The system does not apply job constraints when you use this command.

CLI Syntax

The following shows the CLI syntax for the run job::runNow command:

ctm run job::runNow <jobId>

where <jobId> is a unique identifier to reference the specific job. The jobId is returned by the following command:

ctm run status

The format of this ID is <server>:<orderId>.

If annotation is enabled for the Active network category in Control-M, you must also provide an annotation to justify your action. For more information, see Annotation Input.

REST API Syntax

The following example shows the REST API syntax for the run job::runNow command in cURL:

Copy
AuthHeader="x-api-key: $token"
# AuthHeader="Authentication: Bearer $token"  #for a session token

curl -H "$AuthHeader" -X POST "$endpoint/run/job/$jobId/runNow"

To select the AuthHeader value ("Authentication: Bearer $token" or "x-api-key: $token"), see Authentication Tokens.

run job::hold

The run job::hold command enables you to hold the job and stop processing it.

CLI Syntax

The following shows the CLI syntax for the run job::hold command:

ctm run job::hold <jobId>

where <jobId> is a unique identifier to reference the specific job. The jobId is returned by the following command:

ctm run status

The format of this ID is <server>:<orderId>.

If annotation is enabled for the Active network category in Control-M, you must also provide an annotation to justify your action. For more information, see Annotation Input.

REST API Syntax

The following example shows the REST API syntax for the run job::hold command in cURL:

Copy
AuthHeader="x-api-key: $token"
# AuthHeader="Authentication: Bearer $token"  #for a session token

curl -H "$AuthHeader" -X POST "$endpoint/run/job/$jobId/hold"

To select the AuthHeader value ("Authentication: Bearer $token" or "x-api-key: $token"), see Authentication Tokens.

run job::free

The run job::free command enables you to continue the job run from the hold state.

CLI Syntax

The following shows the CLI syntax for the run job::free command:

ctm run job::free <jobId>

where <jobId> is a unique identifier to reference the specific job. The jobId is returned by the following command:

ctm run status

The format of this ID is <server>:<orderId>.

If annotation is enabled for the Active network category in Control-M, you must also provide an annotation to justify your action. For more information,see Annotation Input.

REST API Syntax

The following example shows the REST API syntax for the run job::free command in cURL:

Copy
AuthHeader="x-api-key: $token"
# AuthHeader="Authentication: Bearer $token"  #for a session token

curl -H "$AuthHeader" -X POST "$endpoint/run/job/$jobId/free"

To select the AuthHeader value ("Authentication: Bearer $token" or "x-api-key: $token"), see Authentication Tokens.

run job::delete

The run job::delete command enables you to mark the job for deletion. The system deletes the job on the next scheduled date.

CLI Syntax

The following shows the CLI syntax for the run job::delete command:

ctm run job::delete <jobId>

where <jobId> is a unique identifier to reference the specific job. The jobId is returned by the following command:

ctm run status

The format of this ID is <server>:<orderId>.

If annotation is enabled for the Active network category in Control-M, you must also provide an annotation to justify your action. For more information, see Annotation Input.

REST API Syntax

The following example shows the REST API syntax for the run job::delete command in cURL:

Copy
AuthHeader="x-api-key: $token"
# AuthHeader="Authentication: Bearer $token"  #for a session token

curl -H "$AuthHeader" -X POST "$endpoint/run/job/$jobId/delete"

To select the AuthHeader value ("Authentication: Bearer $token" or "x-api-key: $token"), see Authentication Tokens.

run job::undelete

The run job::undelete command enables you to remove a deletion mark from a job.

CLI Syntax

The following shows the CLI syntax for the run job::undelete command:

ctm run job::undelete <jobId>

where <jobId> is a unique identifier to reference the specific job. The jobId is returned by the following command:

ctm run status

The format of this ID is <server>:<orderId>.

If annotation is enabled for the Active network category in Control-M, you must also provide an annotation to justify your action. For more information, see Annotation Input.

REST API Syntax

The following example shows the REST API syntax for the run job::undelete command in cURL:

Copy
AuthHeader="x-api-key: $token"
# AuthHeader="Authentication: Bearer $token"  #for a session token

curl -H "$AuthHeader" -X POST "$endpoint/run/job/$jobId/undelete"

To select the AuthHeader value ("Authentication: Bearer $token" or "x-api-key: $token"), see Authentication Tokens.

run job::confirm

The run job::confirm command enables you to run a job that is waiting for confirmation.

CLI Syntax

The following shows the CLI syntax for the run job::confirm command:

ctm run job::confirm <jobId>

where <jobId> is a unique identifier to reference the specific job. The jobId is returned by the following command:

ctm run status

The format of this ID is <server>:<orderId>.

If annotation is enabled for the Active network category in Control-M, you must also provide an annotation to justify your action. For more information, see Annotation Input.

REST API Syntax

The following example shows the REST API syntax for the run job::confirm command in cURL:

Copy
AuthHeader="x-api-key: $token"
# AuthHeader="Authentication: Bearer $token"  #for a session token

curl -H "$AuthHeader" -X POST "$endpoint/run/job/$jobId/confirm"

To select the AuthHeader value ("Authentication: Bearer $token" or "x-api-key: $token"), see Authentication Tokens.

run job::setToOk

The run job::setToOk command enables you to set job status to OK after the job is processed. You can use this command, for example, after you resolve issues that cause a job to end in status Not OK.

CLI Syntax

The following shows the CLI syntax for the run job::setToOk command:

ctm run job::setToOk <jobId>

where <jobId> is a unique identifier to reference the specific job. The jobId is returned by the following command:

ctm run status

The format of this ID is <server>:<orderId>.

If annotation is enabled for the Active network category in Control-M, you must also provide an annotation to justify your action. For more information, see Annotation Input.

REST API Syntax

The following example shows the REST API syntax for the run job::setToOk command in cURL:

Copy
AuthHeader="x-api-key: $token"
# AuthHeader="Authentication: Bearer $token"  #for a session token

curl -H "$AuthHeader" -X POST "$endpoint/run/job/$jobId/setToOk"

To select the AuthHeader value ("Authentication: Bearer $token" or "x-api-key: $token"), see Authentication Tokens.

run job::rerun

The run job::rerun command enables you to rerun a job that it is not currently in execution. The system applies existing job constraints when you use this command.

CLI Syntax

The following shows the CLI syntax for the run job::rerun command:

ctm run job::rerun <jobId> [-f zosJobConfig.json]

The following table describes the run job::rerun command parameters.

Parameter

Description

jobId

Defines a unique identifier to reference the specific job. The jobId is returned by the following command:

ctm run status

Format: <server>:<orderId>

zosJobConfig

Optional for z/OS job only: Defines the full path and name of a JSON file that contains advanced restart parameters for Control-M/Restart.

To rerun a z/OS job, the job must be in one of the following statuses:

  • Ended OK

  • Ended Not OK

  • Wait User (which corresponds to Wait Confirmation in Control-M for z/OS)

If annotation is enabled for the Active network category in Control-M, you must also provide an annotation to justify your action. For more information, see Annotation Input.

If you are rerunning a z/OS job, you can specify additional parameters in the configuration file:

Copy
{
  "zosParameters": {
    "from": {
      "pgm": "INPROCS2",
      "proc": "STEP1"
    },
    "to": {
      "pgm": "INPROCS3",
      "proc": "STEP2"
    },
    "cleanup": true,
    "recaptureAbend": "Y",
    "recaptureConditionCode": "N",
    "stepAdjustment": true,
    "restartParmMemberName": "IDJOB5"
  }
}

The following table describes the advanced parameters in the configuration file for a z/OS job:

Parameter

Description

from, to

Defines the parameters to limit job rerun to a range of steps.

If you want to define the starting point (under from) and the end point (under to), specify the program step (pgm) and (optionally) the procedure step (proc) at both points.

If you want to obtain a list of program steps, run the run job:output::get API command. The returned output includes a list of executed job steps that completed successfully and those that failed.

The following example shows how to restart from STEP2 until STEP3 with the from and to parameters in the configuration file:

Copy
"from": {
    "pgm": "STEP2",
    "proc": ""
},
"to": {
    "pgm": "STEP3",
    "proc": ""
},

The following shows the corresponding JCL in z/OS:

Copy
//M99#STEP JOB (EE00,111,30),NOTIFY=&SYSUID,MSGCLASS=X 
//*                                                         
//STEP1   EXEC  PGM=IOATEST,PARM='WAIT=1'                   
//STEP2   EXEC  PGM=IOATEST,PARM='WAIT=1'                   
//STEP3   EXEC  PGM=IOATEST,PARM='WAIT=1'                   
//*

In other Control-M products, the steps in the sample JCL appear, as follows:

Copy
Num Pgm-stp  Proc-stp  Pgm=      Comp
001 STEP1              IOATEST   0000
002 STEP2              IOATEST   0004
003 STEP3              IOATEST   0000

Only the steps in rows 002-003 are restarted.

The following example shows how to restart from INPROCS2 of STEP1 until INPROCS3 of STEP2 with the from and to parameters in the configuration file:

Copy
"from": {
    "pgm": "INPROCS2",
    "proc": "STEP1"
},
"to": {
    "pgm": "INPROCS3",
    "proc": "STEP2"
},

The following shows the corresponding JCL in z/OS:

Copy
//M99#PROC JOB (EE00,111,30),EDUC,NOTIFY=&SYSUID,MSGCLASS=X  
//*                                                          
//SAMPPROC PROC                                              
//INPROCS1  EXEC PGM=IOATEST                                  
//INPROCS2  EXEC PGM=IOATEST                                  
//INPROCS3  EXEC PGM=IOATEST                                  
//         PEND                                              
//*                                                          
//STEP1   EXEC  SAMPPROC                                      
//STEP2   EXEC  SAMPPROC                                      
//STEP3   EXEC  SAMPPROC                                      
//*

In other Control-M products, the steps in the sample JCL appear, as follows:

Copy
Num Pgm-stp  Proc-stp  Pgm=      Comp
001 INPROCS1 STEP1     IOATEST   0000
002 INPROCS2 STEP1     IOATEST   0004
003 INPROCS3 STEP1     IOATEST   0000
004 INPROCS1 STEP2     IOATEST   0000
005 INPROCS2 STEP2     IOATEST   0000
006 INPROCS3 STEP2     IOATEST   0000
007 INPROCS1 STEP3     IOATEST   0000
008 INPROCS2 STEP3     IOATEST   0000
009 INPROCS3 STEP3     IOATEST   0000

Only the steps in rows 002-006 are restarted.

Note the following scenarios:

  • Rerun a single step: Specify the same program step and procedure step under both from and to.

  • Specify a starting point without an end point: Verify that the range extends to the end of the job.

  • Rerun the whole job: Utilize empty values for pgm and proc under both from and to.

  • Restart from the step that failed in the previous run: Specify "pgm": "$EXERR" under from. If there is no such step, the job restarts from the beginning. For this option, ensure that you have Control-M for z/OS version 9.0.21.200 or later, or that you applied APAR WW10041.

cleanup

Determines whether to perform data set cleanup.

Valid values:

  • true

  • false

If you set this parameter to true, all other parameters described here are not relevant and should NOT be included in the configuration file.

recaptureAbend

Determines whether to save the abend codes from the original job execution.

Valid values:

  • Y: Yes, save abend codes.

  • N: No, do not save abend codes.

  • R: Reset abend codes.

Default: Y

recaptureConditionCode

Determines whether to save the condition codes from the original job execution.

Valid values:

  • Y: Yes, save condition codes.

  • N: No, do not save condition codes.

  • R: Reset condition codes.

Default: Y

stepAdjustment

Determines whether to enable automatic Step Adjustment.

Valid values:

  • true

  • false

Default: true

For more details about Step Adjustment, see the Control-M/Restart User Guide.

restartParmMemberName

Defines the name of the member that contains control parameters for the job to restart. The name must be 1-8 characters only.

The default value is the member that contains the JCL of the Job.

REST API Syntax

The following example shows the REST API syntax for the run job::rerun command in cURL:

Copy
AuthHeader="x-api-key: $token"
# AuthHeader="Authentication: Bearer $token"  #for a session token

curl -H "$AuthHeader" -X POST "$endpoint/run/job/$jobId/rerun"

To select the AuthHeader value ("Authentication: Bearer $token" or "x-api-key: $token"), see Authentication Tokens.

For a z/OS job, include the advanced parameters described above in the body of the REST request, using the -d (or --data) option.

run job::waitingInfo

The run job::waitingInfo command enables you to display the reasons why a waiting job was not yet executed (for example: missing conditions, resources, hosts, users, or workloads).

CLI Syntax

The following shows the CLI syntax for the run job::waitingInfo command:

ctm run job::waitingInfo <jobId>

where <jobId> is a unique identifier to reference the specific job. The jobId is returned by the following command:

ctm run status

The format of this ID is <server>:<orderId>.

REST API Syntax

The following example shows the REST API syntax for the run job::waitingInfo command in cURL:

Copy
AuthHeader="x-api-key: $token"
# AuthHeader="Authentication: Bearer $token"  #for a session token

curl -H "$AuthHeader" "$endpoint/run/job/$jobId/waitingInfo"

To select the AuthHeader value ("Authentication: Bearer $token" or "x-api-key: $token"), see Authentication Tokens.

run job::get

The run job::get command enables you to return the definitions of a running job in JSON format.

For a description of the returned job format, see Code Reference.

CLI Syntax

The following shows the CLI syntax for the run job::get command:

ctm run job::get <jobId>

where <jobId> is a unique identifier to reference the specific job. The jobId is returned by the following command:

ctm run status

The format of this ID is <server>:<orderId>.

If annotation is enabled for the Active network category in Control-M, you must also provide an annotation to justify your action. For more information, see Annotation Input.

REST API Syntax

The following example shows the REST API syntax for the run job::get command in cURL:

Copy
AuthHeader="x-api-key: $token"
# AuthHeader="Authentication: Bearer $token"  #for a session token

curl -H "$AuthHeader" -X GET "$endpoint/run/job/$jobId/get"

To select the AuthHeader value ("Authentication: Bearer $token" or "x-api-key: $token"), see Authentication Tokens.

run job::modify

The run job::modify command enables you to modify the definitions of a running job that is currently held and the processing is stopped, based on job definitions in a Job Definitions file.

Currently, you can modify the following types of running jobs:

  • Command

  • Script

  • EmbeddedScript

  • FileTransfer

  • Informatica

CLI Syntax

The following shows the CLI syntax for the run job::modify command:

ctm run job::modify <jobDefinitionsFile> <jobId>

The following table describes the run job::modify command parameters.

Parameter

Description

jobDefinitionsFile

Defines a JSON file that contains the details of a single job with the properties that you want to modify.

For a description of the syntax of the JSON code in this file, see Code Reference and all its child pages. Note that this JSON file contains details of only a single job. Do not include other object types, such as a folder or connection profile, in this JSON file.

The following Job Properties currently do NOT support the Modify action:

  • Host

  • RerunSpecificTimes

  • RunAsDummy

  • RetroactiveOrder

In addition, under the When parameter, only FromTime and ToTime support the Modify action.

jobId

Defines a unique identifier to reference the specific job. The jobId is returned by the following command:

ctm run status

The format of this ID is <server>:<orderId>.

If annotation is enabled for the Active network category in Control-M, you must also provide an annotation to justify your action. For more information, see Annotation Input.

REST API Syntax

The following example shows the REST API syntax for the run job::modify command in cURL:

Copy
AuthHeader="x-api-key: $token"
# AuthHeader="Authentication: Bearer $token"  #for a session token

curl -H "$AuthHeader" -X POST -F "jobDefinitionsFile=@examples/InformaticaJob.json" "$endpoint/run/job/$jobId/modify"

To select the AuthHeader value ("Authentication: Bearer $token" or "x-api-key: $token"), see Authentication Tokens.

Resource Management

A Resource Pool is represented by the name of a resource and the maximum amount of that resource which jobs can use. Jobs that require a Resource Pool cannot run unless there are enough resources available.

The following API commands enable you to manage Resource Pools:

run resource::add

The run resource::add command enables you to add a Resource Pool to a Control-M/Server.

CLI Syntax

The following shows the CLI syntax for the run resource::add command:

ctm run resource::add <server> <name> <max>

The following table describes the run resource::add command parameters.

Parameter

Description

server

Defines the Control-M/Server name.

name

Defines the resource.

The maximum number of characters is 2,048 characters.

max

Determines the maximum quantity of resources available.

Valid values: 0-9999

If annotation is enabled for the Independent AJF entities category in Control-M, you must also provide an annotation to justify your action. For more information, see Annotation Input.

REST API Syntax

The following example shows the REST API syntax for the run resource::add command in cURL:

Copy
server=controlm
AuthHeader="x-api-key: $token"
# AuthHeader="Authentication: Bearer $token"  #for a session token

curl -H "$AuthHeader" -H "Content-Type: application/json" -X POST -d "{\"name\": \"newResource\",
\"max\":5}" "$endpoint/run/resource/$server"

To select the AuthHeader value ("Authentication: Bearer $token" or "x-api-key: $token"), see Authentication Tokens.

run resource::delete

The run resource::delete command enables you to delete a Resource Pool.

CLI Syntax

The following shows the CLI syntax for the run resource::delete command:

ctm run resource::delete <server> <name>

The following table describes the run resource::delete command parameters.

Parameter

Description

server

Defines the Control-M/Server name.

name

Defines the resource name.

The maximum number of characters is 2,048.

If annotation is enabled for the Independent AJF entities category in Control-M, you must also provide an annotation to justify your action. For more information, see Annotation Input.

REST API Syntax

The following example shows the REST API syntax for the run resource::delete command in cURL:

Copy
server=controlm
name=newResource
AuthHeader="x-api-key: $token"
# AuthHeader="Authentication: Bearer $token"  #for a session token

curl -H "$AuthHeader" -X DELETE "$endpoint/run/resource/$server/$name"

To select the AuthHeader value ("Authentication: Bearer $token" or "x-api-key: $token"), see Authentication Tokens.

run resource::update

The run resource::update command enables you to update the values of a Resource Pool.

CLI Syntax

The following shows the CLI syntax for the run resource::update command:

ctm run resource::update <server> <name> <max>

The following table describes the run resource::update command parameters.

Parameter

Description

server

Defines the Control-M/Server name.

name

Defines the resource name.

The maximum number of characters is 2,048.

max

Defines the maximum quantity of resources available.

Valid values: 0-9999

If annotation is enabled for the Independent AJF entities category in Control-M, you must also provide an annotation to justify your action. For more information, see Annotation Input.

REST API Syntax

The following example shows the REST API syntax for the run resource::update command in cURL:

Copy
server=controlm
name=newResource
AuthHeader="x-api-key: $token"
# AuthHeader="Authentication: Bearer $token"  #for a session token

curl -H "$AuthHeader" -H "Content-Type: application/json" -X POST -d "{\"max\":6}" "$endpoint/run/resource/$server/$name"

To select the AuthHeader value ("Authentication: Bearer $token" or "x-api-key: $token"), see Authentication Tokens.

run resources::get

The run resources::get command enables you to get all resource records from a specific Control-M/Server.

CLI Syntax

The following shows the CLI syntax for the run resource::update command:

ctm run resources::get -s [search query]

where -s runs a search with the query string format "field1=criteria1&field2=criteria2".

Criteria may contain a * for wildcard matching and comma separator to specify multiple values.

The following table describes the run resources::get command parameters.

Field

Description

server

Defines the Control-M/Server name.

This field was previously named ctm (deprecated name).

name

The resource name.

The maximum number of characters is 2,048 characters.

The following are search examples:

Copy
-s "name=resourceA"
-s "name=A*"
-s "server=controlm*&name=resourceA,resourceB"

Response

The following example shows the parameters in the ctm run resources::get response:

Copy
[
  {
    "name": "newResource",
    "ctm": "controlm",
    "available": "15",
    "max": 15,
    "workloadPolicy": "N/A"
  },
  {
    "name": "myRes",
    "ctm": "controlm",
    "available": "4",
    "max": 4,
    "workloadPolicy": "N/A"
  },

The following table describes additional run resources::get parameters for the response.

Parameter

Description

ctm

Defines the Control-M/Server name.

name

Defines the resource name.

The maximum number of characters is 2,048 characters.

available

Defines the number of resources available.

max

Defines the maximum number of resources available.

workloadPolicy

Defines the name of the workload policy that is linked to the resource. N/A indicates that the resource is not linked to a workload policy. For more information about workload policies, see Workload Policy Definition.

REST API Syntax

The following example shows the REST API syntax for the run resources::get command in cURL:

Copy
search_criteria="name=A*&server=*"
AuthHeader="x-api-key: $token"
# AuthHeader="Authentication: Bearer $token"  #for a session token

curl -H "$AuthHeader" -X GET "$endpoint/run/resources?$search_criteria"

To select the AuthHeader value ("Authentication: Bearer $token" or "x-api-key: $token"), see Authentication Tokens.

Event Management

An event is represented by a name and a date. Jobs that require an event cannot run unless the specific event exists, as described in Events. A job can add or delete an event.

The following API commands enable you to manage Events:

run event::add

The run event::add command enables you to add events to the Control-M/Server.

CLI Syntax

The following shows the CLI syntax for the run event::add command:

ctm run event::add <server> <name> <date>

The following table describes the run event::add command parameters.

Parameter

Description

server

Defines the Control-M/Server name.

name

Defines the event name.

date

Determines the date options to order the event:

Valid values:

  • MMDD: A specific date.

  • ODAT: The current Control-M date. For example, if the current Control-M date is August 7, 2016, the ODAT converts to 0807.

  • STAT: An alternative to a specific date for an event that is not date-specific.

If annotation is enabled for the Independent AJF entities category in Control-M, you must also provide an annotation to justify your action. For more information, see Annotation Input.

REST API Syntax

The following example shows the REST API syntax for the run event::add command in cURL:

Copy
server=controlm
AuthHeader="x-api-key: $token"
# AuthHeader="Authentication: Bearer $token"  #for a session token

curl -H "$AuthHeader" -H "Content-Type: application/json" -X POST -d "{\"name\": \"newEvent\",\"date\":\"0505\"}"  "$endpoint/run/event/$server"

To select the AuthHeader value ("Authentication: Bearer $token" or "x-api-key: $token"), see Authentication Tokens.

run event::delete

The run event::delete command enables you to remove an event.

CLI Syntax

The following shows the CLI syntax for the run event::delete command:

ctm run event::delete <server> <name> <date>

The following table describes the run event::delete command parameters.

Parameter

Description

server

Defines the Control-M/Server name.

name

Defines the event name.

date

Determines the date options to order the event:

Valid values:

  • MMDD: A specific date.

  • ODAT: The current Control-M date. For example, if the current Control-M date is August 7, 2016, the ODAT converts to 0807.

  • STAT: An alternative to a specific date for an event that is not date-specific.

If annotation is enabled for the Independent AJF entities category in Control-M, you must also provide an annotation to justify your action. For more information, see Annotation Input.

REST API Syntax

The following example shows the REST API syntax for the run event::delete command in cURL:

Copy
server=controlm
name=newEvent
date=0505
AuthHeader="x-api-key: $token"
# AuthHeader="Authentication: Bearer $token"  #for a session token

curl -H "$AuthHeader" -X DELETE "$endpoint/run/event/$server/$name/$date"

To select the AuthHeader value ("Authentication: Bearer $token" or "x-api-key: $token"), see Authentication Tokens.

run events::get

The run events::get command enables you to get all events from the Control-M/Server.

CLI Syntax

The following shows the CLI syntax for the run events::get command:

ctm run events::get -s [search query]

where -s runs a search with the query string format "field1=criteria1&field2=criteria2".

Criteria may contain a * for wildcard matching and comma separator to specify multiple values.

The following table describes the run events::get fields.

Field

Description

server

Defines the Control-M/Server name.

This field was previously named ctm (deprecated name).

name

Defines the event name.

date

Defines the event date.

limit

Defines the limits of the number of returned matches.

Default: 1000 (if not defined)

The following are search examples:

Copy
-s "name=eventA"
-s "name=A*&date=0805"
-s "server=controlm&name=eventA,eventB&date=0805"

REST API Syntax

The following example shows the REST API syntax for the run events::get command in cURL:

Copy
search_criteria="name=A*&server=controlm"
AuthHeader="x-api-key: $token"
# AuthHeader="Authentication: Bearer $token"  #for a session token

curl -H "$AuthHeader" -X GET "$endpoint/run/events?$search_criteria"

To select the AuthHeader value ("Authentication: Bearer $token" or "x-api-key: $token"), see Authentication Tokens.

Response

The following example shows the parameters in the ctm run events::get response:

Copy
[
 {
    "name": "flow1_from_FlowAcc_goodJob_to_FlowAcc_badJob_2902",
    "ctm": "controlm",
    "date": "0726"
  },
  {
    "name": "flow1_from_FlowAcc_goodJob_to_FlowAcc_badJob_2935",
    "ctm": "controlm",
    "date": "0726"
  },
  {
    "name": "flow1_from_FlowAcc_goodJob_to_FlowAcc_badJob_2974",
    "ctm": "controlm",
    "date": "0726"
  },
  {
    "name": "flow1_from_FlowAcc_goodJob_to_FlowAcc_badJob_3007",
    "ctm": "controlm",
    "date": "0726"
  }
]

Workload Policy Management

Workload Policies enable you to balance the workload on Control-M resources and hosts. A Workload Policy groups together jobs and enforces workload rules that limit resource usage by those jobs during specific time periods. You can manage the definitions of Workload Policies with a JSON file. This JSON file is separate from the file that defines jobs and other objects. For more information about defining Workload Policies, see Workload Policies Reference. For more general information about workload policies, see Workload Policy Definition.

The following API commands enable you to manage Workload Policies:

run workloadpolicies:detailed::get

The run workloadpolicies:detailed::get command retrieves full details of all defined Workload Policies or a specific Workload Policy.

The response contains the full JSON details, as described in Workload Policies Reference.

CLI Syntax

The following shows the CLI syntax for the run workloadpolicies:detailed::get command:

ctm run workloadpolicies:detailed::get [-s "name=<policyName>"]

where -s runs a query for a specific Workload Policy. If you do not include the -s option, the system returns the details for all defined Workload Policies.

REST API Syntax

The following examples show the REST API syntax for the run workloadpolicies:detailed::get command in cURL:

The following example shows how to retrieve definitions of all Workload Policies:

Copy
AuthHeader="x-api-key: $token"
# AuthHeader="Authentication: Bearer $token"  #for a session token

curl -H "$AuthHeader" -H "Content-Type: application/json"
-X GET  "$endpoint/run/workloadpolicies/detailed"

The following example shows how to retrieve the definitions of a specific Workload Policy:

Copy
policyname=WPtest
AuthHeader="x-api-key: $token"
# AuthHeader="Authentication: Bearer $token"  #for a session token

curl -H "$AuthHeader" -H "Content-Type: application/json"
-X GET "$endpoint/run/workloadpolicies/detailed?name=$policyname"

To select the AuthHeader value ("Authentication: Bearer $token" or "x-api-key: $token"), see Authentication Tokens.

run workloadpolicies::add

The run workloadpolicies::add command creates new Workload Policies from definitions in a JSON file, as described in Workload Policies Reference.

CLI Syntax

The following shows the CLI syntax for the run workloadpolicies::add command:

ctm run workloadpolicies::add <workloadPoliciesFile>

where <workloadPoliciesFile> is the name of a JSON file with the Workload Policy definitions that you want to create. For more information, see Workload Policies Reference.

REST API Syntax

The following example shows the REST API syntax for the run workloadpolicies::add command in cURL:

Copy
AuthHeader="x-api-key: $token"
# AuthHeader="Authentication: Bearer $token"  #for a session token

curl -H "$AuthHeader" -H "Content-Type: application/json"
-F "workloadpoliciesfile=@examples/WPs.json" -X POST "$endpoint/run/workloadpolicies"

To select the AuthHeader value ("Authentication: Bearer $token" or "x-api-key: $token"), see Authentication Tokens.

run workloadpolicy::delete

The run workloadpolicy::delete command deletes a specific Workload Policy.

CLI Syntax

The following shows the CLI syntax for the run workloadpolicy::delete command:

ctm run workloadpolicy::delete <policyName>

where <policyName> is the name of the specific Workload Policy that you want to delete.

REST API Syntax

The following example shows the REST API syntax for the run workloadpolicy::delete command in cURL:

Copy
AuthHeader="x-api-key: $token"
# AuthHeader="Authentication: Bearer $token"  #for a session token

curl -H "$AuthHeader" -H "Content-Type: application/json"
-X DELETE "$endpoint/run/workloadpolicy/$policyname"

To select the AuthHeader value ("Authentication: Bearer $token" or "x-api-key: $token"), see Authentication Tokens.

run workloadpolicies::get

The run workloadpolicies::get command retrieves details of defined Workload Policies, with the option to filter by status. The filter enables you to retrieve only active or inactive workload policies.

The response shows the current status of each active or inactive Workload Policy and the details of the last update to Workload Policy definitions.

CLI Syntax

The following shows the CLI syntax for the run workloadpolicies::get command:

ctm run workloadpolicies::get [Active|Inactive]

REST API Syntax

The following example shows the REST API syntax for the run workloadpolicies::get command in cURL:

Copy
AuthHeader="x-api-key: $token"
# AuthHeader="Authentication: Bearer $token"  #for a session token

curl -H "$AuthHeader" -H "Content-Type: application/json"
-X GET  "$endpoint/run/workloadpolicies?state=Active"

To select the AuthHeader value ("Authentication: Bearer $token" or "x-api-key: $token"), see Authentication Tokens.

run workloadpolicy::activate

The run workloadpolicy::activate command activates an inactive Workload Policy.

If you want to activate multiple Workload Policies, specify a string that contains a * as a wildcard. In addition, you can optionally filter Workload Policies by an associated Control-M/Server.

CLI Syntax

The following shows the CLI syntax for the run workloadpolicy::activate command:

ctm run workloadpolicy::activate <policyName> [<server>]

The following table describes the run workloadpolicy::activate command parameters.

Parameter

Description

policyName

Defines the name of a Workload Policy. For multiple Workload Policies, it defines a string that contains a * as a wildcard.

server

(Optional) Defines the name of an associated Control-M/Server to use as a filter.

The system activates only Workload Policies associated with the specified Control-M/Server.

If annotation is enabled for the Active network category in Control-M, you must also provide an annotation to justify your action. For more information, see Annotation Input.

REST API Syntax

The following example shows the REST API syntax for the run workloadpolicy::activate command in cURL:

Copy
policyname=WP*
server=LocalControlM
AuthHeader="x-api-key: $token"
# AuthHeader="Authentication: Bearer $token"  #for a session token

curl -H "$AuthHeader" -H "Content-Type: application/json"
-X POST "$endpoint/run/workloadpolicy/$policyname/activate?server=$server"

To select the AuthHeader value ("Authentication: Bearer $token" or "x-api-key: $token"), see Authentication Tokens.

run workloadpolicy::deactivate

The run workloadpolicy::deactivate command deactivates an active Workload Policy.

If you want to deactivate multiple Workload Policies, specify a string that contains a * as a wildcard. In addition, you can optionally filter Workload Policies by an associated Control-M/Server.

CLI Syntax

The following shows the CLI syntax for the run workloadpolicy::deactivate command:

ctm run workloadpolicy::deactivate <policyName> [<server>]

The following table describes the run workloadpolicy::deactivate command parameters.

Parameter

Description

policyName

Defines the name of a Workload Policy. For multiple Workload Policies, it defines a string that contains a * as a wildcard.

server

(Optional) Defines the name of an associated Control-M/Server to use as a filter.

The system deactivates only Workload Policies associated with the specified Control-M/Server.

If annotation is enabled for the Active network category in Control-M, you must also provide an annotation to justify your action. For more information, see Annotation Input.

REST API Syntax

The following example shows the REST API syntax for the run workloadpolicy::deactivate command in cURL:

Copy
policyname=WP*
server=LocalControlM
AuthHeader="x-api-key: $token"
# AuthHeader="Authentication: Bearer $token"  #for a session token

curl -H "$AuthHeader" -H "Content-Type: application/json"
-X POST "$endpoint/run/workloadpolicy/$policyname/deactivate?server=$server"

To select the AuthHeader value ("Authentication: Bearer $token" or "x-api-key: $token"), see Authentication Tokens.

Service Management

Services are groups of jobs that are aggregated based on specified criteria. Control-M Automation API helps manage SLA services associated with SLA jobs (also known as Control-M BIM jobs) at the end of a job flow.

Service Management in Control-M Automation API is supported for a Control-M environment withControl-M/EM 9.0.18.200 or later.

The following API command enables you to manage services.

run services:sla::get

The run services:sla::get command retrieves details of defined SLA-type services.

For more information, see Service Management.

CLI Syntax

The following shows the CLI syntax for the run services:sla::get command:

ctm run services:sla::get

REST API Syntax

The following example shows the REST API syntax for the run services:sla::get command in cURL:

Copy
AuthHeader="x-api-key: $token"
# AuthHeader="Authentication: Bearer $token"  #for a session token

curl -H "$AuthHeader" -H "Content-Type: application/json"
-X GET  "$endpoint/run/services/sla"

To select the AuthHeader value ("Authentication: Bearer $token" or "x-api-key: $token"), see Authentication Tokens.

Response

The following example shows the parameters in the response to the ctm run services:sla::get command.

The following example lists a single SLA-type service:

Copy
{
  "serviceLastUpdatedTime": "2020-01-26T10:19:42+00:00",
  "activeServices": [
    {
      "serviceName": "SLA-BAD",
      "status": "Not Ok",
      "statusReason": "Service late,Job failure,Service actually late",
      "startTime": "2020-02-09T10:08:10+00:00",
      "endTime": "2020-02-09T10:14:20+00:00",
      "dueTime": "2020-02-09T08:00:05+00:00",
      "slackTime": "-02:14:15",
      "serviceOrderDateTime": "2020-02-09T07:00:05+00:00",
      "scheduledOrderDate": "20200209",
      "serviceJob": "LocalControlM:0002c",
      "serviceControlM": "LocalControlM",
      "priority": "3",
      "note": "",
      "totalJobs": "3",
      "jobsCompleted": "1",
      "jobsWithoutStatistics": "1",
      "completionPercentage": "33",
      "averageCompletionTime": "",
      "errors": "Job \"FindFile\" ended with failure.\nJob \"SLA-Bad\" should have started by 08:00:05 GMT+00:00 and will not start on time. The reason is: \"SLA-Bad\"  is waiting for Wait Condition.",
      "statusByJobs": {
        "executed": "0",
        "waitCondition": "2",
        "waitResource": "0",
        "waitHost": "0",
        "waitWorkload": "0",
        "completed": "0",
        "error": "1"
      }
    }
  ]
}

In this response, serviceLastUpdatedTime specifies the most recent date and time when the services are updated. After that, the response displays the following parameters for each active SLA-type service:

Parameter

Description

serviceName

Defines the service name.

status

Defines the current status of the service.

statusReason

Defines one or more reasons for the current status.

startTime

Defines the date and time when the service started to run.

endTime

Defines the date and time for when the service is estimated to stop running.

dueTime

Defines the deadline with the date and time when the service must complete to be considered not late.

slackTime

Defines the difference in time between the dueTime and its estimated endTime.

serviceOrderDateTime

Defines the date and time when the service is ordered.

scheduledOrderDate

Defines the order date if it is rescheduled during the order.

serviceJob

Defines the job ID of the job associated with the service.

serviceControlM

Defines the Control-M/Server where the service runs.

priority

Defines the priority level of the service.

note

Defines the specific service information provided as a note for the service.

totalJobs

Defines the total number of jobs in the service.

jobsCompleted

Defines the number of completed jobs in the service.

jobsWithoutStatistics

Defines the number of jobs without statistical information.

completionPercentage

Defines the percentage of completed jobs in the service.

averageCompletionTime

Defines a time estimate for the service to complete.

errors

Defines the error messages received for the jobs in the service.

statusByJobs

Defines a breakdown of the number of completed jobs in each job status.

Variable Management

Variables automatically assign dynamic environmental values to the job execution parameters.

Control-M Automation API helps manage pool-type variables. These variables are organized in hierarchical groups. They are expressed in the following manner:

%%\\<named_pool>\<variable_name>

For more information about variables, see Variables.

The following API commands enable you to manage variables:

You must have Control-M/Server and Control-M/EM version 9.0.21 or later to run Variable Management commands.

run variables::get

The run variables::get command enables you to retrieve details of defined pool variables that match a search query.

CLI Syntax

The following shows the CLI syntax for the run variables::get command:

ctm run variables::get -s "<query string>"

where -s runs a search with the query string format "field1=criteria1&field2=criteria2&field3=criteria3" and the following supported fields:

Field

Description

pool

Defines the name of the pool.

pool=Pool1

For wildcard matching, you can specify a * in the named pool string. The * wildcard can be used as the only character or the last character.

Default: * (all pools)

pool=* or pool=P*

variable

Defines the full name of the variable.

variable=Var1

For wildcard matching, you can specify a * in the variable string. The * wildcard can be used as the only character or the last character.

Default: * (all variables)

variable=* or variable=V*

server

Defines the Control-M/Server name.

The server field is required only if you have more than one Control-M/Server. In such a case, the * wildcard is not supported.

If you have only one server, you do not need to include this field or you can use the default server=*.

REST API Syntax

The following example shows the REST API syntax for the run variables::get command in cURL:

Copy
AuthHeader="x-api-key: $token"
# AuthHeader="Authentication: Bearer $token"  #for a session token

curl -H "$AuthHeader" -H "Content-Type: application/json"
-X GET  "$endpoint/run/variables?server=*&variable=%%\\\\P*\\V*"

To select the AuthHeader value ("Authentication: Bearer $token" or "x-api-key: $token"), see Authentication Tokens.

In a REST API command, all backslashes must be escaped.

Response

The following example shows a response to the run variables::get command:

Copy
{
   "variables": [
      { "%%\\\\PoolName\\AUTOVar1InPoolAddedAudit": "value1"  },
      { "%%\\\\PoolName\\AUTOVar2InPoolAddedAudit": "value2"  }
   ]
}

All backslashes are escaped in the JSON format.

run variables::set

The run variables::set command enables you to define new pool variables or update the definitions of existing pool variables.

CLI Syntax

The following shows the CLI syntax for the run variables::set command:

ctm run variables::set <server> -f <variablesDefinitionFile.json>

The following table describes the run variables::set command parameters.

Parameter

Description

server

Defines the Control-M/Server name.

variablesDefinitionFile

Defines the full path and name of a JSON file with the variable definitions.

Copy
{
   "variables": [
      { "%%\\\\PoolName\\AUTOVar1InPoolAddedAudit": "value1"  },
      { "%%\\\\PoolName\\AUTOVar2InPoolAddedAudit": "value2"  }
   ]
}

All backslashes are escaped in the JSON format.

If annotation is enabled for the Independent AJF entities category in Control-M, you must also provide an annotation to justify your action. For more information, see Annotation Input.

REST API Syntax

The following example shows the REST API syntax for the run variables::set command in cURL:

Copy
server=controlm
AuthHeader="x-api-key: $token"
# AuthHeader="Authentication: Bearer $token"  #for a session token

curl -H "$AuthHeader" -H "Content-Type: application/json"
-X POST "$endpoint/run/variables/$server" -d @VariablesDefinitions.json

To select the AuthHeader value ("Authentication: Bearer $token" or "x-api-key: $token"), see Authentication Tokens.

run variables::delete

The run variables::delete command enables you to delete variables from the server.

CLI Syntax

The following shows the CLI syntax for the run variables::delete command:

ctm run variables::delete <server> -f <variablesNames.json

The following table describes the run variables::delete command parameters.

Parameter

Description

server

Defines the Control-M/Server name.

variablesNames

Defines the full path and name of a JSON file with a list of variable names.

Copy
{
    "variables":
    [
        "%%\\\\PoolName\\AUTOVarInPool",
        "%%\\\\PoolName\\AUTOVarInPool2"
    ]
}

All backslashes are escaped in the JSON format.

If annotation is enabled for the Independent AJF entities category in Control-M, you must also provide an annotation to justify your action. For more information, see Annotation Input.

REST API Syntax

The following example shows the REST API syntax for the run variables::delete command in cURL:

Copy
server=controlm
AuthHeader="x-api-key: $token"
# AuthHeader="Authentication: Bearer $token"  #for a session token

curl -H "$AuthHeader" -H "Content-Type: application/json"
-X DELETE "$endpoint/run/variables/$server" -d @VariableNames.json

To select the AuthHeader value ("Authentication: Bearer $token" or "x-api-key: $token"), see Authentication Tokens.

Alert Management

An alert is a message that indicates a problem or exception in a job or folder. Control-M Automation API enables you to update basic alert properties and alert status. For more information, see Alerts.

The following API commands enable you to manage alerts:

run alerts::update

The run alerts::update command enables you to update basic alert properties, including urgency and associated comments.

CLI Syntax

The following shows the CLI syntax for the run alerts::update command:

ctm run alerts::update -f <configuration file>

The configuration file contains the properties required to update the alerts. You must include in the configuration file the mandatory alertIds parameter and at least one of the other relevant parameters.

The following table describes the parameters for the run alerts::update command:

Parameter

Description

alertIds

Defines the unique identifiers for the alerts that you want to update.

urgency

Determines the severity of the alert.

Valid values:

  • Normal

  • Urgent

  • Critical

comment

Defines a free-text comment about the alert.

The following example shows a configuration file:

Copy
{
    "alertIds" : [30,31],
    "urgency":"Normal",
    "comment":"update"
}

REST API Syntax

The following example shows the REST API syntax for the run alerts::update command in cURL:

Copy
AuthHeader="x-api-key: $token"
# AuthHeader="Authentication: Bearer $token"  #for a session token

curl -H "$AuthHeader" -H "Content-Type: application/json"
-X POST "$endpoint/run/alerts" -d @alertModifyValue.json

The configuration file is named alertModifyValue.json.

To select the AuthHeader value ("Authentication: Bearer $token" or "x-api-key: $token"), see Authentication Tokens.

run alerts:status::update

The run alerts:status::update command enables you to update the alert status.

CLI Syntax

The following shows the CLI syntax for the run alerts:status::update command:

ctm run alerts:status::update <alertIds> -f <configuration file>

The configuration file contains the properties required to update the alert status.

The following table describes the run alerts:status::update command parameters.

Parameter

Description

alertIds

Defines unique identifiers for the alerts that you want to update.

status

Determines the alert status.

Valid values:

  • New

  • Reviewed

  • Closed

  • Undefined

The following example shows a configuration file:

Copy
{
    "alertIds" : [20],
    "status":"Reviewed"
}

REST API Syntax

The following example shows the REST API syntax for the run alerts:status::update command in cURL:

Copy
endpoint=
alertIds=15,20
AuthHeader="x-api-key: $token"
# AuthHeader="Authentication: Bearer $token"  #for a session token

curl -H "$AuthHeader" -H "Content-Type: application/json"
-X POST "$endpoint/run/alerts/status/$alertIds" -d @alertModifyStatus.json

The configuration file is named alertModifyStatus.json.

To select the AuthHeader value ("Authentication: Bearer $token" or "x-api-key: $token"), see Authentication Tokens.