PSA: Generate at Runtime Saves Lives.

[Carsten Schmitz]

​Another one from the PSA series. I sincerely hope this saves anyone from the troubles I just went through.

If you have multiple users, and anything more complicated than "Hello World", do use "Generate at Runtime". There is (almost) no reason not to, and the reasons there are do not make up for the pain if you don't use "Generate at Runtime". Put it into your object templates if you must. Even tattoo yourself a reminder or write about it to your congress man (or woman) if that helps.

Case Study:

I already knew that "Generate at Activation Time" makes JOBF, for example, resolve their wild cards at activation time.

That's right: Put a JOBF into a JOBP behind a job that runs an hour. Launch JOBP at 18:00. Your JOBF will generate at 18:00. It will run at 19:00, but it will have already decided which files to copy at 18:00. If there are any files added (or entity of choice forbid, even removed), then that will not be considered anew at 19:00.

I knew this. And now you all do, too.

I still spent the best part of two days debugging a report on an EVNT. Okay, this was mostly because the job construct was unbelievably convoluted ("historically evolved", we call it). That's what you get when about 80 people over several years, some of them retired from the company, create, alter and hand over jobs, are too busy to provide additional details on the problem and it also involves me digging around in SAP. At some point I was running SQL queries over 31 million lines of RT table in search of answers (instead of answers, it only led to a blown-up Oracle rollback segment). I do NOT recommend this entire setup.

At the end, I discovered this:

A file event set to "> 0 Bytes" and "File is stable" will also consider the file system state at ACTIVATION if not configured to "Generate at Runtime". So even though your event runs from 19:00 to 19:05, and the file is there from 18:50 all the way to the next day, and the file is stable all the way from 18:50 until tomorrow, the event won't fire. Because, I recon, when it got activated at, say, 18:00, there was no file, and when it runs at 19:00, it will probably just shrug it's shoulders and say: "meh, there was no file back then, not even gonna look now!"

Now I very much dislike this anthropomorphicized EVNT.

Oh, and if your JOBP with the EVNT in it takes a file from outside that JOBP (as was the case here), and the timing is just as perfectly horrid as can be (as was the case here, naturally), you'll end up with the best of race conditions: an EVNT which most of the time works by pure coincidence, and once in a blue moon does not. Splendid.​​

[Pete Wirfs]

I've even modified our templates to default to "Generate at runtime", because this is a better default.

Yes, there are also valid reasons to generate at activation time.  The most common one being that activation time might be when the UC4 variables contain the desired state values.

I also had an Automic trainer show me that if you generate at activation time, then it was possible to perform manual changes against the generated parameters prior to execution.  (If it hasn't been generated yet, then you aren't allowed to make any manual changes.)   But the use-case of making manual changes to a task before it runs didn't sound like a desirable process to me.

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

[Carsten Schmitz]

Hey Pete,

> I've even modified our templates to default to
> "Generate at runtime", because this is a better default.

Now that you mention this: We've actually done that quite some time ago, too.

Unfortunately, some of our workforce (of about 60 Automic users) prefer to clone all new objects off of old objects, because it's less work that way. I've asked them to change their old objects, but I guess since nobody ever listens to ye olde me, and they also haven't had an intern available recently ... ;)

(edit: in case you're wondering: about 60 users at present. About 80 users over a span of three years since I manage this thing).

[Brian Hudgins]

Pete,
This is great advice, and although rather mundane subject, you make it an enjoyable read. 
"GAR" has been the solution to many hours of troubleshooting at many different clients. As you mentioned, it extends to many other types of objects and will have the same "timing" affect anywhere you utilize Automic scripting. I have gone as far as doing a quick check prior to migration to insure objects that are being deployed to PROD have this option properly selected.

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

[Pete Wirfs]

@Carsten Schmitz said:
" ...some of our workforce ... prefer to clone ... because it's less work that way..."

I believe 100% of our staff have figured this out too.  Unfortunately this also clones the documentation tabs which our staff often forget to correct (Maintaining documentation is everybody's favorite task, right?)

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

[Carsten Schmitz]

> ​Unfortunately this also clones the documentation tabs

This, fortunately and for once, is of no concern to us. American studies show that 99,87% of our documentation tabs are left empty anyways.

;)

[Carsten Schmitz]

Hey Brian,

I'm glad you liked Pete's response! Did you enjoy reading ​my original post as well? :D

Not fishing for attribution here, but it's good to have it, should Broadcom some day decide to tighten the rules on what can be said and how (which, to their outmost credit, they have not strongly enforced for my person to this day).

With the best regards from Germany,
Carsten