Automic Workload Automation

 View Only
Expand all | Collapse all

ACTIVATE_UC_OBJECT with object type as first argument

  • 1.  ACTIVATE_UC_OBJECT with object type as first argument

    Posted Jan 28, 2020 09:52 AM
    Edited by Michael A. Lowry Jan 28, 2020 09:54 AM
    While conducting a survey of object uses today, I discovered that several of our batch developers have been using ACTIVATE_UC_OBJECT with an object type as the first argument, and the object to execute as the second argument.
    :SET &RunID# = ACTIVATE_UC_OBJECT(JOBS,"UC0.DEV.TEST#1_1.JOBS_UNIX")
    This syntax is not documented. I tested it an it appears to work, but at least in my testing it led to a serious problem: the parent SCRI and the called JOBS object executed repeatedly. I had to stop to the queue to cancel the task. By the time I had cancelled it, the SCRI had run more than 200 times.

    AE v12.0.8 HF2


  • 2.  RE: ACTIVATE_UC_OBJECT with object type as first argument

    Posted Jan 28, 2020 10:58 AM
    Hi.

    Interresting, but can't replicate with 12.3.1.​

    My line was:

    :SET &RUNID#=ACTIVATE_UC_OBJECT(JOBS,"JOBS.DC1.CSTEST_HELLO#1_1.WORLD_UNIX")

    Gets executed just one time on that release. Still wrong that it gets executed at all, should generate a syntax or "object not found" error really.

    Best regards,
    Carsten


  • 3.  RE: ACTIVATE_UC_OBJECT with object type as first argument
    Best Answer

    Broadcom Employee
    Posted Jan 29, 2020 02:28 AM
    Hi,
    regarding object type as first parameter: ACTIVATE_UC_OBJECT is part of Automic since version 1.21 if I remember right. At the introduction of that script command the object type was the first parameter and the object name the second. Later, it was discovered, that the first parameter is useless, because there cannot be two objects with the same name anyway. So it was decided (in V8?) to remove the parameter from documentation but keep it functional as an optional parameter for compatibility reasons. It's recommended to remove the object type from all ACTIVATE_UC_OBJECT calls.
    Regards, Markus


  • 4.  RE: ACTIVATE_UC_OBJECT with object type as first argument

    Posted Jan 29, 2020 02:37 AM
    Edited by Michael A. Lowry Jan 29, 2020 02:37 AM
    Ok, thanks @Markus Embacher. I will contact the owners of the affected objects and ask them to remove the object type.


  • 5.  RE: ACTIVATE_UC_OBJECT with object type as first argument

    Posted Jan 29, 2020 02:31 AM
    Edited by Tim Quakulinsky Jan 29, 2020 02:31 AM
    Hi,

    the syntax for specifying the object type looks very old to me. In very old versions (< 3.00 ?), the object type had to be the first parameter for various functions. Example: GET_UC_OBJECT_STATUS

    I think that ACTIVATE_UC_OBJECT is also one of the functions that used to require the object type to be specified.

    Best regards
    Tim

    ------------------------------
    Automation Evangelist
    Fiducia & GAD IT AG
    ---
    Mitglied des deutschsprachigen Automic-Anwendervereins FOKUS e.V.
    Member of the German speaking Automic user association FOKUS e.V.
    ------------------------------



  • 6.  RE: ACTIVATE_UC_OBJECT with object type as first argument

    Posted Jan 29, 2020 02:56 AM
    ...and the same is valid for PREP_PROCESS_REPORT.


  • 7.  RE: ACTIVATE_UC_OBJECT with object type as first argument

    Posted Jan 29, 2020 02:34 AM
    Edited by Michael A. Lowry Jan 29, 2020 02:38 AM
    I found the reason for the repeated runs. I had mistakenly enabled rollback for the child job, and specified the parent script as the backup task. Doh!


  • 8.  RE: ACTIVATE_UC_OBJECT with object type as first argument

    Posted Jan 29, 2020 05:17 AM
    Edited by Carsten Schmitz Jan 29, 2020 05:17 AM
    I'd say make that a bug report for missing loop protection, because that's just another way a designer with limited rights can likely brick the engine.​

    But I filed one of those for a similar thing and it's "by design", so ...

    ------------------------------
    These contain very good advise on asking questions and describing supposed bugs (no, you do not need to go to StackExchange for Automic questions, but yes, the parts on asking detailed, useful questions ARE usually relevant):

    http://www.catb.org/~esr/faqs/smart-questions.html

    https://www.chiark.greenend.org.uk/~sgtatham/bugs.html

    I will not respond to PM asking for help unless there's an actual reason to keep the discussion off of the public forums.
    ------------------------------



  • 9.  RE: ACTIVATE_UC_OBJECT with object type as first argument

    Posted Jan 30, 2020 09:06 AM
    Hi Michael,
    The missing loop protection has been a concern as we use the ACTIVATE_UC_OBJECT frequently for several of our clients. We started using a simple JOBI which takes the object as &JOBP defined at the event definition level. Now our users simply use a template that feeds their object name to &JOBP from a JOBI that we maintain which checks for the previous instance of the JOBP before running another. This keeps the activity window clear of "Waiting" objects quite nicely. Let me know if you want the code from our JOBI which is called from all EVNTs file or time based.

    ------------------------------
    Founder and Partner
    Data Center Automation Consultants DCAC
    ------------------------------



  • 10.  RE: ACTIVATE_UC_OBJECT with object type as first argument

    Posted Jan 30, 2020 09:13 AM
    Yes please. That would be nice.