AutoSys Workload Automation

Have we ever discussed tuning the stuck in starting to have a configurable time ?

just curious what people would think.. I agree it should never take 2 mins for the agent to talk back to the scheduler. 

However..if network or (load balancer - F5 etc) issues warrant what would the people here think if we could tune it? 

Thanx

Steve C.

Steve,

Are you referring to this or something different?

CHASE_STARTING_WAIT_INTERVAL
Specifies the minimum time (in minutes) that the chase utility allows jobs to remain in the STARTING state before raising the CHASE_ALARM alarm. During periods of network load or high workload activity, it might take more than the default two minutes for the agent to notify the scheduler that a job is executing. Setting this environment variable helps reduce the number of alarms that the chase utility generates during this time. Set this environment variable on the computer where you are running the chase command.
Default: 2

There's another one related to CHASE.

• CHASE_SLEEP
  Specifies the time (in seconds) that the chase utility pauses:
  • Between successive sends of chase data to an agent following a connection failure.
    Default: 5
    Limits: 1 or higher; increasing this value might delay recovery during a network failure. Decreasing this value might result in premature chase failures.
  • Before raising the CHASE_ALARM alarm. During periods of network load or high workload activity, you can set this variable to let the chase utility extend the time that it waits for the scheduler to receive delayed job statuses from the agent; thus preventing the chase utility from raising false alarms.
    Default: 10

These environment variables need to be set up where the CHASE is executed.

Cheers,

Chandru

I didn't see that work but let me change it now . I thought it was there wasnt able to find it. 

Thanx

Steve C.

> These environment variables need to be set up where the CHASE is executed.

I sometimes have an allergic reaction to parameters that are only visible on the OS level, invisible in configuration files or menus.  I sense an idea sneeze coming on. The only things worse would be burying these in the Windows registry.

WJ

Hence why I asked .. there used to be a ton of SLEEP/ALARM related variables. And they change like the wind.

And if you miss a patch note you miss the word :

Remember these

CHASE_STARTING_DELAY=seconds

AUTO_ALARM_USAGE

AUTO_ALARM_START_SHADOW

AUTO_ALARM_AUTOPING

AUTO_ALARM_DBMAINT

AUTO_ALARM_STARTJOBS

AUTO_ALARM_CHASE

AUTO_ALARM_CHK_AUTO_UP

Steve C.

Nothing in this message is intended to constitute an electronic signature unless a specific statement to the contrary is included in this message.

Confidentiality Note: This message is intended only for the person or entity to which it is addressed. It may contain confidential and/or privileged material. Any review, transmission, dissemination or other use, or taking of any action in reliance upon this message by persons or entities other than the intended recipient is prohibited and may be unlawful. If you received this message in error, please contact the sender and delete it from your computer.

Hi WJ, bring on the "ideation"!

Makes sense that Autosys variables are dealt with in the Autosys configuration file.

As an example, the 'Nix O/S vars are in their own file, they do not creep into the Autosys config file.

Chris <CJ>

I asked about this in 2015:

Display tunables such as SCHED_SCALE in AutoSys Admin Console 

That idea shows as "New".  While I can expand/alter that, or create a new idea, the basic concept is the same: don't hide critical tuning/configuration data.

And this Idea has the same, um, idea:

AE - Enhancement Request - Keep all configuration items in the config.${AUTOSERV} file 

Polls close at 8 PM Eastern Time...

*sigh* too many old variables. too many new and slightly hidden variables. 

:-(