Automic Workload Automation

 View Only
  • 1.  Modify state manually by script

    Posted Nov 10, 2019 03:17 AM
    Hi,

    Is there a procedure to execute the "Modify state manually" by script? I don't find a function that execute that. Cancel_us_object is not working.
    thx!

    br
    Sören


  • 2.  RE: Modify state manually by script

    Posted Nov 11, 2019 03:17 AM
    Hi

    sure ... :MODIFY_STATE
    https://www.google.com/search?client=firefox-b-d&q=automic+documentation+modify+state
     Please take care that it is only allowed in the Post Process page. It does NOT work in the Process page, because the STATE does NOT exist there.
    What's the error message when you call CANCEL_UC_OBJECT? CANCEL_UC_OBJECT does NOT work, if the task has finished.


  • 3.  RE: Modify state manually by script

    Posted Nov 11, 2019 10:42 AM
    Edited by Carsten Schmitz Nov 11, 2019 10:42 AM
    Hi.

    As I read the manual, ​:MODIFY_STATE can NOT be used to set any Automic states (such as ENDED_OK, ENDED_CANCEL, ENDED_VANISHED). Instead, it "fakes" the return code by the external program in the post processing tab, e.g. to be non-zero. This is evident by the fact that the example specifies a value of 50, whereas Automic codes are always four digits, zero padded (again, as per the manual).

    What happens once you fake the return code of the external program (JCL) using :MODIFY_STATE depends on the configuration of your job in Automic (e.g. using post conditions).

    Faking the OS return code is NOT the same as the "Modify state manually" function, which sets Automic status codes (four digits, 0001-9999) as oposed to OS return codes (e.g. 0-127). These are different concepts.

    OP: I don't know of any function to script the effect of "Modify state manually", sorry.


  • 4.  RE: Modify state manually by script
    Best Answer

    Posted Nov 11, 2019 05:54 PM
    Hi!

    Carsten, THX a lot. You're absolutely right!
    Lot of  usages of CANCEL_UC_OBJECT and :MODIFY_STATE and :STOP here - so, i mixed it up.
    BTW, I was not aware of "Modify state manually" (in UI), because we use job processing without any user interactions only. And THIS is what the OP meant.

    I hope, this is correct. It's late already.
    • :STOP (Script Statement)
      • can be used in Process page
        • with MSG - task ends with ERROR and Status=FAULT_OTHER
        • with NOMSG  - task ends without ERROR and Status = ENDED_EMPTY
    • CANCEL_UC_OBJECT (script function)
      • can be used in Process page
        • Example:
          • : SET &STATUS# = CANCEL_UC_OBJECT (&MY_RUN_ID#) ! , 'ENDED_CANCEL')
          • Result: ENDED_CANCEL
      • Following STATUS can be set:
        • ENDED_OK
        • ENDED_CANCEL
        • ENDED_TIMEOUT
    • :MODIFY_STATE (Script Statement)
        • can be used in Post Process page only!
          • it "fakes" OS return code
          • it does NOT influence Automic status code (four digits 0001-9999)



  • 5.  RE: Modify state manually by script

    Posted Nov 12, 2019 02:35 AM
    Thank you all.

    To create the "new" state in post process is no problem.

    Is there any possibility to create a blocked state? Or only ended_cancel?


  • 6.  RE: Modify state manually by script

    Posted Nov 15, 2019 02:53 AM
    Hi Dejan,​

    That looks like a great and valuable write-up of the various functions for people searching for that info in the future, thanks for that!

    Best regards,
    Carsten


  • 7.  RE: Modify state manually by script

    Posted Nov 15, 2019 03:38 AM
    ​Hi.

    Ahem ... didn't I answer that already in the other thread of yours?

    As far as at least I am aware, there are only two ways to set the "blocked" state. One is setting a manual break point, but that's not conditional. The other is using the workflow dependencies, to tell it to block your workflow when a preceding job ends in a certain state. So you can have a workflow block by having a preceding task end "ended_not_ok", which itself happens by either by having it's program (JCL) return an errorlevel <> 0, or by using :MODIFY_STATE which shouldn't even be needed in 99% of the cases.

    Individual tasks without a workflow can't enter a blocked state afaik, so for those it's a moot point anyway.