Search Results
You arrived here after searching for the following phrases:
Click a phrase to jump to the first occurrence, or return to the search results.
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.
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.
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 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 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.
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.
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 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 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 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 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