Skip to main content
Version: OpCon 26.0 (On-Prem)

Event Types

Theme: Configure
Who Is It For? Automation Engineer

What Is It?​

This section contains the syntax, definition, and parameter descriptions for all supported OpCon events.

Administrative Events​

$CALENDAR:ADD​

The $CALENDAR:ADD event adds one or more dates to an existing calendar. If the calendar does not exist, the event will fail.

caution

Adding and removing dates on a calendar can have a direct impact to whether jobs will run or not.

Syntax:

$CALENDAR:ADD,<calendar name>,<calendar dates>

Parameters:

  • <calendar name>: The calendar name to which to add the dates
  • <calendar dates>: A semicolon (;) separated list of dates to add to the calendar. The dates must be defined using a date syntax recognized by the regional settings of the user running SMA Service Manager

Required Privileges:

  • Maintain Calendars

XML Syntax:

<EVENT>
   <TYPE>CALENDAR</TYPE>
   <ACTION>ADD</ACTION>
   <CALNAME></CALNAME>
   <DATES>
       <CALDATE></CALDATE>
       <CALDATE></CALDATE>\...</DATES>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

$CALENDAR:DEL​

The $CALENDAR:DEL event deletes one or more dates a calendar. If the calendar does not exist, the event will fail.

caution

Adding and removing dates on a calendar can have a direct impact to whether jobs will run or not.

Syntax:

$CALENDAR:DEL,<calendar name>,<calendar dates>

Parameters:

  • <calendar name>: The calendar name to which to add the dates
  • <calendar dates>: A semicolon (;) separated list of dates to remove from the calendar. The dates must be defined using a date syntax recognized by the regional settings of the user running SMA Service Manager

Required Privileges:

  • Maintain Calendars

XML Syntax:

<EVENT>
   <TYPE>CALENDAR</TYPE>
   <ACTION>DEL</ACTION>
   <CALNAME></CALNAME>
   <DATES>
       <CALDATE></CALDATE>
       <CALDATE></CALDATE>\...</DATES>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

$JOB:MACHGRP​

The $JOB:MACHGRP event changes the Machine Group for a job in the Daily.

Syntax:

$JOB:MACHGRP,<schedule date>,<schedule name>,<job name>,<machine group name>

Parameters:

  • <schedule date>: The date of the Daily schedule containing the job
  • <schedule name>: The name of the schedule containing the job
  • <job name>: The name of the job to affect on in the Daily schedule
  • <machine group name>: The new Machine Group name for the job to use in the Daily schedule

Required Privileges:

  • Modify Jobs in Daily Schedules

XML Syntax:

<EVENT>
   <TYPE>JOB</TYPE>
   <ACTION>MACHGRP</ACTION>
   <SKDDATE></SKDDATE>
   <SKDNAME></SKDNAME>
   <JOBNAME></JOBNAME>
   <MACHGRPNAME></MACHGRPNAME>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

$JOB:MAXRUNTIME​

The $JOB:MAXRUNTIME event updates the maximum runtime for the job in the Daily.

Syntax:

$JOB:MAXRUNTIME,<schedule date>,<schedule name>,<job name>,<minutes>

Parameters:

  • <schedule date>: The date of the Daily schedule containing the job
  • <schedule name>:The name of the schedule containing the job
  • <job name>: The name of the job to affect on in the Daily schedule
  • <minutes>: The number of minutes to set the Max Run Time for the job to use in the Daily schedule

Required Privileges:

  • Modify Jobs in Daily Schedules

XML Syntax:

<EVENT>
   <TYPE>JOB</TYPE>
   <ACTION>MAXRUNTIME</ACTION>
   <SKDDATE></SKDDATE>
   <SKDNAME></SKDNAME>
   <JOBNAME></JOBNAME>
   <MAXMINS></MAXMINS>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

$JOB:PRIORITY​

The $JOB:PRIORITY event updates the SAM Priority for the job in the Daily.

Syntax:

$JOB:PRIORITY,<schedule date>,<schedule name>,<job name>,<SAM priority>

Parameters:

  • <schedule date>: The date of the Daily schedule containing the job
  • <schedule name>: The name of the schedule containing the job
  • <job name>: The name of the job to affect on in the Daily schedule
  • <SAM priority>: The new SAM priority value for the job to use in the Daily schedule

Required Privileges:

  • Modify Jobs in Daily Schedules

XML Syntax:

<EVENT>
   <TYPE>JOB</TYPE>
   <ACTION>PRIORITY</ACTION>
   <SKDDATE></SKDDATE>
   <SKDNAME></SKDNAME>
   <JOBNAME></JOBNAME>
   <PRIORITY></PRIORITY>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

$JOB:TAGADD​

The $JOB:TAGADD event adds one or more tags to the job in the Daily.

Syntax:

$JOB:TAGADD,<schedule date>,<schedule name>,<job name>,<tags>

Parameters:

  • <schedule date>: The date of the Daily schedule containing the job
  • <schedule name>:The name of the schedule containing the job
  • <job name>: The name of the job to affect on in the Daily schedule
  • <tags>: A semicolon (;) separated list of tags to add to the Daily job

Required Privileges:

  • Modify Jobs in Daily Schedules

XML Syntax:

<EVENT>
   <TYPE>JOB</TYPE>
   <ACTION>TAGADD</ACTION>
   <SKDDATE></SKDDATE>
   <SKDNAME></SKDNAME>
   <JOBNAME></JOBNAME>
   <TAGS>
       <TAG></TAG>
       <TAG></TAG>\...</TAGS>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

$JOB:TAGDEL​

The $JOB:TAGDEL event deletes one or more tags from the job in the Daily.

Synax:

$JOB:TAGDEL,<schedule date>,<schedule name>,<job name>,<tags>

Parameters:

  • <schedule date>: The date of the Daily schedule containing the job
  • <schedule name>:The name of the schedule containing the job
  • <job name>: The name of the job to affect on in the Daily schedule
  • <tags>: A semicolon (;) separated list of tags to delete from the Daily job

Required Privileges:

  • Modify Jobs in Daily Schedules

XML Syntax:

<EVENT\>
   <TYPE\>JOB</TYPE\>
   <ACTION\>TAGDEL</ACTION\>
   <SKDDATE\></SKDDATE\>
   <SKDNAME\></SKDNAME\>
   <JOBNAME\></JOBNAME\>
   <TAGS\>
       <TAG\></TAG\>
       <TAG\></TAG\>\...</TAGS\>
   <USERNAME\></USERNAME\>
   <USERPWD\></USERPWD\>
</EVENT\>

$JOB:USER​

The $JOB:USER event changes the Batch User on the job in the Daily.

Syntax:

$JOB:USER,<schedule date\>,<schedule name\>,<job name\>,<batch user\>

Parameters:

  • <schedule date>: The date of the Daily schedule containing the job
  • <schedule name>: The name of the schedule containing the job
  • <job name>: The name of the job to affect on in the Daily schedule
  • <batch user>: The name of the new Batch User account for the job to use in the Daily schedule

Required Privileges:

  • Only the OCADM role can change the Batch User via an event.

XML Syntax:

<EVENT>
   <TYPE>JOB</TYPE>
   <ACTION>USER</ACTION>
   <SKDDATE></SKDDATE>
   <SKDNAME></SKDNAME>
   <JOBNAME></JOBNAME>
   <USER></USER>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

$JOBMASTER:BUILDSTATE​

The $JOBMASTER:BUILDSTATE event changes the build status for the frequency of the job in the Master.

Syntax:

$JOBMASTER:BUILDSTATE,<schedule name>,<job name>,<frequency name>,<build state>

Parameters:

  • <schedule name>:The name of the schedule containing the job
  • <job name>: The name of the job to affect on in the Master schedule
  • <frequency name>: The frequency name of the job to associate the Build Status with in the Master schedule
  • <build state>: The build status to set for the frequency on the job in the Master. Valid values include:
    • D, Disable Frequency, or Disabled
    • R, or Released
    • S, To Be Skipped, or Skipped
    • N, Do Not Schedule, or Not Scheduled
    • H, On Hold, or Held

Required Privileges:

  • Modify Jobs in Master Schedules

XML Syntax:

<EVENT>
   <TYPE>JOBMASTER</TYPE>
   <ACTION>BUILDSTATE</ACTION>
   <SKDNAME></SKDNAME>
   <JOBNAME></JOBNAME>
   <FREQNAME></FREQNAME>
   <BLDSTATE></BLDSTATE>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

$JOBMASTER:TAGADD​

The $JOBMASTER:TAGADD event adds one or more tags to the job in the Master.

Syntax:

$JOBMASTER:TAGADD,<schedule name>,<job name>,<frequency name>,<tags>

Parameters:

  • <schedule name>:The name of the schedule containing the job
  • <job name>: The name of the job to affect on in the Master schedule
  • <frequency name>: The frequency name of the job to associate the tag with in the Master schedule. To associate the tag at the job level, leave this field blank
  • <tags>: A semicolon (;) separated list of tags to add to the Master job

Required Privileges:

  • Modify Jobs in Master Schedules

XML Syntax:

<EVENT>
   <TYPE>JOBMASTER</TYPE>
   <ACTION>TAGADD</ACTION>
   <SKDNAME></SKDNAME>
   <JOBNAME></JOBNAME>
   <FREQNAME></FREQNAME>
   <TAGS>
       <TAG></TAG>
       <TAG></TAG>\...</TAGS>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

$JOBMASTER:TAGDEL​

The $JOBMASTER:TAGDEL event deletes one or more tags from the job in the Master.

Syntax:

$JOBMASTER:TAGDEL,<schedule name>,<job name>,<frequency name>,<tags>

Parameters:

  • <schedule name>:The name of the schedule containing the job
  • <job name>: The name of the job to affect on in the Master schedule
  • <frequency name>: The frequency name the tag is associated with on the job with in the Master schedule. To delete the tag at the job level, leave this field blank
  • <tags>: A semicolon (;) separated list of tags to delete from the Master job

Required Privileges:

  • Modify Jobs in Master Schedules

XML Syntax:

<EVENT>
   <TYPE>JOBMASTER</TYPE>
   <ACTION>TAGDEL</ACTION>
   <SKDNAME></SKDNAME>
   <JOBNAME></JOBNAME>
   <FREQNAME></FREQNAME>
   <TAGS>
       <TAG></TAG>
       <TAG></TAG>\...</TAGS>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

$RESOURCE:DEL​

The $RESOURCE:DEL event deletes the resource from the administrative tables. This event will only succeed if a cross reference check reveals that there are no jobs in the Master or Daily using this resource for a Resource Dependency or Resource Update.

warning

When you delete a resource, internal and external events that reference the resource will begin failing unless you modify them.

Syntax:

$RESOURCE:DEL,<resource name>

Parameters:

  • <resource name>: The name of the resource to delete

Required Privileges:

  • Maintain Thresholds/Resources

XML Syntax:

<EVENT>
   <TYPE>RESOURCE</TYPE>
   <ACTION>DEL</ACTION>
   <RESOURCENAME></RESOURCENAME>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

$RESOURCE:RENAME​

The $RESOURCE:RENAME event renames a resource in the administrative tables.

warning

When you rename a resource, internal and external events that reference the resource will begin failing unless you modify them.

Syntax:

$RESOURCE:RENAME,<old resource name>, <new resource name>

Parameters:

  • <old resource name>: The current name of the resource to rename.
  • <new resource name>: The new name for the resource. The name must not exceed 20 characters and cannot contain single quotes.

Required Privileges:

  • Maintain Thresholds/Resources

XML Syntax:

<EVENT>
   <TYPE>RESOURCE</TYPE>
   <ACTION>RENAME</ACTION>
   <OLDNAME></OLDNAME>
   <NEWNAME></NEWNAME>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

$THRESHOLD:DEL​

The $THRESHOLD:DEL event deletes the threshold from the administrative tables. This event will only succeed if a cross reference check reveals that there are no jobs in the Master or Daily using this resource for a Threshold Dependency or Threshold Update.

warning

When you delete a threshold, internal and external events that reference the threshold will begin failing unless you modify them.

Syntax:

$THRESHOLD:DEL,<threshold name>

Parameters:

  • <threshold name>: The name of the threshold to delete

Required Privileges:

  • Maintain Thresholds/Resources

XML Syntax:

<EVENT>
   <TYPE>THRESHOLD</TYPE>
   <ACTION>DEL</ACTION>
   <THRESHNAME></THRESHNAME>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

$THRESHOLD:RENAME​

The $THRESHOLD:RENAME event renames a threshold in the administrative tables.

warning

When you rename a threshold, internal and external events that reference the threshold will begin failing unless you modify them.

Syntax:

$THRESHOLD:RENAME,<old threshold name>,<new threshold name>

Parameters:

  • <old threshold name>: The current name of the threshold to rename.
  • <new threshold name>: The new name for the threshold. The name must not exceed 20 characters and cannot contain single quotes.

Required Privileges:

  • Maintain Thresholds/Resources

XML Syntax:

<EVENT>
   <TYPE>THRESHOLD</TYPE>
   <ACTION>RENAME</ACTION>
   <OLDNAME></OLDNAME>
   <NEWNAME></NEWNAME>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

For all job-related events, only valid job status changes are allowed. For more information, refer to Job Statuses in the Concepts online help.

$JOB:ADD​

The $JOB:ADD event adds the job from the Master tables to the Daily tables for the specified parameters. Depending on the job's "Allow Multi-Instance" setting, requesting a running job will start a duplicate job. For more information, refer to Adding Jobs to Daily Schedules in the Concepts online help.

Syntax:

$JOB:ADD,<schedule date>,<schedule name>,<job name>,<frequency name>,\[job instance property definitions\],\[reopen schedule: Y/N\],\[apply exceptions: Y/N\]

Parameters:

  • <schedule date>: The date to which to add the job

  • <schedule name>: The name of the schedule containing the job

  • <job name>: The name of the job to add to the Daily schedule

  • <frequency name>: The frequency to use for adding the correct dependencies and events for the job. If a frequency name is not specified, the job will default to its first frequency

  • [job instance property definitions]: Defines properties and values for the job being added. This parameter is optional. If not specified, the comma preceding this parameter is not required. For information on creating valid property definitions, refer to Defining Properties in the Concepts online help. Define Properties using the following syntax in the event:

    PropertyName1=PropertyValue1;PropertyName2=PropertyName2
note

If the job is configured to "Run on Each Machine" in a group, the MACHINENAME=<machine name> property can be defined as the first property to add only an instance of the job for one machine.

  • [reopen schedule: Y/N]: Indicates whether a completed parent schedule is reopened. This parameter is optional. Valid values are:
    • Y: Reopen a parent schedule that is closed (has run and is completed) so that any new jobs that are added via the $JOB:ADD event will run. When set to Yes (Y), this new parameter will override the "Job Events to Restart Schedules" setting in the Server Options if it is set to False
    • N: Do not reopen a parent schedule that is closed (has run and is completed). Any new jobs that are added via the $JOB:ADD event will remain in a Qualifying state and never run. When set to No (N), this new parameter will override the "Job Events to Restart Schedules" setting in the Server Options if it is set to True
    • If the parameter is not set or specified, the default value will be set to N
      note

      SAM will reject $JOB:ADD events for Container jobs whose subschedules are In Process.

  • [apply exceptions: Y/N]: Indicates whether exceptions will be applied to the job when the job is added. This parameter is optional. Valid values are:
    • Y: Apply exceptions to the job
    • N: Do not apply exceptions to the job
    • If the parameter is not set or specified, the default value will be set to N

Required Privileges:

  • Add Jobs to Daily Schedules

XML Syntax:

<EVENT>
   <TYPE>JOB</TYPE>
   <ACTION>ADD</ACTION>
   <SKDDATE></SKDDATE>
   <SKDNAME></SKDNAME>
   <JOBNAME></JOBNAME>
   <FREQNAME></FREQNAME>
   <PROPERTIES>
       <PROPERTY></PROPERTY>
       <PROPERTY></PROPERTY>\...</PROPERTIES>
   <REOPENSKD></REOPENSKD>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

$JOB:ADDHLD​

The $JOB:ADDHLD event adds the job from the Master tables to the Daily tables with a status of Held for the specified parameters. Depending on the job's "Allow Multi-Instance" setting, requesting a running job will start a duplicate job.

Syntax:

$JOB:ADDHLD,<schedule date>,<schedule name>,<job name>,<frequency name>,\[job instance property definitions\],\[reopen schedule: Y/N\]

Parameters:

  • <schedule date>: The date to which to add the job

  • <schedule name>: The name of the schedule containing the job

  • <job name>: The name of the job to add to the Daily schedule

  • <frequency name>: The frequency to use for adding the correct dependencies and events for the job. If a frequency name is not specified, the job will default to its first frequency

  • [job instance property definitions]: Defines properties and values for the job being added. This parameter is optional. If not specified, the comma preceding this parameter is not required. For information on creating valid property definitions, refer to Defining Properties in the Concepts online help. Define Properties using the following syntax in the event:

    PropertyName1=PropertyValue1;PropertyName2=PropertyName2
note

If the job is configured to "Run on Each Machine" in a group, the MACHINENAME=<machine name> property can be defined as the first property to add only an instance of the job for one machine.

  • [reopen schedule: Y/N]: Indicates whether a completed parent schedule is reopened. This parameter is optional. Valid values are:
    • Y: Reopen a parent schedule that is closed (has run and is completed) so that any new jobs that are added via the $JOB:ADD event will run. When set to Yes (Y), this new parameter will override the "Job Events to Restart Schedules" setting in the Server Options if it is set to False
    • N: Do not reopen a parent schedule that is closed (has run and is completed). Any new jobs that are added via the $JOB:ADD event will remain in a Qualifying state and never run. When set to No (N), this new parameter will override the "Job Events to Restart Schedules" setting in the Server Options if it is set to True
    • If the parameter is not set or specified, the default value will be set to N
      note

      SAM will reject $JOB:ADD events for Container jobs whose subschedules are In Process.

  • [apply exceptions: Y/N]: Indicates whether exceptions will be applied to the job when the job is added. This parameter is optional. Valid values are:
    • Y: Apply exceptions to the job
    • N: Do not apply exceptions to the job
    • If the parameter is not set or specified, the default value will be set to N

Required Privileges:

  • Add Jobs to Daily Schedules

XML Syntax:

<EVENT>
   <TYPE>JOB</TYPE>
   <ACTION>ADDHLD</ACTION>
   <SKDDATE></SKDDATE>
   <SKDNAME></SKDNAME>
   <JOBNAME></JOBNAME>
   <FREQNAME></FREQNAME>
   <PROPERTIES>
       <PROPERTY></PROPERTY>
       <PROPERTY></PROPERTY>\...</PROPERTIES>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

$JOB:BAD​

The $JOB:BAD event marks the job as Failed.

Syntax:

$JOB:BAD,<schedule date>,<schedule name>,<job name>

Parameters:

  • <schedule date>: The date of the Daily schedule containing the job
  • <schedule name>: The name of the schedule containing the job
  • <job name>: The name of the job on which to run command in the Daily schedule

Required Privileges:

  • Mark Jobs Failed

XML Syntax:

<EVENT>
   <TYPE>JOB</TYPE>
   <ACTION>BAD</ACTION>
   <SKDDATE></SKDDATE>
   <SKDNAME></SKDNAME>
   <JOBNAME></JOBNAME>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

$JOB:CANCEL​

The $JOB:CANCEL event cancels the job. Any jobs dependent on this job does not have the dependency met. This event is allowed for jobs on 'hold'.

Syntax:

$JOB:CANCEL,<schedule date>,<schedule name>,<job name>

Parameters:

  • <schedule date>: The date of the Daily schedule containing the job
  • <schedule name>: The name of the schedule containing the job
  • <job name>: The name of the job on which to run command in the Daily schedule

Required Privileges:

  • Cancel Jobs

XML Syntax:

<EVENT>
   <TYPE>JOB</TYPE>
   <ACTION>CANCEL</ACTION>
   <SKDDATE></SKDDATE>
   <SKDNAME></SKDNAME>
   <JOBNAME></JOBNAME>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

$JOB:DELETE​

The $JOB:DELETE event deletes the job from the Daily schedule. If the job is Running, the event is rejected.

Syntax:

$JOB:DELETE,<schedule date>,<schedule name>,<job name>

Parameters:

  • <schedule date>: The date of the Daily schedule containing the job
  • <schedule name>: The name of the schedule containing the job
  • <job name>: The name of the job on which to run command in the Daily schedule

Required Privileges:

  • Delete Jobs from Daily Schedules

XML Syntax:

<EVENT>
   <TYPE>JOB</TYPE>
   <ACTION>DELETE</ACTION>
   <SKDDATE></SKDDATE>
   <SKDNAME></SKDNAME>
   <JOBNAME></JOBNAME>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

$JOB:FIXED​

The $JOB:FIXED event marks the job as Fixed.

Syntax:

$JOB:FIXED,<schedule date>,<schedule name>,<job name>

Parameters:

  • <schedule date>: The date of the Daily schedule containing the job
  • <schedule name>: The name of the schedule containing the job
  • <job name>: The name of the job on which to run command in the Daily schedule

Required Privileges:

  • Delete Jobs from Daily Schedules

XML Syntax:

<EVENT>
   <TYPE>JOB</TYPE>
   <ACTION>DELETE</ACTION>
   <SKDDATE></SKDDATE>
   <SKDNAME></SKDNAME>
   <JOBNAME></JOBNAME>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

$JOB:GOOD​

The $JOB:GOOD event marks the job as Finished OK.

Syntax:

$JOB:GOOD,<schedule date>,<schedule name>,<job name>

Parameters:

  • <schedule date>: The date of the Daily schedule containing the job
  • <schedule name>: The name of the schedule containing the job
  • <job name>: The name of the job on which to run command in the Daily schedule

Required Privileges:

  • Mark Jobs Finished OK

XML Syntax:

<EVENT>
   <TYPE>JOB</TYPE>
   <ACTION>GOOD</ACTION>
   <SKDDATE></SKDDATE>
   <SKDNAME></SKDNAME>
   <JOBNAME></JOBNAME>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

$JOB:HOLD​

The $JOB:HOLD event places the job on hold. The SAM does not start the job until it is released.

Syntax:

$JOB:HOLD,<schedule date>,<schedule name>,<job name>

Parameters:

  • <schedule date>: The date of the Daily schedule containing the job
  • <schedule name>: The name of the schedule containing the job
  • <job name>: The name of the job on which to run command in the Daily schedule

Required Privileges:

  • Hold Jobs

XML Syntax:

<EVENT>
   <TYPE>JOB</TYPE>
   <ACTION>HOLD</ACTION>
   <SKDDATE></SKDDATE>
   <SKDNAME></SKDNAME>
   <JOBNAME></JOBNAME>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

$JOB:KILL​

The $JOB:KILL event aborts the job on the agent machine. OpCon reports a killed job as Failed. This event is not available for the BIS, OpenVMS, and OS 2200 platforms.

Syntax:

$JOB:KILL,<schedule date>,<schedule name>,<job name>

Parameters:

  • <schedule date>: The date of the Daily schedule containing the job
  • <schedule name>: The name of the schedule containing the job
  • <job name>: The name of the job on which to run command in the Daily schedule

Required Privileges:

  • Kill Jobs

XML Syntax:

<EVENT>
   <TYPE>JOB</TYPE>
   <ACTION>KILL</ACTION>
   <SKDDATE></SKDDATE>
   <SKDNAME></SKDNAME>
   <JOBNAME></JOBNAME>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

$JOB:QUESTATE​

The $JOB:QUESTATE event reports the queue state of a tracked job. This event is only passed between the agent and the SAM to update the queue status and queue information for a job.

Syntax:

$JOB:QUESTATE, schedule-date, schedule-name, job-name, job-status, job-que-info|mach|job-que-display

Required Privileges: None

XML Syntax:

<EVENT>
   <TYPE>JOB</TYPE>
   <ACTION>QUESTATE</ACTION>
   <SKDDATE></SKDDATE>
   <SKDNAME></SKDNAME>
   <JOBNAME></JOBNAME>
   <JOBSTATUS></JOBSTATUS>
   <JOBPDATA></JOBPDATA>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

$JOB:QUEUED​

The $JOB:QUEUED event tracks user-submitted jobs on the IBM i and z/OS platforms. This event is only passed between the agent and the SAM. If a running job is requested, the multi-instance setting on the job is honored. This event must be submitted to an active schedule, or the event is rejected, unless the AdHoc schedule name is used. See additional notes about the AdHoc job under the event $JOB:TRACK.

note

If the job is not multi-instance and it is already associated with an OpCon job in Operations that is Waiting or Running, the SAM rejects the event. If the job is Finished OK or Failed, SAM accepts the event for processing.

Parameters:

None

Required Privileges:

  • TBD

XML Syntax:

<EVENT>
   <TYPE>JOB</TYPE>
   <ACTION>QUEUED</ACTION>
   <SKDDATE></SKDDATE>
   <SKDNAME></SKDNAME>
   <JOBNAME></JOBNAME>
   <FREQNAME></FREQNAME>
   <JOBPDATA></JOBPDATA>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>
More Info

For IBM i, visit the following section in the IBM i Agent online help: Overview of Job Tracking

For z/OS, visit the following section in the Concepts online help: Tracking Externally Submitted Batch Job Events in OpCon

$JOB:RELEASE​

The $JOB:RELEASE event releases the job from a Held state. The SAM starts this job once all its dependencies have been satisfied.

Syntax:

$JOB:RELEASE,<schedule date>,<schedule name>,<job name>

Parameters:

  • <schedule date>: The date of the Daily schedule containing the job
  • <schedule name>: The name of the schedule containing the job
  • <job name>: The name of the job on which to run command in the Daily schedule

Required Privileges:

  • Release Jobs

XML Syntax:

<EVENT>
   <TYPE>JOB</TYPE>
   <ACTION>RELEASE</ACTION>
   <SKDDATE></SKDDATE>
   <SKDNAME></SKDNAME>
   <JOBNAME></JOBNAME>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

$JOB:RESCHEDHLD​

The $JOB:RESCHEDHLD reschedules the job start time after the number of minutes specified. This job will be rescheduled, but put in a Held state.

Syntax:

$JOB:RESCHEDHLD,<schedule date>,<schedule name>,<job name>,<T/S/N>,<minutes>

Parameters:

  • <schedule date>: The date of the Daily schedule containing the job
  • <schedule name>: The name of the schedule containing the job
  • <job name>: The name of the job on which to run command in the Daily schedule
  • <T/S/N>:
    • T: The new start time is calculated based on the time the job Terminated
      • If the job is on a schedule in the future that has not started, SAM uses the future schedule start date and intended start time of the job
    • S: The new start time is calculated based on the time the job Started
      • If the job is on a schedule in the future that has not started, SAM uses the future schedule start date and intended start time of the job
    • N: The new start time is calculated based on Now, which is the current time the event is processed
      note

      The start time of a running job cannot be rescheduled. SAM will reject $JOB:RESCHEDHLD events for Container jobs whose subschedules are In Process.

      • If the job has not run yet in an active schedule, the SAM always uses the current time the event is processed plus the number of minutes specified in the event
      • SAM uses N by default if the value is not specified in the event
    • <minutes>: Define the number of minutes in the future to set the start time based on the setting in the T/S/N field. The maximum value is 1439
      • For jobs that have not yet started, you can use the plus (+) and minus (-) symbols to increment or decrement the current start offset value of a job. The <T/S/N> value is ignored in this case

Required Privileges:

  • Restart Jobs

XML Syntax:

<EVENT>
   <TYPE>JOB</TYPE>
   <ACTION>RESCHEDHLD</ACTION>
   <SKDDATE></SKDDATE>
   <SKDNAME></SKDNAME>
   <JOBNAME></JOBNAME>
   <OFFSETFROM></OFFSETFROM>
   <OFFSETMIN></OFFSETMIN>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

$JOB:RESCHEDULE​

The $JOB:RESCHEDULE reschedules the job start time after the number of minutes specified. The event updates the job's status to Qualifying; consequently, the event releases a Hold status and clears a To Be Skipped status.

note

If the job should reschedule itself on a Finished OK or Failed status, Continuous recommends using the Job Frequency and Other Job Details features in the Concepts online help.

The Job Recurrence and Retry on Job Failure features are much more efficient than the $JOB:RESCHEDULE event when used in those scenarios.

By default if a schedule is Completed, the reschedule event will not automatically re-open the schedule. For information on changing the setting to "Allow Job Events to Restart Schedules", refer to Time Settings in the Concepts online help.

Syntax:

$JOB:RESCHEDULE,<schedule date>,<schedule name>,<job name>,<T/S/N>,<minutes>

Parameters:

  • <schedule date>: The date of the Daily schedule containing the job
  • <schedule name>: The name of the schedule containing the job
  • <job name>: The name of the job on which to run command in the Daily schedule
  • <T/S/N>:
    • T: The new start time is calculated based on the time the job Terminated
      • If the job is on a schedule in the future that has not started, SAM uses the future schedule start date and intended start time of the job
    • S: The new start time is calculated based on the time the job Started
      • If the job is on a schedule in the future that has not started, SAM uses the future schedule start date and intended start time of the job
    • N: The new start time is calculated based on Now, which is the current time the event is processed
      note

      The start time of a running job cannot be rescheduled. SAM will reject $JOB:RESCHEDULE events for Container jobs whose subschedules are In Process.

      • If the job has not run yet in an active schedule, the SAM always uses the current time the event is processed plus the number of minutes specified in the event
      • SAM uses N by default if the value is not specified in the event
    • <minutes>: Define the number of minutes in the future to set the start time based on the setting in the T/S/N field. The maximum value is 1439
      • For jobs that have not yet started, you can use the plus (+) and minus (-) symbols to increment or decrement the current start offset value of a job. The <T/S/N> value is ignored in this case

Required Privileges:

  • Restart Jobs

XML Syntax:

<EVENT>
   <TYPE>JOB</TYPE>
   <ACTION>RESCHEDULE</ACTION>
   <SKDDATE></SKDDATE>
   <SKDNAME></SKDNAME>
   <JOBNAME></JOBNAME>
   <OFFSETFROM></OFFSETFROM>
   <OFFSETMIN></OFFSETMIN>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

$JOB:RESTART​

The $JOB:RESTART event places the job back in a Qualifying state. The job is started as soon as all dependencies are met. By default, the job must be restarted in an active schedule, or the event is rejected.

Syntax:

$JOB:RESTART,<schedule date>,<schedule name>,<job name>,\[Force Restart (optional)\],\[Restart Step (optional)\]

Parameters:

  • <schedule date>: The date of the Daily schedule containing the job
  • <schedule name>: The name of the schedule containing the job
  • <job name>: The name of the job on which to run command in the Daily schedule
  • [Force Restart (optional)]: Indicates whether to force start the job. This parameter is optional. Valid values are:
    • Y: Force start the job
    • N: Do not force start the job
    • If the parameter is not set or specified, the default value will be set to N
  • [Restart Step (optional)]: Specifies whether to restart the job on a pre-configured step setting. This parameter is optional and is only supported for the SAP R/3 and CRM, SAP BW, UNIX, and z/OS platforms. Valid values are dependent on the host system:
    • SAP: For more on the valid values for the SAP system, refer to the SAP Agent Advanced Features in the SAP agent documentation
    • SAP BW: For more on the valid values for the SAP BW system, refer to the SAP BW agent Advanced Featuresin the SAP BW agent documentation
    • UNIX: For more on the valid values for the UNIX system, refer to sma_job_step in the UNIX agent documentation
    • z/OS: The start and end steps can be specified in the 'JCL' format (jobstep or jobstep.procstep), separated by a pipe character. If there is no pipe, or it is not followed by a step name, the job will run to the end. If there is no starting step (i.e., the restart step starts with a pipe), then the job will be restarted without using the step restart feature

Required Privileges:

  • Restart Jobs

XML Syntax:

<EVENT>
   <TYPE>JOB</TYPE>
   <ACTION>RESTART</ACTION>
   <SKDDATE></SKDDATE>
   <SKDNAME></SKDNAME>
   <JOBNAME></JOBNAME>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

$JOB:RESTARTHLD​

The $JOB:RESTARTHLD event places the job back in a Held state. The job will be started as soon as all dependencies are met and it is Released. By default, the job must be restarted in an active schedule, or the event will be rejected.

Syntax:

$JOB:RESTARTHLD,<schedule date>,<schedule name>,<job name>,\[Force Restart (optional)\],\[Restart Step (optional)\]

Parameters:

  • <schedule date>: The date of the Daily schedule containing the job
  • <schedule name>: The name of the schedule containing the job
  • <job name>: The name of the job on which to run command in the Daily schedule
  • [Force Restart (optional)]: Indicates whether to force start the job. This parameter is optional. Valid values are:
    • Y: Force start the job
    • N: Do not force start the job
    • If the parameter is not set or specified, the default value will be set to N
  • [Restart Step (optional)]: Specifies whether to restart the job on a pre-configured step setting. This parameter is optional and is only supported for the SAP R/3 and CRM, SAP BW, UNIX, and z/OS platforms. Valid values are dependent on the host system:
    • SAP: For more on the valid values for the SAP system, refer to the SAP Agent Advanced Features in the SAP agent documentation
    • SAP BW: For more on the valid values for the SAP BW system, refer to the SAP BW agent Advanced Featuresin the SAP BW agent documentation
    • UNIX: For more on the valid values for the UNIX system, refer to sma_job_step in the UNIX agent documentation
    • z/OS: The start and end steps can be specified in the 'JCL' format (jobstep or jobstep.procstep), separated by a pipe character. If there is no pipe, or it is not followed by a step name, the job will run to the end. If there is no starting step (i.e., the restart step starts with a pipe), then the job will be restarted without using the step restart feature

Required Privileges:

  • Restart Jobs

XML Syntax:

<EVENT>
   <TYPE>JOB</TYPE>
   <ACTION>RESTARTHLD</ACTION>
   <SKDDATE></SKDDATE>
   <SKDNAME></SKDNAME>
   <JOBNAME></JOBNAME>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

$JOB:SKIP​

The $JOB:SKIP event places the job in a Job to be Skipped state until the job qualifies to start. When the job qualifies, it is canceled and the job dependency of all subsequent jobs is met.

Syntax:

$JOB:SKIP,<schedule date>,<schedule name>,<job name>

Parameters:

  • <schedule date>: The date of the Daily schedule containing the job
  • <schedule name>: The name of the schedule containing the job
  • <job name>: The name of the job on which to run command in the Daily schedule

Required Privileges:

  • Skip Jobs

XML Syntax:

<EVENT>
   <TYPE>JOB</TYPE>
   <ACTION>SKIP</ACTION>
   <SKDDATE></SKDDATE>
   <SKDNAME></SKDNAME>
   <JOBNAME></JOBNAME>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

$JOB:START​

The $JOB:START event triggers SAM to disregard all dependencies and start the job immediately. This event is invalid for jobs that are in a Skipped status.

Syntax:

$JOB:START,<schedule date>,<schedule name>,<job name>

Parameters:

  • <schedule date>: The date of the Daily schedule containing the job
  • <schedule name>: The name of the schedule containing the job
  • <job name>: The name of the job on which to run command in the Daily schedule

Required Privileges:

  • Start Jobs

XML Syntax:

<EVENT>
   <TYPE>JOB</TYPE>
   <ACTION>START</ACTION>
   <SKDDATE></SKDDATE>
   <SKDNAME></SKDNAME>
   <JOBNAME></JOBNAME>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

$JOB:TRACK​

The $JOB:TRACK event tracks user-submitted jobs on the IBM i, MCP, and z/OS platforms. This event is only passed between the agent and the SAM. By default, this event must be submitted to an active schedule, or the event is rejected.

EXCEPTION

The AdHoc Schedule

Although a pre-defined job on a named OpCon schedule enables more job dependencies and other job control features, it may sometimes be convenient to perform simple job tracking without a pre-defined and active schedule. For those cases the AdHoc schedule may be specified by the agents.

The AdHoc schedule supports the following characteristics:

  • The schedule is dynamically added to the Daily Tables when SAM-SS is informed of a job on the schedule that is to be tracked.
  • Once active, the schedule remains open until midnight when it is allowed to go to a completed state. All jobs on the schedule must finish before the schedule closes.

If jobs to be tracked are on named schedules, those schedules must be built and must be active in the Daily Tables for the SAM-SS to track or queue the job(s). However, the jobs to be tracked should not be allowed to be built in advance when the schedule is built. Tracked jobs will appear on named schedules only when the agents send one of the job tracking external event commands, including $JOB:TRACK and $JOB:QUEUED. See specific notes about Job Tracking in the individual agent references listed below.

Pre-defined tracked jobs can be controlled by the multi-instance box to prevent or allow duplicate jobs.

info

Provided here are references for implementing the Job Tracking concept.

For IBM i, visit the following section in the IBM i Agent online help: Overview of Job Tracking

For MCP, visit the following section in the MCP Agent online help: Using SMA/Announce

For z/OS, visit the following section in the Concepts online help: Tracking Externally Submitted Batch Job Events in OpCon

Parameters:

None

XML Syntax:

<EVENT>
   <TYPE>JOB</TYPE>
   <ACTION>TRACK</ACTION>
   <SKDDATE></SKDDATE>
   <SKDNAME></SKDNAME>
   <JOBNAME></JOBNAME>
   <FREQNAME></FREQNAME>
   <JOBPDATA></JOBPDATA>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

$JOB:UNDERREVIEW​

The$JOB:UNDERREVIEW event marks the job as Under Review.

Syntax:

$JOB:UNDERREVIEW,<schedule date>,<schedule name>,<job name>

Parameters:

  • <schedule date>: The date of the Daily schedule containing the job
  • <schedule name>: The name of the schedule containing the job
  • <job name>: The name of the job on which to run command in the Daily schedule

$MACHINE:MAXJOBS​

XML Syntax:

<EVENT>
   <TYPE>MACHINE</TYPE>
   <ACTION>MAXJOBS</ACTION>
   <MACHNAME></MACHNAME>
   <MACHMAX></MACHMAX>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

$MACHINE:STATUS​

The $MACHINE:STATUS event changes the communication status of a machine.

note

Placing a machine in a down state instructs the SAM to stop communicating with the specified machine. Jobs active on the specified machine run until completion.

Syntax:

$MACHINE:STATUS,<machine name>,<U/D/L>

Parameters:

  • <machine name>: An OpCon Machine Name
  • <U/D/L>: The requested machine state
    • U: Places the machine in an up state
    • D: Places the machine in a down state
    • L: Places the machine in a limited state (no job starts will be sent)

Required Privileges:

  • All Administrative Functions

XML Syntax:

<EVENT>
   <TYPE>MACHINE</TYPE>
   <ACTION>STATUS</ACTION>
   <MACHNAME></MACHNAME>
   <MACHSTATUS></MACHSTATUS>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

Notification Events​

$NOTIFY:COMMAND​

The $NOTIFY:COMMAND event runs a command.

note

This notification event is disabled on Linux. Events defined before Release 20.0.0 will be disabled.

Syntax:

$NOTIFY:COMMAND,<path and command to run>,\[workingdir\],<batch user>

Parameters:

  • <path and command to run>: Full path and name of the program to run as well as any arguments to be passed to it
  • [workingdir]: Working directory used by the program
  • <batch user>: The user with permissions to run the program

Required Privileges:

  • The submitting user must have access to the specified Batch User. No function privilege is required.

XML Syntax:

<EVENT>
   <TYPE>NOTIFY</TYPE>
   <ACTION>COMMAND</ACTION>
   <WINCOMMAND></WINCOMMAND>
   <WORKDIR></WORKDIR>
   <BATCHUSER></BATCHUSER>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

$NOTIFY:EMAIL​

The $NOTIFY:EMAIL event sends an SMTP mail message.

Syntax:

$NOTIFY:EMAIL,<to>,\[cc\],\[ccc\],<subject>,<message>,\[attachments\],\[exclude prefix information from header: Y/N\]

Parameters:

  • <to>: One or more email address (including distribution groups), separated by semicolons (;), to receive the message
  • [cc]: One or more email address (including distribution groups), separated by semicolons (;), to be copied on the message
  • [bcc]: One or more email address (including distribution groups), separated by semicolons (;), to be blind copied on the message
  • <subject>: The subject of the email
  • <message>: Defines a complete, detailed message in the body of the email. By default, no machine, schedule, or job information is passed with this notification
  • [attachments]: Defines the full UNC path to one or more attachments. This parameter is optional. Separate multiple attachments using pipes (|) (e.g., \\server1\file1|\\Server1\file2)
  • [exclude prefix information from header: Y/N]: Specifies whether to include all prefix (system-generated) information in the header of the notification. This parameter is optional
note

By default, this parameter is set to N (No). This means that the SMA Notify Handler will insert the system-generated information , which includes a Notification ID, before any other information in the message so users can look up the source of a notification. For more information, refer to Looking up Notification Sources in the Enterprise Manager online help.

XML Syntax:

<EVENT>
   <TYPE>NOTIFY</TYPE>
   <ACTION>EMAIL</ACTION>
   <MAILTO></MAILTO>
   <MAILCC></MAILCC>
   <MAILBCC></MAILBCC>
   <MAILSUBJ></MAILSUBJ>
   <MAILBODY></MAILBODY>
   <ATTACHMENTS>
       <ATTACH></ATTACH>
       <ATTACH></ATTACH>\...</ATTACHMENTS>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

$NOTIFY:LOG​

The $NOTIFY:LOG event logs a notification message to the Windows Event Log.

note

This notification event is disabled on Linux. Events defined before Release 20.0.0 will be disabled.

Syntax:

$NOTIFY:LOG,<severity>,<eventid>,<message>,\[event source\],\[exclude prefix information from header: Y/N\]

Parameters:

  • <severity>: The event severity to be placed in the Windows Event Log. Valid values are: I, W, and E. I is Informational, W is Warning, and E is Error.
  • <eventid>: The same Event ID used in the Notification Manager when defining an Windows Event Log notification. A third-party notification tool uses this number to process the notification.
  • <message>: Defines a complete, detailed message. By default, no machine, schedule, or job information is passed with this notification.
  • [event Source]: Defines a custom Source ID for OpCon to use when writing to the Windows Event Log.
  • [exclude prefix information from header: Y/N]: Specifies whether to include all prefix (system-generated) information in the header of the notification. This parameter is optional

XML Syntax:

<EVENT>
   <TYPE>NOTIFY</TYPE>
   <ACTION>LOG</ACTION>
   <LOGSEV></LOGSEV>
   <LOGID></LOGID>
   <LOGMSG></LOGMSG>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

$NOTIFY:NETSEND​

The $NOTIFY:NETSEND event sends a network pop-up message.

note

This notification event is disabled on Linux. Events defined before Release 20.0.0 will be disabled.

Syntax:

$NOTIFY:NETSEND,<machine>,<message>,\[exclude prefix information from header: Y/N\]

Parameters:

  • <machine>: A single machine to receive the network pop-up message
  • <message>: The message for the network window. Defines a complete, detailed message. By default, no machine, schedule, or job information is passed with this notification
  • [exclude prefix information from header: Y/N]: Specifies whether to include all prefix (system-generated) information in the header of the notification. This parameter is optional

XML Syntax:

<EVENT>
   <TYPE>NOTIFY</TYPE>
   <ACTION>NETSEND</ACTION>
   <NETMACH></NETMACH>
   <NETMSG></NETMSG>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

$NOTIFY:SNMP​

The $NOTIFY:SNMP event sends an SNMP trap to an SNMP Trap manager. The SMA Notify Handler must be configured for SNMP notifications.

note

This notification event is disabled on Linux. Events defined before Release 20.0.0 will be disabled.

Syntax:

$NOTIFY:SNMP,<severity>,<eventid>,<message>,\[exclude notification id from header: Y/N\]

Parameters:

  • <severity>: The SNMP severity for the SNMP trap. Valid values range from 1 to 5. 1 is Critical, 2 is Major, 3 is Minor, 4 is Warning, and 5 is Information
  • <eventid>: The same Event ID used in the Notification Manager when defining an SNMP notification. A third-party notification tool uses this number to process the notification
  • <message>: The SNMP trap's text. Defines a complete, detailed message. By default, no machine, schedule, or job information is passed with this notification
  • [exclude notification id from header: Y/N]: Specifies whether to include the Notification ID in the header of the notification. This parameter is optional

XML Syntax:

<EVENT>
   <TYPE>NOTIFY</TYPE>
   <ACTION>SNMP</ACTION>
   <SNMPTRAP></SNMPTRAP>
   <SNMPID></SNMPID>
   <SNMPMSG></SNMPMSG>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

$NOTIFY:SPOAL​

The $NOTIFY:SPOAL event sends and AL event report to SPO. The SMA Notify Handler must be configured for SPO notifications.

note

This notification event is disabled on Linux. Events defined before Release 20.0.0 will be disabled.

Syntax:

$NOTIFY:SPOAL,<text\>,<severity>,<alarmid>,<alarmqual>,\[exclude notification id from header: Y/N\]

Parameters:

  • <text>:The text for the AL event report. To send the default <lsam_mach_name> <schedule_date> <schedule_name> <job_name>, do not type any text and enter a comma to indicate the start of the next parameter
  • <severity>: The SPO severity. Valid values are Critical, Major, Minor, Warning, Informational, Indeterminate, and Clear
  • <alarmid>: The SPO Alarmid
  • <alarmqual>: The SPO Alarmqual
  • [exclude notification id from header: Y/N]: Specifies whether to include the Notification ID in the header of the notification. This parameter is optional

XML Syntax:

<EVENT>
   <TYPE>NOTIFY</TYPE>
   <ACTION>SPOAL</ACTION>
   <SPOALARMMSG></SPOALARMMSG>
   <SPOSEV></SPOSEV>
   <SPOALARMID></SPOALARMID>
   <SPOALARMQUAL></SPOALARMQUAL>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

$NOTIFY:SPOCO​

The $NOTIFY:SPOCO event sends a CO event report to SPO. The SMA Notify Handler must be configured for SPO notifications.

note

This notification event is disabled on Linux. Events defined before Release 20.0.0 will be disabled.

Syntax:

$NOTIFY:SPOCO,<instance>,<command>

Parameters:

  • <instance>: The SPO instance to process the command
  • <command>: The command for SPO to process

XML Syntax:

<EVENT>
   <TYPE>NOTIFY</TYPE>
   <ACTION>SPOCO</ACTION>
   <SPOINST></SPOINST>
   <SPOCOMMAND></SPOCOMMAND>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

$NOTIFY:TASKS​

The $NOTIFY:TASKS event sends an SMTP mail message (or multiple if needed) with the email body containing:

  • Task Counts for <Customer Name from License File>: This section contains a comma-separated list of:
    • Period: The date or month for which the report processed
    • agent Type: The type of agent that processed the tasks
    • Number of Days with tasks: The number of days on which tasks processed in the period
    • Total Tasks in Period: The total number of tasks that processed in the selected period
    • Avg Tasks per Day: The average number of tasks that processed each day in the selected period
    • Following the first list, there is a comma-separated list of:
      • Exceeded Max Date: The date on which the total number of tasks per day was exceeded
      • agent Type: The agent type that processed too many tasks
      • Total Tasks: The total number of tasks that were processed by the agent Type on the date the tasks were exceeded
  • Tasks Counted for SMA Utility Jobs: In a comma-separated list, this section contains the list of jobs that were not counted against the task based license:
    • Period: The date or month for which the report processed
    • agent Type: The type of agent that processed the tasks
    • Number of Days with tasks: Within the agent Type, the number of days on which tasks processed in the period
    • Total Tasks in Period: Within the agent Type, the total number of tasks that processed in the selected period
    • Avg Tasks per Day: Within the agent Type, the average number tasks that processed each day in the selected period
  • Tasks Counts by Department: This section contains a list of tasks by Department in a comma-separated list of:
    • Period: The date or month for which the report processed
    • Dept Name: The Department in which the tasks processed
    • Number of Days with tasks: Within the Department, the number of days on which tasks processed in the selected period
    • Total Tasks in Period: Within the Department, the total number of tasks that processed in the selected period
    • Avg Tasks per Day: Within the Department, the average number of tasks that processed each day in the selected period

Syntax:

$NOTIFY:TASKS,<To>,<Cc>,<Bcc>,<Subject>,<Date Desired>

Parameters:

  • <To>: One or more email address (including distribution groups), separated by semicolons (;), to receive the message
    • To generate specific task based license reporting information to send to Continuous, enter the license email address for your Continuous sales and support office:
    • If the Send Email to SMA Office value in the Global Options is set to Disabled, SAM will write the license reporting information to the SAM.log file only, and no email is sent because of the event
    • If the Send Email to SMA Office value in the Global Options has and Continuous office selected, the license reporting information will be emailed to Continuous
  • <Cc>: One or more email address (including distribution groups), separated by semicolons (;), to be copied on the message
  • <Bcc>: One or more email address (including distribution groups), separated by semicolons (;), to be blind copied on the message
  • <Subject>: The subject of the email
  • <Date Desired>: Define a single date or a month name defined using the syntax recognized by the regional settings of the user running SMA Service Manager
<EVENT>
   <TYPE>NOTIFY</TYPE>
   <ACTION>TASKS</ACTION>
   <MAILTO></MAILTO>
   <MAILCC></MAILCC>
   <MAILBCC></MAILBCC>
   <MAILSUBJ></MAILSUBJ>
   <DATEDESIRED></DATEDESIRED>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

$NOTIFY:TEXTMSG​

The $NOTIFY:TEXTMSG event sends a text message.

Syntax:

$NOTIFY:TEXTMSG,<to>,<message>,\[exclude notification id from header: Y/N\]

Parameters:

  • <to>: A single SMTP email address to an SMS-capable device
  • <message>: The notification message's text. Defines a complete, detailed message. By default, no machine, schedule, or job information is passed with this notification
  • [exclude notification id from header: Y/N]: Specifies whether to include the Notification ID in the header of the notification. This parameter is optional

XML Syntax:

<EVENT>
   <TYPE>NOTIFY</TYPE>
   <ACTION>TEXTMSG</ACTION>
   <TEXTTO></TEXTTO>
   <TEXTMSG></TEXTMSG>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

For each of the property events, the specified Property Name must completely identify the property. The syntax for identifying a property depends on whether the property is an OpCon Instance, Machine Instance, Schedule Instance, or Job Instance property. Machine, Schedule, and Job Instance properties have optional qualifiers to specifically identify an instance. For additional information, refer to Fully Qualified Property Name Syntax in the Concepts online help. For more on creating valid property definitions, refer to Defining Properties in the Concepts online help.

note

If the property name or any of the qualifiers contain periods (.), square brackets ( [ or ] ), or curly brackets ( { or } ) in their names, the name must be enclosed in quotes to preserve the syntax of the property name. For example, a JI property could look like this:

JI."File.Name"."08.01.2010"."Sched[Name]"."Job{Name}"

$PROPERTY:ADD​

The $PROPERTY:ADD event adds a new property (of any type) to the database with the value specified. If the event attempts to add a property that already exists, the event merely sets the property value.

note

This replaced $TOKEN:ADD.

Syntax:

$PROPERTY:ADD,<property name>,<initial value>

Parameters:

  • <property name>: The property name
  • <initial value>: The initial value given to the property name
Example

For a $PROPERTY:ADD event attached to a Schedule or Job (internal event), the following are valid for adding a property to a subschedule whose parent schedule is a multi-instance schedule:

$PROPERTY:ADD,JI.FileName.[[$SCHEDULE DATE]]."

Schedule.Name_InstanceName[subSched]".Job Name,Value - or -

$PROPERTY:ADD,JI.FileName.[[$SCHEDULE DATE]].

[[$SCHEDULE NAME]]_InstanceName[subSched].Job Name,Value

For an External $PROPERTY:ADD event, the following would be valid:

$PROPERTY:ADD,JI.FileName.[[$DATE]]."Schedule.Name_InstanceName

[SubSched]".Job Name,Value - or -

$PROPERTY:ADD,JI.FileName.SpecificDate.Schedule.Name_InstanceName [SubSched].Job Name,Value

Required Privileges:

  • Manage Global Properties

XML Syntax:

<EVENT>
   <TYPE>PROPERTY</TYPE>
   <ACTION>ADD</ACTION>
   <PROPNAME></PROPNAME>
   <PROPVALUE></PROPVALUE>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

$PROPERTY:DELETE​

The $PROPERTY:DELETE event deletes an existing property from the database.

note

This replaced $TOKEN:DELETE.

Syntax:

$PROPERTY:DELETE,<property name

Parameters:

  • <property name>: The property name

Required Privileges:

  • Maintain Global Properties

XML Syntax:

<EVENT>
   <TYPE>PROPERTY</TYPE>
   <ACTION>DELETE</ACTION>
   <PROPNAME></PROPNAME>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

$PROPERTY:SET​

The $PROPERTY:SET event sets the value of any existing property to the specified value.

note

This replaced $TOKEN:SET.

note

If a $PROPERTY:SET event is created for a global property that is encrypted, then the value of the property will get updated and stored as a clear text value and NOT as an encrypted value.

Syntax:

$PROPERTY:SET,<property name>,<value>

Parameters:

  • <property name>: The property name
  • <value>: The value of the property defined

Required Privileges:

  • Maintain Global Properties

XML Syntax:

<EVENT>
   <TYPE>PROPERTY</TYPE>
   <ACTION>SET</ACTION>
   <PROPNAME></PROPNAME>
   <PROPVALUE></PROPVALUE>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

SAM Log Events​

$CONSOLE:DISPLAY​

The $CONSOLE:DISPLAY event writes a message to the SAM.log file.

Syntax:

$CONSOLE:DISPLAY,<message>

Parameters:

  • <message>: A user-defined message

XML Syntax:

<EVENT>
   <TYPE>CONSOLE</TYPE>
   <ACTION>DISPLAY</ACTION>
   <MSG></MSG>
   <USERNAME>SYSTEM</USERNAME>
   <USERPWD>MESSAGE</USERPWD>
</EVENT>

For all schedule-related events, only valid schedule status changes are allowed. For more information, refer to Schedule Statuses in the Concepts online help.

$SCHEDULE:BUILD​

If the SMA_SKD_BUILD job exists on the AdHoc schedule in the Master and the event fails for some reason, the SAM will process any events defined on the SMA_SKD_BUILD job for the Failed status. The job will not actually be added to the Daily for processing. Only the notifications and other events associated with "Build Failure" will be processed.

Syntax:

$SCHEDULE:BUILD,<schedule date>,<schedule name>,\[log file\],<Y/N>,\[schedule instance property definitions\],\[Named Instance to build\]

Parameters:

  • <schedule date>: The date for which to build the schedule
note

By default, if the date resolves to a date in the past, the schedule will be built On Hold.

  • <schedule name>: The name of the schedule to build

  • [log file]: An optional argument specifying the path and/or file name for creating a detailed log file of the build. The default path and filename is: <Output Directory>\SAM\Log\SMASchedMan\ScheduleName_Build_ScheduleDate_RequestID.log

  • <Y/N>: Determines whether to overwrite an existing schedule or not. Valid entries include:

    • Y: Overwrite
    • N: Do Not Overwrite (N is the default)

  • [schedule instance property definitions]: Defines Schedule Instance Properties for the schedule being built. This parameter is optional. If not specified, the comma preceding this parameter is not required. For information on creating valid property definitions, refer to Defining Properties in the Concepts online help. Use the following syntax to define properties in the event:

    PropertyName1=value;PropertyName2=value,etc...
Example

$SCHEDULE:BUILD,[[$DATE]],ProcessCreditCards,,Y,StoreNumber=2682;FileDate=123456,batchuser,batchpassword

  • If the schedule has Schedule Instance definitions, and all instances should be built, do not specify Schedule Instance Property Definitions on the event. By default, all predefined instances will build
  • If the schedule is configured to "Build an instance for each machine in Machine Group," and the build is intended for only one specific Machine, specify the machine by adding a property named MACHINENAME as the first property definition
Example

$SCHEDULE:BUILD,[[$DATE]],NightlyBackup,,Y,MACHINENAME=WinServer2,batchuser,batchpassword

  • [Named Instance to build]: Defines the named instance of the schedule to build. This parameter is optional. If not specified, the comma preceding this parameter is not required. For information on referencing valid named instances, refer to Named Schedule Instances in the Concepts online help. Use the following syntax to define the instance name in the event:

    InstanceName=value
Example

$SCHEDULE:BUILD,[[$DATE]],ProcessCreditCards,,Y,,InstanceName=WinServer2

  • If the instance name is specified in the event string, SMASchedMan will build the named instance of the schedule, copy all properties defined for that instance, and copy any user-defined properties in the event string
  • If the instance name specified in the event string, but the schedule being built is not associated with any named instances, then the build will fail
  • If no instance name is specified in the event and the schedule is associated with named instances, then all named instances will get built (with any user-defined properties added to each instance)

Required Privileges:

  • Build Daily Schedules

XML Syntax:

<EVENT>
   <TYPE>SCHEDULE</TYPE>
   <ACTION>BUILD</ACTION>
   <SKDDATE></SKDDATE>
   <SKDNAME></SKDNAME>
   <OVERWRITE></OVERWRITE>
   <PROPERTIES>
       <PROPERTY></PROPERTY>
       <PROPERTY></PROPERTY>\...</PROPERTIES>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

$SCHEDULE:BUILDHLD​

If the SMA_SKD_BUILD job exists on the AdHoc schedule in the Master and the event fails for some reason, the SAM will process any Events defined on the SMA_SKD_BUILD job for the Failed status. The job will not actually be added to the Daily for processing. Only the notifications and other events associated with "Build Failure" will be processed.

Syntax:

$SCHEDULE:BUILDHLD,<schedule date>,<schedule name>,\[log file\], <Y/N>,\[schedule instance property definitions\],\[Named Instance to build\]

Parameters:

  • <schedule date>: The date for which to build the schedule

  • <schedule name>: The name of the schedule to build

  • [log file]: An optional argument specifying the path and/or file name for creating a detailed log file of the build. The default path and filename is: <Output Directory>\SAM\Log\SMASchedMan\ScheduleName_Build_ScheduleDate_RequestID.log

  • <Y/N>: Determines whether to overwrite an existing schedule or not. Valid entries include:

    • Y: Overwrite
    • N: Do Not Overwrite (N is the default)

  • [schedule instance property definitions]: Defines Schedule Instance Properties for the schedule being built. This parameter is optional. If not specified, the comma preceding this parameter is not required. For information on creating valid property definitions, refer to Defining Properties in the Concepts online help. Use the following syntax to define properties in the event:

    PropertyName1=value;PropertyName2=value,etc...
Example

$SCHEDULE:BUILDHLD,[[$DATE]],ProcessCreditCards,,Y,StoreNumber=2682;FileDate=123456,batchuser,batchpassword

  • If the schedule has Schedule Instance definitions, and all instances should be built, do not specify Schedule Instance Property Definitions on the event. By default, all predefined instances will build
  • If the schedule is configured to "Build an instance for each machine in Machine Group," and the build is intended for only one specific Machine, specify the machine by adding a property named MACHINENAME as the first property definition
Example

$SCHEDULE:BUILDHLD,[[$DATE]],NightlyBackup,,Y,MACHINENAME=WinServer2,batchuser,batchpassword

  • [Named Instance to build]: Defines the named instance of the schedule to build. This parameter is optional. If not specified, the comma preceding this parameter is not required. For information on referencing valid named instances, refer to Named Schedule Instances in the Concepts online help. Use the following syntax to define the instance name in the event:

    InstanceName=value
Example

$SCHEDULE:BUILDHLD,[[$DATE]],ProcessCreditCards,,Y,,InstanceName=WinServer2

  • If the instance name is specified in the event string, SMASchedMan will build the named instance of the schedule, copy all properties defined for that instance, and copy any user-defined properties in the event string
  • If the instance name specified in the event string, but the schedule being built is not associated with any named instances, then the build will fail
  • If no instance name is specified in the event and the schedule is associated with named instances, then all named instances will get built (with any user-defined properties added to each instance)

Required Privileges:

  • Build Daily Schedules

XML Syntax:

<EVENT>
   <TYPE>SCHEDULE</TYPE>
   <ACTION>BUILDHLD</ACTION>
   <SKDDATE></SKDDATE>
   <SKDNAME></SKDNAME>
   <OVERWRITE></OVERWRITE>
   <PROPERTIES>
       <PROPERTY></PROPERTY>
       <PROPERTY></PROPERTY>\...</PROPERTIES>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

$SCHEDULE:CHECK​

If the SMA_SKD_CHECK job exists on the AdHoc schedule in the Master and the event fails for some reason, the SAM will process any Events defined on the SMA_SKD_CHECK job for the Failed status. The job will not actually be added to the Daily for processing. Only the notifications and other events associated with "Check Failure" will be processed.

Syntax:

$SCHEDULE:CHECK,<schedule date>,<schedule name>,\[log file\],<Y/N/S>

Parameters:

  • <schedule date>: The date to check the schedule on
  • <schedule name>: The exact schedule name to check. To check all instances of a multi-instance schedule, specify the master schedule name
  • [log file]: An optional argument specifying the path and/or file name for creating a detailed log file of the check. The default path and filename is: <Output Directory>\SAM\Log\SMASchedMan\ScheduleName_RequestID.log
  • <Y/N/S>: Indicates if circular dependencies are included in the process. Valid values are:
    • Y: Check for circular dependencies
    • N: Do not check for circular dependencies (N is the default)
    • S: Perform a simple check which skips after, conflict, and circular dependencies

Required Privileges:

  • Build Daily Schedules

XML Syntax:

<EVENT>
   <TYPE>SCHEDULE</TYPE>
   <ACTION>CHECK</ACTION>
   <SKDDATE></SKDDATE>
   <SKDNAME></SKDNAME>
   <CIRCCHECK></CIRCCHECK>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

$SCHEDULE:CHECKALL​

  • If the SMA_SKD_CHECK job exists on the AdHoc schedule in the Master and the event fails for some reason, the SAM will process any Events defined on the SMA_SKD_CHECK job for the Failed status. The job will not actually be added to the Daily for processing. Only the notifications and other events associated with "Check Failure" will be processed
  • If the SMA_SKD_CHECK job does not exist, the check request is inserted directly into the database for processing, and notification will not be sent if the process fails

Syntax:

$SCHEDULE:CHECKALL,<schedule date>,\[log file\],<Y/N/S>

Parameters:

  • <schedule date>: The date to check the schedule on
  • [log file]: An optional argument specifying the path and/or file name for creating a detailed log file of the check. The default path and filename is: <Output Directory>\SAM\Log\SMASchedMan\ScheduleDate_RequestID.log
  • <Y/N/S>: Indicates if circular dependencies are included in the process. Valid values are:
    • Y: Check for circular dependencies
    • N: Do not check for circular dependencies (N is the default)
    • S: Perform a simple check which skips after, conflict, and circular dependencies

Required Privileges:

  • Build Daily Schedules

XML Syntax:

<EVENT>
   <TYPE>SCHEDULE</TYPE>
   <ACTION>CHECKALL</ACTION>
   <SKDDATE></SKDDATE>
   <CIRCCHECK></CIRCCHECK>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

$SCHEDULE:CANCEL​

The $SCHEDULE:CANCEL event cancels all jobs on the schedule.

Syntax:

$SCHEDULE:CANCEL,<schedule date>,<schedule name>

Parameters:

  • <schedule date>: A date entered in the same date format as the syntax recognized by the regional settings of the user running SMA Service Manager
  • <schedule name>: An OpCon Schedule Name

Required Privileges:

  • Cancel Jobs

XML Syntax:

<EVENT>
   <TYPE>SCHEDULE</TYPE>
   <ACTION>CANCEL</ACTION>
   <SKDDATE></SKDDATE>
   <SKDNAME></SKDNAME>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

$SCHEDULE:CLOSE​

The $SCHEDULE:CLOSE event closes the schedule, marking it as Completed.

Syntax:

$SCHEDULE:CLOSE, schedule-date, schedule-name

Parameters:

  • <schedule date>: A date entered in the same date format as the syntax recognized by the regional settings of the user running SMA Service Manager
  • <schedule name>: An OpCon Schedule Name

Required Privileges:

  • Cancel Jobs

XML Syntax:

<EVENT>
   <TYPE>SCHEDULE</TYPE>
   <ACTION>CLOSE</ACTION>
   <SKDDATE></SKDDATE>
   <SKDNAME></SKDNAME>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

$SCHEDULE:DELETE​

The $SCHEDULE:DELETE event causes the schedule to be deleted from a specific schedule date.

If the SMA_SKD_DELETE job exists on the AdHoc schedule in the Master and the event fails for some reason, the SAM will process any Events defined on the SMA_SKD_delete job for the Failed status. The job will not actually be added to the Daily for processing. Only the notifications and other events associated with "Delete Failure" will be processed.

Syntax:

$SCHEDULE:DELETE,<schedule date>,<schedule name>,\[log file\]

Parameters:

  • <schedule date>: The date from which to delete the schedule
  • <schedule name>: The exact schedule name to delete. To delete all instances of a multi-instance schedule, specify the master schedule name
  • [log file]: An optional argument specifying the path and/or file name for creating a detailed log file of the delete. The default path and filename is: <Output Directory>\SAM\Log\SMASchedMan\ScheduleName_Delete_ScheduleDate_RequestID.log

Required Privileges:

  • Delete Daily Schedules

XML Syntax:

<EVENT>
   <TYPE>SCHEDULE</TYPE>
   <ACTION>DELETE</ACTION>
   <SKDDATE></SKDDATE>
   <SKDNAME></SKDNAME>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

$SCHEDULE:HOLD​

The $SCHEDULE:HOLD event places the schedule On Hold; no additional jobs are initiated until the schedule is released. If there are subschedules under the defined schedule and they are in a status of In Process or Completed, those subschedules are placed in a status of Parent Hold.

Syntax:

$SCHEDULE:HOLD,<schedule date>,<schedule name>

Parameters:

  • <schedule date>: A date entered in the same date format as the syntax recognized by the regional settings of the user running SMA Service Manager
  • <schedule name>: An OpCon Schedule Name

Required Privileges:

  • Hold Schedules

XML Syntax:

<EVENT>
   <TYPE>SCHEDULE</TYPE>
   <ACTION>HOLD</ACTION>
   <SKDDATE></SKDDATE>
   <SKDNAME></SKDNAME>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

$SCHEDULE:RELEASE​

The $SCHEDULE:RELEASE event releases the schedule; the SAM will resume processing of the schedule. If there are subschedules under the defined schedule and they are in a status of Parent Hold, those subschedules will also be released.

Syntax:

$SCHEDULE:RELEASE,<schedule date>,<schedule name>

Parameters:

  • <schedule date>: A date entered in the same date format as the syntax recognized by the regional settings of the user running SMA Service Manager
  • <schedule name>: An OpCon Schedule Name

Required Privileges:

  • Release Schedules

XML Syntax:

<EVENT>
   <TYPE>SCHEDULE</TYPE>
   <ACTION>RELEASE</ACTION>
   <SKDDATE></SKDDATE>
   <SKDNAME></SKDNAME>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

$SCHEDULE:START​

The $SCHEDULE:START event causes the SAM to start processing the schedule immediately, ignoring the defined start date and time of the schedule. If there are subschedules under the defined schedule and they are in a status of Parent Hold, those subschedules will also be started.

Syntax:

$SCHEDULE:START,<schedule date>,<schedule name>

Parameters:

  • <schedule date>: A date entered in the same date format as the syntax recognized by the regional settings of the user running SMA Service Manager
  • <schedule name>: An OpCon Schedule Name

Required Privileges:

  • Force Start Schedule

XML Syntax:

<EVENT>
   <TYPE>SCHEDULE</TYPE>
   <ACTION>START</ACTION>
   <SKDDATE></SKDDATE>
   <SKDNAME></SKDNAME>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

$THRESHOLD:SET​

The $THRESHOLD:SET event sets the threshold to the value specified. If a plus (+) or minus (-) sign is used in front of the value, the Threshold is incremented or decremented accordingly.

Syntax:

$THRESHOLD:SET,<threshold name>,<value>

Parameters:

  • <threshold name>: An OpCon Threshold Name
  • <value>: An update value for the threshold

Required Privileges:

  • Maintain Threshold/Resources

XML Syntax:

<EVENT>
   <TYPE>THRESHOLD</TYPE>
   <ACTION>SET</ACTION>
   <THRESHNAME></THRESHNAME>
   <THRESHVALUE></THRESHVALUE>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

$RESOURCE:SET​

The $RESOURCE:SET event changes the Max Resources for the Resource to the value specified.

Syntax:

$RESOURCE:SET,<resource name>,<value>

Parameters:

  • <resource name>: An OpCon Resource Name
  • <value>: The maximum value for the resource

Required Privileges:

  • Maintain Thresholds/Resources

XML Syntax:

<EVENT>
   <TYPE>RESOURCE</TYPE>
   <ACTION>SET</ACTION>
   <RESOURCENAME></RESOURCENAME>
   <RESOURCEVALUE></RESOURCEVALUE>
   <USERNAME></USERNAME>
   <USERPWD></USERPWD>
</EVENT>

Configuration Options​

The following table consolidates the parameters used by the events on this page. For the parameters that apply to a specific event, refer to that event's Parameters list above.

SettingWhat It DoesDefaultNotes
<calendar name>The calendar name to which to add the dates——
<calendar dates>A semicolon (;) separated list of dates to add to the calendar—Dates must use a date syntax recognized by the regional settings of the user running SMA Service Manager
<schedule date>The date of the Daily schedule containing the job——
<schedule name>The name of the schedule containing the job——
<job name>The name of the job to affect on in the Daily schedule——
<machine group name>The new Machine Group name for the job to use in the Daily schedule——
<minutes>The number of minutes to set the Max Run Time for the job to use in the Daily schedule—Valid range: 1–32767
<SAM priority>The new SAM priority value for the job to use in the Daily schedule—Valid range: 0 (lowest) to 32767 (highest)
<tags>A semicolon (;) separated list of tags to add to the Daily job——
<batch user>The name of the new Batch User account for the job to use in the Daily schedule——
<frequency name>The frequency name of the job to associate the Build Status with in the Master schedule——
<build state>The build status to set for the frequency on the job in the Master—Valid values: D (Disable Frequency / Disabled), R (Released), S (To Be Skipped / Skipped), N (Do Not Schedule / Not Scheduled), H (On Hold / Held)
<resource name>The name of the resource to delete——
<old resource name>The current name of the resource to rename——
<new resource name>The new name for the resource—Maximum 20 characters; cannot contain single quotes
<threshold name>The name of the threshold to delete——
<old threshold name>The current name of the threshold to rename——
<new threshold name>The new name for the threshold—Maximum 20 characters; cannot contain single quotes
[job instance property definitions]Defines properties and values for the job being added——
[reopen schedule: Y/N]Indicates whether a completed parent schedule is reopenedvalue will be set to NY: reopen a closed parent schedule so newly added jobs run (overrides the "Allow Job Events to Restart Schedules" Server Option); N: do not reopen — newly added jobs remain in a Qualifying state
[apply exceptions: Y/N]Indicates whether exceptions are applied to the job when it is addedvalue will be set to NY: apply exceptions to the job; N: do not apply exceptions. If not specified, defaults to N
[Restart Step (optional)]Specifies whether to restart the job on a pre-configured step setting—Optional; supported for SAP R/3 and CRM, SAP BW, UNIX, and z/OS. Valid values depend on the host system (see the $JOB:RESTART parameters above)
<machine name>An OpCon Machine Name——
<U/D/L>The requested machine state——
<path and command to run>Full path and name of the program to run, plus any arguments to be passed to it——

FAQs​

Q: What categories of events does OpCon support?

OpCon events are organized by target: Job events control individual job behavior (add, hold, restart, cancel), Schedule events control schedule state (build, hold, release, cancel), Threshold/Resource events update numeric values, Property events manage user-defined properties, and Machine events control agent communication.

Q: Can event parameters use tokens to pass dynamic values?

Yes. Event parameters support OpCon tokens — property values enclosed in double brackets (e.g., [[$SCHEDULE DATE]]) — which the SAM resolves before processing the event.

Q: How are events passed to the SAM from external sources?

External events are passed by creating an ASCII file with the event string, User Login ID, and event password, then placing it in the SAM's MSGIN directory. Some agents can also send events directly to the SAM using a platform-specific command.

Glossary​

MSGIN: A directory monitored by an agent for incoming OpCon event files. Placing a properly formatted event file in MSGIN causes the agent to forward it to SAM for processing.

SMAServMan (SMA Service Manager): Manages the starting, stopping, and restarting of all OpCon server programs. Monitors configured applications and restarts them automatically if they fail unexpectedly.

SMA Notify Handler: Processes notifications triggered by Machine, Schedule, and Job status changes. Can send emails, text messages, Windows Event Log entries, SNMP traps, and SPO notifications.

SAM-SS (SAM and Supporting Services): The collective term for the OpCon server-side processing programs: SAM, SMANetCom, SMA Notify Handler, SMA Request Router, and SMA Start Time Calculator.

SAM (Schedule Activity Monitor): The logical processor for OpCon workflow automation. SAM monitors schedule and job start times, dependencies, and user commands to determine job execution timing, and processes OpCon events.

Agent: An agent installed on a target platform that runs jobs in the native language of that platform and communicates results back to SAM via SMANetCom over TCP/IP.

Enterprise Manager (EM): OpCon's rich client graphical user interface for Windows and Linux, used to define schedules and jobs, manage automation data, and perform operational tasks.

Subschedule: A schedule that runs as a child process within a Container job, allowing hierarchical, nested workflow automation where a parent schedule can trigger and monitor an entire child schedule.