Endevor Reviews

Source control management.

It performs well.

It's very controlled. I can't say that it improves, the way our company functions. 

It's not so much that it, by itself, isn't beneficial, but that maybe the way we use it is not necessarily great.

There are lots of restrictions and it's difficult to move things through the process and to get things elevated. And then we'd have to do some crazy process to get a CCID created and you've got to submit a request here, and then you've got to have this and that.

We've got this other process, if you generate a package and then you forgot an item, then you have to add to it. We have to get someone else to reset your package and you've got to submit a different request and get someone to reset the package. It's just painful, instead of having the users have the control over what they're doing, and over that process.

• Version control 
• Being able to compare versions
• Being able to see the difference in the history

Learning the tool for the first time was extremely difficult, and it could be because of all the other processes we had around it. But knowing you can do these things in batch, you can do things in the foreground or online mode, and then these, you have to have a package for. There are these rules, and some of the concepts inside the tool are not clear, like what is the CCID? Why do I have to have one? What is that? And how is it used? As a developer, it's not important to me - I don't know what a CCID is, and I don't care - but apparently it's important to someone.

It seems extremely stable.

It seems scalable. I've never encountered any slowness. It seems that many, many users could use it without a problem.

The most important criteria when selecting a vendor are 

• that the tool meet your needs
• that it have the features and functions that you're looking for.

CA Endevor is better than not having any source control management, some kind of source control tools.

We switched from a home grown Librarian based System to Endevor starting in 2009. The product provides good visibility of code changes, and change history. It provides good security options as well.

The biggest benefit we have gained from using this product is the decrease in deployment errors. With our old system, binds and new copies were done manually based on paperwork filled out by the programmer. Now all that is done through Endevor processors.

The biggest irritation I have is the footprint checking process. Once the footprints get out of sync it is hard to tell what the issue is and to fix it.

Support is quite good for this product, although it has become a little more time consuming lately. All calls now appear to go through a general service person first. I have always gotten attention the same day. Not always a fix or an answer that quick, but at least a response from a service tech letting me know they had the problem and were working on it.

The product is still being actively enhanced and there is a strong user community.

We cut implementation errors by around 99%. Less effort is required by developers to set up migrations and the moves are much easier and less prone to problems.

Endevor can be very rigid. When you install and set up your map which controls the way code moves between stages it is important to be sure it is like you are going to want it for the long hall. The map is complicated to change once code is in flight. Each stage is related to the next and this relationship can only be changed when elements are at specific points in the migration cycle.

We have been using this product since 2009.

The biggest issue we had was kick back from staff that didn't like change. We also picked an installer that had a set way of doing the job and so we have an install we don't like. I would strongly suggest that new users take time to understand the product and the different ways it can be set up instead of letting someone just decide for them.

No issues with stability at all.

No issues with scalability.

Customer service is very good.

Technical support is also very good.

We had our own home grown solution that required constant maintenance and patching.

The internal setup is complex and rigid. Get it like you want it the first time. The actual product install is not complex.

We used a contract installer recommended to us by another company, not from CA. This company had a set way that they did the installs and we were not proficient enough with the product to object to some of the things that were done. I strongly suggest that new users take the time to understand the product BEFORE the install.

We did evaluate several products including IBM ClearCase and MKS.

Our company uses ROSCOE for it's primary development. Although ROSCOE and Endevor are owned by the same company, the ROSCOE interface for Endevor is many years out of date.

I thought the most valuable feature of the product was maturity in the process, in the tool itself. In other words, while there were many things we would have liked it to have done, what it did, it did very well.

Over the course of many years of usage, one of the things that we found that some customers wanted to have was point-in-time recovery, which was one thing that I worked on. I remember I was on a project that was called Space Station Freedom at the time, with NASA. They felt like they needed to have a point-in-time recover process. They built that into the tool. They got it done, so there was a way to do it.

Quick Edit was a big add-on. Initially, when I started working with the tool, there was pretty much, "Use your own text editor." ISPF, because everything was ISPF based. You would add it into the tool through the normal script language or core ground processing. Well, they came up with something called Quick Edit, which was an add-on to the tool, but it was seamless. It just gave you an editor where you could go in and change a single object and save it and have it kick off the build in a development stage. It was that automation that really, I think, helped catapult Endevor because before, it was little bit more restrictive. It was more cumbersome to work with.

Since then, I haven't done a whole lot with it.

I'd say, overall, as a development tool, it helped us to automate processes that otherwise were very manually intensive. As a release tool, there probably could have been some additional enhancements, but it was effective. I could easily go from one LPAR to the next LPAR at the push of a button.

The funny thing is that I've learned that most organizations didn't know how much they appreciated it until they didn't have it.

There were a lot of developers who naturally oppose any process that they would deem to be making their jobs more cumbersome. In other words, more overhead on the task that they had to complete. The automation that we were able to build in; we were doing essentially some aspects of agile development before it was even a concept, because we were doing integrated builds every hour, on the hour, with no problems. It was virtually automated, totally automated. All the program had to do was finish your code, let us know, approve a package, and then it would go.

It was just a very nice process. When it was running properly, it was very transparent relative to the whole application development lifecycle.

I have used it off and on for about 26 years.

It was very consistent. When implemented appropriately, it was very solid. It was very stable; it was dependable. I never failed an audit with Endevor.

The only time that we really had down time is when we abuse it or we didn't follow our regular maintenance process. I can think of maybe once or twice in all the years that I've had it where the MCF was corrupted, or the package data set was corrupt, because either one of them could be catastrophic.

They were built on a solid VSAM validation, so it really never caused a lot of issues in that way, although from time to time, some of the share options were not allocated appropriately. Therefore, we might have run into issues of performance degradation, normally, when the share options weren't set right.

There was something called L-serve, which was a separate component that ran as an instance to start a task. That helped improve performance. I remember at one point it did, but in my last installation, we didn't even use it. I was able to use PDSEs and everything was fine, along with the V-samp files which were for the MCF.

I think the scalability did improve over the years, because if there were was issues with performance degradation, it would have been due to not configured properly. For example, too many environments that were nested or linked to each other, which caused a problem because the search routines would have to go through multiple sets of data sets in order to resolve what it is that you were querying. It really depends on how you set that up. Numbers or integers can cause performance degradation, but with that said, there are companies out here that have hundreds, if not thousands, of people connected to Endevor. They do not have these problems, so I know there are probably testimonies much better than mine that could prove that. I've known of many companies that they were using it on a very large operation. Mine might have had, over the last 10 years, maybe 100 or 150 programmers, but I know of others that have 600, 700, 800 or more.

Support has always been excellent. I know Paul Lewis is still there. I remember he was one of the first people I talked to. He would give you that tough love. He says, "Well, when in doubt, try it out." That was always the same. I would say something like, "Paul, do you think I could do this? Do you think I could do that?" His response: "Oh, well, Mark, when in doubt, try it out." I said, "Okay."

I'd go try it and maybe it would work. If it was something that he knew for sure that I was the one exploring it and we were at second- or third-level support, he would say something like, "Okay, well, we have a problem," or right away he would tell me if it was a known issue. There's no way that any company's supporting a product like that, or for any product, knows of all of the variants or considerations - just by searching a data base repository.

Work with CA, a third party or CA consultancy to do a proof-of-concept; not just the demo out of the can, but actually take an application or some part of an application, do a POC, and then get it on your machine. Even if you have to pay for it, it would be worth it, because that's going to set a foundation for you to be successful with the initial implementation. One thing, when working with the consulting company, they're going to have a better view of your configurations, your systems, and your environment. Work with them, and that will make you successful in the long run.

I have not given a perfect rating because I would want that one extra point to be for some subjective criteria that I haven't even thought of.

It is a tool the mainframe programmers use to do their work. If they need to make a change to a program, they go into Endevor and they check out a copy of the program. Then, they make their changes and check it back into Endeavor, and it gets built or compiled into whatever the language is. When they want to move a copy of it to QA for testing, they use Endevor to do that. Also, when it is time to go into production, they use Endevor to do that. The programmers do all their work through Endevor, and it is their bridge between development and production. 

The benefits are that we backup people's source code for them. They do not have to worry about losing it because Endevor keeps it for them, all kinds of previous versions. Endevor keeps track of everything that auditors need. That is a big thing. Any question that an auditor has about our processes and approvals is all stored in Endevor. We can give them reports and it makes them happy, especially when you work for a bank. 

What I like about Endevor personally is it can be very flexible, as far as how you use it. You can make it do nearly anything, but in really clever ways. It is very versatile. You can really customize it for your own shop pretty extensively, pretty easily. 

It may seem a little abstract, but when somebody approves an Endevor package, if they are able to approve, and let us say there's four different approvals that are needed. If they have the ability to approve at four different levels, and if they check off to approve the package it will approve all the way through. If I would like the person to be able to approve at one level. It doesn't matter which one it is, but they only can choose one thing, then somebody else has to do the other approvals. There is no way around it. I spent an entire day trying really hard once to figure out how to do that. In a shorter sentence, the ability to restrict one approval per approval level would be a big deal for us. 

Sometimes finding errors and output can be difficult because it spits out so many messages that it is hard to figure out which ones are the ones you need to look at and what flow did it actually take through the processor is what they call them. There are a lot of if-then-elses, sometimes it is hard to figure out which if-then-elses it actually did. When you can turn on what they call a trace, but if somebody asks you a question you want to just say, "Which one ran and which one failed?" That's not always easy. That could be a little easier. 

It is very stable. We have no problems.

One thing that is great about CA is that they worked with really big companies for a long time. We have no problems with scalability. It is excellent.

I have only ever opened one case as I am relatively new with the company, but they got right back to me and answered my question quickly. 

I was not involved in the initial setup.

There's really only two mainframe tools that do this, Endevor and something called ChangeMan. I used to support ChangeMan. It is good, but it is a lot simpler. If I was talking to somebody, I might point out the flexibility of the Endevor implementation and how you can do so many different things in really clever ways. 

We use the product as a source manager and program manager. It helps in controlling the mainframe code and performing data migrations.

Endevor is easy to use.

The product’s implementation process is complicated and restrictive. It is difficult to find file programs and use a different tool for the setup as the compilation process is all locked up, at least in our implementation. We might switch to MySQL for the same reason.

We have been using Endevor for ten years. We use the latest version.

The product is stable, but it is not static as we are developing software.

We have 100 Endevor users in our organization. It is a very scalable product.

I use SCLM as well.

The initial setup process is complex with complicated programs. We have a primary technical executive and two support executives to handle the implementation.

We implement the product with the help of third-party vendors and our in-house staff.

The product is expensive.

I rate Endevor a seven out of ten. I wouldn’t recommend it to others. It could have better pricing and support strategies.

Our primary use case for the solution is management, version control, process, or building management. Additionally, we deploy the solution on local storage.

We find the robustness of the product and the process management process valuable.

The solution is very good and prevalent in larger organizations, but the solution can be improved by integrating more smoothly with the open world.

We have been using the solution for approximately one year and are currently on version 18.

The solution is stable. I rate it a ten out of ten. There is rarely any downtime from the product because of the infrastructure of the software. The sites could make a mistake but not the product.

The solution is scalable. It allows you to start with a pilot of three or four users and easily increase it to 1000 or 2000 users to even millions of users. There are no restrictions on how big it gets. I rate the scalability a ten out of ten.

I rate technical support a ten out of ten. They have a short turnaround of about a day to get issues rectified. It's one of the best supportive products that I know.

Positive

We did not use any other solutions, but we considered Endevor's most significant competitor at the time ISPW.

I rate the initial setup a five out of ten. When you come into sites with 5,000 files, you integrate them into the package. So you have to do a lot of analysis, which is time-consuming. These are external to the product and take many months to implement. 

The first thing is to understand how all the source management is going on in the organization and what processes are needed to build all those sources. Then deciding who will deploy the objects and planning considerations. Once all the planning is done, you have to go through the plan, which takes many months as it is best to review it in chunks. Then, you can do a pilot, but after the pilot, the procedure takes many months.

We implemented the solution in-house, and I have personally implemented approximately 15 of these solutions.

The return from Endevor is clear. Firstly, all of the process management is automated. Users do not have to be concerned about how to build out of their source. It completely masks the unit and there are no mistakes. The product is built, so everything is automatic. The source management is excellent because it gives you versioning so you can easily go back to an old version, which is also very important for the users. It isolates between developed production permits, which provides flexibility and security for the user and provides protection to prevent unauthorized access by source users. So users of one team cannot see the source of another group. For example, mask the payroll source from the entire organization. Hence, all of these things provide a considerable return because without a sound source management system, if you have hundreds of users and hundreds of thousands of files, you have a colossal mess on every site that doesn't have it. Therefore this solution provides order as it is an excellent container to manage this tremendous asset of financial institutions with over one billion dollars.

The solution is very expensive. There have been negotiations between our customers and Broadcom, the product owner. It also depends on the basket of products they have from Broadcom. Sometimes we use it because the licensing costs are bundled in with many others. It is an expensive product.

I rate the solution an eight out of ten. The solution is good, but since it was developed over 50 years ago, the open world hasn't been taken into account. The solution can be improved by integrating it with current-day changes.

One of Endevor's most valuable features is the ability to have your source in a repository that keeps track of all of your versions. It also has your ACMQ, which allows you to keep track of your input and output components. It has everything in it that you need for auditors: who asked for the change, when the change moved up, all the different stages, and where the approvals are. So, when we have auditors come in, we can trace it from production all the way down through the development, and the changes that we made at a line level.

When we first brought Endevor in, we had a lot of issues with audits. We had Librarian. We had Panvalet. When we brought Endevor in, almost 18-20 years ago, the auditing issues went down dramatically, once we had everyone into Endevor, using it, and we had everything turned on. Now, when we have audits, they go through smoothly. They barely ask us any questions because we can prove the changes all the way up through production, and there's no issue with having to come back for information later.

Right now, we're looking at moving into DevOps, so I'm glad to see that CA has started DevOps on the mainframe. We're looking at using the Eclipse user interface, which will make it easier to move off of ISPF, and we're looking at possibly using Application Lifecycle Conductor. Endevor plugs into that so that we can use more of a pipeline for DevOps and for agile processing; get the pipeline in place so that we can trigger off and go to tools such as JIRA, Jenkins, and still be connected to the mainframe so our projects are all in one.

There is one feature, the sandbox feature, that allows you to virtually create environments for developments and then, once your project is done, those environments go away as you move up through the lifecycle. You can always build new environments.

That's a very good feature, but there are pieces of it that make it difficult to use for my company because of the way we have our data set up. There are some features in there I would like to see improved.

The Sandbox feature was added a few years ago and would be very helpful, but there are several companies that cannot use the feature due to the design. The Sandbox feature reuses the Subsystem field as an identifier for the sandbox then returns the modules back to the original subsystem when done. However there is no mechanism to save the old subsystem field at the module level, so only modules from one subsystem can go into a sandbox. That’s great for standalone or simple applications.
My company uses object oriented code with several layers, so one application may use many subsystems. Without the ability to map the modules back to their original subsystems we cannot use the sandbox feature. It would have worked well if a new field was introduced for the sandbox name instead of using the subsystem. Perhaps a new field or table could be added that would save the old subsystem so it could be replaced when the modules move out of the sandbox.

Currently the only solution is to continue creating environments for use with agile development which is a maintenance nightmare, or ask the application teams to redesign their software so it is contained within their own applications. This is not an option. So we’re going with the maintenance nightmare. I’ve tried designing a solution around the sandbox feature but it will be just as complicated as writing my own solution.

We have had this product for 18-20 years.

Endevor's very stable. We haven't had any issues with it going down. It's on the mainframe, so there really are no issues with stability.

We have five sysplexes. We've increased the number of LPARs. We've increased the number of business units; the lines of code. Everything is increased and we've automated moving things to production, so it really, it scales very well. We've had no issues with that.

We've used technical support several times, when they come out with new features. If we have issues with the features, or we're trying to figure out how we can use them best, we call technical support. Technical support has been great. They point us to the documentation; they'll help us with any issues; they work through everything very quickly.

I was not involved in the initial setup. I was a developer at that point, so I worked with Endevor from the other side.

Later on, I came in as the technical lead on Endevor. At that point, I was involved in cleaning up and streamlining what we had in our Endevor implementation.

The upgrade processes have changed over the years. The upgrade process is very easy now. It's an easy download and then we just have to do our testing. Rolling it out to the users is very simple.

Make sure you involve the technical people from CA on your design. When you bring your tools in, make sure you tell them what you're trying to solve, so they can help you design it correctly the first time, because once you get it in, it's difficult to change the way your design is without disrupting your business.

I haven't seen a perfect product, mostly because the products are usually very good in mainframe or distributed. I haven't seen a product that's really good in both. If it were good in both the mainframe and distributed source code, I would give it a perfect rating.

Managing source code artifacts. It controls who has access to the source code, it versions it, and it deploys it. It also presents it in a controlled environment. It has approval gates built in to the tool to allow different teams to sign off before a deploy.

It provides the business the level of governance it needs over the source code. We’re able to control the gold copy and we’re able to maintain versions, historical record, and control access.

I like the stability and CA’s responsiveness, but I haven’t used anything else, so it’s hard to judge. I don't have a frame of reference to know whether there may be something better.

It maintains a 99.999% uptime. It’s always been available and has always started. Upgrades are smooth and efficient. It’s a very mature, well-worn technology.

It’s so stable – it’s like the good child, you don’t really think about what it needs. I also manage the bad child, too.

We have used CA professional services to make modifications. It was fantastic – really helped some automations we were working on. They overcame the package shipping problem between separate data centers.

This is my only experience with mainframe software configuration management. There isn’t much competition in this space anyway.

Think about how it manages security of the assets and its governance properties.