ESP Workload Automation

  • 1.  Advantages of CA ESP to competing products...

    Posted May 25, 2011 10:39 AM
    Good morning,

    The company I work for is currently gathering information on enterprise scheduling packages to replace the one we currently use (ASG's Zeke, Zebb and Zena). We've looked at several offerings (CA-7, Control-M and ESP). The good news is that we're fairly certain that whatever our choice is, we'll be better off. However, what I'm looking for are "killer features" for the tools available.

    To the experienced and knowlegeable members of this user group: What would you consider to be the advantages of CA ESP over CA-7 or BMC's Control-M? Is there a feature - or features - that stands out in your experience that makes CA ESP more attractive than the competition? What truly differentiates CA ESP from the other seemingly capable tools on the market?

    I greatly appreciate your time, insight and advice!

    Jake


  • 2.  RE: Advantages of CA ESP to competing products...

    Posted May 25, 2011 03:21 PM
    Any modern job scheduler can help you get your batch scheduling done. What differientiates ESP from the other MVS centric schedulers that I have had acquaintance with are calendar management, scheduling vocabulary, the ability to expand capabilities with REXX, non proprietary security with RACF, and good performance (low CPU requirements). I will explain briefly below.

    ESP calendar management of special days and holidays in individual calendars is not unique but is a better implementaion than any other I have seen.

    ESP's rich scheduling vocabulary (workdays, weekdays, weekends, tomorrow, today, yearly, hourly,,, etceteras) is unmatched. It makes it easier for your schedulers and end users to actually schedule their workload using English language terms they are already familiar with.

    ESP's use of REXX as a means to expand the capabilities of the base language CLANG makes it possible to do things that you would not have thought even possible. It allows you to dynamically build job networks on the fly. For instance we have an application that periodically backs up disk packs and this is done with one job per disk pack. As we are always adding disk packs we don't want to continually change the application to account for the newly added disk packs so we use REXX to read a file that contains all the disk packs and build an application to back up all the packs that it finds in the file. You want to add or delete an disk pack from the backup process then you simply add or remove a record in the flat file.

    Another innovative use of REXX is to add features into ESP that it does not currently have. We once acquired a small company that had a MVS job scheduler (I think it was called ASF) that had the capability to schedule events based on the existence or nonexistence of an MVS dataset. ESP can schedule events based on the existence of distributed datasets with the FILE_TRIGGER workload object but its DSTRIG workload object for MVS files does not have this capability. I was able to replicate this capability of ASF inside ESP with REXX which made the conversion from ASF to ESP go much smoother than it would have otherwise.

    To my mind the ability of ESP to utilize REXX to enable the end user to introduce additional capabilities into the product is the standout feature that differientiates ESP from any other scheduler I have come across.

    ESP uses RACF to manage the scheduling entities (appls, events, calendars, tracking models,,,etceteras) which means you do not have to utilize a vendors proprietary internal scheduling security with the product to protect your schedules. This presumes you are comfortable using RACF. Also ESP has your batch workload run with the userid of a end user rather than the userid of the scheduling software so you don't have to use SURROGAT.

    ESP is also very CPU efficient. It scales well, it will run on 25 MIPS or a 6000 MIPS machine and it will use less than 1% of CPU. Hence you will not have to do any CPU performance tuning for ESP.

    To reiterate I believe the things that makes ESP most unique from other schedulers is its ability to utilize REXX to expand its feature set and its use of RACF to allow you to dispense with the use of SURROGAT.

    Regards

    Michael E. Ellis
    Systems Programmer
    Deere & Company


  • 3.  RE: Advantages of CA ESP to competing products...

    Posted May 31, 2011 01:56 PM
    Michael,

    Thanks much for the very detailed response. I appreciate the time and insight into ESP.

    These are very compelling features/capabilities that I'll certainly keep in mind as potential tools are evaluated!

    - Jake


  • 4.  RE: Advantages of CA ESP to competing products...

    Posted Jun 02, 2011 01:20 PM
    I agree with what Mike said, and would add some.
    We looked at many tools as well, a couple of things that were an advantage for our shop is the ability with symbolc use to make things generic.
    Somthing like 35,000 job defs many streams, schids, became 1 as a 9 job generic job stream.
    Also as a PDS file, all job scheduling is now done thru our code migration tool, its just another component to migrate with the jcl etc, and was inculuded in testing. The ability to validate as part of the package, send pdf file to developer before install is a good advantage.


  • 5.  RE: Advantages of CA ESP to competing products...

    Posted Jun 02, 2011 02:56 PM
    I may be restating this one but because of how ESP uses PDS members, we are able to keep several schedules in sync. What I mean by this is since we schedule DEV (5 data environments), QA (2 data environment), UAT(3 data environments) and PROD (obviously 1) per application (several applications with more data environments or copies if you will on the way) and they are virtually the same with the way ESP works (PDS members, variables and SYMLIB's), we only have 1 PDS member for DEV, 1 for QA, 1 for UAT and 1 for PROD. These can be compared using ISPF anytime very easily to insure only the differences we expect are present. We use ESP symbols and SYMLIB for much of the JOBS/ESP Application information so very little is actually different between these, things like some jobs are not run all the time in non-production environments so are set to request or need a different value for non-production (although most of that is done in the SYMLIB member not the application). The only reason we have 1 member for each is so that when a new job is developed, we can add it to each as it moves up the hierarchy and I think to save the human schedulers their sanity since I could easily think of a way to even get around these and have just 2 PDS members (since I would always keep PROD separate personally).

    Again, maybe a repeat but a little more detail on how we utilize what I think is a uniqueness that could not be done in CA7 (admittedly I haven't used CA7 in over 13 years though).

    We also use ESP for NT and UNIX scheduling, perhaps CA7 has pulled this in with AutoSys agents or something but it didn't exist when we implemented ESP but ESP had it. Also when we implemented ESP the Workstation (GUI) was already GA, I am not aware if CA has one now but it didn't then and our operations team couldn't survive without it.

    HTH

    Cheers


  • 6.  RE: Advantages of CA ESP to competing products...

    Posted Jun 07, 2011 02:27 PM
    Thanks for the detail. I could see how these features make managing multiple environments easier.

    Great information!