In defense of Autosys........

[Chris Trinidad]

Why is Autosys the first focus when there is a speed bump?

Examples..........

"The agent is not working"

- yes, not if there is a firewall in the way and could you have let me know before I spent the time finding out?

"Autosys is slow"

- it is not Autosys, it is your server that is on it's knees after you threw 174 jobs at it vs. the normal 16 that it concurrently runs!

"We will get better throughput by unilaterally increasing the sched scale"

- sure you will, but first verify that you have a pool of listners that can take the added threads.

 

And having been on both sides of the fence, I do know that the SE at the Support Desk will do his/her best to help you, but unless you tell him/her all the facts, the case will be going in circles.

Example: The DNS server was just moved and now jobs are failing with agent comm errors, the case will not be near resolution unless that fact is included vs. just stating that the agent cannot communicate!

 

All part of the game!

Cheers

Chris  <CJ>

[Steve Carrobis]

Preach my brother,

 

The choir is listening ☺

User's motto, Autosys is broken.. UM that error message is from your app not autosys.

 

Steve C.

[Eugene Ey]

I often liken Autosys to the canary in the coal mine.  It isn't necessarily "Autosys is down/broken" as I've heard numerous times.  It usually is ... Autosys is reporting that the network latency is through the roof, a filwatcher directory path changed, your app server is offline/unreachable, or your script (CMD job) doesn't work.  All of which are outside the realm of Autosys.

[Steve Carrobis]

But AutoSys is blamed just the same... 

[Linda Williams]

My personal favorite -   "It works when I run it manually!". 

 

Are you running it as the same user you have defined in the job?  Of course you aren't.