An job has a sync object assigned to it that has two states, READY and LOCKED. When the sync is in locked, the object should not run but should wait for the sync to go to READY. Multiple objects use the same sync.
At the same time the job also has Allowed simultaneous executions set to 1, otherwise abort. This job runs every 5 minutes.
The expectation is that when the job is waiting for sync, the next task should be aborted with status:
FAULT_ALREADY_RUNNING - task is already running.
or ENDED_JP_ABEND - not executed due to abnormal Workflow end in case of a workflow
and details:
U00011174 Task 'JOBS.NAME' (RunID '[runid]') aborted because max. parallel condition does not allow further execution.
Instead, when the sync object is set to LOCKED, the task goes to a Waiting for Sync which can cause hundreds of this task in Waiting for sync instead of cancelling.
This can apply to any type of task that can use sync objects or max executions, such as JOBP or Workflow as well.
Version: 21.0, 24.x
This is by design
This behavior is by design. This is discussed in the documentation under Execution stages. Sync objects are checked in Step 7 of the Generation Stage (second stage) of executions and resources are checked in Step 2 of the Processing Stage (third stage) of executions. This is why workflow a is not aborting even though there are no resources available for it.
There are numerous other ways to accomplish the requirements put forward above. One example is:
Place the JOBS object into a worklflow. Put the max simultaneous executions onto the workflow rather than the job. Keep the sync object on the job. This way the workflow will be cancelled due to maximum simultaneous executions before the sync object is checked on the job.