Page 1 of 1

Subsequence Failure propagation

Posted: Wed Mar 01, 2006 4:29 pm
by gateleys
I have designed my job sequences as suggested 'somewhere' in this forum. In short, the failure of any job is handled by 'Otherwise' links to a Sequencer stage (set to ANY). Further, the failure is notified, and the RoutineActivity is called to force fail the sequence, with the name of the sequence passed as parameter to the routine:

Code: Select all

Call DSLogFail(JobName, 'Job Has Failed')
Ans=''
It works perfectly fine. However, there is no difference in its execution or the log generated even when I pass some garbage as the JobName parameter to DSLogFail. As long as there is a failure within the sequence, it aborts and propagates the info to the parent sequence, which in turn, 'finishes' without proceeding further. That works fine with me. But, I am still baffled by the garabage parameter. Can somebody please throw light on this?

gateleys

Posted: Wed Mar 01, 2006 5:00 pm
by ray.wurlod
I prefer to propagate using UtilityWarningToLog() in a Routine activity. This means that I can retain control right back to the top level, which can instigate some diagnostic activity if required. Never abort!

To answer the actual question, the second argument to subroutines like DSLogInfo and DSLogWarn - I never use the other one! - is the value that appears in parentheses in the subject line of a logged event - which you can see in summary view. For example:

Code: Select all

Call DSLogInfo("Resizing completed", "Cleanup")
will log the following event, assuming from job named Resize job control routine:
Resize..Job Control (Cleanup): Resizing completed

This can be useful when you use the log functions for diagnostic purposes. For example:

Code: Select all

$IFDEF DEBUGGING
Call DSLogInfo("Value of loop counter is " : LoopIndex, "*Debugging*")
$ENDIF
It's then clear which messages relate to debugging in the job log.

Posted: Wed Mar 01, 2006 5:46 pm
by chulett
In spite of Ray's misgivings around warnings versus aborts, Sequence jobs must be aborted in order for the Checkpoint Restarting to function as expected. Warnings don't cut the mustard.

If you don't have 7.5.x and all that fancy new Sequence job stuff, then a Warning is ok.