How to use GENERIC jobs

[Michael A. Lowry]

I wanted to expand on the earlier discussion on GENERIC jobs.

The v12.x documentation offers no explanation whatsoever of how to use Generic jobs. To learn a bit more, we have to go back to the v11.2 documentation. There, the page on Generic jobs tells how to specify the agent where a generic job should run: using the &AGENT# variable¹. How does one set the &AGENT# variable?

After several tests, I could not find a way to make Generic jobs work by setting the &AGENT# variable¹ in the pre-process of the generic job. The Generic job will switch correctly to the specified agent only if the &AGENT# variable has been set earlier, during the activation phase of task execution.

The following ways of setting the variable work OK:

• Object variable &AGENT# in Variables & Prompts of the generic job;
• Prompt set variable &AGENT# in prompt set added to Variables & Prompts of the generic job;
• Object variable &AGENT# in the task properties of the generic job within its parent workflow;
• Object or script variable &AGENT# in the calling task, if the generic job is executed via ACTIVATE_UC_OBJECT with the PASS_VALUES option; or
• Input variable &AGENT# read from the prompt/read buffer using the :READ command:
  • when passed to the job via a parameter in an EXEC VARA, or
  • when passed to the job via the set using:PUT_PROMPT_BUFFER in the calling task,
    if the generic job is executed via ACTIVATE_UC_OBJECT.

The following ways of setting the variable do not work:

• Script variable &AGENT# in the pre-process of the job (via :SET command);
• Job attribute HOST in the pre-process of the job (via :PUT_ATT command);
• Curly-brace-style VARA object reference in object variable&AGENT# in Variables & Prompts of the generic job²; or
• Predefined system or object variable in object variable&AGENT# in Variables & Prompts of the generic job³.

Notes:

1. The v11.2 release notes also mentions the &OVERWRITE_AGENT# variable, but provides no explanation how the two variables differ. (Acomment by Jennifer_Jinhong_34 suggests that the latter variable is related to ARA.) My testing revealed that one can specify the agent where a generic job should run using either the &AGENT# variable or the &OVERWRITE_AGENT# variable. If both are set, &OVERWRITE_AGENT# takes precedence.
2. Yes, I actually tried this. I created an EXEC VARA to look up the agent name dynamically. Neither this nor looking it up from a static VARA worked. The following error appeared:
   

   U00000009 '{UC4.RESOLVE_AGENT_GROUP.VARA_EXEC,,1}': Access denied

   Interestingly, VARA object references were correctly resolved in other object variable values— just not in &AGENT# or &OVERWRITE_AGENT#.
3. I also tried passing the agent name via the &ARCHIVE_KEY1# predefined variable. This resulted in
   

   U00007074 Error during generation. A Job object of the type GENERIC may only change to an OS-platform job.

   It seems that variable resolution is simply not performed on the contents of the &AGENT# and &OVERWRITE_AGENT# object variables.

[Anon Anon]

When I played around with GENERIC jobs I observed this issue (NON-ablitity to set agent via PRE-Process) so I switched back very quick to my all-time favorite - PREP_PROCESS + OS command :-)

Result: for our purposes not usable...

cheers, Wolfgang

[Matthias Schelp]

Hello, same for us. I evaluated GENERIC Jobs while preparing a presentation for our update to V12. I was also not able to find any usefull information on the V12 docs, but I found this video from Philipp Elmer (featuring George Clooney)

https://philippelmer.com/video-blog-ae-object-type-jobs-generic-2/?lang=de

Phillipp also mentions that &OVERWRITE_AGENT# beats &AGENT# in a variable shootout. However, one of my intial questions still remains, both on the fact that George Clooney appears in Philipps video and on GENERIC Jobs. What are they good for???

[Michael A. Lowry]

leflu01, the formatting of this post, and many like it that also contain inline preformatted (monospaced) Text in <code> blocks, is a bit messed up. The neighboring spaces are now gone.

[Michael A. Lowry]

It looks like spaces were mistakenly omitted also around italicized text. E.g., this line:

Prompt set variable&AGENT#in prompt set added toVariables & Promptsof the generic job;

originally looked like this:

Prompt set variable &AGENT# in prompt set added to Variables & Prompts of the generic job;

[LuuLe]

Hi Michael,

There are two things it look its happen on these compare to how it was compare to how it look in the Automic Community.  The first that the anything within the <code> field does not have an gray outline (for this, we have to put in as a requested feature in the The Water Cooler -This is similar to the Community Feedback section in Automic Community + it have tips & tricks + how to etc.. related to the community).

 

As for the second issues as you have mention is the space being strip, it appear that the tool used for the data migration seem to have strip the any space that right before or after the <> in certain situation.  I don't believe it would be possible to correct this without running through that migration again but I have reported this with our internal team for any possible post-migration fix to resolve the spacing issue you are seeing.

Code from Vanilla

<li>Predefined system or object variable in object variable <code>&amp;AGENT#</code> in <i>Variables &amp; Prompts</i> of the generic job³.</li>

Code of in CA Community

<li>Predefined system or object variable in object variable<code>&amp;AGENT#</code>in<em>Variables &amp; Prompts</em>of the generic job&sup3;.</li>

The stripping of space does not appear to occur for all instance of italicized text.