Automic Workload Automation

 View Only

Automatic Deactivation: I have (major) issues.

  • 1.  Automatic Deactivation: I have (major) issues.

    Posted Jul 09, 2018 08:09 AM

    Greetings.

     

    This is supposed to be for your information, and a bit of a rant, too. But if you do have further information on the issues presented, please contribute. I'm curious to hear other's mileage.

     

    First off, it appears automatic deactivation of objects has a capital bug in 10.0.x?

     

    I made a simple JOBP with two JOBS - one that works (exit 0), followed by one that fails (exit 1). No other dependencies, just drawn the default lines in the editor. I set every single of these three objects (job plan and two jobs) to "deactive after error-free run". This is what happens:

     

    Version 10.0.3 will deactivate all objects: the job plan, the OK job, and the failed job (even when I fill the box that I'll tell you about in a moment with a value of "ANY_OK").

    Version 12.2 works better, it will keep the three objects activated

     

    Okay, so it's bugged. Par for the course. The help in V10 is additonally patchy in this regard and lists these options with different labels than the actual software. What do they call such over-achivement in golf - a Birdie? a Bogey? an Eddie? I don't know, I'm no golfer.

     

    But the fun gets ever more complicated. And waaay more funky.

     

    There's this option "Error-free status". It seemingly let's you define what an error-free status is:

     

     

    Observe that this is NOT in a group box with the two options above and has an extra indentation, too. To me, based on it's arrangement on the screen, it seems to apply only to the secondmost radio button ("After an error-free restart"), not to the topmost. I honestly don't know if, in this shoddy UI design, it's truly supposed to count for the second radio button only, or the first and second radio button, too.

     

    "Why don't you find out by trying it", you say? Well, because it's apparently bugged one-way, and might be bugged two-ways, so I can't determine what the intended functionality, the actual concept behind this, is.

     

    I tried it in V12.2 however, where Automic changed the layout arround a bit. It's now one and the same field that is clearly applicable now to both "After error-free execution" and "After an error-free restart". If you leave the field empty, it appears from my testing that "empty" means the same as "everything", or "it doesn't matter".

     

    In other words, an empty "Error Free Status" means that ANY status is considered an error-free status: even an ENDED_NOT_OK !?

     

    Now, I wonder: What happens if you migrate from V10 to V12? Let's make the following assumptions:

     

    • "After error-free execution" is a rather useful choice that will have been selected for many jobs in V10
    • many people will NOT have made the mental connection that Automic probably(!) meant for the "Error-free status" field to also count for the "After error-free execution" option. I sure as heck didn't, and my colleague didn't at first assume it would, and a bunch of other people also didn't think so.
    • when you migrate from V10 to V12, that field will probably not be manipulated. I.e. if it's empty, it will likely stay empty.

     

    The result, in my view, can only be this:

     

    A gazillion of objects that are expected to NOT be deactivated on error will be deactivated (also in V12, but for different reasons than in V10) regardless !?

     

    Please tell me I'm wrong.

     

    Cheers,

    Carsten