Automic Workload Automation

Working on a solution that involves querying all the hosts on 2 farms for a bit of data, and depending what's found, 1 farm is selected for further processing. I figured that I could do the initial tests, then dynamically fill in the appropriate HOSTG once I got that far. It's looking like that is not possible, at least within a single workflow, which would be ideal.

Here is the error I am getting:
0020357 Runtime error in object 'JOBS.WIN.GET_METRICS.PS', line '00000': Host 'HOSTG.AWDBSS.WC.D1' does not exist.

HOSTG.AWDBSS.WC.D1 is a host group of course, and does exist, but I'm guessing the HOSTG needs to have been generated in advance of getting to the job, and by this point the job wants one single agent to move forward.

Any thoughts to dynamically assign a HOSTG?

Do you have generate at runtime checked?

Ah good question, Joel, I should have mentioned. This tripped us up long before getting to this point. :smile: 
 So yes, we've made sure that is enabled on all objects.

To clarify - if I read your post I understand, that you dynamically build the HOSTG members. Not that you want to change the attribute of a job to an existing host group? Because changing the host group using the PUT_ATT in the pre-process won't work, also readable in the online help:
"Host group selection, which includes selection of the agent for a task, is made before its script is processed. :PUT_ATT can be used to define a different agent but not a different AgentGroup,"

If you want a fancy solution you might try this:
1. Create a static VARA => SOLUTION.VARA
2. Create the HOSTG objects => DC1.HOSTG and DC2.HOSTG
2. During your decision process put the appropriate HOSTG object name into the vara:
:PUT_VAR SOLUTION.VARA, "MYKEY", "DC1.HOSTG"
3. For the object(s) that run on the dynamic host group, use the following string within the agent attribute:
{SOLUTION.VARA,MYKEY,1}

Let me know if that works for you ;-).

Hi Eric,

I was looking into this error. It appears it has been resolved with V10. Which version are you on?

Joel Wiesmann said:

To clarify - if I read your post I understand, that you dynamically build the HOSTG members. Not that you want to change the attribute of a job to an existing host group? Because changing the host group using the PUT_ATT in the pre-process won't work, also readable in the online help:
"Host group selection, which includes selection of the agent for a task, is made before its script is processed.:PUT_ATTcan be used to define a different agent but not a different AgentGroup,"

Hi Joel,
Actually I was trying to assign a HOSTG to the attribute. I didn't see that documentation so that's helpful.

Your suggestion about storing in a VARA might do the trick, although does this still only work if it's a specific host and not a hostg? I haven't had a chance to try that yet, but I will and report back!

Ian Geglia said:

Hi Eric,

I was looking into this error. It appears it has been resolved with V10. Which version are you on?

Hi Ian,
That is good to know, although for clarity, does this bug pertain to what I was actually trying to do, or what Joel gathered I was after?

Hey Eric, :PUT_ATT can't be used to define a AgentGroup (HOSTG).

From the documentation:
:PUT_ATT can be used to define a different agent but not a different AgentGroup.

eric.felker actually using the {VARA,KEY,FIELD} notation will be resolved in the moment the parent workflow is being generated. The VARA trick works also with HOSTG! 

So what you can do is to put the dynamic-hostg jobs into a sub-workflow with generate at runtime that follows after the decision job. That way the decision job writes the VARA while the dynamic-hostg-jobs haven't been generated yet. Once the generate@runtime workflow is being generated, the jobs will access the previously set VARA value.

[ Decision Job writing the VARA] => [ Workflow with generate @ runtime [JOB with {VARA,KEY,FIELD} host] ]

I'm quiet sure this will work ;-).

Joel Wiesmann said:

eric.felker actually using the {VARA,KEY,FIELD} notation will be resolved in the moment the parent workflow is being generated. The VARA trick works also with HOSTG! 

IT DOES WORK! Thanks very much for the help on this one. A little messy needing to add an extra jobp into the mix, but I'll take it!

Thanks also to Jen for confirming my original direction just doesn't work.

I devised a different solution, based around resolving the agent group using PREP_PROCESS_AGENTGROUP. It might be better in some situations.