To R11 or Not to R11
For a number of people the decision to upgrade to AutoSys R11 or not is a weighty one. I do not intend to make light of it or suggest I have all the answers, but I will try to shed some light on what considerations should be taken into account when trying to decide. I will also suggest some reasons why you should upgrade to AutoSys R11 and some reasons why you might delay your upgrade to AutoSys R11. I will also share my view as to which release of AutoSys R11 you should consider going live with.
In my opinion it is a bit of a no-brainer. You should move to AutoSys R11, it is just a question of when and how. Please bear in mind that these are my personal opinions based on experience and not necessarily the view of CA. CA can provide you with best practice advice, if needed, and I can obviously provide you with best practice advice based on my experience, which may differ from CA.
What to consider:
With AutoSys 4.5 each agent requires a DB client for your DB of choice and that can incur a considerable cost, unless you have an enterprise license with unlimited DB clients. AutoSys R11 does not have the requirement for these DB clients and can thus save you a considerable amount in costs. The non requirement of DB clients also simplifies the agent deployment to the Agent machines.
If you have a preference for one of the AutoSys 4.5 GUI tools you might consider remaining on AutoSys 4.5 because with AutoSys R11 you only have WCC as the user interface. I personally find WCC far superior to the old AutoSys 4.5 GUI tools. This is especially true if you are looking at WCC R11.1 SP1 which I would suggest is the best version to deploy. WCC R11.1 SP1 includes useful tools such as the APP EDITOR which is like a web based version of JOB VISION.
With AutoSys 4.5 you had the choice of Native security or eTrust Access Control (EAC), and with AutoSys R11 you have the choice between Native security and eTrust Entitlements Management (EEM). Firstly it is a no-brainer that you should utilise either EAC or EEM as without it you do not really have much in the way of security and no granular security. With out either EAC or EEM you will also not be able to achieve SOX compliance if that is a requirement. The differences between EAC and EEM are quite marked. EEM has a less complicated architecture and, when combined with AutoSys R11, all security checks are done via the AS-server. This simplifies the overall architecture and reduces points of failure. EEM also has built in HA which EAC does not.
Why you should upgrade:
I have mentioned some reasons why one should upgrade to AutoSys R11 but I will elaborate here. For me the foremost reason for moving to AutoSys R11 is performance. I have seen a marked performance improvement between AutoSys 4.5 and AutoSys R11. Based on performance monitoring I have done, the average lag time in AutoSys 4.5 is at best 7 seconds. Whereas the average lag with AutoSys R11 that I am observing is under 1 second. There are many factors that can negatively affect performance.
Another major reason to upgrade to AutoSys R11 is the new architecture with AutoSys R11. Namely: the non requirement for a DB client, the introduction of the AS-server, and the instance independant agent. The introduction of the AS-server means are no longer required and we have a single point of interaction with EEM. It also means that, because we can have multiple AS-servers, we can spread the workload around. The instance independant agent means we have one agent on a machine, regardless of how many instances might use it. The AS-server list is passed to the agent, by the scheduler, when a job is started. This means there is no need to configure the agent.
EEM is also a really good reason to move to AutoSys R11. A single EEM instance can be used to provide security for AutoSys R11, WCC R11 and JAWS. This simplifies the overall architecture of the environment and also means you only need one integrations point to your LDAP, AD or Siteminder. EEM also has built in HA capabilities which is very important when you have the business or parts of it reliant on Autosys to ensure timely batch completion.
Why you might consider delaying your upgrade:
You might consider remaining on AutoSys 4.5 if you have particular skills in AutoSys 4.5 or you have a large number of users that would need to be retrained to WCC from either the Motif GUI’s or from the Web Interface. Having said that, I do not feel that those two reasons should warrant staying on AutoSys 4.5, as they are both easy to overcome. The only valid reason I can really think of to remain on AutoSys 4.5 is if the performance you are getting is acceptable and you do not have the technical skills, or resources, available to do an upgrade. The technical skills unavailability will only be an issue if you do not have the funds to get a consultant who has worked with AutoSys R11 to do the upgrade for you.
Conclusion:
Well I hope that I have provided you with sufficient information to make an informed decision, I am always available should you want to discuss or bounce ideas off me.
Hendry Taylor
Taylored IT Limited 
18 February 2009 at 12:13
Interesting blog Hendry.
To me the biggest considerations regarding upgrading to r11 are:
1. cost of consultancy
2. cost of retraining
3. features of the product vs the competition
-Consultancy-
Many large r11 upgrades require a 12-18 months project. These projects require expert (and often expensive) consultants to guide them through the process.
-Retraining-
Not all r11 training courses have been released yet but there will be many and the product is now VERY complex. Many courses will prove too expensive.
-Competition-
There is an argument that conversion from AutoSys to dSeries, TES, UC4, $Universe (or practically any other modern scheduling tool) may cost no more (than an AutoSys upgrade), may take less time and in many cases give better functionality (like integrated file transfer, direct database event integration, email integration, JMS, Java Scripting, post-run processing, etc). Organisations may be able to save money on licensing too (perhaps retaining your CA relationship by buying dSeries) which is a big consideration during these times.
I definitely agree that your question “to r11 or not to r11?” is one that every AutoSys shop should be considering right now. Personally my answer is to go back to market, review the options, draw-up a shortlist of options and (finally) run a proof-of-concept project to pick the best option for you. It may be that AutoSys r11 is the best option, maybe not.
To continue to help us make an informed decision I would be very interested to hear your view of the pros and cons of AutoSys r11.0 vs other tools.
23 February 2009 at 13:50
To GG: (Gal?)
I don’t know how you can suggest that a conversion to another Scheduler is going to cost no more than an upgrade to r11? There’s a conversion utility from 4.5 to r11 if you want to use it, or you can simply JIL out the jobs etc from 4.5 and JIL them into r11. There’s no change in the basic functionality as far as 4.5 is concerned; what worked there will work in r11.
Yes the application is more complex (client, AS, etc), but getting over that is far easier than moving to a whole other tool.
Yes we (myself, Hendry and co) have had huge issues upgrading to r11 but that’s unique to us. Now that we’ve gone through that pain, no one else (Unix based) needs to.
Regards
Jon
1 March 2009 at 01:32
In response to Jon’s interesting comments, I still suggest that it is useful to explore all options. I think it would be useful for Hendry to include other scheduling options in his next blog but if I REALLY cared I should write my own blog.
Simple research will unearth scheduling tools with very similar functionality to AutoSys r11.0 for 25% of the licensing costs. Even other CA products have great functionality for less money.
Sorry I’m not aware of the painful experiences you refer with your AutoSys r11 migration(s) but have my own experiences to base my comments on. Any upgrade project taking 6+ months and 2 or 3 dedicated consultants may as well be a migration project to product X. If the licensing fee is reduced then there’s an argument for swap-outs.
I appreciate that a swap-out is not trivial but it sounds like your (and Hendry’s apparently) upgrade wasn’t too good either. My experiences were troubled too. (Incidentally, other utilities have AutoSys 4.5 JIL conversion utilities too, so I’m not sure that issue is too important).
If no-one else experiences r11 pain in future I’d be surprised but undoubtedly the pioneering efforts of early adopters benefited the rest of the AutoSys world. (By the way this product has been generally available for over a year now and has been tested by users across the globe, so I doubt whether the credit for the stabilising of r11.0 can be handed to one or two people).
Thanks
Gordon
1 March 2009 at 19:31
To Hendry
Thanks for your views.
To Jon
I disagree that problems with upgrading to r11 are unique to your site. We have discovered huge problems too. My colleagues and I attended various “Buddy” and other user conferences where the same issues seem to affect the majority of early adopters.
Clearly we can overcome most of these obstacles but there is still work to do.
To GG
I agree with that migration may be no more expensive than an upgrade but CA have our site tied-up for years to come, so there is no choice but to continue with AutoSys.
Regards
Rich
31 March 2009 at 05:04
Dear Forum,
Am about to upgrade 4.2 to 11.1. We have JS artefacts which we need to upgrade. Do we HAVE to use CA conversion software, or must we go to 4.4 or 5.03 first in order to convert? We are jumping directly. Is there some way we can test whether the artefacts work/dont work? Will we be prompted? What is your recommendation?
Thanks,
Adam
8 April 2009 at 09:31
GG is NOT Gal
11 April 2009 at 20:57
Guys or Gals – what exactly are you looking for (Jonathan and others)???
I thought this was a discussion on Job Scheduling not a dating service!
Yours suspiciously
Gordon
11 April 2009 at 23:20
Sorry about that some spam slipped through.
Has been rectified.
22 April 2009 at 07:02
I noticed that this is not the first time at all that you mention this topic. Why have you chosen it again?
24 April 2009 at 00:51
No There is only one post with that title.
24 April 2009 at 22:28
Hi AcidDragon
What a fantastic blog for those interested in AutoSys!
Maybe in future posts, you’ll explain how to keep the backend from flagging. I’ve found that over time holes in the backend system affected my performance.
Thanks
Nadia
25 April 2009 at 18:32
Hi Nadia
I think it’s fair to say that when we worked together we probably overstretched the limits of the back end.
Maybe 11.3 is the answer tho.
Keep well
Ed
26 April 2009 at 03:31
Hi Nadia
How many proc’s did you have on your back-end?
Minimum of two is standard but some go for as many as 10.
Yours
Rod
27 April 2009 at 23:48
Nadia
Please expand on your back-end problems? How much throughput before performance was badly affected?
The limits are not well documented but 300,000 events per day should be achievable on the old 4.5 technology. The limits for r11.0 are still being understood but in principle are far greater.
Mike
29 April 2009 at 17:35
Hi Nadia
I think it’s fair to say that when we worked together we probably overstretched the limits of the back end.
Maybe 11.3 is the answer tho.
Keep well
Ed
29 April 2009 at 17:42
I’m also interested in improving the backend.
Any advice Hendry?
14 May 2009 at 23:36
Jenna & Nadia
My company have spent a considerable amount of effort tweaking the back-end and eventually it paid off. I suggest that you ask CA to send their top guys over.
Like so many things you only get out what you put in.
Simon
23 May 2009 at 20:55
With regard to getting your back-end in order, I concur with Rodney and Simon.
Get as many procs up as you can. You only get out what you put in, so put in as much effort as possible.
But ultimately, as long as you are happy with your back-end performance that should be enough. Customers are always moaning but you shouldn’t have to bend-over backwards to accommodate them!
24 May 2009 at 23:43
I suggest that too much attention is being paid to the backend whereas I believe that a more ample front-end should be the goal.
In my experience the front-end needs too much plumping and coaxing just in order to accommodate a 20-man team.
7 July 2009 at 01:13
What are the CRUD options with r11.0?
Anybody delved into AutoSys r11.3 CRUD yet?
By AutoSys r11.5 does CRUD apply to all AutoSys metadata?
(CRUD=Create, read, update and delete – obviously).
7 July 2009 at 19:38
Surely there’s enough reference to CRUD in the manuals?
10 July 2009 at 13:01
Hi All,
This is very intresting blog for AutoSys guys!
Is anyone has the or maintained the documentation for upgrading Autosys 4.5 to R11? If yes, can you guys please share the same.
And also wanted to know what all proc’s & corn’s should be taken care before upgration. Becuase, upgradation should not effect to the existing 4.5 setup or the jobs which are scheduled.
Waiting for the reply.
Cheers
Ganesh
11 July 2009 at 16:01
r11 is delivers crud control in buckets. Have you looked properly?
I think that Hendry/aciddragon touched upon crud in some of his postings already.
11 July 2009 at 19:49
Adam (Broit)
Your post of 31 March refers to AutoSys versions that don’t exist.
There are not now (and aren’t expected to be) 4.2 or 11.1 versions. Are you talking about another CA product? Maybe dSeries?
Simon / Rocco
If your familiar with CRUD, then nothing new will surprise you with r11.
Good CRUD relies on regular practice. If you just sporadically dip in and out of CRUD you may get rusty.
Good luck
Rich
12 July 2009 at 22:43
Ganesh
With all major upgrades CA recommend customers to use CA Technical Solutions or official CA Services Partners.
Upgrade documentation is very customer-specific, especially when upgrading Autosys 4.5 to r11.
Sincerely
Mason
13 July 2009 at 20:11
In my line of business it is necessary to dip in and out of crud on an irregular basis. I have a special tool for the purpose, which I am happy to show if others are interested.
13 July 2009 at 20:38
Hello,
Have others got two autosys clients on your machine?
If yes, where is located the second auto.profile file)… So autosys load the correct AUTOUSER… and gives not an error…
Else have you set the AUTOUSER and AUTOSYS in Autosys Administrator remote agent machine…
Off topic of CRUD I realise…
Or in French
Même un niais doit comprendre en ce qui concerne CRUD que, si elle ressemble à la merde, ça sent bon et le goût de la merde, il est très probablement la merde.
Best regards.,
Frantz
13 July 2009 at 20:43
Thanks for your comments. It is clear that infrequent experience of CRUD leads to stagnation and backlog.
5 April 2011 at 14:00
This is very intresting blog for AutoSys guys!
Is anyone has the or maintained the documentation for upgrading Autosys 4.5 to R11? If yes, can you guys please share the same.
And also wanted to know what all proc’s & corn’s should be taken care before upgration. Becuase, upgradation should not effect to the existing 4.5 setup or the jobs which are scheduled.
Waiting for the reply.
26 May 2011 at 20:07
I am trying to migrate my jobs to R11 however I get the follwoing error message on the remote agent
Thu May 26 15:46:44 2011: ———————- Unicenter AutoSys JM Agent Log File —————————-
Thu May 26 15:46:44 2011: CAUAJM_W_10382 WARNING! Unable to get environments for instance DEV!
Thu May 26 15:46:44 2011: CAUAJM_I_10153 Setting environment variable:
Thu May 26 15:46:44 2011: CAUAJM_I_10153 Setting environment variable:
Thu May 26 15:46:44 2011: CAUAJM_I_10153 Setting environment variable:
Thu May 26 15:46:44 2011: CAUAJM_I_10153 Setting environment variable:
Thu May 26 15:46:44 2011: CAUAJM_I_20000 auto_remote started with Process ID 3,408!
Thu May 26 15:46:44 2011: ————————– CAUAJM_I_20097 Job Type: Command ———————————–
Thu May 26 15:46:44 2011: CAUAJM_I_20098 Job Data Stream: [Version=3.3][job_type=c][auto_comm_debug=0][SENDEVENT_DEBUG=0][std_in_file=][std_out_file=e:\autosys\logs/%AUTO_JOB_NAME%-%AUTORUN%][std_err_file=e:\autosys\logs/%AUTO_JOB_NAME%-%AUTORUN%][term_run_time=0][min_run_alarm=0][max_run_alarm=0][joid=62760][alarm_if_fail=1][run_num=2287230][ntry=1][run_machine=lclntn15][machine=V_scs-ccs-ccs-lvm][command=e:\x\prod\ccs\Scripts\CcsFtpLVN.bat][owner=serviceAS@lce][pid=3484][jc_pid=3288][watch_interval=0][watch_file=][Eoid=DEV00e0ue6][Server[0].physname=laq9dv2][Server[1].physname=laq9dv3][chk_command=0][watch_file_min_size=0][job_name=scs-ccs-ccs-lcl101_ftplvn.s][box_name=][AUTOSYS=E:\PROGRA~1\CA\UNICEN~1\autosys][AUTOUSER=/app/CA/UnicenterAutoSysJM/autouser.DEV][AUTOSERV=DEV][Base_Time=1306439204][TestMode=0][CleanTmpFiles=1][RemoteProFiles=1][AutoRemoteDir=E:\PROGRA~1\CA\UNICEN~1\agent\out][chk_files=][profile=E:\x\prod\ccs\scripts\ccsftpenv.bat][killsigs=2,9][max_exit_success=0][RemAuthMethod=1][ReturnHost=laq9dv2][ReturnIP=162.53.32.69][ReturnPort=49162][NTpw1=A]BkCVD~E’FQGKIA][NTpw2=][STDAppend=1][StdOutThreshold=20971520][EPHeartbeatInterval=1][AutoServer=laq9dv2][AutoServerPort=9000][end]
Thu May 26 15:46:44 2011: CAUAJM_I_20004 The Generated LogName is E:\PROGRA~1\CA\UNICEN~1\agent\out\auto_rem.62760.2287230.1
Thu May 26 15:46:44 2011: CAUAJM_I_20171 No remote user authentication performed.
Thu May 26 15:46:49 2011: CAUAJM_I_20090 Closing the Socket…
Thu May 26 15:46:49 2011: CAUAJM_I_20080 Agent Sending Message: Type=7,008, Return Value=0 Description=
Thu May 26 15:46:58 2011: CAUAJM_E_20277 Unable to connect to to get profile
Thu May 26 15:46:58 2011: CAUAJM_I_20278 Using local machine for profile E:\X\PROD\CCS\SCRIPTS\CCSFTPENV.BAT
Thu May 26 15:46:58 2011: CAUAJM_I_10153 Setting environment variable:
Thu May 26 15:46:58 2011: CAUAJM_I_10153 Setting environment variable:
Thu May 26 15:46:58 2011: CAUAJM_I_10153 Setting environment variable:
Thu May 26 15:46:58 2011: CAUAJM_I_10153 Setting environment variable:
Thu May 26 15:46:58 2011: CAUAJM_I_10153 Setting environment variable:
Thu May 26 15:46:58 2011: CAUAJM_I_20315 Setting Home Directory to ¼¿
Thu May 26 15:46:58 2011: CAUAJM_I_20316 HOME environment variable is not a valid directory, defaulting to AutoRemote Dir: E:\PROGRA~1\CA\UNICEN~1\agent\out
Thu May 26 15:46:58 2011: CAUAJM_I_20319 Executing command [[ e:\x\prod\ccs\Scripts\CcsFtpLVN.bat ]]
Thu May 26 15:46:58 2011: CAUAJM_I_20321 child process created successfully (3,264)
Thu May 26 15:46:58 2011: CAUAJM_I_20223 parent wait for user task 3,264
Thu May 26 15:46:59 2011: CAUAJM_I_20234 Successful wait for child
Thu May 26 15:46:59 2011: CAUAJM_I_20224 parent returned from wait, exit code hex 2 (0x2)
Thu May 26 15:46:59 2011: CAUAJM_I_20226 Sending the Completion Event…
Thu May 26 15:46:59 2011: CAUAJM_I_20228 Send_Event ret 1
Thu May 26 15:46:59 2011: CAUAJM_E_20344 WIN32 Function “Hive()” failed. Hive remains loaded
Thu May 26 15:46:59 2011: CAUAJM_I_20151 Agent work complete, exiting!
And these on the standard output
Logs (2287230/1)
Details
E:\PROGRA~1\CA\UNICEN~1\agent\out>perl -e “for ($i = 0; $iperl -e “print scalar(localtime) . \”\n\”;”
Thu May 26 15:46:58 2011
E:\PROGRA~1\CA\UNICEN~1\agent\out>perl e:\X\prod\ccs\Scripts\jntest2.pl
Can’t locate lib.pm in @INC (@INC contains: .) at e:\X\prod\ccs\Scripts\jntest2.pl line 15.
BEGIN failed–compilation aborted at e:\X\prod\ccs\Scripts\jntest2.pl line 15.
However when I run the script manually they run sucessfully.
Any Ideas?
Thanks
15 February 2012 at 21:08
I have just migrate an Autosys 4.5 instance to r11 sp5. We choose to use the agent (and not the client) because both client 4.5 and r11 cannot share the same environment if using the same instance name. Consider that using the same instance name will allow you to use the Datamover migration utility moving very quickly jobs, calendars, credentials and agent entries.