Deactivating tasks

[Michael A. Lowry]

We have an automated clean-up process that deletes old objects. As a part of this, a Java program lists active tasks associated with an object. It uses the UC4 Java Application Interface and direct queries of the UC4 DB for this purpose.

Until now, we have been operating under the assumption that active tasks with a status code of 1800 or greater can be deactivated immediately without canceling them first, and that active tasks with a status code less than 1800 must be cancelled before they can be deactivated. We have learned however that there are many situations that can prevent a task from being deactivated. For example, we have discovered that a task cannot be deactivated if it has a parent workflow that is still active. Perhaps there are other conditions that can prevent deactivation. Perhaps there exist status codes greater than 1800, jobs of which must be cancelled prior to deactivation.

Moreover, we would like to get a more complete understanding of the criteria that determine whether a task can be deactivated or not, and how to handle the situations where an obstacle prevents task deactivation.

Has anyone else run into this challenge before? How do you handle automatically deactivating a list of objects? If you have a long list of objects of many different types, is there a preferred order in which they should be deactivated? E.g., is it best to deactivate JOBP objects first, and then the other types of objects? Is it necessary to check the status of all child tasks first? Alternatively, has anyone tried parsing the messages returned by DeactivateTask, to make an intelligent system capable of handling all of the obstacles that can prevent task deactivation?

Thanks in advance!

[Michael A. Lowry]

By the way, we discovered a limitation of ActivityList and TaskFilter. It is not possible using these classes to list all of the active tasks of a given object if those tasks have aliases. To work around this limitation, we use this SQL query:

select EH_AH_Idnr, EH_Alias, EH_Name, EH_OType, EH_status from EH where EH_Name = 'object_name';

This returns a list of all of the active tasks associated with the object object_name, even if those tasks have an alias.

[Michael A. Lowry]

I would also be interested to know the criteria that determine whether a running task can be cancelled, and the various obstacles that can prevent canceling a task. For example, attempting to use recursive cancel on a running EVNT object results in an error:

1541
task CMN.SCHEDULING.SOD.FILE_WATCHER_LOAD_CASH_POOL_RATES.FILE with status state_running found error: xml request returns message Runtime error in object 'XCANCEL_ALL(ACT)', line '00005'. CancelType ALL only available for ObjectType JSCH, JOBP, JOBG. (message nr: 20839) error: xml request returns message Cannot deactivate task with RunID '0022624082', invalid status for deactivation. (message nr: 11161)

[Michael A. Lowry]

I have an update. I decided against implementing automatic cancellation of tasks in the deployment program. Instead, it will now create the object cleanup list and check for associated running tasks before any objects have been loaded or replaced. If any running tasks are found for objects that whould be cleaned up, the deployment will be aborted and the deploying user notified. This way we avoid the possible situation wherein a batch has some old objects and some new, and multiple running instances of what are essentially the same objects. (Obviously this would only happen if someone deployed an object — e.g., from DEV to PROD — and later deployed a renamed version of the same object while the old one was still running. This may seem unlikely, but I’m sure it would eventually happen.)

The pre-deployment check for running tasks will help us to enforce the policy of ensuring that our batch developers deactivate tasks for old objects before they deploy new versions of these objects.

The next challenge I’m working on is coming up with a general and robust approach to automated deactivation of a tasks associated with a list of objects, when these pieces of information are not known ahead of time:
• the possible relationships between the objects in the list
• the status of any tasks associated with these objects

I’ve chosen to deactivate tasks in order, by object type:

#		Name		Type
1		Schedule		JSCH
2		Event		EVNT
3		Workflow		JOBP
4		Script		SCRI
5		Job		JOBS
6		FileTransfer		JOBF
7		Group		JOBG
8		Notification		CALL

This will eliminate many instances of the error Cannot deactivate task with RunID '0022555744', a task within a Workflow cannot be deactivated. (message nr: 11164).

There will inevitably be many instances of the warning Cannot deactivate task with RunID '0001066723', this task is not active anymore. (message nr: 11163) because child tasks will be deactivated when their parent tasks (workflows, schedules) are deactivated. The cleanup step will ignore these warnings.

I have considered querying the Automation Engine to find out the hierarchy of tasks, and deactivating only the top task in the tree. However, I think this would probably be more trouble than it is worth.

[Legacy User]

Is there a limitation on the result count of a sql query using SQLI.VAR.

 

I am not able to fetch the complete list using the below query:

select eh_ah_idnr, eh_name, eh_status, EH_OType from EH
where eh_client = &$CLIENT#

but when I hit a more specific query like below the result comes out.

select EH_AH_Idnr, EH_Name, EH_OType, EH_status
from EH
where eh_client = &$CLIENT# and EH_Name = 'PSC_A2_ZX_P002_JOBP';

Are you aware of such limitations using SQLI.VARA object

Thanks,

Arun

 

[Anon Anon]

Thats a Limit in the UC_SYSTEM_SETTINGS - SQLVAR_MAX_ROWS (CLT 0)

But keep in mind that changing this value could lead to performance impacts if you increase that heavily.

[Michael_Coxson_5769]

My recommendation would be to break it down into chunks based on primary team/project names. Query for base folders, split and return only the team/project name, and loop through the deactivation process for each in turn. 

[Michael A. Lowry]

Now that we are running v11, we will soon begin to take advantage of the new forced option when using DeactivateTask to deactivate tasks that are child tasks of other tasks. We will probably still deactivate tasks in the same order I described above (likely parent tasks first, and then likely child tasks afterward). We will also build in error handling for the various return codes (not all of which are well documented).