BMC AMI DevX Reviews

As the administrator of BMC AMI DevX Code Pipeline, I set up applications, pipelines, associations, flags, and deployment. BMC AMI DevX Code Pipeline's deployment process has three phases. The first phase moves the source code from ISPW's internal libraries to the production libraries. Then it performs the implementation phase, and the final phase is the activation phase. The activation phase moves the code and performs DB2 binds if DB2 is involved in the COBOL programs. During the activation phase, if there are any CICS modules, it performs new copies and phasing commands. It actually runs and kicks off those started tasks to handle the activation phase.

I could not compare how BMC AMI DevX Code Pipeline has impacted my company positively because when I joined the company, this product was already installed. The organization had switched from Changeman to this product, ISPW, before my arrival, so I could not compare the benefits. BMC AMI DevX Code Pipeline is secure and has really tight controls. Nothing can get into production without the proper approvals and following the policies. The developers prefer to use it and are happy with it.

The best feature of BMC AMI DevX Code Pipeline that impresses me is the fallback functionality. The fallback functionality impresses me because when developers deploy large releases involving multiple components, such as COBOL programs, underlying copy books, and CICS modules, backing out changes would typically become a nightmare. With ISPW, developers can back out the entire release or entire package. If they deployed 100 components and want to back out everything, they can do so with one function and back out all components without worrying about backing out each individual component. They can back out the entire deployment set, which handles everything and brings them back to the previous versions. Developers can also selectively back out a subset of the deployed components. They also have the ability to revert to not just the most previous version but can go back several versions if they choose to do so. This gives them a lot of flexibility.

The only thing that bothers me about BMC AMI DevX Code Pipeline is the screen movement. On the screens, I cannot move to fields easily. I have to put my cursor on the field and tap it to bring focus there, or use the tab key multiple times to get to a field on the screen. This sometimes bothers me. If BMC AMI DevX Code Pipeline can improve the UI and user interface on the screens, that would be beneficial. Otherwise, I think the product works well.

I have been using BMC AMI DevX Code Pipeline since 2019, which is seven years.

BMC AMI DevX Code Pipeline is stable and reliable.

BMC AMI DevX Code Pipeline runs on one LPAR, and no matter where someone is in the world, they have to use it on that LPAR. My company does not provide copies of this product on different LPARs. For example, my company has the product installed on one LPAR, let's say SysB. If someone is in India, another country, or another state in the United States and wants to use it, they have to use it on SysB and all log into that. BMC AMI DevX Code Pipeline does have a PC version or internet version called Topaz. Again, it has to go to the same SysB and signs into the same SysB TSO and the same LPAR.

I have a very good experience with BMC AMI DevX Code Pipeline customer service and technical support. Every time I open a case, I get an immediate response. Sometimes it takes a while for them to provide a solution, but they usually do. They are very responsive.

My company was using Changeman before adopting BMC AMI DevX Code Pipeline. Changeman is another version control system that is similar in nature but did not have all the same functionalities that BMC AMI DevX Code Pipeline offers. It was limited.

I was not here to see the initial setup of BMC AMI DevX Code Pipeline, but I heard it took a while. A team of BMC engineers and developers came and sat with the company staff. It took them considerable time because the company had thousands of programs and underlying components, with DB2 and CICS involved. They had to study everything, take inventory of all the artifacts, and then set up sample applications in the product and test everything. I would assume the initial setup took at least a year.

My company is not currently considering changing to anything else regarding BMC AMI DevX Code Pipeline. In the past, the company may have considered other products, but I do not know how many others are available. The only other option is cloud-based, but I do not think the company is going in that direction.

BMC AMI DevX Code Pipeline is a solid product that any company can benefit from if they want to have tight control and a standard way of deploying applications into production in a secure manner. This is an excellent product to work with. I give this product a rating of 9.

BMC AMI DevX solutions are primarily used for mainframe-based resources and application development, encompassing not only COBOL but also Workbench and VS Code for various purposes.

Data management tools like File-AID enhance these capabilities, with features such as Host Manager allowing access to UNIX files on the mainframe, collectively serving as platform operations tools for developers.

While I am aware of the possibility to integrate Git with BMC AMI DevX zAdviser, this integration does not fit within our solution landscape.

BMC AMI DevX offers source code management through a tool called Code Pipeline, which I have been using as a source code manager and for building with custom scripts rather than out-of-the-box functionality.

Code Pipeline also serves as an artifact manager and release manager, providing DevOps capabilities for our organization.

Workbench functions as an IDE for developers, and data management tools enable editing, updating, browsing datasets, and unit testing.

Code Insights, an AI-based solution, helps with code explanation and visualization.

BMC AMI DevX's IDE provides a modern development experience that new developers prefer, and Code Pipeline stands out as a very good standalone solution, though it requires openness at an enterprise scale.

File-AID and similar products are also excellent.

BMC AMI DevX tools have noticeably impacted our developers' productivity and efficiency.

New-age developers prefer VS Code-based or Eclipse-based solutions, which eliminate the need to remember commands, and this represents a significant gain.

The CI/CD offering allows integration of quality checks and unit test processes into the pipeline, which improves compliance and enhances productivity, enabling developers to focus on development while the pipeline automates integration.

To improve BMC AMI DevX, consideration should be given to cloud-style provisioning and development models, as well as integration of more AI capabilities.

Enhancements in VS Code extensions to develop BMC-specific agents that developers can use in their day-to-day work could also make a significant difference.

I have been working with BMC AMI DevX, specifically with the AMI DevX products from Compuware, the company that BMC acquired, for at least seven years.

Hybrid CI/CD integration with existing enterprise DevOps tools is good, and I would rate BMC AMI DevX as a stable solution that I have been using for years and find working fine.

BMC AMI DevX is absolutely scalable, and while I am not certain how to rate it precisely, I consider it a highly scalable solution.

I communicate often with BMC AMI DevX's technical support.

BMC AMI DevX's technical support responds very well and takes all cases seriously.

One case involved certificate-based authentication, which they implemented successfully, and I suggested enhancements for the DB2 pipeline that they are working on, such as adding a validate button on the command center, which I hope will be available next quarter.

I evaluated other tools based on existing tools I had for years, which led to integrating the entire DevX ecosystem into a solution rather than searching for completely new tools.

Before adopting BMC AMI DevX, I carried out proofs of concept and shortlisted solutions, though I did not formally complete implementation with others.

We do development for our customers and we use Topaz to do backend systems for some Latin American banks. It's for enterprise data. It runs on AWS. I'm working on performance testing to do batch performance tests doing step functions with AWS for processes running through the database. 

The enterprise data is mostly for web applications and users are mostly online. There are long-term processes or transactions. The solution helps with a variety of use cases. 

Users don't have to pay for on-prem servers. The application is mostly in the cloud. It can be used across many countries. It doesn't matter where you are, you can use the application anywhere, anytime. 

The solution does handle large amounts of data. Banking systems always have big data that takes a lot of time to get processed.

Test data management capabilities are good. Sometimes it can be difficult to align with the requirements of the customer as it isn't exactly like transactional data. 

It's a very complicated tool.

Sometimes the customer wants better, faster transaction times. They want the solution to move as fast as possible. We're trying to scale and grow our application with more servers to get the level of speed desired. Everything from small processes to big batch processing needs to be faster. 

I've been using the solution for three years. 

The solution is stable for the most part. Mostly it is stable. Sometimes, if you have a beta version, it's not so stable. 

The scalablity is great and it scales well within AWS. You do have to understand the scalability within those systems, and you have to understand the network and how much processing you need, et cetera. 

We have thousands of users.

A lot of pipelines are executed during the installation process. The setup can be complex, depending on the parameters and requirements. Each pipeline could take an hour or more to implement. The compiling and testing processes take time. The security requirements and availability of the system are things that need to be considered at the outset. 

Maintenance is a big deal in the company I work with. The processes sometimes change from time to time and we need to adjust. 

I don't directly deal with the pricing side of the solution.

We use various versions of the solution.

I'd rate the solution overall at a seven out of ten. 

We use the solution clone test files.

The product has made our mainframe data management process easier. It has helped us save manhours. The tool's most valuable feature is the ability to edit tape files. Its ability to clone files is beneficial in application development. 

We plan to replace BMC Compuware File-AID due to its price. Two years back, we paid 11,000 dollars. However, the current price is 27,900 dollars. The price has increased to at least eight times its initial cost. We would need to pay around 60,000 dollars to have all three products together. We also encountered issues during version updates. 

I rate the tool's stability a ten out of ten. 

BMC Compuware File-AID is scalable. 

The tool's deployment is simple. 

We have seen ROI with the tool's use. 

I rate the product an eight out of ten. 

Using BMC Data Management for IMS and DB2 on z/OS has greatly improved our database administration tasks. Although we don't test the database before production, we have experienced benefits in disaster recovery situations and capacity management. For instance, when facing capacity issues during peak transaction times, I've been able to quickly allocate additional resources to ensure smooth operations. This has been crucial, especially during times when the demand surges, such as peak flight hours.

BMC Data Management improved our data recovery process by simplifying it. With IMS, recovery meant reloading the last transaction backup to restore databases quickly during downtime. It has been effective, ensuring minimal disruption and enabling smooth operations even during recovery events.

One area for improvement with this product could be in providing clearer guidance and tools for disaster recovery planning and execution. As someone involved in managing infrastructure, understanding the steps and terminology around disaster recovery is crucial for effectively rebuilding the business after a disaster.

Within our company, which has many thousands of employees, the data management team, including project managers and other roles, typically consists of around 50 people.

I would rate the support as an eight out of ten.

Positive

Setting up IMS with BMC's data management solutions is straightforward, but it requires collaboration across different parts of the business to understand critical data and recovery needs. It involves imagining scenarios and planning for disaster recovery, ensuring that essential data and operations can be restored efficiently in case of a disaster. The number of people maintaining the solution varies depending on the enterprise size, but typically it ranges from five to ten individuals.

From my perspective as an infrastructure guy, the most valuable aspect of BMC's data management solutions was their ability to optimize CPU cycles, improving IMS performance without directly impacting the database. This helped ensure smoother operations and faster transaction processing without significant changes to the underlying data structures.

I wouldn't recommend this product over others without considering individual business needs. For a small company, an SQL solution might be more suitable. The choice between BMC and other solutions depends on factors like support and budget availability. Overall, I would rate BMC Data Management as an eight out of ten.

We have five affiliates and we have installed ISPW in three of those affiliates. One of the things that we had as a goal was to standardize. Until we made the decision to go to ISPW, all of our affiliates had different source statement management processes. They all functioned differently. Our support teams were outsourced, and we couldn't really move a resource from one affiliate to the other without completely retraining them, because their processes were so different. They used different tools. We had CA-Panvalet, we had Endeavor, and we had some in-house tools. There was no standardization. Not being able to move resources was very limiting.

When we installed ISPW one of our goals was to standardize processes as much as possible so that if we needed to move resources from one affiliate to another affiliate, they could transition across with no training based on standardized ISPW processes. Retrieving the code, developing changes, setting up testing, reviewing results and staging for deployment to Production, would all be done the same way. That was the first one of our major goals.

A second goal was to install a system that would track the change process and provide real time information to the developers as to the status of their programs. This information was not readily available in our current process. This step was key to moving to a more Agile model of development. 

It helped us move more toward an Agile development path. We are closer to that than we had been before because one of the main functions of ISPW is tracking code. Information is real time and displays where the code is and who has it checked out. That is critical information when you have 250 developers in different countries and so many different things are happening at the same time. One of the drawbacks of going to an Agile-type platform is you have to have the tracking  information real time and easy to understand. With ISPW you have that information at hand all the time.  

In terms of time savings, with our previous tools there were different platforms and a lot of customization. One issue with our old system was the process required developers make a request to a special department for code to be made available for change. This could take as long as 3 weeks to get access to programs and JCL in order to start a project. With ISPW the developer has the ability to retrieve all of the components they need into their containers. That's something they can do within minutes. From a time standpoint, that has resulted in huge savings for each project. 

One of the features that the developers like is that they can retrieve what they need with ISPW. They don't have to go through a process or request something be done by another team. They can get the programs they need, compile them, retrieve the JCL and alter the JCL if they need to, and put these programs wherever they need to go for their testing. They can promote all the way through to the production step. I know that might make a lot of companies nervous when we talk about the fact that developers can promote to production. What that means is the developers promote the code to the point of being ready to be released into production.  The release step is still controlled using your current approval process. This  gives the development staff a lot more control over what they're doing, and it dovetails nicely into an Agile process. ISPW is really great at giving the developers access to all of the components all the way through the process.

The control of actually putting code into production is more about the "when" and not the "how." In most companies, your change-control coordinators or business analysts,  or managers that release code into production environment, will still do that last step. That's all controllable and secure at different levels. But it really gives the development staff a way to get everything where it needs to be, staged-up and ready to be released so that they can go work on something else. And the management of that movement into production is still maintained through whatever level you choose. 

I have been using Compuware ISPW for about two and a half years.

We installed it into three different affiliates within our company. We started that process in 2019 and finished in 2020. Our first installation was in June of 2019.

ISPW is a very stable product. 

I haven't seen any limitations when it comes to scalability. The three affiliate companies that we converted to ISPW were very different in size. The first one was the smallest, and had a lot of vendor code rather than customized code. The second affiliate had much more customized code and was medium in size, while the last one was our largest and had a lot of custom code and some very old code.

Our support teams are in five different locations and two different countries and there didn't seem to be any problems with that as far as access and speed. 

Their day-to-day tech support is great. We haven't had any problems with it at all. We had some issues that we reported back to them and we got support right away. They have always been there to help us. I would rate them very highly and responsive to any issues we've had. They were very quick, answering our calls right away.

We put some pretty heavy demands on BMC Compuware's professional services when we installed the solution. I required them to be on site with us every time we installed. They were on site at all three sites. We also had an implementation hotline set up for the first night of production support and they were there on the phone with us. They were physically in the building with us when we went live and were there at night on the phone with us when we went live. They stepped up and met our heavy demands.

Having them on site when we went live was something we arranged after the fact, after the contracts had been signed by our company. When we started laying out the project plan they came on site for a week to look at everything we had and how we did things. After we went through all of that and start building the detail project timeline we requested that BMC Compuware be on site at   "GO-Live" and they were very accommodating. 

Positive

Standardization was a key reason for switching. It was critical to standardize all of the development processes under a common Source Statement Management system. Before we converted to ISPW we were running 3 different systems at 3 different affiliates to manage source code. We converted those 3 affiliates to ISPW so that we could interchange our development resources without having to retrain personnel.  Also, the old systems that we were using were very expensive and ISPW's price point was extremely attractive. It gave us  more flexibility in being able to more development resources from one affiliate to another and the ability to standardize processes which allowed us to cut down on the number of people needed to maintain the different systems. 

Deploying it is a complex process, but BMC did a great job of supporting that process and working with us. They answered our questions and tried to understand our environment so that all process were support in the ISPW installation. You should definitely engage the professional services group to help you with the installation. While it was very complex, it was also very thoroughly understood by the teams that we worked with. They did a great job, evidenced by the fact that we were able to convert to  ISPW from two different Endeavor sites and one CA-Panvalet sites,  with between 30,000 and 50,000 programs a-piece, and be up and running at those sites in nine months.

I would certainly encourage everyone to engage their professional services and have a company team available to work with the professional services team. You need both sides. You need somebody within your company who understands what your company does, how all the processes work, and how each process will work using ISPW.  It's your responsibility, as a company, to own that process, and it's  BMC Compuware's responsibility to help you. It is not a case where you do nothing and they come and install it. You have to be engaged. And how you're going to train people should be talked about early in the process as well.

It is a complex process, but as long as both sides, your company and BMC Compuware work together, the result will be a very positive experience. Our project was very successful and was completed on time and within budget. 

When it comes to the actual installation, when you're setting up the parameters for how ISPW will work in your shop, there are a lot of questions that have to be answered. That's pretty normal with any software that you have to install, but because ISPW is a new animal and not very many people have a lot of experience with it, BMC Compuware should have more in-depth explanations about what the installation parameters mean and how each choice will impact your set-up.  I shared this feedback with BMC Compuware.

For example, one of the questions was, "Do you want to have a brand new load library that ISPW promotes the programs into for Production?" Depending on the answer to that question you could cause a lot of additional work to be done. The installation steps should contain some pros and cons about the options you can pick.

In terms of a deployment strategy, we picked some programs from several applications when we began the installation at each of our affiliates and we put up a test version of ISPW. Because we had a test area set aside for this work, we didn't interfere with anything else the development and production support teams were doing. We pulled real programs into the test version of ISPW and had our test team compile the programs, link-edit the programs, and test the programs using ISPW. We also used this test ISPW environment with real application code in it for training, so that when we had the developers sit down for those training sessions, they saw their real programs. 

In terms of maintaining the solution, there doesn't seem to be a lot involved, although you will need an administrator. The first few months there are certainly bumps that have to be worked out, but they were always there to answer our questions. After that, on a day-to-day basis, once you get the primary functions covered ISPW is very stable. There isn't a lot of breakage. The care and feeding have been very minimal since we went live with ISPW. 

Vendor supplied Professional Service installation team.  

Excellent support team. 

The price point is great.

The other solutions that we looked at were much more expensive and not nearly as flexible.

I would advise two things. First, you must have a technical group of people who understand what you're doing now, where your programs are, how you change them, how you test them, how you promote them. You need to be able to clearly communicate all of that so that the ISPW team can create the steps in ISPW to do the same.

Second, I would encourage any company to look at the whole process early on and develop realistic timelines for the whole project. Even the night you go live is a long process. This is not a 45-minute process and you're up and running. It takes time to build all the metadata that ISPW will use for tracking. 

You also need to think ahead about training. The training is a three-day class and you need all of your developers to sit through these classes. That's a logistics nightmare if you have five different sites and 200 people in different countries. You need to think about how you are going to train people, what you are going to show them, and about when you are going to do it. Are you going to do it with a test system or something else? If you don't look at all of that early on, you can be racing towards the installation deadline and realize, "Oh, I have to get 150 people in a room and get them trained. How am I going to do that?"  

Look at the whole process, start to finish. Plan for the "Go-live"  date, and how you are going to communicate where you are in the process to everyone that needs to know. Your team needs to have a really good understanding of all of those steps and then start to execute. We stumbled a little bit with our first installation but the last 2 were much more organized based on understanding how all of the key events had to happen and how to communicate to the development teams. 

 ISPW is an excellent product. It does everything the developers need it to do. We were able to build it and customize it, very simply, as we became more familiar with how the system works during installation. It doesn't need a lot of care and feeding once it's up and running. Our development teams think it is a great product as well. Installation-wise, I think more detail on the installation decisions you make up front would be very beneficial. But as a product, it's a solid nine out of 10.

Our primary use case is managing and deploying code. We also build outputs from the code. 

I think the most valuable features are code management, code deployment, and code generation. The fact that those three features are included makes BMC Compuware ISPW a robust product. If one of those features was missing, it would be less robust and less interesting. But because it has those three features, it is a very good solution for code development and management.

The solution could be improved by being better integrated with the open world. In the next release, I would like to have the ability to work in an open environment whilst remaining integrated with the legacy environment.

I have been using BMC Compuware ISPW for about 10 years.

I would rate the stability of this solution a nine, on a scale from one to 10, with one being the worst and 10 being the best.

I would rate the scalability of this solution a nine, on a scale from one to 10, with one being the worst and 10 being the best.

I would rate their technical support a nine, on a scale from one to 10, with one being the worst and 10 being the best.

Positive

I would rate the initial setup of this solution an eight, on a scale from one to 10, with one being the worst and 10 being the best. The deployment took a couple of months.

The solution requires an intensive planning process to deployment. Also, deployment is not immediate. We're not talking about the deployment of an app like Windows, which can be done in five minutes. We're talking about months. In some cases, it can even take a year. With this solution, deployment is an ongoing process; it is not something that you do once and you are done with it. 

To deploy this solution correctly, you first need to carry out an analysis of the current situation. After that, you need to decide what to do with it. This product is, generally speaking, for organizations that have problems in the development cycle. This tool automates the development cycle and makes it more efficient.

After the solution is deployed, it can be maintained by a single person.

I would say I can definitely see the return on investment. Any product that provides efficiency has a return on investment. It secures one of the most important assets any organization has, which its development in which billions of dollars are invested. That is a return in itself. It also makes the development cycle much more efficient; by as much as 20% or 30%.

I'm a consultant who helps users determine which product they want. I am not a user. I help users evaluate solutions for the implementation of a configuration management tool.

We use it to update data in Compuware File-AID for IMS and File-AID MBF.

We also use it in test cases.

Compuware File-AID can be used for DB2 as well.

I like that Compuware File-AID can actually map out control sections within load modules, or, as they're now known, program objects.

It can run a batch job to produce reports and spreadsheets or CSB to format a spreadsheet.

I like the ability that it has to format copy books in a presentable manner. So, you will be able to see the starting offset in length of each field within the layout.

The use of the product is very straightforward as well.

Integration is very easy.

Technical support has gotten better over the years, though there's always room for improvement.

I've been using it for, probably, close to 30 years.

It is a stable solution.

We're a very small organization as far as mainframe development. There are only four developers who use File-AID. So, it's still getting ramped up as far as its usage goes.

Technical support is provided by a mainframe management company and is decent. Their response time seems pretty decent. It's gotten better over the years. There have been features or bugs that we've reported that didn't get resolved for several weeks, if not months, but that has improved. So, I would give them a nine out of ten.

The installation is pretty straightforward.

I think it's a very decent product and would recommend Compuware File-AID. I would give it a rating of nine on a scale from one to ten.

We use it for debugging COBOL programs, either online IMS programs or Bash programs.

I've only been with this company for less than a year. The Compuware Suite was actually brought into the organization within the last three years, and it has really improved the way the developers manage the software.

I like the ability to flow through the source and see what happens to the data as the statements are executed. If there is a fault, it will track the event, and we can then look back to see why it may have caused the fault. You can also reverse engineer your test. You can set it so that you can go backward as well as forward in your test. This is something that I haven't done here at my company.

Compuware Xpediter is one of the best debugging tools for mainframe software development. We have currently licensed only the COBOL language for Xpediter, but I know they have other languages, including Assembler, PL/I.

Their technical support could be better. There were times where, when we reported bugs, they would fix one bug but add another one. That's probably because of their support model. A lot of organizations are developing software using Agile rather than the Waterfall method, so things are happening all over the place. You get things quicker, but sometimes one fix will break another one or add other bugs.

I have been using this solution for 25 to 30 years. 

It is stable.

It scales quite well. Currently, there are three of us who use it. We're into application development.

Compuware's product support is pretty decent, but their support model can be better. I would rate them an eight out of ten. 

It was fairly easy to install. It did require some assistance from database administrators for things that I wasn't authorized to do, but it was quite easy to install and configure.

I would rate Compuware Xpediter an eight out of ten. I am very satisfied with it. It is one of the best software testing and debugging tools in the industry.

I work for a huge bank, we use this solution for applications for grants, loans, and other stuff for our bank. DB2 is great. It is very robust with a great capacity to deliver the applications.

For bank applications, it's the best on the market. A lot of the major banks in my country use it. 

I have worked with DB2's great features in the last five years. The IDAA feature transformed the vision of warehousing, business analytics, and big data at my bank. Besides the mainframe, I saw that this solution was evolutionary. It gives real-time information.  

DB2 is a hard tool to grasp. It's hard for users to learn how to use it. It's not easy to see how it works.  

They need to improve this aspect of the solution. We've been working on it for 20 years so it's easy for us but it's very difficult to understand for newer users. It's harder to comprehend than other databases on the market. There should be better tutorials with better visuals. 

The stability is very good. 

The scalability is very good. They have a great success rate for the capacity of the application and scalability. I don't know of another database with this capacity.

We have had a few problems with support so I would rate them a nine out of ten. 

They didn't give us the answers we needed for our problems. We would try to explain the problem and they would give us a simple answer that didn't help. They didn't understand that our question was deeper than what they thought. I would have to schedule more meetings with them in order to actually get the problems resolved. Their techs need to be more experienced. 

The initial setup was straightforward. The time it takes to deploy a solution depends on the architecture. For a normal application for ZOS, starting from the development environment and pre-production, it should take around one week. 

We have a web feed and JPBC inside ZOS. It takes longer for this, around two weeks. There are more inquiries and more analysis required. 

I've had a great experience with BMC, but when a new feature or a new version would be announced, I felt that BMC was late to implement. 

I would rate DB2 a nine out of ten.