Something immensely puzzling has come to light following from my recent employment experiences. There’s a piece of software that is – arguably – one of the most critical pieces of software in many organisations. It controls almost every piece of processing the organisations business critical systems does, and it’s – to use a technical term – rubbish.
I’m talking of Computer Associates Autosys here, of course. This software, for the luckily uninitiated, is a scheduling solution. It manages jobs on systems, invoking them based on the appropriate criteria, and managing dependencies between jobs.
Whilst it does do what it’s supposed to, and – at the core it does it very well – it’s the edges that things are badly broken. When you look at a house for structural integrity, it’s very rarely at a sloping angle by a large hole: It’s the small things that give away problems with the integrity: The cracks that don’t appear trivial, the strange differences in colour indicating dampness. It’s the same with Autosys. It’s fine from a distance, but look up close and it has lots of problems.
Architecture
Autosys has a strange architecture. The basics are fair enough: the agents (processes running on machines) are invoked through inetd. So far so good. Where it breaks down is it can’t seemingly decide if it’s two tier or three tier.
The autosys server communicates with the agent after having queried the database. The problem in my view is that the agents must be able to see the database directly. This flies in the face of good abstraction principles, and requires that agents are able to connect to the database. This could easily lead to version problems, and connectivity problems (try connecting a unix box to Microsoft SQL Server). If an organisation grows and takes on a new platform, but has previously decided to use Microsoft SQL Server as the back end, a migration is necessary.
CA argue it “improves reliability” as if the Event Processor fails, agents can still respond with their progress. I disagree, and think abstraction is a very crucial concept in building infrastructures. Supposedly, version 5.0 will solve this, but there are thousands and thousands of Autosys deployments out there that are still not on the latest 4.5 release.
Tool sets
The autosys system has a choice of three user interfaces: Web, GUI and command line. Out of preference, I went for the command line as it was consistent. The Web interface is frequently out of date and boasting strange disparities with the actual state. The Unix GUI is no longer seemingly actively maintained, and struggles with large numbers of jobs definitions. As for the Windows GUI, well, let’s just call it a UI because there’s very little that’s Graphical about it.
If users of the system have to learn about the foibles and nuances of each different interface, it’s no wonder they find themselves beating their heads against a table in frustration at what one of the interfaces displays.
Support
Now here’s one reason many people argue that open source is bad. With proprietary software, and a nominal annual percentage charge, you can get all the support you need from acknowledged experts in the product. Open source solutions make it difficult to get such support unless there’s a company that provides the service (such as Redhat), but then it’s often geographically and technically limited.
Well, that’s all well and good, unless it’s Computer Associates. I’d heard talk of CA support being notoriously bad, but I’m personally shocked at the support I received. I had support staff telling me – on the phone – that with a Windows 2000 server (Sybase backend) “Unix clients weren’t supported”. Er. Pardon? I escalated and got the right answer (they are), and an apologetic support engineer sometime later. But it’s not just big whoops! like that, it was the general “let me check the knowledge base” response.
Compare this to Sybase or – even, surprisingly – Microsoft. Once you’ve got through the 1st line support, the staff are clued up, experienced and helpful. CA just felt like a waste of money. I want experts not librarians at the other end of the phone when I have a problem, especially for the sums of money involved.
Documentation
Bwahahaha!
Sorry, any document that is titled (I kid you not) UAJM45IU really doesn’t get the gold star for clarity. If you must know, that’s the Unicenter Autosys Job Management 4.5 Installation Guide for Unix. But it doesn’t end there. Oh no. Inconsistency seems to be king (Check the documentation for whether wild cards are supported in file watchers: There are two answers), and readability the poor crushed-under-the-foot serf.
Concepts
Autosys has – admittedly – been around for a fair while. Consequently, concepts have been extended perhaps beyond their original goal. The logic definitions and exceptions to the rules takes an age to learn, and a lifetime (it feels) to master. Restart logic depending on whether a component in the dependency chain is on ice or on hold? Don’t ask me! Boxes for organisation rather than initiation? Don’t ask me!
The whole environment feels cluttered and messy conceptually. It’s the technical equivalent of a horrendous piece of programming littered with GOTO’s and #defines to mess up a consistent language.
Good things…
I can’t dispute the fact that Autosys does exactly what it’s supposed to. You just need to know how to treat the thing, and that takes time and experience. But it’s solid. I’ve failed over, rebooted, reconfigured and generally mashed the installations, and it’s kept on working just fine. It continues to schedule jobs in such scenarios, and it recovers from failures in the way it’s supposed to.
It’s much like a good reliable car. It might look very battered, but it does exactly what it’s supposed to: Get you from A to B without getting you too wet, and (hopefully) without you having to push it. So, full marks there, but personally when I’m paying £lots I expect something that feels a bit more straightforward.
And so…
So what’s my point?
Autosys sucks. Big Time. But it does the job. Assuming you know how to speak the language, and are aware of it’s nuances.
Now, what really irks me is that there are few alternatives. I listed a few here some time ago, but Autosys is the Mother of Schedulers. It’s the de facto standard in the industry. But few of the alternatives are much better (I’ve experience with Espresso from Cybermation which was better in many regards, but had other significant problems of its own).
So, I’ve been mulling over whether to embark on an open source alternative that is a drop in replacement to Autosys, ie. can process JIL’s in the same way, as well as supporting a definition that is consistent. Whilst there are open source solutions, many are not actually “open” to the extent of being distributed under the
I’ve played with the concepts before, and a distributed cron was a suggestion from Robert Lefkowitz, publicised by Tim O’Reilly (Robert works at Optaros) as one of the missing Enterprise projects. Let me just say I’m giving it serious thought, because I really think Autosys is that bad. Call it an “itch” if you like, but system administrators and developers do deserve a better alternative, and I’m impassioned enough from my recent experiences (as the above hopefully testifies) to be seriously considering spending some time on this.
Watch this space. Or e-mail me or post a comment if you’ve something to say on this issue.
Entries (RSS)
April 8th, 2005 at 6:40 pm
I’m with you – I’ve been looking around for a open source scheduler for a few years and never found anything that did what I wanted. I know we’re not alone – write it and they will come =)
August 13th, 2005 at 12:11 pm
Has anyone looked at OddJob? It’s open source, does job dependencies. But I could not find any references to handle crash recovery, e.g. restarting a process if it detects failure, try that maybe 3 or more times, if all fails, e-mail the admin. Autosys already does this pretty well.
August 31st, 2005 at 7:04 am
I’m with you; I need a good job scheduler to manage the backends of my websites and something like this is absolutely required for good management.
But as a security person, we cannot make the same mistakes as AutoSys. It’s a truly sucky management nightmare. I’ve been reviewing it today (which is how I found this blog), and honestly … it does EVERYTHING wrong from a security perspective.
It’d also be good to have a scheduler which runs on my Mac, and not just mainframes, Linux and Windows.
Andrew
February 7th, 2006 at 7:28 am
I recently started a new job.
It hurts enough that I have to use Sybase.
It hurts more that I have to use a Windows workstation (at least there is cygwin).
Autosys on the other hand just makes me ask “why”. It makes no sense that such a simple set of tasks can be made so complicated. The only slightly advanced piece of functionality is the file_watcher job option.
Surely we can write something that has 90% of autosys’s functions but is consistent, reliable and secure?
February 7th, 2006 at 7:36 am
Have you looked at http://jobscheduler.sourceforge.net/
March 24th, 2006 at 3:32 pm
Its easy for you chaps to talk about Autosys and how crap is it. For us who don’t have Banking experince, most banks want Sybase, Unix & Autosys experience nowadays .. Now Sybase and Unix is fine .. but most Bank related positions says if you don’t have Autosys don’t apply ..
How difficult is it to learn Autosys? Is there an easy way to learn Autosys like online or Books? Any help appreciated.
Cheers
Mariwan
March 26th, 2006 at 7:23 pm
That’s a little silly IMO. Unless they are specifically looking for an autosys expert who they want to design jobs that use virtual servers etc. then any developer or unix admin worth his salt would pick up the essentials of autosys in no time.
One of the reasons why autosys experience would be prized for managing such advanced jobs is that there are traps you can easily fall into because autosys makes it easy for you to do stupid things – sometimes the manual is silent or even incorrect on limitations.
Setting such an advanced autosys-specific position aside, autosys pretty much consists of writing simple text file configs to specify job requirements and times. Jobs can depend on other jobs and they can be grouped together into boxes.
Once a job is defined it can be manually run, cancelled or suspended (put on ice) using a commandline tool.
That’s about all there is to it. You could read the autosys manual pdf from ca.com and probably wing any autosys question they asked.
May 8th, 2006 at 9:17 am
WOW!!! What an eye opener this is!! My company purchased autosys because they thought that it would solve the problems that Unicenter Workload Manager was causing. I am for all practical purposes the resident expert (said with tongue in cheek) for autosys. In the beginning it worked really well and as stated it pretty much does what it suppose to do…some of the time.
Autosys was owned by another company before CA got a hold of it and the folks I spoke to said that it was a pretty good scheduler. CA wanted to make it “the scheduler” of the industry. But somewhere someone forgot to tell them to hook all the pieces up so that they all worked together. For example, in cross platform communications there is real problems getting autosys recognize a job coming from say the mainframe. The broker, or CCI, or whatever it is suppose to be called fails miserably. CA has no answer for it. What really is frustrating is you open at ticket and then they start by asking you to send all specifics of the the environment. Not an unreasonable request. Then starts the traces and “bouncing” the Event Processor and the mainframe components. gather up all this and send it to CA Technical Support to ponder over only to tell us they need another trace because what we sent them was inconclusive. Thats just for starters. We also have a CA Unicenter Enterprise Job Manager, the window to Autosys where you can start and stop jobs, control resources with sendevents, edit schedules, etc. This monster is as much of a pain as autosys is, and since there are very few users that are going this route as suggested by CA there are few hits in the knowledge base on problems. We seem to be only part of an unlucky few to have experienced any of these errors.
What is really really so frustrating is that CA says that autosys is the “best practice” scheduling solution. What they didn’t say was that however you were doing schedules before would now dramatically change. You basically have to learn it all over again.
I believe autosys can be a good scheduler, but it takes time, resources, training and a whole lot of patience to get any where close to a good comfort level with it. It is a nightmare with no end in sight. Sometimes as is the case with me there is no time or the expert that was there before has gone on to other things and no longer accessible so its fly by the seat of your pants.
Autosys is a collection of several pieces of software that are disjointed. They have no solid base and rather CA spending the time to make it all work and work together, they are acquiring other software companies so they can add them to the big pot. There needs to be better more practicle solutions for businesses and they need to be more user friendly, a term that CA I think has forgetten the meaning of.
Thank you for letting me vent.
Mark Berggren
mberggen03@cox.net
July 3rd, 2006 at 9:33 am
[...] And finally, that other rule. If a company doesn’t make it’s manuals and documentation open to potential customers (much as with Autosys), it speaks a lot about their (lack of) confidence in their product, and should serve as a warning to any potential customers (Good to see Astaro’s is available! (Firefox not Safari though). [...]
August 16th, 2006 at 10:50 am
Sorry, but you’re all amateurs talking about an application you don’t understand because it’s not built for you. AutoSys is an ENTERPRISE scheduler for large companies who want a VERY robust solution for all of their servers; Unix, Linux, Wintel, Minis and Mainframe.
In no way is geared towards running a few jobs on a few Web Servers. No company in their right mind would want to spend millions on a scheduler and then expect their staff to learn it over the weekend. All of your gripes just show that you’re reviewing the product from your own little world and not from a position of a realistic customer.
As Mariwan said, all of the big banks use AutoSys, why do think that is? Are they all delluded? The reason is that is incredibly robust, it’s easy for the users to create their jobs, it’s secure (using eTrust Access Control) and it has good reporting functions. It’s even easy to adminstrate once you know how it works. I should know I’ve used it for 8 years.
Finally just to correct some errors in your post:
You can have Unix clients on a MS-SQL Event Server by using the Univeral Agent.
No AutoSys admin worth his salt would get into creating the jobs for their users, AutoSys allows the users’s to create the jobs themselves, leaving the admin to advise and admin.
The next version of AutoSys is R11, not 5.0. It drops the DB component from the Remote Agents and fully integrates the security component.
Thanks for letting me correct.
Jon McAlroy
August 16th, 2006 at 11:25 am
Right. Amateurs. I’ll just go back to my 8 x quad cpu Solaris servers running over 1,000 autosys jobs a day and consider that.
I totally agree that the high number of supported platforms is a deal winner for companies who really need that. Many “enterprises” use no more than three platforms : A commercial Unix (usually only one of Solaris, HP-UX. Irix or AIX); Windows; and Linux. Some probably only use one.
My (apparently amateur) experience is that autosys can be quite flakey and it’s documentation can be inconsistant. Good documentation and support is just as important as the quality of the software in calling a solution robust.
As for a few jobs on a few web servers – at my previous job we ran literally hundreds of web servers (as in seperate boxes) as well as thousands of background jobs that formed the entire software system of an ISP with nearly half a million customers. Hardly amateur, and we ran no commercial scheduling system. In fact we had no commercial software at all – and yet we had significantly lower costs per customer than our rivals. Hows that for insourcing.
Of course I should avoid getting dragged into this conversation especially as your use of all caps for the word enterprise gives away your humerous intent. I just don’t like being called amateur
August 16th, 2006 at 12:19 pm
Sorry I’m not trying to get into a pissing contest but 8 Solaris boxes doesn’t constitute an enterprise (the caps were for emphasis, not humour). I work for a very large bank and I’ve been in the financial industry for 9 years now.
When I say enterprise (perhaps I should have said ‘large’ enterprise) I’m talking over 3000 servers (not desktops) in one region, including several mainframes, and dozens of F15k’s and E10k’s, AS400’s and VMS minis. O/S’s include Solaris, HP-UX, AIX, Linux, MVS and everything in between.
AutoSys wise, we’re talking 50,000 Production jobs deffined (x3 for Dev and UAT) with hundreds of thousands of executions per day (and growing).
And most importantly we’re talking about admin’s who only administrate AutoSys and not SA’s/DBA’s who also do AutoSys.
I’ve used other schedulers including TWS/Maestro, Control-M and a few in house efforts and they don’t compete.
ISP’s do online (as opposed to batch) processing, apart from a few accounting applications, I’m not supprised there’s not much batch to contend with.
I appologise if I offended you, I’m just trying to give a different perspective from someone who knows and use’s AutoSys in a way some of the other readers probably don’t. If you’re having issues with your implimentation then I can recomend you sign up to a eMail forum for AutoSys admins: http://www.stirlingsystems.com/as_forum.html
Good luck and best wishes.
Jon
August 17th, 2006 at 2:40 am
Not to worry, I didn’t really take offense. I should also clarify that the 8 servers are just those I personally work on every day. The organisation I work for has over 1100 servers and more assets under management than the entire Australian Stock Exchange. I have also use Control-M, although only for a few months.
I do subscribe to the autosys mailing list and also whole heartedly suggest that anyone who has to work with Autosys sign up, not just admins (surprisingly few users seem to).
I also completely admit that I am intentionally taking one particular view, as are you, since that’s how productive discussions often take place (hence why no real offense taken).
[Usefull discussion starts here:]
So with all those formalities aside, one of your comments has helped me understand why I feel so violently opposed to autosys. I still don’t think it’s particularly good product, but what I really don’t like is batch processing itself. Surely 2006 best practise should not be poking a few files on a few different ftp servers, hoping they get there within a particular time window, and then running (often many different) programs against those files.
I would have thought that in such a mature industry as finance we would, by now, have more robust processes such as simply requesting the data we want from the appropriate provider using some form of real time process (whether a web service, EDI, MQ messaging, whatever).
Slightly off topic, but I’m interested to hear if anyone coming across this thread has any opinion or insight into whether this sort of approach is slowly starting to happen – because I don’t see too much sign of it.
August 18th, 2006 at 1:54 pm
I think you’ll always have and need Batch processing. Just for economies of scale it makes sense to have a server that runs the online service during business then crunches the data over night rather than two boxes or one huge box that can do both at the same time.
I also think that a batch gives you more control and is easier to understand and control. Certainly processes that require instant processing are riskier than having the ability to process the data when you’re ready.
On the other hand I think systems are moving to a middle ground. The next version of AutoSys opens itself up as a Web Service that can trigger and be triggered. Though CA are putting little focus on this feature, I think it will have the biggest benefit and impact to users. I try to impress upon my users the benefits of avoiding timed starts and filewatchers in favour of direct dependencies between the various client applications. Plus tools like JAWS and others help identify “design latency” that can help your batch become as efficent as possible.
Regards
Jon
September 1st, 2006 at 7:24 pm
This is an interesting discussion.
I don’t think anyone would question that Autosys fills a vital roles in many large enterprises. That doesn’t make it a great product.
To suggest that large banks use Autosys because “it is incredibly robust, it’s easy for the users to create their jobs, it’s secure ..” is naive. Enterprise software purchases are sometimes made because a product best fits requirements. But changing platforms is tremendously expensive and the real reason that most banks use Autosys today is that most banks used Autosys five years ago. It is familiar, known and safe. People once quipped “noone ever got fired for buying IBM” to explain why IBM mainframes & minis outsold cheaper and better alternatives from Dec, HP and the rest in the late 80s. The same applies here. Today Autosys is an ugly overcomplicated mess because it has been used far beyond its initial vision and possibly underinvested by Platinum and then CA. The poor state of Autosys is a a perverse metric of how valuable it is. A less crucial system would have been trashed years ago.
Unfortunately, whilst creating a better Autosys is well achievable (and presumably has been achieved ) marketing it is a much harder task. The only way things will improve is if an opensource product becomes popular at the grass roots SA level and gets marketshare from the bottom up. At that point it’s much easier to say “Hey System’s X,Y are using SuperDuperFreeJobScheduler and do well with it with no cost – perhaps we should expand it’s use?” Unfortuantely SA tools are much less cool than developer tools or visual tools so its less likely that an open source projevct will ge the same concentration of smart developers that allowed perl, apache,tomcat,ruby,eclipse,ant,CVS to become widely used. I hope that I am proven wrong and an amazing Autosys killer is waiting in the wings.
September 2nd, 2006 at 2:58 am
Peter, I think that’s an excellent summary of the situation.
On a totally unrelated note, it’s interesting how a single blog post can be a place for discussion for over a year. I really must add email notification for threads on my blog@
September 11th, 2006 at 6:14 pm
Jonathan McAlroy said: I’ve used other schedulers including TWS/Maestro, Control-M and a few in house efforts and they don’t compete.
I used AutoSys for over 8 years. I recently moved jobs, and the company I’m at now already has Maestro in house. They put me on a team to evaluate AutoSys vs. Maestro, having heard that AutoSys might be a better way to go for the future. I know nothing about Maesto, but one of the Maestro experts has already given thumbs down to AutoSys, listing things that AutoSys can’t do that Maestro does.
Since you mentioned Maestro, and know AutoSys very well, I was wondering if you could list a few things that AutoSys does better than Maestro.
If you get a chance, I’d much appreciate it. Or anyone else who could comment on this for that matter.
September 12th, 2006 at 12:27 pm
There are so many factors to think about when it comes to deciding to migrate or not to migrate that you’re almost better off with a blind guess.
I think the biggest advantage AutoSys has over Maestro is it’s phillosphy and archetecture.
To my mind Maestro is a more “Mainframe like” application where the backend is closed off and it’s not meant to be understood by the users. The AutoSys backend can be seen by anyone with a ounce of understanding of SQL and the command line utilities are simple and elegant. Because Maestro batches are split between streams and jobs there’s a leap of faith when it comes to getting what you want as opposed to AutoSys batches which are self contained in JIL format.
I also think AutoSys has left the opposition for dead with the recent improvements. R11 is the first mainstream scheduler to open it’s self as a Webservice, the EIAM security improves upon the already great eAC and the UWCC is much better than TWS Graph and JSC. Which I think is the biggest advantage of all; anyone can create AutoSys jobs within a few minutes.
regards
Jon
September 19th, 2006 at 8:04 pm
Hello,
Very simple question – would you recommend to move Maestro to AutoSys?
Let’s say if you have a choice of not doing it, will you stay with TWS(Maestro) or you’ll move it. Thanks.
September 20th, 2006 at 5:45 am
Well I did have that decision to make and we’re consolidating onto AutoSys from many schedulers including Maestro and TWS (Mainframe).
Obviously everyone’s circumstances are different so it doesn’t really help you but for us, the single biggest concern is the availability of AutoSys skills in the Application Developer Workforce and the AutoSys Administration work force (we’re a big company).
September 29th, 2006 at 5:08 pm
This is a great discussion; I have been deploying Tivoli Workload Scheduler (TWS) for 10 years. It hasn’t been called Maestro since Tivoli bought the Unison Corp in 1996. I would say that the TWS architecture is superior to Autosys, especially when it comes to fault tolerance. I don’t know about all of you but I can’t hardly spell SQL so I would say that that isn’t a plus for Autosys.
The leap of faith has me puzzled though. TWS is very similar to Autosys in its definition of jobs and scheduling information. I would like to know the future of Autosys, CA now owns 3 distributed scheduling packages (Unicenter, Autosys, and Cybermation) which one will they drop and force its users to migrate?
Lucky for TWS, Autosys has this export function that produces a text file that Tivoli Services can use to import %95 – %100 of the scheduling information into TWS and be running in no time.
November 6th, 2006 at 7:10 am
Check this out..
http://www3.ca.com/press/PressRelease.aspx?CID=68027
http://www.networkcomputing.com/story/singlePageFormat.jhtml?articleID=159903437
November 17th, 2006 at 4:20 am
Can anyone tell me the difference between Control-M and Autosys.
Thank you,
-Pradeep
December 28th, 2006 at 4:07 pm
Pradeep – The difference between any batch management system will always be the same. What is the difference between an apple and a pomegranate?
FYI
As for Autosys and its uses, IMHO its the bets of breed for what is out there; now. And like anything, how it works depends on the foundation it sits upon. If you slap it together then it will behave just so. If you set up a solid foundation then it will achieve your goals with little issue.
December 28th, 2006 at 4:57 pm
AutoSys is still my favorite scheduler; there’s a simplicity to the basic operation that just clicks. And what’s wrong with Sybase? The AutoSys database (EventServer) is not for data mining, high-volume transactions, or long-term archiving — it’s a temporary store for Event Processing state data. Sybase in this context is simpler to run and requires less oomph than the alternatives.
Yeah, AutoSys can be a little quirky but if you push through you’ll understand the product better – each quirk is just a learning opportunity. And every product in this space has its quirks – just like all software. Seems to me like a lot of the AutoSys bashing is not so much “amateurism” (?) but more a good bit of “Better the devil you know ….” I guess.
I think there’s plenty of room for improvement with respect to Support, Usability, and overall product evolution as provided by CA. Even with CA having owned the product for the last 6 or 7 years, up through at least version 4.5, the core architecture has undergone only relatively minor changes. Reason being is that at the core, it’s solid and follows a pretty consistent and simple logic.
The components follow a simple architecture and configuration issues are easy to track down. IMO simple is always better, the fewer “moving parts” the better. Contrast with Control-M – lots of moving parts, lots of players involved in just getting one job to run and can be a bear to troubleshoot … I think only cron and at are simpler, though severely limited. It is true that CA continues to try to add layers of their other products on top of AutoSys, but they’re often not widely adopted for many of the reasons mentioned by others. But even if you need to implement some of this extra baggage, success comes back to the understanding of the mechanics under the hood.
On the job scheduling side, the biggest hang-up that classically trained schedulers will have is that AutoSys is event driven. Most other schedulers work on a day schedule and so thinking about complex interactions and job flows is quite different in those other products than in AutoSys. The key to this one is just to realize that things are different in AutoSys and try to internalize the logic. The only thing that matters to AutoSys is now and “changes to now” in the form of events that can trigger subsequent actions (which then generate more state changes via events).
Since I started out with AutoSys, I had trouble going the other way around. As I began to understand non-AutoSys scheduling (CTM, TWS, …) I could almost picture the little man collecting his stack of punch cards from a master library at 7 am and putting them in the hopper for mechanical processing over the next day. How antiquated!
Finally, I’d recommend this: If you really want to bash AutoSys, get to know it really well first. Some of the other pro-AutoSys commentators on this thread are world-renowned AutoSys experts but they didn’t get there purely by reading doc or wishing they had some other tool – they got in the game and played hard.
If you do so too, a lot of the concerns you might have had as an outsider will vanish. Don’t worry, they’ll be replaced by a whole new set of concerns — and with a pretty good, well-managed event-driven scheduler/job management system in place too.
Pete
January 3rd, 2007 at 10:19 pm
Hi,
Can someone let me know if file watchers in autosys identify whether the file is complete? Say, I have a huge file which is being imported from an external location. I have a file watcher set to detect this file. will my watcher report as soon as the file is created? How will I detect whether import is complete?
January 5th, 2007 at 4:29 pm
Autosys has a watchfilemin_size value, but the manual recommends to set up your process to generate a zero KB file when the data file is completed writing. You would look for the zero KB “flag” file. This prevents errors when the data file creation is interrupted after the minimum size value is reached, but before the file is complete.
Charles
January 5th, 2007 at 10:34 pm
Another option is to watch file location (a) but transfer/write the large file to locaction (b) on the same physical disk. When the transfer/write is complete, move the file from (b) to (a). File moves are atomic so when autosys notices it is there the move is guaranteed to be complete. Well, for Unix anyway – can’t speak for windows although I assume it would be the same.
January 6th, 2007 at 5:23 pm
File watchers do have a min file size, but there’s also a polling frequency, which is the usual criteria that’s used if you don’t have a minimum size required. IIRC the default is to poll every 60 seconds to see if the file size has changed, but this polling frequency can be adjusted up or down depending on how fast/slow the file transfer is going. In the lastest released version (4.5.1), there’s also the ability to use wildcards to match a file whose name may vary, say to include a date/time stamp at the end.
If in an earlier version or if you want a little more flexibility, see also SSG’s web site under resources, there’s some pretty good tools in the toolkit, including a customized filewatcher that you run as a command job.
January 11th, 2007 at 7:44 am
Hi Steve/Pete,
Thanks for your comments.They were of great use.
-Pradeep
February 6th, 2007 at 7:51 am
Very intresting discussion. Especialy I enjoyed the part about AutoSys and TWS. Let me show you my point of view.
I have 4 years experiance in working with TWS for distributed and 1 year in working with AutoSys.
1. Both schedulers works fine and stable. Basics of scheduling in both cases are easy to learn.
2. AutoSys is more difficulte to master your skills. It’s more sophisticated scheduling tool. It allows you to for more. You can be more creative with AutoSys but if you’re not carefull enough or just not experiance results can be different then expected.
The fact that AutoSys is more sophisticated is an advice but sometime can be big disadvantage. I working on migration of TWS schedules to AutoSys and I think it is much simpler to do then migrating AutoSys to TWS. I wish I’d never had to perform migration in oposite direction.
3. The fact that TWS generated day plans and flexibility in setting start of day in TWS is very handy in such companies like mine where we run most of the batches overnight – it simplifies the logic of scheduling
4. The fact taht TWS generated day plans is pain in the ass if you need to modify batch after the plan has been generated or if you need to ad-hoc submit batches with interbatches dependency.
5. Fault tolerancy – some says its advantage other says it disadvantage. First of all you don’t have to define TWS agents as FTA. Maybe in some cases it is better to stop processing of batch when domain manager is down then lost control on the batch. However I think in most cases fault tolerancy is and adivce.
6. HA model in AutoSys is something I was missing in TWS
7. There is no question that using RDBMS in AutoSys is BIG advantage over TWS. As long as I was allowed to do in in my company I was using TWS/WebAdmin with PostgreSQL database to store historical data from TWS. Generating reports from TWS is horrible.
8. Both systems should be used in companies that have thousends of jobs to schedule.
9. If I would develop alternative scheduler I would try to use AutoSys job definition languge, use sql database, implement day-plan concept from TWS, keep out from using Java applets in web application for managing the scheduler
February 22nd, 2007 at 7:39 pm
Hi,
I would like to know more about AutoSys. Please help me in following scenarios:
1) I have boxA which contains Job1, job2, job3 which run in sequence. My Job1 is successful but Job2 has failed and hence BoxA has terminated without running Job3. I want to restart Job2 and then run job3 in succession so that entire box completes successfully. There are many other box jobs dependent on exit status of this box.
How can I achieve this?
2) In the same scenario, if from job2 I’m calling a wrapper script which performs 3 steps. My step2 has failed causing failure of job2.
I want to start my job 2 by passing an optional argument called step_no to the wrapper script.
Does AutoSys support optional run arguments? I should be able to pass this run argument only while restarting job. Is this possible?
Thanks
February 23rd, 2007 at 7:41 pm
Scenerio #1.
Make the startingof job2 dependant on the successful run of job1 and the run of Job 3 dependant on job 2. Before the restart of the box, put Job1 ON_ICE (Sets the exit condition to S) and restart the box. After completion, change job 1 status to inactive.
Scenerio #2. Do a one-time over-ride of the command condition of job2 to pass the optional argument of step_no to the wrapper script. Re-run job2.
I’m sure others will have even better ways to accomplish the same.
February 24th, 2007 at 12:18 am
Reader your initial suposition is wrong. By default the box wont terminate because Job2 failed. The box will only still be running until the jobs within it have run through and either succeeded or failed. You can either re-run job2 or change it’s status to SUCCESS and job3 will run.
You could have a Box terminate condition on the box which would make it terminate in the event of a failure of job2, but it sounds like this is unwanted and should be removed.
regards
Jon
February 25th, 2007 at 2:33 pm
Jon,
I did not assume box terminates on its own. I knw that I need to configure it.
My requirement is to have box terminate if any of the job in the box fails.
Thereby my subsequent jobs say job3 should not run because job3 depends on some intermediate files created by job2.
So my requirement here is clear. I should have condition on all jobs to make the box terminate if any jobs fail.
My question was how can I restart my jobs from the point of failure and make sure the subsequent jobs also run.
Regards
A Reader
February 26th, 2007 at 7:51 am
First case
The box would terminate ONLY if you would specify in job2 defintion “boxterminator: y” . By default boxterminator flag is set to ‘n’ which means that failure of job does not terminates box it is in and then after rerun of job2 job3 will start if job2 will finish successfully.
So do not configure the jobs in the way to terminate the box! It is not necessary at all.
Second case:
I don’t think its possible. If I were you I would split the job2 into 3 jobs, each of the job doing single steps. General rule for all schedulers like AutoSys or TWS is: keep skript as atomic as possible. It is always better to run 10 jobs with 10 simple scripts then 1 job with 1 script doing many things.
March 2nd, 2007 at 5:54 pm
Reader,
Well if your initial supposition isn’t wrong then your logic is. A box is a scheduling tool, not an organisation tool. As well as starting/activating jobs at the sametime it also ensures that there’s one job execution per box execution. If you don’t want that to happen then dont put them in a box.
So the solution is simple. Take the jobs out of the box and then you can rerun them without having to ensure they have all run.
On your second case Michal is correct, as a general rule you should have one task per job. Otherwise you have to script what AutoSys does automatically. For example you could use an AutoSys Global Variable to record the last successful step and have each step of the job check and update that global variable to see if it should be executed..
Good luck,
Jon.
April 4th, 2007 at 11:39 am
Just a site-owners aside here. I’ve been very impressed with the quality and insightfulness of the various points made by the contributors here, and I’d like to encourage folk to continue to make points regarding pro’s and con’s of Autosys as they feel appropriate.
However, I’ve received (and denied) a number of submissions asking me to list advantages/disadvantages of Autosys, TWS and other such systems, or to seek to advertise a particular product, or to answer a particular technical question regarding Autosys.
Whilst in the last case I’ve done that in the past, I’m not going to be doing so any more. This thread is a conversation about Autosys’s shortcomings (and retorts to that), not a help forum. It’s higher level than the nitty gritty of file watchers, or box logic. Many of the posters receive e-mail updates, and (unless they say otherwise) they’re probably not interested in receiving lots of questions: There are forums for such user questions.
I might post something dealing with nitty gritty sometime soon (Goodness knows there’s a shortage of open access content regarding Autosys).
Hope posters past, present and future appreciate the reasoning behind my decision.
October 10th, 2007 at 9:21 am
It might be worth pointing out that the next release of AutoSys – R11 – has just become Generally Available.
This version brings with it:
New functionality such as time-based dependencies, blobs, better application grouping, machine offline, new ways to set up cross-instance.
Changed architecture – agents no longer need a database client, new Application server ‘brokers’ between agents, scheduler and database, security integrated into CA’s Embedded Entitlement
Caveats:
Conventional wisdom dictates that a new AutoSys release takes up to two years (yes, really) to have all the kinks ironed out of it. The extended beta cycle of R11 was supposed to mitigate against this, but we’ll see. A good way to keep track of the progress and pain of early adopters, is to subscribe to the AutoSys forum linked above.
There is a new version of the GUI too, called UWCC R11. Any and all other older GUIs for AutoSys disappear with R11. Unfortunately, UWCC really is horrible – everything about it from architecture, to performance, to look and feel, to functionality is poor.
Unfortunately, CA’s insistence on shipping a mandatory MDB with everything, means that you will finish up with their Ingres database in your organisation, should you want it or not.
November 6th, 2007 at 4:28 pm
I haven’t dealt with Autosys myself but I know of people who do. Yes, I am very interested to see open source initiatives in this area. It also strikes me that research in the area of High Performance Computing could possibly provide solutions? What about GRID schedulers, e.g., Condor-G?
However, I believe that if a number of enthusiastic people were to knock up a full-blown distributed scheduler that does what it is supposed to do, is well-documented and is capable of questioning the authority of Autosys in the market then it will eventually be made closed source so that enterprises can be asked to pay millions for it; or Google may offer to buy it for several billions!
February 1st, 2008 at 1:08 pm
Having tried most of the market leaders I cannot really see an alternative to Control-M. Ok, it is aimed at “high end” usage but the flexibility and features are absolutely streets ahead of Autosys. The one problem is that it is so open and has so many features that it can be intimidating to new and occasional users. The problem usually is not “Can I do this?”, but “Which one of the dozen different ways is the best way to do this?”.
February 18th, 2008 at 4:06 pm
I just can tell you my story – we were looking for a product to get rid of CA – we were pissed off with their bad support and we didn’t like their strategy of buying all those products together – and then we found UC4. the softwares architecture is superior – you can add additional servers to share the workload without problems – you can use them as an active/active solution – simple failover. Farther they have a much better integration with SAP than Autosys. I love that product – it’s so powerful, and they have really big installations in place – I saw that they schedule over 1.000.000 jobs a day at SAP’s SAP-Hosting. Maybe you’ll take a look at that – I would recommend (I like it much more than autosys – support is just “wow” and the documentation is the best I’ve ever seen with an automation tool)……
Did someone of you already install the r11 version? would interest me how it works – i suppose a lot of troubles – not?
February 18th, 2008 at 6:08 pm
Well I’m the best admin in the world and I say Orsyp is the best scheduler..
No wait, Tidal.
Then again, Espresso/dSeries has a certain charm.
Mind you, Cron is free.
Has anyone just tried using a bit of paper and executing the scripts when they need to?
May 28th, 2008 at 2:31 am
Autosys has many modules, some good, some bad. The modules change frequently. Many modules disappear within a single release e.g. Xpert (3.x only), Web Interface (4.x only) and eTrust Access Control (4.x only). For a new example try CleverPath (used in UWCC 1.0 & r11 and dropped in r11.1). If you’ve learnt every module you’ll be pretty skeptical about the future. The Autosys roadmap meanders violently and it has a few very big potholes in it! Even with dozens of modules it is still common to buy 3rd party tools to make Autosys acceptable to your users (e.g. JAWS for SLAs and IXP for monitoring/forecasting).
One key problem with Autosys is that a job cannot be placed in multiple job-flows (or “boxes” to use the Autosys terminology). Whereas the other schedulers (e.g. Cybermation, Tidal, TWS or UC4) include that capability. For example, a UNIX healthcheck batch that uses the same commands on every UNIX host must be replicated 100 times if you have 100 new UNIX servers. If the the healthcheck batch consists of 10 jobs, then 100 copies of the batch results in 1000 jobs. Most other big name scheduling tools will do this with a single job-flow with common job definitions (10 jobs) and point them at 100 servers. The Autosys method is terribly inefficient (to change the housekeeping flow you’d need to make 100 changes). Autosys doesn’t have an object oriented architecture in 4.5 or r11 – I’ve seen no plans for a oo approach, has anybody else? For a true oo approach try Tidal, UC4, Cybermation (now CA owned) or DollarUniverse.
For Autosys 4.5 security you must install eTrust Access Control but as a side-effect you’ll have a massive security tool that not only secures Autosys access but the whole operating system. It can even prevent (UNIX superuser) root doing anything on your UNIX system. It also interrogates every single system call on your system resulting in an inevitable system performance deterioration. The latest security solution for Autosys r11 is EIAM; it appears to be an improvement on Access Control but there is very little decent documentation available.
Promoting jobs from one environment to another is not part of the Autosys product. You will need to pay for a 3rd party tool. However to see jobs promoted efficiently from development to test and from test to production look at Tidal or UC4.
The UWCC portal based product is heavyweight, slow and doesn’t have a high availability option (yet). The previous CA Web Interface was quicker, more robust and presented the job-flows better bur now its been dropped. Some pay for 3rd party tools like IXP (with high availability and security built-in), others wait for the new UWCC.
For predictions and forecasting CA don’t produce their own tool (unlike BMC with their CONTROL-M/Forecast module for example). You will need to pay for 3rd party tools like JAWS from Terma or iDash from Paragon.
In conclusion – Autosys has very many modules and the product continues to grow (web services module has just arrived) and only time will tell whether it deserves its massive following. Consider saving-up for a trip to CA World 2008 to see the new plans for r11.3, r11.5 and r12. Also look at every other tool on the market for alternatives.
June 6th, 2008 at 2:59 am
I can’t claim to be a great expert in autosys, just a developer that produces masses of JIL code but here are my 2 cents worth…
re: the lack of a built-in method to promote schedules (from dev to test and finally into prod) in autosys – we use a freeware utility called make_jil. It builds code for multiple environments from a single source and uses RCS for change control (i.e. to check-in/check-out the JIL files and record change history). It was one of a few freeware tools we were given (nothing fancy, mostly ksh and perl) but I only used this one tool.
Also from a developer’s perspective I have to say that its easier to view schedules in the old web interface than it is in the UWCC interface (I think Antony summed it up perfectly earlier in the stream “UWCC really is horrible”!) We are not using r11 though, so maybe the job-flow rendering improves then.
For what its worth, 10 years ago I was using control-M and even back then the visualisation was miles better.
June 6th, 2008 at 12:01 pm
The make_jil.sh script is from Extra Technology. I suggest you change the check-in and check-out functions to use your preferred tool (e.g. Clearcase or cvs).
Andy – UWCC R11 is no better at presenting the jobs than the previous couple of versions as far as I can see.
June 8th, 2008 at 9:47 pm
This page is 3rd in the Google search list for “AutoSys R11″ – good showing for a 2005 blog!! It is fascinating reading, and way more controversial than the AutoSys forum!
Re: Jonathan’s contribution (response 18) on 12 September 2006 (including the comment “AutoSys has left the opposition for dead with the recent improvements”), he wrote about AutoSys R11 like it was actually released. Some readers may have assumed that in 2006 R11 “really” incorporated a working Webservice (it didn’t) or that EIAM worked (it didn’t). In September 2006 R11 was only Beta (and a pretty shaky beta at that), a whole year away from being made generally available.
It is 1 year 9 months down the line from those comments but there is still not a single ‘large’ enterprise (using Jonathan’s definition) using AutoSys R11 in production (according to my CA salesman) anywhere in the world. Dozens of sites are “nearly” ready but too scared to take the final plunge. Dozens of highly paid (and highly skilled) AutoSys consultants (like Jonathan?), making a small fortune learning it’s intricacies.
I have hands-on R11 experience, recently working on an R11 project for a couple of months, before our team of Engineers were sent on other projects including (JAWS & IXP evals), so the company could wait for the product to mature.
I agree that R11 AutoSys will eventually be useable but think that it will be wise to wait until 11.3 or 11.5. I guess that Jonathan will be one of the first to do so, “very large banks” can make anything work with the best staff available to them.
Just though I’d point out that it is ironic that in October 2007 TWS 8.4 was made generally available with an embedded WebSphere Application Server which 1. works, 2. has documentation and 3. is actually understandable.
TWS 8.4 also introduced event-driven workload automation (which will suit those brought up with AutoSys) .
So still no ‘large’ enterprise using AutoSys R11 in production anywhere in the world, ask the AutoSys user forum. Meanwhile, ask TWS Admins how many have upgraded to 8.4 and use it as their main Production scheduling infrastructure? Answer is most of them (and incidentally it works).
June 11th, 2008 at 5:41 pm
I was naive..
But we do have r11 working now and we’ll reap the benefits and gain the experence required to meet our businesses requirements while you’re all sucking your thumbs
I’m not going to critise TWS as I now manage that too, 8.2 at the moment but we’ll move to .3 or .4 when the business demands it.
regards
Jon
July 6th, 2008 at 12:04 pm
My problem isn’t with with the core AutoSys product (there’s not much wrong with the core of 4.5.1 and r11 is not mature enough for adult discussion at the moment) but I have to say that UWCC is rubbish.
I’ve seen a number of interfaces over time. Jobscape and Timescape were good (liked the attempt at forecasting and Gantt flow although they were old-fashioned and required X-Windows emulation), Web Interface was okay (it could have been redeveloped into something great if they added HA and forecasting), UEJM was an unpolished turd, which turned into UWCC (a polished turd).
This year we finally admitted that UWCC is non-scalable, inaccurate, poorly presented, restrictive, overly complicated, slow, NOT highly available, did I mention slow?
Our act of genius was to go back to Web Interface and wait for WCC to be replaced by CA with a product that actually works and has high availability built-in (i.e. not WCC SP4 or WCC r11). When CA drop support for Web Interface we will simply place out heads in the sand.
After spending a heap of money on a high spec Windows server, stuffing it full of memory and installing UWCC, the result was three times as slow and twice ugly as Web Interface (which didn’t require any additional hardware). Perhaps Ingres and the CleverPath Portal were to blame? No point asking CA since no-one in their Tech Support organisation can support either.
I would love to know how CA manage to sell AutoSys to new customers. How could any buyer sign-off on a key infrastructure tool where a key component like the user interface isn’t highly available? Is it really still the market leader?
July 10th, 2008 at 5:44 pm
Wow- what an amazing thread! I would love to see an AutoSys message board somewhere (not hosted by CA). I’ve subscribed to the forum for many years, but it’s difficult to read and keep up in that format. Any volunteers? lol
I really appreciate the open dialog here.
July 16th, 2008 at 10:01 pm
Im relatively new to the automation industry as an administrator. With a mere 8 years AutoSys experience working up from an operator with basic point and click functionality up to an AutoSys Sys admin.
One thing I have grown to realise that AutoSys’ simplicity has been its distinguishing feature to date. The idea that pretty much anyone can sit down in-front of a terminal with minimal instruction and design a batch within minutes has helped many clients widely deploy the tool into the foundations of there environment.
There has been a lot of discussion above regarding the various interfaces to AutoSys and the merits of each, but truth be told I think the interface choice/combinaion is down to your environment and your organisational demands. It is good that there isn’t a singular option. Competition drives productivity and presently that is what I am seeing.
Of the AutoSys interfaces to date JobScape, 4.5 Web Interface, UWCC and iXp all have there merits and it would be incredibly naive for us administrators to simply to say that everyone should like and use a singular toolset and disregard the rest.
My experience of UWCC, CA’s latest offering is that it is suited more to high level management requiring an overview of their whole estate. iXp on the other hand seems more suited to those environments of a much larger dispersion.
We each have our own distributed environments, some housing a central automation team others placing application developers in the driving seat.
Who’s to say you cant use them both?
Each of them compliments AutoSys in their own way, WCC through native CA terminology and high level reporting, iXp through enabling AutoSys users to do exactly that, use AutoSys to its full capability with ease!
With regards to r11 the automation industry has been scheduled a long overdue overhaul. It is hitting an exciting time. The way in which each of the vendors addresses front end will inevitably be interesting.
There has been a lot of comments around poor implementations etc what we all seem to forget is that each of the vendors are driven to change because of us and our internal community’s.
We are very quick to criticise but can you honestly say you would like the job of catering for the whole automation industry. CA AutoSys, UC4, BMC Control-M or Tidal, each have compelling elements and each are trying to get right the feature set. No one product will get it right 100% of the time and the weight lies on our shoulders.
I don’t proclaim to be an expert but im of the belief that there is more than one way to skin a cat! As automation administrators I think the best thing we can do is remain open minded, competition never hurt anyone its just what the industry needs. Use the resources out there in the industry to help you choose your toolset, lisen to peoples experiences of each product, consult with experts in the different technologies.
Just because you have been on a specific product for years doesn’t mean that it has to be painful to move to another, no one product will get it right 100% of the time thats why we are paid what we are paid. The weight lies on our shoulders, there certainly isn’t a right or wrong decision, there is simply a best fit!!!
Thanks for reading…
Ade
July 17th, 2008 at 5:26 pm
We have been looking to move from 4.51 to R11 but heard that there are serious problems (we are looking at Linux/Oracle). I am interested in the comment from Jonathan:
“But we do have r11 working now and we’ll reap the benefits and gain the experence required to meet our businesses requirements while you’re all sucking your thumbs”
Does this mean it really does work, do you have R11 running reliably in test or prod? This may change our view on the risk of migrating.
Thanks
Rich
July 24th, 2008 at 4:22 pm
Is any single large customer using AutoSys R11 in prod at this time? Hell no. Not anywhere.
r11 success stories refer to dev systems. Please correct me if Im wrong (probably in 6 months when you hear of the first prod golive).
Anybody crazy enough to go prod with r11 in a big site at this time really will have plenty of time “sucking their thumbs” while they pickup the welfare check. I admire the r11 pioneers for their pluck and perseverance but even when they do make a successful golive I would still recommend waiting 6 months for the bugs to shake-out. Then another year while UWCC is replaced or rewritten.
When r11 actually works, r11 experts will become gold-dust and the good ones will probably be very very expensive.
July 24th, 2008 at 5:56 pm
Stevie C? Not Nevie V? GoLive?
Anyway a few of your points in this post and the one on the 8th June (which wasn’t Steve C at Stirling) seem to be aimed at me, maybe I’m being paranoid, maybe not, but I’ll give you an update on r11.
It’s no secret that we’re at the bleeding edge of AutoSys r11 deployments. We’re going to be the first to go li.. sorry, go into Production with r11 on a Unix backend. It hasn’t been an easy process, we’ve had an issue list the length of your arm and we’ve spent hundreds of thousands of pounds on Consultants. However, thanks to that money and a fantastic response from the CA developers and sustainable engineering teams with whom we’ve had daily calls for the last few months, we’ve gotten through that list.
Now you could argue that all of this is folly, that r11 wasn’t ready and we should have walked away. But then what? Go to TWS? Control-M? Cybermation? No chance, there’s no product out there that could hope to replace AutoSys once its embedded into a firm the size of a City. Additionally the issue list would never fix itself, someone somewhere had to discover each one of these issues, raise a ticket, wait for 1st, 2nd and whoever to look through it before it got the necessary attention. We’ve bypassed all of that and had the work done so that it suits our particular environment.
But what about all of that money? Well if you look at the cost of our AutoSys ELA, it pails into insignificance, so when it comes to the next ELA, recouping these costs isn’t going to offend anyone.
Plus you have to weigh in what we’ve got for our money; You mentioned the Welfare (though I think you meant Dole) I suppose that might be an option if any of the staff got bored of earning top dollar on the back of the irreplaceable and unprecedented experience we’ve all gained on the back of this endeavour. There’s no finer collection of AutoSys r11 experts on the planet and we’ve a unique working relationship with the core developers at CA, further to that they’re in our debt. When all is said and done I’ve given my firm the finest scheduling solution in the market for less than 0.002% of the annual Tech budget.
“Those who can; do. Those who can’t; whinge about it on the Internet.”
Anon.
July 24th, 2008 at 11:08 pm
FYI -
It was brought to my attention, someone either has the same “name” as me, or was using my name to post negative things about Autosys etc.
For those that haven’t guessed, the other Steve/Stevie C. is not me. The only post I made was to Pradeep many years ago. To Stevie C, if that is indeed your name, no worries. If you are just using my name to spread gossip, then please refrain it only makes you look like a coward, plus you now owe me a few beers.
Hope this clears things up for those that were scratching their heads at the odd posts by the second Steve/Stevie C.
Steve C.
July 28th, 2008 at 10:30 pm
Time to call a truce with Jonathan – no more saying TWS is best. Must not upset man with $100,000,000,000.00 budget!! – guessing the 0.002% mentioned would pay the $2M needed to pay for AutoSys R11 experts and a test server or two for a year.
Fun aside I am genuinely interested to know if or when fellow posters ‘really’ think that AutoSys does claim the title of “the finest scheduling solution in the market”. Maybe Jonathans dedication will save CA and give the title to them – stranger things have happend.
Other Steve/Stevie. Apologies for the confusion, I am indeed another Stevie C. From this point on I will call myself “Stevie C (not convinced about R11)”. Other Stevie C can choose to be “Stevie C (totally convinced about R11)” or just plain “Stevie C”. For the record – I’ll buy any Stevie C a beer irrespective of identity theft misundertandings.
August 21st, 2008 at 6:28 pm
We are struggling a little with UWCC r11.
When database corruptions occur with EIAM and Portal we have to de-install / reinstall Ingres and it is not easy. Usually we just wipe the (W2K3) server and start again.
Our DBAs refuse to get involved (they only know Oracle, Sybase and MSSQL). It makes you wonder why CA stick with Ingres but that’s another matter.
Do other AutoSys Administrators typically attend Ingres classes? Ingres education appears to be expensive but with EIAM continuing to use Ingres, I guess it may be necessary.
How many AutoSys Administrators are needed to maintain your UWCC and the core product? It seems that many more staff are required for the R11 products.
August 21st, 2008 at 6:35 pm
Anybody out there that understands CA’s “Core” and “Spectator” High Availability arrangement for WCC? Do the r11.1 trialists find the new HA aspect pleasing?
Any non-standard WCC HA methods being employed out there? Clustering? Home-grown replication? Ingres dump and load?
August 22nd, 2008 at 10:09 am
Isn’t the new “Core” and “Spectator” High Availability arrangement limited to a common sub-net? Not really suitable for multiple datacenters then.
August 24th, 2008 at 8:34 pm
AutoSys R11 SP1 cannot be installed from scratch and use Ingres as its database.
That might give you a big hint as to the direction that things are heading W.R.T. Ingres, AutoSys and WCC.
For further information, contact your CA representatives.
September 14th, 2008 at 8:15 pm
Re: “UWCC is a polished Turd” LMOA! I can agree that in my experience it is certainly prone to constipation! It is soooo sloooow!
Can anybody advise how to speed it up? Anything faster than stopped will be an improvement.
I’m all-ears when it comes to alternative (homegrown/3rd party/freeware) UI solutions too…
September 17th, 2008 at 1:08 am
Hi Jonathan
I notice that you’re giving a talk at CA World about your 4.5 to r11 migration experiences. Have you taken r11 into production now? Can you please tell us how is it going (for those of us who won’t make it to Vegas in November)?
Thanks
Mike
September 29th, 2008 at 4:16 am
Hi Bob
As I mentioned in my post of July 6 our company chose to move back to CA’s AutoSys Web Interface, rather than continue with WCC. But we will move to iXp next.
iXp has a some features that Web Interface doesn’t have, including schedule forecasting which we would find useful. It is the quickest and most scalable option we have seen. Best of all it has single-sign-on, making user set-up much simpler than WCC. Their technical support is good too. Our vendor let us trial the software for 60 days. They also pointed us in the direction of some big reference customers.
iXp isn’t perfect, the drawing of the pert and gantt flows could be more modern (the sister product iDash, a SLA monitoring tool, has a more modern look).
Hope this helps
Mike
December 30th, 2008 at 8:48 pm
Unfortunately I couldn’t attend CA World 2008 (Credit Crunch makes Vegas seem too extravagant). Could those allowed to attend confirm whether Mr McAlroy’s talk (about his 4.5 to r11 upgrade experiences) help those considering the move?
I am concerned about rumours of 9 months (and upwards) upgrade projects at big AutoSys shops and would appreciate hearing of success stories.
After 6-12 months upgrading I would expect great improvements. Do other AutoSys 4.5 users find it disappointing that AutoSys r11.0 is still missing simple functionality like file transfer and pre/post job scripting (which all the opposition seem to provide)?
January 2nd, 2009 at 11:03 am
Does anybody know if the 3rd party products providing AutoSys SLA monitoring (particularly Terma Software Labs JAWS or PGTI iDash) are also available for other schedule products?
If I purchase JAWS or iDash to use with AutoSys today could I swap-out AutoSys with Tidal or UC4 next year and still continue to use JAWS or iDash with my new scheduler ?
Thanks
Martin
January 21st, 2009 at 11:18 am
Gordon –
I agree that AutoSys is lagging behind the competition in terms of functionality.
Martin –
In a word, no. Both tools are AutoSys-specific. However, other tools on the market come with their own SLA monitoring and do not require a 3rd party add-on.
January 23rd, 2009 at 2:06 am
Thanks for your opinion Antony.
Time to look at alternatives to AutoSys before having to renew with again. Our company is full of cost-savings initiatives, this could be a slam-dunk.
March 11th, 2009 at 3:14 pm
This article is close to 4 years old. Don’t you think the kinks would’ve been worked out by now.
May 12th, 2009 at 10:15 am
This article is very inetersting and I think it’s very important to track all the comments also the oldest ones.
I’m very “lucky”, because I am an administrator of both scheduling tools, Autosys (4.5.1) and Control-M (6.3.01). My company is evaluating the upgrade to the Autosys r11 SP2, but in my opinion changing completely the architecture the comparision between these tools is not possible. Autosys r11 is going to become similar to Control-M but due to the complexity of this architecture I think will take several versions to reach the Control-M level. The Control-M last version (6.4.01) is really powerful (versioning, BIM, Forecast, agentless, cyclic job improvement, job update tool) and actually I think is the best choice.
July 28th, 2009 at 11:21 am
Just wanted to point out that R11.0 SP2 Incremental 2 (or SP4 in English) has been available for a couple of weeks.
This includes a bunch more fixes, updated SSA, etc.
Plus this includes EEM (security) v8.4 that finally does not require an Ingres database.
Also GA now are:
WCC 11.1 SP1 (has a couple of new features such as limited job flow editing)
iXp R6 (completely new job flow piece, a few more new features)
I would suggest that these releases now make AutoSys R11.0 more feasible, particularly to existing AutoSys shops that are thinkig of migrating from an earlier version (budget permitting).