AutoSys Workload Automation

 View Only
Expand all | Collapse all

Migration form TWS to Autosys

  • 1.  Migration form TWS to Autosys

    Posted Apr 20, 2017 06:08 AM

    I want to migrate my Jobs which are Scheduled on TWS right now to Autosys. need some suggestion.

  • 2.  Re: Migration form TWS to Autosys

    Posted Apr 20, 2017 07:22 AM

    My suggestion. Don't they are 2 different products. TWS scheduling is NOTHING like AutoSys, nothing good will come from treating Autosys like TWS.

    just my 3 cents and expert advice 

    Good luck with your choice.. 

  • 3.  Re: Migration form TWS to Autosys

    Posted Apr 20, 2017 07:44 AM

    Hey Steve,


    Yes they are different job Scheduler. 

    However, this is my project requirement I am suppose to do that. can you help me with some suggestion on how should I proceed as I am completely new to this.

  • 4.  Re: Migration form TWS to Autosys

    Posted Apr 20, 2017 07:47 AM

    I am helping..tell them you can get the jobs out but they need to rethink the jobflow. AutoSys does not have a jnext day or end of cycle at midnight .

    the jobs do not need to be killed at midnight etc. It's a complete rethink. are you an Autosys person or a TWS person? 

    I cannot do the job for you but i can give you THE best piece of advice I can. DO NOT do a 1:1 conversion. You will regret it.


    Steve C.

  • 5.  Re: Migration form TWS to Autosys

    Posted Apr 20, 2017 07:55 AM

    I am new to both but I have better understanding of Autosys then TWS. Yes, I am not doing 1:1 conversion, so far what i am thinking to do is club the Jobs inside the box based on the days of week it runs. The jobs which i am dealing with can be classified as Daily,Weekly,Monthly and yearly. 


    Currently, I am working on Daily running jobs, just wanted to know what are the Important Points to keep in mind while doing Migration.

  • 6.  Re: Migration form TWS to Autosys

    Posted Apr 20, 2017 08:00 AM

    naming convention. is key. set that up first. you may want to make sure that you set up eEM to handle job names better than they had in TWS.

    set up the machines also based on proper naming conventions. 

    set up calendars... 

    do these first.

    then worry about the jobs. without machines and calendars .. jobs cannot be added for the most part 

    They really need someone well versed in AutoSys, good luck.. this is NO easy task for someone just starting out.


    Steve C.

  • 7.  Re: Migration form TWS to Autosys

    Posted Jan 04, 2018 09:58 AM

    Hi Steve,


    Sorry to get into your discussion but i can see you have expertise in both TWS and Autosys. So based n that can you tell me the pros and cons between TWS and AutoSys? My client which is currently triggering distributed Agent jobs on Mainframe CA-7 are thinking of migrating them but we are thinking what are the best options we have.





  • 8.  Re: Migration form TWS to Autosys

    Posted Jan 16, 2018 08:18 AM

    I have always felt that AutoSys is best of breed and as long as they don't cybermation far too much it will remain best of breed.

    with Autosys you can use the Z/OS agents and therefore not have mainframe scheduler just autosys on distributed.,


    Hope that helps and Good luck!


    Steve C.

  • 9.  Re: Migration form TWS to Autosys

    Posted Jan 16, 2018 03:49 AM

    Hi ps241992,


    as Steve rightly pointed it is not an easy task and not a good fit to migrate from TWS to AUTOSYS as both tools work

    and behaves in a very different manner.


    i along with my team mates did experience how difficult and complex the migration was, while doing the migration for one of my client and we were able to successfully migrate whole jobs from TWS to AUTOSYS but it requires alot of effort and thinking in terms of depicting TWS job behavior in AUTOSYS. 


    Key things that you need to take care or work from day 1 is:

    1. Conversion - How are you converting the jobs from TWS to AUTOSYS? i mean you first need to create a skeleton or basic job definition as per AUTOSYS. So are you planning to do it AUTOMATIC using script or manual? Naming Convention is what you have to consider from day 1 and start setting and following those stds. 


    Note: once the basic job definition is ready, then that job definition will undergo so many changes to mimic TWS behavior. Similar is the case with naming conventions, you will come across with so many scenarios where in you have to add or modify the naming stds to cater to those scenarios.


    2. DEPENDENCY MAPPING - In tws, one job can be called in multiple schedules, so when you are converting the jobs from TWS to AUTOSYS, you may need to understand, know and differentiate these jobs and have to validate and verify that whole job flow in AUTOSYS as per TWS. Here naming convention again plays an important role.


    3. DOCUMENTATION - Documents on naming stds, test cases to demonstrate TWS scenarios in AUTOSYS, VALIDATION Documentation, Reports which can display the job flows from TWS as well as AUTOSYS. etc etc.


    4. Time Frame - This migration is not as easy nut to crack and will exceed the timelines depending upon the number of jobs to migrate. in TWS, if you are referring to 100 JOBS then in autosys the count will be somewhere 150 to 200 depending upon the scenarios like in TWS there is no separate job required for a file being watched but in AUTOSYS that will be a separate job. So once the migration or jobs will be converted then we need to validate and test the executions which will take time. Decide about the timelines based on number of jobs, complexities, application team (job owners) involvements to validate the flow etc.


    5. AS IS MIGRATION or SIP - Best way to handle or proceed with this project is to have a SIP(Systematic Improvement Plan) where business requirements will be understood and the jobs in AUTOSYS can be created, defined and managed as per business requirement instead of doing AS-IS migration which in turn at later stages involves SIP. So propose the project as an SIP.


    6. Job ATTRIBUTE MAPPING - You have to map all attributes/behaviors of TWS in AUTOSYS. Like RECOVERY OPTIONS (CONTINUE, RERUN, PROMPT) eg. You should know how the behavior of these can be mimicked in AUTOSYS. Similarly, in TWS, one schedule can have multiple run frequencies (Multiple Calendars, individual Dates, offsets etc) where as in AUTOSYS it is not the case, so you have to consider those as well.


    7. TWS Scenarios / PAIN POINTS - list down all the scenarios, requirements, pain point which you are currently facing and then work on that to cover in AUTOSYS. 


    There is so much to consider and list is endless.. based on my experience i will suggest in following sequence:

    a. try to mitigate or cover the problem areas or business requirements in TWS only instead of migrating to AUTOSYS.

    b. if you dont have choice to move from TWS, then choose CONTROL M instead of AUTOSYS as TWS and control M works in same manner.

    c. if you still decided to switch to AUTOSYS, then have NON PRD instance ready first where in you can do all the testings and executions and validations in NON PRD then to PRD. When i am saying NON PRD instance ready, i mean all scripts and business/application teams shd have nonprod instances as well.

    d. Do the SIP instead of AS-IS.


    Hope it will help. Best of luck.

  • 10.  Re: Migration form TWS to Autosys

    Posted Jan 16, 2018 08:19 AM

    well said sunish.

  • 11.  Re: Migration form TWS to Autosys

    Posted Jan 17, 2018 02:23 AM

    Thanks Steve... i tried to cover the basics in my post but as i said list is endless and more to cover and take care in these kind of migrations.

  • 12.  Re: Migration form TWS to Autosys

    Posted Jan 17, 2018 02:26 AM

    Good explanation to start with. 

  • 13.  Re: Migration form TWS to Autosys

    Posted Jan 16, 2018 03:58 AM

    for further queries on this, u can reach emai me i will be happy to assist as we have done this before as well.

  • 14.  Re: Migration form TWS to Autosys

    Posted Jan 16, 2018 08:20 AM

    Like moving from cron, you should revisit the batch understand what you really want to do and see how autosys can make it better. when moving off TWS no more J Next day. you dont need to kill you batch at midnight. 

    Just let your schedules run to completion :-)


    Steve C.

  • 15.  Re: Migration form TWS to Autosys

    Posted Jan 16, 2018 08:59 AM

    Thank you very much for the responses. Actually my client is currently using CA-7 on Mainframe and we start a conversation of having the jobs there moved to a distributed tool. I know TWS and Autosys are completely different from one to another and so far we more likely to choose Autosys. Anyway will take note of what you guys said about the two Softwares.


    Daniel Dourado

  • 16.  Re: Migration form TWS to Autosys

    Posted Jan 17, 2018 07:20 AM

    My Views Only ....

    Please also try to use other sources like EMA Radar , Gartner , IDC , Foresster data to get more detailed understanding each product merits and demerits. EMA Radar lists 'radar chart with 5 focus areas - with its respective characteristics scoring". Add required characteristics for Migration - Asses radar with of 6th focus area , with its characteristics create your own radar chart with 6 elements . This approach might help you to understand which is best tool to go for. 


    Yes, Every tool have it's own merits & demerits . We need to look which suites best based on "Must required" , "required" , "good have" , "nice to have" requirements of every shop where they finalize a tool for them. 


    CA Products are highly scalable & proven solutions .. All the very best. 


    Hope this helps..