Automic Workload Automation

Expand all | Collapse all

Investigation: AutoForecast not working V12.3.0

Jump to Best Answer
  • 1.  Investigation: AutoForecast not working V12.3.0

    Posted 11-13-2019 12:09 PM
    Edited by Pete Wirfs 11-13-2019 12:12 PM
    I've seen others here state that they could no longer use AutoForecast, so I know I'm in good company.  Under V11 we could never trust the script function to complete, so we were recalculating manually.  Now that we are on V12, it seems that even doing a manual recalculation will not complete either.  It generates some results but they are incomplete, which misleads my operations staff.  (I've informed them to NOT TRUST IT at this time.)

    So I stripped one of our schedule objects down to 3 tasks that can't AutoForecast.  When I strip it down to 2, it can AutoForecast.  So I'm doing some deep analysis to try to figure out what about that one task is blocking the process.  I've also got support working on re-creating this problem today as I've been exporting all of the related objects to them.

    Seriously hoping to get to the bottom of this... Without a healthy AutoForecast, any impromptu maintenance windows will be flying blind.

    SYMPTOM:
    Under "Forecasts", the AUTOFORECAST entry hangs up in "Preparing" state and never completes.  It must be manually deleted before another attempt is allowed.

    ------------------------------
    Pete
    ------------------------------


  • 2.  RE: Investigation: AutoForecast not working V12.3.0

    Posted 11-20-2019 08:53 AM
    Hello, Pete,
    after the upgrade from V12.0.7 to V12.3 the AUTOFORECAST also does not finish.
    We haven't been able to find a cause yet.
    However, if we create a forecast for a single scheduler from the perspective of process assembly, we always get the status "ENDED_TIMEOUT start time exceeded" for the contained objects. In reality at least some of these objects should start at a certain time, while others should be skipped due to calendar conditions.
    In this case, the FORECASTS states should also be treated with caution!
    And yes, some of these forecasts do not come to an end too.
    We have created Tickest for both cases, but have not received a usable answer yet.

    Regards
    Thomas


  • 3.  RE: Investigation: AutoForecast not working V12.3.0

    Posted 11-21-2019 04:51 AM

    Hi all, we have 2 confirmed bugs with forecast in awaV12.3.0hf2 from Automic support:

    {Case#20078659} ## Forecast is not working properly for schedule object - timezone is ignored

    Response Update: Hi Frantisek,

    I was able to reproduce this issue. It has been sent to Engineering to be patche up.

    {Case#20078672} ## Forecast is not working for object with mx runtime defined (frozen in preparing) has been updated
    I was able to reproduce this issue. It has been sent to Engineering to be patche up.

    Best Regards,


  • 4.  RE: Investigation: AutoForecast not working V12.3.0

    Posted 11-22-2019 05:47 PM
    Thank you for confirming it is not just us.  My support call has not yet gotten a response.  I suspect that the forecast function is so bad off, that support is probably sitting back and waiting for engineering to go through it and report the finding and correction of some of these issues.

    In the mean time, I'm educating my staff on how to fly blind during maintenance cycles;
    1. Go ahead and shut down AE systems for maintenance when necessary.
    2. After AE system restart, review all schedule monitors to see exactly what was missed, and take appropriate action.

    We are doing a maintenance cycle this Sunday morning to apply patches to our PROD AE Windows server OS, and we'll see how it goes.

    ------------------------------
    Pete
    ------------------------------



  • 5.  RE: Investigation: AutoForecast not working V12.3.0

    Posted 11 days ago

    Good news on the topic "Forecast".
    We have received the following information from Broadcom Support.
    --snip--
    This issue is already reported by many other customer and it has been already investigated by R&D team.
    Issue description: Forecast not completing as per expectation and it doesn't not end from preparing state.
    This issue is fixed in the upcoming release, that is 12.3.2
    Which will be available for download from Feb 24th 2020.
    Please upgrade to the fixed version to resolve the issue.
    --snap


  • 6.  RE: Investigation: AutoForecast not working V12.3.0

    Posted 11 days ago
    Great news - thanks!


  • 7.  RE: Investigation: AutoForecast not working V12.3.0

    Posted 11 days ago
    Just yesterday I was re-creating the Forecast problems with WP traces turned on as per American support.  I will inform them that 12.3.2 is supposed to have repaired this.  I'll ask if they can get an advanced copy of the 12.3.2 documentation.

    ------------------------------
    Pete
    ------------------------------



  • 8.  RE: Investigation: AutoForecast not working V12.3.0

    Posted 01-02-2020 02:40 PM
    This is good to know. Tried executing my first Recalculation in 12.3.0 today and it got stuck on preparing, then caused the AWI to stop responding for all users. I had to delete the forecast I'd tried running (for one agent over a 5 hour period) through the thick client, and restart the JWPs and JCP. I hope they never get rid of the thick client or we will be dead in the water.


  • 9.  RE: Investigation: AutoForecast not working V12.3.0
    Best Answer

    Posted 11 days ago
    We had major issues with the forecast in v9 and v10, but v12.0 has been pretty decent for the most part other than some strange occurrences.  Currently with the v12.0, we have two schedules that fault within the forecast.

    Have you looked at the last message that is generated on those that are stuck in preparing status?

    With the two faults that we encountered, one I just found was due to the use of an invalid calendar object.  The other is due to the use an agent group in a file transfer for the source and a variable listed in the destination.  The second forecast issue is probably a bug since the variable was really just a single host, but I haven't taken the time to open a ticket on it.