Automic Workload Automation

Hello,

  I have an Job named restart_job adnd below is the code with in the process tab:

:PRINT "BEGIN OF RESTART"

:SET &RET# = RESTART_UC_OBJECT ("RESTART_QUIZ2",LAST,R2,"ORIGINAL_SCRIPT,")

:PRINT "Iam being Restarted"

:PRINT " RSTART STATUS : &RET# "

This job is supposed to restart the below script object named "RESTART_QUIZ2"  from restart point R2.

RESTART_QUIZ2 Script code:

!:ON_ERROR RESUME

:PRINT "Script start"

:RESTART R1

:PRINT "Point R1"

:GENERATE ON_RESTART_ALWAYS

:PRINT "ON_RESTART_ALWAYS"

:GENERATE ON_RESTART_CHECK

:RESTART R2 , "I'm being restarted"

:PRINT "Point R2" 

:RESTART R3

:PRINT "Point R3"

 :PRNT "Script end"

:SET &RET# = SYS_RESTART_POINT()

:PRINT "Script was processed from &RET# on."

Issue is: Each time I execute restart_job I receive an error  as below:

6/19/2014 4:20:32 PM -  U0011002 Job 'RESTART_JOB' (RunID '0002326438') on Host 'BOL3LUC401' ended normally. Remote ID=11880 

6/19/2014 4:20:32 PM -  U0010014 Activation of 'RESTART_QUIZ2' was aborted by :STOP.

I am not sure where did the STOP come from.

The purpose of this script is to 

.Print out "I'm being restarted" if the object containing this code is restarted.

 

I've been doing my own testing here, and I'm suspicious of the flags being used in the RESTART_UC_OBJECT command here.  I built another very simple script and job -- little "hello, world" things -- and they both bomb in the same way if I try using the "GEN_JCL" or "ORIGINAL_SCRIPT" options.  (That is, FAULT_OTHER - Start Impossible, with a Last message of "U0010014 Activation of <object> was aborted by :STOP".)  The restart works fine if I leave those flags out.

This function works properly for me under V8, though I did not test your code in particular.

Manual restart of the script objects shows desired results but whne we try to automate it via another job it fails.

 

Interesting!

When I use your script (with syntax corrections) in a Script object it fails similar to what you report.

When I remove the ""ORIGINAL_SCRIPT" flag from the RESTART_UC_OBJECT function it works properly.

Not certain when this flag would be used as it not one that we use in our environment.  I have no understanding what it really does beyond its rather cryptic and obvious description.

Maybe somebody else will weigh in that has a better understanding than I do. 

The Problem your are describing  is not exactly the same as ours, but since V8 we see again and again that scripts hang after a RESTART_UC_OBJECT. This is particularly bothering when a job restarts itself from its PostScirpt, because then the entire Plan may be blocked. Automic already fixed this problem for the most part, but we still see it occasionally.

As a workaround we never use RESTART_UC_OBJECT from within the Object to be restated, but instead activate this SrciptObject:

Script Name: SCRI.ALLG.RESTART_THIS_OBJECT

!!-----------------------------------------------------------------
!!Wiederanlauf
!:SET &ACTOBJ# = ACTIVATE_UC_OBJECT(SCRI.ALLG.RESTART_THIS_OBJECT)
!!-----------------------------------------------------------------
!
:SET &ACT_RUNID# = SYS_ACT_ME_NR()
:SET &PARENT_NAME# = GET_PARENT_NAME(&ACT_RUNID#, ACT)
:SET &PARENT_RUNID# = GET_PARENT_NR(&ACT_RUNID#, ACT)
:print "Wiederanlauf: &PARENT_NAME#(&PARENT_RUNID#)"
:SET &RET# = RESTART_UC_OBJECT(&PARENT_NAME#,&PARENT_RUNID#,,)
:print "Wiederanlauf: &PARENT_NAME#(&PARENT_RUNID#) / Returncode: &RET#"

Maybe that's also a workaround for your problem. It's worth a shot. 

 

When you say "Automic already fixed this problem for the most part" - can you be more specific?  I haven't found anything in the Bug Fix notes about this.

We had a user report this type of behavior as well and we're trying to recreate / document / report it to Support, but wanted to follow up with you guys first since it sounds like you beat us to the punch here on hitting this issue.   :)

I just had a Webex with Support today and reproduced it, so it is on its way to hopefully being fixed.

Our process is somewhat convoluted - I am always amazed by what our users come up with.  Don't ask me the why - just telling you the scenario.  :-)

We have a jobplan and within that jobplan are a handful of objects that run and end as normal.  Toward the end of the work flow there are some sub jobplans.  We'll say 10 - one for each firm we're processing for.

Within each sub jobplan there is a file event and some other processing going on.  The LAST object in the sub jobplan is a script.  This script does an ACTIVATE_UC_OBJECT and passes some values to the object (another script) that it is activating.  Things like the sub jobplan name.

The script that gets activated is where they have the RESTART_UC_OBJECT and it restarts the sub jobplan within the master jobplan.  So yeah, the sub jobplan essentially completes successfully, but they "restart" it so that it stays active within the master jobplan and then starts looking for the file again.

In our case the activate of the script is successful and the restart of the sub jobplan is successful.  So mostly working well.

The problem is the script doing the restart - after it does the restart - gets stuck in a 'generating' state in the Activities Window.  You can't cancel it - only way to remove it is to change the status manually to something else.  So seems somewhat similar to yours where it doesn't seem to be reporting back to RESTART_UC_OBJECT that the restart was successful and just to end.

Hope that helps.

That sounds familiar. It seems to be the same problem. We were also able to capture it on a trace but haven’t heard a lot since then. The last response was that the ticket is now in development. If you like, you could point support to INC0335514 or that thread. (I'll do that.) We largely mitigated the problem by our workaround (above) but a solution would be desirable. Especially when you consider that we have problems with ACTIVATE_UC_OBJECT and RESTART_UC_OBJECT since V8 (2012).

FYI - we were told that this certain behaviors relating to RESTART_UC_OBJECT were not working correctly in V8 - so those were fixed in V10.  A workaround - or new way for us to handle this situation is to use the Post Conditions.  This will restart the sub jobplan and then there's no more issue.