We have the requirement to dynamically decide which tasks should run in a JOBP. Usually everything runs but for testing purposes in some cases we only want one single task to run. Condition is to not touch the workflow itself as it is already productive and this change only affects test.
So my idea was to create a script, that starts the JOBP. A prompt defines which task shall be run. MODIFY_TASK then is used to firstly set a breakpoint in the <START> task. This avoids any job to run. Secondly I can then activate the needed task by using the function parameter ACTIVE and set it to YES.
Problem: report outputs return codes that indicate that it cannot perform those actions. First issue is that STOP_MODIFY does not work. But I don’t know why.
Does anybody have an idea how to resolve this?
Thanks a lot in advance.
Are you allowed to modify the jobs (or their Pre-Process tabs, anyway)?
If so, then using the workflow-level prompt you mentioned, you could add this code to each job that might require skipping:
! replace this &SKIP_THIS_JOB# var with the appropriate var for each job:if &SKIP_THIS_JOB# = "Y": stop nomsg,50,"Skipping this job":endif
You'll need to ensure the dependencies on all of the tasks in this workflow are set to ANY_OK or something so that it doesn't trip things up when they get skipped.
"not change the workflow itself"
That is the challenge. We quite often have to modify our production workflows in order to be able to run tests. I've been working with various batch test systems for more than 30 years, and this as always been an unsolvable problem on every platform. The best you can hope for is to minimize the number of changes required via good design and lots of environmental variables.
If it would help, I could post the code for a utility job that sets a breakpoint on all workflow tasks at runtime. The customer could then use "go immediate" selectively on the task(s) they want to test. But this requires you modify the workflow to add this utility job.
Here is the code for a script that when added to the beginning of a workflow, will dynamically apply breakpoints to all tasks. (I didn't write it... I got it from someone else in these forums.)
Put this in a script object;
!Get Parent RUNID:PSET &WORKFLOW_RUNID# = GET_PARENT_NR(&$RUNID#):SET &HND# = PREP_PROCESS_VAR(DC.UTIL.SET.BREAKPOINTS.QUERY)!STOP Workflow:SET &RET# = MODIFY_TASK(&WORKFLOW_RUNID#, STOP_MODIFY)!SET Breakpoints on every Task:PROCESS &HND#: SET &TASK_NAME# = GET_PROCESS_LINE(&HND#,2): SET &TASK_RUNID# = GET_PROCESS_LINE(&HND#,3): SET &TASK_TASKNUM# = GET_PROCESS_LINE(&HND#,4): SET &RET# = MODIFY_TASK(&WORKFLOW_RUNID#,,&TASK_TASKNUM#, BREAKPOINT, "YES"): print "RET=&RET#. Setting breakpoint for &TASK_TASKNUM#:&TASK_RUNID#:&TASK_NAME#":ENDPROCESS!COMMIT Changes & Start Workflow:SET &RET# = MODIFY_TASK(&WORKFLOW_RUNID#, COMMIT):SET &RET# = MODIFY_TASK(&WORKFLOW_RUNID#, GO, FORCED)
The SQLI_SEQ variable DC.UTIL.SET.BREKAPOINTS.QUERY contains this SQL:
(and it must accept &WORKFLOW_RUNID# as a bound parameter)
selectejpp_object as child_task_name,ejpp_taskidnr as child_task_runid,ejpp_lnr as tasknumfrom ejppwhere EJPP_AH_IDNR = ?and ejpp_taskidnr <> 0order by ejpp_lnr
I think the technical problem with your approach, is you can not do modify_task commands against your target workflow until after it has activated.
And what if you have workflows that run workflows?