Hello,
Here, a post concerning the Documentum Job Sequence. A job sequence is a job that runs a series of other jobs. For each job in the sequence, one or more predecessor jobs may be designated. Each job is run in the sequence after any predecessors run. Jobs that do not have predecessors run in parallel. Each job sequence must contain at least one job that does not have any predecessors.
The procedure of creation is detailed from page 222 in the “Administrator Version 7.2 User Guide” http://www.emc.com/collateral/TechnicalDocument/docu57878.pdf, however, you would find below several important points concerning the dependencies setting of jobs in job sequence:
- It is possible to select jobs of several repositories,
- It is necessary to fill the connection info (docbase,login and password) for each repository,
- The jobs in the sequence run in parallel except when the jobs have a predecessor,
- The selected jobs in the job sequence must be inactive,
- …etc.
However, there is another important point concerns the selection of jobs, the success_return_codes, success_status fields of dm_method and the a_current_status, a_last_return_code fields of dm_job. Indeed, the methods executed by jobs included in a job sequence must have a defined value for the dm_method.success_return_codes field or the dm_method.success_status field or both. So, Documentum Administrator only displays jobs whose associated methods dm_method have a value for either or both of these fields: success_return_codes and success_status.
Why?
The dm_run_dependent_jobs method, which invokes sequenced jobs, uses one or both of those fields to determine whether an invoked job completed successfully. In order to consider the invoked job to have completed successfully, the dm_run_dependent_jobs method compares:
- dm_job.a_last_return_code to dm_method.success_return_codes
- dm_job.a_current_status to dm_method.success_status
Note: The agent exec process sets the dm_job.a_last_return_code field to the value returned by the job’s method. The dm_job.a_current_status field must be set directly by the invoked method.
Example:
We have the 3 inactive jobs (dm_job) already executed with the following status and return code:
- Custom job My_JavaLuCustomJob:
o a_current_status : COMPLETED
o a_last_return_code : 0
o method_name : My_JavaLuCustomMethod - Records migration job My_JavaLuRecordsMigrationJob:
o a_current_status : My_JavaLuRecordsMigrationJob Tool Completed at 09/28/2016 13:42:33. Total duration was 0 minutes.
o a_last_return_code : 0
o method_name : dm_Migration - Migration Policy job My_JavaLuMigrationPolicy:
o a_current_status : My_JavaLuMigrationPolicy Tool Completed at 09/28/2016 17:29:39. Total duration was 0 minutes.
o a_last_return_code : 0
o method_name : dm_MoveContent
….and the 3 methods (dm_method):
- Custom method My_JavaLuCustomMethod :
o success_return_codes : __
o success_status : __ - System Administration method dm_Migration :
o success_return_codes : __
o success_status : __ - System Administration method dm_MoveContent :
o success_return_codes : __
o success_status : __
=> These 3 jobs could not been selectable because the value of dm_job.a_current_status and/or dm_job.a_last_return_code fields don’t match with the dm_method.success_return_codes and/or dm_method.success_status fields.
=> But, the adding of the 0 value to the dm_method.success_return_codes,
UPDATE dm_method OBJECTS append success_return_codes = 0 where object_name like 'My_JavaLuCustomMethod';
- Custom method My_JavaLuCustomMethod :
o success_return_codes : 0
o success_status : __
=> The job “My_JavaLuCustomMethod” becomes selectable in the job sequence.
=> The same, the jobs using DCTM methods like dm_Migration/dm_MoveContent couldn’t be selected in a job sequence without modify the success_return_codes and/or success_status fields of the concerned methods.
For information, below the API in order to ROLLBACK the modifications done by DQL:
API> remove,c,100xxxxxxxxxb9,success_return_codes,0
API> save,c,100xxxxxxxxxb9
Best regards,
Huseyin OZVEREN