If you come up with a good design, follow the recommendations, and start with a pilot with varied content of "types" of programs, then gradual incorporation of the systems into the inventory, it is straightforward.

The initial setup is highly complex. It requires a project to design the implementation of the software. It is not a straightforward default solution.

Actually I was not involved in the initial setup at the company I'm with now, but I was involved in it with the company I was with before.

Back in those days - this was years ago - at that point in time, it was complex in a way because the product was so flexible. You really have to figure out what you want to do first, even without the product there, just figure out how you want to handle things, and then you take the product, Endevor, and you kind of overlay it on top of what you want to do at your company. But it's so flexible you can do almost anything you want with it. Sometimes that can add to the complexity, but once you have the knowledge of the product, then the complexity goes away.

I was involved in setup. It was complex from the aspect that we were going from a different, core product. It was complex converting everything over to the libraries. But CA was very, very helpful in getting that work done for us.

The initial setup of Endevor is of a medium difficulty.

The initial setup is a bit complex. Two people are required for the deployment.

I think it's a pretty simple setup.

I was not involved with the initial setup. It was installed when I started working for this company. 

I do not do the upgrades. Somebody else does that. The whole separation of duties thing. The system programmer has to do one thing, and I do the rest.

The initial setup depends on the shop. Some instances it can be very straightforward to set up, while in another shop, depending on what type of source code they have or what type of procedures they have to get code into production, it can get complicated. I haven't seen anything that Endevor couldn't handle. I haven't found an issue anywhere where Endevor couldn't handle a piece of source code or the way a piece of source code is built.

I was not involved in the initial setup.

The initial setup was easily understood as far as the concept. The setup was difficult. We did need technical services initially, but I spent very little time in having to do anything with it. 

I was not involved in the initial setup, which happened back in 1993.

I've been in this role for the last eight years. Lately, I've actually installed and upgraded the last two releases of the software. It's gone very well.

The initial Endevor setup was very straightforward. After setting up the system and subsystem information within Endevor, source code is ported into Endevor through a batch process. Endevor keeps track of components for each element, so one part does not move into production without the other parts.

I wasn't involved in the initial setup, but those who were never complained. It's not considered one of the more complex products. They do the updates and I've never heard any complaints.

It was pretty straightforward.

I have been involved with the initial setup of version 18. I was not involved with the initial onboarding of Endevor. With version 18, so far, so good. There have been a couple stumbling blocks just setting up the different check boxes that you have to check to get certain features applied. But even then, if you go through the documentation or you reach out to customer service, you can get those pretty quick and easy. 

There are a few steps along the way that we stumbled on, but they were quick fixes and they were pretty minor.

I started managing about it four years back and we've gone through many upgrades and renewals, but I was not part of the initial set up.

If you're upgrading more than one version, there is a difference. Typically, if you upgrade frequently, it's better. But if you're doing multiple jumps then I would say getting CA's support would be helpful, as the underlying architecture could have changed and things could go south. So it is important to involve CA support or at least to have them review the plan.

It’s straightforward as long as you know the mainframe. If you don’t know the mainframe, they’ve gotten better with the instructions. It’s more like a distributed side. They’ve gotten a lot better, so it’s a lot easier. They’ve got little things that I would like to see. It’s more for the administrative side as opposed to the developer who uses Endevor.

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

I was not involved in the initial setup.

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

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.

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.

I was involved in the initial setup. While it was simple and straightforward, we took simple and straightforward, then made a disaster out of it. Back then, we did not have the knowledge base. Now, we do have the knowledge base. 

I find setup very straightforward. The biggest challenge we had when converting was replicating the compile options. The load module analyzer only looks at link options. It would be nice if it also looked at compile options.

It's complex because it depends upon your development architecture. Also, it's reached the limits of automation and freedom given to end users.

It was complex just from a matter of getting everything set up initially and making sure all our parameters were set properly. So it was about us getting everything there the first time. Because when you've got code everywhere, and you're trying to get it in one place, it can sometimes be a challenge just to find it all and get it there.

I was involved in the initial setup. It was complex. It is a toolbox, so you have got to design it to do what you want to get done, so it was complex. 

Straightforward in terms of the SDLC, but complex in the way the processors were initially built. A simple single stream of development made it easy to follow the development lifecycle.

The approach of writing a single set of Endevor processors to work across multiple instances of the application (separate systems) made the processors fairly complex, but once you understand them, they are so powerful.

I was not part of the initial setup. I have gone through several releases of the software, though. Those were pretty straightforward.

I did not perform the installation.

I was not involved in the initial setup.