Workflows unexpectedly enter a blocked state when a job or task finishes with an ENDED_LOST status. Even if task-level post-conditions (such as ANY_ABEND) are configured to handle the error or modify the status, the workflow ignores these conditions and blocks.
Version: ALL
This is by design. The blocking behavior is governed by a specific system variable located in the UC_HOSTCHAR_DEFAULT - Host Characteristics object.
Within this variable, there is a setting called BLOCK_ON_LOST.
What it does: This entry explicitly defines the action a workflow should take if one of its jobs changes its status to ENDED_LOST (System Return Code 1815).
Default Value: The default value out-of-the-box is YES.
Because this is a global host-level configuration, when BLOCK_ON_LOST is set to YES, the engine is hardcoded to automatically block the workflow the moment the job registers as ENDED_LOST. This system-level rule preempts task-level Post Conditions, which is why the workflow blocks even though your ANY_ABEND postcondition correctly triggers and resolves.
To prevent workflows from automatically blocking and instead allow your Post Conditions and dependencies to drive the logic, you need to change this variable:
Go to Client 0000.
Open your Host Characteristics variable (UC_HOSTCHAR_DEFAULT or your custom UC_HOSTCHAR_<SUFFIX> if you are using specific agent configurations).
Locate the BLOCK_ON_LOST key.
Change the value from YES to NO.
Changing this to NO instructs the workflow not to automatically block on ENDED_LOST. This will allow your ANY_ABEND postcondition and other dependency settings to successfully govern what happens next in the workflow without requiring a manual unblock. No agent restart is required for this change to take effect.
More information can be found in the documentation under UC_HOSTCHAR_DEFAULT => BLOCK_ON_LOST