Automic Workload Automation

Hi there

In the setup I'm working with, most objects do not have the generate at runtime checkbox ticked. As I heard from other AE users, most people do have this setting enabled in their jobs so I started to evaluate whether it would make sense to change our default setting.

One thing I didn't like is, that you can't see the content of nested workflows that didn't start yet.  So I basically wanted to ask how you manage this. Do you only have the non-workflow items on generate at runtime or all of them with the downside of not beeing able to see within not-yet-generated workflows?

Regards
Joel

The answer is quite complicated as the generate@runtime flag itself: It depends :-)

Automic Script is always processed when the job is being generated!

Background (simplified):
If you start a lets say WIN Job in Automic the script content (JCL and Script) is being generated to JCL, sent to the agent, executed by the agent and the Returncode transferred to AE which creates the report of the job.

So if you work without Automic Scripts and Script variables it mostly does not matter if you check the generate@runtime flag.

BUT if you work with Script variables in a Workflow where one job depends from another the generate@runtime flag becomes more importent. If the second job gets a script variable of the first job  (job output) its necessary to check the flag.

Otherwise (we learned that Automic Script is always processed when the job is being generated! ) JCL of the first job and of the second Job is being generated when Workflow is being generated - but at this time the output of the first job is not processed so far and the second job gets a wrong value.

Good practical example of the generate@runtime flag:
https://community.automic.com/discussion/5239/two-job-start-in-the-same-time#latest

Hope this helps a litle bit understanding the "magic" flag generate@runtime.


If you want to know "everything about Object execution" please have a look at following docu part:

http://docs.automic.com/documentation/AE/10.0.5/english/AE_WEBHELP/help.htm#uczafu.htm

Hi Wolfgang

Thank you for the explanation, but you might got me wrong. I do know the effect of having generate@runtime enabled / not enabled - however I was wondering whether people do have a mix of this setting or stick with generate@runtime in every case (as you might have more trouble when not having it switched on).

In my working environment I could imagine having all workflows without generate@runtime whereas the other executeable objects have it enabled. This would have the benefit, that the last monitor on not-yet-started nested workflows would be available. At least in the solutions I've seen workflow objects did rarely have script that required generate@runtime being enabled (like reading the previous' job output).

Regards
Joel

Ahhh now I understand :-)
as you might have more trouble when not having it switched on
=> absolutely right

I made a similar obervation that on the one hand often Workflows just "contain jobs" without any script. All of the scripting is done within the jobs.
On the other hand if you dynamically set or change workflow structures e.g. using :modify_task its more and more important to use or at least think about using generate@runtime.

Virtually all of our objects use generate at runtime as we have common Include objects in all of them to set attributes such as Host and Login and to make various kinds of processing decisions.  These common routines are used in any object that has some type of Process tab including Scripts, Groups, Process Flows and File Transports.  Most of the values are passed either in Variable objects or with the PSET function.  We also, on a limited basis, use the MODIFY_TASK function.

The only exception are objects, probably less than 10,  that use the READ statement for a dialog response.

We are on V8.  Also, we have modified some of the templates, such as EVNT.TIME and JOBS.UNIX, in our development Client to have this attribute set.

We are on V9 and modified all of our templates to default to having GenerateAtRunTime turned on.  We only turn it off when there is a technical reason to do so (and there have been very few reasons to do so).

Many of our evening batch systems are scheduled to start at 7pm and wait for several hours for their external predecessors to be satisfied.  During this several hour wait the contents of some of the variables that need to be resolved can be altered, so if they were to generate at activation time they would pull stale information.

If your scripts contain a SEND_MAIL() function, it is unlikely that you would want to send the email at Activation time.  It is more likely that you want it to be sent at RunTime.

One situation where we needed to generate at activation time was a job that needed to be generated before midnight, or else it would pull the wrong system date.

FrankMuffke now you got me perfectly right ;-). Another reason I'd like to change to generate@runtime is to prevent runtime failures from cancelling the whole generation process. In large workflows it's really unfortunate if they get canceled just because of a typo or alike. Right now our system is almost unuseable for 20 minutes at around 10PM workdays due to thousands of jobs that get calculated the same time.

@Mark Hadler very interesting thanks. We currently have no usage of the READ function but plan to implement some solutions with promptsets.

@Pete Wirfs thanks you for the response. One of the main reasons why all the jobs have been setup that way was the last argument you wrote. We strongly rely on the processings-workday date. However we're going to replace this information with the logical date as we always ran into trouble when we restarted abended objects.

Generate at runtime.....ugh.

What a confusing thing.  There were issues in older versions that prevented read statements when it was set/not set.  I just remember that once we got our templates setup, we never messed with that setting.  Now and again I have to disable it, or enable it to get something to work.

Generally we follow this process:
1. Master/Parent workflow has Generate at Runtime checked.
2. Sub Jobplans are usually just "containers" to simplify the overall automation and compartmentalize (thank you spell check) the steps.  As you've stated we want our support staff to be able to view this, so we have it unchecked so they can monitor.
3. Pretty much every object we've created our own version of (We do not modify the defaults, as they get overwritten when you run the InitialData on upgrade) .  Thsese objects include default variables & Prompts entries, pre/process/post entries, etc. Also, By not modifying the defaults, it assists us in making sure that we provide exact steps to Support when something doesn't seem to be working correctly.
4. In general, the process flow of automic is very odd, if you look at the flow chart some things are missed and cause issues depending on if that is checked or not.

We 're on v9 and v10.  We have our work-flows set to NOT generate at runtime, but everything else does.
Reason for the work-flows may be a lack of info on our part?   When we set a work-flow to "Generate at runtime", and we have a prompt-set on it, and the work-flow is started manually from ECC, the flow activates, but does not bring up the prompt-set dialog for user input.  Instead the job just goes into a "waiting for user input" status and hangs.  This seems like a bug, but in any case we don't set it on work-flows as a result.  We seem to get along just fine this way.

Jeremy_Swartwood_269 I see my idea seems to quiet in-line with the experience of others, that's good to read :).

EricLeacox604617 we're not yet using ECC as we just migrated from v8 to v10 and have no concepts so far. However it's good to read that keeping the workflows without generating @ runtimes works in favour with it as we might use it in the future!

I usually do not use Generate@runtime by default - If I use scripting and its necessary for the job - then yes :-)

By experience it seems that generate@runtime activated on all objects creates far less problems than it solved. It's more in the logic of how things are working regarding of the time line, like using a value set by a previous object only when you start the current object inside a logical workflow.

The only issue is that when you do an update fix or an upgrade of your UC4/AE Server all the templates are reloaded with the default configuration that is ... without the generate@runtime set ! And then when you create from scratch a new object you get in trouble if you don't modify this attribute.

One solution is to create a separate set of templates from the original set and use them instead so the modification of the original templates has no impact. It some work to do it on all objects but you have to do it once only. You just need to check if there is new templates when you do an upgrade, a fix or add a new type of Agent (RA-automation agents i.e.).

Note : there is also a similar issue with the deactivation attribute sometimes set to "always" or "never" in some objects when the common usage is "after a successfully restart" with "ANY_OK" status. Can be another topic to discuss on the "why" and "why not" of this default setting.  :)