Out-of-the-box agentparms

[Chris Trinidad]

At times, the agent service is recycled while jobs are still running on the agent server.

This results in "loss of control" and a subsequent job failure alarm.

The job failure alarm in this case is false, as the actual job is still running.

I understand that the solution for this issue is to add two additional parameters to the agentparm.

These two additional parameters should be part of the original agent installation so that if the agent service is terminated for any reason, when it "wakes" up, it will pick up the correct job status.

Thoughts ???????

Thank you

Chris <CJ>

[Rick Romanowski]

Can you provide the 2 additional parameters and the suggested values?

[Chris Trinidad]

Here you go........

persistence.coldstart=false

oscomponent.noguardianprocess=false

- Thanks

Chris <CJ>

[Rick Romanowski]

According to the CA documentation both of the parameters you mention are set that way by default.

So aren't the Out-of-the-box agentparms set as you would expect/want?

Or am I missing something?

 

https://supportcontent.ca.com/cadocs/0/CA%20Workload%20Automation%20System%20Agent%20r11%203-ENU/Bookshelf.html

 

oscomponent.noguardianprocess

Specifies whether the agent resumes tracking jobs that were active at the time the agent is recycled.

true

Does not return the status of jobs that ran at the time the agent went down.

The agent fails UNIX jobs upon restart and returns the message "Lost Control".

false

Returns the status of any active or inactive job when the agent restarts.

Default: false

Note: To enable the default, set the persistence.coldstart parameter to false or comment it out.

persistence.coldstart

Specifies whether the agent performs a warm or cold start.

true

Performs a cold start. All databases are automatically destroyed and new ones opened. No manual intervention is required. This setting is recommended if there is extensive damage to the databases. The agent discontinues job monitoring after a cold start.

Note: On UNIX systems, the agent continues monitoring after a cold start.

false

Performs a warm start. The agent tries to use the existing databases. However, if there is sufficient damage, the agent does not start.

Default: false (agent performs a warm start)

[Chris Trinidad]

If that is a default, then I am glad !

Though, I have seen that the installation of the Build #717 agent does not provide those.

Possibly the installation media could be outdated ?

Is there any way that this can be checked ?

Thank you

Chris <CJ>

[Chandru.Venkataraman]

Chris,

"false" being the default for both persistence.coldstart and oscomponent.noguardianprocess, I am not sure why one must add those lines explicitly with default values in the agentparm.txt. Did you have to change them to "true"?

By the way, "persistence.coldstart=true" isn't recommended, except when the Agent's database has to be cleaned just once to rid of corruption.

Build# 717 is 11.3 SP4. Can you please share the DVD ISO name you installed the Agent from? I'll check this out.

 

Thanks,

Chandru

[Rick Romanowski]

Is there any way that this can be checked ?

 

• Verify the parameter is not in the agentparm.txt file
• Check the agent_properties.log file in the ESP Agent log directory, if the parameter does not show then you are getting the default.

 

Maybe you should open a case with CA, Severity 4 - Minor problem or question about use and see what they say.

[Chris Trinidad]

Thank you for sharing the information!

[Steve Carrobis]

sqlplugin for autosys:

 

db.connectionPool.maxSize=0
db.connect.separateThread=true
db.connect.setTrace=true

 

 

windows: 

 

oscomponent.lookupcommand=true
oscomponent.joblog=true
oscomponent.cmdprefix.force=true

 

 

 

[Chris Trinidad]

+1, for Steve's ask!

Chris <CJ>

[Chandru.Venkataraman]

The System agent installation using the AE package, has these defaults:

 

#
# Legacy Default Values
#
filemon.firstscan.skip=true
oscomponent.cmdprefix.force=true
oscomponent.initialworkingdirectory=USER_CONT_NOT_AVAIL
oscomponent.noexitcode=256
oscomponent.noforceprofile=true
oscomponent.profiles.src.delay=true
oscomponent.profiles.src.order.global.first=true
oscomponent.profiles.src.verify=true

 

#
# Unix specific settings
#
oscomponent.loginshell=false
oscomponent.defaultshell=/bin/sh
oscomponent.validshell=/usr/bin/sh,/bin/csh,/bin/ksh,/usr/bin/ksh,/bin/sh,/bin/bash
oscomponent.checkvalidshell=true
oscomponent.lookupcommand=true
oscomponent.joblog=true

 

And when using the independent System Agent installer (not part of AE install package), if the WAAE compatibility mode is chosen at install time, the following are the defaults since 11.3 SP4;

 

# Autosys Compatibility Mode
agent.spool.success.autocleanup=true
agent.resourcemon.enable=true
oscomponent.joblog.success.autocleanup=true
oscomponent.noexitcode=256
oscomponent.cmdprefix.force=true
oscomponent.initialworkingdirectory=USER_CONT_NOT_AVAIL
oscomponent.cmdprefix.force.quotes.full=true

 

 

[Steve Carrobis]

Chandru,

 

With all due respect (and i mean that), I understand that you work for CA and defend the status quo, but I have always worked in the real world and defended the product for all. One thing that always tweaks me is when someone comes up with a request or oddment, the book is quoted chapter and verse and sometimes the book can be wrong ;-)

 

Let's please look at this from a purely AutoSys perspective:

 

Even if I chose non-compatibility mode, certain things should not be turned on/off for AutoSys installs. 

The issue here is that the agents are agents for all products , for the most part, and there are effects that negatively impact how AutoSys inherently works.

 

 

So instead of asking for compatibility mode, the install should know it’s an AutoSys install and make sure the settings are made that won’t break AutoSys behavior, such as reading the profile attribute. 

 

oscomponent.profiles.src.delay=true - BREAKS autosys profile attribute

oscomponent.profiles.src.delay=false - Is the proper setting 

 

Even if I choose to allow it to read the user login ID it shouldn’t make the profile attribute to be sourced after the command call. Which that delay does. and was only discovered when i opened a ticket and we found the culprit.

 

As for the sqlplugin , advice to bump up the maxpool is the wrong advice to give, several years ago after working with CA we discovered it actually needs to be set to 0 as I indicated, otherwise DBPROC and other issues may arise. 

 

So , yes to be fair, there are certain setting that get made when you do compat or non-compat. However, the non-compat SHOULD never break how AutoSys behaves, Can we please agree on that ? I believe this is the point Chris has brought on this thread.

 

*off the soap box*

Thank you for understanding the ask and dilemma we face with AutoSys agent installs. 

 

Steve C.

[Clark Ammons]

I have to echo what Steve has said as I have been on that same road, maxpool needs to be a zero because there are issues as was stated.  I have also spent time fxing stuff that was not broke just because the oscomponent.profiles gets set to true and finding that the profile attribute is no longer working.  I only found one extra thing that I think Steve might have forgot,  when AutoSys is logging into a *nix system it logs in with permissions of 0600 and, we found that by adding the following oscomponent's  you can at leas get it to 664 (rw,rw,r) so that one id can create a file and another one can append to it, only run into this when you are sharing with an agent, you add to the Unix specific settings:

oscomponent.umask=113
oscomponent.defaultfile.permission=0664
oscomponent.noforceprofile=true
oscomponent.cmdprefix.force=true
oscomponent.profiles.src.delay=true
oscomponent.profiles.global.override=true

 

That's my extra three cents.

Clark A

[Chandru.Venkataraman]

Steve,

I just stated the facts from an actual install. Its been ages I referred to a doc/guide, 'cause it fails me. I agree that the real world is different from what's documented. Thanks for sharing your experience on the src.delay and SQL params!

 

Chris,

If you like these params to be changed, then please raise this as an idea for traction.

 

Thanks,

Chandru

[Steve Carrobis]

so just to be clear on profile issues 

 

if legacy mode is chosen:

oscomponent.noforceprofile=true

oscomponent.profiles.src.delay=true

 

if it is not chosen 

and you need the user login profile sourced then you need to make sure you do not delay the profile. 

 

oscomponent.noforceprofile=false

oscomponent.profiles.src.delay=false 

 

Thank you 

 

Steve C. 

[Steve Carrobis]

ON further contemplation. 

oscomponent.noguardianprocess

Specifies whether the agent resumes tracking jobs that were active at the time when the agent is recycled.

• false—Returns the status of any active or inactive job when the agent restarts
• true—Does not return the status of jobs that ran at the time the agent went down. Fails UNIX jobs upon restart and returns the message "Lost Control".

Default: false

Note: To enable the default, set the persistence.coldstart parameter to false or comment it out.

 

i think i want to set this to true. - if you reboot an agent or stop the agent due to maintenance. i think you would want any job running killed. 

I like the idea of stopping an agent ... doing something to the machine and the jobs coming back failed because killing the agent is equivalent of killing the old autoremote. you want a failed status to come back .

 

 

Steve C.